OSS

概要 Microsoftは2026年8月11日、GitHub Copilot向けの新しいコーディングAIモデル「MAI-Code-1.1-Flash」を発表した。前モデル「MAI-Code-1-Flash」の後継として、コーディング品質や命令理解、ツール利用能力を向上させたほか、新たにネイティブな画像理解機能を搭載した。最大の特徴は価格で、旧モデルと比較して73%安価な料金設定を実現している。年間サブスクリプション契約者には0.25倍のプレミアム乗数が適用される。 Copilot CLI、GitHub Copilotアプリ、Visual Studio Code、Visual Studio、JetBrains IDE、Eclipse、Xcodeなど幅広い開発環境で利用可能。Free・Student版では自動的に選択される一方、Pro・Business・Enterprise版ではユーザーが手動で選択することもできる。Enterprise・Business管理者は管理設定で有効化する必要がある。 技術的な詳細 Microsoft AIによれば、MAI-Code-1.1-Flashは「より高品質なコード出力を、25%高いトークン効率で、4分の1のコストで」実現しているという。具体的な性能指標として、GitHub Copilot CLI上でのTerminal-Bench 2.1が22%向上、.NET関連タスクで15%の性能向上が確認されたと報告されている。実運用面では、生成コードの生存率が4%上昇し、ユーザーの再訪問率も9%増加したとしている。 効率性の面では、トークン生成速度が25%高速化し、同時にタスク完了に必要なトークン数も25%削減された。Microsoftは数十万規模の強化学習環境を用いてモデルを最適化し、そのコスト削減分をユーザーに還元したと説明している。 競合比較と評価 一方で、The Decoderの分析では、MAI-Code-1.1-Flashは競合のDeepSeek-V4-Flashに価格・性能の両面で見劣りするとの指摘がなされている。ベンチマークでは、SWE-bench VerifiedでMAI-Code-1.1-Flashが72.6%を記録した一方、Terminal Bench 2.1ではDeepSeekが82.7%とMicrosoftの62.9%を大きく上回った。価格面でも、DeepSeek-V4-Flashは入力$0.14・出力$0.28であるのに対し、MAI-Code-1.1-Flashは入力$0.20・出力$1.20と、DeepSeekが安価であるとされている。 同記事は、Microsoftがオープンウェイトの優れた代替モデルを採用するのではなく、性能で劣る自社製の非公開モデルに投資している点を問題視している。GitHub Copilotユーザーに自社モデルをデフォルトとして提供することで、市場シェアの囲い込みと利益率の改善を狙う戦略ではないかとの見方を示しており、これは技術的優位性や顧客選択の自由よりもエコシステムの支配を優先する戦略だと分析している。

概要 Googleは2026年8月11日、オープンソースの電子設計自動化(EDA)ツールチェーンを開発する非営利団体OpenROAD Initiative(ORI)に、最上位の会員区分である「プリンシパルメンバー」として参画したと発表した。同社のハードウェアツールチェーンチームに所属する技術プログラムマネージャーのAaron Cunningham氏が、ORIの運営委員会(Governing Board)の理事に選出され、戦略・財務・技術の各面で助言を行う体制となる。Googleのシリコンインフラストラクチャ責任者Drew Wingard氏は「最先端のシリコン研究には、堅牢で検査可能かつ再現可能なツールチェーンが不可欠だ」と参画の意義を説明している。 OpenROADの技術的特徴 OpenROAD Projectは、RTL(レジスタ転送レベル)の設計データからチップ製造用のGDSIIレイアウトまでを、人手を介さず24時間以内に自動生成する「RTL-to-GDSII flow」の実現を掲げるオープンソースEDAツール群である。学術研究を基盤に開発が進められており、これまでに500本以上の査読済み論文で参照されるなど、世界中の学生・研究者・スタートアップに広く利用されてきた。従来、チップ設計の自動化ツールは特定ベンダーの商用製品に依存する部分が大きく、高コストかつブラックボックス化しやすいという課題があったが、OpenROADはこうした制約からの脱却を志向するプロジェクトとして位置づけられている。 参画の狙いと体制 Googleのプリンシパルメンバーとしての関与は、(1)エコシステムの中立的な統治、(2)コミュニティ・利用基盤の拡大、(3)次世代技術者の育成、(4)CI/CDパイプラインやプロセス設計キット(PDK)の技術強化、という4つの重点領域に focus するとされる。ORIはカリフォルニアを拠点とする501(c)(3)の公益法人で、米国立科学財団(NSF)の「Pathways to Enable Open-Source Ecosystems(POSE)」プログラムから支援を受けて運営されており、Googleのような大手テクノロジー企業の高位メンバーシップ参画は、資金基盤と技術リソースの両面でプロジェクトの持続可能性を高めるものと見られる。 業界の反応と今後の展望 OpenROADの学術面での立役者として知られるUC San Diegoのアンドリュー・カーン(Andrew Kahng)教授は、今回の参画について「透明性と共有に基づく革新でエコシステムを構築する」という理念へのGoogleの貢献を評価し、プリンシパルメンバーシップが「オープンソースEDAエコシステムの安定した長期的基盤づくり」に寄与すると述べた。半導体設計の民主化とベンダーロックインの低減という目標に向け、今後はGoogleの技術リソースを活かしたCI/CD基盤やPDKの拡充が進むとみられ、学術・スタートアップ双方でのOpenROAD採用がさらに広がることが期待される。

