参加者約 5,000 人が UC Berkeley に集結 — Agentic AI Summit 2026 参加レポート

こんにちは、AIドリブン推進室の神谷( @_yukamiya )です。

2026 年 8 月 1 日〜2 日に UC Berkeley（米国カリフォルニア州バークレー）で開催された「Agentic AI Summit 2026」に、当社Developer Expertsの原、降矢とともに参加してきました。開発組織における AI 活用を推進する立場として、特定ベンダーの製品発表に紐づかない、Agentic AI そのものをテーマにした国際カンファレンスの現地の空気を掴むことが目的です。

このサミットは、規模と登壇者の顔ぶれに対して日本での知名度がまだ低く、日本語の参加レポートもほとんど見当たりません。そこで本記事では、サミット自体の紹介を厚めにしつつ、現地で見聞きしたセッションの内容をできるだけ具体的にお伝えします。長編ですが、Agentic AI の「いま」を一望できる内容になっているはずです。

Agentic AI Summit 2026 とは

Agentic AI Summit は、UC Berkeley の研究センター Berkeley RDI（Center for Responsible, Decentralized Intelligence）が主催する Agentic AI 専門のカンファレンスです。共同ディレクターを務める Dawn Song 教授が今回も自ら Keynote とパネルに登壇していました。

このサミットの特徴を一言でいえば、「主催がイベント会社でも特定ベンダーでもなく、大学の研究センターである」ことです。そのため特定製品の発表会という色がなく、研究者と実務者が同じ壇上に並ぶ構成になっています。

• 会期・会場: 2026 年 8 月 1 日〜2 日、UC Berkeley キャンパス
• 規模: 現地参加者約 5,000 人＋グローバルライブ配信、登壇者 150 名以上（公式ページの事前見込みに加え、Day 2 の開会挨拶でも「close to 5,000 in-person attendees」と当日報告されていました）
• 参加費: 1 名 399 ドルから（複数ティアあり）
• 公式ページによれば前回 2025 年は現地 2,000 人以上。今回の約 5,000 人は約 2 倍の規模

もうひとつ面白いのは、母体に学習コミュニティがあることです。Berkeley RDI が運営する Agentic AI の MOOC シリーズには世界で約 4 万人の受講者がおり、このサミットはその年次集会という性格を持ちます。単発のイベントではなく、通年で動いているコミュニティのオフライン集会と捉えると位置づけが分かりやすいと思います。

登壇者の顔ぶれ

登壇者 150 名以上のラインナップは第一線の当事者揃いです。一部を挙げると次のような顔ぶれでした。

• Peter Steinberger 氏（OpenClaw 作者、OpenAI）
• Silas Alberti 氏（Cognition, SVP of Research）
• Eno Reyes 氏（Factory AI 共同創業者・CTO）
• Alex Graveley 氏（GitHub Copilot 共同開発者、FlyingObject.ai 共同創業者）
• Ryan Lopopolo 氏（Google Cloud, Principal Engineer）
• Michele Catasta 氏（Replit, President）
• Wojciech Zaremba 氏（OpenAI 共同創業者）
• Oriol Vinyals 氏（Google DeepMind, VP of Research）
• Milad Nasr 氏（Anthropic, Research Scientist）
• Andrew Ng 氏（DeepLearning.AI 創業者）
• Woosuk Kwon 氏（vLLM 共同開発者、Inferact 共同創業者・CTO）
• Ali Ghodsi 氏（Databricks 共同創業者・CEO）
• Dawn Song 氏（UC Berkeley 教授、Berkeley RDI 共同ディレクター）

このほか Amazon、Microsoft、NVIDIA、Scale AI、Snowflake、HubSpot、Uber、LinkedIn、IBM、Waymo など、モデル開発企業からエンタープライズの実践企業、ロボティクスまで幅広いレイヤーの登壇がありました。

4 つの並行ステージ

会場はキャンパス内の 4 つの並行ステージ制で、役割分担が明確でした。

• Plenary: ビッグネームによる Keynote・パネル（OpenAI、Google DeepMind、NVIDIA、Amazon、Microsoft など）
• Atlas / Compass: スタートアップや現場メンバー中心の実践事例。エンタープライズ導入・評価・システムの具体論
• Nexus: 研究寄り（AI for Science、Secure Agentic AI、Coding & Web Agents など）

このほかスポンサー各社によるハンズオン形式の Workshop、Poster Presentations、スタートアップ 12 社によるピッチ（Startup Spotlight）がありました。

