【テンプレあり】英語アーキテクチャ設計書の書き方｜ITプロジェクトで使える日英フォーマット付き

英語でアーキテクチャ設計書を書くよう求められたとき、何を書けばいいか迷った経験はないだろうか。

アーキテクチャ設計書はシステムの全体像・設計思想・技術選定の根拠を記録するドキュメントだ。グローバルチームでは英語が基本になるが、8つのセクション構成さえ押さえれば英語でも問題なく書ける。

この記事では、アーキテクチャ設計書に必要な8つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに実務で活用できる。

アーキテクチャ設計書に必要な8つの構成要素
1. なぜ英語で書くのか
2. ADR（アーキテクチャ決定記録）とは
テンプレートをダウンロード（Word）
日本語版テンプレート（コピペOK）
英語版テンプレート（コピペOK）
各セクションの書き方と例文
アーキテクチャ設計書でよく使う英語表現
まとめ：英語アーキテクチャ設計書は8つのセクションで完成する

アーキテクチャ設計書に必要な8つの構成要素

アーキテクチャ設計書は、システムの構造と設計判断を記録するドキュメントだ。以下の8つが標準的な構成要素になる。

基本情報（Document Info）
目的・スコープ（Purpose & Scope）
アーキテクチャ概要（Architecture Overview）
コンポーネント設計（Component Design）
データ設計（Data Design）
セキュリティ設計（Security Design）
非機能要件（Non-Functional Requirements）
アーキテクチャ決定記録（Architecture Decision Records）

なぜ英語で書くのか

グローバルチームでは英語が設計ドキュメントの共通言語になる。英語で書くことで、海外チームのレビューや引き継ぎがスムーズになる。

「なぜその技術を選んだか」「どのトレードオフを許容したか」という意思決定の記録は、後から参加するメンバーにとって特に価値が高い。

ADR（アーキテクチャ決定記録）とは

Architecture Decision Records（ADR）は、設計上の重要な決定を記録するセクションだ。「なぜMySQLではなくPostgreSQLを選んだか」「なぜモノリスではなくマイクロサービスを採用したか」といった理由を残すことで、将来の変更判断が楽になる。

テンプレートをダウンロード（Word）

以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。

📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)

日本語版テンプレート（コピペOK）

基本情報

項目	内容
ドキュメント名	（例：〇〇システムアーキテクチャ設計書）
バージョン	v1.0
作成日	YYYY-MM-DD
作成者	（名前・役割）
最終更新日	YYYY-MM-DD
レビュアー	（名前）
ステータス	Draft / In Review / Approved

目的・スコープ

項目	内容
目的	（このドキュメントが何のために作成されたかを1〜2文で記入）
対象システム	（システム名・サービス名）
対象読者	（開発チーム・アーキテクト・レビュアーなど）
スコープ内	（このドキュメントで扱う範囲）
スコープ外	（このドキュメントで扱わない範囲）

アーキテクチャ概要

項目	内容
アーキテクチャパターン	（例：マイクロサービス / モノリス / サーバーレス）
主要な技術スタック	（例：React, Node.js, PostgreSQL, AWS）
デプロイ環境	（例：AWS / Azure / GCP / オンプレミス）
概要図	（アーキテクチャ図のURLまたは添付参照）

コンポーネント設計

コンポーネント名	役割	技術	依存関係
フロントエンド	ユーザーインターフェースの提供	React, TypeScript	APIゲートウェイ
APIゲートウェイ	リクエストのルーティング・認証	Node.js, Express	各マイクロサービス
認証サービス	ユーザー認証・認可の管理	Node.js, JWT	DB（ユーザー）
データベース	データの永続化	PostgreSQL	各サービス
キャッシュ	頻繁なクエリの高速化	Redis	APIゲートウェイ

データ設計

