生成AI・AIエージェント時代のDX～企業のDX推進で押さえておきたいポイント～後編～

生成AIが登場してから2年以上が経ち、AIエージェントが企業のDX戦略で重要な役割を果たす時代が到来しています。専門家は2025年を「AIエージェント元年」と位置づけ、企業の競争力強化には自社独自のAIエージェント開発が鍵を握ると予測しています。後編では、「API・データ基盤の構築」「統合UIの準備」を中心に、特化型AIエージェントの事例についても解説します。

【関連記事】 生成AI・AIエージェント時代のDX～企業のDX推進で押さえておきたいポイント～前編～

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・データ基盤を整えていくという形が良いでしょう。

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

統合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エージェントの開発において、参考になる点が多いのではないかと思います。

企業事例1. ウォルマート：調達交渉AIエージェント

日々、膨大な数のサプライヤーから、さまざまな製品・資材などの調達を行うウォルマートは、各社との価格・納期の調整業務の効率化を目的としたAIエージェントを構築しました。AIエージェントに調達の目的と商材の概要、予算を伝えると、過去の取引データや競合他社の見積額、原価の変動データなどをもとに最適な購買価格を算出し、AIエージェントが各サプライヤーと自動で交渉を実施します。スタッフでは数週間～数か月かかっていたサプライヤーとの交渉をAIエージェントにより数日程度に短縮する事を可能にしました。

こちらはまさに、「調達」というコア業務の領域で、自社のノウハウを詰め込んだ特化型のAIエージェントを構築している良い事例なのではないかと思います。また、ウォルマートという大手であるため、サプライヤーに対して強い交渉力を持つという調達における自社の強みも上手く活かしているのではないでしょうか。さまざまなステークホルダーがいる中、自社のビジネスモデルの中で「どこまでならAIエージェントで踏み込めるか」というラインを見極めつつ、AIエージェントを設計する事が重要になってきます[1]。

企業事例2. Morgan Stanley：財務アドバイザーサポートAIエージェント

米大手金融機関Morgan Stanleyでは、生成AIを活用した社内チャットボットを2024年以降に正式導入しました。財務アドバイザーをサポートするAIエージェントが膨大な社内リサーチやナレッジベースへ素早くアクセスし、投資提案や顧客対応の効率化を支援し、従来、必要情報の検索や文書の要約に多くの時間を要していましたが、このAIアシスタントにより作業が大幅に短縮され、提案の質向上にもつながりました。リリース後、98%以上のアドバイザーが日常業務で活用しており、7,000件に限定されていた回答可能範囲は10万件以上の社内文書へ拡大し、社内にある高度な専門知識を誰もが瞬時に利用できる仕組みは、サービス品質と顧客満足度の向上に寄与しています。

こちらもコア領域かつ、社内のナレッジベースの膨大な文書情報を活用する事で、他社には追随できない強みを持ったAIエージェントとなっています[2]。

企業事例3. Allianz：クレーム対応AIエージェント

世界的保険会社Allianzは、保険金請求（クレーム）業務を支援する特化型AIエージェント「Insurance Copilot」を2024年にまずオーストリアの自動車保険で導入しました。大型言語モデルを活用し、契約内容・過去請求データ・顧客情報などを自動解析・要約して担当者に提示することで、煩雑な書類チェックや不足情報の特定を効率化します。

従来、クレーム処理には多くの手作業と時間が必要でしたが、AIが下調べを代替し、迅速な支払い判断をサポートするため、顧客満足度が向上し、過大請求や不正請求の兆候を早期に発見できるため、余計な保険金支払いを防ぎ、保険料の安定にも寄与しています。また「Human-in-the-loop」方式を採用し、最終判断は人間が行うことでコンプライアンスや説明責任を確保。保険金支払いプロセスのDXを牽引する事例として注目されています。

クレーム処理という顧客接点のかなりウェットな領域ではあるものの、Human-in-the-loop方式に上手く取り入れる事によって導入を進めた事例になります。クレーム対応に関しては今後、各社同様のAIエージェントの構築は進めていくものと思われますが、早期から試行錯誤を進め、性能を高めた特化型AIエージェントはそれ自体が大きな競争力となり、AIの性能向上のためのデータ環境の整備、UIの作り込みも含め、その企業の大きな強みの一つとなっていくのではないでしょうか[3]。

著者の取り組みをご紹介

