生成AIユースケース選定の進め方｜FDEが使う優先度評価と5つの手順

生成AIのユースケース選定で失敗する原因は？

生成AIのユースケース選定は、技術起点で選ぶこと、評価軸が曖昧なまま始めること、この2つで失敗しやすくなります。

生成AIの導入プロジェクトでは、「とりあえずPoC（概念実証）をやってみたが、本番に進めなかった」という話をよく聞きます。Gartnerは2024年7月の発表で、「生成AIプロジェクトの少なくとも30%は、2025年末までにPoC後に放棄される」と予測しました。主な理由には、データ品質の低さ、リスク管理の不備、コストの増大、ビジネス価値の不明確さが挙げられています（出典：Gartner プレスリリース、2024年7月29日）。この理由のうち「価値の不明確さ」は、多くの場合ユースケース選定の段階で決まってしまいます。

技術起点で選ぶと「使われないAI」になる

「最新のLLMで何かできないか」から始めると、業務課題と結びつかないユースケースが選ばれやすくなります。

よくあるのが、チャットボットや社内文書検索（RAG）を「生成AIらしいから」という理由で最初のテーマにするケースです。デモの評判は良いのに、現場の業務フローに組み込まれていないため、数か月で利用が止まってしまいます。FDE（Forward Deployed Engineer）の現場感覚では、「誰の、どの作業の、何分を減らすのか」を一文で言えないユースケースは、選定の段階で一度保留にしたほうが安全です。

評価軸がないと声の大きい部署の案が通る

評価軸を事前に決めておかないと、優先順位は政治力で決まり、成果の出にくいテーマに予算が集まります。

ユースケースの洗い出しワークショップでは、数十件の候補が出ることも珍しくありません。比べる物差しがないままだと、役員の関心が高いテーマや、要望を強く出した部署の案が優先されがちです。失敗パターンを整理すると次のとおりです。

生成AIユースケースの評価軸と優先順位の付け方は？

まず「事業インパクト」と「実現可能性」の2軸で評価し、リスクで足切りしてから優先順位を決めるのが基本です。

評価軸を増やしすぎると点数付けが形だけになります。そのため、FDEが現場で使う枠組みはシンプルに保たれることが多いです。ここでは、実務でよく使われる評価軸と、優先順位の付け方を整理します。

事業インパクト・実現可能性・リスクの3軸で評価する

候補は「価値・実現性・リスク」の3軸で評価し、リスクは加点ではなく足切りの条件として扱います。

事業インパクトと実現可能性は、5段階などで相対評価します。一方でリスクは「許容できるか／できないか」で判定し、許容できない候補はスコアが高くても後回しにします。実務では、この扱い分けが議論の混乱を防ぎます。

2×2マトリクスで「最初の1件」を決める

インパクトと実現可能性の両方が高い「クイックウィン」から始め、社内に成功事例を作るのが定石です。

FDEの立場から付け加えると、最初の1件は「インパクト最大」より「確実に本番まで到達できること」を重視したほうが、結果として全体の進みが速くなる傾向があります。最初の成功事例が社内の信頼を生み、その信頼がデータ提供や部門間調整を進めやすくするからです。

FDEはユースケース選定をどの手順で進めるのか？

FDEは「業務観察→候補の洗い出し→評価→検証設計→合意」の5つの手順で、現場に入り込んで選定します。

Palantirが広めたFDEという職種の特徴は、顧客の現場に常駐に近い形で入り込み、課題の発見から実装までを一貫して担う点です。ユースケース選定でも、会議室で要望を聞くだけでなく、実際の業務を観察して、構造的なボトルネックを見つけることを重視します。

5つの手順と各手順の成果物

各手順で成果物を明確にしておくと、選定プロセスが属人化せず、意思決定者への説明もしやすくなります。

1. 業務観察とヒアリング：現場担当者の作業に同席し、時間がかかっている作業、判断が属人化している作業、繰り返し発生する作業を特定する。成果物は業務フロー図と課題リスト。
2. ユースケース候補の洗い出し：課題リストを「生成AIで解ける形」に翻訳する。要約、分類、抽出、下書き生成、検索、対話など、生成AIが得意な処理の型に当てはめる。成果物は候補一覧。
3. 評価と優先順位付け：前章の3軸で採点し、2×2マトリクスに配置する。成果物は優先順位付きのユースケース一覧。
4. 検証設計：上位の候補について、使うデータ、評価用のテストケース、成功基準、検証期間を定義する。成果物はPoC計画書。
5. 関係者合意：業務オーナー、情報システム部門、法務・セキュリティ担当と、判定基準とリスク対応方針を合意する。成果物は合意済みの実行計画。

