開発者は1日あたり1,200回も注意散漫に、MCPが生産性向上を目指す

ソフトウェア開発者は、実際のコードを書く時間よりも、コーディング以外の作業に遥かに多くの時間を費やしている。業界調査によれば、直接的なプログラミング作業は開発者の1日の労働時間のわずか16％程度を占めるに過ぎず、残りの大部分はサポート業務や運用作業に奪われている。チームがより少ないリソースでより多くの成果を求められ、CEOがAI生成コードを称賛するこの時代において、重大な疑問が浮かび上がる：エンジニアの作業負荷のうち残り84％を、我々はどのように最適化しているのか？

開発者を最も生産性の高い場所に留める

開発者の生産性を最も損なう要因の一つがコンテキストスイッチングだ。ソフトウェアの構築とリリースに必要な、拡大し続けるツールやプラットフォーム群の間を絶えず行き来することである。ハーバード・ビジネス・レビューの研究によれば、デジタルワーカーは1日平均1,200回近くアプリやウェブサイトを切り替えている。 中断には常にコストが伴う。カリフォルニア大学の研究によれば、一度の中断から完全に集中力を回復するには約23分を要し、さらに深刻なのは中断されたタスクの約30%が未完了に終わる点だ。このコンテキストスイッチングの課題は極めて重要であり、ソフトウェア開発パフォーマンス測定で広く採用されるDORAフレームワークにも組み込まれている。

AI主導の組織が、大規模言語モデル（LLM）へのアクセス提供を超え、従業員がより少ないリソースでより多くの成果を上げることを目指す中、新たな潮流が形作られつつある。 Brexの主任エンジニアであるジャロッド・ルーランドは、「開発者は統合開発環境（IDE）内で集中を維持している時に最大の価値を発揮する」と確信している。この原則に基づき、彼はこれを実現する新たな手法を模索し、Anthropicの新しいプロトコルがそのパズルの重要なピースとなる可能性がある。

MCP：IDEに文脈をもたらすプロトコル

Cursor、Copilot、WindsurfといったLLM強化型IDEに代表されるAI搭載コーディングアシスタントは、開発者ルネサンスを牽引し、その普及率は前例のない速さで進んでいる。Cursorは史上最速で成長したSaaS製品となり、ローンチから1年で年間経常収益1億ドルを達成。フォーチュン500企業の70%がMicrosoft Copilotを採用している。

しかし従来、これらのアシスタントはコードベースの文脈に限定されていた。これにより開発者はコードを迅速に記述できるが、文脈切り替えという広範な課題は解決されない。 この課題を解決する新プロトコル「Model Context Protocol（MCP）」が登場した。2024年11月にAnthropicが発表したMCPは、AIシステム（特にLLMベースのツール）と外部データソース・アプリケーション間の連携を簡素化するオープン標準だ。過去6ヶ月で新規MCPサーバーが500%増加し、6月単月で推定700万ダウンロードを記録するなど、その人気は急上昇中である。

MCPの最も影響力のある応用例の一つは、AIコーディングアシスタントを開発者が日常的に使用するツールに直接接続する機能だ。これによりワークフローが合理化され、コンテキストスイッチングが劇的に削減される。

機能開発を例に考えてみましょう。従来は複数のシステム間を移動する必要がありました：プロジェクトトラッカーでチケットを確認し、チームメイトの会話内容を明確化するために確認し、APIの詳細をドキュメントで検索し、最後にIDEを開いてコーディングを開始する。各ステップは別々のタブで実行され、進捗を遅らせる思考の切り替えを強いられていました。

MCPとAnthropicのClaudeのような現代的なAIアシスタントを活用すれば、このプロセス全体をコードエディタ内で完結できます。

例えば、コーディングアシスタント内での機能実装は以下のように行えます：

• Linear MCPサーバーでチケット詳細を取得；
• Slack MCPサーバーで関連ディスカッションを表示；
• Glean MCPサーバー経由で必要なドキュメントを参照；
• カーソルに初期スケルトン生成を依頼して機能を記述する。

同様のアプローチは他のエンジニアリングワークフローにも適用できます。例えばサイト信頼性エンジニア（SRE）のインシデント対応では以下が想定されます：

