はじめに
生成AIの登場によって、ソフトウェア開発の役割は大きく変わりました。
- コードを書く時間が減った
- レビューや検証の重要性が上がった
この変化を理解する一つの視点として、複雑性クラスに当てはめて整理してみます。
※実務は厳密な計算問題ではないため、あくまで性質の類似です。
複雑性クラス
複雑性クラスは多数ありますが、
- P問題（多項式時間で解ける問題）
- NP問題（多項式時間で正しさを検証できる問題）
- NP完全問題（NP問題の中で最も難しい問題）
- NP困難問題（NP問題と同等以上に難しい問題）
に絞って分類します。
これらの関係は以下のようになります。
※注意：P≠NPとして図示しています。
P問題
多項式時間で解ける問題 ＝ 手順が明確で機械的に解ける仕事
- 手順が明確
- 入出力が決まっている
- 再現性が高い
ツールやスクリプトで自動化できる領域
業務例
- CRUD実装（単純ロジック）
- SQL生成
- マイグレーション
- APIスケルトン生成
- コード変換（DTO ⇔ Entity）
- 定型バッチ処理
NP問題
多項式時間で正しさを検証できる問題 ＝ 作るのは難しいが正しさを確認できる仕事
- 解を作るのが難しい
- 正しさは検証できる
正しいかどうかをテストやレビューで判断できる領域
業務例
- 詳細設計書 ⇒ コーディング
- テストコード作成
- 単体テスト作成
- バグ修正
- コードレビュー
- API設計（要件が明確な場合）
NP完全問題
NP問題の中で最も難しい問題 ＝ 最適解を見つけるのが極めて難しい仕事
- 選択肢が爆発的に増える
- 最適解が見つけにくい
設計力・経験・トレードオフ判断が問われる領域
業務例
- アーキテクチャ設計
- マイクロサービス分割
- DB設計
- パフォーマンス最適化
- キャッシュ戦略設計
- 大規模リファクタリング
NP困難問題
NP問題と同等以上に難しい問題 ＝ 正解の定義自体が難しい仕事
- 正解の定義が曖昧
- 検証すら難しい
意思決定の領域
業務例
- 要件定義
- プロダクト企画
- UX設計
- 技術選定
- 開発プロセス設計
- チーム設計
複雑性 と 仕事 と 生成AI と 人間
複雑性 と 仕事
複雑性と仕事の関係は以下の通りです。
| 複雑性 | 仕事 |
|---|---|
| P問題 | 手順が明確で機械的に解ける仕事 |
| NP問題 | 作るのは難しいが正しさを確認できる仕事 |
| NP完全問題 | 最適解を見つけるのが極めて難しい仕事 |
| NP困難問題 | 正解の定義自体が難しい仕事 |
仕事 と 生成AI
生成AIは問題を解いているのか？
生成AIはアルゴリズムとして問題を解いているわけではありません。
入力に対して尤もらしい回答を出力します。
そのため、正しい答えを出すことはありますが、常に正しさが保証されるわけではありません。
生成AIは
「解く」のではなく「候補を生成する」
生成AIはどんな仕事が出来るか？
P問題に対して、高い精度で実装やコード生成を行うことができます。
NP問題に対して、解の候補を高速に生成し、探索を大幅に効率化します。
ただし、NP困難問題に対しては、人間による問題設定や評価が不可欠です。
生成AIは
- P問題を自動化
- NP問題を支援
- NP困難問題は人間依存
生成AI と 人間
人間の役割の再定義
生成AIの導入により、人間の役割は変化します。
重要になるのは、問題の解き方よりも扱い方です。
生成AI時代における人間の役割は3つに集約できます。
① 検証能力
- 出力結果の正しさを判断する
- テスト・レビューを設計する
- 境界条件・例外を確認する
NP問題の「検証側」
② 問題定義能力
- 入力・制約・評価軸を明確にする
- 何を解くべきかを決める
- 成功条件を定義する
NP困難問題の領域
③ 分解能力（＝帰着）
- 問題を部分問題に分割する
- 検証可能な形に変換する
- 生成AIが扱える粒度に落とす
NP問題に帰着可能（＝検証可能）な形へ変換する能力
おわりに
複雑性クラスの関係で見ると、生成AIの本質が見えてきます。
| 複雑性 | 本質 | 担い手 |
|---|---|---|
| P問題 | 手順化可能 | 自動化・ツール |
| NP問題 | 検証可能 | 生成AI（生成）＋人間（検証） |
| NP完全問題 | 最適化問題 | 人間中心 |
| NP困難問題 | 意思決定 | 人間の領域 |
生成AIは解答者ではなく、解答の候補を大量に出す存在です。
そして、人間は問題を「分解し、検証し、定義する」側に回ります。
生成AI時代におけるエンジニアに求められるのは、「問題を解くこと」ではなく「問題を解ける形に変換すること」です。