Gemma 4が来た――Googleのオープンモデル戦略は次の段階へ

はい、Gemma 4は本当に来ました。Google AI for Developers のリリースノートでは 2026年3月31日 付けで Gemma 4 の公開が記録されており、Google公式ブログの一般向け発表記事は 2026年4月2日 付けです。つまり、「Gemma 4が来た！」は誇張ではなく、まさにこの数日の最新動向です。 (ai.google.dev)

Gemma 4は、Google DeepMind が公開した新しいオープンモデル群です。Google はこれを、Gemini 3 の研究・技術を土台にした“最も知的なオープンモデル”と位置づけており、Apache 2.0 ライセンスで提供します。モデルは4系統に分かれ、モバイルやIoT向けの超軽量系から、PCやワークステーション向けの高性能系までを一つの家族として揃えています。 (deepmind.google)

---

まず何が出たのか

Gemma 4 のラインアップは次の4つです。小型モデルは「E」、中型MoEモデルは「A」という表記が付きます。Google公式モデルカードによると、E2B は実効 2.3B（埋め込み込みでは 5.1B）、E4B は実効 4.5B（埋め込み込みでは 8B）、26B A4B は総計 25.2B・推論時アクティブ 3.8B の MoE、31B Dense は 30.7B の密結合モデルです。小型2モデルは 128K コンテキスト、中型2モデルは 256K コンテキストに対応します。 (ai.google.dev)

モダリティも世代をまたいで整理されました。全モデルが テキストと画像 を扱え、動画はフレーム列として処理できます。さらに 音声入力は E2B と E4B にネイティブ搭載されており、音声認識や音声翻訳をローカル実行しやすい構成になっています。Google DeepMind の製品ページでは、小型モデルをスマートフォンや Raspberry Pi、Jetson 系デバイスなどのエッジ環境で動かす方向が明確に打ち出されています。 (ai.google.dev)

利用面でもかなり広く開かれています。Google AI Studio では 31B と 26B A4B を試せ、E2B/E4B は Google AI Edge Gallery で扱えます。重みは Hugging Face、Kaggle、Ollama などから取得でき、JAX、Keras、PyTorch、gemma.cpp、Google AI Edge、GKE などへの接続も公式に案内されています。 (deepmind.google)

---

Gemma 4のどこが新しいのか

1. 「軽いのに賢い」を本気でやりにきた

今回のキーワードは、Google自身の表現を借りれば “intelligence-per-parameter”、つまり「パラメータ当たりの知能」です。大きいモデルをそのまま配るのではなく、スマホで回るE系と、PCで前線級の推論を狙う26B/31B系に設計思想を分けています。31B/26B は推論・コーディング・エージェント用途を強く意識し、E2B/E4B は低遅延・省メモリ・省電力を重視しています。 (blog.google)

2. マルチモーダルが“実用品質”に近づいた

Gemma 3 でも画像理解は可能でしたが、Gemma 4 では画像の 可変アスペクト比 と 可変解像度 に対応し、OCR、文書解析、UI理解、チャート理解、手書き認識などがコア能力として前面に出ています。さらに画像の視覚トークン予算を 70 / 140 / 280 / 560 / 1120 から調整でき、軽い分類タスクから重い文書OCRまで、用途ごとに精度と計算量をトレードできます。 (ai.google.dev)

3. 長文処理がさらに伸びた

Gemma 3 の主力モデルは 128K コンテキストでしたが、Gemma 4 では 31B Dense と 26B A4B MoE が 256K コンテキスト に到達しました。Googleはこれを、長文ドキュメントやコードベース、リポジトリ丸ごとの入力に使える長さとして訴求しています。小型モデルも 128K を維持しており、エッジ側でも「短い命令だけを処理する小型モデル」から一歩進んだ設計です。 (ai.google.dev)

4. エージェント実装をしやすくした

Gemma 4 は ネイティブな function calling、構造化 JSON 出力、system ロール対応、そして thinking mode を備えています。モデルカードでは、Gemma 3 と比べて Gemma 4 は標準的な system / assistant / user ロールを使うことが明記されており、既存のチャットUIやエージェント基盤との整合性がかなり良くなっています。開発者にとっては、単に性能が上がる以上に、この「扱いやすさ」の改善が大きいです。 (ai.google.dev)

---

技術的な背景をどう見るべきか

Per-Layer Embeddings が小型モデルの肝

E2B/E4B の「E」は effective の意味で、見かけの総パラメータ数より、推論時に重い高速メモリへ載せる実効サイズを小さく見せる設計です。Googleの説明では、小型モデルは Per-Layer Embeddings（PLE） を使っており、各デコーダ層に小さな埋め込みを持たせることで、層を増やしすぎずに品質を上げつつ、GPU/TPU 側の高コストなメモリ使用量を抑えています。なお PLE は Gemma 3n で前面に出た技術で、Gemma 4 の小型モデルにも継承されています。 (ai.google.dev)

これは、単に「小さいモデル」ではなく、“モバイルで賢く動くように調整された小さいモデル” だということです。ローカル推論では、総パラメータ数よりも、VRAM やアクセラレータの高速メモリに何を載せるかが効きます。Gemma 4 のE系はそこをかなり意識した設計です。これは公式記述からの読み解きですが、Googleが Gemma 4 をスマホ・IoT・Raspberry Pi まで視野に入れている理由も、このメモリ戦略と整合しています。 (ai.google.dev)

26B A4B は「実質4B級の軽さで26B級の器」を狙うMoE

26B A4B は Mixture-of-Experts で、総パラメータは 25.2B ある一方、推論時に使うのは 3.8B アクティブです。モデルカードでは、128 の専門家のうち 8 がアクティブで、さらに shared expert を持つ構成とされています。Googleは、このモデルを 31B Dense より低遅延で、4B 級に近い速度感を狙うものとして説明しています。 (ai.google.dev)

