AIエージェントのシステムプロンプトをコードと同様にビルドする「プロンプトトランスパイラ」— 循環依存検出・静的検証・CI/CDドリフトチェックまで

7月10日、Simerus Maheshが「Scaling AI Agents: Building a Prompt Transpiler for Production Agents」と題した記事を公開した。LLMエージェントの本番運用が急増する2025年、プロンプトはもはや「テキストファイル1枚」では管理しきれない規模に膨張しつつある。本記事はその課題に対し、コンパイラの設計思想を持ち込んだ「プロンプトトランスパイラ」というアーキテクチャを提案している。

なぜ「巨大なシステムプロンプト」が問題になるのか

AIエージェントが組織内で普及すると、システムプロンプトはあらゆるチームの「書き込み先」になっていく。セキュリティチームが安全ポリシーを追記し、プラットフォームチームがツールスキーマを定義し、開発チームがワークフロールールを足す。結果として生まれるのは、1つの巨大なテキストファイルへのマージコンフリクト、重複した記述、互いに矛盾する指示だ。

LangChainのプロンプトテンプレート管理やPromptLayerのようなバージョン管理ツールはすでに存在するが、いずれも「モジュール分割されたプロンプトを静的に検証・結合してビルド成果物として確定させる」というコードビルドシステム的な発想には踏み込んでいない。本記事はこの「モノリシックプロンプト問題」に対し、まさにその発想で解決しようとするアプローチを提案している。

プロンプトをコードと同様に扱う：トランスパイラの設計思想

そもそも「トランスパイラ」とは、あるソースコードを別の形式のソースコードに変換するツールを指す（JavaScriptのBabelやTypeScriptコンパイラが代表例だ）。通常の「コンパイラ」が高水準言語を機械語などの低水準表現に変換するのに対し、トランスパイラは抽象度の近い表現間の変換・合成を担う。本記事が提唱するプロンプトトランスパイラはこの考え方をプロンプト管理に適用したもので、モジュール分割された複数のプロンプトファイルを静的に検証・結合し、決定論的なコンパイル済みプロンプト成果物を生成するビルドシステムだ。

SREエージェントを例にとると、リポジトリ構成は次のようになる：

prompts/
  shared/
    safety.prompt.md
    formatting.prompt.md
    tool_usage.prompt.md
  sre/
    incident_triage.prompt.md
    kubernetes_debugging.prompt.md
  agents/
    sre_agent.prompt.md

エントリーポイントとなる sre_agent.prompt.md は、各プロンプトフラグメントをインクルードする形で記述される：

# agents/sre_agent.prompt.md
You are an SRE triage agent responsible for helping engineers investigate production issues.

{% include "shared/safety.prompt.md" %}
{% include "shared/tool_usage.prompt.md" %}
{% include "sre/incident_triage.prompt.md" %}
{% include "sre/kubernetes_debugging.prompt.md" %}
{% include "shared/formatting.prompt.md" %}

開発者にとってはテンプレートファイルに見えるが、ビルドシステムからすると各 include は依存関係の宣言だ。

テンプレートエンジンは変数展開や条件分岐もサポートする：

You are operating in the {{ environment }} environment.
Only use tools available for:
- cluster: {{ cluster_name }}
- namespace: {{ namespace }}

{% if allow_remediation %}
You may recommend remediation steps, but do not perform destructive actions without approval.
{% else %}
You may inspect and summarize the issue, but do not recommend remediation actions.
{% endif %}

ただし、テンプレートエンジンだけでは不十分だ。ランタイムにレンダリングするだけでは、変数の欠落や循環インポートがデプロイまで検出されない。トランスパイラが必要な理由はここにある。

トランスパイラパイプラインの構造

トランスパイラは以下のステージで構成される：

パーサー：インクルード先のファイルと参照変数を特定
依存グラフ構築：各プロンプトファイルをノード、インクルードをエッジとして有向グラフを構築
バリデーター：循環依存の検出、変数の未定義チェック、ファイルの存在確認
レンダラー & 成果物ライター：最終的なシステムプロンプトを生成し dist/sre_agent.compiled.prompt.md として保存

CLIのコマンドイメージは次の通りだ：

