作業結果を読まない技術

CC BY 4.0

なぜ、これだけ自動化しないのか

「毎回同じ一言なら、終了時の手順に組み込めばいい」と思うはずです。私も思いました。やらない理由が二つあります。

一つ。問いを手順に組み込むと、問いが作業の一部になります。 セッションの終わりの AI の文脈は「完了」に寄っています。完了に寄った文脈の中で発生する「不足点はありますか」は、完了報告の続きとして処理される——つまり、報告と同じ偏りを受けます。人間が外から打てば、前回の話が反転します。人間の指示は何よりも優先される——作業の途中では、それは進行中の優先順位を壊す力でした。作業が終わった今は、壊すものがありません。完了に寄った文脈を貫いて、新しい最優先の問いとして届く力だけが残ります。

二つ。「終わり」の判定は人間にしかできません。 自動化するなら何かをトリガーにする必要があり、それは実質「AI が完了を宣言したとき」になります。「終わったつもり」を起点にした確認は、終わったつもりの中身しか確認できません。

正直に添えると、一つ目は試して劣化を確かめたわけではなく、構造上そうなるはずだという推測です。ただ、この問いはセッションに 1 回・数秒のことなので、自動化で節約できるものが元々ほぼありません。節約がゼロに近いなら、偏りのリスクだけが残ります。

この問いが、シリーズ全体を支えている

もう一つの役割のほうが重要かもしれません。ここまでの各回の仕組みで拾えなかったものは、全部ここに現れます。

テストの要約は失敗以外の異常を隠すかもしれない（第 1 回）。数か所の変異は抜き取りにすぎない（第 3 回）。ガードレールは名乗りを止められない（第 5 回）。自動テストは機械が真偽を決められるルールしか持てない（第 6 回）。観測点は決めた数字しか見ない（第 9 回）——各回で正直に書いてきた死角は、どれも「これで全部拾える」とは言っていません。言わずに済んだのは、最後にこの問いがあるからです。「その仕組みでは漏れる」という指摘は正しくて、答えはいつも同じです。仕組みからこぼれたものは、最後にこの問いで拾います。

ただし、この問いは主役ではありません。答えるのは作業した本人の AI なので、網の目は粗い。拾う本体はあくまで各回の仕組みと観測点で、この問いは、それでも残ったものが言葉になって出てくる最後の受け皿です。

CC BY 4.0 はここまで

CC BY 4.0

検証手順: 今日の終わりに、一度問う

前提

• 置くものはありません。設定も要りません
• 今日の作業が一区切りついたセッションが 1 つあること

所要時間: 3 分

手順

1. AI が「完了しました」と言った後で、あなたが、下の一文をそのまま打ちます。
2. あなたが、返ってきた不足点の数だけを数えます。中身は読まなくて構いません

ここまで不足点はないですか？確認して不足点がなければ次のセッションに引き継いでください

⚠️ 完了の報告より後に打ってください。 作業の途中に打つと、進行中の優先順位を壊す割り込みになります（第 11 回）。⚠️ 言い換えないでください。「不足点を洗い出して報告して」にすると、不足があるという前提が一緒に渡ります

見るところ（合否ではなく、数で分かれます）

• 1 件以上出た —— この問いは働いています。⚠️ 確かめてほしいのは中身の妥当性ではなく、この一文を打たなかったら、それらがどこへ行っていたかです。どこへも行きません。セッションと一緒に消えていただけです
• 0 件だった —— 今日は仕組みが全部拾ったか、AI が完了に寄った答えを返したかの、どちらかです。1 日では区別が付きません。 数日続けて 0 件が並んだときだけ、問いの文言を疑います

後始末

• 出た不足点は、AI にそのまま処理させます。処理しきれないものは、次のセッションへの引き継ぎに書かせます
• ⚠️ あなたが中身を読んで判断する工程は、ここにはありません

CC BY 4.0 はここまで