はじめに:なぜ「思考・記憶」と「実行」を分けるのか
2026年10月、Zennの日次トレンドを見ていると開発ツール周りの話題が目立つ。CodeRabbitやClaude Code向けのSkillとして公開された日本語の読みやすさを構造レベルで改善する「yomiyasu」、AI開発時代におけるテストの役割を再定義する議論、15年使ってきたGitからJujutsuに移行した体験談——どれも「AIにコードを書かせる時代に、人間はどこで品質と制御を握るか」という同じ問いに向き合っている。
筆者はSESで常駐しながら個人開発・自動化基盤の構築を続けているエンジニアだが、この半年でワークフローを大きく変えたのが「思考・記憶・指示を司るレイヤー(OpenClaw的な構成)」と「開発・実行を担うレイヤー(Claude Code)」を明確に分離する設計だった。この記事では、実際に使っているコマンドと設定ファイルの構成例を示しながら、このアーキテクチャがなぜ単価や年収に直結するスキルになり得るのかをデータ分析的な視点も交えて解説する。
アーキテクチャの全体像
| レイヤー | 役割 | 担当ツール | 永続化先 |
|---|---|---|---|
| 思考・記憶 | ユーザーの好み・過去の決定・プロジェクト文脈の保持 | OpenClaw(記憶/指示オーケストレーション) | memoryディレクトリ・MEMORY.md |
| 指示 | 恒久ルールの明文化 | CLAUDE.md | リポジトリ直下 |
| 開発・実行 | コード生成・テスト・デプロイ | Claude Code | git worktree / CI |
ポイントは「記憶は記憶レイヤーに置き、実行はコードと一緒に検証可能な形で残す」という分離だ。AIエージェントに何かを「覚えさせたい」と思ったとき、それをチャットのコンテキストに頼ると次回セッションで消える。そこでOpenClaw側に恒久的な指示・プロジェクトの背景・過去の失敗パターンを溜め込み、Claude Code側はその指示を読み込んで実際にコードを触る、という役割分担にしている。
実践例1: CLAUDE.mdによる恒久指示の注入
最初に手を付けたのは、プロジェクトルートにCLAUDE.mdを置き、Claude Codeが起動時に必ず読み込む恒久ルールを書くことだった。
## デプロイ鉄則
- 未コミットのWIPがある状態でビルドしない
- push前に必ず差分検証を行う
- 本番でない重い処理は research-run 経由で優先度を下げて実行する
こうした「過去にやらかした事故の再発防止ルール」を自然文で書いておくと、Claude Codeは毎回のタスクでそれを前提条件として扱う。これはOpenClaw的な「記憶」をコードベースに染み込ませる最も原始的で確実な方法で、チャットの文脈が切れても消えない。
実践例2: memory層でユーザー固有の文脈を持たせる
CLAUDE.mdは「プロジェクト全体の恒久ルール」向けだが、「このユーザーは何を好み、過去にどう修正されたか」という粒度の情報は別のmemoryファイル群で管理している。
memory/
feedback_testing_approach.md
feedback_commit_style.md
project_deploy_freeze.md
reference_ci_dashboard.md
MEMORY.md # 索引ファイル
例えば「モックではなく実データでテストする」という指摘を一度受けたら、それをfeedback_testing_approach.mdに以下のように残す。
---
name: feedback-testing-approach
description: 統合テストは実データで行う方針
metadata:
type: feedback
---
モックDBでの統合テストは禁止。
**Why:** モックとプロダクションの挙動差分がマイグレーション失敗を隠した実例がある。
**How to apply:** DBを跨ぐ統合テストを書く・直すときは常に実DB(またはテスト用の実環境)を使う。
ここで重要なのは、AI開発時代のテストの役割を論じたZennの記事が指摘していたのと同じ問題意識——「AIが書いたテストは通っても、それが本当に品質を保証しているか」という点だ。記憶層に「なぜそのルールが必要か」を書いておくことで、Claude Codeは単にルールを守るだけでなく、エッジケースでの判断材料として理由を参照できる。
実践例3: Skill化で再利用可能な手順に落とす
一度きりの指示で終わらせず、繰り返し使う作業はSkillとして切り出す。例えばコードレビューの手順をこう定義しておくと、/code-reviewのようなコマンド一発で、低負荷のレビューから複数エージェントによる徹底レビューまで切り替えられる。
# 直近差分を標準レビュー
claude -p "/code-review"
# PRを高エフォートで多角的に検証
claude -p "/code-review high --pr 123"
この「頻出タスクをSkillに固定化し、思考コストをゼロに近づける」という発想こそが、OpenClaw的なレイヤーがClaude Codeに渡す「指示の再利用資産」だ。毎回ゼロからプロンプトを書き直すエンジニアと、資産化されたSkill群を呼び出すだけのエンジニアでは、同じ時間で出せる成果物の量が変わってくる。
実践例4: 定期実行による自律的な保守(cron×Claude Code)
人間が気づかないうちに劣化する領域——依存パッケージの更新、CIの赤信号、ログの異常——をClaude Codeに定期的に見させる構成も組んでいる。
# 毎朝CIの失敗ログを確認し、直せるものは直す
claude -p "直近のCI失敗を調査し、原因が明確なら修正PRを作成して" \
--allowedTools "Bash,Edit,Read"
これをcronで回す際は「本番機の優先度を奪わない」ことが重要で、重い処理は専用のラッパー経由で優先度を下げて動かす設計にしている。無人実行時にコスト事故や誤爆が起きないよう、実行前チェックと差分検証を必ず挟むのは、記憶層に書かれた鉄則をそのままコード化した形だ。
実践例5: Jujutsu的な発想をgit worktreeで再現する
今日のトレンドでもう一つ目立ったのが「GitからJujutsuに移行した」という記事だ。Jujutsuの魅力はブランチを気にせずコミットを自由に組み替えられる点にあるが、Claude Codeでも似た体験はgit worktreeを使った並行開発で近似できる。
# 複数のエージェントタスクを別ワークツリーで並行実行
git worktree add ../repo-feature-a feature-a
git worktree add ../repo-feature-b feature-b
複数のClaude Codeエージェントが同じリポジトリの異なるブランチを同時に触っても、worktreeで物理的に分離しておけば衝突しない。これは「思考・記憶」側で「このタスクは並行実行して良い」という判断をし、「実行」側がworktreeという具体的な隔離機構で応える、という役割分担の一例だ。
なぜこれが単価・年収に直結するのか
ここからは少しビジネスの話をする(記事全体の比重としては小さくするが、SESで働くエンジニアにとって無視できない論点だ)。
SESの現場では、常駐先の業務範囲内でしかスキルを評価されないことが多い。一方で、記憶レイヤーと実行レイヤーを分離したAI駆動開発基盤を個人で構築・運用できるエンジニアは、以下の点で市場価値のデータ分析上も差別化要因になりやすい。
- 再現性のある生産性: Skill化・memory化された資産は、プロジェクトが変わっても持ち運べる。フリーランス案件の探し方を考えるとき、「この人は過去の成果を再現できる仕組みを持っている」ことは提案書やポートフォリオで説得力を持つ。
- 運用コストの説明力: cronやworktreeでの自律運用を自分の言葉で説明できると、クライアントに対して単価の根拠(どれだけの作業を自動化で肩代わりしているか)を具体的に示せる。
- 独立準備としての実験場: SESの業務では触れにくい「エージェント運用」「無人実行の安全策」「記憶の設計」を個人のリポジトリで実践しておくことが、エンジニア 独立 準備そのものになる。独立後に案件単価を交渉する際、これらの実装経験は「AI時代の開発体制を構築できる人材」という評価につながりやすい。
ただし、ここで言う年収・単価への影響は筆者個人の運用実感であり、業界全体の相場を保証するものではない。フリーランスや独立を検討する場合は、IPA(情報処理推進機構)の「DX白書」やフリーランス協会が毎年公開する実態調査など、公的機関・業界団体の調査データを必ず確認したうえで、自分のスキルセットと市場のマッチングを判断してほしい。
構築する上でのチェックリスト
実際にこの構成を組む際、最低限押さえておきたい項目を整理した。
- 恒久ルールはCLAUDE.md、ユーザー固有の文脈はmemoryファイルに分離したか
- memoryファイルには「何を」だけでなく「なぜ」を書いたか(Why/How to applyの形式)
- 繰り返す作業はSkillとして切り出し、索引(MEMORY.mdに相当するもの)を更新しているか
- 無人実行(cron)には優先度制御と差分検証のガードを入れたか
- 並行タスクはworktreeなどで物理的に隔離し、衝突を避けているか
- 統合テストやCIは「AIが書いたから通った」ではなく、実データ・実環境での検証になっているか
おわりに
OpenClaw的な記憶・指示レイヤーとClaude Codeの実行レイヤーを分離する発想は、特別なプロダクトを導入しなくても、CLAUDE.md・memoryディレクトリ・Skill・worktree・cronといった既存の仕組みの組み合わせで今日から再現できる。重要なのは「AIに何を覚えさせ、何を毎回のコンテキストから学ばせるか」を意識的に設計することだ。
SESで日々の業務に追われていると、こうした基盤構築の時間を取りにくいかもしれない。しかし、フリーランス案件の探し方や単価交渉を考える段階になったとき、「自分の開発体制をデータで説明できる」ことは、口頭の実績アピールよりも強い武器になる。まずは自分のリポジトリに一つのCLAUDE.mdを置くところから始めてみてほしい。
関連記事
- 【2026年最新】AIコーディングツール徹底比較|Claude Code・Copilot・Cursor・Windsurf・Codeiumの選び方
- 月商250万・社員3人がAI経営OS(CFO/COO/CMO)を自作した話
- OpenClawで9体のAIエージェント経営OSを構築した実践記録【2026年10月】
AI駆動塾 — AIを使ったスモビジの作り方を学ぶ
Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。
💼 フリーランスエンジニアの案件をお探しですか？
SES解体新書 フリーランスDBでは、高単価案件を多数掲載中です。
- ✅ マージン率公開で透明な取引
- ✅ AI/クラウド/Web系の厳選案件
- ✅ 専任コーディネーターが単価交渉をサポート