はじめに **ISTQB AI Tester 認定（Chapter 4）**では、 機械学習（ML）モデルを支える「データ」の扱いが非常に重要なテーマとして扱われています。 本記事では、 学習データ（Training Data） 検証データ（Validation Data） テストデータ（Test Data） という 3つのデータセットの役割・使い分け・分割比率を、 テスト観点・具体例を交えながらわかりやすく解説します。 MLモデル開発に必要な3つのデータセットとは？ ① 学習データセット（Training Data Set） 役割 MLモデルが「パターン」や「ルール」を学習するためのデータ モデルの重みやパラメータを直接更新するために使用される 具体例 画像認識：ラベル付き画像（犬／猫など） 自然言語処理：文章＋正解ラベル 自動運転：センサー情報＋正解操作データ 👉 最も多くの割合を占めるデータセットです。 ② 検証データセット（Validation Data Set） 役割 学習途中のモデル性能を評価する ハイパーパラメータ調整（チューニング）に使用 過学習（Overfitting）を防ぐために重要 ポイント 学習には使わない しかし「モデル改善」には利用する 👉 テストデータとは明確に役割が異なる点が試験でよく問われます。 ③ テストデータセット（Test Data Set / Hold-out Data） 役割 最終的なモデル品質を評価するためのデータ 学習・検証では一切使用しない 重要な考え方 テストデータは「完全に未知のデータ」でなければならない これにより、 実運用時の性能を正しく評価できる 評価結果の信頼性が確保される

特徴量エンジニアリングとデータ準備の課題 本記事では、 ISTQB AI Tester | Data Preparation (Part-2) | Feature Engineering | Challenges in Data Preparation の内容をもとに、機械学習（ML）におけるデータ準備の後半を詳しく解説します。 前回（Part 1）では、 データ取得（Data Acquisition） データ前処理（Data Pre-processing） について学びました。 今回はその続きとして、**特徴量エンジニアリング（Feature Engineering）**と、 **データ準備における代表的な課題（Challenges）**を扱います。 データ準備はMLワークフローの要（かなめ） 機械学習モデルの性能は、 アルゴリズムよりもデータの質で決まると言われるほどです。 どれだけ優れたモデルを使っても、 不要な情報が多い ノイズだらけ 偏ったデータ では、正しい予測はできません。 そのため、データ準備はMLワークフローの中核工程になります。 特徴量エンジニアリング（Feature Engineering）とは？ 特徴量（Feature）とは何か？ 特徴量とは、 👉 データに含まれる「属性」や「性質」のことです。 例： 犬の画像認識 耳の形 体の輪郭 毛色 自動運転 車速 距離 周囲物体の位置 この特徴量をどう扱うかが、モデル性能を大きく左右します。 特徴量エンジニアリングの2つの要素 特徴量エンジニアリングは、次の2つに分かれます。 特徴量選択（Feature Selection） 特徴量抽出（Feature Extraction） 特徴量選択（Feature Selection）

はじめに ISTQB AI Tester Certification のシラバス第4章では、 **機械学習（ML）モデルの学習に使われる「データセットの品質」**が、AIシステムの性能や信頼性を大きく左右することが説明されています。 本記事では、**Chapter 4.3「Dataset Quality Issues（データ品質の問題）」**について、 AIテスト初心者でも理解できるように整理・解説します。 なぜデータ品質が重要なのか？ 機械学習モデルは、 「与えられたデータからしか学べない」 という大前提があります。 そのため、 データが間違っている 不足している 偏っている といった問題があると、どれほど高度なアルゴリズムでも誤った結果を出してしまいます。 データセットにおける代表的な品質問題一覧 以下は、MLモデルの学習用データでよく発生する代表的な品質問題です。 ① 間違ったデータ（Wrong Data） 内容 センサーの故障による誤検知 手入力ミス（タイポ、コピペミス） データ収集時の設定ミス 具体例 速度センサーが故障し「0km/h」を常に記録 年齢欄に「222歳」と入力されている 👉 正しくないデータは、モデルに誤った学習をさせる原因になります。 ② 不完全なデータ（Incomplete Data） 内容 一部の項目が空欄 特定期間のデータが欠落 原因例 ハードウェア障害 人為的ミス セキュリティ・プライバシー制限 具体例 センサー停止中のログ欠落 個人情報保護のため年齢・性別が取得不可 ③ 誤ったラベル付け（Mislabeled Data） 内容 教師あり学習では、正しいラベル付けが必須です。 具体例 「犬」の画像に「猫」とラベル付け 正解クラスの取り違え 👉 誤ラベルは、モデルの判断基準そのものを壊します。 ④ データ量が不足している（Insufficient Data）

〜データ取得（Data Acquisition）とデータ前処理（Data Pre-processing）を徹底解説〜 はじめに：なぜ「データ準備」が最重要なのか？ ISTQB AI Tester認定の**Chapter 4（MLとデータ）**では、 「データがAIの品質を決定する」という考え方が中心テーマになります。 機械学習（ML）モデルは、 どんなデータを使うか どのように整形・加工するか によって、精度・安全性・信頼性が大きく左右されます。 実際、ML開発全体のうち 約43%の工数がデータ準備に費やされる と言われており、 モデル構築（約17%）よりもはるかに重い工程です。 本記事では、 4.1 データ準備（Data Preparation）Part1 として、 以下の2点を重点的に解説します。 データ取得（Data Acquisition） データ前処理（Data Pre-processing） Chapter 4 全体構成のおさらい Chapter 4 では、次の内容を扱います。 4.1 MLワークフローにおけるデータ準備 4.2 学習・検証・テストデータセット 4.3 データセットの品質問題 4.4 データ品質がMLモデルに与える影響 4.5 教師あり学習におけるデータラベリング 本記事は 4.1（Part1） にフォーカスします。 1. データ準備（Data Preparation）とは？ データ準備とは、 MLモデルを学習させるために、適切なデータを集め・整え・使える形にすることです。 もし、 不適切なデータ 偏ったデータ ノイズだらけのデータ を使ってしまうと、 MLモデルは 誤った予測・不安定な挙動・低精度 を示します。 そのため、データ準備は

