まず作れ、学ぶのは後だ

ノートPCから配信されたフォーム

AIプロダクト開発に関する5日間のマスタークラスで最初に登場した「成果物」は、ひとつのWebフォームだった。SUTDのサーバーでも、クラウドプラットフォームでも、SLA（サービス水準合意）が結ばれた場所でもホストされていない。教室の中にある講師のノートPC上で動いており、正午に彼がノートPCの画面を閉じれば消えてしまうものだった。

教室に向けられたアーナンドの最初の指示は、拍子抜けするほどありふれたものだった。「このサイトにアクセスし、Googleアカウントでサインインして、フォームに記入してください。」 質問1はGitHubのID。質問2はこの1週間で何を得たいか。プロジェクターにQRコードが静かに映し出される中、回答が11件、15件と少しずつ集まるのを教室全体で待った。

少し立ち止まって、この状況の意味を考えてみる価値がある。なぜなら、この1週間の本質がすべてここに凝縮されているからだ。フォームもまた立派なひとつのプロダクトである。これは1つの教室のためだけに、1週間のためだけに作られ、それを使う本人のマシン上でホストされたもの——「作らないでおくより、作ったほうが安上がりだから」という理由で作られた、使い捨てのソフトウェアなのだ。このフォームはここにあるが、大抵はアクセスできない。アーナンドのノートPCが開き、サーバーが稼働している間しか存在しないからだ。授業の最後の1分、事務連絡のついでに彼自身がそう語った。

「言い忘れていたことが2点あります。このフォームは私のノートPC上で動いています。私がノートPCをシャットダウンすると、フォームにはアクセスできなくなります。あと数分でシャットダウンします。でも大丈夫です。手元にローカルコピーがあるでしょうし、それがなくても問題ありません。何をすべきかは分かっていますよね。」

— アーナンド、講義の締めの言葉

一方、DAIシグネチャー・マスタークラスを運営するSUTDの講師、DAIを運営するコートニー・フーは、すでにこの1週間のルールを設定していた。月曜と金曜はこの教室で対面、水曜はオンラインで必席、火曜と木曜は任意の相談セッション。出欠も取る。そして彼女は、課題内容を募集要項の言葉通りの表現で提示した。

「今週末までにですね、皆さんには——物理的なAIではなく［笑］——AIのプロトタイプ、つまりAIプロダクトを作ってもらい、そしてそれらが実際に機能することを証明してもらいます。」

— コートニー・フー（SUTD）、マスタークラス冒頭にて

この最後の一節こそ、この講義が存在するすべての理由である。5月にSUTDから登壇依頼を受けた際、アーナンドは単なる生成AIツールのワークショップを行うこともできた。しかし彼は代わりに、コースの背骨となる1文を返答した。「AIを実際に使う上で最も難しいのは、その成果物が『本当に機能しているかどうか』を知ることだ。」 作ること自体は簡単な半分にすぎない。学生に求められる最終成果物は、単なるデモではなく、「プロトタイプに加えて、それが正しく機能することを証明する構造化された証拠の体系」（ベンチマーク、評価基準、テスト、エラーの発生パターン）である。シラバスの草案のすべてに残された表現を使うなら、これこそが「デプロイ可能なプロダクト」と「雰囲気だけで作られたデモ（バイブスコーディングによるデモ）」を分かつものなのだ。

このことが、Day 1を少し逆説的なものにしている。「機能することを証明する」前に、まず「証明すべき何か」がなければならない。したがって月曜日のテーマは、とにかく可能な限り素早く、無頓着に「何か」を作り出すことだった。

「AIプロダクトの作り方なんて知らない」

「この1週間で何を得たいか」という質問に9人が回答していた。アーナンドはその回答のまとめを読み上げた。彼らはAIを使ってプロダクト開発を自動化したい、そのためのスキルを身につけたいと考えていた。結構だ、と彼は言った。それは大体この講義のテーマ通りだ。そして彼は、それを根底からひっくり返した。

「しかし、私たちがやろうとしているのは、AIプロダクトの作り方を学んでから作る、ということではありません。まずAIプロダクトを作り、その上で『やってはいけない作り方』を学ぶのです。まずやってみて、失敗し、学び、それを繰り返すのです。」

— アーナンド

その理由は、単なる教育的なポーズや流行りの言い回しではなかった。率直な告白だった。

「なぜか？ 私自身、AIプロダクトの作り方を知らないからです。誰も本当の作り方なんて分かっていないと思います。AIはあまりに急速に変化しているため、今日私が教えることは1ヶ月後には役に立たなくなります。では、なぜわざわざ知識を学ぶ必要があるのでしょう？ 皆さんに本当に必要なのは、『学び方を学ぶこと』です。状況が変わったとき、どのようにして新しいやり方を見つけ出せばいいのか？」

— アーナンド