この A4B が面白いのは、オープンモデルの定番トレードオフ――「速いけど弱い」か「強いけど重い」か――の中間をかなり本気で取りにきている点です。ローカル IDE、コーディング支援、半自律エージェントのように、そこそこ深く考えつつ応答速度も欲しい用途では、このモデルがいちばん実戦的かもしれません。これは公式スペックと用途説明に基づく推測ですが、Gemma 4 の主戦場はまさにそこに見えます。 (ai.google.dev)

長コンテキスト対応は注意機構の工夫で支える

Gemma 4 は、ローカルな sliding window attention とグローバル attention を交互に使う hybrid attention を採用し、最終層は常にグローバル attention になるよう設計されています。さらに長文処理時のメモリ最適化として、unified Keys and Values と Proportional RoPE（p-RoPE） を使うと説明されています。 (ai.google.dev)

要するに、Gemma 4 の長コンテキストは「ただ窓を広げた」だけではなく、速度・メモリ・全体把握のバランスを取るためのアーキテクチャ改善を伴っています。長文RAG、巨大リポジトリ解析、文書QAのようなユースケースで効いてくるのは、まさにこの種の工夫です。 (ai.google.dev)

---

性能はどれくらい伸びたのか

ここは冷静に見るべきですが、公式モデルカードの数字はかなり強いです。比較表では、Gemma 4 31B が MMLU Pro 85.2%、AIME 2026 89.2%、LiveCodeBench v6 80.0%、GPQA Diamond 84.3%、MMMU Pro 76.9% を記録しています。同じ表で比較対象になっている Gemma 3 27B（no think） は、それぞれ 67.6%、20.8%、29.1%、42.4%、49.7% です。長コンテキスト系の MRCR v2 8 needle 128k でも 31B は 66.4%、Gemma 3 27B は 13.5% で、世代差がかなり大きいことが示されています。 (ai.google.dev)

ただし、ここには注意もあります。これらは Google公式モデルカードの自己報告ベンチマーク であり、比較対象には “Gemma 3 27B (no think)” と明記されています。つまり、Gemma 4 の reasoning / thinking 機能が効く条件で優位が大きく出ている可能性があります。数字は強いですが、そのまま「どの実アプリでも同じ差が出る」とは限りません。 (ai.google.dev)

一方で、Googleは外部指標としても、2026年4月1日時点の Arena AI テキストリーダーボードで 31B がオープンモデル世界3位、26B が6位だと紹介しています。順位は日々変動し得ますが、少なくとも Google が Gemma 4 を「サイズの割に異様に強いオープンモデル」として打ち出しているのは確かです。 (blog.google)

---

Gemma 3から何が変わったのか

Gemma 3 は 2025年3月に 1B / 4B / 12B / 27B で公開され、画像入力、128K コンテキスト、140超言語、function calling などを備えていました。Gemma 4 はそこから一段進み、音声入力を小型モデルへ統合し、31B Dense と 26B A4B MoE を追加し、256K コンテキスト、thinking mode、system ロールのネイティブ対応、Apache 2.0 ライセンスまで含めて再設計した世代と見るのが妥当です。 (ai.google.dev)

Gemma 3 が「単一GPUやTPUで回せる高性能オープンモデル」を押し出した世代だったとすれば、Gemma 4 はそこからさらに、モバイル常駐AI・ローカルコーディング・エージェント基盤・企業内主権運用までを一つの製品戦略にまとめた世代だと言えます。これは公式発表内容を踏まえた分析ですが、今回の進化は単なるベンチマーク更新ではありません。 (blog.google)

---

いちばん大きな変化は、実はライセンスかもしれない

Gemma 4 で見逃せないのが Apache 2.0 への移行です。公式モデルカードと発表ブログは、Gemma 4 を Apache 2.0 で提供すると明記しています。これに対し、従来の Gemma Terms of Use では、配布や派生物の利用にあたって 使用制限の継承 など独自条件がありました。 (ai.google.dev)

この変更は、ベンチマークの数ポイント差以上に実務へ効きます。企業や公共機関がオープンモデルを評価するとき、性能と同じくらい重要なのが 法務の通しやすさ と データ主権 です。Google自身も、Apache 2.0 を「developer flexibility」や「digital sovereignty」の基盤として説明しています。したがって、Gemma 4 は性能だけでなく、導入障壁の低さ でも前進した世代だと言えます。これは公式説明に基づく評価です。 (blog.google)

---

どんな影響が出るのか

1. ローカルAIが一段実用寄りになる

E2B/E4B が音声・画像・動画フレーム理解を持ち、しかもオフライン運用を強く意識していることで、端末上の音声アシスタント、OCR、翻訳、現場作業支援、教育アプリのようなユースケースがかなり現実的になります。音声は最大30秒、動画は 1fps 換算で最大60秒と制限はありますが、逆に言えば「端末上で扱える実務的な範囲」を明確に定義した設計です。 (ai.google.dev)

2. ローカルコーディング支援が強くなる

Googleは 26B/31B を、IDE、コーディングアシスタント、エージェントワークフロー向けに明確に位置づけています。31B/26B の非量子化 bfloat16 重みは単一 80GB H100 に収まり、量子化版はコンシューマGPUでも動かせるとしています。つまり、クラウド常時接続ではなく、ローカル優先の開発支援がかなり現実的になります。 (blog.google)

3. Googleの“二本立て戦略”がはっきりした

