AI導入の最初の90日｜何から始めるかをわかりやすく解説

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO CREATREE合同会社の代表社員。生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。

著者

藤村 隼人

CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。

AI導入はツール比較ではなく、課題の定義、責任者の決定、候補業務の選定、データとリスクの確認、小規模なPoC、効果測定、継続・中止・展開判断の順で始めます。本記事では最初の90日を3段階に分け、対象業務の比較軸、PoCの終了条件、経営報告と全社展開の判断材料を整理します。

AI導入で最初に決めるのは「ツール」ではなく「課題と判断条件」

AI導入の出発点は、解決する経営・業務課題と、導入後に継続するか中止するかを決める条件です。この2点が曖昧なまま製品比較を始めると、PoCの実施自体が目的になり、結果が出ても次の意思決定につながりません。

最初に「どのAIを使うか」ではなく、「どの業務の、どの状態を、どこまで改善したいか」を一文で定義します。例えば「生成AIを活用する」ではなく、「営業担当者が提案書の初稿作成に使う時間を減らし、顧客対応へ振り向ける」のように、対象者、対象業務、改善したい状態が分かる表現にします。

目的文には、現状を示す基準値も添えます。作業時間、処理件数、手戻り件数、エラー率、問い合わせ件数など、PoC後と比較できる値が必要です。厳密な測定が難しい場合でも、対象者と計測期間を限定して現状を記録しておかなければ、導入効果を説明できません。

1. 経営課題を業務課題へ分解する：売上、利益、人材不足、品質、顧客対応などの経営課題から、改善対象となる業務を特定します。
2. AIで扱える作業単位まで狭める：業務全体ではなく、情報の検索、文章の下書き、分類、要約、予測など、検証可能な単位へ分けます。
3. 目的文を作成する：対象者、対象業務、改善したい状態を一文にまとめ、経営層と業務部門の双方に確認します。
4. 判断条件を決める：判断時期、判断者、使用する評価項目、継続できない条件を開始前に定めます。

競合対応や取引先の要請によって期限が先に決まっている場合も、目的設定を省略してはいけません。期限を延ばせないなら、対象業務を一つに限定し、短期間で判断できる範囲へ縮小します。

以下の90日ロードマップ、比較軸、判定方法は、公的なAIガイドラインのガバナンスやリスク管理の考え方を踏まえ、CREATREE編集部が企業の初期導入向けに実務整理したものです。公的機関が一律に90日間の進め方を推奨しているという意味ではありません。

期間	主な目的	決めること	次へ進む条件
1〜30日	方針と体制の確定	目的、責任者、関係部門、停止判断の経路	業務責任者と意思決定者が決まっている
31〜60日	対象業務とPoCの設計	候補比較、利用範囲、現状値、評価項目、終了条件	入力可能な情報とPoCの合否条件を説明できる
61〜90日	検証と導入判定	業務効果、利用実態、リスク、継続費用	継続・修正・中止のいずれかを根拠付きで選べる

1〜30日：推進体制と責任分担を決める

最初の30日では、専門部署の設置よりも、誰が何に責任を持つかを確定させます。専任者を置けない企業でも兼任は可能ですが、業務上の成果と品質に責任を持つ人を空欄にしたまま進めてはいけません。

決めるべき5つの責任

初期段階では大規模な推進組織を設ける必要はありません。一方で、次の5つの責任には、氏名または役職を割り当てます。

• 日常利用：対象工程、利用方法、人が確認する工程、教育、問い合わせ対応を管理する
• 効果測定：現状値とKPIを管理し、継続や改善の判断材料を作る
• データと権限：入力可能な情報、アカウント、アクセス権限、ログを管理する
• 例外・事故対応：問題発生時の停止、報告、調査、再開を判断する
• 外部事業者管理：契約、費用、作業分担、改善要望、定例報告を管理する

