Claude Code GitHub Actionの脆弱性、Issueを1件投稿するだけでリポジトリを完全掌握できるサプライチェーンリスク

概要 GMO Flatt SecurityのセキュリティリサーチャーRyotaKは、AnthropicのClaude Code GitHub Actionに重大な脆弱性を発見した。悪意あるGitHub IssueをターゲットのリポジトリにポストするだけでCI/CDワークフローを乗っ取れるというもので、Anthropicのアクション本体のリポジトリ(anthropics/claude-code-action)が侵害されれば、それを利用するすべてのダウンストリームプロジェクトへのサプライチェーン攻撃に発展しうる深刻なリスクだった。脆弱性はCVSS v4.0スコア7.8と評価され、Anthropicは報告から4日以内に初期修正を施した。 脆弱性の技術的詳細 今回の攻撃は2種類の脆弱性を連鎖させることで成立する。 権限バイパス(GitHub App Permission Bypass):Claude Code GitHub ActionのcheckWritePermissions()関数は、名前が[bot]で終わるアクターを実際の権限にかかわらず無条件に許可していた。GitHub Appは公開リポジトリに対して暗黙の読み取りアクセスを持ち、インストールトークンを使って任意の公開リポジトリにIssueやPull Requestを作成できる。これにより、攻撃者は自身のリポジトリに悪意あるGitHub Appを作成・インストールし、そのインストールトークンを用いてターゲットリポジトリでIssueを開くだけで、権限チェックを完全に迂回できた。 プロンプトインジェクション:権限バイパスに成功した後、攻撃者はIssueの説明文に偽のエラーメッセージや指示を埋め込み、Claude Codeに任意のコマンドを実行させることができた。Claude CodeはBashコマンドの一部(cat、headなど)をユーザー承認なしに実行するため、Linuxの擬似ファイル/proc/self/environを読み取ることでワークフロープロセスのすべての環境変数を外部に送信できた。 漏洩する情報とサプライチェーンへの影響 /proc/self/environから取得できる最も重大な情報はACTIONS_ID_TOKEN_REQUEST_TOKENとACTIONS_ID_TOKEN_REQUEST_URLだ。これらを使ってGitHub ActionsのOIDCトークン交換プロセスを再現することで、ターゲットリポジトリへのインストールトークンを取得でき、リポジトリコンテンツ・Issue・PR・ディスカッション・ワークフローファイルへの書き込みアクセスが手に入る。 さらに深刻なのは、Anthropicが管理するanthropics/claude-code-actionリポジトリ自体も同じワークフローを使用していた点だ。このリポジトリへの侵害に成功すれば、アクションに悪意あるコードを仕込んでアップストリームに反映させ、Claude Code GitHub Actionを利用するすべてのプロジェクトを一括して攻撃できるサプライチェーン攻撃が成立する。 また、デフォルトのワークフロー設定がallowed_non_write_users: "*"(誰でもトリガー可能)になっていたことや、2段階のワークフローチェーンを悪用してIssueへのwrite権限を持つトークンを先に窃取し、それを使って信頼済みユーザーの処理前にIssueを編集してプロンプトインジェクションペイロードを注入するという高度な攻撃経路も報告されている。 修正タイムラインと推奨対策 RyotaKが2026年1月12日に脆弱性を報告し、Anthropicは1月16日(4日後)にGitHub Appをデフォルトで拒否する修正をコミットした。その後も春にかけて多層的なハードニングが続けられ、現在の修正済みバージョンはclaude-code-action v1.0.94となっている。主な追加対策として、人間アクターの検証(checkHumanActor())、ワークフロー実行サマリーセクションのデフォルト無効化、URLベースの情報漏洩をブロックするカスタムghコマンドラッパー、子プロセスへの環境変数のスクラビング、トリガー後に編集されたIssueやコメントを無視するロジックが実装されている。バグバウンティ報酬は基本額$3,800に追加バイパス発見のボーナス$1,000を加えた合計$4,800が支払われた。 Claude Code GitHub Actionを利用している組織は、allowed_non_write_usersの設定を見直し、ワークフローに公開するシークレットをAnthropicのAPIキーとGITHUB_TOKENのみに絞り込み、可能であればワークフローのトリガーを信頼済みユーザーに限定することが推奨される。本件はAIコーディングツールをCI/CDパイプラインに統合する際のプロンプトインジェクション対策と最小権限原則の重要性を改めて示す事例となった。

