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?

社員3人・月商250万円の会社がAI経営OSを作った実装記

1
Posted at

月商250万、社員3人。経営の「詰まり」はどこにでもある

2026年10月現在、うちの会社は社員3人、月商およそ250万円の小さな会社です。経理担当は私が兼任、営業資料は代表がExcelで手打ち、月次の数字は税理士に渡す前に自分でダブルチェック――という、スモールビジネスにありがちな体制でした。

人を増やす余裕はない。でも経営の意思決定に使う時間は増やしたい。そこで「CFO」「COO」「CMO」「CEO補佐」役のAIエージェントを並べて動かす社内の仕組み、いわばAI経営OSを、Claude Codeをベースに自作しました。この記事では、構築の手順、実際につまずいた箇所、そして導入後に体感した変化を、できるだけ具体的に書きます。

SESでエンジニアとして働いている方、これからフリーランスとして独立しようとしている方にとっても、「小さな会社がAIで何をどう自動化しているか」は独立準備やデータ分析スキルの参考になるはずなので、終盤ではその視点にも触れます。

AI経営OSの全体構成

「AI経営OS」と呼んでいますが、やっていることはシンプルです。Claude Codeのサブエージェント機能を使って、役割ごとにプロンプトと権限を分離しただけの構成です。

エージェント 役割 主なインプット 権限
CFOエージェント 資金繰り・請求管理のチェック 会計データ、入出金CSV 読み取りのみ
COOエージェント 業務プロセスの進捗管理、タスク棚卸し タスク管理ツールのAPI 読み取り+ステータス更新
CMOエージェント コンテンツ企画・トレンド分析 Qiita/Zennのトレンド、自社記事のPV 下書き作成のみ(公開は人間承認)
CEO補佐エージェント 週次の意思決定サマリー作成 上記3エージェントの出力 読み取りのみ

重要なのは、どのエージェントも「実行」権限を持たせていない点です。CFOエージェントが勝手に振込を実行する、CMOエージェントが勝手にSNSへ投稿する、といった事故を避けるため、生成は自動・実行は人間承認を徹底しています。これは一度、投稿の自動化で痛い目を見た経験からの学びでもあります(後述)。

構築ステップ1: 役割定義をCLAUDE.mdに書く

Claude Codeはプロジェクト直下のCLAUDE.mdを読み込んで振る舞いを変えてくれるので、エージェントごとにディレクトリを分けて、それぞれにCLAUDE.mdを置きました。

# CFOエージェント設定 (finance/CLAUDE.md)

## 役割
あなたは当社のCFO補佐です。資金繰り・請求状況を毎週チェックし、
リスクがあれば数値で指摘してください。

## 絶対ルール
- 振込・送金の実行は行わない(読み取りと提案のみ)
- 数値は必ず実データ(会計CSV・入出金明細)から算出する
- 推測値を使う場合は「推測」と明記する
- 出典のない統計・予測を断定形で書かない

この「絶対ルール」の書き方がかなり重要で、最初は緩く書いていたら、CFOエージェントが根拠薄弱な「来月は黒字化します」的な楽観的コメントを出してきたことがありました。断定を避けさせる一文を足してから、だいぶ落ち着きました。

構築ステップ2: データ基盤に「軽量ベクトル検索」を足す

CMOエージェントに過去記事や社内ナレッジを参照させたくて、最初はSupabaseのpgvectorを検討していました。ただ、小さな会社がマネージドDBを増やすとコスト管理の手間が増えるので、今回は見送り、SQLite側の動きを追うことにしました。

ちょうど今週、Zennの日次トレンドで「SQLite本体にベクトル検索拡張 vec1がやってきた」という話題が上位に来ていて、これがタイミング的にハマりました。ローカルの単一ファイルDBのまま埋め込みベクトルを扱えるのは、社内ナレッジ検索程度の規模には十分すぎるスペックです。

-- イメージ(実際のAPIは拡張のバージョンにより変わるため公式ドキュメントで要確認)
CREATE VIRTUAL TABLE knowledge_vectors USING vec1(
  embedding float[1536]
);

INSERT INTO knowledge_vectors (rowid, embedding)
VALUES (1, :embedding_json);

SELECT rowid, distance
FROM knowledge_vectors
WHERE embedding MATCH :query_embedding
ORDER BY distance
LIMIT 5;

Postgres+pgvectorのような運用コストをかけずに、CMOエージェントの「過去にこういう企画はやったか」を調べるリクエストに応えられるようになったのは地味に大きい変化でした。小規模な会社がAI経営基盤を作るなら、まずは重いマネージドDBより軽量な構成から試すのが現実的だと感じています。

つまずいたポイント1: 権限設計とセキュリティ

Qiitaでは直近2週間、Securityタグを付けたストック20超の記事が7本も出ていて、AIエージェントの権限管理に関心が集まっているのを実感します。うちでも最初の設計ミスがありました。

最初、すべてのエージェントに同じAPIキー・同じ権限セットを使い回していたのですが、これだとCMOエージェントの誤作動がCFOデータにまで影響を及ぼしかねない構成になっていました。対策として以下を徹底しました。

  • エージェントごとにAPIキー・トークンを分離する
  • 「実行」権限が必要な操作(送金・投稿・デプロイ)は必ず人間承認を挟む
  • 無人実行(cron経由)するタスクは読み取り専用に限定する
  • SNS投稿など対外的に見える操作は、同一アカウントへの連投間隔を必ず空ける運用ルールを明文化する

特に最後の「連投間隔」は、過去に外部で短時間の連続投稿がプラットフォーム側のシャドウバン判定を招いた事例を聞いてから、社内ルールとして明文化しました。AIで自動化すること自体がリスクなのではなく、実行権限の設計を詰めずにスケールさせることがリスクだと学びました。

