【ITニュース解説】Architectural Debt is the New Technical Debt

システム開発の世界では、「テクニカル負債」という言葉をよく耳にするだろう。これは、急いで開発を進めたり、設計が不十分だったりするために、コードの品質が低下し、将来の修正や機能追加の際に余計な手間がかかる、といった問題を指す。しかし、最近ではこれとは異なる、より根本的な問題である「アーキテクチャ負債」が、開発現場で大きな課題となっている。

アーキテクチャ負債とは、システム全体の構造において、各機能やデータが「誰のものか」「どこに属するべきか」という境界線が曖昧であったり、そもそも存在しなかったりすることで発生するコストのことである。これは、システムの変更を行うたびに、その曖昧な境界をまたいでしまい、そのたびに余計な作業や、より深刻な問題を引き起こす可能性がある。

具体的な例を挙げてみよう。あるシステムで、注文ページに支払いステータスを表示する機能を追加する依頼があったと仮定する。開発者は、注文の情報を管理している部分（注文サービス）に、支払いステータスを格納するための項目を追加し、請求サービスから支払い情報の一部をコピーして表示するように実装したとする。この時点では、テストも問題なくパスし、機能は正しく動作するように見える。しかし、翌日になってその注文が払い戻された場合、問題が発生する。

このとき、支払いに関する「真実の状況」を管理しているのは、本来であれば請求サービスである。しかし、注文サービスにも支払いステータスが記録されてしまっているため、「真実の源泉（Single Source of Truth）」が二か所に存在することになる。もし、何らかの理由で請求サービスと注文サービスの支払いステータスが一致しなくなった場合、例えば、払い戻し済みにもかかわらず注文ページでは「支払い済み」と表示されるような状況が生まれかねない。この状況では、どちらのステータスが正しいのかを判断し、調整するための追加作業が必要になる。開発者が追加したコード自体はきれいに書かれていたとしても、「誰が支払い情報を所有するか」という根本的な設計判断が欠けていたために、このような問題が起こるのである。この、境界線が曖昧なことで生じる将来のコストがアーキテクチャ負債に他ならない。

最近のIT開発では、人工知能（AI）を活用したコード生成ツールが普及し、プログラムコードの記述や、既存のコードをきれいに修正する作業が格段に速くなった。例えば、特定の処理を行うためのコードや、テストコード、データベースの変更スクリプトなどをAIが瞬時に生成できるようになっている。これにより、開発者は以前よりも少ない労力で、高品質なコードを記述し、重複する部分を削除したり、定型的なコードを埋めたりすることが可能になった。

しかし、この技術の進歩は、「コードの限界費用（コードを書くこと自体にかかるコスト）が下がった」だけであり、「システム全体に変更を加えるコスト」が下がったわけではないという重要な点を見落としてはならない。たとえAIが瞬時にきれいなコードを生成できたとしても、そのコードがシステム全体に与える影響を評価し、データ移行計画を立て、本番環境にデプロイし、そして本番環境で予期せぬ問題が発生した際にサポートする、といった一連の作業は依然として人間の担当である。

AIは、コードの書き方や文法的な誤り（リンターエラー）を指摘したり、重複コードを見つけたりすることには長けている。しかし、「支払いステータスという情報が、注文サービスに属すべきなのか、それとも請求サービスに属すべきなのか」といった、システム全体の設計に関わる根本的な問いには答えることができない。AIによる高速なコード生成は、目の前の局所的なコードの品質を高めることには役立つが、システム全体の構造や、各機能の責任範囲といった「グローバルな設計」に関する問いへの注意を、むしろ分散させてしまう可能性があるのだ。これは、まるでAIが「目的の意図」を増幅させ、その結果をより早く引き起こすようなものであり、目に見えて壊れた機能としてではなく、もっともらしい「新たな真実の源泉」を生み出す形で影響が及ぶのである。

なぜ開発者は、このようなアーキテクチャ負債を抱えやすい「安易な道」を選んでしまうのだろうか。注文ページに支払いステータスを表示するよう依頼された開発者は、まず注文ページをレンダリングするコードを探すだろう。そして、最も手っ取り早い解決策は、現在処理している注文モデルを拡張することだと考えるかもしれない。特に悪意はなく、目の前のタスク、関連するコード、そしてテストの全てが、その場でタスクを完了させることに焦点を当てているためである。

しかし、これが問題の始まりとなる。その後、別の機能が「注文の支払いステータス」を参照して商品の出荷を決定したり、さらに別の機能がチャージバック（顧客による支払いの取り消し）後にそのステータスを更新したりするかもしれない。個々の変更は、それぞれのタチケット（作業依頼）の中では正当に見える。しかし、これらの変更が積み重なることで、当初は単なる表示目的のショートカットだったはずの「支払いステータス」が、いつの間にか「ドメインの重要なルール」へと変貌してしまう。結果として、注文サービスも請求サービスも、お互いに調整することなく、支払いステータスの状態モデルを変更することができなくなるのである。

