AIエンジニアリングにおけるトークンエコノミクス（Token Economics）

数字で考える価値のある問い

AIを活用したエンジニアリングワークフローでは、セッション中に知識を獲得する過程でコストが発生します。「AI関連のシミュレーション結果を信頼する前に問うべき5つの質問」において、4つ目の質問は「AIはエンジニアリングに労力を費やしているのか、それともインフラに費やしているのか？」というものでした。

これは5つの質問の中で最も重要であり、定量化が最も難しいものです。また、読者が繰り返し注目する点でもあります。他の質問は正確性に関するものですが、この質問はコストに関するものです。今年の春に行われた2つのケーススタディは、この質問に答えるのに十分な証拠を提供しています。

適切なスタック環境下では、AIを活用したエンジニアリングワークフローにより、トークンコストがおよそ1桁削減されます。コスト削減の大部分を占める要因は、具体的に指摘できるほど明確です。

3種類の知識とコストの帰属先

AIを活用したエンジニアリングワークフローでは、必ず以下の3つの要素を取得する必要があります：

• ドメイン知識： 物理法則（方程式、単位、有効範囲）。
• モデル知識： モデルが何を表現し、どのように構成されているか。
• 実行知識： 解析の実行方法、KPIの抽出方法、結果の解釈方法。

ワークフローのコストとは、これらを獲得するためのコストである。問題は、そのコストがセッション中のAIのトークン予算に計上されるのか、それともAIが継承する成果物に計上されるのかという点だ。その決定は下位のスタックによって行われ、それは明示化可能な構造化された方法で行われる。

階層化されたスタック

そのコストがどこに計上されるかは、階層化されたエンジニアリング・スタックとして明示化できる：

軌道の変更だけでコストを1000分の1に削減できます。インフラコストが大幅に削減されれば、残るのはエンジニアリングに関する議論だけとなり、それこそが支払う価値のあるコストであるため、セッション全体のコストは約1桁削減されます。

構築ワークフロー

2つ目の研究は、このスタックがサポートするもう1つのワークフロー、すなわちモデルの調整ではなく構築に関するものである。別のセッションにおいて、エージェントはシュナイダーエレクトリックのベンダー仕様書（RD108、NVIDIA GB200ラック向けの7.4 MW Tier IIIリファレンスデザイン）を起点とし、Modelica形式で検証済みかつシミュレーション可能なデュアルループ冷却モデルを完成させた。

1回の作業セッションで、以下のことを行いました

• RD108のPDFを読み込み、27のエンジニアリングパラメータをD（データシート）、C（計算値）、A（仮定値）のタグが付いた構造化された表に抽出し、Modelicaを記述する前にレビュー用に提示しました。
• 検証済みのデータセンターライブラリを照会し、ライブラリに既に収録されているメーカーのデータシートから適切なコンポーネントを特定しました。
• デュアルループトポロジーのインスタンスと接続（「ドラッグ・ドロップ・接続」）を作成し、コンパイルして、24時間の動的シミュレーションを実行しました。
• 単一の呼び出しを通じて、RD108の目標に対するKPIを報告しました。6つのうち5つが合格しました。LT供給温度は、目標の23°Cに対して42.2°Cとなり、19°Cの不足でした。
• 不具合の原因を特定：LTループには約1.88 MWのチラー容量が必要だが、実際には1,125 kWしか使用されておらず、1.7倍の不足が生じていた。インスタンスを置き換え、診断中に発見された冗長なコンポーネントを削除して再実行した。修正後のシミュレーションでは供給温度が23.0 °Cとなり、目標値を達成した。

所要時間：不具合の特定と診断を含め、約4時間。経験豊富なシミュレーションエンジニアによる同等の手動実装には、3～4営業日かかると推定された。エージェントは熱交換器の方程式を記述したり、チラーの効率曲線を導出したりすることは一切なかった。各ライブラリコンポーネントは独自の検証済み物理法則を備えており、エージェントはそれを再導出するのではなく、その物理法則に依存している。一言で言えば：エージェントは選択し、構成する。ライブラリが物理法則を保証する。

各レイヤーは具体的なエンジニアリング上の選択である：モデルの表現方法、ツールの公開方法

