CRISP-DMは生成AIの案件に使える？｜6工程の読み替え方

「外注先の提案書の工程表がCRISP-DMで書かれているが、生成AIの案件もこの進め方でよいのか」「工程の名前は並んでいるのに、どこで次に進むかを誰が決めるのかが書かれていない」。AI案件を発注する側や、社内で推進を担う側から聞こえてくる声です。工程の名前が共通語になっている一方で、その中身が案件の種類に合っているかは確かめられないまま進みがちです。CRISP-DMは、そのままでは生成AIの案件に使えない古い手法ではありません。本当は、工程ごとの成果物と出口の判定を読み替えれば、生成AIの案件にも骨組みとして使える手法です。この記事では、原典に書かれた6工程の中身と、生成AIを業務に組み込む案件でそれぞれがどう入れ替わるか、出口で進む・戻す・止めるを決める会議の項目を整理します。

CRISP-DMとは：2000年に1.0が公開された、分析案件の6工程

CRISP-DMは、データ分析（当時の言い方ではデータマイニング）の案件を進めるための標準工程です。名前は「業界を問わない、データマイニングの標準工程」を意味する英語の頭文字から来ています。原典の前書きによれば、1996年の終わりに構想され、翌年に複数の企業がコンソーシアムを作り、欧州委員会の資金を得て開発が進みました。1999年半ばに草案ができ、2000年8月に手順書の1.0版がまとめられています。

原典の表記では、コンソーシアムの構成は、米国のデータウェアハウスの会社、ドイツの自動車大手のダイムラークライスラー、統計解析ソフトの会社、オランダの保険・銀行グループの4者です。特定の業界・道具・用途に依らないことを狙って作られ、現在も統計解析ソフトの提供元のサイトで手順書が配布されています。製品ではなく手法なので、提供の終了という考え方はありません。

工程	原典での主な作業	原典での主な成果物
1 ビジネス理解	業務の目的を決める／状況を評価する／分析の目標を決める／案件の計画を作る	業務上の成功の基準、資源・制約・リスクの一覧、分析上の成功の基準、案件の計画
2 データ理解	初めのデータを集める／記述する／探索する／品質を確かめる	収集・記述・探索・品質の各報告
3 データ準備	選ぶ／整える／作る／統合する／形式をそろえる	分析に使うデータの一式とその説明
4 モデリング	手法を選ぶ／試験を設計する／モデルを作る／モデルを評価する	試験の設計、モデルとその説明、評価
5 評価	結果を業務の基準で評価する／工程を見直す／次の手を決める	承認されたモデル、工程の見直し、取りうる手の一覧と決定
6 展開	展開を計画する／監視と保守を計画する／最終報告を作る／案件を振り返る	展開計画、監視と保守の計画、最終報告、経験の記録

• 工程と作業・成果物の名前は、原典（手順書1.0版、2000年）の英語を本稿で日本語にしたものです
• 以下で述べる生成AIの案件への読み替えは原典には無く、本稿の整理です

原典が最初から前提にしている「行き来」と、2種類の成功の基準

工程表に6つの箱が順に並んでいると、上から順に1回ずつ通る進め方だと読まれがちです。原典ははっきり逆のことを書いています。工程の順番は固定ではなく、工程の間を行き来することは常に必要であり、各工程の結果が、次にどの工程のどの作業をするかを決める、という書き方です。工程を囲む外側の円は、展開で終わらず、得た学びが次のより絞った問いを生む繰り返しを表しています。

もう1つ、工程表の読み手が見落としやすいのが、成功の基準が2種類あることです。原典は、業務の言葉で書く業務上の成功の基準（例として、案内の郵送への反応率を10パーセント上げる、が挙がっています）と、技術の言葉で書く分析上の成功の基準（予測の正確さなど）を分け、両者は別物だと注意しています。

さらに原典は、成功の基準が主観的な形でしか書けない場合には、誰がその主観的な判定をするのかを明記するようにと求めています。生成AIの案件では、出力の良し悪しが主観に寄りやすいため、この一文はそのまま効きます。判定する人の名前が工程表に無い提案書は、この点で原典からも外れています。

行き来の前提は、発注の形にも関わります。工程を1回ずつ通る前提で見積もった工程表では、戻るたびに追加の費用と期間の交渉が起きます。原典が言うとおり行き来が常に必要なら、戻りを何回まで見込むか、戻ったときに誰が決めるかを、契約の前に工程表へ書き込んでおくほうが、発注側にとっても受注側にとっても現実的です。

