AI化に使うサービスの契約者は、自社か委託先か：名義・APIキー・請求先・解約時の移管を確かめる

委託先が作ったAIは、問題なく動いている。ところが契約が終わる段になって、そのAIを動かしているクラウドやAIサービスのアカウントは誰の名義なのか、APIキーを止められるのは誰か、毎月の利用料の請求書は誰宛てに届いていたのか、という問いに、自社で答えられないことに気づく。委託先を決める時点では、機能や費用の比較に目が向き、こうした「持ち主」の話は後回しになりやすいものです。

この記事は、AI化を外部に委託しようとしている経営者と、総務・情報システムの責任者に向けて、委託先を決める段階で確かめておく項目を整理したものです。契約者の中身を四つに分け、契約者の置き方を三つ並べて、契約が終わる日に何が起きるかを比べ、最後に解約の日に受け取る一覧と、規約で確かめる順序を示します。

扱わないことも先に書いておきます。名義や権利の帰属、規約違反の有無といった契約の法的な当否の判断は、この記事ではしません。個別のサービスの規約の中身にも踏み込みません。成果物の権利、入力データの学習への利用、データの削除は別の論点で、ここでは並べ直しません。委託先に個人データを渡す場面は別の記事で、運用が始まってからの記録の持ち方は担当者が替わっても回し続けるための記事で扱っています。

「契約者」の一語に、四つの持ち主が入っている

提案書や見積に「アカウントは自社名義で」と書かれていても、次の四つのうち、どれを指しているのかは分かりません。四つは、別々の人や会社のものになりえます。

持ち主	委託先に聞くこと	決まっていないと起こりうること
契約の名義	サービスの利用契約の当事者は、自社か委託先か	契約が終わるとき、アカウントを自社へ移せるのかが、規約を読むまで分からない
管理者権限	最初の管理者は誰か。何人いるか。管理者の連絡先は誰のものか	委託先の担当者が替わったとき、権限の追加や削除を頼める窓口がない
APIキーなどの認証情報	誰が発行し、どこに置き、止めたいときに誰が操作できるか	漏えいが疑われても、止める操作をできる人が決まっていない
請求先と支払い方法	請求書の宛名は誰か。支払い方法は誰のものか。利用量の上限は誰が設定するか	利用料が想定より増えたとき、誰が気づき、誰が止めるのかが決まっていない

「自社名義で作る」ことを委託先選びの条件にする、という考え方は、委託先選びの解説にも書かれています。この記事は、そこから先の、名義以外の三つと、置き方ごとの負担に絞っています。

名義を決めても、「最初の管理者」は別に残る

クラウドの例として、AWSの公式資料（IAMユーザーガイド。2026年10月15日に確認した版）を読むと、次のように書かれています。アカウントを作ると、最初に、アカウント内のすべてのサービスとリソースに対する完全なアクセス権を持つ「ルートユーザー」ができる。ルートユーザーは、アカウントの作成に使ったメールアドレスとパスワードでサインインする。AWS Organizationsに属さない単体のアカウントでは、メールアドレスやルートユーザーのパスワードの更新、アカウントの閉鎖に、ルートユーザーの認証情報が必要になる。

つまり、このクラウドでは、アカウントの名義とは別に、「最初のメールアドレスと認証情報を誰が持つか」が、後の管理に関わります。委託先の担当者のメールアドレスで作られたアカウントは、名義を自社に移したとしても、最初のメールアドレスの受信箱が委託先に残っているなら、ルートユーザーの入り口の一つは委託先のものです。ほかの管理者を追加できるかどうかなど、AWSの仕組みの詳細は、この記事では確認していません。

ここで書いたのは、AWSの資料に書かれている仕組みです。ほかのクラウドやAIサービスが同じ仕組みとは限りません。AIサービス側の管理者の仕組みは、この記事では確認していません。使う予定のサービスごとに、公式資料で「最初の管理者は誰か」「管理者を追加できるか」「請求情報を変更できる役割は誰か」を確かめてください。

管理者の連絡先は、退職や異動で受信できなくなる個人のアドレスではなく、部署で受け取れる窓口のアドレスにしておく、という置き方もあります。どれにするかは、自社の管理体制で決める部分です。

契約者の置き方は三つ。選ぶ前に、契約が終わる日に何が起きるかを並べる

契約者の置き方は、大きく三つに分かれます。どれが正しいかは、業務の重さ、自社の管理体制、使うサービスの規約によって変わります。ここでは、どれも一長一短があるものとして並べます。

