「AIで内製できますよ」と言われた経営者が、最初に決めるべきこと

こんにちは、大平です。

最近、経営者の方から「AIを使えば、これまで外注していたシステムも社内で作れますよね？」と相談されることが増えました。

たしかに、作れる範囲は大きく広がっています。以前なら開発会社へ依頼していた業務ツールでも、社内メンバーがClaude CodeやCursorを使い、数日で初期版まで作れるケースは珍しくありません。外注費を減らし、改善速度も上げられるなら、内製化へ動きたくなるのは自然です。

ただ、経験上はっきり言うと、「社内で作れた」と「会社として内製できた」は別の状態です。

デモが動いた瞬間には見えませんが、システムには問い合わせ、権限変更、データ修正、外部サービスの仕様変更、障害対応が続きます。その仕事を誰が引き受けるのか決まっていなければ、内製化ではなく、開発した個人への依存が始まっただけです。

経営者が最初に決めるべきなのは、使用するAIツールでも、作る機能でもありません。 作ったあとに誰が運用責任を持つのかです。

内製化の本番は、リリースした翌日から始まる

AIを使った開発では、最初の画面が驚くほど速く出てきます。ログインできる、データを登録できる、一覧で確認できる。この段階まで来ると、プロジェクトはほとんど終わったように見えます。

しかし、会社がシステムを使い始めるのはその後です。

利用者から「このデータだけ直したい」と連絡が来る。組織変更で閲覧権限を変える必要が出る。連携先のAPIが更新され、昨日まで動いていた処理が止まる。業務ルールが変わり、当初の仕様では処理できない例外が生まれる。

こうした変化は、プログラムの不具合とは限りません。事業と組織が動いている以上、避けられない変化です。

外注していたときは、保守契約や追加発注という形で、開発会社が変化を受け止めていました。内製化すると、その受け皿も社内へ移ります。初期開発の工数だけを比較して「内製の方が安い」と判断すると、この移ってきた仕事が見積もりから抜けます。

内製化のコストは、コードを書く時間だけではなく、変化を受け止め続ける体制の費用です。

運用責任者は「何でも直せる人」ではない

では、運用責任者には高度なエンジニアを置かなければならないのでしょうか。

必ずしもそうではありません。運用責任者に必要なのは、すべての障害を一人で直す能力ではなく、問題が起きたときに判断を止めないことです。

少なくとも、次の四つを引き受ける必要があります。

受付：問い合わせや障害情報を、誰が最初に受け取るか
判断：今すぐ直すのか、回避策でしのぐのか、利用を止めるのか
手配：社内で直せない場合、誰へ依頼し、どの予算を使うか
記録：変更した理由と、次に同じ問題が起きたときの手順をどこへ残すか

ここで必要なのは、役職名ではなく権限です。「詳しそうだから」という理由で担当者を置いても、優先順位を変える権限も、外部へ依頼する予算もなければ責任を果たせません。

逆に、責任者自身がコードを書けなくても、技術担当者や外部パートナーへ適切につなぎ、事業側の判断を出せるなら運用は回せます。内製化を一人のスーパーマン探しにしてしまうと、その人が新しい属人化の中心になります。

作れる人と、直し続けられる組織は違う

AIによって増えたのは、初期版を作れる人です。一方で、直し続けるために必要な仕事は、初期実装より広いまま残っています。

既存データとの整合性を確認する。障害の原因をログから調べる。セキュリティ更新を適用する。利用者へ影響を説明する。変更によって別の業務が壊れないか確かめる。

これらは、AIへ依頼すれば一部を速くできます。それでも、どの状態を正しいとみなすか、どのリスクを許容するかは会社側で決めなければなりません。

たとえば、AIがデータ修正用のSQLを作ることはできます。しかし、その修正を本番環境で実行してよいか、顧客への説明が必要か、監査記録をどう残すかまでは、会社の事情を知らなければ決められません。

つまり、AIが実装を引き受けても、判断の責任は消えません。むしろ実装が速くなった分だけ、会社は短い時間で多くの判断を求められます。

社内に残すべきなのは、コードより業務判断である

「内製化」を「すべてのコードを社員が書くこと」と捉えると、必要な採用人数も教育コストも大きくなります。しかし、内製化の目的は外部の力を一切借りないことではありません。

社内に残すべきなのは、次のような事業固有の判断です。

どの顧客課題を先に解くか
自社の業務ルールをどうシステムへ反映するか
どのデータを正しいものとして扱うか
どのリスクまで受け入れるか
何を満たせばリリースできるか

この判断を社内が持っていれば、実装の一部を外部へ頼っても主導権は失いません。反対に、コードだけ社内で書いていても、仕様と優先順位を外部の提案に依存しているなら、事業の中核は内製できていません。

僕は、AI時代の内製化を「実装を社内へ戻すこと」ではなく、「事業判断を社内で更新できる状態にすること」だと考えています。

この定義なら、AI、SaaS、開発会社を使うことと内製化は矛盾しません。外部の専門性を使いながら、自社にしか決められないことを自社で決める。その方が、限られた人員を会社の強みに集中させられます。

担当者が異動した翌朝に、内製化の実力が出る

営業部の担当者がAIを使い、顧客情報を整理する社内ツールを作ったとします。

