【要約】LLMが書いたタスク分解は、誰が検証しているのか [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
AIエージェントが大規模タスクを分解して並列実行する際、その分解の正当性を誰が保証するかという課題がある。多くのシステムではLLM自身がレビューを行っているが、以下のリスクを孕む。
- ・LLMの出力は同じ分布からサンプリングされるため、相関した誤りを見逃す。
- ・タスク間の暗黙的な依存関係（ファイルの競合）をLLMが把握しきれない。
- ・LLMの「申告（計画）」と「実挙動」が乖離した場合、実行時エラーやデータ破損を招く。
// Approach
開発者はOrchestuneにおいて、LLMの自己申告に依存しすぎない3層の検証アーキテクチャを構築した。これにより、不確実な生成物に対して決定論的な制御を適用する。
- ・層1（形式強制）: LLMの出力を機械可読なスキーマに落とし込み、footprint（操作対象ファイル）を明示させる。
- ・層2（事前検証）: 実行前にプログラムでDAGを検証する。footprintの重なりを「加重 Otsuka-Ochiai 係数」で測定し、暗黙の依存関係を自動で直列化する。
- ・層3（実行時検証）: エージェントの実際のファイル操作と宣言を突き合わせる。乖離があればDAGを再計算し、必要に応じてタスクを強制的に直列実行へ切り替える。
// Result
開発者は、LLMの不確実性を決定論的な制御で補完する仕組みを実現した。これにより、エージェントの暴走を防ぐための以下の成果を得ている。
- ・「再現性」「監査可能性」「実行停止理由の明確化」という、LLM単体では不可能な3要素を確保した。
- ・LLMの申告が誤っていても、実行時の挙動に基づいて安全側に倒す制御が可能になった。
- ・Claude Code等のツールと連携する、個人・少人数チーム向けのオーケストレータとしての基盤を構築した。
Senior Engineer Insight
> LLMの出力を「確率的な生成物」として扱い、その不確実性を「決定論的なシステム」で包み込む設計思想は極めて実戦的だ。特に層3の「実挙動との突き合わせ」は、エージェントの暴走を防ぐ防波堤として機能する。ただし、Otsuka-Ochiai係数の閾値設定などのヒューリスティックな部分は、運用フェーズでのチューニングが必要になるだろう。スケーラビリティと安全性のトレードオフを、決定論的なフォールバックで解決しようとする姿勢は高く評価できる。