PMBOK第8版が問うAI統制 その2 ～ AIガバナンスを支えるYAML記述と自然言語翻訳の思想

はじめに

これまでの過去5回の記事において、PMBOK第8版で求められているAI活用のポリシーを、どのように業務へ落とし込んでいくべきか検討してきました。日々の仕事に追われている現場のPMの負担を最小限にしつつ、組織の「AIポリシー」を実際のプロジェクトへ適用できるのか、という視点で考察を重ねてきました。

過去の関連記事

• PMBOK第8版のAIポリシー実装の集大成　組織を動かす6ゲートモデル
• PMBOK(R)第8版のAIポリシーの説明責任を実装する　ガバナンスエンジンによるリスク可視化
• PMBOK第8版が示すAIポリシーを実装する　三層構造と検証から見えた論点
• PMBOK第8版はAIをどう位置づけているのか　三層AIポリシーで読み解くAI活用の前提
• AI導入の本質とは？──理念から業務へ落とし込むためのパラダイム・シフト
• PMBOK第8版が問うAI統制 現場主導のAIガバナンスオーケストレータ　その１

本稿では、このYAMLポリシーがどのように記述され、どのようなロジックで「安全な例外」を実現して
いるのか、その設計思想と実務的な実装方法を解説していきます。

組織の防衛と現場の例外は両立できるか

AIの利用が全社に広がる中で、多くの組織が「ルールの粒度」というジレンマに直面しています。全社一律で「個人情報の入力禁止」と厳しく縛れば、開発現場でのテストや特定のプロジェクトにおけるNDA(秘密保持契約)に基づいた正当な業務まで止まってしまいます。しかし、現場の裁量に任せすぎれば、組織として守るべき防衛ラインは容易に突破されてしまうでしょう。
この「組織としての防衛」と「現場の柔軟性」は、長らく二者択一のものと考えられてきました。ルールを厳しくすれば利便性が損なわれ、利便性を優先すればリスクが高まる。このトレードオフを解消する鍵は、ガバナンスを一つの「静的な壁」としてではなく、多層的な「動的な評価体系」として再構築することにあります。
AIガバナンスオーケストレータが採用しているのは、YAMLポリシーを用いた「3層構造」のモデルです。これは、社則や法令を定義する「組織層」、プロジェクト固有の要件を反映する「プロジェクト層」、そしてユーザー個別の例外を扱う「個人層」を独立させつつ、それらを厳密な優先順位で統合する仕組みです。

ルールは、適用したい範囲に合わせて3つの階層のYAMLファイルで管理されます。

• 組織ポリシー (org.yaml): 全てのチャットやプロジェクトに共通して適用される基本ルールです。
• プロジェクトポリシー (project.yaml): 特定の案件や顧客ごとの固有ルールです。
• 個人ポリシー (personal.yaml): ユーザー個人の業務スタイルや習慣に合わせたルールです。

（これらは、組織＞プロジェクト＞個人の優先順位で評価されます。）

ガバナンスの形をつくるレシピ

前章で解説した「3層構造」という構造は、組織の階層に応じたルールの棲み分けを可能にしました。しかし、実際に検知された言葉に対して「どのようなアクションをとるか」というロジックこそが、ガバナンスの実効性を左右します。
AIガバナンスオーケストレータは、検知したキーワードやパターンに対して、主に4つの「レシピ(ロジック)」を使い分けることで、画一的ではない柔軟な制御を実現しています。

判定ロジックの比較

4つのパラメータがどのような挙動を示すのかを整理します。

パラメータ名	判定（カラー）	通信の動作	主な用途
DENY	RED（即時遮断）	ブロック	絶対禁止（クレカ番号、特定顧客名など）
ALERT	記録のみ	通過	監視対象（不適切な可能性はあるが制限はしない）
CONDITIONAL ALLOW	YELLOW（要確認）	ユーザー承認後に通過	現場の判断が必要な例外事項
MANDATORY ALLOW	PASS（無条件許可）	即時通過（AI審査スキップ）	信頼された技術用語、誤検知回避ワード

各レシピの詳細と設計思想

