AIエージェント時代のRACIと「説明責任」――PMP実務者のためのステークホルダー管理

Nick／野村です。有限会社システムマネジメントアンドコントロール（SMCL）で、PMP®・CAPM®・PMI-ACP® の試験対策と、プロジェクトマネジメントの実務支援をしています。

先日、PMIの公式ブログに、実務者にとって示唆的な記事が出ました。原題は “Stakeholder Management and RACI: Who Does What, and Who Answers for It”（ステークホルダー・マネジメントとRACI：誰が何をやり、誰が責任を負うのか）。2026年7月29日付です。テーマは、AIエージェントがプロジェクトチームの作業の一部を担うようになったとき、RACIと説明責任をどう設計するか。資格試験だけでなく、日々のマネジメントに直結する話なので、弊社の視点を添えて整理します。（原典リンクは末尾）

まず用語を厳密に：RACIとは何か

RACIは、1つのタスクまたは意思決定について、4つの役割を割り当てる手法です。用語の定訳を固定しておきます。

• Responsible（実行責任）：実際に作業を行う人。複数いてよい。
• Accountable（説明責任）：成果を所有し、その結果について答える人。必ず1人。
• Consulted（相談対象）：作業の前に意見を求める相手。双方向。
• Informed（報告対象）：決定や進捗の後に知らされる相手。一方向。

RACIの本質は表を埋めることではなく、この「Accountable は1つの成果につき1人」という原則を、動いているプロジェクトの上で守り続けることにあります。PMI記事も、グリッド自体は難しくない、難しいのは優先順位が動く現場で役割を正直に保つことだ、と指摘しています（出典：前掲PMIブログ）。ここは実務でも同感です。Accountable が2人いれば次の対立の火種になり、0人なら次の「ボール落ち」を準備することになります。

このRACIの定義は、PMP® 試験対策でも大切なポイントです。役割語の意味（とくに Responsible と Accountable の違い、そして「Accountable は1つの成果につき1人」という原則）は、試験でも実務でも問われます。まず定義を正確に押さえることが、得点にも現場にも効いてきます。

もう一つ補足しておきます。RACIには、目的に応じて拡張した派生形があります。私がよく参照するのは、ハネウェル（Honeywell）で用いられている RACI-X です。末尾の X は「何もしない・させない」を表します。つまり、そのタスクについて、あえて着手しない／関与させないことを、意図的に明示する役割です。

一般的な RASCI（S＝Support／支援）などが役割を「足す」方向の拡張であるのに対し、RACI-X は「あえて手を出さない」ことを明示できる点が実務的です。善意の“やりすぎ”や担当外からの横やりを防ぎ、責任の所在をぼかさずに済みます。もちろん、「Accountable は1つの成果につき1人」という土台は変わりません。

この発想は、AIエージェントの統治とも相性が良いと感じます。エージェントに「やらせないこと（＝X）」を先に決めておくと、権限のはみ出しや想定外の実行を未然に防げます。

記事の核心：AIは Responsible にはなれるが、Accountable にはしない

PMI記事の中心的な主張は明快です。AIエージェントが実タスク（議事要約、ステータス草案、リスク分析、定型ワークフローなど）を担うようになっても、説明責任・承認権限・エスカレーションの所有は人間に残す、というものです。記事のFAQでも「AIエージェントを Accountable にしてはいけない」と明言されています（出典：前掲PMIブログ）。

言い換えると、RACIの文字（R/A/C/I）は変わりません。変わるのは、その表が「人だけの仕事」ではなく「人＋エージェントの仕事」を統治対象にする点です。エージェントは限定された定型作業について Responsible になれる。しかし、信頼・交渉・トラブル時の答えは所有できない。ここを弊社は、実務でエージェントを導入するときの最初の線引きとして推奨します。

実務の勘所（1）：エスカレーションの所有者を、稼働前に人間で決める

いちばん難しいのはエスカレーションだ、と記事は述べます。エージェントが想定外の判断をしたとき、その責任は「技術担当」ではなく「そのプロセスに説明責任を持つ人間」に属する、という整理です。例えばエージェントがレポート業務を担うなら、業務上のエスカレーションを所有するのはプロジェクトマネージャーです（出典：前掲PMIブログ）。

弊社の補足として、これは順序が肝心です。エージェントを動かす前に、エスカレーションの所有者（人間）を名指しし、あわせて「何をもってエスカレーションとするか」（顧客影響・金額影響・コンプライアンス露出・安全性など）を定義しておく。事後に決めようとすると、「AI担当チームが見ているはず」という全員の思い込みに落ちます。

実務の勘所（2）：レビューは「リスクで階層化」する

