概要 Cloudflareは、AIエージェントがオンラインで安全に取引を行うための2つの新機能を発表した。1つは、エージェントの恒久的な身元を表す人間可読の識別子体系「cloudflare.pay」、もう1つは人間が設定した上限内でエージェントが自律的に支払いを行える「Cloudflare Wallets」だ。企業がやり取りの相手を正規の顧客代理AIか不正なプログラムかを判別できないという課題に対応し、AIエージェントによる自律的な商取引の信頼基盤を整備する狙いがある。Cloudflareは今回の発表の背景として、「エージェントには安定した識別子がなく、API代金を支払う本質的な方法も欠落している」という2つの根本的な問題を挙げている。 背景・課題 現状、AIエージェントが新しいAPIを試すことには多くの障壁がある。ログインページは人間の利用を前提に設計されており、支払い方法の追加には人間の介入が必要で、APIキーの発行手続きも煩雑だ。こうした摩擦は、エージェントが自律的に必要なサービスを発見し利用するという体験を大きく妨げている。加えて、マーチャント側にも問題がある。アクセスしてきた相手が正規の顧客の代理として動くAIエージェントなのか、それとも悪意あるボットなのかを判別する手段が乏しく、AIエージェント経済の健全な発展を阻んでいるという。 技術的な仕組み Cloudflare Walletsは、HTTPリクエストに支払い情報を直接添付できるマイクロペイメントプロトコル「x402」を採用する。これにより、AI推論やデータ、コンテンツへの支払いをリクエストの流れの中でシームレスに処理できる。 ウォレットは2種類に分かれる。人間のCloudflareアカウント所有者が保有する「アカウントウォレット」は、資金の追加や仮想ウォレットへの支出権限の委譲、資金の引き出しを行える。一方、エージェント向けの「仮想ウォレット」はAPIキーによって操作され、アカウント所有者があらかじめ設定した上限の範囲内でのみ支出できる。 支出管理のためのガードレール機構も用意されており、支出上限や許可リスト、1件あたりの最大トランザクション額などを柔軟に設定可能だ。異常な支出パターンが検出された場合には、人間が内容を確認・承認するフローも組み込まれている。cloudflare.payでは、エージェントが「research.example.cloudflare.pay」のような形式のハンドルを取得し、身元情報を自発的に取引先へ宣言できる。 対象ユーザーと今後の展開 想定される利用者は幅広い。エージェント開発者は複数のAPIを低摩擦で試験・評価できるようになり、Monetization Gatewayを通じてコンテンツやAPIを販売するCloudflareの顧客企業は新たな収益機会を得る。また企業の管理者にとっては、従業員が利用するAI推論サービスへの支出予算を管理する手段にもなる。 現時点でCloudflareはcloudflare.payのハンドル取得受付を開始しており、マイクロペイメント機能は近日開始予定としている。対象地域限定でVirtual Walletのステーブルコイン自己資金調達オプションも段階的に展開する方針だ。今回の取り組みは、既存のWeb Bot Authなどのセキュリティ技術や、標準化を進めるx402 Foundationのイニシアティブとも連携しており、AIエージェントが人間の監督のもとで安全に経済活動を行える基盤づくりの一環と位置付けられている。

