Nullstead

AI

2026年版・個人開発者のためのエージェント実装現実解：MCP × Responses API × Cloudflare Workflows

MCP・Responses API・Cloudflare Workflows/Durable Objectsの最新動向を踏まえ、個人開発でAIエージェントを壊れにくく運用するための実装設計と導入手順を解説します。

約10分

「AIエージェントを作りました！」と言うのは簡単ですが、実際に運用すると、だいたい3日目くらいでこうなります。

  • 会話履歴が飛ぶ
  • ツール連携が増えるほど壊れる
  • 長い処理がタイムアウトする
  • 料金表を見て静かに目を閉じる

私も何度かこの“エージェントあるある”を踏んできました。そこで2025年後半〜2026年にかけての仕様更新を追いながら、個人開発で現実的に回せる構成を整理してみました。

結論を先に言うと、次の3つを押さえるとかなり安定します。

  1. MCP※を接続標準にする（ツール連携の配線を減らす）
  2. Responses APIのツール実行を中核にする（推論＋ツール呼び出しを一体で扱う）
  3. Cloudflare Workflows/Durable Objectsで耐久性を持たせる（長時間・再試行・状態保持）

※MCP（Model Context Protocol）: LLMアプリと外部ツール/データをつなぐためのオープンプロトコルです。

この記事では、最新ドキュメントをベースに「何が変わったか」「どう設計すると事故が減るか」「最小構成の実装例」をまとめます。

なぜ今この3点セットなのか：2026年時点の前提整理

2024年ごろのエージェント開発は、ざっくり言うと「各社SDK＋独自接着剤」で頑張る世界でした。動くのですが、ツールが増えると配線がスパゲッティ化しやすいです。ソースコードより設定ファイルのほうが怖くなるやつです。

2025〜2026で変わったのは、標準化と実運用機能の厚みです。

  • OpenAI Responses API側で、web search / file search / code interpreter / remote MCPなど、ツール実行基盤が強化
  • MCP仕様側で、認可・タスク・JSON Schema運用などの実務機能が前進
  • Cloudflare側で、Durable ObjectsやWorkflowsによる「長く動く処理」の実装がかなり現実的に

要するに、

  • 「つなぐ方法」= MCP
  • 「考えて呼ぶ脳」= Responses API
  • 「落ちずにやり切る体」= Workflows / Durable Objects

という分担がしやすくなりました。

個人開発の現場では、最先端モデル精度よりも、再実行時に壊れないことの価値が高いです。深夜2時に自分で自分をオンコールしないためにも、設計で負債を減らしておくのが正義です。

MCPの進化で何が嬉しいか："連携地獄"の脱出

MCPは「AIアプリ ↔ ツール群」のインターフェースをそろえる規格です。仕様ではJSON-RPC 2.0ベースで、サーバーが tools/resources/prompts を公開し、クライアント（AIアプリ側）がそれを利用します。

ここで重要なのは、ツールを呼ぶたびにベンダー固有SDKの癖を追わなくてよくなる点です。もちろん現実には差異は残りますが、少なくとも設計の主語を「このモデル専用の関数」から「MCPのツール契約」に移せます。

さらに2025-11-25版の変更では、実装者目線で効く改善がいくつかあります。

  • 認可周り（OpenID Connect Discovery、OAuth関連）の強化
  • tasks（実験的）で、時間のかかる要求を追跡しやすく
  • JSON Schema 2020-12を標準方言として明確化
  • samplingでのtool calling対応

このへんが効いてくると、MCPは「デモ用の便利規格」から、運用を見据えた接続面に近づきます。
「MCPサーバーを1本差し替えたら、上位ロジックをほぼ触らず移行できた」が増えるのは、個人開発者にとってかなりの福音です。

Responses APIを中核に置く理由："推論と実行"を同じ文脈で扱える

OpenAIのResponses APIは、単なるテキスト生成エンドポイントというより、モデル推論とツール呼び出しのオーケストレーション層として使うと真価が出ます。

最近の更新で注目したいのは次の点です。

  • remote MCPサーバーをツールとして扱える
  • Code InterpreterやFile Searchなどを同じ流れで呼べる
  • background modeで長時間処理を非同期化できる
  • reasoning summariesで監査しやすい
  • 一部モデルで推論トークン再利用によりコスト/遅延改善

実装していて一番ありがたいのは、「考える」と「道具を使う」の往復を1つの会話コンテキストで扱えることです。

たとえば「障害調査レポートを作る」タスクなら、

  1. ログを検索
  2. 関連ドキュメント参照
  3. 追加質問
  4. 集計コード実行
  5. 結果を要約

を同じランでまとめやすくなります。昔のように、外側でif文地獄を構築して「次はこのAPI、次はこのAPI……」と祈る時間が減ります。祈りは宗教施設でやって、プロダクトは再現性で作りましょう、という話です。

Cloudflare Workflows / Durable Objectsで"最後まで終わらせる"

エージェント実装でよくある失敗は、モデル精度よりも実行継続性です。
APIが一瞬落ちる、ネットワークが揺れる、外部サービスが429を返す。これだけで処理全体が崩れる構成は、運用するとメンタルに来ます。

