AI 設定 Drift Detection

packet_id: MANUAL-EA290-DRAIN-20261022-C1 revision_id: EA-290-RESEARCH-20261022-R1 status: RESEARCH_CANDIDATE / PRE_BRIDGE_AUDIT 確認日: 2026-10-22 JST

AI構成ドリフト検知は、承認された構成と、保存されている設定および実際の処理に適用された構成の差を検出する運用である。Gitの設定ファイルが変わっていなくても、環境変数、個人設定、管理ポリシー、モデル別名、参照データ、実行時の上書きによって処理条件が変わることがある。そのため、ファイルの変更監視だけでAIシステムの構成が一定だと証明することはできない。

本稿では、承認済みの期待値、保存された設定、要求ごとの実効設定を区別する。さらに、固定した評価条件に対する挙動の変化を別の観測として扱う。構成の差分は原因候補となるが、回答品質が変わったという報告だけでは、提供者の内部設定が変わったことまで証明できない。検知結果には、差分の有無だけでなく、どこまで観測できたかを付ける必要がある。

AWS CloudFormation資料[S1]では、ドリフト検知には対象資源とプロパティの制限があり、明示されていない既定値は比較対象にならず、親スタックの検知だけで入れ子の全スタックが検査されるわけでもない。この製品固有の制約は、基盤の検知成功をAIアプリケーション全体の構成一致と読み替えてはいけない具体例である。

Claude Codeの公式設定資料[S2]は、複数の設定スコープと優先順位、実際に読み込まれた設定を確認する考え方を説明している。ここから本稿は、設定ファイルの存在確認と実効値の確認を分ける必要性を導く。全AI製品が同じ優先順位で設定を解決するとは主張しない。

既存Explorerが参照したGitHub issue #57618[S3]は、投稿者がClaude Code 2.1.138で、あるウィンドウのeffort変更が別ウィンドウに影響すると報告したものである。今回GitHub APIで本文と状態を取得した。報告は設定スコープの衝突を考える具体例になるが、当方による再現結果ではない。issueがclosedであることだけから、修正バージョンや現行環境での解消を断定しない。

もう一つのissue #24991[S4]は、同じモデル識別子で挙動が変化したと投稿者が主張する報告である。投稿者の自己評価を一般的な性能指標として採用せず、バックエンド変更という推測も確定事実へ昇格させない。「観測した出力の変化」と「設定変更を裏付ける証拠」が別であることを示す資料として扱う。

実務上はモデル名一つでは基準が粗すぎる。本稿の設計提案では、モデル識別情報、API経路、SDKとアダプターの版、プロンプトの版、ツール定義、権限、検索索引の版、参照データの識別情報、実行フラグ、環境設定を、処理条件を説明する組として記録する。すべてを一つの巨大な文字列にする必要はなく、責任者と変更頻度に合わせて分割し、要求IDから各版へたどれるようにする。

秘密の値を記録する必要はない。秘密の参照先、版、権限境界の識別子を記録し、変更の検知に必要な情報と秘匿性を両立させる。秘密そのものの単純なハッシュを共有ログへ出すと、値の候補が少ない場合などに推測を助けることがある。保存する指紋の対象と閲覧権限も設計する。

基準には承認者、適用対象、適用開始時刻、例外の有効期限、直前の基準を付ける。最新の実態を自動的に基準へコピーすると、未承認変更を検知した直後に正常扱いしてしまう。実態の収集と基準の昇格は別操作にし、意図した変更であることを確認した後にのみ基準を更新する。

収集点は、デプロイ時、起動時、設定変更時、重要な要求の実行時、定期確認時に分ける。設定が起動時に固定される製品ではファイルの更新が既存プロセスへ反映されないことがあり、動的に読み直す製品では同じプロセス内でも実効値が変わり得る。どの時点の値を取得したかを時刻と実行主体に結び付ける。

比較前には、型を維持した正規化、意味を持たないキー順の統一、環境固有で承認済みの差の扱いを定める。ただし、配列の順序や権限ルールの優先順位など、意味を持つ順序まで並べ替えてはならない。比較対象を減らす除外ルールには理由と有効期限を持たせる。除外が増え続けると、検知が成功していても重要な変更を見落とす。

判定は、承認済みの計画変更、未承認差分、事故対応中の一時差分、観測不能に分ける。取得失敗や対象外を「差分なし」にしない。観測不能の対象、最終成功時刻、検知できない範囲を明示し、制御上重要な項目であれば新規処理を止めるなどの運用判断につなげる。すべての不明点で全停止するかどうかは、対象操作のリスクと可用性要件で決める。

二つの作業セッションが同じユーザー設定を参照していると仮定する。セッションAの操作が共有設定を書き換え、セッションBが次の要求でその値を読む設計なら、Bの作業者が操作していなくても条件が変わる。この仮定を確かめるには、操作前後の共有設定、各セッションの実効値、変更時刻、要求IDを比較する。利用量が増えたという印象だけでは、設定伝播の経路は特定できない。

