AIに作らせたツールを社内に配るとき、いちばん怖いのは「動いているように見えるだけ」の状態です。
この記事では、ローカルAI構築キットに同梱したE2Eテスト自動化プロンプトが実際に出力したレポートをもとに、7シナリオ・79件の検証チェックが何を確かめ、どんな証跡（フルHD動画・赤枠スクリーンショット・SQLite直接照合）を残すのかを解説します。
1. 「動いているように見える」を終わらせたい
Claude Codeのようなコーディングエージェントにアプリを作らせると、驚くほど短時間で「それらしいもの」が出てきます。問題はその後です。社内や研究室に配るなら、誰かが全機能を触って確認しなければなりません。人がやると抜けるし、UIを直すたびにやり直しです。
そこでキットでは、テストもAIに書かせ、失敗したらAIに直させ、証跡付きのレポートまで出させるプロンプトを同梱しました。この記事は、そのプロンプトが実際に出力したテストレポートの中身を紹介するものです。
2. テスト対象：ローカルAIワークステーションの7つの機能
テスト対象は、キットのプロンプト1本目で構築されるStreamlit製アプリです。Ollama、ChromaDB、faster-whisperを使い、資料検索（RAG）、Word/Excel/PowerPoint/BibTeX出力、音声議事録をすべてPC内で処理します。
テストシナリオはプロンプト側で7つ指定しています。
| No | テスト | チェック数 |
|---|---|---|
| 1 | アプリ起動とセキュリティ確認 | 10 |
| 2 | プロジェクト作成・管理 | 14 |
| 3 | 多形式資料のアップロードとRAG絞り込み | 14 |
| 4 | プロンプト管理（CRUD） | 12 |
| 5 | チャット対話と出典表示 | 11 |
| 6 | 高付加価値エクスポート | 8 |
| 7 | 音声議事録タブ | 10 |
合計79件。すべてPASSでした。使用モデルは gemma3:4b、画面解像度は1920×1080、対象はサンドボックスDBで起動した localhost:8501 です。
3. レポートの冒頭だけで分かる全体像
生成されたレポートは、冒頭に総合評価（PASS / FAIL）、総テスト数、成功数、自動修正されたバグ数を置き、その直下に7行のサマリー表が来る構成です。管理職や発注側がレポートの1画面目だけ見て判断できるように、プロンプトでこの構成を指定しています。
今回の結果は「総合評価 PASS、7 / 7 シナリオ成功、検証チェック 79 / 79、自動修正されたバグ 6件」でした。6件のバグの中身は次の記事で扱います。
4. 証跡の設計：動画・赤枠スクショ・DB直接照合
主張ではなく証跡を出す、がこのプロンプトの方針です。レポートには3種類の証跡が付きます。
操作動画（.webm、1920×1080） テスト全体を1本の動画として録画します。人が目で追える速さになるよう、各入力・クリックの間に1〜1.8秒の待機を入れ、テキストは1文字ずつ打つ演出にしています。
赤枠付きスクリーンショット（PNG / JPG 両形式） 操作対象の要素に outline: 3px solid #FF0000 を一時的に付けてから撮影し、撮影後に外します。今回のレポートでは37枚、起動確認からチャットタブへの復帰まで連番で並びます。
SQLiteへの直接照合 画面の見た目だけでなく、プロジェクト作成・プロンプト追加・削除のたびに app_data.db を直接SELECTして「DBに本当に入ったか・消えたか」を確認しています。見た目は更新されているのにDBは古いまま、という典型的なバグをこれで捕まえます。
5. 本番データを汚さないサンドボックス実行
テストランナーは、アプリ一式を一時フォルダへコピーし、空のDBで別ポートに起動してから操作します。普段使っている app_data.db と chroma_db/ には触れません。
テストで読み込ませる資料も、ランナー自身が生成する架空データです。今回は「架空_都市交通シミュレーション論文.pdf」「架空_量子センサー実験レポート.txt」「架空_海洋微生物サンプル一覧.csv」「架空_研究室ミーティングノート.md」の4形式と、架空のゼミ録音（wav）でした。
実在の論文や人物は一切使っていないので、スクリーンショットをそのまま社内資料やブログに載せられます。
6. 特に重要なテスト1：セキュリティ確認の10項目
ローカルAIを名乗る以上、ここが一番大事です。テスト1は次の10項目を確認しています。
localhost:8501で正常に表示される- ヘルスチェック
/_stcore/healthが200を返す - Deployボタンが非表示（DOM上0件）
- 標準メニューが非表示（DOM上0件）
- ツールバーが非表示（DOM上0件）
- ヘッダーが非表示（表示0件）
- 「Deploy」の文字が画面に出ない
- ダークモード背景色
#0E1117が適用されている - LAN側IPからは接続できない（127.0.0.1限定バインド）
- 画面に例外・エラー表示がない
LAN側IPの項目は、テストランナーが自分のLANアドレスを調べ、そのIPの8501番へ実際に接続を試みて「失敗すること」を確認しています。設定ファイルを読んで安心するのではなく、外から叩いて閉まっていることを確かめる、という考え方です。
7. プロンプトはどこまで指定しているか
テスト自動化プロンプトは、ざっくり次のことを指示しています。
- 既存の製品コードとテスト専用コードを分離し、テストランナーは別ファイルで作ること
- 例外、UI要素の未検出、StreamlitのTraceback表示を検知したら、該当コードを修正して全テストが通るまで再実行すること（自動バグ修正ループ）
- 出力フォルダ構成（screenshots / video / test_data / レポート.md）と、レポートの見出し構成
- 動画の解像度、待機時間、タイピング演出、赤枠の付け方といった証跡の品質要件
- 7つのテストシナリオと、そこで必ず確認する項目（全選択・全解除でチェックボックスが実際に切り替わるか、など）
逆に、どのセレクタを使うか、どう待機するかといった実装は指定していません。そこはClaude Codeに任せ、人は「何を確かめるか」だけを書く分担です。
8. 自分の環境で同じレポートを出すには
キットには、このプロンプトで生成されたテストランナー本体も参照用コードとして入っています。参照用コードの環境にPlaywrightとPillowを追加してOllamaを起動し、次を実行するだけです。
.venv\Scripts\python.exe test_automation_runner.py
.venv\Scripts\python.exe test_automation_runner.py --headed --model gemma3:4b
テスト結果_日時/ フォルダに、レポート・動画・スクリーンショット・テストデータが揃います。自分で作り変えたアプリに対しては、プロンプトの「検証すべきテストシナリオ」を書き換えてClaude Codeに再生成させてください。
9. まとめと次の記事
- 7シナリオ・79チェックを全自動で実行し、動画・赤枠スクショ・DB照合の証跡が残る
- セキュリティ確認は設定の確認ではなく、LANから実際に接続を試みて閉まっていることを検証している
- 本番データは触らない。読み込む資料は架空データ
次の記事では、このテストが自動修正した6件のバグを1つずつ見ていきます。Streamlitでツールを作る人なら、同じ罠を踏んでいる可能性が高い内容です。
コメント