Agent Tool Compiler — 自然言語からAPI設計・コード生成・実行までのコンパイルパイプライン

1. コンパイラとしてのAgent：アナロジーとその含意

コンパイラは高水準言語で書かれたソースコードを、一連の明確に定義された段階を通じて実行可能な機械語に変換する。字句解析・構文解析・意味解析・中間表現・最適化・コード生成。各段階には形式的な保証がある。パーサーは構文的妥当性を保証する。型チェッカーは意味的一貫性を保証する。最適化器はプログラムセマンティクスを保持しつつ性能を改善する。コードジェネレータは出力がターゲットアーキテクチャに対して有効であることを保証する。

ツール生成エージェントはこれらの段階をすべてスキップする。自然言語（可能な限り最高水準の「言語」）を入力とし、実行可能コード（最低水準）を単一ステップで生成する。これは中間表現も型チェックも最適化も形式的保証もなく、ソーステキストから直接機械語に変換するコンパイラに等しい。結果は予測可能である。生成されたツールにはデッドコードが含まれ、エラーケースを見落とし、型安全性を欠き、セキュリティ脆弱性を含み、最適化対象となる構造化表現が存在しないため最適化できない。

Agent Tool Compilerはコンパイラエンジニアリングの原則をツール合成に適用する。 | コンパイラ段階 | 従来のコンパイラ | Agent Tool Compiler | |---|---|---| | ソース言語 | プログラミング言語（C、Rustなど） | 自然言語（英語、日本語など） | | 字句解析 | トークン化 | 意図抽出 | | 構文解析 | 構文木構築 | Intent AST構築 | | 意味解析 | 型チェック、スコープ解決 | 契約推論、副作用解析 | | IR生成 | LLVM IR、SSA形式 | Tool IR（汎用ツール記述） | | 最適化 | デッドコード除去、ループ展開 | セキュリティ強化、キャッシュ、並列化 | | コード生成 | x86、ARM機械語 | TypeScript、Python、WASM | | リンク | ライブラリリンク、シンボル解決 | ランタイム統合、依存性注入 |

このアナロジーは単なる教育的なものではない。各段階境界でテスト可能な保証を持つ具体的なエンジニアリングアーキテクチャを含意する。

2. フロントエンド：自然言語からIntent ASTへ

フロントエンド段階は非構造化の自然言語意図を構造化されたIntent AST（意図の抽象構文木）に変換する。これはツールが何をすべきかを、どのようにするかを指定せずに捕捉する。Intent ASTはコンパイラのユーザーリクエストの内部表現であり、従来のコンパイラがソースコードから構築する構文木に類似する。

// Intent ASTノード型
interface IntentAST {
  root: IntentNode
  metadata: {
    sourceUtterance: string    // 元のNL入力
    confidence: number         // パーサー信頼度スコア
    ambiguities: Ambiguity[]   // 人間レビュー用の未解決曖昧性
  }
}

type IntentNode =
  | ActionNode          // "取得", "変換", "検証", "保存"
  | DataFlowNode        // 入力 → 処理 → 出力
  | ConstraintNode      // "5秒以内に完了", "PIIを公開してはならない"
  | ErrorModeNode       // "APIが429を返したら、バックオフで再試行"
  | SideEffectNode      // "データベースに書き込む", "通知を送信する"
  | CompositionNode     // 逐次・並列・条件付き合成

interface ActionNode {
  type: "action"
  verb: string                 // 正規化されたアクション動詞
  object: string               // アクションの操作対象
  parameters: ParameterSpec[]  // 型付き推論パラメータ
  returnType: TypeSpec          // 推論された戻り値型
}

フロントエンドは2フェーズの解析戦略を使用する。フェーズ1（意図抽出）はLLMを使用して自然言語記述から構造化された意図を抽出し、ドラフトIntent ASTを生成する。このフェーズは本質的にファジーである。自然言語は曖昧であり、LLMの解釈が不正確である可能性がある。フェーズ2（意図検証）はドラフトASTに決定論的ルールを適用する。パラメータの型推論、副作用解析、制約整合性チェック、曖昧性検出。フェーズ2が解決できない曖昧性を発見した場合、コンパイルが進む前に人間レビューのためにフラグ付けされる。

核心的な洞察は、フロントエンドが理解（フェーズ1、LLM駆動、ファジー）と検証（フェーズ2、ルールベース、決定論的）を分離することである。これはまさに従来のコンパイラの動作方法だ。パーサーは構文的に有効だが意味的に無意味なプログラムを受け入れ、意味解析器がエラーを捕捉する。問題を分割することで、理解フェーズが本質的に確率的であっても、検証フェーズに形式的手法を適用できる。