概要 ネットワークプロトコルアナライザWiresharkの開発チームは8月13日、最新版となる4.6.8をリリースした。今回のアップデートでは、クラッシュにつながる約28件のセキュリティ脆弱性がまとめて修正されており、過去のリリースと比較しても大規模なセキュリティパッチとなっている。修正対象にはBluetoothスタックやUMTS(3G)関連プロトコル(RRC、UMTS FPなど)の解析処理も含まれ、ネットワーク解析の現場で広く使われるツールだけに、利用者には速やかなアップデートが推奨される。 修正された脆弱性の内訳 28件の脆弱性のうち9件はファイルパーサーに起因するもので、pcapng、Endace ERF、Tektronix K12xx、BUSMASTER、Catapult DCT2000、Gammu DCT3、3gpp phone logs、TTX Logger、Ixia IxVeriWave、Vector Informatikの BLFといった各種キャプチャファイル形式のパーサーが対象となった。これらは攻撃者が細工した悪意あるキャプチャファイルを開かせるだけで悪用が成立し得るため、ファイルの受け渡しを伴う運用では注意が必要だ。 残りの脆弱性は主にプロトコルディセクタ(解析コンポーネント)に関するもので、RDP、SSH、Kerberos、H.245、ESS、X.509IF、RRC、UMTS FP、CMS、C12.22、Bluetooth関連プロトコルなど多岐にわたる。具体的な不具合の種類としては、スタックバッファオーバーフロー、スタックオーバーリード、メモリ範囲外読み取りなどが報告されており、いずれも悪意あるパケットやキャプチャデータの取り込み時にクラッシュを引き起こす可能性がある。なお、NetLog JSONパーサーのスタック枯渇に関する問題も別途修正されているが、これは28件の番号付き脆弱性には含まれない。今回のリリースでは個別のCVE番号は付与されていない。 その他の改善点 セキュリティ修正に加え、プロトコルおよびキャプチャファイルサポートの改善も行われた。具体的には5G NAS(Non-Access Stratum)通信フィールドのデコード誤りが是正されるなど、プロトコル解析の精度向上に関する細かな修正も含まれている。 今後の見通し Wiresharkはネットワークトラブルシューティングやセキュリティ調査で広範に利用されるオープンソースツールであり、悪意あるキャプチャファイルやパケットを介した攻撃対象となるリスクが指摘されてきた。今回のような大規模な脆弱性修正は、ツールの堅牢性を高める上で重要な意味を持つ。利用者は公式サイトやパッケージマネージャーを通じて4.6.8への更新を行うことが推奨される。

