SimpleModelingにおけるアーキテクチャセントリック

浅海 智晴 Created: 2026-05-11

この記事では、Unified Processの原則であるArchitecture-Centricを、SimpleModelingがAI時代向けにどのように再解釈するかを説明します。アーキテクチャは単なる設計成果物ではなく、モデリング・実装・実行・知識管理・運用を安定化する開発フレームワークとして扱われます。

AI時代における再解釈

アーキテクチャセントリックなプロセスでは、アーキテクチャは単なる設計成果物ではありません。要求、分析モデル、設計モデル、配置構造、運用構造は、アーキテクチャビューを通して解釈・精緻化されます。

これはAI時代においてさらに重要になります。生成AIは、構造・文脈・責務・ビューが明示されているほど安定して動作するためです。

アーキテクチャは、開発全体を通して反復的に精緻化されます。各イテレーションでは、概念モデル・実装構造・実行環境・運用知識が、一貫したアーキテクチャ枠組みの中で漸進的に精緻化されます。

SimpleModelingリファレンス・プロファイル

SimpleModeling Reference Profileでは、開発を支える複数のアーキテクチャを定義しています。

SimpleModelingのStandard Profileでは、Reference Profileで定義されたすべてのアーキテクチャを採用します。実際のプロジェクトでは、利用者はこれらのアーキテクチャを参考にしながら、一部をカスタマイズ・置換・拡張して利用できます。

以下では、SimpleModelingで利用される代表的なアーキテクチャを説明します。

  • 4+1ビュー・モデル

  • 3層リファレンスアーキテクチャ

  • 実行アーキテクチャ

  • 文芸的アーキテクチャ

  • 知識アーキテクチャ

  • プロセスアーキテクチャ

4+1ビュー・モデル

SimpleModelingは、Unified ProcessでPhilippe Kruchtenが提唱した*4+1ビュー・モデル*を継承し、人が読める文芸的記述(SmartDox)と構造的な設計モデル(Cozy)を結びつける多視点モデリングフレームワークとして再解釈します。各ビューはシステムの異なる関心事に対応します。

ビュー 焦点 対応モデル

ユースケースビュー

利用者の目的とシナリオ

UseCase, Scenario

論理ビュー

ドメイン概念と関係構造

Entity, Value, Rule

プロセスビュー

振る舞い・並行処理・ワークフロー

StateMachine, Activity

開発ビュー

コンポーネント・モジュール・インターフェース

Component, Interface

物理ビュー

配備と実行時構成

Deployment, Node

「+1」としてのユースケースビューは、利用者の意図をシステムアーキテクチャへと結びつける起点となります。これらのビューが統合されることで、一貫したアーキテクチャベースラインが形成されます。

関連記事を以下に示します。

3層リファレンスアーキテクチャ

SimpleModelingリファレンス・プロファイルでは、アーキテクチャベースラインをPresentation(表示)Application(応用)Domain(ドメイン)の3つのサブシステムで構成する、現代的に再解釈された3層アーキテクチャを採用しています。この構造がモデリング・コード生成・デプロイメントの安定した基盤となります。

サブシステム 責務 主要モデル

Presentation

UI・API・ユーザー対話

View, Controller, APIComponent

Application

ユースケース統合・処理制御

Service, UseCase, Workflow

Domain

ビジネスロジックと中核知識

Entity, Value, Rule, DomainEvent

この階層構造は4+1モデルのLogical/Development/Physicalビューと整合し、システム全体の分析容易性・進化可能性・自動化適性を高めます。

関連記事を以下に示します。

実行アーキテクチャ

SimpleModelingでは、実行時振る舞い・実行境界・運用構造を安定化するための実行アーキテクチャを定義します。

  • CNCF実行アーキテクチャ:ライフサイクル、サービス、セレクタ、実行コンテキストを標準化します。

  • CQRS+ジョブアーキテクチャ:同期・非同期実行境界を安定化します。

  • Form API/Static Form Appアーキテクチャ:UI実行構造と画面遷移構造を標準化します。

関連記事を以下に示します。

文芸的アーキテクチャ

SimpleModelingは、アーキテクチャセントリックの概念を文芸的アーキテクチャ(Literate Architecture)へと拡張します。各アーキテクチャ決定・モデル・ビューは、人が読めるSmartDox形式で記述され、Cozyモデルとリンクします。これにより、アーキテクチャは実行可能で説明可能なものになります。

関連記事を以下に示します。

知識アーキテクチャ

SimpleModelingでは、知識の構造・表現・循環を安定化するための知識アーキテクチャを定義します。

  • 文芸モデル (literate model)/SmartDoxアーキテクチャ:知識を半構造文書として整理します。

  • Vocabulary/Glossary/BoKアーキテクチャ:用語と意味空間を安定化します。

関連記事を以下に示します。

プロセスアーキテクチャ

SimpleModelingでは、開発活動と成果物流れを安定化するためのプロセスアーキテクチャを定義します。

  • Process/Activity/Skillアーキテクチャ:開発順序・責務・成果物流れを定義します。

関連記事を以下に示します。

アーキテクチャメカニズム

SimpleModelingでは、アーキテクチャを安定化・制約・支援するためのアーキテクチャメカニズムも定義します。これらはアーキテクチャそのものではなく、アーキテクチャセントリック開発を実践的かつ安定的に成立させるための基盤構造です。

  • 型システム:構造とデータ関係を制約します。

  • Executable Specification:法則や実行可能ルールによって振る舞いを制約します。

  • DSL/文法:モデリング空間と記述空間を制約します。

  • Vocabulary/Glossary:用語と意味的一貫性を安定化します。

アーキテクチャメカニズムに関する記事を以下に示します。

ハーネスエンジニアリング

Harness Engineeringの観点から見ると、SimpleModeling Reference Profileで定義されるアーキテクチャとアーキテクチャメカニズムは、全体として開発ハーネスシステムとして解釈できます。実行・知識・プロセスの境界をアーキテクチャによって構造化することで、開発全体の安定性と再現性を高めます。

これはAI時代においてさらに重要になります。生成AIは、開発環境が明示的に構造化されているほど安定して動作するためです。

まとめ

SimpleModelingにおけるアーキテクチャセントリック開発とは、モデル・実行構造・知識構造・プロセスを統合アーキテクチャの枠組みで整合させることです。SimpleModeling Reference Profileは、概念理解と実行可能システムを結びつける再利用可能なアーキテクチャ基盤を提供します。

参照

サイト内

用語集

UP (Unified Process)

UMLを基盤とし、反復型・ユースケース駆動・アーキテクチャ中心のプロセスモデル。Rational Unified Process (RUP) などの派生形を持ち、CBD(コンポーネント指向開発)の実践基盤となる。

SimpleModelingリファレンス・プロファイル (SMRP, SimpleModeling Reference Profile)

SimpleModelingのリファレンス・プロファイルです。 SimpleModelingによる文芸モデル駆動開発の説明を具体的にするために、リファレンス・プロファイルを定義しています。

実行アーキテクチャ (Execution Architecture)

モデル層と実行層を分離した技術的・実行的基盤。Scala・TypeScript・CDK・ECSなどを含む。

活動 (Activity)

アクティビティスペース内で実行される具体的な行為またはタスク。アルファをより進んだ状態へ移行させるために行われ、通常はワークプロダクトの生成や改良を伴う。

コンポーネント (Component)

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

Cloud Native Component Framework (CNCF)

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

文芸モデル (literate model)

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

BoK (Body of Knowledge)

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

DSL (Domain Specific Language)

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