> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.
# フラグ変更の承認
> フィーチャーフラグ変更の制御と監査のために、本番反映前のリクエスト＆レビューワークフローを実装します。
フラグ変更の承認を有効にすると、フィーチャーフラグの編集にリクエスト＆レビューの仕組みが導入されます。チームメンバーは変更をリクエストでき、指定された承認者がそれらのリクエストをレビューし、有効になる前に承認または却下できます。
フラグの承認により、フラグに適用される変更をより細かく制御できます。承認設定を構成すると、特定のユーザーによるフラグ変更はリクエスト＆レビュープロセスを経て、承認された変更だけがエンドユーザーに届きます。
## プロジェクトで承認を有効化する
承認を構成できるのは **Admin** 権限を持つユーザーのみです。フラグ承認を有効にするには、次の手順を実行します。
1. 左サイドバーで **Features** > **Flags & Experiments** をクリックします。
2. **Settings** タブをクリックし、**Approval settings** を選択します。
3. ドロップダウンから、フラグ承認を有効化するプロジェクトを選択します。
4. リクエストをレビューできるユーザーを選択し、**Save** をクリックします。
本番環境でのみ承認をトリガーするオプションを選択した場合、Kameleoon はキーが `production` の環境にのみワークフローを適用します。ただし、変数・バリエーション・ゴールの更新など、間接的に本番環境に影響を与える変更も承認ワークフローをトリガーします。
承認は環境、インテグレーション、またはフラグのトグルを制御しません。フラグの状態（オン/オフ）を変更できるのは **Production** 権限を持つユーザーのみです。
## フラグ変更の承認をリクエストする
プロジェクトで承認を有効にすると、レビュアー以外のユーザーが変更を保存する際に承認リクエストのポップアップが表示されます。リクエストのタイトルをカスタマイズし、承認者が閲覧できるコメントを追加できます。
リクエスト者は、セットアップや環境の異なるセクションをまたいで複数の変更を一括で行い、送信できます。Kameleoon は承認者に保留中のリクエストを通知し、提案された変更をレビューできるようにします。
すべての承認リクエストは **Review** セクションで確認できます。**Pending** 状態のリクエストを個別に取り下げるには、該当のリクエストをクリックし、**Withdraw request** をクリックします。
## 変更リクエストを承認する
メインダッシュボードでは、承認者は各フラグのレビュー状況の概要を確認できます。
* **Pending**: フラグに少なくとも1件の保留中リクエストがあります。
* **Reviewed**: すべてのリクエストが承認または却下済みです。
レビューステージにカーソルを合わせると、追加情報が表示されます。
フィーチャーフラグを編集する際、レビュアーは **Review** セクションに移動してすべてのリクエストを確認できます。リクエストをクリックすると、提案された変更内容やコメントを含む詳細を表示できます。リクエストは次の4つの状態のいずれかになります。
* **Pending**: レビュー待ち。
* **Approved**: 変更が承認され適用されました。
* **Rejected**: 変更が却下されました。
* **Invalid**: より新しい変更が適用されたため、リクエストされた変更がもはや適用できません。Kameleoon はこのリクエストをデフォルトで却下します。
各リクエストに対して、承認者は提案された変更を承認または却下できます。Kameleoon はそれに応じて関連する変更を適用または破棄します。
承認者は上から下への順序（新しいリクエストが先）でのみリクエストをレビューできます。
## FAQ
いいえ。承認を有効にした後、プロジェクト内のすべてのフラグは承認ワークフローを通過する必要があります。プロセスが厳しすぎる場合は、承認者リストの見直しを検討してください。
Kameleoon は却下されたリクエストを破棄しますが、リクエスト者はいつでも変更を再送信できます。
新しいリクエストを先にレビューするプロセスにより、無効になったリクエストはフラグ付けされて無視されるため、データ競合のリスクは排除されます。