ISTQB AI Tester認定試験の**Chapter 3（Machine Learning）**では、 機械学習の基本概念を「定義レベルで正しく理解しているか」が問われます。 今回は公式チュートリアル動画に基づき、 実際の試験形式に近いサンプル問題3問を使って、 ✔ 問題文の読み方 ✔ 選択肢の見極め方 ✔ ありがちなひっかけポイント を丁寧に解説していきます。 問題1：教師あり学習における分類（Classification）と回帰（Regression） 問題文 次のうち、教師あり学習（Supervised Learning）における「分類」と「回帰」を最も適切に説明しているものはどれか。 選択肢 A. 回帰とは、同じテストデータを実行したときに、MLモデルの結果が変わらないことを確認することである B. 分類とは、ラベル付きデータを複数のクラスにグループ化することである C. 分類とは、MLモデルを学習させるためにデータにラベルを付与することである D. 回帰とは、MLモデルが出力するクラス数を予測することである 正解 ✅ B. 分類とは、ラベル付きデータを複数のクラスにグループ化することである 解説 この問題の最大のポイントは、**問題文にある「best（最も適切）」**という言葉です。 試験では「一部正しい」選択肢ではなく、定義として完全に正しいものを選ぶ必要があります。 A：これは「回帰（Regression）」ではなく、ソフトウェアテストにおける「リグレッションテスト」の説明 B：分類の正確な定義。教師あり学習では正解 C：ラベル付けは「前処理作業」であり、分類そのものではない D：回帰は「数値を予測する」ものであり、クラス数の予測ではない 👉 用語の定義を正確に覚えているかが問われる典型問題です。 問題2：強化学習（Reinforcement Learning）の具体例 問題文 次のうち、強化学習（Reinforcement Learning）の例として最も適切なものはどれか。 選択肢 A. モバイルゲームアプリが、プレイヤーの課金額に応じてフィードバックのタイミングや選択肢を変更する B. 翻訳アプリが、インターネット上の多言語テキストを検索して翻訳精度を向上させる C. 工場の品質検査システムが、人間の検査員を監視して不良品を識別する D. 欠陥予測システムが、過去の品質指標を使って不具合が多そうな部品を特定する 正解 ✅ A. モバイルゲームアプリが、プレイヤーの課金額に応じて挙動を変える 解説

ISTQB AI Tester シラバス Chapter 3 では、 機械学習（ML）モデルを構築するうえで非常に重要な2つのテーマ が登場します。 3.4 MLアルゴリズム選定に関わる要因 3.5 過学習（Overfitting）と未学習（Underfitting） 本記事では、 「なぜこのアルゴリズムを選ぶのか？」 「モデルがうまく動かない本当の理由は何か？」 を 実務・試験の両面 から、わかりやすく解説します。 1. MLアルゴリズム選定に「絶対的な正解」はない まず大前提として重要なのは、 最適なMLアルゴリズムを一意に決める決定的なルールは存在しない という点です。 アルゴリズムは一から作ることも可能 しかし実務では 既存ライブラリのアルゴリズムを選び、調整（チューニング）する のが一般的 その際、複数の要因を組み合わせて判断 します。 2. MLアルゴリズム選定に影響する主な要因（3.4） ① 必要とされる機能（Required Functionality） まず最初に考えるべきは、 そのMLモデルに「何をさせたいのか」 です。 代表例： 分類（Classification） 例：犬か猫かを判別する 予測（Prediction / Regression） 例：売上や気温を予測する クラスタリング（Clustering） 例：顧客を購買傾向ごとにグループ化する 👉 機能が違えば、選ぶべきアルゴリズムも根本的に変わります。 ② 要求される品質特性（Quality Characteristics） 次に重要なのが 品質面の要求 です。 代表的な観点： 精度（Accuracy） 処理速度（Performance） 応答時間（Prediction Speed）

ISTQB AI Tester認定のChapter 3：Machine Learningでは、 「どの機械学習（ML）の手法を選ぶべきか」という非常に重要なテーマが扱われます。 本記事では、3.3 Selecting a Form of Machine Learning の内容をもとに、 機械学習の学習形態の選び方 データや出力の違いによる判断基準 試験でも実務でも使える具体例 を交えながら、わかりやすく解説します。 機械学習の3つの基本的な学習形態 まず前提として、機械学習には次の3つの学習形態があります。 ① 教師あり学習（Supervised Learning） 入力データと**正解ラベル（出力）**がセットで与えられる 主な用途 分類（Classification） 回帰（Regression） ② 教師なし学習（Unsupervised Learning） 正解ラベルが存在しない データの構造や特徴を自動的に発見する 主な用途 クラスタリング（Clustering） アソシエーション（Association） ③ 強化学習（Reinforcement Learning） 環境との相互作用を通じて学習 状態・行動・報酬を繰り返しながら最適化 **知的エージェント（Intelligent Agent）**として振る舞う MLの学習形態を選ぶ際の基本ガイドライン では、実際にどの学習形態を選べばよいのか。 ISTQB AI Testerでは、以下の観点が重要だと説明されています。 ① 十分な学習データ・テストデータがあるか 最も重要なのは データの有無と品質 です。 学習用データ（Training Data） テスト用データ（Test Data） MLモデルが理解できる適切な形式 これらが揃っていなければ、どんなML手法でもうまく機能しません。 ② 正解ラベル（出力データ）が存在するか？

