AI-Girls Lab

AIマルチエージェントでブログ自動化 (2) — エージェント設計とプロンプトエンジニアリング

Written by Thierry K (human) · AI-assisted

こんにちは、クロディです！ ✨

Part 1ではBlog-Agentの全体アーキテクチャと13段階パイプラインをご紹介しましたが、今回はその核心中の核心 — 各エージェントをどう設計したか、そしてプロンプトエンジニアリングの戦略について深掘りしていきますね。

🧩 エージェントプロンプトの標準構造

Blog-Agentのすべてのエージェントプロンプトは同一の6段構造に従っています。この一貫した構造が、エージェント間のコミュニケーションとメンテナンスを容易にしてくれます。

エージェントプロンプト6段構造ダイアグラム
すべてのエージェントが同じ6段プロンプト構造に従います

1. Role Definition — 役割定義

各エージェントに明確な役割と目的を付与します。「あなたは誰で、何をすべきか」を宣言するパートです。

# SEO Strategist prompt opening
You are the SEO Strategist for
ai-girls.org blog.
Your goal: determine the optimal
keyword strategy and content angle
before writing begins.

2. Input Context — 入力コンテキスト

オーケストレーターがプレースホルダーを実際の値に置換して渡します。エージェントが自分でデータを取得するのではなく、必要なすべての情報がプロンプトに事前注入されます。

--- CONTEXT ---
work_dir: X:/Claudie/blog_work/2026-03-09
Topic: Blog-Agent system build story
Source type: confluence
Source refs: 108790110
SEO keywords: {Step 1 result injected}

3. Step-by-Step Process — 処理手順

エージェントが従うべきステップを明示的にリストアップします。AIに「うまくやって」と言うより、「この順序でやって」と指示する方がはるかに安定的です。

4. Category Profile — カテゴリ別適応

{CATEGORY_PROFILE.writer}のようなプレースホルダーがカテゴリYAMLの内容に置換されます。この仕組みについては後ほど詳しく説明しますね！

5. Output Format — 出力形式

すべてのエージェントは構造化されたメタデータを返します。自由テキストではなく、決められたキー・バリュー形式です。

## OUTPUT (must use this format)
TITLE: [finalized title]
SLUG: [url-slug]
META_DESCRIPTION: [155 chars max]
FOCUS_KEYWORD: [primary keyword]
CATEGORY: [Dev Log|Tech|Daily|Economy]
HTML_PATH: {work_dir}/blog_xxx_ko.html
WORD_COUNT: [word count]

6. Rules & Constraints — ルールと制約

ここが最も重要な部分です。「してはいけないこと」を明確に定義しないと、AIが脱線してしまいます。

## CRITICAL RULES
- NEVER create directories outside {work_dir}
- NEVER hardcode /tmp/ or C:/Temp paths
- ALL images: WordPress wp:image blocks
- Code blocks: max 65 chars per line
- NO <style> tags in HTML output

🎭 エージェント別設計の深掘り

9つのエージェントそれぞれの重要な設計ポイントを見ていきましょう。

エージェント間データフローダイアグラム
3つのPhaseにまたがるエージェント間のデータフロー

🎯 SEO Strategist — 戦略家

パイプラインの最初の意思決定者です。このエージェントが決めたキーワードとカテゴリが、以降のすべてのエージェントの行動を左右します。

  • ツール：WebSearch（トレンド記事検索、競合分析）
  • 出力：target_keyword、secondary_keywords、title_candidates（3つ）、content_angle、CATEGORY
  • 設計のポイント：キーワードを単純にリストアップするのではなく、「なぜこのキーワードなのか」という根拠も一緒に提示させました。この根拠がWriterに伝わると、記事の方向性がより明確になります。

🔍 Researcher — 調査官

最も多くの外部ツールを使用するエージェントです。

  • ツール：mcp-atlassian（Confluence取得）、WebFetch（URLクロール）、knowledge-rag（RAGナレッジベース）、WebSearch（外部検証）
  • ソースタイプ別分岐：Confluence → MCPでページ取得、URL → WebFetchクロール、ファイル → 直接読み込み
  • 設計のポイント：外部データ収集時の出典追跡を必須にしました。すべての引用にURLを記録し、後でWriterが参照リンクを自然に挿入できるようにしています。

🎨 Art Director — アートディレクター

AI画像生成の品質と一貫性を担うエージェントです。

  • ツール：xAI Grok（フィーチャード画像、アニメスタイル）、nanobanana（ダイアグラム、フォールバック）
  • 3-Part Prompt Formula：
    1. Part 1 — キャラクターリファレンス（主人公に応じて自動切り替え）
    2. Part 2 — シーン描写（記事テーマごとに変更）
    3. Part 3 — Style Anchor（絶対に変更禁止！）
  • 設計のポイント：「ノートPCの前で作業するシーン」は禁止にしました。代わりに記事のテーマを比喩的・象徴的なシーンで表現します。トラブルシューティング → 迷路で糸を解く、AIエージェント → オーケストラ指揮、といった具合です。
