Anthropic のこの記事は、Claude Code SDK を Claude Agent SDK へ改称することを発表し、新しい名前の理由を論じている。その主張は、Anthropic が当初は開発者の生産性のために作った Claude Code が、コーディングツールをはるかに超えるものになったというものである。Anthropic は、社内でディープリサーチ、動画制作、ノート作成に Claude Code を使っていると報告し、同社の主要なエージェントループのほぼすべてを Claude Code が動かすようになり始めたと述べている。したがって、その下にあるハーネスは他の多くの種類のエージェントも動かすことができ、改称はそうしたより広い適用範囲を反映したものとして提示されている。
記事の中心的な設計原則は、エージェントにコンピュータを与えることである。Claude Code がうまく機能するのは、プログラマーが日々使うツール、つまりファイルを探す、ファイルを書いて編集する、リンティングする、コードを実行してデバッグする、コードが成功するまで反復するといったツールを Claude が持っているからであり、記事は、ターミナルへの同じアクセスこそが、コーディング以外のデジタル作業でも Claude を有効にしているのだと論じる。そのうえで記事は、このように構築されたあらゆるエージェントについての考え方として、コンテキストの収集 → アクションの実行 → 作業の検証 → 繰り返し というフィードバックループを提案し、SDK 上でメールエージェントをどう構築しうるかをスケッチしながら、全体を通してそれを例示している。
要点
- Claude Code を動かしているエージェントハーネスは他の種類のエージェントも動かせるため、Claude Code SDK は Claude Agent SDK へ改称される。記事は例として、金融、パーソナルアシスタント、カスタマーサポート、ディープリサーチのエージェントを挙げている。
- 設計上の重要な原則は、エージェントが人間と同じように作業できるよう、エージェントにコンピュータを与えること、つまり bash コマンドを実行し、ファイルを編集・作成・検索できるようにすることである。
- エージェントはしばしば、コンテキストの収集、アクションの実行、作業の検証というループで動作し、このループは、エージェントにどの能力を与えるべきかを判断するための方法として提示されている。
- コンテキストの収集においては、エージェントが作業するフォルダとファイルの構造が コンテキストエンジニアリング の一形態になる。エージェントは
grepやtailのようなツールを使って、大きなファイルをどう読み込むかを自ら決める。記事はこれを エージェント型検索 と呼んでいる。 - セマンティック検索は、エージェント型検索より通常は高速だが、精度が低く、保守が難しく、透明性も低いと説明されている。記事は、まずエージェント型検索から始め、より高速な結果やより多くのバリエーションが必要になった場合にのみセマンティック検索を加えることを勧めている。これは Anthropic の推奨であり、測定された比較ではない。
- サブエージェントはデフォルトでサポートされており、2 つの理由で有用である。並列化と、コンテキストの管理である。各サブエージェントは独立した自分のコンテキストウィンドウを使い、関連する情報だけをオーケストレーターに送り返すからである(サブエージェントアーキテクチャ を参照)。
- SDK のコンパクト機能は、コンテキストの上限が近づくと以前のメッセージを自動的に要約するもので、Claude Code の
/compactスラッシュコマンドを基盤にしている(コンパクション を参照)。 - ツールは Claude のコンテキストウィンドウの中で目立つ位置を占めており、そのため Claude が検討する主要なアクションとなる。したがって記事は、ツールをエージェントの主要かつ最も頻繁なアクションとして、コンテキスト効率を考えて意図的に設計するよう助言している。
- コードは正確で、組み合わせ可能で、再利用可能であるため、コード生成はエージェントに適している。記事は例として、Claude.ai のファイル作成機能を挙げている。これは完全に、Claude が Python スクリプトを書くことに依拠している。
- Model Context Protocol のサーバーは、認証と API 呼び出しを処理して外部サービスとの標準化された統合を提供するため、エージェントはカスタムの統合コードなしに Slack や Asana のようなサービスを利用できる。
- 自分の出力を確認して改善できるエージェントは、根本的に信頼性が高いものとして提示されている。記事は 3 つの検証アプローチを挙げている。どのルールがなぜ失敗したかをフィードバックする明確に定義されたルール(例としてコードのリンティングを挙げ、フィードバックの層が増えることから、素の JavaScript よりもリンティングされた TypeScript を推奨している)、スクリーンショットやレンダリング結果による視覚的フィードバック、そして LLM-as-a-Judge である。LLM-as-a-Judge について記事は、一般にあまり堅牢ではなくレイテンシーのコストも大きいが、わずかでも性能が向上するならコストに見合う場面では役に立つとしている。
- エージェントを改善するために、記事はその出力、とりわけ失敗を注意深く読み、エージェントが適切なツールを持っているかを問うことを勧めている。機能を追加するにつれて性能がばらつく場合には、顧客の利用状況に基づいて、プログラムによる評価のための代表的なテストセットを構築することを勧めている。
背景
この記事は、効果的なエージェントの構築に関する Anthropic の以前の文章の続編として位置づけられており、その推奨事項は、比較研究の結果ではなく、Anthropic 自身のチームが SDK をデプロイする中で生まれたベストプラクティスである。また、ベンダーが自社製品について説明したものでもあるため、SDK によって何が容易になるかについての主張はベンダー自身のものである。記事は、Claude Code がモデルの周囲に提供するものを「エージェントハーネス」と呼び(エージェントハーネス を参照)、SDK をそのハーネスを他のエージェントに引き渡す手段として扱っている。