Google公式ブログは、Gemma 4 を Gemini 3 技術に基づくオープンモデルとして紹介しつつ、Gemma は Gemini を補完する存在だと説明しています。また、Gemma 系ではここ1年で Gemma 3n、TranslateGemma、MedGemma 1.5、FunctionGemma、EmbeddingGemma、T5Gemma v2 などが次々に公開されています。これは、Google が Gemma を単発モデルではなく、オープンな基盤ファミリーとして育てていることを示します。 (blog.google)

Googleは発表の中で、Gemma はこれまでに 4億ダウンロード超、10万超の派生モデルを生んだと述べています。こうした規模感を見ると、Gemma 4 の意味は「Googleがまた一つモデルを出した」ではなく、すでに巨大化した Gemma エコシステムに新しい中核世代が入ったことにあります。 (blog.google)

---

とはいえ、注意点もある

まず、知識の新しさには限界があります。Gemma 4 の学習データのカットオフは 2025年1月 です。したがって、2025年以降の出来事や頻繁に変わる事実をそのまま知っているわけではありません。これは Gemma 4 に限らずオープンモデル一般の重要な注意点です。 (ai.google.dev)

また、Gemma 4 は安全性評価で Gemma 3 / 3n より大きく改善したとされていますが、モデルカード自身が、事実誤認、曖昧表現、バイアス、複雑タスクでの失敗の可能性を認めています。長いコンテキストは有利に働く一方、性能は与える文脈やタスク設定にも左右されます。実運用では、評価・ガードレール・人間の監督がまだ必要です。 (ai.google.dev)

---

今後の展望

今後の焦点は3つあると思います。第一に、Gemma 4 小型モデルが Android / Edge 側でどこまで実装事例を増やすか。Googleは AI Core Developer Preview を通じた Gemini Nano 4 との前方互換 にも触れており、オープンな Gemma と製品向け Nano 系の距離を縮めていく可能性があります。第二に、Gemma 4 ベースの派生モデルがどれだけ増えるか。第三に、Apache 2.0 化によって企業導入がどれだけ加速するかです。これは現時点での推測ですが、Gemma 4 は単なるモデル更新というより、Google のローカルAI戦略とオープンモデル戦略が合流した節目に見えます。 (blog.google)

---

まとめ

Gemma 4 の本質は、「軽量オープンモデル」から「配備先ごとに最適化された実戦的オープン基盤」への進化です。E2B/E4B は端末上のマルチモーダルAIを狙い、26B A4B/31B はローカルの高性能推論とコーディング支援を狙う。そこに 256K コンテキスト、thinking mode、system ロール、Apache 2.0 ライセンスが加わり、Gemma はかなり“使う前提”のモデル群になりました。Gemma 4は、Googleのオープンモデル路線が本気で第2フェーズに入ったことを示すリリースです。 (ai.google.dev)

---

主な出典

• Google公式ブログ「Gemma 4: Byte for byte, the most capable open models」 (blog.google)
  
• Google AI for Developers「Gemma 4 model card」 (ai.google.dev)
  
• Google DeepMind「Gemma 4」製品ページ (deepmind.google)
  
• Google AI for Developers「Gemma releases」 (ai.google.dev)
  
• Google AI for Developers「Gemma Terms of Use」および Gemma 4 の Apache 2.0 表記 (ai.google.dev)
  
• Google Developers Blog「Introducing Gemma 3n」系資料（PLE の背景） (developers.googleblog.com)

必要なら次に、
- Gemma 4 と Llama / Qwen / DeepSeek の比較
- Gemma 4 をローカルPCで動かす方法
- 開発者向けに用途別おすすめモデルサイズ
まで続けて整理できます。

以下、調査結果をもとにした解説記事です。

Adobeはなぜ hosts を触ったのか

PC Watch報道から読む、Creative Cloud“無断変更”騒動の本質

2026年4月2日、PC Watchは「Adobe CCがhostsファイルを無断で変更しているのではないか」という話題を報じました。記事によると、Creative Cloud利用者のPCでhostsファイルに detect-ccd.creativecloud.adobe.com を固定IPへ向ける記述が追加されている例が見つかっており、PC Watch自身も検証環境で3月18日更新の変更を確認しています。さらに、同種の報告は少なくとも2026年3月16日のReddit、3月21日のAdobeコミュニティでも確認でき、WindowsだけでなくmacOSでも見つかったとされています。 (pc.watch.impress.co.jp)

この件が強く反発された理由は、単に「勝手に書き換えたら気分が悪い」という話ではありません。hostsファイルは、OSがホスト名をIPアドレスへ解決する際に参照する低レベルの設定で、Windowsではまずhostsを確認し、そこに情報がなければDNSへ問い合わせます。つまり、hostsはDNSより先に効く“強い設定”です。Microsoftも、hostsの変更は名前解決に影響し得ると説明しており、PowerToysのHosts File Editorでも管理者権限がないと保存できない仕様になっています。 (learn.microsoft.com)

しかもhostsは、昔からマルウェアやアドウェアによる改ざん対象として知られています。Microsoftは、Windows Defenderがhosts変更を PossibleHostsFileHijack として検知することがあると案内しており、その理由として「マルウェアが悪意あるサイトへ誘導するためにhostsを書き換えることがある」からだと明記しています。したがって、たとえ今回の変更がAdobe自身による“正当な目的”だったとしても、セキュリティ運用の観点ではかなりセンシティブな行為です。 (support.microsoft.com)

ここで重要なのは、Adobe自身がこれまでhostsを「慎重に扱うべきもの」と位置づけてきた点です。Adobeのヘルプには、ライセンス認証や接続エラー時にhosts内のAdobe関連エントリを削除する手順が繰り返し案内されています。日本語ヘルプでも、誤って構成されたhostsがライセンス認証サーバーへの接続を妨げる可能性があるとして、Adobe関連エントリの削除や、管理者権限で動かす「Limited Access Repair tool」による修復を推奨しています。Adobeコミュニティでも2021年から、Fix Host File機能でadobe.com関連の記述を消す案内が出ていました。 (helpx.adobe.com)

