AI開発の仕様の伝え方｜作りたいものを言葉にする手順
AIに開発を任せると、指示した内容は短い時間で形になります。その分、指示にあいまいな部分があれば、AIが推測で埋めた状態で返ってきます。この記事では、作りたいものを言葉にするときの観点を5つに整理し、指示文の例と、動くものを見ながら直していく進め方を紹介します。
AIは「言われたこと」を早く形にする
AI駆動開発では、要件の整理から実装、テストまでの多くの作業をAIが担います。全体像は「AI駆動開発とは｜AIと人の役割分担と発注側の要点」で整理しています。ここで押さえたいのは、AIが得意なのは「与えられた情報をもとに、それらしい形を素早く作ること」だという点です。
指示に書かれていないことは、AIが一般的な例にならって補います。たとえば「会員登録の機能を付けて」とだけ伝えれば、メールアドレスとパスワードによる一般的な登録画面が出てくるかもしれません。ところが、新規事業の本当の狙いが「紹介を受けた人だけが参加できる招待制」だった場合、その画面は意図と食い違います。AIに悪気があるわけではなく、補う材料がなかっただけです。
人どうしの開発であれば、担当者が「招待制ですか、誰でも登録できますか」と聞き返してくれる場面もあります。AIは、聞き返さずにそのまま進めることもあります。だからこそ、最初の指示に何を書くかが結果を左右します。
もうひとつ、AIは作り直しも速いという性質があります。完璧な仕様書を最初に書き上げようとするより、「確かめやすい言葉で指示し、出てきたものを見て直す」ほうが、AI時代の進め方に合っています。そのために、何を言葉にすればよいのかを次に整理します。
作りたいものを言葉にする5つの観点
新規事業のシステムを頭の中に描いているとき、私たちは「当たり前」と思っていることを省いてしまいがちです。次の5つを順に書き出すと、抜けに気づきやすくなります。
1. 目的：何のために作り、何が分かれば成功か
最初に書くのは機能ではなく目的です。「予約機能を作る」ではなく、「専門家への相談がどれくらい申し込まれるかを確かめるために、予約の受付までを作る」といった書き方です。
目的があると、AIは細かな判断（入力項目を増やすか減らすか、管理画面を作り込むか）で迷ったときの拠り所を持てます。事業として何を確かめたいのかは、人にしか決められない部分でもあります。検証の指標の考え方は「MVP検証の指標を先に決める方法｜判断基準の作り方」にまとめています。
2. 利用者と場面：誰が、いつ、どこで使うか
次に、使う人と使う場面です。「利用者」とひとことで書いても、実際には立場が分かれます。サービスを使う人、サービスを運営する人、間に入る人といった具合です。それぞれについて「誰が」「どんな状況で」「何をしたくて」使うのかを一文ずつ書きます。
スマートフォンで移動中に使うのか、事務所のパソコンで腰を据えて使うのかでも、画面の作りは変わります。場面を書いておくと、AIの提案が現実の使われ方に近づきます。
3. 動き：できごとを順番に書く
機能の一覧よりも、「利用者がこう動いたら、システムはこう反応する」という流れで書くと伝わりやすくなります。
- 相談者が専門家の一覧から条件で絞り込む
- 気になる専門家のページで空いている日時を選ぶ
- 申込内容を送ると、専門家に通知が届く
- 専門家が承諾すると、相談者に確定の連絡が届く
このように時間の順に並べると、「承諾されなかったときはどうするのか」「日時が重なったらどうなるのか」といった、書かれていない分岐が見えてきます。分岐を洗い出すこと自体が、仕様を固める作業になります。
4. 範囲：今回やらないこと
AIに任せると、「ついでに」機能が増えることがあります。範囲を絞るには、作るものだけでなく「今回は作らないもの」も書いておきます。
たとえば「決済、レビュー機能、ポイント制度は今回の範囲に入れない」と明記します。最初に作る範囲の決め方は「MVP開発の機能の絞り方｜最初に作るものと後回しの基準」が参考になります。範囲を書かないまま始めると、確認しなければならない画面や動作だけが増えていきます。
5. 確認の基準：できたかどうかをどう見るか
最後に、「できた」と判断する条件を書きます。「使いやすいこと」のような感覚的な言葉ではなく、実際に操作して確かめられる形にします。
- 利用者が一覧から申込完了まで、画面を3つ以内の移動で進められる
- 承諾・見送りのどちらの場合も、相談者に結果が届く
- 同じ日時に二重で申込が入らない
こうした基準があれば、出てきたものが指示どおりか、人が確認できます。AIにテストを書かせるときも、この基準が土台になります。テストの任せ方は「AIのテスト自動生成｜任せる範囲と人が見る確認項目」で詳しく扱っています。
指示文の例：あいまいな書き方と、言葉にした書き方
ここまでの5つの観点を、架空の例で比べてみます。専門家と相談者をつなぐ予約サービスの、最初の版を作りたい場合です。
あいまいな書き方
専門家と相談者をマッチングするサービスを作ってください。予約もできるようにしてください。
これでもAIは何かを作ります。ただ、誰が使い、何を確かめたいサービスなのかは伝わっていません。出てきた画面を見て「イメージと違う」と感じても、どこが違うのかを言葉にするのに時間がかかります。
5つの観点で言葉にした書き方
【目的】専門家への相談に、相談者がどの程度申込むかを確かめたい。そのために、申込の受付から確定連絡までを動く形にする。 【利用者と場面】相談者は、仕事の合間にスマートフォンで専門家を探す。専門家は、パソコンで申込を確認し、承諾か見送りを選ぶ。 【動き】一覧で絞り込み → 専門家ページで日時を選択 → 申込送信 → 専門家に通知 → 承諾または見送り → 相談者に結果を連絡。 【範囲】決済、レビュー、ポイントは今回作らない。専門家の登録は管理者が手作業で行う前提とする。 【確認の基準】二重予約が起きない。承諾・見送りの両方で相談者に連絡が届く。 【未決事項】キャンセルの扱いは決まっていない。作り始める前に、選択肢を挙げて質問してほしい。
後者は長く見えますが、書いている時間は十数分程度のことが多いはずです。その時間で、作り直しの手間をかなり減らせます。なお、マッチング型のサービスで最初に決めておきたい項目は「マッチングサービス開発の進め方｜最初に決める5つのこと」にも整理しています。
決まっていないことは隠さず、AIに質問させる
新規事業の初期は、すべてが決まっているほうが珍しいものです。決まっていない部分を無理に埋めて指示すると、AIはその仮の内容を前提に作ります。そこで有効なのが、「決まっていないこと」を明記し、作り始める前にAIから質問を出してもらう方法です。
指示文の最後に、次のような一文を添えます。
上記の内容で、仕様として不足している点や、判断が分かれる点を質問として挙げてください。実装はまだ始めないでください。
AIは、キャンセルの扱い、専門家が承諾しなかった場合の期限、通知の手段といった論点を挙げてくれます。人が見落としていた分岐に気づける、という使い方です。この工程は、要件定義をAIに支援させる考え方そのものです。詳しくは「AI要件定義で変わること｜AIが整理し人が決める範囲」を参照してください。
ここで大切なのは、質問への答えを決めるのは人だという点です。AIは選択肢と、それぞれの長所・短所を示せます。ただ、事業の方針に合うのはどれかは、事業を担う側が判断します。仕様が固まっていない段階でどこまで相談できるかについては「仕様が決まってないシステム開発の相談は可能か」で触れています。
言葉だけで伝え切ろうとせず、動くものを見て直す
どれほど丁寧に書いても、言葉だけで頭の中のイメージが完全に伝わることはありません。画面の余白、ボタンの位置、文言の温度感といった部分は、実物を見て初めて「これではない」「ここはこう」と言えることが多いからです。システム開発で起きる認識のズレは、言葉だけで要件を決めることから生まれやすい、というのが私たちの考えです。詳しくは「システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせ」にあります。
そのため、AIへの指示は一度で完成させようとせず、小さな単位で出して確かめます。
- 最初は、動きの流れ全体ではなく、申込の受付までだけを依頼する
- 出てきたものを実際に操作し、気づいたことをメモする
- 直したい点は、「現象」「期待する動き」「その理由」の3点で伝える
- 決まった内容は、指示文（仕様メモ）に書き足して更新する
修正の伝え方は、たとえば次のようにします。「日時を選ぶ画面で、空いていない日が選べてしまう。選べないようにしたい。二重予約を防ぐため」。「使いにくいので直して」より、AIが直す方向を絞れます。
最後の「仕様メモを更新する」は、地味ですが効果があります。会話の中で決まったことは、次の指示に引き継がないと失われがちです。決まったことを一か所に書き残しておくと、人が入れ替わっても、AIに依頼し直しても、前提がぶれにくくなります。
なお、思いつくまま指示して出てきたものをそのまま使う進め方は、試作には向いても、事業として育てるシステムには不安が残ります。違いは「バイブコーディングとは｜AI駆動開発との違いと事業での使い方」で整理しています。
人が決めること、人が確かめること
AIに任せる範囲が広がっても、人の役割は残ります。大きく分けると、次の2つです。
- 何を作るかを決めること：目的、範囲、優先順位、判断が分かれる点の答え
- 出てきたものの品質を最終的に判断すること：基準を満たしているか、事業の意図に合っているか
AIが書いたコードや画面は、動いて見えても、条件によっては想定外の挙動をすることがあります。人が確認すべき点は「AI開発でも品質には人の確認が必要な理由」で、セキュリティ面の確認点は「AI生成コードのセキュリティ｜確認点と人の役割」で扱っています。
もうひとつ、指示を言葉にする過程では、事業のアイデアや顧客に関する情報を書き込むことになります。どこまでの情報を入力してよいか、利用するAIの設定や取り扱いがどうなっているかは、指示を書き始める前に確かめておきたい点です。「生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデア」に、確認の観点をまとめています。
まとめ
AIに開発を任せるときの指示は、機能を並べるよりも、「何のために」「誰が」「どう動かし」「どこまで作り」「どう確かめるか」を言葉にすることが土台になります。5つの観点を書き出し、決まっていない点はそのまま明記してAIに質問させ、出てきたものを見ながら小さく直していく。この流れで、指示のあいまいさから生まれる手戻りを減らせます。
押さえておきたい点を、あらためて整理します。
- AIは書かれていないことを推測で補うため、目的と範囲を先に書く
- 動きは、時間の順に「利用者がこう動いたらこう反応する」と書くと分岐が見える
- 決まっていないことは隠さず、AIに質問させて人が決める
- 言葉だけで伝え切ろうとせず、動くものを見て、現象・期待・理由の形で直す
- 何を作るかの決定と、品質の最終判断は人が担う
JustFitは、構想をもとに約1ヶ月で、実際に動くプロトタイプを先に開発する受託開発サービスです。要件定義や設計、実装などを専門のAIが分担して進める独自の開発基盤「LAF」を使い、何を作るかを決める部分と品質の最終判断は人が担います。仕様が固まっていない段階でも相談できるため、作りたいものをまだうまく言葉にできていない場合も、実物を見ながらすり合わせる進め方を取れます。詳しくはJustFitのサービス紹介をご覧ください。