【ITニュース解説】I Let AI Plan 170 Changes. It Made the Same 3 Mistakes Every Time.

AIの進化は、システム開発や運用、計画策定での活用を期待させる。しかし、AIが立てる計画の信頼性は、まだ検証段階だ。あるエンジニアが構築した「PlannerCritic」というシステムを通じて、AIによる計画策定の現実と、そこに潜む課題、そしてその解決策が深く掘り下げられている。

PlannerCriticは、シンプルながらも巧妙な仕組みを持つシステムだ。まず、大規模言語モデル（LLM）が「プランナー」として、システムの変更計画を作成する。この計画には、実行すべきタスク、その前提条件、実行順序、そして問題発生時に元の状態に戻すための「ロールバック」の手順が含まれる。次に、この計画は「決定論的なゲート」と呼ばれる層を通過する。これは、LLMを一切使わず、あらかじめ決められた厳格なルールに基づいて計画を検証する仕組みだ。もし計画がこれらの硬いルールに違反していれば、そこでブロックされる。ゲートを通過した計画は、さらに別のLLMである「クリティック」によってレビューされる。クリティックが問題を発見すれば、プランナーは計画を修正しようと試みるが、一定回数修正しても改善が見られない場合は、人間のエンジニアに判断が委ねられる。このシステムは、アイデンティティ管理、システム信頼性エンジニアリング（SRE）、サプライチェーンポリシーなど、40もの多様な領域にわたる170もの実世界の変更計画目標に対してテストされた。総コストはわずか0.49ドルという安さだった。

テストの結果、「AIモデルが単純に悪い」という結論ではなかった。それよりも奇妙で、しかし非常に役立つパターンが見つかった。プランナーAIは、常に同じ3つの構造的な間違いを繰り返していたのだ。

一つ目は「未確認の依存関係」だ。これは、あるタスクを実行するために「特定の条件が満たされている必要がある」と計画で宣言されているにもかかわらず、その条件を実際に満たすための前のタスクが計画に含まれていない、あるいはそれが確認されていないケースを指す。例えば、サーバーのトラフィックを100%切り替える計画で、「10%と50%のトラフィック段階が正常であることを確認してから」という条件があるのに、その確認作業が計画に入っていなかったような状況だ。

二つ目は「安全でない順序」だ。これは、タスクの実行順序が間違っており、前提条件が満たされる前に、それを必要とするタスクが実行されてしまうケースだ。例えば、新しいデータベースのインデックスを構築する計画で、「インデックスの品質が検証されるまでデータ投入はできない」というルールがあるのに、品質検証よりも先にデータを投入してしまう、といった状況だ。

三つ目は「不十分なロールバック」だ。これは、システムに大きな影響を与える可能性のあるタスクに対して、もし問題が発生した場合に元に戻すための「ロールバック」手順が、実際には不完全で効果がないケースを指す。例えば、データベースを分割する際、「デュアルライト設定」を行うタスクで、問題発生時のロールバックが「シングルライトモードに戻すだけ」とされている状況だ。デュアルライト中に発生した可能性のあるデータの一貫性の問題に対処できなければ、ロールバックしてもシステムの状態は完全に元に戻らず、データ不整合が残ってしまう。

これらの3つの間違い、「未確認の依存関係」「安全でない順序」「不十分なロールバック」は、テストで検出された132の具体的な問題のうち、実に121件もの主要な原因だった。これらは、複数ステップにわたる計画を立てる際に、特に注意すべき構造的な欠陥と言える。

この問題の根源を探るため、エンジニアはGPT-4oのような高性能なAIモデルをプランナーやクリティックとして試した。しかし結果は同じだった。高性能なAIはより流暢な言葉で計画を提示したが、根本的な構造上の間違いは変わらなかった。この経験から、問題はモデルの知能の大きさではなく、計画の構造を理解し、その整合性を保つ能力にあるという重要な洞察が得られた。AIが言葉を生成する能力と、論理的な構造を構築する能力は別物なのだ。

