読まない技術第8回：修正履歴を読まない技術

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

今回は、AI を軌道修正させた記録の話です。同じ失敗への対処を私が指示ファイルに書いておいても、AI は次にもまた同じ失敗をします。問題が起きる前に読んだ方針には文脈がないからです。効くかどうかを決めるのは内容ではなく、差し込む瞬間のほうでした。何が足りないのかを扱います。

覚えがあると思います。AI が失敗したとき、同じやり方でもう一度試す。もう一度。もう一度。

「リトライを繰り返すな、失敗したらアプローチを変えろ」——過去に何度も軌道修正させて、その教訓は指示ファイルにも書いてある。それでも失敗の瞬間になると、AI は目の前のエラーを「もう一度やれば直る」と処理します。エラーの直後にもう一度試すのは学習で染み付いた定番の振る舞いで、教訓の 1 行より優先順位が上にあります。

同じことが続くと、前はどう直したのかを探しに戻ることになります。過去のやり取り、そのとき書いた対処、指示ファイルに足した行。この修正履歴を読み返して、私は方針をもう 1 行足していました。次のセッションで、また同じ失敗が出ます。

効かない理由は二つ重なっています。一つは序論の薄まりで、方針はコンテキストの遥か上で他の全部と混ざっています。もう一つが本質で、問題が起きる前に読んだ方針には文脈がないのです。何も失敗していない時点で読む「失敗したらアプローチを変えろ」は他人事の一般論で、覚えておく理由が AI 側にありません。同じ文が意味を持つのは、失敗が目の前にある瞬間だけです。

第 7 回で「方針は保存の後にしか効かない」を見ました。保存は最優先で走るので、その前に置いた方針は負けていました。

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

方針は、問題が起きる前に読ませても文脈がない。効くかどうかは内容ではなく、差し込む瞬間で決まる。

CC BY 4.0

なぜ、問題が起きる前に読ませても効かないのか

先に読ませて覚えさせる、という道はそもそもありません。AI は使われているあいだ、学習をしていないからです。Brown ほかが 2020 年に示したのは、勾配の更新も追加学習もなしに、テキストのやり取りだけで振る舞いが決まるという形でした。指示ファイルを読ませても、AI の中に何かが書き込まれるわけではありません。読ませた方針は、コンテキストに並ぶ行の 1 つになります。

その行は、会話の先頭で読み込まれたまま動きません。失敗が起きるのはずっと後です。その瞬間に近いところにあるのは、直前に届いたエラーと、進行中の作業です。直前に届いたエラーは、その瞬間の一番強い入力になります。

直近に置くという形は、Anthropic 自身も使っています。公開されている claude.ai のシステムプロンプトには、利用者のメッセージに追記される形で送られ、長い会話のあいだ Claude が指示を保つのを助ける仕組みがあります。

失敗した直後に出てくる手にも、由来があります。同じコマンドをもう一度打つ並びは、学習のときに繰り返し見た形です。第 1 回の標準コマンドと同じで、こちらが指示しなくても出てきます。

出てくるだけなら、2 回目で直ることもあるはずです。そうならないのは、1 回目と 2 回目のあいだに、外から新しい材料が何も入らないからです。Huang ほかは、LLM は外部のフィードバックが無いと自分の応答を自己修正できず、ときに直したあとでかえって悪くなると報告しています。材料が同じなら、言い回しが変わっても同じ種類の手が出ます。だから私は、その 2 回目そのものを止めることにしました。

仕組み: 方針ファイル 1 枚と、瞬間に差し込む hook

軌道修正の方針——過去の失敗から人間が学ばせたいこと——を 1 ファイルに数行で書きます。

# 軌道修正の方針（問題を検知したときに差し込まれる）
- 1 回失敗したら、同じ方法を繰り返さず、まずアプローチを根本的に変える（分割・別手法）
- やり直しの前に、必ず人間に確認を取る
- 失敗が 2 回続いたら、その手段を中断して代替案を提示する

