タグアーカイブ MCP

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行でセットアップが完了し、すぐにエージェント向け検索エンジンとして利用開始できる。
WordPress 7.0でAIプラグインを作る!Abilities APIとAI Client連携の実際

WordPress 7.0でAIプラグインを作る!Abilities APIとAI Client連携の実際

WordPress 7.0から導入された3つのAI関連コンポーネント、Abilities API、AI Client、そしてMCP Adapterがプラグイン開発の風景を大きく変えようとしている。これらを組み合わせると、AIが画像を解析し、自動で記事を生成するプラグインを驚くほど少ないコードで実装できる。

本記事では、実際に「Photo to Post」というプラグインの構築を通して、各APIの役割と連携方法を具体的に解説する。WordPressの管理画面から画像URLを入力するだけで、AIがビジョンで内容を理解し、下書き投稿を自動生成する流れを追いながら、新しい開発スタイルの全体像をつかんでほしい。

情報源はWordPress Developer Blogのチュートリアル「Build your first AI-Powered WordPress plugin」(2026年7月30日公開)だ。ここで示されるコードと設計思想は、今後のWordPressエコシステムにおけるAI統合の方向性を色濃く反映している。

新しいAI開発基盤の3要素

新しいAI開発基盤の3要素

WordPress 6.9以降で整備されたAbilities API、7.0で正式に取り込まれたAI Client、そしてMCP Adapterは、それぞれ独立して使えるが、組み合わせることで真価を発揮する。まずはこの3つの役割を押さえておく。

Abilities API

Abilities APIは、プラグインが提供する機能を「能力」として登録し、REST APIやAIエージェントなどが統一された方法で発見・実行できる仕組みだ。入力スキーマ、出力スキーマ、パーミッションコールバック、そして実処理を行うコールバックを定義する。これにより、従来のようにエンドポイントを個別に実装する手間が省け、一度登録した能力が管理画面・REST・MCP経由でそのまま利用可能になる。

WordPress AI Client

AI Clientは、プロバイダー(OpenAI、Anthropic、Googleなど)に依存しないPHPライブラリだ。プラグインコードはwp_ai_client_prompt()というフルーエントなビルダーでプロンプトを組み立て、テキスト生成やファイル送信を依頼するだけでよい。プロバイダーの切り替えは管理画面のConnectors API(後述)でAPIキーを設定するだけで済み、コードを一切変更する必要がない。

MCP Adapter

MCP(Model Context Protocol)は、AIエージェント(デスクトップアプリやVS Code拡張など)が外部ツールを呼び出すための標準プロトコルだ。MCP Adapterプラグインをサイトにインストールすると、登録したAbilityがMCPツールとして自動公開される。ClaudeやChatGPTなどのAIクライアントにWordPressの機能を認識させ、「この画像から投稿を作成して」と自然言語で指示するだけで、プラグインの能力が裏側で呼び出される。

REST経由
能力 describe-image
curlでエンドポイントを叩けばJSON応答が返る
管理画面経由
能力 create-post-from-photo
DataFormで生成されたフォームから実行
MCP経由(AIエージェント)
能力 create-post-from-photo
Claudeなどがツールとして呼び出す
REST  管理画面  MCP
同じ能力が3つの入口からシームレスに使える

上の図はAbilities APIの最大のメリットを示している。一度登録すれば、UI、REST、AIエージェントのどこからでも同一の能力を実行できる。エンドポイントごとに別の処理を書く必要はない。

プラグイン「Photo to Post」の仕組み

プラグイン「Photo to Post」の仕組み

チュートリアルで構築する「Photo to Post」は、画像URLを入力するとAIが画像の内容を解析し、その説明文をもとにブログ投稿用のタイトルと本文を生成、さらにその画像をアイキャッチに設定した下書き投稿を作成するプラグインだ。

内部では、3つのAbilityが連携している。ここで重要なのは、最後の能力が他の能力を呼び出す「能力の合成(composition)」を実践している点だ。

STEP 1 画像URLを入力、describe-imageが画像を解析し説明文を生成(AI Vision)
STEP 2 説明文を元にgenerate-post-from-descriptionが投稿内容をAIで生成(テキスト生成)
STEP 3 create-post-from-photoが上記2つを内部で呼び出し、投稿を作成してアイキャッチを設定

この合成パターンは、WordPressのフィルターフックやアクションフックで築かれた「小さな機能を組み合わせて大きな機能を作る」という哲学のAI時代バージョンといえる。

実装の流れを追う

実装の流れを追う

ここからはチュートリアルの主要な実装ステップを、要点を絞って解説する。すべてのコードはスタータープラグインをベースにしており、TODOコメントを置き換える形で進められる。AIプロバイダーとしてはOpenAI、Anthropic、Google Geminiなどが利用可能だ。

AIプロバイダーとの接続

WordPress 7.0では、設定メニューに「コネクター」画面が追加された。Connectors APIによって、各プラグインはAPIキーの保存場所を一元管理できる。従来はプラグインごとに設定ページでキーを管理する必要があったが、これで1箇所に集約される。

OpenAI、Anthropic、Googleの公式プロバイダープラグインをインストールし、コネクター画面でAPIキーを登録すれば、あとはAI Clientが自動的にそのプロバイダーを使う。ビジョンモデルを使う場合は、Anthropicのように画像をBase64で送る必要があるが、AI Clientが吸収するためコード上の差異はほとんど生じない。

能力の登録

Abilities APIにおける能力の登録は、wp_register_ability()関数にラベル、説明、入出力スキーマ、パーミッション、コールバックを渡すだけだ。ここで定義したスキーマが、RESTやMCP経由で能力を呼び出す際の「説明書」になる。

チュートリアルでは、describe-image(画像URL → テキスト説明)、generate-post-from-description(説明文 → 投稿タイトルと本文)、create-post-from-photo(画像URL → 下書き投稿)の3つを登録する。

従来のプラグイン開発(Before)
RESTエンドポイントをregister_rest_routeで個別定義
フロントJSでfetchを手書き
MCP対応は別途SDKが必要
Abilitiesベースの開発(After)
能力を1回登録するだけでRESTも管理画面もMCPも自動対応
入出力スキーマが自己文書化
能力どうしの合成で複雑な処理もシンプルに

能力を登録したら、wp_abilities_api_initアクションにフックし、RESTで表示するためにメタ情報にshow_in_rest => trueを指定する。これだけでアプリケーションパスワードを使ったcurlで能力の一覧を取得できる。

AI Clientによる画像解析とテキスト生成

最初の能力describe-imageのコールバックでは、wp_ai_client_prompt()でプロンプトを構築し、with_text()with_file()で画像のデータURIを渡してgenerate_text()を呼ぶ。戻り値はWP_Errorの可能性があるため、必ずチェックする。

画像はwp_remote_get()で取得しBase64エンコードしたデータURIにして送る。これにより、URLでの画像指定を受け付けないプロバイダーでも動作する。

2つ目の能力generate-post-from-descriptionでは、AIに「画像説明文から魅力的なブログ投稿を生成し、JSONで返す」よう指示する。プロンプトには「markdownコードフェンスで囲まない」と明示するが、AIは非決定論的なため、念のためpreg_replace()でフェンスを除外し、JSON文字列の中からオブジェクトを抽出する防御的なパース処理を入れている。

能力の合成

3つ目の能力create-post-from-photoがこのプラグインの心臓部だ。ここでwp_get_ability()を使って自分自身以外の能力を取得し、execute()で実行する。最初にdescribe-imageを実行して画像説明を取得し、次にその説明を使ってgenerate-post-from-descriptionを実行、最後に得られたタイトルと本文からwp_insert_post()で下書きを作成する。

このように、能力を「LEGOブロック」のように組み合わせられることがAbilities APIの真骨頂だ。各能力は単独でテスト可能であり、後から新しい能力を追加して組み合わせることも容易である。

管理画面の拡張

スタータープラグインに付属するDataFormベースの設定画面を、実際の能力と連携させる。JavaScript側からは@wordpress/abilitiesパッケージのgetAbility()executeAbility()を使い、先ほどPHPで登録したcreate-post-from-photo能力を呼び出す。

