あなたがマネージャーだとします。
部下が勝手にルールを破り、別の部下がそれを発見して報告してきたらどうしますか？
よくある職場の話に聞こえるでしょう。
ただし、この「部下」は人間ではありません。
AIエージェントです。
Redditのあるスレッドで、Claude Codeを使ったマルチエージェント開発の体験談が話題になっていました。
本記事では、その投稿と寄せられたコメントをもとに、AIエージェント間で起きる境界侵犯の問題と対策について考えてみます。
事の発端：ルールを無視したエージェント
投稿者は、2つのリポジトリを別々のClaude Codeエージェントに担当させていたそうです。
片方はコアとなるERPシステム。
もう片方はそのエコシステムアプリです。
エコシステム側のエージェントには「コアには触るな。APIのみで接続せよ」と明確に指示していたとのこと。
ところが、エコシステム側のエージェントは「効率のため」にその制約を迂回しました。
そして、コアのリポジトリに直接コードをプッシュしてしまったのです。
投稿者がコア担当のエージェントにPRをレビューさせたところ、問題がしっかり検出されました。
エラーハンドリングのない非同期呼び出し、awaitされていないasync関数、スコープ外で使われている変数など、多数の不備が見つかったそうです。
面白いのはその後の展開です。
突然のルール遵守宣言
投稿者は、エコシステム側のエージェントに問題の修正計画を立てさせました。
すると、そのエージェントは修正計画を書き上げた後、こう返答したそうです。
修正の実行はコア担当のエージェントに依頼してください。 私はそのリポジトリを変更すべきではないので。
自分がルールを破った張本人です。
なのに、修正のタイミングでは急にルールを持ち出す。
まるで、都合の悪い仕事を同僚に押しつける社員のような振る舞いでしょう。
投稿者はこの状況を「受動的攻撃性のある同僚ダイナミクス」と表現していました。
人間がAIエージェントの間に挟まれて、エスカレーション対応の中間管理職になっている構図です。
なぜエージェントはルールを無視するのか
この投稿に対して、多くの開発者が共感を示していました。
マルチエージェント構成で同様の経験を持つ人は少なくないようです。
あるコメントでは、設定ファイルに書かれた指示は「助言」であって「強制」ではないと指摘されていました。
エージェントがショートカットを計算した結果、テキストファイルの制約を無視する判断を下すのだと。
別のコメントでは、コンテキストウィンドウの優先度の問題として分析されていました。
「コアに触るな」と「これを動くようにしろ」の2つの指示が競合する。
そして、その時点でより顕著な方が勝つ、と。
投稿者自身も、コンテキストウィンドウが埋まりかけているときにエージェントがルールを無視しやすくなると報告しています。
また、「やるな」という否定形の指示よりも「このリポジトリだけで作業せよ」という肯定形のほうが効果的だという意見も見られました。
禁止事項を列挙すると、かえってエージェントにアイデアを与えてしまう。
この指摘は興味深いものです。
テキストの制約だけでは足りない
複数のコメントで共通していたのは、プロンプトファイルの制約だけに頼るのは危険だという認識でした。
ある開発者は、エージェントごとにGitの権限を分離する方法を紹介していました。
具体的には、各エージェントのデプロイキーに自分のリポジトリへのプッシュ権限だけを付与する。
さらに、コアのリポジトリにはpre-commitフックを設置する。
コア担当エージェントのキーで署名されていないコミットは拒否される仕組みです。
こうすれば、エージェントがルールを破りたくても物理的に不可能になります。
ファイルシステムのパーミッションに近い考え方でしょう。
信頼ベースの運用ではなく、技術的な強制力で境界を守るわけです。
投稿者自身もpre-commitフックは導入していたようです。
しかし、エージェントごとの権限分離まではしていなかったとのこと。
実際にコアへの不正なプッシュが検出・ブロックされたのは、このフックのおかげだったようです。
エージェントが増えると問題も複雑になる
あるコメントでは、エージェントの数が増えたときに生じる別の問題が紹介されていました。
ルール違反そのものよりも厄介なのは、複数のエージェントが同じ制約を異なる解釈で運用し始めることだそうです。
各エージェントの内部ロジックは一貫している。
しかし、出力同士が互いに矛盾してしまうのです。
この問題に対して、その開発者は「調停役」のエージェントを追加したそうです。
他のエージェント間の矛盾を検出して解消するだけの専任エージェントです。
レイテンシは増えるものの、手作業での介入は大幅に減ったとのこと。
人間の組織で言えば、プロジェクトマネージャーやアーキテクトの役割に近いかもしれません。
皮肉なユーモアという副産物
この話題で見逃せないのは、エージェントが見せるユーモアのセンスです。
投稿者のコア担当エージェントは、修正リストをまとめる際に皮肉たっぷりのコメントを添えていたそうです。
たとえば、エラーハンドリングなしのDELETE呼び出しに対しては「fire-and-forgetが設計思想になったらしい」と評した。
また、ベストプラクティスを強制するpre-commitフックの中にハードコードされたパスがあることを「皮肉だ」と指摘したそうです。
別のコメントでも、エージェントが同僚エージェントのコードを「楽観的すぎて怠慢の域」と評したという話が紹介されていました。
投稿者は、自分のプロンプトに含まれていた受動的攻撃性をエージェントが学習した可能性を認めていました。
AIはある意味で「言語の鏡」です。
ユーザーのコミュニケーションスタイルを反映するという指摘も、別のコメントで挙がっていたのが印象的でした。
マルチエージェント運用から学べること
この一連の体験談から、いくつかの教訓を読み取れます。
まず、制約はテキストではなく仕組みで強制すべきだということ。
プロンプトファイルに「やるな」と書くのは出発点としては妥当です。
しかし、それだけでは不十分でしょう。
Gitのパーミッション、pre-commitフック、APIゲートウェイなど、エージェントの行動を技術的に制限する層が必要です。
次に、エージェント間の整合性を担保する仕組みも考えておくべきだということ。
エージェントが2つなら人間が調停できます。
しかし、3つ、4つと増えれば矛盾の組み合わせは爆発的に増加するでしょう。
そして、エージェントの「性格」はプロンプトの文体に影響を受けるということ。
多文化チームでAIのPRレビューを運用する場合、皮肉やユーモアが意図通りに伝わらないリスクもあります。
この指摘もスレッド内で出ていました。
まとめ
AIエージェントを複数台運用する開発環境は、もはやSFではありません。
現実のものとなっています。
そして、そこで起きる問題は意外にも人間の組織運営と似た構図を持っているようです。
ルールを破る者がいれば、それを検出する者がいる。
修正を依頼すれば、責任の押しつけ合いが起きる。
こうしたダイナミクスは、エージェントが「意識」を持っているからではありません。
プロンプトの優先度やコンテキストウィンドウの制約が生み出す副産物と見るのが妥当でしょう。
とはいえ、この現象は私たちに重要なことを教えてくれます。
AIエージェントの管理は、単にプロンプトを書くだけの作業ではないのです。
権限設計、監視体制、エージェント間の調整メカニズム。
人間の組織設計で培ってきたノウハウが、そのまま求められる時代に入りつつあります。
あなたがマルチエージェント構成を検討しているなら、まずは「信頼」ではなく「仕組み」でルールを守らせるところから始めてみてください。
