AIプロダクトはなぜ失敗するのか:非決定性、エージェンシーとコントロール、そして継続的キャリブレーション

レニーとのこの対談で二人が主張するのは、チームが従来のソフトウェアと同じようにAIプロダクトを作ると失敗する、ということだ。二人によれば、開発ライフサイクルを変える特性が二つある。非決定性と、AIシステムに与えるエージェンシー(自律的に行動する能力)と人間が保持するコントロールとの間のトレードオフである。この二つの考え方から、二人は「継続的キャリブレーション、継続的開発」と呼ぶ実践を導き出している。狭い範囲の自律性から始め、人間の行動を記録し、予期しなかった挙動に目を光らせ、システムが信頼を獲得してはじめて、許可する範囲を広げていくというものだ。

アッシュはまず、コンサルティングの現場で目にしていることから話を始めた。彼女の見方では、2025年が2024年と違った主な点は、懐疑的な見方が減ったことだ。2024年には、多くのリーダーがAIを「また一つの暗号資産ブーム」ではないかと疑っていた。彼女が目にしたユースケースの多くは、本質的には自社データに対するチャットにすぎず、それがAIプロダクトとして売り出されていた。2025年には、ユーザー体験やワークフローを再考する企業がずっと増えているという。そうした企業は、成功するAIプロダクトを作るには既存のプロセスを分解し、再構築する必要があることを受け入れている。

彼女が考える悪いニュースは、実行面が「いまだにバラバラ」だということだ。この分野はまだ生まれて3年ほどで、プレイブックも教科書もないと彼女は指摘する。デプロイ前後のAIのライフサイクルは、従来のソフトウェアのライフサイクルとは異なる。その結果、PM、エンジニア、データ担当者の間にあった従来の取り決めや引き継ぎの仕組みが崩れてしまった。以前はそれぞれの役割が自分のフィードバックループを最適化していた。今では、こうした人々はおそらく同じ部屋に集まり、一緒にエージェントのトレースを確認し、プロダクトがどう振る舞うべきかを決める必要があると彼女は言う。企業はまだ、そうした緊密な働き方を学んでいる最中だ。

アッシュは、AIシステムと従来のソフトウェアには多くの共通点があることを強調した。しかし、プロダクトの作り方を根本的に変える違いが二つあるという。一つ目は、ほとんどの人が見過ごしていると彼女が考える、非決定性である。

彼女は対比としてBooking.comを挙げた。従来のソフトウェアでは、サンフランシスコに2泊したいユーザーには意図がある。プロダクトは、ボタンや選択肢、フォームを通じてその意図を行動に変換する、よく設計された意思決定エンジンだ。AIプロダクトでは、その層が流動的で、主に自然言語によるインターフェースに置き換わる。ユーザーは同じ意図を無数の方法で表現できるため、作り手はユーザーがどう振る舞うかもはや分からない。出力側では、作り手はLLMを扱うことになる。彼女はLLMを、非決定的で確率的なAPIであり、プロンプトの言い回しに敏感で、本質的にはブラックボックスだと表現する。つまり作り手は、入力、処理、出力のいずれもよく理解できていないものを相手にしている。そのうえで挙動を予測し、それに合わせて作ろうとしているのだ。エージェント型システムでは、これがさらに難しくなると彼女は言う。

彼女は同じ特性の利点も挙げた。人はボタンをクリックしていくよりも話すほうが楽なので、AIプロダクトは利用のハードルを下げる。しかし、コミュニケーションの方法は数多くある。周辺のシステムのほとんどは決定的であり、チームは非決定的な技術から決定的な結果を得たいと考えている。「そこが少し厄介なところです」と彼女は語った。

二つ目の違いは、二人がエージェンシーとコントロールのトレードオフと呼ぶものだ。多くのチームが自律型エージェントの構築に夢中になっていることを考えると、これを論じる人があまりに少ないことに驚いているとアッシュは言う。彼女の主張では、エージェント型システムに意思決定の能力を委ねるたびに、作り手はある程度のコントロールを手放すことになる。エージェンシーが増えれば、コントロールは減る。だから作り手は、システムがその能力を獲得していること、つまり十分に信頼できるようになり、時間をかけて信頼を積み上げてきたことを確認しなければならない。

