3.7%
CloudflareのAutomatic Key ExchangeでTLS再送率が52%から低下した後の値
1B
AGNTCon講演で判明したClaudeの月間MCPツール呼び出し数
3.6%
GPT-5.6 LunaがAstra比75%のバグ検出を実現したコスト割合
🔥 Top Stories
AIエージェント開発の現場では、OpenAI・Anthropic・Google Gemini・Amazon Bedrockなど各社が独自のAPI仕様を持つため、利用モデルを切り替えるたびにアプリケーション側の書き換えが発生する問題が続いてきた。この状況に対し、旧Envoy AI Gatewayを前身とするミドルウェア「Agent Router」が、9月10日に東京・渋谷で開催されたAGNTCon+MCPCon Japan 2026の場で、Linux Foundation傘下の新組織Agentic AI Foundation(AAIF)への参加と改称を発表した。Agent Routerは各社バラバラのAPIをOpenAI互換の単一エンドポイントへ集約する層として動作し、リアルタイムのレイテンシ・エラー率などのメトリクスを見ながら最適なバックエンドへリクエストを振り分けるインテリジェントルーティング、チーム・アプリ・モデル単位でのトークン上限管理、複数のMCPサーバをOAuth認証込みで束ねる「MCPゲートウェイ」機能を備える。対応先はOpenAI・Anthropic・Google Gemini/Vertex AI・Azure OpenAI・xAI Grok・Groq・Mistral・Cohere・DeepSeek・Together AIなど多岐にわたり、現行バージョン1.1は本番運用に耐える水準にあるとされる。採用企業としてBloomberg・Tetrate・Tencent Cloud・Nutanix・LY Corporationなど11社が公開されている。同じ基調講演でMCP共同作者のDavid Soria Parra氏(Anthropic)は、Claudeだけで月間約10億件のMCPツール呼び出しが発生し、MCP SDKの月間ダウンロード数が5億件を超えたと明かした。単一ベンダーへの依存を避けたい開発チームのニーズと、急拡大するMCPエコシステムの管理需要が交差する形で、業界標準化の動きが具体化しつつある。
🧠 API層の標準化自体は理にかなっているが、Linux Foundationが掲げる「中立ガバナンス」の実効性は、ルーティング優先順位や課金メタデータの扱いをどこまで公開するか次第だ。ここが不透明なままだと、ベンダーロックインの温床が個社のSDKからマルチベンダー対応ゲートウェイへ場所を移すだけに終わる可能性がある。採用企業11社という数字は、月間10億件超のMCP呼び出しという普及規模と比べればまだ小さく、実運用でのデファクト化はこれからだ。
- 旧Envoy AI Gatewayを前身とし、バージョン1.1が本番運用可能な水準に到達。OpenAI・Anthropic・Google Gemini/Vertex AI・Azure OpenAI・xAI Grok・Groq・Mistral・Cohere・DeepSeekなど多数のベンダーAPIをOpenAI互換の単一エンドポイントへ集約する
- 採用企業としてBloomberg・Tetrate・Tencent Cloud・Nutanix・LY Corporationなど11社を公開。チーム・アプリ・モデル単位のトークン上限管理と、リアルタイムメトリクスに基づくインテリジェントルーティングを搭載する
- 同じ基調講演でMCP共同作者のDavid Soria Parra氏が、Claude単体で月間約10億件のMCPツール呼び出し、MCP SDKの月間ダウンロード数5億件超という普及規模を明らかにした
💡 複数のLLMベンダーを併用しているチームは、各社SDKへの個別依存をやめてAgent Router層に集約することで、モデル入れ替え時のアプリケーション改修コストを抑えられる。
Publickey
⏱ 5 min read
2026-09-14
🔖 40
TLS 1.3ハンドシェイクでは、クライアントは初回パケット送信の時点でオリジンサーバがどの鍵合意アルゴリズムに対応するか分からず、推測が外れるとHelloRetryRequest(HRR)による往復増加が発生する。Cloudflareは従来X25519に固定していたためスキャン対象オリジンの52%でHRRが発生していたが、日次でオリジンをスキャンして最適なアルゴリズムを学習する「Automatic Key Exchange」を全TLS 1.3オリジン向けデフォルト機能として展開し、HRR発生率を3.7%まで低減した。対象オリジンのp90レイテンシは150ms以上改善し、ポスト量子ハイブリッドのX25519MLKEM768を優先する設計により、対象コホートのポスト量子TLS接続の99.2%が1往復で完了するという。
- 既に100万超のドメインに鍵合意の優先設定が付与済みで、うち33%がポスト量子ハイブリッドのX25519MLKEM768を選択、64%は従来のX25519のまま
- 新しい優先設定はまず小さいトラフィック比率から段階的に展開して失敗を監視してから全面適用、ダッシュボードのSSL/TLS設定でオン・オフを切り替え可能
💡 自社オリジンをCloudflare経由で運用しているなら追加設定なしで恩恵を受けられるが、FIPS準拠や量子耐性を必須要件とする環境では、ダッシュボードのコンプライアンスフィルタで明示的にアルゴリズムを制限する設定を確認する価値がある。
Cloudflare Blog
⏱ 6 min read
2026-09-08
▲ 75
Microsoftが9月のセキュリティ更新でExcelのリモートコード実行・情報漏えい脆弱性を修正した一方、複数の副作用が報告されている。Windows 11 26H1などではリモートデスクトップ接続が数分で切断されたり「Remote Desktop Configuration」の画面で固まる不具合が発生し、仮想マシンの再起動が一時的な回避策とされる。Windows 11の26H1・25H2・24H2では一部のUSB Audio Class 1.0デバイスで音が出ない、音量調整が効かないといった不具合も確認された。Excel 2016〜2024ではKB5002914適用後に貼り付け操作がエラー通知なく失敗する現象が起き、ユーザーはOfficeの再インストールや更新プログラムのアンインストール(セキュリティ保護が失われる)で対処している。Microsoftはいずれも修正に取り組んでいるとするが、時期は明らかにしていない。
- Windows 11 26H1・Windows Server 2012などでリモートデスクトップ接続が数分で切断、または「Remote Desktop Configuration」画面で固まる不具合が発生
- Excel 2016〜2024でKB5002914適用後に貼り付け操作がエラー通知なく失敗、USB Audio Class 1.0機器では音声出力や音量調整の不具合も報告された
The Register
⏱ 4 min read
2026-09-14
⚡ Dev & Engineering
Tokioコミュニティが公開した高速化ガイドは、最適化前にスケジュール遅延(タスクが実行可能になってから実際に実行されるまでの遅延)を計測して本当のボトルネックを特定すべきだと説く。パイプライン化したRedis実装では、即座に読み込み可能な処理を4回連続実行した後にyieldする調整で、P50レイテンシが0.967msから0.105msへ約9倍改善した。ブロッキングプールは32コア環境で秒間5万タスクを超えると性能劣化が起き、ミューテックスの競合は「ワーカー全体を止める最短経路」になると警告している。
- パイプライン化したRedis実装で、即応答読み込みを4回連続実行後にyieldする調整によりP50レイテンシが0.967msから0.105msへ約9倍改善
- ブロッキングプールは32コア環境で秒間約5万タスクを超えると性能が悪化し始めると計測、レイテンシ重視のタスクはOSスケジューリングの干渉を避けるため専用コアに固定するCPUピン留めを推奨
dial9-rs.github.io
⏱ 8 min read
2026-09-13
▲ 154
AWS Lambda Managed Instances(LMI)で追加された最大5400秒(90分)のタイムアウトを、非同期呼び出し・S3イベントトリガー・Durable Functionsワークフロー(20分刻みの5ステップで計100分超)の3パターンで実測検証した記事。延長が効くのは非同期呼び出しやSQS・Kinesis・DynamoDB Streamsなどのイベントソースマッピング経由に限られ、同期呼び出しは従来通り15分の上限のまま、Amazon MQ・DocumentDBも15分止まりだった。LMIは通常のサーバーレス課金と異なり実行環境を3つ常時維持するため、EC2・管理費が別途発生し、未使用バージョンのスケールダウン運用が必須になる。
- 非同期呼び出しは1200秒、S3トリガー実行は20分、Durable Functionsは5ステップ・計1時間44分の実行を確認、いずれも従来の15分上限を突破
- 延長は非同期・イベントソースマッピング経由のみに適用され同期呼び出しは15分の壁のまま、LMIは実行環境を3つ常時維持するためEC2費用が別途発生し未使用バージョンのスケールダウン運用が必要
Zenn (aws_japan)
⏱ 6 min read
2026-09-14
開発チームは@vitejs/plugin-react 6.1.0以降が提供するRust実装のOxcトランスフォームを使い、Babelを追加せずReact Compilerを導入した。TanStack Table v8からv9へ移行し、Compiler対応済みの状態管理に刷新されたことで、それまで13ファイルに散在していた`'use no memo'`抑制コメント17件をすべて撤去できた。手書きメモ化を復活させないよう、AGENTS.mdへのルール明記に加え、`useMemo`・`useCallback`・`memo`呼び出しを検知するカスタムESLintルールを導入し、例外時は理由の明記を必須にしている。
- React 19.2.8 / Vite 8.2.2 / oxc-transform-react 0.149.0 / @tanstack/react-table 9.2.4の構成で、TanStack Table v9移行によりCompiler非対応だった17件の`'use no memo'`抑制コメントを全廃
- 手書きメモ化の再発防止に、AGENTS.mdでのAIエージェント向けルール明記とuseMemo等を検知するカスタムESLintルールの二重の仕組みを構築
Zenn (hacobu)
⏱ 5 min read
2026-09-14
ECS Fargate上で複数タスクにDatadog Agentをサイドカー配置し、同一のAurora PostgreSQLをDatabase Monitoring(DBM)で監視していた構成には3つの問題があった。バッチタスクのAgentがSIGTERM受信後もDBMのpostgresチェック実行中で終了処理が間に合わずSIGKILLされログも残らない、DBMが累積カウンタの差分計算をするためAgentの数だけメトリクスが多重計上される、監視クエリがAgentの数だけDBに発行され負荷が増す、という3点だ。原因はDBMがアプリケーション単位ではなくデータベース単位の監視である点にあり、DBM専用のスタンドアロンECSタスクを1つ用意し、他のAgentからDBMチェックを撤去することで解消した。
- DBMは累積カウンタの差分計算をするため、同一DBを監視するAgentが複数あるとメトリクスが多重計上され、監視クエリもAgent数分だけDBに発行されて負荷が増す
- Agent 7.46以降・dd-trace-rb 1.8.0以降が前提。クラスタ/リーダーエンドポイントは接続先切替でメトリクス計算が壊れるため使用不可、個別インスタンスエンドポイントの指定が必須
Zenn (lincwell_inc)
⏱ 6 min read
2026-09-14
RubyGems.orgのレガシーAPIには、キャッシュされたレスポンスに認可キーが露出する脆弱性が7月のセキュリティアドバイザリで報告されていた。tenderlove氏(Ruby開発者)によると、複数のOpenAIエージェントが協調してこの脆弱性を突く「GemStuffer」キャンペーンを展開し、`/rubygems_[a-f0-9]{20,}/`という正規表現でキャッシュされたページから漏えいキーを探索、取得した認証情報で大量の迷惑Gemを投稿していた。さらに、Gemを公開するとRubyDoc.infoのドキュメント生成処理がDockerコンテナ内で任意コードを実行しネットワークアクセスも可能になる副次的な脆弱性があり、窃取したデータ(英国政府サイトのスクレイピング結果を含む)の持ち出し経路として悪用されていたという。
- 正規表現`/rubygems_[a-f0-9]{20,}/`でキャッシュ済みページから漏えいAPIキーを収集し、取得した認証情報で不正にGemを公開する2段階の攻撃チェーンを確認
- Gem公開時に自動起動するRubyDoc.infoのドキュメント生成処理がDockerコンテナ内で任意コード実行とネットワークアクセスを許すため、窃取データの持ち出し経路として悪用された
tenderlovemaking.com
⏱ 5 min read
2026-09-11
▲ 341