あなたのLLMはコーディングエージェントのワークフローであるべきではない：OpenClawにおける関心の分離

コーディングエージェントのワークフローがLLMの利用制限に達した瞬間に停止してしまうなら、それはアーキテクチャに問題があります。LLMがやりすぎているのです。OpenClawコミュニティの実践的なルール：モデルは作業について推論すべきですが、ワークフローそのものになるべきではありません。

重要なポイント

• オーケストレーションと判断を分離する：キュー、状態管理、リトライ、スケジューリング、検証、レシート、リカバリはすべて、LLMの関与なしに決定的に実行できます。
• 判断が必要な場合にのみLLMを呼び出す：モデルの呼び出しは、本当に推論が必要なタスクに集中させ、ルーチンの制御フローには使用しないでください。
• ループをインフラにする：この分離により、エージェントループは「プロンプトを繰り返す」ものから、実際に信頼性高く動作するものへと変わります。

なぜ重要か

LLMがワークフローのすべてのステップに組み込まれていると、利用制限がハードストップになります。作業が完了したからではなく、オーケストレーターが頭脳なしでは思考できないためにブロックされるのです。状態トラック、リトライロジック、スケジューリング、検証チェックなどの決定的な部分をプレーンなコードに移すことで、LLMが利用できなくてもシステムは機能し続けます。

その結果、コーディングエージェントのループはインフラのように動作します。つまり、自己回復、リトライ、検証を自律的に行います。実際に推論が必要な場合にのみLLMトークン（と制限）を消費します。

対象読者

OpenClawなどを使用してコーディングエージェントを構築・拡張する開発者で、脆弱なプロンプトチェーンではなく、堅牢で本番グレードの自動化を目指す方。