【ITニュース解説】Can Two Local AI Agents Build an App Without Me? I Gave Them 6 Rounds to Find Out

あるIT技術者が、AIエージェントにソフトウェア開発を完全に任せたらどうなるかという興味深い実験を行った。この実験の目的は、2つのローカルAIモデルがそれぞれソフトウェア開発者とコードレビュー担当者の役割を担い、人間の介入なしにアプリケーションを構築できるかを探るものだった。OpenAIやClaudeのような有料のクラウドサービスを使うのではなく、自分のPC上でOllamaというツールとPythonを使い、完全にローカル環境でAIモデル同士が連携するシステムを構築したのが大きな特徴だ。

実験のシステム「RelayLab」は、シンプルな開発チームを模倣した。まず、「Builder」と呼ばれるAIエージェントが開発担当で、製品の要望を読み、アプリケーションを作成または修正する役割を持つ。次に、「Reviewer」と呼ばれるAIエージェントがコードレビュー担当で、Builderが作成したものを検査し、実装をレビューして承認するか、変更を要求する。この2つのエージェントは、まるでリレーのように開発物を互いに渡し合い、作業を進める仕組みだ。RelayLabの核となるオーケストレーターはPythonで書かれ、エージェントが任意のコマンドを実行したり、PCの他の部分に影響を与えたりしないよう、厳しく制約された隔離された環境でファイル操作のみを許可した。これは、実験をシンプルに保ち、安全性を確保するためでもあった。

AIモデルの選定には、予想外の苦労があった。最初は比較的大規模なモデル（Builderにqwen2.5-coder:7b、Reviewerにqwen3:8b）を試みたが、PCのCPU使用率が100%に達し、システムが事実上フリーズしてしまった。これは、Ollamaが両方のモデルを常にメモリに保持しようとしたため、GPUメモリが不足し、CPUに処理が溢れてしまったのが原因だった。そこで、より軽量なモデル（Builderにqwen2.5-coder:3b、Reviewerにqwen3:4b）にダウンサイズし、さらにOllamaの設定でkeep_alive: 0と指定することで、各モデルが処理を終えるたびにメモリからアンロードされるように変更した。これにより、GPUメモリの競合が解消され、スムーズな動作が可能になった。この経験から、ローカル環境で複数のAIモデルを動かす際には、リソース管理が非常に重要であることを学んだ。また、Ollamaのインストール自体にも問題があり、モデルのダウンロードはできたものの、実際に実行するためのバイナリが不足していたため、再インストールを余儀なくされた。この初期の段階で、ローカルAI環境のセットアップには多くの予期せぬ課題があることが明らかになった。

エージェント間の対話が始まると、さらなる問題が浮上した。実験は「作成、完了、削除ができる洗練された単一ページメモアプリを構築し、使いやすくすること」という指示で開始された。Builderが最初のHTMLファイルを生成し、Reviewerはすぐに変更を要求した。この開発とレビューのサイクルが何度も繰り返されたが、Reviewerは「承認」または「変更要求」の2つの厳密なステータス形式で返答するように求められていたにもかかわらず、しばしば異なる表現を使ってしまった。例えば、「revision required」のような独自の言葉遣いや、ステータスフィールド自体がないJSON形式で返答することがあった。これに対し、RelayLabのオーケストレーターは「AgentProtocolError」を発してクラッシュしてしまう。AIが適切な判断を下していても、決められた形式で表現できないためにシステムが停止する、という事態だ。この問題を解決するため、オーケストレーター側で「rejected」「needs_changes」といった様々な表現を「changes_requested」に正規化したり、無効な応答も安全に「変更要求」として処理したりするよう、より柔軟な設計に修正された。この経験から、AIモデルが必ずしも推論に失敗しているわけではなく、「定められたプロトコルに従う」という点で失敗していること、そしてシステム設計においてこの「プロトコル遵守」に対する堅牢性が極めて重要であることを深く理解した。

最終的に、システムは6ラウンドのサイクルを完走したが、全てが「変更要求」で終了した。完成したメモアプリは、機能的にはメモの作成、完了、削除が可能だったものの、その見た目は非常に簡素で、まるで1990年代のHTMLチュートリアルに出てくるようなデザインだった。最初の指示にあった「使いやすくする」という要求からは程遠いものだったのだ。興味深かったのは、最終ラウンドでのReviewerのフィードバックが、機能の根幹ではなく、例えば「完了状態を切り替えるとノートテキストに余分なスペースが入る」といった特定の細かい実装上のバグに焦点を当てていたことだ。技術的には正しい指摘かもしれないが、アプリケーション全体のユーザビリティという大きな問題には触れていなかった。

この実験で明らかになった最も重要な点は、AIエージェントが互いに協力し、問題を特定し、修正する能力はあったものの、全体として「より良い製品」を生み出すことには繋がらなかったという事実だ。エージェントたちは局所的な最適化に陥り、Reviewerが指摘した個別のバグをBuilderが修正するというサイクルを繰り返しただけで、根本的な「使いやすさ」や「製品の品質」といった、ユーザーの全体的な要求に目を向けることはなかった。どちらのエージェントも、一歩引いて「これは本当にユーザーの要望を満たしているのか？」と問い直す役割を持っていなかったのだ。この問題は、単にエージェントを増やせば解決するものではない。「開発者AI＋レビューAI＝より有用」という単純な足し算にはならないことを示している。エージェント間の相互作用の設計、つまり「何を完了とするか」の明確な定義、受け入れ基準、優先順位付けといった「マネージャー」のような役割が不可欠であることが判明した。

この結果を受け、今後のRelayLabの改善計画として、エージェントに対して機能性、ユーザビリティ、アクセシビリティ、視覚的品質など、より具体的で明示的な「受け入れ基準」を与えることが挙げられている。さらに、Reviewerがソースコードだけでなく、実際にブラウザでアプリケーションを開き、操作し、スクリーンショットをキャプチャして視覚的なフィードバックも得られるような「ブラウザ検証」の導入も検討されている。これにより、ソースコードの品質だけでなく、実際のユーザー体験に基づいたレビューが可能になり、AIがより総合的な観点から製品を評価できるようになることを目指す。

この実験は、たとえ開発したアプリが期待通りでなかったとしても、決して失敗ではなかった。インフラは正常に機能し、2つのローカルAIモデルが異なる役割を担い、フィードバックを交換し、共有された成果物を修正し、複数回のイテレーションを乗り越え、全てを自分のPC上で実行できたことは大きな成功だった。ここから得られた最大の教訓は、「会話だけでは協調は生まれない」ということだ。AIエージェントには、明確な制約、成功の共通定義、現実世界の環境を観察するためのツール、そして時には、あいまいな表現を正しいプロトコルに変換するような、人間が介在する（あるいはコードで模倣された）「調整役」が必要なのだ。この知見は、AIを活用したソフトウェア開発システムの未来を考える上で、非常に重要な一歩となるだろう。