OSS

概要 GitHub Copilot CLIは2026年4月7日、独自のモデルプロバイダーやローカルモデルの利用に対応したことを発表した。これまではGitHubのホストモデルルーティングに限定されていたが、今回のアップデートにより、ユーザーは環境変数を設定するだけで、OpenAI・Azure OpenAI・Anthropicなどのリモートサービスや、OllamaやvLLM、Foundry Localといったローカルモデルを接続して利用できるようになった。 オフラインモードとして COPILOT_OFFLINE=true を設定すると、GitHubのサーバーへの通信が遮断され、テレメトリも無効化される。このモードとローカルモデルを組み合わせることで、インターネット接続のないエアギャップ環境や厳格なセキュリティポリシーが求められる企業・政府機関などの開発環境でも、Copilot CLIを活用できるようになる。 技術的な詳細 カスタムモデルプロバイダーを使用する際には、GitHub認証は必須ではない。ただし、GitHubアカウントにサインインすることで、/delegate コマンドやGitHub Code Searchといった追加機能にもアクセスできる。対応するモデルの条件として、ツール呼び出し（function calling）とストリーミングのサポートが必要であり、最低128kトークンのコンテキストウィンドウを持つモデルが推奨される。 サブエージェント機能（explore・task・code-review）は、設定されたプロバイダー情報を自動的に継承する。なお、設定が無効な場合でもGitHubホストモデルへの自動フォールバックは行われず、エラーメッセージが表示される仕様となっている。セットアップ手順は copilot help providers コマンドで確認できる。 意義と展望 このBYOK（Bring Your Own Key）対応は、コンプライアンスやデータプライバシーの観点からGitHubの標準モデルを利用できなかった組織にとって大きな選択肢の拡大となる。特に、閉鎖的なネットワーク環境での開発を余儀なくされるケースでも、AI支援の恩恵を受けられるようになる点で意義深い。また、ローカルLLMの多様な選択肢を活用できるようになることで、コストやレイテンシの観点でも柔軟な運用が可能になる。

概要 米スタートアップArcee AIは、400Bパラメータのオープンウェイト推論モデル「Trinity Large Thinking」をApache 2.0ライセンスで公開した。CEO Mark McQuadeは「非中国企業がリリースしたオープンウェイトモデルとして史上最高性能」と主張している。同社は従業員わずか26名、トレーニング予算2000万ドルという極めて小規模なチームでこのモデルを開発しており、潤沢なリソースを持つ大手AIラボに少人数チームが真っ向から対抗できることを示す事例として業界の注目を集めている。 モデルはHugging Faceからウェイトをダウンロードして利用できるほか、Arcee APIを通じたクラウドホスト版（出力トークン100万件あたり$0.90）や、オンプレミスでのデプロイ・カスタムトレーニングにも対応している。 技術的な詳細 Trinity Large Thinkingは、短期的なコーディング性能よりも**長時間稼働するエージェントタスク（long-horizon agents）**に最適化されている点が特徴だ。マルチターンのツール呼び出しや、拡張ワークフローでのコンテキスト一貫性の維持、長期エージェントループでの安定したパフォーマンスを重視して設計されている。Arceeチームは「開発者が毎日24時間365日稼働させているエージェントで異常なほど優れたモデルを構築することに注力した」と説明している。 インフラ面では、事前学習にNVIDIA B300を2,048基、後処理学習にH100を1,152基使用。本番環境にはNVIDIA DynamoとBlackwell Ultra GPU、vLLMを組み合わせて運用している。ベンチマークでは、Kiloのエージェント特化評価「PinchBench」で2位を記録（1位はClaude Opus-4.6のみ）。OpenRouterにおける米国内オープンモデルの使用量でも首位を達成しており、ピーク時（2026年3月1日）には1日あたり806億トークン以上を処理したという。 普及の背景と今後の展開 同モデルが急速に普及した背景には、AnthropicがClaude Codeのサブスクリプション条件を変更し追加料金が必要になったことで、開発者がオープンソース代替を探し始めたタイミングがあったとされる。また、中国系AIモデルへのデータセキュリティ・地政学的リスクへの懸念から、自社インフラで運用・カスタマイズできる西側企業製オープンウェイトモデルへの需要が高まっていることも追い風となっている。 今後はTrinity Large Thinkingで確立したトレーニング手法を、Trinity-MiniやTrinity-Nanoといった小型モデルへディスティレーションで展開する計画だ。「まず大きなモデルで優れた手法を確立し、その後スタック下方へと流し込む」という段階的アプローチを採用しており、エンタープライズおよび開発者コミュニティへのさらなる普及拡大を目指している。

