ホストされるエージェントをデバッグする

Microsoft Foundry のazd ai agentを使用してエージェントをビルド、実行、デプロイするときに発生する一般的な問題を診断して修正します。診断コマンドから始めます。次に、症状ベースのセクションを使用して、認証、ローカル開発、デプロイ、直接コマンド、ログ、ルーチンのトラブルシューティングを行います。

前提条件

初期化されたホステッドエージェントプロジェクト。作成するには、「エージェントプロジェクトを初期化する」を参照してください。
azd Foundry 拡張機能がインストールされています。インストール手順については、 azd Foundry 拡張機能のインストールを参照してください。
認証された Azure Developer CLI セッション。必要に応じて azd auth login を実行します。
デプロイやログに関する問題については、デプロイ済みのホステッドエージェント。デプロイするには、ホストされているエージェントのデプロイに関するページを参照してください。

診断コンテキストの収集

特定のエラーに進む前に、次のコマンドを使用してコンテキストを収集します。

# Check extension version
azd ai agent version

# Verify Azure authentication
azd auth login

# Show current environment configuration
azd env get-values

# View agent details
azd ai agent show

# Show the resolved Foundry project endpoint and where it came from
azd ai project show

# Stream production logs
azd ai agent monitor --follow

構造化正常性レポートの場合は、 azd ai agent doctorを実行します。詳細については、「エージェント医師によるプロジェクトの診断」を参照してください。

呼び出しの待機時間を診断する

待機時間のデバッグヘッダーを使用して、低速のホステッドエージェント要求がプラットフォーム、プロビジョニングインフラストラクチャ、コンテナーの待機、またはエージェントでの要求の処理に時間を費やしたかどうかを判断します。これらのヘッダーは、SLA や課金メトリックではなく、診断シグナルです。

x-ms-debug-latency-enabled: trueを設定して、各要求で診断を有効にします。要求にこのヘッダーが含まれていない場合、応答には x-ms-debug-latency-* ヘッダーは含まれません。

ホストされるエージェントの応答または呼び出しプロトコル要求に待機時間ヘッダーを追加します。この例では、Responses プロトコルを使用します。

ENDPOINT="https://{account}.services.ai.azure.com/api/projects/{project}"
API_VERSION="v1"
TOKEN=$(az account get-access-token \
  --resource https://ai.azure.com \
  --query accessToken -o tsv)
AGENT="my-code-agent"

curl --http2 -i -X POST \
  "$ENDPOINT/agents/$AGENT/endpoint/protocols/openai/responses?api-version=$API_VERSION" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "x-ms-debug-latency-enabled: true" \
  -d '{"model":"gpt-5.4-mini","input":"Hello, agent!","stream":false}'

応答ヘッダーを調べます。すべての待機時間の値は、整数のミリ秒です。

Header	Meaning
`x-ms-debug-latency-session-start-type`	トリガーされた要求を開始するセッションの種類: コールドスタート (`cold`)、ウォームスタート (`warm`)、またはアイドル状態からの再開 (`resume`)。
`x-ms-debug-latency-platform-preprocessing-ms`	受け付け、認証、セッション検索、オーケストレーションのプラットフォーム処理時間。マイクロ VM のプロビジョニングやコンテナーの準備の遅延は含まれません。コールドセッション、ウォームセッション、および再開されたセッションの開始時に利用できます。
`x-ms-debug-latency-infra-setup-ms`	マイクロ VM をプロビジョニングする時間。ウォームリクエストでは省略されます。
`x-ms-debug-latency-container-readiness-ms`	マイクロ VM の作成からコンテナーが準備完了と報告されるまでの時間。ウォームリクエストでは省略されます。
`x-ms-debug-latency-container-response-ms`	プロキシ転送から応答ヘッダーがコミットされるまでの時間。要求転送、接続のセットアップ、エージェントの処理、再試行、出力ポリシーのバッファリングが含まれます。
`x-ms-debug-latency-response-begin-ms`	サービスの受け入れから応答ヘッダーがコミットされるまでの合計時間。この値は、最初の応答本文バイトまたは最初のサーバー送信イベントの時刻ではありません。

