AI導入は次の5段階で進みます。順番に見ていく前に、全体像を押さえておいてください。

技術の話が出てくるのは③から

ここで強調しておきたいことがあります。①と②では、技術よりも業務整理と意思決定が中心になります。やっているのは業務の整理と意思決定であり、AIの専門知識がなくても進められる部分が多くあります。

それにもかかわらず、AI導入でつまずく企業は、この2段階で課題を抱えることが少なくありません。対象業務の選定を誤ったまま③以降に進むと、技術的には成功しているのに誰も使わないシステムができあがります。この場合、開発費が無駄になるだけでなく、社内に「AIは使えなかった」という記憶が残り、次の提案が通りにくくなります。

逆に言えば、最初の2段階は社内だけでも進められます。外部に相談するとしても、自社である程度整理してから声をかけたほうが、話が具体的になります。

5段階すべてを通す必要はない

すべての案件が①から⑤まで順に進むわけではありません。既製ツールを1業務に導入するだけなら、③のPoCは数日の試用で済みますし、④の本開発にあたるものは発生しません。

この記事は、社内システムに組み込む規模の導入を想定して各段階を説明します。自社の規模に合わせて、不要な段階は省いてください。重要なのは手順を守ることではなく、判断すべきことを飛ばさないことです。

始める前に、3つの役割を決めておく

手順より先に決めておくべきものがあります。誰がこの取り組みを進めるのか、という体制です。

• 推進担当 — 日常的に手を動かし、関係者をつなぐ人。専任である必要はありませんが、月に一定の時間を確保できることが条件です
• 判断者 — 進む・止めるを決める人。予算の権限を持つ立場が望ましい
• 現場の代表 — 実際にその業務をやっている人。1人で構いません

3つ目が抜けている体制はよく見られ、導入後の定着で課題になりやすい傾向があります。企画部門と外部の会社だけで進めた仕組みは、現場の運用と噛み合いません。設計段階で使う人を1人入れるだけで、導入後の定着率が変わります。

逆に、この3つさえ決まっていれば、AIの知識がある人が社内にいなくても進められます。必要なのは技術の知識ではなく、業務を説明できることと、社内の判断を通せることです。

最初にやることは、AIで何ができるかを調べることではありません。自社の業務のうち、どこに時間がかかっているかを把握することです。

洗い出しの単位は「業務」ではなく「工程」

「経理業務」「問い合わせ対応」という粒度で並べても、AIを当てる場所が見えません。必要なのは、その中の工程に分解することです。

たとえば請求書処理であれば、受領する、内容を目視で確認する、システムに入力する、承認に回す、保管する、という工程に分かれます。このうちAIが効くのは「内容を目視で確認する」「システムに入力する」の部分で、承認の判断や例外対応は人が残ります。

工程まで割らないと、AIで何割が減るのかを見積もれません。そして見積もれないと、投資判断も稟議も通りません。

各工程について押さえる4つの数字

• 頻度 — 月に何件発生するか
• 所要時間 — 1件あたり何分かかるか
• 担当者数 — 何人が関わっているか
• ばらつき — 人によって、時期によってどれだけ変わるか

正確な数字である必要はありません。現場に聞いた概算で構いませんが、「だいたい多い」ではなく数字にしてください。この作業をやっておくと、後の全段階が楽になります。PoCの合格ラインもここから決まりますし、導入後の効果測定も同じ数字と比較するだけで済みます。

棚卸しシートに並べる項目

表計算ソフトで作れる程度のもので構いません。次の項目が埋まっていれば、以降の判断に使えます。

この表が20行ほど埋まれば、次の段階に進めます。全業務を網羅する必要はありません。時間がかかっていると感じているものから順に埋めていき、20行に達したら止めて構いません。

現場に聞くときのコツ

「AIで楽になりたい業務はありますか」と聞いても、有用な答えはあまり返ってきません。多くの人はAIで何ができるか知らないため、想像の範囲でしか答えられないからです。

代わりに、次のように聞いてください。

• 「今週、いちばん時間を取られた作業は何でしたか」
• 「同じことを何度も繰り返していると感じる作業はありますか」
• 「他の人に頼みにくい、自分しかできない作業はありますか」

技術の話をせず、事実だけを集めるのがこの段階です。AIに向くかどうかの判断は次の段階で行います。

洗い出した工程のうち、どれから着手するかを決めます。AI導入の成否は、実質ここで決まります。

AIが効きやすい工程の3条件

