はじめに:なぜ「思考層」と「実行層」を分けるのか

2026年9月現在、Qiitaでは直近14日間で「AI」タグ付きのストック20超え記事が8本、「ClaudeCode」タグ付きの記事も5本公開されており、AIコーディングエージェントの実務活用がエンジニアの日常的な関心事になっていることがうかがえます。一方でZennの日次トレンドでは「既存のLLMがCPUなら、その先を行く新しいアーキテクチャはGPU版のようなもの」という比喩が話題になるなど、単体のLLM呼び出しから一歩進んだ「役割分担型のAI運用」への関心が高まっています。

筆者は日々の業務自動化に、記憶・意思決定を担う「OpenClaw」的な構成(メモリ層+指示層)と、実際にコードを書いて実行する「Claude Code」を組み合わせて運用しています。本記事では、この2層構成を実務でどう組んでいるか、具体的なコマンドと設定例を交えて共有します。なお本記事で紹介する運用は開始から日が浅く、定量的な成果指標はまだ蓄積段階です。「動いている」ことと「安定して成果が出ている」ことは別物なので、その前提で読んでください。

OpenClawとClaude Codeの役割分担

2層構成の基本思想はシンプルです。「何をすべきか判断し、記憶する層」と「実際に手を動かして実行する層」を分離することで、それぞれの層をシンプルに保てます。

層	役割	主な保存形式	典型的なタスク
OpenClaw(思考/記憶/指示)	状況判断、優先度付け、履歴管理	YAML/JSONLのメモリファイル、inboxキュー	「今日やるべきこと」の決定、過去の教訓の参照
Claude Code(開発/実行)	コード変更、テスト実行、PR作成	Gitリポジトリ、CLAUDE.md、settings.json	ヘッドレスモードでのバグ修正、ビルド検証

ポイントは、OpenClaw側が「判断結果」をファイル(メモリ)として永続化し、Claude Code側はそのファイルを読み取って実行に専念する、という一方向の依存関係にすることです。これにより、判断ロジックを変更してもコード実行部分に影響が出にくくなります。

実践例1: 日次ヘルスチェック→自動修正パイプライン

複数プロダクトを運用していると、ビルド失敗や依存関係の欠落に気づくのが遅れがちです。そこでcronで日次ヘルスチェックを回し、異常を検知したらメモリに記録、Claude Codeに修正を依頼する、という流れを組んでいます。

#!/bin/bash
# 1. 日次ヘルスチェック(OpenClaw側の「思考」ロジック)
for repo in product-a product-b product-c; do
  cd ~/products/$repo
  if ! npm run build --silent; then
    echo "{\"date\":\"$(date +%F)\",\"repo\":\"$repo\",\"issue\":\"build_failed\"}" \
      >> ~/openclaw/memory/incidents.jsonl
  fi
done

異常が記録されたら、Claude CodeをヘッドレスモードでCLI起動し、修正を依頼します。

# 2. Claude Codeに実行を委譲(--output-format json で結果を構造化して回収)
claude -p "~/openclaw/memory/incidents.jsonl の本日分エントリを読み、
該当リポジトリのビルド失敗原因を特定し、修正コミットを作成してください。
修正内容は日本語で要約してください。" \
  --output-format json \
  --allowedTools "Bash,Edit,Read,Grep" \
  > ~/openclaw/logs/claude_run_$(date +%F).json

最後に、実行結果をOpenClaw側のinbox(人間が確認するキュー)に戻します。

# 3. 結果をOpenClawのinboxに反映
jq '{date, repo: .result.repo, summary: .result.summary}' \
  ~/openclaw/logs/claude_run_$(date +%F).json \
  >> ~/openclaw/inbox/today.yaml

この構成のポイントは、Claude Code側のプロジェクトルートに置くCLAUDE.mdに「無人実行時の安全ルール」を明文化していることです。例えば以下のような記述です。

## 無人実行時の制約
- git push --force や git reset --hard は使用禁止
- テストが通らない変更はコミットしない
- 未知のnpmパッケージを新規インストールする場合は必ずコメントで理由を残す

こうしたルールをCLAUDE.mdに書いておくと、cron経由の無人実行でも一定の安全境界を保てます。

実践例2: メモリ駆動の継続的な改善ループ

もう一つの実践例が、過去の失敗や指摘事項を「教訓」としてメモリに蓄積し、次回の指示に反映するループです。ユーザーからの修正指摘があった場合、単にその場で直すだけでなく、memory/lessons.mdのようなファイルにパターンを書き残しておくと、Claude Codeが次回以降同じ間違いを繰り返しにくくなります。

# memory/lessons.md 抜粋
- 2026-09-15: DBアクセスをモックしたテストで本番障害を見逃した。
  以降、結合テストは実DBに対して実行すること。
- 2026-09-18: 未コミットの変更がある状態でデプロイスクリプトを実行し、
  意図しない差分が混入した。デプロイ前に git status を必ず確認する。

このファイルをClaude Code起動時のコンテキストに含めることで、「同じ注意を毎回口頭で繰り返す」手間を減らせます。CLAUDE.mdから@memory/lessons.mdのようにインポートしておくのも有効です。

実際に使うコマンド・設定集

用途	コマンド/設定例
ヘッドレス実行	`claude -p "<指示>" --output-format json`
使えるツールを制限	`claude -p "..." --allowedTools "Bash,Edit"`
プロジェクト固有ルール	`CLAUDE.md` にルールを記述
自動化フックの登録	`.claude/settings.json` に `hooks` を追加
外部ツール連携	`claude mcp add <server>`
よく使う指示のテンプレ化	`.claude/commands/*.md` にスラッシュコマンドを定義