そして、問題の検知できる形を hook に持たせ、検知した瞬間にこのファイルを差し込みます。私の環境での実例はサブエージェントのリトライです。個人で運営している typingtube（YouTube の音楽動画でタイピング練習ができる Web サービス）では、翻訳のような数の多い仕事をサブエージェントに投げるので、失敗も再開もそこで起きます。同じ名前での再起動や、起動済みエージェントへの再送信は機械的に検知できるので、hook がそこで止めて方針を出します。

# 起動の記録に同じ名前があれば、それはリトライ。止めて方針を差し込む（手元のコードを短くしたもの）
# 記録は、起動を通すたびに echo "$agent_name" >> tmp/launched_agents.txt で追記しておく
if grep -qxF -- "$agent_name" tmp/launched_agents.txt 2>/dev/null; then
  echo "'${agent_name}' has already been launched. This counts as a retry." >&2
  cat docs/course_correction.md >&2
  echo "Recount what is left, report to the human, then ask for direction." >&2
  exit 2
fi

コードが exit 2 で終わっているのは、それが AI に届く終わり方だからです。Claude Code のドキュメントは、終了コード 2 で終わった hook は操作を止め、標準エラー出力を止めた理由として Claude へ渡す、と書いています。1 で終わった hook は操作を止めず、差し込んだ文も AI には届きません。

方針を hook のメッセージに直書きせず cat しているのは、方針の更新を hook に触らず済ませるためです。失敗の記録が増えても、絞り込んだ数行だけを差し替えます。

これが効いた実例を一つ。この仕組みの前、失敗したサブエージェント 2 体を AI が確認なしで再開し、そのままセッションの使用量上限に当たりました。指示ファイルには当時から「リトライ前に確認を取る」と書いてありました。読まれなかったのではなく、失敗の瞬間にそこに無かったのです。いまは同じ操作が必ず一度止まり、方針が目の前に出ます。止まった AI は目の前の文を読みます。ここでも、読んでいなければ動けない形です。人間が気づいて割り込むころには、リトライは何周も進んでいます。差し込みは 1 周目の入り口に来て、作業の流れのまま向きを変えさせます。

読まなくなったもの

修正履歴です。「前はどう直したんだっけ」と過去のやり取りや失敗の記録を読み返すことも、AI に読み返させることも、「前も言ったよね」と人間が繰り返すこともなくなりました。履歴は方針の数行に絞り込まれていて、届くのは必要な瞬間だけです。

CC BY 4.0

注意: 検知できる問題にしか差し込めない

この仕組みは、リトライのように機械的に検知できる形を持つ問題にしか使えません。検知の書けない新種の失敗には差し込む瞬間がありません。そういうものは外から問われたときにだけ出るので、次回（コマンドの数字）と第 12 回（終わりの問い）の網が拾います。もう一つ、前回と同じ注意です。方針ファイルは数行に保つこと。失敗のたびに 1 行足したくなりますが、同じ対象の行は統合し、差し込まれても効かなかった行は消す。ファイルが育たないことが、この仕組みが機能している証拠です。

検証手順: わざと繰り返させて、止まることを確かめる

前提

方針ファイルを数行で置き、それを cat して差し込む hook を登録し終えていること
検知の条件が決まっていること（本文の例では「同じ名前でのサブエージェントの再起動」）

所要時間: 10 分

手順

AI に、検知の条件に当たる操作をわざと繰り返させます。本文の例なら、1 度起動したのと同じ名前でサブエージェントをもう一度起動させます。1 回目は普通に通ります。確かめるのは 2 回目です

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

操作が実行される前に止まる
止まった場所に、方針ファイルの全文が出ている（要約や「方針を読め」という指示ではなく、中身そのものです）
AI の次の応答が変わる——同じ操作をもう一度試すのではなく、代替案を出すか、あなたに確認してくる

合格しなかったとき

止まらなかった —— 検知の条件が、実際の操作の形と合っていません。hook が見ている文字列を、AI が打った通りの形に直します
止まったが、AI が同じ操作を繰り返した —— 方針ファイルの文が「その瞬間に何をすればよいか」を言えていません。次の一手を書き足します

後始末

手順 1 で起動したサブエージェントを止め、途中まで書かれた成果物があれば消します

次回は「引き継ぎを読まない技術」。AI が書く完了報告を、私は読んでいません。それでも、報告と実際が食い違えば、その場で気づきます。

連載「読まない技術」