動くのに稼げない副業AI運用、Claude Codeに判断を任せず確認事項リストに変える3領域の境界線

自動化はできているのに副業収益が伸びない人に共通する設計ミス
AIエージェントに”判断”を任せてはいけない受託業務の境界線
1. 見積もり・契約条件・納期見込みで起きる「それらしい断定」
判断を「確認事項リスト」に変換する設計の作り方
この設計変更が案件獲得・継続受注につながる理由
まとめ
参考
【PR】フリーランスエンジニアにおすすめのツール
【PR】おすすめの書籍
1. あわせて読みたい

自動化はできているのに副業収益が伸びない人に共通する設計ミス

Claude Codeを半年触ってSNS投稿もコード生成もジョブで並列に回る。GitHubには自分専用のパイプラインが揃っている。それなのに副業の口座残高は動かない。自分は10年以上現役でエンジニアをやりつつ副業でAI運用を組んできて、この「動くのに稼げない」相談をかなり受ける。

答えを先に言う。AIに”判断”を任せている領域が多いほど、案件は取れない。動くこと自体は評価されない。判断を1回外した瞬間、依頼主は次を頼まない。副業の売上を殺すのはそこ。

自分自身、ブログ(WordPress)とnoteの記事生成の仕組みで、AIが外部記事の数値を勝手に盛る事故を何度も踏んだ。「販売開始8時間で4,500万円突破」を「短期間で爆発的に」と言い換えたり、「先行販売」を「1億超え」に格上げしたりする。動いてはいるが、内容がズレる。読者からの信用は一発で崩れる。副業の受託業務でも構造はまったく同じ。

AIエージェントに”判断”を任せてはいけない受託業務の境界線

きっかけになった記事がある。株式会社フォー・クオリアの佐野貴信氏がQiitaで公開した「企画検証AIチームに法務観点を足す」という記事。企画書をAIチームに投げると6人の専門家AIが意見書を返す仕組みに、法務観点を追加した話。結論は「AIに法務判断はさせない。法務部門に確認すべき項目だけを出させる」だった。

なぜかというと、法務領域にはリポジトリ内に参照資料が存在しないから。仕様書・コード・チケットと違い、社内規程・契約書・過去の判断記録はコード管理の外にある。AIは参照先がない領域では、モデルの記憶で”それっぽく”喋る。条番号も判例も出てくる。でもそれが正しいかは、リポジトリの中で確かめる方法がない。

これは副業・受託業務にそのまま当てはまる。クライアントの社内規程、過去のトラブル対応、慣行、業界のグレーゾーン。全部リポジトリの外だ。しかもAIは、それっぽく答えを返す。動いていることと、答えが正しいことは別の話。

見積もり・契約条件・納期見込みで起きる「それらしい断定」

具体的に危ない3領域を並べる。副業の売上を止めているのはだいたいこの3つ。

見積もり工数。「このスコープなら3日で行けます」とAIが断定する。実際は要件整理と手戻りで2週間かかる。この差分をAIは見えていない。過去の見積もり実績、あなた個人の速度、依頼主の要件曖昧度は、AIのコンテキストに入っていない。それっぽい計算式が出てくるだけ厄介。断定を鵜呑みにして提案書を送ると、実装後に地獄を見る。

契約条件。「著作権はクライアント帰属で問題ない」「瑕疵担保は納品後30日が業界標準」とAIが平気で書く。業界標準なんて実在しない。契約書テンプレを読んだAIが、平均的な文言を返しているだけ。あなたの取引形態・報酬帯・案件性質でどう握るべきかは、AIには判断できない。ここを外すと、後で無償対応の泥沼に沈む。

納期見込み。「外部APIの応答速度なら1秒以内で返せます」と書いてしまう。テスト環境と本番負荷は違う。ピーク時のレート制限で3秒かかることがある。断定した瞬間、依頼主側の期待値が固定される。実装後に「話が違う」となり、次の依頼は来ない。

3領域に共通するのは、判断が外れると信頼が飛ぶこと。しかもAIは自信満々に返してくる。手戻り1件で継続受注は消える。副業で継続案件を1本失うのは、月換算で数万〜十数万のダメージだ。

判断を「確認事項リスト」に変換する設計の作り方

