AI後のソフトウェアアーキテクチャ

ソフトウェアアーキテクチャの定義は長年にわたり捉えどころのないものでしたが、『進化するアーキテクチャ構築』という書籍で提示された定義は鋭い洞察を提供しています。すなわち、アーキテクチャとは本質的に「変更が難しいもの」です。この定義は最も正直でシンプルであり、ある決定が「アーキテクチャ上の」ものと見なされるのは、その概念的な重みではなく、それを元に戻すコストとビジネスへの影響によるものであることを認めています。そして「変更が難しい」とは、根本的には壁時計の時間に関わる問題であり、調整コスト、インシデント軽減、認知的負荷、引き継ぎの摩擦などを含みます。ソフトウェアアーキテクチャは常に、設計問題に偽装された労働問題でした。

現在、AIはコードレベルの大規模な変更に必要な壁時計の時間を劇的に圧縮しています。かつて数ヶ月かかっていたことが数日で可能になります。コードレベルのほとんどの決定を元に戻すコストが一桁減少すると、アーキテクチャはどうなるでしょうか？

答えは、アーキテクチャの境界が移動するということです。場合によっては劇的に。ほとんどのコードレベルの決定はもはやアーキテクチャの内部にはありません。それらを元に戻すコストは低下し、誤った決定の結果は数ヶ月ではなく数日の手直しで済みます。依然として内部にあるのは、データ、サービス境界、ユーザーの信頼です。これらは、困難な部分が決してコード自体ではなかったため、変更が難しいままです。そして、コードレベルの議論に埋もれていたいくつかの関心事が、より明確に浮かび上がります。特に可観測性は、機能提供の速度が上がるにつれて再考に値します。

何十年もの間、コードレベルの決定は確かにアーキテクチャ上のものでした。言語、フレームワーク、モジュール構造、永続化戦略は、議論し、コミットする価値のある決定であり、それらを再検討するには莫大な時間がかかり、チームの生産性に長期的な影響を与えました。これらを変更するには数ヶ月から数年かかる可能性があり、企業はその時間の中で生き残ったり死んだりしました。リファクタリングでさえ、コードレベルの変更は可能だがコストがかかるという前提に基づいていました。

しかし、ソフトウェア実践者は何十年にもわたってアーキテクチャ上の決定を日常的な決定に格下げしてきました。痛みに直面する（避けない）効果は、チームがそれに対処するツールを構築する動機を与え、かつてアーキテクチャだったものを一般エンジニアが当然のように扱うものに変えることです。

データベースマイグレーションが一般的になる前は、スキーマの決定は不可逆的で、アーキテクチャ上のものと見なされ、多くの場合DBAが調整する必要がありました。その後、Pramodが『進化的データベース設計』を執筆し、マイグレーションが主要フレームワークに組み込まれ、DBAの役割は目立たなくなり始めました。彼らの判断と専門知識は本物で重要でしたが、その市場価値は機械的なボトルネックによって膨らんでいました。ボトルネックが取り除かれると、専任のゲートのコストがより明確になり、判断は一般のエンジニアリング役割に吸収され、多くのチームにより大きなレバレッジをもたらしました。継続的デリバリーは、デプロイメントとリリースエンジニアに対しても同じことを行いました。ツール効率の小さなシフトはそれぞれ、かつて専門家を必要とした決定のカテゴリーを機械的なものに変え、専門化された判断はしばしば機械的コストに閉じ込められた一般的なエンジニアリングスキルであることを明らかにしました。

AIはこの傾向の最新の例ですが、最も劇的です。なぜなら、一度に一つではなく、残りのコードレベルの決定のほとんどを一度に圧縮するからです。最近の個人的な例：私は（現在は消滅した）スタートアップで、同じくスタートアップだったベンダーのNoSQLデータベースを使用していましたが、そのベンダーも（驚くことではありませんが）倒産しました。Claude Codeをそれに向け、いくつかのガイダンスを与えたところ、数時間でデータレイヤー全体を従来のRDBMSにほぼ完璧に移植しました。この種のことが一般的になったことは知っていますが、それでも驚きました。その作業の単調さと本業の間で、私は宇宙の熱的死までにそれを成し遂げられなかったかもしれません。

これは孤立した例ではありません。Cloudflareのチームは、約1,100ドルのAPIコストで、1週間足らずでNext.jsのAPIサーフェスの94％を再実装しました。Christopher Chedeauは、1ヶ月で10万行のTypeScriptをRustに移植しました。読者の多くも同様の変化を経験しているでしょう。

ある意味で、これらの例は良い構造が重要であるというルールを証明しています。私はクリーンなインターフェース境界に対してデータレイヤーを構築していました。昨日コーディングを始めたわけではないので、実装の交換が簡単だったのはある意味当然です。しかし、クリーンな境界がなくても、変更は基本的に機械的です。すべての呼び出し箇所を見つけ、すべての実装を変更し、正確性を検証するだけです。より多くのトークン、より多くの時間、そしてより多くの人間の介入が必要ですが、大きな違いはありません。おそらく数時間から数日程度です。そしてエージェント開発の二次的な効果として、その上に検証を自動化でき、正確性チェックをプロセス自体に組み込むことができます。

これらの例は明らかに簡単なケースに偏っています。クリーンなインターフェース、明確に定義された境界、機械的に検証可能な正確性です。微妙なセマンティクス、不明確な境界、深く絡み合ったビジネスロジックを持つシステムは、AIがあっても変更が困難です。しかし、トレンドラインは重要です。AIは結合度、移行リスク、ロールアウトの複雑さを消すわけではありませんが、かつて永続的に感じられた多くのコード形成の決定を格下げし、残りの決定を劇的に監視および修正しやすくします。これにより、ますます多くの変更のカテゴリーが「もはやアーキテクチャではない」領域に位置付けられます。

コードがアーキテクチャの境界外に移動したなら、何がまだ内部にあるのでしょうか？ソフトウェアアーキテクチャの包括的な分類を作成することは定義上馬鹿げていますが、以下に6つのカテゴリーを挙げ、2つの軸（決定を誤った場合の結果と元に戻すコスト）に沿って分類してみます。これは直感に基づくものであり、ハードデータではありません。

決定 | ステータス | 理由 ローカルコード構造 | ↓格下げ | モジュール、フレームワーク、永続化、統合配線。AIは機械的な再構築を安価にし、間違えても今は数時間のコスト。 スケーラビリティとデプロイメント姿勢 | ↓格下げ | インフラストラクチャトポロジーとパフォーマンス戦略。通常のコードよりは難しいが、AI支援ツールで日常的なエンジニアリングの範囲内。 データアーキテクチャ | →依然としてアーキテクチャ | 所有権、一貫性、スキーマ進化。データには重力がある。困難な部分はコードではなく、実質的に変わっていない。 信頼とサービス境界 | →依然としてアーキテクチャ | セキュリティ姿勢とダウンストリームコンシューマーが依存する契約。違反は事実上不可逆。契約は組織を拘束する。 可観測性と動作検証 | ↑昇格 | コード量が増加し、理解力が低下。動作の検証は、読めなくなったものを捕捉する方法。 ビジネス戦略と能力の整合 | ↑昇格 | 常に結果が大きい。コードレベルの議論が安価になり、アーキテクチャは仕事が存在する目的に取り組む余裕ができた。

3つの動き、3つの異なる理由。

一部の決定は、AIが元に戻すコストを削減したために格下げされました。ローカルコード構造（モジュール、フレームワーク、永続化、統合配線）はかつて真剣なアーキテクチャ上の注意を必要としましたが、今はそうではありません。スケーラビリティとデプロイメント姿勢も同様です。これらの決定には依然として判断が必要ですが、その判断はもはや機械的コストに閉じ込められておらず、誤った判断の結果は時間とトークンで測定され、四半期や人員ではありません。

