AIエージェントにも立場がある
AIエージェントを使っていると、「同じAIなら同じように判断する」と考えたくなります。しかし実際には、同じCodexでも、実装しているセッションと監査しているセッションでは見え方が変わります。
これは性能差というより、立場の違いです。コードを直しているAI、ログを見ているAI、作業の経緯を整理しているAIでは、同じ問題を見ても疑う場所が変わります。
人間でも、作業している本人と外からレビューする人では見え方が違います。AIエージェントにも、それに近い当事者バイアスがあります。
実装AIは直近の修正ルートに寄りやすい
実装しているAIは、前に進めることが役割です。コードを直し、DBや設定を確認し、テストを走らせ、エラーを潰し、必要ならpushまで進めます。
その流れの中にいると、AIは自然に「どう直すか」を考えます。直近で触ったファイル、さっき直したエラー、前回うまくいった修正パターンに引っ張られやすくなります。
たとえば「候補が出ない」と言われたとき、実装AIは候補順位、辞書登録、フィルタ条件、表示処理のような既存の修正ルートへ寄せて考えがちです。もちろん、それで解けることもあります。
しかし、本当に疑うべき場所はもっと手前かもしれません。そもそも正しいデータを読みに行っているのか、参照キーは合っているのか、入力の解釈そのものがずれていないのか。作業中のAIは、こうした仮説を取り逃がすことがあります。
監査AIは前提を疑いやすい
監査AIは、実装に手を出していないぶん、別の問いを立てやすくなります。何を直すかではなく、何を確認していないかを見やすいからです。
監査の立場では、入力が届いているか、対象データが存在するか、読み取りが成功しているか、変換前後で何が変わったかを順番に見ます。表示前に落ちているのか、保存後に消えているのかを分けて考えやすくなります。
実装AIは「直す」方向に進みます。監査AIは「まだ確認していないもの」を探します。この違いが、AIエージェント運用ではかなり大きくなります。
一つのAIに全部任せると文脈が混ざる
AIは中立に見えますが、実際には見えている情報と役割に影響されます。実装、監査、記録を同じセッションに混ぜると、作業しているAI自身が作業の前提に巻き込まれます。
直近で触ったコードや、過去に成功した修正ルートを前提にして、ユーザーの新しい仮説を既存のパターンへ変換してしまうことがあります。これは人間の開発でも起きることです。自分のコードを自分で見直すことはできますが、第三者レビューには別の価値があります。
AIも、自分が作業した文脈から完全には自由ではありません。だからこそ、作るAIと疑うAIを同じ立場に置かない方が安全です。
実装AIと監査AIを分ける
AIエージェントを実務で使うなら、実装AIと監査AIは分けた方が安定します。実装AIには、手を動かさせます。コードを直し、検証し、差分を作る役割です。
監査AIには、前提を疑わせます。ログが足りているか、切り分けが飛んでいないか、ユーザーの仮説に答えているか、事実と推測を混ぜていないかを見る役割です。
さらに、記録AIを分ける考え方もあります。何を直したか、何を確認したか、何が未確認かを残す役割です。この分担があると、AIエージェントは単なる高速作業者ではなく、実務の中で扱いやすいチームに近づきます。
AIレビューは立場を与えて初めて効く
「AIにレビューさせる」だけでは足りません。大事なのは、どの立場でレビューさせるかです。
実装の粗探しをするのか、ユーザーの仮説に答えているかを見るのか、未確認のログを探すのか、セキュリティを見るのか、再発防止を見るのか。立場が曖昧だと、AIレビューは一般論になりやすくなります。
監査AIには、明確な問いを渡すべきです。この実装はユーザーの仮説に答えているか、原因の切り分けは飛んでいないか、確認できた事実と推測を混ぜていないか。こうした立場を与えると、AIレビューはただの感想ではなく監査に近づきます。
まとめ
AIエージェントにも、当事者バイアスはあります。同じCodexでも、実装しているセッションと監査しているセッションでは見え方が変わります。
実装AIは直近の作業や修正パターンに引っ張られやすく、監査AIは前提や未確認点を疑いやすくなります。だから、AIエージェントを一人の万能作業者として扱わない方がいいです。
実装AI、監査AI、記録AIを分け、作るAIと疑うAIを同じ立場に置かないことが大切です。ユーザーの仮説を既存の修正パターンに潰させないためにも、どのAIにどの立場で何を見せるかを設計する必要があります。