生成AI・AIエージェント時代のDX

2023年にChatGPTが世界の注目を一挙に集めてから早くも2年以上が経ち、生成AI(Generative AI)という言葉が今や時代を象徴するキーワードの一つとなりました。

目まぐるしいテクノロジーの進化が日々続く中、推論機能を備えた新しいモデルやオープンソースのモデルなど、基盤モデルの更なるアップデートが続いています。多くの専門家は、2025年を「AIエージェント元年」と位置づけ、企業のDX戦略においてAI活用がより一層重要になることを予見しています。

今回は、「生成AI・AIエージェント時代におけるDX推進」と題して、各企業が自社のAI活用を促進していく上で押さえておくべき重要なポイントについて書いていきたいと思います。

## はじめに

生成AIが一気に注目を集めた当初は、主に一般ユーザーが気軽に使えるチャット型のサービスがクローズアップされていました。

しかし、その後わずか数か月間で、企業での利活用を目的としたクラウドサービスやオープンソースモデル、さらにはプラグイン・API、オープンソースのライブラリなども次々と登場しました。

生成AIの利活用は、様々な業種・業態でのPoC(試験実施)の段階を経て、今まさに「どうやって社内に根付かせるか」や「自社独自の強みとどう結びつけるか」というフェーズへと移行しつつあります。

2024年の後半頃から、多くの専門家が「AIエージェント」の重要性について強調しているものの、他方で「ChatGPTを導入・展開したのに社内ではまだあまり使われていないレベル」「AIエージェントと言われても、具体的にどこから手をつければ良いかわからない」というように、生成AIの黎明期である今、まだまだ実際の現場とのギャップは大きくあります。

米政府によるStargate Project、中国企業によるDeepSeekの発表、そしてOpenAIによるGPT-4.5, GPT-5のリリース予定など、生成AI関連のニュースについては、新たな話題に毎日事欠かない状況になっています。

一方で、あまり重要でない情報も含めて広く流布されるようになり、生成AI時代において、本質的に捉えておくべきポイントは何なのか、そして、企業のDX推進で今本当に力を入れておくべきポイントは何なのかという事が非常にわかりにくくなっています。

テクノロジーの進化が早く、新たな情報が矢継ぎ早に発表されている今の状況において、最新の動向をまとめただけの情報にはほとんど価値はありません。生成AIに関する最新情報の賞味期限はあまりにも短く、数週間後には「もうその情報古いよね」となっているためです。

今回は、最新情報によって移り変わる特定のトピック(枝葉)に依拠した内容ではなく、中長期のスパンで考えて、企業のDX推進で本質的に何に取り組む必要があるのかという”幹”の部分について考えていきたいと思います。

## なぜChatGPTを社内に配ってもあまり使われないのか？

