数百万円の見積もりが来た。でも彼女は1週間で作った。
これはたとえ話ではない。2025年から2026年にかけて、この種の話が企業の現場から次々と報告されている。
「エンジニアに頼まなければ」が崩れ始めた
これまで、社内ツールを作るには2つの選択肢しかなかった。エンジニアに頼む（時間とコストがかかる）か、外注する（さらに時間とコストがかかる）かだ。
Zendeskのシニア・プロダクト・ディレクター Jorge LutheはAIコーディングツールの導入後にこう語った。「アイデアからプロトタイプまで6週間かかっていたものが、3時間でできるようになった」。
McKinsey社内では、社内開発チームへの依頼で4〜6ヶ月待ちだったものを、Lovableで数時間で構築するケースが出始めている。
これは突然変異的な出来事ではない。ツールが変わったのだ。
AIコーディングツールが登場する前、プログラムを書くにはプログラミング言語の文法を知らなければならなかった。JavaScriptとは何か、変数とは何か、関数とは何か——そこから学ばないと何も動かない。
いま、そのプロセスが逆転した。「何を作りたいか」を日本語で伝えれば、コードはAIが書く。人間が担うのはコードではなく指示だ。
日本でも起きていること
海外の大企業だけの話ではない。日本でも、名前のある会社の非エンジニア部門から事例が出てきている。
ASOLAB（マーケティング支援会社）では、非エンジニアのスタッフがClaude CodeとCodexを組み合わせ、24時間でファイル転送サービスを自社開発した。外注すれば数十万から数百万、納期は数週間という規模の案件だ。
SmartBankの事業開発担当者（非エンジニア）はCursorを活用し、5ヶ月間で工数1/3、売上3倍、事業規模16倍という数値を自ら報告している。同氏は「屋台モデル」と呼ぶ——最小工数で事業の基盤を動かしながら、現場で改善を回す方法論だ。
コロプラのマーケティング戦略部では、非エンジニアの部門がCursorを導入。ドキュメント検索ツールを内製し、検索作業にかかる時間を10分から1分に短縮した。
共通点がある。全員、エンジニアではない。コードを書く訓練を受けていない人たちが、ツールを使って動くものを作った。
「コードが書けるか」より「何を作るか言えるか」
Replit社のCEO Amjad Masadは、「製品マネージャーが最高のバイブコーダーだ」と言った。その理由はシンプルで、「PMは問題を細かく分解し、正確に伝える訓練を受けているから」だ。
これは反転した競争力の話だ。かつては「コードが書ける人」が強かった。今は「何を作るか、なぜ必要か、誰のためかを正確に言語化できる人」が強い。
Lovable社のCEO Anton Osikaは"Demo, don't memo"という言葉を使う。12ページのプレゼンを作る時間があるなら、動くものを作ってフィードバックをもらえ、という意味だ。
現場の担当者がいちばん「何が問題か」を知っている。その知識をAIへの指示に変換できれば、プロトタイプは数時間で手に入る。
プロンプトが設計図になる
AIへの指示（プロンプト）の書き方で、結果の質はまったく変わる。
❌ 漠然とした依頼（AIが迷う）
「営業管理ツールを作って」
✅ 具体的な指示（AIが動ける注文書）
「営業担当者が商談を記録するツールをNext.jsで作って。
機能:
- 商談先会社名・担当者名・日時・金額・ステータスを入力できるフォーム
- ステータスは「初回接触」「提案済み」「成約」「失注」の4種類
- 一覧画面でステータス別にフィルタリングできる
- Googleスプレッドシートに自動記録する
対象ユーザー: 社内の営業スタッフ10名（スマートフォンでも使えること）
アクセス制限: 社内のGoogleアカウントでのみログイン可能」
大工に「なんかいい感じにして」と言えば失敗する。「この壁を取り払って、南向きに窓を付けて」と言える人が成功する。AIも同じだ。指示の精度が、アウトプットの精度を決める。
どのツールを選ぶか
AIコーディングツールにはいくつかの種類があり、用途によって使い分けが必要だ。
| ツール | 向いている用途 | 料金 |
|---|---|---|
| Lovable | WebアプリをゼロからUIごと作る | 無料プランあり、Pro月額$25〜 |
| Cursor | 既存コードの改修、ファイル操作 | 月額$20 |
| Claude Code | ターミナル操作、幅広い用途 | Claude Max（月額$100〜）に含まれる |
Lovableは2025年末時点で毎日10万件以上の新規プロジェクトが生まれており、2025年12月時点のARR（年間経常収益）は$200Mを突破、評価額$66億に達した。
数字が示すのはシンプルな事実だ。コードが書けない人でも使っている、使えている。
向く案件と向かない案件
ただし、何でも内製化すればいいわけではない。
✅ 内製化に向く案件
- 社内専用ツール（外部ユーザーが使わない）
- データの集計・変換・ダッシュボード
- 業務フローの自動化（メール送信、スプレッドシート連携）
- プロトタイプ・PoC（本番前の検証用）
- 試行錯誤しながら要件を固めていくもの
❌ 内製化だけでは危ない案件
- 顧客に使わせる本番サービス（決済・認証・個人情報処理を含む）
- 金融・医療・法律など規制の厳しい分野
- 大規模な既存システムとの統合
- 24時間止められない業務インフラ
「社内ツールなら大丈夫」というわけでもない。社内ツールでも個人情報を扱うなら、セキュリティの確認は必要だ。
セキュリティだけは油断するな
AIは動くコードを書くが、安全なコードを保証しない。Apiiroの調査では、AIコーディングツールの普及以降、認可チェックが欠けたAPIが10倍増加したと報告されている。「動いた」で終わらせると、ドアの裏に合鍵を貼っているようなコードが残る可能性がある。
内製ツールをチームで使い始める前に、最低限このプロンプトをAIにかけること。
「このコードにセキュリティ上の問題はないか確認して。特に個人情報の取り扱い、認証・認可の設計、APIキーやシークレットの管理、入力値の検証、外部からのアクセス制御に注目して」
AIが「問題ありません」と答えたとしても、重要な情報を扱うなら専門家のレビューを求めること。
シャドーIT（IT部門の承認を得ずに使う業務ツール）の問題もある。個人のアカウントで作ったツールに顧客データを入れると、データの所在と管理責任が曖昧になる。社内で展開する前に、情報システム部門やセキュリティ担当に確認する手順を踏むべきだ。
詳しいセキュリティの落とし穴については、バイブコーディングで踏むセキュリティの落とし穴にまとめてある。
「コードを書くかどうか」という問いが変わった
iPhoneが登場して、誰でも写真が撮れるようになった。でも「カメラマンが不要になった」とはならなかった。プロが撮る写真とスマートフォンで撮る写真は違う。ただ、「撮りたいなら専門家に頼まなければ」という制約はなくなった。
内製化の話もそれと同じだ。エンジニアは引き続き必要で、複雑なシステムや本番サービスの構築はプロの仕事だ。変わったのは「手軽に試せる範囲」だ。
McKinseyのコンサルタントが4〜6ヶ月待ちの開発チームを迂回して、数時間でプロトタイプを作って持ってきた。それが通るようになった。
「外注するか、エンジニアに頼むか」という問いの前に、「まず自分でやってみる」という選択肢が生まれた。その選択肢を持っているかどうかが、2026年の現場での差になりつつある。
