OSS

概要 Dropboxのエンジニアチームは、GitHubと連携してGitのデルタ圧縮の最適化に取り組み、バックエンドモノレポのサイズを87GBから20GBへ約77%削減することに成功した。これによりリポジトリのクローン時間は1時間以上から15分未満へと75%短縮され、CI/CDパイプラインのパフォーマンスと開発者のオンボーディング体験が大幅に改善された。 同社のバックエンドモノレポはバックエンドサービスや共有ライブラリの統合拠点として機能していたが、規模の拡大に伴いクローン操作に1時間以上かかるようになり、CI/CDパイプラインの繰り返しフェッチによってビルドオーバーヘッドも増大していた。さらに、リポジトリホスティングの上限に近づくリスクも浮上していた。 根本原因と技術的な詳細 問題の根本原因は、大容量バイナリの誤コミットや通常の開発活動量ではなく、GitのデルタCOMPRESSIONが大規模リポジトリで非効率なpackfileを生成していた点にあった。DropboxのシニアソフトウェアエンジニアであるIshan Mishraは「実際の開発活動量から想定される成長ペースとは一致しなかった」と説明しており、問題は「何が保存されているか」ではなく「データがどのように保存されているか」にあったという。Shailesh Mishraも「ツールの前提がスケールしたリポジトリ構造と衝突した」と表現している。 対策として採用されたのは以下のアプローチだ。 再パッキング戦略の最適化: packfileの生成方式を見直し、デルタ圧縮の効率を改善 デルタウィンドウと深度の調整: Gitの圧縮パラメーターをリポジトリ規模に合わせてチューニング GitHubとのサーバーサイドパッキング調整: ホスティング側でのパック処理をDropboxの要件に合わせて最適化 ミラー環境での段階的な検証: 本番ロールアウト前にミラーリポジトリでの安全な検証を実施 改善結果と開発者への影響 この取り組みにより達成された改善は以下の通りだ。 指標 改善前 改善後 改善率 リポジトリサイズ 87GB 20GB 77%削減 クローン時間 60分以上 15分未満 75%短縮 CI/CDパイプライン 低速 データ転送量削減により高速化 — 開発者オンボーディング 時間がかかる 待ち時間を短縮 — この事例はバージョン管理システムをプロダクションインフラとして扱う重要性を示している。ストレージ効率がエンジニアリング速度に直結することを改めて示した例であり、ツールの最適化・組織横断的な協力・慎重な検証の組み合わせが大規模モノレポ運用における解決策となり得ることを証明した。

概要 GitHubは2026年4月24日、GitHub Appインストールトークンの新しいフォーマットへの移行を発表した。4月27日より段階的に適用が開始されており、「ステートレストークンフォーマット」の導入によってトークン発行のパフォーマンスと信頼性の向上が図られる。トークンのプレフィックス ghs_ は変更されないが、フォーマット全体は ghs_APPID_JWT 形式に移行し、トークン長が含まれるデータ量に応じて変動する約520文字に延長される。既存のトークンは有効期限まで引き続き使用可能だ。 影響範囲と展開スケジュール 今回の変更はGitHub Enterprise CloudおよびData Residency環境が対象で、GitHub Enterprise Serverへの影響はない。適用対象はサーバー間トークン（server-to-server tokens）とGitHub Actionsの GITHUB_TOKEN で、ユーザー間トークン（user-to-server tokens）については後日対応が予定されている。 展開は2段階で進められる。まず4月27日から5月中旬にかけてGitHub Actionsの GITHUB_TOKEN およびDependabotなどの主要な統合に対して新フォーマットが適用される。続いて5月中旬から6月下旬にかけて全GitHub Appインストールトークンへ拡大され、この期間にはブラウンアウト（一時的な旧形式の無効化）期間も実施される予定だ。 開発者が必要な対応 GitHubはトークンを「不透明な文字列（opaque string）」として扱うことを推奨しており、トークンの内部構造や長さに依存した実装は避けるべきとしている。具体的な対応として、ghs_[A-Za-z0-9]{36} のようなトークン長を固定した検証用正規表現を削除し、データベースのカラムサイズを最低520文字に対応させることが求められる。トークンの形式を検証するコードやトークン長を前提とした処理が存在する場合は、移行期間中に修正を完了させる必要がある。

