「Application Model」の過去と現在 ーOAMからPlatform Engineeringへ

はじめに

Kubernetesのマニフェストを書いたことがあるエンジニアなら「これは本当に開発者が書くべきものなのか」と1度は思ったことがあるはずです。Deployment、Service、HPA、PDB、NetworkPolicy。1つのアプリをプロダクションに載せるために必要な設定の総量は膨大で、Kubernetes利用者にとっての認知負荷は無視できません。

「Application Model」は、この複雑さを抽象化する試みとして生まれました。しかし2019年の登場から7年、この概念は業界の主流になるどころか、ほとんど言及されなくなっています。一方で、同じ時期に「Platform Engineering」という潮流が台頭しました。Application Modelとは異なる文脈から生まれた概念ですが「開発者の認知負荷を下げる」という目的は重なっています。

本連載ではApplication Modelの歴史を振り返り、Platform Engineeringの観点でツール群を比較しながら「自分たちのプラットフォームにどう組み込むか」を考えていきます。

Application Modelとは何か

Application Modelとは、アプリケーションの「意図」を宣言的に記述し、インフラの詳細から分離する抽象のことです。開発者は「Nginxをポート8080で2〜10レプリカで動かしたい」とだけ書けば、プラットフォームがDeployment、Service、HPA、DNS登録、TLS証明書をすべて生成します。HerokuのBuildpacksもCloud FoundryのManifestも、広義にはApplication Modelでした。

この抽象化がうまく機能すると、複数の恩恵をもたらします。

• 認知負荷の削減: Deployment・Service・HPA・NetworkPolicyといったリソースの詳細をプラットフォームが吸収し、開発者が意識すべき設定を最小限に絞ります。Kubernetesを知らなくてもデプロイできる、が理想形です
• 責務の明確化:「何をプラットフォームが面倒を見るか」がコードとして明文化されます。口約束のルールがなくなり、チームが大きくなっても一貫性を保てます
• オンボーディングの高速化:「この10行を書けばデプロイできる」という明確な入口が生まれます。新メンバーがKubernetes全体を理解する前から価値を出せます
• ガバナンスの一元化: セキュリティポリシーやリソース制限をApplication Modelのレイヤーで強制できます。開発者に意識させることなく、組織のルールをデフォルトに組み込めます

核心にあるのは「開発者が何を知らなくて済むべきか」という問いです。ただし、その答えは組織によって全く異なります。ネットワークの詳細を隠すべき組織もあれば、CDN企業のようにネットワーク設定こそが開発者の本業という組織もあります。この「答えが1つに定まらない問い」に対して、Kubernetesの世界で業界標準を作ろうとしたのが「Open Application Model(OAM)」でした。

OAM ー最初にして最大の試み

Helmのvalues.yamlやKustomizeのoverlayも広い意味ではApplication Modelの一種ですが、「アプリケーションの記述方法そのものを業界標準として定義しよう」という試みはOAMが最初でした。

OAM Spec

2019年、MicrosoftとAlibaba Cloudが共同でOAMを発表しました。Kubernetesのマニフェストでは「誰が何を書くべきか」が定義されていません。Deploymentを書くのは開発者かSREか。HPAの閾値は誰が決めるのか。OAMはこの曖昧さに対して3つの役割、Developer(アプリ開発者)、Application Operator(アプリ運用者)、Infrastructure Operator(インフラ運用者)を定義し、それぞれが触れるエンティティをSpecレベルで分離しました。

OAMの仕様は大きく「Definition層」と「Application層」の2つに分かれます。

Definition層(Infrastructure Operatorが定義する):

• ComponentDefinition: コンポーネントの「型」を定義します。内部実装はCUE(JSONのスーパーセットにあたる型付き構成言語)やHelmで記述し、開発者に公開するパラメータ(image、port等)だけをparameterとして宣言します。開発者からはインフラの詳細が見えない構造です
• TraitDefinition: コンポーネントに付与できる運用特性(スケーリング、Ingress等)を定義します。appliesToWorkloadsでどのワークロードに適用可能か、conflictsWithで競合するTraitを宣言でき、組み合わせの整合性をSpecレベルで保証します
• WorkloadDefinition: プラットフォームが実行できるワークロードの種類を宣言します。replicable(スケール可能か)、daemonized(常駐プロセスか)、exposed(エンドポイントを持つか)といったラベルでワークロードの性質を分類します
• ScopeDefinition: コンポーネントをグループ化し、共有の振る舞いを定義する論理的境界です。Specではヘルスチェックを集約するHealth Scopeと、ネットワーク境界を定義するNetwork Scopeが標準として定義されています

