要件定義で9割決まる。AIへの最高の指示書の書き方

AIに「いい感じのアプリ作って」と言って、本当にいい感じのアプリが出来た人を、僕は見たことがない。

103本のアプリを開発してきた経験から断言する。AIの出力品質の9割は、あなたが書く要件定義で決まる。

コードの品質でもない。モデルの性能でもない。要件定義。これが全て。

”思った通り”を引き出すならね。この記事は雑に進めてアイデアを具体化することを否定するわけではありません。念の為。

---

要件定義とは「AIへの最高の指示書」である

要件定義と聞くと、ITの専門用語に聞こえるかもしれない。

でも本質は単純です。「何を、なぜ、誰のために、どういう制約の中で作るか」を明文化したもの。

従来の要件定義は、人間のエンジニアに渡すために書かれていた。だから「読む人がある程度察してくれる」前提で書かれていた。

AI向けの要件定義は違う。AIは一切察してくれない。

書いてあることしか理解しない。書いてないことは存在しない。

だからこそ、要件定義の品質がそのままAIの出力品質になる。Garbage In, Garbage Out。

---

従来の要件定義とAI向け要件定義の決定的な違い

面白いことに、AI向けの要件定義は、従来とは書く順番が逆転します。

従来: 背景 → 要件 → 制約

``` 1. プロジェクトの背景 2. 機能要件 3. 非機能要件（制約条件） ```

AI向け: 制約 → 要件 → 背景

``` 1. 制約条件（絶対に守ること） 2. 機能要件（何を作るか） 3. 背景情報（なぜ作るか） ```

なぜ逆転するのか？

LLMには「Attention機構」というものがあり、入力の最初と最後に配置された情報に強く注意を払う傾向がある。

つまり、最初に書いた情報が最も重視される。

制約条件を最後に書くと、AIが「守るべきルール」を軽視してしまう。だから制約を最初に持ってくる。

これだけで、AIの出力の「暴走」が激減する。

---

情報の3層構造：Why → What → How

AI向け要件定義には、3つの層があります。

Why層（ビジネス層）

- なぜこれを作るのか - 誰が使うのか - どんな課題を解決するのか

What層（要件層）

- どんな機能が必要か - どういう画面構成か - どんなデータを扱うか

How層（実装層）

- 技術スタック - アーキテクチャ - デプロイ先 ほとんどの人がWhat層しか書かない。 「ログイン機能を作って」「ToDoアプリを作って」。これはWhat層だけ。

Why層がないと、AIは「なぜログインが必要なのか」を理解できない。だから的外れな実装をする。

How層がないと、AIは「勝手に最適と思う技術」を選ぶ。それがあなたの想定と違うと、全部やり直し。

---

実例：ダメな要件定義 vs 良い要件定義

❌ ダメな要件定義

``` ToDoアプリを作ってください。 タスクの追加、削除、完了ができるようにしてください。 ```

これで出来るのは「ChatGPTが想像する平均的なToDoアプリ」です。あなたが欲しいものとは多分違う。

✅ 良い要件定義

```

制約条件

- Next.js 16（App Router）で実装 - Supabase（認証・DB・ストレージ） - Tailwind CSS + shadcn/ui - TypeScript必須 - 日本語UI

概要

中小製造業（従業員50人）の生産管理チームが使う タスク管理ツール。現在は紙とExcelで管理しており、 タスクの進捗が可視化されていないのが課題。

ユーザー

- 管理者（工場長）: タスク作成・割り当て・進捗確認 - 作業者: タスク確認・完了報告 - 全員PCよりスマホ操作が多い → レスポンシブ必須

機能要件

タスク管理

- CRUD操作（作成・読取・更新・削除） - ステータス: 未着手 / 進行中 / 完了 / 保留 - 担当者割り当て（プルダウン選択） - 期限設定（日付ピッカー） - 優先度: 高 / 中 / 低

ダッシュボード

- 今日の未完了タスク一覧 - チーム全体の進捗（棒グラフ） - 期限超過タスクのアラート表示 ```

この2つの差が、AIの出力品質の差になる。

---

要件定義の「5ステップフレームワーク」

僕がBootcampで教えている、AI向け要件定義の書き方。

Step 1: Why（なぜ作るのか）を3行で書く - 課題は何か - 誰が困っているか - 解決されたらどうなるか
Step 2: 制約条件を列挙する - 技術スタック - 使わないもの - 絶対に守るルール
Step 3: ユーザーを定義する - 誰が使うか（ペルソナ） - どういうデバイスで使うか - ITリテラシーのレベル
Step 4: 機能を構造的に書く - 大分類 → 中分類 → 詳細 - マークダウンの階層構造を活用
Step 5: 画面遷移を定義する - ログイン → ダッシュボード → 詳細画面 - 各画面で何ができるかを明示

この5ステップを踏むだけで、AIの出力品質は劇的に変わる。

書くとはいっても、実際にはこの辺りを明確にするためのプロンプトを書いておいて、AIと壁打ちしながら中身を詰めていくというやり方をすることの方が多いんですけどね。

音声入力でいっぱい喋るのをお勧めします。しゃべるにしても、このあたりは押さえたいということです。

---

「AIが賢くなれば要件定義はいらなくなる」という幻想

よく聞く反論です。「AIがもっと賢くなれば、曖昧な指示でも理解してくれるようになるでしょ」

ならない。

なぜなら、あなたの会社固有の文脈は、どんなに賢いAIでも知りようがないから。

「従業員50人の製造業で、工場長が紙で管理していて、スマホしか使えない作業者がいる」

この情報は、インターネットのどこにも書いていない。あなたの頭の中にしかない。

AIが賢くなっても、あなたが文脈を渡さなければ、AIには「見えない」。

要件定義は、AIが賢くなればなるほど重要になる。高性能なAIに高品質な要件定義を渡したときのリターンが、指数関数的に大きくなるから。

---

要件定義力 = ビジネス力

最後に一つ。

要件定義を書く力は、そのままビジネス力です。

- 課題を特定する力
- ユーザーを理解する力
- 制約の中で最適解を見つける力
- 構造的に思考する力

これは全部、ビジネスパーソンに求められる基本能力。

要件定義が書ける人は、AIを使いこなせるだけじゃない。仕事そのものが上手くなる。

だから僕は、Vibe Coder Bootcampで「プログラミング」じゃなく「要件定義」を教えている。

要件定義で9割決まる。残りの1割は、AIがやってくれる。

---

次回は「チャットAIを卒業せよ」。IDE×AIが革命の本質で入口である理由を解説します。

きちんとコンテクストコントロールを身につけるためには、いきなりClaude Codeやるよりステップ踏むのがおすすめ。