生成AIの案件では、何が入れ替わるのか

ここからは本稿の整理です。この記事でいう生成AIの案件は、社内の資料をもとに質問に答える仕組み、問い合わせや報告書の要約、文書の分類のように、既にある生成AIのモデルを業務に組み込む案件を指します。自社でモデルを学習させる案件ではありません。機械学習と生成AIのどちらを使うべきかという使い分けは、別の記事で整理しています。

骨組みは同じでも、入れ替わる点は大きく4つあります。データ準備は「学習用のデータを整える」から「AIに渡す資料と指示を整える」に、モデリングは「モデルを学習させる」から「指示・資料の探し方・出力の形式を組み合わせる」に、評価は「正解率を測る」から「正解が1つに決まらない出力を業務の基準で採点する」に、展開は「再学習の計画」から「提供元のモデルの更新に追従する計画」に変わります。

なお、AIを開発の主役に据えてソフトウエアを作る工程の考え方とは別物です。そちらはソフトウエアの開発の工程で、本稿が扱うのは、業務の課題から始めて分析やAIの仕組みを使い始めるまでの案件の工程です。工程表を読むときは、どちらの話をしているかを最初に確かめます。

工程1 ビジネス理解：成功の基準を2本立て、判定する人を書く

原典のビジネス理解の工程は、業務の目的を決め、資源・前提・制約・リスク・用語・費用と効果を評価し、分析の目標と分析上の成功の基準を決め、案件の計画を作る工程です。原典は、手の届かない目標を立てないように、また、展開を最初から計画しておくように、と注意しています。

生成AIの案件に読み替えると、2本の基準は次のように書けます。業務上の基準は「問い合わせの一次回答にかかる時間を、担当者の確認込みで半分にする」のような業務の言葉。出力の基準は「根拠の資料を示せない回答を出さない」「規程と食い違う回答が、確認した題材の中で一定の割合を超えない」のような出力の言葉です。業務の基準を満たさないのに出力の基準だけを満たした、という状態を成功と呼ばないことを、この工程で合意しておきます。

この工程の出口で確かめるのは、2本の基準が書かれ、判定する人が決まり、止める条件（例：一定の期間で業務の基準に届く見込みが立たなければやめる）まで書かれているかです。基準の案の下書きや、似た案件で使われた観点の洗い出しはAIに任せてかまいませんが、何がどれだけ良くなれば採用するかは、業務の責任者が決めます。

原典はこの工程で、問題を定義し直すことも勧めています。例として挙がっているのは、顧客の離反を防ぎたいときに、顧客単位の予測では結果が出るのが遅すぎて手を打てないため、製品単位の継続を予測し直す、という話です。生成AIの案件でも、「問い合わせに全部答えさせる」を「よくある質問の一次回答の下書きを作らせる」に絞り直すと、基準が書けるようになることがあります。

工程2 データ理解：渡す資料の棚卸しに変わる

原典のデータ理解は、初めのデータを集め、中身を記述し、探索し、品質を確かめる工程で、それぞれの報告が成果物です。機械学習の案件では、予測に使う項目がそろっているか、欠けや偏りがどれだけあるかを確かめます。

生成AIの案件では、この工程がAIに渡す資料の棚卸しに変わります。対象になるのは規程、手順書、過去の問い合わせと回答、製品資料などです。確かめるのは、最新版がどれか分かるか、同じ内容の資料が複数の版で残っていないか、担当部署が分かるか、社外秘や個人情報を含むか、の4点が中心になります。

この工程の出口は、資料の一覧と、それぞれの持ち主と、使ってよいかどうかの区分がそろったことです。資料の一覧の下書きや、版が重なっている資料の候補の洗い出しはAIに任せられます。ただし、どの資料をAIに渡してよいかは、資料の持ち主の部署が決めます。ここが決まらないまま次の工程に進むと、後の評価で「この資料は使ってはいけなかった」と分かり、工程を大きく戻すことになります。

工程3 データ準備：学習用の整形から、渡す資料と指示の準備へ

原典のデータ準備は、分析の道具に入れる最後のデータの一式を、生のデータから作るためのすべての作業です。選ぶ、整える、新しい項目を作る、統合する、形式をそろえる、が作業として並び、原典は、これらは何度も、決まった順番なしに行われることが多いと書いています。

