Bun、Claude Fable 5で53万行のZigコードを11日間でRustへ全面移植

概要 JavaScript/TypeScriptランタイムBunの開発チームは7月8日、もともとZigで書かれていたランタイム本体、約53万5000行のコードをRustへ全面移植したと発表した。Anthropicに買収されたBunチームの一員であるJarred Sumner氏によるブログ記事で明らかにされたもので、作業には最大64個のClaude Fable 5インスタンスを同時稼働させるClaude Codeの動的ワークフローが用いられ、2026年5月3日から14日までのわずか11日間で完了したという。コミット数は6,502件、追加行数は約100万行に達した。この事例は、AIエージェントを並列活用することで大規模コードベースの全面書き換えという従来避けられてきた手法が現実的になった例として、Simon Willison氏など複数のメディアが取り上げ注目を集めている。 移植の背景 BunはこれまでZigの手動メモリ管理とJavaScriptCoreのガベージコレクターを組み合わせて実装されていたが、この構成がuse-after-free、double-free、エラーパスでの解放漏れといったメモリ安全性のバグを継続的に生む原因となっていた。Rustのボローチェッカーはこれらの問題の多くをコンパイル時エラーとして検出できるため、安定性向上を狙って全面的な言語移行が選択された。Simon Willison氏は、従来のソフトウェア開発では大規模な完全書き直しはリスクが高く避けるべきとされてきたが、現代のAIモデルの能力がこの前提を変えつつあると指摘している。 実装プロセス 移植は単発のプロンプトでコードを変換するのではなく、体系的なパイプラインとして構築された。まずPORTING.md(ZigからRustへのパターン対応表)とLIFETIMES.tsv(複雑な構造体のライフタイム分析)を準備し、全1,448個の.zigファイルを機械的に.rsへ変換。その後発生した約1万6000件のコンパイルエラーを段階的に修正し、テストをローカルからCIへと順次拡大しながら検証した。品質保証の要となったのは、実装を担当したエージェントとは別のコンテキストで動作する2つのClaudeによる「敵対的レビュー」と、TypeScriptで書かれた既存テストスイートを言語非依存の適合性検証スイートとして活用した点である。全体では約50の動的ワークフローが連続して実行され、入力トークンは59億、出力トークンは6.9億に上り、API利用コストは推定16万5000ドルと見積もられている(Anthropic社員という立場からトークン費用は実質負担していないという)。 成果と今後の展望 移植の結果、バイナリサイズはLinuxで20%、Windowsで19%削減(Linux版は88MBから70MBへ、Windows版は94MBから76MBへ)されたほか、HTTPスループットが2.8〜4.8%、TypeScriptコンパイルが4.7%向上するなど性能面でも改善が見られた。メモリ使用量では、2,000回の反復ビルドテストにおいてZig版が6.7GBを消費していたのに対し、Rust版は609MBにまで抑えられたという。移行後に発覚した回帰は19件のみで、HMR破損やUTF-16処理の差異など軽微なものにとどまり、いずれも迅速に修正された。128件のバグ修正やメモリリーク問題の根本的解消も報告されている。今回Rustで書き直されたコードは「Bun v1.4.0」として最初にリリースされる予定で、今後はパーサーの24時間体制でのファジングや、現在4%残るunsafeコードの段階的削減が継続される見込みだ。

July 14, 2026

npm 12がリリース、依存関係のインストールスクリプトをデフォルト無効化しサプライチェーン攻撃対策を強化

