【レポート】After software Anthropic's vision for the next era of enterprise AI
お疲れさまです。とーちです。
Google Cloud NextのAnthropicセッションに参加してきましたので、その内容をレポートしていきます。Anthropicメンバーの生の講演を聴けるということで、私にとっては非常に貴重な機会になったのかなと思っています。
セッション概要
タイトル
After software: Anthropic's vision for the next era of enterprise AI
概要
Enterprise software will change more in the next two years than it has in the last twenty. The model is inverting: top-down planning, where organizations define and prioritize what gets built, is giving way to bottom-up execution, where AI agents help teams solve problems as fast as they find them. Anthropic shares what we're seeing at the frontier. Teams are already deploying agents on Vertex AI that define, build, and iterate autonomously. We'll ground the vision in real examples and practical frameworks for readiness.
※日本語訳:
エンタープライズソフトウェアは、過去20年よりもこれからの2年で大きく変わる。モデルは逆転しつつある。組織が何を作るかを定義・優先順位付けするトップダウン型の計画は、AIエージェントがチームと一緒に問題を見つけた端から解いていくボトムアップ型の実行へと置き換わっていく。Anthropicがフロンティアで見ているものを共有する。すでにチームはVertex AI上でエージェントをデプロイし、自律的に定義・構築・反復を行っている。本セッションではリアルな事例と、そのための実践的なフレームワークを示す。
スピーカー
- Eric Burns 氏 (Anthropic, Member of Technical Staff)
Eric氏のバックグラウンドとAnthropicのミッション
Eric氏はまずご自身のバックグラウンドを紹介されました。エンタープライズSaaS企業であるPanoptoの創業CTOから最終的にCEOになり、クラウドアーキテクチャからUX、クロスプラットフォームインテグレーションまで現場で経験してきたとのこと。その経験を通じて辿り着いた結論として、次のように仰っていました。
インテグレーションはプロダクトの最重要部分であり、優れたものはまるでそこに存在しないかのように感じられる。
さらにEric氏は、AnthropicではLabsチームの初代プロダクトマネージャーとして、MCPおよび最初のMCPクライアントとなったClaude Desktopのローンチに関わってきた とも話されていました。
この「優れたインテグレーションはまるでそこに存在しないかのように感じられる」という哲学を持つ方が、まさにMCPのローンチに関わっていたという事実を知って、個人的にはめちゃくちゃ納得感がありました。私自身もMCPを初めて触ったときのことを思い出すと、確かに接続されていることを意識させずに必要な情報がClaude上にすっと連携されるところを見て、感動した記憶があります。
そしてこのセッションの最初のつかみとして、Eric氏は「少し失望させることを言うと」と前置きしつつ、以下のように話されました。
ソフトウェアの後に来るものはただのソフトウェアであり、しかも圧倒的に多い。
この言葉は私としてはなかなか新鮮でした。Anthropic自身、しかもAnthropicの主要人物が「AIはソフトウェアを代替しない」とも取れる発言をしているのが意外でした。
Anthropicのミッション
続いてAnthropic自体の紹介があり、次のようなミッションが語られました。
私たちのミッションは、世界が変革的AIへの移行を安全に乗り越えることを確実にすることです。
Anthropicのミッションがこういう内容だというのを、恥ずかしながら私は知りませんでした。Anthropicのモデルは肌感として誠実さを感じているのですが、そういったモデルの特徴がこのミッションにきちんと表れているんだなと思いました。実際、Eric氏はモデルの誠実さを測る「MASK benchmark」というベンチマークでAnthropicのモデルが業界をリードしているという話をされていました。MASK benchmarkは「モデルが自分の信念に反する発言を、圧力をかけられた状況でするかどうか」を測るもので、単純な正確さではなく「知っていることに対して嘘をつかないか」という観点で誠実さを評価するベンチマークだそうです。Anthropicには「最もフロンティアな知性へのルートは安全性を通ること」という信念があることについても触れられていました。
Anthropicのプロダクトスタック
Anthropicが提供するフルスタックについても紹介がありました。
- ベース: クラウド（GCP / AWS）
- その上: モデル（Opus / Sonnet / Haiku の3種類 = 大 / 中 / 小）
- その上: プラットフォーム
- その上: アプリケーション（ビジネスアウトカムを提供）
エンタープライズ向けの最初のプロダクトはシンプルなチャットで、次が2025年にリリースされたClaude Codeだったとのこと。Claude Codeについては「モデルの能力とコンピュータをコンピュータとして使う能力を組み合わせた、一つのブレイクスルーだった」と評されていました。そして非エンジニアにも役立つことが分かったためVM上のフレンドリーなラッパーに包んで「Cowork」というプロダクトにした、というのが今のClaude Coworkアプリの成り立ちだそうです。
エンタープライズがAIを活用する3つの柱
Anthropicが考えるエンタープライズでのAI活用には、3つの柱があるとのことでした。
- 従業員 (AIを導入した企業で働く人たち) をより賢くする: 情報アクセスを改善し、thought partnerを提供して、日々の業務を効果的にする
- プロセスを改善する: AIとの作業直感が育つと、業務プロセスの無駄を見つけて効率化できる
- 変革的なものを作る: 全く新しいプロダクト、全く新しいビジネスを創造する
この3つのステップは、私としても非常に納得感があるなと思いました。私も直近で1番と2番にあたるような提案をしていたからです。また3番の部分については、直近でAWSのブログ記事で AI-BPR (AI-driven Business Process Re-Engineering) というものが掲載されていたのですが、そこと重なる部分を感じました。
コーディングモデルの指数関数的進化
ここでEric氏は、YouTubeにも公開されているというClaudeの歴代バージョンによるコーディング進化の動画を紹介されました。
セッション中で見た動画と同様のものがRedditに上がっているのを見つけました。
参考: Anthropic: A video of all versions of Claude from 1 to Opus 4.5 (Reddit)
こうやって改めて見ると、短期間ですごい進化をしているのがわかります。Claude 1や2の頃はそもそもツールが使えなかったというのが個人的には一番驚きでした。コーディングエージェントが当たり前になっている今の感覚で見ると、ほんの数年前の世界観とのギャップが激しいです。
scaling laws: Moore's Lawに似た指数関数
ここでEric氏は一度話を大きく引いて、トランジスタの発明からMoore's Law (集積回路の性能がおよそ18ヶ月で倍になるという経験則) までを振り返られました。そしてAIにも同じように指数関数的な成長則があり、それが「AIを支配する自然法則に最も近いもの」として知られる scaling laws である、と説明されました。以下のスライドは「The Artificial Intelligence Exponential」と題され、2017年のTransformer、2020年のScaling Laws、2022年のChatGPT、そして近年のClaude Sonnet 3.5やClaude Opus 4.6 (We are here) といったマイルストーンを, 指数関数のカーブに沿って並べた図になっていました。
実は3つの次元が同時に加速している
ただしEric氏は「この指数関数のグラフだけでは実際に起きていることを表現しきれない」と続けられて、3つの次元の同時加速について説明されました。
- モデルが取り組める問題の複雑さ (長いコンテキスト、複数の指示のナビゲーションなど)
- エージェントが生産的に動作できる時間 (SWE-benchで計測されている)
- フレームワーク自体の複雑さ (サブエージェント、並列化、敵対的エージェントなど)
これら3つの次元を加味すると、AIの実用的な能力は7ヶ月ごとに倍になっている とのことでした。AIの改善の周期は早いなと感じてはいましたが、こうやって数字で表されると驚きがありました。
エージェントとは何か
Eric氏はまず、共通認識を揃えるためにエージェントのシンプルな定義を次のように示されました。
エージェントはツールとスキルを持つLLMです。
この一文がAnthropicが考えるエージェントの定義なんだな、とまず押さえておくと、この後の話が入ってきやすいと思います。
その上で、Eric氏自身が見つけた中で一番しっくり来たという、もう少し踏み込んだ定義も紹介されました。
エージェントとは、ループの中で動作するLLMであり、ツールを使う。そしてゴールを持つ。 (このループはinner loopとも呼ばれる)
ここで出てくる「inner loop」は、エージェント (LLM) がゴールを達成するまで「思考 → ツール使用 → 結果を観察 → また思考...」を繰り返す内側のループのことだそうです。Claude Codeが「ファイルを読む → コードを書く → テストを実行する → エラーを見て修正する...」と自律的にタスク完遂まで繰り返しているのがまさにこれにあたります。
共同創業者のBen Mann氏の「エージェントをいつ使うかを理解するには、賢い人を雇って仕事のトレーニングをして任せる時のことを考えればいい」という発言も紹介されていました。確かにClaude Codeを使っていると、とても仕事のできる部下を持ったような感覚を抱いていたので、この発言が腑に落ちました。
そして「コンピュータで問題を解くには、まずコンピュータなしでどう解くかを考え、そのとおりにコンピュータにやらせる」というプログラミング初期に受けたアドバイスを引用されつつ、エージェントの組織化はまさに人間社会の組織構造を再現しているだけだ、とのことでした。リーダーがいて、その下に専門的なフォロワーがいて、木の下に行くほど専門化が進む、という話をされていました。
私はエージェントのスキルを作るときに、まず自分とLLMで対話的に実際の仕事の内容をやってみて、そのセッションの最後に「今実施した手順をスキルにして」といった指示でスキル化することが多いので、この「まずコンピュータなしで解き方を考える」という話は自分のやり方と重なっていて納得感がありました。
GCCをクリーンルームで再現したソリューションマシン
一番驚いたのがここのパートです。Anthropicの研究として、Claude CodeにGCC (GNU Cコンパイラ) のクリーンルームクローンを構築させた という実験が紹介されました。この実験の詳細はAnthropicのエンジニアリングブログ Building a C Compiler with a Team of Parallel Claudes にもまとめられています。
Eric氏によると、GCCはオープンソースの世界の基盤中の基盤で、何十年もかけた最優秀エンジニアたちの集合的作業の成果なのだそうです。しかも、コンパイラは完璧でないと意味がない (1つでもエラーがあれば使い物にならない) という厳しい条件があるとのことでした。
Eric氏がセッションで共有してくれた実験の概要は以下のとおりです。
- 使用モデル: Opus 4.6
- 投入トークン: 約2万ドル分
- 期間: 2週間
- 実行形態: ループ実行するClaude Codeに対して「GCCを構築せよ」というdirective (指令) を与える形
- 構造: inner loop (Claudeがエージェントとしてゴールを達成するまでループ) + outer loop (全体目標に向かって次の小ゴールを設定し、少しずつ前進させる)
- 成功条件: 本物のGCCとバイト単位で一致するLinuxカーネルをコンパイル
結果として、Opus 4.6はこれをやってのけた、最初に達成できたモデルになったそうです。
これは一般化すると「問題と資本を受け取り、ソリューションを提供する」マシンなんだ、ということで、ここから話がさらに発展していきます。
自己改善型ソリューションマシン
さらに別の実験として、以下3つのロールをループで回すハーネスが紹介されました。
- Planner: タスクをプランに分解する
- Generator: プランを実装して動作を検証する
- Evaluator: ソフトウェアエンジニア/デザインリードとして評価する
このPlanner/Generator/Evaluatorのループを回すと、自己反復するだけでなく自己改善するハーネスになる、とのこと。このあたりの話はAnthropicのエンジニアリングブログ Harness design for long-running applications にも書かれていましたね。
そしてこの自己改善ハーネスを、先ほどのGCC実験のようなソリューションマシンに組み合わせると、自己改善型ソリューションマシン と呼べるものが生まれる、というのがEric氏の整理でした。
ここからEric氏の話は「自己改善型ソリューションマシンがあるということは、実行リソースが豊富かつ安価に使える状態に近づくということ」という方向に展開していきます。
Great Inversion: ソフトウェアのコストモデルが逆転する
これが次のキーコンセプトである Great Inversion (大逆転) の話につながっていきます。エンタープライズソフトウェアの構築コストはこれまで以下のような「ピラミッド」でした。
- ピラミッドの頂点 (1%): 問題の特定、定義、スコープ決定、戦略的意思決定（楽しい部分）
- ピラミッドの大部分: 実装、検証、デプロイ、メンテナンス（苦労の連続）
このピラミッド全体のコストが、市場に出した時の生涯価値を大幅に下回らない限りやらない、というのが従来のエンタープライズソフトウェアの経済モデルでした。
しかし今、ピラミッドの底（実装部分）が実質的にドル建てで測れるほど安くなり、次のような新しいピラミッドになりつつある、とのこと。
- 作業の大半: 楽しい戦略的な部分（問題特定、定義、スコープ、意思決定）
- 実装: 無料に近づいている
Omega Integration: 最後のインテグレーション
続いて、多くの大企業には300〜500のシステムがあり、そのほとんどは直接関連するシステムとさえほとんど話さない、という課題が提示されました。さらにEric氏は「仮に全部を繋げられたとしても、どのシステムがどの機能を使いたくなるかをすべて事前に予測するのは不可能」と話されていて、これは確かにそうだなと思いました。
そしてEric氏は、インテグレーションには面白い特性があると続けられました。それは「正しく作られたインテグレーションは、一つのシステムができることすべてを、他のすべてのシステムから (両方が対応できる帯域の範囲で) 使える状態にしてくれる」というものです。
つまり、「このAPIだけ公開」「このデータだけ共有」と個別に仕様を決め打ちしなくても、正しく統合すれば自動的に全機能が他システムから利用可能になる、ということ。先ほどの「組み合わせを事前に予測するのは不可能」という話への答えにもなっていて、事前予測しなくても必要な時にどの機能でも使える状態を作れる のがこの特性の価値だそうです。Eric氏はこれを「self-specifying (自己指定的)」と呼んでいました。
ただ個人的にこの話を聞いていて少し引っかかったのは、セキュリティの観点です。「一つのシステムの全機能を他のすべてのシステムから使える」状態というのは、裏を返すと攻撃面
がかなり広がることにもなります。従来のAPI設計は最小権限の原則 (必要な機能だけ公開する) が基本なので、「全部使えるようにする」という言葉だけ聞くと少し違和感もありました。このあたりAnthropicが実際どう考えているのか、機会があれば聞いてみたいところではあります。
話をEric氏の主張に戻します。この自己指定的なインテグレーションをソリューションマシンで実現するには、コーディングエージェントが以下3つをサポートするだけでよい、と話されていました。
- 自己反復できる
- 自分がリグレッションする能力を制限する
- 害を与え副作用を持つ自分の能力を制限する
先ほどセキュリティの観点で引っかかりを覚えた部分について、この2番・3番の「自己制限」がある種の安全装置の役割を果たしているとも読めます。Anthropicとしては、アクセス制御で縛るのではなく、エージェント自身のふるまいに自制的な性質を持たせることで、全機能公開と安全性を両立させようとしているのかもしれません。
こういう自己反復・自己改善型のインテグレーション構築ソリューションマシンがあれば、Omega Integration (最後のインテグレーション) が実現する、というのがEric氏の主張でした。そしてこの継続的インテグレーションは自然にすべてのシステムをClaudeと統合し、Claudeがそれらすべての情報を横断的に束ねて意味づけできるようになる、とのこと。
Opus 4.5のデモ: 10世代イテレーションで到達するUI
Planner/Generator/Evaluatorのループで10世代改善したUIがどう見えるか、というデモが紹介されました。
- プロンプト: 「日本の桜祭りを作れ」→ バージョン10は美しい出来栄え
- プロンプト: 「オランダの美術館のウェブサイトを作れ」→ バージョン1は普通のサイト、バージョン10はOpenGL 3Dレンダリングのギャラリー体験
これは改善を繰り返すループを用意して、モデルが経験を通じて自己改善できる条件を揃えるだけで、ここまで到達できるということを示したデモでした。
Centara社のボードデッキ事例
ここでEric氏は、ここまで話してきた内容がエンタープライズソフトウェアの現場でどのように組み合わさるかを示すため、Centaraという架空の会社を題材にしたストーリーを紹介されました。設定は以下のとおりです。
- Centara: ARR 1億ドルのエンタープライズデータ分析プラットフォーム
- 新しい資本パートナーとしてMeridian Capitalに買収されたばかり
2025年までの古いやり方
まず提示されたのが、Centaraがこれまでどのようにボードデッキ (取締役会で経営陣が使う業績報告資料一式のこと) を作っていたかという話でした。各チームがそれぞれの記録システム (CRMなど) から自分たちの数字を引いて、「自チームはこれだけうまくいっている」というストーリーを組み立てる、という従来のやり方です。
実際に示されていた数字を追っていくと、一見するとどの部門も順調に見えるようになっていました。
- 営業: セールスクオリファイド→オポチュニティのコンバージョン率52.4% (ベンチマーク超え、計画比で四半期以上先行)。ファネルもベンチマーク近辺で健全
- マーケティング: MQL→SQLのコンバージョンが良好で、マーケミックス内の大規模エンタープライズ顧客比率が時系列で伸びている
- カスタマーサクセス: 中堅企業セグメントの10日間アクティベーション率82.3%
そしてカスタマーサクセスチームの報告には「大規模エンタープライズ顧客のトライアルは少し遅れ気味」というノートが付いていたものの、「大規模エンタープライズ顧客はだいたいアクティベーションできているので問題ない」として軽く扱われていました。Eric氏はこの状態を「これが典型的なエンタープライズソフトウェア企業のボードデッキです」とコメントされていました。
MCPで繋いでClaudeにボードデッキを作らせる
ここで状況が変わります。新しい資本パートナーのMeridianは週次でボードパッケージを要求してきた、とのこと。Centaraの既存体制ではこのスピードに全く対応できません。そこでCentaraが最初にやったのが、社内の基幹システム (営業のCRMや財務システム、CSツールなど、各部門の業務データの元帳になっているシステム群) をMCPサーバーでラッピングし、Claudeから直接話しかけてデータを取り出せるようにする ことでした。
このセットアップを済ませた上で「Claude, CentaraのボードデッキのReact版を作って」と依頼すると、Claudeが実際のMCPサーバーから全データをリアルタイムで引いてきて、ボードデッキを組み上げてきます。事前に集計してスライドに貼り付けるのではなく、ボード会議の直前にClaudeが生のデータから作り直せる、というのは理想的な姿だなと思いました。
そしてClaudeが3つの事業システムを横断して情報を束ねて読み解いた結果、各チームの楽観的なストーリーとは裏腹に、Centaraは実際には構造的に成長が鈍化している ということが浮かび上がってきます。
財務モデルで根本原因を特定する
次のステップとして、Claudeに財務モデルを構築させて原因を深掘りさせます。Claudeが生のデータから複雑な分析ができるという能力を活かすわけです。
出てきた予測は、利益 (EBITDA) も手元資金もほぼ横ばい、という内容。Meridianから多額の資本を投じられたばかりで成長を期待されているCentaraにとっては、よくない状況。しかし3つのシステムを整合させて見られるClaudeだからこそ、「大規模エンタープライズ顧客がお試し利用からうまく本格利用へ移行できていないことが、成約率低下の真因だ」 という推奨事項を引き出してきます。
カスタマーサクセスチームが善意で軽く扱っていた「大規模エンタープライズ顧客のトライアルが少し遅れ気味」というあのノートが、実は伸びている大規模エンタープライズ向けマーケの成約率の低さにつながる原因だった、というわけです。前提を変えて**「お試し開始から10日以内にサービスを本格利用できる顧客の割合を37.6%から70%に改善した場合」** をモデル上でシミュレートすると、利益は右肩上がりになり、売上が営業コストを上回って伸びていく絵が出てきます。つまり「大規模エンタープライズ顧客のお試し→本格利用の成約率を上げる」という1つの気づきだけで、この会社を軌道に乗せられる、という話でした。
3部門の情報を横断的に見られるからこそ引き出せるインサイト、という分かりやすい事例でした。会場ではこのボードデッキがClaudeによって組み上がっていくライブデモも披露されていて、Eric氏はその締めくくりとして「シンプルなハーネスでこそモデルの力が発揮される」と話されていました。この話がそのまま次のBitter Lessonの章につながっていきます。
Bitter Lesson: シンプルなハーネスに任せる
ここで紹介されたのが, 強化学習の研究者Rich Sutton氏が2019年に書いたエッセイ「The Bitter Lesson」の考え方です。AI研究の70年を振り返ると, 人間の知識をモデルに作り込むよりも, 計算資源を素直に活かす汎用的な手法のほうが長期的には勝ってきた, という主張の記事です。
これをハーネス設計に当てはめて, Eric氏はおおむね次のような趣旨を話されていました。モデルは今後どんどん賢くなっていきます。その賢くなるモデルに対して, 無理やり言うことを聞かせたり, 出し抜こうとしたりしながら, 目先の性能を少しでも絞り出すために複雑なハーネスを作り込むのは, 長期的にはむしろ逆効果になる, と。
なぜなら, そうやって凝って作り込んだハーネスは, 次世代モデルが登場した時にかえって足かせになるからです。逆にハーネスをシンプルに保っておけば, モデル自身の性能向上の指数関数にそのまま乗れる, というのがEric氏の考え方でした。実際AnthropicでもSonnet 3.7からSonnet 4世代にかけて, システムプロンプトを約26%削減したそうです。
3つのドア: AIで何を狙うか
最後にEric氏は、ここまで話してきた「自己改善型ソリューションマシン」「Great Inversion (実装コストの逆転)」「Omega Integration (自己指定的な統合)」「シンプルなハーネス」といった一連の能力をひとまとめに捉えた上で、それらが私たちにもたらす機会を「3つのドア」として整理されました。
- 既存事業の収益性を高める: 今やっている事業をAIで安く回すことで利益率を上げる (人を減らして浮いたコスト分を利益に回す, という発想)。Eric氏はこれを「ベースラインの効率化アイデア」と呼びつつ, 新しい価値は何も生まないので3つの中では最も保守的な選択肢だ とされていました
- 並列化する: 必ずしも出荷が速くなるわけではないが、実験を並列で大量に走らせてビジネスに選択肢を生み出せる
- プロダクトを本当に良くする: MVPで止まらず、愛されるものを作る機会
3つ目について「真に素晴らしいものを作る機会は、エンタープライズソフトウェアでは多くの場合逃してしまう。なぜなら通常MVPに達したとき、あるいはMVPをわずかに下回ったときに出荷するからです」と仰っていました。私はプロダクト作成の経験はほとんどないですが、確かにありそうな話だと思いました。
Shannon限界と流動的コンピューティング
締めとして, ClaudeがClaude Shannon (情報理論の父) に由来する名前であることに触れつつ, Eric氏の未来像が語られました。
まず前提として, Shannonが打ち立てた定理では「どんな情報チャネルにも運べる情報量の上限 (=Shannon限界) がある」とされています。正しくエンコーディングすればこの上限ぎりぎりまで情報を詰め込める, という考え方です。
この考え方を踏まえた上で, Eric氏は次のような未来像を示されました。自己改善型ソリューションマシンによって、ユーザーエクスペリエンスをその場で生成して届けられる「流動的コンピューティング」と呼ぶべき新しいソフトウェアの形が見え始めている, と。ここで言う流動的コンピューティングは「あらゆるコンピューティングプラットフォームとエンタープライズシステムの組み合わせから引き出せる全機能を継続的に配信し, 長尾のタスクにはその場でパーソナライズしたUIを生成する」ものだそうです。
そしてこの流動的コンピューティングは, コンピューティング環境側 (ハード・ネットワーク・プラットフォーム) が物理的に出せる最大帯域で届けられるようになる, とのこと。そうなると何が起こるか。Eric氏曰く, システム側の上限が取り払われることで, 残る上限は「ユーザーがどれだけ速く受け取った情報を理解・解釈できるか」だけになる, と。つまり新しいShannon限界は, システム側ではなく人間側の認知能力に移る, というのがEric氏の示した絵姿です。
コンピューティングは継続的なサービスとなり, 自然言語を入り口にして, 一般的なユースケースには作り込まれた予測可能なエンタープライズワークフローを, 長尾のユースケースにはストリーミングUXを届ける。その核心に自己改善型エージェントがいる, という未来像で締めくくられました。
まとめ
このセッションでは、エンタープライズSaaS出身のEric氏ならではの視点で、以下のような話が語られました。
- AIの後に来るのは「より多くのソフトウェア」である
- コーディングモデルの倍加周期は7ヶ月で、Moore's Lawより速い
- 自己改善型ソリューションマシン (Planner/Generator/Evaluatorループ) でGCCすら再現できる
- Great Inversion: ソフトウェアコストのピラミッドが逆転する (実装が無料に近づく)
- Omega Integration: エージェントが継続的にすべてのシステムを繋ぎ続ける未来
- シンプルなハーネスに任せる (Bitter Lesson)
- 3つのドア: 既存の収益改善 < 並列実験 < プロダクトを真に良くする
- コンピューティングは流動的な継続サービスになる
以上、とーちでした。
