WEB時代とは180度違う、AI時代のDX戦略

WEB時代のDXとAI時代のDXは、同じ「デジタル化」という言葉で語られます。しかし、経営として見るべきポイントは大きく異なります。むしろ、設計思想は180度違うと言ってよいでしょう。

WEB時代のDXは、業務をシステムに合わせる変革でした。紙、電話、表計算、口頭確認、担当者の経験で動いていた業務を、画面、フォーム、ワークフロー、データベース、APIへと置き換えていく。人間はシステムが求める形式に合わせて入力し、選択し、承認し、検索する。これがWEB時代の基本的な設計思想でした。

このアプローチは、多くの企業にとって大きな前進でした。業務の標準化、情報共有、進捗管理、内部統制、遠隔対応を可能にし、企業活動の土台を大きく変えました。

しかしAI時代には、この前提が反転します。

AIは、自然言語を読み、文脈を推論し、曖昧な指示や例外的な状況を扱うことができます。すると、業務をすべて画面や選択肢に押し込めるのではなく、業務の意味を保ったまま、AIに読ませ、考えさせ、作業を支援させることが可能になります。

AI時代のDXとは、単にAIツールを導入することではありません。業務の言葉、判断基準、知識、責任の流れを、AIと共有できる形に再設計することです。

その鍵は、次の3つです。

1. 業務用語の復権
2. 業務プロセスのAI可読化
3. 人間とAIの役割再設計

1. 業務用語の復権

AI時代のDXにおける第一の鍵は、業務用語の復権です。

これは単に、システム内の項目名やプログラムの変数名を日本語にするという話ではありません。WEB時代のシステム化の過程で削ぎ落とされてきた、業務用語に宿る文脈を、情報設計の中心に置き直すということです。

業務用語には、単語以上のものが含まれています。現場の判断基準、例外処理の記憶、組織内で共有された暗黙の前提、顧客との関係性、業界固有の慣習です。

たとえば「要注意案件」「一次回答期限」「稟議状態」「顧客区分」といった言葉には、その会社がどのようにリスクを見ているか、誰がどこで判断するか、どの程度の緊急度を想定しているかが含まれています。

WEB時代のシステム開発では、こうした言葉はしばしば英語の識別子や汎用的なデータモデルへ翻訳されました。approvalStatus、customerSegment、riskFlag のような名前は、実装上は扱いやすいものです。外部サービス、データベース、開発フレームワークとの相性もよく、開発者にとっても標準的でした。

しかし、その翻訳の過程で、現場の言葉が持っていた意味の厚みは失われがちでした。

WEB時代には、それでも大きな問題になりにくかったのです。システムは言葉の意味を理解していたわけではありません。識別子は、機械が区別でき、開発者が最低限理解できれば十分でした。

AI時代には違います。AIは、項目名、コメント、仕様書、マニュアル、プロンプト、ナレッジベースに残された言葉を手がかりに、業務の意味を推論します。言葉は単なるラベルではなく、AIに業務文脈を渡すインターフェースになります。

だからこそ、業務で実際に使われている言葉を、コード、データ、仕様書、プロンプトの中に残すことが重要になります。日本語識別子は、その具体策の一つです。approvalStatus ではなく 稟議状態、customerSegment ではなく 顧客区分、riskFlag ではなく 要注意案件 と書くことには、実務上の意味があります。

業務用語の復権とは、業務の言葉をシステムから排除するのではなく、システムとAIの中心に置き直すことです。これは、経営にとっても重要な論点です。なぜなら、企業の競争力は、一般的なIT用語ではなく、その会社固有の業務理解に宿るからです。

2. 業務プロセスのAI可読化

第二の鍵は、業務プロセスをAIが読める形にすることです。

WEB時代のDXでは、業務プロセスは主に画面遷移や承認フローとして実装されました。誰が入力し、誰が承認し、どの状態になったら次の画面へ進むのか。業務はワークフローや業務システムの中に組み込まれ、人間はその流れに沿って操作しました。

AI時代には、これだけでは不十分です。AIが業務を支援するためには、画面の流れだけでなく、その背後にある判断基準を読める必要があります。

どの条件なら自動処理してよいのか。どの条件なら人間に確認すべきなのか。判断に迷う場合は何を優先するのか。例外処理はどこまで認めるのか。過去の類似事例では、どのような判断がなされたのか。最終的な出力は、どの形式で残すべきなのか。

