AIエージェントは「検索する」から「業務を動かす」へ

2026年7月21日 2026年8月3日

fukayayuji

はじめに

AITCセンター長の深谷です。

生成AIやAIエージェントの活用が進むにつれて、企業がAIに期待する役割は大きく変わり始めています。

これまでの生成AIは、質問を入力すると回答を返す、文章を要約する、資料のドラフトを作るといった、「人から与えられた指示に応える」使い方が中心でした。

一方、現在注目されているAIエージェントは、単に質問に回答するだけではありません。

人から目的を受け取ると、その目的を達成するために必要な作業を分解し、情報を探し、ツールやシステムを使い、結果を確認しながら次の行動を決めていきます。つまり、AIの役割が「情報を回答すること」から、「業務を前に進めること」へと広がり始めています。

しかし、AIエージェントに高度な業務支援をしてもらうためには、AIモデルの性能を高めるだけでは十分ではありません。

AIが社内の知識やデータを正しく理解できること。
必要な情報がどこにあるのかを発見できること。
業務システムへ安全にアクセスできること。
必要に応じて情報の作成や更新まで実行できること。

このような、AIが知識とシステムを横断して行動できる仕組みが必要になります。

電通総研が提供する生成AIプラットフォーム「Know Narrator」は、2026年7月、この方向に向けて大きく進化しました。

これまで複数の業務ナレッジを横断して情報を集めていた「マルチ業務ナレッジエージェント」が、MCPを通じてデータベースや業務システムとも接続し、情報検索だけでなく、作成や更新を含む処理を実行できる「マルチAIエージェント」へと進化したのです。

今回は、この進化が企業のAIエージェント活用にとって、なぜ重要なのかを考えてみたいと思います。

マルチ業務ナレッジエージェントは、複数の業務ナレッジを横断できる

Know Narratorは、企業内に分散する知識を集約し、組織全体で安全に活用するための「組織のAI基盤」をコンセプトとした生成AIプラットフォームです。

複数のLLMを利用できる「Chat」、社内ナレッジを検索・活用する「Search」、生成AIの利用状況や効果を可視化する「Insight」、特定の業務をAIエージェントが実行する「AgentSourcing」などを通じて、企業における生成AI活用を支援しています。

この中で、AIエージェントによる業務支援を担うのがKnow Narrator AgentSourcingです。

2026年6月時点の「マルチ業務ナレッジエージェント」では、AIエージェントが複数の業務ナレッジを自律的に選択し、必要な情報を集め、統合した回答を生成できました。

たとえば、次のような情報を横断的に扱うことができます。

部門ごとに管理されている業務ナレッジ
SharePointやBoxに保存されている社内文書
インターネット上の公開情報
文書に含まれる文章、画像、表、グラフ
Code Interpreterを利用した集計や情報処理

一般的なRAGでは、利用者が検索対象を選び、検索結果を確認しながら情報を組み合わせる必要があります。

これに対して、マルチ業務ナレッジエージェントでは、利用者が「どのナレッジを検索するか」を細かく指定しなくても、AIエージェントが質問や目的に応じて必要な業務ナレッジを選択します。

複数の知識を持ったAIエージェント同士に異なる観点から検討させ、合議制で情報を統合することも可能です。

これにより、部門やシステムごとに分散していた知識を横断し、組織の集合知として利用しやすくなりました。

しかし、この段階でAIエージェントが主に扱っていたのは、「参照できるナレッジ」です。

AIエージェントは、複数の情報を探し、読み、整理し、回答を生成できました。一方、業務システムに保存されているデータを直接操作し、業務そのものを進めるためには、個別のシステム連携が必要でした。

言い換えると、AIエージェントは高度な「情報処理」を行うことはできても、実際の業務システムに対する「行動」には一定の壁があったのです。

マルチ業務ナレッジエージェントは、MCPと接続してマルチAIエージェントへ進化

2026年7月、Know Narrator AgentSourcingのマルチ業務ナレッジエージェントに接続する、MCPクライアントオプションをリリースしました。

MCPとは「Model Context Protocol」の略称です。

AIアプリケーションと、外部のデータ、ツール、業務システムを共通の方法で接続するためのプロトコルです。MCPサーバー側が利用可能なデータやツールを提供し、MCPクライアントを持つAIアプリケーションが、それらを発見して利用します。

Know NarratorがMCPクライアントを内包したことで、これまで扱っていた業務ナレッジやインターネット情報に加えて、MCPサーバーを介して、さまざまなデータベースや業務システムへ接続できるようになりました。

接続先としては、たとえば次のようなものが考えられます。

グラフデータベース
SnowflakeやDatabricks、Microsoft Fabricなどのデータ基盤
顧客管理、案件管理、問い合わせ管理などの業務システム
社内で利用している各種データベース
APIを備えた社内外のサービス

