概要

相変わらず生成AI関連の取り組みを行っているICTチームの中井です。

2025年度、ICTチームではMCP（Model Context Protocol）についてPoCを行っていました。

最終的には2026年2月頃に、MCPを利用してAIと社内システムを連携させるとどのような働き方ができるのかをイメージした、

「ABChat Link ～AIと共創する未来の働き方～」

というコンセプトを作成し、社内イベントで展示しました。

今回はこちらについて、技術的な構成を中心にご紹介します。

以前ご紹介した「ABChatギジロク」では、今後MCP Server化してAIエージェントから利用できるようにしたい、と書いていました。

今回はそのさらに先、複数の社内システムをMCP Serverとして公開し、AIが必要なものを選択して一連の仕事を進めるところまでをコンセプトとして実装しています。

MCPとは

MCP（Model Context Protocol）は、AIアプリケーションと外部のデータやツールを接続するためのオープンなプロトコルです。

Anthropicによって2024年に公開され、AIと外部システムの接続方法を標準化することを目的としています。（現在ではLinux Foundation傘下のAgentic AI Foundationへ移管されています。）

ざっくりいうと、

「AIから外部システムを利用するときの共通インターフェース」

のようなものです。

以前であれば、

「ABChatからシステムAを使う仕組み」

「GeminiからシステムAを使う仕組み」

「ChatGPTからシステムAを使う仕組み」

というように、それぞれの組み合わせを意識して実装する必要がありました。

MCPでは、システム側にMCP Serverとして共通のインターフェースを用意することで、MCPに対応したAIアプリケーションから共通の方法で利用できるようになります。

展示では、以下の資料を使って説明していました。

展示資料では、MCPを「AIが、ただ考えるだけに留まらず、色々なシステムと一緒に行動するための世界共通ルール」と説明していました。

厳密にはAI製品ごとの実装差や認証・認可の設計などもありますが、コンセプトとしては上図のようなイメージです。

※総合予約システムは会議室などの予約システム、ATLASは経理システムです。

我々ICTチームがMCPを検証する意図

ICTチーム（≒情シス）は、ネットワークやセキュリティだけでなく、多くの社内ITシステムの導入・運用にも関わっています。

そのため、生成AIが進化していった場合に考える必要があるのは、単に

「どのAIサービスを導入するか」

だけではありません。

AIから社内システムを利用することが一般的になるのであれば、

「社内システムを、AIから安全に利用できるようにするにはどうすればよいか」

も情シス側で考えておく必要があります。

2025年に検討を開始した時点では、MCPの認証・認可を含め仕様や各製品の実装がまだ大きく変化している途中でした。

一方で、将来的にAIエージェントが社内システムを操作する世界は来るだろうと考え、まずはABChatなどを利用してPoCを行い、MCP Serverを作る側・使う側の両方の知見をためることにしました。

2023年のFunction Callingとの違い

実は似たようなことは、2023年にもFunction Callingを利用してPoCしています。

LLM自身に必要なFunctionを判断させ、Web検索、天気情報、リアルタイム情報などを取得させる仕組みを作っていました。

ただし当時は、自社システムをFunction Callingから利用しようとすると、利用するFunctionの定義や、実際にAPIを呼び出す処理などを、AIアプリケーション側で個別に実装する必要がありました。MCPで面白いと感じたのは、このAIと外部システムを接続する部分に共通のプロトコルができたことでした。

システム側でMCP Serverとして機能を公開しておけば、MCPに対応したAIアプリケーションから、共通の方法でToolを発見・利用することができます。

「これは社内システムでも使えるのでは？」というところから検証を始めました。

今回作ったもの

今回のコンセプトでは、

会議終了後に発生する一連の作業を、AIとの会話だけで進める

というシナリオを作りました。

例えば定例会議が終了した後、AIが会議データから文字起こしを行い、議事録を作成します。

さらに議事録の内容から、「次回の会議室を予約する必要がある」と判断すると、AIからユーザに予約を提案します。

ユーザが「お願い」と答えると議事録の内容から参加人数や日にち、会議時間などを取得してそれにあった空き会議室を検索・予約し、その後Google Calendarへの登録も提案します。

もう一度ユーザが了承すると、Google Calendarにも予定を登録します。

つまり人間から見ると、AIと会話しているだけです。

裏側ではAIエージェントが依頼内容を判断し、文字起こし、議事録作成、会議室予約、Google Calendarという複数のMCP Serverを順番に利用しています。

展示資料のシナリオがこちらです。

なお、展示では、重要な操作の前にはAIからユーザへ確認を行うようにしました。

「会議室を予約する？」

「お願い」

というように、人間が判断するステップを残しています。

いわゆる Human in the Loop です。

AIが何でも勝手に実行するのではなく、外部システムへの変更を伴う操作では人間の承認を挟む、という考え方です。

構成図

構成図だけ見ると大げさに見えるかもしれませんが、基本的には、

AIエージェント + 複数のMCP Server

という構成です。

フロント部分はデモのためStreamlitで実装しています。

AIエージェント部分はLangChain / LangGraphとMCP Adapterを利用して構成し、LLMにはAzure OpenAI Serviceを利用しました。

