PMBOK第8版はAIをどう位置づけているのか　三層AIポリシーで読み解くAI活用の前提

はじめに　なぜAI活用は「便利さ」から考えてはいけないのか

近年、プロジェクトマネジメントの現場でもAIやLLM（大規模言語モデル）を活用する動きが急速に広がっています。

議事録作成、レポート要約、文書分析、予定調整。
いずれも一見すると、AIによる「自動化」によって効率化できそうな業務です。
実際、市場には「AIアシスト」「AI自動化」を謳うツールが数多く登場しています。

しかし、ここで一つ立ち止まって考える必要があります。
それらのAIは、どの原則に基づいて振る舞っているのか。 そして、その判断や結果に対する説明責任は誰が負うのか。

PMBOK®ガイド第8版では、AIを単なるツールとしてではなく、学習し、適応する技術として定義しています（Appendix X3）。

Appendix X3 Artificial Intelligence X3.1 Artificial Intelligence in the Project Context Artificial intelligence (AI) describes a set of technologies that simulate human behavior on computers. This technology allows machines to perform tasks they were not directly programmed to do, learn from experiences, and adapt to new situations. AI has a broad range of applications, including pattern recognition, fraud detection, robotics, and the discovery of new drugs to combat diseases. The quick changes in the field of AI, and its rising potential, require great adaptability for staying current with new tools and in learning new ways of working.

（訳）X3.1 人工知能（AI）とは、コンピュータ上で人間の行動をシミュレートする一連の技術を指します。この技術により、機械は直接プログラムされていないタスクを実行し、経験から学習し、新しい状況に適応することができます。AIは、パターン認識、不正行為の検出、ロボット工学、疾病と闘うための新薬の発見など、幅広い用途に応用されています。AI分野は急速に変化し、その潜在能力は高まっているため、新しいツールを常に把握し、新しい働き方を習得するための高い適応性が求められます。

PMBOK(R)　第8版 Appendix X3より引用

同時に、その予測不能性と変化の速さを前提として、

• 倫理的ガイドライン
• AIポリシー（AI policies）

を組織として定義し、AIの使い方について共通理解を形成することの重要性を示しています。

ここで重要なのは、PMBOKが「AIに判断を委ねよ」と言っているわけではない、という点です。

むしろ逆です。

AIが学習し、適応する存在であるからこそ、 人間側が原則・判断境界・責任の所在を事前に定義しなければならない。

これが、PMBOK第8版に一貫して流れている思想です。

一方、実務の現場ではどうでしょうか。

AI導入の議論は、セキュリティやプライバシーの話題にとどまることが多く、「社内ポリシーに準拠可能」といった抽象的な表現で済まされがちです。

また、「AIは学習させていけば賢くなる」という発想から、個別のチューニングや経験学習に期待を寄せるケースも少なくありません。

しかし、プロジェクトマネジメントの観点では、それでは不十分です。

判断基準が曖昧なまま自動化を進めれば、

• 誰が判断したのか分からない
• なぜその結果になったのか説明できない
• 問題が起きても是正ポイントが見えない

という状態に陥ります。

本記事では、PMBOK第8版が示しているAIポリシーという考え方を出発点に、

• 自動化・支援・拡張の違いを整理し
• AIに「させてよいこと」「させてはいけないこと」を明確にし
• プロジェクト実務において
  AIポリシーをどのように具体化すべきか

を考察します。

その過程で、PMBOKのAIポリシーを、プロジェクト関係者全員が理解しやすい形に落とし込んだものを、便宜的に 「AI憲章」 と呼びます。

これは新しい概念ではありません。PMBOKが求めているAIポリシーを、実際に運用できる形に翻訳するための表現です。

AI活用は、技術導入の話ではありません。
判断・責任・ガバナンスをどう設計するかという、 プロジェクトマネジメントそのものの問題です。

本記事が、AIを安心して、かつ原則に則って活用するための一つの整理の軸となれば幸いです。

記事の末尾には、「AIポリシー」の例を掲載しておりますのでぜひご覧ください。

PMBOK第8版におけるAI活用の整理

PMBOK第8版におけるAI活用は、「新しいツールの導入」ではなく、原則ベースのマネジメントを前提とした価値提供の手段として位置づけられています。

そのため、AI活用は以下の観点から整理されます。

• 自動化・支援・拡張という役割の違い
• 説明責任・倫理・ガバナンスを含むAIポリシー
• プロジェクト全体の価値提供システム（Value Delivery System）との整合

PMBOK第8版におけるAIの基本的な位置づけ

