8月25日、Datadogが「How to adapt Golden Paths for autonomous AI agents」と題した記事を公開した。人間の開発者向けに設計されたGolden Pathsを自律型AIエージェント向けに適応させる方法について詳しく紹介されている。
確率的ステップと決定論的ステップの分離が鍵
記事の中で最も独自性が高く、実践的示唆に富むのが、確率的(probabilistic)な処理と決定論的(deterministic)な制御の分離という設計原則だ。
エージェントが判断・解釈を行うステップは確率的だ。一方、CIワークフロー、ポリシーチェック、認可、承認、デプロイルールは決定論的な制御として機能する。この二つを明確に分けることが、エージェント向けGolden Pathsの設計において最も本質的な問いとなる。
バグ修正パスを例に取ると、エージェントが問題の診断とコード変更の生成を担う一方、テスト・セキュリティスキャン・承認・マージ権限がその出力を通過させるかどうかを決める。エージェントはゲートに失敗した出力を修正できるが、ゲートを上書きしたり、自分の判断でリリース条件を満たしたと決定することはできない。確率的な操作を含みながら、ワークフローの進行は決定論的な制御下に置く——この「ハイブリッドGolden Paths」の発想が記事全体を貫く軸だ。
AIエージェントはすでにあなたのプラットフォームを使っている
AIエージェントはすでにセルフサービスAPIを呼び出し、サービスカタログを参照し、24時間体制でリソースをプロビジョニングしている。プラットフォームチームの問いはすでに「エージェントにプラットフォームを使わせるべきか?」から「エージェントが使う前提で、プラットフォームをどう進化させるか?」へと移っている。
Golden Paths(ゴールデンパス)とは、プラットフォームエンジニアリングの文脈で、開発者が推奨ワークフローを辿れるように整備されたテンプレート・自動化・ガードレールの集合体を指す。人間の開発者向けに設計されたこれらのパスを、自律的に動作するAIエージェント向けに再設計する必要がある、というのがこの記事の核心だ。
設計の軸:実行パターンとワークロード要件の対応
エージェント向けGolden Pathsを設計する際に最初に問うべきは、そのエージェントがどの実行パターンで動くかだ。
記事では実行パターンの選択を、Carnegie Mellon Software Engineering Instituteが提唱してきたAttribute-Driven Design(ADD)の原則に基づいて考えるよう推奨している。エージェント特有の課題は、実行時間の変動幅が大きく、動的にアクションが選択され、耐久性や分離性への要求が高い点にある。
リアルタイム会話エージェント:数秒〜数分のレイテンシ予算内で応答しなければならない。同期・低レイテンシの実行パターンが必要で、エンドツーエンドのデッドライン設定、個別呼び出しへのタイムアウト、デッドライン超過時の挙動定義がGolden Pathsに含まれるべきだ。ストリーミングは最初の出力までの待ち時間を短縮するが、全体の完了時間を保証するものではない点に注意が必要だ。
長時間・プロアクティブエージェント:数時間〜数日にわたって非同期で動作するエージェントには、耐久性のある再開可能な実行パターンが必要だ。Datadogは自社の内部向けLLMプロキシサービスであるAI Gatewayのローリングデプロイ時に、グレースフルシャットダウン期間が短すぎてエージェントのリクエストがタイムアウトするという問題を実際に経験している。ワークフローの状態(完了済みステップ、中間出力、保留中の承認)はモデルコンテキストやインメモリ状態とは独立して永続化する必要がある。
コード実行が必要なエージェント:開発環境でコードを実行するエージェントは、その環境の権限をそのまま継承してしまう。モデルが生成したコマンドが、エージェントプロセスと同じファイル・認証情報・ネットワークへのアクセス権を持つことになる。Golden Pathsはこれらの操作をプライマリエージェントサービスから分離した隔離サンドボックスとして外部ツールに露出させることを推奨している。
プラットフォーム能力の機械可読化と権威あるカタログ
エージェントが使うすべてのアクションには、以下を含む機械可読なコントラクトが必要だ:
- 明確な説明
- 型付きの入出力
- 安定したバージョン管理されたスキーマ
- 機械可読なレート制限とエラー分類
- 副作用・事前条件・承認要件の宣言
エラーレスポンスは「無効な入力」「認可失敗」「レート制限」「一時的な障害」「非リトライ可能なポリシー拒否」を区別できる必要がある。また、エージェントが成功後も再リクエストを送る可能性があるため、状態変更操作は可能な限りべき等(idempotent)に設計するか、べき等キーを受け付ける設計にすべきだ。
DatadogはDatadog AI Guardでプロンプト・モデルレスポンス・ツール呼び出しをセキュリティポリシーに照らして評価し、必要に応じてツール呼び出し自体をブロックする。またDatadog MCPサーバーのクエリ指向ツールでは、フィールド選択・レコード数制限・集計結果の取得を可能にすることで、評価シナリオによってはランコストを約40%削減した実績がある。
エージェントがウィキやランブックを参照しても、不完全・陳腐化・矛盾した情報を信頼性高く突き合わせることはできない。そのため、オーナーシップ・依存関係・サービス重要度・環境・サポートされるアクションを権威あるサービスカタログから取得できる設計が必要だ。カタログの精度はエージェントの判断に直接影響する。誤ったオーナー情報は承認を誤ったチームにルーティングし、欠落した依存関係は変更の影響を過小評価させる。
ディスパッチ・チェックポイント・監査ログによるコントロール
エージェント向けGolden Pathsは、なぜ実行が開始されるか・何にアクセスできるか・どこで実行されるか・結果がどう記録されるかを明示的に定義する必要がある。
ディスパッチ(実行開始)は明示的なステップとして設計し、誰が何の目的でエージェントを起動したかを記録する。ワークフローにはチェックポイントとリトライ予算を組み込み、エージェントが同じアクションを繰り返してコストや副作用が際限なく増大しないよう制御する。また、エージェントのすべての行動は監査ログとして残し、可視性とアカウンタビリティを確保する必要がある。
詳細はHow to adapt Golden Paths for autonomous AI agentsを参照していただきたい。