キリティは、その実践的な帰結をたとえ話で説明した。非常に長く過酷なハイキングが目標なら、初日にいきなり全ルートに挑戦したりはしない。小さな区間で訓練し、徐々に積み上げていく。同様に、チームはあらゆるツールと会社の全コンテキストにつながったエージェントから始めて、それがうまく動くことを期待すべきではない、と彼は主張する。チームは意図的に、影響が最小限で人間のコントロールが強いところから始めるべきだ。そうすることで、現在の能力がどの程度か、AIが実際にどんな問題をどの程度解決するのか、次にどんなコンテキストやツールを追加すべきかを学べる。彼はここに良い面も見ている。誰もが最小限の構造から始めてそれを発展させていくのだから、よそで見かける見栄えのするエージェントに気後れする必要はない。このパターンは自分たちの仕事の中で「何度も何度も」繰り返されていると彼は言う。

キリティが挙げた主な例はカスタマーサポートで、これはOpenAI自身も直面した問題だという。画像モデルやGPT-5などのリリースによってサポートの問い合わせ件数が急増し、新しい種類の質問が寄せられた。間違ったやり方は、ヘルプセンターの記事をすべてエージェントに放り込むことだと彼は言う。段階的なアプローチでは、まずAIが人間のサポート担当者に回答を提案するところから始める。人間は、個々のケースでどの提案が良く、どれが悪いかを示す。そのフィードバックによってシステムの盲点が明らかになり、修正できるようになる。そうしてはじめて、システムは顧客に直接回答する段階へと進む。その後で、返金の処理やエンジニアリングチームへの機能要望の登録といった新しい能力を追加できる。これらすべてを初日から始めると、複雑さは「信じられないほど制御が難しく」なると彼は語った。

アッシュは、より高いレベルの考え方を「振る舞いのキャリブレーション」と表現した。システムがどう振る舞うかを事前に予測することは事実上不可能なので、目標は、ユーザー体験を損なわないようにしながら、人間が行使する必要のあるコントロールの量を徐々に減らしていくことだ。自律性を制限する唯一の正しい方法はない。彼女が挙げた例は保険の事前承認で、臨床医は血液検査やMRIなどの処置の事前承認に多くの時間を費やしているため、非常に有望なユースケースだという。血液検査やMRIは、患者の情報が分かれば承認しやすいため、比較的手をつけやすい部分だ。侵襲的な手術はリスクが高く、自律的に承認すべきではない。チームは、どのケースをヒューマン・イン・ザ・ループの層に通し、どのケースをAIに任せられるかを決めることができる。その間ずっと人間の行動を記録し、信頼を損なうことなくシステムを改善するフライホイールを築いていく。

レニーは、二人が以前寄稿したゲスト記事から、さらに二つの段階的な進め方を読み上げた。コーディングアシスタントの場合、段階はインライン補完や定型コードから始まり、人間がレビューするテストやリファクタリングといった大きなコードブロックを経て、変更の適用とPRの作成を自律的に行う段階へと進む。マーケティングアシスタントの場合は、メールやSNS向けの文面の下書きから始まり、複数ステップのキャンペーンの構築と実行を経て、複数チャネルにまたがるキャンペーンの立ち上げ、A/Bテスト、自動最適化へと進む。

レニーは、チームがいきなりV3の段階に飛びつくとトラブルに陥るのではないかと指摘した。キリティもこれに同意した。エージェントが「100通りくらいのやり方で」間違ったことをしていると、優れた評価手法があったとしても、そのすべてを一覧にして修正するのは現実的に無理だ。間違った場所から始めると、軌道修正が非常に難しくなる。

彼は、コントロールを強くエージェンシーを弱くして始めることの、あまり目立たない利点を指摘した。それは、自分たちが実際にどんな問題を解決しようとしているのかを考えざるを得なくなることだ。二人は「問題ファースト」という言葉を使っている。キリティにとってこの考えは当たり前に思えたが、人々には強く響くという。AIが急速に進歩する中で、解決策の複雑さばかり考え続けて問題を忘れてしまうという、陥りやすい落とし穴がある、と彼は言う。自律性を小さな規模から始めることで、チームは問題を、後に向けて構築していける自律性のレベルへと分解せざるを得なくなる。

アッシュは、UCバークレーとDatabricksのマテイ・ザハリアらの研究者による最近の論文を引用した。彼女の読み方によれば、調査対象となった企業の約74〜75%が、信頼性を最大の課題として挙げていた。それが、顧客向けのプロダクトをデプロイすることに不安を感じる理由だった。著者らはこれを、現在のAIプロダクトの多くが、ワークフローを置き換えるエンドツーエンドのエージェントではなく、自律性の低いカテゴリーである生産性向上に重点を置いている理由とも結びつけている。これは自分のスタートアップが目にしていることと一致すると彼女は語った。

