Architect Professional ドメイン6: 関係者コミュニケーションとライフサイクル管理（14%）
この章で学ぶこと: 構造化された要件の発見と収集、設計判断とトレードオフの伝え方、フィードバックと期待値（SLA を含む）の合わせ方、アーキテクチャの文書と実装の指針、ライフサイクルの各段階（発見・設計・引き継ぎ・監視・反復）の支え方。
| タスク（試験ガイド） | この章の節 |
|---|---|
| 構造化された要件発見と要件収集を行う | 第1節 |
| 設計判断とトレードオフを伝える | 第2節 |
| 関係者のフィードバックループと期待値のすり合わせを管理する（SLA を含む） | 第3節 |
| アーキテクチャを文書化し、実装の指針を示す | 第4節 |
| ライフサイクルの各段階を支援する（発見、設計、引き継ぎ、監視、反復） | 第5節 |
本番の63問のうち約9問です。
このドメインは、Anthropic の公式ドキュメントに専用のページがほとんどありません。この章の多くは、一般的なソリューションアーキテクトの実践を、公式の考え方（成功の基準、評価、段階的に始める）と結びつけた、この教材の整理です。試験では「どの関係者に、何を、どの順で示すのが最も適切か」という判断が問われると考えて読んでください。
基礎はここで復習してください:
- 業務要件 → 機能要件・インフラ要件、システムライフサイクル → Developer F ドメイン2 第1〜2節
- 価値と限界を関係者に伝える → Associate 補習 S3 第6節
- 評価の指標と A/B テスト → ドメイン4
1. 構造化された要件の発見と収集
1.1 誰に聞くか
| 関係者 | 主な関心 | 聞くこと |
|---|---|---|
| 業務の責任者（スポンサー） | 業務の成果、投資の回収 | 何を良くしたいか、成功をどう測るか、予算 |
| 実際の利用者 | 毎日の使いやすさ | 今の手順、困っていること、例外の多い場面 |
| 業務の専門家（SME） | 正しさ | 正解の例、判断の基準、よくある誤り（評価データの元になる） |
| セキュリティ | リスク | データの種類、アクセスの統制、監査、インジェクション対策 |
| 法務・コンプライアンス | 規制と契約 | どの規制がかかるか、保存・削除、開示、人の確認の要件 |
| 運用・SRE | 動かし続けること | SLA、監視、事故対応、費用の上限 |
| 開発チーム | 作りやすさ | 既存のシステム、技術の制約、引き継ぎ |
1.2 発見の質問の型（この教材の整理）
| 分野 | 質問の例 |
|---|---|
| 課題 | 今どうやっているか。どこに時間がかかるか。何件くらいか |
| 成果 | 何がどれだけ良くなれば成功か（数字で）。今の値は |
| 品質 | どんな誤りなら許せるか、許せないか。誰が確かめるか |
| データ | どのデータを使うか。どこにあるか。個人情報・PHI・機密は含むか。誰が見てよいか |
| 速さ・量 | 応答は何秒以内か。1日に何件か。ピークは |
| 統合 | どのシステムとつなぐか。認証のしくみは |
| リスク | 間違えたら何が起きるか。取り消せるか |
| 運用 | 誰が運用するか。何かあったとき誰に知らせるか |
1.3 要件を整理する
| 種類 | 例 |
|---|---|
| 機能の要件 | 問い合わせを分類し、返信の下書きを作る。出典を示す |
| 品質の要件 | 分類の正答率95%以上。誤情報の割合1%未満 |
| 非機能の要件 | p95 で3秒以内、可用性99.9%、1件あたり $0.01 以下 |
| 制約 | PHI を含む → HIPAA readiness の対象の機能だけ。EU の個人データ → GDPR |
| 範囲外 | 返金の実行は今回は入れない |
公式の成功の基準の考え方（具体的・測れる・達成できる・関係がある）を、品質と非機能の要件にそのまま使います（ドメイン4 第1.1節）。
2. 設計判断とトレードオフを伝える
2.1 聞き手に合わせる
| 聞き手 | 伝える中心 | 避けること |
|---|---|---|
| 経営層 | 業務の成果、コスト、リスク、いつ何ができるか | 技術の細部、専門用語 |
| セキュリティ | データの流れ、権限、統制の層、残るリスク | 「モデルが賢いので安全」という説明 |
| 法務 | どのデータをどこで処理・保存するか、人の確認、開示 | 確かめていない「準拠しています」 |
| 開発チーム | 部品、インターフェース、評価、手順 | あいまいな要件 |
| 利用者 | 何ができて何ができないか、どう確かめるか | 「100%正しい」という期待 |
2.2 トレードオフの示し方
選択肢を並べ、同じ物差しで数字を出し、勧める案と理由を示します。
| 案 | 正答率（評価） | p95 遅延 | 1件あたりコスト | リスク |
|---|---|---|---|---|
| A: Haiku のみ | 88% | 1.2秒 | $0.002 | 難しい問い合わせで誤り |
| B: ルーティング（Haiku ＋ 上位モデル） | 94% | 1.8秒 | $0.006 | 分類の誤り |
| C: 上位モデルのみ | 95% | 3.5秒 | $0.020 | SLA（3秒）を超える |
（数字は説明のための架空の例です）
勧め: B。品質の要件（93%以上）と SLA（3秒）の両方を満たす中で、いちばん安い。C は品質がわずかに高いが SLA を満たさない。
2.3 判断を記録する（ADR）
アーキテクチャの決定記録（ADR, Architecture Decision Record）は、一般的なソフトウェアの実践です。
| 項目 | 書くこと |
|---|---|
| 背景 | 何を決める必要があったか |
| 選択肢 | 考えた案 |
| 決定 | 選んだ案 |
| 理由 | 評価の数字、要件、制約 |
| 結果 | 受け入れたトレードオフ、見直す条件（例: 新しいモデルが出たら再評価） |
3. フィードバックと期待値のすり合わせ（SLA を含む）
3.1 LLM のシステムで最初に合わせておく期待
| 誤った期待 | 合わせるべき現実 |
|---|---|
| 毎回同じ答えが出る | 非決定性がある。構造化出力や評価で幅を管理する |
| 100%正しい | 誤りは起きる。許せる誤りの割合と、人の確認の場所を決める |
| 一度作れば終わり | モデル・データ・利用のしかたが変わるので、評価と監視を続ける |
| 新しいモデルにすれば必ず良くなる | 振る舞いや料金が変わる。回帰の評価で確かめてから移す |
3.2 SLA・SLO・SLI
| 用語 | 意味 | 例 |
|---|---|---|
| SLI（指標） | 実際に測る値 | p95 の遅延、エラー率、品質スコア |
| SLO（目標） | 内部の目標値 | p95 で2.5秒以内 |
| SLA（約束） | 利用者や顧客との約束。守れないときの扱いを決めることもある | p95 で3秒以内、可用性99.9% |
LLM のシステムで SLA を決めるときの注意（この教材の整理）:
- 遅延は出力の長さで大きく変わる。出力の上限や形式を決めてから約束する
- 品質も SLA の対象にできる（例: 本番のサンプルの品質スコア）。測り方を合意しておく
- 外部の API の混雑（529）やレート制限（429）を考え、再試行とフォールバックを設計してから約束する
- SLO は SLA より厳しくして、余裕を持つ
3.3 フィードバックのループ
| ループ | 頻度の例 | 中身 |
|---|---|---|
| 利用者からの評価 | 毎回 | 採用・修正・低評価のボタン、コメント |
| 関係者との定例 | 週・月 | 指標（品質・遅延・コスト・SLA）、事故、改善の計画 |
| 評価の結果の共有 | 変更のたび | 能力と回帰の評価の結果 |
| 要件の見直し | 四半期など | 業務の変化、新しいモデル、規制の変化 |
4. アーキテクチャの文書と実装の指針
| 文書 | 中身 | 読み手 |
|---|---|---|
| アーキテクチャの説明 | 全体の図、データの流れ、部品、統合、信頼の境界 | 全員 |
| データの流れと保存 | どのデータがどこを通り、どこに何日残るか | セキュリティ、法務 |
| ADR | 決定と理由 | 開発、将来の担当者 |
| プロンプトとツールの台帳 | プロンプトの版、ツールの定義、権限 | 開発 |
| 評価の計画 | データセット、採点のしかた、合格の基準 | 開発、品質 |
| 運用手順（runbook） | 監視の指標、アラート、よくある問題と直し方、ロールバック | 運用 |
| 実装の指針 | コードの決まり、Claude Code の設定、CLAUDE.md（ドメイン7） | 開発 |
実装の指針の例: プロンプトは Git で版を管理し、モデルの ID は固定し、変更のたびに回帰の評価を回す（Developer F ドメイン2 第6節のモデルの固定・プロンプトの版の管理）。
5. ライフサイクルの各段階
| 段階 | アーキテクトがすること | 次に進む条件 |
|---|---|---|
| 発見（discovery） | 関係者に聞く、課題と成果を数字に、データとリスクを把握 | 成功の基準と範囲に合意 |
| 設計（design） | パターン・モデル・統合・統制を選ぶ、試作、小さな評価 | 評価で基準を満たす見込み、セキュリティと法務の確認 |
| 構築・試行 | 評価データセットを作る、段階的に出す（少人数 → 広く） | 回帰の評価と SLA を満たす |
| 引き継ぎ（handoff） | 文書、runbook、評価の道具、権限を運用・開発チームへ。教える | 受け取るチームが自分で運用できる |
| 監視（monitoring） | 指標、アラート、本番のサンプルの採点、drift の検知 | 続ける |
| 反復（iteration） | 失敗を評価に足す、プロンプト・モデルを改善、新しいモデルを評価 | 変更ごとに A/B テストか評価 |
引き継ぎで抜けやすいもの（この教材の整理）:
- 評価のデータセットと採点の道具（これがないと、引き継いだチームは変更が安全か判断できない）
- プロンプトとモデルの版の管理のしかた
- 費用の上限とアラートの設定
- 「なぜこう決めたか」（ADR）
6. 試験に向けたまとめ
- 発見は関係者ごとに聞く。成果・品質・データ・速さ・リスク・運用を数字で
- 品質と非機能の要件は「具体的・測れる・達成できる・関係がある」
- トレードオフは同じ物差しの数字で比べ、勧める案と理由を示す。ADR に残す
- LLM の非決定性と誤りを最初に伝える。「100%」を約束しない
- SLA は SLI と SLO と分けて決める。遅延は出力の長さ、外部 API の混雑も考える
- 引き継ぎには評価の道具と runbook を必ず含める
7. 用語集
| 用語 | 意味 |
|---|---|
| SME | その業務の専門家 |
| 非機能の要件 | 速さ、可用性、コスト、セキュリティなど、機能以外の要件 |
| ADR | アーキテクチャの決定記録 |
| SLI / SLO / SLA | 測る指標 / 内部の目標 / 外部への約束 |
| runbook | 運用の手順書 |
| handoff（引き継ぎ） | 作ったシステムを運用するチームに渡すこと |
出典
- Define success criteria and build evaluations（Claude Platform Docs）: 成功の基準の4つの性質
- Demystifying evals for AI agents（Anthropic Engineering）: 評価・本番の監視・A/B テスト・人のレビューの組み合わせ
- Building effective agents（Anthropic Engineering）: 簡単な形から始める
- 試験ガイド: ドメイン6のタスクの一覧
注意: この章の表（関係者の一覧、質問の型、聞き手ごとの伝え方、SLA の注意、文書の一覧、ライフサイクルの表）は、一般的な実践にもとづくこの教材の整理です。第2.2節の数字は架空の例です。