生成AI と Model Context Protocol サーバーによる 5G コアオペレーション自動化の取り組み紹介〜Interop Tokyo 2025〜

こんにちは、イノベーションセンターの福田です。 NTT コミュニケーションズ株式会社は、日本最大級のネットワーク展示会である「Interop Tokyo 2025（会場：幕張メッセ、会期：2025年6月11日〜13日）」において構築される ShowNet に対し、生成 AI と Model Context Protocol (MCP) による 5G コアオペレーション自動化のコントリビューションを行いました。

本記事ではその構築にあたって具体的にどのようなことを開発したのか、その実装を通して得た知見やノウハウを紹介します。

背景
どんなことをしたのか
Model Context Protocol (MCP) とは？
- サーバー・クライアント・ホスト
アーキテクチャ
動かしてみてわかったこと
- MCP を利用することによるメリット
- MCP を利用する上での注意点
  - MCP のツールの網羅性
  - MCP のツール名について
まとめ

背景

5G コアで設定するパラメータは標準の識別子や設定項目を網羅的に対応しようとすると、多数のパラメータ管理が必要になります。さらにいくつかのパラメータを中心とした依存関係が形成されており、その依存関係にしたがって設定値を更新したり削除したりしなければなりません。

今回、この 5G コアのパラメータを生成 AI で全部あるいは一部を変更することを立案し、生成 AI によるオペレーション自動化にチャレンジするということになりました。

どんなことをしたのか

こうした背景から、生成 AI が既存データから必要なデータの構造や値を把握して、オペレータの指示する通りに 5G コアのパラメータを処理する仕組みを作ることになりました。

まず始めに生成 AI の動作環境とモデルについて決めました。今回、 5G コアの環境が Amazon Web Services 上で構築されるため、そちらに合わせて Anthropic PBC の Claude や Amazon.com, Inc. の Amazon Nova といったさまざまなモデルが利用可能である Amazon Bedrock を用いました。生成 AI のモデルは Anthropic PBC が提供する Claude 3.7 Sonnet を用いることにしました。

当初、以下のサービスや機能を組合せて実現しようとしていました。

Amazon Bedrock にて機能提供されている Amazon Bedrock Agents による AI エージェント
Amazon OpenSearch Service による Retrieval-Augmented Generation を組み合わせた構成を検討しました。

これらのマネージドサービスを用いることで開発工数を抑えながら、事実(既存のパラメータ)に基づいた生成ができると考えたためです。なかでも Amazon Bedrock Agents には AWS Lambda の関数を設置し、その関数を事前に定義したパラメータで呼び出すことができるという機能があります。始めはこの機能を用いることで必要なパラメータをやり取りすることを検討していました。ところが、先述したとおり、 5G コアのパラメータ数が非常に多く用途毎に設定がわかれていました。そのため、命令の度に柔軟にパラメータ数を幅広く増減させる必要があるのに対し、 Amazon Bedrock のパラメータ定義はデフォルトで5つしか設定できず(※ある程度上限緩和は可能)柔軟さに欠けることが判明しました。

そのため Amazon Bedrock Agents の代替手段の調査にのりだしました。その中で昨今ホットな話題である MCP を用いることで柔軟にツールの利用やコンテキストの提供を実装可能だということがわかってきたため、 MCP での実装に切り替えました。

その結果 MCP を用いて 5G コアのパラメータを生成 AI が生成・設定可能な構成が実現しました。さらにオペレータ側が自然言語による指示を実施すると生成 AI の方でその指示に合わせて各種パラメータ操作のオペレーションを実施するサービスを実装することに成功しました。以下ではその実装を通して得られたノウハウや実際の構築例を通して MCP の使い所について共有します。

Model Context Protocol (MCP) とは？

まず、本題へ入る前に何度か出ている Model Context Protocol (MCP) について知らない方向けに解説をします。もしすでにご存知であれば本章は読み飛ばしていただいて構いません。

Model Context Protocol (MCP) は Anthropic PBC が提唱する、 AI モデルが各種サービスやさまざまなドキュメントへのアクセス、写真や画像といったものを統一して扱えるようにするためのオープンなプロトコルです。

Anthropic PBC は公式ドキュメントの中で AI 用の USB-C ポートという表現を用いていますが、まさしくその表現の通り AI モデルがさまざまなものへアクセスするのに使用する統一的なインターフェースを提供します。

Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.

ref: Model Context Protocol - Introduction

最近では AIOps という AI によるシステムの運用を自動化するパラダイムが提唱されていますが、日々さまざまな機能の開発や改修が行われているサービスやシステムを AI が扱うにはそれらのサービスのさまざまな操作方法や知識を AI も取り込まなければなりません。