スクリプトをモジュールとして読み込み、readyプロミスでAPIが利用可能になるのを待ってから実行する。これで管理画面から画像URLを入力し「投稿を生成」ボタンを押すだけで、一連のAI処理が走り、下書きが作成される。成功すると編集画面へのリンクが表示される。

MCP対応でAIエージェントにも開放

能力の登録時にメタに'mcp' => array( 'public' => true )を追加し、MCP Adapterプラグインを有効化するだけで、その能力がMCPサーバー経由で外部AIエージェントに公開される。

例えばClaudeデスクトップアプリの設定ファイルにWordPressサイトのURLとアプリケーションパスワードを記述すれば、「この写真から投稿を作成して」と話しかけるだけで、create-post-from-photoが自動的に呼ばれる。REST、管理画面、MCPという3つの入口を同じコードで実現できるのは、Abilities APIの設計の妙だ。

実装から見える将来性

実装から見える将来性

WordPressのコアに組み込まれたこれらAIビルディングブロックは、単なる補助機能ではない。プラグイン開発のパラダイムを「単一の機能提供」から「再利用可能な能力の提供と合成」へとシフトさせる可能性を秘めている。

従来のプラグイン開発
個別のREST実装
フロントとバックエンドの密結合
MCP対応は別途開発
Abilities API+AI Clientの世界
能力を登録すればREST・管理画面・MCPが即座に利用可能
AIプロバイダー非依存の設計
能力の合成で複雑な自動化も容易
従来  これから

さらに、Connectors APIによるAPIキーの一元管理は、複数プラグイン間の設定のばらつきを解消し、サイト管理者の負担を大きく下げる。開発者は「どのAIモデルを使うか」を気にせず、ビジネスロジックに集中できる環境が整いつつある。

注意点として、AI呼び出しには時間がかかるため、デフォルトのHTTPタイムアウトでは処理が中断される可能性がある。チュートリアルではwp_ai_client_default_request_timeoutフィルタでタイムアウトを120秒に延長する対処が示されている。このような実運用の勘所も押さえておきたい。

プラグイン開発者がこうした基盤を活用し始めれば、WordPressエコシステム全体のAIリテラシーが一気に加速する。非エンジニアでも「写真から投稿を作って」と指示するだけでコンテンツ制作が進む未来は、すぐそこまできている。

この記事のポイント

  • WordPress 7.0のAbilities API・AI Client・MCP Adapterにより、AI搭載プラグインを少ないコードで構築できる
  • 能力を1回登録すればREST・管理画面・AIエージェントの3経路で同一機能を提供可能
  • AI Clientはプロバイダー非依存で、Connectors APIがAPIキー管理を集約
  • 能力の合成で「LEGOブロック」のように複雑な自動化を実現
  • 実運用ではタイムアウト延長フィルタなど、実装上の注意点も必要
Amazon Bedrock AgentCoreにWeb Search機能が一般提供開始、AIエージェントの回答を最新Web情報で根拠づけ

Amazon Bedrock AgentCoreにWeb Search機能が一般提供開始、AIエージェントの回答を最新Web情報で根拠づけ

AWSは2026年6月17日、Amazon Bedrock AgentCoreにWeb Search機能の一般提供を開始した。AIエージェントがユーザーからの質問に対し、最新のWeb情報を参照しながら根拠のある回答を提示できるようにする。トレーニングデータだけではカバーしきれない直近の出来事や新事実を、AWS環境内で安全に取得できる点が最大の特徴だ。

この機能は、Amazonが長年培ってきた検索インフラ上に構築されている。Alexa+やAmazon Quick、Kiroといった製品で実績のある基盤を活用し、WebインデックスとAmazon Knowledge Graphを組み合わせたマルチソースな根拠付けを実現する。検索クエリは外部APIプロバイダに送信されず、AWS環境内で完結するため、企業のガバナンス要件にも適合する。

本記事では、Bedrock AgentCore Web Searchの仕組み、料金体系、導入事例を詳しく解説する。

Web Search機能の概要と背景

Web Search機能の概要と背景

Bedrock AgentCoreの位置づけ

Amazon Bedrock AgentCoreは、AIエージェントの構築と運用を管理するフレームワークである。エージェントに必要なツールやデータソースとの接続をGatewayという仕組みで一元管理し、モデルの推論と外部機能の呼び出しを連携させる。今回発表されたWeb Searchは、AgentCore Gateway上で利用できる組み込みコネクタターゲットのひとつだ。

Web Searchが解決する課題

LLM(大規模言語モデル)は、学習時点のデータに基づいて回答を生成するため、つねに最新の情報を反映できるとは限らない。たとえば、企業の決算発表や法改正、製品アップデートなど、学習後に発生した出来事には対応できない。Web Searchを用いれば、エージェントがリアルタイムにWeb検索を実行し、得られたスニペットやURLを参照して回答を生成できる。回答には引用元が明示されるため、情報の信頼性をユーザーが確認しやすくなる。

仕組み:MCP接続とAmazon知識グラフによる根拠付け

仕組み:MCP接続とAmazon知識グラフによる根拠付け

MCP(Model Context Protocol)の役割

Web Searchは、MCP(Model Context Protocol)と呼ばれる標準プロトコルを介してAgentCore Gatewayに接続される。MCPを使うことで、エージェントは自然言語のクエリを送信し、関連性の高い検索結果(スニペット、URL、タイトル、公開日)を取得できる。GatewayがMCPターゲットとしてWeb Searchツールを仲介するため、開発者が個別に検索APIを実装する必要はない。

Amazon知識グラフとの統合

一般的なWeb検索に加え、Amazon Knowledge Graphの構造化データが検索結果に組み込まれる。これにより、単なるWebスニペットではカバーしきれない検証済みの事実情報をエージェントが参照できるようになる。AWSのブログ記事によれば、このマルチソースアプローチが従来のWeb検索だけに頼る場合と比較して、より的確な回答につながるとされている。

エージェントが回答を生成するまでの流れ

以下のデモは、ユーザーが質問してからエージェントが根拠付き回答を返すまでの一連のステップを図示したものだ。

STEP 1 ユーザーが自然言語で質問を送信
STEP 2 Bedrock AgentCore GatewayがMCP経由でWeb Searchツールを呼び出し
STEP 3 Amazonの検索基盤がWebインデックスと知識グラフを検索し、関連スニペットやURLを返す
STEP 4 AIエージェントが検索結果に基づいて回答を生成し、引用元を明示

STEP 3の段階でAmazon Knowledge Graphが活用される点が、単なるWeb検索を超えた信頼性につながる。エージェントは受け取った情報をそのまま返すのではなく、モデルが内容を推論した上で回答を構成するため、質問の文脈に合った自然な応答になる。

AWS環境内で閉じるセキュアなWeb検索の価値

AWS環境内で閉じるセキュアなWeb検索の価値

多くのAIエージェント向けWeb検索ソリューションでは、ユーザーのクエリやプロンプトが外部の検索APIプロバイダに送信される。これに対しBedrock AgentCoreのWeb Searchは、Amazon自身の検索インフラを使用するため、データがAWS環境の外に流出しない。これにより、機密性の高い業務データを扱う企業でも、ガバナンスやコンプライアンスの要件を満たしながらエージェントにWeb検索機能を組み込める。

従来の外部検索API利用(Before)
ユーザー クエリ送信 外部検索API
※データがAWS環境の外に送信されるリスク
Bedrock AgentCore Web Search(After)
VPC内のエージェント MCP経由で検索 Amazon検索基盤
※すべての通信がAWS内部で完結、外部へのデータ送信なし

AWSの説明によれば、この仕組みはAlexa+やKiroなどのプロダクトで培われた検索技術を基盤にしており、信頼性とスケーラビリティの両面で実績がある。ユーザーは外部の検索サービス契約やAPIキー管理を気にすることなく、AgentCoreの設定画面上でWeb Searchを有効化するだけで利用を開始できる。

料金体系と利用開始手順

料金体系と利用開始手順

料金詳細

