Zenn
💻

生成AIのプロンプト設計について、Chatgptに聞いてみた！

に公開
初心者
プロンプト
生成 AI
idea

この記事について

  • この記事は、生成AIについて、以下の人向けです。
    • まだ全く知らない人
    • これから使ってみようと思う人
  • 生成AIを使う上で一番最初に大事なものとしては、生成AIに対する指示書（プロンプト）が大事ということを理解してもらうために書いております。
  • 餅は餅屋ということで、Chatgptに聞いた内容をまとめております。

注意事項

  • 生成AIを使う上での注意事項
    • 生成AIの回答内容は、参考程度にしましょう。
    • 聞くたびに回答も変わります。

その１：プロンプトとはなんだろう？？

プロンプトが何かを聞いてみた！

あなたは、生成AIの第一人者でありITアーキテクトです。以下に精通しております。
・生成AI自体を開発すること
・生成AIを使ったシステム・アプリケーション開発
・生成AIをプロダクトに組み込む開発

私は、生成AIに関して素人で、10年程度のシステム開発経験があるバックエンドエンジニアです。
これから生成AIをプロダクトや開発ツールにて使っていくにあたり、生成AIに対するプロンプトが重要と知りました。

学習していくにあたり、まず、プロンプトとは何かを教えてください。

もらった回答を一言で言うと

  • 要は、ちゃんと指示を出そうということです。
    いい感じにしといて言われても・・・いい感じの定義を伝えないと、あなたが思い描いているいい感じは、わからないよね。
    （人間対人間でも指示が曖昧だと、曖昧なものが出来上がるのと同じだよね）

もらった回答の要約は・・・

  • 要約すると以下となる。(要約し、一部加工。実際の返答分は、Appendixを参照)。

    • プロンプトとは、生成AIに与える「入力文」であり、AIにとっては処理対象データ、人間>にとっては指示書。(SQLのクエリに似ていますが、厳密さはなく自然言語で曖昧なままでも動作します)。

    • 役割は大きく3つあり、設計が曖昧だと意図しない答えになるため、アーキテクトの設計図の>ように工夫する必要。

      • ①何をするか伝える「指示」
      • ②背景や前提を与える「文脈」
      • ③出力形式を制約する「条件」

    • 学習のステップとしては、以下の流れが有効です。

      • まず質問してみる
      • 次にAIに役割を与える
      • 制約を加える
      • リファクタリングのように改善する

    • 要するにプロンプトは「自然言語による仕様書」であり、文脈・制約・目的をうまく記述する>ことで、より正確で役立つ応答を引き出せます。

その２：どんなプロンプトが良いのだろうか？

より良いプロンプトも聞いてみた！

どんなプロンプトを投げるとより良い回答がもらえるのでしょうか？

もらった回答を一言で言うと

  • 生成AIに◯◯な専門家になりきってもらって、こちらの状況と求めているものををしっかり伝えるということ。

もらった回答の要約は・・・

生成AIから良い回答を得るには、プロンプト設計が重要です。
ポイントは4つあります。

  • ①ロールを指定すること。
    • 回答者の立場や専門性を明示すると内容が的確になります。
  • ②目的を明確化すること。
    • なぜ知りたいかを伝えると、実務に直結した回答が得られます。
  • ③制約を与えること。
    • 表形式やサンプルコード付き、文字数制限など条件を付けるとすぐ使える出力になります。
  • ④文脈を提示すること。
    • 自分のレベルや状況を伝えると、不要な説明が減り適切な粒度の回答が返ります。

さらに、一度で完璧を狙うより「要約して」「コードのみで」と追加指示を重ねることで精度が上がります。

結論として、

  • プロンプトは「役割・目的・制約・文脈」を組み合わせることで、より高品質で実務的な回答を引き出せる仕様書のような役割を果たします。

その３：プロントの設計方法どうやるんだろう？

次に、プロントの設計方法ってあるの？

