OSS

CLI v4の主要な変更点 shadcn/uiは3月のアップデートでCLI v4をリリースし、開発者体験の大幅な改善を図った。最大の特徴は、CLIが単なるインストーラーからプロジェクト状態を管理する高度なツールへと進化した点にある。新たに追加された--dry-runフラグはディスクへの書き込みなしにコンポーネント追加のシミュレーションを行い、--diffフラグはレジストリの更新とローカルの変更を比較表示する。さらに--viewフラグでペイロードを事前に確認できるため、プロジェクトへの変更を透明性高く管理できるようになった。 フレームワーク対応も大きく拡張され、Next.js、Vite、TanStack Start、React Router、Astro、Laravelの6つのフレームワークに対してファーストクラスのテンプレートが提供される。--baseフラグによりRadixとBase UIのプリミティブを選択できるほか、shadcn docs [component]コマンドでレジストリからドキュメントやコードスニペットを直接取得することも可能になった。 AIエージェント向けスキル機能 今回のアップデートで注目すべき新機能が「shadcn/skills」だ。これはv0、Cursor、Claudeといったコーディングエージェントに対して、shadcn/ui固有のコンテキストを提供する仕組みである。AIエージェントがRadixとBase UIのプリミティブの違いや、レジストリのワークフロー、CLIフラグの使い方を正確に理解できるようになり、ハルシネーションや誤操作が軽減される。例えば「新しいViteモノレポを作成して」や「Tailarkからヒーローセクションを探して」といったプロンプトを信頼性高く実行できるようになるという。 デザインシステムプリセット デザインシステムプリセットは、カラー、テーマ、フォント、ボーダー半径、アイコンなどの設定をポータブルな文字列としてバンドルする機能だ。ワークフローは3ステップで構成される。まずビジュアルビルダー「shadcn/create」でプレビューしながらプリセットを生成し、次にnpx shadcn@latest init --preset [CODE]でプロジェクトを初期化する。既存のプロジェクトに対してinitを再実行すれば、プロジェクト全体の設定が自動的に切り替わる仕組みだ。 このアップデートにより、shadcn/uiは「最もAI対応が進んだデザインシステム」としてのポジションを強化しており、デザインコンセプトからプロダクション品質のインターフェースまでの距離を縮めることを目指している。

昇格の概要 CNCF（Cloud Native Computing Foundation）の技術監視委員会（TOC）は2026年3月24日、KubernetesネイティブのCI/CDフレームワーク「Tekton」をIncubatingプロジェクトとして正式に承認した。TektonはCD Foundation（CDF）で既に卒業プロジェクトとしての地位を確立しており、CNCFにはSandboxを経ずに直接Incubatingレベルで受け入れられた。これはプロジェクトの成熟度、安定性、そしてクラウドネイティブエコシステムにおける重要性が認められた結果である。TOCスポンサーのChad Beaudin氏は「TektonはKubernetesネイティブなデリバリーのためのコアインフラとしての実力を証明した。Incubatingへの移行は、強力なマルチベンダーガバナンスとCNCFプロジェクトとの深い連携を反映している」と評価している。 Tektonのアーキテクチャと主要コンポーネント TektonはKubernetes上で動作するCI/CDフレームワークであり、Steps、Tasks、Pipelinesという構成可能なプリミティブを通じて、マルチクラウドおよびオンプレミス環境でのビルド、テスト、デプロイを実現する。プロジェクトは複数のコンポーネントで構成されており、CI/CDワークフローの中核を担う「Pipelines」（コアはv1.0安定版に到達済み）、Gitプッシュやプルリクエストなどのイベントに基づいてパイプラインを起動する「Triggers」、コマンドラインインターフェースの「CLI」、Webベースの管理UIである「Dashboard」、そしてアーティファクトの署名・証明を行うサプライチェーンセキュリティツール「Chains」がある。 コミュニティの成長と採用実績 Tektonのコミュニティは着実に成長を遂げており、GitHub上で11,000以上のスター、5,000以上のプルリクエスト、2,500以上のIssue、そして600人以上のコントリビューターを擁する。企業採用も広がっており、Red Hat OpenShift PipelinesやIBM Cloud Continuous Deliveryといった商用製品の基盤として活用されているほか、Puppet社やFord Motor Companyなどの大手企業でも導入されている。さらに、CNCFプロジェクトであるShipwrightやRed Hatが主導するKonfluxといったプロジェクトの基盤としても機能しており、エコシステム内での存在感を高めている。Argo CD（GitOps）、SPIFFE/SPIRE（アイデンティティ管理）、Sigstore（署名・検証）との統合も進んでいる。 今後のロードマップ Tektonの今後の開発では、サプライチェーンセキュリティの強化が重要な柱となる。SLSA Level 3をデフォルトで達成することを目指すほか、共有ストレージなしでタスク間のデータを安全に受け渡す「Trusted Artifacts」機能の開発が進められている。また、リモートのTask/Pipeline参照の構文改善、Kueueとの統合による高度なスケジューリング、長期的な履歴管理とクエリのためのResults APIの安定化、Artifact Hubを通じたCatalogの進化、そしてGitベースのワークフローを実現する「Pipelines as Code」の継続的な開発が予定されている。TOCスポンサーのJeremy Rickard氏は「Tektonのコンポーザブルな設計と幅広い採用は、クラウドネイティブワークフロー環境において重要な位置を占めている」と述べており、Incubating昇格によりエンタープライズ採用のさらなる加速が期待される。