つまり、Adobeの従来方針は一貫して「hostsにAdobe関連の行があると不具合の原因になり得るので、明示的に修復・削除する」というものだったわけです。今回の問題が厄介なのは、そのAdobe自身が、少なくとも一部環境では新しいAdobe関連エントリを自動で足しているように見えることです。しかも、修復ツールやCleaner Toolはユーザーが自分で実行する“明示的な操作”であり、Adobeもバックアップ取得や管理者実行を前提に案内しています。そこに、静かに書き換える挙動が重なると、整合性が崩れます。 (helpx.adobe.com)

では、この追加エントリは何のためだったのか。現時点でAdobeの明確な公式説明は確認できませんが、Reddit上では、Adobeサイト側のJavaScriptが https://detect-ccd.creativecloud.adobe.com/cc.png へのfetch成功・失敗で、Creative Cloudデスクトップアプリの有無を判定しているのではないか、という解析が共有されています。要するに、hostsにその名前解決が仕込まれていればアクセス成功、なければ失敗し、その結果を“Creative Cloudが入っているかどうか”の判定信号にしている、という見立てです。これはAdobe公式の確認ではなく、ユーザー側の解析に基づく推定ですが、報告されている追記内容とは整合しています。 (reddit.com)

この推定がもし正しければ、今回の問題は「ライセンス認証」そのものよりも、「Webとデスクトップアプリの連携確認」をどう実装するかという設計の問題です。実際、Adobeの企業向けネットワークエンドポイント文書は非常に詳細で、creativecloud.adobe.com、connect.ffc.adobeoobe.com、さらには detect.ffc.adobeoobe.com のような“検出系”に見える名前まで列挙しています。しかし、2026年3月27日更新版のその一覧には、少なくとも公開ページ上では detect-ccd.creativecloud.adobe.com は見当たりません。必要な通信先を公開ドキュメントで説明する仕組みがあるのに、その外側でhostsを書き換えるように見える点が、透明性への不信を招いています。 (helpx.adobe.com)

影響は個人ユーザーだけにとどまりません。今回の報告では、正規ライセンス利用者のWindows/macOS環境でも同じ記述が確認されていますし、Adobeコミュニティでは「hosts変更監視でアラートが上がった」という企業ユーザーの声もあります。Adobeの日本語コミュニティ記事でも、会社支給端末でhostsを修正する前にはIT管理者に相談するよう注意喚起しており、hostsが企業統制の対象であることはAdobe自身も理解しています。だからこそ、もし自動変更が本当に行なわれていたなら、エンドユーザーよりも先に情シスやEDR/監査の現場が問題視するのは自然です。 (community.adobe.com)

技術的背景として、私はもうひとつ別の流れも無視できないと見ています。Chromeは近年、ローカルネットワークやローカルで動くソフトウェアへのWebからのアクセスを、より厳しく制御する方向に進んでいます。2025年以降はLocal Network Accessの許可プロンプト導入が進み、「サイトがユーザー端末上やローカルネットワーク上のサービスに勝手に触れに行く」こと自体が、ブラウザ側で抑制される流れです。今回のAdobe実装がこれに直接対応したものだと断定はできませんが、少なくとも“Webページから補助アプリの存在を知りたい”という需要は今後も残り、その実装方法はますます難しくなるはずです。 (developer.chrome.com)

だから今後の争点は、Adobeがこの件をどう説明するかに尽きます。必要なのは、影響を受ける製品・バージョン、変更が入る条件、追加される行の意味、削除してよいかどうか、再追加条件、企業管理環境での推奨設定を明文化することです。Adobeにはすでにネットワークエンドポイント一覧や修復ツールのドキュメントという公式な告知経路があります。そこを使って説明すれば済む話であり、逆に言えば、それがないままシステムファイルへ手を入れる設計は、今のセキュリティ時代には受け入れられにくいでしょう。 (helpx.adobe.com)

要するに、この騒動の本質は「その3行が危険かどうか」だけではありません。もっと大きいのは、「システム設定の変更を、誰が、いつ、何のために、どこまでユーザーへ説明してよいのか」という信頼の問題です。hostsは小さなテキストファイルですが、そこはユーザーとベンダーの境界線でもあります。今回の件は、Creative Cloudの利便性やWeb連携の裏で、その境界線をどこまで越えてよいのかをAdobeに突きつけた事例だと言えます。 (pc.watch.impress.co.jp)

参考・出典

• PC Watch「Adobe CCがhostsファイルを無断で変更か。批判の声相次ぐ」 (pc.watch.impress.co.jp)
• Adobe Help Center「Creative Suite アプリケーションの接続エラーを解決する方法」「購入した Creative Cloud アプリケーションが体験版として表示される」「Limited Access Repair tool overview」「Network endpoints for Adobe apps & services」 (helpx.adobe.com)
• Adobe Community「Addition to /etc/hosts file」「Hostsファイルが起因で『体験版』もしくは『体験版の期限切れ』が表示される場合の対処方法」 (community.adobe.com)
• Microsoft Learn / Microsoft Support「Hosts File Editor utility」「Host Names and IP Addresses」「Hosts file is detected as malware in Windows Defender」 (learn.microsoft.com)
• Chrome for Developers「New permission prompt for Local Network Access」「Private Network Access update」 (developer.chrome.com)
• 観測・解析ソースとしてのRedditスレッド「Hosts file changes - due to Adobe themselves?」 (reddit.com)

必要なら次に、
- この記事をブログ掲載向けに整える
- もっとニュース記事風に短くする
- 情シス向けに「影響と対策」に絞って再構成する

