内製化という言葉が、二つの違うことを指している

AIで開発が速くなり、社内でもシステムが作れるようになる。だから外注をやめて内製化しよう。この話が、ここ一年で急に増えました。急に、です。

半分は正しいと考えています。自社で持つべき領域は、確実に広がりました。

ただ、データは逆のことも示しています。MITの研究プロジェクト「NANDA」のレポートによれば、外部パートナーと組んだ導入の成功率が約67%であるのに対し、社内だけで作った場合の成功率は約33%。内製は外部連携の2倍つまずきやすい、と読めます。

The GenAI Divide: STATE OF AI IN BUSINESS 2025（MIT Project NANDA, 2025）
https://www.artificialintelligence-news.com/wp-content/uploads/2025/08/ai_report_2025.pdf

外注をやめた会社が、そのぶん速くなっているわけではありません。むしろ逆のことが起きています。

この記事では、この矛盾を解いたうえで、どこを抱えてどこを任せるべきかの線の引き方を書いてみます。

「内製化」が指している二つのこと
抱えるべき三つ、任せてよい三つ
ベンダー依存が生まれる本当の理由
任せ方を変えるだけで、依存は減る
人を採るなら、何を基準に採るか
手を離すタイミングの決め方
契約の形を、何で選ぶか
北海道では、そもそも選択肢が少ない
最後に

1. 「内製化」が指している二つのこと

議論が噛み合わない原因は、言葉の指す範囲が人によって違うことにあります。混ざっています。内製化という一語には、次の二つの意味が入り込んでいます。

ひとつは、作るのを自社でやるという意味。コードを書く、設定する、仕組みを組み立てる。ここを社内の人員でやる、という意味です。手を動かす話です。

もうひとつは、決めるのを自社でやるという意味。何をどこまで自動化するか、どの判断を人に残すか、合格ラインをどこに置くか。この判断を自社で持つ、という意味です。

経営者が内製化したいと言うとき、本当に欲しいのは後者であることがほとんどです。ベンダーの言いなりになりたくない。何が起きているか分からないまま費用を払い続けたくない。こうした不満は、実装を外に出していることからではなく、判断を外に預けてしまっていることから生まれています。

ところが実際に進めると、話は前者にすり替わります。人を採る、ツールを導入する、開発体制を作る。そして、採った人が辞めて止まる。よくある結末です。

前者ができなくても、後者は持てます。そして成果を分けるのは後者です。分けて考えるだけで、議論はかなり整理されます。

2. 抱えるべき三つ、任せてよい三つ

具体的に線を引きます。

抱えるべきものの一つめは、業務の記述。自社の業務がどう流れ、どこで何を判断しているか。この記述は、外部には書けません。正確には、聞き取って代筆する役は外部でも担えますが、中身を知っているのは社内の人だけです。ここを外に預けると、ベンダーが変わるたびに一から説明し直すことになります。損失が最も大きい部分です。

二つめは、合格ラインの決定。どこまでできれば使えるとするか。この判断は、業務に責任を持つ人にしかできません。ベンダーの立場からは「技術的には可能です」としか言えず、それを採用するかどうかの線引きまでは踏み込めないからです。

三つめは、持ち主。運用後に手を入れ続ける人。ここを外に出すと、業務が変わったときに自社で何もできなくなります。

任せてよいものの一つめは、技術選定。どのモデルを使うか、どう構成するか。この領域は変化が速すぎて、専門にやっていないと追えません。半年で前提が変わります。無理に自社で判断しようとすると、半年前の情報で今期の投資を決めることになり、それはそのまま負債になります。

二つめは、最初の立ち上げ。ゼロから一本目を作る工程は、経験の差がそのまま出ます。よくある失敗のパターンを事前に知っているかどうかで、同じものを作るのにかかる時間が3倍変わります。ここは買ったほうが安い。

三つめは、詰まったときの切り分け。うまく動かないとき、原因がモデルの限界なのか、渡した指示書の書き方なのか、そもそも渡すべきでない業務だったのかを判断する作業です。見分けるには、失敗例を何十件も見た経験が要ります。社内だけでやろうとすると、直しようのない問題に何週間も時間を溶かすことになります。

整理すると、業務と判断は抱え、技術と立ち上げは任せる。これが現実的な線です。

3. ベンダー依存が生まれる本当の理由

依存の構造を見ておきます。

