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では、そんな世界を共に楽しめる仲間を募集しています。興味のある方はぜひエントリーいただければ幸いです。本記事についてもカジュアルに話したい方は是非！
*1:カバレッジ基準についてはCapers Jones氏のペーパーを参考に設定しています。
