Web4.0は、AIが支配する世界ではない — 大店モデルとAIBizOps【2026年11月更新】

はじめに

この1年で、AIの風景は急に見通しが悪くなった。

正直に言えば、だいぶモヤっとしてきた。どれがモデルなのか。どれがオーケストレーターなのか。どれがUIなのか。何がWeb3で、何がWeb4なのか。AIが主役なのか、仕事が主役なのか。単発の比較記事をいくら読んでも、頭の中に地図ができない。

なので、一度整理することにした。この記事の目的は「どのLLMが最強か」を決めることではない。いま起きている変化を歴史軸と階層軸から並べ直し、人間がどこに立ち、何を選び、何を委ねるのかを見える形にすることにある。

結論から言えば、いま起きているのは「賢いチャットボットが増えた」という話ではない。目的を持つ人間の上に、差配する層、考える層、手を動かす層が積み上がり、Webが一種の組織になり始めた、という話である。

Web4.0とは何か — 番号の整理

Web1.0〜3.0の流れ

Web1.0は、読むためのWebだった。静的なページがあり、ユーザーは基本的に受け手だった。基礎にあるのはHTTP、HTML、URL、TCP/IPといった、情報を届けるための土台である。

Web2.0は、参加するWebだった。ブログ、SNS、UGC、コメント、共有。この時代を支えた代表格がAjaxであり、画面遷移なしでデータをやり取りし、Webアプリを「アプリらしく」見せることができるようになった。AjaxはWeb2.0の産物であり、Web3ではない。

Web3は「分散化・所有権・価値移転」のレイヤーだった。ブロックチェーン、スマートコントラクト、ウォレット、トークン。その本質はAPIそのものではなく、分散型の信頼と所有権の構造にある。

APIはWeb3なのか

このあたりで多くの人が一度ひっかかる。「API中心になった世界」がWeb3なのか、と。答えは半分Yesで、半分Noだ。API自体はWeb2.0の頃からある。REST、OAuth、SaaS連携は、Web2.0以降の発展のなかで普及した。だから「API＝Web3」と言い切るのは歴史的には正確ではない。ただしAPIが「人間向け画面の裏方」から「機械間で直接価値とデータをやり取りするレイヤー」に昇格したという意味では、Web3で起きた変化は大きい。LLMはそのレイヤーの上に乗った。

Web4.0 = Agentic Web

• Web1.0：土管そのもの（HTTP/HTML）
• Web2.0：土管の使い方革命（Ajax＋REST＋SaaS API）
• Web3.0：価値と信頼のための新しい土管（ブロックチェーン／スマコン）
• Web4.0：土管の上で動く頭脳（LLM・AIエージェント）

現在の生成AIトレンドを「Web3」と呼ぶのは少しずれる。生成AIの波はむしろWeb3の上に現れた「Web4.0」あるいは「Agentic Web」として理解したほうが収まりがいい。ここでの主役は、人間がクリックして回るWebではない。AIエージェントがAPIやブラウザやデータベースを横断して、目標に向かって動くWebである。

一番上から見た景色

Web4.0を最上位から見たとき、下位層はすべてコントロール可能な対象に見える。LLMやAIエージェントは、検索、計算、記憶、ブラウザ操作、社内API、外部SaaSまで、ひとつの目的に沿って呼び出し、組み合わせ、再試行できるようになりつつある。ただし「支配している」という言い方は強すぎる。できるのは、公開されたAPI、許可された権限、用意されたツールの範囲で、委任された範囲で動くことだけだ。下位層は「完全な支配下」ではなく、「呼び出し可能な状態」にある。

LLMオーケストレーションの階層 — 大店モデル

LLMの使い勝手を決めるのは差配力

いまのLLMの使い勝手を決めているものは何か。答えは、単純な賢さではない。差配力——オーケストレーション能力だ。ユーザーの目標を受け取り、それをサブタスクに分解し、何を自分で考え、何を別のツールに投げ、どこで外部知識を読み、どのタイミングで確認を求め、どこで再試行するか。この一連の差配がうまいほど、LLMは「使える」と感じられる。

L1〜L5の配役

ここで一度、大店モデルの全体像を俯瞰しておきたい。LLMオーケストレーションを江戸時代の大店（おおだな）の組織になぞらえ、L1（主人）からL5（従業員）までの5階層に整理したものである。各層が何を担い、IT的には何に対応し、代表例として何が挙がるかを一枚の表で押さえておくと、以降の議論が立体的に見えてくる。

層	商家の役職	ITな実体	代表例（2026年11月時点）
L1	主人	人間ユーザー。目的・制約・評価基準を決める	あなた自身
L2	大番頭	オーケストレーター（司令塔ハーネス＋最上位判断モデル）。複数モデル・サブエージェント・ローカル処理を統括差配	Antigravity（進行・統括／Gemini 4 Argon + 3.8 Flash + Google AI Ultra）。業界製品例は Perplexity Computer、Copilot Studio、Manus
L3	番頭	個別LLM（思考・専門判断の頭脳）。専門性を持つ推論・監査・実装モデル	Gemini 4 Argon / 3.8 Flash、GPT-6 Astra / 6.1 Sol / 6.1 Terra、Claude Opus 5.5 / Sonnet 5.5、Grok 4.7、Llama 4、MiniMax M2.5
L4	手代・丁稚	実行ハーネス（手綱・肉体）＋オンデバイス軽量LLM。CLI実行、決定論的ラッパー、ローカル下ごしらえ、ブラウザ操作、MCP	Claude Code CLI、Codex CLI、決定論的Pythonハーネス＋ローカルLLM（Qwen 3.8 27B）、Comet、Atlas、MCPサーバー群
L5	従業員（商いの土台）	API、DB、SaaS、EDI、ブロックチェーン、HTTP	社内API、Web3基盤、REST SaaS

※ AIBizOpsシリーズ間の層番号対照について：本記事（第1弾）および第2弾における L1〜L5 は、上表の通り人間（主人 L1）から商いの土台（L5）へ至るトップダウンの「組織役割階層（大店モデル）」を指す。一方、第4弾（2軸JDマトリクス論文）における Layer 0〜Layer 3 は、OS・ハードウェアから母艦環境へ積み上げるボトムアップの「物理システム実行レイヤ」（Layer 0=macOS/SSOT［L5相当］、Layer 1=オンデバイス27B推論［L4丁稚相当］、Layer 2=外部監視・CLIハーネス［L3/L4相当］、Layer 3=統合母艦Antigravity［L2大番頭相当］）を表している。

L1 主人層 — 目的と評価基準を決める

L1は人間ユーザー、つまり主人である。AIBizOpsの出発点であり、同時に終着点でもある。「何を成功させたいのか」「どんな制約があるのか」「どの基準で評価するのか」——この三つはL1にしか決められない。下の層をいくら豪華に揃えても、主人がここを曖昧にした瞬間、大店は空回りする。AI時代に人間の仕事が残るのは、この層だからである。

L2 大番頭層 — 進行役と業界の製品

大番頭は単体LLMではない。「複数の番頭を束ねる進行役」として理解したほうがいい。筆者の運用でも、この層は半年で大きく進化した。2026年9月時点では進行のプライマリがGrok Bot、週次枠が尽きたあいだの補完がAntigravity（agy）だったが、2026年10月にはAntigravityに最上位モデル「Gemini 4 Argon」が到来し、Google AI Ultra（レート制限5倍）へ昇格したことで、Antigravity（agy）が単一の大番頭（正室1トップ）として全工程を統括する体制に一本化された。

同時に、手元の専門実務を担うClaude、Codex、Grokは、もはや個別のブラウザ画面では開かず、すべてAntigravityからL4の専用ハーネス（Claude Code CLI／Codex CLI／Grok Build CLI）でしか使わない形に統一された。なお、GrokとGrok Botは同一契約（The X Subscription）で使用量の枠が共通化したが、Antigravityの差配が軌道に乗り、Codex（GPT-6 Astra／6.1 Sol）の独立監査・構成力が高まったことでGrok姉妹の出番がほぼなくなり、10月下旬に解約手続きを済ませた（11月13日の更新日をもって有料契約終了・予備役へ移行）。

また、「最初から20以上のモデルを束ねるPerplexity ComputerをL2の大番頭に据えればよいのではないか」と思う読者もいるかもしれない。実際に筆者はPerplexity Computer（Mac版のHybrid Compute含む）も徹底検証したが、クレジット消費の激しさに加え、手元のローカルモデル（27B）が上流のルーティング判断を握る「Local-First」設計ゆえに、難問でクラウド最上位モデルへのエスカレーションを見誤る構造的限界（30点満点ベンチマークで26点）があった。そのため筆者の実運用では、上流の判断権をクラウド最上位の Gemini 4 Argon（Antigravity）に固定し、L4のCLIや決定論的Pythonハーネスを通じて他社モデルやローカル27Bへ仕事を振り分ける「Cloud-Firstの大番頭構成（30点満点）」を採用している（詳細は『Perplexity Computerを解剖して「改良版」を自作した話』で解説した）。

