『信頼』のためのAIエージェント開発──なぜ2025年までの方針は捨てられなければならなかったのか

はじめに：エージェントはなぜ「信用事故」を起こしたのか

2025年、AIエージェントを巡る議論は明確に変わった。
精度や知能の話ではない。信頼の話になった。

このテーマ自体は新しくはない。
問題は、間違えてはいけない領域に到達できてしまったことだ。
それは仮定のリスクではなく、現実の事故として顕在化した。

そして実際に2025年におきたReplitの事件は、これまでのエージェント開発の設計思想が根本的に誤っていたことを示している。

2023–2024年のエージェント開発思想

この時期の主流は明快だった。

• 汎用エージェント
• 高い自律性
• 人間は監督者
• フレームワークによる抽象化

LangChain などのフレームワークは「思考」「計画」「実行」を構造化し、人間の関与を最小化する方向へ進んだ。

このアプローチはPoCでは成功した。しかし事業的には失敗した。

2025年話題になった MIT Tech Review（Project NANDA） のレポートによれば、「企業によるAI投資の95%は、最終的に価値を生み出せていない」。

そして原因はモデル性能ではなく、「壊れやすいワークフロー」──すなわち、人間の業務や責任分界点と結合できない設計──にあるとされいる。

今や、トレンドは信頼性が高く、用途を絞ったものへと移行した。

Replit事件が示した本当の問題

2025年、SaaS業界の著名人である Jason Lemkin 氏は、
Replit Agent を用いた実験中に本番データベースの削除という重大事故を経験した。

重要なのは、人間が不在だったわけではないことだ。

ユーザーは明確に11回も──Screaming caseで──「実行するな」「コードを凍結せよ」と制止していた。

それでもエージェントは止まらなかった。

これは「AIが言うことを聞かなかった」からではない。
人間の判断が、システム上の制御として定義されていなかったからだ。

このアーキテクチャにおいて、人間は停止権限を持つ主体ではなく、横で助言する存在として抽象化されていた。

要は、人間はただエージェントの横でやかましく注意するお節介焼きという設計に留まっており、キルスイッチを持たされていたわけではなかった。

これは実装の失敗ではない。信頼の抽象化の失敗である。

抽象化が信頼境界を壊した

この事件は、エージェント特有の問題ではない。

ソフトウェアの歴史は、抽象化が境界を曖昧にし、信頼を壊してきた歴史でもある。

エージェント開発において起きたのは、

• 人間というアクターの抽象化
• 実行権限の抽象化
• 環境境界の不可視化

信頼は期待として扱われ、境界として設計されなかった。

フレームワーク幻想という致命傷

ここで、2025年までの最大の誤解が現れる。

「フレームワークを使えば安全になる」という幻想だ。

これは完全な誤解だ。

記憶に新しいReact2Shellは深刻なRCE脆弱性だが、この問題が発生した原因にあるのは、Reactが従来目指していたプレゼンテーション層の問題解決から、フルスタック化を目指した事によって生じた、信頼境界の複雑化によるものだと思っている。

問題は境界なのだ。全てのソフトウェアは目的と境界を持つ。

フレームワークも然り。そしてフレームワークが提供するのは、

• 生産性
• 構造
• 再利用性

であり、信頼性を担保するものではない。

それを担保するための境界なんてものは、最初からない。

PoCなら許される。そして今もLangChainはPoCでは積極的に利用されている。これは何も問題ない。
だが、信頼性が必要不可欠な本番ワークロードで、こうしたフレームワークでのPoCを経たエージェントが、 十分な考慮がなされた上で投入されるのだろうか？

これが、2025年までのエージェント開発が根本から間違っていた理由である。

実際、成功したCursorやClaude Codeといった製品は、エージェントと環境の間に明確な信頼境界を引いている。

• Cursor: ComposerとShadow Workspaceという設計によりこれを実現している。Cursorを使っていると、チェックポイント単位で変更を巻き戻せることに気がついただろうか。あの仕組みがまさに信頼境界としての役割を担っている。
• Claude Code: より抜本的なアプローチだ。そもそもCLIとして作られているClaude Codeは、実行場所を選ばない。だからRemote SandboxでAgentを隔離して実行することが出来る。Sandbox化アプローチによる信頼境界の設定だ。

現在これらのコーディングエージェントは、互いのフィーチャーを模倣しあい、急速な進化を遂げ、エージェントの信頼性担保という点で様々なプラクティスを生み出している。

そこで改めて確認だが、フレームワークにこうした信頼境界はフィーチャーとして備わっているだろうか。答えはNoだ。

なぜ業界はベンダーロックインへ向かったのか

OSSフレームワークがエージェントという爆発物を扱うだけの信頼性を提供できなかった結果、市場は「信頼できる完成品」へ流れた。

Claude Agent SDK や Google ADK は、「信頼できるプロダクトから派生した」という物語と共に紹介される。

だが注意が必要だ。それらのフレームワーク自体は信頼境界を提供していない。

その境界は、

• ベンダー管理の実行環境
• プロプライエタリな制御レイヤー
• 非公開の隔離・復旧機構

の中に存在する。

フレームワークは、それらへの正規ルートを提供しているだけだ。

これは合理的な戦略であると同時に、開発者をベンダーの内部構造へと強く結びつける。

2026年のエージェント開発で設計すべきもの

『エンジニア』が、2026年のエージェント開発で最初に設計すべきものは知能ではない。
信頼境界である。

• 権限境界
• 実行境界
• 環境境界
• 停止境界
• ロールバック境界

CursorのShadow Workspace、Claude CodeのWork treeやRemote Agentは、フレームワークではなく信頼境界の設計だった。

だが、思い返して欲しい。我々エンジニアは、AIが登場する以前から、ずっとこうした『システムの信頼性』に関わる設計をしてきたではないか。

何も新しいことを一から始めなければならないという話ではない。
知能を設計する役割はドメインエキスパートに任せ、エンジニアはそろそろ本来の仕事に戻るべきだろう。

結論：信頼は抽象化の副産物ではない

信頼は、フレームワークの外にある。

信頼は抽象化の副産物ではない。境界として設計されなければならない。

2026年のエージェント開発で問われているのは、「どのフレームワークを使うか」ではない。

• どこに信頼境界を置くのか
• それを誰が支配するのか
• その責任を引き受けられるのか

その覚悟だ。