概要 Intelは2026年4月、同社のオープンソース推進活動の象徴的な存在だった「Open Ecosystem Community and Evangelism」イニシアティブを終了し、関連するGitHubリポジトリをアーカイブした。このリポジトリにはIntelのOSSエバンジェリストたちが20年以上にわたって積み上げてきた活動記録や支援ドキュメントが含まれており、同社のオープンソースへの関与が大幅に縮小していることを改めて示した。最後に掲載されていたエバンジェリストはKatherine Druckmanで、彼女は2025年7月にIntelを離れていた。 アーカイブされた主なプロジェクト 今回アーカイブされたのはエバンジェリズムリポジトリだけではない。Intelは同時期に以下のプロジェクトも廃止・アーカイブしている。 Predictive Assets Maintenance — エンドツーエンドのAIソリューション High Density Scalable Load Balancer — DPDKベースの高密度スケーラブルロードバランサー Double Batched FFT Library — Intel GPU対応の高速フーリエ変換ライブラリ Intel Edge AI Performance Evaluation Toolkit — エッジAI評価ツールキット これらのプロジェクトの多くは、正式なアーカイブ前からすでに更新がほぼ停止していた状態だったが、公式に廃止されたことで今後のメンテナンスや機能追加への期待は完全に絶たれた。 背景：財務圧迫と企業再構築 この動きはIntelの広範な企業再構築の一環だ。同社は近年、収益率の低下や競合他社との激化する競争に直面しており、多年にわたるターンアラウンド計画を推進している。直接的な収益貢献が見えにくいオープンソース活動への投資は、こうした状況下で優先度が下がりやすい。2025年末頃からGitHub上のリポジトリのアーカイブが相次いでおり、今回の動きはその流れの延長線上にある。一方でIntelはElon MuskのTerafab AI chipイニシアティブへの参画など、AIチップ分野への集中的なリソース配分へと戦略をシフトしている。 OSSコミュニティへの影響 Intelは特にLinuxエコシステムへの貢献を通じて、20年以上にわたりオープンソース界における重要なプレーヤーとして認知されてきた。Open Ecosystem Community/Evangelismプログラムはその活動を文書化・推進し、開発者がIntelプラットフォームでOSSを活用するための情報提供や支援を行ってきた。このプログラムの廃止は、Intelがそのオープンソースリーダーとしての地位を徐々に手放しつつあることを象徴しており、コミュニティからの支持を失うリスクも指摘されている。IntelのGPUドライバやカーネルパッチなど主要な技術貢献は引き続き行われているものの、エコシステム全体を支えるエバンジェリズム活動がなくなることで、特に中小の開発者や組織が受ける影響は小さくないと見られている。

