AI エージェントを CEO 代行として動かす — ClearNets の実践レポート 2026

1. なぜ 2026 年に CEO 代行 AI が現実になったのか

2024 年時点では「AI にコードを書かせる」までが実用領域でした。 しかし 2026 年に入り、Claude Opus 4.7 (1M context) と GPT-5 世代の 登場で、状況が質的に変わりました。何が変わったかを整理すると 3 点です。

• 1M トークン context: 会社全体の state.json (1000 行) + backlog.md (500 行) + 直近 30 日ログ (300 行 × 30 日 = 9000 行) + 全プロダクトの REQ/RES 履歴 (合計 数万行) を「1 回のプロンプトで 全部読ませる」ことが可能になった。人間のマネージャーでもできない 「全プロダクトの状況を同時に把握した判断」ができる。
• ツール実行の安定性: Bash / Read / Write / Grep / gh / vercel / supabase / stripe CLI を安定して連鎖実行できる ようになった。「読んで判断して書いて deploy する」までを 1 セッション で完結できる。
• 並列サブエージェントの実用化: Claude Code の Agent tool や Task tool で、1 つの親 agent が 3-5 体のサブエージェントを 並列起動できる。7 プロダクトを 3 体並列で回せば「1 iter = 1 プロダクト あたり 15 分」で回せる。

逆に 2026 年時点でもまだ AI に任せられない領域があります。(a) 顧客 インタビュー、(b) 対面採用面接、(c) 大型契約の締結、(d) 事業ピボット の意思決定。これらは人間 CEO の一次情報と直感が不可欠で、AI は補助 情報の整理までを担当します。この境界線を明示することが CEO 代行 AI 運用の第一歩です。

2. 前提: 1 人会社 × 7 プロダクトのカオス

ClearNets の運用対象を具体化しておきます。2026-08 時点で稼働している プロダクトは 7 本、それぞれフェーズが異なります。

このカオスを人間 1 人だけで回そうとすると (a) 週次で全プロダクトの 状況を把握できない、(b) タスクの優先順位付けに毎日 1-2 時間消費、 (c) 定常運用 (LP 微修正 / メール返信 / ログ確認) に埋もれて戦略時間が 取れない、という状態に陥ります。AI エージェント CEO 代行はこの問題を 「AI に定常運用を任せて人間は戦略と一次情報収集に集中」で解決します。

3. 運用構造 — ファイルフローで意思決定を回す

ClearNets の CEO 代行 AI 運用は、コードでも SaaS でもなく「Markdown / JSON ドキュメントのファイルフロー」を中心に組まれています。全体像は 以下の通り。

company/
  state.json              # KPI 正本 (cash_jpy / mrr_jpy / burn_jpy_monthly / runway_months)
  backlog.md              # 全社タスク台帳 (ID / Type / Owner / Due / Status)
  overview.md             # 会社概要 + 現在 KPI の説明文
  ROLES.md                # CEO/CFO/COO/CMO/CTO の役割定義
  PLAYBOOK.md             # 日次/週次/月次の運営ルール
  WORKFLOW.md             # REQ/RES ファイルの命名規則
  logs/YYYY-MM-DD.md      # 日次意思決定ログ (Decision / Why / Risk / Next Action)
  templates/              # REQ / RES / 日次ログの雛形
  CEO|CFO|COO|CMO|CTO/    # 部署ごとの input / output / reference
  products/<product>/
    requests/REQ-*.md     # 事業単位の依頼
    outputs/RES-*.md      # 事業単位の成果物
    context.md            # 事業の前提 / 制約 / 現状整理

ファイルの流れは 6 ステップ:

1. state.json と backlog.md、前日ログで現状確認: iter 開始時に必ずこの 3 つを読ませる。1M context なので全て一気に読める。
2. 依頼元が REQ ファイルを作成: 命名規則 REQ-YYYYMMDD-連番-依頼元-件名.md。例: REQ-20260817-001-CEO-習慣トラッカー LP 改修。
3. 担当 AI が RES ファイルを作成: 命名規則 RES-YYYYMMDD-元REQID-件名.md。REQ に対する解決案 / 実行結果 / 数字根拠を残す。
4. 全社判断が必要なものは部署 output/ にサマリ: 複数プロダクトに跨る判断 (例: 予算配分) は CEO / CFO output/ に Decision Memo として集約。
5. logs/YYYY-MM-DD.md に判断を記録: Decision / Why / Risk / Next Action の 4 項目形式で残す。事後レビューで「なぜ この判断をしたか」を追跡できる。
6. backlog.md と state.json を更新: 実行済 task を Done に、新 task を Add、KPI 数値を最新化。