概要 Googleは、複数のAIエージェントを並列かつ分離した環境で管理するオーケストレーション基盤「Scion」を実験的なオープンソースプロジェクトとして公開した。Scionは「エージェントのハイパーバイザー」として機能し、ローカル環境やリモートVM、Kubernetesクラスタをまたいでエージェントグループを統制する。各エージェントには独自のコンテナ、Gitワークツリー、認証情報が割り当てられ、プロジェクトの異なる部分を干渉せずに並行して担当できる設計となっている。 アーキテクチャと技術的な詳細 Scionの特徴はルールをエージェントのコンテキストに埋め込むのではなく、インフラストラクチャ層で境界を強制する「分離優先」の設計思想にある。Googleはこのアプローチを「–yoloモード」と表現しており、エージェント自体の行動制約に頼らず、コンテナ化・Gitワークツリー・ネットワークポリシーによって隔離を実現する。 タスク管理では動的なタスクグラフを並列実行し、コーディング・監査・テストなど異なる役割を持つエージェントが協調して動作できる。エージェントのライフサイクルは柔軟で、長期稼働する専門エージェントと単一タスク専用のエフェメラルエージェントの両方をサポートする。コンテナランタイムはDocker・Podman・Appleコンテナ・Kubernetesからプロファイルで選択可能だ。 また、Gemini CLI・Claude Code・OpenCode・Codexなどの人気エージェントに接続するための「ハーネス」アダプタが提供されており、各ハーネスのサポート機能レベルは異なる。独自の用語体系として、プロジェクト単位を「grove」、中央コントロールプレーンを「hub」、hubが稼働する場所を「runtime broker」と定義している。 デモと今後の展望 Scionの能力を示すデモとして、エージェントグループが協力して計算パズルを解くゲーム「Relics of the Athenaeum」が同時に公開された。このデモでは、異なるハーネスを使用するエージェントが共有ワークスペースやダイレクトメッセージで連携しながら動作する様子を確認できる。Scionの公開は、AIシステムの複雑化にともない、マルチエージェントの協調フレームワークへの業界の関心が高まっていることを反映しており、専門化されたエージェントワークフローが本番環境で普及していく流れを加速させる可能性がある。