Application層(Developer・Application Operatorが記述する):

• Application: ComponentとTraitをまとめる最上位の単位です。開発者はtypeでComponentDefinitionを参照し、propertiesでパラメータ値を渡すだけで済みます。運用者がTraitやScopeを追加して運用特性を設定します

この二層構造がOAMの核心です。Infrastructure OperatorがDefinition層で利用可能なコンポーネントとパラメータを制御し、Developerはその結果として絞り込まれたApplication層だけを触ります。Kubernetesの全リソースを直接扱う必要がなくなる設計です。

つまり、開発者から見れば「typeを選んでpropertiesを埋める」だけ。裏側の複雑さはDefinition層が全部吸収します。

実装: RudrからKubeVelaへ

Microsoftは、Specと同時にRust製のリファレンス実装「Rudr」を公開しました。しかしRudrは2020年にアーカイブされ、Alibabaが開発した「KubeVela」が後継となりました。以降、OAMの実装はKubeVelaのみです。

KubeVelaはOAM Specの二層構造をそのまま実装しています。Infrastructure OperatorがCUEでComponentDefinition/TraitDefinitionを記述し、Developerに公開するパラメータを制御します。Developer側はApplication CRDにtype: webserviceとイメージ名を書くだけでデプロイでき、Trait(scaler、ingress等)を追加すればスケーリングやルーティングが設定されます。

採用と停滞

KubeVelaの採用は中国を中心に広がりました。国内では2021年の「CloudNative Days Tokyo 2021」でサイバーエージェントのチーム(三澤虎遊汰・谷成雄)がAmeba基盤での運用事例を発表しています。2023年3月にCNCF Incubatingに昇格しましたが、グローバルでの採用は限定的でした。

しかし、この頃から状況が変わります。KubeVelaはv1.7.0(2023年1月)からv1.9.0(2023年6月)まで2〜3ヶ月間隔でリリースされていましたが、v1.9.0以降は約1年8ヶ月の空白を経てv1.10.0(2025年2月)が出たのみで、実質的な機能更新は2023年半ばで止まっています。公式ブログも2023年5月以降約2年半途絶えました。OAM Specはさらに早く、v0.3.0(2021年6月)を最後に4年以上更新されていません。

なぜOAMは停滞したのか

多くのエンジニアが挙げる理由は「Helmで十分」「複雑すぎる」「エコシステムがない」です。いずれも事実です。ただ、私はより構造的な原因があると考えています。OAMとKubeVelaの間で何が起き、なぜ立て直せなかったのか。その背景には、連鎖的に問題が広がっていった構造があります。

KubeVelaのフルプラットフォーム化

OAM Specが定義したのは記述モデルまでです。「アプリケーションをどう書くか」は定義しましたが「書いたマニフェストをどうデプロイするか」はスコープ外でした。Helmならhelm install1つで記述からデプロイまで完結しますが、OAMで同じことをするには別途デリバリの仕組みが必要でした。

KubeVelaはこの空白を埋めるために生まれました。ただし最初からSpec実装を超えた野心を持っていました。共同創設者自身がOAM Spec Issue #473上で“it is designed to be an OAM platform since day 0”と述べているように、最初からデリバリを中心としたフルプラットフォームを志向していました。Workflowエンジン、Terraform連携、Web UI、マルチクラスタデリバリと、OAM Specの範囲を大きく超える機能を次々に実装していきます。

ユーザーが求めていたのも、OAM準拠の記述モデルよりKubernetesの複雑さを隠すプラットフォーム機能でした。

仕様と実装の乖離

本来、Specが記述モデルを定義し、KubeVelaが実装し、運用経験がSpecにフィードバックされる。このサイクルでOAMは成熟するはずでした。しかし、KubeVelaの開発リソースはプラットフォーム機能に集中し、コアモデルの改善は後回しになりました。共同創設者自身が同Issueで“we should not have created a 'spec only' project”と振り返っています。

結果として、KubeVelaの実装が事実上のOAM仕様となりました。Openであるはずだった仕様は1つの実装に閉じ、OAMに興味を持った開発者やベンダーがSpecを読んでも実際のKubeVelaの動作とは乖離しており、KubeVelaを使わない限りOAMに参加するメリットがない状態になりました。OAMの運命はKubeVelaの運命と同義になったのです。

ユーザーの関心の移行

