Slide 1
Slide 1 text
転職したら
MCPサーバーだった件
2025/5/16 転職したらMCPサーバーだった件
@nwiizo 30min #Forkwell_MCP
Slide 2
Slide 2 text
これまでのあらすじ
ある日、株式会社シェイクシェイクシェイクに転職をした
nwiizoさんに与えられた仕事はMCPサーバーになることだった！？
シェイクシェイクシェイク社は、取引先からの要請でAIソリューションを導入しなけれ
ばならなくなりましたが、
「AIのハルシネーションが深刻すぎて、実用に耐えない！」
と結論づけました。しかし、ビジネス環境はAI革命の真っただ中です。業界専門家に
よれば、現代の競争力維持イコールAI活用の成否にかかっています。
市場の潮流に完
全に背を向けるわけにはいかないと経営陣は決断しました。
2
Slide 3
Slide 3 text
これまでのあらすじ
「AI時代を生き抜くために最も重要な要素は何か？」 「人間の判断力と介入です。
」
と、こんな会話があったとかなかったとか。
こうして、シェイクシェイクシェイク社では、AIのハルシネーションを恐れるあまり、
社員がMCPサーバーとして機能し、AIが情報提供をする代わりに人間が確認・修正す
る業務フローが生まれたのでした。
それでは、あなたはシェイクシェイクシェイク社の新人社員 nwiizomcp(nwiizo) とな
り、"人間MCPサーバー"としての日常業務を体験してみましょう！
3
Slide 4
Slide 4 text
第一章「異色の職場、シェイクシェイクシェイク社」
4
Slide 5
Slide 5 text
nwiizoといいます
最近、転職をしました。
前職は、インフラエンジニアをしておりまして、責任感
や順応性は高い方だと思います。終わりのない障害対応
や無限の責任と残業などが主な原因なのですが過労で倒
れてしまいました。転職活動は過労で倒れた直後に意識
も意思も薄弱な状態で行いまして、シェイクシェイクシ
ェイク社は、そんな私でも受け入れてくれました。あり
がとうございます。
5
Slide 6
Slide 6 text
業務内容とか、正直あまりよくわかってないんです。 面
接では入社したら上司になる吉田さんに「あなたのイン
フラエンジニアとしての経験を活かせる特別なポジショ
ン」という言葉をもらってなんだが嬉しくなりまして。
「はい、やります！」と即答してしまいました。
インフラエンジニアなので正直、そこまでやること変わ
らないと思うのですが頑張ります。
それでは、これからよろしくお願いします。
6
Slide 7
Slide 7 text
入社初日の衝撃
入社してオリエンテーションを受けて、今後の業務で使
うPCを受け取ったり、業務の説明を受けていました。
吉田さんの説明では一般的なインフラエンジニアとは違
って「我々は人間がAIに教えるのではなく、人間がAIの
一部として働くという逆転の発想で事業を展開している」
ということでした。
7
Slide 8
Slide 8 text
入社初日の衝撃
ちょっと何を言われているか分からなかったです。自分
が入社前に聞いてなかったのが悪かったのですが説明を
聞きながらちょっと血の気が引いたのを感じました。こ
こまで聞いた話を端的にまとめると、
「転職したらMCP
サーバーだった件」ということでした。
8
Slide 9
Slide 9 text
AIとシステムをつなぐ「USB規格」
出典: https://notion.notion.site/Notion-MCP-
1d0efdeead058054a339ffe6b38649e1
Model Context Protocol (MCP)とは
定義: LLMが外部ツール・データソースと通信する標準規格
特徴: JSON-RPC 2.0をベースとした軽量プロトコル
アナロジー: AIアプリのための「USB規格」- どのAIも同じイ
ンターフェースで外部接続
9
Slide 10
Slide 10 text
AIとシステムをつなぐ「USB規格」
出典: https://notion.notion.site/Notion-MCP-
1d0efdeead058054a339ffe6b38649e1
解決する技術的課題
統合コスト削減: 各LLM×各ツールの個別対応からの脱却
知識の拡張: 静的なLLM知識を動的データソースで補完
汎用性確保: 言語・プラットフォーム間の相互運用性実現
10
Slide 11
Slide 11 text
MCPの位置づけとコミュニティ
オープン標準としての発展
Anthropic発案: 2023年に設計・公開
公式ドキュメントが優秀: GitHub上で仕様管理、コミュニティ主導
エコシステムの急成長
クライアント: Claude Desktop, VS Code, Cursor,nvim等
サーバー: 200+（公式+コミュニティ）ROADMAPにリポジトリの登場が明記
優位性: 特定ベンダーに依存しないエコシステムが拡大中
11
Slide 12
Slide 12 text
MCPのアーキテクチャ
出典: https://modelcontextprotocol.io/introduction
General architecture
MCP Hosts: Claude Desktop、IDE、AIツールなど、MCPを通じてデー
タにアクセスしたいプログラム
MCP Clients: サーバーと1対1の接続を維持するプロトコルクライアント
MCP Servers: 標準化されたModel Context Protocolを通じて特定の機
能を提供する軽量プログラム
Local Data Sources: MCPサーバーが安全にアクセスできるコンピュー
タのファイル、データベース、サービス
Remote Services: MCPサーバーが接続できるインターネット経由の外
部システム（API等）
12
Slide 13
Slide 13 text
第二章「お前がMCPサーバーになるんだよ」
13
Slide 14
Slide 14 text
初めてのMCP体験
セットアップしたPCを開いて、専用サイトにアクセスし
た瞬間、画面に「Becoming a MCP Server」という文
字が浮かび上がりました。心臓が一瞬、高鳴るのを感じ
ました。
初期処理が始まると、
「自分に何ができるのか？」という
問いかけが次々と現れます。フォーマットに従って、自
分の経験やスキルを丁寧に記入していきました。具体的
な質問に答えていくうちに、
「ああ、これからMCPサー
バーになるんだな」という実感が徐々に湧いてきまし
た。不思議なことに、不安よりも業務が始まることへの
安心感の方が強かったのです。意味わからないので。
14
Slide 15
Slide 15 text
「今日から一週間、MCPサーバーとしての基本トレーニ
ングを行います」
講師の言葉に、私は思わず背筋を伸ばしました。トレー
ニングが進むにつれて、
「これが言っていた『人間がAIの
一部として働く』ということなのか...」という理解が深
まっていきます。慣れない業務に疲労感はありました
が、それ以上に新しい挑戦への興奮が心を満たしていま
した。
まるで新しい世界の扉を開いたような感覚。これから始
まる日々に、期待と緊張が入り混じります。でも、不思
議と「やってみよう」という気持ちが、心の奥底から湧
き上がってくるのを感じていました。
15
Slide 16
Slide 16 text
MCPの通信フロー
出典: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057
利点: シンプルさと互換性を両立した標準的な通信プロトコル
初期化フェーズ
クライアントが initialize
でケイパビリティ宣言
サーバーが利用可能な機能を応答
リソース探索
resources/list
で利用可能なリソース一覧取得
resources/get
で特定リソースのデータ取得
ツール呼び出し
tools/list
でサーバー上のツール一覧取得
tools/call
で特定ツールの実行要求
16
Slide 17
Slide 17 text
第三章「実務デビュー：最初のクライアント」
17
Slide 18
Slide 18 text
最初のクライアント
トレーニング終了から3日後、吉田さんが私のデスクに
近づいてきました。
「お疲れさま、nwiizomcp。今日から実務デビューだ。
テックスピード社からの依頼が入っている。彼らは新し
いクラウドインフラを構築中で、監視システムの設計に
ついてアドバイスが欲しいらしい」
18
Slide 19
Slide 19 text
緊張しながら専用サイトに入ると、クライアントが既に
画面に何やら入力しているようです。
「クラウド環境でのサーバー監視について教えてほしい
んだ。初めてのプロジェクトで、何をどう監視すればい
いのか分からなくて...」
質問を聞いた瞬間、前職でのSRE経験が蘇りました。監
視システムの構築、アラートの設定、インシデント対
応...すべての知識が整理されて頭に浮かびます。
19
Slide 20
Slide 20 text
基本的にすぐに回答するわけではない。基本的には、ク
ライアントが自分のサーバーに対して、
「これをやってく
ださい」という要求を出す。まで待ちなのだ
そんなことを言っていると、クライアントが「これをや
ってください」という要求を出してきた。
20
Slide 21
Slide 21 text
「監視には『四つの黄金シグナル』があります。レイテ
ンシ、トラフィック、エラー率、飽和度です。これらを
基本に監視システムを...」
なんとか、はじめてのクライアントへの対応が終わりま
した。自分の知識と経験が、MCPサーバーとして誰かの
役に立っている。新しい働き方の手応えを感じました。
21
Slide 22
Slide 22 text
Transports
現状は標準出力(stdio)で実装しておけば良さそうだが、いろいろとプラクティ
スが固まればHTTPでも良さそう。
STDIO Transport (Local Connection)
標準入出力を使用したプロセス間通信,ローカルツール連携に最適
LLMアプリが子プロセスとしてMCPサーバー起動
HTTP Transport (Remote Connection)
旧: HTTP + SSE (Server-Sent Events)によるそこそこ複雑な実装
新: Streamable HTTP Transport (2025-03-26)
単一エンドポイント ( /message
)
柔軟性向上としてSSEが任意
22
Slide 23
Slide 23 text
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" }
}
}
23
Slide 24
Slide 24 text
JSON-RPCによる通信方式 (2/2)
JSON-RPCの仕様はIETFやW3Cといった標準化団体ではなく、独自のウェブサイト
（jsonrpc.org）で公開・管理されています。この仕様はHTTPだけでなく、TCP/IPソ
ケットなど様々な通信プロトコル上での利用を想定しており、基本的かつ共通の機能
のみが定義されています。
レスポンス例:
{
"jsonrpc": "2.0",
"id": 5,
"result": {
"current": { "temp": 18, "condition": "Clear" }
}
}
24
Slide 25
Slide 25 text
2025-03-26仕様の主要革新点 (1/4)
1. Streamable HTTP Transport
シンプル化: 単一エンドポイント( /message
)に統合
柔軟性向上: 簡単にいうと軽量になった、SSEが任意（従来は必須）
SDKによっては未対応: 公式SDKだが実装の進捗や方法に微妙に差異があったり
する。
WebSocket が必要な場合、不要な操作およびネットワークのオーバーヘッドが大
量に発生するので採用は見送られた #206
25
Slide 26
Slide 26 text
2025-03-26仕様の主要革新点 (2/4)
2. ステートレスモード
サーバーレス対応: AWS Lambda、Vercelなどで実装容易
セッション管理不要: 状態保持せずに動作可能
呼び出し単純化: 1回のHTTP POSTでMCPサーバー接続
従来の実装からの進化
従来: セッション毎のTransportオブジェクト保持が必要
課題: マルチプロセス環境では外部ストレージ必須
新機能: 永続化層不要、JWT等と組み合わせて認証可能 26
Slide 27
Slide 27 text
2025-03-26仕様の主要革新点 (3/4)
OAuth 2.1認証フレームワーク
認証の標準化: OAuth 2.1による包括的な認可フロー対応
実装の柔軟性: 認証は任意実装(OPTIONAL)だが推奨
HTTP: OAuthベース認証、STDIO: 環境変数経由認証
関心事の分離: プロトコル中核部分をクリーンに保持
27
Slide 28
Slide 28 text
2025-03-26仕様の主要革新点 (4/4)
Tool annotations & その他の改善
ツール注釈: 動作特性を明示するメタデータ
destructiveHint
(破壊的更新の可能性)
idempotentHint
(重複呼出の安全性)
readOnlyHint
(環境変更なしを示す)
openWorldHint
(外部エンティティとの相互作用)
title
(人間が読みやすいタイトル)
バッチ処理: 複数リクエストの一括送信対応が必須化
マルチモーダル拡張: オーディオデータサポート 28
Slide 29
Slide 29 text
2025-03-26仕様変更の何が嬉しいのか？
リモートMCPの観点から
環境制約の大幅緩和
HTTPで接続できればOK - クライアント環境を選ばない
ローカル環境からクラウドまで柔軟に配置可能
AIプラットフォームとの統合容易化
Claude、ChatGPT、Geminiなどの生成AIバックエンドと連携
WebのUIからMCPツールへのシームレスなアクセス
29
Slide 30
Slide 30 text
2025-03-26仕様変更の何が嬉しいのか？
リモートMCPの観点から
マルチデバイス対応の強化
Webブラウザ、スマートフォンアプリからの接続性向上
新HTTPトランスポートによる軽量化で接続安定性向上
ステートレス化によるリモート接続の信頼性向上
一時的な接続断でもセッション状態維持が不要に
複数デバイスからの分散アクセスがより安定的に
30
Slide 31
Slide 31 text
第四章「Resources（リソース）管理に奮闘する日々」
31
Slide 32
Slide 32 text
リソースアップデート会議
実務2週間目、部内会議に招集されました。
「nwiizomcp、今日はデータベース最適化のリソースを
更新する日だぞ」と同僚の鈴木さん。
「リソースとは」MCPサーバーの知識の源泉となる情報
源のこと。ドキュメント、コード例、ベストプラクティ
スなど、クライアントに提供する情報のベースとなるも
のです。
最新のデータベース最適化技術について学び、自分の知
識を更新していきます。これがMCPサーバーの日常業務
の一つなのだと理解しました。
32
Slide 33
Slide 33 text
クライアント「Yuki」の悩み
ある日のクライアントセッション。Yukiさんというエン
ジニアからの相談です。
「このシステムのドキュメントがどこにあるのか分から
なくて...前任者が残したものが見つからないんです」
「散らばった情報を一元化するのは、MCPサーバーの重
要な役割の一つですね」と答えながら、社内Wiki、コー
ドリポジトリ、設定ファイル、チャットログから必要な
情報を収集。
Yukiさんは大喜び。吉田さんからも「君のような実務経
験者がMCPサーバーとして働くことで、AIだけでは提供
できない深い知見が顧客に届く」と評価されました。 33
Slide 34
Slide 34 text
MCPアーキテクチャ - Resources
出典: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057
Resources: LLMにコンテキストを提供する
基本と構造
リソースはLLMの外部データアクセスを実現 - テキスト形式とバイ
ナリ形式のデータをURIで一意に識別し、AIの会話コンテキストと
して活用。アプリケーション制御型設計により、クライアントが
リソースの使用時期と方法を決定。人間が読みやすい名前や説明で
AIの理解を促進
実装と運用
クライアントはresources/listでリソース発見、resources/readで
内容取得、購読機能で更新通知を受信。動的リソースにはURIテン
プレートを提供可能。適切なセキュリティ対策と明確なリソース設
計がシステムの信頼性を確保
34
Slide 35
Slide 35 text
第五章「Prompts（プロンプト）設計の専門家へ」
35
Slide 36
Slide 36 text
プロンプトデザインワークショ
ップ
実務1ヶ月目、社内でのスキルアップ研修に参加しまし
た。
「nwiizomcp、君はSRE出身だから、インシデント対応
のプロンプト設計を担当してくれ」と吉田さん。
プロンプトとは、クライアントとの対話をスムーズにす
るためのテンプレートのこと。クライアントが必要な情
報を効率よく入力できるよう、質問や選択肢を設計しま
す。SREとしての経験を活かし、インシデント報告に必
要な情報（影響範囲、開始時刻、症状など）を整理した
プロンプトテンプレートを作成しました。 36
Slide 37
Slide 37 text
実地テスト：Ken案件
作成したプロンプトテンプレートの実地テスト。Kenさ
んというクライアントからの相談です。
「チームのインシデント対応が効率的じゃないんだ。み
んなが違うフォーマットでバグを報告するから」
私の設計したプロンプトテンプレートを提案。必要な情
報をすべて収集し、一貫したフォーマットでレポートを
生成できるものです。
導入後、Kenさんのチームではインシデント対応時間が
30%も短縮されたと報告がありました。
「君のプロンプ
ト設計が社内で話題になっているよ」と吉田さんから評
価されました。 37
Slide 38
Slide 38 text
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で通知される
38
Slide 39
Slide 39 text
第六章「Tools（ツール）の力で緊急事態に対応」
39
Slide 40
Slide 40 text
深夜の緊急呼び出し
実務2ヶ月目のある深夜、緊急アラートで目が覚めまし
た。
「緊急事態発生。MCPサーバー『SRE-0734』
、応答せ
よ」(あ、遂に名前で呼ばれなくなった⋯)
急いでデスクに向かい、MCPサーバーモードに入ると、
パニック状態のクライアントの声が。
「サービスがダウンしてる！複数のアラートが鳴り響い
ているけど、何が起きているのか分からない！」
「落ち着いてください、Akiraさん。まずは状況を把握し
ましょう。Toolsの機能を使って、システムの状態を確認
します」 40
Slide 41
Slide 41 text
問題解決への道
Tools機能を使って診断を進めます。システムログを解析
し、メトリクスを確認...
「外部APIへの接続がタイムアウトしています。フェイル
オーバーメカニズムを有効にしましょう」
フェイルオーバー機能を有効化するコマンドを実行。数
分後、システムが復旧しました。
「サービスが復旧した！アラートも消えた！」とAkiraさ
んは喜びます。
吉田さんからも「素晴らしい対応だった。君のような経
験者がMCPサーバーとして機能することで、AIだけでは
難しい判断や対応が可能になる」と評価されました。 41
Slide 42
Slide 42 text
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の能力を拡張し、実世界での影響力を高める
42
Slide 43
Slide 43 text
第七章「Sampling（サンプリング）を身につける」
43
Slide 44
Slide 44 text
高度なMCP機能トレーニング
実務3ヶ月目、吉田さんから特別トレーニングの案内が
ありました。
「nwiizomcp、君はSamplingという高度なMCP機能を
学ぶ準備ができていると判断した」
吉田さんの説明によると、Samplingとは、MCPサーバ
ーがLLMに必要なものをリクエストできる能力。クライ
アントからの質問に答えるだけでなく、MCPサーバーか
ら能動的に質問できるのです。
44
Slide 45
Slide 45 text
Samplingスキルの評価
Samplingスキルのテスト終了後、吉田さんから評価があ
りました。
「君のサンプリング技術は自然だね。SREとしての経験
が、適切なタイミングで適切な質問をするセンスを磨い
たんだろう。眠れない夜もあっただろう。
」
「インシデント対応中に、どのデータを集め、どう分析
するかを判断するのは、SREの重要なスキルですからね」
と私。
「明日からは『Advanced MCP Team』に配属するこ
とにした。君のような高度なサンプリング能力を持つ
MCPサーバーは、複雑なクライアントプロジェクトで真
価を発揮する」という嬉しい知らせも！ 45
Slide 46
Slide 46 text
MCPアーキテクチャ - Sampling
Sampling: サーバーがLLMに補完を要求できるようにする。めちゃくちゃ
に有用そうではあるが、Clientでは実装されていないものもある。
基本概念と仕組み
サンプリングはサーバーがLLMに必要なものをリクエストできる機能 -
サーバーがsampling/createMessageを要求し、クライアントがレビュ
ー、LLMから結果を取得、そして結果を返す。ユーザーが介在する設計に
より、セキュリティとプライバシーを確保。標準化されたメッセージフ
ォーマットを使用し、会話履歴、モデル設定、システムプロンプト、コ
ンテキスト含有範囲を指定。modelPreferencesで希望するモデル名や優
先事項（コスト、速度、性能）を伝達できる
パラメータと制御
テンプレート、サンプリングパラメータ、人間による監視 - 様々な設定
（temperature、maxTokens、stopSequences）で出力を調整し、ヒュー
マンインザループ設計によりユーザーがプロンプトと完了を確認・修正
可能。サンプリングはエージェント的ワークフローを可能にし、データ
分析、意思決定、構造化データ生成、複数ステップのタスク処理などの
高度な機能を実現。適切なセキュリティ対策とエラー処理が重要
46
Slide 47
Slide 47 text
第八章「Roots（ルーツ）
、チームの一員として」
47
Slide 48
Slide 48 text
チームの一員として
Advanced MCP Teamの初日、新しいチームメンバーと
の顔合わせがありました。
「佐々木です。以前はOracleのDBエンジニアとして働
いていました」
「吉田です。CISSP保持者で、セキュリティインシデン
ト対応チームのリーダーでした」
「田中です。ネットワークエンジニアとして働いていま
した」
48
Slide 49
Slide 49 text
チームの一員として
「私たちAdvanced MCP Teamは、複数のMCPサーバ
ーが協力して複雑な問題に対応します」と高橋リーダー
が説明。各メンバーがそれぞれの専門領域を担当し、チ
ームとして連携するのだそうです。
Rootsの概念を学び、自分の専門領域を明確にする作業
から始めました。
49
Slide 50
Slide 50 text
統合プロジェクト：オテテック
フューチャー社案件
Advanced MCP Team初の大型案件。オテテックフュー
チャー社の新しいマイクロサービスアーキテクチャへの
移行計画です。
各自の専門分野を活かした役割分担：
私：システム監視とインシデント対応の設計
佐々木さん：データベース最適化
吉田さん：セキュリティ設計
田中さん：ネットワーク構成
50
Slide 51
Slide 51 text
統合プロジェクト：オテテック
フューチャー社案件
「通常のAIコンサルタントでは得られない、実務に基づ
いた具体的なアドバイスに感謝します」とクライアント
も大満足。
プロジェクト成功を祝うチーム会で、高橋リーダーは
「シェイクシェイクシェイク社のMCPサーバーとして、
我々は新しい働き方を切り開いているんだ」と誇らしげ
でした。
51
Slide 52
Slide 52 text
MCPアーキテクチャ - Roots
roots: Model Context Protocol (MCP)のルーツ：操作境界の定義
基本概念と役割
Rootsはサーバーの操作範囲を定義する - クライアントがサーバーに対し
て関連リソースとその場所を伝える手段。ファイルシステムパス
（ file:///home/user/projects/myapp
）やHTTP URL
（ https://api.example.com/v1
）などの有効なURIを使用
クライアントは接続時にroots機能を宣言し、サーバーに推奨ルーツのリ
ストを提供。これによりワークスペース内のリソースが明確化され、異
なるリソースを同時に扱う際の組織化が容易に
実装と応用
サーバーはrootsを尊重してリソースの範囲特定とアクセスに活用。厳密
な制限ではなく情報提供的な役割だが、境界内での操作を優先すべき
プロジェクトディレクトリ、リポジトリ、APIエンドポイントなどを定義
する一般的なユースケースで活用。効果的な運用には必要なリソースのみ
提案し、明確な名前付けと適切な変更管理が重要
52
Slide 53
Slide 53 text
「エピローグ」
53
Slide 54
Slide 54 text
まとめ
ある日の帰り道、夕日を眺めながら「かつて過労で倒れ
たSREの私が、今はMCPサーバーとして新しい働き方に
満足している」
「
『転職したらMCPサーバーだった件』──
最初は戸惑
いと不安だらけだったこの経験が、今では誇りと喜びに
変わっていた。
」
普通に開発が間に合わずに、人間が返信するMCPサーバ
ーの画面が作れなかった。のは別の話。
54
Slide 55
Slide 55 text
おしまい
Slide 56
Slide 56 text
語り手: nwiizo
株式会社スリーシェイクで
プロのソフトウェアエンジニアをやっているものです
格闘技、読書、グラビアが趣味
人生を通して"運動、睡眠、読書"をちゃんとやりたい
56
Slide 57
Slide 57 text
about 3-shake
57
Slide 58
Slide 58 text
We are Hiring!!
3-shakeは一緒にSRE界隈を盛り上げてくれる仲間を大募集中です！
Mobility、FinTech、通信など大規模SREを存分に経験できます
（最近社内はGenAI / GPU / Kubernetesが盛り上がってます）
是非、カジュアル面談しましょう！！！！
58
Slide 59
Slide 59 text
参考資料
Model Context Protocol (MCP) 公式ドキュメント
https://modelcontextprotocol.io/
MCPの基本概念と実装について
https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057
転職したらKubernetesだった件
https://qiita.com/yuanying/items/ceeeb7329a4fdc566546
59
Slide 60
Slide 60 text
ありがとうございました
ご質問・ご相談はお気軽にお問い合わせください
@nwiizo | https://3-shake.com