Web Searchの料金は従量課金制で、エージェントが実行した検索クエリの数に応じて計算される。具体的には、1,000クエリあたり7ドルである。新規のAWS顧客には最大200ドル相当の無料利用枠も提供される。利用料はすべてAWSの請求に統合されるため、別途外部サービスへの支払い管理は不要だ。

セットアップ手順

Bedrock AgentCoreコンソール(us-east-1リージョン)にアクセスし、Gatewayを作成する。ターゲットの追加時に「MCP target」プロトコルと「Connectors」タイプを選択し、プリコンフィギュアされた「Web Search tool」を指定する。Gatewayの詳細ページに遷移すると、PythonやMCP Inspectorを用いた呼び出しコードのサンプルが表示されるため、これをコピーして自環境に組み込むだけで統合が完了する。

テスト用途であれば、MCP InspectorをGatewayのリソースURLに接続し、Web Searchツールにクエリを直接入力して動作を確認できる。実運用では、エージェントのプロンプト設計にWeb検索の呼び出しトリガーを組み込み、回答生成時に適宜検索が走るように構成することになる。

企業での活用事例

企業での活用事例

Benchling:科学研究の加速

ライフサイエンス分野のR&Dプラットフォームを提供するBenchlingは、早期アクセスを通じてWeb Searchを試験導入した。同社AIエージェント責任者Nicholas Larus-Stone氏によると、科学者が研究対象について質問すると、Benchling内の組織データと公開文献の両方に基づく回答が得られるようになったという。これにより、仮説生成の質が向上し、顧客のデータ管理ポリシーにも適合する安全な環境を維持できている。

Gen Digital:オンライン評判管理の強化

消費者向けセキュリティ製品を展開するGen Digital(Nortonブランド)は、Norton RevampというサービスにWeb Searchを組み込んだ。プロフェッショナルが自身のオンライン評判を構築する際、最新のトレンドや事実に基づいたコンテンツアイデアをエージェントが提案できるようになる。同社AI・イノベーション部門シニアディレクターIskander Sanchez-Rola氏は、すべてのクエリが信頼できるAWS環境内で処理される点を高く評価しているとコメントした。

いずれの事例でも、外部サービスを利用せずにAWS内で完結するセキュリティと、Amazon独自の検索インデックスによる高精度な情報取得が決め手となっている。

この記事のポイント

  • Amazon Bedrock AgentCoreでWeb Search機能が一般提供開始。MCP経由でWeb検索と知識グラフを統合し、エージェントの回答を最新情報で根拠づける
  • 検索クエリはAWS環境外に出ず、Amazonの検索インフラで処理されるため、データガバナンスとコンプライアンスに対応
  • 料金は1,000クエリあたり7ドルの従量課金。新規顧客向けに200ドル分の無料枠あり
  • BenchlingやGen Digitalなどの企業がすでに導入し、研究支援や評判管理の精度向上に活用している
  • us-east-1リージョンで利用可能。AgentCoreコンソールから数ステップで設定できる
MDN MCPサーバーでAIに正確なCSSブラウザ互換性情報を提供、開発効率が向上

MDN MCPサーバーでAIに正確なCSSブラウザ互換性情報を提供、開発効率が向上

MDN Web DocsがMCP(Model Context Protocol)サーバーを公開した。このサーバーを使うと、AIコーディングアシスタントにMDNの最新ドキュメントとブラウザ互換性データを直接読み込ませられる。CSSの新機能やブラウザサポートを正確に把握できるため、誤ったコード提案を防ぐことが可能だ。

特に、CSSの最新機能(light-dark()画像対応、:buffering疑似クラスなど)はLLMの学習データに含まれていないことが多い。MDN MCPを導入すれば、AIが正しい情報を参照して回答を生成するため、開発者はわざわざブラウザで互換性を調べる手間が省ける。

MDN MCPサーバーとは

MDN MCPサーバーとは
開発者の質問
「light-dark() CSS関数を画像で使う方法とブラウザサポートを知りたい」
MDN MCPサーバーが呼ばれる(計4回)
MDNのドキュメントと互換性テーブルを取得し、AIアシスタントに正しい回答を生成させる
AIが外部の最新データを参照することで、学習データの鮮度不足を補える。

MCPはAIツールが外部データソースに接続するためのオープンスタンダードだ。MDN MCPサーバーはこのプロトコルを使って、MDNの豊富なWebプラットフォーム情報(HTML・CSS・JavaScript・Web APIのリファレンス、ブラウザ互換性データ)をAIエージェントやIDEに提供する。これにより、AIが常に最新のWeb標準に基づいてコードを提案できるようになる。

MCPの基本とMDNの役割

MCP(Model Context Protocol)はAnthropicが中心となって策定したオープンプロトコルで、LLMが外部ツールやデータベースと通信するための共通インタフェースを提供する。MDN MCPサーバーはHTTPトランスポートで動作し、クライアント(VS CodeやClaude Codeなど)がリクエストを送ると、MDNのコンテンツAPIから必要な情報を抽出して返す仕組みだ。

たとえば、AIが「CSSのlight-dark()は画像でも使えるか」と問われた場合、通常のLLMは学習時の知識だけを頼りにする。しかしMDN MCPサーバーが接続されていれば、AIはリアルタイムで正式な仕様とブラウザ実装状況を取得し、誤った回答を防げる。

対応しているツール一覧

MDN MCPサーバーは主要な開発ツールと連携する。エディタではVS Code、Zed、Cursorがサポートされており、AIコーディング支援機能から直接MDNを参照できる。ターミナルベースのエージェントとしてはClaude Code、OpenAI Codex CLI、Google Antigravity CLI(旧Gemini CLI)が対応。チャットアプリではClaude Desktopで利用可能だ。

これらのツールにMCPサーバーを登録する手順は各公式ドキュメントに記載されている。基本はHTTPエンドポイントを指定するだけで、追加のAPIキーなどは不要だ。

なぜ今、MCPが必要なのか

なぜ今、MCPが必要なのか

Webプラットフォームの進化は速い。CSSだけを見ても、light-dark()の画像対応、@view-transition、:buffering疑似クラスなど、直近1年以内に実装が始まった機能は多い。AIの学習データは数カ月から1年以上前の情報で固定されているため、こうした新機能に関する質問には正確に答えられない可能性がある。

MDN Blogの記事では、Claude Code Opus 4.7を用いてテストを行った結果、MCPなしではWeb Serial APIについて「Firefoxでは未実装で、Mozillaの標準ポジションでは有害とされている」と誤った回答をしたと報告されている。実際にはFirefox 151でサポートが開始されており、MCPを有効にすることでこの誤りは解消された。

AIの回答が誤っていると、開発者はブラウザの実装状況を手動で調べ直す必要が生じる。MDN MCPはその手間を省き、AIが確かなソースに基づいて回答する仕組みを提供する。

実際のCSS機能で検証、MCP有無の比較

実際のCSS機能で検証、MCP有無の比較

light-dark()画像対応のブラウザサポート

light-dark()はカラースキームに応じて値を切り替えるCSS関数だが、画像も受け付ける。たとえば次のように書ける。

.profile-avatar {
  background-image: light-dark(url(avatar-light.png), url(avatar-dark.png));
}
ライトモード時の表示イメージ
‘); background-size:cover; border:3px solid #ccc; box-sizing:border-box;”>
明るい背景に合わせた画像が表示される
ダークモード時の表示イメージ
‘); background-size:cover; border:3px solid #666; box-sizing:border-box;”>
暗い背景に合わせた画像が表示される

light-dark()はOSのカラースキームに応じて自動で画像を切り替える。画像以外にもグラデーションやURLが使用可能だ。

このlight-dark()の画像対応について、Claude CodeにMCPなしで質問した場合、色の値に関する説明しか得られず、画像がサポートされていることは明確に示されなかった。一方、MCPを有効にすると、Firefox 150以降、Chrome(フラグ付き)でサポートされていることが即座に回答された。

:buffering疑似クラスとWeb Serial APIの誤情報

