常駐・調整・委譲——AIエージェントオーケストレーションの次の形：ClawsとCord

AIエージェントが「呼ばれたら動いて、終わったら消える」フェーズを抜けつつある。2026年2月、ほぼ同時に2つのプロジェクトが出てきた。Andrej Karpathyが概念に名前をつけた「Claws」と、June KimがPython 500行で動くものを作った「Cord」。片方は語彙の定義、もう片方は動くコード。どちらもエージェントの「次の層」を扱っている。

Claws——Karpathyがつけた名前

Andrej KarpathyがMac Miniを買ってClawsを動かしている、とポストした。Simon Willisonがそれを拾って解説記事を書いた（simonwillison.net/2026/Feb/21/claws/）。

Karpathyの定義はこうだ：

Clawsは、オーケストレーション、スケジューリング、コンテキスト、ツール呼び出し、および永続性を次のレベルに引き上げる

要するに、LLMエージェントの上にもう一枚レイヤーをかぶせるという話。Claude Code CLIのようなツール呼び出しエージェントは、タスクを受け取って実行して終わる。セッションが切れたら状態は消える。Clawsはそこに常駐性を足す。

要素	単体エージェント	Claws
ライフサイクル	起動→実行→終了	常駐。セッションをまたいで生存
スケジューリング	なし。呼ばれたら動く	自律的にタスクをキューイング・実行
コンテキスト	実行中のみ保持	永続化。過去の結果を参照可能
ツール連携	直接呼び出し	メッセージプロトコル経由で間接的に仲介
実行環境	クラウドAPI or ローカル	個人ハードウェア前提

個人のMac Miniで動く常駐型AIシステム、という具体像がKarpathyの発言から見える。直接の指示にも応答するし、スケジュールされたタスクも自律的にこなす。公式絵文字は🦞。

OpenClawの爆発的普及とKarpathyの警戒

この「Claw」カテゴリの火付け役はOpenClaw。Peter Steinbergerが開発したオープンソースの自律AIエージェントで、2026年1月29-30日にGitHub 100Kスターを約2日で達成した。史上最速。ピーク時のスター増加速度は710スター/時。

OpenClawはNodeJSベースで、音声対話、ライブキャンバス、メッセージングプラットフォーム連携など全部入りの構成。ただし1GB超のメモリを使い、コードベースは40万行を超える。

Karpathyは自分のMac MiniでClawを試しつつも、OpenClawに対しては明確に警戒している:

giving my private data/keys to 400K lines of vibe coded monster that is being actively attacked at scale is not very appealing at all. Already seeing reports of exposed instances, RCE vulnerabilities, supply chain poisoning, malicious or compromised skills

40万行のvibe codedモンスターに秘密鍵を渡す気にならない、と。RCE脆弱性、サプライチェーン汚染、悪意あるスキルの報告が既に出ている。

2月14日にSteinbergerはOpenAIへの参加を発表し、OpenClawはオープンソース財団に移管される予定。

Claw実装群の乱立

OpenClawへの不満や用途の違いから、2月に入って代替実装が一斉に出てきた。

実装	言語	メモリ/バイナリ	特徴
OpenClaw	NodeJS	1GB超	全部入り。音声・キャンバス・コンパニオンアプリ
ZeroClaw	Rust	3.4MB / 5MB未満	プロバイダ・ツール・メモリが全てswappable trait。起動10ms未満
PicoClaw	Go	10MB未満	$10のハードウェアで動く。95%がAI生成コード。2/9公開、4日で5000スター
NullClaw	Zig	678KB	Arduino/Raspberry Pi対応。2,000以上のテスト
NanoClaw	TypeScript	約4,000行	コンテナ内実行。Anthropic Agents SDK直結
IronClaw	Rust	—	WebAssemblyサンドボックス。認証情報をツールから隔離。プロンプトインジェクション防御
TinyClaw	—	—	マルチエージェント協調（coder/writer/reviewer）

ZeroClawはOpenClawの194分の1のメモリで動く。PicoClawは$10のボードで動くことを売りにしている。IronClawはセキュリティ特化で、全ツールをWasmサンドボックス内で実行する。

共通しているのは「OpenClawはデカすぎる」という問題意識だ。40万行のコードベースを個人がセキュリティ監査するのは現実的でなく、軽量な代替を求める動きが同時多発的に起きた。Karpathyが「Claw」という名前を使った時点で、この概念は個別のプロジェクト名を超えてカテゴリ名になった。Simon Willisonも記事でそれを指摘している。

Cord——ワークフローのハードコードをやめる

June Kimが作ったCordは500行のPythonとSQLite、MCPで実装された概念実証。Hacker Newsで112ポイントを獲得した。

既存フレームワークの共通の壁

