OSS

概要 GitHubは2026年6月2日、GitHub Copilot SDKの一般提供（GA）開始を発表した。開発者は自前のアプリケーションやサービスにGitHub Copilotのアジェントエンジンを組み込めるようになり、プランニング・ツール呼び出し・ファイル編集・ストリーミングといったエージェントランタイム機能を活用できる。対応言語はNode.js/TypeScript・Python・Go・.NET・Rust・Javaの6言語で、各言語向けのパッケージマネージャー経由でインストール可能だ。 対応言語とインストール方法 各言語のインストールコマンドは以下の通り。Node.js/TypeScriptはnpm install @github/copilot-sdk、Pythonはpip install github-copilot-sdk、Goはgo get github.com/github/copilot-sdk/go、.NETはdotnet add package GitHub.Copilot.SDKで導入できる。RustとJavaはGA時に新たに追加された言語で、JavaはMavenおよびGradle経由で利用可能となっている。 主な機能と技術的詳細 SDKが提供する主要機能として、カスタムツールの定義、Model Context Protocol（MCP）サーバーへの接続、システムプロンプトの細粒度カスタマイズが挙げられる。そのほかにも、OpenTelemetryによるトレーシング、柔軟な認証オプション、クラウドセッション管理、フック機構への対応が含まれており、本番環境での運用を見据えた機能セットが整っている。 背景と利用可能性 SDKはパブリックプレビュー段階から開発者によって活用されており、CI/CDアシスタントや社内開発ツール、顧客向けのAI機能構築などの用途で実績を積んできた。GAへの移行により、APIの安定性が保証され、より本番環境への採用が進むと見られる。利用資格は既存のCopilotサブスクライバー（無料プランを含む）およびBYOK（Bring Your Own Key）ユーザーに開放されており、追加費用なく今日から利用を開始できる。

概要 GitHubは2026年4月27日、全CopilotプランをAIクレジット制の従量課金（Usage-Based Billing）モデルへ2026年6月1日から移行すると発表し、当日より正式稼働を開始した。従来は「プレミアムリクエストユニット（PRU）」という単位で課金されていたが、今後は「GitHub AIクレジット」に置き換えられ、入力・出力・キャッシュトークンの消費量に応じてクレジットが消費される仕組みとなる。 この変更の背景には、エージェント的な利用パターンの急増によるコスト構造の歪みがある。GitHubは「短い1回のチャット質問と、数時間にわたる自律的なエージェントセッションが同じ金額になってしまうのは持続不可能だ」と説明しており、利用実態に即した公平な課金体系を実現するための移行としている。 新しい価格体系と各プランの詳細 月額料金とそれに対応するクレジット枠は次のとおりで、サブスクリプション価格自体は変更されない。 Copilot Pro：月額10ドル、毎月10ドル相当のクレジット付与 Copilot Pro+：月額39ドル、毎月39ドル相当のクレジット付与 Copilot Business：ユーザー1人あたり月額19ドル、19ドル相当のクレジット付与 Copilot Enterprise：ユーザー1人あたり月額39ドル、39ドル相当のクレジット付与 BusinessおよびEnterpriseプランの顧客には6〜8月の3か月間、プロモーションとして追加クレジット（Businessは30ドル分、Enterpriseは70ドル分）が付与される。 機能ごとの課金方針と組織向け管理機能 コード補完機能と「Next Edit Suggestions」は引き続き全プランで無料のまま提供される。一方、Copilot Chatやコードレビュー、各種エージェント機能はAIクレジットが消費対象となる。またコードレビュー機能はGitHub Actionsの実行分も別途消費する点に注意が必要だ。これまで提供されていたフォールバック体験（低コストモデルへの自動切り替え）は廃止される。 組織向けには、エンタープライズ・コストセンター・ユーザーの各レベルでクレジットをプール管理し予算上限を設定できる機能が追加され、チーム単位でのコスト管理が可能になった。 移行スケジュール 月払いのサブスクリプションは6月1日付けで自動的に新モデルへ移行済みとなる。年払い契約者は現行の有効期限が切れるまでPRU方式の料金が適用され、期限後に月払いプランへ切り替わり、残存分は日割りでクレジットに換算される。