最適化ワークフロー

最初の事例は、From Intent to Action で紹介した多段階エージェント型実験計画法（DoE）であり、Vehicle Dynamics Library の Modelica Compact ElastoKinematic シャーシ上で実行されています。私はこのライブラリの構築に20年を費やしたため、セッションのコスト明細を直接読み取ることができます。

エージェントのタスクは、両方のKPI目標を達成できていなかったベースラインにおいて、横方向のグリップを最大化することでした。エージェントは、13パラメータの感度解析、2フェーズのラテンハイパーキューブDoE、異常診断（主要指標におけるコントローラの飽和によるアーティファクト）、そして元のパラメータ範囲外での仮説駆動型探索（リアサスペンションブッシュの剛性）を実行し、これらを2つの荷重条件下での2つの過渡操作を通じて検証しました。

トークンの使途：

• ドメイン知識 ≈ コストゼロ。 変数分類、フレーム規約、KPI定義はライブラリのコンテキストとして提供された。30の実験を通じて、エージェントが変数名を独自に考案することは一度もなかった。
• モデル知識 ≈ コストゼロ。 車両ダイナミクスのプレイブックが、ハンドリング図のプロトコルと、シャシーパラメータを抽出するためのパターンを提供した。エージェントはプロトコルとヒューリスティックを継承しただけで、それらを導出することはなかった。
• 実行コストは劇的に削減された。 1回のsweep呼び出しで30ケースのスイープが実行され、1回のanalyze sweep呼び出しでKPIテーブルが返された。解析が実行された軌道データ（スイープ全体で約75,000個の値）は、エージェントのコンテキストには一切取り込まれなかった。これは、生軌道データの約20万トークンに対し、KPIテーブルは数百トークンに過ぎず、このスタックにおける最大のコスト削減要因となっている。

実際に消費されたトークンは、エンジニアリング作業に費やされました。具体的には、感度解析結果における非対称性の解釈、後方への重心移動が荷重感度を示唆するという仮説の立案、それを裏付ける積載車両ケースの設計、そして剛性の頭打ち状態を打破する要因としてリアブッシュを特定する作業です。

2つのワークフロー、同じ経済性

2つのケースは手法が異なりますが、経済性については一致しています。どちらも同じスタック上で実行されました。どちらも単一の作業セッション内で、正当化可能なエンジニアリング結果を導き出しました。また、両ケースとも、モデルの考古学的な調査やグルーコード、軌道の管理といった作業ではなく、エンジニアリング上の意思決定にトークンの大部分を費やしました。

これが当初の質問に対する答えです。このスタックでは、インフラコストはレベル1の場合に比べておよそ1桁低く抑えられています。これは、1つの操作（サーバーサイドでのKPI抽出）が主要な要因であり、再利用可能な知識と構造化されたツールインターフェースによって強化されているためです。

人間のために構築され、AIに対応済み

上記の経済性は、そのドメイン向けに検証済みのライブラリが存在すること、およびエンジニアリングパラメータを導き出せるほど明確に指定された入力に依存している。これらの条件が満たされない場合（新規の物理現象、曖昧な仕様、コンポーネントライブラリの欠如）、AIは作業を支援することはできても、主導することはできない。

Modelicaコミュニティは30年をかけて、ますます幅広い工学分野においてこれらの条件を実現可能なものにするライブラリを構築してきました。Modelica自体は、実装ではなく物理法則として読み取れるモデルを、エンジニアのために設計されました。検証済みのライブラリは信頼性と再利用性を重視して設計されており、エンジニアはコンポーネントを再導出することなく信頼できます。構造化されたプラットフォームAPIは、エンジニアがオーケストレーションコードを記述することなくシミュレーションを実行できるように設計されました。

これらはいずれもAIのために作られたものではない。ドメインの専門家にとってスタックを読みやすくするための決定（非因果方程式、名前付きコネクタ、宣言型コンポーネントインスタンス化、型付きツールインターフェース、人間が記述可能なナレッジレイヤー）こそが、AIにとってトークン効率を高める決定そのものである。

トークン経済学の問題とオープンスタンダードの問題は、結局のところ同じ問題であることが判明した。