自動化は金曜日!
ツール解説

Claude Architect完全ガイド — 5つの領域をマスターして本番レベルのAIアプリを構築する方法

Claude Architect完全ガイド — 5つの領域をマスターして本番レベルのAIアプリを構築する方法
あいちゃん
あいちゃん
Claude Architectって何ですか?資格試験があるって聞いたんですが...
須崎
須崎
Claude Code、Agent SDK、API、MCPの4つを体系的にマスターするための学習ガイドだよ。試験自体はパートナー限定だけど、知識は誰でも学べるし、それが大事なんだ。

先日、Xで@hooeem氏がClaude Certified Architect(Foundations)試験のガイドを公開していました。

この試験はAnthropicのパートナー企業向けの認定制度ですが、試験そのものよりも、そこで問われる知識の中身がとにかく実践的なんです。

エージェントアーキテクチャ、MCP、Claude Code、プロンプトエンジニアリング、コンテキスト管理 ── この5つの領域をきちんと理解すれば、本番レベルのAIアプリを自力で構築できるスキルが身につきます。

この記事では、hooeem氏の英語記事を日本語に翻訳・再構成し、5つのドメインを体系的にまとめました。試験を受けなくても、この知識は必ず役に立ちます。

この記事でわかること

・Claude Certified Architectの5つの領域(ドメイン)の全体像
・エージェントアーキテクチャの設計パターンとアンチパターン
・MCP統合とツール設計のベストプラクティス
・Claude Codeの設定とワークフロー最適化
・プロンプトエンジニアリングと構造化出力の実践テクニック
・コンテキスト管理と信頼性設計

Claude Certified Architectとは

Claude Certified Architect(Foundations)は、Anthropicが提供するClaude技術の認定試験です。

対象はAnthropicのパートナー企業のエンジニアで、Claude APIやClaude Codeを使ったアプリケーション開発の知識を体系的に評価します。

試験は5つのドメイン(領域)に分かれており、それぞれに配点の重みがあります。

EXAM DOMAINS
Claude Architect 5つのドメイン配分
Domain 1
Agentic Architecture
27%
Domain 2
Tool Design & MCP
18%
Domain 3
Claude Code
20%
Domain 4
Prompt Engineering
20%
Domain 5
Context Management
15%

最も配点が高いのがDomain 1の「エージェントアーキテクチャ」で27%。次いでClaude Codeとプロンプトエンジニアリングが各20%と続きます。

パートナー限定の試験なので一般の方は受けられませんが、この5つのドメインの知識を身につけること自体が、AI開発スキルの底上げに直結します。順番に見ていきましょう。

Domain 1 ── エージェントアーキテクチャ&オーケストレーション(27%)

試験全体の27%を占める最重要ドメインです。AIエージェントがどのように動き、複数のエージェントをどう連携させるかを扱います。

エージェントループの仕組み

エージェントの基本動作は、実はシンプルなループです。

エージェントループの基本フロー
1
APIリクエスト
2
stop_reason確認
3
ツール実行
4
結果を履歴追加
5
再送信 or 完了

Messages APIにリクエストを送ると、レスポンスに stop_reason というフィールドが返ってきます。

"tool_use" → ツールを実行して結果を会話履歴に追加し、再度APIに送信
"end_turn" → タスク完了

ここで重要なのが、ループの終了判定を絶対に間違えてはいけないという点です。

NGパターン
  • 自然言語で完了を判定(「完了しました」をパース)
  • 任意の反復上限を主停止メカニズムにする
  • テキスト応答の有無で完了を判定
おすすめ
OKパターン
  • stop_reasonフィールドを使ってループの終了を判定する

stop_reasonはAPIが構造的に返すフィールドなので、パースミスや曖昧さが起きません。これが唯一の正しい判定方法です。

マルチエージェントオーケストレーション

複数のエージェントを連携させるとき、最もよく使われるのが「ハブ&スポーク」構成です。

中央にコーディネーター(司令塔)を置き、その下にタスクごとのサブエージェントを配置します。

ここで絶対に押さえておくべきポイントがあります。

サブエージェントは、コーディネーターの会話履歴を自動で継承しません。
必要な情報は、明示的にサブエージェントに渡す必要があります。これが最も間違えやすいポイントです。

また、タスク分解の精度も重要です。例えば「AIのクリエイティブ産業への影響を調査して」というタスクを分解するとき、視覚芸術だけを調査して音楽・執筆・映画を欠落させてしまう ── これが典型的な失敗パターンです。

ワークフロー強制とフック

エージェントの行動を制御する方法は2つあります。

1. プロンプトベースのガイダンス
プロンプトで「こういう場合はこうしてね」と指示する方法です。低リスクな案件ではこれで十分です。