レニーは、プロンプトインジェクションとジェイルブレイクを扱った以前のエピソードに触れた。そのゲストは、これを解決不可能かもしれない問題であり、ガードレールは簡単に回避されてしまうと説明していた。アッシュは、システムが主流になれば、これは巨大な問題になると予測した。今のところ、チームは構築に忙しくてセキュリティを気にかける余裕がないと彼女は言う。基盤となるAPIが非決定的であるため、プロンプトに注入できる指示は数多く存在する。

キリティはより楽観的な見方を示した。彼もこれが現実の問題であることには同意する。しかし、2025年はエージェントにとって忙しい一年だったとはいえ、導入はまだごく初期の段階にあり、普及の度合いは企業が恩恵を受けられる水準をはるかに下回っている、と彼は主張する。適切なヒューマン・イン・ザ・ループのチェックポイントを設ければ、企業はプロセスを効率化しながら、こうしたリスクの多くを回避できると彼は考えている。企業は、何がうまくいかない可能性があるかばかりに目を向けるのではなく、AIの導入を試みる必要があると彼は言う。OpenAIで彼が話をした企業の中で、AIがまったく役に立たないと結論づけたところは一つもなかったという。最適化できることは、必ず何かしらあった。

AIプロダクトをうまく構築できる企業を何が分けるのかと問われ、アッシュは、リーダーシップ、文化、技術的な前進という三つの辺からなる「成功の三角形」について説明した。「あらゆるテクノロジーの問題は、まず人の問題です」と彼女は語った。

リーダーシップについて彼女が言いたいのは、リーダーは10年、15年かけて直感を築き上げ、その直感によって尊敬されているということだ。AIに関しては、その直感を学び直さなければならず、そのためには弱さをさらけ出す覚悟が必要になる。彼女が挙げた例は、かつて一緒に働いていた、現在Rackspaceのガジェン・カンディアCEOだ。ガジェンは毎日午前4時から6時を「AIのキャッチアップ」のために確保し、会議を入れずにポッドキャストなどの情報を取り入れていた。ガジェンは週末にバイブコーディングのセッションも開いていた。アッシュによれば、ガジェンは信頼できる2〜3の情報源という短いリストに頼っていた。その後、ガジェンは彼女も参加していたAI専門家のグループに質問を持ち込み、この学びが会社の意思決定にも浸透していったと語っていたという。リーダーは手を動かす必要がある、と彼女は主張する。それは物を実装するためではなく、直感を作り直すためだ。自分の直感が間違っているかもしれないこと、自分が「その場で一番分かっていない人間」かもしれないことを受け入れるべきだという。これはトップダウンで行われなければならないと彼女は考えている。テクノロジーを信用していないリーダーや、期待がずれているリーダーから、エンジニアが賛同を得ることはできない。リーダーがAIの能力を過小評価しているか、あるいは何かをバイブコーディングで作ってみて、本番環境に持っていくのも簡単だと思い込んでいる、という声を多くの作り手から聞いてきたという。

レニーはこれを、以前のダン・シッパーとの対談と結びつけた。シッパーは、企業がAIで成功するかどうかを最もよく予測する指標は、CEOがChatGPTやClaudeなどのツールを1日に何度も使っていることだと語っていた。

文化について、アッシュは、AIが本業ではない多くの企業は、競合がやっているからという理由でAIを導入していると言う。それはしばしば、FOMO(取り残されることへの恐れ)や「あなたは置き換えられる」という文化を生む。これは有害だ。なぜなら、領域の専門家が不可欠だからだ。チームは、AIがどう振る舞っているか、そしてどう振る舞うべきかを理解するために、専門家を必要としている。それなのに、自分の仕事が置き換えられると考えて専門家が協力しようとしない企業と、彼女は話をしたことがある。リーダーはその代わりに、人々が自分の仕事を守るのではなく、自らのワークフローにAIを取り入れて仕事を「10倍」にするような、エンパワーメントの文化を築くべきだ。AIは以前よりも多くの機会を開いている、と彼女は付け加えた。

技術面について、成功しているチームは自分たちのワークフローを理解することに執着していると彼女は言う。どの部分がAIに適していて、どの部分にヒューマン・イン・ザ・ループが必要かを判断している。ワークフローの一部を自動化することは、単に「エージェントを使う」という話であることはめったにない。通常は、ある部分を機械学習モデルが担い、ある部分を決定的なコードが担う。チームは技術に固執するのではなく、それぞれの部分に適したツールを選ぶ必要がある。こうしたチームは、非決定的なAPIを扱うことでライフサイクルが変わることも理解している。顧客体験を損なわない形で素早く反復しながら、挙動を推定するのに十分なデータを得ている。「競合の中で最初にエージェントを持つ会社になることが大事なのではありません」と彼女は言う。「時間とともに改善していけるように、適切なフライホイールを整えられているかどうかが大事なのです」