概要 GitHubは2026年7月、npmの新バージョンv12.0.0を正式リリースした。最大の変更点は「allowScripts defaults to off」という方針転換で、これまでnpm install実行時に自動で走っていた依存パッケージのpreinstall・install・postinstallといったライフサイクルスクリプトが、デフォルトで無効化される。相次ぐサプライチェーン攻撃を受けた大きな方針転換であり、世界中の膨大な数のnpmユーザーに影響する変更となる。 技術的な詳細 npm 12では、主に3つの制御がデフォルトで厳格化された。 ライフサイクルスクリプトの無効化:依存関係のスクリプトや、暗黙的に実行されていたnode-gypによるネイティブビルドが、明示的な許可なしには実行されなくなる。 Git依存関係の制限:--allow-gitのデフォルトが「none」となり、直接・間接を問わずGit経由の依存関係が明示的な許可なしには解決されなくなる。 リモートURL依存の制限:--allow-remoteのデフォルトも「none」となり、HTTPS経由のtarballなど、リモートURLからの依存関係取得が制限される。 正当なビルドスクリプトを必要とするパッケージを使い続けたい開発者は、npm approve-scripts --allow-scripts-pendingを実行して信頼するスクリプトを個別に承認し、その結果をpackage.json内のホワイトリストとしてコミットする運用が必要になる。 セキュリティ関連の追加変更 今回のリリースでは、npmのGranular Access Tokens(GAT)にも重要な変更が加わった。2要素認証(2FA)をバイパスするよう設定されたGATは、アカウントや組織に関わる機微な操作を実行できなくなる。対象にはトークンの作成・削除、リカバリーコードの生成、パスワードやメールアドレスの変更、2FA設定の変更、パッケージアクセス管理、公開組織・チームの管理などが含まれる。この制限は2026年8月初旬から段階的に発効する予定だ。 今後の展望 npmは2027年1月をもって、Granular Access Tokens(GAT)による直接公開機能を廃止する計画も示している。GATの公開範囲はプライベートパッケージの読み取りと公開のステージングに限定され、実際の公開には人間による2FA承認が必要になる。今後は自動公開についてOIDCベースのtrusted publishing、あるいは人間によるレビュー・承認ステップを経た公開フローへの移行が推奨される。同時期には、pnpm 11.10でも認証情報とその接続先ホストを単一の構造化された値として関連付ける_auth設定が導入されており、リポジトリに紛れ込んだマルウェアによる認証トークンの横取りリスクを軽減する動きが業界全体で広がりつつある。

July 13, 2026

Paysafe・Skrill・Netellerの決済SDKを偽装、npmとPyPIで17件のタイポスクワッティング攻撃を検知

