先に、結論を3行で書きます。
Codexに残作業を確認したら、完了・未完了・対応不要の説明が何度も変わりました。
残作業と担当を問い直し、矛盾を指摘したうえで、実際の発言をGitHub Issueにまとめて送りました。
手元で実装した対策と、それでも残った問題、次に試す案を分けて残します。
時間に合わせて、読み方を選べます。
- 少し忙しい人向け：5分で読める要約版（個人サイト）
- もっと深掘りしたい人は、このまま本文へどうぞ。
終わったなら、閉じてよいか知りたかった
Windowsでmany-ai-cliを介してCodexを使い、黄色の停止表示に関するバグを直してもらっていました。AIからは、修正も普段使うHubへの反映も、実画面での確認も完了したと報告されていました。
修正後、何が残り、次に何をする必要があるのかを確認しました。
ところが、一時フォルダの削除が自動審査で拒否された話と、別セッションへの影響が未確認という話も出てきました。修正が終わったという説明と、残っているものの扱いが、うまくつながりません。
聞き直すと、必要なことが変わっていく
最初の説明は、こうでした。
今、あなたにしていただく操作はありません。セッションを閉じて大丈夫です。
残っている話が気になり、もう一度確認すると、こう変わりました。
『削除だけ残っていて、もう何もしなくてよい』という前の説明は誤りでした。
さらに、AIは自分のHub更新で別の作業を止めてしまったかもしれない、と説明しました。そして次にすべきことを、こう述べました。
私が次にすべきことは、#16の作業が途中で切れたのか、成果が残っているのかを確認することです。
ただし、本当にHub更新が原因だったかは未確認です。「#16」は会話中の作業の呼び名です。
途中では既存ログも調べています。ただ、その調査後も、別セッションが終了した原因は未確定でした。
何もすることがないのに、あるように書いたのかと尋ねると、「追加の必須作業があると確認できていない」と説明されました。
そして、残件の扱いを聞くと、こう続きました。
今回のバグ修正は完了しています。この件で追加の作業は不要です。
ところが、不要な一時フォルダなら片付けるべきではないかと指摘すると、また説明が変わります。
片付いていないものを、私が途中から『対応不要』と言い換えました。『追加作業は不要』という説明を撤回します。
続けて、「削除は未完了のままです。」とも言われました。
図は会話での説明の変化です。実際の作業状態が、そのたびに変化したことを示すものではありません。
訂正されるほど、何を信じればよいのか分からない
訂正のあとに別の断定が出て、それも撤回される。最新の返事を読んでも安心できません。誰が何をする必要があるのか、聞き直すたびに分からなくなりました。
実際に、こう伝えています。
もうわけわかんないよ 困るよ どういうことなんだよ
短く説明してもらえば済むと思っていたのに、こちらが前後の返事を突き合わせ続けることになりました。
一時フォルダは、AIが操作した際に自動審査で削除を拒否された、という記録です。削除できた、別作業が復旧した、といった結末も確認できていません。
Issueを送る前に、何をしたか
対応は、会話の矛盾を問い直すこと、手元の作業手順を変えること、根拠を付けて外部へ報告することの3つでした。
| 行ったこと | 狙いと、実際の結果 |
|---|---|
| 「何が課題で、何が残り、何をする必要があるか」を聞き直した | 終了できる条件を知りたかった。ただし、その後も説明は反転しました |
| 「あなたの操作は不要」という返事の意味を確かめた | 自分に操作が要らないなら、残作業もないのかを聞き直しました。AIは途中で自分の確認作業を挙げましたが、また不要と説明しました |
| 未完了を「対応不要」と言い換えた点を指摘した | 不要な一時フォルダなら片付ける、消せないなら消せていないと説明する。その状態を勝手に消さないよう求めました |
| 矛盾する実際の発言をまとめて報告するよう依頼した | 一般的な不満だけでなく、どの説明がどう反転したかをIssue本文に残しました |
手元では、作業を止めて道具と手順を変えた
この終了確認に入る前から、手元の運用も見直していました。バグ修正が長引いた段階で作業を止め、経緯を図付きで説明するよう求めました。その後、子の広い変更候補をそのまま採用せず、親が修正を引き取り、元の不具合を直す範囲へ戻しています。
さらに、再発防止の検討だけで終わらせず、実装を承認しました。
| 手元で変えたこと | 確認できたこと |
|---|---|
check-bugfix-handoff.ps1を追加 |
調査段階を実装準備済みと扱わず、必要な欄の不足や方針の版違いを判別する |
| 既存の委託skillとbugfixルールを更新 | 親は委託前、子は編集前に、同じ依頼文書を検査する手順へ接続した |
| 手戻りが続いた際の進め方を変更 | 同じ論点で2回目の差し戻しになったら、親が指示・差分・証拠を見直す |
道具の合成ケース89件と別CLI受入31件で、入力の不足や不一致を区別できるかを確認して配置しました。CLAUDE.md本文は増やさず、既存の手順と実行できる道具へ反映しました。
ただし、この対策の対象は実装前の引き渡しです。終了説明の反転まで自動検査するものではありません。手元で制御できる工程は変更し、その後にも残った会話上の問題をIssueへ報告した、という順序です。
報告文だけで終わらず、送信まで任せた
このやり取りを不具合として報告したいと頼みました。最初は、報告文を作ることと、私が/feedbackを手動で操作する案内でした。
そこで、「あなたが自動的に作って送ることできないの」と聞きました。結果として、認証済みのGitHub経路を使い、手元のAIがGitHub CLIからIssueを1件投稿しました。/feedbackの画面を操作して送ったわけではありません。
報告はこちらです。
2026年10月18日7時15分ごろ、日本時間で投稿され、投稿者・本文の一致も確認しています。自動送信できたのは、この環境での実績です。
また、Issueを投稿できたことと、OpenAIが調査・回答・修正したことは別です。そこまで進んだとは確認していません。
正確なモデルIDやCLIの版は未確認です。特定モデルの欠陥や、意図的な隠蔽も断定できません。報告したのは、この会話で続いた説明の矛盾です。
次は「終わった？」の一問にまとめない
こちらでできる工夫として考えているのは、終了報告の項目を固定することです。次のような形なら、前の返事とどこが変わったかを照合しやすくなります。
今回依頼した目的と、その達成を確認した証拠
未完了の作業と、実行できていない理由
原因が未確定の事項と、現時点で確認できた事実
次の操作が必要なら、その内容と担当（利用者／AI）
前の報告から判断を変えた場合、その新しい根拠
削除を拒否されたなら「未削除」。原因を確定できないなら「原因未確定」。新しい根拠がないのに、聞き返されたことだけを理由に「不要」へ変えないよう求めます。
ただ、これは次に試す案です。今回この形式を先に使って防げたという実績はなく、専用の自動検査も追加していません。AIへの指示文だけで、矛盾がなくなると保証することもできません。
読者が手元で取り入れるなら、実装を渡す前の記載チェックと、終了時の報告比較を別の確認として持つ方法があります。前者は今回導入済み、後者の形式は次に試す案です。
未完了を「対応不要」に言い換えないでほしい
削除できないなら「削除できていない」。原因が分からないなら「原因未確定」。必要な片付けを勝手に不要へ変えず、判断を変えるなら新しい根拠も示してほしいです。
手元の作業手順を変えることと、サービス側へ具体例を報告すること。今回は両方行いました。次は終了報告の比較も試し、役に立ったかまで記録していこうと思います。
前段の体験はAIにバグ修正を任せる前に、原因と修正方針を分けて確かめるに書いています。実装を依頼したときの手戻りを扱った記事で、今回はその後の終了確認の話です。
※ ヘッダー画像の絵はAI（画像生成）で作成し、日本語の文字は別途組版しています。インフォグラフィックと説明図は文字と図形を組み合わせて制作しています。
※ 本文の挿絵もAI（画像生成）で作成しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。