OpenClaw×Claude Code実践｜思考・記憶と実行を分離するハーネス設計術

Posted at 2026-10-19

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

Zennでは「改めて考える、AIエンジニアリングの今」というテーマが日次トレンド上位に入り、Qiitaでも直近2週間でAIタグ・Securityタグの記事がそれぞれストック20超の反応を集めている。AIエージェントに何をどこまで任せるか、その境界線をどう設計するかが、2026年10月時点のエンジニア界隈で改めて議論の中心になっている実感がある。

筆者はCLI経由で動くClaude Codeを「実行役」、その上に自分で構築した思考・記憶・指示のレイヤー（本記事では便宜上「OpenClaw」と呼んでいる個人のAI経営OS）を「判断役」として分離して運用している。これはOpenAIやAnthropicが提供する既製品ではなく、CLAUDE.md・memory/ディレクトリ・ポリシーファイル群を自前で積み上げた構成だ。今回はこの連携の具体的なユースケースと、実際に踏んだ地雷を含めて共有する。

「AIにコードを書かせる」記事は巷に溢れているが、「AIに何を覚えさせ、何を判断させ、何を実行だけさせるか」を設計した記事は意外と少ない。この記事はその設計メモだ。

OpenClawとClaude Codeの役割分担

筆者の構成はシンプルな三層になっている。

層	担当	中身
思考・記憶・指示（OpenClaw）	判断	`memory/`配下のuser/feedback/project/reference 4種のメモリ、`~/.claude/policies/`の方針ファイル
ハーネス（境界・門）	統制	`~/openclaw-gates/`、`check`コマンド、cronの安全鉄則
実行（Claude Code）	作業	コード生成・ファイル編集・コマンド実行・subagent呼び出し

重要なのは、実行役（Claude Code）には判断をさせすぎないという設計思想だ。本番DBや課金系API、外部送信の入口はそもそも作業役が到達できない構造にしておく。「柵（hookやlint）は漏れる前提」で、本当に効くのは構造的に手が届かないことだと割り切っている。

ユースケース1：自己改善ループとしてのメモリシステム

一番効果を実感しているのが、修正と確認を「メモリ」として型別に記録する仕組みだ。4種類に分けている。

user: ユーザーの役割・前提知識（例：Goは10年書いているがReactは初めて、など）
feedback: 「次からこうして」という指摘、または「その判断で合ってた」という確認。どちらも書く
project: 今動いている案件の背景（締切・制約・誰が何をいつまでに）
reference: 外部システムへのポインタ（Linearのプロジェクト名、Slackチャンネルなど）

実際に蓄積されているfeedbackメモリの例を挙げる。ポケモンカードのKaggleシミュレーション部門で4,549位/6,807チームという結果に終わった際の振り返りだ。

根拠: ポケカKaggle Simulation部門 4,549位/6,807チーム。
選別の仕組みは上位と同じ作りだったのに、候補を自前で作っていたので負けた。
上位は他チームの一流の実データ（上位チームの棋譜 9万〜69万判断）を教師にしていた。
当方は98判断。

これは単なる敗因分析では終わらず、「候補データは必ず外部の一流の実データから取る」という恒久ルールとしてCLAUDE.mdに昇格させた。以後、企画書やコンテンツ生成のどの案件でも、このルールが毎回の判断基準として効いてくる。失敗を一度記録すれば、次のセッションのAIが同じ轍を踏まない——これがメモリレイヤーの一番の価値だ。

ユースケース2：ハーネス設計で無人運用の事故を防ぐ

無人cron実行では、実行役に任せきりにすると事故が起きる。実際に起きたインシデントをベースに、5つの原則で指針を薄く保っている。

境界を先に引く：本番DB・課金・外部送信・秘密の値は作業役が到達できない構造にする
指針は薄く：1行=毎回の家賃。実際の失敗か規約に対応する行だけ残す
門は1コマンド：make check（lint→型→ビルド→テスト→verify_claims）を通過すること以外は「完了」と呼ばない
ループを閉じる：同じ手順を3回繰り返したらSkill化、同じ観点を3回確認したらサブエージェント化
棚卸しする：~/.claude/tools/harness_audit.shで工場ごとにgit状態・check通過・テスト・停止ファイル・送信入口・.env権限を定期点検

実際にharness_audit.shを叩くとこういう出力になる（イメージ）。

$ ~/.claude/tools/harness_audit.sh
[factory] content-automation
  git: clean
  check: PASS (lint/type/build/test/verify_claims)
  stop-file: none
  send-gate: 1 (post_approved_only.sh)
  .env perms: 600
[factory] trend-scraper
  git: 3 uncommitted files  <- 要確認
  check: FAIL (test)
  ...

「完了」の定義を自然言語の報告文ではなく、checkコマンドの通過と一次データの有無で判定する。これにより、Claude Codeが「できました」と言っても、それを鵜呑みにしない運用になっている。

ユースケース3：重い処理の隔離とコスト事故の防止

本番機で研究・学習系の重い処理を走らせると、本番cronを詰まらせる。実際に2026年9月29日23時14分、LeRobotの試験的な学習処理が固まって10時間CPU使用率約890%を使い続け、負荷27〜39の状態が続いて朝の定時処理が571回も負荷待ちになるという事故が起きた。

これを受けて、研究・実験系は必ず専用ラッパーを通すルールにした。

# 優先度最低(taskpolicy -b + nice 19)・並列数既定2・実行時間既定2時間で実行
~/bin/research-run -t 3600 -j 2 -- python train_experiment.py

