種類の違うLLMのシステムを、いくつも作ってきた。社内文書を検索して答えさせるもの、テキストから3次元モデルを作るもの、自作のディープリサーチ。同じ「LLMに任せる仕組み」でも、どれも作りが違う。
作り分けは、2つの問いで決まる。1つは、どこまでモデルに任せるか。もう1つは、任せると決めたあと、次の一手を回す仕組みと、道具が動く場所を、自分で持つか提供元に預けるか。前半で1つ目を4段階として、後半で2つ目をエージェントの作り方4通りとして書く。
LLM活用の4段階
1番は、ChatGPTやClaude、Geminiのチャット画面をそのまま使うことを指す。自分ひとりが、その都度開いて使う形だ。良し悪しではなく用途が違う。自動化の仕組みを作るなら、2番以降になる。
下に行くほど、できることの複雑さと柔軟性が上がる。そのぶん、動きは読みにくくなる。
どこまで降りるかは要件で決まる。単発で足りるなら2で止める。手順が書き切れるなら3で止める。書き切れないときだけ4に降りる。降りるほど偉いわけではない。降りるほど、動かす前に正しさを確かめる手段が減る。
ワークフローとエージェントは何が違うのか
3番と4番の境目だけ、言葉が混ざりやすい。Anthropicが公開している「Building Effective Agents」（2024年12月）に、次の区別がある。
Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.
拙訳：ワークフローは、LLMと道具が、あらかじめ書かれたコードの経路にそって組み立てられるシステム。エージェントは、LLMが自分の進め方と道具の使い方を実行時に決め、どう達成するかの主導権を持つシステム。（出典：https://www.anthropic.com/engineering/building-effective-agents ）
この記事では、この区別に沿って書く。
この定義で効いてくるのは、モデルが選ぶかどうかではなく、経路が先に書かれているかだ。だから、モデルに選択肢から選ばせる作りはワークフローに入る。入力を分類して対応する処理へ振り分ける形は同じ文書で「ルーティング」と名前が付いていて、連鎖・並列・分担・評価と並ぶワークフローの型の1つとして数えられている。分岐はコードに書かれていて、モデルはそのどれを通るかを選んでいるだけだからだ。
自分に聞く形にすると、こうなる。書き始める前に、実行の経路を全部描けるか。 描けるならワークフロー。描けない、実行してみるまで形が決まらない、というときだけエージェントになる。
エージェントにするかどうかは、4つで判断できる。
- 手順を事前に書き切れないほど複雑か
- かかる時間と費用に見合う結果か
- そもそもモデルが得意な種類の仕事か
- 歯止めを付けたうえで、まだ任せる価値があるか
1つでも欠けるなら、単純なほうに留める。
4つ目に関しては、ファイルの変更ならバージョン管理に差分が残るので、そのままでも見つけて戻せる。メールの送信、外部への書き込み、課金、データの削除は戻せない。ただし、戻せないから任せない、とはならない。実務では歯止めを付けて任せている。金額に上限を置く、送信先を限定する、下書きまでで止めて人が出す、消す前に控えを取る。
そして歯止めは、たいてい付けられる。 最後に人が確認する形にすれば、どんな仕事でも止められるからだ。だから4つ目は「付けられるか」ではなく、付けたうえで、まだ任せる価値が残るかになる。1回動かすたびに人が全部見るなら、任せた意味はほとんど残らない。そのときは、任せる範囲を狭めるほうが早い。危ないところだけ人が押す形に切り出せば、残りは経路が書ける単位になることが多い。
私はこれまで、Claude Codeを使って、スライドや動画、3次元モデルの作成といった仕組みを作ってきたが、これらはエージェントを使った仕組みということになる。やらせる中身は違っても、次に何をするかはClaude Codeが実行時に決めていて、こちらのコードに経路は書かれていないからだ。
境界にあるのが、自作のディープリサーチだ。調べる角度は固定していて、深さだけを途中の結果を見て伸ばす。手順は書き切れているが、どこまでやるかは実行のたびに変わる。呼ぶなら「適応的なワークフロー」で、エージェントではない。
二分法への反論
この線引きには、まっとうな反論がある。自律の度合いは連続量であって、ワークフローとエージェントの2つに割るのは雑だ、というものだ。実際そのとおりで、途中に何段階も置ける。どの道具を使うかだけモデルに選ばせて順番は固定する、繰り返す回数だけモデルに決めさせる、といった作りはいくらでもある。上に書いたディープリサーチがまさにそれだ。
ここで引っかかるのが、作り込みとの関係だ。ワークフローをどこまでも作り込んでいけば、いつかエージェントになるのか。
ならない。エージェントのコードは、作り込んだワークフローより単純になることが多い。 ループは「道具を呼べと言われたら実行して結果を返す」の繰り返しで、数行で書ける。複雑なのはコードではなく、実行のたびにモデルが立てる段取りのほうだ。Claude Codeのような道具も、コードとして持っているのは道具の一式とループと文脈の管理で、「ファイルを読んでから直してテストを走らせる」という順番はコードに書かれていない。順番は毎回モデルが決める。
だから、作り込みの量では線が引けない。引けるのは実行の前に経路を数え上げられるかで、数え上げられるなら分岐が1000本あってもワークフローのままだ。
割る位置が決まれば、割る意味もはっきりする。割った位置で、作るものと壊れ方が変わるからだ。
手順を書き切れる側では、テストが書ける。入力に対する出力が決まっているので、想定外が来たら止まる。止まるのは良い性質で、直す場所も分かる。
手順を書き切れない側では、テストが書けない。動くたびに経路が変わるので、正しさを事前に確かめられない。代わりに要るのは、あとから気づく仕組みだ。差分が見えること、元に戻せること、何をしたかの記録が残ること。作るものが根本的に変わる。
だから連続量として眺めるのは理解のためには正しいが、手を動かすときには「手順を書き切れるか」で一度割ったほうが決めやすい。連続量のどこに自分がいるかを議論するより、書き切れるか書き切れないかを自分に聞くほうが速い。
エージェントにすると、うまくいったときの上限は上がるが、外れたときの下限も下がる。だから4番目の条件が効く。テストがある、差分が見える、元に戻せる。この3つが揃っている場所はそのまま置ける。揃わない場所でも、下がる下限に床を張れるなら置ける。損害の大きさを先に決めておく、というのが床の意味だ。
どこで止めるかを決める
ここまでが前半だ。4段階のどこで止めるかは、上から順に聞いていけば決まる。
止まったところが作るものになる。番号は最初の4段階と同じだ。最後の問いだけ行き先が違う。歯止めを付けても割に合わないときは、任せる範囲そのものを狭める。危ないところを切り出して人が押す形にすれば、残りは経路が書ける単位になり、3に落ちてくることが多い。
エージェントまで降りたときだけ、後半の話が要る。
エージェントにすると決めたら
ここで、やることが2つに分かれる。
1つは、コーディングエージェントをそのまま使うこと。Claude CodeやCodexのコマンドを開いて、自分が指示しながら仕事をさせる。ここでいうコーディングエージェントは、端末で動いてファイルの読み書きやコマンドの実行まで自分でやる種類のものを指す。チャットの中で完結する使い方と区別するために、こう呼び分けておく。
もう1つは、用途を決めた仕組みを作ること。たとえば動画を作る仕組みのように、材料と段取りをこちらで用意しておいて、実行をコーディングエージェントに任せる。毎回同じ指示を書かずに済み、決めた時刻に動かすこともできる。
どちらも、自分の契約の枠の中で動かすなら、いちばん手が少ない。作るまでが速く、費用も契約の中に収まる。
走らせる場所は、手元のマシンでなくてもいい。提供元のクラウド側にセッションを作って、そこで同じものを動かす道もある。保存しておいた環境の設定（ネットワークの許可、環境変数、準備のコマンド）の中で動く形だ。手元が空くので、長い作業や、外から投げる使い方に向く。
ここで、2つのことが別々に決まると分かる。動く場所が手元か外かと、費用が定額か使った分かだ。クラウドのセッションは、場所は外だが、費用は契約の枠の中に収まる。このあと出てくる作り方4通りも、APIキーで動かすなら使った分だが、エージェントSDKのように自分の契約の認証で動かせるものもある。費用の出方を決めるのは作りではなく、どの認証で動かすかだ。場所の話と費用の話を一緒にすると、ここで混乱する。
ただし、手元でもクラウドでも、これは自分しか使えない。 どちらも自分の契約に紐づいていて、動かす人それぞれが自分の契約とログインを持っていないと動かない。
配るときに引っかかるのは認証だ。自分の契約で動かすのと、利用者それぞれの契約で動かすのと、APIキーで動かすのとでは、条件が違う。 たとえばAnthropicのSDKの説明には、事前の承認がある場合を除いて、作ったものの利用者にclaude.aiのログインや枠を使わせることは認めていない、と書かれている。一方で、契約の認証で動かすSDKの使い方を案内している文書もある。書き方が変わってきている場所なので、配る前に最新の条件を確かめる。
同じ仕組みを複数人で使いたい、人に配りたい、納品したい、サービスとして出したい。そうなった時点で、枠の外に出るかどうかを決めることになる。
ここから先が、その外側の話だ。
作り方4通り
外に出ると、作り方は4つに分かれる。見るのは3つの持ち分だ。次の一手を回すループを誰が持つか。道具が動く場所を誰が用意するか。使う道具が最初から入っているか。
| # | 方法（例） | 自分が書くもの | これを選ぶ理由 |
|---|---|---|---|
| 1 |
自作ループ 自分でループを書く |
ループ全部。道具を呼べと言われたら実行して結果を返し、また呼ぶ、の繰り返し | 打ち切り方、順序、失敗したときの動き、記録の残し方まで、全部を自分で決めたい |
| 2 |
ツールランナー 提供元のSDKに入っている （例：AnthropicのSDK） |
道具の中身だけ。呼び出しの往復はSDKが回す | 使わせる道具を絞りたい。実行前の承認や、失敗の差し替えを1回ごとに挟みたい |
| 3 |
エージェントSDK コーディングエージェントの仕組みごと （例：Claude Agent SDK） |
プロンプトと設定だけ。ファイルの読み書き、コマンド実行、検索は最初から入っている | ファイルの読み書きやコマンド実行まで、まるごと任せたい |
| 4 |
マネージド 提供元に預ける （例：Managed Agents） |
エージェントの設定。保存されて版が付く | 実行環境を持ちたくない。実行のたびに専用の環境が要る。決めた時刻に動かしたい |
SDKはSoftware Development Kitの略で、そのサービスを自分のプログラムから呼ぶための部品一式のことだ。提供元が配っていて、これを入れると通信や形式の細かいところを自分で書かずに済む。
持ち分で見ると、こうなる。
実行環境の軸は、物理的にどこで動くかではなく、誰が用意して誰が払うかで見ている。自分のマシンでも、借りたサーバでも、GitHubのランナーでも、用意するのが自分なら同じ側だ。提供元が勝手に立ち上げて、こちらは何も用意しない形だけが反対側になる。
自作ループ、ツールランナー、エージェントSDKは、どれも動かす場所を用意してくれない。置き場ごと預けられるのはマネージドだけだ（そのマネージドにも、実行環境を自前で立てる構成が用意されている）。「SDKを使えば環境も込み」と考えていると、動かす場所をどこに置くかが見積もりから抜ける。
自作ループとツールランナー：どこが分かれ目か
APIはモデルに話しかけるための口そのもので、SDKはその口を自分の言語から叩くための部品一式だ。SDKの中ではAPIを呼んでいる。だから自作ループでもSDKを使ってかまわない。分かれ目は道具ではなく、ループを自分で書くかどうかにある。
自分で書く利点は、ループの中身を全部決められることだ。
- 何回で打ち切るか
- どの順で呼ぶか
- 失敗したときに何をするか
- 何を記録に残すか
出来合いのループに乗ると、この形に合わせることになる。試験的な機能に依存しないので壊れにくい、という利点もある。とはいえ、たいていはツールランナーで足りる。
ツールランナーとエージェントSDK：強いほうを選ばない理由
ツールランナーとエージェントSDKは、どちらもSDKという名前が付いていて紛らわしいが別物だ。前者は普通のSDKに入っている補助輪で、道具は全部自分で用意する。後者はコーディングエージェントの仕組みごと持ってきたもので、道具が最初から入っている。
エージェントSDKのほうが強力なのに、ツールランナーを選ぶ理由があるのか。ある。
| ツールランナー | エージェントSDK | |
|---|---|---|
| 道具 | 自分が用意したものだけが入る | ファイル操作やコマンド実行が最初から入っていて、そこから選んで絞る |
| 文脈の管理 | 自分で組む | 長い作業のための仕組みが入っている |
| 向く仕事 | 渡す道具を数えられる状態にしたい | 手を動かす作業をまるごと任せたい |
どちらも、使わせる道具を限ったり、実行の前に人の承認を挟んだりはできる。違いは「絞れるかどうか」ではなく、「最初から入っているものを使うかどうか」だ。
社内の検索とデータベースの照会だけを渡す、という仕事なら、道具を自分で書くツールランナーのほうが見通しがいい。ファイルとコマンドを使う作業を任せるなら、最初から入っているエージェントSDKが速い。自分が用意した道具だけで足りるならツールランナー、手を動かす作業ごと渡すならエージェントSDK、という分かれ方になる。
外部のフレームワークはどこに入るか
提供元のSDK以外に、外部のフレームワークを使う道もある。エージェントを作るための部品と作法をひとそろいにしたもので、こちらもこの表のどこかに入る。
- ループはフレームワークが持ち、置き場は自分（LangChain、LangGraphなど）…… ツールランナーと同じ場所
- 道具まで最初から入っていて、置き場は自分（OpenClaw、Hermes Agentなど）…… エージェントSDKと同じ場所
- 上のどちらも、作り手が実行環境まで預かる形を用意していることがある（LangSmithのDeploy to Cloudなど）…… それを使うならマネージド
名前も並びも入れ替わりが速い。覚えるなら個々の製品ではなく、ループと実行環境を誰が持つかのほうだ。
先に引いたAnthropicの文書には、こうしたフレームワークについての助言もある。まずAPIを直接使い、必要になってから入れる。使うなら、中で何が起きているかを把握しておく。 中身の想像がずれたまま使うのが、よくある失敗の元になる、という話だ。
身近な道具はどこに入るか
すでに出来上がっていて、名前を呼べば動く道具もある。この表のどこに入るのかを見ておくと、違いが分かりやすい。
GitHubのイシューやプルリクエストで名前を呼ぶと動くもの、たとえば本文に@claudeと書くと作業を始める形は、コーディングエージェントのSDKで作られていて、動く場所はGitHubのランナーだ。自分のマシンではないが、自分のGitHubの契約で動き、設定も自分が書く。この記事の軸では「自分で用意する側」に入る。エージェントSDKの位置にあたる。費用の出どころも2つある。GitHub Actionsの実行時間と、モデルの利用分だ。公開リポジトリの標準のランナーは無料で、非公開にも無料の枠がある。モデル側はAPIキーでも契約の認証でも動かせる。なお、名前を呼ぶだけで動くわけではなく、先にGitHubアプリとワークフローの設定が要る。
チャットの場で名前を呼ぶもの、たとえばSlackのチャンネルで@Claudeと書いて仕事を頼む形は、提供元のクラウド側で動く。ここには2種類あって、個人の契約のままセッションが動くものと、組織の共有の名前で動きアクセスを管理者が決めるもの（こちらは法人向けの契約が要る）に分かれている。
どちらも動く場所は預ける形だが、これは出来上がったサービスであって、自分でエージェントを定義して預ける仕組み（マネージド）とは別物だ。「預ける」という言葉が同じでも、自分が設定を書くかどうかが違う。
マネージドは、自分でエージェントの設定を書いて、それを保存して、実行を預ける形を指している。出来合いの道具を使うのとは、作る量が違う。
枠の外へ出すときの費用
入り方は2つある。自分の枠の中で作り込んでから外へ移すか、最初からAPIで作るか。どちらでもいい。手元の枠で作るほうが速いので、試す段では枠の中、と決めても構わない。
ただし移すときに、費用の出方が変わる。枠の中では月額に収まっていた同じ処理が、使った分の請求になる。動かす回数も、試している間より本番のほうが多い。エージェントは同じ仕事で何度もモデルを呼ぶので、費用は思ったより伸びる。
移す前に、代表的な仕事を1回動かして、入力と出力のトークンがどれだけ出るかを見ておく。 料金はトークンで決まるので、回数だけでは足りない。1回分の量が分かれば、月の実行回数を掛けて見当が付く。そのうえで、用途に合うモデルを選ぶ、上限を決める、使った量が見えるようにする。この3つを、動かし始める前に入れておく。止まらないループが1本あるだけで、請求は簡単に跳ねる。
枠の中で回すときは、自動で動かしてよいかを提供元の利用条件で確かめておく。人が対話で使う前提の枠と、無人で回す使い方は、扱いが違うことがある。
どれを選ぶか
要件から引く。当てはまるものを拾って、行き先が重なったところを候補にする。1つに決まる表ではない。
| 要件 | 行き先 |
|---|---|
| 実行環境を持ちたくない | マネージド |
| 途中で止めて再開したい（長い作業、日をまたぐ作業） | マネージド |
| 決まった時刻に動かしたい | マネージド（自前で仕掛けを作るなら、ほかでも可） |
| ファイルの読み書きやコマンド実行が要る | エージェントSDK |
| 実行前の承認や、失敗したときの差し替えが要る | ツールランナー |
| 使わせる道具を、自分が定義したものだけに絞りたい | ツールランナー |
| どれも要らない。制御を全部自分で持ちたい | 自作ループ |
上の3つは「持ちたくない」側、下の3つは「自分で決めたい」側だ。迷ったら、預ける理由があるかを先に見る。 無ければ自分の側に残る。なお、途中で止めて再開する仕組みは、エージェントSDKやフレームワークの側にもある。
まとめ
エージェントの前に3段ある。提供元の画面をそのまま使うだけで足りるなら、それでいい。単発のAPIで足りるならそれでいい。手順が書き切れるならワークフローで止める。書き切れないと分かったときだけ、エージェントに降りる。
降りると決めたら、自分の契約の枠の中で作る道と、最初からAPIで作る道がある。複数人で使う、配る、納品する、が決まっているなら後者でいい。作り方4通りは、ループ・実行環境・道具の3つを誰が持つかの組み合わせで並んでいる。
気づいた点があればコメントで教えてください。AI関連のご相談はThreadsのDM（@ai_advisor_jp）へどうぞ。