初心者が速く作れる 3画面スターターアプリ テンプレート

なぜ最初は3画面だけで始めるのか？

初心者は完成形を先に想像してしまいがちで、その結果スクリーンや機能、決定事項が山のように積み上がり、何も動かないまま立ち止まってしまいます。アプリを端から端まで動かせないとモチベーションは下がり、次に何を作るべきか分からなくなります。

3画面のスターターテンプレートはスコープを小さく保ちながら、本物のアプリらしさを感じられます。List（リスト）画面は表示するものを見せ、Add（追加）画面でデータを変更し、Settings（設定）画面で簡単な好みを保存できます。これらは一連のループを作ります：データを見る→データを追加する→基本的なオプションを変える→結果を見る。

3画面はまた、ほとんどのアプリで出てくる要素を練習させてくれて、細部に溺れずに済みます。

3画面のビルドで学べること

小さなテンプレートでも、より大きなプロジェクトに移行できるスキルを素早く練習できます：

• データフロー（アイテムがどこにあり、追加後にリストがどう更新されるか）
• ナビゲーション（画面間を予測可能に行き来する方法）
• バリデーション（空や不正な入力を防ぐ）
• プリファレンス（並び順などの小さな設定を保存する）
• 基本的なエラー処理（何か失敗したときに明確なメッセージを出す）

テンプレートが小さいので週末で仕上げられ、磨く時間も残ります。たとえばシンプルなブックトラッカーは、書籍のリスト、タイトルと著者を追加するフォーム、並べ替えを選ぶ設定ページから始められます。

テンプレート：List、Add、Settings

このテンプレートは小さいまま基本をカバーします：データ表示、データ作成、設定の保存。

画面1：List（ホーム画面）

List 画面は「今何があるか？」に答えます。アイテムを見やすく表示します。

空の状態は省略しないでください。まだアイテムがないときは短いメッセージと「最初のアイテムを追加する」のような明確なアクションを示しましょう。これは白紙の画面でユーザーを混乱させるのを防ぎます。

並び替えは最初はシンプルに。ひとつのルール（新しいものを先に、またはアルファベット順）を決めて徹底してください。後でオプションを追加する場合は別画面にせず、小さなコントロールで済ませましょう。

画面2：Add フォーム（アイテムを1つ作る）

Add 画面は初心者が最もバグを出しやすい部分なので、意図的に退屈に保ちます。本当に必要なフィールドだけを使ってください。簡単なタスクリストなら、タイトルと任意のメモだけで十分です。

バリデーションは親切で具体的に。必須フィールドが空なら、そのフィールド近くに短いメッセージを表示します。保存後は結果が明らかになるべきです：リストにアイテムが現れ、フォームはリセットされる（または画面が閉じられる）など。

画面3：Settings（機能ではなく設定）

Settings は小さく、実際に意味のあるものにします。いくつかのトグルと1つの単純なテキスト設定を入れて、ユーザーの選択を保存・読み込みする練習をします。例：ダークモードのトグル、「削除時に確認する」トグル、「表示名」のようなテキストフィールド。

基本フローは次の通りです：

• アプリを List 画面で開く
• Add をタップしてフォームを開く
• 保存して List に戻り、追加したアイテムを確認する
• アイコンやメニューから Settings を開き、設定を変更して List に戻る

小さなアプリのアイデアを選び、データを定義する

アプリが管理する「もの」を1つだけ選んでください。5つも6つも選ばないこと。タスク、連絡先、レシート、メモ、ワークアウト、植物、本などはどれもこのループに合います：アイテムを見る、アイテムを追加する、いくつかの設定を調整する。

良い小さなアイデアは一息で説明できます：「このアプリは ___ を追跡するためのもの」です。タグや推奨、同期、共有の説明が必要なら、それはもう小さくありません。

UI に触る前にデータを定義してください。あなたの「もの」のフィールドを3〜6個書き出し、どれが必須かをマークします。たとえばレシート項目は：store（必須）、total（必須）、date（必須）、category（任意）、note（任意） のようになります。短く保つことでトレードオフを強いられ、v1 を終わらせられる要因になります。

v1 の「完了」を厳密に定義しましょう。完了とは、アイテムを追加でき、リストで見られ、設定が小さくても実際に何かを変えることです。検索やアカウント、共有は含めません。

スコープを固める実用的な方法は、画面ごとに1文を書くことです：

