DSLと実行基盤が成立させるCBD:実装可能なコンポーネント構造

Created: 2026-02-23

📄 AI時代の開発スタックでは、AIがBoKから実行基盤までを束ねる構造を整理しました。本稿では、SimpleModelingが提供する構造の上でCBDがどのように成立するのかを考察します。

CBDの実現技術

CBDは非常に強力な技術体系ですが、実装技術側の受け入れ態勢が整備されておらず「絵に描いた餅」になっていた部分が多かったと思います。 現時点ではプログラミング言語での直接のサポートはなく、JavaのエコシステムでもJavaBeansやEnterprise JavaBeans、Springなどで部分的にサポートされているのみです。

Javaでコンポーネント (Component)をサポートする場合、

  • プログラミング重視でPOJOを基本とすると、コンポーネントの持つ能力をフルに発揮できない

  • コンポーネントの仕様設定が煩雑で、開発の難易度が高い割に効果が限定的

のいずれかになりがちです。

この問題を解決するためには以下の技術が必要になります。

  • コンポーネント仕様を厳密に定義する方式

  • コンポーネント仕様を仕様通り実行する実行基盤

SimpleModelingではこの目的で以下のプロダクトを提供しています。

文芸モデル (Literate Model)DSL (Domain Specific Language)であるCozy Modeling Language (CML)で分析モデル・レベルの仕様を記述します。

CNCFは実行基盤のDSL内部DSL (internal DSL)として提供しています。

文芸モデル・コンパイラであるCozyCMLで記述した分析モデル仕様からCNCF内部DSLを自動生成することで、分析モデルと実装を直結します。

このメカニズムにより分析モデル・アップダウンのダウン側の実現を行います。

コンポーネント開発者はScala言語でコンポーネントDSLに紐付けられたロジックを記述することでコンポーネントの実現を行います。

ロジックの記述は各種仕様が固まっている状態 (State)で行うのでAIによる半自動生成が有効に働きます。 DSLによる構造定義だけでなく、文芸DSLの「文芸」による記述、BoKによる用語集 (Glossary)や関連記事もAIに対する有力な入力情報となります。

クラウド・プラットフォーム

従来からあるコンポーネント技術の問題点に加えて、AI時代にはクラウド・プラットフォームの取り扱いが重要になってきます。 クラウド・プラットフォームの能力を最大限に発揮するためには、コンポーネント仕様と実行基盤がアーキテクチャレベルで整合している必要があります。

クラウド・プラットフォームは以下の特徴 (Feature)を持ちます。

  • 複数台のサーバーを手軽に同時使用することが可能

  • クラウド・ファンクションによるサーバーレス

  • 大規模メモリの使用が可能

  • 必要なサーバーを必要なタイミングで使用することが可能

これらの特徴を活かして、以下の性質を実現することが求められます。

  • リアクティブ

  • スケーラビリティ

  • リジリエンシィ

  • パフォーマンス

  • 低コスト

高い即答性を持つスケールする高可用性のアプリケーションを低コストで運用する、という非常に難易度の高い性質を実現するためには、様々な技術を適切に組み合わせて用いる必要があります。

この目的で有力視されているのがCQRSを軸にしたアプリケーション・アーキテクチャです。

  • コマンドとクエリの分離

  • 読み取りと書き込みの責務分離

  • 状態更新と状態参照の構造的分離

これらをコンポーネント仕様レベルで定義し、実行基盤がその通りに実現することで、クラウド前提のアーキテクチャが自然に成立します。

CQRSをアプリケーション・アーキテクチャとして採用すると、アプリケーションの作り方が大きく変わるという問題が出てきます。 この新しい方式に適したモデリング手法やDSLを用意しなればなりません。 そして、この新しいアーキテクチャのアプリケーションをそのまま動作させることができる実行基盤が必要です。

CozyCNCFはこの2つの課題に対応することを重要な目的の一つとしています。

コンポーネントによる契約

CNCFコンポーネントDSLにより以下の仕様を定義します。

