「コードを書けないアイドルが、Claude Codeを使って10時間配信のシステムを作った」。この話を見て、エンジニアや受託開発会社で働く人ほど、少し落ち着かない気持ちになったのではないでしょうか。
非エンジニアが自分でシステムを作れるなら、受託開発企業は必要なのか。SES会社は残るのか。事業会社は開発を内製できるのか。エンジニアの仕事はどこへ移るのか。
結論から言います。
受託開発もSESもエンジニアも、すぐにはなくなりません。ただし「仕様を受け取り、人を集め、コードを書いた量で売上を立てる仕事」は確実に厳しくなります。
内製化も進みます。ただし、全社員がプログラマーになり、外部企業を一切使わなくなるわけではありません。企業が内製すべきなのは、すべての実装ではなく、何を作るか、何を許可するか、何をもって完成とするかを決める能力です。
この記事では、話題になった事例を起点に、システム開発の今まで・現在・これからを整理します。AIを組織へ入れる順序やガバナンス全体は生成AIの組織導入ガイドで扱っているため、ここでは開発産業と仕事の変化に絞ります。
話題になったのは「コードを書かなかったこと」ではない
本人の制作記録と技術構成によると、作ったのは単純なデモではありません。10時間のYouTube生配信で使うために、次の仕組みを組み合わせています。
- OBSに表示するリアルタイムゲージ
- スマホやPCから操作する管理画面
- Xの投稿数を取得して反映する仕組み
- 動画を比較して再現度を採点するローカルアプリ
- Cloudflare WorkersとKVを使った状態管理
- API障害時にも配信を止めない手動フォールバック
公開された制作記録と技術構成によると、実装はほぼClaude Codeへ任せ、コードは読んでいなかったとのことです。一方で、事前に仕様書を作り、要件、データ構造、API、実装順、当日の運用を決め、エラー画面を渡しながら修正しています。
さらに、無料プランではCronが使えないと分かれば手動取得へ変え、決済で詰まったAI APIは別の事業者へ切り替えています。自動処理が失敗しても配信を継続できるよう、管理画面から直接値を変えられるようにもしています。
つまり、AIが担ったのは主にコード生成と修正です。本人は、次の役割を持っていました。
- 何を作るかを決めるプロダクトオーナー
- 制約から構成を選ぶ設計者
- 期待動作を確認するテスター
- 本番を止めない運用責任者
- 締切から逆算して代替案を選ぶプロジェクト責任者
その後に公開された振り返りを見ると、突然すべてができるようになったわけでもありません。クラウドを学び、外部の専門家からWeb開発を教わり、詳細な仕様をMarkdownで作り、複数のAIにレビューさせています。
この事例を「初心者でもAIに丸投げすれば本番システムが作れる」と要約するのは雑です。注目すべきなのは、業務や企画を一番よく知る人が、実装待ちの列に並ばず、自分で仮説をシステムへ変えられたことです。公開後の議論でも、単なるコード生成より、企画力、判断力、フェイルセーフ設計が注目されていました。
システム開発の今まで・現在・これから
ソフトウェア開発は、コードの書き方だけでなく、分業の境界が変わり始めています。
| 観点 | 今まで | 現在 | これから |
|---|---|---|---|
| 企画 | 事業部が要望を文書化 | 事業部とエンジニアが対話 | 事業当事者がAIで動く仕様を作る |
| 設計 | 上流工程でまとめて確定 | 小さく作って更新 | 制約・受入条件・運用を継続的に更新 |
| 実装 | 人がコードを書く | 人とAIが共同実装 | AIが複数案を実装し、人が選択・検証 |
| 品質 | 後工程でテスト | CIとレビューを自動化 | テスト・権限・監査を開発環境へ組み込む |
| 調達 | 人月と納品物を購入 | チームと継続改善を購入 | 解決能力、運用責任、知識移転を購入 |
Anthropicが50万件のコーディング対話を分析したEconomic Indexでは、Claude Code上の対話の79%が、AIが直接タスクを実行する「automation」に分類されました。特にWeb、UI、UXの利用が多く、単純なユーザー向けアプリほど早く影響を受ける可能性が示されています。
ただし、これは雇用が79%減るという意味ではありません。Claude Codeの利用内容を分類した調査であり、労働市場の予測ではないからです。読み取れるのは、実装作業の一部が、人間の手作業からエージェントへの委任へ移ったことです。
私自身、受託案件と自社プロダクトの両方でAIコーディングを使ってきました。短くなったのは、既存コードの調査、定型実装、テストの草案、エラー原因の候補出しです。逆に軽くならなかったのは、業務例外の確認、権限境界、既存データとの整合、本番移行、障害時の責任分担でした。
コードを書く時間が減ると、開発全体が同じ割合で短くなるわけではありません。今までコードの陰に隠れていた意思決定が、開発期間の中心に出てきます。
内製化は進む。ただし「全部自分で作る」ではない
IPAのDX動向2025では、日本はコア事業・競争領域でも外部委託による開発が最も多い一方、米国は内製による自社開発が約半数と報告されています。米国では、内製化を進めている企業と必要部分を内製化済みの企業を合わせると、従業員規模を問わず8割を超えます。
AIコーディングは、この差を縮める道具になります。業務を知る社員が、社内ツール、データ連携、検証用アプリを自分で作りやすくなるからです。
ただし、IPAは現場主体のDXについて、システム乱立、基幹システムと連携できないデータ、セキュリティ不足も課題として挙げています。作れる人が増えるほど、無秩序なシャドーITも増えます。
内製化で社内に戻すべきなのは、次の3つです。
1. 事業の優先順位
誰の、どの問題を、なぜ今解くのか。これは外部ベンダーにもAIにも委任できません。話題の事例が強かったのも、配信の企画とファン体験を当事者が理解していたからです。
2. 設計と許可の境界
どのデータを使ってよいか。どこまで外部APIへ送ってよいか。誰が本番へ反映できるか。AIは案を出せますが、会社として受け入れる判断は社内に残ります。
3. 完成と運用の責任
動けば完成ではありません。監視、問い合わせ、障害対応、費用超過、サービス終了、担当者退職まで含めて持てるかが本番運用です。
したがって、今後の内製化は次のような混成になります。
| 対象 | 基本判断 |
|---|---|
| 競争力に直結し、頻繁に変わる機能 | 社内がプロダクト責任と設計判断を持つ |
| 会計、勤怠などの共通業務 | SaaS・パッケージを優先する |
| レガシー移行、高度なセキュリティ、特殊技術 | 外部専門家と共同で進める |
| 小さな業務改善、仮説検証 | 業務担当者とAIで試し、技術レビューを通す |
これは「内製か外注か」の二択ではありません。Build、Buy、Partnerを案件ごとに選ぶ能力を内製するということです。
受託開発企業は必要なのか
必要です。ただし、必要とされる理由が変わります。
経済産業省のデジタル産業に関する資料は、共通領域はSaaSやパッケージへ、競争領域は内製へ移り、大規模な受託開発は減少すると以前から予測していました。AIはこの流れを速めます。
一方、日本ではレガシーシステム、複雑な基幹連携、規制対応、24時間運用、人材不足が残っています。IPAのモダン化解説も、ユーザー企業が自律性を持ちながら、ITベンダーと協力して内製化する方向を示しています。すべてを社員だけで作るのは現実的ではありません。
厳しくなる受託開発は、次の形です。
- 顧客が書いた仕様をそのまま実装する
- 共通機能まで毎回フルスクラッチで作る
- 人数と期間の大きさを売上の根拠にする
- 納品後の運用や事業成果を持たない
- コードと知識をベンダー内に閉じ込める
残る受託開発は、次の価値を持つ会社です。
- 顧客と一緒に業務を分解し、作らない選択もできる
- AIが安全に働ける開発基盤、テスト、権限、監査を整える
- レガシー移行や複数システム統合を完遂する
- セキュリティ、信頼性、障害対応まで持つ
- 顧客社員が次から自分で改善できるよう知識を移転する
- 複数案件の学びをテンプレートやプロダクトへ還元する
これからの受託会社が売るのは、コードの行数ではありません。顧客が安全に変化できる状態です。
AIへ仕事を任せるほど、リポジトリの指示、検証コマンド、権限、レビュー工程が品質を左右します。この開発環境の作り方はHarness Engineering入門で具体化しています。
SES会社は必要なのか
短期では必要です。しかし、人月を埋めるだけのSESモデルは受託開発以上に圧力を受けます。
ここでは契約類型の法的な議論ではなく、外部技術者の稼働を人月単位で提供する事業モデルをSESと呼びます。
IPAのシステム開発に関する資料では、日本のIT人材はIT企業に72%、ユーザー企業に28%所属すると整理されています。人材が急に事業会社へ移るわけではないため、外部の技術者が開発を支える構造は当面残ります。
問題は、企業が何を買うかです。
| 厳しくなるSES | 残る技術支援 |
|---|---|
| 指示された実装だけをこなす | 曖昧な課題を分解して受入条件を作る |
| 稼働時間と人数だけを価値にする | リードタイム、品質、復旧力で成果を示す |
| 顧客固有の知識を個人に閉じ込める | 文書、テスト、運用手順として社内へ残す |
| AI利用を個人任せにする | 共通のAI開発基盤とレビュー工程を運用する |
| プロジェクトを離れると止まる | 引き継ぎと内製移行を完了条件に含める |
特に、明確なチケットを受け取って定型実装するだけの仕事は、AIエージェントと競合しやすいです。反対に、顧客の業務を理解し、AIが出した差分を検証し、複数部署を調整し、本番責任へつなげられる技術者は不足します。
SES会社が残るには、「何人出せるか」から「どの能力を顧客に組み込み、いつ自走できる状態にするか」へ提案を変える必要があります。
外部人材を個人単位でどう使い分けるかはAI時代でも企業がフリーランスを使う理由で別に整理しています。本記事の論点は、個人の契約形態ではなく、開発会社の事業モデルです。
エンジニアの仕事はなくなるのか
「コード生成が自動化される」と「ソフトウェアエンジニアが不要になる」は同じではありません。
国際労働機関は2025年の調査で、生成AIの影響を受ける仕事の多くは、人間の入力が引き続き必要なため、消滅より変容が中心になるとまとめています。米国労働統計局も、AIの普及を織り込んだ上で、ソフトウェア開発者の雇用が2024年から2034年に15.8%、約26万7,700人増えると予測しています。米国の予測を日本へそのまま当てはめることはできませんが、少なくとも「AIが普及すれば開発者数はゼロへ向かう」という単純な根拠にはなりません。
変わるのは仕事の中身です。
減る仕事
- 既存パターンに沿った定型実装
- 調査結果の単純な要約
- ひな型から作るテストやドキュメント
- エラーメッセージを検索して試すだけのデバッグ
- コードを書いた量だけで評価される仕事
増える仕事
- 業務の曖昧さを仕様と受入条件へ変える
- AIへ渡すコンテキストと作業範囲を設計する
- 生成された差分をテスト、セキュリティ、運用面で検証する
- データ、権限、外部接続の境界を決める
- 監視、障害対応、コスト管理まで含めて運用する
- 技術的な選択を事業責任者へ説明する
Google Cloudの2025 DORA調査は、AI導入をツールの問題ではなくシステムの問題として扱っています。技術者の90%が仕事でAIを使い、8割超が生産性向上を感じる一方、3割はAI生成コードをほとんど、またはまったく信頼していません。強いチームはAIでさらに強くなりますが、弱い開発プロセスへAIを入れると、手戻りも速く増えます。
ここで難しいのが若手育成です。これまで新人が担当していた小さな修正や定型テストをAIが処理すると、経験を積む階段が消えます。企業は、AIで人数を減らすだけではなく、次の学習機会を意図的に作る必要があります。
- AIの差分を説明させ、人間がレビューする
- 失敗したテストや障害の原因を自分で切り分ける
- 小さな機能でも受入条件と運用手順を持たせる
- 本番監視やインシデント対応に参加させる
- 設計判断を記録し、先輩と比較する
AI時代のエンジニアは、コードを書かない人になるのではありません。コードを読めなくてもよい人でもありません。必要なときに深く読める一方、すべてを自分で入力しなくてもよい人になります。
IT企業はどう変わるべきか
AI時代にIT企業が最も変えにくいのは、技術ではなく売上モデルです。
人を増やし、工期を長くし、個別開発を増やすほど売上が伸びるモデルでは、AIによる工数削減が自社の減収になります。そのため「AIを使っています」と言いながら、顧客には従来どおり人月を売る矛盾が起きます。
今後のIT企業は、少なくとも次の方向へ移る必要があります。
1. 個別受託から再利用可能な資産へ
毎回ゼロから作らず、認証、監査、デプロイ、テスト、AIエージェントの権限設定を共通基盤にします。案件の学びをテンプレート、プラットフォーム、マネージドサービスへ戻せる会社ほど強くなります。
2. 納品から継続運用へ
リリース後の利用率、変更速度、障害復旧、コストまで持ちます。作って終わる会社より、事業成果が出るまで改善できる会社が選ばれます。
3. 秘匿から知識移転へ
顧客が分からない状態を維持するのではなく、顧客が次の改善を自分で判断できるようにします。設計記録、テスト、運用手順、AIへの指示を顧客資産として残します。
4. 人数の提案から能力の提案へ
提案書に書くべきなのは、10人を6か月投入することだけではありません。何日で仮説を検証し、どのリスクを止め、どの指標を改善し、どの状態で顧客へ引き渡すかです。
5. AI利用からAI統制へ
社員がClaude Codeを使えるだけでは差別化になりません。顧客データを入れない仕組み、秘密情報の管理、承認、レビュー、監査ログまで提供できることが価値になります。社内ルールの最小構成はAIコーディングツールの社内ガイドラインにまとめています。
企業が今から90日でやること
大規模なAI改革計画より、開発責任を小さく社内へ戻す方が先です。
1〜30日: 小さな対象を選ぶ
- 現場が毎週困っている業務を1つ選ぶ
- 個人情報や決済を扱わない範囲から始める
- 業務担当者をプロダクト責任者にする
- 既存SaaSで解決できないかを先に確認する
31〜60日: AIで作り、技術者が境界を見る
- 仕様をMarkdownで書く
- 受入条件と手動フォールバックを先に決める
- 分離したリポジトリと検証環境でAIに実装させる
- 秘密情報、外部通信、本番反映を承認制にする
- エンジニアがコード、依存関係、権限をレビューする
61〜90日: 運用して調達基準を変える
- 利用者数、変更リードタイム、障害、手戻りを測る
- 誰が止め、誰が直し、誰が費用を見るかを決める
- 外部企業には人数ではなく、検証、運用、知識移転を求める
- 内製する部分、SaaSを使う部分、外部へ任せる部分を更新する
この90日で得たい成果は、アプリ1本ではありません。自社がどこまで決められ、どこから専門家が必要かを見極める能力です。
まとめ: 消えるのは会社ではなく、価値の薄い境界
コードを書けないアイドルがClaude Codeで配信システムを作った事例は、エンジニア不要論の証拠ではありません。
これは、企画を持つ人とソフトウェアの間にあった距離が、一気に短くなった事例です。そして距離が短くなると、これまで中間にあった役割はすべて、価値を問い直されます。
- 事業会社は、要件、設計判断、完成条件、運用責任を内製する
- 受託開発企業は、実装量ではなく統合、信頼性、変化能力を売る
- SES会社は、人数供給ではなく顧客が自走する能力を組み込む
- エンジニアは、コード量ではなく問題設定、検証、運用で価値を出す
- IT企業は、人月商売から再利用資産と継続成果へ移る
AIで作れるものが増えるほど、ソフトウェアの需要も増えます。今まで予算が付かなかった小さな業務、個人の企画、短命なイベントにも、専用システムが作られるようになるからです。
仕事の総量が単純に減るとは限りません。ただし、同じ仕事のやり方が残るとも限りません。
これから問われるのは「コードを書けるか」だけではありません。誰よりも問題を理解し、AIを使って形にし、壊れたときまで責任を持てるかです。そこまでできる人と会社には、受託でもSESでも内製でも仕事が残ります。