Claude Codeで「AI社員」を雇って会社経営してみた — 理想と現実の話

★ 0
🎧 この記事を音声で聴く（10:20）

「AIが10億ドル規模の一人会社を生む」。Forbesにそんな記事が載る時代です。ワクワクしますよね。

僕もそうでした。Claude Codeのディレクトリ構造を使って仮想会社を作り、秘書・CEO・各部署をAIエージェントとして定義する。フォルダが組織図になり、CLAUDE.mdが就業規則になる。面白そうだと思って、実際に構築してみました。

結論から言うと、仕組みとしては動きます。でも「これで何でもできる」かと言うと、そうでもなかった。今回は、構築から分析まで1日かけて分かったことを正直に書きます。

きっかけ

以前からClaude Codeのエージェント機能には興味がありました。きっかけは、しんコード（ShinCode）さんの「クロードコードで会社経営してみた」という動画。Claude Codeのディレクトリ構造で仮想会社を構築し、各部署にCLAUDE.mdでルールを定義するというアプローチです。

フォルダが部署、マークダウンが業務マニュアル。エンジニアとしてはかなり直感的で、「これは試してみたい」と思いました。

まず5つのリサーチエージェントを走らせた

構築する前に、まず調べました。Claude Codeのエージェント機能を使って、5つのリサーチを同時並列で走らせます。

1. GitHubの既存スキル（cc-company、cc-secretary等）の設計パターン
2. ビジネス自動化の先行事例（solopreneur-plugin等）
3. Claude Codeの公式アーキテクチャ仕様
4. ビジネス向けMCPサーバーの調査（Notion MCP、Slack MCP等、約50サーバー）
5. AIエージェント経営の成功・失敗パターン（McKinsey、ChatDev等）

5つのエージェントが同時に動いて、約10分で包括的な調査が完了しました。一人でやったら半日はかかる量です。この「並列リサーチ」の体験自体が、エージェント経営の強さを実感する最初のポイントでした。

得られた重要な知見

調べてみて特に刺さったのは、McKinseyのレポートです。50以上のAIエージェントプロジェクトを手がけた結果として、こう言っています。

> 「エージェントではなく、ワークフローに焦点を当てよ」

いきなり全部署を作るのではなく、まず秘書1人から始めて、本当に必要になったら部署を増やす。秘書ファーストアプローチ。これはかなり腑に落ちました。

構築してみた

リサーチを踏まえて、独自のアーキテクチャを設計しました。既存のcc-companyスキルをそのまま使うのではなく、自分の既存資産（ジャーナル、ニュース収集システム、開発プロジェクト群）との連携を最初から組み込む形です。

.company/
├── CLAUDE.md          # 組織ルール（60行）
├── secretary/         # 秘書室
│   ├── CLAUDE.md      # 秘書の性格・役割
│   ├── inbox/         # メモ・思いつき
│   ├── todos/         # タスク管理
│   └── notes/         # 相談メモ
├── ceo/               # CEO（振り分けロジック）
│   ├── CLAUDE.md
│   └── decisions/
└── reviews/           # 週間レビュー

12ファイル、CLAUDE.md合計約130行。Claude Codeの「CLAUDE.mdは200行以下が最適」というベストプラクティスに収めました。

VSCodeで /company と打つと秘書が起動して、ダッシュボードを出してくれる。TODO管理もメモもここから。「フォルダが会社」という感覚は、実際に触ると想像以上に自然でした。

155業界で「使えるか」を検証した

ここからが今回の本題です。

「エージェント経営」って、どんな業界で本当に使えるのか。漠然と「便利そう」で終わらせたくなかったので、155の業界を一つずつ分類しました。飲食でも定食屋とスナックは違うし、医療でも病院と薬局は違う。そのレベルで細かく見ています。

結果はこうなりました。

分類件数割合
活用できる6743%
活用できない4932%
判断不明3925%

半分以下。「何でも使える」わけではない。（全155業界の分類リストはこちら）

活用できる業界に共通しているのは、PC中心で、情報のハブとして機能する仕事です。IT、コンサル、クリエイティブ、教育。逆に、物理的な作業が中心の製造・建設・飲食は厳しい。

面白かったのは総合商社の考察です。商社は「製造業」や「小売業」ではなく、情報のハブとして機能している。つまり業界ではなく、その業務の性質（情報中心か物理中心か）で分類した方が正確なんですよね。

28のマネタイズモデルを洗い出して、ほとんど消えた

次に「このアーキテクチャで直接お金を稼げるか」を調べました。4つの並列リサーチエージェントで28のビジネスモデルを特定しました。テンプレート販売、コンテンツ量産、SaaS開発、コンサル、コミュニティ運営…。

一見すると夢のある話です。でも、ここからが大事でした。

3つの「疑い」をかけてみた

28モデルに対して、こんな問いを投げました。

1. 本当にそんなに簡単？ — 「誰でもできる」と言われるものは、参入障壁が低い分レッドオーシャンになりやすい
2. わざわざお金を払う？ — AIの普及で「自分でできること」が増えている。無料で手に入る情報にお金を出す人がいるか
3. 品質は担保できる？ — AIが生成したものを売るとき、本当に対価に見合う品質を維持できるか

