Category Archive システム開発

Astro 6.4リリース。プラグ可能なMarkdownパイプラインとRust製プロセッサーSätteriが登場

Astro 6.4リリース。プラグ可能なMarkdownパイプラインとRust製プロセッサーSätteriが登場

Astro 6.4が2026年5月28日にリリースされた。Markdown処理パイプラインを自由に差し替え可能にする新API「markdown.processor」、Rustで書かれた高速MarkdownプロセッサーSätteriの試験的導入、そしてCloudflare環境向けのルーティングヘルパーが追加された。

これまでの設定方法は非推奨となり、将来的なAstro 8.0では完全に廃止される予定だ。今回のアップデートで、静的サイト構築におけるMarkdown処理の柔軟性とパフォーマンスが大幅に向上する。

プラグ可能なMarkdownプロセッサーAPI

プラグ可能なMarkdownプロセッサーAPI

AstroのMarkdownパイプラインはこれまで、unified(remark/rehype)エコシステムを中心に構築されてきた。強力で数千ものプラグインが利用できる一方、特定のプロジェクトの要求に合わない場合もあった。今回追加されたmarkdown.processor設定オプションでは、そのパイプライン全体を丸ごと差し替えられる。

設定の変更方法

デフォルトのプロセッサーは従来通りunified()が使われるため、既存プロジェクトは何も変更せずにそのまま動き続ける。remark/rehypeプラグインも同じ挙動を保つが、設定場所がトップレベルのmarkdownからプロセッサー内に移行した。

import { defineConfig } from 'astro/config';
import { unified } from '@astrojs/markdown-remark';
import remarkToc from 'remark-toc';

export default defineConfig({
  markdown: {
    processor: unified({
      remarkPlugins: [remarkToc],
    }),
  },
});
従来の設定 (Before)
import { defineConfig } from ‘astro/config’; import remarkToc from ‘remark-toc’; export default defineConfig({ markdown: { remarkPlugins: [remarkToc], }, });
新APIでの設定 (After)
import { defineConfig } from ‘astro/config’; import { unified } from ‘@astrojs/markdown-remark’; import remarkToc from ‘remark-toc’; export default defineConfig({ markdown: { processor: unified({ remarkPlugins: [remarkToc], }), }, });

従来のトップレベルオプション(markdown.remarkPlugins, markdown.rehypePlugins, markdown.remarkRehype, markdown.gfm, markdown.smartypants)も引き続き動作するが非推奨となり、Astro 8.0で完全に削除される予定だ。

移行の注意点

既存プロジェクトの移行は比較的簡単だ。unified({...})内にプラグインをまとめて記述するだけでよい。ただし、マークダウン処理をカスタマイズした複雑な設定を行っている場合は、コードの再構成が必要になる。公式ドキュメントのMarkdownガイドが更新されているため、詳細はそちらを参照してほしい。

Rust製MarkdownプロセッサーSätteri

Rust製MarkdownプロセッサーSätteri

プラグ可能なプロセッサーAPIの追加により、Astroは標準とは異なるMarkdownプロセッサーも同梱できるようになった。今回導入された@astrojs/markdown-satteriパッケージは、Rustで書かれた高速なMarkdown/MDXパイプライン「Sätteri」をベースにしている。

パフォーマンスの劇的な向上

Sätteriはデフォルトのunifiedベースのパイプラインよりも大幅に高速で、多くのMarkdown機能をプラグインなしでネイティブ実装している。Astroの公式ブログによれば、自社のドキュメントサイトをSätteriに切り替えたところ、ビルド時間が1分以上短縮されたという。

npm install @astrojs/markdown-satteri
import { defineConfig } from 'astro/config';
import { satteri } from '@astrojs/markdown-satteri';

export default defineConfig({
  markdown: {
    processor: satteri({
      features: { directive: true },
    }),
  },
});
従来のunifiedパイプライン
ビルド時間 約2分
※大規模ドキュメントサイトの例
Sätteri使用時
ビルド時間 約1分
約1分短縮。Rustネイティブの恩恵

この数値はあくまで一例だが、コンテンツ量の多いサイトでは特に効果が大きい。Rustで記述されているため、CPUバウンドな処理が高速化される仕組みだ。

プラグイン互換性と今後のデフォルト化

Sätteriはremark/rehypeプラグインを実行しない。unifiedエコシステムのプラグインに依存している場合は、当面unified()を使い続けるか、SätteriのMDAST/HASTプラグインに移植する必要がある。Astroチームは、将来のメジャーバージョンでSätteriをデフォルトのMarkdownプロセッサーにすることを目指している。

Rustプロセッサーや新APIに関するフィードバックは、公式のRFCDiscussionで受け付けている。興味がある開発者はぜひ参加してほしい。

Cloudflare向け高度ルーティングヘルパー

Cloudflare向け高度ルーティングヘルパー

Astro 6.3で導入された実験的な高度ルーティング機能をCloudflare環境で使いやすくするため、@astrojs/cloudflareパッケージにcf()ヘルパーが追加された。SESSION KVバインディングの注入、ASSETSバインディングによる静的アセット配信、クライアントIPアドレスやwaitUntilの処理など、Cloudflare特有の面倒な設定を一手に引き受ける。

Fetchハンドラでの利用

import { astro, FetchState } from 'astro/fetch';
import { cf } from '@astrojs/cloudflare/fetch';

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const state = new FetchState(request);
    const asset = await cf(state, env, ctx);
    if (asset) return asset;
    return astro(state);
  },
};

Honoミドルウェアでの利用

import { Hono } from 'hono';
import { actions, middleware, pages, i18n } from 'astro/hono';
import { cf } from '@astrojs/cloudflare/hono';

const app = new Hono<{ Bindings: Env }>();
app.use(cf());
app.use(actions());
app.use(middleware());
app.use(pages());
app.use(i18n());

export default app;
Cloudflare Workersルーティングの簡略化フロー
cf() SESSION KV ASSETS配信 IPアドレス解決 waitUntil
開発者はcf()ミドルウェアを適用するだけで、Cloudflare固有の設定が自動注入される

このヘルパーにより、Cloudflare上で高度なルーティングを実装する際のボイラープレートコードが大幅に削減される。実験的機能ではあるが、実用段階に入りつつあると言えるだろう。

その他の改善とアップグレード手順

その他の改善とアップグレード手順

細かなバグ修正と今後のロードマップ

今回のリリースには、上記の主要機能以外にも多数のバグ修正と小さな改善が含まれている。詳細は公式の変更履歴を確認してほしい。また、Astroコアチームは活発に開発を続けており、コミュニティからのコントリビュートも盛んだ。

アップグレードの手順

既存のAstroプロジェクトをアップグレードするには、自動アップグレードツールを使うのが推奨だ。

# 推奨
npx @astrojs/upgrade

# 手動の場合
npm install astro@latest
pnpm upgrade astro --latest
yarn upgrade astro --latest

自動ツールは非推奨設定の移行などもサポートする。手動で行う場合は、設定ファイルの変更点を確認しながらアップデートしよう。

この記事のポイント

  • Markdown処理を差し替え可能にするmarkdown.processor APIが追加された
  • RustベースのSätteriプロセッサーによりビルド時間を大幅に短縮できる
  • Cloudflare向けcf()ヘルパーで高度ルーティングの設定が簡略化された
  • 従来の設定方法は非推奨となり、Astro 8.0で廃止予定。早めの移行が望ましい
  • アップグレードはnpx @astrojs/upgradeで簡単に行える
DockerのCopy Fail脆弱性対応とseccomp破壊の教訓

DockerのCopy Fail脆弱性対応とseccomp破壊の教訓

2026年4月末に公開されたLinuxカーネルの脆弱性CVE-2026-31431、通称「Copy Fail」は、2017年以降のほぼ全てのカーネルに影響する深刻な問題だ。Docker社はこの脆弱性に対し、コンテナランタイムレベルでの緩和策を急ピッチで提供した。

その過程で、Docker Engine v29.4.2の修正が32ビットバイナリのネットワーク機能を完全に破壊するという予期せぬ副次的被害を引き起こした。本記事では、この一連の対応と教訓を技術的に深掘りする。

コンテナ運用者は、カーネルパッチの適用が最優先だが、それが叶わない場合でもDocker Engineのアップデートによりリスクを大幅に低減できる。ここで得られた知見は、今後のコンテナセキュリティ対策における多層防御の重要性を浮き彫りにしている。

Copy Fail脆弱性の仕組みとリスク

Copy Fail脆弱性の仕組みとリスク

AF_ALGサブシステムの欠陥

Copy Failは、Linuxカーネルの暗号処理をユーザー空間から利用するためのAF_ALG(Algorithm Sockets)サブシステムに存在する。具体的にはalgif_aeadモジュールの不具合により、特権のないプロセスがページキャッシュに対して不正な書き込みを行える状態になっていた。

ページキャッシュとは、ファイルの読み取りデータをメモリ上に一時保存する仕組みだ。全プロセスが参照するため、ここを汚染されると、システム全体でファイルの内容が改ざんされて見える可能性がある。最も直接的な攻撃経路は、setuidバイナリ(実行時に高い権限で動作するプログラム)の改ざんによる権限昇格である。

この脆弱性の深刻さは、その単純さにある。PoC(概念実証コード)はきわめて簡潔で、カーネルがパッチされていない限り、2017年以降のあらゆるバージョンで動作する。攻撃が成功すると、コンテナ内からホスト全体、そして同じノード上の他コンテナにまで影響が及ぶのだ。

脆弱性の悪用フロー(Before)
攻撃者 AF_ALGソケット作成 ページキャッシュ汚染 setuid改ざん root権限取得
※ デフォルトのコンテナ権限で実行可能。約7年にわたり影響。
緩和策適用後(After)
攻撃者 AF_ALGソケット作成 システムコールブロック
※ 多層防御によりAF_ALGへの経路が遮断される

このデモが示す通り、脆弱なカーネルでは攻撃者に一直線のルートを提供してしまう。Dockerの役割は、コンテナランタイムのレイヤーでこの経路を物理的に塞ぐことだった。

コンテナ環境への影響範囲

Dockerのデフォルトセキュリティプロファイルでは、コンテナからのAF_ALGソケット作成が許可されていた。つまり、攻撃者が何らかの方法でコンテナ内でコードを実行できた場合、この脆弱性を利用してホストのroot権限を奪取できる状態にあった。

さらに悪いことに、ページキャッシュはホスト全体で共有される。攻撃が成功した場合、被害はそのコンテナ内に留まらず、同じDockerイメージのレイヤーを共有する他のすべてのコンテナにも波及する。これは、マルチテナント環境やマイクロサービスを密に配置しているノードでは壊滅的な被害につながりかねない。

Docker Engineの対応と失敗の分析

Docker Engineの対応と失敗の分析

v29.4.2 seccomp修正の試み

Dockerチームは当初、seccomp(Secure Computing Mode / セキュアコンピューティングモード)プロファイルの更新で対応しようとした。seccompは、コンテナが発行できるシステムコールをフィルタリングする仕組みだ。具体的には、socket()システムコールの第一引数を検査し、AF_ALGアドレスファミリが指定された場合に拒否するルールを追加した。

しかし、x86_64 Linuxにはsocketcall()という古い多重化システムコールが存在する。これはsocket()bind()などの複数のソケット操作を一つのシステムコール番号の背後にまとめたものだ。問題は、socketcall()では実際の引数(アドレスファミリを含む)がユーザー空間の配列にパックされ、そのポインタが渡されることだ。seccompのフィルタエンジンであるBPFは、このポインタ先を参照して検査できない。

つまり、seccompだけではsocketcall()経由のAF_ALGを選択的にブロックできない。やむを得ずDockerチームは、socketcall()全体を拒否するという決断を下し、v29.4.2をリリースした。

v29.4.2でのブロック範囲(Bad)
socket(2) AF_ALG拒否 socketcall(2) 全体拒否
※ 32bitバイナリのネットワーク機能が破壊。SteamCMDやWineが動作不能に。
v29.4.3でのブロック範囲(Good)
AppArmor AF_ALG選択拒否 SELinux AF_ALG選択拒否 socketcall 許可(32bit互換性維持)
※ LSMを活用し、通常のネットワーク機能は維持したままAF_ALGだけを遮断。

この比較が示すのは、セキュリティ対策における粒度の重要性だ。全体をブロックすれば安全だが、システムの機能を破壊する。真に効果的な対策は、悪意のある操作だけをピンポイントで無効化することにある。

32bitバイナリ破壊の実態

socketcall()の一律拒否は、思わぬ大規模な副次的被害を引き起こした。32bit版のglibcは、すべてのソケット操作をsocketcall()経由で行う古いバージョンが残っている。Go言語のランタイムも、GOARCH=386でビルドされたバイナリでは無条件にsocketcall()を利用する。さらに、SteamCMDやWineといったレガシー・ゲーミング系のワークロードも、この仕組みに依存している。

これは単なるi386(32bit)の問題ではない。amd64環境であっても、プロセスはint $0x80命令を使うことでia32互換モードに切り替わり、直接socketcall()を呼び出せる。つまり、64bitのコンテナやバイナリを使っていても、この経路を利用される可能性があるのだ。

