著者:野原琉海(業務効率化に特化したエンジニア)
「ChatGPTを使って業務を効率化したい。できれば自社のシステムに組み込みたい」という話を、顧問先の経営者から週に2〜3回は聞く。
内製化への意欲は本物だ。問題は、その多くが3〜6ヶ月以内に止まっていることだ。完成しないまま、あるいは完成しても使われないまま、毎月のツール費だけが積み上がっていく。
業務効率化に特化したエンジニアとして、顧問先のAI活用を支援してきた経験から言うと、内製化が失敗する理由の9割は技術の問題ではない。体制と進め方の問題だ。この記事では、中小企業のAI内製化が止まる典型的な5つのパターンと、それぞれの対策を整理する。
AI内製化が失敗する5つの典型パターン
まず、どのパターンに当てはまりそうかを整理する。チェックリストとして使ってほしい。
| パターン | よくある状況 | 主な損失 |
|---|---|---|
| パターン1: 担当者1人への集中 | 「AIに詳しい社員」1人に全て任せている | 退職・異動で全てが止まる |
| パターン2: PoC止まり | 試作は動いたが本番業務に入っていない | 開発コストと時間の無駄 |
| パターン3: 成果の測り方が不明 | 効果があったかどうか判断できない | 投資判断ができない |
| パターン4: 現場が使わない | 作ったが誰も使っていない | ツール費だけ発生し続ける |
| パターン5: トラブル対応できない | 動かなくなっても直せる人がいない | 業務が突然止まる |
この5つのうち、2つ以上に心当たりがある場合、現在進めている内製化は高確率で止まる。
パターン1: 担当者1人に全てが集中し、その人がいなくなったら終わる
中小企業でAI内製化を進めると、たいていこうなる。「AIが得意な社員がいる」か「AIに興味があって自分でキャッチアップしている社員がいる」かで、その社員が全てを担当するようになる。
最初は効率的に見える。決定が速い。仕組みが次々に出来上がっていく。
ところが、その社員が退職した瞬間に全てが止まる。作ったシステムの仕組みを理解している人が社内からいなくなる。どのAPIキーを使っているかも分からない。エラーが出ても直せない。元の手作業に戻るしかない。
実際に顧問先の1社で、社内のエンジニアがChatGPTのAPIを使った問い合わせ対応の自動化を構築した。月200件の問い合わせを8割自動処理できる仕組みで、かなりうまくいっていた。そのエンジニアが転職した3ヶ月後、「急に動かなくなった」と連絡が来た。APIキーの更新が必要なだけだったが、設定ファイルの場所もパスワードも誰も知らなかった。
属人化は一般業務でも問題だが、AI活用においては特に深刻だ。コードが動いていること自体が「ブラックボックス」になる。
対策:引き継ぎ前提の仕組みを最初から作る
- 使っているAPIキー・サービス・設定の記録を必ず残す(Notionや社内Wikiで管理)
- 月1回、担当者以外の社員もシステムの確認作業を行う習慣を作る
- 手順書は「担当者が書く」ではなく「別の社員が担当者に聞きながら書く」形にする
- 外部のAI顧問と定期的に状況確認を行い、社内だけのブラックボックスにしない
特に重要なのは最後の点だ。外部の目が入っていると、「この人しか分からない状態」が自然と解消されていく。AI活用を内製するvsAI顧問に外注する|中小企業向け判断基準でも詳しく書いているが、内製と外部支援の組み合わせがリスクを下げる上で有効だ。
パターン2: PoC段階で止まり、本番業務に繋がらない
「試してみた。うまくいった。でも実際の業務では使っていない」という状態が続くケースだ。
PoCは成功した。精度も出た。デモも問題なかった。しかし本番業務に導入しようとすると、既存のシステムとの連携が必要だった。他部署への説明が必要だった。セキュリティ審査が必要だった。こうした「本番化に必要な手続き」がハードルになって、試験運用のまま放置になる。
PoC費用として100〜500万円を使ったにも関わらず、本番に届かずプロジェクトが凍結するケースは業界でも多く報告されている。自社のシステムにきちんと組み込まれて初めて、コストに見合う価値が生まれる。
僕が見てきたPoC失敗の事例でいちばん多いのは「KPI未設定」だ。「とりあえず動くか試してみよう」という始め方をすると、終わりの条件が決まっていないため、うまくいっても「本番に移すタイミング」が来ない。何がOKだったら次に進むのかを最初に決めていないと、PoC段階で永遠に止まる。
製造業のある会社では、画像検査の自動化PoCに約500万円を投じたが、「どの工程の不良を何%削減したら成功とみなすか」が決まっていなかった。精度は出ていたが成功基準がないため、経営判断ができずそのまま凍結した。
対策:本番移行の条件を先に決める
- PoC開始前に「本番移行の条件」を文章で決める(例: 精度90%以上 かつ 現場担当者3名の承認が得られた場合)
- 本番移行後の運用体制を仮決めしておく(誰が更新するか、トラブル時の連絡先はどこか)
- PoCに現場の担当者を最初から巻き込む(本番化の承認者が試作段階から理解している状態を作る)
パターン3: 「成果が出ているか」が分からないまま進む
内製化を進めているが、効果があったかどうか分からない。「使っている人は便利になった気がする」という感覚だけで、数字で成果が確認できていない状態だ。
測り方が決まっていないと、次の投資判断ができない。続けるべきか、やり方を変えるべきか、一旦止めるべきか。全ての判断があいまいになる。
特に怖いのは、費用だけが増え続けるパターンだ。API費用・ツール使用料・担当者の人件費が積み上がっていく一方で、業務がどのくらい楽になったかが数字で見えていない。3ヶ月後に「やっていたけど効果が分からなかった」で終わる。
業務効率化に特化したエンジニアとして言うと、この問題は「測る指標を決めること」だけで解決できる。難しい話ではない。何かを改善しようとしているなら、改善前と改善後で比べられる数字が1つあればいい。
対策:1つの数字を先に決める
- 「何が改善されれば成果とみなすか」を開始前に決める
- 処理時間・件数・エラー率・対応工数など、前後で比較できる指標を1つ選ぶ
- 月1回、その数字を確認するだけでいい(複雑なレポートは不要)
- 3ヶ月後に「改善なし」なら、続けるかやり方を変えるか判断する
下記の記事で具体的な効果測定の考え方をまとめているので参考にしてほしい: 中小企業のAI導入が成功する条件|経営者視点で整理
パターン4: 現場スタッフがシステムを使わない
システムは作れたが、現場の社員が使っていないケースだ。
操作が分かりにくい、使う理由が社員に伝わっていない、「従来のやり方の方が速い」と感じている、AIを使うことへの不安がある。これらのどれかが原因になっていることが多い。
ある小売業の会社で在庫管理のAI推奨システムを導入した事例がある。導入時に現場スタッフへの説明が不十分なまま「明日から使ってください」と指示したところ、AIへの不信感と「自分の仕事が奪われるかも」という不安から、活用が進まなかった。導入から3ヶ月後でもAIの推奨を無視して手動で処理するスタッフが多数残っていた。
内製化した担当者にとっては使い方が明白でも、初めて触れる人には分からないことが多い。「作った」と「使われている」は全く別の話だ。僕が顧問先で最初に確認するのは「今、実際に誰が何回使っているか」という数字だ。作ったことと使われていることを混同しているケースが本当に多い。
対策:「定着」を設計段階から考える
- リリース前に現場担当者3〜5名に試用してもらい、使いにくい点を事前に修正する
- 「なぜ使うのか」「使うとどう楽になるか」を現場に説明する時間を30分でも作る
- 手順書または説明動画(3分以内)を用意し、聞かなくても使える状態にする
- 初週は担当者が使い方の相談を受ける時間を確保する
- 月1回「誰が何回使ったか」を確認し、使われていない場合は理由を聞く
パターン5: 技術的なトラブルが起きると誰も対処できない
自社で構築したAIシステムが動かなくなった時、内製化を進めた担当者以外は対処できないケースが多い。
APIの仕様が変わった。クラウドの設定が更新された。依存しているライブラリのバージョンが変わった。これらは半年〜1年スパンで定期的に発生する変化だ。特にOpenAIのAPIは仕様変更・料金改定が頻繁にある。内製で作ったシステムは、作った人しか直せないことがほとんどだ。
担当者が不在の時にトラブルが起きると、業務が突然止まる。「自社で作ったのに自社で直せない」という状態になる。外注した業者に頼むと、当初の開発費とは別に保守費用が発生する。
重要なのは、この問題が起きることは最初から分かっているという点だ。APIは変わる。ライブラリは更新される。にもかかわらず、「本番稼働させた後のこと」を考えずに開発を進めるプロジェクトが多い。
対策:保守体制を構築段階から設計する
- 「誰でも最低限の対処ができる」手順書をシステム完成と同時に作る
- 定期的に外部の技術サポートを受けられる体制(AI顧問・業務委託エンジニア)を用意しておく
- 使っているAPIやクラウドサービスの更新情報を月1回確認する担当を決める
- クリティカルなシステムは「止まった時の代替手段」を先に決めておく
内製化 vs 外部支援 — 中小企業はどちらを選ぶべきか
内製化か外注かという選択は、「どちらが優れているか」ではなく「自社のリソースと目的に合っているか」で判断する。
| 比較軸 | 内製化 | 外部支援(AI顧問) |
|---|---|---|
| 初期費用 | API費用・開発工数(月数万〜数百万円) | 月3〜30万円が中心(内容・規模による) |
| 社内にノウハウが残るか | 残る(担当者に集中するリスクあり) | 残しやすい(定期的に整理・共有できる) |
| トラブル時の対応 | 担当者に依存 | 外部がサポートできる |
| スピード | 担当者のスキル次第 | 即日〜数週間で動き出せる |
| 向いているケース | 専任のエンジニアがいる / 特定業務に深く使い込む | エンジニアがいない / 複数の業務をまんべんなく改善したい |
| リスク | 担当者の退職・異動 | 顧問変更時の引き継ぎ |
中小企業の大半は「AIに詳しい専任エンジニア」を社内に持つのが難しい。現実的な選択肢は、外部支援を活用しながら少しずつ社内のナレッジを積み上げていく形だ。
費用の実態についてはAI顧問の費用相場|月額3万〜30万円の価格帯と内訳でまとめているので、コスト面で迷っている場合は参考にしてほしい。
また、採用とのコスト比較についてはAI担当者を雇うvsAI顧問を依頼|コスト・成果・リスク比較が参考になる。
内製化を成功させるための3つの条件
パターン1〜5を踏まえると、中小企業がAI内製化を成功させるには3つの条件を満たすことが重要になる。
内製化を始める前に、以下のチェックリストで自社の準備状況を確認してほしい。
| 確認項目 | 準備できている | 準備が必要 |
|---|---|---|
| AI担当者が社内に2名以上いる | 内製化を進めやすい | 外部サポートを先に確保する |
| 担当者が退職した場合の引き継ぎ資料がある | 継続性のリスクが低い | 最初に作成を義務づける |
| 本番移行の成功条件を文書で決めている | PoC止まりを防げる | PoC開始前に必ず決める |
| 成果を測る指標(数値)を1つ決めている | 効果検証ができる | 指標を決めてから着手する |
| 現場スタッフがシステムの目的を理解している | 定着しやすい | 説明の機会を先に設ける |
| トラブル時の連絡先・対処手順が決まっている | 業務停止リスクが低い | 稼働前に必ず決める |
チェックが4つ以上OKなら内製化を進めやすい環境がある。3つ以下の場合、外部サポートを入れながら並行して整備することを勧める。
条件1: 担当者が複数いる、または外部サポートがある
1人体制での内製化は、担当者の退職で全てが止まるリスクを常に抱える。社内に2名以上の担当者を作るか、外部のAI顧問・業務委託エンジニアを定期的に巻き込む体制を作る必要がある。自社の場合、月3.5万円のAIツール代で経理・問い合わせ対応・コンテンツ制作を回しているが、これが成立しているのは複数の手段を組み合わせているからだ。
条件2: 「小さく始める」を徹底する
1つの業務に絞って改善を始める。最初から全社的な仕組みを作ろうとすると、PoC段階で止まる。「メールの下書きをAIに作らせる」「請求書の読み取りを自動化する」など、1つの具体的な作業から始めて、動いたら次に進む。AI導入は小さく始めるが正解|中小企業が失敗しない最初の一歩でも詳しく解説している。
条件3: 本番稼働後の「定着・保守」を設計に含める
開発・導入の計画だけでなく、「本番稼働後に誰が何をするか」を最初から決めておく。月1回のメンテナンス担当・トラブル時の連絡先・使用状況の確認担当を事前に割り当てておくだけで、「作ったのに止まった」を防げる可能性が大幅に上がる。
まとめ:内製化は「動かすこと」より「動き続けること」が難しい
AI内製化が失敗する理由の9割は技術の問題ではない。体制・進め方・定着の問題だ。
5つのパターンを振り返る。
- 担当者1人への集中 — 退職・異動で全てが止まる
- PoC止まり — 本番移行の条件が決まっていない
- 成果の測り方が不明 — 投資継続の判断ができない
- 現場が使わない — 定着設計が抜けている
- トラブル対応できない — 保守体制が設計されていない
「社内でAIを動かすこと」と「AIが業務の中で動き続けること」は別の話だ。前者を目標にすると、後者で必ずつまずく。
AIを業務に組み込む最初の一歩として、まず1つの業務を特定するところから始めることを勧める。そこから判断できることが見えてくる。AIを導入しても伸びない会社の特徴の記事も合わせて読んでほしい。