QAによるハーネスエンジニアリングと QA組織の未来像 — 暗黙知を「AIが破れないルール」にして組織に渡す 西田泰明 株式会社TOKIUM QA 2021年 BearTail（現TOKIUM）に一人目QAとして入社し、QA組織を立ち上げ 

— TOKIUMのプロダクトとテストの難しさ ⽀出管理クラウド(SaaS) 経費精算 契約管理 電⼦帳簿保存 テストの難しさ 1 プロダクト間連携 連携が多く、1つの修正の 影響範囲が広く複雑 インボイス 請求書発⾏ 経理AIエージェント 相互連携 2 ⾦額計算 経理業務のため、1円の ミスも許されない AI経費承認 AI請求照合 AIヘルプデスク AI明細⼊⼒ AI新リース判定 3 会計データの形式 会社ごとに形式が違い、どれで テストするか選びきれない 2 

— 今日の話 1. ハーネスで何を実現したかったか 2. 5か⽉回して⾒えた課題 3. 棚卸しをして分かったこと。修正するか作り直すか ハーネスエンジニア リングの話 4. その先でQAは何をする⼈になるのか QAエンジニアの 未来の話 3 

— 出発点は今年の3月 テスト対象プロダクト 14。QA チーム 2〜3 が、1 チームあたり 3〜4 プロダクトを担当 P1 P2 P3 P4 QA チームA（4プロダクト） P5 P6 P7 P8 P9 P10 P11 QA チームB（4プロダクト） QA チームC（3プロダクト） QA⼯程はすべて⼿動。テスト依頼をリリース単位で受け付ける ヒアリング テスト設計 テスト実⾏ 不具合報告 再テスト P12 P13 14 兼務・都度対応 ヘルプセンター 作成 Claude Code 等でコーディングが速くなり、リリース前に QA で停滞する懸念が⼤きくなった → QA ⼯程を⾃動化する要求が、以前の⽐ではないレベルで⾼まった 1 ハーネスで何を実現したかったか 4 

— 設計フェーズと実行フェーズ 設計フェーズ ヒアリング テスト設計 実⾏フェーズ テスト実⾏ 不具合報告 再テスト ヘルプセンター 作成 Claude Code で設計フェーズ・実⾏フェーズ双⽅を代替するツールを作成 → 50% を完⾛できた 1 ハーネスで何を実現したかったか 5 

— ハーネスとは何か ナレッジ 人の頭の中にある判断基準を、AIが毎回同じ ように読める形にしたもの 検証 ルールを「知っている」から「破れない」に する。ここが要点 実行環境 上の2つが読み込まれない実行は、ハーネス が無いのと同じ プロンプトエンジニアリング＝「AIに何を聞 くか」 ハーネスエンジニアリング＝「AIをどういう 環境で走らせるか」 1 ハーネスで何を実現したかったか ① ナレッジ（判断基準） 観点・記述ルール・ドメイン知識を AIが毎回同じように読める形に 参照させる AI（Claude Code） テストを設計・実⾏する 違反はブロックして 成果物 差し戻し ② 検証（Hook群） 成果物がルールに従うかを 機械判定 合格のみ通過 次フェーズ／テスト実⾏へ ③ 実⾏環境（⼟台） ①②を毎回確実にAIへ読み込ませ ⽣成から実⾏まで⼀貫して回す 6 

— 全体像と実現したかったこと ① インプット 仕様 開発リポ 過去テストケース テスト観点 ② 設計 観点→テストケース AI＋ナレッジで⽣成 ③ 実⾏ まずコードで実⾏ 状態把握できない所だけ AI探索 テストケース資産 実⾏コード資産 ④ 報告 結果・エビデンス 不具合起票 ⑤ ⑤再利⽤: テストケースと実⾏コードを資産化 → 次回は決定論で再実⾏(AIを使わない) テストを回せば回すほど、テスト資産が積み上がる これを使えば、QAメンバー以外でも一定以上の品質でQAを回せるようにしたい 1 ハーネスで何を実現したかったか 7 