概要 Perforce Softwareは2026年3月24日、Open Source Initiative（OSI）およびEclipse Foundationと共同で「2026年版オープンソース実態調査（2026 State of Open Source Report）」を発表した。あらゆる規模・業界のOSS利用組織を対象とした本調査では、オープンソースソフトウェア（OSS）の採用動機として「ベンダーロックインの回避」が全体の55%に上り、前年比68%増という急激な伸びを記録した。特に欧州・英国ではEU規制の強化やデータ主権への意識の高まりを背景に63%が同項目を挙げており、北米の51%を大きく上回っている。Perforce OpenLogicのPrincipal Product ManagerであるMatthew Weier O’Phinney氏は「デジタル自律性は欧州組織にとって戦略的な優先事項となっており、ポータビリティを重視するベンダーがデジタル主権の実現に欠かせないパートナーになる」と述べた。 メンテナンス負荷とセキュリティの課題 調査では、OSSの本番環境への浸透に伴う運用上の課題も浮き彫りになった。従業員5,000人以上の大企業では60%がエンジニアの工数の50%以上をメンテナンスやバグ修正に充てており、新機能開発に割けるリソースが慢性的に不足している。Javaを採用するエンタープライズチームではさらに深刻で、約3分の1がメンテナンスに75〜90%の時間を費やしている実態が明らかになった。 セキュリティ面でも懸念が大きい。全体の20%がCVE（共通脆弱性識別子）への対応プロセスを正式に定めておらず、大企業の39%は内部SLAに沿った脆弱性対応ができていない。コンプライアンス監査に失敗した組織はサポート終了（EOL）ソフトウェアを使い続けているケースが多く、Tomcat・Spring Boot・Spring Frameworkの旧バージョンでは現行バージョンの2倍の監査失敗率が確認された。 規制対応と今後の展望 EU Cyber Resilience Actなど今後施行が予定される規制への備えも遅れており、対応計画を策定済みの組織はわずか16%にとどまる。OSIのInterim Executive DirectorであるDeb Bryant氏は「自分たちで技術の選択肢を持てる自由は、戦略的必要条件だ」と強調し、OSSが組織の技術的自立を支える基盤として位置付けられている点を訴えた。調査全体を通じて、OSSへの依存度と責任意識の両方が高まる中で、セキュリティ・コンプライアンス・長期サポートに対する期待がクリティカルインフラと同水準に引き上げられつつある現状が示されている。

概要 OpenAIは2026年4月22日、テキスト中の個人識別情報（PII）を自動的に検出・マスキングするオープンウェイトモデル「Privacy Filter」を発表した。Apache 2.0ライセンスのもとHugging FaceおよびGitHubで公開されており、企業がAIワークフローにおけるプライバシーリスクを軽減するための実用的なツールとして設計されている。背景には、ユーザーが氏名・住所・口座番号などの機密情報を含むテキストをそのままAIツールに貼り付けてしまうという、広く見られる問題意識がある。OpenAIは「より回復力のあるソフトウェアエコシステムをサポートする」という目標のもと本モデルを開発したと説明している。 技術仕様とパフォーマンス Privacy Filterはトークン分類アプローチを採用し、単一パスでテキストをラベル付けする設計になっている。総パラメータ数は15億（1.5B）だが、実稼働時に実際に使用されるのは約5,000万パラメータのみという効率的な構造を持つ。コンテキストウィンドウは最大128,000トークンに対応しており、長文書の処理にも適している。 対応するPIIカテゴリーは8種類で、名前・住所・メールアドレス・電話番号・URL・日付・口座番号・秘密情報を識別できる。公開ベンチマーク「PII-Masking-300k」では精度94.04%・再現率98.04%・F1スコア96%を達成し、改訂版データセットではF1スコアが97.43%に達するなど高い性能を示している。 ローカル実行によるプライバシー保護 本モデルの大きな特長のひとつが、オンデバイスでの完全ローカル実行だ。テキストデータを外部サーバーに送信することなくPIIの除去が可能なため、企業や組織が機密性の高いデータを扱う場合でも安心して利用できる。特に医療・金融・法務分野では規制上の要件としてデータの外部送信が制限されることが多く、ローカル処理対応は実務上の重要な優位点となる。 制限事項と活用上の注意 OpenAI自身も、本モデルには一定の限界があることを認めている。稀なPII識別子は見落とす可能性があり、文脈が限定的なテキストでは過剰なマスキングや検出漏れが発生することがある。そのため、法務・医療・金融分野での利用においては人的レビューを組み合わせることが推奨されている。あくまでもAIワークフローの第一層の防御として活用し、完全な代替手段として過信しないことが重要だ。

