実践記事は6本ある。バラバラに読むと、たいてい2本目で止まる。
理由ははっきりしていて、いきなり「環境構築が必要な回」や「APIキーを取る回」に入ってしまうからだ。
このページは、6本をやる順番に並べ直した地図。各回の「終わったと言える状態」と「つまずく場所」だけ先に渡しておく。
順路の全体像（5走＋常備1本）
作るものを毎回1つだけ増やす並びにしてある。前の回でできたことを、次の回で必ず1回使う。
| 走 | 記事 | 作るもの | 新しく増えること |
|---|---|---|---|
| 1走 | HTMLだけで自己紹介ページ | ファイル1つのページ | AIに作らせて、ブラウザで開く |
| 2走 | ToDoアプリを30分で作る | 動くアプリ | 機能を後から足していく |
| 3走 | ポートフォリオサイト | 公開されたサイト | PC環境・GitHub・公開 |
| 4走 | ブログをCloudflareで公開 | 更新できるサイト | 記事を増やす仕組み |
| 5走 | 天気APIダッシュボード | 外部データを使うアプリ | APIキーと、失敗したときの処理 |
| 常備 | エラーが出た！対処法 | — | 詰まったときに開く（走らない） |
この並びの意味
1走・2走はPCに何も入れずに終わる。3走で初めてPC側の準備が要る。「環境構築で心が折れた」を最後まで先送りにするための順番。
順路に入る前の2つだけ
ツールは1つに決めてから走る
決め方に迷ったら目的別のツール比較で1つ選び、5走が終わるまで替えない。
途中で乗り換えると、画面も操作も変わって「どこで詰まったか」が自分で分からなくなる。1走から5走までは同じツールで通す。
環境構築は3走の直前でいい
PC環境の準備は、3走に入る直前に読めばいい。 1走・2走はブラウザだけで完結するので、先に読むと単なる遠回りになる。
1走：HTML1枚（ここでゴールを体験する）
やること
AIに指示を出して、自己紹介ページを1ファイルだけ作らせ、ブラウザで開くところまで。
1走の記事にはブラウザで完結する作り方と、Claude Codeを使う作り方の両方が載っている。最初はブラウザ側を選ぶのが安全。
終わったと言える状態
- 自分の名前が入ったページがブラウザに表示されている
- 色や並びを1回以上、AIに言って変えてもらった
つまずく場所
「思ったデザインにならない」で止まりやすい。 ここは直し方の練習だと思っていい。記事の後半にカスタマイズ例が12個並んでいるので、そのまま真似して「言えば変わる」を体で覚える回にする。
2走：ToDoアプリ（機能を足す練習）
やること
追加・完了・削除が動くToDoアプリを一度作り、そこへカテゴリ・期限・並べ替えを1つずつ足していく。
2走の記事は8ステップに分かれている。1ステップ足すたびに動かして確認するのが唯一のコツで、まとめて3つ頼むと壊れた場所が分からなくなる。
終わったと言える状態
- 追加・完了・削除が動く
- 機能を3つ足しても壊れていない
- 壊れたとき、直前に頼んだ内容を自分で言える
つまずく場所
「さっきまで動いていたのに動かない」。 原因はほぼ、一度に頼みすぎたこと。指示の粒度そのものはAIへの指示の出し方の範囲なので、詰まったらそちらを1回読んでから戻る。
3走：ポートフォリオ（初めて外に出す）
やること
PCに必要なものを入れ、サイトを作り、GitHubに上げて、Cloudflare Pagesで公開する。
3走の記事は7ステップ。前半（環境）と後半（公開）で性質がまったく違う。1日で全部やろうとしないほうがいい。
終わったと言える状態
- URLを人に送れる
- 中身を直して、もう一度反映できた（1回で終わりにしない）
つまずく場所
インストール系のエラーがここに集中する。 Mac / Windows で出方が違うので、この回に入る前にエラー対処の記事を開いた状態で始めるのが現実的。
3走は「公開」まで行かないと意味が薄い
作っただけで止めると、次の4走（更新し続けるサイト）に何もつながらない。時間が足りないときは、デザインを削ってでも公開まで行く。
4走：ブログを公開（増やせる形にする）
やること
Astroでブログを作り、記事をファイルで増やせる状態にして公開する。
4走の記事では、記事1本＝ファイル1つという形と、カテゴリ・タグ、公開までの手順を扱う。3走で一度公開しているので、公開作業そのものは2回目になる。
終わったと言える状態
- 記事を1本足して、公開されたページに出た
- 「次の記事を書くときにやること」を自分で説明できる
つまずく場所
frontmatter（記事の先頭にある設定行）のズレでビルドが止まる。 これはエラー文が親切なタイプなので、エラー文をそのままAIに貼るのが最短。
5走：天気API（外のデータを扱う）
やること
APIキーを取得して外部の天気データを取り込み、表示し、失敗したときの処理まで入れる。
5走の記事は、キーの取得 → 取得したデータの表示 → エラー処理 → 予報の追加、という並びになっている。5走を最後にしているのは、失敗のパターンが一番多い回だから。
終わったと言える状態
- 自分のキーでデータが表示される
- 通信に失敗したときに、画面が真っ白にならない
- キーをそのまま公開しない置き方が分かっている
つまずく場所
キーまわり。 発行直後は使えないことがある・キーを貼る場所を間違える・そのまま公開してしまう、の3つ。ここだけは慎重に進める。
APIキーは「パスワード」と同じ扱い
キーを書いたファイルをそのまま公開すると、他人に使われて課金される可能性がある。記事内のキー管理の章は飛ばさない。
常備：詰まったときに開く1本
5走の途中で必ず何か壊れる。壊れてから探すのではなく、最初からタブで開いておく。
エラーが出た！対処法には、よくあるエラーの型と、AIにエラーを報告するときの書き方、直らないときに上げていく手順が並んでいる。
エラー文の読み方そのものに慣れたい人はAIと一緒にデバッグするを先に。「エラーが出た」とだけ書いてAIに投げるのをやめられれば、この順路の体感難易度は半分になる。
この順路でやってはいけない3つ
| やりがち | 何が起きるか | 代わりに |
|---|---|---|
| 走ごとにツールを替える | 詰まった原因が操作なのか指示なのか分からなくなる | 5走まで同じツールで通す |
| 1回の指示で3機能まとめて頼む | 壊れた場所が特定できず、戻せなくなる | 1機能ずつ足して毎回動かす |
| 動いたら中身を一切見ない | 5走のキー管理のような「見えない事故」を踏む | 信用していい所・確認すべき所の観点だけ通す |
よくある質問
Q. 全部やるのにどれくらいかかりますか？
A. 走ごとに区切って進めるのが前提です。 2走のToDoアプリは記事タイトルどおり30分規模ですが、3走は環境の準備と公開が入るので、1日で終わらせようとせず前半・後半に分けたほうが完走率は上がります。
Q. 順番を飛ばして、作りたいものから始めてはダメですか？
A. 作りたいものがはっきりしているなら、それが最優先です。 ただしその場合も、詰まったときに戻る場所として1走・2走は残しておいてください。「小さく作って足す」型を先に身につけている人ほど、大きいものが完成します。
Q. 6本のうち1本だけやるなら？
A. 2走のToDoアプリです。 「一度作って、そこへ機能を足していく」というvibe codingの中心の動きが、この1本にだけ丸ごと入っています。
Q. コードが読めないままでも進められますか？
A. 進められます。 この順路は写経が目的ではありません。ただし5走のAPIキーの扱いだけは、読めなくても「どこに置くか」を理解して進んでください。
Q. 途中で作ったものは残しておくべきですか？
A. 残してください。 3走以降はGitHubに上がるので自動的に残ります。1走・2走のファイルもフォルダごと取っておくと、後から「同じものをもっと速く作れる」を実感できます。
Q. そもそもvibe codingが何かあいまいなまま始めてもいいですか？
A. 1走を先にやってからで構いません。 用語や全体像を先に整理したい場合だけバイブコーディングとはを読んでから戻ってきてください。
まとめ
- 順番は 1走HTML → 2走ToDo → 3走ポートフォリオ → 4走ブログ → 5走API
- 環境構築は3走の直前まで先送りしていい
- エラー対処の1本は最初からタブで開いておく
1走は今日中に終わる。まずはHTML1枚の自己紹介ページから。