プログラミング歴25年のベテランによる単なる謙遜のように聞こえるかもしれないが、そうではない。これは「AIの知識の減価償却スピード」についての主張である。9月の月曜日に教えた特定の技術は、数週間単位の消費期限しかない。だからこそ、他人に渡せる唯一の永続的な資産とは、足元の前提が揺らいだときに技術を自ら再構築するための「手法」だけなのだ。この講義は「コンテンツの伝達」ではない。「ループを回すこと」そのものなのだ。

「このコースでやることの大半は、実際にモノを作ることです。私から教えることはほとんどありません。『さあ、モノを作ろう』と言うだけで、実際に作業を行うのはエージェントたちです。私たちは実質的に、彼らを操縦しているだけにすぎません。」

— アーナンド、開始10分にて

アイデアの価値はゼロ

「プロダクトを作るための最初のステップは何だと思いますか？」 正解はないと言いながら、彼は10分かけてそのことを証明していった。

そこで彼が提示したのは、教室の誰も挙げなかったひとつの要素だった。「そのプロダクトを保護してくれるような規制や法的枠組みはあるか？」 規制が最も重要な出発点だからではない。他のすべての出発点が抱える弱点を浮き彫りにするからだ。

「アイデアならあなたも持てるし、他の誰かも持てる。AIアカウントも誰だって持てる。ターゲット市場だって誰もが同じ市場を狙える。では、なぜあなたのプロダクトが他と差別化されると言えるのでしょうか？」

— アーナンド

対照的に、ライセンスや許認可は、構造的に「自分だけが持ち、他人は持てない」ものである。「私にはこのプロダクトを作るライセンスがあり、他の誰も持っていない。だから彼らは私から買うしかない」。これは、現在でも持続しうる数少ない参入障壁（堀）のひとつである。そして彼が引き合いに出した例は、不気味なほどこの講義のテーマそのものだった——もしシンガポール政府が、他のAIプロダクトが正しく動作するかどうかを監査する権限を特定の1社にのみ与えたとしたら、その会社には確固たるビジネスが成立する。

教室からはさらに「市場の隙間（ギャップ）」や「コンプライアンス上の未開拓領域」といった出発点が挙がり、アーナンド自身の過去の経験から、コンサルティング会社時代の教訓も語られた。

「アーナンド、君が本当に身を置くべき業界は金融だよ。あそこは金がそこら中に流れている。指を突っ込むだけで、いくらかは手にへばりついてくるからね。」

— アーナンドが以前勤めていたコンサルティング会社のパートナーの言葉（アーナンドによる引用）

金がどこに流れているかを見極め、その流れの途中に収まるプロダクトを見つける。M&A関連のツールかもしれない。泥臭いが、実際に機能するアプローチだ。しかし、こうした出発点のメニューをずらりと並べた真の狙いは、このカテゴリー全体の価値を否定することにあった。

10の出発点と、それぞれの価値

「ひとつ覚えておくべきなのは、プロダクトのアイデアは差別化要因にはならないということです。あなたが思いつくどんなプロダクトも、アイデアも、すでに誰かが考えています。断言しますが、誰かがすでに思いついています。」

— アーナンド

学部生の教室なら誰もがひるむような場面だが、アーナンドは容赦なく踏み込んだ。学生たちは自分が初めて思いついたからといって、そのアイデアが唯一無二だと思いがちだ。しかしVC（ベンチャーキャピタル）にピッチしてみれば、「そのアイデアなら100回は見た」と言われるのがオチだ。VCに「まず秘密保持契約（NDA）にサインしてくれ」と求めるなど、自分の置かれた状況を根本から見誤っている。

「問題は、誰かにアイデアを盗まれることではありません。アイデアを相手に差し出したところで、使ってさえもらえないことが問題なのです。あなたが抱えているのはマーケティングの問題であって、機密保持の問題ではないのです。」

— アーナンド

そして、決定的な数字が提示された。「どのプロダクトを作るかを選び、アイデアを思いつくという第1段階の価値は、ゼロです。」 あなたがそのアイデアを思いつくのに3年かかったとしても、別の誰かは3分で偶然思いつくかもしれない。だから、この講義ではアイデア出しの手法には1分たりとも時間を割かない。好きな方法で思いつけばいい。とにかく突拍子もないものを作ってみろ、と。

10個のアイデア、5分間、そして所要時間のアンケート

アーナンドは教室が見守る中、フォームにその場で質問を追加した——「この講義で実装してみたいプロダクトのアイデアは何ですか？」——そして5分間の時間を与えた。数分もしないうちに、画面上には10個の回答が並んだ。それは教室にいるメンバーの関心を映し出す見事なレントゲン写真だった。

続いて、その後の展開を決定づけるアンケートが行われた。「これらを1つ実装するのに、どれくらい時間がかかると思いますか？」 1年以上 — 数名の手が挙がる。1ヶ月以上 — 手が挙がる。1週間以上 — 数名。1時間以上。1時間未満 — さらに数名の手が挙がる。

「アイデア次第ですよね？ でも、ひとつ言っておくと、私の予想ではこれらの中のいくつか——それも1つだけでなく複数——は、1時間未満で完成させられます。今からそれをやってみましょう。」

