はじめに：なぜ「記憶」と「実行」を分けるのか
Zennの日次トレンドを見ていたら、「俺のAIプログラミング手法(2026/10/05)」がいいね換算823という数字で上位に来ていた。AI駆動開発のやり方そのものが、個々のTips記事を超えてコンテンツとして成立する段階に来ているということだと思う。
一方でQiitaでは直近14日で「Security」タグのストック20超の記事が5本、「AIエージェント」タグも4本という状況で、「AIエージェントにAPIキーを渡しても大丈夫か」「.envの流出事例1,566件を経路で分類する」といった記事が目立つ。AIエージェントを業務に組み込む人が増えた分、事故の記事も増えているという構図だ。
この2つのトレンドは実は同じ根っこを持っている。AIに「何をしてよいか／してはいけないか」を覚えさせる層（記憶・判断）と、実際に手を動かす層（実行）を分けていないと、便利さと事故リスクが比例してしまうということだ。
今回はSESエンジニアや個人開発者が実務で使える形で、思考・記憶・指示を担うOpenClawと、開発・実行を担うClaude Codeを連携させた実践例を、実際のコマンドと構成を交えて共有する。
OpenClawとClaude Codeの役割分担
まず前提として、2つのツールの役割をはっきり分けておく。
| 層 | 担当ツール | 役割 | 具体的な中身 |
|---|---|---|---|
| 記憶・判断 | OpenClaw | 過去の失敗・成功パターンの蓄積、ルールの一元管理 | CLAUDE.md、memoryディレクトリ、lessons.md |
| 指示 | OpenClaw | タスクの優先度付け、何をClaude Codeに渡すかの選別 | タスクキュー、cron設定、承認フロー |
| 実行 | Claude Code | コード生成、ファイル編集、コマンド実行、テスト | Bash/Edit/Agentツール群 |
| 検証 | Claude Code | 差分確認、テスト実行、セキュリティレビュー |
/code-review、/security-reviewスキル |
ポイントは「実行する側（Claude Code）に毎回ルールを説明し直さない」ことだ。OpenClaw側にCLAUDE.md形式やmemoryファイルとしてルールを蓄積しておき、Claude Codeを起動した瞬間にそれが自動で読み込まれる状態を作る。これで「前回も同じ注意をしたのに、また同じミスをした」が構造的に起きなくなる。
実践例1：記憶層が実行の暴走を止める
実際に運用している中で効果が大きかったのは、事故が起きたらすぐにルール化してOpenClaw側の記憶に書き込むという運用だ。例えば以下のようなルールをCLAUDE.mdに持たせておく（内容は一般化した形で示す）。
## 無人運用 安全鉄則
- 同一SNSアカウントへの連投は最低15分間隔を強制する
(短時間の連投でプラットフォーム側のシャドウバン判定を受けた経験から)
- クラウドの新規課金リソースはデフォルトOFFで作成する
(従量課金の設定ミスで想定外の請求が発生した経験から)
- 「実装完了」と「稼働中」を書き分ける。1-2週間の運用実績が出るまで
「稼働中」と表現しない
これをClaude Codeが起動時に読み込む仕組みにしておくと、無人のcronジョブからタスクを投げても、Claude Code側が「このSNS投稿は直前の投稿から15分経っていないので止める」といった判断を自分でするようになる。重要なのは、この判断ロジックを毎回プロンプトで書かないことだ。記憶層に一度書けば、以降のすべての実行に効く。
実践例2：無人cron実行とOpenClawの承認ゲート
定期実行（cron）でClaude Codeにタスクを投げる構成では、「生成はさせるが、公開は人間が承認する」というゲートをOpenClaw側の指示層に持たせるのが効果的だった。実際のコマンドイメージはこうなる。
# cronから呼ばれるラッパースクリプト例
claude -p "今日のトレンドを元に記事案を1本作成し、\
data/drafts/ に保存すること。公開(publish)は行わない。\
公開可否は人間が別途判断する。" \
--allowedTools "Read,Write,Bash(git:*)"
この --allowedTools の絞り込みが地味に重要で、「生成・保存はできるが、公開APIを叩くツールは許可しない」という制約をコマンドレベルで二重にかけている。OpenClaw側のルール（指示層）とClaude Code起動時の権限設定（実行層の制約）を両方使うことで、「ルールを書いたつもりだったのに実行できてしまった」という事故を防げる。
研究目的の重い処理（データ生成・ベンチマークなど）を本番環境と共存させる場合も同様に、実行層側の仕組みで縛る。
# 本番プロセスと競合させないための優先度制御
~/bin/research-run -t 7200 -j 2 -- python train_eval.py
これは「研究用の重い処理は優先度最低・並列数は既定2・実行時間は既定2時間で動かす」というルールを、記憶（ドキュメント）だけでなく実行可能なラッパーコマンドとして持たせている例だ。ドキュメントに書くだけでは守られない。ルールは最終的にコマンドか設定ファイルに落とし込む、というのがここでの学びだった。
実践例3：セキュリティレビューとの連携（Qiita「Security」トレンド）
Qiitaで「APIキーをAIエージェントに渡しても大丈夫か」という記事がストックを集めているのは、実務でAIエージェントを使う人が増えた裏返しだと思う。Claude Codeには /security-review というスキルがあり、変更差分に対してペンディングの変更を自動でレビューできる。
# 現在のブランチの差分をセキュリティ観点でレビュー
/security-review
これをOpenClaw側のタスクフローに組み込む場合、「コードをコミットする前に必ずセキュリティレビューを通す」というルールを記憶層に持たせておき、Claude Code側でコミット前フックとして実行させる形にしている。APIキーの渡し方についても、.env や環境変数経由ではなく、OS側のキーチェーンやシークレットマネージャ経由で渡す運用にして、対話文に直接貼らないというルールを明文化している。
保存版チェックリスト：OpenClaw×Claude Code導入前に確認する10項目
実際に構成を組む前に、以下の項目は最低限確認しておきたい。チェックリストとして保存しておくと、新しいエージェント構成を作るたびに使い回せる。
| # | 確認項目 | 確認できていない場合のリスク |
|---|---|---|
| 1 | ルールはCLAUDE.md等の記憶層に永続化されているか | プロンプトでしか伝えておらず、毎回同じ事故が再発する |
| 2 | 実行層の権限（allowedTools等）は最小限に絞っているか | 想定外のAPI呼び出し・課金・公開が起きる |
| 3 | SNS/外部公開系のアクションは人間承認ゲートを挟んでいるか | 自動公開による炎上・規約違反のリスク |
| 4 | クラウドリソースの新規作成はデフォルトOFF設定か | 従量課金の見落としによる請求事故 |
| 5 | 無人実行の優先度・並列数・実行時間に上限があるか | 本番プロセスと競合してサービス全体が遅延する |
| 6 | APIキー・シークレットの受け渡し経路は安全か | エージェント経由での漏洩リスク |
| 7 | 「実装完了」と「稼働中」の表現を区別しているか | 未検証の機能を既成事実として扱ってしまう |
| 8 | コミット前にセキュリティレビューを通す導線があるか | 脆弱なコードがそのままマージされる |
| 9 | 事故が起きたら即ルール化して記憶層に書き込む運用があるか | 同じ失敗を繰り返すループから抜けられない |
| 10 | 数値や実績を主張する前に実データを確認する運用があるか | ピーク値を再現可能な実力と誤認してしまう |
この10項目は、思いつきで作ったものではなく、実際に事故が起きた後に記憶層へルールとして書き込んだものを一般化している。AIエージェント運用で一番コストが高いのは「同じ事故を2回起こすこと」なので、1回目の事故は仕組み化のための投資と捉えるのが現実的だ。
SESエンジニアがこの連携を学ぶ意味
ここまでは開発ツールの話だが、SESエンジニアとして働く人にとっても無関係ではない。SES（System Engineering Service）は客先常駐が中心のため、現場で使えるツールやクラウド環境に制約があることが多く、個人のPCや契約外の環境でAI開発ツールを自由に試せないケースが実際にある。
フリーランスとして独立すると、この制約がなくなる代わりに、環境構築からセキュリティ管理まで全部自分で判断する必要が出てくる。SESエンジニアとして現場でAIツール連携の設計経験を積んでおくことは、独立後の年収や契約条件を考えるうえでの材料になる。SES契約の注意点としては、客先常駐の契約条項でAIツールの利用自体が制限されている場合があること、生成したコードやドキュメントの著作権・利用範囲が契約書上どう扱われているかを事前に確認する必要があることの2点は特に見落とされやすい。SESエンジニアの実態として、契約先によってAI活用の自由度に大きな差があるため、面談時に「AIコーディングツールの利用可否」を確認しておくと、入ってから制約に気づくミスマッチを減らせる。
年収面では、AIエージェントの設計・運用経験（特に「記憶と実行を分離する」ような事故に強い構成を作れること）は、単なるコーディングスキルより評価されやすくなってきている。これは単価交渉やフリーランス案件選びの場面で、「AIツールを使える」ではなく「AIツールの事故を防ぐ構成を作れる」という差別化点として示せるからだ。
まとめ
- OpenClawのような記憶・指示層と、Claude Codeのような実行層を分けることで、同じ事故を繰り返さない仕組みが作れる
- ルールは記憶層に書くだけでなく、
--allowedToolsやラッパーコマンドのような実行層の制約に落とし込むことで初めて機能する - 無人cron実行では「生成は自動、公開は人間承認」のゲートを必ず挟む
- セキュリティレビューはコミット前の導線に組み込み、APIキーの受け渡し経路も明文化しておく
- SESエンジニアにとっても、こうした運用設計の経験は独立後の年収・契約条件を考える材料になる
AIエージェントに仕事を任せる範囲が広がるほど、「何を覚えさせて、何を実行させるか」の設計がそのまま事故率とアウトプット品質を決める。今回紹介したチェックリストは、新しい構成を作るたびに見直す前提で運用している。
関連記事
- 3人・月商250万円の会社がAI経営OS(CFO/COO/CMO)を作った記録
- Claude Code実務Tips総まとめ|hooks・サブエージェント・MCP活用で変わった開発フロー
- OpenClawの記憶×Claude Codeの実行で開発を自律化する実践録
AI駆動塾 — AIを使ったスモビジの作り方を学ぶ
Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。
書いた人: 合同会社Radineer（フリーランス向け案件サイト FreelanceDB を運営）