サブエージェントの出力だけは、細かく指示しろ

CC BY 4.0

手順は、1 本だけ残っていました

第 2 回で、指示ファイルにもスキルにも用途カタログにも、タスクの進め方を書いた手順は 1 つも無い、と書きました。そのとき私は、もう手元に手順は残っていないと思っていました。数え直したら、1 本ありました。

置いてあるのは、サブエージェントに渡す手引きです。第 2 回で数えたのは指示ファイルとスキルとカタログの側で、カタログが「起動前に用意しておけ」と指しているファイルの中身までは見ていませんでした。残っていた 1 本は、そこにありました。例外はここです。

同じ課題を、2 つのモデルで 2 通りずつ投げました

第 1 回で、検証を指示した AI と、しない AI を比べました。あれは opus で測っています。 ところがサブエージェントは違うモデルで走ります——私の用途カタログは、翻訳の用途に model: [sonnet, haiku] と書いてあり、コメントには「⚠️ opus を既定にしない」と添えてあります。だから、第 1 回の結果をそのまま持ち込めません。

そこで、同じ課題を sonnet でも 2 通り回しました。

正答は 4 体とも、先に機械で作った正解表と完全一致でした。罠——10 本目にだけ該当の一文が無い——も 4 体とも避けています。

仮説は外れました。 私は「下位モデルには細かい指示が要る」と思っていました。sonnet は指示なしで 10/10 を出し、しかも opus より手数が少ない（3 回 → 4 回）。

外れ方は、2 つに分かれます。

一つ、増え方が違います。 検証を指示したときの手数は、opus が 2 倍（4 → 8）、sonnet が 4.3 倍（3 → 13）。第 1 回で書いた「頼むと手数が増える」の度合いが、モデルで違う。

二つ、自分で照合した痕跡が、opus にしかありませんでした。 指示していない opus は、報告の冒頭に数字を出しました——「目印の語を grep した。9 ファイルにちょうど 1 回ずつ、10 本目には 0 回」。sonnet のほうは「他の 9 本すべてで該当のフレーズを確認しました」と述べただけで、照合の数字はありません。

⚠️ 観測できるのは報告に痕跡が残ったかどうかだけです。正答が一致したことは、照合した証拠になりません——「読まない技術」の第 9 回のとおり、自己申告は完了に寄ります。

Anthropic のプロンプト指針にも、但し書きがあります——特定のモデル名が付いた技術は、そのモデルで測ったものとして扱い、他のモデルへ当てる前に自分で確かめよ。

理解したことは一文にできます。

ここまでの技術は、測ったモデルの上でだけ成り立つ。走るモデルが違う相手には、出力の形——何をもって完了とするか——を書く。

仕組み: 完了の形を、1 枚に書き切る

置くのは 1 枚です。用途ごとに、出したものが受け取られる条件を並べます。受け取るのは、サブエージェントを起動して仕事を割り振ったメイン側の AI で、ここでは「中央」と呼びます。指揮を執る側です。一般の用語ではオーケストレーターです。

# 連載記事の翻訳の手引き（実物からの簡約版）

| | |
|---|---|
| 入力 | 原本 1 本と、その言語の「連載の入口」の訳（用語の正） |
| 出力 | `<series>/<lang>/<file>.md` **1 本だけ** |

⚠️ 記事の登録一覧は触らない（言語を足すのは中央の仕事。同じ 1 ファイルを全員が書くと競合する）
⚠️ 原本も触らない。原本に手が要ると分かったら、訳を止めて報告する
⚠️ テストを走らせない（並走ガードが 1 本しか通さない）。受け入れテストは中央で回す

## 囲み（```）は 3 種類ある —— 訳してよいかが違う
  code      = 読者が手元で走らせるもの。一致必須（行コメントだけ訳す）
  markdown  = 読者が自分の指示ファイルに書く文章。訳す
  mermaid   = 図。ラベルは文章なので訳す

## 機械が落とすもの（揃っていないと赤になる）
  リンク先 URL（順序込み）/ 見出しの数と階層 / 箇条書きの項目数 / 段落の数 /
  code の囲み（一字一句）/ 本文の数値（桁区切りもそのまま）

## 機械が落とさないもの（= 人が見る）
  訳文の意味・語調・用語の一貫性 / 題が一覧で読める長さか / 実画面

前作の第 4 回が書いたのはカタログの契約——どの用途で、何を用意できたら起動してよいか。入口です。こちらは出口で、出てきたものの形を決めています。

そして、この 1 枚は自分では判定しません。「落とすもの」を見るのは受け入れテストのほうで、原本と訳の構造が同じかだけを突き合わせます。手引きと受け入れテストは 2 つとも、カタログの「起動前に用意しておけ」の側に入っています（第 2 回で見た欄の、別の用途の行です）。

⚠️ ここで増えているのは出力の形であって、やり方ではありません。冒頭で見つかった 1 本の手順も、中身は中央とサブエージェントの担当の境目です。

そして、もう指示しません

手引きを 1 枚書いたあと、1 回ごとの依頼に書くことは無くなりました。渡すのは「この記事を、この言語へ」だけです。前作の例外回と同じ形で、一度だけ、細かく書く。その一度が、次からの依頼を短くしました。

注意: 4 体とも、間違えませんでした

一つ、「下位モデルは間違える」とは書けません。 4 体とも 10/10 でした。測ったのは 1 課題・各条件 1 回で、統計ではありません。観測できたのは「易しい課題では差が出なかった」ということだけです。

二つ、全部のサブエージェントに手引きを書くのではありません。 書いてあるのは、同じ形の出力が何本も出る用途だけで、読み取りだけの調査には書いていません。前作が同じ場所に線を引いています——厚く書くのは、繰り返し呼ばれるものに限る。

三つ、手引きも読まれたときだけ効きます。 この回だけ例外にはなりません。読まれなくても落ちるのは、受け入れテストだけです。

検証手順: 手引きに書いたものを 1 つ欠いて、失敗になることを確かめる

前提

• サブエージェントに渡す手引きを 1 枚書き、その中に「機械が落とすもの」の一覧があること
• 受け入れテスト（成果物が受け取れる形かを判定するもの）を書き終えていること
• ⚠️ サブエージェントは起動しません。受け取る側だけを確かめます

所要時間: 10 分

手順

1. あなたが、正しい成果物を 1 つ用意し、受け入れテストに通して合格することを先に見ておきます（過去にサブエージェントが出したもので構いません）。⚠️ ここを飛ばすと、手順 3 で落ちたときに「欠いたから落ちた」のか「元から落ちていた」のかが分かりません
2. あなたが、手引きの「機械が落とすもの」から 1 つ選び、その要素をわざと欠いた写しを作ります（見出しを 1 つ消す、項目を 1 行減らす）。⚠️ 元のファイルは残し、写しのほうを壊してください
3. あなたが、写しを受け入れテストに通します

合格条件（すべて満たすこと）

• 受け入れテストが失敗になる
• 何が欠けたかが出る（「見出しが 1 つ足りない」に当たる形）

合格しなかったとき

• 通ってしまった —— 手引きに書いた「機械が落とすもの」を、受け入れテストが見ていません。手引きと判定が食い違っています
• 「不合格」としか出ない —— 直す側（サブエージェントか、あなた）が、差分を自分で探すことになります

後始末

• 壊した写しを消します

⚠️ 見ているのは意味ではなく構造の同一性です。中身が正しいかは人が見ます。機械に決められるところまでは、機械に決めさせる。

CC BY 4.0 はここまで