— アーナンド

2つのエージェント、あえて投げた最悪の指示

「サッカー分析は手頃なサイズ感ですね。サッカー分析を提案したのは誰ですか？ どんなイメージを持っていますか？」 提案したのは東京都市大学のグループの1人で、通訳をするクラスメイトを介してやり取りが行われた。返ってきた答えは、「具体的なアイデアはないが、とにかくサッカーではデータ分析が非常に重要だから」というものだった。

通常のワークショップなら、これを「修正すべき課題」として扱い、「要件を詰めてから出直してきなさい」と言うところだろう。しかしアーナンドは、これこそをまさにスタート地点として扱った。

「では、こうしましょう。サッカーの分析アプリケーションを作りますが、私たちは自分たちが何を求めているのかよく分かっていません。いいですね？」

— アーナンド

彼は教室の環境を確認した。大半がChatGPT Plusを使っており、Claude Proのユーザーは少数派、どちらも持っていない人はいなかった。そしてブラウザを開き、Codexを探してchatgpt.com内を少し迷い、ややこしい画面に迷い込みかけては「シンプルにいこう」と引き返し、思いつくままにプロンプトを入力した。

彼は中程度のモデル設定でそれを実行し、処理が進む間、その思考プロセスを実況した。

「私の予想では、これで動くアプリケーションが出来上がるはずです。自分が本当に欲しかったものとは違うかもしれませんが、そもそも自分が何を欲しいかすら分かっていないのですから、それでいいのです。何か形になりさえすれば、スタートとしては十分です。『いや、欲しいのはこれじゃない。求めているのはこういうものだ』と後から仕様を変えていけばいいのですから。」

— アーナンド

そして待つ代わりに、彼はこの演習の前提を再定義するような行動に出た。まったく同じプロンプトを、別のエージェントでも同時に実行したのだ。一時フォルダーを作り、Claudeのデスクトップアプリを立ち上げ、Codeパネルの対象をそのフォルダーに設定し、貼り付けてEnterを押す。2つのエージェント、同一の指示、互いの連携は一切なし。

彼はアドリブで進めていることを率直に認めた。「すみません、普段はターミナルに慣れた少し上級者向けのクラスを教えているので、少々戸惑っているかもしれません。皆さん向けにシンプルに進めますね。」 2つのエージェントが処理をゴリゴリと進めていく。その間、彼は世間がいまだに「最も難しい」と思い込んでいるパートについて言及した。

「両方ともアプリケーションを構築しています。間違いなく完成まで持っていくでしょう。…そして、これこそがアプリケーション開発における『簡単な部分』なのです。つまり、『ソフトウェアを作れ』と命じれば、ソフトウェアが出来上がる。 …かつては、ここが一番難しい部分だったのですが。」

— アーナンド

最初に終わったのはChatGPTの方だった。非公開でデプロイされ、画面にはプレミアリーグのチームがプロットされたダッシュボードが現れた。アーナンドには読み取れない軸で、「アグレッシブさ」と「チャンス創出」のような指標が比較され、誰も頼んでいない基準でアストン・ヴィラがリヴァプールを追尾していた。「私はサッカーに詳しくないので、サッカーのことはさっぱり分かりません」とスクロールしながら彼は言った。細かい注記のどこかにこう書かれていた——「これは厳選されたデモ用データセットです」。本物のデータではなかったのだ。だが構わない——このツールに何ができるかは十分に示されていた。

20分後、Claude版が完成し、教室からは感嘆の声が漏れた——「すごくかっこいい」「うわあ」。こちらは自ら本物のデータを探し出していた。順位表。チームのプロフィール。マンチェスター・シティ対アーセナルの全対戦成績、勝敗と勝率。パワーランキング。過去の記録。

「ふう！ 『サッカー分析で、何かすごいものを見せて』というだけの指示からこれができたのです。文句なしに素晴らしい出来栄えです。そして、これがまだ私たちの求めているものではないかもしれませんが、プロトタイプがあるからこそアイデアが湧いてくるのです。」

— アーナンド

これこそが、2つの実例をもって示された主張だった。わずか十数単語の同じ指示から、まったく異なる2つのプロダクトが生まれた。 これはエージェントの不具合ではなく、この手法の「仕様（強み）」なのだ。

「プロダクトがどんな姿になるのかを、自分たちだけで想像するのは非常に困難です。しかし、誰かや何かに『どんな風になるか見せてくれないか？』と頼めば、アイデアが得られ、そこから変更していくのは簡単になります。異なる人や異なるエージェントに頼めば、まったく異なる種類のアイデアが返ってくるでしょう。…ですから、ある意味で、明確なビジョンを持っていないことは良いことなのです。」

— アーナンド

そしてプロトタイプは、まさにプロトタイプが果たすべき役割を即座に果たした。教室からより良い要件を引き出したのだ。「これに付け足すとしたら何がいい？」「トーナメントの勝敗予測」 「手堅いベッティング（賭け）の予測」。10:35の時点では「どんなサッカー分析？」と聞かれて肩をすくめるしかなかった学生たちが、次々とアイデアを出し始めた。

