あなたのプロダクトの「アーキテクチャ図」、最後に更新されたのはいつですか？
「うちはちゃんと描いてあるから大丈夫」と思っているマネージャーの方に、ちょっとだけ立ち止まって読んでほしい話があります。
私はエンジニアリングの現場で長年、設計と実装の間にあるギャップを見てきました。
そして最近、AIによるコード生成が当たり前になってきて、このギャップが「危険な領域」に入りつつあると感じています。
そもそも、アーキテクチャ図って何のためにあるの？
まずは原点から確認させてください。
アーキテクチャ図とは、システムの「設計意図」を見えるかたちにして、チーム全体で共有するためのものです。
設計の初期から、障害対応、新人の受け入れ、経営層への説明までエンジニアリングのあらゆる局面で「共通言語」として機能するはずのもの。
・・・ところが現実は、そうなっていない。
図はあるのに、誰も見ていない問題
次に数字を見てみましょう。
2025年に公表された世界調査「IcePanel State of Software Architecture Report 2025」によると、58%のアーキテクチャ図が現実のシステムと乖離しているそうです。
半分以上！
さらに別のUKでの調査では、ドキュメントを完全に最新状態に保てている組織は43%しかない。
87%のチームが何らかのダイアグラムツールを使っている、にもかかわらず。
つまり、「図は描いている。ツールも入っている。でも、実態とは合っていない」という状態が、世界中で当たり前になっている。
（うちは違う、と言い切れる方はどれくらいいるでしょうか）
何がおかしいの？
原因はおおまかに3つあります。
①コード変更とドキュメントが別々のワークフローにある
エンジニアはGitでコードを書く。図はConfluenceや別のツールにある。両者がつながっていないので、コードを直しても図は直されない。当たり前といえば当たり前。
②締め切りプレッシャー
リリース直前に「図も更新しといて」と言われても、現場は機能を間に合わせるので精一杯。「あとで直そう」がそのまま放置される。
③書き方の基準がチームごとにバラバラ
Aチームの図とBチームの図でレベル感も記法もバラバラ。結果、「何を見ればいいかわからない図」が量産される。
これらは個人のサボりではなく、構造的な問題です。
2026年、AIが新しい乖離を生む
2026年、エンジニアの多くがAIにコードを書かせている、あるいは修正させている。これは生産性的には素晴らしいことです。
ただ、副作用があります。AIに「この機能を追加して」と頼むと 、AIは「目の前のコード」しか見ない。
つまり、システム全体の設計意図（境界、依存の方向、責務の分離など）を必ずしも考慮しない。
（ちゃんとプロンプトで確認する指示を出しているから大丈夫、と思ったあなた、自分やチーム間のコードレビューなどはどのくらい機能していますか？コンテキストウィンドウにも限界があります）
その結果、何が起きるか。
知らないうちに、本来分かれていたはずのモジュールがくっついていく。
bounded contextが崩れる。
singletonパターンが意図せず増殖する。
データの分離ルールが、しれっと破られる。
そして気づいたときには、密結合でテスト困難で、アーキテクチャ図とは異なっていて誰も全体を把握していないシステムが出来上がっている。
これは怠慢ではなく、AI時代の構造的リスクです。
設計判断は人間がやらないとダメ
過去に私自身が研修を受けたことのあるDavidさんのブログに、こういう一節があります。
「ボトルネックが移動している。もはや『これを実装できるか』ではなく『何を構築しているのか理解しているか』へ」
そして、
「設計とは決定と責任の配置である」
「ここは分けるべきか、まとめるべきか」「この責務はどこに置くべきか」「このデータは誰が持つべきか」という設計判断は、依然として人間がやらないといけない。
AIは「速い実装者」ではあっても、「責任を取る設計者」ではない。
そしてここが特に組織のマネジメントの方に一番伝えたいところです。
「図があるから安心」は、もう通用しない
アーキテクチャ図は、システムの「設計意図」を表しています。ビルでいえば設計図、人体でいえば骨格図のようなもの。
この図はあくまで「こうあってほしい姿」であって、「実際の現状」ではない。
リフォームが進んでいるのに、最初の設計図しか手元にない、みたいな話です。
マネージャーの方が「うちは図がしっかりしているから設計は守られている」と思うのは、リフォーム後の家の状態を、新築時の図面だけで判断するようなもの。
そして、AIが施工を担当している今、リフォームのスピードはとんでもなく速い。図と現実の乖離は、これまでよりはるかに早く広がる。
これはもう、根本的に考え方を変える必要がある。
じゃあ、どうしたらいいの？
「図をもっとマメに更新しよう」では、もはや解決しません。
私は、ハーネスエンジニアリングのような考え方が大事だと思っています。ハーネス、は「安全帯」みたいなイメージです。ガードレールの方がしっくりくる方もよく見かけます。
人間が落ちないように、最初から仕組みでガードしておく。
アーキテクチャの前提（境界、依存方向、データ分離ルールなど）を、テストや静的解析として開発ワークフロー自体に組み込む。
たとえば「モジュールAはモジュールBに直接依存してはならない」というルールがあるなら、それをCIで自動チェックできるレベルの状態にする。
違反したらマージできないようにする。
そうすれば、AIがどれだけ速くコードを書こうが、設計の前提を壊すことはできない。
「図を更新する文化」を頑張るのではなく、「図の前提をコードが壊せない仕組み」を作る。
このような考え方が、AI時代における持続可能なプロダクト開発の大前提になると考えております。
（図を硬直化させたいわけではないので、更新頻度を定めるなど、運用面も人間がコントロールする必要があります）
ドキュメント自動生成だけでは足りない
2025年の同じ調査では、60%の開発者が「AIによるドキュメント自動生成が最もインパクトが大きい」と期待しているそうです。
これは確かに有望です。コードから図を自動生成できれば、乖離問題はかなり緩和されますし、一人一人が共通のルールで運用していくことで非常に強力な効果が得られます。
Git上のコメントなどもルール化することで必要な情報が残しやすくなりました。
でも、それだけでは不十分です。なぜなら、自動生成された図は「現状を映す鏡」にすぎないから。
「あるべき姿」を示してはくれない。
本当に必要なのは、
- コードから図を生成する仕組み（現状の可視化）
- 図の意図からコードを検証する仕組み（規律の維持）
前者だけだと「現状確認」です。後者があってはじめて、「設計意図が守られている」と言えます。
おわりに
エンジニアもマネジメントも、技術の細部に踏み込み続けるのは大変だと思います。でも、「アーキテクチャ図がある＝設計が守られている」という思い込みだけは、ぜひ手放してほしいです。
代わりに、現場でこう聞いてみてください。
「うちのアーキテクチャって、自動でチェックされる仕組みになってる？」
設計の判断と責任は、どこまでいっても人間のもの。
AIはそれを助ける素晴らしいパートナーだけれど、丸投げしていい相手ではない。
技術が変わるたびに、私たちはまた新しい責任の引き受け方を学ぶ。
大変ですが、より現場と経営が近づくきっかけとなると私は信じています。
最後まで読んでくれて、本当にありがとうございました。明日からの会話のきっかけになれば嬉しいです。
※本記事の統計データは2025年時点の調査に基づきます。最新情報はご自身でご確認ください。
参考文献
IcePanel「State of Software Architecture Report 2025」https://icepanel.io/blog/2026-01-21-state-of-software-architecture-survey-2025
IcePanel「State of Software Architecture Report 2024」https://icepanel.io/blog/2024-11-26-State-of-software-architecture-2024
Living in Software「Why architecture diagrams are never up-to-date?」https://livinginsoftware.substack.com/p/why-are-architecture-diagrams-never
DEV Community「The Real Reason Architecture Diagrams Go Stale」https://dev.to/erajasekar/the-real-reason-architecture-diagrams-go-stale-35ok
iSAQB「Agile Software Architecture: Why Plans Always Change」https://www.isaqb.org/blog/agile-software-architecture-from-idea-to-system-but-never-quite-as-planned/
David氏のブログ「Why AI Exposes Our Weakest Design Skills」https://passprog.com/why-ai-exposes-our-weakest-design-skills/