外注したAIのプロンプト開示：自社で変える範囲と保守の境目
外注したAIの中身は、自社で変更する部分を開示させ、変更した時点で外注先の保守から外すと契約前に決めます。
この記事の要点
- 開示させる範囲は、プロンプトなど自社で変更する範囲と同じ線で引く
- プロンプトと連携設定は開示させ、変更したら保守が外れると決める
- 評価セットは見るだけにして、合否を決める物差しに残す
- 外注先の保守は最後に検証した構成に付け、外れた保守は再検証で戻す
目次
開示の線は、自社で変更する範囲と同じ所に引く
A&Aの考え方
外注先に作らせたAIの中身は、見せてもらえるかどうかではなく、自社で変更するかどうかで開示させる範囲を決めます。ここで言う開示範囲とは、外注先が作った仕組みの中身のうち、発注側が読める形で受け取る部分のことです。
A&Aの考え方
中身には、AIへの指示文であるプロンプト、合否を決めるための評価セット、メールや社内チャットとつなぐ連携設定があります。どれを開示させるかを「隠されると不安だから」で決めると、後で困ります。
A&Aの考え方
開示させた部分は、自社で変えられるようにするのが原則です。自社が変えた時点で、その部分は外注先が確かめた形ではなくなり、外注先の保守から外れます。開示させる範囲、自社で変える範囲、保守から外れる範囲。この三つを、同じ一本の線にそろえます。
A&Aの考え方
この線を契約前に決めておかないと、困るのは仕組みが壊れた時です。自社と外注先のどちらの変更が原因かを調べる作業が、見積もりに無いまま残ります。調べる前から、押し付け合いになることもあります。
出典に基づく事実
AIで業務を自動化する道具を提供するGumloopは、2026年2月に自社のサポート運用を記事にしています。サポート担当は2人だけで、その仕組みは全利用者が使えるのと同じ部品で作ったと書いています。仕組みは数か月かけて、自動化の手順を一つずつ足しながら育ったそうです。
A&Aの考え方
この記事を書いているAutomate & Augment（A&A）は、ここから、外注先から受け取る中身について次のことを読み取ります。部品が全部見えていても、それをどう組むかと、どう直し続けるかまでは受け取れません。中身を全部受け取っても、それだけで自社で回せるようにはならないということです。
A&Aの考え方
反対に、開示させなくてよい部分もあります。外注先がほかの案件と共通で使っている、AIを動かしたり失敗を知らせたりする土台の部分です。自社で変えることが無いので、外注先が保守を持ったままで構いません。
プロンプトと連携設定は、変更したら保守が外れる
A&Aの考え方
プロンプトと連携設定は開示させて自社で変えられるようにし、変えた時点で保守が外れると契約前に合意します。どちらも、業務が変われば変わる部分だからです。
仮想例
たとえば、問い合わせメールの一次仕分けをAIで行う仕組みを、外注先に作らせるとします（仮の例です）。プロンプトの本文、仕分けの区分、担当者に回す基準の値、通知先は、業務が変われば変わります。これらは自社で変える側に入れます。
A&Aの考え方
連携設定も同じ側です。連携設定とは、受信箱や社内チャットとつなぐための、接続先と、接続に使う鍵（パスワードにあたる文字列）の設定のことです。鍵は自社の物なので、担当者が辞めた時などに自社で入れ替えられる必要があります。
A&Aの考え方
ここで一つ決めておくことがあります。鍵を入れ替えると、外注先が何もしていなくても、構成は確かめた形から外れます。これは自社の落ち度ではないので、鍵の入れ替えに伴う確認は、無料で受けてもらう取り決めにします。
A&Aの考え方
通知先に担当者を足すような小さな変更でも、扱いは同じにします。小さい変更と大きい変更の境目を契約で決めると、壊れた時にその境目でまた揉めるからです。そのかわり、小さな変更でも、変えたことは外注先に伝えておきます。
A&Aの考え方
「触ったら保守しない」とだけ書くと、社内の誰も怖くて触れません。それでは開示させた意味が消えます。外れた保守を元に戻す手順まで決めて、初めて開示が役に立ちます。
A&Aの考え方
医療や金融のように、「設定が変わった」では監督する側への説明にならない分野は別です。自社で変える部分そのものを作りにくいので、全体を編集できない形にしてもらう方が実態に合います。
| 中身の部分 | 開示と自社での変更 | 外注先の保守 |
|---|---|---|
| プロンプトの本文・区分・基準の値・通知先 | 開示させ、自社で変える | 変えた時点で外れ、再検証に合格すると戻る |
| 連携設定（接続先と鍵） | 開示させ、自社で変える | 変えた時点で外れる。鍵の入れ替えに伴う確認は無料 |
| 評価セット | 開示させるが、編集権限で変更を止める | 合否は外注先の手元の写しで決める |
| AIを動かし、失敗を知らせる土台 | 開示させなくてよい。自社では変えない | 外注先が持ったまま |
評価セットは見るだけにし、合否の物差しに残す
A&Aの考え方
評価セットは開示させますが、自社では変えない場所に置いてもらいます。評価セットとは、検収（納品物を受け取る時の確認）で合意した合否の基準と、判定に使う実例の組のことです。
A&Aの考え方
物差しを変えると、AIが今も合格しているかを決められなくなります。ここだけは、開示させる範囲と自社で変える範囲が重ならない例外です。合否の判定には、外注先が手元に持つ評価セットの写しを使います。
出典に基づく事実
文章で頼むとアプリを作るサービスのLovableについて、Anthropicは事例のページを公開しています。それによると、Lovableは新しいClaudeが出るたびに、当初から使っている同じ評価を通しています。
出典に基づく事実
測っているのは、仕組みが行き詰まり、壊れたアプリや頼まれた物と違うアプリを出す頻度です。ページは、この確認が大事な理由も書いています。Lovableの利用者の多くは自分でコードを読めず、出力が動くと信じて使っているからだ、としています。
A&Aの考え方
発注側も、これに近い立場にいます。プロンプトを受け取っても、全部を読んで確かめる時間はありません。頼れるのは、変更のたびに同じ評価を通しているかどうかです。だから評価セットは変えずに残します。
A&Aの考え方
ただし、見るだけの区分は「変えないでください」と書くだけでは成り立ちません。成り立つのは、編集権限で変更そのものを止めた時だけです。仕組みが権限を分けられないサービスの上で動くなら、全体を自社で変える側として扱い、合否は外注先の写しで決めます。
A&Aの考え方
合否の基準そのものの書き方は、別の記事「AI納品物の検収条件：出力が毎回違っても合否を決める4項目」で扱っています。
最後に検証した構成に付け、外れた保守は再検証で戻す
A&Aの考え方
外注先の保守は最後に検証した構成に付け、自社が変えた後は、外注先の再検証に合格した時点で戻します。これを取り決めに書きます。最後に検証した構成とは、外注先が評価セットを通して合格を確かめた時点の、設定一式のことです。
A&Aの考え方
再検証とは、自社が変えた後の構成に、外注先が評価セットを通し直して、合格を確かめることです。通らなかった時は、変えた部分を保存した構成の形に戻すか、直しを外注先に頼むかを選びます。
A&Aの考え方
この形にするには、その構成を外注先に実際に保存してもらう必要があります。納品の時と再検証のたびに、鍵の文字列だけを消した設定一式と評価セットを書き出してもらいます。
A&Aの考え方
不具合が出たら、まず保存した構成に評価セットを通します。通れば、いま動いている構成との違いを見ます。これで、どちらを先に調べるかが決まります。ただし、責任の所在まで決まるわけではありません。
A&Aの考え方
変更の連絡は、いつでも無料で受けてもらいます。連絡に料金がかかると、社内で黙って変える動機が生まれるからです。再検証は毎月の点検などに含め、期間内の回数を決めます。
仮想例
仮の例の仕組みなら、取り決めはたとえば次の一文になります。「保守の対象は、受注者が最後に検証した構成とする。発注者がプロンプト・区分・基準の値・通知先・連携設定を変えた時点で対象外となり、定期点検の再検証に合格した時点で対象に戻る」。
A&Aの考え方
月額の保守を払うなら、その中身も同じ形で書けます。稼働の見守り、無料の変更連絡、期間内に含まれる再検証の三つです。三つ目があるので、保守が外れている間も、月額で受けられるものが残ります。
まとめ
A&Aの考え方
開示させる範囲は、プロンプトなど自社で変更する範囲と同じ線で引く
A&Aの考え方
プロンプトと連携設定は開示させ、変更したら保守が外れると決める
A&Aの考え方
評価セットは見るだけにして、合否を決める物差しに残す
A&Aの考え方
外注先の保守は最後に検証した構成に付け、外れた保守は再検証で戻す
外注したAIの開示は、見る範囲・自社で変える範囲・保守から外れる範囲が一本の線にそろって初めて役に立ちます。次に決めるのは、どの部分を自社で変えるかと、外れた保守を戻す再検証をいつ、何回受けるかです。
よくある質問
外注先がプロンプトの開示を断ったら、どうしますか。
その部分は自社で変えない側に入れ、保守を外注先に持ってもらいます。そのうえで、業務が変わるたびに変更を頼む費用を見積もりに入れてもらい、開示させた場合と比べます。
中身を全部開示させれば、外注先を替えやすくなりますか。
乗り換えの手間は下がります。ただし、どう組むかと、どう直し続けるかまでは受け取れないので、全部受け取っても、それだけで自社で回せるようにはなりません。
この取り決めは、どこに書けば効きますか。
外注先の見積書の前提条件に書いてもらい、自社の発注書に「見積書の前提条件を含む」と一行入れます。法的にそのまま通るかは別の問題で、契約書にする前に専門家への確認が要ります。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Supporting the world’s most AI-native companies with a 2-person team
Gumloop · 2026-02-17
確認日 2026-10-23 - Lovable helps anyone create software 20x faster with Claude
Anthropic · no date shown on page
確認日 2026-10-23