タグアーカイブ AIエージェント

Cloud Run instances登場!AIエージェントを月額6ドル弱で常時稼働

Google Cloudが2026年8月27日、常時稼働するAIエージェント向けの新サービス「Cloud Run instances」をプレビュー公開した。サーバーレスの利便性を保ちながら、単一インスタンスを長期間動かし続けるための専用ランタイムだ。

1vCPU・1GiBメモリの構成なら、30日間連続稼働して月額5.70ドル。従来の専用VMと比較すると運用コストと管理負担を大幅に抑えられる。

パーソナルAIエージェントを自宅のPCや専用サーバーで動かしていた開発者にとって、クラウド移行の有力な選択肢になる。本記事ではCloud Run instancesの特徴、料金構造、実際のデプロイ手順までを解説する。

Cloud Run instancesの基本と既存サービスとの違い

Cloud Run instancesの基本と既存サービスとの違い

Cloud Run instancesは、Google Cloudのサーバーレスコンテナ基盤であるCloud Runの新しい実行モードだ。既存のCloud Run servicesが高スループットなWebサービス向けに設計されているのに対し、Cloud Run instancesは「1つのインスタンスを確実に動かし続ける」ことに特化している。

主な特徴は次の4つにまとめられる。

  • オートスケーリングなしの単一インスタンスのみを実行する
  • 最大7日間の連続実行と自動再起動ポリシーを標準で備える
  • 更新や再起動後も変わらない固定HTTPS URLが発行される
  • 使わないときは停止し、必要なときに再開できる
Cloud Run services(既存)
Webサービス向け、オートスケーリング対応
リクエスト停止時にスケールゼロで終了
Cloud Run instances(新サービス)
AIエージェント向け、単一インスタンスを継続実行
最大7日間連続、自動再起動、固定HTTPS URL
従来の専用VM
24時間365日課金、OS管理が必要
ファイアウォールやHTTPS設定を自力で構築

3つの実行環境の違いを比較した図だ。Cloud Run instancesは既存Cloud Runと専用VMの中間的な位置づけで、サーバーレスの手軽さと常時稼働の確実性を両立している。

既存のCloud Run servicesとの決定的な違い

Cloud Run servicesは、リクエストが途絶えるとインスタンスがスケールゼロになる。これは高トラフィックなWeb APIには効率的だが、常に1つのコピーが動き続けることを期待するAIエージェントには不向きだ。一方、Cloud Run instancesはオートスケーリングを行わず、指定した設定のインスタンスを1つだけ動かし続ける。これが最大の設計上の違いになる。

なぜAIエージェントに最適なのか

なぜAIエージェントに最適なのか

OpenClawやHermesといったパーソナルAIエージェントは、継続的に動作し、通常は一度に1人のユーザーにしかサービスしない。これらの特性は、ステートレスな高スループットWebサービスとはインフラ要件が大きく異なる。

OpenClawは、ユーザーの代わりにさまざまなタスクを実行するオープンソースのパーソナルAIエージェントだ。使うほど学習して賢くなる。多くのOpenClawユーザーは最初に自分のノートPCで実行し始めるが、ノートPCがスリープするたびに停止してしまう問題に直面する。ここでクラウド上の常時稼働環境が必要になる。

従来の選択肢の問題点

専用VMを借りる方法もあるが、24時間365日の課金、OSのアップデート管理、ファイアウォールのポート開放、HTTPSエンドポイントの構築といった手間が発生する。Cloud Run instancesはこれらの管理タスクをクラウド側に任せつつ、低コストで常時稼働を実現する。

ここでのポイントは、AIエージェントのワークロードが「バースト型」であることだ。普段は待機状態でCPUをほとんど使わず、ユーザーが指示を出した瞬間だけ計算リソースを消費する。共有vCPUとバーストバジェットによる課金モデルは、このバースト型の特性と相性が良い。常時フルパワーのCPUを確保する必要がないため、価格を抑えられる。

料金とコスト構造の分析

料金とコスト構造の分析

1vCPU・1GiBメモリのCloud Run instanceを30日間連続稼働させた場合のコストは5.70ドル。共有vCPUとvCPUバーストバジェットを利用して、低く予測可能な価格で連続実行を実現している。

従来の専用VM(Before)
月額 約50〜100ドル
24時間365日課金・OS管理・ファイアウォール設定が必要
💻 常時フルパワーのCPUを占有
Cloud Run instances(After)
月額 5.70ドル
サーバーレスなので管理不要・自動再起動つき
✅ 使った分だけの課金・バースト時のみCPU増強
従来の専用VM  Cloud Run instances

従来の専用VMと比べると、クラウド料金に大きな差がある。30日間連続稼働でわずか5.70ドルという価格は、個人開発者が気軽に試せる水準だ。

価格設定の分析

5.70ドルという価格は、パーソナルAIエージェントの利用シーンを想定した戦略的な設定だ。個人開発者がノートPCの代わりにクラウドでAIエージェントを常時稼働させるには、月額10ドル以下という心理的なハードルが大きい。Cloud Run instancesはこの価格帯を実現したことで、パーソナルAIエージェントのクラウド移行を加速する可能性がある。

OpenClawデプロイの実践手順

OpenClawデプロイの実践手順

OpenClawをCloud Run instancesにデプロイする手順はシンプルだ。設定ファイルをCloud Storageバケットにアップロードした後、1つのコマンドを実行するだけでデプロイが完了する。

STEP 1 OpenClawの設定ファイルをCloud Storageバケットにアップロード
STEP 2 デプロイコマンドを1つ実行
STEP 3 Cloud Run instanceが起動し固定HTTPS URLが発行される
STEP 4 TelegramやWhatsAppなどのメッセージングと連携して対話

デプロイ後のOpenClawは、使いたい限り動かし続けられる。メッセージングアプリと接続してタスクを任せることも、必要なツールと連携させることも可能だ。

SSHアクセスと今後のアップデート

Cloud Run instancesとCloud Run servicesの両方で、SSHアクセス機能が近日中に提供される予定だ。これにより、実行中のコンテナに直接ログインしてデバッグや設定変更ができるようになる。詳しい手順はCloud Runのcodelabで公開されている。

ユーザー事例と今後の展望

ユーザー事例と今後の展望

OffDeal社の導入効果

中小企業向けのAI投資銀行を提供するOffDealは、Cloud Run instancesを長期間稼働するエージェントの主要インフラとして利用している。OffDeal社のLuis Ruiz Morel氏によれば、コールドスタートが88%削減され、実装も非常にシンプルで信頼性が高いとのことだ。

コールドスタート88%削減とは、エージェントが待機状態からタスクを開始するまでの起動時間が大幅に短縮されたことを意味する。AIエージェントの応答性がビジネス成果に直結するユースケースでは、この改善は大きな価値となる。

プレビューからGAへ

Cloud Run instancesは現在プレビュー段階で、パフォーマンスを犠牲にせずに新しい種類のワークロードをコスト効率よく実行する手段として提供されている。今後、GA(一般提供)への移行とともに、より多くのAIエージェントワークロードがこの基盤に集約される可能性がある。

Cloud Run instancesの登場は、サーバーレスコンピューティングの適用範囲を「常時稼働するステートフルなワークロード」にまで広げる動きとして捉えられる。従来のサーバーレスは「イベント駆動・ステートレス・短期実行」が前提だったが、AIエージェントのような新しいワークロードの台頭が、この前提を変えつつある。Google Cloudがこのニーズに素早く応えた形だ。

この記事のポイント

  • Cloud Run instancesは常時稼働するAIエージェント向けの新しいサーバーレス実行環境
  • 単一インスタンスのみ、オートスケーリングなし、最大7日間連続実行
  • 1vCPU・1GiBメモリで30日間連続稼働して月額5.70ドル
  • 固定HTTPS URLが提供され、停止・再開も自由
  • OpenClawを1コマンドでデプロイ可能
  • 近日中にSSHアクセス機能が追加予定
Amazon Bedrock AgentCoreにランタイムインスタンス発表、本番AIエージェント向け永続コンピューティング

Amazon Bedrock AgentCoreにランタイムインスタンス発表、本番AIエージェント向け永続コンピューティング

AWSは2026年8月6日、Amazon Bedrock AgentCoreに新たな計算オプション「ランタイムインスタンス」を追加した。AIエージェントのプロトタイプを本番環境に移行する際、長時間の状態維持やマルチエージェント協調、GPUアクセスといった要求に応える、永続的なマネージドインフラだ。

従来のAgentCore Runtimeでは、マイクロVM上で最大8時間のステートフルな呼び出しが可能だったが、日をまたぐワークフローやOSレベルへの直接アクセスが必要なシナリオには限界があった。ランタイムインスタンスは、14日間のセッション永続化とEC2ベースのフルマネージド環境を提供し、本格的なエージェント運用基盤を実現する。

ランタイムインスタンスが解決する本番運用の3つの課題

ランタイムインスタンスが解決する本番運用の3つの課題

AIエージェントをプロダクションに投入するとき、開発者はインフラの壁にぶつかる。ランタイムインスタンスはその3つの主要な課題を解消する。

長時間の状態維持とセッション永続化

通常のサーバーレス実行環境では、処理が終わるとメモリやストレージが破棄される。エージェントが数時間〜数日にわたる複数ステップのワークフローを扱う場合、途中結果を外部ストレージに退避させるなどの手間が生まれる。ランタイムインスタンスでは、最大14日間の共有セッションストレージが標準で提供される。セッションは停止・再開が可能で、アイドル期間のコストを抑えながら、必要なときに前回の状態から処理を再開できる。

マルチエージェントの同一ホスト協調

現実の複雑なタスクは、コード生成・レビュー・テスト・デプロイといった複数の専門エージェントが連携して初めて完結する。ランタイムインスタンスでは、複数のエージェントを同一のEC2ホストにデプロイし、共有ファイルシステムを介して直接データをやり取りできる。API呼び出しやネットワーク越しのストレージを挟むオーバーヘッドがなく、シームレスな協調が可能だ。

GPUとOSへの直接アクセス

画像認識や動画解析、重い数値計算を伴うエージェントはGPUを必要とする。ランタイムインスタンスはGPUアクセラレーテッドなインスタンスタイプに対応し、OSレベルへのアクセスも提供する。コードのコンパイル、セキュリティスキャン、GUI自動操作など、コンテナだけでは実現しにくいタスクをエージェントに任せられる。

コードライターとレビュアーの連携を実際に見る

コードライターとレビュアーの連携を実際に見る

公式デモでは、自然言語でPythonコードを生成する「コードライターエージェント」と、生成されたコードのバグやスタイルをレビューする「コードレビュアーエージェント」を同じランタイムインスタンス上にデプロイし、協調動作させる手順が紹介された。

このデモのポイントは、2つのエージェントが完全に独立したアプリケーションでありながら、セッションIDで紐づく共有ディレクトリを経由してファイルをやり取りする点にある。外部APIを呼び出すことなく、同一ホストのファイルシステム上で完結するため、レイテンシが極めて小さい。

STEP 1 コードライターエージェントが自然言語プロンプトを受け取る
STEP 2 生成したコードを /tmp/agentcore-session/{session_id}/code.py に書き込む
STEP 3 同じセッションIDで起動したコードレビュアーエージェントがファイルを読み込む
STEP 4 バグやスタイルの問題を指摘したレビュー結果を返す
ライターエージェント  共有セッションストレージ  レビュアーエージェント

各エージェントはStrands Agentsフレームワークと好みのモデル(デモではClaude Sonnet)を使い、単一のPythonファイルに @app.entrypoint デコレータを付けるだけで実装できる。パッケージングもzipまたはコンテナイメージで済み、インフラ管理の負担は大きく軽減される。

セットアップから初回実行までの流れ

セットアップから初回実行までの流れ

ランタイムインスタンスの利用は、大きく3つのステップで完了する。AWSマネジメントコンソールを使う場合の手順を簡潔にまとめた。

  • 容量プロバイダの作成 、 エージェントが稼働するEC2インスタンスのスペックとネットワークを定義する。OS(ARM64またはx86_64)、インスタンスタイプ、VPC、サブネット、セキュリティグループを設定。ストレージはgp3ボリュームがデフォルトで用意される。
  • ランタイムの作成とエージェントのデプロイ 、 コンピュートタイプに「Instances」を選び、先ほど作成した容量プロバイダを紐づける。エージェントのコードをzipでアップロードし、ランタイム(Python 3.11〜3.14)とエントリポイントを指定。IAMロールもコンソールが自動生成する。
  • エージェントの呼び出しと協調 、 デプロイ完了後、コンソールの「Runtime playground」からテスト用のJSONペイロードを送信できる。セッションIDを明示的に指定し、同じIDで別のエージェントを呼び出せば、両者が同一の共有ストレージを使ってシームレスに連携する。

