Vibe Coding

Vibe Codingでは、日本語で目的を伝えると、AIが画面やコードを短時間で組み立ててくれます。最初の試作品が早く見えるのは、大きな魅力です。

一方で、画面が動いた瞬間に「ほぼ完成」と感じやすくなります。保存の仕組み、本人確認、公開後の観測は、見た目からは分かりません。

速く作れることと、安全に届けられることは別の能力です。この講座では、開発を一本の長い作業ではなく、目的の異なる駅を乗り継ぐ旅として扱います。

このレッスンの目的

このレッスンを終えると、次の三つができるようになります。

1. 開発路線図の「駅」と「路線」が何を表すか説明する
2. いま取り組んでいる作業の現在地を一つ選ぶ
3. 次へ進む前に必要な確認と安全線を書く

今日のゴールは、全部の用語を暗記することではありません。 自分がどこにいて、次に何を確認するかを言える状態を作ります。

所要時間の目安は、読了10分 + 実習14分です。

概念：完成ではなく現在地を見る

開発路線図の駅は、技術の種類ではなく、その時点で答える問いを表します。アイデア駅では「誰の何を良くするか」、データベース駅では「何をどんな形で保存するか」、公開駅では「第三者へどう届け、問題時にどう戻すか」を考えます。

路線は進み方の軸です。「つくる線」は課題から画面までをつなぎ、「データ線」は保存や認証を扱い、「公開線」は品質確認と公開をつなぎます。「育てる線」は利用状況を見て次の改善を決めます。

たとえば、架空の読書メモで登録ボタンが動いたとします。その事実から分かるのは、入力を画面内の一覧へ渡せたことまでです。再読み込み後も残るかを確かめるには、保存先と読み出しを扱うデータベース駅へ進みます。架空アカウントAのメモがBから見えないかを確かめるなら、認証と権限の駅が必要です。第三者へ届ける前には、テスト結果、公開先、監視、戻し方を公開線で確認します。利用が始まった後は、数値と声を育てる線へ持ち帰り、最初の課題へ本当に効いたかを見直します。このように一つの画面でも、答える問いを変えながら複数の駅を通ることで、見た目の完成と提供できる状態を混同せずに済みます。

地図は作業を増やす表ではなく、確認漏れを見つける表です。

駅は問い、路線は問いをつなぐ順序です。同じ駅を一度通ったら終わりではありません。試作品で通り、公開前にもう一度通り、利用者の反応を受けて戻ることもあります。

見える完成と、見えない未完成

画面に一覧と登録ボタンがあれば、アプリらしく見えます。しかし、再読み込みして内容が残るか、別の利用者から見えないか、失敗時に戻せるかは別の確認です。

たとえば架空の「読書メモ」を作るとします。カードが追加できても、ブラウザを閉じたら消えるならデータベース駅は未通過です。誰でも編集できるなら認証駅が未通過です。公開URLがあっても異常を検知できなければ監視の準備が残っています。

動いた画面は到着ではなく、現在地を知らせる標識です。

実習：ダミー企画を路線図へ置く

実習では、実在する人や業務の情報を使いません。次の架空企画だけを使います。

企画名: まちの読書メモ
対象: 架空の読書会メンバー
やりたいこと: 架空の本の題名と一言メモを登録し、一覧で見返す
使うデータ: 「星空図鑑A」「海辺の物語B」など、実在性のない文字列
公開範囲: まずは手元だけ

紙かテキストファイルへ、次の「開発ルートカード」を書いてください。

現在地:
いま答える問い:
確認できた証拠:
まだ確認していないこと:
次の駅:
進む前の安全線:

まず現在地を「アイデア」にします。いま答える問いは「誰が何を見返せると便利か」です。証拠はまだないため「架空企画として仮置き」と書きます。

カードを書くときは、企画全体を一度に完成させようとしません。最初に、直前の操作で自分が観測した事実を一文に固定します。次に、その事実からは言えないことを、保存、認証、公開、分析、履歴の観点で分けます。それぞれを「できていない」と断定せず、「まだ確認していない」と書くのが重要です。未確認の中から、いまの目的に最も近い問いを一つ選び、次の駅へ置きます。最後に、使うデータ、外部影響、止まる条件を安全線へ書き、進める範囲を狭くします。この順序なら、AIが多くの変更案を出しても、カードにない作業を増やさず、結果を同じ基準で比較できます。

一枚のカードには、現在地と次の一駅だけで十分です。