もらった回答を一言で言うと

  • ゴールを明確にし、4要素の役割、目的、文脈、制約を埋め、施行と改善を繰り返す　と言うことです。

もらった回答の要約は・・・

プロンプトには設計方法があり、勘に頼らず設計図のように組み立てると安定した回答を得られます。
基本は以下の4要素です。

  • 「Role（役割）」
    • RoleではAIに誰として答えるかを指定
  • 「Task（目的）」
    • Taskでは何をしてほしいかを明確に伝えます
  • 「Context（文脈）」
    • Contextで前提や状況を与えると不要な説明が減り
  • 「Constraint（制約）」
    • 表形式や文字数制限を指定すると実務で使いやすい出力になります。

設計手順は、①ゴールを明確化、②4要素を埋める、③試行と改善の流れです。

例えば「Javaに詳しい講師」とロールを設定し「JavaとTypeScriptの違いを表形式で」と制約を付けると、期待通りの回答が得られます。
結論としてプロンプトは要件定義と同様に設計し、反復改善することで高品質な結果につながります。

その４：プロンプト自体を作り上げていくのはあり？

プロンプト自体をやり取りしながら、作り上げていくとかはできるの？

もらった回答を一言で言うと

  • むしろそれが一番自然、1度完成ではなく、徐々に膨らませていく感じです。

もらった回答の要約は・・・

  • プロンプトは一度で完璧に仕上げる必要はなく、AIとのやり取りの中で磨いていくのが効果的です。
    まず大まかな指示を投げ、AIの回答を確認してズレを見つけます。
    その後、以下など追加指示を重ねることで、プロンプトは徐々に精度を増していきます。
    • 「表形式にして」
    • 「比較を追加して」
    • 「初心者向けに簡単に」
  • 最終的には、繰り返し使えるテンプレートとして整理でき、再利用が可能になります。
  • このプロセスはコードや要件定義のリファクタリングに近く、AIを相棒として設計を進化させるイメージです。重要なのは一発完成を狙わず、対話の中で調整することです。
  • 結果として、プロンプト自体が資産化され、より正確で実務的な回答を引き出せる仕様書のように育っていきます。

最後に一言

  • 「プロンプト設計」という言葉はバズワード化しているが、要するに人へ仕事を依頼するのと同じで、目的や背景を明確に伝え、曖昧さをなくして指示・依頼を出すことにほかならない。

  • 指示が曖昧であれば、曖昧な結果しか返ってこない。

  • これは人に依頼する場合も、生成AIに依頼する場合も同じである。

  • 普段から仕事の指示や依頼をきちんと行えている人は、生成AIも問題なく活用できるだろう。

  • 一方で、そうでない人にとっても、生成AIを通じて依頼の仕方を学び、その経験を人への依頼にも活かせる可能性がある。

Appendix

その１：プロンプトとはなんだろう？？の実際の回答

いいですね！土台からしっかり理解しておくと、生成AIを「ブラックボックス的に使う」ではなく「意図的に使いこなす」ことができます。
バックエンドエンジニアとしての経験があるなら、プロンプトを 「AIに渡す仕様書／クエリ」 と考えると理解しやすいと思います。

1. プロンプトとは何か

  • 定義

    • プロンプトとは、生成AI（LLMなど）に与える「入力文」です。AIはこの文を解釈して、最適だと考える出力を返します。
      人間にとっては「指示文」ですが、AIにとっては「処理対象データ」でもあります。

  • SQLとの類比

    • SQLで「SELECT name FROM users WHERE age > 30;」と書くと、DBは条件に従って結果を返しますよね。
    • プロンプトも同じで、「30歳以上のユーザーを一覧で出して」と書くと、AIはそれに応じたテキストを返すイメージです。
    • 違いは、SQLは構造化されて厳密なのに対し、プロンプトは自然言語ベースで曖昧でも動くという点です。

2. プロンプトの役割

プロンプトは単なる「質問」以上のものです。
役割は大きく3つに分けられます：

