アプリ権限と承認ロールを分ける
システムのAdminであることと、法務として承認できることは同じではありません。アプリ権限はデータを閲覧・編集できるかを決め、承認ロールはどの部門の責任で判断できるかを決めます。
アプリ権限
→ データを閲覧・編集できるか
承認ロール
→ どの部門の責任で承認できるかクライアントが送信した「legal」という値をそのまま信用せず、OrganizationとBrandごとに割り当てられた現在の承認ロールをサーバーで確認します。
課題種別で承認を変える
- 事実誤認・古い情報：マーケ＋広報
- コンプライアンスリスク：法務＋事業責任者
- 競合負け・未言及：マーケ＋事業責任者
- 引用不足・ページ品質：マーケ
すべての課題で四部門の承認を要求すると運用が止まります。課題の性質と重大性に応じて、必要なロールだけを求めます。
職務分離
複数部門の承認が必要な場合、一人が複数ロールを兼任すると説明責任が弱くなります。たとえばコンプライアンスリスクで、同じ担当者が法務と事業責任者の両方を承認する状態は避けます。
職務分離を実装する際は、次を確認します。
- 承認ロールの割り当て者
- 現在のOrganization Membership
- 現在のBrandスコープ
- 既存承認の承認者
- 課題の最新Version
- 必要なロールと完了済みロール
セキュリティ・法務チェックリストでは、承認以外のEnterprise統制も整理しています。
残すべき証跡
承認をIssue内の配列だけで管理せず、不変の承認記録として残します。
- Issue
- 承認ロール
- 承認者
- コメント
- 日時
- 改ざん検知用ハッシュ
- 承認時のIssue Version
同じIssue・Roleに対する上書きや物理削除を簡単に許すと、後から判断経緯を説明できません。取消が必要な場合は、取消の理由と新しい承認を別イベントとして記録します。
承認前に確認するEvidence
承認ボタンだけではガバナンスになりません。承認者が最低限確認できる情報を揃えます。
- 実際のAI回答
- 引用URL
- 承認済みファクト
- PromptとAI面
- 言語・地域・取得日時
- 重大性と事業影響
- 推奨アクション
- 需要代理値の算定方法
- 信頼済みサンプル数
証拠不足の課題は承認できないようにします。
承認後の流れ
承認された改善アクションをProjectへ変換し、担当者、期限、タスク、Baselineを設定します。プロジェクト完了後は、同じPrompt×EngineでOutcomeを測定します。
改善アクションの製品ページでは、上位5件から承認・Projectへ進む体験を紹介しています。
まとめ
AI回答の承認ワークフローでは、Admin権限、承認ロール、課題種別、Evidence、職務分離を分けて設計します。誰がどの立場で何を確認したかを残せることが、日本企業向けガバナンスの中核です。