ダッシュボードが嘘をつくとき：Google I/O 2026のエージェント検証

これはGoogle I/O Writing Challengeへの投稿です

月曜の朝です。1時間後にリーダーシップミーティングが始まります。セールスのダッシュボードは開いていて、数字は正常に見えます。そして誰も、大きな赤いエラーメッセージを見ていません。

ところが誰かが、最悪の可能性を告げます。

「この数字、正しくない気がします。」

それが起きた瞬間、ダッシュボードはダッシュボードではなくなり、調査になります。

たぶん更新日時のタイムスタンプは問題ないように見えるけれど、元データが遅れています。元のシステムには新しいレコードがあるのに、レポートがそれを除外しています。パイプラインは技術的には完了しているのに、重要な何かをスキップしました。あるいは、数字自体は正しいけれど、誰も気づかないうちにビジネス上の定義が変わったのかもしれません。

私はGoogle I/O 2026の間、そうした問題のことを考えていました。

Google I/Oにはもっと大きな出来事がたくさんありました：新しいGeminiモデル、反重力、マネージドエージェント、AI Studioのアップデート、Firebaseの改善など、エージェントで構築するための新しい方法がさらに増えたのです。ですが、私に残ったのは「エージェントができることが増えた」という点だけではありませんでした。Googleが、エージェントの周辺を構成する部品を一貫して見せ続けたこと――ツール、サンドボックス化された実行、デプロイ経路、リアルタイムデータ、そして承認の場面です。

それがビジネスシステムにとって重要です。

エージェントは、「賢そうに見える」から有用なのではありません。周辺のワークフローが、エージェントが正しいタイミングで確認し、説明し、そして止まるのを助けるときに有用になります。

私にとってのテストはシンプルです。

エージェントは、人々が誤った答えを信じる前に、壊れたダッシュボードの調査を助けられるか？

私の見方はビジネスシステム

私の見方は純粋なソフトウェアエンジニアリングではありません。私はビジネスシステムの周辺で仕事をしています。レポーティング、Salesforceのようなプロセス、データ品質、ワークフロールール、そして「システムはこう言っている」と「ビジネスはこう期待していた」の間の気まずい引き継ぎです。

だからエージェントのデモを見るとき、私は次だけを尋ねるのではありません。

「これでコードを書けますか？」

代わりに尋ねます。

「状況を悪化させずに、なぜその数字が間違っているのかを突き止めるのに役立ちますか？」

レポーティングの仕事では、「数字が間違っている」という言い回しには注意深くなるべきだと学びました。時には数字が古いことを意味します。時にはフィルターが間違っていることを意味します。時にはユーザーが別の定義を期待していたことを意味します。時にはデータ自体は正しいが、タイミングが合っていないことを意味します。

それらは別の問題です。それを1つの問題として扱うと時間を浪費します。

更新履歴ページで緑のチェックマークが付いていても、ビジネス上の問題が必ず解決したとは限りません。ダッシュボードは「動いている」のに、なお誤解を招くことがあり得ます。

だからこそ、ダッシュボードのインシデントはAIエージェントにとって良いテストになります。デモでは通常省略されがちな作業の要素――古いデータ、はっきりしない定義、権限、不確実性、ステークホルダーへのコミュニケーション――をきちんと扱うことを強制するからです。

小さな例：120万ドルの問題

セールスのダッシュボードに「今月の予約売上高が120万ドル（$1.2M）」だと表示されているとします。

セールス側は、今朝新たに3件のクローズ・ウォン（受注確定）案件が入ったので、数字はもっと高いはずだと言います。ダッシュボードの更新履歴では、レポートが午前8時10分に実行されたと表示されています。元のシステムでは、新しい案件が午前8時26分に更新されたことが分かります。パイプラインの状態では、最新の実行は完了したが警告付きだったと示されています。

明らかに燃えている場所はありません。

ダッシュボードは読み込まれます。

更新は実際に行われました。

元のシステムにはレコードがあります。

ミーティングはまだ1時間後に始まります。

これは、曖昧な自信が危険になりやすいまさにその地点です。「問題なさそうに見える」と言わせる必要はありません。必要なのは、問題を絞り込むことです。

ダッシュボードは古いのでしょうか。元データは更新後にリフレッシュしたのでしょうか。パイプラインは一部のレコードをスキップしたのでしょうか。レポートは新しい案件をフィルタリングしてしまっているのでしょうか。リーダーシップは現在の数字を使うべきか、それとも更新版を待つべきか。

それが「壊れたダッシュボード」テストです。

手作業版

現実の世界では、こうした確認が常に完璧な順序で行われることはほとんどありません。あちこち行ったり来たりします。ダッシュボードを開き、次に元のシステムを見て、更新履歴ページを確認して、場合によっては先週誰かが送ったスプレッドシートも開くのです。

作業の半分は技術的です。残り半分は、「間違っている」という言葉を人が実際にどういう意味で使っているのかを理解することです。

基本的なダッシュボード調査は、たとえば次のようになります。

大変なのは、人が待っている間にツールや状況（コンテキスト）を切り替えることです。あなたは「推測」から「事実」を切り分けようとしています。さらに、必要以上のパニックを生まないようにも気をつけます。

そこで、Google I/Oのエージェントの話が私にとって役立つようになりました。

エージェント版は、あえて退屈にすべきだ

私の心に刺さったGoogle I/O 2026の部分は、「モデルに質問する」から「エージェントに仕事・ツール・境界を与える」へと向かった点でした。

