自分の思想を画面にする

この講義のテーマは「自分の思想を画面にする」です。第1章で学んだAI-Driven Rules その3「自分の武器を自分で作れ」を、自分専用のワークスペース(日々の仕事を行う作業画面)という形で体現する内容です。

前半では、講師が実際に講義制作で使っている自作ツール「Contents Studio」を例に、既存ツールと自作ツールの違いを掘り下げます。NotionやExcelのような既存ツールが圧勝している領域を直視したうえで、それでも自作にしかたどり着けない「90点から100点」の世界があることが示されます。

後半は実践編です。自作ワークスペースを成功させる3つのコツとして、企画を詰める「grill-me」、画面設計の「4ペイン」、技術選定の「Next.jsとshadcn/ui」が紹介されます。技術用語が多く登場しますが、今日すべてを理解する必要はありません。「迷ったらこれを使えば間違いない」という道筋を知ることがゴールです。

6ヶ月カリキュラムの全体地図

本編に入る前に、スクール全体の学びの地図が整理されました。

• 1ヶ月目: AI-Driven Rules(10個)と図解ツール。Webの技術はあまり扱わず、自分用の図解を作る
• 2ヶ月目: レポートツール。図解ツールの応用として、図解を自動で送る道具を作る
• 3ヶ月目(今回): 自分専用ワークスペースの「見た目」。画面のレイアウトや操作感
• 4ヶ月目: ワークスペースの「裏側」。今月はデータの保存までは行わない
• 5ヶ月目: コンテンツ作成。文章作成と資料作成
• 6ヶ月目: 5ヶ月間の学びの振り返りと卒業制作。最新のAIツールも試しながら臨機応変に対応

当初の予定では「自分専用のワークスペースを作る」は3ヶ月目で完了する計画でした。しかし受講生のフィードバックと、変化の速いAI時代に伝えるべきことを整理した結果、3ヶ月目と4ヶ月目に分けて扱うことが決まりました。全体像を早く見せるより、解像度を上げて丁寧に伝える方がAI-Drivenな人材に早く近づける、という判断です。予定していた内容が削られることはありません。

第2章の内容も軽く復習されました。報告の自動化を4つのパーツ(トリガー・ソース元・処理・届ける先)に分ける考え方と、「認知が変われば意思決定は変わる」という報告自動化の意義。そしてAnthropic社のブログを題材に、仮説検証のためのMVP(実用最小限の製品)と実証検証のためのPOC(概念実証)でアイデアを形にするプロセスです。

「技術がわからない不安」の正体

受講生から届く声の中に「技術がわからなくて、このままついていけるか不安」というものがあります。講師は精神論で済ませず、この不安の正体と、それが解ける仕組みを説明しました。

講師はこれまで万単位の人に教育サービスを提供し、プログラミングだけでなくデザインスクールやビジネススクールも運営してきました。その経験から、学びが最も速い人は例外なく次のタイプだったといいます。自分の作りたいものを自分で作ってみて、わからないことを1つずつ調べて疑問を解決する。これを繰り返した人です。教材を端から端まで読み込んだ人ではありません。最初から「これを作りたい」という明確なゴールがあるか、仮でもいいので「自分はこれを作る」と決めて突き進んだ人が最速で成長していました。

かつて、わからないことは人間が答えるしかありませんでした。質問できる体制を作っても24時間対応はできず、質問が続けば待ち時間が生まれます。教える側の癖や性格の相性も、学びの体験に大きく影響しました。それが今はAIに聞けばすぐ返ってきます。自分のレベルに合わせた説明を、24時間いつでも、作りながらその場で得られます。この革命的な学びのループが、人類史上初めてちゃんと回るようになったのです。人に質問できるサービスを日本最大級まで育てた講師自身が、「人間よりAIの方がわかりやすい」と断言しています。コストやスピードまで考えると、AIの方が圧倒的に効率的だからです。

もう1つ大事な事実があります。「身についた」という感覚の正体は慣れです。どうしても解けなかった問題が、解いているうちに気づけば疑問に思わなくなっていた経験は誰にでもあります。例えばGit(変更履歴を管理する仕組み)をどれだけ丁寧に概念として説明されても、身についた感覚には至りません。ドリルで模擬体験はできても、最後は実際に動かしてみるしかないのです。

不安をなくす最短距離は、概念の勉強を積み増すことではなく、慣れるまで手を動かし続けることです。ただし慣れには反復が必要で、反復は退屈です。漢字練習帳に同じ字を書き続けるのは退屈ですし、与えられたことをその通りにやるだけでも退屈です。旧来型のプログラミング教材では「Instagramのようなサービスを作ってみよう」というお題が出ますが、「自分は仕事でInstagramを作らないのに、何の役に立つんだろう」と疑問を持った瞬間に手が止まります。

この「反復は必要だが退屈」という問題への最良の解決策は1つ、自分の作りたいものを作りながら学ぶことです。旧来の教育では全員に同じお題を出すしかありませんでしたが、AI時代には1つ1つAIに聞きながら、自分が作りたいものに向かって作りながら学べます。

そのうえで、講師から2つのお願いが示されました。1つ目は、スクールの至らない点(講義・運営・サポート)を遠慮なく指摘すること。2つ目は、二人三脚で走る覚悟を持つことです。自分が作りたいものを真剣に考え、わからないことだらけの中で、どう作るかを自分で考えて調べて進んでみる。スクールが示す道筋と、受講生1人1人の前に向かう意志の掛け算で、最良の学びが完成します。

