はじめに：なぜ「例の選び方」だけでAIの回答が変わるのか？
AIエージェントや業務システム開発の現場でエンジニアの方々と話していると、よくこんな悩みを耳にします。「プロンプトに完璧な回答例を5つも入れたのに、なぜか本番データでは期待通りの精度が出ない」と。
皆さんも、似たような壁に直面したことはありませんか？
プロンプトの中に「例（ショット）」を含めるFew-shotプロンプティングは、AIの挙動を制御するための定石です。2026年現在も、ChatGPTやClaudeの最新モデルにおいて、3〜5個の適切な入出力例を提示することは、出力フォーマットの遵守や回答精度の向上に不可欠な標準手法とされています。特にChain-of-Thought（思考の連鎖）と組み合わせることで、その効果はさらに高まります。
しかし、実はここに大きな落とし穴があります。それは、「どんな入力に対しても、同じ固定された例を見せている」という点です。
人間で考えてみてください。数学のテストを受けている時、微積分の問題を解くのに、足し算の例題を見せられてもあまり参考になりませんよね？ AIも同じです。入力されたタスク（問題）に最も近い「似ている例」を見せないと、高度な推論能力を持つ最新モデルであっても、かえって混乱を招くことがあるのです。
この記事では、AIの精度を劇的に安定させるための鍵となる「類似例の動的な選択」について、その仕組みと原理をQ&A形式で紐解いていきます。まずは動くものを作る前の「頭の整理」として、ぜひ付き合ってください。
Q1-Q3：Few-shotプロンプティングと「類似例」の基礎知識
まずは基本から押さえていきましょう。なぜ固定の例ではダメで、動的に選ぶ必要があるのでしょうか？
Q1: そもそもFew-shotプロンプティングとは何ですか？
Few-shotプロンプティングとは、AIに対して「タスクの説明」だけでなく、「入力と出力のペア（例）」をいくつか提示してから回答させる手法のことです。
例えば、こんな感じです。
入力: 最高でした！
感情: ポジティブ入力: 最悪の気分だ。
感情: ネガティブ入力: まあまあかな。
感情:
このように例を見せることで、AIは「あ、これは感情分析をしてほしいんだな」と文脈から学習します。これを専門用語でIn-context Learning（文脈内学習）と呼びます。モデルの重み（パラメータ）を更新することなく、その場のプロンプトだけでタスクに適応させる、非常に強力なテクニックです。
Q2: なぜ「似ている例」を選ぶ必要があるのですか？
ここが重要なポイントです。AI（大規模言語モデル）は、プロンプトに含まれる情報を非常に敏感に拾い上げます。
もし、あなたが「法律の契約書」を要約させたいのに、プロンプトに入っている例が「料理レシピの要約」だったらどうでしょう？ AIは「レシピ風のカジュアルな文体で要約すればいいのかな？」と誤解してしまうかもしれません。
これを「ネガティブ・トランスファー（負の転移）」と呼ぶこともありますが、要するに、関連性の低い例はノイズになり得るのです。逆に入力内容と構造やトピックが似ている例を提示できれば、AIはそのパターンを模倣しやすくなり、精度の向上と回答スタイルの統一が期待できます。
Q3: ランダムに例を選んではいけないのですか？
ランダム選択は、固定の例よりはマシな場合もありますが、ギャンブル性が高すぎます。
カスタマーサポートの自動化プロジェクトを例に考えてみましょう。膨大な過去ログからランダムに3つの例を選んでプロンプトに入れた場合、偶然「激怒している顧客への対応例」ばかりが選ばれてしまうリスクがあります。その結果、普通の問い合わせに対しても、AIが過剰に謝罪しまくるといった奇妙な挙動を引き起こしかねません。
入力された内容（クエリ）に対して、最も適切なコンテキストを提供するためには、ランダムではなく「意味的な近さ」に基づいて選ぶ必要があるのです。
Q4-Q6：AIを使って「最適な例」を選ぶ仕組みとメリット
では、どうやってその「最適な例」を選び出すのでしょうか？ ここでAI技術そのものが活躍します。
Q4: 「AIを用いて類似例を選ぶ」とは具体的にどういうことですか？
イメージとしては、あなたの手元に何千もの「過去問と模範解答のセット」があるとします。新しい問題が来た瞬間に、その中から「この問題に一番似ている過去問トップ3」を瞬時に抜き出してくる、というプロセスです。
これを実現するために、Embedding（埋め込み表現）という技術を使います。これは、文章の意味を数百〜数千次元の数値の列（ベクトル）に変換する技術です。
簡単に言えば、文章を「地図上の座標」に変換するようなものです。「猫」と「犬」は地図上で近くに配置され、「猫」と「冷蔵庫」は遠くに配置されます。新しい入力が来たら、その座標に近い場所にある「例」を探してくればいいわけです。
Q5: 人間が選ぶのと比べて何が良いのですか？
人間が手動で選ぶ場合、どうしても「汎用的で無難な例」を数個選んで固定しがちです。しかし、実際の入力は千差万別です。
AI（ベクトル検索）を使って動的に選ぶメリットは、スケーラビリティと特異点への対応です。
例えば、普段はあまり来ない「システムエラー時の特殊な返金処理」についての質問が来たとします。固定の例にはそんなマニアックなものは入れていないでしょう。しかし、データベースの中に過去に一度でも似た事例があれば、AIはそれを探し出し、「ほら、この時の対応を参考にして！」とプロンプトに差し込んでくれます。
人間が予期しきれないロングテールなケースにも対応できるのが最大の強みです。
Q6: どのような技術が裏側で使われていますか？
裏側の仕組みは、主に以下の3つのステップで構成されています。
- Vector Store（ベクトルデータベース）: 全ての「例（過去の良質な入出力ペア）」をEmbeddingして保存しておく場所。
- Retriever（検索機）: 新しい入力文をEmbeddingし、Vector Store内で距離が近い（類似度が高い）データを検索する機能。K-NN（k近傍法）などが使われます。
- Selector（選択機）: 検索結果の中から、プロンプトの文字数制限などを考慮して最適な数件をピックアップする機能。
実装には、LangChainやLlamaIndexといったフレームワークを活用するのが一般的です。
特にLangChainの最新環境では、中核機能（langchain-core）と外部連携機能（langchain-community）がパッケージとして明確に分離され、セキュリティや安定性が大幅に向上しています。シリアライズ処理の脆弱性対策なども強化されており、エンタープライズレベルでの採用が進んでいます。また、LlamaIndexもRAG（検索拡張生成）に特化した高度なデータ構造を提供しており、これらを適切に組み合わせることで、単に動くだけでなく、本番運用に耐えうる堅牢な検索パイプラインを構築できます。
Q7-Q8：導入効果とよくある誤解
夢のような技術に聞こえるかもしれませんが、銀の弾丸ではありません。現場のリアリティをお話しします。
Q7: これを導入すると、具体的にどんな効果が期待できますか？
最も明確な効果は「精度の安定化」です。特に入力のバリエーションが豊かなタスク（多言語対応、多種多様なカテゴリの分類など）では、その都度適切なガイドライン（例）が示されるため、AIの迷いが減ります。
もう一つの隠れたメリットは「トークンコストの削減」です。
あらゆるケースに対応しようとして、プロンプトに20個も30個も例を詰め込む必要はありません。その都度、最適な3〜5個だけを選んで入れれば良いので、プロンプトがスリムになり、API利用料の節約やレスポンス速度の向上につながります。
Q8: どんなタスクでも効果がありますか？
いいえ、必ずしもそうではありません。
例えば、「2つの数字を足す」といった単純でルールが明確なタスクや、AIが既に十分な知識を持っている一般的なタスク（「こんにちは」への挨拶など）では、わざわざ複雑な検索システムを組んでもコストに見合いません。
また、「例の質」が低いと逆効果になります。データベースに入っている過去の例自体が間違っていたり、品質が低かったりすると、AIは嬉々としてその「悪い例」を真似します。これをGarbage In, Garbage Out（ゴミが入ればゴミが出る）と言いますが、動的選択をする場合は、データのクレンジング（掃除）がこれまで以上に重要になります。
Q9-Q10：次のステップと発展的な活用
最後に、似た技術との違いと、明日からできるアクションについて解説します。専門家としてのアドバイスは、まず「小さく始めること」です。
Q9: RAG（検索拡張生成）とはどう違うのですか？
構造は非常によく似ていますが、検索してくるデータの「目的」が異なります。
- RAG (Retrieval-Augmented Generation): AIに「知識 (Knowledge)」を与えるのが目的です。社内規定、製品マニュアル、最新ニュースなどの「事実情報」を検索してプロンプトに含め、回答の根拠とします。
- Dynamic Few-shot: AIに「振る舞い (Behavior)」や「思考パターン」を教えるのが目的です。入力に対する「理想的な回答の仕方」や「思考プロセス」の例（過去の良質な回答など）を検索して含めます。
もちろん、これらは排他的なものではありません。知識をRAGで参照しつつ、その回答のトーンや形式はDynamic Few-shotで制御する、というのが高度なAIアプリケーションの構成です。
Q10: まず手元で試すには何から始めればいいですか？
いきなり本格的なベクトルデータベースを構築する必要はありません。まずはReplitやGitHub Copilotなどのツールを活用し、以下のステップでスピーディーにプロトタイプを作成して検証することをお勧めします。
- データの準備: Excelやスプレッドシートで「入力」と「理想の回答」のペアを50個ほど作成します。
- 類似度の計算: Pythonの簡単なスクリプトで、新しい入力に対してコサイン類似度（文章の似ている度合い）を計算し、トップ数件を取得する仕組みを作ります。
- プロンプトへの埋め込み: 取得した例をプロンプトに動的に挿入し、AIに回答させます。
API利用のヒント:
OpenAIのAPIを利用する場合、Embedding API（テキストのベクトル化）は非常に安価で高速です。
現在、OpenAIのモデルラインナップは刷新されており（旧来のモデルの一部は廃止されています）、利用可能な最新モデルや料金体系については、必ず公式ドキュメントを確認してください。
まずは小さく実験を行い、「例を動的に変えるだけで、これほど回答の精度やニュアンスが変わるのか」という効果を肌で実感するところからスタートしましょう。
まとめ：精度の鍵は「プロンプト調整」から「データ選択」へ
これまでのプロンプトエンジニアリングは、「いかに命令文を工夫するか」に焦点が当たっていました。しかし、システムが高度化するにつれ、「いかにAIに適切なコンテキスト（例）を与えるか」というデータ中心のアプローチ（Data-Centric AI）へとシフトしています。
「AIに何をお願いするか」だけでなく、「AIに何を見せるか」をコントロールする。
これが、あなたのAIアプリケーションを次のレベルに引き上げる鍵となるでしょう。
この分野は日進月歩で、新しい手法が次々と生まれています。常に最先端の技術スタックをアップデートし、理論だけでなく「実際にどう動くか」を検証し続けることが重要です。
「もっと実践的なコードが見たい」「実際の業務ケースだとどうなる？」といった疑問が湧いたなら、まずは手を動かして小さなプロトタイプを作ってみてください。技術の本質を見抜き、ビジネスへの最短距離を描きながら、AIの可能性を探求していきましょう。
コメント