自分のアプリを世界に出す

この講義のテーマは「自分のアプリを世界に出す」ことです。ただしWebアプリケーションのリリース方法だけを説明するのではなく、リリースまでの流れ全体を、これまでより解像度を上げて見ていきます。前半は第1章で扱った図解スキルを題材に、GitHubにリポジトリ(プロジェクトの保管庫)をゼロから作り、開発して、再びリポジトリに上げるまでの「開発の一周」を通します。後半はNext.jsで作った本格的なWebアプリケーションを、Vercelという公開サービスで世界に出すところまでを実演の形で追いかけます。

講座はここまで階段を一段ずつ登ってきました。1ヶ月目はAI-Drivenな人材になるための土台となる考え方と図解、2ヶ月目は手でやっていた報告作業を仕組みに置き換える自動報告ツール、3ヶ月目は自分の仕事の型を画面の構造にした自分専用ツールの作成です。第3章の前半では「これを使えば間違いない」という鉄板フレームワークとしてNext.jsとshadcn/uiを紹介しましたが、その時点ではまだ名前を知った状態でした。一度の説明で完璧に理解できる人はいません。この講義では、それぞれが何のための道具で、どう繋がっているのかを、自分の言葉で語れる水準まで引き上げていきます。

開発の全体像 ─ 図解スキルを作る最短距離

最初に、開発プロセス全体を自分の頭で組み立てるワークが行われました。

このワークに絶対的な正解はありませんが、講師が示した一例は次の10ステップです。

1. PoC — Surgeを使ったことがないので、図解のWebページを実際に上げられるか試す
2. GitHubでリポジトリを作る
3. Cursorでクローンする — リポジトリを手元に持ってくる
4. AIルールを置く(任意。このタイミングでなくてもよい)— CLAUDE.mdやAGENTS.md、Cursor Rulesのこと
5. grill-meでやりたいことを詰める — どんな図解を何のために作るのか
6. 模範解答として実際の図解を1枚作る
7. スキルを作る — 模範解答と同じような図解を作れるようにする(creating-skillsの活用)
8. Surgeへのアップ処理をスキルに組み込む — 1コマンドで図解を公開できる状態にする
9. サブエージェントレビュー — 完成したスキルの品質を別のサブエージェントに厳しく見てもらう(タイミングは前後してよい)
10. GitHubにプッシュする

この前半パートは単なる復習ではありません。講師はここで印象的な例え話をしています。これまでの講義は、大阪から東京まで飛行機の上から景色を見てきたようなものです。今回は電車に乗ってゆっくり景色を見ていきます。しかし実際に自分でやるときに乗るのは、飛行機でも電車でもなく自転車です。いざ漕ぎ出すと「まず何からやればいいんだっけ」「この道はどっちだっけ」という小さなわからないことが無数に出てきます。ありがたいことに、今の時代は細かいところほどAIに聞けば答えが返ってきます。東京から大阪に行きたい、という行き先は人間にしか決められませんが、行き先さえ決まっていれば道中の膨大な道のりはAIがナビゲートしてくれるのです。

ステップ1|PoC ─ 使ったことのない技術は最初に試す

最初にやるのはPoC(Proof of Concept、やりたいことが本当にできるかの試し打ち)です。第2章の自動議事録ツールでは、MVP(最小限の価値を検証するためのプロダクト)を定義したあと、会議中にリアルタイムでタスクを表示できるかをPoCで検証しました。

今回はSurge(シンプルなWebページを公開できる無料サービス)を「知ってはいるが使ったことがない」前提です。こういうときこそPoCすべきタイミングです。最後の工程で「Surgeに上げれば終わり」と思っていたら、うまく動かない、想定と動きが違った、実はお金がかかった、思ったより使いにくい、といった思いもよらない落とし穴に当たることがあります。

PoCの進め方は次のとおりです。

1. テスト用フォルダを作る。まだリポジトリはないので、zukai-tempやzukai-pocのような使い捨てフォルダで構いません。終わったら消す前提なので雑でよいのです。ただしフォルダ名・ファイル名は半角英数が無難です。日本語名は稀にエラーの原因になるため、不要なリスクを排除します。なおフォルダは「ディレクトリ」とも呼ばれます。開発者寄りの呼び方がディレクトリで、その程度の理解で困ることはありません。
2. Cursorでフォルダを開く。スタート画面にはOpen Project、Clone repo、SSHの3つがあります。自分のパソコン内のフォルダを開くならOpen Project、GitHubから持ってくるならClone repoです。SSHは別の場所にあるパソコンのフォルダを開くような機能で、頻繁に使うものではないため今は覚えなくて構いません。
3. AIモデルを選ぶ。講師は普段ClaudeのOpus最新モデルを使うことが多いものの、コストが高いのが難点です。コストを抑えるならCursor提供のComposer、いちばんバランスがいいのはClaudeのSonnet、Codexもよい選択肢です。実演ではSonnetのMediumが使われました。
4. AIに依頼する。例えば「Surgeというサービスがあると聞きました。Webページが動くか検証したい。簡潔なサンプルを作って動かしてみて」と書きます。初めての場合はメールアドレスとパスワードの登録を求められます。「チャットではできないのでターミナルで実行して」と言われることもありますが、ターミナル(コマンドを打ち込む黒い画面)はCursor上で開いて実行できます。

ターミナルについての補足です。講師はMacで、cmuxという無料のターミナルを使っていますが、iTermやMac標準のターミナル、WindowsのPowerShellなど、どれも基本は同じです。最初のうちはCursor内蔵のターミナルで十分です。

Surgeにログインしてサンプルのindex.htmlを上げると、ブラウザで見られるようになります。ここで重要な対比があります。AIはいきなりSurgeのサーバー上にページを作ったわけではなく、まずフォルダ内にローカルファイル(自分のパソコン上のファイル)を作っています。ローカルのindex.htmlを開いても同じ見た目が表示されますが、URLが違います。Surge版はSurgeのサーバー上のものが見えており、ローカル版は自分のパソコン上のファイルがブラウザに表示されているだけです。パソコン内の画像を他人が見られないのと同じで、ローカルファイルは他の人からは見えません。他人に共有するにはSurgeにアップするか、ファイル自体を送る(例えばzipに圧縮して送り、相手が解凍して見る)しかないのです。

検証したかった「SurgeでWebページを公開できるか」が確認できたので、PoCは終了です。

ステップ2|GitHubにリポジトリを作る

次はGitHub上にリポジトリという入れ物を作ります。リポジトリは1つのプロジェクト分の箱です。今回作る図解スキルの中身はすべてこのリポジトリに入り、別のプロジェクトを作るときはまた別のリポジトリを作ります。原則は「1プロジェクト1リポジトリ」です。

GitHubをざっくり言うと「コード版のGoogle Drive」です。Google Driveに資料を上げれば家でも会社でも開けるように、コード・設定ファイル・ドキュメントを上げておく場所がGitHubです。完全に同じではありませんが、最初の理解としてはこれで十分です。現在はMicrosoftが運営しており、個人で使う範囲なら無料です。

「自分1人で使うツールならGitHubは不要では?」という疑問には、講師は「それでも使ったほうがいい」と答えています。理由は2つです。