アジャイル開発において、チーム全員が常に状況を把握し、迅速に意思決定を行うためには「タスク管理」と「進捗トラッキング」が欠かせません。 ISTQB Agile Tester Extensionの第3章「ツール支援（Tools in Agile Projects）」の最初のテーマである 3.4.1 タスク管理とトラッキングツール（Task Management and Tracking Tools） では、アジャイル開発を支える具体的なツールとその役割について解説されています。 🔹 タスク管理・トラッキングツールとは？ タスク管理・トラッキングツールとは、開発チームが日々の作業（タスク）やユーザーストーリーの進捗を「見える化」するためのツール です。 アジャイルでは「透明性（Transparency）」がとても重要であり、チームの誰もが現在の状況を即座に理解できるようにする必要があります。 この目的を実現するために、ツールには主に以下の2つのタイプがあります。 🔸 1. 物理的なボード（アナログ管理） もっともシンプルな方法は、ホワイトボードやカンバンボードに付箋を貼る形式 です。 例： 「To Do（やること）」 「In Progress（作業中）」 「Done（完了）」 といった列を作り、タスクごとに付箋を貼っていきます。 付箋を動かすことで、チーム全員が「どのタスクが進行中か」「誰が担当しているか」「完了まであとどれくらいか」を一目で把握できます。 👉 メリット：直感的でシンプル、すぐに変更できる 👉 デメリット：リモート作業では共有しづらい 🔸 2. デジタルツール（オンライン管理） 近年では、アジャイルチームの多くが JIRA や Trello, Azure DevOps, ClickUp, Asana, Notion などのデジタルツールを活用しています。 これらのツールは、付箋ボードの機能に加えて次のような強力なサポートを提供します。 🌟 主な機能 ユーザーストーリーとタスクのリンク付け（トレーサビリティ） 開発タスクとテストタスクの関連付け ストーリー単位の工数見積もり（ストーリーポイント） 進捗の自動集計（バーンダウンチャートなど） チーム全体の作業負荷の可視化 ダッシュボードによるリアルタイム状況の表示

〜Planning Pokerで合意を形成し、リスクも考慮した精度の高い見積りを行う〜 はじめに アジャイル開発では、短いイテレーションの中で頻繁に変更や調整が発生します。 そのため、「どの作業にどれくらいのテスト工数が必要か」を正確に見積もることが、プロジェクト成功の鍵になります。 この記事では、ISTQB Agile Tester Extension（Chapter 3.2.2）のテーマである **「内容とリスクに基づくテスト工数の見積り」**について詳しく解説します。 1. テスト工数の見積りとは？ テスト工数（Testing Effort Estimation）とは、テスト活動に必要な 時間（Time） コスト（Cost） 作業量（Effort） を見積もることです。 たとえば、新しいユーザーストーリーをテストする場合、 テスト設計・実行・不具合修正確認などにかかる時間を事前に算出します。 見積りが正確であれば、 チームのスケジュールが安定し、 バックログ管理がスムーズになり、 遅延リスクの早期発見にもつながります。 2. アジャイルで使われる代表的な見積り手法「Planning Poker」 アジャイルでは、チーム全体で合意形成する見積り方法が重視されます。 その代表例が「プランニング・ポーカー（Planning Poker）」です。 ● Planning Pokerの概要 Planning Pokerは合意形成型の見積り手法で、以下の流れで進められます。 **プロダクトオーナー（PO）**がユーザーストーリーを説明する **各メンバー（テスター、開発者など）**がタスクの難易度を考え、 手元のカードで見積り値を出す 値は一般的に「フィボナッチ数列（1, 2, 3, 5, 8, 13, 21…）」を使用 各自が一斉にカードを出す（例：テスターA＝5、開発者B＝8など） 数値の違いが大きい場合は理由を話し合い、共通理解を得る 最終的に合意された値（ストーリーポイントや時間）を記録する ● 例：テストケース作成タスクの見積り 参加者 見積り値（ストーリーポイント） 理由 テスターA 5 既存機能に近く、テスト設計も再利用できる テスターB 13…

アジャイル開発では、プロジェクト全体の成功のために「計画」がとても重要です。 しかし、ウォーターフォールのように大きな計画を一度だけ作るのではなく、段階に応じて2種類の計画を作成します。 それが以下の2つです。 リリース計画（Release Planning） イテレーション計画（Iteration / Sprint Planning） この記事では、それぞれの役割や内容、テスターが何をすべきかをわかりやすくまとめます。 ■ 1. リリース計画とは？ リリース計画は、プロジェクト全体（1回のリリース）に関する大枠の計画です。 ● リリース計画で行うこと プロダクトバックログの定義・更新 ユーザーストーリーの優先順位付け リリースに含める範囲の決定 チームの能力（キャパシティ）や工数の見積り リスクの洗い出し 大まかなスケジュール作成 ここでは、プロダクトオーナーが中心となり、ビジネス価値・リスク・複雑性などを考慮して優先度を決めていきます。 ■ テスターがリリース計画で担う役割 アジャイルでは、テスターも計画段階から積極的に関わる必要があります。 ● テスターの主な貢献 テスト可能なユーザーストーリーの定義（明確な受け入れ基準を含む） リスク分析への参加 テスト努力（工数）の見積り 必要なテストレベルの定義（例：単体、結合、E2E など） リリース全体のテスト計画を作成 ● 例：テスターの視点で見たユーザーストーリーの改善 悪い例（テストしにくい）： 「ユーザーは検索機能を使えるようにする」 良い例（テスト可能）： 「ユーザーは商品名を入力して検索したとき、該当商品が3秒以内に表示されること」 → 受け入れ基準が明確のため、テスターがすぐテストケースを作成可能。 ■ 2. イテレーション（スプリント）計画とは？ スプリント計画とは、1回のイテレーション（通常1〜4週間）で実施する作業内容を決める計画です。 リリース計画がプロジェクト全体の“地図”なら、 スプリント計画は「次の1〜2週間に何をするのか」の“詳細スケジュール”です。 ■ イテレーション計画で行うこと スプリントバックログの確定 各ユーザーストーリーの詳細化（タスク分割） ストーリーポイントの調整 テストタスクの明確化 ビジネス側の質問に対するプロダクトオーナーの回答 チーム全体でのリスク分析 ■ テスターがイテレーション計画で担う役割 ユーザーストーリーをより細かいテストタスクに分解 各タスクの工数見積り

