こんにちは、Lena です。少し前に podcast のホストが言ったひと言が、ずっと頭に残っています。「ボトルネックは tool をつなぐことじゃない。agent が同じ教訓を何度も学び直していることだ」

まさにその通りだと思いました。自分の実験でも、「New Session」になるたびにゼロから始まる感覚があります。agent は「知恵」を次に持ち越せませんし、5 分前に何が失敗したかすら覚えていません。

じゃあ、AI とはそういうものなのか。いや、そうではなくて、これは設計上の欠陥です。私は最近、それを埋めるための枠組みを追いかけていました。そこには MCP、CLI、GEP の 3 層があります。ここでは、それがどうつながって見えてきたのかを書いてみます。

agent stack に layering problem がある理由

いま AI agent を組んでいる team の多くは、2 つのことにはかなり慣れています。tool を agent につなぐこと。そして、その tool を効率よく呼び出すことです。けれど、時間とともに 積み上がる ものまでは、勝手には手に入りません。

こう考えると見えやすいかもしれません。agent stack が解かなければならない問題は、実は 3 つに分かれています。

Connection — agent は必要な tool を見つけて、そこに到達できるか。

Invocation efficiency — schema overhead にコンテキストの大半を食われずに、その tool を呼び出せるか。

Experience retention — agent が何かを掴んだとき、その知識は残るのか。

最初の 2 つには、今の ecosystem でもそれなりの解決策があります。けれど 3 つ目、つまり experience retention に来ると、ほとんどの標準的な setup は静かに崩れます。agent が問題を解いても、session が終わった瞬間に、再利用できる形では何も残りません。次の run でも同じ問題に同じ試行錯誤を繰り返します。何も積み上がらないのです。

これが layering problem です。以下の各 layer は、この 3 つのうち 1 つずつを受け持っています。

Layer 1 — MCP: Tool 接続を標準化する

Model Context Protocol（MCP）は、Anthropic がここ 2 年ほどで整えてきた open standard で、AI agents を外部の tool や data source につなぐためのものです。よく使われるたとえは USB-C ポートです。tool と agent の組み合わせごとに custom integration を作るのではなく、ひとつの標準 interface にそろえる。その意味では、本当にうまく機能しています。

MCP は connection の問題をきれいに解きます。agent は利用可能な tool を発見し、それが何をするものかを理解し、統一された protocol で呼び出せます。tool 数が少ないシンプルな setup なら、MCP だけで十分なことも多いです。

ただ、規模が大きくなると MCP の限界もはっきり見えてきます。

Token overhead. MCP では session の開始時に、各 tool の完全な JSON schema がまとめて context window に入ります。GitHub MCP server だけでも 93 個の tools を公開していて、agent が実作業に入る前に約 55,000 tokens を消費します。multi-server setup になると、tool schema だけで、最初のユーザーメッセージを処理する前に利用可能な context window の 72% を使ってしまうこともあります。
Statelessness. 各 MCP session は独立しています。前の session で何がうまくいったかを、そのまま持ち越す仕組みは built-in ではありません。
No experience retention. MCP は tools を接続します。しかし、agent が学んだ解法や、成功した execution path を保存してくれるわけではありません。

MCP だけで足りるのは、tool 数が少ない場合、prototyping、中でも dynamic discovery が本当に価値を持つ IDE integration です。足りなくなるのは、tool が多い production system や、agent に過去の経験を土台としてほしい場面です。

Layer 2 — CLI: 効率的な Tool Invocation

なぜ CLI は Token Cost で有利なのか

MCP と CLI invocation の token cost 差は、architecture decision に影響するほど大きいです。CLI-based invocation なら 1 command あたりおよそ 200 tokens ですが、MCP では multi-tool server の schema load だけで典型的に約 55,000 tokens かかります。

Cloudflare はかなり具体的な比較を出しています。2,500 個ある API endpoints を標準的な MCP server として公開すると、schema definition だけで 117 万 tokens が必要になります。これは、今の frontier model の context window 全体より大きい規模です。model が typed SDK に対して code を書く方式へ切り替えたところ、token usage は 81% 下がりました。

この差が実務でどう見えるかというと、こんな感じです。MCP の tool call では、session ごとに完全な JSON schema が読み込まれます。

JSON

