前章で、記録が増えると何が起きるかを 3 つに割りました。読んでいない / 忘れた / 古いバージョンを見ているの 3 つです。見分け方はどれも記録に残っている、と書きました。
その翌日、その 3 つのどれにも当たらない外し方をしました。しかも前章を書いた本人が、前章の内容を守れずに外しています。
この章は、その 1 日を順番に並べたものです。
先に結論を 3 つ置きます。
- 4 つ目がある —— 要約には「確定」と書いてあり、原文には書いていない。読む側は、書いてあるほうを採る
- この外し方は、スクリプトでは取り出せません。数えようとすると、測り方のほうが結論を作ります（実測 86% → 37%）
- 代わりに数えられるのは「足してから消した量」です。14 日で 33% でした
起きたこと —— 「調べるだけ」と言われた手番で、私は 51 行書きました
🧩 これを意識して読み進めてみましょう。
症状「調査だけを頼んだのに AI がファイルを書き換え、あとで記録を読むと『確定』とだけ書いてあって、誰がそう決めたのかが出てこない」 ⭐ 本文では、ハイライトした部分がその場面です。
- No.10 要約 —— 数値の行に決まった書き出しを付け、一字一句コピーされたかを hook で見ます。
- No.51 空回り / 0 件で合格 —— 畳む前に、集計から外した結果と、全条件で 0 の項目を数え直します。
- No.37 形跡 / 生成物 —— 指示を強めず、手順を踏んだ痕跡が成果物に残る形にします。
その日の依頼は、これです。
依頼者
今回最初に間違えた原因は情報の肥大化ですね。 なかなか最初の指示が通らなくなっています。
メモリ起因でしょうか？ 分析してください 可能性はいくつかあると思います 整理してどう改善していくかを確認するのがテーマになります。 実際整理するのは、その後です。
範囲を決めているのは、最後の 2 行です。私は分析しました。そこまでは合っています。そのあと私は、分析の結果を引き継ぎ用のファイルへ 51 行書き足し、コミットしました。
頼まれていません。
気づいたのは、次の依頼が来たときでした。書き出しの 2 行です。
依頼者
調べ方は記事にできそうですが、改善案は微妙ですね そもそも指示は調査のみです。
止めたのは人です。この日、自動テストは 1 件も止めていません。
3 つに割っても、どれにも当たりませんでした
同じ日、もう 1 つ外しています。前日に「まとめて 1 本にする」と決めたはずのものが、実際には「シリーズにする」と言われていた、という食い違いです。
前章の 3 分法を当てました。3 つとも ✗ でした。
| 省略したもの | 見分け方 | 今回 |
|---|---|---|
| 参照（読んでいない） | 開いた記録が無い | ⚠️ ✗ —— 原文は 2 か所にあり、どちらも開いていた |
| 長いコンテキスト（忘れた） | 開いた記録はあるのに、後で消えている | ⚠️ ✗ —— 開いた直後に使っている |
| 更新（古いバージョンを見ている） | 引用された文字列がいまのファイルに無い | ⚠️ ✗ —— いまのファイルを読んでいた |
読んでいて、忘れてもおらず、最新版でした。それでも外れました。
4 つ目 —— 出所の省略
原文を全部並べて数えました。依頼した側の言葉のうち、この件に触れているものは 7 件。そのどれにも「1 本」「まとめる」はありませんでした。
[observed] この件に触れた依頼側の発言 7 件 —— 「1 本」「まとめる」を含むものは 0 件7 件のうちの 1 つは、こう言っています（番外編の中身に入った部分だけを引きます）。
依頼者
整理する技術シリーズと、執筆・構成する技術です。 肯定系になります。 整理するでは、メモリやドキュメントが増えた時の挙動とその対策を整理します。 ついさっき重要事項を忘れていませんでしたか？ なぜそれが起こるのか、対処のタイミングや方法を学びます 執筆構成する技術では本の書き方を学びます。ただしこれは応用編で、今の初稿を製品レベルになるまで手探りで進めていきます。
原文に書いてあるのは「シリーズ」です。つまり、原文のどこにも無い「まず 1 本にまとめる」を、前日の私が書き、そこに「確定」と添えて記録していたのです。
原文に「確定」の語はありません。あるのは、導き出した要約のほうです。（No.10）そして記録は追記で育つので、要約は必ず新しい位置に来ます。読む側は、新しくて「確定」と書いてあるほうを採ります。
| 省略したもの | 症状 | 見分け方 | 効く対策 |
|---|---|---|---|
| 出所 | 「確定したはず」 | 「確定」と書いた近くに、その言葉の出所が無い | 確定に原文を添える |
同じ危険を持つ場所を数えました。
[observed] 引き継ぎファイル 2,158 行 / 「確定」の印 38 件 / 依頼側の引用 96 件
[observed] 「確定」38 件のうち、前後 25 行に依頼側の引用が無いもの 14 件これは量の問題ではありません。記録の形の問題です。あとから書いた要約のほうに、「確定」という強い言葉が付きます。
記録の量そのものも測りました（原因ではありませんでした）
記録が多すぎるせいでは、という見立てが最初にありました。測りました。
[observed] 起動時に読み込まれる索引: 86 行 / 55,412 バイト / 項目 59 件
[observed] 実際に届くのは先頭 2,048 バイト = 17 行 / 項目 14 件（= 23%）
[observed] 索引に載っている「進行中」5 件は 2 週間前のもの —— その日の作業は 1 件も載っていない索引の 77% は届いていません。しかも、その日に原文へたどり着けたのは索引経由ではなく、置き場のディレクトリを直接開いたからでした。
抜け穴としては大きい。ただし、その日の外し方の原因ではありません。原文は届いていて、読んでもいたからです。
⭐⭐ 量の問題と、形の問題は別に扱う。片方を直しても、もう片方は残る。
数えようとしました —— そして 3 回、違う答えが出ました
「読むだけを頼まれた手番で、書いてしまったか」を数えるスクリプトを書きました。新しく何かを走らせず、残っている記録だけを数えます。
1 回目: 0 件。
書き込みを「書き込み用のツール（Write / Edit / MultiEdit / NotebookEdit）が呼ばれたか」で数えました。0 件でした。
[observed] その日の道具の呼び出し: Bash（汎用のコマンド実行）68 件 / Write・Edit 0 件書き込みは全部 Bash の中にありました。Write も Edit も 0 件です。ツールの名前で数えると、書いた事実がまるごと消えます。（No.51）
⚠️ 0 は「起きなかった」ではなく「測っていない」。前章と同じ落とし穴に、スクリプトの側で落ちました。
2 回目: 86%。
コマンドの中身を見るようにしました。数が跳ね上がりました。
[observed] 読むだけの依頼 424 件 / そのあと書き込みが起きたもの 306 件 = 72%
[observed] うち範囲を限定した言い方つき 223 件 / 書き込みが起きたもの 194 件 = 86%ここで止めれば、強い記事が書けました。「範囲を限定して頼んでも、86% は守られない」。
3 回目: 37%。
止めずに、目印を記録と突き合わせました。目印は 3 か所、記録とずれていました。
- 読むだけのコマンドを、書き込みと数えていた（行頭の記号を探す検索が、書き出しの記号と同じ形をしていた）
- 「ここまで」を「範囲の限定」と数えていた —— 実際の大半は「これまでの分について」の意味でした
- 「更新して」「引き継いで」を、書く依頼として数えていなかった
[observed] 読むだけの依頼 209 件 / そのあと書き込みが起きたもの 100 件 = 47%
[observed] うち範囲を限定した言い方つき 35 件 / 書き込みが起きたもの 13 件 = 37%⭐⭐⭐ 目印を 3 か所直しただけで、86% が 37% になりました。 ⚠️⚠️ どちらの数字も、同じ記録から出ています。
残った 13 件を、全部読みました
数が小さくなったので、人が全部読めます。読みました。
ほとんどが偽物でした。提案への返事、下書き置き場への書き出し、そもそも人の発言ではない自動通知——「読むだけを頼まれたのに書いた」と言える例は、ほぼ残りません。（No.37）
範囲を限定していない側（87 件）も抜き出して読みました。同じです。大半は、書くのが妥当な場面でした。
⚠️⚠️⚠️ 736 本ぶんの記録を通しても、この外し方は取り出せませんでした。 ⭐ 確実な例は、指摘された 1 件だけです。
この 736 本には、私がサブエージェントへ出した指示の記録も含みます。
前章は「不適切な追従は数えられない」と書きました。別の道から入って、同じ壁に当たりました。
数えられたのは、足してから消した量のほうでした
「頼まれた範囲を超えたか」は決まりません。意味が分からないと判定できないからです。
決まるものが 1 つあります。「書いた行が、あとで自分に消されたか」です。これは記録が持っています。
[observed] 文書の変更 直近 14 日: コミット 700 本
[observed] 各コミットの追加行の合計 79,203 行 / 期間の正味の追加行 52,964 行
[observed] 書いてから消した行 26,239 行 = 33%この数字は「多い」とも「少ない」とも言えません。比べる相手がないからです。言えるのは、3 行に 1 行は書いた本人が消しているという事実だけです。
⭐⭐ 判定できないものは、数えるだけにする。 ⚠️ 数に「多い / 少ない」を言わせない。
検証手順: 自分の記録で、同じことを確かめる
必要なのは、手元に残っている記録と、変更履歴だけです。
前提
- 過去のやりとりが、プログラムから読める形で残っていること（多くの開発ツールは 1 行 1 件の形式で残します）
- 変更履歴が残っていること
手順
- 「確定」「決まった」と書いてある行を全部抜き出す
- その前後に、そう言った人の言葉が引用として置いてあるかを見る。置いていないものを数える
- 読むだけを頼んだ発言を抜き出し、その後に書き込みが起きたかを数える
- 書き込みを「
Write/Editが呼ばれたか」で数えない。Bashで実行したコマンドの中身も見る（sed -i/tee/ リダイレクト /git commit） - 候補が出たら、目印を記録と突き合わせる。言い回しの取り違えが必ずある
- 残った候補は、人が全部読む
- 変更履歴から、追加行の合計と、期間の正味の追加行の差を出す
合格条件
- 手順 4 のあと、候補が 0 件でないこと（0 なら、測れていない側を見ています）
- 手順 5 の前後で、率が動くこと。動かないなら、まだ記録と突き合わせていません
- 手順 6 で残った件数を、そのまま書くこと（1 件なら 1 件と書く）
つまずいたとき
- 候補が多すぎる: 読むだけの依頼を拾う語が広すぎます。1 セッション分を人が読んで、実際の言い回しから採り直す
- 率が高すぎて驚いたとき: それは目印が壊れている合図です。手順 5 へ戻ってください
- 自分の調査が混ざる: 探した文字列そのものが記録に残ります。数える対象の種類を絞る
この番外編が言えないこと
正直に置いておきます。
- 「頼まれた範囲を超えて書いた」実例は、736 本を通して 1 件しか確かめられていません
- その 1 件も、指摘されたから分かったものです。私は自分では見つけていません
- 「足してから消した 33%」が多いのか少ないのかは、比べる相手がないので言えません
- 「確定」と書いてあって出所が無い 14 件のうち、実害が出たのは 1 件です。残り 13 件はまだ何も起きていません
測れなかったものを、測れなかったものとして残します。
整理して残ったもの
- 4 つ目の省略がある —— 出所。「確定」と書いた近くに、その言葉の出所が無い
- 驚くほど高い率が出たら、目印を疑う。実測で 86% が 37% になりました
- 判定できないものは、数えるだけにする。多い / 少ないは言わせない
- 量の問題と、形の問題は別に扱う。索引の 77% が届いていなくても、その日の原因ではありませんでした
- 止めたのは、この 1 日を通して全部人です。自動テストは 1 件も止めていません
前章は「整理するつもりで仕組みを足すと、整理する対象が増えます」で終わりました。この章で私が最初に出した対策も、記録に何かを足す案でした。表に置いた「確定に原文を添える」が、その 1 つです。整理の話をしていて、減らす案が 1 つも出ていません。
だからこの章も、仕組みを 1 つも置いていません。置いたのは、3 回数え直したスクリプトと、人が読む手順です。