はじめに｜なぜ“AI × DesignOps”なのか？ プロダクトが成長すればするほど、ビジュアルアセットの需要は指数関数的に増えていきます。しかし、デザイナーの数は（悲しいことに）指数関数的には増えません。 従来のイラスト制作は個人のスキルに依存しやすく、結果として品質のバラツキや制作スピードが開発ベロシティを阻害する「 デザイン負債（Design Debt） 」を生み出していました。DesignOps の本質は、デザインを「一点物のマニュアルアート」から「再現可能なシステム」へと昇華させることにあります。 私たちは今回、AI を単なる「便利な魔法の筆」ではなく、一貫性のあるデザインシステムを支える「 レンダリングエンジン 」として再定義する検証を行いました。 DesignOpsとは？ 「DesignOps（デザインオプス）」という言葉、デザイナー以外にはまだ少し耳慣れないかもしれません。 簡単に言うと、 DesignOps は 「 デザイン版の DevOps 」です。 属人的になりがちなデザイン業務をプロセスとして整理し、担当者が変わってもチームとして一定の品質をデプロイできる状態を目指す考え方です。 今回の取り組みでは、生成 AI を「クリエイティブな遊び」としてではなく、プロダクトのコードベースの一部のように運用できるかを検証しました。特にエンジニア主体の組織においては、デザインも「 ロジックとして扱えるか 」が、持続可能な運用の鍵になります。 プロジェクトの背景：Unlimited App で直面した「成長の痛み」 Unlimited App ではこれまで、プロダクトデザイナーがイラストの世界観設計から品質の最終調整まで、いわば「職人のこだわり」をもって一貫して担ってきました。しかし、プロダクトが成長し、機能追加やコンテンツ拡張が加速するなか、必要とされるイラストの量と展開範囲は、私たちの想像を超えるスピードで拡大していきました。 https://kinto-jp.com/unlimited/app/ その過程で、個人の努力だけではカバーしきれない「 構造的なボトルネック 」が浮き彫りになってきたのです。 工数の比例増加 ：表現を都度最適化する運用では、制作アセット数に比例して工数も積み上がっていく（まさに O(n) の世界です）。 再現性の設計難度 ：クオリティの判断が個人の経験値に依存しやすく、「なぜこれが正解なのか」という基準を仕組みとして残しづらい。 属人的なバランス調整 ：スピードと完成度のトレードオフを、常に個人の「さじ加減」で調整し続けなければならない。 これらは決して個人のスキルの問題ではなく、プロダクトが次のステージへ進むために解決すべき「 システム上の課題 」でした。 そこで生まれたのが、「 イラスト制作を個のスキルに依存する形から、再現性のある設計へとリファクタリングできないか？ 」という問いです。私たちはこの問いに対し、生成 AI という強力なエンジンを DesignOps のプロセスに組み込むことで、持続可能な制作体制の構築に挑みました。 ※ [ ちょこっと技術解説 ]： O(n) とは？ エンジニアがよく使う「計算量」を測る指標です。ここでは「描くイラストの枚数（ n ）」が増える分だけ、「制作時間」も正直に増えていくという 線形の現実 を指しています。 つまり、「 単なる「魔法」ではなく、10 倍の依頼が来たら 10 倍の工数が必要になる 」という、デザイナーにとっては少し切ない、そしてエンジニアにとっては「今すぐ最適化（リファクタリング）したい！」と血が騒ぐ状態のことです。 今回の検証アプローチ｜“AIに寄せる” vs “AIを寄せる” AI を活用する際、戦略は大きく 2 つに分かれます： AI に寄せる（AI-Native Approach） AI が得意な表現（原生スタイル）をそのまま受け入れ、効率を最大化する。「AI っぽさ」を味方につける手法です。 AI を寄せる（Brand-Centric Approach） 独自のブランドアイデンティティに基づき、AI の出力を厳格に制御する。 Unlimited App はすでに確立された世界観を持つプロダクトです。そのため、前提条件として「AI を寄せる」 アプローチを選択しました。これは、プロンプトを単なる命令文ではなく、ブランドの 「デザイン・トークン（Design Tokens）」 として定義し、AI という不確実な実行環境において 「決定論的な出力（Deterministic Output）」を目指す、エンジニアリング的な挑戦でもあります。 イラスト標準化の設計思想とプロンプトアーキテクチャ 「AI なら、プロンプトひとつで何でも描いてくれるのでは？」——そんな期待は、運用フェーズに入った瞬間に崩れ去ります。実用的な DesignOps において、プロンプトは単なる「魔法の呪文」ではありません。明確な設計意図を AI へ伝えるための、厳密な「 インターフェース 」であるべきです。 標準化プロセスの構築にあたり、筆者は下図のような 7つのステップ を策定しました。ビジュアル定義の抽出（Step 1）からリファレンスの整理（Step 4）までは、いわば「 視覚的な仕様書 （ Visual Spec ）」を書き上げる、設計の根幹を支えるフェーズです。 Step 1〜4：プロンプトを「エンジニアリング」するための前処理 Step 1｜ビジュアル定義の抽出（Extracting Visual Tokens） 最初に取り組んだのは、デザインシステムとの整合性チェックです。2.5D の立体感、余白の持たせ方、低コントラストな配色……。これらを言語化する工程は、後に解説する 「 Style Tokens （ スタイル定数 ）」 の基盤となります。 Step 2｜イラスト用途の分類（Defining the Scope） 生成 AI の活用範囲を「クリエイティブな表現」ではなく、「 UX を補助するインフォグラフィック 」 と定義しました。目的を限定することで、維持すべき「再現性」と、AI に任せるべき「表現幅」の境界線が明確になります。 Step 3 & 4｜リファレンスの構造解体（Deconstructing References） 大量のリファレンスを収集し、「好き嫌い」という感性ではなく、構図や影の強度といった「 Visual Spec（視覚仕様） 」として分解・整理しました。「なんとなく似ている」を「仕様通りである」に変えるための、最も泥臭く、かつ重要なリサーチ工程です。 この Step 1〜4 の本質は、「 AI に依存しない設計構造を人間側で作る 」 ことにあります。 このプロセスで最もエキサイティングであり、かつ重要なのが Step 5 の「プロンプト作成」 です。ここを単なる「作文」にせず、 エンジニアリング的に構造化された工程 として設計しました。 具体的には、プロンプトを以下の 2 層構造（Layered Architecture） として定義しています： Part 1：Style Tokens（スタイル定数層） 線画の太さ、立体感、陰影のルール、配色など、プロダクトの DNA を定義します。「何を描くか」に依存しない、 再利用可能な Constant（定数）レイヤー です。 Part 2：Content Variables（コンテンツ変数層） 「車」「人物」「スマホを持つ手」など、画面ごとに差し替え可能な Dynamic Variable（動的変数）レイヤー です。 この 「 スタイルとコンテンツの解耦（Decoupling） 」 こそが、DesignOps 視点での解決策です。これにより、「何を描いても同じトーンで出力される」という、デザイナーにとっての聖杯（Holy Grail）を目指しました。 ツールごとに異なる「Prompt の最適解」 検証を進める中で面白いことが分かりました。AI ツールごとに「プロンプトの癖」が全く違うのです。以前は同一のプロンプトで比較していましたが、現在は「構造（Part 1 / Part 2）は共通、実装（実際の記述）は各ツールに最適化」 という方針に切り替えました。 「プロンプトを共有する」のではなく、 「プロンプトを設計するインターフェース（ルール）を共有する」。この方が、ツールの進化に柔軟に対応できる持続可能な仕組みになります。 徹底検証：生成 AI 3 社の「性格診断」—— イラスト標準化の最適解を探る 2025年10月時点の Midjourney 検証 まずは、2025年10月に行った Midjourney（V7）での検証結果です。 当時の出力は、視覚的な完成度が非常に高く、一枚絵としての魅力は群を抜いていました。 しかし、標準化という観点では、いくつかの課題が見えてきました。 装飾的な要素が多く、情報量がやや過剰 構図がダイナミックで、並べた際の統一感が出にくい ブランドトーンよりも「生成AIらしさ」が前面に出る傾向 つまり、 創造性は高いが、制御性が低い。 この特性はクリエイティブ用途には適していますが、UI内で量産・運用するインフォグラフィック用途には不向きであると判断しました。 ChatGPT / Gemini へのシフト Midjourney との比較を経て、検証の軸を「表現力」から「再現性」へとシフトしました。 同一のビジュアルリファレンスと構造化プロンプトを用い、ChatGPT および Gemini で出力を比較しました。 この時点で明確になったのは、 ChatGPT は構図の安定性が高い Gemini はクリーンだが、再解釈が入る傾向がある という違いでした。 最新検証：観点別比較 プロンプトの構造を定義したところで、次なるステップは「どの実行エンジン（AI モデル）が最も安定して仕様通りに動くか」のベンチマークテストです。私たちは、構図・人物・色彩・命令遵守性の 4 つの観点から、プロダクト運用への適性を評価しました。 ① 構図の安定性—— UI に馴染むか？ インフォグラフィックにおいて、余白と主体のサイズ感は「UI の整合性」に直結します。 ChatGPT は視点・余白・被写体のバランスが安定しており、複数枚を並べた際の一貫性が高い結果となりました。 一方 Gemini は、微妙な視点変更や背景処理の差異が発生しやすく、量産時の揺らぎがやや大きい傾向が見られました。 ② 人物表現の精度—— 意図が伝わるか？ 「シートベルトを締める」「スマホを見る」といった具体的な動作の正確さを検証しました。 人物の顔パーツ・視線・身体バランスにおいて、ChatGPT は安定したクオリティを維持しました。 Gemini は柔らかいトーンで描写される一方、表情や骨格の一貫性に若干のばらつきが見られました。 ③ 用色とブランド整合性 ChatGPT は指定した色調レンジを忠実に守る傾向が強く、ブランドトーンとの整合性が高い結果となりました。 Gemini は自然なグラデーション処理を行う反面、色相・彩度が微妙に変化するケースがあり、厳密なトーン統制には追加調整が必要でした。 ④ 命令遵守性（Instruction Following）—— 仕様書通りに動くか？ 最も大きな差はここでした。 ChatGPT はプロンプト構造（Part 1 / Part 2）をほぼそのまま出力に反映する傾向が強く、設計思想と出力結果の対応関係が明確でした。 Gemini は意図を解釈し、最適解を“再構成”する挙動が見られ、創造性は高いものの、決定論的制御はやや難しいという印象です。 ※ 正密に Gemini が過度な再解釈を試みるからこそ、私たちは Part 1（定数層）において、より厳密なビジュアルのガードレールを定義し、封鎖（Lockdown）する必要があるのです。 各ツールの本性：創作のパートナーか、信頼の実行エンジンか Midjourney：気分屋な天才アーティスト 2025 年 10 月時点の検証では、Midjourney は 圧倒的な 「 映え 」を誇りました。一枚絵としての完成度は素晴らしいのですが、標準化という観点では少し「個性が強すぎ」ました。 情報量が多すぎて UI の邪魔をしてしまう。 構図がダイナミックすぎて、並べた時に統一感が出にくい。 つまり、「 クリエイティブな爆発力はあるが、規律を守るのが苦手なタイプ 」です。 Gemini：再解釈を試みるクリエイティブ・ディレクター Gemini 3 Flash などの最新検証では、非常にクリーンな UI イラストを生成してくれますが、時折「自分の色」を出したがる傾向があります。 構図や余白が毎回少しずつズレる「自由奔放さ」。 プロンプトを忠実に守るというより、「 意図を汲み取ってリミックスしてしまう 」挙動が見られました。これは創作には良いですが、量産プロセスでは「予測可能性」を下げる要因になります。 ChatGPT (DALL-E)：仕様書通りに動くシニアエンジニア 対照的に ChatGPT は、 プロンプトの構造をそのまま出力に反映する能力 （ Instruction Following ）が極めて高いことが分かりました。 構図が安定し、用色も保守的でルール化しやすい。 まさに DesignOps における 「 信頼できる実行エンジン 」 です。 「イラストを作る（Make）」ツールではなく、「運用する（Ops）」ツール としての適性が最も高いと判断し、現在は ChatGPT を中心に検証を進めています。 ※ もちろん、表現の幅や偶発的なひらめきという点では、Midjourney や Gemini に軍配が上がる場面もあります。 実装結果：Unlimited App で何が変わったのか？ 確立した標準スタイルは、現在 Unlimited App 内の「車種別イラスト」や「レベル選択カード」などで試験的に運用されています。「 AI で 8 割のベースを生成し、人間が最後の 2 割を整える 」というフローにより、制作スピードと一貫性が（ついに！）両立し始めました。 しかし、この取り組みは Unlimited App という「実験場」だけで完結するものではありません。私たちが構築したプロンプトの 2 層構造は、いわばデザインの「共通プロトコル」です。将来的には、「スタイル定数（Part 1）」というコンフィグを各ブランドの DNA に合わせて差し替えるだけで、社内のあらゆるプロダクトやサービスへこの仕組みを横展開（スケール）させていくことを目見据えています。プロダクトを跨いで「一貫性のあるビジュアルを即座にデプロイできる」状態——これこそが、私たちが目指す真の DesignOps の姿です。 やってみて分かった課題 数ヶ月の検証で分かったのは、プロンプトには「 賞味期限（Prompt Rot） 」があるということです。ツールのアップデートにより、昨日まで動いていた魔法の言葉が、今日には効かなくなる。 そのため、プロンプトを一度作って終わりにするのではなく、 継続的にリファクタリングしていく前提の設計 が必要です。今後は、これらのメンテナンスを自動化する「AI Agent 的なアプローチ」も視野に入れています。 まとめ：AI × DesignOps は何を変えうるのか 今回の検証を通じて確信したのは、生成 AI は単なる「魔法」ではなく、 DesignOps を再設計するための強力なトリガー であるということです。 標準化とは、自由を奪うことではありません。むしろ、「 どこを固定し（Constants）、どこを柔軟にするか（Variables） 」を定義することで、変化の激しいプロダクト開発においてクリエイティブな安定走行を可能にする行為です。 DesignOps は、デザインを「属人的な手癖」から「再現可能なプロセス」へと拡張します。この取り組みが、皆さんのプロダクトにおけるクリエイティブ運用のヒントになれば幸いです。