概要 Grafana Labsは2026年3月25日、深刻度CriticalのCVE-2026-27876とHighのCVE-2026-27880を修正したセキュリティアップデートをリリースした。対象となる修正済みバージョンはGrafana 11.6.14、12.1.10、12.2.8、12.3.6、12.4.2で、これらのいずれかへの速やかなアップグレードが強く推奨されている。Grafana Cloud、Amazon Managed Grafana、Azure Managed Grafanaについてはすでにパッチ適用済みとなっている。 CVE-2026-27876：SQL ExpressionsによるRCE（Critical / CVSS 9.1） CVE-2026-27876はGrafanaのSQL Expressions機能（sqlExpressionsフィーチャートグル）に存在する任意ファイル書き込みの脆弱性であり、最終的にリモートコード実行（RCE）へとエスカレートする可能性がある。攻撃者はSqlyzeドライバーの上書きやAWSデータソースの設定ファイルの細工といった複数の攻撃ベクトルを連鎖させることで、ホストへのSSHアクセスを取得できる。バグバウンティプログラム経由の責任ある開示によって発見された。 悪用には2つの条件が同時に満たされる必要がある。1つはGrafanaインスタンスでsqlExpressionsフィーチャートグルが有効化されていること、もう1つは攻撃者がViewer権限以上を持っていることだ。ネットワーク経由・認証あり・ユーザーインタラクション不要という攻撃特性のため、権限を持つ内部ユーザーや侵害されたアカウントからの悪用リスクが高い。影響を受けるバージョンはGrafana 11.6.0〜11.6.13、12.0.0〜12.4.1（各系列の最終パッチバージョン未満）である。 CVE-2026-27880：OpenFeature経由の認証なしDoS（High / CVSS 7.5） CVE-2026-27880はGrafanaのOpenFeatureフィーチャーフラグ検証エンドポイントに存在する認証バイパスの脆弱性で、Grafana Labsのセキュリティチームが内部で発見した。エンドポイントが認証を要求せず無制限のユーザー入力を受け付けるため、攻撃者が大量の巨大ペイロードを送信することでサーバーのメモリを急速に枯渇させ、アプリケーションをクラッシュさせて持続的なDoS状態を引き起こすことができる。影響を受けるのはGrafana 12.1.0以降である。 対応と緩和策 即時のアップグレードが困難な場合、CVE-2026-27876に対する暫定的な緩和策としてsqlExpressionsフィーチャートグルの無効化が有効である。加えて、GrafanaへのネットワークアクセスおよびViewer権限の付与を最小限に制限すること、ログ監視とネットワークアクティビティの継続的な監視が推奨される。現時点でEPSSスコアは0.00105と低く、CISAのKEVリストへの掲載もないが、CriticalのCVSSスコアを持つRCE脆弱性であることから、可能な限り早期のパッチ適用が不可欠だ。

概要 Linus Torvaldsは2026年4月6日、Linux 7.0の最終リリース候補版となる7.0-rc7を公開した。これが最後のリリース候補版となる見込みで、特段の問題がなければ翌週末に安定版7.0が正式リリースされる。Torvaldsのアナウンスでは「イースターバニーが見ている」とユーモアを交えつつ、ユーザーにテストスイートの実行を呼びかけている。 パッチセットのサイズは通常のrcよりも大きめだが、Torvaldsはスケジュールを遅延させるほどの懸念はないとコメントしており、リリースは予定通り進行している。 主な変更内容 今回のrc7に含まれる変更の約50%はドライバー更新が占めており、GPU、ネットワーキング、USBなど幅広いドライバーが対象となっている。注目すべき点として、AIエージェント向けのドキュメント改善とWi-Fiドライバーのパフォーマンス修正が含まれる。AIツールがLinuxカーネルに対してより高品質なセキュリティバグレポートを送信できるようにするためのドキュメント整備は、AIを活用したコード解析が広がる昨今の開発現場の変化を反映したものといえる。 セキュリティ・安定性面では、メモリ安全性の問題（use-after-freeバグ、境界外読み取り）の修正、ネットワーク処理コードにおける潜在的な情報漏洩の解消、ファイルシステムの改善、暗号化機能の強化が盛り込まれている。 今後の見通し Linux 7.0には、Intel Nova LakeやAMD Zen 6といった最新世代CPUのサポートが含まれる予定であり、ハードウェアサポートの大幅な強化が見込まれる。rc7が最終候補版となれば、来週中に正式版7.0が公開されることになる。引き続きユーザーからのテスト報告が求められており、rc7を実際の環境で試してフィードバックを送ることが奨励されている。