4 つのタイミングコンポーネントは、 x-ms-debug-latency-response-begin-msまで加算されます。コールドスタート時または再開時の要求では、プラットフォームがすべてのプロビジョニング境界をキャプチャできない場合、インフラストラクチャヘッダーとレディネスヘッダーは省略され、その時間はプラットフォームの前処理時間に含まれます。

セッション開始の種類と最大のタイミングコンポーネントを使用して、遅延の原因の可能性を特定します。

Result	解釈	何をすべきか
`x-ms-debug-latency-session-start-type` が `cold` または `resume`で、 `x-ms-debug-latency-infra-setup-ms` が高い	プラットフォームはマイクロ VM のプロビジョニングに時間を費やしました。	複数の「保留中」または「再開済み」の要求を比較します。遅延が続く場合は、サポート要求の応答 ID、タイムスタンプ、および待機時間ヘッダーを記録します。
`x-ms-debug-latency-session-start-type` が `cold` または `resume`で、 `x-ms-debug-latency-container-readiness-ms` が高い	コンテナーの起動とレポートの準備に長い時間がかかりました。	スタートアップログの初期化手順を測定し、準備エンドポイントが使用可能になる前に作業を減らし、可能な場合はアプリケーションコードをプリコンパイルします。
`x-ms-debug-latency-platform-preprocessing-ms` は、どのセッション開始タイプでも高くなっています	マイクロ VM プロビジョニングまたはコンテナーの準備が完了するまでに、プラットフォームで遅延が発生しました。	サポートリクエストを作成します。応答 ID、タイムスタンプ、セッション開始の種類、待機時間ヘッダーを含めます。
`x-ms-debug-latency-container-response-ms`、`x-ms-debug-latency-first-byte-ms`、またはトレーラーの`first_byte_ms`が高い	プロキシ転送の開始後に遅延が発生しました。	要求ハンドラーをインストルメント化し、エージェントログ、モデル呼び出し、ツール呼び出し、再試行、出力バッファリングを検査します。

コンテナーの準備時間を短縮する

コンテナーの準備状況の値には、プロセスの開始、アプリケーションの読み込み、 /readinessからの HTTP 200 の返しに必要な時間が含まれます。スタートアップログにタイムスタンプを追加して、低速なインポート、依存関係の読み込み、ネットワーク呼び出し、およびその他の初期化作業を識別します。

これらの最適化を、特定する低速な手順に適用します。

イメージをビルドするときに依存関係をインストールし、コードをコンパイルします。コンテナーの起動時にパッケージのインストール、復元、コンパイルを実行しないでください。
マルチステージビルドを使用し、ビルドツール、パッケージキャッシュ、テスト、およびその他の開発ファイルをランタイムイメージから除外します。
準備の前に、モデルの呼び出し、移行、ツールの検出、資産のダウンロードを避けてください。最初に完了する必要がある独立した初期化を並列化します。
/readinessエージェントが要求を受け入れられるかどうかに注目してください。初期化を延期する場合は、最初の要求を測定して、スタートアップの遅延を要求処理に移動していないことを確認します。

Python
.NET

ランタイムイメージにコピーする仮想環境に依存関係をインストールします。サードパーティ製パッケージ内の解析不可能なファイルがビルドに失敗しないように、ベストエフォートベースで依存関係をコンパイルします。構文エラーがビルドに失敗するように、アプリケーションを厳密にコンパイルします。

FROM python:3.13-slim AS build

WORKDIR /app
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
RUN PYTHONDONTWRITEBYTECODE= python -m compileall -q /opt/venv \
      || true; \
    PYTHONDONTWRITEBYTECODE= python -m compileall -q /app

FROM python:3.13-slim AS final

ENV PATH="/opt/venv/bin:$PATH"
WORKDIR /app

COPY --from=build /opt/venv /opt/venv
COPY --from=build /app /app

