AIで施策の優先順位を整理する方法|RICEの根拠と前提変更を確認

架空4案をRICEで比較し、同値、情報不足、工数変更による比較値の変化を検算。成功確率や実施順と分けます。

AIものさし編集部

AIで改善施策の優先順位を整理するときは、比較値を計算する前に、何人へ届くか、どんな効果を期待するか、見積もりをどの程度信じられるか、どれだけ作業が必要かを分けます。AIがもっともらしい数値で空欄を埋めても、判断材料が増えたことにはなりません。

この記事では、架空の申請サービスの改善案をRICEで整理します。成果物は、前提付きの比較表、未計算の案、条件を変えた再計算、次の確認事項です。実際の利用者数、効果、工数、AIによる評価、施策の実施結果は検証していません。

RICEは、比較の前提を表にする方法として使う

Intercomが公開したRICEは、Reach・Impact・Confidence・Effortの4要素で案を比べる枠組みです。Reachは同じ期間での到達人数や件数、Impactは1人あたりの影響の見積もり、Confidenceは見積もりの裏付け、Effortは関係者全体の作業量です。比較値はReach × Impact × Confidence ÷ Effortで計算します。Intercom:RICE(新しいタブで開く)

今回、Reachは同じ四半期の対象人数、Effortは人月でそろえます。月間の人数と四半期の人数、1人の作業量とチーム全体の作業量を混ぜません。Impactは実測した改善率ではなく、案を比較するための相対的な見積もりとします。

原案ではConfidenceの例に100%・80%・50%、Impactの例に3・2・1・0.5・0.25を使っています。以下はその一部を使った独自の架空例であり、すべての組織へ同じ評価を求めるものではありません。評価の意味と根拠を担当者でそろえてから使います。

数値と、根拠の状態を別に記録する

今回の目的は、申請を完了する際の体験を改善することです。対象の四半期、対象者、重複を数える単位は全案で同じと仮定します。次の数値は説明用の仮置きで、実ログや調査から得たものではありません。

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

案ID改善案Reach:人/四半期ImpactConfidenceEffort:人月
P01完了案内の見直し1,000180%2
P02入力補助600250%1
P03用語ヘルプ4001100%1
P04検索改善未確認250%2

実務では、Reachに対象操作のログや集計条件、Impactに調査や試行の材料、Effortに作業範囲と見積もりの担当を付けます。ConfidenceもAIの文体の強さで決めず、何が確認でき、何が推測かを説明します。今回の100%は架空の入力値で、実際の裏付けが十分だと確認した結果ではありません。

人月は作業量であり、カレンダー上の完了月数ではありません。2人が各1か月分取り組むなら合計2人月ですが、並行できるか、待ち時間があるかで経過期間は変わります。担当者の実稼働や依存関係は別に確認します。

計算できる案と、情報不足の案を分ける

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

案ID計算式比較値状態
P011,000 × 1 × 0.8 ÷ 2400架空値による試算
P02600 × 2 × 0.5 ÷ 1600架空値による試算
P03400 × 1 × 1 ÷ 1400架空値による試算
P04Reachが未確認未計算情報不足

80%は計算上0.8、50%は0.5として扱います。80をそのまま掛けると100倍になります。また、Confidenceが80%だから実施の成功確率が80%、比較値400だから400人の改善が確実、といった読み方はしません。

今回の入力ならP02の比較値が大きく、P01とP03は同じ400です。同値の案は同値として残し、後から見やすい順に並べただけで差が付いたようにしません。

P04は0ではありません。Reachが0人と確認できた案と、まだ分からない案は別です。未確認値をAIが推測して順位へ入れるより、何を集計すれば比較できるかを確認事項へ回します。

比較値やReachを施策間で合計して、改善する顧客の総人数にしないでください。同じ人が複数案の対象に入る可能性があり、比較値も実際の効果人数ではありません。

工数の前提が変わると、比較も変わる