学習時間を確保するコツは「宣言し続けること」です。宣言どおりにできなかったら、その日のうちに次どうするかをまた宣言します。

実例——講義制作ツール「Contents Studio」

今月のテーマを具体的にイメージするため、講師がこの講義を作るために作った武器、「Contents Studio」が披露されました。講義の構成決め・原稿執筆・スライド指定を、すべて1つの画面で行えるツールです。

画面は縦に4つの区画に分かれています。

1. 講義の選択 — 6ヶ月12回の講義のうち、どの回を編集するかを選ぶ
2. 章立て — 選んだ回の章が縦に並ぶ。「第1章が何分」という情報も表示される
3. 原稿 — 選んだ章の原稿を書く
4. スライド — 原稿に合わせて見せるスライドを並べる

この画面でできることとして、5つの機能が紹介されました。

機能1|原稿を書く

原稿は1つの長い文章ではなく、段落の単位で書きます。文章を書いてエンターキーを押すと新しい段落(ブロック)が1つ下に増え、段落の先頭でバックスペースを押すと上の段落と結合します。この段落が重要なのは、講義でスライドが切り替わる瞬間が、段落が切り替わる瞬間だからです。CursorやClaude経由で原稿を作成することもできます。ただし講義そのものはすべてAIで作って読み上げているわけではありません。AIの力を借りつつ、最後は講師がカメラの前で話しながら、自身のこれまでの知見をすべて生かして調整しています。

機能2|時間を測る

章立ての区画の下部には、予定の時間と実際の時間が表示されます。講義作成では時間配分が重要で、予定を大幅に超過・短縮しないよう常に確認できます。さらに、講師が20分以上話し続ける状態になると警告が出ます。話し手が一生懸命になり、聞き手の集中力が途切れる事態を機械的に防ぐ仕組みです。章にはL(レクチャー)・W(ワーク)・B(休憩)の区分があり、以前は毎回ざっくり手計算していたワークの所要時間(説明・個人で考える・発表・フィードバックの合計)も、原稿区画のUIで設定すれば自動計算されます。

機能3|原稿にスライドの「型」を指定する

原稿の段落を指定し、あらかじめ用意された50種類の型からスライドのテンプレートを選べます。見出しと2列が並ぶ形、4分割のグリッド、流れを矢印でつなぐ図、ピラミッド図などです。ここで決めるのはあくまで「型」であり、受講生が実際に見るスライドは、デザイナーがAIも使いながら1枚1枚確認して仕上げ、ツール上にアップロードしたものです。そのため、簡易的な型のスライドとデザイナーが仕上げたスライドの両方を、このツール上で指定できるようになっています。デザイナーが細部まで作り込んだ後の「そもそもこういうスライドにしておけばよかった」という根本的なやり直しは膨大な工数を生みますが、このツールがそれを防いでいます。効率を上げる仕組みもあり、例えば4要素が横に並ぶ型では「1つ目だけ色をつけ、残り3つはグレーで薄く出す」という設定ができます。目指しているのはツール上のスライドと本番用スライドの完全一致ですが、現時点では最後の詰めは人間がやる方が効率的なため、今の分業になっています。

機能4|スライドに画像を入れる

画像を入れる方法は4つあります。AI生成・Web画像検索・画像アップロード・過去に使った画像の再利用です。特徴的なのはAI生成です。GeminiやChatGPTにプロンプトで画像を頼むと絵柄が毎回バラバラになりますが、このツールで生成すると、常にスクールの世界観、いわゆるトンマナ(トーン&マナー。デザインの一貫した雰囲気)に合った画像が複数生成されます。スクールで使う青色を必ず使う、斜め上から見下ろした構図にする、顔を描かない人のシルエットを使う、外国人ではなく日本人が自然に登場する絵にする——こうした条件が生成時に指定されているためです。人間は候補から選ぶだけで済みます。

機能5|バージョンを保存する

入力は打った瞬間に自動保存されるため保存し忘れはありません。しかし最新の状態しか残らないと、「間違って消した」「前の状態に戻したい」に対応できません。そこで手動でバージョンを保存する仕組みがあります。ボタンを押すと前回バージョンからの変更点が表示され、変更内容の要約が自動で入り、保存すればいつでも以前のバージョンに戻せます。

既存ツール vs 自作ツール——90点の先の戦い

Contents Studioは、サーバーにセットアップされて誰でも使えるサービスではなく、講師や社内メンバーのパソコン上で起動して動かすツールです。データはSupabase(クラウドのデータベースサービス)で管理されているため、誰のパソコンで立ち上げても内容は同じです。

自作ツールを作るとき、必ず「Notionのような既存ツールを使う方がよくないか?」という疑問が湧きます。実際、Notion・PowerPoint・Googleスライドなど、Contents Studioと似たことができるツールは存在します。講師はまず、Microsoft Office製品・スプレッドシート・Googleドキュメント・Notionは「めちゃくちゃよくできている」と明言したうえで、既存ツールが圧勝している4つの領域を挙げました。

自作ツールを作ると、まともに動くサービスがいかにすごいかを痛感することになります。では自作はしない方がいいのでしょうか。ここで第1章のAI-Driven Rules その1「90から100点の戦いに備えよ」が再登場します。AIで誰でも90点に届く時代だからこそ、その先の10点で差がつくという話でした。既存ツールを使えば不便のない90点には届きます。しかし使ううちに「もっとこれができたらいいのに」と思えてくるか、あるいは疑問を持つことすら忘れて「こういうものだから」と諦めてしまいます。最後の10点で劇的な差がつくのに、多くの人が使う汎用ツールに乗るだけではそこにたどり着けません。