概要 Googleは2026年3月、Kubernetes上でマルチプレイヤーゲームの専用サーバーをオーケストレーション・スケーリングするオープンソースプラットフォーム「Agones」を、Cloud Native Computing Foundation（CNCF）にSandboxレベルのプロジェクトとして寄贈した。これにより、Agonesはベンダー中立なコミュニティ主導のガバナンス体制へと移行し、Google以外のクラウド事業者やゲームスタジオからの参加拡大が期待される。 Agonesは2017年にGoogleとUbisoftの共同開発で誕生し、現在は250人以上のコントリビューターによって支えられている。プロジェクト創設者でリードメンテナーのMark Mandel氏は「マルチプレイヤーゲームサーバーのホスティングはかつて独自のプロプライエタリシステムに完全に依存していたが、オープンソースがゲームを変えた」と語り、CNCF移管の意義を強調した。 技術的な特徴 Agonesの最大の強みは、Kubernetesを拡張してゲームサーバーのライフサイクル管理を標準化する点にある。PC、コンソール、モバイルといったプラットフォームを問わず、一度ビルドしたサーバーバイナリを修正することなく、オンプレミスを含む主要なクラウドプロバイダーへシームレスにデプロイできる「Build Once, Deploy Everywhere」のアプローチを採用している。UbisoftのThomas Lacroix氏も、このクラウドアグノスティックな設計により、ゲームサーバーバイナリを変更せずにあらゆるクラウドで一貫して専用サーバーを稼働できる点を評価している。 また、単一のサーバープロセスで複数のゲームセッションを安全にホストする機能や、再利用可能なゲームサーバーパターンによる効率化、共通APIによるサーバー管理の簡素化といった機能を備えており、大規模なマルチプレイヤーゲームの運用コスト削減に貢献する。 今後の展望 CNCFへの移管は、マルチプレイヤーゲームインフラのオープンスタンダード化を推進する重要な一歩となる。これまでゲーム業界ではプロプライエタリなインフラが主流だったが、Agonesがベンダー中立な基盤として広く採用されることで、業界全体のインフラ標準化が加速する可能性がある。2026年のKubeCon + CloudNativeCon Europe（アムステルダム）では、Mark Mandel氏とUbisoftのJean-François Hubert氏による基調講演が予定されており、Ubisoftにおけるオーケストレーション戦略が紹介される見込みだ。

