コーディングエージェントの品質が低下するのは、モデルの能力が落ちたからではなく、エージェントが何を読み、何を行い、変更をどのようにレビューするかを管理する明確な運用システムがプロジェクトに欠けているためであることが多い。作業が数週間にわたり、数千件の変更が加えられると、こうした手順を強制しない限り、エージェントは同じファイルを再発見したり、以前の決定と矛盾したり、テストコマンドを推測したり、テストの記述をやめたりする可能性がある。
「LLMシステムを本番環境で運用する」シリーズの第6部で、Stack Overflow Blogは、モデルの周囲に組織化のレイヤーを構築することを提案している。これには、簡潔なプロジェクト憲章、自律性の境界、複数レベルのコンテキスト、永続メモリ、レビュー委員会、変更のたびに実行されるフックが含まれる。同じリポジトリで複数のエージェントを稼働させる場合は、ファイルの所有権マップ、プロンプトのログ、共有された決定の記録も追加する。
問題はモデルだけでなく運用ベルトにある
記事では、エージェントを、モデルに指示、ツール、コンテキストポリシー、フック、分離、サブエージェント、監視メカニズムを加えたものと定義している。一般的な結果としてTerminal-Bench 2.0の結果を引用し、LangChainが運用ベルトだけを変更することで、あるエージェントを上位30位圏外から上位5位へ引き上げ、モデルを同じまま、スコアを52.8%から66.5%へ、13.7ポイント上昇させたとしている。
実務上の意味は、不完全なツール、曖昧なルール、過密なコンテキストが、最も対処しやすい失敗原因になり得るということだ。モデルとは異なり、開発チームはこのレイヤーを変更し、自らのリポジトリに合わせて調整できる。
統制された単一エージェントの6要素
- プロジェクト憲章: CLAUDE.mdやAGENTS.mdのようなファイルで、計画、文書化、実装、テスト、レビュー、コミットという作業サイクルを定める。品質基準やベンダーパッケージの利用制限も含めるべきだが、各セッションで読まれるため、短く保つ必要がある。
- 自律性の境界: エージェントには、読み取り、編集、テスト、コミットの作成といった可逆的な操作を許可する一方、プッシュ、デプロイ、インフラストラクチャー変更の適用には承認を必要とする。npm:*のような広範なルールが意図せずデプロイを許可しないよう、コマンドのマッチング意味論を検証しなければならない。
- 複数レベルのコンテキスト:ルートのCONTEXT.mdには、プロジェクトの構成、実行方法、テスト方法を記載し、各モジュールのファイルには、その責務、ファイル、依存関係を説明する。DECISIONS.mdには、決定事項、その理由、却下した代替案を記録する。古くなったコンテキストは、変更そのものの中で修正すべきエラーである。
- 永続メモリ:資料では、事実ごとに分離したメモリファイル、簡潔なインデックス、モジュールや決定事項を「依存する」「置き換える」などの関係で結び付けるgraph.jsonlファイルを提案している。
- 複数の観点によるレビュー委員会:サブエージェントが、プロダクト、エンジニアリング、インフラストラクチャー、セキュリティ、テストの観点から変更をレビューする。変更を阻止するのは、ブロッカーまたは高い確信度を伴う重大な問題だけにする。
- 変更後フック: PostToolUseはEdit、Write、MultiEditの各操作の後に実行され、コンテキスト、メモリ、決定ログを同じ変更内で更新するよう促すチェックリストを出力する。ファイルを黙って書き換えることはしない。
エージェントの大規模運用
複数のエージェントが同じリポジトリで動作すると、同じファイルを変更したり、他のエージェントの決定を取り消したりするという新たな問題が生じる。記事は、エージェント同士の直接的な会話に依存するのではなく、監査可能な共有の書き込み状態に依存することを提案している。これには、パスの所有権マップ、CLAIMおよびRELEASEのログ、進捗ログ、タスクごとの独立ブランチ、人間によるマージが含まれる。
これらの要求は実際のロックではない。2つのエージェントが同じ状態を読み、同じパスを同時に要求する可能性があるためだ。実際の分離が必要な場合、記事は、一意な名前を持つGitブランチや、オーケストレーションストアにおける条件付き書き込みのようなアトミックな仕組みを推奨している。
なぜこのアプローチが重要なのか
ここでの本当の変化は、エージェントが関数を書ける能力から、周囲のシステムがエージェントを長期にわたって方向付け、レビュー可能な状態に保つ能力へと焦点を移すことにある。決定ログは、単なる文書ではなく、契約上の役割を果たす。古い決定を変更するのではなく、理由と却下した代替案を明示した新しい決定を追加し、古い決定を置き換える。これにより設計の履歴が可視化され、特定のインポートを禁止するなどの自動チェックと結び付けられる。
このアプローチは、出力の正しさを保証するものではなく、組織化のための指針にとどまる。また記事は、ファイルに基づく要求は同時衝突が発生した場合には助言的なものにすぎず、マージ、プッシュ、デプロイの際には人間によるレビューが引き続き制御点となることを認めている。資料の結論は、より賢いモデルを待つよりも、モデルを封じ込め、監査可能な成果物を構築することのほうが、長期的な作業の信頼性に大きな影響を与え得るということだ。