概要 Git 2.54が2026年4月20日に正式リリースされた。137名のコントリビューター（うち66名が新規）の貢献によるリリースで、目玉機能として設定ファイルでフックを定義できる「Configuration-Based Hooks」と、インタラクティブリベースより手軽にコミット履歴を書き換えられる実験的コマンド git history が追加された。また、Git 2.52で導入された幾何学的再パック（Geometric Repacking）がデフォルト化されるなど、パフォーマンスと利便性の両面で多くの改善が施されている。 Configuration-Based Hooks 従来のGitフックは .git/hooks/ 配下にシェルスクリプトを置く方式のため、複数リポジトリへの展開や共有が難しかった。Git 2.54で導入された Configuration-Based Hooks は、~/.gitconfig などの設定ファイルに直接フックを定義できる仕組みだ。 [hook "linter"] event = pre-commit command = ~/bin/linter --cpp20 この方式では同じイベントに複数のフックを登録でき、git hook list で一覧確認が可能。hook.<name>.enabled = false で個別に無効化もできるため、プロジェクトごとの設定上書きも柔軟に行える。グローバル設定として共有できる点は、チームやマシンをまたいだ開発環境の統一に役立つ。 実験的コマンド「git history」 git history はインタラクティブリベースほどの複雑さを要しないシンプルな履歴書き換えに特化した実験的コマンドだ。現在 reword と split の2つのモードが提供されている。 reword モードは指定コミットのメッセージを編集し、そのコミットから派生する全ブランチを自動更新する。ワーキングツリーやインデックスには一切影響しないため、安全に実行できる。split モードはコミットをインタラクティブに分割でき、取り込む変更をハンク単位で選択できる。ただし、マージコミットを含む履歴は対象外で、マージコンフリクトを引き起こす操作は拒否される点に注意が必要だ。 その他の主な改善点 Geometric Repacking のデフォルト化: Git 2.52で導入された幾何学的再パック戦略が今回からデフォルトになった。全体 repack の代わりに段階的統合を実施することで、大規模リポジトリのメンテナンスコストが軽減される。 HTTP 429 への自動対応: レート制限（HTTP 429）を受けた際に Retry-After ヘッダーを解釈して自動リトライする機能が追加された。大量のリモート操作を行う環境での信頼性が向上する。 その他にも、git add -p でのハンク選択状況の可視化、git log -L と pickaxe 検索（-S/-G）の組み合わせ対応、git rebase --trailer による全 rebase 済みコミットへのトレーラー自動付与、git blame --diff-algorithm による差分アルゴリズムの選択、git alias での ASCII 以外の文字サポートなど、日常的なワークフローを改善する多数の機能追加・修正が含まれている。内部的にはオブジェクトデータベース（ODB）がプラガブルバックエンド設計に移行しており、将来の拡張性が高まっている。

