現在のプロンプト作成方法―AIに作らせる方法から自動最適化まで

変化したプロンプト作成の考え方

プロンプトエンジニアリングとは、生成AIから目的に合った結果を得るために、指示や情報の与え方を設計・改善することです。

AIの性能が現在ほど高くなかった時期は、専門家としての役割を与える、段階的な思考を指示する、回答例を複数提示する、言葉を少しずつ変えて比較するといったテクニックが重視されていました。

現在もプロンプトエンジニアリングは行われています。OpenAI、Anthropic、Googleも、それぞれ公式資料でプロンプトの設計方法を公開しています。ただし、現在は特別な言い回しを探すことだけを意味するものではありません。

現在は、AIに何をさせるか、必要な情報をどう与えるか、どこまで判断させるか、守る条件をどう設定するか、結果をどう評価するかまで含めて設計します。つまり、言葉選びからAIに仕事を任せるための依頼設計へ変化しています。

現在のAIは、短い依頼からでも目的を推測し、必要な作業をある程度組み立てられます。そのため、あらゆる依頼に専門家の役割を設定する、決まった構文を暗記する、単純な質問にも長い条件を付ける、最初から完成したプロンプトを書くといった作業は、以前ほど重要ではありません。

特に推論モデルは、複雑な問題について必要な検討をモデル側で行えるように設計されています。常に思考手順を細かく指定すると、回答が不必要に長くなったり、モデル本来の問題解決を妨げたりする場合があります。

OpenAIも、通常のGPTモデルと推論モデルでは適切な指示方法が異なると説明しています。

AIがプロンプトを作成できるようになっても、依頼の目的そのものを完全に決めてくれるわけではありません。

例えば「売上データを分析したい」だけでは、分析目的、対象期間、重視する項目、利用者、完了条件などが分かりません。AIは推測できますが、その内容が利用者の目的と一致するとは限りません。

人が決める必要があるのは、最終的に実現したいこと、AIに与える情報、優先条件、任せてよい判断、確認すべき判断、実施してはいけないこと、完成と判断する基準です。

現在は、利用者が目的と条件の概要を伝え、AI自身に実行用プロンプトを作らせる方法が使われています。

フロントエンドのバンドルサイズを改善したい。まず原因を分析し、実際の初回ロード削減につながる変更だけ行わせたい。変更後はビルドとテストを実行し、警告がなくなるか確認したい。この内容をCodex用のプロンプトに整理してください。

AIは、この概要を基に、調査対象、作業範囲、制約、検証方法、完了条件、報告内容などを整理できます。OpenAIも、プロンプトや出力スキーマをAIに生成させる方法を案内しています。

単純な依頼には短いプロンプトを使用し、複雑な依頼にだけ必要な条件を追加します。長いこと自体に価値があるのではなく、目的を達成するために必要な情報が含まれていることが重要です。

文章で説明しにくい場合は、期待する回答例を提示します。Few-shotを利用すると、分類基準、文章の長さ、出力形式などを伝えやすくなります。

長いプロンプトでは、見出しやタグを使って、目的、条件、資料、出力形式を区別します。これは魔法の書式ではなく、AIが内容を区別しやすくなり、人も確認・修正しやすくなることに意味があります。

繰り返す作業は、共通部分をテンプレートとして保存し、その都度変わる対象や条件だけを差し替えます。複数の判断を含む作業は、調査、構成、作成、確認などに分けると、間違いが発生した場所も確認しやすくなります。

APIや業務システムでは、JSON Schemaなどを使って出力構造を定義するStructured Outputsが利用されています。形式は安定しますが、内容の正しさまで保証されるわけではないため、形式と内容は分けて検証します。

現在は、言い回しだけでなく、AIにどの情報を与えるかというコンテキスト設計が重視されています。必要な資料を選び、指示と資料を区別し、どの情報を根拠に回答するかを明確にします。

大量の資料がある場合は、質問に関係する部分を検索してAIへ渡すRAGも使われます。重要なのは大量の情報を与えることではなく、必要な情報を適切に与えることです。

あるモデルで有効だったプロンプトが、別のモデルでは長すぎたり不要な制約になったりすることがあります。同じプロンプトでも、モデルの更新によって出力傾向が変化する場合があります。

最初は簡潔な指示から始め、必要な条件だけを追加し、期待する結果と比較します。有効でなかった指示は削除し、モデルを変更したら再確認します。