Agent Experienceは新しいDeveloper Experience（DX）

Developer Experience (DX)は、人がツールをどれだけうまく使えるかを問うものです。Agent Experienceは、同じ問いを機械について投げかけます。

このページでは、Claude Code、Cursor、そして人による監視の度合いがさまざまなカスタムのエージェント型ワークフローなど、コードを書き、実行し、反復するAIコーディングエージェントを中心に扱います。同じ原則は、モデルが誰かに代わってソフトウェアやインフラストラクチャとやり取りするあらゆる場面に当てはまります。

Agent Experienceは製品カテゴリーではなく、設計の一分野です。API、コマンドラインツール、ドキュメント、権限、環境、エラーメッセージ、ログ、フィードバックシステムなど、さまざまな場所に表れます。これらのインターフェースの多くは、もともと人向けに設計されたものです。

優れたDeveloper Experience (DX)は、意図と有用な結果との距離を縮めます。人は、視覚的な階層構造、段階的な情報開示、読みやすい説明、探索を後押しするインターフェースから恩恵を受けます。

エージェントは同じシステムであっても異なる形で関わります。視覚的な一覧性を重視して設計されたダッシュボードは、機械にとってはほとんど使える情報を含んでいないことがあります。詳細なエラーメッセージは、人がコンテキストを理解する助けになる一方で、エージェントにはノイズからシグナルを切り分けるためにトークンを費やすことを強いる場合があります。対話型プロンプトは、人にとってCLIを使いやすくする一方で、自動化されたワークフローを完全に止めてしまうことがあります。

両方の利用者のために設計する

Agent ExperienceはDeveloper Experience (DX)を置き換えるものではありません。ソフトウェアシステムは両方に対応する場面が増えています。

開発者がビジュアルなインターフェースでプルリクエストをレビューする一方で、エージェントはAPI経由で同じ変更を取得することがあります。開発者がビルドログ全体を確認する一方で、エージェントは失敗したステップと関連するエラーだけを要求することがあります。人はガイド付きのセットアップフローを好む一方で、エージェントには予測可能な出力を返す非対話型のコマンドが必要です。

優れたツールは、同じ基盤機能を、それぞれの利用者に適した形で提供します。

開発者向けツールは何十年もの間、キーボードの前に人がいることを前提としてきました。ダッシュボードを一覧し、予想外の事態に気づき、追加の情報を探し、判断力を使って曖昧さを解消できる人です。

エージェントはこの前提を変えます。ソース管理システム、ビルドインフラ、パッケージレジストリ、クラウドプラットフォーム、内部API、開発者向けツールは、誰かに代わって動くソフトウェアからのリクエストをますます多く受け取るようになっています。

エージェントはソフトウェアの利用者になりつつある

エージェントは、これまで開発者が手動で操作してきたシステムと直接やり取りする場面が増えています。

エージェントはドキュメントを読み、APIを呼び出し、コマンドを実行し、リポジトリを変更し、ログを調べ、インフラに問い合わせ、ワークフローを起動します。その過程にあるすべてのインターフェースが、エージェントがタスクを確実に完了できるかどうかに影響します。

質の低いAXは人の仕事になる

構造化されていない出力の壁を渡されたエージェントは、何が重要かを見極めるために時間とトークンを費やさなければなりません。曖昧なAPIレスポンスは、不要な再試行や誤った次のアクションにつながることがあります。対話型プロンプトは、自動化されたタスクを止めて人に差し戻してしまうことがあります。

問題はワークフロー全体で積み重なっていきます。各ステップにおけるわずかな曖昧さが、自律的なタスクを繰り返しの確認、レビュー、後片付けへと変えてしまうことがあります。

優れたモデルはインターフェース設計を不要にはしない

モデルの能力は今後も向上し続けます。チームは、モデルがやり取りするシステム、つまりAPIスキーマ、ドキュメント、CLIの振る舞い、ログ、権限、環境、フィードバックについて、はるかに直接的なコントロールを持っています。

優れたモデルは質の低いインターフェースについてもより効果的に推論できますが、優れたインターフェースはそもそも必要となる推論の量そのものを減らします。

プラットフォームチームは、共有インフラを通じて舗装された道（ペイブドパス）を作ることで、すでに開発者に対して同様の取り組みを行っています。エージェント型の開発は、設計すべきもう一人の利用者をもたらします。

Agent Experienceは、エージェントがタスクを完了するために使用するあらゆるインターフェースの特性です。

コーディングエージェントの場合、たった1つの変更であっても、ドキュメントの読み取り、リポジトリへの問い合わせ、コマンドの実行、ファイルの変更、外部ツールの呼び出し、テスト出力の解釈、CIステータスの確認、プルリクエストの更新が必要になることがあります。

適切なコンテキストを得る

エージェントには、確実に取得し解釈できる形式で情報にアクセスできることが必要です。