\text{Parse}: \Sigma^* \rightarrow \text{IntentAST} \cup \{\perp\}

ここで$\Sigma^*$はすべての自然言語文字列の集合、$\perp$はパース失敗（意図が曖昧すぎるか矛盾してコンパイルできない）を表す。パース関数は全域的ではない。一部の自然言語入力はツールにコンパイルできず、コンパイラは不正な出力を生成するのではなく拒否しなければならない。

3. ミドルエンド：Intent ASTからAPI仕様へ

ミドルエンドはIntent ASTを具体的なAPI仕様、すなわちツールのインターフェース契約に変換する。この段階は型推論・パラメータ設計・エラー契約定義・リソース見積もりを実行する。「このツールがすべきことを踏まえて、そのAPIはどのような形であるべきか？」という問いに答える。

interface ToolAPISpec {
  name: string                      // アクション動詞 + 対象から生成
  description: string               // 人間可読な記述
  version: string                   // セマンティックバージョン

  input: {
    parameters: TypedParameter[]    // 名前、型、必須、デフォルト、バリデーション
    constraints: InputConstraint[]  // 事前条件
  }

  output: {
    successType: TypeSpec           // 成功時の戻り値型
    errorTypes: ErrorSpec[]         // 可能なエラー型（コード付き）
    sideEffects: SideEffect[]       // 宣言された副作用
  }

  contract: {
    idempotent: boolean             // 再試行しても安全か？
    timeout: number                 // 最大実行時間（ms）
    retryPolicy: RetryPolicy        // 一時的障害の処理方法
    resourceBudget: ResourceBudget  // CPU・メモリ・ネットワーク制限
  }

  security: {
    requiredPermissions: string[]   // ツールがアクセスする必要があるもの
    dataClassification: string      // PII、機密、公開
    auditLevel: "full" | "summary" | "none"
  }
}

ミドルエンドの型推論は特に困難である。ソース型が形式的な型システムではなく自然言語から来るためだ。コンパイラはヒューリスティック型推論（パラメータ名とコンテキストから型を推論する。例えば「email」はメールパターンに一致するstringの可能性が高く、「count」は非負整数の可能性が高い）と制約伝播（パラメータが下流で算術演算に使用される場合、数値でなければならない）の組み合わせを使用する。

ミドルエンドはインターフェース設計最適化も実行する。推論されたパラメータから、関連パラメータをオブジェクトにグループ化し、デフォルトを持つべきオプションパラメータを特定し、境界で検証すべきパラメータと実装内部で検証すべきパラメータを決定し、パラメータの数と型に基づいて位置指定と名前付きパラメータスタイルを選択する。この最適化は、パラメータ設計が後付けであるアドホック生成よりもクリーンで人間工学的なAPIを生成する。

4. バックエンド：API仕様からコード生成へ

バックエンド段階はTool API仕様から実行可能コードを生成する。フロントエンド（理解にLLMを使用）やミドルエンド（ルールベースの推論を使用）とは異なり、バックエンドはハイブリッド生成戦略を使用する。ボイラープレート（パラメータ検証・エラーハンドリング・ログ記録）にはテンプレートベース生成、実装ロジック（ツールが実行する実際の計算）にはLLMベース生成を使用する。

ボイラープレートと実装の分離は極めて重要である。ボイラープレートコード（検証・エラーハンドリング・ログ記録・リトライロジック）は予測可能なパターンに従い、テンプレートから決定論的に生成できる。実装コード（実際のロジック）はドメインの理解を必要とし、LLMによって生成される。ボイラープレートを決定論的に生成することで、コンパイラはLLM生成の実装の品質に関係なく、すべてのツールが一貫したエラーハンドリング・検証・ログ記録を持つことを保証する。

ソースマップは重要なアーティファクトである。生成されたコードのすべての行を、それを動機付けたIntent ASTノードにマッピングする。これによりデバッグ（「この行はユーザーが『APIからデータを取得する』と言ったために生成された」）、監査（「このセキュリティチェックはツールがPIIデータを扱うために追加された」）、修正（「この動作を変更するには、対応するIntent ASTノードを修正して再コンパイルする」）が可能になる。

5. 最適化パス：正確から効率的かつ安全へ

初期コード生成後、コンパイラは一連の最適化パスを適用する。各パスは意味的等価性を保持しつつ生成コードを変換する（各パス後にテストスイートを再実行して検証）。