はじめに：Chapter 4「自動車特有のテスト技法」へようこそ ISTQB Automotive Tester資格のChapter 4では、「自動車特有のテスト技法（Automotive Specific Test Techniques）」について学びます。 この章は大きく2つのパートに分かれています。 4.1 静的テスト技法（Static Test Techniques） 4.2 動的テスト技法（Dynamic Test Techniques） まず本記事では、「静的テスト技法」と「MISRA-C:2012 ガイドライン」について解説します。 この内容は**ISO 26262（機能安全）**にも密接に関係しており、安全性の高いソフトウェアを作るうえで欠かせない知識です。 静的テスト技法とは？（Static Testing Techniques） ● 定義と目的 静的テストとは、「ソフトウェアを実行せずに欠陥を検出するテスト」のことです。 主に以下のような作業を含みます。 要件仕様書や設計書のレビュー コードの静的解析（Static Analysis） ドキュメント整合性チェック モデルやフローチャート、データフロー図などの確認 静的テストの目的は、開発初期の段階で欠陥を発見し、コストを削減することにあります。 これはISTQB Foundationでも学んだ「早期テストの原則」に一致します。 ● 静的テストで見つかる代表的な欠陥例 欠陥タイプ 具体例 矛盾 要件と設計の記述が一致しない 欠落 必要な機能が仕様書に抜けている 誤り 関数仕様の数値条件が間違っている 不整合 データフロー図とクラス設計の構造が異なる こうした不具合は、もし後工程（実装・結合テスト以降）で見つかると修正コストが数倍になります。 したがって、静的レビュー段階での検出が極めて重要です。 静的解析（Static Analysis）とは？ 静的解析は、ツールを使ってソースコードを解析するプロセスです。 目視レビューでは発見しにくい欠陥を自動的に見つけることができます。 代表的に検出できる項目 宣言されているが未使用の変数 到達不能コード（dead code） ネストされたコメントや非標準構文

〜MIL・SIL・HILの最適な活用法とVモデルの関係〜 はじめに この記事では、**ISTQB Automotive Software Testerシラバス Chapter 3「Testing in Virtual Environments」**の最後のテーマ、 **「3.2.4 XiLテスト環境の比較（Part3）」**を解説します。 前回までは、モデル（MIL）、ソフトウェア（SIL）、ハードウェア（HIL）それぞれのテスト環境の特徴と構成について学びました。 今回はそれらをVモデルと関連づけて比較しながら、どのテストレベルでどの環境を使うのが最適かを見ていきます。 XiL環境とは何か？再確認 「XiL」とは、“Anything in the Loop”の略で、 モデル・ソフトウェア・ハードウェアなど、テスト対象を仮想的にループに組み込む環境の総称です。 環境名 意味 主な目的 MIL Model in the Loop モデルの妥当性を確認 SIL Software in the Loop ソフトウェア単体や統合の検証 HIL Hardware in the Loop 実ハードウェアと統合システムのテスト VモデルとXiL環境の対応関係 Vモデルは開発工程とテスト工程を対応させる考え方で、左側が設計フェーズ、右側がテストフェーズです。 フェーズ XiL環境 テストレベル 主な活動 技術システム設計（左側） MIL モデルレビュー、設計検証 モデルが要件に沿って設計されているかを確認 ソフトウェア設計・実装 SIL コンポーネントテスト、統合テスト ソフトウェア単体や組み合わせの動作を確認 システム統合・バリデーション（右側） HIL システムテスト、非機能テスト 実機を含む総合的な動作確認

はじめに この記事では、ISTQB Specialist「Automotive Software Tester」シラバス第2章 に含まれる重要トピック、 2.3 AUTOSAR（Automotive Open System Architecture） について詳しく解説します。 このセクションは3つの小項目で構成されています。 2.3.1 AUTOSARの目的（Objectives of AUTOSAR） 2.3.2 AUTOSARの一般構造（General Structure of AUTOSAR） 2.3.3 AUTOSARがテスター業務に与える影響（Influence of AUTOSAR on the Work of the Tester） すべて**K1レベル（知識レベル）**で出題されるため、 詳細な理由説明は不要ですが、「なぜ重要なのか」を理解しておくと、実務にも非常に役立ちます。 AUTOSARとは何か？ AUTOSAR（Automotive Open System Architecture） とは、 自動車ソフトウェアのオープンなシステムアーキテクチャ標準を意味します。 このプロジェクトは、2003年に設立された国際的な開発パートナーシップであり、 主に自動車メーカー（OEM）とサプライヤーによって構成されています。 目的は、自動車ソフトウェアの共通アーキテクチャ標準を確立し、再利用性と品質を高めること。 建物にたとえるなら、AUTOSARは「家の骨組み」にあたる存在です。 構造がしっかりしていなければ、どんなに高級な素材を使っても良い家は建ちません。 同様に、ソフトウェア開発でもアーキテクチャ設計が品質の根幹となるのです。 2.3.1 AUTOSARの主な目的（Objectives of AUTOSAR） AUTOSARのプロジェクト目的は次のようにまとめられます。 試験対策では、暗記対象のK1レベル項目として覚えましょう。 目的 内容の概要 1. ソフトウェアの移植性をサポート プラットフォーム間でソフトウェアを再利用可能にする（Portability） 2. 拡張性の確保

