RACIとは？意味・RACIチャートの作り方・具体例・テンプレート【2026年版】

RACIは、プロジェクトの役割分担を1枚の表にまとめるフレームワークです。「この作業は誰がやるのか」「最終的に誰が承認するのか」があいまいなまま進めると、終盤で手戻りや責任の押し付け合いが起こりがちです。RACIを使えば、こうした行き違いを着手前に防げます。

この記事では、RACIの意味と4つの役割、Webサイトリニューアルを例にした具体例、RACIチャートの作り方と点検方法を解説します。RASCIやDACIとの違い、よくある失敗、コピーして使えるテンプレート、会議で役割分担を定着させるコツもまとめました。

⚠️ 本記事は、2026年10月時点の公開情報やユーザーフィードバックを基に独自にまとめたものです。

目次

1. RACIとは？
2. 4つの役割の意味
3. RACIチャートの具体例：Webサイトリニューアル
4. RACIチャートの作り方：6つのステップ
5. 完成したRACIチャートの点検方法
6. RACIとRASCI・DACI・RAPIDの違い
7. RACIが向いている場面・向いていない場面
8. RACIでよくある失敗
9. コピーして使えるRACIテンプレート
10. 会議で役割分担を形骸化させないコツ
11. よくある質問（FAQ）
12. まとめ

RACIとは？

RACI（レイシー）とは、プロジェクトのタスクや意思決定ごとに、関係者の役割を「実行責任者（Responsible）」「説明責任者（Accountable）」「相談先（Consulted）」「報告先（Informed）」の4つに分けて割り当てる手法です。 縦にタスク、横に担当者を並べた表を「RACIチャート」「RACI図」「責任分担表」などと呼びます。

行を横に読むと、そのタスクを誰が進め、誰が最終責任を持ち、誰に相談し、誰に結果を伝えるのかがわかります。列を縦に読むと、1人の担当者が抱えている役割の全体像が見えてきます。

RACIはプロジェクトマネジメントの定番ツールです。PMI（米国プロジェクトマネジメント協会）のPMBOKガイドでも、責任分担マトリックス（RAM）の代表的な形式として紹介されています。PMP試験の学習やPM研修で、一度は目にした方も多いでしょう。

RACIの価値は、アルファベットそのものにはありません。表を埋めていくうちに、普段は後回しにしがちな話し合いを避けられなくなる点にあります。たとえば、2人の部長がそれぞれ「承認するのは自分だ」と思い込んでいたとします。RACIを作れば、その食い違いはリリース直前ではなく初日に表に出ます。法務チェックを誰も想定していなかった場合も、相談先の欄が空いていることで気づけます。

なお、RACIチャートはプロジェクト計画書の代わりにはなりません。日程や依存関係、工数は書かないからです。計画書が「いつ」を管理するのに対し、RACIが管理するのは「誰が、どの立場で関わるか」です。両方をセットで使うのが基本です。

4つの役割の意味

4つの役割は一見わかりやすいものの、人によって解釈がずれやすい部分でもあります。チームで最初にすり合わせておきたい定義をまとめました。

R（実行責任者）は、成果物を実際に作る人です。原稿を書く、機能を実装する、分析をまとめるなど、手を動かす役割を担います。Rが空欄のタスクは、内容を全員が理解していても前に進みません。

A（説明責任者）は、結果に対して最終的な責任を持つ1人です。成果物を承認し、実行責任者の間で意見が割れたときには判断を下します。うまくいかなかったときに経緯を説明するのも、この人の役目です。RACIでいちばん大切なルールは「Aは1行に必ず1人」です。Aが2人いると、お互いに「相手が見ているだろう」と考えてしまい、結局誰も責任を持たなくなります。

