MCP本を読んで考えた「今やるべきこと/やらなくていいこと」

Transcript

1. MCP本を読んで考えた 「今やるべきこと / やらなくていいこと」 原⼝ 秀⼈ 株式会社シーズ / 取締役CTO
2. ⾃⼰紹介 原口 秀人 株式会社シーズ　取締役CTO Haraguchi Hideto AWS : 2025 AWS Ambassadors (business) 経営 : 経営者1年生。元はバリバリのエンジニア 好きなAWS : ECS(fargate),Graviton,CodeBuild 好きなLLM: ChatGPT 趣味: ゲーム、投資。ぽこポケ中！ 最近: 車を初めて購入した！(kintoでは無い😝)
3. ‧前半 MCPの基礎とアーキテクチャ ‧後半 AWSでの実践ハンズオン さらに、評価⽅法と実運⽤の観点まで含む 基礎‧実践‧運⽤が1冊でつながる本！ 「AWSではじめるMCP実践ガイド」おめでとうございます 🎉
4. ‧新しい技術を、どう扱うべきか ‧何を論点として⾒るべきか 「技術の正解」より、「いまどう判断するか」 のお話しができればと思います 今⽇話したいこと
5. 事前の印象 「便利そうだけど、そこまで追わなくていいか な」と思っていました 当時の疑問‧引っかかり Playwright MCPを使っていた AWSのMCPサーバーも⾒かけていた MCPって接続⽅法のひとつでは？ API連携と何がそんなに違うのか？ 今どれくらい追いかける必要があるのか？ • • • • • 読む前の温度感 使うとLLMがパワーアップするくらいの認識 •
6. MCPは便利ツールというより「接続や責任分界の考え⽅」に近いと感じました。 つなぎ⽅をそろえる 使い回しやすくする 境界を整理しやすくする 触ってみて変わった⾒え⽅
7. MCPは、便利かどうか以上に、「安全に扱えるか」を考える材料として意味があると感じました。 価値が⾒えやすいのは、ユーザーごとに⾒せていい情報が違う場⾯です。 たとえばコールセンターの⾃動応答AIなら、 「ユーザーAの問い合わせで、ユーザーBの情報は返してはいけない」 こういうときは、以下の設計が重要になります。 接続先をどう分けるか： ユーザーのコンテキストに応じた適切なルーティング 認可をどう考えるか： 誰がどのデータにアクセスできるかの厳密な管理 AIにどこまで触らせるか： 実⾏可能なアクションの制限と安全性の確保 価値が⾒えやすい場⾯
8. 本番運⽤の話で⼀番気になったのは、むしろAIの出⼒の揺れでした。 揺れてもいい仕事 AIの柔軟性や創造性が活きる領域。結果のバラ つきが許容される業務。 揺れると困る仕事 正確性、⼀貫性、コンプライアンスが求められ る領域。ルールベースの処理が必要な業務。 例： 例： アイデア出し 叩き台づくり 調査補助 審査処理 顧客対応（クレーム等） 業務の最終判定 • • • • • • AIアプリにおける⼀番⼤きい論点
9. 全社でやる 全⾯展開 今の⾃分の距離感 重要なのは 「判断できる状態を作ること」だと思っています
10. 今やるべきこと いま無理にやらなくていいこと 社内で1〜2⼈は仕組みまで理解しておく ⼩さなユースケースで試してみる 既存のAPI連携と⽐べてみる セキュリティ、再利⽤性、運⽤しやすさを⾒ ていく 全社教育 全⾯移⾏ 既存システムをMCP前提で作り直すこと AIにいきなり広い権限を持たせること • • • • • • • • 今やるべきこと / やらなくていいこと
11. ⾃分の中では、次の3つが判断の軸になりました。 MCPを使うかどうかより、「何を任せてよくて、どう責任を置くか」の⽅が⼤事 1. ⼟台としての価値 単発の便利さか、今後のシス テムアーキテクチャの⼟台に なりそうか。 2. 揺れの許容度 そのユースケースにおいて、AI の出⼒が揺れても⼤丈夫か （業務影響度）。 3. 責任の所在 どこまでAIに任せて、どこをア プリケーション（システム） 側で決めるか。 判断の軸
12. 今の⾃分は、こんなふうに考えています。 MCPは接続や責任分界の⾒⽅を与えてくれる 実運⽤ではAIの出⼒の揺れの⽅が⼤きな論点かも 「⼀気に広げる」より「分かる⼈を作って、⼩さく試 す」が合っていそう この本はMCPを今すぐ実装したい⼈だけでなく、 「AIを業務でどう扱うかを考えたい⼈」にも読む 価値があると感じました。 • • • まとめ