LangGraph、CrewAI、AutoGen、OpenAI Swarm。今のマルチエージェントフレームワークは、タスクの分解構造を開発者が事前に決める必要がある。この前提が共通のボトルネックになっている。

フレームワーク	何ができて、何ができないか
LangGraph	固定ワークフローは強力。ただし実行中に新しい分解が必要になったら対応できない
CrewAI	役割ベースで分かりやすい。が、構造は事前定義必須で動的なチーム再編は不可
AutoGen	会話ベースで柔軟。だが依存関係の追跡と権限スコープの仕組みがない
OpenAI Swarm	シンプルだが線形。並列化や木構造の分岐がない
Claude単体	コンテキストウィンドウの制約と単一スレッド

全部「開発者がワークフローを設計し、エージェントがそれを実行する」モデル。CordはこれをひっくりかえしてAIエージェント自身が実行時にタスク構造を決める。

SpawnとFork——コンテキスト共有の制御

Cordが提供するMCPプリミティブは5つ。

Spawn: クリーンなコンテキストで子タスクを生成。子エージェントは自分のプロンプトと明示的な依存関係だけを受け取る。まっさらな状態で専門家を投入するイメージ
Fork: 全兄弟タスクの結果を引き継いだ子を生成。子エージェントはそれまでの全文脈を把握した状態で起動する。ブリーフィング済みのメンバーを追加するイメージ
Ask: 人間に情報を問い合わせ、実行を一時停止
Complete: タスクを結果とともに完了マーク
Read_tree: 現在のタスクツリー全体を参照

SpawnとForkの区別がCordの設計の核。両方とも子タスクを作るが、「子が起動時に何を知っているか」がまったく違う。

Spawnで作られた子はコンテキストが空。依存タスクの出力だけが渡される。並列実行される独立した調査タスクに向いている。一方、Forkで作られた子は全兄弟の結果を最初から持っている。複数の調査結果を統合して最終判断を出すようなタスクに使う。

この2つを使い分けることで、コンテキストウィンドウの汚染を防ぎつつ、必要な情報は確実に渡せる。各エージェントが知る範囲をプリミティブレベルで制御するという設計方針だ。

SQLiteによる状態管理

Cordの状態管理はSQLiteに一本化されている。

技術スタック:
- Claude Code CLI（エージェントランタイム）
- SQLite（エージェント間の共有状態・タスクツリーの永続化）
- MCPサーバー（依存関係解決・権限スコープの強制）
- Python ~500行（オーケストレーション層全体）

SQLiteを選んだ理由は明快だ。ファイルベースでサーバー不要、トランザクションがあり、複数プロセスからの同時読み取りに対応する。タスクの状態遷移（pending → running → completed）、依存関係グラフ、各タスクの出力結果がすべてSQLiteの単一ファイルに入る。

MCPサーバーがSQLiteを介して権限スコープを強制するため、子エージェントが親の管轄外のタスク結果にアクセスしようとしても拒否される。この権限制御がないと、Forkで全文脈を渡す設計は情報漏洩のリスクを抱える。

動作例：ワークフローを書かずにワークフローが生まれる

クエリ「APIをRESTからGraphQLに移行すべきか？」に対して、開発者はタスク構造を一切コーディングしていない。Claudeが自律的に設計した構造がこうなった：

#1 Root: GraphQL移行分析
├── #2 現行API監査 [Spawn: 並列実行、コンテキスト独立]
├── #3 GraphQL調査 [Spawn: 並列実行、コンテキスト独立]
├── #4 要件確認 [Ask: 人間に問い合わせ、#2完了待ち]
└── #5 最終推奨 [Fork: #2,#3,#4の全結果を統合]
    └── #6 レポート生成 [Spawn: #5の結果のみ受け取る]

#2と#3はSpawnで生成されているから互いの存在を知らない。独立して並列実行される。#5はForkで生成されるため、#2〜#4すべての結果を持った状態で起動する。#6は#5の結果だけあれば十分なのでSpawn。

エージェントが問題の構造を見て、SpawnとForkを適切に使い分けた。開発者が書いたのはルートの質問だけだ。

先に検証、後からインフラ

June Kimのアプローチで特徴的なのは、インフラを作る前に検証を済ませたことだ。15回のテストで確認した内容：

Claudeが read_tree() を自発的に呼んで全体の状態を確認した
SpawnとForkの使い分けを、説明なしに正しく適用した
権限外のアクセスを拒否された際、リトライせずエスカレーションした

モデルが協調プリミティブを自然に理解することを先に確認して、それからインフラを実装した。普通はインフラを作ってからテストするが、逆の順序を取った。プリミティブの設計がモデルの振る舞いに合っているかを先に検証することで、500行で十分な実装に落とせたのだろう。

OpenClawのセキュリティを締めきれないというか信じきれないので、自分で作ってた。その話はまた今度。

参照: