필사 모드: OPAは今、誰がメンテナンスしているのか — StyraチームのApple合流、その後11か月の検証可能な記録

• はじめに — 「AppleがOPAを買収した」はどこまで本当か
• 2025年8月20日、発表の正確な内容
• それで買収だったのか — 確認できることとできないこと
• その後11か月、リリースは止まらなかった
• Styraツール群のそれぞれの運命
• ガバナンスの算数 — メンテナー全員が一社所属になると
• open coreユーザーがこの件から点検すべきこと
• では、あなたは何をすべきか
• おわりに
• 参考資料

はじめに — 「AppleがOPAを買収した」はどこまで本当か

2025年8月末、認可(authorization)スタックにOPAを組み込んでいたチームの間で噂が流れました。「AppleがStyraを買収した」「OPAはAppleのものになった」。ポリシーエンジンは一度導入するとインフラの奥深くに組み込まれるものなので、こうした噂は軽く聞き流せません。ですが、これらの文はどれも正確ではありません — そして、どこがどう不正確なのかは実務者にとって重要です。

本稿の事実関係はすべて一次情報で確認しています。OPA公式ブログの発表原文、GitHub APIで照会したリリース・コミット・リポジトリのメタデータ、リポジトリのMAINTAINERS.mdとGOVERNANCE.mdの原文、そして公開DNSリゾルバの照会結果(2026-07-17時点)です。噂の採点から始めて、11か月が経った今OPAが実際にどんな状態にあるかまでを記録します。

2025年8月20日、発表の正確な内容

発表はAppleではなくOPAのブログから出ました。Note from Teemu, Tim, and Torin to the Open Policy Agent community — OPAを作った人々の名義の記事で、日付は2025年8月20日です。要点はこうです。