生成AIの案件では、成果物が「分析に使うデータの一式」から、「AIに渡す資料の一式と、指示の初版」に変わります。古い版を外す、表や図を文字で読める形にする、資料の区切りを決める、といった作業が中心です。社内資料から答えさせる仕組みで資料がどこで壊れるかという中身は、別の記事で詳しく扱っているので、ここでは出口だけを決めます。

出口で確かめるのは、渡す資料の一式に、工程2で「使ってよい」とされたものだけが入っているか、版が1つに決まっているか、です。抜けの指摘（一覧にあるのに一式に入っていない資料、逆に一覧に無いのに入っている資料）はAIに任せやすい作業です。この確認を飛ばすと、評価の工程で答えの誤りが見つかっても、原因が資料にあるのか指示にあるのかを切り分けられません。

工程4 モデリング：作るのは、指示と資料の探し方と出力の形式の組み合わせ

原典のモデリングは、手法を選び、試験を設計し、モデルを作り、モデルを評価する工程です。同じ問題に使える手法はいくつもあり、手法によってデータの形の条件が違うため、データ準備の工程に戻ることがよくある、と原典は書いています。

生成AIの案件では、自社でモデルを作ることは少なく、作るのは組み合わせになります。どの提供元のモデルを使うか、指示をどう書くか、資料をどう探して渡すか、出力をどんな形式に固定するか、の組み合わせです。原典がモデルの設定値の記録を成果物にしているのと同じく、どの組み合わせで試したかを記録しておかないと、後で良かった版に戻れません。

この工程で原典と同じことが起きるのが、前の工程への戻りです。指示を変えても答えが良くならないとき、原因はたいてい渡した資料の側にあります。工程表に「モデリングからデータ準備へ戻る」矢印が書かれているかどうかは、提案書を読むときの確かめどころです。戻る道が無い工程表は、指示の書き直しだけを繰り返す進め方になりがちです。

工程4の要：作る前に「試験の設計」を固める

原典のモデリングの作業の中で、生成AIの案件にとって最も大事なのが試験の設計です。原典は、モデルを作る前に、その良し悪しをどう確かめるかの手順を作ることを、独立した作業として置いています。

生成AIの案件に読み替えると、作る前に、採点に使う題材（実際にありそうな質問や文書）と、題材ごとの合格の目安と、採点する人を決めておくことになります。題材は、よくある質問だけでなく、規程の境目にある質問、資料に答えが無い質問を必ず混ぜます。答えが資料に無いときに「分からない」と返せるかは、業務に入れたときの事故を左右するからです。

題材の候補を集める作業や、過去の問い合わせから似た質問を束ねる作業は、AIに任せられます。けれども、どの題材を採点に使うか、何点なら合格かは人が決めます。採点の仕方そのもの（人が読むか、AIに採点させて人が抜き取るか）は、AIの出力の評価を扱った別の記事に譲り、ここでは「作る前に決まっているか」だけを出口にします。

工程5 評価：業務の基準に照らし、工程そのものを見直す

原典の評価の工程は、分析の結果を業務上の成功の基準に照らして評価し、基準を満たしたモデルを「承認されたモデル」とする作業から始まります。原典は、この段階のモデルは分析の観点では質が高く見えるが、展開の前に、業務の目的を本当に満たすかを確かめる必要があると書いています。工程4の評価が分析上の基準なら、工程5の評価は業務上の基準です。

続く作業が工程の見直しです。原典は、見落とした要素や作業が無かったかを確かめる作業として、使ってよい項目、将来の分析でも使える項目だけを使ったかという問いを例に挙げています。生成AIの案件では、これが「渡してよいとされた資料だけを使ったか」「試した版と本番で使う版の資料が同じか」の確認になります。

生成AIの案件では、工程4の採点で合格した組み合わせでも、業務の基準では足りないことがよくあります。答えは正しいのに、担当者が確認に時間をかけるため回答の時間が縮まらない、といった場合です。出力が合格でも、業務の時間が変わらなければ承認しないという線を、この工程で守ります。

原典は、この工程の大事な狙いを、まだ十分に考えていない業務上の問題が残っていないかを見つけることだとしています。生成AIの案件でいえば、誤った回答が出たときに誰が顧客へ訂正するか、回答の記録をどれだけ残すか、といった、出力の採点では見えない問題です。ここで見つかれば工程1に戻して基準を足し、見つからないふりをして展開に進まないことが肝心です。

工程5の最後：「次の手」を選択肢と理由で残す