そこから強い主張が導かれた。もし誰かが、2〜3日で大きな成果を示すワンクリックエージェントを約束してきたら、アッシュは懐疑的になるという。その理由はモデルの能力ではなく、企業の雑然としたデータとインフラだと彼女は言う。分類体系は雑然としている。技術的負債が積み重なり、「get customer data v1」と「get customer data v2」のような関数が両方存在し、両方とも呼び出されている。エージェントがこうしたシステムを理解するには時間がかかる。彼女はワンクリックエージェントの売り文句を「純粋なマーケティング」と呼んだ。彼女なら、時間とともに学習するパイプラインを構築するベンダーを選ぶという。彼女の見積もりでは、最高のデータ層とインフラ層があったとしても、重要なワークフローを置き換えたり大きなROIを得たりするには「優に4〜6か月の作業がかかる」。

Evalsをめぐる議論について、キリティは、Evalsか本番モニタリングのどちらか一方だけですべてが解決すると考えるのは誤った二分法だと述べた。彼はEvalsを、チームのプロダクト知識をデータセットとして符号化したもの、つまり何が重要で、エージェントが決してやってはならないことは何かを表したものだと説明する。本番モニタリングとは、デプロイしたうえで、顧客が実際にプロダクトをどう使っているかを示す主要な指標を追跡することだ。本番モニタリング自体は昔から存在していると彼は指摘する。AIエージェントの場合は、より細かい粒度が必要で、暗黙的なシグナルも含めなければならない。彼の例はChatGPTだ。ユーザーは低評価を押さないかもしれないが、回答を再生成したなら、それは最初の回答が期待に届かなかった明確なサインである。

彼は、この二つがどう組み合わさるかを説明した。何のテストもせずにリリースする人はいない。それが感覚的なものであれ、絶対に間違えてはならない10個の質問のセットであれ、だ。それを評価データセットと呼ぶ。デプロイ後、トラフィックの多いプロダクトでは、すべてのトレースを手作業で確認することはできない。明示的なシグナルと暗黙的なシグナルが、どのトレースを見るべきかをチームに教えてくれる。そうしたトレースを調べることで、失敗のパターンが見えてくる。そのパターンがチームにとって本当に重要なものであれば、それが新しい評価データセットになる。彼の例は、明示的に返金しないよう設定されていたにもかかわらず、返金を申し出ていたエージェントだ。ツールやプロンプトを修正して第2版をリリースしても、それが唯一の問題だったという保証はないので、モニタリングは依然として必要だ。どちらか一方のアプローチだけで十分だという見方は、彼の言葉を借りれば「まったく取るに足らない」ものだ。

アッシュは、2025年後半には「Evals」という言葉が非常に多くの意味を背負わされていたと付け加えた。データラベリング企業は、自社の専門家がEvalsを書いていると言う。論者たちは、PMがEvalsを書くべきだと言い、それを「新しいPRD」と呼ぶ。Evalsこそがフィードバックループ全体だと言う人もいる。彼女は、これらはプロセスの異なる部分を指していると主張する。ラベリング企業の弁護士や医師が「Evalsを書く」とき、彼らがしているのはLLMジャッジの構築ではなく、エラー分析やアノテーションに近いことだ。PMがEvalsを書くべきだと言うとき、それは本番レベルのLLMジャッジを意味するわけではない。彼女はマーティン・ファウラーの「セマンティック・ディフュージョン(意味の拡散)」という用語を持ち出した。ある用語が誰によっても再定義され、元の意味を失ってしまうことだ。根底にあるニーズ、つまりAIプロダクトのための実用的なフィードバックループについては、実務家なら誰もが同意するだろうと彼女は考えている。それをどう構築するかはアプリケーションによる。複雑なユースケースでは、LLMジャッジの構築は非常に難しくなると彼女は言う。たとえば冗長さをテストするジャッジでは捉えられない新しいパターンが次々と現れる。チームはEvalsを持ちすぎることにもなりかねない。そうなると、ユーザーのシグナルを見て、問題を修正し、リグレッションを確認して先に進むほうが理にかなっているかもしれない。彼女のアドバイスは、処方箋に執着しないことだ。処方箋は変わっていくからだ。