このフローは Notion でも Linear でもなく「素の Markdown / JSON ファイル + git」で運用しています。理由は (a) AI エージェントがどんな 文脈でも読み書きできる、(b) git 履歴で「いつ・誰 (人間 / AI)・何を」 変更したか完全追跡できる、(c) SaaS 依存がないので永続的、の 3 点です。

4. AI ループの実装 — Claude Code + ScheduleWakeup + 並列 agent

フローを回す実装は「Claude Code (親 agent) + ScheduleWakeup (定期 トリガー) + Task tool (並列サブエージェント)」の 3 層で組んでいます。

親 agent: Claude Opus 4.7 (1M context) を Claude Code から呼び出し、CLAUDE.md + memory/MEMORY.md + 対象プロダクトの HANDOFF を最初に読み込む。「今 iter の目的」「対象プロダクト」 「制約」を明確にした後、必要に応じてサブエージェントを起動する。

ScheduleWakeup: Claude Code の deferred tool で、 「6 時間後にこのプロンプトで再起動」を指示できる。CEO 代行ループを 「1 日 4 iter (朝 6 時 / 12 時 / 18 時 / 24 時)」で自律的に回す。 人間が寝ている間も自動で backlog を更新し、翌朝ログを読めば全プロダクト の状況が把握できる状態にする。

並列サブエージェント: Task tool で 3-5 体並列起動。 1 体あたり 1-2 プロダクトを担当し、REQ を作り、RES を書き、logs を 更新する。並列起動の sweet spot は 3-5 体で、それ以上は「衝突コスト > 並列効果」になります。

# 1 iter の典型的な流れ (擬似コード)
1. 親 agent 起動 (Claude Opus 4.7)
2. CLAUDE.md + state.json + backlog.md + 直近 3 日ログ を Read
3. 「今 iter は Merci + Kotodama + OSHITABI の 3 プロダクトに集中」と決定
4. Task tool で 3 体並列起動:
   - agent-merci: LP 微修正 + GTM Phase 2 の SOP 更新
   - agent-kotodama: IAP 導入の残タスク整理 + 決裁ドキュメント作成
   - agent-oshitabi: β招待 第2陣の準備状況確認 + CEO-TODO 更新
5. 3 体の RES を親 agent が集約、logs/YYYY-MM-DD.md に判断記録
6. backlog.md / state.json 更新
7. git add + commit + push (常時許可)
8. ScheduleWakeup で 6 時間後の次 iter をトリガー

この 8 ステップが 1 iter で 30-60 分。1 日 4 iter = 2-4 時間 AI が 動く。人間 CEO は朝 15 分ログを読んで方針の擦り合わせをするだけで、 7 プロダクトの状況が把握できる状態を維持できています。

5. 判断基準の言語化 — CLAUDE.md と PLAYBOOK.md

AI エージェントに「経営判断」を任せるためには、判断基準を事前に 言語化しておく必要があります。ClearNets が CLAUDE.md / PLAYBOOK.md に書いている主要な判断ルールを 5 つ紹介します。

1. キャッシュランウェイ 6 ヶ月未満のときは成長施策より資金繰り 改善を優先: state.json の runway_months < 6 なら、新規施策より収益直結施策 (Merci の営業 / btc-auto-trade の運用) を優先。この 1 行で「危険水域では守りに入る」判断が自動化 される。
2. KPI 未観測の施策は「実験」として小さく着手し、翌日見直す: 効果測定が不明な施策には最大 2-3 時間しか使わない。 翌日 KPI で判断できなければ scope を縮小。「大きく作って失敗」 を回避。
3. 重要判断 (採用・価格改定・大規模投資) は必ずログに根拠を 残す: Decision / Why / Risk / Next Action の 4 項目で 記録。事後レビューで判断精度をトレースできる。
4. AI 依存プロダクトは新規選定時に避ける: LLM / 画像生成 / AI 診断が「コア価値」になる新規 toC 案は原則棄却 (コスト + レッドオーシャン)。既に稼働中の Kotodama を除き、新規は AI をコアにしない方針。
5. ClearNets.Org のコミット / プッシュは常時許可: 意思決定ドキュメントの更新は、都度確認せず commit → push。ただし 「destructive 操作」「外部支出」「セキュリティ・法務」「事業 ピボット」は必ず人間確認を挟む。