モデルは、古いダッシュボードが意味し得ることを説明するのに役立ちます。丁寧に設計されたエージェントなら、更新時刻を確認し、パイプラインの状態を調べ、いくつかのサンプルレコードを比較し、関係する人間向けに短い復旧メモを作ることができるでしょう。

ただし、エージェント版は次のようにはすべきではありません。

「AIに直させよう。」

それが、より大きな問題を生むやり方です。

有用なやり方は、もっと制御されたものになります。エージェントに調査を整理させ、証拠を集め、提案を準備させる。そして何をするかを決めるのは人間です。

ダッシュボードのインシデントでは、私はエージェントに次をしてほしいです。問題の要約、関係するシステムの特定、新鮮さ（フレッシュネス）の証拠の収集、ソースレコードとダッシュボード出力の比較、影響範囲の推定、復旧ブリーフの下書き。そしてリスクのあるアクションを行う前に承認を求めること。

最後の点は飾りではありません。有益な自動化と無謀な自動化を分ける境界です。

エージェントがリフレッシュ失敗を見つけたなら、再実行を推奨できます。ミスマッチを見つけたなら、起こり得る原因にフラグを立てられます。メッセージの下書きを作れるなら、それも素晴らしいです。ですが、本番データの変更、レポートロジックの編集、プロセスの無効化、主要なワークフローのトリガーといったことは、人間の判断が必要です。

目標は、盲目的な自律ではなく、より速い証拠です。

なぜFirebaseのデモが私にとって重要だったのか

この考え方に意外とぴったり当てはまった「I/Oの一瞬」は、Firebase SQL Connect のリアルタイムデモでした。デモ自体は遊び心がありましたが、見覚えのあるパターンでもありました。つまり、データが変わってもアプリはすぐにその変更を反映せず、そしてリアルタイム同期によって更新がユーザーに届くまでの改善が行われた、というものです。

それは、まさにダッシュボード問題を小さくしたものにほかなりません。

多くのビジネスユーザーは、その問題を「同期の問題」「リフレッシュの問題」「データモデリングの不一致」だとは説明しません。彼らはただこう言うでしょう：

「これ、間違っているように見える。」

優れたエージェントのワークフローは、この曖昧な一文を実際にテスト可能な確認事項へと翻訳できるべきです：

• ダッシュボードは最後にいつリフレッシュされましたか？

• 参照元のシステムは新しいレコードを受け取りましたか？

• パイプラインは完全に実行されましたか、それとも部分的にしか実行されていませんか？

• 不足しているレコードは本当に「欠けている」のか、それともフィルタで除外されているだけですか？

• 会議の前に、誰に警告が必要ですか？

価値は、漠然とした不満を、誰かが確認できるチェック項目へと変えることにあります。

リカバリブリーフも重要

調査は仕事の半分にすぎません。もう半分は、技術的なノイズを必要としていない人たちにそれを浴びせるのではなく、「その数字を信頼できるかどうか」を伝える形で説明することです。

役に立つリカバリブリーフは、何が起きたのか、確認できたことは何か、まだ不確かなことは何か、誰に影響がある可能性があるか、推奨されるアクションは何か、そして次の更新はいつ届くのかを説明すべきです。

それは簡単そうに聞こえますが、圧力がかかると「書きすぎる」「書かなすぎる」、あるいはそもそも「違うことを書く」ことは起こりやすいです。

これは見過ごされがちなエージェントのユースケースです。エージェントが証拠を集めて落ち着いた最初の版を下書きできれば、アナリストは、空白のメッセージから始める代わりに、状況の判断により多くの時間を使えます。

人がレビューできる材料を提供してくれます。

私の注意：調査とアクションは別の仕事

ここで私は慎重になります。

ダッシュボードの調査エージェントには、管理者と同じ権限を与えるべきではありません。何か怪しいものを見つけたからといって、報告のロジックをこっそり書き換えたり、生産環境のデータを変更したり、ワークフローを起動したりできてはいけません。

調査とアクションは別の仕事です。

デモを滑らかにするからといって、管理者レベルのアクセスを持つエージェントを作りたいとは思いません。便利さは権限モデルではありません。

この種のワークフローでは、まずは読み取り専用のエージェントから始めたいです。証拠を集め、発見を要約し、次のステップを推奨できるようにします。書き込みアクションが必要な場合は、承認を明示的に求めるべきです。

読み取り専用が最初というのは制約ではありません。それが信頼を築く方法です。

エージェントを、ビジネスのシステムワークフローのどこかに近づける前に、まずは次の質問をします：

このエージェントの最悪の形は、自信満々に推測してしまうものです。最良の形は、慎重に探索範囲を絞り込むものです。

最終的な要点

私の最大の Google I/O 2026 の学びは、「エージェントは強力だ」ということではありません。そんなことはもう分かっています。

難しいのは、状況がごちゃごちゃしていて、時間に制約があり、しかも半分しか真実がなくても、エージェントが役に立てるのかどうかという点です。

私にとってのテストはシンプルです：

エージェントは、パニックから証拠へと移行するのを助けられますか？

もしダッシュボードが嘘をついているなら、自信たっぷりに聞こえるエージェントは必要ありません。必要なのは、正しい場所をチェックし、見つけたものを示し、まだ不確かな点を説明し、危険なことをする前に止まってくれるエージェントです。

私は、そのエージェントを信頼したいと思います。判断を置き換えるのではなく、意思決定が行われる前に人々が証拠に到達するのを助けるエージェントです。