はじめに：なぜ「思考」と「実行」を分離するのか
2026年9月現在、Qiitaでは「生成AI」「AI」「ClaudeCode」タグの記事が直近2週間でストック20超えの記事を多数出している状況が続いている。個人開発者やSESエンジニアの間でも、Claude Codeを使った自動化・効率化の実践知が急速に共有されている。
一方で、Claude Codeだけを単体で使っていると、あるプロジェクトで学んだ教訓が別のプロジェクトに引き継がれない、日々のタスクや経営判断のコンテキストがセッションをまたいで消えてしまう、という課題にぶつかる。
この記事では、「OpenClaw」という思考・記憶・指示のレイヤーと、「Claude Code」という開発・実行のレイヤーを組み合わせた実践的な連携パターンを、具体的なコマンドと設定例つきで紹介する。SESエンジニアからフリーランスへの転向を考えている人にとっても、単価アップの武器になる開発フローとして参考にしてほしい。
OpenClawとClaude Codeの役割分担
前提として、この2つのレイヤーの役割を明確に分けておく。
| レイヤー | 役割 | 具体例 |
|---|---|---|
| OpenClaw（思考/記憶/指示） | 意思決定・記憶の永続化・タスクの司令塔 | CEO/CFO/CTO/COOエージェント、秘書エージェント、ナレッジDB |
| Claude Code（開発/実行） | コード生成・ファイル操作・テスト・デプロイ | Edit/Bash/Workflowツール、CI連携、実装そのもの |
OpenClaw側は「何をすべきか」「過去に何を学んだか」を蓄積する層で、Claude Code側は「実際に手を動かす」層、という切り分けだ。この分離をしないと、日々の実装ログと経営判断・過去の失敗パターンが同じコンテキストの中でごちゃまぜになり、どちらの精度も落ちる。
ユースケース1：秘書エージェントでinbox/todoを一元管理する
OpenClaw側には「秘書」ロールのエージェントを置き、YAMLベースでinbox/today/archiveを管理させる。Claude Codeから見ると単なる「ファイルを読み書きするサブエージェント」だが、OpenClaw側では継続的にタスクの優先度や期限を追跡している。
実際のコマンド例（スラッシュコマンド形式）：
/cc-secretary list # inboxの未処理タスクを一覧表示
/coo tasks # タスク進捗をCOOエージェントが横断集計
/cto priority # 技術的優先度をCTOエージェントが提案
これらは内部的にYAMLファイルの読み書きとサブエージェントへの委譲で構成されている。Claude Code側の開発タスク（バグ修正・機能追加）が完了すると、その報告がOpenClaw側のタスク管理に反映され、次回のダッシュボード生成時に「完了」としてカウントされる、という一方向の流れになる。
ユースケース2：CEO/CFO/CTO/COO/CMOダッシュボードで経営判断を支援する
複数のプロダクトを運用している場合、各領域の状況をエージェント単位で分離しておくと、コンテキストが汚染されない。
/ceo ダッシュボード # 各C×Oの報告を統合した経営ダッシュボード
/cfo 未決済 # freee連携で未決済の請求書を抽出
/cto health # 複数プロダクトのヘルスチェックを実行
ポイントは、これらのエージェントがそれぞれ独立したメモリ（教訓・KPI・進捗）を持っていて、Claude Codeの実装セッションとは別のライフサイクルで動いている点だ。実装は「今この瞬間」のタスクだが、経営判断は「積み上げてきた文脈」が必要になるため、あえて分離している。
ユースケース3：Claude Codeでの実装結果をOpenClawの記憶に書き込む
Claude Code側で非自明な修正やユーザーからの指摘があった場合、それをその場で捨てずにOpenClaw側の永続メモリに書き込む運用にしている。具体的には、以下のようなMarkdownファイルをmemoryディレクトリに追加する。
---
name: deploy-clean-worktree
description: 無人cronデプロイは未コミットWIPを避け、クリーンなworktreeからビルドする
metadata:
type: feedback
---
未コミットのWIPを含んだ状態でcronデプロイを実行すると、
意図しない差分が本番に反映される事故が過去にあった。
Why: 無人運用では人間のレビューが入らないため、
git statusでの事前チェックが唯一のセーフティネットになる。
How to apply: cron経由のデプロイタスクでは、必ずgit statusを確認し、
未コミット差分がある場合は処理を停止してアラートを出す。
このメモリは次回以降のセッションで自動的に読み込まれるため、「同じ失敗を二度繰り返さない」仕組みがClaude Code単体よりも強くなる。メモリディレクトリの構成は以下のようにシンプルなツリーで管理できる。
memory/
├── MEMORY.md # 全メモリのインデックス（1行要約）
├── feedback_deploy.md # デプロイ運用に関する教訓
├── project_client_a.md # 進行中プロジェクトの文脈
└── reference_dashboards.md # 外部ダッシュボードへの参照
具体的な設定例：CLAUDE.mdとhooks
OpenClaw的な運用をClaude Code単体でも部分的に再現するなら、CLAUDE.mdとhooksの組み合わせが最も手軽だ。
# CLAUDE.md（プロジェクトルート）
## デプロイ前チェック
- 未コミットWIPがある場合は必ず`git status`で確認してから実行する
- cronデプロイはbunxではなくローカルピン留めのwranglerを使う
## SNS投稿ルール
- 同一アカウントへの投稿間隔は15分以上空ける
- 公開前に必ず人間の承認を得る
さらにsettings.json側でBashコマンドの事前チェックをhookとして仕込んでおくと、Claude Codeが危険な操作（force push、rm -rfなど）を実行する前に確認プロンプトを強制できる。これはOpenClawの「経営判断レイヤー」をClaude Code内に縮小移植したものと考えるとわかりやすい。
Workflowツールで多エージェント並列レビューを回す
規模の大きいレビューやリファクタリングでは、Claude CodeのWorkflow機能を使って複数の観点（正確性・パフォーマンス・セキュリティ）を並列に走らせ、最後に統合する構成が有効だ。
export const meta = {
name: 'review-changes',
description: '変更差分を複数観点でレビューし、指摘を検証する',
phases: [{ title: 'Review' }, { title: 'Verify' }],
}
const DIMENSIONS = [
{ key: 'bugs', prompt: '差分の中の論理バグを指摘して' },
{ key: 'perf', prompt: '差分の中のパフォーマンス劣化を指摘して' },
]
const results = await pipeline(
DIMENSIONS,
d => agent(d.prompt, { label: 'review:' + d.key, phase: 'Review' }),
review => agent('この指摘は本当に正しいか検証して: ' + review, { phase: 'Verify' })
)
これをOpenClaw側の「複数視点レビュー」的な位置づけで運用すると、実装の意思決定にも複数視点のチェックが入るようになる。
保存版チェックリスト：OpenClaw×Claude Code導入前に確認すべき7項目
あとで見返せるように、導入判断の前にチェックすべき項目を表にまとめた。ブックマークや保存推奨。
| # | チェック項目 | 確認方法 |
|---|---|---|
| 1 | 記憶レイヤーとタスク実行レイヤーを分離できているか | OpenClaw側メモリとClaude Code側CLAUDE.mdの役割が重複していないか確認 |
| 2 | 無人実行時の安全鉄則が明文化されているか | cron/agent実行時の禁止事項リストがCLAUDE.mdにあるか |
| 3 | SNS投稿など外部影響のある操作に人間承認が入っているか | 自動公開フローの有無をコードで確認 |
| 4 | 過去の失敗がfeedback memoryとして蓄積されているか | memoryディレクトリのfeedback系ファイル数を確認 |
| 5 | デプロイ前にクリーンなworktreeであることを検証しているか | git status / デプロイ検証エージェントの有無 |
| 6 | 経営判断（優先度・予算）と実装タスクが別ライフサイクルか | ダッシュボード生成とコード実装のタイミング分離 |
| 7 | 複数観点の並列レビューが差分の大きさに応じて使われているか | Workflowツールの利用条件を確認 |
この7項目は「導入前チェックリスト」としてそのまま使えるので、社内ドキュメントやNotionに転記して運用開始前に一つずつ潰していくのがおすすめだ。
得られた結果（構造として期待できる効果）
実測PVや工数削減率などの断定的な数字はまだ十分な運用実績が蓄積されていないため、ここでは構造的に期待できる効果に絞って述べる。
- タスクの優先度判断（OpenClaw）と実装の速度（Claude Code）が分離されるため、片方の変更が他方の精度を下げにくい
- feedback memoryの蓄積により、同種の指摘をエージェントが繰り返す頻度が下がる
- cron/hooksによる無人実行の安全ルールが明文化されることで、事故発生時の原因追跡がしやすくなる
なお「稼働中」と表現できるのは実際に1〜2週間以上の運用実績が積まれてからであり、導入直後の段階では「実装完了」に留まる点は誠実に区別しておきたい。
SESエンジニアがこの開発フローをフリーランス転向の武器にする
ここまで紹介したOpenClaw×Claude Codeの連携パターンは、個人や小規模チームでも構築できる規模のものだ。SESとして常駐先の指示のもとで開発するだけでなく、こうした自動化・エージェント運用の設計経験そのものが、SESからフリーランスへ転向する際の技術的な差別化ポイントになりやすい。
フリーランス案件の探し方としては、エージェント経由の案件紹介だけでなく、こうした開発フローの構築事例を発信すること自体が問い合わせのきっかけになるケースもある。単価交渉の場面では「保守・運用の自動化設計ができる」という実績は、単純な実装工数だけでは測れない付加価値として評価されやすい。
もちろんフリーランスの単価は言語・領域・稼働形態によって差が大きいため、断定的な相場を示すことは避けるが、AIエージェントの運用設計スキルは今後も需要が伸びる領域として注目しておく価値がある。SES企業に属しながらでも、業務の合間にこうした個人プロジェクトでOpenClaw的な仕組みを構築しておくことは、転向のタイミングを見据えた実績づくりとして機能する。
まとめ
OpenClawを「思考・記憶・指示」の司令塔として、Claude Codeを「開発・実行」のエンジンとして役割分担することで、単発のAIコーディングツールにはない継続性が生まれる。
- OpenClaw：タスク優先度・経営判断・過去の教訓を蓄積する層
- Claude Code：実際のコード変更・テスト・デプロイを行う層
- 両者をつなぐのはメモリファイルとCLAUDE.mdルール、そしてhooks/cronによる無人実行の安全設計
この記事のチェックリストを起点に、まずは自分のプロジェクトでCLAUDE.mdとメモリディレクトリの分離から試してみてほしい。
関連記事
- OpenClawで9体のAIエージェント経営OSを構築した実践記録
- Claude Codeを1年使い倒して分かった、年収を上げる実践Tips9選
- 【2026年最新】AIコーディングツール徹底比較｜Claude Code・Copilot・Cursor・WindsurfをTier別に解説
AI駆動塾 — AIを使ったスモビジの作り方を学ぶ
Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。
💼 フリーランスエンジニアの案件をお探しですか？
SES解体新書 フリーランスDBでは、高単価案件を多数掲載中です。
- ✅ マージン率公開で透明な取引
- ✅ AI/クラウド/Web系の厳選案件
- ✅ 専任コーディネーターが単価交渉をサポート