AIエージェント開発とMCPサーバー構築：言語モデルを既存システムにつなぐ

デモはどれもうまく動きます。社内ドキュメントを要約したPoCは印象的でしたし、サポート問い合わせに答えるプロトタイプも実用段階に見えました。ところが実際のCRM、実際の権限モデル、実際のデータに触れた瞬間に、実用段階ではなくなります。

その落差こそが作業の中身です。モデルそのものではありません。モデルはもう簡単な部分です。難しいのは、言語モデルと、認証・レート制限・テナント分離・誰が何を見てよいかについて確固たる仕様を持つシステムとの間にあるすべてです。

提供内容

社内システム向けMCPサーバー

Model Context Protocolは、ツールとデータをAIアシスタントに公開するためのオープン標準で、どのクライアントからでも同じ形で扱えることが特徴です。「アシスタントごとに個別の連携を書かずに、自社システムを使わせるにはどうするか」という問いに対する、現時点で最も実用的な答えになっています。

私たちは、事業を実際に動かしているシステムの上に本番品質のMCPサーバーを構築します。CRM、チケット管理、データウェアハウス、社内API、文書管理、ERP。トークンをハードコードしたデモサーバーではありません。適切な認証、既存システムがすでに強制している権限をそのまま尊重するユーザー単位の認可、マルチテナントの分離、レート制限、構造化ログ、そして呼び出しが失敗したときにモデルにとって意味のある情報を返すエラー設計を備えたものです。

業務特化型AIエージェント

一連の業務を最後までやり切るエージェントを構築します。受信キューのトリアージ、食い違う2つのシステムの突合、人が承認する前提の文書初稿の作成、社内外の情報源にまたがる調査タスク。地味な部分も込みで作ります。リトライ、タイムアウト、コスト上限、書き込みを伴う処理の冪等性、そして取り消しが難しい操作の手前に必ず置く人間の承認ステップです。

自社コンテンツに対する検索・参照

RAGを正しく作るということは、文字数ではなく文書構造を尊重した取り込みとチャンク分割、埋め込みとベクトル検索、純粋なベクトル検索では完全一致を取りこぼすためのキーワードとセマンティックのハイブリッド検索、リランキング、そして回答を検証できるようにする出典引用を意味します。加えて地味な残り半分もあります。元の文書が変わったときにインデックスを最新に保つこと、そしてアクセス制御を守り、そのユーザーが本来開けない文書を検索結果に出さないことです。

業務プロセスとバックオフィスの自動化

すべてにエージェントが必要なわけではありません。企業がAIに求めているものの相当部分は、分類、抽出、振り分けです。受信メールを読んで何の用件かを判定する、非構造データから構造化データを取り出す、記述内容をカタログの項目に対応づける。これらはエージェントより安価で、信頼性が高く、評価もしやすい方法です。それが正解である場合は、そちらを構築します。

評価、可観測性、ガードレール

評価のないAI機能は、誰にも改善できない機能です。実際の事例からテストセットを作り、変更のたびに測定し、すべての呼び出しについて入力、ツール利用、レイテンシ、コストをトレースし、暴走ループがAPI請求額を見つける前に上限を設定します。プロンプトインジェクションは、エージェントが信頼できないコンテンツを読み、かつ行動もできるようになった時点で現実のリスクになります。悪意ある文書が破壊的な操作に変わらないよう、ツールの境界そのものを設計します。

モデルプロバイダーとの関わり方

特定の1社に縛られてはいません。AnthropicのClaudeモデル、OpenAI、Google、そして自社インフラで動かすオープンウェイトモデルのいずれに対しても構築しますし、モデルを差し替え可能な構成要素として扱えるように設計します。どれを使うべきかは、タスクの性質、必要なレイテンシ、その取扱量における1回あたりのコスト、そして（欧州では判断を左右する要因になりつつありますが）、データをどこに置いてよいかによって決まります。

データ所在地に制約のあるお客様には、EUリージョンへの配置や、自社ハードウェア上でのセルフホスト推論を用います。それによって性能面で何を諦めることになるかは、率直にお伝えします。

当社が行わないこと

AI戦略コンサルティングは行っていません。何かの変革の可能性を語るワークショップも開催していません。

また、エージェントを必要としない課題にエージェントを構築することもしません。ご相談いただくAI案件のかなりの割合は、仕様のはっきりしたAPI連携、検索インデックス、あるいはその下にあるデータ品質の問題を直すことで、より良く解決できます。そうお伝えすることで案件規模は小さくなりますが、その分、保守し続けなければならないシステムが1つ減ります。

効果が出やすい領域

技術的には存在するのに実質的にたどり着けない社内知識：wiki、共有ドライブ、チケット管理システムに数千件の文書が散在し、どれが最新かを知っている人は休暇中、という状態。