容量プロバイダは一度作成するとOSやインスタンスタイプの変更ができない。本番用と検証用を分けるなど、事前の設計が求められる。

主要スペックと料金モデル

主要スペックと料金モデル
  • 対応OS 、 Linux(ARM64、x86_64)。Windowsは現時点ではサポート外
  • セッション持続 、 最大14日間。停止・再開が可能で、アイドル中のコスト削減に有効
  • ランタイム 、 Python 3.11〜3.14(ネイティブコードに対応)。コンテナイメージのデプロイもサポート
  • GPU 、 対応インスタンスタイプを選択すれば、GPUを使った推論や計算が可能
  • 統合 、 既存のAgentCore API、IAM、監視機能と完全互換。マイクロVMとのハイブリッド構成も取れる
  • 料金 、 使用したEC2インスタンスの標準料金に、AgentCoreオーケストレーションの管理手数料が加算される
  • リージョン 、 米国東部(オハイオ、バージニア北部)、米国西部(オレゴン)、アジアパシフィック(ムンバイ、シンガポール、シドニー、東京)、欧州(フランクフルト、アイルランド)

マイクロVMベースの従来のAgentCore Runtimeとランタイムインスタンスは、同じAPIセットで併用できる。軽量なオーケストレーターエージェントをマイクロVM側に置き、重い処理や永続状態が必要なワーカーエージェントをインスタンス側に委譲するハイブリッド構成が、現実的なアーキテクチャパターンとして紹介されている。

始め方と最初の一歩

始め方と最初の一歩

ランタイムインスタンスを試すには、Amazon Bedrock AgentCoreのドキュメントに掲載されているランタイムインスタンスの公式ガイドを参照し、容量プロバイダの作成から始めるのが近道だ。コンソールの左ナビゲーションから「Runtime」→「Capacity providers」を選び、今回紹介した手順に沿って設定すれば、最初のエージェントデプロイまで数分で到達できる。

この記事のポイント

  • ランタイムインスタンスは、最大14日間のセッション永続化とEC2ベースのマネージド環境を提供するAgentCore新オプション
  • 同一ホスト上でのマルチエージェントファイル共有により、APIを介さないシームレスな協調が可能
  • GPUインスタンスやOS直接アクセスが必要な高度なエージェントワークロードに対応
  • 従来のマイクロVMと組み合わせたハイブリッド構成で、軽量なオーケストレーションと重いバックエンド処理を分離できる
Cloudflare AI Searchがエージェント検索を簡素化、公開エンドポイントと価格プレビュー発表

Cloudflare AI Searchがエージェント検索を簡素化、公開エンドポイントと価格プレビュー発表

Cloudflareは2026年8月6日、AI Searchに大規模な機能拡張を発表した。従来はWorkers AIやVectorize、R2、Browser Runといった複数のプリミティブを組み合わせて独自の検索パイプラインを構築する必要があった。今回のアップデートによりAI Searchがこれらの処理を自動化し、開発者やエージェントが、まるで自前の検索エンジンを持っているかのような感覚で扱えるようになった。

新機能として、複数のWebサイトやファイルを横断して検索できる公開エンドポイントの提供、サイトマップ不要のクロール機能、カスタムドメインによるブランディング、EmDash CMS向けの検索プラグインなどが追加された。さらにプレビュー価格モデルも発表され、デフォルトの埋め込み・リランキングモデルを利用すれば、これらの処理が無料になる予測可能な料金体系が示されている。エージェントが信頼できる情報源から回答を引き出せるインフラが、これまでより格段に手軽になった。

AI Searchの主な機能強化点

AI Searchの主な機能強化点
従来の構成(Before)
開発者 手動組み合わせ Workers AI Vectorize R2 Browser Run
それぞれの設定を個別に管理し、データパイプラインを自前で構築する必要があった
AI Searchで統合(After)
開発者 データソース指定 AI Search が自動処理
クローリング 埋め込み リランキング 検索API
1コマンドでセットアップし、即座に検索エンドポイントが利用可能

AI Searchを導入する前は、ベクトル化したデータの格納先やクローリングの仕組み、リランキングのパイプラインなどを開発者が自前で組み上げる必要があった。しかし今回の強化により、それらの低レベルなサービスを意識せずに済む。結果としてエージェントが信頼できる最新情報を引き出せるインフラが、数分で立ち上がるようになった。

インデックス作成の簡素化

これまでAI SearchでWebサイトをインデックスに追加する際は、サイトマップが必須だった。しかし新たに追加された「Discover」パースオプションを使えば、サイトマップがなくてもページ内のリンクを辿って自動的にコンテンツを収集できる。Cloudflareアカウントに登録されたゾーンであれば、特定のページから始まる全サイトデータを取り込めるようになった。

さらに、HTMLやPDFなどの非構造化データから構造化データまで、幅広いファイル形式に対応した取り込みが可能になった。これにより社内Wikiや製品マニュアルといった多様なデータソースをエージェントの検索対象に加えやすくなっている。

公開検索/MCPエンドポイント

ネームスペースに対して公開URLを有効化すると、/search/mcp のエンドポイントが即座に利用できるようになる。/search は通常のREST APIとして、/mcp はモデルコンテキストプロトコル(MCP)に対応した形で提供される。どちらも認証不要で、複数のインスタンスにまたがる横断検索を1つのリクエストで実行できる。

外部のエージェントやアプリケーションに検索機能を提供したい場合、このエンドポイントをそのまま公開するだけで済む。Cloudflare以外の顧客に自社データへアクセスしてもらうシナリオでも、認証が不要で、URLを渡すだけのシンプルな共有が可能になっている。

EmDashとの統合とbotポリシー

Cloudflareが公開しているOSSのCMS「EmDash」向けに、AI Searchプラグインが提供された。これを導入すると、EmDashで構築したサイト内にセマンティック検索を組み込める。実際にCloudflare BlogやDeveloper Docsもこの仕組みで動いている。

また、AI Searchのクローラは独自のユーザーエージェント「Cloudflare-AI-Search」を使い、各サイトのrobots.txtに従う。ブラウザベースのクローリング機能を使う場合でも、このポリシーは変わらない。サイト運営者がクロールを拒否すれば収集が停止されるため、著作権や利用規約上の配慮が十分になされている。

Cloudflare Dev Stack MCPの実装事例

Cloudflare Dev Stack MCPの実装事例

Cloudflare自身がAI Searchをどう活用しているかを示す好例が、新しく公開された「Cloudflare Dev Stack MCP」だ。これはCloudflareのエコシステム全体(ドキュメント、ブログ、APIリファレンス、コミュニティなど)を横断検索し、コーディングエージェントへ最新の引用付き回答を返す仕組みである。古いトレーニングデータではなく、常にフレッシュな情報を基にコードを生成できる。

インスタンス作成とクロール

CloudflareはDocs、Blog、API Docs、コミュニティ、Astro、Viteなど計10以上のサイトに対して、それぞれ個別のAI Searchインスタンスを作成した。各インスタンスはドメインが異なるが、Cloudflareが所有するサイトデータであるため、統一的な方法でクロールできる。

npx wrangler ai-search instance create cloudflare-community \
  --namespace dev-stack \
  --source https://community.cloudflare.com \
  --type web-crawler \
  --parse-type discover

上記のコマンドでは、--parse-type discover を指定することでサイトマップなしにページを発見するクロールを実行している。この内部ではBrowser Runの/crawl機能が使用され、リンクを辿って再帰的にページを見つけ出す。

Workerを使ったマルチインスタンス統合

10個のインスタンスにまたがる横断検索を実現するため、CloudflareはWorkerを用いたMCPサーバを構築した。wrangler.jsonにAI Searchネームスペースのバインディングを追加し、1つのツール呼び出しで全インスタンスを同時に検索する。

{
  "ai_search_namespaces": [
    { "binding": "AI_SEARCH", "namespace": "cloudflare-stack" }
  ]
}
context.registerTool(
  'search_dev_stack',
  {
    description: 'Search current docs across the Cloudflare stack.',
    inputSchema: z.object({ query: z.string() }),
  },
  async ({ query }) => {
    const res = await context.env.AI_SEARCH.search({
      query,
      ai_search_options: {
        instance_ids: ['developers-cloudflare-com', 'astro', /* ... */],
        retrieval: { max_num_results: 10 },
        reranking: { enabled: true },
      },
    })
    return { content: [{ type: 'text', text: format(res.chunks) }] }
  }
)

この方式により、エージェントが単一のツール呼び出しで全ドキュメントを検索でき、結果にはどのインスタンスから取得されたかのメタデータが付与される。複数の検索先を順に叩く必要がなく、応答速度も一括で処理される。

コード不要の公開エンドポイントも選択可能

Workerを書かずに済ませたい場合、ネームスペースの公開URLを有効化するだけで、すべてのインスタンスにクエリを投げる/searchおよび/mcpエンドポイントが得られる。設定画面からワンクリックで有効化でき、即座に利用を開始できる。Cloudflare自身のMCPサーバもこの公開エンドポイントを活用している。

Workerを使う場合(カスタム制御)
開発者 Worker実装 MCPサーバ 経由で検索
既存アプリやエージェントに検索を組み込む場合に適する
公開エンドポイント(ノーコード)
管理者 ワンクリック有効化 /search /mcp エンドポイント公開
すぐにURLを共有でき、ブラウザやエージェントから直接呼び出せる

コードを書く場合は細かいチューニングやMCPツールとしての統合が可能で、コードを書かない場合は設定画面上の操作だけで外部共有が完了する。どちらの選択肢も提供されている点が、利用者のスキルや要件に応じた柔軟な導入を後押しする。

公開エンドポイントとカスタムドメインで検索を共有

公開エンドポイントとカスタムドメインで検索を共有

AI Searchでは、公開エンドポイントに独自のカスタムドメインを割り当てられる。デフォルトのCloudflare管理URLではなく、search.example.com/mcpといったブランド化されたエンドポイントを用意できるため、サービス提供時の信頼感が高まる。

さらに、検索を限定公開したいケースではCloudflare Accessを介した認証ゲートを追加できる。これによりエンドポイントへのアクセスを許可された人物やエージェントだけに制限し、認証情報を持たない第三者からの不正なクエリを防げる。社内データや顧客限定の検索サービスを安全に運用できる設計になっている。

デフォルト公開URL(無設定)
https://xxx.ai-search.cloudflare.com/search 認証なし
短時間の試験や内部検証には十分だが、ブランド観点では不十分
カスタムドメイン + Access制御(推奨)
search.example.com/mcp Cloudflare Access でログイン必須
ブランド力とセキュリティを両立し、顧客向け公開に最適

このカスタムドメイン機能は、SaaSプロダクトやエージェントサービスを展開する事業者にとってとくに有用だ。自社ブランドのURLで検索APIを提供することで、サービス全体の統一感が生まれ、導入先からの信頼獲得につながる。

プレビュー価格モデルでコストを予測可能に

プレビュー価格モデルでコストを予測可能に

AI Searchは現在ベータ版として無料提供されているが、正式版に向けたプレビュー価格が公開された。課金開始前には十分な通知が行われる予定だ。料金設計の中心にある考え方は「予測可能でスケーラブル」であり、埋め込みとリランキングをデフォルトモデル利用時に無料化することで、トークン数の見積もりに頭を悩ませる必要をなくしている。

料金の主な内訳

  • インジェスト(テキスト): $0.75 / 1Mトークン。月間無料枠5Mトークン。
  • 画像処理アドオン: +$0.50 / 1Mトークン。画像の埋め込みに使用される。
  • ストレージ: $2.00 / GB・月。月間無料枠10GB。
  • セマンティック検索(ハイブリッド+ベクトル): $0.75 / 1,000クエリ。無料枠2,000クエリ。
  • 全文検索: $0.10 / 1,000クエリ。同上の無料枠と共有。
  • 埋め込みとリランキング: 指定モデル利用時は無料。それ以外はWorkers AIの従量課金。

