0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

OpenClawで9体のAIエージェント経営OSを構築した実践記録【2026年10月】

0
Posted at

OpenClawで9体のAIエージェント経営OSを構築した実践記録【2026年10月】

はじめに

2026年10月現在、Claude CodeのSkill機能とAgent(サブエージェント)機能を組み合わせて、CEO・CFO・CTO・COO・CMOをはじめとする9体のAIエージェントが分業する「経営OS」を実際に動かしている。本記事ではOpenClaw(Claude Codeのスキル/エージェント基盤を指す呼び方として使っている)上でこの仕組みをどう設計し、どう実装したかを、設定ファイルや権限設計のレベルまで具体的に共有する。

先に断っておくと、この経営OSはまだ構築してから日が浅く、「実装が完了した」ことと「安定稼働している」ことは別物だと考えている。なので本記事では「何を作ったか」「どう設計したか」という技術的な実務知見に絞り、検証できていない成果数値や誇張した売上実績は書かない。技術者として再現可能な部分だけを渡したい。

OpenClaw(Claude Code)の基本構造をおさらいする

AIエージェントで業務を分担させるとき、最初につまずくのは「1つの巨大なプロンプトに全部詰め込む」アプローチだ。これだと役割が混ざって指示が効かなくなる。Claude Codeでは以下の2つの仕組みで役割分担を実現できる。

  • Skill(SKILL.md): 特定業務の手順書をパッケージ化したもの。/cfo のようなスラッシュコマンドで呼び出す
  • Agent(サブエージェント): 独立したコンテキストで動く別人格。メインの会話を汚さずに調査やレビューを任せられる

Skillのfrontmatterは最小構成だとこうなる。

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

このdescriptionが肝で、Claude Codeは会話の文脈からどのSkillを呼ぶべきかをここで判断する。曖昧な説明文を書くと誤発火するので、「何をする役職か」「何のデータソースに繋がっているか」まで書き切るのがコツだ。

9体のエージェント経営OSの全体構成

実際に動かしている構成は、経営層5体+運用支援4体の役割分担になっている。

エージェント 役割 主な接続先/権限
CEO 他4役職の報告を統合し経営ダッシュボードと意思決定支援 読み取り専用、集計のみ
CFO freee連携で財務データ取得・PL生成・仕訳計上・キャッシュフロー予測 freee API、会計データ
CTO 複数プロダクトのヘルスチェック・技術スタック管理・開発優先度提案 Bash、Read、Grep、WebFetch
COO タスク進捗・クライアント管理・営業パイプライン管理 タスクDB、YAML操作
CMO GA4/Google Ads/GSC/SNSデータ統合によるマーケティング提案 分析API群(読み取り)
秘書(Secretary) inbox/today/archiveのYAML管理 ファイル操作のみ、外部送信権限なし
ナレッジ管理 教訓・パターン・インシデントの記録と検索 読み書き、ただし発信権限なし
サイト監査 pSEO各サイトのSEO/構造化データ/リンク切れを並列監査 Bash、Read、Grep、WebFetch
デプロイ検証 push前にクリーンなcommit/worktreeかを独立検証 Bash、Read、Grepのみ(書き込み不可)

この表だけでも分かる通り、設計思想は「役職ごとに触れるデータと実行できる操作を最小限にする」こと一本に尽きる。

技術的な肝:権限スコープの最小化(ここがセキュリティの話でもある)

直近のQiitaトレンドでも「MCPサーバーと繋いだだけで情報漏洩」「攻撃者視点でのbash侵入技術」といったセキュリティ系の記事がストックを伸ばしているが、マルチエージェント構成を組むときに一番効くセキュリティ対策は複雑な防御ロジックではなく、単純な権限のスコープ分離だ。

実際の設計ルール:

  1. 書き込み権限は業務上必須なエージェントにしか渡さない(秘書はYAML操作のみ、デプロイ検証はBash/Read/Grepで書き込み不可)
  2. 外部発信(SNS投稿・API書き込み)は自動化しない。下書き生成までをエージェントの仕事にし、公開は人間承認を挟む
  3. 読み取り専用エージェント(Explore相当)は調査専任にし、コード変更はさせない
  4. 1つのエージェントに全権限を持たせない — CEOエージェントですら実行権限は持たせず、他エージェントの報告を集約するだけに留める

この「最小権限の原則」はWebアプリのIAM設計と全く同じ考え方で、AIエージェントだからといって特別なものではない。むしろ既存のセキュリティ設計の知見がそのまま転用できる。

オーケストレーションの実装パターン