P02の工数を、別シナリオとして1人月から2人月へ変えると、600 × 2 × 0.5 ÷ 2=300です。他の条件を据え置けば、P01・P03の400より小さくなります。

これは実際に工数が増えた記録ではありません。「必要な作業が2人月だった場合」という仮定の再計算です。元の600という比較値を消さず、どの前提を変えたかを併記します。

最初の順序が確定的に見えても、見積もり1項目で変わるなら、P02の作業範囲を先に確かめる価値があります。比較値の細かい桁を増やすより、判断を変える前提へ調査を向けます。ただし、この2シナリオだけで全不確実性を評価したとは言えません。

掲載例の比較値と同値を検算する

次のPythonは、固定した架空入力の計算です。分数を使い、80%を4/5、50%を1/2として途中で丸めません。

from fractions import Fraction as F

rows = {
    "P01": (1000, F(1), F(4, 5), F(2)),
    "P02": (600, F(2), F(1, 2), F(1)),
    "P03": (400, F(1), F(1), F(1)),
    "P04": (None, F(2), F(1, 2), F(2)),
}
values = {}
for key, (reach, impact, confidence, effort) in rows.items():
    if reach is None:
        values[key] = None
        continue
    assert effort > 0
    assert 0 <= confidence <= 1
    values[key] = reach * impact * confidence / effort
assert values == {"P01": 400, "P02": 600, "P03": 400, "P04": None}
assert values["P01"] == values["P03"]
scenario_p02 = 600 * F(2) * F(1, 2) / F(2)
assert scenario_p02 == 300
assert scenario_p02 < values["P01"] == values["P03"]
print(values, scenario_p02)

このコードは、ID重複や期間・単位の違い、全欄の欠損、入力型などを調べる汎用検査ではありません。Effortが0なら割れず、未確認なら値を出せないため、実運用では入力条件を先に確認します。計算が通ることと、根拠が妥当であることも別です。

比較値から、実施順を自動確定しない

Intercomも、RICEの値を厳格な実施ルールにしないことを説明しています。他の施策の前提になる作業など、値の大小以外で先に行う理由があります。Intercom:RICEの使い方(新しいタブで開く)

今回も、依存関係、実行できる担当者、期限、必須対応を確認した表ではありません。P02が600だから最初に着手できるとは限りません。値とは別に、先に終える必要のある作業や、決定者が考慮する制約を記録します。

意思決定メモには「入力条件ではP02が600。工数2人月の仮定では300へ変わる。P01・P03は400で同値。P04はReach未確認のため比較外。P02の作業範囲とP04の対象人数を確認してから、依存関係と合わせて実施順を検討する」と残せます。

AIへ依頼するのは、根拠付きの比較と確認質問

架空の施策P01~P04を、入力したRICEの条件で整理してください。
Reachの期間と対象、Impactの意味、Confidenceの根拠、Effortの単位を別欄にしてください。
比較値はReach×Impact×Confidence÷Effort。百分率は小数へ直してください。
未確認値を生成せず、P04は未計算として不足情報を示してください。
同値を同値として残し、比較値を改善人数や成功確率へ読み替えないでください。
P02の工数だけを2人月にした別シナリオも示し、元の試算と区別してください。
出力:入力と根拠状態、計算表、前提変更で変わること、未確認、次の質問。
実施順の確定や、施策の実行は行わないでください。

この依頼と比較表は手製例で、AIの評価精度を測った結果ではありません。計算後は、前提の状態が消えていないか、未計算の案を低評価へ変えていないか、工数の変化を実績として書いていないかを確認します。数値の説明と判断に残る条件がそろってから、チームの意思決定へ渡してください。

参考資料

公式資料の確認日:2026年10月20日。施策、人数、効果、確信度、工数、比較値、意思決定メモは独自の架空例です。掲載Pythonと計算をローカルで検査しました。実ログ、顧客調査、工数見積もり、AI評価、実施順の合意、施策効果、画面表示は未検証です。

質問から自分に合うAIを探す