業界の製品例を見ても、Google Antigravityはエージェント統合開発・常駐管制環境として進化し、Perplexity Computerは複数モデルを統合制御する汎用デジタルワーカーとして打ち出され、Microsoft Copilot Studioはマルチモデルの取り込みを進め、Manusは計画・実行・検証を役割分担する方向に振っている。このL2層を見落とすと、ClaudeとCopilotを同じ表で比べたり、PerplexityとGeminiを同列に置いてしまう。階層が違うものを混ぜて見ているからだ。

プラットフォーム	本質	強み	想定ユーザー
Google Antigravity (agy)	エージェント統合開発・自律差配基盤（Gemini 4 Argon ＋ 3.8 Flash。Google AI Ultraで5倍枠）	常駐cron・サブエージェント並列差配・ローカルCLI（Claude / Codex / Grok）の統合指揮	AIオーケストレーション・開発・自動運用の中枢
Perplexity Computer	マルチモデル指揮者＋エージェント型Web（20以上のモデルを統合制御）	検索・リサーチ起点の自律ワークフロー	リサーチャー、調査・企画担当者
Microsoft Copilot / Copilot Studio	業務屋敷の執事長（マルチモデルセレクタ搭載）	Microsoft 365／Azureとの深い統合	企業のDX・業務自動化チーム
Manus	役割分担型マルチエージェント（Manus 1.6 Max）	プランナー／実行／検証の自動分業	個人〜中小の自動化ユーザー

L3 番頭層 — 主要LLMの性格（2026年11月時点）

「どれが一番頭がいいか」という問いは半分しか当たっていない。本当に問うべきなのは「どの仕事を、どのように差配させると強いか」だ。

モデル系統	差配・計画力	ツール連携	コンテキスト長	差配キャラクター（2026年11月初旬の実運用）
Google Gemini 4 Argon / 3.8 Flash	◎ 大番頭・番頭兼務の主軸	◎ Antigravity統合・MCP・CLI差配	1M〜2M	実戦ベンチ（30点満点）でArgonが30点満点首位、3.8 Flashが28点2位。Google AI Ultra（5倍枠）とローカル27Bへの委譲で週次枠を8割以上温存。日常のGemini / NotebookLMも全く枠が減らない
OpenAI GPT-6 Astra / 6.1 Sol / 6.1 Terra	◎ 独立監査・論理構成に強い	◎ Codex CLI・Function Calling成熟	500K〜1M	Codex CLIで運用。白紙からの独立監査に強いAstra（25点）と、長文クロス監査・第4走者フェイルオーバーに強い6.1 Sol（21点）／Terraを大番頭（Antigravity）の目利きのもとで使い分ける
Anthropic Claude Opus 5.5 / Sonnet 5.5	◎ 精密実装・長大タスクに強い	◎ Claude Code CLI・MCP・Skills主導	1M	Claude Code CLI専用で運用。Opus 5.5（25点）・Sonnet 5.5（22点）とも規約遵守とサイレント障害診断、深夜・早朝の定時実装に強い職人気質の番頭
SpaceXSI（旧xAI） Grok 4.7 / 4.6	○ リアルタイム探索・高速実装	○ Grok Build CLI・Function Calling	500K	Grok Build CLIで運用。更地からの突破力は高いが既存資産の保守を苦手とし、10月下旬にThe X Subscriptionを解約手続き済み（11月13日で固定サブスク終了・従量APIによる第3走者フェイルオーバーへ移行）
Meta Llama 4 Scout / Maverick	△〜○ モデル次第	○ 自由に組込み可能	10M（Scout）/ 1M（Maverick）	自邸に雇う内製執事。改造自由
MiniMax M2.5	○ フロンティア級推論	○ API成熟しつつある	196K（Lightning版は1M）	コスパ特化の若手執事

※ 各モデルの仕様・運用評価は2026年11月初旬時点に基づく。バージョン・コンテキスト長は随時更新される可能性があり、採用時は各社の最新ドキュメントで再確認することを推奨する。

