Claude Code にチェックリストを作らせたのに、実行させていなかった — 「作成」と「実行」を分離させない設計にした記録

はじめに

「絶対に忘れるから、チェックリストを作ってから実施しろ」——AIコーディングアシスタントに、こう指示したことがある。作業のたびに「そもそも何を解決しようとしていたか」を見失う場面が繰り返し起きていたからだ。

指示どおりチェックリストは作られた。だが、そのチェックリストが実際に使われたのは、指示から数ステップ後、もう一度同じ指摘をしてからだった。「作る」ことと「使う」ことは別の作業で、片方をやっても、もう片方が自動でついてくるわけではない。 この記事は、その間に何が起きたかと、二度と同じ抜けを起こさないためにどう設計を変えたかの記録だ。

作られたチェックリスト

指示どおりに出てきたのは、次の3段構えのチェックリストだった（実際の記録から、内容を変えずに再掲する）。

フェーズ	確認すること
A. 着手前（1回だけ）	①発端の指示を1行で書き出せるか　②「何がどうなれば解決か」を測れる形で書いたか（値・単位・比較対象）　③今の値（before）を先に測ったか
B. 途中で別の課題が見ついた時（毎回）	①それは発端の解決に必要か、単に見つけただけか　②副次課題なら着手前に持ち出す　③着手するなら「後で戻る先」を書き残す
C. 報告する前（毎回）	①冒頭が発端への答えになっているか　②改善後の値（after）を測ったか　③やったことが発端に効かないなら、そう言う　④未解決なら次の一手を測定手段つきで出す

要は「何を解決したいかを先に固定し、直した後は必ず数字で確かめてから報告する」という、当たり前と言えば当たり前の手順だ。当たり前すぎる手順ほど、忙しい時に飛ばされる。

チェックリストの、いちばん肝心な項目が飛ばされた

チェックリストが作られた後の作業で、実際に何が起きたかを追う。

発端＝「応答が遅い」を改善する作業を進めた
途中で見つかった副次課題（記憶ファイルの置き場の整理）に着手し、そちらを完了させた
副次課題の完了を報告した
肝心の発端の指標（改善後の応答速度）は、一度も測っていなかった

チェックリストのC（報告前）には「改善後の値を測ったか」という項目が明記されていた。にもかかわらず、その項目を素通りして「対応できました」という趣旨の報告が出た。チェックリストは存在していたが、報告を書く手が、それを開いていなかった。

指示「チェックリストを作ってから実施しろ」
        │
        ▼
  チェックリストが作られる（ファイルとして存在する）
        │
        ├─▶ 発端の作業を進める
        │        │
        │        ├─▶ 副次課題を見つける
        │        │        │
        │        │        └─▶ 副次課題を完了させる
        │        │                  │
        │        │                  ▼
        │        │            「対応できました」と報告
        │        │                  │
        │        │                  └── ここでC-2（after測定）を
        │        │                      一度も開いていない ◀── 抜け穴
        │        │
        │        └─▶ 発端の指標（改善後の速さ）は未測定のまま
        │
        └─▶ チェックリストファイル自体は、参照されずに存在し続けている

「ファイルとして存在すること」と「その瞬間に参照されること」は別の状態だ。存在するだけのチェックリストは、思い出さない限り効かない。

もう一度指摘して、初めてC-2が実行された

もう一度指摘して、今度はチェックリストのC-2（改善後の値を測る）を実際に実行させた。すでに存在していた状態管理用の台帳ファイルの中身も、実際の測定値に合わせて書き直させた。

その結果、初めて意味のある数字が出た。修正の投入時刻でログを区切り直し、区間ごとに測り直したところ、通常運用13日間の中央値16.04秒に対し、修正がすべて反映された区間（n=19）の中央値は10.48秒だった。チェックリストの手順どおりに測って初めて、直したのか直っていないのかが分かった。

数字そのものの詳細と限界（サンプル数が小さいこと等）は、技術的な結末をまとめた別記事に書いた。

Claude Code の初回応答を16秒から10秒に縮め、フリーズを0件にした — プロファイラで四つの無駄を解体した記録

「作る」だけでは足りない、という設計に直す

ここで直したのは、チェックリストの中身ではない。**チェックリストの「置き場所」と「報告の書式」**だ。

もともとのチェックリストは、他の多くの記録と同じ場所に、他の記録と同じ扱いで置かれていた。特別に目立つ場所にはなく、開くかどうかは思い出せるかどうかに懸かっていた。これを次の2点に変えた。

毎回の作業開始時に自動で読み込まれる索引の、最上位に置く。 「後で参照する資料」ではなく「作業を始める前に必ず目に入るもの」に格上げした。
C-2の結果を、曖昧な言葉で書けないようにする。 「改善しました」ではなく、「改善後の値を測った/測っていない」のどちらかを明示させる。測っていないなら「未測定」とそのまま書くことを許可し、代わりに「改善した」という言い切りを禁止した。

これは、以前に作った別の仕組みと同じ発想の延長にある——助言として置くだけでは守られない規律を、通り道そのものに埋め込む、という考え方だ。

AIコーディングアシスタントに「やらせない」仕組みを作る — 助言から強制へ、そして関門に空いていた横穴

個人用のナレッジベース（RAG）側でも、同じ理由で「点検の実行そのものを強制する仕組み」を作ったことがある。

個人RAGの健全性を、意志でなく仕組みで毎週点検する — 多角ヘルスチェックと、その実行を強制する時限ゲート

この工夫の限界

今回の直し方は、コードレベルで実行を強制する「かたい」仕組みではなく、「毎回目に入る場所に置く」という、あくまで見え方の工夫にとどまっている。索引ファイルが肥大化して読み込まれる範囲から外れれば、また同じように埋もれる可能性がある。また、今回この工夫が効いたと言えるのは、C-2を実際に実行して数字が出たという1回分の事例だけだ。次に同じ状況が来たとき、今度こそ最初からC-2まで通せるかどうかは、まだ確かめていない。

チェックリストを作ることは、達成ではなく出発点だった。その一文自体が、このチェックリストのA-1（発端を1行で書き出す）で本来いちばん最初に書くべきことだった。