システム開発外注からAIで自社内製化できた話｜外注側の開発会社が最新の状況を正直に伝えます

こんにちは。合同会社Yushin 代表の今井と申します。
弊社はDX支援やシステムの受託開発を行っています。

そんな私たちが経験した「お客様自身によるAIを使った内製化」の話と、「AI時代の新しい開発スタイル」の話をお届けします。

主な対象読者は、すでに開発会社へ外注しているものの、

「システムの外注費が高い」
「開発スピードが遅い、小回りが効かない」
「使い勝手が悪い、現場から使いにくいと言われる」

といった課題を抱えている方です。

簡単に言えば、こうした課題に対してAIをどんどん使って内製化していこうという記事です。同じような境遇にいる開発会社さんにも、有益な情報になるかと思います。

正直なところ、お客様の内製化が進むと、受託開発企業である弊社の仕事は減ることもあります。

有益な情報になれば幸いです。それでは見ていきましょう！

なぜいま内製化なのか｜AIが開発の民主化を起こした

内製化という言葉自体は昔からあります。
ではなぜいま内製化なのでしょうか。

AIの進化でシステム開発の内製化が現実的になった

きっかけは「AIの進化」です。ざっくり振り返るとこうなります。

• 2022年
  • ChatGPT が公開され、生成AIブームが始まる
  • 文章を書く・質問に答えるという、いわゆる「生成AI」が話題になった
• 2023〜2024年
  • エンジニアの間でコーディングにAIを使うのが当たり前になっていく
  • 返ってきたコードを人がコピペしてつなぐ形から、自動で補完してくれる形が主流に
• 2025年
  • Claude Code などの「AIエージェント」が自分でファイルを読み、生成AIを使って書き、動かして確認するようになる
  • コピペや一部の切り取りではなく、開発の一本の流れを一度の指示で完走する
  • 専門知識がなくても、作りたいものを伝えれば形になり始める
• 2026年
  • AIが書いたコードを別のAIがレビュー・検証するようになる
  • 実装から検証までがAIで回り、人に残るのは「何を作り、どこまで作るか」という判断に絞られていく

エンジニアでなくてもAIでシステム開発ができる

いまのAIは開発の流れを最初から最後まで通しで走ってくれます。

ポイントは2つあります。

1. 最初から最後まで自走するようになったこと。これまでは、AIの答えを人がコピペしてつなぎ合わせる必要があり、そのつなぎに専門知識が要りました。いまのAIエージェントは環境の設定からエラーの修正まで自分で完走します
2. 生成AIが出すコードのレベルが飛躍的に上がったこと。以前は人の手直しが前提でしたが、いまはそのまま動く水準のコードが返ってくることも増えました

要は、作りたいものを伝えれば動くものが返ってくるということです。開発の大部分はエンジニアでなくてもやりやすくなりました。

正直に書くと、万能ではありません。 最初にAIが動く環境をつくるところは今も人の手が要りますし、出てきたコードの質を判断するのも別の話です。このあたりは後ほど詳しく書きます。

それでも、内製化を諦める一番の理由だった「作れる人が社内にいない」という前提は崩れ始めています。

そもそも内製化は0か100かの話ではない

内製化と聞くと、自社で全ての開発を行えるようになると思われがちですが、そうではありません。

必要なところだけ内製化すれば良いんです。

「この部分だけは自社で持ちたい」「ここは外注のままで良い」と切り分けて考えることもできます。

そもそも、外注のままのほうがコスパが良い領域もあります。

高度なCTO人材やエンジニアを常に抱えるより、薄く関わってくれるパートナー企業を探したほうが、コストを抑えられたり、安定してお付き合いできたりします。

弊社では内製化をこう位置づけています。

内製化のゴールとは、すべてを自分たちで作ることではない。
「外注ゼロ」ではなく、自社で持つべき能力と、外部を使った方が合理的な領域を
適切に切り分けられることである。

内製化には段階がある

弊社ではお客様の状態を4つの段階で捉えています。多くの企業は「② 外部依存」にいると思います。システムは使っているものの、開発と改善は外部に頼っている段階です。

