💭

AIは失敗していない、我々の作り方が間違っている — Web Summit Vancouver 2026 セッションレポート

に公開
AI
event
llm
websummit
vancouver
idea

Web Summit Vancouver 2026 という4日間のイベントに一般参加者枠で行ってきました。
各ステージやブースでたくさんのセッションが行われていましたが、今回は AI isn't failing we're building it wrong というセッションについて整理・振り返りの意味を込めてアウトプット（レポート）してみます。

セッション概要

基本情報

  • タイトル: AI isn't failing we're building it wrong
  • 開催: Web Summit Vancouver 2026 ／ 2026年5月13日（水）12:00–12:30 PM ／ Vancouver Convention Centre
  • 公式説明:

    In this talk, our experts combine research and real-world insight to expose the gap between model performance and practical deployment. From fundamental limitations in machine learning to the challenges of operating AI at scale, they outline what must change to build systems that actually work in the real world beyond the lab and into production.

    （意訳）本セッションでは、専門家たちが研究と実地の知見を持ち寄り、モデルの性能と実運用の間にあるギャップを明らかにする。機械学習の根本的な限界から、AIを大規模に運用する際の課題までを取り上げ、ラボの中だけでなく、現実世界の本番環境で実際に機能するシステムを作るには何を変えるべきかを示す。

登壇者

登壇者 人物像 パネルでの主張

John Koetsier（進行役）
Forbes シニアコントリビューター／TechFirst ホスト		 ジャーナリスト、アナリスト、テック業界のエグゼクティブ。テック系スタートアップへのコンサルティングも手がける 問いを投げ、議論を方向づけるモデレーター

Jennifer Smith
Scribe 共同創業者 & CEO		 Scribe を「組織の仕事が正しく回ることを保証し、改善の道筋を示す Workflow AI プラットフォーム」と自社説明 コンテキスト層 / organizational legibility。組織が legible でなく last mile problem に

Nancy Wang
1Password CTO／Felicis パートナー		 1Password で世界規模のエンジニアリング組織を率い AI 戦略を主導。Felicis で初期段階の AI インフラ／セキュリティ企業に助言。Advancing Women in Tech 創業者 & CEO Agent Identity と Intent monitoring。従来の IAM（role-based access）ではエージェントを扱えない

Linda Tong
Webflow CEO		 Cisco・NFL・Google で要職を歴任し、Webflow CEO へ AI-native rebuild。AI 後付けでなく土台から作り直す。全員が "builder" に

各トピック

Topic 1: 何を作り間違えているか

進行役の問い

"I'm going to start with the obvious. What are we building wrong?"

（意訳）まずは当たり前の問いから始めよう。我々は何を作り間違えているのか？

登壇者全員が「context（文脈）と controls（統制）が足りていない」ことを共有しつつ、3人が別々のレイヤーの「作るべきだが作られていないもの」を指摘。

① Jennifer：組織が legible（読み解ける状態）になっていない

  • モデルは汎用的な職能（投資銀行・法務・会計など）は身につけているが、「自社ではどう回しているか」という固有の文脈（システム・業務フロー・例外処理・依存関係）はデータ化されておらず、担当者の頭の中にしか存在しない。
  • これがラストワンマイル問題（last mile problem）であり、強力な汎用知能は手元にあるのに、自社に当てはめる文脈データがないせいで、エージェントを訓練することも、正しく動いているか検証することもできない。

② Nancy：Identity（何者か・誰の代理か・どこに属すか）と Intent（何をしようとしているか）を扱う仕組みの不在

  • 従来の IAM（ID・アクセス管理：役割を決めて権限を割り当てる方式）にエージェントを当てはめるのは、問題の先送りでしかない。
  • エージェントは自ら推論し、非決定的（同じ指示でも結果が一通りに決まらない）に動く。だから、たとえ正しいアクセス権を与えても「実際に正しいことをするか」は別問題になる。
  • 必要なのは2つ。エージェント固有の身元（identity）を与え、そこに意図（intent）を紐づける仕組みである。そうすれば、機密システムへのアクセスを許したあとも、そのエージェントが「何をしようとしているか」を監視し続けられる。