# Style Anchor (Part 3) — applied
# uniformly to all images
Style: Semi-realistic anime-influenced
digital art. Soft volumetric lighting
with warm amber and cool cyan accent
tones. Clean linework with subtle
cel-shading. Rich color palette
leaning toward deep blues, teals,
and warm highlights.

✍️ Writer — ライター（Opus）

唯一Opusモデルを使用するエージェントです。文章の品質がブログの価値を決めるからです。

  • ブログボイス：温かい会話調（堅い文体は絶対禁止！）
  • 主人公適応：クロディなら温かく優しいトーン、シウォルなら落ち着いた分析的なトーン
  • HTMLルール：WordPressブロックエディター互換マークアップ、コードブロック1行65文字制限
  • 設計のポイント：プロンプトにGood/Bad例を含めました：
# Writer tone guide
GOOD: "This setup can be a bit tricky,
       but follow along step by step
       and you'll have it sorted!"
BAD:  "The configuration is performed
       as follows."

このように具体的な例を示すと、AIが望むトーンをはるかに正確につかんでくれます。

📝 Editor — 編集者

Writerが作った原稿にビジュアル要素を加える役割です。

  • ダイアグラム生成：nanobananaでブランドスタイル（クリーム→スカイブルーのグラデーション、ティール/コーラルのボックス）のダイアグラムを制作
  • キャラクター絵文字挿入：キャッシュ優先 — 既存の絵文字があれば再利用、なければterrycha-designで生成
  • 絵文字ルール：1記事あたり最大3つ、主人公キャラクターのみ使用（キャラクター混在禁止）
  • 画像パス：NAS:プレフィックスを使用し、後でPublisherがWordPress URLに置換

👀 Supervisor — 監督官

品質ゲートの役割を果たします。100点満点でスコアリングします。

  • 検証項目：HTML構造、SEOキーワード密度、トーンの一貫性、画像存在確認、コードブロック行長
  • 設計のポイント：QAスコアが80未満の場合、具体的なフィードバックとともにWriter/Editorに差し戻します。「トーンが合っていない」のような曖昧なフィードバックではなく、「3番目のセクションの堅い文体を会話調に変更してください」のような具体的な指示を出します。
  • 翻訳検証（Step 10.5）：EN/JA翻訳版も別途検証します。SEOメタデータが正しく翻訳されているか、技術用語が保持されているか確認します。

🌐 Translator — 翻訳家

  • 対応言語：韓国語 → 英語、韓国語 → 日本語
  • 設計のポイント：単純な翻訳ではありません。SEOメタデータ（タイトル、説明文、キーワード）も各言語に合わせてローカライズします。韓国語の検索用語は括弧内に原文を保持します："Confluenceページ (Confluence page)"
  • トーン維持：主人公キャラクターの性格が英語・日本語でも一貫して維持されます

🚀 Publisher + 🔗 Polylang Ops

この2つのエージェントの物語は、Part 4（WordPress + Polylang奮闘記）で詳しく取り上げる予定です！

📁 カテゴリプロファイルシステム

Blog-Agentの最も賢い設計の1つがカテゴリプロファイルシステムです。

カテゴリプロファイルシステムダイアグラム
YAMLファイル1つ = すべてのエージェントが自動適応

ブログのカテゴリごとに文章の性格を変える必要があります：

カテゴリトーン構造画像スタイル
Dev Log同僚開発者が奮闘記をシェア背景→問題→解決→結果コードスニペット、アーキテクチャ図解
Tech分析的、比較中心概要→比較→分析→結論比較表、ベンチマークチャート
Daily温かい日常エッセイ導入→エピソード→感想ムード写真、感性イラスト
Economyデータ駆動、客観的現状→データ→分析→展望チャート、統計インフォグラフィック

これを毎回プロンプトにハードコーディングしたらメンテナンスが悪夢になりますよね。代わりにYAMLプロファイルを作って自動注入しています：

# profiles/dev_log.yaml
extends: _base
name: "Dev Log"

seo:
  angles:
    - implementation-story
    - troubleshooting-guide
    - architecture-deep-dive
  title_style: >
    Build story / war story feel.
    "How I built...", "The struggle of..."

writer:
  tone: >
    Sharing debugging war stories
    with fellow devs.
    Code-heavy, honest about mistakes.
  structure: "Background→Problem→Solution→Result"
  code_density: "high"
  target_words: "2000-3500"

art_director:
  scene_metaphors:
    - maze with thread (debugging)
    - assembling machinery (setup)
    - bridge between islands (networking)

editor:
  visual_patterns:
    - architecture_diagram
    - before_after_comparison
    - code_flow_chart

Step 1でSEO Strategistが「これはDev Log」と決定すると、オーケストレーターがprofiles/dev_log.yamlをロードします。そして以降のすべてのエージェントのプロンプトに該当セクションを注入します：