自社がどこにいるかが分かると、次に何をすべきかも決まります。いきなり全てを内製化しようとすると大変ですので、一段ずつ自社でできることを増やしていくように進めていくべきです。

内製化を掲げていなかった開発会社に起きたこと

支援を始めた時点で、お客様の社内に専任のIT責任者もエンジニアもいませんでした。

この時点で内製化の話は一切していません。 お客様も望んでいませんでしたし、弊社も提案していませんでした。正直なところ、提案する理由がなかったんです。

変化はこちらではなくお客様側から起きました。

2025年11月：お客様がAIでダッシュボードを作った

2025年11月、お客様自身がAIエージェントを使って、それまで市販のツールで見ていた業務データのダッシュボードをゼロから作り上げてきました。

元々技術の話が好きな方ではありました。でも、エンジニアではありません。

これは素直に驚きました。

2026年5月：弊社が作った業務システムにお客様の開発が入り始めた

2026年5月、今度は弊社が設計・開発した業務システムにも、お客様側の開発が少しずつ入り始めました。

ここで弊社も共同開発体制のほうへ舵を切りはじめました。

一番大きな動機は「限られた予算の中でやりたいことがまだまだあり、お客様側で担える範囲が広がれば、その分を別のことに回せる」ということでした。

そのうえで、Slackから開発を進められる環境を用意したり、ローカル開発環境を一緒に整える場を設けたりしました。お客様から開発内容が上がってきた際には、「なぜその機能が必要か？」「設計は適切か？」といったレビューを続けました。

2026年8月：現場の方が日常的に改善を回している

そして2026年9月現在も、現場の多くの方が業務システムの改善を日常的に回しています。弊社が担っているのは、重要な設計判断への助言と、クリティカルな箇所のレビューに絞られています。

はじめから計画して進めた内製化では、まったくありませんでした。 お客様が先に始めて、弊社が後から追いかけた、というのが正直なところです。

外注せずに自社だけでどう開発を内製化しているか

「内製化できました」で終わる話は多いのですが、具体的に何を使って、どうやって開発しているのかまで書かれているものはあまり見かけません。

ここが一番知りたいところだと思うので、実際にたどった順に書きます。

先に結論を書くと、いきなり開発環境を渡してもうまくいきませんでした。Slack から始めて、いまは VSCode + Claude Code に落ち着いています。 開発しているのはエンジニアではない方が複数名です。

最初は Slack だった｜Claude Tag で「話しかけると開発される」状態

最初に用意したのはSlack から開発できる環境でした。エンジニアではない方にとって、ターミナルもエディタも遠い存在です。お客様が毎日使っている Slack の上に開発を乗せれば、覚えることを増やさずに始められると考えました。

Slack に Claude Tag を入れて、スレッドに「この画面にこの項目を足したい」と書くと、その場でコードが上がってくる。これは実際に動きました。ここまでは狙いどおりだったんです。

ただし、コストが見合いませんでした。 従量課金のため、多い月で40〜50万円かかっています。

Slack と Claude Tag の組み合わせは、ローカル開発環境と違って、自分のPCでサッと動かして確かめることができません。 そのため動作を見せるには、何らかの形でプレビュー環境を立ち上げるか、動作確認のスクリーンショットを毎回スレッドに貼り返す必要がありました。

この確認の往復が使い勝手を悪くし、そのぶん費用も積み上がっていきます。処理ごとにモデルを選べないことも費用がかさむ一因でした。

料金体系やモデルの切り替えが変わればまた検討すると思います（詳しい顛末は別の記事に書きます）。ただそれよりも、各自が自由に使えるローカル開発環境を整えた方が、確認もコストも含めてうまくいくと考えました。それが次の話です。

いまは VSCode + Claude Code｜環境構築会を開いた

次に移ったのが、ローカルに VSCode と Claude Code を入れて、自分のマシンで開発する形です。いまはこれが主軸になっています。

ただ、これを「手順書を渡すので入れておいてください」で済ませるのは無理があります。そこで環境構築会を開き、画面を共有しながら一緒に手を動かして、全員が動く状態になるまでやりました。

一番の壁は AI でもエディタでもなくローカル環境だった

正直なところ、一番手こずったのはローカル開発環境を立てるところです。

参加者には Windows の方と Mac の方がいました。手順書は片方の OS でしか通らず、もう片方では途中で止まります。すでに入っているものの整理から始めて、実行環境のバージョンを揃え、データベースが立ち上がるところまで。エラーが出たときに何を読んで何を直すのかは、結局そこに専門知識が要ります。

これは記事の前半で書いた「コードが手に入っても、それを動かすまでの手順に専門知識が要る」という話と、まったく同じ構造です。

ただし、ここには抜け道があります。Claude Code が動くところまで行ければ、その先は Claude Code 自身にやらせられます。 プロジェクトの中にある手順書や設定ファイルを自分で読み、足りないものを入れ、エラーが出れば直す。ここまで来ると、人が横で手順を追う必要はほとんどなくなります。

弊社もいまはこの形にしています。 人が伴走するのは「Claude Code が動く状態にする」ところまでで、その先の環境構築は AI に任せる。伴走が要る範囲は以前よりずっと狭くなりました。

逆に言えば、その最初の一歩だけは今も人が要ります。 内製化を検討するなら、最初の立ち上げを一度きりのイベントとして予算と時間を確保しておくことをおすすめします。

GitHub のレビューは変更の種類で線を引いた

コードは GitHub で管理しています。ここでの運用は最初と今とで変わりました。

始めた頃は、すべての変更をプルリクエストで出してもらい、弊社が全部レビューしてからマージしていました。何が上がってくるか分からない状態では、これが安全です。

かみ砕いていうと、「すべての実装を弊社がレビューしていた」ということです。

続けるうちに、レビューが要る変更と、要らない変更がはっきりしてきました。 そこで線を引き直しました。

• 見た目の調整など、影響範囲が閉じている変更 — お客様側でそのままマージしてよい。マージすると開発環境に自動で反映されるので、その場で見て確認できます
• 設計に関わる変更、データの持ち方が変わる変更 — これまでどおり弊社がレビューします

比較的実装コストの低い公式サイト（WordPress）側は、お客様だけで本番反映まで完結するよう自動化しています。

ここで大事なのは、「権限を全部渡すか、全部持つか」で考えなかったことです。変更の種類で線を引き、安全に任せられるところから順に移していく。この記事の前半で書いた「0か100かではない」という話は、実務ではこういう形で現れます。

AI周りの環境変化は早い｜ツールはそのときどきで選び直す

ここまで書いたのは2026年9月時点の話です。

AI 周りの変化は早く、半年後には別のツールが最適になっている可能性が高いと思っています。実際、Slack から VSCode + Claude Code へ移したのもレビューの線を引き直したのも、その時点で一番回しやすかったからにすぎません。

弊社が続けているのは、特定のツールを勧めることではなく、変化に合わせてそのときどきで最適な環境を一緒に選び直すことです。内製化を始めるときも、いま使っているツールに縛られる必要はありません。

外注を請けている開発会社側は内製化を歓迎するのか

ここは請けている側だから書けることを正直に書きます。

正直、多くの受託開発会社にとって、お客様の内製化は歓迎しにくい話だと思います。

弊社自身、最初から前向きだったわけではありません。

もちろん、単純に売上が減る可能性があるというのもありましたが、本質的な課題はそこではありませんでした。

それよりも
「エンジニア以外にシステムが作れるのか？」
「メンテナンスできるのか？」
を不安に思っていたからです。

AI内製化の不安①：自社内でAIが作ったコードの仕様を把握できないこと

AIは便利ですし、一度の指示だけで高クオリティなサイトやゲームを作ってしまうなど能力も非常に高いです。

しかし、AIが出すコードの質はAIを使う側に委ねられています。またそのコードの質を判断できるのは基本的にエンジニアです。

