さくらのクラウドMCPの開発
はじめに
はじめまして、さくらインターネット2025年度新卒入社の前田雄作です。新入社員研修の一環として、さくらのクラウド向けのMCPサーバの実装を行いました。本記事では、実装したMCPサーバの機能と利用方法・応用事例について紹介します。公開リポジトリは以下になっております。
前提：MCPサーバについて
はじめに、MCPサーバとはなにかについて紹介します。
Model Context Protocol（以下、MCP）とは、LLMが外部ツールやデータソースにアクセスできるようにするオープンプロトコルです。またMCPサーバとは、MCPを利用してAIが外部のツールやデータソースと連携するための仕組みを提供するサーバーのことです。
従来のLLMでは、各LLMの学習データの範囲内でしか回答を生成できませんでした。MCPに従って実装されたサーバを使用することで、リアルタイムにデータベース・API・ファイルシステムなどの外部リソースにアクセスし、適切にリソースの操作を行うことができるようになります。
さくらのクラウドMCPサーバとは
今回実装したさくらのクラウドMCPサーバは、LLMとさくらのクラウドのAPIの間に立って、以下の機能を提供するMCPサーバです。
- リソース管理機能
- 情報取得機能
- 監視・分析機能
使用に必要なソフトウェアや、構築手順などにつきましては、リポジトリのREADME.mdを参照してください。
技術仕様
技術スタック
- 使用言語：Python
- フレームワーク：FastMCP（MCP実装のデファクトスタンダード）
- テスト：pytest（各ツールの動作確認とエラーハンドリング）
アーキテクチャ
システムは以下の流れでリクエストを処理します。
- ユーザーがClaude Desktopにプロンプトを入力
- LLMが適切なツールを選択
- MCPサーバーがツールを実行
- さくらのクラウドAPIにアクセスしてリソース管理やドキュメント取得を実行
すべてローカル環境で動作し、MCPサーバーがLLMとさくらのクラウドAPIの橋渡し役を担います。
実装済み機能一覧
さくらのクラウドの主要機能をMCP経由で操作できるよう、以下の機能を実装しました。
リソース管理機能
- サーバー管理：作成、削除、起動、停止、情報取得
- ディスク管理：作成、削除、アタッチ、デタッチ
- スイッチ管理：作成、削除、設定変更
- VPCルーター管理：設定情報取得、トラフィック監視
情報取得機能
- 料金情報取得：各種プランの料金一覧表示
- マニュアル検索：さくらのクラウドドキュメントからの情報取得
- ゾーン情報取得：利用可能なゾーン一覧表示
監視・分析機能
- リソース状況監視：稼働状況やパフォーマンス情報の取得
- ネットワーク分析：VPCルーターのトラフィック分析
使用例
料金一覧の取得
Claude Desktopで「さくらのクラウドの料金一覧を教えて」と入力すると、MCPサーバーが自動的にAPIから最新の料金情報を取得し、構造化された形で表示します。
マニュアルからの情報取得
「さくらのクラウドでルーターを作成する手順を教えて」のような質問に対して、MCPサーバーがマニュアルから該当情報を自動取得し、手順を分かりやすく説明します。これにより、マニュアルを手動で検索する時間を大幅に短縮できます。
サーバーの作成
「東京第1ゾーンにWebサーバー用のインスタンスを作成して」という指示に対して、MCPサーバーが利用可能なプランを提案し、ユーザーの確認後に実際にサーバーを作成します。作成完了後は詳細情報も表示されます。
応用事例
事例1：他社クラウドサービスとの料金比較
さくらのクラウドMCPサーバと同様に、AWSとGoogle CloudにもそれぞれMCPサーバが実装されています。これらと連携することで、同じスペックのサーバを構築した場合の料金比較を自然言語で指示・自動化することができました。
例えばプロンプトとして以下の文面を入力します。
さくらのクラウドとAWSとGooglecloudでの最小構成時の料金を無料期間を省いて、比較してください。
利用したゾーン情報も一緒に記載してください。すると以下の結果が返ってきます。
※構成を伝える際は、詳細情報を伝えないと意図しない値が表示される場合がございます。
事例2：既存環境のTerraform化
TerraformのMCPサーバであるterraform-mcp-serverと連携することで、稼働中のVMやネットワーク構成を自動的にTerraformコードに変換することができます。既存環境をTerraformに変換することで、検証で建てたVM群をIaC化することができます。
今回はTerraform化のテストを兼ねて東京第1ゾーンに構築した構成を東京第2ゾーンへ移行してみました。まず東京第1ゾーンに構築した環境、およびVPCルータのNAT設定とファイアウォール設定を下図に示します。
入力したプロンプトは以下の通りです。
さくらのクラウド、東京第1ゾーンで起動しているVM,VPCルータ, スイッチがあると思います。
これらの構成及び、VPCルータのFW, NAT, DHCPの設定を再現するterraformを作成してください。
なお、作成するterraformのゾーンは東京第2ゾーンとしてください。このプロンプトでTerraformのコードを作成してくれますので、それを実行すれば東京第2ゾーンに同じ環境が構築可能です。実際に実行して東京第2ゾーンに構築したものを下図に示します。
※実行できるTerraformファイルになるまで、Claudeとのやり取りが4回必要でした。
このように、VPCルータのNATやファイアウォールの設定を含めてTerraformに落とし込むことができました。なおDHCPの設定も移行できましたが、そちらの画像は割愛します。
今回は、さくらのクラウドにおけるゾーン間移行をTerraformで行いましたが、別のクラウド会社の構成をさくらのクラウド上に再現するための中間表現としてTerraformを利用できると考えています。
事例3：タグ機能を用いたVM一括コントロール
VMに記載したタグを用いて、あるタグが付いているVMを一斉に起動・終了することができます。例えばdevタグを付けたVMを作業終了時に一斉終了するときに利用できます。タグ機能についてはこちらをご覧ください。
ここで以下のプロンプトを入力します。
devタグが付いているVMを停止してくださいプロンプトと停止作業を行っている様子は以下のようになります。
作業完了後のサーバ一覧画面を見ると、devタグが付いたVMのみ停止状態になっています。
今後の展望
今回の研修を通じて、MCPサーバーの実装とその応用可能性を確認することができました。今後は以下の展開を検討しています。
機能拡張
現時点でさくらのクラウドMCPサーバは、さくらのクラウドのAPIを網羅していません。さくらのクラウドの全APIへの対応拡大を軸として、以下の3点を開発・機能拡張していきます。
- さくらのクラウド全APIへの対応拡大
- より高度な自動化機能の実装
- 他のさくらインターネットサービスとの連携
コミュニティ展開
さくらのクラウドのMCPサーバはOSSとして公開されます。継続的な開発とメンテナンス、UXの向上のため、コミュニティの形成・展開を目指し、以下の3点を実行していきます。
- オープンソースプロジェクトとしての継続的なメンテナンス
- ユーザーフィードバックを基にした改善
- 活用事例の蓄積と共有
MCPサーバ開発研修の振り返り
このMCPサーバは新入社員研修の一環として開発しました。ここからは開発研修の振り返りをしたいと思います。
開発体制
今回の実際の開発期間は一週間（実質4日）でした。この短い期間でより良いものを作るために、開発体制は以下のようなチーム編成ということになりました。これまでの研修では9人を3グループに分割などして取り組む課題が多かったので、9人全体で一つの物事に取り組むのは実は最初で最後ということになります。そういった特別感もなかなか味わい深いものでした。
| チーム名 | 人数 |
|---|---|
| 全体統括リーダー | 1名 |
| MCPサーバ開発 | 5名 |
| 応用事例考案 | 2名 |
| 記事執筆担当 | 1名 |
まず全体統括リーダーは、今回開発したMCPサーバがそのままOSSとして社外に公開されるということで、社内のOSSチームとの折衝を担いチーム全体の管理を行いました。次にMCPサーバ開発チームは、実際の開発を行う精鋭チームです。彼らの開発スピードの速さには驚かされましたがそれはまた後ほど詳細に書きます。応用事例考案チームは、「MCPサーバって一体何ができるのか」「そもそもMCPサーバの基本要件」などの点について、さまざまな検証と要件決定を行っていました。最後に、このぽつんと浮いた記事執筆担当が私で、Zoomの部屋を行ったり来たりしながら話を聞いて記事執筆に勤しみました。
新卒エンジニア総勢9名はこんな体制で開発をスタートし、無事にMCPサーバの基本形を完成させることができました！ 実際にできたもののソースコードや解説記事も執筆していますのでぜひご利用いただければと思います。また、コントリビュートしてくださる方も大歓迎ですのでよろしくお願いします！
開発スピードが高速すぎる
開発体制で書いた通り、我々はこの開発期間で大まかに2チームに分けました。開発チームと応用チームです。
当初、我々のチーム編成の意図として、「応用チームが必要な機能を考案して、開発チームに渡す」というものがありました。「開発期間は限られているから、開発チームはなるべく基本的な機能を作っていこう」「応用チームは限られた期間内でできそうな機能を洗い出して、開発チームに渡していこう」この2つをコンセプトに持っていたわけです。
チーム分けの後、2日目の開始時点ではそもそも開発するべき基礎機能はかなり広範にわたり、応用と言える範囲に行き着くのはかなり時間がかかるだろうという想定の下でスタートしました。
応用チームはひたすら頭を悩ませていたのです。「MCPの基礎機能ってなに？」とか「この機能、開発が間に合わないかも」、あるいは「MCPでこういった機能はできるのか」を中心に、応用的なMCPの機能の検証を必死にしながら。
一方その頃、開発チームはといえば、想定を上回るペースで開発を進め、2日目の夕方の時点でもうすでに最初に想定していた機能の実装はほとんど済ませ、いつの間にやら新しい機能の開発にも着手していました。応用チームの悩みもいざ知らず、開発に導入した生成AIによって開発速度は光速を突破してしまい、気づいたときにはむしろ「他に開発する機能ありません？」と逆に聞き出す始末です。開発を統括していた人がZoomの部屋をまたいで聞きに来たときの応用チームはまさに鳩に豆鉄砲という感じで、「え、じゃあもっと機能要求していいのか!?」とひっくり返っていました。
おまけに、応用チーム側が爆速で開発されていた基礎機能に気づかなかったことで、応用チームが検証用に似たようなMCPサーバを作ってしまうなどということもありました。
応用・開発チーム間でのやり取りが当初は希薄だったことや、応用側が頭を悩ませている間にリポジトリの様子を観測していなかったことが原因でした。記事執筆のために私がグループの間を橋渡ししていたので、こちらからちゃんと連絡をするべきだったなと思うばかりです。
そしてこのあまりに速い開発速度は、応用チームに限らず開発チーム内でも悪い方向で発揮されてしまうのでした――。
車輪の再発明
開発チームはTiDD（チケット駆動開発）を採用していました。これは、必要な機能やエラーごとにチケットを作成し、担当者を割り当てることで開発の重複や二度手間を防ぐ手法です。リポジトリをGitHubで管理していたので、GitHub ProjectとIssueを活用してTiDDを実現しました。
この運用により、チーム全体としては概ね順調に開発が進んでいました……が。
ある一人の開発者の開発速度があまりにも爆速すぎたため、システムが微妙に機能しなくなってしまいました。「この機能の開発は……あ、もう彼がやってた」「よし、開発できたぞ！みんなのところに持っていこう……あれ、なんだもう彼がやっていた」といった状況が頻発。この現象があまりにも特徴的だったため、原因となった開発者の名前を冠した一種のミームとして新卒の間で定着しました。
さらにこの状況は加速を続け、なんと「開発されたことにすら気づかれず、全員が画面共有している中でも気づかれず、プルリクエスト作成のタイミングでようやくすでに開発されていることに気づいた」といった事態も発生しました。車輪の再発明を防ぐためのチケット駆動開発が機能せず、本当に車輪の再発明をしてしまったというオチでした。
原因としては、Issueを誰が担当しているかを対話上で管理し、後からGitHub上のAssigneeに割り当てていたことでタイムラグが生じていたことでした。ちゃんと使っているシステムに逐一担当者を割り当ててやっていこうね、という反省を得ることができました。
おわりに
5日間という短期間でのMCPサーバ開発は、技術的な挑戦だけでなく、チーム開発の難しさや楽しさを存分に味わえる体験でした。開発チームと応用チームに分かれての作業は、それぞれ異なる視点から同じプロダクトに向き合う貴重な経験となりました。
エラーとの格闘、重複実装の発見、細かいバグでの時間ロス……開発にはつきものの苦労もありましたが、それも含めて良い思い出です。新入社員らしい等身大の開発体験として、この記事が今後同じような研修に臨む方々の参考になれば幸いです。