概要 X（旧Twitter）は8月13日、「For You」タイムラインを支えるコア・ランキングエンジンのソースコードをApache v2ライセンスの下でGitHubに公開した。これにより、以前から一部公開していたコードベースの規模は約10〜15倍に拡大し、外部の開発者はGitHub上でプルリクエストを通じてアルゴリズムの改善を提案できるようになった。同時に、アプリ内で自分の投稿が「シャドウバン」されているかどうかを確認できる新しい透明性ツールの試験展開も始まっている。X幹部は「前例のないレベルのアルゴリズム透明性」だと説明しており、Elon Musk氏も「Transparency build trust（透明性が信頼を築く）」とコメントしている。 技術的な詳細 公開されたコードには、投稿の抽出からランキングまでを担うシステム一式に加え、異なるシグナルに重みを付けるパラメータや、ルール違反コンテンツをフィルタリングする仕組みが含まれる。中核をなすのは「Phoenix」と呼ばれるスコアリングシステムで、ユーザーは自分の環境でこれを実行し、外部の研究者が独立に検証できることも確認済みだという。X製品担当VPのKeith Coleman氏は「誰もが、プラットフォームが日々使っているのと同じランキングコードを見られるようになる」と述べている。一方で、Grokを用いた投稿の違反予測システムはスパム対策の観点から非公開のままとされ、公開範囲には一定の線引きがある。 シャドウバン確認機能 新設された「Under the Hood」ページでは、過去1ヶ月間に10回以上投稿しているユーザーを対象に、自分の投稿に適用された表示制限（visibility-limiting）ラベルの集計統計をJSONファイルとしてダウンロードできる。個別の投稿ごとの詳細ではなく月単位の集計データが中心で、非フォロワーや未成年ユーザーから非表示にされた場合の理由なども明記される。技術に詳しくないユーザー向けには、LLMを使ってこのJSONデータを解釈する使い方も想定されている。現時点ではアカウント登録から1年以上経過した小規模なテスターグループのみが利用可能となっている。 背景と今後の展望 Xはこれまで、特定の投稿やアカウントを意図的に目立たなくする「シャドウバン」を行っているとの疑惑にたびたび直面してきた。特に政治的な文脈での影響や、フェイクニュースの拡散への懸念が背景にあり、今回の一連の施策はユーザーが自らアルゴリズムのデータを検証できるようにすることでこうした批判に応える狙いがあるとみられる。ただし、過去のコード開示ではあまり実質的な情報が明かされなかったとの指摘も一部で上がっており、今回の公開が実際にどこまで透明性向上につながるかは今後の運用次第となりそうだ。シャドウバン確認ツールは現在小規模テスト段階だが、将来的には全ユーザーへの展開が計画されている。

概要 オープンソースの地理空間データ基盤GeoServerに、パッチが提供されていないゼロデイのSQLインジェクション脆弱性が発見され、公開からわずか数時間で悪用の試みが本格化していることが明らかになった。脆弱性は8月12日10:46 UTC、研究者「@q1uf3ng」がX（旧Twitter）上でバグバウンティの一環として公開したもので、記事執筆時点でもCVE番号は採番されておらず、ベンダーからの修正パッチも未提供の状態が続いている。GeoServerは政府、国防、科学、教育、工学・技術分野など幅広い業界で利用されており、影響範囲の広さが懸念されている。 セキュリティ企業watchTowrのプリンシパルセキュリティリサーチャーであるJake Knott氏によると、脆弱性の公開後、少数の発信元IPアドレスから数百件に及ぶ悪用試行がすでに観測されている。ただし現時点では攻撃者はエラーを発生させるだけで、悪意あるペイロードの投入やコマンド実行までは至っておらず、脆弱なインスタンスを洗い出すための偵察活動の段階にあるとみられる。Knott氏は「この状況が長く続くとは考えにくい」と警告しており、GeoServerが過去に大規模な悪用を受けてきた経緯を踏まえると、攻撃がより深刻な段階へ移行するのは時間の問題だとの見方を示している。 技術的な詳細 脆弱性はGeoServerのjsonArrayContains関数に存在し、認証なしでユーザーが任意のSQLコマンドをデータベースに注入できる。通常の設定であれば影響はデータ漏洩や改ざんにとどまる可能性があるが、Microsoft SQL Server上でデータベースが管理者権限のアカウントで稼働している構成では、SQLインジェクションがシステムコマンドの実行ベクトルへと昇格し、リモートコード実行（RCE）にまで発展し得る。記事では、別の研究者がデフォルト以外の設定でこの欠陥の再現に成功したことも報告されており、実環境での悪用可能性が裏付けられた形だ。 過去の悪用実績と背景 GeoServerはこれまでにも複数の脆弱性がCISAの既知悪用脆弱性（KEV）カタログに登録されており、2024年にはCVSSスコア9.8の深刻な脆弱性CVE-2024-36401がDDoSボットネットや暗号資産マイニングの目的で武器化された実績がある。このような経緯から、GeoServerの脆弱なインスタンスは攻撃者にとって価値の高い標的とみなされており、今回のゼロデイも同様の大規模悪用に発展するリスクが指摘されている。 対策と今後の見通し パッチが存在しない現状において、専門家は組織に対し、インターネットに公開されているGeoServerインスタンスを速やかに特定し、可能な限り公開アクセスを制限するよう推奨している。あわせて、すでに悪用の痕跡がないかログを点検することも重要だとされる。ベンダーからの正式な修正パッチが提供されるまでの間、露出したインスタンスは持続的なリスクにさらされることになり、状況の推移を注視する必要がある。

