JaSST’26 Tokyo 登壇レポート
ソフトウェアの品質を可視化し改善につなげる、ODC分析。
この手法は「分類」と「分析」の2つの工程からなりますが、特に前段階の分類は膨大な手作業により全体の8割もの工数を占めるほどの重労働で、現場の大きな負担となっていました。
2026年3月20日に開催され、SHIFTがプレミアムスポンサーを務めた「JaSST’26 Tokyo」。
本イベントに登壇したCATエヴァンジェリスト 石井 優、エグゼクティブ・テストスペシャリスト 山腰 直樹、テストエンジニア 吉澤 麻由の3名は、この欠陥分類にAIを適用し、作業にかかる工数を約2週間からわずか1時間へと劇的に短縮を実現した取り組みを紹介。
AIは自信満々に間違える――。取り組みのなかで直面したこの厄介な壁を突破する鍵となったのは、「あいまいさを可視化する」「逃げ道を用意する」という発想でした。
本記事では、現場の最前線で立ちはだかった「5つのつまずき」と、それらを解消しただけではなく、人間による分類精度にまで到達させた「5つのプロンプト術」を紐解きます。
-
CATエヴァンジェリスト 石井 優
倉庫事業企業のシステム部門にて、基幹システムの開発・保守・導入および大規模基幹システム移行への参画を経験し、2015年にSHIFT入社。CAT開発チーム内でユーザーサポートとして、ユーザーと開発メンバーのブリッジを行いユーザーの課題分析や新機能提案などを日々実施している。
-
エグゼクティブ・テストスペシャリスト 山腰 直樹
大手ITベンダーにて、約38年にわたりソフトウェアエンジニアとして製品開発に従事。その後、ITシステム開発におけるソフトウェアテスト事業の経験を経て、2022年2月にSHIFTへ参画。現在は海外事業推進部にて顧客支援を行う傍ら、ソフトウェアテスト事業拡大の一環である「欠陥分析サービス」を立ち上げる。SHIFTのテストオファリングを組織全体に浸透させ、顧客ニーズに最適化した支援を提供できるよう精力的に活動中。
-
テストエンジニア 吉澤 麻由
国際的な標準規格（IEEE 29119）などをベースに、自社のナレッジを融合して体系化したSHIFT独自の品質保証標準「SQF（SHIFT Quality Framework）」を構築し、現場への適用を推進。書籍『駄目パターンに学ぶ 失敗しないソフトウエアテスト実践ノウハウ』では全体監修を、その改訂版である『SHIFT流 AI時代のソフトウエアテスト』においても執筆の中心的役割を担った。
目次
全体工数の8割を占める欠陥分類。手作業と属人化の壁
石井：今回はAIを活用してソフトウェアテストの欠陥分析を劇的に効率化した取り組みについてお話しします。
まずは、この話のベースとなっている「ODC分析」についてご紹介します。ODC分析とは、テストや本番運用で発生した欠陥（不具合）の情報を分類し、傾向の可視化と品質改善につなげる強力な分析手法です。
従来、欠陥分析には、統計的分析（数の偏りを見る分析）と原因分析（なぜなぜ分析）の2つがありました。ODC分析はこの中間地点に位置しています。
約300件程度の不具合情報から全体の傾向を把握しつつ、一つひとつの欠陥の意味を捉えて改善アクションにつなげることができる、品質改善の切り札ともいえる手法です。
有用な手法であることは間違いありませんが、ネックになるのは、欠陥を分類しタグづけする作業が重労働であることです。お客様からいただくバグデータには、最初からきれいにタグがついているわけではありません。
例えば300件のバグに対して、「修正対象は何か」「トリガーは何か」など、5〜10個のメトリクス（指標）を一つずつ人間の目で見て判断し、タグを付与していく必要があります。
実は、ODC分析の全工程において、この分類作業だけでも工数の約80％を占めており、期間にして約2週間もかかっていたんです。
山腰さん、現場ではこのあたりに課題があったようですね。
山腰：そうなんです。ODC分析には大きく「分類」と「分析」の2つの工程があります。分類は膨大なバグデータにタグをつける作業です。
初心者にはむずかしく、現場では有識者への再鑑（ダブルチェック）依頼が飛び交うなど泥臭い苦労がありますし、教育コストもかかります。
一方で、その分類後に「ここが怪しい」と深掘りしていく分析工程には、専門的な知識と経験が必要で、非常に属人的な作業になっています。
しかもプロジェクトが終わればメンバーは分散してしまうため、2つの工程それぞれにおいて「プロジェクトごとに分類者の教育が必要」「分析できる有識者が限られる」という根深い属人化の課題を長年抱えていました。
石井：そこでAIが登場するわけですね。
山腰：はい。分類にはコツがありますし、一方の分析にも実は有識者特有の“思考パターン”が存在することに気づいたんです。
どちらの工程もパターンがあるなら、AIの得意分野ではないか？と考えたのが今回の取り組みのきっかけでした。
一番のボトルネックであり、全体の工数の8割を占めていた分類の壁。今日はそのなかでも特に、膨大な分類作業そのものをAIで自動化することについてどんな試行錯誤があったのか、詳細をお話しできればと思います。
自信満々に間違えるAI。分類自動化に立ちはだかった“5つの壁”
石井：では実際にAI化を担当された吉澤さんに伺います。当初からスムーズに進んだのでしょうか？
吉澤：いえ、最初は全く上手くいきませんでした。まずAIに分類させる試みについて、直面した“5つの壁”をご紹介します。
1つ目は、「入力の問題」です。障害票の書き方は、お客様やプロジェクトによって異なります。情報が揺らいだままAIに渡すと、前提情報がそろわず精度が落ちてしまうのです。
山腰：現場のリアルな話をすると、綺麗に1件1枚のチケットになっているとは限りません。
なかには、Backlogで「こういうバグが出ました」「これってこういうことですか？」というチャットのやり取りが延々とつづいているものを読み解かなければならないこともありました。
吉澤：2つ目は、「基準の問題（思考の壁）」です。人間が分類するときは、「要件定義書とプログラムの両方を直した場合は、根本原因である要件定義の方を重く見よう」といった暗黙の判断基準をもっています。
しかし、AIには「何を重く見るのか」という基準が共有されていないため、解釈がブレてしまうという課題がありました。
そして3つ目が、「判断の問題」です。情報が足りない場合に、AIが勝手に決め打ちをしてしまうことがありました。
山腰：ここが一番厄介でしたね。AIは、情報が足りなくて判断できない場合でも、「わかりません」とはいわないんですよ。
複数の原因が絡みあっていて人間でも意見が割れるようなケースでも、AIは無理やりどれか一つを選び、自信満々に回答してくるんです。中身を見ると全然違うじゃないか、ということが多発しました。
吉澤：さらに4つ目として、「結果の問題」がありました。AIの分類結果だけを出されてもその理由が見えないと、人間がレビューをする際に判断に困ってしまい、結果的に差し戻しが増えてしまうという課題です。
最後の5つ目は、「応用の問題」です。AIは障害票に書かれている手順や内容を強く参照する傾向があるため、人間なら行間を読んで補完する“潜在的な検出パターン”を拾いにくいというケースがありました。
逃げ道を用意する？欠陥分類の精度を飛躍させる5つのプロンプト術
石井：そうした壁を、プロンプトの工夫でどう乗り越えたのでしょうか？
吉澤：前提として、ここで扱うプロンプトとは「AIに何を、どの形式で、どんな基準で出させるかという指示」のことです。
1つの大きなプロンプトにすべての指示を詰め込むとAIの出力が不安定になるため、私たちは先ほどの壁に対応する「5つのプロンプト（整形から各分類までの5段階）」に分割して処理するアプローチをとりました。
まず1つ目は、「入力品質の均一化」です。1つのプロンプトで処理するのをやめ、前処理として整形専用のプロンプトを挟みました。
どんな障害票が来ても、必ず「ID」「タイトル」「事象」「発生条件」「原因」「対処内容」という6項目の表形式に整理させます。
ポイントは、「要約しすぎないこと」と「空欄を禁止すること」です。情報がない場合は「ない」と書かせることで、後続の分類プロセスへ渡すデータのばらつきを抑えました。
2つ目は、「判断基準のルール化」です。AIの解釈ブレを防ぐため、「要件定義 ＞ 設計書 ＞ プログラム」といったように、人間が暗黙で使っている優先順位をAIの仕様として明示しました。
もし複数の修正対象がある場合は、この優先順位に従って代表を一つ選び、選ばなかった他の要素は理由として保持しておくよう指示しています。
石井：先ほど厄介だったといっていた、AIが自信満々に間違える問題はどう解決したんですか？
吉澤：3つ目の工夫「あいまいさの可視化」で解決しました。これが一番のポイントかもしれません。
原因が複数絡みあっていたり、情報が不足していたりする場合に無理やりどれかを選ぶことを禁止しました。その代わり、「アルゴリズムかチェックか、どちらかあいまいである」というような救済カテゴリーを用意したんです。
山腰：人間が分類していても、迷うものは必ず出てきます。その場合、有識者に再鑑を依頼していました。
選択肢を増やしてあえて「あいまいです」と報告させることで、人間が後から再鑑する対象を全件ではなくグッと絞り込むことができたんです。
吉澤：4つ目は、「結果と理由をセットで出力させること」です。分類結果だけを出力させると、なぜその結論に至ったのか人間にはわかりません。
そこで、分類した理由の出力を必須にし、さらにAI自身に「選んだ結果と理由に矛盾がないか」の整合チェックをさせました。
山腰：これによって、「AIはどう考えて間違えたのか」が見えるようになりました。
間違えた理由がわかれば、「こういうときはこっちを選ぶんだよ」とプロンプトに具体例を追加してチューニングできます。間違いの傾向も見えて、精度向上のために非常に役立った工夫ですね。
吉澤：最後の5つ目は、「AIに行間を読ませる」工夫です。
障害票に書かれた手順だけをなぞるのではなく、「実際（障害票通りのテストパターン）」と「潜在（そうテストすれば発見できたと判断されるパターン）」の2軸で分類させるようにしました。
例えば「ログアウトして別ユーザーでログインしたら不具合が起きた」という事象から、「同一機能を別端末で同時操作しても起きたはずだ」といった潜在的な検出パターンをAIに推測させるんです。
これも理由を必須にすることで、より人間に近い深い分類ができるようになりました。
人間の思考を仕様化。わずか1時間で分類できるようになった
石井：結果として、どのくらいの成果が出たのでしょうか？
山腰：分類作業にかかっていた工数が、2週間からわずか1時間へと劇的に短縮されました。
また、精度に関しても、人間2人が分類しても100%は一致せず、だいたい80％程度の一致率なんです。現在のAIの分類精度は、人間同士がやった時の精度とほぼ同等レベルにまで到達していると実感しています。
吉澤：今回学んだのは、AIに分類を丸投げするのではなく、「人間が普段行っている分類ルールや判断プロセスを整理し、仕様として言語化すること」が重要だということです。
山腰：工数削減だけでなく、属人化の解消という当初の悩みにも光が見えました。 いまでは、ODC分析をこれからはじめる初心者に対して、AIが教育係として機能しています。
AIのおかげで分析のハードルが下がり、より多くの人が品質改善に関われるようになる。この裾野の広がりに、とてもワクワクしています。
石井：最後に吉澤さん、今後のビジョンや取り組んでみたい野望はありますか？
吉澤：今後は分類だけでなく、その後の分析プロセスにもAIを適用していきたいです。
分析にも、ある程度のパターンがあります。ベストプラクティスとの比較や異常値の発見、共通項を見つけ出すといった作業はAIの得意分野です。
AIと人間が互いの強みを活かすことで、より高度な品質保証の形を追求していきたいと考えています。
石井：ありがとうございます。吉澤さんが執筆を担当したSHIFTの書籍『SHIFT流 AI時代のソフトウエアテスト』にも、これからの時代に品質保証の精度を高めるヒントが多数記載されています。
同書に書ききれなかった“AI時代のエンジニアの生存戦略”や“エンジニアの真の価値”について言及した記事も、ぜひご一読ください。
関連コンテンツ
（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）
