AIコード生成の「責務トレース」という発想——確率的出力の品質をどう担保するか

ChatGPTやClaude、GitHub Copilotなど、生成AIを使ったコーディングが日常的になった今、多くの開発者が直面している課題があります。それは「AIが生成したコードが、意図した通りの責務を果たしているか」という検証の難しさです。

生成AIは確率モデルに基づいて動作するため、同じプロンプトでも異なる出力を返すことがあります。特に問題なのは、要件定義→設計書→実装コードという「ドキュメント間の変換」を繰り返す過程で、本来保持すべき責務が静かに変質していくケースです。

今回取り上げる投稿は、この問題に対して「責務をトレースする」という斬新なアプローチを提案しています。ソフトウェア開発を「次元変換」として捉え直すことで、AIの確率的な振る舞いの中から品質担保の糸口を見出そうとする試みです。

投稿者が提示する核心的な視点は、ソフトウェア開発を「次元変換のプロセス」として理解することです。

従来、ソフトウェア開発は「上流から下流への情報の流れ」として理解されてきました。しかし、AIを介在させた開発では、この捉え方だけでは不十分です。なぜなら、AIは各ステップで**確率的に新しい表現を生成**するからです。

これらは単なる「詳細化」ではなく、異なる表現空間への「変換」です。AIがこの変換を行う際、入力と出力の間に厳密な対応関係は保証されません。数学的には同じ情報を表現していても、責務の重点が微妙にずれることがあるのです。

投稿が提起する問いはこうです。

生成のたびに責務をトレースすれば、ドキュメント間で責務が異常に変化した箇所を、捉えられるのではないか。

これは非常に実践的な着眼点です。具体的には以下のような仕組みが考えられます。

1. **各ドキュメントから責務を抽出**

要件定義、設計書、実装コードそれぞれから「このドキュメントが果たすべき責務」をリスト化

2. **責務の対応関係をマッピング**

上流の責務A→下流の責務B、C という対応を明示化

3. **異常な変化を検出**

- 責務が突然消失している

- 責務が意図せず追加されている

- 責務の重要度が不自然に変化している

このアプローチの革新性は、**AIの出力を「正しいか間違いか」の二元論で判定するのではなく、変換過程の整合性を連続的にモニタリングする**点にあります。

従来のテスト手法との違い

従来のソフトウェアテストは、主に「実装が仕様を満たすか」を検証するものでした。ユニットテスト、結合テスト、E2Eテストなど、いずれも**最終成果物の振る舞い**に焦点を当てています。

一方、責務トレースのアプローチは**変換プロセスそのもの**を監視対象とします。これは、AIが介在する開発プロセス特有の課題に対応した手法と言えます。

| 観点 | 従来のテスト | 責務トレース |

|------|------------|------------|

| 検証対象 | 最終成果物 | 変換プロセス全体 |

| 検出できる問題 | 機能の不具合 | 意味の揺らぎ、責務の変質 |

| AI適用時の有効性 | 限定的 | 高い |

| 実装の容易さ | 確立された手法あり | 新規開発が必要 |

メリット：早期の意味的ドリフト検出

最大のメリットは、**意味的なドリフトを早期に発見できる**ことです。

従来の手法では、実装が完了してテストを実行して初めて「あれ、この機能は要件にない」と気づくことがありました。責務トレースを導入すれば、設計書生成の段階で「この責務は要件定義に存在しなかった」という警告を出せます。

これにより、手戻りのコストを大幅に削減できます。実装後の修正は設計段階の10倍、要件段階の100倍のコストがかかると言われる中、この早期検出の価値は計り知れません。

注意点：責務の定義と抽出の難しさ

一方で、実装上の課題もあります。最大の難点は**「責務とは何か」を形式的に定義し、自動抽出する難しさ**です。

責務は、コードのシグネチャやクラス構造から機械的に抽出できるものばかりではありません。「ユーザーのプライバシーを守る」「システムの拡張性を維持する」といった非機能要件的な責務をどう表現し、トレースするかは未解決の問題です。

現実的には、以下のような段階的アプローチが有効でしょう。

1. **第1段階**: 機能的責務（「データを保存する」「バリデーションを行う」など）に限定

2. **第2段階**: タグやアノテーションで明示的にマークした責務のみ追跡

3. **第3段階**: LLMを用いた自然言語ベースの責務抽出と対応付け

適用が有効なケース

このアプローチが特に効果を発揮するのは、以下のような場面です。

逆に、シンプルな単機能のユーティリティ実装など、変換ステップが少ない場合は、オーバーヘッドの方が大きくなる可能性があります。

1. 手動での責務マッピング演習

まずは小規模なプロジェクトで、手動で責務をトレースしてみましょう。

## 要件定義の責務
- [R1] ユーザー入力を検証する
- [R2] データベースに保存する
- [R3] 成功・失敗をユーザーに通知する

## 設計書の責務
- [D1] ValidationService: 入力検証ロジック ← R1に対応
- [D2] UserRepository: DB操作の抽象化 ← R2に対応
- [D3] NotificationService: 通知処理 ← R3に対応

## 実装コードの責務
- [C1] UserController.validate() ← D1に対応
- [C2] UserRepository.save() ← D2に対応
- [C3] EmailNotifier.send() ← D3に対応

この対応関係を明示的に記録することで、責務の変質や欠落を発見できます。

2. AIに責務の差分分析をさせる

ChatGPTやClaudeに、2つのドキュメント間の責務の差分を分析させるプロンプトを作成します。

以下の2つのドキュメントを比較し、責務の対応関係と、
異常な変化（追加・削除・変質）を指摘してください。

【要件定義】
...

【設計書】
...

出力形式：
- 対応する責務のペア
- 新たに追加された責務
- 削除された責務
- 意味が変化した責務

これを定型化し、CI/CDパイプラインに組み込むことも検討できます。

3. コードレビューに責務チェックを追加

プルリクエストのテンプレートに、責務トレースの項目を追加しましょう。

## 責務の整合性チェック
- [ ] この変更で新たに追加された責務は文書化されているか
- [ ] 既存の責務が意図せず変更されていないか
- [ ] 上流ドキュメント（要件・設計）との対応が明確か

最初は形式的でも、チーム内で責務を意識する文化が育つことで、AI生成コードの品質が大きく向上します。

AIは確率的に振る舞いますが、ソフトウェアは決定的に動作しなければなりません。この矛盾をどう解消するかが、AI時代の開発の核心的課題です。

責務トレースというアプローチは、AIの柔軟性を活かしながら、開発プロセスの整合性を担保する有望な方向性を示しています。まだ理論段階の部分も多いですが、小さく始めて徐々に洗練させていくことで、AIと人間が協調する新しい開発スタイルが確立されるでしょう。

この情報は @cognitiveosmdl さんの投稿を参考にしています。