コードレビューを別のAIに渡しても判断基準を維持する方法
一つのAIにコード構造を説明し別のAIにセキュリティやパフォーマンスレビューを任せられます。
しかし新しいAIが現在の作業の保存条件と証拠状態を知らなければすでに除外した解決策を再び提案したり範囲を広げる可能性があります。
コードレビューでつなぐべきなのはコード片だけではなく確認された事実、禁止条件と修正承認の境界です。
コードだけ伝達すれば抜ける情報
同じdiffを見ても次の情報がなければ判断が変わる可能性があります。
- ユーザーが経験した実際の障害
- 期待値と実際の値が最初に異なった境界
- すでに確認した非原因
- 必ず保存すべき既存機能
- 修正が許可されたファイルと関数
- まだ原因が確定していないという状態
- デプロイと検証のSTOP条件
Savedで証拠を残します
重要なログ解析、コード分岐とリスク警告をSavedとして残せます。
SavedはAIの回答を正解として確定する機能ではありません。次のレビュアーが再び確認すべき特定の質問と回答に戻る座標です。
Anchorでレビュー契約を作ります
別のAIに渡る前に次の内容をAnchorとして整理できます。
- 現在の問題定義
- 確認された事実
- ROOT_CAUSE_PROVENの有無
- 既存機能保存契約
- 許可された修正範囲
- 禁止された変更
- 次の検証作業
Anchorは実装指示書全体を代わりしませんが検討が出発すべき基準を提供します。
Handoffで役割を分離します
一つのAIにはread-only証拠検討を、別のAIには制限されたdiff reviewを任せられます。
Handoffを使えば同じ基準を毎回再び説明せずに役割別に異なる観点を受け取れます。
新しいAIが以前の結論を無条件に従うわけではありません。保存条件と証拠に基づいて独立的に検討します。
原因確定前に解決策が混ざらないようにします
コードレビューで最も危険なのは可能性のある原因を実際の原因として扱うことです。
Anchorに現在の証拠状態を明確に残せば次のAIが任意修正、ロールバックとリファクタリングに移ることを減らせます。
5BY.AIが自動的に作業を承認するわけではありません。ユーザーが決定したGateとSTOP条件を次の対話につなぐことです。
グラフィックビューで検討の流れを見ます
5BY.AIグラフィックビュー（Graph View）では原因調査Pack、重要なSaved、修正承認Anchorと以降のレビューPackがどうつながったか確認できます。
最終コミットだけでは消える次の内容を再び確認できます。
- なぜ該当ファイルだけ修正したか
- どのような代替案はなぜ除外したか
- どの証拠の後に修正が承認されたか
- デプロイ前に何を検討したか
実際のワークフロー
- 最初のAIで障害とコードの流れを調査します。
- 重要な不一致境界をSavedとして残します。
- 原因と保存契約をAnchorとして作ります。
- 別のAIにHandoffしてread-only反証検討を任せます。
- 原因が維持されればexact patch範囲を確定します。
- 実装後新しいAIで制限されたdiff reviewを実行します。
- 結果と残ったリスクを新しいAnchorに記録します。
公式開発記録を代替しません
コードリポジトリ、issue、テスト結果とデプロイ記録は公式システムに残す必要があります。
5BY.AIはその記録を代替するのではなくAIと検討しながら作られた判断の流れを再び見つけさせます。
コードレビューを別のAIに渡す時に必要なのは多くの説明をコピーすることではありません。
現在まで証明されたこととまだ証明されていないこと、保存すべき機能と許可された範囲を同じ出発点として維持することです。
5BY.AIのSaved、AnchorとHandoffはその判断基準が対話ウィンドウとAIサービスの間で消えないように助けます。