概要 GitHubは8月11日、JetBrains向けGitHub Copilotに2つの新機能を追加したと発表した。1つ目は「Copilot memory」と呼ばれる会話メモリ機能で、agent chatのセッションをまたいで有用な情報を保持・想起できるようになる。プロジェクトの詳細や個人の設定を毎回入力し直す手間がなくなり、開発者はより自然な形でCopilotとの対話を継続できる。2つ目は、ローカルモデルプロバイダーとしてOllamaをBYOK(Bring Your Own Key/Model)方式で選択できる連携機能で、開発者はクラウドサービスに依存せずローカル環境で動くモデルを使ったコーディング支援を受けられるようになった。 機能の詳細 Copilot memoryは、Copilot設定ポータル内の「Copilot Memory」トグルで有効・無効を切り替えられる。有効にすることで、これまでチャットセッションごとにリセットされていた文脈情報がセッションを越えて保持され、プロジェクト固有の情報や開発者ごとの好みを繰り返し伝える必要がなくなる。一方のOllama連携は、JetBrainsのプロバイダー設定・モデル選択のUI全体に統合されており、他のBYOKプロバイダーと同様の操作感でローカルモデルを組み込める設計になっている。今回のアップデートにはCopilot CLIの自動インストール対応も含まれており、macOS・Linux・Windowsの各プラットフォームで利用可能とされている。 背景と今後 ローカルLLMを手軽に実行できるOllamaとの連携は、機密性の高いコードをクラウドに送信したくない開発者や、オフライン環境での開発を求めるユーザーにとって有力な選択肢となる。GitHubは今回の変更点についてフィードバックを募集しており、JetBrains版Copilotの機能拡張は今後も継続していく方針とみられる。会話メモリ機能とあわせて、Copilotの利用体験は「その場限りのアシスタント」から「開発者の文脈を学習し続けるパートナー」へと進化を続けている。