のいずれかで書き直せます。

Block「From Hierarchy to Intelligence」徹底解説

AIは“人を助ける道具”から“会社を動かす仕組み”になれるのか

2026年3月31日に公開されたBlockの「From Hierarchy to Intelligence」は、AIを単なる業務効率化ツールとしてではなく、会社の調整機構そのものへ押し上げようとする、かなり野心的な文章です。著者はJack DorseyとRoelof Botha。読み物としては経営思想のエッセイですが、実質的には組織設計、データ戦略、AIエージェント基盤、プロダクト戦略を一体で再定義する宣言文だと読むべきです。(block.xyz)

しかも公開タイミングが重要です。Blockは2026年2月末、AI活用を前提にした再編の一環として4,000人超の削減を公表しており、Bloomberg Lawも今回の文章を「中間管理職をAIで置き換える構想の提示」として扱いました。したがってこれは単なる抽象論ではなく、すでに動いている組織改革を理論化した文書と見るのが自然です。これは私の解釈ですが、時系列から見てかなり妥当です。(apnews.com)

---

まず結論：この記事が本当に言いたいこと

この文章の核心はシンプルです。企業の階層構造は、本来「人が人に命令するため」ではなく、「情報を運ぶため」に作られてきた。そして今は、AIがその情報ルーティング機能を代替できる水準に近づいたので、会社をヒエラルキーではなく“知能”として組み替えられる、という主張です。Block自身の表現では、既存組織にAIの副操縦士を配るのではなく、会社そのものを intelligence、あるいは mini-AGI のように作ることを狙っています。(block.xyz)

この見立ては、歴史の読み替えから始まります。本文はローマ軍、プロイセン参謀、鉄道、テイラー主義、マトリクス組織、Spotify/Zappos/Valveの実験までたどりますが、要点は一つです。階層組織は情報流通の制約から生まれたということです。実際、Daniel McCallumが1850年代にニューヨーク・アンド・エリー鉄道で作った組織図も、長距離運行で増えたデータと事故リスクを処理するための情報設計として登場しました。(block.xyz)

---

Blockが描く新しい会社の設計図

1. 会社は4層でできる

記事の中で最も重要なのは、Blockが会社を次の4層で捉え直している点です。
Capabilities は決済、融資、カード発行、銀行、BNPL、給与などの金融プリミティブ。
World model は会社の状態と顧客の状態を表す内部表現。
Intelligence layer は、その時点の顧客状況に応じて必要な能力を合成する層。
Interfaces はSquare、Cash App、Afterpay、TIDAL、Bitkey、Protoのような接点です。記事は、価値の中心はUIではなく、モデルと知能層にあると明言しています。(block.xyz)

ここで面白いのは、従来の「製品チームがロードマップを引く」発想をかなり強く否定していることです。Blockの考えでは、intelligence layer が顧客のための解決策を組み立てようとして、必要な capability が足りず失敗した場所が、そのまま次の開発課題になります。つまり、プロダクトマネージャーの仮説ではなく、顧客現実そのものがバックログを生むという設計です。(block.xyz)

2. world model は2つある

Blockは world model を2つに分けています。
ひとつは company world model。これは社内の意思決定、議論、コード、設計、計画、進捗といった機械可読な成果物から、会社の状態を常時更新するモデルです。
もうひとつは customer world model。Cash App 側の利用者、Square 側の加盟店、さらに加盟店運営データまで含めて、顧客や事業者の金融状態を表現するモデルです。(block.xyz)

Blockがここで強調するのは、金の動きは“正直なシグナル”だという点です。アンケートや広告クリックより、支出・送金・借入・返済のほうが、実際のニーズに近い。さらにInvestor Day資料では、Blockの接続されたエコシステムがCash Appの5,800万人アクティブとSquareの加盟店ネットワークを組み合わせることで独自価値を作ると説明されています。要するにBlockは、単なる社内自動化ではなく、商流と金流の両側を見られる“経済グラフ”を自社の土台だと見ているわけです。(block.xyz)

3. 人間の役割は3つに減る

この構想では、人の役割もかなり大胆に整理されます。
IC は各レイヤーを作り運用する専門家。
DRI は期間を区切って横断課題と顧客成果を持つ責任者。
player-coach は手を動かしながら人材育成も担う存在です。
記事は、従来の中間管理職が担っていた“状況把握と情報伝達”は world model が引き受けるので、恒常的な中間管理レイヤーは不要だと述べています。(block.xyz)

ただし同時に、記事は人間を不要だとは言っていません。人は「edge」に残る。つまり、AIがまだ触れない現実、たとえば直感、文化的文脈、信頼関係、部屋の空気、そして倫理判断や高リスク判断は人が担う、という位置づけです。これはかなり重要で、Blockの構想は「完全自動化」ではなく、判断責任の高い場所に人を残しつつ、調整コストをAIで圧縮するものです。(block.xyz)

---

技術的背景：なぜ今この話が出てくるのか

world model という発想自体はAI研究の中核にある

Blockの world model という言葉は比喩ではありません。AI研究で world model は、環境の時空間的な表現を内部に持ち、それを予測や計画に使う考え方として使われてきました。2018年の「World Models」はそれを「圧縮された時空間表現」として提示し、最近の研究でも world model は記憶・推論・行動計画・人間との協調の中核だと整理されています。Blockはこの概念を、物理環境やロボットではなく、企業運営と金融顧客の理解へ移植しているわけです。(arxiv.org)

それを実装可能にするのが、MCPとgooseのようなエージェント基盤