ここからはより手触りのある話として、私が現在クライアントと協業して構築を進めている特化型AIエージェントの2つの事例について、紹介可能な範囲とはなりますが、概要を紹介していきます。

1.営業支援特化型AIエージェント

一つ目は営業職員の方々の日々の営業活動を支援する特化型AIエージェントになります。

「営業職」と聞くと、企業の最前線で働き、ほとんどの時間を商談などの対面の営業活動に費やしているというイメージがあるかもしれませんが、実際のところは、商談先の事前調査や提案書作成、商談結果のシステム登録や報告作業も含め、営業に関する事務的な周辺業務が非常に多くあるという悩みが従来からあります。

一方で、いわゆる数値情報だけでなく、交渉状況等も含めた非常にウェットな情報も多く取り扱うため、これまでの手続き的かつデジタルベースでのITではなかなか踏み込めない領域も多く、補助的なサポートに留まるという状況にありました。

私自身、長くRPA等を活用した業務自動化領域に携わってきましたが、やはり定型業務の自動化はバックオフィス領域が多く、業務プロセスや利用データ含め、業務手順をルールベースで定義しきれるわけではない、営業領域のようなフロントオフィスの支援はなかなか難しいというのが実情でした。

一方、生成AIの登場により、これまでのフロントオフィスにおけるDX推進の様相が大きく変わりました。というのも、生成AIはその性質上、ゼロイチのような手続き型の処理をするのはあまり得意ではなく、むしろ言語情報のような非構造化データの取り扱いが上手いという特性があるためです。

営業部署が持つデータは、商談の状況や議事録情報など、デジタルデータにするとあまりにも情報が落ちる非構造化データが多数あり、これまでは定型的に処理するために無理矢理デジタル化していたケースもあったものの、生成AIの登場により、この非構造化データを直接取り扱えるようになりました。

そのため、生成AIと営業領域はむしろ非常に相性の良い領域として挙げられており、ガートナー社のレポートでも営業機能領域の周辺業務の約60%が、中長期的に生成AI関連技術によって自動化・削減が可能との予測が出ています[4]。

営業機能領域については、商談準備から商談中、商談後の業務含め、おそらく全領域で生成AIによる支援が可能になる想定で、そのロードマップも検討していますが、今まず優先的に取り組んでいる「社内接点検索」と「CRM活動情報サマリ」の取り組みについて簡単に説明していきます。

「社内接点検索」は、特定の取引先とコンタクトを取りたい場合に、社内で強い接点を持つ人物を検索するための機能になります。

なぜこの機能が重要かというと、私のクライアント企業はいわゆる同一の製品を大量に販売するモデル（自動車や家電, SaaS）ではなく、一つ一つの商材が完全に個別の商品であるため、商材と買い手のマッチングが肝になるからです。

同一の商材であれば、営業プロセスはある程度標準化・共通化できますが、同じ商材が存在しない個別の商材かつ、一つ一つの商材の売上規模が非常に大きいため、いかに商材と買い手の最適なマッチングを実現させるかが営業において最も重要なポイントの一つとなります。

つまり、商材の買い手候補となる各クライアントとの社内の接点情報を常に把握しておくこと、また最新の接点情報を常時取得できる事は、営業活動を行う上で非常に重要なポイントになります。

これまではCRMや名刺情報, 取引履歴情報や予定情報など、さまざまなシステムを各人が個別に検索し、特定の取引先に関する接点情報を繋ぎ合わせた上で、社内接点の強そうな人を間接的に類推するしかありませんでした。当然、接点になり得る情報は各システムに散在しており、日々の営業活動における時間の制約上、断片的な情報から判断するしかありませんでした。

このような状況を踏まえ、生成AIを活用して社内接点のソースとなるシステムを一気通貫で検索し、特定の取引先に関する社内接点の強い人物候補をランキング形式で表示するAIエージェントを開発しました。

最初から特定の人物の接点詳細情報も全て表示するのは、レスポンス時間や表示する情報量の観点からもユーザービリティの低下に繋がると判断し、最初のレスポンスでは、接点上位候補者とそのサマリをクイックに表示し、利用者が接点を深堀りたい人物を選択すれば、その人物に絞った情報を各システムから抽出し、接点詳細情報が生成される2段階の操作構成としました。

直近の商談履歴や未来の面談予定等の情報も取り入れているため、特定のクライアントとコンタクトを取りたい時に社内でタイムリーに連携できるようになったと好評の声を頂いています。フィードバックの中で「この機能は営業領域だけでなく、全社で使えるのではないか？」との声が上がり、将来的には全社展開も見据えています。