項目	内容
データベース種別	（例：リレーショナル / NoSQL / 時系列）
主要なエンティティ	（例：User, Order, Product）
データ保持期間	（例：ユーザーデータ：退会後1年）
バックアップ方針	（例：日次フルバックアップ、1時間ごとの差分）
データ暗号化	（例：保存時AES-256、転送時TLS1.2以上）

セキュリティ設計

項目	内容
認証方式	（例：JWT / OAuth 2.0 / SAML）
認可モデル	（例：RBAC / ABAC）
通信の暗号化	（例：全通信をTLS 1.2以上で暗号化）
シークレット管理	（例：AWS Secrets Manager / HashiCorp Vault）
脆弱性対策	（例：依存ライブラリの週次スキャン、WAF導入）

非機能要件

項目	要件	計測方法
可用性	99.9%以上（月間ダウンタイム44分以内）	CloudWatchアラーム
レスポンスタイム	APIレスポンス95パーセンタイルで500ms以内	APMツール
スループット	最大1,000リクエスト/秒を処理できること	負荷テスト
スケーラビリティ	トラフィック増加時に自動スケールできること	オートスケール設定
障害復旧	RTO 1時間以内、RPO 15分以内	定期的なDR訓練

アーキテクチャ決定記録（ADR）

ID	決定内容	理由	代替案	結果
ADR-001	データベースにPostgreSQLを採用	トランザクション整合性と豊富なJSON対応が必要なため	MySQL, MongoDB	Approved
ADR-002	キャッシュ層にRedisを採用	セッション管理とパフォーマンス最適化のため	Memcached	Approved
ADR-003	コンテナオーケストレーションにKubernetesを採用	複数サービスの統一的な管理と自動スケールのため	ECS, Nomad	Approved

英語版テンプレート（コピペOK）

Document Info

Field	Value
Document Title	(e.g., Architecture Design Document for [System Name])
Version	v1.0
Created Date	YYYY-MM-DD
Author	(Name / Role)
Last Updated	YYYY-MM-DD
Reviewer	(Name)
Status	Draft / In Review / Approved

Purpose & Scope

Field	Value
Purpose	(Describe the purpose of this document in 1–2 sentences)
Target System	(System / service name)
Target Audience	(e.g., Development team, Architects, Reviewers)
In Scope	(What this document covers)
Out of Scope	(What this document does not cover)

Architecture Overview

Field	Value
Architecture Pattern	(e.g., Microservices / Monolith / Serverless)
Key Technology Stack	(e.g., React, Node.js, PostgreSQL, AWS)
Deployment Environment	(e.g., AWS / Azure / GCP / On-premises)
Architecture Diagram	(URL or see attachment)

Component Design

Component	Role	Technology	Dependencies
Frontend	Provides user interface	React, TypeScript	API Gateway
API Gateway	Routes requests and handles authentication	Node.js, Express	Microservices
Auth Service	Manages user authentication and authorization	Node.js, JWT	User DB
Database	Persists application data	PostgreSQL	All services
Cache	Accelerates frequent queries	Redis	API Gateway

Data Design

Field	Value
Database Type	(e.g., Relational / NoSQL / Time-series)
Key Entities	(e.g., User, Order, Product)
Data Retention Policy	(e.g., User data retained for 1 year after account deletion)
Backup Policy	(e.g., Daily full backup, hourly incremental backup)
Data Encryption	(e.g., AES-256 at rest, TLS 1.2+ in transit)

Security Design

Field	Value
Authentication Method	(e.g., JWT / OAuth 2.0 / SAML)
Authorization Model	(e.g., RBAC / ABAC)
Transport Encryption	(e.g., All traffic encrypted via TLS 1.2+)
Secret Management	(e.g., AWS Secrets Manager / HashiCorp Vault)
Vulnerability Management	(e.g., Weekly dependency scanning, WAF deployment)

Non-Functional Requirements

