この記事は、連載「言わない技術」の第 2 回です。うまくいかない症状と、その対処を一つずつ並べています。各回はファイルやスクリプトを一つ置けば完結します。その仕組みがなぜ要るのかは、置いたあとに解説を読めば分かります。連載の全体像と各回の一覧は序論にあります。

今回は、手順の話です。AIに「こうやって直して」と手順を書く代わりに、何を渡せばよいかを扱います。手順を書くと、AIの探索の範囲は、AIが探し始める前に、書いた手順の中に狭まります。AIは指示に正確に従い、頼まれていないやり方まで探すことは当てにできないからです。

まず一つだけ、探してみてください。

直近のセッションで、あなたがAIに手順を書いた箇所です。「まず〜して、次に〜して」「〜の関数を使って」「〜のパターンで」。

その手順は、あなたが一番良いと思った順序でしたか。

それとも、書かないと不安だったから書いたのでしょうか。

CC BY 4.0

指示ファイルを数えたら、番号付きの手順は 0 行でした

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

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

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

場所中身これは手順か
画面確認のスキル4 段階（grep → lint → 撮影 → スモーク）順序が効く。安い手段から順に試し、前の手段で解けたら進まない
メモリ保存前のチェックリスト5 項目（価値・恒久性・重複・整合・承認）判定条件。上から順に見る必要はない

指示ファイルとスキルと用途カタログの 3 つにある番号付きの列挙は、「順序そのものが答えである場合」と「順序と関係のない判定条件」の 2 つだけでした。作業の手順を書いた列挙は、この 3 つの中に 0 件です。私は手元の計画書（機能ごとの計画を書いた文書）も、作業の手順の節（「手順」の見出しや「STEP 1」の番号）があるかで数えました。200 本のうち、その節を持つものは 0 本でした。

AIの推論は、人が書く手順を超えることが多い

Anthropic のプロンプト指針は、全モデル向けのページで、AIの考え方を導くときの注意として、次のように書いています。

「よく考えて」のような一般的な指示のほうが、手で書いた段階ごとの計画よりも、良い推論を生むことが多い。Claude の推論は、人が指示する手順を超えることが多い。

同じページは、いまのモデルは指示に正確に従う、とも書いています。例に挙がっているのは、「変更を提案してもらえますか」と頼むと、変更してほしいつもりでも、提案だけが返ることがある、という場面です。あなたが頼んだ以上のことをAIにしてほしいなら、AIが曖昧なプロンプトから推し量ってくれるのを当てにせず、はっきり頼むように、とあります。

AIに手順を書くと、AIはその手順を文字どおりに受け取り、手順に沿って進みます。あなたは、手順の外にあるやり方を探すことを、AIに頼んでいません。手順は、AIが探し始める前に、探索の範囲を狭める指示です。

だから、あなたの手順が最善でなかったなら、最善の手順との差が、そのまま出力の差になります。

あなたがAIに、既存の一覧に並び替えを足す仕事を、手順まで書いて頼んだとします（「まず一覧の取得を直して、次に並び替えのボタンを足して。並び替えにはこの関数を使って」）。AIは手順のとおりに直し、自動テストも通りました。あとで、同じ並び替えを既にしている仕組みが別のファイルにあり、AIはそこに触れていなかったと分かりました。あなたも、その仕組みを知りませんでした。次に同じような仕事を頼むとき、あなたなら次のどちらにしますか。

  • 手順を、もっと細かく、正確に書き直す
  • 手順を消し、何ができていれば終わりか、触ってはいけない場所、どの自動テストが通れば合格かだけを書く

答えは、手順を消すほうです。AIが既存の仕組みに触れなかったのは、書いた手順に正確に従い、手順の外にあるやり方を探すことは頼まれていなかったからです。手順を細かく書き直せば、今回見つかった仕組みは手順に書き足すことができます。けれども、次の仕事であなたが知らない仕組みは、どれだけ細かく書いても手順に入りません。細かくするほど、AIが従う範囲は、あなたの知っているやり方の中に寄ります。手順を消して、結果と制約と確かめ方だけを渡せば、どの関数を使い、どこから手を付けるかを探して決めるのは、AIです。

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

手順を書くと、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]

