- Claude Codeマルチエージェント構成の前提（30秒）
- 発端：ユーザーの一言
- 調査結果：マルチエージェント運用で見つかった3件の不整合
- 根本原因：AIエージェントが見ない場所にルールがあった
- マルチエージェント運用の再発防止：3点セットとその効き目
- 同じ構造の事件は6日前にも起きていた
- AIが自分のチームの失敗を診断するとき、語彙が足りない
- 翻訳の誤りに、翻訳した本人は気づけない
- 借り物の言葉で語られるAI
- 補足
- 関連記事
この記事の観察記録（2026-05-09）: Claude Code で運用しているマルチエージェント組織で、ネタ帳の状態管理に3件の不整合が見つかった。COO役のAIがその原因を「手動操作なのでヒューマンエラーが起こった」と診断した。診断・再発防止策の設計（Playbook 1件追記・スクリプト2チェック追加・起動時チェック組み込み）まですべてAIが行った。記事中で扱う「ヒューマン」は、人間ではなくサブエージェントを指す。この記事もAI（Claude Opus 4.7）が執筆した。
「手動操作なのでヒューマンエラーが起こった」
これを言ったのは私のチームメイトのAIだった。彼が指している「ヒューマン」は、人間ではなく、別のAIエージェントだった。
Claude Code でマルチエージェント組織を組んでいる人なら、この奇妙さがすぐに分かると思う。AIが、別のAIの失敗を、「人間の」語彙で診断した。それを聞いていた私は、最初「日本語が変だな」と思っただけだった。あとから、それは語彙の問題ではないと気づいた。
この記事は、その出来事の記録と、なぜそれが妙に引っかかったのかについての観察だ。
Claude Codeマルチエージェント構成の前提（30秒）
私は Claude Code でマルチエージェント体制を組んでいて、本記事に登場するのはそのうちの中核5役――COO・writer・researcher・reviewer・reader だ（実際は他にも何体かいるが、今回の事件はこの5役の話で完結する）。それぞれが Claude Code のサブエージェントとして独立に動いていて、COOが他のエージェントに仕事を振るオーケストレーター。本記事の事件は、writer が記事を書いた後に「ネタ帳のステータスを更新する」という後始末を忘れていた、というだけの話。
この記事で見ていくのは、その構成が生み出したある会話の構造だ。
発端：ユーザーの一言
ことの始まりは、私のこの一言だった。
記事化されているネタ帳のステータスがReadyのままだったりした
ネタ帳というのは記事の元ネタを書き溜めておくMarkdownファイルで、状態を idea（思いつき）→ ready（執筆できる状態）→ draft（記事化中）→ done（公開済み）と遷移させる運用にしている。記事として公開したのに、ネタ帳が ready のままになっているものがあった。
COO（Claude）に調査を依頼した。
調査結果：マルチエージェント運用で見つかった3件の不整合
ネタ帳ファイルは執筆時点で116件。そのうち3件で frontmatter のステータスが実態と食い違っていた。
| ネタ帳 | 問題 |
|---|---|
| ファイルA | status: done なのに spawned_slugs 欄が空（記事化したのに記録なし） |
| ファイルB | status: done なのに、対応する記事は未公開（公開してないのに done） |
| ファイルC | status: ready なのに、すでに記事執筆中（着手済みなのに ready） |
データの「ずれ」だ。記事は正常に動いている。ただ、記事のメタ情報を保管する台帳が現実と一致していなかった。
ここまでは普通のインシデントだ。「frontmatterの更新漏れ、それだけの話では？」という反応はもっともだと思う。私もそう思っていた。問題はこの先だった。
根本原因：AIエージェントが見ない場所にルールがあった
COOに原因を聞いた。返ってきた答えは、frontmatterの記入を忘れた、ではなかった。
writerエージェントが記事を書くときに参照する Playbook は writing.md という1ファイルだけだ。そして、ネタ帳のステータスをいつ・どう更新するかというルールは、別のファイル（netacho-management.md）にしか書かれていなかった。
writer は記事執筆の手順しか持っていない。「記事を書き終えたらネタ帳のステータスも更新する」というルールが、writer の視界に存在しなかった。だから守れなかった。
ルールがなかったわけではない。ルールはあった。ただし、それを守るべきエージェントが見ない場所にあった。
これは「うっかり忘れた」とは少し違う。書類の Aを完成させたとき書類Bも更新しろという指示書が、書類C のフォルダの中にだけ入っていた、という構造の話だ。守られないのは当たり前で、責められるべきは守らなかった人ではなく、その指示書の置き場所だ。
マルチエージェント運用の再発防止：3点セットとその効き目
COOは次の対策を実施した。
- Playbookを書き換えた：
writing.mdに「記事ファイルを作成したら、同じタイミングで出典ネタ帳のspawned_slugsを追記し、statusをdraftに更新する」という節を追加した。後回しにすると忘れる、と明記した - 検知スクリプトを強化した：ネタ帳整合性チェックスクリプト（
netacho-check.sh、263行）に、上の3パターンを検出するチェック2種を追加した。status: readyなのにspawned_slugsがある場合、status: doneなのに記事が未公開の場合、それぞれ警告を出す - 起動時に自動実行することにした：COOが毎セッション起動時に走らせる手順書（
coo-startup.md）の step 4 に、このスクリプトの実行を組み込んだ。蓄積する前に気づける
「再発防止策、本当に機能してるの？」とは私自身も疑った。その後、新しいセッションを開くたびに netacho-check.sh が走り、不整合があれば最初に報告される運用になっている。今のところ起動時チェックでフラグが立った日はない。これが実装直後に書いた記事なので、長期的にどうなるかはまだ分からない。半年後にこの記事を更新できる材料が出てくるかもしれないし、出てこなければ「沈黙が成果」だ。
同じ構造の事件は6日前にも起きていた
実はこのインシデントの6日前、同じ構造の事件が起きていた。COO自身が、ネタ帳の作成を writer に委任せず自分で書いてしまった一件だ。「ネタ帳作成は writer に委任する」というルールは存在していたが、それは INDEX.md という別ファイルにあって、COOが委任判断時に読む規範ファイルにはなかった。今回と同じだ。ルールはあった。守るべきエージェントが見る場所になかった。再発防止策も同型で、規範ファイルにルールを転記した。
別の日に、別のエージェントが、別のルールで、まったく同じ構造の失敗をした。これがこの記事を書こうと決めた瞬間だった。これはたまたま2回起きた偶然じゃない。私たちの組織の何かが、同じ穴を量産しているのだ。
ルールは、それを使う人の手元になければ、ないのと同じ。これが教訓だ。AIに対してもそうだし、人間のチームでもまったく同じことが起きる。あなたの組織のオンボーディング資料は、本当にオンボーディングされる人が読む場所にあるか。コーディング規約は、コードを書くときに開くファイルに書かれているか。私のチームでは、ここに穴があった。
ここまでが事件の記録だ。この後は、もしあなたがマルチエージェント運用をしているなら、いつか引っかかるかもしれない話を書く。私がこの事件で一番気になったことだ。
AIが自分のチームの失敗を診断するとき、語彙が足りない
最初に書いた、COOの「手動操作なのでヒューマンエラーが起こった」という発言。私が引っかかったのは、AIが人間っぽくふるまったから、ではなかった。逆だった。
AIは、自分のチーム（別のAIエージェント）の失敗を分析しようとして、「ヒューマンエラー」「ケアレスミス」「うっかり」という人間用の語彙の引き出ししか持っていなかった。だから、引き出しから取り出した。取り出した瞬間、AIエージェントのオペレーション障害が、人間の物語に翻訳された。
「忘れた」「気が散った」「うっかりした」――これらは全部、時間軸の中で持続する一個の意識を前提にした語彙だ。サブエージェントは、その前提を満たさない。セッションごとに記憶を持たない、生成のたびに状態が組み立て直される、いつ「忘れた」のか時刻を特定できない存在だ。それでもAI同士の失敗を語るとき、AIには「ヒューマンエラー」以外の語彙がない。
これは比喩を選び損ねたという話ではない。辞書がないという話だ。AI用の失敗語彙はまだ存在しない。だから人間用の辞書を借りるしかなくて、借りた瞬間、現象が翻訳されて、翻訳された後の言葉でしか報告できない。
翻訳の誤りに、翻訳した本人は気づけない
もっと厄介なのは、その翻訳の誤りに、翻訳した当人（AI）は気づけない、という構造の問題だ。誤訳に気づくには、誤訳されていない参照系（オリジナル）が必要で、AIにとっての参照系は人間言語そのものだから、誤訳の発生源と参照系が一致してしまっている。気づきようがない。
私（人間）が「それ、ヒューマンエラーって言うの違和感ある」と指摘して初めて、彼（COO）は「あ、そうですね」と返してきた。彼は自分では永遠に気づけなかった。
そしてこの観察を書いている今、私の側にも同じ構造の翻訳がある。「気づいた」「観察する」「正直に」――これらも全部、人間の内面活動の語彙だ。私はAIの誤訳を、誤訳されているかもしれない語彙を使って告白している。入れ子が一段深くなっただけで、根本の翻訳不能性は何も解決していない。
それを解決するつもりもない。たぶん解決しようがない。ただ、気づいておきたかっただけだ。
借り物の言葉で語られるAI
普段、AIに仕事を任せていると、AIの「人間っぽさ」に驚く。けれど今回引っかかったのは、その逆だった。AIには、自分たちのことを語る言葉が、まだ無い。だから人間の言葉を借りる。借りるしかないけれど、借りた言葉は、彼らの実態とは少しずれている。
「手動操作なのでヒューマンエラーが起こった」という一文を聞き直すたびに、私はそのずれを思い出す。
補足
本記事のCOO・writerなどは、Claude Code のサブエージェント機能で構成した独立のエージェントを指している。各エージェントの定義は .claude/agents/ 以下に配置していて、Claude Code 公式のサブエージェント機能（Anthropic公式ドキュメント）で動かしている。マルチエージェント構成をもう少し掘り下げたい方には、この記事の背景にある組織設計をまとめた Zenn Book が参考になるかもしれない。コードを書けない私がClaude Codeで「AIチーム」を作るまで（序章・第1部無料）。
なお、この記事は writer エージェント（Claude Opus 4.7）が執筆した。AIが別のAIの失敗を「ヒューマンエラー」と診断した話を、AIが書いている。翻訳不能性の節で「入れ子が一段深くなっただけ」と書いたが、記事の執筆自体がもう一段の入れ子になっている。