依存は、外注したから生まれるものではありません。抱えるべき三つを外に出したときに生まれます。そこだけです。

典型的な形はこうです。自社の業務を書き起こす作業をベンダーが引き取る。合格ラインもベンダーが提案する。運用後の修正もベンダーに依頼する。この状態になると、自社には何も残りません。切った瞬間に止まります。

逆に、業務の記述が自社にあり、合格ラインを自社で決め、持ち主が社内にいれば、ベンダーは交代可能になります。実装を外に出していても、依存はしていない。

中小企業基盤整備機構の調査では、「適切なベンダーや製品を選定する情報が十分にある」に当てはまらないと答えた企業が79.8%にのぼっています。

中小企業のAI等の利活用に係る実態調査（中小企業基盤整備機構、2026年3月／n=1,647）
https://www.smrj.go.jp/research_case/questionnaire/fbrion0000002pjw-att/202603_AI_point.pdf

選ぶための情報がない状態で選んでいる。だから当たり外れが大きくなり、しかも一度当たりを引いてしまうと、他に替える判断材料がないまま、その一社への依存だけが深まっていきます。

この構造を抜けるには、ベンダーを見る目を養うより先に、自社に何を残すかを決めるほうが確実です。残すものが決まっていれば、外れを引いても致命傷になりません。

4. 任せ方を変えるだけで、依存は減る

契約の仕方で変えられる部分もあります。四つ挙げます。

書き起こしたものを、自社の文書として受け取る。ベンダーが作った要件定義書や設計書を、納品物として自社の形式で受け取る。相手のツールの中に置かれたままだと、持ち出せません。

設定内容を、読める形で残してもらう。AIに渡している指示書やルールは、プログラムではありません。文章です。読めるはずなので、「ブラックボックスなので」と言われたら、そこは交渉する価値があります。

運用の最初の3か月、横で見せてもらう。修正作業を、自社の担当者が横で見る。やってもらって終わりにせず、手元を見る。これだけで、半年後には自分で触れるようになります。

手を離す時期を、契約に書いておく。「6か月後に、運用を自社に移管する」と最初に決めておく。決めておかないと、ずっと同じ体制が続きます。移管しない理由など、お互いにいくらでも作れてしまうからです。

私たちが伴走型という形を取っているのは、この四つを前提にしているためです。作って納めて終わり、という形だと依存が残ります。

5. 人を採るなら、何を基準に採るか

実装の内製化を選ぶ場合、採用の話になります。ここで基準を間違えると、高い給与を払って成果が出ない状態になります。

採ってはいけないパターンは、「AIに詳しい人」を基準に採ることです。技術の知識は半年で陳腐化します。そして、業務を知らない技術者は、何を作るべきかを自分では決められません。結果、指示待ちになり、指示を出せる人が社内にいないので止まります。

採るべき人の条件は三つ。現場のヒアリングができること。現場に入って、話を聞いて、構造化して書き出せる。この能力は、技術力より希少です。手を動かして形にできること。完璧でなくていい。粗くても、2日で動くものを見せられる。議論が一気に進みます。そして、分からないことを調べ続けられること。技術は変わります。いま知っていることより、変化を追い続けられるかのほうが重要です。

この三つを兼ね備えた人は、市場では取り合いになっています。採用が難しければ、社内の業務に詳しい人に技術を足すほうが現実的です。現場の理解はゼロからでは身につきませんが、技術は学べます。順序としては、こちらのほうが成功率が高い。

採用しないという選択も、十分に合理的です。従業員50名の会社でAI専任を1名採るコストと、外部に月数回入ってもらうコストを比べると、後者が安いことがほとんどです。専任を置くのは、対象業務が5つ10つと増えてからで足ります。

6. 手を離すタイミングの決め方

いつ自走に切り替えるか。判断の目安を三つ置きます。

自社の担当者が、設定を1回自力で変えられた。小さな変更で構いません。例外ルールを1つ追加する、出力の形式を変える。自力でできれば、手は離せます。

失敗したときに、原因の切り分けができた。入力データが悪い、指示書の書き方が足りない、そもそも渡すべき仕事ではなかった。この三つを区別できるようになれば、ほぼ自走できます。

二件目の対象を、自社で選べた。一件目はこちらが提案したとしても、二件目を自社で選べるようになったら、判断の内製化は完了しています。

この三つが揃うのに、だいたい6か月から1年。それまでは、外部が横にいたほうが速い。実感としてはそうです。

