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を構築した実装ノート

0
Posted at

一人経営者が抱える「意思決定の孤独」という問題

SESからフリーランス、あるいは法人化へとキャリアを進めたエンジニアなら誰もが一度はぶつかる壁がある。技術力があっても、財務・営業・技術戦略・マーケティングを一人で回すのは物理的に不可能だという事実だ。

会計処理をしながら見積もりを出し、その合間に技術選定をして、SNSの投稿も考える。どのタスクも「今すぐやらなければ」に見えるのに、優先順位をつける相手がいない。これは経営者特有の孤独であり、SESからフリーランス、独立へと進むエンジニアが最初にぶつかる壁でもある。

この記事では、Claude Codeをベースにした「OpenClaw」という仕組みの上に、CEO・CFO・CTO・COO・CMOと秘書・ナレッジ管理系の合計9体のAIエージェントを構築し、実際に経営判断のサポートに使っている実装を、技術面と運用面の両方から共有する。

OpenClawとは何か:Claude Codeを土台にしたマルチエージェント経営基盤

OpenClawは、Claude Codeの「Skill」機構とスラッシュコマンドを組み合わせて、役割ごとに独立したAIエージェントを常駐させる設計思想だ。特別な独自ランタイムを持つわけではなく、以下の3つの標準機能の組み合わせで成立している。

  • Skill(YAML frontmatter付きMarkdown) — 各エージェントの役割・権限・使用ツールを定義
  • スラッシュコマンド — /cfo, /cto のように役割を即座に呼び出す入口
  • CLAUDE.md — エージェント間の指揮系統と全体ルールを記述する憲法にあたるファイル

生成AIやClaudeCodeタグがQiitaで直近14日にストック20超の記事を10本以上集めているように、AIエージェントを「使う」段階から「複数体を役割分担させて運用する」段階への関心が明らかに高まっている。OpenClawはその実践の一つの答えだ。

9体のエージェント構成表(保存版)

実際に運用している経営OSの構成は以下の通り。保存して自分のプロジェクトに当てはめてみてほしい。

# エージェント 役割 主な連携先
1 CEO 各役員報告の統合・経営ダッシュボード生成 CFO/CTO/COO/CMO全員
2 CFO 会計freee連携、PL生成、仕訳、キャッシュフロー予測 会計API
3 CTO プロダクト群のヘルスチェック、技術優先度提案 GitHub/CI
4 COO タスク進捗・クライアント管理・営業パイプライン管理 プロジェクト管理ツール
5 CMO GA4/Google Ads/GSC/SNSデータ統合、マーケ戦略提案 分析ツール群
6 CC Company(統括) 子会社的プロダクト群の横断管理 各プロダクトSkill
7 CC Knowledge 教訓・パターン・インシデントの記録検索 ナレッジベース
8 CC Products プロダクトポートフォリオ管理 CTO
9 CC Secretary(秘書) inbox/today/archiveのYAML操作、日次タスク整理 CEO

経営学的に見ると、これはCFO/CTO/COO/CMOという伝統的な役員会にナレッジマネジメント層(CC Knowledge)と秘書機能を足した構成になっている。人間の経営チームを模倣するのではなく、「意思決定に必要な情報を毎朝勝手に集めてくる」ことに主眼を置いている点が実務上のポイントだ。

技術詳細1:Skillとしてのエージェント定義

各エージェントはMarkdownファイル1本で定義する。YAML frontmatterに名前・説明・使用可能ツールを書き、本文に振る舞いのルールを書くだけだ。CFOエージェントの骨格は以下のようなイメージになる。

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

# CFOエージェント振る舞いルール

- 起動時は必ず未決済一覧を先に確認する
- 数値を提案する前に実データ(freee API)を必ず参照する
- ピーク値を「通常値」として扱わない
- 実装が完了しても、運用実績が出るまで「稼働中」と書かない

ここで効いてくるのが最後の2行だ。AIエージェントは放っておくと「良さそうな数字」を作文してしまう。経営判断に使う以上、これは致命的なバグになる。だからこそ、Skill定義そのものに「実データ確認必須」「未検証の値を断定しない」というガードレールを明文化しておく必要がある。

技術詳細2:CLAUDE.mdでエージェント間の指揮系統を作る

CLAUDE.mdはプロジェクト全体のルールブックだ。ここに「誰が誰に報告するか」「危険な操作(本番デプロイ、外部送信、資金移動など)は必ず人間承認を挟む」といったガードレールを書いておくことで、9体のエージェントが暴走しない設計にしている。

## 経営OS運用ルール

- 各役員(CFO/CTO/COO/CMO)はCEOにのみレポートを提出する
- SNS投稿・対外発信は必ずPR(下書き)を経て人間が承認する
- 財務数値・実績数値は必ずAPI実データに基づく。推測値は「推定」と明記する
- 同一チャネルへの連続実行は最低15分間隔をあける

この手のルールは、実際に事故を経験してから初めて言語化されることが多い。連投間隔のルールなどはまさにその典型で、SNS運用を自動化するなら最初から明文化しておいた方がいい。

技術詳細3:スラッシュコマンドでエージェントを呼び出す

