新しいAIエージェントのプリミティブ: ポリシーには独自の言語が必要な理由(YAMLとRegoが抱える限界)

Dev.to / 2026/3/23

💬 オピニオンDeveloper Stack & InfrastructureIdeas & Deep Analysis

要点

  • AIエージェントは現在、資金の移動やインフラの運用といった実際のアクションを実行しており、堅牢なガバナンスが不可欠になっている。
  • YAMLポリシーは拘束力のある契約ではない。予算、フェーズ、委任といった強制力を持つ概念が欠けており、ポリシーが拡大すると維持不能になる可能性がある。
  • Regoは強力だがエージェントネイティブではなく、新しいロジックが必要となり、予算・委任を追加し、必須の拒否ルールを設けると、複雑さが増し、コンパイル時の安全性が制限される可能性がある。
  • 本稿では、AIエージェントのガバナンス専用に設計されたドメイン特化言語であるFPL(Faramesh Policy Language)を紹介し、エージェントの挙動を統治するためのエージェントプリミティブと形式的意味論を提供する。
  • FPLはエージェントスタックにおける新しいプリミティブとして位置づけられ、エージェントポリシーに対するYAMLとRegoの限界を解決する。

AIエージェントはもはや実験ではありません。彼らはコードを書き、お金を動かし、インフラを運営しています。しかし、彼らが自律性を獲得するにつれて、1つの質問が繰り返し浮かび上がります:彼らが何をできるかを安全に制御するにはどうすればよいのでしょうか?

ほとんどのチームはシステムプロンプトとYAML設定から始めます。一部はOPA/RegoやCedarのような汎用ポリシーエンジンに移行します。しかし、どちらのアプローチもエージェントのために設計されたものではありません。YAMLは予算、フェーズ、委任のようなネイティブな概念を欠いています。Regoは強力ですが汎用的で、「deny」をランタイムの後付けとして扱います。

読んでくれてありがとう、アムジャド!新しい投稿を受け取るために無料で購読し、私の仕事をサポートしてください。

だからこそ、私たちはFPL(Faramesh Policy Language)を構築しました。これはAIエージェントのガバナンスのために特別に設計されたドメイン固有言語です。これは再利用された設定形式ではありません。エージェントスタックのための新しいプリミティブです。

では、3つのアプローチが実際のエージェントポリシーをどのように扱うかを比較してみましょう。

問題:YAMLは契約ではなく慣習

式評価を伴うYAMLの典型的なエージェントポリシーは次のようになります(省略):

この簡略化されたバージョンでも、予算、フェーズ、委任のようなエージェント特有の概念は単なる慣習です。言語によって強制されるものではありません。後のルールが偶然にdenyを上書きしないという保証はありません。そして、ポリシーが増えるにつれて、YAMLはメンテナンス不可能になります。

Rego(OPA)は強力だがエージェントネイティブではない

Regoはインフラストラクチャの認可のために設計された汎用ポリシー言語です。表現力がありますが、シンプルなエージェントポリシーを書くには新しい論理言語を理解する必要があります:

今、予算、フェーズ、委任、上書きできない必須のdenyを追加します。結果として数百行になり、複雑なルールの順序が必要になり、コンパイル時の安全性がなくなります。Regoにはエージェントのプリミティブが組み込まれていないため、手動でエンコードする必要があります。

FPL:エージェントのためにゼロから構築

FPLはエージェントガバナンスを簡潔で読みやすく、安全にする宣言型言語です。こちらがFPLでの同じポリシーです:

25行。すべてのプリミティブ—予算、フェーズ、defer、deny!—は第一級の構造であり、慣習ではありません。

deny! – コンパイル時の必須deny

これはゲームチェンジャーです。FPLでは、deny!はコンパイル時の制約です。位置や優先度に関係なく、他のルールによって上書きされることはありません。RegoやYAMLベースのシステムでは、「deny」は単なるランタイムの決定です—後で何かを許可してしまう可能性があります。FPLはそのクラスのエラーを排除します。

自然言語コンパイル + バックテスト あなたはポリシーを平易な英語で書くことができます:

`#bash

faramesh policy compile “すべてのシェルコマンドをdenyし、$500を超える返金を財務にdeferする”
`
CLIはFPLを生成し、それを検証し、アクティベーション前に実際の決定記録に対してバックテストします。ポリシーが過去のエージェントの行動に対して何をしたかを正確に確認できます。推測はありません。

サイドバイサイド比較

GitOpsネイティブで拡張可能

FPLファイルはプレーンテキスト(.fpl)で、バージョン管理され、CIで検証されます。この言語には正式なEBNF文法、適合性テストスイート、エディタツールが準備中です(VS Code、JetBrains、Neovim)。YAMLと同じ内部表現にコンパイルされるため、混ぜて使うことができます。

ポリシーを次のように書くこともできます:

  • コード注釈 – @faramesh.tool(defer_above=500)
  • YAML(相互運用形式)
  • 自然言語(FPLにコンパイルされる)

なぜ今これが重要なのか

エージェントが本番環境に移行するにつれて、ポリシーはコアプリミティブとなります—エージェントのモデルやツールと同じくらい基本的です。YAMLはこれを目的としていませんでした。Regoは静的インフラのために構築されており、動的で多段階のエージェントワークフローには適していません。

FPLはAIエージェントのために特別に設計された最初の言語です。複雑さを減らし、設定エラーの全クラスを排除し、安全チームにエージェントを再構築することなくポリシーを強制する方法を提供します。

エージェントを構築しているなら、プロンプトやYAMLが機能することを期待するのをやめて、FPLを試してみてください。

始める準備はできましたか?

GitHub: https://github.com/faramesh/fpl-lang – 言語仕様、例、適合性
Docs: https://faramesh.dev/docs/fpl – 完全な言語リファレンス
ガバナンスエンジン: https://github.com/faramesh/faramesh-core