#9: Claude Code のループ、global workspace、Workers Cache

今回は、Claude Code のループ分類、Anthropic の global workspace 研究を先に扱い、続いて Cloudflare Workers Cache、その他の話題を見ます。

Claude Code のループ分類

Claude Code チームの公式ブログ Getting started with loops（6 月 30 日付）が、ClaudeDevs の投稿をきっかけに大きく拡散していました。「プロンプトではなくループを設計する」という言い回しが X で人によって別の意味で使われている状況を受けて、チームとしての定義を「停止条件を満たすまで作業サイクルを繰り返すエージェント」に固定し、トリガー・停止条件・使う Claude Code プリミティブでループを 4 種類に分類しています。

• Turn-based: プロンプトごとの通常の agentic loop。検証手順を SKILL.md にエンコードして、Claude 自身が end-to-end で確認できる範囲を広げる。
• Goal-based（/goal）: 完了条件を定義すると、Claude が止まろうとするたびに評価用モデルが条件を判定し、達成か上限ターン数まで作業へ戻す。「テストが通る」「Lighthouse スコア 90 以上、5 回で打ち切り」のような決定的な条件が効く。
• Time-based（/loop / /schedule）: 一定間隔でプロンプトを再実行する。/loop はローカル実行で、/schedule でクラウドの routine に移せる。
• Proactive: /schedule + /goal + skills + dynamic workflows + auto mode を合成し、バグ報告のトリアージや依存アップグレードのような定常業務を人間の同席なしで回す。

公開後の反応は、「定義がやっと揃った」という歓迎と「回し始めると別のボトルネックが露出する」という現実論に割れています。肯定側は、loops を導入して 2 日かかっていた仕事が 2 時間になった運用例への参照が増え（Richard Seroter）、「4分類が実務で使いやすい」という紹介が広がりました。一方で、実装ループが速くなっても人間レビューが詰まると全体は詰まる、という典型的な詰まり方も共有されています（Matteo Collina）。つまり論点は「loop を回せるか」より「どこを停止条件にし、誰の承認を残すか」の設計に移っています。

ループ設計では、停止条件と検証手順そのものが品質ゲートになります。テスト・Lighthouse・レビュー基準を先に skill と /goal に埋め込まないと、反復回数だけ増えて不具合も増えます。公開後の反応で「ループで実装は速くなったがレビュー待ちが詰まる」という報告が出たのも、この設計点が原因です。トークン管理も同じで、決定的な作業は推論させずスクリプト化し、dynamic workflows は小さい範囲でパイロットしてから広げ、/usage で skills / subagents / MCP 別の消費を確認する運用が前提になります。

Anthropic の global workspace 研究

Anthropic が 7 月 6 日、interpretability 研究 A global workspace in language models を公開しました（Anthropic）。この話題で押さえる価値があるのは、「LLM が中で考えていることを、出力テキスト以外から読んで操作できるところまで来た」点です。彼らはその内部領域を J-space、読み出し手法を J-lens と呼んでいます。