パス1：デッドコード除去。 LLM生成コードには到達不能な分岐、未使用変数、冗長な計算が頻繁に含まれる。コンパイラは制御フローグラフとデータフロー解析を使用して標準的なデッドコード解析を実行し、出力に影響しないコードを除去する。典型的な削減量：生成行の15〜25%。

パス2：セキュリティ強化。 コンパイラはツールのデータ分類と必要な権限に基づいてセキュリティチェックを注入する。PIIを扱うツールには入力サニタイゼーション・出力マスキング・監査ログを追加する。外部APIコールを行うツールにはリクエスト署名・TLS検証・レスポンス検証を追加する。データベースに書き込むツールにはパラメータ化クエリ構築（SQLインジェクション防止）とトランザクション境界を追加する。

パス3：型絞り込み。 LLM生成コードは広い型（any、object、unknown）を使用する傾向がある。LLMが正確な型について不確実なためだ。コンパイラは型絞り込み解析を実行する。値が実装内でどのように実際に使用されているかを調べ、すべての使用法と一致する最も具体的な型に絞り込む。これにより、そうでなければ実行時に表面化する型エラーをコンパイル時に捕捉する。

パス4：並列化。 コンパイラは同時に実行可能な独立した操作を特定する。異なるエンドポイントへの逐次APIコール、独立したデータ変換、非依存の検証チェックは、Promise.all（TypeScript）またはasyncio.gather（Python）を使用して自動的に並列化される。典型的な高速化：複数の外部コールを持つツールで30〜50%。

パス5：キャッシュ挿入。 同じパラメータで繰り返し呼び出しを行うツール（データエンリッチメントツールで一般的）に対して、コンパイラは設定可能なTTL付きメモ化レイヤーを挿入する。キャッシュの判断はAPI仕様のべき等性宣言に基づく。べき等な操作のみがキャッシュされる。

パス6：エラー回復注入。 コンパイラはツールのエラーモードを解析し、回復ロジックを注入する。一時的エラーには指数バックオフ付きリトライ、永続的障害にはサーキットブレーカー、オプション依存関係にはグレースフルデグラデーションパス、回復不能障害には構造化エラーレポートを挿入する。

\text{Optimize}: \text{Code} \xrightarrow{P_1} \text{Code} \xrightarrow{P_2} \cdots \xrightarrow{P_n} \text{Code}'

各パス$P_i$はセマンティクス保存的である：$\forall x. \; \text{eval}(P_i(\text{Code}), x) = \text{eval}(\text{Code}, x)$。パスの合成もセマンティクス保存的であり、最適化されたコードがすべての有効な入力に対して最適化されていないコードと同一の出力を生成することを保証する。

6. エージェントツールの型システム

ATCにはエージェントツール専用に設計された型システムが含まれる。この型システムは標準的なプログラミング言語の型システムを、エージェント固有の懸念を捕捉する構成要素で拡張する。

// エージェントツール型システム
type ToolType =
  | PrimitiveType          // string, number, boolean, null
  | StructType             // { field: Type, ... }
  | ArrayType              // Type[]
  | UnionType              // Type | Type
  | ConstrainedType        // Type & constraint（例：string & email）
  | ResourceType           // 外部リソース参照（URL、DB接続）
  | SensitiveType          // 任意の型をPII/機密としてマーク
  | TemporalType           // 時間制限値（TTL後に期限切れ）
  | FallibleType           // Result<T, E> — 明示的な成功/エラー

// 制約型はドメインルールを型レベルで強制する
type EmailAddress = ConstrainedType<string, "matches(/^[^@]+@[^@]+$/)">;
type PositiveInt = ConstrainedType<number, "x > 0 && Number.isInteger(x)">;

// 機密型は自動的にセキュリティ対策をトリガーする
type SSN = SensitiveType<string, "PII">;
// コンパイラが自動注入：入力検証、出力マスキング、監査ログ

// 時間型は陳腐化データの使用を防ぐ
type CachedPrice = TemporalType<number, { ttl: 300_000 }>; // 5分TTL
// コンパイラが自動注入：使用前の期限チェック、期限切れ時のリフレッシュ

型システムは3つの重要な特性を強制する。 1. ツール境界を超えた型安全性。 ツールAの出力がツールBの入力に流れる場合、コンパイラはコードが生成される前にIRレベルで型の互換性を検証する。これにより統合エラーをコンパイル時に捕捉する。 2. 構築による安全性。 機密型はデータフローを通じて伝播する。ツールがSensitiveType入力を受け取った場合、そこから派生するすべての出力も機密としてマークされる。これにより偶発的なデータ漏洩を防ぐ。コンパイラは明示的な機密解除なしに機密データをログ・キャッシュ・返却するコードの生成を拒否する。 3. 時間的正確性。 時間型は鮮度要件を型システムにエンコードすることで、陳腐化データのバグを防ぐ。キャッシュデータを使用するツールはキャッシュの有効期限切れケースを処理しなければならず、コンパイラがリフレッシュロジックを自動生成する。

