← 試験の目次へ

Architect Professional ドメイン1: ソリューション設計とアーキテクチャ（17%）

この章で学ぶこと: 業務課題を Claude のソリューションに落とし込む手順、入力から改善までの全体の形、パターンの選び方（ワークフロー・エージェント・拡張LLM）、マルチエージェントを使うべき場面と使うべきでない場面、分解のしかた、業務価値の柱との結びつけ方。

タスク（試験ガイド） この章の節
業務課題を Claude ベースのAIソリューションに落とし込む 第1節
エンドツーエンドのアーキテクチャを設計する（入力 → 処理 → 出力 → フィードバックループ） 第2節
適切なアーキテクチャパターンを選ぶ（ワークフロー、エージェント型、拡張LLM） 第3節
マルチエージェントシステムとオーケストレーション戦略を設計する 第4節
複雑な問題を解くために分解の手法を使う 第5節
ソリューションを業務価値の柱に合わせる（効率、変革、生産性、コスト、性能SLA） 第6節

本番の63問のうち約11問です。Professional は「どれが正しい機能か」より、「この条件ならどの設計を選び、なぜ他を選ばないか」を問います。

基礎はここで復習してください（この章では繰り返しません）:

1. 業務課題を AI ソリューションに落とし込む

1.1 最初に問うこと: そもそも LLM が要るか

アーキテクトの最初の仕事は、Claude を使う理由を確かめることです。Anthropic は「いちばん簡単な方法から始め、必要なときだけ複雑にする」ことを勧めています（Building effective agents）。

問い 「いいえ」なら
入力があいまい・多様で、ルールで書ききれないか 普通のプログラム（ルール、検索、SQL）で足りるかもしれない
少しの間違いを許せるか、または人や仕組みで確かめられるか 確認のしくみを設計に入れる。入れられないなら自動化の範囲を狭める
成功を測れるか 先に成功の基準と評価を決める（ドメイン4）
1回の呼び出し＋検索＋良い例で足りないか 足りるなら、エージェントにしない

1.2 落とし込みの手順（考え方の型）

以下は公式の手順ではなく、試験で役立つ考え方の型です（この教材の整理）。

段階 やること 成果物の例
1. 課題を言い換える 「誰の、どの作業の、何が困っているか」を1文に 「サポート担当が返信の下書きに1件15分かかる」
2. 成果を数字にする 今の値と目標の値。品質・速さ・コスト・安全の指標 下書き時間 15分 → 5分、誤情報率 1%未満
3. 制約を集める データの種類（個人情報・PHI）、規制、遅延の上限、予算、既存システム 「PHI を含む」「応答は3秒以内」
4. 人と AI の分担を決める AI が下書き・人が承認、AI が自動で実行、など 人が送信ボタンを押す
5. いちばん簡単な形を選ぶ 1回の呼び出し → ワークフロー → エージェントの順に検討 検索＋1回の生成＋人の承認
6. 評価と試作で確かめる 小さな評価セット（20〜50件）で試す 合格なら段階的に広げる

1.3 よくある誤り

誤り なぜだめか 正しい方向
「最新・最大のモデルとマルチエージェントで作る」から始める コストと遅延が増え、評価もしにくい 簡単な形から。足りない能力が評価で見えたら上げる
成功の基準なしに作り始める 良くなったか判断できない 先に指標と目標値
AI に最終判断まで任せる（影響の大きい判断で） 規制や Usage Policy で人の確認が要る場合がある 人の確認を設計に入れる（ドメイン5）

2. エンドツーエンドのアーキテクチャ

試験ガイドは「入力 → 処理 → 出力 → フィードバックループ」の形を挙げています。各段で何を決めるかを表にします。

段 決めること 主な部品
入力 どこから来るか、信頼できるか、形式、個人情報の扱い 入力の検証、PII のマスキング、プロンプトインジェクション対策
文脈の準備 何をモデルに見せるか RAG（ドメイン3）、ツール、メモリ、キャッシュする固定部分
処理 モデル、パターン、ツール、ループの上限 ワークフロー / エージェント、モデル選択（ドメイン2）
出力 形式、検証、誰に届くか 構造化出力、スキーマ検証、引用、人の承認
記録 何を残すか トレース、request-id、トークン数、コスト
フィードバック 結果をどう改善に戻すか ユーザーの評価、人の修正、失敗例を評価セットに追加