タイムアウト・並列数・優先度をラッパー側で強制することで、「とりあえず実行してみる」がそのまま本番を巻き込む事故を防いでいる。実行ログは~/tasks/research-run.logに残るため、後から「いつ何を何分走らせたか」を棚卸しできる。

同様にコスト事故の教訓として、Vercelでは誰も使っていない試作サイトがAIクローラーに1日250万回叩かれて約120万円請求された事例があり、以後Vercelの新規利用を禁止しデプロイ先をCloudflare Pages/Workersに統一した。Supabaseも「移管した」は課金停止の証明にならず、プロジェクト削除と請求明細の行が消えたことを完了の定義にしている（過去に11プロジェクトが残り続け約2万円の無駄な請求が発生した経験から）。

SNS投稿の自動化でも、同一アカウントへの15分15件連投でMetaのshadow banを受けた実例（2026年4月30日）があり、以後「同一アカウントへの連投は最低15分間隔」をハーネス側の強制ルールにしている。

得られた結果：報告文ではなくログで判断する

この構成を通して得られた一番の気づきは、「AIエージェントの報告は信用しない、ログと一次データで判断する」という原則がそのまま運用コストの削減につながるということだ。

実行ログ（research-run.log）があるから「いつ何が暴走したか」を後から追える
門（checkコマンド）があるから「完了しました」を鵜呑みにせずに済む
メモリ（feedback型）があるから同じ失敗を二度繰り返さない
棚卸しスクリプトがあるから「柵が破れていないか」を定期確認できる

どれも単体では地味な仕組みだが、組み合わせることで「無人で回しても大きくは外れない」状態に近づく。逆に言えば、これらの仕組みを入れる前は、Vercel課金事故・Meta shadow ban・LeRobotの固まりなど、実際に損失を伴うインシデントが起きていた。ハーネス設計は精神論ではなく、実際に起きた事故の再発防止策の積み重ねだ。

フリーランスエンジニア・SESエンジニアへの示唆

ここまでの話は社内のAI活用基盤の話だが、フリーランスエンジニアとして複数案件を掛け持ちする人にも応用できる考え方がある。

SESエンジニアの実態として、常駐先ごとに使えるツールやルールが異なり、属人的な判断に頼りがちになるケースは多い。SES契約の注意点としてよく挙がるのが、成果物の責任範囲や指揮命令系統の曖昧さだが、これは「誰が判断し、誰が実行するか」を明文化していないことに起因する場合が多い。自分の作業ルールを「指針（方針）」と「実行ログ」に分けて記録しておくだけでも、契約上のトラブルや認識齟齬を減らせる。

フリーランスエンジニアガイドとしてよく紹介される内容は契約形態や単価交渉が中心だが、実務面では「自分の判断基準をどう外部化し、再利用可能にするか」も地味に重要な論点だ。フリーランスガイド全般に共通するのは、属人的な勘に頼らず、過去の失敗と成功をメモとして残し、次の案件に引き継ぐという発想であり、これはAIエージェントのメモリ設計とまったく同じ構造をしている。

フリーランスエンジニアとして複数のクライアントワークをこなす場合も、案件ごとの制約（project型）、クライアントからの指摘（feedback型）、クライアントの背景知識（user型）を分けて記録しておくと、次回の提案や見積もりの精度が上がる。AIエージェント運用のために作った型が、そのまま自分自身のナレッジマネジメントにも転用できるというのは、この構成を作ってみて得られた副産物だった。

保存版チェックリスト：AIエージェント運用を始める前に確認すること

チェック項目	確認内容	未対応時のリスク
送信・公開の入口は1本か	複数経路から外部送信できないか	無承認投稿・誤送信
本番DB/課金APIに作業役が直接到達できないか	環境変数・権限の分離	誤操作による本番破壊・想定外課金
「完了」の定義がコマンド通過か報告文か	`make check`等の有無	未検証の「できました」を信用してしまう
重い処理の隔離ラッパーがあるか	タイムアウト・並列数・優先度の強制	本番cronの詰まり・負荷事故
連続実行の間隔制限があるか	SNS投稿・API呼び出し等	shadow ban・アカウント凍結
失敗・成功をメモリ化する仕組みがあるか	feedback/project/user/reference等の型	同じ失敗の繰り返し
定期棚卸しスクリプトがあるか	git状態・check結果・停止ファイル・権限	柵の形骸化に気づけない

この表はそのまま自分の運用環境のセルフチェックに流用できる構成にしてある。上から順に埋まっていない項目があれば、そこが次に手を入れるべき場所だ。

まとめ

OpenClaw（思考・記憶・指示）とClaude Code（実行）の連携は、「AIに何でも任せる」ことではなく、「何を任せて何を任せないか」を明文化する作業だった。実際に起きたコスト事故・停止事故を教訓に、境界・薄い指針・1コマンドの門・閉じたループという4つの原則に落とし込んだことで、無人運用でも大きく外れない状態に近づいている。

この考え方は、AIエージェント運用に限らず、フリーランスエンジニアやSESエンジニアが自分の仕事の進め方を仕組み化する際にもそのまま使える。判断の記録を残し、完了の定義を明確にし、危険な操作の入口を絞る——地味だが、事故を防ぐのはいつもこの手の仕組みだ。

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

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

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

書いた人: 合同会社Radineer（フリーランス向け案件サイト FreelanceDB を運営）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up