ユーザから依頼を受けると、AIエージェントが接続されているMCP ServerのToolを確認し、必要なToolを判断して呼び出します。

今回用意したMCP Serverは、大きく4種類です。

• 文字起こしMCP Server
  Faster-Whisperとpyannoteを利用して文字起こし・話者分離を行います。「ABChatギジロク」のMCP Serverです。
• 議事録作成MCP Server
  文字起こし結果を受け取り、Azure OpenAI Serviceを利用して要約・議事録を作成します。同じく「ABChatギジロク」のMCP Serverです。
• 会議室予約MCP Server
  社内の総合予約システムがMCP Serverになった場合を想定したものです。今回のデモでは見た目だけ本物そっくりですが、実システムではなく、ローカルのJSONデータを利用したハリボテを用意しました。
• Google Calendar MCP Server
  OSSのMCP Serverを利用し、新規予定の登録などを行います。

文字起こし、要約、予約についてはFastMCPを利用してMCP Serverを実装しています。

もちろん、MCP ServerについてはStreamable HTTPを利用しています。

また、自作したMCPクライアントだけでなく、Claude Codeからも今回作成したMCP Serverを（何の変更も加えることなく）利用できます。

Function CallingでPoCしていた頃とは異なり、AIアプリケーションごとに専用の連携処理を作らなくても、同じMCP Serverを別のMCPクライアントから利用できることを実際に確認できました。

加えて、Langfuseを利用してLLMの動作をログとして追えるように設計しています。PoCはもちろん、実運用でもログを追える状態にすることは重要です。Langfuseはローカルで動作させています。

MCPのToolとResource

MCPには、モデルから処理を実行するための Tool だけでなく、クライアントがデータやコンテンツを取得するための Resource なども定義されています。

今回のPoCでは、AIエージェントが必要なToolを判断して呼び出します。一方、文字起こし結果や生成された議事録などのファイルはResourceとして公開し、MCPクライアント側から取得できるようにしました。

例えば文字起こしでは、transcribe_audio_file Toolで処理を実行し、生成されたCSV/JSONをResourceとして取得します。議事録についても同様に、要約をToolで実行し、生成されたWordファイルをResourceとして取得する構成にしています。

なお、PoCでは長時間の会議を文字起こしすると結果のJSONが大きくなり、MCP経由で受け渡すとデータが欠落するケースがありました。そのため、文字起こし結果を共有領域に保存し、transcription_idのみを次のToolへ受け渡す構成としています。

単純にAPIをLLMから呼ぶだけではなく、AI側から見た外部機能の扱い方までプロトコルとして定義されているのがMCPの面白いところだと感じました。

MCPを社内で利用するときの課題

実際に社内利用することを考えると、MCP Serverを作れば終わり、というわけではありません。

特に情シスとして重要になるのが、

認証・認可とセキュリティ

です。

PoCを行っていた2025年時点でも、リモートMCP Server向けの認証・認可仕様は整備されつつありましたが、仕様変更や各実装の差がまだ大きい状況でした。

またMCPを利用したAIエージェントでは、Tool Poisoning、Context Poisoning、認証情報の窃取など、これまでのWeb APIとは少し異なる観点のリスクも考える必要があります。

PoCでは、利用するMCP Serverを信頼できるものに限定する、最小権限にする、MCP Serverを隔離する、といった対策も検討していました。

加えて、社内システムを本当にAIから操作できるようにするのであれば、「誰がAIを使っているのか」をMCP Server側まで引き継ぎ、そのユーザが本来持っている権限の範囲だけを操作できるようにする必要があります。ただし、2026年現在では企業向けの認可仕様もかなり整備されてきていますが、AIエージェント自身のIdentityや、ユーザの代理として動作する際の権限委譲（User Delegation / on-behalf-of）についてはまだ未整備で、現在も標準化が進められています。（参考：The New MCP Roadmap / Model Context Protocol Blog）

このあたりは、今後実用化していくうえで特に重要になる部分だと考えています。

今後

今回の展示はあくまでコンセプトです。

会議室予約についても、実際の総合予約システムを操作しているわけではありません。

ただ、PoCを通して、

社内システムをMCP Server化し、AIエージェントから共通の方法で利用する

という構成そのものは十分実現可能であることを確認できました。

今後、ABChatだけでなくGeminiやChatGPTなど様々なAIエージェントが業務の入口になっていく可能性があります。

そのときに重要になるのは、社内システム側にAIから利用できる共通のインターフェースを用意しておくことだと考えています。

認証・認可やセキュリティなど、実運用に向けて考えるべきことはまだまだありますが、引き続き検証していきたいと思います。

まとめ

今回は、MCPを利用してAIと社内システムをつなぐ「ABChat Linkコンセプト」をご紹介しました。

今回作ったもののポイントは、単純にAIから一つのシステムを操作したことではありません。

文字起こし、議事録作成、会議室予約、Google Calendarといった異なる機能をそれぞれMCP Serverとして分離し、AI自身が必要な機能を判断しながら一連の仕事を進めたところにあります。

「AIに質問して答えてもらう」から、「AIと会話しながら仕事そのものを進める」へ。

そんな働き方がどう実現できるのか、ICTチームとして引き続き検証していきたいと思います。