番頭には向き不向きがある。また、同じ陣営の周辺ツールでも実戦での見極めは欠かせない。たとえばGoogle ColabのAI補助は検証した結果、要領を得ず実務では使いものにならなかったし、非同期コーディングエージェントのJulesも、普通に手元のCLIでLLMを回してCI/CDを流したほうが圧倒的に早いため使っていない。看板や宣伝文句ではなく、実際の工程に置いて使えるかどうかで番頭と道具を選ぶのが主人の仕事だ。

L4 手代・丁稚層 — 実行ハーネス（手綱）・オンデバイス27B・AIブラウザ

L3のモデルが「頭脳（人格）」だとすれば、L4はそれに道具と規律を与えて現場で動かす「手綱（ハーネス・肉体）」と「蔵番の丁稚（オンデバイス軽量モデル）」の層である。同じモデルでも、どんなハーネスで包むかによって現場での働きぶりは別物になる。筆者の環境では、このL4を三つの系統で構成している。

第一は、大番頭（Antigravity）からコマンドラインで呼び出されてファイル編集やスクリプト実行、検証を担うローカルCLIハーネス群（Claude Code CLI、Codex CLI、Grok Build CLI）やMCPサーバー群だ。ブラウザのチャット画面を開いて人間がコピペする手作業は完全に消え、L2の大番頭がL4のCLIを通じてL3の番頭たちを直接動かす形に収斂している。

第二は、2026年11月に導入した「決定論的Pythonハーネス＋オンデバイスローカルLLM（Qwen 3.8 27B）」による丁稚（下働き）機構である。長大なログの一次圧縮（Prep）、定型HTMLやスクリプトの下書き生成（Draft+Verify）、異常有無の一次門番（Triage）までを、クラウドのクォータを1ミリも消費しない手元のMac内27Bモデルと決定論的コードで処理し、高度な判断が必要な案件だけをL2/L3のクラウドモデルへ引き渡す（詳細は『Perplexity Computerを解剖して「改良版」を自作した話』を参照）。

第三は、CometやAtlasのようなAIブラウザである。Webページを開き、読み、フォームに入力し、ボタンを押し、タブを横断してブラウザという現場で手作業を代行する。Cometは Search と Work が分かれ、Work は Computer と同一のクレジット課金である（詳細はPerplexity Deep Research の独白に書いた）。Atlasは独自ランタイムで安全制御を内蔵し、「手代＋番頭見習い」の位置づけが近い。同時に、Webの内容そのものがAIへの命令として作用しうる間接プロンプトインジェクションのリスクも生まれている。

L5 従業員層 — API／DB／SaaS基盤

L5は最下層の基盤である。社内API、データベース、SaaSサービス、EDI、ブロックチェーン、HTTP——Web2.0以降に積み上げられてきた土管群が、ここに収まる。L5自体はAIではない。しかし、L4の手代が呼び出す先も、L3の番頭が参照するデータも、元を辿ればすべてL5にある。ここが整理されていなければ、上位層をいくら磨いても商売は回らない。AI活用の成否は、見えない最下層の整備に規定される。

権限委譲と責任分界

この図式の良いところは、権限委譲と責任分界が自然に理解できることだ。主人が全部やる必要はないが、主人にしか決められないこともある。大番頭は全体を差配するが、番頭の専門性を超えることはできない。手代は現場で手を動かすが、与えられた範囲に限られる。従業員層は最も下にあるが、そこが整っていないと商売は回らない。筆者の肌感では、個人や小規模チームなら主人が直接L3を差配しても回る。だが長期自律実行、並列タスク、大量比較、複数ツール連携が入ってくると、大番頭なしでは回らなくなる。

ただし現実のLLMオーケストレーションでは、この「上から下」の指揮系統だけでは片付かない。L4の手代（Comet）はページ処理の判断にL3の番頭を内部で呼び出すし、L3同士（Claude→GPT）が相談することもある。L3がL4のMCPサーバーを叩き、その結果を受けてL3がまた考える。層と層の呼び出しは、しばしば双方向だ。

ここで混同してはいけない。呼び出し関係と指揮系統は別物である。手代が番頭を呼んでいるように見えても、その出力に対する責任は、手代を呼び出した主人に帰属する。層をまたぐ呼び出しは「誰が誰を使ったか」という技術的事実にすぎず、「誰が結果に責任を取るか」という設計は常にL1起点の一方通行だ。これはTesla FSD Supervisedと同じ構図である——ハンドルを握っているのはFSDだが、運転席で監督し、事故の責任を負うのはドライバーだ。「Supervised」という名前自体が、責任の所在を明言している。