概要 セキュリティ企業Socketは2026年7月7日、npmとPyPIの両パッケージレジストリにまたがる調整型のタイポスクワッティング攻撃キャンペーンを検知したと発表した。攻撃者は決済サービスのPaysafe、Skrill、Netellerの公式SDKを装い、npmに13パッケージ(paysafe-checkout、paysafe-vault、paysafe-js、neteller、skrillなど、各4バージョンずつ)、PyPIに4パッケージ(paysafe-kyc、paysafe-payments、paysafe-sdk、paysafe-api)の計17件を公開していた。狙いは決済SDKを導入しようとする開発者を騙し、CI/CD環境の認証情報やシークレットを窃取することにあった。公開からわずか6分で悪意あるコードとして検知されたが、パッケージレジストリを標的にしたサプライチェーン攻撃の脅威が改めて浮き彫りになった。 巧妙なフェイクSDKの仕組み 悪意あるパッケージは、本物のPaysafe APIクライアントを模したクラスを実装しており、表面上は正常に動作しているように見える。実際には決済サービスの本物のエンドポイントには一切接続せず、{ success: true, method, path }のような偽の成功レスポンスを返すだけの「ファサード」に過ぎない。APIキーは環境変数PAYSAFE_API_KEYから読み込む形を取り、正規のSDKと同様の使い勝手を装うことで開発者に気付かれにくくしていた。 シークレット窃取とサンドボックス回避の手口 すべてのAPIリクエストメソッドが実行されるたびに、内部の_request()関数がシークレット抽出ルーチンを起動する仕組みになっていた。この処理では、変数名に「KEY」「SECRET」「TOKEN」「PASS」「AUTH」「API」を含む環境変数を片っ端からフィルタリングし、値を100文字に制限した上で窃取する。実際の被害シナリオではPAYSAFE_API_KEYだけでなく、AWS_SECRET_ACCESS_KEYやGITHUB_TOKEN、NPM_TOKENといったCI/CDの重要な認証情報も捕捉対象となっていた。 さらに、解析環境での検知を逃れるための仕掛けも組み込まれていた。CPUコア数が2未満の環境や、ホスト名・ユーザー名に「sandbox」「analyzer」「cuckoo」「virus」といった文字列が含まれる環境を検出すると、悪意ある処理をスキップする仕様になっている。窃取したデータの送信先となるC2(コマンド&コントロール)ドメインも、XORデコード、文字コードの17減算、文字列の反転という3段階の難読化処理で隠蔽されており、最終的にcaliber-spinner-finishing.ngrok-free.devというngrokベースのドメインへ通信する仕組みだった。このC2ドメインが解決するIPアドレスは、既知のマルウェア「NjRAT」など他の情報窃取型マルウェアのC2サーバーとしても使われていた実績があるという。なお、PyPI側のパッケージにはnpm版のようなAPIキーによるゲーティングがなく、インポートするだけで自動的にペイロードが実行される点も特徴だった。 攻撃者の狙いと今後の対策 Socketの分析によれば、攻撃者は決済関連SDKという特定領域に戦略的に的を絞り、パッケージごとに異なる難読化キーを使用することでシグネチャベースの検知を回避しようとしていた。npmとPyPIという複数エコシステムにまたがる攻撃を仕掛けられる技術力も示しており、サプライチェーン攻撃の巧妙化を裏付ける事例といえる。Socketは、該当パッケージを実行した端末上のすべてのシークレットを速やかにローテーションすること、依存関係に13件のパッケージ名が含まれていないか確認しレジストリプロキシ側でのブロックを検討すること、CIやビルドホストから.ngrok-free.devへの不審な通信がないか監視すること、PAYSAFE_API_KEYと該当パッケージ名の組み合わせについてCIログを監査することを推奨している。また52件のSHA-256ファイルハッシュを含む侵害指標(IoC)も公開されており、組織は自社環境への影響有無を照合できる。

July 12, 2026

VS Code 1.128リリース、複数Claudeエージェントを並行実行できる「マルチチャットセッション」を搭載

概要 Microsoftは7月8日、Visual Studio Codeの最新版となる「VS Code 1.128」をリリースした。目玉となるのは、1つの親セッションの中で複数の関連するチャットを並行して扱える「マルチチャットセッション」機能だ。Claudeなどのエージェントホストセッションにおいて、異なるアプローチを比較したり、途中のターンから分岐させたり、複数の作業を同時並行で進めたりできるようになった。各チャットはそれぞれ独立した履歴・タイトル・モデル選択を保持しつつ、一つのグループとしてまとめて管理されるため、作業がバラバラの独立セッションに分散してしまう問題を避けられる。あわせて、画像やPDFをチャットに添付できる「Copilot Vision」が正式にGA(一般提供)となったほか、VS Codeがフォーカスされていない状態でもコマンドを実行できる「OSレベルのキーボードショートカット」など、複数の機能強化が同時に投入された。 技術的な詳細 マルチチャットセッションでは、エージェントホストのセッション配下に複数の子チャットをぶら下げる形で管理する。各チャットは独自の会話履歴・タイトル・使用モデルを持てるため、たとえば同じタスクに対して異なるモデルやアプローチで並行して試行し、後から結果を比較するといった使い方が可能になる。セッション内の各チャットへは直接ディープリンクできるほか、複数チャット間を素早く移動するためのナビゲーションショートカットも用意された。 Copilot Visionは、チャットへの画像・PDFファイルの添付に対応する機能で、ペースト・ドラッグ&ドロップ・右クリックメニューのいずれからも添付でき、エージェントはツール呼び出しを通じてその内容を読み取れる。今回のリリースでプレビューを終え、正式に一般提供(GA)となった。 このほか、キーバインド設定にsystemWide: trueを指定することで、VS Codeがフォーカスを失っていてもコマンドを起動できる「OSレベルのキーボードショートカット」が導入され、Agentsウィンドウなどへの素早いアクセスに活用できる。ワークスペースに紐付かない「クイックチャット」も追加され、⌘K ⌘N(Linuxではcmd+K cmd+N)から起動可能で、特定プロジェクトに関係しない質問向けに、リロードをまたいで独立したセッションとして保持される。そのほか、カスタムエンドポイントに対する温度(temperature)やtop_pなどのサンプリングパラメータ設定、エージェントホストセッションでの実験的なBYOK(Bring Your Own Key)モデル対応、エンタープライズ向けのOpenTelemetryテレメトリ管理、ブラウザタブの配置先を選べるworkbench.browser.newTabPlacement設定なども今回のアップデートに含まれている。 今後の展望 マルチチャットセッションやBYOKモデル対応の実験的サポートは、複数のAIエージェントを組み合わせて開発を進める「マルチエージェントワークフロー」への対応を強化する動きの一環と見られる。Copilot VisionのGA化により、スクリーンショットや設計資料などの非テキスト情報を交えたやり取りがより日常的な開発フローに組み込まれていくことが期待される。

