自分のツールに記憶を持たせる

第3章では、自分の仕事の型を3つから4つのペイン(画面の区画)の構造に落とし込み、Next.jsとshadcn/uiで自分専用ワークスペースの見た目を作り、リポジトリ(プロジェクトの保管庫)の作成からVercel公開までを一周体験しました。講義の冒頭では、その成果物であるワークスペースを1人5分で見せ合う発表会が行われました。ただし、ここまでに作ったWebアプリケーションは「見た目のみ」です。画面上で文章を編集できても、ブラウザをリロードするとすべて元に戻ってしまいます。

今月のテーマは「自分のツールに記憶を持たせる」です。見た目だけのツールにデータの保存を加えていきます。ただし、データの話はWebアプリケーションだけにとどまりません。AIはコンテキスト情報、つまりデータがないとそもそも動きません。どんなデータを持っているか、どんなデータを持たせるかが、AIを使いこなすうえでの核になります。

そこでこの講義は2部構成で進みます。前半はAIの活用法です。AIにどう情報を渡し、どう実力を引き出すのかを、講師が実際に開発したツールを題材に解説します。後半はWebアプリケーションにおけるデータの扱い方です。Markdown・JSON・データベースという3つの形式を比較しながら、データを保存する方法を具体的に学びます。

AIとの付き合い方には3つの段階がある

AIとの付き合い方には3つの段階があります。上に登るほど、AIにより複雑な仕事をさせることができます。

1段目 — 頼む

ChatGPTに質問する。Claudeに文章を直してもらう。「こんな画像を作って」と言って生成する。AIに何かを頼み、返ってきた結果を自分で受け取る。AIを「ただ使う」という立場です。多くの人はこの段階からスタートします。

2段目 — 整えて渡す

AIに頼むだけでは、AIは私たちのことを覚えてくれません。自分の流儀、自分の前提知識、自分の事業や仕事の前提、自分が理解しやすいコミュニケーション。これらを毎回ゼロから伝えるのは大変です。

その背景には、AIが持つ3つの限界があります。

1. コンテキストウィンドウ(AIが一度に扱える情報量の上限)
2. アテンション(AIが情報に向けられる注意力の限界)
3. オートリグレッション(直前までの自分の出力に引きずられて続きを生成する性質)

この限界がある以上、「AIが私たちのことを全部理解して、何も言わなくてもすべていい感じに仕事をしてくれる」という状態は、現段階の生成AIの技術ではかなり難しいのです。ではどうするか。自分の情報を整えて、AIに渡しやすくしておくこと。これがAI活用上級者への入り口です。

情報を整えて渡すための道具は、すでにこれまでの章で学んできました。

• CLAUDE.md・AGENTS.md・Cursor Rules — AIに常に適用したいルールを書いておくファイル
• スキル — 自分の繰り返す作業を記録して、AIが呼び出せるようにしておく仕組み。育てていくもの
• Git — AIに渡す情報を整えていく場所。いつ何を変えたかが全部記録に残り、戻すことができるから、AIに思い切って仕事を任せられる

3段目 — AIが自分の代わりに動く仕掛けを自分で作る

これらの道具を持ったうえで初めてたどり着けるのが3段目です。自分がAIに「これやって、あれやって」と言う必要がない。仕事の流れの中にAIが組み込まれていて、自分がいない間もAIが仕事を始めている。勝手にどんどん進めていくのに、やり直しが起きない。「そうそう、そういうのが欲しかったんだよ」というアウトプットしか出ない状態を作る。この3段目には名前があります。ハーネスエンジニアリングです。AI業界の中で、今一番ホットな領域のひとつとされています。

ハーネスエンジニアリングとは何か

ハーネスとは、馬に取り付ける装置のことです。この装置は拘束具ではありません。馬の力を最大限引き出しつつ、暴れないように、乗っている人の意図する方向に走らせるための道具です。「力を引き出す」と「暴走を止める」。この2つを同時にやるのがハーネスです。

これをAIに当てはめます。AIは賢く、自律的に動きます。しかし、AIにどんどんやらせて放っておくと、とんでもない方向に走り出します。とはいえ、抑え込みすぎると力が出ません。抑え込むとは、たとえばこと細かにすべて確認していくことです。それなら「もう自分がやったほうが速いじゃん」という話になってしまいます。だからこそ、力を引き出しつつ道を外さないように整える仕組みを自分で組む。これがハーネスエンジニアリングです。

プロンプトからコンテキスト、そしてハーネスへ

AI業界の流れは次のように変わってきました。

2025年に流れを変えたのは、AI業界の重鎮であるカーパシー氏が「コンテキストエンジニアリング」という言葉を広めたことでした。AIが賢くなり、指示の仕方だけで劇的な差がつく時代が終わったのです。そして、AIに渡す情報を整えるというのは、まさに私たちがこれまでやってきたことです。私たちはすでにコンテキストエンジニアリングを実践してきました。そのさらなる発展形として、2026年にハーネスエンジニアリングという言葉が生まれました。

重要なのは、この3つは別物ではなく積み重なっているということです。つまり、ハーネスエンジニアリングができるということは、コンテキストエンジニアリングもプロンプトエンジニアリングもできるということを意味します。

ただし、ハーネスエンジニアリングは「これをやればできます」というシンプルな話ではありません。プロのサッカー選手になるために何をしたらいいかという問いに、「ドリブルの練習さえすればいい」とはならないのと同じです。私たちはここまで、ある意味でハーネスエンジニアリングをするために学んできたのです。

実例 — クイズ作成ツール「Quiz Studio」

言葉だけではイメージがつかみにくいため、ハーネスエンジニアリングの考え方をもとに開発され、実際に動いている実物を見ていきます。受講生が使っている学習サービス「本気AIドリル」の問題を作るために、講師が約2ヶ月かけて開発した社内ツール「Quiz Studio」です。

まず誤解のないように前提があります。すべての問題は人間が確認しています。AIに作らせたら全部できて終わり、が実現できればそのほうがいいのですが、おそらく世界中のどんな優れたAIエンジニアがハーネスを設計しても、人間がまったくチェックしない状態には持っていけないはずです。それでも、AI以前の時代と比べたら圧倒的な効率で問題を作成できています。

本気AIドリルには複数のクイズのパターンがあり、問題解説用の図解やイラストも付いています。1シリーズで600問から700問。もしすべて手作業で作るなら、1シリーズだけで1ヶ月かかります。それが今は、シリーズによって差はあるものの、1週間から2週間で600問以上ある1つのシリーズを作成できるようになっています。Quiz Studioなしに本気AIドリルの問題を作ることはできません。

本気AIドリルの学習設計

本気AIドリルは、教材を読み込んで体系的に学んでから練習問題を解くという旧来型の学習ではなく、身近なことと紐づけて概念を「体験として慣れて学ぶ」ことに重きを置いています。レッスンの最後に間違えた問題を解き直す復習はありますが、「同じ問題を解き直す復習」という概念はありません。復習は楽しくないからです。復習だけのレッスンがあれば、多くの人は「なんだ復習か」と退屈に感じます。そこで、レッスンを進めるごとに自然と過去の概念を復習できる流れになっています。1つの概念を何回・どのタイミングで復習するかは、すべて数字で計測されて計算されています。

さらに、1つの概念は同じメタファー(比喩表現)で表現するというルールがあります。たとえばGitのコミットを「セーブポイント」と説明したら、それ以外の説明は出さないようにする。もしAIに大量に問題を作らせたら、間違いなく違うメタファーでの説明が混じってきます。それ以外にも「それは違うんだよな」というポイントが山のように出てきて、1つずつ修正するくらいなら人間がゼロから作ったほうが速い、と思えてきます。そこで開発されたのがQuiz Studioです。

手元で動かす社内ツール

Quiz Studioは一般公開されているサービスではなく、運営チームが使う社内ツールです。Vercelのようなサーバー上にもアップしていません。運営チームのメンバーがそれぞれ自分のパソコンで立ち上げて使います。サーバーに上げてもダメではないのですが、ツールを修正したときにgit pull(最新版を手元に取り込む操作)すればすぐ手元に反映されて使えるほうが、毎回プッシュしてサーバーへの反映を確認するよりスピーディーだからです。

Quiz StudioはNext.js、shadcn/ui、Tailwind CSSでできています。つまり受講生が作ったツールと同じように、pnpm devで起動します。起動する場所(どのフォルダで立ち上げるか)が大事、というこれまでの学びの通り、Quiz Studioのある場所に移動して起動すれば、ブラウザで使えるツールになります。

クイズ作成の3ステップ

Quiz Studioでは、大きく3つのステップでクイズを作ります。

1. シリーズガイドを作る — シリーズの企画書。どのようなシリーズか、どんなコース構成か、どんな概念を伝えるか、どんなメタファーを使うかがまとめられる
2. コースガイドを作る — コース一覧にあるひとつひとつのコースの企画書
3. レッスンを作る — 8問から12問のクイズそのもの

シリーズガイドを作る前には、第3章で紹介した「grill-me」(企画の甘いところを一問一答で、推奨案付きに壁打ちしてくれるスキル)を使い、どんなシリーズにするかをAIと壁打ちして大枠を決めておくこともします。

Quiz Studioの特徴は、ブラウザ上でAIを動かせることです。ざっくり言うと、Agent SDK(アプリの中にAIエージェントを組み込むための開発キット)が組み込まれています。AIとチャットできるエージェントパネルからスキルを呼び出せるようになっており、たとえば新しいシリーズを作りたければ「シリーズを作るスキル」を選び、「こんなシリーズを作りたい」と書いて投稿すれば、シリーズガイドが作られます。

上流はAIに任せない

シリーズガイドのような企画は、一発出しで完成とはいきません。特に企画の上段をAIに任せきりにするのはおすすめできません。シリーズの企画書、コースの企画書、実際のクイズ(レッスン)の順で、上にいくほど「上流」です。第1章でも扱った通り、上流をAIにやらせようとする人が多いのですが、それは間違いです。AIを活用したいのであれば、上流をポンとやらせるのではなく、価値を生むプロセスの下流をAIで解決する。そして人間が詰め切るためのツールを作る、という考え方です。

作成されたシリーズガイドはあくまで叩き台です。講師自身も目で見て頭で理解し、AIと対話しながら磨いていきます。

なぜCursorではなく専用UIなのか

「これはCursorでスキルを呼び出しても同じでは?」という疑問が出ます。結論、ほぼ同じです。作成されたシリーズガイドはJSONという形式でリポジトリ内に保存されており、ツール上でやってもCursorやClaude Code上でやっても、行われることはほぼ変わりません。それでもUI上でAIを動かす理由は2つです。

1. 情報を渡しやすいこと
2. 見やすいこと

CursorやClaude Code、Codexを見て、またブラウザのUIを見て、という行き来は大変です。UI上でボタンをポチッと押せばすぐに作り始められる。ちょっとしたことですが、人間のミスを減らし、人間の認知をしやすくし、生産性が上がります。

クイズ作成の裏側 — 合格するまで終わらないレビューの仕組み

「スキルが動きました」という一言の中には、複雑な処理のプロセスがあります。レッスン(クイズ)作成を例に、何が行われているかを見ていきます。

クイズ作成スキルを動かすと、AIが立ち上がって仕事を始めます。立ち上がった瞬間に、仕事に必要な資料が渡されます。まずCLAUDE.mdが読み込まれ、これがクイズ作成アプリケーションであること、どんなクイズをどのように作りたいのかをAIが理解します。しかしそれだけでは足りません。ここまで作成したシリーズガイドとコースガイドを読み込み、上段の企画を理解したうえでクイズを作る必要があります。さらに、AIが立ち上がった時点ではどのクイズを作るかもわからないため、「このシリーズのこのコースのこのレッスンを作って」という指示も入れています。

そこからの大枠の流れは次の通りです。

1. 8問から12問のクイズの下書き(ドラフト)を作る
2. レビューを行い、OKなら実際にクイズを作成する
3. OKでなければドラフトを修正し、合格するまで何度でもやり直す