Cloudflare Workflowsは、ステップ単位で耐久実行・再試行・待機を扱えるため、エージェント処理の「業務フロー化」に向いています。step.sleep() や step.waitForEvent() のような仕組みがあるので、数分〜数日の待機を含む処理も設計しやすいです。

Durable Objectsは、エージェントごとの状態保持に相性が良いです。最近のドキュメントでは、SQLiteベース運用やデータ管理の情報が整理され、実務投入しやすくなっています。加えて、WebSocket周辺や課金仕様も更新されており、「試作のまま本番で燃える」リスクを事前に見積もりやすいのが良いです。

要するに、

  • モデル/ツール連携の知能部分：Responses API
  • 実行制御と永続状態：Workflows + Durable Objects

という分離をすると、障害時の切り分けも圧倒的に楽になります。

最小構成アーキテクチャ（個人開発向け）

私が今おすすめするのは、次のような責務分割です。

  • Agent Gateway（HTTP入口）
    ユーザー入力を受け、ジョブIDを発行。同期応答は受理通知だけ返す。

  • Orchestrator（Workflows）
    タスクをステップ化。再試行ポリシー、待機、タイムアウト、補償処理を管理。

  • Reasoning Worker（Responses API）
    推論とツール呼び出しを実施。必要に応じてremote MCP toolを利用。

  • Tool Plane（MCP servers）
    GitHub、DB、社内API、スクレイピングなどをMCPで統一公開。

  • State Plane（Durable Objects / D1等）
    会話スナップショット、ジョブ状態、監査ログを保存。

擬似コードはこんなイメージです（動作未検証、設計例です）。

// Workflow pseudo code (design sample)
export class ResearchWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    const plan = await step.do("plan", async () => {
      return await callResponsesAPI({
        input: event.query,
        tools: [{ type: "mcp", server_label: "internal-tools" }],
      });
    });

    const fetched = await step.do("collect", async () => {
      return await runToolPhase(plan);
    }, { retries: { limit: 3, delay: "10s" } });

    await step.waitForEvent("human-approval", {
      event: "approved",
      timeout: "24h",
    });

    const report = await step.do("summarize", async () => {
      return await callResponsesAPI({
        input: `以下を要約してください: ${JSON.stringify(fetched)}`,
      });
    });

    return report;
  }
}

ポイントは、モデル呼び出しを「1発勝負」ではなく業務ステップとして扱うことです。
この設計にすると、エラー時に「どのステップで何が起きたか」が残るので、再実行の判断ができます。障害対応チャネルで「なんか失敗しました！」と叫ぶ回数が減ります。かなり減ります。

実装時の落とし穴5つ（ここでだいたい転ぶ）

1) ツール権限の粒度が粗い

MCPサーバーに広い権限を渡しすぎると、便利な代わりに事故半径が拡大します。
対策として、ツールを「読み取り専用」「更新可能」「破壊的操作あり」で分離し、モデル側には最小権限セットだけ見せるのが基本です。

2) 非同期実行の結果整合を軽視する

background modeやWorkflow待機を使うと、同一ジョブの多重実行や順序逆転が起こり得ます。
ジョブIDベースで冪等性※を担保し、結果書き込み時にバージョンチェックを入れると事故が減ります。

※冪等性（べきとうせい）: 同じ操作を複数回実行しても結果が壊れない性質です。

3) 失敗時ログが自然言語しかない

「失敗しました。もう一度お試しください。」だけ残しても、誰も幸せになりません。
最低でも job_id, step_name, tool_name, error_class, retry_count は構造化で保存すると、翌日の自分が感謝します。

4) コスト監視を後回しにする

ツール呼び出し＋長文推論＋再試行は、静かに請求を育てます。
トークン量、ツール実行回数、Workflowステップ回数をメトリクス化し、日次で上限警告を出すだけでもだいぶ違います。財布にも心にも平和条約が必要です。

5) "使ってない機能"まで先回り実装する

MCP・Workflows・Agents系は機能が多く、楽しくて全部盛りしたくなります。気持ちはわかります。私もやりました。
でも個人開発では、まず「1ユースケースを壊れず回す」ことが先です。機能旗艦より運用駆逐艦を作るほうが勝ちます。

30日で導入するならこの順番

最後に、私ならこう進めます。

  1. Week 1: 単一路線を固定
    まず1つの業務フロー（例: 調査→要約→レビュー）だけ決め、Responses API単体で完走させる。

  2. Week 2: MCPでツール面を標準化
    既存API呼び出しを順にMCP化。最初は読み取り系ツールだけ公開する。

  3. Week 3: Workflowsで耐久化
    再試行、待機、タイムアウト、手動承認を導入。失敗時の再開手順も明文化する。

  4. Week 4: 観測性とコスト管理
    構造化ログ、アラート、日次集計を追加。不要なツールや長いプロンプトを削る。

この順番にする理由は単純で、先に複雑化すると必ず迷子になるからです。
エージェント開発は「賢さの競争」に見えますが、実際は「運用可能性の設計競争」です。

派手なデモはSNSで伸びます。
でも、夜中に起きずに済むシステムこそ、個人開発者にとって本当の勝利です。
私も引き続き、派手さより安定を積み上げていきます。深夜対応は、せめて推し配信の時間だけにしたいので。

参考リンク

Tags #AI #Agent #MCP #Cloudflare #Automation #Personal Development
← 記事一覧に戻る ページの先頭へ ↑