:buffering疑似クラスは、メディア要素がバッファリング中であることを検出するため、MCPなしでも正しいブラウザサポート情報が返された数少ない事例だ。しかしshadowrootslotassignment属性やWeb Serial APIについては、MCPなしでは誤った情報が目立った。

MCPなし(Before)
「Web Serial APIはFirefoxで未実装。Mozillaは有害と判断している」
「shadowrootslotassignmentはChrome 120、Safari 18.3でサポート」
※いずれも誤った情報
MCPあり(After)
「Web Serial APIはFirefox 151でサポート開始」
「shadowrootslotassignmentはFirefox 151が初の対応ブラウザ」

MCPを導入すると、最新のブラウザ互換性データが参照されるため、誤情報を防げる。

特にWeb Serial APIのケースでは、MCPなしのAIは「有害」という強い表現を使ってまで非対応と主張しており、誤った知識で開発を妨げるリスクがあった。MDN MCPはこのような誤解を回避し、確かな情報に基づいたコーディング支援を実現する。

導入方法と活用のポイント

導入方法と活用のポイント

Claude Codeでの設定手順

MDN MCPサーバーはHTTPエンドポイントが公開されており、対応クライアントでMCPサーバーとして追加するだけで利用できる。たとえばClaude Codeの場合、次のコマンドをターミナルで実行する。

claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/

この設定後、AIアシスタントがMDNの情報を必要とする質問を受け取ると、自動的にMCPサーバーへリクエストが送られ、最新のドキュメントが参照される。他のエディタやCLIツールでも同様に、MCPサーバーのURLを登録するだけで連携が完了する。

プライバシーと注意点

現在のMDN MCPサーバーは実験的な提供段階であり、使用時にはMDNのプライバシー通知を確認することが推奨されている。サーバーは利用者が送信したクエリを一時的に処理するが、データの取り扱いについては今後アップデートされる可能性がある。

また、MCPが参照するデータはMDNの公式コンテンツとブラウザ互換性テーブルであるため、正確だが、あくまでAIの出力はLLMの生成結果である点に注意が必要だ。複数の情報源と組み合わせながら活用するのが賢い使い方といえる。

この記事のポイント

  • MDN MCPサーバーは、AIツールにMDNの最新ドキュメントとブラウザ互換性データを提供する。
  • CSSの新機能(light-dark()画像対応、:bufferingなど)の正確な情報を得られる。
  • MCPなしではWeb Serial APIのように「未実装」と誤った回答をするケースがあった。
  • VS CodeやClaude Codeなど主要な開発ツールで利用可能。導入はURL登録のみ。
  • AIの回答が古い知識に依存するリスクを減らし、開発効率を高める。
AIエージェントがECデータを扱うには MCPでアクセスと安全を両立する方法

AIエージェントがECデータを扱うには MCPでアクセスと安全を両立する方法

AIエージェントにGoogle広告の運用を任せようとした検索広告担当者は、同じ話を口にする。パフォーマンスデータをエクスポートし、チャット画面に貼り付け、的確な回答を得て、翌日も同じ作業を繰り返す。

これは自動化ではない。手作業の窓口が変わっただけだ。AIツール自体に問題があるわけではない。主要なモデルは、適切なデータが目の前にあれば高度な分析をこなせる。課題は、そのデータをリアルタイムに、かつ人間がコピーして渡さなくても届けられるかどうかだ。

2026年現在も、ほとんどのPPCアカウントはAIエージェント登場以前とほぼ同じ運用フローにとどまっている。その根本原因は「データの壁」にある。本記事では、この壁を壊す技術であるMCP(Model Context Protocol)と、ECや広告運用の現場で安全に導入するための考え方を整理する。

「もっと良いプロンプト」では解決できない問題

広告プラットフォームは設計上、それぞれがサイロ化している。Google広告はコンバージョンを記録する。CRMはそのリードが商談化可能かを管理する。在庫システムはクリックされた商品がまだ倉庫にあるかを知っている。どのシステムも、意図的な配管なしには相互に会話しない。

検索広告の担当者は長年、このギャップを手作業で埋めてきた。週次のエクスポート、突合せ用のスプレッドシート、月曜朝には最新ではなくなっているダッシュボード。人が決まったスケジュールで橋渡しする分には成り立っていたが、AIエージェントに実行を委ねる瞬間、構造的な問題として立ちはだかる。

たとえば、Google広告上は表示回数も多く、許容範囲のCPA(顧客獲得単価)とCVR(コンバージョン率)を示すキーワードがあったとする。しかしHubSpotでは、そのコンバージョンは「商談不適格」とタグ付けされている。地域が違う、予算がない、まったく別の企業規模だ。エージェントには知る術がない。入札を続け、予算を消費し、問題は月次の振り返りでようやく表面化する。

これはプロンプトの問題ではない。データアクセスの問題だ。より良い指示文では修正できないが、より良いパイプラインなら解決できる。

MCPがエージェントにデータとスキルを渡す仕組み

MCPがエージェントにデータとスキルを渡す仕組み

Model Context Protocol(MCP)は、AIクライアントが外部のツールやデータソースと接続するためのオープン標準だ。個別のカスタム統合を書く代わりに、プラットフォームが一度MCPサーバーを公開すれば、ClaudeやChatGPTのエージェントモード、自社構築のエージェントなど、互換性のあるあらゆるAIクライアントが接続できるようになる。

これまでエージェントにGoogle広告とCRMと在庫システムを読ませようとすると、3つのコネクターを個別に作り、保守する必要があった。データソースが増えるたびに負荷は増大する。MCPは握手の手順を標準化し、インフラの複雑さを解消する。

従来(Before) 手作業によるデータ連携
担当者 Google広告からCSVエクスポート
ChatGPT 貼り付けられたデータを分析
担当者 翌日またエクスポート
※データが常に古く、CRMや在庫と突合できない
改善後(After) MCPによるリアルタイム接続
MCPサーバー Google広告・CRM・在庫に直接接続
AIエージェント ライブデータを取得し分析・実行
結果 条件に応じた自動調整が動作
※複数ソースを横断し、古いダッシュボード不要

この図のように、MCPを導入するとエージェントは必要なデータソースに直接アクセスできる。GoogleはすでにGoogle Ads API MCPサーバーをGitHub上でオープンソース化しており、エージェントがGAQL(Google Ads Query Language)クエリをライブアカウントデータに対して直接実行できる環境が整いつつある。

データが流れ始めると何が起こるか

データが流れ始めると何が起こるか

まずCRMとの断絶が解消される。Google広告とHubSpotの両方に接続したエージェントは、先月のコンバージョンを取得し、CRM上の商談結果と突合して、不適格リードを生んでいるキーワードを特定できる。そして、該当するキーワードの入札を自動的に下げる。これまで半日かかっていたループが、スケジュール実行に変わる。

在庫も同じ盲点だった。Shopifyに接続したエージェントは、週末キャンペーンが開始される前に在庫レベルをチェックできる。SKUがしきい値を下回ったら、関連する商品グループを一時停止し、もはやコンバージョンが見込めないページへのトラフィックを未然に防ぐ。

データパイプラインの構築作業自体も高速化する。PPC専門家のLars Maat氏は、Pythonの経験がない状態から、Google Maps APIとGoogleのThings To Do機能、Ahrefsを接続し、駐車場クライアント向けに最適化されたランディングページを生成するパイプラインをわずか2週間で構築したという。必要なデータをAIの前に正しく置くことさえできれば、あとはエージェントが実行する。

アクセスだけでは足りない ガードレールなきリスク

ここからが本題だ。書き込み権限のあるGoogle広告アカウントへのアクセスを、確率的な言語モデルの手に渡すことは、新たなリスクカテゴリを生む。キャンペーンを一時停止できるエージェントには、どのしきい値で動作をトリガーするか、発動前に誰に通知するか、どのキャンペーンタイプは人間の承認が必要かといったパラメータが不可欠だ。こうした制約はAIツールの内部には存在せず、周囲に構築しなければならない。

