AIネイティブなSIカンパニーを目指すSHIFTでは、社内においてAIの利活用はもちろん、さまざまなAIサービス・ソリューションの開発を強力に推進しています。
なかでも、品質保証事業の根幹を支えるテスト設計ツール「TD（Test Designer）」では、AIがテストケースを生成してくれる「TD AI Assistant」機能を実装し、現在、テスト設計の高速化・高品質化に向けたPoCに取り組んでいます。
今回は、このTD AI Assistantの開発・実装・社内普及を進めるサービスプラットフォームグループのグループ長と担当者に、設計にあたってのポイントや今後に向けた未来予想図などについて話を聞きました。
-
サービスプラットフォームグループ グループ長 森川 知雄
中堅SIerにて品質管理業務を担当。テスト戦略から人材育成までを担当する。テスト自動化技術Seleniumに出会い、テスト自動化ツールをスクラッチ開発し、テストコストを最大40%削減。以後、テスト自動化～DevOpsといった技術に将来性を感じる。2019年、新しいことに挑戦できる環境を求めてSHIFTへジョイン。統合型ソフトウェアテスト管理ツール「CAT」やテスト設計支援ツール「TD」の開発・運営を担うCAT推進室 室長を経て、2023年9月より現職。
-
サービスプラットフォームグループ 越川
新卒の頃から品質関連の業務に携わり、2015年SHIFT入社。PM／PMO、さらにはお客様への提案も担う。現在はテスト設計支援ツール「TD」のプロダクトマネジメント担当として、社内におけるTDおよびTD AI Assistantの普及・定着に向けて取り組んでいる。社外活動としてソフトウェアテスト技術振興協会（ASTER）のスタッフをしていたことも。
目次
業務効率化と属人化防止による「品質向上」を目指して開発
――今回は「TD AI Assistant」の取り組みについて伺いたいのですが、その前に、まずは「TD」というツールについて教えてください。
森川：TDは、システム開発におけるテストの設計を支援するツールで、SHIFTが自社開発しているプロダクトです。
弊社のテスト設計手法は、これまでの実績から生まれた標準観点を使いながら設計の段階を分割することで、レビューと設計の両方を効率化するように組み立てています。
森川：もともとはこれらの作業をExcelベースでやっていたのですが、「Webアプリにできるよね」「システム化したらテスト実績データが溜まっていっていろいろと活用できるよね」といった流れから開発されたのがTDです。
TDのテスト設計画面。上画像の色分けされた部分のように階層表現でテストが設計できるようになっている
越川：経験の浅い方がテストを設計しようとすると、一般的にはほかの方がつくったテスト内容を参照しながらつくることが多いと思います。
それに対してTDを使うことで、たとえばどういうテストをしたいのかというテスト観点の候補や、それに紐づくそのほかのテスト観点が一覧で表示されるので、そこから選択できるようになります。
たとえば「表示」に関するテスト観点を設計したい場合、上画像のような候補が表示される
越川：選択していくだけで一般的なテスト観点の項目は埋まるので、あとはそれらに対して「どうなるか」という期待値を人が入力していくことで、スキル／経験の差によらず、ある程度は同じ粒度のテスト計画をつくることができるようになります。
もちろん、過去に作成したテスト計画を別プロジェクトに呼び出すこともできます。
――なるほど。テスト設計における属人性を一気に減らすことができるわけですね。
森川：あともう一つ、管理者向けには、設計したテスト観点をリアルタイムで集計・表示する画面も推しポイントです。
こちらをチェックすることで、テスト計画の方向性と実際の設計内容のズレの有無／大きさが確認できます。
たとえば「今回は特に画面遷移を重点的にチェックしたい」と考えていたにも関わらず、集計結果で画面遷移のテスト観点が少ないと、テストの目的と実態がズレていきます。
そのような事態を防ぐ意味でも、この集計画面を有効活用いただきたいと考えています。
テスト設計の各段階でAIが内容をリコメンドしてくれる
――つづいて、TD AI Assistant機能についても教えてください。
森川：先ほど、テスト設計の段階を分割しているとお伝えしましたが、それぞれの段階のプロセスに対して、都度AIがリコメンドしてくれるような機能になっています。
越川：画面を見ていただいた方がわかりやすいと思うので、まずは一連の流れに沿ってご紹介しますね。
最初に、AIで読み取り可能な仕様書を作成します。
画面レイアウトを定義した資料があれば、仕様書マルチモーダルAI機能によってそのファイルに配置されたスクリーンショットなどが文字として認識され、Markdown形式で作成されます。
画面定義書などの仕様書から生成されたTD AI Assistant取り込み用の仕様書例
越川：AIで読み取り可能な仕様書ができたら、それをTD AI Assistantに取り込み、画面の区分（コンポーネント）情報を展開します。
ここは仕様書に沿って最初にAIが自動作成してくれますが、必要に応じて人が追記／修正／削除などをすることもできます。
越川：各区分が整ったら、それぞれに対するテスト観点と確認項目、期待値、それからテストパターンの内容も、AIに生成してもらいます。
ここについても、AIのリコメンドに対して人が自由に追記／修正／削除などをすることができます。
越川：このように、AIのリコメンドに対して人がチェック・チューニングしていく流れでテスト設計を進めるという流れです。
SHIFTの独自AIモデルを駆使して、圧倒的な効率化を目指す
――いま教えていただいたような生成AIの機能を、TDに実装することになった背景を教えてください。
森川：2023年ごろに、SHIFTがもつ膨大なテストデータを有効活用しようというプロジェクトがはじまり、その一環で取り組みはじめたのが生成AIの活用でした。
これまで作成したテストケースの実績は1億1,451万件以上（※2025年1月時点）あり、標準テスト観点も900項目用意できているので、グループ会社でAI関連の技術に強いDeMiAとも協力して独自AIモデルをつくりながら、これらのデータをテスト設計業務に活用し、圧倒的な効率化を目指そうと考えたわけです。
※SHIFTの独自AIモデルについては以下の記事もご参照ください。
――TD AI Assistant機能を追加するにあたって、苦労された部分を教えてください。
森川：TD AI Assistantではテスト設計の各段階でAIモデルを使っているのですが、当初はすべてにおいて独自モデルを利用する想定でした。
でも、テストパターンのところだけはチューニングがなかなかうまくいかず、弊社で溜めてきたデータをそれほど有意に活用できなかったので、結果としてGPT-4oを使うことになりました。
このあたりの検証と判断は、けっこう大変でした。
あと、AI関連プロジェクトではよくあることですが、きちんとテスト設計に役立つようなデータに最適化する部分も、DeMiAといっしょにプロジェクトを進めるなかで勘所を掴むのに時間がかかりましたね。
――AI機能を導入した効果はいかがでしょうか？
森川：リリースして間もないので絶賛検証中ではありますが、属人性の排除には効果を期待できそうです。たとえば、いままで有識者が3名必要だったところが、有識者1名と新人2名で行けるようになるのでは、と予想しています。
中長期的には品質を上げるためのオブザーバビリティも追求していきたい
――このようなAIプロジェクトをSHIFTが進めることの強みは、何だと思われますか？
森川：AIのような新しいものに対して感度高くしっかりと耳を傾けてくれ、さらには布教までしてくれる人たちがいるという「環境面」での強みが大きいと思います。
やると決めたら、ものすごいスピード感で進めますからね。あと、先ほどもお伝えしたとおり、SHIFTグループ全体で蓄積してきた膨大なテストデータは、圧倒的な差別化につながっていると感じます。
AIにおいては特に、データをもっていることが大きな強みになりますからね。
――今後、TD AI Assistantで取り組みたいこと／チャレンジしたいことを教えてください。
越川：現在、SHIFTのテスト設計におけるAI活用をまとめたものがこちらの図になります。実はテスト設計の前段階として、お客様がもつ仕様書の抜け漏れチェックなども、SHIFTの方で行っています。
越川：そのうえで、先ほどご紹介したAIと人の協働作業を通じてテスト設計書を作成したら、それを元に人がテストを実行し、不具合の分析などを行うという流れになっています。
これに対して中長期的な未来予想図としては、以下の図にある通り、蓄積してきた不具合情報やお客様がもつドメイン情報を元にしたRAGを構築・活用することで、そのほかのさまざまな業務にもAIを活用していきたいと考えています。
仕様書を元にしたテスト方針の策定や、生成されたテスト設計書の抜け漏れチェックとテスト項目の強化、テスト実行後の分析、さらにはテスト計画に準拠した見積書の作成など、AI活用によるテスト支援の幅を広げていきたいところです。
森川：まだ外販前に解決すべき課題はあるのですが、今年を皮切りに進むであろうAIエージェントの波を受けて、もっとシンプルにオペレーションができるツールにしていけるだろうと想定しています。
あと、将来的にはオブザーバビリティ領域にも切り込んでいきたいと思っていて、プロダクトの画面ログを解析してテスト項目に反映することで、「使ってもらえるプロダクト」のためのフィードバックサイクルを確立できるだろうなと。
弊社がやるからには、品質を上げるためのオブザーバビリティを活用していこうと考えています。
（※本記事の内容および取材対象者の所属は、取材当時のものです）
