RACIとは？意味と4つの役割・作り方を図解で初心者向けに解説

RACI（レイシー）とは、タスクごとに「誰が・どんな責任を持つか」を、R（実行責任）・A（最終責任）・C（相談）・I（報告）の4つの役割で整理した表のことです。

日本語では責任分担マトリクスや責任分担表とも呼ばれ、プロジェクト管理や業務の役割分担で広く使われています。

「担当は決めたのに、いざ問題が起きると誰の責任か分からない」「関係者が多すぎて話が進まない」——こうしたあいまいさを、タスク×担当者の表に落として解消するのがRACIの狙いです。

この記事では、RACIの意味と4つの役割の違い、RACIチャートの作り方5ステップ、メリットと注意点、RASCIやDACIといった派生の型、そしてチームに定着させるコツまで、図解とテンプレートを交えてわかりやすく解説します。

【結論】RACIは責任分担を見える化したマトリクス

RACIは、タスクに関わる人の役割を「実行（R）・最終責任（A）・相談（C）・報告（I）」の4つに分け、タスクごとに誰がどれを担うかを一覧にした責任分担マトリクスです。

RACIは4つの役割の頭文字

RACI（レイシー）とは、R＝Responsible（実行責任者）、A＝Accountable（説明責任者・最終責任者）、C＝Consulted（相談先）、I＝Informed（報告先）の4つの役割の頭文字です。

この4つを、縦にタスク（やること）、横に担当者や部署を並べた表の各マスに割り当てていきます。

たとえば「要件定義」というタスクの行で、企画部にA・R、法務にC、経営層にI、というように記入します。

こうすると、どのタスクを誰が実行し、誰が最終責任を持ち、誰に相談し、誰に報告するのかが一目で分かります。

RACIが使われる場面

RACIは、システム開発やプロジェクトの立ち上げはもちろん、部署をまたぐ業務フローの整理、定例業務の役割分担、社内規程づくりなど、「複数の人が関わる仕事で責任を明確にしたい」場面全般で使われます。

特別なツールがなくても、表計算ソフト1枚あればすぐに作り始められる手軽さも、広く普及している理由です。

似た言葉に「役割分担表」がありますが、RACIの特徴は役割を4種類に定義し、記号で統一的に表す点にあります。

単に「担当：○○さん」と書くのではなく、その人が実行者なのか、最終責任者なのか、相談相手なのかまで区別するため、責任の重さと関わり方が正確に伝わります。

人数が増え、部署をまたぐほど、この「区別できること」の価値は大きくなります。

また、「誰が何をやるか」があいまいなままだと、手戻りや二重作業、宙に浮いたタスクが生まれやすくなります。

RACIは、そうしたムダを防ぐための身近で実践しやすい道具です。

RACIの4つの役割「R・A・C・I」をわかりやすく解説

R・A・C・Iはそれぞれ性質が異なります。
特に「実行(R)」と「最終責任(A)」の違い、「相談(C・双方向)」と「報告(I・一方向)」の違いを押さえると、迷わず割り当てられます。

R・Aは「タスクを完了させる当事者」、C・Iは「その周りで関わる関係者」と2層で捉えると、割り当てのときに迷いにくくなります。

たとえば「新機能のリリース承認」というタスクなら、承認して最終責任を負うプロダクト責任者がA、承認資料を用意する担当者がR、影響を確認する法務やQAがC、結果を知らせる営業やサポートがI、というように割り当てます。

同じ人物が複数タスクで違う役割を持つのも普通のことで、「このタスクでは自分はどの立場か」がその都度はっきりするのがRACIの利点です。

R（Responsible・実行責任者）とは？

Rは、そのタスクを実際に手を動かして進める「実行責任者」です。
1つのタスクに複数人置くことができます。

Responsible は「実行する人」を指します。

設計書を書く、コードを実装する、資料を作成するなど、成果物を生み出す作業そのものを担当します。

1つのタスクに対して複数のRを割り当ててもよく、少なくとも1人は必要です。

誰も手を動かさない（Rが空欄の）タスクは、そもそも前に進みません。

担当者が多い大きなタスクでは、Rを複数人にしつつ、後述のA（説明責任者）だけは必ず1人に絞ると、実行の手は増やしながら責任のあいまいさは避けられます。

誤解されやすい点：「Rが一番えらい担当」ではありません。
Rはあくまで実行役で、最終的な可否を判断するのはAです。

A（Accountable・説明責任者）とは？

Aは、そのタスクの結果に最終責任を負い、成果物を承認する「説明責任者」です。
1つのタスクにつき1人に絞るのが鉄則です。

Accountable は「最終的に説明責任を負う人」を指します。