現地の様子

セッション形式には特徴があります。各講演は 10 分程度と短く、密度の高いトピックが次々と流れていきます。資料は作り込まれているのに発表は要点のみで終わるため、深掘りはアーカイブで補う前提の設計です。その分、2 日間で浴びられる情報量は相当なものでした。

セッション視聴と同じくらい価値があったのが「Ask the Speaker」の導線です。講演直後の登壇者に直接質問できる場が用意されており、著名企業のエグゼクティブにその場で疑問をぶつけられます。オーディエンスの質問の質も総じて高く、第一線の当事者に直接アクセスできる密度はこの規模の国際カンファレンスならではだと感じました。

ポスターセッションも広いエリアで展開されており、agentic coding のトークン消費分析のような実務直結のものから、ポスター前でロボットがダンスを実演する Robotics 系まで多彩でした。屋外広場では全員分のランチボックスが一斉配布され、そのままネットワーキングが始まる、キャンパスらしいおおらかな運営です。

セッションレポート

ここからが本題です。現地で見聞きし、アーカイブと突き合わせて確認したセッション内容を、6 つのテーマに整理してお伝えします。

先にお断りを 1 つ。 私たちは自分たちのミッション（開発組織の AI 活用推進）に直結する Enterprise AI・評価基盤・Coding agent・セキュリティ系のセッションに優先度（P0/P1）を付けて参加しました。そのため以下のレポートはアプリケーション寄りのレイヤーに偏っています。サミット全体では Robotics & World Models、AI for Science、AI for Math、金融・ヘルスケアといった領域のセッションも熱量が高く、それらを含む全セッションが Berkeley RDI の公式サイトから YouTube アーカイブで視聴できます。本記事はサミットの一断面だと思って読んでください。

テーマ 1: 現地の共通言語は「ハーネス」

会期を通じて繰り返し耳にした語彙が harness（エージェントに与えるツール・コンテキスト・ガードレールなどの実行基盤）でした。単なるバズワードではなく、実装の粒度で語られていたのが印象的です。

Google Cloud の Ryan Lopopolo 氏（前職は OpenAI）は「Harness Engineering: How to Build Software When Humans Steer and Agents Execute」と題した講演で、Capability Overhang（モデル能力の未活用） という枠組みを提示しました。モデルはすでに現実世界に影響を与えるだけの能力を持っているが、オペレーターや組織にとってのコンテキストが不足しているため活用しきれていない。人間の役割は、エージェントにツール・コンテキスト・ガードレール・コーチング・信頼を提供することだ、という整理です。組織が持つ希少リソースを「人間の時間」「エージェントとの協力」「知識資産」の 3 つと定義していたのも示唆的でした。

LinkedIn の Ankit Goyal 氏は「Harness as Code」というアプローチを紹介しました。長時間稼働のエージェントでは自然言語プロンプトによる制御が機能しなくなるため、各ステージの責務とスコアラー・評価器をコードで定義し、reward hacking や経路逸脱を防ぎます。エージェントが生成したコードは untrusted 扱い（外部への egress なし、クレデンシャルへのアクセスなし、プロキシ経由）にするという運用も紹介されました。同社の発表によれば、本番稼働する 400 超の TensorFlow モデルを PyTorch へ移行するために、この agentic workflow を開発しているとのことです。

一方で反対意見も明確にありました。Omokai の Krishnakumar Sharma 氏（元 Amazon の AI 責任者）は「数百のエージェントを走らせる agent swarm や、ループの中にループを重ねるような設計はコストとエラーを増やすだけ」と批判し、エージェントは 4 個程度の well-defined なものに絞るべきだと主張していました。ハーネスの語彙は共通でも、その厚みについては現地でも議論が割れています。

テーマ 2: Eval（評価基盤）— 最も具体的な知見が集まった領域

2 日間で最も繰り返されたメッセージを 1 つ挙げるなら、これです（複数の登壇者の主張を筆者が要約したものです）。

エージェント導入のボトルネックは、モデルの性能でも技術でもなく、評価基盤と組織である。

Ema の Surojit Chatterjee 氏は「導入を止める要因の 70% は組織的なもの」と述べ、Mercor の Adarsh Hiremath 氏は「プロジェクト失敗の第一要因は agentic な eval の欠如」と断言しました。複数の登壇者が「ほとんどの AI プロジェクトは成果に至っていない」という文脈で MIT NANDA の「95%」や Gartner の「50%」という数字を引用していたのも印象的です（原典を確認すると、前者は生成 AI パイロットの 95% が測定可能な P&L 効果を示せていないという報告、後者は生成 AI プロジェクトの少なくとも 50% が PoC 後に中止されるという予測で、登壇者による要約とは少しニュアンスが異なります）。

