「外注すると数百万円・数か月。でも社内にエンジニアはいない」——多くの中小企業が抱えてきたこのジレンマが、AIの進化で大きく変わりつつあります。自然言語で指示するだけでアプリが形になる「バイブコーディング（Vibe Coding）」が広がり、非エンジニアの社員が自分の業務に合わせたツールを自分で作る、という選択肢が現実的になってきました。
一方で、「結局どのツールを組み合わせればいいのか」「公開しても安全なのか」は分かりにくいままです。本記事では、非エンジニアが中心の組織が業務アプリの内製化を始めるときの“最小構成”として Claude＋Vercel＋Supabase を推す理由と、ここを外すと事故につながる 安全な進め方 を、できるだけ正直に整理します。
本記事は情報提供を目的としたものです。料金・仕様は変動が早いため、導入前に必ず各サービスの公式情報をご確認ください。
なぜいま「内製化」なのか
バイブコーディングという言葉は、2025年初頭にAIの自然言語指示でコードを生成するスタイルとして提唱され、その後1年ほどで一般語として定着しました。日本国内でも、非エンジニアの社員が短時間で自社専用の業務ツールを作った事例や、大手企業が社内で「AIでアプリを作る」体験イベントを実施した事例が公開され始めています。 <!-- 出典メモ：ASOLAB（非エンジニアが社内ファイル転送ツールを短時間で内製）、NTTドコモグループの社内バイブコーディング大会など。公開事例として紹介可。一次情報の出典URLは公開前に貼付のこと。 -->
内製化のメリットは、主に次の3つに集約できます。
- スピード：思いついた業務改善を、その日のうちに試作して翌日には現場で試せる。要件定義→見積→発注→納品の長いサイクルを短縮できる。
- コスト：外注すれば数百万円規模になりがちな小規模ツールを、既存社員の手で作れる。
- 現場主導：業務を一番よく知っている人が、自分でツールを直せる。仕様のズレが起きにくい。
ただし、後述するとおり**「作れる」ことと「公開して安全に運用できる」ことは別物**です。ここを踏まえたうえで、ツール選定に入ります。
結論：役割が違う3つを組み合わせるのが、いちばん分かりやすい
アプリを作って動かすには、ざっくり3つの仕事が必要です。Claude・Vercel・Supabaseは、この3つをそれぞれ得意分野として分担します。
| 役割 | 担当ツール | ひとことで言うと |
|---|---|---|
| 作る | Claude | 日本語の指示を、動くコードに翻訳する |
| 届ける（公開する） | Vercel | 作ったアプリをインターネット上で動かす |
| ためる（保存・認証） | Supabase | データの保存、ログイン、ファイル管理を担う |
料理に例えるなら、Claudeが「調理する人」、Vercelが「お店に並べて提供する人」、Supabaseが「食材を保管する冷蔵庫」です。3つが自然につながるため、非エンジニアでも「どこで何をすればいいか」を把握しやすいのが、この構成を推す最大の理由です。
それぞれを選ぶ理由
Claude：日本語の“やりたいこと”をコードにする
社内のAI活用では、ツールごとに役割を分けると混乱しません。JPWでは「考える・整理する」フェーズと「成果物を作る」フェーズでツールを分けており、アプリの“制作”は主にClaudeが担います。 <!-- 内部リンク：ChatGPT / Claude / Gemini 使い分けガイド -->
非エンジニアに向く理由は3つあります。
- 自然な日本語で指示が通る：「こういう画面で、こういう動きをするアプリが欲しい」と会話のように伝えるだけで、コードのたたき台が出てくる。
- その場で試せる：チャット内で簡単なアプリをプレビューできる機能（アーティファクト）があり、作りながら確認・修正ができる。最初の一歩の心理的ハードルが低い。
- 本格化への道がある：ちょっとした試作から、複数ファイルにまたがる本格的なプロジェクトの開発支援（Claude Code）まで、同じ系統のツールで段階的にステップアップできる。
プランや利用できる機能は変更されることがあります。料金・提供範囲は公式でご確認ください。
<!-- 要社内確認：自社の利用プラン（経営者＝上位/従業員＝標準）に触れるかどうか。CTAとして触れる場合は別途文面を用意。 -->
Vercel：公開のいちばん面倒な部分を肩代わりする
作ったアプリを「自分のPCの中」から「誰でも使えるWeb」へ出す工程（デプロイ）は、従来もっとも初心者がつまずくポイントでした。Vercelはここを大幅に簡単にしてくれます。コードを置いておくと自動でWeb上に反映され、変更のたびに確認用のURLが発行されるため、「作る→公開→共有」が一連の流れでつながります。
ここで料金の注意点があります。
- 無料の Hobbyプラン は 個人・非商用利用に限定 されています。会社の業務（売上に関わる用途を含む）で使う場合は規約上、有料プランが必要です。
- 業務利用の Proプラン は、おおよそ 1ユーザーあたり月額20米ドル前後（同額分の利用クレジットを含む）から。これに加えて、通信量やリクエスト数に応じた 従量課金 が乗る可能性があります。
- 大規模・高度な要件は Enterprise（要問い合わせ）。
「無料で会社のアプリを公開できる」と誤解しやすい点です。業務利用なら最初から有料プラン前提で考えるのが安全です（金額は概算。公式で要確認）。
Supabase：データベース・ログイン・保存を“ひとまとめ”で
業務アプリには、たいてい「データを保存する」「ユーザーがログインする」「ファイルを置く」といった裏側の仕組みが必要です。Supabaseは、これらを一体で提供してくれるサービスで、AIでアプリを作るワークフローの“裏側（バックエンド）”として広く使われています。データベースには実績あるPostgreSQLを採用しています。
料金の目安は次のとおりです（概算・公式で要確認）。
- Free（無料）：個人検証・試作向け。ただし 一定期間（おおむね1週間）アクセスがないとプロジェクトが自動停止 する仕様で、常時稼働が必要な本番運用には不向き。利用できるデータベース容量やプロジェクト数にも上限があります。
- Pro：おおよそ 月額25米ドル前後 から（自動停止なし／一定のコンピュート利用枠を含む）＋従量課金。小規模な本番運用の現実的なスタート地点。
- Team：おおよそ 月額599米ドル前後。SOC 2 / ISO 27001 など、コンプライアンス要件が必要になったとき向け。
- Enterprise：要問い合わせ。
「無料のまま本番に使えるのでは」と考えると、ある日突然アプリが止まるという事故につながります。社内で継続的に使うなら、Supabase側もProプラン以上が前提になります。
なぜ“この3つ”なのか — 一体型ツールとの違い
非エンジニア向けには、これらを最初からひとまとめにした一体型ツール（Lovable、Bolt、Replit など）もあります。「とにかく速く試作したい」「使い捨てのプロトタイプでいい」なら、そうした一体型のほうが手早いこともあります。
それでも Claude＋Vercel＋Supabase を推すのは、長く使う“資産”として残しやすいからです。役割が3層に分かれているぶん、どこで何が起きているかが見えやすく、特定サービスへの依存（ロックイン）も比較的ゆるやか。試作から本格運用へ移すときも、エンジニアに引き継ぎやすい構成です。
| 観点 | 一体型ツール | Claude＋Vercel＋Supabase |
|---|---|---|
| 立ち上げの速さ | ◎ とにかく速い | ○ 少し手順が増える |
| 後から残る“資産性” | △ ツール依存になりがち | ◎ 標準的な部品で構成 |
| 本格運用・引き継ぎ | △ | ◎ エンジニアに渡しやすい |
| 学びやすさ・透明性 | △ 中身が見えにくい | ◎ どこで何をしているか分かる |
<!-- 要社内確認：一体型ツールの製品名・特徴は2026年時点の一般的理解に基づく記載。公開前に最新状況を軽く確認のこと（製品は入れ替わりが早い）。 -->
料金のリアル：合計でいくらかかるのか
「無料で始められる」は半分本当で、半分は誤解です。個人の検証なら無料枠で十分始められますが、会社として継続運用するなら、現実的な月額の目安はこうなります（いずれも概算・公式で要確認）。
- Vercel（業務利用 / Pro）：1ユーザーあたり 月額20米ドル前後〜（＋従量）
- Supabase（本番 / Pro）：月額25米ドル前後〜（＋従量・コンピュート）
- Claude（制作担当）：利用プランに応じた月額（公式で確認）
つまり、小さく本番運用を始めるだけでも、ツール代として月額数十米ドル規模になるのが実態です。さらに、両サービスとも**使った量に応じた従量課金（通信量・データ量など）**が乗る設計のため、利用が増えると費用も増えます。
ポイントは、「想定外の高額請求」を防ぐ設定です。Supabaseには利用上限を設ける仕組み（スペンドキャップ）があり、初期は有効にしておくと安心です。Vercelも利用状況をダッシュボードで定期的に確認しましょう。
<!-- 要社内確認：為替で円換算額が動くため、本文では米ドル表記＋「公式で要確認」に留めています。円目安を入れる場合はレートと注記を追加。 -->
それでも、外注で数百万円・数か月かかっていた小規模ツールが、月額数十ドル＋社員の工数で内製できると考えれば、費用対効果は十分に検討に値します。
ここが本題：非エンジニア組織が“安全に”内製するための手順
ここまでで「作れる」ことは分かりました。しかし、**非エンジニア組織にとって本当に重要なのは、ここからの「安全な進め方」**です。むしろこの部分こそ、ツール選びより大切だと考えています。
理由はシンプルで、AIが生成したコードには、セキュリティ上の弱点が混入しやすいことが、複数の調査や現場のエンジニアから繰り返し指摘されているからです。「動く」ことと「公開しても安全」なことは、まったくの別物です。 <!-- 要社内確認：「AI生成コードの脆弱性割合（例：4〜6割）」といった具体的数値を載せる場合は、一次情報（IPA、学術調査、ベンダーのセキュリティレポート等）に当たって出典を明記。現状は数値を断定せず、定性的表現に留めています。 -->
手順1：いきなり「外部公開」「個人情報」「決済」に手を出さない
現役エンジニアが共通して指摘するのは、外部に公開するサービス・ユーザー管理・権限管理・個人情報・決済といった、セキュリティに深く関わる領域を「何も分からないまま」公開するのは危険、という点です。最初からここを狙うと壁にぶつかります。
手順2：3段階で“公開範囲”を広げる
安全な内製化は、公開範囲を少しずつ広げる順番で進めます。
- 自分専用：まずは自分だけが使うツールから。計算・変換・集計など、外部とデータをやり取りしないもの。
- 社内限定：チーム内だけで使うツールへ。この段階で「誰がデータを見られるか」を意識し始める。
- 外部公開：顧客など社外が使うものは、ここで初めて検討。公開前に必ず、分かる人（社内のITリーダーや外部エンジニア）のレビューを入れる。
手順3：「シークレット（鍵）」の扱いを最初に決める
アプリを作ると、外部サービスと接続するための「APIキー」などの**機密情報（シークレット）**が必ず出てきます。これをコードに直接書き込んだり、誤って公開したりすると、重大な情報漏えいや不正利用につながります。
- APIキーやパスワードは、コードに直書きせず環境変数などの仕組みで管理する。
- 鍵の保管・共有は、パスワードマネージャーなど安全な手段に一元化する。
- 「誰がどの鍵を持っているか」を棚卸しできる状態にしておく。
<!-- 内部リンク候補：パスワードマネージャー記事 / セキュアノート記事へ。COI：自社プロダクト（noxt）に言及する場合は本文冒頭・末尾にCOI開示を追加し、機能の具体的claimは社内確認後に記載。本文では現時点で製品名を出さず一般論に留めています。 -->
手順4：Supabaseの「公開範囲設定」を放置しない
Supabaseのようにデータベースを持つ構成では、**「誰がどのデータにアクセスできるか」の設定（行レベルのアクセス制御など）**を正しく行わないと、本来見えてはいけないデータが第三者に見えてしまう、という典型的な事故が起きます。AIが生成した初期状態のまま公開せず、アクセス制御が適切かを必ず確認しましょう。判断が難しければ、この部分こそ専門家に見てもらうべき箇所です。
手順5：ガバナンス — “誰が作って誰が承認するか”を決める
個人が勝手にツールを作って勝手に公開する状態は、「管理されないIT（野良ツール）」が社内に増える原因になります。これは、管理されないままAI利用が広がる「シャドーAI」と同じ構図です。 <!-- 内部リンク：経営者から始めるAI活用（初期編・シャドーAI） -->
だからこそ、内製化は経営者・責任者が旗を振り、最低限のルールを敷いたうえで進めるのが正解です。
- 作ってよい範囲・公開してよい範囲のガイドラインを決める。
- 公開前レビューを必須プロセスにする（誰がチェックするか）。
- 扱ってよいデータ／扱ってはいけないデータ（顧客個人情報・決済情報など）を明示する。
- 退職・異動時に、作ったツールと鍵を引き継ぐ運用を決める。
「自由に作らせる」と「野放しにする」は違います。枠を決めたうえで現場に任せるのが、内製化を事故なくスケールさせるコツです。 <!-- 内部リンク候補：中小企業のクラウドセキュリティ（NIST CSF 2.0）へ -->
「内製する／外注する」の判断基準
すべてを内製する必要はありません。境界線をあらかじめ決めておくと、コスト削減と品質の両立がしやすくなります。
内製が向いているもの
- 自分・チーム内で完結する業務効率化ツール（集計、変換、定型作業の自動化など）
- 試作・プロトタイプ。アイデアを素早く形にして検証したいとき
外注・専門家との協業が向いているもの
- 顧客の個人情報や決済を扱うシステム
- 基幹システムとの連携、長期運用を前提とした本番サービス
- 法規制・コンプライアンス対応が求められる領域
現場でよくあるのは、バイブコーディングで試作 → 事業化のタイミングで専門家を入れて本番化という流れです。最初からガチガチに固めず、成長に合わせて作り方も変えていく、という考え方が現実的です。
まとめ：小さく始めて、安全に広げる
- 非エンジニア中心の組織でも、業務アプリの内製化は現実的な選択肢になった。
- 最小構成として Claude（作る）＋Vercel（届ける）＋Supabase（ためる） は、役割が分かりやすく、資産としても残しやすい。
- ただし 会社利用なら最初から有料プラン前提。「無料のまま本番運用」は事故のもと。
- 何より重要なのは 安全な進め方。①自分専用→社内→外部の順で広げる、②鍵（シークレット）の管理を最初に決める、③公開前レビューを必須にする、④経営者主導でルールを敷く。
最初の一歩は、**「自分の毎日のちょっと面倒な作業を1つ、自分専用ツールにしてみる」**ことです。そこで得た手応えと注意点が、組織としての内製化を安全に広げる土台になります。
免責：本記事の料金・仕様は執筆時点の概算であり、変更される場合があります。導入の際は各サービスの公式情報を必ずご確認ください。本記事は一般的な情報提供を目的としており、特定の構成・サービスの採用を保証・推奨するものではありません。