APIは安定したスキーマと構造化されたレスポンスから恩恵を受けます。ドキュメントは正確な例、明確なバージョン管理、標準的な手順から恩恵を受けます。CLIツールは機械可読な出力モードから恩恵を受けます。ツールの説明は、正確な名前、入力、出力、境界から恩恵を受けます。

MCPのようなプロトコルは、インターフェース設計を特に可視化します。ツールの説明は、エージェントがいつそのツールを選ぶか、どのようにリクエストを構築するかを左右します。

利用可能なコンテキストが多いからといって、自動的に優れたAXになるわけではありません。重要なのは、関連性のあるコンテキストです。

安全にアクションを実行する

エージェントには、システムを変更するための予測可能な手段が必要です。

コマンドラインツールは、非対話型の実行、意味のある終了コード、結果が明確に定義された操作をサポートすべきです。実用的な範囲で、コマンドを繰り返しても安全であるか、重複した操作が明らかになるようにすべきです。

権限は、ミスのコストを拡大させることなく、エージェントにどれだけの自律性を与えられるかを決定します。範囲を絞ったスコープ、承認の境界、隔離された環境、ポリシーの適用によって、エージェントは意図しない影響を抑えながら有用な作業を行えるようになります。

何が起きたかを理解する

エージェントは、あるアクションが成功したのか、失敗したのか、あるいは予期しない状態を引き起こしたのかを知る必要があります。

機械可読なステータス、具体的なエラー、構造化されたログ、明示的な状態は、次のステップを判断しやすくします。有用なエラーは、何が失敗したか、どこで失敗が発生したか、システムが何を期待していたかをエージェントに伝えます。

必要なときには完全な詳細情報にアクセスできる状態を保つべきです。それがデフォルトの応答である必要はありません。

状態と履歴を把握する

エージェントは、開発者であれば別のインターフェースを開いて確認するような情報を必要とすることがよくあります。

現在どのデプロイが実行中か。どのパイプラインが失敗したか。前回の試行後に何が変わったか。APIの呼び出しは完了したか。プルリクエストはすでに開かれているか。

運用状態をプログラムからアクセス可能にすることで、エージェントはダッシュボードの情報を人が翻訳してくれるのに頼ることなく、これらの問いに答えられるようになります。

Agent Experience の改善に、AIを中心としたプラットフォーム全体の再構築が必要になることはめったにありません。価値の高い変更の多くは、既存のインターフェースをより明確に、より構造化された、より予測しやすいものにするだけで実現します。

1. 構造化された情報を返す

エージェントが繰り返し利用するワークフローには、機械可読な出力を提供します。

CLIであれば、文書化されたスキーマに基づくJSON出力を意味するかもしれません。APIであれば、安定したレスポンス型と明示的なエラー状態を意味します。ドキュメントであれば、不足している前提をエージェントが自分で補わなくても実行できる例を意味します。

人間可読な出力は、そのまま人間向けに残しておいて構いません。エージェントは、同じ情報への機械指向の経路があることで恩恵を受けます。

2. ソースの時点でコンテキストを絞り込む

利用可能なすべての情報ではなく、現在の判断に必要な情報だけを返します。

3件のテストが失敗した場合は、その3件の失敗を特定し、関連する詳細を提供してから、無関係な出力を何千行も返すようなことは避けます。パラメータが無効なために操作が失敗した場合は、そのパラメータと期待される値を直接示します。

ソースの時点でフィルタリングすることで、トークン消費量が減り、エージェントが検討すべき妥当な解釈の数も絞り込まれます。

3. アクションを予測可能かつ再現可能にする

エージェント型のワークフローは、操作を何度もリトライしたり、代替アプローチに分岐したり、以前のステップに戻ったりすることが頻繁にあります。

冪等な操作は、リトライを安全にします。明確な状態遷移は、何かがすでに発生したかどうかをエージェントが理解する助けになります。正直なexitコードと明示的なステータスにより、エージェントが文章から成功を推測する必要がなくなります。

ガードレールは、可能な限りシステム側に組み込むべきです。権限の境界やポリシーチェックは、すべてのエージェントが記述された規約を発見し従うことを期待するよりも信頼できます。

4. レイテンシーをインターフェースの一部として扱う

フィードバックは、それを生み出したタスクにエージェントがまだ取り組んでいる間に、最も役立ちます。

許容できるレイテンシーはワークフローによって異なります。ローカルの構文チェックはほぼ即座に結果を返す必要があるかもしれません。フルの統合テストにはもっと時間がかかることがあります。デプロイには、本質的に数分かかることもあります。

重要な問いは、そのタイミングがエージェントが次に下すべき判断に見合っているかどうかです。

5. エージェントの成果を測定する

