RAGや基本的な関数呼び出しを上回る理由

1. はじめに

GPT-4oなどの大規模言語モデル(LLM)が企業の情報システムに組み込まれるにつれ、データを取得・処理・活用する方法そのものが大きく変わりつつあります。
これまでは、検索拡張生成(RAG)のパイプラインと関数呼び出しAPIを組み合わせれば、高度な質問応答には十分だと考えられてきました。

しかし、実際の資産管理や財務の業務では、単発の検索や単一関数のクエリにとどまらず、長期にわたる文脈の継続、リアルタイムの状態追跡、複数のデータソースのシームレスな連携が求められます。
そこで、まったく異なるアプローチとして登場するのがModel Context Protocol(MCP)です。

この記事では、MCPの概念と技術アーキテクチャ、RAGや関数呼び出し単体を上回る理由、そして資産管理のユースケースへの適用方法を解説します。

2. Model Context Protocolの定義

2.1 「コンテキスト」とは何か

AIによる自動化におけるコンテキストとは、目の前のプロンプトだけを指すものではありません。次のようなものが含まれます。

• 会話の履歴と、過去のユーザーの問い合わせ
• リアルタイムのシステム状態とデータのスナップショット
• ユーザーの役割、権限、セッションのメタデータ
• それぞれの質問の目的と、過去のタスクとのつながり

このコンテキストを維持することは、複数回のやり取りにわたって正確で一貫した回答を返すために欠かせません。

2.2 MCPとは何か

Model Context Protocol(MCP)は、LLMが次のことを行う方法を定める構造化されたフレームワークです。

• 取得する
• 階層化する
• 保持する
• 更新する

対象は、複数のクエリ、データ取得、関数呼び出しにまたがるコンテキスト情報です。

概念的には次のように表せます。

MCP = {C, U, F, S}

ここで、

• C(Context Layers):プロンプト、履歴、結果の階層的な分割
• U(User State):セッションとユーザーIDの管理
• F(Function Calls):外部データの取得と連携
• S(Session Memory):トークンの最適化と要約

3. MCPとRAG・関数呼び出しの比較

3.1 RAGの限界

検索拡張生成(RAG)は、ベクトル類似度検索と生成型の言語モデルを組み合わせたものです。
独自の文書群をもとにモデルが質問に答えられるといった利点がある一方で、企業での利用では構造的な弱点も見られます。

❌ 状態が継続しない:

• RAGは、過去の会話のやり取りを本来は追跡しません。

❌ 意味のずれ:

• 類似度検索では、一見関連がありそうに見えるものの、誤った情報や古い情報を含む内容が取得されることがよくあります。

❌ ライブデータとの連携がない:

• RAGは、リアルタイムのERPシステムやライブのデータベースに接続できません。

資産管理では、減価償却スケジュールや機器の割り当てを参照する際に、こうした問題が重大な誤りにつながるおそれがあります。

3.2 関数呼び出し単体の限界

GPT APIが対応している関数呼び出しを使うと、LLMは外部APIを通じて構造化データを取得できます。
しかしこちらにも、無視できない制約があります。

❌ 単発の呼び出しだけ:

• 通常は1つのプロンプトにつき1つの関数を処理し、結果を自動的に統合することはありません。

❌ コンテキストの階層化がない:

• 関数の出力を過去の会話の状態と結びつける仕組みが、あらかじめ備わっていません。

❌ メモリ管理がない:

• 長い会話ではすぐにトークンの予算を使い切り、結果が要約されることも保存されることもありません。

3.3 MCPが優れている理由

MCPは、検索と関数呼び出しの長所を組み合わせつつ、それぞれの弱点に対処します。

✅ コンテキストの階層化:

• 会話履歴、ユーザーの指示、システムの出力、モデルの応答を分離します。

✅ 関数結果の統合:

• 複数の関数呼び出しの出力を、目的に沿った一貫した回答にまとめます。