作業を自分でやるとは限らず、Rに実行を任せて、その成果を確認・承認し、うまくいかなかったときに責任をとる立場です。

RACIで最も重要なルールが「1つのタスクにAは必ず1人」という点で、Aが複数いると責任が割れ、Aがいないと誰も最終判断をしない宙づり状態になります。

AとRは同一人物が兼ねてもかまいません（自分で実行し、自分が最終責任も負う小さなタスクなど）が、Aを2人以上にすることだけは避けましょう。

役職の上下ではなく、そのタスクの成否を引き受けられる人を1人選ぶのがポイントです。

C（Consulted・相談先）とは？

Cは、作業を進めるうえで意見や専門知識を求める「相談先（協業先）」です。
双方向のやりとりが前提になります。

Consulted は「相談を受け、意見を返す人」を指します。

法務・情報システム・品質保証など、そのタスクの専門家や利害関係者が該当し、作業前や作業中に意見を求めます。

ポイントは双方向であることで、こちらから相談し、相手からフィードバックが返ってくる関係。

Cは便利ですが、増やしすぎには注意。相談相手が多いほど確認や会議の回数が増え、意思決定が遅くなります。

「本当に意見を聞く必要がある人だけをCにする」という絞り込みが、RACIを適切に回すコツです。

迷ったら、その人がいなくても品質やリスク判断に支障がないかを基準に見直します。

I（Informed・報告先）とは？

Iは、進捗や結果を共有・報告される「報告先」です。
Cと違い、一方向で知らせるだけの関係です。

Informed は「結果や進捗を知らされる人」を指します。

関連部署や経営層など、意思決定には関わらないものの状況を把握しておく必要がある関係者が該当します。

C（相談先）が双方向なのに対し、Iは一方向で、こちらから報告するだけでフィードバックは必須ではありません。

IとCの線引きは、RACIを設計するときに迷いやすいところ。

判断のために意見が欲しいならC、結果だけ知っていればよいならIと切り分けます。

Iを適切に置くと「聞いていなかった」というトラブルが減り、逆にIが不在だと後工程での手戻りや社内の不信につながります。

報告の手段とタイミング（定例会議・チャット・メールなど）まで決めておくと形骸化を防げます。

RACIチャートの作り方【5ステップ・テンプレート付】

RACIチャートは、①タスクの洗い出し→②担当者を並べる→③Aを1人決める→④R・C・Iを割り当てる→⑤合意する、の5ステップで作れます。表計算ソフト1枚から始められます。

5ステップで作る手順

まずは完璧を目指さず、主要なタスクと担当者だけで骨組みを作りましょう。

次の手順で、上から順に埋めていきます。

1. タスク（やること）を洗い出す：プロジェクトや業務を、管理できる単位のタスクに分解して縦に並べる
2. 担当者・部署を並べる：関わる人や部署を横のヘッダーに並べる
3. Aを1人だけ決める：各タスクの行で、最終責任を持つAを必ず1人選ぶ（ここが最重要）
4. R・C・Iを割り当てる：実行するR、意見を求めるC、知らせるだけのIを、残りのマスに記入する
5. 関係者で合意する：完成した表を関係者で確認し、認識のズレをなくしてから運用を始める

ポイント：先に「A（最終責任者）」から埋めると全体が締まります。
Aが決まらないタスクは、そもそも誰が引き受けるべきか曖昧なサインなので、先に決着させます。

ステップ①のタスクの粒度は、1つの作業が数日〜2週間程度で終わる大きさを目安にすると管理しやすくなります。

細かすぎると表が膨れて更新が追いつかず、粗すぎると責任の割り当てが大ざっぱになってしまいます。

最初は主要な10〜20タスク程度に絞り、運用しながら必要な行を足していくのが現実的です。

RACIチャートの記入例とテンプレート

実際の記入イメージは次のとおり。

1つのマスにA・Rのように複数役割を入れても問題ありません（自分で実行し、最終責任も持つ場合など）。

まずはこの形をたたき台に、自社のタスクと担当者へ置き換えてみてください。

→ 表は横にスクロールできます

表を読むときは、まず行（タスク）ごとに縦に見て、Aが1つだけあるかを確認します。

次に列（担当者）ごとに横に見て、特定の人にAやRが集中しすぎていないかをチェックしましょう。

すぐに使えるように、上の表をエクセル／スプレッドシートで開けるテンプレートとして配布します。

ヘッダーの担当者名と、各行のタスクを自社の内容に書き換えれば、そのままRACIチャートとして使えます。