RとAの違いは、多くのチームがつまずくところです。日本語ではどちらも「責任者」と訳されるので、なおさら混同しやすくなります。覚え方はシンプルで、Rは「やる人」、Aは「責任を取る人」です。小さなタスクでは同じ人が兼ねることも多く、その場合は表に「A/R」と書けば問題ありません。大きなタスクでは、別の人になるのが普通です。たとえばトップページのデザインを作るのはデザイナー（R）ですが、期日どおりに公開して成果を出す責任は、マーケティング責任者（A）が負います。

C（相談先）は、専門的な知見で作業の質を左右する人です。システム構成を変える前のセキュリティ担当や、価格を決める前の経理担当がこれにあたります。相談は双方向で、お互いの時間を使います。Cを1人増やすごとに、タスクは遅くなると考えておきましょう。

I（報告先）は、進捗や結果を知っておく必要はあるものの、意見は求めない相手です。進捗報告やリリースのお知らせ、会議の要約メールを受け取る立場にあたります。報告にかかる手間はわずかですが、効果は大きいものです。部門をまたぐプロジェクトの不満は、反対意見よりも「聞いていなかった」から生まれることが多いからです。

RACIチャートの具体例：Webサイトリニューアル

中堅企業がコーポレートサイトをリニューアルするケースで、RACIチャートを作ってみます。登場するのは6つの役割と8つのタスクです。

この表から読み取れるポイントは4つあります。

• どの行も、Aは1人だけです。 大半のタスクはマーケティング責任者がAですが、実装はWebエンジニア、法務チェックは法務部がAを持っています。Aは、役職の高い人に自動で割り振るものではありません。その成果について説明できる立場の人に任せます。
• 専門性の高いタスクは「A/R」になります。 実行と最終責任を同じ人が担うのは、ごく自然なことです。
• 営業はほとんどがIです。 営業部にとって新しいサイトは重要ですが、デザインの相談先に入れるとレビューが1回増えます。そのわりに得られるものは多くありません。要所で報告を入れれば、足並みをそろえつつ、進行を遅らせずに済みます。
• 空欄があってかまいません。 全員がすべてのタスクに関わる必要はありません。表がびっしり埋まっているなら、むしろ見直しのサインです。

RACIチャートの作り方：6つのステップ

一般的なプロジェクトなら、RACIチャートは1時間ほどで作れます。その大半は話し合いの時間ですが、実はそれこそが目的です。

1. タスク・成果物・意思決定を洗い出す。 担当が切り替わる粒度で書き出すのがコツです。「サイトを公開する」では粗すぎますし、「フッターのリンク色を直す」では細かすぎます。多くのプロジェクトでは、8〜20行に収まります。「予算の承認」「外注先の選定」といった意思決定は、独立した行にしましょう。あいまいさがいちばん問題になるのは、こうした判断の場面だからです。
2. 役割を並べる。 メンバーが入れ替わる可能性があるなら、個人名より役割名（「佐藤さん」ではなく「プロダクトマネージャー」）で書きます。実名は、表の下に凡例として添えてください。制作会社や顧客など、実作業を担う社外の関係者も忘れずに含めます。
3. 最初にAを決める。 各行について「失敗したら誰が説明するのか」を考えます。その人がAです。いちばん揉めやすいのがAなので、先に決めておくと後の調整が楽になります。
4. 次にR、続けてCとIを決める。 作業するのは誰か、本当に専門的な意見が必要なのは誰か、結果だけ知っていればよいのは誰か、という順に考えます。Cは控えめにしましょう。相談先を1人増やすことは、打ち合わせやレビューを1回約束することと同じです。
5. 関係者全員で読み合わせる。 メールで回して意見を集めるのではなく、短い会議で一緒に確認します。意見の食い違いは、口頭のほうが早く表に出ます。自分も関わって決めた役割なら、メンバーも納得して引き受けやすくなります。プロジェクト全体でも、いちばん価値のある会議になることが珍しくありません。
6. 公開して、定期的に見直す。 プロジェクトの資料や社内Wiki、プロジェクト用のチャンネルなど、チームが普段使う場所に置きます。フェーズが変わったときやメンバーが入れ替わったときには、必ず見直しましょう。古いままのRACIチャートは、ないよりも害があります。みんなが内容を信じて動いてしまうからです。

