コンテキストを分離した独立のサブエージェントにレビューを任せたはずなのに、その判定役が「これから判定すべき仮説」を先に知った状態で評価している。そういう事故があります。判定役エージェントにとって、「まず ◯◯ を読め」と書かれた指示は、引数を渡したのと同じ です。レビュー用サブエージェントの独立性は、渡した引数だけでなく、読ませた資料まで数えないと判定できません。

分離それ自体は仕様として保証されています。Claude Code のサブエージェントは独立したコンテキストウィンドウで動き、公式ドキュメントは「それぞれのサブエージェントは新しい隔離されたコンテキストウィンドウで開始する。あなたの会話履歴も、すでに呼び出したスキルも、Claude がすでに読んだファイルも見えない」と明記しています（親の会話を引き継ぐ fork は例外です）1。

それでも、同じ命題が 経路を変えて3回 判定役に届いていました。1回目は判定役の定義そのものへの断定、2回目はその断定を禁じたときに添えた理由文、3回目は「まず読め」と必読を指示したファイルの中身です。最終的には「ファイルを読ませる」運用ごとやめ、判断に必要な情報を1行の引数に畳みました。明示的に渡してはいないのに結果としてコンテキストへ入っている情報を、本記事では 暗黙の引数 と呼びます（公式の用語ではありません）。

「読ませる資料」が答えを渡すまで ── 同じ漏洩が経路を変えて3回起きた

舞台は、連載記事の企画と本文を査読するパイプラインです。判定役は「この回は読んだ人が相談したくなる仕事の証明になるか」の一点だけを見る単機能レビュアーとして新設しました。関心事は1つで、それをいくつかの観点に分けて見ます。そしてその連載には、実験として検証中の命題がありました ── 「読者本人に呼びかける文言と、読者が上長へ渡せる形の文言では、どちらが効くか」。記事末のフォーマット部品に「検証する仮説」として明記してあったものです。この命題を判定役が事実として持っていると、実験の比較が成立しません。

先に断っておきます。この判定役は結局一度も起動しないまま作り直したので、偏った判定を出した実例は存在しません。以下は判定が歪んだ記録ではなく、命題が届く経路が開いていた記録です。

1回目 ── 判定役の定義に、検証中の命題を断定で書いた

新設した時点の判定役の定義は、観点3がこう始まっていました。

3. 決裁権のない読者が持ち出せる形になっているか

読者層が mid-level 以下の場合、読者本人は多くの場合決裁権を持ちません。

同じ命題を、記事末のフォーマット部品は「検証する仮説」の2つ目として立てていました。中堅層の読者は多くの場合決裁権を持たないはずだから、後半のいくつかの回では上長へ渡せる形の文言を試す、という組み立てです。実験で確かめようとしている命題を、その実験を査読する側に事実として持たせていたことになります。

発覚したのは、書き手の見直しではありませんでした。別モデル（Gemini）による独立レビューが拾っています。しかもそのレビューは「偏った一般化」として重大度を「中」で出しており、突き合わせた側が「実験で確かめようとしている仮説を、企画を査読するエージェントに事実として持たせた」と評価し直して「高」へ上げました。外部レビューが付けた重大度をそのまま採らない運用については、サブエージェントの「高」判定を、そのまま信じない に書いたとおりです。

2回目 ── 禁止に添えた「理由」が、同じ命題を渡していた

1回目の修正は、断定を中立形に直したうえで、禁止条項を 新たに追加 しました。追加した文がこれです。

どちらの経路が主かを決めつけないこと。 読者層のラベル（junior / mid-level / advanced）から決裁権の有無を推定してはいけません——その推定自体が、このシリーズが実験で確かめようとしている当の命題 であり、査読する側が答えを持っていると実験の比較が成立しません。

次の巡回で、この禁止条項そのものが指摘されました ── 「禁止に理由を書いて、自分で立てた原則を破った」。禁じたはずの命題が、禁止の理由文としてそのまま本文に書かれています。

2回目の修正で、方向が反転します。禁止を強めるのではなく、推定の材料である読者層のラベルを引数から撤去しました。知らないものは推定できないので、禁止条項は不要になり、削除しました。なお「禁止という書き方そのものがモデルの出力に与える影響」は別の層の話で、後段の「『禁止指示は無力』とまでは言えない」節で扱います。

3回目 ── 引数から外しても、「まず読め」と書いた先に載っていた