これらの仕様は実行基盤上で動作する上での契約として機能します。

CozyCNCFによるエコシステムでは、分析レベルのモデル (Model)CNCF上でそのままコンポーネントとして機能することで、モデルと実装の乖離を防ぎ、コンポーネントの持つ本来の能力を発揮することを可能にしています。

契約は以下のメカニズムによって保証されます。

  • DSLによる構造的制約(仕様違反は生成段階で排除)

  • 実行基盤による呼び出し境界の強制

  • API/SPIの型安全 (type safety)な分離

  • ランタイムでの契約検証(エラー・観測モデル)

つまり、契約は文書ではなく、構造として強制されるという点が従来のCBDとの決定的な違いです。

コンポーネントの長所

📄 AI時代のComponent-Based Developmentであげたコンポーネントの長所をベースに、いくつか追加したものを以下に示します。

  • 再利用性

  • 独立性

  • 保守性

  • CI/CD適合性

  • 拡張性と可搬性

  • デプロイ単位の明確性

  • テスト容易性

  • 実行境界の可視化

  • 責務分離の明確化

それぞれの長所によるメリットを実際に享受できるようにCozyCNCFでは様々なサポートをしています。 ここでは再利用性とテスト容易性に絞って説明します。

再利用

Cozyによる外部DSL (external DSL)CNCFによる内部DSLという2つのDSLにより、

されるため、再利用可能な単位として取り扱うことが可能になります。

さらにCNCFでは、

  • Dockerコンポーネント

  • Fat JARコンポーネント

  • Collaborator構造

  • SPIによる拡張

などのメカニズムによって、CNCFコンポーネントのエコシステム外にある通常のJavaエコシステムの成果物をCNCFコンポーネントとして取り込み、CNCFコンポーネントとしての再利用が可能になっています。

テスト容易性

CNCFコンポーネントは以下のメカニズムにより環境に依存しない単体テストが可能になっています。

  • 関数型による副作用の抽象化

  • 実行コンテキストによる実行環境の抽象化

  • API/SPIによる抽象インタフェース

  • 拡張点/変化点

  • UnitOfWorkによるアプリケーション・トランザクション

  • コンポーネント間の結合の外部化

  • データベースやネットワークなどの外部環境の抽象化

  • 時間や乱数などの実行環境の要素の抽象化

上記のメカニズムによって、コンポーネントの実装はそのままで、実行環境を差し替えてテスト (Test)することが可能です。

コンポーネントの短所の克服

📄 AI時代のComponent-Based Developmentでは、以下の短所について、

  • 発見の難しさ

  • 仕様理解コスト

  • 結合コスト

  • 設計難易度

  • 開発コスト

  • 可視性の低下

DSLとAIによって対処できるのではないかという主張を行いました。 これらの短所が克服されることによって、コンポーネント技術の実用性が高まります。

これに加えてCNCFによる実行基盤の提供により、以下の点でさらに改善が期待できます。

  • 実行境界が明確になることによる可視性の向上

  • コンポーネント登録・発見機構による探索性の改善

  • 実行基盤による標準化されたライフサイクル管理

  • 呼び出し規約の統一による結合コストの低減

  • DSL自動生成による設計難易度の平準化

  • テンプレート化・半自動生成による開発コスト削減

  • 観測モデル統合による障害解析の容易化

  • AIによる仕様理解・差分理解支援

特に重要なのは、「実行基盤があること」によってコンポーネントが単なる設計上の概念ではなく、実際に登録・発見・接続・実行される実体として扱える点です。

従来のCBDでは、

  • コンポーネント定義はあるが実行規約はプロジェクト依存

  • 発見はドキュメント頼み

  • 結合は人間の設計判断に委ねられる

という状況が多く、理論と実装の間にギャップがありました。

CNCFでは、

  • DSLレベルでAPI/SPIを明示

  • 実行基盤が接続と境界を管理

  • コンポーネントを単位とした配備・検証・観測が可能

となるため、コンポーネントの概念が「運用可能な単位」として確立します。

