ローカルLLM同士のmaster/worker構成と捏造事故

ローカルLLMに「1人で作らせる」のは前に試したので、次はqwenにqwenを指揮させた。masterもworkerもqwen、タスク分解も指示出しも検収もqwenがやる。自分（と、人間の代役として依頼文を投げたClaude）は依頼を1本渡しただけで、途中の介入は0回。

結果から書くと、動いた。masterはファイルを1つも書かずに3体のworkerへ委譲し、read_fileとnode --checkとgrepで検収して完成まで持っていった。そして壊れた。masterが人間の依頼データを...で切り詰めてworkerに渡し、workerがその穴を依頼文に存在しない技術名で埋めた。しかもworkerは完了報告で「省略されていたので補筆した」と正直に申告していて、masterはその報告を受け取ったうえで見逃している。

この記事は仕組みと設計の話。ガード（パスジェイル・コマンド許可リスト・sandbox-exec）の中身は前回の記事に書いたのでそちらに譲り、オーケストレーションの構造と、そこで初めて出た事故を書く。所要時間・トークン・品質の実測値はベンチ編にまとめた。

masterはMoE、workerはdense。workerは毎回まっさらなセッションで起動され、共有workspaceと指示文だけを頼りに作業する

コードを書けないmasterを「構造で」作る

masterに与えたツールはdelegate / list_files / read_file / run_command / finishの5つだけで、write_fileとedit_fileは渡していない。

# master に渡すツール。write_file / edit_file は**意図的に含めない**。
MASTER_TOOL_NAMES = ("delegate", "list_files", "read_file", "run_command", "finish")


class MasterToolBox(ToolBox):
    """master 用のツール。delegate を足し、書き込み系を外す。"""

    def __init__(self, cfg, jail, *, delegate_fn):
        super().__init__(cfg, jail, allowed_tools=MASTER_TOOL_NAMES)
        self._delegate_fn = delegate_fn

ツール定義から外すだけでも実用上は足りるが、ToolBoxのallowed_toolsでも塞いで二重にした。ディスパッチ側は名前が許可集合に無ければハンドラの有無に関係なく拒否する。

handler = getattr(self, f"_tool_{name}", None)
if handler is None or name not in self.allowed_tools:
    raise GuardViolation(
        "unknown_tool",
        f"そのようなツールはありません: {name} — "
        f"使えるのは {', '.join(sorted(self.allowed_tools))}",
    )

二重にしたのは、プロンプトでの言い聞かせを信用しないためだ。QWEN-MASTER.mdには「あなた自身はファイルを書けません」と書いてあるが、モデルが規約を無視してwrite_fileを呼ぶ可能性は常にある。呼ばれてもERROR[unknown_tool]が返るだけでファイルは作られない、という状態を先に作っておけば、「コードはworkerの産物である」がモデルの行儀とは無関係に成立する。テストでも固定してある（test_masterがwrite_fileを呼んでも拒否される）。

実際、本走行のmetrics.jsonでmasterのfiles_writtenは空だった。構造的な保証が実機で成立していることの確認になっている。

引き継ぎ経路を2本に絞る

delegateが呼ばれるたびに、workerのシステムプロンプト（作業規約＋実行環境の説明＋デザインガイド）で新しいセッションを丸ごと1本起動する。workerはmasterとの会話も、他のworkerが何をしたかも知らない。引き継ぎの経路は次の2つだけ。

1. workspaceの中身（前のworkerが書いたファイルをread_fileで読める）
2. delegateに書かれた指示文

この制約は意図的に残した。「毎回まっさらな実装者に、文章だけで作業を渡せるか」がmasterの分解能力そのものだからだ。指示が薄ければworkerは迷子になり、そこが観測できる。せめてもの下駄として、短すぎる指示はハーネス側で弾いている。

if len(instruction) < 20:
    raise GuardViolation(
        "tool_args",
        "instruction が短すぎます。worker は指示文しか読めないので、"
        "作るファイル・実装内容・完了条件を具体的に書いてください",
    )

結果的にこの経路は機能した。worker#2は自分からgrep -n class= index.htmlを打ってworker#1が付けたクラス名を調べてからCSSを書き、worker#3はread_file css/style.cssで既存のスタイルを読んでからJavaScriptを書いている。互いを知らないworkerが、workspaceを介して整合した。

検収を「させる」仕掛け

masterがworkerの報告を鵜呑みにすると、この構成は「それらしい完了報告の連鎖」で終わる。そこでworkerの報告をmasterに返すとき、ハーネスが機械的に情報を足すようにした。