7. 契約の形を、何で選ぶか

外に出す場合、契約の形でも結果が変わります。よくある三つを比べます。

一括請負は、作るものがはっきりしている場合に向いています。仕様が固まっていれば、費用も期間も読めます。向いていないのはAI活用の立ち上げ期で、何を作るべきかが検討の中にある段階で仕様を固定すると、途中で分かったことを反映できません。変更のたびに追加見積になり、関係がぎくしゃくします。

準委任・月額は、立ち上げ期に向いています。走りながら方向を変えられる。一方、成果の定義が曖昧だとだらだら続く危険があります。対策は単純で、3か月ごとに区切って継続の可否を判断すると最初に決めておくこと。区切りがあれば、だらだらは防げます。

スポットは、ある程度自走できるようになってからの形です。月2回、詰まった点だけを一緒に見る。費用は最も軽い。ただし立ち上げ期にこれを選ぶと進みません。相談する内容を自分で整理できる段階に来ていないと、スポットの時間は質問の交通整理で終わります。

順番としては、準委任で立ち上げてスポットに移行するのが王道です。一括請負は、作るものが確定した後の本番開発で使う。この使い分けを知らずに立ち上げから一括請負で入ると、ほぼ確実に揉めます。

そして、どの形であっても、第4章の四つ、つまり記述を自社形式で受け取る、設定を読める形で残す、修正を横で見る、移管時期を書いておくは共通して契約に入れておくべきです。契約形態より、この四つのほうが依存を左右します。

提案を受けるときに聞くとよい質問も挙げておきます。失敗した案件の話を聞かせてください。答えられない相手は、経験が浅いか、都合の悪い話をしない相手のどちらかです。運用は誰がやる想定ですか。「弊社が」としか答えない場合、依存する設計になっています。やめたほうがいい部分はありますか。全部やりましょう、と言う相手は危ない。対象業務の中には、AIに向かない部分が必ずあります。3か月後に解約したら、何が手元に残りますか。答えが「何も」なら、その契約は結ばないほうがいい。

8. 北海道では、そもそも選択肢が少ない

道内の中小企業にとって、この議論にはもう一つ現実的な制約が乗ります。選べるベンダーが少ない。

札幌にはIT企業が集積していますが、その多くは首都圏の案件を請けており、道内中小企業向けのAI活用支援を主力にしている会社は多くありません。旭川、釧路、帯広、函館まで行くと、地元で相談できる先はさらに絞られます。

結果として、東京のベンダーに頼むか、自社だけでやるかの二択になりがちです。前者は提案が大企業向けの体制論になりやすく、金額も合いません。移動コストも乗ります。後者は、冒頭のデータが示すとおり成功率が下がる。どちらも分が悪い。

この状況で現実的なのは、抱える範囲を広めに取り、任せる範囲を狭く深く使うという配分です。書き起こしと判断は完全に自社で持つ。そのうえで、技術選定と立ち上げ、詰まったときの切り分けだけを、月数回のスポットで外に出す。

十勝のある農機具販売会社では、当初「全部お願いしたい」という相談でした。ただ、従業員25名の会社に常駐で入る体制は費用が合いません。そこで、業務の聞き取りと指示書づくりを社内の担当者がやり、月2回のオンラインで詰まった点だけを一緒に解く形に切り替えました。立ち上がりは3か月遅れましたが、1年後には追加の相談なしで二件目を自分たちで立ち上げています。

道内企業にとっての内製化は、本州の大企業が言う「開発部門を持つ」とは意味が違います。判断を手元に置き、技術だけを外から薄く借り続ける。この形が、人も予算も限られる地域では最も続きやすいと考えています。

9. 最後に

内製化という言葉を聞いたとき、まず「どちらの意味ですか」と確認するところから始めるのがいいと思っています。

作るのを自社でやりたいのか。決めるのを自社でやりたいのか。

後者であれば、外注をやめる必要はありません。むしろ、適切に任せたほうが速い。抱えるべき三つ、つまり業務の記述、合格ラインの決定、持ち主さえ社内に置いておけば、実装をどれだけ外に出していても、依存という状態にはなりません。

外注か内製か、という二択の問題ではありません。どこに線を引くか。考えるべきはそこだけです。

Blakistonでは、北海道の企業のAI活用について、業務の棚卸しから定着までのご相談を承っています。