つまずいたポイント2: コストの見えない増殖

2つ目の詰まりはコスト管理です。複数のAIエージェントを並列で動かすと、API呼び出しの回数が想定以上に増えます。うちでは「有料LLM呼び出しはClaude Codeに統一し、従量課金APIを個別に増やさない」というルールを決めて、コストの見通しを立てやすくしました。

加えて、研究用途の重い処理(トレンド分析のバッチなど)は本番の経営OSとは別プロセス・低優先度で動かすようにして、本番の判断業務を止めないようにしています。経営判断に使うエージェントが、裏側のバッチ処理の負荷で遅延する、という事故を未然に防ぐための切り分けです。

実際の効果(導入後まだ1〜2ヶ月の暫定値)

正直に書くと、運用期間はまだ1〜2ヶ月程度で、長期の実績として語れる段階ではありません。それを踏まえた上での体感ベースの変化です。

項目 導入前 導入後(暫定)
月次の数字チェックにかかる時間 半日〜1日 数時間程度に圧縮(体感)
企画のトレンド調査 手作業でQiita/Zennを巡回 エージェントが候補を下書きまで作成、人間が選別
意思決定の情報収集 都度バラバラに確認 週次サマリーに集約
運用上のインシデント − 権限設計ミス1件(対処済み)

「稼働中で安定している」と言い切るにはまだ早く、しばらく運用実績を積んでから改めて検証記事を書くつもりです。ただ、少なくとも情報を集める手間は明確に減りました。

Claude Code・Copilot・Cursor、マルチエージェント構築にどれが向くか

今回のようにプロジェクト単位でエージェントの役割・権限を分離したい場合、どのAIコーディングツールが向いているかも整理しておきます。

観点 Claude Code GitHub Copilot Cursor
プロジェクト単位の設定ファイル CLAUDE.mdで役割・ルールを明文化しやすい リポジトリ横断の設定は限定的 ルールファイルで近いことが可能
サブエージェント/権限分離 ディレクトリ単位で分離しやすい 単一アシスタント的な運用が中心 拡張で近い構成を組める
CLI/無人実行との相性 cron連携など自動化がしやすい 基本はエディタ内利用が中心 エディタ内利用が中心

価格体系は各社とも変わりやすいので、具体的な金額はここでは書かず、必ず公式サイトの最新情報を確認してください。うちが今回Claude Codeを選んだ決め手は、設定ファイル(CLAUDE.md)でルールを明文化しやすく、無人実行(cron)との相性が良かった点です。

フリーランス・独立準備の視点から見た「AI経営OS」

ここからは少し視点を変えて、SESで働いているエンジニアや、これからフリーランスとして独立を考えている人向けの話です。

今回のような「AI経営OSの構築」は、実は個人がフリーランスとして独立する準備にもそのまま応用できます。独立すると、経理・営業・企画・進捗管理を全部自分でやることになるからです。

  • データ分析の視点:自分の稼働時間と単価、案件の継続率を数値で管理できるようにしておくと、後から「どの種類の案件が割に合っていたか」が見えるようになります
  • フリーランス 案件 探し方の観点:エージェント経由だけでなく、技術記事(Qiita/Zennなど)での発信実績が、直接契約の問い合わせにつながることがあります。今回のCMOエージェントのような「トレンド調査→下書き作成」の仕組みは、個人の発信の下準備にも転用可能です
  • エンジニア 独立 準備として最初にやるべきこと:いきなり全部自動化しようとせず、まず「自分が何にどれだけ時間を使っているか」を記録するところから始めるのが現実的です

一方で、SESから独立する際のリスクも無視できません。契約が切れた瞬間に収入がゼロになる、確定申告や社会保険の手続きを自分で把握する必要がある、営業活動の時間が増える分だけ稼働できる時間が減る、といった点は、独立前に必ずシミュレーションしておくべきです。「うまくいった話」だけでなく、こうしたリスク側の検討もセットで準備することをおすすめします。

保存版チェックリスト:AI経営OSを作る前に確認すべき項目

最後に、同じようにAIエージェントで経営の仕組みを作ろうとしている方向けに、着手前のチェックリストをまとめておきます。ブックマーク・保存しておいて、着手前に見返してください。

  • エージェントごとに役割と「やらないこと」を明文化したか
  • 実行権限(送金・投稿・デプロイ)と読み取り権限を分離したか
  • APIキー・トークンをエージェントごとに分けたか
  • 無人実行(cron等)するタスクは読み取り専用に限定したか
  • SNS投稿など対外的な自動化は、公開前に人間承認を挟む設計にしたか
  • 有料API呼び出しの増殖を防ぐルール(ツールの統一など)を決めたか
  • 本番処理と研究・バッチ処理のプロセスを分離したか
  • 断定表現を避け、推測値には「推測」と明記するルールをエージェントに持たせたか
  • 「実装完了」と「運用実績あり」を混同せず、運用期間を記録しているか
  • 権限設計のインシデントが起きた場合の対処フローを決めてあるか

まとめ

月商250万円、社員3人という小さな体制でも、Claude Codeベースのマルチエージェント構成であれば、CFO/COO/CMOといった役割分担をAIに持たせることは十分に可能でした。ただし、権限設計を詰めずにスケールさせると事故につながるという点は、強調しておきたいところです。

今回紹介したのはまだ運用1〜2ヶ月の暫定的な結果です。今後、半年・1年単位の運用実績が積み上がった段階で、改めて効果検証の記事を書く予定です。

関連記事


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?