アプリ 企画書 テンプレート：1ページで作るiOSアプリの要件定義

モバイルアプリの要件定義書：短い答え

自分のアプリを作るなら、良い要件定義書は1ページに収まります。答えるべき質問は10個です。誰のためのアプリか、どんな問題を解決するか、メイン機能は何か、どうやって収益を上げるか、アカウントなしで何ができるか、どのデータを残す必要があるか、どのプラットフォームか、最初のバージョンに入れないものは何か、うまくいっているとどう判断するか、そしてどんな制約があるか。コピーできるテンプレートは下にあります。テンプレートと検証チェック表（.md）をダウンロードすることもできます。登録は不要です。

ネットで見つかる40ページのテンプレートは、別の用途のために書かれています。発注者が開発会社にアプリを依頼し、契約書類が必要な場合のものです。あなたは決める人であり、作る人でもあります。多くの場合、AIの助けを借りて。あなたの要件定義書の役割は2つです。コードを書く前に決めるべきことを決めること。そして、Claude、ChatGPT、Cursorが正しいアプリを作れるように、明確なコンテキストを渡すことです。

僕は自分のiOSアプリを公開しています。ミニゲーム付き目覚ましのSolysと、トレードシミュレーターのTradaZenはApp Storeに並んでいます。NoleraとClicはAppleにリジェクトされ、その後修正しました。どのアプリにも使っている方法を、ここで紹介します。

自分のアプリを固めるのに1ページで十分な理由

長いドキュメントは、進んだ気分にさせてくれます。でも実際は、一度書いたらほとんど読み返されず、最初の数週間でプロジェクトはそこから外れていきます。1ページなら、作業のたびに2分で読み返せます。

スペースの制約には、もう1つ効果があります。決断を迫られることです。答えが2文を超えるなら、たいていはまだ決めきれていません。それに気づくのは、3週間後のコードの中より紙の上のほうがいいですよね。

そして、1ページはAIにとってもちょうどいいサイズです。会話にまるごと貼り付けることも、プロジェクトのコンテキストファイルに入れておくこともできます。短いドキュメントは読み返しやすく、矛盾した指示も減らせます。ただし、AIがそれに従う保証にはなりません。AIの提案は、この枠組みと照らし合わせて確認してください。

モバイルアプリの要件定義書には何を書くべき？

それぞれの質問に1〜2文で答えてください。

1. 誰が、どんな場面でアプリを使うのか？ 「18〜35歳」ではありません。1日のある特定の瞬間にいる、具体的な1人です。
2. アプリはどんな問題を解決するのか、1文で？ 「それに加えて」が必要なら、それは2つのアプリの説明です。
3. 最初のバージョンの「唯一の」メイン機能は何か？ 1つだけです。ほかの機能は数字が出るまで待ちます。選び方はiOSアプリのMVPのページで解説しています。
4. アプリはどうやって収益を上げるのか？ サブスクリプション、買い切り、または無料。この答えは最初の画面からアプリを変えます。迷っているならiOSアプリはサブスクか買い切りかを読んでください。
5. アカウントを作らずに何ができるのか？ 登録なしで使える範囲を早めに決めておけば、オンボーディングを全部作り直さずに済みます。
6. 機種変更しても残る必要があるデータは何か？ Supabaseのようなバックエンドが必要か、すべて端末内で完結できるかを決める質問です。
7. iOSだけか、iOSとAndroidか？ 初心者への僕のアドバイスは、まずiOSです。理由はiOSとAndroidのアプリを同時に作るで詳しく書いています。
8. 最初のバージョンに明確に「入れない」ものは何か？ ドキュメントで一番役に立つセクションです。自分自身とも、AIとも、議論が始まる前に終わらせてくれます。
9. うまくいっているとどう判断するか？ リリース後の数週間で測れるシグナルを1つだけ。開始された無料トライアル、サブスク登録者、戻ってくるユーザーなどです。
10. 現実的な制約は何か？ 毎週使える時間、手持ちの機材、そして年99ドルかかるApple Developerアカウント。Macがない？ 致命的ではありません。MacなしでiOSアプリを公開するで説明しています。

コピーして使える要件定義書テンプレート

このテンプレートをメモか、プロジェクトのルートにあるテキストファイルにコピーして、各行を書き換えてください。

• アプリの仮の名前： …
• 誰のため： …な人が、…しているとき
• 解決する問題（1文で）： …
• バージョン1のメイン機能： …
• 初めてアプリを開いたときにユーザーが見るもの： …
• ビジネスモデル： サブスクリプション／買い切り／無料、有料になるもの：…
• アカウントなしでできること： …
• 端末間で引き継ぐデータ： なし／…
• プラットフォーム： まずiOS（数字が伴えば後でAndroid）
• バージョン1に入れないもの： …、…、…
• 成功のシグナル： …
• 技術スタック： React Native、Expo、アカウントが必要ならSupabase、サブスクリプションにはRevenueCat
• 制約： 週…時間、Apple Developerアカウントの有無、Macの有無
• 体験が好きなアプリとその理由： …

