AXとは？DXとの違い・5層の構成要素と進め方を実務目線で解説

AXとは何か？DXとの違いは？

AXは、AIが判断と生成を担う前提で業務と組織を作り直す変革です。デジタル化を目的に置くDXとは出発点が違います。

「AX」は、2022年から2023年にかけて生成AIが一気に広まったことを受けて使われ始めた、比較的新しい言葉です。定義はまだ定まっていません。だからこそ、社内で議論を始める前に「自社にとってのAX」を言葉にしておく価値があります。

AX（AI Transformation）の定義は？

AXとは、AIが判断と生成を担う前提で、業務プロセス・組織・事業モデルを組み替え続ける変革活動です。

ポイントは、「AIを導入すること」自体はAXではない点です。生成AIのチャットツールを全社に配っても、それだけではAXになりません。AXと呼べるのは、AIが処理する前提で業務の手順そのものが書き換わり、人の役割が「作業する人」から「AIの出力を判断し、責任を持つ人」へ移ったときです。

問い合わせ対応を例にとります。オペレーターが回答を一から書く前提を捨て、LLM（大規模言語モデル）が一次回答を作り、人は例外処理と最終承認に集中する。ここまで来て初めて、業務が変わったと言えます。ツールの導入と業務の再設計のあいだには「前提の書き換え」という大きな壁があります。AX推進が停滞する企業の多くは、この壁の手前で足踏みしています。

もう一つ強調したいのは、AXが「継続的」な活動だという点です。LLMは数か月単位で性能が変わり、AIにできることの境界も動きます。一度作った業務フローが半年後には最適でなくなる前提で、見直しの仕組みを運用体制に組み込む必要があります。

DXとの違いはどこにあるのか？

DXの主語はデジタル技術、AXの主語はAIの判断能力です。DXは効率化を、AXは業務そのものの再定義を目指します。

DX（デジタルトランスフォーメーション）は、紙や電話、特定の人に頼った手作業をデジタルデータに置き換え、業務プロセスを標準化・自動化する取り組みでした。ただし、DXで自動化できたのは「ルールを明確に書ける業務」に限られます。AXが扱うのは、これまで自動化を諦めてきた「ルールに書き下せない業務」です。文章を読んで要約する、意図を汲んで返信する、複数の資料を横断して比較する、といった領域がこれにあたります。

実務の現場を見ていると、差が出るのはこの表の最終行です。DXの失敗は「使われないシステム」として目に見えます。一方、AXの失敗は「うまくいった実証実験」という、一見成功した姿のまま止まります。成功報告は上がっているのに、本番の業務は何も変わっていない。報告書だけを見ている経営層は、この状態に気づけません。

IT化・DX・AXの三層で整理すると？

IT化は道具、DXは仕組み、AXは判断を変えるものです。三層は積み上がる関係にあり、下の層が弱いと上の層は機能しません。

三層は順番に卒業していく段階ではありません。積み重なっていくものと捉えるほうが実態に近いと考えています。

AX推進の初期に「まずデータ基盤から」という結論に戻る企業が多いのは、この構造のためです。

とはいえ、「三層すべてを完璧にしてからAXに進む」という順番重視のやり方は、実務ではうまくいきません。全社のデータ基盤が整うのを待っていると、数年が過ぎてしまいます。現実的なのは、対象を1業務・1部門に絞り、その範囲だけでIT化・DX・AXを縦に一気通貫で通す進め方です。一度縦に通した経験が、二件目以降でどの層に投資すべきかを判断する基準になります。

自社のAXはどう定義すればよいか？

自社のAXは、AIに任せる判断、人の役割の変化、成功を測る経営指標の3点を言葉にすれば定義できます。

定義を曖昧にしたまま予算だけを確保すると、効果検証の段階で「何をもって成功とするのか」が決まらず、取り組み全体が宙に浮いてしまいます。社内で議論を始める前に、少なくとも次の3つの問いに答えておくことをおすすめします。

なぜ今AX（AI Transformation）が求められるのか？

生成AIが実務で使える水準に達し、人手不足と競争環境の変化も重なって、AXは選択肢から前提に変わりつつあります。

生成AIとLLMは実務で使える水準に達したのか？

2022年以降のLLMの進化で、文章の生成・要約・分類は実務水準に達し、AIは検証段階から運用段階へ移りました。

転換点ははっきりしています。主な出来事を時系列で整理します。