具体的な実践知も豊富でした。特に面白かったものを紹介します。

Uber の「ピザ」事例（Aayush Agrawal 氏の発表より）。ライドの音声予約エージェントはオフライン評価で 95% 以上のスコアを出していましたが、本番でセッションあたりターン数の異常を検知。調査すると、背景で聞こえた「ピザ食べたい」という声を拾って、最寄りのピザ屋に行き先を変更していたことが分かりました。必要だったのは真の意図理解と「反応しない」という判断で、本番評価とプロダクトチームの関与がなければ見つからなかったと言います。同社ではどのチームも「まずエージェントを出荷、eval は後で」と判断して後付けの無限ループに陥った経験から、開発初日からのトレーシング標準装備や evaluator の自動提案など、eval をデフォルト化する仕組みをプラットフォームとして整備していました。

Postman の依存チェーン計測（Zelin Wan 氏）。単発の API タスクなら軽量モデルでも 88〜97% で「解決済み」に見えるのに、依存関係のあるタスクチェーンに繋ぐと成功率が 44〜73% に急落します。タスク自体が難しくなるのではなく、序盤の小さなミスが後段を壊すのが原因だといいます。19 モデル×約 44,000 トライアルの結果とともに、「質問に答えられるか」ではなく「長い依存チェーンで正しさを維持できるか」が本番の問題だと示していました。

Redis の trajectory 評価（Srijith Rajamohan 氏）。失敗を correctness / completeness / usefulness / efficiency の 4 つに分類し、特に efficiency の失敗（重複読み取り・後戻り・行き止まり探索によるトークン浪費）は最終結果に現れず、経路（trajectory）を見ないと分からないと指摘。生ドキュメントを診断プレイブックに再構成した結果、総トークン 43% 削減・総エラー率 48% 削減を達成したと発表していました。興味深い発見として、ドメイン知識で絞った最小ツールセットと、その上位互換の full セットを比較すると、full の方が遅く品質もわずかに悪かったそうです（tool overload の実証）。

IBM Research の ScarfBench（Rahul Krishna 氏）。エンタープライズ Java の移行タスクで、エージェントは「コンパイル・デプロイが通る」移行は得意な一方、挙動が完全一致したのは 2〜14% のみ。「コンパイル成功は弱いシグナル（できた気にさせるだけ）」という言葉は、コーディングエージェントを使うすべての人に刺さる指摘だと思います。

Scale AI の deterministic core（Yuan Xue 氏ほか）。非決定的な LLM 出力の品質担保という難題への最も直接的な回答でした。油井ケーシング設計エージェントでは、数値計算をすべて物理シミュレータと人間のエンジニアが担う決定論的コアとして切り出し、エージェントには計算を一切させない設計で数値忠実度 100% を実現したと同社は報告しています。また既存ベンチマークについて「あれは人間トップとのギャップ（天井）を測る開発者向けの道具で、企業に必要なのはスコアではなく deployment readiness」と喝破し、経営層は text-to-SQL に 99% の信頼性を求めるがベンチマーク SOTA は 60〜70% という現実とのギャップを示していました。

Replit の continual learning（Michele Catasta 氏）。毎日数百万のエージェントトレースをクラスタリングして異常を検出し、フロンティア LLM で問題箇所を特定して自動で修正 PR まで生成するパイプラインを 6 か月以上稼働させていると Catasta 氏は述べていました。「evals をリリース前のチェックゲートではなく、継続的改善のエンジンとして使え」というメッセージは、Uber の取り組みとも綺麗に重なります。

モデルレイヤーのコモディティ化を主張する登壇者が多かった会場の空気に立てば、「評価基盤と組織設計に先んじて投資した企業が抜け出せるフェーズにある」——というのが、複数セッションを貫く含意だと感じました。

このテーマのセッションは Compass ステージ Day 2 のアーカイブでまとめて視聴できます。

テーマ 3: モデルルーティングとトークン効率

「適材適所でモデルを使い分ける」ことを前提にしたセッションが目立ちました。背景にはコストの現実があります。DigitalOcean の Debarshi Raha 氏によれば、Uber は年間の agentic AI 予算を 4 か月で使い切り、Walmart も AI 支出に上限を設けたそうです。

