0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@sescore(SES Core)

OpenClaw×Claude Code実践連携術—思考と実行を分業するAI開発フロー

0
Posted at

OpenClaw×Claude Code実践連携術—思考と実行を分業するAI開発フロー

はじめに

AIコーディングツールを日常的に使うエンジニアが増えた2026年現在、次の壁は「1つのAIに全部やらせる」運用の限界だ。プランニングも記憶管理も指示出しも実装も同じチャットセッションに詰め込むと、コンテキストはすぐに膨張し、数時間前の意思決定が忘れられ、同じ手戻りを繰り返す。

この課題に対して有効なのが、役割を分業する構成だ。OpenClawのような「思考・記憶・指示」を担うレイヤーと、Claude Codeのような「開発・実行」を担うレイヤーを分け、前者が方針と文脈を保持し、後者がその方針に沿って実際にコードを書き、コマンドを実行する。本稿では、この分業を実際にどう組むか、具体的なコマンドと設定例を交えて紹介する。

フリーランスでSES案件をこなしながら自分のツールも開発している、という働き方をしているエンジニアには特に相性がいい構成だと感じている。単価交渉のためのデータ分析ツールを自作したり、SESの受託業務と自社プロダクト開発を並行したりする場面で、AIの「記憶」と「実行」を分けておくと、コンテキストスイッチのコストを大きく下げられる。

OpenClawとClaude Codeの役割分担

思考・記憶・指示を担うレイヤー

OpenClaw側には、CEO・CFO・CTO・COOといった役割ごとのエージェントスキルを置き、経営判断や優先順位付け、過去の意思決定の記憶を担わせる。例えば以下のようなコマンド体系になる。

/cto health      # プロダクト群のヘルスチェックと技術的負債の棚卸し
/cto priority    # 開発優先度の提案
/cfo 未決済      # 財務状況と未決済案件の確認
/coo clients     # クライアント・案件管理の横断確認

これらは単発の質問応答ではなく、継続的な記憶を前提にしている。前回の判断や進行中のプロジェクトの背景を踏まえた上で、次に何を実行すべきかを言語化する層として機能する。人間で言えば、経営会議の議事録と方針を持ち続ける役割に近い。

開発・実行を担うレイヤー

Claude Code側は、この指示を受けて実際にコードを書き、テストを回し、コマンドを実行する。ポイントは、Claude Code自身にもプロジェクト単位の指示ファイル（CLAUDE.md）を持たせられることだ。

## Core Principles
- Simplicity First: 変更は必要最小限に留める
- No Laziness: 根本原因を特定し、一時しのぎの修正をしない
- Minimal Impact: 変更は必要な箇所のみに限定する

この設定ファイルはリポジトリに置かれるため、OpenClaw側から渡された方針とは別に、Claude Code自身が「どう実装するか」の作法を保持できる。思考レイヤーが「何を」「なぜ」を渡し、実行レイヤーが「どうやって」を担う、という分業が成立する。

役割分担を表にすると

観点 OpenClaw（思考・記憶・指示） Claude Code（開発・実行）
主な仕事 優先度判断、方針決定、記憶の保持 コード実装、コマンド実行、テスト
時間軸 週次・月次の継続的な文脈 セッション単位のタスク実行
出力 次に何をすべきかという指示 動くコード・実行結果
事故りやすい点 古い前提で指示を出す 指示を鵜呑みにして裏取りしない

実践ユースケース1: 経営判断から実装タスクへのルーティング

具体例として、複数のWebサービスを運用している場合を考える。OpenClawのCTOスキルで /cto health を実行すると、各プロダクトのビルド状態やエラーログを横断的にチェックし、優先度の高い技術的課題をリストアップする。そこで「このバグを直すべき」という判断が出たら、その内容をそのままClaude Codeに引き継ぐ。

Claude Code側では、Task管理機能で作業を分解し、必要に応じてサブエージェントに調査を委任する。