• 処理量が多い — 件数が少ない業務は、自動化しても効果が小さい
• 判断基準が言語化できる — 「なんとなく」で判断している業務は、AIにも説明できない
• 間違えても取り返しがつく — 一発勝負の判断は、精度が100%でない限り任せられない

3つとも満たす工程が、最初の候補になります。逆に、月に数件しか発生せず、ベテランの勘で判断していて、間違えると顧客に直接影響する業務は、技術的に可能でも最初に手をつけるべきではありません。

効果と実現しやすさの2軸で並べる

ありがちなのは、効果の大きさだけで選んでしまうことです。全社の基幹業務にいきなり手をつけると、関係部署の調整だけで数ヶ月かかり、その間に社内の熱が冷めます。

初回の導入対象は「効果が大きく、実現しやすい」ものを選ぶのがおすすめです。成果が出れば、社内の理解が得られ、2件目以降が通りやすくなります。1件目で難易度の高いものに挑んで失敗すると、その後の提案が止まります。

1件目に選ばれることが多い業務

判断の参考として、実際に最初の対象になりやすい業務を挙げます。いずれも前述の3条件を満たしやすい領域です。

自社の業務がこの表に当てはまらなくても問題ありません。3条件（処理量が多い・判断基準が言語化できる・間違えても取り返しがつく）に照らして考えてください。表はあくまで、判断の感覚をつかむためのものです。

「AIでなくてもいい」という結論も選択肢

この段階で、AIを使わないほうが早いという結論に至ることがあります。手順を見直すだけで解決する、既存システムの設定変更で足りる、そもそもその業務自体をやめられる。

これは失敗ではなく、正しい成果です。AIを導入することが目的になっていると、この判断ができなくなります。経営から「AIで何かやれ」と降りてきた場合ほど、ここを意識してください。

選定した候補と判断根拠は、必ず文書に残してください。後の段階で「なぜこの業務を選んだのか」を問われる場面が必ず来ます。

PoCは実現性と精度を確かめる段階です。ここで最も多い失敗は、合格ラインを決めずに始めることです。

検証の前に決めておく4つのこと

• 何を確かめるのか — 精度か、処理速度か、既存システムとつながるかどうかか
• どうなったら合格か — 数値で。「精度80%以上」「1件あたり3分以内」など
• 誰が判断するのか — 結果を見て進む・止めるを決める人
• いつまでにやるか — 期限を切らないと、検証が延々と続きます

2つ目が特に重要です。「精度80%」という数字が高いのか低いのかは、業務によって違います。人が目視で確認している現状の精度が95%なら80%では使えませんし、そもそも人手では追いつかず未処理が溜まっている業務なら60%でも価値があります。

だからこそ、ステップ①で現状の数字を押さえておく必要があります。比較する相手がいない状態では、合格ラインを決められません。

「止める」判断ができる設計にする

PoCの成果には、「これは進めない」という判断も含まれます。むしろ、数百万円の本開発に進む前に止められたなら、それはPoCが機能したということです。

ところが実務では、止めにくい状況が生まれがちです。ここまでの費用が惜しい、関係者に説明しづらい、経営に報告済みで引っ込みがつかない。こうした力学を避けるには、始める前に「こうなったら止める」を明文化しておくのが有効です。

検証範囲は思い切って狭くする

PoCで全社の業務を対象にする必要はありません。1部署、1業務、直近3ヶ月分のデータ。この程度に絞ったほうが、早く結果が出て、判断も早くなります。

範囲を広げると、データを集めるだけで1ヶ月かかり、関係者との調整にも時間を要します。PoCの目的は網羅ではなく、判断材料を得ることです。

PoCの次を誰が担当するかを先に確認する

外部に依頼する場合、検証だけを請け負って本開発は別会社、という体制になることがあります。この場合、PoCで得た知見が引き継ぎの過程で失われます。

依頼前に「PoCの後、本開発も同じチームで担当できるか」を確認しておいてください。答えが「別途相談」の場合、その前提でスケジュールと費用を見ておく必要があります。段階別の費用感はAI導入の費用相場で詳しく整理しています。

PoCで進む判断が出たら、実際に業務で使える形にします。技術的な作業は外部に任せられますが、この段階で発注側にしかできない仕事があります。

発注側が担う3つのこと

1. 受け入れテスト
実際の業務データで、想定どおり動くかを確認します。開発側のテストは仕様どおりに動くかの確認であり、業務として使えるかの判断は発注側にしかできません。ここに現場の担当者を入れてください。