引数を撤去した直後のレビューで、別軸のサブエージェントが最も重い指摘を返しました。読者層を引数から外しても仮説は渡っている、判定役の定義は記事末のフォーマット部品を必読と指示しており、その部品に検証中の仮説が逐語で書かれている、という内容です。

実際、引数を外した時点の判定役の定義には、査読に入る前の手順としてこの1行が残っていました。文中の「アーク」は連載の区切り（数回ぶんのまとまり）を指す語です。

まず記事末フォーマット部品を読み、今回のアークに割り当てられた文言の方向性（問いかけ型／事実提示型／診断の申し出型／置き換えの相談型 など）を確認してから査読に入ります。

書き手の受け止めはこうでした ── 「渡していないつもりの命題を、別ファイル経由で読ませていました」。そしてこの3巡とも、漏洩を拾ったのは書き手の自己チェックではなく、別モデルか別軸のサブエージェントでした。

ここで定式化が出てきます。

「読め」と指示したファイルの中身は、引数で渡したのと同じである。 分離できているかは、渡した引数だけでなく、読ませた資料まで数えて判定する。

3回の経路を並べると、対処が毎回「その経路だけ」を塞いでいたことがわかります。

回命題が判定役へ届いた経路そのときの対処なぜ足りなかったか
1回目判定役の定義に、命題を 断定文 として書いた断定を中立形へ書き換え、禁止条項を追加禁止文に理由を添えたため、理由文が命題を運んだ
2回目禁止条項に添えた 理由文禁止ごと削除し、推定の材料（引数）を撤去引数以外の経路を数えていなかった
3回目「まず読め」と指示した 参照ファイル対象以外を開かせず、必要な情報を1行の引数に畳む（ここで閉じた）

毎回「渡していないつもり」で、渡す経路だけが変わっていました。

なぜ「禁止する」ではなく「渡さない」を選んだのか

選んだ方針は単純です。推定の材料を渡さない。渡していない情報について、禁止文を書く必要はない。

最終形では、判定役の定義ファイルの入力欄から3項目を削除しました。連載全体の設定ファイルのパス、記事末のフォーマット部品のパス、今回の話数です。代わりに司令塔（サブエージェントを呼ぶ親側）が、今回の導線ブロック（記事末に置く数行の相談導線）の文言の方向性を1行の引数として渡します（たとえば 診断の申し出型 — 持ち込んでもらえれば一緒に見る、という申し出の形）。そして「まず読め」の1行は、査読対象そのもの以外のファイルを開かないこと、設定ファイル類は読まず、判断に要るものはすべて引数で受け取ること、という指示に置き換えました。副産物として、話数の引数も要らなくなりました。話数はもともと、どの区切りに属するかを表から引くためだけのものだったからです。

引数に畳んだだけで、なぜ閉じたと言えるのか。渡している1行は「今回の回にどの方向性を割り当てたか」という 確定事項 であって、実験で確かめようとしている命題（読者層のラベルから決裁権の有無を推定してよいか）ではないからです。判断基準にしてよい確定事項と、判断基準にしてはいけない検証中の命題は身分が違います。必読ファイルの経路で渡っていたのは後者でした。

最後に残った1行が禁止文であることも確かです。Read ツールごと取り上げれば経路は物理的に閉じますが、この判定役は査読対象そのものを開いて読むので、それはできません。ただし、この禁止が背負っているのは「自分から探しに行かない」ことだけで、探す先のパス自体はもう入力にありません。2回目の修正で読者層のラベルを撤去したのと同じ、材料を渡さない側の手当てです。

似た形の話が、別の材料で測られています。判定役に「文脈メタデータとして入れただけ」の事前スコアが評点を系統的に動かすことが、192,000 回規模の試行（成功 185,271 回）で報告されており、Chain-of-Thought でも「このメタデータを無視せよ」という警告でも総効果は減らなかったと述べられています2。CIKM ‘26 に採録予定の論文です。ただし同じ1文は although 節で、産業データの実験では警告がベースライン比で対の正確性（paired accuracy）への効果を改善したとも書いています。そして測られたアンカーは 数値スコア であって、検証中の命題ではありません。渡っていたものの種類が違います。

ここで自社の記録と外部の実測との間に線を引いておきます。この一件で示せるのは、命題が届く経路が3回とも開いていた ところまでです。判定役は起動実績ゼロのまま作り直したので、偏った判定を出した出力そのものが存在しません。「届くと評点が動く」のほうは外部の実験結果であって、こちらの実測ではありません。