自作ツールが勝てる領域は一言でまとめられます。自分の思考を画面に落とし込めること、もっと簡単にいえば自由にカスタマイズできることです。

AI時代の前に、自分の仕事に最適化したツールを自作しようとすれば、エンジニアを何人も何十人も雇い、何百万〜何千万円と半年から1年をかけるのが当たり前でした。大きなお金を動かせる経営者や投資家だけに手が届く世界だったのです。今はちょっとしたリテラシーがあれば、AIと一緒に1人で作れます。もちろんAIを使ってもわからないことは多く、甘くはありません。それでも必要な知識・経験・お金はAI以前の10分の1以下、100分の1と言っても大げさではないと講師は述べます。実際、講師の会社ではエンジニア経験のないメンバーが数ヶ月で、実務で使えるツールを完成させています。お金をいただく商用レベルまで作り込む難易度はぐっと上がりますが、それも以前よりはるかにハードルが下がっており、時間とトークンに投資する覚悟があれば個人でも作れます。まずは「自分の仕事で使える自分の道具」を自分で作ることから始めます。チャンスは無限大です。

ただし、何でも自作すべきという話ではありません。Excelとまったく同じものを自作しても勝てるはずがなく、「全部自作するべきだ」は偏った考えです。伝えたいのは、自分の仕事のための理想的な武器として「今ある汎用ツールがベストなのか?」という疑問を持てるようになることです。すべてはそこから始まります。自作する能力はやればやるほど上がります。作ってみて難しかった・微妙だったと思っても、次は半分以下の時間で同じことができます。AIの性能も上がり続ける中で繰り返せば、自分だけのツールを作れる人になります。それは自分用にとどまらず、チーム・部署・事業部・会社、さらに特定業界の特定の人に提供するものを作れる能力です。AIですべての仕事ができるようになることはなく、人間にしかできない価値創造は残ります。だからこそ、人間にしかできないことを最高の効率でこなせる武器を、作れるようになるべきなのです。

前提の復習——アイデアを企画にする4ステップ

これから紹介するコツは、「本当に作るべきか」を見極めた後のフェーズの話です。前提として、第2章で扱ったアイデアを企画に落とす4ステップを確認しておきます。

1. 課題を分解する — 無意識にやっている仕事を、一度意識の上に戻す作業です。定例会議の困りごとを思いつくまま書き出し、9個の具体的な面倒に分解したワークが例です。この「無意識を意識にする」プロセスをアンラーニングと呼びます。
2. 自分が作る意味を見極める — 同じようなツールがなぜ世の中にないのか、理由をちゃんと説明できるかを問います。コストの問題なのか、プロダクトとしてリスクが高いのか。そこが見えて初めて、自分が作る意味が生まれます。
3. MVPを定義する — 合言葉は「コードを書いたら負け」。MVPはコードを書くこととは限りません。人力でもスプレッドシートでも何でもいいから、仮説を検証できる最低限の形にします。
4. POCで検証する — 技術的に怪しいところから段階的に確かめます。リアルタイム議事録ツールの例では、「一定間隔で音声を文字起こしし続けられるか」を最初に確かめに行きました。

作ることが目的になってはいけません。問題を解決するために道具はあります。ここまでやって初めてアイデアが企画になり、「本気で自作するフェーズ」に進めます。ここからが本題で、コツは企画・画面・技術の順に3つ紹介されます。

コツ1|grill-me——「あとでやり直し」を防ぐ

企画が固まり、MVPで「これでいける」となり、技術もPOCで検証されて、本格的にツールを開発するとき。CursorやClaude Codeで初心者がやりがちなのは、やりたいことを長文で伝えて「よし、作って」とお願いすることです。どんなに機能を絞り込んでも、毎日使える自分用のツールに至るまでには、自分が気づいていない・考えていない仕様が大量にあります。AIは優秀なので、空白を全部「いい感じ」に埋めて作ってくれます。いい感じに見えるのですが、完成品を使ってみると「いや、そうじゃないんだよな」が永遠に繰り返されます。AIはゼロから作るのは得意でも、すでにあるものを改良するのは苦手だからです。

そもそもAIとは関係ない大前提の原則として、仕事の抜け漏れや勘違いは、上流で気づくほど圧倒的にコストが下がります。海外旅行の計画で、チェックリストの段階で水着の漏れに気づけば、スーツケースに入れるのは一瞬です。現地に着いてから気づけば、慌てて買いに行く時間もお金もかかります。人間は本能的にどんどん作りたくなるので、ここでどれだけ冷静になれるか、AI-Driven Rules その9「スピードを出すな、対話しろ」をどれだけ体現できるかが問われます。それを強制的にやってくれるのが「grill-me(グリルミー)」というスキルです。

スキルとは何だったか

スキルとは、毎回ゼロからAIに説明する代わりに、「このやり方で動いてね」という手順書を決まったフォーマットでSKILL.mdという1枚のファイルに書き、決まったフォルダに置いておく仕組みです。AI業界の規格であり、CursorでもClaude Codeでも同じ仕組みで動きます。人間が明示的に呼び出して使うこともできますが、それだけではありません。

grill-meの中身と使い方