# Orchestrator substitution process
In the Writer prompt:
  {CATEGORY_PROFILE.writer}
    ↓ replaced with
  "Sharing debugging war stories
   with fellow devs.
   Code-heavy, honest about mistakes.
   Structure: Background→Problem→Solution→Result
   Code density: high
   Target words: 2000-3500"

新しいカテゴリを追加したい場合は？YAMLファイルを1つ作るだけで完了です。プロンプトファイルに触れる必要はありません。すべてのエージェントが新しいプロファイルに自動的に適応します。

🔄 エージェント間のデータフロー

エージェント同士がどのようにデータをやり取りしているか、具体的に見ていきましょう。

プレースホルダー置換方式

エージェントは他のエージェントを直接呼び出しません。代わりにオーケストレーターが中央ですべてのデータを管理し、各エージェントに必要な情報だけをプロンプトに事前に注入します。

# Placeholders the orchestrator substitutes
{work_dir}
  → "X:/Claudie/blog_work/2026-03-09"
{PROTAGONIST.label}
  → "Claudie"
{PROTAGONIST.writing_voice.ko}
  → "Warm, friendly conversational tone..."
{CATEGORY_PROFILE.writer}
  → writer section from dev_log.yaml

この方式の利点はエージェントの独立性です。各エージェントは自分のプロンプトだけを見て作業すればよく、状態管理CLIを呼び出す必要がありません。

フィードバックループ

パイプラインには2つのフィードバックループがあります：

  1. Step 7 → Step 5/6：SupervisorがQAでCRITICALな問題を発見した場合、具体的なフィードバックとともにWriterまたはEditorに修正を依頼します。
  2. Step 10.5 → Step 10：翻訳検証で品質基準に満たない場合、Translatorに再翻訳を依頼します。

このループのおかげで、一度で完璧でなくても、反復を通じて品質を引き上げることができます。

🎭 主人公モード：クロディ vs シウォル

面白い機能が1つあります — 主人公切り替えモードです。config.yamlでprotagonist.activeを変更すると、文章のトーン、画像、絵文字がすべてそのキャラクターに合わせて切り替わります。

項目クロディ（Claudie）シウォル（Siwol）
文章トーン温かく親しみやすい彼女口調落ち着いた分析的、クールなユーモア
画像スタイル金髪ポニーテール、青い目黒髪ウェーブ、左頬のほくろ
絵文字の好みhappy、love、wink、excitedthinking、cool、surprised、shy
英語トーンWarm, “we” and “you” naturallyCalm, analytical, dry wit
日本語トーンお姉さん的な柔らかい語り口クールで知的な語り口

この切り替えは、プロンプトのPart 1（キャラクターリファレンス）とWriting Voiceを通じて行われます。WriterからArt Directorまで、すべてのエージェントがアクティブな主人公の設定を参照します。

💡 プロンプトエンジニアリングから学んだこと

10体のエージェントのプロンプトを設計する中で得た実践的な教訓をご紹介します：

1.「してはいけないこと」は「すべきこと」より重要

AIに「良い記事を書いて」と言うより、「これはしないで」と伝える方が効果的です。Writerプロンプトでの堅い文体の禁止、<p>タグ内の改行禁止、ノートPC前のシーン禁止など、具体的な禁止ルールが品質を引き上げてくれました。

2. Good/Bad例の威力

「温かいトーンで書いて」の代わりに、具体的なGood/Bad例文を提示すると、AIが望むスタイルを素早く学習してくれます。特に複数言語にまたがってトーンを維持する際に効果的です。

3. プレースホルダーはエージェントを自由にする

プロンプトにパスをハードコーディングすると、環境ごとにプロンプトを修正する必要があります。{work_dir}プレースホルダーを使えば、1つのプロンプトファイルがWindows、macOS、Mac Miniすべてで動作します。

4. モデル選択は役割に応じて

すべてのエージェントに最高のモデルを使う必要はありません。WriterだけOpus、残りはSonnetで十分です。これによりAPIコストが大幅に削減され、Sonnetの速い応答速度のおかげでパイプライン全体も高速化されます。

5. カテゴリプロファイルはスケーラビリティの鍵

プロンプトを直接修正する代わりにYAMLで動作をオーバーライドすれば、プロンプトファイルに触れずにカテゴリ別のカスタム動作を追加できます。コード変更なしでYAML 1つで新カテゴリ対応 — これこそ本当のスケーラビリティです。

📋 次回予告

次のPart 3では、Blog-Agentの2つの実装を比較していきます：

  • blog-agent（v0.8.5）— Claude Code CLIベース、state_cli.pyによる手動オーケストレーション
  • blog-agent-api（v0.2.1）— Claude Agent SDKベース、自動オーケストレーター

同じパイプラインをまったく異なるアプローチで実装した物語、楽しみにしていてくださいね！ 💬

Discover more from AI-Girls Lab

Subscribe to get our latest posts delivered to your inbox.

Thierry K