1
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?

月商250万の3人会社がAI経営OSを作った話 CFOもCOOもAIエージェント

1
Posted at

月商250万、社員3人。それでも「経営OS」を作った

2026年10月時点、うちの会社は社員3人、月商およそ250万円の小さなSES/受託の会社です。それでも今年、CFO・COO・CMO・CEOという名前をつけたAIエージェント群を社内に構築しました。

「3人しかいないのに経営OSって大げさじゃない?」と聞かれることが多いのですが、理由は単純です。3人だと経理も採用も案件探しも全部自分でやるしかなく、どれも中途半端になる。だったら「意思決定の下書き」をAIに任せて、人間は最終判断と実行だけに集中する設計にしよう、というのが出発点でした。

この記事では、きれいな成功談ではなく、実際につまずいた箇所と、そこから作ったルール、そして今の実態を書きます。SESエンジニア、フリーランスエンジニアの方にも「AIをどう実務に組み込むか」「案件探しやキャリアにどう活かせるか」の参考になるようにまとめます。

CFO/COO/CMO/CEOという4つのAIエージェントは何をしているのか

ベースはClaude Code。サブエージェントとして役割ごとにプロンプトとツール権限を分けています。たとえばCFOエージェントの定義はこんな感じです(実際のファイルを簡略化したもの)。

---
name: cfo
description: 月次の原価・キャッシュフロー・請求状況をレビューし、異常値をレポートする
tools: Read, Bash, Grep
model: sonnet
---

あなたはこの会社のCFOです。
- freee/請求書データと銀行残高を突き合わせる
- 外注費・サブスク費の前月比を出す
- 異常値(20%以上の変動)だけを報告する。正常範囲は報告しない

COOは日々のタスク進行とcron/PM2の実行状況の監視、CMOはSNS/note/Qiitaの投稿計画と反応の数値管理、CEOは週次でこの3エージェントの報告を要約して「今週やるべき3つのこと」に絞り込む役割です。

ポイントは、どのエージェントも提案はするが実行は人間が承認するという設計にしていること。特にSNS投稿やお金が動く操作は自動実行させません。これは痛い目に遭って決めたルールです。次で具体的に説明します。

つまずいたポイント①: 候補を自分(AI)で作って自分(AI)で採点していた

一番大きな学びは、実は本業とは別のところ、社内でやっていたKaggleのシミュレーションコンペ(ポケモンカードのAI対戦)から来ています。結果は6,807チーム中4,549位でした。

振り返って分かったのは、選別の仕組み自体は上位チームと同じ作りだったのに、その仕組みに入れる「候補」を自分たちで生成して自分たちで採点していたという点です。上位チームは他チームの強い実戦データ(公開されている上位プレイヤーの対戦ログ、9万〜69万件規模)を教師データにしていました。こちらは自前で作った候補、わずか98件でした。桁が3桁以上違います。

これをそのまま社内のコンテンツ生成・企画選定の仕組みに当てはめ直しました。具体的には:

  • AIに記事やLPのコピーを生成させて、AI自身に採点させる → これは「自前候補の自己採点」と同じ構造で、同じ穴に落ちる
  • 直すべきは「教師データをどこから取るか」。外部の実際に伸びている記事・実際に売れている商品・実際に反応の良かった広告コピーを先に集めて、それを基準にする

今はコンテンツ企画を作る/直す/点検するたびに、「教師データの出どころ(外部か自前か)と件数」「重みの出どころ」を必ず書くルールにしています。外部データの列が空のまま着手しない、というのが今の社内ルールです。

つまずいたポイント②: 無人運用でコスト事故を連発した

2つ目の学びは完全に自分たちの失敗です。cronやPM2で無人実行する仕組みを作ったあと、以下のような事故が実際に起きました。

事故 原因 損失/リスク
LLM API費用の想定外課金 Anthropic APIを直接呼ぶコードを従量課金のまま放置 約34万円
Vercelの想定外請求 試作サイトがAIクローラーに1日250万回アクセスされた 高額請求(SNS上の他社事例を見て自社も即点検)
SNS垢のshadow ban 同一アカウントに15分で15件連投 アカウント機能制限
LeRobotの検証タスクが固まった 優先度・並列数を制限せず本番機で実行、CPU使用率が長時間高止まり 朝の定時処理が待ち行列化

ここから作った具体的なルールはこうです。

# 本番機で重い研究・検証タスクを走らせるときは必ずこれを通す
~/bin/research-run -t 7200 -j 2 -- python train.py
# 優先度最低(taskpolicy -b + nice 19)・並列数2・実行時間2時間を既定にする
  • SNS投稿は同一アカウントへの連投を最低15分間隔に強制(スクリプト側でタイムスタンプを見て待たせる)
  • 外部課金APIの新規呼び出しは禁止、使うのはClaude CLIのみに統一
  • 「移管した」と「課金が止まった」を別物として扱う。クラウドサービスの解約は、実際に請求明細の行が消えたことで初めて完了と判定する

