ここはMCPの夜明けまえ

本日、「AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒」というイベントで「ここはMCPの夜明けまえ」 🎵🧭 というタイトルで登壇しました！

🔍 イベント詳細:
- イベント名: 【ハイブリッド開催】AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒-
- 公式URL: https://hack-at-delta.connpass.com/event/350588/

📝 登壇ブログ
- 2025年4月、AIとクラウドネイティブの交差点で語った2日間の記録 #CNDS2025 #hack_at_delta
- https://syu-m-5151.hatenablog.com/entry/2025/04/24/113500

Transcript

1. ここはMCPの夜明けまえ 2025/4/23 AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒- @nwiizo 30min #hack_at_delta
2. nwiizo 株式会社スリーシェイクで プロのソフトウェアエンジニアをやっているものです 格闘技、読書、グラビアが趣味 人生を通して"運動、睡眠、読書"をちゃんとやりたい 2
3. about 3-shake 3
4. We are Hiring!! 3-shakeは一緒にSRE界隈を盛り上げてくれる仲間を大募集中です！ Mobility、FinTech、通信など大規模SREを存分に経験できます （最近社内はGenAI / GPU / Kubernetesが盛り上がってます） 是非、カジュアル面談しましょう！！！！ 4
5. アジェンダ 1. MCPとは何か - 基本概念と位置づけ (5分) 2. 技術アーキテクチャ - 構成要素と通信方式 (5分) 3. 最新仕様の革新点 - Streamable HTTP、OAuth他 (8分) 4. 実装パターン - クラウド環境・社内システム (8分) 5. セキュリティ考慮事項 - 脆弱性と対策 (2分) 6. まとめ：実践への第一歩 (2分) 5
6. AIとシステムをつなぐ「USB規格」 出典: https://notion.notion.site/Notion-MCP- 1d0efdeead058054a339ffe6b38649e1 Model Context Protocol (MCP)とは 定義: LLMが外部ツール・データソースと通信する標準規格 特徴: JSON-RPC 2.0をベースとした軽量プロトコル アナロジー: AIアプリのための「USB規格」- どのAIも同じイ ンターフェースで外部接続 6
7. AIとシステムをつなぐ「USB規格」 出典: https://notion.notion.site/Notion-MCP- 1d0efdeead058054a339ffe6b38649e1 解決する技術的課題 統合コスト削減: 各LLM×各ツールの個別対応からの脱却 知識の拡張: 静的なLLM知識を動的データソースで補完 汎用性確保: 言語・プラットフォーム間の相互運用性実現 7
8. MCPの位置づけとコミュニティ オープン標準としての発展 Anthropic発案: 2023年に設計・公開 公式ドキュメントが優秀: GitHub上で仕様管理、コミュニティ主導 エコシステムの急成長 クライアント: Claude Desktop, VS Code, Cursor,nvim等 サーバー: 200+（公式+コミュニティ）ROADMAPにリポジトリの登場が明記 優位性: 特定ベンダーに依存しないエコシステムが拡大中 8
9. MCPアーキテクチャ概要 出典: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057 標準化の価値: 単一インターフェースでAIとデータ・ツールの連携を実現 3つの主要機能カテゴリ Resources（リソース） 読み取り専用のデータソース 例：ドキュメント、構成情報、リファレンス Prompts（プロンプト） ※ 任意実装 ツール利用に関するガイダンス文書 LLMへの最適な指示テンプレート Tools（ツール） LLMが呼び出す「関数」 例：情報検索、API呼出、データベース操作 9
10. MCPアーキテクチャ - Resources 出典: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057 Resources: LLMにコンテキストを提供する 基本と構造 リソースはLLMの外部データアクセスを実現 - テキスト形式とバイ ナリ形式のデータをURIで一意に識別し、AIの会話コンテキストと して活用。アプリケーション制御型設計により、クライアントが リソースの使用時期と方法を決定。人間が読みやすい名前や説明で AIの理解を促進 実装と運用 クライアントはresources/listでリソース発見、resources/readで 内容取得、購読機能で更新通知を受信。動的リソースにはURIテン プレートを提供可能。適切なセキュリティ対策と明確なリソース設 計がシステムの信頼性を確保 10
11. MCPアーキテクチャ - Prompts 出典: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057 Prompts: LLM対話の再利用可能テンプレート 基本構造と目的 プロンプトは標準化された対話パターンを定義 - ユーザー制御型の 再利用可能なテンプレートとして設計され、一貫したLLM体験を提 供。引数を受け取り、リソースから文脈を含め、複数の対話をチェ ーン化できる。各プロンプトは名前・説明・引数の構造で定義さ れ、クライアントはprompts/listエンドポイントで発見し、 prompts/getで使用。引数には名前、説明、必須フラグが含まれる 応用と実装 動的なコンテンツと複数ステップのワークフロー - プロンプトは リソースからの情報を埋め込み、複数のメッセージ交換を事前定義 して複雑な対話フローを作成可能。クライアントUIではスラッシュ コマンドやクイックアクションとして表示され、ユーザーに直感的 な操作を提供。テンプレートの更新は notifications/prompts/list_changedで通知される 11
12. MCPアーキテクチャ - Tools 出典: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057 tools: AIに実行力を与える Toolsの基本設計と役割 Toolsは LLM に実世界での行動力を与える - サーバーが公開する実 行可能な機能を介して計算処理やAPI操作を実行できる。クライア ントは tools/list で発見し、tools/call で実行する。各ツールは 名 前、説明、入力スキーマ、アノテーション という明確な構造で定 義され、動作の性質（読取専用・破壊的操作・べき等性など）をAI とユーザーに伝える 実装パターンと応用 サーバー側での リクエストハンドラー実装 がToolsを活性化し、AI の指示を具体的なアクションに変換。エラー処理や進捗報告も適 切に設計する。計算ツールからAPI統合、データ処理まで無限の可 能性 - システム操作、外部APIラッパー、データ変換などさまざま なパターンでAIの能力を拡張し、実世界での影響力を高める 12
13. MCPアーキテクチャ - Sampling Sampling: サーバーがLLMに補完を要求できるようにする。めちゃくちゃ に有用そうではあるが、Clientでは実装されていないものもある。 基本概念と仕組み サンプリングはサーバーがLLMに必要なものをリクエストできる機能 - サーバーがsampling/createMessageを要求し、クライアントがレビュ ー、LLMから結果を取得、そして結果を返す。ユーザーが介在する設計に より、セキュリティとプライバシーを確保。標準化されたメッセージフ ォーマットを使用し、会話履歴、モデル設定、システムプロンプト、コ ンテキスト含有範囲を指定。modelPreferencesで希望するモデル名や優 先事項（コスト、速度、性能）を伝達できる パラメータと制御 テンプレート、サンプリングパラメータ、人間による監視 - 様々な設定 （temperature、maxTokens、stopSequences）で出力を調整し、ヒュー マンインザループ設計によりユーザーがプロンプトと完了を確認・修正 可能。サンプリングはエージェント的ワークフローを可能にし、データ 分析、意思決定、構造化データ生成、複数ステップのタスク処理などの 高度な機能を実現。適切なセキュリティ対策とエラー処理が重要 13
14. MCPアーキテクチャ - Roots roots: Model Context Protocol (MCP)のルーツ：操作境界の定義 基本概念と役割 Rootsはサーバーの操作範囲を定義する - クライアントがサーバーに対し て関連リソースとその場所を伝える手段。ファイルシステムパス （ file:///home/user/projects/myapp ）やHTTP URL （ https://api.example.com/v1 ）などの有効なURIを使用 クライアントは接続時にroots機能を宣言し、サーバーに推奨ルーツのリ ストを提供。これによりワークスペース内のリソースが明確化され、異 なるリソースを同時に扱う際の組織化が容易に 実装と応用 サーバーはrootsを尊重してリソースの範囲特定とアクセスに活用。厳密 な制限ではなく情報提供的な役割だが、境界内での操作を優先すべき プロジェクトディレクトリ、リポジトリ、APIエンドポイントなどを定義 する一般的なユースケースで活用。効果的な運用には必要なリソースのみ 提案し、明確な名前付けと適切な変更管理が重要 14
15. MCPの通信フロー 出典: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057 利点: シンプルさと互換性を両立した標準的な通信プロトコル 初期化フェーズ クライアントが initialize でケイパビリティ宣言 サーバーが利用可能な機能を応答 リソース探索 resources/list で利用可能なリソース一覧取得 resources/get で特定リソースのデータ取得 ツール呼び出し tools/list でサーバー上のツール一覧取得 tools/call で特定ツールの実行要求 15
16. Transports 現状は標準出力(stdio)で実装しておけば良さそう STDIO Transport (Local Connection) 標準入出力を使用したプロセス間通信,ローカルツール連携に最適 LLMアプリが子プロセスとしてMCPサーバー起動 HTTP Transport (Remote Connection) 旧: HTTP + SSE (Server-Sent Events)によるそこそこ複雑な実装 新: Streamable HTTP Transport (2025-03-26) 単一エンドポイント ( /message ) 柔軟性向上としてSSEが任意 16
17. JSON-RPCによる通信方式 (1/2) JSON-RPCはXMLの代わりにJSONを使用したリモートプロシージャコールの仕組み です。2006年に初めて登場し、2009年にバージョン2.0の仕様が公開されました。 SOAPと比較して、シンプルさを重視した設計がその特徴です。 メッセージフォーマット リクエスト例: { "jsonrpc": "2.0", "id": 5, "method": "tools/call", "params": { "name": "get_weather", "arguments": { "city": "Tokyo" } } } 17
18. JSON-RPCによる通信方式 (2/2) JSON-RPCの仕様はIETFやW3Cといった標準化団体ではなく、独自のウェブサイト （jsonrpc.org）で公開・管理されています。この仕様はHTTPだけでなく、TCP/IPソ ケットなど様々な通信プロトコル上での利用を想定しており、基本的かつ共通の機能 のみが定義されています。 レスポンス例: { "jsonrpc": "2.0", "id": 5, "result": { "current": { "temp": 18, "condition": "Clear" } } } 18
19. 2025-03-26仕様の主要革新点 (1/4) 1. Streamable HTTP Transport シンプル化: 単一エンドポイント( /message )に統合 柔軟性向上: 簡単にいうと軽量になった、SSEが任意（従来は必須） TypeScript SDK で実装済み (SDKによっては未対応) WebSocket が必要な場合、不要な操作およびネットワークのオーバーヘッドが大 量に発生するので採用は見送られた #206 19
20. 2025-03-26仕様の主要革新点 (2/4) 2. ステートレスモード サーバーレス対応: AWS Lambda、Vercelなどで実装容易 セッション管理不要: 状態保持せずに動作可能 呼び出し単純化: 1回のHTTP POSTでMCPサーバー接続 従来の実装からの進化 従来: セッション毎のTransportオブジェクト保持が必要 課題: マルチプロセス環境では外部ストレージ必須 新機能: 永続化層不要、JWT等と組み合わせて認証可能 20
21. 2025-03-26仕様の主要革新点 (3/4) OAuth 2.1認証フレームワーク 認証の標準化: OAuth 2.1による包括的な認可フロー対応 実装の柔軟性: 認証は任意実装(OPTIONAL)だが推奨 HTTP: OAuthベース認証、STDIO: 環境変数経由認証 関心事の分離: プロトコル中核部分をクリーンに保持 21
22. 2025-03-26仕様の主要革新点 (4/4) Tool annotations & その他の改善 ツール注釈: 動作特性を明示するメタデータ destructiveHint (破壊的更新の可能性) idempotentHint (重複呼出の安全性) readOnlyHint (環境変更なしを示す) openWorldHint (外部エンティティとの相互作用) title (人間が読みやすいタイトル) バッチ処理: 複数リクエストの一括送信対応が必須化 マルチモーダル拡張: オーディオデータサポート 22
23. AWS MCP Servers (1/2) 出典: https://github.com/awslabs/mcp AWS Documentation MCP Server AWS公式ドキュメント検索 サービス・API・パラメータ情報取得 ベストプラクティス参照 Bedrock Knowledge Bases MCP Server カスタムナレッジベース連携 自社ドキュメント・Wiki活用 独自Q&Aデータベース 実装を見るだけで参考になることも多い。 toolのデザインや考え方が勉強になります。 23
24. AWS MCP Servers (2/2) 出典: https://github.com/awslabs/mcp CDK MCP Server AWS CDKプロジェクト支援 コンストラクト情報参照/プロパティ・メソッド詳細 Terraform MCP Server Terraformプロバイダー情報参照 リソース・データソース詳細/モジュール構造解析 Lambda MCP Server 任意のLambda関数をMCPツールとして実行 カスタムインテグレーション 24
25. kubectl-ai: Kubernetes用AIアシスタント (1/2) 出典: https://github.com/GoogleCloudPlatform/kubectl-ai 概要 Google Cloudの大規模言語モデルを活用したkubectl プラグイン 自然言語でKubernetesクラスタを操作 クラスタ状態を考慮した応答生成 MCPとしても利用可能 https://github.com/GoogleCloudPlatform/kubectl-ai 25
26. kubectl-ai: Kubernetes用AIアシスタント (2/2) 実用的なコマンド例： # デプロイメント作成 kubectl ai "nginxのDeploymentを作成して、レプリカ数は3、リソース制限ありで" # トラブルシューティング kubectl ai "なぜPodがPendingのままなのか調査して" # スケーリング操作 kubectl ai "payment-serviceのレプリカを3から5に増やして" 26
27. kubectl-aiの活用パターン # リソース最適化 kubectl ai "すべてのDeploymentのリソース使用状況を分析し、最適化案を提示して" # セキュリティ診断 kubectl ai "クラスタ内の潜在的なセキュリティリスクを検出して" 複雑なKubernetes操作を自然言語で実行可能に 現在のクラスタ状態に基づいた適切な提案 特定の状況に合わせたトラブルシューティング 27
28. 各種サービスのMCP実装例 各サービスベンダーもMCP実装を進めています。人の夢は!!! 終わらねェ!!! Datadog MCP(非公式) 監視データやログの自然言語分析 インシデント検知と障害対応支援 PagerDuty MCP(非公式) PagerDutyのAPI機能をLLMに提供 インシデント、サービス、チーム管理が自然言語で可能 28
29. 自分でMCPサーバーを作る tfmcp - Terraformを操作するMCPサーバー例 出典: https://syu-m- 5151.hatenablog.com/entry/2025/03/09/020057 アーキテクチャと実装 tfmcp ├── config - 設定管理 ├── core - コアロジック ├── mcp - MCPプロトコル実装 ├── shared - 共通ユーティリティ └── terraform - Terraform連携 29
30. tfmcp - Terraformを操作するMCPサーバー例 出典: https://syu-m- 5151.hatenablog.com/entry/2025/03/09/020057 主な機能と利点 使用言語: Rust (高性能で安全な実装) 内部処理: Terraform CLIをラップしてJSON-RPC化 通信方式: STDIOトランスポート採用 主な機能: 設定解析、計画実行、状態管理、適用 実行 実装例: インフラ管理をLLMから自然言語で操作可能 になる 30
31. tfmcp - 実装から学ぶMCPについて 出典: https://syu-m- 5151.hatenablog.com/entry/2025/03/09/020057 公式SDKを使わない独自実装の価値 深い理解の獲得: プロトコルの細部まで理解でき る カスタマイズの自由: 自社要件に最適化した実装 が可能 軽量な依存関係: 必要最小限のコードで構築 「MCPは実装してこそ理解できる。実装を通じて感覚を掴み、 独自の拡張も検討できる。何ができて何ができないかを体感し てほしいです」 31
32. MCPがもたらす業務変革の具体例 1. 社内知識の民主化と活性化 埋もれた資料を瞬時に発掘し、組織の「知の格差」を解消 新入社員でもベテランの知見にAI経由で即アクセス可能に 2. 「煩わしい」開発タスクからの解放 「リリース手順書見てください」から「リリースして」へ コードレビューの単純指摘をAIが担当し、創造的思考に集中 32
33. MCPがもたらす業務変革の具体例 3. データドリブン意思決定の加速 「このデータどう分析すれば...」から「このデータから何がわかる？」へ 非エンジニアでも複雑なデータインサイトを会話感覚で引き出せる ビジネスインパクト 属人化したシステム運用知識を「全社の資産」として再定義 「マニュアル作成→共有→トレーニング」のサイクルを短縮し、即戦力化を実現 試作版MCP実装で「どこまでをカスタマイズすべきか」を実データで判断可能に 33
34. セキュリティリスクと対策 MCPのセキュリティリスク サードパーティMCPサーバーのリスク: 信頼できない「野良MCPサーバー」によ る危険性 権限の過剰付与: 必要以上の権限によるリソース不正アクセスの可能性 データ漏洩のリスク: 機密情報の外部漏洩 プロンプトインジェクション攻撃: 悪意あるプロンプトによる予期しない操作 34
35. セキュリティリスクと対策 利用・実装時のベストプラクティス 信頼できるソースのみ利用: 公式リポジトリや信頼できる開発者のコードを確認 最小権限の原則適用: 必要最小限の権限のみを付与 サンドボックス環境での実行: 隔離環境によるアクセス制限 監査ログの有効化: 実行コマンドや操作の記録と定期確認 機密情報のフィルタリング: APIキーやパスワード等の検出・削除 ツールのセキュリティチェック: ツールのセキュリティ特性を確認 (riseandignite/mcp-shield,invariantlabs-ai/mcp-scanなどがある) 35
36. まとめ 1. オープン標準のパワー ベンダーロックイン回避と互換性確保 OpenAIも採用し、事実上の業界標準に 2. 2025-03-26仕様の画期的進化 Streamable HTTP・ステートレスモードで実装が容易に OAuth認証・ツール注釈で本番環境での利用障壁を低減 3. 次のステップ 仕様が安定してきたので、実装を進めていくのも良いかも 運用やセキュリティに気をつけながら既存システムとの統合を目指す 36
37. ありがとうございました ご質問・ご相談はお気軽にお問い合わせください @nwiizo | https://3-shake.com