AIはソフトウェア開発を効率化するだけなのか。それとも、ソフトウェアエンジニアリングという仕事そのものを根本から変えてしまうのか。
2026年9月19日、ソフトウェアエンジニアの Thorsten Ball氏 が、X（旧Twitter）で「What I believe about the future of software development（私が考えるソフトウェア開発の未来）」という文章を公開しました。
その内容は、従来の開発常識を覆す、非常に大胆なものです。
例えば、以下のような予測が提示されています。
- コードレビューは消滅する
- ユニットテストも不要になるかもしれない
- コードを書く技術そのものの価値は低下する
- ターミナルやCLIを人間が操作する時代は終わる
- PM・デザイナー・エンジニアという役割分担は崩壊する
- AIのトークンが新しいコンピューティングの中心になる
- UIはAIがリアルタイムで生成するようになる
これらは刺激的な予測ですが、単に「プログラマーの仕事がAIに奪われる」という話ではありません。
むしろ、中心にあるのは次の考え方です。
コードを書くことの価値は下がっても、ソフトウェアによって問題を解決する能力の価値は、これまで以上に高まる。
本記事では、Thorsten Ball氏の16の予測を整理したうえで、現場でシステム開発を行うエンジニアの視点から、その意味と課題を考察します。
なお、以下は原文の逐語訳ではなく、論点を整理した要約と筆者による技術的考察です。また、氏の主張は将来予測であり、すでに業界全体で実現・実証された事実ではありません。
1. AIが変えるソフトウェア開発の全体像
まず、16の予測を一覧にしてみます。
| # | Thorsten Ball氏の予測 | 想定される変化 |
|---|---|---|
| 1 | コードレビューは消滅する | 人間はコードよりシステム全体を評価する |
| 2 | ユニットテストも消えるかもしれない | テストの粒度や品質保証の方法が変化する |
| 3 | コードを書く職人技は消える | 手書きの実装能力の相対的価値が下がる |
| 4 | ソフトウェアを作る能力はより重要になる | 課題解決・設計・提供価値が中心になる |
| 5 | バグの多くは要求の間違いになる | 要件定義と仕様の正確性が重要になる |
| 6 | 現在のOSSのあり方は通用しなくなる | AIによる開発・レビューが貢献モデルを変える |
| 7 | 人間による性能最適化は例外的になる | 必要な最適化もAIが担当するようになる |
| 8 | ターミナルは消える | 自然言語によるツール操作が中心になる |
| 9 | トークンが新しい計算パラダイムになる | AI推論が重要な計算資源になる |
| 10 | PM・Design・Engineeringの分業が消える | AIを活用した職種横断型の開発が増える |
| 11 | 大企業と小規模組織の開発手法の差が広がる | 小規模チームの開発速度が大幅に向上する |
| 12 | 従来の「良いコード」の定義が変わる | 人間の読みやすさ以外の評価軸が重要になる |
| 13 | トークン不足が開発競争力の格差を生む | AI利用能力と計算資源が競争条件になる |
| 14 | 安価なモデルが選ばれるとは限らない | 精度と再試行回数を含めた評価が重要になる |
| 15 | UIはその場で生成される | 固定画面から動的インターフェースへ移行する |
| 16 | この変化には長い時間がかかる | 既存システムと新しい開発手法が長期間共存する |
特に重要なのは、これらが独立した予測ではないという点です。
AIがコードを生成できるようになると、コードレビューの役割が変わります。コードレビューが変わると、テストの位置付けも変わります。実装コストが下がれば、組織構造や開発プロセスにも変化が生まれます。
つまり、AIによるコード生成の進化が、ソフトウェア開発のライフサイクル全体に連鎖的な影響を及ぼすというのが、この文章の本質だと考えられます。
2. コードレビューは本当に消滅するのか？
従来のコードレビューが前提としているもの
一般的なGitベースの開発では、次のようなフローが採用されています。
開発者がコードを書く
↓
Pull Requestを作成
↓
他の開発者がコードを確認
↓
修正・レビュー
↓
マージ
↓
デプロイ
この開発フローは、人間がコードを作成し、人間が変更内容を理解できることを前提としています。
しかし、AIエージェントが短時間に数千行、数万行のコードを生成するようになると、すべてを人間が読んで確認する方法は非効率になります。
Thorsten Ball氏は、将来的には人間がモデル生成コードの不具合を合理的な時間内に発見することが難しくなり、レビュー対象は個々のコードからシステム全体の構成へ移ると予測しています。
レビュー対象は「実装」から「振る舞い」へ
例えば、ECサイトにクーポン機能を追加する場合を考えてみます。
従来のレビューでは、以下を確認します。
- SQLクエリが適切か
- 条件分岐が正しいか
- コーディング規約を守っているか
- 例外処理が実装されているか
AI主体の開発では、レビュー対象が次のように変化する可能性があります。
- クーポンの適用条件は業務要件と一致しているか
- 併用禁止ルールが守られているか
- 不正利用できる設計になっていないか
- 決済システムとの整合性は保証されているか
- 障害発生時に安全に復旧できるか
つまり、重要なのは「どのように実装したか」だけではなく、「システムが期待通りに振る舞うか」です。
筆者の考察
コードレビュー自体が完全に不要になるとは限りません。
特に、認証・認可、決済、個人情報処理、暗号処理、インフラ設定などでは、コードや設定の具体的な検証が必要になる場面が残るでしょう。
一方で、すべての差分を人間が読み続ける方法から、変更リスクに応じてアーキテクチャ、契約、セキュリティ、実行結果を検証する方法への移行は、十分に現実的です。
3. ユニットテストは不要になるのか？
Thorsten Ball氏は、AIが約900行のArduino向けCコードを生成し、コンパイルエラーなくデバイス上で正常に動作させた経験を紹介しています。
この経験から、AIの実装精度がさらに向上すれば、従来のユニットテストの必要性も低下するのではないかと問いかけています。
ただし、この予測には慎重な検討が必要です。
コンパイル成功と仕様の正しさは違う
例えば、割引金額を計算する関数があったとします。
def calculate_discount(price, discount_rate):
return price * discount_rate
このコードは構文的には正しく、正常に実行できます。
しかし、業務仕様が「割引後の販売価格を返す」であれば、実装は誤りです。
正しくは次のようになります。
def calculate_discount(price, discount_rate):
return price * (1 - discount_rate)
AIが高度になっても、仕様が曖昧であれば、間違った実装を正しく生成してしまう可能性があります。
テストの価値は残るが、重点が変わる
従来は、関数単位のユニットテストが品質保証の中心となることが多くありました。
しかし、AIが実装を大量に生成する時代には、次のようなテストの重要性がさらに高まると考えられます。
| テスト | AI時代における役割 |
|---|---|
| Unit Test | 局所的なロジックの検証 |
| Integration Test | APIやDBなどの連携検証 |
| Contract Test | システム間の入出力契約の検証 |
| E2E Test | ユーザー操作と業務フローの検証 |
| Security Test | 権限・攻撃経路・脆弱性の検証 |
| Property-based Test | 広範な入力に対する性質の検証 |
特に、AIが実装を担当しても、期待する動作を独立して検証する仕組みは必要です。
AIがコードとテストを同時に生成する場合、両方が同じ仕様の誤解を含む可能性にも注意しなければなりません。
テストは、単にプログラムが動くことを確認するものではなく、ビジネス上の約束を検証する仕組みだからです。
4. コードを書く能力より、ソフトウェアを作る能力が重要になる
これは、16の予測の中でも特に重要な主張です。
Thorsten Ball氏は、コードを書く職人的技術の価値が薄れる一方で、ソフトウェアを構築する能力はこれまで以上に重要になると考えています。
両者は同じものではありません。
コーディングとソフトウェアエンジニアリングの違い
コーディングとは、仕様に基づいてプログラムを実装する活動です。
一方、ソフトウェアエンジニアリングには、さらに広い活動が含まれます。
ビジネス課題の発見
↓
要件定義
↓
システム設計
↓
実装
↓
テスト
↓
リリース
↓
監視・運用
↓
ユーザーフィードバック
↓
継続的な改善
AIが実装の大部分を担当できるようになった場合でも、以下の判断は重要です。
- どの課題を解決するべきか
- 本当にシステム化が必要なのか
- どのデータを管理するのか
- 既存システムとどう連携するのか
- いつリリースするべきか
- 何をもって成功と判断するのか
例えば、Laravelで管理画面を作成すること自体は、AIによって大幅に高速化できます。
しかし、管理画面で実現するべき業務フロー、権限設計、データ整合性、承認プロセスまで自動的に正解が決まるわけではありません。
AIが「作り方」を支援するほど、人間には「何を、なぜ作るのか」を判断する力が求められるのです。
5. バグの中心は「コードの間違い」から「要求の間違い」へ
従来の開発では、以下のような不具合が日常的に発生してきました。
- Null参照
- 型の不一致
- SQL構文エラー
- 条件分岐の間違い
- メモリ管理の不備
- APIレスポンスの処理漏れ
AIが進化すれば、こうした実装上のミスは減少する可能性があります。
しかし、より根本的な問題が残ります。
それは、AIに何を実装させるべきかという要求自体が間違っているケースです。
具体例：会員向けクーポン機能
AIに次のような指示を与えたとします。
会員向けにクーポン機能を実装してください。
クーポンコードを入力すると10%割引してください。
AIは短時間で動作する機能を実装できるかもしれません。
しかし、この指示には多くの未定義事項があります。
- 有効期限はあるのか
- 一人何回まで使えるのか
- 他のクーポンとの併用は可能か
- 返金時にどう扱うのか
- 利用履歴は保存するのか
- 最低購入金額の条件はあるのか
- 複数リクエストが同時に来たらどうするのか
AIが指示通りのコードを生成しても、ビジネスとして正しいシステムが完成するとは限りません。
これからの要件定義
AI時代には、曖昧な自然言語の要求を、検証可能な仕様へ落とし込む能力が重要になります。
例えば以下のように記述します。
feature: member_coupon
rules:
discount_rate: 0.10
minimum_purchase: 3000
max_usage_per_user: 1
allow_combination: false
constraints:
- expired_coupon_must_be_rejected
- coupon_usage_must_be_atomic
- refund_must_restore_eligibility_when_applicable
acceptance_criteria:
- 有効な会員が条件を満たせば割引される
- 有効期限切れのクーポンは拒否される
- 同時リクエストでも利用回数制限を超えない
- 利用履歴を監査できる
※これは仕様記述の一例であり、実際には有効期限の定義や返金ポリシーなども別途明確にする必要があります。
このように、要件を機械が検証しやすい形式に変換することで、AIエージェントによる実装と自動テストをつなげやすくなります。
6. ターミナルやCLIは消えるのか？
Thorsten Ball氏は、自身もターミナルや開発ツールを愛用しているとしながら、将来的には人間がシェルやCLIを直接操作する機会は大幅に減ると予測しています。
例えば、従来のインフラ運用では以下のようなコマンドを使います。
docker ps
docker logs --tail 100 app
kubectl get pods
kubectl describe pod my-app
これらを組み合わせ、エンジニアが状況を調査します。
しかし、AIエージェントがツールを利用できれば、自然言語による操作が可能になります。
本番環境のAPIレスポンスが遅くなっています。
直近30分のメトリクスとログを確認し、
原因候補を優先順位付きで報告してください。
本番環境の設定変更は行わないでください。
AIエージェントは、許可された範囲内でログやメトリクスを収集し、調査結果を整理できます。
ターミナルが消えるのではなく、操作主体が変わる
ここで重要なのは、CLIそのものの消滅と、人間がCLIを直接操作しなくなることは別だという点です。
AIエージェントの内部では、依然としてシェル、API、データベースクライアントなどが利用される可能性があります。
一方で、運用権限をAIに与える場合には、別の問題が生まれます。
- 誤操作の防止
- 実行可能なコマンドの制限
- 本番変更の承認
- 機密情報へのアクセス管理
- 操作履歴の監査
- 障害発生時のロールバック
AIがインフラを操作するようになっても、権限設計と運用統制の重要性がなくなるわけではありません。
むしろ、自動化できる操作範囲が広がるほど、これらの重要性は高まるでしょう。
7. AIトークンが新しいコンピューティングの中心になる
Thorsten Ball氏は、トークンを新しい計算パラダイムとして位置付けています。
従来のコンピューティングでは、CPU、メモリ、ストレージ、ネットワーク帯域などが中心的な計算資源でした。
AIエージェントを利用するシステムでは、それらに加えて、モデルの推論能力やトークン消費量が重要な設計要素になります。
従来のアプリケーション
ユーザー
↓
Webアプリケーション
↓
プログラムによる処理
↓
Database
↓
結果を返す
AIエージェントを組み込んだアプリケーション
ユーザー
↓
要求の解釈
↓
AIモデルによる推論
↓
必要なツールを選択
↓
API・DB・外部サービスを実行
↓
実行結果を評価
↓
必要に応じて再推論
↓
結果を返す
従来は開発者が明示的に処理フローを実装していました。
しかしAIエージェント型のシステムでは、モデルが実行時に処理の一部を判断するようになります。
ただし、決定的処理が不要になるわけではない
例えば、銀行の残高更新や在庫引当、決済金額の確定などは、依然として厳密な整合性と再現性が必要です。
AIによる推論を利用する場合も、最終的な状態変更は検証可能で決定的な処理に任せる設計が合理的です。
AI：ユーザーの意図を理解する
↓
AI：必要な操作を提案する
↓
システム：権限・制約を検証する
↓
システム：決定的な業務処理を実行する
↓
AI：結果を説明する
AI推論は、従来のコンピューティングを完全に置き換えるというより、既存の計算基盤の上に新しい判断レイヤーを追加するものと考えるのが、現時点では実務的でしょう。
## 8. PM・デザイナー・エンジニアの分業は崩壊するのか？
従来のソフトウェア開発では、主に次の役割で分業してきました。
| 職種 | 主な役割 |
|---|---|
| Product Manager | 何を作るか決める |
| Designer | UX・UIを設計する |
| Engineer | システムを実装する |
これらの役割を組み合わせて開発を進めるのが一般的です。
しかし、AIエージェントが要件整理、UI設計、実装、テストまで担当できるようになると、役割の境界が曖昧になります。
AIによって開発組織はどう変わるのか
従来の開発フローは次のようなものです。
一方、AIを中心とした開発では、次のような構成も考えられます。
この構成では、人間が各工程の作業を細かく分担する必要性は低下します。
一人のエンジニアが、複数の専門エージェントを利用しながら、プロダクト開発全体を進められる可能性があります。
AgileやScrumも不要になる？
Thorsten Ball氏は、AgileやScrumのような既存の開発プロセスについても、かなり否定的な見方を示しています。
従来のScrumは、人間のチームが一定期間で開発できる作業量を見積もり、調整することを前提としています。
しかし、AIによって実装速度が劇的に上がれば、2週間単位のスプリントやチケット管理が、必ずしも最適な方法ではなくなるかもしれません。
ただし、開発速度が上がっても、ステークホルダーとの合意形成やビジネス上の優先順位付けが不要になるわけではありません。
変化するのは、人間の実装作業を管理するプロセスから、AIを含むシステムの成果と品質を管理するプロセスへの移行だと考えられます。
9. 大企業とスタートアップの開発方法はさらに違ってくる
Thorsten Ball氏は、大企業と小規模組織のソフトウェア開発の違いが、今後さらに大きくなると予測しています。
大企業では、一般的に以下のようなプロセスが必要になります。
- 複数部署との調整
- セキュリティレビュー
- 承認プロセス
- システム間の依存関係の管理
- コンプライアンス対応
- 既存システムとの互換性維持
これらは組織規模やシステムの複雑さによって必要になるものです。
一方、小規模チームでは、AIエージェントを利用することで、少人数でも大きな開発成果を出せる可能性があります。
例えば、従来はフロントエンド、バックエンド、インフラ、QAの担当者が必要だったプロジェクトでも、AIを活用できるエンジニアが複数領域を横断して開発できるようになるかもしれません。
重要なのは開発人数ではなく、意思決定の速度
AIによってコード生成のコストが下がった場合、開発のボトルネックは別の場所に移動します。
従来のボトルネック
↓
実装工数・開発者の人数
AI時代のボトルネック
↓
要求の曖昧さ
意思決定の遅さ
検証環境の不足
組織内の調整
本番リリースの制約
この変化は、少人数の開発チームにとって大きなチャンスになるでしょう。
ただし、大企業のプロセスを単に削減すればよいという話ではありません。システムの影響範囲やリスクに応じて、必要な統制を維持することが重要です。
10. 「良いコード」の定義が変わる
これまでのソフトウェア開発では、読みやすく、保守しやすいコードが高く評価されてきました。
例えば、以下のような原則があります。
- DRY（Don't Repeat Yourself）
- KISS（Keep It Simple, Stupid）
- SOLID原則
- Clean Architecture
- コーディング規約の統一
- 適切な命名
- 一貫性のあるコードフォーマット
これらの多くは、人間がコードを理解し、修正し、保守することを前提にしています。
しかし、将来的にコードの大部分をAIが生成・変更するようになった場合、人間の読みやすさが最優先の評価基準であり続けるとは限りません。
AI時代のコード品質
例えば、次のような評価軸が考えられます。
| 従来の評価軸 | AI時代に重要になる可能性がある評価軸 |
|---|---|
| 人間による読みやすさ | 仕様との整合性 |
| コードの簡潔さ | 動作の検証可能性 |
| 命名規則 | システムの振る舞いの明確さ |
| 保守のしやすさ | AIによる安全な変更可能性 |
| 実装の美しさ | 障害時の復旧容易性 |
| コーディング規約 | セキュリティ・性能・運用上の制約 |
ただし、ここで注意が必要です。
読みやすいコードは人間のためだけのものではありません。明確なモジュール境界、単純な制御フロー、適切な型定義などは、AIがコードを分析・変更する場合にも役立つ可能性があります。
したがって、「良いコード」の基準が完全になくなるのではなく、人間中心の保守性から、人間とAIの双方が安全に変更できる構造へ評価軸が拡張されると考えるのが妥当でしょう。
11. オープンソースのあり方も変わる
オープンソースソフトウェアは、多くの開発者がコードを公開・改善し、共同でメンテナンスする文化によって発展してきました。
しかし、AIエージェントによってコードを大量に生成できるようになると、従来の貢献モデルが変化する可能性があります。
例えば、以下のような変化が考えられます。
- AIによるPull Requestの大量生成
- AIによる脆弱性調査
- 自動的な依存ライブラリの更新
- プロジェクト固有の機能追加
- AIによるコードレビュー
- AIを活用したドキュメント整備
課題はコード生成ではなく、信頼性と保守責任
AIがコードを生成できても、それだけでOSSプロジェクトが成立するわけではありません。
依然として以下の問題が存在します。
- 誰が保守責任を負うのか
- 脆弱性が発見された場合、誰が対応するのか
- ライセンス条件をどう守るのか
- 依存ライブラリの信頼性をどう確保するのか
- AIが生成した大量の変更をどう管理するのか
AI時代のOSSでは、コードを書く貢献に加えて、仕様の定義、互換性の維持、品質保証、信頼できる配布基盤の価値が高まる可能性があります。
12. 性能最適化もAIが担当する時代へ
従来、パフォーマンス最適化は経験豊富なエンジニアの専門領域でした。
例えば、Webシステムのレスポンスが遅い場合、以下のような調査を行います。
EXPLAIN
SELECT *
FROM orders
WHERE user_id = 100
ORDER BY created_at DESC
LIMIT 20;
実行計画を確認し、必要に応じてインデックスを追加します。
CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at);
※実際には、既存インデックス、データ分布、更新負荷、ロック、実行計画などを確認して判断する必要があります。
こうした調査についても、AIエージェントがメトリクスやクエリの実行計画を分析し、改善案を提示できるようになっています。
将来的には、負荷試験、実行計画の比較、改善案の実装まで自動化が進むでしょう。
ただし、Thorsten Ball氏が指摘する重要な点は、すべてのソフトウェアが最高レベルのパフォーマンスを必要とするわけではないということです。
ユーザーが少ないシステムで、極端な最適化に時間を費やしても、ビジネス価値につながるとは限りません。
大切なのは、最適化そのものではなく、必要な性能を適切なコストで実現することです。
13. トークンが開発競争力を左右する
AIエージェントを中心とした開発では、モデルの性能だけでなく、どれだけの推論処理を利用できるかも重要になります。
Thorsten Ball氏は、十分なトークンを利用できない開発者や組織が、競争上不利になる可能性を指摘しています。
これは、かつてコンピューターを所有できる人とできない人の間に存在した格差に似ています。
AI開発のコスト構造
AIエージェントを利用した開発では、例えば次のようなコストが発生します。
AI開発コスト
├── 入力トークン
├── 出力トークン
├── 推論・再試行
├── ツール実行
├── テスト環境
└── 人間による検証
ただし、トークン量だけで生産性が決まるわけではありません。
プロンプト設計、コンテキスト管理、ツール連携、テスト環境、モデル選定によって、同じ処理でもコストや成功率は大きく変わります。
安価なモデルが最も経済的とは限らない
例えば、以下の仮想的なケースを考えます。
| 項目 | Model A | Model B |
|---|---|---|
| 1回の実行コスト | $0.10 | $0.40 |
| 1回の成功率（仮定） | 60% | 95% |
| 成功までの期待実行回数 | 約1.67回 | 約1.05回 |
| 成功までの期待APIコスト | 約$0.17 | 約$0.42 |
単純にAPI料金だけで比較すれば、Model Aが安価です。
しかし、失敗によって人間の確認工数が増えたり、誤ったコードの修正が必要になったりすると、総コストは変化します。
上記の計算は、各試行の成功率が一定で独立しており、成功まで再試行するという単純化したモデルです。
実務では、次のような指標を組み合わせて評価するとよいでしょう。
Total Cost = API利用料金 + ツール実行コスト + 検証コスト + 失敗時の修正コスト
単価だけでなく、タスク完了率と総コストでモデルを評価することが重要になります。
14. UIはAIがリアルタイムで生成するようになる
Thorsten Ball氏の予測の中でも、特に興味深いのがUIの変化です。
現在のWebアプリケーションでは、開発者が事前に画面を設計します。
例えば、売上分析システムでは以下のようなUIを用意します。
- 日付範囲フィルター
- 店舗選択
- 売上グラフ
- CSVダウンロード
- 並び替え
- 各種設定画面
しかし、AIがユーザーの目的を理解できるのであれば、すべてのUIを事前に設計する必要はないかもしれません。
従来のUI
ユーザー
↓
売上分析画面を開く
↓
期間を選択
↓
店舗を選択
↓
グラフを選択
↓
データを確認
AIによる動的UI
ユーザーが次のように指示します。
先月と今月の店舗別売上を比較して、
売上が大きく減少している店舗を
グラフで表示してください。
AIは要求を理解し、必要なデータを取得して、その目的に合ったUIを生成します。
例えばReactを使ったシステムなら、AIに任意のHTMLやJavaScriptを直接実行させるのではなく、定義済みコンポーネントの構成データを生成させる方法が考えられます。
{
"type": "dashboard",
"title": "店舗別売上比較",
"components": [
{
"type": "bar_chart",
"data_source": "sales_comparison",
"x_axis": "shop_name",
"y_axis": "sales_amount"
},
{
"type": "table",
"data_source": "sales_comparison",
"columns": [
"shop_name",
"previous_month",
"current_month",
"change_rate"
]
}
]
}
このJSONは、AIが画面の構造を指定するための例です。実際にはJSON Schemaなどによる検証、認可されたデータソースへのアクセス制限、コンポーネントのホワイトリスト化が必要です。
固定UIは完全にはなくならない
動的UIには大きな可能性がありますが、すべての場面で適しているとは限りません。
例えば、決済確認、本人確認、重要な設定変更などでは、毎回同じUIが表示されることによる安心感や操作の再現性が重要です。
また、アクセシビリティ、操作の一貫性、監査可能性なども考慮する必要があります。
したがって、将来的には次のような使い分けが考えられます。
- 定型業務：固定UI
- データ分析：動的UI
- 探索的な操作：自然言語インターフェース
- 重要な承認操作：検証済みの固定UI
15. 既存システムとAIネイティブなシステムは長期間共存する
Thorsten Ball氏は、これらの変化が一夜にして実現するわけではないことも認めています。
既存のソフトウェアが新しいソフトウェアに置き換わるには、世代単位の時間が必要になるという見方です。
これは現実のシステム開発を考えても重要な指摘です。
企業には現在でも、さまざまな技術で構築されたシステムが残っています。
- レガシーPHP
- Javaの業務システム
- ASP / ASP.NET
- COBOL
- 古いERP
- 独自フレームワーク
これらのシステムは、技術的に古いからという理由だけで簡単に置き換えられるわけではありません。
業務プロセス、データ、外部連携、移行コストなどの制約が存在するためです。
現実的なのは段階的なAI導入
既存システムを全面的にAIネイティブな構造へ移行するのではなく、段階的に導入する方法が現実的です。
既存システム
↓
API・データアクセスの整理
↓
AIが利用可能なツールとして公開
↓
AIエージェントによる操作支援
↓
新機能を段階的にAI対応
↓
運用・検証を自動化
これは既存システムを維持しながら、AIの能力を利用できるアプローチです。
重要なのは、AI時代だからといって既存システムをすべて作り直す必要はないということです。
16. AI時代のソフトウェアエンジニアに必要な能力とは
ここまでの予測を整理すると、今後のエンジニアに求められる能力が見えてきます。
従来と今後で重要性が変わるスキル
| スキル | 今後の方向性 |
|---|---|
| プログラミング言語の文法知識 | 手書きの頻度は低下する可能性 |
| コードをゼロから実装する能力 | AIによる代替が進む |
| 要件定義 | 重要性が高まる |
| アーキテクチャ設計 | 重要性が高まる |
| データモデリング | 引き続き重要 |
| セキュリティ設計 | 重要性が高まる |
| AIエージェントの制御 | 新たに必要になる能力 |
| テスト・評価設計 | 重要性が高まる |
| ビジネス理解 | 重要性が高まる |
| システム運用・監視 | AIを活用した自動化へ移行 |
ここで誤解してはいけないのは、プログラミングを学ぶ必要がなくなるという意味ではないことです。
コードがどのように動くかを理解していなければ、AIが生成したシステムの問題点を評価することは難しくなります。
ただし、実装能力だけで他のエンジニアとの差別化を図ることは、今後さらに難しくなるでしょう。
エンジニアは「実装者」から「システムの設計・統括者」へ
AIエージェントを活用するエンジニアの役割は、次のように変化する可能性があります。
単にAIにプロンプトを送信できるだけでは不十分です。
AIが生成する成果物を評価し、失敗した場合に原因を切り分け、適切な制約を設計する能力が求められます。
17. 現場のシステム開発では、今から何を変えるべきか？
ここまでの予測は非常に大胆ですが、すべてが実現することを前提に開発プロセスを変更するのは危険です。
重要なのは、すでに実用化できる技術と、まだ検証が必要な将来予測を区別することです。
現時点で取り組む価値が高い施策を整理します。
① 要件をAIが扱いやすい形式で管理する
曖昧な仕様書だけでなく、受け入れ条件、入力・出力、制約、エラー条件を明確にします。
特に、業務ルールをテスト可能な形で記述することが重要です。
② AIが実装できる開発環境を整備する
AIエージェントが、安全にコードを生成・検証できる環境を用意します。
例えば、以下のような環境です。
Git Repository
↓
AI Coding Agent
↓
コード生成・修正
↓
CIによる検証
├── Unit Test
├── Integration Test
├── Static Analysis
└── Security Check
↓
Staging Environment
↓
人間による評価・承認
↓
Production
人間が全行をレビューできない場合でも、検証可能なプロセスを維持することが重要です。
③ AIエージェントに最小権限を適用する
AIが操作可能な範囲を明確に分離します。
例えば、本番DBの参照権限と更新権限を分け、破壊的な変更には人間の承認を必要とします。
AIを利用する場合も、最小権限の原則は変わりません。
④ AIの成果を定量的に評価する
AI導入の効果を、生成コード量やプロンプト回数だけで評価するべきではありません。
重要なのは、実際の開発成果です。
例えば以下の指標が考えられます。
| 指標 | 評価したいこと |
|---|---|
| Lead Time | 要求から本番反映までの時間 |
| Change Failure Rate | 変更に伴う障害の発生割合 |
| MTTR | 障害からの復旧時間 |
| Task Completion Rate | AIがタスクを完了できた割合 |
| Cost per Completed Task | 完了タスクあたりの総コスト |
| Escaped Defects | 本番まで流出した不具合 |
これらをAI導入前後で比較することで、生産性の改善だけでなく品質への影響も評価できます。
⑤ 小さな領域からAIエージェントを導入する
最初から本番システム全体をAIに操作させる必要はありません。
例えば、以下のような作業から始めるのが現実的です。
- ログ分析やSQL調査の支援
- テストコードやドキュメントの生成
- 既存機能のリファクタリング
- 監視アラートの一次分析
- ステージング環境での限定的な自動修正
こうした小規模な導入で精度、コスト、リスクを確認し、適用範囲を広げていく方法が合理的です。
18. まとめ：AIはエンジニアを不要にするのではなく、エンジニアリングの中心を変える
Thorsten Ball氏の予測は、現在の開発文化に対する非常に大胆な問題提起です。
特に注目するべきなのは、コードレビューやターミナルが本当に消えるかどうかではありません。
ソフトウェア開発の価値が、コードを生産することから、正しいシステムを構築することへさらに移っていくという視点です。
AIによって実装コストが低下すると、これまで見過ごされてきた課題が重要になります。
- 何を作るべきなのか
- 要求は本当に正しいのか
- システムは安全に動作するのか
- ビジネス上の価値を提供できるのか
- AIが作成した成果物をどのように検証するのか
- どこまで自動化し、どこに人間の判断を残すのか
これらは、プログラミング言語やフレームワークだけでは解決できない問題です。
今後のソフトウェアエンジニアにとって重要なのは、コードを書くスピードだけではなく、AIを適切に利用して、信頼できるシステムを設計・構築・運用する能力になるでしょう。
もちろん、未来が原文の予測通りになるとは限りません。
しかし、AIによって実装方法と開発プロセスが変化している以上、これまでの開発常識を定期的に見直す必要があることは確かです。
これからのエンジニアに問われるのは、「どれだけコードを書けるか」だけでなく、「AIを使って、どれだけ価値のあるソフトウェアを生み出せるか」なのだと思います。
参考資料
- Thorsten Ball — What I believe about the future of software development（2026年9月19日）
- Thorsten Ball氏のX投稿
- Thorsten Ball — 公式サイト
- Amp — AI Coding Agent
本記事は、Thorsten Ball氏が公開した将来予測をもとに、ソフトウェア開発の実務への影響を考察したものです。原文の予測と筆者の解釈は必ずしも一致せず、将来の技術動向を保証するものではありません。