大量のトリアージ業務：サポートキュー、請求受付、インバウンド営業、応募書類の審査。人が何かを読んで、何の用件かを判断し、次に回している業務すべて。

連携が用意されなかったシステム同士：本来つながるべき2つのツールがつながっておらず、回避策が「表計算ファイルを持った担当者」になっている状態。両方にMCPでアクセスできるエージェントのほうが、正式な連携プロジェクトより近道であることがよくあります。

文書量の多い業務：契約書、請求書、仕様書、規制当局への届出。人によるレビュー工程を挟んだ抽出は、これらの業務の採算構造を変えられる程度には、すでに信頼できる水準にあります。

自社コードベースにおける開発生産性：社内ツール、コードレビュー支援、テスト生成、そしてチームのアシスタントにビルドシステム、課題管理、ログへのアクセスを与えるMCPサーバー。

プロジェクトの進め方

ディスカバリー：1〜2週間。変えたい業務プロセス、関係するシステム、そしてデータの実態を確認します。成果物は、何が実現可能か、その取扱量で月あたりの運用費がいくらになるか、どのような失敗の仕方をするかを書面にまとめた評価です。「これは作らないほうがよい」という結論になることもあります。

PoC：3〜6週間。管理された環境で実データに対して実施します。目的はデモではなく、お客様が選んだ事例に対して測定された精度という、信頼できる評価結果です。

本番構築：通常8〜16週間。認証、認可、監視、評価基盤、コスト制御、ドキュメントを含みます。御社のインフラに、御社のリポジトリで、御社のチームと一緒に進めます。

運用または引き継ぎ：御社チームがランブックと評価スイートとともに引き取るか、私たちが保守契約のもとで運用を続けるかのいずれかです。モデルは変わり、プロンプトは劣化します。何かが静かに悪化したことを教えてくれるのは評価スイートです。

技術スタック

エージェントとMCPの実装にはPythonとTypeScript。検索基盤にはpgvectorを載せたPostgreSQL、Qdrant、Weaviate、OpenSearch。推論にはAWS Bedrock、Azure OpenAI、各社APIの直接利用、そしてデータを外に出せない場合はvLLMやOllamaによるセルフホスト。トレーシングはOpenTelemetryベース。連携側は御社の既存スタックがそのまま対象です。実際の作業はそこで発生するからです。

よくあるご質問

MCPサーバーとは、平たく言うと何ですか

データベースから読む、チケットを作る、社内文書を検索するといった機能を、AIアシスタントが理解できる標準形式で公開する小さなサービスです。1つ作れば、MCPに対応したどのアシスタントからも、個別の連携を書くことなくその機能を利用できます。

MCPサーバーと通常のAPI連携、どちらを作るべきですか

1つのAIアシスタントが1つのシステムを使うだけなら、直接連携のほうが単純です。MCPが効いてくるのは、複数のアシスタントや複数のチームが同じシステムを必要とする場合、まだ選んでいないツールからも将来使えるようにしておきたい場合、あるいは権限管理と監査ログを1か所にまとめたい場合です。

エージェントが破壊的な操作をしないようにするには

多層で防ぎます。書き込み系のツールは読み取り系と分離し、タスクに必要な最小限の範囲に絞ります。取り消しできない操作は人間の承認ステップを通します。すべての呼び出しは引数とともに記録します。そしてエージェントは、その業務に必要な権限だけを持つサービスアイデンティティで動作するため、影響範囲はプロンプトではなく御社自身の認可モデルによって限定されます。

運用コストはどのくらいかかりますか

取扱量と、1回の呼び出しがどれだけのコンテキストを運ぶかで、ほぼ決まります。ディスカバリーの段階で実数をもとに試算します。毎ターン文書全体を送る設計と、必要な部分だけを検索して送る設計とでは、月額コストが桁で変わることがあるためです。

データをEU域外に出さずに運用できますか

できます。主要プロバイダーはEUリージョンを提供していますし、オープンウェイトモデルは御社が管理するインフラで動かせます。通常は性能とのトレードオフが伴いますので、それが何であるかを「ない」と取り繕わずに具体的にお伝えします。

前回のAI PoCは本番に至りませんでした。今回は何が違いますか

前回そうなった理由は、たいていの場合、PoCがモデルにタスクを実行できることを示しただけで、認証、権限、エラー処理、評価、コストには一切触れていなかったからです。残りの9割の作業はそこにあります。私たちはモデルが動くことを前提として出発し、それ以外のすべてに期間を使います。

お問い合わせ

変えたい業務プロセスと、それが触れるシステムをお聞かせください。エージェントが適切な手段かどうか、現実的な最初のバージョンはどのようなものか、構築と運用にいくらかかるかをお伝えします。

技術ディスカバリーセッションのご相談は、お問い合わせフォームからご連絡ください。