PMBOK第8版では、AIは独立した知識エリアやツール群としてではなく、「プロジェクトの成果と価値を高めるために活用される技術の一つ」として扱われます。

Appendix X3 では、AIを次のように定義しています。

• 人間の行動を模倣・補完する技術群
• 明示的にプログラムされていないタスクを実行できる
• 学習し、適応する能力を持つ

同時に、急速に進化する技術であるがゆえに、適応力とガバナンスが不可欠である点が強調されています。

自動化・支援・拡張という3つの役割整理

PMBOK第8版では明示的にこの3語を定義しているわけではありませんが、
AI活用の整理として非常にPMBOK的な考え方です。

重要なのは、AIの賢さの違いではないという点です。

観点	自動化（Automation）	支援（Assistance）	拡張（Augmentation）
判断	事前定義	人間	人間
実行	システム	人間	人間
AIの役割	決められた処理を実行	分析・補助	思考の幅を広げる
説明責任	人間	人間	人間

PMBOK第8版の前提では、最終的な判断責任（Accountability）は常に人間にあるという点が一貫しています。

AI活用における最大の論点は「品質と信頼性」

LLMには常に以下のリスクが存在します。

• ハルシネーション（事実に基づかない生成）
• バイアスや不完全な前提
• 文脈誤解による不適切な出力

PMBOK第8版の原則で言えば、これは次の原則と直結します。

• Quality（品質）
• Stewardship（責任ある管理）
• Transparency（透明性）

そのため、

• AIの出力を成果物として扱うのか
• レビュー・検証をどこに組み込むのか
• どのレベルまで自動化を許容するのか

を事前に定義することが不可欠となります。

倫理・説明責任・AIポリシーの必要性

PMBOK第8版では、次のように明記されています。

Ethical guidelines in the performing organization, as well as AI policies, could represent a solid basis for building an organizational culture and establishing a common understanding of how AI should be used within the organization.

（訳）実行組織の倫理ガイドラインと AI ポリシーは、組織文化を構築し、組織内で AI をどのように使用すべきかについての共通理解を確立するための強固な基盤となります。

PMBOK(R)第８版 Appendix X3より引用

ここで言う AIポリシー とは、

• AIをどの目的で使うのか
• どこまで任せ、どこから人が判断するのか
• 誰が責任を負うのか
• 何をしてはいけないのか

を組織・プロジェクトとして合意したルールです。

これは単なるセキュリティポリシーや利用規約ではなく、プロジェクト憲章やチーム憲章と同じレイヤーのマネジメント文書と捉えるのがPMBOK第8版の思想に近い整理です。

ガバナンスと持続可能性の視点

AI活用は「便利だから使う」では終わりません。

PMBOK第8版が重視するのは、

• 組織として許容可能なリスクか
• ステークホルダーへの説明が可能か
• 長期的に持続可能な運用か

という視点です。

特にLLMは、

• データ取り扱い
• 計算資源・コスト
• 組織文化への影響

といった非機能要件がプロジェクトの成否に直結します。

本章のまとめ

PMBOK第8版におけるAI活用は、

• 「AIに任せるかどうか」ではなく
• 「人間がどのような原則と責任のもとでAIを使うか」

を設計することに本質があります。

次章では、
このAIポリシーをどのように具体化し、LLM運用に落とし込むのか
を、実際の導入・運用を想定しながら整理していきます。

実装議論　簡易事例：LLMを使った予定整理を検証する

本章では、PMBOK第8版が示すAI活用の考え方を、実際にLLMを業務に組み込む場合、どこまで具体的に定義する必要があるのかを、簡易な実装事例を通して確認します。

題材として扱うのは「予定整理」という一見単純な業務です。単純に見えるが、相対表現・曖昧性・責任の所在が混ざるため、AIガバナンスの縮図になると考えました。

しかし、この単純な業務でさえ、LLMに任せるためには明確なポリシーと指示の設計が不可欠であることが分かります。

検証対象としたユースケース

検証したユースケースは次のとおりです。

• 人が自然言語で入力した予定依頼文を受け取る
• LLMが内容を整理し、構造化された情報として出力する
• 不明点は「人が確認すべき事項」として明示する

入力例は次のようなものです。

来週水曜日の午後に1時間の定例MTGを入れたい。

この時点で重要なのは、LLMに予定を「確定」させない という前提です。

LLMに定義した「実装ポリシー」

まず、LLMに対して役割と制約を明確に定義しました。
これは組織AIポリシーではなく、この実装に限定したAI実装ポリシーです。

定義したポリシー（要点）

