METHOD
CRM は機能より先に「AI が読める形」を決める。次のアクションは人が持つ【業務フロー・指示文付き】
変わるのは「CRM の機能」ではなく「記録が1か所に集まり、AI が読める形になること」です。
会社OSは、ドライブの整備と CRM の両方を指します。コンサルファームでは、ドライブの整備を先方の AI 推進オーナーが、CRM を支援側が担い、どちらも「AI が読めること」を基準に作り直しました。5つに分かれていた DB を1つにまとめ、商談の議事録を AI が読み取れる形に変えて、本番に切り替えています。
- CRM を「機能で選ぶ」から「AI が読める形を先に決める」に変える設計
- 要件定義・収集と整形・統合と移行の順に進め、人の判断を3回に固定する考え方
- 業務フローと AI への指示文（設計用プロンプト）で、自社の CRM を同じ形で作り直す手順
下の「AI への指示文」を Claude に貼ると、業務フローを踏まえて、自社向けの設計を質問しながら組み立てられます。
業務フローと AI への指示文
この記事の業務フロー（To-Be）と、自社向けに設計を組み立てる AI への指示文を無料でお渡しします。右の3つを入れると、ダウンロードのボタンが出ます。
- 業務フロー（To-Be）工程ごとの人／AI／データの担当と、人が判断する場所
- AI への指示文（設計用プロンプト）業務フロー入り。Claude に貼ると、自社向けの設計を質問しながら組み立てます
01結論：何が変わるのか
変わるのは「CRM の機能」ではなく「記録が1か所に集まり、AI が読める形になること」だ。As-Is では、用途ごとに DB が増え、商談は古い方に書かれ続け、議事録は別の場所に残る。AI に読ませようにも、どこに何があるかが人の頭の中にしかない。To-Be では、まず AI が読みやすいフォルダ構造と各ルールを決め、すでに使っているツールに寄せる。要件は壁打ちを重ねて詰め、担当者しか知らない情報はやり取りで補い、5つの DB を1つに統合して移行する。本番に切り替えたあとは、議事録が商談・案件に紐づき、AI が読める形で溜まっていく。次にいつ何をやるかは、人が責任を持って決める。ここが AI を機能させるための、人の判断として残る部分だ。
一番時間がかかったのは、データの要件定義と、収集とクレンジングと、移行の3つです。要件は何回か壁打ちしてだいぶ良くなりました。もともとデータがきれいになっていなかったので、担当者しか知り得ない情報はやり取りしながら埋めていきます。データ量が多いと、AI とはいえ移行にかなり時間がかかるので、そこは最初から見込んでおいてください。
03AI 化の進め方、6つのフェーズ
大手と中小で中身は違っても、進め方の順番はどの会社でも同じです。フェーズごとに「目指す状態」と「実行内容」を置き、塗りがこの事例の位置。
04全社の業務フローのどこを AI 化したか
全社の仕事は6つのカテゴリーに分けられます。この業務が扱うのは、「組織・情報基盤」の4つのステップのうち X-22〜X-23（置き場・命名ルール設計〜CRM・マスタ設計） です。
05効率化の段階
この業務は L0（手作業）から L2（半自動） へ。要件のたたき・整形・統合・移行・紐づけが AI に移り、人は方針・移行の承認・次のアクションの3回の判断に集まりました。
06Before（As-Is）：用途ごとに DB が増え、記録は散らばり、次に何をやるかは頭の中
スキルを使わない場合の一般的な CRM の作り方を同じ8工程に並べました。機能と画面から入るため、AI が読める形になりません。
07After（To-Be）：AI が読める形を先に決め、統合と移行を AI が担う。次のアクションは人
同じ8工程のまま、要件のたたき・整形・統合・移行・紐づけを AI に移しました。人に残るのは方針、移行の承認、次のアクションの3つです。
会社OS・CRMを AI 化する手順
- 方針決定：AI が読める形を基準に：すでに使っているツールに寄せる
- 要件定義：要件のたたきを出す：定義・ステージ・関係を文書に
- 収集・整形：集めて正しい形に：表記ゆれ・欠けを直す
- DB統合：5つの DB を1つに：企業・商談・案件・議事録・タスクを関係で結ぶ
- データ移行：移行して件数を照合：前後で件数が同じことを確認
- 本番切替：使い方ページを作る：地図・書く場所・よく使う操作
- 議事録の紐づけ：議事録を紐づける：商談・企業・案件へ。残りはビューに出す
- 次のアクション：材料を出し、登録する：議事録から次の候補。決まったら登録
08工程ごとの担当の変化
8工程の形は変えず、整形・統合・移行・紐づけを AI に移しました。人に残るのは 方針・移行の承認・次のアクション の3回です。次のアクションは、AI を機能させるために人が責任を持つ部分として残しています。
機能で選ぶ。ツールごとに記録先が増える
AI が読める形（フォルダ構造とルール）を基準に、すでに使っているツールに寄せる。ドライブの整備は先方の推進役、CRM は Zeyra
画面と項目から決める。商談とは何かの定義が曖昧
AI が定義・ステージ・関係を文書にし、人が壁打ちを重ねて詰める。先方は業務の実態を出す
手で転記する。表記ゆれと欠けが残る
AI が元データを集めて正しい形に直す。担当者しか知らない情報は確認シートで聞き、回答を反映する
行われない。用途ごとに DB が増える
5つの DB を1つの DB 群に統合し、企業・商談・案件・議事録・タスクを関係で結ぶ
手でコピーする。件数の照合がない
AI が移行し、前後で件数が同じことを照合する。旧 DB は消さず「旧」を付けて残す
周知するだけ。入口が複数あり、旧 DB に書かれ続ける
入口を新 CRM の1つにし、AI が使い方ページ（地図・書く場所・よく使う操作）を作る
行われない。議事録は別の場所に残る
AI が議事録を商談・企業・案件に紐づける。紐づかないものだけをビューに出し、人が見る
担当者の頭の中。誰がいつ何をやるかが残らない
AI が議事録から次の候補を出す。次にいつ何をやるかは、人が責任を持って決めてタスクに登録する
09設計のポイント
人の判断は3回に固定する
- 判断1 方針: 機能ではなく「AI が読める形」を基準にし、すでに使っているツールに寄せる。相性の悪いツールに無理に載せない
- 判断2 移行の承認: AI が差分を見せ、人が許可してから動かす。旧 DB は消さず「旧」を付けて残し、戻せる形にする
- 判断3 次のアクション: 次にいつ何をやるかは人が決める。AI は議事録から候補を出すだけ
AI の外に残るもの
- 担当者しか知らない情報。確認シートで聞き、回答を反映する。AI は元データに無いものを作れない
- ドライブの整備。先方の AI 推進オーナーが担い、CRM と合わせて会社OSになる
- 旧 DB の削除。消すと動いているものが止まるので、人が後日まとめて判断する
役割の移動
- 先方の担当者: 複数の DB に手で書く人 → 1つの入口に書き、紐づかない議事録だけを見る人
- AI: チャットに貼る道具 → 要件のたたき・整形・統合・移行・紐づけを自分で行う担当
- CRM: 入力を待つ箱 → 議事録・商談・企業・案件が関係で結ばれ、AI が読める記録
次の分岐
- 商談が旧 DB で作られ続けるなら、旧 DB を「見るだけ」にして入口を1つに戻す
- 議事録の未紐づけが溜まるなら、紐づけの条件（種別・企業・案件）を見直す（候補）
- 次の段階（候補）は、先方の推進役が項目とステージを自分で直し、支援側はレビューだけになる状態
11まとめ
- CRM は機能より先に「AI が読める形」を決め、すでに使っているツールに寄せる
- 要件は壁打ちで詰め、担当者しか知らない情報は確認シートで補い、統合と移行は AI が件数を照合しながら行う
- 次にいつ何をやるかは人が決める。AI は議事録から候補を出すだけ
この記事を書いた人
採用・組織人事のコンサルで200社以上、AI系ブティックファームで事業責任者。いまは AI 前提の組織設計を、自社で回しながらクライアントに提供している。
AI への指示文で設計を組み立てたところまでで構いません。30分の無料相談で、どの工程から AI に任せるかと、人が残す判断を一緒に決めます。
無料相談（30分）を申し込む