こうした情報は、従来のシステムでは外側に置かれがちでした。マニュアル、議事録、担当者の経験、暗黙の了解、チャット履歴、過去のメールなどに散らばっていました。つまり、業務の本当の知識は、システムの外側にありました。

AI時代のDXでは、この散らばった業務知識を、AIが参照できる形に整える必要があります。それは単なるマニュアル整備ではありません。AIが実際に読み、判断し、作業を支援できる粒度で、業務プロセスを記述することです。

たとえば問い合わせ対応であれば、FAQだけでは足りません。回答してよい範囲、法務確認が必要な条件、顧客属性による対応の違い、過去のトラブル事例、謝罪文のトーン、エスカレーション基準まで必要になります。

経費精算であれば、金額上限だけでは足りません。例外的に認められるケース、部門ごとの慣習、証憑不足時の判断、監査上の注意点まで必要になります。

AIに業務を任せるということは、AIに業務の文脈を渡すということです。そのためには、業務プロセスを「人間が読めばなんとなく分かる資料」から、「AIが参照して行動を支援できる知識」へ変換する必要があります。

AI時代には、業務知識そのものが実行環境になります。これは、情報システム部門だけの仕事ではありません。経営、事業部門、管理部門、現場が一緒に取り組むべき経営課題です。

3. 人間とAIの役割再設計

第三の鍵は、人間とAIの役割を再設計することです。

AIを既存業務の一部に差し込むだけでは、AI時代のDXにはなりません。それは、WEB時代の業務プロセスにAIという便利な部品を追加しているだけです。

本当に必要なのは、業務全体を「AIと人間が協働する前提」で組み直すことです。

AIが得意なのは、調査、下書き、分類、要約、照合、候補提示、異常検知、反復作業です。大量の情報を読み、一定の基準に沿って整理し、人間が判断しやすい形に整えることに向いています。複数の文書や履歴を横断して、見落としや矛盾を発見することにも強みがあります。

一方で、人間が担うべき領域は残ります。目的設定、責任ある判断、倫理的判断、利害調整、顧客や従業員への説明、最終承認です。これらは単なる情報処理ではなく、責任と関係性を伴う行為です。

重要なのは、AIに任せる範囲と、人間が責任を持つ範囲を明確にすることです。この線引きが曖昧なままAIを導入すると、現場は混乱します。AIの出力を誰が確認するのか。誤った判断が起きたとき、誰が責任を持つのか。どこまで自動化してよいのか。どのタイミングで人間に戻すのか。

これらが決まっていなければ、AIは便利な道具であると同時に、新しい不安要因にもなります。

逆に、役割分担が明確であれば、AIは業務の外付けツールではなく、業務プロセスの一部になります。AIが事前に調べ、整理し、候補を出す。人間が判断し、修正し、責任を持って決定する。その結果を再びAIが参照可能な知識として整理する。

この循環を設計することが、AI時代のDXです。

結論：DXの中心は、画面から意味へ移ります

WEB時代のDXは、画面を中心に設計されました。どの情報を入力するか。どのボタンを押すか。どの画面で承認するか。どのデータベースに保存するか。

AI時代のDXは、意味を中心に設計されます。どの言葉で業務を表すか。どの文脈をAIに渡すか。どの判断をAIに支援させるか。どの責任を人間が引き受けるか。

この違いは小さくありません。

WEB時代のDXが、業務をシステムに合わせる変革だったとすれば、AI時代のDXは、システムを業務の意味に近づける変革です。

そのための鍵は、業務用語の復権、業務プロセスのAI可読化、人間とAIの役割再設計です。

AI時代に求められるのは、単なるAIツールの導入ではありません。業務の言葉、判断、知識、責任の流れを、AIと共有できる形に再構成することです。

経営にとって重要なのは、「どのAIツールを入れるか」だけではありません。自社の業務知識を、AIが活用できる資産へ変えていくことです。

DXの中心は、画面から言語へ、操作から意味へ、システム導入から業務知能の再設計へ移ります。

本稿は、AI時代のDXに関する設計仮説を、経営層と実務部門が議論するためのエッセイとして整理したものです。特定のAIツール、個別システム、導入効果を保証するものではありません。実際の導入では、情報管理、個人情報、法務、労務、監査、セキュリティの観点を分け、各組織の責任体制に基づいて判断してください。