タスク／成果物,企画部,開発部,営業部,経営層
要件定義,A・R,C,C,I
設計・開発,I,A・R,I,I
受け入れテスト,R,R,A,I
リリース承認,C,C,R,A
社内・顧客への告知,R,I,A,I

↑をコピーして「raci-template.csv」として保存し、エクセル／スプレッドシートで開けばそのまま使えます（文字化けする場合は文字コードを UTF-8 で開く）。R=実行／A=最終責任（各行1人）／C=相談／I=報告。1マスに『A・R』のように複数役割を入れてもOK。

RACIを導入するメリット・デメリット

RACIの最大のメリットは責任の所在が明確になること。
一方で、Aを複数にする・Cを増やしすぎる・更新しないといった使い方をすると、かえって形骸化する点に注意が必要です。

RACIを使う3つのメリット

RACIを導入すると、役割分担の「なんとなく」が減り、チームの動きが軽くなります。

代表的なメリットは次の3つ。とりわけ効果が大きいのが、部署をまたぐ仕事での責任の明確化です。

部門の境目にあるタスクは「相手がやってくれるはず」と互いに思い込み、宙に浮きがち。

RACIで各タスクのAを1人に定めておけば、この“責任の狭間”に落ちる仕事がなくなります。

こうした効果は、業務の標準化やDXとも相性が良い点です。

IPA（情報処理推進機構）や経済産業省が推進する業務プロセスの見直し・標準化でも、「誰が責任を持つ工程か」を明確にすることは出発点になります。

RACIのデメリットと失敗パターン

一方で、RACIは作り方・運用を誤ると効果が出ません。次のような失敗が典型例。

これらはいずれも「厳密さを求めすぎる」ことから起きます。

主要なタスクから部分的に始めて、運用しながら改善していくのが失敗しないコツです。

たとえば、あるタスクの列を見て「Aが2つ付いている」「CばかりでRが無い」といった責任の偏りが見つかること自体が、RACIの価値です。

また、RACIが効果的なのは、複数の人・部署が関わり、誰の責任かが曖昧になりやすいタスクです。

「関係者が多くて話が進まない」「担当を決めたのに抜けが出る」と感じたときこそ、導入を検討する好機です。

派生フレームワークとの違い｜RASCI・DACIなど

RACIには、支援者を加えたRASCIや、意思決定に特化したDACIなどの派生型があります。
基本のRACIで足りないときに、目的に合わせて役割を足し引きした型と理解すればOKです。

主な派生フレームワーク一覧

代表的な派生型を、追加・変更される役割とともに整理すると次のとおりです。

まずは基本のRACIを押さえ、必要に応じて使い分けます。

いずれもRACIをベースに、現場で「この役割も区別したい」という必要から生まれた発展形です。

→ 表は横にスクロールできます

たとえばRASCIは、Rを支えるSupport（支援者）を明示できるため、実務の担当と補助の関係が入り組むタスクで役立ちます。

RACI-VSは、成果物を検証するVerifierと、正式に承認・署名するSignatoryを分けるので、品質チェックと最終承認を別の人が担う工程管理に向きます。

基本のRACIに「何の役割が足りないか」を当てはめると、どの派生型が要るか判断しやすくなります。

どのフレームワークを使えばいい？選び方の目安

多くの場合、まずは基本のRACIで十分です。

実行を手伝うメンバーが多いタスクなら支援者(S)を加えたRASCI、品質保証や正式承認の工程を分けて管理したいならRACI-VSがおすすめ。

「あえて関与しない人」をはっきりさせて期待値のズレを防ぎたいときはCAIRO、個別タスクの分担ではなく意思決定そのものの役割分担を整理したいときは、Driver（推進）・Approver（承認）で決め方を明確にするDACIが適しています。

いずれも「基本のRACIに何が足りないか」から逆算して考えると選びやすいです。

注意したいのは、役割を増やすほど表は複雑になり、運用の負担も上がること。

派生型は「基本のRACIでは明らかに区別が足りない」と感じたときに初めて検討すれば十分で、最初から欲張って多くの記号を使う必要はありません。

まずはRACIで小さく運用し、必要が見えてから拡張するのが、現場で定着させる近道です。

RACIをチームに定着させるための3つのステップ

RACIは作ることより「使い続けること」が難しい手法です。
小さく始め、日々のタスク管理と紐づけ、定期的に見直す——この3つで形骸化を防げます。

部分的に導入し、日々のタスク管理に紐づける

RACIチャートは、一度作って壁に貼っただけでは機能しません。

1つのプロジェクト・1つの案件から小さく始め、実際のタスクの進行とセットで運用することが大切です。

RACIで「誰が(A/R)」を決めたら、そのタスクを「いつまでに」やるのかまで落とし込み、進捗を全員が見られる状態にして初めて、責任分担が日々の行動につながります。