June 28, 2026

Node.js 26.4.0リリース:仮想ファイルシステムサポートやパッケージマップなど多数の新機能追加

概要 Node.jsチームは2026年6月24日、Current版の最新リリースとなるNode.js 26.4.0を公開した。リリース担当はAntoine du Hamel(@aduh95)氏。本バージョンでは、仮想ファイルシステム(VFS)サブシステムの最小実装、パッケージマップを用いたモジュール解決、TLS証明書圧縮オプションなど、開発者の利便性とシステムの柔軟性を高める機能が複数追加された。 主要な新機能 仮想ファイルシステム(node:vfs) 最も注目すべき新機能は、node:vfs モジュールとして提供される仮想ファイルシステム(VFS)サブシステムの最小実装だ。これにより node:fs/promises のAPI呼び出しをマウントされたVFSインスタンスへディスパッチできるようになり、テストや組み込みシナリオでファイルシステムを仮想化する際の基盤となる。 パッケージマップによるモジュール解決 ローダーに**パッケージマップ(Package Maps)**機能が追加された(Maël Nison氏の貢献)。これはモジュール識別子の解決をカスタマイズする仕組みで、モジュールのエイリアスやリマップが柔軟に行えるようになる。大規模なモノレポ構成やカスタムモジュールロード戦略を採用しているプロジェクトに特に有用だ。 TLS証明書圧縮 Tim Perry氏が実装した certificateCompression オプションにより、TLSハンドシェイク時の証明書データを圧縮できるようになった。証明書サイズの削減によりネットワーク帯域幅の節約と接続確立の高速化が期待される。 その他の注目機能 FS改善: readFile() でユーザー提供のバッファを使用できるようになり、メモリ効率が向上(Matteo Collina氏) HTTP改善: closeIdleConnections() がpre-requestソケットもクローズするよう改善され、接続管理が最適化 NET強化: setKeepAlive() が TCP_KEEPINTVL と TCP_KEEPCNT をサポートし、TCPキープアライブの詳細な制御が可能に(Guy Bedford氏) dgram: bindSync() と connectSync() という同期メソッドが追加された FFI: AArch64およびx86_64向けの実験的な高速FFI呼び出しAPIが実装され、ほぼ全プラットフォームでのサポートも追加 パフォーマンス改善とバグ修正 パフォーマンス面では複数の最適化が施された。Buffer.prototype.copy() の高速化、simdutfを活用したUTF-8バイト長計算の高速化、WHATWGストリームのホットパスにおけるメモリ割り当ての削減、addAbortListener のオプションキャッシングによる高速化などが含まれる。 セキュリティ面では、CryptoモジュールにおけるHash._transformの未処理エラーの修正、BN_get_word エラーを無視しない修正(Crypto/TLS)、SQLiteのスタック使用後スコープバグの修正が行われた。バグ修正としては、WindowsでEPERMエラーをENOTEMPTYエラーとして誤扱いしない修正、URLSearchParams(null) が null= を正しく生成するよう修正なども含まれる。 依存関係の更新 依存ライブラリも複数アップデートされた。主なものとして npm 11.17.0、SQLite 3.53.2、libffi 3.6.0、acorn 8.17.0、ngtcp2 1.23.0、nghttp3 1.16.0が更新された。また blockList APIの安定性ステータスがリリース候補(Release Candidate)に引き上げられ、正式安定化に向けて一歩前進した。

June 27, 2026

GitHub CopilotのJetBrains向け更新、Claudeをエージェントプロバイダーとしてパブリックプレビュー提供