grill-meはスキルの1つで、本体は短い文章だけの難しくない仕組みです。ファイルを置いておけば、CursorやClaude Code上ですぐ使えます。「グリルして」と頼んでも動きますし、スラッシュから/grill-meを明示的に呼び出しても動きます(講師はスラッシュで呼び出すことが多いそうです)。実行すると、企画の甘いところを一問一答で壁打ちしてくれます。「私のおすすめはこうだけど、どうする?」と推奨案付きで聞いてくれるのが特徴です。

このスキルはイギリスのエンジニアが作り、そのシンプルさ・使い勝手のよさで話題になりました。オリジナル版は英語で、簡潔な指示が書かれているだけです。洗練されているのでそのまま使っても構いません。講師は好みの問題として、自分用に改造したバージョンを使っています。カスタマイズは主に2点です。(1)開発前に使うことが多いため、難しい技術用語を避けたわかりやすい言葉で質問させる(オリジナルは一問一答でも判断できない専門用語が多かったため)。(2)必ず理由付きでおすすめが返るよう、フォーマットまで強制する。加えて、いろいろな角度から聞いてくれる観点のリストも入れています。講師が気に入っているのは名前で、「まだレア(生焼け)な状態の自分をグリル(焼き上げ)していく」という意味が込められています。

使い方の例です。Contents Studioに新機能を付けたいとき、/grill-meに続けてやりたいことを書きます。すると画面に3〜4個の選択肢が並び、そのうち1つにおすすめマークと理由が付いています。「この機能は誰が使う?」という質問に「自分だけ/社内チーム/広く一般に公開」といった選択肢が出て、1つ選ぶ。自分の考えと合っていれば即座に選び、違えば別を選ぶか、チャットで伝えます。それを踏まえた次の質問がまた飛んできて、2問目・3問目と進むうちに「そこは決めていなかったな」という気づきが出てきます。最初からすべての質問が決まっている問診票やアンケートではなく、何か返すたびにゼロから次の質問を考えて投げてくれるので、違うと思ったら遠慮なく「もっとこうしたい」と伝えられます。

grill-meは開発以外でも、企画書作りや文章作成でも便利に使えます。講師がContents Studioを作ったのはgrill-meが流行する前でしたが、一問一答でAIと壁打ちする有効性を感じ、たまたま同じことをやっていたそうです。今ではあらゆる開発を始める前にgrill-meを実行しています。使ってみると、実行前には曖昧だったポイントがどんどんクリアになっていくのがわかります。

3つ目の「忘れる」は、AIの限界を決める3つの壁のうち、アテンション(注意を向ける力)が限界を迎えるために起きます。コンテキストウィンドウ(AIが一度に扱える情報量の枠)にまだ余裕があっても、長い対話では最新のAIでも忘れることがあります。対話で思考が整理され「よし、これで完璧だ」とコードや文章を書かせたら、あんなに熱く語り合った内容が反映されていない——これが起きるのです。防ぐ方法は2つあります。企画が一定詰まった段階で、一度マークダウンファイルに書き出すこと。そして、grill-meの後にいきなり仕事をさせず、1回プランを作らせることです。CursorやClaude Codeなら、プランモードが有効です。

コツ2|4ペイン——1つの画面に収める

2つ目は画面のコツです。自分専用の、頻繁に使うツールを自分で作るなら「4ペイン」、つまり1つの画面の中に4つの区画を並べる構成が推奨されます。ペインとは、UIデザインの世界で使われる画面の区画のことです。例えばメールアプリの画面を構成する各領域(受信一覧など)が、それぞれ1つのペインです。必ず4つである必要はなく、仕事の型によって3つがちょうどよいときも、5つになるときもあります。絶対的なルールではなく、迷ったときの道しるべとなる基本形として「4ペイン」を頭に入れておくと設計が楽になります。

なお、これはパソコンで作業する前提の話です。スマートフォンで複数ペインの同時表示は不可能ですし、そもそも生産性の高い仕事をする場所として、スマートフォンは携帯性はあっても閲覧性では非効率です。

なぜ3〜4ペインなのか

一言でいえば、人間は「大きな地図」を見ながら「小さな地図」を見られると、迷わず効率よく進めるからです。講師は高校2年の夏休みに、地元の福岡から広島まで自転車で旅をしました。持っていた紙の地図には、俯瞰した広いエリアの地図と、拡大した狭いエリアの地図の両方がありました。広い地図で見ると福岡から広島は簡単そうに見えます。しかし実際に走ると、自分が広島に近づいているのかわからなくなり、気づけば遠ざかっていることさえあります。そこで定期的に止まり、まず狭い地図で現在地に丸をつけ、次に広い地図でどの辺りにいるかに丸をつける。これを繰り返して広島にたどり着きました。当時のガラケーの地図は読み込みや拡大縮小に時間がかかって不便で、紙の地図の方が効率的でした。そして紙の地図では、大きい地図と狭い地図の両方が必要だったのです。

旅でも仕事でも、本質は「ゴールに向かってどう進むか」で同じです。旅は遠回りも楽しめますが、仕事は最短距離で効率よく進めたい。必要な情報は2つです。(1)全体の中で、今正しい方向に向かっているか。(2)次の交差点で右に行くか左に行くかという、より細かく具体的な情報。大きい情報と小さい情報の両方がすぐ手に入ることが重要です。Google Mapアプリでは、ピンチアウトで地図を引いて「目的地に向かっているな」と確認し、ピンチインで寄せて「次の交差点は左ね」と確認する操作を繰り返します。スマートフォンのアプリとしてはそれがベストの体験です。しかしパソコンの作業場所で、大きい情報と小さい情報を何度も切り替えるのは効率が悪くなります。