概要 GitHubは2026年8月6日（現地時間午前11時22分/UTC15時22分)、GitHub Actionsのパフォーマンス低下を検知し、これが約10時間半に及ぶ大規模障害へと発展した。原因は実行ランナーに対して無効なジョブが継続的かつ誤って割り当てられていたことで、ワークフローの失敗や遅延が世界中のCI/CDパイプラインを直撃した。障害はActions単体にとどまらず、GitHub Pagesの可用性低下、Copilotのコードレビューおよびコーディングエージェント機能の劣化、ホステッドランナーの不調、GitHub Enterprise Importerの移行ジョブ停止、ウェブフック配信の遅延（処理能力が通常の15%まで低下）へと波及した。一部のトリガーイベントは自動再実行の対象外となり、失われたままとなっている。GitHubは発生から約2時間後に原因を特定したとするも当初は技術的詳細を明らかにせず、その後複数の緩和策と修正を段階的に適用し、現地時間午後8時1分に復旧を宣言した。修正適用後、ワークフロー実行の成功率は99%まで回復したという。 背景にある信頼性の低下 今回の障害は単発の事故ではなく、GitHubのインフラが抱える構造的な問題の一端として位置づけられている。IncidentHubの集計によれば、過去12カ月間でGitHub全体は257件のインシデント（うち48件が「メジャー」）を記録し、累積ダウンタイムは112時間を超える。GitHub Actionsだけでも57件のインシデントが報告されており、月別でも2026年4月に26件、5月に23件、6月に23件、7月に26件、8月も6日時点で既に6件と、高止まりが続いている。GitHubは以前、AI関連ワークロードの急増をシステム負荷の一因として説明し、構造的改善を約束していたが、今回の障害はその効果が十分に表れていないことを示した。GitHubは現在Azureへのインフラ移行を進めているものの、今回の障害発生時点でトラフィックの移行率はわずか12.5%にとどまっており、完全移行までは同種の負荷問題が続く可能性がある。 開発者コミュニティの反応 相次ぐ障害に対し、開発者コミュニティの不満は深刻化している。ターミナルエミュレータGhosttyの開発者Mitchell Hashimotoは「ほぼ毎日のようにインシデントで作業がブロックされている」と述べ、プロジェクトのGitHubからの移行を発表した。Zig言語財団もすでにCodebergへの完全移行を完了させている。ある開発者は、現状のGitHubのプラットフォームは「本格的な業務利用には適さない」との評価も示しており、CI/CD基盤としての信頼性そのものが問われる状況となっている。

概要 Rustのコンパイラや標準ライブラリを管理する5つのチームは8月5日、rust-lang/rustモノレポへの貢献を対象としたLLM利用に関する公式ポリシーを採択したと発表した。基本方針は「質問への回答、分析、精緻化、チェックには良いが、コード生成はダメ」というもので、LLMとの対話を通じて自身の理解を深めたり、テキストの分析・要約、バグ発見の補助、翻訳支援に使ったりすることは歓迎する一方、LLMにコードを生成させてそのままPRとして投稿する行為には強い制限を課している。なお、このポリシーはあくまでrust-lang/rustリポジトリに限定されたものであり、Rustプロジェクト全体としての公式見解ではない点が明記されている。 ポリシー採択の背景 チームがこの方針を採択した背景には3つの課題があるという。第一に、これまで「磨き上げられたPR」は著者の努力や献身の指標として機能してきたが、LLMによって誰でも一見高品質なPRを作れるようになり、その指標が失われつつある。第二に、rust-lang/rustには現在1,281件ものオープンPRが存在し、レビュー体制はすでに逼迫している中で、LLMによる「弾幕」的なPR増加はレビュアーの精神的負担を急増させかねない。第三に、レビューでの指摘事項をそのままLLMに貼り付けて得た回答を投稿するといった機械的なやり取りは、時間の浪費であるだけでなく、著者とレビュアーの間の信頼関係を損なうと指摘されている。 具体的なルール 許可される利用としては、LLMとの非公開の対話による理解の補助、テキストの分析・要約、バグ発見の補助、そして開発者が母語で投稿しやすくするための翻訳支援が挙げられている。一方、LLMが生成したコードを投稿する場合は「事前に調整済みで、重要度が低く、高品質かつ十分にテストされている」ことが条件となり、テストの有無に関わらず必ずテストを添付する必要がある。コンパイラのソウンドネスに関わる変更については、既存の専門家を除いて禁止される。さらに、公開ドキュメントや診断メッセージの本文をLLMが生成することは全面的に禁止されており、診断ロジックの補助としての利用のみ条件付きで認められる。また、公開の場でLLMが生成したテキストを使う場合は、開示が必須とされ、隠すことは許されない。 コミュニティでの運用と今後の展望 運用面では、著者はLLM利用を自発的に申告することが求められ、今後PRテンプレートに使用有無を確認する項目が追加される見込みだ。レビュアーには、ポリシー違反が疑われるPRを理由を示さずに却下する権限が与えられる一方、疑いがある場合の報告は告発ではなく情報提供として扱われ、単なるスタイル上の違和感を証拠として扱わないよう配慮されている。Rustプロジェクトはコンセンサス(合意形成)によって運営されているため、今回のポリシーもトップダウンの一律禁止ではなく、コミュニティが共有する「深い専門知識の構築」「包摂的なコミュニティ」といった価値観に基づいて設計されたという。プロジェクト側は、LLM利用についてコミュニティ内で見解が一致しているわけではないと認めた上で、今後は利用実態のデータ収集やLLM関連ポリシーの承認を簡素化する専門サブチームの設立を検討するとしている。将来的には、チャットやフォーラム、他のリポジトリを含むプロジェクト全体へのポリシー拡大も視野に入れており、今回の方針は最終決定ではなく、経験を踏まえて進化させていく前提で設計されている。

