AI開発の要件定義｜「作ったのに使われない」をなくす4段階（問題定義→原因追求→仮説→試作品）
バイブコーディング（2025年2月にAI研究者のアンドレイ・カルパシー氏が提唱した言葉。作りたいものを自然言語でAIに伝え、生成されたコードを一行ずつ精査するのではなく、動作を確かめながら対話を重ねてアプリを形にしていく開発スタイル）の広まりで、アプリを「とりあえず作る」ことは簡単になりました。音声入力で思いつきを話せば、それらしい形にはなる。ところが、そうして作ったものの多くは使われないまま消えていきます。原因は実装の腕ではありません。抜けているのは、作る前の要件定義です。実装はClaude Code・Codexがやってくれる時代に、人間側に残るいちばん大事な工程はここだと、みやっち🧑💻は考えています。
AI開発における要件定義とは: アプリや自動化を作り始める前に「何の問題を・なぜ・どう解くか」を決める工程です。①問題定義 ②原因追求 ③仮説 ④試作品フィードバックループの4段階で進めます。実装はClaude Code・CodexのようなAIに任せられますが、この工程の中身は業務を知っている人間にしか埋められません。
Web業界では、要件定義は開発の前に置くのが一般的な工程です。ところが非エンジニアがバイブコーディングから入ると、この工程の存在ごと知らないまま、いきなり実装に進んでしまいます。
なぜ「作ったのに使われない」が起きるのか
理由は2つあります。
1つ目は、実装ではもう差がつかないからです。同じ指示を出せば、Claude Code・Codexは書き手の経験に関係なく、動くコードを返してきます。かつては「作れるかどうか」が壁でしたが、その壁はAIが取り払いました。残ったのは「何を作るか」の壁です。
2つ目は、悩んだ瞬間の思いつきをそのまま作ると、解くべき問題とズレたものができるからです。動かないのではありません。動くのに、業務の本当の困りごとに当たっていないから、いつのまにか開かなくなる。「そもそも動かない」ではなく「動いたのに使えない」——この転び方の具体例はバイブコーディングの失敗例5つにまとめています。この記事では、その失敗の根っこにある「作る前」の工程だけを扱います。
AI開発の要件定義4段階
Web業界がアプリを作るときに当たり前にやっている流れを、みやっち🧑💻が非エンジニア向けに整理したものが次の4段階です。順番に意味があります。
ステップ1: 問題定義——「悩み」と「問題」はズレている
最初にやるのは、作りたいものを決めることではなく、解くべき問題を言葉にすることです。ここで前提になるのが、悩みとして口から出る言葉と、実際に解くべき問題はズレていることがよくあるという事実です。
友人の恋愛相談を聞いていて「いや、そこじゃないでしょ」と思った経験はないでしょうか。本人が悩んでいる場所と、外から見える問題の場所が違う——あの構造は、業務の悩みでもそのまま起きます。コーチングやコンサルティングが最初に時間をかけるのもこの言語化です。自分の業務の困りごとを書き出したら、「本当に困っているのは何か」を一段掘ってから次に進みます。なお「そもそも何を作るか」の種を探す段階の話は、AIに作らせるものの見つけ方に書きました。
ステップ2: 原因追求——「ツールが悪い」の下に本当の原因がある
問題が言葉になったら、その原因を掘ります。ここを飛ばすと、症状に絆創膏を貼るアプリができます。
分かりやすいのは、シフトの穴がしょっちゅう開く会社を思い浮かべてみることです。こういう現場では「シフト管理ツールがしょぼい」という声が出がちで、だから使いやすいシフト管理アプリを作ろう、という話になります。もっともに聞こえます。でもきちんと定義していくと、本当の原因はツールではなく人手不足だった、というパターンがありえます。そもそも今の人数ではシフトが回らない状態で、ツールをどれだけ磨いても解決しません。直すべきは採用や業務の組み立て、つまりビジネスモデルの側です。ここで要件定義をせずにシフト管理アプリを作れば、時間をかけて「使われないアプリ」がひとつ増えるだけで終わります。
「なぜ？」を重ねて、症状ではなく原因に照準を合わせる。これがステップ2です。
ステップ3: 仮説——正しさは後で分かる。決めるのは「角度」
原因が見えたら、「こうすれば解決するのではないか」という仮説を立てます。ここで大事なのは細部の正しさではなく、仮説の角度——どの方向に張るか、です。角度が合っていれば、その後の打ち手が全部その線に乗ります。
みやっち🧑💻自身の実録をひとつ。2026年6月末、「AIに触り始めたばかりの初心者が、いきなりClaude Codeから入るのはハードルが高い。最初の一歩はCodexのほうが越えやすいのではないか」という仮説を立て、初心者向けの入口をCodex側に置き換える判断をしました。7月・8月と実際に運用してみて、この仮説は的中。入口の角度をひとつ変えたことで、初心者向けの案内の順番も決まりました（これは入口の順番の話で、講座ではClaude Code・Codexの両方を扱っています）。
仮説は外れても構いません。外れたと分かる形——次のステップで検証できる形——にしておくことが、この段階の仕事です。
ステップ4: 試作品フィードバックループ——完成品を一発で狙わない
仮説ができたら、完成品ではなく試作品を作ります。いきなり業務の本番に入れず、まず1人か2人に触ってもらい、フィードバックをもらって直す。この1周ごとに、要件はどんどん具体的になります。要件定義は1回で終わる書類仕事ではなく、試作品を挟んで回し続ける運動なのです。バイブコーディングはもともと試作向けの手法として広まったので、この回し方とは相性が抜群です。
4段階を通ったら、あとは作る工程です。SaaS・外注・自作という選択肢の比較と、自作する場合の手順は業務アプリの作り方にまとめています。
要件定義をGPTsに肩代わりさせる——7つの質問の設計思想
4段階の考え方は、頭で分かっても一人で回すのが難しい工程です。悩みの渦中にいる本人は、自分の問題を客観視できないからです。だから従来この工程は、コンサルタントやコーチが「質問で引き出す」形で担ってきました。
そこでみやっち🧑💻は、この引き出し役をGPTsに肩代わりさせる設計で、GPT「AIさわる前に”要件定義”手伝うくん」を作り、AI Crewの会員向けに配布しました。仕組みはシンプルで、7つの質問に順番に答えていくと、悩みの正体→因果関係→仮説が整理され、作るべきものが「複数人が画面を触って使う業務アプリ」向きか「自分がAIとやり取りして成果物を作る仕組み」向きかを判定したうえで、最後にClaude Code・Codexへそのまま渡せるプロンプト（業務アプリ向きと判定された場合は、要件をそろえた開発プロンプト）が出力されます。
このGPT自体は会員特典ですが、設計の考え方はそのまま自作に使えます。勘所は3つです。
- 質問は4段階の順に並べる。いきなり「何を作りたいですか」と聞かない。悩み→原因→仮説の順で掘らせる
- 判定と整理はAI側にやらせる。回答をもとに「この問題にアプリは要るか・どんな形が合うか」まで言わせる
- 最後に成果物を出力させる。要件定義の出口は感想ではなく、AIにそのまま渡せるプロンプト1本
この構造さえ守れば、入れ物はGPTsでなくても構いません。ChatGPTやClaudeに貼る固定の質問プロンプトでも、近い働きをします（2026年8月以降、個人アカウントでは新しいGPTsを作れないため、その場合はこの形が現実的です）。この仕組みは、「思いついた順に作って、使われない試作品が溜まっていく」の前に、問題・原因・仮説を通すための装置です。
よくある質問
要件定義書は作らないといけませんか？
書類としての要件定義書は必須ではありません。「何の問題を・なぜ・どう解くか」という4段階の中身が自分の言葉になっていれば、AI開発の要件定義としては十分です。細部を先に固め切るより、試作品フィードバックループで詰めていくほうが早く、正確です。
要件定義そのものをAIにやらせることはできますか？
文章の体裁を整える作業はAIに任せられますが、問題定義と原因追求の中身は、業務を知っている本人からしか出てきません。おすすめは逆向きの頼み方で、「私に質問して、悩みの正体と原因を引き出してください」とAIに聞き役をさせる方法です。本文で挙げた3つの勘所（悩み→原因→仮説の順に聞かせる／判定と整理をAI側にやらせる／最後にプロンプトを出力させる）が、そのままこの頼み方の設計図になります。
プログラミング知識がなくても要件定義はできますか？
できます。むしろ要件定義に必要なのはプログラミング知識ではなく業務の知識です。何が問題で、なぜ起きていて、どうなれば解決なのかを言葉にできるのは現場を知っている人だけで、技術的な実現方法はその後にClaude Code・Codexへ相談しながら決められます。
差がつくのは、業務を知っているあなたの側
実装で差がつかなくなったことは、非エンジニアにとってチャンスです。市販のSaaSは平均的な業務にしか合わせにくく、外注では業務の機微が伝わりにくいものです。自分の業務の問題・原因・仮説を自分で言葉にできる人だけが、自分の仕事にぴったり合うアプリや自動化を持てます。そしてその言語化は、現場を知っている経営者・個人事業主・士業・会社員が、いちばん有利な仕事です。
AI Crewでは、何を作るかを決めるこの要件定義の工程から、みやっち🧑💻が受講生と一緒に進めています。まず無料セミナーでお会いしましょう。
