【第2部】知性に新しい能力をつなぐ
動いていたREST API接続を、RikAI2-MCP Toolへ広げる
はじめに
第1部では、一体のHermes Agentから始まり、Qwen系とGemma系の二体をOmnigent上で討議させる環境へ発展した過程を紹介しました。
次に必要になったのは、画像や文書を読み解く能力です。
接続先として選んだのは、別サーバー上にContainerで構築されたRikAI2でした。
ただし、RikAI2への接続方法が分からなかったわけではありません。Omnigentへ相談する以前に、別途、画像とPromptを社内RikAI2のREST APIへ送り、解析結果を取得する簡単なプログラムを作成していました。
画像・文書 + Prompt
↓
簡単な接続プログラム
↓
社内RikAI2 REST API
↓
非同期の解析結果
つまり、REST APIを直接利用する短い経路は、すでに動いていました。
次に考えたのは、この接続処理をHermes Agentが必要に応じて利用できないか、ということです。既存プログラムを参照できる状態でOmnigent上のHermesへ相談したところ、REST API接続をMCP Toolとして包み直す案が出てきました。
実際に比較すると、決められた画像とPromptを送り、結果を受け取るだけなら、既存の直接接続プログラムの方が単純で速いというのが率直な感想です。
それでもMCPを試したのは、RikAI2を最速で呼び出すためではありません。
動作済みのREST API接続を、Agentが発見し、選択し、実行できるToolへ変えられるか。
第2部では、その再構成の意味とトレードオフを整理します。
1. なぜRikAI2だったのか
業務で扱う情報は、整形済みのテキストだけではありません。
- PDFやスキャン画像
- 手書き文書
- 表や図を含む帳票
- 複雑なレイアウトを持つ資料
こうした情報をAgentの判断材料へ変えるには、画像や文書を読み解く専門能力が必要です。
RikAI2は、米国のAI企業Lazarusが提供する文書処理・マルチモーダル推論向けのAIです。Lazarusは、RikAI2をLLMとExtractive AIを組み合わせて文書を理解・分析する技術として説明しています。
私がExtractive AIという考え方で重視したのは、もっともらしい文章を自由に生成することだけではなく、与えられた画像や文書を根拠として、その内容に沿って情報を取り出す方向性です。
RikAI2を含むLazarus AIは当社の取扱サービスであり、私自身も社内でRikAI2の技術サービスを担当しています。今回の検証は、日頃からサービス開発に関わっているRikAI2を、Agent Harnessから利用できる専門能力として組み込めるかを確かめる試みでした。
今回の役割分担は次の通りです。
第1部でモデルの役割を分けたのと同じように、第2部では文書解析を独立した専門能力として切り出しました。
2. 既存の接続プログラムを、AgentのToolへ変える
私は、事前に作成した接続プログラムを参照できる状態にし、Omnigent上のHermesへ概ね次のように相談しました。
このプログラムでは、画像とPromptをRikAI2へ送り、解析結果を取得できている。これをHermes Agentから必要に応じて利用できるようにしたい。
Qwen側とGemma側のHermesは、独立したSessionで既存プログラムと接続方法を確認し、Moderatorが結果を回収して統合します。
既存のREST API接続プログラム
↓
Qwen側Session
接続処理とMCP化の方針を整理
↓ 回収・受け渡し
Gemma側Session
Tool化した場合の懸念や抜けを検証
↓ 回収
Moderator
実装方針を統合
検討したのは、既存コードのどこを再利用し、どこをAgent向けに作り替えるかです。
- REST APIを呼び出す処理は再利用する
- 画像とPromptを受け取るToolを定義する
- 認証情報はAgentへ直接渡さない
- 非同期結果をTool Resultへ変換する
- エラーやタイムアウトをAgentが判断できる形へそろえる
この検討から、既存のREST API接続処理をMCP Server側へ取り込み、Agentからは目的の明確なToolとして利用する案が具体化しました。
MCPは、動いていた接続プログラムを捨てて作り直すものではありませんでした。
既存のAPI接続を、Agentから利用できるToolとして包み直すための層でした。
AIが勝手に自己進化したわけではありません。接続先、動作済みプログラム、仕様、環境情報は人間が用意しました。Agentは既存実装を読み、MCP化の方針とコードを提案しました。生成コードの確認、配置、認証情報の管理、試験、採用判断は人間が担いました。
3. MCPはREST APIの代わりではない
MCPは「AIのUSB-C」と例えられることがあります。接続面を共通化するという意味では分かりやすい表現です。
ただし、MCPは単なる端子ではありません。MCP ServerはToolの名前、説明、入力スキーマを公開し、ClientはToolを発見し、呼び出し、結果を受け取ります。
Tool Discovery
↓
Tool Call
↓
Tool Result
一方、RikAI2の実処理はREST APIで呼び出します。つまり、MCPはRikAI2 REST APIを置き換えません。REST APIの手前へ、Agent向けのTool境界を追加します。
OpenAPIとの違いは、次のように整理できます。
OpenAPIはAPIの説明書。MCPはAgentとToolの会話規約。REST APIは実際の処理経路。
4. RikAI2-MCP Serverが加えたもの
事前に作成したプログラムには、すでに次の中核処理がありました。
画像 + Prompt
↓
Request整形
↓
RikAI2 REST API
↓
非同期結果の取得
MCP化によって追加したのは、その処理をAgentが利用するための境界です。
Hermesから見えるのは、概念的には「画像・文書を解析する」というToolです。RikAI2固有のRequest形式、認証、結果取得はMCP Server側へ寄せます。
RikAI2-MCP Serverの中核は、すでに動いていたREST API接続処理です。MCP化で加えたのは、Agentがその処理を発見・選択・実行するためのTool境界です。
5. 直接REST APIの方が速い。それでも試した理由
MCP化する前から、RikAI2を直接呼び出すプログラムは動いていました。そのため、直接REST APIとMCP経由を、実際の利用感として比較できました。
固定された画像とPromptを送り、解析結果を受け取るだけなら、既存の直接接続プログラムの方が単純で速いと感じました。
MCP経由では、Tool選択、MCP通信、引数検証、結果変換、再Reasoning、統合などが加わります。高速化だけが目的なら、MCP経由を積極的に勧めることはできません。
今回、直接接続をMCPへ置き換えたかったわけではありません。短い直接接続を残した上で、Agentが自分でRikAI2を選んで利用する別経路を試しました。
固定処理、速度、単純さ
└─ 直接REST API
AgentによるTool選択、抽象化、共通接続面
└─ MCP
今回のRikAI2-MCPは、推奨構成を宣言するものではありません。
Agent Harnessから専門AIを利用する接続方式の一つとして、成立性とトレードオフを確かめた技術検証です。
ご存じの通り、MCPで利用できるToolはRikAI2だけではありません。ここで重要なのは個別サービスの数ではなく、共通の接続面を使っても、Toolごとの信頼境界やPolicyは別に設計する必要があることです。
6. 多層Harnessのどこで待っているのか
MCPを加えると、処理経路は多層化します。
User Interface
↓
Application Control
↓
Omnigent / Meta-Harness
↓
Hermes Agent Session
↓
MCP Client
↓
RikAI2-MCP Server
↓
社内RikAI2 REST API
↓
結果取得・整形
↓
Hermesの再Reasoning
↓
Moderatorの統合
↓
User Interface
RikAI2の解析に時間がかかったように見えても、原因がRikAI2本体とは限りません。
- AgentがToolを選んでいる
- Sessionへ依頼を配送している
- ファイルをAPI形式へ変換している
- REST APIの非同期結果を待っている
- MCP Serverが結果を整形している
- Hermesが再Reasoningしている
- Moderatorが統合している
どの層で待っているかによって、改善方法は異なります。
観測すべき対象はRikAI2だけではない。UIから最終表示までをつなぐHarnessの連鎖全体です。
この問題意識が、第3部のObservabilityへつながります。
結び：動いていた接続を、Agentが使える形へ広げる
第2部の出発点は、RikAI2への接続そのものではありませんでした。
画像とPromptを送り、解析結果を受け取る直接REST API接続は、すでに動いていました。
その実装を二体のHermesへ見せ、Agentからも利用できるようにしたいと相談したことで、MCP Toolとして包み直す案が生まれました。
結果として、RikAI2固有のAPI処理をAgentから分離し、「画像・文書を解析する」というToolとして見せる構成は成立しました。
一方、速度と単純さでは直接REST APIが有利でした。
接続方式は、解決したい問題に合わせて選ぶ必要がある。
今回得られたのは、MCPが常に正解だという結論ではありません。
動いているAPI接続を、Agent向けToolへ再構成できること。そして、その抽象化には追加の処理と遅延が伴うこと。この両方を確認できたことが、第2部の成果です。
接続層を増やすなら、その遅延、Policy、責任境界を観測できなければなりません。
第3部では、Memory、Observability、Git、Policyを使い、多層化したHarnessをどう残し、検証するかを扱います。
次回
【第3部】知性の経験を残し、検証する
Memory、Observability、Git、Policyで多層Harnessを捉える
リンク