そして、この区別が崩れると「権限委譲」は容易に「丸投げ」に変わる。L1が目的と評価基準（Define）を明確にしている限り、下位層に任せるのは委譲である。逆に、Defineを曖昧にしたまま「AIに任せた」と言えば、それは丸投げに過ぎない。責任は常にL1に残る——呼び出しが何重に交差しようと、その原則だけは動かない。

それでも、仕事が主語である

手段と目的の倒錯

ここで一度、強くブレーキを踏んでおきたい。L2もL3もL4もL5も、全部手段である。目的ではない。Perplexityを入れたから何なのか。Claudeを使ったから何なのか。Cometでブラウザを自動化したから何なのか。大番頭や番頭や手代をいくら揃えても、主人が「何をしたいのか」を定義していなければ、大店は空回りする。AIが増えると選択肢が増え、選ぶこと自体が仕事のように見えてくる。だが、本来の仕事はそこではない。言い換えれば、AI時代に重要なのは「どのAIを使うか」ではなく、「何を成功させたいのか」である。

AIの到達点はアウトプットまで

目的が「売上を上げる」だとする。AIが出せるのは、市場分析レポートかもしれない。広告文案かもしれない。提案書の初稿かもしれない。そこまでは到達できても、実際に顧客に会い、交渉し、信頼を積み上げ、契約し、入金を確認するところまでは、人間の仕事が残る。AIの実現可能範囲は、多くの場合「アウトプットまで」だ。

だから主人の仕事は三つになる。目的を明確にすること。AIがどこまで到達できるか終点を見極めること。そして、その終点から現実の成果までを人間がどうつなぐかを設計すること。この三つが揃って初めて、AIは仕事を補完する装置になる。

主役ではなく述語として

AIは主役でなくていい。現実の仕事を成功させることが目的であるなら、AIはその仕事を補完し、支援し、加速し、部分的に代行すれば十分だ。むしろ、AIを主役に据えると危うい。導入したこと自体が目的化し、利用率や機能数が評価指標になり、本来の仕事の成果から目が離れる。これはDXでも何度も見た失敗であり、AIでも同じことが起きる。仕事が主役で、AIは述語である。

AIBizOpsを提唱する — 仕事主語のAI活用フレーム

なぜBizOpsだけでは足りないか

こういう構造を考えている人は当然すでにいる。BizOpsは経営・現場・ITをつなぎ、データに基づいてビジネスオペレーションを回すための考え方として、ここ数年で日本でもかなり見かけるようになった。ただし、既存のBizOpsはLLMオーケストレーションの階層構造や、その階層ごとに何を配備するかという視点を明示的に含んでいない。BizDevOps、MLOps、AIOpsなど近接する概念もあるが、どれも重要な視点を与えるものの、「仕事を主語に、AI補完をライフサイクルとして設計する」という全体像を一語でまとめるには、あと一歩足りない。

AIBizOpsの定義

AIBizOps（エーアイ・ビズオプス）とは、LLMオーケストレーション時代のAI活用設計思想である。BizOpsを土台に、LLMオーケストレーションの階層構造と、Define→Map→Assign→Operate→Measureの5段階サイクルを組み合わせ、AIを主役にせず、現実の仕事を主語に据えてAIを配備することを目的とする。

筆者はこの考え方をAIBizOps（エーアイ・ビズオプス）と名付け、ここに提唱する。既存のBizOpsを土台にしつつ、LLMオーケストレーションの階層構造と、現実の仕事への接続を設計思想として組み込んだものである。なお本記事では、この階層を「大店モデル」という整理軸で説明する。

なお「AIBizOps」という語は、DevOpsやCI/CDパイプライン、あるいはAIOps（Gartnerが2016年に提唱したIT運用へのAI適用）といった文脈で、技術実装論として散発的に言及されることがある。本稿で提唱するAIBizOpsは、それらと問題意識を一部共有しつつも、対象をIT運用ではなくビジネス全体に置き、LLMオーケストレーションの階層設計と、仕事を主語にしたAI補完のライフサイクルとして定義し直すものである。AIOpsが「IT運用の内部最適化」を扱うのに対し、AIBizOpsは「仕事の成果を最大化するための配備設計」を扱う。技術実装論ではなく、経営・設計思想としての位置づけを明確にしておきたい。公開面の運用では、同じ構造をAIDevOps（AI-driven DevOps／Agentic DevOps）と呼んでいる。AIエージェントが計画・割り振り・実行・検証・修正・配信を回し、人間は規則（スキルと正本）を書く側に回る。MLOpsでもLLMOpsでもない。モデルの学習運用ではなく、仕事の配信パイプラインである。AIBizOpsが設計思想、AIDevOpsがその運用での具現化である。具現化の記録は生成AI交際録／集合ハブに置いた。