評価するのはサブエージェント(メインのAIとは別に立ち上がる子のAI)です。別のAIが評価するため、オートリグレッションが働いて「自分が作ったものを正当化する」ということができません。

レビューは、8問から12問のクイズ1問ずつに対してサブエージェントが立ち上がります。12問なら12個のサブエージェントです。そこで2種類の評価が行われます。

1. 機械的なプログラムによるチェック — 使ってはいけないワードが入っていないか、問題数が(規定を超えて)20問になっていないか、問題文が長すぎたり短すぎたりしないか。膨大な機械的チェックがあり、通過しなければやり直しになる
2. AIによるレビュー — チームで決めたクイズの品質基準をまとめた「クオリティチェックシート」のMarkdownファイルを元に、実際にチェックする

ただし、このチェックリストは量が膨大です。たとえば50項目のチェックリストを12問分行うと、1項目1行としても600行のファイルをAIが書かなければなりません。AIはインプットは得意ですが、アウトプットはとても苦手で、負荷がかかります。だからこそ、クイズの数だけサブエージェントを立ち上げているのです。並列で動かすことでスピードアップにもなります。

すべて合格したら、今度は「批判的なユーザー目線で問題を解いて感想を言う」サブエージェントが動きます。そのフィードバックを元に問題を改善し、改善(アップデート)したクイズだけ、再びクイズ単位でレビューが走ります。

この一連の流れは、スキルに手順として書いてあるだけではありません。「このような手順でやってね」と書いても、AIは平気でサボり、手順を自分の判断でスキップします。そこで、スキップできない仕組みが入っています。下書きを作る段階、クイズを作る段階、サブエージェントでレビューする段階、修正する段階、シビアなユーザー目線のフィードバックをもらう段階——という段階ごとに、AIが自動で起動するフック(特定のタイミングで処理を自動発動させる仕組み)を入れています。長い仕事のプロセスを一気に渡して待つのではなく、「まずここまでやってね」と範囲を絞り、終わったら「次はこれ」という指示が自動で走る。その繰り返しが自動で行われる仕組みです(フックの詳細は別の講義で解説されます)。

ハーネスの5つの軸と、データの保存を学ぶ理由

ハーネスの中身は5つの軸に分けられます。

1. データを整理整頓する — Gitリポジトリでデータを整理整頓するのもその1つ
2. データの探し方を決める — 普段意識しないが、Cursorが裏側でやっていることの中身
3. 作業中の記憶を設計する — AIの記憶(コンテキストウィンドウ)は限られている。たくさん渡せばいいのではなく「そのトークンはコンテキストウィンドウを消費するに値するか」を考える(Anthropicの技術ブログで学んだ考え方)
4. やり方とルールを明文化する — CLAUDE.md・AGENTS.md・Cursor Rules・スキルの定義など
5. 外側からやり直しを強制する — サブエージェントのレビューがダメならやり直させる仕組み。「外側から」という点が非常に重要

この5つは抽象度の高い概念であり、「これをやれば絶対うまくいく」という1つの正解があるわけではありません。試行錯誤するときの考え方の軸です。AIを制御するハーネスが5つの軸で整理できる、とざっくり理解できれば現時点では十分です。

ではなぜ、データ保存の講義でこの話をするのか。AI-Driven SchoolはWebアプリケーション開発講座ではなく、AIを活用できる人材になることをゴールにしています。データの保存自体は一般的なプログラミングスクールでも学べます。しかしここで学ぶ目的は、開発のやり方を覚えることでも、エンジニアになることでもありません。目指すのは、ハーネスエンジニアリングを自分でできる人間になることです。自分専用の武器を自分で作れるようになる、その最終到達地点がハーネスエンジニアリングであり、そのためには「今はリロードすると消えてしまうWebアプリケーション」のデータの保持を学ぶ必要があるのです。

文字データを扱う3つの形式

ここからは後半、Webアプリケーションのデータの保存の話です。厳密にはかなり大まかなまとめ方ですが、今回の説明のために整理すると、文字のデータを扱う形式は3つあります。

1. Markdown — スキルの作成などで何度も扱ってきた、人間が読み書きしやすい記述形式
2. JSON — かっこで構造を作る、データをまとめるための書き方の作法。複雑な仕組みではなく、英語や日本語の文法のようなもの。データを常に整理整頓して扱いたいときに便利
3. データベース — ざっくり言うと「複数人で読み書きする、たくさんの表が入った箱」。現時点では「データを保存する表のようなもの」と捉えれば十分

画像・動画・音声のような文字以外のデータは、後の節で扱います。

「Webアプリケーションでデータを保存する」と聞くと、データベースを使うのだとイメージした人が多いかもしれません。実際、XやSlackのような大勢が使うWebアプリケーションを開発するなら、データベースを使うことは確定します。使うしかありません。しかし、私たちは何十万人・何百万人が使う大ヒットサービスをゼロから開発するわけではありません。自分の仕事を効率化する、自分だけが使うツールを開発するときに、データベースはマストではないのです。

さらに言えば、Next.js・shadcn/uiのWebアプリケーションを作ること自体もマストではありません。自分でUI(画面)を作らないという選択肢もあります。講義でWebアプリケーションを作成しているのは、選択肢を増やすためです。常に自分専用のWebアプリケーションを開発することが正解ではない。しかし、やり方がまったくわからず、イメージすらできない状態では、選択肢を持つことすらできません。以前扱ったMVP(実用最小限の製品)の話でも、「MVPの検証はコードを書かなくてもできる」と学びました。常にコードを書くことが正解ではないのです。

この講義では、Markdownだけの文章をJSON形式、さらにデータベースへと発展させていくプロセスを見ていきます。この流れで説明するのは、「適切なデータの形式はこう考えればいいのか」と納得しやすいからです。常にMarkdown→JSON→データベースの順を守る必要はありません。ただし、この順に発展するにつれて考えるべきことが増え、複雑になります。複雑さと引き換えに得られる恩恵もあります。そのメリット・デメリットの中で自分はどう進めるか、選択肢を持てるようになることが目的です。考え方に注目してください。

Markdownだけで作る自分専用ツール

