本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「アプリケーションアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰する記事です。
モノリスかマイクロサービスかを論じる前に、アプリ内部のコードが統一された書き方になっていないと、どんな全体構造も絵に描いた餅になります。本記事ではソフトウェアアーキテクチャとの違い、クラス設計・命名・ドメインロジック・エラーハンドリングなど内部構造の決めごとの全体像と、「チーム全員が同じコードを書けるようにする」という目的を示します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『アプリケーションアーキテクチャ設計パターン』・『アーキテクトの教科書』も参考にしてみてください。
そもそもアプリケーションアーキテクチャとは何か
チーム料理を想像してください。5人のシェフが同じ厨房で働くとき、「包丁はここに置く」「塩加減はこの基準」「盛り付けはこの順番」というルールがないと、料理のたびに味も仕上がりもバラバラになります。
アプリケーションアーキテクチャはチーム全員が同じコードの書き方で開発できるようにする内部の約束事です。クラス設計・命名規則・ドメインロジックの置き場所・エラーハンドリングの方針など、コードの「品質基準」を揃えます。
もしアプリケーションアーキテクチャがなければ、メンバーごとに書き方がバラバラになり、レビューのたびに「この書き方でいいの？」が再燃して生産性が落ち続けます。
「コードをどう書くか」の約束事
ソフトウェアアーキテクチャの一部として語られることもありますが、そちらに含めてしまうと粒度のバランスが取れなくなるため、別のアーキテクチャとして分離しておく方が望ましいです。ソフトウェアアーキテクチャで決めた設計方針に大きく影響を受けるため、検討する際は必ず整合性を取ることが重要です。
アプリケーションアーキテクチャが手薄なプロジェクトは、コードの書き方がチーム内で散らかり、レビューのたびに「この書き方いいの？」の議論が再燃します。地味な規約の徹底が、日々の生産性と長期の保守性を静かに支えているのが実情です。
ソフトウェアとアプリケーションの違い
言葉が似ているため混同されがちですが、ソフトウェアアーキテクチャとアプリケーションアーキテクチャは「対象の粒度が根本的に異なる」設計です。ソフトウェアアーキテクチャはアプリ全体の骨格、つまりモノリスかマイクロサービスか、使用言語、API設計、データベースの選定といった外側の枠組みを決める領域。一方アプリケーションアーキテクチャは、その枠組みの中で実際にコードをどう書くか、つまりクラス分割、命名規則、ドメインロジックの表現方法といった内側の約束事を決めます。
両者を区別する理由は、意思決定の責任者と変更のコストが大きく違うからです。ソフトウェアアーキテクチャは一度決めると後戻りが難しいOne-way Doorの判断が多く、アーキテクトが要件定義フェーズでじっくり決めます。アプリケーションアーキテクチャは実装フェーズで確定し、テックリードやリードエンジニアが主導する、比較的やり直しの効くTwo-way Doorの判断です。
| 観点 | ソフトウェアアーキテクチャ | アプリケーションアーキテクチャ |
|---|---|---|
| 粒度 | アプリの外部構造 | アプリの内部構造 |
| 例 | モノリス / マイクロサービス / 言語 / API設計 | クラス設計 / 命名規則 / ドメインロジック |
| 決定時期 | プロジェクト計画〜要件定義 | 設計〜実装フェーズで確定 |
| 変更容易性 | 変更が極めて困難（One-way Door） | 比較的変更しやすい（Two-way Door） |
家で例えるなら、ソフトウェアアーキテクチャは間取り図（何LDKか、玄関はどこか、水回りは一箇所にまとめるか）、アプリケーションアーキテクチャは「各部屋の家具配置・コンセントの位置・壁紙の柄」にあたります。間取りを変えるには壁を壊す大工事が必要ですが、家具は比較的動かしやすい。そのぶん日々の暮らしやすさは家具配置で決まる、という関係です。
なぜ分けて考えるのか
両者を混ぜて考えると、議論の抽象度が常にバラつき、会議が噛み合わなくなります。「マイクロサービスにすべきか」という大枠の話をしているのに「その中のクラスはどう分けるのか」が割り込んできたり、逆に命名規則を決める場で「そもそも言語の選定が……」と話が戻ったり。「決定の粒度を揃える」ことは、設計議論を前に進めるための前提条件です。
キャリア初期のエンジニアがつまずきやすいのもまさにこの部分で、「クラス設計を頑張ればアーキテクチャが良くなる」と思い込みがちです。ところが実際には、マイクロサービス化やデータベース分離といった外側の判断を間違えていると、どれだけクラスを綺麗に書いても挽回できません。逆にアーキテクトが外側だけ決めて内側を放置すると、チームごとに書き方がバラついて保守不能になります。両レイヤーを別物として並走させる発想が出発点です。
- ソフトウェア側が細かい実装ルールに引っ張られて大枠設計がブレる
- アプリケーション側が曖昧なまま開発が進み、チーム毎に実装がバラつく
「アーキテクト」と「リードエンジニア / テックリード」で責任を分担し、それぞれが違うレイヤーの決定を担うのが健全です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
内部構造・ドメイン設計
| 項目 | 選択肢の例 |
|---|---|
| クラス構成 | 単一責任・継承・委譲・ミックスイン |
| ドメインロジック | 手続き型（トランザクションスクリプト）・リッチドメイン（DDD） |
| エラーハンドリングポリシー | 例外・Result型・エラー境界の設計 |
| 命名規則と概念モデル | ユビキタス言語・用語集の整備 |
| コード規約 | フォーマッタ・リンター・レビュー方針 |
コード構成・テスト・観測
| 項目 | 選択肢の例 |
|---|---|
| ディレクトリ構成 | 機能別（feature-based）/ レイヤ別（layered） |
| 依存関係の方向 | 循環禁止 / クリーンアーキテクチャ |
| テスト戦略 | ユニット / 統合 / E2E のバランス |
| バリデーション設計 | どの層で行うか・再利用方法 |
| ロギング・監査 | ログ粒度・相関ID・PIIのマスキング |
ケース別の選定
プロジェクトの性質によって、アプリケーションアーキテクチャでどこに力を入れるかは大きく変わります。全方位に厳密な設計を施すと過剰設計になり、逆に放置すると保守性が一気に崩れるため、状況に応じて投資配分を変えます。
| ケース | 重点を置くべき領域 |
|---|---|
| 新規CRUD中心アプリ | 命名規則とLinter/Formatterの徹底。ドメインロジックは手続き型で十分 |
| 複雑な業務ロジック（保険・金融・会計） | ドメインモデルを厚く設計（DDD）。業務用語との一致（ユビキタス言語）を優先 |
| 複数チームのマイクロサービス | ディレクトリ構成・API契約・エラー規約をチーム横断で統一 |
| レガシー改修プロジェクト | 既存の命名・構成を尊重しつつ、新規追加部分だけ段階的に規約を適用 |
新規CRUDアプリにDDDを持ち込むのは典型的な過剰設計で、シンプルな手続き型で書いた方が保守性が高くなります。一方で業務ロジックが複雑なドメインでは、手続き型だと条件分岐が爆発してメンテ不能になるため、ドメインモデルへの投資が効きます。レガシー改修は「既存流儀への敬意」が最優先で、新しい規約を一気に全面適用するのは失敗パターンです。
ドメインロジックの2大方針
| 方針 | 特徴 | 向くケース |
|---|---|---|
| 手続き型（Transaction Script） | 処理の流れをそのまま関数化。DDDより単純 | 小規模 / CRUD中心 / 短期プロジェクト |
| リッチドメイン（DDD） | ビジネスロジックをドメインオブジェクト内に凝集 | 大規模 / 複雑な業務ロジック / 長期運用 |
「小さく始めて、複雑化したらリッチドメインに移行」という段階的な設計変更も一般的。過剰設計を避けるため、最初からDDDありきで始めないのが健全です。
クリーンアーキテクチャの考え方
「依存の方向を内側に向ける」ことで、外側（DB・UI・FW）の変更がビジネスロジックに波及しないようにする設計原則です。
規模×業務複雑度の段階表
アプリケーションアーキテクチャはコードベース規模と業務複雑度で必要な投資が変わります。ざっくり結論だけ先に言うと、1万行までは素のレイヤードで十分、5万行を超えたらヘキサゴナル、20万行級の金融・保険系で初めて本格DDD。このパスが2026年時点で最もROIが合います。
| コードベース規模 | 業務複雑度 | 推奨パターン | ドメイン表現 | ファイル行数目安 |
|---|---|---|---|---|
| 〜1万行 | CRUD中心 | レイヤード / 素のMVC | Transaction Script | 〜300行 |
| 〜5万行 | 中程度 | レイヤード or ヘキサゴナル | TS + Value Object | 〜300行 |
| 〜20万行 | 複雑（EC・物流） | ヘキサゴナル / クリーン | Domain Model（DDD軽量版） | 〜300行 |
| 20万行〜 | 極めて複雑（金融・保険） | クリーン + 戦術的DDD | 本格DDD（Aggregate等） | 〜300行 |
「1ファイル300行・1メソッド50行・循環的複雑度10」が多くのプロジェクトで採用される定量ガードレールです。これを超えたら分割の合図で、ESLint・SonarQube で自動検出するのが現代流。「新規CRUD画面にクリーン4層を適用」するのが典型的過剰設計です。
パターンは規模に合わせて段階的に昇格します。MVPにDDDは過剰、巨大プロジェクトで手続き型は破綻します。
このカテゴリの知識構造
このカテゴリは全5記事で構成されています。設計原則から具体的なルールへと段階的に降りていく構造です。
設計の骨格であるクラス設計とドメインロジックの方針を先に決めると、命名やエラー処理のルールが自然に導かれます。たとえばDDDを採用するならユビキタス言語が前提になり、手続き型ならシンプルなエラーコード返却で十分かもしれません。逆に命名規則を先に細かく決めても、設計方針が変わればルールごと作り直しになります。
このカテゴリは他カテゴリと比べて変更コストが低い（Two-way Door）ですが、チーム全員が毎日触れる領域なので、放置すると生産性への影響が最も大きくなります。
やってはいけないこと
各論記事で触れた禁じ手のうち、内部構造レベルで押さえるべき核心を整理します。
| 禁じ手 | なぜダメか |
|---|---|
| 神クラス・God Module を育てる | 「ついでにここに」の積み重ねで3000行級、分割は実質書き直し |
| 貧血ドメインモデル | DDDの形だけ真似、ロジックが全部Service層 |
| 循環依存を放置 | A→B→Aの依存は必ずバグの温床、ESLintで検出 |
Util / Manager / Helper と命名 | 責任を語らない名前、責任が明確なら具体名 |
| 継承4段以上の深いツリー | LSP違反・変更の波及・理解困難 |
エラーを握り潰す（catch { }） | サイレント障害の温床、本番で原因不明 |
| 命名規則をチームごとにバラバラ | User / Member / Account / Customer 問題 |
| リトライに冪等性なし | 二重決済・二重登録の定番、Idempotency-Key 必須 |
| コメントにWHAT（何を）を書く | コードで分かることを書くな、WHYを書く |
| Linter / Formatter をCIで強制せずREADME記載 | 守られない規約は存在しないのと同じ |
| アプリケーション設計＝クラス図と思い込む | クラス図は成果物の一部、命名規則・エラー方針・テスト戦略といった地味な規約の方が日々の生産性を左右する |
| 例外処理を後から追加する | エラー設計は後付けでは必ず漏れる、クラス設計と同時に決めるべき一次判断 |
アプリケーションアーキテクチャは規約の徹底で決まります。ツールで機械的に強制するのが唯一の解です。
AI判断軸
| AI時代に有利 | AI時代に不利 |
|---|---|
| 厳格な型・スキーマ・インターフェース定義 | 動的型付け・暗黙の規約 |
| 統一されたディレクトリ構成・命名規則 | チームごとの暗黙のスタイル |
| 純粋関数・副作用の分離（Hexagonal等） | 副作用の多い手続き型コード |
| 単一責任の小さなクラス・関数 | 巨大な神クラス・長い関数 |
選定の優先順位をまとめると次の通りです。
- ソフトウェアアーキテクチャと整合させる（大枠の制約を守る）
- 一貫性を最優先にする（思想より規約徹底）
- 小さく始めて必要なら強化（DDDありきは過剰設計）
- 型・規約・構成をコードで明示（AI時代の必須条件）
型と規約の明示がAIの生成品質を決める
アプリケーション設計で型（TypeScript・Zod・Protocol Buffers）と規約（ディレクトリ構造・命名ルール・エラーハンドリング方針）がコードで明示されていれば、AIはそれに従った一貫性のあるコードを生成します。逆に規約が口頭合意やConfluenceにしかない場合、AIは毎回異なるスタイルのコードを出し、レビューコストが増大します。
小さなモジュールはAIのコンテキストに収まる
アプリケーション設計を「1ファイル1責務・300行以内」のモジュール粒度で設計しておくと、AIに修正を依頼する際にモジュール単位でコンテキストを渡せます。巨大なクラスや複数責務を持つファイルではAIが全体像を把握できず、意図しない副作用のあるコードを生成しがちです。
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「アプリケーションアーキテクチャ」カテゴリの入口として、内部構造の規約をどう決めるかの全体像を解説しました。如何だったでしょうか。
思想の選択より規約の徹底、過剰設計より段階的成長、人間のためだけでなくAIへの制約として設計する。これがアプリケーションアーキテクチャの3つの核です。
次回からはこの領域の各論に入り、まずクラス設計（SOLID原則・継承vs委譲）から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS アーキテクチャセンター も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（25/89）