ISTQB Advanced Test Analyst シラバス第3章「仕様に基づくテスト技法（Specification-Based Techniques）」の中で、今回は 「決定表テスト（Decision Table Testing）」 について解説します。 この技法は、複数の条件や組み合わせがあるシナリオを効率的にテストするために使われる、非常に重要なブラックボックステスト技法のひとつです。 🔹 決定表テストとは？ 決定表テストとは、複数の条件とそれに対応するアクション（結果）を表形式で整理し、すべての条件の組み合わせを体系的にテストできるようにする方法 です。 これにより、テストケースの抜け漏れを防ぎ、必要最小限のテストで最大限のカバレッジを得ることができます。 目的： 条件が多いビジネスルールの組み合わせを整理する 不要なテストケースを削減して効率化する 条件の組み合わせによる「漏れ」や「矛盾」を防ぐ 🔹 Foundationレベルとの違い Foundation（基礎）レベルでは、単純な条件と結果の対応を学びました。 Advanced（上級）レベルでは、さらに一歩進んで「Collapsed Decision Table（圧縮型）」と「Non-Collapsed Decision Table（非圧縮型）」という2つの手法を区別して理解する必要があります。 🔸 例題：保険会社の割引シナリオ 架空の保険会社 「Good Health」 の新しい医療保険プランを例に考えましょう。 【仕様】 標準保険料： $500 健康診断テストへの「参加承諾」をした顧客には、 　実際に受けなくても $25割引 以下の4つの医療テストを受けるごとに、追加で $25割引 　- BMI（体格指数） 　- 血圧（Blood Pressure） 　- 血糖値（Glucose） 　- コレステロール（Cholesterol） さらに、4つすべてのテストを受けた場合は、追加で $75割引 🔹 条件と出力の整理 条件 内容 C1 テストへの参加承諾（Yes/No） C2…

はじめに この記事では、ISTQB Advanced Test Analyst（アドバンスド・テストアナリスト） シラバスの 第2章「Test Management Responsibilities of the Test Analyst（テストアナリストのテストマネジメント責務）」の中から、 2.2 Test Progress, Monitoring and Control（テスト進捗・モニタリング・コントロール） について解説します。 この章では、テストアナリストがどのようにテストマネージャーをサポートし、 テストの進捗状況を把握・分析・報告するかを理解することが目的です。 テスト進捗とモニタリングとは？ テスト進捗のモニタリングとは、テスト活動がどの程度計画通りに進んでいるかを測定・評価することを指します。 テストアナリストは、テストマネージャーと連携しながら、進捗を可視化するための**メトリクス（測定指標）**を提供します。 主要な5つの測定次元（Primary Dimensions） テスト進捗を評価する際に注目すべき主な5つの観点があります。 No 測定次元 説明 1 プロダクトリスク（品質リスク） 製品が持つ潜在的な品質上の問題。リスクベースドテスト（RBT）と密接に関連します。 2 欠陥（Defects） 発見された不具合の数・重大度・修正状況をモニタリングします。 3 テスト（Tests） 実施済みテストケース数、残りのテストケース数、合格・失敗率などを測定します。 4 カバレッジ（Coverage） 要求仕様、コード、リスク項目に対するテスト網羅率を把握します。 5 信頼度（Confidence） システムの品質に対する信頼度を測る指標。テストの量・質・レビュー完了率などが影響します。 リスクベースドテストとの関係 テストアナリストは、リスク分析で特定されたリスク項目ごとにテストを計画し、 それぞれのリスクが**「軽減済み（mitigated）」か「未軽減（unmitigated）」**かを追跡します。 たとえば以下のような観点でモニタリングします。 高リスク項目に対して十分なテストケースが作成・実行されているか 優先度の高い不具合が修正・再テスト済みであるか 重大リスクに関連するテストが未完了のまま残っていないか これらのデータをもとに、リスクの現状を可視化し、プロジェクト全体の品質を管理します。 テストマネジメントツールの活用 テストの進捗を効果的にモニタリングするためには、ツールの活用が欠かせません。 主な管理領域とツール例 管理対象 内容 代表的なツール

― ISTQB AI Tester試験で必須の基本プロセスを完全理解 ― ISTQB AI Tester Chapter 3では、機械学習（Machine Learning：ML）をどのような流れで構築・運用するのかという 「MLワークフロー（ML Workflow）」が重要なテーマとして扱われます。 機械学習モデルは、 作って終わりではなく、運用しながら改善し続けるものです。 その全体像を体系的に理解することが、AIテストにおいて不可欠になります。 MLワークフローの全体像 MLワークフローは、大きく次の 2フェーズ に分かれます。 モデル開発（Model Development） デプロイ・利用・監視（Deploy, Use, Monitor） まずはモデルを作り、その後、実システムで使いながら継続的に改善していきます。 ① モデル開発フェーズ（Model Development） 1. 目的（Objective）の理解 最初に行うべき最重要ステップが 目的の明確化 です。 なぜこのMLモデルが必要なのか？ 何を予測・分類・判断したいのか？ ビジネス上のゴールは何か？ これらをステークホルダーと合意し、 さらに 受け入れ基準（Acceptance Criteria） を定義します。 具体例 不正取引検知モデル →「不正検知率95%以上」「誤検知率5%以下」など 2. フレームワークの選定 目的・受け入れ基準・ビジネス要件に基づき、 AI／ML開発フレームワークを選択します。 TensorFlow PyTorch Scikit-learn など ISTQBでは、「なぜそのフレームワークを選んだのか」 という合理性が重要視されます。 3. アルゴリズムの選択・構築 次に、MLアルゴリズムを決定します。 既存ライブラリのアルゴリズムを使用 独自アルゴリズムを新規開発

