3人で月商250万円、管理コストだけが膨らんでいく会社だった
前提を先に書く。うちは代表含めて3人の会社で、コンテンツ自動化やSES関連の受託を組み合わせて月商250万円前後で回している。人数が増えないまま案件が増えると、現場の手が止まる理由はコードではなく「誰が何を決めるか」だった。見積もりの承認待ち、請求書の消込待ち、SNS投稿の確認待ち——全部が代表の手元で詰まる。
そこで2026年に入ってから、Claude Codeをベースに「CFO」「COO」「CMO」「CEO」という役割を持つAIエージェント群を社内に置いた。本記事では、その構築過程でつまずいた点と、実際に出た効果をできるだけ数字と事実ベースで共有する。架空の体験や検証できない成果は書かない。
AI経営OSとは何か:役職ではなく「意思決定の型」をエージェント化する
最初に誤解していたのは、「CFOエージェント=会計ソフトのAPIを呼ぶbot」という発想だった。それだと結局、人間が毎回プロンプトを書く作業代行にしかならない。実際にやったのは、役職ごとに**判断の型(プロンプト+ツール権限+チェックリスト)**を固定し、cronとサブエージェントで常時稼働させることだった。
構成の概要
~/ai-os/
cfo/ # 資金繰り・請求消込・コスト異常検知
coo/ # 案件進行管理・タスク分配・納期アラート
cmo/ # SNS投稿下書き・トレンド分析・コンテンツ企画
ceo/ # 週次の意思決定サマリー・各役職レポートの統合
shared/ # 共通の安全ルール(CLAUDE.md相当)・ログ
各エージェントはClaude Codeのサブエージェント機能で動かし、役職ごとに扱えるツールを明示的に絞っている。CFOエージェントに本番のSNS投稿権限を持たせない、CMOエージェントに銀行APIを触らせない、といった「権限の最小化」が後述する事故防止の核になった。
COOエージェントの実装例(タスク分配の判断ロジック)
# coo/dispatch.py — 案件の優先度を機械的に並べ替える
def score_task(task):
deadline_weight = max(0, 14 - task.days_until_due) * 3
client_weight = 10 if task.client_tier == "A" else 5
blocked_weight = 8 if task.is_blocking_others else 0
return deadline_weight + client_weight + blocked_weight
tasks_sorted = sorted(open_tasks, key=score_task, reverse=True)
AIっぽく見えないコードだが、これが重要だった。LLMに毎回「優先順位をつけて」と丸投げすると、同じ入力でも出力がぶれる。優先度のロジックは決定論的なコードに落とし、LLM(エージェント)の役割は「このスコアリング結果を人間向けの文章に翻訳する」「異常なタスクをLLMの文脈理解で見つける」に限定した。判断の再現性が必要な部分はコード、文脈理解が必要な部分だけLLM、という分離がAI経営OSの肝だと今は思っている。
つまずいたポイント:無人運用はコスト事故と直結する
正直に書くと、最初の1ヶ月は「動いた」と「安全に動いた」を混同していた。具体的に踏んだ地雷は以下の3つ。
-
cronで動かしたエージェントが深夜に暴走し、同じ処理を数百回リトライした。 原因はAPIのレート制限エラーをキャッチせず無限に再試行するロジックだったこと。今はリトライ回数とタイムアウトを必ず明示し、
research-run相当の優先度制御(nice値を下げる、並列数を絞る)を重い処理には必須にしている。 - CMOエージェントにSNS投稿の「公開」権限を直接渡していた時期があり、下書きのつもりの文章が本番投稿された。 これ以降、生成は下書きまで、公開は人間承認という一段をどのエージェントにも強制している。AIが文章を作るスピードと、公開の取り消しにかかる社会的コストは非対称だと痛感した。
-
CFOエージェントのログに取引先名や金額がそのまま残り、他のエージェントのプロンプトに混入しかけた。 役職間でコンテキストを共有する設計にしていたのが原因。今は
shared/のログは要約のみを渡し、生データは役職をまたがせないようにRBAC的な境界を引いている。
この3つはすべて「Security」の話でもある。AIエージェントを複数組み合わせるアーキテクチャでは、プロンプトインジェクションだけでなくエージェント間の権限境界が実質的な攻撃面になる。外部ツール連携が増えるほど、どのエージェントがどのデータに触れるかを棚卸しする作業は、単体のWebアプリのセキュリティレビューより手間がかかる、というのが実感だ。
俺のAIプログラミング手法:サブエージェントは「分業」ではなく「検証係」として使う
Zennなどで「俺のAIプログラミング手法」系の記事が伸びているのを見て、自分のやり方を振り返った。うちの場合、サブエージェントを単純な分業(機能A担当、機能B担当)として使うより、実装したエージェントを別のエージェントが検証する構成の方が事故が減った。
phase("実装")
const impl = await agent("COOのタスク分配ロジックを実装", { label: "impl" })
phase("検証")
const review = await agent(
`この実装がCLAUDE.mdの権限最小化ルールに違反していないか確認して: ${impl}`,
{ label: "security-check" }
)
実装係と監査係を分離するだけで、「権限を広げすぎる」「エラーハンドリングを握り潰す」といったミスの検出率が明確に上がった。1人のエージェントに全部やらせると、自分の実装を自分で甘く採点してしまう傾向がある。これは人間のコードレビューでも同じことだが、AIエージェントだと歯止めが効きにくい分、仕組みとして分離する価値が大きい。
実際の効果:誇張せず、観測できた範囲だけ書く
「AIで業務が激変した」とは書かない。正確には、以下の作業について人間の実働時間が明確に減ったことを確認している。
| 業務 | 導入前 | 導入後 | 変化の中身 |
|---|---|---|---|
| 請求消込の一次チェック | 代表が目視 | CFOエージェントが差分検知→人間が最終承認 | 承認作業のみに圧縮 |
| 案件タスクの優先順位付け | 口頭・Slackで都度相談 | COOエージェントのスコアリング結果を確認 | 相談の往復が減少 |
| SNS投稿の下書き作成 | ゼロから人間が書く | CMOエージェントが下書き→人間が編集・承認 | 作成時間が短縮、公開判断は人間が維持 |
ただし、まだ運用は数ヶ月の段階で、長期の安定稼働を確認できたとは言えない。「実装が終わった」と「運用で信頼できる」は別物だと考えているので、この記事でも「稼働中」という言葉は、実際に継続して使っている範囲にだけ使っている。
SESエンジニアとして見たとき、この話は何を意味するか
記事の本題はAI経営OSの実装だが、SESで働くエンジニアや、フリーランス転向を考えている人にとっても関係がある話なので触れておく。
小さな会社が「経営の判断を仕組み化する」動きは、裏を返すと人間に求める役割が「作業」から「判断と承認」に移っていくということだ。SESで常駐してコーディングだけをしてきたエンジニアが、エンジニア キャリア ガイドとして次に意識すべきは、コードを書く速さよりも「何を作るべきかを判断する力」になっていく。
SESとフリーランスの比較でよく聞かれる年収の話も、この文脈で見ると分かりやすい。SESの多重下請け構造では、現場での評価が直接の年収に反映されにくく、仲介のレイヤー分だけ取り分が薄くなる。一方でフリーランスは単価交渉の裁量が大きい代わりに、営業・契約・税務といった「経営の判断業務」を自分で抱える必要がある。AI経営OSのようなエージェント群は、まさにこの「経営の判断業務」を個人でも仕組み化できる手段になり得る。SES フリーランス 比較という観点で言えば、今後は「どちらの雇用形態か」より「経営判断をどれだけ仕組み化できているか」の差の方が、実質的な年収やキャリアの自由度に影響していくはずだ。
保存用チェックリスト:AI経営OSを作る前に確認すること
実際にやってみて、最初に決めておくべきだったことをチェックリストにまとめた。これから同じようなものを作る人は、着手前に埋めてから始めることを勧める。
- 各エージェントの「公開権限」と「下書き権限」を明確に分けたか
- リトライ・タイムアウトの上限を全てのcronジョブに設定したか
- エージェント間で共有するログに個人情報・取引先情報が生データで混入していないか
- 判断の再現性が必要な処理(優先順位付けなど)はLLMでなくコードに落としたか
- 実装係と検証係のエージェントを分離したか(自己採点の閉じたループになっていないか)
- 「実装完了」と「運用で信頼できる」を混同せず、稼働実績の期間を明示しているか
- 重い処理(学習・ベンチ・大量生成)を本番のcron/PM2と分離して優先度を下げたか
一覧性のあるチェックリストとして保存しておくと、次に新しいエージェントを追加するときの事故防止チェックにそのまま使える。
まとめ
AI経営OSは「AIが経営判断をする」仕組みではなく、「判断のうち再現可能な部分をコード化し、文脈理解が必要な部分だけをLLMに渡し、公開や支出といった不可逆な行為は必ず人間が承認する」仕組みだった。3人・月商250万円という規模だからこそ、権限管理や検証の仕組みを後回しにするとすぐに事故につながる、というのが今回の一番の学びだった。
関連記事
- Claude Code実務Tips総まとめ|hooks・サブエージェント・MCP活用で変わった開発フロー
- OpenClawの記憶×Claude Codeの実行で開発を自律化する実践録
- 【2026年最新】AIコーディングツール徹底比較|Claude Code・Copilot・Cursor・Windsurf・Codeiumの選び方
AI駆動塾 — AIを使ったスモビジの作り方を学ぶ
Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。
書いた人: 合同会社Radineer（フリーランス向け案件サイト FreelanceDB を運営）