AIとの会話で決めたこと、チームに残ってる？判断を共有する5行

火曜の16時47分。ECサイトの在庫同期を直したPRに、レビューコメントが付いた。

既存の定期実行ではなく、キューを増やした理由は何ですか？

質問を見た瞬間、手が止まった。

午後はAIと40分ほど会話していた。定期実行、キュー、データベースの変更検知を比べ、失敗時の再実行や二重更新まで質問した。最後には「この案件ならキューがよさそうだ」と納得してコードを書いた。テストも通っている。

なのに、PR本文には「在庫同期をキュー化しました」としか書いていない。

会話履歴を開くと長い。途中には採用しなかった案も、勘違いした質問も、AIが訂正した回答も混ざっている。全部貼れば相手の時間を奪いそうだし、きれいに説明し直すのも面倒だ。「AIと相談して、この方式がよさそうだったので」と返しかける。でも、それでは自分が決めた理由にならない。

説明できない恥ずかしさから、コメントへの返信を後回しにしたくなる。質問が責められているようにも見えてくる。さっきまで進んでいた仕事が、急に自分の足元だけ抜けた感じがする😓

ここで必要なのは、AIとの会話を隠すことでも、全部公開することでもない。会話の中で固まった判断を、チームが確認できる短い記録にまとめ直すことだ。

AIとの会話だけに置いた判断は、チームから見えない

AIを使うと、調査と比較はかなり速くなる。質問を重ねるうちに、自分の中では前提がつながり、「なぜこの案なのか」まで理解した気持ちになる。

ただ、その納得は自動では共有されない。コードには最終案が残るが、捨てた案や、受け入れた不便さ、判断を変える条件までは残りにくい。

個人の速さが、そのままチームの速さにはならない

Stack Overflow の 2025 Developer Survey では、AIエージェント利用者の約70%が特定作業の時間短縮を、69%が生産性向上を感じている。一方、チーム内の協働が良くなったと答えた人は17%だった。

これは「AIを使うと協働が悪くなる」という意味ではない。個人の作業が速くなっても、判断を渡す仕組みがなければ、チーム側の確認は別に残るということだ。

DORAの2025年レポートも、AIはチームの状態を良くも悪くも強めると整理している。調査や変更量が増えても、明確な進め方、変更履歴を残す仕組み、短い確認の往復が弱ければ、レビューやリリースが不安定になる。

火曜のPRも同じだった。実装者の中では40分進んだ。でもレビュー担当者は、コードから理由を逆算するところから始める。個人が短縮した時間を、別の人が文脈探しに使えば、チーム全体ではあまり速くならない。

会話全文を貼っても、判断は見えにくい

それならAIとの会話を丸ごと共有すればよいかというと、そう簡単でもない。

長い会話には、前提を探る質問、外れた仮説、言い直し、採用しなかったコードが含まれる。顧客名、未公開仕様、接続情報など、共有先を広げるべきでない情報が混ざることもある。読み手は「結局、何を決めたのか」を会話の中から探さなければならない。

会話履歴は、考えるための作業机にはなる。でも、チームの決定記録とは役割が違う。

共有したいのは、AIが何文字話したかではない。どんな前提で、何と比べ、誰が何を選び、どんな不便さまで受け入れたかだ。ここが見えれば、レビュー担当者はAIとの会話を再現しなくても判断に参加できる🔍

会話を閉じる前に、判断を5行にまとめる

大げさな設計書を毎回作る必要はない。まずはPRやIssueに、次の5行を置けばよい。

前提: 何を守る必要があるか
候補: 何と何を比べたか
決定: 今回は何を選ぶか
理由: なぜ選び、どの不便さを受け入れるか
見直し条件: 何が変わったら決め直すか

AWSのArchitectural Decision Record、略してADRのガイドでも、重要な設計判断には少なくとも「判断の背景」「決めたこと」「その結果として生じること」を残すとしている。ADRは設計判断の記録だが、小さなPRでいきなり正式な文書を作る必要はない。まず日常語の5行に縮めれば十分だ。

1行目と2行目で、話の出発点をそろえる

火曜の在庫同期なら、最初の2行はこうなる。

前提: 外部APIが一時的に失敗しても再実行でき、同じ商品を二重更新しないことが必要。

候補: 既存の5分ごとの定期実行を延ばす案と、商品単位のキューへ分ける案を比較した。

先に置くのは技術名ではなく、守りたい状態だ。「キューを使いたい」から始めると、手段を正当化する話になりやすい。「一時失敗から戻したい」「二重更新を避けたい」から始めれば、別案の方がよい時にも引き返せる。

候補は、AIが最初に出した案を全部並べなくてよい。最後まで比較対象になったものだけでよい。採用しなかった案が一つ見えるだけでも、「なんとなく新しい仕組みを増やしたわけではない」と伝わる。

3行目と4行目で、選択と引き受ける不便さを分ける

次の2行はこうだ。

決定: 商品単位で再実行できるキューを使う。

理由: 一時失敗だけをやり直せるため。代わりに、滞留件数の監視と失敗ジョブの確認作業が増える。

