はじめに
IT インフラ本部の大山裕泰です。
このたび Pagoda と AI (LLM) とを連携する mcp-pagoda を OSS としてリリース しました。
Pagoda は DMM.com のインフラ部が、当時の情報管理の課題を解決（さまざまな主体で多重・分散管理されていた情報を整理・統合）するために開発された情報管理サービスです。 運用用途に応じて任意のデータ構造を定義でき、また他の情報との関連付けや検索がし易いといった特徴を持ち、これによって、情報の統合管理（SSoT）を DMM.com 社内で実現しています。
そして今回ご紹介する mcp-pagoda により、情報を活用したい利用者の求めに応じ、AI が自ら考え、自律的に Pagoda に登録されている情報を活用してくれるようになります。
具体例の一つとして、以下のように Pagoda に登録されたサーバの搭載情報から、
次のネットワークの構成図を LLM に生成させるといったことができるようになります。
本稿では、SSoT の取り組みと AI 連携（mcp-pagoda）に至る経緯と目的、そして結果についてまとめました。
SSoT とその課題
SSoT とはつまるところ（一言で言うと）「情報を集約させ、効率・効果的に活用できるようにする」ことです。
なぜそうするのか？
これを論理的に説明することは困難ですが、経験的・実践的に説明することは簡単です。 人にしろ、物にしろ、お金（資本）にしろ集約させると効率・効果的になります。
例えば、大きな家具や家電がある家の片付け・引っ越しをする場合、３人で行えば、１人で３倍の時間をかけるよりも短時間で済ませられます。 また、小規模な生産設備しかない工場がそれぞれ生産するよりも、大規模な生産設備がある工場の方が、安くて多くのものを生産できます。 さらに高速鉄道や高速道路の建設効果や、都市型経済の発展など、リソースを集約させることによって、機能が効率・効果的になる実例は多数あります。
SSoT の発想もこれと同様です。つまり、情報を集約させることによって、目的（ビジネス＝顧客の満足）を効率・効果的に達成することを目指します。
活用できなきゃ意味がない
SSoT を実現する手段は様々あります。単純な情報の管理であれば、スプレッドシートでも行えるでしょう。しかし管理対象が多く、また運用も複雑であれば、それを行う専用のシステムを利用する場合が一般的です。
例えば、IT 機材情報の管理の場合、当該機材がどこに設置され、誰が利用している（あるいはしていない）のかといった状態から、 それが何の用途で使用されているのかといった性質について、さらには資産情報との紐付けも会計上必要となります。
実際のシステムの運用では機材は単体で稼働することはほぼあり得ません。
各機材の情報に関連する、以下のような物理・論理構成情報の管理も運用上必要になります。
- 物理構成：機材のどのポートから、どのような媒体（光ファイバー・イーサネットなど）を通じ、どこを経由して、最終的にどの機材のどのポートに接続しているかなど
- 論理構成：どの VLAN、ネットワークに属し、どのIP アドレスが付与されているかなど
加えてこれらの割り当て、そして廃棄といったライフサイクルを管理する必要もあります。
さらに機材の運用にまで視野を広げると、その機材でトラブルが生じた場合の担当チームがどこか。また実際にトラブルが生じた場合には、 具体的にまず誰に連絡すべきで、その連絡手段と連絡先。そして連絡がつかなかった場合、次に誰に連絡するかといった情報も関連して管理・運用する必要が生じてきます。
Pagoda での SSoT
Pagoda では、利用者が任意の型のデータ構造（モデルとアイテム）を自由に定義でき、統一的な情報管理をしつつ、あらゆるニーズに対応できる仕組みを提供しています。
(c.f. https://inside.dmm.com/articles/pagoda_release/ )
実際に DMM の IT インフラ本部で管理する情報の多くは Pagoda によって管理されています。
その対象や目的は、以下のように様々あります。
- サーバ（機材）やネットワークの管理・運用に関する情報の取得・管理
- アプリケーションサービスのデプロイに必要なインベントリ情報の管理
- サービスのドメインの管理や、あるドメインにアクセスした場合にリクエストを受ける LB 配下にどのサーバが格納されているかの把握
- システムトラブルが発生した場合の連絡先の輪番表の把握や、その更新（長期休暇における輪番変更など）
具体的にこうした情報を格納した際に、どのように利用できるかについて Pagoda デモサイト から実際に見て・触れることができますので、ぜひ試してみてください。
以下は、Pagoda デモサイト での機材情報と、障害連絡の輪番情報の確認・更新する様子です。
Pagoda の課題
Pagoda では カスタムビュー という仕組みにより、 格納されている特定のモデル配下のアイテムと、それと関連するアイテムを取得し、特定のビジネスニーズに対応できるようにしています。
例として「データセンタに設置されているラックに、どれだけの機材が格納されているか、あるいはどのラックに空きスペースがあるかを網羅的かつ視覚的に確認できるようにする」といった要望に対応する場合を想定します。
この場合、以下のようにある拠点（データセンタ）のフロア中のラックに格納されている機材の情報を一覧で表示させるページを開発します。
このページでは、拠点のフロア、ラック、そしてラックに格納されている機材といった、複数のモデルに跨るアイテムを取得し、その結果を描画する処理を行なっています。
このように特定のビジネスニーズに対応するため、モデルごとに特定の処理を行うプログラムを動的に拡張できる仕組みが Pagoda のカスタムビューになります。
しかしこうした形の機能拡張は、ニーズが生じてから実際に利用できるまでの期間（タイムラグ）が発生してしまいます。理由は機能の開発が発生するためです。
通常、「機能」が「要求」よりも先に発生することはありえません。世の中の製品やサービスは、何らかの目的を達成するために生じるもので、目的を達成するために要求が生まれ、そこから機能が作られるためです。
従来のプログラム開発は、要求分析から始まり、そこから要件を定義し、アプリケーションの実装・テスト開発を経て、完成したプログラムをデプロイしてようやくユーザが使える状態となります。 さらに通常ここからユーザからのフィードバックを経て、改良するサイクルが回ります。そしてこのサイクルを１周するのに、おおむね数週間（大規模で複雑な仕様のものでは数ヶ月）程度の期間を要します。
また、コンピュータプログラムも（これは多くの人が誤解していることだと思いますが）家や道路などと同じ人工物であり、きちんとメンテナンスをしないと、いづれ使えなくなってしまいます。 そしてメンテナンスにはお金（コスト）が掛かり、コストは規模に比例します。
つまり、情報を集約（SSoT を実現）させたとしても、集約させた情報を活用できなければ意味がなく（目的は果たせず）、目的を果たすためには用途に応じた機能開発が必要となります。 また機能開発には時間がかかり、開発した機能を維持するにもお金が掛かるというのが現実（課題）です。
これは Pagoda 固有の課題というよりも、情報管理システム一般に言える課題と言えます。
AI に一縷の光明を見出す
このことから、機能を開発せずに（あるいは少ない機能で）要求を実現させることができれば、先の２つのコスト（時間とお金）が掛かる問題を解消できそうです。 機能開発をせずに要求に応じるとは、従来のシステム開発の常識からすると、およそ非現実的なことに思えますが、AI 技術（特にLLM）の活用によってこれを実現できると予測し取り組んできました。
折しも 2024年11月に Anthropic 社が Model Context Protocol (MCP) 技術を発表したことで、AI 技術がさらに一般化し、 そしてその恩恵が一般ユーザに届きやすくなった（ブレイクスルーが起きた）ように思います。
MCP とは？
MCP は 2025 年の AI (LLM) 技術トレンドを席巻した技術であり、多くの注目を集め多数の解説記事があるため、MCP 技術自体の解説は割愛いたします。
一言で説明すると、MCP は以下の２つの仕組みを LLM 非依存に実現する仕組みを提供します。
- 従来の RAG (Retrieval-Augmented Generation) と呼ばれる LLM に外部システム情報を認識させる仕組み
- LLM が外部システムに対して操作する（いわゆる「自律化」や「エージェント化」の）仕組み
どんなに賢い推論能力を持つ LLM といえど、事前に学習した以上のことは知りません。ChatGPT に会社で管理している機材の情報を尋ねても期待する回答は得られません。 ましてや、機材のセットアップを指示して、その通り設定してくれるわけもありません。
しかし、MCP Server を利用することで特定の LLM を特定のシステム（例：Pagoda）と連携させることができ、上記のようなことも実現できてしまいます。
mcp-pagoda を使ってみる
ここでは、冒頭でご紹介しました mcp-pagoda を利用した例をご紹介します。
先ほど述べた「課題」のくだりにて「非現実的」と述べた、システム開発をしないニーズへの対応を実践してみます。
以下の Pagoda デモサイト に登録されているラックに搭載されている機器の情報に基づき、
LLM にネットワークの構成図を作図させます。
当然、そうした機能は Pagoda 側では開発されていません。このように LLM を活用することで、ユーザの要求を実現する機能を Pagoda 側で開発しなくとも LLM がよしなに実現してくれるようになりました。
これにより Pagoda に格納された情報の活用が飛躍的にし易くなると共に、Pagoda に情報を集めれば集めるほど、様々なニーズへの対応がし易くなるため、SSoT の重要性と効果がより高まると考えます。
さいごに
ここで述べた内容は、Pagoda に限らずどの SSoT で行っても実現できる内容ではありますが、本稿執筆時点で MCP 連携ができる SSoT システムはまだ少ないように思います。
また我々は、Pagoda によって我々自身（DMM のインフラ運用）の課題を解決してきて、更なる改良と安定稼働を目指しています。 そのためにはナレッジの獲得が不可欠であり、ナレッジを獲得するには実際に使ってもらう他はないと考えています。
そのため我々は、Pagoda 自体を OSS 化 し、さらに Pagoda を気軽に（事前登録なしで）触ってもらえるようにするための デモサイト を無償公開してきました。 そしてこの度、Pagoda 用の MCP Server mcp-pagoda を OSS として公開いたしました。
これを機に、より良い情報管理を一緒に目指し、苦楽を共にできる仲間（パートナー）を探しています。 「仲間」ですのでお客様（クライアント）とは違った形での関係構築を図りたいと考えています。 つまり、情報管理をより良くする共通の目的のもと、我々が情報管理をより良くするためのサポートを提供し、お金ではなく「ナレッジ」をご提供いただける方と中・長期的な関係構築を目指します。
もし共感頂ける方、あるいは Pagoda に興味があるという方がいらっしゃいましたら、Pagoda お問い合せフォーム からご連絡ください。
