マルチエージェントオーケストレーションとドキュメント間参照によるAIを活用したスプレッドシートおよびドキュメント分析
ある企業データチームは、Excel、CSV、Google Sheets、PDF、Word docsといった大量のスプレッドシートやドキュメントを自然言語で分析、クエリ、編集する必要がありました。これには、複数のファイル間でデータを相互参照し、手動でのデータラングリングなしに多段階の分析ワークフローを実行できる機能が求められました。
プロジェクトを相談する
課題
ビジネスドキュメントを大規模に扱うことは、以下の課題に直面していました。
- サイロ化されたデータ — 重要な情報が数十ものスプレッドシート、PDF、Wordドキュメントに散在しており、それらを横断してクエリする方法がありませんでした
- 手動による相互参照 — ベンダーの価格表（Excel）と契約条件（PDF）と請求履歴（CSV）を比較するには、何時間もの手動検索が必要でした
- 数式の限界 — 複雑な分析の質問には、スプレッドシートの数式だけでは答えられませんでした
- コンテキストウィンドウの制限 — 大規模なスプレッドシート（50,000行以上）はLLMのコンテキストウィンドウを超過し、単純なアプローチでは対応できませんでした
- 編集機能の欠如 — 既存のAIツールはドキュメントを分析できましたが、変更をソースファイルに書き戻すことはできませんでした
- 多段階推論 — ドキュメントを横断した順次分析を必要とする質問には、オーケストレーションされた多段階ワークフローが必要でした
私たちのソリューション
当社は、大規模ドキュメント向けのベクターデータベースによる検索、さまざまなドキュメントタイプに対応する専門エージェント、ドキュメント間推論のためのオーケストレーター、そしてスプレッドシート編集のための書き戻し機能を備えたマルチエージェントAIドキュメントインテリジェンスプラットフォームを構築しました。
アーキテクチャ
- Orchestrator: 専門エージェント間で多段階ワークフローを調整するAIオーケストレーターエージェント
- Spreadsheet Agent: Excel/CSV/Google Sheetsの分析、数式生成、セル編集を処理します
- Document Agent: PDF/Wordドキュメントの読み取り、抽出、要約を処理します
- Cross-Reference Agent: ドキュメントタイプ間で結合、比較、照合を実行します
- Vector Database: ドキュメントチャンクとスプレッドシート行のセマンティックインデックス作成のためのMilvus
- LLM Layer: 関数呼び出しを伴うマルチモデルアプローチ
- Backend: ドキュメント処理とエージェントオーケストレーションのためのPython/FastAPI
- Frontend: ファイルアップロード、チャットインターフェース、ライブスプレッドシートプレビューを備えたReactダッシュボード
- Storage: オリジナルファイルのためのS3、メタデータとジョブ追跡のためのPostgreSQL
マルチエージェントアーキテクチャ
エージェントの役割
1. Orchestrator Agent（オーケストレーターエージェント）ユーザーのクエリを受け取り、それをサブタスクに分解し、専門エージェントに委任する中央コーディネーターです。ユーザーの意図を分析し、実行計画を作成し、エージェント間のデータフローを管理し、結果を集約し、エラー回復を処理します。
2. Spreadsheet Agent（スプレッドシートエージェント）スキーマ理解、自然言語からクエリへの翻訳、集計とフィルタリング、数式生成、セル編集と列への自動入力、チャート提案、データ検証/異常検知などの表形式データ操作に特化しています。
3. Document Agent（ドキュメントエージェント）OCRとレイアウト認識テキスト抽出、セクション識別、契約書からのキーバリュー抽出、要約、セマンティック条項検索、PDF/Word docsからのテーブル抽出などの非構造化および半構造化ドキュメントに特化しています。
4. Cross-Reference Agent（相互参照エージェント）ドキュメント間のエンティティマッチング、データ照合と不一致特定、タイムライン分析、競合データに対する依存関係解決、ドキュメントタイプを横断するSQLライクな結合操作などの複数ドキュメント推論に特化しています。
ベクターデータベースレイヤー
ドキュメントにVector DBを使用する理由
大規模なドキュメントやスプレッドシートは、単一のLLMコンテキストウィンドウには収まりません。ベクターデータベースは、数百万行およびドキュメントチャンクにわたるセマンティック検索、クエリごとに必要な部分のみの取得、埋め込み類似性によるドキュメント間エンティティリンク、そしてクエリごとに再処理する必要のない永続的なインデックス作成を可能にします。
インデックス戦略
スプレッドシートのインデックス作成：各行は、主要な列の値を連結することで自然言語表現に変換され、その後、埋め込まれて、書き戻し操作のために元のファイル、シート、行インデックスへの参照と共に保存されます。
ドキュメントのインデックス作成：ドキュメントはレイアウトを認識して抽出され、重複するセマンティックセグメントにチャンク化され、埋め込まれ、ソースファイル、セクション、ページ番号への参照と共に保存されます。
ドキュメント間エンティティインデックス：別のインデックスが、ドキュメントを横断してエンティティ（ベンダー、製品、人物、請求書番号）をリンクし、これにより、ソースファイルに関係なく、エンティティのすべての言及を素早く見つけるための相互参照クエリが可能になります。
検索パイプライン
ユーザーがドキュメント横断的な質問をした際、オーケストレーターはどのドキュメントとエージェントが必要かを特定し、すべてのソースから関連データを見つけるためにベクター検索を実行し、処理のために専門エージェントに委任し、結果を一貫した応答に集約します。
オーケストレーションエンジン
クエリ分解
オーケストレーターは、複雑なクエリを多段階の実行計画に分解します。例えば、「納期遅延のあるベンダーを見つけ、契約のペナルティ条項を確認し、請求可能なペナルティを計算する」といった質問は、Spreadsheet Agentを介して配送データをクエリする、Document Agentを介して契約を検索する、そしてCross-Reference Agentを介して結果を結合するという一連のステップに分解されます。
エージェント間の通信
- エージェントは、型付きペイロードを持つ構造化メッセージを介して通信します
- オーケストレーターは、中間結果を含む実行コンテキストを維持します
- 失敗したステップは、再試行またはフォールバック戦略をトリガーします
- 一部のステップが完了し、他が失敗した場合でも、部分的な結果が返されます
スプレッドシートの編集と書き戻し
編集機能
このプラットフォームは、セルの更新、列の自動入力、行の挿入、条件付き書式設定、新しいシートの作成、数式の挿入をサポートします。これらはすべてAIエージェントによって提案され、ユーザーの承認を得て適用されます。
書き戻しパイプライン
- エージェントが編集操作（どのセル、どの値）を決定します
- ユーザーに差分ハイライト（旧値 vs. 新値）付きの編集プレビューが表示されます
- ユーザーは提案された変更を承認または修正します
- バックエンドは、フォーマットに応じた適切なライブラリを使用してファイルに変更を適用します
- 変更されたファイルは、編集監査証跡付きの新バージョンとして保存されます
- 変更された行のベクターインデックスが更新されます
バージョン管理
- すべての編集は新しいファイルバージョンを作成します（元のファイルは保存されます）
- 差分ログは、何が、いつ、なぜ変更されたかを正確に示します
- ワンクリックで以前の任意のバージョンにロールバックできます
- 編集帰属：各変更をどのエージェントまたはユーザーが行ったか
新規ドキュメント処理パイプライン
ファイルアップロードフロー
- ユーザーがファイルをアップロードします（ドラッグ＆ドロップまたはAPI）
- ファイルタイプが検出され、適切なプロセッサーにルーティングされます
- スプレッドシート: パースされ、スキーマが推論され、行が埋め込まれ、インデックス化されます
- PDF: OCR（スキャン済みの場合）→ レイアウト抽出 → チャンク化 → 埋め込み → インデックス化
- Word Docs: テキスト抽出 → セクション解析 → チャンク化 → 埋め込み → インデックス化
- エンティティ抽出: NERがすべてのドキュメントから人物、組織、日付、金額を識別します
- ドキュメント間リンク: 新しい言及でエンティティインデックスが更新されます
- ファイルメタデータはPostgreSQLに、埋め込みはVector DBに、オリジナルはS3に保存されます
サポートされるフォーマット
このプラットフォームは、Excel, CSV, Google Sheets（完全な書き戻し機能付き）、ネイティブおよびスキャンされたPDF（読み取り専用）、Word docsとGoogle Docs（制限付き書き戻し機能）をサポートします。
主要機能
- マルチエージェントアーキテクチャ — スプレッドシート、ドキュメント、相互参照のための専門エージェント
- AI Orchestrator — 複雑なクエリを多段階の実行計画に分解します
- ドキュメント間参照 — ファイルタイプを横断するエンティティリンクとデータ照合
- ベクター駆動型検索 — LLMのコンテキスト制限を超えるデータセットをセマンティック検索で処理します
- スプレッドシートへの書き戻し — AIがセルの編集、列の自動入力、数式の挿入をユーザーの承認を得て行います
- 大規模データセット対応 — 50,000行以上のスプレッドシートがインデックス化され、ベクター検索を介してクエリ可能
- バージョン管理 — すべての編集が差分ログとロールバック機能付きでバージョン管理されます
- 自然言語クエリ — 複雑な分析の質問を平易な英語で尋ねられます
- マルチフォーマット対応 — Excel, CSV, Google Sheets, PDF, Word, Google Docs
- 編集プレビュー — 変更が適用される前に差分ハイライト表示付きプレビュー
成果
技術スタック
caseStudyDetail.more ケーススタディ
その他の技術実装事例をご覧ください
ハイブリッド検索とマルチフォーマット対応のローカルファースト ドキュメント RAG システム
開発者ツールを構築するチームは、完全にローカルでプライバシーを保護するドキュメントインテリジェンスシステムを必要としていました。このシステムは、複数のファイル形式を取り込み、検索可能なナレッジベースを構築し、外部 API にデータを送信することなく Retrieval-Augmented Generation (RAG) を使用して自然言語クエリに回答できるものでした。
Catant HR & ワークフォース管理プラットフォーム
Catantは、企業が従業員、給与計算、勤怠、およびコンプライアンスを単一のダッシュボードから管理できるよう支援する、モジュラー型のHRおよびワークフォース管理プラットフォームです。
よくある質問
MicrocosmWorks はマルチエージェントアーキテクチャを設計しました。このアーキテクチャでは、特化したエージェントがドキュメント分析のさまざまな側面を処理します。例えば、スプレッドシート用の表抽出エージェント、物語形式のドキュメント用のテキスト要約エージェント、そして複数のファイルにわたるデータポイント間の関係を特定するクロスリファレンスエージェントなどです。この分業は、単一のモノリシックな LLM コールよりも、より正確な結果を生み出します。なぜなら、各エージェントは焦点を絞ったコンテキストウィンドウ内で動作し、ドメイン固有のプロンプト戦略を適用するからです。
はい、MicrocosmWorks は、数式の依存関係を解決し、ピボットテーブルの要約を展開し、シート間の参照を追跡するスプレッドシート解析エンジンを構築し、構造化データを分析エージェントに渡します。システムは、複雑な Excel 構造を LLM が効果的に推論できるフラットなデータ表現に変換し、シート間のリレーショナルなコンテキストを保持するため、AI は複数のタブ間でデータを結合する必要がある「どの部門がQ3の予算を超過しましたか」のような質問に答えることができます。
MicrocosmWorksは、アップロードされたすべての文書から固有表現、数値識別子、日付参照を抽出するエンティティリンキングパイプラインを実装しました。その後、ファイル間の関連する言及を接続するナレッジグラフを構築します。ユーザーが質問すると、相互参照エージェントはこのグラフをたどり、複数のソース文書から関連データを取得し、人間のアナリストが手動で相互参照に何時間も費やすような方法で情報を統合した回答を提供します。
MicrocosmWorksは、1回の分析セッションあたり最大500ファイルのドキュメントバッチを処理できるようシステムを設計しました。個々のファイルサイズは、スプレッドシートで最大100MB、PDFで最大50MBまで対応しています。大規模なドキュメントは自動的にチャンク化され、複数のエージェントインスタンス間で並行して処理されます。また、オーケストレーターは、エージェントの出力を統合された知識表現に集約することで、ドキュメントセット全体の一貫したビューを維持します。
MicrocosmWorksは、マルチエージェント文書分析プラットフォームを1時間あたり30ドルから50ドルの料金で開発しています。文書解析、エージェントオーケストレーション、相互参照検出、およびユーザー向けクエリインターフェースを含む本番環境対応のシステムは、通常、3〜5ヶ月の開発期間を要します。本番環境でのクエリあたりのコストは、文書量とLLMトークンの使用量に依存しますが、マルチエージェントアーキテクチャは、文書セット全体を単一のプロンプトに詰め込むのではなく、各エージェントに関連するコンテキストのみをルーティングすることで、実際にはLLMコストを削減します。