requires に並べた 4 つのファイルで決めているのは、入力（作業の一覧）と、確かめ方に当たる出口（受け入れテスト。サブエージェントの成果をメインエージェントの側で判定するスクリプト）と、制約に当たる越えてはいけない境界（差し込みはメインエージェントの側で行う）です。手順は書いていません。

第 1 回では、指示ファイルからAIに実行を頼む行を削り、コマンドの実行を、hookや自動テストのように、AIが読まなくても動く仕組みに任せました。この用途カタログも同じで、4 つのファイルがそろっているかどうかは、AIに頼まずに、サブエージェントの起動時に割り込むhookが確かめます。hookが確かめるのは、ファイルが実在するかどうかだけです。hookは、ファイルの中身の良し悪しを測りません。

この用途カタログは、前作「AIの意見を聞かない技術」の第 4 回で私が置いたものと同じです。前作の第 4 回はサブエージェントに渡す入力の話で、私は使う場面を並べた条件文を増やさず、契約（渡すもの、使わない場面、越えてはいけない境界）を詳しく書きました。今回、この用途カタログで置き換えるのは、毎回打つ指示に書いていた手順です。

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

手順を書かないというのは、「具体的に書くな」という意味ではありません。どこに手順を書いてよいかは、上の表の 2 箇所を見て分かりました。指示をどこまで具体的に書くかは、その操作が、手順を少し変えただけで失敗するかどうかに合わせます。選択肢が何通りもあって判断が要る作業には目安を書き、安全な選択肢が一つしかない作業には正確なコマンドを書きます。

上の表の、画面確認のスキルの 4 段階は、安全な選択肢が一つしかない作業の例です。安い手段から試すという順序そのものが答えなので、順序を書きます。逆に、「どう実装するか」は、選択肢が何通りもある作業で、私が知らない選択肢のほうが多いです。

だから、指示に書いていた手順は、消さずに、次の表の右の列のものに置き換えます。

書いていたもの置き換えるもの
まず A して、次に B して結果: 何ができていれば終わりか
この関数／このパターンを使って制約: 触ってはいけない場所、越えてはいけない境界
最後に確認して（第 1 回）確かめ方: どの自動テストが通れば合格か

書かなくなったもの

私が指示に書かなくなったのは、手順です。実装の道筋と、使う関数と、着手の順番です。結果と制約と確かめ方は、以前より丁寧に書いています。減ったのは、私が知らない実装の選択肢を、AIが探す前に探索の範囲から外してしまう行だけです。

CC BY 4.0

注意: 渡すファイルを用意しないまま手順を消すと、ただの丸投げになります

用途カタログに並べた 4 つのファイルは、用意するのに時間がかかります。作業の一覧を作り、受け入れテストを書き、注意点をまとめる必要があります。その用意をせずに、「うまくやって」とだけ言って渡すのは、ただの丸投げです。前作の第 4 回では、使わせるスクリプトを渡さなかった 13 体のサブエージェントが、それぞれ自分用のスクリプトを書いていました。

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

前提

コンテキスト（AIの作業記憶）を互いに引き継がない場を、2 つ用意します（新しいセッションを 2 つ立てるか、サブエージェントを 2 体起動する）。手元には、変更してよいリポジトリを用意します。

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

手順

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

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

  • 1 体目に無く、2 体目にあるファイル —— それが、あなたの手順の外で、2 体目が選んだ実装です
  • そういうファイルが 1 つも無い —— その課題では、あなたの手順の外で 2 体目が選んだ実装は無かったということです。それも、この検証で分かったことです

見ないのは、どちらが速かったか、どちらが行数が少ないか、どちらの成果物が好みかです。この検証で測ることができるのは、探索の範囲だけで、成果物の出来の良し悪しは、測る対象の外にあります。

後始末

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

1 体目と 2 体目は、コンテキストを互いに引き継がない別々の場で動かしてください。

同じセッションで続けると、1 体目に渡した手順が、2 体目のコンテキストに残ります。

そして、作業した 1 体目にも 2 体目にも、「どちらの渡し方が良かったですか」と聞かないでください。

答えるのは、その渡し方で作業をした当のAIです。AIに自分の作業を自分で採点させるのは、測定ではありません。判断の材料は、手順 4 で並べたファイルの一覧だけで足ります。

次回は「不具合詳細を書かない技術」。私は、AI に不具合の詳細を書いていません。 それでも、直ります。

連載「言わない技術」