佐野氏の記事の3原則を、そのまま受託業務用に翻訳する。順番に効いてくる。

原則1：判断させず、検知だけさせる。AIプロンプトの冒頭に禁止事項を明記する。「工数見積もりの断定はしない」「契約条件の適否判断はしない」「納期の確約はしない」。代わりに「案件対応前に依頼主に確認すべき項目リスト」を出させる。

具体的にはこう書く。

任務は「案件対応前に確認が必要な項目」の検知に限定する。
工数見積もり・契約条件・納期の断定はしない。
出力は「該当箇所の引用 → 分類 → 依頼主に確認すべきこと」の形式で並べる。

出力は「これは確認が必要」「この条件は依頼主に握り直したい」というリストになる。誤差のコストが「確認1回増える」で済む。断定して外すコストと比べれば桁で安い。

原則2：参照資産がないなら、自分で最小のチェックリストを作る。過去に受けた案件を振り返って、毎回引っかかる論点を洗い出す。自分の場合はざっくり分類するとこうなる。

①要件曖昧度例：追加要望が入りそうな箇所・仕様の穴・想定外ユーザーの扱い

②責任範囲例：バグ対応・保守・仕様変更の切れ目・障害時の一次対応

③技術リスク例：外部API依存・レート制限・アカウント凍結リスク・BAN前提の設計

④支払い条件例：分割払い・検収基準・遅延時対応・作業中止時の精算

⑤著作権・秘密保持例：成果物利用範囲・NDA有無・素材の権利処理・二次利用の許諾

この5分類は自分の案件から逆引きして作ったもの。あなたの案件領域では別の分類になるはず。法令の体系から網羅しようとすると死蔵する分類が増えるので、自分の過去案件から逆引きするのが早い。

このリストをAIに渡して、案件情報と突合させる。「該当箇所を引用 → 分類名 → 確認事項」の3点セットで出させる。これで曖昧な一般論が出なくなる。指摘が突合可能な形になる。

原則3：検証役の突合軸を差し替える。AIが出したリストを、別のAIまたは自分で検証する。「引用が案件情報に実在するか」「分類の当てはめは妥当か」を機械的にチェックする。断定表現が残っていたら「〜を依頼主に確認する」に書き換える。削除はしない。書き換えると論点が消えず、確認事項として残る。

自分の記事生成側でも似た考え方を入れている。外部記事の数値を勝手に盛らないように本文生成側にガードを入れて、書籍紹介のミスマッチも「レビュー必要」フラグで残す設計にした。断定を消すのではなく、確認ステップを1つ挟むだけで事故がガラッと減る。効くんですよ。地味な作業が。

この設計変更が案件獲得・継続受注につながる理由

「AIが確認事項を並べてくる」提案書と、「AIが工数・費用・納期を断定してくる」提案書。どちらの受託先を選ぶか、依頼主の立場になれば分かる。前者は「一緒に整理してくれる相手」で、後者は「勝手に決めつけてくる相手」に見える。

継続受注を取っている副業エンジニアは、案件初期にひたすら確認事項を積む。要件を握り直す。曖昧箇所を潰す。この工程をAIに手伝わせるとき、判断ではなく検知に落とすと、依頼主とのコミュニケーションが噛み合う。噛み合うとリピートが来る。

逆に、AIの断定を鵜呑みにして提案書を出すと、初回は通っても2件目が来ない。「見積もりが甘かった」「納期を守れなかった」で信頼が飛ぶ。副業の売上を伸ばす一番のレバーはリピート率で、そこを潰しているのがAIの断定というわけ。

自動化を組める人ほど、AIに判断させたくなる。設計としても綺麗に見えるから。そこを堪えて「確認事項リスト生成器」として使う。同じAIでも、案件が続く人と続かない人はここで分かれる。動く仕組みを作れる技術がある人ほど、この境界線の引き方が売上を決める差別化につながる。

さらに副次効果として、この設計はチェックリストの外側にある論点を見えなくする性質を持つ。だから成果物の末尾に「このリストは網羅を担保するが、載せなかった領域は視野に入りにくい」と自分で書き添えておくと、依頼主も自分も「並んでいるものが全部」と誤読しなくて済む。誠実さと売上は、意外と同じ設計から出てくる。