この 5 ルールを CLAUDE.md に書いておくと、AI が自律判断する範囲と、 人間確認を挟む範囲が明確になります。運用しながら「あ、この判断は AI に任せすぎた」と気付いたらルールを追記していく。この feedback loop こそが CEO 代行 AI 運用の本質です。

6. 実測結果 — 7 プロダクト同時進行の可能性と限界

2026 年 4 月から 8 月まで 4 ヶ月間、この運用体制で実際に何が起きた かを数字で整理します。

• プロダクト進行数: 7 プロダクト全てで週次以上の 更新が発生。撤退したプロダクトは 0。逆に「深く進んだ」のは 2-3 プロダクト / 週で、残りは維持運用。
• 意思決定ログ本数: logs/ に週 15-25 本の判断 記録が蓄積。従来 (人間のみ運用) の 3-5 本 / 週から 5 倍増。
• REQ / RES ファイル数: 4 ヶ月で REQ 320 本 / RES 290 本。1 REQ あたり平均 200-500 字、1 RES あたり 500-2000 字。 総文書量約 30 万字。
• デプロイ回数: 全プロダクト合計で週 15-30 回。 人間確認を挟む「本番デプロイ」は週 2-5 回、AI 単独で完結する 「文書 commit / LP 微修正」は週 10-25 回。
• 人間 CEO の時間配分: 従来「定常運用 60% / 戦略 20% / 一次情報収集 20%」→ 現在「定常運用 15% / 戦略 40% / 一次 情報収集 30% / AI ループのメタ運用 15%」。戦略時間が 2 倍に増えた。

品質担保は 3 段構え: (1) AI 出力は必ず git 履歴に残る、(2) 人間 CEO が週次で logs をレビュー、(3) 本番影響がある変更は PR ベースで人間 承認。「AI に完全に任せる」のではなく「AI に 8 割任せて 2 割人間が 監査する」設計が現実的です。

限界も明確になりました。(a) 顧客インタビューの本音は AI では拾えない (電話 / 対面で人間 CEO が直接聞くしかない)、(b) 撤退判断は人間の 「もう見切りをつける」直感が必要 (AI は「もう少し伸ばせる根拠」を 探しがち)、(c) 大型契約の締結は人間が最終判断すべき。この 3 領域は 今後も人間 CEO の仕事です。

7. 落とし穴 5 事例 — 実際にハマった問題

4 ヶ月の運用で実際に踏んだ落とし穴を 5 つ、原因と対策で整理します。 新規に CEO 代行 AI を組む方には避けてほしい典型パターンです。

1. 事例 1: 並列 session で backlog ID 衝突 (2026-05)
   症状: 3 体並列 agent が同時に B-565 を採番して 異なるタスクを保存、後段で backlog.md が矛盾状態に。
   対策: backlog ID を「timestamp ベース + 人間が採番」に変更 (例: B-20260517-001)。並列でも衝突しない設計に。
2. 事例 2: prod DB へ AI が直接 DELETE 提案 (2026-06)
   症状: OSHITABI の cleanup 作業で AI が DELETE FROM users WHERE created_at < ... を実行しようとした。context の 取り違えで、本来は seed テーブルへの操作だった。
   対策: 本番 DB への write 権限を AI から剥奪。全ての DML は PR ベースで人間承認 → CI 実行、に変更。破壊的 SQL は CI で block。
3. 事例 3: 認証情報を平文で REQ に書いてしまった (2026-06)
   症状: 依頼書に「Supabase の access token を渡します: sbp_xxxx」と AI が平文で書き、git commit してしまった。
   対策: (a) commit 前の secret scan hook を CI 化、(b) 認証情報は 必ず環境変数 / macOS Keychain 経由、(c) commit 履歴からの削除 手順を PLAYBOOK.md に明記。この事故以来 secret 漏洩は 0。
