Inspired by "WYSIWID" paper and #VibeCoding concepts.
A project to structure QA's "tacit knowledge" into "explicit knowledge" with AI.
"Structure-Based Agentic Testing"
「どのテストから始めたらよいだろうか ー「何もしないこと」のテストから始めてみよう」Kent Beck 著、和田 卓人 訳：テスト駆動開発 より
- はじめに
- おことわり
- Vibe Testingとは？
- 一段目：「過去の亡霊」との決別
- 二段目：経験知「品質保証のゴールデントライアングル」の限界
- 三段目：転機「What You See Is What It Does」
- 四段目：Vibe Testingでの「融合」と実装（Implementation）
- 五段目：技術スタックと実装 ーAIエージェントとの共創ツールチェーンー
- 六段目：できたこと・成果（Achievements）
- 七段目：むずかしいところ・正直な葛藤
- 八段目：Vibe Testingの「熱意（Passion）」〜批判的対話を経て〜
- 九段目：まとめ・今後の展望（QAエンジニアのロール変革への一歩）
- 十段目：おわりに
はじめに
どうも！
AI開発推進部でQA（品質保証）エンジニアをしています、高田です！
「秋」
マロングラッセとドリップコーヒーと石焼きいもが、一番美味しい季節。
も、あっという間に過ぎ去ろうとしつつ、「えっ、もうすぐで年末！？」と慄いている、今日このごろ。
入社して、1年とちょっと経って、いろんなことがあり（初のLT登壇だったり、初の部署異動だったり、人生初のボーナスだったり）
※今年9月から、開発二部 QA課→AI開発推進部に異動になりました。
「"初めてづくしで"なんか、充実してたな〜」と、感慨に耽っております。
そんな、初めてづくしの中で、本投稿で初めてお話すること。
そう、Vibe Testing計画についてです。
「Vibe Codingなるものがあるのか。ん？、Vibe Testingもあるんじゃね？」と今年の夏に思い立ち、考えて一旦アウトプットしてみました。
ただ、考えたはいいけど「じゃあ、どんなことして何をするの？」という明確なビジョンが、ふにゃっふにゃで、計画の構想が頓挫してたところ、最近やっとその道筋も明確になり、これから実践へと踏み出すことと相成りました。
今回は、現在進行中のプロジェクト「Vibe Testing計画」について、考えることになったきっかけから、構想、挫折、転機、現在の立ち位置までを書こうと思います！
おことわり
今回は実践した結果を、お見せすることはできません。
ですが、ここ直近で弊社ユニファが掲げてる行動指針の「SpeedDriven」「PlayFair」をもとに、Vibe Testing計画の骨子を爆速で進めた結果、「OneMoreStep」なものを構想することができ、その構想内容が「高田の中で、納得いくものになった」ので、今回その証跡を残すために投稿しました。
そして、個人的な意見ですが「早く、失敗したい！」と願っています。
その失敗は、「経験」となってくるものとも考えているからです。
あと、「事が予定調和に進むなんて、今までで無いでしょ？」と。
プロジェクトしかり、人生もしかり。
ということで、ここから本編です！
Vibe Testingとは？
まず最初に、「Vibe Testing」とは何か？を一言で説明します。
それは、「QAエンジニアの頭の中にある『経験知』を、AIと共に『形式知』へと変換し、構造化するプロジェクト("A project to structure and transform QA's 'tacit knowledge' into 'explicit knowledge' through co-creation with AI.")」です。それらを通して、「根本的・本質的に、品質を”エンジニアリング”する("Engineering quality, at its very core.")」ことを、目指します。
私たちQAエンジニアが長年培ってきた「テスト設計の勘所（Golden Triangle）」に、最新のソフトウェア可読性理論「WYSIWID」を掛け合わせ、さらにそこに「AI（Who）」と「意図（Why）」を組み込むことで、人間にもAIにも理解しやすい品質保証のモデルを構築します。
概念を図にすると、以下のようになります。
graph TD
subgraph Experience ["Experience (Golden Triangle)"]
Where[Where? <br>テスト対象<br><br>]
What[What? <br>テスト観点<br><br>]
How[How? <br>テスト方法<br><br>]
end
subgraph Structure ["Structure (WYSIWID)"]
Concepts[Concepts <br>独立した機能単位<br><br>]
Syncs[Synchronizations <br>連携ルール<br><br>]
Actions[Actions <br>具体的な操作<br><br>]
end
subgraph NewElements ["New Elements"]
Who[Who? <br>AI as a Reader<br><br>]
Why[Why? <br>Intent & Property<br><br>]
end
Where --> Concepts
What --> Syncs
How --> Actions
Who -.-> Concepts
Who -.-> Syncs
Why -.-> Syncs
では、なぜこのプロジェクトが生まれたのか？ その背景からお話しします。
一段目：「過去の亡霊」との決別
きっかけは、前職の在籍中に、個人で書いた記事「それ、「TM技術を使った、MBT(モデルベースドテスト)」で解決出来ないか？」に遡ります。
QA歴10年目になろうとして、やっとこさ自分なりの「品質保証の型」が見えて実践知を積んでいく中で、3つの大きな課題（亡霊）を抱えていました。
- 書式や内容の粒度、確度がバラバラ: テスト設計書や計画書のフォーマット、ひいては仕様書のフォーマットが統一されていない。
- 仕様書がない！（これが、一番キツイ）: そもそも存在しないか、更新されておらず古い。
- 伝わらない: QAの意図が開発者に、あるいは開発者の意図がQAに伝わらない。また、ステークホルダーにもその意図が伝わらない。
「品質保証の型」を身に着けても、その身につけた実践知や品質保証の知識体系を使って「色も形もバラバラなパズルを一つずつ組み合わせながら、時には、無理矢理ねじ込んだりもしながら、なんとか一枚の絵にしていた」そんな品質活動を続けてました。
要は、「認知負荷が高すぎて、あらゆるリクエストを察してテストドキュメントを作るのは、疲れる」というところです。
その疲れが澱のように溜まっていく中で、上の記事にも書いた「モデル化（TM技術）」こそが解決の鍵になるのではないか？。という直感を持つようになりました。
混沌とした仕様や要件を、構造化されたモデルとして表現できれば、ステークホルダー同士のコミュニケーションによる齟齬はなくなり、テストも自動化しやすくなるはずだ、と。
また、どの人が読んでも「意図」が伝わることで、自分たちの行動・活動に「意義がある」と自己効力感を持って、前向きにプロジェクトを進められる、と。
そして、生成AI時代の現在。その直感は、ある最新の論文との出会いによって当初の予想を超えた「解への近道」へと進化することになりました。
それが「Vibe Testing計画："AI版Model-Based Testing"」です。
二段目：経験知「品質保証のゴールデントライアングル」の限界
高田自身は、熟練には遠く及ばず、まだまだ中堅レベルであると自覚していますが、長年QA業務に携わっていると、テスト活動をする際に無意識に使っている「思考の型」のようなものが出来上がってきました。
高田はこれを、勝手に「品質保証のゴールデントライアングル」と呼んでいました。
それは、非常にシンプルな3つの要素で構成されています。
- Where? (テスト対象): どの画面、どのAPIか。
- What? (テスト観点): 何を確認するのか（シナリオ、組み合わせ）。
- How? (テスト方法): 具体的にどう操作するのか。
熟練のQAエンジニアは、仕様書がなかったとしても、画面を見た瞬間にこの3要素を脳内でテスト分析・設計を瞬時に組み立て、テストシナリオを構築していきます。
もしくは、仕様説明の段階で話を聞きながら組み立てて、「勘所」を押さえている人もいます。
「この画面（Where）なら、こういうバリデーション（What）が必要だから、こういうデータを入力（How）してみよう」といった具合です。
面白いことに、この思考プロセスは手動テストを行う場合でも、自動テストのコードを書く場合でも、本質的には変わりません。どちらも「対象」に対し、「操作」を行い、「結果」を確認するプロセスだからです。
その「品質保証のゴールデントライアングル」を、先述した「品質保証の型」として、高田なりに身につけていきました。
しかし、当時の高田は、この3要素の外側にもう2つの重要な要素があることを、ある種の「当たり前」として切り離していました。
それが 「Who?（誰が）」 と 「Why?（なぜ）」 です。
これらは「テスト計画（Plan）」フェーズで定義するものとして切り離していたのです。
これからの形式（Vibe Testing）と比べて欠けていたのは、「ソフトウェアの構造としてのWhy（因果関係）」への考慮でした。
「なぜこの入力で、この結果になるのか？」というロジックや、「なぜこの順序で操作するのか？」という意図。
これらが、具体的なテスト手順（Design/How）に落とし込まれる過程で、単なる「操作ステップ」へと変換され、最も重要な「理由」が削ぎ落とされていたのです。
この構造レベルでのWhyの欠落（およびWhoの不在）こそが、QAの意図が伝わらない、そしてAIが文脈を理解できない根本原因だったことに、当時は気づいていませんでした。
また、「品質保証のゴールデントライアングル」についても属人的であり、暗黙知のままであるということも課題としてありました。
そうなると、頭の中で整理されているもの・ドキュメントにアウトプットしたものを、新人のQAエンジニア、他のステークホルダー、AIに伝えようとすると、途端に難しくなる。
それは、テストの意図がなんとなくでわかった「気」になる、クローズドな暗黙知として。
この「暗黙知の壁」をどう乗り越えるか。それが、ここ最近まで追っていたテーマでした。
三段目：転機「What You See Is What It Does」
そんな折、一つの論文と出会い、衝撃を受けることになります。
今年、arxivにて公開された論文 「What You See Is What It Does: A Structural Pattern for Legible Software」 という論文です。
論文では、ソフトウェアの可読性を高めるための構造パターン（Concepts/Syncs）について書かれており、AIエージェントにおける「認知（See）」と「行動（Do）」の一致を目指すためのモデルを提唱していました。
一見すると、論文で提唱されている主要な概念は、高田が経験知・実践知で得た「品質保証の型」と驚くほど綺麗にマッピングできるように見えました。
- Concepts (概念) ≒ Where? 独立した状態とアクションを持つ機能単位。Page Object Modelにおけるページクラスのような、他と依存しない「個」としての存在です。
- Synchronizations (同期) ≒ What? Concepts同士の連携ルール。あるConceptの状態変化が、別のConceptにどう影響するか。これがまさに「テストシナリオ」や「観点」になります。
- Actions (操作) ≒ How? Conceptsに対する具体的なメソッド実行。クリックや入力などの具体的な操作手順です。 重要なのは、この「Actions」が手動テストの手順であれ、自動テストのスクリプトであれ、モデル上は等価であるという点です。
"品質保証のトライアングル”そのものが間違いではない。問題は、仕組みにあったことに気付きました。
と同時に、高田がこれまでのキャリアの中で得た経験知に「構造」と「意味」を与えてくれましたような気がしました。
これまで「勘」や「センス」という言葉で片付けられていたQAとしての直感が、「Concepts / Syncs / Actions」 という論理的なエンジニアリング用語として説明できるようになったのです。
これは高田にとって、まさに「アハ体験」でした。
さらに重要なインサイトを、得ることもできました。
それは、Plan（計画）だけでなくDesign（設計）の中核に「Who（AI/人間）」と「Why（目的/不変条件）」を埋め込む必要性です。
- Who? (Observer): ソフトウェアは「誰」にとって読みやすくあるべきか？ → AIもまた、ひとりの「読者（Who）」である。
- Why? (Purpose/Causality): コンセプトには必ず「目的（Purpose）」があり、シンクロニゼーションは「因果関係（Why）」を説明するものである。
ここで気付いたことは、AIもまた、ひとりの「読者（Who）」であること。
そして、構造の中に「なぜそうなるのか（Why）」が含まれていなければ、人間もAIも、文脈を理解できないのです。
「Who」と「Why」は計画フェーズだけの話ではなく、設計（Design）の中核、つまり「Concept」と「Sync」の定義そのものに含まれていなければならない要素だったのが、大きなインサイトでした。
四段目：Vibe Testingでの「融合」と実装（Implementation）
ここで、先述したインサイトを、実際のプロジェクトでどう「形式知」として落とし込もうとしているかをご紹介したいと思います！
① 【Format】「書式バラバラ」問題への解：Concepts/Syncs分離モデル
まず着手したのは、テスト標準（憲法）とテストドキュメントの刷新です。
- Concepts Definition: テスト設計書に「登場人物（Concepts）」の定義テーブルを新設。これにより、AIに「Where（テスト対象）」を厳密に教えることが可能であると考えました。
- Viewpoint Matrix: 従来のテストケースを「Syncs（シナリオ）」として再定義しました。
これにより、誰が書いても「構造化されたデータ」となり、AIが学習可能な形式に統一されました。
更に深掘ると、これまでは「PlanでWho/Why」「DesignでWhere/What/How」と分けていた思考を改め、「Design（Viewpoint Matrix）」の中に「Why（目的/Syncの意図）」を明示的に組み込むように意識改革をするようにしました。
具体的には以下の2点です。
- 「Design（Viewpoint Matrix）」の進化:従来の「期待値」を「Then Property（満たすべき性質）」へと再定義。単なる「結果」ではなく、「なぜその結果になるべきか（Why）」という不変条件（Invariant）を記述させることで、AIが検証すべき「正解」の精度を高める。
- Concepts定義の分離:テスト設計書内に「Concepts Definition」テーブルを新設し、テスト対象の「責務（Responsibility）」を明文化。これがAIにとっての「Where/Who」の定義となります。
AIに対するプロンプトとしても、「操作（Action）」だけでなく「なぜその操作が必要か（Sync/Purpose）」を含めることで、ハルシネーションを抑制することを目指しています。
② 【Spec】「仕様書がない」問題への解：Process Transformation
次に、情報の抽象度を段階的に変換するフローを確立しました。
- Plan & Spec: ユーザーストーリーを「Concepts」と「Syncs」に分解します。このプロセス自体が「テスト仕様書」を作成する行為となります。
- Design: マトリクスを用いて網羅性を担保します。
- Implement: ここで初めて、具体的なコードや手順（How）に落とし込みます。
ここで重要なのがProperty-Based Approachの導入です。
DesignとImplementにある、テンプレートの「期待値」を「Then Property（満たすべき性質・不変条件）」へ変更しました。
「なんとなくOK」ではなく、「Concept AはIntegrity（整合性）を保っているか？」という問いに答えることで、仕様の曖昧さを徹底的に排除しました。
また、Syncs（シナリオ）で書くと肥大化するという課題に対し、以下の解決策を導入しました。
- Concepts側に「状態の整合性（Integrity）」を持たせる。
- Syncsは「連携（Synchronizations）」だけに集中する。
これにより、AIへの指示が「詳細な手順（Micro-management）」から「目的と性質の検証（Goal-oriented）」へと進化すると考えています。
③ 【Communication】「伝わらない」問題への解：レイヤー別適用戦略
最後に、テストピラミッドをベースに各テストレベルを再定義し、共通言語化を図りました。
- Small (Unit Test): Syncs（連携ルール）を使わず、個々のConceptsのProperty（不変条件・整合性）検証に集中する（開発者向け）。
- Medium/Large (Integration/System/E2E Test): Syncs（連携ルール）を主軸に、Concepts間の相互作用と因果関係（Why）を検証する（QA/ステークホルダー向け）。
「このテストはSyncを確認するフェーズ（Medium/Large）です」「これはConceptのProperty検証（Small）です」という共通言語ができたことで、開発とQAが意図を共有しやすくするようにしました。
そして、「AIエージェント」を新たな「Who（テスター）」として定義し、人間にとって読みやすいテスト仕様（Syncs）は、AIにとっても読みやすい（＝実行しやすい）という「Legibility」の共通項を見出し、人間とAIが同じドキュメントを見て協働する環境を整備しました。
五段目：技術スタックと実装 ーAIエージェントとの共創ツールチェーンー
ここで、気になる技術スタックを、以下に掲載していきます！
今回構想・構築したVibe Testingの実装は、以下の3つの柱（Brain, Body, Nervous System）で支えるようにしました！
それぞれの役割とデータの流れは、以下の図のようになっています。
graph LR
subgraph Brain ["Brain (Design and Code)"]
Cursor["Cursor AI"]
SpecKit["spec-kit"]
Spec["Spec (Markdown)"]
Plan["Plan and Tasks"]
end
subgraph Body ["Body (Execution)"]
Playwright["Playwright"]
Vitest["Vitest"]
Manual["Manual Test (Natural Lang)"]
Recorder["Recorder"]
Report["Markdown Report"]
end
subgraph Nervous ["Nervous System (Sync)"]
MCP["Atlassian MCP Server"]
Confluence["Confluence Doc"]
end
Cursor -->|Write| Spec
Spec -->|Input| SpecKit
SpecKit -->|Generate| Plan
Plan -->|Implement UT| Vitest
Plan -->|Implement Auto| Playwright
Plan -->|Implement Manual| Manual
Vitest -->|Result| Report
Playwright -->|Result| Report
Manual -.->|Log| Recorder
Recorder -.->|Code| Playwright
Cursor <-->|Sync| MCP
MCP <-->|Update| Confluence
リッチに書くと↓のようになります！
flowchart LR
classDef tool fill:#e1f5fe,stroke:#01579b,stroke-width:2px,rx:5px;
classDef doc fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,shape:subroutine;
classDef process fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,shape:ellipse;
classDef actor fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px;
User(("QA Engineer")):::actor
subgraph Brain ["Brain (Design and Code)"]
direction TB
Constitution[["Constitution and Rules"]]:::doc
Cursor["Cursor AI"]:::tool
SpecKit["spec-kit"]:::tool
Spec[["Spec.md"]]:::doc
Plan[["Plan and Tasks"]]:::doc
end
subgraph Body ["Body (Execution)"]
direction TB
Vitest["Vitest (Small)"]:::tool
Playwright["Playwright (Large)"]:::tool
ManualTest("Manual Execution"):::process
Recorder["Browser Recorder"]:::tool
Logs[["Trace / Code Logs"]]:::doc
Report[["Markdown Report"]]:::doc
end
subgraph Nervous ["Nervous System (Sync and CI)"]
direction TB
MCP["Atlassian MCP Server"]:::tool
GHA["GitHub Actions"]:::tool
Confluence[["Confluence Page"]]:::doc
end
User -->|"Prompt / Review"| Cursor
Constitution -.->|"Rule Check"| Cursor
Cursor -->|Write| Spec
Spec -->|Input| SpecKit
SpecKit -->|Generate| Plan
Plan -->|"Implement UT/PBT"| Vitest
Plan -->|"Implement E2E"| Playwright
Plan -->|"Implement Procedure"| ManualTest
GHA -.->|"Trigger CI"| Vitest
GHA -.->|"Trigger CI"| Playwright
Vitest -->|Result| Report
Playwright -->|Result| Report
ManualTest -->|"Judgment: OK/NG"| Report
ManualTest -.->|"Record Ops"| Recorder
Recorder -.->|"Generate Code"| Logs
Logs -.->|Import| Playwright
Report -->|"Analyze / Improve"| Cursor
Report -->|"Sync Result"| MCP
Cursor <-->|"Read / Update"| MCP
MCP <-->|Sync| Confluence
Brain (Design & Code): Cursor + spec-kit GitHubが開発したSDDツールキット「spec-kit」を用いたものを、採用することにしました。
Markdown形式のSpec (/specify) から実装計画 (/plan) とタスク (/tasks) を生成するこのツールにより、AIエージェントが「迷いなく」テストケースやテストコードを生成できるパイプラインを構築しました。Body (Execution): Playwright + Vitest + Recorder 自動テストはPlaywrightで実行し、Custom Reporterで結果をMarkdown化するようにしました。
手動テストは、自然言語（日本語）で記述されたテスト手順（Actions）として実装されます。これにより、誰でも読み書きできる状態を保ちます。
さらに、「Recorder」で操作ログを記録し、将来的にはそれをコードとして管理・自動化へ接続する仕組みも整備中です。Nervous System (Sync): Atlassian MCP Server AIエージェントがConfluenceと直接対話し、ドキュメントの同期や更新を行うようなことを想定しています。
これにより、「テストコードとドキュメントの乖離」という永遠の課題に終止符を打つことを目指しています。
こちらについては、テストドキュメント自身の管理方法も鋭意構想中のため、現状の管理ツールをベースにしました。
2026年6月までには、なんとか形作りたい（もうちょい、早まるかも？）ために、以下の指標を重視してテスト活動を進めていき、上記をブラッシュアップする予定です。
- 単なる自動化率だけでなく、「ハルシネーション率（誤生成）」や「バイアス含有率」を監視。
- また、生成されたテストコードの「Legibility（可読性）」や「Sync Transparency（透明性）」を重要指標として設定し、人間にとっても理解しやすいテスト生成を目指す。
六段目：できたこと・成果（Achievements）
以下に、このVibe Testing計画をする中で、得たものを以下に掲載します！
「仕様書がない」問題の真の解決
単に「動作」を記述するのではなく、「意図（Why）」をSyncsとして記述することで、それが「生きている仕様書」になる道筋が立てられたこと。
また仕様変更があった際も、「動作」だけでなく「意図」に立ち返ることで、メンテナンスの指針が明確になると考えています。
AIとの対話の質向上
「XXをテストして」という丸投げの指示から、「XXという目的（Why）のために、YY（Who）の視点で、ZZ（Concept）のProperty（整合性）を確認せよ」という、高度な文脈付きの指示が可能になったこと。
これにより、AIが生成するテストコードの品質と信頼性が格段に向上することを目指します。
あとは、実践あるのみ！！ということで、その実践知をこれからAI開発推進部内のQA（一人しかいないですが）としてゲットしていき、トライ＆エラー通して品質保証活動に臨みたいです！
七段目：むずかしいところ・正直な葛藤
そう意気込んでも、もちろん、理想通りに全てが進むわけではありません。
以下のところが、難しいところであると考えてます。
「Why」の言語化のコスト
「なんとなく」で動いていた仕様に対し、逐一「なぜそう動くのか（Syncのルール）」や「不変条件（Property）」を定義するのは、人間にとって非常に負荷が高い作業です。
「動けばいいじゃん」という誘惑と常に戦う必要があります。
ほら、エンジニアって基本「楽したい生き物」じゃないですか！。
その「楽したい〜！」を「判断を楽にしたい〜！」という悪い誘惑から、如何に遠ざけるか。品質という「目に見えないもの」を相手にしているQAエンジニアなら、尚更です。
抽象度のコントロール
UTレベルのPropertyと、E2EレベルのSyncをどう使い分けるか。この「レイヤーごとの翻訳」こそが、QAエンジニアの新たな専門性になると痛感しています。
論文はあくまで「構造」の提案であり、それを実務の「ドロドロした仕様」に当てはめるには、QAエンジニアによる高度な「翻訳（モデリング）」能力が不可欠です。AIが勝手に解決してくれるわけではないのです。
また、論文を精読し、実際のテスト設計に落とし込む過程で、いくつかの「壁」にぶつかりました。
しかし、その壁こそがVibe Testingをより強固なものにするためのヒントを与えてくれました。
以下に論文（WYSIWID）に対する批判的思考実験を経て得られた、3つの重要なインサイトを共有します。
Whoの壁：「誰」にとっての正解か？
論文ではConcept（概念）は独立しているとされますが、現実には「誰（Who）」が見るかによって「正解」が変わります。
管理画面とユーザー画面で同じConceptの見え方が異なるように、テストにおいても「ペルソナの視点」が欠落すると、AIは文脈を見失います。
インサイト① Principle of Persona (Who):テストやConcept定義において、「誰」の視点であるか（Persona/Access Policy）を常に明示する。
「普遍的な真実（例：サーバーが落ちない）」と「文脈的な真実（例：このユーザーにはボタンが見える）」を区別して定義することにしました。
Whyの壁：同期ルールの競合
「AならBする」「CならDする」という同期ルール（Syncs）が増えた時、それらが競合したらどうなるか？
例えば「認証エラー」と「バリデーションエラー」が同時に起きた時、システムはどちらを優先すべきか。
論文のアーキテクチャではこの解決策が暗黙的でしたが、テストにおいては致命的です。
インサイト② Principle of Causality (Why & Time):同期には必ず「意図（Why）」と「優先順位（Layer）」を持たせる。
また、静的な結果（Then）だけでなく、「Eventually（いつかそうなる）」や「During（その間はずっと）」といった時間的な振る舞い（Temporal Logic）を検証対象に加えることにしました。
Actionの壁：エッジケースの爆発
Webの世界では、HTTPステータスコードやネットワーク遅延など、考慮すべき「状態（Actionの結果）」が爆発的に増えます。
これをすべて人間が設計するのは不可能ですし、それをやろうとすると「楽をしたい」という本能に負けてしまいそうです。
インサイト③ Principle of Generative Coverage (Action):人間は「あるべき性質（Property）」の定義に注力し、エッジケースの網羅は「人間とAI/Fuzzerの協業」によって達成する。
人間がシード（種）となるテストケースと不変条件を与え、AIがそれを拡張して「意地悪なケース」を生成する。
この役割分担こそが、Vibe Testingの現実解であると考えしました。
これらの部分が、これから実践していくときに最大の問題・課題となるのは、間違いないでしょう。
ただ、その苦しみの中にエンジニアとしての楽しみや自己効力感を持つことができるのであるなら、喜んでその苦しみを受けることにしたいです。
このVibe Testing計画で構築した方法も、もしかしたら「全て捨て去って、また新たに構築する」かもしれませんが、まだ「手を動かしていません」。
手を動かして、失敗（経験）して、アンラーニングして、インサイトを得て、手を動かして、失敗（経験）して。を、繰り返して。
「本当の失敗」は、「機能不全による、崩壊」であると考えてます。
そうならないように、今回構築したものからクリティカルに考えながら、「手を動かして」いく所存です。
八段目：Vibe Testingの「熱意（Passion）」〜批判的対話を経て〜
この計画を進める中で、プロのリサーチャー（AI）と批判的な対話を行いました。
そこで浮き彫りになった「問い」と、それに対する高田の「熱意（答え）」を、ここに記しておきます。
これは、Vibe Testingを単なる「楽をするための手法」に堕落させないための、自分自身への戒めでもあります。
1. "We seek 'Simple', not 'Easy'." （我々は安易さではなく、単純さを追求する）：「簡単（Easy）」と「単純（Simple）」は違う
「Vibe Coding」の文脈では、「Low Cognitive Load（低い認知負荷）」すなわち「詳細を気にせず、自然言語で雑に作れる軽さ」が良しとされます。
しかし、「簡単（Easy）」であることと、「単純（Simple）」であることは、似て非なるものです。
- Easy（簡単）: 手数を減らし、楽をすること。メソッドへのフォーカス。
- Simple（単純）: 構造上の複雑さを排除し、明快であること。アーキテクチャへのフォーカス。
Vibe Testingが目指すのは「雑にテストすること（Easy）」ではありません。
品質という「目に見えない概念」を、雑に扱ってよいわけがないのです。
もし構造を理解しないまま、ただAIに「いい感じでテストして」と投げるなら、それは「品質保証のエンジニアリングではなく、ただの作業を再定義した車輪の再発明」に過ぎません。
QAエンジニアが構築したのは、人間にもAIにもわかる「構造上で複雑なことはなく、単純なこと（Simple）」です。
2. "Testing without structure is just reinventing manual labor." （構造なきテストは、手作業の再発明に過ぎない）：「量（Brute Force）」より「構造（Structure）」
海外のトレンドの一部には、「AIは所詮、確率的なトークン予測器である」という諦念に基づき、「質より量（大量の探索的テスト）」でバグを見つけようとする「How重視（ツール重視）」のアプローチがあります。
しかし、その「量」のアプローチが失敗した時、そこには何が残るでしょうか？
費やした時間と計算リソースが、徒労に終わるリスクがあります。
対して、「Why（構造）」重視のアプローチはどうでしょうか。
仮に失敗したとしても、その失敗は「構造のどこが間違っていたか」という「経験知」として残ります。
それは人間にとっても、AIにとっても、次に繋がる学習データ（ナレッジ）となります。
「動いていることを確認する」だけではなく、「品質を検証・評価する」という本来の目的を見失わないために。
QAエンジニアは、確率に頼るギャンブル（Brute Force）ではなく、エンジニアリング（Structure）を選択します。
3. "Turn failures into assets, not waste." （失敗を徒労ではなく、資産に変えよ）：バイアスとの共存
「構造を定義すること自体が、設計者のバイアスではないか？」という批判もあります。
その通りです。ダニエル・カーネマンのプロスペクト理論にあるように、バイアスを完全に排除することは不可能です。
だからこそ、「Who?（誰にとって？）」と「Why?（なぜ？）」を構造に組み込みました。
これらを能動的に定義し続けることこそが、バイアスによる汚染を最小限に留める唯一の方法であり、それこそがQAエンジニアのスキルアップ（自己効力感）に繋がると信じています。
「作業はシュリンクするが、品質をエンジニアリングすることは無くならない」("The work may shrink, but the engineering of quality endures.")。
この信念を持って、Vibe Testingを進めていきます。
九段目：まとめ・今後の展望（QAエンジニアのロール変革への一歩）
私たちQAエンジニアは、「テストシナリオ通りに動いていることを、確認する低レイヤーの人」でなければ「開発者が作ったものに、ケチをつける嫌な人」でも、「チェックリストをただこなしているだけの人」では、ありません。
QAエンジニアは、品質という「目に見えない概念」に正対して、日々「品質とは、何か？」を問い続けながら、日々の業務にあたっています。
「確率的に変わる / 非決定的に決まる期待値」である現代の生成AI時代で、より「品質保証の複雑性・多様性など」が増す真っ只中で、ちゃんと正対して対峙しなければいけません。
高田のミッションは、今回得たもの（長年の経験知（Golden Triangle）を論文（WYSIWID）という型に流し込み、AIという新たなパートナー（Who））と共に、品質の「Why」を問い続けることです。
その品質の「Why」を問い続けながら、「QAエンジニアは、品質という”誰かにとっての価値”を語るストーリーテラーになること」であると、個人的な意見ですが考えています。
そのために、「品質のモデラー（Quality Modeler）」へと進化しなければならない、とも考えています。
単なる自動化でも効率化でもなく、「AIが文脈（Why）を理解する」ための学習フェーズを重視し、今後に向けて、このVibe Testingが「意味のある・意義のある活動であること」を、実証していきます。
十段目：おわりに
如何でしたでしょうか？
今回は、実践知の公開には至らなかったのですが、今後そこで得たものを共有できたらと考えてます！
「すべての人にすべてのものを与えようという考えを捨て、90パーセントのニーズを満たすことに徹しているのだ。残りの10パーセントには、それぞれに自分のオペレーティングシステムを書いてもらうしかない」Mike Gancarz 著、芳尾 桂 監訳：UNIXという考え方 より
今回も、最後まで読んでいただき、ありがとうございます！
そして告知ですが、来月12/16（火）に以下のイベントにて登壇します！
よかったら、聞きにきてください！
では、また！
ユニファでは家族の幸せを生み出すあたらしい社会インフラを一緒につくっていく仲間を大募集しています！
気になる方はぜひこちらのサイトもチェックしてみてください！！