つまり、「AIは賢いか」を確かめるフェーズはおおむね終わりました。今は「自社の業務にどうつなぎ、誰が責任を持って運用するか」を設計するフェーズです。技術の見極めよりも、業務と責任分担の設計に人を割くべき局面だと言えます。

人手不足という構造要因はAXにどう効くのか？

人手不足は構造的な制約で、配置換えだけでは追いつきません。AXは省人化ではなく能力の拡張として設計します。

日本の生産年齢人口が長期的に減っていくことは、統計上ほぼ確実な前提です。さらに、経済産業省が2018年9月に公表した「DXレポート」が指摘した「2025年の崖」の問題も続いています。古いシステムが複雑化・ブラックボックス化し、それを支えてきた人材が退職していくという問題です。

AXの議論を「AIで人を減らす」話として始めると、社内の抵抗が強まります。一方、「減っていく人員で、同じかそれ以上の量と質を出す」話として始めると合意を取りやすい、というのが現場での実感です。単なる言い換えに見えて、推進体制の作りやすさにはっきり効いてきます。現場が協力しなければ業務フローの再設計は進まず、業務フローが変わらなければAXは成り立たないからです。

競争優位はなぜ「導入」から「運用」に移ったのか？

同じLLMを誰もが使える以上、差がつくのは自社データと業務知見をどう組み込むかという運用設計の巧拙です。

APIを呼び出せば、OpenAIやAnthropicの最先端モデルを誰でも使えます。そうなると、モデルそのものは差別化の要因になりません。差が出るのは次の3点です。

1. 自社データの構造化：自社にしかないデータを、どれだけ整理して参照できる状態にしているか
2. 暗黙知の形式化：ベテランが言葉にせず持っている知見を、どこまでプロンプトや評価基準に落とし込めているか
3. 品質の継続改善：出力の品質をどう測り続け、改善しているか

どれも短期間では真似できない資産で、着手が早いほど蓄積の差が開きます。

なお、総務省「令和6年版 情報通信白書」は、日本で生成AIを使ったことがある個人の割合が、米国・中国・ドイツより低い水準にとどまると報告しています。組織として取り組む余地はまだ大きいと見るべきでしょう。裏を返せば、国内では先に動くだけで相対的に優位に立ちやすい状況が続いています。

AXの構成要素とレイヤー構造は？

AXは戦略・業務・データ・AI基盤・ガバナンスの5層で捉えると、投資判断や責任分担の議論が噛み合いやすくなります。

5つのレイヤーで全体像をつかむには？

上から戦略、業務・ユースケース、データ・ナレッジ、AI基盤、ガバナンス・人材の5層に分け、構成要素を整理します。

この5層を会議の共通言語にすると、議論が噛み合わない理由が見えるようになります。経営が第1層の話をしているのに、情報システム部門が第4層のモデル選定で答えている。こうしたすれ違いは珍しくありません。今どの層の話をしているかを毎回はっきりさせるだけでも、意思決定の速さは変わります。

データ・ナレッジ層がRAGの成否を決めるのはなぜ？

RAG（検索拡張生成）の回答精度は検索対象の文書の整い具合でほぼ決まり、散らばった文書では安定しません。

RAGは、社内文書を検索してLLMに渡す仕組みです。渡す材料に古い規程と新しい規程が混ざっていたり、部署ごとに用語がばらばらだったりすると、そのまま誤った回答が返ってきます。AX推進の相談で「RAGを入れたが精度が出ない」と聞くとき、原因がモデル側にあるケースは、私たちの経験では多くありません。多くは、参照する文書の版管理と、アクセス権限の設計（誰が見てよい情報か）を詰め切れていないことが原因です。

地味ですが、データ・ナレッジ層は最も効果の出る投資先です。モデルを入れ替えるよりも直接、回答品質を上げられる作業は次のとおりです。

AIエージェント時代に必要なアーキテクチャとは？

AIエージェントの要は業務システムへのつなぎ方と権限設計です。実行範囲と監査ログの残し方を先に決めます。

AIエージェントは、文章を生成するだけでなく、検索・計算・システム操作といった行動を自分で組み合わせて実行します。便利な反面、誤った操作を実行してしまうおそれもあります。そのため、設計時には「何ができるか」より先に「何をさせないか」を決めます。

前述のMCP（Model Context Protocol）のような標準的な接続方式が登場し、技術的なハードルは下がりました。しかし、権限設計の難しさは変わっていません。むしろ接続が簡単になった分、「つなげられるからつなぐ」という判断が事故につながりやすくなっています。まず読み取り専用で始め、書き込みを伴う操作には承認フローを挟む。この段階的な設計を、最初のアーキテクチャ議論に入れておくべきです。

