はじめに
Google Cloud Next '26のセッションにて、AnthropicのField CTO、Eric氏のセッションを聴講しました。
今回のセッションの内容ですが、個人的には「ソフトウェアの作り方そのものに関して、大きな発見と学びを得た」というように感じました。
イベント: Google Cloud Next '26（2026年4月、ラスベガス）
セッション: After software: Anthropic's vision for the next era of enterprise AI
登壇者: Eric（Field CTO, Anthropic）
Eric氏は冒頭でこう自己紹介しました。
"I'm a bit of an odd choice to give this presentation. I'm an old guy from the world of traditional computing and enterprise SaaS. I'm not an AI engineer."
（訳）自分はこのプレゼンを担当するには少し場違いだ。従来のコンピューティングとエンタープライズSaaSの世界出身の古い人間で、AIエンジニアでもない。
AIのインサイダーではなく、エンタープライズSaaS出身の経営者（Panopto創業CTO→CEO）が、フロンティアAIとエンタープライズSaaSの交差点で何が起きているかを語る。だからこそ、響く話だと感じました。
このセッションで語られたこと 一覧
このセッションは新機能発表型ではなく、「フロンティアAIがエンタープライズソフトウェアの経済構造をどう書き換えるか」を骨太に語るセッションでした。
| トピック | 中身 |
|---|---|
| Three Pillars | Anthropicが語る企業AI活用の3段階。社員を賢く→プロセスを賢く→新事業を生む |
| 3次元の指数関数 | 問題の複雑度、エージェントの稼働時間、ハーネスの複雑度。掛け合わせると7ヶ月で能力倍化 |
| エージェントの厳密定義 | LLMがループで動き、ツールを使い、ゴールに向かって進み、達成すると消える |
| Solutions Machine（GCC事例） | Opus 4.6が $20K のトークン・2週間でGCCのクリーンルームクローンを生成 |
| 自己改善ループ | Planner / Generator / Evaluatorの三役で品質を自己修復 |
| Great Inversion | 実装コストが99%→ほぼゼロへ反転。戦略・スコープ設定が99%に |
| Be Like Water | ソフトウェアが「形を持たない」流体に。MCPは"オメガ統合"への入口 |
| Claudeサービスを使用したデモ | 架空のSaaS企業の取締役会資料を、MCPサーバ×Claudeで自動生成 |
| The Bitter Lesson | モデルが賢くなるほどシンプルなハーネスが勝つ。Sonnet 3.7→4でシステムプロンプトを26%削減 |
| 三つの扉 | AI活用の方向性は「利益率上げる／並列実験する／磨き上げる」の3択 |
| Shannon Limit | コンピューティングは連続サービスへ。律速は「ユーザーの理解能力」 |
図：エンタープライズLLM APIの使用状況別市場シェア
Eric氏が共有した数字が象徴的でした。エンタープライズソフトウェアは史上もっとも速くスケールしたソフトウェアカテゴリで、2025年に約400億ドル規模。そのうちAnthropicは「主要プレイヤーの一社」と自認できる位置に来た。1年前に比べると、語り口の重心が「モデル」から「製品とエコシステム」に明確に移っています。
ここで強調したいのは、「Claudeが入っているプロダクト」がAnthropic製品とは限らないこと。Eric氏も明言しました。
"Not all of this is through Claude Code or coding agent. A lot of it is through other partners' agents and different pieces of software that pass through our models."
（訳）これらすべてがClaude Codeやコーディングエージェント経由というわけではない。多くはパートナー各社のエージェントや、我々のモデルを経由する様々なソフトウェアを通じて起きている。
CursorのARRが10億ドルを突破し、GitHub Copilot単体の売上がMicrosoftが買収した当時のGitHub全体を超え、Harveyが2026年に2億ドルARR近くまで来ている。コーディングと法務のレイヤーで、Claudeはすでに現実の業務プロセスに組み込まれている——これがNext'26時点の事実です。
図：エージェント型ビジネスの急拡大
エージェントの厳密定義
Eric氏が引用したAnthropic共同創業者Ben Mann氏の言葉が、このセッション内で私の中で印象に残った一節のうちの一つとなりました。
"To understand when to use agents, you just think about when you would hire a smart person and train them to do something."
（訳）エージェントをいつ使うべきかを理解するには、賢い人を雇って何かを訓練したくなる場面を考えればいい。
エージェントを使うべきタイミングは、「賢い人を雇って訓練するならこの仕事だな」と思える時。これだけ、シンプルです。
そのうえで、Eric氏はエージェントの厳密定義を提示しました。
An agent is a large language model running in a loop that continues to be called over and over. It uses tools. It has a goal. It is invoked, it loops, it uses tools, and it works until it achieves the goal or hits some barrier. And then it ceases to exist.
（訳）エージェントとは、繰り返し呼び出されながらループで動く大規模言語モデルだ。ツールを使い、ゴールを持つ。呼び出され、ループし、ツールを使い、ゴール達成か何らかの障壁にぶつかるまで動き続ける。そして消える。
図：エージェントの定義（現地撮影）
要素を抜き出します。
- ループする — 一回呼んで終わりではない
- ツールを使う — 世界の状態を変えられる（ファイル書き込み、API呼び出し）
- ゴールがある — 目標達成までやる
- 達成すると消える — その後、再度呼び出せるし、並列で複数走らせられる
「ゴール達成または障壁到達で終了する」——この終了条件の設計が、本番運用での暴走対策の核です。提案資料でエージェントを語るとき、曖昧な表現をしているケースをたまに見かけますが、Eric氏の定義はクリアでした。
Solutions Machine —— GCC事例から見える"$20Kで何が買えるか"
ここは本セッションのハイライトだと感じています。
Opus 4.6が、たった一つの指示「Build GCC」と$20K相当のトークンを与えられて、2週間でGCCのクリーンルームクローンを完成させた。
GCCとはオープンソース史における伝説のコンパイラのこと。
byte-for-byteでLinuxカーネルをコンパイルできるレベルで一致しなければ「成功」と認められない。一発でも誤差があれば失敗です。
仕組みは以下の通りです。
- 内側のループ：Claudeがエージェントとして、ゴール達成までループ
- 外側のループ：完成という大目標に向けて、サブゴールを設定し直す
これを抽象化すると、「複雑度Xの問題＋資本Y → 解決策」を返す機械が出来上がる。Eric氏はこれを"Solutions Machine"と呼びました。
参考：Building a C compiler with a team of parallel Claudes
図：The Solutions Machine（現地撮影）
さらに自己改善版の実験では、3つの役割をループに入れました。
図：The Solutions Machine 自己改善版
| 役割 | 仕事 |
|---|---|
| Planner | タスクを分解し、計画を立てる |
| Generator | 計画を実装し、動作を検証する |
| Evaluator | エンジニア／デザイナー視点で品質を評価する |
この3つがループすると、自己反復するだけでなく自己改善するハーネスになるということを、Eric氏はデモ動画で2件の実例を見せながら説明をしました。
1行のプロンプトを同じハーネスに10ラウンド通したとき、第1版から第10版でどこまで進化するかを比較するビフォー・アフター映像です。仕様書もワイヤーフレームも参考画像も渡しません。指示はたった一文で、人間からのフィードバックも挟まない。Planner / Generator / Evaluatorの3役が互いをチェックし合いながら推敲を重ねた結果を、横並びで見せるという内容でした。
- 「日本の桜祭りページを作って」 → 第1版はそれなり、第10版は美しい3Dページ
図：桜祭り Webサイト 第1版
図：桜祭り Webサイト 第10版
- 「オランダの美術館サイトを作って」 → 第1版は普通のサイト、第10版はOpenGL 3Dでギャラリー体験を再現したWebビュー
図：オランダの美術館 Webサイト 第1版
図：オランダの美術館 Webサイト 第10版
プロンプトは1行のみ。あとはループが磨き上げました。
The Great Inversion —— 経済構造が反転する
この章がセッションのクライマックスです。Eric氏はトーマス・エジソンの有名な言葉を引きました。
"Genius is 1% inspiration and 99% perspiration."
（訳）天才とは1%のひらめきと99%の汗である。
エンタープライズソフトウェアもずっとそうでした。1%のスコーピング・戦略判断、99%の実装・検証・運用。
図：高コスト体質な構造
ところが、と彼は続けます。
"What if it weren't? What if it was 99% the fun part and 1% the execution part because we had these abundant execution resources?"
（訳）もしそうでないとしたら？ 実行リソースが潤沢にあるおかげで、99%が楽しい部分、1%が実行部分になるとしたら？
そうなった場合、ピラミッドはひっくり返ります。
図：次世代のピラミッド：10倍のスケール
| 旧来のエンタープライズソフト経済 | Great Inversion後 | |
|---|---|---|
| 戦略・スコープ設定 | 1%（楽しい部分） | 99% |
| 実装・検証・運用 | 99%（汗の部分） | 1% |
| 判断基準 | 「LTV＞総コスト」を満たさないと作らない | 「作るべきか」だけが残る判断 |
作るべきかどうかを判断する時、これまでは「実装コストを上回るリターンが見込めるか」が決定的なフィルタでした。それが取り払われると、フィルタは「そもそも作る価値があるか」だけになる。経営判断のフィルタが、経済性から事業性に移ります。
私がみてきた提案書やディスカッション資料などでは、大半は「いくらで作れるか」「何ヶ月で出せるか」「ROIは何年で回収するか」が記載されていることが多かったかなと思います。
これは全て、実装にお金がかかる前提の問いなんだと振り返ると感じています。
実装がほぼ無料ととらえていけば、提案の中心の問いは「それを作って、お客さまにどんな体験を届けたいか」「事業をどう変えたいか」に置き換わり、お客さまから最初に飛んでくる問いが「これ、いくら？」から「これ、何ができる？何が変わる？」になっていく——そのような感覚です。
これは脅威ではなく、現場のSEにとってはむしろ面白くなる変化だと感じています。
デモ - 架空企業Syntaraが示した近未来
デモパートに入ります。架空の企業Syntara（ARR 1億ドルのデータプラットフォーム）が、新オーナーMeridian Growth Partnersから「取締役会パッケージを週次で出せ」と要求された設定です。
旧来のSyntaraは、営業／マーケ／カスタマーサクセスがそれぞれ自部門のCRMから資料を作っていました。部門ごとの数字は綺麗——営業は計画を上回る進捗、SQLからの商談化52.4%、マーケはMix改善、CSは10日アクティベーション82.3%。一見何の問題もない。
図：デモ 四半期受注 個別KPI
ところが全システムをMCPサーバでラップしてClaudeから横串で読ませると、構図が一変します。
- エンタープライズ層の10日アクティベーションは37.6%しかない（CSが「少し遅い」と表現していた数字の正体）
- マーケは「エンタープライズ比率を上げる」ことを目標にしているのに、そのエンタープライズで詰まっている
- 結果として、成長は減速し、構造的な問題になっている
Claudeはこの不都合な事実をシステム横断で発見し、「エンタープライズ・トライアルのオンボーディングが穴」とピンポイントで指摘した。1部門の中では見えなかった真実が、横串で見ると即座に浮かび上がる——これがMCP×Claudeの説得力です。
さらに面白かったのは、当日のデモでGoogle Sheets / Slidesへの出力用MCPサーバが未整備だったこと。Eric氏は「じゃあClaudeに作らせた」と数日間のプロンプトでMCP統合を即席で実装し、その場で取締役会資料をGoogle Slidesに自動生成しました。「自分で道具を作って、その道具で仕事をする」姿勢そのものがGreat Inversionの体現でした。
図：デモ レポート作成
図：デモ Google Slide作成画面
The Bitter Lesson —— ハーネスは"薄く"作れ
このセッションでもう一つ私の中に残ったのは、Sonnet 3.7→4の世代でAnthropic自身がシステムプロンプトを約26%削ったという話です。
Eric氏が言及した"The Bitter Lesson"（リッチ・サットンの古典的な記事を踏まえた最近のエッセイ）の主張はシンプル。
"As models get smarter, efforts to try to coerce them and outsmart them and place them in ever more complex harnesses to wring just a little bit more performance out of them, tend to backfire over time."
（訳）モデルが賢くなるほど、無理に従わせようとしたり、出し抜こうとしたり、より複雑なハーネスに押し込めて少しでも性能を絞り出そうとする努力は、時間とともに裏目に出る傾向がある。
モデルが賢くなるほど、ハーネスを複雑化して捻り出す性能向上は、長期的に裏目に出る。
これは現場で耳の痛い話です。私自身、提案で「プロンプトをガチガチに作り込んで誤動作を抑える」アプローチをよく使います。短期では効きます。でも3ヶ月後にモデルが賢くなった時、その作り込みが足を引っ張る——これがEric氏の警告でした。
三つの扉 —— エンタープライズが選ぶべき道
Eric氏が締めに提示した3つの選択肢。提案活動でそのまま使えるフレームなので、整理します。
図：開発者とプロダクトチームのための3つの扉
扉1：人員削減で利益率を上げる
- 何をする：人を減らし、同じアウトプットを少人数で出す
- 打率：高い。短期的にEBITDAは確実に伸びる
- 限界：Eric氏は「最も野心の薄い選択肢」と表現。守りの一手
扉2：並列実験で打席を増やす
- 何をする：コーディングエージェントで並列にPoC・プロトタイプを回す
- 打率：機能仮説の検証速度が上がる。リスクを早く減らせる
- 核心：「100%早くソフトを出荷できるわけではない。意思決定こそ難しい部分」とEric氏
扉3：プロダクトを"本当に偉大"にする
- 何をする：MVP止まりだったプロダクトを磨き続ける。10ラウンドで美しくなる
- 打率：刺されば世代を超える資産になる（Slackの導入経験談を引用）
- 核心：「愛されるプロダクトを作るチャンス」が、これまで企業ソフトには無かった
Shannon Limit —— コンピューティングが連続サービスになる
最後にEric氏は、クロード・シャノンに触れました。
"If you half-squint at the solutions machine... you can see the outlines of a new form of software: fluid, continuous delivery of the full capabilities of any computing platform and any combination of enterprise systems, with personalized user interfaces for the long tail of tasks."
（訳）ソリューション・マシンを少し目を細めて見れば、新しい形のソフトウェアの輪郭が見えてくる。あらゆるコンピューティング基盤と企業システムの組み合わせの全機能が、流動的かつ連続的に提供され、ロングテールのタスクにはパーソナライズされたUIが付く。
要約すると、以下のような未来像だと考えます。
- ユーザー体験は自然言語から始まる
- 共通ユースケースには磨かれた予測可能なエンタープライズワークフロー
- ロングテールにはストリーミング生成されるパーソナライズUI
- 多くの自己改善エージェントがClaudeで動く
- 律速はもはやコンピュータ側ではなく、人間が理解・関与できる帯域
シャノン限界は、最大情報伝達量の数学的上限。Eric氏は「コンピューティングの限界が、ユーザーの理解能力になる」と言い切りました。聴いていて、SF的でありながら、Syntaraデモの延長線で実装可能なロードマップに感じました。
ソフトバンクのエンジニアが、ソフトバンクの業務・サービスを支える技術をテーマに、現場の知見や取り組みを発信する技術ブログです。 2026年３月以前のブログ softbank.jp/biz/blog/cloud-technology/
Discussion