• あなたは実行権限を持たない秘書AIである
• 役割は「予定や依頼内容を整理・解釈・提案すること」に限定する
• 外部システム（カレンダー、通知、家電等）を直接操作してはならない
• 判断が必要な場合は、必ず人間に確認を求める
• 出力は、機械処理しやすいJSON形式で行う

この時点で、
「AIに何をさせるか」よりも「何をさせないか」を重視しています。

実際に与えた指示（プロンプトの考え方）

次に、個別タスクとしての指示を与えました。
ポイントは、曖昧な解釈をAIに任せないことです。

与えた指示の要点

• 出力はJSONのみとする
• 日付・時刻が確定できない場合は null を入れる
• 相対表現（来週、午後など）は解釈せず、不明として扱う
• 不明点は uncertain_points に「理由を文章で」記載する

つまり、

• AIが「それっぽく補完する」ことを禁止
• 人が次に判断すべき材料を揃えることに集中

させています。

LLMから得られたアウトプット例

上記ポリシーと指示のもとで、入力文を処理した結果、LLMは次のような出力を返しました。

ここで注目すべき点は、
AIが一切の判断を下していないことです。

• 日付を勝手に決めていない
• 時刻を推測していない
• 代わりに「なぜ決められないか」を明示している

これは、人間の意思決定を奪うのではなく、支援している状態です。さらにLLMのポリシーの理解度を確認するために以下の質問をしました。

曖昧な部分は質問として人間に確認すべきという認識をLLMはしています。

この事例が示す重要なポイント

この簡易事例から分かるのは、次の点です。

• LLMは「賢いから安全に使える」わけではない
• 役割・権限・責任を定義しなければ、意図しない判断をする
• AI活用の成否は、実装ポリシーの設計でほぼ決まる

これはPMBOK第8版が強調する責任あるAIの使用、説明責任、ガバナンスを、実装レベルで具体化した例だと言えます。

補足：今回の検証環境について

本記事で紹介している検証は、クラウド型AIサービスではなく、ローカル環境で動作するLLMを用いて行いました。
これは、PMBOK第8版で重視される「ガバナンス」「情報管理」「説明責任」を実装レベルで検証するためです。

検証環境の概要

• LLM実行環境
  • ローカルPC上でLLMを実行（Ollamaを使用）
  • モデル：Llama 3.1（8B）
  • 推論処理はすべてローカルで完結
• ユーザーインターフェース
  • Web UI（Open WebUI）を使用
  • ブラウザ経由で自然言語入力・出力を確認
  • 音声入力や外部連携は使用せず、テキストベースで検証
• ネットワーク構成
  • LLMはローカルネットワーク内で稼働
  • 他PCからのアクセスも可能（IP reachable な範囲）
  • インターネット経由で外部AIサービスへ通信しない構成
• 外部システムとの関係
  • Googleカレンダーなどの外部システムは直接操作しない
  • LLMの役割は「整理・構造化・不明点の明示」に限定
  • 実際の登録・反映は、人または別システムが行う前提

この環境を選んだ理由

この構成にした理由は次のとおりです。

• AIの判断や振る舞いを完全に制御・観察できる
• データが外部に送信されず、情報管理上のリスクを排除できる
• 「AIに何を任せ、何を任せないか」を明示的に設計できる
• PMBOK第8版が求める責任あるAI利用・説明責任・ガバナンスを検証しやすい

実務への示唆

この検証環境は、そのまま本番利用するためのものではありません。
しかし、

• AI活用の初期段階で
• 原則・ポリシー・責任分界を詰める
• 影響範囲を限定して検証する

という意味では、プロジェクトマネジメント的に非常に相性の良い構成です。

この後の記事では、このような環境で得られた知見をもとに、AIポリシーをどの粒度で定義・運用すべきかを掘り下げていきます。

AIポリシーは「三層構造」で設計する

ここまで見てきたように、AI活用において最も重要なのはAIをどう使うかではなく、どう“位置づけるか”です。

PMBOK第8版では「AIポリシー」や「倫理的ガイドライン」という言葉が使われていますが、
その具体的な粒度や構造までは明示されていません。

実務に落とし込むためには、AIポリシーを一枚の文書として捉えるのではなく、役割ごとに分解して設計する必要があります。

本章では、AIポリシーを次の三層構造として整理します。

これはPMBOKに定義されているわけではなく、筆者の検討結果としてのテイラーリングの１種としての提案です。

• 組織AIポリシー
• プロジェクトAIポリシー
• 実装AIポリシー（LLM実装ポリシー）