transpiler build agents/sre_agent.prompt.md \
  --out dist/sre_agent.prompt.md \
  --verify-drift

--verify-drift フラグはCI/CD上でコミット済みの成果物と再コンパイル結果を比較し、依存ファイルが更新されていれば検証を失敗させる。

循環依存の検出：深さ優先探索によるバックエッジ検出

依存グラフは有向非巡回グラフ（DAG：Directed Acyclic Graph）を形成しなければならない。DAGとは、ノード間のエッジに向きがあり、かつどこからたどっても同じノードに戻ってこないグラフ構造のことで、Makefileやnpmの依存解決でも使われる概念だ。循環検出は深さ優先探索で実装できる：

def visit(node):
    if node in visiting:
        raise CycleError(f"Cycle detected at {node}")
    if node in visited:
        return
    visiting.add(node)
    for dependency in imports_of(node):
        visit(dependency)
    visiting.remove(node)
    visited.add(node)

パスの正規化も重要な実装上のポイントだ。同じファイルが異なるエイリアスで複数回グラフに挿入されると、誤検知や検出漏れが起きる。

静的検証で早期に失敗させる

トランスパイラが実行時より前に検出すべきエラーの例：

存在しないファイルのインポート
未定義の変数参照（例：{{ namespace }} に値がない）
メタデータの欠落（owner、version、descriptionなど）
成果物のドリフト：コミット済みのコンパイル済みプロンプトとCIが生成したものの不一致

スキルファイルのフロントマターで所有者情報や評価スイートを宣言する仕組みも提案されている：

---
name: kubernetes_debugging
owner: sre-platform
description: Instructions for investigating Kubernetes workload failures.
version: 1.2.0
evals:
  - evals/image_pull_backoff.yaml
  - evals/crash_loop.yaml
---

実行時の柔軟性：プログレッシブディスクロージャー

コンパイル済みプロンプトをすべてのスキルを含むモノリスにするのではなく、コントロールプレーン（エージェントの基本ペルソナ・安全制約）は静的にコンパイルし、タスク固有のスキルはランタイムに動的取得するハイブリッドモデルも提案されている。

これを「プログレッシブディスクロージャー」と呼んでいる。エージェントが起動時点では最小限のコアプロンプトのみを保持し、実際に必要なタスクが確定した段階で該当スキルのプロンプトを取得・注入するという設計だ。エージェントが今のタスクに無関係なスキルを大量に保持しないことで、コンテキストウィンドウの削減・コスト低下・レイテンシ改善・デバッグ容易性が得られるとしている。LLMの推論コストがトークン量に比例する現状では、この最適化は本番運用において無視できない効果を持つ。

スキルの自己拡張：Agent-as-Author

さらに踏み込んだ提案が「Agent-as-Author」ワークフローだ。エージェントが必要なスキルをスキルライブラリで繰り返し検索しても見つからない場合、それはテレメトリシグナルとして記録される。このシグナルをフィードバックループとして活用し、エージェント自身が新しいスキルのプロンプト草稿を起草してレビューキューに投入する仕組みだ。

人間のレビューと承認を経てマージされた新スキルは、トランスパイラのビルドパイプラインを通じて正式な成果物として組み込まれる。スキルの発見・起草・検証・デプロイまでが1つのループに収まることで、エージェントの能力を安全かつ継続的に拡張できる体制が整う。Vertex AI Agent Builderのようなマネージド基盤と組み合わせた場合、このループの自動化がさらに現実的になる。

まとめ

本記事が提示するプロンプトトランスパイラのアプローチは、コードのビルドシステムとほぼ同じ規律をプロンプト管理に適用するものだ。依存グラフ、静的検証、決定論的成果物、CI/CDとのドリフトチェックという構成は、大規模な組織でエージェントを安全に運用するための実践的な基盤になり得る。LLMエージェントが実験フェーズから本番運用フェーズへ移行しつつある今、プロンプトをソフトウェア成果物として扱うこの発想は、今後のエンジニアリングプラクティスの標準に近づく可能性がある。

詳細はScaling AI Agents: Building a Prompt Transpiler for Production Agentsを参照していただきたい。