• Rootly MCPサーバー経由でインシデント詳細を取得
• Sentry MCPサーバー経由でのトレースデータ取得
• Chronosphere MCPサーバー経由で監視メトリクスをインポート
• Claude Desktopに指示してバグを解決

目新しいものはない

このパターンは以前にも見られました。過去10年間で、Slackは数百のアプリの中核ハブとなり、従業員がチャットウィンドウを離れることなく多様なタスクを管理できるようにすることで、職場の生産性に革命をもたらしました。Slackのプラットフォームは、日常業務におけるコンテキストスイッチングを効果的に削減しました。

Riot Gamesを例に挙げよう。約1,000のSlackアプリを統合した結果、エンジニアはコードのテストと反復に要する時間が27%短縮され、新たなバグの発見速度が22%向上し、機能リリース率が24%増加したと報告している。これらの成果は、主にワークフローの効率化とツール間の切り替えによる摩擦の低減に起因していた。

今、ソフトウェア開発においても同様の変革が進行中だ。MCP連携によって強化されたAIアシスタントが、これら外部ツールへの架け橋となりつつある。事実上、IDEはエンジニアにとって新たなオールインワン・コマンドセンターとなる準備が整っている。まさにSlackが一般知識労働者にとってそうであったように。

MCPはエンタープライズ対応ではない可能性

MCPは比較的新しい標準です。セキュリティの観点では、組み込みの認証や権限モデルがなく、まだ進化中の外部実装に依存しています。 また、アイデンティティと監査に関する曖昧さも存在する。プロトコルは、アクションがユーザーによって開始されたのか、AI自体によって開始されたのかを明確に区別せず、カスタムソリューションなしでは説明責任とアクセス制御を複雑化させる。F5 NetworksのCTOオフィスで著名なエンジニア兼チーフエバンジェリストを務めるロリ・マクヴィッティは、MCPが「我々が長年抱いてきた中核的なセキュリティ前提を覆している」と指摘する。

もう一つの実用上の限界は、コーディングアシスタント内で同時に使用されるMCPツールやサーバーが多すぎる場合に生じる。各MCPサーバーは利用可能なツールのリスト（説明とパラメータ付き）を広告し、AIモデルはこれを処理しなければならない。数十のツールでモデルを溢れさせると、そのコンテキストウィンドウがオーバーフローし、ツール数が増えるにつれて顕著なパフォーマンス低下を引き起こす。 一部のIDE統合では、プロンプトがモデルの処理能力を超過するのを防ぐため、ハードリミットが実装されている（Cursor IDEでは約40ツール、OpenAIエージェントでは約20ツール）。

最後に、ツールが文脈に応じて自動検出・提案される洗練された方法は現時点で存在せず、単にリスト表示されるのみです。これにより開発者はワークフローを円滑に保つため、ツールの手動有効化/無効化やアクティブセットの管理を余儀なくされるケースが多発します。Riot Gamesが1,000のSlackアプリを導入した先例を考慮すれば、管理されていないツールの増殖が企業利用においていかに問題となるかは明らかです。

スウィベルチェアを減らし、ソフトウェアを増やす

過去10年間、更新情報を一元化するSlackチャンネルから「受信トレイゼロ」メール戦略、統合プラットフォームエンジニアリングダッシュボードに至るまで、作業を労働者に届けることの価値が実証されてきた。今、ツールキットにAIが加わったことで、開発者の生産性を飛躍的に高める絶好の機会が訪れた。Slackがビジネスコミュニケーションのハブとなったように、AIコーディングアシスタントはソフトウェア開発のハブとなるのに最適な位置にある。単にコードが書かれる場所ではなく、関連する全てのコンテキストとコラボレーションが集約される場所として。

開発者が生産的なフローを維持できるようにすることで、エンジニアリングの成果を長年阻害してきた絶え間ない思考の切り替えを排除します。

ソフトウェア提供に依存する組織であれば、開発者が実際にどのように時間を費やしているかを厳しく検証する価値があります。その発見に驚くかもしれません。

シルヴァン・カラッシュはRootlyのAIラボを率いる。