AIが出したコードやAIが作ったシステムを見ても、それが何をしているのか、どういう仕様なのかを社内の誰も把握できない。 これが一番の課題だと思いました。

この状態を放置すると、次のような連鎖が起こります。

• 問題が起きても、中身が分からないので見当がつかない → 無駄な調査と修正が繰り返される → 結局、最初からエンジニアに頼んだ方がコストを抑えられたとなる
• 分からないまま修正を重ねる → 修正が別の場所を壊し、仕様がぐちゃぐちゃになっていく → 保守性が下がり、1年後の改修費用が膨らむ。最悪、作り直しになる

また実際非エンジニアがAIで書いたコードに触れてきてさらにそう思います。

AI内製化の不安②：AIに任せきりで要件定義や設計を疎かにしがちなこと

エンジニアではない方が「システム開発」や「エンジニアリング」と聞くと、コードを書くことを思い浮かべることが多いと思います。ただ実際には、それは工程の一部でしかありません。

エンジニアリングの本質はなぜそれを作るのか、何を解決するのかを定める要件定義と、それをどう解くのかという設計の方にあります。ここが外れていれば、どれだけきれいなコードでも意味がありません。

そして、要件定義や上流の設計は、AIがあっても多かれ少なかれ人に残ります。

つまり、AIが「何かをやりたい」と意思決定を下すのではありません。人間が意思決定して、AIがその手足になるということです。AIが責任を持てない以上、意思決定は必ず人間側にあるべきだと考えるのが妥当でしょう。

逆に言えば、その意思決定が間違っていたら、AIがどれだけ優秀でも開発は間違った方向に進みます。

背景と課題を精度高く整理し、それを効率よくAIに伝えることが、AIを賢く使う鍵です（このあたりは別の記事で詳しく書きます）。

むしろAIはすぐ形にしてくれるぶん、要件定義や設計を飛ばしたまま、いきなり作り始められてしまいます。 弊社が不安だったのは、コードそのものよりも、任せきりでここが疎かになることでした。

疎かなまま作ると、動くけれど筋の悪いものができます。たとえば、こういうことです。

• 運用を1つ変えれば済む話をシステム化してしまう → 画面と手順が増えてかえって使いにくくなる → 覚えることが増えて、教育コストも保守コストも上がる
• 同じデータが連携されないまま何か所にも散らばる → 片方は文字列、片方は別形式のただのコピーで、整合性が取れない → 集計が合わず、ビジネスとしてデータ分析ができなくなる

エンジニアが学んでいるのは、コードの書き方だけではありません。やってはいけないお作法（アンチパターン）などを経験でわかっていて、AIの提案も批判的な視点から見て反論できる。 この視点がないまま「とりあえず作れてしまう」のが、AI開発の怖さだと思っています。

それでも内製化を歓迎する側に回った理由

不安を並べましたが、考えているうちに、お客様自身が開発を行う方が価値がある部分も多いなと考えました。理由は3つあります。

理由①：小回りが効くこと

思いついてから形になるまでが、極端に短くなります。その場で作り、その場で「これじゃない」と気づき、その場で直せる。AIのスピードが乗ると、このサイクルが1日に何周も回ります。

間に外注を挟むと、このサイクルが長くなる可能性が高いです。関係性にもよりますが、依頼・調査・見積もり・発注・確認・反映・修正依頼・確認・反映・報告のように、外注という関係だからこそ生まれるコミュニケーションもあるでしょう。

要件が曖昧なうちほど、この往復の回数が効いてきます。作りながら要件を固めていけるのは、自分で回せる人だけです。

理由②：現場を知っている人の方が課題の解像度が高いこと

何に困っているのか、どうなれば嬉しいのか、どんな例外が起きるのか。「なぜ作るのか」を一番解像度高くわかっているのは、その業務を行っている人です。

実際、弊社が要件定義でやっていたことの多くは、現場が持っている情報を時間をかけて引き出す作業でした。人を1人経由するたびに、細部は削れていきます。

