この記事の要点
- AI内製化は「利用の内製」「開発の内製」「基盤の内製」の3レベルに分かれ、全部を自社で持つ必要はありません
- 内製が向くのは、業務の変更が頻繁・社内固有性が高い・データを社外に出せない、という条件が重なるケースです
- 判断材料は初期費用ではなく3年総コスト。人件費・API利用料・改修頻度を並べて比較します
- 社内に必ず置くべき役割は「業務オーナー」1つ。AIエンジニアやインフラは外部調達でも成立します
- 多くの中堅・中小企業の現実解は、設計と初期構築を外注し、運用と改善を内製するハイブリッド型です
生成AIを試してはみたものの、部署ごとの個人利用で止まっている。外注で業務アプリを1本作ったが、少し直すたびに見積もりと時間がかかる。このあたりで「社内でAIを扱える体制を作るべきか」という話が出てきます。
ただ、内製化という言葉は範囲が広すぎます。ChatGPTの社内利用ルールを整えることも内製化と呼ばれますし、データ基盤からモデル運用まで自社で抱えることも内製化と呼ばれます。この2つは必要な人材も費用も桁が違います。
この記事では、AI内製化の範囲を3レベルに分けたうえで、自社が内製に踏み込めるかを判定する5つの分岐条件、必要な人材と維持コスト、そして設計は外注・運用は内製というハイブリッドの組み方までを整理します。読み終えたときに、自社がどこまでを社内に持つべきかを決められる状態を目指します。
目次
AI内製化とは？外注・SaaS導入との違いを整理する
AI内製化とは、AI・生成AIを使った業務システムの企画・開発・運用を自社の人材で回せる状態にすることです。ただし実務では「利用の内製」「開発の内製」「基盤の内製」の3レベルに分かれます。どこまでを自社で持ち、どこから先は外に任せるかを決めることが、内製化の最初の意思決定になります。
AI内製化の3つのレベル（利用・開発・基盤）
内製化は0か100かではありません。実務上は3段階に分けて考えると判断しやすくなります。レベルが上がるほど必要な人材の専門性と人数が増え、維持の負担も比例して重くなります。
| レベル | 自社で持つ範囲 | 必要な人材の目安 | 立ち上げ期間の目安 |
|---|---|---|---|
| 1. 利用の内製 | ツール選定、社内利用ルール、プロンプトやナレッジの整備、教育 | 兼務1〜2名（業務部門＋情シス） | 1〜3カ月 |
| 2. 開発の内製 | RAG・社内チャット・業務アプリの構築と改修、API連携 | 専任相当1〜2名＋業務オーナー | 3〜6カ月 |
| 3. 基盤の内製 | データ基盤、モデル選定・評価、MLOps、認証・監査基盤 | 専任3名以上＋インフラ・セキュリティ担当 | 1年以上 |
中小・中堅企業が現実的に狙えるのはレベル1〜2です。レベル3はデータ量とシステム連携の規模が相応にあり、専任チームを維持できる企業の選択肢と考えてください。IPA「DX白書」でも、デジタル・AI人材の量的な不足は企業共通の課題として繰り返し指摘されています※1。人が採れない前提で範囲を決めるほうが、計画は現実に耐えます。
内製・外注・SaaS導入の違い比較表
この3つはコスト構造とスピードの前提がまったく違います。どれが優れているかではなく、自社が何を優先するかで選ぶものです。
| 比較軸 | SaaS導入 | 外注開発 | 内製 |
|---|---|---|---|
| 初期コスト | 低い（初期設定のみ） | 高い（要件定義〜構築） | 中〜高（採用・育成が先行） |
| ランニングコスト | ユーザー課金で逓増 | 保守費＋都度の改修費 | 人件費＋API・インフラ費 |
| 立ち上げ速度 | 速い（数週間） | 中（3〜6カ月） | 遅い（体制構築から） |
| 自社業務への適合度 | 低い（業務側を合わせる） | 高い | 高い |
| 改修スピード | ベンダーの開発計画次第 | 都度見積もり・数週間 | 速い（社内判断で着手） |
| ノウハウの蓄積 | ほぼ残らない | 成果物次第で残る | 社内に残る |
| 撤退のしやすさ | 容易 | 中 | 難しい（雇用が残る） |
| セキュリティ統制 | 提供元の仕様に依存 | 要件として指定可能 | 自社で設計できる |
SaaSは速いが業務に合わせられない、外注は適合するが改修のたびに費用と時間がかかる、内製は改修が速いが人材確保が前提。この3すくみが、内製化を悩ませる正体です。
なぜ今「生成AIの内製化」が議論されるのか
生成AIを使った仕組みは、一度作って終わりになりにくいからです。モデルの世代交代、業務ルールの変更、社内ナレッジの追加。この3つが継続的に発生するため、改修が年に数回では済まなくなります。外注のみだと改修サイクルが回りきらない、という声が出るのはここが理由です。
- モデルや料金体系の進化が速く、半年前の設計前提が変わることがある
- プロンプトやナレッジの整備は業務知識そのもので、社外に切り出しづらい
- 精度は大きな作り込みより、小さな改善の積み上げで動くことが多い
とはいえ、内製化そのものが目的化すると本末転倒です。年に1回しか触らない仕組みを内製で抱えるのは、単なる固定費の増加になります。改修頻度が低い領域は、外注やSaaSのままで構いません。
※1 IPA「DX白書」リンク
AIは内製化すべきか外注すべきか？判断する5つの分岐条件
内製化の可否は企業規模では決まりません。業務の変更頻度、社内固有性、データの持ち出し可否、AIを触れる人材の有無、3年総コストという5つの条件で決まります。とくに人材条件を満たさない場合、全内製ではなくハイブリッドを選ぶのが現実的です。まずは判定表で自社の位置を確認してください。
分岐条件5つの一覧（どちらを選ぶかの判定表）
5つの条件を「どちらの状態に近いか」で判定します。3つ以上該当した側が、いまの自社に合う進め方です。
| 条件 | 内製が向く状態 | 外注・SaaSが向く状態 |
|---|---|---|
| ①業務の変更頻度 | 月次〜四半期で運用ルールが変わる | 年単位で業務が安定している |
| ②社内固有性 | 暗黙知・独自帳票・自社用語が多い | 一般的な業務プロセスで代替可能 |
| ③データ要件 | 個人情報や設計データを社外に出せない | 公開情報・一般文書が中心 |
| ④人材 | AIを触れる情シス・エンジニアが1名以上、専任に近い工数を割ける | 担当が兼務で工数を確保できない |
| ⑤3年総コスト | 3年の外注費（改修含む）が人件費を上回る見込み | 案件が年1〜2件で外注費のほうが安い |
③については、社外サービスへ顧客情報や機密データを入力する場合、利用規約と学習利用の有無、委託先管理の考え方を確認しておく必要があります。個人データの取り扱いは個人情報保護法の枠組みに沿って判断してください※2。
内製化が向いている企業の特徴
内製が効くのは、AIを使う業務が自社の競争力に直結し、かつ改修が頻発する企業です。裏を返せば、業務が標準的でツールで代替できるなら、内製化の投資回収は難しくなります。
- 製造業で、見積根拠や図面・仕様書の検索をAIに任せたいケース。品目や工程の追加が続くため改修が絶えない
- 卸売・小売で、需要予測や発注支援を扱うケース。商習慣とマスタの持ち方が自社固有
- 士業・専門サービスで、過去案件のナレッジ検索を扱うケース。文書の構造と判断基準が社内資産そのもの
そしてもう1つ、必須条件があります。AI活用を自分の仕事として引き受ける担当者が、社内に明確に1人以上いることです。「みんなで推進する」体制は、誰も改修しない体制と同義になりがちです。旗を持つ人がいない状態で始めた内製化は、たいてい途中で止まります。
内製化を避けたほうがよいケース
兼務の情シス1人体制、初めてのAI案件、要件が固まっていない段階。この状況での内製化は、うまくいかない確率が高くなります。無理に社内で抱えず、外部を挟んだほうが結果的に早く進みます。
- 担当者が兼務で、AIに割ける工数が全体の20%以下 → 初期構築を外注し、運用ルールの整備だけ社内で担う
- 社内に成果物の品質を評価できる人がいない → 第三者レビューを含む伴走支援を使い、評価軸を先に作る
- 初のAI案件で社内に前例がない → PoC（試作検証）のみ外注し、判断材料を得てから体制を決める
- 「採用できたら始める」計画になっている → 採用を前提にせず、既存メンバーの育成計画に置き換える
自社を5分で判定するチェックリスト
次の10項目のうち、当てはまる数で進め方の目安が付きます。7個以上なら全内製の検討可、4〜6個ならハイブリッド推奨、3個以下なら当面は外注＋伴走が現実的です。
- AIに任せたい業務が、月次以上の頻度でルール変更を伴う
- その業務は自社独自のルールや帳票に依存している
- 扱うデータに、社外に出しにくい情報が含まれる
- 社内にコードを書ける、または読める人がいる
- その人がAIに工数の30%以上を割ける
- 業務側に、要件を決めて意思決定できる担当者がいる
- 3年分の投資として予算を検討できる
- 経営層が内製化の方針を認識している
- すでに生成AIを業務で使った経験が社内にある
- 作った仕組みを他部門にも横展開したい構想がある
7個以上なら本記事の人材要件（次のH2）を、4〜6個ならハイブリッド運用のセクションを、3個以下なら進め方5ステップの「最初に内製化する業務の選び方」から読むと、次の一手が決まりやすくなります。
※2 個人情報保護委員会「個人情報保護法」リンク
AI内製化に必要な人材要件と維持コストはいくらか？
AI内製化には最低4つの役割（業務オーナー／AIエンジニア／データ・インフラ／セキュリティ・ガバナンス）が必要で、専任換算で2〜3名相当になります。人件費だけで年1,500万〜2,500万円規模、これにAPI利用料・インフラ費・改善工数が乗ります。判断すべきは初期費用ではなく、この維持コストです。
AI内製化に必要な4つの役割と人材要件
4つの役割すべてを採用する必要はありません。社内で必ず持つべきは業務オーナーだけで、残りは外部調達や既存人材の兼務で成立します。AI人材の内製化は、全職種を揃えることではありません。
| 役割 | 担当範囲 | 求めるスキル | 社内育成 | 不在時の代替 |
|---|---|---|---|---|
| 業務オーナー | 対象業務の選定、要件の意思決定、効果測定 | 業務知識と社内調整力 | 必須（社内でしか務まらない） | 代替不可 |
| AIエンジニア | アプリ構築、プロンプト設計、精度改善 | API連携、RAG構成、簡易な開発 | 可（情シス経験者で6〜12カ月） | 外部委託・伴走支援 |
| データ・インフラ | データ整備、権限設計、実行環境の運用 | クラウド運用、DB・認証の基礎 | 可（クラウド経験者で代替） | 外部委託・マネージドサービス |
| ガバナンス | 利用ガイドライン、機密情報の判断基準、ログ管理 | 社内規程、法務・情報セキュリティ | 一部可 | 外部支援で規程整備 |
採用・育成にかかる費用と期間の目安
中途採用の場合、生成AIアプリ開発の経験者は求人市場で年収700万〜1,200万円程度の提示が見られ、人材紹介を使えば理論年収の30〜35%の手数料が加わります。社内育成なら、実務投入まで6〜12カ月というのが現実的な見込みです。どちらも幅がありますので、自社の採用実績と照らして調整してください。
- 情シス・開発経験者ルート：API連携、RAGの構成、評価とログ設計を学ぶ。実務投入まで6カ月前後
- 業務部門ルート：プロンプト設計、業務フローの分解、効果測定の設計を学ぶ。3〜6カ月で業務オーナーとして機能
IPA「DX白書」が示すとおり人材不足は構造的です※1。採用が読めない前提なら、既存メンバーの育成を第一選択に置くほうが計画は崩れにくくなります。
見落とされやすい維持コスト（API・再学習・属人化）
内製化の失敗は、初期構築ではなく維持で起きます。作り切った後に発生する費用と工数を、あらかじめ年額で見積もっておいてください。
| 維持コスト項目 | 年額の目安（規模により大きく変動） |
|---|---|
| LLMのAPI・推論費用 | 数十万円〜数百万円（利用者数と処理件数に比例） |
| クラウドインフラ | 数十万円〜（構成と可用性要件による） |
| ベクトルDB等の運用 | 数十万円〜（データ量と更新頻度による） |
| モデル・ライブラリ更新対応 | 年1〜2回の検証工数（数人日〜数十人日） |
| 精度評価と改善の工数 | 継続的に月数人日 |
| セキュリティ監査・棚卸し | 年1回の点検工数 |
ソフトウェアは開発後の保守にも継続的な工数が発生します。規模別の工数実績はIPA「ソフトウェア開発分析データ集」で公開されており、自社見積もりの妥当性を確認する材料になります※3。
金額に表れないリスクが属人化です。作った本人しか構成を理解しておらず、退職と同時に改修が止まる。これは内製化で最も起きやすい事故です。設計書と環境構築手順の文書化、コードレビューを2人以上で回す運用、この2つを最初から入れておくと緩和できます。
内製と外注の3年総コスト比較シミュレーション
初年度は外注が安く、改修や新規開発の件数が増えるほど内製が有利に傾きます。目安として、年3件以上の開発・大型改修が続くあたりが分岐点です。以下は従業員150名、生成AI業務アプリ2〜3本というモデルケースでの試算で、一般的な相場に基づく概算です。
| 1年目 | 2年目 | 3年目 | 3年合計 | |
|---|---|---|---|---|
| 内製（専任1.5名＋API・教育） | 約1,400万円 | 約1,300万円 | 約1,300万円 | 約4,000万円 |
| 外注（初期＋保守＋改修年3件） | 約900万円 | 約700万円 | 約700万円 | 約2,300万円 |
| ハイブリッド（初期外注＋運用内製） | 約1,000万円 | 約800万円 | 約700万円 | 約2,500万円 |
この試算では3年でも外注が下回りますが、改修が年6件、対象業務が5本と増えれば内製が逆転します。自社で計算するなら、次の式で十分です。
- 外注側：年間改修件数 × 1件あたりの外注費 ＋ 保守費（初期開発費の15〜20%が一般的）
- 内製側：専任人件費（社会保険等込み） ＋ API・インフラ費 ＋ 教育費
この2つが交差する件数を出せば、いつ内製に振るべきかが数字で見えます。件数が読めないなら、まだ内製化のタイミングではないという判断もできます。
※1 IPA「DX白書」リンク
※3 IPA「ソフトウェア開発分析データ集」リンク
現実解は「設計は外注・運用は内製」のハイブリッド運用
多くの中堅・中小企業にとって、最適解は全内製でも全外注でもありません。要件定義と初期構築を外注し、運用・改善・横展開を社内で担うハイブリッド型です。重要なのは、内製化率を段階的に上げる前提で、契約と成果物とドキュメントを最初から設計しておくこと。ここを曖昧にすると移管できません。
ハイブリッド運用の3つの型と選び方
ハイブリッドにも型があります。自社の人材状況と展開範囲で選び分けてください。
| 型 | 向く企業 | 内製化までの期間 | 外部費用の掛かり方 | 社内に残るもの |
|---|---|---|---|---|
| ①初期構築外注→運用内製 | 1本目を確実に立ち上げたい。判定4〜6個 | 6〜12カ月 | 初期に集中、以後は保守のみ | 運用手順、改修スキル |
| ②共通基盤は外注・業務アプリは内製 | 複数部門に展開したい。判定7個以上 | 12〜18カ月 | 基盤の初期＋継続保守 | アプリ開発の内製力 |
| ③伴走支援型 | 社内に手を動かせる人がいる | 3〜9カ月 | 月額の支援費が継続 | 設計判断の考え方 |
判定が3個以下だった場合は、まず①で1本作り切る経験を積むのが順当です。いきなり②を狙うと、基盤だけできて誰も使わない状態になりがちです。
責任分界点の決め方と契約・ドキュメントの注意点
ハイブリッドが破綻する原因は、技術力ではなく責任分界の曖昧さです。「運用は御社で」という一文だけで契約すると、障害時に誰が一次対応するのかで必ずもめます。発注前に次の5点を文書で決めてください。
- ソースコード・成果物の著作権と二次利用の範囲（改変・他部門展開が可能か）
- プロンプト・ナレッジデータ・評価データの帰属
- 障害発生時の一次対応者と連絡経路、営業時間外の扱い
- 精度が想定に届かない場合の責任範囲と、再チューニングの費用負担
- 運用移管後の問い合わせ窓口とSLA（対応時間・回数の上限）
契約形態も分けて考えます。仕様が固まった構築は請負、精度改善や運用支援のように成果を保証しにくい領域は準委任が適します。生成AIの精度部分を請負で「保証」させようとすると、ベンダー側は防御的な見積もりになり、費用が跳ね上がります。
内製移管を見据えるなら、納品物の指定も忘れずに。設計書、環境構築手順書、デプロイ手順、評価用データと評価方法、依存ライブラリのバージョン一覧。この5点が無いと、引き継いだ瞬間にブラックボックスになります。
移管を前提にした契約と成果物の決め方、一緒に整理します。hikeに相談する
外注から内製へ移管する（技術移転）の進め方
移管は一括ではなく、運用→改修→新規開発の順で3段階に分けると成功しやすくなります。各段階に「できたと言える基準」を置くのがコツです。
| 段階 | 社内が担う範囲 | 移管完了の判定基準 |
|---|---|---|
| 1. 運用 | 監視、ログ確認、利用者の問い合わせ一次対応 | 障害の一次切り分けを社内だけでできた |
| 2. 改修 | プロンプト調整、軽微な機能追加、データ更新 | 社内メンバーだけで軽微改修をリリースできた |
| 3. 新規開発 | 次の業務アプリの設計・構築 | 外部レビューのみで1本を立ち上げられた |
手段としては、ペアプログラミング、設計レビューへの同席、運用ドキュメントを社内メンバーが書いて外部が添削する形が効きます。資料を受け取るだけの引き継ぎは、ほぼ定着しません。手を動かした範囲しか残らないと考えてください。
AI内製化の進め方5ステップと失敗パターン
内製化は人材採用から始めません。①対象業務の選定 ②小さく作って効果測定 ③運用ルールとガバナンス整備 ④社内展開 ⑤体制と評価指標の定着、の順に進めます。最初の1件は成果の大きさより「社内で回せた経験」を得ることを目的に置くと、2件目以降が加速します。
5ステップの全体像と期間の目安
最初の1件で3〜6カ月、社内展開と体制定着まで含めて12〜18カ月が現実的な目安です。①と③は並行して進められます。
| ステップ | やること | 期間目安 | 社内工数 | 外部支援 |
|---|---|---|---|---|
| ①対象業務の選定 | 候補の洗い出し、効果指標の設定 | 2〜4週間 | 業務側が中心 | あると精度が上がる |
| ②小さく作って測る | 試作、現場テスト、合格基準で判定 | 2〜3カ月 | 週1〜2日 | 推奨 |
| ③ルール・ガバナンス整備 | 利用ガイドライン、入力可否基準 | 1〜2カ月（①②と並行） | 情シス・法務 | 規程は外部支援可 |
| ④社内展開 | 研修、業務フローへの組み込み | 2〜4カ月 | 各部門の推進役 | 限定的 |
| ⑤体制と指標の定着 | KPI運用、改修体制の確立 | 継続 | 専任相当 | レビューのみ |
最初に内製化する業務の選び方（3つの選定基準）
最初の対象は、効果が数値で測れる、失敗しても業務が止まらない、関係部署が少ない。この3条件を満たす業務を選びます。基幹業務の中核から始めると、慎重になりすぎて前に進みません。
- 社内問い合わせ対応：情シス・総務への月間問い合わせ件数と、一次回答までの時間で測る
- 議事録・報告書のドラフト作成：1本あたりの作成時間 × 月間本数で削減時間を測る
- 見積・提案書のドラフト作成：作成リードタイムと差し戻し回数で測る
- 社内ナレッジ検索：探すのにかかっていた時間と、検索の成功率で測る
いずれも生成AIの出力には誤りが混じる前提で、人が確認する工程を必ず残してください。確認を省ける前提で効果を計算すると、現場に出したときに数字が合わなくなります。
内製化がうまくいかない4つの失敗パターンと回避策
典型的な失敗は、人材採用を先行させる、PoCで止まる、情シス1人に丸投げする、効果測定の指標がない、の4つです。いずれも発注や計画の段階で防げます。
- 採用先行：採用してから使い道を考えるため、入社後に活躍の場がない。予兆は「まず人を採る」という計画書。回避策は、対象業務と効果指標を決めてから役割を定義すること
- PoC止まり：試して面白かったで終わる。予兆は合格基準が言語化されていないこと。回避策は、着手前に「精度〇%以上」「1件あたり処理時間〇分以内」など数値の合格基準と、本番移行の判断者を決めておくこと
- 情シス1人に丸投げ：業務側が要件を出さず、システム部門が現場の代弁者になる。予兆は業務部門がキックオフに出てこないこと。回避策は業務オーナーを指名し、評価にも組み込むこと
- 指標なし：効果が説明できず、翌年の予算が付かない。回避策は導入前の業務時間・件数を必ず計測してから着手すること
内製化の進捗を測るKPIとガバナンス整備
内製化の進捗は「作ったアプリの本数」では測れません。社内だけで改修・障害対応ができた割合で測ります。本数は増やせても、外部依存が減っていなければ内製化は進んでいないからです。
- 内製改修率：全改修件数のうち社内だけで完了した割合
- リリースリードタイム：改修依頼から反映までの日数
- 対象業務の削減工数：月間の削減時間、処理件数
- 利用率：対象部門の実利用者数 ÷ 対象者数
- インシデント件数と一次対応時間
あわせて、最低限のガバナンスを整えます。利用ガイドライン、機密情報・個人情報の入力可否基準、ログの保管方針、利用するモデル・ツールの承認プロセス。この4点です。国が示す考え方は経済産業省・総務省「AI事業者ガイドライン」にまとまっており、自社の規程を作る際の下敷きになります※4。
※4 経済産業省・総務省「AI事業者ガイドライン」リンク
まとめ：AI内製化は「どこまで自社で持つか」を決めることから始まる
AI内製化の議論は、やるかやらないかではなく、どこまでを自社に置くかの線引きです。最後に要点を整理します。
- 内製化は利用・開発・基盤の3レベルに分かれ、中小・中堅企業が狙うのは主にレベル1〜2です
- 判断は5つの分岐条件（変更頻度・社内固有性・データ要件・人材・3年総コスト）で行います
- 社内に必ず置くべき役割は業務オーナーで、エンジニアやインフラは外部調達でも成立します
- 比較すべきは初期費用ではなく3年総コストで、改修件数の交差点が分岐点になります
- 現実解は設計・初期構築を外注し、運用と改善を内製するハイブリッドです
次の一手は3つです。まずチェックリストで自社を判定すること。次に、最初の対象業務を1つ選び、効果指標を先に決めること。そのうえで、移管を前提に設計してくれる外部パートナーへ、現状の体制と対象業務を持ち込んで相談することです。判定が4〜6個だった場合、要件定義と初期構築を任せながら運用を社内に移す進め方が、いちばん無理がありません。
よくある質問
AI内製化は何人から可能ですか？
最小構成は、業務オーナー1名＋開発を担える人材1名です。ただしこの規模では、扱えるのは既存アプリの改修と小規模な業務アプリまでと考えてください。複数部門への展開やデータ基盤の運用まで含めるなら、専任2〜3名相当が必要になります。人数を増やせない場合は、範囲を絞るかハイブリッドに切り替える判断が現実的です。
AI人材は採用と育成のどちらが現実的ですか？
第一選択は、既存の情シス・業務担当の育成です。生成AI活用の多くは既存モデルのAPIを組み合わせる領域で、機械学習の研究スキルまでは求められません。開発経験者なら6カ月前後で実務投入が見込めます。採用する場合も、役割を限定して（例：RAGの構築と運用）募集したほうが、要件と処遇の設計がしやすくなります。
生成AIの内製化と、AIのスクラッチ開発は何が違いますか？
必要なスキルが違います。生成AIの内製化は既存モデルの活用が前提で、プロンプト設計、社内データの整備、API連携、評価設計が中心になります。モデルを一から学習させるスクラッチ開発は、大量の学習データと機械学習の専門人材、計算資源が必要です。多くの業務課題は前者で足ります。
AI内製化に使える補助金はありますか？
時期によりますが、IT導入補助金やものづくり補助金などが対象となる場合があります※5。ただし補助対象経費の範囲や要件は年度ごとに変わり、人件費が対象外となるケースもあります。制度を前提に計画を組む場合は、必ずその年度の最新の公募要領で要件と締切を確認してください。
ノーコード・ローコードだけで内製化できますか？
レベル1（利用の内製）と、レベル2の一部までは可能です。社内チャットや簡易な文書生成であれば、開発者がいなくても形になります。限界が出るのは、既存の基幹システムとのデータ連携、権限の細かい制御、監査ログの要件がある場合です。この3つが要件に入った時点で、開発の知見が必要になります。
外注したシステムを後から内製化できますか？
可能ですが、契約時の準備次第です。ソースコードの著作権と二次利用の範囲、設計書と環境構築手順書の納品、データとプロンプトの帰属。この3点が契約で確保されていないと、移管の段階で追加費用と交渉が発生します。将来の内製化を少しでも考えているなら、初回契約の時点で明記しておいてください。
内製化にはどのくらいの期間がかかりますか？
最初の1件を作り切るまでで3〜6カ月、社内で改修が回る体制が定着するまで12〜18カ月が目安です。この幅は、業務オーナーの工数と、対象業務のデータ整備状況で大きく動きます。データが紙やバラバラのExcelに散っている場合、整備だけで数カ月かかることもあります。
内製化したのに現場で使われない場合はどうすればよいですか？
利用率をKPIとして計測し、使われていない理由を現場に聞くところからです。多くは「既存の業務フローの外側に置かれている」ことが原因になります。使う手間が現状より増えていないか、入口が普段使うツールの中にあるか、この2点を確認してください。機能を足すより、業務フローへの組み込み方を変えるほうが効くケースが目立ちます。
※5 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク