HN 日本語サマリー

← 一覧へ戻る
AI・機械学習

スケーラブルなAIエージェントをモジュラープロンプト変換で構築する

Building scalable AI agents with modular prompt transpilation (developers.googleblog.com)

7 pointsby yruzin1 コメント

要約

プロダクションスケールでのAIエージェント開発において、単一の巨大なプロンプトファイルは管理が困難になります。この記事では、プロンプトをビルドアーティファクトとして扱い、モジュール化されたスキルファイルに分割し、トランスパイラを使用して依存関係を解決・検証するアプローチを紹介しています。これにより、プロンプトの保守性、信頼性、テスト容易性が向上し、エージェント自身が指示レイヤーの改善を提案するワークフローも可能になります。

全文翻訳

モジュラープロンプト変換によるスケーラブルなAIエージェントの構築 2026年7月16日 Simerus Mahesh サイト信頼性エンジニア 共有 Facebook Twitter LinkedIn Mail AIエージェントを最初に構築する際は、単一のモノリシックなシステムプロンプトで十分な場合が多いです。いくつかの指示、おそらく1つか2つのツール定義があり、すべてが1つの読みやすいファイルに収まっています。 しかし、本番用途での使用を開始すると、その形式は単純に破綻します。チームは、安全性ポリシー、ドメイン固有のルール、フォーマット要件、エスカレーション動作を重ねて適用し始めます。突然、エージェント全体のコントロールプレーンが単一の指示ファイル内に存在することになり、まさに問題の始まりです。 これは典型的なソフトウェアエンジニアリングのスケーリング問題です。すべての懸念事項を1つのファイルに押し込むと、システムを推論する能力を失います。コラボレーションは悪夢になり、テストは難解になり、1つのワークフローを改善するための小さな変更が、静かに別のワークフローを壊す可能性があります。 本番スケールでは、プロンプトの保守性がエージェントの信頼性になります。 モノリシックなプロンプトが破綻する理由 プロンプトがあるサイズを超えて成長すると、通常3つの主な障害モードが見られます。 不明瞭な影響範囲: 標準的なソフトウェアエンジニアリングでは、モジュール境界、呼び出しサイト、テストを通じて変更のスコープをレビュー担当者が推論するのは容易です。しかし、システムプロンプトの差分はより困難です。1文を追加するだけで、エージェント全体にわたって意図しない副作用が生じる可能性があり、これは予測したりテストしたりするのが難しいことがよくあります。 コピー&ペーストのずれ: 組織が拡大するにつれて、多くのチームが、内部サービスの使用方法、PII(個人識別情報)の処理、安全性ポリシー、エスカレーションプロトコルなどのさまざまなアプリケーションのために共有ロジックを複製することになります。これにより、同じ機能のコピー&ペーストや複数のバージョンが発生し、一貫性が失われます。 遅延した実行時エラー: スパロール(散らばり)を管理するために、チームはしばしばアドホックな文字列フォーマットや単純なテンプレートに頼ります。これは作成には役立ちますが、エラー検出を実行時に押しやります。特定の、まれに使用されるワークフローが、欠落した変数や無効なインポートパスのために失敗するプロンプトをデプロイする可能性があります。 テンプレートは良い出発点ですが、それだけでは十分ではありません。本番システムには、決定論的なビルド、静的検証、CI/CD統合が必要です。 プロンプトをソフトウェアアーティファクトとして扱う ここでの解決策は、プロンプトを単なる静的なテキストとしてではなく、ビルドアーティファクトとして扱うことです。 1つのモノリシックなプロンプトファイルを維持する代わりに、モジュラーなスキルファイルを作成できます。これにより、各ファイルのスコープを縮小し、特定の動作をカプセル化できるため、チームは関心を分離し、コンポーネントを個別にイテレーションできます。 トップレベルのエージェントプロンプトテンプレートは、次のようになります。 # agents/sre_agent.prompt.md (プロンプトテンプレートファイル) {% include "shared/safety.prompt.md" %} {% include "shared/tool_usage.prompt.md" %} あなたは{{ environment }}環境で動作するSREトリアージエージェントです。 {% if allow_remediation %} あなたは修復手順を推奨できますが、破壊的なアクションには人間の承認が必要です。 {% else %} あなたは問題を検査、要約、説明できますが、修復アクションを推奨することはできません。 {% endif %} {% macro bullet_section(title, items) %} ## {{ title.rstrip() }} {% for item in items %} - {{ item.rstrip() }} {% endfor %} {% endmacro %} {{ bullet_section("必要な調査手順", [ "最近のデプロイイベントを検査する", "レイテンシまたはエラー率の変化についてサービスメトリクスを確認する", "繰り返し発生する失敗パターンについてログを確認する" ]) }} プレーンテキスト コピー済み これにより、両方の世界の利点が得られます。テンプレートレイヤーにより、共有指示を構成し、環境固有の値を注入し、マクロを使用できます。しかし、ビルドシステムにとっては、各includeは依存関係であり、各変数は要件です。結果として、モデルに到達する前にテスト、監査、diffできる、決定論的で完全にレンダリングされたアーティファクトが得られます。次に、トランスパイラを使用してテンプレートのincludeを解決し、エージェントが取り込めるファイルを作成できます。 たとえば、environment = production かつ allow_remediation = true の場合、トランスパイルされたアーティファクトは次のようになります。 あなたは本番環境で動作するSREトリアージエージェントです。 あなたは修復手順を推奨できますが、破壊的なアクションには人間の承認が必要です。 ## 必要な調査手順 - 最近のデプロイイベントを検査する - レイテンシまたはエラー率の変化についてサービスメトリクスを確認する - 繰り返し発生する失敗パターンについてログを確認する プレーンテキスト コピー済み 高レベルのトランスパイルパイプラインは次のようになります。 ビルド時検証は必須です 本番グレードのトランスパイラは、実行時前にエラーを検出する必要があります。 ビルドプロセス中に、欠落しているinclude、未定義の変数、循環依存関係の検証チェックを実行する必要があります。依存関係グラフはここで非常に役立ち、堅牢なテンプレートエンジンの必要性を強化します。各プロンプトフラグメントを有向グラフのノードとして扱うと、本番環境で静かな失敗を引き起こす可能性のある再帰的なincludeを簡単に検出できます。これにより、ドリフトチェックも可能になります。 CIパイプラインを設定して、ソース(ゴールデンファイルと呼ばれる)からトランスパイルされたプロンプトを再生成し、現在コミットされているアーティファクトと比較できるようにします。出力が異なる場合、ビルドは失敗します。これにより、リポジトリ内のコードが本番環境で実行されているものとまったく同じであることが保証され、ソースファイルとデプロイされたアーティファクトの間のギャップがなくなります。 動的なスキルとエージェント作成の更新 モジュラープロンプトフラグメントのスキルライブラリが成長するにつれて、すべてのエージェントが毎回すべてのスキルをロードする必要はありません。そうするとトークンが消費され、エージェントのタスク固有のパフォーマンスに干渉する可能性のあるノイズが導入されます。 より良いアーキテクチャパターンは、プログレッシブ開示を活用することです。これは、安定したコントロールプレーンをタスク固有のコンテキストから分離する場所です。コンパイルされたベースプロンプトは、IDや安全性境界などの譲れない動作を強制する必要があります。次に、実行時に、エージェントはツールを使用して、その時点で実際に必要な特定のスキルモジュールのみを動的に取得できます。これにより、コンテキストの枯渇が減り、エージェントがタスクに集中し続けるのに役立ちます。 このモジュラーシステムがあれば、強力なワークフローがアンロックされます。エージェントは、それ自体の指示レイヤーの維持を支援し、自己持続的なエージェントシステムを作成するのに役立ちます。エージェントが新しいタイプのインシデントを解決すると、理論的には新しいスキルモジュールを作成し、関連するincludeを更新し、プルリクエストを開くことができます。 エージェントは自身の指示をリアルタイムで変更しているのではなく、コード変更を提案しています。トランスパイラは、その提案を他のコード変更と同様の検証およびレビューの厳格さにさらします。人間のレビュー担当者はPRを検査し、評価を実行し、変更をマージできます。 結論 本番プロンプトトランスパイラは、プロンプトエンジニアリングをビルドシステムの問題として再構築します。 モジュラーなスキルファイルを構築すると、標準的なソフトウェアインフラストラクチャと同じように、依存関係を解決し、includeを検証し、ドリフトチェックを強制できます。エージェントは、変更が既存の検証およびレビュープロセスを通過することを条件に、自身のロジックの改善を提案できるようになります。 AIエージェントが重要なワークフローに深く統合されるにつれて、それらの指示レイヤーは、ソフトウェアに要求するのと同じ信頼性基準を必要とします。プロンプトは編集されるだけでなく、構築、検証、バージョン管理、デプロイされる必要があります。 投稿先: AIベストプラクティス 業界トレンド ソリューション Learn CI/CD 生成AI 影響力 インスピレーションを得る AIエージェント エージェントインフラストラクチャ プロンプトエンジニアリング 前へ 次へ 関連投稿 AI Cloud アナウンスメント ベストプラクティス GoogleのAgent Development KitとA2Aでクロス言語マルチエージェントチームを構築 2026年6月22日 AI Cloud アナウンスメント ソリューション Gemini Enterprise Agent Platformの選択肢を拡大: 並列Web検索によるグラウンディングの導入 2026年7月16日 AI Cloud How-To Guides ベストプラクティス ADK 2.0を構築した理由 2026年7月1日 Web AI アナウンスメント Learn Googleの高性能ライブラリLiteRT.js