無料枠はインジェスト5Mトークンと検索2,000クエリがそれぞれ一つのプールとしてまとめられており、用途を気にせず使い切れる。埋め込みやリランキングのコストが気にならないため、データ更新や再インデックスの頻度を高めやすい。これは頻繁に情報が変わるナレッジベースをエージェントに与えたい開発者にとって大きなメリットだ。

2万ドキュメント規模の試算例

以下は、2万件の文書(約2,000万トークン)と1,000枚の画像をインジェストし、月間3万回のセマンティッククエリを実行した場合の想定コストである。ワーカーズ有料プランが前提で、埋め込みとリランキングにはデフォルトモデルを使用する。

  • インジェスト(テキスト): 18.1Mトークン × $0.75/1M = $13.58
  • 画像アドオン: 1.1Mトークン × $0.50/1M = $0.55
  • ストレージ: 約1.2GB → 無料枠内で$0
  • 検索: 28,000クエリ × $0.75/1k = $21.00
  • 埋め込み・リランキング: $0
  • 合計: 約$35.13

初月にインジェスト費用がかかるが、2か月目以降は主に検索クエリ分だけ(この例では約$21)で運用できる。ドキュメントの大幅な増加がなければ、ランニングコストを低く抑えられる構造だ。

初月のコスト内訳イメージ
インジェスト $13.58 + $0.55 検索$21
埋め込み・リランキングは無料
2か月目以降の月額
検索のみ 約$21.00
インジェスト費用が不要で、クエリ数に応じた変動

このように、AI Searchのコストは初回のデータ登録が大部分を占め、その後は利用量に比例した検索料金のみになる。大規模なデータベースを抱える場合でも、固定費ではなく使った分だけ支払うモデルのため、予算計画が立てやすい。

AI Searchの導入方法

AI Searchの導入方法

AI SearchはCloudflareダッシュボードから有効化し、すぐに使い始められる。もっとも簡単な導入は、次のwranglerコマンドでインスタンスを作成する方法だ。

npx wrangler ai-search create my-search \
  --namespace my-namespace \
  --source https://my-website.com \
  --type web-crawler \
  --hybrid-search

この1行でWebクローラー型のインスタンスが立ち上がり、ハイブリッド検索(セマンティック+キーワード)が有効になる。クロールが完了すれば、/searchエンドポイントで検索APIとして利用できる。さらに/mcpエンドポイントを使えば、ChatGPTやClaudeなどのモデルが直接ツールとして呼び出せる。

既存のアプリに組み込む場合はWorker経由でバインドし、エージェントと連携させればよい。カスタムドメインやCloudflare Accessを設定すれば、プライベートな検索サービスとしても公開できる。詳しい手順は公式ドキュメントを参照してほしい。

この記事のポイント

  • Cloudflare AI Searchは、複数サービスの組み合わせを自動化し、データ検索基盤をワンストップで提供する。
  • 公開/MCPエンドポイントやカスタムドメインにより、エージェントへの組み込みや外部共有が容易になった。
  • サイトマップ不要のクロールやEmDash CMSとの統合で、あらゆるデータソースを取り込める。
  • プレビュー価格ではデフォルトモデルの埋め込み・リランキングが無料で、予測しやすいコスト構造が示された。
  • wranglerコマンド1行でセットアップが完了し、すぐにエージェント向け検索エンジンとして利用開始できる。
Supabase Evals公開、AIエージェントのコード品質を自動評価する基盤

Supabase Evals公開、AIエージェントのコード品質を自動評価する基盤

Supabaseが2026年7月31日、AIコーディングエージェント向けの評価フレームワーク「Supabase Evals」をオープンソースで公開した。Claude CodeやCodex、OpenCodeといった主要エージェントを使い、実際のSupabaseプロジェクト開発を自動で試行し、その成否を定量的に測る仕組みだ。

このフレームワークは、エージェントがデータベーススキーマの構築やEdge Functionsのデバッグ、RLSポリシーの修正といったタスクをどれだけ正確にこなせるかを評価する。公開されたベンチマーク結果は誰でも閲覧でき、エージェントの得意分野や弱点が数値で把握できる。

なぜSupabaseがこの基盤を作ったのか。AIを使ってSupabase上にアプリを構築する開発者が急増する中、エージェントの「実力」を正確に把握し、改善につなげる必要があった。本記事ではその仕組みと、初期の評価で明らかになったエージェントの弱点、そして今後の展望を解説する。

Supabase Evalsが目指すもの

Supabase Evalsが目指すもの

Supabase Evalsは、AIコーディングエージェントがSupabaseを使った開発タスクを実行する際のパフォーマンスを評価するためのフレームワークだ。ベンチマークテストとリグレッション(回帰)テストの2つのスイートを持ち、エージェントの実力を多角的に測る。

具体的には、エージェントがCLIやMCPサーバー、各種ドキュメントを活用しながらスキーマ設計やEdge Functionsの作成、RLSポリシーの修正などを行う。その結果を「ユーザーが特定のデータにアクセスできるか」「Edge Functionが期待通りのレスポンスを返すか」といった決定論的なチェックと、LLMによる判定(LLM-as-a-judge)でスコア化する。

この基盤は、Supabaseが公開する公式ベンチマークのほか、日次で動作する内部のリグレッションスイートにも利用されている。これにより、新しい機能がエージェントの動作を悪化させていないかを継続的に監視できる。

なぜ今、AIエージェント評価基盤が必要なのか

なぜ今、AIエージェント評価基盤が必要なのか

AIコーディングエージェントを使った開発は日常化しつつある。SupabaseのCLIやMCPサーバー、エージェントスキル、ドキュメントを介してエージェントがプロジェクトを構築するケースが増えてきた。しかし、各エージェントがどこでつまずき、どの機能がうまく使えていないのかを体系的に把握する手段が不足していた。

Supabaseの公式ブログ記事によれば、エージェントが苦手とするパターンを特定し、それを修正した上で再発防止(リグレッション)を確認するサイクルを回すことが目的だ。単一のツールだけではなく、Supabaseが提供するすべてのインターフェースを横断的に評価できる点が特徴である。

従来は開発者自身が手動でコードを書く前提だったため、エージェントに特化したテスト基盤は存在しなかった。Evalsの登場により、AI時代の開発者体験を数値で議論できる土台が整ったと言える。

評価の仕組みとベンチマーク/リグレッションの二層構造

評価の仕組みとベンチマーク/リグレッションの二層構造
ベンチマークシナリオ(幅広さ重視)
少ないシナリオ数でSupabaseの主要な領域をカバーする。結果は公開され、複数のエージェント構成で比較される。
リグレッションシナリオ(深さ重視)
既知の障害パターンに焦点を当て、頻繁に実行される。公開スコアには影響せず、品質管理の内部指標として使われる。
実行環境
ホスト型SupabaseスタックとローカルCLIプロジェクトをコンテナ内で生成する。エージェントは実際のMCPサーバーやCLIを操作する。
判定方法
決定論的チェック(データアクセス可否など)とLLMによる意味評価を併用する。エージェントには一度のリトライが許される。

このフレームワークでは、エージェントが実際のSupabase環境で作業するため、机上の空論ではない実用的な評価が可能だ。テスト結果はWebアプリで可視化され、誰でも確認できる。

初期ベンチマークが明らかにしたAIエージェントの弱点

初期ベンチマークが明らかにしたAIエージェントの弱点

スキル読み込みの効果は想定以上に限定的、ただしドキュメント参照は改善

Supabase Evalsのベンチマーク結果では、エージェントがスキル(エージェント向けの最適化ガイド)を読み込んでいない状態でも、多くのシナリオをクリアできることがわかった。ビルド段階では、Opus 5とKimi K3がスキルなしで100%のスコアを達成している。

スキル読み込みの効果は限定的だが、Sonnet 5は78%から100%へ、GPT-5.6 Solは89%から100%へ、GPT-5.4 miniは78%から89%へと改善した。特に、スキルを有効にするとSupabaseドキュメントの参照頻度が一貫して増え、古い事前学習知識を上書きする必要があるエッジケースで差がついた形だ。

宣言的スキーマを使わず、マイグレーションを手書きする傾向

Supabaseには宣言的スキーマという、データベースの構造を一つのファイルで管理できる仕組みがある。本来は複数のマイグレーションファイルをつなぎ合わせるより効率的だが、エージェントは既に宣言的スキーマが使われているプロジェクトでも、手書きのマイグレーションを作成しようとする傾向があった。

この問題を受け、Supabaseはエージェントスキルの中で「どのワークフローを選ぶべきか」の指針を明確に改訂し、Evalsを使って修正が正しく反映されたことを確認した。

新しいライブラリ「@supabase/server」の発見率が低い

Supabaseは最近、Edge Functionsを安全に書くためのボイラープレートを簡略化する@supabase/serverパッケージをリリースした。しかし、エージェントは依然としてsupabase-jsを使い、手動で認証を検証する方法を選んでしまう。

このためSupabaseは「どのパッケージを選ぶべきか」を解説する専用ガイドを公開し、エージェントの判断材料として提供している。

Postgresベストプラクティススキルの有効化が不安定

Evalsは、エージェントがセッション中にどのスキルを読み込んだかを追跡している。主要な「supabase」スキルはほぼ常に読み込まれるのに対し、Postgresのベストプラクティスを教えるスキルは当初、約1割のシナリオでしか有効化されなかった。

スキルの説明文を具体的なトリガーで書き直した結果、有効化率は60%まで向上したが、それでもOpenAIモデルの方がより安定してスキルを活用する傾向が見られる。

ドキュメント参照の頻度に大きなばらつき

Evalsの実行中、エージェントがSupabaseドキュメントを読む頻度も測定している。CodexベースのエージェントはClaude Codeよりもドキュメントをチェックする傾向があり、最も高性能なOpenAIモデルは毎シナリオ約8ページを読むのに対し、Claude Codeは約2ページにとどまる。

しかもClaude Codeはスキルを読み込んでいても、40%未満のシナリオでしかドキュメントを確認しない。Supabaseはエージェントが必要な情報を確実に見つけられるよう、改善を進めている。

AIエージェント時代のSupabase開発体験を支える展望

AIエージェント時代のSupabase開発体験を支える展望

Supabase Evalsはまだ出発点に過ぎない。今後はエッジケースのカバレッジを広げ、エージェントやプロダクトの進化に合わせて新しいシナリオを追加していく計画だ。スコアリングの精度と安定性も引き続き強化される。

また、内部のリグレッションシナリオのなかで信頼性が確認されたものは、順次公開ベンチマークへと格上げされる方針である。さらに、エージェントがタスクに失敗した際にフィードバックを提出できるCLIコマンドやMCPツールも開発中で、これにより次の改善優先度をデータドリブンに決定できるようになる見込みだ。

AIコーディングエージェントを本格的にプロダクト開発に組み込むチームにとって、Supabase Evalsは「エージェントが何を得意とし、どこでつまずくのか」を数値で判断する貴重な羅針盤になる。公開されたベンチマークはsupabase.com/evalsで誰でも確認できる。

この記事のポイント

  • SupabaseがAIコーディングエージェント向け評価フレームワーク「Supabase Evals」をOSS公開
  • 実際のSupabase環境でエージェントを動作させ、ベンチマークとリグレッションの2層でスコア化
  • 初期のベンチマークでは、スキル無しでも高スコアの一方、宣言的スキーマの無視や新ライブラリの未発見など弱点が判明
  • ドキュメント参照頻度のばらつきやスキル活性化の不安定さも浮き彫りに
  • 今後はエッジケースの拡充やエージェントからのフィードバック収集機能の追加を予定
エージェント開発ライフサイクル(ADLC)がCloudflareで始動。SDLCを超える新たな枠組み

エージェント開発ライフサイクル(ADLC)がCloudflareで始動。SDLCを超える新たな枠組み

ソフトウェア開発のライフサイクル(SDLC)が、AIエージェントの登場によって根本から再定義されようとしている。Cloudflareは2026年8月4日、エージェント中心の新たな開発モデル「Agent Development Lifecycle(ADLC)」の構想と、それを支える具体的なツールセットを発表した。

従来のSDLCは「計画→設計→実装→テスト→デプロイ→保守」という人間中心の工程だった。しかしAIエージェントがコード生成の速度を劇的に高めた結果、周辺の工程がボトルネック化している。ADLCはこの課題を解決し、エージェントがライフサイクル全体を自律的に管理できる環境を提供する。

ADLC(エージェント開発ライフサイクル)とは何か

ADLC(エージェント開発ライフサイクル)とは何か