評価の工程の最後に、原典は「次の手を決める」という作業を置いています。評価と見直しの結果から、案件を終えて展開に進むか、もう一巡繰り返すか、新しい分析の案件を立てるかを決める作業で、残りの資源と予算も判断に影響すると書かれています。

成果物は2つです。取りうる手の一覧（それぞれに賛成と反対の理由を付ける）と、決定（どう進めるかと、その理由）です。工程表の多くは「評価」の箱の次にすぐ「展開」の箱を置きますが、原典はその間に、選択肢を並べて理由付きで決める作業を挟んでいます。

生成AIの案件では、この一覧に「止める」をはっきり入れておくことが大切です。業務の基準に届く見込みが立たない、渡せる資料が足りない、といった場合です。止める理由が記録に残っていれば、同じ題材の案件が後で立ち上がったときに、同じところでつまずかずに済みます。一覧の下書きと理由の整理はAIに任せてもよいですが、決定の欄を書くのは案件の責任者です。

工程6 展開：版の追従と、監視の計画を先に書く

原典の展開は、モデルを作れば終わりではなく、得た知見を発注側が使える形に整える工程です。展開の計画、監視と保守の計画、最終報告、案件の振り返りが作業として並びます。原典は、多くの場合、展開を実行するのは分析者ではなく発注側であり、だからこそ発注側が使い始めるために何をすべきかを最初に理解しておくことが大事だと書いています。

監視と保守の計画について、原典は、分析の結果が日々の業務の一部になるなら、誤った使われ方が長く続くのを避けるために、保守の方針を注意深く準備すると書いています。生成AIの案件では、これが提供元のモデルの更新への追従と、渡している資料の更新への追従になります。提供元のモデルが変わると、同じ指示でも出力が変わるからです。

この工程の出口は、誰が監視し、何が起きたら工程4や工程5に戻すかが計画に書かれていることです。実証実験から本番への移行の判定や、作った後の運用の仕組みそのものは別の記事で整理しているので、ここでは「戻す条件が計画にあるか」だけを確かめます。

最終報告について、原典は、それまでのすべての成果物をまとめた書面と、案件の終わりに発注側へ結果を示す場がよく設けられることを書いています。生成AIの案件では、この場で、業務の基準に対してどこまで届いたか、使い始めてから何を見続けるか、どうなったら止めるかを、使う部署の責任者に直接示します。報告の書面だけを渡して終えると、監視の担当が宙に浮きます。

展開の後：振り返りの記録が、次の案件の工程1になる

原典の最後の作業は案件の振り返りで、成果物は経験の記録です。うまくいったこと、いかなかったこと、改善すべきことを評価し、落とし穴や誤った進め方、似た場面で手法を選ぶ手がかりを残す、と書かれています。外側の円が示す繰り返しは、この記録が次の問いを生むことで回ります。

生成AIの案件では、振り返りに残す価値が高いのは、採点に使った題材と合格の目安、止めた理由、戻った回数と理由です。これらは次の案件の工程1で、成功の基準を現実的な水準に置くための材料になります。原典が手の届かない目標を立てないようにと注意しているのは、まさにこの材料が無い状態を指しています。

記録の下書き（会議の記録から決定と理由を抜き出す、戻った箇所を時系列に並べる）はAIに任せやすい作業です。何を教訓として残すかは、案件に関わった人が読んで決めます。記録が個人の手元に散らばらないよう、置き場所を工程1の計画の段階で決めておきます。

工程ごとの出口の判定表

ここまでの読み替えを、出口で何を確かめ、どうなったら進む・戻す・止めるのかの表にまとめます。表の中身は本稿の整理で、原典の文言ではありません。自社の工程表や外注先の提案書と見比べる物差しとして使ってください。

工程	出口で確かめること（生成AIの案件）	進む	戻す・止める
1 ビジネス理解	業務の基準と出力の基準、判定する人、止める条件	3つが書かれ、責任者が合意した	基準が業務の言葉で書けない→止めるか目的から見直す
2 データ理解	資料の一覧、持ち主、使ってよいかの区分	使ってよい資料で目的に足りる	足りない→工程1の目的を絞る
3 データ準備	渡す資料の一式が一覧と一致し、版が1つ	抜けと重なりが無い	使えない資料が混ざる→工程2へ
4 モデリング	試験の設計が作る前に決まり、試した組み合わせが記録されている	採点の題材で合格の目安に届いた	資料に原因→工程3へ。届かない→工程5で止めるかを判断
5 評価	業務の基準での評価、工程の見直し、取りうる手の一覧と決定	業務の基準に届き、決定に理由がある	出力は合格でも業務が変わらない→工程4か工程1へ
6 展開	展開の担い手、監視の担当、戻す条件、振り返りの置き場所	発注側が使い始められる	戻す条件が無い→計画を作り直す