概要 GitHubは2026年6月22日、GitHub CopilotのJetBrains IDE向けプラグインに複数の新機能を追加したと発表した。最大のハイライトは、AnthropicのClaudeをCopilotのエージェントプロバイダーとして利用できるパブリックプレビューの開始だ。IntelliJ IDEAやWebStormをはじめとするJetBrains製品のユーザーは、Claude Code CLIをインストールし設定でパスを指定するだけで、IDE内からClaudeを活用したAIエージェント機能を試せるようになる。これまでVS Codeを中心に展開されてきたGitHub CopilotのAIエージェント統合が、JetBrainsエコシステムへも本格的に拡大した形だ。 Claudeエージェントプロバイダーの詳細 Claudeエージェントプロバイダー機能を利用するには、まずClaude Code CLIをローカル環境にインストールし、JetBrainsプラグインの設定画面でそのパスを指定する。現時点ではツール実行が自動承認モードで動作するため、エージェントの操作に対してユーザーが個別に承認を求められることはない。将来的には権限設定のカスタマイズが予定されており、セキュリティや制御の観点から細かな設定が可能になる見込みだ。また、本機能はCopilot BusinessおよびEnterpriseプランのユーザーを対象としており、利用には管理者が「エディタープレビュー機能ポリシー」を有効化する必要がある。 その他の新機能 今回のアップデートではClaudeエージェント以外にも多数の機能が追加された。組織・エンタープライズエージェント対応では、管理者が定義したカスタムエージェントを組織全体に配信できるようになり、ユーザーはエージェントピッカーから目的に合ったエージェントを選択して利用できる。CLIでのメッセージキューイング機能により、実行中のリクエストに対して「現在の応答完了後に追加(Add to Queue)」「即座に方向修正(Steer with Message)」「現在のターンを中止して送信(Stop and Send)」の3種類の操作が可能になった。さらに、セッション全体の集計統計を確認できるエージェントデバッグログの統合ビュー、モデルピッカーの拡張(/modelsコマンドやコンテキストウィンドウ選択)、ターンごとのAIクレジット表示、そしてクラウドエージェントの正式リリースなども含まれている。 今後の展望 VS Code向けに先行して提供されてきたGitHub CopilotのAIエージェント機能がJetBrains製IDEにも広がることで、より多くの開発者がEditorを問わず高度なAI支援を受けられる環境が整いつつある。特にClaudeをエージェントプロバイダーとして統合できる点は、OpenAI製モデルに限らず複数のAIモデルをCopilot基盤上で選択・活用できるエコシステムの拡充を示している。現在はプレビュー段階だが、権限設定のカスタマイズ対応など機能の成熟が進めば、企業利用での採用がさらに加速すると期待される。

June 23, 2026

GitHub CLI v2.95.0がリモートファイル読み取りに対応、PR数制限やNode 24デフォルト化も発表

GitHub CLI v2.95.0:クローン不要のリモートリポジトリ参照 GitHub CLIのバージョン2.95.0に、リモートリポジトリのファイルをクローンせずにターミナルから直接参照できる2つの新コマンドが追加された。gh repo read-file は指定したリモートリポジトリから単一ファイルの内容を取得し、gh repo read-dir はリポジトリのディレクトリ構造を一覧表示する。どちらのコマンドもパブリック・プライベートを問わず、アクセス権のある全リポジトリで利用可能で、GitHub Enterprise Serverも対象に含まれる。 ユースケースとして、READMEやドキュメントの素早い確認、複数リポジトリをまたいだ設定ファイルの比較、スクリプトや自動化処理への組み込みなどが想定されている。特にAIエージェントやCIワークフローとの統合において、クローン操作のオーバーヘッドなしにリポジトリ内容を参照できる点が有用とされており、開発者の日常的な作業効率向上に加えてツール・自動化統合への活用が期待される。 PR数制限:外部コントリビューターによる大量PR問題に対処 GitHubは書き込みアクセス権を持たないユーザー(外部コントリビューター)がオープンできるプルリクエスト数に上限を設定できる管理機能を追加した。リポジトリ管理者は「maximum number of open pull requests」を設定でき、上限に達したユーザーは既存のPRをクローズまたはマージしない限り新規のPRを作成できなくなる。 この機能の背景には、活発なオープンソースリポジトリで大量の低品質または投機的なプルリクエストがトリアージと審査キューを圧迫するという課題がある。信頼できるコントリビューターを対象外とするホワイトリスト機能も用意されており、フルのコラボレーターアクセスを付与することなく制限を個別に回避させることができる。なお、ドラフト状態のプルリクエストは上限カウントには含まれないため、準備中の作業は影響を受けない。 GitHub Actions:Node 24がデフォルトランタイムに 2026年6月16日より、GitHubホストランナーにおけるJavaScriptアクションのデフォルト実行環境がNode 20からNode 24に変更された。Node 20が2026年4月にEnd-of-Life(EOL)を迎えたことを受けた対応で、Node 20の完全削除は2026年秋に予定されている。 移行に際しては互換性の注意点がある。Node 24はmacOS 13.4以下の環境では動作しないため、古いmacOSランナーを使用しているワークフローは影響を受ける可能性がある。またARM32アーキテクチャへの公式サポートがないため、ARM32上のセルフホストランナーはNode 20廃止後にサポート対象外となる。移行準備のためにNode 24での動作を事前テストしたい場合は FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true 環境変数を設定することで確認できる。Node 20を一時的に継続使用するための ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true も用意されているが、あくまで移行期間の暫定対応として位置づけられている。

