AI導入のユースケース選定は何を基準に決めるか｜5軸評価と実装手順

AI導入のユースケース選定はなぜ最初の関門になるのか？

AI導入のユースケース選定は、投資判断と現場定着の両方を左右する最初の分岐点になるためです。

生成AIの導入プロジェクトが止まる場所は、モデルの精度でもインフラでもなく、その手前の「何に使うか」の決定にあることが少なくありません。AX（AI Transformation）は、単発のツール導入ではなく、人が判断・作文・分類していた工程をどこまで機械に委ねるかを設計し直す取り組みです。この線引きを先に決めないまま契約や環境構築に進むと、後工程のすべてが根拠を失います。

DX（デジタルトランスフォーメーション）が既存プロセスのデジタル化を起点にするのに対し、AXでは要件を固め切る前に小さく試して仕様を詰める進め方が中心になります。だからこそ「試す対象」の選び方が成果を決めてしまう、という構造的な違いがあります。

技術選定より先にユースケースを決めるのはなぜか？

生成AIは汎用的で、用途を先に固定しないと必要な機能も費用対効果も判定できないからです。

OpenAI、Anthropic、Google、Microsoftといった主要ベンダーが提供するLLM（大規模言語モデル）は、いずれも「文章を読んで書く」領域を広くカバーします。汎用的であることは利点ですが、選定の場面では判断を曖昧にする要因になります。「何にでも使えます」という説明は、裏を返せば「どれを選んでも決め手がない」という状態と同じだからです。

対象業務を先に1つ決めれば、技術選択はほぼ機械的に決まります。たとえば「問い合わせの一次回答を作る」と決めた瞬間に、社内文書を根拠として引くRAG（検索拡張生成）が必要か、出典リンクの提示が要件か、複数システムをまたぐならAIエージェントに工程を連結させるべきか、という判断軸が具体化します。逆順では、この判断がいつまでも「好み」の議論から抜け出せません。

現場では「モデル比較の会議を3回開く前に、対象業務を1つ決めたほうが早い」という声を聞くことがあります。比較検討そのものが目的化しやすい領域だ、という実感が背景にあるのだと思われます。

選定を誤ると実装のどこで詰まるのか？

精度不足ではなく、効果の測定不能と現場の運用負荷の増加で止まる例が実務では目立ちます。

ユースケース選定の失敗は、技術的な失敗として現れません。典型的には次の3つの形で表面化します。

1. 効果が証明できない — 着手前の処理時間や件数を記録していないため、改善したかどうかを誰も言えない。
2. 確認コストが元の作業を上回る — 出力の正しさを人が全件検証する必要があり、削減したはずの工数が検証工数に置き換わる。
3. 使う人が限られる — 発生頻度の低い業務を選んだ結果、担当者がツールの使い方を覚える前に次の機会が来ない。

いずれも「導入後」に判明しますが、原因はすべて選定段階にあります。この点は、後述する5軸評価のうち測定可能性とリスク許容度を足切り条件に使うべき理由にも直結します。

ユースケース選定の評価軸は何を使えばよいのか？

価値・頻度・実現性・データ・リスクの5軸で採点し、合計点と足切り条件を併用します。

評価軸を持たない選定は、声の大きい部署の要望か、直近に見たデモに引きずられます。逆に軸が10個以上あると、採点作業そのものが数週間のプロジェクトになり、意思決定が遅れます。実務で回る粒度は5軸前後です。

5軸評価はどの指標で構成するのか？

業務価値、発生頻度、技術実現性、データ可用性、リスク許容度の5つで構成するのが基本です。

各軸を3段階（3点／2点／1点）で採点すれば、候補間の序列は十分つきます。5段階にしても順位はほとんど変わらず、採点の議論時間だけが伸びる傾向があります。

各軸の重みづけと足切りはどう決めるのか？

重みは経営の狙いで変え、データ可用性とリスクは点数ではなく足切り条件に使います。

5軸を単純合計すると、「価値は高いがデータが存在しない」案件が中位に紛れ込みます。合計点で並べる前に、次の2つを通過条件として先に判定してください。

• データ可用性の足切り：入力になる情報が電子テキストとして存在し、利用可能な権限があるか。ここが×なら、その案件はAIのユースケースではなくデータ整備のタスクです。
• リスク許容度の足切り：誤りが起きたときに人が検知・修正できるか。不可逆な領域は、評価手順とガバナンスを整えてから改めて候補に戻します。

残った候補に対して、①業務価値と②発生頻度に重みを置いて合計します。コスト削減が当面の狙いなら発生頻度を、事業インパクトを狙うなら業務価値を厚くする、という配分が一般的です。重みの数字そのものより、「なぜその配分にしたか」を1行で書き残すことのほうが、後の説明責任では効いてきます。

