点が線になる ─ ツールをゼロから育てきる

この講義は、新しい概念をたくさん覚える回ではありません。これまで学んできたことを総動員して、1つのツールをゼロから目の前で育てていく回です。題材は、講師が実際に「本気AIドリル」のクイズ作成に使っている管理ツール「Quiz Studio」。ただのチャット依頼から始まり、スキル化、ビューアー開発、JSON化、そしてデータベース移行へ。ツールが成長していくストーリーを疑似体験しながら、データの保存に関わる概念と考え方を高い解像度で見ていきます。

なお、本気AIドリルの問題は1問1問、最終的に人間が確認しており、講師自身も確認しています。AIの一発出しではありません。しかし、AIの力なしにクイズを作成することは不可能と言えるほど、AIに助けてもらっています。その生産性を支えているのがQuiz Studioです。重要なのは「いかに高品質なクイズを、生産性高く作り出すか」。この問いへの答えの出し方は、クイズ以外の仕事にも応用できます。

講義の冒頭では、学習開始から4ヶ月が経ち、モチベーションが下がってくる時期であることを踏まえたアイスブレイクが行われました。ポイントは「だらけてきた自分を認めず、惰性で続けてしまうこと」が一番良くないという指摘です。学びはスクールのためではなく、自分の人生を充実させるために続くものです。

完璧な理解を目指さない ─ この時期の学び方

データの保存を扱う段階は、技術的な話が増え、「小難しい」「ついていけない」と感じる人が一定数出てくる時期です。なかでも4ヶ月目・5ヶ月目は、このカリキュラムの一番の山場とされています。ここで講師は、学び方の前提を整理しています。

まず、数時間の講義でソフトウェアエンジニアレベルの知識と経験を身につけることはできません。このスクールは、Webアプリケーション開発を職業とするエンジニアを目指す場ではなく、「AI時代に自分の武器を自分で作れる人材」を目指す場です。商用のプロダクトをミスなく持続的に効率よく開発する仕事は、AI時代でも人の知識と経験が活きる領域であり、卒業してすぐプロと肩を並べられるわけではありません。

その代わりに得られるのは、「仕事の作業をAIでできるのでは」と思ったとき、ChatGPT・Claude・Geminiをただ使うのではなく、自分専用のツールを作り上げるという、普通の人にはできない選択肢です。お金を取れる商用サービスにはならなくても、自分が使うには十分なレベルのツールを作れる。0から1、1から10を自分でこなし、プロに依頼するときも相手の話がわかる。これがゴールです。

そこに最短で達する方法は、自分が作ると決めたツールを手を動かして開発しきることです。プロの現場でも、エンジニアはすべてを理解して迷いなく作業しているわけではありません。便利なツールや手法はものすごい速さで移り変わり、誰もが悩みながら前に進んでいます。一度勉強した概念を忘れて調べ直すことは、講師自身も毎日繰り返していると言います。

いま扱っている分野は、プロのエンジニアでも完璧に理解しているわけではありません。将来ツールを作ろうと思い立ったとき、「講義でデータベースと言っていたな」とキーワードレベルで思い出せれば十分です。サッカーの入門書を読むだけでサッカーができるようにならないのと同じで、講義を聞くだけで実力は上がりません。学びを深めたければ、どれだけ自分のツールを作り込むかがすべてです。

これまでの学びの全体像

本題に入る前に、これまでの講義内容が振り返られました。今回の内容はすべての学びの集大成なので、要点を整理しておきます。

第1章では、まずAIによる図解作成を扱いました。文章のチャットだけのやり取りは続けるうちに嫌になるものですが、読みやすい図解を作ってもらえば、隙間時間にわからない概念を理解できます。これは卒業後もずっと使える技術です。あわせて紹介されたのがAI-Driven Rulesその1「90点から100点の戦いに備えよ」。AIを使えば90点まではあっという間ですが、残りの10点に労力の9割がかかり、最後の10点は汎用的な道具では届きません。だから自分の武器を自分で作るのです。

同じく第1章で学んだのが、AIの限界を決める3つの壁です。コンテキストウィンドウ(AIが一度に扱える情報量の上限)は机の広さで、一度に置ける量に限りがあります。アテンション(AIの注意力)は、あれもこれもと指示を重ねるほど分散し、性能が下がります。オートリグレッション(1語ずつ順番に言葉をつなげて生成する仕組み)により、AIは後戻りができず、過去の自分の出力と整合性を取ろうとします。AIはインプットが得意でアウトプットが苦手であり、実際アウトプットのトークン(AIが扱う文字の単位)費用は高く設定されています。長文を一気に書かせると後半が崩れるため、少しずつ出力させるのがコツでした。第4章前半で扱ったハーネスエンジニアリング(AIが正しい方向に進み続けるよう環境を整える技術)は、まさにこの3つの壁を超えるためにあります。

第2章では、面倒な報告の自動化を扱いました。報告を自動化すれば毎日目に入る情報が変わり、認知が変われば意思決定が変わり、人生に大きな影響を及ぼします。自動化ツールは料理に例えて4つのパーツで考えます。注文の伝票にあたるトリガー(処理を始めるきっかけ)、冷蔵庫にあたるデータのソース元、キッチンにあたる処理をする場所、そして料理を届ける先です。実際のシステムは複雑ですが、最初の技術理解としてはこの4つで考えると助けになります。また、その場で文字起こしされる議事録ツールを例に、「作る前の考え方」を学びました。このツールは、参加者を登録して開始ボタンを押すと、決定事項や誰がいつまでにやるかがその場でどんどん溜まり、会議が終わった瞬間にはやることリストができているものでした。漠然とした面倒を小さく分解し、わかっているつもりのことを分解し直してアンラーニング(思い込みを解きほぐすこと)する。そして、いきなりコードを書かずに一番小さい形で試す。「コードを書いたら負け」という言葉と、MVP・PoC(実用最小限の試作と検証)の考え方です。

