強いAIでも制約抽出とゲート化に失敗する

Posted: 2026-05-24

何が起きたか

AI agent に、自宅検証環境の復旧と設計相談を任せていた。

使っていたのは GPT 5.5 xhigh の coding agent で安定してた。それでも、既存ドキュメントに残っていた重要な制約を、計画上の制約として扱いきれなかった。

具体的には、ある Windows app installer を Wine / container / Kubernetes volume 上で動かす検証で、install destination が local disk として見える必要があった。

Linux 側では path が見えており、Kubernetes volume として mount でき、read/write もできる。しかし app 側はそれだけでは通さない。Windows API 的に remote filesystem と判定されると installer が止まる(NFS上にストレージを置くとエラーになる)。 # TF_VAR_xpra_basic_auth_htpasswd: ‘kaoru:$2y$05$replace_with_htpasswd_output_after_changeme’

Wine / Windows app の文脈では、たとえば GetDriveType("C:\\") が DRIVE_FIXED なのか DRIVE_REMOTE なのかが効く場合がある。

この制約は過去ログや既存メモに残っていた。しかし AI agent は、復旧計画を立てる時点でそれを制約事項に昇格できなかった。

推論力不足ではなく制約抽出の失敗

この失敗は、単純な推論力不足とは少し違う。

AI は関連ログを読めば、NFS-backed path が local disk と見なされず installer が失敗したことを説明できた。つまり、後から問われれば正しく整理できる。

問題は、その情報を計画立案の前に取り出し、「この gate を通さない限り次へ進めない」という形に変換できなかったことにある。

言い換えると、失敗したのは次の処理である。

過去ログ / docs
  -> 現在も有効な制約の抽出
  -> hard / operational / preference への分類
  -> 実行前 gate への変換
  -> 計画への反映

強いモデルでも、長い会話、複数のドキュメント、過去の成功エビデンス、現在見えている症状が混ざると、制約を「注意点」として読むだけで終わることがある。

今回の環境では、2026-05-24 時点で repository 内の docs/**/*.md は wc -l で 26,059 行あった。

内訳としては、docs/operation が約 14,000 行、docs/troubleshooting が約 5,700 行、docs/system が約 1,600 行だった。これは人間にとっても AI agent にとっても、毎回すべてを精読する前提にはしにくい量である。

そのため、長い docs を否定するのではなく、そこから現在も有効な制約を抽出し、短い contract と gate へ昇格する必要がある。 (ai-context.md, memory.mdというファイルを設け、そのファイル自身に行数の目安を設けて、溢れるようであれば自動的にdocs配下にファイルを作って良い運用にしました)

なぜ落ちるのか

今回の失敗には、いくつかの要因があった。

直近の症状に引っ張られる

表面上の症状は、registry が存在しない、containerd cache で Pod が起動している、prefix が見つからない、というものだった。

そのため、調査と計画は registry、cache、prefix 復旧、node-local state の方向に寄った。

しかし installer が通るかどうかは、それより前段の storage semantics の問題だった。

docs にあることと gate 化されていることは違う

ドキュメントに「NFS では失敗した」と書いてあっても、それだけでは実行時の事故は防げない。

計画時に必要なのは、次のような形である。

constraint:
  Wine C: / install destination は local disk として見えなければならない

reason:
  installer が remote filesystem を拒否する

gate:
  GetDriveType(C:) が DRIVE_FIXED
  drive_c の実 filesystem が NFS/CIFS ではない
  installer log が check install path correct end まで進む

この形になっていない制約は、長い作業の途中で抜け落ちやすい。

成功済み状態が認知を曇らせる

既存 Pod が起動している、過去に成功 evidence がある、という状態は「構成はだいたい正しい」と見えやすい。

しかしその起動が local cache や過去に生成済みの state に依存している場合、fresh install の再現性は証明されていない。

AI agent は現在の成功状態を説明できても、「cache が無い状態で同じことができるか」「state を消しても再生成できるか」を gate にしないと、再現性を過大評価する。

gate にするとは何か

ここでいう gate は、単なる注意書きではない。

作業を次に進める前に、必ず確認する条件である。

たとえば次のように書く。

constraint	reason	gate
installer destination must be local disk	app が remote filesystem を拒否する	`GetDriveType(C:) == DRIVE_FIXED`
NFS-backed path は runtime data root にしない	lock、rename、fsync、filesystem type 判定で失敗し得る	`stat -f -c %T`, `findmnt`, app-specific probe
registry が必要	local containerd cache が成功を偽装する	cache 無し pull、image digest 確認
state は再生成可能にする	drift や壊れた状態を持ち越さない	fresh install job、fresh prefix、起動確認

重要なのは、gate が command、log、API probe、artifact で確認できることだ。

「気をつける」では弱い。「この log line が出るまで進めない」「この API がこの値を返すまで成功扱いにしない」まで落とす。

今回入れた対策

今回の対応では、上位の system contract を作った。

目的は、すべての経緯を 1 ファイルに詰め込むことではない。設計時に落としてはいけない制約だけを、短く、参照可能な形でまとめることである。

形式は次のようにした。

ID
type: hard / operational / preference
constraint
reason
gate
related docs

たとえば、Windows app / Wine / installer の制約は次のような扱いにした。

constraint:
  Wine / Windows app の install destination は DRIVE_FIXED 相当でなければならない

reason:
  installer が NFS-backed drive_c を remote / non-local disk と判定して停止した

gate:
  drive_c 実体の filesystem type を確認する
  Wine 上で GetDriveType("C:\\") が DRIVE_REMOTE でないことを確認する
  installer log の check install path correct end を確認する

また、registry / containerd cache についても、起動していることだけを成功条件にしないようにした。

constraint:
  local containerd image cache で再現性を証明しない

gate:
  registry readiness
  image digest
  fresh node または cache 無し pull
  imagePullPolicy の確認

AI agent への期待を変える

AI に全履歴を完全に記憶させる、という期待は置かない方がよい。

人間も記憶に頼ると落とす。AI agent は特に、会話履歴、圧縮済み context、複数 repository、tool output、過去 docs の間で重要度を誤ることがある。

代わりに、次を期待する。

作業前に system contract を読む。
今回触る constraint ID を列挙する。
hard constraint の gate を先に決める。
operational exception は期間と戻し方を書く。
失敗したら、原因を troubleshooting だけでなく contract に昇格する。

これにより、AI の推論力に頼る範囲を狭められる。

一般化した運用パターン

この事象は、AI agent に限らず、人間の運用でも起きる。

過去ログに原因がある。設計メモにも注意点がある。しかし作業計画には入っていない。

この状態では、知識は存在していても運用には効いていない。

効かせるには、次の形にする。

knowledge
  -> constraint
  -> gate
  -> preflight
  -> acceptance criteria

特に、次のような領域では gate 化が効く。

filesystem / storage semantics
installer / DB / container runtime
network path / VPN / firewall
hardware-attached workload
cache が成功を偽装する処理
reboot 後に消える state と残る state が混ざる構成

まとめ

強い AI でも、既存ドキュメントにある制約を計画上の gate に昇格できないことがある。

これは「モデルが何も分からなかった」というより、「知っている情報を実行前制約として使えなかった」失敗である。

対策は、より長いプロンプトを毎回書くことだけではない。

制約を system contract として外部化し、作業前に constraint ID と gate を列挙する。

AI agent の推論力を信頼する場合でも、最終的には確認可能な gate に落とした方がよい。