概要 Googleは2026年5月19日、AI搭載コマンドラインツール「Gemini CLI」の無料・Pro・Ultraユーザー向けサポートを2026年6月18日で終了すると発表した。代替として提供されるのは、Google I/O 2026で発表されたクローズドソースの「Antigravity CLI」だ。ただしGemini Code AssistのStandardまたはEnterpriseライセンス契約企業は影響を受けず、従来通りのアクセスが維持される。 2025年夏にApache 2.0ライセンスでオープンソース公開されたGemini CLIは、わずか1年足らずで6,000件以上のプルリクエストをコミュニティから受け入れ、Dynatrace、Elastic、Figma、Shopify、Stripeなど大手企業との統合も進んでいた。このような状況での突然の方針転換に対し、貢献した開発者たちから激しい批判が巻き起こっている。 「おとり商法」批判の核心 開発者Andrea Albertiは「自分たちはエンタープライズ向けコードベースのために事実上無償で働いていたのか」と問い、別の貢献者はGoogleが「オープンソースで開発者を集め、貢献させた上でクローズドソースへ移行した」と直接的に批判した。 最も矛盾として指摘されるのは、企業ライセンスユーザーへの影響がゼロである点だ。Googleは「単一プラットフォームへの統合」という技術的必要性を移行理由として挙げるが、その技術的必要性が有料ユーザーには適用されないことから、コミュニティからは説明の整合性を欠くと見なされている。この構図——オープンソースでコミュニティの貢献を集め、成熟した段階でクローズドな企業向け製品に転換する——は「バイト・アンド・スイッチ（おとり商法）」と呼ばれ、OSS界隈での強い懸念を呼んでいる。 Antigravity CLIの課題と移行の問題点 後継となるAntigravity CLI自体にも問題がある。Googleは「初期段階では1対1の機能パリティを持たない」と自ら認めており、移行先が旧ツールと同等の機能を備えていない状態での廃止となる。使用量制限も厳格化され、従来の「1日1,000リクエスト」から「週単位」の制限に変わり、大規模なコード生成を行うユーザーが上限に達する事例が報告されている。さらに移行時点でnpmやHomebrewでの配布が未対応であり、既存ワークフローへの組み込みが困難な状況も批判を強めている。 OSSプロジェクトへの信頼と今後の課題 本件はApache 2.0ライセンスという形式上の「オープンソース」が、クラウドサービスや専有インフラへの依存によって実質的にクローズドソース化し得ることを示す事例として注目されている。Linux Foundation Model Openness Toolのような評価フレームワークがこの問題を可視化しつつあるが、大企業がオープンソースコミュニティとの関係をどう設計するかという問いは、業界全体に投げかけられた課題として残っている。

概要 オープンソースのバージョン管理プラットフォームGiteaの組み込みコンテナレジストリに、重大な認証バイパス脆弱性（CVE-2026-27771）が発見された。CVSSスコアは8.2（High）で、「プライベート」に設定されたリポジトリのコンテナイメージが、アカウントやパスワードを持たないインターネット上の誰からでも取得可能な状態にあった。セキュリティ研究者のNoScopeが2026年4月に自動ペネトレーションテストエージェントを通じて発見し、Giteaメンテナに責任ある開示を行った。修正済みのバージョン1.26.2が2026年5月にリリースされており、早急なアップグレードが推奨されている。 技術的な詳細 本脆弱性はGiteaのコンテナレジストリにおけるアクセス制御の根本的な欠陥に起因する。プライベート指定されたリポジトリであっても、レジストリエンドポイントが匿名リクエストに対してイメージレイヤーおよびマニフェストを返してしまう設計になっており、攻撃者は標準的なDocker/OCIプルリクエストを使用するだけで認証なしに完全なプライベートコンテナイメージを取得できた。NoScopeは「Giteaのコンテナレジストリは、アカウントもパスワードも事前のアクセス権も持たないインターネット上の誰もが、プライベートとされるコンテナイメージをプルできる状態にあった」と説明している。プライベート指定はまったく機能しておらず、この欠陥は約4年間にわたって検出されることなく存在し続けた。 影響範囲 Shodanを通じた調査により、インターネットに公開されているGiteaインスタンスは3万4,000件以上確認され、そのうち約3万1,750件（93%）が脆弱な可能性があるとされている。4,000件は主要なクラウドプラットフォーム上の本番環境で稼働しており、7,000件はデフォルトポートで動作していた。影響は30か国以上に及び、中国・米国・ドイツ・フランス・英国への集中が確認されている。影響を受けた業界は医療機関、航空宇宙メーカー、小売業インフラ、ISP、エンタープライズソフトウェア開発チームなど多岐にわたる。悪用に成功した場合、ソースコードや業務ロジックの流出、APIキーやデータベースパスワード・クラウドプロバイダー認証情報などの機密情報の取得、内部インフラ構成の把握といった深刻な被害が生じる可能性がある。 Forgejoへの波及と今後の対応 GiteaのフォークであるForgejoも独立した検証において脆弱性が確認されており、他のGiteaから派生したプロジェクトも個別にパッチ適用が必要な状況にある。セキュリティ研究者は技術的な詳細の公開を意図的に控えており、エコシステム全体がパッチを適用するのに十分な時間を確保する方針をとっている。現時点では公開されたPoC（概念実証コード）や実際の悪用報告は確認されていないが、脆弱性の深刻度と攻撃の容易さから高リスクと評価されており、インターネット接続環境でGiteaを運用している組織には即時のv1.26.2へのアップグレードが強く推奨される。アップグレードが直ちにできない場合の一時的な回避策として、設定ファイルで[service].REQUIRE_SIGNIN_VIEW=trueを設定することで匿名アクセスを制限できるが、意図的に公開設定にしているリポジトリへの影響も生じるため注意が必要だ。