概要 GitHubは2026年3月25日、Copilotの利用状況メトリクスを更新し、Copilot Coding Agent（CCA）のアクティブユーザーを識別・追跡できる機能を追加した。これにより、エンタープライズおよび組織の管理者は、IDE内でのCopilotエージェントモードの利用と、CCAによる自律的なコーディング作業を明確に区別して把握できるようになった。日次および28日間の利用レポートでCCAのアクティブユーザー数を確認でき、チームがIDEの外でどのようにCopilotを活用しているかをデータに基づいて理解できる。 技術的な詳細 CCAの利用状況はAPIレスポンス内のused_copilot_coding_agentフィールドとして提供される（APIバージョン2026-03-10）。従来からあるIDEエージェントモードのused_agentフィールドとは別に管理されるため、2つの異なるエージェント機能の利用状況を個別に分析できる。CCAのアクティビティとしてカウントされるのは、Copilotにissueをアサインした場合と、プルリクエストのコメントで@copilotをタグ付けした場合の2つのアクションだ。 管理者にとっての意義 今回の更新により、組織の管理者はCopilotの導入効果をより詳細に評価できるようになった。IDEでのコード補完やチャットといった従来の利用に加え、CCAによる自律的な計画・コーディングの利用パターンを把握することで、チーム全体のAI活用状況を包括的にモニタリングできる。これは、Copilotへの投資対効果を測定し、組織内での最適な活用方針を策定するうえで重要なデータとなる。

概要 Microsoftは2026年3月25日、Visual Studio Code 1.113を正式リリースした。週次Stableリリース体制への移行後、本格的な機能強化を含むリリースとして注目される。今回のアップデートでは、AIエージェント関連の機能が大幅に拡充されたほか、チャット体験の改善、エディタのブラウザタブ管理機能、新しいデフォルトテーマの導入など、幅広い領域で改良が加えられている。 AIエージェント機能の強化 最も目を引く新機能の一つが「Thinking Effort」セレクターだ。Claude Sonnet 4.6やGPT-5.4など推論をサポートするモデルにおいて、モデルピッカーから思考量を「Low」「Medium」「High」の3段階で切り替えられるようになった。これにより、簡単な質問には素早い応答を、複雑な問題には深い推論をといった使い分けが可能になる。従来のgithub.copilot.chat.anthropic.thinking.effortおよびgithub.copilot.chat.responsesApiReasoningEffort設定は非推奨となった。 サブエージェントのネスト呼び出しも重要な追加機能だ。chat.subagents.allowInvocationsFromSubagents設定を有効にすることで、サブエージェントが別のサブエージェントを呼び出せるようになり、複雑なマルチステップワークフローの構築が可能になった。さらに、MCPサーバーをCopilot CLIやClaudeエージェントと共有できるようになり、ローカルエディタを超えたMCPサーバーの活用が広がった。 チャット体験とセッション管理の改善 チャットカスタマイゼーションエディタがプレビューとして導入され、カスタムインストラクション、プロンプトファイル、カスタムエージェント、スキルなどを一元的に管理できるインターフェースが提供された。コードエディタの埋め込みやAI支援によるコンテンツ生成機能も備えている。 セッション管理面では、Copilot CLIやClaudeエージェントのセッションをフォークする機能が追加された。github.copilot.chat.cli.forkSessions.enabled設定で有効化でき、元のコンテキストを失うことなく異なる思考の方向性を探索できる。また、エージェントデバッグログパネルがCopilot CLIやClaudeエージェントのセッションにも対応し、デバッグが容易になった。 エディタとUIの改善 エディタ体験では、統合ブラウザでの自己署名証明書の一時的な信頼機能が追加された。開発時に自己署名証明書を使用する場面で、1週間有効な一時的信頼を付与でき、必要に応じて失効させることも可能だ。ブラウザタブ管理も強化され、⇧⌘A（Windows/LinuxではCtrl+Shift+A）でのクイックオープンや、タイトルバーへのグローブアイコン表示、全タブの一括クローズなどが利用できるようになった。 デフォルトテーマも刷新され、「VS Code Light」と「VS Code Dark」が従来の「Modern」テーマに代わる新しいデフォルトとして導入された。新規インストールではOSテーマとの同期がこの新テーマに自動設定される。なお、v1.110で非推奨となったEdit Modeは完全に廃止され、v1.125まではchat.editMode.hidden設定による再有効化が可能だが、その後は完全に削除される予定だ。

