AI時代のソフトウェア工学における八つの栄光と恥辱：コード削減からAI操作可能空間の拡大へ
2026-06-03
- システムに必要なことを誇りとし、チームの制約を恥とする。
- 局所的な自律を誇りとし、全体への波及を恥とする。
- 明示的なロジックを誇りとし、暗黙のルールを恥とする。
- 特化した実装を誇りとし、汎用的な互換性を恥とする。
- クローズドループでの検証を誇りとし、人手による対応を恥とする。
- 制御可能な権限委譲を誇りとし、過度なリスク回避を恥とする。
- 並行反復を誇りとし、単一ラインでの推進を恥とする。
- リファクタリングによる打開を誇りとし、パッチでの安易な妥協を恥とする。
AI時代のソフトウェア工学において、本当に変わったのは「誰がコードを書くか」ではなく、ソフトウェア工学のコスト構造が根本的にシフトしたことです。かつては、コード作成コストが高く、クロスチームでの協業コストが高く、採用や知識移転のコストも高かったため、多くのエンジニアリングプラクティスが「コードを減らす、技術を変えない、分岐を減らす、コミュニケーションを減らす」ことに集中していました。その結果、フルスタック同一化、統一データベース、汎用フレームワーク、ミドルウェア基盤、最小限の変更、人手によるバックアップは、当時は合理的な選択だったのです。
しかし、AIが介入したことで、従来のコスト構造は緩み始めました。コード生成コストの低下、言語横断的な理解コストの低下、使い捨てスクリプト、グルーコード、局所的な実装、特化ツールのコストも低下しました。その一方で、本当に高価なものは次のようになりました：コンテキスト理解、システム検証、実行監視、責任境界、自動化実行権限、そしてソフトウェアが継続的に進化できるかどうかです。したがって、AI時代のソフトウェア工学は「コード削減」を中心に据えるのではなく、「AIの操作可能空間の拡大」を中心に据えるべきです。
これこそが「AI時代のソフトウェア工学における八つの栄光と恥辱」の出発点です。
一、システムに必要なことを誇りとし、チームの制約を恥とする
従来のエンジニアリングでは、多くの技術選定はシステム自体によって決められるのではなく、チームが現在何を知っているかによって決められていました。フロントエンドチームがJavaScriptに精通していれば、バックエンドもJavaScriptに。チームがPostgresしか知らなければ、キャッシュ、分析、コールドデータ、ファクトデータもすべて同じデータベースに詰め込んでしまう。チームがRustに詳しくなければ、高性能バックエンドに適した言語をあきらめる。
このやり方には過去に合理性がありました。なぜなら、人件費が高く、技術スタックをまたいだ協業が難しかったからです。しかし、AIは言語、フレームワーク、ツールを横断する理解コストを低減しました。現在、ソフトウェアシステムは「システムが必要とするものを使う」という原則に立ち返るべきです。フロントエンドはTypeScript、バックエンドはRust、データ分析はPython、ホットデータはRedis、コールドデータはParquet、トランザクションファクトはPostgresという選択が可能です。技術スタックはもはやチームの在庫に合わせる必要はなく、システムの責務に従うべきです。
二、局所的な自律を誇りとし、全体への波及を恥とする
ここでいう「局所的な自律」とは、従来の意味でのモジュールカプセル化や、単なる高凝集・低結合を指すものではありません。従来のモジュールはたとえ適切にカプセル化されていても、依然として大きなシステムに依存し、独立して存在できないことがよくありました。AI時代においてより重要な局所的自律とは、ビジネスシナリオレベルでの複数アプリの独立した自律です。
かつて私たちはミドルウェア基盤（中台）を構築することを好み、複数の類似したビジネス能力を一つの公共システムに統一して、重複を減らし、統一的な口径を実現しようとしました。しかし、このやり方はしばしば新しい単一障害点を生み出しました。本来独立して進化できるはずの複数のビジネスシステムが、一つのミドルウェア基盤機能によって結びつけられてしまったのです。一箇所の変更が全体に影響し、一箇所の障害が複数のビジネスラインを引き起こし、一箇所のルール変更がすべてのビジネスに適応を強いることになります。
AI時代には、複数の独立したアプリを作成・維持するコストが低下しています。複数のビジネスシナリオが一つの重いミドルウェア基盤を共有するよりも、それぞれが自律し、それぞれが進化し、それぞれが境界を負う方がよいのです。局所的自律の価値は、AIが小さなコンテキスト、小さな影響範囲、低い連鎖関係の中で独立して行動できることです。
三、明示的なロジックを誇りとし、暗黙のルールを恥とする
明示的なロジックとは、コードが必ずしも単純であることを意味するのではなく、ロジックのコンテキストが目の前に置かれていることを意味します。実際に批判されるべきは、設定ファイル、デコレータ、コールバック関数、ライフサイクル、依存性注入といった技術そのものではなく、それらが公開言語から逸脱した暗黙のルールを生み出すことです。
多くのシステムはコードを減らすために、ルールをフレームワーク、方言、業界用語、暗黙の了解、動的インジェクション、ライフサイクルフック、一目ではわからない用語の中に隠してきました。人間の熟練者は経験からこれらのルールを知っているかもしれませんが、AIは情報の壁に直面することになります。コードは見えても、実際に動作を決定するコンテキストが見えないからです。
かつて「規約は設定に勝る」が成立した前提は、その規約が十分に普遍的であり、人々の考え方さえ変えたということです。しかし、規約が単にチーム内部の業界用語、フレームワークのローカル方言、歴史的な遺産ルールに過ぎないならば、それはコード削減ではなく、理解のブラックボックスを作り出しているのです。AI時代においては、明示的な設定、明示的な判断、明示的なフローのコストが低下しました。情報を一箇所に集め、直接見えるようにすることは、ロジックを複数の注入可能な実装に分散して動的に読み込むよりも、しばしば価値があります。
四、特化した実装を誇りとし、汎用的な互換性を恥とする
ソフトウェアは本来、具体的な問題にサービスを提供するものです。しかし、かつてはコードを減らし、分岐を減らし、複数のパスを維持する手間を省くために、異なる要件、異なる入力、異なるビジネスシナリオを無理に一つの汎用的な互換レイヤーに吸収してきました。結果として表面上は統一されたものの、実際には問題そのものが歪められてしまいました。
汎用的な互換レイヤーの最大の危険性は、すべての具体的な問題に対して、まずそれが受け入れ可能な形に変形することを要求することです。その結果、具体的なビジネスは原型を失い、専用の能力は弱められ、システムは現実の問題ではなく抽象レイヤーを中心に回るようになります。
AI時代においては、使い捨てコード、グルーコード、小さなスクリプト、特化した実装を作成するコストが大幅に低下しました。少しのコードを減らすために、具体的なタスクを汎用フレームワークに無理やり押し込む必要はもうありません。多くの場合、現在のタスクに直接対応した実装の方が、さまざまな可能性に対応する抽象レイヤーよりも明確で、コストも低く、AIが操作するのにも適しています。
五、クローズドループでの検証を誇りとし、人手による対応を恥とする
クローズドループでの検証は、CI/CDに留まるべきではありません。従来のCIはビルド、テスト、リリースチェックを実行できますが、これがAI時代の完全なクローズドループではありません。AIが本当に必要とするのは「センサー」です。つまり、目を持ち、オンラインの状態を見え、システムの変化を感じ取り、可観測性の指標に基づいて自身の行動結果を判断できることです。
もしAIがコードコミット前のテストしか実行できず、リリース後のオンライン指標、ユーザー行動、レイテンシ変化、エラー率、リソース消費、ビジネスファネル、異常アラートを見ることができなければ、それは依然として盲目です。人間がどこが壊れたかを伝えるのを待つことしかできず、人手による対応に依存し続けることになります。
したがって、クローズドループ検証の核心は、検証ルールを増やし続けることではなく、システムがより多くの次元の情報を観測できるようにすることです。AIは「テストが通ったか」だけでなく、「リリース後にシステムが健全かどうか」も知る必要があります。人間は正しさとリスクの境界を定義し、機械は継続的な観測、継続的な検証、継続的なフィードバックを担当します。
六、制御可能な権限委譲を誇りとし、過度なリスク回避を恥とする
多くのチームはAIが破壊行為を行うのを恐れて、AIには提案の作成、ドキュメントの書き込み、コードスニペットの生成だけをさせ、実際にシステムを操作させることをしません。しかし、これではスケールしません。AIが実行権限を決して得られなければ、永遠にアドバイザーに過ぎず、エンジニアリング自動化の主体にはなれません。
正しいアプローチは、AIが実際のシステムを操作するのを拒否することではなく、まずAIがすべてに対して操作できると仮定することです：コード、データ、デプロイ、クラウドリソース、設定、監視、ロールバック。その上で、権限境界、監査、ドライラン、サンドボックス、承認ゲート、ロールバック機構、リスク分離を追加します。
制御可能な権限委譲の要点は、AIに本当の実行力を与えつつ、すべての動作が制御可能な範囲内にあることです。過度なリスク回避の結果は、人間が手動でコマンドをコピーし、手動でコンソールを操作し、手動で問題を調査し続けることであり、エンジニアリング自動化は真に拡大しません。
七、並行反復を誇りとし、単一ラインでの推進を恥とする
AI時代のソフトウェア進化は、もはや一人または単一ラインのエンジニアリング作業として理解されるべきではなく、最適化器（optimizer）やソルバー（solver）の求解プロセスとして理解されるべきです。同じ問題に対して、AIは同時に複数の候補解決策を提案できます：局所的な修正、モジュールのリファクタリング、ライブラリの置き換え、パスの書き換え、パフォーマンスの最適化。
従来のエンジニアリングは人的リソースに制約され、一度に一つの道しか試せませんでした。失敗したら戻って、次の道を再び進む。AIはこれを変えました。並行的に生成し、並行的にデプロイし、並行的に検証し、並行的に比較することで、ソフトウェア進化を線形推進から多経路探索に変えることができます。
もちろん、機械による評価は常に信頼できるとは限りません。ソフトウェアの良し悪しはしばしば微分不可能で、原因特定が難しく、即座に判断できません。しかし、並行反復の価値は、機械が自動的に絶対最適解を見つけ出すことではなく、探索空間を拡大し、より多くの候補経路を実行可能で比較可能で検証可能にすることにあります。
八、リファクタリングによる打開を誇りとし、パッチでの安易な妥協を恥とする
かつて多くのエンジニアリング規律では最小限の変更が要求されました。なぜなら、人間がコードを書くコストが高く、リファクタリングのコストが高く、検証コストが高かったからです。最小限の変更はかつてリスクを低減する方法でした。しかし、AI時代においても、AIに対して常に最小限の変更を要求し続ければ、AIはパッチマシンに格下げされてしまいます。
多くのシステムの問題は特定の一行のコードにあるのではなく、構造がすでに行き詰まりに陥っていることにあります：ハーネスがますます重くなり、検証がますます硬直化し、リファクタリングのコストがますます大きくなり、少し大きな変更でもプロセスによって却下される。システムは表面上安全でも、実際には反復不可能になっています。ソフトウェア改良が機能しなくなり、慢性的な死を迎えるか、またはチームが一斉に書き直すのを待つしかありません。
AI時代においては、コード作成コストが低下し、かつて人間にとって面倒で割に合わなかったリファクタリング作業が再び可能になりました。AIを最小限のパッチに閉じ込めるべきではなく、クローズドループ検証の保護下で、構造的な打開を許すべきです。境界を再定義すべきときは再定義し、古い経路を削除すべきときは削除し、リファクタリングすべきときはリファクタリングする。パッチ自体は恥ずべきことではありませんが、システムがすでに行き詰まりに陥った後でもなおパッチを当て続けることは、安易な妥協です。
結び：ソフトウェアをAIが操作可能で検証可能で進化可能な対象に
AI時代のソフトウェア工学は、AIに古いパラダイムのコードをより速く書かせることではなく、ソフトウェア自体を再設計してAIが操作しやすくすることです。新しいソフトウェアシステムは、より局所的で、より明示的で、より特化され、より可観測的であるべきであり、またAIに実際の実行権限を与え、並行的な探索と構造的なリファクタリングを可能にするべきです。
かつて多くのバッドアーキテクチャは、エンジニアが理解していなかったからではなく、古いコスト構造のもとでの合理的な妥協でした。フルスタック同一化、一つのデータベースで何でも済ませる、汎用フレームワーク、ミドルウェア基盤への依存、人手による対応、最小限の変更——これらはすべてかつて人件費を節約するのに役立ちました。しかし、AIがコード作成、理解、実行、検証のコストを変えた今、これらの古い妥協はもはや当然の合理性を持ちません。
AI時代のソフトウェア工学の核心目標は、ソフトウェアを人手で維持する静的な資産から、AIが操作可能で、観測可能で、検証可能で、権限委譲可能で、並行探索可能で、リファクタリングによって打開可能な動的システムに変えることです。
これこそが、八つの栄光と恥辱の背後にある共通の判断です： AIを単なる古いソフトウェア工学の加速装置にするのではなく、ソフトウェア工学そのものをAIのために再編成すること。