― 教師あり学習・教師なし学習・強化学習とは？ ISTQB AI Testerシラバスの Chapter 3（Machine Learning） では、 まず最初に「機械学習の学習形態（Forms of Machine Learning）」を理解することが求められます。 本記事では、以下の3つの機械学習の形態について、 定義 → 仕組み → 具体例 → 試験でのポイント の順でわかりやすく解説します。 教師あり学習（Supervised Learning） 教師なし学習（Unsupervised Learning） 強化学習（Reinforcement Learning） 機械学習（Machine Learning）とは？ 機械学習とは、データからパターンやルールを学習し、将来の予測や判断を行う技術です。 AIシステムの多くは、この機械学習を中核として構成されています。 ① 教師あり学習（Supervised Learning） 概要 教師あり学習とは、 「正解ラベル付きデータ（Labeled Data）」を使って学習する手法です。 入力データ：画像、数値、テキストなど 出力ラベル：「犬」「猫」「年齢」「価格」などの正解情報 学習時に「これは犬」「これは猫」と答えを明示的に与えるのが特徴です。 具体例①：画像認識（犬と猫の分類） 犬の画像 → ラベル「Dog」 猫の画像 → ラベル「Cat」 このような 入力＋正解ラベルのペア を大量に与えることで、 モデルは「犬らしさ」「猫らしさ」を学習します。 身近な例：Googleの「私はロボットではありません」 信号機・横断歩道・バス・自転車を選ばせる認証画面は、 教師あり学習で学習された画像分類モデルが使われています。 テストフェーズ 学習後、未学習の新しいデータ（Unseen Data） を入力

― 自律性・バイアス・リワードハッキングを完全理解 ― ISTQB AI Tester認定試験の**Chapter 2（AIベースシステムの品質特性）**は、 概念理解だけでなく「どの品質特性を問われているか」を正確に見抜く力が重要です。 この記事では、Chapter 2の代表的なサンプル問題3問を取り上げ、 ✔ 設問の意図 ✔ 各選択肢の判断ポイント ✔ なぜそれが正解／不正解なのか を、試験対策向けにわかりやすく解説します。 問題1：AIシステムにおける「自律性（Autonomy）」 設問 次のうち、AIベースシステムにおける「自律性（Autonomy）」の要求を最もよく表しているものはどれか。 選択肢 A. システムは、ドライバーがブレーキまたはアクセルを操作するまで、他の車両との安全な距離を維持しなければならない。 B. システムは、メール通信を遠隔監視することで、好ましいメール返信スタイルを学習しなければならない。 C. システムは、住宅価格の予測結果と実際の販売価格を比較し、再学習が必要かどうかを判断しなければならない。 D. システムは、異なるタイプのユーザーに対応するため、その振る舞いを1日以内に変更できなければならない。 正解 ✅ A 解説 **自律性（Autonomy）**とは、 👉 人間の介入なしに、AIシステムが自ら判断し行動する能力 を指します。 A： 人間の操作がなくても、センサー情報を基に「安全距離を維持する」という判断を行っている → 自律的な意思決定を明確に表している B： 学習（Learning）に関する要求であり、自律的な「判断・行動」そのものではない C： 再学習やコンセプトドリフトへの対応に関する要求 D： 適応性（Adaptability）に関する要求 👉 **「人の操作がなくても判断するか？」**が、自律性を見抜く最大のポイントです。 問題2：AIベースシステムにおける「バイアス」 設問 次のうち、AIベースシステムのバイアスに関する説明として「正しくないもの」はどれか。 選択肢 A. 書籍推薦システムにおいて、ユーザーが意図的に偏った選択をすることで、システムが不適切な推薦を行う可能性がある。 B. 従業員の死亡年齢予測システムにおいて、退職者のみのデータを用いて学習を行うことで、バイアスが生じる可能性がある。 C. クレジット審査システムにおいて、クレジットカード利用者のみのデータを学習に使用することで、バイアスが生じる可能性がある。 D.

AI（人工知能）を活用したシステムは、私たちの生活や仕事の中で当たり前の存在になりつつあります。 しかし、AIが「なぜその判断をしたのか分からない」状態で使われることは、大きなリスクを伴います。 そこでISTQB AI Testerでは、 AIベースシステムに求められる品質特性として、次のテーマを重視しています。 透明性（Transparency） 解釈性（Interpretability） 説明可能性（Explainability） 安全性（Safety） 本記事では、これらの概念を初心者にも分かるように解説します。 AIに「透明性・解釈性・説明可能性」が求められる理由 AIベースシステムは、次のような分野で使われることが多くなっています。 医療（診断支援、治療方針の提案） 金融（与信判断、不正検知） 自動車（ADAS、自動運転） 音声アシスタント（Siri、Alexa、Google Assistant） これらの分野では、 **「AIを信頼できるかどうか」**が極めて重要です。 その信頼を支えるのが、 透明性・解釈性・説明可能性という3つの考え方です。 ブラックボックス化するAIの問題点 多くのAIシステムは、ユーザーから見るとブラックボックスです。 例えば： Siriがなぜその回答を出したのか分からない レコメンド結果の根拠が示されない 開発者自身も内部挙動を完全に説明できない このような状態では、 判断ミスが起きても原因が追えない バイアス（偏り）が潜んでいても気づけない 規制当局や利用者が納得できない といった問題が発生します。 Explainable AI（XAI：説明可能なAI）とは？ この課題を解決する考え方が、 **Explainable AI（XAI：説明可能なAI）**です。 XAIの目的は、 AIがどのように結論に至ったのかを 人間が理解できる形で説明できるようにすること これにより、以下の効果が期待できます。 説明可能なAIが求められる主な理由（Royal Societyの整理） 説明可能なAIが重要とされる理由には、次のようなものがあります。 ① ユーザーの信頼を高める 判断の根拠が分かれば、AIを安心して使えます。 ② バイアス（偏り）の検出・防止 性別・人種・年齢などに対する不公平な判断を見つけやすくなります。 ③ 規制・法令への対応 規制当局がシステムの妥当性を評価できるようになります。 ④ システム設計の改善 内部挙動が分かれば、モデルやデータの改善が可能です。 ⑤ リスク・脆弱性の評価 誤動作や想定外の挙動を事前に把握できます。