メリットの裏にあるトレードオフと適用限界

「禁止指示は無力」とまでは言えない

査読済みの研究（ICML 2023）が、算数問題に無関係な情報を混ぜたとき、解答する側のモデルが引きずられることを示し、緩和策の1つとして「無関係な情報を無視せよ」という指示をプロンプトに足すことを挙げています3。ただし測ったのは判定役ではなく算数問題を解く側のモデルで、しかも禁止指示ではなく「無視せよ」指示です。アブストラクトは緩和策として挙げるところまでで、効果量は示していません。したがってここから言えるのは、注意を促す指示が緩和策として提案されている領域はある、というところまでです。

同じことが、先ほどの判定役の実験の中にも書かれています。警告でも Chain-of-Thought でも総効果は減らなかったと述べた同じ1文が、although 節で「ただし産業データの実験では、警告がベースライン比で対の正確性への効果を改善した」と続きます2。条件によっては警告が効いたとも書いている、というのが読み取れる範囲です。

そこで、本記事の主張は2点に限定します。

  1. 禁止指示は効き目が保証されない。 緩和策として提案されている側が算数問題を解くモデルでの報告3、総効果が減らなかった側が判定役に入れたメタデータの報告2であり、両者を分けるのは査読の有無ではなく測った対象です。
  2. 禁止に理由を添えると、その理由文が材料そのものを運ぶ。 これは効き目の問題ではなく、文面の構成の問題です。

2点目について、外部に同じ形の測定は見当たりません。近いところでは、7B 級のオープンウェイトモデル1本（Qwen2.5-7B-Instruct）を対象にした統制実験で、禁止語を書くこと自体がその語を priming してしまうという モデルの出力挙動 までが測られています4（著者自身が全モデルへの一般化は主張しないと書いています）。測られているのはモデルの挙動であって、人が書いた文面の構成ではありません。理由を書けば理由の中身が渡る、というのは測定の問題ではなく文面の問題です。

「判定役に答えを渡すな」と一般化はできない

LLM-as-a-Judge の代表的な評価研究は、参照解答を判定役にあえて与える reference-guided grading を判定方式の1つとして提案しています5。これは、判定役が採点しようとしている「評価対象として提示された解答」の誤りに引きずられて誤判定する（原典の言い方では “it was misled by the provided answers”）という、数学・推論問題での限界への対処です。判定役に自分で独立に解かせた参照解答を渡すことで、失敗率が 70% から 15% へ下がったと報告されています（母数は数学 10 問）。答えを渡すこと自体が悪いのではありません。

引くべき線は、次の1文です。

実験で検証中の命題を、その実験を査読する側に渡さない。 前提（判断基準にしてよい確定事項）と、検証中の仮説（判断基準にしてはいけない命題）は身分が違う。

手間は消えず、司令塔へ移る

「読ませない」代わりに、渡す1行の質が全責任を負います。調査タスクをサブエージェントへ委任する運用についての報告では、「詳細なタスク記述がないと、エージェントは作業を重複させ、抜けを作り、必要な情報を見つけられない」と述べられています6。あちらが困っているのは調査の網羅性、こちらが守ろうとしているのは査読の独立性で、「委任の記述が薄いと困る」という形は同じでも困る中身は違います。それでも、渡す1行の質がそのまま結果を左右するという形は共通します。

実務上のコストもはっきりしています。連載の区切りや文脈が変わるたびに、司令塔側で1行を作り直す必要があります。資料を読ませておけば自動で追随した部分を、明示的な受け渡しに置き換えたからです。

そして効果は測っていません。作り直したあとの起動実績がこの記録の期間内になく、「漏洩が止まった」ことを事後に観測してはいないからです。示せるのは経路を閉じたところまでです。なお同じ変更で、判定役を lead-reviewer から inquiry-reviewer へ改名しました。兄弟にあたる reader-reviewer / continuity-reviewer が関心事を名乗っているのに lead だけが役職名にも読める、という不揃いを直したものです。

検出は外部に依存している

この一件では、3巡とも漏洩を拾ったのは書き手の自己チェックではありませんでした（母数は3巡）。別モデルか、別軸のサブエージェントです。

