Agentsとは？AIエージェントとMCP

《 Cloudflare完全ガイド 目次へ 》

第7章もこれが最後のページです。ここまでは、AIに「答えさせる」話でした。質問を受けて、必要なら自分のデータを検索して、文章を返す。RAGもAI Searchも、その枠の中にあります。

このページで扱うのは、AIに「行動させる」話です。AIが自分で判断して道具を使い、結果を見て次の手を決め、タスクを最後まで進めていく――それがAIエージェントです。そして、そのエージェントに道具を持たせるための共通規格がMCPです。

Cloudflareがこの分野で強い理由は、第5章で学んだDurable Objectsにあります。少し意外に思えるかもしれませんが、読み進めればつながります。

このページで分かること

• AIエージェントとは何で、ワークフローやコパイロットと何が違うのか
• なぜエージェントにDurable Objectsが向いているのか
• Cloudflare Agents SDKでできること
• MCP（Model Context Protocol）とは何か
• エージェントを作るときに注意すべきこと

AIエージェントとは

エージェントとは、道具の使い方と進め方を自分で判断しながら、タスクを自律的に実行するAIの仕組みです。

似た言葉との違いを整理すると、輪郭がはっきりします。

旅行の手配を例にすると分かりやすくなります。

• ワークフロー：航空券を調べ、ホテルを調べ、結果を返す。この順番は変わりません。想定外の事態には対応できません
• コパイロット：「この便が安いですよ」と教えてくれますが、予約するのはあなたです
• エージェント：予算と日程を渡すと、自分で調べ、比較し、満室なら別の候補を探し、予約まで進めます

第5章で扱ったWorkflowsがまさに1つめにあたります。エージェントはその対極で、同じ入力でも実行ごとに違う道筋をたどり得るという点が本質的な違いです。

エージェントを構成する3つの要素

• 判断エンジン：次に何をするかを決める部分。通常はLLMが担います
• 道具（ツール）：実際に何かを行う手段。API呼び出し、検索、ファイル操作など
• 記憶：これまでの経緯と進捗を保持する部分

そして、次のループを繰り返します。

1. 観察：今の状況を確認する
2. 計画：次に何をするかをAIが決める
3. 実行：道具を使う
4. 学習：結果を記憶に残し、次の周回に備える

なぜDurable Objectsなのか

ここが、Cloudflareでエージェントを作る理由の核心です。

エージェントには、通常のWebアプリケーションと決定的に違う性質があります。

• 状態を持ち続ける：会話の経緯、途中まで進んだ作業、集めた情報を覚えている必要がある
• 長く生きる：1回のリクエストで終わらず、数分・数時間・数日にわたって同じ作業を続けることがある
• 待つ時間が長い：LLMの応答待ち、外部APIの応答待ち、人間の承認待ち
• 利用者ごとに独立している：Aさんのエージェントの記憶が、Bさんに混ざってはいけない

これは、Workersのような「リクエストが来たら起動し、返したら消える」という仕組みとは相性がよくありません。記憶をどこかに保存し、毎回読み直す実装が必要になります。

一方、Durable Objectsは1つのオブジェクトが1か所で動き、自分専用の保存領域を持ち、使われていないときは眠るという性質を持っていました。これはエージェントに求められる性質とほぼ完全に一致します。

Cloudflare Agents SDKは、この対応関係の上に作られています。エージェント1体が、Durable Objects 1つです。

Cloudflare Agents SDK

agents というnpmパッケージで提供されるSDKです。Agent クラスを継承して自分のエージェントを定義します。

import { Agent, callable } from "agents";

export class CounterAgent extends Agent {
  initialState = { count: 0 };

  @callable()
  increment() {
    this.setState({ count: this.state.count + 1 });
    return this.state.count;
  }
}

this.state に値を入れるだけで、その内容は自動的に保存され、再起動しても失われません。データベースへの書き込みコードは書きません。さらに、接続しているクライアント（ブラウザなど）へWebSocket経由で自動的に配信されるため、画面の更新処理も不要です。