Anicca Digital創設者で英国有数のペイドメディア実務者であるAnn Stanley氏は、効果的なAI導入を「サンドイッチ」にたとえている。最前線には目標を理解し正確な指示を与える人間がおり、最後尾には出力をレビューし何を反映するか判断する人間がいる。AIはその中間で実行を担う。出力の品質は、投入されるデータの品質と、中間層に制約が存在するかどうかに左右される。

Googleがオープンソース化したMCPサーバーは優れたインフラだが、安全網ではない。エージェントが構築したクエリや変更を忠実に実行し、エージェントがキャンペーンIDを誤認したり誤ったルックバックウィンドウを選んだりすれば、その結果は広告アカウントが引き受けることになる。LLMは確率的であり、広告プラットフォームのAPIはそうではない。だからこそ、その間に座る仕組みが必要だ。

Optmyzr MCPが提供する安全な実行レイヤー

PPC管理プラットフォームを提供するOptmyzrは、Google広告の実際の振る舞いを10年以上にわたってコード化してきた。APIが公開する情報だけでなく、設定間の相互依存関係、キャンペーンタイプごとのエッジケース、重複キーワードの真偽判定といったナレッジが同社のビジネスインテリジェンス層として蓄積されている。OptmyzrのMCPコネクターは、その知見をAIエージェントが借りられるようにするためのものだ。

ClaudeやChatGPT、あるいはチームのカスタムエージェントがOptmyzr MCPに接続すると、同プラットフォームで提供されているSidekick機能と同等の能力を得る。豊富なフィルタとセグメントによるPPCレポートの取得、設定済みアラートの表示と編集、マーチャントフィードの詳細取得、全アクティブアカウントのポートフォリオ健全性の要約などが可能になる。そして最も見落とされがちなのが、自然言語の指示からルールエンジン戦略を生成し実行する機能だ。

このアプローチが、多くの自作セットアップと異なる理由は3つある。

  • 一文から戦略を生成し、Optmyzr内で実行する。 MCPのルールエンジン機能は、「過去14日間でCPAが目標から20%以上乖離したキャンペーンを見つけ、入札調整戦略を立案して」といった自然言語の指示を受け取り、対応する戦略を生成してアカウントに適用し、結果を分析して推奨事項を返す。LLMが意図を書き、Optmyzrの決定論的エンジンが作業を行う。この実行と制御の層は、生の広告プラットフォーム向けMCPにはないものだ。
  • クロスアカウントかつポートフォリオ規模の分析が可能。 OptmyzrのUI内のSidekickは単一アカウントの単一ページの文脈では優れている。MCPは「保有する80アカウントのうち、今月除外キーワードの浪費が上昇傾向にあるのはどれか」といった問いに答えるために使う。Optmyzr MCPに接続したAIクライアントは、1回のプロンプトで全アカウントに問い合わせを展開できる。代理店が生のAds APIではなくOptmyzr MCPを選ぶ最大の理由がここにある。
  • Sidekickから継承されるガードレール。 Optmyzr MCPを通じて実行されるすべてのアクションは、Sidekickを直接使用する場合と同じ権限とワークフローロジックの下で動作する。エージェントは分析、戦略立案、アラート通知を行い、変更案を作成する。実際の変更は人間または既存の承認フローが送り出す。Stanley氏の言う「安全のサンドイッチ」が製品に組み込まれている。

結果として、APIの到達範囲と、AIエージェントというカテゴリが生まれる前からこの分野にいるプラットフォームの判断力、そして自前で回路遮断器を構築せずに済む安全な姿勢を兼ね備えたエージェントが、ポートフォリオ全体で稼働する。

実践的な導入ステップ

実践的な導入ステップ

まずは読み取り専用で様子を見たいなら、Windsor.aiやZapierのMCP統合が最も手早い。ガードレールの管理に自信があるなら、GitHub上のGoogle Ads API MCPサーバーで正確なGAQL制御を手に入れられるが、そのぶん安全層の構築は自前になる。

ミスが許されないクライアントアカウントを運用している場合、あるいはAIエージェントにシニアPPCストラテジストの判断力で全ポートフォリオを考えさせたい場合は、Optmyzr MCPが安全に「鍵を渡せる」エージェントへの最短経路だ。Claude Desktop(カスタムコネクターまたは手動設定)、Claude Code、ChatGPT(Developer Modeアプリ)、その他MCP互換クライアントで動作し、セットアップは数分で完了する。Optmyzrの設定画面でAPIキーを生成し、サーバーURLをAIクライアントに貼り付けるだけで、プロフィール上の全アクティブアカウントにエージェントが接続される。

データの壁はどちらにせよ崩れつつある。問題は、エージェントがその壁を計画を持って通り抜けるか、それともプロンプトと祈りだけで通り抜けようとするかだ。

この記事のポイント

  • AIエージェントが実務で使えない最大の原因は、データソースとの接続不足にある
  • MCPはAIクライアントと各種ツールを標準化された方法で接続し、手作業のエクスポートを不要にする
  • 書き込みアクセスにはガードレールが必須で、人間の承認や制約の設計が欠かせない
  • Optmyzr MCPは、10年以上のPPC知見と安全な実行レイヤーを兼ね備えた選択肢であり、クロスアカウント分析や自然言語からの戦略実行を実現する
Google Cloud、AlloyDB向けリモートMCPサーバーがGA。AIエージェントとDBの安全な統合を実現

Google Cloud、AlloyDB向けリモートMCPサーバーがGA。AIエージェントとDBの安全な統合を実現

Google CloudがAlloyDB向けのリモートMCP(Model Context Protocol)サーバーの一般提供を発表した。これまでローカル開発が中心だったMCPだが、本番環境での運用に耐えるフルマネージドな仕組みとして登場した。AIエージェントが企業のオペレーショナルデータベースに直接アクセスし、安全にクエリを実行できるようになる。

この記事では、リモートMCPサーバーが解決する技術的課題と、AlloyDBを基盤にしたエージェントアプリケーションの構築方法を解説する。データの鮮度、セキュリティ、運用負荷のバランスを取るアーキテクチャを具体的に示す。

リモートMCPとは何か(ローカルMCPとの違い)

リモートMCPとは何か(ローカルMCPとの違い)

MCP(Model Context Protocol)とは、大規模言語モデル(LLM)が外部のデータソースやツールと安全に通信するためのオープン標準プロトコルだ。Anthropicが提唱し、現在では多くのAIエージェントフレームワークで採用されている。従来は開発者のローカルマシン上で動作する「ローカルMCPサーバー」が主流だった。

ローカルMCPサーバーは標準入出力(stdio)を使ってプロセス間通信を行う。これは開発段階では手軽だが、本番環境に持ち込むと途端に問題が顕在化する。複数のエージェントインスタンスが同時にデータベースへアクセスする場合、プロセス管理が複雑化し、ネットワーク越しのセキュリティ確保も難しくなる。

従来のローカルMCP構成
AIエージェント stdio通信 ローカルMCPサーバー
プロセス管理が手動、スケール時に通信が不安定化しやすい
リモートMCP構成(今回のGA)
AIエージェント HTTPS リモートMCPサーバー AlloyDB
フルマネージド、IAM認証、自動スケーリング

リモートMCPサーバーは、これらの課題をHTTPエンドポイント経由で解決する。Google Cloudのマネージドインフラ上で動作し、OAuth 2.0ベアラートークンによる認証とIAM(Identity and Access Management)によるきめ細かな権限制御を提供する。エージェント開発者はインフラ管理から解放され、クエリ実行に集中できる。

なぜAlloyDBと組み合わせるのか

AlloyDBはGoogle CloudのフルマネージドPostgreSQL互換データベースだ。標準PostgreSQLと比較して、ベクトル検索では最大6倍高速、フィルタ付きクエリでは最大10倍高速というパフォーマンスを備える。ScaNNインデックスを使えば100億ベクトル規模まで拡張でき、AIエージェントのRAG(検索拡張生成)ワークロードに最適化されている。

さらにAlloyDBには、データベース内で直接埋め込みベクトルを生成するAI Functionsや、Gemini Enterprise Platformモデルを使った検索結果のリランキング機能が組み込まれている。エージェントがデータベースにクエリを投げるだけで、最新のオペレーショナルデータに基づいた回答を得られる。データの鮮度を保つためのETLパイプラインが不要になるケースも多い。