Platform Engineeringの普及とともに、責務の明確なツールを組み合わせてプラットフォームを構築するアプローチが確立されてきました。Backstage(開発者ポータル)＋ArgoCD(デリバリ)＋Crossplane(インフラ)のような構成です。個々のツールはスコープが狭い分、独立してアップグレード・置き換えが可能で、障害の影響範囲も限定されます。1つのツールに依存しきるリスクを避けたい組織にとって、composableなアプローチは合理的な選択と言えるでしょう。

すべての組織がこの方向に向かったわけではありませんが、少なくとも選択肢として成立するようになった中で、すべてを包もうとするKubeVelaは競合が増えました。コミュニティと周辺ツール群が薄いまま、Application Modelとしての本来の強み、つまり認知負荷を下げる記述モデルはプラットフォーム機能の開発に押されて磨かれず、徐々にユーザーが離れていきます。

決定打 ースポンサー企業の戦略変更

MicrosoftはOAMの提唱企業でありながら、2023年10月に「Radius」という別のアプリケーションプラットフォームを発表しました。RadiusはOAMの役割ベースの関心分離ではなく、リソース間の関係をApplication Graphとして表現するモデルを採っており、公式ドキュメントにOAMへの言及は一切ありません。Alibaba側も2022〜2023年の大規模な組織再編を経て、事実上KubeVelaから撤退しました。コントリビュータの大半をAlibaba社員が占めていたため、この離脱がそのまま活動量の低下に直結しました。

仕様の問題は修正できます。しかし、それを修正する人がいなくなったとき、プロジェクトは終わります。

OAMの停滞が残した問いは、Platform Engineeringとして内製プラットフォームを構築する多くのチームにも当てはまります。これについては本連載の後半で掘り下げます。

OAM以降 ー概念は死んだのか

OAMは停滞しましたが、Application Modelの概念自体は形を変えて生き延びています。「Crossplane 2.0」(2025年8月リリース、同年11月にCNCF Graduated)はインフラ管理からアプリとインフラの統合管理へ進化しました。「Kro」(2024年11月にAWSが公開、2025年1月にGoogle・Microsoftが合流しkubernetes-sigsに移管、Alpha段階)はKubernetesネイティブのリソース合成に挑んでいます。いずれもOAMのようにフルプラットフォームを目指すのではなく、既存のエコシステムと共存するスコープ設計を採っています。

KubeVela自体も完全に止まったわけではありません。2025年2月に約1年8ヶ月ぶりのメジャーリリースとなるv1.10.0を公開し、年末にはコミュニティ主導で安定性と成熟性に注力した1年を振り返るブログを公開しています。ただし、Alibabaの組織的支援が戻る見込みは薄く、持続的な開発体制を確立できるかは未知数です。

一方、Application Modelが実際に機能しているのはむしろ自社構築のケースです。MercariはCUEベースのフレームワークでKubernetes設定を90%削減しました。LINEヤフーは独自App CRDで29,000アプリ・140,000＋Podを統一管理し、開発者は10〜20行のマニフェストでデプロイが完了します(「KubeCon Japan 2025」での登壇資料)。

アプローチは対照的ですが、共通点があります。どちらもOAMやHelmを採用せず「自社の開発者が何を知らなくて済むべきか」を起点に設計しています。ただし自社構築には専任チームの人件費、アップストリーム追従コスト、ナレッジ断絶のリスクがあり、この規模の組織力があって初めて成立する選択です。

まとめ

2026年時点でApplication Modelという言葉はほぼ聞かなくなりました。OAMの停滞が用語自体に否定的な連想を付けたことと、「唯一の標準モデル」より「組織ごとの最適解」を志向するPlatform Engineeringの哲学が支配的になったためです。しかし概念は死んでいません。Golden Path、Self-Service Portal、Internal Developer Platform。これらはApplication Modelの別名ではありませんが「開発者が何を知らなくて済むべきか」という同じ問いに別の角度から向き合っています。多くのプラットフォームチームは意識するかどうかに関わらず、何らかのApplication Modelを構築しています。

「自分たちの開発者にとって、何を知らなくて済むべきか」。この問いに対する各組織の回答が、そのままその組織のApplication Modelになります。

OAMは標準仕様としては停滞しましたが、その設計思想、つまり役割ごとの関心分離、Definition層による抽象化、開発者に見せるパラメータの制御はPlatform Engineeringでプラットフォームを設計する際のフレームワークとして使えます。OAMの歴史から学べるのは「何を作るべきか」と同時に「どこにスコープを引くべきか」という教訓でもあります。

次回は、Application Modelに関わるツール群(KubeVela、Crossplane、Kro)がそれぞれどのような答えを出しているのか、同一のワークロードをデプロイしながら比較します。