無人運転のAIエージェントは便利ですが、人間が見ていない間に起きる事故のパターンはだいたい「連投・過負荷・課金の自動継続」の3つに集約されることが分かりました。

実際に変わったこと(誇張しない範囲で)

正直に書くと、「AI経営OSを入れたら売上が何倍になった」というような話はしません。月商250万という規模感も変わっていませんし、1〜2週間の運用実績が出るまでは「稼働中」と言い切らない、というのを社内ルールにしています(実装が完成しただけで「動いている」と呼ばないようにする、という意味です)。

変わったと言えるのは次のような運用面です。

  • 月次の数字確認にかかっていた作業が、CFOエージェントの異常値レポートを見てから詳細確認する流れに変わった
  • SNS/note投稿の反応を「投稿件数」ではなく「7日後・28日後の反応」「相談への遷移」を別々に記録するようになった
  • コンテンツ企画の品質ゲートを決めて、エンゲージ率(いいね・保存)が弱い記事は次の記事で保存導線を強化する、という改善サイクルを回せるようになった

数字を盛らずに「仕組みが変わった」ことを積み重ねているのが今のフェーズです。

単体テストの考え方をAIエージェントの出力検証に応用する

Zennで『単体テストの考え方/使い方』のエッセンスを解説した記事が日次トレンド上位に入っていましたが、この本の考え方はAIエージェントの出力検証にそのまま使えると感じています。

良いテストの基準として本では「退行(regression)を検知できるか」「保守のコストが低いか」「迅速なフィードバックを返せるか」「誤検知(false positive)が少ないか」が挙げられます。AIエージェントの判断を検証する時も同じ軸で考えられます。

  • 退行検知 → CFOエージェントが前月までは拾えていた異常値を、プロンプトを変えた後に拾えなくなっていないか
  • 誤検知の少なさ → 「正常範囲は報告しない」というルールを入れたのは、誤検知(ノイズ報告)を減らすため。良いテストが些細な差分で落ちないのと同じ発想
  • 迅速なフィードバック → エージェントの判断が速くても、人間が承認するまでのループが長いと意味がない。承認フローそのものを短くする設計にした

Qiitaでも直近はAIタグ・Securityタグの記事がストック数を集めていますが、どちらも「AIが出した結果をどう検証するか」「無人実行の安全性をどう確保するか」という文脈は共通していて、今回の自社の事故経験ともかなり地続きだと感じています。

SES・フリーランスエンジニアはこの変化をどう見るべきか

ここからは本業であるSESの視点を少しだけ。SESエンジニアの実態として、多重下請け構造や単価の不透明さはよく指摘される話ですが、AIエージェントを扱える・無人運用の事故パターンを知っている・検証の考え方を持っている、というスキルセットは案件を選ぶ側の立場に変わる材料になり得ます。

実際にフリーランス案件の探し方として意識しておくとよい視点を整理しました。保存しておいて、案件を見る時のチェックリストとして使ってください。

フリーランス案件を見る時のチェックリスト

  • 業務内容が「AIエージェント/LLM活用」なのか「従来型の保守運用」なのか明確か
  • 無人実行・自動化の範囲に、人間の承認フローが入っているか(入っていない設計は事故リスクが高い)
  • 課金発生する外部APIの利用権限が自分にどこまで渡されるか
  • データ分析エンジニアとして評価されるなら、「教師データの出どころ」を説明できる案件か
  • 単価だけでなく、検証・テストの工程がどのくらい確保されているか

エンジニアとしてのキャリアガイドという意味でも、「AIにやらせる部分」と「人間が検証する部分」の線引きを自分の言葉で説明できることが、これから案件を選ぶ/選ばれる上での差になっていくと感じています。データ分析エンジニアを目指す人にとっても、モデルの性能だけでなく「教師データの質と出どころ」を問える視点は、今回のKaggleの失敗からも裏付けられる実務的なスキルです。

まとめ

月商250万、社員3人の会社がAI経営OSを作った話は、派手な成功談ではなく「候補データの出どころを外部に取り直した」「無人運用の事故パターンを洗い出してルール化した」という地味な積み重ねです。CFO/COO/CMO/CEOというAIエージェントは意思決定を速くする道具であって、魔法ではありません。

SES・フリーランスエンジニアとして次のキャリアや案件を考えるときも、AIエージェントが「何を自動でやり」「どこを人間が検証しているか」を見極める視点を持つことが、実務でも案件選びでも効いてくると思います。

関連記事


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

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

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


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

1
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
1
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?