そこで AI モデルを開発する各社では生成 AI にツールを操作させたりコンテキストを提供する方法を提唱しています。たとえば ChatGPT を提供する OpenAI では Function Calling という AI がツールを呼び出すためのインターフェースを定義しています。 MCP もそのうちの1つですが、 Function Calling が構造上、生成 AI の実行環境に合わせてその処理フローを実装する必要があるのに対し、以下に説明するクライアント・サーバーの構造を取ることで個別の処理フローを実装する必要がなくなっています。

サーバー・クライアント・ホスト

MCP は以下の3つのコンポーネントからなります。

サーバー
- AI が利用したいサービスやシステムに MCP で通信させるためのインターフェースを提供する
クライアント
- サーバーと接続するためのインターフェース
ホスト
1. IDE などの MCP を利用した処理を行うプログラム

ref: https://modelcontextprotocol.io/introduction

これらはアプリケーションやコンテナーで1つにまとめられる場合もあれば別々に運用されることもあります。これらを適切に実装・提供して組み合わせることで AI がさまざまなシステムやサービスを操作できるようになります。

アーキテクチャ

ここまで MCP について解説しました。本項ではこの MCP を実際に 5G コアオペレーション自動化のミッションを解決するにあたってどのようにシステムに組み込んでいったのかをアーキテクチャの観点から解説します。

今回我々が自動化するにあたって作ったシステムは次の通りです。

5G コアのパラメータは Amazon Relational Data Service へ保管されており、その DB 自体は 5G コアが操作するものであったため直接書き込み操作はせず、変わりとして GitLab 上にパラメータが設置してあり、そのパラメータを操作すると 5G コアに設定が同期するようになっていました。

そこで、 DB については直接書き込みをしないようにリードレプリカを作成し、ここから最新の 5G コアパラメータを取得できるようにした上で生成した 5G コアパラメータを GitLab へ書き戻す、という構成をとることになりました。

この構成を元に、我々は以下のコンポーネントでオペレーション自動化システムを作成することにしました。

DB のリードレプリカから 5G コアパラメータを取得する REST API サーバー
オペレータが生成 AI とやりとりし、生成 AI が指示された内容をもとに REST API サーバーや GitLab を操作する MCP ホスト
AI モデルを提供する Bedrock

このうち、 REST API サーバーは Amazon Elastic Kubernetes Service (以下、 EKS) を構築し、その上でサービスとして公開しました。

サービスは同一ネットワーク上からアクセスできるように Elastic Load Balancing における Network Load Balancer を使ってネットワーク内に公開しました。

また、 MCP ホストはパブリックな場所に Amazon EC2 のインスタンスを設置し、その上に Docker Compose 化して動作させました。これによってユーザーがインターネットを通してインスタンスから MCP へアクセスできるようにしています。

今回、 REST API サーバーと MCP ホストは元々ローカル環境で開発・検証しやすいようにコンテナー化して Docker Compose にて検証基盤を立ち上げて検証できるようにしていました。本来であればこの Docker Compose 環境と同じように EKS や Amazon Elastic Container Service で REST API サーバーと MCP ホストを配置すると思います。ですが今回は短い期間で上記環境を動作させねばならなかったことや頻繁に変更を伴う検証をしながら実装したため、実装・スケジュール優先で確実に実現できる形で実施しています。

動かしてみてわかったこと

今回上記環境を構築してみていくつかわかったことがあるため紹介します。

MCP を利用することによるメリット

今回、 MCP を実装・利用してみると、実際に Anthropic が述べているような MCP は USB-C のようなものであるということが実感できました。 MCP 自体はまさしくさまざまなシステムを AI が操作しやすくするための標準化手法であり、その点こそ利用することのメリットになっていることを実感しました。

システムがどんなツールを提供しているのかや、どんなコンテキスト情報を与えられるのか、システムを上手く使うためにはどのようなプロンプトを提供する必要があるのかといったことを統一されたインターフェースで提供します。これによって AI は各システムの実装差異であったりインターフェースの違いといったものを意識せずに統一した方法でアクセスできます。ちょうどプログラミング言語におけるインターフェースと同じように中身を知らなくてもその操作方法さえわかってしまえばいいわけです。

MCP そのものは新しい技術ではなく既存技術の組み合わせで実現されているため、技術的な部分で押さえておかなければいけないところは少ないです。ですが、標準化によって生成 AI が事前に知識がなくてもシステムを操作できることが示されたというところは押さえておく必要があります。