完成したRACIチャートの点検方法

表が埋まったら、行ごと（横）と列ごと（縦）の2方向で読み直します。向きによって、見つかる問題が違います。

行ごとに見る（タスク）：

列ごとに見る（担当者）：

RACIの効果がいちばん出るのは、この2方向の点検です。たとえば、1つの列にAばかりが並んでいたとします。プロジェクトがたびたび止まる原因は、たいていこれで説明がつきます。すべての判断が、同じ1人の予定待ちになっているのです。

RACIとRASCI・DACI・RAPIDの違い

RACIにはいくつかの派生形があります。どれが優れているということはなく、重視するポイントがそれぞれ違います。

いちばん大きな違いは、「タスクの責任」を扱うのか、「意思決定の責任」を扱うのかという点です。RACIは、多数のタスクについて「誰が何をするか」を整理する手法です。一方、DACIやRAPIDは「この1つの判断をどう下すか」を整理するために使います。DACIでは、推進者（Driver）がプロセスを動かし、承認者（Approver）が最終判断をします。RACIのRとAに近い関係ですが、対象は成果物の一覧ではなく、1つの意思決定に限られます。DACIや決裁権限の決め方は、意思決定のガイドで詳しく解説しています。

実務では、両者を組み合わせて使うことが多くあります。プロジェクト全体はRACIで管理し、その中の大きな判断2〜3件だけをDACIで整理するという方法です。

RACIが向いている場面・向いていない場面

RACIは、連携の難しさを解消するためのツールです。そのため、連携が難しい場面ほど効果を発揮します。

向いている場面：

• 3つ以上のチームや部署にまたがるプロジェクトです。
• 途中から参加したメンバーが、誰が何を担当しているかを把握する必要があるときです。
• 「本来は誰が承認すべきだったのか」という議論が、すでに2回起きているときです。
• 制作会社や顧客、外部ベンダーなど社外と協業し、役割の線引きが必要なときです。
• 月次決算や障害対応、リリース作業など、定型業務で抜け漏れがたびたび起きるときです。

向いていない場面：

• 毎日顔を合わせる3人程度のチームです。
• 探索的な仕事で、役割が毎週のように変わるときです。
• テンプレートを埋めること自体が目的になっていて、誰も読む予定がないときです。

判断の目安は単純です。役割があいまいなせいで起きた最近のトラブルを、誰も挙げられないとします。その状態でRACIを入れても、ただの事務作業に感じられるでしょう。逆に、何人もがすぐ例を挙げられるなら、RACIは歓迎されるはずです。

RACIでよくある失敗

• Aが2人以上いる。 最も多く、最も深刻な失敗です。共同責任は協力的に見えますが、実際にはお互いが相手の動きを待つことになります。2人のリーダーが本当に同じ目標を持っているなら、行を2つのタスクに分け、それぞれにAを1人ずつ置きましょう。
• 役職の高さで責任を決めてしまう。 役員がすべての行でAになる必要はありません。Aは、成果に最も近く、判断する権限を持つ人に任せるのが原則です。経営層を全行に入れると、先ほど説明したボトルネックがそのまま生まれます。
• 相談先を増やしすぎる。 「念のため」「角が立たないように」とCを足してしまうのは、よくあることです。ただ、Cが1人増えるたびに、確認の往復も1回増えます。意見をもらえたらうれしい程度なら、Iに切り替えましょう。
• 部署単位で役割を割り当てる。 「情報システム部がR」と書くと一見明確ですが、実際に手を動かす人が決まっていません。できる限り、1人を指す役割名か個人名で書きます。
• 1人で作って配るだけで終わる。 マネージャーが1人で作成してメールで配ったRACIは、ただの仮説にすぎません。ステップ5の読み合わせを経て、初めてチームの合意になります。
• 一度作ったきり見直さない。 プロジェクトが進むと、役割は少しずつ変わっていきます。フェーズの切り替わりで見直さなければ、表と現実はやがてかけ離れてしまいます。
• 会議でRACIを使わない。 表では外注先の選定のAが佐藤さんなのに、会議では最後に発言した人の意見で決まってしまうことがあります。実際に仕事が割り振られる場でRACIが使われなければ、表を作った意味がありません。