2. 運用ルールの整備
誰が使うのか、AIの出力をそのまま使ってよいのか、確認が必要な場合の手順はどうするのか。特に生成AIを使う場合、入力してよい情報の範囲を明文化しておく必要があります。

3. 現場への説明
完成してから通知するのではなく、開発中から状況を共有しておきます。ここを怠ると、便利なものを作っても「勝手に決められた」という反発が先に立ちます。

入力してよい情報の範囲を先に決める

生成AIを使う場合、展開前に必ず整理しておくべきことがあります。何を入力してよく、何を入力してはいけないのかです。

顧客の個人情報、取引先との契約内容、未公開の経営情報、開発中の製品仕様。これらの扱いを決めないまま現場に渡すと、判断が個人に委ねられます。悪意なく情報が外部に出るのは、たいていルールがない状態で「これは大丈夫だろう」と判断されたときです。

決めるべきは次の3点です。

• 入力してよい情報と、してはいけない情報の区分
• 迷ったときに誰に確認するか
• 使用するサービスが、入力内容を学習に利用しない設定になっているか

3つ目は契約プランや設定によって変わるため、導入時に確認し、その結果を記録しておいてください。後から「どうなっていたか」を調べ直す手間が省けます。

一斉展開せず、段階的に広げる

完成したものを全社に同時展開するのは避けてください。想定外の使われ方や、業務の例外パターンが必ず出てきます。

まず1部署、あるいは協力的なメンバー数名から始め、出てきた問題を潰してから広げます。最初の利用者が「使いやすい」と言っている状態を作ってから広げると、展開がスムーズになります。逆に、最初の利用者が不満を持ったまま広げると、その評判が先に伝わります。

説明会より、手元で触れる時間

展開時によく行われるのが全体説明会ですが、聞くだけでは使えるようになりません。実際の業務で1件処理してみる時間を、その場で取ってください。

あわせて、社内の問い合わせ窓口を決めておきます。展開初期は「これはどう使うのか」という質問が集中します。窓口が不明確だと、質問できないまま使わなくなる人が出ます。

導入したAIが使われなくなる時期は、だいたい決まっています。展開から3〜6ヶ月後です。最初の物珍しさが薄れ、精度への不満が出はじめ、担当者が異動する頃合いです。

使われなくなる3つの理由と、その対処

精度が落ちたように感じられる
実際にはAIの性能が落ちたのではなく、参照している情報が古くなっているケースがほとんどです。社内規程が改定された、商品情報が更新された、業務手順が変わった。元データを更新する担当と頻度を決めておかないと、必ずこうなります。

例外対応が面倒で、結局手作業に戻る
AIが処理できないパターンに出会ったとき、どうすればいいかが決まっていないと、人は元のやり方に戻ります。例外時の手順を用意し、その件数を記録してください。件数が多ければ、改善の対象になります。

担当者が変わって、経緯が分からなくなる
なぜこの設定なのか、なぜこの業務は対象外なのかが分からなくなると、誰も触れなくなります。判断の経緯を残しておくことが、運用を継続しやすくする土台になります。

当社の実感｜決めたことを残しながら進める

3つ目について、当社自身の経験を書きます。ある会員制アプリの開発案件で、複数のエンジニアが入れ替わりながら1年以上進める体制を取っていた時期がありました。

途中で「仕様書を正として作業し、議論した内容を都度そこへ反映できていれば、後戻りを減らせたはずだ」という反省があり、そこから運用を変えました。打ち合わせで決めたことは必ずドキュメントへ反映する。会話で決まったまま、どこにも書かれていない状態をなくす。

結果として、新しく参加したメンバーが人に聞かずに経緯まで追える状態になり、担当が入れ替わっても大きな停滞なく継続できました。運用保守の段階でも、開発時に何をなぜ決めたのかを参照できます。

これは開発側の話ですが、AI導入の運用でも構造は同じです。担当者の記憶に依存した運用は、その人が異動した時点で止まります。各ステップの判断根拠を残しながら進めることが、半年後に使われている状態をつくります。

なお、この取り組みについて前後の工数を計測しておらず、削減率として示せる数字はありません。現場の手応えとしての話です。数字で語れないことは反省点で、現在は計測を始めています。

ガバナンスの整備も運用の一部

総務省と経済産業省は、AIの開発・提供・利用に関わる事業者向けの行動指針として「AI事業者ガイドライン」を公表しており、2026年3月31日に第1.2版が公表されています。法的拘束力を持つものではありませんが、社内ルールを整備する際の参照先になります。