2.1 フィードバックループの設計

フィードバックループがないシステムは、時間とともに悪くなっても気づけません。

ループ 何を戻すか どこに戻すか
本番の失敗 → 評価セット 失敗した入力と、正しい答え 回帰評価（regression eval）に追加
人の修正 → プロンプト 人がどこを直したか プロンプト・例・ツールの説明の改善
利用データ → 指標 採用率、修正率、エスカレーション率 ダッシュボード、SLA の確認
文書の更新 → インデックス 新しい文書、消えた文書 RAG の再インデックス（ドメイン3）

Anthropic は、本番で見つかった実際の失敗から20〜50件の簡単なタスクを集めるだけでも評価の良い出発点になる、と書いています（Demystifying evals for AI agents）。

3. パターンを選ぶ: ワークフロー、エージェント、拡張LLM

3.1 3つの形

形 何か 向いている場面 弱み
拡張LLM（augmented LLM） 検索・ツール・メモリを持った1つの LLM 呼び出し。すべての形の部品 1回でほぼ答えが出る質問応答、要約、分類 多段階の作業は苦手
ワークフロー 決まった手順のコードが LLM とツールを順に呼ぶ 手順が前もって決まる。予測できること・監査しやすさが大事 予想外の入力に弱い
エージェント LLM が自分で次の手順とツールを決め、ループする 手順が前もって決められない、答えのない調査 コスト・遅延・予測しにくさ。テストが難しい

3.2 選び方の判断表

条件 選ぶ形 理由
手順が決まっていて、監査で「毎回同じ手順」を示す必要がある ワークフロー（プロンプトチェーン＋ゲート） 予測でき、各段を個別にテストできる
入力の種類がはっきり分かれる ルーティング 種類ごとに専用のプロンプトやモデルを使える。簡単なものは安いモデルへ
同じ入力に複数の独立した確認をしたい 並列化（分割・投票） 速く、視点を増やせる
必要なサブタスクが入力を見るまでわからない オーケストレーター・ワーカー、またはエージェント 動的に分けられる
はっきりした評価基準があり、くり返すと良くなる 評価・最適化 生成と評価を分ける
何十ターンも自分で調べて進める エージェント（上限・権限・監視つき） 柔軟さが必要

ポイント: 「エージェントのほうが賢いから良い」ではありません。予測しやすさ、コスト、テストのしやすさを捨てる価値があるときだけ選びます。

4. マルチエージェントシステムとオーケストレーション

4.1 Anthropic の Research の事例（数字）

Anthropic は自社の Research 機能（オーケストレーター・ワーカー型のマルチエージェント）について、次のように書いています（How we built our multi-agent research system）。数字はその記事の時点のモデルでの社内評価です。

事実 内容
性能 Opus 4 をリード、Sonnet 4 をサブエージェントにした構成が、単体の Opus 4 より社内の調査評価で 90.2% 良かった
効く理由 問題を解くのに十分なトークンを使えること。BrowseComp での性能の差の80%はトークン使用量で説明できた
コスト エージェントはチャットの約4倍、マルチエージェントは約15倍のトークンを使う
向いている 並列にしやすい、1つのコンテキストに入りきらない、多くの複雑なツールを使う、価値の高い仕事
向いていない 全員が同じコンテキストを共有する必要がある、エージェント同士の依存が多い仕事（多くのコーディングなど）
速さ リードが3〜5個のサブエージェントを並列に起動し、サブエージェントも3つ以上のツールを並列に使うことで、複雑な調査の時間を最大90%短縮

4.2 オーケストレーションで決めること