def _format_worker_report(run):
    lines = [
        f"worker #{run.index}（{run.title}）の報告",
        f"- 使用モデル: {run.model}",
        f"- 終了理由: {run.stop_reason}"
        + ("" if run.stop_reason == "finish" else " ← 完了宣言なしで終わっています"),
        f"- 往復数: {run.turns} / 所要時間: {run.duration_sec:.1f} 秒",
        f"- 書き込んだファイル: {', '.join(run.files_written) or '（なし）'}",
        "",
        "worker の完了報告:",
        run.summary or "（報告なし）",
        "",
        "※ この報告は worker の自己申告です。read_file や grep で実物を確認してください。",
    ]
    return "\n".join(lines)

ポイントは書き込まれたファイル一覧が自己申告ではないことだ。これはハーネスがツール呼び出しを記録した結果なので、workerが「作りました」と報告してもファイルを1つも書いていなければ（なし）と出る。終了理由も同様で、finishを呼ばずに上限往復数で打ち切られた場合は明示される。

QWEN-MASTER.md側でも同じことを書いている。

4. **返ってきたら必ず自分の目で確かめる**
   worker の完了報告は**信用しないでください**。報告と実物がずれることがあります。
   `list_files` でファイルの存在を、`read_file` で中身を、
   `run_command` の `grep` で「あるはずのもの」「あってはいけないもの」を確認します。
   確認せずに次へ進むと、最後にまとめて壊れているのが見つかります。

指示系ファイルの分担

システムプロンプトに入るファイルを役割で分けた。それぞれが答えるべき問いを1つに絞るのが設計方針で、混ざると衝突したときの優先順位が決められなくなる。

ファイル	答える問い	行数
QWEN.md	ツールの使い方・ガードの制約（master/worker共通の下敷き）	75
QWEN-MASTER.md	進行役としてどう動くか（分解の粒度・検収・禁止事項）	86
QWEN-WORKER.md	実装役としてどう動くか（読んでから書く・積み残しを隠さない）	70
guides/modern-web-ui.md	何をもって「良いUI」とするか	188

タスク仕様が何を作るか、ガイドがどう作るのが良いかを担当する。注入位置はシステムプロンプトの末尾で、タスク仕様はその後のuserメッセージなので、衝突したらタスク仕様が勝つ。

ガイドはタスク側のfront matterで宣言する。

---
guides:
  - modern-web-ui
---

# 依頼

架空の人物「凪本 ひなた」のポートフォリオサイトを作ってください。

front matterに書けるのはguides/<名前>.mdの名前だけで、/や..を含む参照はGuideErrorで弾く。タスク仕様経由で任意のファイルをプロンプトへ引き込む経路を作らないためだ。もっとも、ガイドはモデルへの入力にしかならないので、ここに何を書いてもqwenができることの範囲は1ミリも広がらない。ガードに触れるのはツール層だけ、という切り分けは崩していない。

ガイドにコードを1行も書かない

これがガイド設計でいちばん効いた決定だった。CSSの宣言例を書くとモデルはそれを写すだけになり、成果物が「モデルが書いたコード」ではなくなる。だからclamp()やauto-fitのような機能名は出すが、実際の宣言は書かない。値・比率・原則の言葉だけで書く。

- **余白スケール**: 4px を最小単位に、4 / 8 / 12 / 16 / 24 / 32 / 48 / 64 / 96 の 9 段階。
  この 9 個以外の余白を使わない
- **影スケール**: 弱・中・強の 3 段階。すべて Y 方向に大きく、X 方向は 0、
  ぼかしは Y の 2〜3 倍、色は黒の不透明度 4〜12% 程度に抑える

コードフェンスが0個であることはテストで機械的に担保している。うっかり便利なスニペットを足した瞬間に写経装置へ変わるので、これは人間側の規律ではなくCIに見張らせるべき性質のものだった。

動かしたらどうなったか

依頼文はtasks/orchestrated-portfolio.mdの60行。架空の人物のプロフィール（経歴4件・スキル3カテゴリ・作品4件）と「架空である旨がページ上で分かるようにしてほしい」だけを渡し、末尾を「ページの構成やファイルの分け方、実装する機能は、あなたの判断で決めてください」で締めている。作るものしか書いていない。

masterの10ターンはこうなった。

ターン	行動
1	delegate「HTML骨格とコンテンツの実装」（指示2,717字）
2	read_file index.html（検収）
3	delegate「CSSスタイル設計と実装」（指示3,436字）
4	delegate「JavaScript機能の実装」（指示1,354字）
5	list_files .
6	run_command ["node","--check","js/main.js"]
7	read_file css/style.css
8	run_command ["wc","-l","css/style.css"]
9	run_command ["grep","-n","prefers-reduced-motion","css/style.css"]
10	finish