概要 Anthropicは、Claudeモデル向けの独自AIチップを設計する社内チームの立ち上げを正式に確認した。狙いはハードウェアとモデルの「共同設計(co-design)」によって、トークンあたりの推論コストを約半分に削減することだ。Anthropicはこれを単なる研究プロジェクトではなく、事業戦略の中核に位置づけている。技術リーダーには、OpenAIの独自チップチームで2番目のハードウェアエンジニアとして採用され、同社のBroadcom設計推論アクセラレータ「Jalapeño」の開発に約2年半携わったClive Chan氏を迎えた。同氏はTeslaのAutopilot向けディープラーニング基盤やML学習用ASIC開発にも従事した経験を持つ。 採用と技術的アプローチ Anthropicは半導体エンジニアの採用を本格化しており、求人では「完成したチップ設計を出荷した経験」を持つ人材に対し年俸32万〜48.5万ドルを提示、「大きな組織の後ろ盾なしに重要な意思決定を下せる」人物を求めている。同社の方針はNvidiaやGoogleのTPUといった既存の外部サプライヤーを置き換えるのではなく、AWS・Google・Nvidia・AMDとのパートナーシップを維持しつつ、チップとAIモデルを一体で最適化する「共同設計」によって効率を引き上げるというものだ。実際、4月にはGoogle・Broadcomとのパートナーシップを拡大し、2027年稼働予定のTPU容量3.5ギガワットに加え、2026年内にも追加で1ギガワット分の確保を発表している。7月には製造委託先としてSamsungとの協議も報じられた。 背景 この動きの背景には、Anthropicの急成長がある。年間経常収益(ARR)は2025年末時点の約90億ドルから、現在は300億ドルの水準まで3倍に伸びており、年間100万ドル以上を支出する法人顧客も1,000社を超える。急拡大する需要をまかなうコンピュート基盤の確保が経営上の最優先課題となっている。また、同業他社との競争も要因の一つだ。OpenAIは2026年6月にBroadcomと共同開発した推論向けチップ「Jalapeño」を発表済みで、Google DeepMindは自社のTPUを、MetaもMTIAアクセラレータをそれぞれ活用しており、大手AI企業の間で外部ベンダー依存から脱却する動きが広がっている。 今後の展望 現時点でAnthropicは完成したシリコンの投入時期や具体的な製造契約について明らかにしておらず、発表は主に採用活動を軸としたものにとどまる。ただし、同社はChan氏を中心にハードウェア人材の採用を積極化させている様子がうかがえる。これは、単なるAIモデル開発企業から、自社シリコンを持つ企業へと軸足を広げつつある兆候とも受け取れる。

