すべてのAIコーディングエージェントは、diff（差分）を出力できます。真の問題は、そのdiffが集中した意図的なプロセスから生まれたものなのか、それともリポジトリを必死にスキャンした結果、偶然正解に辿り着いたものなのかを判断することにあります。現在、ほとんどのチームはその違いを見分けることができません。

これは技術的な限界ではなく、可視性の問題です。

エージェントが3行の本番用コードを書くとき、それは3つのファイルを読み、テストを実行しただけかもしれません。あるいは、無関係な40個のファイルに触れ、十数回のコマンド失敗を繰り返し、依存関係のインストールが壊れたためにテストスイートをスキップし、その代償として料金を請求してきただけかもしれません。どちらにせよ、diffの見え方は同じです。プロセスの記録がなければ、結果の品質について推測するしかありません。

なぜチャットログは「レシート」ではないのか

多くのツールが、作業の証明としてチャットのトランスクリプト（対話記録）を提供しています。しかし、トランスクリプトはレシートではありません。それは、机の上にぶちまけられた部品の箱のようなものです。そこには、あらゆる思考のループ、あらゆる失敗した試行、あらゆるシステムプロンプト、そしてあらゆる無関係なツール呼び出しが含まれています。3行のパッチを検証するために1,000行もの会話を読む必要があるなら、あなたのレビューワークフローはすでに崩壊しています。

人間の注意力は有限です。エージェントの目的は認知的な労力を節約することであり、宿題を増やすことではありません。トランスクリプトは、レビュアーに探偵になることを強います。レシートは、一目で答えを提示します。

有用なレシートとは、実用的な要約です。エージェントに何を依頼したのか、実際に何を行ったのか、そしてどのように結論に至ったのかを伝えます。失敗を隠すのではなく、それを浮き彫りにします。

優れたレシートとは何か

レビュー可能なレシートは、深掘りすることなく以下の具体的な質問に答えるべきです。

  • タスクは何だったのか？ 曖昧なプロンプトの繰り返しではなく、意図された変更の明確な説明。
  • どのファイルが読み込まれたか？ エージェントが正しいソースからコンテキストを構築したかどうかを判断するため。
  • どのファイルが編集されたか？ 変更の最終的な痕跡。
  • どのコマンドが実行されたか？ エージェントが呼び出したビルドステップ、リンター、フォーマッター、またはカスタムスクリプト。
  • どのコマンドが失敗したか？ 成功したコマンドだけでなく、失敗したコマンドも重要です。失敗は、エージェントがどこで即興的な対応を迫られたか、あるいはどこで諦めたかを明らかにします。
  • どのテストがパスしたか、あるいはスキップされたか？ スキップされたテストは警告サインです。レシートには、なぜスキップされたのかを記載すべきです。
  • 総コストはいくらか？ トークン、API呼び出し、計算時間。これにはモデルだけでなく、アーキテクチャのコストも含まれます。

この形式により、レビューは「考古学的な発掘作業」から「迅速なサニティチェック」へと変わります。シニアエンジニアは、レシートをスキャンして1分以内に「これは理にかなっている」あるいは「これは怪しい」と判断できるはずです。

履歴だけでなく「フットプリント」を読め

エージェントの実行によるフットプリントは、作業の形を示します。エージェントはチケットの範囲内に留まっていましたか？それとも、無関係なモジュールに迷い込み、誰も求めていない変更を加えてしまいましたか？「読み込まれたファイル」と並んで「編集されたファイル」をリストするレシートがあれば、これは一目瞭然です。

フットプリントは繰り返しのパターンも明らかにします。同じ設定ファイルを3回読み直したり、失敗するテストを何度も実行したりと、同じ行き止まりに突き当たり続けているエージェントは、計算リソースとコンテキストウィンドウを浪費しています。そのパターンは可視化されるべきです。マイグレーションスクリプトの実行に9回かかったなら、レシートにそう記載されるべきです。その情報は、出力の評価方法を変えます。力技の混乱によって生み出された「正しい」diffは、クリーンに生み出された正しいdiffとは別物です。