July 12, 2026

AIエージェント8体が並列開発、PostgreSQLのRust書き直し「pgrust」が回帰テスト4.6万件に全合格

概要 元Heap CEOのMalcolm Matis氏は7月9日、個人プロジェクトとして開発しているPostgreSQLのRust書き直し「pgrust」が、PostgreSQL 18.3の回帰テスト4.6万件以上に全件パスし、さらに分離テストにも合格したことを発表した。pgrustはPostgres 18.3との完全互換を目標としており、既存のPostgres 18.3のデータディレクトリからそのまま起動できるディスク互換性も実現している。この発表はHacker Newsで740ポイント超・620件超のコメントを集める大きな反響を呼び、AIコーディングエージェントによる大規模ソフトウェアの書き換えがどこまで実用的かを示す事例として注目されている。 開発手法 pgrustの最大の特徴は、その開発プロセスにAIコーディングエージェントを大々的に活用していることだ。Matis氏はJason Seibel氏と共同で、8体の並列AIコーディングエージェント(Codex)を運用し、月額約1,600ドルのコストをかけて開発を進めた。並列セッションの調整には「Conductor」というツールを用い、10〜20個のセッションを同時に走らせることで、4月末までに45万行以上のRustコードを生成したという。 技術的な詳細 アーキテクチャ上の大きな変更点は、従来のPostgresが採用していたプロセス単位の接続モデルから、スレッド単位の接続モデルへの移行だ。これによりメモリ安全性の向上や接続数上限の問題解消が見込まれるが、Matis氏自身は「一つの接続でのクラッシュが他の接続に影響を及ぼす可能性がある」という新たなリスクも認めている。未発表のベンチマークでは、トランザクション処理でPostgres本体より約50%高速、分析ワークロードでは約300倍高速という主張もされているが、Matis氏は「v0.1は本番環境での使用には対応しておらず、パフォーマンス最適化も未実施」と明言しており、既存のPostgres拡張機能とも互換性がない段階にとどまる。ブラウザ上で動作を確認できるデモがpgrust.comで公開されており、ソースコードはGitHub上で公開されている。 反響と今後の展望 Hacker Newsでの反響は大きく、740ポイント超・620件超のコメントが寄せられた一方、fsyncの設定条件やClickHouseとの比較の妥当性について懐疑的な意見も多く出ている。OrioleDBの開発者であるBen Dicken氏は「まだ基準に達していない」と指摘するなど、成果の評価には慎重な声も少なくない。開発チームが掲げる目標は「Postgresの内部を変更しやすくすること」であり、Postgres本体の挙動を正解(oracle)としながらRustでコードベースの作業性を高め、AI支援プログラミングによってサーバーのより深い部分への変更を探求していく計画だとしている。

