この記事はこんな人におすすめ
・ChatGPTを毎日触っているのに「結局チャットしただけ」で終わってしまう人
・Claude Codeの名前は聞いたが、自分で何を任せていいか掴めていない人
・AI副業で動き出したい、でも「1人で全部やる」前提から抜け出せない人
はじめに
半年前、僕は「AIで稼ぐ」と検索しては、似たような副業ノウハウを延々と読んでいた。
ブログを書け。アフィリエイトをやれ。プロンプト集を売れ。書いてある内容はそれぞれ正しい。けれど、読み終わると毎回「で、自分は明日何をやるんだ？」という同じ場所に戻された。
転機はClaude Codeに触った日だった。
ChatGPTが「答えをくれるAI」だとしたら、Claude Codeは「実際に手を動かしてくれるAI」だ。コードを書く。ファイルを保存する。テストを回す。商品ページを起こす。一連の作業を、ターミナルの中で勝手に進めてくれる。
ここで気づいた。AIが1台では限界がある。けれど29台を「6部門の組織」として動かすと、人間のチームと同じように動く。
その仕組みでデジタル商品の企画→開発→出品→販売を回した結果、月商は85万円、累計は110個を超えた。
人間の僕がやることは、最終的なGo/No-Goを押すことと、AIが詰まった時に方向性を直してあげることだけ。1日の作業時間は2時間以内に収まっている。
この記事は、その「29台の運営OS」の設計図をそのまま開く内容になっている。
いま伸びているのは「AIを使う人」ではなく「AIを組織化する人」
AIツールは毎週新しいものが出てくる。最新ツールを追いかける情報収集は楽しい。けれど追いかけ続けても収益化には届かない。
伸びている個人運営者はみんな、こう動いている。
・AIを「ツール」ではなく「役割を持った社員」として扱う
・1台のAIに全部やらせず、部門ごとに分担させる
・人間は最後の判断と、AIが詰まった時の方向修正に時間を使う
ChatGPTに10通り聞いて疲れていた頃の自分と、いま運営している自分の差は、能力ではない。AIに役割と境界線を渡したかどうか、それだけだ。
1台運用が破綻する3つの理由
1. 文脈が長くなると判断がブレる
1台のAIにリサーチも企画も実装もやらせると、会話履歴が膨らみすぎて、後半の判断精度が落ちる。これは性能の問題ではなく構造の問題で、別の役割は別のセッションで動かす方が速い。
2. レビュー機能が成立しない
作った当人がレビューすると、自分の前提を疑えない。同じAIに「厳しく見て」と頼んでも、優しい指摘しか返ってこないことが多い。作る側と見る側を分けるだけで、品質は段違いに上がる。
3. 進捗が見えず、止め時を見失う
1本の長い会話で全部やると、どこまで終わってどこで詰まったかが追えない。気づいたらAIが2時間同じエラーを叩き続けている、という暴走が起きる。部門ごとにタスクを切り分けると、止め時の判断が機械的にできるようになる。
このまま「1台で全部やる運用」を続けると起きること
AIは進化を止めないし、後発で組織化に踏み切る人は毎月確実に増えている。
「ChatGPTを使い始めた」だけで差別化できた時代はもう過ぎた。これから先は「AIを部門化して回している」人たちが、コンテンツ・商品・SaaSのどの戦場でもアウトプット量で押してくる。
1台ですべてを抱える運用のまま半年が過ぎると、自分の手元に残るのは「いっぱい試したけど何も完成していない」という感覚と、月数万円のサブスク代だけになる。
1日2時間で回すための分岐点
逆に、29台を6部門に組織化した運用に切り替えると、毎日の現実はこう変わる。
・朝、Claude Codeに「今日のタスクを整理して」と1行投げる
・出てきたタスクのうち、Goサインを出すべきものに「OK」と返すだけで作業が走り出す
・自分は別のことをしていて、進捗が止まった時だけAIから報告が上がってくる
・夜、1日分の振り返りをAIにまとめさせ、翌日のキューに積んで終了
この設計に切り替えてから、僕の作業時間は1日8時間から2時間まで落ちた。それでも商品は出続け、月商はむしろ上がった。
部門化して最初の10日で起きた3つの変化
組織化に踏み切ってから、最初の10日で自分の体感は明確に変わった。
・判断の数が激減した
1台運用の頃は1日200回ほど「次に何をするか」を自分で決めていた。部門化した後は、各部門が自律で判断するので、自分の判断は1日30〜40回に絞られた。判断疲れという言葉の重さは、減ってから初めて分かる。
・作業の取りこぼしがなくなった
部門間ハンドオフをJSONで揃えるようにしてから、「誰がボールを持っているか」が一瞬で見えるようになった。「やったつもりで実は止まっていた」というあの嫌な発見が消えた。
・失敗が資産になり始めた
失敗ログをスキルファイルに昇格させるルールを入れたら、同じ失敗を二度繰り返さなくなった。半年もすると「自分専用の運営マニュアル」が分厚く育ち、新しい商品の立ち上げ時間が体感で半分以下になる。
この記事で渡すもの
ここから先の有料パートでは、29台のAIを6部門に組織化して回すための具体的な設計図を全部開く。
・6部門の役割マトリクス（部門名・担当範囲・主要AI・成果物）
・Claude CodeをCOOとして使う5つの実プロンプト
・スキル蓄積のテンプレート（毎日の作業を資産化する方法）
・商品開発7ステップと、それぞれで使うプロンプト
・サーキットブレーカー（AI暴走を機械的に止める安全装置）の設定
・部門間のハンドオフJSON仕様
・月次コスト構造の分解表
・ROI判定マトリクスと撤退ライン
・1日のタイムライン（朝起きてから夜寝るまで）
読み終わった時に、明日から自分の運営に組み込めるレベルまで、テンプレートとそのまま使えるプロンプトを揃えてある。
叶った後の毎日
29台の運営OSが回り始めると、平日朝の自分の役割はこう変わる。
「企画が出る」「実装が進む」「品質チェックが走る」「商品ページが完成する」「出品される」という工程のすべてで、AIが「今ここまで終わりました、次に進んでいいですか？」と聞いてくる。
人間がやるのは「OK」と返すだけ。判断の根拠は事前に部門マトリクスに書いてあるから、迷わない。
夜、1日の終わりに今日の出来事をAIにまとめさせて寝る。翌朝にはもう次のキューが立ち上がっている。
これが、今日から作りに行く未来。「AIを29台使う」と聞くと派手に響くが、実態は「人間が判断と方向修正だけに時間を使える状態」を組み立てる、地味で再現性のある工程だ。誰でも、今日から1部門ずつ積めば届く距離にある。
第1章 AIを「6部門の組織」として組み立てる
ここからは、29台のAIをどう6部門に組織化するか、その全体マップを公開する。
6部門の役割マトリクス
部門 / 役割 / 担当AI / 主な成果物 / 1日あたりの稼働
**経営企画部** / 戦略・KPI管理・撤退判断 / Claude Code（統括） / 週次KPIレビュー / 事業ポートフォリオ / リソース配分 / 30分
**プロダクト開発部** / 企画→実装→テスト / Claude Code + Cursor + Windsurf / 商品の機能実装、テスト、リリース可能なZIP / 4時間（AI稼働時間）
**品質管理部** / レビュー・整合性・安全性 / Claude Code（別セッション） / レビュー指摘リスト、リスク評価、最終GO判定 / 1時間
**マーケティング部** / LP・SNS・コピー / Claude + ChatGPT / 商品説明文、SNS投稿文、メルマガ案 / 1時間
**R&D部** / 新技術調査・PoC / DeerFlow + Firecrawl + ローカルLLM / 競合分析、新APIの検証ノート、判断付き調査メモ / 2時間（夜間自動）
**リスク管理部** / OPSEC・法務・予算 / Claude Code / 公開前チェック、利用規約点検、予算アラート / 30分
なぜ部門に分けるのか。理由は3つある。
・視点を切り替えられる: 「マーケティング部として見て」と頼むだけで、出力の切り口が変わる
・チェック関係が成立する: 開発部の成果物を品質管理部に回す。同じAIでも別の帽子を被せれば、自分のミスが見える
・進捗管理が機械的になる: 部門ごとにタスクを持てば、ボトルネックが一瞬で見える
部門間ハンドオフのJSON仕様
部門が複数あると、引き継ぎが雑になる事故が必ず起きる。これを防ぐために、部門間で渡すデータは必ず以下のJSON形式に揃えている。
{
"from_division": "product_dev",
"to_division": "qa",
"artifact_path": "generated/products/<product_slug>/build/",
"summary_one_line": "MVP実装完了。テスト全通過。",
"decisions_made": [
"決済はStripe Linkに固定",
"管理画面は最小UI、あとで拡張"
],
"open_questions": [
"返金ポリシーの文言、法務確認待ち"
],
"next_action_owner": "qa",
"next_action": "セキュリティと整合性レビュー、CRITICAL/HIGH/MEDIUM=0まで修正依頼を返す",
"blockers": []
}
このJSONを必ずハンドオフ時に書かせるだけで、引き継ぎ漏れがほぼ消える。
人間も「いまどこに何があるか」を1秒で把握できる。
部門が1つ生まれるたびに、自分の手は1つ空く
最初から6部門を一気に組み上げる必要はない。
僕も最初は「経営企画部 = Claude Code」と「プロダクト開発部 = Claude Code」の2つから始めた。
1部門立ち上げると、人間がやっていた30分〜2時間の作業がそのまま空く。空いた時間で次の部門の設計に回す、というループだけで、3週間あれば6部門に届く。
第2章 Claude Code を COO として使う5つの実プロンプト
プロンプト1: 朝一の優先度整理
毎朝、起きたら最初にこのプロンプトをClaude Codeに渡す。
今日のタスクを整理して。
優先度の付け方:
1. 昨日の未完了で、止まっているもの
2. 売上に直結するもの
3. 仕組みを改善するもの
各タスクには:
- 担当部門
- 想定所要時間
- 完了条件（数字で書ける場合は数字で）
- ブロッカーになりそうな要因
を付けて、Markdownチェックボックス形式で出して。
ポイントは「完了条件を数字で」と指定すること。曖昧なタスクは延々と続いて、AIも人間も終わらせ方が分からなくなる。
「LPを改善する」ではなく、「LPのCTAクリック率が3%を超えたら完了」と書ける形まで具体化する。
プロンプト2: 詰まった時の脱出
AIが同じエラーで止まり続けた時、このプロンプトに切り替える。
このタスクで詰まっている。状況を以下の形式で整理して、別のアプローチを3つ出して。
【ゴール】
（最終的に達成したい状態）
【今までやったこと】
（試したアプローチを箇条書き）
【それぞれが失敗した理由】
（推定でいいので分析）
【別のアプローチ案3つ】
- 案A（軸となる発想・想定リスク）
- 案B（軸となる発想・想定リスク）
- 案C（軸となる発想・想定リスク）
【推奨】
3案のうちどれを最初に試すべきか、根拠と一緒に。
このフォーマットを通すと、AIは「同じやり方の延長」から強制的に外れる。
詰まり続ける時間を短く切り上げる、これが個人運営の生産性を支える要だと思っている。
プロンプト3: コードレビュー
開発部が出したコードを、品質管理部の帽子で見る時のプロンプト。
あなたは品質管理部のシニアエンジニアです。
以下のコードを厳しくレビューしてください。
チェック項目:
1. セキュリティ（XSS / CSRF / SQLi / パストラバーサル / 認証回避）
2. パフォーマンス（N+1 / メモリリーク / 不要な再レンダリング）
3. UX（ユーザーが詰まりそうなフロー、エラー時の復帰導線）
4. エラーハンドリング（エッジケース、ネットワーク障害時の挙動）
5. アクセシビリティ（スクリーンリーダー対応、コントラスト比）
各項目について、「問題なし」で終わらせず、何を確認して問題なしと判断したか具体的に書いて。
問題が見つかったら、重要度（Critical / High / Medium / Low）と、修正コードを併記して。
「厳しく」と「何を確認したか書いて」をセットで入れることで、褒めるだけのレビューが出なくなる。
プロンプト4: スキル蓄積
一度やった作業を「スキル」として保存し、次回から自動で再利用させるためのテンプレ。
---
name: <スキル名（短くて検索しやすい名前）>
description: <このスキルが何をするか、1行で>
trigger: <どんな時にこのスキルを使うか>
owner_division: <担当部門>
---
## 手順
1. <ステップ1>
2. <ステップ2>
3. <ステップ3>
## 使う時の注意
- <やりがちなミスとその回避策>
## 完了条件
- <何をもって完了とするか、できれば数字で>
## 失敗時の戻し方
- <途中で詰まった時、どこに戻れば安全か>
このテンプレで貯めていくと、半年後には「自分専用の業務マニュアル」が自動的に積み上がっていく。
人間スタッフを雇うと最初の3か月は教育に費やすが、AIにはこのテンプレ1枚渡すだけで済む。
プロンプト5: 1日の終わりの振り返り
夜、AIに今日の振り返りを書かせるプロンプト。
今日のセッションをレビューして、以下の形式でまとめて。
## WORKED（うまくいったこと）
- <具体的に何が成功したか、なぜ成功したか>
## NOT WORKED（うまくいかなかったこと）
- <具体的に何が失敗したか、なぜか、再発を防ぐにはどうするか>
## NOT TRIED（今日はやらなかったが、明日試すべきこと）
- <次のセッションで最初に着手すべきこと>
## 翌日のキュー（優先度順）
- [ ] タスク1（担当部門・想定時間・完了条件）
- [ ] タスク2
- [ ] タスク3
このログを毎日積むと、翌朝のセッションの立ち上がりが10倍速くなる。
「昨日どこまでやったっけ」を思い出す時間がゼロになるので、朝の30分がそのままアウトプットに変わる。
第3章 商品開発7ステップ（プロンプト付き）
ここからは、1つの商品を企画→販売まで持って行くフローを、各ステップで使うプロンプトとセットで開く。
Step 1 市場の穴を見つける（30分）
以下のジャンルで、需要があるのに供給が少ない商品カテゴリを5つ提案して。
ジャンル: <ターゲットジャンル>
各提案に以下を含めて:
- 推定市場規模（大 / 中 / 小、根拠つき）
- 既存の競合商品数（推測の場合は「推測」と明記）
- なぜ供給が少ないのか（技術的に難しい？気づかれていない？）
- ターゲットの具体的なペルソナ（年代・職業・予算感）
- 価格帯の予想
- 「買わない理由」になりそうな懸念
「買わない理由」を最初に出させるのがポイント。ここで致命的な懸念が出た案は、企画段階で落とせる。
僕は最初これを省略していて、3週間開発した商品が全く売れなかった。痛い授業料だった。
Step 2 競合を1段階深掘り（15分）
<候補商品>の競合分析をして。
1. 直接競合（同じ課題を同じ方法で解決する商品）を3つ
2. 間接競合（同じ課題を別の方法で解決する商品）を3つ
3. 各競合の弱点を分析
4. その弱点を突く差別化ポイントを3つ
5. 価格を競合の何倍に置くべきか、根拠つきで
差別化は最終的に1つに絞るが、候補は3つ出させる。1つ目を絞り込んだ後で2・3つ目を「副次的な訴求点」として商品説明文に活かせる。
Step 3 企画書を作る（30分）
以下のリサーチ結果から、商品企画書を作成して。
<Step 1の結果>
<Step 2の結果>
企画書に含める項目:
1. 商品コンセプト（1文で）
2. ターゲットペルソナ3人分（名前 / 年齢 / 職業 / 課題 / 予算 / 購入を後押しする一言）
3. 解決する課題トップ3
4. 機能リスト（Must / Should / Could に分類）
5. MVP定義（Must だけで構成した最小版）
6. 価格設定と根拠
7. 競合との差別化ポイント（1つに絞る）
8. 出品後30日の販売目標
9. リスクとその対策
差別化は3つも4つも並べず、必ず1つに絞って。
ペルソナ3人分が肝。1人だとターゲットが狭すぎる。3人いれば商品の汎用性が見える。
Step 4 開発キックオフ（1〜3日）
以下の企画書に沿って、このプロダクトを実装して。
<企画書>
開発ルール:
1. まずファイル構成を提案して、承認を取ってから着手する
2. MVP機能だけを実装する（Should / Could は後回し）
3. 各機能の実装後にテストを書いて通す
4. コミットメッセージは「何をしたか」ではなく「なぜしたか」を書く
5. 同じエラーが3回続いたら、別のアプローチを提案する
6. 1時間以上進捗がなければ、状況を報告して指示を仰ぐ
ここで決定的に重要なのは「3回同じエラーが続いたら別アプローチ」のルール。
このルールがないと、AIは延々と同じ修正を繰り返して、API使用量だけが膨らんでいく。
Step 5 サーキットブレーカーを必ず仕込む
検知条件 / 自動アクション
同じエラーが5回連続 / セッション停止、別アプローチを提案
3イテレーション連続で進捗ゼロ / 停止して状況報告
API予算が月額の80%到達 / 警告アラート＋以後は確認しながら実行
出力品質スコアが30%以上低下 / レビュー要請のフラグを立てる
同じ入力が3回繰り返された / 強制ハンドオフ書き出しに切り替える
僕はこれを入れ忘れた夜、AIが大量のAPIコールを叩き続けて、翌朝1万円超の請求を見ることになった。
それ以来、すべての自律ループにサーキットブレーカーが入っている。1度ハマったら絶対に二度とハマらせない仕組みにする、これが個人運営の継続条件。
Step 6 出品準備（1〜2時間）
商品説明文のテンプレ。
【ヘッドライン】（20文字以内、最大のベネフィット）
あなたの<対象領域>が<after>になる
【リード】（3行、共感→問題提起→解決策）
<ターゲットが感じている不満>
→ <その原因>
→ <この商品がどう解決するか>
【こんな人におすすめ】（3つ、箇条書き）
- <ペルソナ1の状況>
- <ペルソナ2の状況>
- <ペルソナ3の状況>
【含まれるもの】（数字つきで具体的に）
- <成果物1>（◯ファイル / ◯ページ）
- <成果物2>
【ビフォーアフター】
Before: <導入前の状態>
After: <導入後の状態>
【よくある質問】（3つ、購入を止める不安を潰す）
Q: <買わない理由になりそうな不安>
A: <それを解消する回答>
【保証】
<返金 / サポート / 追加アップデート>
説明文のNGとOKを並べると、差は一発で見える。
ダメな書き方 / 売れる書き方
TypeScript対応、ES2022準拠、バンドル12KB / テンプレを1つ入れるだけで、あなたの<対象>が自動で動き出す
全機能搭載、無制限、スケーラブル / 月◯時間の手作業が、◯分で終わる
プロ仕様、業界標準、最先端 / <具体的なペルソナ>が翌週から差を感じる設計
機能ではなく、変化を売る。これは何度も自分に言い聞かせている。
Step 7 出品後の改善サイクル（毎週）
以下の販売データから、改善提案を3つ出して。
販売期間: <日数>
ページビュー: <PV>
購入数: <件数>
コンバージョン率: <%>
返金率: <%>
優先順位:
1. コンバージョン率の改善（説明文 / 価格 / サムネ）
2. PVの増加（SEO / SNS / 相互リンク）
3. LTV向上（追加商品 / バンドル / リピート施策）
出品して終わりにしないこと。週1回のこの分析だけで、商品ページのCVRは少しずつ確実に上がっていく。
第4章 月次コスト構造の分解
29台のAIを動かすコストはいくらなのか。リアルな内訳を出す。
カテゴリ / 月額目安 / 用途
Claude Code（メイン） / $20 / 統括・開発・レビュー
Cursor（コーディング補助） / $20 / リアルタイム補完
ChatGPT（リサーチ・文章） / $20 / 幅広いリサーチと長文生成
Windsurf（マルチファイル編集） / 無料枠 / 大規模リファクタ時のみ
ローカルLLM（Gemma / Qwen） / 0円 / セカンドオピニオン・下書き
ブラウザ自動化系 / 無料枠 / 出品・データ収集
画像生成 / 無料枠 or 月¥2,000 / サムネ・LPビジュアル
サーバー・ドメイン / 月¥1,500前後 / LPホスティング
**合計** / **月¥9,000〜¥12,000** /
人間スタッフを1人雇うコストの50分の1で、エンジニア・デザイナー・マーケターの仕事が回る。
ここに「AIを組織化したROI」がある。
第5章 ROI判定マトリクスと撤退ライン
新しい商品を出す前に、必ずこの計算を通している。
【投資】
AI月額のうち、この商品に按分する額: ¥___
開発時間: ___時間 × 自分の機会費用: ¥___
その他（サーバー / 素材 / 広告）: ¥___
投資合計: ¥___
【リターン予測】
価格: ¥___
月間販売予測: ___個
月間売上: ¥___
プラットフォーム手数料: ¥___
月間純利益: ¥___
【回収期間】
投資合計 ÷ 月間純利益 = ___ヶ月
【判断】
3ヶ月以内に回収 → GO
6ヶ月以内に回収 → 慎重に検討（差別化を1つ追加してから着手）
6ヶ月超 → 見送り
この判断はAIに任せて30秒で出す。
人間の「なんとなくいけそう」より、定量化した試算の方が信頼できる。
撤退ラインも事前に決めておく。
状況 / 撤退ライン
出品後30日でPVが100以下 / 商品ではなく集客導線を疑う
PV 300超でCVR 0.5%以下 / 商品説明文 / 価格 / サムネを順に検証
返金率10%超 / 一度販売停止して、商品の品質と説明文の整合性を再確認
月額コストが月利益を超えて2ヶ月 / 即時撤退、別商品にリソース移動
「撤退できる事業」は強い。撤退できないと、ダメな商品にリソースが食われ続けて、伸びる商品の手当てが薄くなる。
第6章 1日のタイムライン
実際の1日の流れ。
07:00 起床
07:15 Claude Codeに「今日のタスクを整理して」と投げる
07:20 出てきたタスクの優先度をざっと確認、修正があれば指示
07:25 AIにGoサイン、自分は朝食
09:00 進捗確認、問題なければ「続けて」だけ
09:05 別のことをする（運動 / 学習 / 別事業）
12:00 昼の進捗確認、品質チェックが必要なものに目を通す（15分）
12:30 軽食 → 別作業
15:00 午後の進捗確認、出品準備が完了していれば最終GO（10分）
15:15 別作業
18:00 1日の振り返りをAIに書かせる（10分）
18:10 翌日のキューを設定して終了
合計の人間作業時間: 約2時間
AI稼働時間: 約12時間（夜間自動含む）
23時間の大半は、AIが動いて、人間は別のことをしている時間になる。
「AIを組織化する」というのは、結局のところ「自分の時間が空く設計を組む」ということだ。
第7章 失敗パターン12分類とリカバリ手順
うまくいった話だけ並べても嘘くさいので、12個の典型的な失敗をオープンにしますね。
# / 失敗パターン / 何が起きたか / リカバリ手順
1 / サーキットブレーカー無し / 一晩で1万円超の請求 / 全自律ループにブレーカーを必須化
2 / 1台のAIに全部任せた / 後半の判断が崩れる / 部門ごとに別セッションに分割
3 / レビューを同じAIに頼んだ / 自分のミスを見逃す / レビューは必ず別の帽子を被せるか他のAIにさせる。
4 / 完了条件が曖昧 / 終わらないタスクが積み上がる / 完了条件を数字で書く
5 / 市場検索ボリューム未確認 / 売れない商品を3週間開発 / 月間検索1,000以上を最低基準に
6 / 価格をターゲットの予算と外した / 反応はあるが買われない / ターゲットの「痛くない額」の1.2倍に
7 / 機能ベースの説明文 / CVRが0.2%以下に張り付く / 「あなたの何が変わるか」型に書き直す
8 / サムネ手抜き / クリック率が業界平均の半分 / 1280×720・テキスト大
9 / 商品出して放置 / PVが3週間後にゼロ / 週1回の改善ループを必ず回す
10 / セッション引継ぎ無し / 翌朝のスタートで30分溶ける / WORKED / NOT WORKED / NOT TRIED の3行を毎晩残す
11 / 失敗を記録しなかった / 同じ失敗を3か月後に再演 / 失敗ログをスキルファイルに昇格
12 / 1人で抱えた / 判断疲れでGo/No-Goが歪む / ローカルLLMを「セカンドオピニオン」として常駐させる
12個全部、自分が踏んだ。踏まないに越したことはないが、踏んだ後に「同じパターンを2度踏まない仕組み」を作れば、それは資産になる。
第8章 週次レビュー自動化の構造
週末に1時間だけ、AIに今週をレビューさせる時間を取っている。
今週のセッションをレビューして、以下の構造でまとめて。
## 売上 / KPIサマリー
- 出品数 / 販売数 / 売上 / CVR / 返金率
- 先週との比較
## WORKED（再現したいこと）
- どの行動が成果につながったか、3つ
- それぞれを次週どう増やすか
## NOT WORKED（やめること / 減らすこと）
- 効果が出なかった作業3つ
- それぞれをやめる / 減らす理由
## 学んだこと（資産化候補）
- スキルファイルに昇格すべきナレッジ3つ
## 来週の最優先3つ
- 売上に直結するもの
- 仕組み改善
- リスク対応
## ブロッカー（人間判断が要るもの）
- ここだけ列挙、Go / No-Goを次の月曜朝に判定
このレビューを毎週積むと、半年後には「自分の運営の傾向と打ち手のパターン」が完全に見える状態になる。
データに基づく判断ができるかどうかは、こういう小さなログの積み重ねで決まる。
第9章 明日から動くための3ステップ
完璧を目指す必要はない。最小限のスタートはこの3つ。
・Claude Codeを使い始める（無料枠から）
・第2章のプロンプト1（朝の優先度整理）と5（夜の振り返り）を、明日の朝晩に1回ずつ通す
・1週間続けて、自分のセッションログから「次に部門化する作業」を1つ選んで、そこに第2章プロンプト4のスキルテンプレを当てる
これだけで「1人で全部やる運用」から「AIを部門化する運用」への移行は始まる。
僕も最初は2部門だった。気づけば6部門になっていた。
「AI29台」と書くと大げさに聞こえるが、最初から29台必要なわけではない。Claude Code 1台から始めて、空いた時間で次の部門を立ち上げていけば、3週間あれば6部門は十分組み上がる。
大事なのは「AIをツールとして使う」から「AIをチームとして組織化する」への発想転換。これだけ。
おわりに
AIで何か始めたい個人にとって、いま一番しんどいのは「全部自分で抱えなければいけない」という感覚だと思う。
僕も最初はそうだった。検索しても情報は出てくる、でも結局自分の手で全部やらなければならない、その重さで動けなかった。
29台のAIを6部門に組織化してから、その重さは消えた。今は「人間が全部やらない」が前提で、自分は判断と方向修正だけに時間を使っている。
この記事に書いたプロンプトとテンプレは、すべて今日からそのままコピペで使える形にしてある。完璧に揃ってから始めるのではなく、まず1つ、明日の朝に試してほしい。
次回の記事では、29台のAIを動かす上で必須の「メモリ管理」と「セッションハンドオーバー」の設計を全公開する予定。フォローして待っていてもらえると嬉しい。