構造化する技術（第2回）― 意味・関係・実行を構造化する

第1部では、エンティティの境界と同一性を定め、用途ごとに複数の射影を作る考え方を整理した。

第2部では、関心の軸に沿って意味、関係、振る舞い、実行、アクセス、通信、保存を分け、領域の軸に沿ってビジネス、データ、アプリケーション、テクノロジーの設計責任を整理する。各表現を同じエンティティへ紐付ける文脈も扱う。

1. 関心：意味と関係を仕様にする

関心の軸では、同じエンティティについて何を表すかを分ける。ここでは、フィールドの意味、用語の対応、エンティティ間の関係を順に扱う。

1.1 フィールドの意味を仕様へ落とし込む

顧客レコードに文字列型のid、name、statusを設け、idを必須項目にし、statusをactiveとinactiveのいずれかに制限すると、フィールドの有無、データ型、値の範囲を検証できる。JSON Schema Draft 2020-12も、JSON文書の構造と検証規則を記述する仕組みを定めている。

この定義からは、idを誰がどの範囲で発行するか、status = activeがどの状態を表すかまでは判断できない。idを顧客IDとして使うなら、顧客エンティティを参照し、テナント内とシステム全体のどちらで一意にするかを仕様へ落とし込む必要がある。statusには、activeが取引可能な顧客を表すのか、連絡可能な顧客を表すのかを定義する。

単位と比較範囲もフィールドの意味に含まれる。たとえば整数の100を金額として扱うなら通貨を、処理時間として扱うならミリ秒などの単位を指定する。参照先、単位、状態の意味、比較できる値の範囲を論理仕様へ落とし込むことで、同じ文字列型や整数型を持つ値の誤用を検出できる。

複数のシステムで同じ意味を共有するには、フィールドごとの定義に加えて、異なる用語がどの概念を表すかも対応付ける必要がある。

1.2 異なる用語をつなぐ統制語彙

あるシステムが稼働環境をprod、別のシステムがproduction、運用台帳が本番と記録している場合、三つの値を同じ概念へ対応付けなければ横断検索できない。概念ごとに標準の表記と別名を定める統制語彙を用意すると、元の表記を残したまま共通の検索条件へ変換できる。SKOSリファレンスは、概念、優先ラベル、代替ラベル、上位と下位の概念などをRDF（Resource Description Framework、資源記述フレームワーク）で表す語彙を定義している。

一台のサーバーを稼働環境、地域、所有者、重要度で検索する場合、それぞれを独立した分類軸として扱う方法をファセットと呼ぶ。上位語と下位語の階層を使う分類体系がタクソノミーである。検索条件を独立に組み合わせるならファセットを、製品分類や組織分類の上下関係をたどるならタクソノミーを選べる。

概念に加えて関係、制約、推論規則まで定義するモデルがオントロジーである。たとえば人、組織、サービスを概念として定め、所属、所有、依存という関係と制約を記述する。OWL 2概要は、クラス、プロパティ、個体を記述し、明示された知識から論理的な帰結を導くための言語群を説明している。

概念、ラベル、関係を決めた後で、その論理モデルをRDF、リレーション、ドキュメント、プロパティグラフなどの形式で表現する。RDF 1.1の概念と抽象構文は、主語、述語、目的語のトリプル集合をRDFグラフと定義している。語彙や関係の設計と保存形式の選択を分けることで、同じ概念体系を用途に合うデータ形式で利用できる。

1.3 関係の性質に合う論理表現

論理表現は、保持する関係の方向、数、循環の有無から選ぶ。組織の直属関係だけを扱い、各人の上司を一人に限定するならツリーで表せる。兼務やプロジェクト参加のように複数の親を許すならグラフが候補になり、ビルドの依存関係を循環のない関係として扱うならDAG（Directed Acyclic Graph、有向非巡回グラフ）を選べる。

関係の仕様には、方向、カーディナリティ、包含、循環、到達可能性のうち、クエリと検証に必要な条件を記述する。サービス一覧を属性表で表せば所有者や重要度で検索でき、依存グラフで表せば障害が波及する経路を探索できる。保持する関係と実行するクエリを定めてから論理表現を選び、その後でDB製品や保存形式を決める。

2. 関心：振る舞い・プロセス・計算を仕様にする

エンティティの属性と関係を定めた後は、状態がどう変わり、業務をどの処理へ分け、どの実行単位へ割り当てるかを仕様にする。ここでは、状態遷移、再試行するタスクの粒度、実行環境の単位を扱う。