概要 Zed Industriesは8月12日、開発者とAIエージェントが同じ場所でコードを書き、レビューできるマルチプレイヤー開発環境「Delta」を発表した。創業者のNathan Sobo氏は「Delta keeps code and conversations connected」と述べ、コード変更がどのような経緯で生まれたのかという文脈を失わないことを設計の核に据えたと説明している。従来のコミットベースの開発フローでは、AIエージェントとのやり取りの過程がコミット履歴から切り離されがちだったが、Deltaはコードの進化に伴う会話の全履歴を保持し、コメントを特定のコード行に紐付けたまま自動的に追従させる。現時点ではプライベートベータの段階で、初期ユーザーへの招待が始まっており、今後数週間かけて対象を広げていく予定だ。 技術的な詳細 Deltaの中核を支えるのが、新設計のデータベース「DeltaDB」だ。DeltaDBはCRDT（Conflict-free Replicated Data Type）をベースとしており、複数の参加者が同時にコードや会話を編集しても自動的に内容を調和させる。「DeltaDBは会話とワークツリーを一体として、リアルタイムに複製する」設計になっており、既存のGitリポジトリとも互換性を保ちながら、コミットとコミットの間に発生したすべての編集と会話のやり取りを記録できる点が特徴だ。 利用方法も複数用意されている。macOS・Linux向けのデスクトップアプリでローカル実行できる（Windows対応は近日公開予定）ほか、RustアプリケーションをWebAssemblyとWebGLでビルドしたブラウザ版により、インストールなしでほぼ同等の体験を提供する。さらにターミナル経由でClaude Codeなど外部のAIエージェントとも連携できる設計になっており、単一のエディタに閉じない柔軟な使い方を想定している。インターフェース面では、AIエージェントとの会話を単に受動的に眺めるログとしてではなく、人間が直接編集できるドキュメントとして扱う点も特徴で、スレッド内の任意の位置にカーソルを置いてコメントを付けられるため、エージェント側もユーザーの意図をより正確に把握できるという。 チーム利用も考慮されており、スレッドに他のメンバーを招待すると、全員がリアルタイムで同期されたワークツリーにアクセスできる。処理をクラウドランナーに移行することも可能で、エージェントがバックグラウンドで作業を続けている間に、開発者は別のタスクへ移れる仕組みになっている。 今後の展開 Zedは、DeltaDBを将来的には既存のZedエディタ本体にも統合する方針を示しているが、現時点では新環境Deltaの開発が優先事項だという。既存のZedユーザーへの影響を最小限に抑えつつ、Deltaで新しいプリミティブを段階的に検証・改善していく考えを示している。AIエージェントとの協働を前提としたコーディング環境が各社から相次いで登場する中、Zedは「コードと会話の文脈を切り離さない」という切り口で独自のポジションを打ち出した形だ。

概要 PostgreSQLプロジェクトは8月13日、サポート対象となっている全バージョン（18.6、17.11、16.15、15.19、14.24）に対する定期アップデートを公開した。今回のリリースでは28件のセキュリティ脆弱性と110件以上のバグが修正されており、あわせて次期メジャーバージョンとなるPostgreSQL 19のベータ3も公開された。マイナーバージョンアップデートのため、既存環境ではpg_dumpの再実行やデータのリロードは不要で、PostgreSQLを停止してバイナリを更新後に再起動するだけで適用できる。 セキュリティ脆弱性の詳細 修正された28件の脆弱性のうち、特に深刻度の高いものが多数含まれている点が今回のリリースの特徴だ。CVSSスコア8.8の脆弱性としては、tsvector/tsqueryの整数オーバーフロー、正規表現処理におけるヒープバッファオーバーフロー、to_char関数のヒープバッファオーバーフロー、plperlのtiedオブジェクトに起因するヒープバッファオーバーフロー、pg_stat_statementsのヒープバッファオーバーフローなどが挙げられ、いずれも悪用された場合は任意コード実行につながる恐れがある。このほか、EXTRACT関数の引数を通じたSQLインジェクションや、pg_restore_attribute_stats()・カーソルのCLOSEとDECLAREの組み合わせにおける型混同、pg_dumpのヒープバッファオーバーフローなども同スコアで報告されている。psqlクライアント側の脆弱性としては、COPY FROM STDINの早期終了によりデータ行がpsqlコマンドとして処理されてしまう問題（CVSS 8.1）や、\unrestrictコマンドを通じた任意コード実行（CVSS 8.8）も修正された。中程度の深刻度では、ロジカルデコーディングを悪用した任意ファイルのdlopenや、pgcryptoにおける平文暗号化の脆弱性なども対象に含まれる。 主なバグ修正 セキュリティ修正に加え、データの整合性に関わる重要なバグ修正も多数含まれる。並列GINインデックスビルドでは、並列ワーカーが初期化されていない行数を報告することでreltuplesが無限大やNaNになる問題が修正されており、該当するインデックスを持つテーブルではANALYZEの再実行が推奨されている。btree_gistでは、float4/float8のNaN処理やbit/bit varying型のソート順に問題があり、影響を受けるインデックスの再構築が必要となる。また、14,653個以上のラベルを含むltree値の比較が不正確になり、B-treeインデックスが破損する可能性がある問題も修正されたため、該当するインデックスの再構築が推奨される。このほか、RANGEパーティションのデフォルトパーティション処理、外部テーブルにおけるランタイムパーティション剪定、RETURNING句のOLD/NEW処理、ハッシュジョインのパフォーマンス、jsonpathの@?・@@演算子のエラー処理、VACUUMのラップアラウンド失敗時セーフモードなど、幅広い領域で修正が行われている。 19 Beta 3とサポート終了について 同時にリリースされたPostgreSQL 19 Beta 3では、Beta 1で導入されていたGROUP BY ALL機能が撤回されたことが大きな変更点となる。このほか、FOR PORTION OFテンポラルテーブル構文やロジカルレプリケーションのシーケンス同期機能、REFRESH SEQUENCESのレース条件、postgres_fdwにおける配列比較のプッシュダウンなど、複数の不具合が修正されている。プロジェクトは本番相当のワークロードでのベータ版テストを呼びかけており、フィードバックはPostgreSQL公式のバグ報告フォームから受け付けている。なお、PostgreSQL 14は2026年11月12日にサポート終了が予定されており、同バージョンを本番環境で運用しているユーザーには早めのアップグレード計画の策定が推奨される。

