senior-architect

シニアアーキテクト

概要

システム設計の意思決定に関するアーキテクチャレベルのガイダンスを提供します。このスキルでは、アーキテクチャ決定記録（ADR）、トレードオフ分析、スケーラビリティの設計図、非機能要件仕様を作成します。すべての推奨事項にはトレードオフを明記し、実証済みのパターンに基づいています。

開始時に伝える: 「システム設計とアーキテクチャの意思決定に senior-architect スキルを使用しています。」

---

フェーズ 1：要件分析

目標： 設計を始める前に、機能要件と非機能要件をすべて把握します。

アクション

1. 機能要件（機能）を特定します
2. 非機能要件（品質特性）を定義します
3. 制約（予算、チーム、スケジュール、コンプライアンス）を特定します
4. 既存システムとの統合ポイントを整理します
5. 成功基準と SLO を設定します

STOP — フェーズ 2 に進む前に、以下を満たしてください：

• 機能要件が列挙されている
• 非機能要件が定量化されている（曖昧でない）
• 制約が明確になっている
• 成功基準が測定可能である

---

フェーズ 2：アーキテクチャ設計

目標： 選択肢を評価し、最適なトレードオフ特性を持つアプローチを選択します。

アクション

1. アーキテクチャスタイル（モノリス、マイクロサービス、イベント駆動型）を評価します
2. コンポーネントの境界とインターフェースを設計します
3. データアーキテクチャ（ストレージ、フロー、一貫性）を定義します
4. インフラストラクチャとデプロイのトポロジーを計画します
5. 横断的関心事（認証、ロギング、モニタリング）に対処します

アーキテクチャスタイルの決定表

要素	モノリス	モジュラーモノリス	マイクロサービス	サーバーレス
チーム規模 < 10	推奨	適合性が高い	過剰	負荷変動が激しい場合に適する
チーム規模 > 30	難しい	良い	推奨	状況による
ドメインが十分に理解されている	適合性が高い	適合性が高い	まだ不要	適合性が高い
ドメインが急速に変化している	まず始めるには問題ない	適合性が高い	まだ早い	適合性が高い
独立したデプロイが必要	不可能	限定的	主な利点	標準で備わっている
運用成熟度が低い	適合性が高い	適合性が高い	リスクが高い	リスクを管理しやすい
変動の大きい／突発的な負荷	過剰にプロビジョニング	過剰にプロビジョニング	可能	適合性が高い

デフォルトの推奨事項

モジュラーモノリスから始めます。明確なモジュール境界を設け、デプロイは単一にします。独立したスケーリング、デプロイ、またはチームの自律性が必要だと実証されてから、マイクロサービスに切り出してください。

トレードオフ分析：よくある組み合わせ

改善する項目	低下する可能性がある項目
一貫性	可用性、レイテンシー
パフォーマンス	保守性、コスト
セキュリティ	ユーザビリティ、パフォーマンス
スケーラビリティ	シンプルさ、コスト
柔軟性	パフォーマンス、複雑さ
市場投入までの時間	品質、スケーラビリティ

決定マトリックスのテンプレート

Weight each quality attribute (1-5), score each option (1-5), multiply and sum.

| Quality Attribute  | Weight | Option A | Option B | Option C |
|--------------------|--------|----------|----------|----------|
| Performance        |   4    |  4 (16)  |  3 (12)  |  5 (20)  |
| Maintainability    |   5    |  5 (25)  |  4 (20)  |  2 (10)  |
| Scalability        |   3    |  3 (9)   |  5 (15)  |  4 (12)  |
| Cost               |   4    |  4 (16)  |  2 (8)   |  3 (12)  |
| Total              |        |    66    |    55    |    54    |

STOP — フェーズ 3 に進む前に、以下を満たしてください：

• 2 つ以上のアーキテクチャ選択肢を評価している
• トレードオフが明示的に記録されている
• 決定マトリックスのスコアが推奨事項を裏付けている
• データアーキテクチャが定義されている

---

フェーズ 3：ドキュメント作成と検証

目標： 意思決定を記録し、要件に照らして検証します。

アクション

1. 重要な意思決定についてアーキテクチャ決定記録を作成します
2. システムコンテキスト図とコンテナ図を作成します（C4 モデル）
3. 非機能要件に照らして検証します
4. リスクと緩和策を特定します
5. 進化的アーキテクチャのガードレールを定義します

ADR の形式

# ADR-{number}: {Title}

## Status
Proposed | Accepted | Deprecated | Superseded by ADR-{number}

## Context
What is the issue motivating this decision?

## Decision
What change are we proposing?

## Consequences

### Positive
- [Benefit 1]
- [Benefit 2]

### Negative
- [Trade-off 1]
- [Trade-off 2]

### Risks
- [Risk and mitigation]

## Alternatives Considered
| Option | Pros | Cons | Verdict |
|--------|------|------|---------|
| Option A | ... | ... | Chosen |
| Option B | ... | ... | Rejected because... |

C4 モデルのレベル

レベル	表示内容	使用するタイミング
レベル 1：システムコンテキスト	ユーザーと外部システム	常に
レベル 2：コンテナ	主要な技術的構成要素	常に
レベル 3：コンポーネント	コンテナ内のコンポーネント	複雑なサービス
レベル 4：コード	クラスレベルの詳細	重要または複雑な領域のみ

STOP — 以下を満たした時点でドキュメント作成は完了です：