さらにAIとの組み合わせにより、

  • 仕様→DSL→実装の流れが安定化

  • 既存コンポーネントの理解コスト低減

  • 結合候補の探索支援

  • 仕様変更の影響範囲解析

といった支援が現実的になります。

つまり、CBDの短所は「概念的であること」そのものに起因していたのではなく、それを支える構造と実行基盤が不足していたことに起因していたと言えます。

CozyCNCFはその欠落部分を埋めるための基盤です。

品質属性の外部化

SimpleModelingでは以下の品質属性をモデル化対象としています。

  • 実行時品質

  • 運用品質

    • 運用性

    • 観測可能性

    • 配備容易性

    • 構成容易性

  • 設計時品質

    • 保守性

    • 拡張性

    • 再利用性

    • テスト容易性

    • 可読性

    • 一貫性

  • 組織・ビジネス品質

    • 移植性

    • 相互運用性

    • 進化可能性

    • 経済性

  • AI品質

    • モデル可読性

    • AI操作性

    • 文脈安定性

    • 自動生成適合性

従来からある実行時品質、運用品質、設計時品質、組織・ビジネス品質に加えてAI時代に対応するAI品質を追加しています。

これらの品質属性は横断的関心事に対する関心の分離によって、ドメイン構造やドメイン・ロジックとは切り離して扱えることが望ましいです。 さらに、DSLによる設定と実行基盤によって暗黙的に実現できると理想的です。

SimpleModelingではCozyCNCFによって上記のような品質属性を隠蔽し、ドメイン構造やドメイン・ロジックの開発に集中できる枠組みを提供します。

非同期抽象化

クラウド・アプリケーションに要求されるリアクティブな性質やクラウド・プラットフォームの提供するマルチサーバーの環境は必然的に非同期処理が必須となります。

非同期処理を容易に開発して、安全に運用するためには、アプリケーション・アーキテクチャをCQRSにするとともに、実行基盤のサポートが必須です。

実行基盤が、

  • 同期呼び出し

  • 非同期メッセージ

  • イベント受信

を抽象化することで、コンポーネント設計は通信方式から解放されます。 CNCFではこのための枠組みを提供しています。

まとめ

本稿では、DSLと実行基盤の組み合わせによってCBDが実装可能な構造として成立することを論じました。

従来のCBDは理念としては強力でしたが、実装技術との接続が弱く、理想論に留まりがちでした。

しかし、

  • DSLによる厳密な構造定義

  • 実行基盤による構造保証

  • クラウド前提アーキテクチャとの整合

  • 横断的関心事の外部化

  • 非同期抽象化

が揃ったとき、CBDは設計思想ではなく、実行可能なアーキテクチャ単位になります。

CNCFはそのための実行基盤であり、Cozyはそのための構造定義言語です。

AI時代の開発スタックにおいて、CBDは再び中心技術として位置づけられます。

参照

用語集

BoK (Body of Knowledge)

SimpleModelingでは文脈共有の核となる知識体系をBoK (Body of Knowledge)と呼んでいます。 BoKの構築は、知識の共有、教育、AIによる支援、自動化、意思決定支援を可能にするための基盤です。

CBD (Component-Based Development)

CBD(コンポーネント指向開発)は、ソフトウェアを責務・契約・インターフェースを明確に定義したコンポーネント単位で構築・再利用する開発方式です。 コンポーネントは独立性と交換可能性を備え、システムを疎結合に構成することで保守性と再利用性を高めます。 論理モデルでは機能や契約を定義する抽象構造単位として、物理モデルでは実際の実装・デプロイメント単位として扱われます。

シンプルモデリング (SimpleModeling)

SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。

コンポーネント (Component)

責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。

Cozy

Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。

Cloud Native Component Framework (CNCF)

Cloud Native Component Framework(CNCF)は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server(REST / OpenAPI)、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。

Cozy Modeling Language (CML)

CML(Cozy Modeling Language)は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。

DSL (Domain Specific Language)