好きなアプリのスクリーンショットを3〜5枚添えて、気に入っている点をひと言書いておきましょう。デザインガイドラインより伝わります。自分にとっても、AIにとっても。

要件定義書は願い事リストではありません。決めたことのリストです。

例：架空のアプリで埋めたページ

どのくらい細かく書けばいいかを見るために、例として考えた勉強用タイマーアプリでテンプレートを埋めてみます。

• 誰のため： 夜にひとりで勉強していて、10分で集中が切れる学生。
• 問題： スマホを触らずに勉強を続けられない。
• メイン機能： 時間を計る勉強セッションを始め、続けられた日数の連続記録を見る。
• 最初の画面： セッションを始めるボタンが1つだけ。
• ビジネスモデル： 詳しい統計はサブスクリプション、基本セッションは無料。
• アカウントなし： 端末間のバックアップ以外はすべて使える。
• バージョン1に入れないもの： グループモード、友達とのランキング、ウィジェット、Android版。
• 成功のシグナル： 何日も続けて戻ってくるユーザー。

あえて入れていないものに注目してください。20画面のリストも、指定の色も、アーキテクチャもありません。それらは作りながら決めていきます。このページは、その選択がメイン機能のためになっているかを確かめるために使います。

要件定義書を使ってAIに指示を出す方法

ここがこのページが一番役に立つところです。コンテキストなしでコードを書くAIは推測します。そして、あなたのものとは別のアプリを推測しがちです。

ページをプロジェクトの常設コンテキストに入れましょう。 Claude CodeはルートのCLAUDE.mdファイルを読み、Cursorには独自のルールファイルがあります。そこに要件定義書と技術スタックを貼り付けます。そうすれば、どの依頼も同じ土台から始まります。

AIがやりすぎたら「バージョン1に入れないもの」を引用しましょう。 AIアシスタントは、ダークモード、共有機能、通知など、機能を追加したがります。除外リストがあれば答えは決まっています。「今はやらない」です。

ページに沿った計画を求めましょう。 大きな作業の前に、こう書きます。「これが要件定義書です。メイン機能の計画を提案してください。まだコードは書かないでください」。計画が決めたことから外れていれば、すぐに気づけます。

コードだけでなく、ページもレビューさせましょう。 「この要件定義書の中で、あいまいな質問や矛盾している質問はどれですか？」と聞いてみてください。過小評価されているAIの使い方で、間違った方向への何週間もの作業を防いでくれます。

このテーマをさらに深掘りしたい人のために、落とし穴とチェック方法をAIでiOSアプリを作るで詳しく書いています。

決めたことを検証基準に変える

メイン機能には、目で確認できる結果が必要です。この例の架空のタイマーなら、「タイマーが動く」ではあいまいすぎます。代わりにこう書きます。「セッションを始めると残り時間が表示され、止めることができ、アプリを開き直しても最後に完了したセッションが見られる」。画面ロック中もタイマーを動かし続けるかは別に決めてください。この選択で技術的な作業が変わることがあります。

機能ごとに3行を追加します。操作、期待する結果、証拠です。証拠は、計算なら自動テスト、操作フローなら実機での確認でかまいません。テストしていないことも書いておきましょう。この小さなチェック表があれば、「画面ができた」と「機能が使える状態になった」を取り違えずに済みます。

架空のタイマーで埋めたチェック表です。これは確認すべき基準であって、すでに合格したテストではありません。

決めたこと	テスト内容	期待する結果
基本セッションはアカウントなしで使える	アプリをインストールし、登録せずにセッションを始める	登録フォームがセッション開始を妨げない
途中でやめたセッションは連続記録に数えない	セッションを終了前に止め、履歴を開く	完了したセッションが追加されない
履歴は端末に残る	セッションを完了し、アプリを閉じてから開き直す	セッションが正しい時間で1回だけ表示される
基本タイマーはネットワークなしで動く	機内モードにしてセッションを完了する	タイマーとローカル保存が使える状態のまま
詳しい統計は有料	サブスクリプションなしで統計を開く	プランが表示され、基本セッションは使えるまま

まだあいまいな点は、決めるべきことになります。たとえば、セッション中にユーザーが画面をロックしたり、スマホの時刻を変えたりしたらどうするか？ エージェントに黙って選ばせないでください。望む動作を書き、そのケースをチェック表に追加します。実際のインストール環境でこの受け入れテストを進めるには、TestFlightでiPhoneアプリをテストするのガイドを使ってください。

最初のバージョンが膨らんだときに何を削るか決める

機能を1つずつ見直して、こう問いかけます。「これがなくても、ユーザーは約束した結果を得られるか？」 架空のタイマーなら、友達とのランキングは後回しにできます。連続日数を約束するなら、完了したセッションを見返せることは必須です。サブスクリプション画面が必須になるのは、このバージョンから実際に統計を販売する場合だけです。

決めたこととその理由を、ダウンロードできるテンプレートの記録欄に書いておきましょう。テスト後にこの選択を見直すときも、最初の範囲を決めた理由を失わずに済みます。その後、Claude Codeでアプリを作るのチュートリアルで、この枠組みを範囲を絞った検証可能な依頼に変える方法を紹介しています。

