このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
本日は、次世代のAgents SDKであるProject Thinkをご紹介します。Project Thinkは、長期間実行されるエージェント（耐久性のある実行、サブエージェント、サンドボックス化されたコード実行、永続セッション）を構築するための新しいプリミティブセット（耐久性のある実行、サブエージェント、サンドボックス化されたコード実行、永続セッション）と、それらすべてを1つに接続する指定されたベースクラスです。プリミティブを使用してまさに必要なものを構築し、ベースクラスを使用して迅速に開始できます。
今年初め、私たちのAIに対する考え方を変える事態が起こりました。Pi、OpenClaw、Claude Code、Codexのようなツールは、シンプルでありながら強力なアイディアを証明しました。LLMにファイルを読み、コードを書き、実行し、学習したことを記憶する能力を持たせると、開発者ツールというよりは汎用アシスタントのようなものが得られます。
このコーディングエージェントはもはやコードを書くだけではありません。多くのユーザーは、カレンダーの管理、データセットの分析、購入の交渉、納税、ビジネスワークフロー全体の自動化などに使用しています。パターンは常に同じです。エージェントはコンテキストを読み取り、それについて理由を調べ、アクションを実行するためのコードを書き、結果を観察し、反復を行います。コードは、動作の普遍的な媒体です。
当社のチームは、これらのコーディングエージェントを毎日使用しています。そして、同じ壁に取り組み続けました。
ノートパソコンか高価なVPSで動作するだけで、デバイス間の共有、コラボレーション、引き渡しは一切ありません。
アイドル中は高価です: エージェントが機能していても働いていなくても、月額定額料金がかかります。チームや会社に合わせた拡張なら、すぐに膨れ上がります。
依存関係のインストール、アップデートの管理、IDとシークレットの設定など、管理と手動セットアップが必要です。
そして、より深刻な構造的な問題があります。従来のアプリケーションは1つのインスタンスから多くのユーザーに配信されます。「Agents Weekへようこそ」の投稿で述べたように、エージェントは1対1です。各エージェントは固有のインスタンスであり、1人のユーザーにサービスを提供し、1つのタスクを実行します。レストランには、大量の料理を提供するために最適化されたメニューとキッチンがあります。エージェントは、専属料理人に似ていて、毎回、異なる食材、技術、ツールを使用します。
これにより、スケーリングの数学のあり方が根本的に変わります。1億人のナレッジワーカーがそれぞれエージェンティックアシスタントを使用する場合、控えめな同時実行数でも、何千万もの同時セッションに対応できる容量が必要になります。現在のコンテナごとのコストでは、持続不可能です。異なる基盤が必要なのです。
それが私たちが構築してきたのです。
Project Thinkは、Agents SDKの新しいプリミティブのセットを出荷します。
ファイバーによる耐久性のある実行：クラッシュからの復旧、チェックポイントの作成、自動キープアライブ
サブエージェント：独自のSQLiteと型付けRPCを持つ分離された子エージェント
永続セッション：ツリー構造化メッセージ、フォーク、コンパクション、フルテキスト検索
サンドボックス化されたコード実行：Dynamic Workers、コードモード、ランタイムnpm解決
実行ラダー：ワークスペース、分離、npm、ブラウザ、サンドボックス
自己作成型拡張機能：エージェントが実行時に独自のツールを作成する
これらはそれぞれ、エージェントベースクラスで直接使用できます。プリミティブを使用してまさに必要なものを構築するか、Thinkベースクラスを使用して、迅速に始められます。それぞれの内容を見ていきましょう。
現在も存在するエージェントは、一過性のものです。それらは1つのセッションのために実行され、単一のプロセスやデバイスに結びつき、その後、消えてしまいます。ノートパソコンがスリープすると終了するコーディングエージェント、それはツールです。持続性のあるエージェント、オンデマンドで起動し、中断後の作業を継続し、ローカルランタイムに依存せず状態を続行できるものは、インフラストラクチャのように見え始めます。そして、エージェントのスケーリングモデルを完全に変えます。
Agents SDKは、Durable Objectsを基盤としており、すべてのエージェントにID、永続的な状態、およびメッセージを認識する能力を提供します。これがアクターモデルです。各エージェントは、独自のSQLiteデータベースを持つアドレス可能なエンティティです。ハイバネーション時の消費量はゼロです。何かが起きると（HTTPリクエスト、WebSocketメッセージ、スケジュールされた警告、受信メールなど）、プラットフォームはエージェントを起動し、状態をロードして、イベントを引き渡します。エージェントは作業を行うと、スリープ状態に戻ります。
| VM/コンテナ | Durable Objects |
|---|
アイドルコスト | 常にフルコンピューティングコスト | ゼロ（ハイバネーション） |
スケーリング | 容量のプロビジョニングと管理 | エージェントごとの自動 |
状態 | 外部データベースが必要 | 内蔵SQLite |
復旧 | 構築（プロセスマネージャー、ヘルスチェック） | プラットフォームを再起動、状態は存続 |
アイデンティティ/ルーティング | 構築はお客様による（ロードバランサー、他方のセッションなど） | 組み込み型（名前 → エージェント） |
10,000のエージェント、それぞれアクティブ率1% | 常時稼働インスタンス 10,000件 | 約100件のアクティブな攻撃 |
これにより、エージェントを大規模に実行することの経済状態が変化します。「パワーユーザーごとに1つの高価なエージェント」ではなく、「顧客ごとに1つのエージェント」、「タスクごとに1つのエージェント」、または「メールスレッドごとに1つのエージェント」を構築することができます。新しいエージェントを生成するためのわずかなコストは、事実上ゼロです。
クラッシュの耐久性確保：ファイバーによる耐久性のある実行
LLMの呼び出しにかかる時間は30秒です。複数ターンのエージェントループは、はるかに長い間実行されることがあります。このウィンドウのどの時点でも、実行環境は消失する可能性があります。デプロイ、プラットフォームの再起動、リソース制限などです。モデルプロバイダーへのアップストリーム接続は永続的に切断され、メモリ内の状態は失われ、接続されたクライアントは説明なしにストリームが停止したことを見ることができます。
runFiber() がこれを解決します。Fiberは耐久性のある関数呼び出しです。実行が開始される前にSQLiteに登録され、stash()を介して任意の時点でチェックポイント可能で、onFiberRecoveredを介して再起動時に回復できます。
import { Agent } from "agents";
export class ResearchAgent extends Agent {
async startResearch(topic: string) {
void this.runFiber("research", async (ctx) => {
const findings = [];
for (let i = 0; i < 10; i++) {
const result = await this.callLLM(`Research step ${i}: ${topic}`);
findings.push(result);
// Checkpoint: if evicted, we resume from here
ctx.stash({ findings, step: i, topic });
this.broadcast({ type: "progress", step: i });
}
return { findings };
});
}
async onFiberRecovered(ctx) {
if (ctx.name === "research" && ctx.snapshot) {
const { topic } = ctx.snapshot;
await this.startResearch(topic);
}
}
}
SDKはファイバーの実行中、自動的にエージェントを有効にします。特別な設定は必要ありません。分単位で測定される作業時間については、keepAlive() / keepAliveWhile()がアクティブな作業中の退去を防止します。より長い操作（CIパイプライン、設計レビュー、動画生成）の場合、エージェントは作業を開始し、ジョブIDを保持し、ハイバネーションし、コールバック時に起動します。
単一のエージェントがすべてを行うべきではありません。サブエージェントは、Facetsを介して親と併置された子Durable Objectsであり、それぞれが独自の分離されたSQLiteと実行コンテキストを持ちます。
import { Agent } from "agents";
export class ResearchAgent extends Agent {
async search(query: string) { /* ... */ }
}
export class ReviewAgent extends Agent {
async analyze(query: string) { /* ... */ }
}
export class Orchestrator extends Agent {
async handleTask(task: string) {
const researcher = await this.subAgent(ResearchAgent, "research");
const reviewer = await this.subAgent(ReviewAgent, "review");
const [research, review] = await Promise.all([
researcher.search(task),
reviewer.analyze(task)
]);
return this.synthesize(research, review);
}
}
サブエージェントは、ストレージレベルで分離されます。それぞれが独自のSQLiteデータベースを取得しますが、それらの間でデータが暗黙的に共有されることはありません。これは、サブエージェントRPC遅延が関数呼び出しであるランタイムによって実行されます。TypeScriptはコンパイル時に誤用を検出します。
数日または数週間にわたって稼働するエージェントの場合、通常のフラットなメッセージリスト以上のメッセージが必要です。実験的なセッションAPIは、これを明示的にモデル化しています。Agentベースクラスで利用可能。会話はツリーとして保存されます。各メッセージにはparent_IDがあります。これにより、フォーク（元のパスを失うことなく代替手段を探る）、非破壊的圧縮（古いメッセージを削除するのではなく要約する）、およびFTS5を介した会話履歴のフルテキスト検索が可能になります。
import { Agent } from "agents";
import { Session, SessionManager } from "agents/experimental/memory/session";
export class MyAgent extends Agent {
sessions = SessionManager.create(this);
async onStart() {
const session = this.sessions.create("main");
const history = session.getHistory();
const forked = this.sessions.fork(session.id, messageId, "alternative-approach");
}
}
セッションはAgentで直接使用でき、Thinkベースクラスが構築するストレージレイヤーです。
従来のツール呼び出しは、扱いにくい形をしています。モデルはツールを呼び出し、コンテキストウィンドウで結果を引き出し、別のツールを呼び出し、元に戻すという動作をします。ツールの対象領域が拡大すれば、これは高価かつ使い勝手の悪いものになります。100ファイルは、モデルを介した100回のラウンドトリップを意味します。
しかし、モデルはツールを呼び出すゲームよりも、システムを使用するためのコードを書く方が得意です。これは、@cloudflare/codemodeの背後にあるインサイトです。一連のツール呼び出しの代わりに、LLMはタスク全体を処理する単一のプログラムを書きます。
// The LLM writes this. It runs in a sandboxed Dynamic Worker.
const files = await tools.find({ pattern: "**/*.ts" });
const results = [];
for (const file of files) {
const content = await tools.read({ path: file });
if (content.includes("TODO")) {
results.push({ file, todos: content.match(/\/\/ TODO:.*/g) });
}
}
return results;
モデルとの100回の往復の代わりに、単一のプログラムを実行するだけでよいのです。これにより、使用されるトークンが少なく、実行が速く、結果が改善されます。Cloudflare API MCPサーバーは、これを大規模に実証しています。当社が公開するツールはsearch()とexecute()の2つのみで、これらは約1,000トークンを消費します。これは、エンドポイントごとに単純なツールを使用した場合の約117万トークンとは対照的です。これは99.9%の削減です。
モデルがユーザーに代わってコードを書く必要があると仮定すると、問題はそのコードがどこで実行されるか、ということになります。最終的には、製品チームがそれをロードマップの項目に変換した後ではありません。現在、このユーザーは、このシステムに対して、厳密に定義された権限でアクセスが可能です。
Dynamic Workersがそのサンドボックスです。数メガバイトのメモリを使用して、実行時に数ミリ秒でスピンアップされます。これは、コンテナより約100倍速く、最大100倍のメモリ効率があります。リクエストごとに新しいものを開始し、コードのスニペットを実行して、破棄することができます。
設計における重要な選択は能力モデルです。汎用マシンから始めてそれを制約するのではなく、Dynamic Workersは、アンビエント権限がほとんどない状態から始まり（globalOutbound: null、ネットワークアクセスなし）、開発者はバインディングを通じて、リソースごとに明示的に機能を付与します。「過剰な行為を防ぐにはどうすればいいか？」を考え始めるのです。 「私たちは、具体的に何をできるようにしたいのか？」
これはエージェントインフラストラクチャに正しい質問です。
この能力モデルは、当然ながら、エージェントが必要に応じて段階的に利用する、実行ラダーであるコンピューティング環境の多様化につながります。
階層0はWorkspace、SQLiteとR2に支えられた耐久性のある仮想ファイルシステムです。読み取り、書き込み、編集、検索、グループ化、差分。提供@cloudflare/shell。
Tier 1はDynamic Workerで、ネットワークにアクセスできないサンドボックス化された分離環境で実行されるLLM生成のJavaScriptがこれに該当します。提供@cloudflare/codemode.
階層2はnpmを追加します。@cloudflare/worker-bundlerは、レジストリからパッケージを取得し、esbuildとバンドルし、結果をDynamic Workerに読み込みます。エージェントは import { z } from "zod" と記述し、すべて動作します。
階層3は、Cloudflare Browser Runを介したヘッドレスブラウザです。ナビゲート、クリック、抽出、スクリーンショット。サービスがMCPまたはAPI経由でエージェントをまだサポートしていない場合に有用です。
Tier 4 は、ツールチェーン、リポジトリ、依存関係が設定された Cloudflare Sandbox です。git clone、npm test、cargo build は、ワークスペースと双方向で同期されます。
重要な設計原則: エージェントはTier 0単独でも有用であるべきで、各階層は付加的なものとなる。ユーザーは、必要に応じて機能を追加することができます。
これらのプリミティブはすべて、スタンドアロンパッケージとして利用可能です。Dynamic Workers、@cloudflare/codemode、@cloudflare/worker-bundler、および@cloudflare/shell（ツールを備えた永続ファイルシステム）はすべて、Agentベースクラスで直接使用できます。これらを組み合わせることで、エージェントに作業領域、コード実行、ランタイムパッケージ解決を提供することができます。
以下は、Cloudflareでエージェントを構築するための全スタックです：
これらは、それぞれが重要な要素です。これらが合わさって、まったく新しいものを形成します。それは、今ローカルのマシン上で実行しているAIエージェントと同じ能力のAIエージェントを、誰でも構築、デプロイ、実行できるプラットフォームです。ただし、サーバーレスで、耐久性があり、設計上安全です。
プリミティブを見てきたので、次はこれらをすべてつなぎ合わせた場合に起こることを示しています。
Thinkは、独自の規約を持つハーネスであり、エージェントループ、メッセージの永続化、ストリーミング、ツール実行、ストリーム再開、拡張機能など、チャットライフサイクル全体を処理します。エージェントの独自性に重点を置いています。
最小のサブクラスは次のようになります：
import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";
export class MyAgent extends Think<Env> {
getModel() {
return createWorkersAI({ binding: this.env.AI })(
"@cf/moonshotai/kimi-k2.5"
);
}
}
事実上、ストリーミング、パーシスタンス、中断/キャンセル、エラー処理、再開可能なストリーム、組み込みのワークスペースファイルシステムを備えた作業用チャットエージェントが必要なのはこれだけです。npx wrangler deploy でデプロイする。
考えることができるようになるのです。制御を強化する必要がある時は、注目するものをオーバーライドすることができます。
オーバーライド | 目的 |
getModel()
| 使用する言語モデルを返す |
getSystemPrompt()
| システムプロンプト |
getTools()
| エージェンティックループ向けのAI SDK互換ToolSet |
maxSteps
| 1ターンあたりの最大ツール呼び出し回数 |
ConfigurationSession()
| コンテキストブロック、圧縮、検索、スキル |
内部では、Thinkはすべてのターンで完全なエージェントループを実行します。コンテキスト（基本指示 + ツール説明 + スキル + メモリ + 会話履歴）を組み立て、streamTextを呼び出し、ツールコールを実行し（コンテキストの肥大化を防ぐための出力切り捨て）、結果を追加し、モデルが完了するかステップ制限に達するまでループします。すべてのメッセージは、各ターンの処理後に残ります。
パイプライン全体を所有する必要はなく、チャットターンの各段階でフックを提供できると考えてください。
beforeTurn()
→ streamText()
→ beforeToolCall()
→ afterToolCall()
→ onStepFinish()
→ onChatResponse()
フォローアップターンを低コストのモデルに切り替え、使用できるツールを制限し、ターンごとにクライアントサイドのコンテキストで渡します。また、分析へのすべてのツール呼び出しをログに記録し、モデルが完了した後、onChatMessage を置き換えることなく、フォローアップターンを自動的に再度トリガーします。
Thinkは、セッションAPIをストレージレイヤーとして利用しており、ブランチングが組み込まれたツリー構造のメッセージを提供します。
さらに、コンテキストブロックを通じて永続的なメモリを追加します。これらは、モデルが時間の経過とともに読み取り、更新できるシステムプロンプトの構造化されたセクションであり、ハイバネーション後も存続します。モデルは「MEMORY（重大な事実、更新にはset_contextを使用）[42%、462/1100トークン]」を見て、積極的に記憶することができます。
configureSession(session: Session) {
return session
.withContext("soul", {
provider: { get: async () => "You are a helpful coding assistant." }
})
.withContext("memory", {
description: "Important facts learned during conversation.",
maxTokens: 2000
})
.withCachedPrompt();
}
セッションは柔軟です。エージェントごとに複数の会話を実行し、元の内容を失うことなく、別の方向へフォークすることができます。
コンテキストが拡大するにつれて、Thinkは非破壊的な圧縮で限界に対応します。古いメッセージは削除されずに要約されますが、全履歴はSQLiteに保存されます。
検索機能も組み込まれています。FTS5を使用すると、セッション内、またはすべてのセッションの会話履歴をクエリできます。エージェントは、search_contextツールを使用して、自身の過去を検索することもできます。
実行ラダー全体を統合して、一つのgetTools()を返すと考えてください。
import { Think } from "@cloudflare/think";
import { createWorkspaceTools } from "@cloudflare/think/tools/workspace";
import { createExecuteTool } from "@cloudflare/think/tools/execute";
import { createBrowserTools } from "@cloudflare/think/tools/browser";
import { createSandboxTools } from "@cloudflare/think/tools/sandbox";
import { createExtensionTools } from "@cloudflare/think/tools/extensions";
export class MyAgent extends Think<Env> {
extensionLoader = this.env.LOADER;
getModel() {
/* ... */
}
getTools() {
return {
execute: createExecuteTool({
tools: createWorkspaceTools(this.workspace),
loader: this.env.LOADER
}),
...createBrowserTools(this.env.BROWSER),
...createSandboxTools(this.env.SANDBOX), // configured per-agent: toolchains, repos, snapshots
...createExtensionTools({ manager: this.extensionManager! }),
...this.extensionManager!.getTools()
};
}
}
Thinkは、コードの実行をさらに一歩進めます。エージェントは独自の拡張を記述することができます。つまり、Dynamic Workersで実行され、ネットワークアクセスやワークスペース操作の許可を宣言するTypeScriptプログラムです。
{
"name": "github",
"description": "GitHub integration: PRs, issues, repos",
"tools": ["create_pr", "list_issues", "review_pr"],
"permissions": {
"network": ["api.github.com"],
"workspace": "read-write"
}
}
Think's ExtensionManager は、拡張機能（オプションで @cloudflare/worker-bundler を介したnpm依存関係を含む）をバンドルし、Dynamic Workerにロードして、新しいツールを登録します。拡張機能はDOストレージに永続的で、ハイバネーションにも耐え得ます。次にユーザーがプルリクエストについて尋ねたとき、エージェントは30秒前には存在しなかったgithub_create_prツールを持っています。
これは、時間の経過とともにエージェントを本当に有用にしていく、自己改善型のループのようなものです。微調整やRLHFではなく、コードを通して行われるのです。エージェントは、サンドボックス化され、監査可能で取り消し可能なTypeScriptで、新しい機能を自分で書くことができます。
Thinkもサブエージェントとして機能し、親からRPCを介してchat()経由で呼び出され、コールバックを介してイベントをストリーミングします。
const researcher = await this.subAgent(ResearchSession, "research");
const result = await researcher.chat(`Research this: ${task}`, streamRelay);
児童はそれぞれ独自の会話ツリー、メモリ、ツール、モデルを取得します。親は詳細を知る必要はありません。
Project Thinkは実験的なものです。APIサーフェスは安定していますが、今後数日および数週間で進化し続けるでしょう。独自のバックグラウンドエージェントインフラストラクチャの構築にすでに社内で使用しており、早期に共有することで、あなたが私たちと一緒に構築できるようにします。
npm install @cloudflare/think agents ai @cloudflare/shell zod workers-ai-provider
// src/server.ts
import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";
import { routeAgentRequest } from "agents";
export class MyAgent extends Think<Env> {
getModel() {
return createWorkersAI({ binding: this.env.AI })(
"@cf/moonshotai/kimi-k2.5"
);
}
}
export default {
async fetch(request: Request, env: Env) {
return (
(await routeAgentRequest(request, env)) ||
new Response("Not found", { status: 404 })
);
}
} satisfies ExportedHandler<Env>;
// src/client.tsx
import { useAgent } from "agents/react";
import { useAgentChat } from "@cloudflare/ai-chat/react";
function Chat() {
const agent = useAgent({ agent: "MyAgent" });
const { messages, sendMessage, status } = useAgentChat({ agent });
// Render your chat UI
}
Thinkは@cloudflare/ai-chatと同じWebSocketプロトコルを使用しているため、既存のUIコンポーネントはすぐに動作します。AIChatAgentを基に構築した場合でも、クライアントコードは変更されません。
AIエージェントには3つの波があります：
第1の波はチャットボットでした。ステートレスで、リアクティブで脆弱なものでした。会話のすべてがゼロから始まり、メモリもツールも行動もありません。そのため、質問に答えるために有用でしたが、質問への回答だけに限定されていました。
第2の波は、コーディングエージェントを使用したものでした。これらは、Pi、Claude Code、OpenClaw、Codeexのようなステートフルでツール使用の、はるかに能力の高いツールです。これらのエージェントは、コードベースを読み取り、コードを書き、実行し、反復することができます。この結果、適切なツール付きのLLMは汎用マシンであるが、1人のユーザー向けのノートパソコン上で動作し、耐久性は保証されないことが証明されました。
そして今、インフラとしてのエージェントという第3の波が突入しています。耐久性、分散性、構造的に安全性、そしてサーバーレス。これらは、インターネット上で実行され、障害に指定され、アイドル状態ではコストは一切かかりず、動作ではなくアーキテクチャを通じてセキュリティを強化するエージェントです。開発者が任意の数のユーザーのために構築およびデプロイできるエージェント。
これは、私たちが賭けている方向性です。
Agents SDKはすでに数千の本番エージェントを支えています。Project Thinkとそれが導入するプリミティブによって、不足しているピースを追加し、エージェントの能力を劇的に向上させます。永続的なワークスペース、サンドボックス化されたコード実行、耐久性のある長期実行タスク、構造的セキュリティ、サブエージェントの調整、自己認証などです。契約が必要です。
本日、プレビューとして公開されます。当社はお客様と共に構築しています。お客様（とコーディングエージェント）がそれを使ってどんなものを作るのか、楽しみにしています。
ThinkはCloudflare Agents SDKの一部です（@cloudflare/think）。この記事で説明している機能はプレビュー版です。フィードバックを取り入れることで、APIが変更される可能性があります。ドキュメントと例を確認して開始してください。