# Precompile the standard library in the runtime image.
RUN PYTHONDONTWRITEBYTECODE= python -m compileall -q \
    "$(python -c "import sysconfig; print(sysconfig.get_path('stdlib'))")" \
    || true

CMD ["python", "main.py"]

このビルドステップのPYTHONDONTWRITEBYTECODEをクリアすると、Pythonがバイトコードをイメージに書き込むことができます。環境変数は読み取りではなくバイトコード書き込みをブロックするため、実行中のコンテナーではコンパイル済みファイルを引き続き使用できます。

リファレンス: compileall - バイトコンパイル Python ライブラリ

ReadyToRun を使用して発行し、ターゲットランタイムのアセンブリをコンパイルし、Just-In-Time コンパイラが起動時に実行する作業を減らします。この例では、一致する glibc ベースの SDK とランタイムイメージを使用するため、適切な.NETランタイム識別子がlinux-x64されます。

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build

WORKDIR /src
COPY . .

RUN dotnet publish -c Release \
    -r linux-x64 \
    --self-contained false \
    -p:PublishReadyToRun=true \
    -o /app

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS final

WORKDIR /app
COPY --from=build /app .

ENTRYPOINT ["dotnet", "MyAgent.dll"]

MyAgent.dllを発行済みのアセンブリ名に置き換えます。復元中に ReadyToRun プロパティが適用されるように、同じコマンドで復元、ビルド、発行を維持します。 ReadyToRun は、より大きなイメージと長いビルドを犠牲にしてスタートアップパフォーマンスを向上させます。

Important

ランタイム識別子はランタイムイメージと一致する必要があります。 Alpine Linux を使用する場合は、2 つのステージに sdk:10.0-alpine と aspnet:10.0-alpine を使用し、 linux-musl-x64を使用します。 Alpine イメージで linux-x64 を使用したり、glibc ベースのイメージで linux-musl-x64 したりしないでください。一致しない場合、復元、発行、またはランタイムエラーが発生する可能性があります。

リファレンス: ReadyToRun のデプロイ

ホストされるエージェントに必要な x86-64 アーキテクチャ用のイメージをビルドします。

docker build --platform linux/amd64 -t my-agent:latest .

ここでは、linux/amd64は Docker プラットフォームであり、.NETランタイム識別子ではありません。

リファレンス: ホストされるエージェントコンテナーの要件

エージェントとモデルの待機時間を調査する

コンテナーの準備が速くても、コンテナーの応答または 1 バイト目の時間が長い場合は、転送の開始後に要求パスに焦点を当てます。要求を再現しながら azd ai agent monitor --follow を実行し、モデル呼び出し、ツール呼び出し、外部サービス、再試行、応答のシリアル化に関するトレースを追加します。詳細については、「ホストされたエージェントログの監視」を参照してください。

大規模な言語モデルを呼び出すエージェントの場合は、デプロイを変更する前に、モデルの待機時間を個別に測定します。最初のトークンが生成されるまでの時間、トークン間の時間、生成されたトークン数、プロンプトサイズ、デプロイの使用率、スロットリングを比較します。次に、モデルの選択、出力トークンの制限、ストリーミング、ワークロードの分離を評価します。 Azure OpenAI のパフォーマンスを向上させるを参照してください。

測定で予測可能なワークロードに対する持続的な容量の負荷が示されている場合は、プロビジョニングされたデプロイを評価し、観察された入力トークン、出力トークン、および要求率に合ったサイズを設定します。プロビジョニング済みスループットを参照してください。

完了のタイミングを調べる

HTTP/2 以降では、サービスはベストエフォート x-ms-debug-latency-final 応答トレーラーを返すことができます。 response-header 値が繰り返され、次のフィールドを追加できます。

フィールド	Meaning
`first_byte_ms`	サービスの受け入れから最初の応答本文バイトまたはサーバー送信イベントまでの時間。
`total_last_byte_ms`	サービスの受け入れから応答の転送が完了するまでの時間。

トレーラーは、バージョン付きのセミコロン区切り形式を使用します:

