意思決定、全社浸透、Shadow AI、データ基盤、Tokenomics――Agentic AI Summit '26 Fall Day1 Track 3・4レポート

日本テレビ「ミカタッチAI」セッションの登壇風景。
現地撮影／Day1

Day1 Track 3・4で前面に出たのは、「AIを導入した後」の問題だった。

日本テレビ、電算システム、TAPP、読売広告社。そしてGemini agent、Shadow AI、SOAP Architecture、JAL、Tokenomics。9セッションを追うと、企業AIの論点がモデル性能から、意思決定、定着、権限、データの意味、コストへ移っていることが分かる。

日本テレビ――AIで「考える仕事」を減らすのではなく増やす

日本テレビの「ミカタッチAI」は、番組制作の判断を支えるためのデータエージェントだ。視聴データを集計するだけでなく、質問を分解し、必要なデータを取り出し、番組ごとの分析観点に沿って考察する。人間が分析時に踏んでいたステップ自体をエージェントへ渡している。

このセッションで重要だったのは、「最終回答が合っているか」だけを見ない姿勢だ。AIの回答が誤っていた場合、どのデータを使ったのか、どの定義で計算したのか、どの段階で判断を誤ったのかを切り分けられなければ改善できない。データエージェントを本番で育てるには、中間過程を追える設計が必要になる。

そして導入後、人間の仕事が減ったとは限らない。分析できる範囲が広がったことで、以前は見切れなかった情報が見えるようになり、「では何を意味するのか」「次に何を検証するのか」と考える回数が増えた。効率化によって考える仕事を消すのではなく、仮説検証の密度を上げる使い方だ。

詳しく読む：日本テレビの「ミカタッチAI」で、人間が考えることはむしろ増えた

電算システム――AIリテラシー格差を埋め、自走する組織を作る

電算システムのテーマは「AIリテラシー格差」だった。社内には、新しいAIを自分から試す人、必要性は感じているが使い方が分からない人、時間や心理的な抵抗からほとんど触れていない人がいる。全社一斉にツールを配っただけでは、この差は縮まらない。

同社は社内外でAI活用定着支援を行い、研修満足度96.7％、エージェント関連資格の保有者123名という実績も紹介した。ただし、資格や座学だけをゴールにはしていない。全社研修の後に、各部門が自分の業務を棚卸しし、「どの仕事ならAIを使えるか」をグループで考える場を作る。

業務棚卸しでは、作業時間や頻度も書き出す。AIで効率化できたとき、何時間削減できたかを測れるからだ。3時間程度のワークショップを通じ、既に誰かが使っている方法を共有したり、新しい活用案を見つけたりする。結果として、研修が「使い方を教える場」から「自社業務をAI前提で見直す場」へ変わる。

さらに、推進者・相談窓口・社内事例集などを用意し、使い始めた人が孤立しないようにする。組織のAI格差を埋めるには、初心者向けの導線と、先行ユーザーが周囲を引っ張る仕組みの両方が必要になる。

TAPP――500超のエージェントより重要な「使われる状態」

USEN Smart WorksとTAPPの対談では、Gemini Enterpriseを使った全社浸透が扱われた。目を引くのは500を超えるAIエージェントという数だが、本質は「現場が自分で作る側へ回った」ことにある。

非エンジニアを含む社員が業務課題に合わせてエージェントを作れるようにし、開発者的な役割を担う社員も約200人規模まで広がった。中央のIT部門がすべての要望を受けて作る方式では、現場の細かなニーズへ追いつかない。安全に試せる基盤とルールを用意した上で、作る力を分散した。

定着状況を示す社内アンケートでは、週1回以上の利用率92.0％、定常業務へ組み込み済み82.3％、Gemini利用率94.7％。重要なのは、ログイン数ではなく、仕事の中に入っている割合が高いことだ。

