この記事の内容
AIに頼めば、画面もデータの保存も数分で動くようになりました。それなのに、できあがったものを触ってみると「欲しかったのはこれじゃない」と感じる。AIで作り始めた人の多くが、この段階でつまずきます。原因の多くはAIの性能より、頼む側が「何ができたら正解か」を決めないまま頼んでいることにあります。コードを書く作業が速くなるほど、人の手元に残る仕事は「何が正しいかを決めること」、つまり要件定義になります。この記事では、AIに頼む前に書いておく4つ（誰の・どの行動・合格ライン・やらないこと）、そのまま埋められるテンプレート、AIに要件を下書きさせて批判させる使い方、AIには判断できないことを順に整理します。後半では、開発経験のない人が要件を書くときのコツもまとめました。監修は、要件が固まっていない案件や、他社から引き継いだ開発の立て直しを担当してきた株式会社Walkers取締役の池田龍一です。
この記事について
書いているのは、作る側です。ハコブネを運営する株式会社Walkersは、受託と自社事業で累計300件の開発に関わり、200社以上の事業づくりを支援してきました。監修は取締役の池田龍一です。
一般論ではなく、実際にやったことの中身で説明します。この記事に出てくる数字は、すべて公開済みの自社・支援先の事例から引いています。出典は記事の最後にまとめました。
AIはコードを速く書くが、「何が正しいか」は決めない
AIは、言われたことを速く、それらしく形にします。裏返すと、言われていないことは推測で埋めます。「予約アプリを作って」と頼めば、予約アプリらしいものはできます。ただ、誰が予約するのか、キャンセルは何日前まで受けるのか、同じ時間に2件入ったらどうするのかは、AIが一般的な答えで埋めたものです。その答えが自分の事業に合っている保証はありません。
Walkersが運営するAI駆動開発の解説記事でも、AIが確実にはできないこととして、曖昧な要求を正しく解釈することや、どんなアプリを作るべきかを決めることを挙げています。同じくWalkersのノーコード開発の記事では、ノーコードやローコードで作る場合でも設計は必要だという専門家の意見や、仕様書どおりに組むだけの仕事は減っていくという見方を紹介しています。
AIに渡す言葉が短いほど、AIが推測で埋める部分は増えます。作る速さが上がると、間違ったものも速くできあがります。作り直しも速いので一見困らないように見えますが、「何が正解か」が決まっていないと、何度作り直しても正解に近づきません。AIに任せられるのは「どう作るか」で、「何を作れば正解か」を決めるのは作る人の仕事です。
個人で作るときの要件定義は4つに絞る
Walkersの開発メディアでは、受託開発の要件定義で決める項目として、目的・背景、システム概要、役割分担、開発手法、機能要件、非機能要件、スケジュール、費用、運用の流れの9つを挙げています。発注する会社と開発会社のあいだで、誤解なく合意するための項目です。
自分でAIを使って作る場合は、発注と受注の調整が要らないぶん、項目を絞れます。最初に決めるのは次の4つです。
一つめは、誰の困りごとを解くのか。二つめは、その人のどの行動を変えたいのか。三つめは、何がどうなれば合格とするのか。四つめは、今回はやらないことです。
9つのうち残りの項目も、消えるわけではありません。費用とスケジュールは「いつまでに、AIツールやサーバー代を含めていくらまで」の一行で足ります。役割分担や開発手法は、一人で作るなら決める必要がほとんどありません。機能要件と非機能要件は、4つが決まったあとにAIと一緒に洗い出せます。
この4つは、仕様書というより、作る前に置いておく判断の物差しです。AIが出してきた画面や機能を見たときに、この4つに照らせば「採用する・直す・捨てる」を自分で決められます。逆にこの4つがないと、AIの提案を全部受け入れるか、気分で選ぶかのどちらかになります。
AIに頼む前に書く4つ
誰の困りごとか
「中小企業向け」のような広い言い方では、AIは平均的な利用者を想定して作ります。「店長と、日本語の説明を読むのが苦手なスタッフ」のように、使う人の顔が浮かぶところまで書きます。
どの行動を変えるか
ハコブネのハッカソンで運営が作った記録アプリ「BENLOG」は、確かめる仮説を「うんちを育てるためなら、人は毎日トイレを記録するのか」に絞っていました。誰が、どんな条件で、何をするかが一文に入っています。ここまで書けると、必要な画面とそうでない画面の区別がつきます。
合格ライン
BENLOGでは、仕様書の段階で7日後の継続率40%、30日後の継続率20%、1日平均3.5件という線を置いていました（いずれも検証前に置いた目標値で、実測ではありません）。業務ツールなら、使い勝手の条件が合格ラインになることもあります。Walkersが支援した中華料理店の一番飯店は、紙の伝票とトランシーバーで回していたオーダーをシステムに置き換えました。いちばん重視したのは簡単に操作できることで、外国籍のスタッフが日本語の説明を読まなくてもオーダーを取れるよう、写真を多く使うことが要件でした。導入後、オーダーの労力は50%ほど減り（依頼者の体感）、約2年使われ続けています。
やらないこと
ログイン、通知、管理画面、決済など、今回の合格ラインに関係しないものを書き出します。AIは頼まれていない機能も親切に足してくることがあるので、「やらないこと」を書いておくと、それを断る根拠になります。
そのまま埋められる要件メモのテンプレート
4つを含めて、AIに渡す前の要件メモを1枚にまとめます。各行を1〜2文で埋めれば十分です。
- 作るもの：一文で。「〔誰〕が〔どんなとき〕に〔何をする〕ための〔道具〕」
- 使う人：名前か、顔が浮かぶ具体的な人物像。使う場所と端末も
- 今のやり方：いまその作業をどう回しているか。紙、表計算、口頭など
- 変えたい行動：使い始めたあと、その人が何をするようになれば成功か
- 合格ライン：数字か、使い勝手の条件。いつ測るかも
- やらないこと：今回は作らない機能
- 困る場面：こうなったら使えない、という状態を3つ
- 確かめ方：完成したと言える操作の手順。誰が、何を押して、何が表示されるか
仮に、ハッカソンで参加者が作った「社員の資格期限管理アプリ」と同じ題材で書くと、次のようになります。作るものは「総務担当者が、社員の資格の更新期限を見落とさないための一覧」。今のやり方は表計算で、期限は担当者が目で追っている。変えたい行動は、期限の1か月前に担当者が本人へ連絡すること。やらないことは、資格の申し込みや費用の精算です。ここまで書いてからAIに渡すと、出てくる画面の数がぐっと減ります。
最後の「確かめ方」は、受け入れ条件とも呼ばれます。ここが書けていると、AIが作ったものを自分で検収できます。
AIに要件を下書きさせ、批判させる
要件メモそのものも、AIと一緒に作れます。使い方は4つあります。
1. 聞き取り役をさせる。 「私が作りたいものについて、要件を決めるための質問を1つずつしてください。答えが曖昧なら聞き返してください」と頼みます。一人で書くより抜けが減ります。
2. 抜けを指摘させる。 書いたメモを渡して、「この要件で作ると困る場面と、決まっていない点を挙げてください」と頼みます。同時に使う人数、データが消えたとき、スマホで見たときなど、Walkersの記事で非機能要件と呼ばれている部分の抜けを拾ってくれます。
3. 受け入れ条件に書き換えさせる。 「変えたい行動」と「合格ライン」を渡して、「完成を確かめる操作手順に書き換えてください」と頼みます。曖昧な言葉が、押す・表示されるといった確かめられる形に変わります。
4. 作る前に、画面の流れを文章で返させる。 コードを書かせる前に、「利用者が最初に見る画面から目的を果たすまでを、手順で説明してください」と頼みます。ここで違和感があれば、コードを書く前に直せます。
この4つは、AIを決める人としてではなく、抜けを探す相手として使う方法です。AIの指摘は材料として受け取り、採用するかどうかは4つの物差しに照らして自分で決めます。
AIには判断できないこと
AIは、一般的に起こりやすい問題を挙げるのは得意です。一方で、次のことは判断できません。
- 誰を優先するか：利用者が複数いるとき、どちらの使いやすさを取るか
- 何を捨てるか：時間とお金に限りがある中で、今回やらないことの線引き
- 合格ラインの数字：その事業にとって、どこまでいけば続ける価値があるか
- 相手が本当に困っているか：困りごとの深さは、相手に会って聞かないと分かりません
Walkersが開発を支援したUPSTA Japanの「ApoLink」は、開発の途中でテストマーケティングを行い、マッチング機能への反応が圧倒的に良かったため、後に予定していたその機能を最初のリリースに前倒ししました。公開の時期は予定どおりで、リリースから約1ヶ月半で会員は200人弱まで増えています。作る順番を変えたのは、市場の反応という、AIの手元にない事実を見た人の判断でした。
要件定義は、一度決めたら終わりではありません。反応を見て書き直すたびに、判断するのは人です。AIのおかげで作り直しの手間は小さくなりましたが、何をどう直すかを決める手間は残ります。要件メモに「いつ、何を見て、何を変えたか」を一行ずつ残しておくと、あとから判断を振り返れます。AIに次の修正を頼むときも、そのメモを渡せば、前の判断と食い違う提案を減らせます。
非エンジニアが要件定義をするときのコツ
開発の経験がなくても、要件は書けます。Walkersの記事でも、要件定義を成功させるポイントとして、現在の業務の流れを把握すること、専門用語を使いすぎないこと、開発する側と認識をすり合わせることを挙げています。AIを相手にするときも、この3つはそのまま使えます。
一つめは、画面よりも手順を書くことです。「こういう画面が欲しい」より、「いまは誰が何をして、どこで困っているか」を順番に書くほうが、AIは目的に合った画面を考えられます。二つめは、例を3つ書くことです。「予約が重なる」より、「火曜18時に2人が同時に申し込んだ」のような具体例のほうが、条件の抜けが見えます。三つめは、分からない言葉をそのままにしないことです。AIの返答に分からない用語があれば、「中学生にも分かる言葉で言い直して」と頼んでから判断してください。
ハッカソンでは、類似のPoCを横断比較する企業向けのPoC設計ツールを、開発がまったく初めての参加者が約4時間で作り、受賞しました。作る技術より先に、誰のどんな困りごとを解くかがはっきりしていれば、開発経験がなくても形になります。
ハコブネは、AIで新規事業を立ち上げる個人・経営者のコミュニティで、運営は株式会社Walkersです。1DAY新規事業立ち上げイベントは、アイデアがなくても、開発が初めてでも参加でき、会員は参加費無料、一般は3,000円です（日程は1DAYイベントのページで案内しています）。月1〜2回のランチ会や、3ヶ月・全6回の個別伴走である新規事業立ち上げゼミでは、作る前の「何が正解か」を人と詰められます。入会するか迷っている場合は、オンラインの無料相談会で、いま考えている事業のことを話しながら決められます。
よくある質問5選
質問1要件定義そのものをAIに丸ごと任せてもいいですか？
下書きや抜けの洗い出しはAIに任せて構いません。ただし、誰を優先するか、何を捨てるか、合格ラインをどこに置くかは、事業の事情を知っている人にしか決められません。AIの案は、自分の4つの物差しに照らして採否を決めてください。
質問2要件メモはどのくらいの分量が必要ですか？
個人や少人数で作るなら、テンプレートの8行を1〜2文ずつ埋めた1枚で足ります。分量より、「確かめ方」まで書けているかが大事です。完成の手順が書けていれば、AIが作ったものを自分で確かめられます。
質問3プロンプトを工夫すれば要件定義は要らなくなりますか？
プロンプトの書き方で、AIの出力の質はある程度上がります。ただ、プロンプトに書く中身そのものが要件です。何が正解かが決まっていなければ、どれだけ丁寧に頼んでも正解には近づきません。
質問4途中で要件を変えてもいいですか？
変えて構いません。相手の反応を見て作る順番を変えるのは、むしろ良い判断です。変えるときは要件メモも書き直し、何を変えたかを残しておくと、AIへの指示がぶれません。
質問5非エンジニアでもAI駆動開発で作れますか？
小さな試作なら作れます。ハコブネのハッカソンでは、開発がまったく初めての参加者が約4時間でプロダクトを作りました。ただし、人に使ってもらう段階では、動作の確認や公開前の点検を誰かと一緒に見る場面が増えます。そのぶん、何を作れば正解かを決める要件定義の比重が大きくなります。
この記事について
池田は、ITとノーコードの事業開発・教育事業の立ち上げを経て2021年にWalkersを共同創業。100件以上のシステム開発に携わり、要件がまだ固まっていない案件や、他社から引き継いだ開発の立て直しを担当しています。
株式会社Walkersは、AI駆動開発・ノーコード開発のシステム開発会社です。累計開発実績300件、200社以上の支援、自社メディアの累計100万PV。受託開発と並行して、自社でも複数の新規事業を立ち上げています。
この記事で触れた事例の出典
最終更新：2026年10月15日