• List 画面： 全アイテムと最も重要なフィールド（必要なら小さなステータス）を表示する。
• Add 画面： 必須フィールドのみで新しいアイテムを作る（オプションは1つまで）。
• Settings 画面： 並び順、通貨、オン/オフのような1〜2個の設定を管理する。

例：「ワークアウトアプリ」。List：日付と所要時間を表示。Add：日付、所要時間、任意のメモでワークアウトを追加。Settings：分表示か時間表示か、デフォルトのワークアウトタイプを選ぶ。これら3文を余計な機能を入れずに書けないなら、アイデアをさらに縮小してください。

意図的にデータモデルをシンプルにする

初心者向けのアプリはデータモデルが単純なほど速く作れます。目標は完璧なデータベースではなく、挙動が予測できること。そうすれば次の機能追加が大きな書き直しになりません。

アイテムの単一の信頼できる情報源を用意してください：リストが1箇所にだけ存在する（アプリ状態の1つの配列、またはサーバの1つのテーブル）。リストを複数画面にコピーしたり「一時的なリスト」を持つと、保存されたのに更新されない、のような奇妙なバグが生まれます。

List、Add、Settings 間で項目の形を一貫させてください。名前、型、デフォルトを決めて守ること。シンプルなアイテム例：

• id (string)
• title (string)
• createdAt (date or timestamp)
• done (boolean, default false)
• notes (string, default empty)

後からフィールドを追加するなら、すべての場所に適切なデフォルトで追加してください。初心者がよくするミスは、一方の画面で name を使い、別の画面で title を使うことや、done を真偽値と文字列（"yes"）の両方で扱ってしまうことです。

アプリが壊れやすく感じないように、いくつかの基本状態を計画しましょう：

• ローディング：データの取得や復元中に何を見せるか？
• 空の状態：アイテムがまだないときに何を見せるか？
• エラー：保存や読み込みが失敗したときに何を見せるか？
• 保存済み：ユーザーは成功をどう認識するか？

これらを具体的にしてください。リストが空なら短い文と Add を開くボタンを出します。保存が失敗したらフォームは消さずに「保存できませんでした。再試行してください。」のような平易なメッセージを表示します。

最後に、ローカルとサーバ保存の判断ルールを決めます：アプリが1台で使えて共有が不要ならローカルに保存、同期やログイン、複数デバイスでのアクセスが必要ならサーバを使います。多くのスタータープロジェクトはローカル保存で十分です。後でバックエンド（例：Go + PostgreSQL）に移すときも、アイテムの形を保てば UI はほとんど変わりません。

ステップごとに：3画面を順に作る

厳密な順序で作ってください。各ステップの終わりにアプリが使える状態であること（たとえ裏側はフェイクでも）が重要です。3画面テンプレートの目的は、常にタップして試せるものを持ち続けることです。

1) まず List 画面（最初はダミーデータ）

List 画面を作り、5〜10個のサンプルアイテムをハードコードします。各アイテムは表示に十分なフィールドだけを持たせます（例：title、短い note、status）。

空の状態は早めに入れます。トグルで切り替えられるようにするか、最初から空の配列で始めても良いです。短い友好的なメッセージと「Add item」のような明確なアクションを表示します。

リストに小さなコントロールを1つ入れるなら控えめに。タイトルでフィルタする検索ボックスや「アクティブのみ」フィルタ1つで十分です。大げさなシステムにしないでください。

2) Add 画面を作る（まず保存はせずに）

リストで必要な同じフィールドを使ってフォーム UI を作ります。最初は保存を接続せず、入力のレイアウト、ラベル、はっきりしたプライマリボタンに集中します。

その後、修正箇所をユーザーに伝えるバリデーションを追加します：

• “Title is required”
• “Title must be under 40 characters”
• “Pick a status”

次に Save をつなげて、新しいアイテムがリストに表示されるようにします。最初はメモリ内の状態（再起動でリセットされる）で良いです。最初の成功は、新しいアイテムが即座に表示されることです。

3) 最後に Settings を追加し、可視的な挙動に結びつける

設定は小さくし、各設定が何か目に見える変化を与えるようにします。「コンパクト表示」トグルでリストの間隔が変わる、「完了済みを表示する」トグルで表示アイテムが変わる等。設定が何も変えないなら、その設定はまだ不要です。