Contents Studioで、もしエディターのペインしか表示されなかったら、「あれ、今どの章を作っていたんだっけ」と不安になります。「そもそも何の講義だっけ」という情報は一見忘れそうにありませんが、常に見えていること自体が安心感を生みます。Slackも4ペインです。一番左がワークスペース、隣がチャンネル一覧、その隣がチャンネルの内容、スレッドで返信するともう1つペインが開きます。一般的なパソコンでは3〜4ペインが限界で、頻繁に使われるツールはどれも3〜4ペインの構造に収束します。これは偶然ではなく、人間が全体感を見失わずに目の前のことに集中しようとすると、大体3〜4ペインになるのです。常に情報を俯瞰できた方がよいため、講師のおすすめは4ペインです。

この4ペインの話は、AI-Driven Rules その10「1クリックを減らせ」につながっています。

補足として、作業効率を上げる意味で横に広いディスプレイの利用が勧められました。講師の会社では40インチの曲面ディスプレイを使っています。会社指定のディスプレイしか使えない場合は、自宅の作業場所で検討する選択肢があります。

コツ3|鉄板構成——Next.jsとshadcn/ui

最後のコツは技術の話です。結論からいうと、ブラウザで動くWebアプリケーションを作るなら「Next.js」と「shadcn/ui」の2つを使うのが鉄板です。この範囲を正確に説明するには丸1日でも足りず、時間内に完璧に理解できる人はいません。やるべきことはとてもシンプルなので、細かい技術をすべて理解できなくても問題ありません(技術的な内容は次の講義でさらに深掘りされます)。

スクールでは詳しい技術の講義は行いません。例えばGitだけでも全12回の講義が必要になり、学び方としても非効率だからです。自分の作りたいものがあり、そのために必要な技術を学ぶ。ただし全部AIに聞いて進むのはさすがに難しいので、道筋を示す——それがこのコツの位置づけです。使い方をすべて理解する必要はありませんが、これから紹介するReact・TypeScript・App Router・Vercelという名前と役割をまったく知らないままでは、さすがに厳しいというのが講師の立場です。

伝えたいことは非常にシンプルです。Webアプリケーション開発は世界中で行われており、めちゃくちゃ頭のいい人たちが、たくさんの便利なツールを公開しています。その人たちが作ってくれたものをちゃんと使おう、ということです。プロの世界では「本当に必要か」を考えるべきですが、初学者のうちは迷わずNext.jsとshadcn/uiを使うと覚えます。

家づくりで例えると、Next.jsのようなフレームワーク(開発の型)は、「こうやって家を作るとうまくいきやすい」という世界中の知恵が詰まった家の組み立て方です。選ぶだけで自然と効率的な開発ができます。shadcn/uiは、頑張ってゼロから考えなくても、選べば勝手におしゃれになるデザイン集です。ドア・階段・ダイニングテーブル・ソファ・電球まで、プロが用意したものを選ぶだけ。「このソファをもっとグレーにしたい」という調整もできます。独自の世界観を追求するならゼロから考える手もありますが、自分のツールでそれをやる必要はありません。

なお、Next.jsやTailwind CSSが「心の底からあってよかった」と腑に落ちる瞬間は今日ではありません。今日は「とりあえず使っておけば間違いないらしい」と理解する日です。腑に落ちる瞬間は、使い続けた先にあります。

Webアプリケーションが動く仕組み

前提として、Webアプリケーションの全体像をざっくり押さえます。ブラウザにURLを入れるかリンクをクリックすると、ブラウザはその先のサーバー(情報を返す側のコンピュータ)に「このページをください」というリクエスト(要求)を送ります。サーバーが受け取って中身を返す。これがレスポンス(応答)です。手元の端末からリクエストを送り、世界のどこかのサーバーからレスポンスが返り、ブラウザがそれを画面に表示する——これがWebの基本の動きです。

レスポンスで返る中身は、ざっくり3つに分かれます。

• HTML — ここにこんな文章がある、こんな画像を入れる、という画面の情報を決める
• CSS — 色や余白、レイアウトのような見た目を決める
• JavaScript — ボタンを押したら何が動く、入力したらこう反応する、という動きを決める

この3点セットがブラウザの中で組み合わさって、見えている画面ができあがります。

普段使うサービスの多くは、もう一段階複雑です。例えばXは開くたびに違う投稿が並びます。リクエストからレスポンスまでの間に、「リクエストを送った人オリジナルの情報を取ってくる」プロセスがあるからです。リクエストには自分が誰かの情報が含まれており、サーバーの中でプログラムが動き、膨大な情報が入ったデータベース(情報の保管庫)から、その人が興味を持ちそうな投稿を取ってきます。取ってきた中身をHTMLに埋め込み、CSS・JavaScriptと一緒に返す。基本の動きは同じでも、裏側にその人専用の情報を取ってくるプロセスがあるから、見るたびに、そしてユーザーごとに画面が変わるのです。

