生成AIのコーディング能力は急速に向上しています。
要件を伝えれば、AIがコードベースを調査し、設計し、実装し、テストを書き、場合によってはリファクタリングまで進めてくれる。
AIエージェントによるソフトウェア開発が現実的になったことで、
「より高性能な大型モデルに、できる限り多くの開発を任せればよいのではないか」
という考え方も自然に出てきます。
一方で、私は別の問題が大きくなっていると感じています。
それが、
AIの生成能力が、人間の認知・検証能力を上回り始めている
という問題です。
本記事では、
- Large Modelを中心としたAgentic Development
- Small Model + Human-in-the-loop
- Spec-Driven Development
- DDDとSource of Truth
- AI時代のTraceability
- 人間の認知能力とレビュー
という観点から、AI時代のソフトウェア開発のあり方について考えてみます。
AIの生成能力より、人間の検証能力がボトルネックになる
例えばAIエージェントに、
「この機能を実装してください」
と依頼した結果、次のような変更が数分で生成されたとします。
- 30ファイル変更
- 2,000行追加
- DB Migration追加
- API変更
- Unit Test追加
- リファクタリング
- ドキュメント更新
AIにとっては短時間で処理できる仕事です。
しかし、人間側には別の仕事が残ります。
「この2,000行は本当に正しいのか？」
という確認です。
つまり、生成速度だけを上げても、人間が確認できなければ意味がありません。
従来は、
Software Development Throughput
≒
Human Coding Throughput
でした。しかしAI時代には、
AI Generation Throughput
≫
Human Verification Throughput
という状態が起こり得ます。
その結果、開発のボトルネックは、
「コードを書くこと」から「生成されたものが正しいと確認すること」
へ移動していきます。
Large Modelは「推論できる」ことが強みであり、リスクでもある
大型モデルの大きな特徴は、単純な指示だけでも広いコンテキストを読み取り、自ら推論できることです。
例えば、
発送後キャンセルによる物流コストが問題になっている。
発送開始後は注文キャンセルを禁止したい。
という要求を与えるだけでも、大型モデルであれば、
- 既存コードを探索する
- Order Aggregateを特定する
- 関連するAPIを調べる
- Testを調べる
- 影響範囲を推論する
- 実装方法を決定する
- コードを変更する
- Testを追加する
ということまで、自律的に実行できる可能性があります。
これは非常に強力です。
一方で、大型モデルは能力が高いからこそ、
「ここも変更したほうがよさそう」
「ついでにリファクタリングしよう」
「将来を考えると、この抽象化も必要だろう」
と、人間が明示的に要求していないところまで推論できます。
つまり、大型モデルには、過剰な推論ができるという側面もあります。
Large ModelほどAcceptance Criteriaが重要になる
そのため、大型モデルを使う場合に重要なのは、単なる実装指示ではありません。
私は次の3つが重要だと考えています。
Context
+
Goal
+
Acceptance Criteria
例えば、
Context:
発送後キャンセルにより物流コストが発生している。
Goal:
発送開始後の注文キャンセルを禁止する。
Acceptance Criteria:
- 発送前はキャンセル可能
- 発送後はキャンセル不可
- Payment Aggregateには影響させない
- APIレスポンス形式を変更しない
- 既存Testを壊さない
というように、
「どう実装するか」ではなく、「最終的にどの状態になれば成功なのか」
を明確にします。
AIの自由度を高くすればするほど、人間側には正解の境界を定義する能力が求められます。
Large Model中心では、AIがAIをレビューする構造になる
Large Model中心で人間の介入を減らしていく場合、人間がすべてのコードを直接確認するのは現実的ではありません。
そこで、次のような構造が必要になります。
つまり、
AIが生成し、別のAIが検証する
という構造です。
人間に渡す情報も、コード全文ではなく、
今回の目的
↓
重要な変更点
↓
Acceptance Criteriaの達成状況
↓
AIレビュー結果
↓
Test結果
↓
人間判断が必要な項目
まで圧縮していく必要があります。
人間が2,000行のコードを読むのではなく、
「人間が判断すべき5つのポイント」
を見る。
これがLarge Model中心の開発では重要になります。
Human-in-the-loopをなくすのではなく、配置場所を減らす
Large Model中心の開発では、
Human Review
を完全になくすことは難しいと思います。
ただし、
人間が確認する場所を減らす
ことはできます。
例えば変更をリスク別に分類します。
Low Risk
- 変数名変更
- Test追加
- 軽微なリファクタ
Medium Risk
- CRUD変更
- API内部実装変更
High Risk
- 認証
- 決済
- DB Migration
- Domain Rule変更
- External API Contract変更
そして、
Low Risk
↓
AI Review + Test
↓
自動承認
High Risk
↓
AI Review + Test
↓
Human Review
という設計にする。
これは、
Risk-based Human-in-the-loop
と考えると分かりやすいと思います。
一方でSmall Modelという選択肢もある
ここまでLarge Modelを中心に考えてきましたが、必ずしも大型モデルを使うことだけが正解ではありません。
例えば次のような組織です。
- AI利用コストを抑えたい
- AIは補助ツールとして使いたい
- エンジニア自身がコードを理解したい
- Domain Knowledgeを人間側に残したい
- 人間が設計・判断する文化を維持したい
このような組織では、Small Model中心の開発も十分に成立します。
Small Modelでは人間が認知ループに残りやすい
Small Modelでは、一度に巨大なタスクを任せるよりも、小さな作業単位で使う方が向いています。
確かに、Large Modelに一度に任せる場合よりも人間の操作回数は増えます。
しかし、この「手間」は必ずしもデメリットだけではありません。
人間自身が、
- 今何を変更しているのか
- なぜ変更するのか
- どのDomain Ruleに影響するのか
- 何が変更されたのか
- 次に何をすべきなのか
を追いながら開発できます。
つまり、
人間のMental Modelを維持しながらAIを使える
というメリットがあります。
「人間の操作が多い」は、組織の開発スタイルでもある
Small Modelを使うと、
「人間の操作が増えるから生産性が低い」
と考えることもできます。
しかし、これは必ずしも絶対的な欠点ではありません。
例えば組織として、
Human
↓
AI
↓
Human
↓
AI
という細かいフィードバックループを意図的に採用することもできます。
その場合、人間の関与が多いこと自体が開発プロセス です。
特に、
- エンジニア主体の開発文化
- ドメイン理解を重視する組織
- AI予算に制約がある組織
では、Small Model中心は合理的な選択肢になり得ます。
Small ModelとSpec-Driven Development
Small Model中心で開発する場合、特に相性が良いと考えているのが、**Spec-Driven Development（SDD）**です。
大型モデルの場合、
Prompt
↓
モデル内部で要件理解
↓
設計
↓
タスク分解
↓
実装
↓
Code
という処理をモデル内部で行えます。
一方、Small Modelでは、そこまでの広い推論をモデルに期待しない。
代わりに、
Requirements
↓
Design
↓
Detailed Design
↓
Atomic Tasks
↓
Implementation
↓
Verification
という形で、開発プロセス側に分解します。
ここで重要なのは、
Small Modelでは推論をなくしているわけではない
ということです。
Large Modelでは、
Reasoning
=
Model内部
だったものを、
Small Model + SDDでは、
Reasoning
=
Development Process
へ移動させています。
言い換えると、
推論を外部化・構造化している
ということです。
Large ModelにはGoalを、小型モデルにはProcedureを渡す
Large ModelとSmall Modelでは、Prompt Engineeringの考え方も少し変わってくると思います。
Large Model
Context
+
Goal
+
Acceptance Criteria
が重要です。
Howはある程度モデルに任せる。
Small Model
Context
+
Procedure
+
Constraints
が重要になります。例えば、
目的:
注文キャンセル条件を変更する
対象:
Order Aggregateのみ
変更可能:
- order.ts
- order.spec.ts
変更禁止:
- Payment Aggregate
- DB Schema
- API Interface
手順:
1. 現在の条件を確認
2. キャンセル条件を変更
3. Unit Test追加
4. Diffを提示
完了条件:
既存Test + 追加Testが成功する
というように、
何をするかだけではなく、どう進めるかまで明示する
ことで、小型モデルの弱い部分を開発プロセスで補います。
Small Context / Small Output
Small Modelでさらに重要なのが、Contextを狭くすることです。
毎回Repository全体を読ませるのではなく、
Issue
+
関連Domain Code
+
関連Test
+
必要なADR
だけを渡す。
さらにOutputも、
変更対象:
Order.ts
Order.spec.ts
のように限定する。
つまり、
Small Context
↓
Small Reasoning
↓
Small Output
↓
Verification
という構造にします。
これによって、
- Token Costを抑える
- 意図しない変更を減らす
- 人間がDiffを理解しやすくする
という効果が期待できます。
DDDとAI時代のSource of Truth
ここでDomain-Driven Designの話につながります。
私はDDDにおいて、
Domain RuleはDomain Layerを見れば分かる
という状態が重要だと考えています。
例えば、
class Order {
cancel() {
if (this.status === OrderStatus.SHIPPED) {
throw new OrderCannotBeCancelledError();
}
}
}
というコードが存在すれば、
「発送後はキャンセルできない」
という現在のDomain Ruleはコードから読み取れます。
さらにTestがあれば、
Code
+
Test
が現在の振る舞いについてのSource of Truthになります。
コードから読み取れないものだけを残す
一方でコードを見ても分からない情報があります。
例えば、
なぜ発送後キャンセルを禁止したのか？
という情報です。
これは、
- 法律上の制約
- ビジネス上の理由
- 過去の障害
- 外部システムの制約
- 顧客要求
などかもしれません。
こうした、
WHY
Context
Decision
Constraint
はドキュメントとして残す価値があります。
つまりAI時代には、
コードを文章に転記しただけのドキュメント
の価値は下がる。
一方で、
コードから復元できない人間の意図
の価値は上がる。
と考えています。
DocumentationよりTraceability
さらに重要になるのが、 Traceabilityです。
コードから、
と遡れる状態を作ります。
例えば、
git blame src/domain/order.ts
で変更したCommitを確認し、
Commit Messageに、
[#142] Add order cancellation policy
とIssue番号が入っていれば、
git log --grep="#142"
で関連Commitを検索できます。Pull Requestには、
Fixes #142
と書いておく。Issueには、
## Context
発送後のキャンセル処理による物流コストが増えている。
## Decision
発送開始後はキャンセル不可とする。
## Alternatives
発送後もキャンセル可能にする案は採用しない。
## Reason
物流システムとの整合性を維持するため。
程度を残す。このIssue自体がADRの役割を持ってもよいと思います。ADRは必ずしも、
docs/adr/001.md
のような独立したファイルである必要はありません。
意思決定が記録され、コードまで辿れること
の方が重要です。
AIに「証拠のチェーン」を辿らせる
このTraceabilityは生成AIとの相性も非常に良いです。
AIに、
「このコードが存在する理由を調査してください」
と依頼すれば、
Code
↓
git blame
↓
Commit
↓
Pull Request
↓
Issue
↓
Decision
を辿らせることができます。
つまりAI時代には、
巨大な設計書をAIに全部読ませる
よりも、
必要な情報をAI自身に辿らせる
という設計の方が合理的かもしれません。
私はこれを、
Documentation CompletenessよりTraceability
という考え方で捉えています。
AI時代にドキュメントは不要になるのか？
ドキュメント自体が不要になるとは思っていません。
ただし、ドキュメントの役割は変わります。
従来は、
Document
=
人間が読む説明書
でした。
AI時代では、
Document
=
Human + AIが共有するContext
という側面が強くなります。
ドキュメントを3種類に分けると分かりやすいと思います。
Human-authored
人間しか定義できない情報。
Business Intent
Domain Knowledge
Constraints
Decision
ADR
Acceptance Criteria
Executable
機械が検証できる情報。
Source Code
Test
Schema
OpenAPI
IaC
Generated
必要になったときにAIから生成すればよい情報。
Class説明
API解説
Sequence Diagram
ER Diagram
Onboarding Document
Code Explanation
特に3つ目については、AI時代には人間が常に最新状態を維持する必要性が下がっていくと考えています。
Small Model vs Large Modelは、どちらが正しいのか
ここまでの話を比較すると次のようになります。
| 観点Small ModelLarge Model | ||
|---|---|---|
| AIコスト | 低い | 高い |
| 人間の関与 | 多い | 少ない |
| 認知維持 | しやすい | しにくい |
| 自律性 | 低め | 高い |
| Context | 狭く具体的 | 広くても扱える |
| Prompt | Procedure / Constraints重視 | Goal / Acceptance Criteria重視 |
| Verification | 小さなDiffを頻繁に確認 | AIによる多段検証 |
| 向く組織 | 理解重視・予算制約あり | 少人数・高速開発重視 |
重要なのは、
Large Modelが正しく、Small Modelが古い
という話ではないことです。
組織が何を重視するかによって変わります。
「AIの知能最大化」と「チームの認知能力最大化」は違う
Large Model中心では、
AI単体の知能を最大化する
という方向に進みやすくなります。
一方、Small Model + Human-in-the-loopでは、
Human + AIを合わせたチーム全体の認知能力を最大化する
という考え方ができます。Small Modelを使うことは、
「性能の低いAIで我慢する」
という意味ではありません。人間がDomain Intelligenceを持ち、
Human
=
Domain Intelligence
+
Decision
AI
=
Execution Intelligence
と役割を分ける。これも立派なAI開発戦略です。
人間の認知能力には限界がある
最終的には、この問題に戻ってくると思います。AIは大量の情報を処理できます。人間には限界があります。
だから、
Large Model
↓
AIに大量に任せる
↓
人間のレビューを減らす必要がある
↓
AI Review / Test / Risk Classification
という方向も合理的です。
一方、
Small Model
↓
小さく進める
↓
人間が毎回理解する
↓
認知状態を維持する
という方向も合理的です。
前者では、
Human Reviewの回数を減らす
ことを重視する。
後者では、
一回あたりのHuman Reviewを小さくする
ことを重視する。
これはトレードオフです。
まとめ
AI時代のソフトウェア開発では、
どのモデルが最も賢いか
だけを考えるのでは不十分だと思います。
本当に重要なのは、
どこまでAIに判断を委ね、どこから人間が責任を持つのか
という境界設計です。
Large Model中心なら、
Context
+
Goal
+
Acceptance Criteria
を明確にし、
AI Review
+
Automated Test
+
Risk-based Human-in-the-loop
によって人間のVerification負荷を減らしていく。
Small Model中心なら、
Context
+
Procedure
+
Constraints
を明確にし、
Spec
↓
Atomic Task
↓
Small Diff
↓
Human Check
という短いループを回す。
そしてDDDやTraceabilityを組み合わせることで、
Business Intent
↓
Issue / ADR
↓
Specification
↓
Code / Test
↓
Commit / PR
を追跡可能にする。
私は、AI時代の開発で重要になるのは、
AIにすべて考えさせることではなく、人間とAIのどちらに、どの種類の認知を担当させるかを設計すること
なのではないかと思っています。
Large Modelでは、
モデル内部にReasoningを持たせる。
Small Model + SDDでは、
Reasoningを開発プロセスそのものに埋め込む。
どちらが正しいという話ではありません。
組織の開発文化、予算、Domain Knowledge、求める速度、そして人間をどこまで開発ループに残したいのか。
その違いによって、最適なAI開発スタイルも変わっていくのだと思います。