Zenn
Microsoft (有志)Publicationへの投稿
⛳

Deep Researchを内製化: Deep Research Agentsの紹介

kusano
に公開
Azure
Microsoft
OpenAI
LLM
Deep research
tech

生成 AI が普及するにつれ、「単なるRAGでは深掘りが甘い」「検索結果が“点”でしか返ってこない」という声が急速に高まっています。一般的な RAGでは、単一クエリに基づく検索・要約でレポートを作成する構成が多く、内部資料に対する深掘りや反復的な検証が難しく、複雑な用途では限界が生じがちです。

そこで注目されるのが、Deep Researchです。
Deep ResearchはRAGとは異なり、ユーザーからのクエリを受け取ったAIが様々な角度から情報を収集・分析してより詳細なレポートを生成する高度な機能のことです。従来のRAGでは得られない深い洞察や多角的な視点からの分析を可能にし、意思決定や課題解決のサポートを行います。

しかし、市販SaaSやPaaSで提供される Deep Research 機能は拡張性に乏しく、専門性の高い分野やエンタープライズが活用しようとすると限界に直面する場合があります。そこで、本記事では「オーケストレーターを自社で組み上げる＝手組みアプローチ」 に焦点をあて、Deep Researchを内製化する方法を紹介します。

手組Deep Researchのサンプルコード

本件のサンプルコードをDeep-Research-AgentsとしてGithubに公開しています。実行方法などはGithub上に記載がございますので、そちらを参考になさってください

Deep Research活用アプローチの比較

企業でDeep Researchを活用する場合、1. M365 CopilotなどのSaaSの利用、2. Azure AI Foundry AgentにおけるDeep Research機能などのPaaSの利用、3. オーケストレーターを自分で組む手組、の3つのアプローチがあります。それらを比較すると、1が最も導入が簡単な一方でフレキシビリティが低く、3は導入難易度は高いもののフレキシビリティが高くなり、2はその中間です。詳細は以下の通りです。

アプローチ 概要 Pros Cons
1.SaaSの利用 M365 CopilotやChat GPTを通してDeep Researchを使用 即導入・運用が非常に手軽 細かい制御や既存システムとの連携が困難
2.Azure AI Foundry AgentにおけるDeep Research機能などのPaaSの利用 API経由でDeep Research機能を利用 既存システムへのAPI統合が可能 - システム開発が必要
- 処理のフレキシビリティは限定的
3.オーケストレーターを自分で組む手組 OSSベースでオーケストレーターを手組み　自社要件に合わせて設計・開発・運用 カスタム自在で拡張性大 開発・運用が必要

「3.オーケストレーターを自分で組む手組」は、開発・運用の難易度は高いものの、拡張性に優れており、自社独自の制御アルゴリズムや非公開データを最大限に活用できます。そのため、自社に高度な導入・運用能力があり、特に専門性の高い調査や業務を必要とする業態（製造業・医療・金融など）においては、手組アプローチが優位性を発揮します。結果として、他社が容易に模倣できないDeep Research基盤を構築することは、社内の意思決定の質・速度を持続的に向上させる“競争優位のエンジン”となり得ると考えられます。

手組Deep Researchの設計

今回の手組Deep Researchにおいて採用した設計思想について説明します。

実装戦略

手組でDeep Researchを組む場合、大きく2パターン A. ワークフロー形式とB. 動的ルーティング形式があり、詳細は以下の通りです。OSSで公開されているDeep Researchの実装はA. ワークフロー形式が多いですが、柔軟性と拡張性が求められるDeep Researchタスクの性質上、B. 動的ルーティング形式が適していると考えられます。

実装パターン 概要 Pros Cons
A. ワークフロー形式 事前に処理ワークフローを厳密に定義しておき、手続き的に処理 - 実装が簡単
- 処理が具体的に理解しやすい		 - 柔軟性が低い
- 拡張性が低い
B. 動的ルーティング形式 事前に各処理の内容のみを定義しておき、実行時に生成AIが入力に対してどの処理を行うかは動的にルーティング - 柔軟性が高い
- 拡張性が高い		 - 実装に慣れが必要
- 処理内容が動的に変わるので、理解コストが必要

なお、Azure AI Foundry AgentにおけるDeep Research機能やChatGPTにおけるDeep Research APIもB. 動的ルーティング形式の派生形です。

アーキテクチャ

今回は動的ルーティング形式を採用してDeep Researchを手組で実装しています。
動的ルーティング形式の一類型であるManagerがタスク管理を行う階層型Multi Agent構成としました。具体的には、Semantic KernelのMagentic Orchestrationという機能を活用し、役割分担されたエージェントにマネージャーエージェントが適宜仕事分担し課題解決を行うよう設計しました。