• すべての重要な意思決定について ADR を作成している
• システムコンテキスト図を作成している
• 設計に照らして NFR を検証している
• リスクと緩和策を記録している

---

スケーラビリティのパターン

水平スケーリングの判断表

パターン	使用する状況	実装
負荷分散	同じサービスのインスタンスが複数ある場合	ラウンドロビン、最小接続数、IP ハッシュ
ステートレスサービス	インスタンスを自由に追加・削除する必要がある場合	JWT／外部セッションストア
オートスケーリング	負荷の変動パターンがある場合	CPU／メモリ／リクエスト率をトリガーとする
読み取りレプリカ	読み取り中心のワークロード	読み取りをレプリカに、書き込みをプライマリにルーティング

シャーディング戦略の判断表

戦略	方法	適している用途
ハッシュベース	キーの一貫性ハッシュ	均等な分散
範囲ベース	日付範囲、ID 範囲	時系列データ
地理ベース	地域／国別	データのローカリティ
テナントベース	顧客ごと	マルチテナント SaaS

キャッシュレイヤー

Client Cache (browser) -> CDN Cache -> API Gateway Cache ->
Application Cache (Redis) -> Database Query Cache -> Database

---

非機能要件テンプレート

## Performance
- Response time: p95 < 200ms, p99 < 500ms for API calls
- Throughput: 1000 RPS sustained, 5000 RPS peak
- Batch processing: 1M records/hour

## Availability
- Target: 99.9% (8.76h downtime/year)
- RTO (Recovery Time Objective): < 15 minutes
- RPO (Recovery Point Objective): < 5 minutes

## Scalability
- Current: 10K DAU
- 12-month target: 100K DAU
- Scale dimension: users, data volume, request rate

## Security
- Authentication: OAuth 2.0 / OIDC
- Authorization: RBAC with resource-level permissions
- Data encryption: at rest (AES-256) and in transit (TLS 1.3)

## Observability
- Logging: structured JSON, 30-day retention
- Metrics: RED method, custom business metrics
- Tracing: distributed tracing across all services
- Alerting: PagerDuty integration, tiered severity

SLO／SLA／SLI フレームワーク

用語	定義	例
SLI	測定可能な指標	リクエストのレイテンシ、エラー率
SLO	目標値	可用性 99.9%
SLA	契約上のコミットメント	99.5%、ペナルティ条項付き
エラーバジェット	1 - SLO	0.1% = 年間 8.76 時間

---

アンチパターン／よくある間違い

アンチパターン	問題点	適切なアプローチ
履歴書映えを重視したアーキテクチャ	メリットのない複雑さ	機能する中で最もシンプルなソリューションを選ぶ
分散モノリス	両方の欠点をすべて抱える	真のモノリスか、真のマイクロサービスのいずれかを選ぶ
時期尚早な最適化	ユーザーが 100 人なのに 100 万人向けにスケーリングする	1000 倍ではなく、現状とその 10 倍を想定して設計する
万能のハンマー	あらゆる用途にひとつの技術を使う	問題ごとに適切なツールを選ぶ
検証なしのアーキテクチャ	未検証の前提	負荷テスト、障害テストを行い、検証する
反復のない大規模な初期設計	要件は変化する	ガードレールを設けた進化型アーキテクチャ
曖昧な非機能要件（「速い」「スケーラブル」）	検証できない	測定可能な定量目標を設定する

---

サブエージェントへの委任機会

タスクのパターン	委任先	タイミング
異なるアーキテクチャレイヤーの分析	Agent ツールで subagent_type="Explore" を指定（レイヤーごとに 1 つ）	フロントエンド、バックエンド、インフラを個別にレビューする場合
アーキテクチャのセキュリティ評価	Agent ツールで security-review スキルを呼び出す	アーキテクチャに認証、データフロー、外部 API が関わる場合
パフォーマンスへの影響分析	Agent ツールで performance-optimization スキルを呼び出す	アーキテクチャの決定がレイテンシやスループットに影響する場合
既存パターンのコード品質レビュー	Agent ツールで code-reviewer エージェントに委任する	リファクタリングに向けて現在のコードベースを評価する場合

委任する際は、dispatching-parallel-agents スキルのプロトコルに従ってください。

---

統合ポイント

スキル	関係
senior-backend	バックエンドの実装はアーキテクチャの決定に従います
senior-fullstack	フルスタックアーキテクチャはサービス境界に従います
security-review	セキュリティはアーキテクチャ全体に関わる課題です
performance-optimization	パフォーマンスの非機能要件が最適化目標を決定します
planning	アーキテクチャの決定が実装計画に反映されます
code-review	レビューでアーキテクチャの一貫性を検証します
acceptance-testing	非機能要件が受け入れ基準になります

---

主要原則

• 機能する可能性のある最もシンプルなアーキテクチャから始める
• 可能な限り、決定を元に戻せるようにする
• 障害を前提に設計する（いずれすべてが失敗する）
• 技術的な優雅さではなく、チームの認知負荷を最適化する
• 結果だけでなく、決定も文書化する
• 重要な処理経路には、実績のある技術を優先する
• すべてのアーキテクチャ上の決定にはコストが伴うため、それを明確にする

---

スキルの種類

柔軟 — アーキテクチャに関する推奨事項は、具体的な状況に合わせて調整します。重要な意思決定には、ADR を強く推奨します。トレードオフの分析は必須です。NFR は曖昧な表現ではなく、数値で定量化する必要があります。