概要 BroadcomはKubeCon EU 2026（アムステルダム）にて、Kubernetesネイティブのバックアップ・リストア・移行ツール「Velero」をCloud Native Computing Foundation（CNCF）のサンドボックスプロジェクトとして寄贈すると発表した。Veleroは2026年2月にCNCFサンドボックスへの申請が受理されており、今回のKubeConでの発表はその公式なコミュニティへの移行を示すものとなった。CNCF CTOのChris Aniszczyk氏は「VeleroはKubernetes環境における重要なバックアップおよびディザスタリカバリレイヤーを提供し、ステートフルアプリケーションを保護します。CNCFサンドボックスに参加することで、ベンダーニュートラルな環境のもとコミュニティコラボレーションを促進できます」とコメントした。 VeleroのCNCF移行の背景と意義 Veleroはクラスタの状態と永続データの保護、ディザスタリカバリおよびロールバックワークフロー、クラスタ間や異なるクラウド・オンプレミス環境へのワークロード移行といった機能を提供するKubernetesエコシステムにおける重要なツールだ。これまでBroadcom（旧VMware）が主体的に開発・管理してきたが、CNCFへの移管によってベンダーニュートラルなガバナンスのもとに置かれることになる。これにより、特定ベンダーへの依存という懸念が払拭され、幅広いコントリビューターが参加しやすくなる。Broadcomは自社がCNCFのトップ5コントリビューターに位置すると主張しており、今回の寄贈はオープンソースコミュニティへのコミットメントの一環として位置づけられている。 同時発表：VMware vSphere Kubernetes Service 3.6 Veleroの寄贈と合わせ、BroadcomはVMware vSphere Kubernetes Service（VKS）3.6もリリースした。主な新機能として、Kubernetes 1.35への対応（24ヶ月の拡張サポート付きでCNCF認定済み）、RHEL 9のサポート追加（既存のPhoton OS 5、Ubuntu 22.04/24.04、Windows Server 2022に加え）、ノードプール単位で異なるOSを組み合わせられるヘテロジニアスクラスタ対応が挙げられる。運用面では、データベースやレイテンシ敏感型ワークロード向けのTuneDプロファイルによるカーネル・sysctlチューニング、アップグレード前の事前チェック機能（SystemCheckSucceeded条件）、vCenter認証不要でのサポートバンドル生成が実装された。セキュリティ面ではAppArmorプロファイルのカスタムリソース管理やnftablesバックエンドのサポートも追加されている。 今後の展望 BroadcomはCNCFへのVelero移管を通じ、エンタープライズ向けKubernetesデータ保護の長期的な持続可能性を高めるとともに、より広いコミュニティと共同でプロジェクトの技術的方向性を決定していく方針だ。VKS 3.6とVeleroのCNCF移管は、BroadcomがVMware Cloud Foundation上でVMとコンテナを対等なワークロードとして扱うという戦略的方向性とも一致しており、エンタープライズKubernetesプラットフォームの信頼性と中立性をアピールする動きとして注目される。

概要 Rustの公式ドキュメントホスティングサービス「docs.rs」は、2026年5月1日からデフォルトでビルドするターゲットを従来の5つから1つ（x86_64-unknown-linux-gnu）に削減すると発表した。これまで、クレートがCargo.tomlのdocs.rsメタデータでtargetsリストを明示的に定義していない場合、docs.rsは5つのデフォルトターゲット向けにドキュメントを自動的に生成していた。5月1日以降は、新規リリースおよび既存リリースの再ビルドを含め、明示的に指定のない限りデフォルトの1ターゲットのみでビルドが行われるようになる。 変更の背景とメリット この変更の主な動機はビルド時間とリソース消費の削減にある。実際のところ、多くのクレートはターゲットアーキテクチャによってコンパイルされるコードが変わらないため、複数のターゲット向けにドキュメントを生成しても冗長な作業となっていた。1ターゲットのみをビルドすることで、docs.rsのインフラ負荷を大幅に軽減できる。この方針はdocs.rsが2020年に始めた段階的な効率化改革の延長線上にある取り組みでもある。 複数ターゲットが必要なクレートへの対応 プラットフォーム固有のコードを持つクレートや、複数のターゲット向けドキュメントが必要なクレートは、Cargo.tomlのdocs.rsメタデータを通じて引き続き対応できる。default-targetフィールドで表示するデフォルトターゲットを変更したり、targetsリストに複数のターゲットを明示的に指定したりすることで、従来と同様の挙動を維持することが可能だ。クレート開発者は5月1日までに設定を見直し、必要に応じてメタデータを追加しておくことが推奨される。

