AIに渡す計画書の見直し方｜CLAUDE.md の書き方と要件の決め方

なぜ計画書を見直すのか

ここでいう計画書は、AIエージェント（指示を受けて、コードを書いたり動かしたりするAI）に渡す文書全体を指します。Claude Code の CLAUDE.md、Codex などが読む AGENTS.md、Cursor のルール、Lovable の Instructions、それに要件のメモや方針のメモです。

AI はこれらを読んでから作業します。ただし、書いたことが必ず守られるわけではありません。Claude Code の公式の説明では、CLAUDE.md は強制される設定ではなく、参考に読む情報（文脈）として扱われます。2つの指示が食い違っていると、AI がどちらかを適当に選ぶことがあるとも書かれています。

同じ説明では、思っていたものと違うものができる原因の多くは、コードを読んでも分からない情報が AI に足りないことだとしています。書いていないことは、AI が自分で決めます。その決め方が意図と違っていても、画面は普通に動くので気づきにくいのです。

道具ごとの置き場所

道具	ファイルや設定	公式の目安
Claude Code	プロジェクトの `CLAUDE.md`（または `.claude/CLAUDE.md`）、自分用の `~/.claude/CLAUDE.md`、共有しない `CLAUDE.local.md`	1ファイル200行未満
Codex	`AGENTS.md`（リポジトリの直下や下のフォルダ、`~/.codex`）	合計の大きさは標準で32KiBまで
Cursor	`.cursor/rules` の `.mdc` ファイル、`AGENTS.md`	1つのルールは500行未満
Lovable	Project settings → Instructions（以前の名前は Knowledge）	10,000文字まで

Claude Code は AGENTS.md も読めます。複数の道具を使うなら、どのファイルが読まれているかを先に確かめておくと、古い指示が残ったままになるのを防げます。

観点1：目的と「作らないもの」

最初に確かめるのは、誰が何のために使うかと、今回は作らないものです。

誰が使うか（自分だけ、知り合いの数人、一般に公開）
何ができたら完成か（例：「会員が自分の予約を登録・取り消しできる」）
今回は作らないもの（例：決済、管理者の画面、英語対応）

「作らないもの」を書いておくと、完成の範囲について、AI と自分の考えがずれにくくなります。使う人の範囲は、必要な守りの強さを決めます。自分だけで使うものと、知らない人が登録するものでは、確かめることが大きく違います。

観点2：データと権限

計画書でいちばん抜けやすいのが、データを誰が見て、誰が変えられるかです。次のような表を計画書に入れておくと、AI がデータベースの設定を作るときの手がかりになります。

データ	見られる人	変えられる人
予約	本人と管理者	本人（取り消しだけ）と管理者
教室の情報	誰でも（ログイン不要）	管理者
会員のメールアドレス	本人と管理者	本人

「本人だけ」「ログインした人全員」「誰でも」の違いを、データごとに書くのが大事です。Supabase を使う場合は、この表がそのまま RLS（行単位のアクセス制御）の設定のもとになります。確かめ方は「Supabase の RLS が効いているか確認する方法」にまとめました。

個人情報やお金を扱うかどうかも書いておきます。扱う場合に法律上何が必要かは、計画書や AI の答えで決めず、公式の案内や弁護士に確かめてください。

観点3：完成をどう確かめるか

「ちゃんとテストする」のような書き方では、AI は何をしたら終わりなのか判断できません。Claude Code の公式の説明では、確かめられるくらい具体的に書くよう勧めていて、次のような例を挙げています。

あいまいな書き方	具体的な書き方
変更を確かめる	コミットの前に `npm test` を実行する
ファイルを整理しておく	API の処理は `src/api/handlers/` に置く
コードをきれいに整える	インデントは空白2つ

同じ説明では、テストやビルドの結果のように「合格か不合格か」が分かる確かめ方を渡すと、AI が自分で直しながら進められるとしています。AI が「全部通りました」と言ったときは、実行したコマンドとその出力という証拠を求めるよう勧めています。

テストのコードが書けなくても、「この手順で操作したら、この結果になる」という確認の手順を文章で書いておけば、完成の基準になります。2つのアカウントで他人のデータが見えないかを試す、といった確認もここに入れます。

