MCP

PM による override 適用: 本稿は PM が 6/19 夕方に P0-AM として位置付けた Agentjacking を取り上げる。Cost Reckoning Part 9 (Bochinski ホームコーディング戦略) は週末枠 (6/20 PM〜6/21) に繰越。これは 5/22 GitHub 3800 攻撃 (5 攻撃ベクトル分析) の起点から続く、MCP 経由攻撃ベクトル 6 本目の連鎖記事である。 2026 年 6 月 12 日、Tenet Security の Threat Labs が公開した「Agentjacking」研究は、AI コーディングエージェント時代のセキュリティ議論を「プロンプトインジェクションの亜種」から「アーキテクチャそのものの欠陥」へ引き上げた。本稿では、その攻撃構造、影響範囲、Sentry が公式に「技術的に防御不能」と認めた背景、そして日本企業を含む開発組織が今すぐ取り得る 5 ステップ防御策を、Python 検証コード付きで構造的に整理する。 1. Agentjacking とは何か — 6 段階で実行される「データと命令の混同」攻撃 Agentjacking は、Tenet Security が命名した新しい攻撃クラスで、Sentry の DSN (Data Source Name) と MCP サーバー経由の AI コーディングエージェント の交差点を突く。Tenet の Ron Bobrov、Barak Sternberg、Nevo Poran によれば、 ...

LLMエージェントが「自律的に」サイバー攻撃を実行した——そんな報告が2026年5月下旬に相次いでいる。原因はStarlette（FastAPIの基盤となるASGIフレームワーク）に存在したHostヘッダー処理の脆弱性 CVE-2026-48710（通称 BadHost）だ。 この脆弱性は、従来の「手動攻撃」とは異なり、LLMエージェントが自ら脆弱性を発見・悪用する可能性を示した点で、AIセキュリティ史上初めての事例として注目されている。 脆弱性の概要 Starlette 1.0.0以前では、request.url を構築する際にクライアントから送られてくる Host ヘッダーをそのまま使用していた。この処理に問題があり、攻撃者が細工したHostヘッダーを送信することで、request.url.path の値と実際にルーティングされるパスが乖離する状態を作り出せた。 具体的には、以下のようなリクエストを送ることで認証ミドルウェアを欺くことが可能だった： GET /admin/users HTTP/1.1 Host: example.com/health?x= このリクエストに対し、Starletteは内部で request.url を http://example.com/health?x=/admin/users のように再構築してしまう。一部のミドルウェアが request.url.path を信頼してアクセス制御を行っていた場合、/health が許可リストに含まれていれば /admin/users へのアクセスが通ってしまう。 AIインフラへの影響が特に深刻な理由 この脆弱性がAIエージェント基盤に特に危険な理由は3つある。 1. MCP（Model Context Protocol）の設計思想との相性 MCPサーバーはOAuth discoveryエンドポイントを公開することが仕様上求められる。これらのエンドポイントは意図的に認証なしでアクセス可能に設計されているため、BadHost攻撃の「スケルトンキー」として機能しやすい。 2. ミドルウェアの一般的な実装パターン 多くのAIフレームワーク（FastAPI、vLLM、LiteLLM、BentoMLなど）で、以下のようなパターンが一般的だった： from starlette.middleware.base import BaseHTTPMiddleware class AuthMiddleware(BaseHTTPMiddleware): async def dispatch(self, request, call_next): if request.url.path in self.public_paths: return await call_next(request) # 認証処理... このパターンがBadHost攻撃の標的になる。 3. 325M週次ダウンロードという爆発的な普及 Starletteは2026年時点で週325百万回のダウンロードを記録している。AIエージェントのほとんどがこのフレームワークの上に構築されているため、影響範囲が極めて広い。 実践的な対策 即時対応（優先度高） Starletteを1.0.1以上にアップデート 公式パッチでHostヘッダーの検証が強化された scope["server"] へのフォールバック処理が追加 request.url.path ではなく scope["path"] を使用 ASGIスコープから取得したパスはHTTPリクエストラインから来るため、Hostヘッダーによる汚染を受けない リバースプロキシの導入 nginx、Caddy、TraefikなどでHostヘッダーを検証・正規化する RFC準拠のプロキシは不正なHostヘッダーを拒否する コード例（FastAPI + MCPサーバー向け） # 推奨パターン from starlette.requests import Request @app.middleware("http") async def secure_path_check(request: Request, call_next): # 悪い例: request.url.path を使用 # path = request.url.path # 良い例: scopeから直接取得 path = request.scope["path"] if path in PUBLIC_PATHS: return await call_next(request) ... まとめ BadHostは「AIエージェントが自律的に攻撃を実行する」時代が到来したことを象徴する脆弱性だ。従来のセキュリティ対策が「人間の攻撃者」を前提としていたのに対し、今後は「LLMエージェントが自ら脆弱性を発見・連鎖させる」シナリオを想定した防御設計が必要になる。 ...

