5 ポストモダン技術の出現

この資料はテスト技法セミナーのスライドに関する補助資料です．目次は右側に表示されます．

概要

2024–2025のAI進化に関して

5.1 2024–2025のAI進化に関して

スライドに対応する解説です．

AI進化の全体像

このスライドは，2024〜2025年のAI進化の大きな流れをマインドマップで示している．中心にあるのは「AIの進化」であり，そこから4つの主要テーマが派生する．エージェント化，AI IDE，協調AI，そして今後の方向性である．エージェント化は，AIが単なるチャットではなく，自律実行能力を獲得し，状態を保持しながら複雑なタスクを処理できるようになったことを意味する．AI IDEは，CursorやWindsurfの登場で，開発環境そのものがAIネイティブになり，プロジェクト全体の構造理解，自動修正，テスト生成まで担う段階に進んでいる．協調AIは複数エージェントが連携し，DevOpsを含む業務フローを自動化する方向性を指す．そして今後は，長期プロジェクトの自動化や自己修復システムなど，さらに大規模な業務自動化が進むと予測される．

(2)AI進化のタイムライン解説（2023–2025）

タイムラインでは，AIの進化を年次で整理している．2023年は対話型AIが成熟し，GPT-4を中心とした高度な言語モデルが普及した．2024年はAgent APIが公開され，AIが計画と行動を自律実行する新しい段階に入った．同年後半にはソフトウェア自動開発AI Devinが登場し，AIが人間の開発フロー全体を模倣する可能性を示した．2025年にはCursorやWindsurfが普及し，AIネイティブIDE時代が本格到来した．以降は複数エージェントが協調し，業務の完全自動化に向けて加速している．

(3)AIエージェントの構造解説

このスライドは，AIエージェントの基本構造をシンプルなループとして説明している．ユーザの指示が入力されると，AIはまずタスクを分解するPlanningを実行し，次にActionとして実際のコマンド実行やAPI操作を行う．その結果をFeedbackとして受け取り，再び計画を調整する．この一連のサイクルが何度も繰り返され，複雑なタスクを自律的に進めることが可能になる．これは「思考→行動→観察→修正」を続ける強化学習にも似たアーキテクチャであり，2024年以降のAIエージェントはこのループを標準装備し始めた．

(4)自律実行AI（エージェント）のワークフロー実例

この図は，エージェントが複雑タスクをどのようにこなしているかを示す．Plan（計画），Action（行動），Check（結果検証）という3段階を繰り返しながら，エージェントは自律的に作業を実行する．従来のAIは応答を返すのみだったが，2024年以降のAIはこのループにより，長時間・多手順のタスクを自動完遂できるようになった．ファイル生成，Web検索，API連携，Git操作などが自動処理され，業務自動化の中心を担う基盤となっている．

(5)Devinによる自律開発の流れ解説

Devinのワークフロー図では，ソフトウェア開発に特化したエージェントの動作を示す．要件理解から設計，実装，テスト実行，PR作成まで，人間のエンジニアが行うプロセスに沿って自律実行する．テストに失敗した場合は自動修正し，再度実行するループも備える．この仕組みにより，Devinは「開発プロジェクト全体を実行できる初のAI」として話題になった．ただし2024年時点では完全自律ではなく，実行時間・安全性・精度に課題もあり，現在はCursorなどのIDE統合型AIが実用性の面で主流になりつつある．

(6)AIネイティブIDE（Cursor/Windsurf）のアーキテクチャ解説

この図は，CursorなどのAI IDEがどのようにコードを扱うかを示している．従来のIDEと違い，AIエンジンはプロジェクト全体の構造を解析し，変更の影響範囲を把握する．ユーザの要求が入力されると，AIはリファクタリング，仕様変更，テスト生成などを自動で提案し，AI Diffによって変更理由と影響範囲を提示する．これにより開発は「AIと一緒に進める共同編集型」へ移行した．2025年時点ではCursorが最先端にあり，コード補完ではなく「コード操作そのもの」をAIが担当し始めている．