GitHub Enterprise Server 3.20の主な新機能 GitHub Enterprise Server（GHES）3.20が2026年3月17日に一般提供（GA）を開始した。今回のリリースでは、デプロイの効率性、監視機能、コードセキュリティ、ポリシー管理の各領域で大幅な強化が行われている。 注目すべき新機能として、まずイミュータブルリリースが導入された。GitHubリリースに不変性を付与できるようになり、公開後のリリースアセットの追加・変更・削除をロックし、リリースタグの移動や削除も防止する。これにより、サプライチェーン攻撃から配布アーティファクトを保護できる。また、以前パブリックプレビューだったバックアップサービスがGAとなった。GHES内蔵のマネージドサービスとして、従来のbackup-utilsに代わるバックアップ手段を提供する。なお、backup-utilsはバージョン3.22で廃止予定となっている。 プルリクエストのマージ体験も刷新され、ステータスチェックがステータス別にグループ化（失敗チェックが先頭表示）され、自然順ソートで整理されるようになった。高可用性構成では、プライマリデータノードからCPU集約型タスクをオフロードするための追加ノードをデータセンターに配置できるようになり（パブリックプレビュー）、水平スケーリングが可能となった。さらに、エンタープライズオーナーがエンタープライズチームを作成・管理し、組織横断のガバナンスを簡素化できる機能も追加されている。 Dependabotによるnpmマルウェア検出 同日、Dependabotにnpm依存パッケージのマルウェア検出機能が追加された。有効化すると、DependabotがnpmパッケージをGitHub Advisory Databaseのマルウェアアドバイザリと照合し、既知の悪意あるバージョンへの依存を検出してアラートを発行する。 この機能はオプトイン方式で、リポジトリ・組織・エンタープライズのセキュリティ設定から有効化できる。マルウェアアラートはCVEベースの脆弱性アラートとは別カテゴリとして表示され、トリアージの効率化が図られている。2022年にパブリック・プライベートパッケージの名前衝突による誤検知問題で一度停止されていたが、オプトイン制御やマルウェアバージョンのみのデフォルトアラート、CVEアラートとの明確な分離といった再設計を経て復活した。今後はOpenSSF Malware Streamsプロジェクトとの統合を通じ、npm以外のエコシステムへの対応拡大も予定されている。 CodeQL 2.24.3：Java 26サポートと解析精度の向上 2026年3月10日にリリースされたCodeQL 2.24.3では、Java 26のサポートが追加された。Java解析においてMaven POMファイルからJavaバージョンを自動選択する仕組みが導入され、可能な場合はすべてのMavenプロジェクトでJava 17以上を使用してビルド互換性を向上させる。GHES 3.20自体もCodeQLの強化を多数含んでおり、C/C++リポジトリのビルドなしスキャン（build-mode none）のGA化、全サポート言語でのインクリメンタル解析、Swift 6.2/6.2.1やKotlin 2.2.0x/2.2.2xへの対応などが盛り込まれている。 その他の言語別改善としては、JavaScript/TypeScriptでmobx-reactおよびmobx-react-liteのobserverラップReactコンポーネントのサポート、PythonでAntiSSRFライブラリによるSSRFサニタイゼーションバリアの追加、isSafe(x) == trueやisSafe(x) != falseといったガード条件の自動処理が含まれる。 Actions Runner Controller 0.14.0：マルチラベル対応とオートスケーリング安全性の強化 2026年3月19日にリリースされたActions Runner Controller（ARC）0.14.0では、ランナースケールセットへのマルチラベルサポートが実現した。従来は1スケールセットにつき1ラベルしか設定できず、OS・ハードウェア・ネットワーク構成の組み合わせごとに別のスケールセットが必要だったが、複数ラベルを1つのスケールセットに定義しruns-on宣言で組み合わせて指定できるようになった。 オートスケーリングの安全性も向上し、ランナーが終了コード7で終了した場合にコントローラーがそのランナーセットのオートスケーリングを停止する仕組みが導入された。これにより、新しい構成のロールアウト中に古いランナーがプロビジョニングされるリスクが軽減される。リスナーPodにはデフォルトでkubernetes.io/os: linuxのnodeSelectorが追加され、混合OSクラスターでのWindows Nodeへの誤スケジューリングも防止される。また、actions/scalesetライブラリが唯一のAPIクライアントとして採用され、内部アーキテクチャが整理された。