第3章では、Webアプリケーション開発に入りました。講義作成補助ツール「Content Studio」を例に、既存ツールと自作ツールのメリット・デメリットを比較しました。常に自作すべきという立場ではなく、「いまある汎用ツールが自分の仕事の理想の武器なのか」という問いを持つことが大切です。ExcelがあるのにExcelと同じものを作る必要はありませんが、「ここがもっとこうなれば」というチューニングポイントは必ずあり、ある部分でExcelを上回るツールを作ることは可能です。感情的に納得しやすいように、見た目だけの簡単なプロトタイプを作るのは良い方法です。ただしコードをしっかり書き始める前に、「何を解決したいのか」という根本的な問いからスタートすることが求められました。しっかりしたWebアプリケーションには完成がなく、いくらでもこだわれるからこそ、小さく始めます。技術面ではNext.js(Webアプリの骨組みを提供するフレームワーク)・shadcn/ui(デザイン部品集)・Tailwind CSS(デザインを整えるための道具)・React(画面を作るための土台)が登場し、「初心者のうちは迷ったらNext.jsとshadcn/ui」と覚えておけば十分でした。さらにVercel(Webアプリ公開サービス)を使えば、git pushひとつで世界に公開できることも見ました。

第4章前半では、データの保存を扱いました。採用管理ツールの例で言うと、面接記録をAIにMarkdown(#で見出しを作る文章の書き方)で作らせていくと、数が増えるにつれ「評価4」「評価A」「レビュー5」のように書き方が揺れます。人間が読む分には問題なくても、プログラムにとって同じ概念の書式が複数あることはエラーの原因です。そこでJSON(ラベルと中身をセットにして情報を構造化するデータ形式)にすれば、データをきっちり定義できます。AIが「評価A」と書き間違えてもシンプルなプログラムで気づけますし、「評価4以上」のフィルターも簡単です。複数人で使うならデータベース(たくさんの表が入った箱)へ。候補者の表と面接の表があり、1人の候補者に複数の面接記録が紐づくイメージです。進むほどできることは増える一方、考えることも増える。このトレードオフのなかでツールをどう作り上げるか考えること自体が、すでにハーネスエンジニアリングの始まりでした。

AIの育て方 ─ 5つのステップ

本題の理解を深めるため、講義では次のワークが行われました。

このワークの正体は「スキルの育て方」です。スキルとは、AIをベテランにする自分専用の手順書のことでした。AI-Driven Rulesその7「スキルを育て続けろ」で学んだとおり、同じ作業を3回繰り返したらスキルにします。絶対的な正解は1つではありませんが、うまくAIを使える人の段取りには共通の型があります。講義では「毎日来るお客様からの問い合わせメールの返信」を例に、5つのステップが示されました。

1. ゴールを言葉にする — 例:「お客様が読んで、対応してもらえたと安心でき、次に何をすればいいかがわかる状態になる」。私たちはついゴールを省略し、明確になっていると勘違いしたままAIに仕事をさせます。ゴールがなければAIの出力を評価できず、AIもどの方向にトークンを使えばいいかわかりません。
2. まず雑に1回投げる — 生成AIの世界でゼロショット(手本を一切見せずに依頼するやり方)と呼ばれる方法です。「このお客様の問い合わせに返信して」とだけ、具体例も難しい注文もなしで頼みます。雑に頼んで高品質なものが出るなら、それに越したことはありません。私たちはついAIをマイクロマネジメントしがちですが、細かい指示自体が性能を下げている可能性もあります。この1投目は偵察です。何が足りないのかを見るためにやります。
3. 手本を1個、自分の手で作る — AI-Driven Rulesその8「抽象指示よりも模範解答を作れ」。これぞという返信文を1通、自分の手で書きます。最初からたくさん用意する必要はありません。AIを育てるコツは、必要最小限の情報で出力の変化を見ることだからです。模範解答があると、ゼロショットではばらついていた品質がそろってきます。
4. 足りなければ、簡単な修正方法で改善する — 手本を渡しても、たまに外します。ここでの詳細は次のセクションで扱います。
5. 磨き続ける — 「こういう失敗はもうしないで」とAIに伝えるのは悪いことではありません。ただし、ダメ出しを足し算のように積み重ねると、基礎的なことすら守れなくなります。雑に改善せず、何を改善したのかを自分で認知しながら磨き続けます。

打ち手の階段 ─ 軽い手から順に試す

ステップ4で重要なのは、いきなり「大手術」をしないことです。プログラムで機械的にチェックするバリデーション(入力や出力が正しい形式かを検証する仕組み。メールフォームで間違った形式を指摘してくれるのがその例)をいきなり作る、複数のサブエージェントにレビューさせる仕組みをいきなり作る──どれも有効ですが時間がかかり、必要がないのにやるのは時間の無駄です。

講義で示されたのが「打ち手の階段」です。下に行くほど軽く、上に行くほど重い打ち手で、簡単な方法で品質が上がるならそれに越したことはありません。

1段目の「手本を足す」は比較的簡単です。1つの模範解答でいくつか出力させ、良いものを微修正して新たな模範解答に追加するやり方もおすすめです。ただし模範解答は増やすほど品質が上がるわけではなく、感覚的には2〜3個あればAIは十分に理解してくれます。

3段目のサブエージェントとは、別のコンテキストウィンドウを持つ、ここまでのやり取りを知らない別のAIに仕事を依頼することです。オートリグレッションの性質上、AIは自分のやってきたことを正当化しやすいため、サブエージェントに頼むと客観的なフィードバックが得られます。

4段目の「仕組みで守る」には、AIが書いた返信文にプログラムを走らせて文字数を数える、不適切な単語が含まれていないかチェックする、いきなり文章を書かせず情報収集→まとめ→執筆の流れに分ける、などいくらでも方法があります。複雑なので、最初から取り組む必要はありません。

データの保存がテーマの講義でスキルの話をしたのは、スキルを育てるプロセスとAIでWebアプリケーションを育てるプロセスがとても似ているからです。一言でいえば「必要最小限の工数で小さく試していこう」。シンプルなやり方で解決できるならシンプルなほうが良いに決まっています。AIは有能なので、つい複雑なことを一気にやらせたくなり、90点の壁にぶつかって改善できなくなります。AI-Driven Rulesその9「スピードを出すな、対話しろ」の実践です。

ゼロショットで試す ─ Quiz Studioの出発点

ここからQuiz Studioをゼロから育てていきます。まずゴールをはっきりさせます。今回は「技術に詳しくない人でも、問題を解きながらステップアップして新しい概念を学んでいけるクイズを作成する」。実際にやるときは「解き終わったときにどんな気持ちになるか」まで解像度を上げるべきですが、今回は簡単なゴールで進めます。また、本気AIドリルのクイズの品質については人それぞれ意見があるかもしれませんが、ここでは「運営が納得する高品質なクイズを作る」という例題として進めます。

最初に作るのはクイズそのものです。簡単に頼んで高品質なクイズができるなら、スキルもツールもデータベースも不要で、それで終わりでいいはずです。長期的な運用を考えるとCursor上で行うのがおすすめです(そのままMarkdownで保存できるため)。さっと試すだけならClaude・ChatGPT・Geminiのブラウザ版でも構いません。

Cursorのエージェントを立ち上げ、「AIの使い方の基本についてクイズを作って」と、見本も難しい注文も一切なしで頼みます。すると、問題・4つの選択肢・正解・解説と、一通り形のそろったクイズが出力されました。これだけでも重要な学びです。1問であれば十分な品質のクイズが作れると確認できたからです。逆に、複雑な指示を作り込んでもうまくいかない場合、「今のAIの性能ではクイズ作成自体が難しい」可能性もあります。そうであれば、AIにクイズを作らせようとすること自体が間違いです。それに早く気づけるという意味でも、雑な指示で1回出させる価値があります。

ただしチャットに出力されただけではデータとして残りません。次は新しいエージェントで、Markdownで保存するよう指示を添えてクイズを作らせます。MarkdownはAI活用の基礎で、スキルもMarkdownで作ります。

1問ずつでは手間がかかるので、今度は一気に作らせてみます。本気AIドリルは1レッスンに8〜12問のクイズがあり、1コースは平均8レッスンです。1レッスンざっくり10問とすれば1コース80問。新しいチャットで80問作らせました。

AIに大量の文章を出力させたときは、よく見ることが大切です。さらっと眺めるとどれもいい感じに見えますが、80問のなかに気になるものがありました。「ゼロショットとは何か」というクイズの選択肢に「シュートを決めること」「飲み物の一気飲み」「充電がない状態」と、関係がなさすぎるものが並んでいたのです。難しすぎるのもよくないですが、あからさまな間違いが並ぶのも不適切です。解説も「Aが正解です」のあとがさっぱりしすぎて、ゼロショットが何かの説明が不足していました。

1問なら問題なかったのに、大量に作らせると微妙なクイズが混ざる。これは必ず起きます。AIのアテンションが分散するからです。とはいえ1問ずつでは効率が悪すぎます。1回10問か、80問か──これは作り手の判断ですが、まず比較してみることがすすめられました。1レッスン10問で何度も試すと、いいときも悪いときもあり、品質がばらつくことがわかります。

模範解答とスキル化で品質を安定させる

運まかせを止める最初の一手は、模範解答を作ることです。模範にしたいクイズを1問、自分の手で書きます。AIが出したもののなかに優れたものがあれば、それを活用しても構いません。

ここまではただAIに指示するだけでした。ここからは「良いクイズが出るよう繰り返し改善していく」と決めたので、スキル化します。スキル作成には、図解スキルに同梱されていた「creating-skills」(スキルを作るためのスキル)を使うのもよいでしょう。ただし注意があります。AIに「スキル化して」と言うと、頼んでもいないのに、がっつり文章の詰まったスキルが作られます。AIが一生懸命考えた結果ではあるのですが、スキルは最小限の文章で作るべきです。「洗練された最小限のスキルにして」と伝えると簡潔になります。

この簡潔なスキルのなかに、自分で確認して作った模範解答の参照先を書いておきます。以降のクイズ作成はすべてこのスキルで実行します。80問だと時間がかかるため、1レッスン単位で作成するスキルにしました。

ここまでの流れを整理します。ゼロショットで雑に作らせ、AIでクイズが作れることを確認した。大量に作らせると品質が劣化するとわかったので、8〜12問の1レッスン単位にした。品質を安定させるため、簡潔なスキルから模範解答を参照させるようにした。これで出力の品質が安定していきます。

実際のドリルのクイズは、模範解答1つで安定したわけではありません。模範解答の追加、スキルの中身のチューニング、サブエージェントやバリデーションと、何度もAIに作らせては人間の目で確認し、修正を繰り返して品質を高めるスキルにしています。講義では簡素化して伝えられていますが、学んでほしいのは「汎用AIをただ使うのではなく、自分専用のツールへ進化させるときの考え方の流れ」であり、クイズ以外にも応用できます。

ビューアーを作る ─ Webアプリケーション開発への覚悟

スキルでクイズを作り続け、コースやシリーズという概念も導入して整理していくと、大量に生成されたMarkdownを見てこう思うようになります。「見づらい」。Markdownのままでは、ユーザーから見たときにどう見えるかもわかりません。本気AIドリルのQuiz Studioも、最初は「Quiz Viewer」というビューアー(Markdownをブラウザ上で見やすく表示するもの)から始まりました。

ここから一歩進むには覚悟が必要です。ビューアーを作ると決めた瞬間に、それはWebアプリケーション開発になるからです。AIで誰でもプログラミングができる時代でなければ、自分が見やすくするためだけにWebアプリケーションを作ることは絶対にしません。費用対効果が合わないからです。しかしAI時代には、自分が認知しやすく、管理しやすく、品質を上げやすい自分専用のツールを設計できるようになりました。常にゼロから自作するのが正義ではないけれど、選択肢として取れるようになった──これが劇的な変化です。

このワークにも絶対的な模範解答はありませんが、講師の答えは「AIにアスキーアート(文字だけで描いた絵)で見た目のイメージを出してもらう」でした。いきなり開発するのでも、デザインを複数パターン作らせるのでもなく、まずアスキーアートだけ。理由は、それが最もやり直しの工数が低いからです。指示の例は次のとおりです。

今Markdownで作成しているクイズをブラウザで見やすく表示したい。
プロのUI/UXデザイナーとしてベストなUIをアスキーアートで提案して。
時間をかけてもいいので品質を優先してください。

AIがアスキーアートでUI(画面の見た目)のイメージを提示してくれます。イメージがずれていたら修正するか、チャットをRedo(やり直し)して指示を追加します。アスキーアートなら最小限の工数でデザインのイメージをそろえられます。別のやり方として、アプリケーションの解像度を高めるために「grill-me」で深掘ってもらうのもおすすめとされました。

イメージがそろったら開発です。迷わず使うべきはNext.jsとshadcn/ui。最初に使っておかないと、あとから変更するのは骨が折れます。この2つを使えば「いろいろいい感じにしてくれる」ので、技術に触れたばかりの段階では一旦これでOKです。何が便利なのかは、ドリルのNext.jsシリーズや、開発しながらAIに質問して理解を深めていきます。

AIと対話しながら開発を進めれば、Markdownで表示していたクイズをブラウザで表示できるようになります。ただし、UI作りはAIで昔よりはるかに楽になったものの、微調整は必要です。shadcn/uiでプロの模範的なUIを取り入れても、大きさや余白、バランスがおかしくなることはよくあります。配布された採用管理ツールのひな形も一発出しではなく、「ここがずれている」「もっとこうしたい」と何度も対話しながら微修正を繰り返して作られています。

サーバーを起動する ─ 実行場所とpnpm devの正体

Webアプリケーションを動かすには、サーバー(アプリを動かして届ける係のプログラム)を起動しなければなりません。AIに「サーバーを起動して」と頼めば立ち上げてくれますが、講師のおすすめは、ターミナル(文字でパソコンに命令する画面)で手動実行することです。AIに立ち上げてもらうと、どこで立ち上げたのかを見失いやすいからです。ターミナルはCursorに組み込まれているものでも、別のターミナルアプリでも大差ありません。

便利な頼み方として、「サーバーをターミナルで起動したいので、実行コマンドをフルパスで出して」があります。フルパスとは、実行する場所を省略せずすべて書いた指定のことです。ターミナルで何かを実行するときは「どの場所で実行するか」が重要です。デスクトップなのか、ユーザーフォルダの下なのか、作ったアプリケーションの場所なのか。

Next.jsで作ったアプリケーションはpnpm devというコマンドで起動しますが、ターミナルを開いた直後のユーザーディレクトリで実行するとエラーになります。今回の構成では、ユーザーディレクトリの下にsrcというディレクトリがあり、その下にGitで管理するリポジトリたちがあり、そのなかにNext.jsアプリケーションが作られています。実行すべき場所はそこです。移動にはcd(チェンジディレクトリの略)コマンドを使うのが一般的で、長期的には覚えておく価値があります。ただ、毎回移動するのは面倒なので、フルパスで指定すればどこにいても確実に実行できます。

小難しいと感じる人は、「実行する場所が重要」「実行コマンドはAIに聞けば教えてもらえる」の2点がわかれば困りません。エラーが起きても、内容をコピーしてAIに伝えれば次にどうすべきか教えてくれます。AIがない時代は1人ではどうにもならず、いつまでも動かないだけでした。今はAIに聞けば必ず前に進めますし、理解したければ追加で聞けばいいのです。

フルパスのコマンドでサーバーを起動すると、localhost(自分のパソコンのなかにだけ通じる住所)のアドレスが表示されます。アクセスすると、Markdownでしか見られなかったクイズが見やすく表示されました。実際にユーザーが解くときに近いイメージで表示することで、人間がクイズの善し悪しを判断しやすくなります。

pnpm devは何をしているのか

ここで講義では、サーバーの仕組みを考えるワークが行われました。

答え合わせです。まずpnpmとは、アプリ開発に必要な道具をネットから集めてきて管理してくれるツールです。Webアプリケーション開発では、世界中の優秀なエンジニアが作った無料の便利道具をあちこちから取ってきて使います。そのありかを全部覚えるのは不可能なので、「すべてのありかをわかっている道具屋さん」に管理してもらうのです。この道具管理ツールでpnpm devと打つと、開発用サーバーが起動する設定になっています。pnpm自体は暗記不要です。来年には使われていない可能性すらありますが、「道具を管理するツールが必要」という本質はこれからも変わりません。

ではpnpm devは何をしているのか。めちゃくちゃ簡単に言うと、HTML・CSS・JavaScriptを作ってくれています。Next.jsはフレームワーク(小難しい実装を短く楽に書けるようにした骨組み)であり、コードはHTML・CSS・JavaScriptそのもので書かれていません。しかしブラウザはHTML・CSS・JavaScriptしか表示できません。だから変換が必要で、その変換をpnpm devが自動でやってくれているのです。

さらに、pnpm devで起動していれば、コードを書き換えた瞬間にブラウザへリアルタイムで反映されます。講義では、Quiz Viewerの表示に関わるファイルの文言を1単語消すと、リロードなしで即座にブラウザに反映される様子が示されました。AIに「もっとこうして」と指示してコードが書き換わるたび、昔のようにブラウザを何度もリロードする必要がないのは、開発において非常に楽です。

表記揺れとバリデーション ─ Markdown管理の限界

ビューアーはMarkdownをHTMLに変換して表示しています。AIに「わかりやすく表示するビューアーにして」と言った瞬間、MarkdownをHTMLに変換するプログラムが作られたのです。この運用で十分便利なら、このままでOKです。複雑にすることが常に正解ではありません。本気AIドリルも、AIがMarkdownでクイズを作り、ブラウザで見やすく確認するシンプルな運用から始まりました。

しかし問題数が増えるごとに、Markdownの限界が出てきます。あるクイズでは「選択肢」と書いていたのに、別のクイズでは「Option」と書かれてしまう。人間なら「別の書き方をしただけ」と理解できますが、MarkdownをHTMLに変換するプログラムには大問題です。「選択肢：」の後にテキストが続く形式だけを正とするプログラムに、「Option」形式のファイルを読ませるとエラーになります。プログラムは微妙なニュアンスを汲み取れません。それができるのはAIだけです。AIは柔軟でクリエイティブですが、こうしたちょっとしたミスは必ず起きます。そのときデータをすべてMarkdownで管理していると、とても大変です。

防ぐ方法はいくつかあります。1つは、スキルのなかに「選択肢は必ず『選択肢：』と書くように」と念押しを書くこと。これだけでもAIは間違いにくくなります。もっと確実なのが、機械的なバリデーションです。クイズ作成後に、Markdownファイルを解析して形式をチェックするプログラムを必ず動かします。

やり方は簡単で、AIに「模範解答の形式でクイズが作られることを、クイズを作成したあとにバリデーションでチェックするようにしてください」と伝えるだけです。プログラムが作られますが、その中身を1行1行読める必要はありません。ただし「どんなチェックをしているのか」は理解しておくべきです。実際に「Option」が並ぶ問題ファイルにこのスクリプト(小さなプログラム)をかけると、選択肢の部分が間違っているとエラーを表示してくれました。

このバリデーションをクイズ作成後に必ず実行する流れにするため、スキルに「クイズ作成後はこのバリデーションを実行して」と書き、スクリプト自体もスキル内に保存しておきます。こうすれば、間違った形式のクイズが作られてもバリデーションに引っかかり、AIが間違いに気づいて自分で修正してくれます。

MarkdownからJSONへ ─ 構造化データへの覚悟

次はMarkdownをJSONに変化させます。JSONとは一言でいうと「ラベルと中身をいつもセットで書く書き方」です。「これは選択肢ですよ」とラベルをつけて中身を書く。この組み合わせを決まった形で並べていくだけです。

JSONは構造化データです。構造化とは、パソコンでフォルダのなかにファイルを入れて整理するのと同じことです。一方Markdownは構造化データではなく、自由に書けます。どの箱に何が入っているかが厳密に決まらない書き方ができるため、柔軟で便利な反面、プログラムからすると扱いにくい。Markdownでデータを管理し続けることは、プログラムにとって扱いづらい形式で保存し続けることを意味します。

先ほどのバリデーションスクリプトを見返すと、中身はわからなくても「なんだかたくさん書かれている」ことはわかります。Markdownの解析はプログラムがやや複雑になるのです。講義では、クイズの形式が4種類(4択問題・○×問題・並び替え問題・組み合わせ問題)あるとして、○×問題だけを抽出するコードが比較されました。Markdownから抽出するコードは長く複雑になりますが、JSONで管理していれば非常にシンプルに書けます。JSONのほうがプログラムで扱いやすいデータ形式なのです。

Quiz Viewerを発展させて機能が増えるほど、Markdown保存の限界が近づきます。何をもって限界とするかは「決めの問題」です。そしてJSON形式への移行には覚悟が必要です。理由は2つあります。

1. JSONは人間にとって読みにくい — 緻密な形式で、カッコが1つ欠けるだけでプログラムの読み込みがエラーになります。
2. AIに出力させるならMarkdownのほうがのびのび動いてくれる — AIはJSONを作れますし、よくやることでもあります。しかし特に長く複雑なJSONを作らせると、緻密に作り上げようと頑張るがゆえに、肝心の中身の品質が下がることがありえます。

これを回避する方法が、「AIにはMarkdownでクイズを作らせ、そのあとプログラムでJSONに変換する」やり方です。AIにはMarkdownでのびのび作ってもらい、バリデーションで間違った保存を防ぎ、最後にスクリプトで変換します。実際にスキルを更新し、「最後はJSON形式にしてほしいので、スクリプトを書いてバリデーションのあとに実行して」と伝えると、変換スクリプトが作られました。スキルを動かすと、Markdown保存→バリデーション→問題なければJSON変換、という流れで処理されます。

ただし、絶対にこのやり方でなければいけないわけではありません。Markdownの構造チェックにはどうしても抜け漏れが生まれるため、最初からJSONを作らせたほうが手っ取り早いと感じる場面もあります。実際にスキルへ「最初からJSONで出力する」と書き、模範解答もJSONにして実行すると、AIはクイズのJSONを問題なく作りました。このぐらいの難易度なら劇的な差は感じられず、カッコの閉じ忘れやラベルの間違いもまれです。

つまりこれは設計判断です。Markdownで出力させるメリット・デメリット、JSONで出力させるメリット・デメリットを天秤にかけて、自分で判断するしかありません。押さえるべきは原理原則です。生成AIにはアテンションの壁があり、小難しいことを同時にたくさんやらせると、どれかが抜け落ちます。最大限の創造性を発揮してほしい難しい仕事なら、カッコをきっちり閉じることに頭を使わせないほうがよい。簡単な仕事ならJSONを直接作らせてもよい。AIが進化してJSON出力をものともしなくなる可能性もありますが、判断の軸となる原理は変わりません。

最後に、アプリケーション側もJSONに対応させます。作成したJSONファイルをチャットにドラッグ&ドロップし、「このようなJSON形式を表示するように変更して」と指示します(実際はもっと伝えたいことがあれば各自チューニングします)。pnpm devを起動していればコードの変更が自動反映され、JSONを読むQuiz Viewerができあがりました。

Gitという命綱 ─ ビューアーからQuiz Studioへ

ここまでで、品質の高いクイズを作り、作った人が見やすく確認できるようになりました。クイズ作成はCursor上で行いますが、スキルとして定義してあるので、Claude Code(ターミナルで動くAIコーディングツール)でもCodexでもAntigravity(いずれもAIコーディングツール)でも動きます。クイズのデータは、この時点ではリポジトリ内のJSONファイルとして管理されています。

Git(変更履歴を記録・巻き戻しできる仕組み)で管理していることの恩恵を確認しておきます。AIに「クイズを修正して」と指示すると、Cursorのソースコントロール(Git操作画面)で、何が変更されたかを差分として見られます。AIに次々と修正指示を出していると何がどう変わったかわからなくなりますが、Gitなら常に差分を確認し、コミット(変更の保存)して進められます。前の状態に戻したければコミット履歴から戻せます。「このクイズは消すけど、いつか使うかも」と「_Backup」の名前でファイルを残すような小細工も不要です。一度コミットしていれば残っているからです。

自分の認知できるボリュームで作っている間はGitは不要かもしれません。しかし、認知を超える大量のクイズをAIで作れるようになると、どこがどう変わったかわからなくなります。さらに厄介なのが複数人での作成です。誰がいつどこを編集したかわからない状況でも、Gitなら同じ箇所を編集したときにコンフリクト(競合。AさんとBさんが同じ場所を編集していますよという通知)が起き、どう直すかを人間に確認してくれます。気づかないうちに誰かの変更を上書きして消すことは、Gitでは起きません。

なぜここでGitの話を改めてするのか。データベースでクイズを管理するようになると、Gitの世界から出なければならないからです。データベースのなかの情報はGitで管理できません。両立させる運用──クイズはリポジトリ内のJSONを元データとし、そのデータをデータベースに流し込む──もありえますが、限界があります。Gitのリポジトリは膨大なデータの管理に向きません。XやInstagramのようなSNSの投稿すべてを1つのGitリポジトリのJSONに保存することはありえません。リポジトリには容量制限があり、データが膨大になるとGitの動きも重くなります。クイズが増え続ける限り、必ず限界を迎えます。

もう1つの課題は編集のしにくさです。JSON化した時点で、人間がファイルを直接修正する選択肢は「できなくはないが、やりにくい」ものになりました。間違えてカッコを1つ消せばエラーです。そこで、ただ見るだけのQuiz Viewerから卒業し、ブラウザ上でテキストを打って微修正できる「Quiz Studio」に変えていきます。Cursorのエージェントに「ブラウザ上でクイズを修正できるようにして」と伝えるだけで、編集機能が作られます。

ブラウザで問題文を変更すると何が起きるでしょうか。Gitを見ると、JSONファイルに差分が生まれています。ブラウザで修正した瞬間にプログラムが動き、JSONファイルが更新されているのです。うっかり問題文を全部消して保存する誤操作をしても、消される前のデータはGitに追跡されており、簡単に元に戻せます。

しかしこの命綱は、登るのがうまくなると邪魔に感じられるようになります。命綱とは、少し登っては杭を打ち、動かないことを確認して紐をつける行為の繰り返しです。プロのクライマーになったとき、50センチ登るごとに杭を打てと言われたらどうでしょう。ペースが落ちて逆に疲れ、杭を打つことが目的化して、登りきれなくなります。クイズ作成でいえば、GoogleドキュメントやWordのような感覚でブラウザ上の細かい修正が高速化していったとき、Gitには大量の差分が表示されます。「差分を確認できてよかった」と思えるうちは命綱が機能しています。しかし「もうGitなんて見てないよ」となったら──差分が大量に出て人間の認知が追いつかなくなったら──それがデータベースに移行するタイミングです。

データベースは「キャビネットの奥」 ─ AIとの距離

ここでAI活用における重要な話がされました。データの保存形式はMarkdownからJSON、そしてデータベースへと進んできました。JSONまではGitで管理できる世界でしたが、データベースはGit管理の外です。そして、AIに渡すコンテキスト情報として「ちょっと距離のある場所」になります。

Git管理されないため、保存の工夫をしない限り、うっかり8〜12問入りのレッスンをデータベースから消してしまえば二度と戻せません。厳密には、最近のデータベースサービスは有料プラン(それほど高くない)なら自動バックアップがあります。しかしGitのように細かくはなく、差分をいちいち認知することもできなくなります。

編集の手軽さも変わります。JSONで管理していれば、Cursorのエージェントに該当レッスンのJSONをドラッグ&ドロップして「この1問目を改善したい」と伝えるだけでした。JSON管理をやめれば、その手軽な受け渡しはできません。CursorやClaude CodeのようなAIコーディングツールは、自分でデータベースにアクセスし、修正対象を見つけ、データを取得して更新するところまでやってくれます。できるのです。ただし、どのデータベースを見るのか、権限やキーの設定をしておかなければ見に行けません。距離が生まれるのです。

講師はこれを資料の置き場所に例えました。データベースはAIからすると「鍵のかかったキャビネットの奥にファイリングされた資料」です。鍵を持って行き、開けて、ファイルから必要な資料を探さなければなりません。一方、Git管理されたMarkdownやJSONは「机の上に置かれた資料」で、AIはパッと見つけて作業できます。

データの保存とAIの性能は密接に関わっています。Webアプリケーションのデータ管理は突き詰めると膨大な分野で、商用サービスのレベルでは考えることが山ほどあります。そのレベルをやるなら経験豊富なソフトウェアエンジニアに依頼すべきです。このスクールで理解してほしいのは、完璧な開発知識ではなく「AIの性能を引き出すデータの管理方法」です。Markdown→JSON→データベースと進むほど、AIとの距離が離れていく。極論、それだけ覚えれば十分だと講師は強調しました。

Neonでクラウドデータベースを作る

最後に、JSONで管理してきたデータをデータベースに保存します。データベースの細部まで扱うと、それだけで6ヶ月の講義になるボリュームがあります。講師自身、10年以上データベースを扱っていても勉強不足と感じることがあると言います。完璧な理解をこの講義だけでしようとせず、「要するにこういうもの」と捉えて、作りながら必要な知識を身につけていきます。

データベースを動かす場所はざっくり2つ、自分の手元のパソコン(ローカル)か、クラウド上かです。ローカルにデータベースを作るのは開発者向けなので、今回はクラウドを使います。ドリルのデータもクラウド上に保存されています。構図としては、データの保存場所はネット上のクラウドにあり、Webアプリケーションは自分のパソコンで動いている状態です(手元で動くアプリを他の人もアクセスできるサーバーに置けば、みんなが使えるWebアプリケーションになります。手元で立ち上げるのはpnpm devですでにできています)。

やることは、クラウド上にデータベースを用意し、データを入れる表を作り、そこにクイズのデータを流し込むことです。今回はVercelと連携しやすい「Neon」というデータベースサービスを使います。Vercelを開き、マーケットプレイス(連携サービスの一覧)からNeonを選択すると、数クリックでクラウド上のデータベースが手に入ります。なお講義では割愛されましたが、ローカルのNext.jsアプリケーションをVercelにプッシュし、プロジェクトが作られている前提です。最終的にはVercel上のWebアプリケーションとNeonを接続しますが、この時点では、手元のパソコンで立ち上げたサーバーからNeonのデータベースとやり取りできるようにします。

操作でわからないことがあれば、Claude in Chrome(ブラウザ上で動くClaude)などでチャット質問したり、Cowork(ブラウザを操作してくれるAI)にセットアップさせたりもできます。ただしブラウザをAIに操作させることには一定のリスクがあると承知のうえで実行してください。

重要なのは、こまごまとした設定をブラウザの管理画面上で人間がやる必要はない、ということです。VercelやNeonを操作する権限のあるAPIキー(サービスを操作するための鍵)を発行し、環境変数ファイル(鍵を置いておく場所)に貼り付けておけば、AIがその鍵を読み取って設定をすべてやってくれます。

NeonのAPIキーさえあれば、JSON管理からデータベース管理への移行はとても簡単です。Cursorのエージェントに「今JSONで管理しているデータをNeonのデータベースで保存したいです」と指示します(CursorがNeonと接続できている状態が前提)。実行するとAIから「このような形式でいいですか」「こう進めていいですか」と聞かれるので、内容を理解し、わからなければ質問しながら進めます。小難しい作業を手作業でやらなくても移行できるのです。細かい手順をすべて覚えるより、「クラウド上にデータベースを作れば、その設定はAIとのチャットで全部できるはずだ」と理解しておくことが大切です。あとは自分の知見次第で、1つずつAIに聞きながら概念を理解していけば必ずできます。

できあがったデータベースの中身は、たくさんの表で構成されています。この表をテーブルといいます。現時点ではクイズのテーブルがあるだけです。Neonの管理画面で見られますが、そこまで見に行かなくても、AIに聞けばアスキーアートで教えてもらえます。ローカルでpnpm devを動かすと、Quiz Viewer改めQuiz Studioにデータベースの内容が表示されました。データベースの中身を変えると、リロードすれば画面の情報も更新されます。データベースを深く学びたい人には、本気AIドリルのデータベースシリーズがすすめられました。厳密にいえばデータベースにも様々な種類がありますが、そこまで高度な技術判断は今は不要です。

現在のQuiz Studioと、AIの限界を超える3つの道具

「では今はどうやって問題を作っているのか」。Quiz Studioは、作業者が手元のパソコンでサーバーを立ち上げて使う、外部非公開の「自分たち用の武器」です。一方、受講生が毎日解く本気AIドリルのアプリケーション自体はVercel上のサーバーに置かれています。両者は同じデータベースを見ています(もちろん、いきなり更新されないような工夫がされています)。

最新のQuiz Studioの画面右側には、AIが動くチャットが組み込まれています。簡単にいうと、ブラウザ上でClaude Codeを動かせるのです。現在クイズはCursorではなく、ここで作られています(Cursorを使うのはイレギュラーなときだけ)。この裏ではかなり複雑なハーネスエンジニアリングが行われていますが、その中身は「クイズを作ったあとにバリデーションをかける」「サブエージェントがレビューする」「スキルを動かす」と、すべて講義で説明済みのことです。

1つだけ、しっかり説明されていなかった仕組みがあります。フックです。クイズ作成後にプログラムで検証したいとき、スキルに「やって」と書いておくだけでは、AIがサボることがあります。このAIのサボりを強制的になくす仕組みがフックです。ただし取り扱いが難しく複雑になりやすいため、最初から使うことはおすすめされていません。「AIって気まぐれだな、やれと言ったことをやってくれないな」と思ったときに、フックというものがあると押さえておけば十分です。

点が線になる ─ 学びを自分の言葉にする

Webアプリケーション開発の技術を集中的に扱うのは今回までです。ここから先はどんどん複雑になっていくわけではありません。自分専用のWebアプリケーションを開発していくなら、今回学んだことを活かして1つずつ学ぶ必要があります。一方で、Webアプリケーション開発という形ではAIを活用しない人がいてもよい、と講師は言います。Webアプリケーションを作り上げることがゴールではなく、AIを活用して新しい価値を生み出すことがゴールであり、作るのはあくまで手段だからです。

たくさんの新しい概念が降り注いで大変だったはずです。細かいやり方を全部暗記するのではなく、「要するに、中学生でもわかる言葉で言うとどういうことか」という視点で振り返ることがすすめられました。細かい技術ややり方は常に移り変わりますが、本質は変わりません。自分なりの簡単な言葉に落とし込むことが、次につなげるために一番重要です。

技術的な知識が多いのはこの講義までです。難しく感じても心配はいりません。ここから先は新しい概念を覚える時間ではなく、ここまでで手に入れた「作る力」を使いこなしていく時間だと講師は締めくくりました。

次回はコンテンツ作成がテーマとなり、受講生が開発したWebアプリケーションの発表から始まります。ポータルの情報も参考に、自分なりのWebアプリケーションの完成を目指すことが課題です。

まとめ

• スキルもWebアプリケーションも、育て方の本質は同じ。「必要最小限の工数で小さく試す」こと
• AIに仕事を任せる5ステップは、ゴールの言語化→ゼロショット→模範解答→軽い打ち手での改善→磨き続ける
• 打ち手の階段は、手本を足す→頼み方を整える→サブエージェントレビュー→仕組みで守る。下から始め、ゴールに届いたらやめる
• 模範解答は2〜3個で十分。スキルは常に簡潔が正義
• 大量に作らせると品質は必ず下がる(アテンションの分散)。単位を小さくして比較する
• Markdownは柔軟だがプログラムに扱いにくく、JSONは厳密だが人間に読みにくい。AIにのびのび作らせたいならMarkdown→バリデーション→JSON変換という設計もある
• Gitは命綱。差分・コミット・巻き戻しで守ってくれるが、修正の速度が人間の認知を超えたらデータベースへ移行するタイミング
• データベースはAIにとって「鍵のかかったキャビネットの奥」。AIの手元に置くべき資料(模範解答など)はGit管理のMarkdownにする
• クラウドデータベース(Neonなど)の設定は、APIキーを環境変数ファイルに置けばAIとのチャットでほぼ完結する
• AIの限界を超える道具は、スキル・サブエージェント・フックの3つ

新出用語

• ゼロショット — 手本や具体例を一切見せずにAIへ依頼するやり方。まず雑に1回投げて、何が足りないかを偵察するのに使う
• バリデーション — データが正しい形式かをプログラムで検証する仕組み。フォームでメールアドレスの形式間違いを指摘してくれるのがその例
• フルパス — 実行する場所を省略せずすべて書いたファイル・フォルダの指定方法。どこにいても確実にコマンドを実行できる
• cdコマンド — チェンジディレクトリの略。ターミナル上で作業する場所(ディレクトリ)を移動するコマンド
• localhost — 自分のパソコンのなかにだけ通じる住所。開発中のWebアプリケーションの確認に使う
• pnpm — アプリ開発に必要な道具(ライブラリ)をネットから集めて管理してくれるツール。pnpm devで開発用サーバーが起動する
• フレームワーク — 小難しい実装を短く楽に書けるように設計された骨組み。Next.jsはその1つで、コードはHTML・CSS・JavaScriptに変換されてブラウザに表示される
• 構造化データ — フォルダにファイルを整理するように、どの箱に何が入るかが厳密に決まったデータ。JSONは構造化データで、Markdownはそうではない
• コンフリクト — Gitで複数人が同じ箇所を編集したときに起きる競合。Gitが検知して知らせてくれるため、誰かの変更を気づかず上書きすることがない
• テーブル — データベースのなかの1つひとつの表のこと
• 環境変数ファイル — APIキーなどの「鍵」を置いておく場所。ここに貼っておけばAIが読み取って外部サービスの設定を行える
• フック — スキルに書いただけではAIがサボることのある処理を、特定のタイミングで強制的に実行させる仕組み。強力だが複雑になりやすい