また「AIBizOps」という同じ綴りでBiz AI Ops（bizaiops.ai）というAI実装コンサルティング事業が先行して存在する。ただし同事業はサービス名・業態名としての使用であり、本稿のような階層モデルや運用ライフサイクルを伴うフレームワーク論として理論的に提唱しているものではない。本稿は先行する同名事業への敬意を払いつつ、独自の設計思想として再定義するものである。

AIBizOpsの5段階 — Define→Map→Assign→Operate→Measure

この考え方を無理なく使うために、ライフサイクルもシンプルに定義しておきたい。5段階で十分だと思う。

1. Define — 何を成功させたいか

まず、何を成功させたいのかを定義する。売上なのか、調査レポートや成果物の品質なのか、意思決定の速度なのか、調査の抜け漏れ削減なのか。目的、制約、成功基準、評価指標を言葉にする。ここを曖昧にしたまま次へ進んでも、あとで全部がぼやける。

2. Map — 工程の棚卸しとAIの入る場所

現実の仕事を工程に分解し、AIが入れる場所と入れない場所を棚卸しする。必要なデータは何か。APIはあるか。どこまでがAIの実現可能範囲で、どこから先は人間の承認や信頼形成が必要か。L5を俯瞰する段階である。

3. Assign — 階層ごとの配役決定

どの階層に何を置くかを決める。L2を置くか。L3は何人雇うか。L4にどんな手代を持たせるか。逆に、AIを置かない工程はどこか。ここで初めて、モデル比較やツール比較が意味を持つ。

4. Operate — 実際に回す運用設計

実際に回す。AIに任せる工程、人間が受け取ってつなぐ工程、確認を挟む工程、例外時に止める工程。この運用設計がないと、理屈がきれいでも現実では回らない。

5. Measure — 本業のKPIで測る

最後に測る。ここで測るべき最終指標（Lagging KPI）は、AIの利用回数ではない。本業のKPIである。調査や制作の所要時間が何時間減ったか、公開後のファクト誤りやリンク切れがゼロに保たれているか、月次のサブスクリプション固定費が適正化されているか——ビジネスの成果に戻して評価する。

そのうえで、日々の運用が本業KPIを毀損していないかを監視するために、現場の先行指標（Leading / Operational Metrics）を組み合わせる。筆者の姉妹連載（生成AI交際録およびAI大奥外伝）で用いている用語との対応を整理すると、以下の通りすべてこの5段階サイクルに収まる。

• Define（目的・掟の策定）：人間（L1・上様）が正本スキルや品質規約（12項目チェック・HTTP 200導通義務など）を定義する。
• Map ＆ Assign（適材適所の配役選抜）：実務課題を模した『大運動会ベンチマーク（30点満点）』によって各モデルとハーネスの実力を測定し、大番頭（Antigravity）・番頭（Claude／Codex）・丁稚（ローカル27B）の席を決める。
• Operate（自律運行と七つの門）：『外伝4・七つの門』で定めた自律運行基準（障害時の迂回、サイレント障害の検知、外部実物とのRead-back照合）と決定論的ハーネスで日々のパイプラインを回す。
• Measure（本業成果と兵站の監査）：本業の成果物品質・リードタイム短縮・サブスク費用対効果を主指標とし、それを支える運用ヘルス指標としてクォータ余力（蔵の米・基礎代謝削減率）を計測して次のAssign見直し（契約の昇格や解約）へ還流させる。

具体例：1つの業務タスクが L1〜L5 をどう往復するか（ミニトレース）

抽象的な5段階ループとL1〜L5の階層が実務でどう噛み合うのか、日常業務の1つである「技術記事の公開前ファクト監査＆自動パブリッシュ（3層ハイブリッドRAG）」を例にデータフローをトレースしてみよう。