同じ「外部の目」でも、拾える欠陥の種類は違いました。単一の正本から派生した設計文書の追従漏れは、差分を見るレビューでは原理的に拾えません。ただしこれは仮説の漏洩とは別の欠陥種別での観察であって、3回目の漏洩を拾った経路とは別の事象です。別モデルのレビューの得手不得手については 別モデルのコードレビューは「欠陥の所在」を当てるが「修正案」は逆を向く に書きました。

前提が変われば結論はどう変わるか

読ませ口は1つではありません。 Claude Code のサブエージェントの初期コンテキストには、システムプロンプト・タスクメッセージ・CLAUDE.md・Git status に加えて、skills フィールドで指定したスキルの全文が入ります1。明示的な必読指示を消しても、仕様上はここが同じ経路になると読めます。この経路で実際に命題が漏れたことを測ってはいませんが、点検の対象からは外せません。

モデルが強くなれば禁止が効くようになるのか。 否定制約の失敗を機構レベルで調べた研究が示したのは 7B 級1モデルでの結果であり、規模や系統が変われば違いうると著者自身が書いています4。ただし「効くようになる」に賭ける設計と、「渡さない」で閉じる設計とでは、外したときのコストが違います。

判定役が資料を読むべき場面も、当然あります。 参照解答を渡す評価設計5のように、渡すことが前提の判定タスクでは、この記事の結論は当てはまりません。分けるべきは「渡してよい確定事項」と「渡してはいけない検証中の命題」であって、資料の量ではありません。

よくある質問（FAQ）

Q. サブエージェントに分ければ、レビューの独立性は保証されるのですか？

A. 保証されるのは「親の会話履歴と既読ファイルを引き継がない」ところまでです。公式ドキュメントも、サブエージェントは新しい隔離されたコンテキストウィンドウで開始し、会話履歴も、すでに呼び出したスキルも、すでに読んだファイルも見えないと明記しています（親の会話を引き継ぐ fork は例外です）1。ただし、そのサブエージェントに Read ツールを与えて「まず ◯◯ を読め」と書けば、隔離は自分の手で破ったことになります。

Q. 「この情報は判定に使わないでください」と書けば十分ではないですか？

A. 不十分な場合があります。判定役に文脈メタデータとして入れた事前スコアは評点を系統的に動かし、「無視せよ」という警告でも Chain-of-Thought でも総効果は減らなかったと報告されています（測られたのは数値スコアのアンカーです。同じ論文は、条件によっては警告が改善したとも書いています）2。加えて、禁止の理由を書き添えると、その理由文が禁じたい命題そのものを運びます。こちらは効き目以前の話で、その命題が文面に書かれているという事実自体は、禁止が効くかどうかとは別に決まります。

Q. 判定役に参照解答や資料を渡すのは常に間違いですか？

A. 違います。LLM-as-a-Judge の評価研究では、参照解答を判定役に与える手法が判定方式の1つとして提案されています5。線を引くべきは資料の量ではなく身分です ── 判断基準にしてよい確定事項と、実験で検証中の命題は別に扱います。

Q. 読ませるのをやめると、何が犠牲になりますか？

A. 司令塔側の手間です。資料を読ませておけば自動で追随した部分を、明示的な1行の引数に畳んで渡し直す必要があります。調査タスクの委任についての報告ですが、詳細なタスク記述を欠くとエージェントが作業を重複させたり抜けを作ったりすることが知られており6、渡す1行の質がそのまま結果を左右する点は査読の委任でも変わりません。

まとめ

  • 判定役の独立性は、渡した引数ではなく、届く経路の総数で決まります。 「読め」と指示したファイルの中身は、引数で渡したのと同じです。
  • 禁止に理由を添えると、理由文が禁じたい命題を運びます。 「その命題が文面に書かれている」という事実自体はモデルに依存しません。効き目の話をする前に、渡すか渡さないかが決まっています。
  • 「渡すな」ではなく「渡す身分を分ける」。 判断基準にしてよい確定事項と、実験で検証中の命題を混ぜないことです。参照解答を渡す評価設計が成立している以上、資料の量で線を引くと間違えます。
  • 点検は引数リストだけでなく、読ませ口の一覧で行います。 明示的な必読指示に加えて、初期コンテキストへ自動で入るもの（指定したスキルの全文など）も、仕様上は同じ経路になります。
  • この事例で漏洩を検出したのは、3巡とも外部でした（母数は3巡）。自己チェックが同型の欠陥を拾えなかった以上、独立した目を通す工程は外せません。