ここで大事なのは、利点だけを書かないことだ。どの案にも不便さはある。監視対象が増える、運用が複雑になる、費用が増える、元に戻しにくくなる。そこまで書くと、判断が急に現実へ戻る。

AIは候補や利点をきれいに並べてくれる。だからこそ、人は「この案件で引き受ける不便さ」を決める。AIの回答に判を押すのではなく、自分たちの条件で選び直すわけだ。

説明を返すのが怖かった人も、引き受ける不便さまで書けると気持ちが少し変わる。完璧な正解を証明しなくてよい。何を得て、何を負担する案なのかを出せば、チームで修正できるからだ。

5行目があると、決定が檻にならない

最後は見直し条件だ。

見直し条件: 同期件数が1日500件を超える、または5分以内の反映が不要になった時に、方式と運用費を再比較する。

判断を記録するのが重く感じるのは、「一度書いたら永遠に守らないといけない」と思うからでもある。でも、条件が変われば決め直してよい。

AWSのADRガイドでも、新しい事情で判断を変える時は、新しい記録で前の判断を置き換える流れを示している。見直し条件があれば、今の情報で決めることと、将来の可能性を閉じないことを両立しやすい。

これで5行がそろった。会話40分を要約したのではない。チームが賛成、修正、反対を選べる形に変えたのだ。

判断の大きさで、置き場所を変える

すべてを同じ文書に残すと、今度は記録作業が詰まる。大事なのは、判断の大きさに合う場所へ置き、あとからコードと結びつけられるようにすることだ。

小さく戻せる判断は、PR本文に置く

一つのPRで完結し、問題があればすぐ戻せる判断は、PR本文の5行で足りる。ライブラリ内の関数を使うか標準機能で書くか、再試行回数を何回にするか、画面内で状態を持つかURLに持つか、といった判断だ。

レビューで内容が変わったら、その5行も直す。コードだけ修正して判断記録を古いままにしない。

AIで作ったPRを渡す時の4項目は、変更理由、確認済み、未確認、見てほしい場所を渡す方法を扱っている。今回の5行は、その中でも「なぜこの方式を選んだか」を一段深く残したい時に使える。

複数のPRへ効く判断は、IssueかADRに置く

認証方式、外部サービス、データの持ち方、運用体制のように、複数の変更へ影響する判断は、PRだけだと後で見失う。Issueやリポジトリ内のADRに5行を置き、各PRからリンクする。

ADRという言葉に身構えなくていい。最初から長い資料にせず、5行に日付、状態、決める人を足すところから始めればよい。大切なのは文書名ではなく、次の人が「なぜこうなっているのか」をコードの外でも確認できることだ。

NISTの生成AI向けリスク管理資料は、事故対応の文脈で、記録、変更履歴、いつ誰が何を変えたかという情報が、関係者との共有を助けると整理している。普段の設計判断も、問題が起きてから会話履歴を掘るより、変更と理由を結びつけておく方が追いやすい。

AIの提案と、人が決めたことを混ぜない

記録には「AIがキューを推奨した」とだけ書かない。AIは比較のたたき台を出せるが、案件の優先順位や運用負担を引き受ける人までは決められない。

まず、公式資料や既存コード、手元の検証から確認できた事実を書く。次に、AIを含む候補整理で分かった選択肢を書く。最後に、チームが選んだ案と理由を書く。この順なら、AIの説明が間違っていた時も、どこへ戻ればよいか分かる。

「AIが言ったから」ではなく、「既存の定期実行では失敗単位の再実行が難しいことをコードで確認し、監視が増える点も含めてキューを選んだ」と言える。これなら判断の持ち主が見える。

次の1件を、10分でチームが確認できる形にする

火曜のPRに5行を追記すると、レビュー担当者から返ってきた。

その前提ならキューでよさそうです。滞留監視だけ、このPRに含めるか分けるか決めましょう。

反対されなかったから安心したのではない。話す場所が「AIを信じたかどうか」から、「監視をどこまで今回入れるか」へ移ったことで、肩の力が抜けた。質問は責めるためではなく、判断に参加するためだったと分かる🙂

まず一つ、会話履歴を閉じる前に書く

今日から全部の判断ログを整えなくてよい。直近のAI支援で作った変更を一つだけ開き、会話を見ずに次の問いへ答えてみる。

何を守るための変更か
最後まで比べた候補は何か
今回は何を選んだか
得るものと、引き受ける不便さは何か
何が変わったら見直すか

答えられない行があれば、そこだけ会話、公式資料、既存コード、テストへ戻る。5行を書いたら、「実装が合っているか」だけでなく「この不便さを受け入れてよいか」をレビューで聞く。

AIとの会話は、考える速度を上げてくれる。ただし、会話の中だけで決めたことは、チームにとってまだ決定になっていない。

前提、候補、決定、理由、見直し条件の5行にまとめる。 それだけで、個人の速さを、次の人が続きから考えられる仕事へ変えやすくなる。

AI活用の判断とチームへの渡し方を整理する

ページへ移動

AIとの会話で決めたこと、チームに残ってる？判断を共有する5行

AIとの会話で決めたこと、チームに残ってる？判断を共有する5行