なぜマルチエージェントなのか

マルチエージェントとは、複数の AI エージェントがそれぞれの専門性を生かしつつ協調・対話し、タスクを遂行する仕組みです。人間の組織階層に近い構成をとることで、各エージェントが分担・連携しながら、より複雑な課題に対応できます。

また、マルチエージェント形式で実装すると、エージェント間の議論ログが可視化されるため結果の解釈容易性が向上します。加えて、近年の学術論文(Pre-print)[1]でもマルチエージェント形式の採用による精度向上が報告されており、ソフトウェア設計上も保守性を高めるデザインパターンとして有効であることから、本プロジェクトではこの方式を採用しています。

Magentic Orchestrationとは

Magentic Orchestrationとは、マルチエージェント構成の際に、全体計画やタスク進捗を管理して、必要に応じてAgentに仕事を振る機能です。今回マルチエージェントに動的ルーティング形式を実現する際に採用しています。人間でいうと管理職のようなイメージです。具体的な処理プロセスは以下の画像の通りです。
Magentic Orchestrationのイメージ図
また、Semantic Kernel公式のMagentic Orchestrationの実行サンプルは以下にありますので、興味のあるかたは参考になさってください
https://github.com/microsoft/semantic-kernel/blob/main/python/samples/getting_started_with_agents/multi_agent_orchestration/step5_magentic.py

エージェント構成

Semantic KernelのMagentic Orchestrationを活用し、以下のようなエージェント構成で実装しました。人間の調査チームを想定して、各人員の役割分担を元に以下のようなエージェント構成になっています。
具体的な情報検索はLead Researcher以下のエージェントが行いますが、得られる情報の網羅性を高める為に、Sub-Researcherを3つ設け、各Sub-Researcherの回答生成の際のTemperature(生成AIの挙動のランダム性を制御するパラメーター)を変更し、挙動に振れ幅をもたせるように設計しています。

  • Magentic Orchestration: 全体の計画、タスク進捗管理、仕事の割り振り、最終レポートの作成
    • Lead Researcher: 研究計画を立てて、具体的な研究タスクをSub-Researcherに割り振る。Sub-Researcherが提出した調査結果を元に調査結果のサマリーを提出
      • Sub-Researcher 1～3：検索・調査（挙動に多様性を持たせている）
    • Credibility Critic: 情報ソースの信頼性や、情報ソースのカバレッジを評価し、フィードバックを実施
    • Report Writer: 入手した情報から暫定版のレポートを作成
    • Reflection Critic: 暫定版のレポートの品質を評価し、フィードバックを実施
    • Translator: 必要に応じて翻訳を実施
    • Citation Agent: 調査結果に含まれる引用文献を記録。レポートに適切な引用追加出来るよう調整

全体アーキテクチャ

全体アーキテクチャは以下の通りで、Web検索APIの他に、内部文書の検索にも対応する為、Azure AI Searchを用いた検索にも対応しています。また、表形式の内部データを利用したい場合は、Azure Table Storageにデータを格納し、Azure AI SearchのTable Storage向けIndexerでIndexを作成することで、データ形式に合わせた調査が可能になるので推奨します。

Web検索に関しては、サンプルコードではTavilyを利用していますが、検索サービスのProduct Termsの確認および検索クエリを通した情報漏えいリスクは各自ご自身の責任でご対応ください。

実験及び評価

サンプルコードを実際に動かした際の出力例を以下に記します。実行時間は約7分、消費コストは188円となっています。詳細はAppendix: 出力例の実行情報をご参照ください。

実行例

入力クエリ: 日本におけるAzure AI/OpenAI を活用したマルチエージェントの事例を5社分まとめて 詳細なレポート形式で日本語で回答して　情報ソースは企業公式サイトの情報のみを用いてください

出力結果

Executive Summary

本調査は、日本国内で「Azure AI/OpenAI Service」を活用し、複数AIエージェント（マルチエージェント）を連携させた公式事例を公開している5社（NEC、パナソニック コネクト、富士通、KDDI、パナソニック ホールディングス）を対象に、最新動向・構成・成果を体系的に整理したものである。主要知 見は下記のとおりである。

  • 5社すべてがAzure OpenAI Serviceを安全に企業利用する前提で、目的別エージェントを複数稼働させている。
  • 代表的な役割分担は「検索系エージェント」「専門業務エージェント」「ワークフロー／オーケストレーションエージェント」であり、Retrieval Augmented Generation（RAG）やSaaS連携を組み合わせる構成が主流。
  • 導入効果は検索・要約時間20〜40%短縮、攻撃検知率15%向上、作業時間最大30%削減など、定量的に示されている。
  • 今後はメタ認知型オーケストレーションや海外拠点展開など、スケールアウト戦略が計画されている。