現場の例としては、TradaZenは公開後にスコープを変えました。枠組みは、測定できる最初のバージョンを出し、実際のフィードバックをもとに次を決めるためのものです。

機能カタログの落とし穴

自然な反応は、アプリが「やるべきこと」を全部書き出すことです。地図、チャット、通知、紹介プログラム、オフラインモード。このカタログは、完成しないプロジェクトの最も確かなサインです。理由は単純で、リリース前に追加する機能はどれも、本物のユーザーが何が大事かを教えてくれる瞬間を遅らせるからです。

良い最初のバージョンは、1つのことを、うまくやります。ただし逆の行き過ぎにも注意してください。App Review Guidelinesの4.2により、AppleはアプリがウェブサイトをパッケージしただけのものAP以上であることを求めています。メイン機能が1つなのはOK、中身のない殻はNG。これがガイドライン4.2のリジェクト理由です。

モバイルアプリの要件定義書に入れてはいけないもの

• 完全なデザインガイドライン。 最初は参考スクリーンショットが数枚あれば十分です。
• 日単位のスケジュール。 それを守るための情報がまだありません。週ごとの目標で十分です。
• 詳細な技術アーキテクチャ。 実績のある技術スタックを選び、細部は作りながら決めましょう。
• ほかの項目に混ざった「後でやる」機能。 すべて「バージョン1に入れないもの」のセクションに入れます。

要件定義書はいつ更新する？

作業する週の初めに毎回読み返してください。更新するのは、本当の理由で決定が変わったときだけです。iPhoneでのテストである画面がうまく機能しないとわかった、テスターからフィードバックがあった、途中でAppleの制約を見つけた、などです。毎日書き換えているなら、もう何も枠にはまっていません。

最初のバージョンを公開したら、このページが次のバージョンの土台になります。バージョン1に入れなかったものが、数字が教えてくれる順に浮上してきます。アイデアから公開までの全体像は、iPhoneアプリを作るのページにあります。

ページから公開されたアプリへ

10の質問に答えたなら、多くのプロジェクトが飛ばしている作業をもう終えています。次は、メイン機能を作り、iPhoneでテストし、サブスクリプションを組み込み、Appleへの提出準備をすることです。

これがiOS Kitの流れで、自分のペースで進められる4つのステップに分かれています。最初のステップでは、稼げるアプリとそのターゲット、価格を選びます。要件定義書はその出発点です。

自分のアイデアが1ページにまとまる段階か、わからない？ 無料の診断で、今プロジェクトを止めているものと、最初に取り組むべきステップがわかります。トップページでは、この枠組みからClaude Codeでモバイルアプリを作る方法を紹介しています。

収益も公開も約束はしません。審査するのはAppleで、その先を決めるのは市場です。キットがなくても、このテンプレートで始めるには十分です。

よくある質問

モバイルアプリの要件定義書はどう書けばいいですか？

要件定義書は1ページに収めます。質問は10個、答えはそれぞれ1〜2文です。対象ユーザー、問題、メイン機能、ビジネスモデル、アカウントなしでできること、残す必要があるデータ、プラットフォーム、最初のバージョンに入れないもの、成功のシグナル、制約について答えます。答えが2文を超えるなら、たいていはまだ決めきれていません。

アプリの要件定義書はどのソフトで書けばいいですか？

シンプルなメモか、プロジェクトのルートにあるテキストファイルで十分です。テンプレートをコピーして、各行を書き換えます。テンプレートと検証チェック表（.md）をダウンロードすることもできます。登録は不要です。AIに指示を出すなら、その後プロジェクトのコンテキストファイルに入れておきましょう。

アプリには40ページの要件定義書が必要ですか？

自分のアプリを作るなら不要です。1ページで十分です。ネットにある40ページのテンプレートは、開発会社にアプリを発注し、契約書類が必要な発注者向けに書かれています。あなたは決める人であり、作る人です。このページは、コードを書く前に決断し、AIにコンテキストを渡すためのものです。

コードを書くAIに要件定義書をどう渡せばいいですか？

ページをプロジェクトの常設コンテキストに入れます。Claude CodeはルートのCLAUDE.mdファイルを読み、Cursorには独自のルールファイルがあります。AIがやりすぎたら「バージョン1に入れないもの」のセクションを引用しましょう。大きな作業の前には、すぐにコードを書かせず、ページに沿った計画を求めます。

機能が要件定義書どおりか、どう確認すればいいですか？

機能ごとに、操作、期待する結果、証拠の3行を追加します。証拠は、計算なら自動テスト、操作フローなら実機での確認でかまいません。テストしていないことも書いておけば、「画面ができた」と「機能が使える状態になった」を取り違えずに済みます。

アプリの要件定義書に入れてはいけないものは何ですか？

避けるべきものは4つです。完全なデザインガイドライン、日単位のスケジュール、詳細な技術アーキテクチャ、そしてほかの項目に混ざった「後でやる」機能。最初は参考スクリーンショットが数枚、スケジュールは週ごとの目標で十分です。後でやる機能は、すべて「バージョン1に入れないもの」のセクションに入れます。