リスク評価の考え方を体系立てて整理したい場合は、NIST（米国立標準技術研究所）のAI Risk Management Frameworkのように、影響度と可逆性を軸にする公開フレームワークが参照先になります。

候補の洗い出しから絞り込みはどう進めるのか？

現場ヒアリングで30〜50件を広く出し、5軸採点で最終的に3件以内へ絞り込みます。

候補が5件しか出ていない状態での選定は、選定ではなく追認です。最初の広げ方が足りないと、評価軸をいくら精緻にしても選べる幅が生まれません。

候補はどこから集めればよいのか？

既存の業務フロー図、問い合わせログ、残業の多い工程の3か所から集めるのが近道です。

加えて、現場ヒアリングでは「面倒な作業は何か」ではなく「先週いちばん時間を取られた作業は何か」と聞くほうが具体例が出やすい、という感触があります。前者は抽象的な不満を、後者は実在する工程を引き出すためです。

絞り込みはどんな手順で進めるのか？

棚卸し、粗選別、5軸採点、経営合意の4段階で、各段階の通過件数を先に決めておきます。

1. 棚卸し（1〜2週間） — 部門横断で候補を30〜50件出す。この段階では実現性を問わない。
2. 粗選別（数日） — データ可用性とリスク許容度の足切りを適用し、10〜15件に落とす。
3. 5軸採点（1週間） — 残った候補を現場担当と推進担当の双方で採点し、上位5件に絞る。
4. 経営合意（1回の会議） — 上位から3件以内を選び、成功指標・ベースライン・撤退基準を同時に文書化する。

重要なのは、各段階で「何件まで残すか」を着手前に宣言しておくことです。件数の上限がないと、絞り込み会議が「全部やりましょう」で終わります。

ユースケース選定でつまずく典型パターンをどう避けるのか？

多くは全社一斉、経営肝いり案件、ベンダー主導の3類型で、事前の足切りで回避できます。

なぜ「全社一斉導入」は選定の失敗になるのか？

対象業務が特定されないまま契約が先行し、効果検証の単位そのものが消えてしまうためです。

全社向けに生成AIの利用環境を配るところまでは、AXの基盤整備として合理的です。問題は、それを「導入完了」と扱ってしまう場合です。全員が使える状態と、特定業務の成果が変わる状態は別物であり、前者からは投資対効果の数字が出てきません。

環境配布は基盤整備、ユースケース選定は業務改革、と分けて管理するのが実務的です。前者のKPIは利用率、後者のKPIは処理時間や差し戻し率になります。

ベンダー主導とPoC乱立はどう防ぐのか？

評価軸と撤退基準を自社で先に文書化し、PoCの同時並行数を上限3件に制限します。

他社事例は候補の発想を広げる材料としては有用ですが、そのまま採用判断の根拠にはなりません。同じ「議事録要約」でも、会議体の数と議事録の保管形式が違えば、データ可用性の評点は変わります。

選定後の検証と全社展開はどうつなげるのか？

検証は合格ラインと撤退基準で判定し、通過後に類似業務へ型ごと複製する流れにします。

検証フェーズの合格ラインはどう置くのか？

人手のベースラインと比べ、品質・時間・コストの3点で数値の合格ラインを定めます。

検証開始前に記録すべきベースラインは、最低限この3つです。

1. 品質 — 現状の差し戻し率、修正が必要な割合。AI導入後にこれが悪化しないことが最低条件。
2. 時間 — 1件あたりの処理時間、一次回答までのリードタイム。
3. コスト — 月間の人件費相当と、API・ライセンスの想定利用料。

このベースラインを取らずに始めた検証は、結果がどうであれ「体感では速くなった気がする」で終わります。撤退基準も同時に決めてください。「8週間で1件あたり処理時間が改善しなければ中止」といった形で、期限と数値をセットで書いておくのが実務的です。

RAGを使う構成では、回答精度だけでなく「参照した社内文書が正しいか」を分けて評価する必要があります。文章としては自然でも根拠文書が誤っているケースは、品質指標を1本にまとめていると検知できません。

横展開は何を単位に複製するのか？

ツールではなく、業務手順・プロンプト・確認体制をひとまとまりの型として複製します。

検証を通過した案件を他部門に広げるとき、共有されるのがツール名だけだと、受け取った部門は選定からやり直すことになります。複製すべき単位は次の4点セットです。

横展開の判断は、成果の大きさよりも「現場が自走しているか」で見るほうが安全だと考えられます。推進担当が毎日介入しないと回らない状態のまま件数を増やすと、支援工数が先に限界を迎えるためです。1件目が自走し、業務マニュアルに手順が組み込まれた段階を、複製開始のサインとして扱うのが現実的です。

なお、複数の工程をまたいでAIエージェントに連結させる構成は、単一工程の型が安定してから検討する順序をおすすめします。工程が増えるほど、どこで誤ったかの切り分けが難しくなるためです。

姉妹メディアの関連記事