🔌
CA.ai#2 〜明日から使える実践MCPテクニック〜 イベントレビュー
2025年7月17日、渋谷Abema Towersにて開催された技術勉強会「CA.ai#2 〜明日から使える実践MCPテクニック〜」。会場は150名を超える参加者の熱気に包まれ、オンラインでも多くの方々にご視聴いただきました。今回のテーマはMCP (Model Context Protocol)。生成AI活用の現場で誰もが直面する課題を解決し、開発の未来を大きく変える可能性を秘めたこのプロトコルについて、サイバーエージェントのトップエンジニアたちが惜しみなく知見を共有しました。
本レポートでは、イベント当日の興奮と学びを凝縮し、AI開発の新たな地平を切り拓くMCPの魅力と実践的なテクニックをお届けします。
オープニング：なぜ今、MCPが”企業価値”になるのか？
オープニングに登壇したのは、CTO統括室のGünther Brunner（グンタ ブルンナー）。彼は力強いメッセージでイベントの幕を開けました。
「2026年、投資家はMCPエコシステムの充実度を企業評価の重要指標にする」
これは単なる予測ではなく、すでに始まっている未来であるとBrunner氏は語ります。従来のAPI連携では、バージョニング管理の複雑さや、LLMが最新の仕様を自律的に発見できないという課題がありました。MCPは、LLMが外部ツールやサービスの機能を”発見”し、常に最新の状態で連携できる仕組みを提供することで、この問題を根本から解決します。
Amazon社内では、もはや管理画面UIを作らず、MCPサーバーを提供するだけで各チームがデータや機能を操作する文化が根付いているといいます。これは、開発のあり方が「なんとなく」のペアプログラミングから、再現性の高いコンテキストエンジニアリングへとシフトしていることの証左です。
特に日本の企業にとって大きなチャンスとなるのが、Anthropic社が発表したDXT (Distributed Context Toolkit) です。これは、ローカル環境で動作するシステムや、セキュリティ要件の厳しい社内ツールなどを、まるでApp Storeのアプリのように手軽にMCP対応させる仕組みです。非エンジニアでもワンクリックで高度なAI連携を実現できるDXTは、レガシーシステムと最先端AIの架け橋となり、日本のDXを加速させる起爆剤になる、とBrunner氏は熱弁しました。
セッションの最後、彼はこう問いかけました。 「来年、あなたの会社はMCPサーバーを100個持つ企業ですか？それとも、0個の企業ですか？企業の価値は、どちらが持つことになるでしょう？」 この問いは、イベント全体を貫く重要なテーマとなりました。
はじめてのMCP：開発現場で役立つMCPの基礎
続いて登壇したのは、AIオペレーション室の濱口 宝。2024年新卒入社の若きエンジニアが、MCPの「そもそも」を分かりやすく解き明かしてくれました。
「AIに期待する回答が返ってこない…その課題、MCPが解決するかもしれません」
濱口氏は、GitHubのIssue対応を例に挙げ、MCPの威力を示しました。Issueの内容を読み取り、コードを修正し、プルリクエストを作成するまでの一連の流れを、MCPを活用することで完全に自動化できるのです。
この魔法のような技術の裏側にあるのが、MCPクライアント（CursorやClaudeなど）とMCPサーバー（GitHubやAWSなど、各種ツールに対応）の連携です。クライアントは、利用可能なMCPサーバーのリストをLLMに提示し、LLMは対話の文脈に応じて最適なツールを自律的に選択・実行します。
RAG（検索拡張生成）やFunction Callingといった類似技術との違いも明確に解説されました。
RAG: 情報を”検索”する技術
Function Calling: 外部ツールを”実行”する技術だが、LLMごとに仕様が異なり、都度実装が必要
MCP: 一度サーバーを立てれば、どのLLMクライアントからでも統一されたインターフェースで再利用できる
FigmaのUIデザインをコードに起こしたり、Notionの議事録を元に実装を進めたりと、複数のMCPを組み合わせることで、ソフトウェア開発のあらゆる局面でAIの支援を受けられるようになるといいます。
しかし、便利な技術にはリスクも伴います。悪意のあるプロンプトによって機密情報を送信してしまうプロンプトインジェクションや、偽装されたMCPサーバーを利用してしまうツールポイズニング攻撃など、セキュリティ上の注意点も共有されました。信頼できる公式MCPの利用、権限の最小化、実行時の都度許可など、安全に活用するための具体的な対策は、すぐにでも現場で実践できる内容でした。
【Q&Aハイライト】Q. セキュリティリスクを考えると、例えばCursorからGitHubへの書き込みは避けるべきでしょうか？
濱口氏: 私たちのチームでもまだ本格的には行っておらず、Issue作成なども手動です。ただ、Issueを細かく書くのは大変な作業なので、将来的にはAIで自動化できると良いと考えています。まずは試験的に導入してみるのが良いかもしれません。
Playwright MCPで変わるフロントエンドAI活用 🤖
株式会社MG-DXのフロントエンドエンジニア、柳萬 真伸氏は、AI活用の難所とされてきたフロントエンド開発に焦点を当てました。
「AIは高速でコードを書いてくれますが、そのUIが正しく表示・動作するかは、結局人間の目で確認する必要がありました」
この課題を解決するのが、E2EテストライブラリであるPlaywrightとMCPを組み合わせたPlaywright MCPです。これは、LLMにブラウザを操作する 「目」と「手」を与えるようなものだと柳萬氏は表現します。
Playwright MCPが可能にすること：
自然言語でのテスト実行: 「ログインフォームに正しい情報を入力し、ダッシュボードに遷移することを確認して」といった自然言語の指示だけで、AIが実際のブラウザ操作を伴うテストを実行します。
高精度なテストコード生成: AIが実際にページを操作し、UI要素やユーザーの操作フローを理解した上で、網羅的なテストケースを考案し、テストコードを生成します。
レスポンシブデザインの一括チェック: 「モバイル、タブレット、デスクトップで表示を確認して」という一言で、各画面サイズのスクリーンショットを撮影し、レイアウト崩れなどを自動で検証します。
アクセシビリティの動的検証: 静的解析ツールでは見つけにくい問題（例：キーボード操作の妥当性、スクリーンリーダーの読み上げ順）を、実際の画面操作を通じて検証。alt属性の内容が画像の意味と合っているか、といった高度なチェックまで可能になります。
最もインパクトがあったのは、 「コード生成→テスト→修正」のサイクルを完全に自動化するという活用例です。AIが生成したコンポーネントを、Playwright MCPを使って即座にブラウザ上で動作確認し、問題があればAI自らが修正する。この自己完結型の開発ループは、フロントエンド開発の生産性を劇的に向上させる可能性を秘めています。
【Q&Aハイライト】Q. 自然言語での指示は、どのくらい細かくする必要がありますか？
柳萬氏: 私の場合は、かなり細かく指示を出しています。「このセレクトボックスに、この要素が含まれているか確認して」というように、一つの要素に対して具体的な指示を与えるようにしています。
Q. テスト実行の時間的・費用的コストは？
柳萬氏: 正直、時間はかかります。コンテキスト量も増大します。そのため、私が試しているのは、一つのまとまったタスクをAIに任せ、その間自分は別の作業を進めるというやり方です。手放しで任せられる部分に使うのが効果的だと感じています。
AI駆動開発を最大化する効率化への挑戦
AIオペレーション室の李 俊浩（イ ジュンホ）氏は、開発プロセス全体をAIで変革する「AI駆動開発」という壮大なビジョンを語りました。
「これまでのAI活用は”実装”という点に集中しがちでした。AI駆動開発は、要件定義からリリースまで、開発サイクル全体をAIと伴走するアプローチです」
このアプローチの課題は、「AIが生成したコードは本当に信用できるのか？」という点に尽きます。情報が古かったり、プロジェクト固有のルールを無視したり…。その根本原因は、AIに適切なコンテキクスト（文脈）が与えられていないからだと李氏は断言します。
そして、その解決策こそがMCPです。
要件定義の自動化: N8NのMCPサーバーを活用し、Slackの議事録や関連ドキュメントをAIが自律的に収集・分析。それを基に、精度の高い仕様書を自動で作成します。
信頼性のあるコード生成:
Context.shのMCPサーバーを利用することで、ライブラリの最新バージョンのドキュメントに準拠した、信頼できるコードを生成させます。エビデンスベースのセキュリティ指摘: OWASPのドキュメントをMCP経由で参照させ、コードの脆弱性を指摘する際に、その根拠を明確に提示させることが可能です。
AIによるコードレビューと自動マージ: GitHub ActionsとClaudeを連携させ、プルリクエストに対してAIがレビューコメントを付けます。さらに、ドキュメント修正などの軽微な変更であれば、事前に定めた基準に基づき自動でマージするところまで実現しています。
極め付きは、SlackでIssueを起票するだけで、AIが内容を分析し、計画を立て、コーディングからプルリクエストのレビューまでを自律的に完遂するデモでした。人間は最後の意思決定とレビューに集中する。まさに開発の未来像がそこにありました。
【Q&Aハイライト】Q. AI駆動開発において、人間のエンジニアの価値はどこにあるのでしょうか？
李氏: これからは、素晴らしいコードを書くこと以上に、適切な意思決定とレビューをする力が人間の価値になると思います。AIが生成したコードが本当に正しいのか、ビジネス要件を満たしているのかを判断し、採用を決定する。その能力がより重要になります。
PipeCDとBucketeerのDocumentation MCP Serverを作って公開した話
最後のセッションでは、CTO統括室の菊池 哲哉氏と黒田 尚輝氏が、自ら開発するOSS「PipeCD」と「Bucketeer」のドキュメント検索用MCPサーバーを開発・公開した経験を語りました。
「OSSのドキュメント検索は、開発者である私たちにとっても面倒な作業でした」
この課題を解決するため、彼らはOSSのドキュメントをローカル環境で手軽に検索できるローカルMCPサーバーを開発しました。リモートサーバーにしなかった理由は「開発・運用が楽で、その必要性がなかったから」とシンプルです。
実装における工夫も非常に実践的でした。
差分更新: ドキュメントをローカルにダウンロードする際、ハッシュ値を比較し、変更があったファイルのみを更新することで高速化。
賢い検索ロジック: 単純な全文検索ではなく、「①タイトル完全一致 → ②キーワード一致 → ③全文検索」のように優先順位をつけ、検索精度と速度を両立。
Git Sparse Checkoutの活用: リポジトリからドキュメントディレクトリのみをクローンすることで、不要なデータのダウンロードを防ぎ、効率化。
驚くべきは、「MCPサーバー開発は意外と簡単」で、「AIに関係ない実装が多い」という点です。彼らは、既存のMCPサーバーを参考にし、UvやRepoMixといったツールでコードを整形し、Claude上で壁打ちしながら設計を進めたといいます。
この取り組みは思わぬ副産物も生みました。従来、設定ファイル生成のために別途作っていたツールが、自然言語で設定ファイルを生成できるMCPサーバーの登場によって不要になったのです。
セッションの最後には、フューチャーフラグ管理ツールであるBucketeerの機能を、IDE上から直接操作できるMCPサーバーをわずか1日で開発したという話も飛び出しました。MCP開発のハードルは、私たちが思うよりずっと低いのかもしれません。
【Q&Aハイライト】Q. ベクトル検索を使わなかった理由は？
黒田氏: 最初は迷いましたが、まずは早く作ってみることを優先しました。今回実装した単純な検索ロジックでも、タイトル検索などを加えることで、かなり性能が良くなりました。もちろん、ベクトル化をちゃんとやれば、さらに精度は上がると思います。
イベントを終えて、未来への確信
今回の「CA.ai#2」は、MCPという技術が単なるトレンドワードではなく、私たちの開発スタイルそのものを根底から覆すパラダイムシフトであることを強く印象付けるイベントでした。
オープニングで提示された「MCPは企業価値になる」という未来像。それを裏付けるように、各セッションでは、基礎的な概念から、フロントエンド、AI駆動開発、OSSといった具体的な領域での目覚ましい活用事例が次々と示されました。登壇者たちの熱意、そしてそれに食い入るように耳を傾け、鋭い質問を投げかける参加者の姿は、AI開発の最前線にあるコミュニティの熱量を象徴しているようでした。
特に心に残ったのは、どのセッションにも共通していた「AIに適切なコンテキストを与える」という思想です。AIの能力を最大限に引き出すのは、魔法のプロンプトではなく、正確で、構造化された、信頼できる”文脈”の提供に他なりません。MCPは、そのための最も強力でスケーラブルな仕組みです。
明日から、いや、今日からでもMCPサーバーを作ってみよう。イベントを終えた多くの参加者が、そう感じたのではないでしょうか。AIと共にコードを書き、AIと共にサービスを創る。そんな新しい時代の開発者体験が、もうすぐそこまで来ている。そんな確信を抱かせてくれる、刺激的な一夜でした。
Yardでは、AI・テック領域に特化したスポットコンサル サービスを提供しています。
興味がある方は、初回の無料スポットコンサルをお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...