June 19, 2026

GitHub Copilotデスクトップアプリが正式リリース、Canvas・クラウド自動化など新機能を搭載

概要 GitHubは2026年6月17日、GitHub CopilotのスタンドアローンデスクトップアプリがmacOS・Windows・Linuxの全主要プラットフォーム向けに正式リリース(GA)されたと発表した。テクニカルプレビュー期間を経て一般提供に移行したこのアプリは、「エージェント駆動開発のホーム」として位置づけられており、AIエージェントを活用した開発作業の中心的な拠点となることを目指している。複数リポジトリにまたがるエージェントセッションを並列実行できるマルチセッション対応が特徴で、従来のIDE拡張とは異なる独立したネイティブ環境を提供する。 テクニカルプレビューからGAへの主な追加機能 正式リリースにあたり、テクニカルプレビュー以降に3つの重要な機能が新たに追加された。 **Canvas(キャンバス)**は、ユーザーとエージェントが同一の作業計画を共有しながら操作できる双方向インターフェースだ。エージェントの進捗をリアルタイムで可視化し、必要に応じて途中で介入・操作できる。IssueやPRを起点としてエージェントセッションを開始し、その進行状況をCanvasから直接確認・コントロールできる点が大きな強みとなる。 **クラウドオートメーション(Cloud automations)**は、エージェントによる作業をクラウド上でスケジュール実行できる機能だ。定期的なタスクやバッチ処理をAIエージェントに委任し、ローカル環境を占有せずに非同期で実行させることが可能になる。 カスタマイズ性の強化として、使用するAIモデルの選択に対応したほか、MCPサーバーを経由した外部ツールとの統合もサポートされた。これにより、チーム固有のツールチェーンや社内システムとの連携をアプリから直接行えるようになる。 利用要件と組織向け設定 Copilot BusinessまたはCopilot Enterpriseプランを契約する組織・企業においては、アプリを利用する前に管理者がポリシー設定でCopilot CLIを有効化する必要がある。アプリはターミナルおよびブラウザ上での検証機能も内蔵しており、Pull Requestの作成時にはチームの既存のCI/CDチェックやマージ要件にも対応している。エージェントが生成したコードの品質確認をアプリ内で完結できる設計となっており、開発フロー全体をシームレスに管理できる環境を提供する。

June 18, 2026

GitHub ActionsにUbuntu 26.04とWindows 11 ARM64新ランナーイメージがパブリックプレビュー公開

