評価失敗を記録することで、今後のトリアージセッションを迅速化する組織的知識が蓄積されます。 同じ種類のエラーが再び発生した場合、同じ根本原因を改めて突き止めるのではなく、最初に何をチェックすべきかが既に分かっています。
これらの構造化されたテンプレートを使用して、トリアージセッションにおけるエラー分析を記録してください。 チームのニーズやワークフローに合ったバージョンを選択してください。
重要
まず、故障トリアージを完了してください。 不具合が発生したら、診断と同時にその内容を記録してください。
チームに合ったテンプレートバージョンを選択してください。
軽量エラーログ
軽量エラーログは小規模チームや迅速なトリアージセッション向けです。
この表をコピーして、トリアージセッション中に記入してください。 失敗ごとに 1 行追加してください。
| テスト ケース | 主要因タイプ | 観察された問題 | 変更適用 | 解決済 |
|---|---|---|---|---|
| ___ | 評価設定、エージェント構成、プラットフォームの制限 | ___ | ___ | はい / いいえ / 部分的 |
| ___ | ___ | ___ | ___ | ___ |
| ___ | ___ | ___ | ___ | ___ |
例 (記入済み)
| テスト ケース | 主要因タイプ | 観察された問題 | 変更適用 | 解決済 |
|---|---|---|---|---|
| KG-003 | 評価セットアップ | 期待される回答が古い（旧返金ポリシー：30日間、現行ポリシー：15営業日） | 期待値を「15営業日」に更新 | 有 |
| KG-005 | エージェントの構成 | エージェントが提供した保証の詳細は、どのサポート情報ソースにも記載されていなかった | グラウンディング指示を追加：「サポート情報ソースからのみ回答する」 | 有 |
| TI-002 | プラットフォームの制限 | 検索順位付けが正確なドキュメントタイトルを考慮せず、FAQが製品マニュアルの代わりに常に取得される | 回避策としてドキュメントの見出しを再構成し、プラットフォームチームにエスカレーションした | 部分的 |
| FA-019 | プラットフォームの制限 | 曖昧なクエリは正しいソースを安定して取得できません | 既知の制限として記録済みであり、本番環境で監視中 | いいえ（既知のギャップ） |
詳細な失敗ログ
詳細な失敗ログは、調査結果の共有、スプリント間での状況追跡、複数エージェントにわたる組織知の構築が必要なチーム向けです。
注意
このテンプレートの CSV版 をダウンロードしてください。
失敗ごとの記録
| フィールド | 値 |
|---|---|
| テスト ケース ID | （評価セット（例：KG-003）） |
| 評価セット | （この記録がどの評価セットに属しているか） |
| 品質信号 | （事実の正確性、知識の根拠付け、ツール呼び出しなど） |
| 主要因タイプ | （評価セットアップ、エージェント構成、プラットフォーム制限、ツール統合、未分類） |
| 根本原因の詳細 | （特定のサブタイプ。例：「古い期待回答」や「ツール説明の曖昧性」など） |
| 観察された問題 | （エージェントの実際の行動と期待される行動） |
| 診断パス | （どのトリアージ質問がこの分類につながったか。例：「手順1、Q1.2—期待される回答が古くなっている」） |
| 修復活動 | (変更内容。再現可能なほど具体的な詳細) |
| 状態 | (オープン、進行中、解決済み、修正しない) |
| 修正しない理由 | （修正しない場合：理由と、どのような監視が行われているか） |
| 検証 | （再実行結果：合格または失敗、日付、イテレーション番号） |
| トリアージ日 | ___ |
| トリアージ担当 | ___ |
例 (記入済み)
| フィールド | 値 |
|---|---|
| テスト ケース ID | KG-005 |
| 評価セット | 知識グラウンディング |
| 品質信号 | 知識グラウンディング |
| 主要因タイプ | エージェントの構成 |
| 根本原因の詳細 | 誤った情報、エージェントが生成した内容はサポート情報ソースに存在しません |
| 観察された問題 | エージェントは「部品と労務をカバーする3年間の延長保証」と主張しましたが、情報源には「標準保証2年」と記載されています。 |
| 診断パス | 手順1合格（評価有効）→ 手順2、Q2.4（ソースなしで回答）＋ Q2.5（ソースと矛盾） |
| 修復活動 | システムプロンプトに追加：「サポート情報ソースにある情報に基づいてのみ回答してください。」 情報がなければ、そう言ってください。」 |
| 状態 | 解決済 |
| 修正しない理由 | 在庫切れ |
| 検証 | パス（2回目、2月15日） |
| トリアージ日 | 2 月 14 日 |
| トリアージ担当 | [name] |
イテレーション要約ログ
傾向分析のために、反復処理全体を通してスコアと変化を追跡します。
| 繰り返し | 日 | 変更内容 | 影響を受けた評価セット | 変更前スコア | 次のスコア | 差分 | メモ |
|---|---|---|---|---|---|---|---|
| 1 | ___ | ベースライン（変更なし） | All | — | ___% | — | 初回実行 |
| 2 | ___ | ___ | ___ | ___% | ___% | ___ | ___ |
| 3 | ___ | ___ | ___ | ___% | ___% | ___ | ___ |
集中度まとめ
各トリアージ セッション後、根本原因の種類を集計して集中パターンを見つけます。
| 主要因タイプ | カウント | 全体の割合 (%) | 体系的かどうか? |
|---|---|---|---|
| 評価セットアップ | ___ | ___% | （80%以上の場合はエージェントの作業を一時停止し、まず評価を修正する） |
| エージェントの構成 | ___ | ___% | （80%以上が 1 つの領域に集中している場合＝アーキテクチャ上の問題） |
| プラットフォームの制限 | ___ | ___% | （80％以上＝範囲の再評価、エスカレーション） |
| ツールまたは統合 | ___ | ___% | (エージェントではなく、バックエンドを修正) |
| 未分類 | ___ | ___% | （監視。さらにデータが増えれば分類できる可能性あり） |
| 合計 | ___ | 100% |
ログを維持するためのベスト プラクティス
- トリアージ中にリアルタイムで更新します。 セッション後の一括更新は避けてください。
- ネガティブな結果も必ず記録しましょう。たとえば「X を試したが、効果がなかった」などです。この実践により、失敗したアプローチを再度試すことを防げます。
- 必ず各イテレーションの前にレビューしてください。 個々の失敗に対処する前に、共通パターンがないか確認しましょう。
- チーム全体で共有しましょう。 ログをチームのメンバー全員に共有し、以前の発見を参照できるようにしてください。
- 削除せずにアーカイブしてください。 パターン分析のために、解決済みのエントリは保存しておいてください。 アクティブなログが長くなった場合は、エントリーをアーカイブセクションに移動してください。
次の手順
失敗を記録した後:
- レイヤー4: パターンを分析してシステム上の問題を特定します。
- 「レイヤー 3: エラーパターンを修復戦略にマッピングする」を使用して、対象を絞った修正を適用します。
- 継続的な改善を維持するために、評価ワークフローを継続してください。