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

浅海 智晴 Created: 2026-02-23

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

CBDの実現技術

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • リアクティブ

  • スケーラビリティ

  • リジリエンシィ

  • パフォーマンス

  • 低コスト

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

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

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

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

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

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

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

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

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

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

  • API

  • SPI

  • サービス

  • レセプション

  • イベント

  • 拡張点

  • 変化点

  • エラーモデル

  • 品質属性

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

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

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

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

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

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

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

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

コンポーネントの長所

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

  • 再利用性

  • 独立性

  • 保守性

  • CI/CD適合性

  • 拡張性と可搬性

  • デプロイ単位の明確性

  • テスト容易性

  • 実行境界の可視化

  • 責務分離の明確化

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

再利用

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

  • 仕様が明確

  • 依存が明示

  • 境界が構造化

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

さらにCNCFでは、

  • Dockerコンポーネント

  • Fat JARコンポーネント

  • Collaborator構造

  • SPIによる拡張

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

テスト容易性

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

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

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

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

  • 拡張点/変化点

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

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

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

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

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

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

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

  • 発見の難しさ

  • 仕様理解コスト

  • 結合コスト

  • 設計難易度

  • 開発コスト

  • 可視性の低下

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

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

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

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

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

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

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

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

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

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

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

従来のCBDでは、

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

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

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

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

CNCFでは、

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

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

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

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

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

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

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

  • 結合候補の探索支援

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

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

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

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

品質属性の外部化

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

  • 実行時品質

    • 性能

    • 可用性

    • 信頼性

    • スケーラビリティ

    • セキュリティ

    • 回復性

  • 運用品質

    • 運用性

    • 観測可能性

    • 配備容易性

    • 構成容易性

  • 設計時品質

    • 保守性

    • 拡張性

    • 再利用性

    • テスト容易性

    • 可読性

    • 一貫性

  • 組織・ビジネス品質

    • 移植性

    • 相互運用性

    • 進化可能性

    • 経済性

  • AI品質

    • モデル可読性

    • AI操作性

    • 文脈安定性

    • 自動生成適合性

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

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

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

非同期抽象化

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

非同期処理を容易に開発して、安全に運用するためには、アプリケーション・アーキテクチャを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(コンポーネント指向開発)は、ソフトウェアを責務・契約・インターフェースを明確に定義したコンポーネント単位で構築・再利用する開発方式です。 コンポーネントは独立性と交換可能性を備え、システムを疎結合に構成することで保守性と再利用性を高めます。 論理モデルでは機能や契約を定義する抽象構造単位として、物理モデルでは実際の実装・デプロイメント単位として扱われます。

コンポーネント (Component)

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

能力 (Competency)

特定の活動を効果的に遂行するために必要な人的能力。役割に関連するスキル、経験、知識水準を定義する。

文芸モデル (literate model)

文芸モデル(Literate Model)は、モデル構造と自然言語による語り(構造化文書)を統合した「読めるモデル」です。 文芸的プログラミング(Literate Programming)の思想をモデリング領域に拡張し、 構造(モデル)+語り(構造化文書) を一体化することで、人間とAIの双方が理解・操作できる知識表現を実現します。 「Literate Modeling(文芸的モデリング)」という発想自体は、 これまでにも一部の研究者や開発者によって試みられてきました。 しかし、それらは主にドキュメント生成やコード理解の支援にとどまっており、 モデルと言語・語り・AI支援を統合した体系的なモデリング手法として確立されたものではありません。 文芸モデル(Literate Model)は、SimpleModelingがAI時代に向けて新たに体系化・提唱したモデリング概念です。 文芸的モデリングの思想を継承しつつ、 AI協調型の知識循環とモデル生成を可能にする知的モデリング基盤として再構成されています。 文芸モデルは、単なるモデル記述技法ではなく、 人間の思考過程や設計意図を語りとしてモデルに埋め込み、 AIがそれを解析・再構成して設計や生成を支援するための枠組みです。

Cloud Native Component Framework (CNCF)

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

CML (Cozy Modeling Language)

CMLは、Cozyモデルを記述するための文芸モデル記述言語です。 SimpleModelingにおける分析モデルの中核を担うDSL(ドメイン固有言語)として設計されています。 モデル要素とその関係性を自然言語に近い文体で記述できるよう工夫されており、AIによる支援や自動生成との高い親和性を備えています。 CMLで記述された文芸モデルは、設計モデル、プログラムコード、技術文書などに変換可能な中間表現として機能します。

DSL (Domain Specific Language)

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

内部DSL (internal DSL)

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

型安全 (type safety)

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

エラー (error)

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

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

Observationは、Phenomenon(現象)の中から記録に値すると判断されたものを保存した記録です。 観測記録はログ、モニタリング、監査、トラブルシューティングの基盤となります。

妥当性確認 (validation)

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

外部DSL (external DSL)

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

表出化 (Externalization)

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

仕様確認 (verification)

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