入力作業は減り、チームの評判もよい。小さな修正も担当者がその場で入れられる。外注費もかからないので、内製化は成功したように見えます。

ところが、その担当者が別部署へ異動することになりました。

そこで初めて、デプロイ方法を本人しか知らないことが分かります。外部APIの契約は個人のアカウントにひもづき、エラー通知も本人のメールアドレスへ届いています。どの項目を営業部が編集してよいのか、判断理由も残っていません。

この状態で新しい担当者を置いても、すぐには運用できません。コードを読む前に、契約、権限、業務ルール、過去の判断を発掘する必要があるからです。

問題は「担当者が異動したこと」ではありません。異動しても引き継げる形に、会社が仕事を変えていなかったことです。

内製化の実力は、作った本人がいるときには分かりません。本人が休んだ日、異動した日、障害が起きた日に初めて見えます。

全部を抱えないための三段階ロードマップ

内製化は、外注から内製へ一度に切り替えるイベントではありません。責任範囲を移していくプロセスです。

現場では、次の三段階に分けると進めやすくなります。

外部と一緒に土台を作る 最初は、設計、権限、監視、デプロイ、復旧手順を外部の経験者と整えます。この段階から社内の運用責任者を置き、判断理由と手順が社内に残るようにします。
小さな変更を社内で回す 文言変更、設定変更、小さな業務ルールの追加など、失敗しても影響が限定される変更から社内へ移します。外部パートナーは実装者ではなく、レビューと緊急時支援へ役割を変えます。
事業の中核を社内で判断する 顧客価値や競争優位に直結する仕様は、社内が優先順位と受け入れ条件を決めます。実装手段はAIや外部を使っても、何を作り、どの状態なら出せるかは社内で完結させます。

この順番なら、社内は実際の運用を通じて必要な能力を学べます。最初からすべて抱えた場合のように、開発、採用、教育、障害対応が同時に立ち上がることも避けられます。

最初の90日で「会社が持てる状態」を作る

最初の30日は、すでに社内で動いているツールを棚卸しします。利用者、運用責任者、扱うデータ、外部サービス、認証情報、問い合わせ先を一覧にしてください。

責任者が空欄のものは、止まったときの影響を確認し、影響が大きい順に責任者と復旧手段を決めます。

次の30日は、一つのツールだけを選び、作った本人以外が変更と復旧を試します。手順書によるデプロイ、認証情報へのアクセス、エラー通知、ロールバックを一度通します。

そこで止まった箇所が、会社へ移せていない知識と権限です。新しいドキュメントを大量に作るより、実際に引き継いで止まった場所を直す方が効きます。

最後の30日は、社内で持つ範囲と外部へ頼る範囲を決めます。通常の改善は社内、インフラ障害は外部、権限変更は責任者の承認付きというように、人員とリスクに合わせて境界を引きます。外部支援の連絡先と予算も、この時点で確保します。「必要になったら探す」では、障害が起きた日に間に合いません。

90日後に目指すのは、すべてを社内だけで直せる状態ではありません。 問題が起きたとき、誰が判断し、誰へ頼み、どう戻すかを会社が説明できる状態です。

投資効果は、外注費の削減だけで測らない

内製化の企画では、「年間の外注費をいくら減らせるか」がROIとして置かれがちです。

しかし、外注費だけで評価すると、社内メンバーの運用時間、教育、採用、レビュー、障害対応が見えなくなります。請求書がなくなった代わりに、複数の社員が本来業務の合間に対応しているなら、会社全体のコストは下がっていない可能性があります。

内製化の価値には、改善までの時間短縮、業務知識の蓄積、小さな検証を自社の都合で回せることも含まれます。経営会議では外注費だけでなく、改善のリードタイム、社内で完結できた変更の割合、障害から復旧するまでの時間も追うべきです。

内製化が成功している会社は、外注費がゼロの会社ではありません。 事業に必要な変更を、自社の判断で止めずに進められる会社です。

内製化を始める前の五つの問い

内製化の対象を決める前に、最低限、次の五つへ答えてみてください。

運用責任者を個人名で言えるか
問題が起きたとき、利用停止か継続かを誰が決めるか
本番環境へ反映し、問題があれば戻せる人がいるか
アカウント、権限、外部サービスの契約を会社で管理しているか
社内で持たない領域を、誰にどの条件で頼るか

すべてに即答できなくても構いません。ただし、未定の項目を未定のまま開発へ流すと、その判断は作った人へ集まります。

AIはコードを生成できます。運用責任者を任命し、予算を割り当て、障害時の優先順位まで決めてはくれません。

その仕事は、経営側に残ります。

まとめ

最初に決めるのは運用責任者：内製化は、作った後の問い合わせ、変更、障害対応まで社内へ移す判断です
社内に残すのは事業固有の判断：実装にAIや外部を使っても、優先順位、業務ルール、受け入れ条件は社内で持ちます
外部支援を移行に使う：設計やレビューを借りながら、引き受けられる責任を一段ずつ増やします
外注費以外の指標も追う：改善のリードタイム、復旧時間、社内で完結できた変更の割合で効果を見ます

AIで作れる範囲は、これからも広がります。デモを作った人が席を外しても、会社として運用を続けられるか。内製化を始める前に、まずこの問いへ答えてみてください。