概要 GitHub Actionsのホステッドランナーに、Ubuntu 26.04(x64・arm64)とWindows 11 ARM64(Visual Studio 2026搭載)の新しいランナーイメージが2026年6月11日よりパブリックプレビューとして追加された。ワークフロー定義に新しいラベルを指定するだけで利用できるため、最新OSへの対応状況を早期に確認したい開発チームはすぐに試せる状態となっている。 利用方法と対応イメージ 各イメージの runs-on ラベルは以下のとおり。Ubuntu 26.04はx64向けに ubuntu-26.04、arm64向けに ubuntu-26.04-arm を指定する。基本イメージはラージランナーユーザーも利用可能。Windows 11 ARM64はVisual Studio 2026ツールチェーンを搭載した windows-11-vs2026-arm ラベルで利用でき、既存の windows-11-arm イメージと並行して稼働する。これにより、既存パイプラインに干渉することなく段階的に新環境への移行や検証を進められる。 注意事項と今後の予定 プレビュー期間中はピーク時間帯にキューの遅延が生じる可能性がある点に注意が必要だ。また、Windows 11 ARM64については2026年9月初旬にプレビュー終了を予定しており、その時点で既存の windows-11-arm ラベルが新しいVS2026イメージへ移行する。既存のワークフローでこのラベルを使用している場合は、移行後の動作変更を事前に確認しておくことが推奨される。バグ報告やフィードバックはGitHubの runner-images リポジトリへ送ることができる。

June 16, 2026

MCP Dev Summit Mumbaiが開幕——AIエージェント相互運用標準「MCP」の実装とエンタープライズ展開を議論

概要 Agentic AI Foundation(AAIF)が主催するMCP Dev Summit Mumbaiが、2026年6月14〜15日の2日間にわたりインド・ムンバイで開催された。本サミットは「エージェントスタックが構築される場所」をコンセプトに掲げ、Model Context Protocol(MCP)を活用した次世代AIエージェント開発に取り組む開発者・エンジニアが一堂に会する場として企画された。MCPは、AIエージェントがモデル・ツール・データをセキュアかつ相互運用可能な形で連携させるためのオープンスタンダードであり、近年エンタープライズ領域でも注目度が急速に高まっている。 主要セッションと登壇者 セッションはプロトコルの技術的深掘り・実装ベストプラクティス・本番運用の課題という3本柱で構成された。Googleのデベロッパーアドボケイト Romin Irani 氏は「Agents @ Scale: The Platform」と題した講演を行い、大規模AIエージェント基盤の設計思想を共有した。AAIFの VP を務める Angie Jones 氏がオープニングリマークを担当し、オープンスタンダードとしてのMCPエコシステムの意義を強調した。Obot AIのShannon Williams氏はエンタープライズ規模でのMCP採用事例を紹介し、組織への展開における実践的な知見を提供した。またAAIFのCTO Manik Surtani氏は、AAIFの設立背景と今後のビジョンについて語り、MCPコミュニティ全体の方向性を示した。ダイヤモンドスポンサーにはAWSが参画しており、クラウド大手によるMCPエコシステムへのコミットメントも注目を集めている。 背景と今後の展望 MCPはAnthropicが2024年末に提唱したオープンプロトコルで、AIエージェントがさまざまなツールやデータソースを標準化された方法で呼び出せるようにする仕様として策定された。その後、業界横断的な標準化を推進するためにAAIFへの移管が進み、Google・AWS・Microsoft・Anthropicをはじめとする主要プレイヤーが参加する体制が整いつつある。ムンバイ開催は、アジア太平洋地域の開発者コミュニティへのリーチ拡大という戦略的な意図も見て取れる。本サミットで示された実装事例や運用ノウハウは、今後のMCPエコシステムの成熟を加速させる土台となりそうだ。

June 15, 2026

GitHub Agentic Workflowsがパブリックプレビューへ昇格、PAT不要でActionsにAIエージェント自動化を統合