なお、パナソニック コネクト株式会社とパナソニック ホールディングス株式会社は登記上別法人であり、公式情報も個別に発信しているため、本レポートでは独立した「2社」として計上し、合計5社とした。

Detailed Findings

1. NEC

  • 導入背景
    部門やタスクごとに異なる回答粒度への対応が課題となり、複数エージェント協調の必要性が高まった。
  • マルチエージェント構成
    「NEC AI Agent for NGS」はSearch Agent、Office Agent、業務 Agent、個別 Agentが自律連携し、Azure OpenAI Serviceと社内データを組み合わせるハイブリッド型[1]。
  • 成果
    ドキュメント検索時間を大幅に短縮し、利用部門が増加。
  • 展望
    オーケストレーション層を追加し、意思決定支援・開発支援へ拡大[1]。

2. パナソニック コネクト

  • 導入背景
    製造・物流・小売など多様なドメインで共通的に使える生成AI基盤を整備する必要があった。
  • マルチエージェント構成
    LangChain・LangGraph・ChainlitとAzure OpenAIを組み合わせ、ナビゲーター型・ワークフロー型・汎用型の3種エージェントを複数同時展開する基盤 を構築[2][3]。
  • 成果
    生産・物流・営業で作業時間を最大30%削減[3]。
  • 展望
    2025年度内に100案件以上へ拡大し、コード生成・デザイン自動化へも適用[2]。

3. 富士通

  • 導入背景
    サイバー攻撃の複雑化に伴い、脆弱性検知・対策を自動化する必要があった。
  • マルチエージェント構成
    「マルチAIエージェントセキュリティ技術」は攻撃解析・防御策生成・復旧計画立案を分担する複数エージェントとAzure OpenAI Serviceを組み合わせる[4]。
  • 成果
    未知攻撃検出率15%向上、対策案提示時間を半分以下に短縮[4]。
  • 展望
    2026年までにグローバルSOCへ展開し、自律防御を目指す。

4. KDDI

  • 導入背景
    法人顧客向けに複数AIサービスを統合した生成AI基盤を提供する戦略を策定。
  • マルチエージェント構成
    4種類のAIエージェントを組み合わせ、マルチクラウドゲートウェイ経由で既存システムと連携[5][6]。
  • 成果
    コールセンター要約、EC商品説明自動生成、マニュアル作成の3領域で作業時間を40%圧縮[6]。
  • 展望
    通信ネットワーク運用領域で障害分析・トラフィック最適化エージェントの連携を計画。

5. パナソニック ホールディングス

  • 導入背景
    グループ横断で生成AIを安全に活用し、広範な部門で業務効率を高めるために社内共通基盤を立ち上げた。
  • マルチエージェント構成
    「PX-GPT」はAzure OpenAI Serviceを中核に部門別エージェントをイントラネットで提供。「各部門横断で使える複数AI基盤」と明記[7]。
  • 成果
    リリース4か月で28,000ユーザー利用、検索・要約時間を平均20%削減[7]。
  • 展望
    2025年度に海外拠点へ展開し、知識共有プラットフォームを統合予定。

Conclusions and Recommendations

日本企業は、Azure OpenAI Serviceのセキュリティとスケーラビリティを活用し、役割分担型AIエージェントを複数連携させることで業務効率化・品質向上を実現している。共通ポイントは以下である。

  1. RAGを活用した検索エージェントが情報取得の起点となり、専門エージェントが深掘りする構成が主流。
  2. 成果指標は時間削減率や検出率など定量的に示され、導入効果が検証されている。
  3. 将来展望として、オーケストレーション層の強化と海外展開が挙げられる。

企業への推奨事項は次のとおり。

  • オーケストレーションの自動化: タスクの動的配分とエージェントのメタ認知機能を強化し、複雑タスクにも対応できる体制を構築する。
  • ガバナンス強化: 生成AI利用指針・監査ログを整備し、機密情報やHallucinationリスクを低減する。
  • PoCから本番移行の迅速化: 小規模検証で得た指標とROIをもとに、ビジネスプロセスをエージェントフレンドリーに再設計し、本番運用へ早期移行する。

Source Documentation

