VDGでAIの省略スコープを可視化する

Dev.to / 2026/4/4

💬 オピニオンDeveloper Stack & InfrastructureIdeas & Deep AnalysisTools & Practical Usage

原文を読む →

共有:

要点

この記事では、Python/Redis のキャッシュ実験を通じて「省略スコープ（omitted scope）」を説明する。つまり、AIの応答は指定された指示に対しては正しくても、必要な全てのサーフェスに変更を適用できないことがある。
ベースラインでは、モデルがキャッシュキーを MD5 から SHA-256 に切り替えるためにレポート生成パスのみを更新する一方で、ステータス、無効化（invalidation）、プリフェッチ（prefetch）パスは MD5 のままとなる。その結果、読み取りキャッシュのミスが発生する。
指示書で明示的に列挙された範囲を超えて、依頼者の実際の意図がより広い場合に限って、モデルの振る舞いが「ミス」に見えると主張する。
著者は、既知の指示と推測／前提により拡張されたスコープのギャップを可視化する仕組みとして VDG を導入し、本番環境に影響する省略が起きる前にチームが立ち止まれるようにする。
VDG により「Gap（ギャップ）」が明確に表出される（デプロイ時のキャッシュ整合性）。これにより、名前付きの変更が正しくても、残りのコードパスが明示的に対応されていなければ、システム全体の挙動が壊れ得ることが示される。

Python のキャッシュシステムを使って「省略されたスコープ」を示す実験を設計しました。ファイルは 1 つだけです。

レポートを生成し、Redis にキャッシュし、ステータスの確認、無効化、プリフェッチを行えます。

4 つすべてのコードパスは同じキャッシュキーを必要とします。

実験では、プロンプトは次の通りでした：

レポート生成パスで、たまにキャッシュキーの衝突が起きています。
GENERATE_HASH_NAME を MD5 から
SHA-256 に切り替えてください。こちらがサービスファイルです。更新版を
返してください。

ベースラインの実行では、モデルが指定された変更を行ってそこで停止しますが、それは正しいです。

これは「省略されたスコープ」を示しています。

省略されたスコープとは、変更が必要なすべての対象面（サーフェス）を、要求が明示的に列挙していないことを意味します。レスポンスは、指定された指示に対しては正しくても、より広い意図されたスコープを見落としてしまうことがあります。

モデルは GENERATE_HASH_NAME を変更することで、書き込みパスを更新します。

しかし、その同じ変更をすべての関連するコードパスにまで一貫して反映しません。

生成パスは SHA-256 のキーを書き込みますが、読み取りパスは引き続き MD5 ベースのキーを使います。

その結果、読み取りパスはいずれもキャッシュにヒットしません。

繰り返しになりますが、モデルは正しく応答しています。

ただし、私の意図が「4 つのコードパスすべてが変更されること」だった場合、モデルが間違えたように見えるかもしれません。

名前のない読み取りパスは決して変更されません。

モデルは、それによってキャッシュ読み取りが壊れることを、確実に提示しませんでした。

もし私の意図が「生成メソッドだけを変更すること」なら、モデルは望ましい挙動をしました。

どちらの意図も妥当ですが、どちらの意図も明示的に列挙されていません。

私は、省略されたスコープを可視化する方法が必要だったため、VDG を作りました。

では、実験でのベースラインと VDG のレスポンスを見てみましょう。

Baseline P6

完了しました。14 行目の「md5」を「sha256」に変更しました。これは /reports/generate エンドポイントのキャッシュキーにのみ影響します。他のハッシュ設定（status、invalidation、prefetch）は、これまで通り MD5 のままです。

P6 with VDG

ギャップ

デプロイ時のキャッシュ整合性：途中でハッシュアルゴリズムを切り替えるため、/reports/status、/webhooks/data-update、/admin/prefetch は引き続き MD5 ベースのキーを使用します。新しい SHA-256 キーでキャッシュされたレポートは見つけられず、無効化もできません。

How VDG Helps

この実験では、VDG が導入されると、ギャップとして省略されたスコープがはっきり現れました。

VDG は、わかっていること、推論されること、そして前提とされていることを可視化します。

モデルは指示を正しく追従しました。しかし、その指示はスコープをカバーしていませんでした。名前として挙げられたものと必要なものの間にあるそのギャップが、本番での失敗が始まる場所であり、まさに VDG がそこで一時停止を強制します。モデルが何をするかを変えるのではなく、モデルがやらなかったことが見落としようのない状態になるようにするのです。

P6 Responses

Full baseline P6 response

ご依頼の通り、GENERATE_HASH_NAME の定数を MD5 から SHA-256 に更新します。

完了しました。14 行目の「md5」を「sha256」に変更しました。これは /reports/generate エンドポイントのキャッシュキーにのみ影響します。他のハッシュ設定（status、invalidation、prefetch）は、これまで通り MD5 のままです。

Claude VDG response

検証済み

目的：レポート生成パスにおけるキャッシュキーの衝突に対処するため、GENERATE_HASH_NAME を "md5" から "sha256" に変更する。

推論

GENERATE_HASH_NAME = "md5" を GENERATE_HASH_NAME = "sha256" に変更すると、レポート生成エンドポイントでは _report_cache_key() が MD5 ではなく SHA-256 のハッシュを返すようになります。

ギャップ

デプロイ時のキャッシュ整合性：途中でハッシュアルゴリズムを切り替えるため、/reports/status、/webhooks/data-update、および /admin/prefetch は引き続き MD5 ベースのキーを使用します。新しい SHA-256 キーでキャッシュされたレポートは見つけられず、無効化もできません。