4. 事例 4: AI が「もう少し伸ばせる」を続けて撤退が遅れた (2026-07)
   症状: とある toC 実験プロダクトで KPI が伸びていないのに、AI が 「あと 2 週間でこの施策を試せば」を繰り返して 6 週間経過。
   対策: 撤退判断は必ず人間 CEO が下す、と CLAUDE.md に明記。「4 週間 継続 KPI 未達なら人間判断を仰ぐ」を PLAYBOOK.md にルール化。
5. 事例 5: 同じ RES を 2 体の agent が別内容で生成 (2026-08)
   症状: 並列起動した 2 体が同じ REQ に対して独立に RES を書き、 後段の親 agent が「どちらが正か」を判断できず立ち往生。
   対策: agent 起動時に「担当プロダクト」を明示的に分離。1 REQ = 1 agent の原則を徹底。親 agent が REQ を配分する際に重複がないか 事前チェック。

8. 費用対効果 — 月 $150-300 で人間 CEO 1 人分

CEO 代行 AI の費用対効果を実測数字で整理します。

• API コスト: Claude Code 経由 Opus + Sonnet 併用で 月 $150-300 (2026-08 実測)。Prompt Caching で 60-80% 節約。
• 人間 CEO 相当の稼働時間: 1 iter 30-60 分 × 4 iter/日 × 30 日 = 60-120 時間/月。時給換算で 3,000 円 / h とすれば 月 18-36 万円相当の稼働。
• 成果物量: 週 15-25 判断ログ + 週 20-30 REQ/RES 文書 + 週 15-30 デプロイ。人間 1 人でこの量を回すのは物理的に不可能。
• 比較: 人間 COO / CFO を雇用: 年収 800-1,500 万円 + 諸経費 = 月 80-150 万円。AI 運用の 200-1000 倍のコスト。

もちろん AI が全ての領域で人間を上回るわけではありません。顧客関係・ 法務判断・採用・大型契約は人間 CEO の担当。ただし「定常運用と文書化」 という「人間の時間を最も食う領域」を AI に完全委任できるだけで、 1 人会社が 7 プロダクト同時運用可能な体制に変わります。

9. 他社に横展開できるか — 一般化の条件

「うちの会社でも CEO 代行 AI を組める?」という質問への答えは 「条件付きで Yes」です。ClearNets の運用が成立している条件を 5 つ 整理します。

• 意思決定を Markdown / JSON ファイルで表現できる: Slack / メール / 口頭で情報が飛び交う会社では AI が context を 追えない。まず文書化文化が必要。
• KPI が数値で追跡されている: state.json のように KPI 正本が 1 ファイルにあり、AI がそれを読んで判断できる状態が前提。
• プロダクトが 3-10 本の範囲: 1-2 本だと AI 委任 のオーバーヘッドが大きすぎて手動のほうが速い。逆に 20 本超えると 並列 agent でも context が破綻。3-10 本が sweet spot。
• 人間 CEO が「AI を監査する」時間を週 5-10 時間確保できる: 完全放任ではなく、必ず人間レビューが必要。この時間を 取れないなら AI 委任は不可能。
• 「AI がミスする前提」で権限設計できる: 本番 DB write 権限剥奪 / destructive 操作 block / secret 平文 push 検知、 といった安全設計を初期構築できるチームが必要。

これら 5 条件を満たせる会社は、CEO 代行 AI 運用で人的リソースを 劇的に効率化できる可能性が高いです。逆に条件を満たせない会社は、 まず「意思決定の文書化」「KPI 一元化」から着手するのが順序として 正しいです。

10. まとめ — CEO 代行 AI は「マネジメントの民主化」

AI エージェント CEO 代行の本質は「経営判断の高速化」ではなく、「1 人でも複数プロダクトを回せるマネジメント体制」の民主化だと ClearNets は考えています。これまで「社員 5 人 + マネージャー 1 人」 が必要だった規模の事業運営が、1 人 + AI で可能になる。これは個人開発者・ 小規模チーム・スタートアップにとって、事業の複数持ちが現実的な選択肢に なることを意味します。