題材は、配布されたワークスペースUIキットの採用管理サンプルアプリ(採用候補者の管理画面)です。このアプリのデータは、dataフォルダの下のcandidates.jsonというJSON形式のファイルに入っています。今回は説明のために、このアプリをあえて「退化」させ、UIもまだ存在しないMarkdownだけの状態から考えていきます。

CursorはAIエディターです。候補者の情報を更新したいときは、チャットでAIに依頼すれば新規作成も更新もできます。実はもうこれだけで、ツールとして成り立っています。リポジトリで管理していれば、自分たちがどんな会社でどんな事業をやっているのかというコンテキストを整理しておけますし、スキルを置くことも、CLAUDE.md・AGENTS.md・Cursor Rulesのような常に適用したいルールを整理することもできます。情報をGitリポジトリで整理整頓するだけで、すでに便利なツールが完成しているのです。

一方、UI(画面)を作るのは大変です。shadcn/uiを使ったとしても、一発で完璧に、やりたいことが全部できて見た目もきっちり揃う、ということは起きません。ボタンを並べ、レイアウトを整える微調整・チューニングが必要です。せっかくいい感じにできたと思ったら、AIが壊し始めることもあります。何度も微調整してUIは完成します。でもMarkdownだけでいいなら、画面を作らなくていいのです。

実際の手順はこれだけです。Gitリポジトリを作ってクローン(手元に複製)し、Cursorを開き、候補者の情報を入れるフォルダ(candidates)を作り、その中に候補者の名前でMarkdownファイル(例: 佐藤花子.md)を作る。中身は普通の文章です。Markdown形式なので自由に書けます。面接のときの情報、ヒアリングで得られた情報、面接官の評価。全部Markdownで書いて、candidatesフォルダに放り込んでいけば、自分の採用管理ツールになります。書き直してもGitで履歴が残ります。Gitリポジトリで管理してさえいれば、スマホのブラウザでCursorを開き、スマホ上でリポジトリの情報を読んだAIに仕事をさせることもできます。

たとえば候補者に内定を伝える文章をAIに考えてほしいとき、チャットで依頼して候補者の情報を渡せば考えてもらえます。繰り返しやるならスキルにしておくことで、いつも同じ品質の文章を出してもらえます。

ただし、次のような瞬間が来ることがあります。候補者が10人、20人、数十人、100人以上と増え、候補者の数だけMarkdownファイルがずらっと並ぶと、Cursorで見るのは見にくくなります。全員を見比べたい、スコアで並べたい。そう思ったとき、Markdownだけだと苦しくなります。できなくはないけれど、見づらく扱いにくいのです。

ビューアーというハイブリッド戦略とパースの仕組み

ここから先の一歩を踏み出すには、覚悟が必要です。より見やすくするために、3つから4つのペインのある自分専用のワークスペースUIを作ろうと踏み出したら、大変になります。中途半端に作っても使いにくいだけなので、進むからには一定やり切らないと恩恵を受けられません。

最大の問題は、自分でUIを作っても、そのUIの上でCursorのようなAIが動くわけではないということです。Quiz Studioのように動かすことは実装可能で、うまく実装すれば強力なツールになります。しかし、5分でできあがるような簡単なものではありません。

そこで講師が推奨するのがハイブリッドです。たとえば採用管理ツールなら、候補者の情報を編集するときはCursorを使い、見るのはUI上で行う。つまりビューアー(閲覧専用の画面)として作るのです。実はQuiz Studioも最初はビューアーから始まりました。当初の名前は「Quiz Viewer」だったのです。膨大な量のクイズをすべてファイルで管理していると何がなんだかわからなくなるため、まずはMarkdownで作られたクイズをブラウザ上で見やすく表示するところから小さくスタートしました。

ビューアーを作るだけなら、Next.js・shadcn/uiを使って「Markdownを表示できるようにしてほしい」とAIに伝えれば、すぐにWebアプリケーションを開発してくれます。Cursor上で見ていたMarkdownが、ブラウザ上で見やすく表示される。それだけのものです。

Markdownが画面に表示されるまで

ここで重要な話があります。ブラウザというのは、HTML・CSS・JavaScriptを表示する道具です。Markdownという概念をブラウザはまったく知らず、Markdownを表示する機能もありません。実際、Markdownファイルを単純にブラウザで開くと、ただテキストが表示されるだけです。それなのに、ビューアーでは見やすく表示されている。何が起きているのでしょうか。

