AXの進め方とは？6ステップ・推進体制・KPI設計と失敗回避を実務解説

AXの進め方は何から始めるべき？

AXの進め方は、ツール選定ではなく対象業務の棚卸しと成功指標の合意から着手するのが原則です。

AX（AI Transformation）は生成AIを導入する作業ではなく、AIが判断や生成の一部を担う前提で業務・組織・事業を組み替える取り組みです。既存業務のデジタル化を主眼に置くDX（デジタルトランスフォーメーション）と比べると、AXでは「人が判断していた工程をどこまで機械に委ねるか」という線引きそのものが設計対象になります。

したがって最初の一手は「どのAIを使うか」ではなく「どの業務のどの工程を、どこまでAIに任せるか」を決めることです。ここを飛ばすと、契約したライセンスが使われないまま更新時期を迎える、という典型的な行き止まりに入ります。

なぜツール導入から始めると失敗するのか？

先に契約すると用途を後付けで探すことになり、使われないライセンスだけが残りやすいためです。

生成AIは汎用的であるため、「何にでも使える」という説明が成立してしまいます。その汎用性が、導入判断を曖昧にします。実務では、対象業務を1つに決めてから必要な機能を逆算する順序のほうが、社内の説明も評価もしやすくなります。

たとえば「問い合わせの一次回答を作る」と決めれば、社内文書を根拠として引くRAG（検索拡張生成）が必要か、出典リンクの提示が必要か、ログ保存の要件は何か、という判断が具体化します。

現場では「ツール比較の会議を3回やる前に、対象業務を1つ決めたほうが早い」という声が少なくありません。比較検討そのものが目的化しやすい領域だという実感が背景にあるようです。逆に言えば、対象業務が決まっていれば、技術選択は次のように後から機械的に決まります。

最初に選ぶべき業務の条件は？

頻度が高くテキスト中心で、誤りの代償が小さく測定できる業務を最初の対象に選ぶのが定石です。

判断の材料になる軸は、おおむね次の4つに整理できます。

この条件を満たす業務は、議事録の要約、社内ナレッジ検索、問い合わせの一次回答、営業提案書のドラフト作成、契約書の観点チェックなどに集まります。逆に、最初から事業モデルの変革を狙うと、データ整備と組織再設計が同時に必要になり、投資判断のサイクルが年単位に伸びます。

着手前に合意しておくことは何か？

対象業務・成功指標・ベースライン・撤退基準の4点を、経営と現場の双方で先に文書化しておきます。

とくに撤退基準は後回しにされやすい項目です。「効果が出なければやめる」という曖昧な合意では、判断のタイミングで必ず揉めます。上の表の水準まで具体化しておくと、失敗が組織の学習として扱えるようになります。この4点が揃って初めて、AXの進め方は個人の思いつきではなく、組織の意思決定として回り始めます。

AX推進の6ステップはどう進める？

現状把握・優先順位づけ・小規模検証・ガバナンス整備・標準化・横展開の6段階で順に進めます。

各ステップの終わりに、続けるか対象を変えるかの判断を必ず挟むのが要点です。工程を直線的に走り切る前提で計画すると、途中で無理が見えても止められません。

ステップ1〜2で最も時間を使うべきところはどこか？

処理時間や差し戻し率といった現状の数値を記録する作業に、最も時間を割く価値があります。

ベースラインのない改善は証明できません。1件あたりの処理時間、月間件数、差し戻しの回数、標準からの逸脱件数といった項目を、2〜4週間分だけでも記録しておきます。計測方法を統一しないと後で比較できないため、記録の様式を先に固める必要があります。

同種の業務を扱うチームが2つ以上ある場合は、一方だけ先行導入する形にすると、季節要因や体制変更の影響を切り分けやすくなります。厳密な実験は難しくても、比較対象があるだけで社内の議論は格段に進みます。ここで手を抜くと、後段の効果測定で「効果はあった気がするが証明できない」という状態に陥り、次の予算がつかなくなります。

ステップ3〜4の小規模検証とガバナンス整備はどこまでやるか？

検証は精度と失敗パターンの把握までに絞り、規程は入力してよい情報の範囲から着手します。

小規模検証で追うべきは平均精度よりも失敗の型です。確認すべき問いは次の3点に集約できます。

• どういう入力で誤るのか
• 誤ったときに人が気づけるのか
• 気づけない誤りはどの程度あるのか

この3点が分かれば、人の確認をどこに置くかが決まります。生成AIは誤った内容を自然な文章で返すため、確認工程を外した設計は成立しにくいのが実情です。

規程づくりの参照先は、次の表のとおりです。

契約面では、Microsoft の Azure OpenAI Service、OpenAI や Anthropic、Google の法人向け提供などについて、入力が学習に使われない条件とログの保存期間を確認するところが出発点になります。

ステップ5〜6で現場に定着させるには何が必要か？

プロンプトと参照文書を業務マニュアル側に置き、更新の担当者を社内に明示することが条件です。

検証は成功したのに定着しない、という現象はプロンプトが個人のメモに留まっているときに起きます。標準化とは、うまくいった問い方と参照すべき社内文書のセットを、業務手順の一部として書き残す作業です。加えて、参照文書が古くなれば出力品質は静かに劣化するため、更新責任者を置かない標準化は半年で形骸化します。

横展開の段階では、複数工程をつなぐAIエージェントの活用が視野に入ります。ただし操作権限を与える範囲の設計が甘いと、誤操作の影響が一気に広がります。単一工程の支援で運用が安定してから進めるのが順序として無理がありません。

AXの推進体制と人材はどう整える？

小規模な推進チームが基盤と規程を担い、業務改善の主体は現場部門に残す分担が機能します。

