連載: AIに仕事を奪われる不安から始めるハーネス作成入門
第17回: AI時代でもSEの品質保証経験が価値を持つ理由
第1〜16回: ✅ 公開済み ｜ 当該記事: 📖 ｜ 次回: 第18回
はじめに――「AIがコードを書く時代」に品質は誰が保つのか
LLMがコードを生成し、AIエージェントがタスクを実行する。そんな時代に、「品質を保証するのは誰の仕事なのか？」という問いが浮かびます。
結論から言えば、AI時代だからこそ品質保証の経験が価値を持ちます。ただし、その活かし方は従来と少し変わります。今回はその「変わる部分」と「変わらない部分」を整理し、QA観点表としてまとめます。
AI生成物の品質問題――従来と何が違うのか
AIが生成したコードや出力には、従来のソフトウェア開発とは異なる品質リスクがあります。
| 観点 | 従来のソフトウェア | AI生成物 |
|---|---|---|
| バグの種類 | ロジックエラーが中心 | 「もっともらしい間違い」（ハルシネーション） |
| 再現性 | 同じ入力なら同じ出力 | 同じプロンプトでも結果が変わる |
| テスト容易性 | 比較的テストしやすい | 非決定的でテストが難しい |
| セキュリティ | 既知の脆弱性パターン | プロンプトインジェクションなど新たなリスク |
| 説明責任 | コードを読めばわかる | なぜその出力になったか不明 |
これらの違いがあるからこそ、「品質を見る目」を持つSEの経験が重要になります。
SE経験が活きる4つの領域
1. 入力検証の観点
業務システムで「入力値のバリデーション」を設計した経験は、AIエージェントへのプロンプト検証にそのまま応用できます。
- 入力長の制限、禁止文字のチェック → プロンプトの長さ制限、インジェクション検知
- 必須項目のチェック → タスクの必須パラメータ検証
- マスタデータとの突合 → ホワイトリストとの照合
2. 出力検証の観点
帳票出力やレポート生成で「出力が仕様通りか」を確認してきた経験は、AI出力の検証に活きます。
- フォーマット検証 → AI出力の構造化データ検証
- 値の範囲チェック → AI出力の妥当性チェック
- クロスチェック → 複数AI出力間の整合性確認
3. エラーハンドリングの観点
障害対応や例外処理の設計経験は、AIエージェントのエラーハンドリングに直結します。
- リトライロジック → APIタイムアウト時のリトライ
- サーキットブレーカー → 無限リトライの防止
- フォールバック設計 → AI失敗時の代替処理
4. セキュリティの観点
セキュリティ設計や脆弱性対応の経験は、AI特有のリスクへの対策に活かせます。
- 権限管理 → ツールアクセス制御
- 入力サニタイズ → プロンプトインジェクション対策
- 監査ログ → AI処理のトレーサビリティ
QA観点表――AIエージェント/ハーネスの品質保証
上記の4領域をまとめた、ハーネス開発向けQA観点表です。
| # | 観点 | 具体的なチェック内容 | SE経験との対応 | 優先度 |
|---|---|---|---|---|
| 1 | 入力バリデーション | プロンプトの長さ・形式・禁止パターンを検証しているか | 入力バリデーション設計 | 高 |
| 2 | インジェクション対策 | プロンプトインジェクションを検知・ブロックしているか | 入力サニタイズ | 高 |
| 3 | 出力構造検証 | AI出力のJSON/Markdownが期待フォーマットに合致しているか | 帳票・レポート検証 | 高 |
| 4 | 出力妥当性 | AI出力の値が妥当な範囲に収まっているか | 値の範囲チェック | 中 |
| 5 | エラーハンドリング | APIタイムアウト・レートリミット時のリトライがあるか | 障害対応設計 | 高 |
| 6 | サーキットブレーカー | 無限リトライ・無限ループを防ぐ機構があるか | 障害防止設計 | 高 |
| 7 | フォールバック | AI失敗時の代替処理が定義されているか | 縮退運転設計 | 中 |
| 8 | アクセス制御 | ツールごとの権限制御が実装されているか | 権限管理設計 | 高 |
| 9 | トレーサビリティ | 全処理の監査ログが記録されているか | 監査ログ設計 | 高 |
| 10 | パフォーマンス | レスポンスタイム・スループットが許容範囲内か | 非機能要件設計 | 中 |
| 11 | データ保護 | 機密情報がLLMに渡らないようマスキングされているか | 情報セキュリティ設計 | 高 |
| 12 | 再現性 | 同じ入力で結果が大きくブレないことを確認しているか | テスト設計 | 中 |
「変わらないこと」と「変わること」
変わらないこと（SE経験がそのまま活きる）
- 「入力を疑う」という姿勢
- 異常系を先に考える習慣
- テストで品質を担保するアプローチ
- 監査ログでトレーサビリティを確保する設計
変わること（新たに必要になる観点）
- 非決定的な出力への対応（統計的テストの導入）
- プロンプトインジェクションという新たな攻撃ベクトル
- AIの「幻覚」を検知する仕組み
- コスト（トークン消費）の監視
実践ステップ――QA観点表を埋めてみる
上記のQA観点表をテンプレートとして、自分のハーネスに当てはめてみてください。
- 各観点について「対応済み」「未対応」「該当なし」を記入
- 未対応の項目に優先度をつける
- 優先度「高」から対応を始める
すべての観点に一度に対応する必要はありません。重要なのは「観点を持っていること」自体です。
SEからAIエンジニアへのロードマップ
品質保証の経験をAI領域に活かすロードマップを描くとすれば、以下のような段階が考えられます。
- 現状のスキルを棚卸し: QA観点表で自分の経験を可視化
- ハーネスで実践: 自分のハーネスに品質ゲートを組み込む
- 新たな観点を学ぶ: プロンプトインジェクション、ハルシネーション検知など
- チームに展開: ハーネス品質ガイドラインを整備
まとめ
- AI生成物には従来と異なる品質リスクがある（非決定性・ハルシネーション・新たな攻撃ベクトル）
- SEの品質保証経験は4領域（入力検証・出力検証・エラーハンドリング・セキュリティ）で活きる
- QA観点表で12のチェック項目を整理。優先度「高」から対応
- 「観点を持つこと」自体が最も重要な第一歩
次回予告
第18回「MCPサーバーの単体テスト・結合テスト観点を作る」では、今回作成したQA観点表をベースに、MCPサーバーの具体的なテストケース表を作成します。pytestを使った実装例も含め、「どうテストを書けばいいのか」という具体的な問いに答えます。
📖 連載一覧: 第1〜16回 ✅ 公開済み ｜ 第17回（本記事） ｜ 第18回〜 続刊予定