③ Linda：後付けではなく、土台から作り直す

  • 多くの企業は「AI-native（AIを前提に作られた）」を名乗るが、実態は AI-assisted（既存システムにAIを後付け）なだけである。だから、いくら革新を試みても、出てくるのは弱々しい成果ばかりになる。
  • システムの構成（architecture）、基幹データを保持する仕組み（systems of record）、データの構造（data schema）、データの持ち方（modeling）。これらはすべて、AIを前提としない時代の設計のままである。土台がそのままでは、上にAIを後付けしてもうまく噛み合わない。
  • まず事業そのものと技術スタックを「再創業（refound）」するつもりで土台から作り直す。そして、その土台の上に、AIへ自社の文脈を与える文脈層（context layer）と、AIの暴走を防ぐ統制層（controls layer）を載せていく。

トピックまとめ

3人が指摘したのは、そろえるべき3つの層である。

  • インフラ層（Linda）── AI-native に作り直す、最も根本的な土台
  • ガバナンス層（Nancy）── Identity と Intent でAIの挙動を統制する
  • データ層（Jennifer）── 組織を legible にし、文脈をAIに渡せるようにする

ところが多くの企業は、土台（インフラ）の作り直しをスキップし、統制（ガバナンス）は後付けで済ませ、そして文脈（データ）が丸ごと欠けていることにすら気づいていない。

Topic 2: ベンチマークと現実のギャップは何か？

進行役の問い

"We still see a big gap. We see the benchmarks for some of the latest frontier models ... it looks unbelievable. You apply it yourself and reality is a little different. What's going on there?"

（意訳）最新のフロンティアモデル（最先端モデル）のベンチマークを見ると、その数値は信じられないほど高い。ところが、いざ自分で実際に使ってみると、いまだに大きなギャップがある。いったい何が起きているのか？

結論：ギャップの原因はもうモデル性能ではない。組織側の準備不足。

  • この現状はたとえるなら、ノーベル賞受賞者をオフィスのロビーに座らせコーヒーを出すだけ、という状況。いくら頭が良くても、会社のことも何を期待されているかも分からなければ、手をつけることすらできない。文脈のない「知能」は、どれだけ優秀でも無力である。
  • モデルの良し悪しを論じるのは、もう脇に置いていい。十分に強いし、今後もさらに強くなる。いま本当に問うべきは「組織として何をすべきか」である。
  • 技術の進歩は、指数関数的に跳ね上がっていく。一方、組織が変革を進める力は、ゆるやかな線形でしか伸びていかない。この2本の成長曲線が開いていく差こそが、ベンチマークと現実のギャップの正体である。 だから手を入れるべきは技術ではなく、組織の側、つまり仕組み・業務プロセス・変革のマネジメント（change management）である。
  • 企業の使い方も、年を追って成熟してきた。2024年は「とにかくAIを全社員に配り、何か面白い成果が芽吹くのを期待する」段階。2025年は「気づけばトークンに大金を注ぎ込んでいた」と我に返る段階。そして現在は「ROI（投資対効果）で語る」段階である。
  • 大事なのは、目標を「測定できる」ところまで具体化すること。「do more with less（少ない人手でより多くを）」では曖昧すぎ、「新人営業が戦力になるまでの期間（ramp time）を縮める」まで具体化して初めて成果を測れる目標になり、AIを当てる先がはっきりする。

ただし、「では組織を実際にどう変えればいいのか」という "How" には依然として多くの問いが残っている、と Jennifer 自身も率直に認めている。

Topic 3: Token Maxing から Local Maxing へ

進行役の問い

"Who's heard of token maxers? ... You got to choose the model you're using for different tasks quite carefully as well, right?"

（意訳）「token maxers（トークンを使い倒す人たち）」を聞いたことがある人は？ …… それと関連して、タスクごとに、使うモデルもかなり慎重に選ばないといけませんよね？

なぜ Local Maxing なのか

そもそも Token Maxing とは、AIにできるだけ多くのトークンを使わせること。企業によっては「最低でもこれだけ使え」とノルマ化するほどの動きを指す。

これは決して無駄ではなく、AI時代への抵抗をなくし、組織全体の適応を促す "きっかけ" として、誰にでもできる手軽さゆえに、初期にはよく機能した。

しかし、それは本質的ではない。投入量（どれだけ使ったか）を、活用度（どれだけ価値を生めているか）の代わりの指標にしてしまい、手段が、目的にすり替わっている。たくさん使うことと、価値を生むことは、同じではない。

さらに、AIの "コスト化の課題" と "小型モデルの性能向上" という時流の環境変化が相まったことで、前者により Token Maxing の非効率を顕在化させ、後者により回避可能になった。

結果として、過渡的手段である Token Maxing を卒業し、Local Maxing の認知と実行が価値創造の鍵になってきている

