1. トポロジー契約チェーンと宣言駆動グラフアーキテクチャ
業務アプリ制作の本質は、「ドメイン知識」と「システム制約」のみがソースであり、これをどう整理し、どうコードに落とし込むかというプロセスであると言い換えられます。
こういった課題に対して、DDD（ドメイン駆動設計）は非常に強力なアプローチとして定着してきました。しかし、DDDのプロセスは本質的にステップワイズ（段階的）であり、ドメインやテーブルを確定してから次のステップに進みます。あとから要件が増えると最悪にはやり直しとなり、複雑な依存関係があったとしても「グラフ構造」として構築しているわけではありません。知識や制約が網の目のように絡み合う現代のアプリケーションにおいて、この手続き型に向かって線形的なアプローチは徐々に限界を迎えつつあります。
本来、ドメイン知識は概念同士が絡み合うグラフ構造です。同様に、業務アプリのロジックもデータと処理の依存グラフとして表現でき、UI/UXの制御も状態遷移のグラフとして表現できます。つまり、各レイヤーはすべて「有向非巡回グラフ（DAG）」という共通の構造を持っているのです。
私たちは、この「奇妙な一致」を利用できないかと考えました。
例として3Dプリンターのフィラメントを管理するアプリを考えましょう。要件を書きだします。
3Dプリンターフィラメントを管理するアプリ。
重量を測って残りの量を算出する。
乾燥した日付と温度と時間を記録する。
ギャラリーは素材別フィルターがある。
素材の色と残量が横棒グラフで表示される。
メーカー、素材、フィラー、スプール材質、カタログ重量。
乾燥時は素材別推奨温度を表示するがスプールによる制限をかける。
Power AppsとShare Point Listsを使用する。
業務アプリがドメイン知識に依存し、UI/UXがアプリのルールに依存するのであれば、レイヤー間にもDAGが成立します。結果として出来上がるのは、要件から画面の振る舞いまでが強固に結びついた「立体的な依存グラフ」です。これをロジカルに処理できるなら、AIが自動的に計算できるはずです。
つまり宣言的プロンプトが業務要件という宣言からノードとエッジを抽出し、依存グラフとして構築し、それをそのままアプリケーションに適用することができないものか。これが「宣言駆動グラフアーキテクチャ」の理想です。
本記事では、このドメイン知識である自然文からアプリを意味する依存グラフまでをシームレスに繋ぐ「トポロジー契約チェーン(TCC)」という推論エンジンについて解説します。
2. 依存グラフを出力するTCCのコア
しかし、依存グラフを中心に据えたアプリケーション構築の試みは、決して新しいアイデアではありません。むしろ古くから研究されてきた領域です。実際に同期型データフロー言語(Lustre)やフローベースプログラミング(Node-RED)が存在し、依存グラフからコードを生成する言語もあります。
それにもかかわらず、なぜ依存グラフは長年放置されてきたのか。理由はシンプルです。
「完成すれば強力だが、完成させるのが極めて困難」だったからです。
従来のグラフ構造計算は、すべてのピースが揃った「正解」を入力すれば正しく機能します。しかし、開発途中で情報がわずかでも不足していると、システムはただエラーを吐いて停止するだけでした。どこがどう狂っているのか、原因の特定すら困難で、実質的に手の施しようがなかったのです。未完成を許容できない硬直性が、このアプローチの最大のボトルネックでした。
この「構築不可能の壁」を打ち破るために策定したのが、以下の3つの基本ルールです。
2-1. 依存グラフ（構造）
あらゆる要素やタスクの接続関係（トポロジー）を記述する骨格です。何が何に依存しているかを厳密に中央管理します。これにより、ドメイン知識からUI/UXにいたる立体的なつながりが破綻なく定義されます。これを完成させることが目標です。
2-2. 遅延評価（制御）
すべての計算や処理を「必要になったその瞬間」まで実行しない仕組みです。無駄な先行計算を徹底的に排除すると同時に、一部のデータやルールが動的に変化しても、システム全体が即座に矛盾なく追従することを可能にします。TCCではさらにプレースホルダを使用して「まだ観測されていない（Unknown）」「一旦仮説として置いておく（Hypothesis）」というグラフ構造を仮の形で保持し保留できます。
2-3. Human in the Loop Graph Completion（調停）
グラフの評価が不完全なとき、人間が指示を与え解決する仕組みです。これこそが、「情報不足による即停止」を回避したうえで解決する手段となります。データやルールが足りないノードに到達した際、システムは遅延評価で保留され、人間がAIを使った対話で仮説の判断やドメイン知識を注入し、依存グラフの評価を再開します。このタイミングではAIにより作成されたプレースホルダの名称を訂正したり、AIが出す選択肢を指定することもできます。
AIはグラフ評価のランタイムをエミュレートして、「構造」として網の目を定義します。このときエッジを契約による設計(DbC)のインターフェイスとして機能します。だからこそ、途中に不明なノードがあったとしても前後の契約関係から「そこにあるべきデータの性質」を逆算して推測できるのです。
さらに「制御」においては「希望の箱」と呼ばれるプレースホルダを活用し、未完成の不確実な状態をエラーにすることなく安全に保留します。そして最終的に「調停」が依存グラフの不完全を動的に解決します。
これら「構造」「制御」「調停」の3つが揃うことで、かつて机上の空論だった依存グラフの動的解決が現実のものとなります。全体のトポロジー(接続構造）は契約に従ってドミノ倒しのように連続的に解決され、不完全だった依存グラフは確定的な形へと姿を変えます。これにより、TCCは机上の理想論から脱却し 「いま、目の前で実用できる推論エンジン」へと昇格したのです。
💡 あわせて読みたい（補足）
本稿で触れていませんが「宣言型と命令型との比較」の詳細や、TCCのさらに具体的動作の説明、タイプ別実装方法については、過去バージョンの記事を再投稿した『【補足】「Topological Contract Chain」トポロジー契約チェーンの背景』で一歩踏み込んで解説しています。具体的なコードの組み方等に興味がある方は、こちらの補足も参考にしてください。
3．動作事例
例として、3Dプリンター用フィラメント設計時の応答の一部を掲載します。
トポロジカルソートの結果
Requires: 現在の測定重量, カログ重量（正味量）, 【空白：スプール単体重量（風袋）】
これは現在のネット重量を算出するためには現在の測定重量「以外にスプール単体重量が必要(とAIが推測)」だが、それがどうやって決めるのか情報が無いため空白となり、評価が保留されます。
サスペンド
残量算出における風袋（スプール重量）の扱い 「重量を測って残量を算出する」際、
実測値にはスプール自体の重量が含まれます。このスプール重量はどのようにシステムへ与えられますか？
- (A) カタログ重量とは別に、スプール単体の重量（例：200g等）をユーザーが手動入力する
- (B) スプール材質やメーカーごとに、システム側で標準的なスプール重量のマスタ（辞書）を持つ
この文はAIが作成しています。候補もAIが考えました。
ドメイン情報の入力
「スプール重量は不明です。グロスを測定し、カタログ重量をネット推算値とすれば、その差がスプール重量だと思っている。」
AIの理解
「新品時のグロス（総重量）計測によってスプール重量（風袋）を逆算・同定する」
という動的状態（State）のエッジ
グロスという単語が「新品時のグロス（総重量）」と解釈されています。
ドメインの追加
新品登録時の初期総重量（Wgross, initial）からカタログ重量（Wcatalog）を減算し、個体ごとのスプール固有重量（Wspool）を固定値として自律同定する。
Formula: Wspool=Wgross, initial−Wcatalog
ドメイン知識がここに残ります。スプール重量計算はここにしか書かれていません。
ステート
Node: NetVolumeCalculated
Current Net Weight: Wnet=Wgross, current−Wspool
スプール重量を用い、派生値を計算してネット重量とする。
エッジと契約
%% 2. Domain & Input -> State
N_St_InitialRegistration -->|初期総重量| N_Dom_SpoolWeightId
N_Dom_SpoolWeightId -->|W_spool = W_gross,initial - W_catalog| N_St_SpoolWeightFixed
エッジごとの契約
Edge: InitialRegistration ──> SpoolWeightFixed
Requires: ユーザーによる「新品時の総重量（Wgross, initial）」の入力、および「カタログ重量（Wcatalog）」の存在。
Provides: 減算による固有スプール重量（Wspool）の決定。以後のライフサイクルにおける風袋の固定値化。
💡 あわせて読みたい（動作ログ）
具体的なカスタム指示の生成からドメイン知識の入力、AIとの対話、出力された依存グラフなど、一連の動作ログと簡単な解説を記事にまとめています。こちらの資料も参考にしてください。
4. TCCの「4つの発明」
この手法がソフトウェア開発にもたらすブレイクポイントの本質は、次の4つの発明に集約されます。
4-1. 依存グラフと「人」のインターフェースとしてLLMを配置したこと
過去のグラフ駆動開発が挫折したのは、システムが「完璧な入力」しか受け付けず、少しの情報不足で即座にクラッシュしていたからです。TCCでは、曖昧な日常言語と厳密なトポロジーの「結び目」としてLLMを配置しました。LLMは単なるテキスト生成器ではなく、足りない知識を補完し、文脈を解釈してグラフの欠落を埋める「動的な調停者」として機能します。
4-2. 「ドメイン知識の追加」が単なる「再評価」になったこと
従来の手続き型開発では、新しいルールが増えるたびに「既存コードのどこに差し込むか」「どこに影響が出るか」を人間が配慮する必要がありました。TCCは完全な宣言型であるため、新しい知識（ノード）をグラフに記述するだけで完了します。あとは遅延評価ランタイムが自動的にトポロジーを組み替え、必要になった瞬間に「再評価」するだけ。
4-3. アプリの末端（UI/UX）までトポロジーで解決できること
このアーキテクチャは、バックエンドのロジック層だけで完結しません。画面のボタンの活性・非活性、入力項目の表示・非表示といったUI/UXの制御まで、すべて同じ「立体的な依存グラフ」の末端ノードとして組み込まれます。データの変化がそのままUIの振る舞いへと波及するため、画面制御のための泥臭い条件分岐コードが一切不要になります。
4-4. 「設計」と「実装」の距離が極限まで近いこと
日常の言葉でドメイン知識と制約を記述すれば、それがそのまま依存グラフ（＝アプリの構造）になります。「仕様書を書いて、それをエンジニアがコードに翻訳する」というステップが消滅します。設計図そのものが動くランタイムとなるため、ビジネス側の意図が100%の純度でそのままシステムに昇華されます。
5.メリットと制限
不完全な状態（グラフ）でも、その場所で調和を保ってランタイムが動き続ける。この「宣言型トポロジー」の性質によって、私たちは開発を支配していた「時間軸（シーケンス）」から解放されるのです。しかしその一方でこのシステムを破壊しかねない指示については制限があるため回避させる。
メリット：「時間」からの解放
思考や実行の「時間軸（ステップ）」という概念から脱却します。
5-1.ドメインの入力順序を気にする必要はない
「どのルールから順番に定義するか」を悩む時間は不要です。処理はトポロジカルソートで上から下に流れるだけではなく、遅延評価によって「必要になったものから逆引きで駆動」します。思いついたドメイン知識、あるいは判明したシステム制約から、順不同でグラフに投げ込んで構いません。
5-2.最初から「完璧なグラフ」を目指さない
仕様の全容が明らかにならないからと言って手を止めないでください。TCCには「Human in the Loop（調停）」があります。情報が足りない部分は実行時にLLMや人間がその場で補完すればよいため、「動かしながらグラフを育てていく」アプローチが正解です。
5-3.循環参照（ループ）は厳禁（AIが検知・修正を要求）
各レイヤーが「DAG（有向非巡回グラフ）」である以上、依存のベクトルがぐるぐると輪を描く循環関係を作った瞬間にシステムは解決できなくなります。ただし、人間がこれを完璧に防ぐ必要はありません。依存グラフを評価する推論エンジン（AI）がトポロジーの破綻を検知し、即座にユーザーへ修正を要求します。TCCはビジネスアプリケーション開発を目標としています。ビジネスルールは決定的な依存関係の方向を定義していると期待しているため、実行可能仕様をDAGとして表現できます。反復数値手法、動的シミュレーション、または不動点計算を必要とする領域は、本研究の範囲外です。
制限：アンチパターンから「宣言型」への転換
「どう動かすか」ではなく、「どうあるべきか」の定義に集中します。
5-4.コードを書いてはならない
ノードの内部にIf文の乱発やForループなどの命令的コードを書いた瞬間、アーキテクチャは硬直した過去のシステムへ逆戻りします。開発とは、ロジックを命令することではなく「要素間の関係性（トポロジー）を宣言すること」です。
5-5.「副作用」を持つ手続きを混ぜてはならない
遅延評価は「いつ、何度評価しても同じ結果になること（べき等性）」が前提です。手動でグローバル状態の書き換えや外部DBの更新といった副作用を起こすと、グラフ全体の動作が予測不能になります。純粋な宣言型を維持するため、副作用を手続き的に実行してはなりません。副作用は依存グラフの評価結果としてのみ発生するよう設計し、評価グラフの境界に配置します。
5-6.「いつ実行されるか」を人間が制御しようとしてはならない
「このボタンを押したから、次にこの処理を走らせる」という時間的な順序制御を放棄してください。すべては遅延評価ランタイムの判断で動きます。人間は「何が何に依存しているか」という不変の事実だけを管理し、実行タイミングのコントロールはシステムに完全に委ねます。
5-7.命令的入力はエッジへ変換される
- ユーザーの入力情報に、手続き的な指定やコードのロジックが含まれていた場合、エンジンはそれをそのままグラフ構造に組み込んではなりません。エンジンは入力された「手続き」を解釈し、「本質的に何と何が依存関係にあるのか」という『エッジ（トポロジー）』へと自動的に変換・抽出します。
- 宣言型代替手段のユーザーへのフィードバック手続きを勝手に解釈して埋め込むだけでなく、エンジンはユーザーに対して「宣言型の代替手段」を提示し、自発的なトポロジーの修正を促します。エンジンの応答例（協調的インターフェース）：「入力された『Aの処理が終わったらBをループで回す』という手続きは、TCCの構造に適合しません。これは【要素Bが要素Aの状態変化に依存している（$A \rightarrow B$ のエッジ）】と解釈し、トポロジーを再評価しました。次回からは『BはAの最新状態を常に参照する』という宣言の形での記述を推奨します」
5.宣言型の本質へ— 理想と現実のミッシングリンク
「ローコードだから、適当に動くものを手早く作れればそれでいい」
宣言駆動グラフアーキテクチャは、そういう安易な妥協を目指さない。Power Appsは単なるローコードではない。最新の宣言型ランタイムを備えており、あらゆる判断をリアルタイムで行い、画面の見た目すらリアクティブに制御できる。私たちが手に入れたTCC（トポロジー契約チェーン）というパラダイムは、Power Appsをローコードという「プログラミングができない人のための妥協の道具」ではなく、「だれも到達できなかった、極限のアジリティを具現化する最強の宣言型ランタイム」として利用します。
ユーザーはドメイン知識を語るだけ、AIはそれを整理し、足りない関係を見つけ、ユーザーに確認する。暴走の予感もなく、ソフトウェアは依存グラフとして静かに完成する。
しかし、ここで私たちは冷徹な「現在地」で現実の段差に直面する。
プラットフォームの限界と、泥臭い現在地
本来、この宣言型パラダイムにおいて最もふさわしい器であるはずのPower Appsだが、現実にはまだ「依存グラフをシステムへ自動的に移植・抽出する」といったエコシステムは整備されていない。理想に対して、インフラが追いついていないのだ。
TCCという推論エンジン（動的ロジック）はすでに完成している。しかし、それを支えるべき「宣言駆動グラフアーキテクチャ」を100%ネイティブに回せるプラットフォームは、世界を見渡してもまだ最適な形で存在していない。
だからこそ、現在は「変換エンジン」による応急処置でこの段差を繋ぐしかない。手動のブリッジを噛ませてでも、TCCのロジックを利用し、現行のシステムを駆動させる。この泥臭い実践こそが、過渡期におけるエンジニアリングのリアルである。
「依存グラフエコシステム」が業務アプリを統一する未来
だが、この段差が埋まる未来の予感は、すでにすぐそこまで来ている。
仕様や依存関係の構造を、YAMLのような宣言型データとしてLLMに生成させるアプローチは、現在の高度なAI（Copilotや推論特化型モデル）の最も得意とする領域だ。AIは、手続き型コードの生成よりも、契約で縛られた「静的な依存関係（グラフ）」を出力させる方が得意だ。
やがて自動化の架け橋が完成し、すべてが「依存グラフ」という共通言語で記述され流通する「依存グラフエコシステム」が誕生するだろう。
そのとき、UIがPower AppsだろうがWebフロントだろうが、DBが何であろうが関係なくなる。業務アプリケーションの本質はすべてグラフの結合と組み替えだけで統治され、泥臭い手続きコードは世界から一掃される。
私たちは今、その業務アプリ天下統一の、まさに前夜に立っている。
6.おわりに：【自己言及のDAG】思想の宣言が、システムを導出する
「概念としては面白いが、そんな高度なシステムプロンプトやカスタム指示を、人間がメンテナンスし続けられるのか？」という懸念を抱くかもしれない。
ここで、本アーキテクチャが持つ最も核心的なルールを再度適用する。
本記事では、「TCC評価エンジン規約」の具体的なプロンプトコード（手続き）は一切公開しない。
なぜなら、「こういうプロンプトを書けば動く」という手順を提示した瞬間、それは読者を再び「手続き型（命令型）」の思考へ逆戻りさせてしまうからだ。TCCというエンジンそのものを手続きで縛ることは、自己矛盾でしかない。
今、あなたが読んでいるこの文字、この記事のテキストそのものが、TCCにおける「ドメイン知識」であり、思想という名のカーネルである。本記事に記述された「構造・制御・調停」のメカニズム、「依存関係をソートせよ」「空白があればサスペンドせよ」という契約関係を、そのままAI（LLM）に読み込ませてみてほしい。そして、こう問いかけるのだ。
「この思想を内包した、TCC評価エンジンを駆動するシステムプロンプト（YAML/規約）を導出せよ」
第5章で述べた通り、AIはステップバイステップの手続きを書かせるよりも、規約と依存関係で縛られた「静的な構造」を出力させるタスクにおいて、最高のパフォーマンスを発揮する。AIは言葉の背後にある意味論（アテンション）を解釈し、自律的な再計算の結果として、完璧に駆動するTCCのランタイム環境を自ら導出する。
人間が与えるべきは、プロンプトハックという名の手続きではない。「思想の宣言」だけだ。
あとはAIという推論器にドメイン知識を語り、エッジを契約で連結させ、システムというグラフを紡ぎ出す。
変換エンジンで段差を埋める現在地から、依存グラフエコシステムが業務アプリを統一する未来へ。この自己組織化のチェーン（DAG）を回し始めたとき、AIと人間が真に対等なパートナーとしてソフトウェアを共創する、新しい開発のパラダイムが幕を開ける。