--- title: "読まない技術 第9回：引き継ぎを読まない技術" author: garplab publisher: TypingTube license: CC BY 4.0 license_url: https://creativecommons.org/licenses/by/4.0/ license_scope: 「CC BY 4.0」の印から始まる節（仕組み・検証手順・コード）。印の無い本文は著作権を留保 canonical: https://typing-tube.net/articles/a43b57a94d2216 series: "バイブコーディングにおける読まない技術" language: ja --- > この記事は、連載「読まない技術」の第 9 回です。各回はファイルやスクリプトを一つ置けば完結します。連載の全体像と各回の一覧は[序論](https://typing-tube.net/articles/34b02627c718fa)にあります。 今回は、AI が書く引き継ぎ文と完了報告の話です。それを読む代わりに、何を見れば足りるかを扱います。 セッションの終わりに AI が書く完了報告や引き継ぎ文を、私は読んでいません。読んでいた頃に気づいたことがあって、そこには**うまくいったことが書いてある**のです。隠蔽ではありません。要約とは重要度の判断で、その判断は書いた AI の「完了に寄った文脈」で行われます。第 5 回で見たとおり、十数回のリトライは「完了しました」に要約されます。テストを 3 割しか走らせていなくても「テストは通っています」は本当のことです。報告文をいくら丁寧に読んでも、落とされたものは読めません。 でも、数は落ちません。触ったファイルの数、変更した行数、テストの実行件数——機械が数えた数字は、書いた AI の文脈を通らずに出てきます。 理解したことは一文にできます。 > **引き継ぎの文章は書いた側の要約で、都合の悪いものから落ちる。数は要約で落ちない。** ## 仕組み: 報告の隣に、機械の数字を並べる 観測点を決めて、作業の終わりに毎回同じ数字を出すだけです。[typingtube](https://typingtube.net)（YouTube の音楽動画でタイピング練習ができる、個人運営の Web サービス）の開発で私が使っているのは 2 行です。 ```bash # handoff_numbers.sh — 報告の隣に並べる数字。AI の自己申告ではなく機械が数える git diff --stat HEAD | tail -1 # 例: 14 files changed, 512 insertions(+), 40 deletions(-) grep " runs, " tmp/test_last.log | tail -1 # 例: 13950 runs, ..., 0 failures, 228 skips（第 1 回のログから） ``` 読み方は「報告文と数字の食い違いを探す」だけです。違和感という曖昧な言葉を、具体的な観測点に落としておきます。 - 「小さな修正です」という報告の隣に **14 files changed, 512 insertions**——量が合わない - 「テストは全部通っています」の隣に、前回 13,950 だった runs が **9,000**——走っていないものがある（第 1 回で件数の行を削らなかったのは、このための布石です） - 「ログイン処理を直しました」の隣に、変更ファイルの一覧が **決済ディレクトリまで**及んでいる——場所が合わない 大事な条件が一つあります。**数字は AI に報告させない**こと。報告文の中の「3 ファイル変更しました」は要約の一部なので、同じ偏りを受けます。使うのは、AI の文章を経由せずコマンドが直接出した数字だけです。 数字が合っていれば、私は報告を読まずに引き継ぎます。食い違ったときだけ、そこで初めて diff なりログなりの全文を開きます。どれを開けばいいかは食い違った数字が教えてくれるので、探し回ることもありません。 ## 読まなくなったもの 引き継ぎ文と完了報告です。数行の数字との照合に置き換わりました。照合は数秒で、しかも報告文を精読するより多くを拾います——文章に書かれなかったものは文章から読めませんが、数には現れるからです。 ## 注意: 数は「おかしい」までしか教えない 観測点は異常の存在を教えますが、中身は教えません。runs が減った理由が、テストの整理（正しい）なのかロード漏れ（事故）なのかは、開いて読むまで分かりません。この仕組みの役目は判定ではなく、**全文を開くタイミングを人間が決められるようにする**ことです。それから、観測点は少なく保ってください。数字が 10 行並ぶと今度は数字が読まれなくなります。2〜3 個で始めて、一度も食い違いを拾わなかった観測点は外す。ここでも、増やさないことが機能の証拠です。 ## 検証手順: 食い違いが見えることを確かめる **前提** - 観測点を 2〜3 個決め、作業の終わりに毎回その数字が出るようにしてあること（この回の例は、変更ファイル数・変更行数を出す 1 行と、テストの実行件数を出す 1 行です） - ⚠️ その数字が、**AI の報告ではなく、コマンドが直接出したもの**であること **所要時間**: 10 分 **手順** 1. **AI に**、範囲のはっきりした小さな作業を 1 つ頼みます——「`<ファイル名>` だけを直して」 2. **AI が作業している間に、あなたが**、その作業と**無関係な既存ファイルを 1 つ、1 行だけ変えます**。⚠️ これが「報告と実際がずれた状態」の再現です。ずらす側を人の手で作るので、AI に嘘をつかせる必要はありません 3. **あなたが**、作業の後に、AI の報告と機械が出した数字を並べて見ます **合格条件**（すべて満たすこと） - AI の報告のほうは「1 ファイル直しました」に相当する内容になっている - **機械の数字のほうは 2 ファイルになっている**（`2 files changed` に当たる行） **合格しなかったとき** - **数字も報告と同じ 1 ファイルだった** —— ⚠️ その数字は、機械ではなく **AI の文章から来ています。** 数字の出どころを、コマンドが直接出すものへ繋ぎ直します **後始末** - 手順 2 であなたが変えた 1 行を戻します ⚠️ この手順が確かめているのは「食い違いが見えること」だけです。数字は異常の**存在**を教えますが、中身は教えません。開くかどうかを決めるのは、そのあとのあなたです。 --- 次回は「AI に要約しろと言わない技術」。**AI に「まとめて」と言うのをやめました。**それには深い理由があります。 --- **連載「読まない技術」** - ← 前回: [第 8 回 修正履歴を読まない技術](https://typing-tube.net/articles/f7c9c30f567aee) - → 次回: 第 10 回 AI に要約しろと言わない技術 - 全回の一覧: [序論 AIの出力を、もうほとんど読んでいない](https://typing-tube.net/articles/34b02627c718fa)