DSL(ドメイン固有言語)は、特定の領域(ドメイン)に特化して設計された言語であり、その分野の概念や構造を直接的かつ簡潔に表現することを目的とします。 一般的な汎用プログラミング言語(GPL)に比べ、DSLは特定ドメインの問題解決や自動生成に適した高い抽象度を持ちます。

文芸モデル (Literate Model)

Undefined

内部DSL (internal DSL)

内部DSL(Internal DSL)は、ホスト言語の構文と型システムを利用して構築されるドメイン特化表現です。 ホスト言語の文法範囲内で設計されるため、既存の型検査やツール群をそのまま活用でき、実行可能で保守性にも優れます。 Scalaでは、関数・型クラス・マクロ・拡張メソッドを組み合わせて柔軟なDSLを設計できます。

Scala

Undefined

状態 (State)

UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。

用語集 (Glossary)

Glossaryとは、対象領域で使用する用語について、名称、意味、境界、同義語、識別子を管理する知識資源です。関係者が同じ用語を同じ意味で扱うための共通基盤になります。

特徴 (Feature)

UMLにおけるFeatureは、ClassifierのInstanceを特徴付ける構造上または振る舞い上の性質です。AttributeなどのStructural Featureと、OperationなどのBehavioral Featureがあります。

性能 (Performance)

Performanceとは、指定された条件と資源のもとで、システムが処理時間、応答時間、Throughput、容量などの時間的要求を満たす性質です。

イベント (Event)

UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。

品質属性 (Quality Attribute)

Quality Attributeとは、ソフトウェアが機能を実行できることに加えて、どの程度の品質で要求を満たすかを表す特性です。Security、Performance、Availability、Reliability、Resilience、Observability、Maintainabilityなどが含まれます。

モデル (Model)

Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。

型安全 (type safety)

型安全とは、プログラムにおける型の整合性をコンパイル時または実行時に保証する性質を指します。 型安全性が保たれているとき、ある型に対して定義されていない操作を実行しようとした際にエラーとして検出され、 意図しない動作やバグの発生を防ぐことができます。 Scalaは強い静的型付けと型推論を併用することで、高い型安全性を維持しつつ柔軟なプログラミングを可能にしています。

型 (Type)

Undefined

エラー (error)

汎用的な表現として用いられる用語。ソフトウェア工学では多義的に使われ、バグや障害全般を指す。SimpleModeling では広義のラベルとして使用し、個別には Mistake・Defect・Fault・Failure・Deviation に整理する。

観測記録 (observation, オブザベーション)

対象の現象を捉えて記録した結果。

妥当性確認 (validation)

Validation(妥当性確認)とは、システムや機能が利用目的や要求仕様に対して妥当であるかを確認する行為である。

外部DSL (external DSL)

外部DSL(External DSL)は、汎用プログラミング言語とは独立した構文体系を持つドメイン特化言語です。 特定の領域に最適化された文法と語彙により、人間による記述・読解に優れています。 実行にはパーサーやコンパイラを必要とすることが多く、ホスト言語とは分離された設計が前提となります。

依存 (Dependency)

UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。

表出化 (Externalization)

SECIで暗黙知を言語・モデル・図表など形式知に外化するフェーズ。

テスト (Test)

Testとは、指定した条件で対象を実行または評価し、観測した結果を期待する結果やConstraintと比較して、要求または契約への適合を確認する活動とその仕様です。

仕様確認 (verification)

Verification(仕様確認)とは、規定された設計仕様や要求仕様に対して、実装が一致しているかを確認する行為である。

信頼性 (Reliability)

Reliabilityとは、指定された条件と期間のもとで、システムが要求された機能を一貫して遂行する性質です。Availability、Fault Tolerance、Recoverabilityなどを含む観点から評価します。

セキュリティ (Security)

Securityとは、情報と機能を正当な権限に従って保護し、不正な閲覧、利用、変更、破壊、否認を防ぐ性質です。Confidentiality、Integrity、Authenticity、AccountabilityなどのConcernを含みます。