顧客が自分で作れるようになったとき、何を売るか：商品を生成の下流へ動かす

A&Aの考え方

顧客の担当者が自分で道具を作り始めたとき、取るべき手は値下げでも、より難しい技術へ逃げることでもありません。売っている工程を一段下流へ動かすことです。手順は三つです。第一に、いま受けている作業を「生成すれば終わる作業」と「生成したあとに誰かが引き受ける作業」に分けます。第二に、前者のうち顧客側に作れる担当者が一人でもいるものを商品から外します。第三に、後者のうち「間違っていないと言い切る仕事」と「壊れたときに戻す仕事」に、単価と期間を付け直します。これがこの記事の答えです。

A&Aの考え方

この分け方を採る理由は、内製化が奪うのは工程であって業務ではないからです。顧客が自分で作れるようになったのは、作るという一工程です。作ったものが業務に乗るためには、その出力が正しいと言える根拠と、壊れたときに戻す人が要ります。そして後者は、作れる人が社内に増えるほど量が増えます。つまり内製化が進むと、受託が売れる量は減らず、売れる場所が移動します。値下げで同じ工程に留まると、移動した先に誰も立っていないまま単価だけが下がります。以下では、この読み替えの土台にした二つの記述を順に示します。片方は生成の工程が顧客側に移った例、もう片方は生成を速くした組織の中で何が増えたかの記録です。両者を受託の値付けに結びつけるのはA&Aの仮説であり、どちらの出典も述べていません。最後に、その仮説を表に落とします。

A&Aの考え方

ここで受託側が見るべきなのは所要時間ではなく、作った人の属性です。十五分という数字は当事者の自己申告であり、同じ作業が誰にでも十五分で終わるという意味ではありません。重要なのは、ソフトウェアの経歴がない所有者と、長年AIを不要と言っていたIT責任者の両方が、自分の困りごとに合わせて道具を作った点です。この二人は、これまでなら小さな受託の見積を取っていた層です。受託側から見ると、見積依頼そのものが来なくなる領域が、技術的な難易度ではなく「困りごとを一番よく知っている人が近くにいるか」で決まり始めている、ということになります。なお、同記事はAnthropicが自社の無償のツアーについて自ら公開したもので、参加者は自ら申し込んだ米国の事業者です。日本の受託市場の需要を示す資料ではありません。

A&Aの考え方

この記事が扱っているのはAnthropic社内のソフトウェア開発という特定の文脈であり、受託の工程に同じ比率で当てはまるとは述べられていません。それでも読み取れる構造は一つあります。生成が速くなったとき、仕事がなくなったのではなく、確認と選別と復旧の側に移ったという点です。同記事で増えたのはCIの実行件数と、それに伴ってサービスが処理すべきテスト選定と結果取り込みの判断の量です。なお人手のほうは増えておらず、エンジニアの増員は名目的で、作り直し全体も一人で三週間だったと書かれています。減ったのはコードを書く時間ではなく、コードを書くことが制約である度合いのほうです。担当の所在については、同記事は増えたとは書いておらず、むしろ「ownership was murky. No one wanted to own another piece of infrastructure.」と記しています。この構造を受託に移すと、顧客が道具を作れるようになったあとに増えるのは「その出力を信じてよいかを決める作業」と「止まったときに戻す作業」になります。この読み替えはA&Aの仮説であり、出典が述べている事実ではありません。

A&Aの考え方

ここに挙がっている三つは、いずれも生成ではありません。新入社員が全要約を確認するという設計、送信だけは人が押すという線引き、個人情報の削除手順と全ワークフローの台帳です。どれも「誰がどこまで責任を持つか」を決める作業で、作る作業とは別の技能が要ります。そして受託側から見ると、この三つはいずれも一回で終わらず、顧客の社内で作る人が増えるほど量が増えます。台帳は作れる人の数に比例して崩れ、確認の設計は業務が変わるたびに書き直しになります。値下げして生成工程に留まる判断が損なのは、相場が下がるからではなく、量が増えている側に自分が立っていないからです。

A&Aの考え方

実際に商品を動かすときは、作業の一覧を作って一行ずつ二つの問いに答えます。第一の問いは「顧客側の担当者だけで完結するか」です。完結するなら商品から外します。外すというのは断るという意味ではなく、見積の行から消して、必要なら作り方を教える短い伴走としてだけ残す、という意味です。第二の問いは「完結しないなら、何として売るか」です。ここで「技術支援」のような広い名前を付けると、顧客側は自分で作れる作業と区別できず、値段の根拠も立ちません。理由はこの種の道具に固有です。同じ入力から別の出力が出うる以上、顧客は成果物を見ても、どこまでをこちらがやったのかを推し量れません。決定的な納品物は範囲を自分で示しますが、生成物は示さないので、名前のほうが範囲を担うしかありません。検収条件の設計、取り扱い範囲の設計、復旧の責任範囲、台帳の維持といった、納品物の形が言える名前にします。名前の具体性は、先に引いた出典の失敗の形から取れます。実測の壁面寸法ではなく床面積の係数が使われていた、という形の誤りは、出力が顧客にとって金額として間違ってから初めて書かれる種類の検査です。つまり検収条件の設計とは、顧客が「どう間違うと損になるか」を言語化する作業であって、動かす作業ではありません。台帳の側も同じ読み方ですが、出典の先にある部分はA&Aの推論です。出典が記しているのは、HireEffectが職員への展開前にPIIの削除と全Claudeワークフローの台帳を作ったという事実であって、職員が後から作った道具の一覧ではありません。その先、つまり社内で作れる人が複数になれば台帳は「誰でも追加しうる一覧」に変わり、決まった手順の一覧と違って放置すれば崩れる、という部分はA&Aの推論で、出典は述べていません。崩れることこそが、維持に値段が付く理由です。

