ServiceDock
2026年8月17日 更新
約4分で読めます
エージェントを作るためのSDKが各社から出ています。どれを選ぶべきか迷うところですが、その前にSDKが何を肩代わりしてくれるのかを把握しておく必要があります。
今回は数えました。エージェントを動かすのに必要な処理を列挙して、SDKが持つものと自分で書くものに分けています。結果を先に言うと、10項目中7つは肩代わりされ、3つは残りました。
エージェントを動かすための繰り返し処理を肩代わりします。ツールを呼んで結果を戻し、終わりを判定する部分です。
Agents SDKが担うのは、エージェントを動かす繰り返しの処理です。この部分はどの実装でもほぼ同じ形になるため、共通化する価値があります。
エージェントの動作は、単純な繰り返しでできています。AIに聞く、ツールを呼べと言われたら呼ぶ、結果を戻してまた聞く、終わりと言われたら止める。この往復を管理するのがSDKの中心的な役割です。
そこに周辺の処理が付きます。応答が失敗したときの再試行、待ち時間の調整、逐次表示のための処理などです。
Anthropicは、多くのチームを見た経験として、成功している実装は複雑な枠組みではなく、単純で組み合わせやすい形を使っていると述べています。
SDKの選定でも同じ観点が使えます。機能が多いことより、必要な部分だけ使えて、要らない部分を避けられるかが実務では効きます。
呼び出しを補助するだけの薄いSDKと、構成そのものを規定する厚い枠組みがあります。後者は書き方が固定される代わりに、そこから外れる要件が出たときに苦労します。どちらを採用しているかは意識しておく価値があると編集部は考えています。
the most successful implementations use simple, composable patterns rather than complex frameworks原文Anthropic Engineering「Building effective agents」 この内容の有効期限2027-02-17
エージェントに必要な処理を列挙して分類しました。配管は肩代わりされますが、業務にあたる3項目は残ります。
Agents SDKの効果を確かめるため、必要な処理を列挙して分類しました。SDKが持つものと、自分にしか書けないものに分けています。
エージェントを動かすのに必要な処理の内訳 SDKが持つ 会話履歴の保持 どのSDKも持つ SDKが持つ ツール定義の受け渡し 形式が決まっている SDKが持つ ツール呼び出しの検出 応答の解釈 SDKが持つ ツールの実行と結果返却 ループの中核 SDKが持つ 停止条件の判定 無限ループを防ぐ SDKが持つ 再試行と待機 レート制限への対応 SDKが持つ ストリーミングの処理 逐次表示 自分で書く 業務ルールの実装 自分にしか書けない 自分で書く ツールの中身 自分にしか書けない 自分で書く 権限の設計 自分にしか書けない SDKが肩代わりする範囲: 7 / 10 項目（70%） 自分で書く範囲 : 3 / 10 項目（30%）
分かれました。7項目と3項目です。肩代わりされる7項目には共通点があります。どれも業務の内容と関係がない処理だ、という点です。
一方、残る3項目はどのSDKを選んでも書くことになります。業務ルール、ツールの中身、権限の設計。いずれも自分の業務を知らないと書けません。
そして、エージェントの答えの質を決めるのはこの3つです。ツールの説明が曖昧なら選択を誤り、権限が広すぎれば事故が起きます。SDKを変えてもここは改善しません。
肩代わりされる7項目のうち、最初の5つはそれほど大きな実装ではありません。再試行とストリーミングを除けば、自前で書ける範囲です。
Anthropicの推奨も、可能な限り単純な解から始めることでした。SDKを入れる前に、必要な処理だけ書いてみるという順序も現実的です。
SDKで減るのは配管の7項目。品質を決める3項目は残る。
we recommend finding the simplest solution possible, and only increasing complexity when needed原文Anthropic Engineering「Building effective agents」 この内容の有効期限2027-02-17
機能の多さではなく、後から抜けられるかで選びます。前の節で見たとおり、品質を決める部分はSDKの外にあるためです。
Agents SDKの選定では、比較表の機能欄を見比べたくなります。ただ前の節で見たとおり、品質を決める3項目はどのSDKを選んでも自分で書きます。
3番目が実務では重要です。エージェントの周辺は変化が速いので、1年後も同じSDKを使っているとは限りません。移りやすさを見ておくと、あとで助かります。
判断の目安は、業務ルールとツールの中身が、SDKと切り離して書けているかです。ここがSDK固有の書き方に埋め込まれていると、乗り換えのたびに書き直しになります。
逆に、ツールを普通の関数として書き、SDKからはそれを呼ぶだけの形にしておけば、SDKを差し替えても中身はそのまま使えます。
対応で候補を絞り、依存度で選ぶ。機能の多さは判断材料にしない。
手順が決まっている業務なら、エージェントの仕組み自体が不要な場合もあります。詳しくは決定的ワークフローの記事で扱っています。
Anthropicも、エージェント的なシステムは応答の速さと費用を性能と引き換えにしていると述べたうえで、その引き換えが見合う場面かを考えるよう促しています。SDKの選定は、その判断のあとに来ます。
Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.原文Anthropic Engineering「Building effective agents」 この内容の有効期限2027-02-17
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る