Google Chromeなら、右クリックして「検証」を押すと、開発者モードが開きます(本格的に開発するときは、この画面をずっと見続けることになります)。ここで、表示されているページがどんなHTMLになっているかを見られます。すると、たくさんのタグで文章が囲まれています。元のMarkdownにはそんなものは付いていませんでした。たとえば見出しは、Markdownではシャープ(#)の後に半角スペースを置いて文字を書いているだけですが、HTMLで見るとシャープ1個ならh1タグ、シャープ2個ならh2タグになっています。

これはブラウザの機能ではありません。AIがMarkdownビューアーのNext.jsアプリを作ったときに、MarkdownをHTMLに変換するプログラムを書いてくれたのです。このプロセスをパースといいます。Aという形式で書かれた文章をBという形式に変換すること、と理解できれば十分です。ページを開いた瞬間にプログラムが動き、MarkdownをパースしてHTMLに変換し、ブラウザで表示している。簡単に言うとそういうことが起きています。

Markdownの限界とJSONへの移行

では、データは全部Markdownでいいのでしょうか。結論、できなくはないけれど難しいです。Markdownは人間が読みやすいように作られた、自由に書いていい形式だからです。

プログラムは文脈を読めない

具体例で見ます。candidatesフォルダに3人分のMarkdownがあるとします。

• 佐藤さんのファイル: 「評価：4」
• 田中さんのファイル: 「評価：A」
• 鈴木さんのファイル: 「レビュー：5」

微妙に書き方が違います。人間が見れば意味はわかります。「評価もレビューも同じ意味で使っているんだな。できれば評価という言葉で統一してほしいな」と思うくらいで、人間が読むならそれで終わりです。しかし、プログラムからしたら大問題です。

プログラムは、人間やAIのように文脈を読んで、ざっくりでも大枠の意味を捉えるということが一切できません。たとえば「Markdownの中の評価を星マークで見せる」という変換をしたい場合、プログラムは佐藤さんの形式(評価：4)を想定して書かれます。「評価」という言葉でなければならず、コロンは半角の「:」でなければならず、その後には数字がなければならない。田中さんのような「評価：A」や、鈴木さんのような「レビュー：5」があると、表示を開いた瞬間にエラーが出ます。

Markdownは自由で柔軟です。その反面、きっちりしていません。この「きっちりしていない」ことが、プログラムが動くWebアプリケーション開発においては致命的な弱点になります。AIにMarkdownを書かせるとだいたい正確ですが、たまに「評価：A」「レビュー：B」のようなことを書き始めます。1つでもあればエラーです。しかも、あからさまな間違いだけではありません。不要なところに全角スペースが入っている、改行が入っていないといった、普通の人間なら気づきもしないちょっとしたズレでも、プログラムはエラーを出します。

Markdownで情報を管理してWebアプリケーションを発展させていくと、Markdownという自由なフォーマットに対応するために複雑なプログラムを書かなければならなくなります。最初はうまく動いても、やがて限界が来て、何をやってもバグが生まれ、新しい機能を追加できない。そんな「詰んでいる」状況に陥ることは確実です。

JSONはプログラムのための形式

そこで登場するのがJSONです。JSONは自由ではありません。かっこで閉じることで階層を表現し、たとえば閉じかっこがないだけで構文エラーになります。Cursor上でも「かっこがないですよ」と表示されます。候補者の情報をMarkdownからJSONに変換すると、それぞれの項目の前にラベルが付きます。このラベルをキーと呼びます。JSONは「キーと、キーに対応する情報」という構造になっており、1つのキーの中に複数の情報を入れることもできます。1つの箱の中に3つの箱を置けるようなものです。

JSONにすると、プログラムが非常に簡単になります。たとえば「評価が4以上の候補者を取り出す」という処理を書く場合、Markdownだと次のようになります。

1. 1人の候補者のMarkdownファイルを全部読み込む
2. 行ごとに分解する
3. 「評価」という言葉を含む行を探す
4. コロン(：)の後を切り出す
5. コロンの後の情報を数字に変換できるか確認する(問題があれば対応する)
6. これを候補者ごとに繰り返す

実際のプログラムにすると複雑な処理です。ところがJSONなら、同じことがごく短い記述で書けます。文法を理解する必要はありません。「プログラムにとってはJSONが扱いやすい」ということが理解できていれば十分です。

では最初から全部JSONで作ればいいかというと、そうではありません。Markdownは見やすく、Cursorのプレビューできれいに表示できます。JSONはCursor上で見やすく表示できません。Markdownは人間が見やすいように作られた記述方法で、JSONはプログラムのために作られた形式なのです。

AIにとってのJSONのコスト

もう1つ、頭に入れておくべきことがあります。JSONを作るのは、AIにとってもコストだということです。AIはプログラムのように精密なことをやるのが苦手で、いわば雰囲気で仕事をしています。Markdownが自由作文だとすれば、JSONは、はみ出してはいけない、きれいな字で書かなければいけない手書きの履歴書を完成させるのに近い作業です。AIはすごく集中して注意(アテンション)を払いながらJSONを作り上げます。今のAIは賢いので明らかな性能低下は感じないかもしれませんが、それでも負荷はかかっています。

ただし、絶対にダメというわけではありません。必要な場面もあります。

移行には覚悟がいる

ここまでの流れをまとめます。自分専用ツールに必ずしもUIは要らず、Markdown管理でもいい。しかしMarkdownだけでは見づらくなるので、ブラウザで見やすいビューアーを作る。ビューアーはMarkdownをHTMLにパースしており、それをやるのはプログラムである。プログラムが自由なMarkdownを扱うのは大変で、プログラムが複雑化し、そのまま進めると必ず破綻する。そこで役立つのがJSONで、プログラムはシンプルになる。ただし人間には読みにくく、AIに作らせると性能を奪う——。

より見やすく使いやすいWebアプリケーションを作ろうとすると、「もうMarkdownでの情報の保存は限界だ、JSON形式に切り替えよう」というタイミングが来ます。Quiz Studioもそうでした。ただし、この移行にも覚悟を決めた一歩が必要です。見やすかったMarkdownをJSONにするということは、もうCursorのようなエディターでは読みにくくなるということです。「もう全部ツールで見るんだ」という覚悟を決めた者だけが、MarkdownをJSONに変換する判断ができます。Markdownで管理していた頃はこんなに緻密に考えなくてもよかったのに、と思うかもしれません。でもMarkdownに戻ればプログラムが複雑になる。メリットとデメリットがあるのです。そして、このJSONにも限界があります。

データベース — 複数人で使うための箱

配布された採用管理のひな形は、JSONの情報を表示しています。JSONから候補者の名前などを取り出し、HTMLの中に流し込んでブラウザで表示します。このJSONからHTMLへの変換を行っているのはブラウザではなく、サーバー上です。ブラウザができるのはHTML・CSS・JavaScriptを動かすことだけだからです。

このJSON管理にも限界が来ます。自分の手元のパソコンにある、Gitで管理しているJSONファイルを見るだけなら特に困りません。しかし、この採用管理アプリをVercelで公開し、社内の複数人が使うようにしたいと考えたら、データベースを使うしかありません。理由はいくつかありますが小難しくなるため、講義では「複数人が使うWebアプリケーションにしたければ、データベースを使うしかない」という結論を押さえれば十分とされています。

データベースを使ううえでの前提が2つあります。

1. データベースは自分のPCの中でも動く — サーバーに置くものというイメージが強いかもしれませんが、手元のパソコンの中でも動きます。開発中は手元で動かすほうが速く、壊しても自分しか影響を受けないので、安全で効率的です。サーバーに置くのは、他の人と同じデータを共有したい瞬間です
2. データベースを置くだけでは何も動かない — プログラムがデータベースにアクセスして情報を取ってきて、適切に処理し、HTML・CSS・JavaScriptにして返す。この一連の動作があって初めてデータベースは意味を持ちます。データベースそのものは、ただのデータ置き場です

Neonとの連携

講義では、Vercelと連携しやすいNeonというサービスを使います。Vercelのダッシュボードを開き、ストレージのタブにあるマーケットプレイスを見ると、データベースを提供するサービスがずらっと並んでいます。その中からNeonを選び、Createボタンを押すだけです。Neonを選ぶ理由は3つあります。

1. Vercelとボタン一つでつながる
2. Postgresが使える — 今一番よく使われているデータベースの形式。データベースには色々な種類がありますが、迷ったら今はPostgresを選んでおけば大体大丈夫です。NeonはそのPostgresがすぐ使えるサービスです
3. 無料で始められる

他の候補もあります。たとえば講師のチームではSupabaseというデータベースのサービスをよく使います。どちらも良し悪しがありますが、要するにどちらもPostgresのデータベースを簡単に使えるサービスです。今回は一番摩擦が少ない選択としてNeonを使います。

環境変数 — 鍵はプログラムに書かない

Vercel上でNeonとつなぐと、サーバーのアドレスやパスワードに当たる情報が、アプリの環境変数というところに自動で入ってきます。環境変数は、開発に関わるなら絶対に覚えなければならない概念です。環境変数とは、プログラムの中に埋め込むことができない重要情報たちのことです。

データベースの中身 — 表・カラム・SQL

データベースは「たくさんの表が入った箱」です。1つのデータベースの中に複数の表を並べられます。Excelやスプレッドシートで、1つのシートの中にたくさんのタブを作れるのと同じです。今回作るのは候補者一覧のcandidatesという表1つだけですが、たとえば面接の記録を残すinterviews、社内のメンバーを管理するusersといった表を追加できます。なお、テーブル(表)名は複数形にするのが一般的です。

親と子の紐付け — 同じ情報を二度書かない

データベースでは、表形式で情報が被らないように整理整頓して保存します。整理整頓されていない状態とは、たとえばこうです。1人の候補者に対して面接は何度も行われます。このとき、候補者の名前のような基礎的な情報が、面接の回数の分だけコピー&ペーストされて保存されている——これが整理整頓されていない状態です。

データベースの表における重要な概念は、同じ情報を書かなくていいように親と子の紐付けができることです。表の1行のことをレコードといいます。candidatesの1レコード(1人の候補者)に対して、interviewsの複数レコード(複数回の面接記録)が紐付きます。どうやって結びついているかというと、candidatesの一番左にあるID(識別番号)がinterviews側にも入っているのです。candidatesのIDが1なら、interviews側にも候補者ID=1と入っている。これで紐付きます。情報と情報を紐付けて整理していくもの、と今は理解できれば十分です。

カラム — 列ごとに入る値を厳密に決める

次に縦の列です。この列のことをカラムと呼びます。カラムは、列ごとに入れる値の種類を決められます。たとえばスコアの列には数字しか入らない、名前の列には文字しか入らない。プログラムにおいて、数字と文字は厳密に分かれます。単純な文字か数字かだけでなく、配列(複数の値の並び)やJSONのような複雑な情報を入れられるカラムもあります。

Markdownでは、プログラム側でデータの揺れ(評価の後が数字なのか英語なのか)を全部吸収するしかありませんでした。しかしデータベースは、そもそも「ここは数字しか入れられない」と決めたら、数字以外を入れようとするとエラーになります。データベース構築のセオリーは、何でも入れられるようにするのではなく、数字なら数字だけ、名前なら文字だけと、間違った情報が入らないように決めていくことです。

SQL — 表の操作はすべてこの言語で

表を作る、候補者を1人追加する、といったデータベースの操作はSQLという言語で行います。中身はほぼ英語の文です。たとえば「候補者の表から全部選ぶ」という命令が書けます。追加するときはINSERT、書き換えるときはUPDATE、消すときはDELETE、表を作成するときはCREATE。表の操作すべてがSQLで動きます。

SQLはプログラムなので、1文字間違ったら動きません。ただし今の時代、商用のきちんとしたWebアプリケーションを作るのでなければ、ゼロから複雑なSQLを手書きすることはほぼありません。AIが全部書いてくれるからです。

では、WebアプリケーションにおいてこのSQLを動かすのは誰でしょうか。私たちの書いたプログラムです。たとえばJavaScriptで書かれたNode.js(サーバーの中で動く、JavaScriptで書ける言語)が、あらかじめ用意したプログラムを通じてSQLを動かします。

処理の流れを1つずつ追う

ブラウザで候補者一覧を表示するとき、どういう流れで動くのか。これまでの復習も含めて追いかけます。

1. ブラウザでURLを開くと、採用管理ツールがセットアップされているサーバー(私たちの場合はVercelのサーバー)にリクエストが送られる
2. Vercelにはブラウザが読めるHTML・CSS・JavaScriptの状態になったコードが置いてあり、それをブラウザに返す
3. ブラウザで画面が表示される(最初の表示のときに候補者一覧のデータをデータベースから持ってきて一緒に返すこともできる)
4. あるいは一度HTML・CSS・JavaScriptを返した後、アプリケーションがもう一度通信を走らせる
5. サーバー側でNode.jsが動き、データベースに対してSQLを実行する
6. 候補者一覧の情報がNode.js側に戻ってくる
7. その情報をJSON形式にしてブラウザに返す
8. JSONはデータの形式でありそのまま表示できないので、HTMLのひな型に入れてブラウザに描画する
9. 候補者一覧が表示される

説明すると長いですが、実際は一瞬です。この説明を難しいと感じるのが自然です。以前の講義でも扱った通り、自分が触って慣れていないものを、人の説明を聞くだけで完璧に使いこなせる自信を持てる人は絶対にいません。不安を感じるなら、それはまだ慣れていないだけです。講義でできるのは極力噛み砕いて雰囲気をつかんでもらうことであり、理解するには自分でAIに聞くことです。

データベースの強みとAIからの距離

データベースの強みは、検索がとにかく速いことです。候補者が1万件、10万件あっても、「面接のスコアが4以上で、最終面接まで進んでいる人」という絞り込みが瞬時に返ってきます。JSONのままだと、10万人分の情報が入ったJSONファイルは重くて開けません。読み込みに時間がかかり、スクロールもまともにできず、プログラムがうまく処理することもできません。Markdownも同じです。データベースは、きれいに整理整頓して置いてさえいれば、一瞬で必要な情報を探してきてくれます。AIのような探し方ではなく、プログラムで機械的に探すのが速い、ということです。だからデータベースが使われています。

「候補者ごとにJSONファイルを分ければ問題ないのでは?」と思うかもしれませんが、それも問題です。1つのフォルダを開くと10万件のJSONファイルがある——これは開けません。ファイル管理の限界を超えています。フォルダの中に何十万件も入れることは想定されていないのです。しかしデータベースなら軽くこなします。何十万レコード追加していようが、ものともしません。つまり、膨大な量の情報を扱おうとするとデータベース管理一択になります。なお、ここで扱った仕組みは厳密にはリレーショナルデータベース(表と表が紐づいたデータベース)と呼ばれますが、今回は覚えなくて大丈夫です。

進化と引き換えに失ったもの

Markdownから、JSON、データベースへと「進化」させてきました。膨大な量の情報を扱いやすく、サーバーにセットアップして複数人でデータを扱えるという意味では確かに進化です。しかし、失ったものがあります。AIからの距離です。

AIから見るとシンプルな話で、手元の紙に情報があるほうが、棚の奥に丁寧にファイリングされた紙を見るよりも楽に見られる、というだけのことです。Cursor・Claude Code・Codexは、どこで起動するかが重要でした。Cursorなら1つのリポジトリを指定して開きます。するとAIは、そのリポジトリの中の情報を、言われずとも必要に応じて読みに行ってくれます。採用管理ツールなら「佐藤さんはどんな方ですか」と聞けば、佐藤花子.mdを読んで一瞬で答えてくれます。

しかしデータベースに表形式で保存すると、AIの手元に情報がないため、そのままではわかりません。方法がないわけではなく、「候補者の情報はこのデータベースに入っている」「このデータベースにこんなSQLを発行したら情報が取れる」とあらかじめ指示し、権限を与えておけば、AIが棚の奥のファイルを取ってくるようにデータベースを開き、中の情報を取ってきて理解してくれます。ただし、この一手間が加わることで、端的に言うとAIの品質が落ちます。どんなにルールに書いてあっても、手元に広がっている資料に比べたら、棚の奥の資料は遠い場所です。取ってこないで「取ってきたふり」をすることもあれば、取ることに失敗することもあります。

AIがデータを「保存する」観点でも同じです。Markdownでそのまま保存するのと、AIがSQLを考えて実行するのとでは難易度が違います。SQLはプログラムなので1文字でも間違えばエラーになり、JSONを作る以上に重い仕事です。そのため、あくまでベターという前提ですが、講師は「AIに文章のアウトプットをさせるときは、極力Markdownで出力させるべき」と考えています。JSONやSQLを作らせるのは、白い画用紙に最初から緻密な絵を描かせるようなもので、まず下書きから進めたい、という考え方です。

3つの形式の性質を整理すると次の通りです。

データベースは何十万件もの情報から瞬時に情報を取り出せる便利なツールです。しかしAIとの距離は遠くなる。ではどうするか。絶対的な答えはありません。AIにとってベストなデータの保存の仕方は何かを考える——これがすなわちハーネスエンジニアリングです。どのようにデータを保存するかを考えるところから、私たちがたどり着きたい最終到達地点であるハーネスエンジニアリングへの道のりはもう始まっています。だからこそ、Webアプリケーションのデータ保存の仕組みを理解せずに、AIの性能の限界を引き出すハーネスエンジニアリングを実行することは不可能なのです。今回初めてデータの保存という概念に触れた人も、焦る必要はまったくありません。ここが一歩目です。

画像・動画・音声 — 文字以外のデータの保存

ここまではすべて文字データの話でした。Markdown・JSON・データベース、全部文字です。データベースに画像や動画・音声を保存できないわけではありませんが、一般的ではありません。正確には、データベースに入れる意味があまりないのです。

私たちが見るWebサービスは文字だけではありません。採用管理ツールなら、候補者の顔写真、履歴書のPDF、面接の録画・録音など、テキスト以外の情報がたくさんあります。ざっくり理解すると、データは「文字データ」と「それ以外」に分かれます。それ以外のことをバイナリと呼びます(これは覚えなくても大丈夫です)。

AIから見ると、文字のデータと文字以外のデータでは、文字のほうがわかりやすく理解しやすいです。「ものすごい長文よりは画像1枚のほうが理解しやすい」という話も以前ありましたが、基本は文字です。そうでなければ、リポジトリ内の情報もプログラムも全部画像で保存したほうがいい、ということになってしまいます。そんなことはありません。画像や動画・音声は容量を食い、重くて扱いづらいのです。

HTMLの中に書かれているのは、画像そのものではありません。画像が置いてある場所の「住所」が文字で書かれています。Google Chromeの「検証」で画像のHTMLを見ると、それが確認できます。住所を指定しておくと、その住所から画像を読み込んでくれる——これが昔からのHTMLの仕組みです。つまり、1つのWebサイトにたくさんの画像が入っていたら、その画像の数だけ通信が走っているということです。

では、サービスで使うすべての画像をGitリポジトリ内に入れればいいのでしょうか。どこかで限界が来ます。理由は2つあります。

1. Gitは画像の差分管理ができない — Gitは文字の差分管理が得意で、「ここ1行変わったね」と追ってくれます。しかし画像や動画は、ほんの1ピクセル変えただけで丸ごと別ファイルとして認識されます。差分が効かず、ファイル単位でしか変化がわからないため、Gitで管理する意味があまりありません
2. 容量の限界 — 1つのリポジトリ全体で、だいたい1GBが目安です。リポジトリはたくさんの画像を置いておける場所ではありません

したがって、リポジトリに置くのはロゴデータや小さなアイコンのような、軽量なWebアプリケーションのパーツだけにします。Instagramのような画像投稿サービスで、ユーザーが投稿した画像を全部リポジトリ内に保存することは無理なのです。

そこで使うのがストレージ専用サービスです。文字以外の情報を保存しておける場所です。Neonをつないだのと同じ、Vercelダッシュボードのストレージタブにあるマーケットプレイスから、今度はBlobを選びます。これも簡単に連携できます。Neonが文字データを表形式で保存する箱だとすれば、Blobは(たくさんあるストレージサービスのあくまで1つですが)画像・動画・音声という文字以外のデータを保存する箱です。文字以外のデータの扱いは今回は詳しく扱いませんが、「文字のデータとは別で保存するのが普通」と理解できれば十分です。

月次課題 — データを保存できるアプリを公開する

今回の月次課題は、第3章で作った自分用のツールを、データを保存できるWebアプリケーションにしてVercelに公開することです(詳細はポータルで案内されます)。

講義で扱った通り、常にデータベースを使うことが正解ではありません。それでも、データベースを備えたWebアプリケーションを一度は自分で動く状態にしてみないと、自分の中の選択肢に上がることはなく、今回の内容もふわふわとした概念のままいつか忘れてしまいます。

自分で作りながら、どこをデータベースにするか、どこはGitで管理するのか、AIの手元に置くべき情報は何なのかを自分で考える。そこからハーネスエンジニアリングは始まっています。

もっと踏み込んで学びたい人のために、発展課題(任意)も用意されています。自分のWebアプリケーションの中に、AIが動く機能を組み込んでみることです。詳しいやり方ではなく指針がポータルに記載されます。

今回は概念の話が多めの回でした。次の講義では、もう一度全体を端から端まで眺めて解像度を上げていきます。1回の講義ですべての概念を扱えるようになるとは想定されていません。ここはまだスタート地点です。ただし、手元でやってみたかどうかは学びの速さに大きく影響します。ぜひ自分の手を動かしてみてください。

まとめ

• AIとの付き合い方には「頼む」「整えて渡す」「AIが自分の代わりに動く仕掛けを自分で作る」の3段階がある。3段目がハーネスエンジニアリングであり、AIの力を引き出しながら道を外さないようにする仕組みを、人間が主体となって組む技術である
• プロンプトエンジニアリング(2022〜2024)→コンテキストエンジニアリング(2025)→ハーネスエンジニアリング(2026)は別物ではなく積み重なっている
• Quiz Studioでは、機械的チェック・チェックシートに基づくサブエージェントレビュー・批判的ユーザー目線のレビューをフックで自動起動し、合格するまでやり直しを外側から強制している。AIの「やったふり」は項目ごとにOK/NGと理由を出力させて防ぐ
• ハーネスの5つの軸は「データの整理整頓」「データの探し方」「作業中の記憶の設計」「やり方とルールの明文化」「外側からのやり直しの強制」
• 文字データの形式はMarkdown・JSON・データベースの3つ。Markdownは人間用で自由、JSONはプログラム用で厳密、データベースは複数人・大量データ用
• 自分専用ツールにUIやデータベースは必須ではない。Git・Markdown・スキルだけでも立派なツールになり、見づらくなったら「編集はCursor、閲覧はビューアー」のハイブリッドが有効
• 形式を発展させるほどプログラムは扱いやすくなるが、AIからの距離は遠くなり品質が落ちる。AIの文章出力は極力Markdownがベター
• パスワードやAPIキー、データベース接続情報などの「鍵」はプログラムに書かず環境変数に設定する
• 画像・動画・音声(バイナリ)は文字データとは別に、Vercel Blobのようなストレージ専用サービスに保存するのが普通
• AIにとってベストなデータの保存の仕方を考えること自体が、ハーネスエンジニアリングの始まりである

新出用語

• ハーネスエンジニアリング — AIの力を最大限引き出しつつ、道を外さないようにコントロールする仕組みを自分で組む技術。ハーネスは馬の力を引き出しながら暴走を防ぐ装置のこと
• コンテキストエンジニアリング — 「どう聞くか」ではなく「何を見せるか」。AIに渡す資料・規範・履歴を整える技術
• プロンプトエンジニアリング — AIへの指示の言葉を工夫して結果を良くする技術。2022〜2024年頃の主役
• コンテキストウィンドウ — AIが一度に扱える情報量の上限
• アテンション — AIが情報に向けられる注意力。JSONのような厳密な出力はこれを多く消費する
• オートリグレッション — 直前までの出力に引きずられて続きを生成するAIの性質。自己レビューの正当化の原因になる
• サブエージェント — メインのAIとは別に立ち上がる子のAI。並列処理や客観的なレビューに使う
• フック — 特定の段階・タイミングでAIや処理を自動起動させる仕組み
• バリデーション — 入力や成果物が決めた条件を満たしているかをプログラムで検証すること
• パース — Aという形式で書かれた文章をBという形式に変換すること(例: Markdown→HTML)
• JSON — かっこで階層を表現し、キーと値の組でデータをまとめる記述形式。プログラムが扱いやすい
• キー — JSONで各情報の前に付くラベル
• データベース — 複数人で読み書きする、たくさんの表が入った箱。基本的に文字を保存する仕組み
• テーブル — データベースの中の表。名前は複数形にするのが一般的
• レコード — 表の1行分のデータ
• カラム — 表の縦の列。列ごとに入れられる値の種類を厳密に決める
• リレーショナルデータベース — 表と表がIDで紐づいた形式のデータベース
• SQL — データベースを操作するための言語。SELECT(選ぶ)・INSERT(追加)・UPDATE(書き換え)・DELETE(削除)・CREATE(表の作成)など
• Node.js — サーバーの中で動く、JavaScriptで書ける言語。プログラムからSQLを実行する役割を担う
• Postgres — 今一番よく使われているデータベースの形式。迷ったらこれを選べば大体大丈夫
• 環境変数 — パスワードやAPIキーなど、プログラムの中に埋め込んではいけない重要情報を設定しておく場所
• バイナリ — 文字以外のデータ(画像・動画・音声など)の総称
• ストレージ — 文字以外のデータを保存しておける場所・サービス。例: Vercel Blob
• Agent SDK — 自分のアプリケーションの中にAIエージェントを組み込むための開発キット