これらは全てClaude Codeの公式CLIオプション・設定ファイルの仕組みであり、OpenClaw側は「いつ、何を指示するか」を決めるオーケストレーション層として、この上に乗る形になります。

つまずいたポイントと教訓

無人実行(cron/agent)を組む上で実際に踏んだ落とし穴を共有します。

タイムアウトの挙動差: macOS標準にはtimeoutコマンドがなく、gtimeout(coreutils)を使う必要があります。これに気づかず長時間ハングするジョブを放置してしまうケースがありました。
エラーの握りつぶし: 2>/dev/nullでエラー出力を捨てると、無人実行時に失敗に気づけません。ログは必ず残し、失敗時は明示的にinboxへ通知する設計にすべきです。
未コミットWIPからのデプロイ: クリーンなコミット/worktreeからビルドしないと、意図しない差分がデプロイされるリスクがあります。デプロイ前にgit statusと差分の確認を必須ステップにしています。
常駐プロセスの管理: launchdは無音で停止することがあるため、認証まわりの常駐プロセスはPM2など状態が見える仕組みで管理する方が安全です。

これらは特別な話ではなく、無人実行を前提にした自動化を組む際に共通して発生しやすい問題です。

データで見るフリーランスエンジニアの市場

ここでSESやフリーランスの話に触れておきます。経済産業省が2019年に公表した「IT人材需給に関する調査」(みずほ情報総研への委託調査)では、IT人材の需給ギャップが2030年に最大で約79万人に達すると試算されています。特にAIやビッグデータなど第4次産業革命関連の「先端IT人材」については、2030年時点で約12.4万人が不足すると見込まれており、AI活用スキルを持つエンジニアへの需要は構造的に高まる方向にあります。

こうした市場環境の変化は、フリーランスエンジニアの年収にも影響します。単価は経験年数や技術スタックだけでなく、「AIツールを使って一人でどれだけの範囲をカバーできるか」という生産性の要素で評価されるようになりつつあります。データ分析やAI駆動の自動化を扱えるかどうかは、今後の単価交渉における差別化要因の一つになりそうです。ただし具体的な単価水準は各フリーランスエージェントの案件条件によって大きく異なるため、実際の年収レンジは自分が登録するエージェント経由で確認するのが確実です。

フリーランスエンジニアガイド:スキル別・レベル別ロードマップ

AI活用エンジニアとして独立を目指す場合、段階を踏んだ習得が現実的です。以下は一般的な学習ステップの整理です。

初級(SES/受託の傍らで習得)

Claude Codeなどのコーディングエージェントを個人プロジェクトで日常的に使い、CLAUDE.mdの書き方に慣れる
Gitの基本操作とコードレビューの勘所を押さえる
簡単なデータ分析(SQL、pandas程度)ができるようにする

中級(案件で実践投入)

無人実行やcronでの自動化を小規模に構築し、失敗時のロールバック設計まで含めて経験する
複数リポジトリ・複数プロダクトを横断する運用フローを設計できるようにする
顧客向けにAI活用の提案ができるレベルまで引き上げる

独立準備(フリーランス転向前)

自分の得意領域(例:AI自動化基盤、データ基盤、フロントエンド)を明確化する
実績を第三者が確認できる形(GitHub、記事、登壇など)で可視化する
複数のフリーランスエージェントに登録し、単価感を比較検討する

この順序はあくまで一般的な目安であり、個人の状況によって前後します。重要なのは、SESや受託の中でも「AIエージェントを使った自動化」を実務で試せる余地がないか、日々の業務の中で探しておくことです。

SESをやめたいと感じたときに考えたいこと

「SESやめたい」という悩みを持つエンジニアは少なくありませんが、辞めること自体を目的にすると、転職後・独立後に同じ不満を繰り返すリスクがあります。まず整理すべきは、不満の原因が「客先常駐という契約形態」にあるのか、「技術的に成長を感じられない環境」にあるのか、「単価と裁量のバランス」にあるのかという切り分けです。

AI活用スキルは、この切り分けのどのケースにも効きます。技術的な停滞感が原因なら、業務時間外でClaude Codeのような開発エージェントを使ったツール開発を試すことで、次の職場や案件で語れる実績を作れます。単価に不満があるなら、前述の通り先端IT人材の需給ギャップを踏まえて、AI活用を軸にしたポジショニングでフリーランス市場に出る選択肢も検討に値します。いずれにせよ、勢いだけで退職や独立を決めるのではなく、データと実績の両方を積み上げてから動く方が、結果的に選択肢が広がります。

まとめ

OpenClaw的な「思考/記憶/指示」の層とClaude Codeの「開発/実行」の層を分離する構成は、無人実行を安全に回すための実務的な選択肢です。ポイントは以下の3つに集約されます。

判断結果はファイル(メモリ)として永続化し、実行層はそれを読むだけにする
CLAUDE.mdや設定ファイルに「無人実行時の安全ルール」を明文化する
失敗や指摘は都度メモリに教訓として残し、同じ間違いを繰り返さない仕組みにする

こうした地道な設計の積み重ねが、AIエージェントを使った自動化を「一時的に動くデモ」から「日々使える実務ツール」に引き上げる鍵になると感じています。

関連記事

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

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

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

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

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

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

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