実運用では、ターミナルから以下のように呼び出すだけで各エージェントが起動する。

/cfo 未決済          # CFOに未決済案件の一覧を出させる
/cto health          # CTOに全プロダクトのヘルスチェックをさせる
/coo tasks           # COOにタスク進捗をまとめさせる
/cmo                 # マーケティングダッシュボードを生成
/ceo ダッシュボード   # 全役員の報告を統合した経営ダッシュボード

ポイントは、CEOエージェント自体は数値を「作らない」ことだ。CFO/CTO/COO/CMOの出力を集約して並べるだけの層にしておくことで、ハルシネーションが混入する経路を減らせる。集約層でもう一度LLMに数値を要約させると、そこで数字が微妙に変わるという事故が起きやすいため、この層は極力「転記」に徹させている。

技術詳細4:cronで秘書エージェントに定期報告させる

毎朝のタスク整理はCC Secretaryエージェントに任せている。これはcron的な仕組みで定期実行し、inbox/today/archiveというYAMLベースの3層構造でタスクを移動させる設計だ。無人実行するため、ここでも「有料APIの新規呼び出しを増やさない」「常駐プロセスが落ちても気づけるように監視する」といった運用面のガードレールが欠かせない。無人自動化は便利な反面、気づかないうちに動き続けて想定外のコストや投稿を生む危険もあるため、実行間隔と承認フローの設計に一番時間をかけている。

つまずいたポイント3選

  1. エージェントに数字を「創作」させてしまった — 実データ取得に失敗した際、フォールバックとして「もっともらしい数値」を返してしまうケースがあった。対策として、データ取得に失敗したら数値を出さずにエラーを明示するようSkillのルールを修正した。
  2. 役割の重複でエージェント同士が矛盾した報告を出した — COOとCMOの両方が営業パイプラインに言及し、微妙に違う数字を出したことがある。責任範囲をCLAUDE.mdでより厳密に切り分けることで解消した。
  3. 秘書エージェントの自動実行が想定より頻繁だった — cron設定の間隔が短すぎて、同じタスクが何度も再提示される状態になった。実行間隔と冪等性の設計を見直した。

どれも「動くようになってから初めて気づく」種類の問題で、事前に完璧な設計をするより、小さく動かして早めに壊れる場所を見つける方が結果的に早かった。

SESエンジニア視点で見る「データ分析」という武器

ここでSESエンジニアの話に戻りたい。SES フリーランス 比較を検討する際、多くのエンジニアは「単価」だけを見て判断しがちだ。しかし経営OSを回してみて痛感したのは、単価そのものより、エンジニア 市場データ分析の観点から自分の稼働実態を可視化できるかどうかが独立可否を分けるという点だ。

SES契約下では稼働時間・案件内容・評価がすべて客先企業の管理下にあり、自分自身のデータ分析基盤を持てないことが多い。一方でフリーランスや法人化後は、自分の案件データ・収支データを自分のフォーマットで蓄積できる。この「自分のデータを自分で分析できる状態」を早期に作れるかどうかが、SESからフリーランスへの移行における最大の分水嶺だと感じている。

AIエージェントによる経営OSは、この「自分でデータ分析基盤を持つ」というハードルを大きく下げてくれる。会計データ、案件データ、マーケティングデータをそれぞれ専任のエージェントに任せることで、一人でもデータドリブンな経営判断ができる体制に近づける。

保存版チェックリスト:AIエージェント経営OSを作る前に確認する10項目

自分でOpenClaw的な仕組みを構築する前に、以下をチェックしておくと事故を減らせる。

  • 各エージェントの役割と権限をCLAUDE.mdに明文化したか
  • 危険な操作(送金・対外発信・本番デプロイ)に人間承認のステップを挟んだか
  • データ取得失敗時に「創作値」を返さないルールを書いたか
  • エージェント間の報告経路(誰が誰に報告するか)を一本化したか
  • 無人cron実行の間隔と冪等性を検証したか
  • 有料API/LLM呼び出しのコスト上限を設定したか
  • SNS等の対外発信は下書きまでで、公開は人間承認にしたか
  • 実績・数値は必ず実データ確認を経てから記載するルールにしたか
  • 「実装完了」と「運用実績あり」を書き分けるルールを設けたか
  • エージェント同士の役割重複がないか定期的に見直しているか

このリストは実際に事故ってから足していった項目が大半だ。最初から全部揃えるのは難しいが、少なくとも「危険操作への人間承認」と「創作値の禁止」の2つは初期段階で必ず入れておくべきだと感じている。

まとめ

OpenClawによる9体のAIエージェント経営OSは、特別な独自技術ではなく、Claude CodeのSkillとスラッシュコマンド、CLAUDE.mdによるルール定義という標準機能の組み合わせで実現できる。重要なのは技術的な実装そのものよりも、「エージェントに何をさせないか」というガードレールの設計だ。

SESからフリーランス、独立へとキャリアを進めるエンジニアにとって、AIエージェントを役割分担させて経営タスクを肩代わりさせる発想は、一人で全部を抱え込まずに事業を回すための現実的な選択肢になりつつある。ClaudeCodeや生成AIタグの記事がQiitaで急増している今、単体での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?