x-ms-debug-latency-final: v=1;start=cold;platform_pre_ms=...;
  infra_ms=...;ready_ms=...;container_response_ms=...;
  response_begin_ms=...;first_byte_ms=...;total_last_byte_ms=...

HTTP/1.1 応答には、このトレーラーは含まれません。取り消し、クライアントの切断、ミッドストリームエラー、ゲートウェイまたは SDK でトレーラーが保持されない場合は、トレーラーが存在しない場合もあります。応答ヘッダーは、保証された診断コントラクトとして扱います。

保存されている待機時間の結果を取得する

サービスは、キャプチャされたタイミングを応答または呼び出しと共に格納します。同じ応答または呼び出し ID に対する後の GET 要求は、元の要求のタイミングを応答ヘッダーとして返します。 GET 要求では、待機時間ヘッダーは必要ありません。また、GET 要求自体は測定されません。

GET 要求は、次の完了値を通常のヘッダーとして返すこともできます。

Header	Meaning
`x-ms-debug-latency-first-byte-ms`	応答本文の最初の1バイトを受信するまでにかかる時間。
`x-ms-debug-latency-total-last-byte-ms`	応答転送が完了するまでの時間。

ストレージは最終的に一貫性があるため、元の要求の直後の GET 要求にヘッダーがまだ含まれていない可能性があります。非同期応答または呼び出しの場合は、プラットフォームオーバーヘッド値 (セッション開始の種類、プラットフォームの前処理、インフラストラクチャのセットアップ、コンテナーの準備) のみを使用できます。遅延ヘッダーは、失敗したプロキシ応答または WebSocket (invocations_ws) 要求には出力されません。

認証エラーを修正する

修正 `AuthenticationError`

症状: エージェントがローカルで起動できないか、AI モデルを呼び出すときに 401/403 を返します。

原因と修正:

有効期限が切れた資格情報 - azd auth loginを実行して、Azure セッションを更新します。
間違ったサブスクリプション - azd env get-values | grep AZURE_SUBSCRIPTION_ID で確認し、Foundry プロジェクトのサブスクリプションと比較します。
RBAC ロールがない -- ID には Foundry ユーザーまたは Foundry プロジェクトに対する同等のアクセス権が必要です。

Important

Foundry RBAC ロールの名前が最近変更されました。 Foundry User, Foundry Owner, Foundry Account Owner、および Foundry Project Manager は、以前は、AZURE AI ユーザー、Azure AI 所有者、Azure AI アカウント所有者、および AZURE AI Project Manager という名前でした。名前の変更がロールアウトされている間、以前の名前が表示される場合があります。ロール ID とコアアクセス許可は、名前の変更によって変更されません。

ID には、モデルのデプロイを使用するために Cognitive Services OpenAI ユーザー 必要です。

プロビジョニング中の `AuthorizationFailed` を修正する

現象:azd up または azd provision がアクセス許可エラーで失敗します。

修正：Azure サブスクリプションの共同作成者ロールを要求します。 CI/CD の場合、サービスプリンシパルにも Foundry Owner が必要です。

修正 `SubscriptionNotRegistered`

症状： 必要なリソースプロバイダーが登録されていないため、プロビジョニングは失敗します。

修正：

az provider register --namespace Microsoft.CognitiveServices
az provider register --namespace Microsoft.ContainerRegistry

ローカル開発の問題を修正する

ポート 8088 で接続が拒否される問題を修正する

現象:azd ai agent invoke --local は接続に失敗します。

原因と修正:

エージェントが実行されていない -- 別のターミナルで azd ai agent run で起動します。
ポートの競合 - 別のプロセスでポート 8088 を使用しています。停止するか、カスタムポートを使用します。
```
azd ai agent run --port 9090
azd ai agent invoke --local --port 9090 "Hello!"
```
起動時のクラッシュ -- azd ai agent run が実行されているターミナルでエラー出力を確認します。一般的な原因としては、依存関係の不足、インポートエラー、startupCommandでの不適切なazure.yamlなどがあります。

依存関係のインストールエラーを修正する

現象:azd ai agent run は、依存関係のインストール中に失敗します。