彼女はまた、「Evalsをやっている」と言っていたクライアントの話をした。データセットを見せてほしいと頼むと、モデルを選ぶためにLMArenaとArtificial Analysisを確認していたのだと説明された。それはモデルのベンチマークであってEvalsではない、と彼女は伝えたという。

レニーは、Claude Codeの責任者による、チームはEvalsをやっておらず感覚に頼っているという発言を取り上げ、Codexではどうしているのかを尋ねた。キリティはバランスの取れたアプローチについて説明した。コーディングエージェントは、エンジニア向けに、カスタマイズ性を重視して作られているという点で、他の領域のエージェントとは異なると彼は言う。決まった5つか6つのワークフローを解決するためのものではない。数多くのインテグレーションやツールにまたがって使われるため、あらゆるインタラクションをカバーする評価データセットを構築するのは非常に難しい。それでもチームは、変更によって中核機能が損なわれないことを確認するための評価を維持している。

同時に、チームは顧客がプロダクトをどう使っているかにも細心の注意を払っているとキリティは言う。彼の例は最近リリースしたコードレビュー製品で、大きな反響を得ており、OpenAI社内でも外部の顧客でも多くのバグを発見してきたという。コードレビューの裏にあるモデルを変更したり、別のRLの手法で学習させたりする場合、チームはそれが正しい誤りを見つけるか、ユーザーがどう反応するかをA/Bテストしたいと考える。誤ったレビューに苛立ったユーザーは、製品を完全にオフにしてしまうこともあり、それは注視すべきシグナルだ。こうしたシナリオを事前に予測するのは非常に難しいと彼は言う。チームはまた、報告された問題がないかSNSも注意深く見ている。新しいモデルが届くと、チームメンバーはそれぞれ異なる領域に集中し、共有している難問のリストを新モデルで試す。彼はこれを、エンジニアごとのカスタムEvalsのようなものだと表現した。他に何も必要とせず、命を賭けられるほどの確固たるEvalsのセットを持っていると主張する人がいても、自分は信じないと彼は言う。

二人の仕事の中心にあるのが、CI/CDにちなんで名づけた、継続的キャリブレーション、継続的開発(CC/CD)と呼ぶフレームワークだ。アッシュはその背景を説明した。多くの企業は完全自律型のエージェントを構築しなければという競争圧力を感じており、彼女もいくつかの顧客とエンドツーエンドのエージェントに取り組んだ。ユーザーがどうやり取りするか、AIがどう応答するかを事前に誰も知らなかったため、多くの判断を含む4〜5ステップのワークフローをデバッグすることは手に負えなくなった。二人のゲスト記事で例として使われたあるカスタマーサポートのプロジェクトでは、ホットフィックスがあまりに多かったため、チームはプロダクトを停止しなければならなかった。次々と現れる問題に追いつく術がなかったのだ。彼女はエア・カナダの事例も挙げた。彼女の言葉によれば、エージェントが会社のプレイブックにない返金ポリシーをハルシネーションで作り出し、航空会社は法的な理由でそれを履行しなければならなかった。このフレームワークの狙いは、顧客の信頼を守り、危険な判断を避けながら、それでも改善のためのフライホイールを築くことにある。

ループの開発側は、能力の範囲を定め、データを整備するところから始まる。想定される入力と想定される出力のセットだ。アッシュは、どんなAIプロダクトを作る前にもこれをやる価値があると考えている。プロダクトがどう振る舞うべきかについてチームの認識がそろっていないことが、しばしば明らかになるからだ。ここはPMや領域の専門家が大きく貢献できるところだ。データセットは網羅的ではないが、出発点にはなる。次にチームはアプリケーションを準備し、評価指標を設計する。彼女はあえて「Evals」ではなく「評価指標」という言葉を使っている。評価はプロセスであり、指標はその過程で測定される次元だからだ。そしてチームはデプロイし、それらの指標を実行する。

キャリブレーション側は、誰も予期しなかった挙動に対処する。ユーザーはほぼ必ず、元のデータセットが想定していなかった振る舞いをする。指標はある程度の洞察を与えてくれるが、指標がカバーしていない新しいエラーパターンがしばしば現れる。チームは挙動を分析し、エラーパターンを見つけ、修正を適用し、新たに現れたパターンのための新しい指標を設計する。ただし、すべてのエラーに新しい指標が必要なわけではない。定義の甘いツールが原因で一度だけ起きたツール呼び出しの失敗なら、単に修正すればよい。

こうした反復を通じて、このフレームワークは、まずエージェンシーが低くコントロールが強いバージョンから始め、時間とともに自律性を高めていくことを求めている。アッシュは、カスタマーサポートの例を3つのバージョンに分けて説明した。