責任	主な担当候補	開始前に決める事項
日常利用	業務部門長、現場責任者	対象工程、利用者、品質確認、教育方法
効果測定	業務部門、経営企画、DX推進	現状値、評価項目、集計頻度
データと権限	情報システム、セキュリティ、データ保有部門	入力範囲、権限、アカウント、ログ
例外・事故対応	経営者、役員、法務、セキュリティ責任者	停止条件、報告先、再開の承認者
外部事業者管理	DX推進、情報システム、管理部門	契約窓口、作業分担、成果物、費用

推進責任者は技術知識だけで選ばない

推進責任者には、経営層へ短い経路で報告できること、複数部門を横断して調整できること、対象業務の課題を理解できることが求められます。AIに詳しいことだけを理由に技術担当者へ全責任を集めると、業務効果や現場運用の判断が不足しやすくなります。

情報システム部門は利用環境や権限を判断できますが、成果物の品質が業務上十分かどうかは、業務責任者が判断すべきです。反対に、業務部門だけでは契約条件や情報管理を評価できないため、初回の検討段階から情報システム、セキュリティ、必要に応じて法務を参加させます。

経営層が関与する場面を限定する

経営層にはすべての定例会議への出席を求めるのではなく、次の場面で判断を依頼します。

• AI導入の目的、対象範囲、予算上限を決めるとき
• PoC開始の可否と許容できるリスクを決めるとき
• 継続投資、全社展開、利用停止を決めるとき

1. 5つの責任を一覧にし、氏名または役職を記入します。
2. 問題発生時の報告先、連絡手段、停止判断者、再開承認者を記載します。
3. 経営層が参加する判断会議と、実務担当者だけで進める定例会議を分けます。
4. PoC後に運用を引き継ぐ担当者を決め、必要な工数を確認します。

31〜60日：対象業務を絞り込み、PoCを設計する

候補業務は複数挙げてから、同じ基準で比較します。最初の1件は期待効果の大きさだけで選ばず、結果を測りやすく、誤りが発生しても人が確認して影響を抑えられる業務を優先します。

対象業務を7つの軸で比較する

候補はできれば3件以上集め、次の7軸について「適している・条件付き・適していない」などの共通尺度で相対比較します。

比較軸	確認する質問	初回PoCに向く状態
業務上の重要度	改善が経営・部門課題の解決につながるか	目的との関係を説明できる
作業量と頻度	一定量が繰り返し発生しているか	比較に必要な件数を確保できる
標準化しやすさ	担当者ごとの手順や判断が大きく異ならないか	基本手順と完成条件を文書化できる
必要データ	検証に使えるデータが存在し、利用できるか	所在、品質、利用権限を確認できる
誤りの影響	誤出力が顧客、契約、金銭、権利へ及ぼす影響は何か	限定された範囲で試せる
成果の測りやすさ	時間、件数、品質などの現状値を取れるか	検証前後を同じ条件で比較できる
人による確認	本番利用前に担当者が出力を確認できるか	レビュー工程を組み込める

合計点だけで機械的に選ぶのではなく、重大なリスクが一つでもある候補は別枠で扱います。点数が高くても、必要データを利用できない、誤りの影響を限定できない、人による確認ができない場合は、最初のPoCには適しません。

候補業務が一つしか挙がらない場合は、無理に候補数を増やす必要はありません。ただし、その業務を選ぶ理由に加えて、ほかの業務を選ばなかった理由を記録し、選定判断を説明できる状態にします。

高リスク業務は通常のPoCから外す

次の業務は一律に導入不可という意味ではありませんが、一般的な小規模試行と同じ手順で始めるべきではありません。法務、セキュリティ、情報システム、契約管理部門などの確認を先行させます。

• 機密情報や個人情報を主に扱う業務
• 誤回答が顧客、取引、審査、重要な意思決定へ大きな影響を与える業務
• 法令、業界規制、契約、秘密保持義務による制約がある業務
• AIの出力を基幹システムへ直接書き込む業務
• 人が出力を確認できないまま社外へ提供される業務