概要 AWSは2026年8月5日、Amazon Aurora Serverlessのスケーリング性能を強化したと発表した。新機能により、負荷が急増した際にわずか1秒以内で最大12 ACU(Aurora Capacity Unit)まで到達し、その後も需要に応じて最大256 ACUまで拡張し続けることが可能になった。ワークロードが終了すればクラスターは自動的にゼロまでスケールダウンし、アイドル時のコストは発生しない。 この強化はプラットフォームバージョン3および4で自動的に有効化されるため、ユーザー側での追加設定は不要だ。バージョン1や2を利用している場合は、バージョン4へ直接アップグレードすることでこの機能を利用できる。現在使用しているバージョンは、AWS Management Consoleのインスタンス設定セクション、またはRDS APIのServerlessV2PlatformVersionパラメータから確認できる。 想定されるユースケース AWSは今回の強化について、突発的なアクセス集中、長いアイドル期間、予測が難しいトラフィックパターンを持つアプリケーションに特に有効だとしている。中でも主なターゲットとして挙げられているのが「エージェント型AI」アプリケーションだ。AIエージェントは、タスク実行時に短時間で大量のデータベースクエリを発行し、処理が完了すると一気にアイドル状態へ戻るという、瞬間的かつ極端な負荷変動を伴うことが多い。従来のオートスケーリングでは、こうした急激な立ち上がりに追従しきれずレイテンシが悪化したり、逆に不要な容量を確保し続けてコストが膨らんだりする課題があった。今回の高速スケーリングは、こうしたバースト特性の強いワークロードに対して、性能とコスト効率を両立させることを狙っている。 背景と今後の展望 Aurora Serverless(v2)はもともと、需要に応じてデータベースの処理能力を自動的に増減させることでコスト最適化を図る仕組みとして提供されてきた。生成AIやエージェント型AIの普及に伴い、アプリケーションのトラフィックパターンはより予測不可能かつスパイク状になっており、データベース基盤にもそれに追従できる俊敏性が求められるようになっている。今回のアップデートは、AWSがそうした新しいワークロード特性に合わせてマネージドデータベースサービスを継続的に進化させている一例と言える。既存クラスターへの適用に追加コストや移行作業が発生しない点も、導入のハードルを下げる要素となりそうだ。

概要 2008年リリースのLinux 2.6.25以降、実に18年にわたって存在し続けていたLinuxカーネルのSCTP(Stream Control Transmission Protocol)実装のuse-after-free脆弱性が公表された。CVE-2026-64564として追跡され、「SCTPhantom」と命名されたこの欠陥は、Tencent Zhuque Labの研究者によって発見され、特権コンテナに限らず一般的な非特権ユーザーであっても、特別な権限(CAP_NET_ADMINやCAP_SYS_ADMIN)なしにroot権限の奪取とコンテナからホストマシンへのエスケープを実現できることが実証された。既に8月3日リリースの安定版カーネルで修正が完了している。 技術的な詳細 SCTPは、複数のネットワークパスを同時に利用できるマルチホーミング機能を持つトランスポート層プロトコルで、通信の冗長性向上を目的として設計されている。SCTPhantomはこのマルチパス機能に起因するカーネルのメモリ管理上の矛盾を突くものだ。具体的には、カーネルがトランスポート(パス)の削除リクエストを処理する際、リクエストの正当性をパケットの送信元アドレスに基づいて確認する一方、実際の通信は選択された別のパス(アドレス)を使って行われるという食い違いが存在する。この不整合を悪用することで、既に解放されたメモリ領域への参照が生じるuse-after-freeの状態を意図的に作り出し、カーネルメモリの読み書きへとつなげることが可能になる。攻撃はローカルからSCTPプロトコルに到達可能な環境であれば成立し、リモートからの直接攻撃は想定されていない。 影響範囲と悪用シナリオ 影響を受けるディストリビューションとして、Debian 13、Ubuntu 24.04、Rocky Linux 9、RHEL 9、OpenCloudOSなどが挙げられている。いずれも標準的な設定でSCTPカーネルモジュールがロード可能な状態にあり、悪用の対象となり得る。研究者らの検証では、コンテナ環境においても特権を持たないプロセスからこの脆弱性を突くことで、ホストマシンの権限を掌握できることが示されており、マルチテナント環境やコンテナオーケストレーション基盤を運用する組織にとって深刻なリスクとなる。 対応状況と推奨事項 本脆弱性は2026年8月3日にリリースされた安定版カーネル(7.1.6、6.18.42、6.12.101、6.6.148)で既に修正済みである。ただし、カーネルのバージョン文字列を確認するだけでは修正パッチが適用済みかどうかを判断できないケースがあるため、利用しているディストリビューションが提供する脆弱性トラッカーで個別に修正状況を確認することが推奨される。また、業務上SCTPプロトコルを利用していない環境では、該当カーネルモジュールの読み込みをブロックすることで、そもそも攻撃対象領域(アタックサーフェス)自体を排除できるとされている。

