AI駆動開発 2026年10月4日

AIエージェント全史2026：スキル1万件登録の熱狂、20万台危機のMCP、そしてPoC地獄を抜けた先にあるもの

AIエージェントの「全史」を振り返る意味

AIエージェントをめぐるニュースは、ここ数年ずっと「凄い」と「危ない」の繰り返しだった。

ただ、2026年に入って少し状況が変わったと感じる。凄いと危ないが、もはや順番に来るのではなく、同時に、同じ話の中で展開されている。スキル登録が72時間で1万件を突破したというニュースと、そのMCPに20万台のサーバーを危険にさらす脆弱性が見つかったというニュースが、事実上ひとつながりの話として語られる時代になった。

今回参照したきなこもっちーのテック深掘りの記事は、このAIエージェントの流れを「全史」として整理したものだ。技術の変遷を追いながら、今起きていることの文脈を丁寧に置いている。ここではその事実を土台に、実務の現場から見た意味づけを加えてみたい。

スキル標準化の波：Agent SkillsからAgent Pluginsへ

まず「スキル」の話から整理したい。

AIエージェントが何かを「できる」ようになるには、スキルや外部ツールとの接続が必要になる。そのスキルを共有・再利用する仕組みとして登場したのがMCP（Model Context Protocol）であり、その周辺の標準化の動きだ。

72時間で1万件のスキルが登録されたという数字は、エコシステムが爆発的に広がったことを示している。2026年8月時点でMCPサーバーは2万件を超え、月間ダウンロード数は9700万に達した。Vercelが「Agent Plugins」という新標準を出し、ChatGPTやVS Codeが対応したことで、この流れはさらに加速している。

ここで少し立ち止まって考えたいのは、「標準化」が何を意味するかだ。

スキルの登録数やダウンロード数が増えることは、確かにエコシステムの成熟を示す。しかし、誰でもスキルを登録できる構造は、品質管理とセキュリティのリスクを同時に内包している。npmのエコシステムがたどった道と重なる部分がある。利便性と脆弱性は、オープンなエコシステムでは常にセットで来る。

MCPの「セキュリティ悪夢」：普及の影に潜む構造的脆弱性

その懸念が現実になったのが、CVE-2026-30623だ。

2026年4月、MCP公式SDKに深刻な脆弱性が発見され、最大20万台のサーバーが危険にさらされる事態となった。月間9700万ダウンロードという普及規模を考えると、影響範囲の大きさは想像に難くない。

注目したいのは、Anthropicがこの脆弱性に対して「仕様どおりの挙動」として設計変更を拒否したという点だ。

これは単なる強がりではないと思う。MCPの設計思想の中に、この挙動を「問題」と見なさない前提があったのだろう。後にOAuth 2.1の認証フローを導入し、接続前の同意を必須にすることで対応したが、これは言い換えれば**「後追いで安全弁を付けた」**構造だ。

セキュリティを設計の中心に置いていなかった、という批判は避けられない。ただ、AIエージェント関連の標準プロトコルの多くが、まず「動くもの」を作ってから安全性を強化するという順序を踏んでいる。急成長するエコシステムの宿命とも言えるが、企業がこれを使う判断をする際には、その「後付け感」を理解した上で採用する必要がある。

88%という数字が示すもの：企業はリスクを知りながら導入を続けている

2026年のレポートによれば、企業の88%がAIエージェントのセキュリティ事故を経験済み、または経験した疑いがある。

この数字を見て「だからAIエージェントは危険だ」と読むのは、少し筋が違う。

ここからは見方の話だが、88%という数字が示しているのは「それでも導入を止めない選択をしている企業が多数派だ」という現実だ。リスクを知らないから使っているのではなく、リスクを知りながら、そのリスクと引き換えに得られる効率・競争力を選んでいる。

これはバグではなく、企業の合理的な判断の結果だと思う。問題は「使うか使わないか」ではなく、「リスクをどう管理しながら使うか」に既に移っている。にもかかわらず、多くの現場では「とりあえず試してみる」のフェーズのままリスク管理の仕組みが追いついていないケースが多い。

プロダクト担当や経営者が今考えるべきなのは、「うちはAIエージェントを使うべきか」ではなく、「使う前提で、どのリスクを許容し、どのリスクを遮断するか」の設計だ。

PoC地獄の正体とLangGraph 1.0の意味

スキルが充実し、セキュリティの議論が進んでも、AIエージェントの多くはまだPoC（概念実証）段階にとどまっている。

記事では、カスタムAIツールの5%しか本番稼働に届かないと述べられている。これは2026年に入っても変わっていない現実だという。

なぜこうなるのか。技術が足りないから、という話ではない。本番環境には「動くこと」以外の要件が山積している。監視・ロールバック・権限管理・エラーハンドリング・コスト制御、そして説明責任。PoC段階では見えない問題が、本番に向けた設計段階で一気に噴き出す。

LangGraph 1.0の到達と、UberやLinkedInのような大企業の本番環境での採用は、ここに対する一つの答えだ。グラフ構造でエージェントのフローを明示的に定義するLangGraphのアプローチは、「動くものを作る」ではなく「管理可能なものを作る」に向いている。本番運用に必要な可観測性や制御性を、フレームワークレベルで提供しようとしている点が重要だ。

コスト面でも変化がある。NVIDIAの新型Nemotron 3 Ultraが、近い精度のタスクを1回あたり10分の1近くのコストでこなせるようになったという。本番運用でのコスト障壁は確実に下がってきた。ただ、コストが下がるだけでPoC地獄が解消するわけではない。設計・運用・監視の整備が追いつかなければ、「安くたくさん失敗できる環境」になるだけだ。