ADLCは、従来のSDLC(Software Development Lifecycle)をエージェント時代に合わせて再設計した概念だ。SDLCは1975年にランド研究所が提唱した「Systems Development Lifecycle」を起源とし、長年にわたりソフトウェア開発プロセスの標準だった。しかし、AIエージェントがコードを実装する速度は人間の比ではなく、テストやレビュー、デプロイといった他の工程が追いつかなくなっている。

Cloudflare Blogの著者Carlo Daniele氏によると、AIによって「実装」が最速かつ最安になった一方で、他の工程に携わる人々が膨大なプルリクエストやイシューに圧倒されるという逆説的な状況が生まれている。オープンソースメンテナの疲弊や本番環境の不安定化は、まさにこの非対称性の表れだ。

ADLCは、エージェントが実装だけでなく、テスト・デプロイ・監視・改善までを一貫して担うことを前提とする。そのために必要な要件は、プログラムによる操作が可能(Programmatic)、水平スケーラブル、再現可能、リアルタイムのプッシュ型イベント対応、アトミックな変更管理、適切な権限制御、そして自己改善能力の7つに整理されている。

従来のSDLC(人間主導)
計画 設計 実装(人間) テスト デプロイ 保守
ボトルネック: 実装だけが高速化し、他工程が逼迫
ADLC(エージェント主導)
計画 設計 実装 テスト デプロイ 保守・改善
全工程をエージェントが自律的に駆動。人間は監視と方針決定に集中

ADLCへの移行は、単にエージェントにタスクを委譲するだけでは実現しない。Cloudflareが提唱する7要件は、いずれも人間向けに設計された既存の開発基盤では満たせないものだ。次のセクションでは、なぜこのタイミングでパラダイムシフトが必要なのかを掘り下げる。

SDLCからADLCへ なぜ今パラダイムシフトが必要なのか

SDLCからADLCへ なぜ今パラダイムシフトが必要なのか

エージェント時代の「人間ボトルネック」

ChatGPTやClaude、GitHub CopilotといったAIツールの普及により、コード生成のスピードは飛躍的に向上した。ところが開発現場の実態を見ると、生成されたコードのレビューやテスト、本番デプロイは依然として人間が担っている。結果として、プルリクエストの滞留が慢性化し、オープンソースプロジェクトではメンテナが数千件のイシューに対処しきれずに疲弊する事例が相次いでいる。

Cloudflareの見解では、これは「エージェントを部分的にしか使えていない」ことに起因する。実装だけをエージェントに任せ、他の工程を人間が管理するという中途半端な状態が、かえって現場の負荷を増大させているのだ。

自律走行車に学ぶ「全体最適」の視点

Cloudflare Blogの記事では、ADLCの必要性を自律走行車に例えて説明している。人間向けの車にAIを載せただけでは、80%の性能は出せても、残りの20%が致命的な事故を引き起こす。安全に走行するには、LiDARや高性能コンピュータ、遠隔制御システムといった専用設計の技術が必要だ。

ソフトウェア開発でも同じで、エージェントが安全にコードをマージし、本番にデプロイするには、人間向けのCI/CDパイプラインでは不十分だ。エージェント専用のインフラ、トレーシング、権限管理、自己修復の仕組みが求められる。

ここで鍵となるのが、Cloudflare Workflowsとエージェントの組み合わせだ。従来のGitHub Actionsのような線形のパイプラインではなく、動的に分岐し、コンテナやブラウザを立ち上げ、ログを解析しながら自律的にソフトウェアを出荷する「ワークフロー」がADLCの中核を担う。

自律走行車とソフトウェアファクトリーの比較
人間用の車+AI
80%の走行は可能だが、緊急時の判断に限界。専用センサーなしでは安全性を担保できない。
自律走行専用車
LiDARや遠隔制御で99%以上の安全性を実現。専用設計が信頼を生む。
ソフトウェア開発も同じ。人間用パイプライン+AIでは限界があり、ADLC専用基盤が必要。

Cloudflareが提供するADLC基盤の全容

Cloudflareが提供するADLC基盤の全容

Workflowsが実現する動的なCI/CD

Cloudflare Workflowsは、複数のステップをチェーンし、失敗したタスクを自動リトライし、数時間から数週間にわたって状態を保持できるサービスだ。従来のCI/CDパイプラインが静的なYAML定義だったのに対し、WorkflowsはTypeScriptで動的にワークフローを定義できる。

さらにWorkflowsは、エージェントや別のWorkflowを子プロセスとして起動できる。たとえば、毎晩収集したデータをエージェントにレビューさせ、その結果を元に次のステップを動的に決定する、といった高度なオーケストレーションが可能だ。

import { CIWorkflow } from '@cloudflare/ci'

// CIパイプラインの例: 依存関係インストール後、lint/test/typecheck/buildを並列実行
const deps = await ci.runner({
  name: 'install',
  command: 'bun install --frozen-lockfile',
  cache: { inputs: ['package.json', 'bun.lock'] },
});
await Promise.all([
  deps.runner({ name: 'lint', command: 'bun run lint' }),
  deps.runner({ name: 'test', command: 'bun run test' }),
  deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
  deps.runner({ name: 'build', command: 'bun run build' }),
]);
await deps.runner({
  name: 'deploy',
  command: 'bun wrangler deploy',
  cloudflareCredentials: { accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID },
});

このコードは、依存関係のインストールをキャッシュしつつ、後続のlintやテスト、ビルドを並列で実行するパイプラインを簡潔に表現している。Workflowsによって、エージェントが生成したコードを安全に検証し、本番へデプロイするまでの一連の流れを自動化できる。

エージェントの可観測性と自己改善

ADLCにおいて、エージェントの動作を監視し、改善につなげる仕組みは欠かせない。Cloudflareは、OpenTelemetryベースのトレーシングをローカル開発環境(WranglerやViteプラグイン)に組み込み、本番環境と同等の可観測性を提供する。また、Agent Tracesによってエージェントのセッション全体をキャプチャし、パフォーマンス向上に活用できる。

さらに、Feature Flag管理のFlagshipや、段階的デプロイメント(Gradual Deployments)、Browser Runによるヘッドレスブラウザのプログラム操作など、エージェントが自律的にソフトウェアをテストし、リリースするためのプリミティブが一通り揃っている。

ADLCを支えるCloudflareの主要プリミティブ
Workflows 動的なオーケストレーションとエージェント起動
Agent Traces エージェントセッションの完全な記録と分析
Browser Run ヘッドレスブラウザを用いたE2Eテストのプログラム実行
Gradual Deployments トラフィックを徐々に切り替える安全なリリース
Cloudflare MCP Server API駆動のインフラ管理。エージェントが直接リソースを操作可能

エージェントが主導するソフトウェアファクトリーの実践例

エージェントが主導するソフトウェアファクトリーの実践例

Cloudflare自身のエンジニアリング標準化

Cloudflareは自社の全プロダクトとシステムリポジトリにわたり、AIを用いてエンジニアリング標準の遵守を強制している。具体的には、コードレビューや仕様チェックをエージェントが補助し、人間のレビュアーの負荷を軽減する仕組みだ。

これにより、コーディング規約の違反やセキュリティパターンの逸脱を自動検出し、修正案まで提示できる。人間はより創造的な設計判断や顧客との対話に時間を割けるようになったという。

Astroプロジェクトにおけるイシューゼロへの挑戦

また、CloudflareはAstroというオープンソースプロジェクトにおいて、イシューの自動トリアージ、再現、修正を行うシステムを構築した。この「ソフトウェアファクトリー」により、GitHub上のイシュー件数をゼロに近づける試みが行われている。

エージェントがバグレポートを受け取り、自動で再現環境をセットアップし、修正PRを作成する。Workflowsがこれらのステップをオーケストレーションし、テストと検証を経てマージする流れだ。この事例は、ADLCが現実のプロジェクトで有効に機能することを示している。

STEP 1 ユーザーがGitHubにバグレポートを作成
STEP 2 エージェントがイシューをトリアージし、再現環境をセットアップ
STEP 3 修正コードを生成し、PRを作成
STEP 4 Workflowsがテスト・検証を実行し、安全にマージ
Astroプロジェクトにおけるイシュー解決フロー。エージェントとWorkflowsの連携で、手動プロセスを大幅に削減している。

ADLCがもたらす開発現場の未来と課題

ADLCがもたらす開発現場の未来と課題

ソフトウェアファクトリーの民主化

現在、最先端の企業だけがソフトウェアファクトリーを構築できているのが実情だ。Cloudflareは、WorkflowsやAgent Traces、Browser Runといったプリミティブを誰でも使える形で提供することで、この格差を埋めようとしている。小規模なスタートアップでも、ADLCの恩恵を受けられるようにする狙いだ。

具体的には、@cloudflare/ciパッケージによるCI/CDの簡素化や、Flueエージェントフレームワークとの統合によって、複雑なオーケストレーションを少ないコードで実装できるようになっている。

残る課題と人間の役割

ただし、ADLCへの移行には越えるべきハードルもある。エージェントが本番環境に直接変更を加えることへの心理的な抵抗感は依然として強い。Cloudflare自身も、権限の段階的な委譲(エスカレーション)の仕組みや、監査証跡の確保が不可欠だと認識している。

また、エージェントが生成するコードの品質をどう担保するか、未知のエッジケースにどう対応するかは、自律走行車と同じく「99%の壁」をどう突破するかの問題だ。CloudflareはAgent Tracesを通じてエージェントの経験値を蓄積し、時間とともにパフォーマンスが向上する仕組みを描いているが、実運用でのデータ蓄積がこれから本格化する。

それでも、コードを書くだけのエージェントから、ソフトウェアのライフサイクル全体を駆動するエージェントへの進化は、もはや避けられない流れだろう。ADLCは、そのための地図と道路を提供するものだ。

この記事のポイント

  • ADLC(Agent Development Lifecycle)は、従来のSDLCをエージェント中心に再設計した新しい開発モデルである。
  • AIエージェントの実装速度に他の工程が追いつかない「人間ボトルネック」の解決を目指す。
  • Cloudflare Workflowsを中核に、動的でスケーラブルなCI/CDとエージェントオーケストレーションを実現する。
  • Agent TracesやBrowser Runなどのプリミティブが、エージェントの自己改善と安全な本番運用を支える。
  • ソフトウェアファクトリーの民主化により、スタートアップから大企業までADLCの恩恵を受けられる時代が近づいている。
GKE Agent Sandboxがエージェント1台あたりのコストを75%削減する仕組み

GKE Agent Sandboxがエージェント1台あたりのコストを75%削減する仕組み

AIエージェントを本番環境でスケールさせようとすると、すぐにコストとリソースの壁にぶつかる。Google Cloudが2026年7月30日に公開したブログ記事では、Google Kubernetes Engine(GKE)の新機能「GKE Agent Sandbox」とオーケストレーションを組み合わせることで、同一の仮想マシン上で動かせるエージェント数を最大3.5倍に増やし、エージェント1台あたりのコストを最大75%削減できるという検証結果が示された。

エージェントは要求に応じて動作するバースト型のワークロードであり、何もしない待機時間が長い。従来のように固定的なコンピュートリソースを割り当てる方法では、遊休状態のエージェントが貴重なCPUやメモリを消費し続けてしまう。この問題に対するGKEのアプローチを詳しく見ていく。

マイクロVM方式の限界とGKE Agent Sandboxの登場

マイクロVM方式の限界とGKE Agent Sandboxの登場

マルチエージェントを安全に動かすための一般的な方法として、各エージェントを専用のマイクロVM(Kata Containersなど)で隔離するやり方がある。ハードウェアレベルの隔離によってセキュリティを確保する狙いだ。しかしこの方式には大きな落とし穴がある。

マイクロVMはエージェントごとにゲストOSを起動するため、メモリとCPUに無視できないオーバーヘッドが生じる。実際にGoogle CloudのチームがOpenClawプロファイルを使い、48vCPUの標準VMインスタンス(n2-standard-48)上でテストしたところ、61個のエージェントを起動した時点で信頼性が低下し、ヘルスチェックの失敗が頻発し始めたという。

従来のマイクロVM方式(Before)
VMインスタンス 各エージェントに専用のゲストOS
61エージェントで上限 (信頼性低下・ヘルスチェック失敗)
オーバーヘッド大 / 固定リソース割当
GKE Agent Sandbox 利用時(After)
VMインスタンス 軽量サンドボックス(gVisor)で共有
88エージェントで動作 (約44%増加)
オーバーヘッド削減 / 同一VM内で高密度化