ここで大原則を1つ。ブラウザ(Safari・Chrome・Edge)で動くのは、どこまでいってもHTML・CSS・JavaScriptだけです。画像も、保存場所へのリンクをHTMLに書くことで表示されます。ところが今のWeb開発の世界で、プロがCSSやJavaScriptをそのまま書くことはほぼありません。実はHTMLもそのまま書くことはほぼないのです。料理で例えるなら、醤油をゼロから大豆を発酵させて作る料理人はほとんどいないのと同じです。スーパーで醤油を買ってくればいい。こだわるなら大豆から作ってもいいですが、そこまでしなくても美味しい料理は作れます。Webの世界には「みんなこれは絶対使うよね」という便利道具がたくさん用意されており、フレームワーク・ライブラリ・ツールといった名前で呼ばれます。これらの言葉の厳密な使い分けは面倒なので、「頭のいい人たちが作った便利道具」と捉えれば十分です。その代表選手が、Next.jsとshadcn/uiです。

Next.jsの中身——4つの土台

Next.jsは名前こそシンプルですが、中身をすべて理解しようとするととても複雑で、プロでも完璧には理解できません。土台となる4つの技術を順に見ます。

1. React — Meta社が出したライブラリ(再利用できるプログラムの部品集)で、Webの画面作りで一番使われている事実上の標準です。React以前は、大きく2つの困りごとがありました。1つは画面の一部だけを書き換える処理です。ボタンをクリックしたら下の表示が変わる、といった動きを昔のやり方で書くと、どの場所をいつどう書き換えるかを全部自分で書く必要があり、画面が複雑になるほど命令が絡まって、自分でも何が起きているかわからなくなります。もう1つは同じパーツの使い回しです。商品カードのような見た目を10箇所に出したいとき、大昔はコピペするしかありませんでした。解決する道具は他にもありましたが、Reactはとても使いやすかったので流行りました。Reactはこの2つをコンポーネント(画面を構成する部品)という発想で解決します。画面を小さな部品に分けて作り、必要な場所に何度も貼り付ける。モーダル(画面に重ねて出る小窓)を1つの部品として1つのファイルにまとめる、という具合に整理整頓するのです。そして部品の元になる情報が更新されると、見た目も自動で変わります。チャットで送信ボタンを押したら投稿が表示される、という更新作業をReactが自動でやってくれます。車で例えるなら、昔は車を改良するのにメカニックが車体を直接触る必要があったのが、Reactでは設計図を書き換えれば自動で車が変わる、というイメージです。深く理解しなくても道具として便利に使えます。エンジンの仕組みを知らなくても車を運転できるのと同じです。

2. TypeScript — Microsoftが作っている言語で、簡単にいうとJavaScriptのもっと強い版です。より正確には「型」という概念を追加しています。型とは、「正しい道具で、正しい手順で作っているか」の点検システムです。家を建てるとき、大事な骨組みは太いネジで固めると設計図にあるのに、うっかり細い折れやすいネジで打ってしまう。家が完成して崩壊してからでは取り返しがつきませんが、ネジを締める瞬間に「そこ、ネジが間違っていますよ」と警告が鳴れば事前に防げます。TypeScriptで書くと、ミスや間違いの少ないWebアプリケーション開発ができます。間違いやすい点として、ブラウザで動くのはあくまでJavaScriptです。TypeScriptはブラウザでは動かないため、開発はTypeScriptで書き、その後JavaScriptに変換する作業が必ず入ります。Next.jsを使うことは、ほぼイコールTypeScriptを使うことです。さらに、型があるとAIがコードを書くときの品質も上がります。データベースからユーザーの名前を取るべき処理で年齢しか取っていない、という間違いを、型を見ればわかるからです。AIも型を見ながら開発するので、出力の精度が上がります。

3. App Router — Next.jsが用意している仕組みの1つで、ブラウザのURLと表示されるページの結びつけを楽にしてくれる道具です。一般的なWebアプリケーションではページを切り替えるとURLが変わります。URLが変わるおかげで、リロードしても同じページに行けますし、人に「ここを見て」とURLを渡せます。昔はこの設定がすごく面倒でしたが、Next.jsなら楽に設定できます。

4. サーバー機能とVercel — Next.jsはオープンソース(コードが公開されていて誰でも無料で使えるソフトウェア)のフレームワークですが、実際にはVercelというサービスとセットで使うのが鉄板です。Next.jsを開発したのはVercel社で、同社はWebアプリケーションをアップロードして公開できるサービスVercelを提供しています。昔は、アプリケーションの開発と、それを動かすサーバーのセットアップは完全に別々のプロジェクトでした。Next.jsで作ってVercelに上げれば、Webアプリケーションとサーバーを別々に構築しなくてよくなります。自作ツールを発展させると間違いなくサーバーが必要になりますが、Next.jsを選んだ時点で、サーバーの複雑なことを考えなくてよくなるのです。Vercelを使えば、自分のコードをGitで管理し、git pushコマンド(変更をアップロードする操作)をするだけで、世界中からアクセスできる状態になります。セキュリティの仕組みも、ページを素早く表示する効率的な配信の仕組みも、全部裏で勝手にやってくれます。公開という工程が一発で終わるのです。プレビュー環境(本公開前の確認用環境)を簡単に作れる機能も大きな利点です。開発の知識がまったくない人でも、AIに聞きながらVercelにWebアプリケーションをアップすることはできます。

車の例えに戻ると、運転するのにエンジンの仕組みを全部理解する必要はありません。しかしオートマ車があるのにマニュアル車しか知らなければ、運転好きでもないのにマニュアル車に乗り続けることになります。Next.jsという概念を知らないことは、それと同じ状態です。

shadcn/uiとTailwind CSSで見た目を整える

Next.jsとVercelは「動くものを作って公開する」道具で、ここまでの話に色や余白、ボタンの見た目の話は一切入っていません。見た目を担うのがshadcn/uiです。