置き方	平時に自社が負うこと	契約が終わる日に起きること	委託先を選ぶ段階で確かめること
A 自社が契約し、委託先に権限を貸す	請求書の受取と支払い、管理者の指名、規約への同意、キーの漏えいが疑われたときの対応	アカウントは自社のものとして残る。作業の中心は、委託先に貸した権限を外すことと、設定や手順を自社が扱える形で受け取ること	貸す権限の範囲、権限を外す手順と実施する人、外した日の記録の残し方
B 委託先が契約し、費用を転嫁する	請求書は委託先経由で届く。利用の中身が自社から見えにくくなりうる	アカウントが委託先のものなら、自社が使い続けるには、移管するか、自社で作り直すかの判断が要る。移管の可否は、各サービスの規約で確かめる必要がある	利用明細を自社が見られるか、費用への上乗せの有無、解約と移管に協力してもらえる条件
C 併用する（例：試作は委託先の契約、本番は自社の契約）	二つの置き場の管理。どちらに何があるかの把握	本番に切り替える日が、名義を移す区切りになる	どの段階で自社の契約に切り替えるか、切り替えの作業を誰が持つか、試作の環境を残すか閉じるか

Aは、契約が終わる日の見通しが立てやすくなる反面、請求書の処理、管理者の指名、キーが漏れた疑いがあるときの対応を、自社が担う前提になります。社内にその担当を置けるかどうかが、判断条件の一つです。Bは、自社の手間は少なくなりやすい一方、契約が終わる日の扱いが、委託先との取り決めとサービスの規約の両方に左右されます。Cは、切り替えの日が決まっていないと、試作のアカウントがそのまま本番を動かし続けることがあります。

「自社名義にすれば安全」とは言えません。自社名義にした場合の負担を引き受けられないまま、キーの管理や請求の確認が止まってしまう例も考えられます。引き受けられる範囲で、置き方を選ぶ必要があります。

APIキー：発行する人と、止められる人を分けて聞く

APIキーは、サービスを呼び出すための秘密の文字列です。キーの値そのものは、見積書にも、契約書にも、メールやチャットにも書きません。委託先に聞くのは値ではなく、取り扱いの手順です。

• 誰が発行するか。自社の管理者が発行して委託先に渡すのか、委託先に与えた権限で委託先が発行するのか
• 委託先の作業環境のどこに置くのかを、文書で説明してもらえるか
• 開発中と本番で、キーを分けるか。分けるなら、誰が切り替えるか
• 止めたいとき、自社の誰が、どの画面や手順で止められるか。委託先に依頼する形なら、連絡の経路は何か
• 委託先の担当者が替わったとき、キーを作り直すか
• 契約が終わる日に、渡していたキーを無効にする人は誰か。新しいキーへの切り替えは、無効にする前か、後か

止める操作を誰に許すかは、サービスの権限の仕組みで決まります。仕組みはサービスごとに違うため、使う予定のサービスの公式資料で確かめてください。

見積の「実費は別」を、請求先の問いに言い換える

見積に「クラウド・外部API・ライセンス等の実費は別」と書かれている場合、実費を誰が負担するかを確認するように勧める解説はあります。それに加えて、請求書の宛名と、利用の明細が誰から見えるかを、次の順に聞くと、置き方（A、B、C）の違いが見えてきます。

1. 実費の対象に、どのクラウド、どのAIサービスが入るのか。サービス名を挙げてもらう
2. 請求書の宛名は、自社か委託先か
3. 委託先経由で請求される場合、元の利用明細を自社が見られるか。費用への上乗せはあるか
4. 利用量が増えたとき、利用量の上限を設定するのは誰か。上限に近づいたとき、誰に連絡が行くか
5. 試作の期間と、本番の期間で、請求の置き方が変わるか

次の二つの回答は、架空の例です。委託先Xは「実費は別で、当社名義で契約し、月ごとにまとめて請求します」と答えた。委託先Yは「自社名義で作成していただき、請求はサービスから直接届く形にします」と答えた。どちらが良いとは、この二つの回答だけでは決まりません。Xには、元の明細を見られるかと、解約のときに自社へ移せるかを聞きます。Yには、請求書を受け取って支払う担当と、管理者を自社の誰にするかを聞きます。

解約の日に自社が受け取るものを、先に一覧にしておく

契約を終えるときに確保するものを洗い出す考え方は、委託先の乗り換えを扱う解説にもあります。その考え方を、乗り換えの場面ではなく、委託先を選ぶ段階に前倒しして使います。受け取るものを選定の時点で一覧にしておけば、見積や契約の条件に載せやすくなります。