概要 Samsungは8月4日から米カリフォルニア州サンタクララで開催された「Future of Memory and Storage(FMS)2026」において、AIデータセンター向けの次世代メモリ技術3種、zHBM・zNAND-O・V10 BV-NANDを発表した。いずれも先進的なウェハー接合(wafer bonding)技術を基盤としており、大規模AIトレーニングにおけるメモリ帯域幅のボトルネック、発熱、電力効率という3つの課題への対応を狙う。SamsungはzHBMとzNAND-Oについて業界初のコンセプトモデルを披露したとしている。 zHBM:メモリをアクセラレータの真上に積層 zHBMは、HBM(High Bandwidth Memory)を根本的に再設計したアーキテクチャである。従来のHBMはAIプロセッサの隣に水平配置されるのが一般的だが、zHBMは次世代ウェハー接合技術を用いてメモリをAIアクセラレータの真上に垂直積層する。これによりメモリとプロセッサ間の物理的距離を最小化し、データ転送の遅延を大幅に削減する狙いだ。 性能面では、HBM5比で最大8倍の性能向上、同じ実装面積で10倍以上のメモリ密度、エネルギー効率は3倍改善、熱抵抗は50%以上削減されるとしている。また、カスタマイズ可能なIP層を備え、特定のAIワークロード向けにロジックを追加できる点も特徴として挙げられている。ただし、これらの数値の詳細な算出根拠は現時点で公開されていない。 zNAND-OとV10 BV-NAND:NANDにもウェハー接合を適用 zNAND-Oは、SamsungのV-NAND技術をベースにしたエッジAI向けの高性能NANDソリューションで、4層および8層構成の開発が進められている。高い空間効率と改善されたI/O性能、低レイテンシを特徴とし、リアルタイムのデータ処理を要するエッジAI用途を想定する。 一方のV10 BV-NAND(Bonding V-NAND)は、業界で初めてウェハー接合技術をNANDフラッシュに適用したアーキテクチャで、400層を超える積層数を実現したプロトタイプとして披露された。ウェハー接合では、メモリセルとペリフェラル(周辺)ロジックを別々のウェハーで製造し、後から貼り合わせる製法を採る。これにより、従来の単一ウェハー上に全層を積み上げる方式に比べ高密度化がしやすくなる。前世代のV9と比較して、ストレージ密度は約58%向上したほか、読み書き性能やI/O性能も改善されたという。 今後の見通し 今回発表された3技術はいずれもコンセプトモデルやプロトタイプの段階であり、量産・製品化の具体的な時期は明らかにされていない。生成AIの普及に伴いAIアクセラレータの計算能力は急速に向上している一方、メモリからのデータ供給が追いつかない「メモリウォール」問題が業界共通の課題となっている。Samsungは今回の技術群を通じて、演算性能の向上にメモリ側の帯域・密度・熱特性を追随させる方向性を示した形で、HBMやNANDの次世代開発競争は今後さらに激化するとみられる。

