はじめに：経営者が「全部見る」をやめた日
経営をしていると、市場データ、契約書、コード品質、セキュリティ、SNS運用——見るべき対象が多すぎて、どこかで必ず抜け漏れが出ます。私は2026年に入ってから、Claude Codeのサブエージェント機能とcron/PM2によるバッチ実行基盤を組み合わせて「OpenClaw」と呼んでいる社内の経営OSを構築し、9体のAIエージェントに業務の監視・一次判断・レポーティングを分担させています。
この記事では「作ってみた」の実務ログとして、具体的な設定ファイル・コマンド・エージェント定義を公開します。生成AIの業務活用に興味があるエンジニア、そしてSES・フリーランスとして市場を見ながら動いているエンジニアの両方に役立つ内容を意識して書きました。
OpenClawとは何か（アーキテクチャの土台）
OpenClawは独自のLLMエンジンではなく、Claude Codeのエージェント機構（.claude/agents/*.md）を役割ごとに定義し、それをcronとPM2で常時稼働させる「運用レイヤー」です。ポイントは3つだけです。
- エージェントは役割単位でMarkdownファイルに分離する（1ファイル1責務）
- 実行はcronで時間起動、監視はPM2で常駐プロセス化する
- 本番の定時処理と重い検証処理は優先度を分けて競合させない
下は実際に使っている9体の役割一覧です。
| # | エージェント名 | 役割 | 起動方法 | 出力 |
|---|---|---|---|---|
| 1 | market-data-analyst | エンジニア市場データ分析（単価帯・需給） | cron(日次) | Markdownレポート |
| 2 | freelance-sourcer | フリーランス案件の探索・スクリーニング | cron(日次) | 候補リスト |
| 3 | ses-contract-reviewer | SES契約書の注意点チェック | 手動呼出 | チェックリスト結果 |
| 4 | security-watch | 依存関係・脆弱性情報の監視 | cron(日次) | アラート |
| 5 | test-quality-reviewer | テスト設計の質のレビュー | PR起点 | レビューコメント |
| 6 | content-ops | 記事・SNS原稿の生成 | cron | ドラフト |
| 7 | finance-watch | 請求・支払いの整合性チェック | cron(週次) | 差分レポート |
| 8 | incident-logger | 障害・ヒヤリハットの自動記録 | hook起点 | ログ |
| 9 | exec-digest | 1〜8の要約を経営者向けに1枚化 | cron(日次) | デイリーダイジェスト |
9番目のexec-digestが一番重要です。個々のエージェントがどれだけ賢くても、経営者が全部読む時間はないので、最後に「今日見るべき3行」まで圧縮させています。
技術詳解：エージェント定義の実例
実際のmarket-data-analystの定義はこういう形です（機密情報は除いています）。
---
name: market-data-analyst
description: エンジニア市場データ分析。SES単価帯・求人数・技術トレンドを日次で収集し異常値を検知する
tools: WebSearch, WebFetch, Bash, Write
model: sonnet
---
あなたはエンジニア市場データの分析官です。
毎回以下を行う:
1. 主要な求人系メディア・統計サイトから単価レンジを取得する
2. 前回実行結果との差分（+-10%以上）をハイライトする
3. 出典URLと取得日時を必ず明記する
4. 推測の数値は「推定」と明記し、断定しない
cron側はこのように、headlessモードでエージェントを指名して呼び出します。
# crontab -e
0 7 * * * cd ~/ses-content-automation && claude -p "/agents market-data-analyst を実行" --headless >> logs/market.log 2>&1
常駐が必要なプロセス（例：Claude認証のkeepaliveや通知ワーカー）はcronではなくPM2に乗せています。cronは「落ちても気づかない」のに対し、PM2は再起動とログ監視がセットになっているためです。
// ecosystem.config.js
module.exports = {
apps: [
{
name: "openclaw-keepalive",
script: "./scripts/keepalive.js",
autorestart: true,
max_restarts: 10,
watch: false
}
]
}
本番cronの定時処理と、研究・検証目的の重い処理（新しいエージェントのベンチマークなど）は優先度を明確に分けています。重い処理は専用スクリプト経由でnice優先度を下げて別枠実行し、本番の日次バッチが待たされないようにしています。マルチエージェント基盤を自作する人は、最初からこの「本番レーン」と「検証レーン」の分離を設計に入れておくことを強く勧めます。実際に分離前は、検証用の実行が長時間CPUを占有し、朝の定時処理が数百回単位で待たされる事態を経験しました。
エンジニア市場データ分析エージェントとフリーランス案件探し
market-data-analystとfreelance-sourcerは連携して動いています。市場データ分析エージェントが「今月、特定技術スタックの単価帯が上昇傾向」と検知すると、案件探索エージェントがその条件でフィルタをかけた候補リストを作る、という流れです。
フリーランスとして案件の探し方を考えるとき、個人の感覚だけで動くと「たまたま見た案件」に引っ張られがちです。AIエージェントに日次で市場データを取らせ、差分（前週比・前月比）だけを見る運用にすると、感覚ではなく数字ベースで動けるようになります。ここで重要なのは、エージェントに「推定は推定と書かせる」ルールを必ず入れることです。生成AIは聞かれれば断定的な数字を作ってしまうので、出典と取得日時を必須フィールドにしています。
SES契約レビューエージェントとSESフリーランスの注意点
SES契約を自分でレビューするses-contract-reviewerは、法律的な最終判断はしません（これは弁護士の仕事です）。あくまで「見落としやすい項目を機械的にチェックする一次フィルタ」として使っています。チェック項目は以下のように固定リスト化しています。
| チェック項目 | 見るポイント |
|---|---|
| 偽装請負リスク | 指揮命令系統が契約形態と一致しているか |
| 契約期間と更新条件 | 自動更新/非更新の通知期限 |
| 再委託の可否 | 多重下請け構造になっていないか |
| 知的財産権の帰属 | 作成物の権利が誰に帰属するか |
| 損害賠償の上限 | 上限条項の有無と金額 |
| 稼働時間の定義 | 準委任か請負かで変わる就業条件 |
SES契約の注意点は毎回似たパターンでつまずくため、チェックリスト化してエージェントに毎回同じ順番で確認させるのは、人間が見落とすより確実です。ただしここは意図的に「AIの最終判断」ではなく「人間が最終判断するための一次情報整理」に留めています。
セキュリティ監査エージェント——Qiitaの潮流から学ぶ
Qiitaでは直近14日間に「Security」タグを付けた記事のうちストック20超のものが5本観測されています。セキュリティ領域への関心が継続的に高いことがわかります。この潮流を受けてsecurity-watchは、依存パッケージの既知脆弱性だけでなく、「直近2週間で注目度が上がっている脆弱性カテゴリ」もあわせて要約するようにしています。やっていることは単純で、依存関係スキャンの結果と外部の脆弱性データベースの更新を日次で突き合わせ、差分だけをSlackに流す形です。
# セキュリティ監査エージェントの最小実行例
claude -p "/agents security-watch で package-lock.json の既知脆弱性を確認し、重大度High以上のみ報告して" --headless
テスト品質レビューエージェント——『単体テストの考え方/使い方』のエッセンスを運用に落とす
Zennの日次トレンドで『単体テストの考え方/使い方』のエッセンスを扱った記事が高い反応（いいね換算134）を得ていました。この本の核心的な主張の一つは「テストの数を増やすことより、リグレッションに強く・実装の詳細に依存しないテストを見分けること」です。test-quality-reviewerはこの観点をレビュー基準に組み込んでいます。具体的には、PRごとに以下を確認させています。
- モックが過剰で、実装の詳細に密結合したテストになっていないか
- テストが「何を保証しているか」をタイトルだけで説明できるか
- 同じ振る舞いを別の実装に変えてもテストが壊れないか（リファクタ耐性）
生成AIにコードレビューをさせる場合、「バグを探して」だけでは表面的な指摘に終わりがちです。良いテストの判断基準を明文化してエージェントに渡すことで、レビューの質が安定しました。
経営的に見えてきたこと
定量的な成果を誇張したくないので、ここは慎重に書きます。確実に言えるのは、9体に役割を分散させたことで「経営者である私が全部のログを読まなくても、exec-digestの1枚で優先度の高いものだけ判断できる」状態になったことです。これはまだ運用期間が浅い取り組みであり、「稼働している」とは言えても、長期的な経営成果として語れる段階ではありません。今後数週間〜数ヶ月の運用実績を見て、どのエージェントが本当に判断の質を上げているかを検証していきます。
保存用チェックリスト：マルチエージェント経営OSを作る前に確認する9項目
実際に手を動かす前に、この表だけブックマークしておけば設計のやり直しを減らせます。
| # | 確認項目 | やらないとどうなるか |
|---|---|---|
| 1 | エージェントを役割単位で1ファイル1責務に分離したか | 責務が混ざり、修正時に影響範囲が読めなくなる |
| 2 | 本番cronレーンと検証用の重い処理レーンを分けたか | 検証処理が本番の定時処理を待たせる |
| 3 | 常駐プロセスはPM2など再起動保証のある仕組みに乗せたか | 無音停止に気づけない |
| 4 | 「推定」と「確定値」を出力フォーマットで区別させたか | 断定的な誤情報がそのまま経営判断に使われる |
| 5 | 最終判断（法務・契約など）は人間に残したか | AIの一次整理を最終判断と誤認するリスク |
| 6 | 全エージェントの出力を1枚に要約するダイジェスト役を置いたか | 情報があっても読まれない |
| 7 | 外部API呼び出しのコスト上限を決めたか | 想定外の課金事故につながる |
| 8 | ログ・アラートの通知頻度に下限を設けたか | 通知疲れで本当に重要なアラートを見逃す |
| 9 | チェック項目・レビュー基準を明文化してエージェントに渡したか | 表面的な指摘しか出なくなる |
生成AIの業務活用で見えた本質
生成AIを業務に使うときにありがちな失敗は「1つの万能エージェントに全部やらせようとする」ことです。役割を分けて、各エージェントの出力を人間が最終判断する一次情報として扱うほうが、結果的に安全で、かつ経営者が安心して権限を渡せます。SESフリーランスとして動く個人であっても、この発想——市場データ・契約・コード品質を別々のチェックルーチンに分解する——はそのまま応用できます。
まとめ
OpenClawという名前の経営OSは、特別な魔法のツールではなく、Claude Codeのエージェント機構・cron・PM2という既存の部品を役割分担の設計で組み合わせたものです。9体という数字自体に意味はなく、「経営者一人では見きれない領域を、責務を分けたエージェントに一次整理させ、最後に1枚のダイジェストに圧縮する」という設計思想が本体です。フリーランスエンジニアの案件探しからSES契約のチェック、エンジニア市場データ分析まで、同じ発想で小さく始められます。まずは1つのエージェントを1つの役割だけに絞って動かしてみることをお勧めします。
関連記事
- OpenClaw×Claude Code連携実践：思考と実行を分離するAI開発設計
- 社員3人・月商250万円の会社がAI経営OSを作った実装記
- OpenClawで9体のAIエージェント経営OSを作った話｜設定と権限設計を全公開
AI駆動塾 — AIを使ったスモビジの作り方を学ぶ
Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。
書いた人: 合同会社Radineer（フリーランス向け案件サイト FreelanceDB を運営）