小さな UX の工夫で実際のアプリ感を出す

初心者のアプリが「本物っぽく」感じられるのは、画面が余計なタップなしに小さな問いに答えるときです。これらの工夫は手間がさほど増えず、摩擦を減らします。

List 画面：混乱を減らす小さな手がかり

上部にアイテム数や「さっき更新されました」のような一行を表示します。状態があるなら「Open」や「Done」のような短いタグで示すと一覧で判別しやすくなります。

ルール：ユーザーが「何個ある？」や「これ今の状態？」と聞けるなら、リスト画面で答えを出してください。

Add フォーム：デフォルトと明確な完了動作

Add 画面はメモアプリより速く入力できるべきです。デフォルト値を使い、最小限の操作で送信できるようにします。入力タイプはデータに合うように：数量は数値キーパッド、日付は日付ピッカー、オン/オフはトグルなど。

プライマリボタンは目立つようにしてラベルをはっきりさせます。「Save」でもよいですが「Add to list」の方が分かりやすい場合もあります。

有効な小さな工夫：

• 最初のフィールドに自動でフォーカスを当てる
• よく使う値を事前入力する（例：quantity = 1）
• エラーはフィールド横に短く表示する
• 必須が有効になるまでプライマリボタンを無効にする
• 送信後にフォームをクリアするかリストに戻して簡単な確認を表示する

Settings：動作を変えるオプションだけ残す

設定がジャンクドロワーにならないように、2〜3個の実際に挙動に影響するオプションだけにします。例えばソート順、単位（分/時間）、完了済みをアーカイブするトグルなど。各設定は即時にリストに効果が見えるべきです。

使いやすくする：キーボード、フォーカス、基本的なアクセシビリティ

多くの初心者アプリはキーボードでボタンが隠れたり、フォーカスが飛んだり、タップ領域が小さすぎたりして操作感が悪くなります。これらを早めに直すとテストが格段に楽になります。

チェック項目：

• キーボードからフォームを送信できるか（Next、Done）
• フォーカスは上から下に自然に移動するか
• ラベルはプレースホルダだけでなく常に見えるか
• ボタンはタップしやすい大きさか
• ステータスタグは色だけでなくテキストがあるか

買い物リストは良い例です：デフォルト数量1、リスト上の「Bought」タグ、そして「通路別にグループ化する」設定があるだけで、3画面に収めつつ実用的になります。

初心者を遅らせるよくある落とし穴

最速で詰まる原因は、アプリが端から端まで動く前にスコープを広げてしまうことです。このテンプレートの目的は動くループを作ること：リストを見る、追加する、1〜2個の設定を変えて実際に挙動が変わるようにすることです。

よくある遅延要因：

• 最初からアカウント実装。 パスワードルールやメール周り、エッジケースが増えます。まずはシングルユーザーで。
• UI が動く前にデータベース設計にこだわる。 リスト画面がまだ空ならテーブルを増やしても役に立ちません。
• 挙動と結びつかない設定。 設定がどこで使われるか指摘できないなら省きます。
• バリデーションを省く。 基本的なチェックがないとデータが信頼できず、バグがランダムに見えます。
• 追加が安定する前に編集・削除に飛びつく。 Add が不安定だと編集・削除で問題が増幅します。

例えば家族アカウントを早期に導入すると、誰もが「牛乳」を追加できる前にログイン画面や認証周りに多くの時間を取られます。バリデーションを省くと空白行だらけのリストになります。

拡張したい衝動が出たら、代わりに次を行ってください：

1. Add フローを誰が見ても誤解しない設計にする（ラベル、デフォルト、明確なボタン文言）。
2. ひとつのバリデーションルールとひとつの親切なメッセージを追加する。
3. ひとつの設定を追加し、それが即座にリストに反映されるようにする。
4. 大きな変更前に動くスナップショットを保存しておき、必要ならロールバックする。

コアループを守れば、後から編集・削除・アカウントを追加しても一から作り直す必要はありません。

画面4を作る前の簡単チェックリスト

検索やタグ、アカウント、通知を追加する前に、まず既にある3画面がしっかり動くか確かめてください。基本が遅かったり分かりにくかったりすると、新機能はその痛みを何倍にもします。

後で助かる5つのチェック

初めて使うユーザーを想定して、小さい画面で片手でテストします。