2.1 注文状態と許される遷移

注文をid、customer_id、totalの組として表すと、ある時点の情報を扱える。注文の受付から配送までを処理するには、状態、状態を変えるイベント、遷移を許可する条件も必要になる。

受付済み → 確認済み → 決済済み → 出荷済み → 配送済み

このステートマシンでは、決済済みから出荷済みへ進める条件、取消しが可能な状態、失敗後に戻る位置を定義する。注文の属性を表す情報ビューと、注文がどう変化するかを表す振る舞いビューは、同じ注文に対する別の射影になる。

UMLの説明には、クラス図など静的な関係を表す図のほかに、アクティビティ図、ステートマシン図、シーケンス図などの振る舞いを表す図がある。statusの列挙値だけで処理を判断せず、許可する遷移と操作を振る舞いの仕様として記述することで、画面、API、バッチに同じ規則を適用できる。

2.2 タスクの粒度と再試行の範囲

注文処理で決済が完了した後に出荷処理が失敗した場合、注文受付から全体を再実行する構成では、決済の重複を防ぐ処理が必要になる。決済と出荷を別のタスクにすれば出荷だけを再試行できるが、タスク間の状態と依存関係を管理する必要がある。タスクの境界によって、再試行する処理と保持する状態が変わる。

業務プロセスでは、注文受付、在庫確認、決済、出荷、請求の順序、担当、開始条件、例外を記述する。BPMN 2.0.2仕様は、イベント、アクティビティ、ゲートウェイ、シーケンスフロー、メッセージフローを使い、組織内のプロセスと参加者間の協調を記述する。

ビジネス領域のプロセスをアプリケーションの仕様へ落とし込むときは、業務上の一つのアクティビティを、認可、記録、通知、外部サービス呼び出しなど複数の機能へ分ける場合がある。業務上のアクティビティとアプリケーションのタスクを同じ粒度にそろえず、各タスクの入力、出力、状態、再試行の開始位置を決める。

2.3 アプリケーション処理と実行環境の単位

アプリケーション処理の実行単位には、ジョブ、ステージ、タスクがある。実行環境では、プロセス、スレッド、コルーチンによって並列性とリソース共有の範囲を決める。たとえば、一回の注文集計をジョブ、分割した集計範囲をタスクとして管理し、複数のタスクを一つのプロセス内のスレッドで実行する構成を選べる。

POSIXのスレッドの概説は、スレッドをプロセスのリソースを共有しながら独自の実行状態を持つ単位として説明している。ジョブやタスクは処理の依存関係と再試行を管理する単位であり、スレッドは実行時の資源を割り当てる単位になる。

実行単位の仕様には、依存関係、並列数、取消し、タイムアウト、再試行、リソース分離のうち、処理の制御に必要な項目を落とし込む。業務プロセス、アプリケーション処理、実行環境を段階に分けることで、業務上の失敗とプロセスやスレッドの障害を別の範囲で回復できる。

3. 関心：アクセス・通信・保存の単位を決める

関心の軸には、エンティティへどう到達し、どの単位で転送し、どの単位で保存するかという問いもある。ここでは、ファイルのアクセスパス、通信単位、ストレージの配置単位を扱う。

3.1 同じファイル、複数のパス

ファイルシステムでは、/home/alice/report.mdというパスを、ルートからhome、alice、report.mdへ順に名前を解決する。ディレクトリごとに名前の範囲が分かれるため、同じconfig.jsonというローカル名を別のディレクトリで再利用できる。

ファイルのパスと実体は別の識別方法を持つ。Linuxカーネルのパス名検索の解説は、パスを構成要素へ分け、ディレクトリエントリーとinodeをたどる処理を説明している。ハードリンクでは複数のパスが同じinodeを参照でき、シンボリックリンクはパス解決に別の参照関係を加える。

ファイルを扱う仕様では、パスによるアクセス、ファイルの同一性、物理配置を区別する。パスは名前空間上のアクセス方法であり、ファイルの内容はエクステントやブロックへ配置される。

たとえば設定ファイルが/mnt/reports/current.csvを参照している場合、マウント先が変わればパスを書き換える必要がある。一方、名前や配置が変わっても同じファイルを追跡する用途なら、ファイルIDをパスとは別に持たせる構成を選べる。