• 保険になる — パソコンが壊れると手元のデータは消えますが、GitHubにあれば残ります
• 別の端末から見られる — 家のPCで作ったものを出先のノートPCやスマートフォンからも開けますし、リポジトリを指定してAIに仕事をしてもらうこともできます

GitHubが一番真価を発揮するのはチーム開発で、個人の恩恵は限定的ですが、使わない理由はありません。

作成手順は、GitHubにログインして右上のプラスボタンからNew repositoryを選び、フォームを埋めていきます。

READMEはそのリポジトリの説明書です。GitHubでリポジトリのページを開くと、ファイル一覧の下に大きな文章エリアが表示されますが、これはREADME.mdというマークダウンファイルの内容が表示される仕組みです。リポジトリを見た人が最初の数秒で目にするのがREADMEなので、「このリポジトリは何か」をここに書きます。自分専用ツールでもREADMEを作るべき理由は3つあります。半年後の自分が思い出しやすいこと、他人に見せる機会があったときリポジトリを見せるだけで伝わること、AIの参考情報になることです。READMEはあくまで人間のためのマークダウンで、AI向けの専用指示書は別に置きますが、AIはリポジトリ内の必要なファイルを勝手に読むため、READMEがあるとAIの理解も助けます。

.gitignore ─ Gitに追跡させないものを決める

リポジトリ作成時には省略しましたが、.gitignoreの理解抜きに開発は不可能だと講師は強調しています。.gitignoreは1つのファイルで、ここに書いたものをGitが認識しなくなります。アプリケーション開発で.gitignoreすべきものは大きく3つです。

1. パスワードやAPIキーが入ったファイル — 代表は.envという名前のファイルです。慣習的に、パスワードやAPIキーは.envに書きます。APIキーは家の鍵やクレジットカード情報のようなもので、オープンなリポジトリにコミットして上げてしまうと悪用されます。人が多い場所にクレジットカードを置くようなものです。
2. 自動で大量に作られる巨大なフォルダ — 代表はnode_modulesです。フレームワーク(誰かが書いた便利な道具が揃ったもの)は膨大なファイルで構成されることが多く、コマンドで自動生成されます。これをGitにコミットしてはいけません。.gitignoreはファイル単体だけでなくフォルダ単位でも指定でき、一番上のフォルダを指定すればGitの差分から消えます。
3. OSが勝手に置くゴミファイル — Macの.DS_Store、WindowsのThumbs.dbなど。ファイルの状態をOSが覚えるためのもので、コミットする必要はありません。

似た仕組みに.cursorignoreもあります。ここに書くと、Cursor上でAIがそのファイルを「存在しないもの」として扱います。.gitignoreでAPIキーをGitから守っても、AIが勝手にAPIキーを読んでパブリックな場所にアップしてしまったら危険です。それを防ぐのがCursor側の無視の仕組みです。このignore周りは開発者もよくつまずくポイントなので、存在を理解しておくことが大切です。READMEも.gitignoreも、あとからでも作れます。

Create repositoryを押すと、GitHubのサーバー上に自分だけがアクセスできるプライベートリポジトリが完成します。作成後に表示されるセットアップ画面は「このリポジトリをあなたのパソコンに持ってきてください。アドレスはこれです」という案内で、HTTPSとSSHの2形式があります。基本はHTTPSと覚えておけば間違いありません。

ステップ3|クローン ─ 完全な作業場を手元に立ち上げる

次はGit cloneで、GitHubにあるリポジトリを手元に持ってきます。クローンは「ファイルのコピーをダウンロードする」のとは違います。ただのダウンロードならファイルが来るだけですが、Git cloneは4つのものがセットで来ます。

1. 今のファイルの完全コピー
2. 過去の全履歴 — リポジトリが生まれてから誰がいつ何をしたかの情報。だから1年分のコミットがあるリポジトリなら、1年前・半年前・3ヶ月前の状態に手元で戻れます
3. 送り先の住所 — ブラウザで保存した画像はどのサイト由来かわからなくなりますが、クローンにはGitHubのどの倉庫から来たかのメモが入っています。だから編集後にコミットして送り返すとき、いちいち場所を指定しなくても送り先がわかります
4. 今の作業位置 — Gitにはブランチという履歴を分岐させる機能があり(チーム開発向けで今回は深入りしません)、自分が今どの位置にいるかの情報も含まれます

つまりクローンの正体は「完全な作業場が1つ立ち上がること」です。

先ほど「GitHubはコード版Google Drive」と言いましたが、思想は違います。Google DriveやDropbox、社内共有ファイルは同期前提です。ファイルは常に1つで、誰かが触った瞬間に全員に反映されます。Gitは違います。クローンすると自分の作業場が立ち、手元の変更が勝手に同期されることはありません。自分の作業場で好きに進めて、区切りで「これを送るよ」「これを受け取るよ」とやり取りする、非同期前提の設計です。同期型では、誰かが間違えて全部消したら全員の手元からも消えてしまい、複数人での開発は成り立ちません。Gitならそれぞれが作業場を持ち、必要なタイミングで変更を融合させます。同じファイルの同じ場所を変更していた場合はコンフリクト(衝突)という形で「AさんとBさんが同じ場所を編集していたようです。どうしますか」と警告してくれます。

クローンと似た概念にフォークがあります。頻繁に使うものではありませんが、素敵な概念です。例えばAさんがオープンソースで公開している便利なツールがあり、「この土台は素晴らしいが、自分はもっと違う思想で作りたい」と思ったとします。クローンするとそれはAさんのリポジトリのままですが、フォークすると履歴を全部引き継いだ別のリポジトリになります。Aさんに「こうしたほうがいい」と言い続けて聞いてもらえない不満を抱える必要はなく、これまでの歴史を取り込みながら違う歴史を始められる。要するに、他人のリポジトリを自分用に複製する仕組みです。

実際のクローンはCursorのClone repoから行います。URLを直接打ち込むか、GitHubでログインしていればClone with GitHubで自分のリポジトリ一覧から選ぶだけです。次に置き場所を聞かれます。ここで講師のおすすめは、ホームディレクトリ(パソコンを使い始めると自動で作られる自分の名前のフォルダ)の直下にsrc(ソースコードの意味)というフォルダを1つ作り、リポジトリをすべてその中に並べることです。初心者はデスクトップ、ダウンロード、書類フォルダなどいろいろな場所にリポジトリを散らばらせてしまい、どこにあるかわからなくなりがちです。srcではなくdevやrepositoriesと名付ける流派もありますが、1箇所に集約することが大切です。

隠しファイルと.gitの正体

開発の世界に足を踏み入れたら知っておくべき概念が、隠しファイル・隠しフォルダです。名前がドット(.)から始まるものはすべて隠しファイルで、FinderやExplorerでは通常表示されません。触る必要のない人には見せない設計だからです。しかし開発をするなら見えたほうがよいので、Cursorに「隠しファイルを常に表示するように設定したい」と依頼して設定しておくとよいでしょう。