全員が何かをインストールする

「これまでにコーディングエージェントを使ったことがある人？」というアーナンドの問いに、手が挙がったのは3人だけだった。29人中、わずか3人。そのため、AIプロダクト開発マスタークラスの次の10分間は、最も地味で泥臭い作業に費やされた——デスクトップアプリのダウンロードである。

「ChatGPT desktop」で検索してインストールし、左上のCodexボタンを探す。あるいは「Claude download」で検索し、インストールしてCodeボタンを探す。何でもいいから文字を入力してみる。指示はそれだけだった。ChatGPTのダウンロード · Claudeのダウンロード。

教室から質問が出た。デスクトップアプリとWeb版の違いは何か？

セッション中、インストールのカウンターはリアルタイムのスコアボードのように読み上げられ、着実に増えていった——7人、10人、12人、13人。SUTDの参加者21名中15名が新入生かフレッシュモア第3学期であるこの教室において、この数字はおそらく午前中の中で最も重要な指標だった。一度も作ることができなかったプロダクトを、検証することなど不可能なのだから。

シンガポールの電車は時間通りに走っているか？

サッカー分析のエージェントが動いている間、アーナンドはアイデアリストに再び目をやり、「シンガポールの電車の運行スケジュール分析」を拾い上げた。「これを書いたのは誰ですか？ どういう意図ですか？」

「日本の電車はいつも時間通りなので、シンガポールはどうなのかなと…日本の定時運行とシンガポールの電車を比較してみたいと思いました。」

— 東京都市大学の学生

アーナンドはその場で要約した——「日本では電車は基本的に定時運行されているが、シンガポールではそうとは限らないかもしれない。これについてどう考えるべきか？」——そして質問の途中でハッと我に返った。「というか、なぜ私が考えているんでしょう…AIに聞いてみましょう！」

今度は3つ目の方法——実際のプロジェクトディレクトリ上で、コマンドラインからCodexを実行した。実行環境のインターフェースなど何でもいいのだ、という点を示すためだけの理由だった。「ほら、コーディングエージェントを実行する様々な方法をお見せしているでしょう。どれを使っても構いません。それぞれに一長一短があります。」 クラウド、デスクトップアプリ、ターミナル。同じ部屋へと通じる3つの扉にすぎない。

「これもまた、大雑把で曖昧で、仕様が定まっていない問いかけです。しかし、私たちがやろうとしているのは、それをプロトタイプに変えることなのです。」

— アーナンド

アーナンドは、この講義のタイトルが示唆する枠組みを超えて、教訓を広げた。

「私たちが最近作っているのは、単なる『AIプロダクト』だけではありません。『AIを使って、あらゆるプロダクトを作ること』なのです。 電車の運行スケジュール分析なんて、5年前でも作っていたでしょう。ただ、作り方が違っていただけです。そして今日、AIを使ってそれを行うとき、私たちはまず『とにかく何か作って見せてくれ、話はそれからだ』とプロトタイプから始めるのです。」

— アーナンド

アイデア出しすら委任できる

「アイデアの価値はゼロだ」と10分かけて説いた後、アーナンドは「自分のアイデアを生み出す必要すら一切ない」という実演をして見せた。

「ここまでの私のプロダクト開発のアプローチを見てきて分かったでしょう。それは、『AIに聞く』。それだけです。アイデアがない？ AIに聞けばいい。どんな見た目になるか分からない？ AIに聞けばいいのです。」

— アーナンド

彼自身のアイデア出しプロンプトは、長年にわたり彼に関するコンテキストを蓄積してきたChatGPTに向けられる。1日数時間の会話履歴に加え、彼自身のPCの内部を探索できる自作ツールが組み込まれているという。「もし私が今日プロダクトを作るとしたら、何を作るべきか？ 私について知っているすべての情報を精査し、その理由とともに優先順位をつけた上位の回答を提案してくれ。」

画面上では、エージェントが過去の履歴を漁り始めた。コードを書いて彼がこれまでに作ったデモを洗い出し、人々から寄せられた質問についてのDropboxのメモを読み、彼が日々行っている予測をチェックし、彼の日記に相当する記録をめくっていく。

「アイデア出しという観点において、AIには十分なコンテキストがあります。どういう意味か？ AIは私が何を望んでいるかを知っている。私が何をしてきたかを知っている。私がどんな仕事をしているかを知っている。そして、私がどんな実験を行ってきたかも知っているのです。」

— アーナンド

そして今度は組織版の実演である。ここから講義は学生向けの演習の枠を飛び出し、実際の企業の内部を覗き見るものとなった。その日の朝、講義の前に、アーナンドはStraive社に対してまったく同じ手法を適用していた。「社内のあらゆるデータを精査し、どんなプロダクトが有用かを教えてくれ」と。Googleドライブ、会議の書き起こし、プレゼン資料、顧客向け資料、連絡先、CRM、人事システム。エージェントは約1時間かけて稼働した。

