2026年10月1日の技術アップデート：npmのOIDC強化、HydraFusion、AWSデータ基盤の進化

直近24時間では、「秘密の長期トークンを減らす」「AIに複数モデルを役割分担させる」「データを移動せずに検索・分析する」という3つの流れが目立ちました。

特に押さえたいのは、npmのTrusted Publishingがさらに使いやすくなったこと、GitHub CopilotのHydraFusionがVS Codeまで広がったこと、AWSがAurora PostgreSQLとS3 Vectorsをそれぞれ強化したことです。

今日何が重要か

今日の更新は、単なる新機能の追加というより、開発や運用の「面倒だった部分」を減らす方向に進んでいます。

npmでは、パッケージ公開後のタグ操作までOIDCで行えるようになり、長期間保存するアクセストークンをさらに減らせます。
GitHub Copilotでは、1つのAIモデルを固定して使うのではなく、複数モデルを自動で組み合わせるHydraFusionがVS CodeとCopilotアプリでも試せるようになりました。
AWSでは、Aurora PostgreSQLからS3上のデータを直接SQLで読めるようになり、S3 Vectorsでは検索前にメタデータで絞り込む仕組みが追加されました。

この3つはそれぞれ、Supply Chain Security、AI Agent設計、データ基盤設計の基本につながる更新です。

1. npmのTrusted Publishingでdist-tagまでOIDC管理できるようになった

結論から言うと、npmパッケージ公開のために保存していた長寿命アクセストークンを、さらに減らせるようになりました。

GitHubの公式発表では、npmのTrusted Publishing設定に「Allow npm dist-tag」という権限が追加されています。

Trusted Publishingとは何か

npmにパッケージを公開するとき、以前はCI/CDにnpmのアクセストークンをSecretとして保存する方法が一般的でした。

しかし長期間有効なTokenをCI/CDへ置いておくと、Workflowや依存パッケージが侵害されたときに、そのTokenまで盗まれる危険があります。

Trusted Publishingでは、GitHub ActionsなどのCI/CDが**OIDC（OpenID Connect）**を使って「私はこのRepositoryのこのWorkflowです」とnpmへ証明します。npmはその証明を確認し、短時間だけ有効な権限を渡します。

つまり、

昔：Secretとしてnpm Tokenを保存する

から、

今：実行時に本人確認して短時間だけ権限をもらう

へ変わっています。

今回は何が増えたのか

npmのdist-tagは、あるVersionへ「latest」「next」「beta」などの名前を付ける仕組みです。

たとえば1.5.0を公開したあとに、

latest → 1.5.0

と切り替えることで、利用者が通常のnpm install package-nameをしたときに1.5.0が選ばれるようになります。

これまではTrusted PublishingでPackageの公開をTokenレスにできても、dist-tag操作のためだけに長寿命Tokenを残すケースがありました。今回から、この操作もOIDCの短期Credentialで実行できます。

新しい権限は既定ではOFFなので、必要なTrusted Publishing設定だけ明示的に許可します。

誰に影響するか

npmへ自作Libraryや社内PackageをCI/CDから公開している人が対象です。

GitHub Actionsでnpm TokenをSecretへ保存している場合は、Trusted Publishingへ移行できないか確認する価値があります。

今すぐ壊れる変更ではありませんが、Supply Chain Securityを考えるなら「強い長寿命Secretを減らす」という方針は覚えておきたいところです。

2. GitHub CopilotのHydraFusionがVS Codeでも使えるようになった

GitHub Copilotでは、1つのAIモデルを選ぶ方式から、複数モデルを自動で組み合わせる方式が広がっています。

9月30日、HydraFusionのResearch PreviewがVS CodeとGitHub Copilotアプリにも追加されました。これまではCopilot CLIが中心でした。

HydraFusionとは何か

HydraFusionは新しい単体モデルではありません。

ユーザーのタスクを見て、どのモデルをどの順番で使えば「必要な品質を満たしつつ、無駄を減らせるか」を自動で決める仕組みです。

GitHubは3つの実行パターンを説明しています。

Singleでは、1つのモデルがそのまま回答します。