代表的な隠しフォルダが.gitです。Git cloneをすると必ずこの.gitが入っています。Gitというツールが、ただのフォルダとファイル群にすぎないものを「これはGitのリポジトリだ」と判断できるのは、すべての情報が.gitに入っているからです。誰がどんな作業をしてきたかの全履歴、どの倉庫から来たかの住所、自分が今どのセーブポイントにいるかの情報、コミット時に書くコミットメッセージ(何を変更したかのメモ)も、すべて.gitの中のファイルに保存されています。Gitの正体とは.gitフォルダなのです。

「Gitはなんかいい感じに動いてくれる」という抽象度の高い理解ではなく、「.gitが正体で、これがあるから動く」という原理を理解することが大切です。さらに興味があれば「過去の履歴を全部保存したら膨大な量になるはずなのに、どういう仕組みなのか」をAIに聞いて深掘ると、長年使われるGitの本質にたどり着けます。

CursorのサイドバーにはソースコントロールパネルというGit操作の画面があり、過去の履歴や変更の差分が見られます。これが見ているのも.gitの中身です。ちなみにこのパネルはCursorが作ったものではありません。CursorはVS Codeというオープンソースの無料エディターの上に作られており、ソースコントロールパネルはVS Code由来の機能です。Gitの操作はAIにお願いするか、このパネルで十分です。

ステップ4|AIルール ─ 毎回伝えることを先に伝えておく

ここで2つ目のワークが行われました。

このワークの意図は、実装を進める中で「AIにはこういう傾向がある」「自分は毎回これをお願いしている」という気づきを言語化することです。開発を始める前に、繰り返し伝えることになる内容をあらかじめAIに伝わっている状態にしたほうが効率的です。それを実現するのがAIルールで、Cursorで開発する前提ならざっくり3つのやり方があります。

• Cursor Rules — リポジトリ内に適用するルールは.cursorという隠しフォルダの下のrulesフォルダに置くと自動で読み込まれます。ユーザールール(全リポジトリ・全パソコン共通)はCursorのサーバー上に保持され、Cursor SettingsのRulesから設定します。ルールは複数設定でき、ルールごとに「常に読み込む」か「必要に応じて読み込む」かを選べます。ただし適用されるのはCursorを使うときだけで、Claude Codeでは読まれません
• AGENTS.md — OpenAIのCodexやGoogleのAntigravityが採用する業界共通の規格です
• CLAUDE.md — AnthropicのClaude Code用。リポジトリの直下にCLAUDE.mdという名前のマークダウンファイルを置くと読み込まれます。全リポジトリに適用したい場合はホームフォルダ直下の.claudeという隠しフォルダの中に置きます

どれも「このことは常にわかっておいてください」というルールをAIに設定するもので、例えば「日本語で返して」「技術がわからない人でもわかるように説明して」などを書きます。ルールには、すべてのリポジトリに効くユーザールールと、そのプロジェクトだけのプロジェクトルールという階層があります。

3つもあってややこしいので、講師のおすすめは「どれか1つに決めること」です。講師はCursorも使うものの、開発のメインは今はClaude Codeなので、CLAUDE.md一択にしてプロジェクトのルールを集約しています。Cursorは設定で「サードパーティーのルールを読み込む」をオンにするとCLAUDE.mdも読めるようになります(ルールだけでなくClaude用のスキルなどの設定も読み込まれます)。読み込まれているかは、Cursorの設定画面のルール欄にCLAUDE.mdの内容が表示されているかで確認できます。どのツールが将来勝つかは誰にも予想できませんが、ルールに書く内容の本質は変わりません。その本質を理解しておけば「どれが一番いいのか」に悩む必要はなく、その時々で判断すればよいのです。

実演では、プロジェクトのCLAUDE.mdに「めちゃくちゃハイテンションで絵文字を多用して話して」というルールを設定し、新しいチャットで同じ質問を投げると、出力の様子が明確に変わることが示されました。ルールは新しいチャットを始めたときに読み込まれます。読み込まれない場合は再起動してみてください。

運用のコツは、最初からたくさん書かないことです。「AIに毎回言うのが面倒だな」と思ったときに、作業しながら少しずつ増やします。毎回必ず伝えたいことはユーザールールに、プロジェクト固有のことはプロジェクトルールに書き分けます。

ただし重要な限界があります。AIルールは万能ではありません。あれもこれもと書き足していくと、AIはアテンション(注意力)の限界にぶつかり、ルールを守れなくなっていきます。AIから見ると、ルールは優先度の低い指示で、一番優先度が高いのはチャットで入力した内容です。ここで思い出したいのが、以前の講義で読んだAnthropic社の記事の教えです。すべてのAI活用の話は「そのトークンはコンテキストウィンドウ(AIが一度に扱える情報量)を消費するに値するのか」に収束します。ルールを足すごとにAIは1つ賢くなる一方で、それ以外の部分で賢くなくなっていくのです。だからCursor RulesもCLAUDE.mdも極力簡潔に書くことが推奨されています。

ステップ5・6|grill-meで詰めて、模範解答を作る

次は、開発するものをgrill-me(壁打ちスキル)で深掘ります。grill-meはチャットで呼び出すと1問ずつ容赦なく質問してきて、分岐を全部解決するまで進まないスキルです。どんな図解を何のために作るのかを、実装前にここで詰めます。

Cursorでgrill-meを使うには、ユーザースキルとして設定しておく必要があります。プロジェクト内に置いたスキルはそのプロジェクト固有のもので、プロジェクトAに入っているスキルはプロジェクトBでは使えません。共通で使いたいものはユーザースキルとして定義します。ユーザースキルはパソコンのユーザー名のフォルダの下に保存され、さらにCursorがクラウド上にも保存してくれるため、別のパソコンでもすぐ使えます。「グリルして」「壁打ちして」と言って使うこともできますが、確実に呼び出すにはスラッシュ(/)からスキル名を入力すると候補が出るので選択します。

やりたいことが詰まったら、次はスキルが自動で出してくれるはずの「図解の理想形」を先に自分で作ります。これはAI-Driven Rules その8「抽象指示より模範回答を作れ」の実践です。AIを使っても構わないので、「こういう図解のWebページを作ってほしい」という模範回答を最初に作ることが、AIによい出力をしてもらう最短距離です。

実務上のポイントは2つあります。1つ目は、ブラウザで見た目を作るときは「Tailwind CSSを使って」と伝えておく(またはAIルールに書いておく)のがおすすめだということです。2つ目は、納得のいく1枚ができたらリポジトリ内に保存されていることを確認し、ファイルを作成・編集・削除したらこまめにコミットすることです。セーブポイントは細かいほうがよく、プロのエンジニアは皆そうしています。

なおTailwind CSSはフレームワークで、使い方は2通りあります。1行「Tailwind CSSを読み込んで」という無料のリンクを埋め込む方法と、Tailwind本体をリポジトリ内に入れてコミットする方法です。個人開発では読み込み形式の1行で構いません。

ステップ7|スキル化 ─ SSoTと「洗練」を保つ

模範解答ができたら、同じような図解を出してくれるスキルを作ります。模範解答を渡して「このような図解を作成するスキルを作って」と言うだけでもできますが、もう1段階こだわってほしいのが「洗練されたスキルにすること」です。AIに雑に作らせると、ごてごてとたくさん書いたスキルになりがちです。

