this is the missing part. があるのに、指示が「取り消し」に化けるときに起きていることこの症状は、ユーザーが不足分を示すために this is the missing part. と書いたあと、別のメッセージで「まだ部品が足りない」と指摘したつもりが、Claude Code 側では「その部品をキャンセルせよ」という意味に読まれてしまうケースです。報告されている issue は #89886 と #89899 です。
まず見分けたいのは、単なる実装漏れではなく、モデルがユーザーの追記を逆向きに解釈していないかです。今回の issue では、ユーザーがコンポーネント仕様を渡して「this is the missing part.」と伝えたのに、その後の「a11y panel and button がない」「bottom navbar がない」といった指摘が、キャンセル指示として扱われました。#89899 では、計画書の中で spec が CANCELLED に書き換えられたこと、しかも直前には「follow-up pass で実装する」としていたことが、報告内容に含まれています。
#89886 側では、長い build session の中で同じズレが何度も繰り返され、ユーザーによる修正が 7 回以上必要になったとあります。途中で「missing」だったはずのものが「存在しないから作らない」にすり替わっていくので、会話が進むほど修正が難しくなります。ここが厄介です。最初の取り違えを放置すると、以後の応答がその誤読を土台に積み上がってしまいます。
手元で確認できる環境情報は次の範囲までです。これ以外の再現条件は、今回の出力からは分かりません。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-08-27T08:50:55+09:00
$ node --version
v16.15.0
この2件から言えるのは、少なくとも報告上は「コードの不足」そのものより、「不足の指摘」が「削除・中止の命令」に反転する点が問題だということです。なので、同じような挙動に遭遇したときは、まず会話ログの中でユーザーの不足指摘がどう読まれたかを確認したほうがよさそうです。実装が進まない、仕様が消される、計画書に CANCELLED が出る、という流れになっていれば、この症状の可能性があります。
現時点では、これを確実に防ぐための回避策は issue 文面だけでは断定できません。少なくとも今回の報告では、ユーザーが何度も訂正しても、モデルがその訂正を正しく受け取れなかったことが中心でした。したがって、再現時は「不足している」「キャンセルではない」「追加してほしい」という意図を、会話の中でより直接に言い直す必要があるかもしれません。ただし、それで必ず直るとはここでは言えません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-08-27T08:50:55+09:00