CEOエージェントが他4役職を統合する部分は、メインループから各Skillを個別に呼び出し、戻ってきたレポートをテキストとして集約する設計にしている。疑似的な流れはこうだ。

/ceo dash
  → /cfo のレポートを取得(PL・未決済状況)
  → /cto のレポートを取得(プロダクトヘルス)
  → /coo のレポートを取得(タスク・パイプライン)
  → /cmo のレポートを取得(マーケ指標)
  → 4つのレポートをCEO視点で要約・優先順位付け

ポイントは、CEOエージェント自身にはfreeeやGA4へのアクセス権を持たせず、「各専門エージェントの出力を読んで統合する」役割に限定していることだ。これにより、CEOエージェントのプロンプトが壊れても財務データや顧客データに直接触れない。障害時の被害範囲(blast radius)を役職の壁で区切っている。

構築して分かった運用上の教訓

技術的な実装よりも、実際に動かしてみて効いたのは地味な運用ルールだった。

  • 「実装完了」と「稼働中」を混同しない。コードが動いても、1〜2週間の運用実績が出るまでは「稼働中」と言わない方が誠実
  • 無人実行するタスクには必ずガードレールを明文化する。たとえばSNS投稿エージェントは同一アカウントへの連投間隔を強制し、公開は人間承認を挟む設計にしている
  • コストがかかる外部API呼び出しは経路を限定する。従量課金APIを気軽に新規呼び出しできる設計にすると、想定外の請求が発生しやすい
  • 重い処理と本番運用を同じリソースで混在させない。優先度の低いバッチ処理は本番のcronやPM2常駐プロセスと競合しないよう別枠で動かす

これらは特別な技術ではなく、普通のシステム運用の基本に近い。AIエージェントだから気をつけなくていい、ということは一つもなかった。

フリーランスエンジニア・個人開発者でも応用できる範囲

9体も作らなくても、この考え方は個人や小規模チームにそのまま使える。最初の一歩としてのチェックリストをまとめておく。

AIエージェント経営OSを作る前の確認チェックリスト

  • 各エージェントの役割を1行で説明できるか(説明できないなら分割が足りない)
  • 各エージェントに渡す権限(Bash/Read/Write/外部API)を最小限に絞ったか
  • 外部発信系のアクションに人間承認のステップを挟んだか
  • 無人実行する処理にコスト上限・実行間隔のガードレールがあるか
  • 1つのエージェントが壊れても他業務に波及しない設計になっているか
  • 「動いた」と「安定稼働している」を混同せず、検証期間を決めているか

このチェックリストは保存しておいて、自分のエージェント構成を作るときに見返してほしい。

SESエンジニアの実態とフリーランス比較(補足)

ここからは本題から少し離れるが、エンジニアのキャリア設計という文脈で触れておきたい。SES(システムエンジニアリングサービス)は多くの場合、一次請け・二次請け・三次請けという多重下請け構造の中で契約されており、現場のエンジニアに届く単価は各層のマージンが引かれた後の金額になる。これがSESエンジニアの年収がフリーランスの単価感覚と乖離しやすい構造的な理由だ。

SESエンジニア実態とフリーランス比較のポイントを整理すると以下のようになる。

比較軸 SES(正社員) フリーランス
契約形態 雇用契約+常駐(準委任/派遣) 業務委託契約を自分で締結
単価交渉 会社が代理交渉、本人には不透明なことが多い 自分で単価交渉に直接関与できる
収入の安定性 固定給で安定 案件終了リスクを自分で管理する必要
多重下請けの影響 マージンが複数層で発生 クライアントと直接契約なら層を減らせる
案件選択の自由度 配属先を選べないことが多い 自分でクライアント・案件を選べる

年収や単価の具体的な水準は年度・職種・経験年数によって変動が大きく、エージェント各社(レバテックフリーランス、PE-BANKなど)が公開している最新の相場データを確認するのが確実だ。独立を検討する際は、この表の比較軸をベースに「自分がどの軸を重視するか」を整理してから判断するといい。

まとめ

OpenClaw(Claude Code)でのマルチエージェント経営OS構築は、派手な新技術というより「権限設計」「役割分離」「人間承認を挟むポイントの設計」といった地味な設計判断の積み重ねだった。9体のエージェントを動かして分かったのは、AIエージェントのアーキテクチャ設計は結局のところ既存のソフトウェア設計・セキュリティ設計の知見がそのまま通用するということだ。これから似た仕組みを作る人は、上のチェックリストから始めてみてほしい。

関連記事


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

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

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


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

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

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

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?