Arize AI、Signal が Alyx で発見した隠れたリトライループの事例を公開

Arize AX に組み込まれた AI エンジニアリングエージェント「Alyx」で Signal を実行したところ、通常の監視では見逃されがちな問題が浮き彫りになりました。具体的には、進捗のように見えるタスク状態のループと、43 回の呼び出しに及ぶデータセットのリトライです。これらは従来のツール呼び出しやルートスパンの観点からは正常な活動として認識されていました。

AI システムにおけるバグは、エラーとして現れることはめったにありません。むしろ「振る舞い」として現れます。進歩しているように見えるループ、正しくない動作をする有効なツール呼び出し、あるいは依然として OK と表示されるルートスパンなどです。

こうした振る舞いを人手で発見するのは時間がかかります。例外のように grep で検索することもできず、一度に一つのトレースを検査するだけではスケールしません。

Signal は大量の生産環境トレースをレビューし、繰り返し現れる振る舞いをランク付けされた課題としてグループ化します。そして各課題について、根拠、影響度、次のアクションを示す調査へと発展させます。

実際に、自社で運用している Alyx で Signal を実行したところ、従来の監視では健全な実行と見なされていたタスクループとデータセット参照のリトライを検出することができました。

コードの変更自体は小さかったものの、Signal が担ったのは高コストな部分です。つまり、パターンの発見と、修正への明確な道筋の提示です。

Arize AX に組み込まれた AI エンジニアリングエージェント Alyx について、通常の監視では見逃される可能性のある生産環境トレースから何が読み取れるのかを明らかにしたかったのです。

私たちは、Arize AX に新たに組み込まれた管理エージェント「Signal」を用いて、Alyx の動作を調査しました。その結果、227 秒間にわたる実行で 192 のスパンが生成され、同じツールが 43 回呼び出されたケースにおいて、即座に問題を検知することができました。ルートスパンは正常と報告されていましたが、Alyx がクラッシュしたわけではありませんでした。実際には、空のオプションフィールドによって誤った検証パスへ誘導され、その結果生じたエラーメッセージがエージェントを同じツールへと繰り返し呼び戻すループを引き起こしていたのです。

これは Signal が見つけた 2 つのリトライループのうちの一つで、一見すると妥当なエージェントの活動に見えました。いずれの場合も、最終的なコード修正は小規模なものでしたが、Signal を利用する以前には、本番環境のトレースに潜むこうした行動パターンを見逃していました。

Arize Signal とは何か？

Signal は Arize AX の機能の一つで、本番環境のトレースをレビューして繰り返されるエージェントの動作を検出し、関連するパターンをランク付けされた課題としてグループ化します。さらに、裏付けとなる証拠、推定影響度、そして次のアクションを示唆した調査レポートを作成します。

この「次のアクション」には、プロンプトやコード、設定、評価基準の変更が含まれる可能性があります。また、企業チームは GitHub リポジトリを接続することで、Signal が調査内容をコードベースに引き継ぎ、レビュー用のプルリクエストまたはスコープ限定のイシューを自動的に作成することも可能です。

私たちは Signal を用いて、Arize AX に組み込まれた AI エンジニアリングエージェント「Alyx」の分析を行いました。30 日間にわたる調査で、Signal は Alyx の本番トレースから 34 の課題を検出しました。その中には、この記事で詳しく取り上げる 2 つの行動上の失敗も含まれています。

Alyx で Signal が見つけたこと

Alyx で見つかった 2 つの問題には、共通する基本的な構造がありました。エージェントがツールの応答を受け取り、「アクションに失敗した」という示唆を得た後、状態を改善し得ない操作を繰り返していたのです。

問題の概要

モニタリングで明らかになったこと | 実際にエージェントが行っていたこと | 対策

---|---|---

Todo ステータスのリトライループ | 有効なツールの呼び出しが繰り返し発生 | すでに完了したステート遷移を再試行している | 同じステータスへの重複更新は、成功した NOP（何もしない操作）として扱う

空のデータセット ID リトライ | ルートスパンは正常とマークされている | オプションフィールドが空で誤ったコードパスに入り、get_datasets が 43 回も繰り返された | ツール境界において、空のオプション値を None に正規化する

いずれの問題も、エンジニアが既知の例外を検索することから始まったわけではありません。Signal は再発する振る舞いを検出し、関連するトレースをグループ化して、失敗の原因を理解するために必要な証拠を提示しました。

発見 1: todo_update エラーが Alyx をリトライループに閉じ込めた理由

Alyx はタスクリストを使用して、多段階の作業を調整します。計画を作成または復元したり、pending（保留中）、completed（完了）、blocked（ブロック済み）といったステート間でタスクを進めたり、ターンが終了する準備ができたら finish() を呼び出したりできます。

通常のフローは概ね以下のようになります。

1. todo 計画を復元または作成する
2. 現在のタスクを選択する
3. 完了に必要なツールを呼び出す
4. todo_update でタスクのステートを更新する
5. 計画が完了したら finish() を呼び出す

証拠となるトレースでは、finish() が拒否されました。その理由は、まだブロックされた作業が残っていたためです。これを受け、Alyx はブロックされたタスクの更新を試みました。

todo_update(id=0, status="blocked") を再度呼び出した際、既存の状態を確認する代わりに回復可能なエラーが返されました。すべてのツールレスポンスはモデルのコンテキストに追加されるため、エージェントはこのエラーを「アクションが失敗した」という証拠と解釈してしまいました。

その結果、トランジションを再試行しました。時には todo_update と finish() を交互に行うこともありましたが、いずれも根本的な状態を変更しないため、ストリームがキャンセルされるまでループが続きました。