1. 指示 (Instruction)

  • 何をして欲しいかを伝える
  • 例：「JavaのLINQを使ったサンプルコードを出して」

2. 文脈 (Context)

  • AIに背景や前提条件を与える
  • 例：「あなたはJavaの講師です。初心者向けに、コメント付きでわかりやすく説明してください」

3. 制約 (Constraint)

  • 出力の形式や条件を指定する
  • 例：「コードのみをMarkdown形式で出力してください」「100文字以内で回答してください」

3. プロンプト設計の重要性

AIは「前提条件が曖昧」だと、こちらの意図と違う答えを出すことがあります。
そのためプロンプトは、アーキテクトの設計図のように工夫する必要があります。

  • 悪い例:

    • 「TypeScript教えて」 → 答えは漠然として、深掘りができない

  • 良い例:

    • 「あなたはJavaに詳しいバックエンドエンジニアです。JavaとTypeScriptのクラス定義の違いを、サンプルコード付きで表にまとめてください」

4. プロンプトを理解するための比喩

  • SQL → 厳密な問い合わせ言語
  • プロンプト → 「曖昧な問い合わせ」だけど、工夫次第でほしい形に整えられる
  • APIリクエストのPayload → パラメータ（context, instruction, constraint）を詰め込むと安定して動く

5. 最初のステップとしておすすめの学び方

  1. 「質問」から始める
    • ChatGPTに「○○について説明して」と気軽に投げてみる
  2. 「ロール（役割）」を指定する
    • 「あなたは経験豊富なエンジニアです」「あなたはFPです」など
  3. 「制約」を加える
    • 「表形式で」「コードだけ」「300文字以内」など
  4. リファクタリングする感覚で改善する
    • 思った通りに動かないときは、プロンプトを修正してチューニングする

👉 まとめると、プロンプトは 「AIへの自然言語ベースの仕様書」 です。
そしてSQLやAPI設計と同じように、文脈・制約・目的をうまく記述することが成功の鍵です。

その２：どんなプロンプトが良いのだろうか？の回答

とても良い問いです！
10年の開発経験があるエンジニアの視点から見ると、生成AIに投げるプロンプトは 「仕様書」や「要件定義」 に近づけるほど、回答の精度と実用性が上がります。

以下に「より良い回答を得るプロンプトのコツ」を整理します。

1. ロールを指定する（誰として答えるか）

AIは万能ですが、立場や専門性を指定すると回答のトーンや深さが変わります。

  • 悪い例：「TypeScript教えて」
  • 良い例：「あなたはJava経験10年のエンジニアで、TypeScriptをJavaエンジニアに教える講師です。違いを具体例で説明してください」

2. 目的を明確にする（何を達成したいか）

「なぜ聞くのか」を書くと、回答が目的に沿ったものになります。

  • 悪い例：「JSON-RPCについて教えて」
  • 良い例：「JSON-RPCをREST APIと比較し、バックエンドエンジニアがシステム設計判断できるように利点・欠点を整理してください」

3. 制約を与える（フォーマットや粒度）

回答の形式を指定すると、すぐ使えるアウトプットが得られます。

  • 「表形式で」
  • 「サンプルコード付きで」
  • 「300文字以内で」
  • 「Markdown形式で」

4. 文脈を与える（背景を知らせる）

あなたがどのレベルで、どんな状況なのかを伝えると無駄が減ります。

  • 「私はバックエンドエンジニアで、Javaは得意だがフロント経験は浅い」
  • 「MVPを作りたい。まずはPoC段階でOK」

5. 反復して改善する（リファクタリング思考）

最初から完璧なプロンプトを書くのは難しいので、

  • 👉 「この回答を要約して」
  • 👉 「コードだけ出力して」
  • 👉 「もっと実務的に改善して」

といった追加指示を繰り返すと精度が上がります。

まとめ

より良い回答を得るためには、プロンプトに以下を盛り込むのが鉄則です：

  • ロール（役割）
  • 目的（ゴール）
  • 制約（フォーマット・条件）
  • 文脈（前提や背景）