(7)複数エージェント協調の未来像解説

このスライドは，複数のエージェントが専門分化する未来の開発フローを示す．設計エージェント，実装エージェント，テストエージェントがワークフロー実行基盤で連携し，CI/CDと統合され，自動デプロイされる．デプロイ後はモニタリングAIが動作し，異常を検知したら自己修復AIが対応し，必要なら実装エージェントに修正版を指示する．この流れは「ソフトウェア開発〜運用」を完全自動化する未来のDevOpsを象徴している．

(8)Git連携を含む自動CI/CDパイプライン解説

この図では，AIがGitコミットを起点として自動化パイプラインを実行する流れを示す．Commitイベントを受け取るとAI Pipelineが起動し，テストの自動実行，デプロイ，自動監視へと流れる．結果は再びAIに戻り，学習や修正が行われる．2024年以降はGitHub ActionsやGitLab CIとAIエージェントが連携し，開発者は「コードを説明してコミットするだけ」で高度なCI/CDが自動化される環境が増えている．

(9)長期自律プロジェクトのAI実行解説

このスライドは，AIが短時間作業だけでなく，長期間にわたるプロジェクトを実行する未来像を示す．まず長期目標から長期計画を自動生成し，自律実行ループにより継続的にタスクを実行しながら学習と改善を繰り返す．段階的成果を納品しつつ，全体の方向性を常に評価する．これは「プロジェクトマネージャAI」とも言える能力であり，2025年には初期形態が登場し始めている．

(10)AIによる業務全体の自動化（マインドマップ）解説

最後のスライドは，業務自動化全体を俯瞰するマインドマップである．AIエージェント化により単純作業だけでなく，判断・計画・実行がAIに移り始めている．AI IDEの進化は開発業務の自動化を加速し，複数エージェントの協調は企業内のワークフロー自体を最適化する．今後は長期プロジェクトの自動化，自己修復インフラ，業務丸ごとのAI化が現実に近づいている．スライド1の構造と連動しており，全体像の締めくくりとして配置されている．

5.2 Cursor 出力結果

三角形判定関数テスト報告書

test_report.md の内容です．

1. テスト概要

1.1 テスト対象

関数名: triangle
関数シグネチャ: int triangle(int i, int j, int k)
仕様書: triangle_requirements.md
実装ファイル: triangle.c
テストフレームワーク: Unity

1.2 テスト実施日

2024年12月（実施日を記入）

1.3 テスト環境

