TORM

■ プロローグ：我々は長い間、"レイテンシ"の中にいた

.NETのデータアクセス層における「最適解」とは何か？
我々はこの10年間、終わりのない振り子運動を続けてきた。

一方には、Microsoftの正統なる覇者 Entity Framework Core (EF Core) がいる。「抽象化」という甘美なVR空間を提供し、開発者からSQLという現実を隠蔽する。しかし、その魔法は時に呪いとなる。複雑なクエリは解読不能なモンスターSQLへと変貌し、我々をパフォーマンス・チューニングという名の深淵へ引きずり込む。

もう一方には、Dapper がいる。「生」のデータを愛する硬派なマイクロORMだ。しかし、その代償として我々は、C#コードの中に文字列（String）として埋め込まれた非構造化データと戦うことになる。構文ハイライトも効かず、リファクタリングのたびに崩壊する「文字列の塊」は、ハイパースケールなシステムにおいては時限爆弾そのものだ。

「我々が欲しいのは、ブラックボックス化した魔法ではない。しかし、原始的な文字列操作でもない」

現場のアーキテクトたちの渇望に、ついに一つの解が提示された。
TORM (TERIOS Object Relational Mapping)。

Javaのエコシステムにおいて「2-Way SQL」の概念を確立し、熱狂的な支持を集める「Doma」にインスパイアされ、.NETの最新テクノロジー（Source Generator / MEF2）を用いて再構築された野心作である。

これは単なるライブラリではない。システム開発における「シンギュラリティ（技術的特異点）」だ。ここにあるのは、人間の思考とデータベースの実行エンジンを神経接続（Neural Link）する、全く新しいインターフェースである。

本稿では、TORMがもたらす4つの「革命」を軸に、その全貌を解き明かしていく。

■ Revolution 1: Cognitive Sync (認知の直列化)

脳とDBの間の「翻訳レイテンシ」をゼロにする

ハイパースケール開発において、最も生産性を阻害するノイズは何か。それはコードを書く時間ではない。「翻訳（Translation）」の時間 だ。

通常、高度なクエリを作成する際、開発者はまず pgAdmin や DataGrip といったDB管理コンソールにダイブする。そこで試行錯誤し、インデックスを確認し、実行計画を最適化した「完璧なロジック」を練り上げる。
断絶はそこから始まる。その完成されたロジックを、C#の世界に持ち込むために「翻訳」しなければならないのだ。

「ここは StringBuilder で動的に結合して…」
「この WHERE 句は LINQ の Expression ツリーで表現して…」

この過程で、せっかくの美しいロジックは劣化コピーとなり、DBAとアプリエンジニアの間には埋めがたい「認知のズレ」が生まれる。

SQL is Code. Code is SQL.

TORMはこう宣言する。「そのSQL、そのままファイルに保存せよ。それがコードだ」。
TORMの 2-Way SQL は、SQLファイルが「二つの量子状態」を持つことを許容する。

SELECT
    p.product_name,
    SUM(o.amount) as total_sales
FROM orders o
INNER JOIN products p ON o.product_id = p.id
WHERE 1 = 1
/*%if (phase != null) */
  AND o.phase = /* phase */'ALPHA'
/*%end*/
/*%if (threshold > 1000) */
  AND o.amount >= /* threshold */1000
/*%end*/
GROUP BY p.product_name

この .sql ファイルは、次元を超えるインターフェースだ。

そこにあるのは、「思考したロジックが、遅延なくアプリの駆動力になる」 という体験だけだ。「翻訳」というノイズがない世界では、開発者の脳とデータベースは常に同期（Sync）し続ける。

■ Revolution 2: Compile-Time Precognition (コンパイル時の予知)

"不確定性" の排除と、未来の確定

数千本のクエリが走るシステムにおいて、バグの大半は「実行してみるまで分からない」という不確定性に起因する。
「モジュールAを修正したら、依存関係のないモジュールBのクエリが崩壊した」。
こうした些細なエントロピーの増大が、巨大なシステムを死に至らしめる。

TORMの Source Generator は、この不確定性をコンパイル時にすべて焼き払う。

コンパイラによる未来予知

あなたが partial メソッドを定義したその瞬間、TORMのジェネレータは時空を超えてプロジェクト全体をスキャンする。

これは「テスト」ではない。「予知（Precognition）」 だ。
TORMの世界では、バグは実行時に発見されるものではなく、コードを書いている最中に排除されるものとなる。この「決定論的ビルド」こそが、ハイパースケール開発における唯一の生存戦略だ。