この3つのフィルターを通すと、28モデルのうち検証に耐えるのは以下の7〜8程度でした。

モデルなぜ残るか
マイクロSaaS開発「動くプロダクト」はAIにコピーされない
AI戦略コンサルティング信頼関係と実務経験がベース
企業向けエージェント経営導入コンサル導入支援は人間の伴走が必要
サブスクリサーチサービス独自の切り口・一次情報が価値になる
業界特化リサーチレポート販売専門領域の深い分析は模倣困難
コーチング×エージェント自動化人格・信頼関係がスケールの核
トレンド商品リサーチ×EC最終的に物理商品を届ける
補助金・助成金申請代行専門知識＋成果報酬の信頼モデル

逆に消えたのは、テンプレート販売、デジタルコンテンツ量産、SEO記事、電子書籍など。「AIで作れるものは、誰でもAIで作れる」。参入障壁がないものは、すぐにレッドオーシャンになります。

AIが代替できない価値は4つだけ

整理していくと、AIの普及後も価値が残るものは4カテゴリに集約されました。

カテゴリ例
物理商品製造、物流、飲食
人格・信頼コーチング、コンサル（信頼関係ベース）
ソフトウェアマイクロSaaS（動くプロダクト）
一次情報独自データ、実体験に基づくレポート

逆に言えば、「情報そのもの」の価値はAIの普及で急速に下がっています。コンテンツ量産、SEO記事、テンプレート販売。これらは構造的に厳しくなっていく。前回の記事で書いた「定型業務がAIに代替される」という話と、根っこは同じです。

「それ、スクリプトで良くない？」

さらに深掘りして気づいたことがあります。

たとえばドロップシッピング。リアルタイムで市場データを収集して、トレンド商品を自動で出品する。FXでもリアルタイム情報収集と自動売買。AIと相性が良さそうに見えます。

でも、ここで根本的な問いが浮かびました。

「秘書→CEO→部門」という組織構造が、本当に必要か？

単一の自動化タスク（価格モニタリング→出品、為替分析→売買）であれば、Pythonスクリプト1本で十分です。わざわざ「PM部門」「リサーチ部門」「開発部門」を置く必要がない。

エージェント経営のアーキテクチャが本当に必要になるのは、複数の異なる業務を1人で並行管理する状況だけです。ジャーナルの執筆と、クライアントワークと、SaaS開発と、コミュニティ運営を同時に回す。そのくらいの複雑さがあって初めて「組織」が必要になる。BCGのレポートでも、エージェントAIが真に効果を発揮するのは「複数のワークフローを横断的に統合する場面」だと指摘されています。

正直な結論

「AIで一人経営」という言葉は魅力的です。でも1日かけて真剣に分析してみた結果、こう思いました。

エージェント経営は「稼ぐ手段」ではなく、「複雑な一人経営を整理するOS」。

会社経営ごっこが楽しいのは間違いありません。フォルダが組織図になる面白さ、秘書に話しかける体験、並列リサーチの圧倒的な速さ。技術的にはとてもワクワクします。

ただ、「これで何でも稼げる」は幻想です。AIが代替できない価値（物理商品、人格・信頼、ソフトウェア、一次情報）を持っていなければ、いくら仕組みを整えても売るものがない。

今の僕にとっては、このアーキテクチャはすぐに必要なものではありませんでした。でも、将来的に複数の事業を並行して回す段階に入ったら、間違いなく活きてくる仕組みだと思います。

構築プロセスは面白かった

ネガティブなことばかり書きましたが、構築のプロセス自体はかなり楽しかったです。

– 並列リサーチの威力: 5エージェント同時起動で10分調査完了。これは純粋にすごい
– McKinseyの知見: 大企業のAI導入教訓が、個人開発にもそのまま使える
– 「秘書ファースト」の合理性: いきなり全部署を作らない。まず1人から。これはソフトウェア開発の「YAGNI（You Ain’t Gonna Need It）」と同じ考え方
– Remote Controlでどこからでもアクセス: PC、ブラウザ、スマホの3デバイスから秘書に話しかけられる
「使えるかどうか」と「面白いかどうか」は別の話なんですよね。仕組みとしては面白い。ただ、それを「経営」と呼ぶには、まだ乗せるべきビジネスの中身が必要です。

まとめ

Claude Codeでエージェント経営を構築してみて分かったこと。

1. 155業界を分析した結果、活用できるのは43%。PC中心・情報ハブ型の業務に限られる
2. 28のマネタイズモデルのうち、批判的に検証して残るのは7〜8。「情報の価値」はAI普及で急速に下がっている
3. AIが代替できない価値は4カテゴリのみ: 物理商品、人格・信頼、ソフトウェア、一次情報
4. 単一業務の自動化にはオーバースペック。「それ、スクリプトで良くない？」という問いに答えられるか
5. エージェント経営の本質は「稼ぐ手段」ではなく「複雑な一人経営を整理するOS」

ワクワクから始まって、冷静な結論に着地しました。でも、こういう「やってみて分かった」プロセスが大事だと思っています。

次に複数事業を並行して回す段階が来たら、この仕組みを本格稼働させるつもりです。そのときはまた書きますね。

この記事が参考になったら

Share