OS: Linux
コンパイラ: GCC
テストフレームワーク: Unity (https://github.com/ThrowTheSwitch/Unity)
カバレッジツール: gcov

2. テスト戦略

2.1 テスト技法

同値クラス分割法: 入力値を同値クラスに分類し、各クラスから代表値を選択
境界値分析: 境界値付近のテストケースを追加
構造テスト: コードカバレッジ（C0: 命令網羅、C1: 分岐網羅）による網羅度測定

2.2 テストケース設計方針

以下の同値クラスに基づいてテストケースを設計：

EC-001: 正三角形
EC-002: 二等辺三角形（i = j ≠ k）
EC-003: 二等辺三角形（i = k ≠ j）
EC-004: 二等辺三角形（j = k ≠ i）
EC-005: 不等辺三角形
EC-006: 無効入力（辺の長さ < 1）
EC-007: 無効入力（三角形の成立条件を満たさない）

3. テストケース一覧

3.1 EC-001: 正三角形

テストケースID	入力値 (i, j, k)	期待結果	実測結果	判定
TC-001-001	(1, 1, 1)	2	2	PASS
TC-001-002	(2, 2, 2)	2	2	PASS
TC-001-003	(5, 5, 5)	2	2	PASS
TC-001-004	(10, 10, 10)	2	2	PASS

3.2 EC-002: 二等辺三角形（i = j ≠ k）

テストケースID	入力値 (i, j, k)	期待結果	実測結果	判定
TC-002-001	(2, 2, 3)	1	1	PASS
TC-002-002	(5, 5, 3)	1	1	PASS
TC-002-003	(5, 5, 7)	1	1	PASS

3.3 EC-003: 二等辺三角形（i = k ≠ j）

テストケースID	入力値 (i, j, k)	期待結果	実測結果	判定
TC-003-001	(2, 1, 2)	1	1	PASS
TC-003-002	(2, 3, 2)	1	1	PASS
TC-003-003	(5, 3, 5)	1	1	PASS
TC-003-004	(5, 7, 5)	1	1	PASS

3.4 EC-004: 二等辺三角形（j = k ≠ i）

テストケースID	入力値 (i, j, k)	期待結果	実測結果	判定
TC-004-001	(1, 2, 2)	1	1	PASS
TC-004-002	(3, 2, 2)	1	1	PASS
TC-004-003	(3, 5, 5)	1	1	PASS
TC-004-004	(7, 5, 5)	1	1	PASS

3.5 EC-005: 不等辺三角形

テストケースID	入力値 (i, j, k)	判定
TC-005-001	(2, 3, 4)	PASS
TC-005-002	(3, 4, 5)	PASS
TC-005-003	(4, 5, 6)	PASS
TC-005-004	(5, 6, 7)	PASS
TC-005-005	(10, 11, 12)	PASS

3.6 EC-006: 無効入力（辺の長さ < 1）

テストケースID	入力値 (i, j, k)	期待結果	実測結果	判定
TC-006-001	(0, 1, 1)	3	3	PASS
TC-006-002	(1, 0, 1)	3	3	PASS
TC-006-003	(1, 1, 0)	3	3	PASS
TC-006-004	(0, 0, 0)	3	3	PASS
TC-006-005	(-1, 5, 5)	3	3	PASS
TC-006-006	(5, -1, 5)	3	3	PASS
TC-006-007	(5, 5, -1)	3	3	PASS
TC-006-008	(-1, -1, -1)	3	3	PASS

3.7 EC-007: 無効入力（三角形の成立条件を満たさない）

テストケースID	入力値 (i, j, k)	期待結果	実測結果	判定
TC-007-001	(1, 2, 3)	3	3	PASS
TC-007-002	(1, 3, 2)	3	3	PASS
TC-007-003	(3, 1, 2)	3	3	PASS
TC-007-004	(1, 2, 4)	3	3	PASS
TC-007-005	(4, 1, 2)	3	3	PASS
TC-007-006	(2, 4, 1)	3	3	PASS
TC-007-007	(1, 2, 10)	3	3	PASS
TC-007-008	(1, 1, 2)	3	3	PASS
TC-007-009	(10, 5, 5)	3	3	PASS
TC-007-010	(5, 10, 5)	3	3	PASS
TC-007-011	(5, 5, 10)	3	3	PASS

3.8 統合テスト: 判定優先順位の確認

テストケースID	入力値 (i, j, k)	期待結果	実測結果	判定
TC-INT-001	(5, 5, 5)	2（正三角形が優先）	2	PASS
TC-INT-002	(5, 5, 3)	1（二等辺三角形）	1	PASS

4. テスト実行結果

4.1 テスト実行サマリー

=========================================
Running Unity tests...
=========================================
test_triangle_unity.c:182:test_EC001_equilateral_minimum:PASS
test_triangle_unity.c:183:test_EC001_equilateral_standard:PASS
test_triangle_unity.c:186:test_EC002_isosceles_i_equal_j:PASS
test_triangle_unity.c:189:test_EC003_isosceles_i_equal_k:PASS
test_triangle_unity.c:192:test_EC004_isosceles_j_equal_k:PASS
test_triangle_unity.c:195:test_EC005_scalene:PASS
test_triangle_unity.c:198:test_EC006_invalid_side_less_than_one:PASS
test_triangle_unity.c:201:test_EC007_invalid_triangle_condition_equal:PASS
test_triangle_unity.c:202:test_EC007_invalid_triangle_condition_less:PASS
test_triangle_unity.c:203:test_EC007_invalid_isosceles_shape:PASS
test_triangle_unity.c:206:test_priority_equilateral_over_isosceles:PASS
test_triangle_unity.c:207:test_priority_isosceles_over_scalene:PASS

-----------------------
12 Tests 0 Failures 0 Ignored 
OK
=========================================

4.2 テスト結果統計

項目	数値
総テストケース数	12テスト関数
総アサーション数	42アサーション
成功数	12
失敗数	0
無視数	0
成功率	100%

5. コードカバレッジ結果

5.1 カバレッジサマリー

File 'triangle.c'
Lines executed:100.00% of 10
Branches executed:100.00% of 22
Taken at least once:100.00% of 22
No calls

5.2 カバレッジ詳細

カバレッジ種別	達成率	目標	判定
命令網羅（C0）	100.00%	100%	✓ 達成
分岐網羅（C1）	100.00%	100%	✓ 達成
パス網羅	100.00%	100%	✓ 達成

5.3 カバレッジ詳細分析

関数全体

関数呼び出し回数: 42回
関数戻り率: 100%
ブロック実行率: 100%

分岐カバレッジ詳細

入力検証分岐 (i < 1 || j < 1 || k < 1)
- すべての分岐が実行済み
- 真偽両方のパスをカバー
三角形成立条件分岐 (i + j <= k || j + k <= i || k + i <= j)
- すべての分岐が実行済み
- 真偽両方のパスをカバー
正三角形判定分岐 (i == j && j == k)
- すべての分岐が実行済み
- 真偽両方のパスをカバー
二等辺三角形判定分岐 (i == j || j == k || k == i)
- すべての分岐が実行済み
- 真偽両方のパスをカバー

6. パス網羅度分析

6.1 パス網羅度

すべての実行可能パスがテストされ、パス網羅度は100%を達成しました。

6.2 主要な実行パス

パス1: 無効入力（辺 < 1） → 戻り値 3
パス2: 無効入力（成立条件不成立） → 戻り値 3
パス3: 正三角形 → 戻り値 2
パス4: 二等辺三角形 → 戻り値 1
パス5: 不等辺三角形 → 戻り値 0

すべてのパスがテストケースでカバーされています。

7. 不具合報告

7.1 発見された不具合

不具合なし

すべてのテストケースが正常にパスし、不具合は発見されませんでした。

8. テスト完了判定

8.1 完了基準

項目	基準	実績	判定
テストケース実行率	100%	100%	✓
テスト成功率	100%	100%	✓
命令網羅（C0）	100%	100%	✓
分岐網羅（C1）	100%	100%	✓
パス網羅	100%	100%	✓

8.2 判定結果

✓ テスト完了基準をすべて満たしました

すべてのテストケースが正常に実行され、成功しました
コードカバレッジ（命令網羅、分岐網羅）が100%を達成しました
パス網羅度が100%を達成しました
不具合は発見されませんでした

9. 推奨事項

9.1 追加テストの必要性

現在のテストケースで十分な網羅度を達成しているため、追加のテストケースは不要です。

9.2 今後の改善点

回帰テストの自動化（CI/CDへの統合）
パフォーマンステストの追加（必要に応じて）
静的解析ツールの導入（必要に応じて）

10. 付録

10.1 テスト実行コマンド

# Unityテストのビルド
make -f Makefile.unity

# テスト実行
make -f Makefile.unity run

# カバレッジ付きテスト実行
make -f Makefile.unity run-gcov

# カバレッジ結果確認
make -f Makefile.unity coverage

10.2 関連ファイル

triangle.c - テスト対象の実装
test_triangle_unity.c - Unityテストケース
Makefile.unity - Unityテスト用のMakefile
triangle_requirements.md - 仕様書
triangle.c.gcov - カバレッジ詳細レポート

承認

役割	名前	承認日	署名
テスト実施者	-	-	-
テスト責任者	-	-	-
開発責任者	-	-	-