一部の決定は、困難な部分がコードではなかったために留まりました。データアーキテクチャ（所有権、一貫性モデル、スキーマ進化）は、データに重力があるため移動しませんでした。データは時間とともに質量を蓄積し、その現在の形状に依存するものは誰も列挙できません。信頼とサービス境界も移動しませんでした。セキュリティ違反と契約違反は事実上不可逆であり、それらを元に戻すには人間との調整、蓄積された状態の再形成、またはコード変更では到達できない現実世界の結果を取り消す必要があります。

2つの決定は、異なる理由で昇格しました。可観測性と動作検証は、コード量の増加により重要度が増しています。欠陥密度が一定でもコード量が5倍になれば、システムの実際の動作を検証できないことの結果は大きくなります。さらに、行レベルの理解が同様に崩壊する場合（ダークソフトウェア工場のように）、すべての行を理解しなくてもシステムが何をするかを検証できる必要があります。監視の実装は安価ですが、何を監視し、どのように動作の正確性を検証するかの決定はそうではありません。ビジネス戦略と能力の整合は、逆にチャート上ではまったく移動しませんでした。常に結果が大きく、戦略的な失敗を元に戻すことは常に高価でした。変わったのは、アーキテクチャがそれに取り組む余裕を得たことです。コードレベルの議論が安価になり、どの境界が競争優位性を生み出すかという問題が、フレームワークの議論に圧迫されなくなりました。

コード構造は、私がアーキテクチャと呼ぶものの執行メカニズムであると合理的に主張できます。良いモジュール境界はAPI契約の執行に役立ち、良い型システムはデータ不変条件の保護に役立ちます。コード構造を気にしなくなれば、気にかけている契約を危険にさらすことになりませんか？これは決定とその実装を混同していると思います。契約の形状とその保証が困難な部分であり、それらを変更するには人間との調整が必要なため実際の時間がかかります。それらを執行するコードは実装であり、実装は今や安価です。契約自体に触れることなく執行メカニズムを交換できます。私のスタートアップの移行作業がまさにそれを行いました。

もう一つ関連する反論に取り組む価値があります。中間レベルの設計決定（「このビジネスロジックはサービスAとサービスBのどちらに置くべきか？」）は時間とともにシステムの全体的な可鍛性に蓄積され、それらの蓄積された決定は解きほぐすのが本当に困難です。これは事実ですが、常にそうでした。そもそも中央で制御することは決してできませんでした。チームは通常、ローカルの自律性とスループットを最適化するために、物をあるべきと思われる場所に置き、中央でどれだけ統治しようとしてもある程度のドリフトが生じます。変わったのは、コードベース検索インデックス（急速に標準装備になりつつある）に接続されたLLMが、実際にすべてを見つけ、なぜそうなったかを推論し、再編成を支援できることです。中間レベルの決定の蓄積された影響は、依然として重要でおそらくアーキテクチャ上ですが、AIによってより扱いやすくなっています。解きほぐすコストは低下しており、消えたわけではありません。

パターン増幅は運命ではありません。AIはコードの品質をより重要にする、という反論を聞くでしょう。それは良い決定も悪い決定も量で増幅するからです。ある程度は正しい。AIの出力はその入力とプロンプトに依存します。コードベースが混乱していれば、AIが生成するコードも混乱し、より高速になります。しかし、パターン増幅は運命ではありません。ターゲットを絞った制約プロンプト、契約強制、自動化ガバナンスを構築して、出力を事前にコードを完璧にすることなく導くことができます。マイクロサービスが中央ガバナンスなしに収束するローカル境界を統治できるように、AI生成コードも導くことができます。

結論として、AIはソフトウェアアーキテクチャの状況を根本的に変えています。アーキテクトの役割は、コードレベルの決定の守護者から、データ、信頼、可観測性、ビジネス整合に焦点を当てたシステムレベルの特性の戦略家へと変化しています。この変化に適応する者こそが、次世代のソフトウェアエンジニアリングを定義するでしょう。