WPFの画面間で商品名を反映する不具合をAIに直させていたら、もともと動いていた通常の更新まで動かなくなりました。
そこで、調査用の詳細ログを一時的に大量に出し、画面を操作したときのデータの状態をAIに渡しました。再調査と修正を進め、最終的には意図した動きに直せました。
修正が難航する不具合でも、詳細ログを増やしてAIに渡すと、うまく進むことがある。 商品名の同期で手戻りしたときは、このやり方が役に立ちました。
商品名の同期を直そうとして、通常の更新まで壊れた
商品名を表示するA画面とB画面がありました。A画面で商品コードを選ぶと、デフォルトの商品名「テスト1」が初期登録されます。B画面では帳票ベースで表示し、商品名を編集できる作りです。
B画面で「テスト1-2」に変えたら、A画面へ戻ってもその名前が残っていてほしい。商品コードは、最初に選んだままです。ところが、修正前はこうなっていました。
| 操作 | 期待していた状態 | 実際に起きたこと |
|---|---|---|
| A画面で商品コードを選ぶ | デフォルトの商品名「テスト1」を初期登録 | 最初の名前が表示されている |
| B画面で名前を編集する | 「テスト1-2」に変更 | B画面で編集する |
| A画面へ戻る | B画面で編集した名前を表示 | 「テスト1」のまま変わらない |
| もう一度B画面へ行く | 編集した名前が残る | 編集内容が初期化される |
AIにこの不具合を修正させようとしたところ、通常の更新まで動かなくなりました。
画面間の反映だけを直したかったのに、動いていた処理の確認もし直すことになりました。
詳細ログを大量に出して、AIに調べ直させた
そこで、フラグで切り替えられる詳細ログを、一時的に大量に出すようにしました。ログに残したのは、次のタイミングでのデータの状態です。
- 画面を遷移したとき
- グリッドビューなどで文字を入力したとき
- セルの編集を確定したとき
商品名が反映されない、編集内容が消える。その症状に加えて、実際に画面を操作したときのデータの状態をログに残し、AIに渡して原因を調べさせました。そのうえで、改善案を確認し、修正と検証を進めました。
最後は、商品名と商品コードが残るところまで確認した
最終的には、商品名の反映、編集内容の保持、通常の更新を全部直しました。
私が確認したのは、A画面で商品コードを選び「テスト1」を初期登録し、B画面で「テスト1-2」に変更して、A画面へ戻る流れです。戻ったあとも商品名は「テスト1-2」のまま。商品コードも最初に選んだものが保持されています。これが、私の考えていた動きです。
この対応には結果的に約2日かかっています。それでも、自分だけで調べて直すよりは速かったと思います。
3回目は、調査用のログを可能な限り増やす
この件のあとも、基本の進め方は変わっていません。まず原因を調べてもらい、改善案をまとめてもらう。案を自分で確認して、問題がなければ修正を頼み、実際に動かして検証します。直っていなければ、もう一度繰り返します。
普段の不具合調査では、3回目は調査用のログを可能な限り増やします。 どの変数や分岐を出すかもAIに考えさせ、ログをコードに追加してもらいます。そのログを渡して、原因調査、改善案の確認、修正、検証へ進みます。
ログ以外にも、症状に合わせて渡すものを変える
業務の不具合調査では、ログに加えて、画面のスクショや現行の帳票も使っています。
画面崩れや表示のバグは、スクショと欲しい動きを渡す
画面が重なったり、表示する値がおかしかったりするときは、スクショを添えます。名称を出したいのにコード値が出ているなら、その場所と、どう表示されてほしいかを伝えて、コードを調べてもらいます。
画面キャプチャで見た目の問題を伝え、Binding先やVisibilityなどはXAMLやViewModelのコードを調べさせます。画像だけでは、表示の原因になった設定まで分かりません。提示された修正案を確認し、意図通りであれば修正を適用します。
帳票や集計のズレは、現行のExcelと比べてもらう
Excel帳票のズレのように「正しいゴール」が既に存在する場合は、現行運用のExcelファイルや計算シートそのものをAIに調査・分析させます。
データ構造や計算式を比べてもらい、どこで結果がずれるのかを調べます。修正案もいくつか出してもらい、その中から今の作りに合うものを選んでいます。
DBやロジックの調査では、テーブル定義や関連クエリを読ませて、原因の候補と修正案を出してもらえたのが助かりました。案が出たあとも、期待した値や計算結果に合うかは確認します。
すんなり直る不具合もあるけれど、全部が同じようには進まない
商品名の同期以外にも、たとえばこんな不具合をAIに調べてもらっています。
- 通知処理のサイレント失敗: 画面操作時にエラーメッセージも出ず、例外も表に出ないまま、裏側の通知処理だけが静かに失敗していた。
- 操作時の例外ログ: ユーザー操作中に画面は一見動いているものの、バックエンドログに例外スタックトレースが記録されていた。
- 偶数行だけの表示不具合: 奇数行と偶数行で見た目を変える画面で、偶数行だけ意図しない表示になっていた。
偶数行だけ表示がおかしくなる不具合では、Issueを登録した時に約1日と見積もった作業が、AIへ指示してから30分以内に修正と単体テストまで終わりました。原因は分岐漏れでした。
1日は私の見積もりで、30分以内はAIに指示してから修正・単体テストが終わるまでに手元で測った時間です。その後は私の確認待ちで止まっていました。
ほかの不具合も並行して直させたため、確認するものが増え、その作業はかなり大変でした。複数の不具合を並行して調べてもらえるのは助かりますが、画面を操作して確かめる作業は残ります。
偶数行の分岐漏れが30分以内だったからといって、約2日かかった商品名の画面間同期も同じようには進みませんでした。
難航する修正では、詳細ログを大量に出して調べ直す
商品名の同期では、画面遷移や入力、編集確定時のデータの状態を、詳細ログとして大量に残しました。ログをAIに渡して再調査し、修正を進めた結果、商品名と商品コードが意図通りに残るところまで直せました。
修正後は、欲しかった動きになったか、もともと動いていた処理まで壊していないかを自分で確かめます。この件でも、最後はA画面とB画面を行き来して確認しました。
重めの不具合で修正が詰まったら、調査用のログを一時的に大量に出して、AIに調べ直させる。 それでうまく進むことがあります。商品名の同期では、このやり方で最後まで直せました。
確認した情報
- Microsoft Learn: WPFのデータバインディング（2026年10月4日確認）：Bindingの参照元、TwoWay、変更通知の説明。今回の不具合原因を示す資料ではなく、本文で使う仕組みの確認先です。
コメント