7. Tool IR：汎用ツール記述形式

Tool IRはATCの中心的なデータ構造であり、ソース言語やターゲット言語に関係なくすべてのツールが通過する中間表現である。IRは言語非依存・最適化可能・シリアライズ可能に設計されている。

interface ToolIR {
  // 識別
  id: string
  name: string
  version: string

  // データフローグラフ
  entryBlock: IRBlock
  blocks: IRBlock[]
  edges: IREdge[]

  // 型環境
  typeEnv: Map<string, ToolType>

  // リソース宣言
  resources: ResourceDeclaration[]

  // 制約集合
  constraints: IRConstraint[]
}

interface IRBlock {
  id: string
  kind: "entry" | "compute" | "branch" | "call" | "error" | "exit"
  instructions: IRInstruction[]
  successors: string[]          // ブロックID
}

type IRInstruction =
  | { op: "load"; target: string; source: string }
  | { op: "validate"; target: string; constraint: string }
  | { op: "transform"; target: string; fn: string; args: string[] }
  | { op: "call"; target: string; service: string; method: string; args: string[] }
  | { op: "branch"; condition: string; trueBlock: string; falseBlock: string }
  | { op: "return"; value: string }
  | { op: "error"; code: string; message: string }

IRは従来のコンパイラ設計から借用した基本ブロック構造を使用する。各ブロックは単一のエントリポイントと1つ以上の出口エッジを持つ命令列を含む。この構造により標準的なコンパイラ最適化が可能になる。共通部分式除去（2つのブロックが同じ値を計算する場合）、ループ不変コード移動（値がループの反復全体で定数の場合）、分岐予測（条件が静的に決定可能な場合）である。

IRはツールレジストリにツールが格納される形式でもある。ツールを別のターゲット言語に再コンパイルする必要がある場合、または最適化パスが改善された場合、元の自然言語意図を再解析せずにIRからツールを再コンパイルできる。これによりツールのセマンティクスとツールの実装が分離される。IRはツールが何をするかを捕捉し、バックエンドがどのようにするかを決定する。

8. ランタイム統合：コンパイル済みツールのホットロード

コンパイルされたツールは再起動なしにエージェントランタイムに統合されなければならない。ATCはホットロードを実装する。実行中のエージェントにツールを追加・置換・削除する能力である。

ホットロードプロトコルは3つのステップに従う。 1. 分離。 コンパイルされたツールは分離された実行コンテキスト（TypeScriptにはV8アイソレート、Pythonにはサブプロセス、WASMにはWASMサンドボックス）にロードされる。分離により、不正なツールがエージェントランタイムをクラッシュさせたり他のツールの状態にアクセスしたりすることを防ぐ。 2. 登録。 ツールのAPI仕様がエージェントのツールレジストリに登録され、ツール選択システムから発見可能になる。登録はアトミックであり、ツールは完全に登録される（すべてのメタデータ・型・エントリポイント）か、まったく登録されないかのいずれかである。 3. ウォームアップ。 ランタイムが分離されたコンテキストでツールの自動生成テストスイートを実行し、コンパイルされたコードが本番環境で実際に動作することを検証する（コンパイルサンドボックスだけでなく）。ウォームアップが失敗した場合、登録はロールバックされる。

ホットロードにより強力な開発ループが可能になる。エージェントは新しいツールの必要性を特定し、ATCパイプラインでコンパイルし、自身のランタイムにホットロードし、使用を開始する。すべて人間の介入やシステム再起動なしに。意図から実行可能ツールまでの全サイクルはベンチマークで2秒未満である。

9. コンパイルエラーハンドリング：ツールコンパイルが失敗する場合

すべての自然言語意図がツールにコンパイルできるわけではない。ATCはコンパイルエラーの分類法を定義し、それぞれに固有の回復戦略を持つ。

コンパイルエラーは不具合ではなく機能である。入力を決して拒否しないコンパイラは検証を実行していない。ATCが不正な意図を拒否し、その理由を説明できる能力は、意図がコンパイル可能かどうかに関係なくLLMが常に何らかのコードを生成するアドホック生成に対する主要な優位性の一つである。

10. ベンチマーク：コンパイル時間と生成コード品質

ATCをアドホックLLMベースのツール生成に対して3つの次元でベンチマークする。コンパイル時間・コード品質・ランタイム信頼性。