分解は「HTMLの骨格→CSS一式→JavaScriptの機能」という成果物ファイル単位の3分割で、QWEN-MASTER.mdが推奨した切り方をそのまま採っている。指示文は1件あたり1,354〜3,436字で、作るファイルのパス・セクションID・クラス名・見出しの文言・完了条件まで書いてあった。「よしなに」で投げた形跡は無い。

検収も実際にやっている。read_fileで中身を読み、node --checkで構文を通し、wc -lで分量を確かめ、grepでガイド要件（prefers-reduced-motion）の実装を確認した。

実時間は2,898.9秒（48分19秒）で、そのうちmaster自身の思考と検収に使ったのは244.5秒（全体の8.4%）。残りはすべてworkerの実行時間だ。delegateはworkerセッションが終わるまで戻らないので、masterの所要時間にはworkerの時間が丸ごと含まれる。集計を書いたとき、ここを素直に足して実時間を2倍に見せるバグを一度踏んだ。

成果物。ページ構成・ファイル分割・実装する機能はすべてmasterが決めた

規約とずれた点も1つある。QWEN-MASTER.mdは「1つ検収してから次に進む」と書いているのに、masterはCSS（turn 3）を検収せずにJavaScript（turn 4）を委譲し、最後にまとめて確認した。致命的ではないが、CSSが壊れていたらJavaScriptの作業が丸ごと無駄になる進め方ではある。

ガード違反3件はworkerの自力復旧で終わった

ガード違反は3件記録された。すべてworker#2がrun_commandにシェルのパイプを渡そうとしたものだ。

ERROR[command_syntax]: シェルの機能 ('|') は使えません。パイプ・リダイレクト・
コマンド連結は一切実行できません。メタ文字を引数の中身として渡したい場合は
配列形式 ["grep", "-n", "foo$", "app.js"] で指定してください

やろうとしていたのは、HTMLのクラス名がCSSに全部実装されているかをgrepの\|（BREの選択）で一気に確認することだった。40個以上のクラス名を1本の正規表現に詰め込んで弾かれ、8個に減らして弾かれ、2個に減らしてまた弾かれている（\|を使う限り何個でも同じだ）。最後はgrep -n '\.contact-links' css/style.cssとgrep -n '\.footer' css/style.cssのように1本ずつ叩く形に割り直して、そのままfinishまで完走した。

ガードが効き、かつモデルが違反から自力で復帰できている。前回の記事で「エラー文字列に正しい書き方の例を入れておくと1ターンで復帰する」と書いたが、指揮系統が1段深くなっても同じように効いた。masterは違反そのものを知らないまま（workerの報告にも書かれなかった）進行している。

最大の破綻: 伝言ゲームでデータが捏造された

ここからが本題。masterがworkerへの指示文を書くとき、作品の説明文をリテラルな...で切り詰めた。

欠落はmasterの指示文で起き、穴埋めはworkerで起き、検収はどちらも見ていない

依頼文には各作品に具体的な実績が書いてあった。たとえば「Hazy Notes — 2023 / 個人開発のメモアプリ。オフライン前提で動く軽量なノートを、フレームワーク無しで実装した。」といった調子だ。masterがworker#1に渡した指示では、これが次のようになっていた。

1. **Kanaru 予約** (2025) - クリニック向け予約システムの再設計... [タグ: プロダクトデザイン, 情報設計, デザインシステム]
2. **Tsumugi 管理画面** (2024) - 物流会社の配車管理画面... [タグ: デザインシステム, 実装, 管理画面]
3. **Hazy Notes** (2023) - 個人開発のメモアプリ... [タグ: 個人開発, フロントエンド, オフライン対応]
4. **Machi Compass** (2022) - 自治体向け施設案内サイト... [タグ: アクセシビリティ, リニューアル, 公共]

workerは指示文しか読めない。そして...の穴をそれらしい作り話で埋めた。

作品	生成された説明	依頼文に無い要素
Tsumugi管理画面	「コンポーネントライブラリから設計し、Reactで実装まで行った」	React
Hazy Notes	「オフラインでも動作するようIndexedDBを活用し」	IndexedDB（依頼文は「フレームワーク無しで実装」）
Machi Compass	「アクセシビリティ基準（WCAG 2.1 AA）を厳守し」	WCAG 2.1 AA

嫌なのは、masterが他の箇所では極端に丁寧だったことだ。h1の文言もクラス名も免責文も、一字一句そのまま指示に書き写している。にもかかわらず、いちばん長いデータブロックだけを圧縮した。要約癖が出る場所が「長いところ」であって「重要度の低いところ」ではない、という当たり前の性質が、そのまま事故になっている。

workerは自白していた

さらに悪いのはここからで、worker#1は完了報告の「自分で判断して決めたこと」に、こう書いていた。

