1
ボタンは正しく見えるのに、押しても反応しない
短いタスク名を入力してAddをクリックします。新しい行が表示されなければ、どのボタンをクリックし、何を入力し、何が表示されるはずだったかをVibe Codeに伝えましょう。見た目の変更を依頼する前に、まずその操作だけが機能するよう依頼してください。修正後は、空欄のままでも試しましょう。ページは空欄の入力を明確に拒否するか、意図に沿って処理する必要があります。
実践ガイド
最初のプロジェクト：初心者向けバイブコーディングチュートリアル
この初心者向けバイブコーディングチュートリアルでは、シンプルなタスクリストページを作ります。実現したい動作を説明し、結果を確認して、次に何を変更するか決めましょう。
事前に必要なもの
小さなタスクリストページで、作業の一連の流れを十分に練習できます。最初のプロンプトを書く前に、アプリ全体を計画する必要はありません。
番号付きの手順
バイブコーディングでは、毎回この短いサイクルを繰り返しましょう。範囲を絞って依頼し、自分で試してから、具体的な修正を1つ依頼します。
-
1
最初のバージョンを説明する
テキスト入力欄、追加ボタン、チェックボックス、完了済みタスクを削除する方法を備えたタスクリストページを依頼しましょう。ページを再読み込みした後の動作を伝え、見た目に関する要望はシンプルにしましょう。
-
2
表示された結果をテストする
タスクを追加し、完了のチェックを入れ、完了済みタスクを削除してから、ページを再読み込みしましょう。見た目でプロジェクト全体を判断せず、どの操作がうまくいかなかったかを正確に記録してください。
-
3
修正を1件依頼する
失敗する操作と期待する動作を伝えます。たとえば、更新後にタスクが消える場合、本来は残るべきです。変更後に同じ操作を再テストします。
作業環境を準備する
必須項目があれば、このチュートリアルでは確認できる動作に集中できます。任意項目があれば、使いにくい点を見つけやすくなります。
必須
任意
-
生成されたページを開いて操作できるブラウザー — 動作を確認するには、コントロールをクリックしてページを再読み込みする必要があります。
-
タスクリストページを説明する1文 — ユーザーの操作と、その後に起こるべきことを記述します。
-
簡単なテスト項目：追加、完了、消去、更新 — 関連する変更を加えるたびに、同じ項目を確認します。
-
個人情報を含まないタスク名の例 — まず通常のテキストを試し、次に空欄と長い入力を試します。
-
幅を狭くしたモバイルブラウザーのウィンドウ任意 — ボタンを操作でき、タスクのテキストを読めるか確認します。
次に作るものを選ぶ
この小さなページが動いたら、一度にすべての機能を追加するのではなく、新しい課題が1つあるプロジェクトに進みましょう。
ワークフローが形になるまで
ツールは変わりましたが、このチュートリアルで役立つ習慣は変わりません。次の出力を求める前に、まず出力されたものを確認しましょう。
-
コードの提案が身近に
GitHub Copilotのテクニカルプレビューによって、AIによるコード提案がエディターでの作業に取り入れられました。それでも開発者は提案を読み、適切かどうかを判断する必要がありました。
-
会話形式での依頼が広がる
ChatGPTの一般公開により、プログラミングの作業を日常的な言葉で説明し、結果について追加で質問しやすくなりました。
-
プレビューして修正する流れが広がる
生成された画面のプレビューを表示するツールによって、依頼した画面と実際に表示された画面を比較し、具体的な変更を伝えやすくなりました。
-
バイブコーディングという名前が付く
Andrej Karpathyがバイブコーディングという言葉を広めました。初心者にとって大切なのは、すべての出力をそのまま受け入れることではありません。ページを実行し、実際に何が起きたかを伝えることです。
よくあるエラーと修正方法
予期しない結果は、次のプロンプトに役立つ手がかりとして扱いましょう。ただ「もっと良いものにして」と繰り返すよりも、以下の確認を行うほうが確実です。
2
ページを更新するとタスクが消える
まず、ページを再読み込みする前に、タスクの追加と完了が機能することを確認します。次にページを更新し、リストが残っているかを確認します。消えた場合は、ブラウザーのセッション中または使用中のデバイスにタスクを保存するよう依頼し、既存の追加操作と完了操作は引き続き機能させるよう伝えましょう。こうすれば修正結果を確認しやすくなり、修正によって別の操作が壊れるのを防げます。
3
画面幅を狭くするとレイアウトが崩れる
ブラウザーの幅を狭め、ボタンが途中で切れていないか、タスク名がはみ出していないか、操作部分が近すぎないかを確認します。全面的なデザイン変更を求めるのではなく、画面上の具体的な問題を伝えましょう。レイアウトの変更後は、狭い幅と広い幅の両方でタスクの操作を再テストしてください。見た目の変更が、クリックできる範囲に思わぬ影響を与えることがあります。
応用のヒント
動くデモは有用な到達点ですが、あらゆるエッジケースが解決済みである証拠ではありません。機能を拡張する際は、次の限界を念頭に置いてください。
1
見栄えのよいプレビューだけでは、正しく動くことを証明できません
タスクリストのページが完成しているように見えても、チェックボックス、消去操作、更新後の動作が壊れている場合があります。
代わりにすべきこと
変更するたびに同じ4つの操作をテストし、どの操作が失敗したかを正確に記録してください。
2
このチュートリアルではセキュリティを検証しません
小規模なローカル演習では、生成されたコードが機密データの取り扱いや一般公開に対して安全かどうかは確認できません。
代わりにすべきこと
架空のサンプルタスクを使い、秘密情報は入力しないでください。実際のユーザーデータを扱う前に、別途コードレビューとセキュリティレビューを受けてください。
3
1つのプロンプトですべてのエッジケースを指定することはできません
空の入力、極端に長いテキスト、クリックの繰り返しでは、通常の操作時と異なる動作をする場合があります。
代わりにすべきこと
テスト項目にエッジケースを1つずつ追加し、失敗するたびに具体的な修正を依頼してください。
4
ブラウザー内だけのリストは、デバイス間で共有できるストレージではありません
1台のデバイスでページを更新してもタスクが残るからといって、別のブラウザーやデバイスにも表示されるとは限りません。
代わりにすべきこと
ストレージやアカウント関連の機能を依頼する前に、デバイス間でのアクセスが本当に必要か判断してください。
テストできる最初のバージョンを作る
まずタスクリスト用のプロンプトを使い、各操作を自分で確認してください。この初心者向けバイブコーディングチュートリアルは、追加の依頼ごとに、確認した問題とテスト可能な結果を明記すると最も役立ちます。
チュートリアルのよくある質問
入力欄、Addボタン、チェックボックス、完了したタスクを消去する操作を備えたタスクリストページを作りましょう。各操作の結果を目で確認できるため、大まかに説明された大規模なアプリよりもテストしやすくなります。
まずは普通の言葉でページを説明し、ブラウザーで各操作を試すところから始められます。基本的なエラーメッセージの読み方やページの構成要素を覚えると、より的確に修正を指示できます。
ページの名前、必要な操作部品、各部品に期待する動作を書きましょう。更新後もタスクが残ることなど、重要な要件を1つ加え、装飾の細部は後回しにします。
何を操作し、実際に何が起き、代わりにどうなるはずだったかを説明しましょう。たとえば、タスクを入力してAddをクリックしても項目が追加されないと伝え、その操作の修正を依頼してから再テストします。
この演習では、タスクの追加、完了への変更、完了したタスクの消去ができ、ページを更新してもタスクが予期せず消えなければ完了です。最初のバージョンを完成とする前に、空欄での追加と幅の狭い画面も試しましょう。