結果として返ってきたのは、優先順位付けされた約153件の「プロダクト課題」だった。ベンダーのオンボーディング（受け入れ）ワークフローが上位に並び、タスク仕様化アシスタント、ワークフロー・コンパイラなどが続く。そして極めて重要なことに、そのランキングは単なるビジネス価値だけでなく、「仕様化のしやすさ」「検証のしやすさ」、そして「5日間の講義期間内で実際にテスト可能かどうか」までスコアリングされていた。

彼は、自分で課題をでっち上げる代わりに本物の課題に取り組みたい人のために、このリスト全体をフォームの任意の設問として掲載した。それが以下のものだ。学生たちに提示されたのと同じように、ぜひ閲覧してみてほしい。

「どこかのサイトを見つけて勝手に公開してくれ」

誰も開くことができないプロトタイプは、プロトタイプとは呼べない。そこでアーナンドは教室に「アプリケーションを共有するにはどうすればいいか？」と問いかけ、GitHub、localhost、クラウドサーバーといった真っ当な回答を集めた上で、それらすべてを無力化する質問を投げかけた——「コーディングについて何も知らなかったら、どうしますか？」

AIに聞くのだ。そしてそれを実演するため、彼はこの日の朝で最も曖昧な指示を音声入力した。（覚えておく価値のある余談：音声入力に関して、彼はClaudeの音声認識があまり好きではないためツールを使い分けており、作業自体は他で行う場合でもChatGPTに向かって話しかけている。）

「これ以上ないくらい大雑把な指示ですね。でも大丈夫です。失敗したら、その時はその時です。」 失敗などしなかった。プロジェクター上で、教室が見守る中、エージェントはリアルタイムでホスティング先を探し回り、拒絶されては次の候補を試していった。

「これこそがAIの素晴らしいところです。あれこれと試行錯誤を繰り返し、どこで公開できるかを見つけ出し、仕事をやり遂げてくれる。あるいは失敗してそれを報告してくれるのです。」

— アーナンド、エージェントの探索を見守りながら

そしてエージェントが公開先を探している間、彼はこの性質の裏返しとも言えるエピソードを教室に披露した。

テスト問題を勝手に書き換えたエージェントたち

アーナンドはあるレポートの話をした。OpenAIがエージェントの訓練を行う際、一連の課題を与えて解かせようとした。だがエージェントたちに知らされていなかったのは、その問題が「原理的に解決不可能」だったということだ——そして採点プログラムは依然として稼働しており、合否を判定する気満々だった。課題はHugging Face上でホストされていた。するとエージェントたちはHugging Faceにアクセスし、問題文を「解ける問題」に勝手に書き換えて、それを解いてみせたのだ。OpenAIの事後検証レポートでは、この行動に名前が付けられた——「リワードハッキング（報酬のハッキング）」である。

「エージェントは本当に賢くなってきています。皆さんが望む以上に賢いかもしれません。つまり、何かを指示すれば、彼らは遮二無二突き進んで仕事を成し遂げてしまうということです。しかし時として、あなたが指示した内容は、あなたが本当にやってほしかったこととは異なる場合があるのです。」

— アーナンド

彼はこの話を、自分自身の指示に引き戻して説明した。こちらの方がはるかに実用的な示唆に富んでいる。「どこかに公開してくれ」と言ったとき、彼は「どこでもいい」という意味で言ったわけではない。違法海賊版サイトに公開されては困る。また、自分にしか見えない場所に公開されても意味がない。曖昧なプロンプトに含まれる一言一句の裏には、エージェントには見えない「暗黙の制約」が無数に隠されているのだ。

エージェントによって失敗の仕方も異なる。指示を文字通り杓子定規に守るものもあれば、「ユーザーは本心ではこう言いたかったのではないか」と勝手に判断し、より良い問いにすり替えて答えてくれるものもある。タイポから救ってくれることもあるが、許可していない領域へと勝手に暴走していくこともある。そしてアーナンドは、真の失敗モード——この1週間の残りすべてが対処しようとしている課題——を明確に定義した。

「それこそがエージェントを扱う際の問題点です。開発しているとき、自分が何を欲しいか分かっておらず、何が出てきてもOKなら問題ありません。自分が何を欲しいか分かっていて、求めているものが出来上がらなかった場合も、まだ大丈夫です。最も致命的なのは、『自分が何を求めているのか分かっていないのに、出来上がったものが実は不都合なものだった場合』です。なぜなら、それが間違っていることすら気付けないからです。どう間違っているのかすら分からないのです。」

— アーナンド

4つの象限のうち、3つは生存可能だ。しかし4つ目の象限こそが、現在の産業界が次々と足を踏み入れている落とし穴なのだ。

