ユニファ開発者ブログ

ユニファ株式会社プロダクトデベロップメント本部メンバーによるブログです。

えっ？ AIは、品質を〇〇〇〇〇！？　3つの負債と、構造的テスト（SDAT）の話　【前編】

QA AI テスト

どうも！
AI開発推進部でQA（品質保証）エンジニアを担当しています、たかだ（@tackaaaada）です！

早速ですが、AIコーディングツールを導入して、普段の開発業務は「いい感じ」に進んでいますか？

すっかり、AIでコーディングするのも「当たり前」になってきた、今日このごろ。
僕はというと、ちょっと気になることがあるんです！




そう、「AIは、品質を〇〇〇〇〇んじゃないか」って。



はじめに：AIで業務は速くなった。では、品質は？

皆さんの会社でもAIコーディングツールを導入し、使う頻度が増え、開発チームのコード量も増え、デプロイ頻度も上がりつつあるのではないでしょうか。（実際に、上がっているのかもしれません）

DORA 2025*1によると、90%の開発者がAIを業務で活用しており、前年比+14%で普及が加速しているというレポートが報告されました。

一方で、次のようにも言及しています。

「AIはチームを修正しない。すでにあるものを増幅するだけだ」

チームの現在の状態を、そのまま増幅することで、以下のことが見えてきたと言っています。

  • 「スループット」と「安定性」の不均衡が生じ、変更失敗率が上昇している。
  • 変更量の増加によって、「検証の難化」と「認知摩擦」の移動が発生し、テストとその調整コストを増加させる可能性がある。

ここで、ふと立ち止まって考えてみるとこんな問いが浮かんできます。

「テスト」と「品質保証」、置き去りになっていませんか？　
（テストは、追いついている？。不具合は、減っている？。品質は、良くなっている？）

今回は、その「増幅器」が品質に何をもたらすのか。
そして、ユニファのQAエンジニアである私「たかだ」が、それにどのように向き合ったのか。
データと理論を軸に、お話したいと思います。

AI以後の「2つの負債」

「コードを書くコストは下がったのに、なぜ品質コストが上がるのか」

この問いに、Lilia Abdulina*2らのリサーチ「QA in the Age of AI-Accelerated Development」が、答えてくれました。

このリサーチによると、「AIがコストモデルそのものを、逆転させた」という事実を明らかにしています。

アクティビティ AI以前 AI以後
コードを書く 高価 (人間の時間) 安価 (エージェントが生成)
コードを理解する 無料 (作成者が理解している) 高価(誰も深く理解していない)
コードを書き直す 高価 (人間の時間) 安価 (エージェントが再生成)
書き直す箇所を見つける 普通 (理解しているコードを辿る) 非常に高価 (理解のギャップが大きい)


このリサーチでは、そのコスト上昇について、以下のように言っています。

The cost driver shifts from rework volume to comprehension debt, and the curve gets steeper*3

コストの要因が「手戻りの量」から「理解の負債」へとシフトし、曲線はさらに急勾配になります*4


このコストの逆転により、以下の2つの負債が生まれるとも言っています。

  • 理解の負債（Comprehension Debt）：「どう動くか」を誰も深く知らない状態で知見が少なくなる
  • 意図の負債（Intent Debt）：「なぜ作ったか」「どのビジネス課題を解決するか」「どんなトレードオフを許容したか」が消えていく状態で、意思決定を行った人間がいなくなる


従来の品質を向上させてきたメカニズム「テストでバグを発見 → 開発者が学習 → 次のサイクルで同様のバグが減る」というフィードバックループも弱体化し機能しなくなる上に、AIエージェントはセッションごとに「ほぼリセット」され「学習しなくなる」と言及しています。

加えて「ブートストラップ問題」という、同じ盲点を共有したテストが生まれ、人間のドメイン知識が介在しない「同じ誤解を共有しているためにPassしてしまうテストが生まれてしまう」問題も、その俎上に上がってくると言っています。

またこのリサーチでは、AIエージェントを導入して「2種類の企業タイプ」があることも、紹介していました。

もう一つの「負債」

ここまでの話で、「いや、それって理論の話でしょ？」という声が聞こえてきそうです。

その声に応える形になりますが、もう一つ。今度は、Hao He氏ら*5による実証研究「Speed at the Cost of Quality」*6（MSR '26）を、ご紹介したいと思います。

研究対象のAIコーディング支援ツールを採用した806のGitHubリポジトリと、未採用の1,380リポジトリを比較した大規模な実証研究で、差分の差分法*7と、動的パネルGMMモデル*8による因果推論から、「AIコーディング支援ツールを採用して、品質がどのように変わったのか？」ということを、因果を厳密にしながら検証した実証研究です。

Attention！：この実証研究では、対象となったOSSリポジトリ群において、AIコーディング支援ツール導入後に短期的な速度向上と、静的警告・複雑度の増加が観測されています。ただし、これは観測条件に依存する結果であり、すべてのプロジェクトに同一の影響が生じることを直接意味するものではありません。



結果はというと、

指標 変化率 持続性
追加コード行数 +28.58% ⚠️ 一時的（1〜2ヶ月でベースラインに戻る）
静的解析警告数 +30.26% 🔴 永続的（採用後も増加し続ける）
コードの複雑度 +41.64% 🔴 永続的（コードベース全体に蓄積）

のようになっています。

上のグラフは、

  • 導入前6ヶ月の平均値を100として、それをベースラインに設定
  • 左側のグレー帯（t=-6〜t=-1）= 導入前の期間
  • 点線の縦線（t=0）= 導入した月
  • 右側（t=1以降）= 導入後の経過

を表しており、導入した月に「コード追加量が約3.5倍」になったそうです。

速度向上は、研究対象のAIコーディング支援ツール導入直後の「1〜2ヶ月に集中」し、その後時間経過とともにベースラインへ戻り、逆に「静的解析警告」や「コードの複雑度」といった技術的負債の蓄積は、右肩上がりになっています。

論文ではこれを、 「複雑性の負債（Complexity Debt）」 と呼んでいます。

そして最も重要な発見が「自己強化サイクル」です。

先程紹介した動的パネルGMMモデルの因果分析によると、蓄積した複雑性は将来の開発速度を64.5%低下させるとのこと。

AIコーディング支援ツール導入によって、「コードの複雑度が増加 → 更に将来の開発速度を6割強低下 → またコードの複雑度が増加 → 開発速度が低下」というサイクルが自動的に形成されると、実証研究の論文の中で言及しています。

「LLMは構造的には正しいが意味論的に不透明なコードを生成している可能性がある。これは機能的な正確さに関係なく持続する"理解のコスト（comprehension tax）"である」


このことから「QA in the Age of AI-Accelerated Development」が理論的に語った「理解の負債」を、この実証研究の内容から定量的に証明された、と読み取れるように思えます。

問題の本質：AIは"差"を広げる

以上、これらの研究内容から「あるメッセージ」が、以下のように浮かび上がってきそうです。

AIは「品質をバグらせる」増幅器だ。Proactive QA（予防型） のチームはAIでプロダクトの品質を「強化させ」、Reactive QC（事後管理型） のチームはAIでプロダクトの品質を「悪化させ」、コストも急増する

「テストは後で」「バグが出たら直す」というアプローチは、AI時代において「開発コスト」「品質コスト」が現状から更に、高くつきます。

また、去年の12/16にWAKE Career主催で行った登壇「なめらかな"品質保証"と、その敵〜開発者が知っておくべきQAの本質とAI活用テスト設計〜」*9の中で言及した、「バイアス（思い込み・勘違い）」といった人間が潜在的に持っている不具合と合わさり、AIの速度でコードが増え、理解されないまま、複雑性だけが積み上がっていく先には、


技術的な負債だけが積み上がっていく。それが私たちが向き合うことになった現実です。

では、どうすれば良いか。


実は「私」も、同じ壁に当たった

実は、「たかだ」も似たようなことを最近まで経験していました。
テスト設計の補助ツールとしてAIコーディングツールを使い始め、速度は確かに上がりました。
「テストドキュメントを書く速さ」という意味では。
しかし、何かがうまくいかなかった。

色々と試してみて、以下のことが起きることに気づきました。

  • テスト実施の証跡が残らない
  • 「なぜこのテストを書いたか」がセッションをまたぐと消える
  • AIへの指示がうまく伝わらず、毎回ゼロから説明し直す
  • テストはあるのに、なぜそのテストが必要かが誰にも説明できない
  • 従来のテストプロセスにあてがって作ってみても、内容の再現性が薄れてしまう



では、

  • 「AIと一緒にテストをする、とはどういうことか？」
  • 「速度に合わせてQAをスケールさせるとはどういうことか？」
  • 「それらを実現する"何か"とは？」

問い続けて、生まれたのがSDAT（Structure-Driven Agentic Testing）です。*10

SDATとは何か：3つの概念

SDAT（Structure-Driven Agentic Testing）とは、「構造」を軸にしたテストフレームワークになります。

理解の負債・意図の負債・複雑性の負債。これら3つに対し、具体的な設計上の解決方法を持つようにしています。ブートストラップ問題 についても同様です。

では、その「構造」は一体どこから来ているのか？
SDATの核となるのは、「WYSIWID（What You See Is What It Does）」 という考え方です。

Concepts / Syncs / Actions：WYSIWIDの構造要素

MITのEagon Meng & Daniel Jacksonによる論文「What You See Is What It Does」（Onward! '25）は、ソフトウェアに「判読性 / 読みやすさ（legibility）」を与える構造パターンとして、Concepts / Syncs / Actions の3要素を定義 しています。

Concepts（概念）

目的が明確な、「独立したサービス単位」です。「ログイン機能」「ユーザー管理」「通知システム」のように定義します。Concepts同士は依存せず、疎結合のメリットを活かして「独立して設計・生成・変更できる」ことが最大の特徴です。この独立性が、複雑性の負債の蓄積を構造的に防ぐようにしています。

Actions（アクション）

Concept内で実行できる操作です。「パスワードを設定する（set）」「パスワードを確認する（check）」のように、入力と出力を持つ明示的な操作として定義します。入出力が明確なため、LLMへの指示も人間による確認も、正確に行えます。

Syncs（同期）

「あるActionsが完了したとき、別のActionsを呼び出す」イベントベースのルールです。「パスワードを3回間違えたとき、アカウントをロックする」のように、Concepts間の連携を疎結合に表現します。Syncsがあるから、Conceptsはシンプルなままでよいという考え方です。

ここから、品質保証の技術体系と高田の経験から導き出した「品質保証のゴールデントライアングル：「What?：テスト観点」「Where?：テスト対象」「How?：テスト方法」」をかけ合わせることによって、テスト活動のコンテキストをAIに渡し、理解の負債も構造的に防ぐようにしています。

SDATに加えた問い：Who / Why & Time / Then Properties

また、WYSIWIDの構造要素（Concepts / Syncs / Actions）をテスト活動として更に機能させるために、SDATでは独自に3つの問いを体系化しました。

これは論文の定義ではなく、実践を通じて積み上げたものです。

問い 意味 解く負債
Who（誰のための正解か） テストの「主語」を決める 意図の負債
Why & Time（なぜ・いつ起きるか） SyncsのWhyと発火条件を明文化する フィードバックループの崩壊
Then Properties（何が満たされていれば正解か） 人間がテストの「性質」を定義し、AIがケースを広げる ブートストラップ問題


Who

「ログインできた」という結果が、管理者と保護者ユーザーとで意味が違うように、「誰にとってのOKか」を最初に決めます。ここを曖昧にすると、「テストは通っているが、誰も検証していない」状態になります。

Why & Time

Syncsの「Why（なぜそのルールが必要か）」と「Time（いつ発火するか）」といった「意図と背景を明文化」します。これがないと、Syncsは「動いているが、なぜ動くかが分からない」という意図の負債に戻ります。

Then Properties

「〜であること」という形で記述する、検証可能な性質の定義です。「画面が表示される」ではなく、「ログイン後にダッシュボードが表示され、ログインしたユーザーの名前が正しく表示されること」のように書きます。人間がこのPropertiesを定義し、AIがテストケースを生成することで、ブートストラップ問題を回避するようにしています。*11

Boltという単位

AI時代のQA反復は、Sprintの単位（数週間）などでは追いつかないところから、SDATでは「Bolt（ボルト）」という時間〜半日の短い反復単位を設けています。
BoltはSprintより小さく、コミットより大きい単位です。各Boltには必ず次の4要素を持たせます。

  • Who：このBoltで誰の何をテストするか
  • Why：なぜこのタイミングでこのテストをするか
  • Key Syncs：対象となる主要なルールはどれか
  • Evidence（証跡）：何をもって完了とするか

「意図とともに証跡を残す」仕組みにし、意図の負債とフィードバックループの崩壊に正面から対抗するようにしています。

SDATの哲学：Simple over Easy

最後に、このアプローチの根本にある3つの考えを、紹介します。

Simple over Easy（単純さは安易さに勝る）

「Easy（安易）」とは、AIにコードを丸投げして生成させることです。手間はかかりません。しかし、先の研究が示した+41.64%のコード複雑度は「Easy」の代償です。
「Simple（単純）」とは、構造上の複雑さを排除し、意図と構造を明快にすることです。簡単ではないかもしれませんが、長期的なコストが違います。

Structure over Brute Force（構造は力業に勝る）

