一晩で3つのPRを完了させたエージェント。しかし、私のメッセージの40%は修正指示だった。
私のAI駆動コーディングエージェントは、一晩で3つのプルリクエスト（PR）をプッシュしたが、私が送った30のメッセージのうち40%は修正指示だった。
このセッションでは、MCPクライアント、Azure AI Agent、およびM365 Copilot Agentが作成された。自動チェックは3つのPRすべてをパスし、私はコードを一行も編集しなかった。しかし、ログ（transcript）は異なる物語を語っている。合計710のメッセージのうち、私が入力したのは30で、そのうち12がエージェントを軌道に戻すためのものだった。「ステアリング率（steering rate）」、つまり私のメッセージに占める修正指示の割合は40%に達した。
パイプラインの構成
- Claude がハイレベルな実装計画を策定。
- DeepSeek V4-Flash がオーケストレーターとして機能し、計画をレビュー。
- Codex が実際のコードを生成。
- オーケストレーターがコードを検査し、プルリクエストを作成。
オーケストレーターの本来の役割は、純粋にコンポーネント間を「つなぐ」ことであり、自らコードを書くのではなく、コンポーネント間の競合を解決することであった。実際には、エージェントは約40分間で3つのPRにわたって3,500行のコードを生成したが、同時に2つの繰り返されるエラーパターンに陥った。
2つのエラーパターン
- ワークフロー違反 – オーケストレーターが時折コーディング工程を乗っ取り、「接着剤（glue）」としての役割を無視して、自ら実装の詳細を書き込んでしまう。
- コンテキスト取得の失敗 – 明示的な指示があったにもかかわらず、エージェントが誤ったSDKやバージョンを選択した。正しい情報はプロンプトのコンテキスト内に存在していたが、モデルが適切なタイミングでそれを引き出すことができなかった。
これらは推論能力の欠如ではなく、ワークフローの制約の仕方に起因するエンジニアリング上のバグである。より高性能な言語モデルであっても、オーケストレーターを非コーディング業務に固定し、正しいSDKの選択を強制するための、強力で絶対的なルールが必要になる。
エージェントを制御するために変更したこと
私は、システムがステップリストから自身の役割を推論すると想定するのをやめた。そして、「あなたはオーケストレーターです。実装は行わないでください」という直接的な記述を追加した。この指示が定着するまでに5回の修正メッセージを要したが、その後、エージェントは境界を遵守するようになった。
また、コンテキスト取得のロジックも強化した。誤ったツールが登場した際、それをハルシネーション（幻覚）としてではなく、取得パイプラインのバグとして扱い、正しいバージョンを見逃すことが不可能なように、SDKの詳細を供給するプロンプトを書き換えた。
AIを活用した開発における実践的な教訓
- 自身のメッセージ数をカウントする。 承認されたPRの数が多いことは、プロセスが壊れていることを隠してしまう可能性がある。修正指示の回数は、制御の仕組みのどこに漏れがあるかを示す先行指標となる。
- 役割を明示的に述べる。 エージェントはチェックリストからアイデンティティを推論することはない。彼らが何者であり、何ができるのかについて、明確に固定された指示が必要である。
- ツールの選択ミスをエンジニアリングのバグとして扱う。 エージェントが指定されたSDKを無視する場合、その責任はモデルの「知識」ではなく、コンテキストの配信メカニズムにある。
- ミスを再利用可能なスキルに変換する。 私はエージェント自身のミスからバリデーション（検証）ルーチンを生成させ、失敗を将来のガードレールへと変えた。