不適切な設計に潜むコスト

コストとは、単なるトークンあたりの価格ではありません。設計の悪いワークフローは、エージェントが文字を生成する前から高価なものになります。肥大化したツールスキーマ、不要なファイルインデックス作成、過度に広範なシステムプロンプトは、すべてコンテキストウィンドウを膨張させます。レシートはこのオーバーヘッドを露呈させるべきです。

生成コストが下がってもレビューが難しくなるなら、得られるものは何もありません。ボトルネックを移動させただけです。エンジニアの時間は、通常、チームにおいて最も希少なリソースです。APIコストを5ドル節約するために、プルリクエストあたりのレビュー時間を30分増やすのは、最悪のトレードオフです。レシートは、このトレードオフを直接監査するのに役立ちます。

「誠実さ」は機能である

有用なレシートは、必要に応じて「不快なもの」であるべきです。エージェントが非効率に見えるような事実を報告すべきです。なぜなら、その誠実さが、次の人間による意思決定をより速く、より良くするからです。

例が重要です：

  • 「1行の変更のために37個のファイルを読み込んだ。」
  • 「npm install がピア依存関係の競合で失敗したため、テストをスキップした。」
  • 「エージェントが導入したインポートを修正するため、要求されたスコープ外の utils.py を編集した。」
  • 「リンターを4回実行。最初の3回はパスの設定ミスにより失敗した。」

これらはレシート（実行記録）のバグではありません。これらはシグナルです。レビュアーに対して、どこに疑念を向けるべきかを伝えています。また、プラットフォームチームに対しては、ワークフロー自体のどこを強化すべきかを伝えています。

小さな実行、より明確な監視

エージェントに広範囲を自由に走らせたくなる誘惑は自然なものです。サービス全体をリファクタリングするために巨大なプロンプトを1つ投げるのは、一見速そうに思えます。しかし、実際はそうではありません。それはレビュー不可能な「作業の塊」を生み出します。変更された80個のファイルのうち、どれが意図的なものだったのかを追跡しているうちに、午後の時間は消えてしまいます。

小さく、検証可能な実行の方が優れています。タスクに対して明確な境界を定義してください。エージェントが読み取ることができるファイルのリストと、書き込めるファイルのリストを分けましょう。行き止まりが可視化されるよう、失敗したコマンドの履歴を記録してください。スキップされた検証は明示的にフラグを立てます。検索APIからテストランナーまで、あらゆる外部ツールの使用を記録してください。

目標は完全な自律性ではありません。人間が検証できない完全な自律性は、単に責任を伴うだけの自動化に過ぎません。真の目標はレビューのしやすさ（reviewability）です。エージェントのアウトプットは、承認も拒否も容易であるべきです。調査するのが疲れすぎて、仕方なくコードを受け入れてしまうような、曖昧な中間地帯があってはなりません。

あらゆるコーディングエージェントへのテスト

いかなるエージェントやプラットフォームを採用する前にも、一つの質問を投げかけてください。「それは、人間が自信を持って次のステップを承認できるだけの十分な証拠を残せるか？」

もし答えが「はい」であれば、そのツールはプロフェッショナルなワークフローに適しています。もし答えが「いいえ」であれば、あなたは生産性を買っているのではなく、「たまにコンパイルできる謎」を買っていることになります。それは週末のサイドプロジェクトなら構いませんが、プロダクションエンジニアリングにおいては容認できません。

エージェントのアウトプットを「検証なしの贈り物」として扱うチームは、検知できなかったスコープクリープによって導入された、微細なバグを最終的にリリースしてしまうことになります。差分（diff）は一見無害に見えるでしょう。しかし、レシートがあれば真実が語られていたはずなのです。

レシートを要求しましょう。レビューのために設計しましょう。信頼は戦略ではありません。証拠こそが戦略なのです。

AIツールや開発者ワークフローに関するより実践的な議論については、GyaanSetu on Telegram のコミュニティに参加してください。