✅ セッションメモリ:

• 長時間にわたる会話の状態を維持します。

✅ 要約と永続化:

• 重要な情報を選んで保持しながら、GPT-4oの128kトークンの上限内でトークンの使用量を最適化します。

4. MCPの技術アーキテクチャ

4.1 コンテキストの階層化

MCPは、入力を個別のレイヤーに整理します。

• システムプロンプト:役割の定義と動作の制約
• ユーザープロンプト:現在の問い合わせ
• 会話履歴:過去のやり取り
• 関数結果:APIを通じて取得したリアルタイムのデータ

このアーキテクチャにより混乱を防ぎ、各レイヤーが適切に処理されるようになります。

4.2 マルチステップの関数呼び出し

単純な関数呼び出しと異なり、MCPでは複数の呼び出しを連鎖させ、集約できます。

‍

User: "Show me last quarter's depreciation and unused assets."
MCP:
  → Call 1: /depreciation?date=last_quarter
  → Call 2: /assets/unused
Model response:
"Last quarter's total depreciation was $120,000. Currently, there are 12 unused assets."

4.3 セッションメモリとトークンの最適化

GPT-4oは最大128kトークンのコンテキストウィンドウに対応しており、LLMの中でも最長クラスです。
それでも、複数のセッションにまたがる業務では、トークンの上限が制約として残ります。

MCPは、次の方法でこれに対処します。

• 要約:古いやり取りを簡潔な文にまとめます。
• 選択的な永続化:重要な識別子(資産ID、ユーザー名)をそのまま保持します。
• レイヤー単位のトークン管理:各コンテキストレイヤーに割り当て枠を設けます。

5. 企業の資産管理との連携

5.1 資産管理のデータレイヤー

企業の資産管理プラットフォーム(例:Sellease)では、MCPは次のデータレイヤーとやり取りします。

• 資産マスターレコード(ERP)
• ライセンスモジュール
• 使用ログ
• 減価償却の計算サービス

MCPはこれらのレイヤーへの呼び出しを調整し、1つのセッション内で結果を整合させます。

5.2 シナリオ例

ステップ1 – ユーザーの問い合わせ:
「先月返却された資産と、その減価償却を見せてください。」

ステップ2 – MCPが調整:

• 会話の状態を取得する
• 必要な関数呼び出しを特定する:
  • /assets/returned?date=last_month
  • /depreciation?date=last_month

ステップ3 – モデルの応答:
「先月は5台のノートPCが返却されました。減価償却の合計は2,500ドルです。」

6. 期待できる効果

MCPを導入すると、次のような明確な利点が得られます。

✅ 文脈を踏まえた、一貫した回答
✅ システム間でのリアルタイムのデータ連携
✅ レポートの自動生成
✅ RAGや関数呼び出し単体を上回る信頼性

7. 考慮事項と制約

MCPを実装するには、いくつかの点に対処する必要があります。

• トークン管理:長いセッションに向けた要約と削減
• レイテンシの制御:複数のAPI呼び出しを効率よく調整すること
• セキュリティ:ロールベースのアクセス制御とデータのマスキング
• 応答の標準化:予測可能な出力形式を確保すること

8. おわりに

Model Context Protocol(MCP)は、単純な検索パイプラインと、真にインテリジェントな企業向けエージェントとの間を埋めます。
RAGではハルシネーションが起こりうる一方、関数呼び出しだけでは断片的になりすぎます。MCPが提供するのは次のものです。

• 階層的なコンテキスト管理
• セッションメモリ
• 統合されたデータ取得
• 予測可能で監査可能な出力

Sellease は MCP を取り入れ、LLM を活用した資産管理の可能性を最大限に引き出し、一貫性があり正確で自動化されたワークフローを提供します。

企業のAIが進化するなかで、MCPは資産管理、財務、調達、コンプライアンスの各領域にまたがる基盤フレームワークになると見込まれます。

‍