MCP（Model Context Protocol）は、2026年7月28日に公開予定の新仕様に向けて、プロトコル史上最大の改訂を迎えている。2026年5月21日に公開されたリリース候補（RC）は、ステートレスコアへの移行、拡張機能フレームワークの導入、認証の大幅強化、そして複数の非推奨機能を含む破壊的変更の集大成だ。 現在の仕様（2025-11-25）を使用しているMCPサーバー・クライアントは、この60日間の移行ウィンドウの中で対応が求められる。本記事では、全ての変更点を5つの柱に整理し、具体的な移行手順をコード例付きで解説する。 MCP 2026-07-28 の全体像 2026-07-28 RCの変更点は、以下の5つの柱に集約される。 ステートレスコア（Stateless Core） — プロトコル基盤の抜本的再設計 運用性レイヤー（Operability Layer） — HTTPヘッダーによるルーティング・トレーシング 拡張機能フレームワーク（Extensions Framework） — MCP Apps・Tasks の正式化 認証強化（Authorization Hardening） — OAuth 2.1 への準拠 非推奨ポリシー（Deprecation Policy） — Roots/Sampling/Logging の代替戦略 MCPは2026年3月時点で月間9,700万ダウンロード、登録サーバー数5,800を超え、Anthropic・OpenAI・Google・Microsoft・AWSが主要アダプターとして参加するまでに成長している。この規模でのプロトコル改訂は、エコシステム全体に影響を与える。 1. ステートレスコア — 最も重要な破壊的変更 なぜステートレスなのか MCPの当初の設計は、初期化ハンドシェイク（initialize/initialized）とセッションID（Mcp-Session-Id）に依存していた。これは「クライアントとサーバーが永続的な接続を張る」前提に基づいており、負荷分散、水平スケーリング、サーバーレス環境との相性が悪かった。 日本語コミュニティでも、この疑問は共有されていた。 MCPって単発のツール呼び出しのインターフェースを提供するだけなのに、なんでコネクション貼りっぱなしなんだ before/after の移行パターン 2025-11-25（現在の実装）: import httpx # 初期化ハンドシェイク session_id = None async with httpx.AsyncClient() as client: # Step 1: initialize resp = await client.post("https://mcp-server.example.com/mcp", json={ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-11-25", "capabilities": {} } }) data = resp.json() session_id = data["result"]["sessionId"] # Step 2: initialized notification await client.post("https://mcp-server.example.com/mcp", json={ "jsonrpc": "2.0", "method": "notifications/initialized" }) # Step 3: 以降は session_id をヘッダーに含めてリクエスト resp = await client.post( "https://mcp-server.example.com/mcp", headers={"Mcp-Session-Id": session_id}, json={ "jsonrpc": "2.0", "id": 2, "method": "tools/list" } ) 2026-07-28（移行先）: ...

2026年5月20日、GitHubは従業員のデバイスが悪意あるVS Code拡張機能によって侵害され、約3,800の内部リポジトリが流出したことを公表した。攻撃者TeamPCPは盗んだソースコードを$50,000で販売中で、買い手がなければ無料公開すると脅迫している。 しかし、この事件は単なる「VS Code拡張機能による侵害」ではない。同時期に発生した4つの関連攻撃を合わせると、5つの攻撃ベクトルが連鎖する未曾有のサプライチェーン攻撃の全体像が見えてくる。本記事では、各ベクトルの技術的詳細と、開発者が今すぐ実践すべき防御策を解説する。 事件の全体像：5つの攻撃ベクトル 2026年5月18日から20日にかけて、TeamPCP（Google Threat IntelligenceがUNC6780として追跡）は、以下の5つの攻撃ベクトルを連続して展開した。 ベクトル1：Nx Console VS Code拡張機能侵害（5月18日） 悪意あるバージョンのNx Console（nrwl.angular-console v18.95.0、2.2Mインストール）がVS Code Marketplaceに公開された。わずか11分間で削除されたが、その間に拡張機能をインストールした開発者のGitHubトークン、npmトークン、AWS認証情報、HashiCorp Vault認証情報、Kubernetes認証情報、1Passwordの認証情報が窃取された。 特筆すべきは、この拡張機能がClaude Codeの設定ファイル（~/.claude/settings.json） を標的にしていた点だ。AIエージェントのAPIキーが平文で保存されている設定ファイルが、新たな攻撃対象となっている。 // 悪意ある拡張機能の概念（実際のペイロードは難読化） const vscode = require('vscode'); const fs = require('fs'); const { execSync } = require('child_process'); function activate(context) { // AIエージェント設定ファイルの収集 const targets = [ '~/.claude/settings.json', '~/.cursor/config.json', '~/.config/openclaw/credentials.json', ]; targets.forEach(p => { if (fs.existsSync(p)) { const data = fs.readFileSync(p, 'utf8'); exfiltrate(data); } }); // 環境変数から全トークンを抽出 const tokens = { ...process.env }; exfiltrate(JSON.stringify(tokens)); } ベクトル2：Mini Shai-Huludワームによるnpmサプライチェーン攻撃（5月19日） TeamPCPはMini Shai-Huludワームの新たな波をnpmエコシステムに解き放った。639の悪意あるnpmパッケージバージョンが323パッケージにわたって公開された。標的となったのはAlibabaの@antvエコシステム（週間約1,600万ダウンロード）で、jest-canvas-mock（1,000万+月間DL）、size-sensorなどの休眠パッケージが乗っ取られた。 この波の最大の特徴は、Sigstoreのビルド証明書（provenance）を実行時に偽造する新手法だ。ワームがFulcioとRekorを実行時に呼び出し、悪意あるパッケージに対して正当なSigstore署名証明書を生成する。証明書バッジはグリーン表示されるが、ビルドチェーン自体は攻撃者に支配されている。Endor LabsのPeyton Kennedyは「証明書はパッケージがどこでビルドされたかを示す。ビルドが承認されたかどうかは示さない」と指摘する。 2種類の配送メカニズム Type 1 — ファントムコミットドロッパー: jest-canvas-mockやsize-sensorなどの休眠パッケージに、optionalDependenciesエントリを1行追加するだけの手法。npmがgithub:依存関係を解決する際、prepareライフサイクルフックが発火し、Bunランタイムで難読化されたペイロードを実行する。 ...

