Open Policy Agent（OPA）とは？Policy as Codeを実現する汎用ポリシーエンジンを解説

Open Policy Agent（OPA、読みは「オーパ」）は、認可やガバナンスのルールをコードとして一元管理するためのオープンソースの汎用ポリシーエンジンです。ポリシー専業スタートアップのStyraが開発し、2021年（CNCF発表は2月）にCNCF（Cloud Native Computing Foundation）のGraduatedプロジェクトへ昇格しました。アプリに散らばりがちな「誰に何を許可するか」の判断をOPAへ切り出し、Regoで書いたルールに沿って許可・拒否（allow/deny）を返します。ライセンスはApache 2.0、最新版はv1.18.2（2026年7月時点）です。本記事ではOPAの定義から仕組み、Kubernetesやインフラ構成コード（IaC）での使いどころ、他手法との違い、導入前の判断ポイントまでを整理します。

まとめ：OPAの要点

• 正体：Styra発・CNCF Graduated（2021年）の汎用ポリシーエンジン。読みは「オーパ」、Apache 2.0ライセンスのOSS。
• 役割：認可・ガバナンスの判断ロジックをアプリから分離し、Policy as Code（ポリシーのコード化）で一元管理する。
• 仕組み：JSON入力を受け取り、Rego言語のポリシーで評価し、JSON（allow/denyなど）を返すだけのシンプルな構造。特定領域に依存しない。
• 主な用途：Kubernetesのアドミッション制御（Gatekeeper）、Terraform等IaCのデプロイ前チェック、APIやマイクロサービスの認可。
• 向かない場面：Kubernetesの制約だけならGatekeeper単体で足りる。Regoの学習コストと評価パフォーマンスの設計は事前に見積もる必要がある。

OPAの定義と生まれた背景

汎用ポリシーエンジンとしてのOPA

OPAは「ポリシー決定」だけを担う独立したコンポーネントです。特定のアプリケーションやクラウドに縛られず、入力データとポリシーを与えれば判定結果を返す点が「汎用（general-purpose）」と呼ばれる理由です。判断の仕組みをサービス本体から切り離すため、開発者はビジネスロジックに集中し、ポリシーはセキュリティ担当が別ファイルで管理する、といった分業が成立します。

認可ロジックの散在という課題

マイクロサービス化が進むと、「このユーザーはこの操作を実行してよいか」という認可判定が各サービスのコードに個別実装され、ルールの重複や食い違いが生まれます。OPAはこの判定を一箇所へ集約し、ルール変更を1つのポリシーファイルの修正で全体に反映できるようにします。ロールに基づく制御そのものについてはRBAC（ロールベースアクセス制御）の仕組みと導入判断も参照してください。OPAはRBACもより柔軟な属性ベース（ABAC）もRegoで表現できます。

Policy as Codeとの関係

Policy as Codeは、これまで文書や手作業で運用していたルールをコードとして記述し、バージョン管理・レビュー・自動テストの対象にする考え方です。OPAはこの考え方を実装する代表的なエンジンで、ポリシーをGitで履歴管理し、CI/CDで検証してからデプロイする運用が可能になります。

OPAの仕組み：入力・Rego・出力

評価の基本フロー

OPAの動作は3ステップに集約されます。(1) 判定対象の情報をJSON形式で受け取る（入力データ）、(2) Regoで書かれたポリシーに照らして評価する、(3) 結果をJSONで返す。結果は真偽値のallowだけでなく、違反理由のメッセージや任意の構造化データも返せます。この単純さが、Web APIからKubernetes、CI/CDまで同じエンジンを使い回せる理由です。

Regoによるポリシー記述

ポリシーはRegoという宣言型言語で書きます。「管理者のGETリクエストだけ許可する」ルールは次のように表現します（OPA 1.0以降のRego v1構文）。

package authz

default allow := false

allow if {
    input.method == "GET"
    input.user.role == "admin"
}

default allow := falseで既定を拒否にし、条件を満たしたときだけ許可する「デフォルト拒否」が基本形です。構文の詳細やv0からの移行、テストの書き方はRegoの書き方とOPA 1.0（Rego v1）への移行ガイドで解説しています。

OPAの提供形態

OPAは用途に応じて複数の形態で組み込めます。単体バイナリのopaコマンドでの検証、常駐サーバーとしてのREST API、Goアプリへ直接組み込むライブラリ（SDK）の3つが代表です。サーバーとして起動すると既定でポート8181を待ち受け、他サービスはHTTPで判定を問い合わせます。

OPAの主なユースケース

Kubernetesのアドミッション制御（Gatekeeper）

