Bringing more agent harnesses and frameworks to Cloudflare, starting with Flue｜Cloudflare、エージェントハッチスとフレームワークの拡充へ、まずは「Flue」から | AIニュース最前線

2026 年は、エージェント・ハルネスが生産環境へ移行する年となる。モデルの外部世界へのアクセスを制御するソフトウェア — Codex、Claude Code、OpenCode、Pi、Project Think といったハルネス — は成熟し、チームはもはやプロトタイプとしてではなく、実際の負荷を支えるインフラストラクチャとしてエージェントを展開している。 しかし、生産環境で生き残るエージェントを構築するのは難しい。 これは、私たちがファーストパーティのエージェント・ハルネスである Project Think を構築する過程で身をもって学んだことだ。顧客と協力して生産環境でエージェントを実行する中で、クラウド上で動作する際にすべてのエージェントが直面する共通の分散システム上の課題が見つかった。エージェントが中断された場合、コンテキストを失わずトークンを浪費することなく、どこからでも自動的にかつ優雅に再開するにはどうすればよいか？不審なコードを安全に実行させるにはどうすればよいか？トレーニングで用いたツールを利用できるようにするにはどうすればよいか？ ハルネス単独ではこれらの問題を解決できない。これらは状態（ステート）、ストレージ、計算リソースと密接に関連しており、つまりエージェントが動作するプラットフォームに依存している。そこで私たちは、生産環境向けに Project Think を堅牢化する過程で得た知見を Cloudflare Agents SDK の基盤層として提供することにした。永続的な実行（durable execution）、動的コード実行、永続ファイルシステム、そして動的ワークフロー — これらはすべて、Agents SDK をベースに構築されるあらゆるハルネスで利用可能となった。 同時に、ハーンサーの上層に新たなレイヤーが出現しました。Flue などのフレームワークは、エージェントを効率的に構築するためのプロジェクト構造、規約、統合、そして開発者体験を備えたハーンサーを包み込むことで機能します。 これらのスケーリング課題に対処するため、本格的な AI を構築するための新たな 3 レイヤー構成が出現しています。ユーザー facing の開発者体験から下位のプラットフォーム基盤へと至るまでの各要素の連携は以下の通りです： フレームワーク（Flue）— エージェントを構築するためのプロジェクト構造、規約、統合、CLI、および開発者体験。 ハーンサー（Pi, Project Think）— ツールを呼び出し、結果を読み取り、コンテキストを管理し、タスクが完了するまで継続するエージェントループ。 ランタイム/プラットフォーム（Cloudflare Agents SDK）— 上記すべてが依存する計算、状態、ストレージの基盤プリミティブ。 Agents SDK はこの最下層レイヤーであり、永続実行などのプリミティブをあらゆるハーンサーおよびフレームワークに提供します。Astro のチームが開発した新しいオープンソースフレームワークである Flue が、これをベースに構築された最初の例です。その仕組みは以下の通りです。 Flue Flue は今週、1.0 ベータ版をリリースしました。これは OpenClaw が構築されているのと同じ Pi ハーネス（harness）の上に作られています。エージェントフレームワークとしての違いはアプローチにあります：エージェントが何をするかをスクリプト化するのではなく、何がわかるかを記述するのです。エージェントが必要とするコンテキスト——モデル、スキル、サンドボックス、そして指示——を定義すれば、与えられたタスクを自律的に解決します。オーケストレーションループ（orchestration loop）を書く必要はありません。 この宣言型モデルが、エージェントの作成を容易にする理由です。以下は、バグレポートをインターセプトし、サンドボックス内で再現して 25 行未満で問題診断を行うトライアージエージェントの例です。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5U50mjNZpg7RD3fb0pOLLs/5e20ad63c1e6ab92cf5d334b79996c1a/image5.png) Flue の開発者体験 Flue の強みは、エージェントが孤立して存在しないという事実にあります。彼らはユーザーがすでに作業している場所に存在し、好みのツールチェーンと統合するように設計されています。 どこでも動作するエージェント：Slack、GitHub、Linear、Discord にエージェントを配置できます。イベント検証とディスパッチのボイラープレート（boilerplate）を自動的に処理する事前設定済みのチャンネルを使用可能です。 ヘッドレスだが UI 対応済み：エージェントはブラックボックスの中に住むべきではありません。Flue エージェントはバックグラウンドタスクのために完全にヘッドレスで実行できますが、@flue/react はネイティブのフロントエンドフックを提供し、カスタムのリアルタイム基盤をゼロから構築する必要なく、エージェントの状態、ツール実行、ライブメッセージを直接フロントエンドアプリケーションにストリーミングします。 エコシステム対応済み：Flue を使えば、「flue add channel slack」のようなコマンドで統合を追加・アップグレードするのが容易になり、Markdown の青写真が生成されます。これにより、あなたのコーディングエージェントが読み取り、修正し、コードベースにきれいに直接統合することが可能になります。 単なるプロトタイプのためではなく、本番環境向けに設計されています エージェントをローカルターミナルから本番エコシステムへ移行すると、従来の分散システムの障害が発生します。ホストのクラッシュ、LLM プロバイダーからの API タイムアウト、予期せぬ再起動は、実行中のエージェントのターンにおける短期記憶を消去する恐れがあります。 Flue は Durable Streams（永続ストリーム）によってこれを解決します。実行履歴内の各イベントは、追加専用ログに追加されます。すべてのプロンプト、ツール応答、モデル選択を不変の台帳として処理することで、エージェントの状態は決して不安定になりません。プロセスが終了しても、別のプロセスがそのログを引き継ぎ、中断した正確なステップから継続します。 Cloudflare を含むあらゆる場所にデプロイ可能 Flue はマルチクラウドフレームワークです。Node.js では、各エージェントは長期間実行されるプロセスとして動作します。任意の VM やコンテナにデプロイしたり、GitHub Actions で実行したり、既存のサーバーに埋め込んだりできます。しかし、Cloudflare をターゲットとする場合、各エージェントは Durable Object になります。 Flue エージェントをそれぞれの Durable Object 内で実行することで、Cloudflare は必要な数のエージェントに対して自動的にスケールし、それぞれが独立したストレージと計算リソースを持つことができます。サーバーのプロビジョニングやスティッキーセッションの管理、ノイジーネイバーへの懸念は不要です。また、Flue エージェントを Cloudflare にデプロイすると、Agents SDK の runFiber()、stash()、onFiberRecovered() メソッドを使用して永続的な実行が可能になります。さらに、Flue は @cloudflare/codemode と @cloudflare/shell を使用して、永続的なワークスペースに対してサンドボックス化されたコード実行を行います。 エージェントプラットフォームからハッチが求めるもの Flue の Cloudflare ターゲットがこれほど効果的に機能するのは、Agents SDK に組み込まれた中核的なプリミティブに明確に対応しているからです。Flue ソースコードを詳しく見て、基盤となるハッチである Pi がどのように Cloudflare Agents SDK で動作するように適応されているかを理解することもできます。 ここでは、Flue が内部でどのように Agents SDK を活用し、現代のエージェントハッチを大規模かつ確実に実行するために何が必要かが説明されます。 すべてのエージェントハッチは永続的な実行を必要とします エージェントのターンは単一のリクエストではありません。モデルはトークンをストリーミングし、ツールを呼び出し、結果を待ち、人間からの承認を求めるか、あるいはサブエージェントに作業を委譲します。この一連の流れには数秒から数分がかかることもあり、その過程でプロセスが中断されたりクラッシュしたりする可能性があります。そのような事態が発生すると、メモリ上に存在していたすべてのエージェント状態が失われます：ストリーミング接続、保留中のツール呼び出し、そしてそのターンにおけるエージェントの位置です。もちろん会話履歴はディスクに永続化されていますが、ユーザーには解決しないスピナーが表示されることになります。これは壊れたユーザー体験です。 Fibers は、ネイティブのチェックポイント機構をエージェントの基盤となる Durable Object の内部に直接提供することでこの問題を解決します。runFiber() は、エージェントのターン内の作業が始まる前に進捗を Durable Object の SQLite ストレージに記録し、stash() を用いてターンが進行するごとにチェックポイントを保存します。中断後に新しいエージェントインスタンスが起動すると、onFiberRecovered() が最後のチェックポイントを受け渡すため、あなたのエージェントはターンが中断されたこと、どこまで到達したかを知り、どのように継続するかを判断できます。 import { Agent } from "agents"; import type { FiberRecoveryContext } from "agents"; class MyAgent extends Agent { async doWork() { await this.runFiber("my-task", async (ctx) => { const step1 = await expensiveOperation(); ctx.stash({ step1 }); const step2 = await anotherExpensiveOperation(step1); this.setState({ ...this.state, result: step2 }); }); } } async onFiberRecovered(ctx: FiberRecoveryContext) { if (ctx.name !== "my-task") return; const { step1 } = (ctx.snapshot ?? {}) as { step1?: unknown }; if (step1) { const step2 = await anotherExpensiveOperation(step1); this.setState({ ...this.state, result: step2 }); } } } Flue は、まさにこのために Cloudflare ターゲット上で runFiber() を使用します。onFiberRecovered() フックにより、ハルネスはターン実行の再開方法を決定できます。具体的には、Project Think のような完全な再構築モデルでターンの状態を修復する試みを行うか、あるいはターンの特定の部分を再生するかを選択します。 エージェントにツールを過剰に与えるよりもコードを実行させる方が優れている Agent ハルネスは、ツールを通じてモデルが外部世界にアクセスできるようにします。しかし、ツールの表面（インターフェース）は急速に拡大し、リストが長くなり、コンテキストウィンドウがツールの定義で埋まるとともに、モデルは適切なツールを選択する能力が低下します。より良いパターンは、コードを実行するための 1 つのツールをモデルに与えることです。モデルは必要な API を呼び出す TypeScript 関数を書き、ハルネスがそれを実行します。私たちは Code Mode（コードモード）を導入した際にこの点について言及しました。 問題は、そのコードがどこで実行されるかです。LLM が生成したコードを安全に実行するにはサンドボックスが必要です。しかし、一般的なサンドボックスでは、各ツール呼び出しを実行する際に遅く、コストが高額になり、非効率的になります。そこで、Agents SDK は@cloudflare/codemode を提供しており、これは Dynamic Workers（動的ワーカー）をラップして、LLM が生成したコードを独自の Worker イソレート内で実行し、あなたが提供するバインディングのみを使用可能にします。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1NCq9AP9xL1b70WyB0iqE0/7569fc7ee43b6071f0b98945d872e9c7/BLOG-3336_3.png) Code Mode は、各スニペットに対して新しい Dynamic Worker を作成し、実行した後に破棄します。イソレートの起動は 10 ミリ秒未満で完了し、ロードあたり 0.002 ドルというコストで、エージェントが短いコードを実行するたびにコンテナを起動する場合と比較して、劇的に高速かつ低コストな実行を実現します。Flue は、その Cloudflare ターゲット上で@cloudflare/codemode を使用してコードツールを機能させています。エージェントはワークスペースに対して JavaScript を記述し、Code Mode で実行します。 ほとんどのワークスペースタスクには完全なコンテナは不要です Agent ハーネスでは、ファイルの読み込み、出力の書き込み、コードの検索や差分の理解など、ファイルシステムが必要になることがよくあります。特にコーディングエージェントはファイルシステム上で動作します。しかし、ハーネスがサーバーレス環境で実行されている場合、どのようにして実行を跨いで永続化する耐久性のあるファイルシステムを取得できるのでしょうか？ 通常の答えはコンテナです。それは機能しますが、エージェントが主に実行する作業に対しては高価すぎます。エージェントのターンにおけるファイルシステムの操作の大部分はテキスト処理です。例えば、ファイルを読み込み、ソースコードを grep 検索したり、パッチを書いたりするレビュー用エージェントを考えてみてください。それには完全な Linux の起動は必要ありません。 @cloudflare/shell は、Durable Object 内に永続的な仮想ファイルシステムを提供し、そのバックエンドとして SQLite を使用します。これは、エージェントハネスがツールとして利用可能な型付きのファイル操作（read, write, edit, search, grep, diff）を提供します。 個別のツールを呼び出すのではなく、Cloudflare ターゲット上で実行される Flue エージェントは、ワークスペース仮想ファイル状態 API に対して JavaScript を記述します。Durable Object 内でより多くの操作を実行することで、エージェントはアイソレートモデルのより効率的な実行プロセスの恩恵を受け、コンテナオーバーヘッドを完全に回避できます： async () => { const files = await state.glob("src/**/*.ts"); const results = []; for (const file of files) { const content = await state.readFile(file); const todos = content.match(/\/\/ TODO:.*/g); if (todos) results.push({ file, todos }); } return results; } これは、シェルやファイルシステム操作を実行して作業を完了させる必要があるエージェントに対して、より高速でコスト効率の高いサンドボックス環境を実現します。また、npm install や git、コンパイラを実行するために完全な OS が必要となるエージェント向けには、Cloudflare Containers が提供されます。さらに、@cloudflare/workspace を構築中であり、特定の Durable Object の仮想ファイルシステムとコンテナのそれを同期させることで、軽量な Workers から Linux 環境へのシームレスな移行を、必要な場合にのみ可能にします。 ダイナミックワークフロー：エージェントが自らワークフローを記述してタスクを一貫して反復実行 しかし、エージェントがファイルの読み取りや単一のコードスニペットの実行を超えた作業を必要とする場合、あるいは時間を通じて一貫して反復される大規模な多段階パイプライン（例えば、バグを正常に解決するコードレビューや、良好な結果を生み出す研究ワークフローなど）を調整する必要がある場合はどうなるでしょうか？ハーン単体では、永続的な多段階実行を提供することはできません。各ステップの永続化、失敗時の再試行、中断からの再開にはプラットフォーム側のサポートが必要です。 このパターンは注目を集めています。Claude Code は最近、動的ワークフローを実装しました。これは、Claude が実行時に JavaScript スクリプトを記述して数十人のサブエージェントに作業を引き渡し、ランタイムがそれを永続的に実行する仕組みです。@cloudflare/dynamic-workflows は、Agents SDK 上で動作するあらゆるハッチ（harness）に対してこの機能を提供します。あなたのエージェントは実行時にワークフローを生成し、Workflows エンジンは各ステップを永続化し、失敗した場合は再試行を行い、数時間の待機や人間による承認待ちなどの外部イベントの待機も可能です。 Agent クラスから runWorkflow() を呼び出すと、エージェントが Workflows エンジンに接続されます。エージェントはワークフローを開始して待機状態に入ることができ、ワークフローは RPC を介してエージェントにコールバックし、進捗状況の報告や状態の更新、承認のリクエストを行います。ワークフローが完了すると、エージェントは結果を持って起動します。 Cloudflare エコシステムへの直接アクセス 計算リソースやストレージだけでなく、エージェントハッチは外部機能へのアクセスも必要です。具体的には、ウェブブラウジング、メール、メモリ、検索、推論などです。各機能を個別に統合したり、それぞれの API キーを管理したり、エージェント生成コードを通じて認証情報が漏洩することを心配する必要はありません。 Agent クラスを使用すると、バインディングを通じて Cloudflare の他の機能にアクセスできます。具体的には、エージェントごとの支出追跡と制限管理のための AI Gateway、Web 自動化のための Browser Run、受信トレイワークフローのための Email Service、永続的な記憶保持のための Agent Memory、検索のための AI Search、フル OS が必要なワークロード向けの Containers、そして 14 以上のモデルプロバイダーにわたる推論機能です。バインディングは認証情報を公開することなく機能を付与します。エージェントがこれらを使用しますが、キーがエージェント生成コード内に直接入力されることはありません。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7jLx08K0FuCd8mJ4xIjwop/3833967f110d119a260979608cc57fce/BLOG-3336_4.png) エージェントをアジェンティッククラウドへ持ち込もう このアプローチが機能することは、私たちがファーストパーティのエージェントハネスである Project Think を構築する際に使用したのと同じアーキテクチャ基盤を採用していることから明らかです。Project Think は、ネイティブな Cloudflare エージェント体験のための非常に最適化された即戦力ソリューションとして引き続き提供されますが、Agents SDK により、より広範なオープンソースエコシステムも、Flue を含むこれらの実証済みの基本機能（プリミティブ）を活用できるようになります。 今日 Flue でエージェントを構築している場合、数回のクリックで Cloudflare へデプロイできます。また、独自のエージェントハネスやエージェントフレームワークを構築している場合は、Agents SDK をターゲットとし、プラットフォーム統合機能を無料で利用してください。 Agents SDK: developers.cloudflare.com/agents Flue: flueframework.com, npm install @flue/runtime Think: docs Cloudflare Community: community.cloudflare.com 翻訳全文

Cloudflare、エージェントハッチスとフレームワークの拡充へ、まずは「Flue」から

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト