「成功したギバーは、自分だけではなくグループ全員が得をするように、パイ（総額）を大きくする。」アダム・グラント 著、楠木 建 訳：GIVE & TAKE 「与える人」こそ成功する時代 より
目次（クリックすると展開されます）
はじめに
どうも！
AI開発推進部でQA（品質保証）エンジニアをしています、"たかだ"です！
からっ風が吹きすさぶ中。いかが、お過ごしでしょうか？
そんな中、最近ノルウェー式HIIT*1を導入したおかげで、体力がついてお酒の席がラクになってきた今日このごろ（新亀のだし割が、うまい季節です）。
今回は、弊社PdMのさとうさんが以前ご自身が投稿した記事を元に、「PdMがテスト観点を作ってみた」経験から、「PdMが作ったテスト観点から、QAエンジニアがAIエージェントといっしょにテストを書いてみた」ことを書いていこうと思います！
tech.unifa-e.com
モチベーション
弊社PdMである、さとうさん*2が、以下のような思いから、テスト観点を作ってみたとのこと。
- 開発品質を高めつつもスケジュールを厳守したい
- 実物（開発成果物）とイメージとのギャップから、レビューなどでかかる工数をなんとかしたい
- 開発メンバーとの間にある「認識の行間」を、なんとか近づけたい（できれば、「その行間」は作りたくない）
そんな実務の課題感から、テスト観点を書いてみたことを開発定例で紹介されていたことが、今回の記事を投稿するきっかけでした。
突然ですが、ここで「感謝の言葉」
PdMのさとうさん*3に、最初に感謝申し上げたいです。
PdMの方で、テスト観点を「想像する」ことはあっても、「テスト観点を、書く」というのは、なかなか無いんじゃないかなと思いまして。
更にいうなら、ご担当になっている「ルクミー請求管理」という請求管理業務のプロダクトとなると、
- 一機能のボリュームも多く、
- 複雑なロジックも考慮して、
- 細かい計算の内訳（内税、外税とか）も絡む etc...
考慮事項を考えるだけでも沢山あるプロダクトの、それも「テスト観点を考える」となると、並大抵のことじゃぁないのではと。
5回も書き直した形跡から、その大変さは並大抵のことではなかったことがうかがえました。
開発プロセスの品質改善は、他にもやり方や手段があるでしょうけれど、「テスト観点を出してみる」ところから改善の糸口を探すその姿勢から、さとうさん*4の知的好奇心には、目を瞠る（みはる）ものがあります。
あとは、純粋にQAエンジニア以外の人がテスト観点を作ってくれたことが、嬉しかった。
誰に言われたわけでも頼まれたわけでもなく、能動的に自ら弊社の行動指針にある「OneMoreStepの精神」を持って行動されていたことに、ただただ嬉しかった。
あれ？
いつの間にか、さとうさんの他己紹介みたいになってる？（笑）
まぁ、何がモチベーションになったというと、"QAエンジニア以外の人がテスト観点を作ってくれた"その意気に応えよう！ということで、今回の記事を書いた次第です。
書いてくれたテスト観点を、見てみる
前フリが長くなりましたが、仕切り直して、技術ブログらしくここからは「どのように具体→抽象→具体という形で、AIエージェントといっしょにテストを書いていったのか？」について品質保証技術の視点から解説していこうと思います！
作ってくれたテスト観点を見てみると、以下のような構成になっていました。
テスト観点の内容（クリックすると展開されます）
# 機能一覧 1. 機能1 2. 機能2 3. 機能3 4. 機能4 # 1. 機能1 ## 1.1 テスト対象 ### 1.1.1 テスト観点の大枠 #### 1.1.1.1 テスト観点の詳細 - 期待値1 - 期待値2 #### 1.1.1.2 テスト観点の詳細 - 期待値1 - 期待値2 .....（中略） ### 1.1.2 テスト観点の大枠 #### 1.1.2.1 テスト観点の詳細 - 期待値1 - 期待値2 #### 1.1.2.2 テスト観点の詳細 - 期待値1 - 期待値2 .....（中略） # 2. 機能2 ## 2.1 テスト対象 ### 2.1.1 テスト観点の大枠 #### 2.1.1.1 テスト観点の詳細 - 期待値1 - 期待値2 #### 2.1.1.2 テスト観点の詳細 - 期待値1 - 期待値2 - 期待値3 .....（中略） ### 2.1.2 テスト観点の大枠 #### 2.1.2.1 テスト観点の詳細 - 期待値1 - 期待値2 - 期待値3 #### 2.1.2.2 テスト観点の詳細 - 期待値1 - 期待値2 - 期待値3 - 期待値4 - 期待値5 - 期待値6 .....（中略）
と各機能に対して上記のような書式で「4. 機能4」に至るまで、機能テストの観点が記述されていました。
また、他のテストレベルごとに、
テスト観点の内容（クリックすると展開されます）
# 5. 結合テスト ## 5.1 機能間連携 ### 5.1.1 結合テストの観点 - 期待値1 - 期待値2 - 期待値3 ### 5.1.2 結合テストの観点 - 期待値1 - 期待値2 - 期待値3 .....（中略） # 6. データ整合性テスト（全体） ## 6.1 整合性テスト観点の大枠 ### 6.1.1 整合性テスト観点の詳細 - 期待値1 - 期待値2 .....（中略） # 7. 制約事項のテスト ## 7.1 制約事項のテスト観点 - 期待値1 - 期待値2 .....（中略）
という形で記述。
さらに、
テスト観点の内容（クリックすると展開されます）
# 8. テスト実施方針 ## 8.1 テスト環境 <ここにテスト環境に関する情報が掲載> ## 8.2 テストデータ <ここにテストデータに関する情報が掲載> ## 8.3 テスト実行 <ここにテスト実行に関する情報が掲載> # 9. テスト結果管理 ## 9.1 結果記録 .... ## 9.2 改善活動 ...
と、テスト観点以外の情報も記述していました。
それらも含め、さとうさんが作ってくれたテスト観点の全量、
なんと700行超え！
ヮ(ﾟдﾟ)ォ!
いやいや、さとうさん！
パねえっす（笑）
うん、パねえっす（笑）
そして、さとうさん。頑張った。
すごく。頑張ったんだなぁ（感慨深い）。
自分でも今までのキャリアで、一機能のテスト観点をここまで書いたこと、無いっす（笑）
さて、"さとうさん"の汗と涙と「なにか」の結晶とも言える気合の入ったこのテスト観点は、今回の技術ブログでは、好都合ってなもので。
ここから、「具体→抽象→具体という形で、AIエージェントといっしょにテスト」を、書いていきます！
実際に、やってみた
さとうさんが作成したテスト観点は、いわば「具体化されたもの」とみなすことができます。
んで、ここで登場するのが、弊社QA課の"はなみさん"が投稿した↓の記事*5
要は、抽象化することによって「共通認識を言語化できる」と考えたからです。
そして、それはテストプロセスにも当てはまると、考えています。
個人的な哲学になりますが、「テストプロセスの上流〜下流の流れで、"抽象"→"具体"」して、テストに必要なものを言語化していくとも、考えています。
テストプロセスについては、たかだが過去に投稿した↓の記事
を、読んでいただければと思います。
そんなこんなで、「抽象化」するとなったら、そう！
AIエージェントの出番です！
なんてったって、「要約」に関して力を発揮してくれるのがAIエージェントじゃぁ、ないですか！
ということで、以下の環境・ツールを使って「具体→抽象」してテスト計画書を、「抽象→具体」でテスト設計書を作ってみました！
【環境】
spec-kitには、以下のように構成したファイル群を置いています。
.specify/
├── memory/
│ ├── constitution.md
│ └── iso25010-quality-dictionary.md
├── scripts/
│ └── bash/
│ ├── check-prerequisites.sh
│ ├── common.sh
│ ├── create-new-feature.sh
│ ├── setup-plan.sh
│ └── update-agent-context.sh
└── templates/
├── agent-file-template.md
├── checklist-template.md
├── confluence_templates_update.md
├── plan-template.md
├── production_issue_highest_template.md
├── prompt/
│ ├── prompt_fixed.md
│ ├── prompt_full_login.md
│ └── prompt_variable_login.md
├── spec-template.md
├── tasks-template.md
├── test-design-template.md
├── test-execution-template.md
├── test-implementation-template.md
└── test-report-template.md
そして.specify/以降は、以下の内容でルール化したファイルを格納しています。
.specify/の内容（クリックすると展開されます）
1. memory/ - プロジェクトの憲法と品質辞書
constitution.md
プロジェクトの基本原則を定義した憲法文書：
- テストファースト原則（交渉不可）：TDD必須、Red-Green-Refactorサイクル
- Bolt運用原則：短サイクル反復（数時間〜半日単位）での意思決定と証跡の局所化
- WYSIWID原則（SDT原則）：
- Principle of Persona（Who - 誰の視点か）
- Principle of Causality（Why & Time - 構造的因果）
- Principle of Generative Coverage（Action - 生成的カバレッジ）
- テスト標準：細かい粒度の観点記述、固定列形式、バージョン管理
- SDAT Tech Stack：Brain（Cursor + spec-kit）、Auto Exec（Playwright/Vitest）、Manual Exec（Browser Recorder）
iso25010-quality-dictionary.md
ISO/IEC 25010 品質特性を測定可能なQuality Propertyに翻訳する辞書：
- 品質特性→副特性のマッピング
- 各副特性をテスト可能な「性質」に変換するテンプレート
- 機能適合性、性能効率性、セキュリティなど8つの品質特性を網羅
- チェックリストではなく、機能ごとに必要な品質プロファイルを選択して使用
2. scripts/bash/ - ワークフロー自動化スクリプト
common.sh
すべてのスクリプトで共有される基盤関数： - リポジトリルートの検出（Git/非Git対応） - ブランチ情報の取得 - feature dirのパス解決（番号プレフィックスベースの柔軟なマッチング） - 環境変数管理
create-new-feature.sh
新機能ブランチとspec構造を作成： - ストップワードフィルタリングによる賢いブランチ名生成 - 既存ブランチとの重複チェック - spec-template.mdのコピー - GitHub 244バイト制限への対応
setup-plan.sh
実装計画（plan.md）のセットアップ： - plan-template.mdをコピー - JSON出力対応
check-prerequisites.sh
前提条件の統合チェック： - plan.md、tasks.mdの存在確認 - 利用可能なドキュメント（research.md、data-model.md等）のリスト化 - JSON出力モード、paths-onlyモード対応
update-agent-context.sh
AIエージェントのコンテキストファイル更新： - plan.mdから技術スタック情報を抽出 - Claude、Gemini、Copilot、Cursor、Qwen等、複数AIエージェントのファイル更新 - テンプレートベースの新規作成と既存ファイルの段階的更新
3. templates/ - 各種テンプレート群
開発ワークフロー系
- spec-template.md：機能仕様テンプレート（Concepts、Syncs、WYSIWID原則ベース）
- plan-template.md：実装計画テンプレート（技術コンテキスト、憲法チェック、フェーズ別計画）
- tasks-template.md：タスクリストテンプレート（ユーザーストーリー別に整理）
テスト設計系
- test-design-template.md：テスト設計書（Bolt Context、Quality Profile、Viewpoint Matrix）
- test-execution-template.md：テスト実行テンプレート
- test-implementation-template.md：テスト実装テンプレート
- test-report-template.md：テストレポートテンプレート
プロンプト系（prompt/）
- prompt_full_login.md：ログイン機能のテスト設計用プロンプト例
- prompt_variable_login.md：変動可能なログインプロンプト
- prompt_fixed.md：固定プロンプト
その他
- agent-file-template.md：AIエージェント用の開発ガイドラインテンプレート
- production_issue_highest_template.md：本番障害報告書テンプレート（直接原因/根本原因の分離、SDAT回帰統合）
- checklist-template.md：チェックリストテンプレート
- confluence_templates_update.md：Confluence更新テンプレ
上記の中身の解説は、今回の記事では割愛させていただきます。
※今後の投稿で、中身の解説はしていこうかと。
さて、上記spec-kitの設定から、以下のプロンプトを投げてAIエージェントにspec.mdという「テスト仕様が記述されたファイル」を出力してもらいます。
あなたは熟練のQA兼テスト設計者です。 <さとうさんが作成したテスト観点の格納先リンク>を参照して、「AIエージェントと共創して」手動テストのテスト計画書を作ります（手順はこのフェーズでは書かない）。 やること: - ユーザーストーリーを Concepts と Syncs に分解する（Actionsは書かない） - Who(観測者/権限) と Why(意図/不変条件) を必ず明示する - （非機能がある場合）ISO/IEC 25010 の副特性を参照し、測定可能な Quality Property（尺度/条件つき）として定義する 出力: 1) spec.md（.specify/templates/spec-template.md の構造で） 制約: - 断定できない前提は「仮定」として列挙する - （非機能がある場合）spec.md の Quality Profile（ISO25010）と、test-design.md の ISO25010 Tag を埋める
上記のプロンプトから出力されたspec.mdは、以下の構成になっております。
spec.mdの内容（クリックすると展開されます）
# Feature Specification: <大まかな機能名が掲載> <!-- 🔥🔥 VIBE TESTING PHILOSOPHY CHECK 🔥🔥 Before writing this spec, ask yourself: 1. Is this "Simple" (Architecturally clear) or just "Easy" (Lazy)? 2. Are you defining "Why" (Structure), or just throwing "What" at the AI? 3. Are you reinventing manual labor, or engineering quality? --> **Feature Branch**: `<機能名が掲載>` **Created**: <作成日が掲載> **Status**: <作成状況が掲載> **Input**: <入力したインプット資料の概要が掲載> ## Assumptions（仮定） - 成果物は「手動テスト計画書（spec.md）」で、E2E手順や詳細ケースは後続フェーズに記載する。 - 仕様未記載で★かつ確率<30%の項目は、下記「低確度の仮定」に列挙する。 ### 低確度の仮定（仕様未記載・確率<30%） <ここに、"仕様未記載で★かつ確率<30%の項目"が一覧で列挙> ## 1. Concepts (Where) - The Actors & Objects <!-- V1: 最低限の Concept 情報だけを定義する --> ### <Feature 1>（Featureの概要） - **Purpose**: <テスト目的が掲載> - **Who (Access Policy)**: <ユーザーの属性が掲載> - **State**: - <Syncs 1> (flagやstate) - <Syncs 2> (Shown/Hidden) - <Syncs 3> - <Syncs 4> (Used/Unused) ..... --- ## 2. Synchronizations (What) - The Scenarios <!-- V1: 優先度と Layer を 1 つだけ付けた Sync 一覧を簡潔に書く --> <!-- 事前に「「構造的Why」…」パターンで1行プロンプトを作り、それを分解して記載する --> ### User Story 1 - <ユーザーストーリーを元にしたテスト観点が掲載> (Priority: P1) <大まかな期待値："誰が" "どのように操作して" "どうなるか"が掲載> **Who (Observer/Access)**: <ユーザーの属性、タイプが掲載> **Why (Intent/Invariant)**: <テスト目的が掲載> **Acceptance Scenarios (Synchronizations)**: 1. **Scenario**: <テストシナリオが掲載> - **Layer/Priority**: <UIなのかデータなのか、テスト対象のレイヤーが掲載>/ <優先度が掲載> - **Given** <事前条件が掲載> - **When** <操作が掲載> - **Then** <期待値が掲載> ... --- ## 3. Who / Why（Context） - **Who（Persona / Access Policy）**: <ユーザーの属性、タイプが掲載> - **Why（Purpose）**: <テスト目的が掲載> --- これ以降は、リスク要件・想定される非機能要件・定量的な品質メトリクスなどがつづく
Markdownプレビューでは、以下のようにspec.mdを見ることができます。
出力したファイルの中身にある、Concepts (Where)は「テスト対象」を。
Synchronizations (What)は、「テスト観点」を表しています。
んで、このspec.mdをインプットとして、test-design.mdを出力します。
test-design.mdを出力する時の、プロンプトは以下の通り。
# === 固定 === あなたは熟練のQA兼テスト設計者です。 @spec.md を元に、「AIエージェントと共創して」手動テストのテスト設計書を作ります（手順はこのフェーズでは書かない）。 やること: - ユーザーストーリーを Concepts と Syncs に分解する（Actionsは書かない） - Who(観測者/権限) と Why(意図/不変条件) を必ず明示する 出力: 1) test-design.md（.specify/templates/test-design-template.md の構造で / Viewpoint Matrixまで） 前提（このデモの作業ディレクトリ）: - spec.mdを参照する。テンプレ参照は `.specify/...` とする 制約: - 断定できない前提は「仮定」として列挙し、質問があれば最後にまとめる - test-design.md では Then Property（満たすべき性質）を必ず書く - Viewpoint Matrix は最低2行（成功/失敗）を作る - Concepts 名は spec.md内に掲載している語句から作成すること（必要なら補助Conceptを追加してよい） # === 変動 === スコープ内: - 一旦は、spec.md内に掲載しているものをベースに作成する スコープ外: - 「低確度の仮定（仕様未記載・確率<30%）」の項目は、確認事項としてみるため一旦設計書作成のスコープ外とする ユーザーストーリー: - User Story 1 - <ユーザーストーリー その1> - User Story 2 - <ユーザーストーリー その2> .....（この後、ユーザーストーリーが続きます） Why（構造的Why）: <システム内の因果関係を元に、不変条件（Property）を明示> Who: 園管理者/園スタッフ（請求管理権限）, 保護者（L4F閲覧）の視点で作る。
このようにAIエージェントに指示してたら、test-design.mdは以下の構造で、出力されます。
test-design.mdの内容（クリックすると展開されます）
# Test Design Document: <大まかな機能名が掲載> **Input Spec**: `spec.md` **JIRA Ticket**: TBD **Status**: IN PROGRESS **Author**: QA+AI Co-Design ## Bolt Context（AI-DLC） - **Bolt**: Bolt 1-2 - **Target Platform**: <テスト対象のプラットフォーム> - **Primary Who**: <ユーザーの属性が掲載> - **Key Syncs**: <重要となる、テスト観点IDが掲載> ## Story Decomposition (Concepts & Syncs) | User Story | Concepts | Syncs (Scenario) | | --- | --- | --- | | User Story 1 - <ユーザーストーリー 1 の内容>| <機能名 1> | <機能名 1のざっくとしたテスト観点 1> | | User Story 2 - <ユーザーストーリー 2 の内容> | <機能名 2> | <機能名 2のざっくとしたテスト観点 2> | ..... ## 0. Critical Thinking Check (Design Verification / V1) - [ ] Edge cases やエラー経路も 1 つ以上含まれている - [ ] Sync 同士が明らかに矛盾していない - [ ] 各 Viewpoint に対応する Who / Why が 1 行ずつ書かれている ## 1. Common Preconditions (Shared Context) - **Environment**: Staging - **Data Setup**: <用意するテストデータの一覧が掲載> - **Assumptions（仮定）**: <未定義、またはまた決まっていない内容が掲載> ## 1.5 Quality Profile (ISO/IEC 25010)（Optional, but recommended） **Quality Dictionary**: `.specify/memory/iso25010-quality-dictionary.md` | Priority | ISO25010 Tag | Target Concepts | Quality Property（測定可能な性質） | Budget / Threshold | Conditions（Env/Load/Data/Observation） | Evidence（Log/Metric/Trace/Screenshot） | | --- | --- | --- | --- | --- | --- | --- | | P1 | <品質特性> | <テスト対象の機能名> | <測定可能な性質が掲載> | <品質達成の目標値> | <テスト条件>| 出力ファイル+画面 | .....（表が複数作られる） ## 2. Concepts Definition (Test Objects) | Concept ID | Name | Type | Responsibility | | --- | --- | --- | --- | | **<機能ID 1>** | <機能名> | <テストの種類> | <期待値の概要> | .....（表が複数作られる） ## 3. Viewpoint Matrix (Synchronizations / V1 最小構成) | ID | Viewpoint (Scenario) | Target Concepts | Method (Small/Medium/Large) | Condition (Given) | ISO25010 Tag | Then Property（満たすべき性質） | Case Count | Remarks | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | **<観点ID>** | <テスト観点> | <テスト対象> | <テストレベル> | <事前条件> | <満たすべき品質特性> | <期待値> | <想定ケース数> | Who: <ユーザーの属性> / Why: <テスト目的> | .....（表が複数作られる）
Markdownプレビューでは、以下のようにtest-design.mdを見ることができます。
やってみてどうだった？
結果、以下のようになりました！
| 【さとうさんVer.】テスト観点数 | 【たかだVer.】テスト観点数 |
|---|---|
| 100 | 12 |
おおっ、約1 / 8にまで圧縮できた！！
要約力に関しては、AIエージェントの力を存分に発揮できたのではないかと、思ってます！
ただ要約した分、本来別の観点であるものが「どこかのテスト観点に吸収されている感」がありそうとも思ってまして。
そこらへんは、一旦AIエージェントが出力してもらったものに人間側のほうで追記するとか、テスト設計の後に続く「テスト実装」のほうで調整したりと、色々と工夫をして対応できる余地はあるな〜と考えてます！
何が嬉しいん？
今回、「AIエージェントといっしょに、テストを書く= "SDAT*8"」によって、以下のことを可能にしてくれると考えてます。
- "シフトレフト"の促進（開発前にテストを書いて、お互いの認識に対して平仄を合わせる）
- "テストファースト"で考えるため、XP（エクストリームプログラミング）やTDD（テスト駆動開発）のように進めつつ、成果物の確度を向上させる
- AIエージェントといっしょに "SpeedDriven" に動きつつ、作成されたテスト成果物を元に "PlayFair" に議論を進めつつ、"OneMoreStep" なプロダクトを開発するベースメントの構築
QAエンジニアは、「情報整理の鬼」であると常々思っています。
特に「要約する力」「詳細化する力」といった「具体 ⇔ 抽象を使った問題・課題の導出力」は、群を抜いていると考えています。
あとは、そこに「能動的に行動する力」や「批判的思考力」が合わさったら。もう、つよつよなわけで
そんな鬼を味方につければ、「鬼に金棒」*9ってもんでしょ？
Topics
今回紹介した「AIエージェントといっしょに、テストを書く= "SDAT*10」に関連した記事は、以前投稿した↓の記事
を、ご覧いただければと思います。
また去年、私が12/16にWake Careerさん主催のオンライン登壇した「なめらかな"品質保証"とその敵｜QAの本質とAI活用テスト設計」にて、アーカイブ動画を展開していますので、「デモを見たいんだっ！」って方は、お時間あるときにご覧いただければと思います。
「動画を観る時間が、ない！」という方は、スライドを↓にリンクしてますので、そちらをご覧ください。
おわりに
如何でしたでしょうか？
今回は、AIエージェントと一緒に「具体→抽象→具体」で、テストを書いたことを記事にしました！
お役に立てられれば、幸いです！
「ここには「挑戦、失敗、分析、修正、再挑戦」のサイクル、そして努力し、自らを磨きつづけようとするやり抜く力の大切さが見事に表現されている。ビル・フラックは「永遠のベータ」だ。そしてそれも彼が超予測者である所以なのだ。」フィリップ・E・テトロック＆ダン・ガードナー 著、土方 奈美 監訳：超予測力 不確実な時代の先を読む10カ条 より
今回も、最後まで読んでいただき、ありがとうございます！
では、また！
ユニファでは家族の幸せを生み出すあたらしい社会インフラを一緒につくっていく仲間を大募集しています！
気になる方はぜひこちらのサイトもチェックしてみてください！！
*1:5分間のウォームアップしてから、「4分間の全力ワークアウト→3分間のインターバル」を4回やり、5分間のクールダウンをする"鬼レベル"のトレーニング。もう、そりゃぁ.........キっツイのよ！
*2:釣り好きで、ウィットなジョークをさらっと言う、百戦錬磨の兵（つわもの）
*3:再掲：釣り好きで、ウィットなジョークをさらっと言う、茶目っ気たっぷりの百戦錬磨の兵（つわもの）
*4:再々掲：釣り好きで、ウィットなジョークをさらっと言う......て、さすがに天丼が過ぎますね。失敬！。兎にも角にも、何が言いたいかって「すんげえ頼りになるマネージャー」ってこと。
*5:「WACATE」という、若手のテストエンジニア中心で夏と冬、年2回行われるワークショップ。この記事は、はなみさんがWACATEに参加したときに出会った本や実際のワークショップから得たインサイトが掲載されています
*6:https://cursor.com/ja?from=home
*7:https://github.com/github/spec-kit
*8:Structure-Driven Agentic Testingの略。高田が命名しました
*9:この前あった、節分に掛けてます
*10:追記：旧 "Vibe Testing"と呼称していたもの。"Vibe = ノリ"でテストするというネーミングは、ちょっと避けたかったため、これからは「SDAT」と呼びます