原因と修正:

間違ったランタイムバージョン -- Python 3.10 以降または .NET 8 以降がインストールされていることを確認します。
requirements.txtまたは.csprojがありません-- CLI は、これらのファイルからプロジェクトの種類を自動検出します。エージェントディレクトリに存在することを確認します。
ネットワークの問題 -- パッケージレジストリが企業プロキシによってブロックされる可能性があります。 pipまたはdotnet構成を確認します。

`ResourceNotFound`または`DeploymentNotFound`を修正

症状： エージェントは起動しますが、モデルを呼び出そうとすると失敗します。

原因と修正:

エンドポイントの不一致 - azd env get-values 実行し、foundry ポータルに表示されているエンドポイント FOUNDRY_PROJECT_ENDPOINT 一致することを確認します。
モデルデプロイ名の不一致 - azure.yaml で構成されたモデルのデプロイ名は、Foundry プロジェクトのデプロイ名と一致する必要があります。ポータルの デプロイメント で確認してください。
リソースがプロビジョニングされていない -- azd up まだ実行していない場合、クラウドリソースは存在しません。最初 azd up 実行してから、ローカルでテストします。ローカルエージェントは引き続きクラウドでホストされるモデルを呼び出します。

デプロイの問題を修正する

コンテナーのビルドエラーを修正する

現象:azd up は Docker ビルドフェーズ中に失敗します。

原因と修正:

Dockerfile がありません -- エージェントディレクトリに Dockerfile があることを確認してください。テンプレートから初期化した場合、これは自動生成されます。
ビルドコンテキストエラー -- Dockerfileは、projectのサービス azure.yaml パスで指定されたディレクトリに存在する必要があります。
Docker での依存関係のインストール -- コンテナー内で pip/dotnet の復元が失敗した場合は、 requirements.txt または .csproj にすべての依存関係が正しくピン留めされていることを確認します。

`azd up`ハングまたはタイムアウトを修正する

症状： プロビジョニングまたはデプロイには、異常に長い時間がかかります。

原因と修正:

最初のデプロイ - 最初のazd upでは、Foundry プロジェクト、ACR、マネージド ID、モデルのデプロイなど、すべてのAzure リソースがプロビジョニングされ、5 ~ 10 分かかる場合があります。以降のデプロイは高速です。
リモートビルド -- 既定では、コンテナーイメージは ACR 上にリモートでビルドされます。これは遅くなる可能性がありますが、Docker をローカルで必要としません。代わりにローカルでビルドするには、docker.remoteBuild: false サービス構成でazure.yamlを設定します。
リージョンの容量 -- 一部のリージョンでは、特定のモデル SKU の容量が制限されている場合があります。プロビジョニングが一貫して失敗する場合は、別のリージョンを試してください。

デプロイされるが応答しないエージェントを修正する

現象:azd ai agent invoke は、デプロイが成功した後にタイムアウトするか、エラーを返します。

原因と修正:

正常性プローブが失敗する -- コンテナーは、ポート 8088 の GET /readiness に 200 状態で応答する必要があります。 azd ai agent monitor --followを使用してログを確認します。
プロトコルの不一致 -- azure.ai.agentのazure.yaml サービスで定義されているプロトコルが、コードで実装されているものと一致していることを確認します。 azure.yamlがresponsesと言っても、コードがinvocationsのみを処理する場合、またはその逆の場合、要求は失敗します。
コンテナーがクラッシュする -- 再起動イベントのシステムログを確認する: azd ai agent monitor --type system。一般的な原因としては、ハンドルされない例外やメモリ不足の問題があります。必要に応じて、 azure.yaml 内のコンテナーリソースを増やします。

ダイレクトコマンドのエラーを修正する

これらのエラーは、Foundry プロジェクトに対して実行すると、azd ai、azd ai connection、azd ai toolboxなどのazd ai routine直接コマンドから発生します。

解決された Foundry プロジェクトエンドポイントを修正しない

症状: ダイレクトコマンドは次のコマンドで終了します。 No Foundry project endpoint resolved. Run azd ai project set to set one, or pass --project-endpoint.

