7月31日、Leela Kumiliが「Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review」と題した記事を公開した。この記事では、DropboxがMCP(Model Context Protocol)と社内ナレッジシステムDashを統合し、セキュリティ設計の意図をコードレビュー時に自動的に参照可能にした取り組みについて詳しく紹介されている。
「設計時の意図」がコードレビューで消える問題
多くの大規模エンジニアリング組織が抱える構造的な問題がある。脅威モデルや設計ドキュメント、セキュリティ要件はデザインレビューの段階で作成されるが、コードベースとは別の場所に保管されることが多い。システムが進化するにつれてドキュメントは陳腐化し、コードレビュー時には「なぜこの要件が存在するのか」という背景が失われる。結果として、レビュアーが設計の意図とコード変更を手動で照合する作業が発生し、要件の見落としや不一致が生じやすくなる。
Dropboxはこの問題に対し、MCPとDashを組み合わせたアーキテクチャで対処した。
MCPとDashによるアーキテクチャ
/filters:no_upscale()/news/2026/07/dropbox-mcp-ai-code-review/en/resources/1dropbox-mcp-header-1785008779688.jpeg)
MCP + Dash Architecture Overview(出典: Dropbox Tech Blog)
DashはDropbox社内の文書システムをまたいでインデックスを作成し、既存のアクセス制御ポリシーを維持しながら組織のナレッジをクエリ可能にする中央集権的なレイヤーとして機能する。
MCP(Model Context Protocol)はAIシステムが開発者ワークフロー内でこのコンテキストを取得・活用するための標準化されたプロトコル層として機能する。MCPはAnthropicが提唱し、現在はOSSコミュニティを中心に広く標準化が進んでいる仕様であり、AIエージェントが外部ツールやデータソースと標準的なインタフェースでやり取りするための共通基盤として定着しつつある。
プルリクエストが作成されると、システムは関連するコード変更を特定し、MCPを経由してDashから紐づく脅威モデルとセキュリティ要件を取得する。セキュリティ上のコンテキストはコードレビューのインタフェース内に直接表示されるため、エンジニアが別の文書システムを検索する必要がなくなる。
「自動化」ではなく「可視化」が設計思想の核心
InfoQはDropboxのEngineering LeadであるIshan Mishraにインタビューを行った。その中で浮かび上がったのは、このシステムが「AIによるセキュリティ判断の自動化」を目指していないという点だ。
なぜCIやコードレビューシステムに直接組み込まず、MCPを選んだのかという問いに対し、Mishraは次のように答えている。
特定のワークフロー向けの一品物の統合を作ることは避けたかった。MCPはDashをコンテキストプロバイダーとして公開する標準的な手段を提供してくれた上に、早期段階でPoCを構築し素早くイテレーションすることも可能にしてくれた。コードレビューのエージェントは情報がどこにあるか、どう取得されるかを知る必要がない。関連するコンテキストを要求するだけで、Dashがバックグラウンドで取得とアクセス制御を処理する。
このアーキテクチャの再利用性も重要な設計判断だ。セキュリティレビューが最初のユースケースだが、プライバシー要件・コンプライアンス検証・APIガバナンス・設計レビューといった他のガバナンス中心のワークフローへの展開も想定されている。
「誤った安心感」を与えないための仕組み
「システムが正確だとエンジニアが過信するリスク」についてMishraは3点を挙げた。
- トレーサビリティ: レビュアーは要件・その出典・関連コードを確認できる。要件と実装の両方に根拠がなければ、その指摘はシステムから出力しない。
- 判断の補助であり代替ではない: 目標はAIがコードを認定したとエンジニアに思わせることではなく、合意済みの要件がワークフローから消えにくくすることだ。
- フィードバックループ: 指摘が正確か・関連性があるか・実行可能かについての開発者フィードバックを継続的な改善に活用する。
スケーラビリティ面の最大の課題として、Mishraは「正しいコンテキストを取得すること」を挙げた。大規模な組織では設計文書とコードが直接紐づいていないため、キーワード検索だけでは不十分であり、セマンティック検索の活用が前提となる。セマンティック検索は文書間の意味的な近さを埋め込みベクトルで評価するアプローチで、Dropboxのケースではコード変更と設計ドキュメントを意味的に照合するために用いられている。一方で、コードレビュー中に開発者はすでに大量の自動フィードバックを受けているため、偽陽性に対する許容度は極めて低いという現実がある。Mishraはこの点について、関連性の低い指摘がノイズとして蓄積するとシステム全体への信頼が損なわれるリスクを明示的に認識しており、精度とリコールのバランスを継続的にチューニングすることが運用上の主要課題であると述べている。
「速くするだけでなく、組織の意思決定を保存する」
Mishraが最後に述べたこの一文が、プロジェクト全体の方向性を端的に表している。
多くのAIコーディングワークフローは、コードの生成やレビューを単独で行うことに集中している。それは有用だが、そのコードが存在する理由の背後にある広いコンテキストを見逃してしまう。AIの支援は単にエンジニアを速くするだけでなく、意思決定が行われる時点で組織の制度的知識を保存するものであるべきだ。
詳細はDropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Reviewを参照していただきたい。