DEVELOPER’s BLOG

技術ブログ

PoCでは動いた生成AIが本番直前で崩れる理由 ― few-shotの限界 ―

2026.03.16 髙橋 由子
コラム 生成AI
PoCでは動いた生成AIが本番直前で崩れる理由 ― few-shotの限界 ―


  1. はじめに
  2. 生成AIプロジェクトで起きがちなこと
  3. リリース前に起きる問題とよくある対応
  4. 本質的に必要なアプローチ
  5. おわりに


1.はじめに

「PoCではうまくいっていたのに、本番が近づくと急に問題が噴出する」

いくつかの生成AI案件を進める中で、この現象には共通する構造があることに気づきました。PoCでは「使えそう」だったものが、本番直前で「このままでは出せない」と判断されるのです。

原因はモデルの性能不足だけではありません。

多くの場合、課題は進め方にあります。生成AIは、曖昧な要件でもそれらしく動いてしまう一方で、評価基準が定まらないまま進めると、後工程で揺らぎが顕在化します。

本記事では、生成AI活用でよくある失敗パターンと、 安定した成果を出すために必要な考え方について整理してみます。


2.生成AIプロジェクトで起きがちなこと

生成AIを使ったプロジェクトの初期段階では、次のような状況がよく見られます。

  • 生成AIの活用範囲を模索する段階で、要求がまだ抽象的な状態にある
  • 具体的な評価基準が定まらないままPoCが進む
  • 「なんとなく良い」という評価で次のフェーズに進む


この段階では、大きな問題は表面化しません。むしろ「思ったよりできる」という印象を持つことも多いでしょう。
なぜこのようなことが起きるのでしょうか。

生成AIは、要件が曖昧な状態でも一定水準の回答を返せるという特性を持っているからです。

たとえば「わかりやすく説明して」という指示に対して、明確な基準がなくても、それらしい文章を出力します。これは生成AIの強みでもあります。 評価基準がまだ固まっていない段階でも一定品質の出力が得られるため、想定以上に「使えそうだ」という感触のPoCが出来上がることがあります。

その結果、「十分に良いのではないか」という評価のもと、仕様や判断基準が明確に整理されないまま、プロジェクトが次のフェーズへ進んでいくケースも見られます。


3.リリース前に起きる問題とよくある対応

しかし、リリースや本格運用が近づくにつれて状況は変わります。

  • 「ここはこうしてほしい」という具体的な要望が出てくる
  • これまで許容されていた回答の揺れが問題視される
  • リリースを目前にして、初めて「こんなのでは困る」という具体的な目標がわかってくる


つまり、ここで初めて評価基準が具体化するのです。PoC段階では曖昧だった「正解」が、急に具体的な形を持ち始めます。
その結果、これまで見えていなかったズレが一気に顕在化します。

◆よくある対応の落とし穴

多くのプロジェクトで見られるのが、指摘されたケースを例示として追加し、few-shotで挙動を矯正する対応です。

特にリリース直前では、急いで修正する必要があり、影響範囲を限定しながら確実に直したいという判断から、このような対応方法が選ばれやすくなります。

一見、直ったように見えます。 しかし、修正を重ねるほど次のような問題が起きやすくなります。

  • 特定のケースに合わせた指示になるため、そのケースではうまく動くが、少し条件が変わると対応できなくなる
  • 新しい入力パターンでは通用しない
  • few-shotによる例示がどんどん増えていき、全体の一貫性が失われる(あらゆる箇所に「最重要」などの強い指示が増えていく)


結果として、安定して使える状態になりにくくなります。


4.本質的に必要なアプローチ

安定した成果を出す為には、指摘を足していくだけではいずれ限界が来ます。 重要なのは、次のようなプロセスです。

  • お客様からもらった指示をそのままプロンプトに落とし込むのではなく、背景や意図を考える
  • その指示が必要な理由を掘り下げる
  • 期待される結果や出力の形を整理する
  • 複数の要望を共通の判断基準にまとめる
  • その判断基準に沿ってプロンプトを組み立てる