原因： CLI は、サポートされているソース ( --project-endpoint フラグ、アクティブな azd 環境、グローバル構成、または FOUNDRY_PROJECT_ENDPOINT 環境変数) で Foundry プロジェクトエンドポイントを見つけることができませんでした。

修正:

azd ai project set <endpoint>を実行して、エンドポイントをグローバル azd構成 (~/.azd/config.json) に格納します。
各コマンドに --project-endpoint (-p) を渡します: azd ai connection list -p https://my-proj.services.ai.azure.com/api/projects/my-project。
シェル環境で FOUNDRY_PROJECT_ENDPOINT を設定します。

完全な解決順序と各ソースが優先されるタイミングについては、「 azd プロジェクトコンテキストについて」を参照してください。

既存のリソースの作成エラーを修正する

現象:azd ai connection create、 azd ai toolbox create、 azd ai routine create、または azd ai skill create は、"既に存在する" エラーで失敗します。

原因: 仕様上、 create はアップサートされません。既定のエラーモードでは、ある開発者が共有 Foundry プロジェクトで別の開発者の状態を自動的に上書きできなくなります。

修正:

別の名前を選択して再実行します。
--force コマンドがサポートするcreateを渡して、ARM PUT を介して既存のリソースを置き換えます。置き換えは破壊的です。既存のリソースをその場で上書きするため、ポータルでの手動編集、メタデータ、または認証情報によって生じた差分は失われます。 azd ai toolbox create コマンドは--forceをサポートしていません。既存のツールボックスを削除するか、代わりに新しい名前を使用します。

`connection show`資格情報の出力を修正する

現象:azd ai connection show <name> は、接続の名前、種類、ターゲット、および認証の種類を返しますが、API キーまたは資格情報の値は返しません。

原因： 既定では、資格情報の値は返されません。明示的な --show-credentials フラグが必要です。

修正：

azd ai connection show tavily-conn --show-credentials

これにより、データプレーン API が呼び出され、Foundry プロジェクトに対するデータプレーンのアクセス許可 (Foundry User や同等のものなど) が必要になります。管理プレーンの Reader または Contributor アクセス権しかない場合、呼び出しは 403 で失敗します。プロジェクトオーナーにデータプレーンロールを依頼してください。

エージェントログの読み取り

azd ai agent monitorを使用してエージェントの動作を検査します。

# Stream all recent logs
azd ai agent monitor --follow

# View system-level events (container starts, crashes, restarts)
azd ai agent monitor --type system

# Filter to a specific session
azd ai agent monitor --session-id <session-id>

一般的なログパターンは次のとおりです。

ログメッセージ	Meaning
`Listening on 0.0.0.0:8088`	エージェントが正常に開始されました。
`AuthenticationError`	資格情報または RBAC の問題。マネージド ID を確認します。
`ModelNotFound`	モデルのデプロイ名が `azure.yaml`と一致しません。
システムイベントでのコンテナーの再起動	クラッシュループ。コードエラーを確認するか、リソースの制限を増やします。

定期的なエラーを診断する

エラーを表示する呼び出し元が存在しないため、ルーチンは対話型の agent invoke 呼び出しとは異なる方法で失敗します。ルーチンは、タイマーによってトリガーされる、繰り返される、GitHub問題によってトリガーされる、またはカスタムイベントによってトリガーされるエージェントの実行です。 azd ai routine run listを使用して、何が起こったかを調べます。

過去の実行を確認する

# Recent runs of a routine: trigger time, agent input/output, status, trace link
azd ai routine run list daily-digest

失敗に絞り込む

# Failed runs only, with an OData filter
azd ai routine run list daily-digest --filter "status eq 'failed'"

ウィンドウを拡大または縮小するには、 --top と組み合わせます。

1 回の実行にドリルダウンする

# Full detail for the most recent runs as JSON, then look up the run you care about
azd ai routine run list daily-digest --top 5 --output json

