AI駆動TDD ― 2026年10月版

AI駆動開発において、TDDと適切なレイヤー設計を活用し、生産性と品質を高めるための資料です。

工程ごとに考える対象を分けること、Skipテストによる仕様管理、人間のレビュー、AIへの指示と履歴管理を紹介します。付録にはTDD作業指示の全文を掲載しています。

Transcript

1. AI駆動TDD 2026年10月版
2. 序章 AI駆動開発とソフトウェア工学 001
3. 人間とAIで、保守しやすいコードの条件はほぼ同じ 責務と依存関係が明確 暗黙の前提が少ない 変更の影響が局所化されている 従来のソフトウェア工学の知見は、AI駆動開発でもそのまま重要 002
4. レイヤー設計とTDDの両方を採用する レイヤー設計 • 作業する位置を 限定する TDD • 作業する工程を 限定する 003
5. 二つの手法を採用して得られた効果 AIの混乱と手戻りを抑える 無駄な利用枠消費を減らす 作業効率は体感で10倍以上 本資料では、レイヤー設計とTDDを中心に、生産性と品質を高める考え方・実 践方法を紹介します。 004
6. 第1章 システム開発のボトルネック 005
7. システム開発のボトルネックは情報のやり取り 人間の抽象的な要求 人間が段階的に詳細化 コンピュータが実行できる 具体的な命令 初期のシステム開発では 006
8. AI以前から、情報伝達は抽象化によって効率化されてきた 開発技術の発達 情報の抽象化 • 人間の作業をコンピュー タに任せる • 少ない指示で複雑な処理 を実現する 情報伝達の効率は指数関数的に向上 007
9. 「プログラミング不要」は、今回が初めてではない バイナリを直接書く • 当時の「プログラム」 コンパイラの登場 • バイナリ生成を自動化 • ソースコードが新たな「プログラム」に フレームワーク・IDEの普及 • コードを直接書く作業がさらに減少 008
10. AIの登場で、人間の仕事はコード入力からレビューへ 要求を伝える • 人間が 自然言語で指 示 結果を レビューする コード・画面を 生成する • 人間が不足や 問題点を指摘 • AIが 生成・修正 情報伝達の効率は、さらに数倍に向上 009
11. 要求は開発しながら具体化できる まず、 大まかな要求 を 伝える 足りない条件 や新たな要求 を追加する 生成結果を見 て 不足に気づく 要求の整理と開発を並行して進められる 010
12. 要求の伝え方が変わっても、必要な情報量は減らない 最初にまとめて伝える 往復しながら少しずつ伝え る • 要求や条件を事前に整理 する • 生成結果のレビューと指 摘を繰り返す 伝えなければならない要求や条件の情報量は減らない 011
13. 効率化すべきは、情報のやり取り全体 要求を 提示する 問題点を 指摘して 修正させ る 生成結果 を確認す る ボトルネックは、今も人間とコンピュータの情報のやり取り 012
14. 第2章 AIは何をしているのか 013
15. LLMは次に来そうな単語の確率分布を予測する 学習済みの知識 • 膨大な文章・プログラ ム コンテキスト • 質問・会話・資料 予測するもの •次に来そうな単語の確率分布 014
16. 次に来そうな単語を選び続ければ文章になる 次に来そうな単語を選ぶ 選択を繰り返す 文章ができあがる 人格をシミュレートしているわけではない 015
17. なぜ高度な回答ができるのか 質問への回答 プログラムの作成 • 非常に博識な人間 • 凄腕のプログラマー 次の一言の確率分布を計算する 016
18. なぜハルシネーションが起きるのか 言葉の確率 • 次の一言として続く確率 事実の確率 • 回答内容が正しい確率 LLMが計算しているのは前者の確率 017
19. 正解を知らなくても、確率計算はできてしまう 正解を特定する情報が、学習済みの知識にもコンテキストにもない 次の一言の確率計算 • 何の支障もなく実行できる 文章の生成 • 正解が分からないまま回答できる その結果、事実と異なる回答も生成される＝ハルシネーション 018
20. AIは正解が分からなくても自信ありげに答える 正解を特定できる情報がなくても、 LLMは自信ありげに回答することがある 回答が自信ありげであることと、その回答が正しいことは別 019
21. コンテキストに必要な情報があるかで回答は変わる 正解を特定できる情報があ る 必要な情報が不足している • 正しい回答が得られる確 率が高い • もっともらしい誤答の可 能性 020
22. 回答が長く複雑になるほど、確率的に誤りが含まれやすい 長く複雑な回答 • 一部に誤りが含まれる確率が高まる 短く明確な回答 • 正しい回答が得られる確率が高い傾向 021
23. 正解を特定できる状況を作る 必要な情報 が揃ってい る 正解を特 定できる 状況 一度に扱う 範囲が限定 されている 求める出力 が 明確に なっている 022
24. 第3章 レイヤー設計によって AIの作業を単純化する 023
25. レイヤー設計でAIが考慮する範囲を小さくする 変更理由に応じて責務を分離 実装先が明確になる 各レイヤーのコードを 短く単純に保てる AIが一度に考えることを減らす 024
26. 既存の設計原則を活用する 広く使われている設計原則や ベストプラクティスを利用する 025
27. レイヤー構成は必要最小限から始める 必要最小限の構成から始め、 開発しながら育てていく 026
28. Webアプリケーションの構成例 画面 • 表示・入力・イベント ViewModel • 画面の状態・操作・判断 Client Application HTTP境界 Server Application Domain Infrastructure • クライアント操作・API利用・状態管理 • 通信契約・DTO変換 • 業務操作の進行・取得と保存 • 業務の状態・規則・判断・状態変化 • DB・外部サービスとの接続 これは一例。必要なレイヤー数やプロジェクト分割を定めるものではない 027
29. 変更内容から実装先が決まる 変更内容：業務上の判断 画面 ViewModel Client Application HTTP境界 Server Application Domain Infrastructure 全体構成を考え直さなくてよい 028
30. Domainに業務の複雑さを集める Domain •複雑な業務規則 複雑になる場所を限定する 029
31. 広く使われる設計パターンはAIの予備知識になる 広く使われる 設計パターン 独自の構造 • AIの学習済み知識を利用 できる • 未説明の決まりは推測す る必要がある 設計上の誤った推測を減らせる 030
32. AIは設計原則を知っていても、実践できるとは限らない 知識 • 設計原則について高度な議論ができる 実践 • 設計原則に反するコードを書くことがある AIでは知識と実践の隔たりが人間以上に大きい 031
33. 自分の間違いを手本にして、間違いを増やす 誤ったコード を書く 同じ間違いを 繰り返す 既存コードを 調べる • 自分の書いた 間違いも参照 する 「既存のコードもこうなってますし」 （それを書いたのもAI自身） 032
34. AIによる開発に、ツールによる自動検査を併用する AIによるコー ド生成 ツールによる 自動検査 •実装・修正 •自動テスト ・静的解析 AIはルールを守らない 033
35. 第4章 TDDによって AIの作業と判断を小さくする 034
36. TDDはRed → Green → Refactorの短いサイクル TDD（テスト駆動開発）は、テストを先に書き、実装と設計改善を繰り返しながらソフトウェアを発 展させる開発手法です。 Red Refactor Green 035
37. Red・Green・Refactorで行うこと Red（外部設計） Green（最小限の実装） Refactor（内部設計） 次の振る舞いをテストに記述 意図した理由で失敗することを確認 利用側から見た仕様・APIの使いやすさを考える 現在のテストを通す最小限の実装に集中 内部設計の改善や将来機能は考えない テストが通る状態を維持 重複・責務・依存関係を見直して改善 036
38. TDDは工程ごとに考える対象を分離する 外部設計を考える 何も考えずに 実装する 内部設計を考える テストを先に書くだけではない 037
39. 仕様や設計は開発しながら発見していく 小さな実装 設計改善 次に必要な仕様や設計を発見 最初から全部決めなくてもいい 038
40. TDDはAIへの指示を小さく区切れる AI駆動開発と相性がよい理由① 作業範囲を限定する 目的を明確にし、結果を 確認する • 一度に扱う仕様と判断を 絞る • 混乱や無関係な実装を減 らす • 各工程の目的が明確 • 自動テストでフィードバ ック • 問題を小さな範囲で修正 作業も修正も、小さく 039
41. TDDは人間のレビューを容易にする AI駆動開発と相性がよい理由② 小さな仕様単位で開発 • 対応するコミット履歴を残す 変更の目的と実装内容が明確 目的の絞られた変更を順にレビュー 大量の変更を一度にレビューするのは無理。 小さく分ければ、順に確認できる。 040
42. レイヤー設計とTDDを組み合わせる レイヤー設計 TDD • 実装する場所と責務 を明確にする • コードを短くシンプ ルに保ちやすい • 仕様と実装範囲を小 さく区切る • Refactorで責務・依存 関係を見直し、レイ ヤー構造を維持・発 展させる 複雑なシステムも、小さな作業の積み重ねで開発する 041
43. 第5章 要求や資料をAIに伝える 042
44. 手元にある資料を、そのままAIに渡す AIに必要な情報を十分に伝える 手元にある資料 • ラフな設計・議事録・メモ • 既存の帳票 • 紙を撮影した画像・スキャン資料 • 整理された仕様書 形式や完成度にこだわらない 043
45. 資料の位置づけもAIに伝える 資料に矛盾や不足がある場合 検討途中の資料 • 仮にまとめてよい レビュー済みの資料 • 正式な仕様である 判断できない点は対話で補う 044
46. 開発途中の資料更新もAIに伝える 開発途中で資料が更新される 変更内容をAIに伝える 実際の資料管理の例 Teams・SharePoint上の資料 Git管理の docs に簡潔な資料を配置 最初に渡して終わりではない 045
47. 実際に動く画面で要求を具体化する アジャイル開発における顧客からの要求収集 ラフな要求から暫定画面 を作る 顧客と実際に操作して確 かめる 顧客の要求を具体化する AIに画面を作らせる 不足する項目・使いにく い動作を指摘 発見した要求を次の修正 に反映 実際に触ると、改善点が見えてくる 046
48. AI駆動TDDで要求変更に対応する 要求の追加・変更 • その都度Redのテストに反映 実装・修正 • 大部分をAIに任せる 既存の動作を確認しながら変更 • TDDのテストで確認 著者の実感 手戻りのコストがほとんど気にならなくなった 047
49. Redのテストで外部仕様を記述する Redのテスト •次に実現する振る舞いを記述 •期待結果を明確にする 複雑なロジック・公開APIなど、画面では判断できない仕様にも適用 期待する振る舞いを、実行可能な仕様にする 048
50. 第6章 AIにTDDを進めさせる 049
51. AIにはTDDの工程を具体的に指示する TDDでAIが一度に考える範囲を限定する 工程ごとの具体的な規則 何を行うか 何を行わないか 「何を行わないか」まで具体的に 050
52. Redでは外部設計に集中する 工程ごとに考える対象を分離する／Red 正しい外部設計をテストとして表現する 利用側から見た仕様・APIを考える 意図した理由で失敗することを確認する 必要な場合の補助作業：未実装APIの仮宣言・仮実装 テストを実行できる状態にするためのもので、機能の実装ではない Redの仮実装は、Greenの機能実装ではない 051
53. Greenでは必要最小限の実装に集中する 工程ごとに考える対象を分離する／Green とにかくテストを通す 対象テストと既存テストを通す ベタ書き・コピペでも構わない AIが余計な実装を追加していな いか確認 今回追加したコードだけが対象 必要のない処理を追加していた場合は 取り除く Greenではリファクタリングを行わない 綺麗なコードは書こうとしない 052
54. Refactorでは内部設計を改善する 内部設計を見直す コードの重複 責務 依存関係 アルゴリズムの妥当性 テストが通る状態を維持／必要に応じて改善／変更不要なら終了 新しい仕様や不具合は記録して、次のRedで扱う 053
55. AIの作業を工程単位で止める 各工程の目的と終了条件を明確にする • Red・Green・Refactor 指定した工程の終了時に作業を止める • Redまで • Greenまで • Refactorまで 一度に複数の問題を解決させない 054
56. 新しい指示はその場でテストとして記録する 新しい仕様や修正要求を受け る その場でテストとして 記述する 条件や判断の意図が明確なう ちに 仕様を完全に固定し、いつでも確認できる 055
57. 未着手の仕様はテストとして保留する 未着手の仕様 •テストとして保存しておく •実行は保留する xUnit Skip／NUnit Ignore／Jest test.skip 仕様を確定しても、実装は後回しにできる 056
58. 保留したテストを一件ずつ有効化する 保留したテストを一件選ぶ • 有効化して実行する 意図した理由で失敗 既に成功 •Green・Refactorへ 進む •既存実装が仕様を 満たすことを確認 057
59. Skipテストには実行順序も記録する Skipテストをまとめて作成する • 実行順序を決める • 各テストのSkipのテキストに記録する Skipを外すとき • 記録した順序を確認する • 次に外すテストを決める 実行順序もSkipに書いておく 058
60. 仕様をテストとして確定し、一件ずつ実装する 指示された内容を具体的な入出力で表 現する • 入力条件を定める • 期待する結果を定める テストとして仕様を確定する 確定した仕様から実装する仕事 を一件ずつ取り出す 一度に多数のテストを書いた場合、未実装APIの仮宣言も多く必要になることがあります。この場合も、先 ほどの未実装スタブを利用できます。 最初から全仕様を確定させる必要はない 059
61. 別件の課題と、現在の作業による失敗を区別する 現在の作業とは別の 不具合・不足仕様 現在の作業で既存テ ストが失敗 • 必要ならSkipテスト として記録する • 後のRedから扱う • Skipして保留しない • Green・Refactorでは 成功状態を維持する 今回失敗させた既存テストをSkipして先へ進まない 060
62. 仕様変更では、テストを仕様に合わせる 仕様に合わせてテス • 変更後の仕様を先にテストへ反映する • 旧仕様のテストは必要に応じて変更する トを変更する 実装に合わせてテス • 失敗したテストの期待値を現在の実装に合わせて書き 換えない トを変更しない テストの基準は実装ではなく、仕様 061
63. 既存機能の変更では、新規追加と手順が異なる Red ① 変更したい機能のテストを修正 Green ① 修正したテストを通す Red ② 失敗した既存テストを精査・修正 Green ② すべてのテストを通す Refactor 内部設計を改善 062
64. Red①では既存テストを新しい仕様に合わせる 新規機能の追加 必要な振る舞いをテストとして記述 既存仕様の変更 既存テストを新しい仕様に 合わせて修正 両者に共通 意図した理由でRedになることを確認 063
65. Green①では変更したテストを先に通す 新規機能の追加 対象テストと既存テストをすべて成功 させる 既存仕様の変更 まず変更したテストを成功させる ほかの既存テストには失敗が残る場合がある 次のRed②で失敗した既存テストを精査する Green①では、まだすべてのテストが成功するとは限らない 064
66. Red②では変更すべきテストを見分ける 新規機能の追加 既存仕様の変更 既存テストを変更せず、成功状態を維 持する 失敗した既存テストの変更要否を判断 する Red②：失敗した既存テストを精査する 仕様変更に伴い、仕様どおりの挙動が変わった部分 テストを新しい仕様に合わせて修正 仕様変更後も、仕様どおりの挙動が変わらない部分 テストは変更しない 変更すべきテストと、維持すべきテストを見分ける 065
67. Green②ではすべてのテストを通す すべてのテストを通す 必要最小限の実装修正を行う 066
68. Refactorは新規機能の追加と同じ 新規機能の追加も、既存仕様の変更も同じ テストが通る状態を維持しながら、内部設計を改善する 067
69. 変更箇所が多い場合も、一件ずつ進める 変更箇所が多い場合 テストをSkipで保留する 一件ずつ取り組む 変更が多くても、小さな単位で進められる 068
70. TDDは指示を育てても人間のレビューが必要 TDDを指示しない場合 TDDを指示し、 違反をしつこく指摘しても 指示を工夫し、規則を育て る • 与えられた仕様を理解する • 一気にプログラムを実装する • その後でテスト・修正する • Red・Green・Refactorの原則を守らないことが多い • 付録のTDD向け指示ファイルのように改善する • わりと守るようになるが、人間のレビューは必要 それほど有効なら、なぜ最初からTDDを使わないのか？ 開発元は、AIにはTDDが向かないと判断して、あえて採用させていないのか？ 069
71. AIはTDDの実践過程を十分に学習できていない？ 公開されている ソースコードやテスト • 完成したものが中心 完成したコードからは 分からないこと • Red：どのような外部設計 を考えたか • Green：どのように実装を 限定したか • Refactor：どのように 内部設計を改善したか TDDを説明できても、実践できるとは限らない 070
72. AIはTDDを説明できても、実践では守れないことがある TDDについて議論さ せると • TDDを深く理解した高度な説明ができる 実際に実装させると • Greenでテストにない機能まで実装してしまうことが ほとんど Greenなのに、テストにない機能まで実装してしまう 071
73. AI研究の現場ではTDDが普及していない？ AI研究者の開発文化 （著者の印象） TDDが重視すること • 複雑なアルゴリズムを 一気に書き上げる能力が 重視される • 研究用コードは実験後に 使い捨てられることもあ る • 個人の才能に依存しない 再現可能な開発手順 • 製品品質と作業効率を 安定して維持する 研究の現場では、TDDの価値を実感しにくいのでは？ 072
74. TDDの有効性を評価するには、適切な実験条件が必要 TDDの一部分を扱う 研究 • テストの先後を比較（開発時間・不具合数） • 与えられたテストでプログラムを生成・修正 TDDそのものを評価 するには • TDDを理解した参加者 • Red・Green・Refactorを一体として実践 • 設計品質・継続的な変更のしやすさを評価 テストの先後や、与えられたテストによる プログラム生成だけでは、TDDそのものを評価できない 073
75. AI研究ではTDDの価値が十分に反映されていない？ 学習データ • 完成したコードが中心では、Red・Green・ Refactorの実践過程を学びにくい 研究者の開発 文化 • 一気に実装し、研究後は使い捨てる開発では、 再現可能な手順や保守性の価値を 実感しにくい モデルの訓練 ・評価方法 • 完成したプログラムの動作だけで 評価するなら、TDDによる設計上の改善が 評価されにくい 074
76. AIがTDDを自発的に使わないことと、TDDへの適性は別問題 TDDを明示しない場合 • 一気に実装し、 後からテスト・修正する TDDを明示した場合 • TDDの各工程と原則を指 示 • 良好な結果が得られてい る 自発的にTDDを使わないことは、TDDに向いていないことを意味しない 075
77. 開発元はTDDを不向きと判断しているのか？ なぜ開発元の意図を検討したのか • 開発元が推奨しない使い方には、 技術的な理由がある可能性 • 公開方針やロードマップは、 技術選定の重要な判断材料 検討した結果 • AIがTDDを標準で採用しない理由について 、複数の可能性が考えられた • AIにTDDが不向きだとする 根拠は見当たらなかった 076
78. 第7章 人間によるレビュー 077
79. 人間のレビューは重要な問題に集中させる 人間に残る役割 • 仕様・設計の妥当性を判断する レビューの課題 • AIが生成した大量のコード・テストを すべて詳細には確認できない レビューの工夫 • 必要な情報を短時間で確認する • 重要な問題にレビューを集中させる 078
80. 必要になったらテストを読んで仕様を調べる テストに仕様を記述する • 外部から見た振る舞いを記述する • 漏れなく記述できれば完全な外部仕様書になる • 仕様として読めるテストを用意する テストを使って仕様を調べ • 必要になったときに該当するテストを読む る • 実際の仕様を短時間で把握する 必要なときにテストを読めば、実際の仕様が分かる 079
81. テストは数秒で仕様を理解できるようにする テスト本文から 読み取れるようにする • どのような入力か • どのような結果を期待す るか • 期待値は補助メソッドの 引数などに残す 長い場合は補助メソッド へ切り出す • テスト対象の準備 • モックの設定 • 付随的な検証処理 そのテストで確認する仕様以外に目がいかないようにする 080
82. 画面テストではViewModelのテストを活用する 画面テストの課題 • 画面要素の検索や準備処理が多い • テストから仕様を読み取りにくい 実施している工夫 • 画面全体のテストが必要ない処理 は、ViewModelのテストで確認す る 081
83. 小学校で習った「確かめ算」 計算をやり直して、答えが正しいか確かめる方法です。 同じ方法でもう一 度計算する なるべく違う方法 で計算する •同じ間違いを繰 り返す可能性が ある •結果が一致する か確認する 同じ間違いを繰り返さないための工夫 082
84. TDDに生きる「確かめ算」の原理 テストの期待結果と実行結果を突き合わせる Red：外部設計 • 期待する振る舞いをテストで表す Green・Refactor：実 装と内部設計 • テストを通す実装を作る • 動作を維持して内部設計を改善する 確認済みの動作は、人間が重複してレビューしない 083
85. 人間のレビューは工程ごとの重要な判断に集中する Red：外部設計 Green：過剰実装 Refactor：内部設計 テストの可読性 外部仕様・公開APIの使いやすさ テストに不要な分岐・処理がないか コードの可読性 責務・依存関係・重複・抽象化 プロセスやツールで確認済みのことは、人間が重複してレビューしない 084
86. Skipテストのレビューは明らかな仕様の間違いに集中する テストコードの実装 仕様そのもの • Skip解除後、意図した理由 で Redになるか確認 • Greenでテストと実装を突 き合わせる • 仕様を取り違えても Greenまで進んでしまう • 明らかにおかしい仕様がな いか ざっと確認する • 実装上の間違いは通常その 過程で発見される • 人間は細かく確認しない 085
87. レビューのタイミングは開発対象の複雑さで変える 定型的な処理 • RedとGreenの結果をまとめてレビュー • テストコードと実装コードの変更を区別しやすい 定型的でないAPI設 計 • Redで外部設計をレビューしてからGreenへ • 実装前にAPIの使いやすさ・設計の妥当性を確認する 定型的な処理では、Red直後のレビューを省略できる 086
88. 逐次レビューと履歴レビュー AIの作業・コミット単位は両方式とも同じく小さな単位（例では3件）。 逐次レビュー 履歴レビュー AIの作業①・コミット① AIの作業①・コミット① 人間のレビュー① AIの作業②・コミット② AIの作業②・コミット② AIの作業③・コミット③ 人間のレビュー② 人間のレビュー① AIの作業③・コミット③ 人間のレビュー② 人間のレビュー③ 人間のレビュー③ AIにはまとめて作業させても、レビューは一件ずつ 087
89. 履歴レビューの適用条件と注意点 履歴レビューが有効 な場合 履歴レビューが向か ない場合 • 小規模で自明な実装 がほとんど • 指摘事項がほとんど なく、レビューは見 るだけで済む • 数コミットに1件程 度の指摘が発生 • 変更が積み重なり、 個別修正が難しくな る 指摘事項が何件も溜まるほど、履歴を貯めない 088
90. レビュー方法の使い分け • レビューの負担 履歴レビュー • 小さなコミットでも、後から大量に確認するのは疲れ る • 主な利用場面 • 一般的なWebアプリケーションの定型処理 • レビューの負担 逐次レビュー • 問題を一つずつ解決でき、精神的にはるかに楽 • 主な利用場面 • 設計が複雑なクラスライブラリの開発 複雑さ・納期・レビュー負担で使い分ける 089
91. 第8章 AIに守らせる規則の設計と管理 090
92. AIに守らせる規則を整理する 共通規則 • 作業範囲・Git操作・結果確認 設計規則 • レイヤーの責務・依存方向・DTO TDD規則 • Red・Green・Refactor 言語固有の規則 • C#・テスト・ビルド プロジェクト固有の規則 • 採用技術・固有の設計制約 同じ指示を繰り返すより、規則として保存する 091
93. AGENTS.mdとSkillsの使い分け AGENTS.md Skills • 基本的な指示とし て参照 • 継続して守らせる 規則や参照先を記 録 • 作業に応じた詳細 な手順 • AIが選択したとき に読み込まれる 常に守らせたい規則をSkillsだけに置かない 092
94. 失敗や指摘から規則を改善する 問題や繰り返す指摘を発見 • 例：Greenの過剰実装・指示範囲外の作業 AIに規則として記録させる • 「今の指摘をルールにしておいて」 追加された規則を人間がレビュー • 意図した内容か・継続して適用すべきか 規則は開発しながら育てる 093
95. 規則を整理しても、意味を変えない • 長いこと自体は問題ではない • 複雑になりすぎたら整理を検討 規則が蓄積する • 重複を解消する • 重要な条件が抜け落ちることもある AIに規則を整理させる 変更前後の差分をレビュー • 禁止事項・適用条件・論点の欠落を確認 短さより、規則の実効性 094
96. 第9章 AIを活用した検証と作業の効率化 095
97. 課金を節約するために、AIに考えさせる作業を減らす 機械的な実行・判定は開発ツールに • ビルド・テスト・静的解析 繰り返す処理はスクリプト化 • 実行・ファイル操作・結果集約 • スクリプト自体もAIに作らせる AIには必要な結果だけを渡す • 大量のログを避け、判断に集中させる ツールができる処理を、LLMに考えさせない 096
98. AIにテスト条件そのものを発見させる 高性能モデル・高推論レベ ル • 「問題点を指摘して」 • 実装・既存テストを調査 • 不足しているテスト条件を発見 安価なモデル • テストを追加・修正 • 未着手のテストはSkipで管理 フィンランド語設定でのみ発生するバグ AIが発見 → 再現テストを作成 → Redで失敗を確認 → Greenで成功 097
99. テストデータの作成もAIに任せる 再現したいテスト条件を指定 • ファイル形式・言語設定・書式など AIにテスト用ファイルを作成させる • 特殊な条件を含むWord・Excelなどのファイル 作成したファイルでテストする • 読み込みテスト・WordではOOXML形式も検証 098
100. 複数のチャットで並行して作業する AI側：別々の仕事を並行実行 • 作業① • 作業② • 作業③ 人間：完了した仕事から対応 • 結果をレビュー • 指摘・次の指示 • 次に完了した仕事へ 作業内容を忘れたら、会話や作業報告を読み返すか、AIに説明させる。 並行数は、人間が無理なく管理できる範囲まで 099
101. Gitの作業ツリーでチャットごとの作業環境を分ける 作業ツリーA ・ブランチA チャットA 独立した 編集・テスト 一つのGit リポジトリ 作業ツリーB ・ブランチB チャットB 独立した 編集・テスト 複数のチャットで同じ作業ツリーを共有しない 100
102. 作業ツリーの配置と後片付け 初期設定（一度だけ） • 作業ツリー専用の親ディレクトリを用意 • Codexのアクセス権限を設定 各作業で繰り返す 開始時 終了時 • 専用ディレクトリの下に作業ツリ ーを作成 • 担当チャットに割り当てる • 成果物をレビューして変更を統合 • 未統合の変更を確認 • 不要な作業ツリーとブランチを削 除 共通データベースなどの外部環境は、作業ツリーでは自動的に分離されない 101
103. AIは論点を整理する段階から役立つ 断片的な考えをAIに伝える • メモ・経験・思いついたこと AIが話の関係を整理する • 一つの論点にまとめる 自分の考えが明確になる • 出来上がった文章を読んで気づく 「自分はこういうことを書きたかったのか」 102
104. 考えがまとまらないときはAIにインタビューさせる AIにインタビューを 依頼する • 論点がまだまとまっていなくてもよい 質問と回答を繰り返す • AIが次の質問を考え、人間の考えや経験を引き出す 必要な情報が集まったら 整理・文章化 • 質問を続けること自体は目的にしない 実例：この資料の後半部分もインタビュー方式で作成 103
105. AIは読者目線で説明を補い、丁寧に伝える 技術者の端的な説明 AIによる 読者向けの説明 • 一文に情報を凝縮し、 自分の思考や検討には効 率的 • 一文を五行ほどに展開し 、前提や論理のつながり を丁寧に説明する 言葉の選び方にも優れている。 読みやすい資料には、増えた文章が必要 104
106. AIが活用できる膨大な技術知識 学習済みの膨大な情 • 技術書・論文・GitHubの公開コードなど • 人間が読むなら数十万年規模の情報量 報 Web検索による追加 調査 • 学習していない情報も調査 • 関連資料を短時間で収集・比較 Meta Llama 3.1の学習規模を英語文章に換算。1日8時間の読書を想定。 105
107. AIは存在しない資料を実在すると断言することがある 実在しない資料を 提示することがある 出典を掲載する前の確 認 • 存在しない論文や文献 を「あります」と断言 する • もっともらしい出典情 報まで 示すことがある • その資料は本当に存在 するか • 実際にその主張を裏付 けているか 最近のモデルでは、著者自身はこうした事例をあまり見かけなくなった。 106
108. AIの文章は自然でも、伝える目的が抜ける AIが生成する文章 • 読みやすく、個々の文も自然 • しかし、伝える目的が抜けることがある 抜け落ちる目的 • 誰に何を伝えるのか • 読者にどう感じてもらうのか 人間によるレビュー • 文章の目的や読者に与えたい印象を指摘 • 一度か二度で修正できることも多い 文章の目的は、人間が確認する 107
109. AIの推敲では、伝えたい観点が失われることがある AIによる文章の推敲 人間による変更前後の比較 • 文章が読みやすくなる • 書き手が伝えたい観点や 主張が抜けることがある • 原文で伝えたかったこと が維持されているか • 重要な論点・条件・論理 が 残っているか • 技術的な正確さが保たれ ているか 読みやすさだけで、推敲を評価しない 108
110. 長い資料は一節ずつ作成し、レビューする 一節ずつ作成・ レビュー • 本文を一度に全部書かせない • 節ごとに確認して進める 長い資料で起き る問題 • 一節の修正が別の章と矛盾する • 章立ての変更で参照関係が崩れる 変更の対象を明 確にする • 本文の修正と構成の変更を区別す る 何を変更するのか、明確にして進める 109
111. 推敲を重ねると文章も論点も増えていく 推敲による文章の 長文化 増えた文章の中身 • 説明の追加や表現の調整 が積み重なる • AIだけでなく人間も同じ • 読者の理解に必要な説明 もある • 重複や不要な論点も残り やすい 110
112. 資料全体の論理を深く理解し、慎重に枝刈りする 資料完成後にまとめて時間をかけて検討 • 推敲で増えた重複や不要な論点を洗い出す • 個々の節だけでなく資料全体を検討する 高い推論レベルのAIが修正候補を提案 • 削除・統合・再配置の候補と理由を一覧化 • この段階では原稿を書き換えない 人間が資料全体の論理を深く理解して精査 • 各論点の役割と変更による影響を確認 • 一件ずつ採否を判断し、採用分だけ修正 • 修正後も論理や重要な条件の欠落を確認 全体の論理を深く理解してから、枝刈りする 111
113. AIにこまめに確定原稿を保存させる レビューの区切りご • 承認済みの原稿を確実に保存 • 保存内容を照合してから次へ進む とにAIに保存させる 保存先の一例： GitHub • 変更履歴を残して復元可能にする • ChatGPTから非公開リポジトリへ 直接コミット可能 確定原稿を保護する • AIによる勝手な書き換えを禁止 • 原稿消失事故への対策（第13章） 保存したつもりでは、原稿は守れない 112
114. AIで考えを整理し、読者に伝わる資料を作る AIが支援すること 人間が責任を持つこと • 自分の考えを整理する • 膨大な技術情報を活用 する • 読者に伝わる文章へ仕 上げる • 誰に何を伝えたいのか を決める • 実際にその目的を 果たしているか確認す る 単なる執筆作業の省力化ではない 113
115. 第10章 モデルと推論設定の使い分け 114
116. モデルは判断の質と費用・利用枠で使い分ける 高性能モデル 安価なモデル • 高い判断能力が必要な作 業に使いたい • 料金や利用枠の制約があ る • 長時間の作業を任せやす い • 判断ミスで大きな手戻り を 招くこともある どの作業に高い判断能力が必要かを見極める 115
117. モデルによってAPI単価は100倍違う 標準API料金・100万トークンあたり（米ドル） モデル 入力 出力 GPT-6 Astra $10 $50 GPT-6.1 Sol $2 $10 GPT-6.1 Terra $1 $5 GPT-6 Luna $0.10 $0.50 Claude Fable 5.1 $10 $50 Claude Opus 5.5 $4 $20 Claude Sonnet 5.5 $2 $10 Claude Haiku 4.5 $1 $5 Claude Haiku 5.5 $0.10 $0.50 標準API料金です。定額契約の利用枠とは異なります。Haiku 5.5は入力10万トークン以下の場合です。 AstraとLunaではAPI単価が100倍違う 116
118. 定額契約の利用枠はモデルによって大きく異なる Luna Astra • 一晩動かしても利用枠が ほとんど減らない • 普通に使っているだけで 、 1日で1週間分の利用枠を 消費する 著者がCodexを使った経験に基づく比較。公式な利用枠の比率ではない。 117
119. 安価なモデルでも、手戻りで高くつくことがある 安価なモデルで利用枠を節約 • 長時間の作業を任せやすい しかし、判断ミスが起きると • 一度のミスで100倍以上の手戻りも 現実的なモデルの使い分け • 必要な判断の質を考える • 費用・利用枠の制約も考える 節約しても、手戻りが増えたら意味がない 118
120. モデルと推論レベルは別々に調整できる モデルそのものを変える • 学習方法や計算資源が異 なる モデルを選ぶ 同じモデルの推論レベルを 変える • 回答前にどれだけ 検討するかを調整する 119
121. モデル間の価格差ほど、能力に差があるとは限らない モデルごとに異 なる学習条件 • 学習に使った計算量や学習方法 • 場合によっては学習データも異なる 回答生成に必要 な計算資源 • モデルによって必要な計算資源が異なる • クラウド上での運用費用にも差が出る 判断能力の違い • 上位モデルほど見当違いが少ないと期待 • 高性能モデルでも大きく外すことがある 高性能モデルでも、かなり見当違いな判断はする 120
122. 安価なモデルでも、高い開発能力を持つ ここではCodexで利用するモデルを例に説明します。 Luna：著者の使用経験 GPT-6.1 Sol：OpenAIの公 開評価 • 通常の実装・修正には 十分な能力 • 一部の評価では約1年前 の 上位モデルに匹敵 • DeepSWE v1.1でAstraと 同等の性能 • 約5分の1のコストで達 成 安価なモデルでも複雑な作業はできる 121
123. 安価なモデルでも、高い開発能力を持つ ここではClaudeのモデルを例に、Anthropicの公開評価を紹介します。 Opus 5.5 • 多くの作業でFable 5.1と同等水準 • API単価はFableの40％ Sonnet 5.5 • Terminal-Bench 4.0で70.6％ • Opus 5.5の66.4％を上回る Haiku 5.5 • 低価格モデル • FrontierCode 1.1で46.4％ 一部の評価では、安価なモデルが上位モデルを上回る 122
124. 上位モデルが有利な作業もある 公開評価によって 優位なモデルは変わる 作業に応じたモデル選択 • 安価なモデルが上回る評価もあ る • 別の評価では上位モデルが優位 • 複雑で自由度の高い長時間作業 では、AnthropicはOpusを高く評 価 • 正しい判断のために上位モデル を選びたい場面もある • 判断の質を調整する方法は、モ デルの変更だけではない ClaudeについてはAnthropicの公開評価に基づく説明であり、著者自身によるClaude Codeの比較結果では ありません。 判断の質を調整する手段は、モデル変更だけではない 123
125. LLMは「独り言」を生成しながら考える LLMは文章を生成し • 頭のいい人なら次に何と言うかを予測する ないと考えを進めら • 考えるときも途中の考えを文章にする れない そこで、考えをまと • その続きを予測して考えを進める • 結論に至るまで繰り返す める 文章を生成し続ける • 途中の文章は通常チャット画面に表示されない この方法をCoT（思考の連鎖）と呼びます。 ブツブツ言わないと考えられない 124
126. 推論レベルで回答前の検討量を調整する 推論レベルとは 推論レベルを高くすると • 回答前にどれだけ長く 検討するかを調整 • 内部で生成する独り言の 長さに影響する • 複数の可能性を比較しや すくなる • 矛盾を調べてから回答し やすくなる • 数行の回答でも 長文で検討することがあ る 回答が短くても、考えが短いとは限らない 125
127. 推論レベルを上げると、時間と利用枠の消費も増える 推論レベルを上げた 場合 • 内部で生成する文章も使用量に含まれる • 回答までの時間や利用枠の消費が増えやすい • 生成する文章量は厳密には決まらない 推論レベルの設定を 比較するとき • モデルそのものの変更とは別の調整 • CodexとClaude Codeでは、同じ設定値でも検討量が同 じとは限らない 画面に表示されない文章も、使用量に含まれる 126
128. 何が難しいかで、モデルと推論レベルを使い分ける 高性能モデルを選ぶ場面 推論レベルを高くする場面 • 問題への着眼点を見つけるのが 難しい • 何を検討すべきかを 発見する能力が重要 • 高度な抽象設計や複雑な不具合 の原因発見 • 順序立てて考えるのが難しい • 途中経過を書き出せば解けそう な問題 • 安価なモデルでも 対応できる場合がある 「この用語をどう説明するか」を長々と考えても、「そもそも説明する必要があるか」に気づかなければ、 余計な説明を増やしてしまいます。 推論の途中で重要な問いを発見することもあるため、絶対的な区別ではありません。 長く考えるだけでは、重要な問いに気づけるとは限らない 127
129. 難しい判断は高性能モデル、実行は安価なモデルに任せる 高性能モデルで問題を発見 • Sol・高い推論レベル • 設計上の問題や改善候補を洗い出す • 必要ならAstraも使う 安価なモデルで修正を実行 • 改善内容が具体的になったら切り替える • Luna・中程度の推論レベル • 長時間の実行作業を任せる 難しい判断が再び必要になったら • そのときだけ上位モデルに戻す • 同じ作業の中でモデルを切り替える モデルは同じ作業の途中でも切り替えられる 128
130. 単純で時間のかかる作業は、推論レベル「中」で進める 推論レベルを高く設定する と 推論レベルを「中」に抑え る • 単純な作業でも長く考え てしまう • 実際の作業が ほとんど進まないことが ある • 利用枠の消費を抑える • 実際の作業の進捗を確保 する 長く考えるだけでは、作業は進まない 129
131. 長時間動ける能力と、使い続けられる費用は別 高性能モデルの長時 • 何時間もの自律的な作業に強いと言われる 間作業能力 実際に使い続けられ • 高価なモデルを長時間動かすには費用がかかる • 能力があることと、利用できることは別 るか 高価なモデルを何時間も動かし続けるのは、 お金持ちに任せておきましょう。 130
132. TDDの各工程でモデルと推論レベルを使い分ける 工程・作業 モデル 推論レベル Red（明確な仕様をテストにする） GPT-6 Luna 中程度 Red（通常） GPT-6.1 Terra 高い Red（判断が難しい場合） GPT-6.1 Sol 高い〜最大 Green GPT-6 Luna 中程度 Refactor（軽微） GPT-6 Luna 中程度 Refactor（通常） GPT-6.1 Terra 中程度 Refactor（重要・複雑） GPT-6.1 Sol 高い〜最大 広範囲のリファクタリング GPT-6.1 Sol ウルトラ 広範囲のリファクタリングはTDDサイクル外の作業例です。クラスや機能ごとに分担できます。 設定は一例であり、最適な組み合わせを定量的に確認したものではありません。 131
133. Redは設計判断、Greenは具体化された実装 Red：外部仕様やAPIを設 計する Green：実装すべき内容が 具体化している • テストを通じて 利用しやすい設計を考え る • 高度な設計判断が必要 • Sol・推論レベル「高」 • テストによって必要な振 る舞いが明確 • テストを素早く通す実装 を進める • Luna・推論レベル「中」 必要な判断の難しさに合わせて、モデルを変える 132
134. Refactorは内部設計の難しさでモデルを選ぶ 軽微なRefactor • 名前の変更・単純な重複除去 • Luna・推論レベル「中」 通常のRefactor • 責務の分離・抽象化 • Sol・推論レベル「中」 重要・複雑な Refactor • 高度な内部設計の判断が必要 • Sol・推論レベル「高」 • 問題を洗い出した後、 具体的な修正はLunaに任せる場合もある 変更は小さく区切り、動作を壊していないことを自動テストで確認します。 133
135. Codexの利用枠が不足しても、ChatGPTで作業を続けられる CodexとChatGPTは利用枠が別 • Codexの利用枠が不足しても、 ChatGPTで開発作業の 一部を継続できる 著者の利用経験（2025年頃） • 会社の月額20ドル契約で両方を利 用 • 製品規模のコードを高い推論レベ ルで検討 • ChatGPTは実質無制限と 思えるほど使えた • 追加契約は不要だった Claudeの定額プランではClaude Codeとチャットで利用枠を共有するため、切り替えても利用枠不足を回避 できません。 「実質的に無制限」は2025年頃の著者の利用経験であり、公式に無制限という意味ではありません。 Codexが使えなくても、開発作業を続ける方法はある 134
136. ChatGPTのチャットでは、テキスト中心の開発作業を行う ソースコードを渡す • 指定範囲をスクリプトで結合 • クリップボード経由でチャットへ渡す ChatGPTに作業を任せ る • 課題・リファクタリング候補の洗い出し • システム全体のドキュメント作成 • Skipにしたテストの一括作成 生成結果を反映する • エディタへ貼り付け • patchコマンドで反映 通常のChatGPTでは、コマンド実行や多数のファイル編集が煩雑なため、テキストのやり取りで済む作業 を選びます。 Skipテストの一括作成は、個々のRed・Greenを後から進められるため、通常のチャットに向いています。 135
137. GitHub連携なら、ローカルを経由せず直接コミットできる GitHub連携でできること 向いている作業 • ChatGPTからファイルを 直接変更・コミット • ローカル環境を経由しな い • 文書や設定ファイルの編 集 • ローカルでのビルド・テ ストが不要 • まとまった変更の一括反 映 ファイルの読み書きには時間がかかるため、細かな編集の繰り返しには不向きです。 ChatGPTからGitHubへ直接コミット 136
138. コードを編集しない仕事の相談にも、ChatGPTを使う ChatGPTで仕事の相 談 • コード編集やファイルの受け渡しは不要 • 入出力の文章量が比較的少ない 推論レベルを高くす • 深い検討が必要な相談に使う • 回答まで時間がかかる間は別の作業を進める る 137
139. 第11章 仕様変更から実装までの自動化 138
140. 仕様変更から実装までの自動化を試す これまでに紹介した手法 • レイヤー設計 • Skipテスト • 履歴レビュー • モデルの使い分け 新たに組み合わせる仕組み • AI-DLCによる仕様資料の 管理 仕様変更の取り込みから実装まで、ほぼAIに任せる方法を試す 139
141. 自動化には、レビューでほとんど指摘が出ない状態が必要 自動化の適用条件 条件を満たさない場合 • 開発対象が十分に整理されている • レイヤー設計で個々の変更を小さく自明にする • 実装の大半をAIに任せられる • 人間のレビューは流し読みが中心 • 指摘事項がほとんど発生しない • 数コミットに一件程度でも指摘が発生 • 問題が溜まりやすい • まとめて作業させる利点が薄れる 140
142. 仕様資料を定期的に確認し、変更台帳を更新する 仕様に関する資料を管理 • 正式な仕様書でなくてもよい • ラフ案・画面ラフ・議事録など • GitHub・OneDrive同期フォルダ・SharePoint 更新されたファイルを定期確認 • タイマーで一日一回など • 更新されたファイルを調べる 仕様変更の台帳を更新 • AIに仕様の変更内容を整理させる • 整理した変更内容を台帳へ反映 141
143. 仕様変更一覧をレビューしてからSkipテストに反映する 開発を開始する • 台帳更新時・任意のタイミング • 複数日分をまとめてもよい • Gitの作業ツリーを用意 • 台帳と元資料を確認 AIが仕様変更一覧を作成 • ある程度の推論能力を持つモデルを使用 人間が変更一覧をレビ ュー Skipテストへ反映 • 今回取り込む仕様変更を確認 • 必要な修正を行う • レビュー後の仕様をテストに反映 • 変更をコミット 仕様変更一覧は、人間がレビューしてからテストに反映 142
144. 安価なモデルでSkipテストを一件ずつ実装する Red モデル設定 • 安価なモデル を 使用 • 高速に作業で きる推論設定 Green Refactor（必要な 場合） 次のSkipテストへ Skipテストを一件ずつ有効化 意図した失敗を確認 テストを通す 結果をコミット 内部設計を改善 別のコミットに記録 同じ手順を繰り返す 143
145. AIの実装完了後、コミット履歴を一件ずつレビューする AIが一連の実装を完了 • Red・Green・Refactorの反復を終了 人間がコミット履歴をレビュー • コミットを一件ずつ確認 • 適用条件を満たせば、 一日分でも指摘はほとんどないはず 必要な修正を行って完了 • 指摘があれば修正 • 変更をコミット 144
146. 開発の大部分をAIに任せ、人間はレビューに集中する AIが進める一連の作業 • 仕様資料の更新確認 • 変更内容の整理 • Skipテストへの反映 • TDDによる実装 人間が主に行う レビュー • 今回取り込む仕様変更の 確認 • 実装結果のコミット履歴 を確認 145
147. 文書に表れない判断材料が、今後の課題 現在のプロジェ クト • 仕様のブレは特に見られない • まだ開発初期で、確定仕様が少ない • 問題が表面化していない可能性 文書に表れない 判断材料 • 過去の会議で顧客が重視した点 • ドメイン専門家が重視する事項 • 重要になる場面はまだ十分に経験していない 業務上の問題を 見逃す可能性 • 文書にない判断材料をAIが知らない • 業務上好ましくない変更を見逃すおそれ 146
148. 業務上の判断材料への対処は、今後の開発で検証する 人間がドメインに関わる変更を重 点的にレビュー 議事録を詳しく記録しAIに渡す • 業務上好ましくない変更を見逃 さないため • レビュー負担が増える可能性 • 文書に不足する判断材料を補う • 人間のレビューをそれほど増や さずに済む可能性 今後の開発で確認する •どの程度の対応が必要になるかは未確定 147
149. 第12章 AIへの指示のちょっとしたコツ 148
150. 普通の言葉でAIに指示できる理由 対話用LLM 定型的なプロンプト 技法 • 自然な言葉の指示に 応答するよう訓練 • 文脈や言い回しから 明示されない意図も 読み取る • 単純な命令の解釈を 前提とした技法もあ る • 自然な会話より有効 とは限らない 149
151. 専門的なプロンプト技法を習得する必要はない OpenAI・Anthropicの推 奨 • 簡潔で直接的な指示 • 人間の同僚に頼むような説明 ソフトウェア開発の比 較研究 • 改善効果が小さいとの報告 • 逆効果になる場合も報告 普通の言葉で仕事を頼む • 目的と必要な情報を伝える • 相手の反応を見ながら進める • 情報が不足していたら説明を補う • 特殊な言い回しと必要な情報は別問題 150
152. 短い指示でAIに再検討させる 設計上の違和感を指摘 問題点を 洗い出させる 繰り返す間違いを 規則化 • 「ここにこれがあるのは おかしくないですか？」 • 責務や依存関係を見直してくれることがある • 人間が改善方法まで指定する必要はない • 「問題点を指摘して」 • 問題や追加すべきテスト観点を洗い出す • 修正より先に問題を発見させる • 「今の指摘をルールにしておいて」 • 指示ファイルに記録させる • 追加されたルールは人間が確認 その場で必要なことを、普通の言葉で伝える 151
153. 質問でAIを誘導しない 質問者が自分の見解や確信を先に示すと、迎合が増える傾向がある 判断を誘導する聞き方 判断を求める聞き方 • 「このロジックは ViewModelに置くのが正し いですよね？」 • こちらの判断を前提に回答 する可能性 • 「このロジックを ViewModelに 置くべきか迷っています。 ドメイン側とどちらが 適切でしょうか？」 • 自分がどちらの立場なのか 分かりにくい 目的は反論ではなく、こちらの意見に引きずられない判断を得ること 152
154. パーソナライズと指示ファイルを使い分ける パーソナライズ • 回答の文体 • 毎回求める判断の仕方 • 個人の回答の好み 指示ファイル • TDDの工程 • 実装上の制約 • プロジェクトの開発規則 どちらもAIが必ず従う保証はない 153
155. 批判的な回答を求める設定の効果と副作用 継続して設定していること • 批判的に答える • 自分自身の回答の前提・根拠・論理をまず検討する 感じている効果 副作用 • 過剰な賞賛や迎合が多少減 る • 些細な表現への揚げ足取り • 反論するための反論 本来の批判的思考は、相手の欠点探しではなく、自分の考えも含めた検証です。そう指示しても、AIが十分 に実践するとは限りません。 154
156. 長期作業の継続方法はCodexとChatGPTで異なる 開発では、過去の情報を簡単に捨てられない Codex ChatGPTの通常チャット（2026 年10月現在） • コンテキストが膨らむと自動 圧縮 • 多くの場合は同じチャットで 作業を継続 • 圧縮で情報が正確に 引き継がれない可能性 • 上限到達でチャットが強制終 了 • 同じチャットでは作業を継続 できない • 新しいチャットへの引き継ぎ が必要 長期作業では以前の指示や前提を忘れやすくなることもあるため、必要に応じて改めて確認する。 155
157. 長期作業の情報は、区切りごとに保存する 引き継ぎに 必要な情報 保存するタイミング ファイル管理上の 注意 • 作業の進捗・決定事項 • 未解決の問題・次に行う作業 • ファイルに保存して後から参照する • Codex：自動圧縮の直前には 保存できない場合がある • ChatGPT：チャットの終了に備えて保存する • 重要な作業の区切りで保存する • 意図しない場所へのファイル作成を防ぐ • 保存先を管理できる環境では場所を指定する • 既存ファイルの更新か新規作成かを指定する 156
158. 引き継ぎファイルの保存先はCodexとChatGPTで異なる Codex：Git管理外のメモ ChatGPT： ChatGPT側のファイル • 一時的な引き継ぎメモを Git管理外に置く • 専用の保存先を.gitignore に登録 • 次の作業環境からも参照 できる 場所に保存 • 引き継ぎ情報をChatGPT 側に保存 • 新しいチャットで ファイルを参照して再開 • 具体的な保存場所や受け 渡し方法は 把握していない 157
159. 引き継ぎはファイル、継続ルールは指示ファイルで管理する ChatGPTで過去の情報を引き継ぐ • 過去のチャットから関連情報を検索して利用する（RAG） • この参照方法では要約しか得られない • 細かな条件や議論が失われることがある • 必要な情報はファイルに省略せず保存する • ChatGPT側に保存し、開発リポジトリには増やさない 保存する情報の役割分担 • 指示ファイル：TDDの進め方・プロジェクトの基本規則 • 引き継ぎファイル：進捗・決定事項・未解決の問題など 158
160. 第13章 AIの挙動と限界 159
161. AIは理論を正しく説明しても、そのとおりに行動するとは限らない 同じLLMが 学習しているもの • TDDや設計原則についての専門的な説明 • 公開コードによく見られる実装パターン 文脈によって 出力の確率が変わる • 理論の議論：専門的な説明が続く確率が高い • 実装の依頼：一般的な実装パターンが 続く確率が高い • どちらの文脈でも両方の可能性がある 結果：理論と行動が 食い違う • TDDの原則を正しく説明できる • Greenで不要な機能まで実装することがある • 説明した理論を一貫した信念として 守るわけではない 160
162. AIが規則を守ったかは、成果物で確認する AIは規則を正しく説明できても、実際に守れるとは限らない。 成果物を検証する • 自動テスト：実装が期待動作を満たすか • 静的解析：機械的に検出できる問題がない か • 人間のレビュー：仕様・設計・開発規則に 従っているか 自動テストもAIが作成するため、テスト自体が仕様を正しく表しているか確認する必要がある。 161
163. AIの暴走――指示していない作業を進め、確認手順を飛ばす 指示範囲外の作業 確認手順の省略 • 頼んだ箇所以外の周 辺コードまで変更 • 頼んでいない リファクタリングを 始める • 決めていた確認手順 を飛ばして 作業を進める 変更結果が一見よさそうでも、依頼した範囲を越えていること自体が問題 162
164. AIの暴走が長時間続くと、利用枠を使い果たすこともある AIが次々と作業を始める • 手動で停止しなければ続く場合がある 暴走が長時間続く • 何時間も、場合によっては何十時間も • その間も利用枠を消費する 最悪の場合、利用枠を使い果たす • 回復まで1週間近く AIによる作業を進められないこともある 163
165. この勉強会資料の作成中、 AIが未保存の原稿の約3分の1を上書きした この勉強会資料をAIと作成 • 原稿を一節ずつレビューして承認 • GitHubへ保存する方針だったが保存できていなかった • 未保存の原稿はAIが会話の中で保持していた AIが未保存の原稿を勝手に上書き • 確認を待たずに統合・書き換えを進めた • 原稿全体の約3分の1が失われた 元の原稿を復元できなかった • AIは以前の原稿を思い出せないと説明 • GitHubにも復元できる保存版がなかった • レビュー済みの成果物そのものを失った 後から書き直せても、元の原稿を復元したことにはならない 164
166. 規則を明示しても、AIの暴走は起こり得る 規則を指示した場合 作業中のコンテキストによっては • 規則に従う出力の確率が高いと判断さ れる • 通常は規則に沿って作業する • 規則に反する出力の方が確率が高い場 合もある • 規則を守ろうという一貫した意志はな い 結果 • 明確に指示しても遵守は保証されない • 規則を正しく説明できても行動では外れることがある 暴走は、指示が曖昧だったからとは限らない 165
167. AIの暴走に備え、作業を区切って保存・照合する 作業範囲を限定する • レビューや承認が必要なところで区切る レビュー済みの原稿を保存する • 一節のレビュー直後にGitHubへコミット • Gitで変更履歴を残す 保存結果を照合する • GitHubから全文を再取得 • 承認した文章と一致することを確認 • 確認できたら次の節へ進む 保存されていない原稿は、Gitの履歴からも復元できない 166
168. AIの自律作業では、どこで止めるかも決める AIの作業能力が高まる • 指示範囲外の作業による影響も大きくなる 暴走による損失 • Gitで変更を元に戻すことはできる • 消費した利用枠は戻らない 長時間の自律作業 • 進行状況を確認する • 異常があれば手動で停止する 何を任せるかだけでなく、どこで止めるかも決める 167
169. AIは自分がなぜそんなことをしたのか覚えていない AIは当時の判断を覚えていない • LLM自体には思考過程を記憶する仕組みがない 後から理由を尋ねられると • 現在のコンテキストから原因を推測 • 筋の通った説明を生成する ただし、記録が残っている場合もある • 作業中に生成した独り言の記録 • 残っていれば後から参照できる場合がある 筋の通った説明でも、実際の原因とは限らない 168
170. 理由が分からなくても、AIは自信ありげに答える AIは当時の判断を覚えていなくても、現在の情報から理由を推測して答えます。 その情報すら残っていない場合 • なぜその行動をしたのか推測できない それでもAIは理由を説明する • 文脈から確率が高い文章を生成 • 自信ありげに答えることもある ハルシネーション • 実際の原因とは無関係な説明を • 事実であるかのように述べる 根拠がなくても、もっともらしい理由は作れてしまう 169
171. AIの独り言の記録が残っていても、完全な記録とは限らない 独り言の記録が残る場合 記録には限界がある • 作業中に生成した推論 の文章 • ユーザーの画面には表 示されない • AIが後から参照できる 場合もある • 当時の判断過程が すべて残るとは限らな い • コンテキストの圧縮な どで 失われる場合もある 記録が残っていても、当時の判断を完全に再現できるとは限らない 170
172. AIの説明は、原因の証拠にはならない 原因調査に役立つ記録 • 実行したコマンド • 変更履歴 • 途中で作成した計画 AIに記録を分析させる • 記録から確認できる事実を調べる • その事実から原因を推測する 事実と推測を区別する • 実際の原因を特定できるとは限らない • 手掛かりがなければ理由を作り出すこともある AIに理由を尋ねても、本人から事情を聞き出しているわけではない 171
173. AIの謝罪は見事だが、反省した結果ではない AIの謝罪は見事 しかし、反省した結果で はない • 間違いを指摘されると すぐに非を認める • 丁寧に謝罪し、言い訳も しない • 人間が手本にしたいほど • 自分の行為を反省して謝 罪するわけではない • この違いはLLMの 学習の仕組みから説明で きる 謝罪が上手なことと、反省したことは別 172
174. AIは謝罪の仕方を文章から学ぶ 謝罪の言葉は文章に残る • 間違いを認める • 丁寧に謝罪する • 再発防止を約束する 反省の過程は文章だけでは分 • 内面で何を学んだのか からない • どう考えを改めたのか LLMが学習できること • 謝罪の場面に適した言葉を学習できる • 反省の過程まで学習したとは限らない 謝罪の仕方を学ぶことと、反省を学ぶことは別 173
175. 謝罪しても、同じ間違いを繰り返すことがある 間違いを指摘される • 文脈に応じて謝罪や反省の言葉を生成 • 反省の過程を経なくても生成できる 指摘後に改善される場合もある • 指摘された内容はコンテキストに残る • 次の作業で参照できる しかし、同じ間違いを繰り返すこともある • 謝罪してもモデルの学習内容は変わらない • 再発防止を約束しても保証はない 「今後は勝手に作業を進めません」と約束した後で、再び指示範囲外の作業を始める。 謝罪によって、モデルが学習し直すわけではない 174
176. 謝罪や反省の言葉は、改善の証拠にはならない AIが謝罪とともに原因 • 失敗の原因が正確とは限らない • 原因を特定する情報がない場合もある を説明する 反省や再発防止策を述 • もっともらしい言葉を生成できる • 実際に改善された証拠にはならない べる 謝罪したことと、改善できたことは別 175
177. 謝罪と再発防止は別の仕事 問題が起きたら • 何が起きたのか確認する • 再発防止策を考える • 改善策の検討はAIにも任せられる 再発防止策を仕組みに反映 • 指示ファイルに規則を追加する • 作業手順を変更する 反映結果を確認する • 規則が実際に保存されたか • 作業方法が実際に変更されたか 謝罪の言葉ではなく、実際に何を変えたか 176
178. 付録：TDD向け指示ファイルの実例 実際の開発で使用している 指示ファイル • Red・Green・Refactorの 工程別指示 • Skipによる未着手仕様の管理 • Greenでの過剰実装防止 • 既存仕様の変更手順 開発しながら改善 • 発生した問題への対策を 規則として追加 • 改善を繰り返してきた DocumentAsDataのTDD作業指示（2026年10月12日確認版） 完成された模範解答ではなく、実践を通じて育てた一例 177
179. 付録：TDD作業指示 全文（1/5） # TDD作業指示 この文書は、振る舞い追加、仕様変更、不具合修正、リファクタリングに適用する。 C#以外の開発にも共有できる内容として扱う。 ## 基本 * 振る舞いの追加や変更、不具合修正では、原則として実装前にテストを追加または修正する。 * Red、Green、Refactorを区別し、「Redまで」「Greenまで」「Refactorまで」と指定された場合はその段階で停止する。 * 期待仕様が明確でテストを実行できる場合は、既存テスト・API・データを必要な範囲だけ確認してテストを書き、実行結果か ら失敗理由を確認する。Redになる見込みを予測・説明するためだけに実装を調査したり、推論へトークンを費やしたりしない。 * Red確認では、失敗したコマンド、失敗理由、意図した失敗かどうかの判断根拠をユーザーへ報告する。 * Red確認が意図した失敗でない場合は、Green実装へ進まず、テスト、仕様、テストデータ、既存設計の確認へ戻る。 * 公開APIを追加または変更する場合は、Red段階のテストをAPI案として扱う。 * APIレビューのためにコンパイルを通す必要がある場合は、`NotImplementedException` などで失敗する最小限の公開APIス タブを追加してよい。 ## 各段階で考えること * RGRは作業順序だけでなく、考える対象を分ける手順として扱う。ある段階で考えないことは、検討そのものを不要にするので はなく、担当する段階で取り組む。 * Redでは、次に必要な振る舞い、APIの外部設計、使い勝手を考える。実装方法、実装の容易さ、テスト全体の網羅性の検討を 持ち込まない。 * Greenでは、テストを通す必要最小限の実装に集中する。きれいな内部設計やアルゴリズムの正当性をじっくり検討する作業は Refactorへ分け、Greenの完了条件に混ぜない。テストを実行して結果を確認することと、正当性を精査することを区別する。 178
180. 付録：TDD作業指示 全文（2/5） * Refactorでは、内部設計と読みやすさを改善しながら、実装の意味、アルゴリズムの正当性、ロジックの不足をじっくり検討 する。Greenでテストが通ったことを理由に、この検討を省略しない。振る舞いの追加・変更はここでは実装せず、別のRed→Gre enへ回す。 * GreenやRefactorでは、ミスがないことを注意力だけで保証しようとせず、小さな変更ごとにテストを実行する。Refactorで の検討も自動テストの代わりにはしない。 ## Skip保留仕様 * API仕様をまとめて検討するためにGreen対象より多いテストを先に書く場合は、保留する仕様テストに理由付きの `Skip` を 付ける。 * ユーザーと後で確認することに合意したテスト観点は、既存テストとの重複を確認したうえで、口頭の予定だけにせず `Skip` 付きテストとして残す。既存実装で成功する見込みでも、未レビューなら同様に保留する。未合意の将来仕様を先回りして追加 する根拠にはしない。 * `Skip` 理由は、後から読んだ人が、なぜ今は実行対象でないのか、いつ解除するのかを判断できる内容にする。 * `Skip` 理由に単に「未実装」とだけ書かない。 * `Skip` 属性の行から理由が読み取りにくくなる場合は、共通定数化せず文字列を直接書く。 * `Skip` 済み仕様テストは、Green対象にするまで原則として変更しない。 * `Skip` で保留した仕様をGreen対象へ移す場合は、どのテストの `Skip` を外すかをユーザーに確認してから進める。 ## Green対象と過剰実装 * Green対象は、一つのテスト、またはユーザーと明示的に合意した小さな仕様のまとまりに限定する。 * Greenでは、現在有効な対象テストを通すための必要最小限の実装を最初から書く。事後チェックで削ることを前提に実装を増 やさない。 179
181. 付録：TDD作業指示 全文（3/5） * Greenの動作確認には自動テストを積極的に使う。成功するかを長く推論するより、対象テストを実行し、結果に基づいて修正 する。関連テストや全体テストで既存動作への影響も確認し、実装を最小限にする判断と動作確認を混同しない。 * Green・Refactorの最終確認とコミット前には、原則として全テストを実行する。対象テストや関連テストだけで済ませるの は、変更が残りのテストへ影響しないことを依存関係や実行経路から論理的に説明できる場合に限り、その理由を報告する。所要 時間だけを省略理由にしない。影響しないか長く推論するより、全テストを実行するほうが低コストなら実行する。 * 必要最小限とは、対象テストが要求する振る舞いを実現することであり、Green対象外の仕様を先取りして固定することではな い。 * Green確認後の見直しは、過剰実装の見落としを防ぐ補助とする。そのGreenで追加したコードに、対象テストが要求していな いロジック（分岐、代入、初期化、後始末など）が含まれ、取り除いても対象テストと既存テストが通る場合は、削除してからG reen完了とする。点検対象を既存コード全体へ広げず、内部設計やアルゴリズムの正当性の精査へ広げない。 * AIが先の仕様や必要になりそうな実装を推測した場合も、Green対象外なら実装せず、推測として報告する。 * Green中に対象テストとは別の仕様が必要だと分かった場合は、実装せず、理由付きの `Skip` テストまたは確認事項として 残す。 * 対象テストが要求していない実装を先に入れ、その後でRedテストを追加して正当化しない。 * Green対象外の `Skip` 済み仕様テストやテストデータ全体の整理が必要に見えた場合は、編集前に理由を報告して止まる。 * Green対象を理解するために必要なテストデータ、期待値、補助APIだけを同じ作業単位に含める。 * 予定テストを失敗させ続けるために、公開APIを不自然または不完全な形へ歪めない。 * 同じAPIの正常系と異常系が同じ自然な実装で満たされる場合は、予定テストが通ること自体を避けるための迂回実装をしない 。 * 対象テストが要求していない分岐、例外型、エラーメッセージ、戻り値仕様を、自分で判断して追加しない。 * 自分で `throw` を書く例外は仕様として扱い、原則として先にテストで固定する。 * 低水準API、標準ライブラリなどの呼び出し結果として自然に発生する例外まで、すべて明示仕様にする必要はない。 ## 既存機能を変更する手順 180
182. 付録：TDD作業指示 全文（4/5） * 仕様変更が合意された場合は、まず変更対象の既存テストを変更後の仕様に合わせて修正し、意図した理由でRedになることを 確認する。追加する振る舞いに対応するテストがない場合は、新しいテストを追加する。 * 変更した対象テストを通すための必要最小限の実装を行う。 * 変更に伴って通らなくなった既存テストを精査し、合意した仕様変更に合わせて修正すべきテストと、維持すべき振る舞いを 確認するテストを区別する。仕様上の判断が必要ならユーザーへ確認し、実装に合わせて期待値を変更しない。 * 修正すべきテストを変更したうえで、維持すべき振る舞いも含めてすべてのテストが通るように実装する。対象テストだけの 成功と、全体のGreenを区別する。 * 全体がGreenになってからRefactorへ進む。仕様変更と内部設計の整理を混ぜない。 ## Refactorとテスト保守 * Green確認後に、外部から観測できる振る舞いを変えずにリファクタリングする。 * Refactorでの検討の結果、整理が不要ならコード変更は行わない。ただし、テスト成功を理由に検討自体を省略しない。「Gr eenまで」の指定で停止した場合は、Refactorでの検討は未実施として引き継ぎ、完了扱いにしない。 * リファクタリングでクラスやメソッドを抽出・新設する場合も、既存の振る舞いを移すことに限定する。新しいクラスの一般 的な役割を理由に、対応する入力、例外処理、保存方法などの新機能を追加しない。既存テストがすべて通ることだけで、新機能 の混入がないとは判断しない。 * リファクタリング中に不足機能へ気づくことは、TDDで次の仕様を見つける重要な機会として扱う。既存テストとの重複を確認 し、不足している振る舞いと期待結果を、理由付きの `Skip` テストとして提案する。リファクタリングへ実装を混ぜず、ユー ザーの仕様レビュー後に別のRed→Greenとして進める。 * 既存テストを、実装に都合よく弱めたり削除したりしない。 * テストが誤っている可能性がある場合は、勝手に変更せず報告する。 * 実装済みの仮挙動を仕様として固定するテストを、理由なく追加しない。 * テスト数を増やすこと自体を目的にしない。 * 一つのテストに一つのAssertだけを機械的に強制しない。 181
183. 付録：TDD作業指示 全文（5/5） * 内部変数やprivateメソッドを直接テストするためだけに設計を歪めない。 * 実装予定のテストが通らない状態を維持することは仕様ではない。 * 将来のテストを通さないために、現在の実装を不自然に読みにくくしない。 182