AI活用では「導入した」「アカウントを配った」「エージェントを何個作った」という数値が先行しやすい。TAPPの事例は、成果指標を「実際の業務に組み込まれたか」へ置き直している。

読売広告社――M365を残し、GeminiをAIの入口にする

読売広告社はMicrosoft 365を利用している。そのため「既存環境があるのに、なぜGeminiも全社導入するのか」がセッションの出発点だった。答えは置き換えではなく、接続にある。

M365、BigQuery、独自の調査データなど、仕事に必要な情報は複数のシステムへ分散している。Gemini EnterpriseをそれらへアクセスするAIの入口として置き、現場から見れば一つの場所から必要な情報を引き出せる状態を作る。既存SaaSを全部捨てて統一するのではなく、AIレイヤーでつなぐ発想だ。

導入ではタスクフォースを組成し、社内ポータルや支援体制も整えた。3カ月で約5,500時間の業務時間削減、700を超える「市民開発型」のAIエージェントが生まれたという。現場が自分の業務をよく知っているからこそ、小さなエージェントが多数生まれる。

ここでも「作れる基盤」と「使われる仕組み」は別だ。全社の入口を分かりやすくし、学習機会、ルール、事例共有を整えることで、AIの利用者を作り手へ変えている。

読売広告社とG-genによるGemini全社展開セッションの登壇風景。
現地撮影／Day1

詳しく読む：読売広告社はM365をやめずに「つなぐ」道を選び、Geminiを全社のAIの入口にした

Gemini agent――自律性が上がるほどIDと監査が必要になる

Track 4では、10月8日に発表されたGemini agentの技術的な裏側が扱われた。Geminiは質問へ答えるだけでなく、仕事の目的を受け取り、Skillsやツールを使い、必要なシステムへ接続して成果物まで持ってくる「業務のための汎用エージェント」へ広がっている。

自律性が高まると、従来のチャットAIにはなかった管理が必要になる。Google Cloudは「そのエージェントは誰か」「何をしてよいか」「何をしたか」「絶対に触れてはいけないものは何か」という4つの問いを企業ガバナンスの中心に置いている。

各エージェントが独自のアイデンティティを持ち、最小権限で動き、行動が監査ログへ残る。外部システムへ接続するときも、誰の権限で実行したかを追えるようにする。エージェントを「ユーザー本人の見えない代理」ではなく、独立した行動主体として扱う考え方だ。

この設計は、翌日のProduction ArchitectureやKaz Sato氏のAsk the Speakerでも繰り返された。本番化するほど、モデルよりID・権限・監査が重要になる。

Shadow AI――禁止ではなく、安全な経路へ誘導する

生成AIが普及すると、会社が正式導入していないAIサービスを社員が使う「Shadow AI」が避けにくくなる。問題は、利用実態が見えないまま機密情報やファイルが外部へ送られることだ。

セッションでは、ブラウザを制御点にし、AIサービスへのアクセスを可視化し、承認済みサービスへ誘導する方法が紹介された。必要に応じてコピー＆ペーストやファイルアップロードなどの操作を制限する。ネットワークで全部ブロックするよりも、ユーザーの行動に近い場所で守る。

ここでの発想は「AIを使わせない」ではない。安全に使えるAIを正式に用意し、危険な経路だけを制御する。Shadow AIはセキュリティ問題であると同時に、正式なAI環境が現場のニーズを満たしているかというUXの問題でもある。

SOAP Architecture――AIへデータではなく「意味」を渡す

SOAP Architectureのセッションは、AIエージェントとデータ基盤の関係を「接続」ではなく「意味」から捉え直した。AIにBigQueryやデータベースへの権限を与えても、「売上とは何か」「顧客とは誰か」「この指標はどの条件で計算するか」は分からない。

人間のアナリストは、指標定義、業務ルール、データの由来を知っている。AIにも同じ文脈を渡すために、セマンティックレイヤー、メタデータ、ナレッジ、リネージを組み合わせる必要がある。セマンティックレイヤーを「計算式集」だけにせず、業務の意味を共有する層として扱う。