• Add フローの速さ： アプリ起動から新しいアイテムの保存までが速く感じるか。30秒以上かかるならフォームが長すぎるか、ボタンが見つけにくいか、デフォルトが不適切です。
• リストの耐久性： 空のときも見栄えがよく、何十件あっても使えるか。スクロールや間隔、名前の折り返しを確認します。
• エラーの明確さ： メッセージは直すべき点を示しているか。“Invalid” だけでは不十分です。“Name can’t be empty” のように具体的に。
• 設定の効果： すべての設定は即座に分かる変化を引き起こすか。
• データの生存性： 永続化を選んだならアプリを閉じて再度開いてアイテムが残っているか。読み込みが混乱を招かないか。

簡単なスクリプト：3つアイテムを追加し、わざと1つでミスをして、設定を変え、アプリを再起動する。どのステップでも不安があれば、それを直してから4画面目に進んでください。

例：小さく保った買い物リスト

買い物リストはこのテンプレートに最適です。実用的に感じられる一方で大きくなりすぎません。アイテムを保存し、新規追加し、いくつかの設定を選ぶだけです。

必要な最小データ

各買い物アイテムは以下のようなレコードで足ります：

• Name（例：「eggs」）
• Quantity（例：12）
• Store（例：「Trader Joe’s」）
• Notes（任意、例：「free range」）
• Created date（追加時に自動設定）

これだけで作成と表示を練習できます。

実際に変化を起こす設定

Settings は小さく保ち、各項目がすぐ分かる効果を持つべきです。このアプリならデフォルトの店舗、店舗でグループ化、ダークモードのトグルの3つで十分です。

短いウォークスルー：

アイテムを2つ作成します：

1. Name: “Bananas”, Quantity: 6, Store: “Costco”, Notes: “green”
2. Name: “Milk”, Quantity: 1, Store: “Whole Foods”, Notes: (空白)

List に戻ると、両方のアイテムと店舗、数量が見えるはずです。created date を表示するなら「Added today」のように控えめにします。

次に Settings を開いて Default store を “Costco” に設定します。Add に戻って “Bread” を作成すると、Store フィールドが既に入力されているはずです。その単純な変化だけで Settings の価値が分かります。

次に “Group items by store” を有効にして List に戻ると、項目が “Costco” や “Whole Foods” の見出しでグループ化されます。

最後にダークモードを切り替えると、アプリが即座にテーマを反映するはずです。もう少し学びたいなら、ダークモードが再起動後にも保持されるようにしてみてください。

次のステップ：3画面からフォーカスを失わずに拡張する

3画面が端から端まで動くようになったら、次の目標は「画面を増やす」ことではなく、小さくても有用な振る舞いを1つ追加することです。変更を1文で説明できないなら、それは大きすぎる可能性が高いです。

機能は1つずつ追加して完全に仕上げます（UI、データ、空の状態、簡単なテスト）。最初の良いアップグレードは、アイテムの編集、取り消し可能な削除、長くなったときの検索、シンプルなカテゴリー追加などです。

1つのアップグレードを出荷したら立ち止まり、その変更がアプリを明確にしたか、それともただ複雑にしただけかを自問してください。初心者は同じデータに対して複数の機能を重ねてしまい、アプリがすぐに乱雑になります。

いつバックエンドを追加すべきか

個人用で単一デバイスならバックエンドなしで始めます。サインイン、同期、他者との共有、確実なバックアップが必要になったらバックエンドを追加します。

バックエンドを導入するときは最初のバージョンを地味に保ち、既にあるデータをそのまま保存・読み込みするようにします。役割や分析のような高度な機能は、CRUD が安定してから検討してください。

変更を安全に保つ（スナップショットとロールバック）

拡張していくとき、一番のリスクは既に動いている部分を壊すことです。小さなチェックポイントで作業し、大きな機能を加える前に現在の動作するバージョンのスナップショットを取っておきましょう。新機能で問題が出たらロールバックして、より小さなステップでやり直します。

チャット中心でこのテンプレートを作りたいなら、Koder.ai (koder.ai) はプレーンランゲージのプロンプトからウェブ、バックエンド、モバイルアプリを生成するために設計されており、スナップショットとロールバックをサポートしているので、動くバージョンを失わずに反復できます。

メインの考え方は変わりません：大きな書き直しを避け、小さく安全なアップグレードでアプリを成長させていきます。