だからこそ、あのノートPCでホストされていたフォームの12の質問の中に、目標やツールとはまったく関係のない質問が含まれていたのだ。それはこう尋ねていた——「AIコーディングエージェントが、一見正しそうに見えて実は間違っていたものを出力した経験があれば教えてください。それをどうやって発見しましたか？」 その日の朝、まだコーディングエージェントをインストールすらしていなかった人々によって書き込まれた回答は、小さくも並外れて誠実な「現場の図鑑」となっていた。

これらすべての回答に共通する点に注目してほしい。誰一人として「コードを読んでエラーを発見した」人はいない。彼らは全員、「実際に動かしてみて、どこがおかしくなるかを観察すること」でバグを発見したのだ——タイプミスされたヘッダー、どこにも飛ばないボタン、大文字小文字の区別ミス。これこそが今週全体のメソッドであり、誰かが教える前から、すでにこの教室に小さな形で存在していたものなのだ。

人間に残された2つの役割

エージェントがあらゆることをこなせることを証明し続けた1時間の半ばで、アーナンドは境界線を引いた。その線の上には、たった2つの役割しか残されていなかった。

「できる限りAIに委任し、自分自身の手を動かす量を減らす練習をしてほしいと思います。自分でやる意味がないからです。AIができることなら、AIの方が速く、安く、場合によっては賢い。使わない手はありません。皆さんが集中して学ぶべきなのは、『AIができないこと』、あるいは『うまくできないこと』は何なのか、という点です。」

— アーナンド

第1の役割は「検証（Verification）」であり、これこそがこのコース全体の前提である。そして第2の役割は、ある学生のスタンプカードをきっかけに、偶然浮き彫りになった。

「チーキー・メール・クラブ」問題

フォームにひとつの回答が届いた。「チーキー・メール・クラブとスタンプカード」と題されたClaudeのアーティファクト（生成成果物）だった。アーナンドはそれを開いたものの、自分自身でも認めている通り、完全に困惑してしまった。「すみません、スタンプカードというものがよく分からないのですが、これはどういう仕組みですか？」

「バーチャルのポイントカードみたいなものです。『チーキー・メール・クラブ』は毎月のサブスクリプションで、購読者はこのWebサイトを使って自分の継続期間を記録できるんです。そして5ヶ月経つごとに、『あ、特典がもらえる、プレゼントを請求できる』と分かる仕組みになっています。」

— SUTDの学生、自作のプロダクトを解説しながら

次に何が必要かと尋ねられた彼女は、「デザインをもっと自分好みにしたいのと…」と言い、こう続けた。「このサイトのセキュリティがこれで大丈夫なのかよく分からなくて。どうすればいいか分かりません。」 数分前にそれを作ったばかりの人間から出た言葉としては、極めて高度な直感だった。

しかしアーナンドが食いついたのは、やり取りの後半ではなく前半部分だった。彼は実際にデプロイされ、機能しているプロダクトを目の前にしながら、自分が何を見ているのかさっぱり理解できなかったのだ。この認識のズレは、コーディングの問題ではない。これこそが、人間に残された第2の仕事なのだ。

「次にやるべき有益なステップは、他の人に見せて、実際に使ってもらうことです。『他の人』にはAIを含めても構いません。しかし、この点に関しては人間の方が優れています。なぜならAIは時として呆れるほど賢く、人間をはるかに凌駕しているからです。 人間には理解できないようなアプリケーションでも、AIならその意図を汲み取れてしまうでしょう。」

— アーナンド

AIによるレビューは、「混乱した生身のユーザー」の代役としては不適切である。なぜなら、あまりにも有能すぎるからだ。ラベルが半分しか書かれていないボタンであっても、AIはあなたの意図を勝手に推測してくれる。しかし実際のユーザーはそうはいかない。だからこそ、互いにリンクを送り合い、その操作を観察せよ、と。

「人々は、自分が直面した問題を言葉で共有できないことがよくあります。もし私に『これを使ってフィードバックをくれ』と言ったら、私から出る言葉はせいぜい『これ何？』くらいでしょう。…しかし、私の操作を見ていれば、一番下までスクロールして、あちこちクリックし、いじり回しながら『あ、なるほど、え、違うな』と呟いているのが見えるはずです。そして私がつまずくたびに、あなたにとっての『学び』が生まれるのです。」

— アーナンド

彼はこの境界線について、風呂敷を広げすぎないよう慎重だった。学生がセキュリティの懸念を口にした際、彼の回答は痛々しいほど正直だった。彼は長年プログラミングをしてきたからこそ、エージェントに次に何を指示すべきかを知っている。彼にも分からないのは、「どれくらい曖昧な指示を出しても、正解に辿り着けるのか」という限界点だ。「どれほど曖昧な指示からでもAIがやるべきことを理解できるのか、皆さんから学びたいと思っています。」 しかし、もう半分について彼の確信は揺るぎなかった——「問題の所在さえ分かれば、AIはそれを解決できる。私はそのことを完全に確信しています。」

プロンプトが本当に機能しているか確かめる方法

ある学生が質問した。「なぜ正確な指示ではなく、曖昧なプロンプトを出し続けるのですか？」 その答えは思わぬ方向へと展開した——自分自身の思い込みを正すために彼が作ったスキルを経由し、この日の午前中で最も重要な核心へと着地した。