この整理を挟むかどうかで、プロジェクトの安定性は大きく変わります。 判断基準が曖昧なまま具体例だけを増やしても、安定した成果にはつながりません。
「やっとわかってきた具体的要求を噛み砕いて、生成AIにプロンプトという形で指示を与える。」 それは、従来の開発における上流工程で実施していた要求分析から設計、実装に落とすフェーズや、PMがメンバーに業務を指示してきたことに近いのです。


5.おわりに

生成AI案件では、目標が曖昧で、正解が一意でなく、評価基準も途中で変わることが少なくありません。だからこそ、修正のたびに要望をそのまま追加していくのではなく、一度立ち止まることが重要になります。お客様の要望をそのままプロンプトに足し続けると、全体の構造が崩れ、プロンプトが複雑化していきます。
その前に、「本当に必要なことは何か」「本当にモデルに指示するべき内容は何か」を整理することが、安定した設計につながります。


求められるのは、曖昧な要求を整理し、背景意図を読み取り、具体的な期待値を噛み砕いてプロンプトに落とす力です。


生成AIや機械学習の知識だけではなく、「要求をどう整理し、どう指示するか」が成功の鍵となります。 そのため、生成AI活用を成功させるには、単に技術に強いだけでなく、要求分析や要件定義を丁寧に行えるパートナーかどうかという視点も重要になります。


アクセルユニバースでは、こうした要求整理のプロセスを重視し、曖昧なアイデアや構想の段階から整理しながら、生成AIを組み込んだシステムをオーダーメイドで開発しています。生成AIの特性を踏まえた設計を行うことで、PoCにとどまらない実運用につながる形での活用を支援しています。


それが、生成AI活用プロジェクトの難しさであり、面白さであるのかもしれません。

AUCへのお問い合わせ 



X(旧Twitter)・Facebookで定期的に情報発信しています!

関連記事

AWS Kiro Spec駆動開発とは - AIとの対話を構造化する新しいアプローチ

目次 はじめに Kiroについて 実際に触ってみた 感想 おまけ 1. はじめに AIを使用してコーディングする場面を思い浮かべてください。 コード生成した結果、周辺とは違った書き方をされたり、余計な箇所を直されたり、意図しない修正をされて困った経験はありませんか? 他機能への影響が限定的な箇所や、とても簡単な機能の修正は、思い通りにいくことが多いですが、 他機能への影響が大きい改修など、機能の複雑度が高くなればなるほど

記事詳細
AWS Kiro Spec駆動開発とは - AIとの対話を構造化する新しいアプローチ
体験記 生成AI
コード生成を安定させる3つのポイント:設計書・指示の出し方・セッション管理

はじめに ポイント1:設計書を書いてもらいましょう ポイント2:Geminiを使うときの指示の出し方 ポイント3:自分で修正したら「読み直して」と必ず伝える まとめ はじめに 生成AIを使ってコード生成や修正を行うことは、もはや特別なことではなくなってきました。 Gemini や CodeX、Copilot、Cursor など、選択肢も増え、「うまく使えばかなり楽になる」という実感を持っている方も多いと思います。 一方で、実際に使い込

記事詳細
コード生成を安定させる3つのポイント:設計書・指示の出し方・セッション管理
コラム 生成AI
非エンジニアでもできる!Microsoft Copilotを利用した業務改善入門

目次 はじめに プロジェクトの概要 ― 障害対応を生成AIで効率化する 全体の構想 - PowerAutomate × Copilot Studioによる自動化 実際に構築したフロー - Microsoft 365 Copilotでできること 振り返りと教訓 おわりに 1. はじめに 2026年現在、生成AIサービスは目的や専門性に合わせて非常に多くの選択肢がありますが、その中でも、Microsoft Copilotは

記事詳細
非エンジニアでもできる!Microsoft Copilotを利用した業務改善入門
生成AI
Cursorを使う前に知っておきたかったこと | Rulesやコードレビュー

目次 1. はじめに 2. Cursorの概要 3. 言語モデルの選択 4. 4つのモード  4-1. Agentモード  4-2. Askモード  4-3. Planモード  4-4. Debugモード 5. Rulesの設定  5-1. プロジェクトルール  5-2. ユーザールール 6. コードレビューでの活用  6-1. レビュー用のプロジェクトルールを作成する  6-2. レビュー対象の差分

記事詳細
Cursorを使う前に知っておきたかったこと | Rulesやコードレビュー
生成AI

お問い合わせはこちらから