1. 背景と課題：ソフトウェア設計におけるネットワークの関係性
私は、業務要件から堅牢なローコードソフトウェア構造を構築したプロセスを振り返った。ソフトウェア設計を最も簡単に表現すると「ドメインモデル」と「システム制約」のみが情報源で、これを基礎とする ネットワーク構造 をくみ上げているだけである。
ソフトウェアの大半がデータフローをネットワーク構造表現できると言えるのは1970年頃の文献[1]にある通り、情報という「ノード（要素）」を「エッジ（関係性）」がつなぎ、その過程で情報が変換され次の情報というノードに変化する。分岐や合流があるため、グラフ構造として表現可能である。
人間の業務もまた、「Aの情報が存在するとBのルールに基づく判断基準が適用され、Cが導出される」という関係性のネットワークであり情報をリレーするダイアグラムを書ける。
ここで奇妙な一致 に気が付いた。ソフトウェアはノードとエッジを持つDAGである。人間の業務フローもDAGである。ついでに言うとソフトウェア設計も基礎情報とシステム制約というルールで判断した結果としてソフトウェアを構築するDAGであると言える。
しかし実際のプログラミングの多くは、要件定義の段階ではグラフ構造として把握できるはずの業務知識を、実装の初期段階において情報ノードを作成するが、それ以外の情報からネットワーク構造を構築することなく、時系列の手順（手続き型コード）でノードを直接利用している。同時に存在したはずのエッジである情報が生かされず、プログラマは業務要件を根拠に、その場その場の判断ロジックを書くことになる。残念なことに、仕様変更などが発生すると、以前のエッジと変更後のエッジを比較したくなるが、その情報は記録されていないため、その場その場の判断ロジックをどう修正するかを考えることになる。これでは全体の見通しがつかず、必要な情報をつなげられないのも無理はない。
私たちは、この 「奇妙な一致」 を利用できないかと考えました。つまり業務プロセスをいきなりコードに書くのではなく、DAGとして表現して、それをソフトウェアの構造として利用し、DAGからコードに変換するのです。
例として3Dプリンターのフィラメントを管理するアプリを考えましょう。要件を書きだします。
3Dプリンターフィラメントを管理するアプリ。
重量を測って残りの量を算出する。
乾燥した日付と温度と時間を記録する。
ギャラリーは素材別フィルターがある。
素材の色と残量が横棒グラフで表示される。
メーカー、素材、フィラー、スプール材質、カタログ重量。
乾燥時は素材別推奨温度を表示するがスプールによる制限をかける。
Power AppsとShare Point Listsを使用する。
つまり業務要件からノードとエッジを抽出し、依存グラフとして構築し、それをそのままアプリケーションにする。これが「グラフアーキテクチャ」の理想です。
本記事では、自然文で書いたドメイン知識から、アプリ構造の依存グラフを直接変換する「トポロジー契約チェーン(TCC)」という推論エンジンについて解説します。
[1] “First Version of a Data Flow Procedure Language” (1974)
2. 中核理論：Topological Contract Chain（TCC）の構造
しかし、グラフアーキテクチャを中心に据えたアプリケーション構築の試みは、決して新しいアイデアではありません。むしろ古くから研究されてきた領域です。実際に同期型データフロー言語(Lustre)やフローベースプログラミング(Node-RED)が存在し、依存グラフからコードを生成する言語や、コードからDAGを生成する言語もあります。
それにもかかわらず、なぜドメインモデルから直接DAG生成 は長年放置されてきたのか。理由はシンプルです。
「完成すれば強力だが、完成させるのが極めて困難 」だったからです。
従来のグラフ構造計算(networkx)は、すべてのピースが揃った「正解」を入力すれば正しく機能します。しかし、開発途中で情報がわずかでも不足していると、システムはただエラーを吐いて停止するだけでした。どこで何が不足しているのか、原因の特定すら困難で、実質的に手の施しようがなかったのです。未完成を許容できない硬直性が、このアプローチの最大のボトルネックでした。
この「構築不可能の壁」を打ち破るために策定したのが、以下の3つの基本ルールです。
2-1. 目的：プリケーションとしてのDAG構造の完成（構造）
DAG構造は、あらゆる要素やプロセスの接続関係（トポロジー）を記述した骨格です。何が何に依存して何が求まるのかを記述します。業務における一つのプロセスを一つのエッジとして表現します。すべてのエッジが契約による設計(DbC)のインターフェイスであり、プロセスの実体である関数（射）を含みます。これにより、ドメイン知識からデータパイプラインが破綻なく定義できます。これを完成させることがTCCの目的です。
2-2. 課題発見：サスペンド（制御）
networkxはエラーを検出すると計算を終了しますが、そこをうまく回避するためにサスペンド・ルールを導入します。「希望の箱」を使用して保留（サスペンド）することができます。そしてこれを解決しないと目的が完成しないので一時的に課題として記録します。
2-3. 解決手段：Human in the Loop Graph Completion（調停）
AIはグラフ評価のランタイムをエミュレートして、「構造」として網の目を定義します。
グラフの評価が不完全なとき、希望の箱を利用してサスペンドします。
ここでLLMはユーザーからの入力を受け付けます。入力内容が希望の箱を置き換えることができるなら、評価のサスペンドを解除して再評価を始めます。
これら「構造」「制御」「調停」の3つが揃うことで、かつて机上の空論だった依存グラフの動的解決が現実のものとなります。人間は分かっている部分だけを伝え、LLMは理解できるところまで整理する。そして不明な情報があれば人間の入力を待ち、データフローDAGが完成するまで評価を繰り替えすのです。全体のトポロジー(接続構造）は契約のチェーン構造で連続的に解決され、不完全だった依存グラフは確定的な形へと姿を変えます。
3．動作事例
例として、3Dプリンター用フィラメント設計時の応答の一部を掲載します。
トポロジカルソートの結果
Requires: 【空白：スプール単体重量（風袋）】
これは現在のネット重量を算出するためには現在の測定重量以外にスプール単体重量が必要だが、それがどうやって決めるのか情報が無いため空白となり、評価が保留されます。
サスペンド
残量算出における風袋（スプール重量）の扱い 「重量を測って残量を算出する」際、
このスプール重量はどのようにシステムへ与えられますか？
AIが作成した文の一部を表示しています。
ドメイン情報の入力
「グロス値からカタログ重量を減算、その値がスプール重量」
AIの理解
「新品時のグロス（総重量）計測によってスプール重量（風袋）を逆算・同定する」
という動的状態（State）のエッジ
グロスという単語が「新品時のグロス（総重量）」と解釈されています。
ドメインの追加
Formula: Wspool=Wgross, initial−Wcatalog
スプール重量計算はここにしか書かれていません。
ステート
Node: NetVolumeCalculated
Current Net Weight: Wnet=Wgross, current−Wspool
スプール重量を用い、派生値を計算してネット重量とする。
4. TCCの「4つの発明」
この手法がソフトウェア開発にもたらすブレイクポイントの本質は、次の4つの発明に集約されます。
4-1. インターフェースとしてLLMを配置したこと
過去のグラフ駆動開発が挫折したのは、システムが「完璧な入力」しか受け付けず、少しの情報不足で即座にクラッシュしていたからです。TCCでは、曖昧な自然文と厳密なトポロジーの「通訳」としてLLMを配置しました。LLMは単なるテキスト生成器ではなく、文脈を解釈してグラフの欠落を埋める「動的な調停者」として機能します。
4-2. 「ドメイン知識の追加」が単なる「再評価」になったこと
従来の手続き型開発では、新しいルールが増えるたびに「既存コードのどこに差し込むか」「どこに影響が出るか」を人間が配慮していました。TCCは完全な宣言型であるため、新しい知識（ノード）とエッジをグラフに記述するだけで完了します。あとはLLMが自動的にトポロジーを組み替え、「再評価」するだけ。
4-3. アプリの末端（UI/UX）までトポロジーで解決できること
このアーキテクチャは、バックエンドのロジック層だけにとどまりません。画面のボタンの活性・非活性、入力項目の表示・非表示といったUI/UXの制御まで、すべて同じ「依存グラフ」の制御層として組み込まれます。データの変化がそのままUIの振る舞いへと波及するため、画面制御のための泥臭い条件分岐コードが一切不要になります。
4-4. 「設計」と「実装」の距離が極限まで近いこと
自然文でドメイン知識と制約を記述すれば、それがそのままデータフローDAG（＝アプリの構造）になります。「仕様書を書いて、それをエンジニアが見てコードに翻訳する」というステップが消滅します。エッジそのものがプロセスとなるため、ビジネス側の意図が100%の純度でそのままシステムに昇華されます。
5.TCCのメリットと制限
不完全なグラフでも、サスペンドして再評価する。このTCCの性質によって、私たちは開発を支配していた「時間軸（シーケンス）」から解放されるのです。しかしその一方でこのシステムを止めるコードがあるため、方針として留意する必要がある。
メリット：「時間軸」からの解放
思考や実行の「時間軸（シーケンス）」という概念から脱却します。
5-1.ドメイン知識の入力順序を気にする必要はない
「どのルールから順番に定義するか」を悩む時間は不要です。処理はトポロジカルソートで上から下に流れるだけではなく、遅延評価によって「必要になったものから逆引きで駆動」します。思いついたドメイン知識、あるいは判明したシステム制約から、順不同でLLMに投げ込んで構いません。入力順序や処理順序という「時間軸（シーケンス）」がなくなりました。
5-2.最初から「完璧なグラフ」を目指さない
仕様の全容が明らかにならないからと言って手を止めない。TCCにはサスペンド・ルールがあります。情報が足りない部分は人間が後から補完すればよいため、「確認しながらグラフを育てていく」アプローチができます。完成してから評価するという「時間軸（シーケンス）」がなくなりました。
5-3.循環参照（ループ）は厳禁（AIが検知・修正を要求）
「DAG（有向非巡回グラフ）」である以上、依存のベクトルがぐるぐると輪を描く循環関係を作った瞬間にシステムは解決できなくなります。ただし、人間がこれをあらかじめ防ぐ必要はありません。依存グラフを評価する推論エンジン（AI）がグラフの巡回を検知し、これもサスペンドしてユーザーへ修正を要求します。TCCはビジネスアプリケーション開発を対象としています。ビジネスルールは巡回している処理を持ちません。依存関係の方向があるため、DAGとして表現できます。ただし業務以外の反復数値手法、動的シミュレーション、または不動点計算を必要とする領域は、本手法の範囲外です。
制限：アンチパターンから「宣言型」への転換
グラフで作った構造はリアクティブで評価したいために宣言型で書くのが良い。そこで「どう動かすか(How)」ではなく、「どうあるべきか(What)」の定義に集中します。
5-4.手続きコードを書かない
ノードの内部にIf文の乱発やForループなどの命令的コードを書いた瞬間、アーキテクチャは硬直した過去のシステムへ逆戻りします。宣言型開発とは、ロジックを命令することではなく「どうあるべきかを宣言すること」です。
5-5.「副作用」を隔離する
遅延評価は「いつ、何度評価しても同じ結果になること（べき等性）」が前提です。手動でグローバル変数の書き換えやPatchで外部DBの更新といった副作用を起こすと、グラフ全体が再計算されます。問題は手動で変更した値が残ると、情報のコンタミが生じるのです。純粋関数の世界を維持するため、副作用を手続き的に実行してはなりません。副作用は依存グラフの評価結果としてのみ発生するよう設計し、評価グラフの末端ノードに配置します。
5-6.「いつ実行されるか」を人間が制御しようとしてはならない
「このボタンを押したから、次にこの処理を走らせる」という時間的な順序制御を放棄してください。すべてはDAGのトポロジカルソート判断で動きます。人間は「何が何に依存しているか」という不変の事実だけを管理し、実行タイミングのコントロールはシステムに完全に委ねます。
5-7.命令的入力はエッジへ変換される
ユーザーの入力情報に、手続き的な指定やコードのロジックが含まれていた場合、LLMはそれをそのままグラフ構造に組み込みません。LLMは入力された「手続き」を解釈し、「本質的に何と何が依存関係にあるのか」という『エッジ（トポロジー）』へと自動的に変換します
5.宣言型の本質へ— 理想と現実のミッシングリンク
「ローコードだから、適当に動くものを手早く作れればそれでいい」
TCCは、そういう安易な妥協を目指していない。Power Appsは単なるローコードではなく、最新のリアクティブ宣言型ランタイムを備えており、あらゆる判断をリアルタイムで行い、画面の見た目すらリアクティブに制御できる最新のプラットフォームです。私たちが宣言したTCCは、Power Appsをローコードという「プログラミングができない人のための妥協の道具」ではなく、「だれも到達できなかった、極限のアジリティを具現化する最強の宣言型ランタイム」として利用します。
ユーザーはドメイン知識を語るだけ、AIはそれを整理し、足りない関係を見つけ、ユーザーに質問する。暴走の予感もなく、ソフトウェアはデータフローDAGとして静かに完成する。
しかし、ここで私たちは冷徹な「現在地」で現実の段差に直面する。
プラットフォームの限界と、泥臭い現在地
現時点で、このリアクティブ宣言型DAGの活用に最もふさわしい器であるはずのPower Appsだが、残念なことに「グラフアーキテクチャをシステムへ自動的に移植・抽出する」といったエコシステムは整備されていない。理想に対して、インフラが追いついていないのだ。
TCCという推論エンジンはすでに完成している。しかし、リアクティブな「グラフアーキテクチャ」を100%ネイティブに回せるプラットフォームは、世界を見渡してもまだ最適な形で存在していない。
だからこそ、現在はLLMというコードへの「変換エンジン」による応急処置でこの段差を繋ぐしかない。手動のブリッジを噛ませてでも、TCCのロジックを利用し、システムを駆動させる。この泥臭い実践こそが、過渡期におけるエンジニアリングのリアルである。
「グラフアーキテクチャエコシステム」が業務アプリを統一する未来
だが、この段差が埋まる未来の予感は、すでにすぐそこまで来ている。
仕様や依存関係の構造を、YAMLのような宣言型コードとしてLLMに生成させるアプローチは、現在の高度なAI（Copilotや推論特化型モデル）の最も得意とする領域だ。AIは、ドメイン知識から直接手続き型コードを生成するよりも、データフローDAGから手続き型コードを生成させる方が得意だ。
やがて自動化の架け橋が完成し、すべてが「グラフアーキテクチャ」という共通言語で記述され流通する「グラフアーキテクチャエコシステム」が誕生するだろう。
そのとき、プラットフォームがPower AppsだろうがWebフロントだろうが、DBが何であろうが関係なくなる。業務アプリケーションの本質はすべてデータフローDAGだけに統一され、泥臭い手続きコードは世界から一掃される。
私たちは今、その業務アプリ天下統一の、まさに前夜に立っている。