ガバナンス層は後付けできるのか？

後付けは割高になります。AI事業者ガイドラインやEU AI Actなどルール整備が進む今は、設計段階から組み込みます。

参照すべき主な枠組みは次のとおりです。

すべてに一度に対応する必要はありません。ただ、利用ルールを作る際にどの枠組みを参照したかを書き残しておくと、のちの監査対応や取引先からの問い合わせで役立ちます。逆に、参照元を書かずに社内ルールを作ると、数年後には「なぜこの基準なのか」を誰も説明できなくなります。規制が改定されたときには、ルールを一から作り直すことになります。

AXの進め方は？何から始めればよい？

現状把握、ユースケース選定、小さな実装、運用定着、横展開の順に進めるのが、遠回りに見えて最短の道です。

ステップ0〜4の全体像は？

準備から横展開までを5段階に分け、段階ごとに「次へ進む条件」を先に決めると、取り組みの停滞を防げます。

この表で最も大事なのは「完了の目安」の列です。期間ではなく条件で区切ることで、「まだ精度が足りないので、もう少し検証を続けます」という終わりのない延長を防げます。

最初のユースケースはどう選ぶべきか？

頻度が高く、失敗しても取り返しがつき、成果を数字で示せる業務を選ぶと、社内の合意を取りやすくなります。

具体的な判断軸は次の4つです。

最初の一件に議事録の要約や社内問い合わせ対応が選ばれやすいのは、この4軸をどれも満たしやすいからです。逆に、いきなり顧客向けの自動回答や、経理・法務の最終判断を伴う業務を選ぶと、失敗が許されにくいことが足かせになります。検証が終わらないまま時間だけが過ぎがちです。

効果測定はどう設計すればよいか？

最も大事なのは導入前にベースラインを測ることです。導入後の「体感で速くなった」は投資判断の材料になりません。

測るべきは次の4点です。

特に実利用率は軽く見られがちです。しかし、精度は十分なのに使われていない状態を早く見つけられる指標になります。

AIの出力品質そのものについては、代表的な入力を30〜50件ほど集めて評価用データセットを作り、変更のたびに同じ基準で採点する運用を用意しておきます。そうすれば、モデルやプロンプトを変えたときの品質低下に気づけます。評価用データセットは一度作れば資産として残り、モデルの世代交代が起きたときの乗り換え判断にもそのまま使えます。

人と組織の設計はいつ手をつけるか？

技術検証と並行して進めるのが原則です。運用オーナーと承認プロセスが未定のまま実装すると、本番移行で止まります。

決めておきたい役割は3つです。

あわせて、AIの出力を最終確認する人の役割（何を確認し、何に責任を持つのか）を文書にしておくと、現場の心理的なハードルが下がります。

「AIの出力をそのまま使って問題が起きたら、誰の責任か」。この問いに答えが用意されていない組織では、現場は安全を優先してAIを使わなくなります。責任範囲をはっきりさせることは、統制のためだけでなく、利用を後押しする施策でもあります。

AX推進でつまずきやすい落とし穴は？

停滞の多くはAI技術ではなく、本番移行条件の未決定、過剰な精度期待、権限設計の後回し、KPI未接続から生じます。

4つの落とし穴と、先回りして決めておくべきことを整理します。

なぜPoC（実証実験）で止まってしまうのか？

検証の成功条件だけを決め、本番移行の条件を決めていないことが原因です。技術ではなく意思決定設計の問題です。

「精度が出たら本番化する」というあいまいな合意のまま検証を始めると、本番化の議論に入った途端に、運用コスト・保守担当・障害時の責任といった未決事項が一斉に出てきます。検証を始める前に、本番移行の判断者、判断基準、移行後の運用予算を決めておく。この一手間の有無で、その後の進み方は大きく変わります。

精度への期待をどう調整するか？

LLMの出力は確率的で、100%の正確性は前提にできません。人が確認する工程を最初から業務設計に組み込みます。

生成AIには、事実と違う内容をもっともらしく出力する「ハルシネーション」という性質があります。RAGで根拠を示したり出典リンクを表示したりすれば減らせますが、ゼロにはなりません。そのため、設計で問うべきは「どうすれば完璧になるか」ではなく、「誤りが混じる前提で、どこに人のチェックを置けば業務が成り立つか」です。この考え方をヒューマン・イン・ザ・ループと呼びます。