今回の進化で重要なのは、単に検索できる情報源が増えたことではありません。

MCPを通じて、データやシステムに対するCreate、Read、Update、Delete、いわゆるCRUD操作を業務プロセスに組み込めるようになったことです。

つまり、情報を読み取るだけでなく、権限や設定に応じて、新しい情報を作成する、既存の情報を更新する、処理結果をシステムへ書き戻す、といった動作まで実行できるようになります。

「検索できるAI」と「業務を実行できるAI」の違い

従来のRAGやナレッジ検索型のAIは、利用者が必要とする情報を探し、回答として提示することに強みがあります。

一方、業務を支援するAIエージェントには、回答の先にある処理まで求められます。

両者の違いを整理すると、次のようになります。

観点	ナレッジ検索型AI	業務実行型AIエージェント
主な目的	質問に回答する	与えられた目的を達成する
利用する情報	文書、FAQ、ナレッジ	文書、ナレッジ、データベース、業務システム
主な処理	検索、要約、回答生成	計画、検索、判断、ツール実行、結果確認
データ操作	主に参照	参照、作成、更新など
出力	回答文、要約、ドラフト	回答、成果物、システム更新、次工程の実行
人の役割	回答を読んで次の操作を行う	重要な判断や承認を行う

たとえば、従来のAIに「この顧客に適した提案内容を考えてください」と依頼した場合、AIは過去の提案書や製品資料を検索し、提案内容のドラフトを作成します。

しかし、その後は人が顧客管理システムを開き、顧客情報を確認し、案件情報を更新し、関係者へタスクを割り当て、提案書を所定の場所へ保存する必要があります。

業務実行型のAIエージェントでは、この一連の処理を一つの業務フローとして扱います。

AIエージェントは必要な情報を探すだけではなく、許可されたツールを選択し、業務システムを操作し、処理結果を確認しながら次の行動を決めます。

この違いは非常に大きいと考えています。

生成AIが便利な「相談相手」である段階から、業務プロセスの一部を担う「実行主体」へと変わるためです。

Agenticに動くとは、目的から次の行動を決めること

AIエージェントを説明するとき、「Agentic（エージェンティック）」という言葉が使われます。

Agenticとは、AIが単発の指示に回答するだけではなく、与えられた目的に向けて、自ら次の行動を選択しながら処理を進める性質を表します。

高度な業務支援を行うAIエージェントは、一般的に次のようなサイクルで動きます。

目的を理解する
利用者が実現したいことや、業務上の制約を確認します。
作業を分解する
目的を達成するために、どのような作業が必要かを整理します。
情報を収集して判断する
社内ナレッジ、外部情報、データベース、業務システムから必要な情報を取得します。
ツールを使って処理する
データを集計する、文書を作成する、システムへ情報を書き込むなどの処理を行います。
結果を確認して次の行動を決める
実行結果が目的を満たしているかを確認し、必要であれば処理を修正します。

ここで重要なのは、「情報検索」はこのサイクルの一部分にすぎないという点です。

AIエージェントが実際の業務を完了するためには、検索した後に、判断し、操作し、結果を確認する必要があります。

Know NarratorがMCPを通じてさまざまなシステムと接続することは、このAgenticな業務処理を実現するための重要な仕組みになります。

提案書作成業務は、業務を実行出来るAIエージェントによってどのように変わるのか

具体的な例として、「過去の提案書を参考に、新しい顧客向けの提案書を作成する」という業務を考えてみます。

従来の生成AIでは、利用者が顧客情報、提案条件、過去の提案書、製品情報などを集め、プロンプトに入力する必要がありました。

マルチ業務ナレッジエージェントでは、複数の業務ナレッジを横断し、過去の類似提案や製品情報、導入事例などを自律的に検索できます。

さらに、MCPを通じて顧客管理システムや案件管理システムと連携すると、次のような業務フローが考えられます。

顧客管理システムから、顧客の業種、企業規模、過去の商談履歴を取得する
案件管理システムから、今回の提案条件やスケジュールを確認する
社内ナレッジから、類似顧客への過去提案書を検索する
製品情報、導入事例、競合比較、よくある質問を収集する
顧客に適した提案ストーリーを組み立てる
数値や製品情報に矛盾がないか確認する
提案書のドラフトを作成する
人による確認や承認を依頼する
承認後、所定の場所へ成果物を保存する
案件管理システムへ作成状況や次のアクションを記録する

これまでは人が複数のシステムを開き、情報をコピーし、別のシステムへ転記していた処理です。

AIエージェントがナレッジとシステムの両方を扱えるようになることで、一連の作業を一つの業務として実行できる可能性があります。