また、プランナーAIが自分の間違いを修正しようとする「リビジョンループ」も、構造的な問題の解決には至らなかった。プランナーは、クリティックが指摘した一つの問題を修正しても、別の問題を新たに生み出したり、根本的な依存関係のギャップを埋められないまま、意味のある修正を加えられなくなる傾向が見られた。結果として、システムは早々に人間の介入を求める形になった。このことから、構造的な問題をプロンプトだけで解決することはできない現実が浮き彫りになった。

では、これらの構造的な問題をどう解決したのか。その答えは、AIの能力向上ではなく、決定論的なコードによる厳格な検証と自動修復だった。最も効果的だったのは「前提条件クローザー」と呼ばれる仕組みだ。これは、プランナーの計画作成後、クリティックのレビュー前に動作する。すべてのタスクの前提条件が、それ以前のタスクによって満たされていることを厳密にチェックし、もし満たされていなければブロックする。この仕組みだけで、検出された問題の約半分を、AIモデルを一度も呼び出すことなく排除できた。

さらに、残りの問題に対処するために、「トポロジカル自動修復」と「振動検出」という二つの決定論的なメカニズムが導入された。トポロジカル自動修復は、タスクの順序を自動的に並べ替え、前提条件が満たされるようにする。これは、循環する依存関係（タスクAがBに依存し、BがAに依存するような状況）がない限り、常に正しい順序を見つけ出す。振動検出は、プランナーAIが同じような修正を繰り返して堂々巡りになるのを検知し、早期にループを終了させて人間の介入を促す。これらの修正はすべて、AIモデルのアップグレードではなく、純粋なコードによって実装された。

システムは進化するにつれてその役割も変化した。最初はバグを発見する診断ツールとして機能したが、決定論的なゲートや自動修復が導入されると、バグが入り込まないことを証明する回帰テストゲートとしての役割を果たすようになった。つまり、コードレビューの段階で多くのバグが発見・修正され、AIを用いたテストは、それらの修正が新たな問題を引き起こしていないことを検証する最終防衛ラインとなったのだ。わずか0.49ドルで170もの目標を検証できるこのシステムは、開発者の貴重な時間を節約し、システムの品質と安全性を大幅に向上させた。

興味深いことに、クリティックAIは非常に「非決定論的」だった。同じ入力に対して、毎回異なる評価や説明をすることがあった。しかし、これはシステムの安全性には影響しなかった。なぜなら、必須の安全チェックはすべて決定論的なゲートが担っていたからだ。クリティックAIは、あくまで追加の知見を提供したり、人間が見落としがちな側面を指摘したりする役割であり、ゲートが検出するべき必須の問題を見逃すことはなかった。システムの安全性は、AIの信頼性ではなく、外部の厳格なコードによって保証されるという原則がここでも確認された。

この研究結果は、他の先行研究とも一致する。LLMは個々の行動を局所的に評価する傾向があり、未来の結果を予測して長期的な計画を立てるのが苦手だという共通の知見がある。そのため、LLM単独に頼るのではなく、LLMと決定論的な検証、そして古典的な計画アルゴリズムを組み合わせた「ハイブリッド」なアプローチが、これからの主流になるだろう。

この経験から得られる教訓は、AIを使って複雑な計画を立てるシステムを構築する場合、以下の点に留意すべきだということだ。まず、少数のデモ目標だけでなく、実際の多様なシナリオを想定した大量の目標でテストし、AIが犯す間違いのパターンを特定することが重要だ。次に、AIモデルのサイズを大きくしても、構造的な問題は解決しないことを理解し、問題の種類に応じて適切な決定論的な修正を加えるべきだ。AIの自己修正能力は有用だが、構造的な問題に対する万能薬ではない。そして何よりも、AIシステムの安全性は、AI自身に任せるのではなく、厳格なコードによる決定論的なゲートによって確保するべきだ。

この研究は、AIが完璧な計画を立てるという幻想を打ち破り、その限界を明確にした一方で、人間とAIが協力することで、より堅牢で安全なシステムを構築できる可能性を示している。AIは強力なツールだが、その能力を引き出し、弱点を補うためには、人間の知恵と経験に基づいた厳格なルールと仕組みが不可欠だ。