なぜ三層に分ける必要があるのか

AIポリシーを一つの文書で済ませようとすると、必ず次のような問題が起きます。

• 抽象的すぎて現場では使えない
• 技術寄りになりすぎて経営層が理解できない
• 特定のツール前提になり、再利用できない

これは、関心のレイヤーが異なる人たちに同じ文書を読ませようとすることが原因です。

PMBOK第8版が強調しているのは、「共通理解を作ること」であって、「同一文書を配ること」ではありません。

そのため、共通理解の階層構造を明示的に分ける必要があります。

組織AIポリシー：価値観と原則のレイヤー

最上位に位置づけるのが、組織AIポリシーです。

これは、

• 経営層
• 管理職
• プロジェクト横断の関係者

が共有すべきレイヤーです。

組織AIポリシーで定義すべき内容

• AIを導入する目的（効率化か、品質向上か、価値創出か）
• AIに任せない判断領域（最終意思決定、評価、人事など）
• 倫理・コンプライアンスの基本方針
• 説明責任は常に人間が負うという原則

ここではツール名や実装方法は一切書きません。

PMBOK第8版が言う「AI policies」「ethical guidelines」は、
本来このレイヤーを指しています。

プロジェクトAIポリシー：責任分界と適用範囲のレイヤー

次に位置づけるのが、プロジェクトAIポリシーです。

これは、

• 特定プロジェクトにおいて
• AIをどの業務に、どの範囲で使うか

を定義するレイヤーです。

プロジェクトAIポリシーで定義すべき内容

• 当該プロジェクトでAIを使う業務領域
• 自動化・支援・拡張のどれに該当するか
• 人とAIの役割分担
• 承認フローとレビュー責任

ここで初めて、「このプロジェクトでは、AIはここまで」という合意が形成されます。

実装AIポリシー：LLMの振る舞いを定義するレイヤー

最下層に位置づけるのが、実装AIポリシーです。

本記事で扱ってきた「LLMへの役割定義」は、まさにこのレイヤーに該当します。

実装AIポリシーで定義すべき内容

• LLMの役割（例：秘書AI、分析補助）
• 実行権限の有無
• 外部システムとの接続可否
• 判断が必要な場合の振る舞い
• 出力形式や制約条件

ここではじめて、プロンプトや設定、JSON出力といった具体的な実装ルールが登場します。

三層は「上下関係」ではなく「整合関係」

重要なのは、この三層が単なる上下関係ではないという点です。

• 上位ポリシーは下位を拘束する
• 下位ポリシーは上位を具体化する

この双方向の関係があって初めて、AI活用は安定します。

もし実装ポリシーが上位の原則と矛盾すれば、そのAIは「使ってはいけないAI」になります。

PMBOK第8版との対応関係

この三層構造は、PMBOK第8版の考え方と自然に対応します。

• 原則ベース（Principle-based）
• 説明責任（Accountability）
• ガバナンス（Governance）
• テイラリング（Tailoring）
• リスク・パフォーマンスドメイン（Risk Performance Domain)
• ステークホルダー・パフォーマンスドメイン（Steakholder Performance domain)
• 知識（Knowleadge）

PMBOKは「AIポリシーを作れ」とは言っていますが、
「一枚にまとめろ」とは言っていません。

むしろ、状況に応じて分解・調整することを前提としています。

AIポリシーの運用と変更管理　― AIは「一度決めたら終わり」ではない

AIポリシーは、作って終わりの文書ではありません。
むしろ本質は、どう運用し、どう変更を管理するかにあります。

PMBOK第8版が繰り返し強調しているのは、原則やガイドラインを「掲げること」ではなく、
それを前提として意思決定が行われ続ける状態を作ることです。

AI活用においても、この考え方は変わりません。

なぜAIポリシーは運用が難しいのか

AIポリシーの運用が形骸化しやすい理由は明確です。

• AI技術の進化が速い
• 利用範囲が徐々に拡大する
• 現場ごとに「例外」を作りたくなる

特にLLMは、「できることが増えた」「精度が上がった」という理由で、いつの間にか役割が拡張されがちです。

このとき、ポリシーが曖昧だと、

• いつの間にか判断をAIに任せている
• 当初想定していなかった業務に使われている
• 誰も全体像を把握していない

という状態に陥ります。

運用の基本原則：人が責任を持ち続ける

AIポリシー運用の大前提は、非常にシンプルです。

AIは運用される対象であり、
運用を判断する主体は常に人間である

これはPMBOK第8版のAccountability（説明責任） の原則と完全に一致します。