概要 2026年8月4日、週間1億件を超えるダウンロード数を誇る人気npmパッケージ「keyv」をはじめとする一連のパッケージが、GitHubアカウント侵害を通じて汚染される大規模サプライチェーン攻撃が発生した。攻撃コードはpreinstallスクリプトとして仕込まれ、開発環境やCI環境でGitHub認証情報、npmレジストリアクセス権、クラウド認証情報、Vault・Kubernetes・データベースの認証材料などを窃取した。監視ツールによれば被害はSafeDepの検証で79パッケージ名・353バージョンに及び、Aikidoの報告ではさらに広く868パッケージ・1,381バージョンに達したとされる。攻撃は自動化されたワームとして機能し、2〜7分ごとに侵害した組織アカウントから次の組織へと移動し、約30分で横断的な公開バーストを完了させたと分析されている。 攻撃手法の技術的詳細 最初の悪意あるリリースであるkeyv@6.0.0は、インストール時に自動実行されるpreinstallスクリプトを通じて認証情報窃取バンドルを実行する設計だった。setup.mjsとMath_Symbol.jsという2つのファイルが仕込まれ、まずBunランタイムの有無を確認し、必要であればGitHubから1.3.13版のBunをダウンロードした上で、727,680バイトのコンパイル済みバンドルに制御を委譲する多段構成となっていた。攻撃者はGitHubアカウントの侵害によって取得した権限を悪用し、正規のGitHub Actionsリリースワークフローを通じてOIDC/SLSA証明付きの「正規リリース」として悪意あるパッケージを公開した。コミット自体もgithub-actions[bot]名義で検証済みバッジ付きだったが、専門家はこのバッジが署名パスの有効性を示すのみでソースコードの安全性までは保証しないと指摘している。同様にOIDC/SLSA証明もビルドプロセスの出所を特定できるに過ぎず、ソースの安全性を確立するものではないという限界が改めて浮き彫りになった。 IDE・エディタへの実行経路の仕込み 今回の攻撃で特に問題視されているのが、開発者のローカル環境で自動実行されるツール設定への侵入である。.claude/settings.jsonにはセッション開始時に自動実行されるSessionStartフックが仕込まれ、.vscode/setup.mjsを呼び出す構成になっていた。同様に.vscode/tasks.json内の「Environment Setup」タスクにはrunOn: folderOpenが設定され、フォルダを開いた際に.claude/setup.mjsを自動実行する仕掛けが組み込まれていた。ただしVS Codeは信頼されていないワークスペースでの自動タスク実行をブロックし、デフォルトでは実行前にユーザーへ確認プロンプトを表示するため、無条件で実行されるわけではない点は留意が必要である。とはいえ、開発ツールのワークスペース設定ファイルという開発者が見落としがちな場所に実行経路を仕込む手口は、今後同種の攻撃が広がる可能性を示唆している。 発見・対応状況とマルウェアファミリーとの関連 8月4日午後5時40分(IST)頃には、keyv@5.6.0やflat-cache@6.1.23、cache-manager@7.2.9など複数パッケージで、汚染前の以前のバージョンが「latest」タグに復元される対応が取られた。その後の続報では、keyvおよびCacheableの毒物化リリースは非公開化されたものの、それ以外のほぼすべての被害パッケージでは「latest」タグが依然として悪意あるバージョンを指したままであると報告されている。セキュリティ企業Aikidoはこの攻撃を既知のマルウェアファミリー「Shai-Hulud」に位置づけており、セキュリティ企業Semgrepは同一のClaude Code・VS Codeフック、setup.mjsというファイル名、Bun 1.3.13のダウンロード手口が、2026年4月に発生したPyPIのlightning(pytorch-lightning)パッケージ侵害でも確認されていたと報告している。報道時点では、メンテナー・npm・GitHubいずれからも公式声明は出されていない。 推奨される対策と今後の見通し 専門家はlockfileと実際に解決されたバージョンをパッケージ名単位で正確に照合すること、不要なインストールスクリプトを無効化すること、そして影響を受けたバージョンを実行した環境はすでに侵害されたものとして扱うことを推奨している。npm 12ではデフォルトで未承認のライフサイクルスクリプトがブロックされるようになっているが、旧バージョンのクライアントやライフサイクルスクリプトの実行を許可する設定を残した環境は依然として脆弱なままだ。正規のCI/CD証明やコミット署名だけでは供給元の安全性を保証できないことが改めて示された今回の事例は、開発ツールの自動実行設定を含めた多層的なサプライチェーン防御の必要性を浮き彫りにしている。