PoC開始前に5項目を文書化する

対象業務を決めたら、ツール契約や設定作業の前に、次の5項目を一つの計画書へまとめます。

• 現状値：現在の作業時間、処理件数、品質、手戻りなど
• 評価項目：業務効果、利用状況、修正負荷、リスク事象など
• 利用範囲：対象者、対象工程、使用データ、検証件数、利用環境
• 禁止事項：入力禁止情報、禁止用途、AIだけで確定してはいけない成果物
• 終了条件：終了日、継続条件、中止条件、判断者、報告方法

1. 各部門から候補業務を集め、7つの軸で比較します。
2. 高リスク業務を分け、追加確認が必要な事項を明示します。
3. 初回PoCの候補を一つ選び、選定理由を一文で記録します。
4. 現状値、評価項目、利用範囲、禁止事項、終了条件を文書化します。
5. 業務責任者、情報管理担当者、意思決定者の承認後にツール選定へ進みます。

PoC開始前にデータとセキュリティを確認する

PoCを開始できるかどうかは、期待する精度より先に、入力してよい情報の範囲を定義できるかで判断します。契約・利用条件、会社が管理する利用環境、アクセス権限、出力の確認工程、問題発生時の記録と停止手順をそろえます。

契約・利用条件を確認する

生成AIサービスでは、プランやAPIの利用形態によってデータの取り扱い条件が異なる場合があります。営業資料やWebサイトの説明だけで判断せず、契約書、利用規約、プライバシー関連文書、セキュリティ資料を確認し、確認日と参照箇所を記録します。

• 入力データや出力データがサービス改善・学習に利用されるか
• データの保持期間と削除条件はどうなっているか
• 提供事業者や委託先がデータへアクセスできる範囲はどこまでか
• データの保存・処理場所に関する条件を確認できるか
• 障害、情報漏えい、仕様変更が起きた場合の通知条件は何か
• 契約終了時にデータとアカウントを削除できるか

契約条件は変更される可能性があるため、確認時点を残すことが重要です。個人情報、著作物、取引先情報などの取り扱いについて個別の法的判断が必要な場合は、法務部門または専門家へ確認します。

会社管理の利用環境と権限を用意する

個人アカウントや管理外の無料プランを業務利用に残すと、退職・異動時の停止、利用状況の把握、設定の統一が難しくなります。会社が管理するアカウントを用意し、利用者、管理者、権限付与者を分けます。

AIを導入するために、既存データのアクセス権限を広げることも避けます。利用者が元々閲覧できない情報をAI経由で参照できる状態にすると、既存の情報管理と矛盾します。必要最小限の権限を維持し、異動・退職・委託終了時の停止手順まで確認します。

入力情報と出力成果物を分類する

入力側では、候補業務で扱う情報を機密度や契約条件に応じて分類し、「入力可」「条件付きで入力可」「入力禁止」に分けます。匿名化や置き換えによって利用できる情報については、加工方法と確認者も定めます。

出力側では、誤った内容が混入した場合の影響を整理します。社外文書、提案資料、規程、顧客対応、重要な意思決定に使う資料などは、AIの出力をそのまま確定せず、人による事実確認、根拠確認、承認を業務手順に組み込みます。

ログ、停止、報告の手順を決める

問題が発生してから記録方法を決めるのでは遅いため、PoC段階から利用状況とリスク事象を記録します。少なくとも、利用者、利用日時、対象業務、問題の内容、影響範囲、対応結果を追跡できる状態にします。

1. 対象業務で使用する情報を洗い出し、機密度と利用条件で分類します。
2. 契約・利用条件を確認し、確認日、参照文書、判断結果を記録します。
3. 会社管理のアカウント、権限、利用者の追加・削除手順を設定します。
4. 入力可能な情報、禁止情報、人が確認する成果物を一枚のルールにまとめます。
5. 停止条件、報告先、調査担当者、再開承認者を参加者へ共有してからPoCを開始します。

