Claude Agent SDKとStrands Agentsの違い — 認証・ツール・観測

Claude Agent SDKは、Claude Codeのエージェントを自分のPython・TypeScriptアプリに組み込むためのライブラリです。Strands Agentsは、AWS発のオープンソースで、モデルを差し替えられるエージェント基盤です。同じ「エージェントを作る道具」でも、ループを誰が持つか、認証をどう通すか、観測をどこで取るかが大きく違います。

Bedrock経由でClaudeを動かす場合、どちらでも同じモデルに届きます。差が出るのは、その手前の設計です。この記事では、認証・ツール・権限・マルチエージェント・セッション・観測の6点で両者を並べます。

結論: 何を組み込みたいかで分かれる

Agent SDKの概要ページでは、このSDKを「Claude Codeのバイナリを動かすライブラリ」と位置づけています。ファイルの読み書きやコマンド実行といった組み込みツールが最初から付いてきます。

Strandsは、自分のプロセス内で動くライブラリとして説明されています。ホスト型の管理基盤は持たず、Amazon Bedrock・Anthropic・OpenAI・Google・Ollamaなどを同じエージェントコードで使えます。

呼び名にも注意が要ります。Strandsは今、2層に分かれています。

• Strands harness: 組み立て済みのエージェント。Pythonはstrands-harness、TypeScriptは@strands-agents/harness
• Strands Harness SDK: ループから自分で組む層。Pythonはstrands-agents、TypeScriptは@strands-agents/sdk

Agent SDKに近い位置にあるのは、組み立て済みのStrands harnessです。ただしharnessは0.x系の製品で、既定値は今後変わる前提と説明されています。

認証: Claude側はClaudeの経路、Strands側はモデルごとの経路

認証は、いちばん早く差が出る部分です。

Agent SDKは、ANTHROPIC_API_KEYを通す方法が基本です。クラウド経由では、環境変数で経路を切り替えます。

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-west-2
python agent.py

このスクリプトのagent.pyでは、Agent SDKのquery()をいつも通りに呼びます。コードはAPIキー版と変わらず、経路は環境変数だけで決まります。Bedrockの認証経路そのものは、Claude in Amazon Bedrockの認証3経路にまとめています。

Agent SDKには、認証まわりで見落としやすい注意が1つあります。Anthropicの許可を得ていないサードパーティが、自社製品でclaude.aiのログインやレート制限を提供することは認められていません。製品に組み込むなら、APIキー方式を使います。

Strandsはモデル提供元ごとに認証が分かれます。Bedrockは既定のプロバイダーで、AWS SDK(Pythonではboto3)の認証情報の解決順に従います。環境変数ならAWS_ACCESS_KEY_ID・AWS_SECRET_ACCESS_KEY、リージョンはAWS_REGIONなどです。

リージョンの解決には順序があります。BedrockModel(region_name=...)の指定、boto3セッション(AWS_DEFAULT_REGIONやプロファイル)、AWS_REGION、そして既定のus-west-2の順です。AWS_REGIONはプロファイルの設定より弱いので、意図と違うリージョンに飛ぶときはここを疑います。

Anthropicに直接つなぐときは、追加の依存を入れます。

pip install 'strands-agents[anthropic]'

from strands import Agent
from strands.models.anthropic import AnthropicModel
 
model = AnthropicModel(
    client_args={"api_key": "<KEY>"},
    max_tokens=1028,
    model_id="claude-sonnet-5",
)
agent = Agent(model=model)

これはStrandsのAnthropicプロバイダーのドキュメントにある書き方に沿った例です。実際には<KEY>を直書きせず、環境変数から渡します。

要するに、Agent SDKは「Claudeをどのクラウドで呼ぶか」を環境変数1つで選びます。Strandsは「どのモデル提供元を使うか」をコードで選びます。Claudeだけを使うなら前者が単純で、Claudeと他社モデルを同じコードで切り替えたいなら後者です。

ツール: 最初から持っているか、自分で渡すか

Agent SDKは、ファイルの読み書き、コマンド実行、Web検索といった組み込みツールを備えています。自作ツールは、@tool(Python)やtool()(TypeScript)で定義し、create_sdk_mcp_serverで包んでmcpServersに渡します。サーバーは自分のプロセス内で動きます。

不要な組み込みツールはtools配列で絞れます。自動承認したいものはallowed_toolsに入れます。