— 5か月回した成果 ナレッジベース（4⽉ → 9⽉） テスト資産（4⽉ → 9⽉） ファイル数 17 ⽣成したテストケース 合計サイズ 0.5MB 128 9MB Playwrightのコードになったもの 6,482件 607件（1割弱） ナレッジベース: テスト設計・実⾏時に参照するルールや前提 QA以外にも配り、要望はIssueとPRで取り込んだ Issue 127件・PR 598本（うちテスト資産の供給 100本） このまま活動を継続することで、自動テストで置き換えていけそうだ...... 2 5か月回して見えた課題 8 

しかし 2 5か月回して見えた課題 9 

— 発覚した問題（2件抜粋） ① テストの所要時間が延びている......？ エラーは検知しないが、無駄な寄り道作業が目についた ② Issue・PRが滞留し始めた 9⽉上旬 利⽤者を⼀部拡⼤ 9⽉中旬 修正PRを2本起票 利⽤者を開発者・PdMの 成果物を供給するPRが 17ファイルと15ファイル ⼀部にも広げた 5⽇で7本積まれる レビュー往復 2回と4回 open PR 12本 3週間 閉じられず 1本はコンフリクトで停⽌ 参考: それまでのマージ済みPRは561本、起票からマージまでの中央値は0⽇ 利用者拡大の後、フィードバックが加速。Issue・PRの登録速度がマージ速度を上回る日有り 2 5か月回して見えた課題 10 

— 棚卸しをしてみた もしかすると...... ナレッジベース内でルールの衝突があるかも 陳腐化した無駄な記述や検証があるかも → 調査しよう 「メモリやSkills、Hooks、各種ドキュメントを棚卸しします。ルールの衝突や陳腐化した ナレッジを洗い出してください（＋具体事例）」 3 棚卸しをして分かったこと 11 

— 棚卸しで見つかった問題 ⼀つのルールが複数箇所に散在 ステータス遷移の関数が 3 か所に散在 壊れて無意味になったルールが稼働し続ける 共通ルールと固有ルールが別々に巨⼤化 継ぎ⾜しの結果、1か所直すのに 11 ファイル 直さないといけない事例が発⽣ ⾒た⽬は異常なし。裏では無意味なルールが ずっと動いて、リソースを無駄遣い 呼び出し側も別々に呼び出す 結果が衝突しうる 同じことが別ファイルに書いてある 共通と固有が衝突する場合もある Issue・PRの取り込みを重ねた／ナレッジベースの構造化が不⼗分 → 情報汚染が進んでいる 参照されるルールが散在し、正解を引くことも間違いを引くこともある。全部読むだけで時間がかかる 3 棚卸しをして分かったこと 12 

— 修正するか作り直すか 修正して使い続ける 実運用で見つけた修正の知識がコードに残 る 良い点 旧を止めずに済む 移行の費用が要らない 一つの規則を直すのに10か所触る 悪い点 継ぎ足すたびに要らない情報が混入する 修正PRが供給PRと重なり3週間閉じない ※作り直しを繰り返さないような設計が必要 3 棚卸しをして分かったこと 新しい場所で作り直す（こちらにした） 編集する場所が1つの構造から始められる 継ぎ足しの汚染がない状態から始められる 供給PRとぶつからずに作業できる 文書にもコードの分岐にも無い知識は持ち出せな い 移行・同等性確認・並走の費用は未評価 速いか安いか信頼できるかは未実測 13 

— 作り直しの要件にしたこと ナレッジの誤適用が起きないように、適用範囲と優先順を持たせる 旧: プロダクトBのテストなのに、Aの前提を読んで従う 共通の指⽰ファイル プロダクトAの認証の 起動時に必ず読む 注意ドキュメント リンク プロダクトBのテスト ⾒なくてよいのに読み、 を開始したAI Aの⼿順に従ってしまう どのプロダクトでも、起動時にAの前提がコンテキストに載る 全プロダクトに妥当かを確かめる場所が無かった 3 棚卸しをして分かったこと 新: 知識に適⽤範囲を持たせる（内側が優先） 共通 プロダクト チーム 今回の依頼 このPRだけの条件 ⽭盾したら⽌める／共通化は⼈が判断（実装はこれから） 14 

