OpenClawで9体のAIエージェント経営OSを構築した実装ログ【2026年版】

Posted at 2026-08-03

はじめに：なぜ「経営OS」をAIエージェントで作ったのか

2026年8月現在、Claude Codeのスキル（Skills）機構とサブエージェント機能を組み合わせると、個人でも「複数の役員が並行して仕事をする会社」をコードベースで再現できる。私はOpenClawというプラグイン基盤の上に、CEO・CFO・CTO・COO・CMOの経営5職と、部署ルーティング・秘書・ナレッジ管理・プロダクト管理を担う4体の補助エージェントを組み合わせた、計9体構成の「AI経営OS」を組んで日常業務に使っている。

本稿ではこのシステムを実際にどう設計し、どんなコマンドで回しているかをコード例付きで解説する。単価・年収の話とも無関係ではない。「AIオーケストレーションを自分の手で組める」スキルは、SESエンジニアが自分の単価を上げるための実務的なレバレッジになる。最後にその接続点にも触れる。

OpenClawとは何か

OpenClawは、Claude CodeのSKILL.mdベースのスキル定義とサブエージェント（Agent）、さらにCronCreateによるスケジュール実行を組み合わせて、業務プロセスを「呼び出し可能なコマンド」として再現するためのプラグイン群だ。1つのスキルは以下のようなfrontmatter付きMarkdownで定義される。

---
name: cfo
description: CFO（最高財務責任者）。freee連携で財務データ取得・PL生成・
  仕訳計上・未決済管理・キャッシュフロー予測を実行
---

# CFO スキルの振る舞い定義
- freee APIから当月の仕訳・入出金を取得する
- 未決済請求書のリストをYAMLで出力する
- PLサマリーをMarkdownテーブルで返す

これを.claude/skills/（あるいはプラグインパッケージ）配下に置くと、/cfo 未決済のようにスラッシュコマンドとして呼び出せるようになる。ポイントは、各スキルが独立したコンテキストとツール権限（Bash、Read、WebFetchなど）を持つ点だ。CFOエージェントに経理データのアクセス権だけを与え、CMOエージェントにはGA4やGoogle Adsの読み取り権限だけを与える、というように役割ごとに権限を絞れる。これはセキュリティ的にも「本番DBに秘書エージェントが誤って書き込む」ような事故を防ぐ設計になっている。

9体構成の設計思想

会社組織をそのままエージェント化すると、権限も責務も分離しやすい。私が実際に運用している構成は次の通り。

エージェント	役割	主なコマンド	連携先
CEO	経営ダッシュボード統合・意思決定支援	`/ceo`, `/dash`	CFO/CTO/COO/CMOの出力を集約
CFO	財務・freee連携・PL/仕訳・未決済管理	`/cfo`, `/pl`, `/shiwake`, `/mikessai`	freee API
CTO	プロダクトヘルスチェック・技術優先度提案	`/cto`, `/health`, `/priority`	各プロダクトのリポジトリ・CI
COO	タスク進捗・クライアント管理・営業パイプライン	`/coo`, `/clients`, `/project`, `/tasks`	プロジェクト管理データ
CMO	GA4/GSC/Google Ads/SNSを統合したマーケ分析	`/cmo`	GA4, GSC, Ads API
cc-company	タスクを部署に振り分けるルーティング層	`/cc-company`	各部署エージェント
cc-secretary	inbox/today/archiveのYAML操作	`/cc-secretary`, `/inbox`	ローカルYAMLストア
cc-knowledge	教訓・パターン・インシデントの記録検索	`/cc-knowledge`	ナレッジDB
cc-products	プロダクト横断管理	`/cc-products`	各プロダクトメタデータ

CEOエージェントは自分では財務データもコードも直接触らない。CFO・CTO・COO・CMOの「報告」を受け取って統合するだけの薄いレイヤーにしている。これはマイクロサービスにおけるAPI Gatewayの発想に近い。各職能エージェントが吐き出すレポートのフォーマットさえ揃っていれば、CEOレイヤーは差分の要約とアラート抽出に専念できる。