この機能の構築において、生成AIの強みで面白いなと感じたのは文字の揺れの吸収の上手さです。というのも、同じ人物でもシステム毎に、〇〇さん、〇〇課長、〇〇マネージャーのように登録名が異なる事はよくあり、部署等もシステム毎に完全に一致しないケースはよくあります。この辺りを実際に一つ一つルールで定義しようとすると、容易にルール爆発を起こしてしまうのですが、生成AIはこのような揺れを人間のように上手く吸収してくれます。

今後、役員との接点に特化した接点検索や、特定部署との接点情報の検索等も検討していますが、これまでのITやAIではルールが定義できず、スコープに入らなかった所まで、生成AIによって具体的な検討が進められるようになってきています。

もう1点、取り組みとして進めているのが「CRM活動情報サマリ」機能です。

各営業担当が日々の営業活動における商談情報やその議事録をCRMに順次登録していくのですが、一つ一つの商材の規模が大きいため商談の期間が長く、商談議事録の確認も含め、これまでの商談経緯や最新の交渉状況がどうなっているのかという事が一目でわかりにくいという悩みがありました。

交渉におけるかなりウェットな情報も含むため、タグやステータス管理のような情報だけでは詳細状況の把握が難しく、議事録に重要な情報が入っているため、参照においては各商談の議事録を順番に見ていく必要があるというような状況でした。

当然、人によって議事録の長さや粒度、書き方のスタイルにもバラつきがあるため、CRMに情報はあるものの、単なる挨拶だったのか、交渉に重要な会話があったのかなどの情報の取捨選択が難しく、特に管理職・上位層の方は商談状況を把握するのが一苦労というような状態でした。

そこで特定の取引先との商談における、過去の商談履歴を一気通貫で検索し、必要な情報をサマリする機能を作成しました。

こちらもユーザビリティを考慮し、初回のレスポンスは取引先との商談の一覧をクイックに返すようにし、初回のレスポンスに対して、特定の商談を選択すれば、その商談に紐づく個別の活動情報を全て抽出し、議事録等の内容も踏まえた上で、時系列で商談の経緯と最新状況をサマリするようにしました。

その際、単なる挨拶のような情報は極力省き、先方の部署や担当者名、価格情報、交渉のキーとなる情報や先方の温度感等を中心に抽出・サマリする形としています。

こちらも営業の企画担当の方とディスカッションを重ねながら、最適なプロンプトを作成し、現場の営業担当の方からもフィードバックを頂いて機能改善を重ねています。実際の現場の利用者の方からも、これまでは一つ一つ確認していくのが大変だったが、必要な情報がクイックに参照できるようになり非常に助かっているとの声を頂いています。

実際にいくつかの機能を開発してみて、共通して感じた生成AIの大きな強みが「高速でPDCAを回せる」という点です。

開発したプロトタイプ版を実際の利用者の方々に触ってもらうと、「このような観点で情報を抽出できないか」「このシステムのこの情報にもう少し重みづけをするとレスポンスが良くなるのではないか」など、さまざまなアイディアを現場の方々から頂くのですが、生成AIの場合は、プロンプトの変更によってPDCAを短期間で回す事ができます。

これまでのITやAIの場合は、試行錯誤と言っても、要件変更として学習データの準備やプログラムの変更に数週間～数か月以上かかるケースも少なくありませんでしたが、生成AIの場合はプロンプトの変更のみで対応できる範囲が多く、場合によってはその場で試してみる事ができます。

仮説検証が容易に繰り返せるため、まずは色々と試してみて、この方向性が良いとなった場合は、プロンプトを更に作り込んだり、バックエンドプログラムの処理速度を高めていくといった形で、現場の方々と密に連携しながらアジャイル型で進めていけるため、手戻りや期待値のずれが本当に少なく、開発の実感としても、これほど楽なのかと日々感じています。

ウェットな情報が多く、バックオフィスのように定型的にルールを決められるケースがそれほど多くはない営業領域のDXにおいて、自然言語のような非構造化データがそのまま扱えること、試行錯誤を繰り返しながらアジャイルで進められる生成AIの性質は大きな強みとなるのではないでしょうか。

