AIプロンプトを改善する方法:シンプルなテストの仕組み

なぜプロンプトがうまくいかないのか、当てずっぽうはもう終わり。実際に成果が上がる、テストと改善の4ステップ・サイクル。

2026年1月31日

プロンプトを書いた。出力はずれていた。だから書き直した。やっぱりずれているけれど、ずれ方が違う。少し言葉を変えて、もう一度生成して、ちょっとマシになった気がする——そうしているうちに、自分が何を変えたのか分からなくなる。30分後、振り出しに戻り、どのバージョンが一番良かったのかも思い出せない。

この「再生成して祈る」やり方が、ほとんどの人のAIの使い方だ。そしてこれが、多くの人がいつまでもイライラし続ける理由でもある。Workdayの調査によれば、AIで節約できた時間のうち約37%は、誤りの修正、出力の検証、的外れな文章の書き直しといった「やり直し」に消えていく。

場当たり的な手直しと、体系的な反復改善との違いは、努力の量ではなく方法にある。変更点をテストし、評価し、記録していけば、同じ間違いを繰り返さなくなる。自分のユースケースで本当に効くものが分かってくる。そして、たまたま良い結果が出るプロンプトではなく、安定して良い結果を出せるプロンプトが手元に残るようになる。

なぜ場当たり的な手直しではうまくいかないのか

プロンプトの改善がギャンブルのように感じられるのには理由がある。一度に3つのことを変えて出力が良くなっても、どの変更が効いたのかは分からない。前のバージョンと比べずに記憶頼みで書き直していたら、パターンには気づけない。古い試行を消してしまえば、何が効くかを教えてくれるはずのデータも一緒に失う。

MITスローンの研究では、最先端のAIモデルによるパフォーマンス向上のうち、モデル自体に由来するものは半分にすぎないことが示されている。残り半分は、ユーザーがプロンプトをどう工夫するかから生まれている。つまり、あなたのプロンプト力は、AIの性能と同じくらい結果を左右する。

とはいえ、プロンプト力は魔法ではない。構造化された練習を通じて身につけるパターン認識だ。どの変更がどんな結果につながるかを「見える」ようにする必要がある——だからこそ、仕組みが要る。

改善のための4ステップ・サイクル

効果的なプロンプト改善は、シンプルなループに沿って進む:

テスト — プロンプトを実行し、出力を丸ごと記録する
評価 — 結果を自分の具体的なゴールと照らし合わせる
修正 — 問題に応じて、ピンポイントで一つだけ変更を加える
記録 — 何を変えて、何が起きたかを書き残す

難しいことは何もない。それでも、4つすべて——とくに最後のひとつ——をやり切れるかどうかが、着実にうまくなる人と、同じ問題に何度もつまずく人との分かれ道になる。

ステップ1:プロンプトを実行し、すべてを記録する

まずは手元にあるプロンプトでいい。最初のバージョンに悩みすぎないこと——どうせこれから直していく。目的は、比較できる「ベースライン」を作ることだ。

プロンプトを実行したら、プロンプトと完全な応答の両方を保存する。良いところだけ、ではない。要約でもない。丸ごと全部だ。問題を診断するには、全体像が必要になる。

ChatGPTやClaudeでテストしているなら、変更を加える前に、やり取り全体をメモやドキュメントにコピーしておこう。再生成や編集をしてしまえば、元のものはもう戻ってこない。

ステップ2:本当のゴールに照らして評価する

ここで多くの人がつまずく。出力を見て「なんかしっくり来ないな」と思った瞬間、すぐに書き直し始めてしまう。そのモヤッとした不満では、何を直せばいいのか分からない。

代わりに、私が「赤ペンチェック」と呼んでいる方法を使ってみよう。出力を読み返しながら、具体的な問題に印を入れていく:

トーンがずれている?どこが?
必要な情報が足りない?具体的に何が?
長すぎる?どの部分が冗長?
タスクを誤解している?どう誤解した?
フォーマットが違う?本来はどういう形であるべき?

評価を文字に起こす。「2段落目がフォーマルすぎる、予算の制約が抜けている、会社沿革の余計な背景が混ざっている」。これで、何を直せばいいかがはっきり分かる。

ステップ3:変更は一度に一つだけ

ここがいちばん守りにくく、そして一番大事なルールだ。一度に複数のことを変えてしまうと、どの変更が効いたのか学べない。A/Bテストの研究でも一貫して、変数を一つだけに絞ることが決定的に重要だと示されている——複数の変更を同時に試すと、結果の原因を切り分けられなくなる。

評価で見つかった問題のうち、もっとも重要なものを一つ選び、それだけに対処する。よくある修正パターンは次のとおり:

コンテキストを足す: 状況を理解するためにAIが必要としている背景情報を渡す
制約を足す: 文字数・フォーマット・トーン・除外したいものを指定する
例を足す: 良い出力の見本を見せる(これはフューショット・プロンプティングと呼ばれる)
タスクを明確にする: あいまいな指示を、具体的な指示に書き直す
役割を与える: AIに「あなたは何者か」を伝える(ロール・プロンプティングを参照)

変更を一つだけ加えて、もう一度プロンプトを実行し、比べる。よくなったか?新しい問題が出てきたか?変えたのは一箇所だけだから、ちゃんと判断できる。

ステップ4:変更内容を記録する