実際のセットアップ手順

導入は大きく3段階。

1. スキルディレクトリの配置

mkdir -p .claude/skills/{ceo,cfo,cto,coo,cmo,cc-company,cc-secretary,cc-knowledge,cc-products}
# 各ディレクトリにSKILL.mdを配置し、frontmatterでname/descriptionを定義

2. ツール権限のスコープ設定

各エージェントに必要最小限のツールだけを許可する。例えばCFOはBashとfreee連携用のスクリプトだけ、CMOはWebFetch・WebSearch・GA4/GSC参照だけ、という具合だ。過剰な権限を与えないことが、無人実行時の事故防止に直結する。

3. 定期実行のcron登録

朝会代わりに、毎朝CEOダッシュボードを自動生成させている。

# 平日朝にCEOダッシュボードを生成するcron相当の設定例
0 8 * * 1-5  claude --skill ceo --command dash >> logs/ceo_dash.log

Claude Code環境ではCronCreateツール経由でこれをエージェントに登録させることもできる。人間がcrontabを書く代わりに「毎朝8時にCEOダッシュボードを作って」と指示すれば、エージェント自身がスケジュールを設定する。

日常運用フロー

平日の朝、私が最初に叩くのは/ceoまたは短縮版の/dashだ。CEOエージェントはバックグラウンドでCFO・CTO・COO・CMOに問い合わせを投げ、並行して返ってきたレポートを1枚のダッシュボードに統合する。

$ /dash
[CEO] 集約中... CFO/CTO/COO/CMOへ並列問い合わせ
 - CFO: 未決済請求書あり → /cfo 未決済 で詳細確認可能
 - CTO: プロダクトヘルスチェック完了、要対応1件 → /health
 - COO: 案件パイプライン更新なし
 - CMO: GSCのクリック率に変動あり

ここで気になる項目があれば、該当エージェントにピンポイントで潜る。財務なら/mikessai（/cfo 未決済のショートカット）、技術的な優先度判断なら/priority（/cto priorityのショートカット）といった具合に、ショートカットスキルを別途定義しておくとタイプ数が減る。

秘書エージェント（cc-secretary）はinbox/today/archiveのYAMLファイルを直接操作する係で、/inboxで未処理タスクの一覧を取得し、処理済みのものをarchiveに移す。人間が「今日やること」を手で書き出す作業をここに寄せている。

構築で学んだ落とし穴

無人実行のエージェント群を回していると、コード上のバグより「運用ルール」の設計不備の方が事故につながりやすいと痛感する。実際に設計に組み込んだ安全策をいくつか挙げる。

API呼び出しの一本化：LLM APIを複数の場所から従量課金で叩けるようにすると、想定外のループで課金が跳ねるリスクがある。呼び出し経路をCLI経由の1本に絞り、新規の直接API呼び出しは原則禁止にした。
SNS投稿の連投間隔：SNS投稿を担うエージェントに自動公開までさせると、短時間の連投がプラットフォームのスパム判定に引っかかる。生成は自動、公開は人間承認、という分離を必須にしている。
権限のスコープ最小化：cc-secretaryのようなYAML操作専用エージェントに本番DBの書き込み権限を持たせない。役割ごとにツールを絞ることで、誤操作の影響範囲を局所化できる。
「実装完了」と「稼働実績」の区別：新しいエージェントを組んだ直後は、まだ実運用で検証されていない。数週間の運用実績が出るまでは「稼働中」と書かない、という区別をナレッジ（cc-knowledge）に明文化した。

これらは机上のセキュリティ論ではなく、無人実行を続けるうちに「そういえばここが甘かった」と気づいて後付けしたルールだ。cc-knowledgeエージェントに教訓を蓄積させておくと、同じ失敗パターンを次のエージェント設計時に自動で参照できる。

経営的な成果をどう測るか

「AI経営OSを作ったら売上が何倍になった」という類の話は、検証可能な形で語れる段階にまだない。正直に言うと、効果測定はこれからの課題だ。ただし設計上、次のような指標は追いやすくなっている。

