課題: ブランド情報の散在が修正コストと一貫性をむしばむ
複数チャンネルを同じパイプラインで運用する場合、ブランドの人格を一度定義しても、その後の管理で課題が生じやすい。
台本生成・映像編集・サムネイル設計の各エージェントへ指示を出すたびに、ブランドのトーン・色彩・声質といった情報を毎回プロンプトに書き込む形になる。記述が分散すると、トーンを調整したい場合に修正漏れが発生する。3チャンネルなら見落としは稀だが、10チャンネルになると「このガイドラインはチャンネルA にだけ反映されたが B・C は未適用」という事態が常態化する。また新しいチャンネルを追加するたびに既存コードを複数箇所書き換える必要があり、スケーラビリティに欠ける。
根本原因は「ブランドの定義がコード・プロンプト・ドキュメントに散在」していることだ。修正時の一貫性を保証する仕組みがない。
パターン: ブランド設定駆動（Brand Config-Driven Design）
一行定義: ブランドの人格をすべて単一の JSON 設定ファイルに集約し、パイプラインの全エージェントがそこから読み込むことで、トーン・表現・ビジュアル指針を一貫して保つ設計パターン。
設計の核: 二層構造で「なぜ」と「どう作るか」を分離する
ブランド設定ファイルは単なる値の集合ではなく、上位層（人格定義） と 下位層（実装指示） の二層で構成する。この分離があれば、後からブランド方針を変更した際に各エージェントの実装がズレる危険性を減らせる。
層１: Purpose — ブランドの存在理由と価値観
{
"channelId": "market-news-jp",
"purpose": {
"mission": "金融市場のニュースを、テレビ経済番組のような信頼感と速報性で届ける",
"audience": "株式投資初級者〜中級者、朝のニュースチェック習慣者",
"differentiation": "報道スピードと正確性の両立。複雑なデータを迷いなく説明する",
"constraints": [
"1分以内に起承転結を完結させる",
"ナレーション速度 1.25 倍速でも聞き取りやすい話速"
]
}
}purpose セクションはエージェント向けプロンプトに直接渡される。Scriptwriter は「テレビ経済番組のような信頼感」を見て「『今日は日経平均が…』で始まり、個人投資家への着地まで5文で繋ぐ」という意思決定ができる。
層２: 実装指示 — 各エージェントが読む具体的ガイドライン
{
"scriptwriter": {
"narrator": "professional_female_jp",
"tone": {
"adjectives": ["報道的", "冷静分析", "親切丁寧"],
"examples": {
"good": [
"今日の日経平均は2.3%上げ。背景にはテック買いが。",
"重要なのはここ — PBR 1 倍割れ企業が18社から12社に減った"
],
"bad": [
"すごかったんだけど聞いて？",
"完全自動化で投資は終わり"
]
}
},
"scriptLength": "300-400 words / 2.5-3 minutes",
"pacing": {
"sentencesPerTopic": "3-4",
"talkingSpeed": "words_per_minute: 300"
}
},
"composer": {
"colorPalette": "corporate-blue-gold",
"chartPreference": ["line_chart", "bar_chart"],
"backgroundMusic": "jazz_calm_id: BG_JAZZ_003",
"onScreenTextStyle": "sans-serif_bold_lowercase",
"transitionPace": "medium"
},
"thumbnail": {
"colorTheme": "dark_blue_accent_gold",
"fontWeight": "bold",
"emojiUsage": "minimal",
"numberHighlight": true
},
"design": {
"theme": "src/themes/market-news-jp.ts",
"contrastRatio": 4.5,
"logoPosition": "top-left"
}
}各エージェントは「自分の担当セクションだけ」を読む。Scriptwriter は scriptwriter と purpose を見、Composer は composer を見る。セクションが分かれていることで、「どのエージェント向けの指示か」が自動で明確になり、読み違える危険が減る。
ファイル配置:
config/brands/{channelId}.json— ブランド定義（SSOT）src/themes/{channelId}.ts— 色・フォント・アニメーション値（TypeScript 定数）
config は「方針の言語化」にとどめ、数値ベースの値はテーマファイルに分離する。そうすることで「ブランド方針の変更」と「数値調整」を見分けやすくなり、レビューが効率化する。
トレードオフ分析: なぜ設定駆動か
同じ目的を達成する三つの手段が考えられる。
| 手段 | メリット | デメリット | 適用場面 |
|---|---|---|---|
| 設定駆動（config JSON） | 修正が一箇所。スケール時にコード変更なし。ブランド方針と実装が構造上分離。定義の漏れが可視化される。 | config ファイルと実装プロンプトのズレが生まれやすい。構造化の初期コストが高い。エージェントが config を「本当に読んでいるか」の検証が必要。 | 3チャンネル以上。定期的なトーン調整がある。複数人による管理が必要。 |
| コード埋め込み | シンプル。実装とブランド定義が同じ場所にある。変更時の一貫性が（同じファイルなら）高い。 | チャンネルが増えるたびにコード分岐が増える。AI エージェント間でブランド記述が重複。修正時に全箇所を漏れなく書き換える職人技が必要。 | 1〜2チャンネルのみ。ブランド定義が固定。 |
| 動的マッピング（ルックアップテーブル） | チャンネルごとの個別プロンプトを実行時に生成。理論的には最も柔軟。 | 実行時の複雑性が増す。AI エージェント側でどの値を引いたかが追跡困難。バグが深くなりやすい。テスト負担が高い。 | 極めて動的なブランド管理が必要な場合（実務ではほぼない）。 |
八雲が config 駆動を選んだ理由: Montage はチャンネル数が多く、各チャンネルのトーンを頻繁に調整する。コード埋め込みでは修正漏れの頻度が許容不可になる。また複数のアナリスト・ライターが同じパイプラインを使うため「ブランド定義の一貫性」が組織運営上の要求になる。config に集約することで「ガイドラインは config に書き換えてから AI に投げる」という一本化ができた。
非自明な洞察: 形容詞3個ルール と toneExamples
トーンを定義する際、形容詞の数を 3個までに絞る ことが重要だ。
"adjectives": ["報道的", "冷静分析", "親切丁寧"]
なぜか。AI エージェントは複数の指示を同時に最適化するとき、指示が増えるほど「平均値」へ収束する傾向がある。5個以上の形容詞を渡すと、AI はそれぞれをバランス取ろうとして、結果として「どれにも当てはまらない無色な出力」になりやすい。3個が、AI の判断容量と人間の意図伝達の限界の交点だ。
形容詞の例（チャンネル別）:
- 市場ニュース: 報道的・冷静分析・親切丁寧
- ロボティクス製品レビュー: エキサイティング・分かりやすい・独立系
- 決算分析: 詳細志向・業界通・判断寄り
しかし形容詞だけでは不十分だ。「報道的」という一言では AI エージェントの解釈にブレが生まれる。そこで 具体的なセリフの良い例・悪い例 を toneExamples に入れる。
"toneExamples": {
"good": [
"日経平均はテック買いで2.3%上げ。背景は…",
"重要なのはここ — 利益率が前年比12%改善"
],
"bad": [
"すごかったんだけど聞いて？",
"完全自動化で投資は終わり",
"本日はトヨタ自動車の決算について分析いたします"
]
}「悪い例」を含めることで、エージェントは「こういう話し方は避ける」という負の学習ができる。形容詞3個 + 具体的なセリフ例で、言語化できないブランドの特性が伝わりやすくなる。
トーン調整のケーススタディ
ブランド設定駆動の効果を示す実例。
シナリオ: 市場ニュースチャンネルで、「個人投資家向けから機関投資家向けへシフト」という方針転換が生じた。
修正前の config（個人投資家向け）:
"tone": {
"adjectives": ["分かりやすい", "親切丁寧", "鼓舞的"],
"examples": {
"good": ["今日の値動きで初心者が押さえるべき点は…"],
"bad": ["高周波取引ファンドの売却圧"]
}
}修正後の config（機関投資家向け）:
"tone": {
"adjectives": ["技術分析", "根拠重視", "冷徹"],
"examples": {
"good": [
"テクニカルブレイク：200日線を上抜けした、機関買い圧を示唆",
"バリュエーション：PER 17.2 倍、セクタ中央値を下回る"
],
"bad": [
"初心者向けに砕いた説明",
"感情的な励まし"
]
}
}変更の影響範囲:
- 修正個所:
config/brands/market-news-jp.json1ファイルのみ - Scriptwriter プロンプト: コード変更なし（config を読むだけ）
- Composer プロンプト: コード変更なし
config を更新した翌日のジョブから自動的に新しいトーンが全チャンネル出力に反映される。既存コードには手を加えていないため、別のチャンネルへの副作用もない。
運用上の落とし穴と検証の必要性
落とし穴1: Config と実装の乖離
config にトーン定義があっても、それを読むエージェントのプロンプトが「定義を無視する」場合がある。例えば toneExamples に「機関投資家向けのセリフ」を入れたのに、Scriptwriter のシステムプロンプトが「初心者にも分かるように」と明示されていると、エージェントは config より明示的な指示を優先する。
検証方法: 新しい config を反映した後、実際に出力を数件サンプリングして「tone adjectives に合致しているか」を定性レビューする。レビューエージェントを組み込むのが効果的だ。
落とし穴2: 言語化できない部分を数値で補える限界
ブランドの「雰囲気」「間のとり方」「隠喩の選び方」など、形容詞 3 個では伝わらない部分がある。こうした部分は toneExamples に「実際のセリフ」を具体的に入れることと、人間によるレビューループで補うしかない。AI だけで完全に自動化するには、ブランド定義の精度が限界に達する。
補償戦略: 毎週 1 本のサンプル出力をレビューエージェント（あるいは人間）が確認し、「ブランド外れ」を見つけたら「どの config 項目が不足しているか」を言語化し config に追記する。この反復で定義は自然と充実する。
まとめ
複数チャンネルを同じパイプラインで運用する際、AI エージェント間のブランド一貫性を保つ最良の手段は「ブランドの人格を JSON config に一元化し、すべてのエージェントがそこから読み込む」ことだ。
設計の鍵:
- 二層構造（Purpose + 実装指示セクション）で「なぜ」と「どう作るか」を分離する
- トーン定義は形容詞 3 個 + 具体的なセリフ例に絞る
- 色・フォント・数値はテーマファイルに分離し config は方針言語化にとどめる
- 新しいチャンネルは config ファイル追加のみで既存コードに影響しない
- 修正後は実装との乖離チェック。言語化できない部分は toneExamples で補い、レビューループで繰り返す
ブランドの一貫性は「毎回同じ指示を渡す」ことではなく「同じ定義ファイルをすべてが参照する」構造から生まれる。シンプルで破りにくい仕組みが、AI との協働には何より効く。