このステップは「やってもやらなくてもいい」もののように見える。違う。記録しないと、同じ失敗を繰り返し、うまくいったテクニックを忘れ、せっかくのベストプロンプトもチャット履歴の中に埋もれて消えていく。

記録は凝ったものでなくていい。シンプルなログで十分だ:

バージョン: v1, v2, v3...
変更内容: 「200語の文字数制約を追加」
結果: 「文量はちょうど良くなったが、会話的なトーンが失われた」
採用するか戻すか: 制約は採用、トーンは次に修正

続けていくうちに、このログは自分専用のプレイブックになっていく。傾向も見えてくる——たとえば、文章タスクでは例を入れるとほぼ確実に効く、フォーマットを早めに指定すると構造が安定する、など。こうした気づきが積み重なっていく。

繰り返し使うプロンプトを改善しているなら、PromptNestのようなツールを使えば、各プロンプトに直接メモを紐づけられる。試したこと、効いたこと、その理由を——別のドキュメントを管理しなくても——一箇所で残しておける。

実例:ミーティング要約プロンプトを改善する

実際に改善サイクルを一巡してみよう。チーム向けに、ミーティングのメモをアクションアイテムにまとめたいとする。

バージョン1:

Summarize these meeting notes.

{{meeting_notes}}

結果: ふんわりとした要約が返ってきて、アクションアイテムが文章のあちこちに埋もれている。長すぎるし、本当に何をすべきかを探さないといけない。

評価: 構造化された出力になっていない。アクションアイテムが明確でない。不要な振り返りが混ざっている。

変更: フォーマットの制約を追加する。

バージョン2:

Extract action items from these meeting notes. Format as a bulleted list with the owner's name in brackets after each item.

{{meeting_notes}}

結果: 担当者付きのきれいな箇条書きでアクションアイテムが並ぶ。ただし、いくつかの項目があいまい(「さっき話したあの件をフォローする」)で、期日も入っていない。

評価: フォーマットは良し。ただし内容の具体性とタイミングが足りない。

変更: 具体性と期日に関する要件を追加する。

あいまいなプロンプトが、具体的で構造化されたプロンプトに生まれ変わるビフォーアフター比較

バージョン3:

Extract action items from these meeting notes.

For each action item, include:
- What specifically needs to be done (not vague references)
- Who owns it [in brackets]
- Deadline if mentioned, or "No deadline specified"

If an action item is unclear in the notes, flag it with "[NEEDS CLARIFICATION]" so I can follow up.

{{meeting_notes}}

結果: 具体的なアクション、明確な担当者、分かっている範囲の期日、そしてあいまいなものにはちゃんとフラグ。これならそのまま使える。

3回の反復。それぞれの回で、評価から見えた具体的な問題に手を入れた。最終的なプロンプトは最初のものとは比べものにならないほど良くなり、しかもその「なぜ」を自分で説明できる。

いつ改善をやめるか

反復改善には逓減効果がある。どこかで、すでに十分なものを磨きすぎる時間に変わってしまう。やめどきのサインはこれだ:

出力が要件を満たしている。 完璧、ではなく、要件。必要なことができているなら、もうリリースしていい。

変更するたびに悪くなっている。 ローカルマキシマムにはまっているときがある。直近3回の変更がすべて品質を下げているなら、いちばん良かったバージョンに戻して、そこで打ち止めだ。

例外ケースばかりを最適化している。 プロンプトが90%のケースでうまく動いていて、残り10%に何時間も費やしているなら、その時間に見合う価値があるかを考え直そう。

問題はプロンプトではなく、タスクそのもの。 今のAIには本質的に難しいタスクもある。考えられる手をひと通り試したのにダメなら、そもそもAIにはまだ安定してできないことを頼んでいる可能性がある。

プロンプトだけでなく、仕組みを育てる

体系的な改善の本当の価値は、改善された個々のプロンプトそのものではない。身についていくスキルと、積み上がっていくライブラリのほうにある。

改善のたびに、AIが指示にどう反応するかが少しずつ分かってくる。やがて、最初のドラフトの時点でも筋の良いものが書けるようになる。「これは効いた」「これは外した」のパターンが体に染み込んでいるからだ。よくある失敗の形がすぐに見える。新しいタスクに使い回せる、信頼できるプロンプトのコレクションも手元に残る。

このコレクションが大きい。優れたプロンプト・エンジニアは毎回ゼロから書き始めない——テスト済みのプロンプトのライブラリを持ち、それを修正・流用していく。Rev.comの調査によれば、参考になるプロンプト候補を活用できているユーザーは、そうでないユーザーに比べて、2分以内に満足のいく回答を得られる確率が280%高くなるという。

「これは取っておきたい」と思えるプロンプトが増えてきたなら、PromptNestがちゃんとした置き場所になる。プロジェクトごとに整理でき、検索もでき、どのアプリからでもキーボードショートカットで呼び出せる。改善し終えたプロンプトは、{{meeting_notes}}のような変数を埋め込んだまま保存しておけば、必要なときに空欄を埋めるだけでいい。改善のプロセスを毎回やり直す必要はない——もう一度やったのだから。

次に書くプロンプトから、4ステップのサイクルを始めてみてほしい。テスト、評価、修正、記録。最初は少しだけ手間が増える。それでも、改善に投じた1時間は、プロンプトがちゃんと動くようになったあとで、何倍にもなって返ってくる。