この構想を単なる思想で終わらせないのが、Blockのエージェント基盤です。AnthropicのMCPは、AIアプリをデータソース、ツール、ワークフローへ接続するためのオープン標準で、Anthropic自身はこれを「AI向けのUSB-C」のようなものと説明しています。Blockのオープンソース説明によれば、同社はMCPのRust実装に貢献し、goose拡張の基盤としてもMCPを使っています。(docs.anthropic.com)

gooseはその上で動く、Block発のオープンソースAIエージェントです。GitHubの公開情報では、gooseはローカルで動く拡張可能なエージェントで、コードの生成だけでなく、実行、編集、テスト、外部API連携まで自律的に扱え、どのLLMとも組み合わせられます。2026年4月初旬時点のGitHub表示では star は3.39万、fork は3,200超です。Blockの最近の発表では、コミュニティは数千人規模に拡大し、外部コントリビューターは数十人、Databricksやスタートアップ、大学研究室にも採用が広がっているとされています。(github.com)

オープン標準戦略もかなり本気

さらに2025年12月には、OpenAI、Anthropic、BlockなどがLinux Foundation配下でAgentic AI Foundation（AAIF）を立ち上げました。OpenAIはAGENTS.md、AnthropicはMCP、Blockはgooseを持ち寄り、エージェント基盤を単一企業の私有インフラにしない方向を打ち出しています。Blockの今回の論考は組織論に見えて、実際にはこのオープン標準戦略とも強く結びついています。閉じた社内自動化ではなく、企業知能のOSを標準化された部品で組み立てる発想だからです。(openai.com)

---

この記事が現実味を帯びる理由

Blockがここまで強気なのは、すでに社内でAI活用の数字が出ているからです。2025年Investor Day資料では、エンジニア1人あたりの週次コード変更数の中央値が2025年5月から10月中旬にかけて30%増え、Q3時点で約7,500人が毎週AIツールを使い、11月時点ではコード提出の90%以上が部分的または全面的にAI支援を受けていると示されました。別のInvestor Dayまとめでは、10,000人超の社員のうち6,500人超がgooseを毎週使い、エンジニアは週8〜10時間を節約し、手作業を約25%減らしたとされています。さらに2026年3月のgoose grant program発表では、gooseが開発時間を50〜75%短縮し、全社員の60%が週次で使っているとBlockは述べています。母集団や時点は同一ではありませんが、少なくともAIが周辺実験ではなく、日常運用の中心に入っているのは確かです。(block.xyz)

また、顧客向けプロダクトにもすでにその片鱗があります。Square AI は売上データに外部の天気、イベント、ニュース、レビューを重ねて示唆を返す方向へ進化しており、Moneybot はCash App内の行動に基づく文脈的な提案を返すAI機能として紹介されています。これはまさに、記事がいう intelligence layer が状況に応じて capability を組み合わせる、という考え方の初期実装に見えます。(investors.block.xyz)

---

ただし、難所はかなり多い

1. 金融でやる以上、規制・公平性・説明可能性が重い

この構想が難しい最大の理由は、Blockが扱うのが金融だからです。記事で capability に挙がっているのは決済、融資、カード発行、銀行、BNPL、給与で、そこには信頼性・コンプライアンス・性能目標が前提として組み込まれています。しかもBlockは2026年1月時点で、顧客向け提供信用額が累計2,000億ドルを超えたと公表しています。AIが先回りして融資や返済条件を提案する世界は魅力的ですが、その分だけなぜその提案に至ったのか、誰に不利益が出るのか、偏りはないかが厳しく問われます。(block.xyz)

2. エージェントは便利だが、攻撃面も一気に広がる

goose自身のセキュリティ文書はかなり率直で、開発者エージェントはローカルマシン上でコード実行や操作を行うため、通常のチャット型LLMより高いリスクを持つと警告しています。Blockは、専用VMやコンテナで動かすこと、人間確認を要求すること、生成コードをレビューすること、信頼したMCP拡張だけを使うことを推奨しています。さらに2025年のMCP安全性監査のプレプリントでは、悪意あるMCPサーバがコード実行、遠隔操作、認証情報窃取に誘導しうると示されています。つまり、会社を知能化するほど、会社全体の攻撃面も知能化してしまうのです。(github.com)

3. 中間管理を削っても、統治の問題は消えない

記事は中間管理の恒久レイヤーを不要にすると言いますが、人材育成、評価、責任の所在、優先順位の衝突が消えるわけではありません。最近の経済学プレプリントでも、AIが調整コストを圧縮すると管理スパンの拡大や組織再設計は起きうる一方、その恩恵が広く配分されるか、少数に集中するかは制度設計次第だと論じられています。要するに、AIが階層を縮めることと、組織統治が簡単になることは別問題です。Blockが player-coach を置くのはその自覚の表れですが、ここは今後もっとも実務差が出る部分でしょう。(block.xyz)

---

この記事の本当の射程

私がこの文章を面白いと思うのは、AI導入の話を「何%効率化できるか」から、「会社は何によって会社であるのか」へ引き上げている点です。Blockは、製品群の集合ではなく、金融 capability と proprietary data と agentic intelligence を持つ一つの計算機械として自社を捉え直そうとしている。ここまで明確に言い切った大企業の文章は、かなり珍しいです。(block.xyz)

同時に、これはBlock特有の条件にも強く依存しています。remote-firstで成果物が機械可読であること、Cash AppとSquareの両面データを持つこと、gooseやMCPのようなエージェント基盤を自前で持つこと、そしてその上で組織再編に踏み込む経営判断があること。この4つが揃わない企業が、そのまま真似しても成功するとは限りません。だからこの文章は「未来の一般解」というより、Blockという会社が自分の持ち物に最適化して描いた、かなり解像度の高い特殊解として読むのが正確です。(block.xyz)

---

今後の展望

