プロンプトエンジニアリング実践 - AIから良い回答を引き出す技術

「なんか違う」が返ってくる瞬間

AIチャットに「このコードのバグを直して」と貼り付けたのに、見当違いの修正が返ってきた。もう一度「違う、そこじゃない」と打ち直す。この往復を何度か経験した方は多いはずです。

同じAIモデルでも、投げかける文章しだいで回答の質は大きく変わります。腕のいいAIを引き当てられないのではなく、指示の出し方に改善の余地があるのです。この「指示の出し方」を扱う技術が、プロンプトエンジニアリングです。

プロンプト（prompt） とは、AIに渡す入力文のこと。そして プロンプトエンジニアリング とは、望む回答を引き出すためにその入力文を設計する技術を指します。本記事では、これを特別な才能ではなく、再現できる手順として整理します。

プロンプトは「作業指示書」だと考える

まず頭に置いてほしいモデルがあります。プロンプトは、新しく入ったメンバーに渡す作業指示書だということです。

優秀な同僚でも、「あの件、いい感じにやっておいて」とだけ言われたら困ります。何の件か、誰に向けたものか、どんな形で納品すればよいか。これらが書かれていない指示書は、受け取った側が想像で埋めるしかありません。想像が外れれば、成果物も外れます。

AIもまったく同じです。AIはあなたの画面も、プロジェクトの事情も、あなたの頭の中の前提も見ていません。見えているのは、あなたが打ち込んだ文章だけです。だからこそ、曖昧な指示には曖昧な回答が返ってきます。これは精度の問題ではなく、情報が足りていないことの自然な結果です。

良いプロンプトとは、良い作業指示書です。この一点を押さえると、次に何を書き足せばよいかが見えてきます。

役割・文脈・出力形式 — 明示すべき三点

作業指示書に最低限必要な要素を、プロンプトに落とすと次の三つになります。

• 役割: AIにどんな立場で答えてほしいか
• 文脈: 前提となる状況や制約
• 出力形式: どんな形で返してほしいか

具体例で見てみましょう。まずは、よくある曖昧な指示です。

Review this Python function.

def f(d):
    return [x for x in d if x > 0]

これだと、「読みやすいですね」程度の当たり障りない感想が返ってきがちです。レビューの観点も、返してほしい形も指定していないからです。三点を足すと、こうなります。

# Role
You are a senior Python reviewer.

# Context
This runs in a data pipeline. Input may be very large,
and may contain None values mixed with numbers.

# Task
Review the function below for correctness and readability.

# Output format
List issues as bullet points. For each, show a fixed code snippet.

def f(d):
    return [x for x in d if x > 0]

後者の読み方を説明します。# Role でレビュアーとしての視点を固定し、# Context で「大規模データ」「None が混ざりうる」という、コードだけ見てもわからない前提を渡しています。この前提があると、AIは None > 0 が例外を起こす点に気づけます。# Output format で箇条書きと修正コードを求めているので、読み返しやすい形で返ってきます。見出し（#）で区切っているのは装飾ではなく、指示の境界をAIにはっきり示すためです。

つまずきポイント：出力形式を指定しないと、毎回バラバラの体裁で返ってきて、結局こちらが読み直す手間が増えます。「箇条書きで」「表形式で」「コードだけ、説明は不要」といった一言を添えるだけで、後工程がぐっと楽になります。

つまずき — 一度に全部を詰め込む

三点を意識し始めると、今度は逆の失敗が起きます。あれもこれもと欲張り、一つのプロンプトに五つも六つも要求を詰め込んでしまうのです。

「リファクタして、テストも書いて、ドキュメントも英語と日本語で、ついでに性能も測って」。こう頼むと、どれも中途半端な回答になりがちです。指示書に作業を詰め込みすぎると、受け手が優先順位を見失うのと同じです。

対処はシンプルで、タスクを分割します。まずリファクタだけを頼み、結果を確認してから、次にテストを頼みます。一往復で一つのことをやらせるほうが、結果的に速く、確認もしやすくなります。

例を見せる — Few-shotという考え方

言葉で形式を説明するより、見本を一つ見せたほうが早いことがあります。これを Few-shot（フューショット） と呼びます。few は「少数の」、shot は「例」で、いくつかの例を添えて望む出力を示す方法です。例を一切与えないやり方は ゼロショット（zero-shot） と呼びます。

たとえば、コミットメッセージの体裁をそろえたいとき。

Convert each change description into a Conventional Commit line.

# Examples
Input: fixed a null check in the login form
Output: fix: add null check to login form

Input: added dark mode toggle
Output: feat: add dark mode toggle

# Now convert this
Input: updated the README install steps
Output:

読み方のポイントは # Examples の部分です。入力と出力のペアを二つ見せることで、「fix: や feat: という接頭辞を付ける」「命令形で簡潔に書く」というルールを、言葉で説明せずに伝えています。AIは最後の Output: の続きを、この型にならって埋めます。ルールを文章で列挙するより、例を二、三個見せるほうが正確に伝わる場面は多くあります。

考える手順を指定する

難しい問題では、答えだけを急がせると間違えやすくなります。人間でも、暗算で即答するより、途中式を書いたほうが正確なのと同じです。

そこで「段階的に考えてから答えて」と手順を指定します。英語では “think step by step” という一文がよく使われます。

A function processes 200 records. Each call to the API takes 0.3s,
and we run 4 calls in parallel. Estimate the total time.

Think step by step, then give the final number on the last line.

この指示では、AIはまず「200件 ÷ 並列4 = 50バッチ」「50 × 0.3秒」と途中の計算を書き出し、最後に結論を出します。途中が見えることには、もう一つ利点があります。計算の前提が間違っていたとき、どこで狂ったかをあなたが確認できるのです。

つまずきポイント：AIの回答は、自信ありげでも間違っていることがあります（事実でない内容を生成する現象を ハルシネーション と呼びます）。特にコードや数値は、鵜呑みにせず手元で実行・検算する習慣を持ってください。生成物を本番に適用する前に、小さく試して確かめます。これは熟練エンジニアが必ず踏むステップです。

まとめ

プロンプトエンジニアリングの中心にあるのは、派手なテクニックではなく一つの見方です。

• プロンプトは 作業指示書。AIには、あなたが書いた文章しか見えていない
• 役割・文脈・出力形式 の三点を明示すると、回答が安定する
• 要求は詰め込まず、一往復に一タスク で分割する
• 言葉で説明しにくい形式は、例を見せる（Few-shot）
• 難問は 段階的に考えさせ、途中を確認する
• 出力は必ず 自分で検算・実行 してから使う

次の一歩として、今日あなたが最後にAIへ投げた曖昧な質問を一つ思い出し、役割・文脈・出力形式の三点を足して書き直してみてください。同じモデルから返ってくる回答が、どれだけ変わるかを体感できるはずです。