ISTQB AI Tester シラバス Chapter 2「Quality Characteristics for AI-Based Systems」では、 AIシステムの品質を左右する重要な概念として、次のテーマが扱われます。 2.5 AIシステムの倫理（Ethics of AI Systems） 2.6 AIシステムの副作用（Side Effects） 2.6 AIシステムのリワードハッキング（Reward Hacking） これらは単なる理論ではなく、実際のAI製品やサービスの信頼性・安全性に直結する重要テーマです。 本記事では、それぞれを試験・実務の両面から解説します。 1. AIシステムにおける「倫理（Ethics）」とは何か 倫理とは何を意味するのか 「倫理（Ethics）」とは、 社会的・文化的に受け入れられている行動規範や価値観を指します。 AIシステムにおける倫理とは、 人々に正しい情報を提供すること 人間と同じように礼儀正しく、配慮ある振る舞いをすること 利用者の価値観・文化・信念を尊重すること を意味します。 これは、私たち人間が他者と接する際に期待される行動と同じです。 AIと文化・地域差の関係 AIシステムは、地理的・文化的な違いを強く意識する必要があります。 例：音声アシスタント（Alexa / Siri / Google Assistant） ユーザーはAIを「信頼できる存在」として質問する 文化や国によって、適切な表現・提案は異なる 言語・慣習・宗教・法律の違いを考慮する必要がある 具体例 インド向けのAIが、ドイツ国内限定の商品やサービスを推薦する → 実現不可能であり、倫理的に不適切 日本向けAIが、日本では許可されていない行為を助言する → 法令違反につながる可能性 このように、**「その地域で意味を持つかどうか」**が倫理判断の重要なポイントになります。 倫理は時代や文化で変化する 倫理は固定されたものではありません。 時代とともに価値観は変化する 国・地域・文化によって異なる グローバルAIではステークホルダーの価値観を尊重する必要がある 特に国際展開されるAIシステムでは、

ISTQB AI Tester シラバス第2章では、AIベースシステム特有の品質特性について学びます。 今回はその中でも特に重要なテーマである、 2.3 Evolution（進化） 2.4 Bias（バイアス） について、具体例を交えながら詳しく解説します。 AIシステムは、従来のWebアプリやモバイルアプリとは異なり、使われる中で振る舞いが変化するという特徴を持っています。この特性を理解することは、AIテスターにとって非常に重要です。 1. AIベースシステムにおける「進化（Evolution）」とは？ Evolutionの基本的な考え方 「進化（Evolution）」とは、 AIベースシステムが時間の経過とともに、自らの振る舞いを改善・変化させていく能力を指します。 従来のシステムでは、機能改善は「人がコードを修正し、リリースする」ことで行われていました。 一方、AIベースシステムでは、 環境の変化 ユーザーとのインタラクション 新しいデータの取得 などに応じて、システム自身が学習し、振る舞いを変えることがあります。 AIシステムが進化する2つのパターン 自己学習型AIシステムでは、主に次の2種類の変化（進化）が発生します。 ① 自分自身の判断・経験から学習する進化 これは、AIが自分の過去の判断や環境とのやり取りから学習するケースです。 具体例：スマートフォンの顔認証（Face ID） スマートフォンの顔認証機能を思い出してください。 数年前に登録した顔データでも、今も問題なくロック解除できる 髪型、ひげ、メガネ、顔のむくみ、体型の変化があっても認識できる 明るい場所・暗い場所など、照明条件が変わっても使える これは、顔認証AIが 毎日の顔の微妙な変化 光の当たり方や環境条件 を継続的に学習し、少しずつ自分の判断基準を更新しているからです。 このように、AIは使われる中で進化し、より精度の高い判断ができるようになります。 ② 運用環境の変更によって起こる進化 もう一つは、システムの外部要因による進化です。 例としては、 OSやアプリのアップデート 新しい学習データの追加 機能拡張による再学習 などがあります。 具体例：画像認識AIの機能拡張 以前は「猫」だけを識別できたAI 学習データやモデルを更新することで「犬」も識別できるようになる この場合、人間が意図的に環境や学習条件を変更することで、AIが新しい能力を獲得します。 進化には「制御」が必要 AIシステムは進化することで、 効率 精度 利便性 を向上させますが、無制限な進化は危険でもあります。 そのため、以下が重要です。 進化が元の要件や制約を超えていないか 人間の価値観や倫理観とズレていないか 望ましくない振る舞いをしていないか

「柔軟性（Flexibility）・適応性（Adaptability）・自律性（Autonomy）」をわかりやすく理解する ISTQB AI Tester シラバスの**第2章「AIベースシステムの品質特性」**では、従来のソフトウェア品質とは異なる、AI特有の観点が数多く登場します。 本記事では、その中でも 2.1「柔軟性・適応性」 と 2.2「自律性」 に焦点を当て、 具体例を交えながら、実務や試験対策の両面で理解しやすく解説します。 第2章：AIベースシステムの品質特性とは？ AIベースシステムでは、以下のような品質特性が重要になります。 柔軟性（Flexibility） 適応性（Adaptability） 自律性（Autonomy） 進化（Evolution） バイアス（Bias） 倫理（Ethics） 副作用（Side Effects） 報酬ハッキング（Reward Hacking） 透明性・解釈可能性・説明可能性 安全性（Safety） 今回はこの中でも、環境変化への対応力と人間との関わり方に直結する 「柔軟性・適応性・自律性」を扱います。 2.1 柔軟性（Flexibility）とは？ 定義 柔軟性（Flexibility） とは、 👉 当初のシステム要件では想定されていなかった状況でも、システムが利用できる能力 を指します。 ポイント 元々想定していなかった環境や用途でも使える プラットフォームや利用条件が変わっても破綻しにくい 「想定外」にどれだけ耐えられるかが重要 具体例 ある画像認識AIが 工場用カメラ スマートフォン 異なるOS（Linux / Windows） でも動作する 特定のハードウェア専用ではなく、複数環境で利用できるAIモデル もしAIシステムが特定の環境に強く依存していると、 再利用できない コストが高くつく 導入先が限定される といった問題が発生します。 2.1 適応性（Adaptability）とは？ 定義 適応性（Adaptability） とは、 👉 新しい状況や環境に対して、どれだけ容易にシステムを変更・調整できるか