開発プロセスの標準化、AI Operations の導入設計、アーキテクチャや意思決定プロセスの見直しについて、ぜひ コンタクトフォーム よりお気軽にご相談ください。

Footnotes

  1. Create custom subagents Anthropic、Claude Code 公式ドキュメント（2026年9月21日閲覧）。「独立したコンテキストウィンドウ・独自のシステムプロンプト・個別のツールアクセスで動く」は冒頭の導入段落。「新しい隔離されたコンテキストウィンドウで開始し、会話履歴も、すでに呼び出したスキルも、すでに読んだファイルも見えない」「fork は親の会話を引き継ぐ例外」、および初期コンテキストの一覧（システムプロンプト / タスクメッセージ / CLAUDE.md / Git status / Preloaded skills＝skills フィールドで指定したスキルの全文 / Sibling roster）は、いずれも「Manage subagent context」節の「What loads at startup」小節。 ↩ ↩2 ↩3

  2. Anchoring Bias in LLM-as-a-Judge Systems: Prior Scores Compromise Evaluation Independence Ante Kapetanovic, Kemal Altwlkany, Andro Mercep, Tomislav Duricic, Emanuel Lacic、arXiv:2608.25869 [cs.CL]、2026年8月26日。Comments 欄に「to appear in proceedings of the 35th ACM International Conference on Information and Knowledge Management (CIKM ‘26), 2026」とあり、CIKM ‘26 に採録予定（2026年9月21日閲覧）。事前スコアが文脈メタデータとしてだけ入っていても評点を系統的に動かすこと、192,000 回の試行（成功 185,271 回）・8モデル中7モデル・Cohen’s d の絶対値が最大 0.71 に達すること、および「Chain-of-Thought でも metadata-disregard warning でも総効果は減らない。ただし industry 実験では警告がベースライン比で paired accuracy 効果を改善した」という1文は、いずれもアブストラクト。 ↩ ↩2 ↩3 ↩4

  3. Large Language Models Can Be Easily Distracted by Irrelevant Context Freda Shi, Xinyun Chen, Kanishka Misra, Nathan Scales, David Dohan, Ed H. Chi, Nathanael Schärli, Denny Zhou、Proceedings of the 40th International Conference on Machine Learning, PMLR 202:31210-31227, 2023（査読済み）。モデルが無関係な情報に容易に気を散らされること（“easily distracted”）と、緩和策として self-consistency デコーディングおよび「無関係な情報を無視せよという指示をプロンプトに足すこと」を挙げている記述は、いずれもアブストラクト（緩和策は末尾の1文）。測定対象は GSM-IC の算数問題を解く側のモデルであり、判定役ではない。arXiv 版（arXiv:2302.00093）はアブストラクトの文言が異なる。 ↩ ↩2

  4. Semantic Gravity Wells: Why Negative Constraints Backfire Shailesh Rana（単著）、arXiv:2601.08070 [cs.AI] v1、2026年1月12日。Comments 欄に掲載先の記載がないプレプリント（2026年9月21日閲覧）。違反の 87.5% が priming failure であること（禁止語を明示すること自体が対象表現を活性化させる）はアブストラクト。実験に使ったモデルが Qwen2.5-7B-Instruct 1本だけであることは §7.3 Limitations 冒頭の「Single model.」、全モデルへの一般化を主張しない旨（“we do not claim universality across all models”）は本文冒頭。 ↩ ↩2

  5. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena Lianmin Zheng ほか12名、arXiv:2306.05685 v4（2023年12月24日）、NeurIPS 2023 Datasets and Benchmarks Track。position・verbosity・self-enhancement の3バイアスはアブストラクト。判定の3方式の1つとしての reference-guided grading の定義は §3.1「Types of LLM-as-a-Judge」、判定役が評価対象として提示された解答に引きずられる限界（“it was misled by the provided answers”）は §3.3「Limitations of LLM-as-a-Judge」、reference-guided judge の提案と失敗率 70% → 15% は §3.4「Addressing limitations」（数値の所在は Table 4。母数は数学 10 問で、failure は誤った回答を正しいと判定することを指す）。 ↩ ↩2 ↩3

  6. How we built our multi-agent research system Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford（Anthropic Engineering）、2025年6月13日。「詳細なタスク記述がないと、エージェントは作業を重複させ、抜けを作り、必要な情報を見つけられない」は「Prompt engineering and evaluations for research agents」節の第2項「Teach the orchestrator how to delegate.」。 ↩ ↩2