AIが自分で直した5件のバグ：全選択ボタンとSession Stateの罠

1. 手動テストでは気づけないバグの正体

社内ツールを Streamlit で作った人なら、一度はこういう経験があるはずです。ボタンを押したのに画面が変わらない。もう一度押すと変わる。再現条件がはっきりしないので「たまに変」で放置される。

この記事で扱う5件のバグは、まさにその種類です。BOOTHで販売している「完全ローカルAI業務アシスタント構築キット」の2本目のプロンプト（E2Eテスト自動化・自動バグ修正）を実行したとき、Claude Code がテストの途中で検出し、原因を特定し、app.py を修正して、8項目中8項目PASS・失敗0で完了するまで回した記録が残っています。

5件のうち4件は、Streamlit の「key 付きウィジェット」と「Session State」の二重管理に関係しています。この記事では、テストレポートの「自動修正したバグ一覧」をもとに、何が起きていて、どう直したのかを順に見ていきます。証跡（動画・スクショ・レポート）の全体像は別記事 {T1} を参照してください。

2. 自動修正されたバグ5件の一覧

テストレポートに記録された5件は次の通りです。すべて対象ファイルは app.py です。

3. バグ①：「全選択」「全解除」が効かない

いちばんわかりやすいのが1件目です。社内資料の一覧にはファイルごとにチェックボックスがあり、チェックを入れた資料だけがAIの検索対象になります。「全選択」「全解除」ボタンはそれを一括で切り替えるためのものです。

ところがテストを実行すると、ボタンを押してもチェックが切り替わらず、参照件数の表示も変わりませんでした。テストのシナリオ3は「全解除で全件OFF、参照件数0」「全選択で全件ON、参照件数5」を確認する項目なので、ここで検知されます。

原因は Streamlit の仕様にあります。st.checkbox(..., key="doc_xxx", value=True) のように key と value の両方を渡すと、Streamlit は保存されている Session State の値を value 引数より優先します。元のコードは「選択集合」を更新していましたが、チェックボックス本体の保存値（st.session_state['doc_xxx']）を書き換えていなかったため、再描画時に古いチェック状態が復元され、直後の処理で選択が元に巻き戻されていました。

修正は、一括操作のときに選択集合と一緒に st.session_state['doc_<doc_key>'] も書き換えることです。修正後の再テストで、全解除で0件、全選択で5件、個別チェックで5→4件と連動することが確認されています。

4. バグ②：登録成功と同時に警告が消える

2件目は、見落とすと業務上の事故につながる種類です。正常な資料と旧Office形式（中身が旧形式の .xlsx など）をまとめて登録すると、旧形式は「新形式で保存し直して再登録してください」という案内を出して読み飛ばす設計になっています。

ところが登録成功時に st.rerun() を呼んで画面を再描画するため、直前に描画した st.warning が破棄されていました。利用者から見ると、「5件登録しました」の成功メッセージだけが出て、1件が取り込まれていないことに気づけません。

修正は、メッセージを st.session_state['ingest_notices'] に退避し、再描画後にアップローダーの直下で表示する関数を追加することでした。テストのシナリオ4で、成功メッセージと旧形式の案内が同時に表示されることを確認しています。

5. バグ③：プロンプトを選び直しても入力欄が変わらない

3件目は実務プロンプト（テンプレート）の機能です。サイドバーの一覧からタイトルをクリックすると本文が入力欄に展開される仕組みで、別のテンプレートを続けて選び直すと、入力欄が1件目のまま切り替わらないという事象でした。意図しない指示文を送ってしまう危険があります。

原因は1件目と同じ構造です。入力欄が key="prompt_draft_area" 付きの st.text_area で、Streamlit は保存値を value 引数より優先します。修正は、テンプレート適用時に prompt_draft だけでなく st.session_state['prompt_draft_area'] も同時に入れ替えることでした。シナリオ5で、2つのテンプレートを続けて適用し、入力欄が正しく切り替わることを確認しています。