どんなタスクにも最上位のフロンティアモデルを使うのは、近所のスーパーへ行くのにフェラーリを出すようなものである。軽い処理なら小型モデルで十分、速く、はるかに安く済む。

Local Maxing の実践

では、Local Maxing を実践するには何を考えればよいか。

  • モデルを選ぶ際は、次の4点を問う。①手元のタスクは何か、②それに適したモデルはどれか、③どうチューニングするか、④そのタスクにどれだけの価値があるか。
  • さらにその手前に、上位の問いがある。そもそものビジネス課題は何か、正しい解決策は何か、それは本当にAIで解くべきか、（AIなら）どのモデルか。「AIありき」で始めないことが肝心である。
  • モデルは常に入れ替わる "動く標的" でもある。新しいモデルが出るたびに、試して検証し続ける必要がある。
  • その効果は小さくない。進行役自身、適切なモデルに切り替えただけで、あるワークフローのコストが1日 $20〜40 から $3〜4 へ、およそ10分の1に下がったという。

Topic 4: AIシステムに欠けているものは何か

進行役の問い

"What are we missing in our AI systems?"

（意訳）我々のAIシステムに欠けているものは何か？

結論：欠けているのはモデル性能ではなく、運用の規律と統制

「何が欠けているか」への答えは、モデルの性能ではない。それはすでに十分に高く、誰の手にも行き渡った。欠けているのは、それを安全かつ効率的に運用するための規律と統制である。具体的には、コストの制御と、コンテキストの扱いという2つの面に現れる。

Jennifer はこの状況を、全員にフェラーリが与えられたのに誰も運転の教習を受けていない（"We've all been given Ferraris and nobody's got driving lessons."）状態だと評した。強力な道具は全員に配られたが、それを乗りこなす規律と統制は追いついていない。道具を配ることと、安全かつ効率的に使いこなせることは別である。

① 運用とコストの規律

強力なモデルを無造作に動かせば、コストは容易に暴走する。エンジニア1人あたり、トークンの利用料（消費量ではなく代金）が週 $50K〜$100K に達する例もある。原因は、サブエージェントが自己増殖し、24時間並列で走り続けることにある。

コストを統制するには、次のような手立てがある。

  • タスクに応じて適切なモデル（多くの場合は小型で安価なもの）へ振り分ける（モデルルーティング）。
  • キャッシュやインデックスを使い、毎回フルにクロールするのではなく「変化した分だけ」処理する（アーキテクチャ設計）。
  • 支出の上限を出荷量などの業務量に紐づけ、超過時には請求の内訳を精査する（スペンドキャップ）。
  • モデルやAPIごとの支出を財務リーダーが把握できる仕組みを整える（支出の可視化）。
  • 全員が builder になる時代に向け、アクセス権・権限・認証情報の基本を改めて教育する（credentials の再教育）。

ただしスペンドキャップは万能ではない。上限設定が効かないAPIもあり、突然 $127K を請求された実話もある。

② コンテキストの扱い

コンテキストは多いほど良い、とは限らない。ある量までは効果が高まるが、それを超えると頭打ちになり、入れすぎればかえって逆効果に転じる。会議や 1on1 をすべて録音して放り込むようなやり方は、手当たり次第（grasping）に過ぎない。

さらに組織レベルのコンテキストは、権限とセキュリティの地雷原でもある。それでも業界はスピードを優先し、この問題を見て見ぬふり（turning a blind eye）にしている。コストの統制には具体策が出そろってきたが、コンテキストの扱いには、有効な手立てがまだ見つかっていない。

Topic 5: 職種の境界が融け、「builder」へ収束する

進行役の問い

"It's totally changing what we do in terms of work ... they renamed all of their people 'the builder.' ... You can have a vision and execute a vision, right?"

（意訳）これは我々の仕事のあり方そのものを大きく変えつつある。…… ある企業は、社員全員の肩書きを「ビルダー（builder）」に付け替えた。…… ビジョンを描き、それを自ら実行できる、ということですよね？

結論：実行はAIが担い、人間の価値は戦略・判断へ移る

AIがコードやプロトタイプといった「実行」を肩代わりするようになり、PM・デザイナー・エンジニアという職種の境界が融け始めている。全員が一人の「builder」へ収束していく。その結果、人間に問われる価値は「実行できること」から「戦略・思考・判断」へと移る。Linda の言葉では、問うべきは「エンジニア／デザイナー／PM の価値とは何か」であり、その答えは "strategically what they bring to the table"（戦略的に何をもたらすか）である。

受け渡しが消え、職種が一人に収束する

