SOPとは？
SOP（Standard Operating Procedure）は標準作業手順書のことです。工程をいくつのステップに分けるか、各ステップで何をどうするか、どうやって確認するか。繰り返し実行でき、チェックでき、検収できる具体的なステップに分解したものです。
うちの上司の言葉で言えば、ラーメン一杯です。麺が何グラム、水が何ミリリットル、塩が何グラム、ネギが何本。たぶん日本のラーメンのことを言っていたのだと思います。私が作るなら、麺は適量、油は少々、水はほどほど、ネギはお好みで、といったところです。
ゲートとは？
これは説明するまでもないでしょう。子どもの頃、家では「六時までに帰ってきなさい」と言われました。もちろん十一時すぎに帰る選択もできましたが、家に帰らないわけにはいきません。門限はそこにあるのです。帰宅した瞬間に発動します。男子シングルス、女子シングルス、あるいは混合ダブルス。
本文はここまでです。
前回の記事では、マルチAgentの三体対抗（三者対戦）と、コードスタイルの取り決めについて書きました。でも、三者で戦わせれば解決するのでしょうか。正直、足りません。
ドキュメントはAgentが書き、実験はAgentがやり、報告もAgentがします。制限をかけなければ、Agentは何でも自由に書き出します。私が作るラーメンと同じで、美味しいか不味いかはランダムです。
作業中に、かなり深刻な問題がいくつか見つかりました。
- promptやskillで縛っても、Agentはしばしば許可されていないことをしたり、文脈を忘れて抜け漏れを出したりします。出来がどうか、終わったのか終わっていないのか、私のラーメンと同じで「だいたい」です。だから品質は、私の集中力と責任感に完全に左右されます。集中力も責任感も波があるので、高いときと低いときで結果が違うのは当然です。
- Agentはよく考えすぎます。無限に考え込んで完璧な答えを探そうとします。特に明確な目標のない発散的な問いでは、しょっちゅう長考に入ります。囲碁と同じで、私の腕はあなたに劣るかもしれませんが、年寄りを疲れさせる作戦は使えます。残念ながら、シリコン生命体の前では私が年寄りです。四十分の長考なら耐えられます。四十分の長考が三回続くと、もう無理です。
- AI技術の急速な進歩のおかげで、subagentが自分の子分を送り出せるようになりました。トークンの爆発はさておき、子分の子分の子分は私にとって死角です。その思考過程は調べようと思えば調べられますが、もう私の管理の範囲を超えています。私の体力には限りがあるので、子分の子分の子分は私の子分ではない、という状況になります。
- 主Agentは調整役で、コードやドキュメントを書く仕事は任せたくありません。対抗する三者のsubagentは、終わるまで結論が安定しないので、当然メインのディレクトリには書き込ませられません。そこで、主Agentが呼び出すsubagentをもっと設計する必要があります。コードを書くもの、レビューするもの。そして、書くものとレビューするものは一緒にいてはいけません。
こうなったら仕方がありません。プロジェクトを進めるために、少し作り替えましょう。
第一 SOPと職責の分離（問題4への対策）
Agentのオーケストレーションを完全にパイプライン化します。検索 -> 調査 -> 実装 -> セルフチェック -> 知識の腐敗 -> ゲート。
各ノードに1つずつsubagentの定義を置きます（.claude/agents/）。descriptionにはどれも「主agentが名指しで呼んだときだけ使う……自動で呼び出さない」と書き、必要な材料は required-inputs に書きます。以下は各ノードの定義の抜粋です（原文は中国語で、descriptionは訳してあります）。
検索：検索agentはネットに出てもよく、資料を持ち帰って指定のディレクトリに置きます。
---
name: prior-art
description: 調査員。他のファイルシステムのソースとドキュメントをその場で調べ、出典付きの事実だけを渡し、論証は渡さない。主agentが名指しで呼び、調べる問いを与えたときだけ使う。自動で呼び出さない。
tools: Read, Bash, WebFetch, WebSearch
model: sonnet
effort: high
omitClaudeMd: true
required-inputs: 草稿ディレクトリ, レポート
---
調査：三者対抗を起動し、適切な方式を見つけます。
---
name: experiment-designer
description: 実験設計員。実験番号を取り、実行前の登録（アーム、対照、判定基準、失敗条項）を、コードや成果物が存在する前に書く。主agentが名指しで呼び、答えるべき問いと被試験条項を与えたときだけ使う。自動で呼び出さない。
tools: Read, Bash
model: opus
effort: high
omitClaudeMd: true
required-inputs: 草稿ディレクトリ, 被試験条項, 分岐リスト|問いリスト|再実行
---
---
name: three-way-attack
description: 三者論証のクラウド側の攻め手。主agentが名指しで呼び、今回の背景資料、攻撃面、前の回の判定を与えたときだけ使う。自動で呼び出さない。
tools: Read, Bash
model: opus
effort: high
omitClaudeMd: true
required-inputs: 閲覧禁止リスト, 草稿ディレクトリ, 背景資料, 攻撃面
---
実装：コードを書き始めます。
---
name: implementation-writer
description: 実装員。マイルストーンの一歩、並行ラインの一本、または主agentがまとめた一群（複数件を閉じてもよい）について crates/ を変更し、テストを付け、そのテストが赤になることを証明する。主agentが名指しで呼び、ステップ番号と関わる条項を与えたときだけ使う。自動で呼び出さない。
tools: Read, Edit, Write, Bash
model: opus
effort: high
omitClaudeMd: true
required-inputs: 草稿ディレクトリ, レポート, 条項, 触る crates のファイル
---
---
name: tooling-writer
description: ツール実装員。ゲートのステージ、フック、調査スクリプト、ウォッチドッグを変更する。または判定に従ってagent定義、共通の制約、プロジェクトルールを変更する。変更のたびに、まず赤になるはずの入力を作る。主agentが名指しで呼び、どの項目を閉じるかと出口を与えたときだけ使う。自動で呼び出さない。
tools: Read, Edit, Write, Bash
model: sonnet
effort: high
omitClaudeMd: true
required-inputs: 草稿ディレクトリ, レポート, 出口, 変更するファイル
---
セルフチェック：三者で包囲して、コードの品質をレビューします。
---
name: investigator
description: 調査員。テストやゲートの結果が期待と合わないとき、現象を再現し、二分探索でファイルと行まで絞り込み、最小の再現手順と反証条件を渡す。派遣時に「見つけたら直せ」と書かれ、条項に直し方が明記されていれば、そのまま直して赤を証明する。条項に書かれていなければ止まって主agentに返す。主agentが名指しで呼び、現象の原文と答えるべき問いを与えたときだけ使う。自動で呼び出さない。
tools: Read, Edit, Bash
model: opus
effort: high
omitClaudeMd: true
required-inputs: 現象, 草稿ディレクトリ, レポート
---
知識の腐敗：プロジェクト全体で、変更点が一貫しているか監査します。
---
name: sweep
description: 再走査員。数値を撤回した後、書式の定数を変えた後、新しい判定基準を立てた後、あるいは一つの段階の作業が終わった後に、リポジトリ全体から、まだ古い値を引いている箇所、新しい基準の管轄に入るべき箇所、この段階で嘘になった箇所を探し、分類して一覧を渡す。主agentが名指しで呼び、古い値とそれがどの量かを（または段階の変更範囲と成し遂げたことを）与えたときだけ使う。自動で呼び出さない。
tools: Read, Bash
model: sonnet
effort: high
omitClaudeMd: true
required-inputs: 草稿ディレクトリ, レポート
---
ゲート：タスクの最後にエラー台帳を機械的に検査し、そのあと主agentが問題を分析して直します。
各ノードは専任が専門の仕事をします。主Agentはタスクの分解と割り振りだけを行い、子Agentはそれぞれの持ち場を守ります。さらに「知識の腐敗」を扱う仕組みも別に入れ、期限切れの文脈を定期的に掃除して、パイプラインが過負荷にならないようにします。
第二 能力の制限（問題2・3への対策）
---
tools: Read, Bash
model: sonnet
effort: high
omitClaudeMd: true
---
曖昧さとグレーゾーンをなくします。主agentは私のタスクが何なのかをはっきりさせ、タスクに応じて子agentに仕事を割り振ります。
Depth=1。子Agentに子分を持たせません。「死角」の問題を根絶します。（環境変数 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 に対応します。各ロールのtoolsにもそもそもAgentは入っていません。）
omitClaudeMd=true。知りすぎてはいけません。知らなくていい文脈は断固として渡さず、連想が広がるのを防ぎます。
tools：ツールは絞り込み、厳しく制限します。上の各ロールが持つのは、Read, Edit, Write, Bash, WebFetch, WebSearch の部分集合で、ネットに出られるのは調査員だけです。Bashは全員にあるので、鍵はtoolsにはかけず、フックにかけます。危険な書き方は実行前に拒否され、Agentの自覚には頼りません。
effort: high。簡単な問題を、必要以上の能力で解かせてはいけません。
第三 ゲート（張本兄妹、出番だ！）（問題1・2への対策）
赤緑の二重証明：コードにはすべてテストが必要です。しかも、テストが「緑（通過）」になるだけでは足りません。そのテストが間違いを捕まえられる（赤になる）ことを私に証明し、赤と緑の証拠を一緒に提出させます。赤の証拠もAgent自身の申告には頼りません。ゲートがテスト対象のコードを一か所壊し、そのテストが本当に赤になることを確認します。
出所の強い紐づけ：コードの実装は、意思決定と実験記録に紐づいていなければなりません。過去の意思決定の裏付けがない「幽霊コード」は一切認めず、ゲートはコメントに経緯がきちんと書かれているかを厳しく調べます。
監視点の網羅：コードに大量のプローブを埋め込み、通過するたびにデータの状態を厳しく調べて、神経網を張ります。たとえば、コードがシミュレーション環境で二十万の異なる点を通り抜けたとしても、データフローが完全で、違反がないことを証明しなければなりません。まだ組み込めていない検証は、正直に未実装と記し、通ったふりをすることは許しません。
テキストと書式のゲート：知識ベースとドキュメントを一件ずつ突き合わせます。決められたJSON/Markdownの形式どおりに書かれているか。余計なアドリブはないか。記録は合格か。日付一つでも、標準の日付で書かなければなりません。
定時パトロール（Timeout機構）：主Agentが定期実行スクリプトを仕掛け、送り出した子Agentを常に監視します。コンテキストの大きさが上限を超えたり、実行時間が超過したりしたら、すぐに進捗を確認し、期待からずれていれば呼び戻します。
第四 汚れ書き込みの防止（問題4への対策）
これは今の成熟したAgentフレームワークの多くがすでに意識しています。たとえば、worktreeとルート直下のワークスペースで物理的に分離するなどで、ゼロから自前で守る必要はありません。
ただ、ここで私はもう一つ鍵を足しました。専用の「コード実装員」Agentのノードを通らないかぎり、どんなコードもcratesには絶対に書き込ませません。
コードを書くものとレビューするものは、物理的に分離しなければなりません。二重署名がなければ、メインのリポジトリの敷居はまたげません。
これで、動かせるはずです。
Tokenman、出撃！