従来のUX指標では、エージェントがシステムとどれだけうまくやり取りできているかを十分に説明できません。代表的なタスクを少数定義し、プロダクトが変化するたびに繰り返し実行します。

有用なAX指標には、次のようなものがあります。

• 最初の試行が成功する頻度
• タスクに必要なリトライやツール呼び出しの回数
• 解決に至るまでに必要な時間や推論予算
• 人が介入しなければならない頻度
• 失敗した試行の直前に最も頻繁に登場するツールやインターフェース

繰り返し発生する失敗がインターフェースの問題を明らかにした場合は、それを修正し、そのケースを回帰評価として残しておきます。これらの評価は、APIスキーマ、ツール定義、構造化された出力、exitコード、権限境界といったエージェント向け契約のテストと並べて、CI上で実行します。

ベースラインがあることで、本当のAX改善なのか、人間のレビュアーにとって単に見た目がきれいに見えるだけの変更なのかを区別できます。

繰り返される失敗から始める

エージェントが頻繁に実行するタスクを1つ選び、失敗した試行を最初から最後まで調べます。

エージェントがコンテキストを欠いていた、状態を誤解していた、誤ったツールを選んだ、曖昧なフィードバックを受け取った、あるいは人間の介入が必要になった、といった最初のポイントを探します。

最も有用なAX改善は、モデル自体の内部よりも、見慣れたソフトウェアインターフェースから始まることがよくあります。繰り返される失敗を修正したら、それを評価セットに追加し、後で回帰を検知できるようにします。

AIエージェントは非決定的です。同じタスクに対する2回の試行が、異なる推論経路、ツールの呼び出し順序、そして異なる解決策を生み出すことがあります。

インターフェース設計は、こうした違いが生み出すばらつきの大きさを増やすことも、減らすこともできます。

ジョブログ全体を渡されたエージェントには、追うべきシグナルの候補が数多くあります。関連する失敗内容、影響を受けたファイル、期待される挙動、補足のコンテキストを渡されたエージェントは、はるかに絞り込まれた問題定義から出発できます。

この2つ目のインターフェースは、モデルを決定的にするわけではありません。不要な曖昧さを減らすだけです。

精密なツールの説明は、ツール選択を絞り込みます。安定したスキーマは、解釈の余地を減らします。明示的な状態は、推測を減らします。明確に定義された権限境界は、利用可能なアクションを制限します。

良いAXは、モデルのばらつきが誤った、あるいはコストのかかる挙動に転じる余地を減らすように、周囲のシステムを設計します。

上記の原則は、ソフトウェアスタック全体に当てはまります。CircleCIは、Agent Experienceの中でも特定の部分、すなわちエージェントがソフトウェアを開発する際に有用な検証フィードバックをどう得るか、そしてチームがエージェントによる変更を出荷前にどう独自に検証するかという点に注力しています。

コード生成は、より速く、より安価になりつつあります。それでも、追加される変更のひとつひとつには、マージとデプロイに求められる基準を満たしているという根拠が必要です。

CircleCIのアプローチは、エージェントの作業ループ内での高速なフィードバックと、CIにおける独立した検証とを結び付けます。

コーディングエージェントは、もっともらしい変更を素早く生み出せます。しかし、その変更を評価するには、はるかに多くの作業が必要になることがあります。

テストの成功は有用な根拠にはなりますが、それが示すのは実行したチェックが通ったという事実だけです。ある変更が1つのテストを満たしていても、別の箇所でリグレッションを引き起こしていたり、間違った問題を解決していたり、現在のテストスイートがカバーしていない別の要件を満たしていなかったりすることがあります。

エージェント型の開発では、高速なフィードバックと独立した検証の両方の重要性が高まります。エージェントは作業中に効率よく反復するための十分なシグナルを必要とし、チームはコードが共有されたりデプロイ可能になったりする前に、より幅広い検証レイヤーを必要とします。

私たちは、単一の成功シグナルを正しさの証明として扱うのではなく、ある変更がチームのマージ要件を満たすのに十分な根拠を備えているかどうかを表すために、マージ品質という言葉を使います。

CIは、そうした根拠を集め、適用するための独立した場を提供します。

エージェント型のソフトウェア開発は、2つのフィードバックループにまたがって動作する。

インナーループ

インナーループとは、エージェントが変更に取り組んでいる間に起きることを指す。

書く → 実行する → チェックする → 修正する → 繰り返す

エージェントは、問題、実装内容、直近のツール出力をまだアクティブなコンテキストに保持している。ここで高速に検証することで、pushやプルリクエストの前に問題を発見できる。

アウターループ

アウターループは、変更が共有の配信インフラストラクチャに到達した時点で始まる。

これには、CI/CDパイプライン、統合テストやシステムテスト、セキュリティチェック、レビュー、デプロイ、デプロイ後の検証などが含まれる。