概要 IBMとRed Hatは2026年5月28日、オープンソースソフトウェア（OSS）のサプライチェーンセキュリティを抜本的に強化する取り組み「Project Lightwell」を発表した。総投資額は50億ドルにのぼり、20,000人を超えるエンジニアとAIツールを組み合わせて脆弱性の特定・検証・修正を大規模に自動化することを目指している。IBM会長兼CEOのArvind Krishna氏は「オープンソースは今日のデジタル経済の基盤であり、現代AIの土台でもある。我々は今、その構築・セキュリティ確保・スケールのあり方における転換点に立っている」と述べ、業界全体でのセキュリティ水準向上に向けた本プロジェクトの重要性を訴えた。 技術的な取り組みと仕組み Project Lightwellの中核となるのは、エンタープライズ向けの統一的なOSSセキュリティクリアリングハウスの構築だ。このプラットフォームでは、企業が発見した脆弱性を報告すると、AIによる自動検証とエンジニアによる審査を経て、検証済みのパッチが提供される仕組みとなっている。AIツールは脆弱性のトリアージや優先順位付けを担い、膨大な量のOSSコンポーネントを効率的にスキャンすることを可能にする。また、上流のオープンソースコミュニティとも密に連携し、修正内容がプロジェクト本体へフィードバックされる体制も整える方針だ。 業界への影響と今後の展望 すでに11の大手金融機関がProject Lightwellへの参加を表明しており、早期実装から得られた知見がプログラムの改善に継続的に反映される予定となっている。OSSのサプライチェーン攻撃は近年急増しており、Log4ShellやXZ Utilsのインシデントに象徴されるように、単一のOSSコンポーネントの脆弱性が広範なエンタープライズシステムに連鎖的な影響をもたらすリスクが顕在化している。IBMとRed Hatによる今回の大規模投資は、こうしたリスクへの業界横断的な対応策として注目されており、エンタープライズにおけるOSSの信頼性向上に向けた重要な一歩となる可能性がある。

概要 Linux Open-Source SummitにてKernelScript 0.1が発表された。KernelScriptはeBPF・ユーザー空間・カーネル空間の開発を単一のコードベースに統合することを目的とした型安全なドメイン固有言語（DSL）で、Apache 2.0ライセンスのオープンソースとして公開されている。従来、eBPFプログラムをC言語で手書きするには複雑な知識とボイラープレートが必要だったが、KernelScriptはその複雑さを抽象化し、必要なコードやMakefile、カーネルモジュール統合コードを自動生成することで開発効率の向上を目指している。 技術的な詳細 KernelScriptは主要なeBPFプログラム種別を幅広くサポートしている。ネットワークパケット処理向けのXDP（eXpress Data Path）、トラフィック制御向けのTC（Traffic Control）、カーネル関数のトレーシングに使うプローブ、そしてパフォーマンスイベントプログラムが対象となっている。データ構造についてはハッシュマップ、CPU別配列、LRU（Least Recently Used）マップ、ピンマップといったeBPF標準の各種マップ型に対応する。 さらに高度な機能として、テールコールの自動化、dynptrによる動的ポインタ処理、プログラムライフサイクルチェック、kfunc（カーネル関数）統合もサポートされている。これらの機能を一つの言語で統一的に扱えることで、ネットワーク・トレーシング・可観測性・セキュリティ・パフォーマンス分析といったeBPFの幅広いユースケースにおける開発体験が改善されることが期待される。 現状と今後の展望 開発チームは現時点のリリースをあくまで実験的なものと位置づけており、構文やAPIは今後変更される可能性があるとして本番環境での使用を推奨していない。バージョン0.1という初期段階のリリースながら、eBPF開発の敷居を下げるという方向性は明確であり、今後のコミュニティの反応や継続的な開発進捗に注目が集まる。