コピーして使えるRACIテンプレート

以下をプロジェクト資料に貼り付け、[ ]の部分を書き換えて使ってください。凡例は消さずに残しておくのがおすすめです。全員が同じ意味でアルファベットを読めることが、RACIの効果の半分を占めるからです。

RACIチャート：[プロジェクト名]
本表の管理者：[氏名]　最終更新日：[日付]

凡例
R = 実行責任者（作業を行う。1人以上）
A = 説明責任者（結果に責任を持ち承認する。各行に必ず1人）
C = 相談先（作業前・作業中に意見を求める。双方向）
I = 報告先（結果を共有する。一方向）

| タスク／意思決定          | [役割1] | [役割2] | [役割3] | [役割4] | [役割5] |
|---------------------------|---------|---------|---------|---------|---------|
| [スコープの決定]          | A       | C       | C       |         | I       |
| [成果物1]                 | C       | A/R     |         | C       |         |
| [成果物2]                 |         | C       | A       | R       | I       |
| [意思決定：予算]          | A       | C       | C       |         | I       |
| [意思決定：公開可否]      | A       | C       | I       | C       | I       |

氏名：[役割1] = [氏名]、[役割2] = [氏名]、…

公開前チェック
[ ] 各行のAは1人だけ
[ ] 各行にRが1人以上いる
[ ] AとRが1人に集中している列がない
[ ] 関係者全員で読み合わせた
[ ] 次回の見直し日を決めた：[日付]

会議で役割分担を形骸化させないコツ

RACIチャートは1回の会議で決まり、その後のすべての会議で試されます。キックオフや定例、意思決定の会議は、タスクが割り振られる場です。そこで責任の所在がはっきりするか、なんとなくぼやけていくかが決まります。表と現実をずらさないために、次の3つの習慣を取り入れましょう。

• 仕事を振るときに、役割を口に出します。 「外注先の選定は、佐藤さんに最終判断をお願いします。田中さんと鈴木さんは、木曜までに意見を送ってください」と伝えるだけです。5秒で済み、RACIの役割分担がその場で全員に共有されます。
• 会議の最後に、担当者を読み上げます。 タスクごとに「実行するのは誰で、責任を持つのは誰か」を確認します。誰かが言いよどんだら、そこがRACIの抜けです。
• チームが見つけられる場所に、記録を残します。 出席者の記憶にしかない割り振りは、時間とともにずれていきます。誰が何を引き受けたのかを示す根拠になるのは、議事録だけです。

多くのチームがつまずくのは3つ目です。会議を進行しながら詳しい議事録を取るのは、やはり大変だからです。この部分は、AIに任せられます。

SuperInternは、MacとWindowsで使えるボットレスのAI議事録アプリです。PCの音声を直接取り込むため、会議にボットが参加することはありません。Zoom、Google Meet、Microsoft Teams、Webexのほか、対面の会議でも同じように使えます。

RACIで役割分担を管理しているチームには、次のような使い方がおすすめです。

• AI Canvasが、指定した形式で議事録をリアルタイムに作ります。 「タスクごとに実行責任者・説明責任者・期限を書き出し、担当者が決まっていないタスクには印を付けてください」と、普段の言葉で一度指示しておきます。すると議事録が会議中にその形式で書き上がっていくので、最後の読み上げもすでに画面に出ている内容を確認するだけで済みます。

