auditing-experiments-flags

実験とフィーチャーフラグの監査

このスキルでは、実験とフィーチャーフラグの設定監査を実行する方法を説明します。 すべてのチェックでは、実験とフィーチャーフラグの読み取りツール（experiment-get、experiment-list、feature-flag-get-definition、feature-flag-get-all）を使用します。フェーズ 1 のチェックに SQL クエリは必要ありません。

使用モード

クイックチェック（単一のエンティティ）

ユーザーが特定の実験またはフラグについて尋ねた場合：

1. experiment-get（実験 ID）または feature-flag-get-definition（数値のフラグ ID）を使って、エンティティを取得します。
2. 実験のチェックまたはフラグのチェックから、該当するチェックを適用します。
3. 結果を重大度別に（CRITICAL、WARNING、INFO の順に）グループ化し、インラインの Markdown で報告します。
4. エンティティへのリンクを [Experiment: name](/experiments/id) または [Flag: key](/feature_flags/id) の形式で含めます。

スコープを絞った監査（単一ドメイン）

ユーザーがすべての実験またはすべてのフラグの監査を依頼した場合：

1. experiment-list または feature-flag-get-all を使って一括取得します。
2. 各エンティティに対して、そのドメインのすべてのチェックを実行します。
3. 結果を重大度別、次にエンティティ別にグループ化します。
4. インラインの Markdown で報告します。

全体監査（包括的）

ユーザーが実験とフラグの両方について包括的な監査を依頼した場合：

1. experiment-list を使ってすべての実験を取得し、feature-flag-get-all を使ってすべてのフラグを取得します。
2. すべての実験チェックとすべてのフラグチェックを実行します。
3. 繰り返し見られるパターンを適用し、複数の結果にまたがるパターンを特定します。
4. 結果のあるエンティティが 5 件を超える場合は、確認しやすいようノートブックに記録します。それ以外の場合はインラインで報告します。プロジェクト独自のノートブックツールを使ってノートブックを作成します。search notebooks?- を実行してノートブックを読み込み、タイトルを確認します。

出力形式

各結果には、以下を含めます。

• 重大度バッジ：🔴 CRITICAL、🟡 WARNING、または 🔵 INFO
• チェック名：この結果を検出したチェック
• エンティティリンク：エンティティへの Markdown リンク
• 問題点：問題を 1 文で説明
• 対応策：問題への対処方法（修正アクションを参照）

例：

🟡 WARNING — フラグ連携 · Experiment: checkout-redesign リンク先のフィーチャーフラグは無効（停止中）です。トラフィックは分割されていません。 対応策：フラグを再度有効にするか、実験を終了します。

データを取得できない場合の対応

一部のチェックではアクティビティログ（フラグの場合は feature-flags-activity-retrieve）が必要ですが、すべてのセッションで利用できるとは限りません。 アクティビティログのデータを利用できない場合：

• checkActivityHistory（実験チェック）は完全にスキップします。
• フラグのライフサイクルチェックでは、「切り替えの不安定性」と「一度も有効化されていない」のサブチェックをスキップします。
• レポートには、スキップしたチェックとその理由を記載します。

  スキップ：アクティビティ履歴チェック（現在のツールではアクティビティログを利用できません）

一部の処理に失敗した場合

一部のエンティティで取得呼び出しが失敗した場合：

• 取得できたエンティティについては、処理を続行します。
• 評価できなかったエンティティとその理由を報告します。
• エンティティを監査結果から黙って除外しないでください。

参照ファイル

• 実験のチェック — 実験設定のチェック
• フラグのチェック — フィーチャーフラグのチェック
• 結果の種類 — 重大度とカテゴリの定義
• 繰り返し見られるパターン — 複数の結果にまたがるパターン
• 修正アクション — 各結果への対処方法