表を見比べると、多くの工程表で欠けやすいのは、工程1の「止める条件」、工程4の「作る前の試験の設計」、工程5の「取りうる手の一覧と決定」の3か所です。この3か所が工程表に無ければ、名前だけ原典をなぞった工程表だと考えて、発注前に書き足しを求めます。

進む・戻す・止めるを決める会議の進め方

出口の判定は、工程ごとの会議で行います。会議の項目は、どの工程でもほぼ同じ形にできます。次の順で進めると、判定の理由が記録に残ります。

会議の資料づくりのうち、成果物の要約、抜けの指摘、取りうる手の下書きはAIに任せられます。会議の時間の大半を、資料を読むことではなく判定に使えるようになります。

会議に出る顔ぶれも、工程によって変えます。工程1と工程5には業務の責任者が必ず出ます。工程2と工程3には資料の持ち主の部署が出ます。工程4は作る側が中心でよいものの、採点の題材を決める場には使う部署の担当者を入れます。外注している場合は、受注側に判定を預けず、発注側の判定する人が会議を締めます。

AIに任せる下ごしらえと、人が持つ判定

この進め方の中でAIに任せやすいのは、各工程の成果物の下書き、評価の観点の洗い出し、資料の一覧と一式の突き合わせによるデータ準備の抜けの指摘、会議の記録からの決定と理由の抜き出しです。どれも、どこを根拠にしたかを一緒に書かせれば、人が短い時間で確かめられます。

反対に、AIに任せてはいけないのは、工程1で決める成功の基準と、各工程の出口で進む・戻す・止めるを決める判定です。AIは成果物の抜けを指摘できても、その抜けを受け入れて進むか、戻って埋めるかを、予算や業務の事情と比べて決める立場にはありません。原典が主観の判定には判定する人を明記するよう求めているのも、判定の責任を人に置くためです。

人が確かめる範囲も、工程1の段階で決めておきます。たとえば、採点の題材のうち規程の境目にある質問は必ず人が採点する、資料の使用可否は持ち主の部署が確かめる、といった決め方です。決めておかないと、AIの下書きがそのまま判定の材料として流れ、誰も確かめていない判定が生まれます。

読み替えでつまずく進め方

CRISP-DMを生成AIの案件に当てるときのつまずきは、原典の骨組みを捨てることよりも、名前だけを借りて中身を読み替えないことから起きます。

• 成功の基準を出力の言葉だけで書く：正答の割合は上がったのに、業務の時間が変わらないまま「成功」と報告される
• データ準備を「学習データの整備」のまま見積もる：渡す資料の版の整理と使用可否の確認が工程表から抜ける
• 試験の設計を作った後に決める：手元で良く見えた組み合わせに合わせて題材を選び、評価が甘くなる
• 評価の次にすぐ展開を置く：止める選択肢が検討されず、届かない案件が本番に持ち込まれる
• 展開の計画に提供元のモデルの更新を入れない：ある日から出力が変わっても、誰も気づかず使われ続ける

どれも、工程の名前は原典どおりでも、出口で確かめる中身が機械学習の案件のまま残っていることが原因です。工程表を受け取ったら、判定表の行と1つずつ突き合わせて、生成AIの案件の中身に読み替わっているかを確かめてください。

まとめ

CRISP-DMは、2000年に1.0がまとめられた分析案件の標準工程で、ビジネス理解・データ理解・データ準備・モデリング・評価・展開の6工程からなり、原典は工程の行き来と繰り返しを前提にしています。生成AIを業務に組み込む案件でも骨組みは使えますが、データ準備は渡す資料と指示の準備に、モデリングは組み合わせづくりに、評価は正解が1つでない出力を業務の基準で採点することに、展開は提供元のモデルの更新への追従に読み替える必要があります。この読み替えは本稿の整理です。工程表を見るときは、止める条件、作る前の試験の設計、取りうる手の一覧と決定の3か所があるかを確かめてください。成果物の下書きや抜けの指摘はAIに任せて根拠を書かせ、成功の基準と、各工程の出口で進む・戻す・止めるの判定は人が決めます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。