今後の注目点は3つです。
第一に、社内向けの知能化が、Square AI や Moneybot のような顧客向け intelligence layerへどこまで本格転写されるか。(investors.block.xyz)
第二に、MCP・goose・AGENTS.md・AAIF のようなオープン標準の陣営がどこまで実運用の主流になるか。(docs.anthropic.com)
第三に、金融とエージェントを結ぶための監査性・安全性・規制整合性を、Blockがどこまで実務レベルで示せるかです。(github.com)

もしBlockがこれを実現できれば、今回の記事は単なる話題作ではなく、「AI-native企業」の最初期設計書として後から読み返される可能性があります。逆に失敗すれば、「管理層を削っても、現実世界の複雑さはモデルに吸収しきれなかった」という教訓になるでしょう。いずれにせよ、この文章は2026年時点のAI経営論の中でも、かなり重要な一次資料です。(block.xyz)

---

主要出典

• Block「From Hierarchy to Intelligence」本文。公開日、著者、4層構造、3役割、world model 構想の中核。(block.xyz)
  
• Block Investor Day 2025「AI & Engineering Excellence」資料。AI活用の社内指標と製品展開の方向。(block.xyz)
  
• BlockのInvestor Day総括記事。gooseの週次利用人数や時間削減の説明。(block.xyz)
  
• Blockのgoose関連記事とGitHub公開情報。gooseの機能、採用状況、コミュニティ規模。(github.com)
  
• AnthropicのMCP公式ドキュメント。MCPの定義とエコシステム上の位置づけ。(docs.anthropic.com)
  
• OpenAIのAAIF発表。AAIFの設立目的と、MCP・AGENTS.md・gooseの寄贈。(openai.com)
  
• gooseのSECURITY.md と MCP安全性監査プレプリント。エージェント運用の主要リスク。(github.com)
  
• McKinseyのDaniel McCallum論文。組織図を情報問題への解として読む歴史的背景。(mckinsey.com)
  
• APとBloomberg Lawの報道。2026年2月の人員削減と、今回の論考が置かれた文脈。(apnews.com)

必要なら次に、この記事を
1) もっとビジネス寄りに要約する版、
2) 技術アーキテクチャ中心に図解風で整理する版、
3) 日本企業への示唆に絞った版、
のどれかに書き換えられます。

ディズニー×OpenAI「Sora」提携解消報道をどう読むべきか

提供URLの記事を起点に、事実関係・技術背景・業界への影響を整理する

ARTnews JAPANの2026年3月30日付記事は、OpenAIの動画生成AI「Sora」の終了が、2025年12月11日に公表されたディズニーとの大型提携と10億ドル出資計画を事実上吹き飛ばした、という流れを描いています。大枠は確かに裏取りできます。2025年12月11日、ディズニーとOpenAIは、200超のディズニー／マーベル／ピクサー／スター・ウォーズのキャラクターをSoraで使える3年契約と、ディズニーによる10億ドルの出資計画を公式発表しました。さらに2026年3月24日には、APやReutersがOpenAIによるSora終了・縮小方針と、それに伴うディズニー側の提携解消コメントを報じています。もっとも、ここで重要なのは、10億ドル投資は公式文書上「最終契約の交渉、社内承認、通常のクロージング条件」に従う予定案件で、完了済み投資ではなかった点です。つまり、正確には「成立済みの投資が白紙化した」というより、「進行中の大型計画が崩れた」と捉えるほうが実態に近いです。 (artnewsjapan.com)

まず、提供URLの記事の核は3つあります。第1に、Soraが終了し、ディズニーとの提携も解消に向かったこと。第2に、背景には収益性・計算資源・権利処理の難しさがあること。第3に、その結果として動画生成AIの主導権争いがGoogleなど他社に有利に動く可能性があることです。ここで第1点はかなり強く確認できますが、第2点と第3点は、公式説明というより報道各社や業界分析に基づく解釈です。Reutersは、OpenAIが企業向け事業に重点を移し、年内の市場デビューを意識していると報じていますが、OpenAI自身は停止理由を詳しく公表していません。したがって、動機の部分は「有力な観測」として読むのが妥当です。 (artnewsjapan.com)

この件をやや複雑にしているのは、2026年3月31日現在のOpenAI公式ドキュメントが、停止報道と完全には噛み合っていないことです。OpenAIの公式サイトにはいまなお「Sora 2」の概要ページがあり、3月23日付の安全性解説ページも公開されたままです。さらにヘルプセンターでは、3月13日に米国で「Sora 1」を終了して「Sora 2」に一本化したFAQが残っており、リリースノートには3月19日付の新しい編集機能追加も記載されています。つまり、3月24日の停止報道は確かに広く出ている一方、公開された一次資料だけを見ると「Soraブランド全体が完全消滅した」とまでは断言しにくく、少なくとも公開文書の更新は追いついていません。ここは、提供URLの記事を読むうえで最も大事な注意点です。 (openai.com)

では、そもそもSoraとは何だったのか。OpenAIの技術資料によれば、Soraは動画を低次元の潜在空間に圧縮し、それを時空間パッチに分解して扱う「拡散トランスフォーマー」です。画像も「1フレームの動画」として同じ表現に載せられるため、異なる長さ・解像度・アスペクト比の映像を一つの枠組みで学習できます。2024年の技術報告では、こうした設計によって3D的一貫性、長い時間の整合性、物体の永続性、さらには簡易な“世界シミュレーション”に似た性質が現れると説明されました。ただし同じ報告書は、ガラスが割れる、食べた跡が自然に残る、といった基本物理ですらまだ破綻があるとも認めています。Soraが衝撃的だったのは万能だからではなく、「映像生成が単なる短尺アニメーションから、世界モデルらしきものへ進み始めた」と感じさせたからです。 (openai.com)