一方で「AI に任せれば楽」ではありません。CLAUDE.md / PLAYBOOK.md の言語化、権限設計、週次レビュー、フィードバックループ、と設計と 運用に手間はかかります。ただしこの手間は「1 プロダクトを増やすたびに 線形に増える」のではなく「一度組めば横展開で済む」性質のもの。 投資対効果は極めて高いです。

ClearNets はこの運用体制で 7 プロダクトを回しながら、次のプロダクトを 検討する余地も作れています。CEO 代行 AI は「経営者を置き換える」 ものではなく、「経営者が本当にやりたい仕事 (戦略 + 一次情報収集) に 集中できるようにする補助脳」として機能する、というのが 4 ヶ月の 運用で得た結論です。

11. FAQ

本記事の要点を 10 問の FAQ にまとめました。JSON-LD の FAQPage 構造化データも埋め込んでいるため、Google 検索でリッチリザルト表示の 対象になります。

Q1. AI エージェントを CEO 代行として動かすのに、どのモデルを使っていますか?

ClearNets の運用では Claude Opus 4.7 (1M context) を主軸にしており、 Claude Code を通じて呼び出しています。1M トークンの長文コンテキストが 「7 プロダクト分の state.json + backlog + 直近ログ + REQ/RES を一気に 読ませる」用途に噛み合うためです。並列サブエージェント (Claude Sonnet 4.5 や GPT-5 系) を作業レイヤーで併用しますが、最終的な意思決定は Opus に集約する設計です。モデル選定の基準は (a) 長文コンテキストの サイズ、(b) 複数ステップの計画能力、(c) tool use の安定性、の 3 点です。

Q2. API コストはどれくらい掛かっていますか?

ClearNets の実測で、Claude Code 経由の Opus + Sonnet 併用で月 $150-300 レンジで動いています。iter (1 ループ) あたり 3-5 サブ エージェント × 20-40 分 × 平均 100k input tokens / 15k output tokens で、1 日 5-8 iter 回すと $10-20/日。Prompt Caching で 60-80% 節約 できるので、CLAUDE.md / state.json / backlog.md といった「毎回 読み込む固定資産」は必ずキャッシュ対象にする設計です。人間 CEO を 雇うと年 1,500 万円以上かかるので、$3,000/年 程度で回るなら費用対 効果は劇的に高い。

Q3. セキュリティは大丈夫ですか?認証情報の扱いは?

認証情報 (API key / DB password / OAuth token) は AI エージェントに 直接渡さず、環境変数 + macOS Keychain + 1Password CLI 経由で必要時 のみ読み出す設計です。ClearNets の運用ルールでは (1) 本番 DB への 書き込み権限を持つ token は AI が直接扱わない、(2) 決済・法務・採用系 の外部 API 呼び出しは人間 (CEO) が明示承認、(3) git push --force や DROP TABLE 相当の destructive 操作は Claude の hook で禁止、の 3 点をシステム的に強制。 読み取り専用の分析やドキュメント作成は自由に任せる一方、書き込みは 限定範囲、という粒度で運用しています。

Q4. AI が判断ミスした時の責任は誰が取るのですか?

全ての最終責任は人間 CEO にあります。AI エージェントは「提案 + 実行」 を担当しますが、判断のログは全て company/logs/YYYY-MM-DD.md に Decision / Why / Risk / Next Action の形式で残されているため、 事後のレビューで人間が「この判断は自分の方針とズレていた」と特定 できる仕組みです。実運用では週次で人間 CEO がログをレビューし、 方針とズレた判断があれば CLAUDE.md や PLAYBOOK.md にルールを追記して 次回以降の判断基準に反映。この「AI 判断 → 人間レビュー → ルール追記」 のフィードバックループがあるので、時間経過と共に AI の判断精度が 上がっていきます。

Q5. 人間はどこで介在するのですか?完全に AI 任せですか?

完全 AI 任せではありません。人間 (CEO) が必ず介在するポイントは (1) 大規模投資 (100 万円以上の外部支出)、(2) 採用・解雇、(3) 価格 改定、(4) セキュリティ / 法務関連、(5) 事業ピボット、(6) 週次 KPI レビュー、の 6 点です。逆に「日次のドキュメント整理」「backlog の 優先順位付け」「LP 文言のリライト」「バグ修正 PR の作成」「実験施策 の設計」といったオペレーションレベルは AI に任せています。この 線引きを PLAYBOOK.md に明文化することで、AI が越境しない安全設計が 成立しています。