結果として、v29.4.2へのアップグレード後に多数の32bitアプリケーションがネットワークに接続できなくなるというインシデントが発生した(GitHub Issue: moby/moby#52506)。セキュリティパッチが新たな機能不全を引き起こすという、運用者にとって最も避けたいシナリオが現実となった。

根本原因:seccompの限界

この問題の本質は、seccompがシステムコール境界でのみ動作する点にある。socketcall()は一つのシステムコール番号の背後に多種の操作を隠蔽する。seccompのフィルタは、その中身である配列のポインタ先を解析できない。これが、seccomp単独では対応できない構造的な限界だ。

Dockerのブログ記事の著者は、「seccompはsocket(AF_ALG)をすべてのシステムでブロックするが、socketcall()に対しては盲目だ」と端的に表現している。この「見えない経路」の存在が、多層防御の必要性を強く示す教訓となった。

v29.4.3 LSMベースの恒久対策

v29.4.3 LSMベースの恒久対策

AppArmorとSELinuxによる多層防御

v29.4.3では、より根本的な解決策としてLinuxセキュリティモジュール(LSM)を活用する方針に切り替えた。AppArmorとSELinuxは、カーネル内部のsecurity_socket_create()コールバックに直接フックする。このコールバックは、socket()経由であれsocketcall()経由であれ、カーネルが実際にソケットオブジェクトを生成する瞬間に必ず呼ばれる。システムコールの入り口ではなく、より深いレベルで制御を行うのだ。

具体的な実装として、AppArmorプロファイルには deny network alg, というルールが追加された。これはAF_ALGアドレスファミリだけを対象に拒否する。SELinux環境向けには、すべてのcontainer_domainタイプに対してalg_socketの作成を拒否するCIL(Common Intermediate Language)ポリシーモジュールが提供され、semoduleコマンドでロード可能だ。

対策の全体像と適用優先度

v29.4.3の防御スタックは、以下の3層で構成されている。seccompによる直接のsocket(AF_ALG)ブロックは防御の一層目として維持しつつ、AppArmorまたはSELinuxによってsocketcall()経由の抜け道を塞ぐ。これにより、どちらか一方の防御層が無効化されても、もう一方がカバーする体制を実現した。

ただし、AppArmorやSELinuxはホストの設定に依存するため、LSMが有効化されていない環境ではsocketcall()経路が無防備なままとなる。この点については、依然としてカーネルパッチが唯一の完全な解決策であることに変わりはない。

STEP 1 Linuxディストリビューションのカーネルパッチを適用する
STEP 2 Docker Engineをv29.4.3以上にアップグレードする(再起動不要)
STEP 3 アップグレード不可ならカーネルモジュールをブラックリスト化する
STEP 4 それも不可ならカスタムseccompプロファイルを適用する

このステップを踏むことで、カーネルパッチの提供を待つ間のリスクを段階的に低減できる。最優先はカーネル修正だが、それが叶わない状況でもDocker Engineの更新だけで強固な緩和策となる。

コンテナセキュリティのための実践的教訓

コンテナセキュリティのための実践的教訓

ランタイム更新のスピードが生む防御力

Copy Failのケースで特筆すべきは、脆弱性の詳細が公表された時点で、主要ディストリビューションの多くはカーネルパッチを提供できていなかった点だ。Ubuntuは記事執筆時点で未対応であり、DebianやRHEL 9が対応を発表した段階だった。この数日間のギャップにおいて、コンテナランタイムの更新は唯一の実用的な緩和策だった。

コンテナ運用においてDocker Engineを最新に保つことは、単なる機能向上のためではない。カーネル脆弱性の公開からパッチ適用までの「空白期間」を埋める、最も迅速な防御手段の一つなのだ。

多層防御の絶対的必要性

このインシデントは「単一の防御層に頼ることの危険性」を端的に示した。seccompは強力だが、システムコールの粒度でしか制御できない。AppArmorやSELinuxはカーネル内部のオブジェクト生成にフックするため、より精密な制御が可能だが、ホストOSの設定に依存する。両者を組み合わせることで初めて、互いの死角を補完できる。

また、v29.4.2のsocketcall()拒否が引き起こした互換性問題は、セキュリティと互換性のトレードオフの難しさを教えている。広範なブロックは新たな問題を生む。可能な限りピンポイントな制御を追求し、やむを得ず広範な制限をかける場合は、その影響範囲を事前に十分評価する必要がある。

単層防御のリスク(Bad)
seccompのみ socket(2)ブロック socketcall()経由で突破
※ seccompはポインタ先を検査できず、抜け道を許す。
多層防御の有効性(Good)
seccomp socket(2)ブロック + AppArmor 両経路でAF_ALG拒否
※ カーネル内部フックにより、システムコールの種類を問わず遮断。

この比較から得られる教訓は明確だ。セキュリティ対策は、異なるレイヤーで相互に補完し合う設計が必須である。一つの仕組みで完璧を目指すのではなく、それぞれの得意領域を理解し、弱点を他の層でカバーする。これこそがコンテナセキュリティの基本原則である。

この記事のポイント

  • CVE-2026-31431はAF_ALGソケットを悪用し、2017年以降のLinuxカーネルに影響する
  • Docker v29.4.2のseccomp修正は32bitバイナリのネットワークを破壊する副次的被害を起こした
  • v29.4.3ではAppArmorとSELinuxを組み合わせた多層防御で選択的なAF_ALG遮断を実現
  • カーネルパッチが最も確実な修正だが、エンジン更新が迅速な緩和策として有効
  • 単一防御層の限界を認識し、複数の技術で死角を補完する設計が今後の鉄則となる
Supabaseプロジェクトをnpmサプライチェーン攻撃から守る7つの防御策

Supabaseプロジェクトをnpmサプライチェーン攻撃から守る7つの防御策

npmエコシステムを狙ったサプライチェーン攻撃が2026年に相次いでいる。5月には、TanStackがGitHub Actionsのワークフローキャッシュを汚染され、正規リリースに悪意あるコードが混入する事件が発生した。Supabaseも同様に、supabase-javascriptというタイポスクワット(入力ミスを狙った偽装パッケージ)がnpm上に現れるなどの標的に遭っている。

同社はこの事態を受け、プロジェクトの保護に向けた社内横断の対応を開始し、誰もが参照できる公式ガイドを公開した。本記事では、そのガイドの中核を抜粋し、攻撃の構造と開発者が今すぐ実施すべき防御策を具体的に解説する。

npmサプライチェーン攻撃の3つの典型的な手口

npmサプライチェーン攻撃の3つの典型的な手口

サプライチェーン攻撃は、直接システムに侵入するのではなく、開発者が信頼しているパッケージに悪意あるコードを忍び込ませる。以下が最も一般的な三つの手口だ。

メンテナの認証情報を奪う「アカウント乗っ取り型」

攻撃者がnpmの公開トークンを盗むか、メンテナをフィッシングして乗っ取り、人気パッケージの新版に悪意あるコードを仕込んで公開する。次にnpm installを実行すると、その悪質なバージョンが導入されてしまう。

入力ミスを誘う「タイポスクワッティング型」

本物のパッケージ名から数文字だけ変えた類似名でパッケージを登録し、開発者やAIコーディングエージェントが誤ってインストールするのを待つ。Supabaseの例では、@supabase/supabase-js ではなく supabase-javascript というスコープなしの名前で公開された。AIエージェントがパッケージ名を幻覚(ハルシネーション)して提案することも多く、この手法は脆弱だ。

ビルドパイプラインを悪用する「CI/CD侵害型」

この手口は、GitHub ActionsなどのCI/CDパイプラインの脆弱なワークフローを突く。攻撃者はフォークしたプルリクエストからワークフローのキャッシュを汚染し、次回の正規リリース実行時にそのキャッシュを拾わせて、正規メンテナの署名で悪意あるコードを公開させる。TanStackを襲った攻撃がまさにこれで、セッションメッセンジャーネットワーク経由で機密情報が流出した。

アカウント乗っ取り型
攻撃者がメンテナ権限を奪い、正規パッケージに悪意あるコードを仕込んで公開
タイポスクワッティング型
類似名の偽パッケージを登録し、開発者の打ち間違いやAIの誤提案を誘う
CI/CD侵害型
ビルドパイプラインのキャッシュを汚染し、正規リリースに紛れて悪質なコードが配布される

いずれの手口も、npm install の完了までに環境変数やAWSメタデータ、SSH秘密鍵といった機密情報を根こそぎ奪われる危険がある。

Supabaseが実施するプロジェクト防御策

Supabaseが実施するプロジェクト防御策

Supabaseはこの問題に対し、全社的な対応を開始した。以下が現在進行中の主な取り組みである。

公式セキュリティガイドの公開

同社は、npmセキュリティに関する推奨事項をまとめた単一の正規ガイドページを公開した。エージェントが読み取り可能な形式で、具体的なアクションを指示している。

GitHub Actionsの安全性強化

組織全体で pull_request_target の使用を精査し、アクションのバージョン参照をコミットSHAに固定する強制ルールの適用が最終段階に入っている。

クレデンシャル関連APIへの警告注釈

createClient などの関数にTSDoc(TypeScript向けドキュメントコメント)を追加し、エディタ上でホバー時に機密情報を扱う旨の警告が表示されるようにした。

全チャネルでの啓蒙活動

顧客かどうかを問わず、できるだけ多くの開発者に防御策を届けるため、ブログやコミュニティを通じた情報発信を強化している。

依存関係管理の厳格化

依存関係管理の厳格化

以下に挙げる設定変更は、いずれも数分で完了する。どれか一つでは完全な防御にはならないが、複数積み重ねることで攻撃者が諦めるほどの障壁を築ける。

パッケージマネージャを最新にして公開遅延を設定する

pnpm 11(またはnpm v11相当)にアップグレードし、minimumReleaseAge をデフォルトの24時間より長く設定する。多くの悪意あるパッケージはリリース後24〜48時間以内に検出され削除されるため、3〜7日の遅延を設けると、被害を受ける確率を大幅に下げられる。

# pnpm-workspace.yaml または .npmrc
minimumReleaseAge: 4320  # 分単位、3日

依存バージョンを固定する

^~ による範囲指定は、npmに対して「次のマイナーやパッチを自動的に取り入れて問題ない」と伝えているに等しい。認証情報やネットワーク通信を扱うパッケージでは、必ず正確なバージョン番号を指定しよう。

従来のバージョン指定(Before)
"dependencies": {
  "@supabase/supabase-js": "^2.39.0",
  "axios": "~1.6.0"
}
防御策適用後(After)
"dependencies": {
  "@supabase/supabase-js": "2.39.0",
  "axios": "1.6.2"
}

ロックファイルをコミットし差分を精査する

pnpm-lock.yamlpackage-lock.json は、インストールされた正確なバージョンとハッシュを記録する。攻撃者が同じバージョン番号で悪意あるtarballを差し替えても、ハッシュが一致せずインストールが失敗する。ロックファイルをリポジトリにコミットし、プルリクエストの差分では目的不明な依存関係の変更がないか必ず確認する。

不用なインストールスクリプトを無効化する

サプライチェーン攻撃のペイロードの多くは、preinstall install postinstall といったライフサイクルスクリプトを通じて実行される。ネイティブコードを含むパッケージを必要としないプロジェクトでは、これらをグローバルに無効化する。npmでは npm config set ignore-scripts true または .npmrcignore-scripts=true を記述する。pnpmではAllow Buildsモデルを使って、実際に必要なパッケージだけを許可リストに登録する。

安全なパッケージ導入のための実践

安全なパッケージ導入のための実践

パッケージ名を毎回検証する

タイポスクワッティング対策として、以下の点をインストール前に必ず確認する。

  • スコープが正しいか。Supabase公式パッケージはすべて @supabase/ 配下にある。
  • メンテナの一覧が期待通りか。長年維持されてきたパッケージに新しいメンテナが突然加わっていれば警戒信号だ。
  • ダウンロード数とリンク先のGitHubリポジトリが、本物のパッケージとして妥当であること。

CI/CDワークフローを狙った攻撃への対策

CI/CDワークフローを狙った攻撃への対策

ActionsをコミットSHAで固定する

ワークフローで参照するサードパーティアクションは、タグではなくコミットの完全なSHAハッシュ(40文字)で固定する。タグは攻撃者が新しいコードで置き換えられるため安全でない。

- uses: actions/checkout@1f9a0c22da41e6ebfa534300ef656b67ce0c5b94 # v6.0.2

pull_request_target の危険な使い方を回避する

pull_request_target イベントは、プルリクエストのコードをチェックアウトして実行するコンテキストで使うと、攻撃者がリポジトリのシークレットやキャッシュにアクセスできてしまう。TanStackを襲った攻撃はまさにこのパターンだった。PRのコードに触れる処理は必ず pull_request を使用し、pull_request_target はラベリングやコメント投稿など、コードを実行しない信頼済み操作に限定する。

危険なワークフロー(Bad)
on:
  pull_request_target:
    types: [opened, synchronize]
jobs:
  build:
    - uses: actions/checkout@v4
      with:
        ref: ${{ github.event.pull_request.head.sha }}
安全なワークフロー(Good)
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  build:
    - uses: actions/checkout@v4

インシデント発生時の即応策

インシデント発生時の即応策

クレデンシャルのローテーションと監査

もし疑わしいパッケージを含む環境で npm install を実行してしまったら、そのマシンを危殆化したと見なし、到達可能なすべての認証情報(AWS、GCP、Kubernetes、Vault、GitHub、npm、SSH、Supabaseのサービスロールキー)を直ちにローテーションする。Supabaseのダッシュボードでサービスロールキーの使用状況を監査し、不審なアクセスパターンがないかも確認する。半日はかかる作業だが、顧客への被害を防ぐ価値は十分にある。

スキャナの導入で第二の防御線を

Socket.devやnpq、Snykといったツールは、npmレジストリのパッケージをリアルタイムで監視し、怪しい挙動をフラグ付けしてくれる。これらは万能ではないが、基本的な対策をすでに実施しているチームにとって有効な第二の防御線となる。

AIコーディングエージェントに渡すセキュリティチェックリスト

AIコーディングエージェントに渡すセキュリティチェックリスト

以下は、Supabaseが推奨するリポジトリ監査プロンプトだ。Claude CodeやCursorなどに貼り付け、変更内容を必ず確認しながら適用する。プッシュやPR作成、依存関係の自動追加、クレデンシャルのローテーションは自動化せず、必ず人間が承認する。


このリポジトリのnpmサプライチェーン衛生状態を監査してください。以下の変更を適用し、何を行ったかを報告してください。明示的な承認なしにプッシュ、PR作成、新しい依存関係のインストール、クレデンシャルのローテーションは行わないでください。

パッケージマネージャ:
- 古いバージョンならpnpm 11+(または最新のyarn/npm/bun)にアップグレード
- 新バージョンに7日間の公開遅延を設定
  - pnpm: `minimumReleaseAge: 10080` を pnpm-workspace.yamlに
  - npm: `min-release-age=7` を .npmrcに
  - yarn (berry): `npmMinimalAgeGate: '7d'` を .yarnrc.ymlに
  - bun: `minimumReleaseAge = 604800` を bunfig.tomlの[install]セクションに
- ライフサイクルスクリプトをデフォルトで無効化。pnpmではallowBuildsで明示的に許可するパッケージをリスト。
- 非レジストリの透過的依存参照をブロック。pnpmでは`blockExoticSubdeps: true`等を設定。
- パッケージマネージャ自体を正確なバージョンとsha512ハッシュで固定

ロックファイルと依存関係:
- ロックファイルがコミットされていることを確認(gitignoreされていない)
- 認証、シークレット、通信、暗号、ユーザデータを扱う依存関係では^/~を正確なバージョンに置き換え
- Supabase関連のインポートがすべて`@supabase/`スコープか検証。スコープなしの類似名はタイポスクワットとしてフラグ

GitHub Actions(存在する場合):
- すべてのサードパーティアクションのusesを40文字のコミットSHAに固定し、元タグをコメントで残す
- pull_request_targetを使いPRコードをチェックアウトしているワークフローを抽出し、pull_requestへの書き換えを提案
- インストールワークフローに`npm audit signatures`の非ブロッキングステップを追加

人の確認が必要な項目:
- Dependabotアラートとシークレットスキャンが無効なら有効化を提案

レポート:
- ファイル変更ごとに1行の理由付きリスト
- 自動変更せずに人の判断が必要な項目の一覧

この記事のポイント

  • npmサプライチェーン攻撃は、アカウント乗っ取り、タイポスクワッティング、CI/CD侵害の3パターンに大別される
  • Supabaseは公式ガイド公開、GitHub Actions強化、API警告追加などで対策を推進中
  • 即効性のある防御策として、パッケージマネージャの更新と公開遅延設定、バージョン固定、ロックファイル精査、インストールスクリプト無効化、パッケージ名検証、ActionsのSHA固定、pull_request_targetの回避がある
  • 万が一侵害が疑われる場合はクレデンシャル全ローテーションとスキャナ導入で二次被害を防ぐ
  • AIエージェントには安全な監査プロンプトを組み込み、自動変更を人の目でレビューする体制を整える
Prisma Next早期アクセス開始、型安全DBコントラクトとエージェント連携

Prisma Next早期アクセス開始、型安全DBコントラクトとエージェント連携

Prisma Nextの早期アクセスが2026年5月22日に開始された。PostgresとMongoDBを対象に、データベース定義をコントラクトとして記述すれば、マイグレーションや型チェックをフレームワークが自動処理する。エージェントと連携する開発ワークフローにより、データ層の構築速度が大幅に向上する見込みだ。

開発者がコントラクトを書くと、あとはPrisma Nextがデータベースマイグレーション、クエリの型検査、エラー時の意味のあるメッセージを生成する。エージェントがコードを提案し、型検査を通過することで、安全なクエリが担保される仕組みだ。

1行のコマンドで始まるオンボーディング

1行のコマンドで始まるオンボーディング

新しいフレームワークを習得するには、ドキュメントを読み、小さなプロジェクトで試行錯誤を重ねる。慣れるまでに数週間を要することも多い。Prisma Nextはその学習曲線を1行のコマンドで解消する。npm create prisma@next を実行すれば、プロジェクトの骨組みと、エージェントを即座に専門家にする多数のスキルが自動生成される。

npm create prisma@next

ドキュメントを熟読する代わりに、エージェントがフレームワークの慣用句をリアルタイムに提示する。質問があればエージェントに尋ねればよく、コマンドの意味や設計の意図をその場で説明してくれる。まるで熟練者が隣で教えてくれているような体験だ。

従来のフレームワーク学習
STEP 1 ドキュメントを通読する
STEP 2 小さなサンプルを作成する
STEP 3 エラーを修正しつつ慣用句を覚える
Prisma Nextのオンボーディング
STEP 1 npm create prisma@next を実行
STEP 2 エージェントがプロジェクトとスキルを構築
STEP 3 質問があればエージェントに聞くだけ
従来は3週間かかっていた学習が、数分で開発を始められる状態になる。

既存プロジェクトへの導入

既存のプロジェクトに追加する場合もnpx prisma-next@latest initで簡単にセットアップできる。その後、エージェントに「読んでいる本を追跡する小さなアプリを構築して」と指示するだけで、スキーマ定義からクエリ作成までを自律的に進める。

コントラクトを書けばデータベース管理はフレームワーク任せ

コントラクトを書けばデータベース管理はフレームワーク任せ

Prisma Nextの中心にあるのが、アプリケーションとデータベースの間の契約であるコントラクトだ。開発者はモデルを定義するだけで、クエリの型検査や自動補完、そしてデータベースマイグレーションの計画と実行をフレームワークに委ねられる。

// contract.prisma
model Book {
  id       String   @id @default(uuid())
  title    String
  author   String
  addedAt  DateTime @default(now())
}
コントラクト(contract.prisma)
アプリケーション 依存関係 データベース 契約に従ってデータを保管
自動化されるタスク
クエリの型検査
自動補完
マイグレーション計画の生成
データベースとの整合性維持
開発者はコントラクトを編集するだけで、データベースとの一貫性が保たれる。

このコントラクトは可読性が高く、更新も容易だ。Prisma Nextではこれが唯一の真実の情報源となる。モデルを変更すると、フレームワークが自動的にマイグレーションを計画し、データベースが常にコントラクトを満たすように調整する。

エージェントによる機能追加の流れ

「著者テーブルを追加し、名前と経歴を持たせ、書籍と紐付けてほしい」といった自然言語での指示をエージェントに与えるだけで、コントラクトが更新される。エージェントは型検査を通過するまで内部でクエリの検証を繰り返し、最終的に安全なコードを出力する。

型安全クエリと高速な反復開発

型安全クエリと高速な反復開発

Prisma Nextのクエリはすべてコントラクトに対して型検査される。開発者(あるいはエージェント)がクエリを書くと、型エラーが即座にフィードバックされる。このループが高速なため、アプリケーションの出荷速度が格段に上がる。

const books = await db.orm.Book
  .where({ addedThisWeek: true })
  .all();

このクエリは、コントラクトで定義されたBookモデルに基づいて型が決定される。エージェントが生成したクエリも同じ型検査を通過するため、人間が書いたコードと同等の安全性が保証される。

クエリ作成の反復ループ
1 エージェントがクエリを書く
2 型検査による即時フィードバック
3 型検査を通過したクエリが確定
4 データベースが対応可能な安全なクエリ
エージェントはツール呼び出し内でこのループを自律的に繰り返す。

マイグレーションを記述する必要がなくなる

マイグレーションを記述する必要がなくなる

データベースのマイグレーションは、多くの開発者にとって最も苦痛を伴う作業の一つだ。構文を正しく記述し、エラーをデバッグし、本番環境で失敗した場合にはさらに時間を費やす。Prisma Nextでは、この負荷から完全に開放される。

マイグレーション作業の変化
従来の方法(Before)
SQLマイグレーションファイルを手動で記述
構文ミスやデプロイ時のトラブルシューティング
本番障害発生時に復旧作業
Prisma Nextの方法(After)
エージェントがコントラクトを編集
フレームワークがTypeScriptマイグレーションを自動生成
トランザクションで安全に適用(Postgres)
エージェントは意図を伝えるだけで、実際のマイグレーションコードは書かずに済む。

TypeScriptで書かれたマイグレーションファイル

生成されるマイグレーションファイルはTypeScriptで記述され、人間が確認しやすい形式だ。prisma-next migration plan を実行すると、ops.json とともにレビュー可能なマイグレーションが出力される。エージェントがSQLを生成するのではなく、フレームワークが決定論的に生成するため、信頼性が高い。

// migrations/app/20260515T0900_add_book_published_at/migration.ts
export default class M extends Migration {
  override describe() {
    return { from: "sha256:…prev", to: "sha256:…next" };
  }

  override get operations() {
    return [
      addColumn("public", "book", {
        name: "publishedAt",
        typeSql: "timestamptz",
        defaultSql: "",
        nullable: true,
      }),
    ];
  }
}

Postgresでは、マイグレーション全体が単一のトランザクション内で実行される。どこかで問題が発生してもロールバックされ、データベースは元の状態を保つ。MongoDBの場合は段階的に安全な手順で計画される。こうした保護機構によって、エージェントに安全に作業を委任できる。

並行ブランチでのマイグレーション競合を自動解決

並行ブランチでのマイグレーション競合を自動解決

複数ブランチで同時にマイグレーションを作成すると、マージ時に順序の衝突が起きることがある。Prisma NextはGitのコミットグラフのようにマイグレーション履歴を扱い、この問題を解消する。

ダイヤモンド型マイグレーショングラフの例
main
branch A のマイグレーション
branch B のマイグレーション
main(両方マージ後)
フレームワークはこの形状を理解し、正しい適用順序を自動的に判断する。prisma-next migration graph で可視化できる。

prisma-next-migration-review スキルをエージェントが活用することで、新しいマイグレーションがmainに到達した場合も、グラフを読み取り、ブランチをリベースし、migration planを再実行する。結果として、衝突なくクリーンにマージできる。複数のエージェントが並行して作業しても、特別な手順を覚える必要はない。

定期的なアップグレードとフィードバックの簡便さ

定期的なアップグレードとフィードバックの簡便さ

Prisma Nextは日々アップデートされており、アップグレードも簡単だ。エージェントに「prisma nextをアップグレードして」と指示するだけで、最新バージョンに更新してくれる。問題が見つかった場合も、エージェントに「これはバグだ」「この機能が欲しい」と伝えれば、適切な報告チャンネルを選び、構造化されたフィードバックを提出してくれる。

コミュニティでの成果発表も歓迎されている。Prismaの公式アカウントで紹介されたり、Prisma NextのREADMEにリンクが掲載される可能性もある。本格的にデプロイする場合、Prisma Postgresの無料枠を活用できる。なお、Prisma Nextはまだ本番環境向けではない。プロダクションには引き続きPrisma 7を推奨するが、一般提供時にはPrisma 8となる予定だ。

この記事のポイント

  • Prisma NextはPostgresとMongoDBに対応し、データベース定義をコントラクトとして扱う
  • 1行のコマンドでプロジェクトをセットアップし、エージェントが即座に開発を支援する
  • 型安全クエリにより、人間とエージェントのどちらが書いたコードも信頼できる
  • マイグレーションはフレームワークが自動生成し、トランザクションで安全に適用される
  • 並行ブランチでの競合もグラフベースの履歴管理で自動解決される
Google I/O 2026 Firebase新機能、AIエージェント統合とCrashlytics Web対応発表

Google I/O 2026 Firebase新機能、AIエージェント統合とCrashlytics Web対応発表

Google I/O 2026でFirebaseは、AIエージェント主導の開発時代に対応する多数の新機能を発表した。

Google Antigravityへのワンクリック統合、Android Studioへの標準組み込み、AI LogicのGemini 3対応、そしてWeb向けCrashlyticsの予告まで、フルスタックアプリ開発の効率を一段と高める内容だ。

これらの更新により、開発者はAIアシスタントとFirebaseバックエンドをシームレスに連携させ、より高速に本番品質のアプリを構築できるようになる。

AIエージェントと統合したフルスタック開発の加速

AIエージェントと統合したフルスタック開発の加速

Google Antigravity 2.0とのワンクリック連携

Google Antigravity 2.0は、エージェントを中心とした開発環境を提供するデスクトップアプリだ。今回、そのオンボーディングプロセスにFirebaseをワンクリックでセットアップする機能が組み込まれた。これにより、Antigravity上でAgent SkillsとMCPサーバーを含む必要なコンポーネントが自動でインストールされ、すぐにFirebaseを利用したエージェント主導の開発を始められる。

STEP 1 開発者が Google Antigravity を起動
STEP 2 オンボーディングで「Firebase を有効化」をクリック
STEP 3 Agent Skills と MCP サーバーが自動インストール
Firebase バックエンドが即座に利用可能に
STEP 4 エージェントが Firestore や Authentication を設定しアプリ生成
※ Antigravity 上で Firebase のプロビジョニングを開始すると、数分でフルスタック環境が整う。

この一連の流れにより、開発者はバックエンド設定にかかる時間を大幅に削減し、エージェントとの対話に集中できる。

Android StudioへのAgent Skills標準搭載

Android開発者にとって大きな変化は、Android StudioのエージェントモードでFirebaseのAgent Skillsがデフォルトで利用可能になった点だ。これまでは個別のセットアップが必要だったが、追加の設定なしで、エージェントがFirestoreの設定、認証コードの生成、セキュリティルールの記述まで支援してくれる。IDE内でFirebaseバックエンドを対話的に構築できるため、ドキュメントを調べる手間が省ける。

従来の開発フロー(Before)
Firebase コンソールで手動設定 → SDK 導入 → 認証コードの手書き → セキュリティルールを自分で作成
Android Studio の新フロー(After)
エージェントモードで指示するだけ → コード生成 → Firestore 設定 → セキュリティルールまで自動提案
手動作業 エージェントによる自動化

開発者の手を動かす作業が大幅に減り、アプリロジックに集中しやすくなる。

Agent Skillsがモバイル開発にも対応

これまでWeb向けに提供されていたAgent Skillsが、Android、iOS、Flutterにも拡張された。さらにCrashlyticsとRemote Configにも対応し、エージェントがクラッシュ解析や設定管理を手助けできる。例えば、IDE内で発生したクラッシュ情報をエージェントが解釈し、修正案を提示するため、ダッシュボードを切り替える必要がなくなる。

開発者 コード記述中にクラッシュ発生 Agent Crashlytics データを解析 提案 修正コードをインライン表示
※ Agent Skills により、IDE を離れずにデバッグが完結する。

Google AI Studioの新機能、Workspace連携とデプロイ簡略化

Google AI StudioでのFirebase統合が一段と進んだ。まず、AI Studioで生成したFirebase対応アプリをワンクリックでCloud Runにデプロイできるようになり、最初の2アプリはGoogle Cloud Starter Tierにより支払い情報不要で無料公開できる。また、自然言語で「受信トレイを整理するアプリを作って」と指示するだけで、Firebase Authentication経由の「Sign in with Google」フローを通じてGmailやGoogleドキュメントといったWorkspaceデータに安全にアクセスし、自分専用の業務アプリを構築できるようになった。

従来のデプロイ(Before)
Cloud Run にデプロイするには、請求情報の登録と手動の設定が必要だった
AI Studio の新デプロイ(After)
ワンクリックで Cloud Run にデプロイ、最初の2アプリは無料(Google Cloud Starter Tier)
※ 支払い情報不要で試せるため、プロトタイプから本番へ気軽に進められる。
STEP 1 AI Studio で「受信トレイを整理するアプリを作って」と自然言語入力
STEP 2 Firebase Authentication を使った「Sign in with Google」で安全に認証
STEP 3 Gmail や Google ドキュメントといった Workspace データにアクセスし、アプリが動作
※ 個人のワークフローに合わせた業務アプリを数行の指示で構築できる。

さらに、マルチエージェントによる本格的な開発に進みたい場合、AI StudioからAntigravityへアプリをエクスポートできる。エクスポート時にはソースコードとAgent Skillsが自動で引き継がれ、Antigravity上で引き続き高度な調整が可能だ。

Firebase AI Logicの進化、Gemini 3対応とセキュリティ強化

Firebase AI Logicの進化、Gemini 3対応とセキュリティ強化

Gemini 3.xモデル対応とグラウンディング強化

Firebase AI Logicは、クライアントサイドから直接Geminiモデルを呼び出すためのSDKだ。今回のアップデートでGemini 3.xシリーズに完全対応し、Google Mapsによるリアルタイムな地理情報のグラウンディング(正確な根拠をもとにした出力)でハルシネーションを抑制する。画像生成ではアスペクト比やサイズのプログラム制御が可能になり、生成に失敗した場合は「finish reasons」で原因(安全性フィルターによるブロックなど)が表示される。また、Gemini Live APIではセッション再開とコンテキスト圧縮がサポートされ、不安定なネットワークでも長時間の対話型アプリが途切れず動作する。

従来の AI Logic(Before)
  • モデル出力の正確性が不安定
  • 画像生成に失敗しても理由が不明
  • 長い会話でネットワーク切断時にリセット
アップデート後(After)
  • Google Maps を使ったグラウンディングでハルシネーション低減
  • 画像生成失敗時に「finish reasons」で原因を表示
  • セッション再開とコンテキスト圧縮で継続的対話が可能
※ より信頼性が高く、プロダクション環境での利用に耐える品質が実現された。

テンプレートのみモードと認証モードでセキュリティ向上

AI機能のセキュリティも大きく強化された。新しい「テンプレートのみモード」では、クライアントが送信できるのはサーバー側に安全に保存されたプロンプトテンプレートのIDだけで、任意の指示を注入できなくなる。まもなく提供開始の「認証モード」では、有効なFirebase Authenticationトークンを伴わない限りGemini呼び出しが実行されない。さらに、Firebase App Checkにワンタイムトークンによるリプレイ攻撃保護が導入され、悪意あるAPI消費を防止する。

安全でない状態(Before)
クライアント 任意のプロンプト送信 Gemini 応答(悪意ある指示の混入リスク)
テンプレートのみモード適用後(After)
クライアント テンプレートIDのみ送信 サーバー上の安全なプロンプト を経由して Gemini が実行
🔒 認証トークン必須 + App Check ワンタイムトークンでリプレイ攻撃防止

ハイブリッド推論のプラットフォーム拡大

ハイブリッド推論機能がiOSでも利用可能になり、Android版はGemma 4に対応した。近くChrome上でのローカルWeb推論も一般提供され、オンデバイスの軽量モデルとクラウドのGeminiを使い分けられる。これにより、プライバシーやコストを最適化しながら、ネットワーク状況に応じて常に最適な推論経路を選択できる。

シナリオ ユーザーが低速ネットワーク環境でアプリを利用
ハイブリッド推論 まずオンデバイスの Gemma 4 で推論実行。負荷が高ければ自動でクラウド Gemini に切り替え。
オンデバイス: 低レイテンシ・プライバシー保護   クラウド: 高精度・大規模処理
※ コストとパフォーマンスを状況に応じて最適化できる。

エンタープライズインフラとの統合とA/B Testingの強化

エンタープライズインフラとの統合とA/B Testingの強化

Application Design Center向けFirebaseテンプレート

Google CloudのApplication Design Center(ADC)に、Firebaseのフルスタックテンプレートが登場した。このテンプレートはFirestore(セキュリティルール付き)、Firebase Authentication、Firebase AI Logicを事前構成済みで、数クリックでプロジェクトに追加できる。ADC内で他のGoogle Cloudリソースと同じ管理モデルでFirebaseを扱えるため、大規模なクラウドインフラとモバイル・Webバックエンドを統一的に運用できる。

手動でのインフラ構築(Before)
Firestore、Auth、AI Logic を個別にプロビジョニングし、IAM やセキュリティルールを設定する必要があった
ADC テンプレート活用(After)
数クリックで事前構成済みの Firebase フルスタックがデプロイされ、Google Cloud リソースと統合管理

A/B Testingのリッチターゲティング

Firebase A/B Testingの実験作成画面が強化され、より細かいユーザーセグメントを指定できるようになった。Remote Configのリアルタイム配信と組み合わせることで、カスタムシグナルにもとづく柔軟な条件設定が可能になる。このアップデートは段階的にロールアウトされる。

Web向けCrashlyticsが登場、フロントエンドのエラー監視が可能に

Web向けCrashlyticsが登場、フロントエンドのエラー監視が可能に

従来Crashlyticsはモバイルアプリ専用のクラッシュレポートツールだったが、Web版が間もなく提供開始される。このWebサポートはGoogle Cloud Observability Suite上に構築され、エラー情報やトレースがCloud LoggingとTraceに一括保存される。モバイルとWebの両方のデータを統合的に分析できるようになり、将来的にはクライアントからサーバーまでのエンドツーエンドデバッグが実現する。開発者はCloud Observabilityのアラート機能やカスタムダッシュボードを活用し、ユーザー体験への影響を詳細に把握できる。

従来の Crashlytics(Before)
iOS アプリ Android アプリ → クラッシュレポート
❌ Web アプリのエラーは監視対象外
Crashlytics for Web 追加(After)
モバイル Web アプリ → Google Cloud Observability に統合
✅ クライアントとサーバーのエンドツーエンドデバッグが可能
※ アラートやカスタムダッシュボードで web のユーザー影響を把握

Firebaseが描くエージェント時代の開発基盤

Firebaseが描くエージェント時代の開発基盤

今回のアップデート群は、Firebaseが単なるモバイル向けBaaSから、AIエージェントを中心としたフルスタック開発プラットフォームへ進化していることを示している。Google AntigravityやAI Studioといったエージェント環境との統合、SQL不要の自然言語操作、そしてWebを含む包括的なオブザーバビリティにより、開発者は「何を作りたいか」に集中できるようになる。Firebaseは、エージェント主導のアプリ開発とクラウドのインフラ力を結ぶ架け橋として、今後もアップデートを続ける見込みだ。

この記事のポイント

  • Google I/O 2026でFirebaseはAIエージェントとの統合を大幅に強化、Google AntigravityやAndroid Studioにワンクリックで組み込めるようになった
  • Agent Skillsがモバイル(Android、iOS、Flutter)に対応し、CrashlyticsやRemote Configの設定もエージェント任せにできる
  • Google AI Studioでは、Firebase Authenticationを使ったWorkspaceデータ連携が自然言語で可能になり、ワンクリックでCloud Runに無料デプロイできる
  • Firebase AI LogicがGemini 3モデルに対応し、グラウンディングやハイブリッド推論で精度とコストを最適化。セキュリティ面でもテンプレート専用モードやApp Check改善が加わった
  • Web向けCrashlyticsが間もなく登場し、モバイルとWebを横断したエラー監視・デバッグがGoogle Cloud Observabilityと統合される
Node.js 24.16.0 (LTS) 登場、cryptoとテストランナーが大幅進化

Node.js 24.16.0 (LTS) 登場、cryptoとテストランナーが大幅進化

2026年5月21日、Node.js 24.16.0(コードネーム Krypton)が長期サポート(LTS)版としてリリースされた。

このバージョンでは、cryptoモジュールへのUUID v7サポート追加、debuggerへの式プローブ機能、HTTPクライアントの安全性強化、テストランナーの大幅な機能拡張など、実務に直結する複数の改善が含まれている。

本記事では、これらの新機能と内部改善を実装例とともに詳しく解説する。

UUID v7がNode.js標準機能に

UUID v7がNode.js標準機能に

今回のリリースで最も注目すべき追加機能のひとつが、crypto.randomUUIDv7()の実装だ。UUID v7(Universally Unique Identifier version 7)は、タイムスタンプベースの一意識別子であり、従来広く使われてきたランダムベースのUUID v4とは根本的な設計が異なる。

UUID v7とは何か

UUID v7は、RFC 9562で標準化された新しいUUIDバージョンだ。先頭48ビットにUnixタイムスタンプ(ミリ秒単位)を含み、続いてランダムビットが配置される。この構造により、生成時刻に基づいた自然なソート順が得られる。

データベースのプライマリキーとしてUUIDを使用する場合、v4ではランダムな値のためインデックスの断片化が発生しやすかった。一方、v7では時系列順に並ぶため、B-treeインデックスの効率が大幅に改善する。具体的には、書き込み性能が最大40〜60%向上したとの報告もある。

crypto.randomUUIDv7()の基本的な使い方

Node.js 24.16.0では、以下のようにシンプルに呼び出せる。

const { randomUUIDv7 } = require('node:crypto');

console.log(randomUUIDv7());
// 例: 0193c548-d70c-7a4a-b17b-3c2b12e5c6f1

戻り値は標準的なUUID文字列形式(8-4-4-4-12のハイフン区切り)で、第三フィールドの先頭ニブルが7になる点がv7の特徴だ。

従来のv4に代えてv7を採用するメリットを、概念図で整理する。

従来のUUID v4(Before)
550e8400 e29b-41d4 a716 446655440000
全てランダム値のため、インデックスに格納する際の位置が予測できず、B-treeのページ分割が多発する
⚠ 断片化率が高く、書き込み性能に悪影響
UUID v7(After)
0193c548 タイムスタンプ d70c-7a4a b17b-3c2b12e5c6f1 ランダム
先頭48ビットが時刻順で単調増加するため、B-treeへの追加が常に右端付近で済み、ページ分割が最小限になる
✅ インデックス効率が大幅に改善し、書き込みスループットが向上
ランダム値  タイムスタンプ部分  ランダム部分(残り)

上の図では、v4の全ランダム性に対して、v7が時刻情報を含む構造であることを対比している。時系列に沿ったINSERT性能が重要なシステムでは、移行を検討する価値がある。

実運用で注意すべき点

UUID v7は時刻情報を含むため、生成時刻が外部に推測される可能性がある。セキュリティ要件が厳しい環境では、この点を評価した上で採用を判断する必要がある。また、時計の巻き戻しが発生するケースでは単調増加性が保証されないため、Node.jsの実装では内部カウンターで対処している。

デバッグ体験を変えるedit-free式プローブ

デバッグ体験を変えるedit-free式プローブ

Node.js 24.16.0では、node inspectコマンドにedit-free runtime expression probesが導入された。これは、デバッグ対象のコードを一切変更することなく、実行時に任意の式を評価できる仕組みだ。

これまでのデバッグ手法との違い

従来、Node.jsアプリケーションの特定の変数の値や式の結果を確認するには、コードにconsole.log()を挿入するか、デバッガでブレークポイントを設定して手動で評価する必要があった。前者はコード改変と再起動を伴い、後者は手動操作の手間が大きい。

従来方式(Before)
コード修正 再起動 値の確認
コードへのconsole.log挿入が必須。本番環境では使えず、開発中も一手間かかる
式プローブ方式(After)
inspect接続 式を指定 即時評価
ソースコードに一切手を加えず、実行中のプロセスで任意の式の値を取得可能
手動・コード変更が必要な工程  ツール側の自動化工程  結果

式プローブを使えば、稼働中のプロセスに対して外部から評価式を注入できるため、トラブルシュートのスピードが大幅に向上する。特に、再起動が難しい本番環境での障害調査で威力を発揮するだろう。

式プローブの活用シナリオ

たとえば、メモリリークが疑われる長時間稼働プロセスで、特定オブジェクトの参照状況を調査するケースを考えてみる。従来であればヒープダンプの取得と解析が必要だが、式プローブを使えばprocess.memoryUsage()や特定変数の.lengthをその場で評価できる。

この機能の追加は、貢献者のJoyee Cheung氏によるPR #62713に基づいている。V8のインスペクタープロトコルを活用した実装で、Chrome DevToolsのExpression Watchに近い使用感だ。

HTTPクライアントの安全性と利便性の向上

HTTPクライアントの安全性と利便性の向上

Node.jsのHTTPクライアント機能に、2つの重要な強化が加わった。いずれも実際のプロダクションコードの安全性と記述性に直結する改善だ。

ClientRequestのオプションマージ強化

http.ClientRequestの内部で、ユーザーが渡したオプションとデフォルト値をマージする処理が厳格化された。この変更は、プロトタイプ汚染(Prototype Pollution)攻撃のベクトルを塞ぐことを主眼としている。

プロトタイプ汚染とは、Object.prototype__proto__を経由してアプリケーション全体のオブジェクトの振る舞いを改変する攻撃手法だ。Node.jsのHTTPクライアントはリクエストオプションを内部でマージする際、従来はプロトタイプチェーンを適切に処理していなかった。今回のPR #63082で、マージ時にnullプロトタイプオブジェクトを使用するよう修正され、この攻撃経路が遮断された。

従来のマージ処理(Before)
Object.assign({}, defaults, userOptions)
__proto__キー経由でプロトタイプが改変される可能性があった
強化後のマージ処理(After)
safeMerge(defaults, userOptions)
プロトタイプを持たないオブジェクトを使用し、__proto__やconstructorキーを無視

Node.jsのMatteo Collina氏が主導したこの修正は、Semver-Minorに分類されているが、セキュリティ上の重要性は高い。とくにユーザー入力からHTTPリクエストオプションを構築するアプリケーションでは、速やかなアップデートが推奨される。

req.signalでリクエスト中断が容易に

もう一つの改善は、http.IncomingMessageへのreq.signalプロパティの追加だ(PR #62541)。これはAbortSignalオブジェクトを提供し、AbortControllerと組み合わせることで、リクエストの中断処理をPromiseベースで簡潔に記述できる。

const controller = new AbortController();

const req = http.request(url, { signal: controller.signal });
req.end();

// 5秒後にタイムアウト
setTimeout(() => controller.abort(), 5000);

req.on('error', (err) => {
  if (err.name === 'AbortError') {
    console.log('リクエストが中断されました');
  }
});

従来はreq.destroy()を手動で呼び出す必要があり、後続のエラーハンドリングも煩雑だった。signalパターンの採用により、fetch APIと同じインターフェースで中断処理を統一的に扱えるようになった点が大きい。

テストランナーが実戦的な機能を獲得

テストランナーが実戦的な機能を獲得

Node.jsの組み込みテストランナー(node --test)は、ここ数バージョンで急速に成熟している。24.16.0では、テスト順序のランダム化、モックタイマーのAPI整備、AbortSignal.timeoutのモックサポートという3つの重要な機能が追加された。

テスト順序のランダム化

Pietro Marchini氏によるPR #61747では、テストファイル内のテスト実行順序をランダム化するオプションが導入された。これは、テスト間の暗黙的な依存関係を炙り出すための機能だ。

node --test --test-randomize-order test/*.test.js

特定の順序で実行されることを前提に書かれたテストは、ランダム化によって失敗する。これにより、グローバル状態への暗黙の依存や、テスト間のデータ共有の問題を早期に発見できる。テクニックとしては、CIパイプラインにランダム実行を常時組み込むことで、テストスイートの堅牢性を継続的に保証できる。

モックタイマーAPIの拡張

テストランナーのモックタイマー機能が、AbortSignal.timeout()にも対応した(PR #60751)。これにより、タイムアウトに依存する非同期処理のテストが、実際の時間を消費せずに実行できるようになった。

STEP 1 テスト内でAbortSignal.timeout(5000)を呼び出す
STEP 2 モックタイマーが即座に5秒後のタイムアウトをエミュレート
STEP 3 実際の5秒間を待たずにAbortErrorが発生

実際のタイムアウト時間を待つ必要がなくなるため、数百のテストを含むスイート全体の実行時間を大幅に短縮できる。テストの信頼性も向上し、CIでの不安定なテスト(flaky test)の削減に寄与する。

テストIDとOpenTelemetry対応

さらに、各テストにtestIdが付与され(PR #62772)、TracingChannelを通じたOpenTelemetryインスツルメンテーションとの統合が可能になった(PR #62502)。テストのトレーシング情報を本番系の監視ツールと統合することで、テスト品質の可視化と傾向分析ができるようになる。

ファイルシステムとストリームの機能強化

ファイルシステムとストリームの機能強化

fsモジュールとストリームモジュールにも、実務のユースケースに即した改善が複数含まれている。

fs.stat()がAbortSignalに対応

Mert Can Altin氏によるPR #57775で、fs.stat()signalオプションが追加された。ネットワークファイルシステム上のファイルをstatする際に、応答が遅い場合のタイムアウト制御が可能になる。

import { stat } from 'node:fs/promises';

const ac = new AbortController();
setTimeout(() => ac.abort(), 3000);

try {
  const stats = await stat('/mnt/nfs/large-file.dat', { signal: ac.signal });
  console.log(stats.size);
} catch (err) {
  if (err.name === 'AbortError') {
    console.error('statがタイムアウトしました');
  }
}

これは、HTTPリクエストの中断パターンと同じAPI設計で、Node.js全体で一貫した中断処理のセマンティクスが浸透しつつあることを示している。

statfsのfrsizeフィールド公開

Jinho Jang氏のPR #62277により、statfsの戻り値にfrsize(フラグメントサイズ)フィールドが追加された。これはファイルシステムの最小割り当て単位を示し、ディスク使用量の正確な計算に利用できる。

import { statfs } from 'node:fs/promises';

const s = await statfs('/data');
const actualSize = Math.ceil(fileSize / s.frsize) * s.frsize;
console.log(`実ディスク消費量: ${actualSize} バイト`);

これまではbsize(ブロックサイズ)しか公開されておらず、一部のファイルシステム(特にZFSやbtrfs)では正確な計算ができなかった。frsizeの追加により、クロスプラットフォームで信頼性の高いディスク容量の見積もりが可能になる。

duplexPairの破壊伝播の改善

stream.duplexPair()は、読み取り側と書き込み側が対になった2つのDuplexストリームを生成するユーティリティだ。Ahmed Elhor氏のPR #61098によって、片方のストリームが破壊(destroy)された場合に、もう片方にもその破壊が伝播するようになった。

これにより、ソケットの模擬テストやプロキシ処理で、一方のストリームがクローズされたにもかかわらず他方が生き続けてメモリリークを引き起こす問題が解決される。streamモジュールの内部的な一貫性を高める重要な修正だ。

util.styleTextの16進数カラー対応

util.styleTextの16進数カラー対応

Guilherme Araújo氏のPR #61556により、util.styleText()に16進数カラーコード(例: #ff5733)の直接指定が可能になった。ターミナル出力のスタイリングにおいて、より繊細な色表現が必要な場面で役立つ。

import { styleText } from 'node:util';

console.log(styleText('#ff5733', '注意: ディスク使用率が90%を超えています'));
console.log(styleText('#4ecdc4', '情報: バックアップが正常に完了しました'));

従来はstyleText('red', ...)styleText('green', ...)のように、限られた色名しか使えなかった。16進数指定のサポートにより、CIログの色分けやCLIツールのブランドカラー適用など、実務での表現力が格段に向上する。

内部実装としては、ターミナルの24ビットカラー(トゥルーカラー)エスケープシーケンスを使用している。サポートしていないターミナルでは近似の8色にフォールバックされるため、互換性の問題も起きにくい。

この記事のポイント

  • Node.js 24.16.0 (LTS) は、crypto.randomUUIDv7()を実装し、データベースのインデックス効率を改善する時系列ソート可能なUUID生成が標準機能になった
  • debuggerにedit-free式プローブが追加され、コード修正なしで実行中のプロセスの式評価が可能になった
  • HTTPクライアントのオプションマージが強化されプロトタイプ汚染攻撃が防止され、req.signalによるAbortパターンが統一された
  • テストランナーでテスト順序ランダム化、モックタイマーのAbortSignal対応、testIdとOpenTelemetry統合が実装された
  • fs.stat()へのsignal追加、statfsのfrsize公開、duplexPairの破壊伝播改善など、ファイルシステムとストリームの実用性が向上した
  • util.styleText()で16進数カラーコードが直接指定可能になり、CLIツールの色表現力が飛躍的に向上した
DockerがカスタムMCPカタログとプロファイルを正式提供、企業のAIツール管理が新段階へ

DockerがカスタムMCPカタログとプロファイルを正式提供、企業のAIツール管理が新段階へ

Dockerは2026年5月15日、MCP(Model Context Protocol)サーバーを管理する「カスタムカタログ」と「プロファイル」の一般提供を開始した。組織はこれらを使ってMCPサーバー群を一元的に管理し、開発者は作業内容に応じたツール構成を簡単に切り替えられるようになる。

この発表の背景には、企業へのMCP導入が進むにつれて「誰がどのMCPサーバーを信頼して使うべきか」という調整コストが急増していた現実がある。Dockerの新機能は、プラットフォームチームが推奨するツール群を「カタログ」として配布し、現場の開発者が「プロファイル」で自由に組み替えるという二層構造でこの課題を解決する。

MCP活用の壁とDockerの解決策

MCP活用の壁とDockerの解決策

MCPはAIエージェントが外部ツールやデータソースと対話するための標準プロトコルだ。ChatGPTのプラグイン機能に相当するが、ベンダーに依存せずオープンな仕様で設計されている。Dockerは2025年後半からMCPサーバーの統合管理機能「MCPカタログ」を提供してきたが、公開サーバーだけでは社内ツールや独自要件に対応しきれないという声が増えていた。

特に大きかったのは「全社で使える信頼済みリストがほしい」というニーズと「開発者個人のワークフローに合わせた構成を使いたい」というニーズのせめぎ合いだ。前者を強めると開発者の自由度が下がり、後者を優先するとセキュリティ基準が守れなくなる。Dockerが今回一般提供を始めたカスタムカタログとプロファイルは、この二つを両立させるインフラにあたる。

カスタムカタログとプロファイルの役割分担

カスタムカタログは「組織が推奨するMCPサーバーの集合」を定義し、OCIアーティファクトとして配布できる仕組みだ。プロファイルは個人がカタログから選んだサーバー群を「コーディング用」「企画用」といった用途別にまとめ、クライアント(Claude Codeなどのエージェント)に切り替えて接続できる。

組織のプラットフォームチーム
Docker MCPカタログ、コミュニティソース、社内開発サーバー
カスタムカタログを作成してOCIレジストリに配布
信頼審査済み、組織として推奨するMCPサーバーを一元管理
現場の開発者
カスタムカタログから必要なサーバーを選択
コーディング用プロファイル
← クライアントを切り替え →
企画用プロファイル
用途に応じたツールだけをエージェントに接続できる

この二層構造によって「組織が定める信頼の枠組み」と「個人が工夫する効率化」が衝突しなくなる点が最大の価値だ。プラットフォームチームはガードレールを引き、開発者はその中で自由にツールを組み替える。

カスタムMCPカタログの作成と配布手順

カスタムMCPカタログの作成と配布手順

Dockerの公式ブログで解説されている手順に沿って、実際にカスタムカタログを作成する流れを見ていこう。ここではDocker Hubをレジストリとして使う例だが、プライベートレジストリにも対応する。

ステップ1 自前のMCPサーバーをイメージ化する

まず、組織内で使いたい独自のMCPサーバーをDockerイメージとしてビルドし、レジストリにプッシュしておく。Dockerの解説では、さいころを振るroll-diceというサンプルサーバーが使われている。stdioで通信する標準的なMCPサーバーであり、Dockerfileからイメージを作成する手順は通常のコンテナ開発と変わらない。

イメージが用意できたら、そのサーバーのメタデータをYAMLファイルに記述する。ファイル名や格納場所は任意だ。

name: roll-dice
title: Roll Dice
type: server
image: roberthouse224/mcp-dice@latest
description: An mcp server that can roll dice

このYAMLにはサーバーの識別名、表示タイトル、Dockerイメージの参照先、説明文が含まれる。実際の運用では、ここにアクセス権限や設定パラメータのメタ情報を追加することも考えられる。

ステップ2 Docker MCPカタログと自前サーバーを束ねる

次に、docker mcp catalog createコマンドを使ってカスタムカタログを作成する。引数にはDocker公式カタログから取り込みたいサーバーと、先ほど用意したYAMLファイルのパスを指定する。

docker mcp catalog create roberthouse224/our-catalog \
  --title "Our Catalog" \
  --server catalog://mcp/docker-mcp-catalog/playwright \
  --server catalog://mcp/docker-mcp-catalog/github-official \
  --server catalog://mcp/docker-mcp-catalog/context7 \
  --server catalog://mcp/docker-mcp-catalog/atlassian \
  --server catalog://mcp/docker-mcp-catalog/notion \
  --server catalog://mcp/docker-mcp-catalog/markitdown \
  --server file://./mcp-dice.yaml

catalog://スキームでDockerの公式カタログから既存のサーバーを取り込み、file://スキームで自作サーバーのメタデータを追加している。このカタログはローカルマシン上にOCIアーティファクトとして作成され、docker mcp catalog showで内容を確認できる。

ステップ3 カタログをレジストリで共有する

作成したカタログは、docker mcp catalog pushでDocker Hubやプライベートレジストリにプッシュすれば即座に共有可能になる。OCIアーティファクトとしての配布は、組織内のリポジトリアクセス権限をそのまま使えるため、追加のインフラ管理が不要だ。

docker mcp catalog push roberthouse224/our-catalog

これで、組織内の他メンバーはDocker Desktopの「カタログインポート」機能か、docker mcp catalog pullコマンドでこのカタログを取得できる。公式カタログにはない社内ツールが含まれている点、すべてのサーバーが組織としての信頼審査を通過している点が、単なる公開カタログとの決定的な違いだ。

カスタムカタログがエンタープライズにもたらす意味

カスタムカタログがエンタープライズにもたらす意味

ここで一歩引いて、この機能が企業のAI活用に何をもたらすかを考えてみたい。単なる「MCPサーバーリストの共有」に見えるが、実際にはもっと大きな変化の起点になる。

第一に、MCPサーバーの発見と評価にかかるコストが大幅に下がる。開発者がインターネット上からMCPサーバーを探して安全性を個別に判断する必要がなくなり、組織が「使ってよいもの」をあらかじめ提示できる。これはソフトウェアサプライチェーン管理の考え方をAIツールに応用したものとも言える。

第二に、プライベートレジストリと組み合わせれば、社内限定のAIツールを企業秘密として保護しながら配布できる。たとえば自社データベースに特化したMCPサーバーを、アクセス権のあるメンバーだけに提供する使い方が想定される。Dockerのブログでも「プライベートカタログ」という方向性が示唆されている。

第三に、OCIアーティファクトという既存の業界標準に乗っていることが地味ながら重要だ。組織はすでにコンテナレジストリの運用ノウハウとアクセス管理の仕組みを持っている。それをそのままMCPに転用できるため、新たに専用の配信インフラを構築する必要がない。

従来のMCPサーバー探し
開発者個人がウェブ検索 → 品質不明、安全性未確認のサーバーを個別に試す
発見コスト大・チーム間でバラつき発生
カスタムカタログ導入後
プラットフォームチームが審査済みリストを配布 → 開発者はカタログから選ぶだけ
信頼性確保・チーム全員が同じ基準で作業開始できる

このようにカスタムカタログは「野良ツールの乱立を防ぎつつ、社内イノベーションを促進する」バランサーとして機能する。とはいえ、カタログで提供されるのはあくまで「選択肢の集合」だ。実際の作業でどのツールをどう組み合わせるかは、次のプロファイル機能が受け持つ。

MCPプロファイルで個人ワークフローを最適化する

MCPプロファイルで個人ワークフローを最適化する

プロファイルは、カタログから選んだMCPサーバー群を「コーディング」「企画」「調査」などの用途別に束ね、任意のAIクライアントに接続できる仕組みだ。特定のプロファイルには必要なツールだけが含まれるため、エージェントのコンテキストウィンドウを無駄に消費しない利点がある。

作業モードの切り替えを数クリックで実現

Docker Desktop 4.63から利用できるプロファイル機能の基本動作はシンプルだ。カスタムカタログを開き、使いたいサーバーを選択して「新しいプロファイル」を作成する。プロファイルには接続先クライアント(Claude Codeなど)を指定できるが、後から付け替えることも可能だ。

たとえば、Playwright、GitHub、Context7を含む「コーディング」プロファイルと、Atlassian、Markitdown、Notionを含む「企画」プロファイルを別々に作っておけば、作業内容に応じてクライアントの接続先を切り替えるだけでツール環境が丸ごと入れ替わる。これまではツールセットを切り替えるたびに再設定が必要だったが、プロファイルによりワンアクションで済む。

設定の保存と再利用で反復作業を削減

プロファイルのもう一つの利点は、MCPサーバーの設定を永続化できることだ。Markitdownサーバーにアクセス可能なディレクトリパスを指定する場合や、GitHubサーバーのうち使うツールをget_meだけに絞る場合など、一度設定した内容はプロファイルに保存される。これにより、毎回手動で同じ設定を繰り返す手間が省ける。

コンテキストウィンドウの最適化という観点では、大量のツールをエクスポートするMCPサーバーに対して「このタスクではツールAとBだけ有効化する」と制限できる点が実用的だ。エージェントの推論性能を落とさず、必要な機能だけに集中させられる。この仕組みは、社内開発するMCPサーバーにリッチな設定オプションを持たせることで、さらに強力な再利用性を発揮するだろう。

コーディングプロファイル
Playwright
GitHub(get_meのみ有効化)
Context7
コンテキストウィンドウ消費: 小
↕ クライアント接続を切り替え
企画プロファイル
Atlassian
Markitdown(アクセスパス制限あり)
Notion
コンテキストウィンドウ消費: 中
※各プロファイルは独立しており、作業内容に合わせて必要なツールだけをエージェントに提供する

上図のように、同じカタログから異なるプロファイルを複数作成し、用途に応じて切り替える運用が基本スタイルになる。この考え方は、VS Codeのワークスペース設定や、ターミナルのプロファイル管理に近い。AIエージェント時代の「作業環境テンプレート」と捉えるとわかりやすいだろう。

プロファイルの共有と今後の展望

プロファイルの共有と今後の展望

プロファイルもカスタムカタログと同様、OCIアーティファクトとしてレジストリで共有できる。docker mcp profile pushでプッシュすれば、チームメンバーはdocker mcp profile pullで即座に同じツール構成を手に入れられる。うまくいった設定を「テンプレート」として展開できるこの仕組みは、プロジェクト立ち上げ時の環境構築コストを大幅に下げる。

docker mcp profile push coding your-namespace/coding

Dockerは今後、以下の方向性でカスタムカタログとプロファイルを拡張していくとしている。

  • ガバナンスとポリシー制御により、承認されたカスタムカタログ以外からのMCP利用を制限
  • カタログとプロファイルのディスカバビリティを向上し、実績のある構成を見つけやすくする
  • プロファイルスコープでのシークレット・設定値管理を強化し、セキュアな代替手段として整備
  • エージェントスキルとの連携により、プロファイルを依存関係として参照するワークフロー

特に最後の「エージェントスキルがプロファイルを依存関係として参照する」という構想は興味深い。たとえば「データ分析スキル」が起動するときに、必要なMCPサーバー構成をプロファイルから自動で引き込むといった使い方が想定されている。これが実現すれば、AIエージェントが自律的に必要なツールを調達して動く世界がさらに近づく。

この記事のポイント

  • DockerがカスタムMCPカタログとプロファイルの一般提供を開始し、企業のAIツール管理に新たな基盤が加わった
  • カスタムカタログは組織が信頼するMCPサーバー群をOCIアーティファクトで配布し、発見コストとセキュリティリスクを同時に下げる
  • プロファイルは個人が用途別にツール構成を保存・切り替えできる仕組みで、コンテキスト最適化にも有効
  • 両方ともOCIアーティファクトで共有可能なため、既存のコンテナレジストリ運用の延長でチーム展開できる
  • 今後のポリシー制御やエージェントスキル連携により、エンタープライズMCPのガバナンス基盤として発展が見込まれる
SupabaseがChatGPT公式アプリに。データベースとEdge Functionsを自然言語で操作可能に

SupabaseがChatGPT公式アプリに。データベースとEdge Functionsを自然言語で操作可能に

SupabaseがChatGPTの公式アプリとして提供を開始した。これにより、ChatGPTの対話画面から直接Supabaseプロジェクトのデータベース管理やEdge Functionsのデプロイが可能になる。コードを書かずに自然言語でインフラを操作できる時代が一歩進んだ形だ。

今回の連携では、全部で29種類のツールが提供される。SQLクエリの実行、テーブルスキーマの設計変更、セキュリティアドバイザーの確認と修正、開発用ブランチの作成とマージなど、データベース運用に必要なほぼすべての操作をカバーしている。対象は全Supabaseプランと、ChatGPTの有料プラン(Plus / Pro / Team / Enterprise)だ。

この記事では、Supabase ChatGPTアプリで実現できること、導入方法、技術的な仕組み、そして国産の類似サービスと比較した実務的な評価を解説する。データベース管理の自動化に興味がある開発者や、Supabaseを使ったプロダクト開発の効率化を目指すチームにとって役立つ情報をまとめた。

ChatGPT側からSupabaseを直接操作できるようになった背景

ChatGPT側からSupabaseを直接操作できるようになった背景

これまでSupabaseの管理は、公式ダッシュボードやCLI(コマンドラインインターフェース)から手動で行うのが一般的だった。開発者であればSQLクライアントを起動し、APIキーを確認し、適切なエンドポイントを叩く。これらの手順に慣れている人にとっては日常的な作業だが、チームに非エンジニアが加わったり、素早いプロトタイピングが求められる場面では操作のハードルが高かった。

一方でChatGPTは、2025年以降、外部アプリとの連携機能を急速に拡充してきた。単なるテキスト生成AIから、実際のサービスを操作する「AIエージェント」としての側面を強めている。この流れの中で、SupabaseがChatGPTの公式アプリとして認定されたのは、両者の方向性が一致した自然な結果といえる。

この連携を支える技術が、MCP(Model Context Protocol / モデルコンテキストプロトコル)だ。MCPは、AIモデルが外部のツールやサービスと安全にやり取りするための標準プロトコルである。ChatGPTはこのMCPを通じてSupabaseのAPIを呼び出し、ユーザーの自然言語による指示を実際のデータベース操作に変換している。

従来のデータベース管理とChatGPT連携の比較

従来のSupabase管理(Before)

開発者 ダッシュボード確認 開発者 SQL作成 開発者 API実行

※非エンジニアが操作できない。ツールの切り替えが発生

ChatGPTアプリ連携後(After)

誰でも 自然言語で指示 ChatGPT MCPで自動実行 Supabase 完了

※対話の中でデータベース操作が完結。非エンジニアも参加可能

この仕組みは、単に検索して情報を得るだけの従来のAIアシスタントとは一線を画す。ChatGPTはSupabaseのAPIを通じて実際にテーブルを作成し、SQLを実行し、Edge Functionsをデプロイする。つまり「調べるAI」から「実行するAI」への進化を象徴する連携だ。

実務におけるインパクト

開発現場では、ちょっとしたデータ確認のためにSQLクライアントを起動する手間が意外に大きい。ChatGPT上で「先週登録したユーザーの数を教えて」と入力するだけで結果が返ってくれば、コンテキストスイッチ(作業の切り替えにかかる認知的負荷)が大幅に減る。また、セキュリティアドバイザーの指摘に対して「修正して」と指示するだけで実際の設定変更が行われる点は、運用負荷の軽減に直結する。

Supabaseの記事によれば、ChatGPTの「プロジェクト」機能と組み合わせることで、特定のSupabaseプロジェクトに会話のスコープを固定することもできる。プロジェクトの参照IDを一度設定しておけば、その後の会話では自動的に正しいデータベースに接続される仕組みだ。

ChatGPTアプリが提供する29種類の操作ツール

ChatGPTアプリが提供する29種類の操作ツール

Supabase ChatGPTアプリには、以下の5カテゴリにわたる29種類のツールが実装されている。いずれも自然言語での指示をChatGPTが解釈し、適切なAPI呼び出しに変換して実行する形式だ。

データベース管理(Database Management)

Postgresデータベースに対するSQLクエリの実行、テーブルスキーマの設計と変更、テーブルや拡張機能の一覧表示、セキュリティに関する推奨事項の取得が含まれる。たとえば「usersテーブルに最終ログイン日時のカラムを追加して」と依頼すれば、ChatGPTが適切なALTER TABLE文を生成し、実行する。

セキュリティアドバイザーの確認機能はとくに実用的だ。RLS(Row Level Security / 行レベルセキュリティ)の設定漏れや、公開すべきでないAPIエンドポイントの検出など、見落としがちな設定項目を自動でチェックし、必要に応じて修正まで行える。

プロジェクト運用(Project Operations)

プロジェクトの作成と一覧表示、コスト見積もりの取得、プロジェクトの一時停止と再開、リアルタイムログへのアクセスといった運用系の操作をカバーする。開発用に一時的なプロジェクトを作成して使い終わったら停止する、といったライフサイクル管理をChatGPT上で完結できる。

ブランチとマイグレーション(Branching and Migrations)

データベースの開発用ブランチ作成、変更のマージ、リベースやリセット、マイグレーションの一覧表示と適用が可能だ。Supabaseのブランチ機能は、Gitを使ったコード管理と同様の考え方をデータベースに適用したもので、スキーマ変更を安全にテストしてから本番環境に反映できる。ChatGPT経由で「開発ブランチを作って、そこに新しいインデックスを追加して」と指示するだけで、一連の作業が実行される。

Edge Functions(エッジファンクション)

サーバーレス関数の一覧表示、デプロイ、管理を行う。Edge Functionsとは、ユーザーに近い地理的に分散したサーバー上で実行される軽量なサーバーレス関数のことで、低レイテンシでの処理が求められるAPIエンドポイントやWebhook処理に適している。ChatGPTに「新規ユーザー登録時にウェルカムメールを送信するEdge Functionを作ってデプロイして」と指示すれば、コードの生成からデプロイまでを自動で処理する。

ドキュメント検索(Documentation)

ChatGPTから直接Supabaseの公式ドキュメントを検索できる。コーディング中に詰まったとき、別タブでドキュメントを開かずに会話の流れの中で解決策を見つけられるのは、開発スピードの向上に寄与する。

29ツールのカテゴリ構成

データベース管理

SQL実行  スキーマ設計  テーブル一覧  セキュリティ推奨

プロジェクト運用

プロジェクト作成・一覧  コスト見積もり  一時停止・再開  リアルタイムログ

ブランチとマイグレーション

開発ブランチ作成  マージ  リベース  マイグレーション適用

Edge Functions

一覧表示  デプロイ  関数管理

ドキュメント検索

Supabase Docsの直接検索

※各カテゴリのツール数はSupabase公式ブログの発表に基づく(2026年5月8日時点)

これらのツールは単独でも有用だが、組み合わせることで真価を発揮する。たとえば「セキュリティアドバイザーを実行して、問題があれば修正用のブランチを作成し、修正後に本番へマージして」という一連の指示を自然言語で伝えられる。従来であれば複数の画面とCLI操作を往復する必要があったフローが、1つの会話で完結する。

利用開始手順と対応プラン

利用開始手順と対応プラン

利用開始はシンプルだ。ChatGPTのアプリディレクトリで「Supabase」を検索するか、直接Supabaseのアプリページにアクセスして認証を行う。ChatGPTにSupabase組織へのアクセスを許可すれば、すぐに使い始められる。

対応しているのは全Supabaseプラン(無料プランを含む)と、ChatGPTの有料プランだ。ChatGPT側はPlus、Pro、Team、Enterpriseのいずれかの契約が必要になる。無料のChatGPTアカウントではこのアプリを利用できない点に注意したい。Supabase側に有料プランの制限はなく、無料枠のプロジェクトでも問題なく連携できる。

Supabaseアカウントをまだ持っていない場合は、supabase.comから無料でプロジェクトを開始できる。作成後、ChatGPTに接続して自然言語での管理を始める流れになる。認証にはSupabaseのアクセストークンが使用され、ChatGPTがユーザーに代わってAPIを呼び出す際の権限管理はこのトークンを通じて行われる。

ChatGPTプロジェクトとの連携で効率をさらに上げる

OpenAIが提供する「ChatGPT Projects」機能を使えば、会話のスコープを特定のSupabaseプロジェクトに固定できる。プロジェクトの参照IDをプロジェクト指示に一度設定しておくと、そのプロジェクト内のすべての会話が自動的に正しいデータベースを参照する。複数のSupabaseプロジェクトを抱えるチームでは、この設定で誤操作を防ぎつつ作業効率を高められる。

技術的な仕組みとMCPプロトコル

技術的な仕組みとMCPプロトコル

この連携の技術基盤となっているのが、MCP(Model Context Protocol)だ。MCPは2024年にAnthropicが提唱し、現在ではOpenAIを含む複数のAIプラットフォームで採用が進んでいるオープンプロトコルである。AIモデルが外部ツールやデータソースとやり取りするための共通言語のような役割を果たす。

MCPの仕組みを簡単に説明すると、AIモデルに対して「このツールはこういう機能を持っていて、こういう引数を受け取る」という定義(ツールディスクリプション)を提供する。ユーザーが自然言語で指示を出すと、AIはその定義を参照して適切なツールを選択し、必要なパラメータを推論して実行する。Supabaseの29ツールも、このMCPの枠組みに沿ってChatGPTに公開されている。

認証にはOAuth 2.0が使われており、ChatGPTがユーザーのSupabaseアカウントに代わってAPIを呼び出す際の権限は、ユーザーが許可した範囲に制限される。すべての操作はユーザーの認可の下で実行され、ChatGPTが勝手にデータベースを変更することはない。また、実行前にはChatGPTが「これからこういう操作をしますがよろしいですか」と確認を求める設計になっており、安全性にも配慮されている。

MCPによるSupabase操作の流れ

STEP 1 ユーザーが自然言語で指示

例「先月の売上を商品カテゴリ別に集計して」

STEP 2 ChatGPTがMCPツールを選択

「execute_sql_query」ツールを呼び出し、適切なSQLを生成

STEP 3 Supabase APIで実行

OAuth認証を通じてユーザーの権限でPostgresにクエリを発行

STEP 4 結果を自然言語で返却

クエリ結果を要約してチャットで表示。必要に応じてグラフ化も提案

※実際の処理では、破壊的操作の前にChatGPTが確認を求める安全機構が働く

特筆すべきは、この仕組みが単なる「自然言語からSQLへの変換」にとどまらない点だ。ChatGPTはSupabaseから返ってきたデータを解釈し、必要に応じて追加の質問をしたり、結果をわかりやすく要約したりする。エラーが発生した場合も、ログを解析して原因を特定し、修正案を提示できる。

セキュリティと権限管理

AIにデータベースの操作権限を与えることに対する懸念は当然ある。SupabaseのChatGPTアプリでは、以下の3層の安全機構が実装されている。1つ目はOAuth 2.0によるスコープ制限で、ChatGPTがアクセスできる操作はユーザーが明示的に許可した範囲に限定される。2つ目は破壊的操作(DROP、DELETE、スキーマ変更など)の実行前確認だ。3つ目は、すべての操作がSupabaseの監査ログに記録される点で、事後的な追跡と検証が可能になっている。

国産データベースサービスとの比較と実務評価

国産データベースサービスとの比較と実務評価

SupabaseとChatGPTの連携は、BaaS(Backend as a Service / バックエンドをサービスとして提供する形態)市場全体に波及効果をもたらす可能性がある。現時点で国内の類似サービスには、このレベルのAI連携を実装しているものは見当たらない。国産BaaSの多くは管理画面のUI/UX改善に注力しており、自然言語による操作という発想自体がまだ新しい。

ただし、実務に導入する際にはいくつかの注意点がある。第一に、ChatGPTが生成するSQLが常に最適とは限らない点だ。複雑なJOINやサブクエリを含むクエリでは、パフォーマンスの観点から人手によるレビューが推奨される。第二に、ChatGPTの有料プランが必要なため、チーム全体で利用する場合はコストの試算が欠かせない。第三に、プロダクション環境での破壊的操作をAIに委ねることのリスクは依然として存在する。スキーマ変更やデータ削除を伴う操作は、ステージング環境でのテストを挟む運用ルールを設けるのが現実的だ。

一方で、この連携が真価を発揮するのはプロトタイピングとトラブルシューティングの場面だ。アイデアを素早く形にしたいとき、あるいは深夜の障害対応で素早く原因を特定したいときに、ChatGPT上でSupabaseを直接操作できる利便性は大きい。とくにスタートアップや少人数チームでは、開発リソースの制約を補う手段として有効に機能するだろう。

今後の展望

SupabaseがChatGPT公式アプリとなったことで、他のBaaSやクラウドサービスにもAI連携の波が広がるのはほぼ確実だ。すでにVercelやCloudflareもAIエージェントとの統合を進めており、2026年後半には「ChatGPTから操作できるクラウドサービス」が標準的な提供形態になっていく可能性がある。

開発者にとっては、コーディングの効率化だけでなく、インフラ管理や運用監視といった領域までAIがカバーする時代が目前に迫っている。Supabaseの今回の発表は、その転換点を象徴する出来事といえる。

この記事のポイント

  • SupabaseがChatGPT公式アプリとして提供開始。チャットからデータベース管理が可能になった
  • SQL実行、スキーマ変更、Edge Functionsのデプロイなど29種類のツールを搭載
  • 全SupabaseプランとChatGPT有料プランで利用可能。無料枠のプロジェクトでも連携できる
  • 技術基盤はMCP(Model Context Protocol)。OAuth 2.0による権限制御で安全性を確保
  • 実務導入ではSQLの最適性確認や本番操作の運用ルール整備が推奨される
Cloudflare IPsecが耐量子暗号に対応、2029年完全移行へ前進

Cloudflare IPsecが耐量子暗号に対応、2029年完全移行へ前進

Cloudflareは、同社のIPsecサービスに耐量子計算機暗号(PQC)を導入し、一般提供を開始した。ハイブリッドML-KEM(FIPS 203準拠)を採用し、CiscoやFortinetといった主要ベンダーの機器との相互接続を確認済みだ。これにより、量子コンピュータによる将来の解読リスクに備えた広域ネットワーク(WAN)の保護を、既存のハードウェアで開始できる。

同社はかねてから目標としていたシステム全体の完全なPQC対応の期限を2029年に前倒ししている。今回のIPsec対応は、TLSトラフィックの3分の2以上がすでにPQCで保護されている状況にネットワーク層が追いつくための、重要なマイルストーンとなる。

耐量子暗号IPsecが一般提供開始となる背景

耐量子暗号IPsecが一般提供開始となる背景

インターネット上の通信の多くは、現在のコンピュータでは解読が困難な公開鍵暗号によって保護されている。しかし、大規模な量子コンピュータが実用化されれば、これらの暗号は簡単に破られてしまう。これが「Q-Day」と呼ばれる転換点であり、想定よりも早く訪れる可能性が指摘されている。

ここで警戒すべきなのが「Harvest-now-decrypt-later(今収集し、後で解読する)」攻撃だ。攻撃者は今日の暗号化された通信データを大量に収集・保存し、将来の量子コンピュータで解読する。サイト間のVPNでよく使われるIPsec通信もこの脅威にさらされてきた。

Webブラウジングの通信を暗号化するTLSでは、すでに2022年からハイブリッドPQCの導入が急速に進んだ。実際、Cloudflareのネットワークに到達するユーザー由来のTLSトラフィックの3分の2以上が、耐量子暗号で保護されている。一方で、企業の拠点間を結ぶIPsecの世界では、相互運用性の確保や標準化の遅れが壁となり、導入が4年ほど遅れていた。

ハイブリッドML-KEMが実現する耐量子暗号

ハイブリッドML-KEMが実現する耐量子暗号

ML-KEMとは何か

今回採用されたML-KEM(Module-Lattice-Based Key-Encapsulation Mechanism)は、量子コンピュータによる攻撃が理論的に困難とされる数学的問題(格子暗号)に基づくアルゴリズムだ。これは、通信の両端が持つ特殊なハードウェアや専用の物理回線を必要としない。標準的なプロセッサ上でソフトウェアとして動作するように設計されている点が、実用上の大きな利点である。

「ハイブリッド」方式の重要性

Cloudflareが実装したのは、IETFのドラフト「draft-ietf-ipsecme-ikev2-mlkem」で規定されるハイブリッド方式である。ハイブリッド方式とは、既存の安全性が十分に検証された古典的なDiffie-Hellman鍵交換と、新しいML-KEMを組み合わせる手法だ。

具体的なハンドシェイクの流れは次のとおりだ。まず、従来のDiffie-Hellman鍵交換を実行して共有鍵を生成する。次に、その鍵を使ってML-KEMの鍵交換を暗号化して実行する。最後に、両方の出力を混合して、実際のデータ通信を保護するセッション鍵を作成する。この二重構造により、仮に将来ML-KEMに未知の脆弱性が見つかったとしても、古典暗号の層が安全性を下支えする。

相互運用性の確立と課題

相互運用性の確立と課題

Cisco、Fortinetとの相互接続に成功

PQCの実装において最大の障壁は、異なるベンダー間での相互運用性の確保だ。Cloudflareの発表によると、今回の一般提供開始に先立ち、以下のネットワーク機器との相互接続テストを完了している。

  • Cisco: バージョン26.1.1以降のCisco 8000シリーズセキュアルーター
  • Fortinet: FortiOS 7.6.6以降を搭載したブランチコネクタ

これらの機器を拠点側に設置することで、Cloudflareのグローバルネットワークとの間に、耐量子暗号で保護されたIPsecトンネルを確立できる。これにより、特別なハードウェアを新たに調達することなく、既存の投資を活かしてセキュリティを強化できる道が開かれた。

標準化の遅れとciphersuite乱立問題

TLSに比べてIPsecでの標準化が遅れた背景には、鍵配送の代替技術としてのQKD(量子鍵配送)への関心が業界の一部にあったことが挙げられる。RFC 8784で規定されたQKDは、量子力学の原理を用いて盗聴を検知するが、専用のハードウェアと物理的な光ファイバー回線が必須だ。これはインターネット規模での展開には根本的に不向きであり、米国NSAや英国NCSCもQKDへの単独依存に警鐘を鳴らしている。

一方で、PQCのソフトウェアベースのアプローチにはこの制約がない。Cloudflareは、インターネットのオープン性と相互運用性を維持するために、PQCの標準化が不可欠であると主張する。

標準化を巡る混乱も導入を遅らせた一因だ。2023年に公開されたRFC 9370は、IPsecで複数の鍵交換を並行実行する枠組みを提供したが、使用すべき暗号スイートを明確に指定しなかった。この隙間を埋めるように、一部のベンダーは「draft-ietf-ipsecme-ikev2-mlkem」が策定される前に独自の暗号スイートを実装して市場に投入した。NIST SP 800-52r2が警告する「暗号スイートの肥大化」が現実のものとなり、結果として相互運用性に支障が生じている。具体的には、Palo Alto NetworksのRFC 9370ベースの実装とは、現時点で相互接続が確立できていないという。Cloudflareは、業界全体が新たなドラフト標準に集約されることで、この問題が解決されることを期待している。

耐量子インターネットに向けたロードマップ

耐量子インターネットに向けたロードマップ

Cloudflareは、2029年までの完全なPQC対応を目標に掲げている。今回のIPsecへのPQC導入は、そのマイルストーンの一つだ。同社は、この機能を顧客に追加コストなしで提供し、特殊なハードウェアを必要とせずに誰もが耐量子セキュリティを利用できる環境を目指している。

しかし、完全な耐量子環境の実現には、まだ解決すべき課題が残る。現在のdraft-ietf-ipsecme-ikev2-mlkemは「通信の暗号化」のための鍵交換を規定しているが、「通信相手の認証」のためのPQC標準はまだ存在しない。認証部分が古典暗号のままであれば、Q-Day以降に攻撃者が他人になりすましてシステムに侵入する「アクティブ攻撃」を防げない。迫る期限を前に、認証のPQC標準化が次の焦点となることは確実だ。

この記事のポイント

  • Cloudflare IPsecがハイブリッドML-KEMによる耐量子暗号(PQC)の一般提供を開始し、2029年の完全移行に向けた一歩を踏み出した。
  • CiscoやFortinetの既存ルーターとの相互運用性を確保し、追加のハードウェア投資なしでHarvest-now-decrypt-later攻撃への対策が可能になる。
  • RFC標準の不在やベンダー間の実装差異によりIPsecのPQC対応はTLSより4年遅れたが、「draft-ietf-ipsecme-ikev2-mlkem」によって相互運用性の基盤が整いつつある。
  • 今後の課題は「通信の認証」をPQCに対応させることであり、真の耐量子セキュリティ実現には標準化コミュニティの継続的な協調が不可欠である。
AIエージェントがCloudflareで自律デプロイ。Stripe連携でアカウント作成からドメイン購入まで完結

AIエージェントがCloudflareで自律デプロイ。Stripe連携でアカウント作成からドメイン購入まで完結

AIエージェントがソフトウェアを開発するだけでなく、本番環境のインフラまで自ら調達し、デプロイを完了させる時代が到来した。Cloudflareは2026年4月30日、AIエージェントがユーザーに代わってCloudflareアカウントを作成し、ドメインを購入し、アプリケーションをデプロイできる新機能を発表した。

この仕組みは決済プラットフォームのStripeが提供する「Stripe Projects」と共同設計された新しいプロトコルによって実現されている。従来は人間が管理画面で行っていたAPIトークンの発行やクレジットカード情報の入力といった作業を、AIが安全かつシームレスに代行する。

開発者は複雑な初期設定に煩わされることなく、AIに指示を出すだけで「ゼロから本番公開まで」を最短距離で駆け抜けられるようになる。これはインフラ構築の在り方を根本から変える可能性を秘めたアップデートだ。

AIエージェントがインフラ構築を担う新時代の幕開け

AIエージェントがインフラ構築を担う新時代の幕開け

コーディングエージェントはプログラムを書く能力には長けているが、これまでは本番環境へのデプロイという壁に直面していた。アプリケーションを公開するには、ホスティング先のアカウント、支払い手段、そして操作のためのAPIトークンの3つが不可欠だからだ。

これまでは人間がダッシュボードにログインし、設定を済ませてからエージェントに情報を渡す必要があった。Cloudflareが導入した新機能は、この「人間による介在」を最小限に抑えることを目的としている。

開発者の手作業をゼロにするStripe Projectsとの連携

今回の機能の中核にあるのが、Stripeとの提携による「Stripe Projects」だ。これはAIエージェントが複数のサービスを組み合わせてプロジェクトを立ち上げるためのプラットフォームである。開発者がStripeのアカウントを持っていれば、それを認証の基盤として利用できる。

エージェントはユーザーの許可を得た上で、Cloudflareのアカウントを自動的にプロビジョニング(準備)する。もしユーザーがすでにCloudflareのアカウントを持っている場合は、標準的なOAuthフローを通じてアクセス権が譲渡される。これにより、APIキーのコピペという原始的な作業から解放される。

1. 従来のワークフロー(人間主体)
アカウント作成(手動)
カード情報登録(手動)
APIキー発行とコピペ(手動)
ドメイン検索と購入(手動)
2. 新しいワークフロー(AIエージェント主体)
認証とアカウント自動生成
支払いトークンの自動受け渡し
ドメインの自律取得とデプロイ
手動作業  エージェントによる自動化

上記の図が示すように、人間が介入すべきポイントは「AIへの指示」と「最終的な承認」だけに集約される。これにより、開発のリードタイムは劇的に短縮されるだろう。

プロトコルを支える3つの柱

プロトコルを支える3つの柱

AIエージェントが自律的に動くためには、単にAPIを叩くだけでは不十分だ。CloudflareとStripeは、エージェントが環境を理解し、権限を得て、支払いを実行するための3つの要素をプロトコルとして定義した。

サービスカタログからの自律的な発見

まず重要になるのが「Discovery(発見)」だ。エージェントは、利用可能なサービスが何であるかを知る必要がある。新しいプロトコルでは、CloudflareなどのプロバイダーがREST APIを通じてサービスカタログをJSON形式で提供する。

エージェントはユーザーの要望に基づき、このカタログから最適なサービス(ドメイン登録、ストレージ、コンピューティングなど)を選択する。人間が「どのメニューから選ぶか」を悩む必要はなく、エージェントがタスク達成に最適な道具を自ら選び出す仕組みだ。

認証とアカウントの即時発行

次に「Authorization(認証)」だ。Stripeがアイデンティティプロバイダーとして機能し、ユーザーの身元を保証する。Cloudflareはこの情報を基に、未登録のユーザーに対しては即座にアカウントを発行する。

発行された認証情報はStripe Projects CLIによって安全に保管され、エージェントはそれを使ってCloudflareのAPIを操作する。この一連の流れにおいて、ユーザーがサインアップフォームに入力する手間は一切発生しない。

クレジットカード情報を渡さない安全な決済

最も懸念されるのは「Payment(支払い)」の安全性だろう。AIにクレジットカード番号を教えるのはリスクが高い。そこでこのプロトコルでは、カード情報の代わりに「支払いトークン」を使用する。

Stripeから発行されたトークンをCloudflareに渡すことで、エージェントは実際のカード番号に触れることなく、有料プランの購読やドメインの購入を実行できる。決済の利便性とセキュリティを両立させた設計となっている。

実際のワークフローとCLIでの操作感

実際のワークフローとCLIでの操作感

この新機能を利用するには、Stripe CLIと専用のプラグインが必要になる。セットアップが完了すれば、ターミナルから簡単なコマンドを実行するだけでプロジェクトを開始できる。Cloudflareのブログでは、具体的な手順が紹介されている。

Stripe CLIを用いたプロジェクトの初期化

まず、以下のコマンドでプロジェクトを初期化し、Stripeにログインする。これがすべての作業の起点となる。

stripe projects init

その後、AIエージェントに対して「新しいドメインを取得してアプリをデプロイしてほしい」と指示を出す。エージェントは自ら stripe projects catalog コマンドを叩いてCloudflareのドメイン登録サービスを見つけ出し、購入プロセスを開始する。

もしStripeアカウントに支払い方法が登録されていない場合は、エージェントがユーザーに対してカード情報の追加を促すプロンプトを表示する。人間はエージェントが提示した確認事項に対して「Yes」と答えるだけで、裏側で複雑なインフラの紐付けが完了する。

セキュリティとガバナンスへの配慮

セキュリティとガバナンスへの配慮

AIに支払権限を与えることには、慎重な意見も多い。「エージェントが勝手に高額なドメインを大量購入したらどうするのか」という懸念は当然の反応だ。この問題に対処するため、プロトコルには厳格な制限が設けられている。

予算制限と予算アラートによる暴走防止

Stripe Projectsでは、デフォルトで1つのプロバイダーに対して月額100ドルという支出上限が設定されている。エージェントがこの上限を超えて勝手に課金することはできない仕組みだ。

さらに上限を引き上げたい場合は、ユーザーが明示的に設定を変更し、Cloudflare側で予算アラート(Budget Alerts)を設定する必要がある。これにより、AIの自律性を保ちつつ、予期せぬコスト増大を防ぐガバナンスが効いている。

💡 セキュリティのポイント
エージェントは実際のクレジットカード番号を見ることはできない。また、デフォルトの「100ドルの壁」があるため、AIのバグや指示ミスによる致命的な損失を回避できる。

独自分析。インフラのコモディティ化とエージェントOSの加速

独自分析。インフラのコモディティ化とエージェントOSの加速

今回のCloudflareの動きは、単なる利便性の向上に留まらない。筆者は、これがインフラの「完全な抽象化」に向けた決定的な一歩であると考えている。かつて開発者はサーバーを自前で立てていたが、クラウドが登場し、さらにサーバーレスへと進化した。そして今、インフラは「AIが勝手に調達するもの」へと変貌しようとしている。

ここで重要なのは、Stripeが単なる決済手段ではなく、Web上の「アイデンティティ(身元)」のハブとして機能し始めている点だ。Stripeでログインしていれば、CloudflareもPlanetScaleもNeonも、あらゆるクラウドサービスが即座に利用可能になる。これは、Web全体が1つの巨大なオペレーティングシステム(OS)のように振る舞い、AIエージェントがその上で自由にリソースを操作できる環境が整いつつあることを意味する。

開発者の役割は、コードを書くことよりも「AIにどのようなビジネスロジックを実現させたいか」を定義することへとシフトしていくだろう。インフラの設定ミスやAPIトークンの管理漏れといった「非本質的なトラブル」から解放される未来は、すぐそこまで来ている。

この記事のポイント

  • AIエージェントがCloudflareのアカウント作成、ドメイン購入、デプロイを自律的に行えるようになった。
  • Stripe Projectsとの連携により、OAuth認証と支払いトークンを用いた安全なプロトコルが構築されている。
  • 人間はダッシュボードを操作することなく、CLIとAIへの指示だけで本番環境を構築できる。
  • 月額100ドルのデフォルト支出制限により、AIの暴走による高額請求を防ぐ仕組みが備わっている。
  • インフラの調達が自動化されることで、開発者はより高度なアプリケーション設計に集中できるようになる。