A&Aの考え方

売る位置を下流へ動かす判断が誤りになる場面があります。第一に、顧客側に作る人が一人もいない場合です。引用した記事の例には、所有者本人かIT責任者か、少なくとも一人は作る人がいました。その人がいない組織では、生成工程そのものが引き続き有償で成り立ちます。第二に、規制や社内規程で内製が認められていない領域です。第三に、作る人はいるが、その人が本業で埋まっていて手が出せない場合です。この三つに当てはまる顧客に対して先に商品を下流へ動かすと、まだ売れる工程を自分から降りることになります。四つめの注意は、同じ出典の中にあります。ツアーの参加者の三分の二近くが講習後に実装の伴走を求めたという記述は、下流ではなく作る工程そのものへの需要です。これを過渡的な需要だと読むのはA&Aの想定であって、出典はそう述べていません。

A&Aの考え方

この誤りを避けるための確認は、顧客を見て決めるのではなく、案件ごとに一問を置くことで足ります。「この作業を、相手の社内で誰か一人が自分の時間でやり切れるか」です。やり切れるなら商品から外し、やり切れないなら理由を記録します。理由は四つのどれかに収まります。作る人がいない、規程で認められていない、手が空いていない、そして「作り方を教わりたい、そこには払う」です。四つめだけは断る理由ではなく、次節で述べる入口にあたります。ただし下流の商品が先に用意されていなければ収入にはつながりません。このうち三つめは時間とともに変わるので、同じ顧客でも半年後には答えが変わります。顧客単位ではなく案件単位で問い直すのは、そのためです。なお、ここで示した分け方と問いはA&Aが提案する枠組みであり、測定された手法ではありません。

A&Aの考え方

この事実は、受託側にとって二つの意味を持ちます。一つは、教えるという仕事の供給が、生成が容易になるほど増えるという点です。参加者の五人に一人がすでに教える側だったという記述は、教育そのものが差別化しにくい方向へ動いていることを示唆します。もう一つは、教えた相手が自分の見込み客でもあるという点です。作り方を教えれば、その顧客は生成工程を自分で担えるようになります。そこで受託の収入が終わるのか、下流の商品へ接続されるのかは、教える前に下流の商品が用意されているかで決まります。したがって講習や伴走は、商品を動かす代わりではなく、動かしたあとの入口として置くのが順序です。ただし、これはA&Aの解釈であり、出典は教える仕事の収益性について何も述べていません。

A&Aの考え方

出典の限界を明示します。引用した二つの記事はいずれもAnthropic自身が公開した資料で、独立した監査ではありません。ツアーの報告は、無償の講習に自ら申し込んだ米国の事業者という自己選択された集団についての記述です。「in about 15 minutes」や「in days rather than months」という所要時間は当事者の自己申告で、母数も作業の難易度も示されていません。CIの記事はAnthropic社内のソフトウェア開発という特定の文脈の観察で、受託の工程に同じ比率で当てはまるとは述べられていません。「制約が下流へ動く」という読み替え、内製化が進む領域と進まない領域の切り分け、下流のどこに値段を付けるかの設計は、いずれもA&Aが提案する枠組みであって、測定された手法ではありません。さらに、この主張に対する最も強い反証は同じCIの記事の中にあります。同記事は、下流の仕組みの作り直し自体も一人のエンジニアで三週間、一年前なら四半期近くかかったはずだと述べています。つまり生成が速くなると下流の作業も安くなりえます。検証と復旧が顧客側の手で同じように圧縮されない理由を、本記事は示していません。それが顧客の外に残るというのは本記事の想定であって、出典が示した事実ではありません。当社の受注実績や顧客の成果も示していません。

A&Aの考え方

次の一歩は、直近の三件の案件について、作業を一行ずつ書き出し、「相手の社内で誰か一人が自分の時間でやり切れるか」を答えることです。やり切れる行が半分を超えたら、商品の名前を書き直す時期です。最初の商品の切り出し方そのものは既刊の「AI受託の最初の商品を決める：一人で売れる業務単位の切り出し方」で扱っています。作るか買うかという顧客側の判断は「既存ツールで始めるか、自社の仕組みをつくるか。」が扱います。顧客獲得から継続までの全体の流れは「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」が地図になります。どの下流工程を自社の商品にするかが決めきれない場合は、相談の段階で扱える論点です。