「Brute Force（力業）」とは、大量のテストでバグを炙り出そうとするアプローチです。力技でなんとかしよう（大量にテストケースを作って対応する。大量に人員を配置してテストするなどの、人海戦術とか）とするときもあるかもしれません。ただ、それが失敗したとき、あたりには何も残りません*12。そこには、なぜ失敗したかが分からないからです。
「Structure（構造）」に基づくアプローチは違います。Concepts/Syncsの構造があれば、失敗すらも「どの構造の欠陥か」という知識として蓄積されます。

Active Engineering（能動的エンジニアリング）

"QA in the Age of AI-Accelerated Development"が引用する、認知科学の知見があります。
「自分で問い、考えて、コードを書く行為」が理解の定着を生む。これを「生成効果（Generation Effect）」*13と呼びます。
同時に、「批判的思考（Critical Thinking）」も取り入れながら進めると、効果的であるとも考えています。*14
SDATでは、「Who?」「Why?」を能動的に問い続けることを設計の中心に置きます。AIに「方法（How）」を教えるのではなく、「構造（Why & Structure）を教える」という立場です。

まとめと後編予告

まとめです。

  • AIは「速さ」を増幅するが、「複雑性の負債」も増幅し、品質をバグらせる
  • 品質保証は、AI時代の速度に合わせてスケールしなければならない
  • SDATはその答えとして「構造」を提供する（WYSIWID / Concepts / Syncs / Boltなど）



後編では、SDATの実践的な全容を公開する予定です。

  • 5フェーズ（PLAN→DESIGN→IMPLEMENT→EXEC→REPORT）の詳細と成果物の見せ方
  • ツールスタック（Claude + Agent Skills / Playwright / Atlassian MCP）の構成図
  • Before / After 比較（設計の再現性・証跡の残し方・フィードバックループ）

ここまでお読みいただいて、お気づきかもしれませんが今回の投稿は、以前投稿した技術ブログ進め！“Vibe Testing”計画！ 〜AI開発推進部 QAの”初”挑戦〜と「具体→抽象→具体」で、"AIエージェントといっしょに"テストを書いてみよう！を取りまとめ、積み重ねた実践知も含めて再編集し、新たなテストフレームワークとして「SDAT」という形で紹介するものです*15。

後編も引き続き、お読みいただければ幸いです。

後編は、5/4のGW中に投稿予定です。

では、後編へ続きます。

ユニファでは一緒に働いてくれる仲間を募集しています。 興味を持っていただけたら、採用情報もあわせてご覧ください。 jobs.unifa-e.com

*1:Google Cloud DORA Report(2025) State of AI-Assisted Software Development

*2:JetBrainsのQA責任者

*3:QA in the Age of AI-Accelerated Development: https://github.com/BeyondQuality/beyondquality/blob/f3886c53ea636c7780137e4c3b79edfbed87101d/research/ai-era-testing/analysis.md より

*4:ブロッコリーさんのブログ：20260413 翻訳記事「AIコーディングツールによって加速するコード生成に品質保証活動はどう立ち向かうか」https://nihonbuson.hatenadiary.jp/entry/QA-activities-in-response-to-generated-code より

*5:Carnegie Mellon University

*6:原題：「Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects」

*7:DiD: Difference-in-Differences：効果検証方法の一つ。施策や介入（処置）の前後において、「施策を実施した群（処置群）」と「実施していない群（対照群）」の平均的な変化の差を比較し、因果効果を推定する手法。

*8:経済成長や企業投資などの動的調整過程の分析に使われるモデル。過去の値が現在の値にどのような影響を与えるかを扱う。

*9:https://speakerdeck.com/tkd_yuki/namerakana-pin-zhi-bao-zheng-to-sonodi-kai-fa-zhe-gazhi-tuteokubekiqanoben-zhi-toaihuo-yong-tesutoshe-ji

*10:次回は、SDATの構造——Concepts / Syncs / Actions——と、それがどのように「3つの負債」に対処するのかを、具体的に解説します。

*11:詳細な実装方法・テンプレートは後編で。ここでは「構造の考え方」の理解を優先します。

*12:松尾芭蕉も、こう詠んでいます。「夏草や 兵どもが 夢の跡」って

*13:SlameckaとGrafによる1978年の論文、およびMcCurdy他が2020年に行なった126件の論文に書かれていた310件の実験のメタ分析より

*14:実際に、SDATにもこの考えを取り入れています。手前味噌ですが、入社した時に書いた技術ブログ https://tech.unifa-e.com/entry/2024/12/22/000000 も参照していただけると、うれしいです。

*15:あと、今までの投稿がポエムちっくだったので、書き方を今後改めて技術ブログらしい書きぶりにしました