— 新旧ハーネスの処理フロー 旧: 設計と実⾏が別パッケージ。資産は2つの置き場を事後に突き合わせる ⼊⼒ PR・仕様書 設計（対話セッション） 保存のたびに Hook 12本 橋渡し 選定・事前検査 実⾏（別パッケージ） 静的コード → 探索 結果・不具合起票 ダッシュボード テストケース資産 事後に突合（2系統） Playwrightコード資産 MD・TSV・YAMLの3表現 状態は3関数で更新 新: 1回のQAを1つのジョブとして、1つの遷移表で受付から供給まで進める ⼊⼒ PR・仕様書 受付 条件抽出 設計 観点→ケース 実⾏計画 実⾏と調査 確定 不具合起票 テスト資産はYAML1つに集め、共通の知識には適⽤範囲をつける テストケースとPlaywrightコードの状態を1レコードで持つ 新は、ケースの検証と保存までが実装済み。実⾏と状態遷移はこれから 3 棚卸しをして分かったこと 資産化 供給 検証は1つ 段階の出⼝ と CI から ⼈の判断は 決めた場所で 15 

— しくじりから学んだこと 最初から考慮する条件 1 2 3 4 編集する場所を1つに 適⽤範囲と優先順を ナレッジに期限を 棚卸しの判断ラインを 3 棚卸しをして分かったこと 16 

QA業務をQAエンジニアから奪う話 ↑ここまで ↓ここから QA業務を奪われたQAエンジニアはどうなる？？？ 17 

— QA組織の未来像 LayerX ⾷べログ freee SmartHR メルカリ エムスリー 確認型テスト252件で⽋陥0件 →「検出」から「観測・価値検証」へ 伴⾛停⽌で開発だけで回すチームあり 複雑な機能ではQAが再関与 テスト実⾏⼯数 52%減 ⾃動化率 24%→64% 受け⼊れ条件の作成をAIツール化 PM・エンジニア全員が使う プロダクトQAと横断QAの ⼆層へ 「全員QA」を推進し、QAは 実⾏者から品質の戦略家へ（構想） 確認した範囲では、QAを無くした例は無い。ただし寄せ⽅は会社ごとに分かれる QAを誰でも実行できる状態にする QAエンジニアは戦略策定や仕組み自体の作成を担当し、本当に困難なテストに手を出す存在になる → 具体的に何が残る？ 4 その先でQAは何をする人になるのか 18 

— QAの仕事はどうなるか 代替型 10 AIが代わりに完了 強化型 16 AIが⼈を速くする。⼈の判断が残る 仕様書からのテストケース作成 テスト観点の洗い出し 品質メトリクスの設計 PR差分からの影響範囲特定 リスクベースのテスト戦略設計 開発プロセスへの品質フィードバック ⼿順書どおりの⼿動テスト実⾏ ⾮機能要件のテスト設計 QAチームの育成・マネジメント 回帰テストの実⾏ 探索的テスト リリース判定・リスク判断 テスト結果の合否判定・記録 ユーザビリティ・UX評価 テスト⾃動化フレームワークの設計 バグチケットの起票・転記 バグの根本原因分析 CI/CDパイプラインの設計・運⽤ バグレポートの定型トリアージ バグ偏在分析・傾向分析 AI⾃動化パイプラインの構築 テストスケジュール管理 インシデント対応・振り返り テスト環境の構築・管理 テスト進捗の報告・集計 テストコードの記述 注⼒: 知⾒注⼊（観点・戦略・指標）／OK・NGラインの判定／ハーネス基盤 作業時間の⼤部分を占めていた 当⾯は⼈の仕事 分類は Anthropic Economic Index の指標に基づく（2026年3⽉） 4 その先でQAは何をする人になるのか 19 