ここで思い出すべきなのがSSoT(Single Source of Truth、信頼できる情報源は1つにするという原則)です。SKILL.md(スキルの本体ファイル)は500行以下が推奨されているため、模範解答のHTMLやCSSを全部書き込むことはせず、「模範解答はこれです」と参照する形にするはずです。しかし油断すると、模範解答を見ればわかることがSKILL.mdの中にも書かれてしまいます。SKILL.mdだけ読めばわかるという利点もあるので常に悪ではありませんが、SSoT違反です。放置すると、模範解答が変わるたびにSKILL.mdも修正しなければならなくなり、メンテナンスがどんどん大変になります。だからSKILL.mdの中身は極力洗練させるべきです。「簡潔」も間違いではありませんが、短ければいいのではなく、本当に必要な情報に絞り込むという意味で「洗練」がぴったりだと講師は言います。

ルールとスキルはいつ作り、どう育てるか

そして大事な心構えがあります。ルールもスキルも、自宅で犬や猫を飼い始めるようなものです。ペットは飼い始めたら最後まで責任を持って育てます。ルールやスキルも放置はありえず、常に面倒を見なければなりません。ペットと違うのは、削除もありえるという点だけです。

講師は自身の事故の経験を紹介しています。いつも通り作業を終え、AIに仕上げを頼んでお手洗いから戻ったら、コードが全部消えていて復旧に時間がかかったというものです。原因は、会社の別のメンバーが半年前に作ったスキルでした。悪意はなく、当時はそのやり方が正しかったのですが、講師はそのスキルの存在を知らず、想定外に動いて予想しない結果を招いたのです。すべてのスキルの文章を覚えるのは無理でも、少なくとも自分が作ったスキルについては「本当に必要か」「ベストな形か」を考えて面倒を見続けなければ、恩恵は受けられません。むしろルールやスキルがお荷物になっていくことすらあります。

洗練をいちいち考えるのが面倒な人のために、この講座では第1章でcreating-skillsという「スキルを作るためのスキル」が配布されています。講義では扱われておらず、ポータルに記載された課題の解説の中で紹介されたスキルです。汎用的に使え、ユーザースキルに設定していれば「このスキルを作って」と言うだけで使われるはずです(スラッシュから呼び出せば確実です)。ただしcreating-skillsもこの先ずっと万能ではありません。スキルのベストプラクティスは変わっていくので、定期的に公式ドキュメントを読ませて更新する必要があります。公式(文脈上はAnthropicを指すと考えられます)が出しているスキル作成用スキルもあり、非常に洗練されていて無駄がなく、それでも十分です。ただ英語で認知しにくいこと、SSoTの厳守の面ではやや弱いと講師は感じています。creating-skillsは公式よりしっかりチェックする分、トークンも消費します。どちらがいいかは好みの問題で、両方使って自分がどう感じるかを大事にしてください。すべての場面で万能なスキルは存在しないのです。

スキルの構造と発火の仕組み

スキルはAI業界共通の規格で、フォーマットはClaude CodeもCursorもCodexも同じです。大文字のSKILL.mdという名前に意味があります。ただし置く場所はツールによって違い、Cursorは.cursorフォルダ下のskills、Claude Codeは.claude下のskillsしか読みません。講師はすべて.claudeの下に集約しています。Cursorのサードパーティー設定をオンにすれば、Claude CodeでもCursorでも読めるからです。Cursorにスキル作成を頼むと.cursorの下に作ることが多い点には注意が必要です。

スキルの冒頭にはname(スキル名)とdescription(何をするスキルかの説明)があります。名前は公式が動名詞を推奨していますが、あくまでガイドで、動名詞でないと動かないわけではありません。大事なのはdescriptionです。AIは起動した時点ではスキルのdescriptionまでしか読みません。ユーザーとのやり取りの中で「図解を作って」と言われたら「このスキルを使うべきだ」と判断し、そこで初めてSKILL.mdの中身を読んで動き出します。つまりdescriptionは、AIがこのスキルを使うべきかを判断する唯一の材料です。書き方には公式の推奨があり、文字数制限もあります。スキルを作ったら必ず自分の目で読んで確認することが重要です。

スキルにしたのに動いてくれないときは、descriptionに書く発火条件の調整余地があります。スキルが使われたかどうかは、実行後に「スキルを読み込んでいる」と表示されるかでわかります。どうしてもダメならAIルールに「こういうときはこのスキルを使って」と書く手もありますが、これを全スキルでやり出すとコンテキストウィンドウを無駄に消費します。ルールもスキルも洗練された状態を保つのが原則です。

出力の検証とコミットの実践

作られたスキルは、模範回答と違う題材でも理想的な図解を出せるかをチェックします。実演では「健康的な朝のルーティンを図解して」と投稿し、処理プロセスにスキルの読み込みが表示されること(スキルが動いている証拠)、模範解答が読み込まれていることを確認したうえで、図解が無事生成されました。

コミットについての実践的なアドバイスが2つあります。

1つ目は、AIが明らかに間違ったことをしていなければ、出力の直後に一度コミットすることです。ありがちな失敗は、出力を確認しているうちに「もっとこうしたい」が次々湧いてチャットを重ね、いつまでもコミットのタイミングを失い続けることです。間違いが含まれていても「AIが出力してくれた」というコミットを打ち、そこから修正すれば、何を直したかがGitの差分で見えます。細かくコミットするのが結局最速です。常に正解のコミットをしなければいけない、というのは間違いです。いろいろ編集したあと「最初のがよかった」と思ったとき、コミットがなければCmd+Z(Ctrl+Z)でひたすら戻るしかなく、途中で編集してしまうともう戻れません。保証がないのです。Gitにコミットしていれば、AIに「あのときの状態に戻して」と言うだけで済みます。正確には過去に戻るのではなく「過去の状態に戻るようなコミットをする」と考えます。コミット履歴をあとから編集すると複雑になるので、Git操作はAIと認識を確認しながら進めるのがおすすめです。

2つ目は、検証のために出した図解をすべてコミットしないことです。下手にリポジトリに残すとAIが読み込んでノイズになる可能性があります。例えばoutputというフォルダに図解のHTMLやCSSを出させるようにし、.gitignoreにoutputと書いておけば、Gitの差分には出てきません。これを知らないと、大量のテスト出力が差分に現れ、誤コミットや毎回の手作業が発生します。スキルやプログラムのアウトプット結果を.gitignoreするのは、本当によくやる定石です。

ステップ8|Surgeへの公開をスキルに組み込む

ここまでの時点では、スキルはローカルに図解のファイルを作るだけです。次は、図解を作ったらSurgeに自分のアカウントでログインし、Webページをアップロードして、URLを出すところまで自動でやってくれるように組み込みます。Surgeが動くことはPoCで確認済みなので、やることはスキルのアップデートです。

「作った図解をSurgeに上げるまでやって」とAIに指示すれば基本できます。ただし、この「基本できる」がポイントです。スキルに「Surgeにアップしてください」と書くだけでもほとんどの場合は動きますが、失敗して止まることもあります。これがAIです。プログラムなら確実に同じ動きをしますが、AIは同じような処理を毎回してくれるとは限りません。