• 話者識別で、誰が引き受けたかを記録できます。 文字起こしに「それは私がやります」と言った人の名前が残るので、後から記憶に頼らずに担当を確認できます。カレンダーの予定から参加者を追加できるため、話者の名前付けも手早く済みます。
• 会議をまたいで、チャットで質問できます。 「外注先選定の説明責任者は誰で、期限はいつと決めた？」と聞けば、プロジェクトの会議で実際に話された内容をもとに答えが返ってきます。
• 決まった担当を、普段のツールに反映できます。 SuperInternのMCP連携を使えば、ClaudeやChatGPTなどのAIエージェントが議事録を読み取ります。合意したタスクを、LinearやAsanaなどのチケットとして登録することもできます。

50以上の言語に対応したリアルタイム字幕・翻訳もあるので、海外メンバーを含むチームでも使えます。なお、SuperInternはRACIチャートそのものを置き換えるツールではありません。表はこれまでどおり、プロジェクト資料で管理します。SuperInternの役目は、仕事が割り振られるたびに、決めた役割分担を確実に記録として残すことです。無料プランがあるので、次のキックオフで気軽に試せます。

よくある質問（FAQ）

RACIは何の略ですか？

Responsible（実行責任者）、Accountable（説明責任者）、Consulted（相談先）、Informed（報告先）の頭文字です。Rは作業を行う人、Aは結果に責任を持って承認する人、Cは作業の前や途中に意見を求める人、Iは結果を共有する相手を指します。

実行責任者（R）と説明責任者（A）の違いは何ですか？

Rは作業をする人、Aは結果に責任を持つ人です。1つのタスクにRは複数いてもかまいませんが、Aは1人だけです。Aは成果物を承認し、結果について説明する立場にあります。小さなタスクでは同じ人が兼ねることが多く、その場合は「A/R」と書きます。

1つのタスクにAを2人置いてもよいですか？

おすすめしません。RACIの基本ルールは「1タスクにAは1人」です。責任を共有すると、たいていは誰も責任を持たない状態になります。2人がそれぞれ別の部分を担っているなら、タスクを2行に分けましょう。

RACIとDACIの違いは何ですか？

RACIは、プロジェクト内の多数のタスクについて役割を割り当てる手法です。DACI（推進者・承認者・貢献者・報告先）は1つの意思決定に絞り、誰が議論を進め、誰が最終判断するかを明確にします。プロジェクト全体はRACI、大きな判断はDACIと使い分けるチームが多く見られます。

RASCIとは何ですか？

RACIにS（Support：支援者）を加えたものです。支援者は実行責任者の作業を手伝いますが、成果物の責任は持ちません。IT運用やシェアードサービスのように、支援チームが多く関わる大きなタスクで役立ちます。

ExcelやGoogleスプレッドシートでRACIチャートを作るには？

1列目にタスク、1行目に役割を並べ、各セルにR・A・C・Iを入力します。条件付き書式で文字ごとに色を変えると、ぐっと見やすくなります。さらに行ごとにCOUNTIF関数で「A」の数を数えれば、Aがない行や2人以上いる行をすぐに見つけられます。

RACIチャートはどのくらいの頻度で見直すべきですか？

フェーズが切り替わるとき、メンバーが加わったり抜けたりしたとき、そして担当をめぐって揉めたときが見直しのタイミングです。継続的な業務プロセスであれば、四半期に1回を目安にするとよいでしょう。

まとめ

RACIは、プロジェクトマネジメントの中でも特にシンプルな手法です。その価値は、表を作る過程で生まれる話し合いにあります。まずタスクと意思決定を洗い出し、最初に各行のAを1人ずつ決めます。Cは必要最小限にとどめ、表を横と縦の両方から点検します。完成したら、関係者全員で読み合わせましょう。

そのうえで大切なのが、決めた役割を日々の会議で生かすことです。仕事を振るときにRとAを口に出し、会議の最後に担当者を確認し、誰かの記憶に頼らない記録を残します。この習慣が根づけば、「てっきりそちらで対応していると思っていました」という言葉を聞くことは、ほとんどなくなるはずです。

SuperInternを無料で試す ― 会議中の担当者とタスクを、リアルタイムで漏れなく記録するボットレスのAI議事録です。