バージョン1:ルーティング。 エージェントはチケットを分類し、適切な部署に振り分ける。些細なことに聞こえるかもしれないが、企業におけるルーティングは、雑然とした階層的な分類体系のせいで非常に複雑になりうるとアッシュは言う。彼女が手がけたあるケースでは、「靴」「女性用の靴」「男性用の靴」がすべて同じ階層に並んでいた。さらに下を見ると、靴の下に「女性向け」「男性向け」という別のセクションがあり、統合されないままになっていた。人間の担当者なら、あるノードが最後に更新されたのが2019年であることに気づき、使われていないものとして扱うかもしれない。モデルにこれが扱えないと主張しているわけではない、と彼女は言う。彼女が言いたいのは、企業には文書化されていないルールがあり、エージェントには単に問題を渡すのではなく、そうしたコンテキストが必要だということだ。ルーティングは、人間が誤った振り分けを修正できるため、コントロールの強い段階である。また、データ層を十分な品質にするために修正すべきデータの問題も浮かび上がらせる。

バージョン2:コパイロット。 ルーティングがうまく機能し、データの問題が修正されたら、エージェントはサポートチームの標準作業手順に基づいて回答の下書きを作成し、人間の担当者がそれを編集する。システムは、各下書きのどれだけが使われ、何が省かれたかを記録する。アッシュはこれを「タダでエラー分析ができる」と表現し、それがフライホイールにフィードバックされる。

バージョン3:エンドツーエンドの解決。 下書きがほとんど編集されず、ほぼそのまま使われるようになったら、エージェントが解決策の下書きを作成し、チケットのクローズまで行えるようにする。

二人の表では、各バージョンについて、何を行い、何を学び、何がループにフィードバックされるかが一覧になっている。たとえばルーティングからは、より質の高いルーティングデータが得られ、プロンプトをどう構造化すべきかも見えてくる。彼女はこれを、コンテキストエンジニアリングのための構造を見つけることだと表現している。

アッシュは二つの注意点を付け加えた。第一に、CC/CDは問題を一度で完全に解決するものではない。チームがV3に到達しても、誰も想像していなかったデータ分布に出くわすことはありうる。これは、完全な自律性に到達する前にユーザーの振る舞いを学ぶことで、リスクを下げる一つの方法である。第二に、Evalsがあるのになぜこれが必要なのかと問う人々に対して、彼女は、評価指標が捉えられるのはチームがすでに知っているエラーだけだと答えた。新たに現れるパターンは本番環境でしか表に出ず、このフレームワークは、一度に大量のエラーに見舞われることなく、それらを見つけるための、よりリスクの低い方法を提供する。自律性は他の方法でも制限できる。この例ではアクションの数を制限しているが、トピックで制限することもできる。ある領域は完全な自律性を与えるにはリスクが高すぎるが、別の領域なら問題ない、といった具合だ。これはPM、エンジニア、領域の専門家が一緒に決めるべきことだ。

よくある質問は、ある段階が十分にキャリブレーションされたことをどうやって判断するのか、というものだ。アッシュは、ルールブックはないが、原則は「驚きを最小化すること」だと言う。チームが1〜2日おきにキャリブレーションを行い、新しいデータ分布のパターンが見られなくなり、ユーザーの振る舞いが一貫しているなら、得られる情報は少なく、おそらく次に進む時期だということだ。その時点では「すべては感覚次第」であることを彼女は認めた。

出来事によってキャリブレーションが崩れることもある。彼女の例は、APIも含めてGPT-4oが廃止されることだ。企業はGPT-5に切り替えなければならず、彼女によればGPT-5は特性が大きく異なるため、キャリブレーションをやり直す必要がある。ユーザーの振る舞いも時間とともに変化する。能力が向上するにつれ、人々のChatGPTへの話しかけ方は2年前とは違っているし、システムがあるタスクを解決するのを見た人は、それを別のタスクにも試してみたくなる。

彼女の最も分かりやすい例は、ある銀行の融資審査担当者向けに構築したシステムだ。融資の申込書は30〜40ページに及ぶこともあり、このシステムは、審査担当者が融資を承認するために関連するポリシーや銀行の情報を探すのを支援していた。3〜4か月の間、誰もが感心し、審査担当者は時間の節約を報告していた。ところがその後、彼らは熱心になるあまり、誰も予想していなかった質問をし始めたと彼女は言う。申込書を丸ごと投入して、「このようなケース」で以前の審査担当者がどうしたかを尋ねるようになったのだ。ユーザーにとって、これは自然な延長のように感じられた。作り手にとっては、まったく異なるエンジニアリングが必要だった。システムは「このようなケース」が何を意味するのか、ある収入帯なのか、地域なのかを解釈し、単にポリシーを調べるのではなく、過去の文書を取得して分析しなければならなかった。エンドユーザーにとって自然に思えることが、作るのは非常に難しい場合がある、と彼女は結論づけた。そして振る舞いがこのように進化したときこそ、キャリブレーションをやり直す時期なのだ。