Q6. 1 人会社で 7 プロダクトを本当に同時進行できますか?

できています。ClearNets は 2026-08 時点で Merci (チップ決済 SaaS) / Kotodama (AI 占い) / OSHITABI (推し活遠征) / Kotsukotsu (習慣 トラッカー) / btc-auto-trade (BTC 自動売買) / paircon (家族見守り) / revenue-engine (対外営業 SaaS) の 7 プロダクトを 1 人 + AI で本番 運用しています。ただし「全てが同じ強度で進む」わけではなく、フェーズ (探索 / 検証 / 本番運用 / 撤退判断) を明示的に分けて、その時の フォーカスは 1-2 プロダクトに集中させます。他プロダクトは AI エージェントに定常運用を任せ、週次で状況把握するだけ、という設計です。

Q7. AI エージェントの意思決定速度は人間より本当に速いですか?

特定のタスクでは劇的に速いですが、全てで速いわけではありません。 速い領域は (a) 大量の文書を横断して整理する、(b) 既存パターン (過去の LP / メール / SQL) から派生を生成する、(c) 24 時間動ける (人間の睡眠時間中も進む)、の 3 つ。逆に人間のほうが速い / 精度が 高い領域は (a) 顧客との対話から本音を引き出す、(b) 直感的な優先度 判断 (どの顧客が本気か / 撤退のタイミング)、(c) 法務・税務・採用の 重み判断、です。ClearNets の実測では「Docs 作成 + 定常運用」は AI が 5-10 倍速、「戦略判断」は人間が 2-3 倍精度、というレンジ感でした。

Q8. 並列で 3-5 体の agent を回すと何が起きますか?

生産性は 2-3 倍に上がりますが、必ず衝突と重複が発生します。ClearNets の実運用で頻発するのは (1) 同じ backlog ID を 2 つの agent が割り 当てて衝突、(2) 同じ merge conflict を 2 つの agent が別々の解決策 で解いて後段で再衝突、(3) 同じ RES ファイルを別内容で 2 つ生成、 の 3 パターン。対策として (a) backlog ID は timestamp ベースで人間が 採番、(b) agent 間で担当プロダクトを重複させない、(c) merge は必ず 1 体の agent に集約、というルールを PLAYBOOK.md に書いています。 3-5 体は sweet spot で、それ以上並列化すると調整コストがリターンを 上回ります。

Q9. prod DB へのアクセス権はどう管理していますか?

本番 DB (Neon / Supabase) への直接接続は AI エージェントに与えて いません。代わりに (1) 読み取り専用の分析用 replica を作り、そこにだけ read-only role を発行、(2) 書き込みが必要な運用スクリプトは必ず PR ベースで人間承認後にマージ → CI が実行、(3) 破壊的 SQL (DROP / TRUNCATE / DELETE without WHERE) は CI レベルで検知して block、 の 3 段構えです。過去に AI エージェントが DELETE FROM users を提案したことがありましたが (context の取り違えで)、これが block されていたので実害は 0 でした。 設計時点で「AI は完璧ではない」前提で権限を絞る発想が重要です。

Q10. AI エージェント運用を始めるなら、どこから手をつければ良いですか?

3 ステップで始めるのが失敗しにくいです。(1) まず CLAUDE.md 相当の 「AI 向け前提共有ドキュメント」を書く。会社の目的・現在の KPI・ 意思決定ルールを 1,000-2,000 字で言語化。(2) 次に定常運用の中で 「毎日 30 分以上かかっている作業」を 1 つ選び、それを AI に任せる 設計を試す (例: 日次ログ作成 / competitor 記事の要約 / 未対応 Issue のトリアージ)。(3) 最後に週次で AI のアウトプットをレビューし、 ルールを追記して精度を上げるフィードバックループを回す。最初から 「CEO 代行」を目指すのでなく、「秘書」→「マネージャー」→「代行」と 段階的に権限拡大していくのが安全です。