OpenClaw と Claude Code は、役割を分けて使うとかなり相性が良い組み合わせです。OpenClaw が「どの作業を、どこで、どの権限で走らせるか」を管理し、Claude Code は実際のコーディングやレビューを担当します。この記事では、OpenClaw 側の運用前提を踏まえて、Claude Code をどう呼び出すと実務で噛み合うかを整理します。
まず整理：OpenClaw と Claude Code の役割
- OpenClaw：Discord / cron / ブラウザ / ファイル操作などをまたいでタスクを調停する司令塔
- Claude Code：コード生成、修正、レビュー、リファクタリングなどを進めるコーディング担当
つまり、「依頼の受付と運用制御は OpenClaw、実装そのものは Claude Code」という分担にすると理解しやすいです。
どんな場面で連携させると強いか
- Discord から「このバグを直して」と投げて、バックグラウンドで実装を進めたいとき
- PR レビューや大きめのリファクタリングを、別セッションに分けて安全に走らせたいとき
- cron や定期タスクからコード監査・差分確認を回したいとき
逆に、単純な 1 行修正や軽いファイル編集なら、わざわざ Claude Code に渡さず OpenClaw 側で完結した方が速いこともあります。
連携方法は 2 パターンある
1. チャット上で Claude Code 系エージェントを起動する
OpenClaw では、チャットから「Claude Code でやって」と依頼したとき、ACP harness 経由の専用セッションとして起動する運用ができます。スレッド単位で作業を分けられるので、Discord での開発相談と相性が良いです。
2. coding-agent スキルでバックグラウンド実行する
新機能開発、PR レビュー、大規模リファクタリングのように長めのコーディング作業は、OpenClaw の coding-agent スキル経由でバックグラウンド実行するやり方もあります。探索・編集・検証をまとめて進めたいケース向きです。
導入前に確認したいポイント
- Claude Code が利用可能な環境か
まず Anthropic 側の Claude Code 利用条件を確認します。インストール方法や利用条件は公式案内が基準です。 - OpenClaw 側でどの実行方式を使うか
Discord スレッドでやるのか、cron / バックグラウンド実行でやるのかを先に決めると混乱しません。 - 権限と作業範囲を絞る
「どのディレクトリを触るか」「レビューだけか、編集まで許可するか」を明示すると事故が減ります。
実務での使い分け例
バグ修正
OpenClaw に「login.ts の認証エラーだけ直して。テスト結果も要約して」と投げると、対象ファイルと目的が明確なので Claude Code 側が動きやすくなります。
コードレビュー
「この PR の危険な差分だけ見て」「型安全性と例外処理だけ確認して」のように観点を限定すると、レビュー結果が実務で使いやすくなります。
長期タスク
複数ファイルにまたがる変更では、OpenClaw 側で別セッション化し、完了時だけ要約を返す形にするとメイン会話が散らかりにくいです。
失敗しやすいポイント
- 依頼が広すぎる：「いい感じに直して」は失敗しやすい
- 実行場所が曖昧：どのリポジトリ・どのブランチか不明だと危険
- 小さな修正まで全部委任する：軽作業まで外部化すると遅くなる
最初に確認しておきたい公式情報
仕様は更新されるので、導入前は公式ドキュメントを一度見直すのが安全です。
チェックリスト
- Claude Code の導入条件を公式で確認した
- OpenClaw 側で「チャット起動」か「バックグラウンド実行」かを決めた
- 対象ディレクトリ・対象ファイル・期待する出力を明示した
- 完了条件（修正、レビュー、要約）を最初に定義した
OpenClaw 側で先に決めると失敗しにくい運用項目
- 実行方式を先に固定する：Discord スレッドでの thread-bound セッションにするのか、バックグラウンド run にするのかを最初に決めると、完了通知やログの扱いがぶれません。
- 完了条件を 1 文で書く：たとえば「PR の危険差分だけ確認して 5 行で返す」「認証バグを修正してテスト結果まで残す」のように、終わり方を先に定義します。
- 権限境界を明示する：どのディレクトリを触るか、レビューのみか編集まで許可するか、外部送信があるかを分けると事故を減らせます。
初心者向けの最小ワークフロー例
- OpenClaw 側で対象リポジトリと目的を 1 つに絞る
- Claude Code 側には「修正」「レビュー」「要約」のどれを期待するかだけ渡す
- 完了後に差分・テスト結果・残課題の 3 点だけを返させる
この 3 段階にすると、指示が広がりすぎず、OpenClaw を司令塔として使う意味も見えやすくなります。
まとめ
OpenClaw と Claude Code の連携で大事なのは、単に 2 つをつなぐことではなく、誰が司令塔で、誰が実装担当かを分けることです。OpenClaw に調整役を任せ、Claude Code にコーディングを集中させると、Discord 運用でも定期実行でも扱いやすくなります。
まずは小さなバグ修正やレビュー依頼から試し、うまく回る指示の粒度を固めていくのがおすすめです。
OpenClaw と Claude Code を実務で分担するときの判断軸
「連携できる」だけでは実務で迷いやすいので、まずは どこで会話し、どこで実装し、どこで結果確認するか を3段階で分けると運用が安定します。
- 相談・受付：Discord やメイン会話で依頼内容を絞る
- 実装・レビュー：Claude Code 側でコード変更やレビューを進める
- 報告・判断：OpenClaw 側で結果を受け取り、次の実行可否を決める
この形にすると、OpenClaw は司令塔、Claude Code はコーディング担当という役割が崩れにくくなります。
thread-bound セッションとバックグラウンド実行の使い分け
| 使い方 | 向いている場面 | 避けたい場面 |
|---|---|---|
| thread-bound セッション | Discord で相談しながら小〜中規模の修正を進めたいとき | 長時間ジョブや大量ファイル探索を静かに回したいとき |
| バックグラウンド実行 | PR レビュー、大規模リファクタリング、複数ファイル変更 | 人間が途中で頻繁に方向修正したいとき |
判断に迷ったら、人間が途中介入する頻度で分けると失敗しにくいです。会話しながら詰めるなら thread、まとまった作業ならバックグラウンドが基本です。
依頼テンプレート例
- 修正依頼：対象ファイル、直したい不具合、完了条件、テスト方法を 1 メッセージで渡す
- レビュー依頼：PR / 差分 URL、見てほしい観点、危険箇所だけ返すか全体要約まで返すかを先に決める
- 調査依頼：実装は不要か、調査後に修正提案まで欲しいかを明示する
特に初心者は、「どのファイルを触るか」「何を返せば終わりか」 を最初に書くと、曖昧な往復を減らせます。
先に決めると事故が減るチェックポイント
- 対象リポジトリ・対象ディレクトリを明示したか
- 編集だけか、レビューだけか、実行検証まで許可するかを決めたか
- 外部送信や本番反映があるなら、誰が最終承認するかを決めたか
- 完了時に必要な報告形式（差分 / テスト / 残課題）を固定したか
この4点が固まるだけで、OpenClaw と Claude Code の連携はかなり安定します。特にチーム運用では、権限境界と完了条件を省略しないのが重要です。
コメント