2. プログラム的な強制(フック / 前提条件ゲート)
金融やセキュリティ関連では、プロンプトだけでは不十分です。コード側で物理的にブロックする仕組み(フック)を入れることで、確実にルールを守らせます。

あいちゃん
あいちゃん
サブエージェントが自動でコンテキストを共有しないのは意外です。
須崎
須崎
ここが一番間違えやすいポイント。必要な情報は全部明示的に渡すのが鉄則だよ。「きっと分かってくれるだろう」は通用しないんだ。

Domain 2 ── ツール設計&MCP統合(18%)

Domain 2では、Claudeが外部ツールと連携するための設計方法を扱います。特にMCP(Model Context Protocol)の理解が鍵になります。

ツール説明文が全てを決める

Claudeがどのツールを使うかを判断する際、唯一の手がかりはツールの説明文(description)です。

「ツールを呼び分けてくれない」「間違ったツールを使ってしまう」── こうした問題のほとんどは、few-shot例の追加やルーティング分類器の導入では解決しません。

最優先で改善すべきは、ツール説明文そのものです。

曖昧な説明はミスルーティングの原因になります。ツールが何をするか、いつ使うべきか、何を受け取って何を返すかを明確に記述しましょう。

エラーハンドリングの4カテゴリ

ツール実行時のエラーは、4つのカテゴリに分けて対処します。それぞれ対処法が異なるので、混同しないことが重要です。

Transient 一時的エラー
タイムアウトやネットワーク障害など。リトライ可能。時間を置いて再実行すれば成功する可能性が高い。
Validation 検証エラー
不正な入力値やフォーマットミス。入力を修正してリトライ。エラーメッセージを見て正しい値に直す。
Business ビジネスエラー
ポリシー違反や業務ルール抵触。リトライ不可。別のワークフローに切り替える必要がある。
Permission 権限エラー
アクセス権限の不足。エスカレーションが必要。人間の管理者に権限の付与を依頼する。

MCPサーバーの使い分け

MCPサーバーの設定には2つのレベルがあります。

プロジェクトレベル(.mcp.json)
プロジェクトごとの設定ファイル。チームで共有されるため、プロジェクト固有のツール連携に使います。

ユーザーレベル(~/.claude.json)
個人の設定ファイル。バージョン管理には含めず、個人の環境に依存するツール設定に使います。

また、MCPサーバーの選び方として以下の基準があります。

コミュニティMCPサーバー → Jira、GitHub、Slackなど標準的なサービスとの統合に使用
カスタムビルド → チーム固有のワークフローや社内システムとの連携が必要な場合のみ

Domain 3 ── Claude Code設定&ワークフロー(20%)

実務で最も直接的に役立つドメインです。Claude Codeの設定方法とワークフローの最適化を扱います。

CLAUDE.mdの3層構造

Claude Codeの動作を制御するCLAUDE.mdには、3つの階層があります。

1
ユーザーレベル(~/.claude/CLAUDE.md)
個人用の設定ファイル。バージョン管理には含めません。自分だけのルールや好みを記述します。
2
プロジェクトレベル(.claude/CLAUDE.md)
チーム共有の設定ファイル。Gitでバージョン管理します。コーディング規約やプロジェクト固有のルールを記述します。
3
ディレクトリレベル(各ディレクトリ内のCLAUDE.md)
特定のディレクトリ内でのみ適用されるルール。例えば「testsディレクトリではモックを使う」といった局所的な指示に使います。

よくある罠: 新しいチームメンバーにルールが適用されない → ユーザーレベル(~/.claude/)に書いてしまっている。チーム共有のルールは必ずプロジェクトレベルに置きましょう。

パス固有ルール

.claude/rules/ ディレクトリにYAMLフロントマター付きのファイルを置くことで、特定のファイルパターンにだけルールを適用できます。

