📌 目次

この記事を書いたきっかけ
MDA(メタデータ駆動型アーキテクチャ)の概要
コードをMDAでシステム設計する
10年くらい先の生成AIに期待できること
20年くらい先の生成AIに期待できること
次回書きたい記事

①この記事を書いたきっかけ

バックエンドプログラムのコード開発と設計書の作成をしていたときに、ほとんどのコードはメタデータとして扱うことができて、複雑な設計書が動的に作成できると考えました。私が思いつくロジックは誰かが考案していると思うので、設計書作成業務が簡単な仕事とされる時代がすぐ来るかもしれません。設計書作成はクリエイティブではない作業で正確さも担保されていないものが世の中にたくさんあると思うので、早く時代が追い付いてほしいと思っています。

②MDA(メタデータ駆動型アーキテクチャ)の概要

コーディング以外のMDAを例に挙げると、ゲームのオプション画面がそうです。ユーザーが設定（メタデータ）を変更するだけで、ゲームの挙動が変わるようになっています。内部的には設定ファイルやデータベースに保存されたメタデータを変更することで制御しています。

グラフィック設定（解像度、テクスチャ品質、シャドウのON/OFF）
操作設定（キーバインド、コントローラーの感度）
サウンド設定（BGMやSEの音量調整）

ゲームの内部処理をMDAで開発していて、2K(2048x1080)の値を選択できるように仕様変更することになったとします。画面サイズ設定で以下のように処理していると仮定すると、設定ファイルの画面サイズの選択肢を増やすだけで仕様変更が完了します。

[オブジェクト名: screen_size, 値: full_hd]を選択
設定ファイルに[オブジェクト名: screen_size, 値: True]を設定
画面サイズを定義しているプログラムが設定ファイルを参照する

これがMDAでないときの例を挙げると、選択できる画面サイズの一覧をコード内に埋め込むことでも同じ機能を実現できます。修正時にはコードを修正します。

MDAのデメリットは、コードのファイル以外に設定ファイルが増えることと、設定ファイルの実態がコードを見ただけでは分からないことです。

③コードをMDAでシステム設計する

コードは3つの要素で構成されます。このうち、実行単位と変数は簡単にメタデータ化できます。

要素	説明	例(MySQLのストアド)
実行単位	SQL文やトランザクション	SELECT、INSERT、UPDATE
制御構造	処理の流れを制御	IF、LOOP、CASE
変数・データ構造	データの保持や管理	DECLARE、SET

例としてMySQLのストアドを実行単位でメタデータをDBに格納しました。

SET variable_value = INSERT INTO Tbl_A (Column) VALUES (0);

program_name	flag_A
execution_order	1
input_table	NULL
input_statement	NULL
variable_name	variable_value
input_variable	INSERT INTO Tbl_A (Column) VALUES (0)
output_table	NULL
output_statement	NULL
explanation	Store the execution flag of process A in a variable

ストアドでは、テーブルのprogram_nameをキーに、[input_statement, output_statement, input_variable]のうちNULLではない値を呼び出して実行するとします。

開発後には、どのストアドでどの順番でどの処理が走っているかを、動的に分析できるデータベースが出来上がります。

MDAによって自動作成の恩恵を受ける設計書一覧

(前回の記事の設計書一覧です)

No	設計書・図の名称	自動作成
1	仕様書	✕
2	マッピング表	〇
3	システムフロー図	△
4	ER図	〇
5	データフロー図	△
6	データリネージ図	〇
7	ストアドプロシージャI/O定義書	〇
8	AWS ECS変換レポート	✕
9	システム構成図	✕
10	業務フロー図	✕
11	アプリケーション機能一覧	✕
12	画面遷移図	✕
13	API仕様書	△
14	バッチ処理一覧	〇
15	テーブル定義書	〇
16	インデックス設計書	〇
17	データ移行計画書	✕
18	データマッピング定義書	〇
19	データクリーニング方針書	✕
20	移行スクリプト一覧	〇
21	運用設計書	✕

制御構造のメタデータ化

Pythonは以下のように変数で格納したFor文を簡単に実行できるので、メタデータ化も容易といえます。しかしシンプルに表現できる言語は限られます。SQLのCURSORはとても複雑な書き方になるでしょう。

loop_control = "for i in range(5):"
code_to_execute = "print(i * 2)"
exec(f"{loop_control}\n    {code_to_execute}")

出力:
0
2
4
6
8

④10年くらい先の生成AIに期待できること

生成AIのコード解析方法は、以下のような流れです。

構文解析: 抽象構文木（AST: Abstract Syntax Tree) で単語の意味を理解する
コード分析: 変数や演算を追跡したデータフロー解析。制御構造の解析。ただし、コードの実行機能がないため、演算や推論が正確とは限らない。

現状の生成AIによる解析方法はまだ原始的で場当たり的です。コードを書いて分析を命令するだけでは情報が足りません。しかし、以下の条件が組み合わされば、正確な設計書作成の自動化が実現可能になるはずです。

No	改善事項	説明
1	実行環境の全情報をエクスポートするスクリプトの開発	OS、プログラミング言語、ライブラリ、依存関係などを取得するPowerShellスクリプトなどの開発
2	開発対象のAPI仕様がSwaggerなどで管理されていること	APIの仕様が統一されたフォーマットで提供されている
3	生成AIがデバッグ機能を実装する	言語 (Python、JavaScript、SQL) とライブラリの情報を持ち、実際にコードを実行して解析できる
4	コード解析のノウハウの確立	構文解析・データフロー解析をさらに精密に行える方法の確立
5	設計図の作図機能の追加	コード解析結果からER図やデータフロー図を自動生成する
6	Gitへのアクセス機能	生成AIがGitのリポジトリを解析し、複数ファイルの関係性を把握できる

⑤20年くらい先の生成AIに期待できること

コーディングが関係するアーキテクチャは、以下のようにさまざまな種類があります。

アーキテクチャ名	概要
MDA（メタデータ駆動型アーキテクチャ）	設定ファイル（JSON, XMLなど）を基にコードを自動生成し、記述を最小化する。
モジュール型アーキテクチャ	独立したモジュール単位でコードを分割し、再利用性や変更のしやすさを向上させる。
MVC（Model-View-Controller）	「モデル（データ）」「ビュー（表示）」「コントローラ（制御）」にコードを分割する。
MVVM（Model-View-ViewModel）	UIとロジックを分離し、データバインディングを活用してコードの結合度を下げる。
クリーンアーキテクチャ	ビジネスロジックを中心に置き、UIやDBなどの技術要素とコードを分離する。
ドメイン駆動設計（DDD）	業務ロジックをオブジェクト指向で整理し、コードにドメイン（業務概念）を忠実に反映させる。
関数型プログラミングアーキテクチャ	副作用を排除し、関数型のコード構造を用いて可読性と保守性を向上させる。

私が③で説明した開発方法は、後から機械的にコードを分析しやすさに特化したものです。そのため、生成AIによって以下のような変換が機械的に可能になるはずです。

別のアーキテクチャへの自動変換: MDAをMVCに変換するなど、異なるアーキテクチャ間の移行が可能
モジュール化されていないコードへの変換: すべての機能を1つのスクリプトに統合する（設定ファイル不要）

これにより、柔軟なアーキテクチャの選択が可能になり、開発者が目的に応じたコードスタイルを選択できる未来が期待されます。

⑥次回書きたい記事

前回の記事で紹介したDB移行で使えるツールについて書こうかと思っています。
✅ AWS SCTの紹介