10 KiB
sidebar_position, title, description, displayed_sidebar, image
| sidebar_position | title | description | displayed_sidebar | image |
|---|---|---|---|---|
| 2 | いま混線しがちなAI用語をほどく:モデル/実行基盤/UIの関係 | モデル、実行基盤、UI/ブリッジの3層でAIツールの関係を整理する(2026年3月検証版) | null | /img/ai-terms-model-vs-agent-platform-banner.png |
いま混線しがちなAI用語をほどく:モデル/実行基盤/UIの関係
はじめに
「AntigravityとClaude、どっちが賢いの?」——この手の会話が噛み合わないのは、層の違うものを比較していることが多いからです。
Antigravityは「IDEに統合されたコーディング体験」、Claudeは「推論を行うモデル」。そもそも比較軸が違います。
この記事では、いま混線しやすい用語を次の3層に分けて整理します。
| 層 | 一言で | 例 |
|---|---|---|
| モデル層 | 推論・生成を行う頭脳 | Claude / GPT / Gemini |
| 実行基盤層(Runtime / Harness) | モデルにツール呼び出し・計画・実行・検証の「手足」を与える | Claude Code / Codex CLI / Antigravity Core |
| UI/ブリッジ層 | 人間や外部チャネルとの接点 | IDE, Web UI, Discord Bot, CDPブリッジ |
注意: 実際のプロダクトは1層にきれいに収まらず、2層以上をまたぐことがあります(例: Antigravity = 実行基盤 + UI、ChatGPT = UI + モデル)。本記事ではあえて「主層」と「副層」に分けて整理します。
3層モデル図
graph LR
subgraph UI["UI / ブリッジ層"]
direction TB
CLI["CLI"] ~~~ IDE["IDE(Antigravity等)"]
IDE ~~~ Web["Web / App UI"]
Web ~~~ Bot["Discord Bot"]
Bot ~~~ CDP["CDPブリッジ"]
end
subgraph Runtime["実行基盤層(Runtime / Harness)"]
direction TB
CC["Claude Code"] ~~~ CodexCLI["Codex CLI"]
CodexCLI ~~~ AGCore["Antigravity Core"]
AGCore ~~~ OC["OpenClaw Gateway"]
end
subgraph Model["モデル層"]
direction TB
Claude["Claude"] ~~~ GPT["GPT"]
GPT ~~~ Gemini["Gemini"]
end
UI --> Runtime
Runtime --> Model
主要ツールを層で分類する
| ツール | 主層 | 副層 | バックエンドモデル | コメント |
|---|---|---|---|---|
| Antigravity | 実行基盤 + UI | — | 構成・時期により異なる(公式Docs参照) | IDE体験が強く「モデル=ブランド」と混同されやすい |
| Claude Code | 実行基盤 | UI(CLI) | Claude(Anthropic公式) | MCP / Skills / Subagents で拡張 |
| Codex CLI | 実行基盤 | UI(CLI) | GPT系(OpenAI公式) | OpenAI側のCLIエージェント |
| Cursor | 実行基盤 + UI | — | マルチモデル(公式Docs参照) | IDE一体型で層が混線しやすい |
| ChatGPT | UI + モデル | 一部実行機能 | GPT系 | 「モデル名=体験名」になりやすい |
| Gemini(チャット) | UI + モデル | 一部実行機能 | Gemini系 | 同上 |
| OpenClaw | オーケストレーション基盤 | UIブリッジ連携 | 接続先の基盤に依存 | 複数エージェント・チャネルを束ねる運用レイヤー |
ポイント: 「どちらが賢いか」を議論するなら、まずどの層で比較しているかを固定する。モデル性能の話なのか、ツール連携の話なのか、IDE体験の話なのかで答えが変わります。
MCP と Skill——実行基盤層を拡張する2つの軸
3層モデルの中でも、実行基盤層の拡張方法としてよく名前が出る2つを整理します。
| MCP(Model Context Protocol) | Skill | |
|---|---|---|
| 何を解決するか | ツール・データソースへの接続の標準化 | 運用ノウハウ・手順の再現性と遅延ロード |
| 粒度 | 1つの外部サービスとの接続定義 | 1つのタスク遂行に必要な手順・プロンプトの塊 |
| 実行基盤との関係 | 基盤がMCPサーバーを呼び出す | 基盤がSkill定義を読み込んで実行する |
| 具体例 | Gitea API接続、SearXNG検索 | コードレビューループ、記事生成手順 |
実務では MCP(接続)+ Skill(再現性) を併用するのが強い構成です。MCPで外部ツールに繋ぎ、Skillでその使い方を定型化する、という役割分担になります。
Antigravityまわりで混線しやすい点
Q1. Antigravityはモデルか?
いいえ。実行基盤 + UI です。モデルそのものではありません。
Q2. なぜモデル扱いされるのか?
- ユーザーは「Antigravityを開いて使う」という体験単位で認知する
- バックエンドモデルを意識する場面が少ない
- ブランド名が体験全体を代表してしまう
これはChatGPTでも同じ現象が起きています。「ChatGPTが賢くなった」は多くの場合「バックエンドがGPT-4oに切り替わった」という意味です。
Q3. AntigravityのDiscord連携はどの層の話か?
多くの場合 UI/ブリッジ層 の話です。非公式CDPブリッジでAntigravityのWeb UIを外部から操作する構成は、モデル性能とは無関係のブリッジ実装の議論になります。
用語の言い換え——議論を噛み合わせるために
| 混線しやすい言い方 | 層を揃えた言い方 |
|---|---|
| 「AntigravityとClaude Codeどっちが賢い?」 | 「Antigravity基盤とClaude Code基盤、運用面でどっちが自分の用途に合う?」 |
| 「Antigravityのモデルは?」 | 「いまAntigravityが使っているバックエンドモデルはどれ?」 |
| 「CursorとAntigravityどっちが強い?」 | 「IDE体験(UI層)と実行基盤の観点でそれぞれ何が違う?」 |
実務的な使い分け——この文脈での判断基準
公式APIベース(本番運用向き)
- 構成例: Claude Code + MCP + Skills、Codex CLI + Gitea連携
- 利点: 可観測性が高い、契約・利用規約が明確、レート制限やエラーハンドリングが公式サポート
- 適用場面: 本番サービス、継続的に動かす自動化
オーケストレーション基盤(複数エージェント統合)
- 構成例: OpenClaw Gateway + 複数エージェント + Discord/Webhook連携
- 利点: 異なる基盤のエージェントを1箇所で管理、チャネル横断の通知・応答が可能
- 注意点: オーケストレーター自体の可用性が単一障害点になりうる。Gateway障害時のフォールバック設計が必要
UI/CDPブリッジ(検証・PoC向き)
- 構成例: CDP経由でAntigravity Web UIを操作、Discord DOM監視
- 利点: 公式APIが存在しないサービスにもアクセス可能
- 制約: 後述のリスクを理解した上で、隔離環境・最小権限で運用すべき
CDPブリッジ運用のリスク整理
非公式CDPブリッジ(antigravity-discord-botのようなUI自動化ツール)は技術的には動作しますが、3つの異なるリスクを分けて評価する必要があります。
1. 技術リスク:リモート操作の攻撃面
CDPポートが開いている=ブラウザの全操作権限が外部に露出しています。
- CDP接続元を
127.0.0.1に限定し、SSHトンネル経由でアクセスする - VM上で隔離されたブラウザプロファイルを使う
- 本番の認証情報が入ったブラウザセッションでCDP操作しない
2. 運用リスク:自動承認による破壊的操作
CDPブリッジ経由の操作を「自動承認」にすると、意図しない破壊的操作が実行されうる。
- ファイル削除、設定変更、外部送信など不可逆な操作は人間承認を挟む
- 操作ログを残し、事後検証できるようにする
3. 規約リスク:UI自動化の利用規約上の扱い
「ただのリモコンだから安全」ではありません。判断軸は——
提供側がその操作を「自動代行」と見なすかどうか
- 多くのサービスはUI自動化(スクレイピング・ボット操作)を利用規約で制限している
- 公式APIが提供されている場合、そちらを使うほうが規約上安全
- 公式APIがない場合でも、利用規約を確認した上で判断する
参考情報
以下は執筆時点で参照した情報源です。URL・内容は変更される可能性があるため、利用時に最新版を確認してください。
- Antigravity公式ドキュメント(Google)
- Claude Code公式ドキュメント(Anthropic)
- Cursor公式ドキュメント(Models and Pricing)
- 非公式CDPブリッジの実装例(GitHub上に複数存在)
この記事は2026年3月時点の情報です。モデル提供範囲・料金・規約は短期間で変わるため、導入前に必ず各サービスの公式ドキュメントと利用規約を確認してください。
CDPブリッジの接続関係(Mermaid)
以下は、今回の会話で出てきた「Antigravity + Discord Bot + CDPブリッジ」の接続関係です。
flowchart LR
U[ユーザー\nDiscord] --> B[Discord Bot UI]
B --> C[Anticlaw / LazyGravity\nCDPクライアント/ブリッジ]
C -->|WebSocket JSON CDP| E[CDP Endpoint\nlocalhost:PORT]
E --> A[Antigravity\nElectron/Chromium runtime]
A --> R[Agent Runtime\n計画/実行/検証]
R --> M[Model Backend\n例: Opus/Gemini/GPT]
classDef ui fill:#4a9eff,stroke:#2d7cd4,color:#fff;
classDef bridge fill:#9b59b6,stroke:#8e44ad,color:#fff;
classDef app fill:#ff8c42,stroke:#d4712d,color:#fff;
classDef model fill:#51cf66,stroke:#3da54e,color:#fff;
class U,B ui;
class C bridge;
class E,A,R app;
class M model;
伝え方テンプレ(誤解が少ない言い回し)
- 「Antigravityの
remote-debugging-portを有効化し、指定ポートのCDPエンドポイントにブリッジを接続する」 - 「Discord BotはUI、Anticlaw/LazyGravityはCDPブリッジ、Antigravityは基盤+IDE」