スタンフォードCS230 | 2025年秋 | 講義8：エージェント、プロンプト、RAG

2016年、マイクロソフトはユーザーから学習するためにTwitterでボットを立ち上げました。わずか1日足らずで、あまりにも人種差別的な発言をするようになったため、わずか16時間後にシャットダウンせざるを得ませんでした。それは即席で編成されたチームではなく、マイクロソフトでした。しかし、数十億ドルと数百人のエンジニアが投入されても、言語モデルを真に制御することは依然として解決されていない問題です。そして、ここが一般的な物語の最初の亀裂です。私たちは、「強力なモデル」が「有用なモデル」と同義であると考えています。しかし実際、LLMの最近の歴史は、信頼性が高く、最新の、そして何よりも正しい出力を得ることがいかに複雑であるかを示す大きな教訓です。このレッスンの論点は、真の飛躍は、ますます大きな基本モデルを構築することではなく、すでに持っているモデルを調整し、修正し、強化する方法を学ぶことであるということです。単純なプロンプトの改善から、本格的なエージェントワークフローやマルチエージェントワークフローに至るまで、おもちゃと製品の違いは、モデルそのものではなく、モデルを取り巻くアーキテクチャにあります。Andrew Ng は、この方向性に「エージェントワークフロー」という名前を付けました。これは、モデル、外部ツール、メモリ、API が自律的な一連のアクションとして組み合わされるシステムです。顧客レビューを分類したいバイオテクノロジー企業のケースを考えてみましょう。理論的には、モデルに「この文は肯定的、中立的、否定的のどれですか？」と尋ねるだけでいいのです。しかし、結果はさまざまな要因によって左右されます。医療系のスタートアップ企業にとって、「すべて順調だったが、期待以上のものではなかった」というコメントは否定的なものかもしれませんが、他の分野では中立的なものとなるでしょう。モデルを実際のニーズに合わせるにはどうすればよいのでしょうか？より多くのデータやより大きなモデルではなく、工夫されたプロンプト、カスタマイズされた例、そしてますます多くの場合、生成を誘導し、評価し、修正し、コンテキストに適応させる多段階のパイプラインを使用します。具体的な例として、プロンプトチェーンが挙げられます。1つの指示ですべてを求めるのではなく、タスクを段階的に分割します。まずは要点を抽出し、次に流れを作成し、最後に最終的な回答を書き出します。Workera などの企業が採用しているこのアプローチは、システムが実際にどこで間違いを犯しているのかを特定することを可能にします。例えば、アウトラインが不十分なのか、最終的な回答が冷たすぎるのか？的を絞った対処が可能です。ビジネスにおいて、この細かさがデモと信頼できるソリューションの違いを生み出します。興味深いデータ：BCG コンサルタントを対象とした調査では、AI を利用でき、さらにプロンプトに関する簡単なトレーニングも受けた人々は、AI を利用していない人々や、AI を「無計画に」利用していた人々の両方を大きく上回っていました。それだけでなく、この研究では LLM とのコラボレーションのスタイルが 2 種類あることが明らかになりました。「ケンタウロス」は、「プレゼンテーションを作成して、終わったら知らせて」といったように、作業全体を委ねるタイプです。一方、「サイボーグ」は、各ステップでモデルと微妙にやり取りし、共生して作業を行うタイプです。どちらの方法も機能しますが、必要なワークフローが異なり、企業規模で展開する場合、その違いは些細なものではありません。RAG（Retrieval-Augmented Generation）は、最新性と正確性の問題に対する最も具体的な解決策です。モデルが「すべてを知っている」と期待するのではなく、外部データベースに接続し、関連性の高い文書のみを取得して回答に組み込むのです。これは応急処置のように見えるかもしれませんが、考えてみてください。将来、モデルがリアルタイムでウェブ全体を読み取れるようになったとしても（スポiler：遅延とコストの理由から、それは決して実現しないでしょう）、効率性と情報源の追跡可能性のために、検索エンジンなどの検索システムは引き続き必要となるでしょう。トランプ大統領の有名な「Covfefe」発言直後に生成されたコンテンツの例を見てみましょう。TwitterのLLMはこれをどう扱えばよいのかわからず、推奨システムは混乱しました。今日、スラング、新語、トレンドでも毎日同じことが起こっています。RAGを使えば、すべてをゼロから再トレーニングすることなく、最新の状態を維持できます。エージェントについて考えてみましょう。カスタマーサポートのエージェントを想像してください。もはや単なるチャット応答機能ではありません。データを抽出し、注文データベースを参照し、ポリシーを確認し、情報を更新し、メールを作成します。これらすべてを、ツールとメモリを活用して実行します。しかし、それが「機能している」かどうかをどのように判断するのでしょうか？ここで、「evals」、つまり評価というテーマが登場します。客観的な指標（解決されたリクエストの割合、応答時間、出力の正確性）と、LLMによる判定や人間によるフィードバックを通じた主観的な評価の両方が使用されます。そして重要な点は、中間ステップのすべてが追跡されることです。回答が不丁寧な場合、どのプロンプトまたはサブシステムが問題を引き起こしたかを追跡できます。このモジュール式で追跡可能なアーキテクチャが、従来の決定論的なソフトウェアとLLMベースのファジーシステムとの真の違いです。ここでは、堅牢なコードを一度書くだけでは不十分で、実験し、不要な部分を捨て、繰り返し、人為的なワークフローを導入して、人工知能が間違えたり、軌道から外れたりする箇所を修正する方法を学ぶ必要があります。エンタープライズレベルでは、McKinsey は、エージェントによる自動化により、信用リスク評価などのプロセスにかかる時間を 20～60% 短縮できると推定しています。しかし、真の課題は技術面ではありません。何千人もの人々の習慣を変え、職務内容を書き換え、インセンティブを再定義することです。だからこそ、技術が進歩しても、組織が真に変革するには何年もかかるのです。最後に考えたいことがあります。今日、真の価値は、最大のモデルを構築することではなく、モデル、ツール、ワークフロー、メモリを組み合わせて、実際の、測定可能な、時間の経過とともに改善可能な問題を解決することにあります。デモと製品の違いとは？生成するモデルだけでなく、それを統括するシステム側に立つことです。このレッスンは、2025年秋のスタンフォード大学CS230コースからのものです。これで、ほぼ2時間分のレッスンを節約できました。