プロンプトエンジニアリングとは？非エンジニアのための実践ガイド

プロンプトエンジニアリングとは、AIモデルから望みどおりの結果を安定して得られるように、指示文を書き、改善していくことです。プロンプトとは、モデルに与えるものすべてを指します。質問、作業の依頼、背景情報、例などです。エンジニアリングするとは、何を入れるかを意図をもって決め、出てきた結果を検証し、調整していくことです。魔法のような言い回しを探すことよりも、明確に伝えることが大切です。

AIでアプリを作るときに重要な理由

AIアプリビルダーでは、プロンプトがそのまま仕様書になります。AIは説明された内容しか作れず、依頼に抜けがあると、もっともらしい推測で埋めてしまいます。その推測が当たることもありますが、意図と違うことも多くあります。例えば、不要なフォーム項目、頼んでいない機能、対象の利用者に合わないデザインなどです。

明確なプロンプトは修正の往復を減らします。往復のたびに時間がかかり、多くの場合クレジットも消費します。また、アプリの中にAIを組み込む場合にも、プロンプトは重要です。そのモデルへの指示によって、チャットボットが顧客にどう話すか、何を断るか、事実に沿って答えるかが決まります。アプリ作成に特化した内容は、AIアプリビルダー向けのプロンプトの書き方をご覧ください。

日常の例え

あなたのビジネスを何も知らず、会ったこともない腕の良いフリーランサーに仕事を頼む場面を想像してください。依頼を終えた瞬間に、相手は作業を始めます。

「ロゴを作って」と頼めば、とりあえずのロゴは出てきます。「ドバイの子ども向け水泳教室のロゴ。親しみやすいけれど幼すぎないこと。青とオレンジ。小さくしても水泳帽の上で見えること。気に入っている例が2つ、気に入らない例が1つあります」と頼めば、狙いにかなり近いものが出てきます。

AIモデルはこの腕の良いフリーランサーに似ています。優秀で速いけれど、依頼内容にすべて頼っています。プロンプトエンジニアリングとは、良い依頼文を書けるようになることです。

基本的な手法

具体例：書き換え前と後

書き換え前：

ジムのアプリを作って。

AIはすべてを推測するしかありません。会員向けかスタッフ向けか。クラス制か個人トレーニングか。決済はあるのか。結果として、一般的なダッシュボードと架空のワークアウトが出てくる可能性が高いです。

書き換え後：

小規模なボクシングジム（会員約150名）向けのWebアプリを作ってください。

利用者： 会員はスマホでクラスを予約します。オーナーのSamはパソコンでタイムテーブルを管理します。

会員にできること： 今週のクラス（時間、コーチ、空席数）を確認し、開始の2時間前まで予約・キャンセルできること。

Samにできること： クラスの追加、編集、キャンセルと、各クラスの予約者の確認。

ルール： 1クラス最大12名。同じ時間帯の二重予約は不可。

今回は対象外： 決済、ワークアウトの記録、モバイルアプリ。

デザイン： 暗い背景、赤のアクセント、タップしやすい大きなボタン。

作り始める前に、不明な点を一覧にして、作成するページを説明してください。

2つ目のプロンプトは賢いから良いのではなく、情報がそろっているから良いのです。利用者、操作、ルール、対象外の項目、そして開始の仕方が書かれています。最後の一文でAIに計画と質問を促しており、コードを書く前に認識のずれを防げます。

アプリ内のプロンプト

アプリ自体がLLMを呼び出す場合、そのプロンプトは多くの利用者に向けて何度も実行されます。基本原則は同じですが、さらにいくつか押さえておくべき点があります。

• システムプロンプト： あらゆる回答を方向づける常設の指示です。役割、口調、ルールを定めます。例：「あなたは植物店Leaf & Potのアシスタントです。注文、植物、配送に関する質問だけに答えてください。」
• 根拠づけ（グラウンディング）： モデルが使うべき事実、例えば方針や商品カタログを含め、それに基づいて答えるよう指示します。理由はLLMとは何かをご覧ください。
• 代替動作： 不確かなときの対応を決めます。例：「提供された情報に答えがない場合は、その旨を伝え、サポートのメールアドレスを案内してください。」
• 出力形式： コードが回答を読み取るなら、JSONなどの厳密な形式を指定します。
• テスト： 実際の利用者より先に、扱いにくい入力を試します。失礼なメッセージ、話題外の質問、指示を無視させようとする試み（プロンプトインジェクションと呼ばれます）などです。

主な用語

よくある間違いと誤解

• 魔法の言葉を探すこと。 「あなたは世界一の専門家です」より、本当に必要なことを伝えるほうがずっと効果的です。
• 一度にすべてを頼むこと。 20の機能を一度に依頼すると、中途半端な機能が20できあがります。段階的に作りましょう。
• 解決策を説明して、問題を説明しないこと。 「3列の表を追加してください」より、「Samは、どのクラスに誰が予約しているかを一目で確認したい」のほうが役立ちます。
• やってほしくないことを書かないこと。 ログイン、決済、デザイン変更をまだ望まないなら、はっきり伝えましょう。
• 結果を読まないこと。 次に進む前に、作られたものを「完成」の定義と照らし合わせて確認しましょう。
• 最初からやり直すこと。 多くの場合、プロンプト全体を書き直すより、「おおむね良いです。Xだけ変えてください」と短く追加するほうが効果的です。
• 秘密情報をプロンプトに貼り付けること。 ツールが安全に保管する仕組みを持たない限り、パスワードや本番のAPIキーをチャットに貼らないでください。

AIビルダーに頼むと良いこと

• 「作る前に、質問と計画を見せてください。」
• 「私の要望を、3文で言い換えてください。」
• 「予約フォームだけを変更し、他には触れないでください。」
• 「私が指定しなかったことで、何を想定しましたか？」
• 「私のメモを、利用者、機能、ルール、対象外の項目を含む短い仕様にまとめてください。」詳しくはAIを使った製品要求定義書の作り方をご覧ください。
• 「今回の依頼は、どう書けばもっと良く伝わったか提案してください。」

Mythexでのプロンプト

Mythexには、この進め方に合う3つのチャットモードがあります。Planは、変更の前に進め方を合意するモードです。Buildは、変更を加えるモードです。Askは、ファイルを編集しない質問のためのモードです。スクリーンショットやモックアップを文脈として添付でき、変更がうまくいかなかった場合はチェックポイントに戻せます。効果的なプロンプトと反復改善のドキュメントに、さらに多くの例があります。繰り返しの進め方については、AIで作ったアプリの改善方法をご覧ください。

よくある質問