検証できる仮説でデバッグする

修正案より先に不具合を記述する

有用なデバッグ依頼は、期待する動作、観察した動作、影響範囲を示します。バージョン、関連する入力、エラーを含めます。AIツールにログを渡す前に、認証情報と非公開のレコードを取り除いてください。

「エクスポートが壊れた」だけでは、調査の方向がほとんど分かりません。「ローカルでは成功します。stagingでは、最新のデプロイ後から同じマネージャーのリクエストが403を返します。他のルートは動作します」と書くほうが有用です。

この説明だけで原因は確定しません。調査の手掛かりとなる違いを示しています。

複数の説明を残す

考えられる原因を少数挙げ、それぞれの証拠を示すようエージェントに依頼します。最初の説得力のある説明に決めつけさせないでください。

架空のエクスポート障害では、サービスIDの権限不足、ロールの対応付けの変更、誤った環境へのリクエストなどが考えられます。それぞれの説明から予測される証拠は異なります。

この表は出発点です。403応答は、さまざまな層から返る可能性があります。アプリの認可に失敗したと決める前に、どのコンポーネントが応答を返したか特定します。

安全な観察を選ぶ

低コストで説明を区別できる観察から始めます。デプロイ済みのバージョンと、機密ではない設定を比較します。関連するエラーとリクエスト識別子を調べます。可能なら、許可されたテスト環境で問題を再現してください。

エラーが消えるかを見るためだけに、広い権限を与えてはいけません。セキュリティの境界を変え、実際に不足する権限を隠す可能性があります。機密情報を取り除いたエラーとリクエスト経路で十分なら、本番ログ全体をモデルに貼り付けないでください。

何が観察されると各仮説の可能性が弱まるかを示します。エージェントが最初の回答を守るのではなく、説明を修正する助けになります。

一度に一つの原因を修正する

証拠から有力な原因が分かったら、そこに絞って修正します。権限の変更、ライブラリのアップグレード、ハンドラーの書き直しをまとめないでください。症状が消えても、どの変更が効いたか分からなくなります。

元の失敗条件を検証します。隣接する境界も確認してください。マネージャーのアクセスを修正したら、権限のない利用者は引き続き拒否されることを確認します。

再発する不具合には、検出できる層に回帰テストを追加します。単体テストでは、デプロイ設定の誤りをすべて検出できません。結合テストや、管理されたデプロイ後の検証が必要な不具合もあります。

新しい証拠がない試行を止める

エージェントは、多数の修正案を生成できます。試行を増やしても、診断が改善するとは限りません。同じ失敗が続くなら、次の試行でどのような新しい観察が得られるかを尋ねます。

不確実な調査には、時間や試行回数の上限を設定します。上限に達したら、現在の証拠、棄却した仮説、未解決の問いを報告してください。この記録があれば、別の人が同じ実験を繰り返さずに続けられます。

復旧後は、原因と、その不具合が影響先の環境へ届くことを許した条件を記録します。修正は、目の前の不具合を取り除きます。有用な追加対応は、同じ不具合が再発する可能性を減らします。