「DENY（絶対ブロック）」
特定のクレジットカード番号や、組織として一切の送信を禁じている機密情報を定義します。このルールにマッチした瞬間、通信は後続の評価を待たずに即座に遮断されます。これは組織の防衛における最後の一線であり、プロジェクトや個人の裁量が及ばない領域です。

「ALERT（監査通知のみ）」
実務において非常に重要なのがこのALERTです。通信そのものは止めませんが、その事実を監査ログに刻みます。ブロックするほどではないが、頻出するようなら教育やルール見直しが必要といった、ガバナンスの「予兆」を検知するためのセンサーとして機能します。

「CONDITIONAL ALLOW（条件付き許可）」
基本的には注意が必要だが、正当な理由があれば許可したいケースに用います。このレシピが発火すると、ユーザーの画面には承認ダイアログが表示されます。ユーザーが自ら「送信を許可する」という意思表示をすることで初めて通信が成立します。このプロセスにより、ユーザー自身にガバナンス意識を持たせると同時に、正当な業務を阻害しない柔軟性を確保します。

「MANDATORY ALLOW（無条件許可・承認）」
特定のワードを「完全に信頼する」という宣言です。通常、Covenantは複数のゲート（Gate 2.5の文脈審査やGate 3の履歴評価）を経て最終的な安全性を確認しますが、MANDATORY ALLOWにマッチしたワードは、これらの後続審査をすべてスキップして「PASS」となります。セキュリティスキャンで頻繁に誤検知される特定の技術用語などをこのリストに加えることで、システムの利便性を向上させます。

その「承認」は全幅の信頼か？

ここで一つ、実務上の重要な問いを提示します。「PMが承認したルール（CONDITIONAL ALLOW）であれば、無条件にAI審査をスキップしてもよいか？」という問いです。

Covenantの設計思想では、答えは「NO」です。PMの承認はあくまで「その正規表現が示す範囲」の許可に過ぎません。その言葉が何度も繰り返されることで構成される「累積的な履歴リスク」や「倫理的リスク」までは、個別の承認ではカバーしきれないからです。

この「承認済みルールでも、なおAIによる多軸評価を継続する」という二重の安全網こそが、AIガバナンスオーケストレーターが単なるキーワードフィルターと一線を画す点です。次章では、この「壊してはいけない不変条件」を支える、厳格な評価順序のロジックについて解説します。

現場の負担をなくす「自然言語とYAMLの翻訳機」

ここまで、多層構造のYAMLポリシーやロジックについて解説してきました。しかし、ここで一つの大きな疑問が浮かびます。

「現場のPMや開発者が、このような複雑な条件を持つYAMLを、ミスなく手書きできるのだろうか？」

答えは、多くの場合「NO」でしょう。多忙なプロジェクトの最中に、正規表現の妥当性を検証し、不変条件を遵守したYAMLコードを記述するのは、現実的ではありません。無理に手書きを強行すれば、設定ミスによるセキュリティホールや、承認の無限ループといった二次災害を招く恐れもあります。

この「理想（厳格な統制）」と「現実（運用の負荷）」の溝を埋めるのが、AIガバナンスオーケストレーターの「自然言語←→YAML翻訳機」です。

申請は「言葉」で、管理は「コード」で

この機能の最大の特徴は、現場の人間が一度もYAMLに触れることなく、安全なルールを追加できる点にあります。

例えば、ある開発者が「プロジェクトAの住所録共有のため、住所という言葉を含む入力を一時的に許可してほしい」と考えたとします。開発者はその意図を自然言語でシステムに伝えます。PMはその申請内容を確認し、ボタン一つで「承認」します。

すると、プロンプトラッパーが作動し、以下のようなYAMLコードを自動生成します。

翻訳機で生成されたYAML記述

- id: RULE-PROJECT-AUTO-001
  title: 住所情報の共有許可（PM承認済み）
  effect: ALLOW
  control_level: CONDITIONAL
  pm_approved: true
  gate2_5_eval: false
  condition:
    regex_match: '住所'
  description: PM承認済み例外。業務上の住所情報共有を許可します。

安全なルール生成

この自動生成には、人間の手書きでは到達しにくい「3つの安全性」が組み込まれています。