3.2 通信境界ごとに変わる注文データの単位

同じ注文要求でも、処理する境界によって異なる通信単位で表される。商品Aを三個注文するという要求を例にすると、アプリケーション境界ではCreateOrderCommand、API境界ではJSONやProtocol Buffersのメッセージになり、ネットワークへ送る段階ではTCPのバイト列として扱われる。

TCPはバイトストリームを転送し、送受信の処理ではシーケンス番号を持つセグメントを扱う。RFC 9293はTCPセグメントをTCPモジュール間で転送されるデータの論理単位と定義し、シーケンス番号、確認応答番号、長さ、ウィンドウなどのフィールドを定めている。IP層では、IPv6仕様のRFC 8200に従って送信元アドレス、宛先アドレス、次ヘッダーなどを持つパケットへ包まれる。

注文メッセージには商品と数量を、TCPセグメントには順序と再送に必要な情報を、IPパケットには経路選択に必要なアドレスを持たせる。アプリケーションの仕様では注文ID、商品、数量などのペイロードを決め、通信プロトコルでは転送、分割、再送に必要な単位とメタデータを決める。

注文処理の再試行とTCPの再送は、対象も責任も異なる。アプリケーションが同じ注文を重複して登録しないための規則は、パケットの再送制御では保証できない。各領域が扱う単位と障害回復の範囲を分けて設計する必要がある。

3.3 読み書きの単位に応じた保存配置

注文レコードを保存する場合、論理仕様では注文エンティティをリレーションやドキュメントとして設計する。物理レベルではレコード、ページ、エクステント、ブロックへ配置し、分散ストレージではキー範囲やハッシュによってパーティションとシャードを決める。

列指向ファイルは、同じ論理テーブルを分析時のI/Oに合わせて物理的に射影する。Apache Parquetでは、ファイルを行グループ、列チャンク、ページという階層へ分ける。同じ列の値を近接して置くことで、必要な列だけを読み、型に合った符号化と圧縮を適用できる。

保存方式によって、読み書き、キャッシュ、レプリケーション、障害回復、整合性を適用する単位は異なる。たとえば、ページを読み書きとキャッシュの単位にし、パーティションを配置やレプリケーションの単位にする方式がある。分割後に全体を復元するなら、親の識別子、順序、オフセット、長さ、チェックサムから必要なメタデータを選ぶ。

保存配置は、後続処理が一件を更新するのか、特定の列を一括で読むのか、障害時にどの範囲を復旧するのかによって決める。論理上の注文エンティティを保ちながら、読み書きと回復に適した物理単位を設計する。

注文エンティティ、コマンド、メッセージ、パケット、レコード、ページは、各領域で別のIDと単位を持つ。同じ注文に由来するデータとして追跡するには、領域を横断する文脈が要る。

4. 領域：同じ注文を四つの設計範囲から扱う

領域の軸では、設計事項がビジネス、データ、アプリケーション、テクノロジーのどこに属するかを区別する。The Open GroupによるTOGAFとArchiMateの解説も、この四つをアーキテクチャの領域として挙げている。同じ注文を扱っていても、各領域で決める内容は異なる。

ビジネス領域で定めた受注という業務を、データ領域では注文エンティティとして管理し、アプリケーション領域ではCreateOrderCommandやAPIの仕様へ落とし込む。テクノロジー領域では、その処理とデータをプロセス、ネットワーク、DB、ストレージへ配置する。

領域は、設計が責任を持つ範囲を示す。たとえば注文メッセージの項目はアプリケーション領域、パケットの転送はテクノロジー領域に属する。成果物の形式が似ていても、変更の理由と責任が属する領域を個別に記録する。

5. 文脈：領域を横断して同じエンティティを追跡する

同じエンティティから複数の表現を作ると、ID、時点、制約、情報源、変換規則も表現ごとに分かれる。文脈には、それらを対応付け、値と判断の根拠を追跡するための情報を記録する。

5.1 名前やアドレスと同一性

会社名、ファイルパス、プロセスID、IPアドレスはエンティティを参照できるが、一対一に対応し続けるとは限らない。会社は名称を変更でき、ファイルはハードリンクによって複数のパスを持てる。プロセスIDは終了後に再利用され、IPアドレスは別のホストへ割り当て直される。