〜AI Effect・AI技術・AIハードウェアを確実に理解する〜 ISTQB AI Tester認定試験では、単なる用語暗記ではなく **「概念を正しく理解しているか」**が問われます。 本記事では、Chapter 1（AIの基礎）を終えた後に確認すべき 代表的なサンプル問題3問を取り上げ、 試験で迷わない考え方を丁寧に解説します。 例題① AIエフェクト（AI Effect）に関する問題 問題 次のうち、**AIエフェクト（AI Effect）**の最も適切な例はどれでしょうか。 選択肢 A. AIベースのシステムが人間より安価で優秀なため、人々が職を失う B. AIが常に勝つため、コンピュータゲームの人気が低下する C. 医療診断に使われていたルールベースのエキスパートシステムは、もはやAIと見なされない D. 映画の影響で、AIが世界を支配すると人々が信じている 正解 C 解説 **AIエフェクト（AI Effect）**とは、 「かつてAIと呼ばれていた技術が、一般化・普及することで、 もはやAIと認識されなくなる現象」 を指します。 なぜCが正解か？ 1970〜80年代、ルールベースの医療診断システムはAIの代表例でした 技術が進歩した現在では、これらは「単なるソフトウェア」と見なされがち 時代の変化によってAIの定義が変わる、これこそがAIエフェクトです 他の選択肢が不正解な理由 A：社会的影響の話であり、AIエフェクトの定義ではない B：AIの性能と人気の話であり、定義変化とは無関係 D：SF的イメージであり、AIエフェクトではない 📌 試験対策ポイント 「昔はAIだったが、今はAIと呼ばれない」 この視点が出たら AI Effect を疑いましょう。 例題② AIを実装する技術に関する問題 問題 次のうち、AIを実装する技術ではないものはどれでしょうか。 選択肢 A. サポートベクターマシン（Support Vector Machine） B. デシジョンツリー（Decision Trees）

― AIシステムはどんなルールに基づいて作られているのか？ ISTQB AI Tester認定では、「AI技術そのもの」だけでなく、 **AIを取り巻く標準（Standards）や規制（Regulations）**についての理解も重要な学習ポイントです。 AIは自由に作って使える技術ではなく、 国際標準・業界標準・法律・規制によって支えられ、管理されています。 この記事では、ISTQB AI Testerのシラバス Chapter 1.9 に基づき、 AIに関わる主な国際標準 EU（GDPR）などの法規制 業界別（特に自動車分野）のAI関連規格 テスト観点で重要なポイント を、具体例を交えながら解説します。 AIと「標準」「規制」が重要な理由 AIは以下のような特徴を持つため、 従来のソフトウェア以上にルールが必要です。 データに依存する 結果が確率的（完全に同じ出力にならないことがある） 差別・偏り・誤判断のリスクがある 人の生命や権利に影響を与える場合がある そのため、 「どう作るか」「どう評価するか」「どこまで許されるか」を定めた 標準と規制が不可欠になります。 国際的なAI標準を策定する組織：ISO / IEC JTC 1 AIに関する国際標準の中心となる組織が、 ISO / IEC JTC 1（Joint Technical Committee 1） です。 ISO：国際標準化機構 IEC：国際電気標準会議 JTC 1：情報技術分野の合同技術委員会 このJTC 1が、AIを含むIT全般の国際標準を策定しています。 AI専門のサブコミッティ：SC 42 ISO/IEC JTC 1 SC 42（Artificial Intelligence） 設立：2017年 AIに特化した国際標準を策定

AI開発の現場では、ゼロからAIモデルを学習させるよりも、すでに学習済みのAIモデル（Pre-Trained Model）を活用することが一般的になっています。 このアプローチは「AI as a Service（AIaaS）」の流れとも深く関係しており、コスト削減や開発スピード向上の鍵となる考え方です。 本記事では、ISTQB AI Testerシラバス第1章「1.8 Pre-Trained Models（事前学習モデル）」の内容を、やさしく解説していきます。 また、Transfer Learning（転移学習）の概念や、これらを使う際のリスクと注意点についても詳しく解説します。 🧠 Pre-Trained Model（事前学習モデル）とは？ ● 定義 Pre-Trained Modelとは、「すでに学習済みのAIモデル」のことです。 膨大なデータを使って学習が済んでおり、私たちはそのモデルを再利用して新しいタスクに適用できます。 AIシステムを一から学習させるには、以下のような膨大なリソースが必要です。 ✅ データ準備（Data Preparation）：大量のデータを収集・分類・クリーニング ✅ モデル学習（Training）：高性能なGPUやクラウドコンピューティング環境 ✅ 人員・時間・コスト：専門家チームと長期間の作業 これらを全て社内でまかなうのは現実的ではないため、既存の学習済みモデルを利用するという手段が一般化しています。 💡 なぜPre-Trained Modelを使うのか？ 主な理由は次の3つです。 コスト削減 　モデルを一から学習させる場合、高額な計算リソースと人件費が必要です。 　事前学習モデルを使えば、その工程を大幅に省略できます。 時間の短縮 　学習済みモデルをベースにすれば、短期間でプロトタイプを構築可能です。 成功率の向上 　公開済みモデルは多くの研究者や企業によってテストされており、 　信頼性が高いという利点もあります。 🧩 Pre-Trained Modelの実例 例：画像分類モデル（Image Classification） たとえば「画像から物体を分類するAI」を作る場合、 ゼロから学習する代わりに、ImageNetという公開データセットを利用できます。 ImageNet：1,400万枚以上の画像を1,000カテゴリに分類したデータセット これを利用すれば、「犬」「猫」「車」などの基本的な識別能力をすでに持つモデルを使い、 自社の目的に合わせて拡張することができます。 よく使われる事前学習モデル例： モデル名 用途 提供元 Inception / VGG / AlexNet / MobileNet…