プロンプトエンジニアリングとは
最終更新: 2026年8月12日
1回の指示文をどう書くかを設計することです。答えようとしている問いは 「どう頼めば、思ったとおりの答えが返るか」。 AIエージェントの設計を語る5つの層のうち、いちばん内側にあたります。
コツを紹介する記事は無数にありますが、 全部を覚える必要はありません。 モデルが賢くなったぶん、細かい小手先はほとんど効かなくなりました。 いま実際に効いているものを、効果の大きい順に4つだけ挙げます。
出力の形を指定する
いちばん効きます。形が決まっていないと、毎回違う返り方をします。
「箇条書きで5つ」「表にして」「JSONで、キーは title と body」。曖昧な「わかりやすく」ではなく、形を書きます。
△ わかりやすくまとめて
○ 見出しと3行の説明を1組にして、5組出してください
例を1つ入れる
言葉で説明するより速く、正確に伝わります。10行の指示より1つの例のほうが効くことがよくあります。
望む出力の例を1つ添えます。悪い例も添えると、避けてほしいことが伝わります。
△ 丁寧な口調で書いて
○ 例：「恐れ入りますが、〜をご確認ください」——この温度感で
前提と制約を先に書く
誰に向けた、何のための文章なのか。ここが抜けていると、AIは平均的な答えを返します。
読み手・目的・長さ・使ってはいけない表現。指示の冒頭にまとめます。
△ この機能の説明を書いて
○ 非エンジニアの利用者向け。300字以内。専門用語は使わない
考える手順を指定する
複雑な作業で効きます。ただし単純な作業では、遅くなるだけです。
「まず条件を整理し、次に候補を3つ挙げ、最後に1つ選んで理由を書く」のように順番を渡します。
△ 最適な案を考えて
○ ①条件を箇条書き ②案を3つ ③1つ選んで理由——の順で
1と2で、実務の大半は足ります。 「形を決める」と「例を1つ見せる」—— これだけで返り方のばらつきはかなり減ります。 3と4は、うまくいかないときに足していくものと考えてください。
効かなくなったこと
昔よく紹介されていて、いまはほとんど意味がないものもあります。 やっても害はありませんが、時間をかける価値は薄い部分です。
- 「あなたは一流の◯◯です」と役割を与える — 効果がないわけではありませんが、 読み手と目的を具体的に書くほうがずっと効きます。
- 「ステップバイステップで考えて」と唱える — いまのモデルは指示しなくても必要なときは考えます。 手順を指定したいなら、その手順自体を書くほうが確実です。
- 丁寧にお願いする／チップを約束する — 検証で差が出たという話もありましたが、 実務で気にする価値はありません。
- プロンプトを長く凝ったものにする — 長い指示は後半が効かなくなります。 短く、順序立っているほうが安定します。
指示文で直らない問題
いちばん大事なのがここです。 プロンプトで解けない問題を、プロンプトで解こうとしないこと。 次の症状は、外側の層の話です。
| こういう症状 | 本当の担当 |
|---|---|
| 長い会話の途中で、前の指示が効かなくなる | コンテキストエンジニアリング |
| 同じ失敗を繰り返して、作業が終わらない | ループエンジニアリング |
| 処理が複雑で、どこで失敗したかわからない | グラフエンジニアリング |
| 動くけれど、権限が怖くて任せられない | ハーネスエンジニアリング |
「もっと丁寧に指示すれば直るはず」と考えて、 指示文をどんどん長くしていくのがいちばんよくある回り道です。 指示が1,000字を超えてきたら、たいてい別の層の問題だと思ってください。
短くするほど、実は効く
指示文を短くすると、3つのことが同時に良くなります。
- 後半が埋もれない — 長い指示は、後ろのほうが効きにくくなります
- 費用が下がる — システムプロンプトは毎回送られるので、ここの削減はそのまま効きます
- 直しやすい — どこが効いているのか分かるので、改善が速くなります
いま使っている指示文が何トークンあるかは トークン数の計算で数えられます。 削れる箇所を探すならプロンプト圧縮が使えます。 毎回送られる分がどれくらい費用に効くかは コンテキストエンジニアリングで計算しました。
良くなったかどうかを、どう確かめるか
指示文を直したあと、2〜3回試して良さそうに見えたのは 良くなった証拠になりません。出力は毎回変わるからです。
同じ課題をいくつか用意して、直す前と後で比べる。 これだけで「直したつもりで悪化した」を防げます。 やり方はEvals（評価）にまとめました。 3件でも意味があります。
層のなかでの位置づけ
プロンプトは5つの層のいちばん内側です。 外側にコンテキスト、ループ、グラフ、ハーネスと広がりますが、 上の層は下の層の代わりになりません。 どれだけ立派な処理の図を描いても、 その中の指示文が曖昧なら結果も曖昧になります。
- AIエージェント設計の5階層マップ — 全体像と、症状からの切り分け
- コンテキストエンジニアリング — 1つ外側。何を渡すか
- Evals（評価） — 直した結果を確かめる
- プロンプト圧縮ツール — 指示文から削れる部分を見つける
本記事は2026年8月時点で一般に共有されている考え方を整理したものです。何が効くかはモデルや用途によって変わり、モデルの更新で有効な書き方も変化します。特定のサービスを推奨するものではありません。