Antigravity

編集

概要

  • やっとまともに使えるIDEが生まれた。。
  • AIの時代がきてまたCLIが最強になってしまった。ブラウザ <<<<<<<<<<<(越えられない壁)<<<<<<<<<< コマンドライン
  • サービスを作って載せ替えていくスタイルになるだろう。コード自体の価値は暴落し、データだけが積み上げていく資産となる。
  • メモリを死ぬほど使う。イメージ単体で 32 GB とか使うこともあるので、64 GB メモリを積んだほうがいいかもしれない。別のパソコンを用意してそっちで動かすのもいいかも。
  • Settings / Agent / Enable Shell Integration は Off にしたほうがいい (2026-03-08)。0.1 秒で終わるような簡単なコマンドが頻繁にハングする。

目次

便利機能

  • Agent Manager > Workspace > Agents で、複数同時にエージェントを走らせられる。
  • Playgroundは本番コードに影響しない実験的なコードを人間が試す場所。/home/hamko/.gemini/antigravity/playground/hidden-pinwheel
  • BrowerはAntigravity用ブラウザ
  • Rules, Workflow (.agents/rules/*.md, .agents/workflows/*.md)
    • 追加後 Editor を再起動しないと読み込んでくれない。
    • ファイル名に小文字・ハイフン限定（_不可）
    • Agent Manager からのワークフロー呼び出しはできない。Editor > Agent のほうでしか予測が動作しない。

Antigravity 自体のデバッグ

-Ctrl-Shift-P (パレット) > Developer: Open log > Antigravity

ショートカット

  • Ctrl-E (エディタ以外で) Agent Manager を開く
  • Ctrl-Shift-`: ターミナルを開く
  • Ctrl-P 曖昧ファイル名検索
  • Ctrl-Shift-V: Markdown プレビュー
  • Ctrl-Shift-O: ファイルが所属するディレクトリを開く（注意: カスタム。Ctrl-Shift-R が普通だが、Antigravity では Run に予約されているので、Ctrl-Shift-P > Open Containing Folder のショートカットを上書きする）

知識

  • Model Context Protocol (MCP)

    • https://modelcontextprotocol.io/docs/getting-started/intro
    • 外部システムと接続するための共通プロトコル。Spanner, Slack, 独自で作ったLLM, Blender (!?), Figma などの操作が可能
      • AntigravityがFigmaのデザインデータを読み取り、デザインを実装することができます。
    • Gemini CLIでもMCPは使える。

  • Open VSX:

  • MCP Toolbox for Databases:

  • Kilo はスペック駆動開発を押している

    • Let's build みたいなテンプレで、Vibe と Spec をまず選べる

  • GWSアドオン: Google AI Ultra for Business を購入すると GWS 連携で Quota を緩められる。

    • 他のすべての Workspace アドオンと同様に、IT 部門が一括で購入、管理できるため、管理された状態を常に維持することができます。

  • search_web というツールを予め持っているので、いえば検索もしてくれるけど、多分 AI モードで検索しているからハルシネーションだらけで使い物にならない（言わないとしてくれない傾向がある。。）

Gemini CLI (Antigravity エージェント) 内部実装と仕組み

実体は Node.js ベースの CLI アプリケーション (@google/gemini-cli および @google/gemini-cli-core) であり、ファイルの探索から各定義をプロンプトへ組み込む設計になっている。

1. Skill の実装と判断ロジック

アーキテクチャの概要

内部の SkillManager クラスが担当している。 起動時に複数のディレクトリから SKILL.md を走査してメモリ上に保持する。 優先順位は低い順から以下のようになっており、同名スキルの場合は後勝ちでオーバーライドされる。

  1. Built-in（CLI組み込み） CLI ツール本体に最初からプリインストールされている基本的なシステムスキル群。ユーザーが何も定義しなくてもデフォルトで機能する。
  2. Extensions パッケージなどサードパーティの拡張機能（プラグイン）として追加インストールされたスキル群。
  3. User skills ユーザーのホームディレクトリ (~/.gemini/antigravity/skills など) に配置されるスキル。どのリポジトリ（プロジェクト）を開いて作業している時でも、環境全体で共通して適用されるユーザーごとの個人スキル。
  4. User agent skills ~/.gemini/antigravity/.agents/skills などの特定の「エージェント（動作コンテキスト）」専用に隔離・設定されるスキル。User skills と似ているが、特定のエージェントや目的に対してのみ呼び出せるようスコープが絞られたエイリアスとして機能する。
  5. Workspace skills 現在のプロジェクトルート (.gemini/skills) に配置されるスキル。そのプロジェクトを開いている時だけ適用され、他のすべての設定より最も優先度が高いプロジェクト専用のスキル。

誰が・いつ・どうやって適切なスキルを判断するのか？

※前提: PromptProvider はいつ、何のために何をするクラスか？ PromptProvider は、LLM と通信する直前に「あなたが守るべきルールは何で、使えるツールは何か」を説明する巨大なテキスト指令書（システムプロンプト）を組み立てるオーケストレーターの役割を持つ。ルールやスキルなど、各所から情報をかき集めて一つのテキストブロックにまとめるために存在する。

この PromptProvider クラスがシステムプロンプトを構築する際、有効なスキル一覧を <available_skills> と </available_skills> のようなタグの中に、名前と概要だけ列挙して埋め込む。 （※ここでの「タグ」とは、LLM に対して『ここからここまでがスキルのリストに関する説明ですよ』と明確に範囲を区切って教えるための <記号>〜</記号> のことを指す）

  1. 判断の仕組み: 各スキルに対して True/False などのフラグによるハードコードされた構造化分岐（if文のような処理）がシステムのバックグラウンドで行われているわけではない。判断ロジックの本体は、LLM の Function Calling (Tool Calling) という仕組み そのものである。

    【補足】Function Calling (Tool Calling) の原理とI/Oプロトコル LLM自体が直接プログラムを実行するわけではなく、以下の Client (Gemini CLI) と API/LLM モデルの往復サイクルによって実現される。

    • Phase 1: Request (Tools Injection) Client はユーザーの入力テキストとともに、使用可能なツールのリスト（関数名、引数スキーマ等）をペイロードに含めて API へ送信する。
    • Phase 2: LLM Inference & Call Generation LLM が推論を開始する。ツール呼び出しが必要と判定した場合、LLM はテキスト生成をバイパスし、代わりに関数名と抽出した引数を含む functionCall オブジェクト (JSON) をレスポンスとして Client へ返却する。 ※ activate_skill の引数は原則として対象の skill_name の指定のみ。引数で「スキル内のここの部分だけ」といった別の細かい分岐を指定することはない。なぜなら、スキルの実体はあくまで「自然言語のMarkdownテキスト」であり、これをプログラムとして部分実行するのではなく、テキストファイル全体を LLM のプロンプトとしてインジェクト（ロード）させることがこのツールの目的だからである。
    • Phase 3: Local Execution 受信した Client は JSON をパースし、自身のローカル環境で実際のネイティブ関数・シェルコマンド等を実行（ここではスキルファイルの読み出し）する。
    • Phase 4: Feedback Request (Tool Response) Client はローカルの実行結果（読み出したスキルのテキストデータ）を functionResponse オブジェクトとしてラップし、再度 API へ送信する。
    • Phase 5: Final Response Generation LLM は取得したスキルの知識をコンテキストに統合して推論を再開し、最終的な回答テキストを生成して返却する。

    以下のシーケンス図は、この I/O プロトコルの往復で具体的に「どんなデータが送られ、何が返ってきているか」を示したものである。

    Loading diagram...

  2. タイミングと判断方法: LLM は通信時に受け取った <available_skills> の概要リストと、ユーザーからの自然言語リクエストを照らし合わせる。 そしてテキスト推論の過程で Function Calling を発動させ、「解決にはこのスキルが必要だ」と判断したとき、テキスト生成の代わりに activate_skill （または Workflow の場合は view_file）というツールを呼び出すための構造化データをシステムに返却する。

  3. 呼び出し後の挙動: ツール呼び出しリクエストを受けた Node.js 側のシステムが、指定されたスキルの詳細（手順やルール）を実際のファイルから読み出し、次のターンのプロンプトとして LLM に（ツールの実行結果として）返却する。これにより、LLM は専門知識を獲得して動作を最適化する。

    【補足】Parallel Function Calling (並列ツール呼び出し) について Gemini API および Client (Gemini CLI) のアーキテクチャでは、1回のレスポンスで必ずしも1つのツールしか返ってこないわけではない。 LLM が「このタスクを解決するには、Skill A と Workflow B の読み込みが同時に必要だ」と推論した場合、ペイロード (parts 配列) 内に複数の functionCall オブジェクトを含めて返却することが可能である。 Client 側は受信した複数の関数呼び出しを非同期または順次実行し、すべての結果をそれぞれ functionResponse として1つの配列に一括してまとめ、次の Phase 4 のリクエストで LLM に送り返す仕組みを備えている。

    【ベストプラクティス】Skill と Workflow の「名前」と「概要（description）」の重要性 上記の原理から分かる通り、LLM は**「システムプロンプトに埋め込まれた名前と概要テキスト」だけを材料にして**、どのスキル/ワークフローを発動させるか（Function Callingをトリガーするか）を推論している。 したがって、YAML のフロントマターに不正確・曖昧な概要を書いたり、適切でない名前を付けたりすると、以下のような問題を引き起こす。

    • 必要なタイミングで対象の機能が全く発動しない（サイレントに無視される）。
    • 不要な場面で誤って呼び出され、ノイズやコンテキスト長肥大化の原因となる。
    • Parallel Calling によって関係のない複数のスキルが同時に無駄に実行される。

    対策: 開発者は、LLM が迷わず的確に推論できるよう、対象の Skill や Workflow の description に「どのようなユーザー入力のときに」「何を目的として」呼び出すべきものなのか、トリガー条件と責務を具体的に記述することが極めて重要である。

【補足】「ツール (Tool)」とは何か？ Skill と同義か？

両者は同義ではなく、以下のように機能や役割が異なる。

  • ツール (Tool / Function Calling):
    • 定義: LLM が外部システムと作用するために提供されているプログラムの関数群。
    • 特徴: 入力引数を受け取り、処理結果を出力として返す。
    • 具体例:
      • run_command: コマンドラインの実行
      • view_file: ファイルの読み込み
      • generate_image: 画像の生成
  • スキル (Skill):
    • 定義: LLM が参照・学習するための、専門的な知識・ルール・手順が記載されたテキスト（ドキュメント）。
    • 特徴: 単独で実行可能なプログラムではなく、プロンプトの一部として活用されるコンテキスト情報。
  • 両者の関係性:
    • LLM は、ツールの一つである activate_skill を実行することで、対象となるスキル（テキスト）をシステムから取得し、自身のプロンプトとしてロードする。

一般的なガイダンス: Skill と Workflow はどう使い分けるべきか？

どちらも「作業を効率化・指示するためのMarkdown定義」という点では似ているが、LLMの扱い方や用途が異なる。迷ったときは以下を基準に作成する。

【 Workflow にすべきケース 】

  • 目的: 定型的な「作業手順書」や「チェックリスト」を作りたい場合。
  • 特徴: 「1. xxxする、2. yyyする」と上から下にコマンドを実行していくような手続き的な作業に向いている。
  • メリット: スクリプト内に // turbo といったアノテーションを入れることで、コマンド実行時のユーザー承認をスキップし、フルオートで完遂させることができる点。

【 Skill にすべきケース 】

  • 目的: 特定分野における「専門家のルール」や「思考のリファレンス」を与えたい場合。
  • 特徴: コマンドの順番ではなく、「この技術スタックを使う際のベストプラクティスはこうだ」「エラーが出たときはこういう観点で考えろ」といった、行動方針や専門知識を定義するのに向いている。
  • メリット: activate_skill で呼び出されると、一時的にLLMの「人格・専門知識」がブーストされ、よりスマートな解決策を提示できるようになる点。

2. Rule (ユーザー定義ルール) の実装

アーキテクチャの概要

階層的なメモリ (Hierarchical Memory) の仕組みとして実装されている。 「プロジェクト固有ルール > グローバルルール」といった明確な優先順位に基づく競合解決がプロンプト上で保証される。

ルール注入のステップバイステップ

  1. テキストの読み込み: CLI 起動時、プログラムがユーザーのホームディレクトリやカレントディレクトリを探索し、~/.gemini/GEMINI.md やプロジェクト直下の制約ファイル群を、単なる文字列として読み込む。

  2. メモリ上への保持: 読み込んだ文字列を、「グローバル用」「拡張用」「プロジェクト用」の変数にそれぞれ格納・保持する。

  3. タグによるラッピング (snippets.ts の 307行目 renderUserMemory 関数): プロンプトへ渡す直前に、これらの文字列を XML のようなタグで囲む。

    • memory.global の内容は <global_context>
    • memory.project の内容は <project_context>

  4. 統合して注入: 上記をすべてひとまとめにして <loaded_context> という親タグで括り、システムプロンプトの末尾に埋め込む。

    【補足】システムプロンプトってどういう扱い？定期的に忘れられるのか？ ここで埋め込まれたルールが途中で忘れられないか（初期化時の1回だけなのか）という点だが、システムプロンプトはLLM と API 通信するたびに毎回必ずコンテキストの先頭に送信される。 そのため、会話履歴が長く続いて情報が圧縮されたとしても、システムプロンプトに注入されたルールやスキルのリストをシステムが忘れることはない。

  5. LLM の解釈: LLM はこの XML 階層構造を見て「競合した場合は <project_context> を優位とする」という指示に従いルールを解釈・順守する。

3. Workflow の実装

アーキテクチャの概要

ローカルに配置された Markdown ファイル群の読み取りおよび自動実行パーサーとして実装されている。 .agents/workflows/、.gemini/workflows/ などのディレクトリから .md ファイルをリストアップする。

YAML フロントマターからの description 抽出とは？

Markdown ファイルの最上部に、ハイフン3つ(---)で囲まれて記述されるメタデータのこと。 例えば .agents/workflows/deploy.md の先頭にある以下のような情報を指す。

---
description: アプリケーションを本番環境にデプロイする手順
---

CLI プログラムは Markdown の本文を読む前にこのブロックを YAML 解析し、「このファイルは何のためのワークフローか (description)」を抽出し、プロンプトの <workflows> リストに追加している。

Workflow 呼び出しと自動実行のステップバイステップ

① どうやってそのワークフローを呼び出そうと思うのか

  • 自律的判断による呼び出し: LLM のシステムプロンプトには抽出したワークフローのリストと「該当する作業なら view_file ツールでファイルを読み込め」という指示がある。LLM が Function Calling によって「必要だ」と判断すれば、勝手にファイルを読み込んで実行手順を得る。

    【重要】Skill と Workflow における Function Calling ツールの差異 両者の読み込みには、それぞれ異なるツール（関数）が使用される。

    • Skill の場合: activate_skill(skill_name: string) LLM はスキルの「名前」だけを指定する。システム側がその名前から裏側の実ファイルパスを解決し、内容を返却する専用のルーターツールを使用する。
    • Workflow の場合: view_file(path: string) LLM のプロンプトにはワークフローのリストと直接の「絶対パス」が提示されており、LLM 自身がパスを指定して中身（手順書）をロードする汎用のファイル閲覧ツールを使用する。

  • 明示的な指定による呼び出し: ユーザーが会話で /deploy 等のスラッシュコマンドを入力すると、システムから強制的に「このワークフローを読み込め」という指示が渡り、LLM は処理を開始する。

② 呼び出された後どうするのか (処理フローと自動実行バイパス)

  1. 手順の読み取り: LLM は view_file によって読み込んだ Markdown に書かれた「1. ディレクトリを作成する」「2. デプロイを実行する」などの手順に従う。
  2. ツール実行前のチェック: LLM が各手順を実行するために run_command (コマンドライン実行) ツールを呼ぼうとした際、CLI システム側がその対象スコープを解析する。
  3. 自動実行 (turbo) の検知とバイパス: スクリプト内に // turbo (そのステップだけ) や // turbo-all (ファイル全体) といった開発者向けの特殊アノテーションが入っていると、システムはユーザーへ表示する「このコマンドを実行してよいですか？」のインタラクティブな承認画面・入力待機をスキップする。
  4. 即時実行: システムが内部的に SafeToAutoRun のフラグを強制的に true にマッピングし、バックグラウンド/シェル上で即座にコマンドが走り出す。これにより、定型ワークフローの手順をノンストップで自動完遂できる。

4. MCP (Model Context Protocol) との統合アーキテクチャ

MCP とは何か？

Model Context Protocol (MCP) は、Anthropic 社が策定した、AIクライアント（Gemini CLI や IDE 等）と外部データソース（データベースやSaaSのWeb API等）を統合するためのオープン標準プロトコルである。 AIモデルと外部ツールの統合において発生する実装コスト（各種APIの個別対応によるN×M問題）を解消するため、通信のインターフェース仕様を抽象化・標準化している。クライアント側はプロトコルの実装を持つだけで、対象となる複数のMCPサーバーから Tool, Resource, Prompt などの機能を動的に取得・実行できる。

MCPサーバーが提供する機能（Primitive）の種類

「1つの MCP サーバー ＝ 1つのツール」ではない。 1台の MCP サーバーは、複数の機能を提供する「APIパッケージ」あるいは「プラグイン」のような役割を持つ。サーバーは、主に以下の3つの機能（Primitive）をクライアントに公開できる。※これら全てを実装する必要はなく、用途に応じて提供内容は自由である。

  1. Tools: LLM が推論の中で自律的に引数を決定して実行できる「関数（Function）」である（例: github_get_pr(id: 123)）。Gemini CLI 上では Function Calling のツール群の一部として透過的に提供される。
  2. Resources: システムに存在する読み取り専用のデータソース（例: ログファイル、データベースのスキーマ情報）。URI (file:///... や postgres://...) によって特定され、LLM は Tool のように副作用を起こすのではなく、参照すべき静的なコンテキストとしてこれを読み込む。
  3. Prompts: 特定のタスクを行う際に利用可能な、パラメーター化されたシステムプロンプトや命令セットのテンプレート。

「プロトコル」とは具体的に何を定めているのか？

MCP が「プロトコル」と呼ばれる理由は、上記のような「サーバーがどんな Tool や Resource を持っているか（List）」「それをどう呼び出して引数を渡すか（Call/Read）」に関する情報のやり取りを、共通の JSON-RPC フォーマットとして規格化しているからである。 従来のように「Slack API用の規格」「GitHub API用の規格」と個別にクライアント（AIアプリ）側で通信プログラムを実装する（N×M問題）必要がなくなり、クライアントは「MCPの共通言語（JSON-RPC）」さえ話せれば、どんな MCP サーバーとでも即座に接続し、中身の機能を利用できるようになる。

プロトコルの通信仕様

MCP の通信プロトコルは JSON-RPC 2.0 をベースに設計されている。 Gemini CLI と MCP サーバー間の通信は、主に以下のトランスポート層を介して行われる。

  • stdio (標準入出力): ローカル環境で MCP サーバーをサブプロセスとして起動し、標準入出力を通じて JSON-RPC メッセージをやり取りする。
  • HTTP / SSE (Server-Sent Events): リモートサーバーとの通信に利用される。HTTPリクエストで指令を送り、SSEで非同期にサーバーからのイベントやストリームを受け取る。

「MCP を呼び出す」というツール（Function Call）が存在するのか？

「MCPを呼び出す」という単体の Function Call は存在しない。

統合メカニズムとプロキシ実行 (シーケンス図)

前述の通り、「MCPを呼び出す」という名前の単体の Function Call は存在しない。 Gemini CLI（クライアント）は、MCP サーバーが公開する Tool / Resource / Prompt の定義だけを吸い上げ、実際の処理はすべて MCP サーバーへ委譲（プロキシ）するルーターとして機能する。

1. Tools (ツール) の実行プロキシ

ツールの実体コード（実際の処理）はすべて MCP サーバー側にある。 Gemini CLI には関数の「名前」と「引数の仕様（定義）」だけが登録され、それが LLM の Tools Schema に追加される。LLM が引数を指定して呼び出すと、CLI がそれを JSON-RPC に翻訳して MCP サーバーへ送信し、MCP サーバー側で実際の計算や外部通信が行われる。

Loading diagram...

2. Resources (リソース) と Prompts (プロンプト) の扱い

Resources や Prompts も、ツールと同様に「MCP サーバー側がデータの実体を持っている」。 AIクライアント（Gemini CLIなど）は、これらを取得するための標準化された JSON-RPC メソッド (resources/read, prompts/get) を使って MCP サーバーと通信する。 LLM から見ると、これも「特定のリソースURIを読み込むための汎用ツール（例: read_resource）」として Function Calling の枠組みの中で提供され、必要に応じて動的にデータをロードする仕組みをとることが一般的である。

Loading diagram...

MCP vs CLI vs API

比較観点CLI (コマンドライン)通常のAPI (REST / OpenAPI 等)MCP (Model Context Protocol)
主要なインターフェース層OS / シェルHTTP / ネットワークJSON-RPC (stdio / SSE)
主な利用者・クライアント人間のオペレーター、AIシステム間連携、AI主にAI・エージェント基盤
Pros (強み・メリット)・トークン高効率: LLMが事前に使い方（man等）を学習済みであり、定義の読み込みコストが最小。
・コンポーザビリティ: パイプやリダイレクトによる多段ツールの連鎖結合が容易。
・実装リソースの統合: 人間用の運用ツールとAI用のツールを1つのバイナリで作れる。
・即応性: ローカルファイルの操作やOS依存のタスクに強い。		・既存資産の活用: 既に存在する堅牢なバックエンド基盤、API Gateway、認証基盤をそのまま流用可能。
・スケーラビリティ: 負荷分散やキャッシュ制御など、Webの標準技術の恩恵を受けられる。
・汎用性: AIだけでなく、従来のWebフロントエンドや他システムと完全に共用できる。		・プロトコルのカプセル化: 通信ロジックや認証フローをサーバー側に隠蔽し、LLMに「単なる関数呼び出し」として提示できる。
・双方向・ステートフル通信: ライフサイクルの維持、実行途中のプロンプト更新、サーバーからのイベントプッシュ（通知）が可能。
・AI向けの型定義: Tool/Resource/PromptというAIのコンテキストに最適化された規格が備わっている。
Cons (弱み・デメリット)・ガバナンスと監査: クライアント環境（LLMの実行環境）に強く依存するため、ゼロトラストなセキュリティ境界を設けにくい。
・状態（ステート）管理: 原則ステートレスであり、持続的な接続やセッション管理が必要なタスクには不向き。
・出力の曖昧さ: エラーや標準出力が非定型なテキストになりがちで、LLMの解釈ミス（JSONパースエラー等）を誘発しやすい。		・LLMの推論負荷: LLM自身が仕様を解釈し、ヘッダー・トークン・ペイロードの構造を自力で組み立てる必要がある。
・コンテキストの圧迫: 巨大なOpenAPIスキーマをそのまま読み込ませるとコンテキストウィンドウを大幅に消費する。
・状態（ステート）管理: 原則ステートレス。		・オーバーヘッド: クライアントとサーバー間に新たなRPCレイヤーが挟まるため、プロセス管理等の通信コストが生じる。
・トークン浪費リスク: ツールの責任境界を広げすぎると、初期化時に膨大なツール定義仕様を送り込みコンテキストを圧迫する。
・人間の操作性: ツール自体を人間がターミナル等から手早く直接叩くことが困難。
セキュリティ・権限管理クライアント依存
実行ユーザーのOS権限やローカルに置かれたクレデンシャルに依存する。		サーバーサイド（標準規格）
OAuth, JWT等、既存のWeb標準の防御機構を前段に配置できる。		サーバーサイド（AI特化）
LLMの要求単位で細かなRBAC（ロールベースアクセス）や監査証跡を残しやすい。
AIの通信時における
抽象度・認知負荷		低（素の操作）
生コマンドの構築をLLM自身が行う。（学習済みのため推論負荷は低いが、自由度が高すぎる）		中（通信プロトコル）
HTTPやRESTの規約に従い、LLM自身がリクエストフォーマットを正確に構築する必要がある。		高（関数レベルの抽象化）
バックエンドの複雑な手続きから解放され、平易な関数（Tool）として解釈できる。

  • とはいうけど、わざわざ MCP にするのはよほどよくやらせたい汎用的な定形タスクがあるときだけに見える。

    • CLI は「Why」や「How」を定義できない。逆に、MCPをただのデータ取得のラッパとして使うならあまり意味がなさそう
    • 実は、Tools でも Resources でもなく、そのプロバイダが提供するプロンプトベストプラクティスの公開としての Prompts の動的公開が本質的に重要になるのではないか

  • https://zenn.dev/hiraly/articles/3409b886607274 言われているデメリット

    • コンテキスト（トークン）の過剰な消費: 同等機能のCLIツールの説明が約225トークンで済むのに対し、MCPはツール定義が重く（GitHub: 93ツール/約55,000トークン、Playwright: 21ツール/13,700トークン）、質問前にコンテキストウィンドウの大半を埋め尽くしてしまう。
    • スケーラビリティの物理的限界: アンチパターンの構成（10サーバー接続時など）ではツール定義だけで100,000トークンを超過し、エージェントの推論効率とパフォーマンスが著しく低下する。
    • 解決策の自己矛盾: プロトコル設計者であるAnthropic自身がこのスケーリング問題を認め、全ツールの事前ロードをやめる「Tool Search Tool」や「MCPをコードAPIとして扱う（150,000トークンを2,000トークンに削減）」という回避策を公式に推奨せざるを得ない状態になっている。
    • 認証基盤の二重管理: CLIはOS上の既存の認証基盤（kubeconfig, SSO, gh auth login 等）をそのまま再利用できるが、MCPは独自の認証レイヤーを要求するため、導入サーバーが増えるほど認証プロセスが際限なく増殖する。
    • CLIとの二重開発・管理: 多くのMCPサーバーの実態は単なる既存CLIのラッパーであり、単により多くのものを開発・管理・保守する必要が出ているだけとなっている。まだ結論が出ていないので何とも言えないが、MCPの開発は対社外的にAI時代に早乗りしているというアピールにしかなっていない可能性がある。
    • プロセスの維持と不安定性: CLIはディスク上のバイナリを単発で起動するだけで済むが、MCPは常にバックグラウンドプロセスとして維持する必要があり、初期化の失敗やフリーズが生じた際にクライアント全体の再起動が必要になる。
    • 権限制御の粒度の粗さ: CLIであれば「リソース閲覧（view）は常時許可、変更（merge）は人間承認」といった細かなOSレイヤーの権限制御が容易だが、クライアントの実装によってはMCPはツール単位での大まかなアクセス許可しか設定できない。
    • 不要な抽象化によるデバッグ困難: 多くのMCPサーバーの実態は単なる既存CLIのラッパーであり、本質的な機能追加がないまま間にJSON-RPC層を挟むことで、人間が「AIが何を実行してどう失敗したか」を追及しにくくなっている。
    • 設計前提の崩壊（陳腐化）: MCPは「LLMがツールの仕様を自力で理解できない」という前提で作られたが、現在のLLM（o1, Opus 4.6等）は直接manページを読んでCLIを組み立てたり、JSON出力を自律的にパース・リカバリーできる推論能力を獲得したため、構造化して教えるためのオーバーヘッドコスト（XML/JSONの無駄）がモデルの自力解釈コストを上回ってしまった。

指示

やりたいこと。https://home.wakatabe.com/ryo/wiki/index.php?%E3%83%89%E3%82%A4%E3%83%84　をホスティングしているがサーバがオンプレなのでGCP GCS静的ファイルホスティングに移行したい。https://home.wakatabe.com/ryo/wiki/index.php?%E3%83%89%E3%82%A4%E3%83%84の
ルールに日本語で会話することをかいて。ドキュメントは日本語にすることを書いて。人間とのやり取り、TODOリスト管理のためのinteractions/というディレクトリを作って、人間にやってほしいことのチェックリストおよび終わったことを別ファイルで管理するようにして。
spec/に極めて詳細なWBS/設計書を書いて。

MCP サーバ

外部サービスに Token が必要だったりしながら AI が勝手に接続する機能

Notion

例えば、Notion では

  • Antigravity > Customization > MCP Server > Notion > Set API token

image.png

  • API Token を取得するために Notion の「内部インテグレーション」からトークン取得

image.png

  • Notion のページで「Connect」から Antigravity へのアクセス許可をする

image.png

  • Antigravity で Notion を読み込めというと読んでくれる

image.png

Sequential Thinking

Planning の強力バージョンみたいな感じ？入れると API を呼び出してかなり深く Planning してくれる機能っぽい。

image.png

GitHub

  • ghp_v から始まる personal token を入れると、レポとかにアクセスできるようになる。

最終更新: 2026-04-07