同氏が紹介した Inference Router は、クライアントとモデルの間に入るサーバーサイドのルーターで、ルーティング専用に purpose-built した 30B モデルとプロキシで構成されます（両方オープンソース）。法務 AI スタートアップで推論コスト 40〜50% 削減という同氏が紹介した実績とともに、実装上の急所として cache-aware routing を挙げていました。エージェントループの途中でモデルを切り替えるとウォームキャッシュ（prompt caching の恩恵）を失うため、キャッシュを意識したルーティングが必要になる、という論点です。ルーティングと prompt caching の両立は私たちも気になっていたポイントで、すでに論点化され解かれつつあることが確認できたのは収穫でした。

IBM Research の Open Agent Leaderboard も実務的でした。任意の agent harness × モデル × ベンチマークの直積で平均成功率とコストを算出し、Pareto frontier から要件に合う構成を選べる形にしています。知見として「品質は主にモデルで決まるが harness の影響もあり、スコアが同等でも挙動は異なる。安く速く失敗する構成と、高くついて失敗する構成がある」「特定の harness とモデルの組み合わせには相性があり、open weights モデルは harness への感度が高い」などが共有されました。

Ema の Chatterjee 氏は「モデルレイヤーはコモディティ化が進み、100 以上のモデルを混ぜる model fusion が標準アーキテクチャになる。重要なのは open か closed かではなく、モデルを差し替えられる設計になっているか」と主張していました。

テーマ 4: ガバナンス・セキュリティ — 抽象論から設計論へ

セキュリティ系のセッションは、攻撃面のカタログと防御側の設計論がセットで語られ、非常に具体的でした。

攻撃側で圧巻だったのは Intuit の Itsik Mantin 氏による「When Good Agents Go Rogue」です。prompt injection のエージェント版を OWASP は agent goal hijacking と呼びますが、その侵入経路（poison の運び手）として、未承諾のメール、カレンダー招待のタイトルやメモ、組織外から共有されたドキュメント、画像内の極めて薄い色の不可視テキスト、人間には聞こえずエージェントには聞こえる周波数の音声コマンド、autonomous browsing のスクリーンショットに写り込む広告——と、「頼んでいないのに届くもの」すべてを列挙していきます。「ダウンロードした skill はツールと指示の集合であり、実行ファイルをダウンロードするのとほぼ同じ」「MCP サーバはツール説明文に poison を仕込める」という指摘や、ファイル書き込み能力を使って human-in-the-loop 必須のセキュリティ設定ファイル自体を書き換えて無効化する攻撃例など、エージェントを日常的に使う組織なら全員が知っておくべき内容でした。Simon Willison 氏の lethal trifecta（untrusted data の取り込み・機密データへのアクセス・外部通信の 3 つが揃ったら危険域）はここでも参照されていました。

Palo Alto Networks の Mohamed Nabeel 氏の研究も不気味な実測でした。LLM が hallucinate した（実在しない）ブラウザ拡張機能を継続監視したところ、調査後に約 12 件が実際に登録され、悪意ある活動に使われたことを確認したそうです。LLM の勧めるものを先回りして本物として登録する、サプライチェーン攻撃の新しい形です。

防御側の設計論も進んでいます。

• Credo AI（Eric Aldana 氏）: 人間は権限を段階的に獲得する（インターンは限定的なアクセスから始める）のに、エージェントはデプロイした瞬間に全権限を得ることが多い。これは design error である——として、Can（技術的にできること）/ May(今この文脈で許可されていること) / Act（人間を待たずに行使できる自律性）の 3 層で権限を管理する枠組みを提案
• Thales Group（Jon-Rav Shende 氏）: 「observability は governance ではない」。見えることと、control path 上で執行できることは別物。全エージェントの declared authority（宣言された権限）をデータベース化し、実行時の observed との差分を allowed / approved / drift / control failure に分類して、control failure を最重要メトリクスとして監視する
• Google Cloud（Rao Surapaneni 氏）: エージェントを「インターン」として捉え、全エージェントに固有の agent identity を発行して既存 IAM と連携。「休暇残高の参照は許可、給与の更新は不許可」といったタスク対応の細粒度制御に加え、「エージェントをクビにできるのか」というアカウンタビリティの問いも提起
• Vanguard（Lovedeep Gondara 氏）: 「推薦を hallucinate するモデルは迷惑にすぎないが、それに基づいて行動するエージェントは liability（法的責任）である」

このテーマは Nexus ステージ Day 1 午後のアーカイブで視聴できます。

