計画を書けと言わない技術

CC BY 4.0

計画書は 200 本あって、「書いて」と頼んだことは一度もありません

私の手元の本番プロジェクト——typingtube という、YouTube の音楽動画でタイピング練習ができる Web サービスです——には、計画書が 200 本あります。機能ごとの設計メモです。

第 2 回で、この 200 本に番号付きの手順は 0 本だと書きました。今回はもう一方の側です。指示ファイル（102 行）と、コミット時などに割り込む hook 群と、スキルの定義を「計画」で検索しました。「計画書を書け」に当たる指示は 0 件です。指示ファイルが計画書に触れるのは 3 箇所だけで、すべて置き場所の案内でした（「docs/plan/ - 機能計画」）。計画書を書けと求める hook も自動テストも、置いていません。

計画書は 200 本ある。「計画書を書いて」と言ったことは、一度もない。 それでも計画書の側には「ユーザー確定」「ユーザー判断」「ユーザー指示」が 538 箇所、73 本にわたって残っています。

計画書の冒頭は、だいたいこの形をしています。実物です。

# 212 連載記事のサイト内公開（/articles・Zenn と並行掲載）

- 起票: 2026-09-03（ユーザー指示「zenn 向けに書いた連載記事が投稿制限で、
  全て投稿するには 1 ヶ月くらいかかる。最新記事はサイト内で公開したい」）
- 状態: ✅ 実装完了・main へ push 済み

## 0. 先に結論
本文は 1 箇所しか持たない。…

私が渡したのは、引用符の中の一文だけです。「計画書を作って」も「章立ては」も打っていません。次に来るのが ## 手順 ではなく ## 0. 先に結論 なのも、指定していません。

書かれる理由は、指示ではなく、並んでいる計画書のほうでした

測りました。会話を引き継がない作業者（サブエージェント）2 体に（前作の第 1 回と同じやり方です）、まだ実装していない依頼を 1 行だけ渡しました。「単語帳の練習記録を、自分で CSV でダウンロードできるようにしたい」。ファイルは作らせず、最初にやることと、その理由を答えさせました。

2 体とも、5 手の最後に「計画書を書く」を置きました。 番号は次の 215、体裁は既存と同じ、書く時点は現状を掴んだ直後でコードに触れる前。頼んでいません。根拠として挙げたのは、指示ファイルに「書け」の明文が無いと確かめたうえで、既存の計画書が同じ体裁で 200 本並んでいることでした。1 体は置き場所の案内の 1 行も挙げましたが、決め手は現物のほうだと答えています。

もう一つ、同じやり方で、実装済みの依頼をわざと渡しました。「一覧に並び替えを足したい」。2 体とも既存の実装と計画書を見つけて、計画書は書かないと答えました。書けと言われていないので、要らないときは書きません。

Anthropic のモデル別のプロンプト指針は、この振る舞いをはっきり書いています。

Opus 5 は、完全なタスク仕様を前もって与えて、あとは走らせるのが最も良い。

仕様であって、指示ではありません。揃っていないときに「まず計画を出して」と打つと何が起きるか——返ってくるのは、欠けた前提を埋めた計画です。埋めたのは AI で、私ではありません。

理解したことは一文にできます。

計画は、頼まれるから書かれるのではない。書かれた計画が、次の計画を呼ぶ。だから頼む代わりに、書かれた計画をそのまま残しておく。

仕組み: 新しく置くものはありません

置くものはありません。置いてあるのは、計画書 200 本そのものです。

最初の 1 本は、私が書かせたのかもしれません。git で一番古い計画書の日付は、指示ファイルに置き場所を書いたのと同じ日です。2 本目からは、1 本目が呼びました。AI は着手の前に既存の計画書を読み、同じ体裁で次の番号を取ります。頼まれるからではなく、前例がそうなっているからです。

書かずに終えることもあります。 それは、要らないケースです。2 体が引いた線引きは同じでした——新しいテーブル・新しい画面・仕様の判断があれば計画書、1 セッションで閉じて次に引き継ぐものが無い修正なら、何も残さない。6 月以降のコミット 1,177 件のうち、件名に計画書を挙げていないものは 508 件でした。

メモリだけに書くこともあります。 恒久の制約や、繰り返す行動の教訓は、計画書ではなくメモリに行きます。手元のメモリは、計画書と同じだけ手を掛けてあります。保存前のチェックリスト 5 項目（価値・恒久性・重複・整合・承認）と、保存の直後に差分を突きつける hook（「読まない技術」の第 7 回）。だからメモリに書いた判断は、計画書と同じように次のセッションが読みます。

CC BY 4.0 はここまで

CC BY 4.0

注意: 最初の 1 本は、蓄積ではありません

一つ、最初の 1 本は、誰かが書きます。 前例がゼロのときに何が起きるかは、測っていません。試すなら、使い捨ての clone で計画書を全部退避して、同じ依頼を渡してみてください。

二つ、指示ファイルには、置き場所を案内する行が 3 行残っています。 「書け」とは言っていませんが、2 体のうち 1 体は、この行も根拠に挙げました。この行を消した状態は、測っていません。

三つ、計画書が集めるのは事実と判断の記録で、何を作るかは決めません。 538 箇所の判断は、いまも私が書いています。この回がやめたのは計画を要求することであって、計画を決めることではありません。

検証手順: 頼まずに渡して、書かれるかを見る

前提

• 手元に計画書が数本以上たまっていること（前例が 0 本の状態では、この検証は何も測れません）
• 会話を引き継がない場所を 3 つ用意できること（サブエージェント 3 体か、新しいセッション 3 つ）

所要時間: 20 分

手順

1. 1 体目に、あなたが、まだ実装していない依頼を 1 行だけ渡します（「単語帳の練習記録を CSV でダウンロードできるようにしたい」）。⚠️ ファイルは作らせません。 「最初にやることと、その理由を答えて」とだけ頼みます。⚠️ 「計画書は要りますか」と聞かないでください。 要るかどうかを尋ねると、答えは尋ねた側の前提に寄ります。何をするかを答えさせます
2. 2 体目に、あなたが、すでに実装済みの依頼をわざと渡します（既にある機能を「作りたい」と言います）
3. 3 体目に、あなたが、手順 1 と同じ依頼に「まず計画を出して」を付けて渡します

合格条件（すべて満たすこと）

• 手順 1 で、答えた手順の中に計画書を書くことが入っている
• 手順 1 で、その根拠として既存の計画書が並んでいることを挙げる
• 手順 2 で、既存の実装と計画書を見つけて、計画書を書かないと答える

合格しなかったとき

• 手順 1 の根拠が「指示ファイルにそう書いてあるから」だった —— あなたの手元には、まだ「書け」の指示が残っています。探して消せる行です
• 手順 2 でも計画書を書くと答えた —— 手順 1 の結果は「いつでも書く」であって、判断ではありません

手順 3 で見るところ（こちらは合否ではありません）

• 返ってきた計画の中に、あなたが決めていない前提が埋まっている箇所が無いか。⚠️ 埋めたのは AI で、あなたではありません。それがこの回の主題です

後始末

• 要りません。3 体ともファイルを作っていません

CC BY 4.0 はここまで