はじめに 2026年5月19日、Google I/O 2026の基調講演でSundar Pichaiが発表した Gemini Spark は、単なるAIアシスタントのアップデートではない。これはGoogleのAI戦略におけるパラダイムシフトを象徴するプロダクトだ。 従来のGeminiが「質問をすれば答えが返ってくる」受動的アシスタントだったのに対し、Sparkは24時間365日クラウド上で動作し、ユーザーに代わってタスクを自律実行する「パーソナルAIエージェント」である。本稿では、アーキテクチャの詳細から実際の使い方、競合との比較、開発者向け統合までを包括的に解説する。 なお、本サイトではすでにGoogle I/O 2026の包括レポートとAntigravity 2.0の実践ガイドを公開している。本記事はI/O Deep Diveシリーズの最終回として、Gemini Sparkに特化した完全ガイドを提供する。 Gemini Sparkとは：3層アーキテクチャの全貌 Gemini Sparkの最大の特徴は、単なるモデルの改良ではなく、インフラからアプリケーションまでを統合した3層スタックとして設計されている点にある。 第1層：Gemini 3.5 Flash（モデル層） Sparkの中核エンジンは Gemini 3.5 Flash である。このモデルは出力速度280トークン/秒以上を達成し、前世代の最上位モデルGemini 3.1 Proをほぼすべてのベンチマークで上回る。エージェント向けベンチマークでは、OSWorld-Verified 78.4%、Toolathlon 56.5%、MRCR v2 77.3%（128k avg）を記録しており、単なる高速モデルではなくエージェントワークロードに最適化されたフロンティアモデルであることがわかる。 重要なのは、Sparkがこのモデルを 推論時の思考レベルの調整 が可能な形で利用している点だ。タスクの複雑さに応じて思考の深さを変えることで、コストと品質のトレードオフを動的に最適化する。 第2層：Antigravity Harness（オーケストレーション層） Sparkの「24時間稼働」を支えるのは、Antigravity 2.0と同じワークオーケストレーション基盤である。この層は以下の機能を提供する： タスク分解とサブエージェント管理：ユーザーの指示を複数のサブタスクに分解し、並列実行する 状態永続化：タスクの途中状態をクラウド上に保持し、デバイスの電源状態に関わらず処理を継続 実行検証ループ：計画→実行→評価→次のアクション決定、という反復サイクルを自律的に回す ヒューマンインザループ：高リスク操作（支払い、メール送信、ファイル削除）ではユーザーの承認を要求 第3層：永続Cloud VM（実行層） Sparkの決定的な差別化要因は、専用のGoogle Cloud仮想マシン上で動作する点にある。これは単なるバックグラウンドプロセスではなく、以下の特性を持つ： ノートPCを閉じても動作継続 スマートフォンのロック中もタスク実行 インターネット接続があれば、いつでもどこでも結果を確認可能 タスクの途中でデバイスを変更しても状態を引き継ぐ 競合のClaude Coworkがローカルファースト、ChatGPT Agentがブラウザベースであるのに対し、Sparkのクラウドネイティブな設計は**「エージェントに仕事を任せて寝る」**というユースケースを現実のものにする。 Skillsシステム：繰り返しタスクの自動化 Sparkの核心的機能は Skills（スキル）システム である。これは、頻繁に行うマルチステップのワークフローを「Skill」として保存し、定期的に自動実行する仕組みだ。 Skillの定義方法 Skillは自然言語で記述する。Sparkは過去の実行パターンから学習し、自動的にSkillを提案することも可能だ。 Skill名: "週次エンジニアリングレポート" トリガー: 毎週金曜日 16:00 実行内容: 1. 今週のGitHub Organizationの全リポジトリからコミット履歴を収集 2. 対応するLinearチケットの進捗ステータスを取得 3. Google Sheetsのテンプレートにデータを整形して書き込み 4. CTOとチームリードにGmailでサマリーを自動送信 トリガータイプ トリガー種別 説明 ユースケース スケジュール 特定の日時・間隔で実行 週次レポート、月次ダッシュボード 条件ベース 特定の条件が満たされたら実行 重要メールの着信検知、株価アラート イベント駆動 カレンダー変更や新規ドキュメント作成に応じて実行 会議後の議事録自動作成 手動トリガー ユーザーが明示的に実行 アドホックな調査・分析 Skillの学習と改善 Sparkはフィードバックループを通じてSkillを継続的に改善する。たとえば、50通の送信済みメールを分析して執筆スタイルを学習し、「ゴーストライターSkill」として再利用できる。直近の実行結果にサムズアップ/ダウンを付けることで、Sparkの動作を徐々にユーザーの期待値に合わせていく。 ...