このような失敗は、他にも様々な形で現れる。例えば、複数のサービスが共有するデータベースのテーブルが、本来意図されていないにもかかわらず、サービス間の非公式な連携APIとして機能してしまうケース。また、フロントエンド（ユーザーインターフェース）が、バックエンドで管理すべき認証ルールを独自に複製してしまうケース。あるいは、「一時的な」データ変換レイヤーが、いつの間にか二つのサービス間で顧客の識別方法が異なる際の矛盾を解消する場所になってしまうケースなどがある。AIによるコード生成は、これらの「罠」自体を作り出すわけではない。しかし、安易な道を選んでしまう行動を、調整コストが表面化する前に何度も繰り返せるほど高速にしてしまうのである。

このようなアーキテクチャ負債を防ぐためには、コードを生成する前に、まず「契約（コントラクト）」を明確に定義することが不可欠である。先の注文ページの例で言えば、まず最初に「支払いステータスは、請求サービスが所有する情報なのか、それとも注文サービスが所有する情報なのか？」という問いを立てる必要がある。もし請求サービスが所有する情報であると判断するならば、注文ページは請求サービスから提供される支払い状況のビューを要求するか、または請求サービスが「意図的に」定義した「プロジェクション（投影データ）」を利用するべきである。もし注文サービスがプロジェクションをキャッシュするとしても、その契約には、データの出典、更新メカニズム、障害時の挙動、そして許容される古さの程度を明記しなければならない。注文サービスが、支払いステータスに関して請求サービスとは独立した「新たな権威」になってしまうことは避けるべきである。

この判断は、開発者への指示内容を根本的に変える。単に「注文に支払いステータスを追加する」という依頼ではなく、「請求サービスが所有する支払いステータスを注文ページに表示すること。ただし、注文モデルに書き込み可能な支払いフィールドを追加しないこと。また、請求サービスが利用できない場合にページが何を表示するかを明確に指定すること」といった具体的な制約付きの依頼になる。このような制約は、レビューするには十分に小さく、テストするには十分に具体的である。例えば、意図しない書き込みや、請求サービスが利用できない場合の処理漏れを、契約テストで検出できる。しかし、どのドメインが情報を所有するかという決定自体は、テストだけではできない。

どのドメイン（システムの部分）にも言えることだが、その境界線に関する「契約」は、実際にコードを書く開発者（あるいはAIエージェント）が受け取る指示の中に盛り込むべきである。例えば、リポジトリ全体に適用されるルールとして「AGENTS.md」のようなファイルに、あるいは特定のコード範囲を対象とする「*.instructions.md」のようなファイルに記述する。そこには、「どの情報が誰に属し、状態遷移を誰が管理するのか」「他のドメインがどのようにその情報を読み取ってよいのか」「どのような書き込みや依存関係が禁止されているのか」「情報所有者が利用できない場合にどうなるのか」といったルールを明確に記すべきである。

コードを編集する前に、開発者やAIエージェントには、関連する情報所有者を特定させ、提案された変更がどのようにその境界を越えるのかを説明させるべきである。もし指示が不足していたり、既存のコードと矛盾していたり、あるいは新しい情報所有者や例外が必要な場合は、開発を一時停止し、ユーザー（人間）に判断を仰ぐべきである。目の前にある一番近いモデルを、勝手に情報を追加する許可だと解釈してはならない。

明確な指示は、システム内の境界線を開発者に可視化させる。そして、チェック機構を導入することで、境界違反のコードが本番環境に出荷されるのを難しくする。可能であれば、依存関係のルール、スキーマの所有権チェック、そして許可されたデータ交換とその障害パスに対する契約テストを追加すべきである。開発者やAIエージェントにはこれらのチェックを実行させ、そのカバレッジを報告させる。これらの自動チェックは、ドメインモデル自体が正しいことを証明するものではないため、最終的に新しい情報所有権や整合性のトレードオフを判断するのは依然として人間である。

これが「境界の守護者」の仕事である。すなわち、ある情報が誰に属するかを明確にし、許可されるデータ交換のルールを定義し、その違反が指示、テスト、API、そしてコードレビューにおいて明確に可視化されるようにすることである。目標は、全てのサービス間の依存関係を禁止することではない。それは、開発者（エージェント）が従うべき永続的な制約を与え、簡単に無視できないチェック機構を提供することで、次の変更が知らず知らずのうちに「二つ目の真実の源泉」を生み出さないようにすることである。

この考え方は、システム開発の計画段階にも当てはまる。実装が高速化した現代では、より多くの小さな機能を次々と開発キューに入れる誘惑に駆られがちである。しかし、ある機能が「小さい」と判断する前に、それが新しい情報所有者、新しいデータプロジェクション、あるいは新しい整合性ルールを追加するものではないかを注意深く確認する必要がある。たった一行のフィールド追加が、その機能の中で最もコストのかかる部分になる可能性もあるのだ。

AIによるコード生成は、一日のうちに私が完了できる作業量を大きく変えた。しかし、ある情報が「どこに属するべきか」という根本的な判断の必要性を取り除いたわけではない。もし私がその判断を怠れば、実装が速くなった分だけ、アーキテクチャ負債をより早く蓄積してしまうことになるだろう。