enterprise-brand-governor

エンタープライズ向けブランドガバナー

AI 生成画像のポリシーをコードとして管理します。すべてのプロンプトを brand.md に照らして事前検証し、すべての出力を事後チェックします。違反は人間の承認者にエスカレーションされ、すべての判断が記録されます。規制の厳しい業界や、ブランドに沿わないアセットが本番環境に混入すると重大なリスクになるあらゆる企業向けに構築されています。

---

使用する場面

• マーケティング、製品、営業、代理店パートナーなど、複数のチームが同じブランドシステムを使って生成する場合
• 画像に法的制約がある規制業界（製薬、金融、アルコール、子ども向け）
• ブランドセーフティ SLA がある場合 — 競合他社のロゴ、制限対象の小道具、ブランドのカラーパレットに沿わない出力が本番環境に到達することを一切許容しない場合
• 代理店への引き継ぎ — 外部ベンダーが自社ブランドに沿って生成する際、自社で管理できるゲートが必要な場合
• 本番前のレビューサイクルを自動化し、人間はエスカレーションされたものだけをレビューする場合

次の用途には使用しないでください：手早い試作やムードボードの作成（ゲートが発想を遅らせます）、またはまだ文書化されたブランドシステムがないアカウント（まず brand.md を作成してください）。

---

前提条件

ガバナーをチーム全体に展開する前に、次の点を確認してください。

1. ブランドシステムの場所 — brand.md のパス／リポジトリ／URL。所有者は誰ですか？変更管理プロセスはどうなっていますか？
2. ポリシーの厳格さ — 拒否（停止）、フラグ付け（記録して許可）、またはアセットの用途に応じた段階的な制御（本番環境では拒否、内部用途ではフラグ付け）にしますか？
3. 承認フロー — フラグ付きアイテムをレビューするのは誰ですか？エスカレーションへの対応 SLA はどのくらいですか（1 時間、24 時間、3 営業日）？
4. ログの保存先 — ローカルの ~/.gen-ai/audit/、S3 バケット、または SIEM（Splunk、Datadog）への送信ですか？
5. コンプライアンス上の制約 — brand.md に組み込む必要がある GDPR／HIPAA／COPPA／金融サービス関連の規則はありますか？
6. ロールバック計画 — ガバナーが正当なリリースをブロックした場合、誰が上書きを承認でき、その記録はどのように残しますか？

---

実行方法

ガバナーは、プロンプト、生成、出力の 3 つのチェックポイントで動作します。

1. brand.md を作成する — カラーパレット、タイポグラフィ、許可／禁止する小道具、画像スタイル、トーン、規制対象カテゴリのルールを記述します。Git でバージョン管理します。コミット SHA がポリシー ID になります。
2. 事前チェック（プロンプトのリント） — クレジットを消費する前に、プロンプトに対して gen-ai validate を実行します。禁止語、許可されないコンセプト、必須要素の欠落（免責事項の配置など）を検出します。
3. ブランドコンテキストを適用した生成 — すべての gen-ai generate と gen-ai batch run のプロンプトに、関連する brand.md の制約を含めます。QA 中に違反を確認します。
4. 事後チェック（出力チェック） — 重要なアセットでは、2 回目のモデル（gemini-3-pro-image またはビジョンチェック）を使って、出力がポリシーに適合していることを確認します。カラーパレットのサンプリング、ロゴの有無の検出、小道具の許可リストを使用します。
5. エスカレーション — ステータスが violation のものは、すべて承認者のキューに送られます。人間がレビューして承認または却下し、その判断は監査 ID に関連付けて記録されます。
6. 監査データのエクスポート — 設定済みの SIEM またはコンプライアンスアーカイブに、すべての判断を毎日／毎週エクスポートします。

クイックリファレンス

ガバナーは、すべてのジョブレコードにポリシーメタデータを追加します。

{
  "defaults": {
    "model": "flux-2-pro"
  },
  "metadata": {
    "policy_id": "brand.md@sha:a4f1c9",
    "policy_version": "2.3.0",
    "policy_mode": "reject",
    "approver": "[email protected]",
    "escalation_channel": "#brand-review",
    "audit_id": "GOV-2026-04-CAMPAIGN-LAUNCH",
    "compliance_tags": ["GDPR", "US-FTC-native-ad"],
    "data_residency": "eu-west-1"
  },
  "jobs": [
    {
      "id": "launch-hero-001",
      "prompt": "Production launch hero. Editorial hero, team of four diverse professionals collaborating, modern office, natural light, brand palette. Apply brand.md constraints and require legal review before publishing."
    }
  ]
}

後続の監査台帳には、理由とともにポリシー判断を approved、flagged、rejected のいずれかで記録してください。

---

クイックリファレンス