• L1（主人／人間）：「全リンクHTTP 200導通・一次ソースの条文や数値との不一致ゼロ」という絶対基準（Red Line）を定義し、最終公開の責任を持つ。
• L2（大番頭／Antigravity Gemini 4 Argon）：監査パイプライン全体を起動・統括し、最終レポートを検分してGo/No-Goを判断する。
• L4（丁稚・手代／ローカル Qwen 3.8 27B ＆ Python決定論的ハーネス）：オンデバイス27Bがクラウド消費0%で原稿から全検証項目（Claim Matrix）を漏れなく抽出し（ハイブリッドハーネス設計）、Pythonスクリプト（Playwright / PyMuPDF）が決定論的にL5へ証拠を取りに行く。
• L5（従業員・土台／外部API・ファイル・DB）：官公庁の一次ソースPDF、検索API（Sonar / Brave）、ローカルGitリポジトリ、WordPress REST APIがデータと通信を支える。
• L3（番頭／Argon ＆ GPT-6.1 Sol）：L5から回収された一次ソース証拠とL4のClaim一覧を100万トークンの長大コンテキストで突き合わせてクロス監査し、修正パッチをL2大番頭へ返す。

この5段階は一周して終わりではない。Defineに戻る。目的が変われば設計も変わるし、技術が変わればAssignも変わる。AIBizOpsとは、結局この反復のことだ。

混沌を地図に変える

筆者自身、この整理に辿り着くまでだいぶ遠回りをした。ここまで長く書いてきたが、言いたいことはそこまで複雑ではない。

LLMの発達によって、世界は一気に便利になった。と同時に、一気にわかりにくくなった。モデルがある。モデルを束ねる層がある。現場で実行する層がある。その下に、APIやDBやWeb3の基盤がある。それらを組み合わせれば、かなり多くのことができるようになった。

だが、それらは全部手段だ。目的は相変わらず、人間の側にある。仕事を成功させたい。より良い成果物を出したい。よりよい判断をしたい。その目的に対して、AIがどこまで届くかを見極め、その終点から先をどうつなぐかを設計し、そのために必要な大番頭、番頭、手代、従業員を配置する。そう考えた瞬間、モヤモヤしていたものは、少し地図になる。

Web4.0とは、AIが全部を支配する世界ではない。主人が目的を握り、大番頭が差配し、番頭が考え、手代が動き、従業員が支える世界である。そして、その商いをどう設計するかは、まだ人間の仕事だ。少なくとも今は、そう思っている。

FAQ

あわせて読みたい

• 生成AI交際録／集合ハブ（本記事のL2「大番頭」とL3「番頭層」を、筆者の実運用と11のAIとの交際記録から描いた姉妹記事）
• AI大奥外伝5・着任篇（本記事の大店モデルを「AI大奥」として実装し、Antigravityが正室兼大奥総取締役に着任するまでの実戦記録）
• AI大奥外伝6・第2回大運動会篇（Assignの根拠となる実戦5種目・30点満点ベンチマークの検証記録）
• Perplexity Computerを解剖して「改良版」を自作した話 —— ローカル27Bの限界（26点）を突破するCloud-First決定論的ハーネス（AIBizOpsシリーズ第2弾：L2大番頭［Cloud-First Argon］とL4丁稚［ローカル27B］を結ぶ決定論的ハーネスの設計と実装）
• Perplexityの検索RAG環境をローカルで完全再現した話 —— オープンソース27B×最小限Web APIで商用検索AIと同等精度を叩き出す自作アーキテクチャ（AIBizOpsシリーズ第3弾：ローカル27BによるClaim全件抽出と150ソース並列検証を組み合わせた3層ハイブリッドRAGエンジンの実装）
• LLMへのジョブディスクリプション（JD）割り当てとAIオーケストレーションの適材適所フレームワーク —— 4層システムレイヤ×6職種によるベンチマークの再編と標準化（AIBizOpsシリーズ第4弾：システム4層×業務6職種の2軸マトリクスによる全17構成の評価と「3アウト・1イン」新陳代謝の全記録）
• テスラ車載Grok（本記事のL1「主人＝責任主体」の視点を、日本市場の制度論から掘り下げた考察）
• テスラFSD日本解禁（Tesla FSD Supervised類比の背景）

---

参考リンク

Google Antigravity

• Antigravity Docs | IDE Overview

Biz AI Ops（先行する同名事業）

• Biz AI Ops | AI Implementation & Transformation Consulting

Gartner（AIOps）

• AIOps (Artificial Intelligence for IT Operations) | Gartner Glossary