61〜90日：効果を測り、継続・修正・中止を判断する

PoCは技術性能を確認するだけの実験ではなく、本番導入の可否を決めるプロセスです。業務指標、利用実態、リスク事象の3方向から評価し、継続、条件を修正して再検証、中止のいずれかを期限内に選びます。

評価指標を3つに分ける

技術的な精度が高くても、修正作業が増えたり、現場で使われなかったりすれば、業務上の効果があるとは限りません。反対に、利用率だけが高くても、品質低下や情報管理上の問題が発生していれば展開できません。

• 業務指標：作業時間、処理件数、手戻り、修正量、品質のばらつき、既存工程への影響
• 利用実態：対象者のうち実際に使用した割合、利用頻度、使わなかった理由、教育や支援の負荷
• リスク事象：誤出力の件数と影響、入力ルール違反、権限上の問題、問い合わせ、停止に至った事象

一律の合格数値を他社事例から流用するのではなく、自社の現状値、投資額、品質要件、許容できるリスクから基準を決めます。繁忙期と閑散期のように条件が異なる期間を比較する場合は、同じ業務量へ換算するか、比較期間をそろえます。

「継続・修正・中止」の3択で判定する

判定	主な状態	次の行動
継続	業務効果を確認でき、リスクと運用負荷が許容範囲にある	限定運用へ移行し、全社展開の条件を確認する
修正	効果の可能性はあるが、対象範囲、教育、データ、確認工程に改善余地がある	変更点と再検証期限を定め、範囲を限定して試す
中止	効果が不足する、必要データを確保できない、許容できないリスクがある	中止理由と得られた知見を記録し、契約・データを整理する

中止はPoCの失敗とは限りません。開始前に設定した条件に基づいて投資を止め、対象業務や前提条件に関する知見を残せたなら、導入判断として意味があります。判断を避けて検証期間を延長し続けるほうが、担当者と現場の負担を増やします。

判定会議を実施する

1. 検証終了の2週間前に、集計項目、データの取得状況、比較条件を確認します。
2. 業務指標、利用実態、リスク事象を集計し、当初の目的と終了条件に照らします。
3. 利用されなかった場合は、業務に合わないのか、教育・環境・権限に問題があったのかを切り分けます。
4. 業務責任者、データ・セキュリティ担当者、意思決定者が参加する判定会議を開きます。
5. 継続・修正・中止の結論、根拠、次の期限、必要な費用と人員を一枚にまとめます。

経営層には業務と投資の言葉で報告する

経営報告では、モデルや機能の説明を中心にせず、当初の課題がどこまで改善したかを示します。次の情報を簡潔にまとめれば、追加投資の可否を判断しやすくなります。

• 当初の目的文と対象業務
• 検証前の現状値と検証後の結果
• 成果物の品質と人による修正負荷
• 発生したリスク事象、影響、対応結果
• 本番運用に必要な費用、人員、教育、システム対応
• 継続・修正・中止の推奨結論と理由

全社展開に進む前に確認すること

一つの部門でPoCが成功しても、そのまま全社展開できるとは限りません。再現性、運用の受け皿、権限と監査、教育、問い合わせ対応、継続費用、既存業務との整合性を確認してから利用範囲を広げます。

展開前チェック項目

• 他部門でも同じ手順と品質基準を再現できるか
• 本番運用の責任者と問い合わせ窓口が決まっているか
• 利用者向けの教育、手順書、入力例、禁止事項を用意できるか
• アカウントの発行・変更・削除と権限管理を継続できるか
• 利用ログを取得し、定期的に点検できるか
• 障害や問題発生時の停止、報告、調査、再開手順があるか
• ライセンス、運用、教育、問い合わせ対応を含む継続費用を説明できるか
• 既存の業務フロー、社内規程、契約、承認手続きと矛盾しないか

PoCの暫定ルールを正式な社内ルールへ移す