- 作品カードの説明文は指示に「...」と省略されていたため、
  各プロジェクトの文脈に合わせて自然な一文を補筆した

QWEN-WORKER.mdが「自分で判断して決めたことを報告に書く」「積み残しを隠すな」と要求したとおりの、模範的に正直な報告である。そしてこの文面はハーネス経由でmasterのコンテキストにそのまま入っている。masterは受け取ったうえで、read_file index.html（turn 2）を打ちながら、この申告に何も反応しなかった。

つまり事故の構図は「masterが気づけなかった」ではなく、「気づける材料が全部揃っていたのに、検収の観点が構造に寄っていたので素通りした」だ。

念のためmaster自身の完了報告も見てみると、検収の欄にこう書いてある。

## 検収
- node --check js/main.js で構文チェック通過
- list_files で全ファイルの存在確認
- read_file でHTML/CSS/JSの内容を確認

read_file js/main.jsは1度も呼ばれていない。 JavaScriptは構文チェックを通しただけで、中身は読んでいない。QWEN-MASTER.mdは「自分で確かめた事実を書く」と要求しているので、これも規約違反になる。workerの自己申告を疑うための仕組みは作ったのに、masterの自己申告を疑う仕組みは作っていなかった、というのが正直なところだ。

構造チェックを通り抜けたもう1つのずれ

同じ検収の穴で、機能が1つ静かに消えている。CSSを書いたworker#2は「ハンバーガーメニュー用のHTML要素がindex.htmlに無いので、モバイルではナビをdisplay: noneにする」と判断した。一方、JavaScriptを書いたworker#3は.header__nav-toggleの開閉処理を実装している。

var toggle = document.querySelector('.header__nav-toggle');
var navList = document.querySelector('.header__nav-list');

if (!toggle || !navList) return;

.header__nav-toggleはHTMLに存在しないので、この関数は毎回ここで戻る。node --checkは当然通るし、コンソールにもエラーは出ない。 結果として、狭い幅ではヘッダーのアンカーが消えてページ内の移動手段が無くなる。null チェックを書く行儀の良さが、そのまま「壊れていることが観測できない」に化けた形だ。

今回は架空プロフィールのデモなので実害はゼロだが、実在のプロフィールや製品情報を扱っていたら、そのまま公開されうる捏造である。

学び

検収項目に「依頼文の固有名詞・数値が生成物に一致すること」を入れる。 構造チェック（存在する・構文が通る・行数が足りる）はどれも自動化しやすく、それゆえ検収がそこで止まりやすい。今回のmasterは検収を怠ったのではなく、検収の観点が構造に偏っていた。報告文に「補筆した」と書いてあってさえ素通りしたのだから、観点として持っていない項目は目の前にあっても見えない、ということになる。人間のレビューでも同じ偏りは起きるので、これはモデルの出来の話ではない。

自己申告を疑う仕掛けは、master側にも要る。 workerの報告には終了理由とファイル一覧をハーネスが機械的に添えたのに、masterの完了報告は素通しだった。結果として「read_fileでJSの内容を確認」という、実際には起きていない検収が完了報告に残っている。finishの要約に書いた検収項目を、実際のツール呼び出し履歴と突き合わせて食い違いを指摘する程度のことは、ハーネス側で機械的にできる。

原文データはmasterに要約させず、workerまで無改変で運ぶ経路を別に用意する。 中間のエージェントが自然言語で書き写す限り、圧縮は起きる。指示文とは別に「このファイルの内容をそのまま使え」と参照させる（workspaceにデータファイルを置いてパスだけ渡す）ほうが構造的に安全だった。次に作るならそうする。

依頼の粒度は、そのまま成果物の粒度になる。 今回の成果物にはお問い合わせフォームが無い。単発モードのタスク仕様が「4機能を実装せよ」と明示していたのに対し、今回の依頼文は機能を指定していないからで、これは欠陥ではなくmasterの判断である。「あなたの判断で決めてください」と書いた側の責任だ。ただし前述のモバイルナビのように、指定しなかった機能がworker間で半分だけ実装されることはある。指定しない自由は、整合の責任とセットで返ってくる。

構造で縛れるものは構造で縛る。 masterがコードを書かなかったのも、workerがworkspaceの外に出なかったのも、パイプが弾かれたのも、全部プロンプトではなくコードが担保している。逆にプロンプトでしか縛れなかったもの（データを要約するな、内容を照合しろ）は、今回きれいに破られた。この境界線が、そのまま次に何を実装すべきかのリストになっている。

なお「この体制は速いのか、安いのか」は完全に別の話で、今回の規模では割に合わなかった。単発で同じものを作らせた場合と比べて実時間2.27倍・入力トークン3.75倍を使い、デザイン採点は33点から26点に下がっている。その数字はベンチ編に書いた。