ここで以前の講義の教え「AIの出力のブレをプログラムでコントロールする」が活きてきます。図解を作るプロセスはとてもクリエイティブで、プログラムには到底できません。しかし、一度作られたローカルのHTMLファイルをSurgeにアップロードする処理はどうでしょうか。クリエイティブではなく、AIにしかできない仕事でもありません。何度やっても十分な精度で成功するならそのままでもいいですが、5回に1回失敗するようなら使いにくいスキルです。そういうときは、AIの出力のブレをプログラムに吸収させます。

補足すると、AIに「サブエージェントを10個起動して成功率を確かめて」と頼めばやってくれますが、トークンを消費するのでAIが勝手にやることはありません。またプログラムを実際に動かすのではなく、プログラムの例をスキルに書いておくやり方もあります。大事なのは、問題があったときに「プログラムにする」という選択肢を持っていることです。スキルもルールも、最初から完璧を目指すとややこしくなります。とにかく小さく試すことです。

AIとやり取りしながら、Surgeへのアップロードまで自動でやってくれるスキルが完成しました。ローカルでindex.htmlを開いたときはアドレスバーがfileから始まりますが(自分のパソコンのファイルを直接開いている状態)、Surge版はhttpsから始まり、リンクを知っていれば誰でもアクセスできます。毎回手作業でSurgeにアップする手間が消えました。

なおSurgeはあくまでシンプルなWebページ専用です。YouTubeやXのように、動きがあって見るたびに中身が変わるアプリケーションは想定されていません。それは後半のNext.jsとVercelの領域です。Surgeに上げられるようになったら、コミットしておきます。

ステップ9・10|サブエージェントレビューとプッシュ

次はレビューです。できあがったスキルを、サブエージェント(メインのAIとは別に動く子AI)に厳しくレビューしてもらいます。今回はやることがシンプルなので最後に置きましたが、本来は、何か機能を作るならまずプランを立て、そのプランに対してサブエージェントレビューをかけるのが一番生産性が高いやり方です。講師は最後の確認としてのサブエージェントチェックも毎回行っています。

別のチャットを立ち上げてレビューさせる方法もありますが、サブエージェントにレビューさせ、その結果を「これまでの流れを理解しているメインのAI」が受け取って修正するほうが効率的です。ただし、やり取りが長く続いている場合は、新しいチャット(セッション)を立ち上げるほうがよいでしょう。目安として講師は、Claudeの100万トークンのコンテキストウィンドウを持つモデルなら、20〜25%まで使ったら次のセッションに進むようにしています(絶対的な基準ではありません)。コンテキストがいっぱいになったセッションで「次やることをまとめてコピーして」と伝えておくと、新しいセッションに貼り付けるだけで続きができるのでおすすめです。

最後の工程がプッシュです。最新の変更まですべてコミットしている前提で、GitHubに反映します。チーム開発ではブランチを切ってコミットしていくものですが、今回は1人なのでmain(主となる履歴)に直接コミットする簡単なやり方です(ブランチを切っても構いません)。プッシュはAIに「プッシュして」と頼むか、Cursorのソースコントロールのボタンを押すだけです。

プッシュするとGitHubに上がり、他のパソコンで続きの作業ができ、プライベートリポジトリに招待すれば人にも共有できます。講師が毎日のように使っている実践的な使い方は、スマートフォンのブラウザからCursorのWebアプリを使うことです。図解スキルのあるリポジトリをプッシュしておけば、スマホから図解を作ることもできます。興味があれば自分で調べてみてください。

これで模範解答の10ステップをすべて通過しました。すでに一度やったことのあるプロセスでも、1つ1つ解像度を上げて見ていくと、理解できていなかったことや「そうすればいいのか」という気づきがあったはずです。

Webアプリケーションの土台 ─ 復習と全体像

後半はNext.jsを使った本格的なWebアプリケーションの公開です。その前に、土台の仕組みを凝縮して振り返ります。

スマホやパソコンのブラウザにURLを入れる(またはリンクをクリックする)と、ブラウザから世界のどこかにあるサーバーへ「このページをください」というリクエストが飛びます。サーバーは中身を返します。これがレスポンスです。返ってくる中身は大きく3つ、HTML・CSS・JavaScriptの3点セットです。

• HTML — ここにこんな文章、こんな画像、という画面の情報
• CSS — 色や余白、レイアウトという見た目・デザインの情報
• JavaScript — ボタンを押したら何が動くかという動き。複雑な処理を担う

この3つがブラウザの中で組み合わさって、Webアプリケーションは動きます。SurgeはシンプルなWebページを上げるためのサービスですが、私たちが普段使うサービスはもう一段複雑です。例えばXは開くたびに違う投稿が並びます。同じURLでも中身が変わるのは、リクエストとレスポンスの間に「この人は誰で、何を見せればいいか」を出し分けるプロセスがあるからです。このような複雑なアプリケーションにSurgeは向きません。そこでNext.jsです。

プロのエンジニアがCSSやJavaScriptを生の記法でそのまま書くことはほぼありません。料理人が醤油を大豆から発酵させて自作せず、スーパーで買ってくるのと同じで、Web開発の世界には「みんな使うよね」という便利道具が揃っています。それらをフレームワーク・ライブラリ・ツールと呼びます(細かい使い分けは気にしなくて大丈夫です)。主要な道具を整理します。

Reactが登場する前、画面作りには大きく2つの困りごとがありました。1つは画面の一部だけを書き換える処理です。ボタンを押したら下の表示が変わるといった動きを、昔はどこがどう動くかを全部自分で書く必要があり、画面が複雑になるほど書き換え処理も複雑になりました。もう1つは同じパーツの再利用です。商品カードのような見た目を10箇所に出したいとき、昔はコピー&ペーストするしかありませんでした。これらを整理するために提案されたのがReactで、画面を小さな部品に分けて再利用するコンポーネントという考え方を持ちます。フレームワークを使うということは抽象化されるということです。車を改良するのに車そのものをいじる技術がなくても、設計図を型に沿って書き換えれば車が変わっていく、というイメージです。

TypeScriptは「家を建てるとき、太いネジで固めるべき場所にうっかり細いネジを打ったら教えてくれる」仕組みです。JavaScriptだけでは間違いに気づけませんが、TypeScriptなら警告してくれるので、かっちり作れます。これがプログラミングにおける型という概念です。

そして重要なのが、shadcn/uiもTailwindもそのままブラウザで動くわけではないという点です。ブラウザで動くのはあくまでHTML・CSS・JavaScriptだけです。開発時にshadcn/ui(=Tailwind)で作られたものが普通のCSSに変換され、サーバーが変換済みのものを返すからブラウザで表示できるのです。この大原則は繰り返し出てきます。

ゼロからNext.jsアプリを作る

ここからは実際にNext.jsのアプリを1個作り、世界に出すまでを通します。実演では、配布された雛形ではなく、あえてゼロからのスタートです。まずはGitHubでリポジトリを作り(Private、READMEにチェック)、Cursorでホーム直下のsrcにクローンします。ここまでは前半と同じです。

