A&A INSIGHTS
AI受託を増やす前に、人の確認で詰まる量を見積もる
生成が速くなっても、納品できる件数は創業者の確認時間で頭打ちになります。通常確認・例外対応・再納品を分けて数え、いまの体制で受けられる件数を見積もる方法を、Anthropicの採点分類とGumloopの自社サポート運用から読み解きます。
Read in English
この記事の要点
複数の顧客へAI生成物を納品している一人・二人の会社で、納期を決めているのは作る時間ではなく、合意した品質へ直すために創業者が使う確認時間です。この記事の主張は、供給能力を決めるのは生成速度ではなく確認時間であり、しかも効くのは目立つ例外対応ではなく全件に掛かる通常確認だ、というものです。Anthropicの評価解説にある採点の三分類——コードによる採点、モデルによる採点（コードより高くつき、人との較正が要る）、人による採点（基準となる品質だが高価で遅い）——を、受託の確認項目を仕分ける表へ読み替えます。Gumloopが自社サポートについて公開した、人がチケットを開く時点で文脈が揃っている設計と、対応可能な発見のときだけ人に知らせる運用も同じ方向を指しています。商品説明文を月600本納品する架空の二人の会社で、供給能力の見積もり表を埋めます。出典の記述、A&Aの解釈、架空の仮想例は区別しています。
受けられる件数を決めているのは、生成の速さではない
A&Aの考え方
「AIで下書きが10分で出るようになったので、受注を倍にできますか」という問いに、A&Aは「生成時間は答えの分母に入っていません」と答えます。複数の顧客へAI生成物を納品している一人・二人の会社で、納期を決めているのは多くの場合、作る時間ではなく、合意した品質へ直すために創業者が使う確認時間です。受注を増やす前に見積もるべきはこちらで、しかもその内訳を「通常確認」「例外対応」「再納品」の三つに分けないと、どこを触れば件数が増えるのかが見えません。
出典に基づく事実
Anthropicが2024年12月19日に公開した「Building effective agents」は、エージェント的な構成について「しばしば遅延とコストを、より良いタスク性能と引き換えにする（Agentic systems often trade latency and cost for better task performance）」と述べ、その交換条件が見合う場面かを考えるよう勧めています。自律的に動く構成については「エージェントの自律性は、より高い費用と、誤りが積み重なる可能性を意味する（The autonomous nature of agents means higher costs, and the potential for compounding errors）」とも書かれています。
出典に基づく事実
同じページの付録は、出力の品質を客観的に測りやすい領域としてコーディングを挙げたうえで、自動テストが機能の検証に役立つ一方で「より広いシステム要件に解が沿っているかを確かめるには、人のレビューが依然として欠かせない（human review remains crucial for ensuring solutions align with broader system requirements）」と書いています。あわせて、エージェントが価値を出しやすい仕事の条件として、会話と行動の両方を要すること、明確な成功基準、フィードバックの回路が働くこと、そして「意味のある人の監督（meaningful human oversight）」の組み込みを挙げています。
A&Aの考え方
A&Aはここを、受託の見積もりに効く下限として読みます。自動判定がもっとも効きやすいはずのコードですら、人のレビューは消えずに残る。つまり「人が一件も触らない納品」を前提にした供給能力の見積もりは作れません。作れないのであれば、残る確認を消そうとするより、それが何分かかるのかを数えて分母に置くほうが実務的です。
A&Aの考え方
この記事が扱うのは「週や月に何件受けられるか」という供給能力の話です。一件あたりにいくらかかり、その商品を続けるかという採算の話は、別の記事「低単価サービスの採算は、生成速度だけで決まらない」で扱っています。分母が違います。採算の分母は費用で、供給能力の分母は創業者の時間です。両方が詰まっている会社もありますが、打ち手が違うので分けて見てください。
人の時間を、通常確認・例外対応・再納品に分ける
A&Aの考え方
A&Aが勧める分け方は三つです。通常確認は、納品するすべての成果物に必ずかかる目視と照合の時間。例外対応は、入力が想定から外れたときだけ発生する、調べ直しや顧客への確認の時間。再納品は、いったん納めたあとに差し戻されて直す時間です。この三つは、件数に対する掛かり方がまったく違います。通常確認は全件に、例外対応は発生率のぶんだけ、再納品は差し戻し率のぶんだけ掛かります。まとめて「確認作業」と呼んでいるかぎり、この違いは見えません。
A&Aの考え方
ですから、月に使える確認時間をHとすると、受けられる件数Nはおおよそ次の形になります。N ≒ H ÷（通常確認の時間 ＋ 例外発生率 × 例外対応の時間 ＋ 差し戻し率 × 再納品の時間）。式そのものは当たり前に見えますが、重要なのは何が入っていないかです。生成にかかる時間はこの分母にありません。生成が二倍速くなってもNは動かない。動かしたければ三つの項のどれかを下げるしかない、というのがこの式の言っていることです。
出典に基づく事実
自動化プラットフォームのGumloopは、2026年2月17日にMax Brodeur-Urbas名義で公開した自社記事で、サポート業務を自社製品で組んでいると説明し、「私たちのサポートチームは二人しかいない（our support team has only two people）」と書いています。同記事は週に50万件を超えるサポート関連のワークフロー実行、18種類のMCPツール連携、5分未満のチケット応答時間を自社の数値として挙げています。
A&Aの考え方
この記事はGumloop自身の記述であり、第三者が検証した監査結果ではありません。挙げられている50万件はサポート関連のワークフロー実行回数であって、問い合わせ件数ではない点にも注意が要ります。また、自社プロダクトのサポートは、顧客へ成果物を納品して検収を受ける受託とは責任の範囲が違います。それでもA&Aが受託向けに読み取る価値があると考えるのは、二人が何をしなくてよくなったかではなく、二人の前に何が届くかを設計している点です。以降で使うのはこの設計の考え方だけで、数値は自社の見積もりへ移しません。
| 確認の段 | 向いている確認 | 受託で発生する費用 |
|---|---|---|
| 入力資料との照合で判定できる | 型番・寸法・数量・文字数・必須項目の有無など、合否の理由を一文で書け、他人が読んでも同じ判定に至るもの | 作るのは一度。入力資料の様式が変わったときに気付く仕掛けが要る |
| 基準を書けば判定できる | トーン、禁止表現、入力資料にない記述の混入など、理由は書けるが判定に幅が出るもの | 人の判定と突き合わせる較正の期間。移設中は確認時間がいったん増える |
| 人でないと判定できない | 顧客固有の方針、責任を伴う判断、前例のない要望 | 件数に比例して残る。ここを分母にして受注量を決める |
| 渡してはいけない確認 | 誤りの損害が顧客側に出るもの、契約上こちらが責任を負うもの | 自動判定の対象から外し、例外対応として先に時間を積む |
| まだ仕分けられない確認 | 差し戻す理由を、自分でもまだ言語化できていないもの | 当面は人の時間として数える。言語化できた時点で上の段へ移す |
確認を速くするのではなく、人に届く前に減らす
出典に基づく事実
Gumloopの記事によれば、サポートのチケットが開くたびにワークフローが社内データベースを照会し、利用者のプロフィール、操作履歴、エラー件数をまとめた資料をチケット管理ツールへ流し込みます。このデータは30分ごとに同期され、「人のサポート担当がチケットを開く時点で（by the time a human support agent opens the ticket）」最新の情報が揃っている状態だと説明されています。
出典に基づく事実
同記事はまた、プラットフォームの健全性を監視するエージェントについて「（そしてその場合に限り）発見が対応可能なものであれば、人に知らせる（If (and only if) a finding is actionable, it alerts a human）」と書いています。問い合わせを診断するエージェントは、まず「ワークフローの失敗か、使い方の質問か、エージェントの不具合か（first determines what kind of issue it’s dealing with）」を判定し、それに応じて次に使う道具を選ぶ、とされています。
出典に基づく事実
Anthropicのエージェント設計の記事は、この形をルーティングという定型パターンとして整理しています。「ルーティングは入力を分類し、専門化された後続タスクへ振り分ける（Routing classifies an input and directs it to a specialized followup task）」もので、別々に扱ったほうがよい明確な区分があり、その分類を正確に行える場合に向くと説明されています。
A&Aの考え方
A&Aの読み替えはこうです。受託で確認時間が膨らむ会社の多くは、生成した成果物を全部同じ一列に並べ、創業者が上から順に見ています。ここに振り分けを一段入れると、全件に掛かる通常確認の中身そのものが変わります。入力資料と突き合わせれば機械的に判定できる項目を先に潰し、判定が割れたものと、そもそも入力が足りないものだけを人の列に残す。人が速く見るのではなく、人の列に並ぶ本数と、一本あたりに残っている判断の数を減らす、という順番です。二つの出典はいずれも自社プロダクトや一般的な設計の話であり、受託への適用はA&Aの仮説です。
仮想例
以下はA&Aが作成した架空の例で、実在の顧客や実績ではありません。EC事業者5社へ商品説明文を納品する二人の会社を考えます。いま創業者は月600本すべてを画面で読み、型番の綴り、寸法、素材、禁止表現、文字数を同時に見ています。振り分けを一段入れると、型番・寸法・素材・文字数は入力資料との一致で機械的に判定でき、人の列に残るのは「不一致が出た本」「入力資料に根拠がない記述が混じった本」「表現の判断が必要な本」だけになります。人の列に残る一本あたりで見る項目も、五つから一つか二つへ減ります。
確認項目を三段に仕分ける：照合・基準・人
出典に基づく事実
Anthropicが2026年1月9日に公開した評価設計の解説は、採点する仕組み（grader）を三種類に整理し、それぞれの長所と短所を並べています。コードによる採点は客観的で再現性があり、デバッグしやすい一方、正しいのに想定の形と違う出力には脆いとされます。モデルによる採点は柔軟で規模を出せ、自由記述も扱えるものの、非決定的で「コードより高くつく（More expensive than code）」うえ「正確さのために人の採点者との較正が必要（Requires calibration with human graders for accuracy）」と書かれています。人による採点は「品質の基準となるもの（Gold standard quality）」で専門家の判断に合致する一方、費用が高く、遅いとされています。
出典に基づく事実
同じ解説は、一つの採点役にすべての観点をまとめて見せるのではなく、「観点ごとに明確で構造化された採点基準を作り、それぞれを独立したLLM採点役で採点する（grade each dimension with an isolated LLM-as-judge rather than using one to grade all dimensions）」ほうがよいと勧めています。
A&Aの考え方
A&Aはこの三分類を、受託の確認項目を仕分ける表として使うことを提案します。出典は評価システムを作るための分類ですが、「何を、どの精度で、いくらかけて判定するか」という問いは、納品前の確認とまったく同じです。仕分けの手順は、いま確認している項目を一つずつ書き出し、それぞれに二つの問いを当てることです。「合否の理由を一文で書けるか」「その一文だけで、他人が読んでも同じ判定に至るか」。両方に「はい」なら照合側、前者だけなら基準側、どちらも「いいえ」なら人に残ります。観点ごとに分けるという助言もそのまま効きます。「全体を見て良いか判断して」と一度に頼むと、どの観点で落ちたのかが分からず、直す先も決まりません。
仮想例
先の架空の制作会社で仕分けると、こうなります。照合側は、型番・寸法・素材が入力資料と一致しているか、必須項目が埋まっているか、文字数が範囲内か。基準側は、ブランドごとのトーン規定に沿っているか、禁止表現が入っていないか、入力資料にない仕様を書いていないか。人に残るのは、その商品で今季なにを訴求するかという顧客固有の方針判断と、前例のない要望への対応です。三段目がいちばん少ないのが健全で、ここが多いなら、まだ商品として切り出せていない可能性を疑います。
確認を機械へ渡す費用は、「較正」の形で先に来る
出典に基づく事実
評価設計の解説は、観点ごとに分けた採点を整えたうえで「仕組みが堅牢になれば、人のレビューは時折で足りる（sufficient to use human review only occasionally）」としています。同時に、モデルによる採点は精度を確かめるために丁寧な反復が要り、人の専門家と密に較正して、人の採点とモデルの採点のあいだに大きな食い違いがないという確信を得るべきだとも書かれています。
出典に基づく事実
Anthropicのエージェント設計の記事は、生成役と評価役を組み合わせる構成について、適合を示すサインが二つあるとしています。一つは「人がフィードバックを言語化したときに、LLMの応答が目に見えて良くなる（LLM responses can be demonstrably improved when a human articulates their feedback）」こと、もう一つは、そのフィードバックをLLM自身が出せることです。
A&Aの考え方
A&Aはこの二つを、確認を機械へ渡す前の二問として使うことを勧めます。第一問は「その確認で差し戻すとき、自分は理由を言葉にしているか」。言葉にせず、自分で直したものを見せて済ませているなら、まだ渡せません。第二問は「その理由を、成果物と入力資料だけを見て書けるか」。顧客との過去のやり取りや業界の暗黙の前提が要るなら、その前提を文書へ出すまでは渡せません。この二問は、渡せるかどうかを判定すると同時に、渡すために何を書けばよいかも教えてくれます。出典はいずれもエージェント構成の設計についての記述であり、受託の確認工程への適用はA&Aの読み替えです。
A&Aの考え方
そして実務でいちばん外しやすいのがここです。確認を機械へ渡すと決めた時点で、その月から時間が空くと計算してしまう。実際には、較正の期間、つまり人とモデルの両方で同じ成果物を判定し、食い違いを潰す期間が先に来ます。A&Aは、この期間を見積もりの外に置かず、「移設中は確認時間がいったん増える」と明記しておくことを勧めます。受注を増やす計画と、確認を移す計画を同じ月に重ねないのは、そのためです。
再納品に上限を置き、直ったかどうかを確かめる工程を持つ
出典に基づく事実
エージェント設計の記事は、自律的に動く構成について、制御を保つために「停止条件（最大反復回数など）（stopping conditions (such as a maximum number of iterations)）」を入れることが一般的だとしています。エージェントは環境から得た結果で進捗を確かめ、区切りや行き詰まりで人の判断へ戻ることができる、とも説明されています。
A&Aの考え方
A&Aは、これを受託の契約欄へ持ち込むことを勧めます。技術側で最大反復回数を決めるのと同じ理由で、商売側にも「この金額に含まれる再納品は二回まで、それ以降は別見積もり」という上限が要ります。上限がないと、一件の修正往復が週の確認時間を食い尽くし、他の顧客の納期まで動きます。先ほどの式でいえば、差し戻し率が低くても、一件あたりの再納品時間に天井がなければ、受けられる件数は計算できません。
出典に基づく事実
Gumloopの記事は、毎日動くワークフローが追跡すべき利用者を特定し、「サポートチームが提供した解決策が実際に効いているかを確かめる（ensure that the solutions the support team provided actually work）」と説明しています。また、修正が反映されるたびに、関係する利用者へ知らせるエージェントを動かしているとも書かれています。
A&Aの考え方
差し戻し率を見積もりに使いたいなら、この工程が要ります。直したものを送って終わりにすると、直っていない案件は「次の依頼の一部」として再び現れ、再納品ではなく新規として数えられてしまう。すると分母が狂い、供給能力を実際より高く見積もることになります。受託の規模なら自動化する必要はなく、納品から一定期間後に「この対応で解決しましたか」を一往復入れるだけで、差し戻し率は測れる数になります。
仮想例
架空の制作会社の契約欄はこうなります。「差し戻しは納品後7日以内、同一本につき2回まで。3回目以降と、入力資料の変更に伴う書き直しは別見積もり。納品10日後に解決確認の連絡を1通送り、返信がない場合は完了とみなす」。この文面自体は仮のもので、実際の条件は商品と顧客によって変わります。ここで見てほしいのは、上限と確認の一往復が、契約の親切さの話ではなく、受注量を計算できるようにするための条件だという点です。
供給能力の見積もり表を、仮定つきで埋める
A&Aの考え方
埋める欄は六つです。月に確認へ使える時間、一件あたりの通常確認時間、例外の発生率、一件あたりの例外対応時間、差し戻し率、一件あたりの再納品時間。最初は記憶で埋めず、二週間だけ実測してください。ストップウォッチは要らず、一件ごとに「通常・例外・再納品」のどれだったかと、終わった時刻を残すだけで足ります。ここで出るのは自社の現在値であって、業界の標準でも、他社へ持ち出せる数値でもありません。
仮想例
以下はすべて架空の仮定で、A&Aや顧客の実測値ではありません。先の制作会社が、月600本、確認に使える時間を60時間とします。通常確認が1本3分なら、600本で30時間。例外の発生率が8%で1件25分なら、48件で20時間。差し戻し率が5%で1本15分なら、30本で7.5時間。合計57.5時間です。使える60時間に対してほぼ上限で、この状態で受注を増やせば、増えるのは納期遅れです。ここで、例外対応を半分に減らせば10時間空きます。一方、通常確認を1本3分から1分にできれば20時間空きます。目につくのは例外ですが、全件に掛かる項のほうが大きい、という順序がこの表で見えます。
A&Aの考え方
この読み方には条件があります。第一に、空いた時間に実際に別の受注が入らなければ、現金は増えません。時間の余りをそのまま粗利に読み替えないでください。第二に、通常確認を1分に縮めるには、前の章の仕分けと較正が先に要ります。この表は「どれを先にやるか」を選ぶための道具であって、削減率を約束するものではありません。第三に、月600本という前提が崩れれば、順序も変わります。件数が少なく一件が重い仕事では、例外対応の項のほうが大きくなることがあり、その場合は手を付ける先も変わります。
この見積もりが成り立たない場合と、次の一歩
A&Aの考え方
最初に、当てはまらない場面を挙げます。一件ごとに仕様が違い、通常確認の中身が毎回変わる仕事では、一件あたりの通常確認時間が安定しません。その場合、この式で件数を見積もっても意味がなく、先に決めるべきは受注量ではなく対象業務の絞り込みです。また、確認を複数人で分担できる体制なら、創業者一人を分母にしたこの式は当てはまりません。人を増やせるのであれば、増やしたあとに同じ表を担当者ごとに作ることになります。
出典に基づく事実
Gumloopの記事は、同社のサポート運用について、最初から完成した形で始まったわけではなく、数か月にわたる継続的な反復のなかで「一つのワークフローずつ育った（it grew one workflow at a time）」と書いています。
A&Aの考え方
A&Aはこれを、この記事全体への歯止めとして読みます。仕分け表を作り、較正を済ませ、再納品の上限を契約へ入れ、それから受注を増やす——という順序は正しくても、全部を先に作り切る必要はありません。評価設計の解説も、人のレビューを時折に減らせるのは仕組みが堅牢になってからだとしており、順序を飛ばせるとは書いていません。最初に触るのは、いま一番時間を食っている一項目だけで足ります。あわせて、Gumloopの数値も、Anthropicの設計上の助言も、A&Aや読者の会社での成果を予測するものではありません。
A&Aの考え方
次の一歩は単純です。今週納品したぶんについて、通常確認・例外対応・再納品のどれだったかを一件ずつ記録し、二週間ぶん貯める。そのうえで、いちばん大きい項を一つ選び、前の章の二問——差し戻す理由を言葉にしているか、その理由を成果物と入力資料だけで書けるか——を当てる。どちらにも「はい」と答えられるなら、そこは移せます。答えられない場合は、まだ商品の定義が足りていない可能性があります。その切り分けが自社でつかない場合は、A&Aの初回相談で、どの確認が供給能力を決めているかを一緒に整理します。顧客獲得から納品・継続までの全体像を先に見たい場合は、「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」で位置づけを確認できます。
AIサービスの供給能力は、生成の速さではなく、合意した品質へ直すために人が使う時間で決まります。その時間を通常確認・例外対応・再納品に分けて二週間だけ実測し、全件に掛かる項から手を付ける。確認を機械へ渡すときは、較正という費用が先に来ることを見積もりへ書いておく。受注を増やす判断は、そのあとです。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Building effective agents
Anthropic · 2024-12-19 (page notes tooling has changed since)
確認日 2026-09-23 - Demystifying evals for AI agents
Anthropic · 2026-01-09
確認日 2026-09-23 - Supporting the world's most AI-native companies with a 2-person team
Gumloop · 2026-02-17
確認日 2026-09-23
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-09-23