# 文字起こし **アナンド**: [00:18] それでは始めましょうか。始めても大丈夫ですか？ よし。まず、提出・共有してくれてありがとうございます。皆さんの大半がチャットログのリンクや、学びをまとめた動画、プロダクトの紹介動画を提出できたようですね。これらについては後ほど詳しく見ていきます。本日行うのは、これまでの学びの総括と、プロダクトを継続的に改善し続けるためには何が必要かを考えることです。まずは、これまでに私たちがやってきたことの振り返りから始めましょう。 **アナンド**: [01:13] **私が皆さんにお見せしてきたプロセスは、Straiveでプロダクト開発に使っている「StraiveX」手法とおおよそ同じものです。** 新しいプロダクト開発の進め方は、従来のやり方とは少し異なっています。かつては「プロスペクティング（見込み調査）」を行っていました。つまり、質問を投げかけて探るということです。しかし今では、質問をする必要すらありません。手元にあるデータをスキャンするだけで、どんなプロダクトを作るべきか、どんなユースケースが求められているのかを自動的に把握できるからです。今回の授業では、スキャンできるデータ自体があまり多くありませんでしたが、皆さんがやったのは自身の経験や直感を掘り起こす（マイニングする）ことでした。ただ覚えているかもしれませんが、初回のセッションで、Straiveが開発候補としている約150個のプロダクトのリストをお見せしましたよね。あれは私のPCやGoogleドライブなどにあったすべてのデータをスキャンして導き出したものです。これが第一歩、つまり「どうやってニーズを特定・発見するか」という部分です。 **アナンド**: [02:37] 次のステップについてですが、以前はソリューションを「提案」するのが普通でした。「3ヶ月、3年、あるいは3週間でこのプロダクトを作れます」などと誰かに持ちかけるわけです。**ですが今や、それが3時間にまで短縮されました。そのため、わざわざ提案書を書く必要はなく、いきなり実際に形にして作り上げればいいのです。** 途中で承認を得るような中間ステップは不要です。実際、皆さんも1つのプロダクトにとどまらず複数のソリューションを作り、途中で変更を加えたりしていましたよね。 **アナンド**: [03:19] かつて第3のステップだったのは、クライアントと綿密に対話を重ねながら進めるフォーマルな開発プロセスでした。しかし皆さんはそれを逆転させました。まず作ってから何人かに見せ、「どう思いますか？ フィードバックをください」と尋ねたわけです。これが「検証（バリデーション）フェーズ」にあたり、皆さんはこれも完了しました。そして以前であれば、完成したソリューションをクライアントに納品していました。**しかし現在では、そのまま直接デプロイ（公開）してスケールさせます。** 皆さんも、「プロダクトの機能を説明する動画を作れないか？」「Webページに公開して他の人に使ってもらえないか？」といった方法を試していましたね。この段階でAIを活用する他の方法についても、後ほどもう少し掘り下げていきます。 **アナンド**: [04:22] **本日のメインテーマは、主に「運用と進化（Run and Evolve）」フェーズについてです。かつてプロダクトは手作業で保守されていました。**「問題なく動いていますか？ バグはありませんか？ 新しい機能は必要ですか？」と人に直接確認していたのです。しかし現在では、エージェントがユーザーの利用状況や、何がうまくいっていて何がうまくいっていないかを自動で監視し、それをもとに次世代のプロダクトを構築・進化させることができます。そしてこのサイクルは反復的（イテレーティブ）に回ります。つまり、進化したバージョンができれば、そのデータを活用して新しいプロダクトや新機能が必要かを感知（センシング）し、再びイテレーションを始められるのです。ですからプロダクト開発は1サイクルで終わるものではなく、常に回し続けるものです。AIのおかげでスピードが劇的に上がりましたし、おそらく、より簡単になったとも言えます。従来とはやり方が違うので戸惑うかもしれませんが、結果として現在のプロダクト開発サイクルは格段にやりやすくなっています。 **アナンド**: [05:51] これがサイクルの大枠です。しかし、このプロセスの副産物として生み出される非常に重要なものがあります。それが「資産（アセット）」です。何らかの作業を行い、そこから得た学びを次回自分たちが再利用したり、他の人が再利用したりできるということです。皆さんが行った作業の中で、再利用できるものには何があるでしょうか？ たとえば、ユーザーがアプリをどのように使っているかの利用ログを取り始めたことなどが挙げられます。これは次回、自分や他の誰かが次のバージョンを開発する際に、エラーを最小限に抑えるのに役立ちます。あるいは、皆さんがプロンプトを入力した際のセッションログもそうです。そこからお互いに集合知として学び合い、セッションログを活用するためのベストプラクティスを見つけ出すことができます。 **アナンド**: [07:11] 実際にやってみましょう。今から行うのは「資産化（アセット作成）」のプロセスです。ちょっと確認させてください……よし、これらのセッション……先ほどセッションログのダウンロードを始めたのですが、何かがおかしいですね、クリックできないな……よし。皆さんそれぞれの……あれ、チャットログがまだ作成されていませんね。ダウンロード中のようです。誰かのチャットログはもうダウンロードできましたか？ まだですね。わかりました、手動でやりましょう。ここに共有されたチャットログがあります。読み込みに少し時間がかかっていますね。Claudeのチャットログを読み込んでみましょう。おや、これはチャットログではないかもしれません……3ページの投稿かな？ リンクが違うのかもしれませんね。次を見てみましょう。はい、これはチャットログのようですね。まさにチャットログです。チャット履歴のコピーですね。これと、これと、これを開いてみましょう。リンクがいくつかありますね。これは開けそうです。チャットリンクが2つあります。 **アナンド**: [08:48] よし、それではこうしましょう。これらのチャットから学びを抽出する演習を始めます。次のように進めたいと思います。先ほどのスプレッドシートには、皆さんがアプリ作成に使ったチャットログの列があります。**うまく機能したプロンプトのパターンにはどんなものがあるでしょうか？ 逆に、あまりうまくいかなかったパターンは何でしょうか？** そして、それらのプロンプトの有効性や、エージェントがそれをどう解釈し実行したかから、私たちは何を学べるでしょうか？ **アナンド**: [09:40] **皆さんにやってほしいのは、「メタプロンプト」として使える、優先度の高い教訓トップ5を作ることです。** つまり、新しいアプリを作り始める前にそのままコピペできる、最大5つの優先ルールを含んだプロンプトを作りたいのです。それを使えば、今回の開発プロセスで生じたような失敗を自動的に回避でき、あるいはチャットログ全体で見られたベストプラクティスを自動的に活用できるようになります。**エージェントや人間がすでに当たり前に知っているようなことは書かないでください。「普通とは違う、特筆すべきユニークな点」を盛り込んでほしいのです。** まさにそこを洗い出してほしいと思っています。 **アナンド**: [10:31] ローカルMCPを自由に使ってください。私のブラウザのタブにすでに開いてあるので、必要ならブラウザのタブを調べて結果を取得できます。今回の場合、私のシステム（特にブラウザ）へのアクセス権限を与えてあるので、ChatGPTに直接アクセスできない場合でもタブの情報を拾えるはずです。さて、お気づきかと思いますが、私が求めているのは「他のプロンプトに追加して使えるもの」です。**これは一般的に「スキル（Skill）」と呼ばれています。** ここを少し修正して……よし、これで実行させましょう。30分ほどかかるかもしれませんが、このまま走らせておきます。 **アナンド**: [11:34] 他のプロンプトと組み合わせて使えるプロンプトを求めているので、これをそのまま機械的に適用できます。チーム全体に「これは皆が見落としがちな5つのミスやベストプラクティスだから、常にプロンプトに付け加えてね」と渡すだけで、少なくともそのパターンのミスは起きなくなります。これは私たちが作成できる資産（アセット）の一例であり、私はこれを「スキル」と呼んでいます。自動的に追加できるものであり、プログラムにスキルを自動的に組み込む方法も存在します。 **アナンド**: [12:15] もう一つの種類は「フック（Hook）」です。フックとは、たとえば「新機能を要求するたびに、必ずテストケースを書くこと」と指示するようなものです。いや、それはあまり良い例ではないかもしれませんね。「必ずGitHubリポジトリにコミットすること」が良い例でしょう。そうすれば、コードは常にバージョン管理されます。**スキルとフックの違いは、スキルが「こうしてほしい」と指示して99%の確率で実行されるものであるのに対し、フックは開発プロセスにおいて「これを絶対に実行しなければならない」とプログラム的に強制し、確実に実行させる点です。ミスは起きません。** フックについては今は詳しく心配しなくて大丈夫です。かなり詳細な話になりますから。 **アナンド**: [13:09] ただ覚えておいてほしいのは、プロダクトを完成させること自体は演習の一部に過ぎないということです。むしろそこが出発点と言えます。本来目指すべきは、そこに到達した後に、何度も繰り返し再利用できる資産（アセット）をできる限りそこから引き出すことです。ご覧の通り、エージェントが私のブラウザを巡回しています。しばらくブラウザは使えない状態になりますが、いずれにせよ、やりたかったことの第1パートはカバーできました。 **アナンド**: [13:46] **では、これを踏まえて皆さんは何をすべきでしょうか？ 自分自身のチャットを分析することです。** CodexやClaude、ChatGPTなどの履歴を見直して、「自分がうまくできている点と、うまくできていない点は何か」をAIに分析させてみてください。また、自分がどうだったかだけでなく、「私が言ったことに対して、AIであるあなたがうまくできたこと・できなかったことは何か？ これらの問題が二度と起きないようにするためにできることはあるか？」とも聞いてみてください。**「私が指示しなくても、同じ問題が再発しない仕組みを考え出せるか？」**と問いかけることは、自己改善や進化（Evolve）プロセスの一環として実践できます。これこそがまさに「運用と進化（Run and Evolve）」です。 **アナンド**: [14:36] 次に進めたいのは、この演習で私たちがどれだけうまくできたか、つまり実質的なこのコースの「評価（Evaluation）」についてです。そして皆さんにも、この評価に対して意見を言う権利があります。これを行うために、これまでと同じプロセスを使います。システムにこのコースでカバーした内容を確認させ、皆さんが何を学ぶべきだったかを考えさせ、提出物全体を通じてそれらのコンセプトを学んだことが実証されているかを評価させます。**言い換えれば、評価にもAIを活用し、エージェントの提案に基づいて皆さん一人ひとりにスコアとフィードバックが提供されます。** **アナンド**: [15:28] しかし、この評価プロセスには皆さんからの意見（インプット）も取り入れたいと考えています。つまり、皆さん自身がこのプロセスを形作ることができ、望むなら「ハック」しても構いません。これを使って本日、各自がどれだけうまくできたか、どこを改善すべきかなどを特定します。このために、システムに次のようなプロンプトを与えました。「すべてのコース内容を確認せよ。ローカルMCPは私のマシンであり、ここがコース資料（議論の文字起こしや学生の提出物など）が格納されているディレクトリである」と指示しました。また、皆さんが提出したフォームの場所や、入力してもらったGoogleスプレッドシートの場所も指定しました。 **アナンド**: [16:21] ここからが面白いところです。私はこう指示しました。「私が学生に教えていること、そしてAI時代において重要だと信じていることに基づいて……」と。私はこれまでChatGPTやClaudeなどと膨大な対話をしてマシンに保存してあり、AIやエージェントがこれほど強力になった時代に人間は何を学ぶべきかについての持論を持っています。エージェントはそこにアクセスできるので、それを読み込ませています。そして「学生とその提出物をどう評価すべきか？」と尋ねたのです。私自身、どう評価すべきか完全には決めていません。私なりの視点もありますし、AIなりの視点もあるでしょう。ただ、AIがアクセスできる情報量は、私がその場で思いつけるものを遥かに超えています。 **アナンド**: [17:01] そこでAIに「すべての情報と提出物を取得し、評価基準を特定せよ。これはエージェントにそのまま投入できるプロンプトにせよ」と指示しました。皆さんが提出物を揃えたら、エージェントにそれらを精査させます。動画を音声に変換して文字起こしを確認し、必要に応じて動画のスナップショットを撮り、チャットログを読み込み、皆さんがどのようにアプリ開発に取り組んだかを確認し、アプリ自体を分析して、その情報を使って評価を行わせるわけです。 **アナンド**: [17:40] AIが考え抜いた結果、注目すべき評価基準として以下の項目を提示してきました： 1. **適切な課題（良い問い）を選び出せているか？** これには当然一定の判断力が必要であり、かなり重要です。 2. **実際にプロダクトを完成させて公開（シップ）できているか？ 単に簡単なものではなく、比較的難易度の高いものを作れているか？** これも極めて重要です。 3. **実ユーザーからの確証（エビデンス）と、エビデンスに基づいた改善（イテレーション）を行っているか？** ユーザーから意見をもらうだけでなく、その意見に沿ってプロダクトを変更しているかどうかです。 4. **プロダクトが正しく動作することを、客観的に信頼できる形で検証できているか？** これも非常に重要です。この2つ——エビデンスと検証は、おそらく最も重要な基準でしょう。 5. **プロセス全体を通じてAIをうまく活用できているか？ 失敗から学ぶことができているか？** 6. **説明責任、限界の認識、そして現実世界での判断力。** 野心的であることは大事ですが、何が不可能なのかを認識して踏みとどまることや、訴訟を起こされるような危険なものを作らないことも重要です。これらには適切な判断力が求められます。 7. **コミュニケーションとエビデンスの明瞭さ・分かりやすさ。** **アナンド**: [19:02] これらがAIの提案した評価基準です。私から見ても妥当なものに思えます。しかし、私が今からやろうとしているのは、これをもとに小さなアプリを作り、皆さんがこの評価基準に対してコメントできるようにすることです。「いや、別の基準を追加すべきだ」「この基準は削除すべきだ」「配点をこのように変更すべきだ」「この基準を見るときは、ここに重点を置き、こちらはあまり重視すべきではない」といったコメントができます。どう提案するかは皆さん次第です。 **アナンド**: [19:42] **私が作ろうとしているのは、皆さんのフィードバックをすべて受け取り、「このフィードバックは採用すべきだと思うが、この部分は採用しない」といった返答を返してくれるアプリです。** 言い換えれば、このコースの評価基準そのものを皆さん自身の手で形作ることができるのです。そしてこれこそが、本日の演習の一部でもあります。全員にとってより良い評価基準にし、かつ自分にとっても有利になるよう評価基準を改善できるかどうかに挑戦してみてください。 **アナンド**: [20:17] これがAIの作成した最終的なプロンプトです。これから行うのは、このプロンプトのコピーを組み込み、皆さんがログインして変更を加えられるアプリを作ることです。もちろんChatGPTのアカウントが必要になるかもしれませんが、無料のChatGPTアカウントで十分ですし、ChatGPTの代わりにClaudeの有料アカウントを持っていても問題ありません。間もなくこれに取り掛かります。ちょっと処理の進捗を確認させてください……よし、まだエビデンスを収集中ですね。 **アナンド**: [21:09] よし、それでは……いや、これに戻る前に、もう一つのアプリを立ち上げましょう。これを実行します。Markdownドキュメントとしてダウンロードして、次のように進めましょう。作業セッションを立ち上げます。サイズはスモールかミディアムで十分でしょう。 **アナンド**: [21:49] （AIへのプロンプト指示）「私がアップロードした評価プロンプトに対する変更提案を、学生が提出できるアプリケーションを作成してほしい。学生がテキストフィールドに必要なだけ詳しく意見を入力できるようにし、それを保存できるようにすること。各学生が自分の回答を編集でき、複数のフィードバック項目を投稿できるようにしてほしい。」 **アナンド**: [22:30] （プロンプト指示の続き）「可能であれば、そのフィードバック全体や評価プロセスの変更案を（一部または全部）取り入れることがどれほど適切か、有用かについての見解も返答として共有してほしい。この返答を参考に、学生は提案を修正したり新たな提案を追加したりできる。私は今日の終わりか週末にかけてすべてのフィードバックを集約し、評価はどうあるべきかという私の視点と照らし合わせてプロンプトを修正し、最終的にそのプロンプトを実行する予定である。コース関連の全資料、過去の対話、その他このアプリ構築に必要なあらゆる情報を自由に使って構築し、サイト上にデプロイしてほしい。」 **アナンド**: [23:35] 試してみましょう。指定すべきファイルは……よし、プロンプト自体はローカルMCPにあります。ファイル名は「evaluation_prompt」です。その他の関連コンテンツはローカルMCPの上のディレクトリや過去のチャットログにあります。よし、うまく解釈してください。何か忘れている気もしますが……そうそう、アプリ実行中はローカルMCPがオンラインにならないので、アプリに必要なコンテキストがすべて含まれている状態にしてください。ただし、関連コンテキストをもとに応答するためにアプリ内でChatGPTを使っても構いません。 **アナンド**: [25:00] よし、うまくいくことを祈って、評価アプリを立ち上げましょう。さて、皆さんのプロンプトから何を学べるかという話に戻りましょう。1つ目は非常に興味深いものです。**「私が提案する解決策は、仕様ではなく仮説として扱え（Treat my proposed solution as a hypothesis, not a specification）」**。これは、プロンプトに関する提案の中で最も重要なものの一つかもしれません。私たちは何かを求めるとき、往々にしてうまく指示を出せません。良い質問の仕方や、的確な指示の出し方を知らないのです。一方でモデルは、指示に極めて忠実に従うようトレーニングされています。「指示された通りのことをきっちりやります」というスタンスです。ユーザーが自分の望みを正確に把握している場合、AIが勝手なことをしたらそれは間違いになってしまうからです。 **アナンド**: [26:13] しかし、プロダクト開発のように抽象的で規模の大きいものにおいては、エージェントに対して「私はこう指示しているが、君の方がもっと良いアイデアを持っているかもしれない。それを試してみてくれないか？」と伝えることが重要な場合があります。このフレーズは、私が最もよく使うスキルの一つです。私には「問いのリフレーミング（reframe question）」というスキルがあり、ほぼすべてのプロンプトに必ずこれを含めています。これは基本的に「私の要求は、私の真のニーズを正確に表していないかもしれない。**これを仮説、近似値、あるいは当てずっぽうとして捉えてくれ。真のニーズのたたき台に過ぎない**」と伝えているのです。つまりエージェントに「Xを要求しているけれど、それに近いYを出してくれても構わない。とにかく良いものを作ってくれ」と許可を出しているわけです。皆さんの多くのプロンプトからも、これが最も重要な気づきとして浮かび上がっているようです。何かを試して結果が出た後、「いや、本当に欲しかったのはこれじゃない」「もっと良くできないか？」と修正した経験があるでしょう。このプロンプトのフレーズを取り入れることで、成果物の質を格段に高めることができます。ここまでで何か質問はありますか？ 一旦ここで区切りましょう。 **アナンド**: [27:48] 2つ目は、**「細部を作り込む前に、最もリスクの高い仮説をエンドツーエンドで検証せよ（Prove the riskiest assumption end-to-end before polishing anything）」**です。皆さんの中にもアプリの書き直しに苦労した人がいましたね。ある方向に3、4歩進めたところで、途中で変更するのが難しくなってしまった。「最初から書き直すべきか？」と。もしそうなら、アプリを丁寧に微調整し始める前に、そもそもこの方向性で機能するのかどうか、最も重要な前提をまずテストしておくのが賢明です。非常に役立つ教訓です。これは私自身のスキルリストには入っていなかったものですが、今まさに学ばせてもらいました。「ああ、頭では分かっていたけれど、エージェントにそう指示したことはなかったな」と。ですから、これは私のスキルリストにも追加する予定です。つまり、エージェントがこのルールを自動的に読み込み、最もリスクの高い仮説が何であるかを見つけ出して最初に検証してくれるようになります。 **アナンド**: [28:46] 3つ目は、**「問題が発生したときは、微調整する前に原因を追跡・特定せよ（When something fails, trace before you tweak）」**です。言い換えれば、皆さんの多くが「エラーが出たから、ここを変えて」と指示しがちだったと思います。しかし、変更すべき箇所は本当にそこだったのでしょうか？ まず「なぜ失敗したのか？」を分析し、その上で変更を提案させる必要があります。プロンプトの出し方において、そこが抜け落ちていたという指摘です。納得のいく指摘ですね。 **アナンド**: [29:16] 4つ目は、**「現実とシミュレーションを絶対に混同させるな（Never blur reality and simulation）」**。なるほど。エージェントがダミーデータやサンプルデータを作成したとき、あるいは皆さんがサンプルデータの作成を求めたとき、それがあたかも実データであるかのように提示されてしまうことがあります。これを見る人が誤解する恐れがあります。明確にラベル付けされるべきです。的を射た指摘です。 **アナンド**: [29:50] 5つ目は、**「フィードバックは単なる機能追加ではなく、全体への再統合の契機として扱え（Treat feedback as a reason to reintegrate, not merely to add）」**です。つまり、個々のフィードバックを……［音声途切れ］ **アナンド**: [30:01] ……フィードバックを、振る舞いと望ましい成果へと昇華させるということです。なるほど。ユーザーが「これができたらいいのに」「この新機能を追加してほしい」とフィードバックをくれたとき、皆さんのプロンプトの多くは、その要望をそのまま受け取って「この機能を追加して」と指示してしまっていました。しかし、その要求はユーザーが感じている不満の一部に過ぎないかもしれません。たとえば、ユーザーが「アプリが分かりにくい。このボタンは何をするもの？」と言ったとします。皆さんのプロンプトは「このボタンの説明を追加して」になりがちですが、実際には理解されていないボタンが他に20個もあるかもしれないのです。 **アナンド**: [31:03] そのボタンが分からないと言った根本的な理由は、アプリ全体が直感的でなく分かりにくいからです。ですから出すべきプロンプトは、**「そのボタンだけでなく、アプリ全体をもっと分かりやすく改善して」**であるべきなのです。単に機能をツギハギで追加するのではなく、全体にどう再統合すべきかという根本原因に着目してください。 **アナンド**: [31:26] つまり、皆さん全員のプロンプトを分析した結果、改善点トップ5がこれらだったということです。個人レベルで見れば、自分のチャットでは起きなかったものもあるかもしれませんが、2つのことを覚えておいてください。第1に、将来的に自分自身がこのミスを犯す可能性があるということです。このうち3つは、私自身もしょっちゅうやってしまうミスです。1つについてはすでにスキル化してありましたが、残りの2つは持っていなかったので、追加するつもりです。 **アナンド**: [32:00] 第2に、仮に自分がこのミスをしなくても、チームメイトが同じミスをする可能性があるため、知っておくことが重要です。そうすれば、相手のプロンプトを見て（理想的には自動的に検知して）、「少し指示の出し方を変えた方がいいかもしれないよ」とアドバイスできるようになります。 **アナンド**: [32:18] しかし、より高次な学び（メタ・レッスン）は、**「ログから学べる。必ずログを残せ」**ということです。他人のログにアクセスして面白い取り組みをしていないか確認できるようにし、自分のログも共有して他人が自分のプロセスから学べるようにしてください。**かつて私たちはコードをオープンソース化していましたが、今やプロンプトやログをオープンソース化することに意味があります。実際の作業はそこで行われているからです。** それこそがプロダクトを生み出している本体なのです。そしてそこから派生した教訓が、実質的に「スキル」へと変換されていくわけです。 **アナンド**: [32:54] アプリがビルドされたか見てみましょう。よし、まだ実行中ですね。もう少し待ちましょう。さて、次にやってほしいことがあります。同じGoogleスプレッドシートにこのリンクを共有しますので、一つの演習をやってみてほしいのです。B列に入れようと思いましたが……いや、シート2に新しくシートを作りましょう。「プロンプトの教訓（Prompting Lessons）」というシートにします。とりあえず「名前」と「リンク」の列があれば十分でしょう。 **アナンド**: [34:01] **これらのプロンプトの教訓から得たプロンプトを、自分のチャットセッションに適用してみてください。** 全体をコピーして自分のチャットセッションに貼り付け、「私のチャットの中で、これらのうちどれが最も顕著に現れていましたか？」と質問してみるのです。ぜひ試してみてください。つまり、自分がどのミスを犯していたか……いや、こうしましょう。オフラインでやった方が進めやすい人もいると思うので、これはオフライン課題として今日の後半に各自でやってもらうことにします。今日の講義は実践（実行）に集中しましょう。 **アナンド**: [34:57] よし、まだ動いていますね。あと数分かかりそうです。今は10時36分です。今日カバーしようと思っていたことの一部は皆さんがすでに完了しており、一部はオフラインに回すので、今日のセッションは予定より短くなるかもしれません。何か質問はありますか？ **質問者**: [35:27] 各プロンプトで犯しているミスというのは、あらゆるAI言語モデルに共通して当てはまるものなのでしょうか？ それとも、ユーザーへの感度が高い特定のモデルに特有のものなのでしょうか？ **アナンド**: [35:51] 良い質問ですね。プロンプトで犯すミスや提案されたリストは普遍的なものなのか、それとも特定のエージェントに依存するものなのか。エージェント依存という点には2つの側面があります。Claudeには当てはまるがChatGPTにはあまり当てはまらない、あるいはその逆というケースです。また、今日のClaudeには有効でも、新しいモデルやエージェントが登場することで、1年後あるいは1ヶ月後には当てはまらなくなる可能性もあります。また、必ずしもモデル固有とは限りません。CodexをGPT 5.6-soulで使うときはこのプロンプトが必要でも、たとえばDeepSeek V4 Flashで使うときは、そのモデルがそうしたミスを犯さないためプロンプトが不要になる、ということもあり得ます。十分に考えられます。 **アナンド**: [36:53] **端的に言えば、すべてのプロンプトのヒントには「寿命（有効期限）」があるということです。** その特定のコンテキストにおいてのみ有効なのです。しかし、変化しているのはエージェントや実行基盤（ハーネス）だけではありません。私たち人間側も変化しています。時間が経てば、私たちは学びを吸収します。同じミスを繰り返さなくなれば、何度も口酸っぱくプロンプトで指示する必要もなくなりますよね？ ではどうすべきでしょうか？「このモデルにはこのプロンプトを使い、あのモデルには別のプロンプトを使う」と決めるべきでしょうか？ **結論から言えば、「テストする（試してみる）」ことです。** 私にも分かりませんし、普遍的な正解はありません。質問の核心はまさに「普遍的な答えはあるか？」でしたね。答えは「ノー」です。ではどうすればいいか？ どうすべきかについての普遍的な答えもありません。だからこそテストするのです。 **アナンド**: [37:49] これに関連して湧いてくる疑問は、「Claudeを使っている人とChatGPTを使っている人とで、これらのミスの発生頻度に違いがあるのか？ 大きな差はあるのか？」ということでしょう。これは尋ねてみる価値がありますね。やってみましょう。 **アナンド**: [38:02] （AIへの指示）「Claudeを使っているユーザーとChatGPTを使っているユーザーとで、これらプロンプトの教訓の当てはまりやすさに大きな違いはあるか？ 傾向として方向性の違いが見られるなら教えてほしい。データポイント数が多いわけではないので、統計的に有意でなくても構わない。最も明確に見られるシグナルを共有し、その確信度も教えてほしい。それに基づいて、一部を切り出して『Claudeを使うときは主にこのプロンプト教訓を使うように』と指示するかもしれない。ただし、シグナルがないのに無理に作り出すことはするな。大きな違いがなくバラバラに見えるなら、率直にそう言ってくれればいい」。よし、次のイテレーションを実行させましょう。 **アナンド**: [38:58] ただ、手短に私の経験から言うと、プロンプトのコツというのは概してモデル横断的です。**モデルがどう反応するかというより、私たちがどうプロンプトを出すかという人間側の問題であることが多いのです。つまり、モデルや実行環境のミスを防ぐというより、人間のミスを防ぐためのものなのです。** 他に質問はありますか？ **質問者**: [39:40] いま議論したアプリは共有してもらえますか？ **アナンド**: [39:48] ああ、それはすでにシート2に記載してありますよ。おや、差が出ましたね。「エラーの原因をエンドツーエンドで追跡すること」はClaudeセッションでより重要であり、「作り込む前に最もリスクの高い仮説を検証すること」もClaudeセッションでより重要だ、とかなりの確信度で出ています。ただ、それがClaudeを使う人がそういうプロンプトを出しがちだからなのか、それともClaude自身がそういうミスを起こしやすいからなのかは分かりません。まだ断定はしないでおきましょう。 **アナンド**: [40:48] さて、このアプリのビルドは予想以上に時間がかかっていますね。少し寄り道して別のことを進めましょう。よし、これらはすべてカバーしましたね。提出物がすべてダウンロードできたか確認しましょう……ええ、すべての提出物をダウンロードできたようです。 **アナンド**: [41:13] もう一つ私が気になっていることがあります。皆さんはプロセスからの学びを動画で共有してくれましたよね。**これまでのプロセスから得た私たちの学びから、集合知としてさらに何を学べるでしょうか？** これも私たちが生み出せるもう一つの資産（アセット）ですよね。やってみましょう。 **アナンド**: [41:37] （AIへの指示）「学生たちがプロセスの一環としてそれぞれの学びを共有してくれた。これらに目を通し、影響度が高く頻出している学びの上位を特定し、それに基づいてソートしてほしい。影響度と頻度に基づいて、学生全体における上位5つの学びを提示してほしい。」 **アナンド**: [42:13] 試してみましょう。ここで気づくと思いますが、皆さんの作業から私たちが引き出したものは2つあります。1つは「プロンプトをどう改善できるか？」、もう1つは「私たちは何を学んでいるのか？」です。しかし、これらは私がたまたま思いついた2つのことに過ぎませんよね？ 考えてみれば、ここには実質的なデータセットが存在しています。スプレッドシートがあり、その背後にはフィードバックの文字起こしや録画動画など、あらゆるリソースを指すリンク群があります。まさに立派なデータセットです。 **アナンド**: [42:51] 先ほど申し上げたように、**このような素材を使って何ができるかを手探りで探す（プロスペクティングする）のではなく、感知（センシング）することができるのです。つまり、エージェントを使って、ここからどのような資産を発掘できるかを探らせるわけです。** 皆さんが作り出したデータだけを使って、新しい教育プロダクトを作ることだってできるかもしれません。それが可能かどうか見てみましょう。別のブランチを切って進めます。 **アナンド**: [43:41] よし、興味深いデータが出てきたようです。私がすでに行ったことの一つは、ChatGPTにこれらの素材をすべてスキャンさせ、学生が自身のセッションから得られるプロンプト改善の教訓トップ5を特定させたことです。現在走っている2つ目のセッションは、影響度と頻度に基づいて優先順位付けされた、学生が学んだ全体の教訓トップ5の抽出です。これらは、このデータから生まれた、いわばメタ資産や再利用可能な資産です。 **アナンド**: [44:21] （AIへの指示）「これをもとに構築できる、他に最も有望な資産は何があるか、アイデア出しとブレインストーミングをしてほしい。思考を整理するために目的を2つ設定する。1つ目：学生たちがお互いの成果から最大限に学び合えるようにすること。2つ目：将来的にこれをもとに新しいプロダクトを作りたいと考えたときに、そのエビデンスや出発点となる興味深い資産を持つこと。斬新かつインパクトのあるアイデアをブレストして提示してほしい。一つずつ実行に移していきたい」 **アナンド**: [45:03] そのプロンプトを投げて、どうなるか見てみましょう。まだ学びを特定している最中ですね。おや、出てきました。クラス全体として学んだ上位の教訓は何だったでしょうか？ 1. **AIは実行の大半を担えるが、人間の判断力がボトルネックになりつつある。** フィードバックをくれた9人のうち7〜8人がこれに言及しているのは興味深いですね。何が正しく、何が有用で、何を優先すべきで、何を信頼できるかを人間が決める必要があったからです。ええ、あらゆるAI活用において、これこそが最も重要な教訓だと断言できます。 2. **AIはソフトウェア構築の参入障壁を劇的に引き下げる。** これも9人中7人が明確に言及しています。変化したのは「これを実装できるか？」ではなく、「何をすべきか指示できるか？ 出力を見て検証し、改善できるか？」という点です。 3. **曖昧なプロンプトよりも、明確な目的と具体的な指示の方が重要である。** これは私にとって非常に興味深い指摘でした。なぜなら私はそうしないからです。皆さんも見た通り、私は非常に曖昧にプロンプトを出します。プロンプトを絞り込みの手段として使うからです。しかし皆さんが発見したこと——そして皆さんの学びとして間違いなく真実であること——は、**具体的なプロンプトを与えた方が良い結果が得られる**ということです。素晴らしいですね。曖昧さはAIの勝手な推測や無限ループ、度重なる修正を引き起こします。ぜひこの教訓を持ち帰ってください。ただ、逆の教訓も心に留めておいてほしいのです。そうしたループや度重なる修正、その試行錯誤自体が、学ぶ価値のある何かを教えてくれているかもしれないということです。自分が何を求めているか分からないときは、曖昧でも構いません。無理に具体化しようとすると、かえって間違った方向に進んでしまうこともあります。とはいえ、素晴らしい学びです。 4. **現実世界の制約は、単に回避するのではなく、プロダクト自体を変更させるべきである。** 6人が挙げていますね。APIコスト、モデルの制限、デプロイの制約、不安定なGPS、セキュリティ、締め切りなどです。こうした現実的な考慮事項があったからこそ、機能を変更したり、シンプルにしたり、一部の機能を後回しにしたりする判断ができました。ええ、極めて実践的な解決策です。しかしこれは、10個の機能を計画したとしても、実現可能なのは5〜6個かもしれないということも意味します。事前にどれが実現可能かを知っておかなければ、時間を無駄にしてしまいます。だからこそ、先ほどの教訓である**「最もリスクの高い仮説を検証せよ」**というプロンプトが重要なのです。何が可能で何が不可能なのかを最初に見極めておかなければ、開発は困難を極めます。 5. **本物のユーザーは、AIや開発者には見えない問題を浮き彫りにする。** エージェントはそのようなフィードバックをくれないため、生身の人間に確認することは不可欠です。分かりにくいUI、意味不明なボタン、感情的な反応など……これらこそまさに人間が気づき、AIには気づけないものです。AI自身は混乱しませんし、物事を理屈で理解してしまうからです。非常に有益な気づきです。 **アナンド**: [48:57] よし、作れそうなプロダクトの提案がいくつか上がってきました。これには後で戻りましょう。うーん、なるほど。おや、これは面白いですね。**皆さんはプロダクトをテストするためにエージェントを使いました。また、人間にもテストしてもらいました。この両者の違いは何でしょうか？** これは極めて強力で興味深い学びです。 **アナンド**: [49:30] （AIへの指示）「合成ユーザー（AIエージェント）と実際のユーザーの間で、予測や反応にどのような違いがあったのかに強い関心がある。両者を比較し、最も重要なポイントを教えてほしい。違いの本質が何であったかを理解できるよう、具体例を挙げてほしい。また、AIを使ったプロダクト開発だけでなく、ユーザー検証を伴うあらゆるAI活用に適用できる再利用可能な教訓として一般化してほしい」 **アナンド**: [50:12] 先に進めましょう。プロジェクトやプロダクト開発のスプリントの最後に行うこのプロセスは、**「ポストモーテム（振り返り・事後検証）」**と呼ばれます。従来のポストモーテムとは、この1週間、1ヶ月、四半期、あるいはプロダクトリリースで自分たちがやったことを振り返り、「何がうまくいったか？ 何がうまくいかなかったか？ 何を続けるべきで、何をやめるべきか？ そして同じミスを将来繰り返さないためにどう記録に残すか？」を自問自答するものでした。 **アナンド**: [50:47] 私たちが今やっていることは、実質的にポストモーテムです。しかし私たちにはサポートしてくれるエージェントがいるため、ポストモーテムに2つの新しい次元が生まれています。1つ目は、エージェントがポストモーテムを実行し、私たちが何をすべきかを提示してくれること。2つ目は、エージェントがどんな種類のポストモーテムを行うべきか（先ほどリストを出してくれたように）教えてくれることです。もちろん、エージェントはこれらを記録し、再利用可能なドキュメントにまとめることもできます。つまり、この実行部分すらもAIに委任できるのです。**「ポストモーテムを行いたい。再利用可能な資産を作りたい」と指示・仕様化すること——これこそが人間に残されるスキルであり、皆さん全員が教訓として学んだことそのものなのです。** **アナンド**: [51:30] よし、ついにアプリが公開されました。『SUTD Prompt Evaluation Prompt Lab』です。これを共有しますね。リンクを知っている人なら誰でもアクセスできます。すぐにリンクを共有しますが、まずはアプリがどんな動作をするのか確認させてください。 **アナンド**: [52:01] なるほど、現在のプロンプトが読めるようになっていますね。これがそのプロンプトです。もっと見やすい表示方法があるとは思いますが。もし私がこのプロンプトにフィードバックを出すとしたら……見てみましょう。「これでは学生が理解するには複雑すぎるのでは？ もっとシンプルな評価メカニズムやルーブリックにできませんか？」と入力して送信してみます。送信すると……どうなるか見てみましょう。フィードバックが返ってきました。「懸念はもっともですが、具体的なスコアリングやルーブリックの変更案が明確ではありません」と。なるほど、つまり「アナンド、そう変えたいのは分かるが、具体的にどう変えようと提案しているのかが曖昧だ」と言っているわけですね。確かに、このプロンプトが良くないという根拠を何も提示していません。「それがなぜ役立つのか、変更すべき根拠は何なのかの両方を明示できるように修正してはどうか」と言ってきています。極めてまっとうなフィードバックです。深く考えていれば、そのように修正を求めたはずです。ここに戻って修正し、保存する、といったことができます。 **アナンド**: [53:37] これをシートに追加しておきます。よし、「タスク1：プロンプトの教訓を自分のプロンプトに適用する」、そしてもう一つは「タスク2：評価プロンプトを改善するためのフィードバックを共有する」としておきます。これがリンクです。ここで少なくとも10分間の休憩を取りましょう。同じワークブックのシート2にある2つ目のリンクをぜひ試してみてください。プロンプトを確認して……実際には15分ほど必要かもしれませんね。プロンプトを精査し、評価基準をどう改善できるか考えてみてください。**自分にできるだけ高い点数がつくような評価基準になるよう提案してみてください。遠慮なくハックしてください。** 現在10時56分ですので、11時10分に再開しましょう。軽食も自由にどうぞ。 **アナンド**: [55:01] さて、授業を再開しましょう。後半では、皆さんに前に出てきてもらって、作成したアプリケーションを発表してもらいます。まずは……そうですね、『Study Walker』を作成した**ユリさん**からお願いしたいと思います。ユリさんはいませんか？ あ、失礼しました。こんにちは、ユリさん。前に来て『Study Walker』アプリの説明をしてもらえますか？ 続いて、『Shot Atlas』アプリの**コウセイさん**。前に来て作ったものを説明してください。日本語で説明した方が良ければ、遠慮なく日本語を使ってください。全く問題ありません。その次は**ミクさん**。ミクさん、『Roam』アプリについて2分ほどで概要を話してください。**ナナミさん**、アプリは釣りでしたね、『関東の釣り場マップ』について説明していただけると嬉しいです。**ヨハンさん**、『Jurnal Lentera Bursa』の紹介をお願いします。残りの時間を見ながら、順次声をかけていきます。 **アナンド**: [56:36] それでは早速始めましょう。皆さんにまずお願いしたいのは、発表を聞きながらアプリの機能を把握するだけでなく、そのアプリを構築する過程でどんなプロセスが踏まれたのかも汲み取ってほしいということです。ではユリさん、『Study Walker』の発表をお願いします。 **ユリ**: [57:14] ええと、こんにちは、ユリです。英語はあまり……はい。デモを共有してもいいですか？ **アナンド**: [57:26] ええ、発表しやすいやり方で構いませんよ。 **ユリ**: [57:29] 分かりました。でもPCを操作しながら話すのが難しくて…… **アナンド**: [57:40] 言ってくれれば私が代わりに操作しますよ。やりやすい方法でどうぞ。 **ユリ**: [57:47] 頑張ります。はい、こんにちは。私はこれをCodexで作りました。このアプリは『Study Walker』です。**目標はあるけれど何から始めたらいいか分からない人を支援するアプリです。** 主な目的は、ユーザーが「今日」小さな一歩を踏み出せるようにすることです。「今日」やるということがとても大切だと思っています。まず、やりたいことを入力します。あ、これは個人的なことではなくて……はい、「ゲームを作りたい」と入力して始めます。ゲームですね。そしてこのボタンを押すと、アプリがどこから始めるべきかアドバイスしてくれます。まだ始めていないので、この選択肢を選びます。 **ユリ**: [60:01] 次に、使える時間を選びます。今話しているので、3分を選びます。そして最後に、今使えるデバイスを選びます。今はノートPCしかないので、PCを選びます。 **ユリ**: [60:27] するとStudy Walkerが、具体的なアクションを1つ提示してくれます。今日試すべきことがここに表示されます。そしてこの文の下の青い部分には、準備すべきものが表示されています。PCとブラウザなので、今すぐできます。 **ユリ**: [61:13] そして……これが所要時間です。右側には、従うべき手順が順番に表示されています。これで自分が何をすべきかが分かりました。そして完全な初心者なので、アプリが具体的な検索キーワードも教えてくれます。すみません……はい、次のページです。 **ユリ**: [61:57] あ、そのボタンを押すと別のページが開きます。そうです、CodePenですね。あ、大丈夫です、ちょっと例が悪かったですが、進めます。 **ユリ**: [62:32] もし初心者であれば、このアプリはどう検索すれば理解できるかを教えてくれます。初心者はどうやってアクションを始めればいいかすら分からないので、どんな言葉で検索すればいいか、どの言葉でウェブサイトにアクセスしてどう始めればいいかを提示してくれるのです。すみません。 **ユリ**: [63:44] このページでは、最初に試した2つのことを記録できます。「必要なページやツールを開く」、これはできたので選択します。そして「CodePenを開いてHTMLを書く場所を見つける」、書く場所が見つかったのでこれにチェックを入れます。途中で気づいたことをメモに残すこともできます。自分が思ったことなどをメモできますが、これは任意（オプション）です。書いても書かなくても構いません。 **ユリ**: [65:10] アクションを試した結果として、どこまで進んだかを記録します。この例では最初のアクションを完了したので、それを選択します。ボタンを押して次のページに進みます。これがこのアプリの最後のページです。明日何をすればいいか知りたい場合は、ここを押すと表示されます。ただしこれも任意です。必須ではありません。 **ユリ**: [67:01] 別のアクションを始めたいときは、「別の目標を始める」を押せば同じように始められます。これが私が過去5日間で作ったStudy Walkerです。ご清聴ありがとうございました。つたない英語ですみませんでした。 **アナンド**: [67:50] いえ、とても分かりやすかったですよ、ユリさん。ありがとう。このアプリを例として取り上げたかった理由の一つは、**機能的には決して複雑すぎるアプリではないものの、開発・実行（エグゼキューション）のスピードが劇的に圧縮されているからです。** ユリさんはこれを実質1日で作り上げました。残りの日数はアプリの改善に充てられており、アイデアが浮かんでから形にするまでわずか1日でした。これほど簡単に作れるのであれば、私たちの日常に役立つ小さなツールをいくらでも作り始めることができます。実際、私自身にとっても有益でした。2日目か3日目にこのアプリを試したおかげで、Rust言語を少し学ぶことができたのです。ずっとやりたいと思いながら2年近く先延ばしにしていたことでした。小さなことですが、迅速に形にできるからこそ強力なのです。コウセイさん、『Shot Atlas』を紹介していただけますか？ **コウセイ**: [69:12] おはようございます。私が作成したこのサイトは『Shot Atlas』といい、シュートの位置と得点確率の関係性を示すものです。オープンプレー、セットプレー、PKから選択できます。そしてこのマップは、パスやクロス、ボール奪取などのシュートシチュエーション別のゴールを示しています。 **コウセイ**: [70:15] 2つ目に、このマップは2つのシチュエーションを比較したものです。左側が前半、右側が後半です。ここにある情報は……この黒いバーはシュートの位置からゴールまでを表します。 **コウセイ**: [71:13] そしてこのマップはシュートの種類を示しています。たとえばコーナーキック、PK、直接フリーキックなどです。この点の大きさ……赤とか青とか黄色は得点の違いの……違いを示しています。赤は確率が高く、黄色は高くありません。以上です。ありがとうございました。 **アナンド**: [72:35] ありがとうございます。このアプリを詳しく取り上げたかった理由の一つは、**アプリ内にエビデンス（根拠）が直接提示されている点です。アプリ自体がデータ駆動型であるため、検証が極めて容易なのです。**「なぜこのアプリを信頼できるのか？」と問う必要がなく、ユーザーがクリックして自分の目で数字を確認できるため、非常に説得力があります。 **アナンド**: [72:57] その一方で、データを提示することは出発点に過ぎません。**次のステップは「これを意思決定にどう活用できるか？」となります。** これを見てコーチはどうすべきか？ 特定の位置により多くの選手を配置すべきか？ こうした状況を避けるよう指導すべきか？ それは本当に機能するのか？ アプリがまだ答えていない一連の新しい問いへとつながっていきますが、それで良いのです。次のステージへと進むためのプラットフォームを提供している点が非常に強力です。次に行きましょう。ミクさん、『Roam』をお願いします。 **ミク**: [74:45] ありがとうございます。ミクです。このアプリは、写真と一緒に旅の記録を残せるアプリです。私は旅行が大好きなので、旅行中にサッと素早く思い出を記録できるアプリが欲しいと思って作りました。実際の使い方をお見せします。 **ミク**: [75:29] 今回はSUTDでの体験を記録してみます。「Start a Trip（旅行を開始）」を押します。旅行名は「SUTD」ですね。目的地はシンガポールです。開始日は9月6日。「Start of my trip」を押して……次に旅の様子と近況を記録します。皆さんに英語で話すのはまだ緊張しますね。目的地はSUTD。記録します。 **ミク**: [76:59] 写真を添付することもできます。これはSUTDのPCなので……はい、望めば写真も入れられます。次に「Add an Action（アクションを追加）」で、旅の記録をさらに追加できます。写真や目的地を入れて、記録をどんどん増やしていけます。ホームに戻って旅全体を表示すると、記録はここに保存されています。ここを押すと、記録した旅が再び表示されます。以上です。とてもシンプルです。ありがとうございました。 **アナンド**: [78:22] ありがとうございます、ミクさん。ここで注目すべきはアプリそのものだけでなく、ミクさんが辿ったプロセスです。**最初のイテレーションでは少し違うアプリを作ろうとしていました。GPS座標を使って現在地を特定し、思い出を記録しようとしていたのです。しかし何度かイテレーションを重ねる中で、技術的な問題からそれがうまく機能しないことが判明しました。そこでミクさんは方向転換し、「代わりに思い出ベースの記録アプリを作ろう」と決断したのです。** **アナンド**: [78:56] そしてこれは非常に重要なことです。**ある方向に進んでみて、うまくいかないことはあります。ピボット（方向転換）すればいいのです。AIのおかげで作成コストが極めて低くなったため、新しいものを作るのも簡単ですし、古いものを躊躇なく捨てることも容易になりました。** そもそも最初の作成に大した労力がかかっていないからです。イテレーションは極めて強力です。よし、次はこれを作ってくれたナナミさんですね。英語版にしますか、日本語版にしますか？ **ナナミ**: [79:29] 日本語で話すので、英語に通訳してください。 **アナンド**: [79:37] 了解です。英語に翻訳すればいいですね？ 完璧です、ありがとう。どうぞ。 **ナナミ**: [79:48] 今から日本語で話すので、英語にしてください。こんにちは。 **ナナミ**: [80:06] 私は東京周辺の、関東エリアという場所の釣り場についてのサイトを作りました。 **ナナミ**: [80:18] 作った理由として、私のお父さんが釣りが好きで、そういうお父さんに使ってもらえるようなサイトを作りたいと思って作りました。 **ナナミ**: [80:41] 魚の種類とかも分かったらいいなと思って作りました。 **ナナミ**: [80:55] まず初めに初心者の人が使える説明とかも載せてます。 **ナナミ**: [81:22] 私自身も釣りをあまりしたことがないので、楽しんで覚えられるように、こういうゲームとかがあります。 **ナナミ**: [81:47] ちょっと難しいんですけど、こんな感じで。 **ナナミ**: [82:01] 釣れた魚は、こんな感じで分かるようになってます。 **ナナミ**: [82:11] まずこのサイトでできることは、釣り場の検索とか、あとどういう魚がいるのかっていうのと、あと釣れた魚の記録とかができるようになってます。 **ナナミ**: [82:26] 最初場所なんですけど、場所が分かっていたら、ここに。 **ナナミ**: [82:36] こんな感じで。 **ナナミ**: [82:41] 出たらここでGoogleマップに飛んで、どのくらいの時間で行けるのかとかが分かるように設定してます。 **ナナミ**: [82:55] もし場所とか決まってなくて、魚どういう魚が釣りたいなとかが決まっていたら、魚を選択して、場所が分かるようになってます。 **ナナミ**: [83:09] アジ、ブリ、クロダイかな、っていうのが表示されるので。 **ナナミ**: [83:21] ここに場所の概要とかレビューとかあるので、実際の声とかが聞いて、状況が見れるようにしました。 **ナナミ**: [83:36] 近くの釣具屋さんの情報が、私のお父さんがこういうのがあった方がいいんじゃないかっていうのを教えてもらったので追加しました。 **ナナミ**: [83:51] 魚のカードを開いてもらうと、魚のどういう魚なのかとか、おすすめの食べ方とか。 **ナナミ**: [84:08] 今のところ魚の種類は結構まだ少ないので、自分で魚の追加できるようにカードを作れるようになってます。 **ナナミ**: [84:32] 自分の魚を記録できるように。 **ナナミ**: [84:41] まだこれは本当にデモ版で、全然判定できないようになってるんですけど。 **ナナミ**: [84:48] ここに写真を入れてもらうと、魚が何の魚かっていうのをAIが判定してくれるような場所も作りました。 **ナナミ**: [85:04] 以上です。ありがとうございました。 **アナンド**: [85:12] ありがとうございます。ここでも特に素晴らしいのは開発プロセスです。ナナミさんが何人かにこのアプリを見せてフィードバックをもらった際、「この情報は正しくないよ」という指摘がありました。**さらに詳しく調べてみると、それはAIが生成した事実に基づかないハルシネーション情報だったことが分かったのです。** **アナンド**: [85:38] それを受けて、**ナナミさんはエビデンスを表示するようにアプリを変更し、「この情報は○年○月○日に取得されたものです。元の情報源へのリンクはこちら」と表示できるようにしました。** 実質的に2つのことを実践しています。第1に、アプリを真に役立つものにするためのフィードバックを受け取って改善（イテレーション）したこと。第2に、何が正しくて何が正しくない可能性があるかを把握し、情報源の検証可能性を担保したことです。これもプロセスにおいて非常に重要な要素です。ヨハンさん、あなたのアプリを見せてもらえますか？ ご自身のPCから発表しますか？ はい、どうぞ。 **アナンド**: [86:41] 始める前に、ミオさん、もしよろしければ次に発表をお願いできますか？ そしてクリストファーさん、その次にお願いします。ちょっと画面を整えますね。よし、サインインできました。どうぞ。 **ヨハン**: [87:46] 言語を変えましょうか……日本語かな？［笑］ **ヨハン**: [88:06] これはインドネシアのユーザー、特にインドネシアの株式トレーダー向けのウェブサイトです。このサイトの機能は、**購入した銘柄やロット数を記録し、得られた利益や損失を確認できるようにすることです。** **ヨハン**: [88:34] ここにあるのがテストデータの一つです。たとえば売りたいとします。売却価格を6,500と設定しましょう。するとこれが私の利益になります。ほら、利益が記録されましたね。ただこれはテストデータなので……他のデータが消えてしまいますね。後で自分のノートPCから動かしてみます。 **ヨハン**: [89:08] また、各ユーザー個別のメールアドレスを使用しているため、管理者画面では誰がログインして何をしたかは確認できますが、ユーザーの保有データ自体は見られないようになっています。プライバシーは保護されています。 **ヨハン**: [89:29] ここも非常に便利な部分で、**既存のアプリにはない機能の一つです。ブローカー（証券会社）の手数料が利益や取引からどれくらい差し引かれているかを可視化できます。** もう一度ログインが必要ですか？ はい、どうぞ。 **ヨハン**: [90:17] ここにはプライバシーに関する注記もあり、データは収集されないことが明記されています。これで利用を開始できます。 **ヨハン**: [90:30] いま自分の管理者アカウントでログインしているので、ここにある専用のタブをクリックできます。これを開くと、何人がログインしたか、前回のセッションログや滞在時間、何をしたかが分かります。何らかの取引を行ったか、データを入力したかどうかもここに表示されます。 **ヨハン**: [90:58] 過去30日、90日、24時間ごとのユーザー数も分かります。［拍手］ **アナンド**: [91:14] ありがとう、ヨハン。**最後の部分は、私にとって最も興味深い点でした。なぜなら、単に各ユーザーにとって便利なアプリにとどまらず、あるユーザーの利用データが他のユーザーのメリットになり得るプラットフォームへと発展する可能性を秘めているからです。** ヨハンは誰が何をしていて、それがうまくいっているかどうかを把握できるため、中央集権的にも集約されたデータからも、アプリをさらに強力に進化させることができます。 **アナンド**: [91:41] 昨日のセッションで、ユーザーの行動ログを記録する「計装（インストルメンテーション）」を組み込もうと提案したのを覚えている人もいるでしょう。**これは、他者の利用データに基づいてアプリが自律的に進化していくための第一歩なのです。** **アナンド**: [91:54] では次に……ミオさん、あなたのアプリも開きますね。 **アナンド**: [92:18] ありがとう、ミオさん。日本語がいいですか、英語がいいですか？ **ミオ**: [92:22] 英語ですか？ わかりました。 **アナンド**: [92:24] あ、英語版があるんですね？ 失礼しました。それで行きましょう。 **ミオ**: [92:30] こんにちは。サカイ・ミオです。私は日本語を話すので、私のChatGPTが英語に通訳してくれます。 **アナンド**: [92:51] ［会場に向けて］彼女は日本語で話し、機械が通訳します。 **ミオ**: [93:09] えっと、今から私が日本語で説明するので、話すのをやめたら英語に翻訳してもらえますか？ **ミオ**: [93:31] 今から私が日本語で説明するので、話すのをやめたら英語で翻訳していただけますか？ **ミオ**: [93:51] これ音出すのどうすればいいの？ **学生**: [93:54] 一番右のやつ。 **ミオ**: [93:55] はい、これで日本語から英語にして。 **アナンド**: [93:59] そのまま話して。 **ミオ**: [94:10] 私は、持っている本や漫画を整理するアプリを作りました。 **ミオ**: [94:31] はじめに開くと、このサイトの使い方を説明してくれます。 **ミオ**: [94:42] これは実際に押しながら体験できて、とても分かりやすくなってます。 **ミオ**: [94:54] 飛ばすこともできます。ちょっと今回は時短のため飛ばします。 **ミオ**: [95:04] 説明を一通り受け終わるとプロフィールが作れます。 **ミオ**: [95:16] 名前を入力して好きなジャンルを選択できます。新しくジャンルを加えることもできます。 **ミオ**: [95:29] また、好きな作者も追加することができます。これは任意です。 **ミオ**: [95:39] で、えっと、さっきの説明はいつでもこのマークから見ることができます。 **ミオ**: [95:51] 本の追加はここからできます。誰か、何か追加したいものありますか？ **学生**: [96:01] ハリー・ポッター。 **ミオ**: [96:06] スペル分かんない。 **アナンド**: [96:14] 私が打ち込みましょう。 **ミオ**: [96:44] ここで出てきたものを選択して追加することができます。で、スマホ版で開くと、このカメラマークからバーコードを読み取ることで本を追加できます。 **ミオ**: [97:03] 登録内容、あ、これ英語に直した方がいいか。細かく登録できて、えっとジャンルもここで選択することができます。説明文とかもこちらで行うことができます。 **ミオ**: [97:29] シリーズ物とかもここでまとめて選択することもできます。 **ミオ**: [97:45] で、えっと、いろんな本を追加していくと、そのジャンルに合わせて自動でおすすめの本も紹介してくれます。 **ミオ**: [98:04] で、えっと、ここに表示する方法なんですが、えっと、いろいろ選べて。 **ミオ**: [98:18] 読み終わった本とかまだ読めていない本とかで絞り込むこともできるし、 **ミオ**: [98:32] 漫画や小説ごととか、お気に入り登録したもの、あとはジャンルごと。 **ミオ**: [98:42] あとは電子書籍と紙の書籍も選ぶことができます。 **ミオ**: [98:53] で、ちょっと今お見せできないんですけど、表示方法が三つあって。 **ミオ**: [99:00] 背表紙と、シリーズごとの表紙とリストがあって、私のイチオシは背表紙表示です。 **ミオ**: [99:14] 本物の本棚みたいにずらっと並べることができて、あの、一緒に購入できていない本とかも把握することができます。 **ミオ**: [99:37] 以上です。ご清聴ありがとうございました。［拍手］ **アナンド**: [99:46] ありがとう、ミオさん。ここでも興味深かったのは、テスターからのフィードバックです。あるテスターはアプリの使い方が分からず、別のテスターは小説を追加しようとした際に、版（エディション）が複数あったりジャンルが多岐にわたっていたりして、かなり苦戦していました。 **アナンド**: [100:11] しかし最終的には「この機能はすごく良いね」と言っていました。また別のテスターは、**「でも待って、この機能ってAmazonがすでに提供していなかったっけ？」**とも言っていました。 **アナンド**: [100:22] そしてこれに対するミオさんの振り返りが非常に印象的でした。**「往々にして、何をすべきかを指示することの方が難しい。実際にそれを実装・実行すること自体は難しくない」**というものです。 **アナンド**: [100:33] 残り1分しかありませんが、クリストファーさん、2分ほどで手短にアプリを紹介できますか？ よし、お願いします。 **アナンド**: [100:59] 日本語に翻訳できますか？ ええ、できると思いますよ。試してみますね。「日本語に翻訳して」と。はい、どうぞ。 **クリストファー**: [101:18] こんにちは。私が作ったのは、いわば「VCパートナーミーティング」のシミュレーション練習アプリです。初めて起業するファウンダーや起業家全般が、投資家に向けたピッチの練習をするためのものです。 **クリストファー**: [101:41] これが私のアプリです。基本的にはこれらのカテゴリを使ったQ&A形式の一問一答セッションになっています。始める前に、いくつか使える追加機能があります。 **クリストファー**: [101:58] **この機能は、スライドや自社に関するあらゆる情報をあらかじめ投入しておくためのものです。これによりAIは、その企業の実態に合わせて質問や回答を最適化し、フィードバックもその企業向けに調整してくれます。** **クリストファー**: [102:22] さらに、投資家にピッチする実際のリアルな状況を再現するためのタイマー機能も備わっています。 **クリストファー**: [102:30] ここからスタートします。すると質問が表示されます。最初の質問は、確か課題（プロブレム）についてだったと思います。マイク機能があるので、マイクに向かって話すこともできますし、キーボードで入力することもできます。 **クリストファー**: [102:54] 入力するか回答したら、パートナー（VC）に向けて提示します。簡単に例をお見せしますね。課題についての質問なので、たとえばこう言ってみます…… **クリストファー**: [103:14] 「世界の飢餓を解決したいです」。これは明らかに非現実的で、具体的な詳細が全くありませんよね。これをパートナーに提示してみます。 **クリストファー**: [103:28] そうすると、他のいくつかのカテゴリに進んでいきます。ここではコピー＆ペーストで進めますね。 **クリストファー**: [103:46] 全7ラウンドが終わると……はい、**カテゴリ別に特化したフィードバックと、総合レーティング（評価点）が表示されます。** **クリストファー**: [104:02] さらに、回答の中で何が効果的で、何が最大の欠点だったのかも教えてくれます。**そして文字起こしログをPDFとして保存することも可能です。** 以上です。［拍手］ **アナンド**: [104:24] ありがとう、クリストファー。ここでも興味深いのはプロセスです。最初のバージョンでは、1問答えるごとにAIがフィードバックを返す仕組みになっていました。しかしクリストファーは気づきました。**「待てよ、実際のVC面談はそんな風には進まない。スライド1枚ごとにフィードバックをくれるわけではなく、最後まで聞いてから総括して意見をくれるものだ」**と。 **アナンド**: [104:48] これこそが、特定ドメインに対する知識や実体験の注入です。**そうしたドメイン知識が加わることで、プロセス全体のレベルが一気に引き上げられるのです。** **アナンド**: [104:58] もうすぐ終了時間ですので、改めて強調しておきます。**皆さんがすでに体得し、学びの共有でも明らかになった通り、AIは「実行（実装）」を極めてスムーズに担うことができます。** **アナンド**: [105:15] **人間に残されているのは「判断力」です。何を指示すべきか、どう指示すべきか、どう検証するか、プロセスから継続的に学びを得るにはどうすべきか、そして次回より迅速に動けるようどうイテレーションを回すか、という判断です。** **アナンド**: [105:28] 皆さんにぜひ実践してほしいことが1つだけあります。**できる限り、あらゆることをAIに委任してみてください。そして、AIに「できないこと」は何なのかを見極めてください。その見極めを学ぶことに集中してください。それこそが、これからの時代に最も重要となるスキルです。** **アナンド**: [105:47] よろしいでしょうか？ 皆さん、ありがとうございました。今後の健闘を祈ります。明日までにこれらの詳細をまとめたメールをお送りします。お疲れ様でした。どうもありがとうございました。［拍手］