観点4：必ず守らせたい決まりは設定で止める

「本番のデータは消さない」「秘密の鍵が入ったファイルは読まない」のように、例外があっては困る決まりもあります。Claude Code の説明では、CLAUDE.md の指示はほとんどの場合に守られるものの、守るかどうかは毎回 AI の判断だとしています。必ず守らせたいものは、hooks（決まった時点で自動で動く仕組み）や、操作を禁止する設定（deny ルール）で止めるよう勧めています。

計画書を見直すときは、決まりを2つに分けます。

AI の判断に任せてよいもの（書き方の好み、ファイルの置き方など）は、CLAUDE.md などに書く。
例外があっては困るもの（本番のデータの削除、秘密のファイル、お金の動く操作など）は、道具の設定で止める。

同じ説明には、「重要」や大文字で強調を重ねても効き目は上がりにくく、かえって決まりを当てはめすぎる原因になる、とも書かれています。何度も無視される行は、強調するより、設定で止めるか、ファイルを短くするほうが効きます。

観点5：長さ、古さ、矛盾

計画書は、長いほど良いわけではありません。

長さ：Claude Code の説明では、CLAUDE.md は1ファイル200行未満を目安とし、長いほど文脈を使って守られにくくなるとしています。
コードを見れば分かることは書かない：フォルダの構成のように、AI がリポジトリから読み取れることは書かなくてよいとされています。書くのは、確かめるためのコマンド、コードからは分からない決めごと、二度直したことなどです。
矛盾：「データは Supabase に置く」と「データは端末の中だけに保存する」のように、食い違う指示が残っていないか。方針を変えたら、古い行を消します。
古さ：もう無いファイルやコマンドを指していないか。Claude Code には、指示のファイルの古い所や矛盾を探す /doctor prompt-audit という機能があります。

Lovable の説明でも、Instructions は常に読み込まれる一方、とても長い会話では一貫して守られないことがあるとしています。

見直したあとの計画書の例

ここまでの観点を入れた、短い計画書の例です。小さな予約アプリを想定しています。

# 目的
- 教室の予約アプリ。使うのは会員（50人ほど）と管理者1人
- 完成：会員が自分の予約を登録・取り消しできる

# 作らないもの
- 決済、メールの一斉配信、英語対応

# データと権限
- 予約：本人と管理者だけが見られる。本人は取り消しだけできる
- 教室の情報：誰でも見られる。変えるのは管理者だけ
- Supabase の public の表は、すべて RLS を有効にする

# 確かめ方
- 変更のあとに npm test を実行し、出力を見せる
- 2つのテスト用アカウントで、他人の予約が見えないことを確かめる

# 決めていること
- 秘密の鍵はサーバー側の環境変数に置き、画面側のコードに書かない

短くても、誰が何を見られるかと、完成の確かめ方が書いてあることが大事です。足りない所は、作りながら「二度直したこと」を足していきます。

AIに計画書を批判させるときの注意

計画書を AI に見せて「問題はありますか」と聞くのは、手軽な見直しの方法です。ただし注意があります。2026年3月に Science に載ったスタンフォード大学の Cheng らの研究では、主要な11のAIモデルが、人と比べて49%多く利用者を肯定しました。利用者は、そうした同調的な答えのほうを信頼できると評価していました。

自分の案を見せて意見を求めると、AI は賛成に寄りやすいということです。次のような頼み方で、偏りを減らす工夫ができます。

良い所ではなく、「抜けている所」や「この計画で起きそうな問題」を挙げてもらう。
自分の考えや経緯は書かず、計画書だけを渡す。Claude Code の説明でも、会話の経緯を見ていない別のレビュー役は、作った側の理屈に引きずられないとしています。
先に AI に質問させる。Claude Code の説明では、決まっていないことがあるときは「仕様が書けるまで私に質問して」と頼み、出来た仕様書を新しいセッションで使う方法を紹介しています。
出てきた指摘が本当に当てはまるかを、自分で1つずつ確かめる。

お金や個人情報が絡む所や、後から変えにくいデータの構造は、AI の答えだけで決めないほうが安全です。判断に迷う所は、経験のある人に一度見てもらうと早いです。