その３：プロントの設計方法どうやるんだろう？の回答

はい、プロンプトにも 設計方法（設計指針・フレームワーク） があります。
「勘で書く」のではなく「設計図のように組み立てる」ことで、再現性のある良い回答を得られます。

🔹 プロンプト設計の基本フレームワーク

プロンプトは大きく 4つの要素 に分けて設計できます。

  1. Role（ロール・役割）

    • AIに「誰として答えるか」を指定
    • 例：「あなたは経験10年のC#エンジニアです」「金融コンサルタントです」

  2. Task（タスク・目的）

    • 何をして欲しいのか明確に伝える
    • 例：「TypeScriptとC#のクラス定義の違いを説明してください」

  3. Context（文脈・背景）

    • 前提条件や状況を与える
    • 例：「私はバックエンドエンジニアで、TypeScript初心者です」

  4. Constraint（制約・出力形式）

    • 出力条件を指定する
    • 例：「表形式で」「サンプルコード付き」「300文字以内」

🔹 設計手順（ステップ）

  1. ゴールを明確化
    • どんな回答が欲しいのか（学習用か、コード実装用か、要件整理か）を決める
  2. 4要素を埋める
    • Role / Task / Context / Constraint を順に書き出す
  3. テスト＆改善
    • 実際に投げて、期待とズレがあれば修正する
    • → プロンプトは「一発完成」ではなく「リファクタリングするもの」

🔹 サンプル設計（TypeScript学習用）

Role: あなたはC#に詳しい講師です  
Task: C#とTypeScriptのクラス定義の違いを解説してください  
Context: 私はC#歴10年のエンジニアで、TypeScriptは初学者です  
Constraint: サンプルコード付き、表形式、500文字以内

👉 実際にこれを投げると、「初心者向けで比較表つきの具体的な解説」が返ってきます。

🔹 補足：設計パターン

  • R-T-C-Cフレームワーク（Role, Task, Context, Constraint）
  • CUP法（Clarity, Usefulness, Precision） ← 研究者が提案している設計基準
  • Chain of Thought誘導（「ステップごとに考えて」と指示）

📌 まとめると

プロンプトは Role / Task / Context / Constraint を設計要素として組み立てるのが基本。
SQL設計やAPI設計と同じく、粒度とフォーマットを意識して「要件定義する」感覚が有効です。

その４：プロンプト自体を作り上げていくのはあり？ の回答

もちろんできます！🙆‍♂️
むしろそれが一番自然で、実務的な「プロンプトエンジニアリング」のやり方です。

🔹 プロンプトをやり取りしながら磨く流れ

1.最初にざっくり書く

  • 例：「TypeScriptのクラス定義を教えて」
  • この段階では意図が曖昧でもOK

2. AIからの回答を確認する

  • 期待した答えとズレている部分を見つける

3. 追加指示で改善する

  • 「表形式にして」
  • 「Javaとの比較を追加して」
  • 「初心者向けにわかりやすく」

4. 最終的に「再利用できるプロンプト」に整理する

  • そのやり取りの中で「完成版プロンプト」ができる
  • → テンプレ化して次回から即利用可能

🔹 実務に近い例

あなたが「MVPの要件定義」をしたい場合、

  • 1回目：「◯◯アプリの要件定義をして」
  • 2回目：「機能を必須・オプションに分けて」
  • 3回目：「非機能要件も整理して」
  • 4回目：「Markdown表でまとめて」

…という流れで、対話を通してプロンプトが完成します。

🔹 ポイント

  • 一発で完璧を狙わない → コードと同じでリファクタリング前提
  • AIを相棒にする → 「プロンプトを設計する」こと自体もAIと一緒にできる
  • 履歴が資産化 → うまくいったプロンプトは保存して使い回せる

👉 つまり「プロンプトは作り込み型」であり、AIとの対話の中で要件定義のように進化させるのがベストです。

Discussion