— 強化型16項目は、開発工程のどこで関わるか 仕様策定 設計・実装 テスト 観点の洗い出し ⾮機能要件のテスト設計 （開発側の⼯程） 探索的テスト リスクベースの テスト戦略設計 ⾃動テストが回る ユーザビリティ・UX評価 品質メトリクス設計 リリース判定・リスク判断 リリース 運⽤ バグの根本原因分析 バグ偏在分析・傾向分析 インシデント対応・振り返り 開発プロセスへの品質フィードバック ⼯程の外（基盤と組織） テスト⾃動化フレームワークの設計 CI/CDパイプラインの設計・運⽤ AI⾃動化パイプラインの構築 テスト環境の構築・管理 QAチームの育成・マネジメント 強化型 16 項⽬を、開発⼯程のどこで関わるかで置いた。設計・実装の⼯程はハーネスで⾃動テストが回る 上流（何を確かめるか決める）と下流（出してよいか決める）に、⼈の判断が残る 4 その先でQAは何をする人になるのか 20 

— QAエンジニアの進路 今のQA テストを設計し、 実⾏し、報告する 時間の⼤部分は 置き換わる側 道（何をする⼈か） 1 品質戦略・リスク判断・セキュリティ 何をどこまで確かめ、どの⽔準で守るかを決める⼈ 2 ハーネス・⾃動化基盤 テストが⾃動で回るレールを作り直す⼈ 3バグの数字から、次に守る場所を決める⼈ 品質データ 4 チーム埋め込み 開発チームの中で、作る前から品質を⾒る⼈ 5わざと壊しに⾏く⼈ ⾮機能・セキュリティテスト ＋ PdM・エンジニア側へ移る道 「QAを辞める」のではなく、要求する側に⽴つ and more......? 呼び名の例／いちばん要る⼒ Quality Strategist クリティカルシンキング・事業の⽂脈 Harness Engineer テスト⾃動化・API・ガードレール設計 Evaluation Engineer に近い データリテラシー Quality Coach コミュニケーション・ドメイン知識 （⾮機能・セキュリティ領域） 負荷・セキュリティテストの基礎 PdM／エンジニア 品質の数字を要求する側に⽴つ → フィードバックは開発プロセスやハーネスに注入。ハーネスを回す組織と人を育てる 4 その先でQAは何をする人になるのか 21 

— まとめ QA業務をハーネスに乗せ、5か月でテスト資産は積み上がった。一方でナレッジベースの情 報汚染が進み、9月に Issue・PR が滞留した 棚卸しで問題を洗い出し、修正するか作り直すかを比べて作り直しにした。作り直しを繰り 返さないために、編集する場所を1つに・適用範囲と優先順・ナレッジの期限・棚卸しの判 断ライン QAは消えるのか。答えは、消えずに重心が作業から判断へ移る。QAを誰でも実行できる状 態にし、QAエンジニアは戦略・仕組み・困難なテストへ 持ち帰ってほしいのは、自分の仕事を奪う仕組みを作ったら、その仕組みが「正常」と言っ ても信じず、棚卸しして数字で疑うこと 4 その先でQAは何をする人になるのか 22 

もっと知りたい方へ / We're Hiring ハーネスの作り方と展開の落とし穴の全文は、Software Design 2026年10月号 第2特集に（右に表紙）。失敗込 み、再現の手引き付き 今日の棚卸しと作り直しの全文は、Zenn「5か月育てた QAのハーネスを棚卸しして、作り直すと決めた理由」に （右のQRから） TOKIUM QAは、品質と開発生産性に一緒に向き合う仲間 を募集しています。採用ページ（右のQRからも） connpass: yasuaki-nishida ／ X: @ynisQA1988 ご清聴ありがとうございました。 このあとのパネルで、未来 像の続きを Software Design 2026年10⽉号 第2特集 ⼿探りの先に⾒えた QAの未来 技術評論社・9/18 発売 Zenn 最新記事 5か⽉育てたQAの ハーネスを棚卸し して、作り直すと 決めた理由 2026-09-25 公開 We're Hiring 採⽤ページ TOKIUM QA connpass: yasuaki-nishida X: @ynisQA1988 x.com/ynisQA1988 23 

