A&A INSIGHTS
エージェントかワークフローか：AI受託の見積もりは手数を数えてから分ける
AIの受託で、エージェントとして請けるかワークフローとして請けるかは、必要な手数を見積もり前に数え切れるかで決まります。数え切れる工程は固定経路で定額、数え切れない工程は経路ではなく引き継ぎの条件を検収に書きます。
Read in English
この記事の要点
エージェントとして請けるか、経路を固定したワークフローとして請けるかは、実装の高度さではなく「必要な手数を見積もり前に数え切れるか」だけで決まります。数え切れる工程は固定経路として定額で請け、数え切れない工程だけをモデルに任せ、その工程では経路ではなく、使ってよい道具の範囲と解決できなかったときの引き継ぎ先を約束します。
答え：分かれ目は「必要な手数を見積もり前に数え切れるか」の一点
A&Aの考え方
「エージェントを作ってほしい」と言われて要件を聞いたら、手順はほぼ決まっていた。この場面で決めるべきことは一つです。その案件を、経路を事前に書き切る実装として請けるか、モデルが経路を決める実装として請けるか。判断の基準は実装の高度さではなく、必要な手数を見積もりを出す前に数え切れるかどうかの一点です。
A&Aの考え方
数え切れるなら、固定した経路として請けます。このとき売っているのは予測可能性です。入力と出力の対応を工程ごとに書けるので、検収条件も定額の見積もりも成立します。数え切れないなら、その工程だけをモデルに任せます。ただし経路は毎回変わるので、約束できるのは経路ではありません。使ってよい道具の範囲と、解決できなかったときに誰へ渡すかという規則です。
A&Aの考え方
そして判定の単位は案件ではなく工程です。一つの仕組みの中に、手数が読める工程と読めない工程が同居するのが普通です。見積もりを「エージェント案件」「ワークフロー案件」と丸ごと分類すると、手数が読める工程にまで自律性の代償を払うことになります。
Anthropicの区別：「事前に定義されたコード経路」か「モデルが自分で決める」か
出典に基づく事実
Anthropicの「Building effective agents」（2024年12月19日公開）は、両者を構造で分けています。ワークフローは「Workflows are systems where LLMs and tools are orchestrated through predefined code paths.（ワークフローとは、LLMと道具が事前に定義されたコード経路を通して組み立てられる仕組みである）」。エージェントは「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が自分の処理と道具の使い方を動的に決め、どう仕事を成し遂げるかの制御を持ち続ける仕組みである）」。
出典に基づく事実
同ページは適用条件も書いています。「Agents can be used for open-ended problems where it’s difficult or impossible to predict the required number of steps, and where you can’t hardcode a fixed path.（エージェントは、必要な手数を予測することが難しいか不可能で、固定した経路を書き込めない、終わりの決まっていない問題に使える）」。条件として挙げられているのは、課題の難しさではなく手数の予測可能性です。
出典に基づく事実
選び方についても明言があります。「workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale（よく定義された仕事に対してワークフローは予測可能性と一貫性を提供し、他方エージェントは、柔軟性とモデル主導の意思決定が規模をもって必要なときに、より良い選択肢になる）」。順序についても「add multi-step agentic systems only when simpler solutions fall short（より単純な解法が足りないときにだけ、多段の自律的な仕組みを足す）」としています。
A&Aの考え方
受託にとって重要なのは、この引用に出てくる predictability（予測可能性）が、そのまま見積書に書ける性質だという点です。ただしこれは出典の主張ではありません。Anthropicが述べているのはモデルの設計指針で、受託の価格や検収条件については何も書いていません。予測可能性が商品として一番売りやすいという接続はA&Aの解釈です。
| 工程の性質 | 見積書に書く行 | 検収で確かめること |
|---|---|---|
| 手数を数え切れる（分岐を含めて書き出せる） | 入力と出力の対応、定額 | 用意した入力でその出力が出るか |
| 使う道具が実行前に決まらない | 使ってよい道具の一覧と、範囲外だったときの扱い | 範囲外の入力を無理に分類していないか |
| 何手で終わるか決まらない | 試行の上限と、上限に達したときの渡し先 | 上限まで試した案件が、決めた相手へ情報付きで渡っているか |
| 失敗したことが自動では分からない | 人へ上げる条件と、上げ先 | 条件を満たした件だけが上がっているか |
| 自律側の工程に共通して乗る作業 | 隔離環境での試験、防護柵の設計、運用での誤り検出 | 試験の記録と、停止条件が実際に効くか |
自律性の代償は、定額で請けた側の財布から出る
出典に基づく事実
自律性には代償があると出典は書いています。「Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.（自律的な仕組みは、より良い課題遂行のためにしばしば遅延と費用を引き換えにする。この取引が妥当かどうかを検討すべきである）」。
出典に基づく事実
代償の内訳も明示されています。「The autonomous nature of agents means higher costs, and the potential for compounding errors.（エージェントの自律的な性質は、より高い費用と、誤りが積み重なる可能性を意味する）」。費用と、誤りの積み重なりの二つです。
A&Aの考え方
この二つは、受託では誰が払うのかが先に決まっています。定額で請けた案件で手数が増えれば、増えた分の推論費用は請けた側の取り分から出ます。誤りが積み重なれば、それを見つけて戻す作業は運用の範囲に落ちます。つまり自律性の代償は、設計の好みの問題ではなく、どちらの財布から出るかの問題です。
A&Aの考え方
だから手数が数え切れる工程で自律性を売るのは、単に過剰な設計というだけではありません。予測可能性という一番売りやすい価値を自分で手放して、代わりに変動費と運用責任を引き受ける取引です。提案書の見た目は高度になり、採算は悪くなります。
Gumloopの公開記録：分け方は案件単位ではなく工程単位だった
出典に基づく事実
工程単位で分けている公開記録があります。Gumloopの「Supporting the world’s most AI-native companies with a 2-person team」（Max Brodeur-Urbas、2026年2月17日）は、同社の支援業務を自社製品で組んだ記録で、「our support team has only two people（支援チームは二人しかいない）」と書いています。使った部品は「the same building blocks that are available to every Gumloop user（すべてのGumloop利用者が使えるのと同じ部品）」であり、ワークフロー、エージェント、トリガー、MCPの道具だと説明されています。
出典に基づく事実
固定経路に置かれているのは、入力と順序が決まっている工程です。記事によれば、利用者情報の付加は、問い合わせが開くたびに内部データベースへ問い合わせて利用者の情報一式を問い合わせ管理側へ書き込むワークフローで、このデータは30分ごとに同期されます。ほかに、毎日の追客対象の抽出、24時間ごとの支援文書の不足箇所の分析、会話の分類と分析も、いずれもワークフローとして説明されています。
出典に基づく事実
モデルに決めさせているのは、手数が事前に読めない工程です。診断を担う「Gummie Support」という名前のエージェントは「first determines what kind of issue it’s dealing with: a workflow failure, a how-to question, or an agent issue（まず、扱っているのがどの種類の問題かを判定する。ワークフローの失敗か、やり方の質問か、エージェントの問題か）」。そのうえで「Based on the situation, it chooses which tools to use next（状況に応じて、次にどの道具を使うかを選ぶ）」としています。
出典に基づく事実
モデルの選択も工程ごとです。「at Gumloop, we use many different models across our agents and workflows（Gumloopでは、エージェントとワークフローにまたがって多くの異なるモデルを使っている）」とし、軽量で高頻度の仕事、コードに関わる仕事、中核の推論、最も難しい仕事に、それぞれ別のモデルを割り当てていると書いています。掲載されている数値——週50万件を超える支援関連のワークフロー実行、18個の固有のMCP道具、問い合わせへの応答時間5分未満——はいずれも同社自身が自社について掲載したものです。
A&Aの考え方
この記録から受託が取れるのは、自律性の量ではなく分け方です。問い合わせが開いたら利用者情報を集める、という工程は手数が決まっているので固定経路に置かれている。何の問題かまだ分からない、という工程は手数が決まらないのでモデルに任されている。同じ仕組みの中で境界が引かれているのであって、どちらかを選んだのではありません。
見積もり前に、一工程ずつ当てる三つの質問
A&Aの考え方
要件を聞き取った段落を工程に割ってから、一工程ずつ次の三つを当てます。これは出典の判定条件を、見積もりの作業に置き直したものです。
A&Aの考え方
一つめ。この工程を動かす前に、必要な手数を数えられるか。「おおむね三手」ではなく、分岐を含めて書き出せるかで判断します。書き出せるなら固定経路です。書き出そうとして「入力を見てからでないと決まらない」と気付いたら、そこが境界です。
A&Aの考え方
二つめ。この工程が使う道具は、実行前に決まっているか。決まっているなら順序も書けます。「どの道具が必要かは状況次第」なら、道具の選択自体をモデルに委ねることになります。先に挙げたGumloopの診断の工程が分かれているのは、この点です。
A&Aの考え方
三つめ。この工程が失敗したとき、失敗だと分かるか。固定経路なら、どの手で止まったかが分かります。モデルに経路を任せた工程では、途中の判断が間違っていても最後まで走り切ることがあります。ここで「分からない」が出る工程は、人への引き継ぎ規則を先に決めないと検収条件が書けません。
工程の性質で、見積書に書く行が変わる
A&Aの考え方
三つの質問の答えで、見積書に書くものが変わります。固定経路の工程には、入力と出力の対応を工程ごとに書きます。検収は「この入力でこの出力が出るか」で確かめられるので、定額で請けられます。
A&Aの考え方
モデルに任せる工程には、経路を書けません。代わりに三つを書きます。使ってよい道具の一覧。自分で解決してよい範囲。解決できなかったときに、誰へ、どの情報を付けて渡すか。この三つが決まっていれば、経路が毎回違っても検収の対象が残ります。
A&Aの考え方
境界をまたぐ工程を一行にまとめないことも大事です。「問い合わせを受けて適切に対応する」と書くと、情報を集める部分（手数が決まっている）と、何の問題か判定する部分（決まらない）が同じ行に入り、価格も検収も決められなくなります。行を割ることが、見積もりの作業です。
出典に基づく事実
一度に全部を請けないことについては、出典側に根拠があります。Gumloopの記事は、同社の支援の仕組みが「didn’t start out fully formed: it grew one workflow at a time, over months of continuous iteration（最初から完成した形で始まったのではなく、何か月もの継続的な反復のあいだに、一つのワークフローずつ育った）」と書いています。二人で回る規模の仕組みも、一度に設計されたものではありませんでした。
任せる工程で約束するのは、経路ではなく引き継ぎの条件
出典に基づく事実
モデルに任せた工程で何を約束できるかの実例が、同じ記事にあります。基盤の健全性を見るエージェントについて「an agent automatically investigates error rates and monitors platform health. If (and only if) a finding is actionable, it alerts a human.（エージェントが誤り率を自動で調べ、基盤の健全性を監視する。発見が対処可能な場合に限り、人に通知する）」と書かれています。
出典に基づく事実
社会の反応を見る工程も同じ形です。記事によれば、あるエージェントがRedditとX（Twitter）でGumloopへの言及を監視し、どの言及が顧客の苦情かを判定して、その苦情に返答します。進む先は、苦情と判定した言及に返答することだと書かれています。
A&Aの考え方
この二つで固定されているのは、調査や監視の経路ではありません。「対処可能な発見のときだけ人に上げる」「苦情と判定したものに返答する」という条件と行き先です。どう調べてそこに至るかは、記事に書かれていません。経路は毎回違ってよい。条件と行き先が固定されているから、約束として成立します。
A&Aの考え方
受託の検収条件も同じ形で書けます。「調査の手順が毎回同じであること」ではなく、「この条件を満たしたとき、この相手に、この情報を付けて渡ること」。なお、出力のばらつき自体を検収条件へどう落とすかは別の判断で、それは「同じ入力で同じ結果が出ないAI納品物を、検収条件にどう書くか」で扱っています。
自律側の工程にだけ乗る、三つの費目
出典に基づく事実
自律側には、固定経路側にない作業が乗ります。出典は対策として「We recommend extensive testing in sandboxed environments, along with the appropriate guardrails.（隔離された環境での広範な試験と、適切な防護柵を推奨する）」としています。隔離環境の用意、広範な試験、防護柵の設計は、いずれも誰かがやる作業です。
出典に基づく事実
費用の性質も違います。同じページは、自律的な仕組みが遅延と費用を課題遂行と引き換えにし、自律性がより高い費用を意味すると述べています。手数が増えれば推論の回数も増えます。固定経路なら一件あたりの手数が決まっているので、一件あたりの費用も見積もれます。
A&Aの考え方
だから見積書では、自律側の工程に三つの費目を分けて立てます。隔離環境での試験。防護柵（使ってよい道具の制限、停止条件、試行の上限）の設計。そして運用開始後に、誤りの積み重なりを見つける作業。固定経路の工程にこれを乗せる必要はなく、乗せれば単に高いだけの見積もりになります。
A&Aの考え方
一件あたりの費用は、固定経路の工程なら定額に含められます。自律側は一件あたりの手数が変わるので、含めるなら試行の上限を決めるか、使用量に応じた別立てにするかを先に選びます。どちらでもかまいません。決めずに定額へ入れると、よく使われた月の持ち出しを請けた側が被ります。
架空の例：「エージェントを作ってほしい」を六工程に割る
仮想例
架空の例で工程を割ってみます。顧客が「社内の問い合わせを受けるエージェントを作ってほしい」と言ってきた状況です。要件を聞くと、問い合わせはチャットの一つのチャンネルに来て、内容は規程の確認、経費の手続き、機器の不調の三つにほぼ収まり、規程と手続きは文書になっている、という話でした。
仮想例
工程に割ると六つになります。問い合わせの受け取り（手数が決まっている）、投稿者の所属と権限の取得（決まっている）、三つのどれに当たるかの判定（入力を見ないと決まらない）、規程と手続きなら該当箇所の提示（決まっている）、機器の不調なら原因の切り分け（決まらない）、解決しない場合の引き継ぎ（決まっている）。固定経路が四つ、モデルに任せるのが二つです。
仮想例
見積書は工程ごとに行を作ります。固定経路の四工程は、入力と出力を書いて定額。判定の工程は、使ってよい情報（投稿本文と投稿者の所属）と、三つ以外だったときの扱い（分類せず引き継ぎに回す）を書く。切り分けの工程は、使ってよい道具（機器の一覧と過去の対応記録）、何手まで試すか、解決しなかったときに誰へ何を付けて渡すかを書きます。
仮想例
検収も行ごとに分かれます。固定経路の四工程は、用意した入力でその出力が出るかを確かめる。判定の工程は、経路ではなく「三つ以外の問い合わせを、三つのどれかに押し込まなかったか」を確かめる。切り分けの工程は、上限まで試して解決しなかった案件が、決めた相手に決めた情報付きで渡っているかを確かめます。
仮想例
この割り方をしないと何が起きるかも書いておきます。六工程を「問い合わせを自律的に解決するエージェント」として一行で請けると、定額の中に、入力を見ないと手数が決まらない工程が二つ混ざります。よく使われた月は推論の費用が増え、切り分けを外した案件は運用で拾うことになります。どちらも見積もりの外で起きます。
A&Aの考え方
この例は説明のために作った構成です。A&Aの受注案件でも、この形で納品した記録でもありません。実際の案件では、三つの分類に収まらない問い合わせの割合や、機器の一覧に触れてよいかどうかで、工程の数も境界の位置も変わります。
この判定が合わない条件と、主張しないこと
A&Aの考え方
この判定が合わない条件を四つ書きます。
A&Aの考え方
一つめ。手数が読めても、固定経路が割に合わない場合があります。出典が分けているのは手数の予測可能性であって、入力の側が変わる速さではありません。顧客の上流——問い合わせの経路や帳票の形式——が毎月変わるなら、固定経路は毎月の変更依頼になります。ただしこれは自律性を売る理由ではなく、変更の受け方を先に値付けする理由です。この接続はA&Aの解釈です。
A&Aの考え方
二つめ。実際の案件は純粋な二択になりません。固定した経路の中に一工程だけモデルの判断を挟む形が多く、その場合の見積もりは工程ごとの行で書くしかありません。本稿の三つの質問は、案件を分類する道具ではなく、行を割る道具です。
出典に基づく事実
三つめ。Gumloopの記録は、同社が自社製品を自社で使った記録であり、独立した第三者による監査ではありません。掲載された週50万件超、18個の固有のMCP道具、応答時間5分未満は、同社が自社の規模と運用について掲載した数値です。また二人で回せたという事実は、その支援業務が自社製品と地続きだったことに依存します。記事自身が「Everything described above was built using the same Gumloop platform available to every customer（上記のすべては、すべての顧客が使えるのと同じGumloopの基盤で作られた）」と述べている通り、対象の仕組みは自社製品そのものです。小さな受託事業の見込み値にも、達成可能な水準にもなりません。
出典に基づく事実
四つめ。Anthropicの記述はモデル提供者による設計指針です。2024年12月19日の公開で、より単純な解法が足りないときにだけ多段の自律的な仕組みを足す、という順序を示していますが、受託の採算、価格の決め方、検収条件について書いたものではありません。本稿の見積書と検収への置き直しは、すべてA&Aの解釈です。
A&Aの考え方
主張しないことも書きます。本稿にA&Aの受注実績、成約率、利益率は出していません。価格水準も示していません。架空の例は説明のために作った構成で、納品の記録ではありません。工程を割れば採算が改善するという因果も示していません。示しているのは、どの工程で予測可能性を売っているかが見積もり前に分かる、という範囲までです。
次の一歩：一件の要件を工程に割って、各行に手数を書き込む
A&Aの考え方
次の一歩は小さくできます。いま見積もりを出そうとしている一件で、要件の段落を工程に割り、各行に「手数を数えられるか」だけを書き込んでみてください。全部の行に数えられると書けたなら、その案件はエージェントとして請ける必要がありません。
A&Aの考え方
数えられない行が出たら、その行だけに、使ってよい道具と、解決できなかったときの渡し先を書きます。この二つが書けない行は、まだ見積もれる状態にありません。顧客に聞くべきことが残っているか、業務の側が決まっていないかのどちらかです。
A&Aの考え方
行の割り方そのものが決まらない場合は、業務の確認が先です。着手前に何を決めれば手戻りが減るかは「AI開発の見積もり前に、何を決めれば手戻りを減らせるか」で、納品後に誰が何を引き受けるかは「AIの仕組みを納品したあと、止まった仕事を誰が戻すのか」で扱っています。工程の分け方が決まっていて実装の範囲を決めたい段階なら、A&Aの開発の相談が使えます。全体の流れを先に見たい場合は「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」があります。
エージェントとして請けるかどうかは、高度さの判断ではありません。要件を工程に割って、各工程の手数を見積もり前に数え切れるかを確かめる作業です。数え切れる工程で自律性を売ると、予測可能性という一番売りやすい価値を手放して、代わりに変動費と運用責任を引き受けることになります。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Building effective agents
Anthropic · 2024-12-19
確認日 2026-10-03 - Supporting the world’s most AI-native companies with a 2-person team
Gumloop · 2026-02-17
確認日 2026-10-03
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-10-03