概要 PHPプロジェクトは、長年にわたって使用されてきた独自の二重ライセンス構造を廃止し、広く認知されたBSD 3条項ライセンス（Modified BSD License）に統一するRFC（Request for Comments）の投票を行っている。Ben Ramseyが主導するこの提案は、2026年4月4日まで投票が続けられており、現時点で賛成49票、反対0票、棄権2票と圧倒的な支持を集めている。採択には3分の2以上の賛成が必要だが、事実上可決は確実な情勢だ。 現行ライセンスの問題点 PHPは現在、コードベースの大部分をカバーするPHP License v3.01と、Zend/ディレクトリに適用されるZend Engine License v2.00という2つの独自ライセンスを使用している。この構造は2006年から続いているが、いくつかの深刻な問題を抱えていた。PHP License v3.01は2020年にOSIのレガシー承認プロセスを通じて承認されたものの、標準的な審査ではなく歴史的使用実績に基づく承認であった。Zend Engine License v2.00に至ってはOSI承認すら存在しない。さらに両ライセンスはGPLと互換性がなく、商用採用の障壁となっていた。Debianがこのライセンス下のPHP拡張機能の配布を拒否する事例も複数発生しており、ディストリビューターやコントリビューターに混乱をもたらしてきた。 なぜBSD 3条項ライセンスなのか RFCの分析によると、現行の両ライセンスから条件4・5・6（PHP GroupやPerforce固有の条項）を除去すると、残る条件1〜3はBSD 3条項ライセンスと同一になる。つまり、ユーザーやコントリビューターの権利を一切変更することなく、OSI承認済みかつGPL互換の標準ライセンスに移行できるという理論的根拠がある。FSF（Free Software Foundation）もBSD 3条項ライセンスをGPL互換の自由ソフトウェアライセンスとして認定しており、これにより他のOSSプロジェクトとの親和性が大幅に向上する。 歴史的経緯 PHPのライセンスの複雑さは、プロジェクトの長い歴史に根差している。PHP 1〜2はGPLv2でライセンスされていたが、PHP 3でGPLv2とApacheスタイルのカスタムライセンスの二重ライセンスに移行。PHP 4以降は、Richard Stallmanとの論争を経て独自のPHP Licenseに切り替えられた。Zend Engineには、共同創設者のAndi Gutmansが「Zend EngineはPHP以外の製品でも使用できるように設計された」と説明したように、スタンドアロンでの商用利用の余地を残すため別個のライセンスが設けられた。しかし25年の歳月を経て「両者は分離できないほど密接に絡み合っている」状態となり、別ライセンスの意義は失われていた。 合意形成と今後の影響 ライセンス変更にあたっては、PHP Groupの全メンバー（Rasmus Lerdorf、Andi Gutmans、Zeev Suraskiら10名）の承認と、Zend Licenseの権利を持つPerforce Software社からの法的な同意書が取得済みである。実装はphp-srcおよびweb-phpのプルリクエストとして既に準備されており、LICENSEファイルの置き換え、ソースファイルヘッダーの更新、ウェブサイトドキュメントの修正が含まれる。既存のPHP License v3.01で公開されている拡張機能は、アップグレード条項に基づき任意でBSD 3条項ライセンスへ移行可能だ。なお、PHPマニュアルはCreative Commons Attribution 3.0のまま変更されない。四半世紀にわたるライセンスの混乱が解消されることで、PHPエコシステム全体の法的明確性と他プロジェクトとの互換性が大きく改善されることが期待される。