概要 GitHubは2026年6月11日、Agentic Workflowsをパブリックプレビューへと昇格させた。これにより、IssueのトリアージやCI失敗の分析、ドキュメントの更新といった推論ベースの繰り返しタスクを、GitHub Actions内のAIコーディングエージェントで自動化できるようになった。ワークフローは自然言語のMarkdownファイルで定義でき、標準的なActions YAMLへ自動コンパイルされる仕組みのため、既存のランナーグループやポリシー制約をそのまま活用できる。 同時に、Agentic Workflowsで従来必要だった個人アクセストークン(PAT)が不要になったことも発表された。代わりにGitHub Actionsの組み込みGITHUB_TOKENが利用可能になり、長期存続するPATの管理コストとセキュリティリスクを削減できる。 技術的な詳細 Agentic Workflowsはサンドボックス環境内で実行され、セキュリティ面では多層的な保護機構が備わっている。Agent Workflow Firewall、safe outputsプロセス、threat detection jobが組み合わさっており、エージェントはデフォルトで読み取り専用の権限で動作する。GitHubコンテンツへのアクセス時にはintegrity filterルールが尊重される。 PAT不要化にあたっては、組織所有リポジトリで利用する際にいくつかの設定変更が必要となる。具体的には「Allow use of Copilot CLI billed to the organization」ポリシーを有効化し、ワークフローのMarkdownの権限セクションにcopilot-requests: writeを追加する。また、CLIを最新版へアップグレードするにはgh extension upgrade awコマンドを実行する。コスト管理の観点では、コストセンターの設定により複数組織への費用配分やワークフロー単位でのトークン使用量監視・上限設定も可能だ。 導入事例と利用可能なプラン すでに複数の企業が本機能を採用しており、Marks & Spencerは「何時間もかかっていた繰り返し作業が数分で自動完了できるようになった」と報告。CarvanaやHud.ioも事例として挙げられており、開発生産性の向上と信頼性確保の両立が評価されている。Agentic WorkflowsはCopilotのFreeからEnterpriseまで全プランで利用可能。公式のクイックスタートガイドやGitHubNextの事前構築済みワークフロー例も提供されており、導入の敷居は低い。

June 13, 2026

Next.js 16.2リリース:開発サーバー起動が約400%高速化、AIエージェント対応も強化