逆に、RACIチャートだけが立派でも、日々のタスクの状況が見えなければ、「決めた責任が守られているか」を誰も確認できず、表は少しずつ実態から離れていきます。

つまり大切なのは、役割だけでなく、タスクの進捗まで見える化すること。

RACIで役割を見える化したら、次はタスクそのものの進捗を見える化する——この二段構えが、責任分担を「絵に描いた餅」で終わらせないポイントです。

役割と進捗を一枚で回す仕組みにする

とはいえ、RACIチャートは表計算、タスクの進捗は別のファイル、報告はチャット……と道具がばらばらだと、更新が止まり形骸化します。

役割・タスク・期限・進捗を同じ場所で回せる仕組みにすると、RACIで決めた責任分担がそのまま日々の運用に乗ります。

デジタル庁や経済産業省が後押しする中小企業のDXでも、「担当と期限を決めて、進捗を全員で見える化する」ことは、規模を問わず効果の出やすい第一歩です。

定着のもう一つのコツは、RACIの見直しを定例のリズムに組み込むこと。

プロジェクトの節目や月次の振り返りのタイミングで、「この役割分担は今も実態に合っているか」を関係者で短く確認します。

人の異動やタスクの追加に合わせて表を更新し続けることで、RACIは古びた資料ではなく、常にチームの「今」を映す表になります。

RACIに関するよくある質問（FAQ）

RACIの読み方や、AとRの違い、Aは何人までかなど、実際に作るときに迷いやすい点をまとめました。

RACIの読み方は？

一般に「レイシー」と読みます。R・A・C・Iの4つの役割（Responsible・Accountable・Consulted・Informed）の頭文字をとった呼び方です。

RACIのAとRの違いは？

R（実行責任者）は実際に手を動かして作業する人、A（説明責任者）はその結果に最終責任を負い承認する人です。Rは複数人でもよいですが、Aは1タスクにつき1人に絞るのが鉄則です。同じ人がAとRを兼ねることもできます。

CとIの違いは？

C（相談先）は双方向で、意見や助言を求める関係です。I（報告先）は一方向で、結果や進捗を知らせるだけの関係です。判断のために意見が欲しいならC、知っておいてもらえれば十分ならIと切り分けます。

1つのタスクにAは何人まで？

Aは必ず1人だけにします。最終責任者が複数いると責任が割れ、「相手がやっているはず」という空白が生まれるためです。実行役のRは複数人置いても構いません。

RACIチャートは何で作ればいい？

エクセルやスプレッドシートなど表計算ソフト1枚から作れます。縦にタスク、横に担当者を並べ、各マスにR・A・C・Iを記入します。運用が続くかが成否を分けるため、タスクの進捗まで一緒に見える化できるツールと組み合わせると形骸化しにくくなります。

RACIとRASCI・DACIは何が違う？

RASCIはRACIに支援者(S)を加えた型、DACIはDriver・Approver・Contributor・Informedで意思決定の役割分担に使う型です。まずは基本のRACIを押さえ、足りない役割があるときに派生型を検討します。

まとめ：RACIで責任を見える化し、運用をスムーズにする

RACIとは、タスクごとに実行（R）・最終責任（A）・相談（C）・報告（I）の4役割を割り当て、責任の所在を見える化する責任分担マトリクスです。

Aは1タスク1人、Rは最低1人という2つの鉄則を守り、主要なタスクから小さく運用するのが成功のコツです。

C（相談・双方向）とI（報告・一方向）を切り分ければ、無駄な会議や報告漏れも減らせます。

作って終わりにせず、日々のタスク管理と紐づけて「役割・期限・進捗」を合わせて管理することで、RACIは絵に描いた餅ではなく、チームを実際に動かす仕組みになります。

RACIは難しい理論ではなく、「誰が何に責任を持つか」を丁寧に言葉にするための共通言語です。

まずは今動いている1つのプロジェクトを、タスク×担当者の表に書き出すところから始めてみてください。

責任のあいまいさが減るだけで、会議の噛み合わなさや手戻りが目に見えて少なくなるはずです。

小さく始めて運用しながら育てていけば、RACIはチームの共通言語として自然に根づいていきます。

参考文献・出典

• 小松裕介『1+1が10になる組織のつくりかた ── チームのタスク管理による生産性向上』実業之日本社、2025年、ISBN 978-4-408-65143-9
• PMI（米国プロジェクトマネジメント協会）
• 公益財団法人 日本生産性本部
• 中小企業庁
• IPA（情報処理推進機構）
• 経済産業省
• デジタル庁