意思決定に必要な情報を集めるまでのリードタイム（人手で各ツールを開いて回る時間 vs /dash一発の時間）
レポート作成にかかる手作業の有無（freeeやGA4を毎回手動で開いて転記していた作業がコマンド1つに集約されたか）
教訓の再利用率（同じ種類のミスをcc-knowledgeが検知して未然に防げたか）

数値としての「稼働実績」を主張できるのは、最低でも1〜2週間の継続運用データが溜まってからだと考えている。今はまだその途上にあるので、本稿では「作れる」「回っている」という事実ベースの共有に留める。

SESからフリーランスへ：このスキルが単価に直結する理由

ここでSESエンジニアの実務目線に戻る。SESの契約形態では、自分の単価がエンド企業にいくらで卸されているか見えないことが多く、多重下請け構造の中でスキルに見合った単価がそのまま年収に反映されにくい。フリーランスエージェント経由で独立すると、この構造上の中間マージンを削減できる分、単価交渉の主導権を持ちやすくなる。

その独立の際に武器になるのが、まさに今回紹介したような「AIエージェントを自分で設計・運用できる」スキルセットだ。理由は単純で、

Claude CodeやOpenClawのようなエージェント基盤を使いこなせるエンジニアの母数がまだ少ないため、案件単価の交渉材料になりやすい
業務自動化の実装経験は、SES常駐先での「AI導入したいがやり方が分からない」という需要に直接刺さる
フリーランスエージェント各社が目安として掲げる「SES 年収800万」クラスの案件は、単純な実装力だけでなく、業務プロセスをエージェント化して提案できる企画力込みで評価されることが多い

つまり、SESで培った「客先常駐で複数システムの実務を横断的に見てきた経験」と、OpenClawのようなエージェント基盤を組む技術力を掛け合わせると、フリーランス転向時の提案の解像度が上がる。年収800万という数字自体は各エージェントのマーケティング上の目安であり、保証された数値ではないが、単価交渉の土台として「業務を自動化できる証拠」を手元に持っておくことの価値は大きい。

OpenClaw運用でよくある質問

Q. OpenClawは何かのSaaSなのか？
違う。特定のSaaSではなく、Claude Codeのスキル（Skills）・サブエージェント・Cron機能を組み合わせて「業務プロセスをコマンド化する」ための設計パターン兼プラグイン集合だ。既存のfreeeやGA4、Google AdsなどのAPIは差し替え可能で、契約しているツールに合わせてスキル側のfrontmatterと処理内容を書き換えるだけでいい。

Q. 9体である必然性はあるのか？
ない。会社の意思決定単位に合わせて増減させればいい。私の場合はCEO/CFO/CTO/COO/CMOという経営5職に、ルーティング・秘書・ナレッジ・プロダクト管理という運用4層を足して9体になっただけで、1人の個人事業なら3〜4体構成でも十分回る。重要なのは体数ではなく、権限を役割ごとに分離する設計思想の方だ。

Q. SESエンジニアが土日で真似できるレベルか？
スキル1つの定義自体はMarkdownのfrontmatterとBashコマンドの組み合わせなので、既存のシェルスクリプトを1本SKILL.md化するところから始めれば土日で試せる。9体まで拡張するかどうかは、業務量と権限管理の必要性に応じて判断すればいい。

まとめ

OpenClawを使った9体構成の経営OSは、特別なインフラを必要としない。Claude Codeのスキル機構とサブエージェント、cronスケジューリングを組み合わせるだけで、役割ごとに権限を絞った「並行して働く役員」を再現できる。重要なのは無人実行時の安全策（API呼び出しの一本化、SNS投稿の人間承認、権限の最小化）を設計段階で埋め込んでおくことだ。

SESエンジニアにとっても、この種のエージェントオーケストレーション設計は他人事ではない。単価・年収を自分でコントロールしたいなら、まずは自分の業務プロセスを1つスキル化してみるところから始めるのがいい。

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

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

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

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

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

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

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

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