Sora 2では、その方向性がさらに強まりました。OpenAIのSora 2 System Cardによると、Sora 2は物理精度、リアリズム、音声同期、操作性、スタイルの幅を強化し、sora.com、iOSアプリ、将来的にはAPIでの提供を想定していました。同時に安全対策も大幅に強化され、プロンプト・動画フレーム・音声書き起こしを横断してモデレーションをかけ、未成年関連は閾値を厳格化し、C2PAメタデータや可視ウォーターマークも導入しています。さらに実在人物の扱いでは、公開人物の生成制限、同意ベースの「characters」機能、非同意ヌードや詐欺目的を抑える分類器など、映像AIが直面する最も厄介な論点——肖像・声・未成年・ディープフェイク——に真正面から向き合っていました。技術の凄さと同時に、運用コストが高くならざるをえない設計でもあったわけです。 (cdn.openai.com)

ディズニーがこの技術に惹かれた理由も、公式発表を読むとよく分かります。両社の2025年12月11日の発表では、Soraは200超のキャラクター、コスチューム、小道具、乗り物、象徴的な環境を使った短尺ファン動画を生成でき、その一部はDisney+でも配信予定でした。加えてディズニーはOpenAIの主要顧客となり、API活用や社内でのChatGPT導入も進める構想でした。つまり、これは単なる「話題作りの出資」ではなく、IPライセンス、配信、社内業務、将来の体験設計を束ねた包括提携でした。ただし同じ文書は、俳優本人の肖像や声は契約対象外であり、投資も最終契約・承認前段階だと明記しています。ディズニーは最初から、“何でもAI化する”のではなく、“法的に整理しやすい範囲からIPを開く”設計をしていたと見るべきでしょう。 (investors.thewaltdisneycompany.com)

この慎重さの背景には、ハリウッド全体の規制・権利保護の流れがあります。カリフォルニア州は2024年に、存命のパフォーマーのデジタル複製に同意を必要とするAB 2602と、故人のデジタル複製をめぐるAB 1836を成立させました。さらに連邦レベルでも、2025年にはNO FAKES Actが議会に提出され、本人の声や容姿に酷似した無断デジタル複製への対処が進められています。映像生成AIは「作れるか」だけでなく、「誰の顔と声を、どの条件で、どこまで使えるか」が事業の核心になっており、Soraのようなサービスはモデル性能だけでは勝ち切れません。提供URLの記事が指摘する“ディズニーの慎重姿勢”は、感情論ではなく、法制度と契約実務の帰結でもあります。 (gov.ca.gov)

では、なぜOpenAIはここで引いたのか。公式の断定はないものの、構造的な理由はかなり見えています。Reutersは、OpenAIが企業向け事業に重心を移しつつあると報じました。一方で、動画生成はテキスト生成よりはるかに重く、Runwayも2026年1月に「より長いシーケンスを生成するにつれて、計算需要は劇的に増える」と説明しています。OpenAI自身もSora 2発表時に、無料提供を始めつつも利用は計算資源の制約を受けるとしていました。要するに、動画生成は“デモとしては強い”が、“巨大消費者向けサービスとして回す”には、GPUコスト・モデレーション・著作権・コミュニティ運営が一気にのしかかる。もしOpenAIが本当にSoraアプリを畳むなら、それは技術撤退というより「独立した動画SNS／動画生成事業としては採算とリスクが合わなかった」という判断の可能性が高いです。これは推論ですが、かなり自然な読みです。 (investing.com)

もっと重要なのは、Soraの後退が「動画生成AIの後退」を意味しないことです。Googleは2026年1月時点でVeo 3.1をGemini、API、Vertex AI、Flow、Google Vidsへ広げ、縦動画、1080p/4K、音声、SynthID透かしまで含めた制作基盤へ育てています。Adobe Fireflyも2026年3月に、Adobe製モデルに加えてGoogle、Runway、Klingなど30超のモデルを束ねる“制作環境”として拡張しました。Runway自身もGen-4.5やworld model研究を前面に出しています。ここから見えるのは、AI動画の主戦場が「単体アプリ」から「制作ワークフロー統合」へ移っていることです。提供URLの記事が示す“Google優位”は少し単純化されていますが、“OpenAIのSoraアプリが沈んでも市場全体はむしろ再編・高度化している”という見方はかなり正しいです。 (blog.google)

今後の展望を一言で言えば、「映像生成AIは消えない。ただし、無制限に開かれた遊び場としてではなく、権利管理・来歴証明・編集機能・企業利用を前提に再構成される」です。OpenAIの公開ページがなおSora 2を掲げ、3月23日に安全機能を詳説していたことを踏まえると、完全な技術撤退よりも、サービス形態の再編——たとえば独立アプリ縮小、限定提供、あるいは他製品への統合——のほうが筋が通ります。ただし、3月24日の報道以後の公式一次資料がまだ十分そろっておらず、アプリ・API・Webのどこまでがいつ止まるのかは、現時点では断定できません。この不確実さも含めて、提供URLの記事は「大筋は当たっているが、最終形はまだ流動的」と読むのが最も正確です。 (apnews.com)

主要出典

• ARTnews JAPAN掲載記事（2026年3月30日）。 (artnewsjapan.com)
• Disney / OpenAIの2025年12月11日公式発表。 (investors.thewaltdisneycompany.com)
• OpenAI公式のSora 2概要・System Card・安全性解説・FAQ・リリースノート。 (openai.com)
• AP、Reutersによる2026年3月24日の停止報道。 (apnews.com)
• Google、Adobe、Runwayの公式ブログ／製品情報。 (blog.google)

必要なら次に、
1) この記事をブログ掲載向けに整えた完成稿
2) もっと技術寄りにした版
3) 5分で読める要約版
のどれかに書き換えます。