受け取るもの	渡す側の作業	受け取ったと言える状態
アカウントの管理者権限	自社の管理者を追加する（または名義を移す）。そのあとで委託先の管理者権限を外す	自社の管理者で入れる。委託先の権限が残っていない
APIキー	旧キーを無効にし、新しいキーを発行する	旧キーでは動かず、新しいキーで動く
設定と指示文の内容、外部サービスとの連携の設定	自社が参照できる形で渡す	自社の担当者が、どこを変えると何が変わるかの説明を受けた
利用の履歴やログ	取り出せる範囲と形式を示す	自社が保管し、見られる場所にある
請求	宛名と支払い方法を自社に切り替える。最後の請求を精算する	次の請求書が自社の宛名で届く
委託先側に残るアクセス	連携に使っていた許可や、委託先の端末に残る設定を洗い出して外す	外した項目と日付の一覧がある

順序は、先に自社の管理者を確保してから、委託先の権限を外します。逆にすると、外した直後に自社が入れない状態になりえます。

名義の変更や移管ができるかは、サービスの規約で確かめる。順序はこう

名義の変更やアカウントの移管ができるかどうかは、サービスごとの規約に左右されます。この記事では、個別のサービスの可否は確認していません。確かめる順序だけを示します。

1. 利用規約と契約の条項から、契約当事者の変更、権利の譲渡、アカウントの移管、解約、アカウントの削除にあたる箇所を探す
2. 見つからない、または読み取れないときは、サービスの窓口に質問し、回答を文書（メールなど）で残す
3. 「移管できない」という回答なら、自社が最初から契約する置き方（A）を選ぶ判断材料になる
4. 規約は改定されうるため、確認した日と、確認した版を記録しておく

委託先との契約と、サービスの規約の関係（どちらが優先するか、規約に反しないか）は、専門家に確認してください。この記事は、個別の契約や規約の当否を判断するものではありません。

回答が次のようなときは、条件を詰めてから進める

委託先の回答が曖昧なまま進むと、あとで困りやすい場面があります。回答の例と、詰める内容を並べます。

委託先の回答の例	詰めること
「アカウントは、動くようになってから整えます」	整える時期と、整える人。整えるまでの間、誰の名義で、誰のメールアドレスで動かすか
「開発中は、共通のキーを使います」	共通キーを使う期間。本番に入る前に作り直す手順と、作り直す人
「管理者は、うちの担当が持っています」	担当が替わったときの連絡先。自社にも管理者を置けるか
「利用料は、実費でまとめて請求します」	元の利用明細を見られるか。上乗せの有無
「解約のときは、ご相談しながら進めます」	受け取るものの一覧（前の表）を、契約に載せられるか

どの答えも、すぐに「だめ」とは言えません。ただ、時期や人が決まっていない答えは、契約が終わる日まで持ち越されやすいものです。選定の段階で、時期と人を決めてもらいます。

当社の公開ページに書いていること

当社は、委託先の候補にもなりえます。当社が公開している業務AI化の説明では、要件整理、設計、PoC、受入試験、運用改善の工程を挙げています。PoCから本番化に進む節では、本番で使うデータ・権限・環境への切り替え方を、最初に決めておく点として挙げています。委託先の選び方の記事では、責任分界（どこまでが委託先で、どこからが自社か）を文書で確認することを案内しています。

一方、アカウントの名義、APIキー、請求先の扱いについては、当社の公開ページには書いていません。この記事の質問は、当社を含め、どの候補にも同じように聞いてください。進め方の全体は、AI業務設計・業務AXと、業務AI化の委託先の選び方に、運用を誰が持つかの考え方は、内製か外注か併用かの記事に掲載しています。

確認に使った資料

• AWS Identity and Access Management ユーザーガイド「AWS アカウントのルートユーザー」（AWSの公式資料。2026年10月15日に確認）

AWS以外のクラウドやAIサービスの管理者・請求・移管の仕組みは、この記事では確認していません。使うサービスの最新の公式資料と規約で確かめ、契約の当否は専門家に確認してください。

契約者と解約の日を、自社の業務に当てはめて整理したい方へ

どの置き方を選ぶかは、業務の重さと、自社で引き受けられる範囲で決まります。候補の委託先に聞く項目を、自社の業務に沿って整理してから進めると、見積の比較もしやすくなります。

AI化を外部に委託する前に、契約者・APIキー・請求先・解約時の移管を、自社の業務に沿って整理したい方は、個別相談の予約へお進みください。（個別相談会（30分）の予約ページへ移動します）