決めること 公式の事例からの教訓
委任の書き方 各サブエージェントに「目的、出力の形式、使うツールと情報源、仕事の境界」を渡す。短くあいまいな指示だと重複や抜けが出る
量の調整 質問の難しさに合わせた目安をプロンプトに書く（例: 簡単な事実確認は1エージェントで3〜10回のツール呼び出し、比較は2〜4サブエージェント）
結果の受け渡し 大きな成果物はファイルなど外部に保存し、参照だけを返す（伝言ゲームでの情報の欠けとトークンを減らす）
失敗からの回復 最初からやり直さず、止まったところから再開できるようにする。再試行とチェックポイントを組み合わせる
配備 動いている途中のエージェントを壊さないよう、新旧を並べて少しずつ切り替える（rainbow deployment）
同期か非同期か 同期は簡単だが、1つの遅いサブエージェントが全体を止める。非同期は速いが、状態の一貫性やエラーの伝わり方が難しくなる

4.3 階層の形（比較）

形 しくみ 長所 短所
ハブ・アンド・スポーク（コーディネーター） 中心がすべての受け渡しを管理 見通しがよく、制御しやすい 中心が詰まりやすい
階層（マネージャーの下にマネージャー） 大きな組織のように分ける 大規模に分けられる 伝言で情報が欠けやすい、コスト増
エージェント間（agent-to-agent）で直接やりとり 別システムのエージェント同士が通信 組織や製品をまたげる 認証・信頼・監視が難しい（ドメイン3 第7節）

5. 分解の手法

手法 しくみ 向いている場面
固定のチェーン 前もって決めた段階に分ける 手順が決まっている（抽出 → 検証 → 要約）
動的な分解 オーケストレーターが入力を見て分ける 調査、答えのない問い
観点ごとの分割 同じ対象を観点別に見る（セキュリティ・性能・可読性） レビュー
データごとの分割（map-reduce） 大きな入力を部分に分けて処理し、最後にまとめる 大量の文書、長いファイル
生成と検証を分ける 作る役と確かめる役を別の呼び出しに 品質が大事、自己確認の甘さを避けたい
幅から深さへ まず広く浅く調べ、あとで絞る 調査（Anthropic の事例でも推奨）

分解のリスク:

6. 業務価値の柱に合わせる

試験ガイドは柱として「効率、変革、生産性、コスト、性能SLA」を挙げています。各柱の意味と指標の例は、この教材の整理です（公式の定義は見つかりませんでした）。

柱 意味 指標の例 設計で効くもの
効率（efficiency） 同じ仕事を少ない時間・手間で 1件あたりの処理時間、自動化率 ワークフロー化、バッチ、キャッシュ
変革（transformation） 今までできなかった仕事のやり方 新しいサービス、新しい顧客体験 エージェント、新しいワークフローの再設計
生産性（productivity） 人が価値の高い仕事に時間を使える 1人あたりの処理件数、待ち時間の減少 下書き支援、開発支援（ドメイン7）
コスト（cost） 総コストを下げる、または予測できるようにする 1件あたりのコスト、月の総額 モデルの使い分け、キャッシュ、バッチ（50%）、トークン削減
性能SLA（performance SLAs） 約束した速さ・可用性・品質を守る p95 レイテンシ、可用性、エラー率、品質スコア ストリーミング、速いモデル、フォールバック、監視

6.1 柱どうしのトレードオフ

例 起きること 決め方
品質を上げるため上位モデルにする コストと遅延が増える → コストと SLA の柱に影響 評価で「品質の差」と「コストの差」を数字で比べ、関係者と合意（ドメイン6）
マルチエージェントで変革を狙う トークンが約15倍 仕事の価値がコストに見合うか確かめる
バッチで安くする 結果まで最大24時間待つことがある 即時性が要らない仕事だけに使う

7. 試験に向けたまとめ

8. 用語集

用語 意味
拡張LLM（augmented LLM） 検索・ツール・メモリを使える LLM。すべての形の基本の部品
オーケストレーター・ワーカー 中心の LLM が仕事を分け、ワーカーに任せてまとめる形
rainbow deployment 新旧のバージョンを同時に動かし、少しずつ切り替える配備のしかた
map-reduce 部分ごとに処理して、最後にまとめる分け方
SLA サービスの水準の約束（速さ、可用性など）

出典

注意: 第1.2節の手順と第6節の柱の定義・指標は、この教材の整理です。数字（90.2%、15倍など）は記事の時点のモデルでの社内評価で、今のモデルでは変わりえます。