shadcn/uiは、めちゃくちゃ賢い、センスに溢れた人たちが作ったUI(ユーザーインターフェース。画面の操作部品)の部品集です。ボタン・カード・ダイアログなど、Webアプリでよく出てくる完成済みの部品を、コマンド1つで自分のコードに入れられます。部品は全部で50種類以上あり、特に社内で使うようなツールを作る場合、必要な部品は全部揃っています。カレンダーを表示したければ、shadcn/uiのカレンダーを選べば終わりです。

shadcn/uiがなければ、ボタン1つをゼロから作るのも大変です。普段の見た目、マウスを乗せたときの見た目、押している間の見た目、押せない状態の見た目、フォーカスが当たったときの枠線、キーボードのエンターで押せる対応——ボタン1個でもこれだけの考慮事項があります。shadcn/uiは誰でも無料で使えます。初心者はすべてshadcn/uiで作り切ることを前提に考え、どうしても理想を実現できないときはカスタマイズもできます。プロが作った部品をスタートラインにして、自分好みに調整していく作り方です。

shadcn/uiでUIを作るときに、1つやってほしいことがあります。デザインのガイドライン、専門用語でいうデザインシステムを作ることです。家を建てるとき、職人がそれぞれ好きな色で塗っていったら、統一感のないカラフルすぎる家になります。色だけでなく文字の大きさや余白も、すべて統一感がある方が使いやすいツールになります。土台となるデザインシステムを作り、「常に参考にして」と指示します。Cursor RulesやCLAUDE.mdのような設定ファイルに「UIはデザインシステムを参考にすること」と書いておくのもおすすめです。shadcn/uiを使っても、どんな指示をしても完璧なUIができるわけではなく、突然これまで使っていなかった色を使い出すこともあります。色が増えたときは要注意です。色は本当に必要なところだけに、規則性を持って使うのがコツです。完璧なデザインシステムは存在しません。shadcn/uiを使う時点で1つのデザインシステムに乗るような面はありますが、個々人でチューニングしたくなるものなので、自分のデザインシステムを育てていきます。UIデザインについては、スクールのドリルでUIデザインシリーズが公開されており、取り組みが求められています。

shadcn/uiと密接に関わるのがTailwind CSSです。shadcn/uiの部品のコードを開くと英数字がずらりと並んでおり、その指定1つ1つに意味があって部品が完成しています。この指定の仕方がTailwind CSSで、shadcn/uiはTailwindが前提です。Tailwind CSSは、Webページの見た目を作るCSSを、より簡単に扱えるようにした道具です。文字を青にしたければtext-blue-500、背景を赤にしたければbg-red-500(bgはbackgroundの略)、余白を取りたければp-4、角を丸くしたければrounded-lg——このような指定をHTMLの中に並べていくと見た目が決まります。普通のCSSを書くともっと複雑になり大変なので、Tailwind CSSの方が楽で効率的です。

ここでも大原則の確認です。shadcn/uiもTailwind CSSも、それ自体がブラウザで動くわけではありません。ブラウザで動くのはHTML・CSS・JavaScriptだけです。開発者がshadcn/ui(すなわちTailwind)を使い、それをCSSに変換してからレスポンスとして返す、という流れは変わりません。

プロはTailwindとshadcn/uiをよく使います。つまり世の中にコードの学習量が多く、AIの精度が高くなりやすいということです。UIは原則shadcn/uiで作り、カスタマイズしたいときは土台のTailwind CSSで作ります。

AIへの指示——作り始めの2段階

作り始めが重要です。今のAIは何も言わなくてもNext.jsやshadcn/uiを使おうとしますが、100%ではありません。もしそれ以外の構成で作り出してしまったら、あとから書き換えるのは大変です。逆に、最初にNext.js・shadcn/uiで作るよう指示できれば、AIはずっとそれを使い続けます。AIへの伝え方は2段階です。

1段階目は、プロジェクトの常設ルールです。第2章で扱った「最初から全部わかっているAIに育てる」の復習で、Cursor RulesやCLAUDE.mdといった、AIがプロジェクトごとに常に最初に読み込むルールに、絶対にブレてほしくない技術構成を書いておきます。次のような簡潔な記述で十分です。

使う技術: Next.js・TypeScript・Tailwind CSS・shadcn/ui
デプロイ先: Vercel

デプロイとは、完成したアプリを公開環境に配置することです。shadcn/uiの使用をより明示的にするなら、「新しい部品はshadcn/uiから追加すること」と書いておくのもおすすめです。

2段階目は、新しいプロジェクトの最初の1メッセージです。設定ファイルがちゃんと読み込まれていれば、作りたいツールを指示するだけで、ほとんどのケースでNext.js・shadcn/uiを使ってくれます。それでも絶対に間違えたくない場合は、最初のメッセージに「Next.js・TypeScript・Tailwind CSS・shadcn/uiを使って」と一言入れておくと確実です。

なお、プロの中には「Next.jsはちょっとモリモリすぎる(機能過剰だ)」という意見の人もいて、それは間違いではありません。Next.jsだからこその難しさもあります。それでもトータルで考えると、Next.jsを使わない理由を考える方が難しい、というのが講師の結論です。

月次課題と次回に向けて

