具体的な指示を出さない技術

CC BY 4.0

数えたら、手順は 1 つも残っていませんでした

私は長いあいだ、具体的に書くほど良い結果が返ると思っていました。実際、AI 向けの指示は「明確に、具体的に」が大原則として語られます。

だから数えてみて、意外でした。私の手元の本番プロジェクト——typingtube という、YouTube の音楽動画でタイピング練習ができる Web サービスです——の指示ファイルは 102 行あります。番号付きの手順は、0 行でした。

指示ファイルの外——スキル（カスタムコマンドやツールの登録）と、サブエージェント（別に立ち上がって働く AI）の用途カタログまで含めても、番号付きの列挙が残っているのは 2 箇所だけです。

指示ファイルとスキルとカタログ、この 3 つに、タスクの進め方を書いたものは 1 つもありません。 残っているのは「順序そのものが答えである場合」と「順序と関係のない判定条件」の 2 つだけでした。ついでに計画書のほうも数えました——200 本あって、番号付きの手順を持つものは 0 本でした。

判断を先に渡すと、その通りに出力が縮む

Anthropic のプロンプト指針に、これを一番はっきり書いた一節があります。レビューを頼むときの話です。

「重大な問題だけ報告して」「保守的に」と書くと、モデルは文字どおり従い、報告が減る。全部報告させて、絞り込みは別の工程でやれ。

やり方を書くというのは、これと同じことをしています。「この関数を使って」は「他の選択肢は見なくていい」であり、「まず A、次に B」は「A より先に見るべきものがあっても飛ばせ」です。手順は、探索の範囲を先に閉じる指示として届きます。

指示は AI に守られます。だから、あなたの手順が最善でなかった場合、その差はそのまま出力の差になります。

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

手順は、探索の範囲を先に閉じる。だから渡すのは、結果と制約と、確かめ方だけにする。

仕組み: やり方ではなく、渡すものを縛る

置くのは 1 枚です。用途ごとに「起動前に実在していなければならないファイル」を並べます。サブエージェントを起動して仕事を割り振り、成果を受け取るメイン側の AI を、ここでは「中央」と呼びます。指揮を執る側です。一般の用語ではオーケストレーターです。

# subagent_missions.yml — 用途カタログ（実物からの簡約版）
missions:
  i18n_translation:
    description: Backfill locale translations (1 agent = 1 language)
    requires:                                    # ⚠️ 実在しなければ起動が止まる
      - scripts/i18n_ledger.py                   # 作業の一覧（渡す唯一の入力）
      - scripts/i18n_apply.py                    # 差し込みは中央で行う
      - scripts/i18n_verify.py                   # 受け入れテストも中央
      - docs/reference/i18n_translation_notes.md # 言語別の注意点
    model: [sonnet, haiku]

この 4 行が、そのまま第 1 回の一文の続きになっています。機構（hook や自動テストのように、読まれなくても動く仕組み）が持てるのは実行で、持てないのは理由でした。ここで縛っているのも実行ではありません——入力（作業の一覧）、出口（受け入れテスト）、越えてはいけない境界（差し込みは中央）です。進め方は書いていません。

起動時に割り込む hook が見るのは、この 4 つの実在だけです。中身の良し悪しは測りません。

前作「AIの意見を聞かない技術」の第 4 回で置いたのと同じ 1 枚です——あちらは道具の説明文の話で、使う場面を並べるのをやめ、渡すものの取り決めだけを厚く書きました。こちらは、毎回打つ指示の側です。

手順を書いてよい場所は、ある

「具体的に書くな」ではありません。線引きの引き方は、上の 2 箇所が教えてくれました。指示の具体度は、その操作の壊れやすさに合わせる。 判断が要る開けた領域には目安を、一つの手順しか安全でない狭い橋には、正確なコマンドを。

上の表の 4 段のはしごが、まさに狭い橋です。安い手段から試すという順序自体が答えなので、順序を書きます。逆に「どう実装するか」は開けた野原で、道は何本もあり、私が知らない道のほうが多い。

だから、書き換えは「消す」ではなく「置き換える」になります。

CC BY 4.0 はここまで

CC BY 4.0

注意: 渡すものが用意できていないなら、手順を書いても届きません

カタログの 4 つは、書くのに時間がかかります。作業の一覧を作り、受け入れテストを書き、注意点をまとめる。それをせずに「うまくやって」とだけ言うのは、この回の話ではなくただの丸投げです。前作が同じ場所で書いたとおり、渡さなかったものは、サブエージェントが自分で作ります。

検証手順: 同じ課題を、二通りの渡し方で投げる

前提

• 会話を引き継がない場所を 2 つ用意できること（新しいセッションを 2 つ立てるか、サブエージェントを 2 体起動する）
• 手元に、変更してよいリポジトリがあること

所要時間: 15〜30 分（課題の大きさで変わります）

手順

1. あなたが、課題を 1 つ選びます。条件は 2 つで、30 分以内に終わる大きさであることと、実装の道が何本もあることです（例: 既存の一覧に並び替えを足す）。⚠️ 道が 1 本しかない課題——設定値の変更、定型のファイル追加——では、この検証は差が出ません
2. 1 体目に、やり方まで書いて渡します。 あなたが最善だと思う手順を、いつもどおり書いてください（「まず A を直して、次に B、この関数を使って」）
3. 2 体目に、同じ課題を、結果と制約と確かめ方だけで渡します。 課題の文言は 1 体目と 1 字も変えず、手順を書いた部分だけを次の 3 つに差し替えます——何ができていれば終わりか（結果）、触ってはいけない場所（制約）、どの自動テストが通れば合格か（確かめ方）
4. あなたが、2 体が触ったファイルの一覧を並べます

見るところ（合否ではありません。差が出るかどうかを見ます）

• 1 体目に無く、2 体目にあるファイル —— それが、あなたの手順が先に閉じていた道です
• そういうファイルが 1 つも無い —— あなたの手順は、その課題では最善だったということです。それも結果です

見ないもの

• どちらが速かったか、どちらが行数が少ないか、どちらの成果物が好みか
• ⚠️ この検証が測れるのは探索の範囲だけで、出来の良し悪しではありません

後始末

• 2 体の成果物は、取り込まないなら消します

⚠️ 1 体目と 2 体目を、同じセッションで続けてやらないでください。1 体目に渡した手順が、2 体目の文脈に残ります。そして、作業した 1 体目にも 2 体目にも、「どちらの渡し方が良かったですか」と聞かないでください。 答えるのは、その渡し方で書いた当の AI です。自分の作業を自分で採点させるのは、測定ではありません。判断の材料は、手順 4 で並べたファイルの一覧だけで足ります。

CC BY 4.0 はここまで