概要 VercelはNext.js 16.2を正式リリースした。本バージョンの最大の見どころは開発サーバー(next dev)の起動速度で、同一マシン・同一プロジェクトでの計測でNext.js 16.1比約87%短縮、前世代からは約400%の高速化を実現した。加えてServer Componentsのレンダリング速度が最大60%向上し、大規模アプリケーションの日常的な開発体験が大きく改善されている。AIエージェントによるコード生成支援に向けたツーリング、Turbopackの大幅強化も今回リリースの柱となっている。なお最低動作要件はNode.js 20.9以上、TypeScript 5.1以上に引き上げられた。 開発パフォーマンスの大幅改善 レンダリング高速化の核心は、Reactに取り込まれたServer Componentsペイロードのデシリアライズ処理の刷新にある。従来実装はJSON.parseのreviverコールバックを使用しており、パース中のすべてのキー・バリューペア処理でV8エンジン内のC++/JavaScript境界越えが発生し、引数なしreviverでさえ約4倍の速度低下をもたらしていた。Next.jsチームはReact本体へのコントリビューション(PR #35776)として、まず通常のJSON.parse()でパースしたのちに純粋なJavaScriptで再帰走査する2ステップ方式に切り替えた。実測ではServer Componentテーブル(1000アイテム)で26%、ネストしたSuspenseを持つServer Componentで33%、Payload CMSのホームページで34%、リッチテキストを含むPayload CMSページでは60%のサーバーレンダリング時間短縮が確認されている。 AIエージェント向けツーリングの強化 create-next-appで生成されるプロジェクトにAGENTS.mdファイルが標準搭載された。このファイルにはプロジェクト構造や慣習が記述されており、CopilotやCursorなどのAIコーディングエージェントがコンテキストを即座に把握できるようになる。あわせてバージョンに対応したドキュメントをMarkdown形式でバンドルし、ローカルエージェントが参照できる仕組みも整備された。さらにlogging.browserToTerminal設定でブラウザのエラーやconsole.logを開発ターミナルへ転送する機能がデフォルト有効になり、実験的CLIである@vercel/next-browserによるターミナルからのアプリ検査もサポートされている。 Turbopackの強化 Turbopackではサーバー向けFast Refreshが大幅に改善された。従来は変更したモジュールに関係するインポートチェーン全体を再ロードしていたが、変更モジュールのみを再ロードする方式に改めた結果、アプリリフレッシュで67〜100%、コンパイル時間で400〜900%の高速化が報告されている。機能面ではサブリソース整合性(SRI)のJavaScriptファイル対応、分割代入した動的インポートのツリーシェイキング、postcss.config.tsのサポートが追加された。200件超のバグ修正も含まれており、安定性も向上している。 デバッグ体験と新機能 デバッグ支援として複数の改善が加わった。開発中のターミナルにServer Functionの実行ログ(関数名・引数・実行時間・定義ファイル)が表示されるようになり、ハイドレーションミスマッチ発生時のエラーオーバーレイには+ Client / - Serverの凡例でサーバーとクライアントの差分が明示される。next dev --inspectに続きnext start --inspectでも本番サーバーへのNode.jsデバッガ接続が可能となった。ImageResponseは基本的な画像で2倍、複雑な画像では最大20倍の高速化を果たし、デフォルトフォントもNoto SansからGeist Sansに変更された。<Link>コンポーネントにはtransitionTypesプロパティが追加され、View Transitionsを使ったナビゲーションアニメーションを柔軟に制御できる。Adaptersは今回から安定版(stable)に昇格し、デプロイプラットフォームやカスタムビルド統合がNext.jsのビルドプロセスをカスタマイズできるようになった。実験的機能としてはunstable_catchError()によるコンポーネントレベルのエラーバウンダリ、unstable_retry()によるデータ再フェッチを伴う再試行、experimental.prefetchInliningによるプリフェッチリクエスト削減なども提供されている。

June 11, 2026

Node.js、年間メジャーリリースを年1回に削減——Node 27からすべてのバージョンがLTS対応へ

概要 Node.jsプロジェクトは、2026年10月より抜本的なリリースモデルの変更を実施すると発表した。従来の年2回のメジャーリリース体制から年1回に削減し、奇数・偶数バージョンによるLTS(長期サポート)の区別を廃止する。Node 27が新方式初のリリースとなり、以降のすべてのメジャーバージョンが最終的にLTSへ昇格する。Node 26(2026年4月リリース)は旧モデル最後のリリースとなった。 変更の主要な動機は、ボランティア主体のメンテナーが複数のリリースラインへのバックポート作業に苦しんでいたことと、奇数バージョン(従来の「非LTS」リリース)の実採用率が著しく低かったことにある。プロジェクトメンバーのJames Snellは「このモデルは10年前に設計されたもの。エコシステムとプロジェクトのニーズが変化したかどうかを定期的に見直すのは重要なことだ」と述べ、今回の刷新を正当化した。 新しいリリースサイクルの詳細 新モデルでは、メジャーバージョンは毎年4月にリリースされ、同年10月にLTSへ昇格する。各バージョンのライフサイクルは4段階に整理される。 Alpha(6ヶ月): 27.0.0-alpha.1 のような事前リリース形式で公開 Current(6ヶ月): 安定版として一般提供 LTS(30ヶ月): 長期サポート期間 End of Life: サポート終了 合計サポート期間は約36ヶ月となり、既存モデルと大きく変わらない。また、バージョン番号はカレンダー年と連動するよう設計され、Node 27は2027年、Node 28は2028年にリリースされる予定だ。 新設されるAlphaチャネルは、ライブラリ著者が破壊的変更を早期に把握し、CI/CDパイプラインに組み込んでテストするための6ヶ月間の猶予期間として機能する。LTSリリースのみをテスト対象としていたライブラリは、Alphaチャネルを見落とすとユーザーへの影響が出る前にバグを検出する機会を失うリスクがある。 コミュニティの反応と影響 既存のLTSユーザーにとっては「バージョン番号以外の変化はほぼない」とプロジェクト側は説明している。しかしコミュニティ内には懸念の声もあり、Kevin Lentinは「2年ごとにしか新LTSが出ないなら、機能を待つ苦しみがひどくなる」と訴えた。エンタープライズユーザーが長いサポート窓口を好む一方、最新機能へのアクセスを求めるチームとの間で一定の緊張が生じている。 ライブラリ保守者に対しては、AlphaリリースをCI/CDに即時組み込むことが強く推奨されており、新しいリリースサイクルへの対応が求められる。エコシステム全体のアップグレードサイクルが簡素化されることで、長期的にはコミュニティの運用負荷が下がると期待されている。

June 11, 2026