次の駅には「需要検証」を選びます。ただし今回は実在する人へ連絡しません。練習の目的は調査ではなく、未確認を未確認のまま記録することです。

続いて、完成した画面を想像し、見た目から判断できない項目を五つ書きます。保存、認証、公開、分析、変更履歴を入れてください。

保存: 再読み込み後もダミーメモが残るか
認証: 架空アカウントごとに表示を分けられるか
公開: 第三者が開ける場所へ出す前に確認があるか
分析: 何を改善するために何を数えるか
変更履歴: どの変更から問題が起きたか追えるか

分からない欄を推測で埋めないことが、この実習の重要な操作です。「未確認」と書けば、次の駅が見えます。

正常な結果

次の6項目を自己採点します。一つでも空欄なら、カードを直してから次へ進みます。

• 現在地を一つの駅で示した
• いま答える問いを一文で書いた
• 自分で観測した証拠と、AIの報告を分けた
• 未確認事項を保存、権限、公開などの観点で残した
• 次の駅を一つだけ選んだ
• ダミーデータと外部影響の安全線を書いた

6項目すべてにチェックが付けば正常です。

よくある失敗

失敗1：画面が出たので公開駅まで進んだことにする

見た目の完成度が高いほど起きやすい失敗です。画面表示はフロントエンドの確認であり、保存、権限、公開、監視の確認を代替しません。

失敗2：知らない用語を全部調べ始める

地図には多くの駅があります。最初から全用語を理解しようとすると、現在地の問いが消えます。

失敗3：AIの「完了しました」を証拠にする

AIの報告は確認候補です。実際の画面、テスト結果、差分、公開URLなど、対象に合った証拠を人間が見るまで完了ではありません。

復旧：一駅前へ戻す

現在地が分からなくなったら、最後に自分で確認できた事実を一つ書きます。「登録ボタンを押すと、画面内に架空のカードが増えた」のように、観測した範囲だけを書きます。

次に、その事実からは言えないことを分けます。「再読み込み後に残るかは未確認」「別の架空アカウントとの分離は未確認」と書きます。

最後に、未確認を確かめる駅を一つ選びます。保存ならデータベース、本人の区別なら認証、第三者への提供なら公開です。

迷ったときは、最後の証拠まで戻る。 これが路線図での復旧方法です。

安全メモ

この講座の実習では、実在する氏名、連絡先、記録、アカウント、業務データを入力しません。すべて明らかなダミーデータを使います。

APIキー、パスワード、秘密のURLも本文やAIへの依頼へ貼りません。必要になる駅では、値そのものではなく、保管場所と読み込み方法を学びます。

公開、課金、メール送信、データ削除など外部へ影響する操作は、画面を作る作業とは分けます。外部影響がある操作は、自動で進めず人間の確認点を置きます。

成果物

このレッスンの成果物は、次の六項目が埋まった「開発ルートカード」です。

現在地: アイデア駅
いま答える問い: 架空の読書会で何を見返せると便利か
確認できた証拠: 練習用の仮説を一文にした
まだ確認していないこと: 保存、認証、公開、分析、変更履歴
次の駅: 需要検証駅
進む前の安全線: ダミーデータだけを使い、外部公開しない

良い成果物は、進捗を大きく見せるものではなく、次の判断を小さくするものです。作業のたびにこのカードを更新してください。

用語集

• 履歴へ戻るときはGit、保存を確かめるときはデータベースを参照する
• 利用者を区別する問いは認証、検証済みの版を反映する問いはデプロイメントへ分ける
• 公開後の改善判断ではアクセス解析を使い、表示できた事実と利用結果を混同しない

用語は定義を書き写すためではなく、いま答える問いを選ぶために使います。

次の駅

企画上の次駅

架空企画では「需要検証駅」です。誰のどんな不便を扱う仮説なのかを、まだ作り始めずに確かめます。

教材上の次レッスン

次は「人間が判断すること」です。AIに作業を任せても、目的、安全、受入条件、公開の判断は自動では決まりません。

路線図で現在地を見つけたら、次はその駅で誰が何を決めるかを分けます。

今日のまとめ

3行で振り返ります。

• 開発路線図の駅は問い、路線は問いを安全な順序でつなぐ進み方
• 動く画面だけで完成とせず、確認済みの証拠と未確認を分ける
• 迷ったら最後に自分で確認できた事実へ戻り、次の駅を一つ選ぶ