PoC参加者だけが理解している口頭ルールでは、利用者が増えたときに統制できません。利用してよい業務、入力可能な情報、人が確認する工程、禁止用途、問題発生時の連絡先を正式な文書へ反映します。

すべてのAI利用を同じ厳しさで扱うのではなく、業務への影響と使用データに応じて承認方法を変えると運用しやすくなります。公開情報を使った下書きと、個人情報を含む顧客対応では必要な確認が異なるためです。

内製と外部支援の範囲を分ける

導入目的、業務上の優先順位、品質基準、許容リスク、最終的な継続判断は、自社に残すべき領域です。外部支援を利用する場合も、これらの判断まで委ねると、支援終了後に運用や改善を継続できません。

一方、次の条件に該当する場合は、必要な範囲を明確にしたうえで外部支援を検討できます。

• 候補業務を比較できず、経営課題から検証対象へ分解できない
• データ連携、アクセス権限、契約・セキュリティ要件を社内で評価できない
• PoCの設計、評価指標の設定、検証データの集計を担当できる人がいない
• 既存システムとの連携や独自開発が必要で、技術要件を定義できない
• 複数部門への展開に伴うルール、教育、運用体制を設計できない

外部へ依頼する際は、対象業務、成果物、作業分担、判断会議への参加者、知識移転の方法、契約終了後の運用担当を明記します。ツールの導入作業だけでなく、自社が継続判断できる状態を成果として設定することが重要です。

まとめ

AI導入は、ツールを選ぶことではなく、解決する課題と導入後の判断条件を決めることから始めます。最初の90日では全社導入を急がず、一つの業務を対象に、責任体制、データ、リスク、評価指標をそろえて継続可否を判断します。

まず1〜30日で目的文、現状値、5つの責任、停止判断の経路を決めます。31〜60日で候補業務を比較し、入力可能な情報、利用範囲、評価項目、禁止事項、終了条件を定めます。61〜90日で業務効果、利用実態、リスク事象を集計し、継続・修正・中止のいずれかを選びます。

最初の行動は、対象ツールの資料請求ではありません。「誰の、どの業務の、どの状態を改善するのか」を一文にし、その成果と品質に責任を持つ業務責任者を決めることです。この2点が決まれば、候補業務の比較とPoC設計へ進めます。

よくある質問

AI導入担当者が最初の1週間で確認すべきことは何ですか？

経営・業務課題、対象部門、意思決定者、業務責任者、利用予定のデータ、判断期限を確認します。最初の会議ではツールを決めず、「何を改善するか」「誰が継続・停止を判断するか」「現状値をどう測るか」の3点を合意してください。

AI導入の対象業務は、どのような基準で絞り込めばよいですか？

業務上の重要度、作業量、標準化しやすさ、必要データの有無、誤りの影響、成果の測りやすさ、人による確認の可否で比較します。初回は、期待効果が最大の業務より、短期間で効果を測れ、誤りの影響を人が抑えられる業務を優先します。

PoCを始める前に、データとセキュリティの何を確認すべきですか？

入力データの学習利用、保持期間、提供事業者のアクセス範囲、会社管理アカウント、アクセス権限、入力禁止情報、人による出力確認、ログ、停止手順、報告先を確認します。入力可能な情報を定義できない場合は、条件を整えるまで開始しません。

PoCの成功・継続・中止は、どのように判断すればよいですか？

検証前の現状値と比較し、業務効果、利用実態、リスク事象の3方向から判断します。効果がありリスクと運用負荷が許容範囲なら継続、改善点を限定できるなら修正して再検証、効果不足や許容できないリスクがあるなら中止します。

専門人材が社内にいない場合、内製と外部支援をどう判断すべきですか？

導入目的、業務の優先順位、品質基準、許容リスク、継続判断は自社で担います。データ連携、セキュリティ評価、PoC設計、効果測定、既存システムとの連携を担当できない場合は、その不足領域に限定して外部支援を検討してください。

著者プロフィール

この著者の記事一覧へ

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。