この論文は、シンガポール経営大学の研究者らによって第 48 回 IEEE/ACM 国際ソフトウェアエンジニアリング会議（ICSE 2026）で発表されたもので、LLM エージェントの実行中に制約を記述し強制するためのドメイン固有言語である AgentSpec を提案する。著者らは、既存の対策では不十分だと論じる。ToolEmu のような LLM によるリスク評価はリスクを特定できるものの解釈可能性に欠け、強制のための仕組みを持たない。ルールベースの安全策は硬直的すぎるか、エージェントのアーキテクチャをまたいで汎化しない。そしてほとんどのアプローチは、エージェントが実行中に行うことを制約するのではなく、実行前にリスクを評価する。AgentSpec では、ユーザーがトリガーとなるイベント、述語チェック、強制アクションからなるルールを記述でき、エージェントの意思決定ループに割り込んでそれらを適用する。
このフレームワークは LangChain 上に実装され、異なるドメインをカバーするよう選ばれた 3 つのエージェントで評価されている。CodeAct フレームワーク上に構築されたコードエージェント、ロボットアームを制御する身体性エージェント、そして Apollo 自動運転スタック上に構築された自動運転エージェントであり、それぞれ RedCode-Exec、SafeAgentBench、FixDrive のデータセットが用いられている。論文ではさらに、LLM（OpenAI o1）が AgentSpec のルールを自動生成できるかどうかを調べ、フレームワークの実行時オーバーヘッドを測定している。
要点
- 著者らは AgentSpec を、彼らの知る限り、LLM エージェントに対してカスタマイズ可能な安全制約を実行時に体系的に強制する最初のフレームワークであると述べている。
- ルールは、トリガー（状態の変化、アクション前のイベント、またはエージェントの終了）、チェックすべき述語の連言、そして 1 つ以上の強制からなる。あらかじめ定義された強制は、ユーザーによる確認、LLM による自己検査、事前定義されたアクションの呼び出し、停止である。
- LangChain との統合は、エージェントの反復ステップを 3 つの意思決定ポイント（アクションが実行される前、アクションが観察結果を生成した後、エージェントがタスクを完了したとき）でフックし、エージェントのコアロジックは変更しない。ルールは ANTLR4 でパースされる。
- 著者らはこの設計がフレームワーク非依存であると述べ、Microsoft の AutoGen や Apollo 自動運転スタックへの適用方法も説明しているが、主要な統合先は LangChain である。
- RedCode-Exec において、論文は AgentSpec が 90% を超えるケースでリスクのあるコード実行を検出して阻止したと報告している。コードエージェントは 25 のリスクカテゴリのうち 24 でリスクのある Python の実行を試みた。
- RedCode の 2 つのカテゴリ（「default ケースの欠落」と「連想リスト内のキーの重複」）では、フラグが立てられたプログラムはなかった。著者らは手作業での検査に基づき、エージェントは Python を呼び出したものの、実際にはリスクのある指示に従わなかったためだと説明している。
- 身体性エージェントでは、AgentSpec を有効にすると 10 の危険カテゴリすべてで危害につながるタスクの割合が 0% に低下した一方、安全なタスクの成功率は 58.62% から 54.26% へとわずかに低下しただけだった。
- 自動運転では、FixDrive から採用したルールが、テストされた法規違反シナリオ全体で 100% の遵守を達成した。
- OpenAI o1 が few-shot の例を用いて生成したルールは、リスクのあるコードのケースの 87.26% を強制し、身体性エージェントでは適合率 95.56%、再現率 70.96% に達した。自動運転向けに zero-shot で生成したルールは、8 つのシナリオのうち 5 つで法規違反を防いだ。
- 著者らは LLM が生成したルールの失敗の原因を、提示された例への過剰適合、複雑なオブジェクトの特性を認識できないこと、曖昧な要件に対してルールが硬直的すぎることに帰している。ある生成ルールは、観葉植物への水やりも含め、注ぐ行為を全面的に禁止していた。
- 測定されたオーバーヘッドはミリ秒単位である。ルールのパースに約 1.42 ms、述語の評価に 2.83 ms（コード）または 1.11 ms（身体性）であり、エージェントの平均実行時間 25.4 s および 9.82 s と比べて小さい。
補足
論文は AgentSpec を、対話レベルで自然言語の制約を適用するものとして説明される NVIDIA の NeMo や、安全制約の解釈と適用を LLM に依存する GuardAgent と対比している。AgentSpec は代わりに、強制をモデルの外部に置き、開発者が定義するものとしており、著者らはこれにより検証可能性と監査可能性が向上すると論じている。これは決定論的で実行前に働くスタイルの ガードレール の一例である。
制限として、著者らは AgentSpec が離散的なチェックポイントで決定論的に強制を行い、一連のアクションの長期的な帰結については推論しないことを挙げ、将来の課題として確率的な強制（たとえば、過去のエージェントのインタラクションから離散時間マルコフ連鎖を学習すること）を提案している。妥当性への脅威としては、ルールがデータセットに過剰適合するリスク（各リスクデータセットの 10% をルール開発に、残りをテストに用いることで軽減した）と、ユーザー確認の結果の判定に人間が関与していることを挙げている。
この論文は arXiv プレプリント（arXiv:2503.18666）としても公開されており、2025 年 3 月 24 日に最初に投稿され、2025 年 7 月 31 日に最終改訂（バージョン 3）されている。掲載情報は Proc. ICSE’26、2938–2950 ページ（ACM、2026 年）である。