――― 付録 以降は当日は提示しない補足です — 旧ツールと新ツールの対照・資産の持ち出し・見直し条 件・QA業務26項目の分類・出典URL一覧 24 

— 【付録】旧ツールと新ツール — 残したもの・捨てたもの・新に無かったもの 旧ツール 残したもの 設計はセッション内、実行と検証はLLMを呼ばない決定論の処理 課金ゼロの経路は検証ゲートを通す、判定不能は要人間確認、走査0 件はfail、事実と推測の区別 決定記録、ナレッジベース、テスト資産（テストケース・ Playwrightコード） 捨てたもの テストケースの3表現（MD/TSV/YAML）と2系統のハッシュ 3か所から別々に呼ぶ検証と、保存のたびに走るHook 状態を変える処理の分散（3関数と呼び出し側） 旧形式を読む分岐、新旧フォルダの二重探索 新に無かっ 画面仕様の「最終調査日」と90日超の警告 たもの 同じ 同じ 新ツール 変換して持ち込む YAML1つ、ハッシュ1系統 1つのエンジンを段階の出口とCIから呼ぶ 1つの遷移表 本体には持たない（取り込みツールの中 だけ） 知識の失効が無い。仕様に足すと決めた （設計はこれから） Hookをやめた代償: 手で直した成果物の検出が次の段階の出口かCIまで遅れる。遅れてよいと判断した 25 

— 【付録】旧ツールの資産をどう持ち出すか — 捨てるもの、持ち出すもの 資産 実行資産（Playwrightコード） 607件 ナレッジベース・決定記録86本 テストケースの現役分 6,388件 過去の実行結果・旧の成果物フォ ルダ 扱い 変換して持ち込む。ただし「独立に再現できたもの」だけ実行に使い、新要件で検証済み とは数えない 変換して持ち込む 変換して持ち込む。変換できる件数は未集計 旧側に凍結し、参照だけ Joel Spolsky「Things You Should Never Do」（2000）: 古いコードには実運用で見つかった修正の知識が詰 まっている。捨てればその知識ごと捨てる。この警告は正しいと思う 持ち込めるのは文書になっている知識だけ。旧コードの分岐が黙って守っていた条件は、文書に無ければ取り 込みの対象にすら現れない。棚卸しでも、文書にも分岐にも無い条件は見つけられない 26 

— 【付録】作り直しの見直し条件 4つ — 旧と新を同じ対象・同じ条件で測る # 条件 1 テストの網羅性が旧より低い 2 所要時間が旧より長い 旧ツールで蓄えた資産が活用で 3 きず、実質的に捨てることにな る 一つの規則を直すために独立し 4 て修正した場所の数が、旧と同 等以上 測り方 事前に固定した期待セット（必須の観点と既知の不具合）に対する検出率。判定を人に戻 した分は網羅に数えない 設計から結果の確定まで。人の確認にかかった時間を含める 変換できたテストケースの件数と、独立に再現できたPlaywrightコードの件数 コミットの分割に関係なく修正全体で数え、実装・テスト・文書を分け、手戻りも含め る。旧側の参考値: ハッシュ修正 コミットごとに6ファイルと9ファイル（重複あり）、読 み方の集約 11ファイル どれか1つでも当てはまれば、作り直した意味を疑い、判断を見直す。測るのは新ツールで1回のQAを完走し た時点。旧ツールを止める条件と、新から戻す条件はまだ決めていない 「明確な要件で新規に作った方が信頼できるし、保守も安くなるはず」の「はず」は、まだ「はず」のまま 27 