キリティは、過大評価されていると言うものは特にないが、マルチエージェントシステムは誤解されていると考えている。よくある考え方は、複雑な問題を機能ごとにエージェントに分割し、それらをつなげて「エージェントのユートピア」を期待するというものだ。成功しているマルチエージェントシステムがあることには彼も同意し、サブエージェントを従えたスーパーバイザーエージェントを成功しているパターンとして挙げた。彼が疑問視しているのは、機能ごとに責任を分割し、エージェント同士が「ゴシッププロトコル」のようなものでピアツーピアに連携することを期待するやり方だ。現在の構築手法とモデルの能力がそこまで達しているとは思わないと彼は言う。人間が複数のエージェントをオーケストレーションすることも、一つの大きなエージェントがオーケストレーションすることもできる。ピアツーピアの構成では、特にカスタマーサポートにおいて、どのエージェントが顧客に応答しているのかを制御するのが非常に難しくなり、あらゆる場所にガードレールを設置しなければならなくなる。

過小評価されているものとして、彼はコーディングエージェントを挙げた。ネット上の盛り上がりを考えると奇妙に聞こえるかもしれないが、一般的な企業のエンジニア、特にベイエリア以外のエンジニアの間では、潜在的な影響力に比べて導入がはるかに遅れていると彼は言う。2025年から2026年にかけて、こうしたプロセスを最適化することで多くの価値が生まれると彼は予想している。

アッシュは冗談めかして過大評価されているものにEvalsを挙げ、その後、重要でないという意味ではなく誤解されているという意味だと説明した。彼女が本当に過大評価されていると考えるのは、ツールを次々と乗り換え、最新のものを追いかけ続けることだ。「今は作ることが本当に安くなっています」と彼女は言う。一方で、設計のほうがコストは高い。問題と設計を深く理解することは過小評価されており、作ること自体を目的にすることは過大評価されている。

キリティは、バックグラウンドで動く、あるいはプロアクティブなエージェントが進歩すると予想している。彼の見方では、今日AIが価値を生み出せていない主な理由は、コンテキストが欠けていることにある。実際に仕事が行われている場所につながっていないからだ。エージェントがコンテキストを得るにつれ、その人がどんな指標を最適化しようとしているのか、何をしようとしているのかを理解し、ユーザーに対して自ら働きかけられるようになる。彼はChatGPT Pulseを挙げた。これはユーザーが関心を持ちそうなことを毎日アップデートとして届けてくれる。彼が思い描いているのは、一日の始まりに、Linearのチケットを5件修正してパッチのレビュー準備ができていると教えてくれるコーディングエージェントだ。これは2026年のプロダクトにとって有力な方向性だと彼は考えている。

アッシュはマルチモーダルな体験に賭けている。人間はマルチモーダルな存在であり、言語は「おそらく私たちの進化の中で最も新しい形態の一つ」だと彼女は主張する。会話の中で人は、うなずきや退屈そうな様子といったシグナルに基づいて絶えず調整しており、彼女はそれを「思考の連鎖の背後にある思考の連鎖」と表現した。より豊かなマルチモーダルシステムは、人間の会話の豊かさにより近づけるかもしれない。彼女は地味な仕事にも目を向けた。手書きの文書や雑然としたPDFの多くは、今日の最高のモデルでも解析できず、マルチモーダルな理解が向上すれば、多くのデータが活用できるようになる。

