エージェント開発はなぜ「BASIC」に退化したのか
深夜の障害対応でスパゲッティコードを解読する際、我々エンジニアは「なぜこんな設計にしたのか」と天を仰ぐことがある。しかし、今まさに我々がAIエージェント開発の現場で繰り返しているのは、まさに50年前に我々が卒業したはずの「BASIC」的な開発スタイルそのものだ。Walmart Global TechのテクニカルフェローであるJake Mannix氏がInfoQで指摘した通り、現在のエージェント開発は、巨大なメインメソッドの中にすべてのロジックを詰め込み、GOTO文のように非決定的な挙動を繰り返す「1975年型プログラミング」に陥っている。
「英語」という新しいプログラミング言語を手に入れた我々は、一見すると高度なことをしているように錯覚する。しかし、実態はどうか。LLMのプロンプトという名の「メインファイル」に、あらゆるツール定義や指示をベタ書きし、コンテキストウィンドウという名のメモリ空間にすべてを流し込む。そこには、ソフトウェア工学が半世紀かけて積み上げてきた「カプセル化」「インターフェース」「依存関係の管理」といった概念が驚くほど欠落している。この現状は、単なる技術的未熟さではなく、AIというブラックボックスを制御するための「標準化された抽象化レイヤー」が不在であることに起因していると私は考える。
多くの開発者が陥っているのは、LLMの推論能力を過信し、ツール定義をそのままプロンプトに流し込むという「コピペ駆動開発」だ。例えば、Jiraのチケット管理ツールを導入する際、組織IDを固定するようなビジネスロジックをLLMの指示に埋め込む。しかし、別のチームが同じようなツールを別の文脈で定義すれば、LLMは混乱し、非決定的な挙動を引き起こす。これは、大規模なシステム開発において、依存関係を解決せずにライブラリをソースコードに直接埋め込むようなものであり、保守性や拡張性を完全に破壊する行為に他ならない。
MCPがもたらす「共有ライブラリ」の光と影
この混沌とした状況を打破するために登場したのが「Model Context Protocol (MCP)」だ。Mannix氏も認める通り、MCPはエージェント開発における「共有ライブラリ」や「サービス指向アーキテクチャ（SOA）」の概念を導入する重要な一歩である。SlackやStripeといった外部サービスとの接続を、エージェント本体から切り離し、独立したサーバーとして管理する。これにより、ツール開発者は「何が適切な粒度か」「どのようなパラメータが必要か」という専門知識をツール側に閉じ込めることが可能になった。これは、API設計のベストプラクティスをAIエージェントの世界に持ち込む試みであり、評価に値する。
しかし、MCPの現状の実装には、シニアエンジニアとして看過できない致命的な欠陥がある。それは、ツール定義を「そのままプロンプトに流し込む」という設計思想そのものだ。MCPサーバーが提供するスキーマや説明文は、結局のところLLMのコンテキストに「文字列として」注入される。これは、NumPyのようなライブラリをインポートするのではなく、ライブラリのソースコード全体をメインファイルに展開（マクロ展開）するようなものだ。これでは、名前の衝突や、文脈による解釈の揺らぎを制御することは不可能に近い。
以下の表は、従来のエージェント開発と、目指すべき「ソフトウェア工学的なエージェント開発」の比較である。
| 項目 | 現状（コピペ駆動） | 理想（コンポジション） |
|---|---|---|
| ツール定義 | プロンプトへのベタ書き | インターフェースによる抽象化 |
| 依存関係 | 暗黙的・非管理 | バージョン管理された共有ライブラリ |
| ビジネスロジック | LLMの推論に依存 | カプセル化されたラッパー関数 |
| 安全性 | プロンプトインジェクションのリスク大 | ランタイムでの汚染追跡（Taint Tracking） |
我々が直面しているのは、ツールを「提供する側」と「利用する側」の契約が極めて脆弱であるという問題だ。エージェントの作者は、自分が何を使っているのかを正確に制御できず、ツール作者は、自分のツールがどのような文脈で呼び出されるかを予測できない。この「契約の不在」こそが、エージェントをプロダクション環境で運用する際の最大の障壁となっている。
エージェントの「推論」を誰が所有するのか
結局のところ、エージェント開発における最大の問いは「推論の所有権」をどこに置くかだ。現在の開発手法では、エージェントの作者がすべての責任を負いながら、その制御権はツール作者が提供するプロンプトの断片に依存している。これは、分散システムにおける「責任の所在が不明確なマイクロサービス」と同じ状態だ。我々が明日から取るべき対策は、単にMCPを導入することではない。MCPサーバーをラップし、インターフェースを定義し、LLMが解釈する前に「ツール定義を変換・検証する中間プロトコル層」を構築することである。
例えば、動的なスキーマ投影や、ランタイムでの汚染追跡（Taint Tracking）を実装し、LLMが不適切なツール呼び出しを行わないようガードレールを設ける必要がある。これは、かつて我々がSQLインジェクションを防ぐためにプリペアドステートメントを導入した歴史と重なる。AIエージェントもまた、単なる「英語でのプログラミング」という幻想から脱却し、型安全で、テスト可能で、バージョン管理された「ソフトウェア」として再定義されなければならない。
読者諸氏に問いたい。あなたが今書いているそのエージェントは、5年後もメンテナンス可能か？ ツール作者がプロンプトを書き換えただけで、あなたのエージェントが沈黙するような脆弱な設計を、いつまで許容するつもりか？ AIの進化速度に翻弄されるのではなく、ソフトウェア工学の原則をAIという新しいパラダイムにどう適用するか。その答えを出すのは、フレームワークの作者ではなく、現場で泥臭い障害対応を繰り返している我々エンジニア自身であるはずだ。明日から、プロンプトを「コード」として扱い、テストとCI/CDのパイプラインに組み込むことから始めてほしい。それが、AI時代を生き抜くエンジニアの唯一の生存戦略である。
コメント