実践的な手順ガイド

初心者向けEmergentチュートリアル:初めてのアプリを作る

この初心者向けEmergentチュートリアルでは、幅広いアイデアを小さく検証可能なプロジェクトに変えていきます。自分の出発点に合う手順に沿って進み、共有したり開発を続けたりする前に、最後のチェックを行いましょう。

無料で開始 · 共有前に確認

自分がどのケースに当てはまるか判断する

現在のプロジェクトに最も合うルートを選びましょう。範囲を小さくすると、システムが解決すべき前提が減り、最初の結果をより明確に評価できるようになります。

アイデアしかない

パスAを選びます。役立つ成果を1つ説明し、それを使う人を挙げ、最初のバージョンをいくつかの重要な操作に限定します。

すでに下書きがある

パスBを選びます。うまく機能している部分から始め、最も重要な1つの変更を特定し、全面的な書き直しではなく、焦点を絞った改善を依頼します。

レビューの準備ができている

最後のチェックを行います。主要なフローをテストし、結果をブリーフと比較して、次に行う変更を優先順位順に整理します。

パスA:シンプルな概要から始める

パスAは、白紙の状態から始める人向けです。目的は、考えられるすべての機能を説明することではありません。確認して改善できる、明確な最初の成果をEmergentに伝えることです。

アイデアを持つ人

あなたは問題を把握していますが、画面、項目、ワークフローはまだ決めていません。誰が助けを必要としているのか、成功とはどのような状態かを1文で書きましょう。

つながりのない機能を長々と列挙する代わりに、具体的な初回バージョンを得られます。

Emergentで何を作れるか

学生プランナー

学習、スケジュール管理、研究の整理に使う小さなプロジェクトが必要です。中心となるビューを1つ、入力フローを1つ、役立つステータス表示を1つ依頼しましょう。

実際の日常的な問題を解決しながら、内容を把握できる十分に小さなプロジェクトに保てます。

学生向けEmergent

新しいビルダー

優れたプロンプトに何を含めればよいか分からない場合は、対象者、目的、必要な操作、希望するトーン、重要な制約を明記しましょう。

最初の回答から有用な方向性が得られ、修正すべき具体的な詳細も分かります。

Emergentの使い方

ビジュアルを重視する人

レイアウトや見せ方を重視する場合は、中心となるタスクを示した後に、階層、ナビゲーション、色の雰囲気、コンテンツの密度を説明しましょう。

インターフェースがワークフローを支え、作業の妨げになりません。

Emergent AIウェブサイトビルダー

パスB:既存のビルドを改善する

パスBは、すでに形になっているプロジェクト向けです。開始時のバージョンと目指す結果を比較し、一度に1つの変更だけを指定して依頼しましょう。

開始時の下書き

基本的な構成を備えた初期プロジェクト案
セクションとアクションがより明確になった洗練されたプロジェクトフロー
焦点を絞った修正

優れた修正では、うまくいっている部分を維持し、何が変わったかを説明し、次のテストを明確にします。

最終確認:概要とビルドを比較する

次の修正を依頼する前に、この並列レビューを使用してください。役立つ次のプロンプトと、すべてを改善してほしいという曖昧な依頼を区別できます。

元の要件 現在のビルド
1

主なユーザー

元の要件

プロジェクトが支援する対象者

現在のビルド

現在のインターフェースが対象としているように見えるユーザー層

2

主な成果

元の要件

ユーザーが到達すべき1つの結果

現在のビルド

現在のワークフローで生み出される結果

3

主要なアクション

元の要件

最初のバージョンに必要な少数のアクション

現在のビルド

実際に表示され、使用できるアクション

4

コンテンツ構造

元の要件

グループ化または優先順位付けが必要な情報

現在のビルド

画面に表示される階層、ラベル、セクション

5

不足している詳細

元の要件

現在のビルド

6

次のリビジョン

元のブリーフ

現在のビルド

7

成功テスト

元のブリーフ

現在のビルド

1つの明確なアイデアをテスト可能なプロジェクトに変える

始める前に完璧な仕様を用意する必要はありません。焦点を絞ったブリーフをEmergentに渡し、最初の結果を確認して、目標と一致しない部分があれば具体的なリビジョンを依頼しましょう。

  • まずは1つの主要な成果に集中する
  • 追加要素を加える前にメインフローを確認する
  • 次のプロンプトで優先度の高い問題を1つ修正する

チュートリアルFAQ

このチュートリアルの背景にある、初心者からよく寄せられる質問への回答です。

最初は、大規模なプロダクトのアイデアではなく、成果に焦点を当てた小さなプロジェクトから始めるのが最適です。対象ユーザー、主なタスク、最初のバージョンに必要な少数の操作を説明し、範囲を広げる前に結果を確認しましょう。

まず、何を作りたいのか、誰が使うのかを説明する、平易な言葉のブリーフを書きましょう。そのブリーフを送信し、生成されたフローを確認して、目標と現在の結果の違いをもとに具体的な変更を依頼します。

ユーザーの主なタスクに合った形式を選びましょう。情報を提示するならシンプルなウェブサイトがよい出発点になります。一方、データの入力、進捗の記録、繰り返しの操作が必要なら、アプリ形式のプロジェクトが適しています。

重要な曖昧さをなくすのに十分な詳細を含めますが、実装上の判断をすべて定義しようとする必要はありません。ユーザー、目的、不可欠な操作、コンテンツ、制約を明記し、最初のバージョンを見た後でレイアウトや動作を調整できる余地を残しましょう。

すぐにやり直さないでください。最も重要な不一致を特定し、望ましい動作や表示を説明して、すでに機能している部分を維持したまま、その1点に絞った変更を依頼しましょう。

開発を始める
開発を始める