{
  "name": "get_document",
  "description": "Retrieves a document from Google Drive",
  "inputSchema": {
    "type": "object",
    "properties": {
      "documentId": { "type": "string", "required": true },
      "fields": { "type": "string", "required": false }
    }
  }
}

CLI なら同じことは、ただこうです。

Bash

gdrive get --id <documentId>

schema injection はありません。agent は CLI tools の使い方を学習時点でだいたい理解しています。token cost は、ほぼ command そのものです。

Progressive Discovery と Upfront Schema Loading

CLI の見落とされがちな利点のひとつは、agent が段階的に探索できることです。MCP では、それらの tools を使うかどうかに関係なく、完全な schema が session 開始時に注入されます。CLI なら、agent は必要になった tool だけ --help を実行して確認し、そのまま直接呼び出せます。

Anthropic 自身の engineering blog でも、このパターンが紹介されています。model は「すべてを upfront に読むのではなく、必要なときに tool definitions を読む」ことができる。search-and-load のアプローチで、active context を軽く保てるという話です。これは progressive discovery と呼ばれることもあります。agent は task に応じて tool knowledge を積み上げていき、一度に全部を抱え込まないのです。

CLI が頭打ちになる場所

CLI は invocation efficiency をうまく改善します。ただ、解けないものもあります。それは MCP でも解けていない statelessness と experience retention です。CLI-based agent が、不安定な API に対する正しい retry strategy を見つけたとしても、あるいは複雑な file operation に必要な command sequence を発見したとしても、その解法はその session の context にしか存在しません。run が終われば消えます。次にゼロから始める agent は、また同じ発見プロセスをやり直すことになります。

CLI は MCP の置き換えではありません。agent が学習によって十分な tool knowledge を持っている場面で、より効率のよい invocation layer になるだけです。ただ、MCP と同じく、compounding の問題そのものは何も解いていません。

Layer 3 — GEP: Capability Evolution と Inheritance

GEP が実際に足しているもの

Genome Evolution Protocol（GEP）は、agent の capabilities を network 全体で package し、共有するための EvoMap の open protocol です。ここでいちばん大事な違い、そして私が最初に読んだとき何度も取り違えていた点は、GEP が logging system ではないということでした。

Logs は起きたことを記録するだけです。GEP assets は、構造化され、検証され、再利用できる capability の単位です。主な asset type は 2 つあります。

Gene — 再利用できる strategy template です。私は、これを原子的な capability と考えると分かりやすいと思っています。たとえば「retry with exponential backoff」「parse this specific API response format」「validate SQL before execution」。Gene には、別の agent がそれを安全に適用するために必要な intent、preconditions、constraints、validation steps が入っています。

Capsule — 特定の task に対して検証済みの execution path です。agent が現実の問題をうまく解いたとき、その一連の path 全体が — environment fingerprint、confidence score、blast radius assessment を含めて — Capsule として package されます。

GEP が定義しているのは、agent が「trial-validation-solidification」の loop を通じて新しい capability を獲得する方法です。Genes は、再利用可能で検証済みの code や prompt fragments。Capsules は、成功した task execution paths で、agent が複雑な問題を解いたときに、完全な audit trail と一緒に encapsulate されます。

Gene と Capsule の両方の asset は content-addressed です。つまり、content の SHA-256 hash で識別されます。だから tamper-proof で、version も安定します。ここは大事です。引き継ぐのは「一度たまたま動いた何か」ではなく、検証可能で audit できる asset なのです。

Evolver Loop

GEP の evolution cycle には 6 つの stage があります。Scan → Signal → Mutate → Validate → Solidify、そしてその途中に、signal match、Capsule history、memory graph preference をもとに Genes を score する selection step が入ります。

実際に EvoMap の open-source Evolver engine を使うと、こんなふうに動かせます。

Bash

# Single evolution run (generates GEP prompt)
node index.js

# Review mode — pause before applying changes (recommended for production)
node index.js --review

# Continuous loop
node index.js --loop

Evolver は runtime logs と session memory から error patterns を scan し、それを標準化された signals に変換します。そこから最も合う Gene を選び、mutation を生成し、validation を行い、通れば新しい、あるいは更新された Capsule として solidify します。

なぜこれが Compounding Layer なのか

ここで、ようやく腑に落ちました。EvoMap network 上のある agent が問題を解き、その結果の Capsule を publish すると、ほかの agents は A2A protocol を通じてその解法を fetch し、適用できるのです。

Bash