Strands Harness SDKのツールは、@toolデコレーターが基本です。スキーマは型ヒントとdocstringから作られます。

from strands import Agent, tool
 
@tool
def search_docs(query: str) -> str:
    """Search the documentation."""
    return index.search(query)
 
agent = Agent(model="global.anthropic.claude-sonnet-5", tools=[search_docs])
agent("Find the pricing guide")

Strands公式の最小例です。Harness SDKでは何も事前に決まっておらず、ツールは渡したものだけになります。

組み立て済みのStrands harnessは、シェル、read・write・edit、Webアクセスを既定で持ちます。つまりharness同士で見ると、ツールの出発点はAgent SDKとほぼ同じです。違いは持ち込み方で、Agent SDKはClaude Codeの機能を継承し、harnessは自前の既定値で組んでいます。

MCPはどちらも使えます。Agent SDKではmcpServersで、Strands harnessではmcpServers設定(JSONファイルのパスまたは設定の対応表)で渡します。Strandsの接続に失敗したサーバーは、クラッシュではなく「ツールが付かない」扱いになります。この挙動は気づきにくいので、起動後にツール一覧を確かめておく価値があります。

権限: 既定で止まるか、既定で通るか

ここは違いが最も運用に響きます。

Agent SDKの権限は、順に評価されます。最初にフック、次に拒否ルール、確認ルール、権限モードと進みます。拒否ルールに当たれば、bypassPermissionsでもツールは止まります。承認が必要な呼び出しは、自分で用意したcanUseToolコールバックに回ります。

モードにはdefault・dontAsk・acceptEdits・bypassPermissions・plan・autoがあります。フックの使い方はAgent SDKのHooksにまとめています。

Strands harnessは逆の出発点です。interventionsを指定しなければ何も止めず、すべてのツール呼び出しが通ります。ゲートをかけるには、次のように指定します。

from strands_harness import create_harness
 
agent = create_harness(interventions="ask")    # 全ツール呼び出しを承認制にする
agent = create_harness(interventions="smart")  # リスク判定で危ない呼び出しだけ止める

"ask"は全呼び出しを止め、"smart"はリスク分類器で危険な呼び出しだけを止めます。自然文のルールやCedarポリシーも渡せます。

Claude Agent SDKを使う側では、dontAskやallowed_toolsで「許可したもの以外は通さない」形に寄せられます。Strands側では、意識してinterventionsを足さない限り、通る方が既定です。同じ「エージェントを本番に出す」でも、最初に確認する場所が逆になります。

セッション: ローカルのファイルか、IDで指すディレクトリか

Agent SDKのセッションは、実行したマシンのディスクに残ります。続きから再開するにはcontinue_conversation、特定のセッションならresumeにIDを渡します。過去の会話をコピーして別の分岐を試すforkもあります。

ここに落とし穴があります。セッションファイルは作ったマシンに閉じています。CIのワーカーやコンテナ、サーバーレスで再開するには、session_storeアダプターで自前のバックエンドに写すか、ファイルを運ぶ必要があります。ディスクに残したくない処理には、TypeScriptのpersistSession: falseがあります。

Strands harnessも、セッションは既定でオンです。session={"id": "refactor-parser"}のようにIDを渡すと、会話をディスクに保存し、同じIDで作り直したときに復元します。保存先は./.agent配下のディレクトリが既定です。

コンテナやサーバーレスでは、この保存先が使い捨てになりえます。長期メモリも含め、session={"dir": ...}やmemory={"dir": ...}を永続ストレージに向ける必要があります。

どちらも「ローカルに書く」点は同じで、本番でそれが消える点も同じです。どちらを選んでも、永続化先を設計する作業は残ります。

観測: 子プロセスが出すか、エージェント自身が出すか

観測の持ち方は、アーキテクチャの違いがそのまま出る部分です。

Agent SDK自身はテレメトリーを作りません。Claude Codeを子プロセスとして動かし、そのCLIに組み込まれたOpenTelemetryが、モデル呼び出しやツール実行のスパン、トークンやコストのメトリクス、プロンプトやツール結果のログイベントを出力します。

設定は環境変数で渡します。

export OTEL_TRACES_EXPORTER=otlp
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4318

トレースはベータ扱いで、CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1も必要です。TypeScriptでoptions.envに値を渡すと、継承されている環境が置き換わります。...process.envを一緒に渡さないと、PATHやANTHROPIC_API_KEYが消えます。エクスポートの失敗は既定では黙って捨てられるので、コレクター側で実際にスパンが届いたかを確認します。