• OPAの創始者たちとStyraのチームメンバー多数がAppleに合流する。
• Appleはすでに大規模なOPAユーザーである — グローバルなクラウドサービス群の認可インフラの中核コンポーネントとして使っていると発表に明記されています。
• OPAはCNCF卒業プロジェクトのまま残り、プロジェクトのガバナンスとライセンスに変化はない。
• メンテナーのリストもそのまま維持され、変わるのはそのメンテナーたちの所属表記(StyraからAppleへ)だけである。
• StyraのGitHubにあったツール群 — 商用ディストリビューションのEOPA、OPA Control Plane、各種SDK(TypeScript、React、C#、Javaなど)、Regoリンターの Regal — は、CNCFのOPA GitHub組織へ移すコミュニティプロセスを開始する。
• ウェブサイトはCNCFとコミュニティが、Rego PlaygroundはStyraが引き続き運用する。
• 月次リリーススケジュールを維持し、2025年ロードマップ(言語拡張、型チェック、ツーリング、部分評価、パフォーマンス、決定ログ)を継続して進める。

注目すべき点が一つ。この発表のどこにも「買収」という単語はありません。会社が会社を買ったという話ではなく、人々が転職したという話です。

それで買収だったのか — 確認できることとできないこと

報道を原文で確認すると、表現はさらに明確です。Cloud Native Nowの記事は、AppleがStyra共同創業者のTim HinrichsとTorin Sandall、そしてシニアエンジニアたちを採用したが、会社やその資産を買収したわけではないと書き、これを「買収なきアクハイア」と呼びました。この件についてApple名義の別途の発表は確認されていません。

その後、Styraという会社に何が起きたかは公式文書に残っていません。ただし観測可能な事実はあります。本稿執筆時点の2026年7月17日基準で:

• styra.comは公開リゾルバ(1.1.1.1、8.8.8.8)でAレコードとNSレコードの照会がいずれもSERVFAILを返します。ドメインのウェブサイトは事実上消滅した状態です。
• github.com/StyraInc組織ページは404です。旧StyraInc/regalのようなアドレスはopen-policy-agent組織のリポジトリへリダイレクトされます。
• 会社の法的状態(清算の有無など)についての公式発表は見つかりませんでした。分からないことは分からないと書くほうが正確です。

一方、人々がApple社内でOPA関連の作業を続けていることは、公開コミット履歴で直接確認できます。たとえばopen-policy-agent/swift-opaリポジトリには、発表後も創業メンバーがApple所属のメールアドレスでコミットした記録が続いています。参考までに、このリポジトリ自体は発表より前の2025年4月に作られ、Swift OPA公開記事は2025年5月14日に公開されています — Apple側のOPA活用は8月の発表より前から進行していたという状況証拠です。

その後11か月、リリースは止まらなかった

プロジェクトが死んでいるか生きているかは、言葉ではなくリリース履歴が答えます。OPAリリース一覧から発表以降のマイナーリリースだけを抜き出すとこうなります。

合間にパッチリリースがあり、本稿執筆時点の最新はv1.18.2(2026-07-02)です。発表が約束した月次ケイデンスは文字どおり守られています。参考までに、OPA 1.0.0は2024年12月20日に出ているので、1.x時代全体がこの激変と重なっているわけですが、リリースの流れに継ぎ目は見えません。

内容もメンテナンス用のつぎはぎだけではありません。発表に書かれたロードマップ項目のうち、実際に出荷されたものがあります。

• v1.15.0 — ロガープラグインインターフェースとローテーション対応のファイルロガー。ロードマップの「ロギングをディスクへ」項目に該当します。
• v1.17.0 — future.keywords.notインポートでRegoの旧来の否定(negation)セマンティクスの問題を改善。ロードマップの言語拡張項目の一つです。
• v1.18.0 — コンテナ認識のリソース制限(GOMAXPROCSの復元、GOMEMLIMIT対応)、そしてブレーキングフィックスが一つ: アウトバウンドのUser-AgentヘッダーがRFC 9110違反だったため、Open Policy Agent/バージョンの形からOpen-Policy-Agent/バージョンの形に変わりました。この文字列を厳密にマッチさせるWAFルールやログフィルターがあれば修正が必要です。

リリースノートの貢献者リストには、Apple所属のメンテナー以外の名前も引き続き見られます。ただし「リリースが出る」ことと「プロジェクトが健全である」ことは同じ文ではない、という点は後のガバナンス節で改めて見ます。

Styraツール群のそれぞれの運命

発表が約束した移管は実際に行われました。ですが、移管されたツールのその後の軌跡はそれぞれ異なります — ここがこの件から最も学べる部分です。

Regal — 生き残ったもの。 RegoリンターRegalは、open-policy-agent組織へ移された後も着実にリリースを続けています。最新のv0.42.0は2026年7月16日 — 本稿の前日です。

OPA Control Plane — 新しく育っているもの。 opa-control-planeはGitリポジトリからポリシーバンドルをビルドし、S3、GCS、Azure Blobのようなオブジェクトストレージへデプロイする管理コンポーネントです。移管後の最初のタグv0.1.0が2025年11月18日、最新のv0.7.0が2026年6月9日です。まだ0.xであることはそのまま受け取ればよく — いままさに作られている最中です。

EOPA — 寄贈されたが止まったもの。 データヘビーなワークロード向けの商用ディストリビューションだったEOPAはオープンソースとして寄贈され、2025年8月28日のv1.43.0から11月6日のv1.45.1までリリースが続きました。そして止まりました。その後は依存関係のバンプコミットが時折あるだけで、2026年6月26日に「アーカイブ案内」コミットとともにリポジトリがアーカイブされました。READMEには、コードは自由に使ってよいという言葉とともに、メンテナンスに関心があればOPA Slackへ連絡してほしいという案内が残されています。寄贈からアーカイブまで約10か月 — 引き受け手が現れなかったということです。

それ以外。 Rego Playgroundは今日もHTTP 200で応答します(発表時点の運営主体はStyraでしたが、現在誰が運営しているかは公式文書で確認されていません)。SDK群も移管リストにありましたが、個々のリポジトリの活動水準までは本稿で検証していません。そして目立つ空白が一つ — StyraのSaaS管理プレーンだったDASは、発表のFAQリストにまったく登場しません。商用顧客にどんな案内が出たのかは、styra.comが消えた今、公開情報源から確認する方法がありません。

ガバナンスの算数 — メンテナー全員が一社所属になると

ここからが居心地の悪い部分です。本日付のMAINTAINERS.mdを読むと、opaリポジトリ領域を担当するメンテナー6名(Anders Eknert、Ash Narkar、Charlie Egan、Stephan Renatus、Tim Hinrichs、Torin Sandall)の所属が全員Appleです。Gatekeeper系統(constraints、gatekeeperなど)は事情が異なり、Google所属1名とMicrosoft所属3名が担当していて、Microsoft側の3名は2026年1月30日付で更新表記されています。

GOVERNANCE.mdは組織単位の投票(organizational voting)を規定しています — 一組織にメンテナーが何人いようと組織あたり1票で、文書が示す趣旨はどの組織も特定領域を支配できないようにすることです。ところが算数をしてみると、現在opa領域で投票権を持つ組織はApple一社です。安全装置は形式上残っていますが、その領域には牽制する相手組織がいません。

公平を期して付け加えると、この集中は新しく生まれた問題ではありません。同じ人々が昨日まではStyra所属だったので、opa領域が事実上一社に集中していたのはStyra時代も同じでした。変わったのはその会社の性格です — ポリシーエンジンを売って生計を立てる会社から、ポリシーエンジンを内部インフラとして使う会社へ。ベンダーにはオープンソースを商用製品への導線として維持する動機があり、大規模ユーザーには自社インフラの安定性のために維持する動機があります。どちらがコミュニティにとってより良い構造かは断定できず、これまでの11か月分のデータは少なくとも放置シナリオを支持していません。

最後の安全網は、プロジェクトが個人や会社ではなく財団にあるという事実そのものです。OPAは2021年2月にCNCF卒業プロジェクトになり、コードはApache-2.0です。最悪のシナリオでもフォークと承継が法的に開かれている構造です — HashiCorpのライセンス転換の際にVaultから分岐したOpenBaoがその経路の実例であり、その話はOpenBao v2.6のまとめ記事で別途扱いました。ガバナンスが財団にあったからこそOPAはフォークなしにこの激変を通過できたという点が、両者の対比で最も際立つ部分です。

open coreユーザーがこの件から点検すべきこと

EOPAの軌跡が核心の教訓です。ベンダーが消える際に商用製品をオープンソースとして解放するのは間違いなく品位ある退場ですが、オープンソース化はコードの生存を保証するだけで、製品の生存を保証するわけではありません。コードが公開されていても、メンテナンスする人が現れなければ10か月後にアーカイブされます。似た立場のツールを使っているなら、点検リストはこうなります。

• 現在使っているスタックの中で、商用専用機能に依存している部分をリストアップしてください。EOPAユーザーであれば、データフィルタリングやDB統合機能がここに該当します。
• プロジェクトの所有構造を確認してください。財団所有(CNCFなど)かベンダー単独所有かによって、ベンダー消滅シナリオの結果はまったく異なります。今回OPAが大きな問題なく通過できた一番の要因はこれです。
• MAINTAINERSファイルを実際に読んでください。メンテナーたちの所属の多様性は、公開文書で確認できるリスク指標です。
• 撤退コストを事前に計算してください。ポリシーエンジンは置き換えコストが大きい部類に入ります — ポリシー言語(Rego、Cedar、関係タプル)ごとに移植は事実上の再実装です。

では、あなたは何をすべきか

オープンソース版OPAだけを使っているチーム — 今すぐやるべきことはありません。リリースケイデンス、ガバナンス文書、ライセンスはすべて発表前と同じ状態で維持されています。ただし注視すべき指標はあります: 月次ケイデンスが維持されるか、Apple以外の所属からの貢献と新規メンテナーの獲得が生まれるか。

EOPAの機能に依存していたチーム — 決断が必要です。リポジトリはアーカイブされ、Apache-2.0なのでフォークして自分たちで維持するのは自由ですが、そのコストを負担できないなら代替への移行計画が必要です。上流のOPAがEOPAの機能をすべて吸収したわけではない点に注意してください。

Styra DASでOPAフリートを管理していたチーム — 発表はDASに言及しておらず、同じ問題領域(バンドルのビルドと配布)を扱うのは移管されたOPA Control Planeです。ただし公式に後継だと宣言した文書はなく、バージョンもまだ0.xです。検証なしに乗り換える段階ではまだありません。

新規導入を検討しているチーム — この件自体はOPAを避ける理由にはなりません。むしろ財団ガバナンスの価値が実証された事例に近いといえます。エンジン選定は依然として問題の種類が決めます — 汎用ポリシー評価(OPA)か、関係ベースの認可(Zanzibar系統)か、その比較は認可エンジン徹底比較で整理しています。Kubernetesのアドミッションポリシーが目的ならKyvernoとOPA Gatekeeperの比較も参考にしてください — 上で見たとおり、Gatekeeper領域はGoogleとMicrosoftのメンテナーが守っています。

おわりに

事実だけを残すとこうなります。買収は一度も発表されておらず、転職がありました。プロジェクトは財団にあり、だから人々の雇用主が変わってもガバナンスとリリースは続きました。商用製品はオープンソースとして寄贈されましたが、そのうちリンターは生き残り、商用ディストリビューションは10か月でアーカイブされました — オープンソース化がそのまま持続可能性を意味するわけではないことを、同じ出来事の中で同時に示した形です。

「ベンダーが消えればオープンソースプロジェクトは終わり」も誤りで、「オープンソースだから無条件に安全」も誤りです。分かれ道は所有構造とメンテナンスの動機がどこにあるかでした。あなたのスタックの中で一社にぶら下がっているコンポーネントが何か、この機会にMAINTAINERSファイルから開いてみることをお勧めします。

参考資料

• Note from Teemu, Tim, and Torin to the Open Policy Agent community (OPAブログ、2025-08-20)
• OPAリリース一覧 (GitHub)
• OPA MAINTAINERS.md (原文) / GOVERNANCE.md (原文)
• open-policy-agent/eopa — 寄贈後にアーカイブされたリポジトリ
• Regalリリース / OPA Control Planeリリース
• OPA v1.17.0リリースノート — future.keywords.not / v1.18.0リリースノート — User-Agentブレーキングフィックス
• CNCF、OPA卒業発表 (2021-02-04)
• Apple Buys Styra Brains, OPA Remains Open (Cloud Native Now)
• Introducing Swift OPA (OPAブログ、2025-05-14)
• 認可エンジン徹底比較 — FGA/Zanzibar系統比較 (関連記事)
• OpenBao v2.6 — Vaultから分岐した後 (関連記事)