文芸モデリング

第5回では、オブジェクト・モデルを、開発者、プログラミング言語、実行基盤、生成AIが共有する形式的な構成要素として扱いました。第6回では、知識モデルを、概念、規則、意味関係、根拠を生成AIが探索し、人間へ説明するための構成要素として扱いました。

第7回は文芸モデルを扱います。文芸モデルは、形式構造への補足説明や実装後に作るドキュメントではありません。自然言語で記述した内容そのものがモデルの一部となり、要求、設計、判断、検証、ドキュメント構成の入力になります。

前回の記事: 📄 AI協業を支える知識モデリング

三つは別々の対象を扱うのではなく、同じ対象について必要な側面を分担します。形式構造だけでは、「この要求は誰のどのような状況を解決するのか」「なぜこの判断をしたのか」「何を前提としているのか」を十分に保持できません。文芸モデルは、これらをモデルの外へ追い出さず、オブジェクト・モデルや知識モデルへ対応付けて保持します。ナラティブとユースケース・シナリオを重要な形式として強調しますが、ビジョン、要求、判断記録、既存仕様に加え、ドメイン・モデルを人が理解できる自然言語で説明する従来型ドキュメントも文芸モデルを構成します。

ストーリーは、主体、目的、状況、出来事、因果、結果から成る意味内容です。ナラティブは、そのストーリーから目的に必要な要素を選び、特定の視点と文脈に基づいて配列、説明した表現です。この意味で、ナラティブは変化の意味を表す文芸モデルとして機能します。同じストーリーから、利用者、運用者、開発者のそれぞれに必要なナラティブを構成できます。

人は抽象的な規則だけを演繹的に追うより、具体的なストーリーをナラティブとして示すことで、帰納的に意味を捉えやすくなります。一方、一つのナラティブだけでは、許されるすべての振る舞いを定義できません。帰納的なナラティブと演繹的な形式モデルを相補的に使うことで、「何が起き、なぜ重要か」と「何が常に成り立つべきか」を接続できます。

ユースケース技術は、利用者視点のナラティブによってシステムの振る舞いを記述する要求モデリングの核です。ユースケース・シナリオは、アクターの目的を達成する一つのストーリーを、アクターと対象システムの間で進む出来事、行為、分岐、成功または失敗の結果として構成したナラティブです。

従来、ユースケースシナリオは開発者が読み解き、分析、設計、実装へ変換する要求記述でした。生成AIは、自然言語で記述されたシナリオを直接読み、関係する用語、規則、モデル要素を参照しながら、オブジェクト・モデルとCML (Cozy Modeling Language) を生成、更新、管理できます。

アクターの目的 → ユースケースシナリオ → textus-bokによる知識モデル化 → 生成AIによるオブジェクト・モデルとCMLの生成・更新・管理 → textus-cbd-supportによる可視化・差分・根拠 → 人間によるレビュー → 承認または指摘を生成AIへ返す

ここで「直接入力」とは、シナリオから正しい実装が無条件に自動生成されるという意味ではありません。生成AIがオブジェクト・モデルを管理する一方、人間が要求との対応、意味、影響を確認し、承認または指摘を返すという意味です。これまで開発者の頭の中にあった解釈を、可視化し、追跡し、承認できる協業工程へ変える点に本質的なブレークスルーがあります。

文芸プログラミングは、プログラムと説明を一つの文書で扱い、コンピュータの実行順序ではなく、人間が理解しやすい順序で記述する考え方です。この考え方をモデリングへ適用し、モデル情報と説明を人間が理解できる形で一体的に組織する活動・方法を、文芸モデリング (Literate Modeling)と呼びます。その活動 (Activity)で記述し、組織する対象と成果物が文芸モデルです。

文芸プログラミング → 文芸モデリング: モデルへ適用する活動・方法 → 文芸モデル: その対象・成果物

CMLは文芸モデリングの具体的な実践でもあります。CML文書の形式要素は実行可能なオブジェクト・モデルを表し、同じ文書にある自然言語の説明、意図、前提は文芸モデルを表します。したがって、CML文書はオブジェクト・モデルと文芸モデルの両方にまたがります。ただし、文芸モデル全体をCMLで表現するわけではありません。AI時代には、CML以外のビジョン、要求、判断、シナリオなどの文書情報も、文芸モデルとして統一的に扱います。

自然言語で書かれているだけでは、文書は文芸モデルになりません。少なくとも、何について何のために記述しているかが分かり、内容の意味と識別子 (Identifier)をたどれ、設計、判断、検証のいずれかへ接続できる必要があります。

すべてを一つの文書へ詰め込む必要はありません。目的に必要な内容を選び、関係する用語、知識、オブジェクト・モデル要素へ対応付けます。

文芸モデルは、ビジョンやユースケースのような目的別の文書だけから成るわけではありません。ドメイン・モデルの概念、規則、関係を、人が読める通常のドキュメントとして記述した従来型の説明文書も重要な構成要素です。形式モデルと対応付けることで、人と生成AIがドメインの意味を理解し、差分を確認するための基盤になります。