概要 GitHubは8月6日、オープンウェイトモデル「Kimi K3」をGitHub Copilotで一般提供開始したと発表した。Kimi K3はFireworks AI上でホストされており、エージェント型コーディングにおいてフロンティア級の性能を低コストで利用できる点が特徴となる。Copilot Pro、Pro+、Max、Business、Enterpriseの全プランで選択可能になったが、BusinessおよびEnterpriseプランではデフォルトで無効化されており、管理者が設定画面から有効化する必要がある。利用はVisual Studio Code、Visual Studio、Copilot CLI、GitHub.comなど複数のインターフェースに対応し、現在は段階的なロールアウトと品質・パフォーマンスの監視が進められている。 料金体系 Kimi K3は従量課金制のモデルとして提供される。公開されている価格は、入力トークンが100万トークンあたり3ドル、出力トークンが100万トークンあたり15ドル、キャッシュされた入力トークンが100万トークンあたり0.30ドルとなっている。既存のフロンティアモデルと比較して低コストな料金設定であり、コーディング支援を日常的に利用する開発者にとって選択肢の幅が広がる形だ。 Kimi K3とは Kimi K3は、北京を拠点とするMoonshot AIが開発したオープンウェイトの大規模言語モデルである。2026年7月中旬に発表され、7月27日にはモデルの重みが公開された。総パラメータ数は約2.8兆にのぼり、これまでに公開されたオープンウェイトモデルとしては最大級とされる。ただし実際には、Mixture-of-Experts(MoE)構造により1トークンあたり1040億パラメータのみが活性化される設計となっている。100万トークンのコンテキストウィンドウを持ち、テキストに加えて画像・動画も扱うネイティブなマルチモーダル入力に対応するほか、OpenAIおよびAnthropicのAPIと互換性のあるインターフェースを備える。重みは商用利用も可能な独自の「Kimi K3 License」の下で公開されているが、学習データや学習コード自体は公開されていないため、厳密には「オープンソース」ではなく「オープンウェイト」の位置づけとなる。 性能面では、総合的なベンチマークではAnthropicやOpenAIの最新フロンティアモデルにはわずかに及ばないものの、コーディングおよびエージェント関連の評価では両社の旧世代モデルを上回る結果を示している。公開直後からコミュニティの注目を集め、モデルリポジトリには短期間で数千件規模の「いいね」と多数のダウンロードが集まった。一方で、自前でホストする場合はNVIDIA H100またはB200 GPUを8サーバー・計64基程度必要とする規模感であり、実運用でのセルフホスティングは潤沢なリソースを持つ組織に限られるのが実情だ。今回のGitHub CopilotによるFireworks AI経由でのホスティング提供は、こうした大規模インフラを持たない一般の開発者にもKimi K3の性能を手軽に届ける狙いがあるとみられる。 今後の展望 GitHub Copilotへの主要オープンウェイトモデルの統合は、開発者がタスクに応じてクローズドソースモデルとオープンウェイトモデルを柔軟に使い分けられる流れを加速させるものだ。特にコストを抑えつつエージェント型コーディングを実行したい場合の有力な選択肢として、Kimi K3の存在感は今後さらに増していく可能性がある。GitHub側は段階的ロールアウトを継続しており、今後のパフォーマンス評価や提供範囲の拡大にも注目が集まる。

