AI外注の納品物、他社への再利用を許すか:見積り前に3層で決める
AI外注の納品物は、見積りを頼む前に3層に分け、外注先の再利用を汎用の足回りだけに認めます。
この記事の要点
- AI外注の納品物を3層に分ける(自社データ・業務ロジック・汎用の足回り)
- 自社データと業務ロジックは自社に残し、外注先には足回りだけ再利用を認める
- 見積りを頼む前に、再利用を認める層を伝える
- 一文を足すか、契約書をそのまま使うかは、成果物の権利の条を読んで決める

目次
まずAI外注の納品物を3層に分ける

A&Aの考え方
AIの仕組みを外注したら、納品物は自社データ、業務ロジック、汎用の足回りの3層に分けて考えます。汎用の足回りとは、データの取り込みやAIへの接続、失敗した時のやり直し、記録のように、どの会社の仕組みでも同じ形になる部分のことです。
A&Aの考え方
自社データは、過去の書類や顧客名簿など、仕組みに読ませる自社の情報です。業務ロジックは、値引きの条件や断る仕事、受け取る時の合否の基準のように、自社の決めごとを仕組みに書き込んだ部分です。
仮想例
たとえば、社員4人の工務店が、問い合わせのメールから見積書の下書きを作る仕組みを外注するとします。仮の例ですが、自社データは過去の見積書、顧客名簿、単価表です。
仮想例
業務ロジックは、値引きの条件、断る工事、見積書を誰が承認するかの決まり、受け取る時の合否の基準です。汎用の足回りは、メールの取り込み、AIへの接続、失敗時のやり直し、処理の記録です。
A&Aの考え方
3層に分けるのは、納品物を丸ごとで扱うと、守りたい部分と使わせてよい部分の区別がつかないからです。丸ごと自社のものにすると、足回りまで縛ることになります。逆に丸ごと外注先の自由にすると、値引きの条件まで他社に流れるおそれがあります。
A&Aの考え方
業務ロジックと足回りの境目は、案件ごとに変わります。迷う部分は、自社の決めごとが1つでも入っていれば業務ロジックの側に入れます。
A&Aの考え方
3層への分け方は、この記事を書いている Automate & Augment (A&A) の設計案です。発注前に外注先へどのデータを渡すかは「AI外注で顧客データをどこまで渡すか:発注前に決める3つの区分」で扱いました。この記事は、出来上がった納品物を外注先がどこまで使えるかの話です。
外注先には、足回りだけ再利用を認める

A&Aの考え方
自社データと業務ロジックは自社に残し、汎用の足回りだけは、外注先が他社の案件で使い回すことを認めます。競合に渡って困るのは、データと決めごとのほうだからです。
出典に基づく事実
AIで業務の自動化を組む道具を提供する Gumloop は、2026年2月17日に自社のサポートの事例を公開しました。サポート担当は2人だけで、その仕組みは全利用者が使えるのと同じ部品だけで組んだと書いています。処理は1つずつ足し、数か月かけて育てたとしています。
出典に基づく事実
Anthropic は2025年9月11日の技術記事で、AIに使わせる道具の作り方の助言を公開しました。助言の多くは、社内の道具を直し続けて得たものだと書いています。道具の出来を確かめる試験は、社内で実際に使っている案件・文書・メッセージで作ったとしています。
A&Aの考え方
A&A はこの2つを、部品や作り方が外に出ていても価値が残る例と読みます。価値が残るのは、その会社のデータと決めごとで組んだ部分です。どちらも外注の話ではありませんが、発注する側でも同じ線が引けます。守る線はデータと業務ロジックの周りに引けば足ります。
A&Aの考え方
納品物を受け取る前に動きを確かめる検収で使った実例は自社データに、合否の基準は自社の決めごとなので業務ロジックに入れます。どちらも自社の仕事をそのまま写したもので、他社の案件に持ち出されると困るからです。
仮想例
工務店の例なら、過去の問い合わせメールが実例に、「単価表どおりの金額になっているか」が基準に当たります。
| 層 | 工務店の例 | 外注先が他社の案件に使うこと |
|---|---|---|
| 自社データ | 過去の見積書、顧客名簿、単価表 | 認めない |
| 業務ロジック | 値引きの条件、断る工事、見積書を誰が承認するかの決まり、受け取る時の合否の基準 | 認めない |
| 汎用の足回り | メールの取り込み、AIへの接続、失敗時のやり直し、処理の記録 | 認める |
見積りを頼む前に、再利用を認める層を伝える