もちろん、要件定義をどう進めるかは別の話です。そこは弊社のレビューが受け持ちます。ただ「何を作るべきか」の解像度に限れば、現場にいる人にはかないません。

理由③：同じ予算でできることが増えること

受託開発会社が言うのも変ですが、日常の細かい改修を外注で回すのは、割高に感じられると思います。理由は次の2つです。

1. 見積もりや確認といった手続き・対外コミュニケーションのコストが、小さい改修ほど相対的に重くなるから
2. 契約や関係性にもよるが、外注側の価格には利益やリスク分などのコストが乗るから

要は、外注はそもそも内製より割高になりやすく、こと小さな改修は自社でサクッと直せた方がコスパが良い可能性が高いということです。

もちろん、自社で回せばコスト0という話ではありません。それでも、外注の仕組み分が乗らないため割安になりやすいということです。

その結果、日常の細かい改修は自社で抑えて、残った予算で大きな新規機能の追加などをまとまった形で外注するといったハイブリッドな開発ができるようになります。

何を内製化して、何を外注に残すか

すべてを内製化する必要はありません。考え方は主に3つです。

1. 細かくて変更の頻度が高いものほど、自社で持つ方がコスパが良い
2. 業務知識が大きく関わる部分は、内製化すると要件の解像度が上がる
3. 高い技術力が要る部分やリスクの大きい部分は、スポットで外注する方がコスパが良い

たとえば、画面の文言や項目の追加、一部デザインやレイアウトの調整などは自社で持つ側です。それは頻繁に起こりやすく、しかも後で直しやすいからです。使う人がその場で直せる方が速くて確実です。

また、業務ダッシュボードのように業務を知っている人が作った方が「痒いところに手が届く」領域も、できれば内製化した方が理想ではありますね。ただここは開発のレベル感もあるので要検討ですが。

逆に、インフラやセキュリティ、決済まわりのような領域は外注に残すことを検討しましょう。変更の頻度が比較的高くないわりに、事故が起きたときの影響が大きいからです。つまり、コスパが悪くなりがちです。

外注から内製化へ移行する進め方

大きく3つです。ポイントは、関係が良好なうちに、関係を続ける前提でベンダーへ相談すること。そして一度に切り替えず、開発会社にガードレールを整えてもらい、レビューを受けながら、担う範囲だけを段階的に変えていくことです。

それぞれの具体的な進め方は別の記事で詳しくまとめます。

まとめ｜AIで外注と内製の考え方は大きく変わっていく

最後に、この記事の要点をまとめます。

• AIで開発のハードルが下がり、内製化のハードルも大きく下がった（開発の民主化）
• すべてを内製化する必要はない。外注に残す方が合理的な領域もある
• AIが肩代わりするのは「どう書くか」がメイン。何を、なぜ作るかの意思決定は人に残る
• 非エンジニアのAI開発は、壊れても直せない・動くけれど間違っているが起こりやすい。だからこそ、プロのレビューを残したまま範囲を広げる
• それでも本来は、現場を知っている側が開発を担う方が良い。課題の解像度が違う

ところで、内製化が進めば開発会社の仕事は減るのでしょうか？

私はそうは思いません。

開発の民主化が起これば、開発を行う企業や人の絶対量はむしろ増えると思います。同時に、正しい開発リテラシーを持たない開発には落とし穴がつきものです。

だからこそ、開発会社の役割は次のようにシフトしていくと感じています。

• 大型の開発案件をまとめて請けて納品する役割（これまでどおり）
• 開発環境の整備やAI開発リテラシーの教育を担う役割
• 技術顧問や開発リスクに対する保険のような役割

つまり、プロがまとめて作った方がコスパの良い領域はそのまま残るということです。一方で、保守運用や改善、小規模なシステムやツールの開発は大きく民主化が進むと感じています。

いま「内製化しましょう」とお客様に打ち出す開発会社は少ないと思います。それでも、いずれこの波は広がっていくはずです。

以上「システム開発外注からAIで自社内製化できた話｜外注側の開発会社が最新の状況を正直に伝えます」でした！

自社の開発成熟度を確認する