アウターループは異なる役割を担っている。その結果は、開発者、エージェント、レビュアー、そして下流のシステム間で共有される。変更が作成された環境の外側から、その変更に関する独立したエビデンスを提供する。

2つのループをつなぐ

優れたAgent Experienceは、両者の間で有用なフィードバックを流し続ける。

インナーループで検知された不具合は、エージェントが完全な作業コンテキストを保持している間に、その場で修正できることが多い。CIで見つかった不具合は、エージェントが問題全体を最初から調べ直さずにタスクを続行できるだけの、十分に構造化された情報とともにエージェントに戻すべきである。

目的は、アウターループのすべてのチェックをインナーループに移すことではない。それぞれのループが自らの役割で成果を発揮し、両者間の引き渡しを効率的にすることにある。

CircleCIは、両方のループにまたがってエージェント向けのインターフェースを構築しており、エージェントがコードをより早い段階で検証し、CIからより高いシグナルのフィードバックを受け取り、開発者に結果の翻訳を強いることなく失敗に対応できるようにしている。

1. インナーループにおけるCIレベルの検証

Chunk sidecarは、pushの前に、影響を受けたコードに対して分離された環境で的を絞った検証を実行する。

エージェントは、実装内容をまだコンテキストに保持したまま、完全なCIパイプラインを待つことなく、作業ディレクトリの変更を検証できる。sidecarは、インナーループに属するチェックについて、1分未満でCIレベルのフィードバックを返すよう設計されている。

高速なインナーループの検証は、単純な問題をそれが発生した場所の近くで捕捉し、アウターループをより深い共有チェックに集中させる。

2. アウターループにおけるより高いシグナルの検証

Smarter Testingは、テストインパクト分析を使用して変更の影響を受けるテストのみを実行し、利用可能な計算リソースにテスト実行をインテリジェントに分割し、失敗したテストを再実行してフレーキーテストを特定する。

エージェントによる開発は、CIを通過する変更と検証サイクルの数を増加させる可能性がある。最も関連性の高いテストを迅速に実行することは、量が増えてもフィードバックを有用に保つ助けとなる。

フレーキーで不必要なテスト実行を削減することは、変更が対応を必要とするかどうかについて、エージェントと開発者の両方により明確なシグナルを与える。

3. アウターループの失敗をコンテキストに戻す

CIの失敗は、関連する情報がエージェントの作業環境に直接戻ってくるときに、そのエージェントにとって最も有用になる。

CircleCI CLIは--failure-reportフラグをサポートしており、失敗したジョブを、ログ全体を解析せずにエージェントが診断に必要とする情報へと絞り込む。

CircleCIはFix with Claude Codeもサポートしており、失敗したCircleCIの実行から構造化された失敗のサマリーをターミナル内のClaude Codeへ送り戻す。

アウターループが問題を検知する。エージェントは関連するコンテキストを受け取り、修正を提案し、CIが次の変更を独自に検証する。

4. エージェントにCircleCIへの直接アクセスを与える

CircleCI CLIは、構造化されたJSON出力、失敗レポート、パイプライン操作、デプロイツールを備えた、CircleCIへのマシン指向インターフェースを提供する。

CircleCI MCPサーバーは、CircleCIのツールをMCP対応のエージェントに直接公開する。エージェントは、パイプラインのステータスを取得し、失敗やテスト結果を検査し、ワークフローを再実行し、パイプラインをトリガーし、その他のサポートされている操作を、開発者が手動でシステム間の情報を移動させることなく実行できる。

新規プロジェクトでは、circleci onboardがリポジトリを検査し、CircleCIの初期設定を生成し、プロジェクトをCircleCIに接続できる。

これらのインターフェースが組み合わさることで、エージェントは配信ワークフローに直接参加できるようになり、その一方でCircleCIはエージェントが生成するコードを取り巻く独立した検証レイヤーであり続ける。

優れたAgent Experienceは、エージェントを製品のユーザーとして扱うことから始まる。関連するコンテキスト、予測可能な行動手段、明示的なシステム状態、そして次の意思決定を明確にするフィードバックをエージェントに与える。

まずは頻度の高いワークフローを1つ選び、それをエンドツーエンドでエージェントが使えるようにする。代表的なタスクを繰り返しテストし、繰り返し発生する失敗を具体的なインターフェースの改善へとつなげる。エージェントの評価やコントラクトテストは、CIのフィードバックループの一部となり、製品が変化する中でAXの後退を検知する助けとなる。

CircleCIを使えば、AXは配信ワークフローそのものにまで拡張できる。コーディングエージェントは、構造化されたCLI出力やMCPツールにアクセスし、インナーループで変更を検証し、アウターループでCIからより高いシグナルのフィードバックを受け取ることで、開発者に結果の翻訳を頼らずに作業を続けられる。

AXを自社製品に組み込み、それを継続的にテストし、改善し続ける対象にしよう。