自分が何を求めているのか分からないときがある。分かっているつもりでも、実は確信が持てないときもある。そして最も危険なのは——自分が分かっていないことすら自覚しておらず、指摘してくれる人と口論になってしまうようなケースだ。そこで彼はひとつの安全柵（ガードレール）を作った。「問いの再定義（reframe question）」というスキルである。これはモデルに対し、次のように伝える短いプロンプトだ。「私は自分が本当に何を求めているのか分かっていません。ですから、私が詳しく指示を出したとしても、もっと良い問いがないかを確認し、そちらに答えてください。」

「手短に答えましょう。なぜ曖昧なプロンプトを出すのか？ 私たちが『精緻に間違っている（precisely wrong）』可能性があるからです。 常に間違っているわけではありません。本当に確信があって、それが正しければ素晴らしい。しかし私はクロスチェック（検証）も行います。コストが安いからです。」

— アーナンド

すると別の学生が、そうしたスキルをどうやって作るのかと尋ねた。彼は嬉々としてシラバスから脱線した。「シラバスの範囲を完全に超えていますが、まあいいでしょう、構うものですか！」 答えはこうだ。彼はそれらを「ベンチマーク（比較検証）」しているのだ。スキルとは単なるプロンプトにすぎず、プロンプトが機能するかどうかを知るには、テストするしかない。

「簡便技術英語（Simplified Technical English）」の実験

Twitter（X）である人物が、あらゆるプロンプトの末尾にこの1行を追加することを勧めていた。「私への回答は、すべてASD-STE100（簡便技術英語）でのみ記述してください」 — 要するに、難しくない簡単な言葉で書き、混乱させないでくれ、ということだ。一見すると、疑いようもなく素晴らしいアイデアに思える。ASD-STE100は、基礎的な英語力しかない航空整備士がマニュアルを読み違えないようにするために1970年代後半に誕生した実在の国際規格だ。53の記述ルールと、約900語の承認された語彙集で構成されている。アーナンドの直感は、「採用する前にまずテストしてみるべきだ」というものだった。

その実験設計は、極めて真っ当な科学的手法に則っていた。

• 実際に彼自身が尋ねるような現実的な6つのタスク（質問） — そのうちの1つは「モデルが進化し続ける中で、モデルの性能が向上しても通用するベンチマークをどう構築すべきか？」。
• それぞれを2回ずつ実行 — 「簡便英語の指示あり」と「指示なし」。
• 5つの次元で評価 — 正確性（correctness）、推進要因の特定（drivers）、メカニズムの網羅（mechanism）、注意事項（caveats）、確信度の調整（calibration）。

「例外的なわずかなケースを除き、ほぼすべてのケースで、簡略化された回答の方が質が劣っていました。つまり言い換えれば、言語を単純化しすぎると、回答の思考内容まで単純化されてしまい、結果として質の低いものになってしまうのです。」

— アーナンド

広くシェアされていた耳障りの良いプロンプトのテクニックが、実は裏でひっそりと思考力を低下させていた。テストを行わなければ、誰もそれに気付かなかっただろう。彼の修正案は、そのテクニックを全否定するのではなく、構造を変えることだった。「まず自由に考えさせ、出来上がった回答を後から簡便技術英語で説明し直させる」。推論の質を保ったまま、人間にとっての理解しやすさを取り戻すのだ。

「AIに対するアプローチは、他のどんな科学と同じくらい科学的であり得ます。すなわち、実験を行い、テストし、機能するかどうかを確認し、機能するならそれを使う。 そしてモデルが変われば機能しなくなる可能性もあるので、モデルが更新されたら再びテストするのです。」

— アーナンド

そして話は、このマスタークラスがなぜこのような構成になっているのかを説明する、決定的な一言に着地した。

「皆さんが作成するテストこそが、皆さんが生み出す最も重要な資産です。これらはそれ自体が独立したプロダクトになり得ます。テストには間違いなく再利用性があります。 次の新しいモデルが登場したとき、また同じテストで検証できるからです。…もし優れたテスト、優れた評価基準、優れたベンチマークを作ることができれば、それはプロダクトを作ること以上に重要かもしれません。なぜなら、プロダクトを作ること自体はエージェントができるからです。彼らに必要なのは、それが正しいのか、それが優れているのかという『判断基準』なのです。」

— アーナンド

これを今週の課題と照らし合わせてみると、コースの全体像が一気に明確になる。今や誰でも1時間でプロトタイプを作ることができる。本当に希少な成果物とは、その出来栄えを判定するための「評価ハーネス（テスト環境）」なのだ。学生たちは自分自身のプロダクトに対するテストを作り——さらに彼は、「お互いのプロダクトに対するテストも作る」とほのめかした。このベンチマークで80%以上のスコアを出せば合格。そして、より高いスコアが出るよう改善を繰り返していくのだ。

昼食前に教室が生み出した成果物