こちらは既に「[ChatGPTを社内に配ってもあまり使われない本当の理由](https://qiita.com/jw-automation/items/cf8ffc7a0edab512d917)」で記載しましたが、読んでいない方も多いと思いますのでポイントだけ絞って解説しておきます。

世界の注目を一挙に集めたChatGPTでしたが、実際の所、企業内ではどのくらい使われているのでしょうか？

「自社もこのAIの流れに乗り遅れまい」と大手企業を中心に2023 年から多くの企業が社内の従業員向けにChatGPTの展開を始めました。

ChatGPTの利用教育や実践研修なども積極的に取り入れ、生成AIの導入により従業員の業務効率の大幅な向上を期待していたものの、導入後のアンケートでは導入者達の当初の期待を大きく下回り、利用率は社内の1割程度というデータが相次いで出ています。

では、なぜこれほど世界で注目を集めたChatGPTがそれほど社内で使われていないのでしょうか？

ChatGPTの性能不足や従業員のITリテラシー不足に帰結される事も多いこの現象ですが、根本的な理由はもっとシンプルで、「ChatGPTが社内の事を何も知らない」からです。

そもそもの前提としてChatGPTは過去のオープンデータを元に学習されているため、プログラミングや多言語翻訳、数学・物理等の一般的な問題はそのまま高い精度で解く事ができます。

そして、Web検索機能も搭載されるようになったため、ChatGPTは過去のオープンデータ+Web検索で対応できる問題は基本的に解けるようになりました。

この性質から、実際にどの職種の人がよく利用しているのかというと、ITエンジニア・研究者・Webマーケターという職種の方達が挙げられます。

プログラムは世界共通言語であり、基盤モデルの学習データにも含まれているため、ITエンジニアにとってはプログラミングのコード生成やバグ修正などで大きな味方になり、もはやChatGPTがなければ仕事にならないと言っていい状況になっています。

研究者にとっても、論文のサーベイや翻訳、執筆支援など、業務で活用できる範囲がかなり広く、Webマーケターの場合は、ペルソナ分析や壁打ち、コピーライティングの作成やWeb記事の執筆サポートなど、多くの場面で利用する機会があります。

一方で、大手企業などの場合、社内でこのような職種の人がどの程度いるかというと、あくまで少数派という位置づけになるでしょう。大部分を占める営業系のフロントオフィスの方や、総務・人事・法務・経理などのバックオフィスの方達も含め、ほとんどの職種の方はオープンデータではなく、社内情報を中心に業務を進めています。

営業系の方であれば、業務を進める上でCRM等に登録している顧客情報や取引情報は必須な上に、バックオフィスの方の場合は、社内の業務プロセスや規程群、組織情報等も前提情報として必須になります。

一方で、ChatGPTはこういった社内情報については何も知りません。つまり、社内の多くを占める職種の方達にとっては、社内の事を何も知らないChatGPTにサポートを依頼できる業務はあまりないという事です。

ChatGPTをそのまま社内に導入するという事がどういう状態なのかを擬人化して考えると、とてつもなく優秀な人材を採用したものの、この人材を社内情報と隔絶した環境で仕事をさせているという状態になります。

従業員はチャットでこの人材に何でも質問や依頼ができるものの、この人材は社内の事は何も知りません。つまり、社内情報が必須の業務をしている人達にとっては、どれだけこの人材が賢くても、あまり依頼できる事はないという事です。

では一方で、この人材が社内情報にアクセスできるようになった場合はどうなるでしょうか？

この人材はとてつもなく賢い上に、あらゆる言語を操り、プログラミングすらできます。その上で、社内の事を誰よりも知っていて、24/365で文句を言わずいつでもチャットを返してくれる存在となります。

こうなると、おそらく誰からも頼られるスーパーマンのような存在になるでしょう。つまり、社内利用の観点では、ChatGPTが社内情報をどれだけ知っているかが鍵になるという事です。

これはChatGPTの性能がどれだけ今後上がっても、また従業員のITリテラシーがどれだけ上がっても解決する問題ではないため、社内での個別の対策を進めていく必要があります。

具体的にはRAGやFine-Tuningという手法を使って、ChatGPTが社内情報にアクセスできる状態を作っていくという話になりますが、Fine-Tuningは再学習のコストや評価、情報統制も難しいため、多くのケースではRAGが中心になるでしょう。

先進企業では、2023年後半から2024年にかけて、RAGを活用した社内情報検索等の開発を進めるケースが多くありましたが、社内情報検索はまず一丁目一番地としての取り組みに向いており、この取り組みによって、AI時代における社内情報管理の重要性や生成AIの特性に関する肌感覚が関係者内に醸成されるようになります。

生成AIに関する具体的な取り組みがまだ進められていないという企業は、抽象的な議論に終始する事なく、まずはChatGPTを社内情報に繋ぐ事で、「情報を探す・人に聞く」という、それ自体は付加価値を生まない行為を極力ゼロにしていくという目標を立てる事が一つの指針として良いのではないでしょうか。

人材の流動性が益々高くなり、リモート勤務などのハイブリッドな働き方が更に拡大していく社会の潮流においても、生成AIによる社内情報検索機能がなく、人に聞かないとわからない事が多いという状態は業務効率を大きく下げる上に、企業競争力を低下させる要因となるでしょう。

## 2025年以降のDX推進の主軸となる「特化型AIエージェント」の開発
まずは社内にChatGPTを配って導入を進めたのが2023年、RAG等を活用した社内情報検索等の実装を進めたのが2024年でしたが、2025年はAIエージェント元年になると言われています。

なぜ、AIエージェントが重要になるのかというと、今後企業の競争力を決める大きな要因になるのがこのAIエージェント、特に特化型AIエージェントだからです。

基盤モデルのアップデートが速く、様々な生成AI関連サービスが矢継ぎ早にリリースされている状況の中、これらの情報にキャッチアップする事も重要ではあるものの、企業がDX推進で本当に力を入れるべきなのは自社独自の特化型AIエージェントの開発になります。それは以下2つの理由からです。

### 1. 基盤モデルも生成AI関連サービスもいずれはコモディティ化していく
現在は様々な情報が日々アップデートされ、もはや全ての最新情報にキャッチアップするのは不可能な状況ですが、基盤モデル自体もいずれコモディティ化していき、生成AI関連サービスも自然淘汰を経て本当に良いものだけが残る形に収斂していきます。

基盤モデルも当初は各社のモデルによって大きな差がありましたが、既にその差は小さくなりつつあり、利用者側としては、各モデルが本質的に良い・悪いという判断はもはやつけられなくなっています。

各社が出す家電製品や自動車、スマホの性能自体に利用者視点では本質的な差が今やなくなってきたように、各社の最新のモデルのいずれかを使っておけば概ね問題はないという状況に早晩なるでしょう。

また、オンプレからクラウド・SaaSの流れに切り替わった時期は大量のプロダクトが市場に投入されましたが、そこから自然淘汰が進み、今となっては各領域で主力プレイヤーがある程度固まりつつあります。

Officeが導入された当初は、最新のツールであるExcelやWord, PowerPointが使いこなせる事が重宝されましたが、今となっては誰もが当たり前に使っているように、生成AI関連サービスも主力プレイヤーが固まってコモディティ化すると、誰もが使う事が当たり前の状態になっていきます。

基盤モデルにしても生成AI関連サービスにしても、結局のところは、市場で出回っているものはお金を出せば誰もが買えてしまうという事です。お金を出せば誰でも買えるものは本質的な差別化要素・競争力にはなり得ません。

もちろん最新情報をキャッチアップして、最新のツールや製品を使うようにしておくべきですが、API提供されている基盤モデルやSaaSツールはお金を出せば誰でも使えるので、市況を見ながら対応しておけば良いでしょう。

とにかく基盤モデルやツールの最新情報にキャッチアップして、一歩でも他社より早く導入する事に奔走しても本質的な競争力強化にはなりません。

### 2. 基盤モデルも生成AI関連サービスもあくまで汎用型製品
もう一つ重要な視点として、基盤モデルや生成AI関連サービスは基本的に汎用型だという事です。

製品開発側の立場としては、なるべく多くの人達に使ってもらえるように共通化した機能を中心に開発していきます。

生成AI関連サービスの多くが、議事録作成や要約、メールのドラフト作成や音声文字起こし等を推している事からもわかるように、なるべく利用者を増やそうとするとこのような共通領域の機能提供にどうしてもなります。

業界特化型のツール等も出てきていますが、業界特化とはいえ、業界内で見ると汎用になるので、こちらも競争力に直結するわけではありません。本当に良い製品なら、業界内各社が使うようになり、こちらもコモディティ化していくからです。

このように、あくまで市場に出回っている製品はコモディティ化する上に、基本的に汎用用途のため、これらの最新ツールにキャッチアップして利用していく事は必須ではあるものの、これ自体はDX戦略とは言えません。

差別化・競争力強化の源泉となるのは、あくまでその企業独自のビジネスモデルや業務プロセス、ナレッジ、リソース等になります。つまり、自社の強みを最大限活かす事のできる専用の特化型AIエージェントを構築できれば、その企業独自の強みを大きくレバレッジする事ができ、他社には追従できない強みとなります。

ノンコア業務や汎用領域については、市場製品やSaaS系ツールを上手く使いつつも、コア領域においてどれだけ強い自社専用の特化型AIエージェントを作れるかが今後最も重要なDX戦略の一つ（勝負の分かれ目）になっていくでしょう。

特化型AIエージェントは、基本的に人的リソースのような制約を受けず、いくらでも複製できます。そのため、自社独自の高性能な特化型AIエージェントを開発し洗練させていけば、業界によっては一社独り勝ちのような状態になる可能性を秘めています。

経営資源で重要になるのは、ヒト・モノ・カネとよく言われますが、今後はおそらく、ヒト・モノ・カネ・AIとなり、AIがない企業は大きく競争力を大きく落とす事になるでしょう。

AIエージェント元年と言われる2025年以降は、もはや経営資源の一つと言える、どれだけ強い特化型AIエージェントを各社作れるかという競争になっていくのではないでしょうか。

## 生成AI・AIエージェント時代に企業が準備しておくべき事

ここからはもう少し具体的な話として、生成AI・AIエージェント時代に企業が準備しておく必要がある、重要な3つのポイントについて解説していきます。

### 1. 特化型AIエージェントの開発
まず、最も重要な事は、ここまで述べてきたように自社独自の強みを活かす特化型AIエージェントの開発を進める事です。

ここはいわゆるChatGPT活用研修やMicrosoft Copilot活用のような汎用領域や製品活用とは分けて考える必要があります。

汎用的な業務の効率化や改善という視点ではなく、「自社の強みを最も活かすAIエージェントは何か？」という視点で構想を策定し、特化型AIエージェントの開発を進めていく事が重要になります。

ChatGPTやMicrosoft Copilot等は一般的に利用しているという会社と、ChatGPTやMicrosoft Copilot等の活用に加え、自社独自の特化型AIエージェントが複数稼働しているという会社では、企業としての競争力の差は明らかでしょう。

以下、特化型AIエージェントの企画・開発において重要となるポイントをいくつか記載します。

#### ポイント①極力ノープロンプトを目指す
生成AIが注目されるようになってから、「プロンプトエンジニアリング」という言葉も次第に注目されるようになりました。

生成AIの機能を正しく引き出すためには、短いチャットの指示だけでは不十分で、指示と目的が明確になるよう、適切なプロンプトを組み立てる事が重要だということです。

これは上司が部下に指示を出す際の話と同じで、ざっくりとした曖昧な指示では、部下がどうすればいいのかわからないのと同様に、AIに対してもなるべく詳細かつ具体的に指示する事が重要だという事です。

プロンプトエンジニアリング自体はもちろん重要で、知識として知っておいたほうが良いのは間違いないのですが、AIエージェントを開発する際に重要なのはむしろこの逆で、いかにユーザーがプロンプトを入力せずに済むようにするかです。

「プロンプトエンジニアリングが重要」と声高に唱え、研修・教育等を積極的に実施しても、ほとんどの場合、従業員に広く定着する事はありません。なぜなら、詳細かつ具体的に指示する事自体の重要性には誰も異論はないものの、単純にそれが面倒だからです。大前提として、長々としたチャットを打ちたいという人は誰もいません。

そもそも、優秀な人材というのは、端的に言ってしまえば「よしなにやってくれる人」と言い換える事もできます。つまり、あれこれ細かい指示を出さずとも自分から動いてくれて、場合によってはこちらから指示を出す前に自分から動いてくれる人材という事です。

具体的かつ詳細に指示を出さないと動けない人材はハイパフォーマーとは言えず、むしろローパフォーマーの位置づけになります。あれこれ指示を出さなくても能動的に自分から動いてくれる人を誰もが求めています。

つまり、優秀なAIエージェントの構築においては、いかにユーザーのプロンプト入力による指示の負担を減らせるかという事が重要になってきます。

場合によっては、プロンプト入力が不要な状態、いわゆるノープロンプトで使えるAIエージェントを構築できればそれに越した事はないという事です。

極力短いチャットだけで済むようにするのも一つですが、選択肢が提示されていて、ボタンを選択するだけで良いというような構成もユーザビリティが高いと言えるでしょう。

やはり、チャット欄を提示されると、どのような内容を入力しければならないのかと誰しも迷ってしまいます。

プロンプトエンジニアリングが重要という事を前提に、ユーザーが多くのプロンプトを打たなくてはいけないAIエージェントを構築してもおそらくあまり利用が定着する事はありません。

目指すべきはむしろ逆で、自社の業務プロセスやノウハウ、独自データなどを埋め込んだAIエージェントを構築し、難しいチャットを打たなくてもユーザーが容易に利用でき、その上でユーザーをベストプラクティスのレベルにまで引き上げるような特化型AIエージェントを作る事が重要になります。

インプットの自由度が高いという事は、利用者の使い方によって良くも悪くもなるという事でもあるため、こちらはどちらかというと汎用型のAIが担う領域となります。

特化型AIエージェントの重要性はあくまで「特化」であるため、インプットの自由度をむしろ下げ、自社における最適化を進めていく事が重要になります。

#### ポイント②自律型にこだわらずAIに任せる範囲を見極める
ここからは構築サイドの話になりますが、AIエージェントの構築の際に、あまり自律型にこだわりすぎないほうが良いという話になります。

というのも、よく言われるAIエージェントのストーリーとして「これまではチャットベースでの応答型のAIでしたが、今後注目されるAIエージェントは自ら考えて行動する自律型です」というものがありますが、コンセプトとしてのわかりやすさも相まって、少しこの「自律」という点が強調されすぎているからです。

完全自律型の問題点は、全てを考えてしまうため安定性が低い上に単純に遅いという事です。OpenAIのOperatorやAnthropicのComputer Useを見た事がある方はわかるかと思いますが、画面の全ての要素を認識して必要な箇所を抽出し、想定できる様々な選択肢から次の行動を考えるという事を毎回やるので、遅い上に実行毎に結果も異なってしまいます。

デモとしては面白いのですが、企業の実業務で安心して使えるかというとなかなか難しいでしょう。

特化型AIエージェントの構築に重要な事として、全ての業務にはそもそも型があるという事です。

つまり、全てをAIに考えさせる必要はなく、考えるべきポイントはAIに任せ、考える必要のないポイントではAIは使わないという事が重要になります。

例えば、特定の業務領域における情報検索に特化したAIエージェントを構築する場合は、あまねくサイトをスコープにしても取得した情報の真偽の判断がつかないため、結果の取り扱いに困るという点があるでしょう。その上、毎回大幅に結果が変わるため、AIとしての信頼性も低くなります。

こういった場合は、信頼できるサイトや、有償かつ優良な情報サイトを一覧にした上で、「この中から検索して」という形で、スコープを絞ってあげるほうが、速度面や信頼性も含め大きく改善されるでしょう。

また、特定のシステムから情報を取得するような場合も、APIのドキュメント一覧だけを渡してもそれなりにAIエージェントは動くとは思いますが、どのAPIを使うべきかを毎回考える上に、入出力の結果のチェックも実施しますが、それでも時々エラーが出てしまいます。

このような場合はそもそもAIに任せるのではなく、専用のプログラムを実装してしまって、その結果をAIに使わせるという形が良いでしょう。この形のほうがそもそも圧倒的に処理が速い上に、エラーハンドリングは既に組み込んであるため、信頼性が向上します。

つまり、特化型AIエージェントの設計において重要な事は、「どこをAIに任せて、どこをAIに任せないか」という点になります。AIで解く必要のない問題をあえてAIで解く必要はありません。

あらゆる業務には型があるので、おそらく、ベストプラクティスを埋め込んだ特化型AIエージェントは、自然とワークフロー形式になる事が多いでしょう。

最も有名なAIエージェント構築のオープンソースライブラリの1つであるLangGraphも、手放しでAIに任せるという訳ではなく、ワークフロー化やモジュール化を強く意識した設計思想になっています。

処理のステップをほぼワークフロー形式で指示し、各ステップ内でAIを使うというようなケースもあれば、メイン処理はステップ含め検討させるものの、前処理と後処理は固定するというようなケースもあると思います。

少なくとも特化型AIエージェントにおいて、完全な自律型で設計する領域はそれほど広くはなりません。

AIエージェントの「自律」という言葉に引っ張られすぎると、AIの処理スコープが必要以上に大きくなりすぎてしまい、リリースに向けた着地や評価が難しいという事態に陥ってしまう可能性があります。

AIエージェントにおいて重要な事は、あくまでユーザーから見たときに、あれこれ指示を出さずに自律的に対応してくれるという事なので、特化型AIエージェントの構築(バックエンド)においては、必要以上に自律にこだわらず、AIの使い所を正しく見極めていく事が、AIエージェントの性能を上げる鍵になります。

#### ポイント③Human-in-the-loopを上手くいれる
こちらも過度に自律型にこだわりすぎないための重要なポイントになります。

というのも、まだまだAIエージェントの利用が一般的ではない現在のフェーズにおいて、「このAIエージェントに頼めば、自分で考えて必要なタスクを最後までこなしてくれます」と言われても、利用者側としては「本当に全部任せて大丈夫かな。。」と不安になるためです。

いわゆる参照情報の提供のようなレベルまでであれば業務影響はないので良いのですが、金銭のやりとりが発生する場合や顧客との接点での利用、またシステムへの情報登録なども実施する場合は、まだまだ手放しで任せるのは不安という方も多いでしょう。

この状態で、自律型を謳い文句にしたAIエージェントをいくら展開しようとしても、なかなか現場としては受け入れづらいという事になるでしょう。

ここは必要以上に完全自律型にこだわらず、Human-in-the-loop型、つまり人間の適切な介入も設計として入れこんでおくという事が有効になります。

つまり、まだまだ信頼性に課題があり、発展途上の段階のAIを全て信じる事は難しいので、一連の処理の中で、人間による確認の観点も含めて設計しておくという事です。

これは人間でも同じ話で、仮にどれだけ優秀な人材を採用したとしても、初日から任せた仕事に対して「全て終わらせておきました」とだけ言われると不安になるのと同じ事です。

ここで期待される動き、おそらく最も優秀な人材というのは、あれこれ指示を出さずとも動いてくれるものの、報連相はしっかりしてくれる人材という事ではないでしょうか。

つまり、自律型といっても完全自律型ではなく、必要なタイミングでの報連相を適切に設計しておく事によって、ユーザーが安心してAIを利用できるようになります。

私も含め技術者としては、技術的な面白さとインパクトから、なるべく自律型にしたいという想いが誰しもあると思いますが、結局の所、現場の方々に使われなければ意味はありません。技術的に面白いというだけでは付加価値はゼロだからです。

「AIエージェント＝自律型」のイメージが強い方も多いと思いますが、このイメージに過度に捉われすぎる事なく、実際の利用者になる方々と会話しながら、AIに任せる範囲と人間の介入を行う範囲の設計も含め、着地点を上手く探っていく事が重要になります。

## 2. API・データ基盤の整備
ここまで特化型AIエージェントの重要性について記載してきましたが、では、「我が社も独自の特化型AIエージェントを開発しよう！」と思い立てばとにかくAIエージェントの開発が進められるのでしょうか？

実は、自社の強みを活かすAIの構想策定や企画と同等に重要になるのが、「AIが自由に動ける環境がそもそも社内で整っているか？」という事です。

特化型AIエージェントの構築には、当然社内情報へのアクセスが必須になりますが、AIエージェントが社内情報にアクセスできるかどうかは、言い換えれば、システムとのAPI連携ができるか、またデータ基盤にデータが整備されているかという事になります。

技術的な形で端的に言ってしまえば、AIがシステムとAPIでやり取りできるか、また必要なデータをデータ基盤からSQLで取ってこれるかという事になります。

AIエージェントは人間と違い、システムの画面(GUI)の操作はしないので、システムからデータを取得したり、システムにデータを登録する場合はAPIを介して実施し、企業のデータ等にアクセスする場合は、データ基盤に対してSQLを発行してデータを取得します。

そのため、社内にまだまだ紙が多く、オンプレのGUI操作しかできないシステムばかりで、データも各所に散在しているというような状況では、そもそもAIがデータにアクセスできないので、特化型AIエージェントの開発は進められません。

また、今後どれだけ強い基盤モデルが出てきたとしても、AIにできる事はかなり限定的になってしまいます。

これは、どれだけ速く走れる車が開発されたとしても、舗装されていない道路やそもそも通れないような道路では、その機能を発揮する事はできない事と同じになります。

「今までデジタル化は積極的に進められていなかったけど、今からAIを頑張れば一気に巻き返せないか」と期待する方もいるかもしれませんが、ここはリープフロッグのような事はなく、これまで地道にDXを進めてきた企業がいち早くスタートを切れる上に、その速度も上げられるという状態になっています。

これまでのDX推進がAIによってゲームチェンジしたように見えますが、どちらかというと、これまでDXをしっかりやってきた企業(地道に足回りを整えてきた企業)が、更に加速できるという位置づけで捉えておく必要があります。

ただ、「順番的にはAPIやデータ基盤を整える事が先で、AIエージェントの開発は後じゃないの？」と思う方もいるかもしれませんが、特化型AIエージェントの開発の重要性をこちらより先に書いたのは理由があります。

それは、「DXはあくまでアウトプットファーストで進めるべき」だという事です。というのも、ビジネス部門とIT部門に距離がある場合に典型的に起こるケースですが、先にIT部門がデータ基盤を整えたものの、具体的に何に使うかが決まっていない(実際のところ誰も使っていない)というケースがよくあるためです。

これは典型的なインプットファースト的な進め方で、いつか使うかもと思って勉強した事が、結局使う機会がなかったという事と同じことです。

データをとにかくためれば、何かしら良いAIができるという事はなく、実際の所、どういうAIが必要なのかという事が具体的に決まらなければ、どのデータが必要なのかという事は定義できません。

「AIにはデータが必要だからとにかくデータを整備しないと」「うちはデータが整備できていないからAIの導入はできない」という人が多くいますが、実際は逆で、「こういうAIを作りたいから、こういうデータが必要」というのが正しい検討の順番になります。

つまり、自社で作りたい特化型AIエージェントのイメージが具体的にできると、このAIを作るためにどのデータが必要なのかという事が具体的に決まってきます。

データの粒度に関しても、月単位で良いのか、日単位で必要なのか、バッチで処理できれば良いのか、リアルタイムで最新情報にアクセスする必要があるのかなどは、実際のアウトプットの機能が決まらなければ具体的には決まりません。

API・データ基盤の整備はもちろん重要ですが、「API・データ基盤を整備しよう」と言っても、これ自体ではスコープが決まらないので、先に特化型AIエージェントのアウトプットを定義して、そこから逆算で必要なAPI・データ基盤を整えていくという形が良いでしょう。

インプットファースト的な思考で、「これも使うかも」と用意しておいたデータは使われずに終わる事が多いため、アウトプットファーストで進める方が、最短距離で無駄なく走れます。

## 3. 統合UIの準備
これは実はAIに限った話ではないのですが、これからのAI時代にいよいよ真面目に検討を進めていかないといけないのが、この統合UIの検討になります。

というのも、今後汎用型や特化型AIエージェント等が更に増えていくことが予想されるものの、今時点の段階で既に、システムやデータが増え続けており、従業員からすると「どこに何があるのかよくわからない」という状態になっているからです。

特に大手企業においては、いわゆる社内ポータルサイトのような所で利用できるシステムのリンクを一覧化されているケースも多いと思いますが、おそらく社内のシステムと機能を全て熟知している人は誰もいないでしょう。

従業員の間で「こんなシステムあったんだ。。」「ここからこのデータ取れるんだ。。知らなかった。。」というような会話は日常茶飯事の状況で、システムの利便性を向上させるという名目と同等かそれ以上に、そもそもちゃんと認知され、利用されているのかという事をモニタリングする事がDX・IT部門にとって重要な課題になっています。

そして今後更に、活用できるデータとシステムは増え続けるため、もはや各個人が認識できるレベルは完全に超えてしまうと言ってよいでしょう。

そもそも個人のレベルで正しく認識して使い分けられるシステムの数はおそらく5個前後ではないでしょうか。10個程度までならまだなんとかなりますが、20や30、それ以上のシステムがあるという状態になってくると、認知の限界を超えてしまい、そもそも知らないというシステムが多数の状態になってしまうでしょう。

既にこのような状況において、各システムに新規のAI機能を載せたり、個別の特化型AIエージェントを開発しても、そもそも認知・普及の壁を越えられないという事が容易に想像できます。

どれだけ便利なシステムやAIを構築しても、存在やその利便性自体が知られていなければ、当然ながら構築した意味がありません。

一方で、各システム担当やAI構築担当がそれぞれ独自に社内の認知・普及に力を入れると、同じ会社内にも関わらず、各担当が限られた従業員の認知リソースを取り合うような構図になってしまいます。

こうなると、声の大きい部署や社内マーケティングの上手い部署の物ばかりが目立つという事になります。

本来であれば、DX・IT部門はシステムやAIの構想策定・企画、開発・テスト、ユーザビリティ向上や品質改善に力を注ぐべき所が、認知・普及のための社内マーケティングに割かなければいけない工数がどんどん膨れ上がっていくという事です。

このように、システムやデータが増え続け、更にAIエージェントも新規に構築されていくような時代においては、「従業員の認知の問題をどうするか」という事は避けては通れない問題になります。

ここで1つ有効なソリューションは、AIをコンシェルジュとした統合UIを作成し、各システムや、特化型AIエージェント群とのタッチポイントにする事です。

各システムや特化型AIエージェントは当然、それぞれの目的を達成するための最適なUI構成になっているため、これ自体を一つに統合する事は現実的ではありません。

これだけ変化の速い時代でモノシリックなアーキテクチャはいずれ崩壊するので、マイクロサービスのような状態を保っておく必要があります。

あくまで既存のシステムなどには手を入れずに、ユーザーが最初にアクセスする統合UIを用意し、ここから目的に応じて、必要なシステムやAIエージェントに誘導させる形が一つの有効な形になります。

これは簡単に言ってしまえば、「社内で利用できるシステムやAIエージェントを全て熟知している人にいつでも聞ける状態を作る」という事です。

この状態の利点は、利用者となる従業員側とシステムやAIエージェントを展開するDX・IT部門側の双方にあります。

まず従業員側としては、今後様々な新しいシステム、AIエージェントが展開される中で、とりあえずここに最初にアクセスすれば良いという状態になるので、システムやデータの利活用に迷う事がなくなり、非常に楽になります。

社内システムやSaaSを含め利用システムが多く、チャットボットが乱立していたり、いつの間にか新しいシステムに移行していたりと、社内IT環境に辟易してしまっている従業員の方も多いのではないでしょうか。その一方で、「こんなシステムがあるならもっと早く知りたかった。。」という声も多くあります。

つまり、「あ、それをやりたいなら、このシステム・AIを使って、こうすると良いですよ」と最短で教えてくれるコンシェルジュ的なAIがいるのは、従業員側として非常に有難いという事です。

特に人材の流動性が高まる中で、新入社員の方や人事異動で新しい部署に来た方達にとっても強い味方になるのではないでしょうか。

そして、利用者側だけでなく、DX・IT部門側にとっても利点が大きく、その理由は、本来力を入れるべきシステムやAIの開発に集中できるという事です。

どういう事かというと、先ほど説明したように、既に各個人の認知可能な範囲を超えるレベルで、システムやアプリ・AIがあるため、DX・IT部門は開発だけに集中できる状態ではなく、社内マーケティングのような活動が必要になってしまっています。

つまり、新規のBIやAIアプリなどの場合で特に顕著ですが、単純に開発してリリースすれば終わりではなく、リリース後の説明会の実施や勉強会、地道な普及活動など、知ってもらう・使ってもらうための活動のウェイトがどんどん大きくなっているという事です。

私自身、かなり良い物ができたなとチームでは自信を持っていたものの、リリース後に思ったように利用率が上がらず、「何かUXや機能面に課題があるのかな。。」と思い、個別にアンケートを取ってみると、「こんなに良い物があるならもっと早く教えて欲しかった」という意見が多数で驚いた事があります。

関係者を集めた説明会や通知はしっかりやっていたつもりでしたが、それでも社内ITが複雑化している中、知ってもらうというハードルはどんどん大きくなっているという事です。

今後この傾向は更に強くなっていくため、発想の転換が必要になります。ここでポイントとなるのは、各個人が認識できるシステムやアプリの数には限界があるものの、AIにはその限界はないという事です。

つまり、各従業員に全てのシステムを認知して使い分けてもらう事は諦め、AIに全てを認識させ、必要な物をレコメンドしてもらう形にする事によって、社内マーケティングを事実上不要にするという事です。

従業員側としては、統合UIにひとまずアクセスして、AIコンシェルジュにやりたい事を言えば最適なシステムやAIエージェントを案内してくれ、DX・IT部門側としては、この統合UIのAIコンシェルジュが参照する情報に新システムやAIエージェント等の情報を登録しておけば良いという形になります。

このように統合UIが、従業員とDX・IT部門のコミュニケーションの潤滑剤のような役割を果たしてくれるため、従業員側としては社内ITの活用に迷う事がなくなり、DX・IT部門としてはシステムやAIの開発に集中できるようになります。

とはいえ、「この統合UIの開発が難しいのでは？」と思うかもしれませんが、どちらかというとここは各システムやAIエージェントとの独立性を高くしておいた方が良いため、まずは各システムやAIエージェントの一覧情報のリストを作成し、利用者からのリクエストに対して、必要なシステムやAIエージェントの機能紹介と共に、URLを案内するというような形から始めれば良いでしょう。

統合UI側に各システムやAIエージェントの機能を寄せ始めるといくらでも膨張し、いつの間にか重厚長大な物になってしまうため、あくまで各システムやAIエージェントの案内のハブの役割として、薄くレイヤーを被せるという位置づけのほうが良いでしょう。

認証やアクセス制御、詳細な利用マニュアル等も、一旦URLに遷移させてから各システムやAIエージェントに任せるという形で割り切ったほうが良いでしょう。とにかく、各システムやAIエージェントとは疎結合の状態にしておく事が重要になります。

個別特化の機能は持たせずに独立性を保った上で、あらゆる従業員とのタッチポイントになるため、レスポンス性や安定性、画面のデザイン含め、UXの向上に注力する事が重要になります。

一方で、広く社内情報を検索できるという機能は備えておいても良いでしょう。こちらは、あくまで専用の作り込みはせず、適合性ではなく再現性重視の社内情報検索機能になります。

精度はともかく、ひとまず社内情報に一通り届くという事を目的とし、「こういう事やりたいんだけど関連資料ないかな」という時に、関連性の高そうな情報を一通り返してくれる、いわば、社内全文検索のAIによる強化版のような形です。

RAGによる社内情報検索アプリの構築で最もはまるケースは、ピンポイントで情報を返させようとしすぎて、その精度が出ずにいつまでもリリースできないという事です。

特定の領域の精度を上げようとすると、むしろ他の領域の精度が下がってしまう、あちらを立てればこちらが立たずという状態になります。

また、現状のドキュメントでは精度が出たが、ドキュメントを更新すると途端に精度が下がってしまったというケースも多くあります。

従業員側としては、関連しそうな情報を広く拾ってきてくれるだけでも十分有難いので、適合性はある程度諦め、再現性重視の社内情報検索機能はこの統合UIの機能として入れておくと良いでしょう。

もちろん、特定の領域・目的に対して、精度高く情報を検索させたい(適合性を高めたい)という場合は、特化型AIエージェントとして開発・リリースすれば良いです。

この統合UIのイメージとしては、Googleが発表したAgentSpaceが参考になります。社内のアプリやAIとのタッチポイントとなる上にNotebookLMによって社内情報の検索等も容易に実現できます。MicrosoftのCopilotも構築したAIエージェントに容易にアクセスできる機能を持ち、同じような位置づけになっていくでしょう。

では、「この辺りをそのまま使えば良いのでは？」と思うかもしれませんが、1つ注意点があります。

統合UIはあらゆるシステムやAIエージェントとのタッチポイントになるため、気をつけなければ容易にロックインしてしまうという事です。

先ほど疎結合の状態を保つ事の重要性を強調したのもそうですが、この統合UIを外部ツールで構築し、社内システムとの連携度を高めてしまうと、おそらく途中でスイッチする事が難しくなってしまいます。

いつの間にか周辺ツールも含め、意図せずともそのベンダーの関連製品が多くなってしまう事でしょう。あらゆるシステムやAIエージェントとのタッチポイントになるからこそ、ロックインしないように、その独立性を高めておく事が重要になります。

また、統合UIはその企業のビジネスモデルや従業員・組織形態によっても最適な形が当然異なるため、自由にUIをカスタムできる状態にしておくほうが望ましいでしょう。

ベンダーのツールは良くも悪くも、誰もが簡単に使えるようにUIがほぼ固定化されているため、リリース後に自社独自のカスタム要件が出てきた場合、個別のSIによりむしろ高くつくという状態になります。

最近は従業員1人当たりの課金という製品が多くなってきている事もあるため、ランニングコスト面やロックインの危険性も加味し、統合UIに関しては、特定のベンダー依存しすぎないように、自社独自のものを構築したほうが良いでしょう。

ここまで長く記載してきましたが、生成AI・AIエージェント時代のDX推進においては、自社の強みを最大化する「特化型AIエージェントの開発」、その開発を支える「API・データ基盤の整備」、そして、従業員を迷わせないための「統合UIの構築」が重要になります。

## まとめ
いかがだったでしょうか。

良くも悪くも、AIが世間で広く注目されるようになり、AIに関して、あまり重要でない情報も広く流布されるようになりました。

重要なもの、重要でないものも含め、日々新しい情報の多さに混乱している人も多いかと思いますが、企業の取り組みで本質的に抑えておくべきポイントはそれほど多くありません。

一過性の情報に左右されることなく、DX推進の幹の部分を太くしていく一助になれば幸いです。