構築において留意している点は、既に特化型エージェントのパートで記載したように、極力ノープロンプトを目指している事と、AIに任せる範囲とプログラムで処理する範囲を明確に分けている事です。

チャット欄だけ提示されていて、「何でも聞いて下さい」という状態はユーザーにとってむしろ負担が大きい上に、入力情報が粗くなりがちなので、現場の方たちとディスカッションを重ねながら、重要な観点を詰め込んだ専用のプロンプトを設計し、利用者の方はプルダウンやボタン選択等のクリック操作のみで利用できる状態にしています。

外出先や移動中等にモバイルでも簡単に操作できるよう、今後の拡張においても、UIに関しては個別のプルダウン等の最低限の追加に留めるつもりで、各ユーザーが個別の要望を詳細に伝えずともなるべく先回りして必要な情報を提示し、「そうそう、こういう情報が欲しかった」と思ってもらえるような状態を目指しています。

もう1点はAIに任せる範囲とプログラムに任せる範囲の棲み分けです。関連情報をまるっとAIのインプットとして渡してしまうと、入力情報があまりにも増えすぎる上にレスポンスが遅くなるため、AIの参照情報となるシステム毎の関連情報は全てSQLやAPIのプログラムの専用プログラムで高速に取得、必要な情報のみに加工した上で、生成AIに渡しています。

つまり、1次情報の取得はプログラムで最適化し、2次情報への加工を生成AI+プロンプトで実施させているという事です。あきらかなノイズや古い情報の削除、生成AIにあえて処理させる必要のない集計処理等も先にプログラムで処理し、整理された1次情報を生成AIのインプットとしています。

この辺りの処理は、生成AIのプロンプト調整でも可能ですが、トークン消費やレスポンス速度、品質担保の観点も含め、ルールベースで定義できる処理を生成AIに実施させるメリットは何もないため、常に「これは生成AIに実施させる必要があるのか？」という事を考えながら、AIに実施させる範囲とプログラムで実施する範囲を棲み分けながら構築しています。

2.業務ヒアリング自動化エージェント（ビジネスアナリストAIエージェント）

こちらは少し毛色が変わりますが、私が業務自動化のコンサルタントに転身した当初より実施したいと思っていた、業務ヒアリングの自動化に特化したAIエージェントになります。

いわゆる業務改革・BPRのプロジェクトにおいて、業務コンサルタントたちが人海戦術的に対応していた業務ヒアリングをAIエージェントにより自動化しようという取り組みです。

DX・ITによる業務改革を推進する際にまず実施しなければいけない事、そして永遠のテーマとして「現状把握（AsIs把握）」があります。というのもDX推進やそのロードマップの策定のためには、「今そもそもどうなっているのか？」の現状把握が必要だからです。

現状課題を分析して改善を検討していくアプローチ、ありたき姿（ToBe）をトップダウンで設定してから現状とのギャップ分析を進めていくアプローチのいずれの場合も、現状の業務プロセスがそもそもどうなっているのかという現状把握は必須になります。

この現状把握の段階で非常に困るのが、工場のライン業務のように厳密に工程が管理されているような場合は別として、ホワイトカラーの業務の多くは、可視化・マニュアル化されていないという事です。個々人が属人的に実施していたり、チーム内で暗黙の了解で業務を進めていたりと、当人達の頭の中にしかないという状態が少なくありません。

現状が可視化されていないため、実態は本人たちにしかわからないものの、「では業務フローやマニュアルを整備して、現状を可視化してくれませんか？」とお願いすると「現業が忙しいのでそんな時間はない」「業務フローの書き方や業務整理の仕方がわからない」と多くの場合は断られてしまいます。

しかし、現状把握のステップ自体を飛ばす事は当然できないため、現業が忙しい現場の方たちのかわりに、社内で専用のチームを構築するか、外部のコンサルティングファームなどに依頼して、業務コンサルタントが現場の方達にヒアリングしながら、現状の業務プロセスを可視化していくという事になります。

業務ヒアリング実施の際に困るのがまず、日程の調整です。業務ヒアリングはある程度期間を区切ってその期間内に実施しますが、現場の方々はそもそも忙しいので、なかなかヒアリングの日程が合わないという事がよくあります。また、現場の方々自身の現状の把握状況や、業務プロセスの複雑度によっては一度のヒアリングで終わる事なく、2度3度と実施する事もあり、その度に日程調整が必要になります。