手順1と手順4に時間をかける理由

FDEが最も時間をかけるのは業務観察と検証設計です。ここを省くと、PoCの成否が判断できなくなります。

ヒアリングだけでは、担当者自身が「当たり前」と思っている非効率は表に出てきません。たとえば、複数のシステムから情報を転記する作業や、過去の対応履歴を探す作業は、実際に隣で見て初めて規模が分かることが多いです。

検証設計で特に重要なのは、評価用データセット（想定入力と期待される出力の組）を、業務担当者と一緒に作ることです。生成AIの出力品質は「なんとなく良い」で判断されがちです。業務担当者が合格と判断する具体例を先に揃えておくと、PoC後の判定が客観的になります。ここは一次体験としても、選定の成否を分けるポイントだと感じる場面が多い工程です。

選定した生成AIユースケースをPoCから本番化するには？

本番化するには、PoCの開始前に「移行の判定基準」「運用体制」「コストの見通し」の3点を決めておくことが前提です。

PoCが「検証のための検証」で終わる原因の多くは、PoCの設計段階で本番の姿を描いていないことです。FDEは、PoCを本番化への最初の段階として設計します。

PoCの段階から本番の判定基準を決めておく

判定基準は「精度」だけでなく「業務時間の削減」「利用率」「運用コスト」を組み合わせて設定します。

数値目標の水準は、業務の性質や現在の作業時間によって大きく変わります。そのため、一律の目安を当てはめるより、導入前の実測値を基準に業務オーナーと合意するのが現実的です。

本番化で求められる運用設計

本番化した後は、プロンプトやモデルの更新、出力の監視、利用者からのフィードバック対応を誰が担うかを決める必要があります。

生成AIのアプリケーションは、一度作れば終わりではありません。基盤モデルのバージョンアップで出力の傾向が変わることもあり、業務ルールの変更に合わせてプロンプトや参照データを更新する必要もあります。FDEは本番化の時点で、次の体制を整えてから手を離すことを目指します。

• 業務オーナー：出力品質の最終判断と、改善要望の優先順位付けを担う
• 運用担当：ログ監視、評価用データセットでの定期的な回帰テスト、障害対応を担う
• ガバナンス担当：利用規程、データの取り扱い、監査対応を担う

FDEが常駐し続けなくても回る状態を作れるかどうかが、本番化の成否を左右します。

生成AIに向かないユースケースの見分け方は？

出力の誤りが許されない、判断根拠の説明が必須、ルールで解ける、のいずれかに当てはまる場合は向かない可能性が高いです。

生成AIのユースケース選定では、「何をやるか」と同じくらい「何をやらないか」の判断が大切です。向かないテーマを早めに外せば、限られたリソースを価値の高い候補に集中できます。

生成AIに向かない業務の4つの特徴

確率的に出力が変わる生成AIの性質と、業務が求める確実性が合わない場合は、別の手段を検討します。

ただし、「全体としては向かない」業務でも、その一部の工程には生成AIを使える場合があります。たとえば与信判断そのものは人が行い、判断材料となる書類の要約や不足情報の指摘に生成AIを使う、といった分け方です。

向き不向きを判断するチェックリスト

業務を工程単位に分解し、各工程に「人が最終確認できるか」を問うと、向き不向きを判断しやすくなります。

選定時にFDEが確認する問いをまとめます。

1. 出力に誤りがあったとき、業務の流れの中で人が気づいて修正できるか
2. 「8割の品質の下書き」でも業務時間の短縮につながるか
3. 入力となるデータは、権限上・技術上アクセスできる状態にあるか
4. 同じ処理を従来型のプログラムで実装した場合と比べて、生成AIを使う理由を説明できるか
5. 誤出力が顧客や取引先に直接届く構造になっていないか

1・2・3に「はい」、5に「いいえ」と答えられ、4の理由を説明できる業務は、生成AIのユースケースとして有力な候補です。反対に、5が「はい」になる業務は、人によるレビュー工程を挟む設計にできるかどうかを先に検討するのが無難です。

ユースケース選定は、FDEの仕事のなかでも「技術」と「業務理解」の両方が問われる工程です。FDEを目指すエンジニアにとっては、モデルやツールの知識に加えて、現場の業務を観察し、評価軸を使って関係者の合意を作る経験が、そのままキャリアの強みになります。

姉妹メディアの関連記事