リモートMCPサーバーが解決する5つの本番課題

リモートMCPサーバーが解決する5つの本番課題

Google Cloudブログの発表によると、リモートMCPサーバーは単なる通信方式の変更にとどまらない。本番環境でAIエージェントを運用するチームが直面する、以下の5つの課題を包括的に解決する設計になっている。

集中管理 Agent RegistryでMCPサーバーを一元発見・管理。散在する設定ファイルの時代は終わる
フルマネージド HTTPエンドポイントはGoogle Cloudが運用。デプロイやメンテナンスが不要
きめ細かな権限制御 IAMでテーブルやビュー単位のアクセス制御。読み取り専用SQLツールで誤操作を防止
運用操作の自動化 エージェントがインスタンス更新、バックアップ、リストアまで実行可能
セキュリティ保護 Model Armorでプロンプトインジェクションやデータ漏洩を防止。全操作はCloud Audit Logsに記録
集中管理  フルマネージド  権限制御  運用自動化  セキュリティ

特に注目すべきはIAMによる権限制御だ。従来のデータベース接続では、共有パスワードやAPIキーを使うことが多かった。しかしリモートMCPでは、エージェントごとに特定のテーブルやビューへのアクセス権をIAMで付与できる。読み取り専用のSQL実行ツールを選択すれば、エージェントが誤ってデータを削除するリスクを根本から排除できる。

Model Armorによるプロンプトセキュリティ

リモートMCPサーバーは、Google CloudのModel Armorと統合されている。Model Armorはプロンプトとレスポンスの両方をスクリーニングし、プロンプトインジェクション攻撃や機密データの意図しない流出を防ぐ。エージェントのサービスアカウントが広範なデータベース権限を持っていても、Model Armorがデータの出し方をフィルタリングする仕組みだ。

たとえば、エージェントが顧客のクレジットカード番号を含むカラムにアクセスできる権限を持っていたとしても、Model Armorがレスポンスからその情報を除去できる。これは「権限はあるが出力は制限する」という新しいセキュリティモデルであり、ゼロトラストの考え方をAIエージェントに適用した形だ。

エージェントから見たAlloyDBの強み

エージェントから見たAlloyDBの強み

リモートMCPサーバーは接続の仕組みを提供するが、その先にあるデータベース自体の性能も重要だ。AlloyDBはエージェントアプリケーションに特化したいくつかの特徴を持つ。

まず、ベクトル検索性能だ。ScaNNインデックスを使うと、標準PostgreSQLの最大6倍の速度でベクトルクエリを実行できる。100億ベクトルまでスケールするため、大規模なRAGアプリケーションでもパフォーマンスが劣化しない。フィルタ条件付きのベクトル検索では最大10倍高速化される。これは「直近30日以内のドキュメントから類似検索」のような実用的なクエリで差が出る。

次に、ハイブリッド検索とリランキングだ。RUM(RUMインデックス / Row Usage Matrix)を使った全文検索とベクトル検索の組み合わせや、Reciprocal Rank Fusionによる結果の融合が可能だ。さらにGemini Enterprise Platformモデルを使ったインテリジェントなリランキングにより、エージェントは最も関連性の高い情報を優先的に取得できる。

また、AlloyDBのAI Functionsはデータベース内部で埋め込みを生成する。外部の埋め込みAPIを呼び出す必要がなく、数百万件の埋め込みを効率的に生成できる。Lakehouse Federationを使えば、BigQueryの分析データやIcebergテーブルのアーカイブデータにも、同じPostgreSQLインターフェースから透過的にアクセスできる。

AlloyDB 単一のPostgreSQLインターフェース
オペレーショナルデータ
最新のトランザクション、在庫、配送情報
分析データ(BigQuery)
Lakehouse Federation経由で透過アクセス
アーカイブ(Iceberg)
長期保存データへのシームレスなクエリ
AIエージェントはデータの所在を意識せず、単一のクエリで全データソースにアクセスできる

AIエージェントにとって重要なのは「データの鮮度」と「アクセスの容易さ」だ。AlloyDBのリアルタイム埋め込み生成とLakehouse Federationの組み合わせにより、エージェントは最新のオペレーショナルデータと過去の分析データを区別なく扱える。配送車両の位置情報のような刻々と変化するデータでも、クエリを発行した瞬間の状態を取得できる。

実際の導入手順とデモの流れ

実際の導入手順とデモの流れ

Google Cloudは今回のGA発表にあわせて、Codelab(ハンズオン形式のチュートリアル)を公開した。導入手順は以下の4ステップに整理されている。