業務ヒアリングを実施する立場としては、複数案件のヒアリングを並行で実施するため、現場の方々の予定を優先しながら、いわば穴埋めパズルのようにヒアリングのスケジュールを立てていく必要があり、業務ヒアリング自体もそうですが、その準備としての日程調整の負担も大きいという側面があります。

続いての問題は、業務ヒアリングの実施者によって、品質のバラつきが非常に大きいという点です。

最も業務ヒアリングが上手い人というのは、前提として対象の業務・業種における土地勘がそもそもあり、専門用語なども理解している人です。その上で業務フローなどの可視化が上手く、重要なポイントとそうでないポイントを取捨選択しながら、要領よく現場の方へのヒアリングを進めていきます。業務ヒアリングの経験が豊富な方は、後続プロセスの事も意識し、課題感やあるべき姿（ToBe）の初期仮説などもセットで検討していきます。

しかし、業務ヒアリングの経験が浅く、対象業務における土地勘がない場合は、必要な情報とそうでない情報の取捨選択ができないため、ヒアリングの粒度粗く、聞き逃している点が多いか、逆に粒度が細かすぎて、現場の方達に必要以上に負担をかけてしまうという事のどちらかになります。

ひどい場合は現場から「うちの部署も●●さんではなく、〇〇さんに実施して欲しい」と名指しでクレームが入る事があります。

人が業務ヒアリングを実施する以上、このようなスキルの差の発生を避ける事はできず、業務ヒアリングチームのリーダーは、進捗管理だけでなく、クレーム対応が入った場合の現場部門やその上長へのお詫び、メンバーの入れ替えや追加ヒアリングの実施なども含め、全体のマネジメント業務に奔走する事になります。

そして最後に問題になるのが、外部のコンサルティングファームなどに依頼する場合、プロジェクトのROIが逼迫してしまうという点です。

業務可視化・業務フロー作成等も含め、業務ヒアリングは一定のスキルと対応工数が必要になるため、社内で必要なリソースが捻出できない場合は、外部のコンサルティングファーム等に依頼する事になりますが、コンサルティングファームの場合は若手でも一か月数百万という単価のレンジのため、外部に委託する場合は、プロジェクトの予算をこの現状把握の段階でかなり食い潰してしまうという事になります。

ここで重要かつ痛いポイントは、現状把握自体には何も付加価値がないという事です。というのも業務改革やDX系のプロジェクトにおいては、現状があるべき姿に刷新されて初めて価値を生むため、現状を把握した段階ではまだ何も付加価値を生んでいないためです。

もちろんこのプロセス自体は必須なのですが、それ自体に付加価値はないにも関わらず、ある種最も工数がかかり、プロジェクトの予算を消費するこの業務ヒアリングのプロセスは、なるべく省力化、可能であれば自動化される事が望まれます。

では、この業務ヒアリングを専用のAIエージェントで実施できるようになると何が嬉しいのでしょうか。まず1点目の利点として、日程調整が不要になります。

AIエージェントにアクセスするURLをヒアリング対象となる方々に案内し、「お手すきの際に対応をお願いします」とだけ依頼しておけば、個別の日程調整が不要になる上に、現場の方も自分の好きなタイミングで実施できるため、現場の方にとっても楽になります。

またAIエージェントは人間と違い複製が可能なため、同一のAIエージェントを並列で稼働させる事ができます。人間の場合は、同じタイミングでヒアリングできるのは1人1件までであるため、業務ヒアリング実施者の頭数がリソース上の制約となりますが、AIエージェントの場合は同時並行で稼働できるため、この制約がなくなるという事です。

これは大規模なプロジェクトの場合は特に重宝し、例えば10部署100業務を対象としたヒアリングを実施するような場合、人間の場合は、例えば各部署1名ずつ、10人で数か月かけて実施となる場合も、AIエージェントの場合、極端に言ってしまえば、「この日にお願いします」と現場の方々に依頼し、現場の方たちの都合さえつけば、1日で終えられるケースもあるという事です。

そして、AIエージェントによる最も大きな利点が、業務ヒアリングの品質のバラつきを排除し、むしろベストプラクティスに引き上げられるという点です。

先ほど、業務ヒアリングにおいては対象の業務・業種における土地勘があり、業務ヒアリングにおける情報の取捨選択が上手く、ToBe検討の後工程の事まで考えられる人と記載しましたが、このようなノウハウをAIエージェントに組み込む事ができれば、属人性を排除し、ベストプラクティスの状態をいつでも再現できます。

