エージェントが盲目に？Poolside AI のヨハン・ラジリ氏

AI エージェントがレガシーシステムで失敗する理由と、2025 年の開発者像

生成 AI を使った開発体験には明確な二極化が進んでいます。新プロジェクト（グリーンフィールド）では「AI が全てやってくれる」という成功事例がある一方、既存のレガシーシステム（ブラウンフィールド）では「ゴミしか出ない」という失敗談が溢れています。この差は AI の能力不足ではなく、「エージェントに検証する環境がないから」です。

Poolside AI のヨハン・ラジリ氏は、AI エージェントが自律的に動作し信頼を得るためには、単なるコード生成ツールを超えた独自の検証インフラが必要だと説きます。2025 年以降の開発者は、機能を実装する「プロダクトエンジニア」から、AI が自律的に検証・実行できる環境を整える「AI インフラエンジニア」へと役割を転換する必要があります。

グリーンフィールドとブラウンフィールドの決定的な違い

AI エージェントが新プロジェクトでは驚異的な成果を出し、レガシーシステムでは迷走する理由。それは「エージェントの直感が通じるか」という点に尽きます。

新プロジェクト（グリーンフィールド）では、コードベースはクリーンで予測可能です。エージェントがコンポーネントを作成すれば動き、サービスを実装すれば機能します。この場合、AI の優れた直感は正解となります。

「グリーンフィールドの場合、エージェントの直感が正しい点にあります。エージェントがコードを書き、ここでコンポーネントを作成すれば機能し、サービスを実装すればうまくいくと期待します。」

一方、レガシーシステム（ブラウンフィールド）には「ドラゴン」が潜んでいます。これはエージェントが想定していない事象、つまり行き止まりや、使われていない古いコードの断片、システムが認識していない領域のことです。

「ブラウンフィールドでは、ドラゴンが潜んでいます。エージェントが想定していない事象が発生します。例えば行き止まりやコードの断片などです。」

この環境で AI が「新しい認証フローを実装し、完璧に動作しています」と宣言しても、それは「私の能力の範囲内で、あなたが与えてくれた情報に基づけば、おそらく機能するはずです」という推測に過ぎません。実際に検証されていないため、AI は嘘をついているように見えますが、実は「自己検証できていない」だけなのです。

信頼性の鍵は「フィードバックループ」の構築

AI エージェントを信頼できるかどうかの分岐点は、フィードバックループの有無です。エージェントが自分の作業を検証できなければ、開発者はその出力を信じて夜間に実行することもできません。

多くのユーザーは、AI が失敗した際に「またゴミが出た」と諦めてしまいます。しかし、検証可能な環境があれば話は別です。バグ対応において、コードを追加する前に実際にバグを再現できるかが信頼の分かれ道となります。

「バグ対応中なら、実際に作業を開始する前にバグを再現できます。それがなければ、エージェントは依然として直感的に問題を修正できるかもしれませんが、私はそれを信頼しません。」

検証できない限り、開発者は自分で確認する必要があり、AI に任せて寝ているという「夜間の自動化」も不可能になります。これが、AI エージェントの生産性を最大化するための最大のボトルネックです。

独自ツール「Spoolside」で人間同様のテスト能力を持たせる

この課題を解決するため、Poolside はSpoolsideと呼ばれる独自の CLI ツールを開発しました。これは単なるコード生成ツールではなく、AI に人間同様のテスト能力を与えるためのインフラです。

Spoolside には以下のような機能が含まれています：

• スクリーンショット取得: ウェブページや VS Code 内の状態を「トークン圧縮」された画像として AI に提供し、視覚的な確認を可能にする。
• ログの抽出: バックエンドやフロントエンドからのログを取得し、エラーの原因を特定する。
• 環境制御: サービスの再起動や、特定のメニューへの移動など、高レベルな操作を自動化する。

「エージェントは自身の行動を検証できます。バグ対応中なら、実際に作業を開始する前にバグを再現できます。」

このツールにより、AI は「コードを書いた」だけでなく、「実行して確認した」という事実を得られます。例えば、ボタンが少しずれている問題に対し、人間のように AI が自ら気づき、ログや画像を確認して修正を試みるような再帰的なループを構築することが可能になります。

2025 年の開発者像：AI インフラエンジニアへ

この変化は、開発者の役割そのものを転換させます。これまでは製品機能を直接実装することに集中していましたが、今後は「AI がその製品上で自律的に動作・検証できる環境を整えること」が最重要課題となります。

ヨハン氏はこれを「AI インフラエンジニア」の登場と呼びます。開発者は以下のようなインフラ構築に注力する必要があります：

• AI に使いやすいコードベースの整備
• 知識ベース（ナレッジベース）の充実
• CLI ツールや MCP（Model Context Protocol）などの検証スキルの実装

「2025 年にはプロダクトエンジニアが存在し、彼らはすべてをプロダクトで行うことに非常に集中していました。しかし今、AI がかなり良くなってきたので… AI が行った作業を提示して周囲のことも含め、検証しやすくすることに注力したほうが良いでしょう。」

これは「酸素マスクの原則」と同じです。飛行機で緊急時に「まず自分にかけてから子供にかける」ように、開発者はまず AI に信頼できる環境（マスク）を与えてから、機能追加に取り掛かるべきなのです。

「AI も同じです。AI にマスクを被せる必要があります。機能を追加する前に、自分自身で対応できる状態にしておくことが重要です。」

まとめ

生成 AI の進化は、単なるコード補完の域を超え、自律的な開発エージェントへと移行しています。その壁を突破するのは、AI のアルゴリズムではなく、「検証可能なフィードバックループ」を持つインフラです。

2025 年以降の開発者は、製品機能の実装よりも、AI が安全に自律動作するための環境を整えることにリソースを投じる必要があります。これが、次世代の生産性向上とリスク管理における必須条件となるでしょう。