OpenClawが年初に公開されたあと、コミュニティでよく出る次の質問は「複数agentは本当に違いがあるの？分けた方が管理しづらくない？」でした。
ここでは、実際に使っている複数agent構成を整理します。Opusが戦略、Sonnetが機械的な作業、Codexがコードを書く構成です。分担の考え方、記憶共有、スケジュール連携、つまずいたところまでまとめます。
なぜ1つでは足りないのか
最初はagentを1つだけにして、全部任せていました。記事を書く、コードを直す、スケジュールを走らせる、ニュースを読む。全部を同じClaude Codeセッションに入れていました。
しばらく動かすと問題が見えてきます。記事はうまく書けるのに、コードを直すとたまにバグが入る。コードを直したあと記事に戻ると、前に決めたトーン設定を忘れている。
実際に起きた話です。Opusに cron/jobs.json の時間フィールドを1つ直してもらいました。直りはしましたが、同時に別のJSON keyの引用符形式を壊しました。その夜のスケジュールは全部止まりました。
同じ作業をCodexに渡すと、形式を直して余計な文字は1つも触りません。ただしCodexにSNS文面を書かせると、READMEを読んでいるような文章になります。
Sonnetはバッチタスクなら速くて安いです。でも記事タイトルを決めさせると、SEOスコアが一番高いものを選び、トーンが完全にずれていました。
1つのagentに全部やらせると、役割を切り替えるたびに品質が落ちます。分けてからは、それぞれが一番安定する仕事だけを担当するようになり、失敗率が明らかに下がりました。
4つのAgentの分担
Opus：戦略の頭脳
Opusはシステム全体の中心的な意思決定者です。
担当すること：
- コンテンツ戦略と記事執筆
- 記憶システム管理（何を覚え、何を忘れるかを決める）
- Agent間の調整（taskを誰に渡すかを判断する）
- 品質レビュー（Codexが書いたコード、Sonnetが出した結果をOpusがレビューする）
鉄則が1つあります。Opusは直接コードを変更しません。Opusはたまにコードを壊しますが、コードレビューはとても得意です。読ませる、判断させる、レビューさせる。手を動かすところはCodexに任せます。
Opusのセッションはたいてい一番長くなります。戦略系の会話には大量の文脈が必要だからです。読む記憶ファイルも一番多く、プロジェクトファイル、MEMORY.md、その日のjournalを合わせると、他のagentの2〜3倍になります。
Sonnet：高速実行
Sonnetが担当するのは、判断力をあまり必要としない作業です。判断基準はシンプルです。SOPを書いてインターンにそのまま実行してもらえる作業なら、Sonnetに渡します。
作業リスト：
- 動画のスクリーンショット取得と変換
- データの一括整形
- テンプレート化されたSNS投稿の下書き
- 固定フォーマットのデータ整理
Sonnetの強みは速さとtokenコストの低さです。Opus 1回分の費用で、Sonnetのtaskをいくつも走らせられます。量が多く、創造力を必要としない作業では、コスト差がかなり大きいです。
つまずいたこともあります。判断力が必要なtaskをSonnetに渡したら、間違った方向をとても真面目に実行してしまい、あとから直す方が時間がかかりました。安定する原則は、先に考えないと進め方を決められない仕事はSonnet向きではない、です。
Codex：コード専門家
コードに関係する作業は全部Codexに渡します。機能開発、バグ修正、テスト作成、リファクタリングです。
モデルはChatGPT最新バージョンに固定しています。低いバージョンのCodexはコード品質が安定しませんでした。これは痛い経験からの結論です。
Codexはとても精密ですが、曖昧なところを自分から考えるタイプではありません。明確なspecを渡すと質の高いコードを書きます。曖昧な依頼を渡すと、こちらが望まない実装を選ぶことがあります。なのでOpusが先に要件をはっきり書き、それをCodexへhandoffします。
作業フロー：Opusが技術計画を作り、specを書く → Codexが実装する → OpusまたはSonnetがコードレビューする。この3ステップでバグ率が下がりました。
記憶共有の設定方法
4つのagentは同じ .openclaw/ ディレクトリを読みます。追加の接続は不要です。MEMORY.md は共通の索引で、brain.md は共通の作業記憶です。
やることは、AGENTS.md に各agentの書き込み範囲をはっきり書くことです。
| Agent | 読めるもの | 書けるもの |
|---|---|---|
| Opus | すべて | 記憶ファイル、戦略ファイル、brain.md |
| Sonnet | task関連 | task出力ファイル |
| Codex | コード + spec | コードファイル |
なぜ分けるのか。2つのagentが同時に brain.md を編集すると、衝突したバージョンができます。あとから手作業で1時間かけて統合することも珍しくありません。安定するやり方は、brain.md を書けるのはOpusだけにし、他のagentは読むだけにすることです。
スケジュール連携
スケジュールtaskにも分担があります。
毎日のSNSコンテンツ作成を例にします。
- 朝6:00：Opusがニュース要約を読み、今日のSNSテーマを決める
- 朝7:00：SonnetがOpusの選んだテーマを使い、テンプレートから下書きを作る
- 朝8:00：Opusが下書きを確認し、トーンと内容を整える
- 予約時間：BufferでSNSへ予約配信する
この流れは毎日自動で走ります。私がたまに入るのはレビュー段階だけで、ほとんどの場合はOpus自身の判断で通せます。
スケジュール間の依存関係はcronの時間差で制御します。7:00のtaskは、6:00の結果がすでに書かれている前提です。6:00のtaskが遅れたり失敗したりすると、7:00のtaskにも問題が出ます。
前のtaskが正常に完了したかを確認するhealth checkスケジュールを追加できます。これがあると、夜中にスケジュールが落ちて翌日まで気づかない、という状況を避けやすくなります。
つまずいたところ
つまずき1：Opusに直接コードを直させる
Opusのコードレビュー能力は高いですが、直接手を動かすと形式やロジックを壊すことがあります。考えすぎるか、何度も修正を繰り返すかのどちらかで、分けて作業するようにしてからコード品質は明らかに安定しました。（私の見立てでは、Opusはコードを書く能力はあるけれど、判断と実装を同時にこなすとエラー率が上がります。）
つまずき2：共有記憶に権限分けがない
2つのagentが同じファイルを同時に書き、衝突しました。解決策は上の書き込み権限表です。
つまずき3：Sonnetに任せるべきではない判断をさせた
Sonnetに記事タイトルを決めさせたところ、SEOスコアは一番高いけれどトーンが完全に違うタイトルを選びました。それ以来、センスと判断が必要なことは全部Opusです。
つまずき4：Handoffファイルが分散しすぎた
最初はプロジェクトごとにhandoffファイルを置いていました。その結果、Opusは新しいtaskを把握するだけで5〜6か所を読む必要がありました。projects/handoff.md に一本化してから、流れはかなりスムーズになりました。
1つのAgentから始める方法
おすすめの拡張ルートです。
ステップ1：Opus + Codex。一番効果を感じやすい分担です。戦略とコードをきっちり分けます。この1ステップだけでも品質向上をはっきり感じられます。
ステップ2：Sonnetを足す。Opusが抱えている機械的なtaskを選び、Sonnetに渡します。tokenも時間も節約できます。
agentを1つ足すたびに、まず2週間ほど走らせて安定を確認してから次を足します。いきなり全部走らせると、システム問題の処理に時間を使うだけになりがちです。
関連記事
こぺんぎんの体験談
私のメインスタックは、OpenClaw上のOpus / Sonnet / Codexという3 agent構成です。毎日この構成で2つのブランドアカウント、複数の公開チャンネル、十数個のスケジュールtaskを管理しています。実践して一番実感しているのは、Opusは自分でコードを書くよりコードレビューの方がずっと安定することです。具体的な実装はCodexに任せると、分担がかなり明確になります。OpenClawは誰にでも合う道具ではありません。繰り返し発生する自動化taskがあるかを確認してから入れる方が、空振りになりにくいです。
よくある質問
Q: なぜ複数のagentが必要ですか？1つでは足りませんか？
1つでも使えますが、品質が安定しません。記事を書くのが得意なモデルと、コードを書くのが得意なモデルでは、向いている仕事がかなり違います。それぞれのagentに一番得意な仕事だけを任せると、全体の品質がかなり良くなります。
Q: 複数agentにすると費用は高くなりませんか？
割り振り方次第です。Opusは一番高いので、戦略と執筆だけに使います。機械的な作業はSonnetに渡すと、コストをかなり抑えられます。実践では月額費用の多くはOpusの執筆に使われ、Sonnetの比率はそれほど高くありません。
Q: agent同士はどうやって連絡しますか？
ファイルシステムを使います。agent同士がリアルタイムで会話するのではなく、共有された記憶ファイルで情報を渡します。Opusがhandoffファイルを書き、Codexがそれを読んで何をすればよいか把握します。シンプルですが効果があります。
Q: 4つのagentを同時に動かすと衝突しませんか？
衝突します。対策は書き込み権限を分けることです。各agentは自分の担当範囲のファイルだけを書けるようにします。Opusは戦略と記憶、Codexはコードだけを触り、2つのagentが同じファイルを同時に編集しないようにします。
Q: 2つのagentだけでも使えますか？
使えます。Opus + Codexから始めるのがおすすめです。片方が戦略、もう片方がコードを担当します。動作が安定してからSonnetを足すか考えれば大丈夫です。
Q: どのtaskをどのagentに渡せばよいですか？
判断基準は、判断力と創造力が必要ならOpus、純粋に機械的な実行ならSonnet、コードに関係するならCodexです。迷うものはいったんOpusに渡し、さらに分担すべきかを判断させます。
— Penchan