例えば **/*.test.tsx というglobパターンを指定すれば、プロジェクト全体のテストファイルに対してのみルールが有効になります。

この方法は、ディレクトリレベルのCLAUDE.mdよりも柔軟で、ファイルパターンでの細かな制御が可能です。

プランモード vs 直接実行

Claude Codeには2つの実行モードがあります。使い分けの基準は明確です。

プランモード: 大規模なリファクタリングやマルチファイルの移行作業。変更の影響範囲を事前に把握したい場合に使います。

直接実行: 単一ファイルのバグ修正や、スコープが明確なタスク。すぐに結果が欲しい場合に使います。

CI/CD統合

Claude CodeをCI/CDパイプラインに組み込む際の重要なフラグが2つあります。

-p フラグ: 非インタラクティブモードで実行。これがないとCIがユーザー入力を待ってハングします。

--output-format json + --json-schema: 機械解析可能な出力を返します。CIパイプラインで結果を自動処理する場合に必須です。

あいちゃん
あいちゃん
CLAUDE.mdのレベル分けって実務でそんなに重要なんですか?
須崎
須崎
チーム開発では超重要。新メンバーが入ってきた時にルールが伝わらないと品質がバラつくからね。CLAUDE.mdの階層設計は、チーム全体の開発品質に直結するんだ。

Domain 4 ── プロンプトエンジニアリング&構造化出力(20%)

Claudeに正確な出力をさせるためのテクニック集です。プロンプトの書き方ひとつで、出力の品質は大きく変わります。

明確な基準を定義する

プロンプトで「控えめに」「高確信の発見のみ」のような曖昧な表現を使うのはNGです。

例えば、コードレビューをさせるなら「重大度」を以下のように具体的なコード例付きで定義します。

重大度 High: セキュリティ脆弱性、データ損失の可能性があるバグ
重大度 Medium: パフォーマンス問題、エラーハンドリングの不備
重大度 Low: コーディングスタイル違反、命名規則の不統一

このように具体的な判断基準を数値や例で示すことで、Claudeの出力が安定します。

Few-shotプロンプティング

出力の一貫性を高める最も効果的なテクニックがFew-shotプロンプティングです。

2〜4個の例を提示し、特に曖昧なケースでの判断理由まで含めると効果的です。

例えば「このコードは重大度Mediumです。理由: エラーハンドリングが不十分で、APIエラー時にユーザーにフィードバックが返りません」のように、判断プロセスまで見せることがポイントです。

tool_useとJSONスキーマ

tool_use と JSONスキーマを組み合わせると、構文エラーを完全に排除できます。

ただし注意点もあります。JSONスキーマが防げるのは「構文エラー」だけです。セマンティックエラー(意味的な誤り)は防げません

また、nullableフィールドを活用すると、Claudeが情報を持っていない場合にnullを返すようになり、捏造(ハルシネーション)を防止できます。

バッチ処理

大量のリクエストを処理する場合は、Message Batches APIが有効です。

同期API: ブロッキングワークフロー(ユーザーがリアルタイムで結果を待つ場合)に使用
バッチAPI: レイテンシを許容できるワークフロー(バックグラウンド処理、夜間バッチ等)に使用。コストが50%削減されますが、最大24時間かかる場合があります。

効果的なプロンプト改善の4ステップ
1
具体的な基準をコード例付きで定義
「控えめに」ではなく、重大度レベルを具体的なコード例で示す。曖昧さをゼロにする。
2
2〜4個のfew-shot例で曖昧ケースを示す
特に判断に迷うケースの例と、その判断理由を含めることで一貫性が飛躍的に向上する。
3
tool_use + JSONスキーマで出力構造を強制
構文エラーを排除し、nullableフィールドで捏造を防止。構造化された出力を確実に得る。
4
バリデーション-リトライループで品質を担保
出力を検証し、基準を満たさなければ修正指示と共に再実行。人間のレビュー頻度を大幅に削減。

Domain 5 ── コンテキスト管理&信頼性(15%)

配点は15%と最も低いですが、他の全ドメインの基盤となる知識です。ここでミスると全体に波及します。

コンテキスト保全

長い会話を続けると、コンテキストウィンドウが溢れてきます。そこで「漸進的要約」を使いたくなりますが、ここに罠があります。

漸進的要約の罠: 要約すると数値・日付・金額などの具体的なデータが曖昧になります。「2026年3月18日に150万円」が「最近、約150万円」に化けてしまうのです。

対策: 重要な事実は「ケースファクト」ブロックとして永続化し、要約対象から除外します。

もう一つ重要な現象が「Lost in the middle」効果です。長文の中央部分に置かれた情報は、先頭や末尾と比べて無視されやすくなります。重要な情報は必ず先頭に配置しましょう。

エスカレーションの判断

AIエージェントが人間にエスカレーション(引き継ぎ)すべきタイミングの判断基準です。

有効
エスカレーションすべきケース
  • 顧客が明示的に人間の対応を要求した
  • ポリシーに記載のない判断が求められる
  • 複数回の試行後も進展がない
エスカレーションすべきでないケース
  • 感情分析スコアだけに基づく判断
  • AIの自己報告による信頼度スコア

エラー伝播

エラーが発生した際、単に「エラーが起きました」と伝えるだけでは不十分です。構造化されたエラーコンテキストを伝える必要があります。

エラー情報に含めるべき4要素:

1. 失敗タイプ: 何が起きたのか
2. 試行内容: どんなリカバリーを試みたか
3. 部分的結果: どこまでは成功したか
4. 代替案: 他にどんな方法があるか

アンチパターン:
・サイレント抑制(エラーを握り潰して何も報告しない)
・単一障害でワークフロー全体を停止(1つのエラーで全部止まる)

あいちゃん
あいちゃん
コンテキスト管理って地味に見えますが、すごく大事なんですね。
須崎
須崎
ここでミスると他の全ドメインに波及するから、実は一番基盤になる知識なんだよ。地味だけど、ここを押さえているかどうかで実力の差が出る。

実践ロードマップ ── 何を作れば身につくか

5つのドメインの知識は、実際に手を動かして作ることで初めて身につきます。以下のロードマップに沿ってプロジェクトを作っていきましょう。

1
マルチツールエージェントを作る
3〜4個のMCPツールを接続し、stop_reasonハンドリングとPostToolUseフックを実装。エージェントループの基本を体験する。
2
ツール設計演習
意図的に曖昧な説明のツールを2つ作り、ミスルーティングを体験する。その後、説明文を改善して精度の変化を確認する。
3
プロジェクト設定の構築
CLAUDE.mdの3層構造を設計し、.claude/rules/ でパス固有ルールを設定。カスタムスキルも追加する。
4
抽出パイプラインの実装
tool_use + JSONスキーマで構造化出力を取得し、バリデーション-リトライループを構築。Batches APIでコスト最適化も試す。
5
マルチエージェントシステムの構築
コーディネーター + 2つのサブエージェント構成を実装。構造化エラー伝播と明示的なコンテキスト共有を組み込む。

各ステップは1〜2週間を目安に進めてみてください。全体で1〜2ヶ月あれば、5つのドメインを一通りカバーできます。

まとめ

あいちゃん
あいちゃん
試験は受けられなくても、全部実践で身につくんですね!
須崎
須崎
その通り。資格より実力。5つのドメインを手を動かして学べば、本番レベルのAIアプリが作れるようになるよ。

Claude Certified Architectの5つのドメインは、Claude技術を使ったAI開発の全体像を体系的に学ぶための最良のフレームワークです。

試験自体はパートナー限定ですが、そこで問われる知識は公開されており、誰でも学べます。そして、この知識を手を動かして実践することで、本番レベルのAIアプリケーションを構築する力が身につきます。

特に重要なのは以下の3点です。

1. エージェントアーキテクチャ(27%)が最重要
stop_reasonによるループ制御、サブエージェントへの明示的なコンテキスト共有 ── この基本を押さえないと、他の全てが崩れます。

2. ツール説明文がAIの行動を決める
MCPやツール連携の精度は、ツール説明文の品質で決まります。ここに最も時間をかけるべきです。

3. コンテキスト管理は全ての基盤
配点は15%と低いですが、ここでのミスは全ドメインに波及します。重要情報の配置と保全を常に意識しましょう。

この記事のポイントまとめ

・Claude Certified Architectは5つのドメインで構成される認定試験(パートナー限定)
・Domain 1(エージェントアーキテクチャ 27%)が最重要。stop_reasonでループ制御する
・サブエージェントはコンテキストを自動共有しない。必ず明示的に渡す
・ツール説明文の品質がMCP連携の精度を決める
・CLAUDE.mdには3層の階層があり、チーム開発での設計が品質に直結する
・プロンプトは具体的な基準 + few-shot例 + JSONスキーマで品質を担保
・コンテキスト管理は地味だが全ドメインの基盤。重要情報は先頭に配置
・5つの実践プロジェクトを作ることで、試験の知識が実力に変わる

よくある質問(FAQ)

Q. Claude Certified Architect試験は誰でも受けられますか?

現時点ではClaudeパートナー限定です。ただし、試験に必要な知識は公開されており、誰でも学べます。知識を身につけること自体が実践的なスキルアップにつながります。

Q. Agent SDKとClaude Codeの違いは何ですか?

Agent SDKはカスタムエージェントを構築するためのフレームワークです。Claude Codeは開発者向けのCLIツールで、コードの生成・編集・レビューを支援します。Agent SDKで「作る側」、Claude Codeで「使う側」という関係です。

Q. MCPとは何ですか?

Model Context Protocol の略で、AIモデルが外部ツールやデータソースと連携するための標準プロトコルです。GitHub、Slack、Jiraなどの外部サービスとClaudeをつなぐ「共通規格」だと考えてください。

Q. 5つのドメインのうち、最初にどこから学ぶべきですか?

Domain 1(エージェントアーキテクチャ)が最重要(27%)で基盤となるため、ここから始めるのがおすすめです。エージェントループとstop_reasonの仕組みを理解すれば、他のドメインの学習がスムーズに進みます。

Q. 学習にどのくらいの期間が必要ですか?

プログラミング経験にもよりますが、各ドメイン1〜2週間、全体で1〜2ヶ月程度が目安です。実際に手を動かしてプロジェクトを作ることが最も効率的です。記事内の実践ロードマップに沿って進めてみてください。

参考: @hooeem氏のX投稿を日本語に翻訳・再構成しました。