■ Revolution 3: Universal Design (ユニバーサル・デザイン)

ホスト言語を超越する、"Smalltalk" の遺伝子

TORMの実装を目の当たりにした時、鋭いアーキテクトなら即座に理解するはずだ。
これはC#のライブラリではない。「C#で実装された、純粋な概念」であると。
TERIOSアーキテクチャの真意は、ホスト言語（C#）という狭い檻からの、ロジックの完全な解放にある。

Smalltalk由来の「契約」による結合

TERIOSは、コンポーネントの解決に 契約名（Contract Name） を採用している。
これは Smalltalk のメッセージング思想に端を発する、極めて純粋なオブジェクト指向のアプローチだ。
JavaのアノテーションやC#のジェネリクスといった「言語固有のDI機能」に依存せず、文字列としての契約のみでシステムを結合する。

なぜか？ それは TERIOS というプラットフォームが、あらゆるプログラミング言語に移植されることを前提とした「次世代アーキテクチャ」だからだ。

TERIOSにとって、C#は一時的な「宿主（ホスト）」に過ぎない。ComponentFactory は、言語の壁を越えてロジックを疎結合に保つための、普遍的なインターフェースなのだ。

これは、システムを 「固体」から「流体」へと進化 させるための装置なのだ。

契約による分離、設定による結合

TERIOSアーキテクチャにおいて、コンポーネントは型（Type）ではなく、契約名（Contract Name） という概念で管理される。
同一のインターフェースを持つ複数の実装を、名前を変えて同時にデプロイしておくことができる。

• ▶ CustomerDao （安定稼働中の標準実装）
• ▶ CustomerDao_Fast （キャッシュレイヤーを導入した高速版）
• ▶ CustomerDao_Experimental （実験的なアルゴリズムを含む版）

そして、実際にどれをアクティベートするかは、設定ファイルの書き換えのみで決定される。

{
  "CustomerDao": "CustomerDao_Fast"
}

リアルタイム・アダプテーション

コードを修正し、リビルドし、デプロイし直す必要はない。設定ファイルを書き換えれば、瞬時にロジックが変異する。
深夜に異常検知があれば、設定を標準実装に戻すだけで1秒でロールバック完了だ。
「本番環境のデータを使って、特定のノードだけ新しいロジックを試す」。そんな危険かつ魅力的な実験を、既存コードを一切汚さずに実現できる。

システムの実装バージョン管理を、Gitの外側（運用フェーズ）で行う。このスピード感に、従来のCI/CDフローはあまりに遅すぎて追いつけない。

■ Revolution 4: AI-Native Protocol (AIとの共鳴)

人間ではなく、AIのために設計されたプロトコル

ここが最も現代的かつ重要な点だ。
TORMの「厳格すぎる規約」は、人間を縛るためではない。
「AI（LLM）が、ハルシネーション（幻覚）を起こさずに完璧なコードを書くため」 のプロトコルなのだ。

現代の開発において、GitHub CopilotやChatGPTといったAIエージェントの支援は不可欠だ。しかし、自由すぎるフレームワークはAIに迷いを生じさせ、ノイズの混じったコードを生成させる。
TORMの厳格さは、AIにとっての「誘導路」となる。

■ 技術的特異点：物理限界への挑戦

概念だけではない。TORMは物理的なパフォーマンスの限界にも挑んでいる。

Warp Drive: PostgreSQL COPY (BulkCopyAsync)

「初期データロードで数百万件を転送したい」。そんな時、ORMの行儀良さは足かせになる。
TORM.PostgreSQL パッケージに搭載された BulkCopyAsync は、EntityListenerも楽観ロックも全て無視し、PostgreSQLのバイナリ転送プロトコル（COPY コマンド）を直接叩く。
これは、通常の INSERT 文とは次元の違う転送速度を叩き出す。「整合性はアーキテクチャで担保せよ。TORMはただ、物理限界の速度を提供するだけだ」。

Zero-Latency Parser: Pidgin Engine

多くの自作ORMが陥る罠、それが「正規表現によるSQL解析」だ。
TORMはここにも妥協がない。パーサーコンビネータライブラリ Pidgin を採用し、SQLを文字列としてではなく、構造化されたAST（抽象構文木）として解析している。
解析結果はSHA256ハッシュでキャッシュされ、動的SQLでありながら静的SQLに迫る実行速度を実現している。