何が起きたか
Alphabet傘下でGoogleからスピンアウトしたWaymoの、systems intelligence and machine learning 担当エンジニアリングディレクターである Manasi Joshi 氏が、VB Transform 2026 で同社のAI開発・検証・展開の作り方を語りました。核にあるのが、同氏が「eval-forced development（評価に強制される開発）」「eval-centric development」と呼ぶ考え方です。評価はモデルを世に出す前の最終関門ではなく、エンジニアリングそのものの一部だという整理です。
象徴的なのが、プロジェクトの成熟度の測り方です。Waymoは、その案件を取り囲むテストがどれだけ成熟しているかを見て、案件自体の成熟段階を判断すると言います。Joshi 氏の言葉では「私たちのプロジェクトが成熟しつつある段階は、そのプロジェクトが示すeval成熟度からたやすく透けて見える」。裏を返せば、性能をきちんと測れない仕組みは、まだ本番に出せる段階にないということです。
なぜ重要か
この話が自動運転の内輪話で終わらないのは、Waymoのリスク管理の作法——継続的な評価、丁寧に選び抜いたデータ、人間の監督、明確に定義された事業成果——が、業界を問わずAIエージェントを本番投入する企業の型として提示されているからです。
実績の数字も、その型の説得力を支えます。Waymoによれば、完全無人（rider-only）走行は2.2億マイル超。同じ距離を走った人間ドライバーと比べ、重傷を伴う衝突事故は17分の1です。ただしJoshi 氏は、モデル品質の測定値は、その裏にある評価データの信頼性を超えられないと注意を促します。だからWaymoは性能の主張を出すとき、テストデータセットがどんな性質のものかという情報を必ず添える。「evalはモデルをローンチするための一回限りの作業ではない」というわけです。
評価の中身：どこを測るか、誰が承認するか
Waymoの品質活動の多くは評価側に移っています。学習中のテスト、学習後のテスト、オープンループ／クローズドループのシミュレーション内でのテスト。評価は走行・シミュレーション・検証をまたぐ連続プロセスとして扱われ、データセット・性能指標・大規模でも効率的に回るインフラが組み合わされます。素材は自社の走行ログを軸に一部サードパーティのデータ、そして数十億マイル相当の合成シナリオを浴びせる現実的なシミュレーションです。
重要なのは、その評価階層の頂点に安全という単一の目的が置かれている点です。そのうえで、脆弱な道路利用者（歩行者や自転車など）、踏切、工事区間といった複雑な状況ごとに、タスクのオーナーが専用のデータと指標を選びます。企業側に翻訳すれば、日常的なリクエストのテストだけでは足りず、間違えたときに金銭・法務・セキュリティ・レピュテーションの損害が出る稀なケースを狙って測る、という話です。
そしてリリース判断は自動化に委ねません。本番投入可否のレビューには広範な人間の監督が入り、社内の安全責任者がソフトウェアのリリースとサービス提供エリアの拡大を承認します。「これはAI任せで完全自動、人間の監督ゼロというものではない。人命がかかっている」とJoshi 氏。「信頼を得ることが何より重要だ」とも語っています。
効率とアーキテクチャ、そして社内エージェント
Waymoでも、計算・ストレージ・メモリ・ネットワークの需要は使えるリソースより速く伸びています。企業のAIチームにも見慣れた問題です。対策はデータ抽出・保管、分散学習、モデル蒸留、シミュレーションと評価にまたがる効率化。特に強調されるのが「データ効率」——量が多いほど良いと考えるのではなく、最も有用な学習事例を選ぶという発想です。技術は車載のオンボード系と、モデル開発・データ処理・シミュレーションを担うオフボード基盤に分かれ、リアルタイム推論と裏方システムの両方の最適化を同時に強います。
モデル面では2017年にtransformerを導入し、その後LLM、ビジョン言語モデル、ビジョン・言語・行動モデルへ広げ、現在は生成マルチモーダルモデルを基盤モデル戦略の一部として使うと言います。さらに社内では、AIエージェントをエンジニアの生産性ツールとして運用中。データ分布の分析、データ効率の評価、車両テレメトリや学習実行、失敗した評価ジョブで見つかった問題のトリアージを手伝わせます。狙いは調査作業を速め、エンジニアの時間を判断と難所に寄せること。そのエージェント自体も評価対象で、社員を無駄な方向へ走らせないかを確かめます。
Joshi 氏が示した全体像はシンプルです。エージェント型AIには、明確に定義された目的、代表性のある評価データ、継続的なテスト、効率的なインフラ、そして展開の責任を負う名前のある人間の意思決定者が必要だ——ということです。
💼 事業会社視点：これは自社にどう効くか
示唆はシンプルで、多くの日本企業に痛いところです。「PoCは通ったが本番に出せない」の正体は、モデルの弱さではなく評価の不在。Waymoの基準に照らせば、テストが未成熟なプロジェクトは本番段階に達していないだけです。
ECな���、返品・不正・キャンセル交渉のようなレアだが金銭と法務が絡む会話をこそ評価セットに固定すべきです。SaaSのカスタマーサポート自動化なら、業界標準ベンチマークのスコアではなく、解約率・一次解決率・エスカレーション率という自社の事業成果に評価を紐づける。受託開発・SIerには商機と地雷が同時に来ます。「AIエージェント構築」ではなく「評価基盤とデータセット設計」を売れる会社が伸び、逆に納品時テストだけの契約は、モデル・業務プロセス・ユーザー行動・入力データが動いた瞬間に品質責任を負わされます。保守契約に継続評価の工数を最初から積むべきです。
役員が今週やることは3つ。第一に、稼働中のAI施策ごとに評価データの性質（誰の、いつの、どんな分布か）を1枚で出させる。測れていないなら性能報告は根拠がありません。第二に、失敗コストの高いレアケースを部門ごとに列挙させ、評価対象に加える。第三に、リリース承認者を実名で決める。Waymoが人命を理由に人間の承認を外さないのと同じ構造で、事業には信用と契約が乗っています。