Claude Codeで Threads を完全自動運用、2週間で3万円 — 6エージェント構成の設計と失敗から学ぶ自動化の現実

この記事で得られること

• Claude Code × 6 エージェントによる SNS 完全自動運用の具体的な構成
• 各エージェントの役割と連携フロー
• 「アカウント凍結」「同一投稿ループ」など実際の失敗とその対策
• AI 自動化で収益を上げる際の設計原則
• 開発者が応用する際の注意点と倫理的な論点

---

一次ソース

2026年3月19日、Threads マーケティングの専門家 シロウ氏（@shiro_life0）が X の Article 機能で長文記事を公開した。

タイトルは「Claude code使ったら完全自動で3万稼げてた件」。

投稿は 187万 views、3,005 いいね、7,063 ブックマーク を記録し、AI×SNS マネタイズの具体的な実践例として大きな反響を呼んでいる。

シロウ氏は自身について「Threads で累計2億円以上を稼ぎ、万垢を7個、累計フォロワー15万人超」と紹介しており、Threads マーケティングにおいて豊富な実績を持つ人物だ。

---

なぜ Threads なのか — AI 自動化との相性

シロウ氏が自動化プラットフォームとして Threads を選んだ理由は明快だ。

プラットフォーム	特徴	AI自動化
X（Twitter）	テキスト・フォロワー依存	△
Instagram	画像リール・フォロワー依存	×
TikTok	動画・アルゴリズム推薦	×
Threads	テキストのみ・アルゴリズム推薦	◎

Threads の優位性

• テキストのみで完結 → AI のテキスト生成能力を最大限活用
• フォロワー 0 でもアルゴリズムがフォロワー外に拡散
• リサーチから投稿まで全工程を AI に任せやすい

---

6 エージェント構成の全体像

シロウ氏のシステムは、1 エージェント = 1 タスク の原則で設計されている。

「1つの AI に全部やらせるとパンクする。リサーチしながら投稿も書いて分析もして、ってやると精度が落ちる。だから人間の会社と同じ。営業と経理と開発を1人にやらせたら終わる」

エージェント一覧

エージェント	役割	主な処理
1. リサーチャー	ネタ収集	YouTube・Xからキーワード検索、テーマツリーに基づく重点調査
2. アナリスト	分析	閲覧数・いいね・リプライの分析、ライターへのフィードバック生成
3. ライター	投稿作成	15種以上のパターンからローテーション、265件の1行目ストック参照
4. ポスター	投稿実行	Threads APIでcron投稿（1日10回、2時間間隔）
5. フェッチャー	データ取得	投稿24時間後にメトリクス収集、投稿履歴に追記
6. スーパーバイザー	監視	エラー3回連続で自動停止、KILL_SWITCH（緊急停止）

日次フロー

朝、シェルスクリプト1本を実行するだけで以下が連鎖する:

1. フェッチャー → 昨日の投稿データ取得
2. アナリスト → データ分析＋ライターへのフィードバック
3. リサーチャー → 不足テーマのネタ補充
4. ライター → 5〜10本の投稿生成（品質スコア7.0未満は棄却）
5. ポスター → cron で2時間間隔の分散投稿
6. スーパーバイザー → 全体監視

注目すべき設計ポイント

AIがAIにフィードバックする構造

アナリストの分析結果が、そのままライターへの「指示書」になる。「断言型の1行目が最近伸びてるから多めに」「〇〇系はもう飽きられてるから控えて」——人間がやる PDCA を AI 同士が自律的に回している。

ライターの品質管理

• 投稿パターン15種以上のローテーション（直近3件と重複回避）
• バズった1行目265件のストックから構造学習
• 10項目の自己採点（7.0未満は書き直し、2回ダメなら棄却）
• 過去100件との類似度チェック（0.85以上は棄却）

---

設計の4原則

シロウ氏が意識した設計原則は、AI エージェント開発全般に応用可能だ。

1. エージェント分離

1エージェント = 1タスク。責務の明確化により、各エージェントの出力品質が安定する。

2. ナレッジとロジックの分離

アカウントの口調、NGワード、投稿パターン、ターゲット情報はすべて外部ファイルに切り出し。コードに「人格」をハードコードしない。

「こうしておくとナレッジファイルを差し替えるだけで、転職でも美容でもママ向けでも、同じシステムが動く」