サブタスク	モデル	備考
プロンプトのコンプライアンスチェック	gpt-image-1.5 / テキスト推論モデル	画像生成のクレジットを消費する前に行う低コストの事前チェック
一次生成（ブランドセーフ）	flux-2-pro	プロンプトへの高い忠実度、商用利用に適しています
一次生成（製品の正確性）	flux-kontext-pro	被写体を保持する必要がある場合は編集モードを使用
生成後のビジョン監査	gemini-3-pro-image	ポリシーチェックに適した高いシーン理解能力
承認済みの出力のみアップスケール	topaz-upscale-image	承認前のアップスケールは避けてください — クレジットが無駄になります

各プロバイダーの商用利用可否は、gen-ai models info <id> で確認してください。製薬業界と金融サービス業界では、事前承認済みモデルの短い許可リストを維持してください。

---

手順

• brand.mdはコードとして扱います。 バージョン管理し、レビューし、署名します。このファイルのコミット SHA が、すべての監査記録におけるポリシー ID になります。
• モデルのバージョンは必ず固定します。 モデルが変わるとポリシーの解釈も変わります。enterprise-pinned-registryと組み合わせてください。
• 費用をかける前に事前チェックします。 gen-ai validateを実行すれば、違反の80％を費用ゼロで検出できます。
• 却下時は人間が関与します。 却下はツールの判断ではなく、ビジネス上の判断です。承認者に回してください。
• フラグではなく、デフォルトで却下します。 フラグモードは下書き専用です。本番では却下する必要があります。
• すべて記録します。 すべてのプロンプト、すべての判断、すべての例外承認を記録します。黙って承認することはありません。
• 監査ログをローテーションします。 JSONL を毎日出力し、開発マシンの外に送信します。ローカルログは消えますが、SIEM のログは消えません。
• 敵対的なプロンプトでガバナーをテストします。 四半期ごとに自社のポリシーをレッドチームで検証します。競合他社のロゴや禁止されている主張を本当に検出できるでしょうか？
• 例外承認の手順を文書化します。 正当な例外は必ず発生します。例外承認を可視化して記録し、期間を限定してください。

---

注意点

• brand.mdが曖昧すぎる — 「ブランドパレットを使う」では適用できません。16 進カラーコード、許可する小道具のリスト、明示的な禁止項目を指定してください。
• 例外承認の手順がない — 正当な例外がシステム外で処理され、監査に支障をきたします。例外承認の仕組みを組み込んでください。
• ログがローカルにしかない — 開発マシンは故障します。初日から SIEM または耐久性のあるアーカイブに送信してください。
• 本番環境でのフラグモード — 「後で確認する」ことは、決して実行されません。デフォルトで却下してください。
• 監査なしのモデル切り替え — 誰かがキャンペーンの途中でflux-2-proを新しいモデルに切り替え、ポリシーの解釈が変わる可能性があります。バージョンを固定してください。
• ヒーロー画像の生成後チェックがない — プロンプトは通過しても、出力は通過しないことがあります。本番用のヒーロー画像では、必ずビジョン監査を実行してください。

---

検証

gen-ai whoamiを実行して認証を確認し、失敗したコマンドを--debugを付けて再実行してください。

コマンド

# Pre-flight validate a prompt before spending credits
gen-ai validate --model flux-2-pro --file prompt.json

# Gated single generation
gen-ai generate --model flux-2-pro --prompt "$PROMPT" \
  --save-to-drive --drive-folder "Gated-Output"

# Gated batch with retry on transient failures only (not violations)
gen-ai batch run campaign.json \
  --concurrency 4 --output ./runs/campaign-2026-04

# Flag mode — for internal / draft contexts
gen-ai batch run drafts.json \
  --output ./runs/drafts-2026-04

---

費用と時間

ガバナンスにかかるオーバーヘッドは、生成に比べてごくわずかです。重要なアセットでは事前チェックと生成後チェックによってクレジット費用が約10～15％増加しますが、重要度の低いアセットでは約0％です。

シナリオ	ガバナンスのオーバーヘッド
ゲート付きの単一生成	+0 クレジット（ポリシーは呼び出し時に通過）
単一生成 + ビジョン監査	+1～2 クレジット
100件のバッチ、事前チェックのみ	+約5 クレジット（テキスト推論モデル）
1,000件のバッチ、完全なパイプライン	+約50 クレジット + 承認者の作業1時間
四半期ごとのレッドチーム監査	約1エンジニア日 + 約200クレジット

違反を却下すれば、クレジットを節約できます。ブランドにそぐわない本番用アセットを1件ブロックするだけで、通常、ガバナーのオーバーヘッドを何倍も上回る費用を節約できます。

---

関連項目

• enterprise-pinned-registry — ポリシーの解釈を安定させるため、モデルのバージョンを固定します
• product-photo-studio — ブランド制約付きの商品カタログパイプライン（再撮影モード）
• enterprise-press-batch — 公開禁止期間の管理を含む、ブランド制約付きPRパイプライン
• gen-ai-use — CLI リファレンス