AIでステークホルダーマップを作るプロンプト｜推測を事実にしない利害関係者分析テンプレート
新規プロジェクトや業務改革で、「誰に先に相談すべきか」「誰の反対が進行を止めるか」を整理したい人向けのプロンプトです。
AIに関係者名だけを渡しても、実用的なステークホルダーマップにはなりません。権限と関心度を分けて評価し、根拠がない項目は推測で埋めず、確認事項として残すことが重要です。
この記事のテンプレートでは、次の順番で整理します。
- プロジェクトに関係する人・部署・社外組織を洗い出す
- 各関係者の権限、関心、賛否、期待、懸念を評価する
- パワー・インタレスト・グリッドの4区分に配置する
- 区分ごとの働きかけ方と連絡頻度を決める
- 情報不足と確認すべき質問を明示する
このプロンプトで作れるもの
完成物は単なる関係者一覧ではなく、誰に、何を、いつ伝えるかを決めるための分析資料です。
ステークホルダーとは、プロジェクトの意思決定に影響を与える人だけではありません。成果の影響を受ける利用者、運用担当者、承認者、予算管理者、取引先、規制機関なども対象です。
パワー・インタレスト・グリッドでは、関係者を「権限・影響力」と「プロジェクトへの関心度」の2軸で整理します。PMIの解説でも、権限と関心度による2×2の分類が紹介されています。
一般的な4区分は次のとおりです。
- 高権限・高関心：密接に連携する
重要な判断に参加してもらい、短い間隔で状況を共有する - 高権限・低関心：満足を維持する
判断に必要な情報を簡潔に伝え、過剰な連絡は避ける - 低権限・高関心：十分に情報提供する
変更内容や進捗を共有し、現場からの意見を集める - 低権限・低関心：状況を観察する
必要な節目だけ伝え、権限や関心の変化を確認する
ここがポイント: 4区分は人物の重要度を決める序列ではありません。現在のプロジェクトで必要な関わり方を選ぶための分類です。
この整理は、システム導入、商品開発、業務フロー変更、イベント企画、社内制度の改定などに使えます。一方、組織内の実権や人間関係は入力資料に現れにくいため、AIの出力だけで確定させず、プロジェクト責任者や現場担当者が確認してください。
コピペ用プロンプトテンプレート
以下をChatGPT、Claude、Geminiなどの対話型AIへ貼り付け、{}内を書き換えて使います。特定サービスだけに依存しない汎用テンプレートです。
あなたはプロジェクトマネジメントを支援するアナリストです。
以下の情報をもとに、ステークホルダーマップと働きかけ方を作成してください。
# 目的
プロジェクトに影響する関係者と、プロジェクトから影響を受ける関係者を整理し、
誰に・何を・どの頻度で伝えるべきか判断できる状態にする。
# プロジェクト情報
- プロジェクト名：{プロジェクト名}
- 目的：{達成したいこと}
- 主な変更：{導入・廃止・変更する業務、製品、制度など}
- 対象範囲：{対象となる部署、拠点、顧客、業務など}
- 対象外：{今回扱わない範囲}
- 現在の段階：{企画／要件定義／実行／移行／運用など}
- 期限・重要な節目：{日付または時期}
- 制約：{予算、法令、セキュリティ、人員、契約など}
# 判明している関係者
{氏名ではなく、役割・部署・組織を中心に列挙する。例：事業責任者、経理部、店舗責任者、現場利用者、委託先}
# 関係者について判明している情報
{承認権限、予算権限、期待、懸念、賛否、過去の発言、影響を受ける業務などを記載する}
# 分析ルール
1. 入力にある事実と、そこから導いた仮説を区別する。
2. 情報がない権限、関心度、賛否、利害を断定しない。
3. 不明な項目は「不明」とし、確認質問を示す。
4. 関係者の役職だけで権限や関心度を決めない。
5. 公式な決裁権だけでなく、現場への影響力、専門知識、拒否権、予算権限も確認する。
6. 同じ部署でも役割や利害が異なる場合は分ける。
7. 個人への否定的なレッテル貼りは避け、観察可能な事実とプロジェクト上の懸念を書く。
8. 個人情報や機密情報を補完・創作しない。
# 評価基準
- 権限・影響力：高／中／低／不明
- 高：承認、予算、停止、優先順位の変更などを行える
- 中：意思決定者への助言、現場の合意形成、専門判断に影響する
- 低：直接の決裁権は限定的だが、変更の影響を受ける
- 関心度：高／中／低／不明
- 高：成果や業務変更が本人・部署の目標や負担に直接関係する
- 中：一部の業務、評価、顧客対応などに影響する
- 低：現時点で直接の影響が小さい
- 現在の姿勢：支持／中立／懸念あり／反対／不明
- 根拠の確度：事実／仮説／不明
# 出力形式
次の順番で日本語で出力する。
## 1. 分析の前提
- 入力から確認できた事実
- 分析上の仮説
- 情報不足による制約
## 2. ステークホルダー別カード
各関係者について、次の項目を記載する。
- 関係者（役割・部署・組織）
- プロジェクトとの関係
- 受ける影響
- 権限・影響力：高／中／低／不明
- 関心度：高／中／低／不明
- 現在の姿勢：支持／中立／懸念あり／反対／不明
- 期待
- 懸念
- 評価の根拠
- 根拠の確度：事実／仮説／不明
- 推奨する働きかけ
- 担当者
- 手段
- 頻度・タイミング
## 3. パワー・インタレスト・グリッド
- 高権限・高関心：密接に連携する
- 高権限・低関心：満足を維持する
- 低権限・高関心：十分に情報提供する
- 低権限・低関心：状況を観察する
- 中または不明：暫定配置せず、追加確認する
各区分に関係者を配置し、配置理由を1文で添える。
## 4. 優先アクション
今後2週間で行う働きかけを優先順に最大5件示す。
各項目に「対象」「目的」「実施者」「期限」「伝える内容」「確認する反応」を含める。
期限を入力情報から決められない場合は、具体的な日付を創作せず「要設定」とする。
## 5. 未確認事項
分析の精度を上げるために関係者へ確認すべき質問を、重要度順に最大10件示す。
## 6. セルフチェック
- 影響を受ける現場利用者を漏らしていないか
- 反対者を根拠なく決めつけていないか
- 仮説を事実として記載していないか
- 各関係者への働きかけが具体的か
- 担当者または期限が未設定のアクションを明示したか
問題があれば、該当箇所と修正案を示す。
入力時に変える部分
最も重要なのは、関係者名を増やすことより「何が変わり、誰の仕事や判断に触れるのか」を書くことです。
必ず入力したい項目
{達成したいこと}
「業務を効率化する」ではなく、「申請から承認までの日数を短縮する」のように、変化が分かる表現にします。{主な変更}
新しいシステムの導入、承認工程の削減、担当業務の移管などを具体化します。{対象範囲}
部署、拠点、利用者、取引先など、影響が届く範囲を示します。{判明している関係者}
個人名が不要なら、役割や部署名に置き換えます。{関係者について判明している情報}
議事録や規程で確認できる権限、本人が示した要望、変更後に増減する作業を入れます。
固定した方がよい条件
毎回残しておきたいのは、次の指示です。
- 事実・仮説・不明を分ける
- 不明な評価を無理に埋めない
- 評価の根拠を書く
- 「中」「不明」は4区分へ強引に配置しない
- 働きかけに担当者、手段、時期を付ける
- 個人への評価ではなく、プロジェクトとの関係を記述する
ここを省くと、AIは空欄を自然な文章で補い、確認していない人物像まで作ってしまうことがあります。
入力前に集める資料
機密情報の取り扱いルールを確認したうえで、次の資料から必要な部分だけを入力します。
- プロジェクト概要、企画書、対象範囲
- 組織図、決裁規程、会議体一覧
- 業務フロー、変更前後の手順
- 議事録、合意済み事項、未決事項
- 契約、法令、監査、セキュリティ上の制約
AIへ入力できない資料は、担当者が要点を匿名化して整理します。個人の評価、未公開の人事情報、顧客情報などを、そのまま外部サービスへ貼り付けないでください。
NG例と改善例
NG例：名前だけ渡して分類させる
新システム導入のステークホルダーマップを作ってください。
関係者は社長、情報システム部、営業部、顧客です。
この指示では、AIは各関係者の権限や関心度を推測するしかありません。「社長だから高権限」「顧客だから高関心」といった、肩書きに依存した分類になりやすい状態です。
また、「営業部」の中でも、責任者と実際の利用者では受ける影響が違います。部署を一つの利害として扱うと、導入後の操作負担や顧客対応の変化が見えません。
改善例：変更、権限、影響を分けて渡す
顧客問い合わせ管理システムの切り替えについて、ステークホルダーマップを作成してください。
目的：問い合わせ履歴を一元化し、担当者間の引き継ぎ漏れを減らす。
対象：営業部とカスタマーサポート部が扱う法人顧客からの問い合わせ。
主な変更：個人管理の表計算ファイルを廃止し、共通システムへ記録する。
判明している関係者：
- 事業責任者：導入予算の承認者。
- 情報システム部：製品選定とセキュリティ審査を担当。
- 営業部の利用者：商談情報と問い合わせ履歴を入力する。
- カスタマーサポート部の利用者：過去履歴を参照し、対応結果を入力する。
- 法人顧客：問い合わせ方法は変わらないが、履歴が新システムに保存される。
不明な点：
- 各部門の入力作業が何分増減するか。
- 顧客への告知や同意が必要か。
- 導入後の運用責任者。
事実・仮説・不明を分け、不明な評価は断定しないでください。
各関係者の権限、関心度、期待、懸念、推奨する働きかけを示してください。
改善点は、関係者を増やしたことだけではありません。
- プロジェクトによって変わる業務を示した
- 同じ部門でも責任者と利用者を分けた
- 確認済みの権限を書いた
- 未確認事項を先に明示した
- AIに推測と事実を区別させた
この情報があれば、AIは「誰が重要か」という曖昧な評価ではなく、「予算承認には事業責任者との合意が必要」「現場利用者には入力負担の確認が必要」と、行動につながる形で整理できます。
出力を安定させる3つのコツ
1. 評価語に判定基準を付ける
「影響力が高い」の意味をプロンプト内で定義すると、分類のぶれを減らせます。
たとえば、承認権、予算権、停止権、専門判断、現場の合意形成を別々に入力します。役職名だけでは、正式な決裁権と実務上の影響力を区別できないためです。
関心度も「会議によく出席するか」ではなく、成果、負担、評価、顧客対応がどれだけ変わるかで判断させます。
2. 4区分へ無理に押し込まない
パワー・インタレスト・グリッドは2×2ですが、実務の情報は最初から高・低に分かれるとは限りません。
そこでテンプレートでは「中」と「不明」を認め、追加確認の対象にしています。曖昧な関係者を無理に4区分へ置くより、次の質問を作る方が安全です。
- 最終承認者は誰か
- 予算超過時に中止を判断できるのは誰か
- 業務変更で作業が増えるのは誰か
- 導入に反対しているのか、条件付きで支持しているのか
- 今後の段階で権限や関心が変わる可能性はあるか
3. マップと連絡計画を一続きにする
分類だけで終わると、会議資料に図が増えるだけです。出力には「担当者」「手段」「頻度・タイミング」「確認する反応」を含めます。
たとえば、高権限・高関心の関係者へ毎週報告すると決めても、担当者と目的がなければ実施されません。「プロジェクト責任者が、毎週の意思決定会議で、未決事項と選択肢を提示する」まで落とし込みます。
OpenAIのプロンプト作成ガイドでも、背景、望む結果、長さ、形式などを具体的に指定し、期待する出力形式を示す方法が案内されています。今回のテンプレートで評価基準と出力順を細かく指定しているのは、回答を実務で比較・修正しやすくするためです。
活用例と応用パターン
プロジェクト開始時
企画書と組織図をもとに暫定マップを作り、キックオフ前の聞き取り対象を決めます。この段階では空欄が多くても問題ありません。「不明」が、次に確認する項目になります。
要件定義・計画変更時
要件が増えたときや対象部署が変わったときは、既存のマップへ追記するだけで済ませず、影響を再評価します。
- 新たに承認が必要になった部署はないか
- 現場利用者の作業が増えていないか
- 外部委託先との契約変更が必要か
- 従来は低関心だった関係者が、移行時期の接近で高関心になっていないか
ステークホルダーマップは固定資料ではありません。プロジェクトの段階が変われば、同じ関係者でも権限の使われ方や関心度が変わります。
会議前の説明設計
同じ進捗情報でも、相手によって必要な内容は異なります。
- 承認者：判断事項、選択肢、費用、期限
- 現場利用者：操作変更、作業負担、支援方法
- 管理部門：規程、監査、契約、セキュリティ
- 社外関係者：自社への影響、依頼事項、変更日
AIには「全員向けの説明文」を一つ作らせるのではなく、マップの各区分に応じた説明要点を作らせます。ただし、相手ごとに事実を変えてはいけません。変えるのは情報の優先順位と詳しさです。
機械処理用データへ変換する
表計算ソフトや管理ツールへ取り込む場合は、分析後に次の追加指示を使えます。
確定済みのステークホルダー情報だけをCSV形式で出力してください。
列は次の順番にします。
stakeholder,relationship,power,interest,stance,evidence,evidence_status,engagement_owner,channel,timing,next_action
ルール：
- 1行目にヘッダーを出力する。
- 値にカンマや改行が含まれる場合はダブルクォートで囲む。
- 推測で空欄を埋めない。
- 不明な値は「不明」とする。
- CSV以外の説明文を出力しない。
この追加指示は、最初からCSVだけを作らせるのではなく、関係者カードと根拠を人が確認した後に使います。先に構造化すると、もっともらしい誤分類を見落としやすいためです。
使用前のチェックリスト
最後に、次の項目を確認してください。
- [ ] プロジェクトで「何が変わるか」を入力した
- [ ] 意思決定者だけでなく、影響を受ける利用者も含めた
- [ ] 同じ部署でも役割や利害が違う関係者を分けた
- [ ] 権限と関心度の根拠を入力した
- [ ] 事実・仮説・不明を分けるよう指示した
- [ ] 不明な人物像をAIに創作させていない
- [ ] 各関係者への働きかけに担当者と時期がある
- [ ] 個人情報や機密情報を入力してよい環境か確認した
- [ ] プロジェクト責任者と現場担当者が結果を見直した
- [ ] 節目ごとにマップを更新する日を決めた
最初に完成度の高い4象限図を作ることより、「不明」を残したまま、誰に何を確認するか決めることが先です。次の分岐点は、未確認事項への回答が集まった時点。そこで権限、関心度、姿勢を再評価し、暫定マップを実際の連絡計画へ更新してください。