そのため、AIポリシーの運用では、必ず次の問いに答えられる状態を保つ必要があります。

• このAIの利用を承認したのは誰か
• どのポリシーに基づいて使われているのか
• 問題が起きた場合、誰が是正を判断するのか

三層ポリシーごとの運用責任

第4章で整理した三層構造は、そのまま運用責任の分担にも対応します。

組織AIポリシー

• 承認主体：経営層・ガバナンス責任者
• 運用の観点：倫理・コンプライアンス・対外説明
• 変更頻度：低（原則は安定させる）

プロジェクトAIポリシー

• 承認主体：プロジェクトスポンサー／PM
• 運用の観点：適用範囲・リスク・品質
• 変更頻度：中（フェーズや状況に応じて）

実装AIポリシー（LLM実装ポリシー）

• 承認主体：PM／テックリード
• 運用の観点：振る舞い・制約・出力品質
• 変更頻度：高（試行錯誤を前提）

この整理により、「誰が決めてよいか」「誰が決めてはいけないか」が明確になります。

変更管理が必要になる典型的なタイミング

AIポリシーの変更は、気分や思いつきで行うべきではありません。PMBOK的には、変更トリガーを明示しておくことが重要です。

典型的な変更トリガーは次のとおりです。

• AIの利用範囲を拡張したいとき
• 自動化レベルを引き上げたいとき
• 新しいデータや外部システムと接続するとき
• 出力品質やリスクに問題が発生したとき

特に注意すべきなのは、「便利そうだから」という理由だけでの変更です。

それは技術判断ではなく、ガバナンス上の判断だからです。

実装ポリシー変更時の最低限のチェック項目

LLMの実装ポリシーを変更する際には、最低限、次の点を確認すべきです。

• 判断をAIに委ねる範囲が広がっていないか
• 人間の確認ステップが削除されていないか
• 出力が検証可能な形で残るか
• 上位ポリシー（組織・プロジェクト）と矛盾していないか

これらはすべて、「AIが賢くなったか」ではなく、「責任構造が変わっていないか」
を確認する問いです。

AIポリシー運用はPMの仕事である

ここまで見てくると、AIポリシーの運用と変更管理は、

• エンジニアだけの仕事でも
• AI担当者だけの仕事でもなく

プロジェクトマネジメントそのものであることが分かります。

• 目的との整合
• リスクの把握
• 責任分界の明確化
• ステークホルダーへの説明

これはPMBOK第8版が定義しているPMの役割と完全に重なります。

AIポリシーにGitを活用できるかの考察　説明責任をどう担保するか？

Gitとは何か ― なぜAIポリシー管理に使うのか

ここで一度、「Gitとは何か」を簡単に整理しておきます。

Gitは、もともとプログラムの変更履歴を管理するための仕組みです。
誰が、いつ、どこを、なぜ変更したのかを記録し、複数人で同じ成果物を安全に扱うために使われてきました。

ただし、Gitの本質は「プログラム管理ツール」であることではありません。

Gitが本質的に提供しているのは、次の能力です。

• 変更の履歴を残す
• 変更理由をレビュー・合意できる
• どの版を正式に採用しているかを明確にできる

この性質は、AIの振る舞いを定義・統制するポリシー管理と非常に相性が良いものです。

Gitで管理されるAIポリシーとは何か

実装AIポリシーをGitで管理すると言った場合、それは「経営AIポリシー・プロジェクトポリシーAIをGitに置く」という意味ではありません。

Gitで管理するのは、

• AIが扱ってよいデータの範囲
• 禁止されている利用方法
• 例外時の扱い
• ログや監査の要件

といった、AIの実際の振る舞いを決める定義です。

言い換えると、

• 経営・プロジェクト向けAIポリシーは
  「なぜそうするのか」「どこにリスクがあるのか」を定める
• Git上のAIポリシーは「AIがどう動くか」を定義する

この役割分担が前提になります。

問題は「両者の関係が見えなくなる」こと

ここで、実務上よく起きる問題があります。

• 経営層・実務者はGitを見ない
• 技術者は経営文書を逐語的には読まない

その結果、

• 「この経営判断は、AIの動きに本当に反映されているのか？」
• 「このGit上の定義は、どの判断に基づいているのか？」

という問いに、誰も即答できなくなります。

このズレを放置すると、ポリシーは存在するが、AIの振る舞いと結びついていないという状態になります。

解決策としての「対応表」

このズレを埋めるために有効なのが、対応表（マッピング表）という考え方です。

対応表は、経営・プロジェクト向けAIポリシーと、Git上の実装AIポリシー定義の対応関係を一覧化したものです。