概要 セキュリティ企業Manifold Securityは、VS Code系エディタ向けのオープンな拡張機能マーケットプレイス「Open VSX」上で、正規の開発者ツールになりすました「evil twin(双子)」型の悪意ある拡張機能77個を発見した。これらは2026年7月26日から8月1日にかけて、本来の所有者ではないアカウントから公開されたもので、いずれも本物の拡張機能の名前・説明文・名前空間をそのままコピーし、バージョン番号を「0.0.1」などの低い値に設定することで検出を逃れようとしていた。実装面では、バンドルされているextension.jsファイルが、情報収集と外部送信を目的としたコードに差し替えられていた。Open VSXは8月3日までに該当パッケージをすべて削除したが、既にインストール済みの環境からは手動でのアンインストールが必要とされている。 収集されたデータと攻撃の階層構造 窃取された情報の範囲は拡張機能によって異なり、大きく2つの階層に分かれていた。77個のうち58個は「軽量型」で、主にマシンのホスト名や、場合によってはワークスペースのフォルダ名・エディタのバージョンといった最小限の情報のみを送信していた。残る19個(全体の約4分の1)は「偵察型」と呼ばれるより高度な変種で、ホスト名やOSのユーザー名、マシンID、エディタの仕様、プラットフォームのアーキテクチャ、ロケールやタイムゾーンに加え、Gitのリモートホストや組織情報、GitHub/GitLabのプロジェクト情報、コミットのメールドメイン、ブランチ情報、CI/CD環境の変数やマーカーなど、開発環境やプライベートリポジトリに関するかなり詳細な情報まで収集していた。一方でManifold Securityは、これらの拡張機能がソースコード本体や認証情報、アクセストークン、SSH鍵、ブラウザデータには一切アクセスしていなかった点も明らかにしている。なお、拡張機能の説明ページには「テレメトリ」の項目として「ソースコードや認証情報、トークンは収集しない」と明記されていたケースもあったが、少なくとも1つの拡張機能ではCIマーカー値を送信しないと述べながら実際には送信しており、利用者を欺く記述だったことも判明している。 インフラと技術的な巧妙さ 77個の拡張機能はすべて、単一のドメイン「mangorbit[.]com」へデータを送信していた。このドメインはキャンペーン開始の11日前にあたる2026年7月15日に登録されており、あらかじめ準備されたインフラが使われていたことがうかがえる。さらに攻撃者はこのドメインを3年間分登録するなど、長期的な運用を見据えた設計を施していた。持続性の面でも工夫が見られ、偵察型の変種では初回インストールからおよそ15分後、50分後、3.5時間後に送信を試み、その後は7~8時間ごとに定期送信を繰り返す仕組みが確認された。また、通信が遮断された場合に備えてDNS TXTレコードを用いた代替の送信先ドメインを問い合わせる機能や、自動インストールとユーザーによる手動インストールを区別するロジックも組み込まれており、単純な自動化ボットではなく人間の開発者を明確に標的にしていたことを示している。 背景と今後の対応 今回の事案は、npmエコシステムで450個のパッケージが影響を受けたとされる大規模なサプライチェーン侵害「ChainDrop」とほぼ同時期に発覚しており、オープンソースのパッケージレジストリ全般を狙った脅威が拡大している状況を浮き彫りにしている。Manifold Securityは、攻撃者の目的や身元について現時点では推測を避けているが、防御策として、パブリッシャーとバージョンをピン留めすること、未検証のパブリッシャーによる拡張機能の自動インストールを警告・ブロックすること、新規登録されたドメインへの通信を検知することなどを推奨している。開発者や組織は、公開されている悪意ある拡張機能IDの一覧と自環境を照合し、該当するものがあれば速やかに削除するとともに、mangorbit[.]com宛ての通信をブロックする対応が求められる。