最も普及した用途がKubernetesです。OPA Gatekeeperを導入すると、Podの作成・更新リクエストをAPIサーバーが受け付ける段階（Validating Admission Webhook）でポリシー評価が走り、ルール違反のマニフェストを拒否できます。「許可されたレジストリのイメージだけ使う」「必須ラベルの無いリソースを弾く」といった制約を、ConstraintTemplate（Regoで判定を記述）とConstraint（パラメータを指定）の二層で宣言的に定義します。現行はGatekeeper v3系が標準で、Regoを直接書かずに再利用可能な制約として配布できる点が、生のOPAとの違いです。Kubernetes自体の全体像はKubernetes（クバネティス）とは？仕組みとDockerとの違いを参照してください。

IaC（Terraform等）のデプロイ前チェック

Terraformなどで定義したインフラ構成コードを、適用前にスキャンして危険な設定を止める用途にもOPAが使えます。OPAプロジェクトのconftestを使うと、terraform show -jsonで書き出したplanのJSONを入力に「パブリック公開されたS3バケットを禁止」「暗号化されていないボリュームを拒否」といったルールを評価できます。設定ミスをレビュー段階で検出できるため、Terraformを一貫したスタイルで運用するTerraformコードのスタイルガイドと組み合わせると、書式と安全性の両面をコードで担保できます。

APIとマイクロサービスの認可

API GatewayやEnvoyのようなプロキシと連携し、リクエストごとに「この利用者はこのエンドポイントを呼べるか」をOPAへ問い合わせる構成です。認可ロジックを各サービスから追い出し、サイドカーのOPAに一元化することで、権限ルールの変更をサービス再デプロイなしに反映できます。

OPA導入前に押さえる判断ポイント

OPAは万能ではありません。導入判断で見落としがちな点を挙げます。

• Kubernetesの制約だけならGatekeeperで十分：クラスタ内のマニフェスト検査が目的なら、Gatekeeperの既存制約ライブラリで完結することが多く、OPAサーバーを自前運用する必要はありません。汎用エンジンとして複数システムを横断したいときにOPA本体の価値が出ます。
• Regoの学習コストを見積もる：Regoは一般的な手続き型言語と発想が異なる宣言型で、集合やルールの評価順に慣れるまで時間がかかります。少人数チームでポリシーが単純なら、フレームワーク標準の認可機能で足りる場合もあります。
• 評価パフォーマンスと配布設計：リクエストごとにOPAへ問い合わせるならレイテンシが加わります。ポリシーとデータはbundle機能で配布し、判定ログはdecision logで監査する、といった運用設計を最初に決めておくべきです。大量データを都度読み込む設計は避けます。

OPAと他の認可手法の違い

「OPAでなければ実現できないか」を判断するため、近い選択肢と比較します。

クラウドやKubernetesの標準機能で要件が閉じるなら、まずはそちらを使うのが素直です。複数の実行環境にまたがって同じルールを一貫適用したい、認可ロジックを実装から切り離してテスト可能にしたい、という要求が出たときにOPAが効いてきます。

よくある質問

OPAの読み方は何ですか？

「オーパ」または「オー・ピー・エー」と読みます。Open Policy Agentの頭文字です。なお同じ表記の商業施設「OPA（オーパ）」とは無関係です。

OPAとGatekeeperの違いは何ですか？

OPAはあらゆるシステムで使える汎用エンジン、GatekeeperはそのOPAをKubernetes専用に組み込んだアドミッションコントローラーです。GatekeeperはRegoを制約テンプレートとして配布でき、Kubernetes運用者がポリシーを再利用しやすくなっています。

OPAは無料で使えますか？ライセンスは？

はい。OPAはApache 2.0ライセンスのオープンソースで、商用利用を含め無料で使えます。開発元のStyraは、OPAを大規模運用するための商用管理プレーン（Styra DAS）を別途提供しています。

OPAを使うにはRegoを覚える必要がありますか？

ポリシーを自分で書くならRegoの習得が必要です。ただしKubernetes用途ではGatekeeperの既成の制約を流用すればRegoをほとんど書かずに始められます。Regoの基本構文はRegoの書き方ガイドで確認できます。

OPAとRBACはどう使い分けますか？

RBACは「ロール（役割）に権限を割り当てる」認可モデルの考え方で、OPAはそれを含む様々なモデルを実装するエンジンです。単純なロール管理ならRBACの標準機能で足り、ロールに加えて時間帯・属性・外部データを条件にした細かい認可が必要になったとき、OPAでRegoに落とし込みます。

関連記事

• Regoとは？OPA 1.0（Rego v1）の書き方とv0コード移行・テストの実装ガイド
• RBACとは？ロールベースアクセス制御の仕組みと導入判断を実装視点で解説
• Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説
• Terraformコードを一貫したスタイルで書くためのガイドライン