6. バグ④⑤：画面は動くのにログが肥大化する二重管理

4件目と5件目は、画面上は正常に動くのに、サーバーログに次の警告がスタックトレース付きで記録され続けるというものです。

The widget with key "doc_..." was created with a default value but also had its value set via the Session State API

1件目と3件目の修正で Session State を直接書き換えるようにした結果、「value 引数」と「Session State」の二重管理になり、Streamlit が警告を出すようになっていました。資料の登録件数が増えるほどログが肥大化し、本当の障害調査の妨げになります。

修正は、value 引数を廃止して Session State を唯一の状態として扱い、キーが未登録のときだけ初期値を入れる方式に変えることです。あわせて、資料を削除したときに st.session_state.pop('doc_<doc_key>') で状態を破棄し、同じ資料を削除してから再登録したときに古いチェック状態が残る問題も解消しています。プロンプト入力欄も同じ方式に統一し、「送信」「破棄」のときに状態を破棄するようにしました。

つまり Claude Code は、最初のバグを直したことで生じた副作用（警告の二重管理）まで検出し、設計を一段きれいな形に揃え直したことになります。

7. Claude Codeはどうやって直したのか

プロンプトには「テスト実行中に例外、UI要素の未検出、Streamlit のエラー画面を検知した場合、Claude Code 自身が該当コードの原因箇所を特定して修正し、テストが全件パスするまで再実行すること」と書かれています。実際の流れは次の通りです。

1. テストスクリプト（test_automation_runner.py）が、画面の状態と DB の状態を突き合わせて不一致を検知する（例: 全解除後の参照件数が0でない）
2. Claude Code が app.py の該当箇所を読み、Streamlit の仕様（保存値が value 引数より優先される）に照らして原因を特定する
3. コードを修正し、テストを再実行する
4. 修正によって新たに出た警告（4件目・5件目）も検知し、再度修正する
5. 8項目すべてが PASS になった時点で、修正内容をレポートの「自動修正したバグ一覧」に記録する

人がやると「再現しない」「ログを見ていない」で止まりがちな工程を、テストの判定条件と再実行のループで機械的に進めているのがポイントです。

8. AIに任せるときの注意点

自動修正は便利ですが、無条件に信用するものではありません。キットの 使い方.md と商品ページにも書かれている通り、生成されたコードやテストコードの完全性は保証されません。実運用に乗せる前に、次の3点は人が確認してください。

• 修正の差分を読む。レポートの「修正内容」欄は、そのままレビューの観点になります
• テストの判定条件が妥当か見る。判定が甘いと、通ってはいけないものが通ります
• 修正によって別の機能が壊れていないか、全シナリオの再実行結果で確認する

この記事の5件は、いずれも「判定条件が明確」で「再実行で確認できる」ものだったため、自動修正が機能しました。曖昧な仕様のバグは、先に仕様を決めてからテストに落とす必要があります。

9. まとめとキットの入手先

• 手動テストで気づきにくい5件のバグを、Claude Code がE2Eテストの実行中に検出・修正し、8項目中8項目PASSで完了した
• 4件は Streamlit の key 付きウィジェットと Session State の二重管理が原因で、修正後は Session State を唯一の状態として扱う設計に揃っている
• 修正の記録はテストレポートに表として残り、そのままレビュー資料になる

修正後の「出典付き社内資料検索」がどう動くかは {U1} で、証跡の全体像は {T1} で解説しています。キットの全体像は総合解説記事をご覧ください。

→ 総合解説記事: {LP_URL}

この記事で引用したテストレポートの実物（修正したバグ5件の詳細を含む取扱説明書 ドキュメント/AI回答.md）は、キットに同梱されています。価格 ¥49,800（税込・買い切り）、購入企業内は人数無制限、商用利用可、人的サポートなしです。

→ BOOTH 商品ページ:https://ai-beginner-navi.booth.pm/items/8937710