これに対してGKE Agent Sandboxは、gVisorというオープンソースのセキュアコンテナサンドボックスを土台にしている。gVisorはユーザー空間カーネル(Sentry)でシステムコールを捕捉・フィルタリングし、ハードウェア隔離に近いセキュリティを実現しつつ、ゲストOSを丸ごと動かす必要をなくした。

結果として、同一VM上で動作可能なエージェント数は88個まで増加。これはベースライン比で44%の密度向上であり、エージェント1台あたりのコストは30%以上削減された計算になる。しかも性能プロファイルはほぼ維持できると報告されている。

この方式が評価を得たのは早く、2026年5月の一般提供開始から4週間足らずで利用量が7倍以上に急増した事実が、その実用性を裏付けている。

遊休エージェントを「凍結」するオーケストレーションの威力

遊休エージェントを「凍結」するオーケストレーションの威力

GKE Agent Sandboxは稼働中のワークロードを効率化するが、遊休状態のエージェントがリソースを占有し続ける問題は残る。そこでカギを握るのが、Kubernetes本来のオーケストレーション機能とGKE Podスナップショットを組み合わせた「凍結・再開」パターンだ。

具体的には、エージェントが待機状態に入ったタイミングでPodスナップショットを作成し、永続ストレージにチェックポイント(凍結)として保存する。これにより物理的なCPUとメモリが解放され、クラスタに返却される。新しいトリガーが届くと、軽量なコントローラやイベントゲートウェイがリクエストを捕捉し、ミリ秒単位でスナップショットからエージェントを再開する。

STEP 1 エージェントが待機状態になる
STEP 2 Podスナップショットを永続ストレージに保存(凍結)
STEP 3 CPU・メモリを解放し、クラスタに返却
STEP 4 トリガー検知でスナップショットから即座に再開(ミリ秒単位)
エージェントのライフサイクルに合わせ、リソースを動的に割り当てる

この仕組みによって、物理リソースをワークロードの実態に基づいて「オーバーサブスクライブ(超過割り当て)」できるようになる。つまり、実際の瞬間的な需要以上のエージェントを同じノードに詰め込めるわけだ。その結果、間欠的にしか動かないエージェントであれば、ベースラインの3.5倍にあたる274個のエージェントを単一ノードで動作させることが可能になった。

ただし、やみくもに詰め込めばよいわけではない。エージェントの種類によって求められる起動時間やレイテンシは大きく異なるからだ。

エージェントの特性に合わせた3つのデプロイ戦略

エージェントの特性に合わせた3つのデプロイ戦略

GKEでは、すべてのエージェントに一律の戦略を強制するのではなく、ノードプールやワークロード設定ごとに異なる挙動を共存させられる。Google Cloudのブログでは、レイテンシ要件に応じた3つの典型例が紹介されている。

リアルタイムコーディングアシスタント(レイテンシ重視)

開発者向けの対話型エージェントでは、起動時間が1秒未満であることと、待ち行列が一切発生しないことが絶対条件だ。このケースでは、GKE Podスナップショットと「Agent Sandboxウォームプール」を組み合わせる。事前にウォームアップされた隔離サンドボックスを常時待機させておくことで、ほぼ瞬時に実行を開始できる。この構成で同一ノード上に133個のエージェントを収容できたと報告されている。

自律的なチームメイト型エージェント(バランス型)

バックグラウンドで対話的に動くエージェントは、平均的な起動時間(数秒)を許容できる。サスペンド&レジューム機能を利用し、遊休時にはリソースを解放、必要時にオンデマンドで復元する。待機中のコンピュートコストを支払う必要はない。

ヘッドレスなバックグラウンドエージェント(レイテンシ許容型)

日次レポートの生成や調査タスクのような定期ジョブは、多少の待ち時間があってもビジネス成果に支障をきたさない。こうしたエージェントには最大限のリソース超過割り当てを適用し、クラスタに空きが出るまで1時間ほど待つ戦略も有効だ。

リアルタイムアシスタント
起動 <1秒 / 待ち行列ゼロ
ウォームプール活用 / 133エージェント
自律的チームメイト
起動 数秒 / サスペンド&レジューム
遊休時リソース解放 / 柔軟な密度
ヘッドレスバックグラウンド
レイテンシ許容 / 最大超過割当
274エージェント(3.5倍)/ コスト75%削減
レイテンシ重視  バランス型  コスト重視

このように、ワークロードの性質に合わせて「パフォーマンス最適化」と「コスト最適化」のバランスをチューニングできるのがGKEの強みだ。サンダリングハード(多数のエージェントが一斉に起動してコンピュートを要求する問題)に対しても、ウォームプールやサスペンド&レジュームの設定で自由度の高い制御が可能になる。

コスト削減を実現するための実践的なアプローチ

コスト削減を実現するための実践的なアプローチ

GKE Agent Sandboxとオーケストレーションの組み合わせによって、エージェントの台数に比例してインフラ予算が増えていく構図を抜本的に変えられる。Google Cloudの検証では、パフォーマンスを重視する構成でも133個のエージェント(ベースライン比約2.2倍)、コスト最適化を突き詰めた構成では274個(同3.5倍)のエージェントを同一ノードで動作させることに成功した。

実務に落とし込む際のポイントは3つある。第一に、セキュリティを保ったままオーバーヘッドを削減するGKE Agent Sandboxへの移行を検討すること。第二に、Podスナップショットによる「凍結・再開」をアーキテクチャに組み込み、遊休リソースを徹底的に活用すること。第三に、すべてのエージェントを同じ扱いにせず、レイテンシ要件に応じてデプロイ設定を変えることだ。

なお、GKE Agent Sandboxの詳細な設定やウォームプール、サスペンド&レジュームの具体的な手順は、Google Cloudの公式ドキュメントで公開されている。まずは既存のエージェントワークロードを対象に、小規模なPoCから始めてみるとよいだろう。

この記事のポイント

  • GKE Agent SandboxはgVisorベースの軽量サンドボックスで、マイクロVMに比べてエージェント密度を44%向上させ、1台あたりのコストを30%以上削減する
  • Podスナップショットとサスペンド&レジュームの組み合わせにより、遊休エージェントを凍結して物理リソースを解放し、理論上3.5倍の密度(最大75%のコスト削減)を達成可能
  • ワークロードのレイテンシ要件に応じて「リアルタイム型」「バランス型」「コスト最適化型」の3戦略を使い分けることで、無理なくスケールできる
ChatGPT for Small Businessプログラム開始、GPT-5.6搭載のChatGPT Workを提供

ChatGPT for Small Businessプログラム開始、GPT-5.6搭載のChatGPT Workを提供

ChatGPT WorkとGPT-5.6が中小企業向けプログラムで提供開始

ChatGPT WorkとGPT-5.6が中小企業向けプログラムで提供開始

OpenAIは2026年7月21日、中小企業の生産性向上を支援する「ChatGPT for small businesses program」の開始を発表した。このプログラムの中核となるのが、複数の工程にわたる複雑なタスクを最後まで実行できるエージェント「ChatGPT Work」であり、最新モデル「GPT-5.6」を搭載する。

小規模なチーム、限られた時間、そして少数のリソース。中小企業の経営者はマーケティング、経理、営業、オペレーション、戦略立案まで、あらゆる役割をひとりでこなすことが求められる。OpenAIのこのプログラムは、AIを「一人ひとりの専門性を拡張し、処理能力を底上げする力の増幅装置」として位置づけ、誰もが大企業並みのツールを手にできる世界を目指している。

本記事では、プログラムの具体的な内容、ChatGPT Workが中小企業の現場で何を変えるのか、そして実際に得られた導入効果の数字をもとに、この動きが持つ意味を読み解いていく。

従来の中小企業の業務負荷
経営者 経理、営業、マーケティング、採用、戦略……
※時間とリソースが分散し、本業への集中が難しい
ChatGPT Work 導入後
経営者 アイデアと判断に集中
ChatGPT Work 定型業務、マルチステップタスクを自動実行
※AIが「力の増幅装置」となり、処理能力を底上げ

上図のとおり、ChatGPT Workは単なるチャットボットではない。ファイルやアプリケーションと接続し、利用者の思考パターンや執筆スタイルを記憶したうえで、複数の手順を必要とする業務をエンドツーエンドで完遂する自律型エージェントである。

プログラムの4つの柱 オンライン学習から対面イベントまで

プログラムの4つの柱 オンライン学習から対面イベントまで

今回発表されたプログラムは、以下の4つの要素で構成されている。単なるツール提供にとどまらず、具体的な業務に即した「使いこなし」までをパッケージにした点が特徴だ。

STEP 1 製品特化型ウェビナー
ChatGPT Workを経理、マーケティング、ECなど業務別のデモで学べる。パートナー企業のQ&Aセッションもあり。
STEP 2 対面型 AI アカデミー
全米各地で開催する実地トレーニング。2025年の実績では参加者の78%が1日で実用的なAIワークフローを構築。
STEP 3 導入ガイドと動画コンテンツ
顧客事例やChatGPT Workに直接アップロードできる対話型ガイド、短尺動画を提供。数分で使い始められる。
STEP 4 パートナー連携と専用スキル
Dropbox、Shopify、Intuit、Slack、Atlassian、Wixなどの厳選パートナーが提供するスキルや特別プロモーションを利用可能。

4つの柱はいずれも「すぐに使える」「具体的な業務に直結する」点で共通している。注目すべきなのはSTEP 2の対面型AIアカデミーの実績データで、参加者の78%がわずか1日で実用的なAIワークフローを構築し、42%がAIの活用によって週5時間以上の時間を節約できたという。この数字は、適切なガイドがあればAI導入のハードルは大きく下がることを示している。

業務別にみるChatGPT Work活用の具体例

業務別にみるChatGPT Work活用の具体例

ChatGPT Workは、設計事務所からテック系スタートアップ、非営利団体まで、業種を問わずに利用できる汎用性を持つ。OpenAIの発表では、特に以下の3つのユースケースが紹介されている。

生産性向上
音声メモをChatGPT Workに送ると、自動で簡潔なSlackメッセージに変換し、複数のチャンネルへ一斉送信。
思考の拡張
市場動向や競合分析を毎週自動更新するサイトを作成。在庫評価から新商品アイデアや販促キャンペーンの提案までを依頼。
サービス改善
全拠点のカスタマーレビューを集約し、成功事例と改善点を抽出したトレーニングプレゼンテーションを自動生成。

これらのユースケースに共通するのは、「これまで外注するか、手付かずで放置されるか、あるいは経営者が無理をして片づけていたタスク」をAIが肩代わりするという点である。とくに音声メモを起点としたワークフロー自動化は、デスクに座る時間すら惜しい現場経営者にとって現実的な省力化手段といえる。

なぜいま中小企業にAIが必要なのか 数字が示す現実

なぜいま中小企業にAIが必要なのか 数字が示す現実

AI導入の具体的なリターン

AI導入の効果は抽象的な話ではない。OpenAIが2025年に開催した「Small Business AI Jams」では、具体的な数字が報告されている。

  • 参加者の78%が、わずか1日で実用的なAIワークフローを構築
  • 42%が、AIの活用で週5時間以上の時間を節約

週5時間の節約は、年間に換算すると約260時間に相当する。これは約6.5週間分の労働時間に匹敵し、中小企業の経営者にとっては事業戦略や新規顧客開拓といった、より付加価値の高い業務へ時間を振り向けられることを意味する。

GPT-5.6がもたらす民主化

ChatGPT Workに搭載されるGPT-5.6は、あらゆる規模のビジネスとすべてのサブスクリプションプランで利用できる最先端モデルである。これは重要な意味を持つ。従来、最高性能のAIモデルは大企業の専有物になりがちだったが、OpenAIはこの垣根を取り払った。

中小企業は、必要なときに必要なだけ高度なAIの知能を呼び出し、品質とスピード、コストのバランスを柔軟に調整できる。デスクでの集中作業中でも、外出先の移動中でも、同じモデルにアクセスできる環境が整ったことになる。

従来のAI活用の壁
高性能AI 大企業専用
※中小企業はコストや専門知識の壁でアクセスできず
GPT-5.6とChatGPT Workによる民主化
最先端モデル 全プランで利用可
※規模を問わず、必要なときに高度なAIを使える環境が実現

この「AIの民主化」は、中小企業の競争環境を大きく変える可能性を持つ。限られた人材と予算のなかで、AIが文字どおり「チームの一員」として機能し始めるからである。