概要 アムステルダムで開催されたKubeCon + CloudNativeCon Europe 2026（2026年3月24日）のDay 1において、NVIDIAはCloud Native Computing Foundation（CNCF）のプラチナメンバーとして正式に加入し、GPU向けDynamic Resource Allocation（DRA）ドライバーをCNCFへ寄贈すると発表した。このドライバーはベンダー中立なリファレンス実装としてKubernetesプロジェクト配下でコミュニティ管理へ移行する。CNCFのCTO Chris Aniszczyk氏は「NVIDIA DRAドライバーのアップストリーム化は、オープンソースのKubernetesとAIインフラにとって大きなマイルストーン」と評した。13,500人以上が100カ国から参加した同カンファレンスで発表されたこの取り組みは、AIインフラ標準化への業界的な期待の高さを示している。 GPU DRAドライバーの技術的な詳細 従来のKubernetesにおけるGPU管理では、nvidia.com/gpu:1 のような単純な整数リソースとして扱うモデルが主流であり、現代のAIワークロードが必要とする細粒度な要求を表現できなかった。新たに寄贈されるDRAドライバーはこの制約を大きく解消する。 主な機能は以下の通りだ。 NVIDIA Multi-Process Service（MPS）とMulti-Instance GPU（MIG） によるスマートなGPU共有 NVIDIA Multi-Node NVLink を活用したGrace Blackwellシステム上での大規模AIモデルのスケーラブルなトレーニング ComputeDomains という抽象化レイヤーにより、複数ノードにまたがるワークロードが単一の巨大なGPU上で動作しているかのように振る舞うマルチノードNVLink通信 Container Device Interface（CDI） による標準化されたデバイス注入 アプリケーション要求に応じたリアルタイムのハードウェア再設定 アーキテクチャとしては「GPUオペレーター」「DRAドライバー」「KAIスケジューラー」の3層構造で構成される。KAIスケジューラーはAI対応インテリジェンスを担い、フラクショナル割り当てや分散トレーニング向けのギャングスケジューリングなどを提供し、今回CNCFサンドボックスプロジェクトとして新たにオンボードされた。 追加発表とエコシステムへの影響 NVIDIAはDRAドライバーの寄贈に加え、以下の取り組みも発表した。 Grove: GPUクラスター上でAIワークロードをオーケストレーションするためのオープンソースKubernetes API Kata Containers向けGPUサポート: 軽量仮想マシンを活用したセキュアなGPU利用 NVSentinel および AI Cluster Runtime プロジェクトの公開 さらにNVIDIAは今後3年間でCNCFプロジェクトへ4百万ドルを投資し、高性能GPUコンピューティングリソースへのアクセスを提供することを約束した。Amazon Web Services、Broadcom、Canonical、Google Cloud、Microsoft、Nutanix、Red Hat、SUSEなど主要クラウド・インフラプロバイダーとの連携も進める予定だ。「KubernetesはモダンなAI時代ワークロードのデファクトコントロールプレーンに進化した」とされる中、今回の取り組みはGPU対応クラウドネイティブ基盤の標準化を加速し、AIインフラが独自サイロから共通ユーティリティへと移行する流れを決定づけるものとして注目される。