Category	Requirement	Measurement Method
Availability	99.9% uptime (max 44 min/month downtime)	CloudWatch alarms
Response Time	95th percentile API response ≤ 500ms	APM tooling
Throughput	Handles up to 1,000 requests/second during peak load	Load testing
Scalability	Auto-scales in response to traffic spikes	Auto-scaling policy
Disaster Recovery	RTO ≤ 1 hour, RPO ≤ 15 minutes	Regular DR drills

Architecture Decision Records (ADR)

ID	Decision	Rationale	Alternatives Considered	Status
ADR-001	Adopt PostgreSQL as the database	Requires strong transaction support and rich JSON handling	MySQL, MongoDB	Approved
ADR-002	Adopt Redis for caching layer	Needed for session management and performance optimization	Memcached	Approved
ADR-003	Adopt Kubernetes for container orchestration	Enables unified management and auto-scaling of multiple services	ECS, Nomad	Approved

各セクションの書き方と例文

テンプレートを埋めるときに悩みやすいセクションを解説する。

Purpose（目的）の書き方

目的は「このドキュメントが何のためにあるか」を1〜2文で書く。読者が誰で、何を得られるかを明確にするのがポイントだ。

日本語	英語
このドキュメントは〇〇システムの全体アーキテクチャを定義します	This document defines the overall architecture of the [System Name].
開発チームとステークホルダーが設計上の決定を理解できるようにします	This document enables the development team and stakeholders to understand key architectural decisions.
このドキュメントは将来の変更判断の根拠として機能します	This document serves as the basis for future design and change decisions.

ADR（アーキテクチャ決定記録）の書き方

ADRは「決定内容・理由・代替案」の3点セットで書く。「理由」が書かれていないADRは将来の判断の助けにならない。

日本語	英語
スケーラビリティとチームの習熟度を考慮してXを採用しました	We chose X considering scalability requirements and the team’s existing expertise.
〇〇は検討しましたが、〇〇の理由で却下しました	We considered [Alternative] but rejected it due to [Reason].
このトレードオフを許容した理由は〇〇です	We accepted this trade-off because [Reason].

Non-Functional Requirements（非機能要件）の書き方

非機能要件は「数値で書く」のが鉄則だ。「高速であること」ではなく「95パーセンタイルで500ms以内」と書く。

日本語	英語
99.9%の可用性を確保すること	Maintain 99.9% availability (max 44 minutes of downtime per month).
ピーク時に1,000リクエスト/秒を処理できること	Handle up to 1,000 requests per second during peak load.
障害発生から1時間以内に復旧できること	Recover from failures within 1 hour (RTO ≤ 1 hour).

英語でのアーキテクチャ設計議論をさらに深めたい方は、エンジニアの英語アーキテクチャ議論術も参考にしてほしい。

アーキテクチャ設計書でよく使う英語表現

実務でよく使う英語表現を場面別にまとめた。

アーキテクチャ説明

日本語	英語
マイクロサービスアーキテクチャを採用	Adopt a microservices architecture
単一責任の原則に従う	Follow the Single Responsibility Principle
疎結合・高凝集の設計	Loosely coupled and highly cohesive design
スケールアウトに対応した設計	Designed for horizontal scaling
障害の影響を局所化する	Isolate the blast radius of failures
フォールトトレラントな設計	Fault-tolerant design

技術選定・トレードオフ

日本語	英語
〇〇と〇〇のトレードオフを検討した	We evaluated the trade-off between X and Y.
〇〇の理由で〇〇を採用した	We selected X because of Y.
この設計の制約は〇〇だ	The constraint of this design is X.
将来的な拡張性を考慮した	We considered future extensibility.
運用コストと開発速度のバランスを取った	We balanced operational cost against development velocity.

非機能要件・SLA

日本語	英語
目標復旧時間	Recovery Time Objective (RTO)
目標復旧ポイント	Recovery Point Objective (RPO)
サービスレベル目標	Service Level Objective (SLO)
エラーバジェット	Error budget
単一障害点を排除する	Eliminate single points of failure
水平スケーリング	Horizontal scaling