— 【付録】QA業務26項目のAI影響分類（代表抜粋・代替型10／強化型16） 業務カテゴリ テストケース作成 テスト実行 不具合起票 形式変換 テスト戦略立案 仕様レビュー ハーネス・パイプライン構築 品質データ分析 代表的な業務 仕様・コードからのテストケース起こし 定型的なリグレッション実行 再現手順・期待結果の記述と起票 既存テストケースのTSV・定型レポートへの変換 リスクに応じた優先度・範囲の設計 仕様段階での抜け・矛盾の指摘 検証ロジックとHookの設計 不具合傾向の分析と観点への還元 分類 代替型 代替型 代替型 代替型 強化型 強化型 強化型 強化型 分類の出発点は Anthropic Economic Index の「AIが代わりに行う（代替型）／人を速くする（強化型）」の観 測指標 「約50%」は項目数の比ではなく、各業務の作業時間で重みづけして部内で合意した見積もり。翌月、実案件 2件で同水準の実測 28 

— 【付録】出典一覧（1/3）— 本人の公開物 Software Design 2026年10月号（技術評論社・9月18日発売）第2特集「手探りの先に見えたQAの未来 AIに よるテスト自動化のリアル」 Zenn（TOKIUMプロダクトチーム テックブログ） QAチームのナレッジを「ハーネス」にする — Claude Codeでテスト設計を自動化した話 https://zenn.dev/tokium_dev/articles/705334e2f6ac10 コードを1行も書く前にバグを潰す — 生成AIが「理想論」だったシフトレフトを現実にする https://zenn.dev/tokium_dev/articles/c0e6e9aca98a85 正解のないテストに挑む ― AIエージェントQAの試行錯誤と学び https://zenn.dev/tokium_dev/articles/c986844e3cf8d8 Findy オンライン「AI時代のPlaywright活用」登壇（2026-07-21）— 全体像の図はこの登壇資料の再掲 Zenn「5か月育てたQAのハーネスを棚卸しして、作り直すと決めた理由」（2026-09-25）— 今日の棚卸し・ 作り直しの数値と判断の全文 https://zenn.dev/tokium_dev/articles/aab76519f4d2d9 29 

— 【付録】出典一覧（2/3）— 業界データ Anthropic Economic Index（代替型／強化型の分類の出発点） https://www.anthropic.com/news/theanthropic-economic-index ／論文 "Which Economic Tasks are Performed with AI?" https://arxiv.org/abs/2503.04761 Anthropic, "Labor market impacts of AI: A new measure and early evidence" https://www.anthropic.com/research/labor-market-impacts Google Cloud, "Announcing the 2025 DORA report"（AIはチームの強みも弱みも増幅する。強い自動テス ト・成熟したバージョン管理・速いフィードバックが前提） https://cloud.google.com/blog/products/aimachine-learning/announcing-the-2025-dora-report Joel Spolsky, "Things You Should Never Do, Part I"（2000-04-06。「書き直すな」の警告） https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ Playwright, "Test Agents"（テストの計画・生成・修復が標準機能になった例） https://playwright.dev/docs/test-agents 30 

— 【付録】出典一覧（3/3）— 公開事例（2026-09-04 に URL 再確認） LayerX「QAをやめて、QAをはじめる」 https://tech.layerx.co.jp/entry/quit-qa-start-qa 食べログ Tech Blog（AI4QA 自動テスト） https://tech-blog.tabelog.com/entry/ai-for-qa-automation-test freee Developers（QA Advent Calendar 2025 day25） https://developers.freee.co.jp/entry/freee-qaadvent-calendar2025-day25 SmartHR Tech Blog（品質保証部連載 第5弾） https://tech.smarthr.jp/entry/qa_series_article_vol5 メルカリ Engineering（QAエンジニアがAIで日々の課題を解決した話・AC Generator） https://engineering.mercari.com/blog/entry/20251203-46bf6511f3/ エムスリー Tech Blog（エムスリー QAチームのこれから2026） https://www.m3tech.blog/entry/qa2026 数値はいずれも各記事の記載どおり（食べログ: テスト実行工数 0.9→0.43人月＝52%減・自動化率 24%→64%／ LayerX: 確認型テスト252件で欠陥0件） 31