テーマ 5: Self-improvement / RSI — モデル層から製品層まで

self-improvement（自己改善）や RSI（recursive self-improvement）は、研究レイヤーだけの話題ではなく、あらゆるレイヤーで語られていました。

Google DeepMind の Oriol Vinyals 氏は、RSI のループ（アイデア生成 → 実装 → テスト → 評価）のうち、進んでいるのは実装フェーズと実験・デバッグで、遅れているのはアイデア生成フェーズと評価フェーズだと現在地を整理しました。「真の RSI の実例はまだ存在しない」という冷静な見立てです。

その「アイデア生成」の通念を揺さぶったのが Anthropic の Milad Nasr 氏の発表です。発表週に公開したばかりの研究で、Claude に暗号解析を end-to-end で実行させ、10 ラウンドの AES-128 を 7 ラウンドに縮小した学術的設定への新攻撃を発見しました（発表動画）。計算量評価では既存最良の約 2^99 に対して約 2^89 と、約 200〜800 倍高速と見積もられています。ただし約 2^105 の選択平文を要する理論上の攻撃であり、現実の AES やインターネットの安全性を破る実用的な攻撃ではありません（この位置づけは暗号研究者 Matthew Green 氏の解説が参考になります）。著者は 2 名のみで、どちらも暗号解析の専門家ではないとのこと。過程が興味深く、モデルは 3,000 超のアイデアを生成し、適用可能なもの 2,000 超、novel なもの約 200、最終的に論文に載ったのは 4 つ。「アイデアは安く、実行がすべて」という通念が逆転しつつある、と締めていました。

Scale AI の Chenguang Wang 氏は、RLHF から rubric-based RL への研究トレンドを紹介。コーディングや数学のような検証可能領域を超えて、検証器のないオープンエンド領域に RL を効かせるため、評価基準（ルーブリック）を検証に変換し、ポリシーの成長に合わせてルーブリック自体を更新する「オンラインルーブリック進化」に取り組んでいるそうです。下位レイヤ（モデル訓練）の評価手法が上位レイヤ（アプリケーション）にも応用できそうだという意味で、テーマ 2 の eval の話と地続きの内容でした。

テーマ 6: Coding agent とエンジニアの役割変化

Day 1 Plenary の「Future of Software Engineering」は今回の目玉セッションの 1 つでした。

OpenClaw 作者の Peter Steinberger 氏（OpenAI)の講演「No Doors for Agents」は、プロダクト作りの思考プロセスとして秀逸でした。現在のテキストボックス型 UI を「テレビでラジオ番組を放送していた時代」になぞらえ、ターミナル → スーパーアプリ → AgentOS → サイドバーと様々なフォームファクターを試した末に、理想のエージェントは「見えない存在」——常にバックグラウンドにいて、どこからでも呼び出せ、会話の自然な流れに参加する——という結論に至ったと言います。「OS はまだエージェント向けのドアを持っていない。だからこそ、ドアを建てる今が面白い」というフレーズが印象的でした。

Cognition の Silas Alberti 氏は、「RL は頭打ち」という言説に対して、ボトルネックは entropy collapse（RL の group 内の多様性喪失）だと特定し、米国の訓練クラスタと世界各地の rollout クラスタを非同期 RL で接続して 4 か国 3 大陸にまたがる訓練を実施した話を紹介。「進歩の多くは新奇なアイデアではなく、シンプルなことをスケールさせて実行し切ること」という総括はモデル開発の現場感そのものでした。

エンジニアの役割変化については、複数のセッションが同じ方向を指していました。

• Factory AI（Eno Reyes 氏）: 人間の新しい役割は工場の process control のように、失敗を観察し、介入し、ワークフローを反復改善すること。code review では、判断基準となるメトリクス（バグ数、インシデント、MTTR）を定めた上で、人間レビューなしでマージする PR の割合を 5% → 10% → 50% → 100% と段階的に拡大していくアプローチを提示
• Microsoft（Zero Ops）: 「人間を operations から排除する」のではなく「operations を人間から取り除く」。人間は diff ではなく outcome をレビューする
• パネルディスカッション: プロンプティング（エージェントとの共同作業）のセッション時間は以前は 30 分程度だったが、現在は 5〜10 時間、場合によっては 20 時間規模に拡大している。新しいモデルが出たときの評価方法として「過去 3 か月で自分が作った 20 種類程度のバリエーションのタスクで検証する」が推奨アプローチとして挙がった