Next.jsはフレームワークなので、どんなWebアプリを作るにしても型(フォルダやファイルの構造)があります。まず型を作り、その型の上で開発します。実際には「Next.jsの雛形を作って」とAIに言えば全部自動でやってくれますし、講師も普段はそうします。しかし今回は裏側で何が起きているかを見るため、ターミナルでコマンドを打ちます。

ターミナルには「今いる場所」という概念があります。ホームフォルダにいるのか、ダウンロードフォルダにいるのか、あるアプリのフォルダにいるのか。コマンドは「どの場所で実行するか」が重要で、移動にはcdというコマンドを使います。わからなければAIにコマンドを出してもらえば大丈夫です。今いる場所はpwdと打てば確認できます。目的のフォルダに移動したら、次のコマンドを打ちます。

pnpm create next-app .

末尾の1個の点(ピリオド)は「今いるフォルダに入れる」という意味です。pnpmとは何か。講師の例えでは「効率よく家を組み立てるキットを取り寄せる材料屋さん(道具屋さん)」です。Next.jsは効率よく家を組み立てられるキットで、そのキット一式をどこからか持ってきてくれるのがpnpmです。正式にはパッケージマネージャーと呼びます。道具屋さんがいるおかげで「Next.jsを使いたい」と言うだけで、ファイル一式がどこにあるかを探さずに済みます。スーパーがなかったら野菜のためにそれぞれの畑の場所を、肉のために牧場の場所を覚えなければならないのと同じです。開発でよく聞くnpmという道具屋もあり、pnpmはざっくりその進化版です。つまりこのコマンドは「pnpmさん、Next.jsのキット一式を取り寄せて、このフォルダに入れてください」というお願いです。

実行するといろいろ聞かれますが、最初のうちはデフォルトやおすすめを選べばOKです。迷ったらAIに聞くとよいでしょう。生成が終わると、READMEしかなかった場所にapp、public、package.jsonなどNext.jsの雛形ができあがります。配布された雛形も同じやり方で生まれたものです。

ここで注目すべきは、Surgeのときにあったindex.htmlのようなファイルがどこにもないことです。Surgeはindex.htmlが必ず必要な仕組みでしたが、Next.jsのアプリにHTMLファイルはなく、開発中にHTMLファイルを開くこともありません。それでも「サーバーはブラウザにHTML・CSS・JavaScriptを返し、ブラウザはその3つで表示する」という大原則は動きません。補足すると、画像や動画のURLがHTMLに入っていれば、それらを取得する機能はありますが、それでもHTML・CSS・JavaScriptが土台であることは変わりません。Next.jsでも最終的にはHTML・CSS・JavaScriptが作られますが、使う私たちが意識することはないのです。私たちとAIが編集するのはtsxというファイルで、HTMLは最終的に.nextという隠しフォルダの中に自動生成されます(いじることはありません)。

雛形の中にはnode_modulesというフォルダもできています。中には何千個ものフォルダが入っており、一切触らず、コミットもせず、.gitignoreします。

Node.jsとフロントエンド・バックエンド

pnpmは何の道具屋なのか。答えはNode.jsの道具屋です。JavaScriptは本来ブラウザで動く言語ですが、とても優れているので「ブラウザじゃないところでも使えるようにしたい」と生まれたのがNode.jsです。先ほどのコマンドを打った瞬間にもJavaScriptが動いていますが、ターミナルでJavaScriptは本来動きません。それを動くようにしたのがNode.jsです。「ブラウザでJavaScriptを動かす以外はすべてNode.js」と考えて問題ありません。node_modulesとはNode.jsの便利道具集のことだったのです。

ここで開発の世界の切り分けを1つ覚えます。HTML・CSS・JavaScriptを作り込む、ブラウザ側の開発をフロントエンドと呼びます。サーバー側の処理はバックエンドです。フロントエンドからリクエストを送り、バックエンドからレスポンスを返す、という関係です。Webの歴史の中でブラウザ側はずっとHTML・CSS・JavaScriptでしたが、バックエンドはJava(JavaScriptとは全くの別物)、PHP、Perl、Rubyなどさまざまな言語で書かれてきました。これらの言語にはそれぞれ良いところがあり、今も現役で広く使われています。つまり開発者はJavaScriptとサーバーサイドの言語の両方を覚える必要があったのです。その中で比較的歴史が浅く人気を伸ばしているのがNode.jsです。Node.jsを使えばバックエンドもJavaScriptで書けます。フロントエンドはJavaScript確定なので、1つの言語でフロントからバックまでまとめられます。特に小規模な開発では両方が1つのリポジトリにセットになっていることが多く、これがNode.js人気の大きな恩恵の1つです。

開発サーバーを立ち上げる

雛形ができたら動かします。Webアプリケーションはサーバーを立ち上げる必要があります。ここでいうサーバーは自分のパソコン上の話で、立ち上げても他の誰かがアクセスできるわけではありません。Next.jsのアプリのフォルダにいることを確認して、次を実行します。

pnpm dev