対策候補は、設定のスコープを明示する、作業ごとの設定を分離する、起動時の実効値を記録する、変更時に影響するセッションを通知する、といったものになる。ただし、issue本文の回避策を現行製品の公式仕様として無検証で展開しない。現行の公式資料と対象バージョンで、優先順位と反映タイミングを確認する。アプリケーションの版、OS、管理ポリシーが違えば結果も異なり得る。

設定差分が見つからないのに品質が変わった場合は、構成が完全に同一だったと即断しない。提供者内部の観測できない条件、入力分布、参照データ、会話状態、非決定性、評価手順を候補として残す。同時に、観測できない提供者変更を原因と決めつけない。まず固定した入力と評価基準で、影響するタスク、再現頻度、エラー、遅延、出力形式を記録する。

設定指紋と挙動評価を同じ要求群に結び付けると、「版Xで評価が悪化した」という相関を調査できる。ただし、同時に複数の要素が変わっていれば一つへ因果を帰属させられない。切り分け用の検証環境で変更要素を減らし、結果と限界を残す。サンプル数や入力条件が違う自己評価を横に並べて、提供者全体の劣化率としない。

ツール権限が広がった、監視が無効化された、未承認の送信先が増えた、といった差分では、対象操作の停止や隔離を優先することがある。単なる表示設定の差と同じ優先度にしない。通知には対象、基準、実測、最初の検知時刻、関連変更、業務影響、担当者を付け、対応できる情報量に絞る。

差分検知をそのまま自動巻き戻しへ接続するのは危険である。直前の基準に脆弱な設定が含まれる場合や、事故対応で意図的に防御を追加した場合、復元が被害を増やす。復元可能な設定、実行条件、承認要件、失敗時の停止条件を定義し、データ削除や外部送信のような取り消せない副作用を設定の巻き戻しと混同しない。

検証では、承認済み変更、未承認変更、共有設定の変更、古いプロセスの残存、取得権限不足、検知対象外、緊急変更をそれぞれ作り、期待する判定になるかを確認する。差分の検出だけでなく、観測不能が正常扱いされないこと、通知から対象要求へたどれること、基準更新が承認を要求することを受入条件にする。

管理指標には観測可能な対象の割合、重要差分の検知遅延、未解決時間、誤通知、例外期限超過を使える。分母を「登録した対象」だけにすると未登録依存が見えないため、資産棚卸しとの突合も必要になる。検知件数がゼロであること単独では統制の有効性を示さない。

• 対象システムの設定優先順位、実効値取得方法、基準一覧、提供者内部の変更は未確認である。
• issue #57618の現行再現性と修正リリース、#24991の原因・評価の一般性はUNKNOWN。公開報告を自ら確認した不具合や性能測定と書かない。
• 本RUNの設定変更注入、並行セッション再現、実効値収集、挙動評価、自動復元の試験はすべてNOT_RUN。
• SAFE_WORDINGは「観測可能な設定差分を検知し、挙動変化の原因調査に結び付ける」。設定一致だけで同一出力を保証する、挙動変化だけで秘密の設定変更を証明する、と表現しない。
• 本文は独立監査待ちの調査候補であり、製品障害認定や公開採用の完了ではない。

[S1] AWS CloudFormation, Detect unmanaged configuration changes to stacks and resources with drift detection, https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html 。2026-10-22 JST確認。明示的なプロパティ、入れ子、対応範囲の節。

[S2] Claude Code Docs, Settings files and precedence, https://code.claude.com/docs/en/settings 。同日確認。設定スコープ、優先順位、読み込まれた設定確認の節。

[S3] anthropics/claude-code issue #57618, https://github.com/anthropics/claude-code/issues/57618 。同日GitHub REST APIから本文・状態取得。2026-05-09作成、2026-06-07 closed。投稿者の環境はClaude Code 2.1.138。SRC-EVID-000091、EVIDENCE_SOURCE_MASTER行92に対応。

[S4] anthropics/claude-code issue #24991, https://github.com/anthropics/claude-code/issues/24991 。同日公開本文確認。2026-02-11の利用者報告、closed as not planned。SRC-EVID-000092、同台帳行93に対応。

既存WORK_UNIT_CLAIMSのWORK-EXPLORER-SRC0091-0092-20261016-R179は、構成変化と挙動変化を切り分ける調査来歴として再利用した。今回の再取得をもって、既存の証拠グラフ全体の未確認欄を一括で確定扱いにはしていない。

旧退避文書1Vd0BP7G2UyPDRQs_-8dPvTgQ78Tk6kcVGuMJjqNdr84、2026-09-18 11:20 JST RUN、tab t.0:23385–25569内EA-290、原案t.0:49161、ARTIFACT_INDEX行266は所在監査の来歴である。完成調査が見つかったという記録ではなく、今回の完成本文とは区別する。