重要なのは、対応表は仕様書ではなく、説明責任のための台帳であるという点です。

対応表の例

上位ポリシーID	上位ポリシー（要約）	意図・リスク	Git上の定義箇所	Gitでの定義内容	制御レベル
GOV-01	個人情報を外部AIに送信しない	法令違反・信用失墜	policy/data_classification.yaml	PII入力は外部LLMへ送信不可	強制
GOV-05	AIは最終意思決定を行わない	責任所在不明	prompts/system.md	最終判断は人間が行うと明示	ガイド
PROJ-12	AI利用は後追い検証可能にする	事故時の追跡不能	logging/config.yaml	全リクエストと判断結果を保存	強制

この表があることで、

• 経営層は「判断がどう実装されているか」を把握でき
• 技術側は「この定義の根拠は何か」を説明できる

状態が生まれます。

このマッピングも自動化を。。。と考えるプロマネもいるかも知れませんが、ここはプロマネが１つ１つ確認をして行く項目と思いますので、敢えて対応表というアナログな手法で確認していくことが、後々の説明責任を果たすことにつながると思います。

具体例：GOV-01 は Git 上でどう定義されるのか

では、対応表に出てきた GOV-01 を具体的に見てみましょう。

上位ポリシー（経営・プロジェクト層）

• GOV-01
  個人情報（PII）を外部のAIサービスに送信してはならない
• 意図：法令違反・信用失墜の回避
• 制御レベル：強制

この判断は、Git上では「定義」「判定」「制御」に分解して表現されます。

① ポリシー定義（人が読むための翻訳）

# policy/data_classification.yaml
policy_id: GOV-01
description: >
  個人情報（PII）を含むデータは、
  外部のLLM（クラウドAI）に送信してはならない。

data_classes:
  PII:
    examples:
      - 氏名
      - メールアドレス
      - 電話番号
      - 住所
      - マイナンバー
    allowed_destinations:
      - internal_llm
    forbidden_destinations:
      - external_llm

ここは、経営層や監査、プロジェクトマネージャでも読める層です。
「GOV-01 という判断が、Gitではこう翻訳されている」と説明するための記述になります。

② 判定ルール（機械が判断するための定義）

# policy/rego/data_guardrails.rego
package ai.policy

deny_external_llm[msg] {
  input.data_class == "PII"
  input.destination == "external_llm"
  msg := "GOV-01 violation: PII must not be sent to external LLM"
}

この層では曖昧さは許されません。
「PIIであり、かつ外部LLMに送ろうとした場合は拒否する」という判断を、機械が確実に行います。

エラーメッセージに GOV-01 を明示している点も重要です。これにより、どの経営ポリシーに基づく制御なのかを即座に説明できます。

③ 強制制御（実際に止める仕組み）

# enforcement/api_gateway.yaml
pre_checks:
  - name: pii_detection
    on_detect:
      action: reject
      reason: GOV-01
      message: >
        個人情報を含む入力は
        外部AIへ送信できません。

ここで初めて、AIの動きが実際に止まります。

利用者が誰であっても、プロンプトがどう書かれていても、GOV-01は必ず守られます。

Gitは「AIの動き」、対応表は「理由」

この一連の例から、次のことが分かります。

• 経営ポリシーは、そのままGitに書かれているわけではない
• 「定義」「判定」「制御」に分解されて初めて、AIの振る舞いになる
• Gitは単なる文書置き場ではなく、AIの行動を縛る仕組みである

そして、対応表があることで、

• Gitの定義が「なぜ存在するのか」
• 経営判断が「どこでどう実装されているのか」

を、コードではなく構造として説明できるようになります。

本章のまとめ

• Gitは、AIの振る舞いを定義する場所
• 経営・プロジェクトポリシーは、その理由を定める場所
• 対応表は、その両者を結びつける翻訳レイヤー

AIポリシーをGitで管理する本当の価値は、技術的に制御できることと同時に、説明できる構造を持てることにあります。

まとめ　AI活用を「技術」ではなく「マネジメント」として成立させるために

本記事では、PMBOK第8版におけるAI活用の考え方を起点に、
AIをプロジェクトマネジメントの文脈で、どのように扱うべきかを整理してきました。

AI活用の成否を分けるのは、
モデルの性能でも、プロンプトの巧拙でもありません。
事前に定義された原則とポリシーがあるかどうかです。

AI活用は「賢さ」の話ではない

PMBOK第8版が示す自動化・支援・拡張という整理は、AIの高度さの違いではなく、