Readyと表示されたら起動完了です。このターミナルはサーバーが動いている状態になり、他のコマンドは実行できません。表示されたURL(localhost

ここで前半との重要な対比があります。図解のときはindex.htmlをクリックするだけでブラウザで見られ、サーバーは立ち上げませんでした。なぜNext.jsはサーバーが必要なのでしょうか。答えは、HTMLとCSSとJavaScriptだけならそのままブラウザで開いて見られるからです。Next.jsではそのままのHTML・CSS・JavaScriptを操作せず、tsxを編集します。HTMLにあたるtsxファイルをブラウザで開いても「tsxって何ですか?」とエラーになります。「図解でTailwind CSSを使ったけど大丈夫だったの?」と引っかかるかもしれませんが、Tailwind CSSは別の言語ではなく、優秀なWebデザイナーたちが最初から整理してくれているCSS集、つまりあくまでCSSです。だからブラウザはそのまま読めるのです。Next.jsで画面を見たいならpnpm devを打たなければ絶対に動かない、と覚えておけば十分です。

この開発サーバーはとても便利にできています。AIに指示してコードを書いたり更新したり削除するたびに、サーバーが自動で変更を理解して読み直してくれます。基本的にリロードも再起動も不要で、「保存したら勝手に反映される」と覚えてください(タイミングによっては立ち上げ直したほうがいい場合もあります)。ただしこれは開発環境だけの話です。pnpm devはパフォーマンスを犠牲にして開発しやすい状態でサーバーを立ち上げるコマンドで、リリース後のサービスでコードを変えたら自動反映される、ということは起きません。

試しに雛形の文言を変えてみます。編集するのはNext.jsで最も重要なフォルダの1つappの中にあるpage.tsxです。tsxは現時点では「HTMLの役割を果たすTypeScript」と理解しておけば十分です。Cursorでpage.tsxを開くと、ブラウザに表示されている文字が入っています。一部を書き換えて保存すると、サーバーの再起動もブラウザのリロードもなしに画面が置き換わります。

Vercelで世界に公開する

今の時点では自分の手元でしか見られません。ここから公開します。ブラウザでVercelにアクセスし、初めての場合はリポジトリを作ったGitHubアカウントで新規登録するのがおすすめです(わからなくなったらAIに聞いてください)。

公開手順は驚くほど短いものです。

1. Vercelのダッシュボード(自分のプロジェクト一覧が並ぶ画面)で右上のAdd Newを押す
2. リポジトリ一覧から先ほどのNext.jsアプリを選択してインポートする
3. 設定は何もいじらずデプロイボタンを押す
4. 1分ほどVercelが裏で動いて完了

Vercelは、Next.jsのコードをブラウザが読める形に変換し、世界中に配信できる場所に置き、公開URLを発行するところまで自動でやってくれます。発行されるのは末尾が.vercel.appのURLで、localhostとは別物です。インターネットにつながっていればどこからでも開けます。

更新はどうするのでしょうか。AIに指示してトップページのデザインを変えると、ローカルの画面は書き換えた時点で変わっています。しかし公開URLはまだ前のバージョンのままです。更新に必要なのは、Cursorのソースコントロールでコミットしてプッシュする、それだけです。プッシュ先はあくまでGitHubのリポジトリですが、VercelとGitHubが連携しているので、プッシュに気づいたVercelが更新作業を行います。この更新作業をデプロイと呼びます。デプロイが終わってリロードすれば反映されています。昔はこのデプロイ作業だけでも大変でしたが、Next.jsとVercelの仕組みに乗ることで苦労せずに済むのです。

Vercelの位置づけと選択肢

VercelはWebアプリケーションを置いておける場所です。イメージは、鍵を受け取ればそのまま便利な生活ができる家具家電付きのマンションです。一方で、土地だけを提供するサービスもあります。Amazon Web ServicesのEC2、Google CloudのCompute Engine、Microsoft AzureのVMなどで、サーバーの設定からOSのインストールまで全部自分でやる必要があります。その面倒な作業を全部やるならNext.js+Vercelより安くつきますが、個人開発でそこからやる人はほとんどいません。「家はあるけど家具は自分で揃える」ような中間のサービスもあり、Amazon・Google・Microsoftのクラウドは土地だけから家具家電付きまで全部取り揃えています。

その中でなぜNext.js+Vercelが人気なのか。VercelがNext.jsの作り手だからです。よくできたNext.jsに最適化された置き場所だから使いやすい、という構図です。もちろんあらゆるケースで万能ではありませんが、小規模の開発であれば「なぜNext.js+Vercelにしないのか」から考えるべきだと講師は言います。個人の簡単なツールなら、ローカルで動かしてプッシュするだけで十分です。

実際に社内ツールとしてみんなに使ってもらう段階になると、開発したものをいきなりデプロイするのはバグのリスクがあります。みんなが使っているツールが突然動かなくなったら困るからです。そこで開発の世界では3つの環境を準備します。ローカルの開発環境、ステージング環境、本番環境です。ステージングは本番に適用する前のテストをする場所で、そこで触ってみて問題がなければ本番にデプロイします。Vercelはステージングと本番の切り替えも簡単にできるようになっています(この講義の範囲では作らない前提なので、必要になったら調べてみてください)。

費用面では、VercelにはHobbyという無料プランがあります。あくまで個人・非商用が前提で制限もありますが、個人開発には十分すぎる内容です。課金が必要になっても、大ヒットサービスを作るのでなければ、とんでもない請求が来ることはありません。気軽に使ってみてください。

最後に、デプロイのときにVercelの裏で何が動いているのかを3つのポイントで押さえます。

1. pnpm install — デプロイ時にも道具屋さんが動いています。package.jsonは「このアプリケーションで使う便利道具リスト」で、世界中の人が作ってくれた道具のうち何を使うかを書いておくファイルです。新しい道具を足したいときもここに書けば、デプロイ時にpnpmが本番環境で取り寄せてセットアップしてくれます
2. pnpm build — ビルドとは、そのままではブラウザが読めないNext.jsのコードを、HTML・CSS・JavaScriptに仕上げる作業です
3. 世界中への配信 — ビルドでできたHTML・CSS・JavaScriptを世界中の配信網に並べ、爆速でアクセスできるようにしてくれます

ワークスペースの雛形を読み解く

ここからは、受講生に配布された「自分専用ワークスペース」の雛形を見ていきます。これもNext.jsで作られており、クローンしてpnpm devで起動した状態から、フォルダとファイルの構成を抜粋で確認します。すべてを完璧に理解する必要はありません。

ファイル名のドットのあとの形式を拡張子といいます。TypeScriptは.tsですが、画面のファイルは.tsxとなっています。難しく考えず「HTMLの役割を果たすTypeScriptコード」で、画面の部品はすべてtsxで作る、と理解しておけば困りません。

App Router ─ フォルダ構造がURLになる

Next.jsではページをpage.tsxというファイルで置きます。appの直下にpage.tsxを置くと、サービスのトップ(ローカル開発ならlocalhost

componentsとshadcn/ui

ページ数が増えると「このボタン、どのページでも使っている」という状況が生まれます。同じボタンのコードを各tsxにコピー&ペーストするのは非効率なので、共通で使う部品はcomponentsフォルダに置きます。実際のページのpage.tsxを見ると、ボタンのコードがそのまま書かれているのではなく、Buttonという記述でcomponents/uiフォルダから読み込まれています。shadcn/uiから運び込んだ部品が置かれるのがこのcomponents/uiです。

shadcn/uiは極力使ったほうがよいと講師は勧めます。ボタン1つでも、通常時、ホバーしたとき、押したとき、無効なとき、フォーカスしてエンターを押すとき、と考えることはたくさんあり、全部手作業で作るのは大変です。shadcn/uiなら動きも含めて最初からセットされています。button.tsxの中を覗くとbg-blue-500やpx-4といった英数字が並んでいます。これはTailwindのクラス名です。shadcn/uiを使うことは、Tailwindを使うことなのです。

表示までの流れも整理しておきます。ローカルのpnpm devでは、ファイルを編集して保存すれば勝手にHTML・CSS・JavaScriptに変換されます。デプロイ時には、ブラウザが読めないNext.jsの形式から読める形式へ.nextの下にビルドし、それを爆速で返せるようにセットアップされ、VercelのURLにアクセスした人はそのHTML・CSS・JavaScriptを見る、という流れです。

ただし、やってみるとわかりますが、すべてをshadcn/uiだけで理想どおり完璧に作りきることは不可能です。あくまで部品であり、デザイン全体の細かい調整をしてくれるツールではありません。それでも全部自作するよりは、はるかに楽になります。配布された雛形もすべてがshadcn/uiのデフォルトパーツではなく、オリジナルの部分がありますが、そこでも共通化が意識されています。

すべては共通化 ─ 先人の知恵の上に積み上げる

AI-Driven Rules その6「AIが見る情報を整えろ」のパートで、SSoTの原則を学びました。同じものがいろいろな場所に書かれるのを防ごう、という話です。今回扱ったのはAIの使い方ではなくWebアプリケーションのフレームワークですが、共通点があります。Next.jsも、AIに渡すコンテキストの整理も、原則は共通化です。同じものが散らばっている状況をやめる。共通化は自分がAIに渡す文章にも言えますし、世界全体でも進んでいます。Next.jsという道具、それを構成するReact、配布された雛形。すべては「頑張らなくていいことは頑張らないようにしよう」という共通化なのです。

ここまで多くの新しい概念を学び、ついていけるか不安な人もいるはずです。しかし講師は断言します。私たちは楽になる方向に確実に進んでいます。AIの活用法もWebアプリケーション開発も、世界中の人たちが「めんどくさい」と思いながら、もっと楽な方法はないかと試行錯誤してきました。私たちはその賢い先人たちが作った仕組みを使っているのです。もしこれを学ばなければ、先人がぶち当たってきた問題に再びぶち当たり、あとになって「だからNext.jsがあるのか。最初から使えばよかった」と気づくことになります。

先人の知恵の上に「自分はこうしたらいいと思う」というアイデアを重ねるから価値が生まれます。Next.jsを使うことは前提として、そのうえで自分はどんなツールを作るかを形にするのです。行き詰まったときも、同じ問題と向き合った先人が必ずいます。急いで作り上げるよりも、AIと対話して「今の状況で一番いいやり方は何か」を自分の頭で理解して進む。それが間違いなく最高速度です(AI-Driven Rules その9「スピードを出すな 対話しろ」)。

それでも不安なら、手を動かして触ってみることです。慣れてしまえば不安はなくなります。

月次課題と次のテーマ

3ヶ月目の月次課題は、自分専用のワークスペースの見た目を作ることです。Vercelへの公開方法は今回学びましたが、Vercelへのアップはマストではなく任意課題です。ただし実演で見たとおりアップは一瞬なので、ぜひ取り組んでみてください。次の回では月次課題の発表会が行われます(発表方法はポータル掲載)。

4ヶ月目のテーマは「自分のツールに記憶を持たせる」です。ここまでは見た目を作って公開するところまでで、データを保存する話はまだ扱っていません。AI時代にデータをどう保存すればいいのかが次の主題です。余裕のある人は自分で調べて先取りしても構いません。講座はちょうど折り返し地点です。講師は、学習習慣が途切れている人はスケジュールを調整し直してドリルを再開し、チームのメンバーに共有しながら最後まで駆け抜けてほしいと呼びかけています。

まとめ

• 開発の一周は「PoC→リポジトリ作成→クローン→AIルール→grill-meで壁打ち→模範解答→スキル化→公開処理の組み込み→サブエージェントレビュー→プッシュ」という流れで進む。絶対的な正解はなく、順番は状況で変わる
• 使ったことのない技術で「動かなかったらすべて終わり」になるものは、最初にPoCで検証しておく
• リポジトリは1プロジェクト1箱。個人でもGitHubを使う理由は保険と別端末アクセス。最初はPrivate一択で、READMEは基本作る
• .gitignoreすべきは、鍵ファイル(.env)、自動生成の巨大フォルダ(node_modules)、OSのゴミファイルの3種(鍵はプライベートリポジトリでもコミットしない)。Git cloneは「完全コピー+全履歴+送り先の住所+作業位置」のセットで完全な作業場が立ち上がり、Gitの正体は.gitフォルダ(触らない・消さない)
• AIルール(CLAUDE.md等)は毎回伝えることを先に伝える土台だが万能ではない。トークンがコンテキストウィンドウを消費するに値するかを常に問い、洗練を保つ
• スキルはSSoTを守り、descriptionを丁寧に書く(AIがスキルを使うか判断する唯一の材料)。同じ説明や作業を3回繰り返したらルール/スキル化し、ペットのように面倒を見続ける
• クリエイティブな部分はAI、確実に動くべき処理はプログラムに吸収させる。その設計判断は人間にしかできない
• ブラウザで動くのはHTML・CSS・JavaScriptだけ。Next.jsではtsxを編集してビルドで変換され、画面を見るにはpnpm devでローカルサーバーを立ち上げる。pnpmはNode.jsのパッケージマネージャー(道具屋)で、Node.jsによりJavaScript1言語でフロントエンドもバックエンドも書ける
• VercelはNext.jsの作り手が運営する公開サービスで、GitHubにプッシュするだけでデプロイされる。無料のHobbyプランは個人・非商用前提。公開直後は認証がかかっている点に注意
• App Routerではフォルダ構造がそのままURLになる。共通部品はcomponentsに置き、shadcn/ui(=Tailwind)を極力使う。SSoTもNext.jsも本質は共通化であり、先人の知恵の上に自分のアイデアを重ねることで価値が生まれる

新出用語

• PoC(Proof of Concept) — やりたいことが本当にできるかを試し打ちする概念実証の工程。動かなかったら計画全体が崩れる技術から先に検証する
• リポジトリ — 1つのプロジェクト分のコードや文書を入れる保管庫。原則1プロジェクト1リポジトリ
• README — リポジトリの説明書となるマークダウンファイル。GitHubのリポジトリページに自動表示される
• .gitignore — Gitに追跡させないファイル・フォルダを指定する設定ファイル。鍵ファイル、自動生成フォルダ、OSのゴミファイルを書く
• .env — パスワードやAPIキーを書く慣習のファイル。どんなリポジトリでもコミットしてはいけない
• クローン(Git clone) — リポジトリを手元に持ってくる操作。ファイルの完全コピー、全履歴、送り先の住所、作業位置がセットで来る
• フォーク — 他人のリポジトリを、履歴を引き継いだ別のリポジトリとして自分用に複製する仕組み
• コンフリクト — 複数人が同じファイルの同じ場所を変更したときにGitが出す警告
• 隠しファイル/隠しフォルダ — 名前がドットで始まる、通常は非表示のファイルやフォルダ。.gitが代表例
• AIルール — AIに常に守ってほしいことを設定する仕組み。CLAUDE.md、AGENTS.md、Cursor Rulesなど
• SSoT(Single Source of Truth) — 信頼できる情報源を1つにする原則。同じ情報を複数箇所に書かない
• description(スキルの) — スキルが何をするかの説明文。AIがそのスキルを使うべきか判断する唯一の材料
• パッケージマネージャー — 開発の便利道具を取り寄せてくれる道具屋。pnpmはnpmの進化版
• Node.js — 本来ブラウザでしか動かないJavaScriptを、ブラウザの外(サーバーやターミナル)でも動かせるようにした実行環境
• フロントエンド/バックエンド — ブラウザ側の開発がフロントエンド、サーバー側がバックエンド
• localhost — 自分のパソコンを指すアドレス。開発サーバーはlocalhost+ポート番号(例: 3000)で開く
• ポート番号 — 1台のパソコンの中でサーバーを区別する住所のような番号
• ビルド — ブラウザが読めないフレームワークのコードを、HTML・CSS・JavaScriptに仕上げる変換作業
• デプロイ — 作ったアプリケーションを公開環境に反映する更新作業
• ステージング環境 — 本番に適用する前にテストをするための環境。ローカル開発環境・本番環境と合わせて3つの環境を使い分ける
• コンポーネント — 画面を小さな部品に分けて再利用するReactの考え方
• 拡張子 — ファイル名のドット以降の形式。tsxは「HTMLの役割を果たすTypeScript」