2026年版 Cloudflare Agents実践設計: WorkflowsとQueuesで作る止まらない個人開発オートメーション

AIエージェントを個人開発で運用していると、だいたい同じ壁にぶつかります。デモは動くのに、本番で静かに壊れる問題です。朝に確認すると、夜中のジョブがこっそり失敗している。しかもログは薄い。犯人は不明。コーヒーだけが減っていく。私もこの流れを何度も通りました。

2026年時点で、この壁を越える現実解としてかなり有力なのが、Cloudflare Agents と Workflows と Queues を組み合わせる構成です。特に、Agents が Durable Objects ベースで状態と接続を持てるようになったことで、チャットデモから実運用に一段進めやすくなりました。

この記事では、Cloudflare Agents の最新ドキュメントと周辺アップデートを前提に、個人開発で無理なく回るアーキテクチャを具体的に整理します。テーマは「止まらない自動化」です。キラキラした話だけではなく、リトライや待機や承認フローなど、地味だけど効く部分を中心に書きます。

なぜ今 Agents なのか: ステートレス地獄からの脱出

Cloudflare Agents の考え方はシンプルです。エージェントを TypeScript クラスとして実装し、各インスタンスを Durable Objects 上で動かす。これにより、会話状態、WebSocket 接続、スケジュール実行、ツール呼び出しを同じ土台で扱えます。

ここで重要なのは「ステートレス API をつなぎ合わせる苦労」を減らせる点です。従来は以下を個別に組み合わせる必要がありました。

会話履歴の保存
接続維持と再接続
定期実行
長時間タスクの再試行
人間承認の待機

Agents では、この多くを最初から想定した設計になっています。※ Durable Objects はエッジ上で状態を持つ実行単位です。セッション管理や協調処理に向いています。

さらに、@callable() を付けたメソッドを WebSocket 経由の RPC として公開できるため、フロントエンドとエージェントの接続も素直です。個人開発では「実装コストより運用コストが後で効く」ので、この一体感は地味に効きます。

まず押さえる設計原則: 1エージェントに全部詰め込まない

Agents が便利だからといって、全部を 1 クラスに詰め込むと、最終的に巨大な万能神クラスが生まれます。便利そうに見えて、未来の自分が泣くやつです。私はこれを「便利の過積載」と呼んでいます。

実運用では、役割で分けるのが安全です。

対話担当 Agent: ユーザー対話、指示解釈、軽いツール実行
実行担当 Workflow: 重い処理、外部 API 呼び出し、再試行制御
非同期キュー担当 Queue: バースト吸収、後段処理への受け渡し

この分離にすると、障害時の切り分けが楽です。対話が生きているのか、ジョブ実行が詰まっているのか、キュー滞留なのかを素早く判断できます。

特に Workflows 側は、ステップを小さく切り、各ステップを idempotent※ に設計するのが重要です。※ idempotent は「同じ処理を複数回実行しても結果が破綻しない性質」です。課金処理や通知処理では必須です。

Workflows の本質: 長時間処理を正しく待てること

Cloudflare Workflows の強みは、長時間の待機や再実行を前提にしていることです。step.sleep() や step.sleepUntil()、さらに waitForEvent() を使うと、人間の承認待ちや外部システム待ちを素直に表現できます。

ここでハマりやすい注意点があります。Workflows は実行中に hibernate する可能性があるため、メモリ上の一時変数だけに依存すると壊れます。ドキュメントでも「ステップ外のメモリ状態に依存するな」が強く推奨されています。

つまり、以下の原則です。

重要な状態は step.do() の戻り値や永続ストアに置く
1 ステップを小さくして再実行可能にする
外部 API 呼び出しは前後条件を明示し、二重実行を防ぐ

「夜中に勝手に直っていてほしい」要件は、派手な推論モデルより、こういう再実行可能な地味設計が満たします。AI 時代ですが、信頼性は昔から地道です。

Queues を挟むと何が変わるか: スパイク耐性と復旧力

Cloudflare Queues は、エージェント運用で意外と効く脇役です。例えば、急に大量イベントが来るケースを想像してください。

Slack や webhook からの連続通知
バッチ処理の一斉開始
再処理ジョブの同時投入

これを Agent が直接受けると、処理が詰まりやすくなります。Queues を挟めば、入力をバッファして後段の処理速度に合わせて捌けます。2025年には pull consumer の上限が 1 キューあたり 5,000 メッセージ毎秒まで拡張され、外部環境からの取り回しも実用性が上がりました。