これは Claude Code の Skills における「参照ファイルの分離」と同じ発想であり、再利用性と保守性を高める定石だ。

3. 状態管理

投稿履歴、キュー、読者分析をすべて JSON で管理。AI が「昨日何を投稿したか」「どのテーマが伸びてるか」を記憶している状態を維持する。状態がないと文脈がリセットされ、同じ投稿を延々ループする（後述の事故参照）。

4. 安全装置

• 品質スコア7.0未満 → 自動棄却
• 類似度0.85以上 → 棄却
• 1日の投稿上限15件
• 最低投稿間隔1時間
• 緊急停止スイッチ（KILL_SWITCH）

「『AI に任せる』と『AI を放置する』は全然違う。任せるけど、手綱はちゃんと握る」

---

生々しい失敗事例

この記事の価値は成功例だけでなく、失敗の詳細な開示にもある。

事故 1: 1分で10連投 → アカウント凍結

自動投稿の間隔設定ミスで、1分間に10投稿を実行。Threads 側に即座に bot 判定されてアカウント凍結。

💡 教訓: AI の処理速度をそのまま使ってはいけない。「速すぎる」ことが自動化最大の敵。人間のリズム（2時間間隔、1日10回のタイムスロット分散）に合わせる必要がある。

事故 2: 同じ投稿を30回ループ

投稿履歴を参照する仕組みがなかった初期段階で発生。AI が文脈をリセットされるたびにゼロから考えるため、「最も無難な投稿」を延々と繰り返す。

💡 教訓: 状態管理（投稿履歴の永続化）がないと、AI は同じ出力を繰り返す。過去100件との類似度チェックが必須の安全装置になる。

---

収益モデル

項目	内容
収益源	ASP 系アフィリエイト（承認率保証あり案件）
手法	本文は通常の有益投稿、コメント欄に PR リンクを自動配置
実績	2週間で約3万円（叩き台段階）
ジャンル	転職系

シロウ氏は「ここからもっと作り込めば月300万ぐらいは作れそう」としているが、これは同氏の Threads での豊富な運用知見が前提にある点は留意すべきだ。

---

開発者が学べること

この事例から抽出できる、AI エージェント開発への汎用的な教訓をまとめる。

1. マルチエージェント設計は「小さな専門家チーム」

1つの万能エージェントより、責務が明確な複数エージェントの方が品質が安定する。これは Anthropic の Thariq Shihipar が Skills の設計でも指摘していた原則と通底する。

2. フィードバックループを自動化する

「アナリストがライターにフィードバックを出す」構造は、PDCA を人間なしで回す仕組みだ。出力品質の改善を自動化したい場面で参考になる。

3. 安全装置は最初から組み込む

「動いてから安全装置を追加」では遅い。投稿間隔、上限、類似度チェック、緊急停止はシステム設計時点で組み込むべきだ。

4. ナレッジの外部化で横展開

アカウント固有の情報を外部ファイルに分離することで、同じシステムを別ジャンルに転用できる。これは Skills の「ナレッジとロジックの分離」そのものだ。

---

倫理面の考慮

この事例は技術的に興味深いが、AI による SNS 自動運用には以下の論点がある。

• プラットフォーム規約: Threads の利用規約に自動投稿がどこまで許容されるか。API を使った投稿自体は公式に提供されている機能だが、完全自動運用の大量投稿はグレーゾーンに位置する。
• コンテンツの透明性: AI が生成したコンテンツであることの開示。読者が人間の投稿だと思って読んでいる場合、信頼性の問題が生じうる。
• 品質の自己評価: AI が自分の出力を採点する仕組みは有用だが、万全ではない。人間の最終チェックが完全に不要かは議論の余地がある。

技術的な「できる」と倫理的な「すべきか」は常に分けて考える必要がある。

---

まとめ

シロウ氏の事例は、Claude Code を使った SNS 自動運用の最も詳細な実践レポートの一つだ。6エージェント構成の設計、失敗とその対策、収益化の仕組みが赤裸々に公開されている。

開発者にとっての本質的な価値は、収益額そのものではなく、マルチエージェントシステムの実践的な設計パターンにある。エージェント分離、ナレッジとロジックの分離、状態管理、安全装置——これらは SNS 運用に限らず、あらゆる AI 自動化システムに適用可能な原則だ。

---