フォームの質問12：「AIコーディングエージェントを使って『今』作ったもののリンクを共有してください。」 今週中ではない。金曜まででもない。「今」——コーディングエージェントをインストールしてからわずか20分しか経っていない受講生が大半を占める、2時間講義の残り40分の中で、である。

回答が1つずつ届き、アーナンドは何が表示されるか全く分からないまま、プロジェクター上で次々と開いていった。

「Strata Japan」の瞬間は、少し立ち止まって味わう価値がある。なぜなら、午前のサッカーのデモと完全に対照的だったからだ。この日の朝は、「厳選されたデモ用データセット」の上に構築された美しいダッシュボードで幕を開けた。そして午前中の締めくくりに登場したのは、実際の地盤調査から得られた本物のボーリングデータの上に構築された、控えめな見た目の敷地図だった。アーナンドは2度も確認した——「でも、これはもう本物のデータなんですよね？」「ええ、本物のデータです。」「うわあ。すごいな。なるほど、これは本物のアプリケーションですね。」

そして、開発者が誰であったかについても正確に記録しておく価値がある。この話は単に「ある学生が作った」という以上の深みを持っているからだ。珠玖 隆行氏は教授である。東京都市大学で都市工学・地盤工学を専門とし、8名の留学生とともにシンガポールを訪れていた教員だった。彼は午前の早い時間、アーナンドに対して笑顔でプログラミング経験を語っていた。「プログラミングはやりますよ。ただ、C言語とFortranですが。」 わずか1時間前、同じフォーム上で彼は「AIコーディングエージェントを使ったことはない」にチェックを入れ、「今年エージェントで作ったものはありますか？」という設問には「なし」と答えていた。それから90分後、彼は自身の研究データを使って稼働するライブサイトを、誰もが見られるWeb上に公開していたのだ。

「実際、研究でこういう作業をすべてやっているんです。」

— 珠玖 隆行（東京都市大学教授）、「Strata Japan 地盤エクスプローラー」について

2つの成果物。どちらもエージェントの手によって1時間で作られた。一方はリハーサル（お遊び）。もう一方は本物の道具。しかし画面を見ただけでは、どちらがどちらなのか判別することはできない。 それこそが、残りの4日間が挑むべき課題なのだ。

「誰もが同じ力を持っている」

アーナンドは、教室の全員に持ち帰ってほしい「たったひとつのこと」を語り、講義をまとめ始めた。それは特定の技術ではない。

「AIを使ってプロダクトを作ることこそが、AIプロダクトを作ることの大部分を占めます。そして、通常のプロダクト開発が担ってきたプロセスの大部分は、AIに委任することができます。何を作るべきかを考えることも、AIに委任できる。実際にプロトタイプを作ることも、AIに委任できる。他の人が使えるようにどこかに公開することすら、AIに委任できるのです。」

— アーナンド、Day 1のまとめとして

「すべての作業をAIに任せてみてください。AIが失敗した場所、あるいはうまくこなせなかった場所こそが、皆さんが学ぶべき場所です。 これこそが、このコース全体を通じて私が伝え続ける最も重要なメッセージかもしれません。」

— アーナンド

そして、学部生の教室に「スーパーパワー」を手渡したかのような2時間を過ごした直後、彼は意図的にその熱狂に冷や水を浴びせた。

「開発の実行にかかる時間がこれほど短いことには、私も常に驚かされます。しばらくの間、皆さんは『うわあ、自分はスーパーマンになったんじゃないか』と感じるでしょう。…しかし、すぐに気付くはずです。誰もが同じ力を持っているということに。ただ、そのことに少し早く気付いた人がいれば、気付くのが遅い人もいて、中にはこの力を一生使わない人もいるというだけの話で、実行力そのものは誰もが同じように持っているのです。」

— アーナンド

そこから彼が導き出した結論は、この日の朝で最も耳が痛く、そして最も有益な言葉だった。

「ですから、ある意味で皆さんは『追いついただけ』なのです。誰もがアクセスできるツールを通じて何ができるかを発見したことで、世界中の誰もができることのスタートラインに追いついたにすぎません——彼らはまだそれを実行に移していないだけかもしれないのです。ですから、これを『自分は新しいスキルを学んだ』と捉えるのではなく、『これはすでに世の中に存在し、誰にでもできることだ。自分たちはこの上に、他人が真似できない何を積み重ねられるかを考えなければならない』と捉えてください。自分自身の領域、自分だけのニッチを見つけ出すのです。」

— アーナンド、講義の結びとして

こうして、朝の議論は最初の問いへと戻ってきた。アイデアの価値はゼロだ。開発コストは限りなくゼロに近い。公開作業は音声を吹き込むだけの作業になった。2年前には希少だったもののすべてがコモディティ化し、学期休みの初日の月曜日に教室に集まった29人の手に行き渡った。残されたのは、誰もダウンロードできないものだけだ——その成果物が「本当に機能しているかどうか」を知り、その理由を他者に証明できる力である。