本文へ移動

FORWARD DEPLOYED ENGINEER

FDE 基礎読本

Claude と Databricks の最新動向と、FDE の基礎知識

Claude Certified Developer: Foundations

Claude 認定デベロッパー（Foundations）で押さえる論点

試験に向けて押さえておきたい知識を、論点ごとにまとめています。それぞれに、覚えること・解説・よくある誤解・関連する基礎知識を付けています。

著者が試験対策の中で学んだ論点を、2026年10月8日時点の公式ドキュメントで確かめて書いています。実際の試験問題や、市販の問題集の問題ではありません。

論点 1ツール利用

ツールの選び分けは、説明（description）で決まる

覚えること

  • Claude はツールの名前と説明を読んで、どれを使うかを決める
  • 名前も入力の形も同じくらい明確なら、見分ける材料はほぼ説明だけ
  • 説明には「いつ使うか」「何が返るか」「似たツールとの違い」を書く

解説

似た役割のツールが複数あり、片方ばかりが選ばれてしまうときは、まず説明を直すのがいちばん直接的な対策です。説明が短かったりあいまいだったりすると、どちらのツールを使うべきかをモデルが判断できず、選び方が偏ります。

たとえば「注文を探す」と「返品を探す」のツールなら、それぞれの説明に、どんな依頼のときに使うか、何が返ってくるか、もう一方のツールとどう違うかを書き分けます。

よくある誤解

  • 入力の形（スキーマ）を変える: 選び間違いの原因がスキーマでなければ、効果はありません。
  • ツール名を変える・ツールを1つにまとめる: 名前がすでに明確なら、根本の原因（説明の不足）は残ります。まとめるのは設計の変更で、直接の対策ではありません。

関連する基礎知識

公式の情報

論点 2Claude API

Message Batches API の2つの期限（処理は 24 時間、結果は 29 日間）

覚えること

  • 処理には最大 24 時間かかることがある（多くは 1 時間以内に終わる）
  • 24 時間以内に処理が終わらなかったリクエストは期限切れになる
  • 結果は作成から 29 日間取得できる（処理の期限とは別）
  • 料金は通常の半額

解説

Message Batches API は、すぐに結果がいらない大量のリクエストを、まとめて非同期で処理する仕組みです。時間の制限が2種類あり、「処理にかかる時間の上限」と「結果を取りに行ける期間」は別物です。

夜間にまとめて送る処理を設計するときは、24 時間以内に終わらないリクエストがありうることを前提にし、結果は 29 日以内に取得して保存しておきます。

よくある誤解

  • 「1 時間で必ず終わる」: 多くは 1 時間以内に終わりますが、保証ではありません。上限は 24 時間です。
  • 「処理と結果の保持は同じ 24 時間（または同じ 29 日間）」: 処理の上限は 24 時間、結果の取得期間は 29 日間で、別の制限です。

関連する基礎知識

公式の情報

論点 3エージェント開発

ワークフローとエージェントの違いは、だれが次の手を決めるか

覚えること

  • ワークフロー: 開発者がコードで手順と分岐を前もって決める
  • エージェント: モデルがループの中で途中の結果を見て、次に使うツールや行動を決める
  • 制御の主体が「コード」か「モデル」かが本質の違い

解説

ワークフローでは、モデルは決められた経路の中の各段階を受け持ちます。エージェントでは、モデル自身が、ツールの結果などの途中の情報をもとに、実行しながら次の行動を選びます。

流れが決まっている業務はワークフローのほうが安定し、費用も読みやすくなります。手順を前もって決められない仕事にだけ、エージェントを使うのが基本です。

よくある誤解

  • 「ツール（サーバーツールを含む）を呼ぶならエージェント」: ツールはワークフローでも使えるので、見分けるポイントにはなりません。
  • 「構造化した出力を返すならエージェント」: 出力の形式の話で、どちらでも使えます。
  • 「手順を前もって決めて、その通りに進める」: これはワークフローの説明です。

関連する基礎知識

公式の情報

論点 4エージェント開発

MCP の stdio は「同じパソコンで1人が使う」形に向く

覚えること

  • stdio: AI アプリが MCP サーバーを子プロセスとして起動し、標準入出力でやりとりする
  • 同じパソコンの上で、1つのクライアントが使う形に向く（ネットワークの設定が要らない）
  • 離れた場所・複数の利用者・利用者ごとの認証・台数を増やす構成は Streamable HTTP

解説

MCP の通信の方式（トランスポート）には、stdio と Streamable HTTP があります。stdio はクライアントが起動した子プロセスとの通信なので、クライアントとサーバーが同じ機械の上にあることが前提です。

複数の利用者が同時に使うサービス、利用者ごとに OAuth で認証する公開のサーバー、ロードバランサーの後ろで台数を増やす構成には、HTTP の方式を使います。

よくある誤解

  • 「マルチテナント・公開・水平スケールにも stdio」: stdio は子プロセスとの通信なので、離れた場所からの接続や、複数の利用者での共有には向きません。

関連する基礎知識

公式の情報

論点 5エージェント開発

コンテキストの汚染は、サブエージェントで分けて防ぐ

覚えること

  • 関係のないツールの結果がたまると、エージェントの集中力（精度）が落ちる
  • 独立した調べものはサブエージェントに任せ、要約だけを返してもらう
  • コンテキストウィンドウを広げても、汚染の問題は解決しない

解説

サブエージェントは自分のコンテキストでツールを使い、大量の検索結果やログを処理して、要約だけを元のエージェントに返します。元のエージェントのコンテキストは小さいまま保たれ、トークンの増加も抑えられます。

Anthropic も、コンテキストは限りがあり、増えるほど効き目が下がる資源だとしています。ウィンドウの大きさにかかわらず汚染は起こりうるので、容量ではなく中身の質の問題として扱います。

よくある誤解

  • 「ウィンドウを広げればよい」: 入る量は増えますが、関係のない情報は残り、トークンも増え続けます。
  • 「ツールの結果を返さないようにする」: 調べものに必要な情報が得られず、仕事になりません。
  • 「複数の調べものを1つのプロンプトにまとめる」: 情報がさらに混ざり、汚染が悪化します。

関連する基礎知識

公式の情報

← Claude 認定デベロッパー（Foundations）のページに戻る