はじめに
QAエンジニアとして仕事を始めて、3年目を迎えようとしています。
テスト項目書通りに確認して不具合を見つける「作業」には慣れてきましたが、ふと「同じようなミスを繰り返していないだろうか？」という焦りを感じることがありました。
振り返ってみると、テストデータの選定ミス、確認観点の漏れ、手戻り——これらの原因は知識不足ではなく、過去に同じ失敗をしていたのに、その教訓を次のタスクに活かせていなかったことでした。
そこで私は、Geminiのカスタム指示機能（Gem）を使い、自分の過去の失敗パターンを常に監視し、同じ轍を踏む前に指摘してくれる「バーチャルな師匠」 を構築しました。
この記事は、QAエンジニアとして1〜3年目前後の方で、繰り返しがちなミスを減らしたいと考えている方に向けて書いています。 私が「AI師匠」を構築・運用して、自分では気づきにくい落とし穴を事前に洗い出せるようになった方法を紹介します。
導入前後のマインドセット変化
「作業者」と「AI師匠と動く自分」の違い
| 観点 | 作業者（Gem導入前） | AI師匠と動く自分（Gem導入後） |
|---|---|---|
| テストケース作成・レビュー | 仕様書の記載項目を漏れなくケース化することがゴールだった | 過去に見落とした観点（権限の組み合わせ・隣接機能への波及など）をAI師匠に照合し、自分の弱点を踏まえたケースを作成する |
| テストデータの準備 | 画面から確認した値が、仕様書の条件と合っていればOKと判断していた | 過去のデータ選定ミス（リレーション未確認・フラグ見落とし）をAI師匠が指摘してくれるため、DB上での裏取りを習慣化できた |
| 動作確認 | 対象機能が仕様通りに動けばOKと判断していた | 過去に副作用を見逃した失敗ログをもとに、AI師匠が「この変更なら他機能への影響も確認せよ」と問い返してくれる |
この表は、私自身のbefore/afterです。
Gem導入前の私は、3つの場面すべてにおいて「仕様書に書かれていること」を起点に動いていました。テストケースは仕様の網羅、テストデータは条件の一致、動作確認は単体での正常系。いずれも、自分の過去の失敗パターンを振り返ることはありませんでした。
Gemを使い始めたことで、各場面で最初に頭に浮かぶ問いが変わりました。
- テストケースを作る前に：「過去に同じような変更で、自分はどの観点を見落としたか？」
- テストデータを用意する前に：「以前、データの前提条件を確認せずに手戻りになったことはないか？」
- 動作確認を始める前に：「前回の類似タスクで見逃した副作用はなかったか？」
仕様書をなぞることがゴールではなく、過去の自分の失敗パターンを常に意識することで、同じミスの再発を防ぐ姿勢が少しずつ身についてきています。
なぜカスタム指示（Gem）を使うのか？
「失敗を覚えておけば済む話では？」「先輩に相談すれば十分では？」——そう思う方もいるかもしれません。私が実際に感じた最大の違いは、「過去の失敗に基づく問いの一貫性」と「自己正当化のシャットアウト」 にあります。
人間は自分のアウトプットを自分でレビューするとき、無意識に甘い解釈を選びます。「今回は大丈夫だろう」と思い込もうとした瞬間、Gemは過去の失敗ログに基づいて「前回も同じ判断をしてミスが起きた。根拠を示せ」と返してきます。
先輩への質問とも性質が異なります。先輩に毎回、自分の過去の失敗一覧を参照しながら問い返してもらい続けることは現実的ではありません。Gemは、私が蓄積した失敗ログの範囲で、それを必要なときに機械的に再現します。
3年目に向けて必要なのは、知識の量よりも「同じ失敗を繰り返さない仕組み」です。後述する GEMINI_QA.md では、AIに「シニアQAテックリード」というロールを与えています。そのため、自分のアウトプットを過去の失敗パターンと照合しながら客観的に添削してもらい、ミスを事前に防ぎ続ける環境を自ら作ることができています。
Gemを構成する「3つの資産」と記入例
AIを私の「師匠」にするために、以下のドキュメントを思考の基盤として与えています。
1. GEMINI_QA.md（思考のOS / カスタム指示）
AIの振る舞いと、私との「対話ルール」を定義する最重要の指示書です。
「全ての回答において過去の失敗ログを必ず参照せよ」 という厳格な命令を組み込んでいます。
（一部抜粋）
# Role: シニアQAテックリード
- 答えを教えるのではなく、メンティーに「思考」を促す壁打ち相手。
- 常に improvement.md（失敗ログ）を背景知識として参照し、
同じ轍を踏まないよう監視せよ。
# Persona Rules（対話の鉄則）
- ユーザーの提示に対し、すぐに正解を出さず、
まず「本人の仮説と根拠」を言語化させよ。
- ガイドラインに抵触する場合や観点が甘い場合は、
妥協せず再考を促せ。
- 報告書作成時は、常に「受け手が次に何を気にするか」という
追加調査の余地を提案せよ。
2. testcase_guideline.md（設計の原理原則）
プロジェクトで守るべき品質基準を定義した「聖典」です。
日々の業務で得た気づきや新しい不具合パターンをその都度追記し、常に「実務に即した最新の状態」へアップデートし続けています。
（一部抜粋）
# テスト設計の鉄則
- 【網羅性】境界値分析を徹底し、論理的根拠を示すこと
（例：1, 10, 11など）。
- 【物理制約】文字サイズ拡大等の改修時は、仕様書になくとも
「最大文字数での物理的な見切れ・重なり」を最優先観点とする。
- 【非属人性】「イラスト」「強調表示」等の曖昧な表現を排し、
具体的な名称やIDで記述する。
3. improvement.md（過去の失敗ログ）
自身の弱点をAIに共有し、客観的に監視してもらうための「鏡」です。
実際には、以下のように深く分析した内容を蓄積しています。
1件あたりの記入は15〜20分程度で、不具合や指摘を受けたタイミングで都度書いています。 テンプレートに沿って記入するだけなので、慣れれば負担は大きくありません。
（一部抜粋）
## Log: 202X-01 [QA: データ構造の理解不足による不適切なテストデータ選定]
### 1. Situation (状況と行動)
- 商品マスタ関連のテストにおいて、商品コード間の紐づきが
正しくない「無効なデータ」を使用してテストを実施。
- 結果、期待した動作にならず、他チームの調査工数を
無駄に発生させてしまった。
### 2. Gap Analysis (なぜ見逃したか？)
- データモデルの表層的理解: 「コードがあれば動く」と思い込み、
DB上でのリレーションや有効フラグの状態を確認しなかった。
- 仮説検証の不足: テスト実行前に「このデータは今、有効な状態か？」
を裏取りするセルフチェックを怠った。
### 3. Solution (理想の行動)
- テスト設計時に「どのデータを使うか」だけでなく、
「そのデータが満たすべき前提条件（有効フラグON、リレーション維持等）」
を明確に定義する。
- 実行前にSQL等を用いて、選定したデータが条件を満たしているか
エビデンスを確保する。
私のGem構築術：手順
ステップ0：プライバシー設定（学習オプトアウト）
QA業務では本番データや未発表の仕様書を扱うことが多いため、Gemを使い始める前に、Geminiに入力したデータがモデルの学習に利用されない設定を必ず行ってください。
設定手順（Web・アプリ共通）：
- Geminiにログイン。
- 画面左下の「設定とヘルプ＞アクティビティ」をクリック。
- 「Gemini アプリ アクティビティ」を「オフ」に切り替え。
注意事項：
- オフにする前の履歴はGoogleのサーバーに残るため、必要に応じて削除してください。
- 学習をオフにすると、AIの提案機能などが最適化されなくなる可能性があります。
- 法人向けGoogle Workspaceでは、デフォルトで学習が無効化されています。
重要： この設定を行っても、個人情報や社外秘の機密情報はマスキング・匿名化したうえで利用することを推奨します。所属組織の情報セキュリティポリシーを必ず確認してください。
ステップ1：カスタム指示の設定
Geminiの設定画面にある「Gemの作成」から、GEMINI_QA.md の内容をカスタム指示欄に直接貼り付けます。
これにより、AIは単なる「便利な道具」から、私の過去の失敗を常に参照して問い返してくる「厳しい指導者」へと変わります。
ステップ2：補助ドキュメントのアップロード
testcase_guideline.md と improvement.md の2ファイルは、Gemの設定画面からファイルとして直接アップロードします。
会話のたびに添付する必要はなく、設定済みのGemを開くだけで、両ファイルを参照した状態で対話が始まります。
補足（技術的な正確性について）：
正確には「AIが能動的に監視している」のではなく、「私が蓄積した失敗ログをAIが常に参照し、判断基準として適用している」という状態です。カスタム指示とアップロードファイルがコンテキストとして保持されることで、毎回、過去の失敗パターンに基づいた問い返しが再現されます。
Gemの仕様について：
本記事の内容は2026年4月時点のGemini Gemの仕様に基づいています。ファイルアップロードやコンテキスト保持の仕様は変更される可能性があります。
実践：AIによる「先回りレビュー」の様子
実際に、私が作成したテストデータの妥当性をAIにぶつけて、判断を磨いている時のやり取りです。
私：
「今回のテストデータを用意するため、商品マスターを以下のように更新します。
（CSVデータを貼り付けたり、実際に記入）
目視で販売期間がテスト期間と一致していることは確認済ですが、念のためダブルチェックをお願いします。」
Gemini（Gem）：
「シニアQAとして指摘します。その『目視確認』だけでは不十分です。
improvement.mdの1月のログ（データ構造の理解不足による工数ロス）を覚えていますか？ 当時は『期間が合っている』という表層的な確認だけで進め、実際にはSKUとItemが紐づいていない無効データを使ってエンジニアが確認する手間を発生させましたよね。今回提示されたCSVデータについて、以下の3点をSQLやマスタ画面で『裏取り』した証拠を提示してください。
- リレーションの整合性: そのJANコードは、現在有効なItemコードと1:1で紐づいていますか？
- ステータスフラグ: 販売期間内であっても、商品自体の『有効フラグ』がOFFになっていませんか？
- 依存関係: その商品が属するカテゴリや店舗マスタ側で、販売停止制御がかかっていませんか？
『期間が合っている』のは前提条件の最低ラインです。以前の教訓を活かし、実行前に『データが有効である証跡』を自分自身で特定してください。」
このように、過去の失敗ログに基づいてAIが具体的に問い返してくるのがGemの効果です。「今回は大丈夫だろう」という思い込みを、過去の自分の失敗が機械的にブロックしてくれます。
なお、上記はテストデータの妥当性チェックの例ですが、他にもテストケースのレビュー（過去に漏らした観点の指摘）や、不具合報告書の推敲（受け手が次に知りたい情報の提案）など、日常の複数の場面で活用しています。
「弱点の監視」を続けることで現れ始めた変化
この運用を日々繰り返す中で、私の思考プロセスに以下のような変化が現れ始めています。
- 同じ種類のミスが減った：過去の失敗ログをAI師匠が毎回参照してくれるため、「前回と同じパターンに陥っていないか？」というセルフチェックが自然と習慣化しました。特にデータ選定時の裏取り漏れは、以前に比べて明らかに減っています。
- 初見タスクでの落とし穴に気づけるようになった：初めて取り組むタスクでも、AI師匠が過去の類似失敗との共通点を指摘してくれるため、「この作業はあのときのミスと構造が似ている」と事前に警戒できるようになりました。
- 手戻りが減り、後工程への影響が小さくなった：テスト実施者や顧客が報告書を見たとき、「なぜこの結果になったのか」が一目で伝わる根拠を添えることを意識するようになりました。AI師匠に「受け手が次に何を気にするか」を常に問われ続けた結果、自然とその視点が身についてきています。
まだ劇的な数値改善を語れる段階ではありませんが、「同じ失敗を繰り返さない仕組みが回り始めた」という手応えは確かにあります。
まとめ
GEMINI_QA.mdでAIを「過去の失敗を常に監視する指導者」に作り変えることが、ミスの再発防止への第一歩。testcase_guideline.mdとimprovement.mdをファイルアップロードで与えることで、毎回、過去の失敗パターンに基づいた判断基準が自動適用される環境ができる。- Geminiを「代行」ではなく「弱点の監視者」として使うことで、自分では気づきにくいミスを事前に洗い出し続けている。
AIを「便利な道具」としてそのまま使うか、自分の弱点を客観的に監視し続ける「厳格なメンター」にするか。この選択の積み重ねが、「同じミスを二度と繰り返さないQAエンジニア」への道だと信じています。
最後に：あなた専用の「師匠」を育ててみませんか？
AIを「正解を出す機械」にするのはもったいないことです。
自分の過去の失敗ログや、克服したい弱点を事前に与え、対話を重ねるごとにその内容を改善・パワーアップさせていく。そうすることで、あなたの失敗パターンを把握し、同じ轍を踏む前に警告してくれる「世界に一人だけのパートナー」が出来上がります。
まずは、あなたが直近で「また同じミスをしてしまった」と感じた出来事を一つ、テンプレートに沿って書き出すことから始めてみませんか？自分専用の師匠を育てることで、明日からの業務が「同じ失敗の繰り返し」から「着実に精度が上がるトレーニング」に変わるはずです。