• 誰が判断するのか
• 誰が実行するのか
• 誰が責任を負うのか

という、マネジメント上の役割分担の違いを明確にするためのものです。

この区別を曖昧にしたままAIを導入すると、判断・責任・説明が混線し、プロジェクトは必ずどこかで破綻します。

PMBOK第8版は「AIポリシー」を前提としている

PMBOK第8版では、AI活用にあたり AI policy や ethical guidelines の重要性が明確に示されています。

これは単なるセキュリティ規程や利用ルールではなく、

• 組織としてAIをどう位置づけるのか
• どこまでをAIに任せ、どこからを人が担うのか
• 問題が起きたとき、誰が説明責任を負うのか

といった、共通理解を形成するための前提条件です。

三層に分けることで、AI活用は初めて運用できる

本記事では、AIポリシーを次の三層で整理しました。

1. 組織AIポリシー（AI憲章）
   ─ 原則・倫理・責任を定義する層
2. プロジェクトAIポリシー
   ─ そのプロジェクトでのAI活用範囲を定める層
3. LLM実装ポリシー
   ─ 実際にAIに与える役割・制約・出力ルールを定義する層

この分離によって、

• 経営の視点
• PMの判断
• 実装上の制約

が混ざることなく、一貫したガバナンスのもとでAIを使うことが可能になります。

LLM実装事例が示した重要な示唆

今回取り上げた「LLMを使った予定整理」の検証は、高度なAI活用ではありません。

しかし、

• 判断をAIに任せない
• 曖昧さは必ず人に返す
• 実行は人が行う

という設計を最初に定義したことで、安全で説明可能なAI活用が成立しました。

これは、PMBOK第8版が意図する原則ベースのAI活用が、実装レベルまで落とし込めることを示す、一つの具体例だと考えています。

AI時代に求められるPMの役割

AIが普及するほど、
プロジェクトマネージャには次の力がより強く求められます。

• 判断と責任を分離しない力
• 原則を言語化し、共有する力
• 技術を「運用可能な仕組み」に変える力

AIは、プロジェクトを楽にしてくれます。しかし、考えなくてよくしてくれるわけではありません。

むしろ、考えるべきことを前倒しで考えることが、AI時代のマネジメントの本質なのだと思います。

次の一歩として

本記事と付録のテンプレートが、

• AI導入を検討している組織
• AI活用を設計するPM
• LLMを実装する技術者

が、同じ前提で議論を始めるための共通言語となれば幸いです。

付録について　AIポリシーを「使える形」に落とすために

本記事では、PMBOK第8版が示すAI活用における倫理・責任・ガバナンスの重要性を踏まえ、

AIは「賢く使う」ものではなく、
原則とポリシーに基づいて運用されるべき存在である

という前提で議論を進めてきました。

しかし、原則や方針を「理解する」ことと、それを実際のAI実装・導入に落とし込むことの間には、大きな隔たりがあります。

なぜ「三層」に分ける必要があるのか

AIポリシーを一枚の文書で済ませてしまうと、

• 経営レベルの原則と
• プロジェクトごとの判断
• LLM実装レベルの制約

が混在し、責任の所在と判断基準が曖昧になるという問題が生じます。

そこで本記事では、AIポリシーを次の三層構造で整理しました。

1. 組織AIポリシー（AI憲章）（※以降、本記事では便宜上AI憲章と呼ぶ）
   ─ 組織としての原則・倫理・説明責任を定義する層
2. プロジェクトAIポリシー
   ─ 特定プロジェクトにおけるAI活用範囲と判断主体を定める層
3. LLM実装ポリシー
   ─ 実際にAIに与える役割・制約・出力ルールを定義する層

この分離こそが、
PMBOK第8版が意図する「原則ベースのAI活用」を
現場で破綻させないための実装方法だと考えています。

付録の位置づけ

以下の付録では、
今回の「LLMを使った予定整理の検証事例」をもとに、

• 組織レベル
• プロジェクトレベル
• 実装レベル

それぞれで使える AIポリシーのテンプレート例を提示します。

これらは「完成形」ではなく、

• 読者自身の組織
• プロジェクト
• 利用するAIの特性

に応じて調整・発展させるための叩き台です。

期待する使い方

この付録は、

• AI導入を検討している経営層
• AI活用を設計するプロジェクトマネージャ
• LLMを実装するエンジニア

が、同じ前提・同じ言葉で議論するための共通資料としての利用を想定しています。

AIの性能や進化に振り回されるのではなく、
原則とポリシーを軸にAIを使いこなすための一助になれば幸いです。