DevOpsは、ソフトウェア開発とIT運用のコラボレーションを強化し、プロセスの自動化を通じて迅速かつ高品質なソフトウェア提供を目指す文化とツールの総称です。本記事では、DevOpsの主な要素、トレンド、メリットとデメリットを紹介しています。

本記事は 2026 年 1 月 15 日 に公開された「 From AI agent prototype to product: Lessons from building AWS DevOps Agent 」を翻訳したものです。 re:Invent 2025 で Matt Garman は、インシデントを解決し、事前に防止することで、信頼性とパフォーマンスを継続的に改善するフロンティアエージェントである AWS DevOps Agent を発表しました。DevOps Agent チームのメンバーとして、私たちは 「インシデント対応」 機能が有用な発見と観察結果を生成できるよう注力してきました。特に、ネイティブな AWS アプリケーションの根本原因分析が正確かつ効率的となるように取り組んでいます。内部的には、DevOps Agent はマルチエージェントアーキテクチャを採用しており、リードエージェントがインシデントコマンダーとして機能します。リードエージェントは症状を理解して調査計画を作成し、コンテキスト圧縮が有効なタスクは専門のサブエージェントに委任します。サブエージェントはクリーンなコンテキストウィンドウでタスクを実行し、圧縮した結果をリードエージェントに報告します。例えば、大量のログレコードを調査する際、サブエージェントはノイズをフィルタリングし、関連するメッセージのみをリードエージェントに提示します。 本記事では、実用的なエージェント製品を構築するために必要なメカニズムに焦点を当てます。大規模言語モデル (LLM) を使ったプロトタイプ構築は参入障壁が低く、動作するものを比較的早く見せられます。しかし、プロトタイプを超えて多様な顧客環境で確実に動作する製品へと進むのは全く別のチャレンジであり、過小評価されがちです。本記事では、AWS DevOps Agent の構築で学んだことを共有し、皆さん自身のエージェント開発に活かしていただければと思います。 私たちの経験では、エージェントの品質を継続的に改善し、プロトタイプから本番環境へのギャップを埋めるには 5 つのメカニズムが必要です。まず、 評価テスト (evals) を実施する必要があります。これにより、エージェントの失敗箇所と改善可能な領域を特定し、同時にエージェントが得意とするシナリオのタイプについて品質のベースラインを確立します。次に、エージェントの軌跡をデバッグし、どこで間違ったかを正確に把握するための 可視化ツール が必要です。3 つ目に、失敗したシナリオをローカルで再実行して反復できる 高速なフィードバックループ が必要です。4 つ目に、確証バイアスを避けるためシステムを変更する前に成功基準を確立する、 意図を持った変更 が必要です。最後に、定期的に 本番環境のサンプルを読んで 、実際の顧客体験を理解し、まだ評価されていない新しいシナリオを発見する必要があります。 評価 評価は、従来のソフトウェアエンジニアリングにおけるテストスイートの機械学習版です。他のソフトウェア製品と同様に、良いテストケースの蓄積が品質への信頼を築きます。エージェントの品質を反復的に改善することはテスト駆動開発 (TDD) に似ています。エージェントが失敗する評価シナリオがあり (テストが Red)、エージェントが合格するまで変更を加えます (テストが Green)。評価に合格することは、エージェントが正しい推論を通じて正確で有用な出力に到達したことを意味します。 AWS DevOps Agent では、個々の評価シナリオのサイズは、従来のソフトウェアエンジニアリングの テストピラミッド におけるエンドツーエンドテストに相当します。 “Given-When-Then” スタイルのテストの観点から見ると: Given – テストのセットアップ部分は、作成に最も時間がかかる傾向にあります。AWS DevOps Agent の評価シナリオの例として、 Amazon Elastic Kubernetes Service 上で動作するアプリケーションを考えます。複数のマイクロサービスで構成され、 Application Load Balancer をフロントに配置し、 Amazon Relational Database Service データベースや Amazon Simple Storage Service バケットなどのデータストアに読み書きし、 AWS Lambda 関数がデータ変換を行います。依存関係の深い部分で S3 への書き込みに必要な AWS Identity and Access Management (IAM) 権限を誤って削除するコード変更をデプロイして障害を注入します。 When – 障害が注入されるとアラームが発火し、AWS DevOps Agent が調査を開始します。評価フレームワークは、 DevOps Agent ウェブアプリケーション がレンダリングするのと同様に、エージェントが生成する記録をポーリングします。このセクションは、統合テストやエンドツーエンドテストでアクションを定義するのと根本的に変わりません。 Then – 複数のメトリクスを検証し、その結果をレポートします。基本的に、品質に対しては単一の “PASS” (1) または “FAIL” (0) メトリクスがあります。DevOps Agent のインシデント対応機能では、”PASS” は正しい根本原因が顧客に提示されたことを意味します。今回の例では、障害のあるデプロイを根本原因として特定し、依存関係のチェーンをたどって、影響を受けるリソースと S3 書き込み権限の不足を明らかにする観察結果を提示することです。それ以外は “FAIL” です。私たちはこれを ルーブリック として定義しています。「エージェントは根本原因を見つけたか？」だけでなく、「エージェントは正しい裏付けの証拠に基づいて正しい推論を行い、根本原因に到達したか？」を評価します。グラウンド・トゥルース (ソフトウェアテスト用語で “expected” や “wanted”) とシステムの応答 (“actual”) は LLM Judge を介して比較されます。LLM Judge とはグラウンド・トゥルースとエージェントの実際の出力の両方を受け取って、推論し、それらが一致しているか判定する LLM です。比較に LLM を使用するのは、エージェントの出力が非決定論的であるからです。つまり、エージェントは全体的には出力形式に従いますが、実際のテキストは自由に生成されるため、実行ごとに異なる単語や文構造を使用しながら同じ意味を伝える可能性があります。最終的な根本原因分析レポートではキーワードを厳密に検索するのではなく、ルーブリックの本質が満たされているかを評価したいのです。 評価レポートは、シナリオを行、メトリクスを列として構成されます。追跡する主要なメトリクスは、「能力」 (pass@k – k 回の試行で少なくとも 1 回合格したか)、「信頼性」 (pass^k – k 回の試行で何回合格したか、例えば k=3 で 3 回中 1 回合格なら 0.33)、「レイテンシー」と「トークン使用量」です。 評価が重要な理由 評価を行うことには複数の利点があります: 赤いシナリオは、エージェント開発チームが製品の品質を向上させるための明確な調査ポイントを提供します。 時間の経過とともに、緑のシナリオは回帰テストとして機能し、システムの変更によって既存の顧客体験が低下した場合に通知されます。 合格率が緑になったら、その他のメトリクスに基づいて顧客体験を改善できます。例えば、品質水準を維持しながらエンドツーエンドのレイテンシーを削減したり、コスト (トークン使用量で代用) を最適化したりできます。 評価の課題 高速なフィードバックループは、開発者がコードが機能するか (正しいか、パフォーマンスが良いか、安全か)、アイデアが良いか (主要なビジネスメトリクスを改善するか) を知るのに役立ちます。当たり前に思えるかもしれませんが、チームや組織が遅いフィードバックループを許容していることがあまりにも多いのです […] — Nicole Forsgren and Abi Noda、 Frictionless: 7 Steps to Remove Barriers, Unlock Value, and Outpace Your Competition in the AI Era 評価にはいくつかの課題があります。難易度の高い順に: 現実的で多様なシナリオの作成が難しい 。現実的なアプリケーションと障害シナリオを考え出すのは困難です。忠実度の高いマイクロサービスアプリケーションと障害を作成するには、業界経験を要する大変な作業です。効果的だと分かったのは、いくつかの「環境」(実際のアプリケーションアーキテクチャに基づく) を作成し、その上に 多くの 障害シナリオを作成することです。環境整備は評価のセットアップにおける高コストな部分なので、複数のシナリオで最大限に再利用します。 遅いフィードバックループ 。「Given」の評価シナリオのデプロイに 20 分かかり、その後「When」の複雑な調査が完了するのにさらに 10〜20 分かかるとしたら、エージェント開発者は変更内容を徹底的にテストしません。代わりに、1 回の合格した評価で満足して本番環境にリリースしてしまい、包括的な評価レポートが生成されるまでリグレッションを引き起こす可能性があります。また、フィードバックループが遅いと、小さく段階的な実験ではなく複数の変更をまとめて実施する傾向が強まり、どの変更が実際に効果をもたらしたかを把握するのが難しくなります。私たちは、フィードバックループを高速化するには3 つのメカニズムが効果的であると発見しました: 評価シナリオのための 長期稼働環境 。アプリケーションとその正常状態は一度作成され、稼働し続けます。障害注入は定期的に (例えば週末に) 行われ、開発者はエージェントの認証情報を障害のある環境に向けることで、テストの「Given」部分を完全にスキップできます。 重要なエージェント領域のみの 分離テスト 。私たちのマルチエージェントシステムでは、開発者はエンドツーエンドフロー全体を実行するのではなく、過去の評価実行からのプロンプトで特定のサブエージェントを直接トリガーできます。さらに、「フォーク」機能を構築しました。これにより開発者は、失敗した実行から特定のチェックポイントメッセージまでの会話履歴を保持した任意のエージェントを初期化して、残りの軌跡のみを反復できます。どちらのアプローチも「When」部分の待ち時間を大幅に短縮します。 エージェントシステムの ローカル開発 。開発者がテスト前に変更をマージしてクラウド環境にリリースしなければならない場合、ループが遅すぎます。ローカルで実行することで迅速な反復が可能になります。 軌跡の可視化 エージェントが評価や本番実行で失敗した場合、どこから調査を始めますか？最も生産性の高い方法は エラー分析 です。エージェントの完全な軌跡、つまりサブエージェントの軌跡を含むユーザー・アシスタント間のすべてのメッセージ交換を可視化し、各ステップに “PASS” または “FAIL” の注釈をつけ、何が間違っていたかメモを残します。このプロセスは面倒ですが効果的です。 AWS DevOps Agent では、エージェントの軌跡は OpenTelemetry トレースにマッピングされ、 Jaeger などのツールで可視化できます。 Strands などのソフトウェア開発キットは、最小限のセットアップでトレース統合を提供します。 図 1 – AWS DevOps Agent のサンプルトレース 各スパンにはユーザー・アシスタントのメッセージの組み合わせが含まれています。各スパンの品質を次のような表で注釈付けします: このローレベルの分析は、1 つだけでなく複数の改善点を一貫して明らかにします。1 つの評価が失敗すると、一般的に精度、パフォーマンス、コストにまたがる多くの具体的な変更点を特定できます。 意図を持った変更 私は父から意図を持って行うこと、すなわち自分が何をしようとしているのかを知り、すべての行動がその目標に向かっていることを確認すること、その重要さを学びました。— Will Guidara、 Unreasonable Hospitality: The Remarkable Power of Giving People More Than They Expect 失敗したシナリオを特定し、軌跡の分析を通して問題を診断しました。さぁ、システムを修正する時です。 この段階で最もよく見られる誤信:   過学習 につながる 確証バイアス です。前述の評価上の課題 (遅いフィードバックループと包括的なテストスイートの非現実性) を考えると、開発者は通常、合格するまでいくつか特定の失敗シナリオのみをローカルでテストします。より広範な影響を考慮せずに、1 つか 2 つのシナリオが合格するまでコンテキスト (システムプロンプト、ツール仕様、ツール実装など) を修正してしまいます。変更がコンテキストエンジニアリングのベストプラクティスに従っていないと、限られた評価では捉えられない悪影響が生じる可能性が高いです。 勤勉さと判断力の両方が求められます: 利用可能な評価と再利用可能な過去の本番環境でのシナリオを通して成功基準を確立するだけでなく、変更の指針となるコンテキストエンジニアリングのベストプラクティスを学んでください。Anthropic の プロンプティングベストプラクティス と エンジニアリングブログ 、Drew Breunig の “How Long Contexts Fail” 、 Manus 構築からの教訓 は特に参考になりました。 まず成功基準を確立する 変更を加える前に、成功とはどのようなものかを定義します: ベースライン: 現在のシステムに特定の git コミット ID を固定します。どのメトリクスが エージェントの体験 と顧客の体験の両方を改善するのかを慎重に検討し、それらをベースラインのメトリクスとして収集します。 テストシナリオ: どの評価で変更の影響を測定しますか？評価を何回再実行しますか？このテストセットが、調査している 1 つの失敗だけでなく、より広い顧客のパターンを代表していると確信を持ってください。 比較 : 同じメトリクスを使用して、ベースラインに対しての変更を測定します。 意図を持ったフレーミングにより、確証バイアス (結果を好意的に解釈する) とサンクコストの誤謬 (時間を費やしたという理由だけで変更を受け入れる) を避けられます。修正してもメトリクスが期待通りに動かない場合は、却下してください。 例えば、AWS DevOps Agent 内の サブエージェント を最適化する際、git コミット ID を固定し、同じシナリオを 7 回実行してベースラインを確立します。これにより、典型的なパフォーマンスと分散の両方が明らかになります。 各メトリクスは異なる側面を測定します: Correct observations – インシデントに直接関連する 関連 シグナル (ログレコード、メトリクスデータ、コードスニペットなど) をサブエージェントはいくつ提示したか？ Irrelevant observations – サブエージェントはリードエージェントにどれだけの ノイズ をもたらしたか？インシデントに無関係で、エージェントの調査を妨げる可能性のあるシグナルをカウントします。 Latency – サブエージェントはどのくらい時間がかかったか (分と秒で測定)？ Sub-agent tokens – サブエージェントはタスクを達成するのにどれだけのトークンを消費したか？サブエージェント実行コストの代理メトリクスとして機能します。 Lead-agent tokens – サブエージェントの入出力はリードエージェントのコンテキストウィンドウをどれだけ消費しているか？サブエージェントツールの最適化機会を具体的に特定できます。つまり、サブエージェントへの指示や返答結果を圧縮できるか？ということです。 ベースラインを確立した後、提案した変更に対して同じ測定値を比較します。これによって変更によって実際改善したかどうかが明確になります。 本番環境のサンプルを読む 幸運なことに、複数の Amazon のチームが AWS DevOps Agent を早期に採用してくれました。DevOps Agent チームのメンバーは、軌跡の可視化ツール (前述の OpenTelemetry ベースの可視化に似ていますが、根本原因分析レポートや観察結果などの DevOps Agent 固有のアーティファクトをレンダリングするようカスタマイズされています) を使用してローテーションで実際の本番実行を定期的にサンプリングし、エージェントの出力が正確であったかどうかをマークし、失敗したポイントを特定します。本番環境のサンプルは替えの効かないものです。実際の顧客体験を明らかにします。さらに、サンプルを継続的に確認することで、エージェントが得意なことと苦手なことの直感が磨かれます。本番実行が満足のいくものでない場合に反復するための実際のシナリオを持っています。エージェントをローカルで修正し、望ましい結果が得られるまで同じ本番環境に対して再実行してください。このような方法に協力してくれる重要なアーリーアダプターなチームとの信頼関係を築くことは非常に価値があります。彼らは迅速な反復のためのグラウンド・トゥルースを提供し、新しい評価シナリオを特定する機会を生み出します。本番データでの緊密なフィードバックループは、評価駆動開発と連携して機能し、包括的なテストスイートを形成します。 おわりに 現実のビジネス課題を解決できることを示すようなエージェントプロトタイプを構築することは、エキサイティングな第一歩です。より困難なのは、プロトタイプを様々な顧客環境とタスクにわたって確実に機能する製品に昇格させることです。本記事では、エージェントの品質を体系的に改善するための基盤となる 5 つのメカニズムを共有しました: 現実的で多様なシナリオでの評価、高速なフィードバックループ、軌跡の可視化、意図を持った変更、本番環境のサンプリングです。 エージェントアプリケーションを構築しているなら、今日から評価スイートの構築を始めてください。ほんの一握りの重要なシナリオから始めるだけでも、体系的に測定・改善するために必要な品質のベースラインを確立できます。AWS DevOps Agent がインシデント対応にこれらの原則をどのように適用しているかについては、 入門ガイド をご覧ください。 翻訳はソリューションアーキテクトの大西朔が担当しました。原文は こちら です。 著者について Efe Karakus AWS DevOps Agent チームのシニアソフトウェアエンジニアで、主にエージェント開発を担当しています。