image 完了済みタスクの todo_update リトライループに関するシグナル問題。証拠トレース、finish() の繰り返し拒否、todo_update(..., blocked) の繰り返し呼び出し、そして関連する PR アプローチを示しています。

コードの変更は単純でした。要求されたステータスが現在のステータスと一致している場合、todo_update は現在タスクリストを成功結果として返すように変更されました。エラー処理は、タスクリストの欠落や不明なタスク ID といった本当に無効なケースにのみ残されています。

imageGitHub PR #77349 のマージ画面は、todo_update リトライループの根本原因を示しています。ステータス更新が重複して発生し、RecoverableException が投げられたことで、メッセージが LLM に戻され、同じツール呼び出しが繰り返されるという悪循環でした。

チームはまた、この重複した状態遷移をカバーする回帰テストも追加しました。修正までの時間は、問題の挙動を発見し再構築することに要されました。パターンが見えた瞬間、パッチ自体は非常に小さく済みました。

発見 2: 空のデータセット ID が 43 回のツール呼び出しを生んだ理由

2 つ目の問題は get_datasets ツールで発生しました。このツールには 2 つの動作モードがあります。

• dataset_id を省略した場合：現在のスペースにあるデータセットの一覧を表示します。
• dataset_id を指定した場合：選択したデータセットをプレビュー表示します。

Alyx は利用可能なデータセットの一覧を取得しようとしていました。しかし、本番環境のペイロードでは、オプションフィールドである dataset_id に空文字列が渡されていました。

型付けされたツールの境界において、空文字列は「指定された値」として扱われます。そのため検証プロセスはこれを有効な候補 ID とみなし、以下のエラーメッセージで拒否しました。

Dataset ID is invalid. Make sure you are getting the id from get_datasets().

この回復ガイダンスにより、Alyx はすでに呼び出していた同じツールへ戻されました。より適切な修正手段がないため、モデルは再試行を繰り返します。

影響を受けた 1 つの実行では以下の状況が確認されています：

• スパン数：192
• ランタイム：227 秒
• オーケストレーター反復回数：50
• get_datasets の重複呼び出し：43 回
• ステータスが OK のままだったルートスパン

imageAlyx trace showing a healthy root status alongside high latency, repeated orchestrator iterations, and repeated tool calls under one_alyx_agent.

The fix moved empty-string normalization into the shared tool boundary. Optional fields that permit None now convert empty strings to None before entering tool-specific validation.

A regression test recreates the production payload and verifies that get_datasets enters list mode rather than returning an invalid-ID error.

Again, the code change was limited. The difficult part was identifying that an apparently healthy trace contained a repeatable behavioral failure.

Why behavioral debugging changes the cost of fixing agents

These incidents illustrate a common production pattern. The agent's implementation bug may be small, while discovering it requires a broad view of runtime behavior.

A human investigating either issue manually would need to:

Notice that a long trace contained little meaningful progress.

Reconstruct the sequence of model decisions and tool responses.

Determine whether the pattern appeared in other traces.

Identify the shared mechanism.

Locate the code boundary responsible for that behavior.

Create a reproducible test case.

Signal は、エンジニアがデバッグを開始する前に、高コストな調査作業の多くを自動で行います。関連するトレースをグループ化し、繰り返し発生する挙動を記述した上で、証拠をまとめてレビュー可能な調査レポートとしてパッケージ化するのです。

一部の発見は直接プルリクエストに反映できますし、他のケースでは関連するトレースを添付した GitHub イシューとして記録するのが適切です。いずれの場合も、チームはフルタイムでのトレースレビューローテーションを維持する必要なく、範囲を限定された着手点を得ることができます。

これにより、チームが観測可能性データを活用する方法も変化します。トレースはエージェントが何を行ったかを文書化するものですが、行動分析によって、その行動がシステムを意図した成果に向けて進めたかどうかを判断できます。

Signal を用いたプロダクション AI エージェントの監視方法

チームは Signal を継続的なプロダクションフィードバックループとして活用できます：

• プロジェクトに Signal を有効化する。Signal は新しいトレースをレビューし、繰り返し現れる行動パターンを検出します。
• 順位付けされたイシューを確認する。各イシューには、挙動の説明、影響を受けたトレース、インパクト、そして裏付ける証拠が含まれています。
• 完全な軌跡（トランジェクト）を検証する。問題を引き起こしたモデルの意思決定、ツール呼び出し、ツールの応答、状態遷移を追跡します。
• 適切な介入を選択する。発見された事象は、プロンプト、コード、設定、ツールスキーマ、あるいは評価基準の変更を指している可能性があります。
• 回帰テストケースを作成する。プロダクションのペイロードまたは軌跡を変換してテストとし、同様の挙動が再発しないようにします。

調査は GitHub へと続きます。エンタープライズチームはリポジトリを接続し、検出された課題をプルリクエストやスコープ限定のイシューとして作成できます。

実際のワークフローを確認するには、Signal のチュートリアルに従うか、ウェビナーのウォークスルー動画をご覧ください。

本番環境のエージェントは、スパンレベルでは健全に見える失敗を継続して発生させる可能性があります。実用的な利点は、これらのトレースを反復可能なエンジニアリングループに変換できる点にあります。具体的には、パターンを検出し、証拠を確認し、変更をリリースし、回帰テストを追加し、再び本番環境を観察するという一連のサイクルです。

今回の Alyx に関する 2 つの問題に対する修正は小規模なものでした。Signal は、エージェントの動作がどこで誤ったのかを特定することで、最もコストのかかる部分を処理しました。

「How Signal found two hidden retry loops in our production agent Alyx」という記事は、元々 Arize AI で公開されました。