概要 GitHubは2026年5月21日、Eclipse IDE向けのAI開発支援ツール「GitHub Copilot for Eclipse」をMITライセンスのもとオープンソースとして公開した。同プラグインのリポジトリには、インラインコード補完・Next Edit Suggestions（NES）・チャット機能・エージェントモード・スキルおよびプロンプトファイルといったコアコンポーネントの実装が含まれており、開発者コミュニティが自由に参照・改修・貢献できる形となっている。GitHubはオープンソース化の動機として「コミュニティ主導のイノベーションと透明性の向上」を挙げており、Eclipseが長年オープンソースエコシステムの一翼を担ってきた背景を踏まえ、AI開発ツールもオープンな精神のもとで構築すべきとの方針を示した。 公開されたコンポーネント リポジトリで公開されたコードは複数の領域に及ぶ。インラインコード補完では自動提案を生成・表示する仕組みが、チャット機能では会話フローとツール呼び出しのロジックが実装されている。エージェントモードについては複数ステップにわたるワークフローの実行機構が含まれるほか、スキルおよびプロンプト管理の検出・呼び出しメカニズムも公開された。さらにカスタムエージェントの構築やModel Context Protocol（MCP）との統合を可能にする高度なAI機能のコードも含まれており、拡張性の高い構成となっている。 コミュニティへの影響と今後 オープンソース化の発表直後から、複数の貢献者による改善が進行しており、コミュニティの関心の高さがうかがえる。GitHubはバグ報告・プルリクエスト・フィードバックをいずれも歓迎しており、Eclipse IDEを日常的に利用する開発者が直接改善に参加できる体制が整った。Eclipse向けCopilotのオープンソース化は、VS Code以外のIDEにおけるAI支援開発ツールの透明性確保という観点でも注目されており、他のIDE向けプラグインへの波及効果が期待される。

概要 GoogleはGoogle I/O 2026にて、Android CLI 1.0の安定版を正式リリースした。開発者リレーションズエンジニアのSimona MilanovicとBen Trengroveが発表したこのツールは、Claude Code・OpenAI Codex・Googleの Geminiなどのサードパーティ製AIエージェントがAndroid開発ツールチェーンに直接アクセスできるよう設計されている。Googleによれば、AIエージェントがAndroid Studio内で作業する場合と比較して、LLMのトークン使用量を70%以上削減し、タスク完了速度を最大3倍に向上させるという。 主な機能と構成 Android CLIは3つの主要コンポーネントで構成される。まずAndroid CLI本体はスクリプタブルなツールチェーンへのアクセスを提供し、エージェントがプロジェクト作成・アプリビルド・エミュレーター管理・SDK インストールを自律的に実行できるようにする。次にAndroid SkillsはMarkdown形式の指示セット集であり、エッジtoエッジ対応の実装やAGP 9へのアップグレード、Compose移行など、具体的な開発ワークフローをエージェントが自動的に参照・実行できる仕組みだ。さらにKnowledge BaseはAndroid・Firebase・Kotlinの最新ドキュメントへのリアルタイムアクセスを提供し、LLMのトレーニングデータが古い場合でも常に最新のガイダンスをエージェントが活用できるよう補完する。 新たに追加された android studio コマンドにより、エージェントはAndroid Studioの高度な機能（ファイル解析・宣言箇所の特定・Composeプレビューのレンダリング・依存関係の検索など）を直接利用できるようになった。またインストール面では、apt-get・winget・homebrewに対応しユーザーローカルディレクトリへのインストールがデフォルトとなり、Windows・macOS・Linux各プラットフォームでの導入が容易になった。 コミュニティの反応と今後の展望 開発者コミュニティからはトークン消費の削減効果を評価する声が上がる一方で、ベンチマークの具体性や、真のボトルネックであるコード検証とテスト工程への貢献については懐疑的な意見もある。Googleはさらに、自然言語によるアプリテストと検証を可能にする「Journey Support」機能や、Google Antigravity 2.0との統合（Androidリソースバンドルによるオプション提供）を発表しており、AIエージェントを活用したAndroid開発基盤の整備が本格化している。