推進チームが業務改善そのものを引き受けると案件が滞留し、逆に現場任せにすると規程とセキュリティ設計が抜け落ちます。この綱引きをどう設計するかが、AXの進め方における体制面の中心論点です。

推進チームの役割はどこまでにすべきか？

環境整備・規程・教育・評価の型づくりまでを担い、個々の業務改善は現場に委ねる形が現実的です。

推進チームの成果指標を「導入件数」ではなく「現場が自走できるようになった業務数」に置くと、この分担が崩れにくくなります。件数を追うと使われない導入が積み上がりやすい、という指摘は実務者から繰り返し聞かれます。

必要な人材要件はどう定義するか？

AIの出力を評価し、任せる範囲を切り分けられる人材を、職種を問わず要件として明文化します。

AXで価値が上がるのは、モデルを作る技術者だけではありません。むしろ現場側で「この出力は業務要件を満たしているか」を判断できる人が不足します。従来、若手が定型作業を通じて判断基準を身につけていた育成ルートは細るため、評価の観点を言語化して教える設計に切り替える必要があります。

外部人材はどこまで使うべきか？

設計と初期立ち上げは外部に任せ、プロンプトと参照文書の更新は社内に残す切り分けが扱いやすいです。

外部人材の活用は初期の立ち上げに有効です。規程の雛形づくり、評価手法の設計、RAGの初期構築などは、経験のある担当者が入ることで数か月分の試行錯誤を圧縮できます。

一方で、プロンプトと参照文書の更新まで外に置くと、契約が切れた時点で運用が止まります。日々の更新を社内の誰が担うのかを、体制図の中に名前つきで書いておくのが安全です。

AXの効果測定とKPIはどう設計する？

活用・業務・事業の3層にKPIを分け、着手前のベースラインを記録して比較するのが基本です。

導入初期に事業KPIだけを見ると、ほぼ確実に「効果なし」と判定されます。層ごとに効果が現れる時期が違うためです。6ステップのSTEP1で記録したベースラインは、この3層のうち業務KPIの比較に直結します。

3層のKPIはどう使い分けるか？

最初の90日は活用KPI、3〜6か月は業務KPI、それ以降に事業KPIを主指標として扱います。

活用KPIは「使われているか」しか示しませんが、初期の異常検知には有効です。利用率が2週で落ちる業務は、精度以前に手順が現場の動線に合っていない可能性が高いためです。

測定でつまずきやすい点はどこか？

ベースラインの取り忘れと、AI以外の要因を切り分けられないことが、測定でつまずく二大要因です。

利用率を発行ID数で見ると、全社契約した直後に高い数値が出て、実態と乖離します。実際に週1回以上使っている人数を分子に置くだけで、どの部門で支援が足りていないかが見えるようになります。

削減した時間はどう報告すべきか？

工数削減額だけでなく、空いた時間を何に振り向けたかを併記すると投資継続の説明がしやすくなります。

工数削減額だけを成果として報告する方法には副作用があります。削減幅が頭打ちになった時点で投資が止まりやすいためです。削減した時間を何に振り向けたか（これまで手が回らなかった分析、提案、点検）まで併記するほうが、継続の説明はしやすくなります。

四半期ごとの報告で「削減時間」と「その時間で新しく実施した業務」を並べて書く様式にしておくと、経営層の関心を効率化から事業成果へ移しやすくなります。

AX推進でよくある失敗と回避策は？

全社一斉導入、目的なきツール契約、効果測定の後回しという3点が、失敗の大半を占めます。

いずれも技術的な難しさではなく、進め方の設計で回避できる範囲の問題です。

PoCが本番運用に進まないのはなぜか？

検証の完了条件と本番移行の条件が定義されず、報告書の提出そのものが目的化してしまうためです。

PoC（概念実証）の企画段階で「どの数値がどの水準に達したら本番に移すか」を書いておくと、この停滞はかなり減ります。同時に、本番運用に必要な次の作業を最初から工程表に入れておくことも要点です。

• 規程整備
• 権限設計
• マニュアル改訂
• 問い合わせ窓口の設置

検証だけを切り出して計画すると、成功しても次の予算がつかないという事態になりがちです。

現場の抵抗はどう扱うべきか？

感情の問題として扱わず、確認負荷と評価制度という具体的な設計課題に分解して対処します。

導入初期に起きやすいのは、レビューを担うベテランへの負荷集中です。生成AIが下書きを大量に作るほど、確認の仕事が増えます。確認手順の簡素化（出典リンクの提示、変更箇所のハイライト、チェック項目の絞り込み）まで含めて設計しないと、最も詳しい人が最初に離脱します。

もう一つは評価制度との不整合です。処理件数で評価される仕組みのままAIを入れると、現場には協力する動機がありません。評価の対象を「AIを使って何を新しくやれたか」に寄せる調整は、経営層でなければ動かせない領域です。技術ではなく制度側の論点であるにもかかわらず、推進チームに丸投げされやすい部分だと感じます。

定着したかどうかは何で判断するか？

推進チームの支援がない状態で3か月運用が続いているかどうかが、実務的な判断線になります。

利用率が高くても、推進チームが毎週フォローしている状態は定着ではありません。次の2条件が満たされた時点で、次の業務へ横展開する余力が生まれます。

• プロンプトと参照文書が現場の手で更新されている
• 新任者が既存のマニュアルだけで業務に入れる

AXの進め方において最後の関門は技術選定ではなく、この自走の確認にあります。

姉妹メディアの関連記事

現場の実装をプロジェクトとして回す型は、姉妹メディアFDE総研の実践記事が参考になります。