Cascadeでは、まず軽量なモデルが回答し、品質チェックを通らなければ強いモデルへ引き継ぎます。

Critiqueでは、1つのモデルが作った回答を別系統のモデルが読み取り専用でレビューし、その指摘を使って最初のモデルが1回修正します。

なぜ重要なのか

AI Agentを作るとき、「全部最高性能モデルに任せる」と品質は上げやすい一方で、料金や待ち時間が増えます。

逆に「全部軽量モデルに任せる」と安く速くなりますが、難しいタスクで失敗しやすくなります。

HydraFusionの考え方は、

簡単な仕事は軽量モデル、難しい仕事だけ強いモデル、必要なら別モデルがレビュー

という分業です。

これはAI Agentの設計でよく使われる**Model Routing（タスクに応じてモデルを振り分ける設計）**そのものです。

今すぐ何をするか

Research Previewなので、本番の重要処理をいきなり全面移行する必要はありません。

ただしCopilotを日常的に使っているなら、「モデルを1つ選ぶ」だけでなく、「複数モデルの組み合わせを自動最適化する」という次の使い方が広がっていることを理解しておくとよいでしょう。

3. Aurora PostgreSQLからS3上のIceberg・Parquetを直接SQLで読めるようになった

AWSは、Amazon Aurora PostgreSQLからApache IcebergとParquetのデータを直接問い合わせられる機能を発表しました。

大きなポイントは、S3上の過去データをAuroraへコピーしてから使う必要が減ることです。

まず「データレイク」とは何か

通常のRDBは、Applicationが頻繁に読み書きする現在のデータを扱うのが得意です。

一方で、ログや大量の履歴データ、分析用データはS3などに安く大量保存することがあります。このような大規模な保存領域をデータレイクと呼びます。

Parquetは分析に向いた列指向File形式、Icebergは大量の分析データをTableとして管理するための形式です。

以前は何が大変だったか

たとえば、

Auroraに現在の注文データ
S3に3年分の注文履歴

があるとします。

両方をSQLで一緒に分析したい場合、これまではS3側のデータをAuroraなどへ移すETL処理を用意するケースがありました。

ETLはExtract・Transform・Loadの略で、「データを取り出して、形を整えて、別の場所へ入れる処理」です。

今回の機能では、Aurora PostgreSQLのSQLからS3上のIceberg・Parquetを直接参照し、Aurora内のデータとJOINできます。

AWSは内部でDuckDBを組み込み、S3上の分析データを処理しています。

誰に役立つか

リアルタイムな業務データと大量の履歴データを一緒に使いたいシステムで役立ちます。

特にAI Agentが「現在の顧客状態」と「過去の履歴」をその場で組み合わせて調べるような構成では、事前に全データをコピーしなくてよくなる可能性があります。

対応VersionはAurora PostgreSQL 17.11以降と18.6以降です。

4. S3 Vectorsは「絞り込んでから類似検索」できるようになった

Amazon S3 Vectorsには、metadata pre-filteringが追加されました。

これはRAGやSemantic Searchを作るときに重要な更新です。

Vector検索とは何か

文章や画像をAIが扱いやすい数値の並びへ変換したものをVectorと呼びます。

Vector検索では、その数値同士の距離を比べて「意味が近いデータ」を探します。

RAGでは、ユーザーの質問に近い社内文書をVector検索で見つけ、その文書をAIへ渡して回答させます。

今回の変更

以前の方式では、大量のVectorから近い候補を探しながら「このCustomerのDataだけ」のようなFilterを確認する方式でした。

ENHANCED Modeでは、まずtenant_idやcategoryなどのMetadataで対象を絞り、その集合の中だけで類似検索します。

AWSによると、選択範囲が狭いFilterでは従来方式より最大5倍多くRelevantな候補を拾えるケースがあります。

たとえば800万件のSupport Ticketから、ある1社の400件だけを検索したい場合、その400件を先に絞ってから意味の近さを比較できます。

既存Indexは自動で切り替わらず、従来のCLASSIC Modeのままです。ENHANCEDへ変更する場合はIndex Modeを更新します。