フィードバックが製品ロードマップを動かす 参加型プログラムの狙い

フィードバックが製品ロードマップを動かす 参加型プログラムの狙い

本プログラムのもうひとつの特徴は、OpenAIが参加者からのフィードバックを製品開発に直接反映させる仕組みを組み込んでいる点である。ウェビナー後のQ&Aセッション、地域イベントでの対話、アンケート調査を通じて、「何が機能し、何が欠けているか、次に何を見たいか」という声を集めるという。

これは、単なるプロモーション施策ではない。実際の業務でAIを使うユーザーの生の声が、ChatGPT Workの機能改善や今後のリソース開発、ひいては中小企業向けの製品体験全体を方向づける。参加者は単なる受益者ではなく、製品の共創者として位置づけられているのである。

OpenAIは専用の登録フォームを用意しており、最新情報やイベントへの参加機会をメールで受け取ることができる。

この記事のポイント

  • OpenAIが中小企業向けプログラムを発表し、ChatGPT WorkとGPT-5.6を全プランで提供開始
  • プログラムはウェビナー、対面トレーニング、導入ガイド、パートナー連携の4本柱で構成
  • 2025年の対面イベントでは参加者の78%が1日でAIワークフローを構築、42%が週5時間以上を節約
  • 音声メモの自動Slack変換、市場分析の自動更新、カスタマーレビュー分析など具体的な活用例を提示
  • 参加者からのフィードバックが製品ロードマップに直接反映される双方向型の設計
WP-CLIとREST APIとAbilities API、WordPressインターフェースの選び方

WP-CLIとREST APIとAbilities API、WordPressインターフェースの選び方

3つのインターフェースの全体像

3つのインターフェースの全体像

WordPressには外部からデータをやり取りするための主要なインターフェースが3つ存在する。WP-CLI、REST API、Abilities APIだ。それぞれが異なる距離感でWordPressと向き合い、異なる呼び出し元に対応する。これらを競合関係と捉えるのは誤りで、実際には階層構造をなしている。

WP-CLIはサーバー上で動作し、REST APIはHTTPを介して通信する。そしてAbilities APIは、そのさらに上位に位置し、AIエージェントが何をすべきかを判断する層になる。どのレイヤーがどこに位置するのかを理解すれば、タスクに応じた最適な選択はおのずと見えてくる。

  • WP-CLI:サーバー上で直接PHPを実行(またはSSH経由)。一括操作、移行、デプロイ、メンテナンス向き
  • REST API:wp-jsonへのHTTPリクエスト。ブラウザ、モバイルアプリ、外部サービスからコンテンツの読み書きに使用
  • Abilities API:RESTとMCPで公開される名前付きPHPケイパビリティ。AIエージェントが安全に操作を行えるように設計
Abilities API(AIエージェント層)
AIエージェントが安全にWordPressを操作するためのケイパビリティ定義
「何ができるか」を記述し、許可された操作のみを公開する
REST API(HTTP層)
ブラウザ、アプリ、外部サービスからのHTTP通信
「どんなデータがあるか」を公開し、認証付きで読み書き可能に
WP-CLI(コマンドライン層)
サーバー上での直接PHP実行、SSH経由の一括操作
HTTP往復なし、認証トークン不要、最高速での実行が可能
■ 上位層ほど「自律性」が高く「説明的」 ■ 下位層ほど「高速」で「直接操作」

3つのインターフェースは、下位ほど呼び出し元がサイトに近く、信頼度も高い。上位になるほど、呼び出し元は自律的で遠隔地に位置する。この構造を理解すれば、「どれを使うべきか」の判断はシンプルになる。

WP-CLI:サーバー上のコマンドライン

WP-CLI:サーバー上のコマンドライン

WP-CLIはWordPressのインストール環境に対して直接PHPを実行する。コマンド例としては wp post createwp plugin updatewp search-replacewp db export などがある。実行にはサーバーへのシェルアクセス(SSH)が前提だが、その分HTTPの往復も認証トークンの管理も不要になる。

WP-CLIが最も威力を発揮するのは、サイトを完全に制御できる状況だ。1000件の投稿を移行する、データベース全体でドメインを置換する、定期メンテナンスをスクリプト化する、あるいはデプロイの自動化など、スピードが求められる一括操作では他の追随を許さない。

WP-CLIが適さないケース
ブラウザやモバイルアプリからのアクセス、リモートサービスとの連携には使えない
WP-CLIが最も輝く場面
一括移行、データベース操作、定期メンテナンスの自動化、デプロイスクリプト

WP-CLIはシェルアクセスが前提のため、ブラウザやモバイルアプリ、外部サービスがサイトと通信する手段にはなりえない。しかし開発者がサイト全体を制御できる状況では、WP-CLIは圧倒的な速度と柔軟性を提供する。ターミナルからすべてを操作するワークフローが浸透している開発現場も多く、管理画面(wp-admin)をほとんど開かない運用も可能だ。

REST API:HTTP越しのWordPress

REST API:HTTP越しのWordPress

REST APIはWordPressサイトを、あらゆるHTTPクライアントが読み書きできる状態に変換する。エンドポイントは /wp-json/wp/v2/ 配下に存在し、認証にはアプリケーションパスワード、Cookieとnonce、あるいはOAuthを用いる。ブラウザ、モバイルアプリ、外部サービスがインターネット越しにコンテンツを取得・更新できるようになる。

ヘッドレスCMS構成のWordPressは、このREST APIを基盤に動作する。AstroやNext.jsで構築したフロントエンドがREST経由でコンテンツを取得し、モバイルアプリが投稿を行い、サードパーティ連携がデータを同期する。呼び出し元がサーバー外にいる場合、REST APIがほぼ唯一の通信経路となる。

REST APIの構造と制約
公開するもの
投稿、ユーザー、タクソノミー、設定といった「リソース」
公開しないもの
「誰が何をしたいのか」という意図や操作の文脈
人間の開発者ならドキュメントを読んで適切なリクエストを組み立てられるが、AIエージェントにはハードルが高い

REST APIには重要な限界がある。公開するのは「データの構造」であり、「そのデータで何をしたいのか」という操作の意図までは記述しない。どのエンドポイントが存在し、どうリクエストを組み立てるべきかは、呼び出し元が自ら理解する必要がある。人間の開発者であれば問題ないが、AIエージェントにとっては推論すべき情報が多すぎるという課題が残る。

Abilities API:AIエージェントのためのケイパビリティ層

Abilities API:AIエージェントのためのケイパビリティ層

Abilities APIはWordPress 6.9でコアに導入された最新のインターフェースだ(それ以前のバージョン向けにはプラグインも提供されている)。REST APIが残した「AIエージェントが何を許可されているのかをどう知るか」という課題を解決するために設計された。

Abilities APIでは、生のリソースを公開する代わりに、プラグインやテーマが「名前付きケイパビリティ(能力)」を登録する。各アビリティは、一意のID、人間が読めるラベル、説明文、入力・出力のスキーマ、権限チェックのコールバック、そして実行コールバックを備えた独立した操作単位となる。

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'my-plugin/publish-draft', [
        'label'             => '下書きを公開',
        'description'       => 'IDを指定して既存の下書き投稿を公開する',
        'category'          => 'my-plugin',
        'input_schema'      => [ /* 期待する入力のJSON Schema */ ],
        'output_schema'     => [ /* 結果のJSON Schema */ ],
        'permission_callback' => 'my_plugin_can_publish',
        'execute_callback'  => 'my_plugin_publish_draft',
        'meta'              => [ 'show_in_rest' => true ],
    ] );
} );
REST API
データの構造を公開する
「どんなリソースがあるか」に答える
Abilities API
操作の意図と許可を公開する
「何ができるか」「誰が許可されているか」に答える
アビリティは「これが実行可能な操作であり、必要な入力と許可条件はこれだ」という契約をAIエージェントに提示する

meta.show_in_rest をtrueに設定すると、そのアビリティは wp-json/wp-abilities/v1/abilities で公開され、クライアントが検出できるようになる。JavaScript側では @wordpress/abilities パッケージを介して利用する。

Abilities APIの最大の価値は、エージェントが安全に行動するために必要な「契約」を提供することだ。操作の定義、必要な入力形式、実行許可の条件が明示されるため、AIエージェントがサイトを壊すリスクを最小限に抑えられる。複数のエージェントが共通の語彙で協調動作するマルチエージェント構成でも、Abilities APIが基盤になりつつある。

3つのインターフェースの積み重なり方

3つのインターフェースの積み重なり方

3つのインターフェースは互いに積み重なる関係にある。Abilities APIは多くの場合REST APIの上に構築され、REST APIはWP-CLIが直接駆動するPHPの上で動作する。すべての基盤にあるのは、同じWordPressコア、同じデータベース、同じ関数群だ。

したがって問うべきは「どれが最善か」ではない。「呼び出し元がサイトからどれだけ離れているか」「操作の意図をどこまで明示する必要があるか」という視点で選択することが本質になる。呼び出し元が近く信頼できるほど下位層を、自律的で遠隔にあるほど上位層を使う。

距離:最短 サーバー上(SSH) WP-CLI 一括操作・最高速
距離:中程度 HTTP越し(リモート) REST API データの読み書き
距離:最長 AIエージェント(自律的) Abilities API 安全な操作定義

上位層になるほど「記述性」と「安全性」が重視され、下位層ほど「速度」と「直接制御」に優れる。これらは設計上、相補的な関係にあり、実際のプロジェクトではすべてを併用するのが理想的な構成だ。

各インターフェースの使い分け方

各インターフェースの使い分け方

日常的なタスクにおける選択指針を整理する。

  • 自分が制御するサイトに対して、一括かつ高速に操作したい → WP-CLI。移行、デプロイ、定期ジョブ、データベース操作が該当する
  • ブラウザ、アプリ、外部サービスがコンテンツを読み書きする必要がある → REST API。ヘッドレスフロントエンド、モバイルアプリ、外部連携が該当する
  • AIエージェントにサイトを壊さず操作させたい → Abilities API。許可したい操作をスキーマと権限付きで登録し、エージェントに発見させる
STEP 1 呼び出し元の「距離」を確認する(サーバー内か、リモートか、自律エージェントか)
STEP 2 操作に必要な「明示性」を判断する(データ構造だけで足りるか、操作意図の記述が必要か)
STEP 3 最適なレイヤーを選ぶ(多くの場合、複数レイヤーの併用が正解)

実際のプロジェクトでは、この3つを排他的に使うことはまれだ。むしろそれぞれの得意領域を活かして組み合わせるのが、効率的なWordPress運用の鍵になる。

3つを組み合わせた実践的な構成

3つを組み合わせた実践的な構成

WP Mayorの記事では、実際に3つのインターフェースを併用している構成例が紹介されている。まず、公開運用と日常的な運用作業はSSH経由のWP-CLIで実行される。新規投稿、メディアのインポート、プラグイン更新、キャッシュクリアといった操作をターミナルから完結させ、管理画面(wp-admin)をほとんど開かない運用が行われている。

フロントエンドはヘッドレス構成で、REST API越しにコンテンツを取得する。Astroで構築されたサイトが wp-json 経由でWordPressからデータを取得し、高速な静的ページとして配信する。訪問者はWordPressテーマに触れることなく、WordPressはバックエンドのエンジンとして機能し、REST APIがそのパイプ役を担う。

エージェント向けの機能はAbilities APIを通じて提供される。AIエージェントに限定的なタスクを任せたい場合、関連プラグインがその操作をアビリティとして登録する。権限チェックとスキーマを伴うため、シェルアクセスを丸ごと渡したり、大量の生エンドポイントをエージェントに解析させたりする必要がなくなる。

WP-CLI(運用層)
投稿・メディア・プラグイン管理をターミナルから一括実行。シェルアクセス可能なAIアシスタントも直接駆動できる
REST API(配信層)
ヘッドレスフロントエンドがコンテンツを取得。Astroが静的ページとして配信し、訪問者はWordPressテーマに触れない
Abilities API(エージェント層)
AIエージェント向けにスコープ付き操作を登録。権限チェックとスキーマにより安全な自動化を実現
各レイヤーがそれぞれの得意領域を担当し、互いに補完し合う構成

WP-CLIは速度と一括処理能力で、REST APIは外部連携の柔軟性で、Abilities APIはAIエージェントの安全性で優位性を持つ。1つのインターフェースに別の役割を強制しようとするところから問題は始まる。3つのレイヤーを適材適所で使い分けることが、WordPress自動化の効率を最大化する道筋だ。