今月の課題は、ワークで書き出した自分の仕事の3〜4ペインを、そのままNext.jsとshadcn/uiで画面にすることです。完全にゼロから作ってもよいですが、Next.jsとshadcn/uiの部品で組まれた4ペインのオリジナルワークスペースの雛形が用意されており、それを土台に自分の仕事に合わせて作り変える進め方が示されています。課題の詳細・提出方法・雛形のダウンロードと動かし方はすべてポータルに掲載されるため、必ず確認が必要です。

今月のゴールは「表側の見た目」だけです。データをどこかに保存して、次に開いたときも残っている、という仕組みは必須ではありません。1ヶ月で裏側まで理想のものを作ろうとすると時間が足りないためです。ただし保存はできなくても、文章を打ったりボタンを押したりして、実際に使ったときの感覚を体験できるように作ることが推奨されています。また、講義のために学ぶのではなく、自分の武器を作るために学んでいるはずです。初挑戦で完璧なものはできなくても、時間のある人は保存も含めた完成を目指すことで学べることがたくさんあります。データ保存の技術や概念はドリルで扱われており、次の講義のテーマでもありますが、講義を待つ必要はありません。

進め方の心構えも示されました。今回は課題提出という締め切りがあるので、企画を詰めすぎず、一定考えたら割り切って作るものを決め、ためらわず完成を目指します。道具を作ることが目的になるのは本来よくありませんが、考えすぎて手がまったく動かないと、いつまでも技術に慣れず知識の定着も悪くなるからです。AI-Driven Rules その2「理解できないものを作るな」と、その9「スピードを出すな、対話しろ」を思い出しながら進めます。初めて本格的なWebアプリケーション開発に挑戦する人でも、今のAIの力を使えば、理想的ではなくても動くものが必ず作れます。Next.jsとshadcn/uiで作れば、細かいことがわかっていなくても、バグが少なくデザインのよいツールができます。

最後に復習の指針です。今回わからなかったこと・モヤモヤしたことは、24時間以内に潰します。時間が経つと「まあいっか」と消えてしまいますが、そのモヤモヤは貴重な資産です。忘れないうちにリストアップして、あとでAIに聞きます。アーカイブは受講後すぐ確認でき、講義の文字起こしも配布されるため、AIを使った復習ができます。次の講義では、データをどのように保存していくかを扱います。

まとめ

• 自作ツールが既存ツールに勝てる領域は「自分の思考を画面に落とし込める(自由にカスタマイズできる)」ことだけ。セットアップの速さ・機能の広さ・安定性・費用では既存ツールが圧勝する
• 0点から90点は他人の思想の上で届く世界、90点から100点は自分の思想を形にして届く世界。まず「今ある汎用ツールがベストなのか?」と疑問を持つことから始まる
• AI時代の自作に必要な知識・経験・お金は以前の10分の1以下。エンジニア経験のないメンバーでも数ヶ月で実務ツールを完成させられる
• 開発を始める前にgrill-meスキルで一問一答の壁打ちを行い、曖昧な仕様を上流で潰す。抜け漏れは上流で気づくほどコストが下がる
• 長い対話の後はAIが内容を忘れることがある。マークダウンへの書き出しと、プランモードでのプラン作成で防ぐ
• 頻繁に使うツールの画面は3〜4ペインに収束する。大きな情報と小さな情報を同時に見られることが効率の源泉。ただし本当に必要な情報だけに絞る
• Webアプリケーションの技術選定は「Next.js+shadcn/ui、デプロイ先はVercel」が鉄板。初学者は「なぜNext.jsを使わないのか」を考える側に立つ
• Next.jsの土台はReact・TypeScript・App Router・サーバー機能の4つ。ブラウザで動くのはHTML・CSS・JavaScriptだけ、という大原則は変わらない
• 見た目はshadcn/uiで作り切り、カスタマイズは土台のTailwind CSSで行う。デザインシステムを作って育て、色は必要な場所だけに規則性を持って使う
• 学びの不安の正体は「まだ慣れていないこと」。自分の作りたいものを作りながら、わからないことをAIに聞いて手を動かし続けるのが最短距離

新出用語

• ペイン — 画面を構成する区画。UIデザインの用語で、メールアプリの受信一覧のように、1画面内の独立した領域を指す
• フレームワーク — 「こう作るとうまくいきやすい」というノウハウが詰まった開発の型。選ぶだけで効率的な開発ができる
• ライブラリ — 再利用できるプログラムの部品集。画面作りの事実上の標準であるReactが代表例
• コンポーネント — 画面を小さな部品に分けて作り、必要な場所で使い回すReactの中心概念
• 型 — プログラムが正しい種類のデータを正しく扱っているかを点検する仕組み。TypeScriptがJavaScriptに追加した概念
• App Router — Next.jsが提供する、URLと表示ページの結びつけを楽にする仕組み
• リクエスト/レスポンス — ブラウザがサーバーに「ページをください」と頼むのがリクエスト、サーバーが中身を返すのがレスポンス。Webの基本の動き
• データベース — サービスの情報をためておく保管庫。SNSの投稿などはここから取り出され、HTMLに埋め込まれて画面になる
• オープンソース — プログラムのコードが公開されていて、誰でも無料で使えるソフトウェアの形態
• デプロイ — 完成したWebアプリケーションを公開環境に配置し、アクセスできる状態にすること
• デザインシステム — 色・文字サイズ・余白などのデザインルールをまとめたガイドライン。ツール全体の統一感を保つ土台
• トンマナ — トーン&マナーの略。デザインや表現の一貫した雰囲気・世界観
• プレビュー環境 — 本公開の前に動作や見た目を確認するための環境。Vercelでは簡単に作れる