付録A　組織AIポリシー（AI憲章）テンプレート

※第1層：組織レベル

1. 目的

本ポリシーは、当組織におけるAIおよびLLMの利用について、
倫理・責任・説明可能性を確保しつつ、価値創出に活用するための原則を定めるものである。

AIは判断主体ではなく、人間の判断を支援・拡張する技術として位置づける。

2. 基本原則

2.1 説明責任（Accountability）

• AIの出力・処理結果に対する最終責任は常に人間が負う
• 「AIが判断した」という説明は認めない

2.2 判断主体の保持

• 意思決定・評価・承認は人間が行う
• AIは判断材料の整理・提示に限定される

2.3 透明性

• AIの利用目的・役割・制約は関係者に共有される
• AIの出力は検証可能な形で残される

2.4 倫理・法令遵守

• 人権、プライバシー、公平性を侵害しない
• 組織の価値観・行動規範に反する利用を禁止する

3. AI利用の考え方

• AI活用は「自動化・支援・拡張」のいずれかとして整理する
• 自動化を行う場合は、判断基準と責任範囲を事前に定義する

4. ガバナンスと変更管理

• AI利用方針の承認は経営層が行う
• 原則は安定させ、変更は慎重に行う

付録B　プロジェクトAIポリシーテンプレート

※第2層：プロジェクトレベル
（今回の「予定整理プロジェクト」を例に）

1. プロジェクトにおけるAI利用目的

本プロジェクトでは、
予定整理業務における情報整理・不明点の可視化を目的としてLLMを利用する。

判断や実行の自動化は行わない。

2. AI活用区分

• 本プロジェクトにおけるAI活用は 「支援（Assistance）」 に該当する
• AIは予定を確定せず、人間の判断を支援する

3. 人とAIの役割分担

項目	人間	AI
依頼内容の入力	○
内容の整理		○
曖昧点の特定		○
判断・確定	○	×
実行（登録等）	○	×

4. 責任と承認

• AI利用範囲の承認：プロジェクトマネージャ
• 出力内容の最終確認・判断：担当者
• 問題発生時の是正判断：PM

5. 上位ポリシーとの整合

本ポリシーは、組織AIポリシー（AI憲章）に準拠する。

付録C　AI実装ポリシーテンプレート

※第3層：実装レベル（今回の実例）

1. LLMの役割定義

• LLMは「秘書AI」として振る舞う
• 役割は予定に関する自然言語入力を整理・構造化することに限定する

2. 権限・制約

2.1 許可される行為

• 入力文から予定情報を抽出・整理する
• 不明点・曖昧点を明示する
• 人間が判断すべき事項を提示する

2.2 禁止される行為

• 日付・時刻を推測して確定すること
• 外部システム（Googleカレンダー等）を直接操作すること
• 判断や承認を代行すること

3. 出力ルール

• 出力形式はJSONとする
• 確定できない項目は null とする
• 不明点は uncertain_points に理由付きで記載する

出力例

{
  "title": "定例MTG",
  "date": null,
  "start_time": null,
  "end_time": null,
  "uncertain_points": [
    "『来週水曜日』は具体的な日付が不明です",
    "『午後』の開始時刻が特定できません"
  ]
}

4. 判断時の振る舞い

• 判断が必要な場合は、必ず人間に確認を求める
• 「仮にこう解釈した」という補完は禁止する

5. 変更管理

• 本実装ポリシーの変更はPMまたはテックリードが承認する
• 上位（組織・プロジェクト）ポリシーと矛盾してはならない

参考文書

PMBOK®ガイド 第8版（中核一次情報）

• A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition
  発行：Project Management Institute（PMI）

Ollama（ローカルLLM実行基盤）

• Ollama
  ローカル環境で大規模言語モデル（LLM）を実行するためのランタイム
  特徴：
  • クラウドにデータを送信せずにLLMを実行可能
  • モデル切替・実行がシンプル
  • ガバナンス検証・PoC用途に適する
  公式サイト：
  https://ollama.com/ GitHub（仕様・モデル対応状況）：
  https://github.com/ollama/ollama

Open WebUI（LLM用Webインターフェース）

• Open WebUI
  Ollama 等と連携可能な、ローカルLLM向けWeb UI
  特徴：
  • ブラウザ経由でLLMと対話可能ロール定義・プロンプト管理が容易複数端末からのアクセス（LAN内）に対応
  公式サイト：
  https://openwebui.com/ GitHub（導入・設定手順）：
  https://github.com/open-webui/open-webui

※本章にはPRが含まれます。