StrandsはエージェントのSDKにテレメトリーが埋め込まれています。トレース・メトリクス・ログの3系統を、標準のOpenTelemetryで出します。OTLPに送るには、追加の依存を入れます。

pip install 'strands-agents[otel]'
export OTEL_EXPORTER_OTLP_ENDPOINT="http://collector.example.com:4318"

from strands.telemetry import StrandsTelemetry
 
strands_telemetry = StrandsTelemetry()
strands_telemetry.setup_otlp_exporter()      # OTLPエンドポイントへ送る
strands_telemetry.setup_console_exporter()   # 開発中はコンソールにも出す

Strands harnessが返すのは通常のAgentなので、このテレメトリー設定がそのまま使えます。harnessだけの設定は要りません。

観測の違いは次の1行にまとまります。Agent SDKで見えるのは「Claude Codeの内側の動き」で、Strandsで見えるのは「自分で組んだエージェントの動き」です。送り先をOTLP対応のコレクターに揃えれば、両者のデータを同じ観測基盤に集められます。

マルチエージェント: サブエージェントか、グラフ・スウォームか

複数のエージェントを組むときも、出発点が違います。

Agent SDKでは、メインのエージェントがAgentツールでサブエージェントを呼びます。agentsパラメーターでdescription・prompt・tools・modelを持つ定義を渡す形が推奨で、.claude/agents/のmarkdownファイルでも定義できます。サブエージェントは独立した会話で動き、途中のツール呼び出しや結果は親に戻らず、最後のメッセージだけが返ります。複数を並列で走らせることも、toolsで権限を絞ることもできます。

サブエージェントがさらにサブエージェントを呼ぶ入れ子も可能です。深さはCLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTHで、同時実行数はCLAUDE_CODE_MAX_CONCURRENT_SUBAGENTSで上限を決めます。既定は深さ3層、同時20個です。

Strandsは、組み方そのものを選ぶ作りです。

Strandsの比較ページは、これらの最大の違いを「実行の経路をどう決めるか」だと説明しています。GraphとSwarmは循環を持てますが、Workflowは持てません。Swarmには引き継ぎ回数の上限(max_handoffs、既定20)があります。

Agent SDKのサブエージェントは、Strandsで言えば「Agents as tools」に最も近い形です。親が必要に応じて子へ委ねる階層型で、経路を図として固定することはしません。「この順序で必ずこの節を通す」という保証が要る業務フローは、StrandsのGraphやWorkflowの領分です。逆に、ファイルを読んで直す単位で作業を切り分けるだけなら、Agent SDKのサブエージェントで足ります。

使い分けの早見表

Agent SDKが向くのは、Claude Codeのファイル操作や権限の仕組みをそのまま製品に持ち込みたい場合です。コードレビューや修正を自動で回すエージェントがこれに当たります。

Strandsが向くのは、Bedrock上で複数のモデル提供元を切り替えたい場合や、既にAWSのサービスに寄せている場合です。モデルの差し替えを前提にするなら、Strandsの方が書き直しは少なく済みます。

Claude Agent SDKを他の選択肢と比べたい場合は、OpenAI Agents SDKとの比較とLangGraphとの比較が参考になります。BedrockとGoogle Cloudでのモデル機能の差は、API機能の対応差にあります。

乗り換えや併用で引っかかる点

Agent SDKからStrandsへ移すとき、いちばん抜け落ちやすいのは、Claude Codeが裏で自動的にやってくれていた部分です。CLAUDE.mdやスキルを、プロジェクトの.claude/から自動で読む挙動はAgent SDKの特徴です。Strands harnessもスキルの読み込みとAGENTS.mdの注入に対応しますが、読み込み先の設定は別物なので、どの指示が効いているかを確かめ直します。

逆にStrandsからAgent SDKへ移すと、モデルの選択肢が狭まります。他社モデルを併用していた処理は、書き直しが必要です。

もう1つ、ストレージです。どちらも既定はローカルディスクなので、移行後に「再開できない」と感じたら、永続化先の設定を先に疑います。

どちらにも向く安全策が1つあります。本番に出す前に、実際に何のツールが呼ばれたかをトレースで確かめることです。エージェントが想定外のコマンドを実行した後で、権限の設計を見直すのは遅すぎます。