社内用語や業界専門用語、社内の部署情報やシステム情報も一覧にした上で、ToBe検討において利用可能なソリューションの情報等も定義しておけば、社内情報やシステムに精通した人間が業務ヒアリングを実施し、ToBe仮説まで検討してくれるという状態になります。

現場の方にとっても、いわゆる既知の情報の説明の手間が省けるため非常に楽になる上、現状把握を元にしたToBe検討の際にも、情報の聞き漏らしなどがなくなるため、非常に効率的に実施できます。

そしてコスト面については言うまでもなく、人件費がゼロになります。AIの構築コストは当然かかりますが、各ヒアリング担当者の人件費に加え、マネジメント業務も大幅に減るので、現状把握の工程における時間とコストを大きく圧縮する事ができます。

このように、これまではそれ自体で付加価値を生まない上に、コストと工数のかかる業務ヒアリングの工程をAIエージェントに実施させる事で、業務改革・DX推進の担当者は現状の深堀りやToBe検討から入れるようになります。この手のプロジェクトを担当した事がある人はわかると思いますが、プロジェクトの開始時に、現状把握のプロセスを圧縮し、現状の1次情報を高品質で揃えられるという事がどれだけプロジェクトマネージャーとして有難いかは想像に難くないでしょう。

AIエージェントへの入力となるのは業務ヒアリングの指示書で、業務ヒアリングの進め方とヒアリング項目、社内用語やシステム情報、よくある質問なども定義していきます。

いわばここが全ての肝になるので、私のこれまでの経験とビジネスアナリストを担当されているクライアントの方々のノウハウを言語化しながら構築を進めています。

出力については、ファイルシステムに対象の業務名でフォルダを自動生成し、ヒアリング結果のサマリと全文の記録に加え、業務フローも生成して格納させる形としています。

今後の拡張としては、音声対応とヒアリング対象者へのリアルタイムでのサマリ提示、ヒアリング結果に基づくToBeの複数案出しまで検討しています。

最終的にはビジネスアナリストとソリューションアーキテクトを兼ね備えたようなAIエージェントに昇華し、現状把握からToBe検討まで一気通貫で実施する、DX推進系のプロジェクトにとってなくてはならない存在にしていきたいと思っています。

「参考（著者執筆）」
・AIエージェントによる業務ヒアリングの自動化

この事例は業務ヒアリングを対象としていますが、ポイントは、専門知識を埋め込んだAIエージェントが必要な情報をヒアリングしながらアウトプットを生成するという点にあります。

私はこれを「対話型生成」と呼んでいますが、例えば、プロジェクト計画書やRFPのドラフト作成、問診や1次カウンセリングでの活用、また市役所等でAIの質問に答えていけば必要な申請書が自動で出来上がるという形のように、様々な応用先が考えられます。

これまで人間が対応していた、多くは専門知識を持っている方が対応する必要があった、ヒアリングとアウトプット生成の領域でもAIエージェントの活用範囲が広がるのではないでしょうか。

最後に

「生成AI・AIエージェント時代のDX」と題して、さまざまな情報が日々錯綜する中で、企業が中長期的に取り組むべき事として、前編では「1.特化型AIエージェントの構築」、後編では「2.API・データ基盤の構築」「3.統合UIの準備」を中心に、特化型AIエージェントの事例についても記載してきました。

汎用モデルはあくまで汎用用途のためコモディティ化の波は避けられず、今後のDX戦略の主戦場となるのは、その企業の独占的な強みを活かす特化型AIエージェントの構築になります。

生成AI・AIエージェント時代における、今後のDX戦略の検討、推進の一助になれば幸いです。

Autofusion Pte. Ltd.

Autofusion Pte. Ltd.では、DX推進における自動化コンサルティングの包括的なサービスを提供しており、構想・企画策定から実開発の領域まで一気通貫で支援をしております。生成AI・AIエージェントの利活用の促進にご興味のある方は、以下のアドレスよりお問い合わせをお願い致します。

Autofusion Pte. Ltd. 渡邊　仁 住所：18 ANN SIANG ROAD 02-01 S069698 電話番号：8314 2627 WEBサイト LinkedIn E-mail：jin.watanabe@autofusion-sg.com

---

シンガポールのビジネス情報や最新記事、セミナー情報をLINE・YouTubeでお届けしています！
ぜひお友だち追加・チャンネル登録をお願い致します。