従来の開発は、受け渡し（break point）の連続だった。PM が何を作るかを考えて仕様を書き、デザイナーが体験をプロトタイプし、エンジニアがコードに翻訳するという分業である。AIによってこの受け渡しが消え、アイデアを話し合い、その場でコードとして生成し、反復する、という流れが一人で完結する。

その結果、人はそれぞれの職種の枠から離れ、「builder」になっていく。builder は、エンジニアが進化した姿ではない。PM・デザイナー・エンジニア・さらには非エンジニアが一人に収束した存在である。一部の企業はこれを正式な肩書きに採用したが、本質は呼称ではなく働き方・あり方の変化にある。Linda 自身、個人的なアプリを作る中で「正しいデータベース構造は何か」を Claude と数時間議論したという。問題を解くうえでの制約をすべて一人で引き受けるのは "different muscle"（これまでとは違う筋肉）であり、誰もがそこへ移りつつある。

増幅されるのは「良い判断を持つ人」

この変化は非エンジニアにも及ぶ。あるカスタマーサクセスマネージャーが自分の業務のためだけに、本来なら本格的なSaaS製品に相当するツールを自作し、いまや他のメンバー全員が欲しがっているという状況も実際に起き始めている。

強力な道具が行き渡ったとき、最も伸びるのは、創造性や強い判断力を持ち、達成したい目標を明確に意識している人である。彼らは以前より遥かに多くを成し遂げ、強く活気づいている。

副作用：仕事は青天井に、移行は未解決

ただし負の側面もある。ひとつは、可能性が見えるほど仕事が際限なく膨らむこと。できることが見えてしまうがゆえに、かえって労働量が増す（"I now work so much more"）。

もうひとつは、全員をこの新しい働き方へどう移行させるかが未解決であること。builder の働き方は、求められるスキルも思考様式も、「どう仕事に臨むか」という期待も、多くの人が採用された当時とは別物である。採用時とは違う人間になることを全員に求める、という難題が残る。

Topic 6: 常にLLMが必要か

進行役の問い

"Do we always need an LLM? Do we sometimes just need plain good old-fashioned unbelievably cheap automation?"

（意訳）我々は常にLLMを必要とするのか？ ときには、昔ながらの、信じられないほど安価な自動化だけで十分なのではないか？

結論：LLMは「ツール」であって「デフォルトの選択肢」ではない

すべてをLLMで解く必要はない。LLMは数ある道具の一つであり、最初から当然の選択肢として据えるものではない。Nancy の言葉では "think about LLMs as a tool, not as the only default choice" となる。

LLMが要る処理と、要らない処理

結果を一意に定めたい決定論的な処理に、LLMは要らない。たとえばデータベースの稼働を確率任せにはできないし、条件によって path A か path B かを分岐させる制御は、結果を特定の出力に固定したい。こうした領域では、従来のプログラミングのロジックがそのまま有効である。

一方、曖昧さの中で推論させたい処理（データセットを渡して「ここから何が読み取れるか」を考えさせる、feature stores のような用途）には、LLM が向く。

AIで作り、AIなしで動かす

LLM を使う場面でも、運用時まで LLM に依存し続ける必要はない。たとえば、エージェント本体は一部 LLM を使うが、その上で進捗や健全性を監視する小さな見張り役（"electronic angel"）は、LLM と対話する必要がなく、CPU を回すだけでコストはかからない。

ここで効いてくるのが「AIで作り、AIなしで動かす」という発想である。トークンは作るための一度きりの費用であり、出来上がったシステムは、すでに自前で持っている CPU の上で動く（"You can build those with AI, but they don't run with AI."）。ただしこれは決定論的な部分の話で、曖昧さや推論が必要な部分は運用時にも AI を使う。AI が運用から完全に消えるわけではない。

非AIの選択肢と、発見ツールとしてのAI

そもそも、成果を出すのに AI が要らない場面も多い。現行ツールの設定を見直す、ツールスタックを入れ替える、Zapier や RPA のような自動化を使う。こうした非AIの手立てだけで、平均すると 25% ほどの生産性向上が得られるという。AI はそこからさらに上積みできる余地が大きい、という位置づけである。

加えて、AI は「どこを自動化すべきか」を見つける発見ツールにもなる。かつての RPA では、自動化の対象を洗い出すこと自体が難題だった（10万人規模の組織で全員に聞き取りをし、業務を棚卸しする、といった具合である）。いまは AI に業務を棚卸しさせて候補を見つけ、そこを決定論的な自動化に置き換えられる。

Topic 7: AIが決して得意にならないもの

