内製化の判断基準。作る・買う・作らないと止まった日の担当

内製化とは、外部に委託していた開発や運用を自社に戻し、自分たちで行うことです。AIで作れるようになった今、内製化するかどうかを分けるのは「作れるか」ではありません。分けるのは、その仕組みが止まった日に、誰が顧客の前に出て説明するかが決まっているかどうかです。この記事では、業務を作る・買う・作らないに仕分ける基準と、稼働前に決める保守の持ち主を書きます。

僕はAIVESTという会社を経営していて、自分でも社内の業務アプリを作って動かしています。同時に、AI顧問や受託の立場で「これは内製でいけますか」という相談を受ける側でもあります。

2026年9月時点で「内製化」の検索上位は、定義・メリット・デメリット・外注との比較・進め方まで丁寧に扱っています。ただ、判断基準として挙がるのは「コア業務かどうか」「コストが適正か」といった抽象的な項目までで、保守を誰が持つか、止まった日に誰が顧客対応をするか、担当者が抜けた後にどう引き継ぐかは見当たりませんでした。この記事はそこだけを書きます。

内製化とは。社内システムを内製する判断は「作れるか」では決まらない

内製化（ないせいか）は、英語ではインソーシング（insourcing）と言います。反対語はアウトソーシング、日本語では外注・外部委託。言い換えるなら自社開発、自前化、内製で、どれもほぼ同じ意味で使われています。

社内システムの内製化には、新しく作ることと、作った後に動かし続けることの2つが含まれます。この記事では後者まで含めて内製化と呼びます。

AIが安くしたのは「作る」の値段だけ

ここ2年で変わったのは、作る工程の値段です。以前なら見積もりを取って数か月かかっていた社内の小さな仕組みが、数日で動くようになりました。

一方で、動かし続ける工程の値段は下がっていません。 脆弱性の連絡は変わらず来ますし、外部サービスの仕様変更も、業務側の「この項目も足して」も、以前と同じ頻度で来ます。

内製化の判断がずれるのは、安くなった「作る」の値段だけを見て、下がっていない「持ち続ける」の値段を見ないからです。

作った直後がいちばん危ない、というのが僕の実感です。動いた画面を見た瞬間に、これなら全部内製でいけると思ってしまう。そこで判断を止めるために、質問を1つだけ使っています。

なぜ内製化の決め手が「止まった日に誰が顧客の前に出るか」なのか

外注の見積もりには「作る」以外のものが入っていました。障害が出たときの窓口、復旧までの責任、担当者が変わったときの引き継ぎです。金額としては見えにくいのですが、契約の中に人が含まれていました。

内製化しても、この人の役目は消えません。社内の誰かに移ります。誰に移るかを決めていないと、作った本人に自動で降ります。

判定は質問1つで足ります

この仕組みが明日の朝止まったとき、顧客や取引先に説明しに行く人の名前を、今この場で言えるか。

言えないなら、その業務はまだ内製化の対象外です。技術的には作れるけれど誰も名前を書けない、という業務はたくさんあります。

名前が言えると、話が具体になります。その人は復旧の見込みを言える立場か。夜間や休日に連絡がつくか。辞めたら次は誰か。ここまで決まって初めて、内製化の判断に入れます。

「作った人＝止まった日に出る人」で始めない

最初は作った本人が対応するのが自然です。危ないのは名前欄に作った人を書くことではなく、名前欄そのものを作らないことです。属人化した業務を止めずにしのぐ設計は、属人化は引き継ぎ書では解消しない。72時間しのぐ代替1本に分けて書きました。

業務を「作る・買う・作らない」に仕分ける。基準は工数ではなく停止許容時間

内製化の話は、たいてい「内製か外注か」の2択で進みます。ここに3つ目を足します。作らない、つまり業務ごとやめるか、手作業のまま置く判断です。月1回しか発生せず、止まっても誰も困らない作業に仕組みを建てると、使う頻度より保守の頻度のほうが多くなります。

仕分けの軸を工数からずらす

よくある仕分けの軸は、工数・コスト・人材です。この軸だと「AIで作れば工数が小さいから内製」という結論にしかなりません。作る工数が小さいことは、持ち続けられることの理由になりません。

そこで軸を停止許容時間に置き換えます。その業務が止まったとき、何時間までなら本業が回るか。単位は時間です。

4ステップで埋めます

埋め終わったら3択に落とす

