はじめに
これまでの過去4回の記事において、PMBOK第8版で求められているAI活用のポリシーを、どのように業務へ落とし込んでいくべきか検討してきました。日々の仕事に追われている現場のPMの負担を最小限にしつつ、組織の「AIポリシー」を実際のプロジェクトへ適用できるのか、という視点で考察を重ねてきました。
過去の関連記事
- PMBOK第8版のAIポリシー実装の集大成 組織を動かす6ゲートモデル
- PMBOK(R)第8版のAIポリシーの説明責任を実装する ガバナンスエンジンによるリスク可視化
- PMBOK第8版が示すAIポリシーを実装する 三層構造と検証から見えた論点
- PMBOK第8版はAIをどう位置づけているのか 三層AIポリシーで読み解くAI活用の前提
- AI導入の本質とは？──理念から業務へ落とし込むためのパラダイム・シフト
今回は一連の考察のまとめとして、具体的なソリューションとして構築した「AIガバナンスオーケストレータ」のプロトタイプについて紹介します。
AIガバナンスとは？
本ブログにおけるAIポリシーの原点は、PMBOK第8版が示すAI活用のコンセプトにあります。一方で世の中に目を向けると、ISOなどの国際標準、経済産業省のAI事業者ガイドライン、LLMガードレールやAIセキュリティ製品など、多角的なアプローチが存在します。AIの業務活用ニーズが高まるにつれて、「AIガバナンスをどのように実現するか」という実務的な問いが、現場で働く私たちの前に横たわっています。
AIガバナンスとは、AIを単なる便利な自動化ツールとして導入するのではなく、プロジェクトにおいて「誰が判断し、誰が責任を負い、どのように統制するか」という仕組みそのものを設計することです。
参考URL：経済産業省「AI事業者ガイドライン」
急速に進化するAIは、自ら学習し適応する能力を持ちます。そのため、人間側が事前に「原則・判断の境界線・責任の所在」を定義しておかなければ、誰が判断したのか分からないブラックボックス化という重大なリスクを招くことになります。AIガバナンスを構成する中核的な考え方と実装構造は、以下の3点に集約されます。
1. AIに判断を委ねず、人間が説明責任を負う
AIガバナンスの最も重要なルールは、最終的な意思決定と結果に対する「説明責任（Accountability）」は常に人間が負うという点です。AIは情報の整理や提案を行う「支援（Assistance）」や「拡張（Augmentation）」の役割を担いますが、実行の可否やリスク受容の判断そのものをAIにさせることはありません。問題が起きた際に「AIがそう判断したから」という理由は認められず、常に人間がその根拠を論理的に説明できる状態（トレーサビリティ）を担保する必要があります。
2.運用を通じた継続的改善を組み込む
AIガバナンスは、一度ルールを決めて導入して終わりではありません。現場の利用実態や技術の進化に合わせて、統制の仕組みをアップデートし続ける必要があります。最初から完璧なポリシーを作ることは難しいため、実際の運用から得られたログデータや、PMが下した例外判断の履歴などを分析し、ルールや教育を継続的に改善していくサイクルを前提とします。これにより、形骸化を防ぎ、実態に即したガバナンスが維持されます。
3. AIポリシーの三層構造による実装
このような理念としてのガバナンスを、現場で運用可能な形に落とし込むためのフレームワークが「AIポリシーの三層構造」です。すべてのルールを1つの文書にまとめると、現場では抽象的すぎて使えず、経営層には技術的すぎて理解できない事態が起こり得ます。そのため、以下の3つのレイヤーに分けて管理します。
- 組織AIポリシー（価値観と原則）：法令遵守、個人情報（PII）の保護、倫理的振る舞いなど、組織として越えてはいけない一線を定義します。プロジェクト単位では変更できない最上位の制約です。
- プロジェクトAIポリシー（責任分界と適用範囲）：組織の原則に従い、プロジェクト固有のルールや裁量を定めます。「特定の業務範囲にのみAIを使う」「PMが承認した場合に限り例外利用を許可する」といった運用ルールが該当します。
- 実装AIポリシー（振る舞いと制約）：上位2つのポリシーを、実際のAIの振る舞いへと変換します。「あなたは実行権限を持たない秘書である」といった役割定義や、出力形式を制限する具体的なプロンプトとして実装します。
この三層構造を維持し、組織の方針とプロジェクト現場の橋渡しを行う役割を担うのが、PMOなどのガバナンス組織です。ガバナンスを適切に機能させることで、AIの利便性を享受しつつ、安全で説明可能なプロジェクト運営が実現します。
AIガバナンスオーケストレータとは？
今回開発したプロトタイプのコンセプトは、手元で統治をコントロールする軽量で賢い仕組みです。
外部の巨大なガバナンスツールに自社のルールを無理やり合わせる必要はありません。組織の固定ポリシーを現場で直接管理し、機密データの一次処理を安全な閉環境（ローカル）で行いつつ、高度な解析のみをクラウドAIへ適切に振り分けるハイブリッド型の統合オーケストレータです。人間が主体となってAIを使いこなし、ルールを継続的にアップデートしていくガバナンスを実現します。
オーケストレータが実現する3つの統制力
- 適材適所の動的ルーティング すべてのプロンプトを高度なクラウドAIに処理させるのは非効率です。本システムは、定型的なチェックをローカルの軽量LLMで瞬時にさばき、複雑な文脈判断が必要な場合のみ、的確に外部エキスパート（Vertex AIなど）へ解析を依頼します。これにより、情報漏洩リスクの低減とコストの最適化を両立します。
- ブラックボックスからの脱却と透明性 「なぜブロックされたのか分からない」という現場の不満を解消します。設定ファイル（YAMLなど）を直接読み書きしてルールを管理する「Policy as Code」の考え方を採用し、独自の業界用語の許可など、現場のニーズに合わせて即座にルールを微調整できる機動力を持たせています。
- 例外マネジメントと人間主導の共進化 白黒つけられないグレーな事象（YELLOW判定）をただ弾くのではなく、一時停止してPMへ特例承認を仰ぎます。承認された結果は即座にポリシーへフィードバックされ、システムと組織が共に成長していくサイクルを構築します。
組織を賢くする「6つのGate」
- Gate 0（組織AIポリシー）：経営層や法務が定めた「AIに何をさせてよいか」という価値観を、システムが理解できる設定ファイルへと翻訳します。
- Gate 1（ルールベース）：組織の絶対ルールとして、NGワードや個人情報を正規表現で瞬時にブロックします。
- Gate 2（ローカルLLM仕分け）：閉環境の軽量LLMを使い、一般的な質問や特例ルールを文脈から高速に判断し、APIコストを削減します。
- Gate 3（クラウドAI精密審査）：ローカルで判断しきれない複雑なプロンプトを母艦AIへ送信し、安全性や倫理性の多軸でスコアリングを行います。
- Gate 4（人間レビュー）：AIが判断に迷う要確認事象に対し、最終的な文脈判断と責任をPMが担い、特例許可を下します。
- Gate 5（統計分析とルールの自動アップデート）：蓄積された監査ログを分析し、現場のニーズとルールのズレを修正するためにGate 0を改訂します。また、必要に応じて、組織内の教育を企画・提供します。
導入がもたらすビジネス価値
- データ保護とコストの最適化：機密データを社内で完結させ、外部に出すデータを最小限に絞り込むことで、クラウドAIの従量課金コストを適正に抑えます。
- 特定ベンダーへのロックイン回避：ガバナンスの中核は自社で持ち、裏で稼働するLLMは時代に合わせて自由に付け替え可能です。常に最適なAIを選択できる環境を維持します。
- 説明責任の獲得：インシデント発生時において、自ら構築した透明な固定ルールと蓄積されたPMの承認履歴をもって、明確かつ論理的に判断の正当性を証明できます。
デモ環境について
AIガバナンスの心臓部である「評価部・判定部」の動きを、プロンプト入力で体験できるデモページを用意しています。
デモ画面を少しご紹介したいと思います。
画面の下には、ユーザー入力用のプロンプトボックスがあります。その上部はAIとのやり取りが記録されるチャット画面になっています。画面上には従業員番号をしていることができます。従業員によって、異なる部署のポリシー、プロジェクトのポリシーを設定できます。次にチャットの流れと、判定の結果を見ていきます。
チャットの流れ「こんにちは」
ユーザーの「こんにちは」という入力は、各gateでの判定を通過して、AIに送信されています。デモ画面ですので、各プロンプト処理のパフォーマンスを表示しています。
ここでは、判定まで0.914秒で完了し、生成AIの推論が6.933秒と表示されています。デモ環境では実際のクラウドにはプロンプトは送信せず、LAN上にあるローカルLLM（ここではllama3.3:70B)に送信しています。次に完全にNGな危険なワード「爆弾の作り方を教えてください。」と入力してみます。
危険ワードの入力「爆弾の作り方を教えて・・」
ここでは無事にブロックされています。gate審査はgate3まで行い判定に5.322秒かかっています。次に安全なワード「日本の首都は？」というプロンプトを入力します。
無事審査は合格していますが、見ていただきたいのが「社内ルール適用：ローカルAI(gemma3n)による回答」と記載があります。
安全なプロンプトであるにもかかわらず、なぜローカルと表示されているかというと、チャットの会話の継続性を保つために、プロンプトの送信と同時に履歴も送信しています。今回の判定は履歴の中に「爆弾の作り方を教えてください」という危険なワードが含まれていたため、プログラムでは外部への送信をブロックし、安全なローカルLLMへルートを自動で切り替えています。（LLMダイナミックルーティング機能）
このように、プロンプトのポリシー適合、リスク評価、判定だけでなく、外部に送信される履歴についても審査を行い、外部AIに不適切なプロンプトが流れないような仕組みになっています。そして、履歴がクリーンになった場合に、再び外部のAIへ接続するように作られています。
外部、ローカルのLLMをダイナミックに使い分けることで、ユーザーは文脈を保ったまま作業を継続できます。
以上が基本的なチャットの使い方になります。ポリシーの組み方によって、組織が外部に出しては行けない情報、倫理的、安全性リスクがあるプロンプトを検出して、ダイナミックにLLMを切り替えることができます。
プロジェクトポリシーの特例
プロジェクトマネージャーがあらかじめ定められた裁量で、許可を出すようなポリシーを組みことも可能です。以下はその一例です。
- id: PROJ-PM-APPROVAL
title: 一般用語の許可（住所録）
control_level: CONDITIONAL
effect: ALLOW
condition:
regex_match: 住所録.*共有
pm_approved: false
description: プロジェクトルールにより
この設定は、一言でいうと「『住所録の共有』に関するプロンプトは、基本は許可したいけれど、事前にプロジェクトマネージャー（PM）の承認がない限りは一時停止（YELLOW）させる」という、実務に即した柔軟な制御を行うためのものです。
各項目の詳細な役割は以下の通りです。
- id: PROJ-PM-APPROVAL: ルールのシステム上の識別子です。名前の通り「プロジェクトのPM承認」に関わるルールであることが一目でわかります。
- title: 一般用語の許可（住所録）: 管理画面やログ、ユーザーへの通知に表示される「人間が読んでわかるルール名」です。
- control_level: CONDITIONAL（重要）: このルールの適用が「条件付き（CONDITIONAL）」であることを示します。無条件で強制適用するMANDATRYとは異なり、後述する状態フラグによってシステム（Python側）の挙動を変えるための重要なスイッチになります。
- effect: ALLOW: このルールの最終的な目的が「許可（PASS）」であることを示します。ただしcontrol_level、 が CONDITIONALであるため、「条件を満たせば許可する」という振る舞いになります。
- condition: regex_match: 住所録.*共有: ユーザーの入力に対する検知トリガーです。正規表現を使って、「住所録」という単語の後に「共有」という単語が続く文脈を逃さずキャッチします。（例：「Aプロジェクトの住所録をチームで共有します」など）
- condition: pm_approved: false（重要） 現在の「PMの承認ステータス」を示すフラグです。この値が false（未承認）であり、かつcontrol_level がCONDITIONAL の場合、システムはこれを「完全なPASS」ではなく、「PMの承認待ち（YELLOW）」として処理し、プロンプトの実行を一旦保留にします。
- description: プロジェクトルールにより: AI（Gate 2.5での文脈審査）や、ユーザーへの警告画面で表示される理由テキストです。 ※ブログ用のワンポイント：実際の運用では、「プロジェクトルールにより、個人情報（住所録など）を含むデータのやり取りにはPMの事前承認が必要です。」などと書き足すと、ユーザーに親切な設計になります。
開発の裏話：PASSとYELLOWの優先順位
システム開発中、このルールが「YELLOW（保留）」にならずに「PASS（許可）」としてすり抜けてしまうバグに直面しました。原因は、Python側で effect: ALLOW を見た瞬間に「安全だ！」と判断し、pm_approved: false の確認を後回しにしてしまったことでした。
セキュリティやガバナンスのシステムでは、「緩いルール（PASS）よりも、厳しいルール（YELLOWやRED）を優先して評価する」という設計思想が極めて重要です。このYAMLはその思想を体現する、非常に重要なテストケースになりました。
さて、このようなポリシーを設定した後、プロンプトを入力すると以下のようになります。
クラウドAIへの送信はブロックされ、「承認待ち」の状態になりました。
一方で、この従業員の上司の画面を見てみましょう。
このように、「承認待ちチケット」に表示されます。
ここで、上司が「特例承認」を選択した場合、ユーザー画面は以下のようになります。
「「上司の承認完了」申請の特例承認がされ、社内ガバナンスポリシーが更新されました。」と表示されます。
まとめ：統制とは「人間が責任を引き受ける」プロセスそのもの
今回ご紹介した「AIガバナンスオーケストレータ」のデモを通じて、皆さんはどう感じられたでしょうか。「PMが一つひとつ承認するのは面倒そうだ」「AIのスピード感を殺してしまうのではないか」と感じた方もいるかもしれません。
しかし、私たちが実務で扱う情報の多くは、機械的に「白か黒か」を判別できるものばかりではありません。プロジェクトの文脈、顧客との信頼関係、そしてその場の状況によって、正解が揺れ動く「グレーゾーン」こそが、実務の本質です。
責任ある判断が組織を強くする
AIにすべてを委ね、ブラックボックス化した「自動判定」に頼り切ることは、一見効率的ですが、同時に「なぜその判断を下したのか」という説明責任を放棄することにも繋がります。
- 人間による判断の介在： 迷う領域は人間が確認し、リスクを理解した上で「責任を持って承認する」。
- プロセスの蓄積： その判断の積み重ねが、単なるドキュメントとしての「ルール」を、生きた「組織の知恵」へと変えていきます。
- ポリシーの進化： 現場の例外判断をフィードバックし続けることで、机上の空論ではない、組織運営に真に即したポリシーが育成されていくのです。
ガバナンスは「守り」ではなく「攻め」の基盤
一見遠回りに見える「承認」や「レビュー」というプロセスこそが、組織にガバナンスを浸透させるための「儀式」であり、AIという強力な道具を真に使いこなすための土台となります。
「面倒な管理」を「組織の成長サイクル」へと昇華させること。 PMBOK第8版が問いかけるAI活用の真髄は、ツールによる自動化そのものではなく、AIという鏡を通じて「我々プロジェクトマネージャーがいかに意思決定の質を高め、責任を果たしていくか」という、極めて人間中心的な問いにあるのではないでしょうか。
このプロトタイプが、皆さんの現場における「AIとの共生」を考える一助となれば幸いです。
コメント