納品から3ヶ月後、特定の条件でだけ計算結果がずれる不具合が見つかった。開発会社に「なぜこの実装になっているのか」を尋ねたら、返ってきたのは「その部分はAIが生成したもので、当時の判断の経緯は残っていません」だった——。
こうした場面が、実際に発生しはじめています。コミット履歴もプルリクエストも残っている。それでも「なぜ」が復元できない。エージェント型の開発ツールが普及したことで、記録に残るものと残らないものの境界が動いたためです。発注する側にとっては、契約と受け入れの条件を見直す理由になります。
履歴は残っているのに、追えなくなった
従来のコードレビューは、人が書いて人が確認するという前提でできていました。誰が書いたかはコミットに残り、なぜそうしたかはレビューのやり取りに残る。この2つで「変更の来歴」がほぼ再構成できました。
エージェント型ツールが入ると、この前提が2か所で崩れます。
gihyo.jp の連載「エージェント型開発ツールの普及で問われる、ワークフローの監査可能性」では、崩れる箇所として変更の来歴、アイデンティティの帰属、意思決定の連鎖、ロールバック範囲の4点が挙げられています。とくに指摘されているのが、推論の過程が一時的なトレースとしてしか残らない場合、監査の段階で意思決定の連鎖を再構成できないという点です（gihyo.jp 前編）。
もうひとつは範囲の問題です。エージェントによる編集が複数のコミット・複数のリポジトリにまたがって連鎖している場合、ある変更だけを取り消す作業が、自動処理ではなく手作業の調査になります。
つまり記録が消えたのではなく、記録の粒度が実際の変更の粒度に合わなくなったということです。
発注側が指定できる記録は4種類
「AIを使わないでください」と指定するのは、いまや現実的ではありませんし、生産性を捨てるだけです。指定すべきなのは使用可否ではなく、残す記録です。契約書や仕様書に書ける形にすると、次の4つに整理できます。
| 記録の種類 | 何が復元できるか | 無いと起きること |
|---|---|---|
| 入力の記録（何を見て判断したか） | 参照した仕様・既存コード・外部情報 | 前提が間違っていたのか実装が間違っていたのか切り分けられない |
| 判断の記録（なぜその案を採ったか） | 却下された選択肢と採用理由 | 同じ議論を毎回やり直す |
| 帰属の記録（人か、エージェントか） | 変更の責任範囲 | レビュー済みかどうかが分からない |
| 影響範囲の記録（どこまで及ぶか） | 取り消すときに触る範囲 | ロールバックが手作業の調査になる |
このうち、発注側が受け入れ時にいちばん困るのは3番目です。人がレビューして通したのか、エージェントの出力をそのまま通したのかが区別できないと、品質保証の前提が立ちません。AIによるレビューをどこまで信頼できるかについてはAIエージェントにソース管理のレビューを任せるときで扱っています。
ロールバックは「元に戻す」ではなくなった
もうひとつ、発注側の認識を更新しておくべき点があります。
障害時の切り戻しを「直前の状態に戻す操作」だと思っていると、エージェントが関与した変更では通用しません。変更が複数の判断の連鎖として積み上がっている場合、どの判断列を無効化し、どの分岐を新しい正本として採用するかを明示しなければ、戻した先が整合しないからです。
これは運用条件の話でもあります。「障害時は前バージョンに戻す」という一文だけを契約に入れていると、実際には戻せない、あるいは戻すのに数日かかるという事態になります。切り戻しの手順が定義されているか、その手順が実際に試されたことがあるか。この2点は受け入れ時に確認できます。
エージェントが権限を持って動く前提での事故の広がり方はAIエージェントの権限設計と信頼境界にまとめています。
受け入れ時に聞くこと
専門知識がなくても確認できる質問に落とすと、次の3つに絞れます。
- 「この機能の実装方針を決めた記録はどこにありますか」 — 出てこない場合、その機能は将来の改修で毎回ゼロから読み解くことになります
- 「AIが生成した部分と、人がレビューした部分は区別できますか」 — 区別できない場合、品質保証の対象範囲が実質的に不明です
- 「この変更だけを取り消すとしたら、どこを触りますか」 — 即答できない箇所は、障害時に長時間止まる箇所です
いずれも「できていないから駄目」という話ではありません。答えられない箇所がどこかを、納品前に把握しておくための質問です。把握できていれば、その部分だけドキュメントを厚くする、といった手当てができます。
聞くタイミングも重要です。納品検収の場で初めて尋ねると、記録が残っていなかった場合に後から作り直すことになり、実質的に「思い出して書く」作業になります。着手前に「この3点を受け入れ条件にします」と伝えておけば、記録は開発の過程で自然に溜まります。後から求めるほど精度が落ち、コストが上がる種類の情報です。
記録を求めすぎると開発は止まる
一方で、すべての変更に完全な記録を求めると、エージェントを使う意味がなくなります。速度を得るために導入したものに、速度を殺す条件を付けることになるからです。
現実的な線引きは、壊れたときの損失で分けることです。決済・認証・個人情報を扱う経路は記録を厚くし、管理画面の表示調整のような箇所は通常のコミット履歴で足ります。全体に一律の基準を敷くのではなく、範囲を先に決めるほうが機能します。
この線引きは、発注側でも引ける種類のものです。技術的な詳細が分からなくても、「この機能が止まったら業務が何時間止まるか」「この情報が漏れたら誰に説明が必要か」は答えられます。その答えが重い箇所だけ、記録の条件を明示する。それ以外は開発側の裁量に任せたほうが、結果的に速度も品質も出ます。
プルリクエストが大量に流れてくる状況でレビューをどう成立させるかはAI生成コードでプルリクエストが溢れたときの現実解で扱っています。
次にやること
いま進行中、あるいは直近で納品を受けた案件で、「なぜこの実装なのか」を説明できる資料がどこにあるかを確認してください。開発会社の担当者の記憶の中にしかないなら、担当者が変わった時点で失われます。
そのうえで、次の発注では受け入れ条件に「実装方針の記録」と「人のレビュー範囲の明示」を1行ずつ入れておくだけで、数年後の改修コストが変わります。
AIエージェントを前提とした開発体制の設計や、既存システムの引き継ぎ可能性の評価について相談したい場合は、グリームハブの開発・AI・自動化のご相談で承っています。システムの規模や求める記録の粒度によって適切な体制は変わるため、個別にご相談ください。お問い合わせからどうぞ。
