カタログデータを動的なポリシーソースとしてOPAと連携させる

はじめに

これまでの5本の記事で、カタログ設計、MCP実装、TechDocs構造化、Scaffolder編、GitHub操作の権限設計と扱ってきました。この中で繰り返し「ガードレール」「権限の絞り込み」という言葉を使ってきましたが、その実体、つまりどこでどう判断を下すのかという実装面には、まだ踏み込んでいませんでした。

今回は、OPA(Open Policy Agent)をBackstageのカタログデータと連携させ、動的なポリシーソースとして使う設計を扱います。これまで個別に扱ってきたガードレール(読み書き分離、承認フロー、GitHub権限の絞り込み)を、それぞれのコードに埋め込むのではなく、OPAという一元的なポリシーエンジンに集約するとどうなるか、という話です。

OPAとは何か

OPA(Open Policy Agent)は、スタック全体にわたって統一的でコンテキストを踏まえたポリシー実施を可能にする、オープンソースの汎用ポリシーエンジンです。サービスは、ポリシー判断が必要な場面でOPAにクエリを実行する形で統合します。OPAにポリシー判断を問い合わせると、与えられたルールとデータをもとにルールを評価し、その結果を回答としてクエリの結果に返します。ポリシーのロジックと、判断対象となるシステムそのものを切り離して管理できる点が特徴です。

ポイントは、「何を許可し、何を拒否するか」というルールを、個々のアプリケーションのコードから切り離して、OPAという一箇所にまとめられることです。ルールを変更したいときも、アプリケーション自体を作り直す必要はありません。

Backstage×OPAの既存の統合パターン

実は、BackstageとOPAを組み合わせる仕組みはすでに存在しています。ポリシーは.regoファイルとして管理され、稼働中のOPAサーバーによって評価されており、Backstageを再デプロイすることなく更新できます。既存の統合は、大きく3つの機能に整理できます。

Permission Frameworkの委譲
BackstageにはPermission Frameworkという、誰が何を見られる・操作できるかを制御する仕組みが備わっています。この判断のすべてをOPAに委譲するプラグインが提供されており、Backstage側は「この操作を許可してよいか」をOPAに問い合わせるだけになります。

カタログのエンティティ検証
カタログにエンティティが取り込まれる際、そのメタデータをOPAのポリシーで検証し、検証結果をカタログ処理の中でannotationとして追加するプラグインもあります。「このエンティティは組織の標準を満たしているか」を、取り込みの時点でチェックできる仕組みです。

UI側の表示制御
OPAの判定結果に応じて、UI上の要素を表示・非表示にするReactコンポーネントやフックも用意されています。ポリシー判断がバックエンドだけでなく、画面表示にも一貫して反映される構成です。

これらはもともと人間のユーザーに対するアクセス制御・表示制御を目的とした仕組みですが、この土台をAIエージェントのガードレールにも転用できます。

AIエージェントのガードレールとしての応用

AIエージェント全般のガバナンスの文脈では、ツール呼び出しの層が、あらゆる操作の前にこのポリシーエンジンに問い合わせ、すべての操作が明示的に許可されていることを確認する、という設計パターンが紹介されています。OPAのようなポリシーエンジンは、この役割を担う代表的な選択肢の一つです。

この発想はAIエージェント特有のリスクにも対応しています。100人以上の専門家によるレビューを経たOWASP Top 10 for Agentic Applications(2026年)は、Agent Goal Hijacking(エージェントの目的が意図せず乗っ取られること)を最大のリスクと位置づけ、エージェントに不要な能力を持たせないことを重視しています。また、NIST(米国立標準技術研究所)が2026年2月に発表したAI Agent Standards Initiativeも、エージェント型アーキテクチャにおける実施可能なセキュリティ・アイデンティティ標準の必要性を強調しています。

これを前回・前々回の文脈に当てはめると、次のようになります。前回のGitHub操作編で扱った「本番リポジトリへの書き込みは承認必須」、前々回のScaffolder編で扱った「本番リソースに関わるテンプレートは人間の承認を必須にする」といったルールは、これまで個々の実装判断として扱ってきました。これらを、MCP経由でツールが呼び出される直前にOPAへ問い合わせる形に集約すると、ルールの変更や追加が、コードの変更なしにポリシーファイルの更新だけで完結するようになります。

カタログのメタデータをポリシー入力として使う設計

ここが今回の中心的な論点です。OPAに判断させる際の入力として、カタログが持っているメタデータをそのまま使える点が、Backstageと組み合わせる大きな利点です。