STEP 1 AlloyDB、Compute Engine、Gemini EnterpriseのAPIを有効化
STEP 2 AlloyDBクラスタをデプロイし、データベースとサンプルデータを作成
STEP 3 Data Access APIをAlloyDBインスタンスで有効化
STEP 4 MCPクライアントにエンドポイント(https://alloydb.googleapis.com/mcp)とOAuth 2.0トークンを設定

接続が確立すると、エージェントは自動的にデータベースのスキーマを把握する。テーブル名やカラム名をイントロスペクションクエリで取得し、ユーザーの質問に応じて適切なJOINや集計クエリを組み立てられる。たとえば「過去24時間で最も遅延が発生している配送ルートは?」という質問に対して、エージェントが配送テーブルと車両テーブルをJOINし、リアルタイムの位置情報と組み合わせて回答する。

AIエージェントが実行できる操作の範囲

リモートMCPサーバー経由でエージェントが実行できる操作は、単なるSELECTクエリにとどまらない。AlloyDBのツールセットを使うと、以下のような運用操作も可能になる。

  • データのエクスポートとインポート
  • バックアップの作成とリストア
  • クラスタの設定更新
  • AI Functionsを使ったテキストのランキング(AI.RANK())

もちろん、これらの操作はIAM権限の範囲内でのみ実行される。読み取り専用のSQLツールを選択していれば、データ定義や変更を伴う操作はブロックされる。本番環境での安全な運用を第一に設計されている点が重要だ。

導入時に検討すべきポイント

導入時に検討すべきポイント

リモートMCPサーバーのGAは、AIエージェントとデータベースの統合を大きく前進させる。しかし導入にあたっては、いくつかの点を事前に検討する必要がある。

まず、コスト構造の把握だ。AlloyDB自体がエンタープライズ向けのプレミアムデータベースであり、さらにMCPサーバーの利用にもGoogle Cloudの料金が発生する。30日間の無料トライアルが提供されているので、まずは小規模なクラスタで検証し、ワークロードに応じたコストを見積もることを推奨する。

次に、IAMポリシーの設計だ。エージェントに必要最小限の権限を付与する「最小権限の原則」を徹底する必要がある。テーブル単位、カラム単位でのアクセス制御が可能だが、データベースの規模が大きくなるとポリシー管理が複雑化する。事前にアクセス制御のルールを整理しておくことが重要だ。

最後に、プロンプト設計の重要性も変わらない。MCPサーバーがデータへのアクセスを提供しても、エージェントが適切なクエリを生成できるかどうかはプロンプトの質に依存する。スキーマの説明やクエリの方針をプロンプトに含めることで、より正確な結果を得られる。

この記事のポイント

  • AlloyDB向けリモートMCPサーバーがGAとなり、HTTPエンドポイント経由でAIエージェントが安全にデータベースへアクセス可能になった
  • IAMによるテーブル単位の権限制御と、Model Armorによるプロンプトセキュリティで本番運用に耐える設計
  • AlloyDBのベクトル検索性能とAI Functionsの組み合わせにより、RAGアプリケーションの構築が効率化される
  • 30日間の無料トライアルとCodelabが提供されており、小規模な検証から始められる
VS Codeで始めるGitHub超入門!リポジトリ作成からAI活用まで

VS Codeで始めるGitHub超入門!リポジトリ作成からAI活用まで

VS CodeとGitを連携させれば、エディタから離れることなくGitHub上のバージョン管理が完結する。コードを書きながらコミット、ブランチの切り替え、プッシュまで行えるため、作業の中断が大幅に減る。

本記事では、フォルダの初期化から変更の追跡、ブランチのマージ、リモートへの公開、さらにMCP(Model Context Protocol)を使ったAI支援まで、実務で頻繁に使う一連の流れを手順を追って解説する。Gitの概念を簡単な言葉で補足しながら進めるので、バージョン管理が初めてでも迷わないはずだ。

VS Codeで始めるGitとGitHubの基本

VS Codeで始めるGitとGitHubの基本

GitとGitHubの役割

Gitはソースコードの変更履歴を管理するプログラムだ。GitHubはその履歴を保管するリモートの場所で、いわば「コードの倉庫」である。Gitでローカルに記録した履歴をGitHubにアップロードすることで、チームでの共有やバックアップが実現する。

VS Codeが開発効率を上げる理由

VS Code(Visual Studio Code)はMicrosoftが提供する無料のソースコードエディタだ。内部にGit機能が統合されており、GUI上でリポジトリの初期化やコミット、ブランチ操作を行える。ターミナルとエディタを行き来する手間を省き、エディタのサイドバーやコマンドパレットからほとんどのGit操作を実行できる。

リポジトリの初期化と最初のコミット

リポジトリの初期化と最初のコミット

まずはローカルのフォルダをGitリポジトリとして初期化し、ファイルを追跡してコミットする流れを確認しよう。

VS Codeを起動し、左側のアクティビティバーにあるExplorerアイコン(重なったファイルのような形)をクリックする。次に「Open Folder」ボタンから、GitHubに上げたいコードが入ったフォルダを開く。

続いて、アクティビティバーの上から3番目にあるSource Controlアイコンを選択する。すると「Initialize Repository」ボタンが表示されるので、これをクリックする。これでフォルダがGitリポジトリとして機能し始める。

初期化直後は、Source Controlパネル内のファイル名の横に「U」(Untracked)が表示される。ファイルを追跡対象にするには、ファイル名の隣のプラス記号をクリックする。全ファイルを一括でステージングしたい場合は「CHANGES」の右にあるプラスを押せばよい。ステージングされるとファイルの状態は「A」(Added)に変わる。

ステージングした変更を記録するには、Source Controlパネル上部のメッセージ入力欄にコミットメッセージを記入し、「Commit」ボタンを押す。ここでCopilotの提案機能を使えば、差分に合ったメッセージを自動生成することも可能だ。

ブランチの作成と切り替え

ブランチの作成と切り替え

コマンドパレットからのブランチ作成

デフォルトでは通常「main」ブランチが使われる。新機能の開発や修正作業は、別のブランチを切って進めるのが一般的だ。

Shift + Command + P(Mac)またはCtrl + Shift + P(Windows)でコマンドパレットを開き、「create branch」と入力する。候補から「Git: Create Branch…」を選び、任意のブランチ名(例「new-features」)を入力してEnterで確定する。すると新しいブランチが作成され、自動的にそのブランチに切り替わる。ウィンドウ左下のブランチ名表示で確認できる。

作業ブランチでの変更と確認

新しいブランチ上でコードを編集すると、後述するようにエディタの左側(ガター)に色付きのインジケータが現れる。この状態でファイルを保存し、Source Controlパネルから変更をステージングしてコミットする流れは先ほどと同じだ。

変更の追跡と差分の確認

変更の追跡と差分の確認

ガターに表示される変更インジケーター

VS Codeでファイルを編集すると、行番号の左側にあるガターと呼ばれる領域に色分けされた目印が表示される。新しく追加した行には緑色のバー、既存の行を修正した箇所には青色の模様付きバー、行を削除した場所には赤色の矢印が現れる。これによって、どの変更が未コミットなのかを瞬時に把握できる。

エディタ上の変更インジケーター(例)
1 function greet() {
2 const name = getParam();
3 alert(“Hello, ” + name);
4 console.log(“debug”);
5 }
追加行  変更行  削除行(ガターに三角で表示)

このように、エディタの左側にある「ガター」に色付きのインジケーターが表示され、どの行を追加・変更・削除したかが一目でわかる。

差分の表示(並列表示とインラインビュー)

変更内容を詳しく比較したいときは、Source Controlパネルでファイル名をクリックする。すると左右に分割された差分ビューが開き、変更前後のコードを横に並べて確認できる。分割ビューの右上にある三点リーダーから「Inline View」を選ぶと、ひとつの画面内に差分がインラインで表示される。このビュー上で直接編集を加えることも可能だ。

ブランチのマージとGitHubへの公開

ブランチのマージとGitHubへの公開

マージ手順

作業ブランチでの変更をmainブランチに取り込むには、まずmainブランチに切り替える。ウィンドウ左下のブランチ名をクリックし、表示される一覧から「main」を選択する。その後、Source Controlパネルの三点リーダーから「Branch」にカーソルを合わせ、「Merge…」をクリックする。マージ元として先ほどまで作業していたブランチを選べば、mainブランチに変更が統合される。

リポジトリのプッシュと公開

ローカルのリポジトリをGitHub上に公開するには、Source Controlパネルにある「Publish Branch」ボタンを押す。VS Codeが公開時の可視性(プライベートかパブリックか)を尋ねてくるので、目的に合わせて選択する。処理が完了すると、通知からそのままGitHub上のリポジトリを開ける。

リポジトリのクローン

リポジトリのクローン

既存のリポジトリを手元に複製して作業したい場合は、GitHubのリポジトリページで緑色の「<> Code」ボタンをクリックし、URLをコピーする。VS Codeのコマンドパレットを開き「clone」と入力して「Git: Clone」を選び、URLを貼り付ける。保存先フォルダを指定すると、クローンが開始される。完了後に「Open」を選択すれば、すぐにローカルで開発を始められる。

MCPでAIを活用する

MCPでAIを活用する

GitHub MCP拡張機能のインストール

MCP(Model Context Protocol)は、AIツールが安全に外部サービスと連携するためのプロトコルだ。VS CodeでGitHubのMCPを利用すると、Copilotチャットがリポジトリの情報を参照しながらコード生成やIssue作成を行えるようになる。

アクティビティバーのExtensionsアイコンを開き、「@mcp github」で検索する。該当するGitHub公式の拡張機能をインストールし、認証を許可すると、下部のパネルにMCPサーバーが追加される。これで準備は完了だ。

Copilotチャットとの連携

チャットウィンドウから自然言語で「フラッシュカードアプリに新機能を追加して」などと指示すると、Copilotが必要なツールを自動的に呼び出し、コードやIssueを生成する。手作業でファイルを開いて確認していた手順をAIに任せられるため、プロトタイピングの速度が格段に上がる。

この記事のポイント

  • VS Codeに統合されたGit機能を使えば、エディタだけでコミットやブランチ操作が完結する
  • リポジトリの初期化から最初のコミットまでは四つのステップで完了
  • ガターの色分けインジケーターで、追加・変更・削除を瞬時に識別できる
  • ブランチのマージやGitHubへの公開もボタンひとつで実行可能
  • MCP拡張機能を導入すると、Copilotがリポジトリの文脈を理解したAI支援を提供する
WooCommerceがClaude連携の実験プラグインを公開、AI店舗分析の新形

WooCommerceがClaude連携の実験プラグインを公開、AI店舗分析の新形

WooCommerceの開発チームが、AIアシスタント「Claude」とECサイトを直接連携させる実験的プラグインを公開した。このプラグインは、単にAIがサイトのデータを読み取るだけでなく、店舗運営者が実際に求める「売上の傾向分析」や「クーポンの効果測定」といった問いに、具体的で意味のある答えを返すことを目指している。

発表元のWooCommerce Developer Blogの記事によれば、これは「Radical Speed Month」と名付けられた社内実験プロジェクトの一環だ。新機能の発表でも、将来のロードマップへのコミットメントでもない。あくまでアイデアを形にし、コミュニティからのフィードバックを得るための試金石である点が強調されている。

実験「WooCommerce for Claude」が解決しようとする課題

実験「WooCommerce for Claude」が解決しようとする課題

AIとWebサービスの連携は、APIを通じて生のデータを取得させるだけでは不十分だ。データの文脈や、事業者にとっての意味まで理解しなければ、役に立つ回答は得られない。

この実験の核心は、「どうすればAIを単なるデータ呼び出しツールではなく、店舗運営の実用的な相談相手にできるか」という問いにある。WooCommerceの開発チームは、この課題に対して3つの仕組みを基盤となるMCP(Model Context Protocol)の上に構築した。

MCPとは、AIモデルが外部のツールやデータソースと安全にやり取りするための共通規格だ。すでにWooCommerceのコアには開発者向けプレビューとしてMCPサポートが組み込まれている。この実験プラグインは、その仕組みを拡張し、AIに対してより深い店舗理解を与えることを狙っている。

従来のAI連携の課題
AIが生の受注データを取得 データの意味や事業文脈を理解できない
「先週の売上は?」という質問 単なる数字の羅列で終わる
WooCommerce for Claudeのアプローチ
事前集計された分析データ 「先週の売上は4%減、要因はカテゴリAの不振」
店舗知識レイヤー 事業内容や商品カタログの構造をAIが事前に把握
従来の課題  新しいアプローチ

このデモで示したように、AIに「考えるための材料」を構造化して与えることが、この実験の設計思想だ。単に問い合わせの窓口を作るのではなく、AIが店舗の状態を理解した上で回答できるようにする。

分析スキル

店舗運営者が本当に知りたい質問に対して、事前に集計された回答を返す仕組みだ。「今週の売上はどうだったか」「どの商品が売上を牽引しているか」「クーポンは効果を発揮しているか」といった質問が想定されている。

重要な点は、これらの分析が商品投稿(wp_posts)の生データを直接参照するのではなく、WooCommerceの分析用参照テーブルに対して実行されることだ。これにより、データベースへの負荷を抑えつつ、高速に意味のある集計結果を返せる。

知識レイヤー

AIがツールを呼び出す前に、店舗のプロフィール、カタログのスキーマ、ポリシー、拡張された商品データをMCPリソースとして露出させる層だ。これにより、AIは「どのような店舗なのか」という文脈を最初から理解した状態で対話を始められる。

たとえば、投資家に店舗を説明するような抽象度の高い質問や、返金が多い注文を洗い出すような具体的な調査にも、前提知識を持って対応できるようになる。

AI準備スコアリングエンジン

商品の完全性、スキーマの網羅率、コンテンツの品質、ポリシーの完全性という4つの要素を重み付けし、0から100のスコアを算出する。その上で、改善すべき項目を優先順位付きのリストとして提示する機能だ。

このスコアは、AIが店舗データをどれだけ正確に解釈できるかの指標となる。データが整備されていない店舗では、AIの回答精度も下がるという前提に立った、実用的な診断ツールといえる。

実際の使用感とセットアップ

実際の使用感とセットアップ

プラグインを導入すると、1つのエンドポイント(/wp-json/woocommerce-claude/mcp)がWordPressの「Abilities」として登録される。別プロセスやcronによる同期処理は一切不要で、MCPリクエストが来たときにだけ動作する省リソース設計だ。

Claude Desktopとの接続は、ワンクリックの.mcpbバンドルファイルで完結する。手動セットアップの場合も、読み取り専用のWooCommerce REST APIキーがあらかじめ埋め込まれたJSONスニペットが店舗ごとに生成されるため、煩雑な設定は不要だ。

接続後は、自然言語で以下のような質問を投げかけられる。

  • 過去7日間の売上が振るわないが、何が変わったのか?商品別、カテゴリ別、時間帯別に分解してほしい
  • 前回のプロモーションは収益を押し上げたのか、それとも定価販売からの付け替えにすぎないのか
  • 新しい投資家になったつもりで、この店舗の全体像を説明してほしい。強み、リスク、成長機会は何か
  • 現在の収益漏れはどこにある?最大の値引き、最大の返金、支払い保留や失敗で滞留している最古の注文を洗い出して
  • 売上のうちリピート購入者の割合は?どの商品が顧客を呼び戻しているのか
  • カタログのAI準備スコアを監査し、最も減点の大きい項目と、最初に改善すべき点を教えてほしい

これらの質問は、単なるデータの抽出ではなく、分析と洞察を求めるものだ。AIが「構造化された店舗知識」を持っているからこそ、意味のある回答が可能になる。

拡張開発者向けの設計思想

拡張開発者向けの設計思想

このプラグインが実験として公開された目的の一つは、エクステンション開発者からのフィードバック獲得だ。プラグインはプロバイダーパターンを採用しており、あらゆる拡張機能がAIの見る知識レイヤーに自らのデータを流し込める。

add_action( 'woocommerce_claude_register_providers', function( $registry ) {
    $registry->register( new My_Extension_Provider() );
});

このコードが示すように、開発者は独自のプロバイダーを登録するだけで、AIが参照できる情報を拡張できる。さらに、AI準備スコアに独自の評価基準を追加したり、出力される商品データをフィルタリングしたりすることも可能だ。

開発チームは、この「プロバイダー + アビリティ + 単一MCPエンドポイント」という設計図が、実際にエクステンション作者が採用したいと思える形かどうかを検証したいと考えている。

Before(ベースのMCP連携のみ)
AIが参照できるのは基本APIの範囲
店舗の文脈や事業知識はAI側にない
After(WooCommerce for Claude導入後)
拡張プラグインのプロバイダー登録 知識レイヤーが拡張される
カスタムAI準備スコア因子を追加 診断精度が向上
エンドポイントは1つに集約 シンプルな構成を維持
Before  After

デモで示したとおり、プロバイダーパターンの追加により、AIが店舗について持つ知識の幅が大きく変わる。このアーキテクチャがコミュニティに受け入れられれば、サードパーティ製プラグインとの連携も大きく加速するだろう。

この実験が探る実用性とリスク

この実験が探る実用性とリスク

開発チームは、この実験が公式機能でも完成品でもないことを明確にしている。Radical Speed Monthの成果物の一部は将来の正式プロダクトになるが、多くはならない。このプラグインがどちらの道をたどるかも、まだ決まっていない。

だからこそ、実店舗や制作会社の環境でのテストが求められている。特に知りたいのは、以下の3つの失敗モードだ。

  • AIが店舗運営者には実行不可能な提案をしてしまわないか
  • 集計データから個人情報や秘匿すべきビジネス情報が漏洩しないか
  • 大規模カタログ(シードされたデモ店舗よりはるかに大きい規模)でのパフォーマンスは許容範囲か

机上の設計では見えない問題を、実際の多様な店舗環境で洗い出すことが、この公開テストの最大の目的だ。

テスト環境と始め方

テスト環境と始め方

リポジトリはGitHubで公開されており、クローン後にcomposer installを実行して有効化するだけで試せる。ローカル開発環境は、npx @wordpress/env start コマンドでWordPress、WooCommerce、そして本プラグインが立ち上がる。

テスト用に、24ヶ月分・5000件の注文データを生成する決定論的シードスクリプトが付属している。これにより、分析機能が十分なデータを基に動作する様子を確認できる。

開発チームは、AIが自信満々に間違った回答をしたケースや、拡張機能の開発者体験に違和感があった場合など、あらゆるフィードバックをGitHubのIssueで求めている。この実験が将来の製品に繋がるかどうかを判断する材料として、コミュニティのテスト結果が重視されているのだ。

この記事のポイント

  • WooCommerce for Claudeは、AIと店舗の新しい連携形を模索するRadical Speed Monthの実験プロダクトである
  • 分析スキル、知識レイヤー、AI準備スコアの3層構造で、AIが「文脈を理解した回答」を返せるように設計されている
  • プロバイダーパターンにより、サードパーティ拡張がAIの知識ベースに自ら統合できる拡張性を持つ
  • 公式機能やリリース予定のものではなく、実店舗環境でのテストフィードバックを目的としている
  • データプライバシーと大規模カタログでのパフォーマンスが、現時点で確認すべき主要な論点である
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の最適性確認や本番操作の運用ルール整備が推奨される