品質の言語化のススメー早期テストの原則をClaude Code Agent Skillsで実現する試み
LayerX は、JSTQB の「早期テスト」原則を言語化し、Claude Code Agent に品質基準やリスク管理の判断基準（Skills）として付与することで、AI によるコード生成と自動テスト作成の質を向上させる実証事例を紹介している。
キーポイント
早期テスト原則の AI 適用
JSTQB FL の「早期テストで時間とコストを節約する」原則を、AI コーディングアシスタントがコード生成段階から適用できるよう設計思想として組み込んだ。
品質判断基準の言語化（Skills）
AI が自律的に判断できるよう、「目指す品質」「リスクと基準」「自動テストのスコープ」という 3 つの判断基準を明確に定義し、システムプロンプトや Skills に実装した。
リスクベースの実践的アプローチ
AI に「今守るべきリスク」や「リスクに応じた作成基準」を思考させることで、過剰なテストや不十分なエラーハンドリングを防ぎ、開発コストと品質のバランスを最適化する。
フェーズ別品質方針の定義
プロダクトのフェーズ（市場投入前か運用中か）に応じて優先すべき品質側面を明確に言語化し、AI に伝える方針を策定している。
プロダクト固有リスクとカバレッジ基準の設定
コンパウンド戦略下での各プロダクト固有のリスク（Severity と影響範囲）を Skills 上で定義し、Capers Jones氏の知見に基づきカバレッジ基準を設定している。
テストピラミッドの再言語化
既存のテストピラミッド戦略に加え、各レイヤーでの検証責務をより詳細な粒度で更新し、自動テストの内容とスコープを明確にしている。
AIによる自動フェーズ判断とHITL
Claude Code はタスク内容からプロダクトのフェーズを自動的に判断し、不明な場合は人間（HITL）に質問する仕組みで柔軟に対応します。
影響分析・編集コメントを表示
影響分析
この記事は、単なる AI ツールの利用報告を超え、従来のソフトウェアテストの理論（JSTQB）を現代の生成 AI エージェントにどう組み込むかという「プロンプトエンジニアリング」や「エージェント設計」の実践的な指針を示しています。開発現場において、AI の出力品質を安定させるためには、ツールの機能だけでなく、人間の専門知見を言語化してシステムに埋め込むプロセスが不可欠であることを示唆しており、実務家にとって非常に参考になる事例です。
編集コメント
AI エージェントの能力を最大化するには、単なる指示ではなく「品質基準」という文脈を明確に定義することが重要であるという、実務的な洞察が得られる記事です。
LayerX QAエンジニアの小山です。
昨今、AIコーディングアシスタント（特にClaude Code等）の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか？
今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。
ソフトウェアテストの原則「早期テストで時間とコストを節約する」
筆者はJSTQB FLの公認コースのトレーナーを15年ほどしているのですが、JSTQB FLシラバスの中に「テストの原則」として7つの原則があります。その中の1つとして「早期テストで時間とコストを節約する」というものがあります。
この原則はプロセスの早い段階で欠陥を取り除くと、後半に発生する故障が少なくなり、結果的に品質コストが削減される。そのため早い段階で欠陥を見つけるために静的テスト（Static Testing）と動的テスト（Dynamic Testing）の両方をなるべく早い時期に開始すべきであるというものです。
これはテストの実行だけを意味するものではなく、要件のレビューや質問なども含めた活動を意味します。つまりは最もコスパが良いのは欠陥の予防であり、できるだけ早くフィードバックをするアジャイル開発とも親和性が高い原則です。
この原則をClaude Codeが動く時に適用したいと考えました。
skillsに盛り込む判断基準
どうすれば予防ができるのか？を考えると、AIが予防をするための判断基準をいくつか言語化する必要があります。本skillsでは以下の判断基準を持たせるようにしました。
- 目指す品質
- 目指す品質を判断するためのリスクと基準
- 自動テストのスコープ
上記を定義することで、コードを書くときやテストを書くとき、レビューをするときやテストを検討する際にコンテキストに応じてAIが以下のように思考し、動くことができます。
- 今目指すべき品質のゴールは何か
- 今守るべきリスクは何か
- リスクに応じてどのくらいの基準で作るか
- それぞれの自動テストで担保すべきスコープは何か
目指す品質の言語化
私たちが目指すゴールイメージをAIに伝えるため、目指す品質の言語化を行いました。バクラクは経済をデジタル化するプロダクト群であり、お客様のセンシティブな情報を預かるプロダクト群のため、一定以上の品質の水準をキープする必要があります。加えて高頻度でリリースを行うことも同時に目指しています。品質をキープするためにコーディング規約などさまざまな取り組みをしていますが、その一環としてプロダクトのフェーズごとに異なる「バクラク事業部が目指す品質」を定義しました。定義の内容の具体についてここでの言及は避けますが、プロダクトのフェーズによって変わる品質の側面において何を優先すべきかといった方針を定義しています。市場にリリースしてフィードバックを集めたいプロダクトのフェーズと、すでに運用状態にあるプロダクトのフェーズでは大事にするポイントが違う、ということを言語化しています。
リスクと基準の言語化
必ずJSON形式で返してください。translation フィールドのみ。他のフィールド(technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "LayerX QAエンジニアの小山です。
昨今、AIコーディングアシスタント（特にClaude Code等）の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか？
今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。
ソフトウェアテストの原則「早期テストで時間とコストを節約する」
筆者はJSTQB FLの公認コースのトレーナーを15年ほどしているのですが、JSTQB FLシラバスの中に「テストの原則」として7つの原則があります。その中の1つとして「早期テストで時間とコストを節約する」というものがあります。
この原則はプロセスの早い段階で欠陥を取り除くと、後半に発生する故障が少なくなり、結果的に品質コストが削減される。そのため早い段階で欠陥を見つけるために静的テスト（Static Testing）と動的テスト（Dynamic Testing）の両方をなるべく早い時期に開始すべきであるというものです。
これはテストの実行だけを意味するものではなく、要件のレビューや質問なども含めた活動を意味します。つまりは最もコスパが良いのは欠陥の予防であり、できるだけ早くフィードバックをするアジャイル開発とも親和性が高い原則です。
この原則をClaude Codeが動く時に適用したいと考えました。
skillsに盛り込む判断基準
どうすれば予防ができるのか？を考えると、AIが予防をするための判断基準をいくつか言語化する必要があります。本skillsでは以下の判断基準を持たせるようにしました。
- 目指す品質
- 目指す品質を判断するためのリスクと基準
- 自動テストのスコープ
上記を定義することで、コードを書くときやテストを書くとき、レビューをするときやテストを検討する際にコンテキストに応じてAIが以下のように思考し、動くことができます。
- 今目指すべき品質のゴールは何か
- 今守るべきリスクは何か
- リスクに応じてどのくらいの基準で作るか
- それぞれの自動テストで担保すべきスコープは何か
目指す品質の言語化
私たちが目指すゴールイメージをAIに伝えるため、目指す品質の言語化を行いました。バクラクは経済をデジタル化するプロダクト群であり、お客様のセンシティブな情報を預かるプロダクト群のため、一定以上の品質の水準をキープする必要があります。加えて高頻度でリリースを行うことも同時に目指しています。品質をキープするためにコーディング規約などさまざまな取り組みをしていますが、その一環としてプロダクトのフェーズごとに異なる「バクラク事業部が目指す品質」を定義しました。定義の内容の具体についてここでの言及は避けますが、プロダクトのフェーズによって変わる品質の側面において何を優先すべきかといった方針を定義しています。市場にリリースしてフィードバックを集めたいプロダクトのフェーズと、すでに運用状態にあるプロダクトのフェーズでは大事にするポイントが違う、ということを言語化しています。
リスクと基準の言語化"}
目指す品質の言語化はできたのですが、それを適用しようとするとプロダクトごとにカスタマイズをして適用する必要が出てきます。バクラク事業部ではコンパウンド戦略を取っており、複数のプロダクトそれぞれ固有のリスクが存在します。いわゆる severity の度合いとその影響範囲をまとめたものです。このリスクにおいては特定の期間単位で振り返りながらチームでリスクの定義をアップデートする習慣が既に社内にできています。このプロダクト固有のリスクをプロダクトごとに分けて skills 上で定義した上で、カバレッジの基準*1 などを決めました。
自動テストの内容やスコープの言語化
LayerX ではテストピラミッド戦略として、自動テストのレイヤーごとにどのような内容を検証し、確認すべきかを定義しています。こちらの言語化は以前からしていたので新しい取り組みではないのですが、詳しくは
バクラク事業部のテストピラミッド設計 - LayerX エンジニアブログ
をご覧いただければ幸いです。
※こちらのテストピラミッドについても、テストの責務の内容については更新がされており上記ブログよりも詳細な粒度での言語化ができています。
Claude Code への統合：AI が自らフェーズとリスクを判断し適用する
言語化した上記の情報を統合し、Claude Code Agent Skills として実装しました。例えば Claude Code にタスクを依頼すると、Claude Code は以下のように動作します。
フェーズ判断
タスクの内容から、当該プロダクトがどのようなフェーズにあるプロダクトなのかを判断し、不明な場合は HITL(Human In The Loop) でユーザーに質問する形を取ります。
リスク評価
対象の機能カテゴリなどを参考に、リスクを判断します。この機能関連の開発である旨を AI に伝えることで、当該機能のリスクレベルを AI が評価をして徹底度を判断します。全プロダクトのリスク情報を読み込むと compaction(コンテキストの肥大化・圧縮による精度低下) を引き起こすリスクがあるため、開発対象のプロダクトのリスクのみを読む仕組みにしています。
基準の適用
判断したフェーズとリスクレベルに基づき、実装方針、テスト戦略（カバレッジ目標など）加えてコーディング規約を自動適用します。（なおコーディング規約については個別に持たせている方が多いため近いうちスコープから外す予定。）
なおプロダクトの開発だけでなく、テストの計画・設計や自動テストの整備相談などにも柔軟に対応します。筆者は情報を与えた上でテスト計画を立案してもらったり、リスクの高いポイントの洗い出しをしてもらうといった使い方をしています。個人的には企画や設計の段階で「怖いポイント」を提案してもらう方がフィードバックがさらに早くなるのでおすすめです。
結果
実際にこのスキルがある状態でどのような効果が見込めるのかを skill-creator の Evals を使って計測をし、改善効果が見込めることを確認しました。
- 特定のプロダクトのリスクが高い機能を作る、とした場合には Claude Code は自らリスクが高いと判断し、トランザクション管理やロールバック処理、定義した基準のユニットテストカバレッジを目指した堅牢なコードを生成しました。
- 特定のプロダクトの○○と言う機能を作る、仕様はこのような仕様である、という情報を与えた場合には not with skill でのテストカバレッジは 65%、with skill でのテストカバレッジは 95% という結果になりました。
エンジニアは生成されたコードやテストケースを確認し、動作確認をして妥当性を判断したり、チューニングをしたりすることができます。もちろん納得がいかない場合は別のプロンプトで動き直すといったトライ&エラーとフィードバックループを高速に回すことができます。
筆者も既にテスト計画を作ってもらったり、自動テストの整備の優先度を決めてもらったりしているのですが、今のところ悪くない実感を得られています。
終わりに
AI がコードを書く時代において、人間の重要な役割は「あるべき姿を定義（言語化）すること」へとシフトしつつあります。暗黙知になっている品質の姿を言語化し型に落とし込むことで Quality Harness として AI に組み込み、フィードバックループを更に早めることができるようになっています。言語化をしてみようかな、と少しでも思っていただけたなら幸いです。
モデルの性能向上に伴い、スピードと質がどんどん上がっていく世界はもう近いところにきていると考えています。その世界の中でどういったポイントを抑えることで、より良いプロダクトを作る方向に持っていけるか、今後も QA エンジニアとして真摯に考えていきたいと思います。
LayerX バクラク事業部 QA では、そんな世界を共に楽しめる仲間を募集しています。興味のある方はぜひエントリーいただければ幸いです。本記事についてもカジュアルに話したい方は是非！
- 【バクラク】QA エンジニア_ポテンシャル枠 / 株式会社 LayerX
- 【バクラク】QA エンジニア / 株式会社 LayerX
- 【バクラク】シニア QA エンジニア / 株式会社 LayerX
*1: カバレッジ基準については Capers Jones 氏のペーパーを参考に設定しています。
原文を表示
LayerX QAエンジニアの小山です。
昨今、AIコーディングアシスタント（特にClaude Code等）の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか？
今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。
ソフトウェアテストの原則「早期テストで時間とコストを節約する」
筆者はJSTQB FLの公認コースのトレーナーを15年ほどしているのですが、JSTQB FLシラバスの中に「テストの原則」として７つの原則があります。その中の１つとして「早期テストで時間とコストを節約する」というものがあります。
この原則はプロセスの早い段階で欠陥を取り除くと、後半に発生する故障が少なくなり、結果的に品質コストが削減される。そのため早い段階で欠陥を見つけるために静的テストと動的テストの両方をなるべく早い時期に開始すべきであるというものです。
これはテストの実行だけを意味するものではなく、要件のレビューや質問なども含めた活動を意味します。つまりは最もコスパが良いのは欠陥の予防であり、できるだけ早くフィードバックをするアジャイル開発とも親和性が高い原則です。
この原則をClaude Codeが動く時に適用したいと考えました。
skillsに盛り込む判断基準
どうすれば予防ができるのか？を考えると、AIが予防をするための判断基準をいくつか言語化する必要があります。本skillsでは以下の判断基準を持たせるようにしました。
- 目指す品質
- 目指す品質を判断するためのリスクと基準
- 自動テストのスコープ
上記を定義することで、コードを書くときやテストを書くとき、レビューをするときやテストを検討する際にコンテキストに応じてAIが以下のように思考し、動くことができます。
- 今目指すべき品質のゴールは何か
- 今守るべきリスクは何か
- リスクに応じてどのくらいの基準で作るか
- それぞれの自動テストで担保すべきスコープは何か
目指す品質の言語化
私たちが目指すゴールイメージをAIに伝えるため、目指す品質の言語化を行いました。バクラクは経済をデジタル化するプロダクト群であり、お客様のセンシティブな情報を預かるプロダクト群のため、一定以上の品質の水準をキープする必要があります。加えて高頻度でリリースを行うことも同時に目指しています。品質をキープするためにコーディング規約などさまざまな取り組みをしていますが、その一環としてプロダクトのフェーズごとに異なる「バクラク事業部が目指す品質」を定義しました。定義の内容の具体についてここでの言及は避けますが、プロダクトのフェーズによって変わる品質の側面において何を優先すべきかといった方針を定義しています。市場にリリースしてフィードバックを集めたいプロダクトのフェーズと、すでに運用状態にあるプロダクトのフェーズでは大事にするポイントが違う、ということを言語化しています。
リスクと基準の言語化
目指す品質の言語化はできたのですが、それを適用しようとするとプロダクトごとにカスタマイズをして適用する必要が出てきます。バクラク事業部ではコンパウンド戦略を取っており、複数のプロダクトそれぞれ固有のリスクが存在します。いわゆるseverityの度合いとその影響範囲をまとめたものです。このリスクにおいては特定の期間単位で振り返りながらチームでリスクの定義をアップデートする習慣が既に社内にできています。このプロダクト固有のリスクをプロダクトごとに分けてskills上で定義した上で、カバレッジの基準*1 などを決めました。
自動テストの内容やスコープの言語化
LayerXではテストピラミッド戦略として、自動テストのレイヤーごとにどのような内容を検証し、確認すべきかを定義しています。こちらの言語化は以前からしていたので新しい取り組みではないのですが、詳しくは
バクラク事業部のテストピラミッド設計 - LayerX エンジニアブログ
をご覧いただければ幸いです。
※こちらのテストピラミッドについても、テストの責務の内容については更新がされており上記ブログよりも詳細な粒度での言語化ができています。
Claude Codeへの統合：AIが自らフェーズとリスクを判断し適用する
言語化した上記の情報を統合し、Claude Code Agent Skillsとして実装しました。例えばClaude Codeにタスクを依頼すると、Claude Codeは以下のように動作します。
フェーズ判断
タスクの内容から、当該プロダクトがどのようなフェーズにあるプロダクトなのかを判断し、不明な場合はHITL(Human In The Loop)でユーザーに質問する形を取ります。
リスク評価
対象の機能カテゴリなどを参考に、リスクを判断します。この機能関連の開発である旨をAIに伝えることで、当該機能のリスクレベルをAIが評価をして徹底度を判断します。全プロダクトのリスク情報を読み込むとcompaction(コンテキストの肥大化・圧縮による精度低下)を引き起こすリスクがあるため、開発対象のプロダクトのリスクのみを読む仕組みにしています。
基準の適用
判断したフェーズとリスクレベルに基づき、実装方針、テスト戦略（カバレッジ目標など）加えてコーディング規約を自動適用します。（なおコーディング規約については個別に持たせている方が多いため近いうちスコープから外す予定。）
なおプロダクトの開発だけでなく、テストの計画・設計や自動テストの整備相談などにも柔軟に対応します。筆者は情報を与えた上でテスト計画を立案してもらったり、リスクの高いポイントの洗い出しをしてもらうといった使い方をしています。個人的には企画や設計の段階で「怖いポイント」を提案してもらう方がフィードバックがさらに早くなるのでおすすめです。
結果
実際にこのスキルがある状態でどのような効果が見込めるのかをskill-creatorのEvalsを使って計測をし、改善効果が見込めることを確認しました。
- 特定のプロダクトのリスクが高い機能を作る、とした場合にはClaude Codeは自らリスクが高いと判断し、トランザクション管理やロールバック処理、定義した基準のユニットテストカバレッジを目指した堅牢なコードを生成しました。
- 特定のプロダクトの○○と言う機能を作る、仕様はこのような仕様である、という情報を与えた場合にはnot with skillでのテストカバレッジは65%、with skillでのテストカバレッジは95% という結果になりました。
エンジニアは生成されたコードやテストケースを確認し、動作確認をして妥当性を判断したり、チューニングをしたりすることができます。
もちろん納得がいかない場合は別のプロンプトで動き直すといったトライ&エラーとフィードバックループを高速に回すことができます。
筆者も既にテスト計画を作ってもらったり、自動テストの整備の優先度を決めてもらったりしているのですが、今のところ悪くない実感を得られています。
終わりに
AIがコードを書く時代において、人間の重要な役割は「あるべき姿を定義（言語化）すること」へとシフトしつつあります。暗黙知になっている品質の姿を言語化し型に落とし込むことでQuality HarnessとしてAIに組み込み、フィードバックループを更に早めることができるようになっています。言語化をしてみようかな、と少しでも思っていただけたなら幸いです。
モデルの性能向上に伴い、スピードと質がどんどん上がっていく世界はもう近いところにきていると考えています。その世界の中でどういったポイントを抑えることで、より良いプロダクトを作る方向に持っていけるか、今後もQAエンジニアとして真摯に考えていきたいと思います。
LayerX バクラク事業部QAでは、そんな世界を共に楽しめる仲間を募集しています。興味のある方はぜひエントリーいただければ幸いです。本記事についてもカジュアルに話したい方は是非！
- 【バクラク】QAエンジニア_ポテンシャル枠 / 株式会社LayerX
- 【バクラク】QAエンジニア / 株式会社LayerX
- 【バクラク】シニアQAエンジニア / 株式会社LayerX
*1:カバレッジ基準についてはCapers Jones氏のペーパーを参考に設定しています。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み