MCP を利用する上での注意点

MCP のツールの網羅性

実装途中で気付いたのですが、生成 AI が MCPでシステムを上手く操作できるかは、 MCP サーバが提供するツールの網羅性に左右されます。

たとえば今回使用した GitLab MCP Server でその網羅性が問題になりました。今回、生成 AI が GitLab のリポジトリーからファイルを探索する際にファイルの中身を取得する API を使っていました。この API はディレクトリー名を指定すると 404 Not Found を返すような仕様になっていました。このエラーを生成 AI はエラーがあったという事実だけを見てしまい、ファイル探索ができないと判断して所望のファイルを取得するところまで実施せず、探索を打ち切ってしまうようになっていました。その影響でファイルが検索できずに新しい探索タスクを再度実施するという事象が発生するようになっていました。そのため、パラメータ変更操作のようなファイルを特定する探索タスクがあるとその探索途中にエラーを認識しては再度探索をためすという操作を繰り返してしまい、全体として操作にかかる時間が長くなってしまうという事象が発生しました。

そこで我々の方で GitLab MCP Server へファイルをリストするツールを実装してみました。すると生成 AI 側で探索タスクの処理内容を以下のように変更してくれました。

リストするツールを用いてファイルの位置を把握
ファイルの中身を取得する API を実行

これによってファイルの中身を取得する API でディレクトリー名を指定してエラーになるのを防ぐことができました。さらにエラーの発生が抑えられることで探索の繰り返し頻度も少なくなり、生成 AI が実施する探索の時間を非常に短く抑えることに成功しました。

このように、提供される MCP サーバーのツールに網羅性がないと生成 AI は期待通りにシステムを操作してくれません。さらに生成 AI が別の方法を試そうとするも提供できるツールは同じであるために何度も同じツールをつかってエラーを発生させるということを繰り返すようになってしまいます。もし MCP サーバーを実装する場合は生成 AI にどんな操作をしてどんな値を返し、どんなエラーを返すのかというところを洗い出しておく必要がありあす。

MCP のツール名について

今回実装してみてツールの名前には名前空間の概念がないことに気が付きました。そのため、 MCP サーバー側は提供するツールの名前衝突に十分気を付ける必要があります。

GitLab MCP Server を参考にすると、以下のようにツール名で switch している箇所が見受けられます。

/**
 * ref: https://github.com/modelcontextprotocol/servers-archived/blob/9be4674d1ddf8c469e6461a27a337eeb65f76c2e/src/gitlab/index.ts#L420-L500
 */
switch (request.params.name) {
  case "fork_repository": {
    // ツールの処理
  }
  case "create_branch": {
    // ツールの処理
  }
  // ...
}

たとえば MCP サーバー A がツール名 tool_a を持ち、同時に MCP サーバー B が同じツール名 tool_a を持っている状況で、双方を利用するように設定している場合は、クライアントが正しくツールを使い分けられない可能性があります。

MCP の中には各ツール定義でツールの説明を定義する description というものがあり、こちらを活用することでどういったツールなのかを生成 AI にヒントとして与えることができます。内容が適切に設定されていれば AI も呼び出すツールを使い分けてくれるはずですが、実装・運用の際には利用する MCP サーバーの各 descirption の重複には気を付けておく必要があります。

/**
 * ref: https://github.com/modelcontextprotocol/servers-archived/blob/9be4674d1ddf8c469e6461a27a337eeb65f76c2e/src/gitlab/index.ts#L363-L369
 */
return {
  tools: {
    {
      // ツール名
      name: "create_or_update_file",
      // ツールがどんなツールなのかの説明
      description: "Create or update a single file in a GitLab project",
      // ツールが受け取るパラメータのスキーマを定義
      inputSchema: zodToJsonSchema(CreateOrUpdateFileSchema)
    },
    // ...
  }
}

まとめ

本記事では 5G コアのオペレーション自動化のノウハウや知見と、その中で実感できた MCP の実体とその注意点について紹介しました。

今回、 MCP によって GitLab の操作や DB からのパラメータ取得を統一したインターフェースで扱えるようになり、実装にかかる時間が少なく済み、提供まで短い期間でありながらもシステムを構築して提供できました。本来であればシステム毎に API を調査したり、その API を組み合わせて目的を達成するためのコードを書く必要がありますが、 MCP のツールという形によって生成 AI へ提供することで生成 AI 側が実現したいことに合わせてツールを組み合わせて呼び出してくれるため、こちらが作らなければならない API を少なく済ませられました。

また、実際に構築してみることで、以下の MCP の実装における注意点や良い部分などを知ることができました。