事例:エンタープライズAIエージェントに「長期記憶」と「組織コンテキスト」を実装する——V7はContext Graphでいかに複雑なビジネスワークフローを成立させたか
OpenAIが公開した事例研究で取り上げられた欧州スタートアップV7の「V7 Go」は、単なる高性能チャットボットではなく、「社内で何が起きたか」「文書間の実体がどう結びつくか」「結論の根拠はどこか」という企業固有の課題を、Context Graphとモデルの役割分担によって解決するアプローチを示している。
OpenAIが公開した事例研究では、欧州のスタートアップ企業V7が開発したエンタープライズ向けAIエージェント(自律的に目標を解釈しツールや推論を用いてタスクを遂行するシステム)基盤「V7 Go」が紹介されています。同プラットフォームが解こうとしているのは、「より賢いチャットボットをどう作るか」ではなく、はるかに具体的で実務的な企業の課題です。すなわち、社内で過去に何が起きたのか、別々のファイルに登場する実体がどう関連しているのか、そしてAIが導き出した結論はどの資料のどこに基づいているのかを、AIにいかに正確に把握させるかという点です。
V7の解決策は、一連の明確なパイプラインとして整理できます。まず社内に散在する文書群を解析し、出典引用の紐付いた「Context Graph(コンテキストグラフ)」として構造化します。その上で、能力とコストの異なる複数のモデルへ工程ごとに役割を分担させ、最後に検索、推論、ツール呼び出し、監査ログを単一のワークフローへ統合して実行します。
- エンタープライズAIエージェントの主な障壁は、多くの場合「推論ができないこと」ではなく、どのファイルが最新版かわからない、異なるシステム間で表記揺れのある名称が同一の対象を指しているか判断できない、そして結論をどの証拠まで遡るべきかが掴めない点にあります。
- V7はエンティティ(企業名や人物などの固有要素)、関係、事実、引用元を事前に抽出します。頻出する関係性の探索はContext Graphを経由し、グラフ上の情報だけで不足する場合に限り元文書へのRAG(検索拡張生成)で補完します。また、直近の対話はモデルのコンテキストウィンドウ内に保持し、過去の資料はグラフへ格納して必要に応じて取り出します。
- 高スループットな抽出処理、複雑なツール呼び出し、極めて難度の高いグラフクエリを、それぞれLuna、Terra/Sol、Astraへ割り振っています。V7の報告によれば、コスト、エラー率、複雑クエリの正答率のいずれにおいても改善が見られたとされています。
- このアーキテクチャが最も適しているのは、文書をまたぐ関係性が密で、エンティティの定義が比較的安定しており、すべての結論について元データとなる一次証拠への遡及が必須となる業務です。一般的な社内FAQのように基本的なRAGで解決できる領域では、ナレッジグラフの構築はかえって保守コストを増加させる要因になります。
1. 根本的な課題:AIは「物忘れ」しやすく、社内の文脈を理解できない
厳密さが求められる企業実務において、有能なシニアアナリストが手元のPDF1点だけを見て判断を下すことはありません。投資先企業が前期に中核子会社をカーブアウト(事業分離)した事実を知っており、一見矛盾する3つのバリュエーション表のうちどれが監査済みの確定版であるかを把握し、業務システムごとに表記が異なる各部門が実際には同一の責任者のもとにあることを理解しています。ビジネスの円滑な遂行を支えるこれらの沿革、関係性、判断根拠こそが、企業の持つ「制度的記憶(インスティテューショナル・メモリー)」です。
一般的な大規模言語モデル(LLM)は、こうした記憶をあらかじめ保持していません。企業の調査レポート、データルーム、財務諸表、メール、社内システムのデータは各所に分散しており、同一組織に複数の通称が存在したり、同一指標に複数のバージョンが混在したりすることも日常茶飯事です。金融、保険、不動産などの業界において、ワークフロー内の検索正確性は妥協が許されない必須要件です。エージェントにどれほど高度な推論能力があっても、どの資料が同一の取引線に属しているか、どの数値が最新か、特定の判断にどの証拠を引用すべきかを自律的に特定することはできません。
構造化された記憶を持たないエージェントは、新規タスクを処理するたびに関連文書をゼロから再検索し、読み込み、手作業のように繋ぎ合わせる必要があります。このようにリクエストごとに毎回コンテキストを再発見するアプローチは、API呼び出し時間とトークン消費量を跳ね上げるだけでなく、複数文書間の関係性の奥深くに埋もれた重要な事実を見落とすリスクを高めます。
基礎的な検索拡張生成(RAG: Retrieval-Augmented Generation。外部知識を検索してプロンプトに付加する手法)は、意味的な類似度に基づいて関連段落を抽出でき、極めて大きなコンテキストウィンドウを用いれば一度に大量の資料を読み込ませることも可能です。しかし、実務で真に難関となるのは「関係性の把握」です。例えば、あるファンドが過去に投資した案件のうち、新規制の影響を受ける銘柄を特定しようとする場合、答えはファンドの管理台帳、個別プロジェクトのデューデリジェンス報告書、業界コンプライアンスメモに分散している可能性があります。関連する3つの断片を見つけ出すのは入口にすぎず、そこに登場するファンド、投資先、適用規則が同一の業務文脈を指しているかを照合・確認できなければ、正しい結論には至りません。
2. V7 の解決策:Context Graph で企業の記憶を補完する
V7 Goの中核メカニズムは「Context Graph(コンテキストグラフ)」と呼ばれます。これはユーザーから質問を受けてから場当たり的に全ファイルを探索するのではなく、資料がシステムに取り込まれた段階で、内部に含まれるエンティティ、関係性、客観的事実、およびその出典をあらかじめ整理・構造化しておく仕組みです。
企業がSharePointやGoogle Driveなどのクラウドアカウントを連携すると、新規ファイルが届くたびにV7 Goがドキュメントをスキャンします。そして事前に定義されたオントロジー(Ontology: 業務上認知・合意されたエンティティ種別やリレーション規則の体系)に基づき、企業、ファンド、キーパーソン、契約条項、資産指標といった対象を識別します。システムは抽出された各事実を結合して新規レコードまたは既存レコードに紐付けると同時に、元文書の該当箇所を指し示す厳密な引用証拠(シテーション)を保持します。
[元ドキュメント連携] (SharePoint / Google Drive)
│
▼
[エンティティ・事実の抽出] (企業、人物、ファンド、条項、指標の識別)
│
├──────────────────────────────┐
▼ ▼
[ナレッジグラフ直接照会] [下位原文の RAG フォールバック]
(エンティティ関係に沿って履歴照会) (グラフ情報不足時に元文書を検索)
│ │
└──────────────┬───────────────┘
▼
[精緻な引用付きの業務成果物を生成]
これにより、エージェントには2つのデータ取得経路が生まれます。一般的な関係性の照会は、グラフ上のエッジを辿って関連事実を直接探索します。構造化データだけでは細かなニュアンスに回答できない場合に限り、下位レイヤーの元テキストを対象としたRAG検索へフォールバックします。V7の説明によると、グラフ探索にかかるコストと速度は長大なコンテキストに全文書を流し込む手法に比べて桁違いの優位性を持っています。エンティティの曖昧性解消(名寄せ)と関係性の接続があらかじめ完了しているため、既知のノードとエッジに沿って直接データを引き出すことができ、都度大量の文書をコンテキストウィンドウに再投入する無駄を排除できるためです。
記憶の構造自体も2層に分離されています。直近の会話履歴はモデルの即時コンテキスト内に保持してタスクの連続性を担保し、それ以前の蓄積資料はContext Graphへ格納して、必要に応じてエンティティや関係性をキーにオンデマンドで呼び出します。この設計により、長期記憶がコンテキストウィンドウを圧迫し続ける事態を回避し、過去の情報をタスクのたびに最初から探索し直す必要もなくなります。
企業のヘテロジニアス(異種混在)データにおける検索・結合能力を測定するHERBベンチマークテストにおいて、V7は自社検索システムが公式ベースラインを69%上回り、回答不可能な設問におけるハルシネーション(もっともらしい嘘の生成)が38%減少したと報告しています。この一連の検証結果は、社内情報間の関係性を事前整理しておくことが、検索精度の向上と不適切な回答の抑止(適切な回答拒否)の双方に寄与し得ることを示しています。
3. OpenAIの複数モデルによる協調運用:難易度に応じた適材適所の振り分け
社内の記憶を整理できたとしても、それだけで複雑なタスクを安定して完遂できるわけではありません。実際の長いプロセスは、確定的なプログラムコード、軽量モデルによる中継、ドキュメント生成ステップ、外部システム連携、そしてLLMによる推論ステップが組み合わさって成り立っており、再利用可能なワークフローでは数百ステップに及ぶケースもあります。このような長大な処理チェーンでは、上流のツール呼び出しが1回失敗したり解釈ミスが生じたりしただけで、その誤りが後続工程へ連鎖的に波及し、プロセス全体が脱線して高額な損失やシステムへの信頼失墜を招きます。一方で、全工程に最も高性能かつ高価格なモデルを割り当てていては、運用コストの維持が困難になります。
適切なモデルルーティングを実現するため、V7は引用精度の高さ、数百種に及ぶ文書タイプの抽出品質、回答の正解率、指示追従性、レイテンシ、コスト、および実際のエンタープライズワークフローにおける挙動を継続的にベンチマーク評価し、その結果をもとに各工程を難易度ごとに階層化してモデルを割り振っています。
- GPT-5.6 Luna が高スループット抽出を担当: V7は数百万件規模の文書からの情報抽出とグラフへの蓄積にLunaを採用しています。同社テストでは精度が11.6ポイント向上し、文書1件あたりの処理コストはGPT-5.4 miniと比較して78%削減されたと報告されています。
- GPT-5.6 Terra および Sol が複雑なワークフローを担当: 多段階の論理推論、アプリケーション横断のツール呼び出し、人間との対話、そして従来であれば人間の専門家が数十時間を要していた複雑な指示の実行をこのレイヤーが担います。V7のContext Graphベンチマークにおいて、ツール呼び出しのエラー率はGPT-5.5の2.7%に対し、GPT-5.6 Solでは0.2%に抑えられました。またV7によると、Terraを採用したことで、従来の精度の低いモデルに配慮して設けていた冗長な中間ステップを撤廃でき、数日分の開発・納品工数を削減できたほか、ワークフロー初版での一発通過率が大幅に向上したとしています。
- GPT-6 Astra が最難度の文書横断クエリを担当: V7は数千件の複雑なドキュメントから成るデータセットを用い、4段階の難易度テストを構築しました。最も難度の高い区分において、Solのスコアが78%にとどまったのに対し、Astraは89%に達しました(なお、簡易、中等度、高難度の区分では双方ともに100%近い数値を記録しています)。
この役割分担は、「モデルは強ければ強いほどよい」という画一的な考え方から、「適切なステップに適切なモデルを充てる」という設計思想への転換を意味します。大量の定型抽出は軽量モデルでユニットエコノミクスを徹底管理し、ツール実行や判断連鎖が絡む工程ではエラーの下流波及を防ぐため安定性を最優先し、真に高度なグラフ推論が必要な局面でのみ最高峰モデルを呼び出します。この運用下において、システムは2種類の監査ログを明確に区別して記録します。1つは事実情報が元文書のどこに由来するかを示す「事実引用」、もう1つは実行ごとにモデルがどのような判断を下したかを完全にトレースする「意思決定軌跡」です。
プライベートエクイティ(PE: 未公開株)投資の案件初期スクリーニングの実演では、この分業体制は単一のチャット画面という形をとりません。システムは秘密保持契約下の案件概要書(CIM: Confidential Information Memorandum)を読み込み、財務指標、取引条件、経営陣の経歴、潜在リスクなどの重要項目を構造化フィールドへ自動分類します。ワークフローのキャンバス上に配置された「競合取引マルチプル」「重大リスクフラグ」「投資機会評価」といったノード群が順次データを処理し、最終評価は評価軸ごとのスコアと算出根拠とともに提示され、該当する証拠文書への引用リンクが付与されます。
V7はさらに、グラフ機能を企業が既存で利用しているツール群へ接続しています。Context Graphのクエリ機能およびデータ取り込み機能はMCP(Model Context Protocol: AIモデルと外部ツール・データソースを接続するオープン仕様)サーバーとしてカプセル化されており、クライアントはChatGPTなどの互換環境から直接グラフを照会したり、Codex環境からMCPを介してV7 Goのワークフローを新規作成したりできます。V7の報告によれば、この連携とシンプルなワークフロー設計により、中規模ワークフローの構築工数は約1時間から約20分へと短縮されました。
下位のAPIインターフェースも従来のChat Completions APIからResponses APIへと移行しています。V7のテスト結果では、PDFを多用する特定のワークフローにおいてトークン消費量が約5%削減され、キャッシュの信頼性が向上したほか、最新の実行フレームワーク環境下では複数の外部呼び出しを伴う重要ワークフローの完了時間が最大で50%短縮されました。インフラ供給面に関しても、他社プロバイダーでは数週間を要することが多かったキャパシティの拡張要求に対し、OpenAIは数時間でスケール対応を完了させたという調達上の実績も挙げられています。
4. 実際のビジネス価値:時間、コスト、エラー率は具体的にどう改善されたか?
Context Graphとモデルルーティングが最終的に証明すべきは、企業が投じる時間を真に減らし、ミスを抑制し、高度専門人材の工数を節約できているか否かです。OpenAIの事例研究では、個別顧客における3つの成果が挙げられています。
- アセットマネジメント: PE投資案件の初期スクリーニング速度が21倍に向上(丸1日かかっていた作業が15分に短縮)。
- 金融サービス: 審査・査定時間が100時間超から10時間未満へ短縮され、案件ごとに約1万2,000ドル相当の専門家コストを削減。
- 保険: 過去の請求履歴および既存契約書の知識を統合した結果、処理ミスが人間のベースラインと比較して13.5%減少。
なお、これらの数値は特定の顧客事例における測定結果であり、すべての企業が導入直後に一律で同様の数値を達成できることを意味するものではありません。技術ベンチマークと顧客成果を突き合わせて確認することで、各指標が具体的にどのような前提のもとで測定されたのかが見えてきます。
| 評価項目 | V7 公表値 | 指標が検証している論点 | 参照時に留意すべき前提条件 |
|---|---|---|---|
| ドキュメント抽出コスト | GPT-5.4 mini 比で 78% 削減 | Lunaが高スループットの文書処理に適しているか | V7の文書処理ワークロードに基づく |
| ツール呼び出しエラー率 | GPT-5.6 Sol が 0.2%、GPT-5.5 は 2.7% | モデルの刷新が多段階フローのツール安定性を改善するか | V7独自の Context Graph ベンチマークに基づく |
| ワークフロー全体の精度 | 50〜100ステップのワークフローで 99.9% の精度を達成したと主張 | V7が長大なフローを単一の品質管理対象として制御できているか | 事例ページに精度算出の完全な計算定義は非開示 |
| 複雑なグラフ照会 | Astra が最難問でスコア 89%(Sol は 78%) | 上位モデルが極めて複雑な文書横断検索を改善できるか | 数千件の文書を用いたV7独自の4段階難易度テストに基づく |
| 実務スクリーニング高速化 | 丸1日から15分へ短縮(21倍の高速化) | グラフ駆動ワークフローが人的一次審査時間を削減するか | 特定のアセットマネジメント顧客事例に基づく |
これらの一連の結果は、V7の優位性が単に「高性能なモデルを使ったこと」だけに起因しているのではないことを示しています。コンテキストの事前整理によって重複検索を削ぎ落とし、モデルルーティングによってコストとエラーを抑制し、構造化ワークフローによって各工程の再利用性を高め、出典の紐付けによって結論を元資料に立ち返って検証可能な状態に保っていることが寄与しています。
5. 次の展望:「受動的な問い合わせ」から「能動的なアラート」へ
現行のContext Graphは、主にユーザーからのクエリやワークフローの実行指示を受け取った段階でコンテキストを提供する「受動型」の構成をとっています。現在V7が開発を進めている次のフェーズは、イベント駆動型のアクティブ・メモリー(能動的記憶)です。これはグラフ内の事実関係に更新が生じた際、システムが自律的にワークフローを起動し、矛盾点を検知して、どの過去の分析結果を再実行・修正すべきかをアラート通知する仕組みです。
例えば、あるファンドの決算報告書に過年度遡及修正が入った場合、システムは古い数値を前提にして作成された過去の分析レポートを網羅的に特定し、担当者へ警告を発します。こうなれば、企業の制度的記憶は単なる「必要なときに調べる静的なナレッジベース」にとどまらず、事業の状態を常時モニタリングし続けるトリガーとして機能するようになります。
もっとも、これは現時点ではV7が掲げる中長期の研究開発ロードマップ上の構想です。この取り組みの本質的な重要性は、エンタープライズAIエージェントの競争軸を「エージェントを社内に何体配備したか」という数の論理から、「継続的に更新可能で、出所を追跡でき、次なるアクションを直接駆動できるビジネスコンテキストを保有しているか」という質の論理へとシフトさせた点にあります。
どのような企業が導入を検討すべきか:3つの判断基準
Context Graphは、すべての企業のAIプロジェクトにおいて必須の構成要素というわけではありません。ナレッジグラフの構築にはエンティティやリレーションの明確な定義が不可欠であり、継続的なメンテナンスコストも発生します。投資に見合う価値があるかどうかは、以下の3つの論点から客観的に判断できます。
業務が文書横断的な関係性に強く依存しているか?
求める要件が個別の社内規程、業務マニュアルの検索、あるいは一般的な一問一答のFAQ対応であるならば、従来のチャンキング(文書分割)とベクトル検索を用いたRAGで大半の要件を満たせます。事前定義によるナレッジグラフ構築コストを回収できるのは、金融のデューデリジェンス、投資先の多層的な実質支配関係の把握、複雑な保険金請求査定のように、複数システム・複数年度にまたがるエンティティの関係性を高頻度で横断追跡しなければならない業務に限られます。
社内に安定したエンティティおよび関係性の定義が存在するか?
グラフを正常に機能させるには、何が「企業」で、何が「ファンド」「プロジェクト」「契約条項」「責任者」であり、それらが相互にどう結びついているのかという前提知識が必要です。業務オントロジーが確立されているほど、抽出結果の検証とグラフの維持管理は容易になります。社内用語や組織体制、承認プロセスが流動的で頻繁に変更される環境では、グラフ内に重複ノードや誤った関係性が増殖し、かえって後続の推論を狂わせる結果になりかねません。
導き出された結論は一次証拠まで遡及できなければならないか?
アイデア出しや一般的な要約タスクであれば、出力結果が概ね妥当であれば実用上問題ありません。しかし、コンプライアンス、財務、法務、引受審査(アンダーライティング)などの現場では、わずかな事実誤認が事業上の重大な誤判に直結します。ここで確認すべき実践的な基準は、「生成された結論から、レビュー担当者が引用リンクを辿って元文書の該当箇所へ即座に戻り、正しいエンティティ、正しい版数、正しい指標数値に基づいているかを客観的に検証できるか」です。この厳密なトレーサビリティが担保できなければ、どれほど整然と構築されたナレッジグラフであっても、真に信頼に足るエンタープライズの記憶基盤として機能させることは困難です。
実践用持ち帰り資料
Markdown をスクロールして確認し、コピーしてチーム向けに調整できます。
Markdown を読み込み中…
