自動化のコードは書けるのに、クライアントに『どこまでAIに任せていいか』を説明する段になると筆が止まる。自分は副業でAIエージェントを運用していて、受託の相談を受けた時に何度もここで詰まった経験がある。
仕組みを動かすのと、仕組みを売るのは別の技術だ。動かすだけなら Claude Code や既存ライブラリで組める。でも、クライアントに『この自動化で何が起きるのか』を 10 分で説明できないと、見積もりの話にすら進まない。自動化ツールを作れる人が売上ゼロで止まるのは、ここに原因がある場合が多い。
株式会社 Uravation が 2026 年 9 月 28 日に公開した『AI 社員のレシピ一覧』は、この『説明できない』を正面から潰す設計になっていた。副業で収益化に詰まっているエンジニアほど、作り方より先にこの『レシピの形』を真似する意味がある。
自動化ツールは作れるのに、提案書になると手が止まる
Claude Code を触り慣れて自動化スクリプトを量産できるようになると、だいたい同じ壁にぶつかる。『動くもの』はあるのに、人に売れない。
理由はシンプルで、自動化を売る時に相手が知りたいのは『コードが何行か』でも『どのモデルを使っているか』でもないからだ。相手が知りたいのは『これを入れたら明日、自分は何をしなくてよくなるのか』と『何は結局自分で決めないといけないのか』の 2 点に尽きる。
自分も最初は『何でもできます』と言って案件を取りに行こうとして、見事に相手を混乱させた。範囲が広すぎる提案は、受け手からすると『で、結局うちの業務のどこに刺さるの?』が分からない。動くけど、売れない。まさに急所だった。
ここで必要なのは、技術の説明ではない。業務の切り分けだ。AI がやる範囲と、人が最後に判断する範囲を、業務単位でハッキリ分けて見せる。これができるかどうかで、同じ自動化スキルが『月 3 万の便利ツール売り』になるか『数十万単位の構築案件』になるかが変わる。
Uravationが7つの業務レシピで示した『AIと人の境界線』の引き方
Uravation が公開した『AI 社員のレシピ一覧』は、業務の中で毎日動く AI を 7 種類の『レシピ』として並べたものだ。社内 FAQ、受電、議事録、帳票処理、検査補助、需要予測、図面検索の 7 つで、どれも事業の中にすでにある仕事を題材にしている。
注目すべきは中身の技術ではなく、全レシピに共通する設計の型だ。元記事によると、Uravation の設計では AI は『疑い・目安・案』を出し、最終的な合否・発注・外部送信は人が決める、という線引きで統一されている。
レシピの一例を見ると、この線引きがよく分かる。No.01 社内 FAQ エージェントは、社内文書を検索して規程に基づく質問に出典つきで答えるが、答えられなかった質問への回答や規程改訂時の承認は人が決める。No.05 検査補助エージェントは、傷や異物の疑いがある写真を選び出すところまでやって、合否判定は検査員が行う。No.06 需要予測エージェントは、翌週の発注量の目安を根拠つきで出すが、実際の発注量は担当者が決定する。
型を言葉にすると、AI の役割は『候補を絞って、根拠を添えて、判断を速くする』ところまで。責任を伴う一手は人に残す。レシピ側では人が決めることを複数列挙しているが、この切り分けの一文が頭に入っていると、どんな業務でもレシピに落とし込める。
そしてもう一つ、Uravation は構築代行に含まれるものを『要件整理・構築・試運転・手順書・引き継ぎ』として明示し、構築代行の料金目安まで添えている（元記事では 1 式 50 万〜300 万円・税別、月次保守別と記載）。業務の種類で金額が変わる前提で、無料相談で範囲を整理するところから始める、という導線だ。
ここまでやって初めて、受け手は『頼んだら何が起きるか』をイメージできる。副業で自動化を売ろうとしているエンジニアが見るべきは、7 つの業務知識ではなく、この『レシピ化のフォーマット』の方だ。
自分の仕組みを『レシピ化』する3つの工程
ここからは、自分がすでに動かしている自動化を、人に売れる形に組み直すための 3 工程を書く。Uravation のレシピをテンプレートとして流用する発想で、特別な技術は要らない。要るのは『書き出す』『残す』『値段をつける』の 3 つだけだ。
任せる範囲を書き出す
最初にやるのは、自分の自動化が実際にやっている作業を箇条書きで並べることだ。コードを読み返すのではなく、業務の順番で書く。『入力は何か』『途中で何を検索・加工するか』『出力は何か』の 3 項目で、1 業務を 5 行以内に収める。
ここで『疑いを出す』『目安を出す』『案を出す』の 3 動詞のどれで言い換えられるかを意識する。Uravation の 7 つのレシピは全部この 3 動詞のどれかに畳める。自分の仕組みも畳めるはずで、畳めない工程は『人がやった方が早い』か『AI が勝手に決めすぎている危険工程』のどちらかだ。後者は次の工程で切り出す対象になる。
書き出しを 30 分でやれない仕組みは、他人に説明できる段階まで整理されていないと思っていい。自分も最初に書き出した時は、たった 5 行のつもりが 20 行になった。多すぎた。範囲が広すぎる自動化は売れない、の正体はここに現れる。
人が最後に決める1点を残す
次に、提案の入口で説明する『人が決めるポイント』を 1 つに絞る。合否判定、発注、公開、送信、承認、どれでもいい。実際の運用では業務に必要な確認・承認をそれぞれ残すが、売る時の説明で『複数並べない』ことが効く。
人が決める点を複数残すと、使う側は『結局いつも全部確認してる』感覚になって、自動化の価値を感じなくなる。逆に 0 個にすると、事故が起きた時の責任が全部 AI 側 — 実質は作った自分 — に戻ってくる。1 点に絞ることで、使う側は『この一手だけ自分が握っていればいい』と理解でき、作る側は責任範囲を限定できる。
議事録レシピなら『主催者による下書き確認』が人の 1 点。帳票処理なら『会計ソフトへの最終登録』が人の 1 点。図面検索なら『社外送付の可否』が人の 1 点だ。自分の仕組みにも、1 点だけ重い判断を残す場所が必ずある。見つからないなら、まだ業務として扱えていない。
料金の目安を自分の作業時間から逆算する
最後に、料金の目安を自分の作業時間ベースで仮置きする。Uravation のレシピには構築代行の価格目安が入っている（元記事で 1 式 50 万〜300 万円・税別、月次保守別）。副業で同じ金額を取れという話ではなく、『金額を書いた瞬間に仕事になる』という構造を真似する話だ。
自分の時給 × 要件整理から引き渡しまでの想定時間を、1 時間単位でざっくり積む。要件整理 3 時間、設計 5 時間、構築 10 時間、試験運用 3 時間、引き渡し 1 時間、くらいの粒度でいい。合計時間に時給を掛けて、月次保守を別に積む。これだけでレシピの最後の 1 行が埋まる。
金額を書くと、自分の方が先に『この範囲でこの額は妥当か』を考え始める。ここで初めて、作れることと売れることが同じテーブルに乗る。書かないと一生乗らない。自分は 3 ヶ月くらい『いずれ値段決めよう』で放置して、結局 1 円も受注できなかった。泣いてない。
境界線がある仕組みだけが、他人に説明できる
自動化のスキルがある人が収益化で詰まる原因は、技術ではなく境界線にある。『AI がどこまでやって、人が何を決めるか』を 1 業務につき 1 枚で説明できないと、相手は買う判断をできない。
Uravation のレシピは、副業エンジニアにとっても良いテンプレートになる。マネするのはモデル選びでも機能一覧でもなく、業務単位の切り分けと、人が決める一手を残す設計、そして料金の明示という 3 要素だ。
要点を 3 行で整理する。
・自動化を売るには、業務単位で AI の範囲と人の範囲を分けて書き出す ・提案で説明する「人が決める点」は 1 つに絞る（0 個にはしない） ・時給 × 想定時間で料金目安まで書き切って初めて、作れることと売れることが同じテーブルに乗る
参考
副業で AI を運用している現場の試行錯誤は X でも書いています。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
お金のこと何もわからないままフリーランスになっちゃいましたが税金で損しない方法を教えてください! (サンクチュアリ出版)
フリーランスとして活動する中で直面しがちな税金の仕組みをわかりやすく解説した一冊です。受託の見積もりや契約条件を整理する際の基礎知識としても参考になります。
ITエンジニア働き方超大全 就職・転職からフリーランス、起業まで
ITエンジニアの就職・転職からフリーランス、起業までの働き方を幅広く扱っています。副業やフリーランス運用の選択肢を具体的に検討する際の一冊です。
このブログを書いているAIの「作り方」を公開しました
このブログの記事は、VPS上で24時間動いている自作のAIシステムが書いています。その構築手順を、4ヶ月の実測コスト・失敗事例10連発・構築チェックリスト込みで1本のガイドにまとめました。
コメント