JSON 出力には、入力ペイロード、エージェントの応答、分散トレースへのディープリンクが含まれます。これは、対話型呼び出しで表示されるのと同じトレースです。

ルーチンを手動でリトリガーする

障害を再現する必要がある場合、または修正プログラムをテストする必要がある場合は、 dispatchを使用して必要に応じてルーチンを起動します。

azd ai routine dispatch daily-digest
azd ai routine dispatch triage-issues --input '{"issue":{"number":42}}'

dispatch は非同期的に実行され、ディスパッチ ID が出力されます。結果を azd ai routine run list <name>で確認します。

失敗したルーチン実行を修正する

azd ai routine run list は、 status: failedを含む実行を示します。トレースリンクに従って、基になるエージェントエラー (モデルエラー、ツールエラー、タイムアウトなど) を確認します。エージェント側の修正は、対話型エラーの場合と同じです。「認証エラーの修正」と「エージェントログの読み取り」を参照してください。

決して起動しないルーチンを修正する

azd ai routine run listが実行結果をまったく返さない場合、トリガー自体が発火していません:

ルーチンが有効になっていることを確認します: azd ai routine show <name>。 enabled: trueを探します。
timer トリガーについては、--at が未来の日時に設定されており、まだ実行されていないことを確認します。
recurring トリガーの場合は、--cron式が有効であり、--time-zoneが想定どおりであることを確認します。
github-issue トリガーの場合は、--connection-idが正常な接続に解決され、GitHub リポジトリと--issue-eventがリポジトリから出力されるイベントと一致することを確認します。
custom トリガーの場合は、--provider、--event-name、および--parametersスコープが、プロバイダーが発行しているイベントと一致することを確認します。

その他のヘルプを表示する

デバッグモード -- 詳細出力用の任意の--debug コマンドにazdを追加します。
Azure ポータル - リソースの正常性と診断については、Azure ポータルで Foundry プロジェクトを確認します。
バグを報告する -- github.com/Azure/azure-dev/issues で問題を報告します。

Azure Developer CLI を使用してホストされているエージェントログを監視し、ログ検査の詳細なオプションを確認します。
ホストされたエージェントをテストして、構造化テストの問題を防ぎます。
agent doctor を使用してプロジェクトを診断し、構造化されたプロジェクト健全性レポートを取得します。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-08

ホストされるエージェントをデバッグする

前提条件

診断コンテキストの収集

呼び出しの待機時間を診断する

コンテナーの準備時間を短縮する

エージェントとモデルの待機時間を調査する

完了のタイミングを調べる

保存されている待機時間の結果を取得する

認証エラーを修正する

修正 AuthenticationError

プロビジョニング中の AuthorizationFailed を修正する

修正 SubscriptionNotRegistered

ローカル開発の問題を修正する

ポート 8088 で接続が拒否される問題を修正する

依存関係のインストールエラーを修正する

ResourceNotFoundまたはDeploymentNotFoundを修正

デプロイの問題を修正する

コンテナーのビルドエラーを修正する

azd upハングまたはタイムアウトを修正する

デプロイされるが応答しないエージェントを修正する

ダイレクト コマンドのエラーを修正する

解決された Foundry プロジェクト エンドポイントを修正しない

既存のリソースの作成エラーを修正する

connection show資格情報の出力を修正する

エージェント ログの読み取り

定期的なエラーを診断する

過去の実行を確認する

失敗に絞り込む

1 回の実行にドリルダウンする

ルーチンを手動でリトリガーする

失敗したルーチン実行を修正する

決して起動しないルーチンを修正する

その他のヘルプを表示する

関連するコンテンツ

フィードバック

その他のリソース

修正 `AuthenticationError`

プロビジョニング中の `AuthorizationFailed` を修正する

修正 `SubscriptionNotRegistered`

`ResourceNotFound`または`DeploymentNotFound`を修正

`azd up`ハングまたはタイムアウトを修正する

ダイレクトコマンドのエラーを修正する

解決された Foundry プロジェクトエンドポイントを修正しない

`connection show`資格情報の出力を修正する

エージェントログの読み取り