ATCのコンパイルは遅い（1.8秒 vs 1.2秒）。複数段階の解析と最適化を実行するためだ。しかし、コンパイルされたツールはすべての品質メトリクスで大幅に優れている。40%のコードサイズ削減はデッドコード除去（パス1）とLLM生成の同等物よりもコンパクトなテンプレートベースのボイラープレートから主に来ている。60%のランタイムエラー削減は型絞り込み（パス3）・セキュリティ強化（パス2）・エラー回復注入（パス6）から来ている。25%のレイテンシ改善は並列化（パス4）とキャッシュ（パス5）から来ている。

コンパイル時間のオーバーヘッド（0.6秒）はツールのライフタイムにわたって償却される。一度コンパイルされたツールは数千回または数百万回実行される。品質改善は複利で効く。ランタイムエラーが少ないことは、リトライが少なく、デバッグが少なく、エージェントの信頼性が高いことを意味する。

11. 数学的基礎：ツール生成に適用される形式言語理論

ツールコンパイルに関与する言語の階層を定義することにより、ATCを形式言語理論に基盤づける。

レベル0：自然言語（$\mathcal{L}_0$）。 入力言語。制限のない自然言語。チョムスキー階層のタイプ0言語（再帰的可算）であり、いかなる有限オートマトンでも完全に解析できないことを意味する。フロントエンドのLLMがこのレベルの近似パーサーとして機能する。

レベル1：意図言語（$\mathcal{L}_1$）。 Intent AST言語。ツールの意図を捕捉する文脈自由文法。チョムスキー階層のタイプ2言語であり、プッシュダウンオートマトンで解析可能。文法はIntentASTスキーマによって定義される。

\mathcal{L}_1 = \{ w \in \text{IntentAST}^* : \text{valid}(w) \}

レベル2：Tool IR言語（$\mathcal{L}_2$）。 IR言語。基本ブロックデータフローグラフを記述する正規言語（チョムスキー階層のタイプ3）。IRには再帰がないため（ツールは再帰プログラムではなく単一レベルの関数）、有限オートマトンとして表現できる。

\mathcal{L}_2 = \{ w \in \text{ToolIR}^* : \text{wellTyped}(w) \land \text{acyclic}(w) \}

レベル3：実行可能コード（$\mathcal{L}_3$）。 出力言語。コードジェネレータが生成できるパターンに制限されたターゲットプログラミング言語のサブセット。

コンパイルパイプラインは一連の言語変換である。

\text{ATC}: \mathcal{L}_0 \xrightarrow{\text{Frontend}} \mathcal{L}_1 \xrightarrow{\text{Middle-end}} \mathcal{L}_2 \xrightarrow{\text{Backend}} \mathcal{L}_3

各変換は言語の複雑さを低減する。タイプ0（制限なし）からタイプ2（文脈自由）、タイプ3（正規）、タイプ2言語の制限されたサブセットへ。この複雑さの低減が最適化を可能にする。タイプ0言語は最適化できない（決定不能）が、タイプ3言語は最適化できる（完全に解析可能）。

形式的基礎はコンパイラの正確性基準も与える。

\forall i \in \mathcal{L}_0. \; \text{ATC}(i) \neq \perp \implies \text{semantics}(\text{ATC}(i)) \subseteq \text{intent}(i)

すなわち、コンパイラが正常に出力を生成した場合、生成されたコードのセマンティクスは自然言語入力で表現された意図の部分集合（すなわち整合的）でなければならない。部分集合関係（等号ではなく）は、自然言語の意図が未指定である可能性を認める。コンパイルされたツールは意図の1つの有効な解釈を実装するが、必ずしも唯一の有効な解釈ではない。

12. 結論

Agent Tool Compilerはツール生成をコンパイル問題として再定義し、現在アドホックなLLM生成が支配するドメインに数十年のコンパイラエンジニアリングの厳密さをもたらす。核心的なアーキテクチャの洞察は、中間表現（Intent ASTとTool IR）の導入であり、理解と最適化とコード生成を分離する。各段階には明確な入力・出力・正確性基準がある。最適化パスは、アドホックに生成されたツールよりも小さく、速く、安全で、信頼性の高いツールを生成する。型システムはコンパイル時にランタイム障害として表面化するはずのエラーを捕捉する。そして形式言語理論の基礎はコンパイラの正確性について推論するフレームワークを提供する。MARIA OSにおいて、ATCは自己拡張エージェントが混沌ではなく体系的に能力を成長させることを可能にするインフラストラクチャである。すべての新しいツールがコンパイル・最適化・型チェックされ、各段階で品質を保証するパイプラインを通じて統合される。