オーナー不在のサービスへの操作を拒否する
カタログのエンティティには、通常オーナー情報が登録されています。このオーナー情報が空、あるいは無効な値になっているサービスに対しては、AIエージェントからの書き込み操作(Scaffolderの実行、カタログの更新など)を拒否する、というルールが考えられます。「誰も責任を持っていないサービスに、エージェントが変更を加えてしまう」という事態を防げます。

ライフサイクルに応じて承認要否を切り替える
カタログのエンティティには、experimental・production といったライフサイクルの情報を持たせられます。この情報をOPAへの入力に含めることで、「productionのサービスに対する書き込み操作は必ず人間の承認を挟む」「experimentalのサービスであれば、エージェントの自律的な実行を許可する」といった、サービスの成熟度に応じた出し分けが可能になります。

annotation namespaceの情報をそのまま条件にする
以前のカタログ設計編で扱った、AIエージェント向けのannotation namespace(どのエージェントからの参照を許可するか、どこまでのツール権限を許可するか)も、そのままOPAへの入力にできます。カタログ側で「このエンティティはエージェントXからの読み取りのみ許可」と定義しておけば、OPAはその情報を読み取って判断するだけで済み、個々のツールの実装側でこの条件分岐を書く必要がなくなります。

このように、カタログはもともと「組織の状態を表現するデータ」として整備されているため、これをそのままポリシー判断の材料として再利用できる、という点がBackstage×OPAの組み合わせの強みです。

これまでの記事との接続:ガードレールの一元化

改めてこれまでの記事を振り返ると、次のように整理できます。

• MCP実装編で扱った「読み取りツールと書き込みツールの権限分離」
• Scaffolder編で扱った「本番リソースに関わるテンプレートの承認フロー」
• GitHub操作編で扱った「GitHub Appのスコープ絞り込み、ユーザー単位の権限分離」

これらは、これまでの記事ではそれぞれの機能ごとに個別の設計判断として扱ってきました。OPAを間に挟むことで、こうした判断ロジックを一箇所に集約し、カタログのメタデータを共通の入力として参照する構成に整理し直せます。ポリシーの変更・追加が、個々のプラグインやアクションの実装を触らずに行えるようになる、という点が、この一元化の主なメリットです。

とはいえ、2026年時点でAIエージェントのガードレールを単一の仕組みだけで完結させるのは現実的ではありません。実務上は、ポリシーエンジン(OPAなど)、IaCのガバナンス層、ランタイムでのAIガード、そしてエージェントにクラウドの認証情報そのものではなく制限されたAPIだけを渡す構成、という複数の層を組み合わせるのが一般的だとされています。OPAはこの中の「ポリシー判断」を担う一つの層であり、それだけですべてのリスクをカバーするものではない、という位置づけで捉えておくのが妥当です。

制約・注意点

• 本記事で紹介したBackstage×OPAの統合プラグインは、もともと人間のユーザー向けのアクセス制御・表示制御を主眼に作られたものであり、AIエージェント向けの活用は、その応用として今回整理した内容です。
• Regoによる具体的なポリシー記述、OPAサーバー自体の運用(可用性、更新の反映方法など)については、本記事では扱っていません。
• ガードレールをOPAに一元化すること自体が、AIエージェントのリスクをすべて解消するわけではなく、他の層(認証、レート制限、監査ログなど、これまでの記事で扱ってきた内容)と組み合わせて初めて機能します。

まとめ

• OPAは、ポリシーロジックを個々のアプリケーションのコードから切り離し、一元的に管理できる汎用のポリシーエンジンです。
• Backstageには、Permission Frameworkの委譲、カタログエンティティの検証、UI表示制御という3つの既存の統合パターンがすでにあります。
• この土台を、AIエージェントがツールを呼び出す直前にOPAへ問い合わせる形に応用することで、これまでの記事で個別に扱ってきたガードレールを一元化できます。
• カタログが持つオーナー情報、ライフサイクル、annotation namespaceといったメタデータは、そのままOPAへの入力として再利用できます。
• OPAはガードレールの一つの層であり、これまでの記事で扱ってきた認証・レート制限・監査ログといった他の仕組みと組み合わせて初めて機能します。

参考リンク

• Parsifal-M「backstage-opa-plugins」(GitHub)
• CodiLime「Why Open Policy Agent is the Missing Guardrail for Your AI Agents」
• Qovery Blog「Which Platforms Enforce Policy Guardrails When AI Agents Provision Cloud Infrastructure?」
• Infracost「Open Policy Agent (OPA)」

注意事項​

　本ブログに掲載している内容は、私個人の見解であり、​
　所属する組織の立場や戦略、意見を代表するものではありません。​
　あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。