概要 Chainguardが公開した「State of Trusted Open Source Report（2026年4月版）」は、2025年12月から2026年2月までの期間に2,200以上のコンテナイメージプロジェクトと33,931件の脆弱性インスタンスを分析した調査結果をまとめたものだ。最大の注目点は、ユニーク脆弱性数が前四半期比145%増と急増した一方で、修正の中央値は安定した2.0日を維持していたことである。AIコード生成ツールの普及による開発サイクルの加速が、脆弱性発見件数の急増に直接影響していると報告は指摘する。 AI活用がもたらした技術スタックの変化 AIワークロードの本番環境への流入が、利用技術スタックにも明確な変化をもたらした。Chainguardの顧客の72.1%がPythonイメージを使用しており、機械学習やデータ処理ワークフローの主軸として定着している。またPostgreSQLの利用は前四半期比73%増と急伸しており、AI向けのベクター検索やRAG（検索拡張生成）機能の採用が主な要因とされる。上位25の本番イメージのうち半数以上を言語エコシステムが占め、Node（60.7%）、Java（44.4%）、Go（42.8%）、.NET（27%）が主要インフラを支えている。 脆弱性の急増と修正対応力 脆弱性の件数は急増したが、対応速度は維持された。組織は前四半期比で300%以上の修正を適用し、それにもかかわらず高リスク脆弱性の97.9%が1週間以内に修正されている。最も懸念されるのは、CVEインスタンスの96.2%が最もよく使われる上位20イメージの外側で発生している点だ。顧客は中央値で74%のイメージをこの上位20外から調達しているが、こうした「見えにくい依存関係」へのセキュリティ注目度は依然として低く、サプライチェーンリスクの温床となっている。 コンプライアンス対応とFIPS普及の加速 規制対応という観点では、FIPS準拠のPythonイメージが初めて顧客数トップ10に入り、セキュリティコンプライアンスが事実上の標準要件へと移行しつつあることを示している。現在、42%の顧客が本番環境で少なくとも1つのFIPSイメージを稼働させており、FedRAMP・PCI DSS・SOC 2に加え、EUサイバーレジリエンス法（CRA）などの規制要件が後押ししている。本レポートが示す核心は、AIによって開発規模が拡大し続ける中で、見過ごされがちな依存関係のセキュリティをいかに一貫して管理し続けるかという課題が、現代のソフトウェアセキュリティの最重要テーマになりつつある点だ。

概要 Discordは2026年3月、社内で運用してきたコンテンツモデレーション向けSafetyルールエンジン「Osprey」をオープンソースとして公開した。同エンジンは1日4億件のプラットフォームアクションを対象に毎秒230万ルールを評価する能力を持ち、大規模なオンラインコミュニティの安全管理に求められる高スループット・低レイテンシを両立させている。プロジェクトはROOSTオーガニゼーションおよびinternet.devと連携して管理されている。 アーキテクチャと技術的詳細 OspreyはRustとPythonを組み合わせたポリグロットアーキテクチャを採用している。Rustコーディネーターが非同期イベントストリームとgRPCリクエストを処理してトラフィックをルーティングし、安定したレイテンシを実現する。一方、ステートレスなPythonワーカーがDockerコンテナ上で動作し、ルール評価をスケールアウト可能な形で担う。 ルール記述には独自DSL「SML」が使われる。SMLはPythonに似た構文を持ち、静的バリデーションをサポートしている。ワーカーは起動時にSMLルールを抽象構文木（AST）に変換することでイベントごとの処理オーバーヘッドを最小化する。ルールの配信にはETCDが用いられており、再デプロイなしに本番環境のルールをリアルタイムで更新できる点が運用上の大きな利点となっている。 機能と拡張性 Ospreyはプラットフォーム上のリアルタイムアクティビティをJSON形式のイベントペイロードとして受け取り、自動応答を実行する。特定の対象（エンティティ）に対してラベルや分類を付与し、設定可能な出力シンクへ判定結果をルーティングする仕組みだ。標準的な構成ではApache KafkaとApache Druidをリアルタイム分析に活用する。 拡張性も重視されており、標準Pythonで記述したユーザー定義関数（UDF）を標準ライブラリとして組み込める。これにより外部APIの呼び出しや機械学習モデルとの統合も可能になっている。 早期採用とOSS展開の意義 OspreyはDiscord以外にもすでに実績がある。分散型SNSプラットフォームのBlueskyやMatrix.orgが早期採用例として挙げられており、Discord固有の要件を超えた汎用的な適用可能性が示されている。オープンソース化によって大規模コミュニティプラットフォームが共通のセーフティインフラを共有・改善できる土台が整いつつあり、今後のコンテンツモデレーション技術の発展に寄与することが期待される。