概要 複数モデルプロバイダーへの接続を担うオープンソースのAIゲートウェイ「LiteLLM」で発生した供給チェーン攻撃の全容が、新たな分析により明らかになった。2026年3月24日、悪意あるバージョン(v1.82.7およびv1.82.8)がPyPI上でわずか約40分間だけ公開されたが、この短い時間の間に自動デプロイ基盤を通じて急速に拡散し、AWS、NVIDIA、Cisco、Samsung、Salesforce、ServiceNow、Siemens、FedEx、Volkswagenなど大手企業を含む2,500近い組織のクラウド認証情報、SSH鍵、Kubernetesトークン、データベースパスワード、AIプロバイダーAPIキーなどが窃取された。セキュリティ企業CloudSEKは約434,000ファイル、Hudson Rockは153GBのアーカイブ(433,909ファイル、118,829件のCI runnerダンプ)を分析し、2,488のドメインに影響が及んだと結論づけている。ただしこれらの数値は確認された被害組織数ではなく、攻撃者が収集したログとファイルの規模を表す点には注意が必要だ。 Trivyハックとの関連 今回の攻撃はLiteLLMが直接狙われたものではない。攻撃者集団「TeamPCP」(Googleの追跡名ではUNC6780)は、まずAqua Securityが運営する脆弱性スキャナー「Trivy」を侵害し、3月19日には77個あるtrivy-actionのバージョンタグのうち76個と、setup-trivyの全7タグに悪意あるコミットを強制プッシュした。LiteLLMのCIパイプラインがこの汚染されたTrivyを自動的に取り込んだことで悪意あるコードがビルドシステムに侵入し、最終的に正規のリリースとしてPyPIに公開される結果となった。CloudSEKはこの経路を「Trivy、次にビルドシステム、そしてLiteLLMのリリース。失効しなかったトークン一つが、3つのツールを貫いた」と表現している。 技術的な詳細 侵害されたパッケージには多段階の認証情報窃取マルウェアが仕込まれていた。特にv1.82.8にはlitellm_init.pthという起動用ファイルが含まれており、Pythonインタプリタが起動時に処理する仕組みを悪用することで、LiteLLMを明示的にインポートしなくても悪意あるコードが実行される設計になっていた。この仕組みにより、パッケージが公開されていた短時間でも高い感染率を実現したとみられる。マルウェアは環境変数、AWS認証情報、Kubernetes設定を収集し、systemdサービスを通じて永続化する機能も備えていた。攻撃のタイムラインとしては、3月24日午前10時39分(UTC)に悪意あるバージョンが公開され、同日午前11時19分頃にPyPI側が隔離、3月26日にはCVE-2026-33634がCISAの既知悪用脆弱性(KEV)カタログに追加されている。 今後の対応と展望 セキュリティ企業各社は、影響を受けた可能性のある組織に対し、3月24日の監査ウィンドウ中に感染したインストールがないか確認し、LiteLLMがアクセスできた全てのシークレットを侵害済みとみなしてクラウドプラットフォーム、リポジトリ、SaaSシステム全体でローテーションすること、CIランナーの再構築、不審な.pthファイルや永続化の痕跡の調査、3月24日以降のログレビューを推奨している。FBIは「tpcp-docs」という命名パターンを持つリポジトリを侵害の指標として列挙しており、Hudson RockとCloudSEKはそれぞれ組織がドメインの影響有無を確認できるポータルを提供している。CloudSEKはAI基盤が「データ、アイデンティティ、計算資源、自律的なアクションが交差する高価値な結節点」であるとして、今後もAIインフラを狙った同種のサプライチェーン攻撃が増加する可能性を指摘している。