3行のうち、いちばん多く当てはまるのは真ん中です。それでいいと思っています。業務を書き出すところでつまずく場合は、AIに任せてよい業務の棚卸しワークシートに記入式の判定表を置いています。

内製に回してよいのはどこまで？「半日止まっても本業が回る業務」まで

僕が自分の運用で置いている線は、半日（およそ8時間）止まっても本業が回る業務までです。

半日という線の出どころ

先に断っておくと、これは計測値ではなく僕の運用上の線です。内訳は2つあります。1つ目は気づくまでの時間で、自分で保守している仕組みが止まったとき、気づくのは次に結果を見に行ったときです。朝止まって夕方気づく、が現実的な幅でした。

2つ目は直すまでの時間。原因が自分の変更なら戻せば済みますが、外部サービス側の変更だと、調べて直して確かめるまでに半日は見ておく必要があります。

この2つを足すと、内製で持てるのは「半日止まっても誰も損をしない業務」までになります。社内の人が待てる業務か、で線を引くのが実務的です。

停止許容時間は自分で決めない

やりがちなのが、作る側が停止許容時間を決めてしまうことです。短く見積もりがちですし、逆に「まあ1日くらい平気でしょう」と長く見積もることもあります。

半日を超える業務は、層で切って一部だけ内製する

停止許容時間が2時間の業務でも、まるごと諦める必要はありません。下書きを作る部分だけ内製し、確定・送信・記帳は既製サービスや人に残す、という切り方ができます。僕が社内で内製しているものも、ほとんどがこの形で、最後の1クリックは人が押します。

顧客・取引先に見える系と、入金・在庫に触る系は対象外に置く

停止許容時間とは別に、時間に関係なく対象外にしている領域が2つあります。

外に出ている画面は内製の対象外に置く

顧客が自分で開く画面、取引先に届くメールやファイル、予約や申し込みの受付。ここが止まると、止まっている事実そのものが社外に見えます。

社内の仕組みなら「今日は手でやります」で済みますが、外向きの画面は代替手段がその場にありません。内製の対象は、間違えてもやり直せる業務に限ります。

入金・在庫・請求は戻せない

もうひとつは、お金とモノに触る系です。二重請求、二重出荷、在庫数のずれは、謝罪では元に戻りませんし、取引先の帳簿側にも記録が残ります。

やり直せるかどうか（可逆性）は、内製の可否を分ける現実的な線です。下書きの生成はやり直せます。送信と確定はやり直せません。

内製してよいのは、やり直せる側の工程まで。 この線を引いておくと、AIで作れる範囲が広がっても判断がぶれません。非エンジニアが作ったツールを業務に載せてよいかの線引きは、非エンジニアが作った社内ツールを業務に載せてよいかの判断に書いています。

システム保守の持ち主を稼働前に決める5項目

システム保守とは、動き始めたシステムを止めずに使い続けるための仕事全般のことです。内製化の相談で抜けやすいのが、この保守の持ち主を稼働前に決めることです。稼働してから決めようとすると、だいたい決まりません。困っている最中に持ち主を決める会議はできないからです。

稼働前に書く5項目

1. 脆弱性の連絡を誰が受けるか。使っている部品に問題が見つかったとき、その知らせが届く先を1人決めます

2. 更新を誰がいつ当てるか。外部サービスや部品の更新は、当てないと動かなくなる日が来ます。月1回など、当てる日を先に決めます

3. 業務の仕様変更を誰が直すか。項目が増えた、区分が変わったという依頼の窓口です。空欄だと、依頼は作った人の個人チャットに来ます

4. 作った人が抜けた日に誰が持つか。動かし方が1枚にまとまっているか、入口のURLが共有されているかも書きます

5. 壊れたときの連絡先が画面にあるか。使う社員が「動かないときはこの人へ」を画面から読めるかどうかです

この5項目のうち3つ以上が空欄なら、その業務は内製ではなく買う側に倒します。作れるかどうかとは別の判断です。

内製すると「生かすための仕事」が増えます

2026年9月16日時点で、僕の作業環境に登録されている自社用の常駐ジョブ（決まった時刻に自動で立ち上がる仕組み）は51本です。実際に数えた本数で、9月10日に数えたときの47本から4本増えています。

このうち7本は、業務の成果物を1つも作りません。毎朝の動作確認、外部サービスとの接続の生存確認、止まったジョブの再起動、状態の退避、退避したものの世代管理。他の44本を生かし続けるためだけに走っているジョブです。