概要 MetaがRustで開発したオープンソースのPython型チェッカー兼言語サーバー「Pyrefly」の最新版v0.62.0が、2026年4月20日にリリースされた。Pyreflyはその名が示すとおり「飛ぶように速い」型チェックを特徴としており、Metaのインフラ環境（166コア・228GB RAM）での計測では毎秒185万行以上のコードを処理できる。これはInstagramの本番コードベース2,000万行を約30秒でチェックできる水準であり、大規模Pythonプロジェクトへの適用を強く意識した設計になっている。Python型準拠テストスイートの合格率は90%に達し、従来から広く使われているmypyやPyrightと並ぶ実用レベルの精度を確保している。ライセンスはMITで、pip install pyrefly 一発でインストールできる。 技術的なアーキテクチャ PyreflyはRustで実装されており、型チェックを三つのフェーズに分割することで大規模インクリメンタル処理と並列化を実現している。第一フェーズで各モジュールの公開シンボル（import * を含む）を確定し、第二フェーズで各モジュールをスコープ情報を持つ「バインディング」へ変換、第三フェーズで他モジュールへの依存を解決して最終的な型を導出する。再帰的な型依存は Type::Var プレースホルダーで扱い、強連結成分が大きいグラフにも対応している。 コードベースは pyrefly_util（汎用ユーティリティ）、pyrefly_types（型定義と操作）、pyrefly_graph（インデックスとキャッシング）、pyrefly_wasm（ブラウザ向けWASMサンドボックス）など複数のRustクレートで構成されている。型推論は関数パラメータを除くほぼすべての箇所（変数・戻り値など）で動作し、制御フロー分析によって静的型を動的に洗練する「フロー型」もサポートする。 IDE統合と最近のリリース動向 PyreflyはLSP（Language Server Protocol）に対応しており、VS Code・Neovim・Zedなどの主要エディタ向け拡張を提供している。オートコンプリート、コードナビゲーション、セマンティックハイライト、クラスのコンストラクタシグネチャとdocstringのホバー表示など、モダンなIDEに期待される機能を網羅している。ブラウザ上で試せるWASMサンドボックスも公式サイトで提供されている。 直近のリリース履歴を見ると、v0.59.0（3月31日）では153コミット・20名のコントリビューターによる大型リリースとして実世界プロジェクト向けの型チェック速度が約2倍に改善され、モジュール解決キャッシュの最適化によるCPU削減も達成した。v0.60.2（4月10日）では「未アノテートの辞書で指数的なメモリ使用」というバグを修正、その後v0.61.0・v0.61.1を経て今回のv0.62.0に至っている。開発は活発でGitHub IssuesやDiscordコミュニティ（隔週オフィスアワー開催）を通じた外部コントリビューションも受け付けている。 他ツールとの位置づけと今後の展望 Pyreflyの設計はMetaの既存型チェッカーであるPyre1のほか、PyrightやmypyなどPythonエコシステムの先行実装から着想を得ている。差別化ポイントはRustによる実装から生まれる純粋な処理速度と、モジュールレベルのインクリメンタル処理・並列化による大規模コードベースへのスケーラビリティにある。Python型準拠テスト90%合格という数字は精度面での実用性を裏付けており、速度と精度の両面でmypy・Pyrightの実質的な代替候補として位置づけられる。現時点ではベータ扱い（既知の問題あり）だが、Metaが自社の巨大Pythonコードベースで実際に運用していることが開発継続の強力な動機となっている。