設定ファイルには、Durable Objectsとしての登録を記述します。

{
  "ai": { "binding": "AI" },
  "durable_objects": {
    "bindings": [{ "name": "CounterAgent", "class_name": "CounterAgent" }]
  },
  "migrations": [{ "tag": "v1", "new_sqlite_classes": ["CounterAgent"] }]
}

new_sqlite_classes の指定によって、各エージェントが自分専用のSQLiteデータベースを持ちます。会話履歴の保存も、進捗の記録も、ここで完結します。

主な機能

• 状態の永続化と同期：setState で保存、接続中のクライアントへ自動配信
• リアルタイム通信：WebSocketによる双方向のやりとり
• ハイバネーション：待機中は眠り、必要なときに起きる。眠っている間の課金がない
• スケジュール実行：「3日後に確認する」「毎朝9時に実行する」といった予約ができる
• 人間の承認：重要な操作の前に人の確認を挟む（human-in-the-loop）
• 多様な入口：チャット、メール、Slack、音声、Webhookから同じエージェントにつながる
• 道具の呼び出し：Workers AI、AI Search、ブラウザ操作、サンドボックスでのコード実行、外部のMCPサーバー

制限

CPU時間30秒と、経過時間が無制限であることの違いは重要です。LLMの応答を2分待っていても、その間はCPUを使っていないので制限に触れません。エージェントが「待つ」仕事を得意とするのは、この仕組みのためです。

料金はDurable ObjectsとWorkersの料金体系に従います（Durable Objectsのページで扱いました）。無料プランでも利用でき、眠っている間は課金されません。

MCP（Model Context Protocol）とは

エージェントの価値は、どれだけ有用な道具を持っているかで決まります。しかし、AIごとに道具のつなぎ方が違っていては、サービス提供側は対応先の数だけ実装しなければなりません。

MCP（Model Context Protocol）は、この問題を解決するためのオープンな共通規格です。Cloudflareの公式ドキュメントは、これを「AIアプリケーションにとってのUSB-Cポート」と表現しています。USB-Cが1つあれば、あらゆる周辺機器を同じ端子でつなげるように、MCPに対応すれば、あらゆるAIと同じ方法でつながります。

3つの登場人物

• MCPホスト：AIアシスタントやエージェント本体。道具を必要とする側
• MCPクライアント：ホストに組み込まれ、サーバーとの接続を担う部分
• MCPサーバー：道具（ツール）や資料を提供する側。自分のサービスをAIに使ってもらうなら、ここを作ります

2つの接続方式

• リモートMCP：インターネット越しに接続する方式。Streamable HTTPで通信し、OAuthで認可を行います
• ローカルMCP：同じパソコン内で接続する方式

Cloudflareが特に力を入れているのがリモートMCPサーバーです。利用者がソフトウェアをインストールする必要がなく、URLを指定するだけでつながります。Workersの上に置けば、世界中どこからでも同じ速さで使えます。

CloudflareでMCPサーバーを作る

Agents SDKには、MCPサーバーを作るための仕組みが含まれています。Wrangler CLIで作成し、デプロイすれば、そのまま workers.dev のURLで公開されます。

2026年7月28日版のMCP仕様で、MCPは完全にステートレスなプロトコルになりました。これに伴い、SDK側の推奨も変わっています。

• createMcpHandler()：現在の推奨。ステートレスなツールの提供に向き、構成が最も単純です
• McpAgent：セッションごとにDurable Objectを1つ割り当てる旧来の方式。状態管理を伴う機能を持ちますが、現在は非推奨・機能凍結です

これから作るなら createMcpHandler() を選んでください。既存の McpAgent から移行する場合は、まずステートレスの経路を追加し、既存のセッションが終わるまで両方を並行させる手順が案内されています。