第1.2版では、自律的に業務を進めるAIエージェントなどが新たに射程に入り、外部に影響を与える操作の前に人が判断できる仕組みを設けることが盛り込まれました。AIに任せる範囲が広がるほど、どこで人が確認するかの設計が重要になります。詳細は原本をご確認ください。

運用体制をどう組むか、どこまで自社で回せるかは、対象業務によって変わります。判断に迷う場合はご相談ください。

スケジュールを引くときの目安です。対象業務の複雑さと、既存システムとの連携範囲によって変わります。

①から③までで2〜4ヶ月、本開発まで含めると半年から1年が一つの目安になります。

期間が延びる典型的な要因

予定どおり進まない場合、原因はたいてい技術ではありません。

• データが揃わない — 散在している、形式がばらばら、そもそも記録されていない
• 社内の合意に時間がかかる — 判断者が決まっていない、関係部署が多い
• 繁忙期と重なる — 現場の協力が得られず、ヒアリングもテストも進まない

3つ目は事前に避けられます。計画を立てる段階で、対象部署の繁忙期を確認してください。決算期や年度末に受け入れテストを設定すると、まず動きません。

半年で本開発まで進める場合の例

4月に着手し、年度後半に稼働させる想定でスケジュールを引くと、次のようになります。

• 1ヶ月目 — 体制を決め、業務の棚卸しを実施。現場ヒアリング
• 2ヶ月目 — 候補を絞り、優先順位を決定。ここで外部への相談を開始
• 3〜4ヶ月目 — PoCの設計と実施。合格ラインに沿って判断
• 5〜7ヶ月目 — 本開発。並行して運用ルールを整備
• 8ヶ月目 — 一部部署で先行展開、問題を潰す
• 9ヶ月目以降 — 順次拡大、運用へ移行

補助金の活用を検討している場合、この計画に締切と交付決定のタイミングを重ねる必要があります。交付決定の前に発注すると補助対象外になるため、発注時期が制度側のスケジュールに縛られます。制度の対象範囲と申請スケジュールはAI導入で使える補助金にまとめています。

また、右側の「社内で必要な関与」の列を軽く見ないでください。外部に依頼しても、業務を知っている人の時間は必ず必要になります。ここを想定せずに計画すると、担当者の通常業務と衝突して全体が止まります。

段階ごとに、実際によく起きることを整理します。

①でつまずく｜現場の協力が得られない

ヒアリングに来た相手が「業務を効率化する」と言えば、現場は自分の仕事が減らされると受け取ります。目的の説明を省くと、正確な情報が集まりません。

対処としては、何のために調べているのかを先に伝えることです。人を減らすためではなく、時間のかかっている作業を減らすためだと明示する。曖昧にしたまま進めると、後の展開段階でも協力が得られません。

②でつまずく｜候補が絞れない

候補が10も20も出てきて、どれも捨てがたく決められない状態です。この場合、判断軸が共有されていないことが原因です。

効果と実現しやすさの2軸に当てはめ、判断する人を1人決めてください。合議で決めようとすると、全員が納得する無難な候補が選ばれ、結果として効果の小さいものに着手することになります。

③でつまずく｜結果の解釈で揉める

合格ラインを決めずに検証すると、必ずここで止まります。結果が出てから「この数字をどう評価するか」を議論することになり、立場によって解釈が割れます。

前述のとおり、検証を始める前に、数値の基準と判断者を決めておくことが唯一の対処です。後から決めようとすると、政治的な話になります。

④でつまずく｜現場が使わない

完成したものを渡したが使われない、という状態です。原因の多くは、設計段階で実際に使う人が関わっていないことにあります。

企画部門と開発会社だけで進めた仕組みは、現場の運用と噛み合いません。設計段階で使う人を1人入れるだけで、この問題の大半は防げます。

⑤でつまずく｜運用の担い手が決まっていない

誰が精度を見るのか、誰が問い合わせを受けるのか、誰がデータを更新するのか。これらが決まっていないと、数ヶ月で利用が止まります。

開発の契約と同時に、運用体制の話を始めてください。「稼働してから考える」は、実際には「考えないまま止まる」になります。

すでにつまずいている場合

いずれかに当てはまっていても、やり直しになるとは限りません。PoCで止まっている案件は、検証結果を捨てずに「何が分かって、何が分からなかったか」を整理し直すところから再開できます。使われていないシステムも、対象業務を絞り直せば復活する例があります。

着手前の相談と同じくらい、止まってからの相談も一般的です。

自社の場合にどの段階から着手すべきか、対象業務の候補出しからご相談いただけます。
AI導入支援の全体像はAI導入支援で整理しています。