記事は、AIが関与するワークフローには人間のワークフローと同等、しばしばそれ以上の統制（適切なアクセス制限、高影響アクションへのピアレビュー、明確な承認ゲート、名前のある人間のエスカレーション所有者）が要る、とします（出典：前掲PMIブログ）。

一方で、全メッセージに法務レビューを付けるのは現実的でない、とも認めています。「全て」だと、膨大な量のメッセージのレビューが必要となりますね。そこで、まず「フル装備」の設計を描き、それをリスクで薄める。定型更新は軽い確認またはスポットチェック、規制対象・対外的に拘束力のある内容だけ完全な Consulted レビューに回す。この「リスクで階層化する」考え方は、統制を絵に描いた餅にしないための実務的な落としどころです。

象徴的な事例として、記事は2026年初頭に報じられた、AWSのコーディングエージェント「Kiro」が障害対応中に本番環境を削除したとされる件を挙げています。Amazonはこれを「暴走ではなく設定ミスが原因」と反論し、本番アクセスにピアレビューを必須化したと報じられています（出典：前掲PMIブログ、および同記事が参照する報道）。どちらの見方に立っても、記事の結論は同じで、教訓は技術ではなく手続き――自分でスポットチェックできないものに承認印を押さない、人間に求めるのと同じアクセス制御とレビューをエージェントにも課す――という点です。ここは事実として両論を併記しておきます。

実務の勘所（3）：エージェントに「名前」を与え、可観測にする

見落とされがちですが重要なのが、エージェントをツール上で独立した担当者（アサイニー、またはサービスアカウント）として表現し、人間の名前の下に隠さないことです。Jira、Asana などのトラッカー上で、エージェントの行った入力・アクションと、それを承認した人間を記録する。こうしておくと、各行が可視化され、監査・検証・差し戻しが可能になります（出典：前掲PMIブログ）。「エージェントは実行できる、しかし人間が説明責任を負う。例外は業務オーナーに上げる」――このルールを文章で書き下しておく、という助言も実務的です。

人＋エージェントのRACI（一例）

記事が示す、週次のステークホルダー連絡ワークフローの例を、弊社で表現し直すと次のようになります（役割の考え方は原典に基づきます）。

ポイントは、エージェントが「限定された反復作業」の Responsible を担い、人間（PM）が全行で Accountable を保ち、送信や例外対応では自らペンを取る、という構造です。Rを「エージェントの実行」と「人間の監督」の二層で考える、という整理が有効です。

資格試験と実務の両面で、なぜ今この話か

ステークホルダー・エンゲージメントは、PMBOK® ガイドにおいて独立した「パフォーマンス・ドメイン」として扱われる、中核の実行業務です（出典：前掲PMIブログ）。加えて、2026年7月に切り替わった新しいPMP® 試験では、Business Environment の比重が上がり、AIや価値実現（アウトカム）への比重も増えています。つまり、AI時代のステークホルダー・マネジメントとRACIは、試験対策としても実務としても外せないテーマになっています。

ここで、私自身の現場の話も少しだけ。実は私も、複数のエージェントと日常的に仕事をしています。あるプロダクト開発では、7つほどのエージェントを同時並行で動かして作業を進めることもあります。そのなかで、この記事には書かれていない工夫として効果が大きいのが、エージェント同士にチェックさせる、という方法です。人間が判断できる粒度のメッセージを Slack や Mattermost に投げてもらい、エージェント同士の対話を可視化・記録しながら、要所を人間がチェックする仕組みにしています。あるエージェントが別のエージェントのミスを指摘する様子は、なかなか微笑ましいものです。もちろん、最終的な説明責任（Accountable）は人間である私が持つ、という原則は崩しません。記事の言う「エージェントは Responsible、人間が Accountable」を、相互チェックと可観測化で実装した形、と言えます。

弊社SMCLでは、新試験（ECO 2026）とPMBOK® ガイド第8版に対応したPMP講座を制作中です。RACIや説明責任の設計は、資格の得点源であると同時に、AIを現場に入れるときの安全装置でもあります。学習と実務の両方から、丁寧に扱っていきます。

まとめ

• RACIの原則は変わらない。Accountable は1つの成果につき1人。
• AIエージェントは Responsible になれるが、Accountable にはしない。説明責任・承認・エスカレーション所有は人間に残す。
• 稼働前にエスカレーション所有者（人間）を名指しし、レビューはリスクで階層化し、エージェントはツール上で名前を与えて可観測にする。

元記事はPMI公式ブログで読めます。実務でAIエージェントの導入を検討している方は、原典にも目を通すことをおすすめします。

出典：PMI Blog “Stakeholder Management and RACI: Who Does What, and Who Answers for It”（2026年7月29日）
https://www.pmi.org/blog/stakeholder-management-raci