July 11, 2026

Gitea公式Dockerイメージに認証バイパスの重大脆弱性、開示から2週間足らずで実悪用が確認

概要 自己ホスト型GitサービスGiteaの公式Dockerイメージに、認証を完全に迂回して任意のユーザー(管理者を含む)になりすませる重大な脆弱性「CVE-2026-20896」(CVSS 9.8)が存在することが明らかになった。2026年6月下旬の脆弱性開示からわずか13日後には、セキュリティ企業Sysdigによって実際の悪用の痕跡が検出されており、パッチ未適用の環境を狙った攻撃が急速に進行していることがわかる。研究者Ali Mustafa氏がこの問題を発見・報告し、Gitea側は1.26.3および1.26.4で修正版を公開済みである。 技術的な詳細 問題の根本原因は、Giteaの公式Dockerイメージがデフォルトでリバースプロキシ認証の信頼済みプロキシ設定をREVERSE_PROXY_TRUSTED_PROXIES = *(ワイルドカード、つまり全IPアドレスを信頼)としていた点にある。本来この設定は127.0.0.0/8,::1/128のようにローカルホストなど限定された送信元のみを信頼するべきものだが、ワイルカード指定によりコンテナのHTTPポートに直接到達できる何者でも、リバースプロキシを経由したかのように振る舞えてしまう状態になっていた。 具体的には、攻撃者はX-WEBAUTH-USERというHTTPヘッダーに任意のユーザー名を設定して送信するだけで、パスワードやトークンなしにそのユーザーとして認証されてしまう。Mustafa氏は「ポートに到達できる者は誰でもX-WEBAUTH-USERヘッダーを送信し、パスワードもトークンも使わずに任意のユーザーとして認証される状態だった」と説明している。さらに自動登録(auto-registration)機能が有効な構成では、既知の管理者ユーザー名になりすますことで、攻撃者が管理者権限まで取得できる危険性があった。影響を受けるのはGitea公式Dockerイメージのバージョン1.26.2以前で、修正版の1.26.3・1.26.4ではこのワイルドカードのデフォルト値が撤廃され、リバースプロキシ認証はオプトイン方式に変更された。 悪用の状況とタイムライン 脆弱性は2026年6月下旬に公開された。Sysdigによれば、最初の実際の悪用行為はその13日後に検出されており、送信元はProtonVPNのIPアドレス(159.26.98[.]241)からのものだった。SysdigのシニアディレクターMichael Clark氏のコメントには報道間で幅があり、SecurityWeekやBleepingComputerでは「開示から2週間足らず後(13日後)に実悪用が始まっていた」とする一方、The Hacker Newsでは「現時点の活動は攻撃者による初期調査(偵察)段階にとどまり、本格的な侵害への進展は確認されていない」とも報じられている。いずれの報道でも、脅威アクターがこの脆弱性に強い関心を寄せ、積極的にプロービングを行っている点では一致している。 Sysdigの調査では、インターネットに公開されているGiteaインスタンスは全世界で約6,200件確認されているが、そのうち実際に脆弱な設定のまま稼働している数までは特定されていない。悪用に成功した場合、攻撃者はプライベートリポジトリのソースコード、誤ってコミットされたAPIキーや認証情報、CI/CD設定、デプロイトークンなど、機密性の高い資産に完全にアクセスできてしまう。シンガポールのサイバーセキュリティ庁(CSA)もこの脆弱性について注意喚起を発行している。 今後の対応 Gitea運用者に対しては、直ちに修正版である1.26.3以降(推奨は1.26.4)へアップグレードすることが強く求められている。何らかの理由で即時のアップグレードが困難な場合は、REVERSE_PROXY_TRUSTED_PROXIES設定を実際に信頼できる特定のIPアドレスやCIDR範囲に限定することで、暫定的にリスクを低減できる。加えて、過去のアクセスログを確認し、不審なX-WEBAUTH-USERヘッダーを伴うリクエストや、身に覚えのない管理者アカウントでのログイン履歴がないか点検することも推奨されている。今回のケースは、公式コンテナイメージのデフォルト設定が誤っていた場合、パッチ公開後もごく短期間で実運用環境への攻撃に直結し得ることを改めて示す事例となった。