Cloudflare自身も、アカウントの設定を読んだりサービスを操作したりできる公式のMCPサーバーを提供しています。また、Cloudflare One側には、社内で使うMCPサーバーを1つの入口にまとめ、Cloudflare Accessでアクセスを制御する「MCPサーバーポータル」という機能もあります。AIエージェントの利用を組織として統制するという、新しい種類の管理課題への回答です。

MCPサーバーを設計するときのコツ

公式ドキュメントが挙げている指針は、実践的で参考になります。

• APIをそのまま道具にしない：エンドポイントを機械的に並べるのではなく、「利用者が達成したいこと」の単位で道具を作る
• 道具は少なく、よく設計する：細かい道具が大量にあるより、よく設計された少数のほうが、AIは正しく使えます
• 権限は絞る：目的ごとにサーバーを分け、それぞれの権限を最小限にする
• 説明文を丁寧に書く：引数の意味・想定される値・制約を書くほど、AIの誤用が減ります
• 評価テストを用意する：道具の説明を変えたら、AIが正しく使えるかを測る

初心者が注意するポイント

• 自律性はリスクでもあります：エージェントは想定外の行動を取り得ます。取り消せない操作（送金、削除、メール送信など）には、必ず人の承認を挟んでください
• 費用の暴走に備える：エージェントはループを回すため、1つの依頼で何十回もLLMを呼ぶことがあります。AI Gatewayで回数と金額の上限を必ず設定してください
• まずワークフローで足りないか考える：手順が決まっているなら、Workflowsのほうが安く、速く、確実です。エージェントが必要なのは、手順が事前に決められない場合だけです
• エージェントの単位を設計する：利用者ごとか、案件ごとか、会話ごとか。この単位がそのままDurable Objectsの単位になります。あとから変えるのは大変です
• 記憶は無限ではありません：1エージェント1GBまでです。会話履歴を延々と貯め続ける設計は、いずれ行き詰まります
• 外部のMCPサーバーは信頼できるものだけ：道具の説明文はAIへの指示として働きます。悪意ある説明文でAIを誘導する攻撃が知られています

関連サービス

• Durable Objects：エージェント1体の実体。状態の保持とハイバネーションを支える
• Workers：エージェントとMCPサーバーの実行環境
• Workers AI：判断エンジンとなるLLMを提供
• AI Search：エージェントに「自分の資料を検索する道具」を持たせる
• AI Gateway：エージェントのAI呼び出しを記録し、上限をかける
• Queues / Workflows：手順が決まっている処理はこちらが適する
• Cloudflare Access：MCPサーバーやエージェントへの認証

まとめ

• AIエージェントは、自分で判断して道具を使い、結果を見て次の行動を決める仕組み。ワークフローと違い、実行のたびに道筋が変わり得る
• 構成要素は判断エンジン（LLM）・道具・記憶。観察→計画→実行→学習のループを回す
• エージェントは状態を持ち、長く生き、待つ時間が長い。この性質がDurable Objectsと一致する
• Cloudflare Agents SDKでは、エージェント1体がDurable Objects 1つ。setState で状態が自動保存・自動同期される
• MCPは、AIと外部サービスをつなぐ共通規格。AIにとってのUSB-Cにあたる
• MCPサーバーはCloudflare上に構築・公開できる。2026年7月28日版の仕様でステートレス化され、createMcpHandler() が推奨。McpAgent は非推奨
• 自律性はリスクでもある。人の承認・費用の上限・権限の最小化を最初から設計する

これで第7章「AI」は完結です。Workers AIでモデルを動かし、AI Gatewayで管理し、RAGとVectorizeとAI Searchで自分のデータに答えさせ、Agentsで行動させる――CloudflareのAI関連サービスが、それぞれどの役割を担うのかが見えたはずです。

次の第8章では、ここまでの知識を実際に手を動かして使います。WordPressの接続、NASの公開、Workersの開発、そしてAI Searchを使ったRAGの構築まで、具体的な手順を扱います。

次に読む

• WordPressをCloudflareに接続する手順
• AI Searchとは？（旧AutoRAG）マネージドRAG

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。