米国時間10月29日（日本時間10月30日）、Knowledge Catalogでは複数のセマンティックモデルを一つのコンテキストグラフへ取り込む機能がGAとなった。Looker、BigQuery、dbt、Snowflake、Databricks、SAPなどで定義済みの指標を、エージェントが共通の文脈として使う方向だ。

AI時代のデータ基盤では、データ量や検索速度だけでなく、「企業内で同じ言葉を同じ意味で使えるか」が精度を左右する。

詳しく読む：AIに「売上とは何か」を教えるのは、エンジニアではなく業務と経営の仕事だ

JAL――自律実行を広げながら、人の承認を残す

JALグループは、AIエージェント活用を段階的に広げる構想を示した。最初は検索・要約など人を支援する利用から始め、将来的にはエージェント同士が連携し、必要な仕事をより自律的に進める方向へ進む。

ただし、目標は「人を完全に外す」ことではない。エージェントが自律して処理できる範囲を増やしながら、重要な実行には人間の承認を残す。個人情報や機密情報を扱う場合は、データのフィルタリング、実行範囲の制限、履歴の記録などをガードレールとして組み込む。

AIエージェントは、便利なほど危険になり得る。検索だけなら誤回答で済むが、予約、登録、更新、送信などを自律実行すれば、誤りが業務結果へ直接反映される。そのため「どこまで自動で進め、どこで人へ戻すか」を先に決める必要がある。

JALグループのAIエージェント活用セッション。
現地撮影／Day1

詳しく読む：JALはAIエージェント選びで、情報の守りと人の承認を譲らなかった

Tokenomics――モデル単価ではなく総コストで考える

AIモデルのトークン単価は急速に下がっている。一方、エージェントは計画、検索、ツール実行、確認、再試行を繰り返すため、一つの仕事あたりのモデル呼び出しが増える。単価が下がっても、利用量が増えれば総支出は増える。

セッションでは、日常的なループの70〜80％ほどは最上位モデルを必要とせず、高い推論能力が必要な処理はごく一部という整理が示された。そこで、処理の難易度に応じてモデルを使い分け、UI・エージェント・モデルを疎結合にする。モデルの進化が速いからこそ、特定モデルへ固定しない。

Smart Gatewayのようなルーティングを使い、品質を維持しながら軽量モデルへ流す。紹介された事例では、総コストを67〜70％削減しつつ、品質98.9％を維持したとされた。この98.9％は品質維持率であり、モデル単価の下落率とは別の数字だ。

コスト管理は経理部門だけの話ではない。どの処理にどのモデルが必要かを判断するには評価データが要る。つまりTokenomicsは、評価設計とアーキテクチャ設計の問題でもある。

AIエージェントのコスト設計を扱ったTokenomicsセッション。
現地撮影／Day1

詳しく読む：単価は98％下がったのにAIの支出は増える、だから最上位モデルは要所にだけ使う

Day1 Track 3・4の結論――企業AIは運用設計の問題になる

Track 3・4の9セッションを並べると、モデル性能の話だけでは説明できない論点が増えていることが分かる。意思決定、全社浸透、教育、権限、Shadow AI、データの意味、人間承認、コスト。AIエージェントが企業へ入り込むほど、周辺の設計が重要になる。

日本テレビではAIが「考える回数」を増やし、電算システムは定着のための教育・伴走を扱った。TAPP、読売広告社では、実際に使われる状態を作る難しさが見えた。Track 4では、その利用を安全に支えるID、データ、ガバナンス、コストが前面に出た。

つまり、企業のAIエージェント競争は「一番賢いモデルを持つ会社」が勝つという単純な話ではない。AIを仕事へ接続し、安全に運用し、改善し続ける仕組みを持つ会社が強くなる。