Agent(
  description: "認証まわりのバグ調査",
  prompt: "ログイン失敗率が上昇している原因を特定してほしい。
           直近のcommit履歴とエラーログを確認し、
           再現条件を報告して。",
  subagent_type: "Explore"
)

このように「原因調査」はサブエージェントに投げてメインのコンテキストを汚さずに進め、修正の実装だけをメインのセッションで行う、という流れにすると、1つの大きなタスクを複数の小さな独立作業に分解できる。原因調査と実装を同じコンテキストでやると、調査ログでコンテキストが埋まってしまい、肝心の実装判断が薄まるという問題が起きやすいが、この分業でそれを避けられる。

実践ユースケース2: 記憶をファイルベースで永続化する

OpenClawとClaude Codeの連携で特に効果を感じるのは、記憶をセッションではなくファイルに持たせる設計だ。Claude Code側にはMarkdownベースの記憶ファイルを持たせられる。

---
name: freelance-rate-negotiation
description: 単価交渉時に参照するデータ分析の方針
metadata:
  type: project
---

単価交渉の際は、過去の稼働実績とスキルセットの
市場相場を突き合わせたデータを用意してから臨む。

Why: 感覚的な交渉ではなく、稼働時間・成果物・
使用技術スタックを定量化した資料の方が交渉が通りやすい。

この記憶ファイルは会話が終わっても消えず、次にAIとやり取りするときに文脈として読み込まれる。OpenClaw側の意思決定と、Claude Code側の実装方針の両方を、同じ設計思想（何を・なぜ・どう使うか）で残しておくと、数週間後に見返しても迷わない。記憶ファイルが増えてきたら、索引となるインデックスファイルを1つ用意し、そこから各ファイルへリンクを張る構成にすると、後から探しやすくなる。

実践ユースケース3: Workflowで調査とレビューを並列化する

規模の大きい変更やコードレビューでは、単一のAIに全部やらせるより、複数のサブエージェントを並列で走らせて統合するほうが速く、かつ見落としが減る。Claude Code環境ではこうした複数エージェントのオーケストレーションをスクリプトとして定義できる。

export const meta = {
  name: 'review-and-verify',
  description: '変更差分を複数の観点でレビューし、指摘を検証する',
}

const dimensions = ['correctness', 'security', 'performance']
const findings = await parallel(
  dimensions.map(d => () => agent(`${d}の観点でdiffをレビューして`))
)

こうしたパターンをOpenClaw側の定例チェック（例えば週次のヘルスチェック）と組み合わせると、経営レイヤーが「今週レビューすべき対象」を判断し、実行レイヤーが並列レビューを回す、という役割分担が自然にできる。1人の担当者が全部の観点を順番にレビューするより、観点ごとに独立したエージェントを走らせたほうが、指摘の見落としが減るのは体感として大きい。

実践ユースケース4: 定期チェックの結果を思考レイヤーに戻す

分業がうまく回るかどうかは、実行レイヤーの結果を思考レイヤーに戻す経路があるかどうかで大きく変わる。Claude Code側で毎週の依存パッケージ更新チェックやテストカバレッジの計測を自動実行し、その結果を記憶ファイルとして書き出しておくと、次にOpenClaw側で /cto priority を実行したときに、その結果を踏まえた優先度判断ができる。実行レイヤーが「調べた事実」を記録し、思考レイヤーが「その事実をどう解釈し、次に何をすべきか」を判断する、という一方通行ではない往復の設計にすることが、分業を機能させる鍵になる。この往復がないと、思考レイヤー側の判断がいつまでも古い前提のまま更新されず、実行レイヤーが積み上げた事実が活かされないまま埋もれてしまう。

無人運用で気をつけていること

OpenClawとClaude Codeをcronなどで無人実行させる構成に踏み込む場合、いくつか外せない安全策がある。

  • SNSや外部への自動投稿は、下書き生成までを自動化の範囲とし、公開は必ず人間が承認する
  • 有料API呼び出しは想定外の高頻度実行が起きないよう、実行間隔や呼び出し先を明示的に制限する
  • 常駐が必要なプロセスは、無音で停止することのある仕組みではなく、監視しやすい形で運用する
  • 破壊的な操作（force push、ハードリセット、テーブル削除など）は無人実行の対象から外し、人間の承認ゲートを必ず挟む