内製化を検討するとき、この7本ぶんの仕事は見積もりに出てきません。作る工数の見積もりには、生かし続ける工数が含まれないからです。作ったものを「運用している」と言える状態かの判定は、別の記事に分けています。

関連記事AIで自作した社内ツール、「運用している」と言える3段階AIで自作した社内ツールは、作ったことと運用していることが別の状態です。自分が見ている間だけ動く、社員がURLを開いて使える、主管が決まっている、の3段階で今どこかを判定し、段を上げる最小条件を自社の実物つきで解説します。→

買う場合のSaaS費用と、内製の見えないコスト（保守時間）の比べ方

内製か購入かの比較が内製に倒れやすいのは、比べ方のせいです。片方は月額という数字で出ていて、もう片方は自分の時間なので数字になっていません。

保守時間を入れて同じ単位に置き直す

やることは単純で、内製側の「保守時間」を0でなく数字で埋めるだけです。月2時間で見積もるなら年24時間。自社の時間単価が5,000円なら年12万円。この金額とSaaSの年額を並べます。

保守時間をゼロで置いた比較は、必ず内製が勝つように作られています。

初期見積もりは「作った時間の2割」から

初めて内製するときは実績がないので、僕は作るのにかかった時間の2割を年間の保守時間として置いて始めます。これも計測値ではなく出発点の数字で、1年回して実績が出たら差し替えます。大事なのは正確さではなく、0以外の数字が入っていることです。

生成AIそのものの料金の比べ方は生成AIの料金比較。業務で使うときの月額と従量課金の考え方、社内ChatGPTのように導入形態が複数ある場合は社内ChatGPTの導入形態と費用の考え方に分けています。

業務アプリを毎日動かしている側から言えること

僕の会社では、業務アプリと自動化の仕組みをほぼ内製しています。そのうえで、内製を選ぶなら先に決めておくとよかったと思うことが3つあります。

1. 検収を人の目でなく機械に持たせる

自分で作って自分で確認すると、基準がその日の体調で動きます。僕はブログの記事を公開する前に、機械が判定するチェックを必ず通す形にしています。見出しの数、本文の長さ、内部リンクの有無、リンク先が実在するか。1つでも欠けると公開の手順に進めません。

さらに、公開済みの記事に上書きしようとすると、手元の仕組みが公開済みの一覧と突き合わせて止め、サーバー側でも拒否します。片方が静かに失敗した日のために二重にしてあります。自分で作った仕組みほど、自分を止める側の仕掛けを先に入れておくと後が楽です。

2. 失敗の記録を消さない

2026年9月16日時点で、僕のブログ運用の失敗記録には2行残っています。2026年9月9日に記事の投稿がサーバー側のエラーで失敗し、再試行した記録です。直った後も消していません。

eval・gateの緩和や削除は禁止。失敗の記録は消さない。

自分の運用規約に書いてある一文です（2026年9月時点）。消せるようにしておくと、次に同じ止まり方をしたときに、前も同じだったことに気づけません。

3. 原料が無い日は縮退して正常終了させる

僕が回しているメールマガジンの生成では、元になる実録が足りない日は「材料不足」として何も作らずに正常終了する決まりにしています。

実録なき号は出さない。原料不足はスキップが正。創作で埋めるのは違反。

内製したものを毎日動かすと、エラーで落ちるより、内容が空っぽのまま成功として終わるほうが怖いとわかります。止まったことには気づけますが、中身が薄くなったことには気づけません。

相談を受ける側としても、「作れます」と答えられる範囲は年々広がっています。それでも最初に聞くのは、止まった日に誰が出るかです。

最初の1業務をAIに手放す日の進め方は最初の1業務をAIに任せる初日にやること、外に頼む側に倒したあとの準備はAI業務自動化を外注する前に知っておくべき5つのことにまとめています。

内製化のよくある質問

まとめ：内製化の判断で今日決められること

内製化の判断基準は、作れるかどうかではありません。止まった日に誰が顧客の前に出るかです。今日決められることは3つあります。

1. 自社の業務を5つ書き出し、停止許容時間を時間で書く（困る人に聞く）

2. 外向き・お金に触る業務を、内製の対象から外す

3. 残った業務に、保守の持ち主の名前を書く。書けない業務は買う側に倒す

この3つが埋まると、「AIで作れるから作ろう」と「やっぱり外注に戻そう」の往復が止まります。内製化は本数を増やす取り組みではなく、止まらない業務を増やす取り組みです。