• 最小限の正規表現： 意図を捉えつつ、広すぎて他の禁止事項まで巻き込まない「最小の正規表現」をAIが考案します。
• 不変条件の自動遵守： 第3章で述べた「CONDITIONAL + pm_approved: true」といった属性が、システム側で強制的に付与されます。
• 無限ループの防止： 判定と承認が繰り返される「無限ループ」を引き起こさないよう、特定のフラグ（gate2_5_eval: false）が正確にセットされます。

自然言語のポリシーを翻訳するとどうなるか？

明らかに人間の作った自然減のルール・ポリシーの翻訳例を見てみます。

YAML記述のパラメータ別の解説

パラメータ	設定内容・意味	実務上の役割
id	ID_PLACEHOLDER	ルールを一意識別するためのIDです。自動生成時は「RULE-PROJECT-XXX」などのユニークな値が入ります。
title	プロジェクトリスクおよび重要課題管理情報入力禁止	管理画面や監査ログに表示されるルールの名称です。何のための制限かを人間が理解するために記述します。
effect	DENY	基本的な動作方針を「拒否（ブロック）」に設定します。このルールが最終的に「適用」と判断されると、通信はRED判定となります。
condition	regex_match: ...	検知のトリガーです。指定された正規表現（リスクレジスタ、ベンダー評価など）がプロンプトに含まれているかをチェックします。
gate2_5_eval	true	本ルールの肝となる設定です。通常、DENYはマッチした瞬間に遮断しますが、これをtrueにすることで「AIによる文脈審査（Gate 2.5）」へと処理を回します。
description	テキストが、プロジェクトの成否に関わる...	Gate 2.5で審査を行うAI（軽量LLM）に対する、判定基準の「補足指示」として機能します。

このルールの動き（ロジックフロー）

この設定が施されたルールは、以下のステップで評価されます。

1. ステップ1：パターンマッチング（Gate 1/2） ユーザーの入力テキストに「リスクレジスタ」や「ベンダー評価」などの言葉が含まれているか正規表現でスキャンします。
2. ステップ2：文脈審査へのエスカレーション（Gate 2.5） 言葉がヒットしても、すぐにはブロックしません。gate2_5_eval: trueが指定されているため、テキストとdescriptionの内容をセットでAI審査（Gate 2.5）に送ります。
3. ステップ3：AIによる評価
   Gate 2.5のAIは、最終判定を下すのではなく、文脈を評価して次のゲートへのパス（経路）を決定します。
   「Gate 2.5が『Unsafe（有害の恐れあり）』と評価した場合」 ここでRED判定として即時遮断するわけではありません。AIは「これは単なる言葉の誤検知ではなく、本当に機密リスクが含まれている可能性が高い」と評価し、処理をエスカレーション（引き継ぎ）します。
   ただし、直接Gate 3に向かうのではなく、まずは一般無害評価の高速プレフィルタである「Gate 2.8」を経由します。Gate 2.8で「無害」と判定されればGate 3はスキップされますが、そうでない場合に初めて、より多角的な履歴・倫理リスクを審査する「Gate 3」へと到達します。
   最終的なRED判定等の決定は、システム全体のロジックに委ねられます。「Gate 2.5が『Safe（無害・誤検知）』と評価した場合」 文脈から見て一般的な用語の使用（例：一般的なベンダー評価の手法に関する質問など）であると評価された場合、システムの判断を「YELLOW判定（PM承認待ち）」へと移行させます
   （※システム上、「Safe」は「悪意ではないがPMの承認が必要」という意味として扱われます）。現場のPM（ユーザー）が内容を確認し、承認すれば通信が許可されます

※補足
Gate 2.5 の発動条件は「ポリシーで gate2_5_eval=true を指定したルールがヒットした場合のみ」です。ヒットが無ければ Gate 2.5はそもそも走らず、Gate 2 → Gate 2.8 → Gate 3 と進みます。

つまり「Gate 2.5 はすべての入力に対して走る」わけではなく、「正規表現では白黒つかないので文脈評価で判断する」とポリシー側が明示したルールに対してのみ起動する補助審査です。この設計が、何を Gate 2.5 に委ねるかは org/project/personal.yaml 側の設計判断になります。

まとめ表