A&Aの考え方
どの層の再利用を認めるかは、見積りを頼む時に一緒に伝えます。外注先は、足回りを他社でも使えるかどうかで、作る手間と値段を見込むことがあるからです。
A&Aの考え方
納品の後で「全部自社のものに」と言うと、見積りのやり直しになることがあると A&A は見ています。足回りまで自社専用にするなら、外注先はそれを毎回作り直すことになり、その分が見積りに乗ることがあります。
A&Aの考え方
伝え方は、見積り依頼のメールに3層の表を添え、短い一言を書くだけで足ります。工務店の例なら、見積書の下書きを作る仕組みの見積り依頼に、表と一言を付けます。
仮想例
たとえば次のような一言です。「データと業務ロジックは当社専用でお願いします。メールの取り込みやAIへの接続などの足回りは、他社の案件で使っていただいて構いません。」
A&Aの考え方
見積りを複数の外注先に頼むなら、同じ表と一言をどの外注先にも送ります。条件がそろうので、見積りの差が作り方の差なのか、再利用の扱いの差なのかを分けて見られます。
A&Aの考え方
外注先から「納品物は全部御社のものです」と返ってきた時は、足回りも自社専用になるのかを聞き返します。そうなら、見積りに作り直す分が入っているかもしれないからです。
A&Aの考え方
仕組みそのものが自社の売り物で、足回りまで自社専用にしたい会社もあります。その場合も見積りの前に伝えておけば、作り直す分を含んだ見積りどうしを比べられます。
A&Aの考え方
似た仕組みを続けて頼む予定が無く、外注先も同じ種類の仕組みを他社に作らないなら、表を手元に作っておくだけでも構いません。
一文を足すかは、成果物の権利の条を読んで決める

A&Aの考え方
契約書を交わすなら、成果物の権利を定めた条を読み、一文を足すか、契約書をそのまま使うかを決めます。成果物の権利の条とは、契約書で成果物と呼ぶ納品物について、著作権などが誰のものになるかを書いた条のことです。
仮想例
たとえば、契約書に「成果物の著作権は発注者に帰属する」とだけ書いてあるとします。この一文は著作権が発注者のものになるとだけ言っていて、足回りを外注先が他社の案件で使えるのかは読み取れません。
仮想例
足す一文の例は次のとおりです。自社を「発注者」、外注先を「受注者」と書きます。「発注者が渡したデータと、発注者の業務ロジックは発注者のものとし、受注者は他の案件に使わない。」
仮想例
続けて、もう一文を足します。「データの取り込みやAIへの接続など、汎用の足回りに当たる部分は、受注者が他の案件で再利用できる。」
A&Aの考え方
契約書を交わさず、発注書やメールだけで頼む場合は、発注書に同じ一文を書きます。書いておけば、担当者が替わっても同じ線を確かめられます。
A&Aの考え方
契約書がすでに層ごとに書き分けているなら、一文を足す必要はありません。足すかどうかの目安は、条を読んで、表の3層それぞれを誰が使えるか答えられるかどうかです。
仮想例
工務店の例なら、単価表、値引きの条件、メールの取り込みの3つを、外注先が他社の案件に使えるかを条から読み取れるかを見ます。
A&Aの考え方
この一文の法的な効力は、弁護士に確かめてから使います。A&A は法的な助言をしません。ここで示したのは、どの層をどう扱うかを先に決めておくための形です。
まとめ
A&Aの考え方
納品物は、自社データ・業務ロジック・汎用の足回りの3層に分けます。
A&Aの考え方
データと業務ロジックは自社に残し、外注先には足回りだけ再利用を認めます。
A&Aの考え方
見積りを頼む時に、再利用を認める層を表と一言で伝えます。
A&Aの考え方
契約書の成果物の権利の条を読み、3層それぞれを誰が使えるか答えられなければ一文を足します。
AI外注の納品物で守るのは、自社データと業務ロジックの2層です。次の見積り依頼までに3層の表を作り、足回りの再利用を外注先に認めるかを決めておきます。
よくある質問
納品物は、全部自社のものにする方が安全ではありませんか。
守りたいのがデータと決めごとなら、その2層を自社に残せば足ります。足回りまで自社専用にすると、作り直す分が見積りに乗ることがあります。
外注先が他社向けに作った足回りを、自社の仕組みに使ってもらってもよいですか。
外注先が他社との約束の範囲で使えるなら、使ってもらって構いません。その時は、他社のデータや業務ロジックが混ざっていないかを外注先に確かめます。
外注先の担当者が身に付けたやり方も、他社で使わないよう契約に書くべきですか。
一文の対象は納品物に絞る方がよいと A&A は考えます。担当者の経験まで縛ると、外注先が引き受けにくくなることがあります。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Supporting the world’s most AI-native companies with a 2-person team
Gumloop · 2026-02-17
確認日 2026-10-27 - Writing effective tools for agents — with agents
Anthropic · 2025-09-11
確認日 2026-10-27