概要 GitHubは2026年5月22日、npmのセキュリティを強化する2つの主要機能を発表した。一つはステージド公開（Staged Publishing）の一般提供開始、もう一つはnpm 11.15.0で追加された非レジストリソースからのインストール制御フラグ群だ。いずれも、TeamPCPのようなサイバー犯罪グループによるオープンソースパッケージへの大規模なサプライチェーン汚染キャンペーンが増加する中、供給チェーン全体の防御を強化することを目的としている。 ステージド公開：2FA承認を挟むリリースフロー ステージド公開は、従来の「npm publish で即時公開」というモデルを改め、リリース前に人的承認ステップを挟む仕組みだ。開発者がCI/CDパイプラインから npm stage publish を実行すると、ビルド済みtarballがステージキューにアップロードされ、2FA（二要素認証）を有効にしたメンテナが明示的に承認するまで、利用者はそのバージョンをインストールできない。承認はnpmjs.comのウェブUIとnpm CLI両方から操作可能となっており、CI/CDは非対話的に実行し、メンテナが後から確認・承認するという運用モデルが想定されている。 この機能を利用するにはnpm CLI 11.15.0以上が必要で、対象パッケージはnpmレジストリに既存のものに限られる（新規パッケージは初回公開にステージド公開を使用不可）。また、OIDCトラステッドパブリッシングと組み合わせてパーミッションを stage-only に制限すれば、CIから直接公開することを完全に禁止できる。これにより、CIが侵害された場合でも悪意のあるバージョンが即座に配布されるリスクを大幅に低減できる。 インストールソース制御フラグ npm 11.10.0で導入された --allow-git フラグ（Gitソースからのインストール制御）を拡張する形で、npm 11.15.0では以下の3つの新フラグが追加された。 --allow-file: ローカルファイルパスおよびローカルtarballからのインストールを制御する --allow-remote: httpsなどのリモートURLからのインストールを制御する --allow-directory: ローカルディレクトリからのインストールを制御する 各フラグは all（現在のデフォルト）または none の値を受け入れ、CLIオプション・.npmrc・package.json のいずれでも設定できる。なお、--allow-git はnpm v12（次期メジャーバージョン）でデフォルトが all から none に変更される予定であり、今後はレジストリ外ソースへの依存がより明示的な許可を必要とする方向に進む見通しだ。 セキュリティ上の意義 これらの機能は、レジストリ外ソースからの依存関係導入や、CI/CDを経由した意図しないパッケージ公開を防ぐ明示的な許可リスト方式を提供する。サプライチェーン攻撃の手口が高度化・大規模化する現状において、パッケージのライフサイクル全体にわたってメンテナの意図的な関与を求める設計は、エコシステム全体の信頼性向上に寄与するものと評価されている。

概要 OpenTofu 1.12.0が2026年5月14日にリリースされた。今回の目玉は、prevent_destroyライフサイクル引数を動的に設定できるようになったことで、これはTerraformのGitHubに2016年に起票されながらHashiCorpが一度も実装しなかった機能だ。コミュニティ主導のフォークとして誕生したOpenTofuが、商業的に管理されてきたTerraformを開発速度で上回っていることを象徴するリリースとなった。 動的prevent_destroyサポートの詳細 従来、prevent_destroyはハードコードが必須であり、本番環境と開発環境を同一のモジュールで管理しようとすると、すべての環境で同じライフサイクルルールが適用されるという制約があった。これを回避するにはモジュールを複製するしかなく、管理コストが増大していた。OpenTofu 1.12では、prevent_destroyに入力変数などの動的な値を参照できるようになり、環境ごとに異なるライフサイクルルールを単一のモジュールで適用できる。例えば本番環境ではprevent_destroy = true、開発環境ではprevent_destroy = falseといった設定を変数で切り替えることが可能になった。 その他の新機能と改善 プロバイダーチェックサムの改善により、tofu initの実行時にロックファイルへzh:とh1:両方のハッシュが自動で記録されるようになった。従来はtofu initでzh:ハッシュのみが書き込まれ、キャッシュやミラーに必要なh1:ハッシュを取得するために別途tofu providers lockコマンドを実行する必要があったが、この手間が不要になった。 -json-into=FILENAMEフラグが新たに追加され、機械可読なJSON出力を指定ファイルへ書き込みながら、端末には人間が読みやすい通常の出力を維持できるようになった。CI/CDパイプラインなどでのツール統合を容易にしつつ、オペレーターの可読性を損なわない改善だ。 また、destroy = falseメタ引数により、インフラを実際に削除することなくリソースをOpenTofuの管理状態から除外できるようになった。複数プロバイダーの依存関係がある場合のtofu initの並行インストール対応も行われ、初期化時間の短縮が図られている。 廃止予定 WinRMプロビジョナーは保守が行われていないGoライブラリへの依存を理由に非推奨となり、バージョン1.13での削除が予定されている。また、386およびARMの32ビットアーキテクチャのビルドも段階的に廃止される予定だ。