概要 JavaScriptランタイムのBunは2026年4月20日、バージョン1.3.13を正式リリースした。今回のリリースは機能追加・パフォーマンス向上・メモリ最適化の三本柱で構成されており、特にテストランナーへの並列実行機能の追加、bun installのメモリ使用量の17倍削減、zlib-ng統合によるgzip圧縮の最大5.5倍高速化が目玉となっている。また1,316件のJavaScriptCoreエンジンのアップストリームコミットをマージするなど、エンジン層の大規模アップグレードも含まれている。 テストランナーの強化 テストランナーには4つの新フラグが追加された。--parallel[=N]は、テストファイルをN個のワーカープロセスへ分散して並列実行する機能で、アイドル状態のワーカーが最も忙しいキューからタスクを盗む「work stealing」方式でCPUを効率活用する。--shard=M/NはCI環境向けの機能で、テストスイート全体を複数のジョブへ分割して実行できる。Jest・Vitest・Playwrightと同じ構文を採用しており、ファイルはパスでソートしてラウンドロビン分散することで決定論的な実行を保証する。 --isolateフラグは各テストファイルを同一プロセス内の独立した環境で実行し、マイクロタスクのドレイン・ソケットのクローズ・タイマーのキャンセルを行うことでファイル間の状態汚染を防ぐ。--changedフラグはgitの変更検知とインポートグラフ解析を組み合わせ、変更の影響を受けるテストファイルのみを選択的に実行することで開発イテレーションを高速化する。 メモリ使用量の大幅削減 bun installのメモリ最適化では、パッケージのtarballをダウンロードと同時にディスクへストリーム書き込みする方式に変更した。従来はアーカイブ全体をメモリ上に展開していたが、今後は圧縮済みバイト列とlibarchiveの固定サイズバッファのみを保持するため、メモリ使用量が最大17倍削減される。 ソースマップについても、VLQ（可変長量）方式からビットパック形式への移行により1マッピングあたり約2.4バイトへ削減（従来は約20バイト）、実測ではTypeScriptコンパイラのデータで11.3MBから1.29MBへと最大8倍の削減を達成した。加えてmimallocをv2からv3へアップグレードし、libpasのscavengerサポート（Windows/Linux対応）を追加することでランタイムのメモリ使用量を約5%改善している。 パフォーマンス向上：gzip高速化とJavaScriptCoreアップグレード gzip圧縮ではNode.js 24+やChromiumが採用するzlib-ng 2.3.3を統合した。ベンチマークでは1MBデータのgzipSync（L1）で2.50倍、123KBデータのdeflate（L6）で5.48倍の高速化を記録している。配列反復処理も1.43倍に高速化された。 JavaScriptCoreエンジンには1,316件のアップストリームコミットをマージし、配列長設定のインラインキャッシュ化・toUpperCase()のJIT内在化・日付フォーマッタのキャッシュ・SIMD高速化したequalIgnoringASCIICaseなどの最適化が含まれている。 Web APIの拡充とバグ修正 Web API面では、Bun.serve()がRange: bytes=...ヘッダに対応し206 Partial Contentレスポンスを自動返信できるようになった。WebSocketはws+unix://およびwss+unix://スキームによるUnixソケット接続をサポートし、npmのwsパッケージとの互換性が向上した。暗号API面ではSHA3-224/256/384/512のcrypto.createHash()およびcrypto.subtle.digest()サポート、RFC 7748準拠のX25519鍵導出が追加された。 バグ修正では、Workerスレッド終了時のクラッシュ、socket.setTimeout()の誤動作、HTTP/2設定の不正広告、fs.watch()のデッドロック、ファイルディスクリプタリークなど複数の重要な問題が解消されている。

概要 GitHubは2026年4月20日、HTTPS接続における SHA-1ハッシュアルゴリズムの使用を段階的に廃止すると発表した。対象はgithub.com、GitHub Enterprise Cloud、データレジデンシー対応版で、ブラウザ、GitHub API、Git over HTTPSのすべてに影響する。なお、GitHub Enterprise Serverは今回の廃止対象には含まれない。 SHA-1は数十年前から使われてきたハッシュアルゴリズムだが、2017年にGoogleが実用的な衝突攻撃（SHAttered攻撃）を実証したことで安全性に重大な懸念が生じた。業界全体でSHA-2（SHA-256など）への移行が進んでおり、今回のGitHubの決定もその流れに沿ったものだ。 廃止スケジュールと影響範囲 廃止は2段階で進められる。まず2026年7月14日（UTC 00:00〜18:00）にブラウンアウトテストとしてSHA-1を一時的に無効化し、互換性の問題を事前に洗い出す機会を提供する。その後、2026年9月15日にGitHubおよびパートナーCDNにおいてSHA-1が完全に無効化される予定だ。 影響を受けるユーザーの種類と対応策は以下の通りとなっている。 ブラウザ利用者: 最新の主要ブラウザであれば既にSHA-2に対応しているため、ブラウザを最新バージョンに保つことで対応可能。https://github.dev にアクセスして互換性を事前確認できる APIを利用するソフトウェア・開発者: SHA-2対応の新しいフレームワークやライブラリへの移行が必要 Gitクライアント利用者: 最新版のGitと、OpenSSLなどのOSコンポーネントを最新に更新することが推奨される 今後の対応と注意点 7月のブラウンアウトは、9月の完全廃止前に自社システムやツールチェーンへの影響を確認するための重要な機会となる。特に古いCI/CD環境やレガシーなGitクライアントを使用している組織は、早めの検証と移行計画の策定が求められる。現代的なブラウザや最新のGitバージョンを使用している一般的な開発者への影響は限定的とみられるが、自動化スクリプトや独自ビルドのツールを利用している場合は注意が必要だ。