July 11, 2026

GitHub Actions、ホスト型ランナーの起動遅延障害が約9時間継続 終盤には最大96%のジョブが起動失敗

概要 GitHubは7月9日、GitHub Actionsのホスト型ランナーでジョブの起動遅延が発生する障害を確認した。障害はUTC午前4時34分(日本時間13時34分)に初期報告され、同日13時52分(日本時間22時52分)に復旧が完了するまで、約9時間18分にわたって継続した。GitHubは公式ステータスページで「GitHub-hosted runners上で実行されるGitHub Actionsのジョブのうち約30%が、5分を超える起動遅延を経験している」と発表し、多数の組織のCI/CDパイプラインに影響が及んだ。 影響の推移と範囲 障害の影響は段階的に拡大した。発生当初は全体の約5%のジョブで5分以上の起動遅延が見られる程度だったが、その後悪化が進み、約30%のジョブが5分を超える遅延に見舞われる状態がしばらく続いた。さらに終盤の約20分間には約96%のジョブが起動に失敗する状態にまで悪化した後、回復に転じた。遅延が長引いた一部のジョブは、リトライ回数の上限を超えて最終的に失敗する事態にもつながった。 影響はActionsランナーの起動遅延にとどまらなかった。GitHub Pagesのビルド処理も同じ障害の余波を受けたほか、Copilot Cloud AgentおよびCopilot Code Reviewについても約30分間、起動に失敗する状態が発生した。なお、GitHub Pagesで公開済みのサイト自体は、この間もアクセス可能な状態が維持されていた。 復旧までの対応 GitHubはインフラストラクチャ側の緩和措置に取り組みながら段階的な復旧を進め、最終的にモニタリングを通じて完全な回復を確認したと報告している。障害発生から復旧完了までの詳細な技術的原因については、公式ステータスページ上で個別の根本原因分析は示されていないが、GitHub Actionsのようにビルドやデプロイの中核を担うマネージドサービスで長時間の遅延が発生したことは、CI/CDを日常的に利用する多くの開発チームの作業に直接的な影響を与えたとみられる。

July 11, 2026

TypeScript 7.0が正式リリース、Go移植でビルド最大12倍高速化