進行役の問い

"What will AI never get right? What will we always need people for?"

（意訳）AIが決して正しくこなせないものは何か？ 我々が人間を常に必要とし続けるのは、どんなことに対してか？

結論：人間に残るのは創造性・所有責任・主体性（agency）

クロージングのこの問いに、3人は人間の異なる3つの側面を挙げた。Linda は創造性と taste、Nancy はシステムの所有と説明責任、Jennifer は主体性（agency）である。

この3つは横並びではなく、緩やかな階層をなす。最上位にあるのが agency、すなわち「自分は何を・なぜ成し遂げたいのか」という方向そのものを定める力である。その下で、創造性・taste は「何が良いか」を見極め、所有・説明責任は「壊れたときに誰が責任を負うか」を引き受ける。AIが実行（how）を肩代わりするほど、人間の価値は「何を・なぜやるか」という上流へ集約していく。

創造性・判断・taste（Linda）

AIが得意なのは remix、すなわち既存のアイデアを組み合わせることである。一方、ゼロから生み出す genuine innovation や、良し悪しを見極める taste は、人間に固有の能力である。とりわけデザインやブランド表現のように「本当に優れたもの」が求められる領域では、"AI just doesn't get there."（AIはそこに届かない）。

システムの所有と説明責任（Nancy）

非エンジニアでもコードの変更（PR）は出せるようになった。しかしテスト・ビルド・デプロイは、依然としてエンジニアが担う。本番環境で何かが壊れたとき、環境の全体像、あらゆる edge case、サービス間の連携を把握して対処できるのは、経験を積んだシニアエンジニアである。

さらに踏み込むと、オンコール（障害対応の当番）をめぐる原則に行き着く。"You can't contribute to someone's on-call load if you're not owning that code."（自分が所有していないコードについて、他人のオンコール負担を肩代わりすることはできない）。AIにも、コードを所有しない者にも委ねられないのが、この説明責任（ownership）であり、「作れること」と「運用の責任を負えること」は別物である。

主体性（agency）（Jennifer）

Jennifer が挙げたのは主体性（agency）だ。"What is it I'm trying to do in the world? What am I trying to create?"（自分は世界で何をしたいのか、何を生み出したいのか）を自分で決める力である。

例に引いたのは、自宅のリノベーションである。AIはいくつも案を出してくるが、どれも derivative（既存の焼き直し）に感じられ、最終的に何をしたいかを決めるのは自分だ。だからこそ、親として「主体性の高い子をどう育てるか」、雇用者として「主体性の高い人をどう採用するか」を考える。そして "The more powerful the tool you give them, the more incredible things they get done."（強力な道具を与えるほど、主体性のある人は桁違いの成果を生み出す）と締めくくった。

おわりに（感想とか）

Web Summit について

  • イベントは日本国内であるイベント（AWSサミットとか）と似ていて、ステージのセッションが複数あり、同時に個別ブースで企業の参加型セッションなどもある。
  • このイベントに限らずだと思うが、視聴したいセッションはあらかじめ決めておいたほうがいい。かなりテンポ良く回転しているイメージで、ステージ間の距離がある場合もあったり。
  • 現地でのミートアップこそ価値があるらしい。これは運営側の方がオープニングから再三発言されていたこと。実際に多数のミートアップイベントがあったし、参加してそこでの会話やつながりに価値があることには頷けた。
  • C$835 は高いと思ったけど、終わってみて（初めてだったし）よかったかなともおもっている（直前に参加を決めたので正規の料金だったけど、いろんな割引はあったみたい）

今回のセッションについて

  • ギャップの原因は、技術の進歩が指数関数的に跳ね上がっていく一方、組織が変革を進める力は、ゆるやかな線形でしか伸びていかず、これらの成長曲線が差であるというのは、すごくイメージ湧いたし、自身も一定の納得感をもって課題感の矛先が組織に向いた感覚がある。
  • 課題の言語化は進んでいるが、解決策はまだ具体的でなく大枠の方針に止まっている印象で、これは自身の現場での体感でもイメージがつながったりする。これから具体どのようにAI活用の価値転換ができるかに当面注目したい。
  • 従来のSDLCが融け、みんなが builder になるという観点もSWEが開発業務以外の領域に染み出している話をちらほら見聞きするようになったので、ある程度現場イメージを持ってそうなんだろうと感じている。
  • Token Maxing から Local Maxing への移行の考えは理解とイメージがしやすい一方、現場でそれを実現するには、その性能評価の点でハードルが高く感じている。

Discussion