Google、AIエージェントのプロンプトもビルド・検証するべきだと提案

何が発表されたのか

Google Developers Blogは7月16日の公式記事で、AIエージェントのシステムプロンプトをproduction prompt transpilerでビルド・検証する手法を説明しました。ここでのポイントは「もっと気の利いた文章を書こう」ではなく、プロンプトをソフトウェア成果物のように扱おうという提案です。

AIエージェントを作り始めた段階では、長いシステムプロンプト1本でも十分な場合があります。しかし実際の業務に組み込むと、安全ポリシー、ツール利用ルール、ドメイン知識、出力形式、エスカレーション条件が次々に加わります。Googleは、この状態になると単一のプロンプトファイルがエージェントのcontrol plane全体を背負うことになり、小さな修正が別の作業を壊す可能性があると説明しています。

なぜ長いプロンプト1本が危険になるのか

Googleが指摘した問題は大きく3つあります。1つ目は、変更の影響範囲が見えにくくなることです。コードであればモジュールの境界やテストによってどの部分が変わったのか分かりますが、システムプロンプトの1行は複数のワークフローに同時に影響することがあります。

2つ目は、コピー＆ペーストしたルールが少しずつ食い違っていくdriftです。個人情報の扱い、安全ポリシー、社内サービスの使い方といった共通ルールを複数のエージェントへコピーすると、バージョンが少しずつずれる可能性があります。3つ目は、変数の抜けや誤ったincludeのようなエラーが、デプロイ前ではなく特定の作業が実行された瞬間に表面化し得ることです。

モジュール式プロンプトとtranspilerの役割

Googleの提案は、プロンプトを小さなskillファイルやtemplateの断片に分け、最終実行の前にtranspilerがそれらをまとめて完成版を作る方式です。たとえば安全ルール、ツール利用ルール、SRE調査手順をそれぞれ別ファイルに置き、上位のエージェントプロンプトが必要な断片をincludeする形です。

こうすると、build systemは各includeを依存関係として扱い、変数の欠落、循環依存、誤ったパスをデプロイ前に検出できます。分かりやすく言えば、AIに渡す指示文を手紙のようにそのまま送るのではなく、組み立て説明書のように検査してから渡す方式です。

なぜCI/CDとドリフトチェックが関わるのか

Googleは、production-gradeなtranspilerであれば、missing import、undefined variable、circular dependencyをbuild processで検出すべきだと述べています。さらにCIがソースファイルから最終プロンプトを作り直し、現在コミットされている成果物と比較するdrift checkも提案しています。

この視点が重要な理由はシンプルです。チームが実際に運用するエージェントであれば、「ソースに書かれたルール」と「実際にモデルへ渡されるルール」は一致していなければなりません。ソースとデプロイ成果物がずれていれば、レビューを通過したルールが実行時には抜けていたり、逆に古いルールが残り続けたりする可能性があります。

必要なときだけskillを呼び出す流れ

記事では、すべてのskillを毎回プロンプトに入れる方式にも注意が必要だと説明しています。skillライブラリが大きくなるとトークンを多く使い、現在の作業と関係のない指示がモデルの判断を曇らせる可能性があるためです。

そこでGoogleは、安定した基本control planeと作業別contextを分けるprogressive disclosureに触れています。基本プロンプトはアイデンティティや安全境界のような譲れないルールを守り、実際の作業では必要なskill moduleだけをツールとして呼び出す構造です。これはHermes Agentのようなツール型エージェントを長く運用するうえでも重要なパターンです。

どんな読者に意味があるのか

この話題は、一般的なChatGPTユーザーがすぐ体感できる新機能発表ではありません。ただし、AIエージェントを業務、開発、運用、カスタマーサポートに組み込みたいチームにとってはかなり直接的です。今後のエージェント競争は、モデル性能だけでなく指示文をどれだけ安全にバージョン管理し、検証できるかによっても分かれる可能性があります。

とはいえ、すべてのプロジェクトが最初からこの構造を持つべきという話ではありません。小さな個人向け自動化であれば、単一プロンプトと簡単なテストでも十分なことがあります。重要な基準は、エージェントが複数人の業務を代行したり、安全ポリシー、権限、ツール実行を扱い始めたりする瞬間です。その段階では、プロンプトもコードと同じようにビルド、検証、レビュー、デプロイの対象として見る必要があります。