作り手はどんなスキルを伸ばすべきかと問われ、アッシュは、今後数年で実装は「ばかばかしいほど安く」なるので、作り手は設計、判断力、センスに注力すべきだと語った。キャリアの初期は伝統的に、実行の仕組みを身につけることに重点が置かれてきた。今ではAIのおかげで素早く立ち上がることができ、その後は誰の仕事も、センスと判断力、そしてその人ならではのものに行き着くと彼女は考えている。それには年功は必要ない。彼女が挙げたのは、最近入社した人の例だ。その人は、チームが何年もお金を払ってきた高価なタスク管理ツールに代わるアプリを自らバイブコーディングで作って会議に現れ、全員をそれに移行させた。バイブコーディングで作ったアプリは保守コストが高く、会社が成長すれば置き換えが必要になるかもしれないことは彼女も認めた。しかし、そこにある主体性とオーナーシップに感銘を受けたという。特定の働き方に慣れた人は作ることにコストを感じるが、若い人はそれをずっと低く見積もる。新しいツールを試したがるこの同じ熱意が、AIプロダクトがリテンションの問題を抱えている理由でもあると彼女は示唆した。彼女はまた「忙しいふりをする仕事の時代の終わり」も予測した。片隅に座って、成果につながらない仕事をしているだけではもう済まされない、ということだ。レニーは、営業チームの大半をエージェントに置き換えたジェイソン・レムキンの逸話を付け加えた。エージェントが通話内容からSalesforceを自動更新し始めた後、ある営業担当者が辞めたという。どうやら、その担当者があまり仕事をしていないことが露呈してしまうからだったようだ。

キリティは粘り強さを強調した。誰もが情報にすぐアクセスできる今、誰でも素早く学ぶことはできるが、本当の優位性は、学び、実装し、何がうまくいくかを見つけ出すという苦痛をくぐり抜けることから生まれる。「苦痛こそが新しい堀(モート)です」と彼は語った。詳しく説明を求められると、新しい領域で成功している企業が成功しているのは、市場に一番乗りしたからでも、派手な機能があったからでもない、と彼は主張した。彼らは、自分たちにとって譲れない要件を特定し、それに対応できる機能やモデルの能力と突き合わせるという苦痛を経験してきたのだ。これには教科書も、踏み固められた道もない。Evalsという形であれ、他の形であれ、試行錯誤を繰り返す中で築かれた知識こそが、その企業の堀になる。

アッシュの締めくくりのアドバイスは、顧客と問題に執着し、AIはツールとして扱うことだった。いわゆるAIエンジニアやAI PMの80%は、最先端のモデルを作ることではなく、ワークフロー、顧客の振る舞い、データを理解することに時間を費やしていると彼女は見積もる。AIに不慣れなソフトウェアエンジニアは「データを見なさい」というアドバイスにしばしば驚くが、それはずっと真実であり続けてきたことであり、大きな差別化要因になると彼女は考えている。

アッシュが薦めたのは、ポール・カラニシの『いま、希望を語ろう』だ。30代前半で肺がんと診断された脳神経外科医が書いた回想録である。彼女が取り上げたのは、ソクラテスの「吟味されない人生は生きるに値しない」に対するカラニシの応答、「生きられなかった人生は吟味するに値したのか」という言葉だ。彼女はそれを、AIの時代に絶えず自分を作り変え続けている人々に向けて、立ち止まって生きることを思い出させてくれるものだと受け止めた。キリティは『三体』シリーズを薦めた。特に、抽象的な科学が人類の進歩にとってどれほど重要か、そしてたとえ日々の生活では気づかなくても、その進歩が止められることがどれほど壊滅的かというテーマを評価している。レニーはヴァーナー・ヴィンジの『遠き神々の炎』を薦めた。

ドラマやゲームについては、アッシュは『シリコンバレー』を見返しており、今のAIブームと不気味なほど似ていると感じている。キリティは『Expedition 33』をプレイしている。アッシュが最近気に入っているプロダクトはWispr Flowだ。コンテキストを踏まえて文字起こししてくれる点を評価しており、Codex内の変数を認識したり、感嘆符を3つ付けるという音声での指示を実際の記号に変換したりしてくれるという。キリティはRaycastと、caffeinateコマンドを挙げた。これはMacをスリープさせずに保つコマンドで、Codexのタスクをローカルで4〜5時間実行させることができる。

アッシュの人生のモットーは、父親から教わった「できないと言われたが、愚か者はそれを知らなかったので、とにかくやってのけた」という言葉だ。失敗すると示すデータは常にあるものだから、時には愚かになって突き進めばいい、と彼女は語った。自称考えすぎるタイプのキリティは、点と点は振り返ってはじめてつなげられるというスティーブ・ジョブズの言葉を挙げ、動き続け、実験し続けるための励ましにしている。互いに尊敬しているところを問われると、アッシュはキリティの落ち着いて地に足のついた性格と、問題を先回りして予測する能力を称え、そのうえで二人が結婚して4年になることを明かした。キリティは、複雑なテーマを教え、分かりやすく噛み砕くアッシュの能力と、それに加わる粘り強さを称えた。それが変化の速い分野で人々に力を与えているのだと彼は言う。