AIに修正を頼むと、数分後には整った差分が現れ、テストまで成功していることがある。そこで「もうほとんど完成だ」と考えたくなるが、早くできたのはあくまで最初の候補である。その変更をチームが安全に引き受けられるかどうかは、まだ分からない。

コーディングエージェントとは、既存のコードを読み、複数のファイルを書き換え、検査の一部まで実行するAIアシスタントである。画面に表示されたパッチは、正式な成果物ではなくレビュー待ちの変更案だ。要件に合っているか、問題なく導入できるか、半年後も保守できるかは、人間が別に確かめる必要がある。

GitHub Blogは、最初のパッチを一種の「price check」として使う見方を示している。小さな費用で具体案を作れば、考えられる解決策や影響範囲を早い段階で観察できる。ただし、そこで見えるのは主に候補を生成する費用である。人間が内容を理解して検証する負担や、導入後に維持する責任まで軽くなったとは限らない。

判断の基準は、AIがコードを書けたかどうかではない。チームがその変更を説明し、失敗時に元へ戻し、その後も維持できるだけの証拠がそろっているかどうかである。

最初のパッチは完成品ではなく、費用を測る試作品である

コードが動くことと、チームがコードを理解していることは別である。レビュー担当者は、変更の目的、データの流れ、権限の境界、主な失敗条件、復旧方法を自分の言葉で説明できなければならない。答えを得るたびにAIとの会話を読み直す必要があるなら、理解の費用は消えていない。後工程へ移されただけである。

導入後の責任もAIには移らない。障害を調査し、依存ライブラリを更新し、コードの意図を説明し、担当者が替わるときに知識を引き継ぐのはチームである。EASE 2026 / arXivの実証研究は、100件のリポジトリ、1,000超のファイル、約3,200件の変更を分析し、エージェントが生成したコードも、その後の保守の大部分を人間が担っていると報告している。

DORAは、AIを組織や開発体制の能力を増幅する存在として位置付けている。テスト、リリース手順、担当範囲が整っていれば、生成の速さを成果につなげやすい。一方で、基盤が曖昧なままでは、確認待ちの変更や誰も説明できないコードまで増幅される。

そこで最初のパッチは、本番導入を正当化する材料ではなく、チームが負う費用を調べるための限定的な試作品として扱う。変更を小さく、元に戻せる形に保てば、本格的な実装に進む前に、どの責任を引き受けることになるのかを確かめられる。

三つの費用を分けて判断する

候補パッチが届いたら、生成にかかった時間だけで総費用を判断しない。生成、レビュー、保守責任を分け、それぞれに具体的な証拠があるかを確認する。

見積もる費用確認すること判断の目安
生成コストこの案を得るまでに、どれだけ背景を説明し、何度やり直したか範囲が明確で、再実行しても同じ方針の案になるなら管理しやすい。実行のたびに設計が変わる、または口頭の事情を繰り返し補う必要があるなら、先に問題を整理して範囲を狭める。
レビューコスト人間が変更の狙い、データの流れ、権限境界、失敗条件を説明できるか変更箇所が絞られ、テストが要件に対応し、担当者がリスクの位置を説明できるなら評価を続けられる。正常系しか試していない、または不要な変更を見分けられないなら受け入れない。
保守責任コスト半年後の担当者は誰か。障害調査、復旧、更新、引き継ぎを実行できるか担当者が決まり、構造や監視方法がチーム内で共有されているなら引き受けられる。重要な知識がAIとの会話にしかない、未知の依存関係や見えない状態が増えるなら止めるか範囲を縮める。

三つすべてに証拠があり、人間による最終確認も終わっている場合だけ、判定はshipとなる。

方針は妥当でも、変更範囲が広すぎる、失敗時のテストが不足している、保守担当者が決まっていないといった補える問題が残るならreviseである。範囲を狭めるか、必要な証拠を追加してから評価し直す。