同一性の仕様では、何を同じエンティティとして扱うかに加えて、識別子の発行主体、スコープ、有効期間、再利用の有無を定める。注文番号1234がTenant AとTenant Bで別の注文を指す場合は、tenant_idとorder_idの組を使う方法と、全体で一意な注文IDへ変換する方法がある。

DBの注文レコード、APIメッセージ、ログイベントを同じ注文として追跡するには、それぞれのIDを注文IDへ紐付ける。名称や配置場所を同一性の規則として流用せず、各領域の識別子がどのエンティティを参照するかを記録する。

5.2 有効時間、記録時間、イベント順序

時間の文脈では、事実が有効だった時間、システムが記録した時間、イベント間の順序を区別する。Service Aの所有者はTeam Bであるという関係には、有効になった時点と終了した時点があり、台帳へ記録された時点はそれとは別になる。過去の日付で組織変更を登録すれば、事実の有効時間とシステムが知った時間がずれる。

現在値だけを上書きすると、過去の障害時に誰が所有者だったかを答えられない。イベント履歴から現在の状態を作る構成では、現在値を高速に取得する射影を用意し、履歴を正本として保持できる。どの時点の状態を答える必要があるかによって、保持する時刻と履歴の範囲が決まる。

分散システムでは、時計の時刻だけでイベントの順序を決められない場合がある。Leslie Lamportの論文Time, Clocks, and the Ordering of Eventsは、同じプロセス内の順序とメッセージの送受信からhappened-beforeという部分順序を定義している。互いに因果関係を持たないイベントには前後を付けない。時間を仕様へ落とし込むときは、答えるクエリに応じて有効時間、記録時間、因果順序を選ぶ。

5.3 関係と状態遷移を成立させる制約

制約は、関係や状態遷移が取り得る状態を限定する。たとえばツリーでは各ノードの親を高々一つにし、循環を禁止する。注文では決済総額が注文総額を超えないこと、契約では終了日が開始日より前にならないことが業務上の不変条件になる。

不変条件を画面の入力チェックだけへ置くと、APIやバッチなど別の更新経路から規則を破れる。どの更新経路でも同じ条件を検証できるように、DBの制約、アプリケーションの検証、状態遷移のガードなど、規則を実施する場所と責任を定める必要がある。

用途別の射影にも、変換後に保持する制約がある。グラフとリレーションのどちらを選んでも、カーディナリティ、一意性、参照整合性、時間の前後関係を検証できる。制約記述言語SHACLは、RDFグラフに対する形状と制約を記述し、データグラフを検証する仕組みを定めている。制約の内容と検証する場所を文脈として記録することで、同じ規則を複数の表現と更新経路へ適用できる。

5.4 判断を再検証するための出自とバージョン

統合した値を検証できるようにするには、情報源、観測時刻、選択規則を残す必要がある。たとえば構成管理台帳では、サービスの所有者をCMDBがPlatform Team、リポジトリのCODEOWNERSがCore Team、サービスカタログがInfrastructure Teamと記録している場合がある。統合処理で一つの値を選ぶなら、採用した情報源と選択規則も記録する。

W3CのPROVデータモデルは、データや物の生成に関与したエンティティ、活動、実行主体の情報を出自として表す。元の記録、変換処理、実行主体を別々に構造化するため、派生値がどの入力と活動から生まれたかをたどれる。

名寄せやAI抽出では、観測事実と推論結果を分ける必要がある。二つのレコードが同じ法人らしいという判定を再評価するなら、比較した属性、モデルまたは規則のバージョン、スコア、判定時刻を記録する。判定結果だけを事実として保存すると、規則を修正した後に再評価すべきレコードを見つけられない。

バージョンを管理する対象には、エンティティの状態、スキーマ、オントロジー、プロトコル、ファイル形式、変換規則がある。たとえば、エンティティの履歴を識別するentity_version、適用したスキーマを示すschema_version、変換規則を示すrule_version、派生データの作り方を示すprojection_versionを使い分けられる。すべてを同じversionというフィールドへまとめると、何を更新した番号か分からなくなる。

複数の射影を独立に更新しながら同じ事実を扱うには、各射影が参照するエンティティ、時点、制約、情報源、変換規則のバージョンを文脈として記録する。入力、判断、変換、出力を紐付けておけば、規則の変更後に影響するデータを特定し、同じ条件で射影を再構築できる。

同じエンティティでも、関心と領域によって表現する単位が変わる。

次回は、クエリに合う表現形式と、変換後の再構築・運用を扱う。