概要 マイクロソフトは7月8日、コンパイラをGoで全面的に書き直したTypeScript 7.0を正式リリースした。従来JavaScriptで実装されていたコンパイラをネイティブコードに移植したことで、マイクロソフトは「10倍高速なネイティブ移植版」と位置づけている。6月18日にリリース候補(RC)版が公開されてから約3週間でのGA(一般提供)到達となった。既存の型チェックの挙動やコマンドライン操作との互換性は維持されており、npm install -D typescript@rcでRC版を試していた開発者は、正式版へ問題なく移行できる。 パフォーマンスの詳細 実プロジェクトでのベンチマークでは劇的な速度向上が確認されている。VS Codeのビルドは125.7秒から10.6秒(11.9倍)、Sentryは139.8秒から15.7秒(8.9倍)、Playwrightは12.8秒から1.47秒(8.7倍)に短縮された。メモリ使用量も6〜26%削減され、VS Codeの場合は5.2GBから4.2GBに減少している。エディタ体験も改善し、VS Codeでファイルを開いてからエラー検出が完了するまでの時間は17.5秒から1.3秒へと大幅に短縮された。この高速化は、解析・型チェック・出力など多くの処理段階を並列実行できるアーキテクチャによるもので、ファイル間の処理をほぼ独立させることで大規模コードベースでのスケーラビリティを高めている。並列化を制御する--checkers(デフォルトでワーカー4つ)や、プロジェクト参照のビルドを並列化する--buildersといった新フラグも導入されたほか、デバッグや資源制約環境向けに--singleThreadedフラグも用意された。ファイル監視機能もParcelのウォッチャーをGoに移植する形で刷新されている。 破壊的変更と設定のデフォルト変更 7.0では設定のデフォルト値が大きく変わっている。strictモードがデフォルトで有効になったほか、moduleのデフォルトはesnext、typesは(従来の自動スキャンから)空配列[]、rootDirは./となった。また非推奨とされていた機能は明確なエラーを返すようになり、ES5ターゲットの廃止、AMD/UMDモジュールの非対応、classicモジュール解決の撤廃、baseUrlの非サポートなどが該当する。細かな仕様変更としては、テンプレートリテラル型がUnicodeのコードポイントを自然な形で保持するようになった点も挙げられ、例えば"😀abc"はUTF-16のサロゲートペアではなく["😀", "abc"]として分割される。 エコシステムへの影響と今後の展望 一方で、Vue、Svelte、Astro、MDX、Angularのテンプレートなど、プログラマティックAPIを必要とするフレームワークは現時点でTypeScript 7を利用できない。これは安定したプログラマティックAPIがまだ提供されておらず、7.1で導入予定であるためだ。当面の回避策として、TypeScript 7のCLIとTypeScript 6.0を併用し、エディタ側のサポートを6.0で担う運用が推奨されている。typescript-eslintのようなツール向けには、@typescript/typescript6パッケージがtsc6実行ファイルを提供し、名前空間の衝突を避けつつTypeScript 6.0のAPIに並行アクセスできるようにしている。実運用での検証も進んでおり、Slackはマージキューの待ち時間を40%削減しCIの型チェックを7.5分から1.25分に短縮、Vantaは大規模プロジェクトで9倍の高速化、マイクロソフトのニュースサービス部門はCIビルドで月400時間の削減、Canvaはエラー検出時間を58秒から4.8秒に短縮したと報告している。マイクロソフトは7.0リリース後に機能開発を再開し、3〜4か月ごとに新版を出す方針で、次のTypeScript 7.1ではエンベデッドフレームワーク向けの新しいプログラマティックAPIが導入される見込みだ。

July 10, 2026

Linux Foundation、AIエージェントに信頼できる身元を与える新標準「Agent Name Service」を発表

概要 Linux Foundationは、インターネット上で活動するAIエージェントに信頼できる識別子と名前を与える新しいオープンソース標準「Agent Name Service(ANS)」の立ち上げ意向を発表した。既存のDNS(ドメインネームシステム)インフラを拡張することで、中央集権的な管理者を置かない形でAIエージェントに関する認証・信頼・ガバナンス・相互運用性の課題解決を目指す取り組みだ。Cloudflare、シスコ、セールスフォースなど複数の企業がこの立ち上げに賛意を示している。 解決しようとしている課題 近年、AIエージェントが自律的にコードを生成したり、システムの運用タスクを実行したりする場面が急速に増えている。しかし現状では、あるエージェントがどの組織や人物によって提供されているのかを検証する仕組みや、生成されたコードやシステム操作の履歴が実際にそのエージェント自身によって実行されたものかを確認する仕組みが整っていない。ANSは、AIエージェントに対してインターネット規模で分散された自律的なアイデンティティ層を確立することで、こうした身元不明・出所不明のエージェントが引き起こす認証やガバナンス上の問題に対応しようとしている。 技術的な仕組み ANSの特徴は、単一のアイデンティティ方式に依存せず、複数の識別システムに対応する設計になっている点だ。具体的には、既存のDNSに加えて、分散型識別子であるDID(Distributed Identity)、法人や取引主体を識別するLEI(Legal Entity Identifier)といった仕組みとの連携を予定している。これにより、企業や組織はすでに導入済みのアイデンティティ管理基盤を活かしながら、AIエージェントの身元確認の仕組みにスムーズに統合できるようになる。DNSという広く普及した既存インフラを土台にすることで、特定のベンダーやプラットフォームに縛られない、相互運用性の高い基盤を目指している点も特徴だ。 今後の展望 Linux Foundationによる本標準の立ち上げには、Cloudflareやシスコ、セールスフォースといった大手企業がすでに賛同を表明しており、業界横断的な取り組みとして進められる見通しだ。AIエージェントが企業システムやインターネットサービスと自律的にやり取りする機会が今後さらに増えることが予想される中、ANSのような信頼できる身元基盤の整備は、なりすましや不正なエージェントによるリスクを抑えつつ、AIエージェント同士やエージェントと人間との安全な連携を支える重要な基盤になると期待される。