3億ドルの「インフラ拒否」—何が起きたのか 2026年5月18日、AnthropicはSDK（Software Development Kit）自動生成ツール企業 Stainless の買収を発表した。買収額は 3億ドル超と報じられている（The Information）。一見すると地味な「開発ツールの買収」だが、この取引の本質は AI業界のインフラ層を支配するという、これまでにない戦略的動きだ。 Forbesはこの買収を「モデル戦争」ではなく「インフラ拒否（infrastructure denial）プレイ」と評している。その核心にあるのは、StainlessがOpenAIやGoogleといった競合他社のSDKも生成していたという事実だ。 Stainlessとは何者か Stainlessは2022年に元Stripeエンジニアの Alex Rattray がニューヨークで創業したスタートアップだ。同社の製品は、API仕様書（OpenAPI Specification）から自動的にプロダクション品質のSDKを生成する。対応言語は以下の通り： Python TypeScript Go Java Kotlin そして何より注目すべきは、Stainlessの顧客リストだ。OpenAI、Google、Meta、Cloudflare、Replicate、Runway、そしてAnthropic自身が含まれる。開発者が pip install openai や npm install @google/generative-ai を実行したときにインストールされるパッケージは、Stainlessの生成ツールによって作られていたのである。 なぜこれが重要なのか：インフラ拒否のメカニズム Anthropicは買収後、Stainlessのホステッドプロダクトをすべて終了すると発表した。既存顧客が生成したSDKの所有権と修正権はそのまま保持されるが、新たな生成エンジンは利用できなくなる。つまり： OpenAIとGoogleは、自社SDKの生成基盤を失う 今後は自前でSDK生成パイプラインを構築するか、SpeakeasyやKonfig、Fernなどの代替ツールに移行する必要がある 開発者が体験する「APIの品質」という接点を、Anthropicが間接的にコントロールすることになる この戦略の巧妙さは、モデル競争ではなく開発者エコシステムの接点を支配する点にある。Anthropicのプラットフォームエンジニアリング責任者Katelyn Lesseは次のように述べている： 「エージェントは接続できる先があって初めて有用になる。Stainlessチームを迎え入れることで、Claudeのデータやツールへの接続能力をさらに強化していく」 AnthropicのM&A戦略：6ヶ月で4社買収 Stainless買収は、Anthropicのここ6ヶ月における 4件目の買収 だ。過去の買収と合わせて見ると、戦略の全体像が浮かび上がる： 企業 買収時期 役割 Bun 2026年初頭 JavaScriptランタイム → Claude Codeの高速化 Vercept 2026年前半 コンピュータ操作技術 → Claude Computer Useの基盤 Coefficient Bio 2026年 創薬AIチームの内製化 Stainless 2026年5月 SDK/API接続基盤 → エージェントエコシステムの根幹 これらの買収に共通するのは、「モデルを作る会社」から「プラットフォームを組む会社」への変貌だ。Anthropicは単なるLLMプロバイダではなく、AIエージェントが動作するためのインフラ全体を垂直統合しつつある。 開発者への実質的な影響 OpenAIとGoogleの立場 両社は潤沢な資金と優秀なエンジニアリングチームを持つ。SDK生成を内製化するのは時間の問題だろう。しかし課題もある： ...