開発環境とデプロイ
情報この章の要点
非エンジニアが挫折しやすいのは、Webアプリ・デプロイ・DB連携の「フル装備」をいきなり組もうとするときです。環境選びもYAGNI（今すぐ不要なものは作らない）と同様、段階的に必要な分だけ進めるのが成功の鍵です。
1. 環境選びも「段階的」であるべき理由
アプリ（バイブコーディング）総論の「作らないがデフォルト」は、環境選びにもそのまま当てはまります。一番身近で・一番準備がいらない環境から入り、必要になった分だけ次へ上げていきます。
いきなり本格的なWebアプリの構築を目指すと、多くの場合、環境設定の複雑さに直面し、開発を始める前に挫折してしまいます。非エンジニアが陥りがちな典型的なパターンです。
2. 開発環境は、目的と難易度で選ぶ
環境は大きく2つに分かれます。チャットの中で作る（Canvas）とGAS＋スプレッドシートは、それぞれ独立した「準備ゼロで試せる」入り口です。その先のWebアプリ（ローカル）→デプロイは、必要な機能が増えるほど段階を上げていく、地続きの道のりです。DB連携はこれらとは別軸の話で、「データを永続的に残したいか」が出てきたタイミングで考えます。ローカルの段階で組み込むことも、デプロイした後から足すこともできるので、必ずデプロイの後に来るわけではありません。現在の要件が手前で満たせるなら、無理に先へ進む必要はありません。
準備ゼロで試せる、2つの入り口
チャットの中で作る（Gemini Canvasモード）
Geminiのチャット画面で「Canvas」モードをONにすると、プロンプトからそのまま動くWebアプリを作れます。生成されたアプリはその場でプレビューでき、共有ボタンでURLを発行すれば、相手のブラウザでもそのまま動きます。インストールも環境構築もゼロ。「作って、配る」を最短で体験できる準備運動です（ChatGPTのCanvas・ClaudeのArtifactsにも同種の機能があります）。
- 向いている用途：見積もりシミュレーター・診断チェックリスト・企画のたたき台デモなど、1画面で完結し、データ保存が要らない道具
- なぜ気軽に試せるか：ブラウザだけで完結し、失敗のコストがゼロだからです。「言葉で道具が生まれる」感覚を、まずここでつかんでください
例AIへのプロンプト例
「Canvasで、研修受講前のセルフチェックアプリを作ってください。質問は5問（はい／いいえ）、全問回答すると『AI活用の準備度』を3段階で判定してコメント付きで表示します。スマホでも見やすいシンプルなデザインでお願いします。」
注意点は2つです。共有リンクは受け取った人なら誰でも開けるため、顧客名や社内の数字を埋め込んだまま配らないこと。そしてデータは保存されないため、入力値を貯めたくなったら、GASやWebアプリなど別の環境を検討する合図です。
GAS＋スプレッドシート
メモ✏️ 用語メモ：GAS（Google Apps Script）
Googleスプレッドシートやドキュメントの上で動く、Google謹製の簡易プログラミング環境です。ブラウザだけで書けて、パソコンに何かをインストールする必要がありません。Google Workspace（Gmail・カレンダー・ドライブなど）と直結しているのが特徴です。
ブラウザだけで書けて環境構築が要らず、Google Workspaceと直結しているのが強みです。
- 向いている用途：フォーム連携、定型メール送信、表計算の自動集計
- なぜ気軽に試せるか：インストール不要・無料・失敗しても被害が小さいからです。「AIと一緒にコードを書く」感覚を、最小のコストでつかめます
- 関連スキル：Google Apps ScriptをPCから管理・デプロイする「Clasp」を利用することで、より高度なバージョン管理や自動化が可能です。
.png)
代表的な使いどころは、フォーム回答への自動お礼メール、毎週月曜朝の売上集計の通知、表記ゆれだらけのCSVをボタン一つで整形——といった「Googleの中で完結する定型処理」です。指示のコツは、どのシートのどこにデータがあり、何をきっかけに、どこへ出力するかを日本語で明確に伝えること。これだけでほぼ一発で動くコードが出てきます。
例AIへのプロンプト例
「Googleスプレッドシートの『問い合わせ』シートにフォームから新しく行が追加されたら、その行のB列（名前）とC列（メールアドレス）を取得し、自動でお礼メールを送るGASコードを書いてください。メール送信後、D列に『送信完了』と現在日時を書き込んでください。」
つまずきやすいのは2箇所です。初回実行時に出る「このアプリは確認されていません」という警告は安全上の仕様で、「詳細」から承認すれば進めます。もう1つ、「フォーム送信時」「毎日◯時」のような自動実行は、コードを書くだけでは動きません。GASエディタのトリガー（時計マーク）から設定を追加して、初めて動き出します。
ヒント💡 番外｜Chrome拡張機能も同じくらい手軽
ブラウザに機能を足す小さなプログラム（manifest.jsonという設定ファイル＋JS/HTMLのコード）です。サーバー環境の準備や、コードを動作可能な形に変換する「ビルド」作業も不要です。chrome://extensionsからデベロッパーモードを有効にし、「パッケージ化されていない拡張機能を読み込む」だけで、すぐに動作を確認できます。難易度感はGASと並びます。
違いは向く用途です。GASはGoogle Workspace（スプレッドシート・Gmail等）と直結していますが、Chrome拡張は今見ているページそのものに介入できます（自動入力・情報抽出・特定サイトの繰り返し操作）。社内利用だけなら公開申請は要らず、デベロッパーモードのままで足ります。外部に配りたくなって初めて、Chromeウェブストアへの申請（審査あり）を検討します。
ここから先は、地続きの道のり：Webアプリ→デプロイ
Webアプリ（ローカル実行）
AIコーディングエージェント（Claude Code等）でコードを書き、自分のPC上だけで動かして確認する段階です。ブラウザで http://localhost:○○○○（localhostは「自分のパソコンの中」を指すアドレスです）を開いて挙動を見ます。まだ誰にも見せません。
- 向いている用途：GASでは足りない複雑なロジック・独自のUI
- この段階の主な目的は、作成したアプリが「期待通りに動作するかどうかの検証」です。アプリの公開はまだ先のステップとなります。アプリ（バイブコーディング）総論で解説した「小さく動くものを出し、触って直す」というサイクルは、まさにこのローカル実行段階で実践するものです。
デプロイ
ローカルで動いたものを、インターネット上に置いて誰でも（または自分だけ）アクセスできるようにする作業です。代表的なデプロイ先はVercel・Netlifyなど（個人利用なら無料枠で足りることが多いです）。
- アプリがインターネットに公開されることで、「問題が発生したらどうしよう」という緊張感が初めて生まれます。そのため、この段階からバージョン管理（コードの変更履歴を記録し、いつでも以前の状態に戻せる仕組み。次節のGitHubで詳しく解説）が実務的に必須となります。
- デプロイサービスの多くは、GitHubと連携してコードを更新するたびに自動で反映する仕組みを持っています
別軸で考える：DB連携
メモ✏️ 用語メモ：データベース（DB）
情報を整理してためておき、あとから検索・更新できるようにする仕組みです。Excelの表をもっと大規模・高速に、複数人で同時に触れるようにしたもの、とイメージするとわかりやすいです。
データベースと接続し、入力・記録を永続的に保存できるようにする話です。ここまで紹介した環境の中で最も難易度が上がります。ローカルで動かしている段階から組み込むこともできますし、まずデータ保存なしでデプロイしてから、必要になった時点で後付けすることもできます。スキーマ設計（データベースの中の「表の形」をあらかじめ決めておく設計作業）、権限設計（権限を最小に絞ると直結）、移行（マイグレーション：データベースの構造を、データを失うことなく安全に変更する作業）といった専門的な作業が絡んできます。
- 個人の小規模用途なら、スプレッドシート・Notion・ローカルのファイル（json/md）で足りるケースが多いです。「本当にデータベースが必要なのか」を、アプリ（バイブコーディング）総論で提示した4つの閾値に立ち返って自問してみてください。
- 段階を踏むなら、まずローカル完結のSQLite（パソコンの中だけで完結する軽量データベース）から始め、複数人・複数端末からのアクセスが要るときにマネージドDB（Supabase等、データベースの管理を代行してくれるサービス）へ進みます
3. 外部連携の要: APIとは何か、どう使うか
メモ✏️ 用語メモ：API
プログラム同士がデータや機能をやり取りするための「窓口」です。例えば天気予報アプリが気象庁のAPIを呼び出して最新の気温データを受け取る、というように使います。「注文票」に例えられることもあります。欲しいデータや機能を決まった形式で注文すると、決まった形式で答えが返ってくる仕組みです。
アプリケーション開発を進めていくと、多くの場合、「外部のAPIを利用する」場面に遭遇します。GASでもWebアプリでも、どの環境でも登場する重要な技術で、特にWebアプリ以降の段階で頻繁に出てきます。
APIには2つの立場があります。呼ぶ側（利用側）——自作アプリからOpenAIや気象庁など外部サービスのAPIに「注文票」を出してデータや機能を受け取る使い方。もう1つが公開する側（提供側）——デプロイした自作アプリが、逆に外から注文を受け付ける側に回る使い方です。最初に出会うのはほぼ前者で、その際に必要になる「APIキー」の管理が最初の関門になります。
APIキーの扱い（コードに直書きしない、環境変数で扱う）は権限を最小に絞るの考え方がそのまま効きます。API自体の基礎はデータとつなぐで扱っています。
GitHubとの実際の付き合い方はGitとGitHubで詳しく扱っています。
4. 再度確認: 次の段階に進むべきかの判断基準
環境を上げる前に、アプリ（バイブコーディング）総論の4つの閾値（既製ツールの限界・反復頻度・データ主権・長期コスト）に戻って自問しましょう。
「次の段階に進めるから進む」のではなく、「進む理由があるから進む」。 これは環境選びにも、そのまま当てはまります。
5. AIに相談してみよう: あなたの最適な開発環境を見つける例
「自分の作業はどの段階から始めればいいか」も、具体的な作業内容を伝えてAIに聞いてしまうのが早道です。
例依頼文の実例（どの段階から始めるべきか相談する）
「プログラミングはほぼ未経験です。やりたいことは〔具体的な作業内容〕で、今は〔現状のやり方〕で対応しています。GAS＋スプレッドシート／ローカルのWebアプリ／デプロイして公開／データベース連携、のどの段階から始めるのが向いていますか。理由も添えて、初心者にもわかるように教えてください。」
「向いている環境」を教えてもらったら、そこからさらに「まずそれだけで試してみたい」と伝えれば、無理に先の段階まで話が進むことはありません。このように、AIとの対話においても、焦らずに段階を一つずつ確認しながら進める意識を持つことが、最適な環境構築への近道となります。