July 8, 2026

VS Code 1.127リリース、ブラウザ操作エージェントがGAへ ターミナルのサンドボックス実行も追加

概要 Microsoftは2026年7月1日、Visual Studio Codeの最新版となる1.127をリリースした。今回のアップデートでは、AIエージェントによるブラウザ操作機能が正式版(GA)となったほか、サイトごとのブラウザ権限管理、macOS/Linux向けターミナルコマンドのサンドボックス実行、複数チャットセッションの整理機能など、AIエージェントを軸にした開発体験の強化が中心となっている。 ブラウザ操作機能のGA化とサイトごとの権限管理 エージェントが統合ブラウザ上でWebアプリをビルド・テストできる機能が、設定workbench.browser.enableChatToolsのもとで正式提供された。この機能により、エージェントは外部のMCPサーバーを介さずに、スクリーンショットの取得、ページ内要素の選択、テキスト入力、ページ遷移といった操作を直接実行できる。 これに合わせて、サイトごとのブラウザ権限設定も新たに導入された。位置情報、カメラ・マイク、加速度計・ジャイロスコープ、クリップボード、Bluetooth・USB・シリアル・HIDといった各種Web APIへのアクセスについて、サイトごとに許可・ブロックを選択でき、「Site Permissions」メニューから一元管理できる。 ターミナルのサンドボックス実行とAgentsウィンドウの改善 セキュリティ面では、macOSおよびLinux環境において、エージェントが実行するターミナルコマンドをサンドボックス内で実行できるようになった。ネットワークアクセスのブロックやファイルシステムアクセスの制限を伴う環境でコマンドを動かすことで、サンドボックス外での実行が必要な場合にのみ承認を求める仕組みとなり、これまで頻発していた承認プロンプトを削減しつつ安全性を確保している。 Agentsウィンドウでは、関連するセッションをグループ化してヘッダーで折りたたんだり、ドラッグ&ドロップで並び替え・グループ追加・ピン留めを行えるようになった。また、1つのエージェントセッション内で複数の独立したチャットを同時に実行できるようになり、各チャットの進捗や変更内容がまとめて集約表示される。CI失敗やプルリクエストのコメントに対しては、チャット入力欄上部に表示される「Chat input banner」から直接対応できるほか、コード行にホバーすると表示される「Add Feedback」グリフを使って、エージェントへのフィードバックをインラインコメントとして挿入することも可能になった。 今後の展望 このほか、サブエージェントが消費したAIクレジットをホバー表示で確認できるコスト管理機能や、カスタム指示が無視される原因や応答遅延を診断する/troubleshootコマンドも追加された。エンタープライズ向けには、managed-settings.jsonによるCopilot設定のファイルベース配信や、BrowserChatTools・ChatAgentNetworkFilterといったポリシーによるブラウザツール制御機能も強化されており、組織単位でのAIエージェント機能の管理・統制がより容易になった。なお、組み込みのOllamaプロバイダーは非推奨となり、公式拡張への移行が推奨されている。一連の変更から、VS Codeがエージェントによる自律的な開発作業を前提に、安全性と管理性を両立させる方向へ舵を切っていることがうかがえる。

July 7, 2026