個人開発では「普段は静か、たまに集中砲火」が多いので、このバッファ層が心理的にも効きます。通知が 1 分で 200 件来ても、とりあえず受け止める。これは精神衛生上かなり大事です。

MCP と認可設計: ツール連携の便利さを事故らせない

2025年以降、MCP のリモート接続は一気に現実的になりました。Cloudflare でも Remote MCP サーバー構築ガイドが整備され、OAuth 2.1 を前提にした認可フローを取り込みやすくなっています。

ここでのポイントは「モデルに秘密を持たせない」設計です。

トークンはサーバー側で管理
ツール呼び出しごとに権限を絞る
監査ログを残す
失敗時のフォールバックを用意する

OpenAI Responses API 側でも MCP ツール接続が強化され、背景実行などの信頼性機能が拡充されています。ただし、機能の組み合わせには制約が出る時期もあるため、実装時は公式ドキュメントと changelog の現行仕様を必ず確認してください。

要するに「つながる」だけで満足しないことです。認可まで含めて設計して、初めて本番で使えます。

実装テンプレート: Agent + Workflow + Queue の最小構成

以下は、個人開発で私がよく使う最小パターンです。動作イメージの共有を目的にしたサンプルで、環境に合わせて調整してください。

// src/agent.ts
import { Agent, callable } from "agents";

export class OpsAgent extends Agent {
  initialState = { accepted: 0 };

  @callable()
  async enqueueTask(payload: { type: string; data: unknown }) {
    await this.env.MY_QUEUE.send({
      id: crypto.randomUUID(),
      createdAt: Date.now(),
      ...payload,
    });

    this.setState({ accepted: this.state.accepted + 1 });
    return { ok: true, accepted: this.state.accepted };
  }
}

// src/consumer.ts
export default {
  async queue(batch: MessageBatch<any>, env: Env) {
    for (const msg of batch.messages) {
      await env.MY_WORKFLOW.create({
        params: { event: msg.body },
      });
      msg.ack();
    }
  },
};

// src/workflow.ts
import { WorkflowEntrypoint } from "cloudflare:workers";

export class TaskWorkflow extends WorkflowEntrypoint<Env, { event: any }> {
  async run(event, step) {
    const normalized = await step.do("normalize", async () => {
      return { ...event.payload.event, normalizedAt: Date.now() };
    });

    await step.do("call-external-api", async () => {
      // 非idempotentなAPIなら、事前照会や重複キーで二重実行を防ぐ
      await fetch("https://example.com/api", {
        method: "POST",
        body: JSON.stringify(normalized),
      });
    }, {
      retries: { limit: 5, delay: "10 second", backoff: "exponential" },
      timeout: "30 second",
    });

    await step.sleep("cool-down", "15 second");
  }
}

運用上はここに、次の 3 点を追加すると安定します。

監視指標: Queue 滞留件数、Workflow 失敗率、再試行回数
失敗通知: Slack などへの要約通知
再実行導線: 失敗イベントを再投入する簡易コマンド

失敗しにくい運用チェックリスト

最後に、実運用で効いたチェック項目をまとめます。

ステップ分割: 1 ステップ 1 役割を徹底しているか
再実行安全性: 二重課金、二重通知、二重更新を防げるか
待機設計: 人間承認待ちや外部待ちを waitForEvent() で表現しているか
バックプレッシャ: スパイク時に Queue が吸収できるか
認可分離: MCP ツールの権限を最小化しているか
観測性: 失敗の原因を 5 分以内に追えるログがあるか

この中で最も軽視されがちなのは観測性です。私は「ログは後で読むもの」ではなく「未来の自分への手紙」だと思っています。手紙が雑だと、未来の自分から苦情が届きます。しかもだいたい深夜です。

まとめ: 派手なモデルより、壊れにくい配管が勝つ

2026年の個人開発において、AIエージェントの価値はモデル性能だけで決まりません。むしろ、

状態を安全に持てること
長時間処理を壊さず継続できること
イベント急増に耐えられること
認可付きツール連携を制御できること

この配管設計で差がつきます。Cloudflare Agents、Workflows、Queues、そして MCP を適切に組み合わせると、デモ止まりから運用可能な自動化へ進めます。

「AIが全部やってくれる時代」と言われますが、現場感覚としては「AIを支える地味な設計が全部を決める時代」です。地味な配管は映えません。でも、止まらない。止まらない仕組みは、最高にかっこいいです。