effect	control_level	pm_approved	gate2_5_eval	結果
ALLOW	MANDATORY	–	False	即時 PASS（Gate 2.5/3 スキップ）
ALLOW	CONDITIONAL	False	False	YELLOW / Gate 2 (PM Approval)（＝PM 承認待ち）
ALLOW	CONDITIONAL	True	False	PM 承認済扱い → Gate 2.5/2.8/3 続行
ALLOW	CONDITIONAL	任意	True	Gate 2.5 に送られる（PM 承認判定より優先）

この記述のメリット

「ベンダー評価」という言葉自体は、一般的なニュース記事の要約などでも使われる可能性があります。これを一律でブロックすると利便性が下がりますが、gate2_5_eval: true を使うことで、「単語の有無」ではなく「機密を漏らそうとしている文脈か」をAIに二段構えで判断させることができ、誤検知を大幅に減らせるようになります。

まとめ：ポリシーの「外出し」がもたらす組織の知的財産

本稿では、AIガバナンスオーケストレーターにおけるYAMLポリシーの構造と、その運用を支える思想について解説してきました。

ルールをAIモデルの内部に閉じ込めるのではなく、独立した「YAML形式」として外出しし、それを自然言語で制御できるようにすることには、単なる効率化を超えた5つの大きなメリットがあります。

1. 機密保護と利便性の両立（自動ルーティング）

情報の機密レベルに応じて、クラウドAIとローカルAIを自動的に使い分けることが可能になります。絶対に漏洩させられない情報はローカルで、公開可能な情報は高性能なクラウドAIで処理するという「適材適所」の運用により、安全性を確保しながら最速の結果を得られます。

2. 顧客・プロジェクトごとの混同防止（3層ポリシー）

ルールを「組織」「プロジェクト」「個人」の3層で管理することで、複数の顧客や案件を抱えるプロフェッショナルであっても、異なるNDA（秘密保持契約）を混同することなく、安全にAIを活用できます。

3. 知的財産としてのルールの育成

ガバナンスのルールは、一度設定して終わりではありません。日々の業務の中で例外を承認し、新しいルールを積み重ねていくことで、システムはユーザー自身の業務スタイルに最適化されたツールへと育っていきます。蓄積されたルールは、他者には真似できない貴重な「知的財産」となります。

4. AIモデルに依存しない資産形成

ルールが独立したYAMLファイルとして管理されているため、特定のAIモデルに依存しません。数ヶ月単位で新しいAIが登場する現在においても、育てたルールや履歴をそのまま引き継ぎ、長期的な業務インフラとして活用し続けることができます。

5. 顧客に対する「説明責任」の確保

「AIが勝手に判断した」のではなく、「自分が定めたルールに従い、私が最終判断した」と胸を張って第三者に説明できる透明性が生まれます。また、監査レポートを通じて「機密情報を適切に扱っていること」を証明でき、顧客からの確固たる信頼に繋がります。

おわりに：現場の負担を減らし、「人がAIを統治する」仕組み

AIガバナンスオーケストレーターが目指している本当のゴールは、単にセキュリティルールを強化することではありません。複雑な設定管理から現場のPMや技術者を解放し、「AIに判断させるのではなく、人が判断してAIを制御する」という、本来の主従関係を構築することにあります。

AIは確かに優秀なツールであり、膨大な文脈を読み解く「評価」には長けています。しかし、その通信がビジネスにおいて本当に安全かどうか、組織の倫理や顧客との約束に反していないかという最終的な「判定」までをAI任せにしてはいけません。プロジェクトの背景を理解し、その結果に責任を持てるのは人間だけだからです。

とはいえ、人間が主導権を握り続けるために、現場のエンジニアが毎回難解なYAMLコードと格闘しなければならないとすれば、それは本末転倒です。システムの防衛のために現場の業務が止まってしまっては意味がありません。

「自然言語←→YAML翻訳機」や「Gate 2.5による評価のエスカレーション」といった機能はすべて、このジレンマを解消するために存在します。技術的な記述の難しさはシステムが裏側で吸収し、現場の負担を取り除く。そして人間は「自らの言葉で例外を申請し、意志を持って承認する」という、一番大切な判断業務のみに集中する。

これこそが、AIガバナンスオーケストレーターが提供したい「人がAIを統治する」ための基盤です。