この工程は何をするのか
IT パスポート試験シラバス Ver.6.5 の「25. システム開発技術」の定義。
④ 統合・テスト ・単体テスト済のプログラムを統合し，ソフトウェア・システムが要件どおりに動作するかどうかを確認すること ・テストには計画，実施，評価のサイクルがあること ・テストを実施するときに，目標に対する実績を評価する必要があること 用語例 統合テスト，ブラックボックステスト，性能テスト，負荷テスト，回帰テスト（リグレッションテスト）
部品が揃ったので、組み立てて確かめる工程。 シラバスがわざわざ「計画，実施，評価のサイクル」「目標に対する実績を評価」と書いているとおり、やみくもに動かすのではなく、何をどこまで確かめたかを測ることが求められる。
用語例の整理
| 用語 | 何を確かめるか |
|---|---|
| 統合テスト | 部品同士のつなぎ目が正しいか |
| ブラックボックステスト | 中身を見ず、入力と出力だけで正しいか |
| 性能テスト | 決めた速さを満たすか |
| 負荷テスト | 想定の量に耐えるか |
| 回帰テスト（リグレッションテスト） | 直したことで、前は動いていた所が壊れていないか |
回帰テストが AI と組み合わせるうえで重要になる。変更の量が増えるほど、壊した所に気付かない確率が上がる。
具体的な成果物
| 成果物 | 中身 |
|---|---|
| テスト計画 | 何を、どの観点で、どこまで確かめるか |
| テストの実施記録 | 実際に流した結果 |
| 目標に対する実績の評価 | 決めた基準を満たしたかどうかの判定 |
つまずきやすいところ
「動いた」で終わらせて、評価をしない。 シラバスが「目標に対する実績を評価する必要がある」と念を押しているのはここ。基準を決めずに流したテストは、通っても何も保証しない。
回帰テストを人手でやろうとすると、続かない。 変更のたびに全部を手で確かめるのは現実的でないので、自動で流れる形にしておく必要がある。
AI に任せられる範囲
変更のたびに自動で流す
Claude Code の hooks は、ライフサイクルの特定の時点で自動実行される、ユーザー定義のシェルコマンド・HTTP エンドポイント・LLM プロンプト（facts/claude-code/hooks.md）。テストを回すのに使えるイベントが揃っている。
| イベント | 発火するタイミング |
|---|---|
PostToolUse | ツール呼び出しの成功後 |
PostToolUseFailure | ツール呼び出しの失敗後 |
PostToolBatch | 並列ツール呼び出しのバッチ全体が解決した後、次のモデル呼び出しの前 |
Stop | Claude が応答を終えたとき |
FileChanged | 監視対象のファイルがディスク上で変わったとき。matcher で監視対象を指定する |
PostToolUse や FileChanged にテストコマンドを結び付ければ、編集のたびに回帰テストが自動で流れる。人が思い出して実行する必要が無くなる。
出典はターミナル、IDE 拡張、デスクトップアプリ、Claude Code on the web のいずれでも同じ hook イベントが発火すると書いている。使う場所によって挙動が変わらない。
CI から呼ぶ
headless は claude -p（--print）で非対話実行する方法で、スクリプトや CI/CD から Agent SDK の CLI として使うことを想定している（facts/claude-code/headless.md）。
出典に、CI で使うことを前提にした記述がある。設定検証でスキップされた MCP エントリは mcp_server_errors に報告され、エラーが無いときはキーが省略されるため、非空配列で CI を落とせる（v2.1.219 以降が必要）。テストの結果を機械的に判定して止めるという使い方が想定されている。
まだ人がやること
何を確かめるかを決めること。 シラバスの「テスト計画」にあたる部分。どの観点をどこまで確かめれば十分かは、業務上の影響の大きさから決まる。
目標値を置くこと。 性能テスト・負荷テストの合否は、システム要件定義で決めた数値と突き合わせて判定する。その数値が無いと、テストを流しても評価にならない。
通らなかったときに、直すか受け入れるかを決めること。 締切と品質のどちらを取るかは技術判断ではない。
ai_leverage を high ではなく medium にしているのはこのため。実施は完全に自動化できるが、計画と評価が人に残っている。 シラバスが挙げる3つのサイクル（計画・実施・評価）のうち、任せられるのは真ん中だけになる。