試作によって、要件が固まっていない、設計や検証の費用が期待価値を上回る、保守を引き受ける人がいないと判明したならstopを選ぶ。これは試作の失敗ではない。大きな開発費と長期的な責任を負う前に、進めない理由を低い費用で発見できたという成果である。

広告

元に戻せる小さな変更から始める

最初に試すのは、本番データへ直接触れず、変更全体を取り消せる小さな要件がよい。AIに任せるのは候補パッチの作成までとし、自動マージや自動リリースは許可しない。

着手前に、人間が次の境界を決めておく。

  • 変更を許可するファイル
  • 必須のテストと期待する結果
  • 人間が直接確認する箇所
  • 最終的な採否を決める担当者
  • 問題が起きた場合の復旧方法

この境界があれば、AIによる探索、人間による承認、チームによる保守責任の引き受けを別々に扱える。AIをどの操作の前で止めるべきか決まっていない場合は、AIエージェントにコードを任せる前に、タスクへチェックポイントを入れるを使って確認地点を設計できる。表示できる情報が限られるスマートフォンから操作するなら、スマートフォンで coding agent を起動できる今、見るだけ・任せる・承認するを分けるも確認しておきたい。

試作が終わったら、レビュー担当者はAIとの会話を見ずに、解決する問題、データの流れ、主な失敗条件、復旧手順を説明する。その後、予定されている保守担当者が、半年後もその変更を扱えるかを確認する。説明できることと、責任を引き受けられることの両方がそろって初めて、本番へ進む候補になる。

次に発生する小さな変更を一件だけ選び、生成、レビュー、保守責任の費用を別々に記録するとよい。証拠がそろえばship、不足を補えるならrevise、価値または担当者が見つからなければstopとする。生成速度ではなく、チームが説明し、復旧し、維持できる範囲で決めるのである。正式なマージとリリースには、どの判定でも人間の承認が必要だ。

AI整理カード

現在アクセスできるリポジトリ、プロジェクト、issue、Git履歴、テスト結果、作業環境を起点に調査する。最初の調査は読み取り専用とし、利用者に要件、diff、テスト資料、保守担当情報の事前整理を求めない。参照可能なプロジェクトが一つもない場合に限り、必要なリポジトリまたはプロジェクトへのアクセスを明示した質問を一つだけ行う。

調査結果から、小さく元に戻しやすい改善候補を一件だけ選ぶ。ファイルパス、issue本文、テスト出力、コミット履歴などの直接証拠を示し、「観測できた事実」と「そこからの推測」を分離する。裏付けがない項目は「要確認」と記し、事実を作らない。

判断文では、変更案を生成するコスト、人間がレビューするコスト、今後6か月にわたって保守責任を負うコストをそれぞれ評価する。そのうえで、推奨は ship、revise、stop のいずれか一つだけとする。ship は候補変更を準備する価値があるという意味に限定し、編集、マージ、デプロイ、リリースの許可とは扱わない。

最後に、問題、根拠、推測と要確認事項、三つのコスト、唯一の推奨を整理し、最小の次の行動を一つ示す。調査中はファイルを変更せず、実際の編集、マージ、デプロイ、リリースは人間の明示的な承認後にのみ行う。

生活四コマ

小さな継ぎ当てから、コート全体の責任が見えてくる

同じ青緑色のコートを調べた仕立て職人が、小さな表地の破れの奥に広い裏地の損傷を見つけ、作業範囲を止めて区切り、表地だけを直して裏地を後日に残す流れ。

  1. 客が持ち込んだコートには小さな破れが一つだけ見え、仕立て職人はすぐ終わる修理だと考えて当て布を手に取る。
  2. 同じコートを開くと、珊瑚色の裏地には広い破れとほつれた縫い目があり、見えていた以上の仕事が現れる。
  3. 仕立て職人は手を上げて作業を止め、今回は表地の小さな破れだけに範囲を絞り、つながったままの裏地を脇へ留める。
  4. 客には表地を直したコートを返し、傷んだ裏地は次に扱う仕事として見える状態で残す。

参考文献