5. GHE.comでは10月7日からX25519だけのTLS Clientが接続できなくなる

GitHubは、GitHub Enterprise Cloud with data residencyでX25519-only TLSを10月7日に終了すると案内しました。

TLSとX25519とは何か

TLSはHTTPS通信を暗号化する仕組みです。

通信を始めるとき、ClientとServerは「暗号化に使う秘密をどう共有するか」を決めます。この仕組みの1つがX25519です。

今回影響するのは、X25519しか提示できない特殊なClientです。

GitHubはFIPS対応のP-256やP-384を引き続きSupportします。現在のBrowser、OS、GitHub CLI、一般的なTLS Libraryは通常P-256にも対応しているため、多くの利用者は何もしなくて構いません。

古いProxyやSecurity ApplianceでX25519だけに固定している場合は、10月7日までにP-256を有効にする必要があります。

なお、これはGitHub.com全体ではなく、Data Residency付きのGitHub Enterprise Cloudが対象です。

6. GitHub TeamでもAdvanced Securityを試しやすくなった

GitHub TeamからGitHub Advanced SecurityのSelf-service Trialを開始できるようになりました。

GitHub Advanced Securityは、Code ScanningやSecret Scanningなどを使って、Repository内の脆弱性やCredential漏えいを検出するための機能群です。

これまではEnterprise向けの印象が強い機能でしたが、Team利用者もOrganization画面などからTrialを開始できます。

今すぐ既存設定が変わる更新ではありませんが、小〜中規模TeamでもSecurity Toolを比較しやすくなった変更です。

7. Thunderbird 157系でSecurity Fix

Mozillaは9月30日、Thunderbird 157のSecurity Advisoryを公開しました。153.4と140.17にもSecurity Updateが出ています。

ThunderbirdはMail Clientですが、内部ではFirefoxと共通するBrowser系Componentも多く使っています。そのため、Widget、DOM、Audio/VideoなどのMemory Safety問題もSecurity Advisoryに含まれます。

Mozillaは、Mail閲覧時にはScriptが無効なため、Browserと同じ条件でそのまま悪用できるわけではないと説明しています。

Thunderbird利用者は通常のApplication Updateとして最新版へ上げておくのが安全です。

8. AWS App Meshは9月30日でサポート終了

AWS App Meshは2026年9月30日でサポート終了となりました。

App Meshは、Microservice同士の通信をEnvoy Proxy経由で制御・監視するService Meshです。

AWSのDocumentationでは、9月30日以降はApp Mesh ConsoleやApp Mesh Resourceへアクセスできなくなると案内されています。

すでにApp Meshを使っている環境では「そろそろ移行を考える」段階ではなく、移行期限を過ぎた状態です。

対象環境が残っている場合は、ECS Service ConnectなどAWSが案内してきた移行先へ切り替えられているかを最優先で確認する必要があります。

小さな変更まとめ

今回の24時間では、Vue 3、React、Vite、Node.js、Bun、PHP、Docker Engine、Kubernetes、Terraformについて、上記より優先して取り上げる新しいStable Releaseは確認できませんでした。

一方で、GitHub・npmは「長寿命Credentialを減らす」、AWSは「データをコピーせず直接使う」「検索対象を先に絞る」といった、運用コストとSecurityの両方に効く変更が続いています。

実務で今日確認すること

npm PackageをCI/CDで公開しているなら、長寿命Tokenを使ったnpm dist-tagが残っていないか確認します。

GitHub Copilotを使っているなら、HydraFusionを「新モデル」と誤解せず、複数モデルを組み合わせるOrchestrationとして理解しておくとよいでしょう。

AWSでRAGやデータ分析を行っているなら、S3 VectorsのENHANCED ModeとAuroraのIceberg/Parquet直接Queryが既存Architectureを簡単にできないか確認できます。

GitHub Enterprise Cloud with data residencyを使っている組織は、X25519-onlyの特殊なTLS設定が残っていないか確認します。

そしてAWS App Meshがまだ構成に残っている場合は、サポート終了後の状態なので移行状況を最優先で確認してください。