ここで得られる効果は、単なる提案書作成時間の短縮だけではありません。

過去の提案ノウハウを再利用しやすくなること
顧客情報や製品情報の転記ミスを減らせること
提案に使用した根拠を追跡しやすくなること
案件管理システムへの記録を含め、後工程まで抜けなく処理できること

こうした、業務プロセス全体の品質向上につながります。

AIエージェント時代には「AI Readyなデータ」の意味も変わる

AIエージェントをAgenticに動かすうえで重要なのは、AIそのものの性能だけではありません。

AIがデータを理解し、検索し、判断に利用し、必要に応じて操作できる状態をつくることが重要です。

以前のコラムでは、AI時代に必要なのは「ナレッジの置き場所」だけではなく、「AIが扱える形」で知識を整備することだと説明しました。

文書にタイトル、見出し、メタデータ、更新日、出典、関連情報などを付与し、AIが知識の意味や関係性を判断できるようにする考え方です。

マルチAIエージェントの時代には、このAI Readyという考え方を、文書だけでなく、データベースや業務システムまで広げる必要があります。

重要になるのは、次の四つの観点です。

1. AIが必要な情報を発見できること

どのシステムに、どのような情報が保存されているのかが分からなければ、AIエージェントは適切なデータを選択できません。

データやツールには、名称だけでなく、目的、対象業務、利用条件、更新頻度などの説明が必要です。

2. AIが情報の意味を理解できること

AIがデータベースへ接続できても、テーブル名や項目名の意味が分からなければ、正しく利用できません。

たとえば、「売上」が受注金額なのか、請求金額なのか、入金済み金額なのかによって、業務上の意味は異なります。

指標の定義、項目の意味、除外条件、データ同士の関係性などを、AIが参照できる形で管理する必要があります。

3. AIが安全に操作できること

情報を読む権限と、作成・更新する権限は分けて考える必要があります。

どの利用者が、どのAIエージェントを通じて、どのデータやシステムを操作できるのかを制御しなければなりません。

4. AIの処理結果を確認できること

AIエージェントが、どの情報を参照し、どのような判断を行い、どのツールを使い、何を更新したのかを追跡できることも重要です。

AI Readyな状態とは、単にAIがデータを読める状態ではありません。

AIがデータの意味を理解し、適切な権限の範囲で利用し、その処理結果を人が確認できる状態まで含めて考える必要があります。

AIエージェントの精度は、接続するデータの品質で変わる

高性能なAIモデルを利用すれば、文章の生成能力や推論能力は高まります。

しかし、AIエージェントが業務で正しい判断を行えるかどうかは、モデル性能だけでは決まりません。

たとえば、次のような状態では、AIエージェントがシステムへ接続できても、期待する結果は得られません。

古い製品情報と新しい製品情報を区別できない
指標の定義が部門によって異なる
データの更新日時が分からない
システム間でIDや名称が統一されていない
項目の意味や入力ルールが文書化されていない
どのデータが正式な情報なのか判断できない
データを更新するための条件が明確になっていない

人間であれば、経験や周辺知識を使って意味を補完できます。

しかし、AIエージェントが自律的に処理を進める場合、情報の意味、構造、関係性、利用条件が明示されている必要があります。

AIエージェントに接続先を増やせば、自動的に業務支援が高度化するわけではありません。

接続するデータやシステムをAIが正しく利用できるように整備することが、AIエージェント活用の前提になります。

つまり、これからの企業には二つの基盤が必要です。

一つは、AIが参照できる形で業務知識を整える「知識基盤」です。

もう一つは、AIが安全に業務システムを利用できる「実行基盤」です。

Know Narratorの今回の進化は、この二つの基盤をつなぐものになります。

自律的に動くことは、AIへ長時間任せることではない

AIエージェントがシステムの作成・更新処理を実行するようになると、ガバナンスの重要性も高まります。

ここで注意したいのは、「Agenticに動くこと」と「AIへすべてを任せること」は同じではないという点です。

企業でAIエージェントを利用する場合には、処理の重要度や影響範囲に応じて、人による承認を組み込む必要があります。

ツールを実行する際には、利用者がツールの利用を確認し、必要に応じて拒否できるHuman-in-the-loopが重要です。

たとえば、次のような設計をおすすめします。

情報の検索や集計は自動実行する
文書のドラフト作成までは自動化する
社外送信の前には人が内容を確認する
データ更新の前に変更内容を表示する
金額や契約に関わる処理には承認を必須とする
大量更新や削除処理には実行制限を設ける
実行した操作をログとして記録する

重要なのは、すべての処理を一律に自動化することではありません。

業務のリスクに応じて、「AIに任せる範囲」と「人が判断する範囲」を設計することです。