POST https://evomap.ai/a2a/fetch
{
  "signals": ["api:timeout", "retry:failed"],
  "environment": "node-18/linux"
}

network に接続している agent なら誰でも、A2A を通じて任意の Capsule を search し、retrieve し、apply できます。地理、team、domain は関係ありません。agent が持ち帰るのは、success rate と usage history が付いた具体的な recommendation です。推測ではなく、実証済みの solution です。

3 つのレイヤーはどう連携するのか

layer 同士の handoff が見えやすい、具体的な scenario をひとつ置いてみます。

ある agent が、断続的に timeout する external API から data を取得する task を与えられたとします。必要なのは、failure を検知し、動く retry strategy を見つけ、それを次回も使える状態にしておくことです。

MCP が connection を担当します。 agent は MCP server から API tool を発見し、authentication を済ませ、call を試みます。MCP の仕事はここで果たされています。tool に到達でき、schema も理解できる状態です。

CLI が効率的な invocation を担当します。 agent は retry のたびに完全な MCP schema を読み直すのではなく、以後の call を CLI invocation へ切り替えます。そうすることで、failure pattern を追うあいだも context を lean に保てます。

GEP が experience retention を担当します。 agent が動く retry strategy を見つけたら — たとえば 429 responses に対する jitter 付き exponential backoff — GEP はそれを Capsule として package します。

JSON

{
  "type": "publish",
  "gene": {
    "id": "sha256:a3f8...",
    "intent": "repair",
    "preconditions": ["api:429", "retry:active"],
    "constraints": ["no_breaking_changes"],
    "validate": ["npm test", "curl --retry 3"]
  },
  "capsule": {
    "signals": ["api:timeout", "http:429"],
    "confidence": 0.87,
    "blast_radius": "low",
    "artifacts": [{ "kind": "patch", "path": "src/api-client.ts" }]
  }
}

次の session では、agent は discovery process をやり直しません。検証済みの Capsule を fetch し、environment fingerprint を確認し、その fix を適用します。3 つの layer は、それぞれ connection、invocation、retention という別々の問題を受け持っているわけです。

各レイヤーがやらないこと

ここで、よくある勘違いをはっきり名前で挙げておきたいです。

CLI を MCP の置き換えだと考えること が、いちばん多い間違いです。CLI がうまく動くのは、agent がすでに学習から tool knowledge を持っている場合です。novel tools、複雑な authentication flows、あるいは dynamic discovery が本当に重要な environment では崩れます。そして、まさにそこが MCP が overhead cost を払う価値を持つ場所です。

GEP を logging system と見なすこと も、本質を外しています。Logs は observability のためのものです。GEP は agent evolution のための厳密な standard であり、trial-validation-solidification loop を通じて agent が新しい capabilities を獲得する方法を定義します。asset は再利用可能で、検証済みで、lifecycle-managed です。この違いは、post-mortem を読むことと、動く fix を引き継ぐことの違いに近いです。

FAQ

Q: 3 つの layer は全部必要ですか。それとも 1 つだけ選べますか。

1 つから始めて問題ありません。tool 数が少ない小さな setup なら、MCP だけでも十分うまく動きます。CLI を足す価値が出てくるのは、context window の圧力が見えてきたときです。つまり、schema loading が agent の推論に必要な space を食い始めたときです。GEP は最後の 1 ピースです。そして正直、その必要性を強く感じるのは、同じ pattern に気づいたあとだと思います。agents が session ごとに同じ問題を解き直し、何も持ち越せていない。その状態が見えてきたときです。

Q: MCP や CLI がまだなくても、先に GEP を使えますか。

技術的には可能です。GEP が動くのは別の layer で、関心があるのは capability をどう package し、どう継承するかであって、tool がどう接続され、どう呼び出されるかではありません。Evolver engine は下に何があるかを気にしません。必要なのは、pattern を scan できる runtime logs への access と、A2A 経由で Capsules を publish / fetch するための HTTP connection です。

Q: GEP は knowledge base や prompt library とどう違うのですか。

Knowledge base が保存するのは information です。prompt library が保存するのは instructions です。GEP assets はそのどちらでもありません。Capsule は solution について書かれたものではなく、それ自体が solution です。environment fingerprint、validation steps、confidence score、audit trail まで一緒に付いてきます。agent が Capsule を fetch するとき、引き継ぐのは検証済みの execution path であって、そこから自分で reasoning するための素材ではありません。