判断を消す手順ノート
100日に1回ぐらいの頻度でしか回ってこない仕事があります。飛行機の予約、出張の段取り、電源タップの全面交換。前回やったことがあるのだから簡単なはずなのに、いざ取りかかろうとすると、何をどうやったのか全然覚えていない。思い出す負荷が高いぶん、余計に億劫になります。
億劫さの正体は、作業そのものの重さとは別のところにありました。AIと一緒に手順を書き出してみると、覚えているつもりの手順が想像以上に多い。人は自分の認知能力を過大評価します。この程度のことは身体化している、という思い込みです。実際には毎回頭の中で組み立て直していて、その組み立て直しの負荷が、手が動かない理由でした。
達成点を「読めば思い出せる」から「判断が消える」へ移す
手順ノートを1回作るのは、気分の上では10時間かかるような苦痛があります。それでも作ってしまえば、2回目からはノートを開いて実行するか、AIに任せるだけになる。判断を毎回ゼロから組み立てる仕事が、読んで実行するだけの仕事に変わります。
だから達成点は「読めば思い出せる」ではありません。索引ノート・手順書・引き継ぎ書のように何度も開かれるノートは、書き手が整理した気になるための道具ではなく、次に開く人が動くための道具です。うまく書けたかどうかは書き手の手応えでは分からず、開いた人が動機・現状・次の行動を読み取って、そのまま手を動かせたかで決まります。
実務をAIへ渡す全体の設計と、AIの下書きを直せば手順書が作れることは、別のページ（AIに日常のオペレーションを任せる）にまとめました。
次に開く人は、書き手の前提を持っていない
次に開くのは、半年後の自分かもしれないし、別セッションのAIかもしれないし、他人かもしれない。どれも書き手の頭の中にあった前提を持っていません。書き手の中で自明な動機・目的・状況は、わざわざ書くまでもないと判断されてノートに残らないからです。半年後の自分はその判断がどんな場面で下されたかを知らないので、自分から探しに行っても元の前提には届きません。
対象は限定されます。走り書きやその場限りのメモまでこう書く必要はなく、この縛りを受けるのは繰り返し開かれるノートだけです。
読まないと手順が壊れるものだけを本体に残す
前提を持たない読み手へ届かせようとすると、書き足したくなります。ところが本文へ骨格サンプルや例外条件を書き込むほど、1画面で全体が見えなくなる。全体が見えないと「今どの手順にいるか」の位置確認に認知コストがかかり、手順を辿る速度が落ちます。届かせるために足したものが、届く速度を落とすわけです。
判定はひとつで足ります。辿らなくても手順が回るものは外へ出し、読まないと手順が壊れるものは本体に残す。
外へ出す側は、骨格サンプル、前例コード、優先度の解説、例外条件です。どれも前例がないときや判断に迷ったときだけ参照する情報なので、別ファイルに出してリンクで繋ぎます。本体に置くのは「前例がないときだけ骨格サンプルを見る」の1行で済みます。
残す側は警告です。「○○するな」「この順序を変えるな」のような一行は、リンク先へ飛ばないと見えない場所に置くと、急いでいるときほど見落とされます。本体を短く保つ中でも、警告の1行だけは削りません。
残った索引の並べ方も決まります。ノートを開いて最初に目に入る領域には、今回の実行に必要な判断を置く。運用ルールや固定情報は、スクロールした先に並べます。探す手間が生まれるのは、書き足しを重ねた結果、最も重要な情報が先頭から外れたときです。
リンクで詳細へ飛ばす設計は、AI側の読み取りを妨げません。人間がこうしたノートに求めるのは「今どうなっているか」の即時把握であって、詳細な手順や履歴ではない。一方でAIはリンク先を自動で辿って中身を読むのが得意なので、本体へ詳細を凝縮する理由が消えます。この非対称があるから、詳細を子ノートへ分離して短い索引とWikiLinkだけを残すのが、人間にもAIにもいちばん合う形です。
逆に、動画の管理ノートへ進行チェック表を足したときには、一覧性が壊れました。
事前に書けるのは事実で、書き方の型は書けない
削ったあとに残す大枠は、ゴール・素材・流れです。事前に書ける詳細は、対象ファイル・照合先・固有名詞のような事実だけで、書き方の型や分量や文体や条件分岐は、実運用で何度か回すまで決まりません。先取りで書けば想像で埋まり、実態とずれて補足カッコが連鎖します。大枠だけ残せば、ノートの長さは半分以下で済みます。
書き方の型は、ファーストビューにも書きません。そこへ置く「今回の実行に必要な判断」は、この事実の側です。
切る場所は工程の大きさではなく同期点で決まる
削っても1画面に収まらないなら、切ります。目印になるのは工程の大きさではなく、処理が一旦止まって状態が確定する地点です。人間への確認、別スキルの呼び出し、外部への引き渡し完了。こうした地点を同期点と呼びます。
同期点の手前まではAIが自律的に進められるので、そこまでは1ファイルでかまわない。跨いで1ファイルにすれば、別セッションで再開したときに「どこまで終わったか」の判定が要ります。切れ目を同期点に合わせておけば、各ファイルは未着手か完了かの2値で状態管理できます。
切る場所が見つからないときに見るのは、タイトルに並んだ動詞の数です。「精読してドラフトを書く」のように動詞が2つ並ぶ手順タイトルは、1ファイルに2工程が詰まっています。動詞が2つある手順は、たいてい間に人間の確認や別スキルの呼び出しが入るので、そこが分割の境界です。
全工程をAIが実行すると、残るのは確認ポイントだけ
従来の手順書は「誰がやるか」を軸にしていました。人間がやる工程とAIがやる工程を区別するマーカーが要り、工程ごとに担当を明示していた。全工程がAI担当になるとこの区別は消え、手順書に残るのは「どこで人間の確認を挟むか」だけになります。手順書の骨格は、切る位置を決めた同期点です。
動画の処理手順は、担当マーカー付きの旧6ステップから、確認待ちだけを明示する新2ステップへ変わりました。工程そのものは同じで、書く必要のある区切りが確認ポイントだけになった結果です。
削って足りなかった分は次の実行で書き足す
削る判断は当てにいかなくて構いません。手順ノートは書いた時点で不完全でよく、1回やって記録を残し、AIに整理してもらい、次回また記録を足す。実行するたびに「ここが足りなかった」「この順番のほうが速い」と分かるので、その分だけ手順の精度が上がります。削りすぎた分も、そのサイクルで書き足せます。だから思い切って削れる。
次にその低頻度の仕事の手順ノートを開いたときには、その場で判定できます。各行が、辿らなくても手順が回るものか、読まないと手順が壊れるものか。ファーストビューに今回の実行に必要な判断が来ているか。切るなら同期点はどこか。
飛行機の予約も、出張の段取りも、電源タップの全面交換も、一度そこまで削っておけば、次に開いたときには覚えていなくても手が動きます。