この記事のポイント

  • WP-CLI、REST API、Abilities APIは競合ではなく、呼び出し元の距離に応じた階層構造をなす
  • WP-CLIはサーバー上の直接操作に最適で、一括処理と速度が求められる場面で選ぶ
  • REST APIはHTTP越しのデータ読み書きを担い、ヘッドレス構成やモバイルアプリ連携の基盤となる
  • Abilities APIはAIエージェントに操作の安全な契約を提供し、マルチエージェント構成でも威力を発揮する
  • 実際のプロジェクトでは3つを組み合わせ、各レイヤーの得意領域を活かすのが理想的な運用だ
GPT-5.5の応答を改善、VS Codeのプロンプトチューニング手法

GPT-5.5の応答を改善、VS Codeのプロンプトチューニング手法

GPT-5.5の応答が改善された技術的背景

GPT-5.5の応答が改善された技術的背景

VS Codeが提供するAIエージェント機能は、コード生成の裏側で「コーディングハーネス」と呼ばれる仕組みが動いている。これはモデルとツール、コンテキスト、指示、エージェントのループを繋ぐ層だ。モデルがコードを書くための土台となる部分といえる。

2026年7月、VS CodeチームはOpenAIと協力し、GPT-5.5向けのシステムプロンプトを改善する実験を実施した。焦点は「エージェントの探索を減らし、検証を早める」ことにある。この変更で応答速度とコストの両方を改善できるかどうかが検証された。

プロンプトチューニングの目的と仮説

GPT-5.5のリリース後、VS Codeチームはエージェントがトークンをどのように消費しているかを分析した。分析の結果、モデルが実際の編集に入る前に過剰な探索を行っているパターンが浮かび上がった。具体的には、ファイルの再読込や周辺コードの比較に多くのトークンが費やされていた。

この観察から1つの仮説が導かれた。それは「エージェントはさまよう努力を減らし、証拠、行動、検証という意図的なループに注力すべきである」というものだ。この仮説を検証するため、2種類のプロンプトが用意された。

従来のエージェント行動(Before)
エージェント 要求受信 広範な検索 ファイル再読込 比較 ようやく編集
※トークン消費が大きく、最初の編集までに時間がかかる
改善後のエージェント行動(After)
エージェント 要求受信 仮説形成 局所検索 検証可能な編集 即時検証
※探索を抑制し、最初の編集と検証を優先する

エージェントが編集前に「考えすぎる」状態を減らし、必要最小限の探索で行動に移すよう誘導する。この考え方は、トークン消費と応答時間の両方に直接影響を与える。

実験の中身と2つのアプローチ

実験の中身と2つのアプローチ

実験は2週間にわたって実施された。GPT-5.5のエージェントトラフィックを、対照群と2つの処置群に25%ずつ分割し、残りの25%はスコアカード外でデフォルトプロンプトが使用された。この設計により、同じ種類のユーザートラフィックで公平な比較が可能になる。

処置A「PRPT_SRCH」簡潔な探索と編集

処置Aは小規模で焦点を絞った変更だ。プロンプトに1つのコンパクトな指示を追加し、不必要な探索を減らすようモデルに促す。この指示は「economical_search_and_edit」セクションと呼ばれる。

具体的には、次の5つの行動指針が与えられた。最も具体的なアンカー(ファイル、シンボル、失敗している動作など)から開始すること。1つの仮説とそれを否定できる安価なチェックを選ぶために十分な周辺コンテキストだけを集めること。広範なリポジトリ探索より1回の対象検索を優先すること。最も安価な判別チェックがわかったら即座に行動すること。そして、新しい結果が関連性を示さない限り、変更されていないコンテキストを再読しないことだ。

economical_search_and_edit:
    - 最も具体的なアンカーから開始する
    - 1つの仮説とその反証チェックに十分なコンテキストだけを集める
    - 広範な探索より1回の対象検索を優先する
    - 最も安価な判別チェックがわかったら即行動する
    - 変更されていないコンテキストは再読しない

処置B「PRPT_LRG」大規模プロンプト再構成

処置Bは同じ仮説をより広範に展開したものだ。エージェントのワークフローを「Before_the_first_edit(最初の編集前)」と「After_the_first_edit(最初の編集後)」の2つの明示的なセクションに再編成する。

このアプローチの狙いは、検索ステップだけでなくループ全体を解決することにある。最初の編集前に局所的な仮説を形成し、広範な探索を避け、根拠のある最初の編集を行い、最初の実質的な編集後に即座に検証する。処置Aと異なり、プロンプト自体のサイズは大きくなるため、構造の追加が効率を改善できるかどうかが重要な論点だった。

処置A PRPT_SRCH(簡潔アプローチ)
変更量 小(1つのコンパクトな指示を追加)
構造 単一セクション
焦点 探索の抑制に特化
vs
処置B PRPT_LRG(大規模アプローチ)
変更量 大(編集前と編集後の2セクションに再構成)
構造 Before/After の2段階
焦点 探索抑制+編集後の検証まで含めたループ全体
処置A:簡潔な指示追加  処置B:ワークフロー全体の再構成

両処置の設計思想の違いは明確だ。処置Aは最小限の介入で探索を抑えるのに対し、処置Bはエージェントの行動全体を構造化して制御しようとする。この差が実際のパフォーマンスにどう現れるかが実験の焦点になった。

2週間のスコアカードが示した結果

2週間のスコアカードが示した結果

実験では品質、レイテンシ、効率の3つの次元で評価が行われた。品質は「コードが定着するか」、レイテンシは「最初の編集がどれだけ早く行われるか」、効率は「トークンとツール呼び出しの数」で測定される。

品質指標 10分生存率とコミット生存率

10分生存率は、AIが書いたコードのうち10分後もファイルに残っている割合を示す。コミット生存率は、さらに厳格にgitコミットまで生き残ったコードの割合だ。この2つが品質のガードレール指標となる。

結果として、コミット生存率は処置Bで+0.68%とわずかに上昇し、処置Aでは-0.48%とわずかに低下したが、いずれも統計的に有意ではなかった。10分生存率は両処置ともわずかに低下し、処置Bの-0.44%だけが統計的有意の閾値をわずかに超えた(p=0.0493)。VS Codeチームはこれを「実際のトレードオフとして考慮すべきだが、動きは小さく、他の品質ガードレールは後退しなかった」と評価している。

レイテンシ指標 初回編集までの時間

編集レイテンシでは処置Bが最も強い改善を示した。p50(中央値)の初回編集時間は-5.68%(3.9秒高速化、p=2e-5)、p95(下位5%の遅いケース)では-9.30%(38.8秒高速化、p=1e-10)といずれも高い統計的有意性を示した。

処置Aもp50で-2.88%(2.0秒高速化、p=0.0271)と改善したが、p95の改善は統計的に有意ではなかった。遅いケースでの差が特に顕著で、「なぜこれが遅いのか」というストレスを感じる場面での改善が大きかったことになる。

トークン効率とツール呼び出し回数

1ユーザーあたりの日次トークン消費量(p50)は両処置とも減少したが、統計的有意ではなかった。しかし、トークン消費の裾野(p95、特に重いリクエスト)では、処置Bが-7.64%(p=0.0003)、処置Aが-5.19%(p=0.0157)と明確な改善を示した。

平均ツール呼び出し回数も両処置で減少した。処置Bは-8.54%(1ターンあたり2.04回の呼び出し削減、p=1e-12)、処置Aは-3.19%(0.77回削減、p=0.0091)だ。処置Bの優位性は極めて高い統計的有意性で裏付けられた。

主要指標の改善度比較(処置B vs 処置A)
p50 初回編集時間 処置B -5.68% 処置A -2.88%
p95 初回編集時間 処置B -9.30% 処置A -1.93%
p95 トークン消費 処置B -7.64% 処置A -5.19%
ツール呼び出し削減 処置B -8.54% 処置A -3.19%
処置Bが顕著に優位  処置Aは部分的改善  統計的有意性なし/低下

処置Bは総合的に最も強いプロファイルを示した。レイテンシの明確な勝利、裾野トークンの有意な削減、ツール呼び出しの減少、そして品質ガードレールのほぼ安定。10分生存率のわずかな低下は軽微な有意性(p=0.0493)にとどまり、レイテンシやトークン、ツール呼び出しの改善ははるかに大きく堅牢だった。

プロンプトチューニングが示す開発体験の進化

プロンプトチューニングが示す開発体験の進化

この実験の成果は数字の変化だけではない。重要なのは、プロバイダからのフィードバックに基づく検証可能な仮説を、オフライン評価で事前検証し、2週間の本番環境で確認するという一連のループが機能したことだ。

モデルのリリースはチューニングループの終点ではない。VS Code上の実際の動作を観察し、焦点を絞った改善をテストし、より速く、信頼性が高く、効率的な体験を実現する新たな方法を見つける機会となる。このプロンプトチューニングは、その1つの具体的な実例だ。

使用量ベース課金におけるトークン効率の重要性

この改善が特に重要なのは、使用量ベースの課金モデルが前提にあるからだ。トークン効率は単なるインフラ指標ではない。エージェントが探索に費やすすべてのトークンは、ユーザーが支払い、待たされる対象だ。根拠のある編集に早く到達するエージェントは、より良い体験とより小さい請求額の両方をもたらす。

VS Codeチームはこの取り組みを継続する方針を示している。モデル、プロンプト、ツール、コーディングハーネス全体にわたって改善点を探し続け、エージェントの予算が必要な作業に集中できるよう最適化していくという。

プロンプトチューニングの改善ループ
STEP 1 VS Code上の実際のエージェント動作を観察し、トークン消費パターンを分析する
STEP 2 プロバイダ(OpenAI)のモデル専門知識と協力し、仮説を形成する
STEP 3 オフライン評価で仮説を事前検証し、有望なプロンプト案を絞り込む
STEP 4 本番トラフィックで2週間のA/Bテストを実施し、統計的有意性を確認する
結果 勝利した処置Bをデフォルトプロンプトとして出荷、次の改善サイクルへ

このループが示すのは、AI開発支援ツールの進化がモデルの性能向上だけに依存する段階から、プロンプト設計やツール連携の最適化を含む総合的な取り組みへと移行していることだ。モデルが高性能でも、使い方が適切でなければ本来の力を発揮できない。その橋渡しをするのがプロンプトチューニングの役割といえる。

この記事のポイント

  • GPT-5.5向けのプロンプトチューニングで、エージェントの探索を抑制し検証を早める改善が実施された
  • 処置B(大規模プロンプト再構成)が最も優れた結果を示し、p95の初回編集時間を9.30%短縮した
  • ツール呼び出し回数は8.54%削減され、トークン消費の裾野(重いリクエスト)でも7.64%の改善が確認された
  • 品質指標(コード定着率)はほぼ維持され、速度と効率の改善が品質を犠牲にしないことが実証された
  • 使用量ベース課金の文脈では、トークン効率の改善がユーザーのコスト削減に直結する重要性を持つ
Vercel Agentが本番環境に進出、プラン即許可で安全なAI運用を実現

Vercel Agentが本番環境に進出、プラン即許可で安全なAI運用を実現

Vercelが2026年7月8日、自社のAIエージェント「Vercel Agent」の大幅な機能拡張を発表した。従来はアラートのトリアージやプルリクエストのレビューが中心だったが、今回のアップデートでダッシュボード上に常設され、本番環境の調査やプロジェクトへの質問応答、承認後のアクション実行まで可能になった。

Vercel Agentの最大の特徴は「プラン即許可(Plan-to-Permission)」という新しい権限モデルだ。デフォルトで読み取り専用として動作し、デプロイのロールバックや設定変更といった操作は、具体的な作業計画を提案して承認を得たうえで、そのタスクに限定された一時的な権限のみを使って実行する。

本番稼働中のアプリケーションにAIを介入させるには、安全性の担保が不可欠である。Vercel Agentは独立したIDで動作し、生成したコードは隔離されたサンドボックスで検証する。この設計により「自律的でありながら制御された状態」を実現しており、AIエージェントの運用にまつわる信頼の課題に対して、具体的な解決策を示した製品といえる。

Vercel Agentの全体像と導入背景

Vercel Agentの全体像と導入背景

Vercel Agentは、Vercelプラットフォーム上で動作するAIエージェントだ。アプリケーションのデプロイと実行を支えるインフラに組み込まれているため、本番環境で問題が発生した際に、最初に対応を開始できるポジションにある。アラートを受けてから自律的にログやメトリクス、デプロイ履歴を調査し、根本原因を特定して修正案を提示する。