ビジョン、ゴール、コンテキストも、開発を方向付ける重要な文芸モデルです。ビジョンは実現したい将来像と存在理由を、ゴールは到達したい結果、優先順位、成功条件を、コンテキストは関係者、対象範囲、環境、制約 (Constraint)、判断の前提を示します。

これらをモデルとして保持すると、要求、アーキテクチャ判断、優先順位、検証結果を、プロジェクトの目的と境界へ照らして確認できます。生成AIも、単独の要求だけでなく、なぜその要求が必要かという文脈を参照して候補を作成できます。

文芸モデルの記述には、フルスペックの基本言語としてSmartDoxを使い、Markdownも利用できます。SmartDoxは、自然言語の読みやすさを保ちながら、見出し、段落、一覧、表、図、用語参照によって文書を組織する記述基盤です。プレーンテキストとして変更を追跡でき、用語集 (Glossary)の識別子を手掛かりに、文芸モデルの記述を他のモデル要素へ接続できます。

SmartDoxで記述しただけで、内容が妥当なモデルになるわけではありません。対象、目的、意味、識別子、根拠、承認状態を組織する必要があります。textus-bokは文芸モデルを知識モデル化して生成AIへ接続します。生成AIはこの文脈を使ってオブジェクト・モデルを生成、更新、管理します。人間はtextus-cbd-supportが提供する可視化、差分、根拠で結果の意味と妥当性を確認し、承認または指摘を生成AIへ返します。

要求仕様、設計説明、レビュー資料、ユーザーガイド、リファレンスマニュアルを、それぞれ独立した正本として開発すると、同じ事実が重複し、更新のたびに不整合が生じます。文芸モデリングでは、背景、目的、要求、判断、シナリオ、前提、履歴を文芸情報の正本として組織し、目的と読者に応じたドキュメントを必要な正本から構成・生成します。

これは、すべてのドキュメントを派生物にするという意味ではありません。ドメイン・モデルの概念、規則、関係を自然言語で説明する文書は、それ自体が文芸モデルの正本となり、他の目的別ドキュメントから参照されます。

生成したドキュメントは、新しい正本ではなく、必要なモデル要素を目的と読者に合わせて構成したビュー (View)です。正本を更新し、一定の組織化規則に従って各ドキュメントを再構成します。

ユースケース・シナリオは、文芸モデルの重要な実例です。アクターの目的、出来事、行為、分岐、結果から成るストーリーを利用者視点のナラティブとして表し、要求仕様の核になります。ユーザーガイドの重要な元情報であり、AI開発ではモデル作成・更新の直接入力になります。

ただし、文芸モデルはユースケースシナリオだけではありません。ビジョン、ゴール、コンテキスト、要求、判断記録、設計意図、前提、履歴に加え、ドメイン・モデルを通常のドキュメントとして説明する文書も、モデルの意味と識別子へ対応し、設計、理解、検証の入力になる重要な文芸モデルです。

ユースケースシナリオからCMLへ直接飛ぶと、シナリオのどの記述が、どの参加者、責務 (Responsibility)、操作 (Operation)、イベント (Event)、状態変化に対応するのかを確認できません。SimpleModelingでは、シナリオと実行可能な要素の間に、レビュー可能なユースケース実現モデル (Use Case Realization Model)を置きます。

ユースケースシナリオ → textus-bokによる知識モデル化 → 生成AIによるユースケース実現モデルと実行可能要素の生成・更新 → textus-cbd-supportによる可視化・差分・根拠 → 人間によるレビュー → 承認または指摘を生成AIへ返す → CMLを更新

生成AIは、シナリオから参加者、役割、責務、協調 (Collaboration)、相互作用を抽出し、ユースケース実現モデルと、サービス、操作、イベント、状態機械 (StateMachine)などの実行可能要素を主として生成、更新、管理します。人間は要求の意味と対応が保たれているかを確認し、承認または指摘を生成AIへ返します。この中間モデルによって、AIが行った解釈とオブジェクト・モデルの更新を追跡できます。協調、相互作用、状態機械を使った具体的なアプリケーション・モデリング (Application Modeling)は、第9回で扱います。

「注文を確定する」という同じ対象を、三つの構成要素から見ると、それぞれの役割が明確になります。

三つの記述は、用語集の識別子を共通の手掛かりとして対応付けます。textus-bokが文芸モデルを知識モデル化して生成AIへ渡し、生成AIがオブジェクト・モデルを生成、更新、管理します。人間はtextus-cbd-supportを通して、シナリオの目的と結果が実行可能なモデルに保たれているかを確認します。

次回の第8回「ドメインモデリング」では、オブジェクト・モデル、知識モデル、文芸モデルから、問題領域の意味、構造、規則、境界をどのように組織するかを扱います。