連載「AI時代のソフトウェア品質」総合インデックス（全8回）
はじめまして。ソフトウェアの品質づくりに携わる中で、「AIで実装は速くなったのに、"本当に意図どおりか"を誰がどう担保するのか」という問いが、ずっと気になっていました。この連載は、その問いを自分なりに整理した記録です。特定の製品や会社の話ではなく、現場で一般化して考えたことを、個人の見解として書いています。肩肘張らず、興味のある回から読んでもらえたら嬉しいです。
ソフトウェアの品質を、AI時代に問い直す連載です。本編は全6回。加えて、実務にさらに踏み込む発展編が全2回あります。番号順に読むと、品質の捉え方から、それを担う役割まで、順に積み上がります。発展編は本編を読んだあとの深掘りとしてどうぞ。
はじめに
本連載では、品質を3つの軸で捉えます——
①設計書適合（仕様どおりか）
②暗黙要件（仕様に書かれない当たり前）
③本質要件（本当に達成したい目的）
本編（全6回）
第1回 「AIが仕様通りに作ったのに業務パターンが抜け落ちる」——AI時代のソフトウェア品質を考え直す
品質を ①設計書適合・②暗黙要件・③本質要件 の3軸で捉え、AIが加速するのは①だけで、②③が抜け落ちる構図を示す。
▶ 第1回を読む：
第2回 なぜAIは「書かれていないこと」をテストできないのか——②暗黙要件と"オラクル"の問題
テストの「正解の基準（オラクル）」とは何か。②は仕様に書かれていないため、AIが最も取りこぼしやすい。
▶ 第2回を読む：
第3回 「正解」が存在しないものをどうテストするのか——③本質要件とReference Oracle
③は明示的な正解がそもそも無い。Shift Left／Reference Oracle／Shift Right の3経路と人間の判断で迫る。
▶ 第3回を読む：
第4回 AIに「書かれていないこと」までテストさせる——QEハーネスという仕組み
②の経験知をマシンリーダブルな制約として書き出し、テストエージェントに埋め込む。
▶ 第4回を読む：
第5回 品質は一つのテストで決まらない——信頼を層で積み上げる「多層バリデーション」
①②③の打ち手を、Layer 1〜4の層として連続させ、信頼を積み上げる設計。
▶ 第5回を読む：
第6回（最終回） その品質を誰が担うのか——AI時代の新しい役割「QEアーキテクト」
②③を統合し、品質の成立に責任を持つ役割。テックアーキテクトと並走し、Quality as a Team で担う。
▶ 第6回を読む：
発展編（実務に踏み込む全2回）
連載の途中から追加した、より実務寄りの2回です。本編の「上流で②③を作り込む」「品質を統治として扱う」というテーマを、プロジェクト運営の側から掘り下げます。
発展編 第1回 SDDを"雰囲気"で回さない——「二階層SDLC」という提言
機能単位の4フェーズ（Specify→Plan→Tasks→Implement）だけを回すのではなく、その上にプロジェクト全体のガバナンス層を置く。
▶ 発展編 第1回を読む：
発展編 第2回 品質は"止める"ものではなく"統治"するもの——リスク受容としての品質ガバナンス
③をリスク受容の問題として扱い、許容水準を事前に合意し、最終判断は事業責任者と協働する。発展編 第1回の「全体ガバナンス層」の上に載る機能。
▶ 発展編 第2回を読む：
この連載は、全8回を一本にまとめたドキュメント（ホワイトペーパー）が元になっています。通しで読みたい方・要点だけPDFで掴みたい方は、個人サイトの全文版（無料）へどうぞ。
▼ホワイトペーパー本体（全文無料・概要PDFあり）
https://software-quality-ai-era.terumitsu-takahashi-qe.workers.dev
本稿および本編は個人の見解であり、所属する組織を代表するものではありません。
問い合わせ先：terumitsu.takahashi.qe [at] gmail.com