Vercel社内では数ヶ月前から本番運用に組み込まれており、すでに具体的な成果が出ている。典型的な事例として、深夜23時に不良デプロイが行われ、チェックアウト用のエンドポイントが500エラーを返し始めたケースでは、オンコールエンジニアがログインする前にAgentがエラーを4分前のデプロイまでトレースし、即時ロールバックを推奨した。エンジニアが計画を承認すると、Agentが前の正常なビルドにロールバックし、エンドポイント修正用のプルリクエスト作成まで自動で進めた。アラート発生から問題緩和までの時間は3分未満だったという。

従来のインシデント対応(Before)
23:00 不良デプロイ発生
23:04 アラート検知
23:15 オンコールエンジニアがログイン
23:25 ログ調査→原因特定
23:35 手動ロールバック実行
対応時間:約35分
Vercel Agent導入後(After)
23:00 不良デプロイ発生
23:00 Vercel Agentが自律的にログ・メトリクス調査開始
23:01 問題デプロイ特定→ロールバック計画を提案
23:02 エンジニアが承認→Agentがロールバック実行
対応時間:約3分未満
人間主体のフロー  AI Agentが介在するフロー

このデモは、同じインシデントに対する従来の対応とVercel Agent導入後の対応を比較した概念図である。Agentが自律的に調査と提案を行い、人間は最終判断に集中できる点が最大の違いだ。

本番環境にAIを近づけるための新セキュリティモデル

本番環境にAIを近づけるための新セキュリティモデル

アプリケーションの修正や設定変更が可能なAIエージェントを本番環境に導入する場合、最も重要な問いは「どう安全にデプロイや設定変更を任せられるか」である。多くのAIエージェントはユーザーの全権限を引き継いで動作するため、誤った指示や混乱したサブエージェントの被害がそのまま本番に及ぶという構造的な課題を抱えている。

Vercel Agentはこの問題に対して、3つの要素からなる新しい権限モデルを実装した。エージェント自身の固有ID(Principal)、タスクごとの一時的な権限付与(Plan-to-Permission)、そして生成コードの隔離実行環境(Sandbox)である。これらはプラットフォームレベルで強制されるため、AIモデルの挙動にかかわらず安全策が機能する。

エージェント固有のIDによる帰属と権限の分離

一般的なAIエージェントは、操作する人間のIDと権限をそのまま使って動作する。その場合、エージェントが行った操作と人間が行った操作を区別できず、誰が何を指示し実行したのか追跡不可能になる。

Vercel Agentは「vercel-agent」という固有のプリンシパル(主体)として動作する。すべての変更操作には「誰が依頼したか」「誰が承認したか」「Vercel Agentが実行した」という記録が必ず残る。さらに、Agentに付与される権限は、操作を指示した人間がもつ権限の範囲を超えることはない。この設計により、説明責任(アトリビューション)と権限の透明性を両立している。

従来型エージェントの権限モデル(Before)
ユーザー AI Agent 全権限を継承して操作
⚠️ Agentと人間の操作が混在し、監査不能
⚠️ 誤指示や誤動作の影響範囲がユーザーと同等
Vercel Agentの権限モデル(After)
ユーザー タスク指示 Vercel Agent (固有ID: vercel-agent)
Vercel Agent 実行計画を提案
ユーザー 計画を承認 一時権限発行
✅ 操作者・承認者・実行者が常に記録される
✅ 付与される権限は承認された計画の範囲に限定
従来型の権限モデル  Vercel Agentの権限モデル

この図は、従来型エージェントとVercel Agentの権限構造の違いを表している。Vercel Agentでは、常に「依頼者」「承認者」「実行者」の3者が記録され、権限も計画単位で一時的に付与されるため、誤動作の被害範囲が極めて狭い。

プラン即許可(Plan-to-Permission)の仕組み

多くの組織がAIエージェントを開発フローに統合する際、最初に直面するのが「事前に広範な権限を付与してしまう」という課題だ。これはエージェントに必要以上の権限を、必要以上の期間与えることになる。そのエージェントにプロンプトを送れる人なら誰でも、付与された権限の範囲にアクセスできてしまうため、権限の広さがそのままセキュリティリスクの大きさに直結する。

Vercel Agentはデフォルトで読み取り専用である。デプロイのロールバック、設定変更、キャッシュのクリアといった操作が必要な場合、Agentはまず実行計画を提案し、その計画に限定されたアクセス権限を要求する。ユーザーが計画を承認すると、Agentはそのタスクに必要な能力を一時的に取得し、作業完了後は自動的に読み取り専用状態に戻る。

Agentが行うすべてのAPI呼び出しは、3つのチェックを通過する必要がある。承認された計画で付与された能力(Capability)、トークンのスコープ、そしてチームの既存権限だ。これら3つすべてが許可する場合にのみ操作が実行され、このチェックはプラットフォーム側で強制されるため、AIモデルがどのような挙動をとっても安全策が破られることはない。Vercelはこの仕組みを「プラン即許可(Plan-to-Permission)」モデルと呼び、最小権限の原則を設計レベルで組み込んでいる。

STEP 1 Agentが問題を検知し、自律的に調査を開始
STEP 2 ログ・メトリクスから根本原因を特定し、修正計画を提案
STEP 3 ユーザーが計画を承認→タスク限定の一時権限が発行される
STEP 4 Agentが修正を実行→完了後、自動的に読み取り専用に戻る
STEP 1: 検知  STEP 2: 提案  STEP 3: 承認  STEP 4: 実行→復帰

この一連の流れでは、Agentが自律的に調査と提案を行う一方で、実際の操作権限は人間の承認を経て初めて発行される。人間の判断を挟むことで安全性を確保しつつ、Agentの自律性を最大限に活かせる設計だ。

サンドボックスによる生成コードの安全な検証

コードを生成するAIエージェントにはもうひとつ重大な課題がある。それは「生成されたコードが実際に動くかどうかは、実行してみるまでわからない」という点だ。動作確認されていない修正を本番環境に適用することは、さらなる障害を引き起こすリスクを伴う。

Vercel Agentが生成したコードは、Vercel Sandbox(FirecrackerマイクロVMによる短寿命の隔離環境)内で実行される。このサンドボックスは実際のプロジェクトのコピーを持っており、Agentは生成したコードを本物のビルドプロセス、テスト、リンターに対して実行し、問題なくパスしたものだけをPRとして提示する。たとえば壊れた設定ファイルを修正する場合、Agentが変更を加えてサンドボックス内でビルドテストを通過させ、その結果をPRにまとめるという流れになる。

この仕組みにより、Agentは自由にコードを生成して実行できるが、検証に失敗したコードや壊れた修正が人間の前に提示されたり、本番環境に直接届いたりすることはない。コードレベルの安全性をインフラ側で担保している点が重要だ。

現場の開発フローがどう変わるか

現場の開発フローがどう変わるか

Vercel Agentはインシデント対応だけでなく、開発者が日常的に直面するさまざまなタスクを支援する。具体的なユースケースを4つ紹介する。

プルリクエストのレビュー

AgentにPRの確認を依頼すると、CIがパスしているだけでは検出できないパフォーマンスの低下やリスクの高い変更を指摘する。たとえば、ある変更によってページが毎回サーバーサイドレンダリングされるようになり、キャッシュが効かなくなっていないかといった観点までチェックできる。

コスト増加の原因追及

「なぜ今月の請求額が跳ね上がったのか」という問いに対して、Agentはコード変更履歴を調査し、コスト急増の原因となった特定のコミットを特定する。たとえば、あるページがキャッシュされずに毎回サーバーサイドレンダリングされるようになったコード変更を検出し、承認を得たうえで修正PRを作成する。

ビルド失敗の修正

失敗したデプロイをAgentに調査させると、ログを読み取り、問題のある設定ファイルを特定し、修正の許可を求めてくる。ユーザーが承認すれば、Agentが設定を修正し、サンドボックス内でビルドをテストしてからPRとして提出する。

本番リリースの安全性確認

フィーチャーフラグに関する質問に対して、Agentはコードと本番のライブメトリクスの両方を分析し、その機能をロールアウトしても安全かどうかを判断する。データに基づいた客観的な判断が得られるため、リリース判断の品質が向上する。

従来の開発フロー(Before)
開発者 PRレビュー(人力) CIパス確認
開発者 コスト増加の原因を手動調査
開発者 ビルド失敗のログ解析
すべての調査・判断を人間が実施
Vercel Agent導入後の開発フロー(After)
Vercel Agent PRのパフォーマンスリグレッションとリスク検出
Vercel Agent コスト増加の原因コミットを特定し修正PR作成
Vercel Agent ビルド失敗の原因設定を特定・サンドボックスでテスト
Agentが調査・提案を代行し、人間は判断に集中
人間がすべて対応する従来フロー  Agentが調査・提案を代行する新フロー

この比較図は、日常的な開発タスクにおける負荷の変化を表している。Agentが調査と提案を担うことで、開発者はコードの質やビジネス判断といったより本質的な業務に集中できる。

反脆弱性インフラがもたらす意味

反脆弱性インフラがもたらす意味

Vercel Agentの発表で最も重要なポイントは、単にAIエージェントの機能が追加されたという話ではない。AIエージェントを「本番環境に近づけても安全に運用できる」という状態を、プラットフォームの設計で実現したことだ。

AIエージェントの時代において、真の限界は2つの天井で決まる。ひとつはモデルが「何をできるか」、もうひとつはユーザーが「何を許可するか」だ。モデル性能が向上し続けるなかで、実際の運用において重要になるのは後者、すなわち信頼の設計である。どれほど高性能なモデルでも非決定論的であり、非決定論的なシステムは非決定論的に失敗する。安全性は「エージェントが毎回正しい判断をすること」に依存してはならず、システムそのものに組み込まれていなければならない。

Vercelは長年にわたり、イミュータブルデプロイメント(デプロイが書き換え不可で、不良デプロイは1回のロールバックで元に戻せる仕組み)をはじめとする安全策を積み上げてきた。これらはもともとAIエージェントのために設計されたものではないが、自律システムが必要とするガードレールそのものとして機能する。Vercelはこの考え方を「反脆弱性インフラ(Anti-fragile Infrastructure)」と呼んでいる。

反脆弱性インフラの本質は、エージェントに誤りがあっても被害を局所化でき、人間のミスさえもコストを抑えられる点にある。安全性がインフラ層に組み込まれているため、エージェントが正しいことを前提にせずとも、実用的な権限を委譲できる。Vercel Agentのケースでは、自律的に調査と提案を行い、人間が承認した範囲内でのみ操作を実行し、何か問題があれば即座にロールバックできる。

このモデルは、AIエージェントの実運用における「自律性 vs 安全性」というトレードオフに対して、明快な解を示している。エージェントが仕事をし、人間が最終判断を保持し、インフラがフェイルセーフとして機能する。この3層構造が揃って初めて、本番環境にAIを近づける信頼の土台が成立する。

Vercel Agentの将来展望と利用開始方法

Vercel Agentの将来展望と利用開始方法

現時点でのVercel Agentは、異常の調査、プルリクエストの作成、プロジェクトや本番アプリに関する質問への回答が可能だ。今後のロードマップとして、特定分野の専門家エージェントへの委任機能が予定されている。たとえば、コードベース全体に対する詳細なセキュリティレビューや、フロントエンドのデザイン・UXレビューを、オンデマンドで専門家AIに依頼できるようになる見込みだ。

Vercel Agentは、ProプランおよびEnterpriseプランのチームに対して段階的にロールアウトされている。利用を希望する場合は、Vercelのアーリーアクセスページから申請するか、ダッシュボードのサイドバーにある「Agent」セクションから有効化できる。

この記事のポイント

  • Vercel Agentは本番環境の異常を自律的に調査し、人間の承認を得て修正を実行するAIエージェントである
  • 「プラン即許可」モデルにより、Agentの権限はタスク単位で一時的に付与され、完了後は読み取り専用に戻る
  • 生成されたコードは隔離されたサンドボックスで検証され、本番環境に直接影響を与えない設計になっている
  • イミュータブルデプロイメントなどのインフラ安全策と組み合わせることで、エージェントの誤動作コストを最小化する
  • AIエージェントの実運用における信頼の課題に対して、プラットフォーム設計で安全性を担保するアプローチを具体化した製品といえる