概要 Microsoftは8月12日、Visual Studio Codeの月例アップデート「1.133」を公開した。今回の目玉はClaudeセッション中にモデルプロバイダーをターンごとに切り替えられるようになったことで、これまでセッション全体で単一のプロバイダーに固定する必要があった制約が解消された。あわせて、GitHubへのサインインなしでAgentsウィンドウを利用できる仕組み、長い会話でも文脈を見失わないチャットのスティッキースクロール、統合ブラウザでのHTMLファイル自動リロードなど、AIエージェントとの協働をさらに滑らかにする機能が追加された。 Claudeのモデルプロバイダー切り替え これまでチャットセッションでは、AnthropicとCopilotのいずれか一方のモデルグループを選んだら、そのセッション中はプロバイダーを固定して使い続ける必要があった。1.133では、モデルピッカーに両方のグループが同時に表示されるようになり、同一セッション内でもターンごとに異なるプロバイダーのモデルへ切り替えられるようになった。Anthropicのモデルを利用した場合はユーザー自身のAPIキーを通じて課金され、Copilotのモデルを利用した場合は既存のCopilotサブスクリプションが適用される。用途や求める応答特性に応じて、都度最適なモデルを選び分けられる点が改善のポイントとなる。 Agentホストとエディタの改善 Agentsウィンドウについても変更が加わり、設定chat.agentHost.allowSignedOutWhenUsableを有効にすることで、GitHubアカウントへのサインインなしでも利用できるようになった。これはAgentホストの認証がGitHubアカウント全体ではなく個々のエージェントやモデルに紐づく形へと変わったことによるもので、現時点ではClaudeが対応済みであり、CopilotやCodexについても今後のリリースで対応が予定されている。Agentホストは「Agent Host Protocol(AHP)」に基づく専用プロセス上でエージェントハーネスを実行する構成となっており、Copilot SDKとの統合が進められている。 チャット面では、設定chat.stickyScroll.enabledによりスティッキースクロールが導入された。長い会話をスクロールする際、通過済みのプロンプトを画面上部に固定表示できるため、固定されたプロンプトをクリックして該当箇所に戻ったり、ナビゲーションボタンで前後のプロンプト間を移動したりできる。長時間にわたるエージェントとのやり取りでも文脈を追いやすくする狙いがある。 このほか、設定workbench.browser.autoReloadOnFileChangeにより、統合ブラウザで表示しているローカルHTMLファイルがファイル変更時に自動的に再読み込みされるようになった。エージェントによる編集結果をブラウザ操作なしで即座に確認できるようになり、AIとのフィードバックループがより短縮される。 今後の展望 今回のアップデートは、複数のAIプロバイダーやモデルを状況に応じて柔軟に使い分けられるようにするという方向性を明確に示している。Agentホストの認証をエージェント単位へ分離した設計や、スティッキースクロール・自動リロードといった細部の改善は、いずれもエディタとAIエージェントとの境界をさらに曖昧にし、開発者がコーディング作業の合間にAIとの対話を自然に差し込めるようにする狙いがある。今後もこの路線での機能拡張が続くとみられる。