言い換えれば、人が誤りに気づけない工程にはAIを置かない、という判断基準にもなります。大量データを一括処理して人が全件を見られない場合のように、チェックが物理的にできない工程もあります。こうした工程は、サンプリング検査の設計まで含めて初めて本番運用に載せられます。

データと権限の整備を後回しにすると何が起きるか？

参照範囲の設計を怠ると、閲覧権限のない情報が回答に混ざる事故が起きます。展開前に必ず権限設計を済ませます。

社内文書をまとめてRAGの検索対象にすると、人事情報や役員会資料が、一般社員の質問への回答に混ざることがあります。技術的には、元の文書管理システムの権限をAI側の検索処理にも引き継ぐ設計（権限を考慮した検索）で対処します。

パイロット段階では対象を1部門の公開文書に絞り、権限設計を確かめてから範囲を広げるのが現実的です。範囲を広げるたびに権限を確認し直す運用ルールを最初に決めておけば、横展開のスピードを落とさずに事故を防げます。

経営指標に接続されていない取り組みはどうなるか？

利用率やツール導入数だけを追うと、予算見直しの際に効果を説明できず縮小されます。業務KPIとの接続を先に決めます。

AX推進の報告が全社の利用回数だけで終わっていると、経営側は次の投資を判断できません。削減できた工数を何に振り向けたのか、リードタイムが何日短くなったのか、対応品質の指標がどう動いたのか。ステップ1の時点で、既存の経営指標のどれと結びつけるかを決めておくことが、取り組みを続けるための最大の防御策になります。

AXは一度導入すれば終わるプロジェクトではありません。モデルの進化に合わせて業務設計を更新し続ける運用です。最初の一件は小さく始め、それでも本番運用まで通し切る。その一周の経験が、二件目以降のスピードを決めます。

AXについて、さらに詳しく知るには何を読めばよい？

AXの全体像をつかんだら、取り組みたい段階に合わせて次の記事へ進めます。

AXの戦略・ガバナンスを具体化するには？

• AI戦略の策定手順とは？経営目標から逆算する5ステップと実行体制
• AI成熟度診断とは？レベル0〜5の定義・6つの評価軸と進め方を実務解説
• AI推進の組織体制とは？3つの型・6つの役割と立ち上げ90日の手順を実務解説
• AIガバナンスとは？企業の体制構築・規程・運用を実務で解説
• ISO 42001とは？要求事項・ISO 27001との違いと認証の流れ
• AI法規制に企業はどう対応する？EU AI法・日本の法律と対応手順を実務解説
• AI導入のコストは何で決まる？内訳・見積もり・削減策・ROIを実務解説
• 生成AI導入の稟議を通すには？稟議書の構成・費用対効果・リスク対策の書き方

AXの実装はどう進めればよい？

• AXの進め方とは？6ステップ・推進体制・KPI設計と失敗回避を実務解説
• AI導入のユースケース選定は何を基準に決めるか｜5軸評価と実装手順
• AI PoCの進め方とは？失敗理由・5ステップ・評価指標と本番化の判断基準
• ヒューマンインザループ（HITL）とは？HOTLとの違いと承認フローの設計
• AIガードレールとは？種類・仕組み・実装手順とツールの選び方を実務解説
• 生成AIの評価方法とは？指標の種類・5段階の手順と運用体制を実務解説
• AI導入の効果測定はどう進める？KPI設計・ROI算出・運用サイクルを実務解説

AXを担う人材はどう育て、どう採るか？

• AX人材とは？DX人材との違い・必要スキル・育成と採用の進め方
• CAIOとは？最高AI責任者の役割・CIOとの違いと設置手順を実務解説
• AI人材の育成はどう進める？役割定義・三層研修・定着と失敗回避を実務解説
• 社員のAIリテラシーとは？研修設計の5ステップと定着度の測り方を実務解説
• AI人材の採用はどう進める？求人要件・選考設計・定着策を実務解説
• 社内AIアンバサダー制度の作り方｜選び方・役割・育成と評価の実務
• AI活用の人事評価とは？導入手順と公平性・リスク対策を実務で解説

他社のAX事例や失敗例を知るには？

• AI導入の失敗事例とは？5つの型と根本原因・立て直し方を実務解説
• AI活用の事例を企業別に解説｜製造・金融・小売の成果とKPI設計
• 生成AIの活用事例を業務別に整理｜営業・人事・開発の実装パターン