1. Model Context Protocolのリリース候補版でステートレスなHTTPコアを導入
今回のリリース候補版は、Model Context Protocol (MCP) の初期リリース以来、最大の改訂となります。コアプロトコルをステートレスに再設計することで、クラウドやHTTPベースのサーバーレス環境へのデプロイが簡素化され、エージェントの相互作用をより容易にスケールできるようになります。開発者は、新しい認証仕様を確認し、安定版リリース前の破壊的変更に備える必要があります。
- • HTTPインフラストラクチャ向けに最適化されたステートレスコアを搭載。
- • 拡張機能の公式サポートを追加し、OAuth/OpenID Connectに準拠した認証を実装。
- • 破壊的変更を導入し、新しい正式な非推奨ポリシーを策定。
- • 仕様の最終版は7月28日にリリース予定。
Model Context ProtocolがOAuth/OpenID認証を備えたステートレスなHTTPコアへ移行し、破壊的変更が導入されるため、既存のカスタムMCPサーバーの即時アップデートが求められます。
2. 認証プロバイダーがMCPサーバー向けマネージドOAuthセキュリティを提供開始
タスク特化型AIエージェントがエンタープライズアプリケーションに統合されるにつれ、ツール呼び出しの保護が優先事項となっています。これに対応するため、業界では保護されたHTTPベースのMCPデプロイメント向けに、PKCEを用いたOAuth 2.1の標準化が進んでいます。WorkOSのエンタープライズ向けSSO統合からArcadeのIDベースの権限ランタイムまで、主要なID・統合プロバイダーがネイティブツールをリリースしており、開発者はエージェント群に対して安全でポリシーに準拠した認証を実装できるようになりました。
- • Model Context Protocol (MCP) は2025年後半までにPythonとTypeScriptの合計ダウンロード数が月間9,700万回に到達。
- • MCPのHTTPベースのデプロイメントには、PKCEを用いたOAuth 2.1、HTTPS、およびProtected Resource Metadata (RFC 9728) が必要。
- • WorkOSは、SSO、SCIM、およびきめ細かな認可 (FGA) と統合されたMCP互換のOAuthを提供。
- • OktaのAuth0は、2026年5月6日に「Auth for MCP」を一般公開。
- • Stytch、Arcade、CloudflareのAgents SDKなどのプラットフォームも、エッジネイティブでポリシー強制型のMCPサポートを提供。
エージェントによるツール呼び出しとMCPサーバーを保護するには、標準化されたOAuth 2.1認証の実装が必要であり、これが主要なIDプロバイダーでネイティブサポートされるようになりました。
3. WorkOSがエージェント登録用オープンプロトコル「auth.md」を公開
新しいauth.mdプロトコルは、自律型エージェントとサービスが互いを発見し、信頼するためのプロセスを簡素化します。ドメイン上にシンプルなMarkdownファイルを配置することで、サービスはサポートされている登録フロー、スコープ、資格情報管理ルールを公開できます。これにより、エージェントはプログラムを通じて登録を行い、既存のOAuth標準を使用して同期的に資格情報を受け取ることが可能になります。
- • サービスのドメインでホストされるMarkdownファイルを使用してエージェント登録を標準化。
- • 既存のOAuth標準の上に構築されており、インフラストラクチャに依存しない。
- • ID-JAGを利用した「Agent verified」フローにより、人間を介さない同期的な資格情報発行を実現。
- • ワンタイムパスワード (OTP) を利用した「User claimed」フローにより、登録をユーザーに紐付けることが可能。
独自の認証インフラに依存することなく、AIエージェントの受け入れに向けた標準的な登録エンドポイントを開発者が公開できるようになります。
4. Together AIが2ビットKVキャッシュ量子化システム「OSCAR」をリリース
長文脈モデルの推論では、KVキャッシュに必要な膨大なメモリフットプリントがボトルネックとなることがよくあります。OSCAR (Offline Spectral Covariance-Aware Rotation) は、アテンション認識型の回転行列を使用して量子化ノイズを敏感な方向から逸らすことで、この問題を回避します。INT2の履歴圧縮と、直近およびシンク（sink）トークン用の小さなBF16バッファを組み合わせることで、精度の大幅な低下やハードウェアの肥大化を招くことなく、コンテキスト制限を拡張できます。
- • 100Kコンテキスト長において、KVキャッシュメモリを最大8倍削減し、デコードスループットを最大3倍向上。
- • 混合精度レイアウトを採用：最初の64個のシンクトークンと最後の256個のトークンをBF16、履歴トークンを2ビットINT2に圧縮。
- • Qwen3-32BやGLM-4.7-FP8などのモデルでBF16に近い精度を維持。
- • SGLangに完全統合されており、ページド・アテンションとプレフィックス・キャッシュをサポート。
- • 事前計算された回転行列とクリップ閾値はRotationZooリポジトリで利用可能。
ローカルまたは専用エンドポイントで長文脈LLMを実行する際の膨大なメモリフットプリントを、推論精度の低下を最小限に抑えつつ7〜8倍削減します。
5. NuExtract3：構造化ドキュメント抽出用4BオープンウェイトVLM
NuMarkdownモデルの後継であるNuExtract3は、非構造化の視覚的ドキュメントをクリーンな構造化Markdownやデータ形式に変換することに特化しています。メモリ要件が低いため、専用のセルフホスト型ドキュメント処理パイプラインをローカルやサーバーレス環境で実行したいコスト意識の高い開発者にとって非常に魅力的です。
- • Apache-2.0ライセンスでリリースされ、Qwen3.5-4Bをベースに構築。
- • PDF、スクリーンショット、フォーム、テーブル、請求書からの構造化抽出用に設計。
- • 実行に必要なVRAMはわずか4GB。
- • Safetensors、GGUF、MLXウェイトと互換性あり。
- • vLLM、SGLang、llama.cppでの動作を確認済み。
高精度なドキュメント解析やOCRタスクにおいて、商用APIに代わる非常に効率的でセルフホスト可能な選択肢を提供します。
6. Clerkがエージェント向けヘッドレス認証用オープンソースCLIをリリース
認証管理をスクリプト可能なコマンドラインインターフェースに移行することで、Clerkはテナントアクセスを管理するためにブラウザのダッシュボードにログインする必要性を排除しました。このCLIはオープンソースであり、エージェントを念頭に置いて設計されているため、開発者が自動化プロセスに対してID境界の安全かつ詳細な制御を与えるためのクリーンな経路を提供します。
- • スキャフォールディング用の「clerk init」、コード設定用の「clerk config」、ヘッドレス操作用の「clerk api」が含まれる。
- • ユーザー、組織、セッションをプログラム的に取得可能。
- • オープンソースであり、エージェントハーネスへの統合に最適化。
自動化されたエージェントが、手動のダッシュボード操作なしでID管理タスクをプログラム的に実行できるようになります。
7. Reasonix：ターミナルベースのDeepSeekコーディングエージェント
Reasonixは、コーディングループをターミナル内に留めたい開発者をターゲットにしています。DeepSeekのネイティブなプレフィックス・キャッシュ動作を中心にエージェントの相互作用を最適化することで、コンテキストを多用するマルチターンプログラミングタスクに伴う反復的なプロンプト処理コストを大幅に削減します。
- • ターミナル環境向けに特別に設計された、DeepSeekネイティブのコーディングエージェント。
- • 長時間実行される開発者セッションを維持するためのプレフィックス・キャッシュの安定性を中心に構築。
- • 長時間のコード編集時におけるトークンコストを最小限に抑えるよう最適化。
安定したキャッシュを活用することで、開発者は低トークンコストで長時間かつインタラクティブなターミナルコーディングセッションを実行できます。
8. llama.cppのPRでエージェントコーディング向けのプロンプト再処理を最適化
インタラクティブなコーディングツールは過去のメッセージを書き換えたりプロンプト履歴を修正したりすることが多く、従来はllama.cppが数万トークンの再処理にリソースを浪費していました。この最適化により、エージェントセッション中の待機時間が劇的に短縮されます。ローカルワークフローを実行する開発者は、モデルが生成した「思考（thinking）」タグを保持することがコンテキストキャッシュの整合性を維持するのに役立つことにも留意してください。
- • 「opencode」のようなエージェントツールがコンテキストを書き換えることで最大70kトークンの再処理が発生する問題を解決。
- • llama.cppがプロンプトコンテキストの変更されたセクションのみを再処理するように保証。
- • 思考/推論タグを削除するモデルも、完全なプロンプト再処理をトリガーする可能性があることに注意。
- • 推論コンテキストの損失を避けるため、（Qwen 3.6のように）「思考の保持」を有効にすることを推奨。
会話履歴を頻繁に書き換えたり、推論タグを削除したりするローカルコーディングアシスタントのインタラクティブな遅延を改善します。
9. llama.cppのCUDAアップデートで高速ウォルシュ・アダマール変換を実装
KVキャッシュの量子化は、長文脈モデルをコンシューマー向けGPUに収めるための一般的な方法ですが、計算オーバーヘッドが発生する可能性があります。このプルリクエストは、CUDAデバイス上のそのボトルネックを直接ターゲットにしています。高速ウォルシュ・アダマール変換の統合により、キー・バリュー量子化操作が高速化され、ローカルでのテキスト生成がより軽快になります。
- • CUDAベースのKVキャッシュ量子化向けに高速ウォルシュ・アダマール変換 (FWHT) を実装。
- • プロンプト処理で1〜2%、トークン生成で7〜9%のパフォーマンス向上を実現。
- • NVIDIA RTX 5090を使用し、8ビット量子化キー/バリュー (-ctk q8_0 -ctv q8_0) を備えたgemma4 26Bでテスト済み。
NVIDIA GPUで量子化されたローカル推論を実行している開発者は、最大9%のスループット向上を即座に実感できます。
10. OpenAIがマルチエージェントシステム向けの「マクロ評価ワークフロー」を立ち上げ
複雑なエージェント設定のデバッグは、マルチステップ推論の非決定的な性質のため、手動で行うのが非常に困難です。OpenAIの新しいマクロ評価アプローチは、大量の実行にわたって実行メトリクスを集約することでこれを解決します。開発者は、個別のエッジケースのバグを追うのではなく、エージェント群全体にわたる繰り返しの失敗パス、アーキテクチャのボトルネック、およびシステム的な問題を特定できるようになりました。
- • トレースの集団全体にわたるマクロパターンの分析に焦点を当てる。
- • 孤立した個別のエージェントの失敗を評価することから脱却。
- • マルチエージェントデプロイメントの予測可能性を向上させるためにOpenAIが導入。
エージェントの評価を、個別の失敗に対する脆い手動チェックから、実行トレースの集団レベルの集約分析へとシフトさせます。