これらは「AIに全部任せる」の対極にある考え方で、思考・記憶・指示のレイヤーが判断を出しても、実行や公開の最終ゲートは人間側に残す、という設計を徹底している。無人運用の範囲を広げるほど、この「最後のゲートだけは人間」というルールの価値が上がっていく。

よくある失敗パターン

分業型の運用を組んでいてよく見かける失敗は、思考レイヤーと実行レイヤーの間で「前提」がずれることだ。OpenClaw側が古い情報をもとに指示を出し、Claude Code側がそれを鵜呑みにして実装してしまうケースがある。対策としては、実行レイヤー側で必ず現状のコードやログを確認してから着手させる、という一手間を挟むこと。記憶ファイルは便利だが、常に「今も正しいか」を検証する前提で扱うべきで、鵜呑みにする設計は事故のもとになる。

もう一つは、権限周りの事故だ。無人実行の範囲を広げすぎると、意図しないファイル削除やpushが起きるリスクが上がる。破壊的な操作は必ず人間の承認を挟む、というルールを最初に決めておくことが重要になる。また、記憶ファイルを増やしすぎて索引が追いつかなくなり、古い方針と新しい方針が両方参照されてしまう、というのもありがちな失敗だ。記憶は増やすだけでなく、定期的に棚卸しして矛盾するものを整理する運用も必要になる。

フリーランス・SESエンジニアにとっての意味

SES契約で常駐しながら「このままでいいのか」と感じているエンジニアは少なくない。SES つらい、SES やめたいと検索する人が一定数いる背景には、案件選択の裁量が小さいことや、単価が自分のスキルに見合っていないと感じる不満があると考えられる。

こうした状況を変える一歩として、自分の稼働実績や習得スキルをデータ分析的に可視化し、フリーランスとして単価交渉や案件選定の材料にする、という動きは選択肢の一つになる。今回紹介したような、思考・記憶を司るレイヤーと実行を司るレイヤーを分けて運用するノウハウは、SESの受託業務をこなしながら自分の環境やツールを整備していく上でも応用が利く。SESを続けるにしても、フリーランスに転向するにしても、AIを使った開発・運用の型を自分の手元に持っておくことは、どちらの選択にも効いてくる。

案件の合間に自分専用の記憶ファイルとClaude Code設定を育てておけば、次の現場に移ったときにもゼロから環境を作り直す必要がなくなる。これは、SESという働き方の中で唯一自分でコントロールできる資産と言ってもいい。

まとめ

OpenClawのような思考・記憶・指示のレイヤーと、Claude Codeのような開発・実行のレイヤーを分けて連携させることで、コンテキストの肥大化を防ぎながら、意思決定と実装の両方の質を保てる。ポイントは次の3つだ。

  1. 記憶はセッションではなくファイルに永続化し、Why（なぜそうするか）まで残す
  2. 実行レイヤーには常に最新の現状確認をさせ、記憶を鵜呑みにさせない
  3. 無人実行の範囲を広げるときほど、公開・破壊的操作のゲートは人間に残す

この型は個人開発だけでなく、SESや受託の実務をこなしながら自分のプロダクトを育てたいフリーランスエンジニアにとっても、実務で使える運用ノウハウになるはずだ。

関連記事

AI駆動塾 — AIを使ったスモビジの作り方を学ぶ

Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。

noteメンバーシップに参加する →

💼 フリーランスエンジニアの案件をお探しですか？

SES解体新書 フリーランスDBでは、高単価案件を多数掲載中です。

  • ✅ マージン率公開で透明な取引
  • ✅ AI/クラウド/Web系の厳選案件
  • ✅ 専任コーディネーターが単価交渉をサポート

▶ 無料でエンジニア登録する

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?