プロパティテストは合理的に聞こえますが、実際にはどのように「どのプロパティをアサーションとして書く価値があるか」を決めればいいですか？プロパティが少なすぎると重要なエラーを見落とす可能性はありませんか。多すぎると別の形の過度な正確一致になりませんか？
プロパティテストがどのプロパティをカバーすべきか決める核心的な考え方は、「この出力が間違っていたら実際にどんな被害が生じるか」を振り返って問うことで、可能なすべてのプロパティを網羅しようとするのではなく、被害の深刻さで優先順位をつけることです。
アサーションとして書くことを優先すべきプロパティタイプ：決定の正確性に直接影響するコアフィールド（前述の信頼スコアが合理的な範囲内にあるか、状態フィールドが期待される選択肢の1つであるかなど）。これらのプロパティのエラーは直接下流の誤った決定につながるため、優先的にカバーする価値があります。安全境界に関わるプロパティ（「Agentは信頼スコアがある閾値未満のとき、絶対にexecute: trueを返すべきではない」といった境界条件）。この種のプロパティのアサーションは「防御メカニズムが本当に機能しているか」をテストするもので、優先的にカバーする価値があります。形式と内容の一貫性に関するプロパティ（前述の記事で触れたように、推論根拠である具体的な数字を引用したと主張しているなら、その数字が本当に根拠のテキストに現れるべきで、漠然とした説明ではいけない）。この種のアサーションは前述の記事で議論した「形式は正しいが内容が空虚」という隠れたリスクを捕捉できます。
アサーションとして書く必要がなく緩和できる部分：純粋な言い回しの違い（「この機会は実行する価値がある」と「この取引の実行を推奨する」という2つの言い方は意味は同じだが言葉が違うなど）は正確なテキスト内容をアサートする必要はありません。非コアな補足説明フィールドは、内容にある程度の表現の柔軟性があっても全体的な決定品質への影響は限定的で、テストの優先度を下げられます。
「書きすぎか書き足りないか」を判断する実務的なシグナル：LLM出力の言い回しの違いによりテストスイートが頻繁に失敗する（実際の決定ロジックは正しいのに）と気づいたら、これは通常アサーションが正確すぎ、文字通りの一致に近すぎることを示し、より緩やかなプロパティアサーションに緩和すべきです。テストスイートが全く捕捉できなかったエラーが本番環境で発生している（信頼スコアが明らかに不合理なのにすべてのテストを通過するなど）と気づいたら、これはカバーしているプロパティの次元が不十分であることを示し、対応するアサーションを追加すべきです。これは実際の運用経験に基づいて継続的に調整する必要がある動的プロセスであり、一度書いたら二度と触らない静的チェックリストではありません。
私のAgentシステムが使用するLLMモデルバージョンを頻繁に更新する場合（あるモデルから別の新しいモデルに切り替えるなど）、前述のテストフレームワークはモデルを変更するたびに再設計する必要がありますか？
フレームワーク全体を再設計する必要はありませんが、再実行する必要があり、モデルバージョン更新後のテストは、実はプロパティテストの設計思想が最も価値を発揮できるシナリオの1つです。理由は次の通りです。
テストフレームワーク自体（4層の分割、プロパティアサーションの設計思想）はモデルに依存しません。決定論的ロジック層のテストはどんなLLMを使うかとは全く関係がなく、モデル変更のために調整する必要はありません。LLM推論層のプロパティアサーションは「出力がどんな合理的範囲を満たすべきか」に対して設計されており、この合理的範囲自体は理論上モデルが変わっただけで変わるべきではありません（モデル変更後「信頼スコアが合理的範囲に収まるべき」というビジネスロジック要件が変わったなら、それはビジネスロジック自体の問題であり、テストフレームワークの問題ではありません）。
すべきことは、モデル変更後にテストスイート全体を再実行することであり、再設計することではありません。これはまさにプロパティテストが正確一致テストに対して持つ優位性です——テストアサーションが「ある文字列に正確一致する」と書かれている場合、モデルを変えて言い回しのスタイルが変わると、この種のアサーションは大量に失敗しますが、失敗の理由は単に言い回しが違うだけで、ロジックが本当に間違っているわけではありません。この種のテストはモデル変更時にむしろ大量の「誤報」を生み、調査時間を無駄にします。テストアサーションがプロパティレベル（前述のQ1で議論したもの）で書かれている場合、モデル変更後に再実行すれば、新モデルの推論品質が劣化していなければ、これらのプロパティアサーションは依然として通過するはずです。プロパティアサーションはそもそも特定のモデルの言い回しスタイルに依存しないためです。
モデル変更後に特に注目する価値のあるテストの側面：テストフレームワークを再設計する必要がなくても、モデル変更後はエンドツーエンドテスト内の「境界事例」というカテゴリのケースの結果に特に注目することを推奨します——異なるモデルが境界事例や曖昧なシナリオを処理する際のパフォーマンスの違いは、通常明確なシナリオを処理する際の違いより大きいです。これはモデル変更後「新モデルはまずまず良さそうだが境界事例の処理が悪化した」という隠れた劣化が最も現れやすい場所であり、優先的に再確認する価値があります。
追加の推奨：旧モデルのテスト結果を基準線として保持する。テストフレームワークが「今回のテストで各プロパティアサーションの通過率、信頼スコアの分布状況」といった統計情報を記録していれば、モデル変更後、新モデルのテスト結果を旧モデルの基準線と比較でき、単に「新モデルがテストを通過したか」という二元的結果だけを見るのではありません。例えば新モデルはすべてのアサーションを通過するかもしれませんが、信頼スコアの全体的な分布が旧モデルと比べて明らかにシフトしている（全体的により保守的または積極的になっている）ことがあります。この種の傾向的な変化は「合格/不合格」だけを見ていては発見しにくいですが、基準線との比較を通じて見て取ることができ、正式にモデルを切り替える前に評価に組み込む価値があります。
記事はエンドツーエンドテストに「異常または欠落した市場データ」というシナリオを含めるべきだと触れていますが、具体的にこの種のテストケースをどう設計すればいいですか？意図的にでたらめな偽データを入力すればいいだけですか？
完全にランダムなでたらめなデータを意図的に入力しても、テストの価値は限られます。この種のデータが実際の本番環境で発生する確率は低く、検証すべき具体的な防御ロジックにも対応しにくいためです。より価値のある方法は「現実世界で実際に起こりうる異常パターン」に対応するテストケースを設計することで、テスト結果が直接「この防御ロジックが実際に遭遇しうるこのシナリオを適切に処理しているか」に対応するようにできます。
具体的な異常パターンの分類と対応するテスト設計：部分的なデータ欠落（完全にランダムではなく）。例えば「あるプロトコルの利率を照会する際、APIは成功を返すがあるフィールドがnullまたは空文字列である」という実際に起こりうるシナリオをシミュレートし（サードパーティAPIは時々フィールド欠落が起こる）、Agentがこの種の部分的に欠落したデータに直面したとき適切な処理ロジックがあるかテストします（このデータが不完全であるとマークする、前述の構造的失敗処理をトリガーするなど。null値を0やデフォルト値として扱い後続の計算を強行し、誤ったデータに基づいて決定を下すことがないように）。形式は正しいが数値が異常。例えば「照会された利率が-50%」や「TVLが突然負数になる」といった構文的には合法（数値である）だがビジネスロジック上明らかに不合理な値をシミュレートし、Agentがこの種の「構文的には合法だが意味的に異常」な値に対して妥当性チェックを行っているか、それとも無条件に受け入れて直接計算に使ってしまうかをテストします。タイムスタンプの異常。例えば「照会された市場データのタイムスタンプがずっと前の古いデータを示している、リアルタイムデータではない」ことをシミュレートし、Agentがデータの時効性をチェックしているか、データがどれほど古くても無条件にリアルタイムデータとして使ってしまうかをテストします——これは前述のスリッページ許容度記事で議論した、即時性に敏感な情報には有効期限の概念が必要であることと呼応します。一部のサービス利用不可。例えば「複数のプロトコルの利率を照会する際、1つのプロトコルのAPIがタイムアウトまたはエラーを返し、他のプロトコルは正常」というシナリオをシミュレートし、一部のデータソースが失敗した場合でもAgentがまだ取得できるデータに基づいて合理的な判断を下せるか（または「今回の判断根拠は不完全」と明確にマークするか）、1つのソースが失敗したために判断ロジック全体がクラッシュしたり止まったりしないかテストします。
設計原則：各異常テストケースは「これは現実世界で実際に発生した、または発生すると信じる合理的な理由がある状況」に対応しているのが望ましく、何もないところから想像した極端な状況ではありません——過去に実際に遭遇した本番環境の問題（あれば）や、類似システムでよくある故障モードを参考にし、これらの実際に起こりうる異常パターンを具体的なテストケースに変換することで、テスト結果が実際の参考価値を持ち、テストのためのテストにならないようにできます。
マルチAgentシステムで、Sub-agent間のHandoffロジック、特に前述のHandoff項目で触れた循環検知とグローバル上限といったメカニズムをカバーするために、テストフレームワークをどう調整すべきですか？
マルチAgentシステムのテストは、前述の4層テストフレームワークを各Sub-agentにそれぞれ適用することに加え、「調整層」のロジックに対して専用のテストケースを追加設計する必要があり、具体的にいくつかの方向に分けられます。
循環検知メカニズムのテスト：前述のHandoff項目で、タスクが数個のAgent間を行ったり来たりする場合（AがBに渡し、BがAに戻す）、循環検知メカニズムに遮断されるべきだと触れました。このメカニズムをテストする方法は、循環をトリガーするシミュレーションシナリオを意図的に構築することです（テスト用のSub-agent Bに「このタスクは自分で処理できない、Aに戻す」と意図的に判断させ、Aが受け取った後「このタスクはBに処理させるべき」と判断するなど）。循環検知メカニズムが重複した引き継ぎ対象を検知した際、無限にループさせ続けるのではなく本当にこの循環を正しく中止するか検証します。この種のテストにはSub-agentの判断ロジックを正確に制御できる能力が必要です（テスト用のモックバージョンを通じて、テストシナリオ下でSub-agentに特定の判断結果を強制的に返させるなど）。実際のLLM推論のランダム性に頼って「たまたま」循環シナリオをトリガーするのではありません。
グローバル上限メカニズムのテスト：「タスクが上限を超えて引き継がれる」というシナリオをシミュレートし、システムが上限に達したら本当にタスクを強制中止し人的介入が必要とマークするか検証します。引き継ぎ回数のカウンタ自体にバグがあってはいけません（カウンタが各層間で正しく累積伝達されないなど。前述のHandoff項目で触れた「複数層のリトライ回数が意図せず合計ではなく積に増幅される」というリスクは、引き継ぎ回数のテストにも適用され、3層以上のHandoffを含むテストシナリオを専用に設計し、グローバルカウンタが正しく動作しているか検証する価値があります）。
引き継ぎ情報の完全性に関するテスト：「Sub-agent AがSub-agent Bに引き継ぐ際、引き継ぎパッケージにある重要なフィールドが欠落している」というシナリオをシミュレートし、Sub-agent Bが不完全な引き継ぎ情報に直面したとき適切な処理ロジックがあるか検証します（前述の再照会や追加情報要求メカニズムをトリガーするなど）。引き継ぎパッケージが必ず完全だと直接想定し、不完全な情報で後続の判断を無理やり行うのではなく。
実行前再検証メカニズムのテスト：「Sub-agent Aが判断を完了してからSub-agent Bが実際に実行するまでの間に市場状況がすでに変化している」というシナリオをシミュレートし（前述のスリッページ許容度記事の事例など）、Sub-agent Bが本当に再照会と比較を行っているか、Aが与えた古いデータをそのまま使って直接実行していないか検証します。
これらのテストの共通する特徴：これらはいずれも単一のSub-agentの推論品質をテストするものではなく（それは前述のLLM推論層プロパティテストが担当すべきもの）、「複数のAgentが協調して動作する際、前述の記事で繰り返し議論した安全メカニズム（循環検知・グローバル上限・引き継ぎの完全性・実行前検証）が本当に設計通り機能しているか」をテストするものです。これはマルチAgentシステム特有の、単一Agentのテストフレームワークではカバーされないテストの側面であり、独立したテストカテゴリとして扱い、追加のリソースを投じて設計する価値があります。
従来のソフトウェアの単体テストの核心的な前提は「同じ入力は同じ出力を生むべき」というものです——この前提がテストを予測可能で自動化可能なものにします。テストケースを書き、特定の入力である関数がどんな結果を返すべきかをアサートし、一度テストを実行すればロジックが正しいか確認できます。この前提はAgentシステムでは直接崩壊します。LLMの推論プロセス自体に一定の不確実性が内在しており、同じ入力でもモデルのランダム性により、異なる実行のたびに完全には同一でない推論経路をたどり、わずかに異なる結果に至る可能性があるためです。これはAgentテストが「同じ入力・同じ出力」という前提に完全には依存しないテストフレームワークを必要とすることを意味し、この記事が分解するのはまさにこのフレームワークがどのようなものであるべきかです。
Agentシステムにとって、テストを3つの階層に分けてそれぞれ処理する方が、「万能なテスト一式」を書こうとするより実務的です。決定論的ロジック層・LLM推論層・エンドツーエンド統合層、各層に適したテスト方法は全く異なります。
Agentシステム内のすべてが不確実なLLM推論に関わるわけではありません——ツール関数自体のロジック（「利率を照会する」ツールがプロトコル名を与えられ対応するAPI照会結果を返すなど）、状態オブジェクトの更新ロジック、前述の記事で触れたリトライ回数計算・コスト累積計算、これらはすべて決定論的なプログラムロジックであり、同じ入力は必然的に同じ出力を生みます。この層は完全に従来の単体テスト方法が適用でき——アサーションを書き、テストを実行し、合格か不合格かを検証する、特別なAgentテストのテクニックは不要です。この層のテストの価値は過小評価されがちです。誰もが「LLM推論が正確かどうか」というより目立つ問題に注意を向けているためですが、決定論的なロジック自体にバグがあれば（リトライカウンタのインクリメント忘れ、コスト累積の計算ミス）、どれほど正確なLLM推論でも根底のロジックに欠陥のあるシステムを救えません。
LLM推論に関わる部分については、「入力Xは必ず出力Yを得るべき」とアサートできません（モデルのランダム性により出力が変動しうるため）が、「出力は特定のプロパティを満たさなければならない」とはアサートできます。これがプロパティベーステスト（property-based testing）の核心的な考え方で、Agentシナリオに適用したものです。具体的には「この市場シナリオが与えられた場合、Agentは必ず`execute: true`を返すべき」という正確一致のアサーションを書く代わりに、「この市場シナリオ（明らかに利益の出る裁定機会）が与えられた場合、Agentが返す`confidence_score`は0.7を超えなければならない」「Agentの推論根拠には具体的な利率数字が言及されなければならず、漠然としたテキスト説明だけではいけない」「Agentが実行しないと判断した場合、`status`フィールドは空欄ではなく`insufficient_opportunity`でなければならない」といったプロパティアサーションに書き換えます。これらのアサーションはLLM出力の言い回しや詳細にある程度の変動余地を許容しつつ、「この出力が合理的な範囲内にあるか」という核心的な問題を依然として捕捉できます。
最初の2層のテストがそれぞれ独立してうまく機能していても、システム全体を繋げても問題がないとは限りません——ノード間で状態が正しく伝達されるか、Handoffの情報が完全か、マルチAgentの協調フローが期待通りか、これらはエンドツーエンドの統合テストでしか検証できません。エンドツーエンドテストの重要な設計は「制御されたシミュレーション市場シナリオを使い、実際の本番環境データに直接接続しない」ことです。具体的には代表的なテストシナリオ一式を構築します（「明らかに利益の出る裁定機会」「利差が小さく損益分岐点に近い境界事例」「流動性が極めて悪く取引が失敗しやすいシナリオ」「市場データ自体に異常や欠落があるシナリオ」）。各シナリオについて、シミュレーションまたは履歴スナップショットの市場データを使い、Agentフロー全体を一度実行し、システム全体がこれらの異なるシナリオで期待通りに動作するか検証します。ここでは前述の境界事例と異常シナリオを特に含めるべきです。大半のバグは「すべて正常」なシナリオには現れず、境界や異常状況の処理ロジックに現れるためです。
最初の3層のテストは入力が「正常」であることを前提としています（境界事例を含んでいても自然に発生する境界事例）が、前述のPrompt Injection項目と記事で議論した攻撃面については専用の敵対的テストで検証する必要があります——悪意ある指示を含む入力を意図的に構築し（Agentの行動を操作しようとするテキストをシミュレートされたオンチェーンメタデータに詰め込むなど）、Agentの防御メカニズム（入力の分離・最小権限）がこの種の攻撃を本当に効果的に遮断しているか検証し、「防御メカニズムを書けば必ず有効」と想定しないようにします。この層のテストはコストが比較的高い（専用の攻撃ケース設計が必要）ですが、実際の資金を扱うAgentにとって、これはローンチ前に省略すべきでないステップです。
ローンチ準備中のAgentシステムを開発しているなら、テスト戦略は「手動で数回実行して正常そうだからローンチする」という段階にとどまるべきではありません。テストを決定論的ロジック・LLM推論プロパティ・エンドツーエンド統合・敵対的テストという4つの層に分け、各層に適したテスト方法（従来の単体テスト・プロパティテスト・シミュレーションシナリオ統合テスト・意図的に構築された攻撃テスト）を使うことで、実際のローンチ前に問題を発見する確率を大幅に向上できます。特にリソースを投じる価値があるのはエンドツーエンドテスト内の境界事例と敵対的テストです。これら2種類の問題は「すべて正常」な手動テストで最も見落とされやすいですが、実際の運用で重大な損失を引き起こす可能性が最も高いシナリオだからです。