ユーザーと成果から始める
誰がアプリを使うのか、何を達成する必要があるのか、成功した結果とはどのようなものかを書き出します。20個の機能リストから始めるのは避けましょう。たとえば、小さなスタジオが顧客からの依頼を記録し、ステータスを割り当て、今週対応すべき内容を確認する必要があるとします。この説明によって、実装の詳細を知る必要なく、Base44に有用なプロダクトの範囲を伝えられます。
最初のプロンプト
会社全体の業務システムではなく、完全なワークフローを1つ依頼しましょう。
実践的な構築ガイド
作り始めるための初心者向けBase44チュートリアル
この初心者向けBase44チュートリアルでは、小さくテスト可能なワークフローを通じて、漠然としたアイデアを動作するアプリに変えていきます。適切なスタート方法を選び、最初のバージョンを作成し、重要な動作を確認して、共有できる状態に整えます。
自分に当てはまるケースを判断する
長いプロンプトを書く前に、現在の出発点に合ったルートを選びましょう。適切なケースを選ぶことで、最初の構築を確認しやすい規模に保てます。
7 min readパスA
アイデアがまだ一文や問題提起、頭の中のスケッチにとどまっている場合は、このルートを使います。
文章を焦点の絞られたプロンプトに変える
主な画面、それぞれの画面に必要なフィールド、ユーザーが実行できるようにすべき操作を挙げます。各操作の後に何が起きるべきかを明記します。初心者向けの有用なプロンプトでは、ダッシュボード、新規リクエストフォーム、詳細ビュー、ステータスフィルター、リクエストを編集またはアーカイブする方法などを求めるとよいでしょう。具体的な言葉を使い、最初の結果から不明点を明らかにします。
プロンプトの形
対象ユーザー、画面、データフィールド、操作、最初の成功条件を含めます。
拡張する前に最初のバージョンを確認する
実際のユーザーになったつもりでアプリを操作します。レコードを作成、編集、フィルタリングし、ページを更新して、フィールドが空欄のときに何が起きるかをテストします。ワークフローをより明確にする最小限の変更を記録します。Base44は、各レスポンスを最終的な判定ではなく、反復の1回分として扱うと最も役立ちます。
反復のルール
一度に1つの動作だけを変更し、どのプロンプトが結果を生んだのか把握できるようにします。
パスB
スプレッドシート、フォーム、業務プロセス文書、簡単なプロトタイプなど、すでに翻訳対象の素材がある場合はこの経路を使います。
-
1
すでに存在するものを洗い出す
素材をデータ、画面、ルール、未解決の疑問に分けます。スプレッドシートには有用なフィールドが含まれていても、明確な権限設定がない場合があります。業務プロセス文書には判断内容が説明されていても、正確な入力形式が抜けていることがあります。Base44に何かを再構築させる前に、こうした不足を明らかにします。
-
2
役立つ最小限の範囲を再構築する
既存の素材から1つの役割と1つのユーザージャーニーを選びます。対応する画面フローを求め、どの部分が正式な情報源なのかを説明します。その後、1回のリクエストですべてのページを再現しようとせず、生成された結果を元の資料と比較します。
-
3
実際の例で動作を確認する
不完全なケースと通常とは異なるケースを1つずつ含む、代表的なレコードをいくつか使います。ラベル、バリデーション、並べ替え、保存状態を確認します。この範囲が安定したら、同じ用語を使って次の役割やワークフローを追加します。
最終確認
最初のバージョンが完成したと判断する前に、このチェックリストを使って、簡単な見た目の確認では見落としやすい問題を見つけます。
必須
任意
-
アプリの主なユーザーが1人明確に定義され、1つの完全なワークフローがある。
必須ワークフローを1文で説明できない場合は、範囲を縮小します。
-
重要な各フィールドに、平易な言葉によるラベルと、理解しやすい空の状態が設定されている。
必須 -
作成、編集、削除、アーカイブ、またはステータス変更の操作は、ラベルどおりに実行されます。
必須 -
ページを更新しても、記録が予期せず失われたり、重要な選択がリセットされたりすることはありません。
必須 -
無効または不完全な入力に対して、何も起こらないのではなく、役立つ指示が表示されます。
必須 -
想定しているユーザーが利用しそうな画面サイズでレイアウトが適切に機能します。
任意狭いスマートフォンのビューポートと、より大きなデスクトップのビューポートを確認します。
-
サンプルの記録、プレースホルダーの文言、テスト専用のコントロールを削除しています。
任意 -
共有する前に、機密データ、外部サービス、アクセスルールを確認しています。
必須インターフェースが動作することを、セキュリティポリシーが完全である証拠とみなさないでください。
タスク別に学習を続ける
次の質問がより具体的になったとき、これらの関連ガイドが基本的なワークフローを変えずに、自然な次のステップを提供します。
最初の作業結果と確認済みバージョンを比較する
初心者に役立つワークフローは、色を変えるだけではありません。メインのアクションを明確にし、不確実さを取り除き、それぞれの画面に役割を持たせます。
最初の作業結果
確認済みの作業結果
区切り線をドラッグして、構成、ラベル、ワークフローの重点を比較します。
この方法の限界を知る
初心者向けのワークフローは、意図的に範囲を絞っています。何を証明できないのかを知ることで、洗練された最初の画面によって誤った確信を抱くのを防げます。
-
プロダクトに関する意思決定の代わりにはならない
Base44は、明確なリクエストをインターフェースやワークフローに変換できますが、本当にそのプロダクトを必要としている人や、どのトレードオフが最も重要かを判断することはできません。
回避策想定するユーザーに数人インタビューし、初版で解決すべき問題を1つ書き出します。
-
生成された動作を完全に保証することはできない
完成しているように見えても、エッジケース、権限ルール、データの遷移が正しく動作しない場合があります。
回避策代表的なレコードをテストし、ユーザーの視点から各操作を説明しながら確認します。
-
機密データを自動的に安全にすることはできない
個人情報、アクセス制御、外部接続には、見た目の確認だけではない、意図的なレビューが必要です。
回避策機密データを最小限に抑え、アクセスに関する期待事項を定義し、高リスクのユースケースでは有資格のセキュリティ専門家に助言を求めます。
-
継続的なメンテナンスの代わりにはならない
公開したアプリにも、コンテンツの更新、ユーザーからのフィードバック、バグの確認、次に何を変更するかの判断が必要です。
回避策課題リストを短くまとめ、最も重要なワークフローを定期的に見直します。
作業スタイルを選ぶ
同じ構築方法でも、出発点となる素材に合わせて調整できます。自分のプロジェクトに最も近いタブを選択してください。
一文から実際に動くフローへ
ユーザー、成果、画面、アクションから始めます。Base44には最初のルートだけを作成するよう依頼し、その結果を使って不足している詳細を見つけます。
- 主要なユーザーを1人決めます。
- 成功した状態を1つ説明します。
- 必要最小限の画面とフィールドを一覧にします。
- 2つ目のワークフローを追加する前にテストします。
行と列から、役立つレコードへ
各列の意味、必須フィールド、レコードに対してユーザーが行うべきことを説明します。スプレッドシートのレイアウトが、すでに優れたアプリ体験になっているとは限りません。
- 各行が表しているレコードを特定します。
- 表示用フィールドと内部用フィールドを分けます。
- 作成、編集、絞り込み、アーカイブの動作を定義します。
- 未完了のレコードと重複したレコードを確認します。
手作業のルーティンから、ガイド付きアプリへ
現在の手順、判断、引き継ぎ、例外を説明します。最も頻繁に発生する経路から構築し、よくある混乱を防ぐルールを後から追加します。
- 現在の手順を平易な言葉で書き出します。
- 判断が必要な箇所と担当する役割を示します。
- 通常の例を1つ、通常とは異なる例を1つ含めます。
- そのワークフローを実行している人と一緒に確認します。
説明できる小さなバージョンを作る
実際のワークフローを1つBase44に取り込み、現実的な例でテストし、焦点を絞ったプロンプトで改善します。役立つ検証にたどり着かない大規模な仕様書より、最初は範囲を絞ったアプリを作るほうが多くを学べます。
最初のワークフローを作成する- 1つのユーザージャーニーから始める
- 拡張する前にテストする
- 確認後にのみ公開する
チュートリアルに関するよくある質問
初めてガイド付きビルドを始める前に、よく寄せられる質問への回答。
トラッカー、ディレクトリ、予約フロー、軽量な社内ツールなど、主なユーザーが1人で、成果が目に見える小規模なアプリを選びましょう。複数の役割、複雑な請求、大規模なソーシャルプロダクトから始めるのは避けてください。基本的なワークフローが機能しているか判断しにくくなるためです。
対象ユーザー、目的、画面、フィールド、操作については具体的に説明しますが、実装の細部まですべて指定しようとする必要はありません。焦点を絞ったプロンプトなら、Base44が有用な初回案を作成するために十分なコンテキストを提供しながら、結果を確認して改善する余地も残せます。
初心者でも、自然言語の指示を使って、従来のコードを書かずに多くのアプリのワークフローを作成し、改善できます。ただし、プロダクトに関する意思決定を行い、結果をテストし、扱うデータを理解し、プロジェクトに機密性の高い要件や技術的に複雑な要件が含まれる場合は助けを求める必要があります。
通常のデータ、未入力のデータ、想定外のデータを使って、ユーザーの一連の操作を最後まで実行します。操作が正しく保存されること、ラベルが明確であること、利用が想定されるデバイスでレイアウトが機能すること、プレースホルダーのコンテンツが削除されていることを確認してください。アプリのアクセス権とデータの取り扱いに関する要件を理解してから共有しましょう。
まず、最も重要な具体的な動作と結果を比較し、具体例を使って一度に1つの修正を説明します。違いを説明せずにリクエスト全体を書き直すのではなく、どのユーザー、画面、フィールド、または操作が間違っているのかを明確にしてください。