概要 Kubernetes v1.36が2026年4月22日に正式リリースされた。今回のリリースは80件のエンハンスメントを含む大型アップデートで、安定版（GA）昇格が18件、ベータ昇格が18件、新規アルファ機能が26件という構成となっている。コンテナセキュリティの強化、GPU・アクセラレータ管理の改善、オートスケーリングの柔軟性向上が主要テーマだ。 主要なGA（安定版）機能 User Namespaces in Pods がついにGA（安定版）に昇格した。v1.25でのアルファ導入から約4年を経ての安定化となる。この機能はコンテナ内のroot（UID 0）を非特権ホストユーザーにマッピングすることでセキュリティ隔離を実現するもので、Podスペックに hostUsers: false を指定するだけで有効化できる。 Mutating Admission Policies もGAに昇格した。CELベースのミューテーションを外部Webhookサーバーなしでkubernetes本体に統合でき、インフラオーバーヘッドと単一障害点の排除を実現する。 OCI VolumeSource のGA昇格も重要な変更だ。OCIイメージをボリュームとしてマウントできるようになり、モデルウェイトや設定ファイル、データセットをアプリケーションコンテナとは独立して配布できる。AIモデルのデプロイにおいて有用な機能となる。 このほかにも 外部ServiceAccountトークン署名（HSMやクラウドKMSへの署名委譲）、DRA向けKubeletPodResources API（GPUなどのリソースをgRPC経由でpod単位に照会）、SELinuxラベル変更の高速化（ファイル単位の再ラベリングからマウント時の一括適用へ）がGAに昇格している。 注目のベータ機能：HPA Scale to Zero HPA（Horizontal Pod Autoscaler）のゼロスケール対応 が待望のベータ昇格を果たし、デフォルト有効化された。2019年のv1.16でアルファ導入されてから実に7年越しの昇格となる。アイドル時にDeploymentのレプリカ数をゼロまでスケールダウンできるため、コスト削減に直結する機能だ。 また、DRAのパーティショナブルデバイスサポート（ベータ）により、NVIDIAのMIG（Multi-Instance GPU）のような分割可能なGPUをスケジューリング時に動的に分割できるようになった。従来の静的な事前設定から脱却し、より柔軟なGPUリソース管理が可能になる。 新規アルファ機能 26件の新規アルファ機能の中で特筆すべきものをいくつか挙げる。 Workload-aware Preemption は分散トレーニングなど、複数のPodが同時にリソースを必要とするワークロードを対象に、Podグループを単一エンティティとして扱うプリエンプション制御を実現する。一部のPodだけがプリエンプトされて処理が中断するような問題を防ぐ。 HPA External Metrics Fallback は、外部メトリクスソースが一時的に障害を起こした際にフォールバック値を使ってオートスケーリングを継続できるようにするものだ。 PVC Last-Used Tracking は status.lastUsedTime フィールドを追加して孤立した永続ストレージボリュームの特定を容易にする。 スケーラビリティ面では Server-side Sharding（クライアントが shardSelector パラメーターで特定データシャードにサブスクライブ）、Graceful Leader Transition（コントロールプレーンコンポーネントのプロセス再起動なしのリーダー移行）、Native Histogram Support（Prometheusネイティブヒストグラム対応）なども追加された。 廃止・削除と移行推奨事項 gitRepoボリュームプラグイン が完全削除された。v1.11から廃止されていたが、今回ついに削除となる。rootコード実行の可能性があるセキュリティ脆弱性が理由で、init containersや外部のgit-syncツールへの移行が推奨される。 IPVS mode in kube-proxy も削除対象となっている。 externalIPsフィールド（Service spec）がv1.36で廃止予定となった（完全削除はv1.43予定）。CVE-2020-8554に関連するMITM攻撃リスクが理由で、LoadBalancer ServicesやGateway APIへの移行が推奨される。 ...