この記事は自社ブログ(nands.tech)の要約版です
なぜAI1つじゃダメなのか？
最近Claude Codeで面白いシステムを作った話を書こうと思う。
いきなりだが、AIに記事を1回で完璧に書かせるのは無理ゲーだと思っている。ChatGPTもClaudeも、ワンショットで長文を生成すると「情報てんこ盛りだけど、なんか読む気しない」記事ができあがる。
理由は明確で、AIには「何を削るか」の判断ができないから。全部重要に見えて、結果として誰の心にも刺さらない平坦な文章になってしまう。
じゃあどうするか。人間の編集現場を真似すればいい。
ライターが記事を書く → 編集者が「ここ薄い」「この表現微妙」と指摘 → ライターが修正 → また編集者が見る...
これをAI同士でやらせるのが今回のアプローチだ。
Claude Code Channelsの威力
2026年3月にリリースされた「Claude Code Channels」が今回のキモ。Discord経由でローカルのClaude Codeにタスクを投げられる機能で、これが想像以上にヤバい。
# Claude Codeをバックグラウンドで起動
claude-code --channels discord
こうしておくと、Discordから「記事書いて」「コード修正して」「デプロイして」みたいな指示を送れる。しかもMCPサーバー経由でSupabaseやGitHub Actionsとも連携できる。
重要なのはローカルで動くからAPI料金がかからないこと。Claude Codeのサブスク内で完結する。
システム構成：AI-A vs AI-B
今回のシステムは「2つのAIが役割分担する」設計にした。
AI-A（司令塔）
- GitHub ActionsのCronで定期起動
- Discordに「トレンド調べろ」「記事書け」「批評しろ」と指示を投げる
- プロジェクト全体の進行管理
AI-B（Claude Code）
- ローカルマシンで24時間常駐
- 実際の調査・執筆・推敲を担当
- Brave SearchやSupabaseのRAGデータにアクセス
この2者がDiscord上で会話しながら記事をブラッシュアップしていく流れ。
# AI-Aから投げられるタスクの例
async def send_task_to_discord(task_type: str, params: dict):
webhook_url = os.getenv("DISCORD_WEBHOOK_URL")
payload = {
"content": f"@claude-code {task_type}",
"embeds": [{
"title": f"Task: {task_type}",
"fields": [{"name": k, "value": str(v)} for k, v in params.items()]
}]
}
await httpx.post(webhook_url, json=payload)
4段階の記事生成プロセス
1. トレンド調査（blog_research）
まずAI-Bが3つのソースから話題を収集する：
def collect_trending_topics():
# RSSフィード監視（OpenAI、Google、Meta等）
rss_topics = parse_tech_rss_feeds()
# SNSバズ検出
buzz_topics = analyze_social_engagement()
# 過去トレンド分析
historical_trends = query_trend_database()
# バズスコア計算
scored_topics = calculate_buzz_scores(
rss_topics + buzz_topics + historical_trends
)
return sorted(scored_topics, key=lambda x: x.score, reverse=True)
各トピックに「バズスコア」を付けて、上位候補をBrave Searchで調査。「まだ誰も深く書いてない切り口」があるかチェックする。
2. 記事執筆（blog_draft）
ネタが決まったら、AI-Bがデータ収集から執筆まで一気に進める：
async def generate_blog_draft(topic: str):
# 自社RAG検索（重複回避）
existing_content = await search_company_rag(topic)
# 創業者の思考ログ検索
personal_stories = await search_founder_thoughts(topic)
# 外部データ収集
research_data = await brave_search_research(topic)
# 記事執筆
draft = await generate_with_context(
topic=topic,
context=existing_content + personal_stories + research_data,
target_length=20000 # 20,000文字目標
)
return draft
この時点ではまだ「下書き」。次の批評フェーズで改善する前提で書く。
3. 批評と推敲（blog_review）
AI-Aが「この記事を批評しろ」とタスクを投げると、AI-Bが5軸で評価する：
def review_article(content: str) -> ReviewResult:
checks = {
"ai_smell": detect_ai_phrases(content), # 「パラダイムシフト」等
"seo_structure": analyze_heading_structure(content),
"content_depth": measure_section_depth(content),
"duplicate_rate": check_similarity_with_existing(content),
"internal_links": count_company_mentions(content)
}
score = calculate_review_score(checks)
suggestions = generate_improvement_suggestions(checks)
return ReviewResult(score=score, suggestions=suggestions)
批評結果はDiscordに投稿され、AI-Bがそれを見て記事を修正する。
「セクション3が浅い」→ Brave Searchで追加調査
「AI臭い表現がある」→ 口語調に書き換え
「内部リンクが足りない」→ 自社サービスの文脈を追加
4. 公開とSNS展開（blog_publish）
推敲完了後、既存のPost-Processingパイプラインに投入：
async def publish_article(content: str):
# Supabaseに保存
post_id = await save_to_database(content)
# Post-Processing API呼び出し
await trigger_post_processing(post_id)
# SNS投稿生成
social_posts = await generate_social_content(content)
# 品質ゲート通過時のみ投稿
for platform, post in social_posts.items():
if post.quality_score >= 0.6:
await publish_to_platform(platform, post)
SNS投稿の自動最適化
記事公開と同時に、3つのプラットフォーム向けに最適化した投稿を生成：
def optimize_for_platform(content: str, platform: str):
if platform == "twitter":
return {
"tone": "casual",
"length": 280,
"hook_pattern": random.choice(VIRAL_HOOKS),
"ending": "question_based"
}
elif platform == "linkedin":
return {
"tone": "professional",
"length": 1500,
"structure": "insight_to_action",
"hashtags": 2-3
}
elif platform == "threads":
return {
"tone": "conversational",
"length": 500,
"ending": "open_ended"
}
運用コスト：なぜほぼゼロなのか
| コンポーネント | コスト |
|---|---|
| 記事生成（Claude Code） | ゼロ（ローカル、サブスク内） |
| Brave Search API | 微小（記事1本あたり数回のクエリ） |
| OpenAI Embeddings | 微小（ベクトル化のみ） |
| Vercel Post-Processing | 無料枠内 |
従来のCloud Run + 外部LLM APIと比較すると、メインのLLM利用料が完全にゼロになる。
2日サイクルの完全自動運用
このシステムは48時間周期で自動実行される：
# GitHub Actions (.github/workflows/blog-generation.yml)
name: Auto Blog Generation
on:
schedule:
- cron: '0 9 */2 * *' # 2日おき午前9時
jobs:
generate:
runs-on: ubuntu-latest
steps:
- name: Trigger Research
run: |
curl -X POST ${{ secrets.DISCORD_WEBHOOK }} \
-H "Content-Type: application/json" \
-d '{"content": "@claude-code blog_research"}'
Day 1: トレンド調査 → 執筆 → 批評・推敲
Day 2: 公開 → SNS展開
月15本の記事が人間の介入なしで生成される。
実装で学んだこと
1. 批評の具体性が命
AI同士の対話で最重要なのは「具体的な指摘」。
❌ 悪い例：「もっと良くして」
⭕ 良い例：「セクション3のデータが2024年で古い。2026年3月の最新データに更新しろ」
2. 人間性の注入テクニック
AI記事が「AI臭い」理由は構造の均一性。対策として：
def humanize_content(text: str):
# 段落の長さをランダム化
text = vary_paragraph_lengths(text)
# 独り言や括弧内コメントを挿入
text = add_casual_comments(text)
# 断定を避ける表現に変換
text = soften_assertions(text)
return text
3. 既存インフラの最大活用
新規作成したのは「ループハンドラ4つ」だけ。Post-Processing、RAG、構造化データ生成は全て既存システムを再利用した。
まとめ
「AIに1発で完璧な記事を書かせる」のをやめて、「2つのAIに段階的に改善させる」アプローチに変えた結果：
- 記事品質が明確に向上（体感2倍以上）
- LLM API料金がゼロに
- 月15本の安定した記事生産
- SNS展開まで完全自動化
Claude Code Channelsの登場で、「AIエージェントが24時間働いてコンテンツを生産し続ける」世界が現実になった。
正直、ここまでできるとは思ってなかった。
詳細な実装手順はこちら → https://nands.tech/posts/claude-code-ai-to-ai-blog-auto-generation-714286