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
Last updated at Posted at 2026-09-07

はじめに:なぜ経営そのものをAIエージェント化したのか

2026年9月現在、生成AIやClaudeCodeといったタグはQiitaでも直近2週間で高ストック記事が続出しており、AIエージェントの実務活用が「試してみた」段階から「本番運用」段階に移りつつあるのを肌で感じる。私自身、ここ数ヶ月かけてOpenClawというマルチエージェント基盤の上に、CEO・CFO・CTO・COO・CMOと秘書役を含めた9体のAIエージェントによる「経営OS」を組み上げてきた。

本記事では、経営者としての立場から、OpenClawの具体的な設定方法、エージェント設計の実体験、そして技術的な工夫と経営判断の両面を、実際に使っているコード・設定例とともに共有する。誇張した成果報告ではなく、再現可能な仕組みの話に絞る。

OpenClawとは何か——Claude Code CLIを核にしたマルチエージェント基盤

OpenClawは、Anthropic社のClaude Codeをベースに、複数のエージェント(サブエージェント)を役割ごとに定義し、それぞれに固有のツール権限・知識・振る舞いを持たせて協調動作させるための構成の総称だ。中核になっているのは以下の3つの仕組みである。

  1. Agents:.claude/agents/*.md のfrontmatterで、役割ごとのエージェントを定義する
  2. Skills:SKILL.md として業務プロセスをパッケージ化し、/コマンド名 で呼び出せるようにする
  3. Hooks / Cron:定型処理を人手を介さず定期実行するためのトリガー機構

エージェント定義は驚くほどシンプルだ。例えばCFO役のエージェントは、次のようなfrontmatter付きMarkdownファイルとして定義できる。

---
name: cfo
description: CFO(最高財務責任者)。会計データ連携でPL生成・仕訳計上・キャッシュフロー予測を実行
tools: Bash, Read, Grep
model: sonnet
---

あなたはCFOとして、月次の損益計算と資金繰り予測を担当する。
数値を提案する前に必ず実データ(会計API・帳簿)を確認し、
未検証の推定値を「実績」として報告しない。

ポイントは tools フィールドでツール権限を役割ごとに絞り込んでいることだ。CFOエージェントに本番デプロイ権限を持たせる必要はないし、逆にCTOエージェントに会計データへの書き込み権限は不要。最小権限の原則をエージェント単位で徹底するのが、無人運用における事故防止の第一歩になる。

9体のエージェント設計:C-suiteモデルで経営を分業する

経営OSの設計思想は、実在の企業の経営陣(C-suite)をそのままエージェント化するというものだ。人間の役員会議と同じ構造をAIに持たせることで、報告フォーマットや意思決定フローが直感的に理解しやすくなる。

エージェント 役割 主なデータソース
CEO 全体統合・経営ダッシュボード 各C-suiteの報告
CFO 財務・PL・キャッシュフロー 会計API連携
CTO プロダクトの技術ヘルスチェック リポジトリ・CI状況
COO タスク・案件・営業パイプライン管理 プロジェクト管理データ
CMO マーケティング指標統合 GA4・広告・SNS分析
秘書(複数体) inbox/todoのYAML管理・議事録整理 ローカルファイル

CEOエージェントは自分では一次データを持たず、CFO/CTO/COO/CMOの報告を受け取って統合するだけ、という設計にしている。これは実際の組織運営とも似ていて、「誰が一次情報を持ち、誰が統合するか」を明確に分離することが、エージェント同士のハルシネーション連鎖を防ぐ鍵になる。CEOエージェントが直接データベースを叩いて数字を「創作」してしまうリスクを、権限設計そのもので潰しておくイメージだ。

エージェント間の情報連携:YAMLベースの秘書パターン

複数エージェントが非同期に動く以上、状態をどう共有するかが設計の肝になる。私が採用しているのは、秘書役エージェントが inbox.yaml / today.yaml / archive.yaml の3ファイルを管理し、他のエージェントはそのファイルを読み書きするだけで連携する、というシンプルなパターンだ。

# inbox.yaml
- id: 20260908-01
  from: cfo
  to: ceo
  summary: 未決済請求書が3件、期限超過
  priority: high
  status: unread

メッセージキューやDBを持ち込まず、Gitで差分管理できるYAMLに寄せているのは意図的な判断だ。障害が起きても人間がテキストエディタで直接原因を追える、というのは無人運用において想像以上に重要になる。凝ったアーキテクチャより、壊れたときに人間が復旧できる仕組みを優先している。

権限設計とセーフティガード:無人運用で事故らないための仕組み

9体のエージェントを自律的に動かす以上、「暴走したときにどこで止まるか」を先に設計しておく必要がある。私が実務で必ず入れているガードは次の3つだ。

  • ツール権限の役割別最小化:settings.json でエージェントごとに許可コマンドを明示し、rm -rf や本番デプロイ系コマンドは人間承認必須にする
  • 外部発信の自動化禁止:SNS投稿やメール送信などの対外的アクションは、生成までは自動化しても公開・送信は人間承認を挟む
  • 数値の出典チェック:エージェントが経営指標や実績値を報告する際、実データに基づかない推定値を「実績」として出力しないようプロンプトで明示的に禁止する

特に3点目は地味だが効果が大きい。AIエージェントは自信満々に「もっともらしい数字」を出しがちなので、「実装完了」と「稼働中」を混同しない、ピーク値を平常値のように扱わないというルールをシステムプロンプトレベルで固定しておくことで、経営判断を誤らせるリスクをかなり減らせる。

スキル(Skill)による業務プロセスの標準化

エージェントの「振る舞い」を都度プロンプトで指示するのではなく、SKILL.md として業務プロセスそのものをパッケージ化しておくと、再現性が一気に上がる。例えば月次決算のフローなら次のようなSKILL.mdを用意する。

---
name: monthly-pl
description: 月次PLを生成し、CFOダッシュボードに反映する
---

1. 会計データを取得する
2. 前月比・予算比を計算する
3. 異常値(前月比±30%超)があれば理由を確認してから報告に含める
4. Markdown形式でCEO向けサマリを1画面に収める

人間の新任担当者に業務マニュアルを渡すのと同じ感覚で、エージェントにスキルを渡す。これにより、モデルのバージョンが変わっても業務プロセスの一貫性が保たれるのが大きい。

経営OS運用で見えてきた変化(定性的な成果)

定量的な誇張はしたくないので定性的な話にとどめるが、体感として最も大きかったのは「経営レポーティングにかかる可処分時間の使い方が変わった」ことだ。以前は各種データを手作業で集計してから意思決定していたが、今はCEOエージェントが常時ダッシュボードを更新してくれるため、経営者としての時間を「集計」より「判断」に振り向けられるようになった。ただしこれはまだ運用期間が短く、システムとして安定稼働と呼べるかどうかは今後数ヶ月の実績で見極めが必要な段階だと考えている。

SESエンジニアにとっての示唆:AIエージェント運用スキルとキャリア

ここからは少し視点を変えて、SES企業に所属するエンジニアのキャリアの話をしたい。経済産業省が公表している「IT人材白書」など各種調査でも、IT人材の需給ギャップと生成AIスキルの重要性は繰り返し指摘されている。今後のエンジニア キャリア ガイドとして重要になるのは、単一言語のコーディングスキルだけでなく、「複数のAIエージェントを設計・運用し、業務プロセス全体を自動化できる能力」だろう。

SES契約の現場では、常駐先の業務効率化提案としてAIエージェント活用の実装力を示せるかどうかが、契約単価や評価に直結し始めている。エンジニア 市場データ 分析の観点で見ても、「AIツールを使いこなせる」ではなく「AIエージェントの権限設計・障害対応まで含めて設計できる」レベルの人材が希少になっているのが実態に近い。年収交渉の材料としても、こうした運用実績を言語化できるかどうかは今後ますます差がつくポイントになるはずだ。

SESからフリーランス、あるいは自社サービス運営へとキャリアを広げたいエンジニアにとって、今回紹介したような「小さく作って壊れない設計にする」「権限を絞る」「YAMLのような枯れた技術で連携する」という地味な設計判断の積み重ねこそが、実は一番再現性の高いスキルだと感じている。

まとめ

OpenClawによる9体のAIエージェント経営OSは、派手な自動化というより、権限設計・データの一次情報管理・障害時の人間介入ポイントを丁寧に作り込んだ結果として成立している。ClaudeCodeのAgents/Skills/Hooksという枯れた3つの仕組みだけで、ここまでの分業体制が組めることは、SESエンジニアが今後のキャリアを考える上でも大いに参考になるはずだ。まずは1体、自分の業務の一部を代行するエージェントから作ってみることをおすすめしたい。

関連記事


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

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

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


書いた人: 合同会社Radineer(フリーランス向け案件サイト FreelanceDB を運営)

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?