適切な権限管理、承認フロー、実行ログ、処理結果の検証を組み合わせることで、AIエージェントの自律性と企業ガバナンスを両立できます。

企業はどこからマルチAIエージェント活用を始めるべきか？

マルチAIエージェントは、さまざまな業務へ適用できる可能性があります。

しかし、最初から複数のシステムを接続し、業務全体を完全自動化しようとすると、設計が複雑になります。

まずは、効果を確認しやすく、処理範囲を限定しやすい業務から始めることが現実的です。

進め方としては、次の三段階が考えられます。

第1段階：ナレッジを横断して回答や成果物を作る

まずは複数の社内ナレッジを横断し、調査、分析、提案書作成、問い合わせ回答などを支援します。

この段階では、AIが参照する情報の品質や、回答精度を確認します。

第2段階：業務システムから必要なデータを取得する

次に、MCPやAPIを通じてデータベースや業務システムと接続し、AIエージェントが最新のデータを取得できるようにします。

文書ナレッジと構造化データを組み合わせることで、より業務の状況に即した判断が可能になります。

第3段階：限定された範囲で作成・更新を実行する

最後に、人の確認や承認を組み込みながら、システムへの書き込みや更新を実行します。

まずは下書きの登録、タスクの作成、ステータス更新など、影響範囲を管理しやすい処理から始めます。

このように、参照、取得、実行と段階的に適用範囲を広げることで、安全性と業務効果を確認しながらAIエージェントを育てることができます。

AI活用は「回答の生成」から「業務成果の創出」へ

これまで生成AIの評価では、回答が自然か、要約が正確か、文章を早く作れるかといった観点が重視されてきました。

しかし、AIエージェントが業務プロセスに組み込まれると、評価すべき対象も変わります。

重要になるのは、AIが何文字の文章を生成したかではありません。

業務がどこまで完了したか
人による確認や転記がどれだけ減ったか
処理時間がどれだけ短縮されたか
抜け漏れや入力ミスがどれだけ減ったか
過去の知識がどれだけ再利用されたか

このような、実際の業務成果でAIエージェントを評価する必要があります。

Know NarratorがマルチAIエージェントへ進化したことは、生成AIの価値を「回答の品質」だけでなく、「業務プロセス全体の成果」で捉えるための重要な一歩だと考えています。

Know Narratorが目指すのは、組織の知識と業務をつなぐAI基盤

AIエージェントが本当に企業の業務で役立つためには、三つの要素が必要です。

一つ目は、企業内に蓄積された業務知識です。

二つ目は、業務の最新状況を持つデータやシステムです。

三つ目は、それらを安全に利用し、目的に応じて処理を実行するAIエージェントです。

これまで、社内文書は文書管理システムに、顧客情報はCRMに、案件情報は案件管理システムに、分析データはDWHに保存され、それぞれ別々に利用されてきました。

Know NarratorのマルチAIエージェントは、これらを一つの業務文脈の中で扱い、複数の知識とシステムを組み合わせながら業務を支援します。

AIに質問して終わるのではなく、必要な情報を探し、判断し、成果物を作り、必要な処理を実行し、結果を確認する。

Know Narratorは、「AIを利用するための基盤」から、「AIが組織の知識を使って業務を動かすための基盤」へと進化しています。

AIエージェントの能力を最大限に引き出すためには、AIモデルの性能を高めるだけではなく、AIが必要な情報を正確に発見し、理解し、判断に利用できるように、データを構造化・標準化・意味付けしておくことが重要です。

そして今後は、そのデータを読むだけでなく、安全に操作できる仕組みも求められます。

「どのAIを使うか」と同じくらい、「AIにどのような知識やデータを渡すか」。

さらに、「AIにどのシステムを、どの権限で操作させるか」。

このような設計が、企業におけるAIエージェント活用の成否を左右します。

まとめ

AIエージェントを高度な業務支援へ活用するためには、AIエージェントを導入するだけでは十分ではありません。

どの業務を対象にするのか
どのナレッジやデータを利用するのか
既存システムとどのように接続するのか
どこまでAIへ任せ、どこで人が承認するのか
AIが利用しやすいように業務知識やデータをどのように整備するのか

これらを、業務、データ、システム、セキュリティ、ガバナンスの観点から設計する必要があります。

電通総研では、Know Narratorを活用したナレッジ基盤の構築から、AI Readyなデータ整備、MCPを通じたシステム連携、AIエージェントの業務適用まで、お客様とともに検討・実装を進めています。

生成AIに質問する段階から、AIエージェントが組織の業務を前に進める段階に来ています。

AIエージェントによる組織の業務変革を、電通総研と一緒に進めていきませんか。

筆者
AITC センター長
深谷勇次

コラムカテゴリー: AIエージェント、AI化戦略、データ準備・分析、生成AI