エンタープライズ導入の文脈では HubSpot の 3 年間の歩みが最も具体的でした。agent harness（コンテナ化されたサンドボックスで人手を介さずテストループを回す実行基盤）を先に構築し、AI 利用をエンジニアに強制せず「コード生成を導入しても信頼性は中立（現在はむしろ向上)」というデータで自発的採用を促したそうです。同社が紹介した社内指標では、AI 利用率は 80% → 96% → 100% と推移し、velocity は 51% → 60% 改善、PR への最初のフィードバックまでの時間は 90% 削減。「共有基盤は後回しにせず、最初に構築する。基盤を先に正しく作れば複利で価値が積み上がる」という総括でした。同社の発表アーカイブで視聴できます。

考察

頻出キーワードを集計してみた

現地では「eval や harness をやたら聞くな」という肌感がありました。帰国後、YouTube アーカイブの字幕を使って実際の出現回数を数えてみました。

先に集計の前提です。対象は私たちが優先度を付けて追いかけた 30 セッション（セッションレポート冒頭で触れた P0/P1）で、サミット全体ではありません（筆者らの関心による選択バイアスがかかっています）。そのうち時刻付きの英語字幕をセッション単位で切り出せた 20 セッション・約 17 時間・169,102 語が定量集計の母集団です（9 セッションは書き起こしテキストのみで集計対象外、1 セッションは字幕・書き起こしとも取得できませんでした）。AI・agent・model・system・data のような一般語は除外しています。

順位	キーワード	出現回数	登場セッション
1	eval / evaluation	264	18/20
2	benchmark	237	18/20
3	workflow	149	14/20
4	harness	136	17/20
5	security	120	15/20
6	deployment	118	16/20
7	context	117	18/20
8	memory	75	12/20
9	safety	74	11/20
10	reliability / robustness	70	15/20

最多は eval / evaluation と benchmark で、評価まわりの語彙が突出していました。harness は回数こそ 4 位ですが、20 セッション中 17 セッションに登場しており、ステージを問わず横断的に使われる特徴語になっていた点が印象的でした。一方、日本のコミュニティで見かける「ループエンジニアリング」という言い回しを現地で耳にする場面はほとんどなく、集計対象の字幕でもごく僅かでした。少数ながら「最近は loop engineering と呼ばれている」と紹介する登壇者もいたので、語彙として存在しないわけではなく、主流が harness だった、というのが正確なところです。

繰り返しになりますが、これは筆者らが選んだセッションに基づく集計であり、カンファレンス全体の傾向を確定的に示すものではない点にご注意ください。

日本のプレゼンスと、参加のすすめ

筆者らが現地で会話やネットワーキングをした範囲では、日本からの参加者に出会う機会は多くありませんでした。また、筆者が確認した範囲では、公式サイトのスポンサー一覧に日本企業は見当たりませんでした。

ただ、これは裏を返せば空いているポジションだとも感じました。第一線の当事者に Ask the Speaker で直接質問でき、ポスター前で研究者と議論できる——この密度の場に日本からの存在感がまだ薄いのだとすれば、継続的に参加することで比較的早く認知を得られる余地があるはずです。

実務的な情報も残しておくと、筆者らの滞在中は会場周辺のホテルからキャンパスまで徒歩で移動でき、動きやすい環境でした（安全面の一般的な情報は UC Berkeley 警察の来訪者向け案内を参照してください）。セッションは全編ライブ配信・アーカイブ公開されるので、「セッションを見る」だけなら現地に行く必要はありません。逆に言えば、現地の価値はネットワーキングと Ask the Speaker に全振りするのが正解だと思います。この分野に取り組んでいる方には、来年の参加を検討する価値のあるカンファレンスです。

おわりに

Agentic AI Summit 2026 の 2 日間を通じて持ち帰った結論を 1 つに絞るなら、「個別タスクの品質にはモデル性能が大きく効く。一方で、本番導入を継続的な成果につなげる鍵は、評価基盤・ハーネス・組織設計と業務への接続にある」ということでした。この認識は、トークン数やコミット数のような量的アウトプット指標ではなく、ワークフロー短縮やビジネス成果に紐づく指標を測るべきだという各社の実践報告とも一貫しています。

全セッションのアーカイブは Berkeley RDI の公式ページからアクセスできます。本記事で紹介しきれなかった Robotics、AI for Science、金融系のセッションも充実しているので、興味のある方はぜひ覗いてみてください。

最後まで読んでいただき、ありがとうございました。