# 種別 タイトル／記事名 URL または文書ID 公開日・版 主な引用箇所抜粋
1 Web Work DX 2025 Session 4 資料（NEC） https://jpn.nec.com/digital-wp/workdx2025/document/pdf/workdx2025_session4.pdf 2025-01 「Search Agent・Office Agent・業務 Agent・個別 Agent が自律連携」
2 Web Large Language Models 技術紹介（Panasonic Connect） https://group.connect.panasonic.com/psnrd/technology/large-language-models.html 公開日記載なし – 最終アクセス 2025-07-14 「LangChain、LangGraph、Chainlit、Azure OpenAI と連携し、AIエージェントを柔軟にカスタマイズ」
3 Web パナソニック コネクト、LLMエージェント活用を加速 https://news.panasonic.com/jp/press/jn250707-2 2025-07-07 「ナビゲータ ー型・ワークフロー型・汎用型AIエージェントを複数展開」
4 Web 世界初 マルチAIエージェントセキュリティ技術を開発（富士通） https://pr.fujitsu.com/jp/news/2024/12/12.html 2024-12-12 「マルチAIエージェントセキュリティ技術」
5 Web Azure OpenAI Service（法人向け生成AI）サービス紹介（KDDI） https://biz.kddi.com/service/ms-azure/open-ai/ 公開日記載なし – 最終アクセス 2025-07-14 「複数のAIエージェントを組み合わせ…」
6 Web KDDI、マルチクラウド×生成AIで法人DXを加速 https://newsroom.kddi.com/news/detail/kddi_pr-958.html 2023-09-05 「4モデルを 組み合わせることで…」
7 Web 社内生成AI基盤「PX-GPT」を公開（Panasonic） https://news.panasonic.com/jp/press/jn230414-1 2023-04-14 「各部門横断で使える複数AI基盤」

参考文献・引用元

[1] Work DX 2025 Session 4 資料, NEC, https://jpn.nec.com/digital-wp/workdx2025/document/pdf/workdx2025_session4.pdf
[2] Large Language Models 技術紹介, Panasonic Connect, https://group.connect.panasonic.com/psnrd/technology/large-language-models.html
[3] パナソニック コネクト、LLMエージェント活用を加速, Panasonic Newsroom, https://news.panasonic.com/jp/press/jn250707-2
[4] 世界初 マルチAIエージェントセキュリティ技術を開発, 富士通プレスリリース, https://pr.fujitsu.com/jp/news/2024/12/12.html
[5] Azure OpenAI Service（法人向け生成AI）サービス紹介, KDDI, https://biz.kddi.com/service/ms-azure/open-ai/
[6] KDDI、マルチクラウド×生成AIで法人DXを加速, KDDI Newsroom, https://newsroom.kddi.com/news/detail/kddi_pr-958.html
[7] 社内生成AI基盤「PX-GPT」を公開, Panasonic Newsroom, https://news.panasonic.com/jp/press/jn230414-1

結論

以上より、Deep Researchの手組み実装に関して、以下を示しました。

  • 深掘りと多角的検証を自在に実装: 手組み Deep Research により、従来型 RAG では困難だった詳細分析・反復検証を、組織固有の要件に合わせて柔軟に設計できます。
  • 競争優位を創出: 手組を行う場合開発コスト等の初期投資は必要ですが、自社の要件に合わせたDeep Researchを構築可能なので、先進企業にとって競争優位性を創出する機会となります。
  • マルチエージェント×動的ルーティングで高い専門性・拡張性・透明性: マルチエージェントと動的ルーティングを組み合わせることで、高い精度を実現しつつ、将来的な機能追加やデータソース拡張にも容易に対応できます。
  • 公開サンプルコードでスムーズな立ち上げが可能: GitHub に公開したコードをベースに PoC を開始すれば、環境構築から評価までを短期間で行えます。

本記事を参考に、是非Deep Researchの手組を実践してみてください！

Appendix: 出力例の実行情報

所要時間: 約7分
LLMの合計所要コスト: 188円

  • o3: 48.8円
  • GPT4.1: 139.2円

消費トークン量:

  • o3:
    • 入力Token(Cache無し): 93.2K
    • 入力Token(Cached): 46.4K
    • 出力Token: 16.0K
  • GPT4.1:
    • 入力Token(Cache無し): 358.1K
    • 入力Token(Cached): 302.7K
    • 出力Token: 12.1K
脚注

  1. Liu, Bang, et al. "Advances and challenges in foundation agents: From brain-inspired intelligence to evolutionary, collaborative, and safe systems." arXiv preprint arXiv:2504.01990 (2025). ↩︎

Microsoft (有志)
Microsoft (有志)Publication

Microsoft Azureをはじめとする最新技術情報をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。

Discussion