AI開発で外部APIに送ってよいデータの決め方。4区分と見積依頼に書く5行

AI 開発の相談で最初に止まるのが「そのデータ、外部の API に送っていいのか」である。情報システム部門に聞くと「持ち帰って検討します」になり、そこで 2 週間止まる。止まっている間に見積もりも取れない。

この判断は、案件ごとにゼロから考えるものではない。データを区分し、区分ごとに外部 API の可否をあらかじめ決めておくと、以後の案件は当てはめるだけで済む。この記事では、その区分の作り方と、区分が費用にどう跳ねるかを整理する。

セキュリティ設計全体の考え方はAIシステムのセキュリティ設計にまとめてある。ここでは「外部に出してよいデータの線引き」だけに絞る。

1. データを 4 つに区分する

区分を細かくすると運用できない。実務で回るのは 4 つである。

区分	中身の例	外部 API への送信
公開	公式サイトの文章、製品カタログ、プレスリリース、公開されている規格	原則そのまま可
社外秘	社内マニュアル、議事録、見積書、設計書、売上の内訳	条件付きで可（規約の確認が要る）
個人情報	顧客名簿、応募者情報、問い合わせ履歴、通話録音	条件付き（法令の確認が要る）
機密	未公開の財務情報、要配慮個人情報、取引先から預かった情報、認証情報	原則不可

区分するときのコツは、「秘密かどうか」ではなく「外に出たときに誰が困るか」で分けることである。社外秘は自社が困る。個人情報は本人が困る。機密は第三者や取引先が困る。困る相手が違うと、必要な手続きも変わる。

判断が割れるのは「取引先から預かった情報」である。自社にとっては業務データでも、預けた側との契約で利用範囲が縛られていることが多い。契約に「第三者への提供の禁止」があるなら、外部 API に投げる時点で抵触する可能性がある。ここは法務に確認する。

2. 個人情報を含むときの法令の確認点

個人情報を外部の API に送るとき、日本の個人情報保護法で見るのは主に 2 か所である。

1 つ目は、そもそも「第三者提供」にあたるかどうか。 個人情報保護委員会の Q&A（7-53）は、クラウドサービスの利用について次のように示している。事業者がクラウドサービスを使っている場合でも、「クラウドサービス提供事業者が当該個人データを取り扱わないこととなっている場合には、当該個人情報取扱事業者は個人データを提供したことにはならないため、『本人の同意』を得る必要はありません」。

つまり、契約や規約の上で提供事業者がそのデータを取り扱わないことになっているかが分かれ目になる。取り扱わないことになっている場合でも、自社側では安全管理措置（アクセス制御など）の義務が残る。

2 つ目は、海外に送る場合の扱い。 外国にある第三者へ個人データを提供する場合は、法第 28 条が適用される。原則として本人の同意が要り、同意を得るときには提供先の国の名称・その国の個人情報保護制度に関する情報・提供先が講じる措置を、あらかじめ本人に伝える必要がある。EU と英国は「同等の水準」として扱われており、この同意は不要とされている。また、提供先が日本と同等の措置を継続的に講じる体制を整えている場合の例外もあるが、その場合は定期的な確認などの義務が発生する。

ここで重要なのは、「第三者提供にあたらない」ルートに乗せられるかどうかで手続きの重さがまったく変わるという点である。要件定義の前に、使う予定のサービスの規約がどちらなのかを確かめておく。

3. サービスの規約で確認する 4 点

区分が決まったら、送り先の規約を見る。確認するのは 4 点である。

確認すること	なぜ要るか
学習への利用	送ったデータがモデルの学習に使われるか。使われない設定があるか、既定でどちらか
保存期間	送ったデータがどれだけ保持されるか。保持しない設定があるか。不正利用監視のための一時保存が別にあるか
処理・保存のリージョン	どの国で処理され、どこに保存されるか。指定できるか
再委託先（サブプロセッサ）	提供事業者がさらに別の事業者を使っていないか。その一覧が公開されているか

この 4 点は、サービスによって答えが違い、同じサービスでもプランや契約形態によって違う。無償プランと法人契約で条件が変わることは珍しくない。「あのサービスは大丈夫」という社内の記憶で判断せず、そのときの規約を見る。

見るときは、開発会社に「調べて教えてください」と丸投げしないほうがよい。規約は発注側の責任範囲に関わる。開発会社に頼むのは「使う予定のサービスと契約形態の一覧を出してもらう」ところまでで、可否の判断は自社で行う。

4. 費用への影響：閉域にすると何が増えるか

「機密は外に出せない」と決めると、選択肢は自社環境で動かす方向に寄る。ここで費用がどう増えるかを、増える項目で押さえておく。

増える項目	中身
計算資源	推論用のサーバまたは GPU。使わない時間も確保しておく必要がある
モデルの選定と検証	自社環境で動くモデルは選択肢が狭い。精度が出るかを先に確かめる工程が増える
構築と維持	導入・アップデート・障害対応。外部 API なら提供側が持っていた部分が自社に移る
ネットワーク	閉域接続、専用線、通信の暗号化と監視
人の稼働	運用を回す担当。ここが一番見落とされやすい

逆に減るのは、API の従量課金と、規約・越境の確認にかかる手続きである。使用量が大きい案件ほど前者の削減幅は大きくなる。

判断は「安全だから閉域」ではなく、使用量と、増える 5 項目の合計で比べることになる。損益の分かれ目の計算方法はAPI利用と自前運用の比較に、環境ごとの費用構造はオンプレミスとクラウドの比較にまとめてある。分野別・フェーズ別の相場はAI開発の費用相場で確認できる。

5. 全部を同じ場所に置かない

実務でよく効くのは、区分ごとに置き場所を変えるという設計である。

• 公開・社外秘のデータを使う機能 → 外部 API
• 個人情報を含む機能 → 個人情報を取り扱わない契約形態の外部サービス、またはリージョン指定
• 機密を含む機能 → 自社環境

この分け方をすると、機密を含む一部の機能のためだけに、システム全体を閉域にするという事態を避けられる。全体を閉域にすると費用は跳ね上がるが、対象の機能はたいてい一部である。

そのためには、設計の段階でデータの流れを区分ごとに分けておく必要がある。後から分けるのは作り直しになる。ここは要件定義で決めておく項目である。手順はAI開発の要件定義を参照してほしい。

もう 1 つ、入力そのものを減らす手もある。外部に送る前に個人情報の部分を伏せる（マスキング・仮名化する）処理を挟むと、区分が 1 段下がる。この処理自体に工数はかかるが、閉域構築より安く済む場合が多い。

6. 案件票・見積依頼に書く形

ここまでの内容を、見積もりを取るときの文面に落とす。曖昧に書くと各社が別々の前提で見積もり、金額が割れる。

そのまま使える書き方

• 扱うデータの区分:「公開」「社外秘」を扱う。「個人情報」は含まない（または: 氏名とメールアドレスを含む）
• 外部 API の利用: 可（ただし学習に利用されない契約形態であること）／ 不可（自社環境で完結すること）
• 処理・保存のリージョン: 日本国内に限る／指定なし
• ログの保持: 入力データを保持しない設定にできること。保持する場合は期間を明記すること
• 再委託先: 使用するサービスと再委託先の一覧を提出すること

この 5 行があると、各社は同じ前提で見積もれる。逆にこれが無いと、ある社は外部 API 前提で安く、別の社は閉域前提で高く出す。金額は 2 倍以上に割れることがあり、比較にならない。

条件をそろえた案件票を作って複数社に渡すところは無料の相見積もりから進められる。案件票にはセキュリティ要件の欄があり、上の項目を選ぶだけで各社に同じ条件で届く。そろえる項目の全体像は相見積もりで条件を揃える12項目にまとめてある。

7. 決める順番

最後に手順としてまとめる。

1. 自社のデータを 4 区分に当てはめる（公開・社外秘・個人情報・機密）。案件ごとではなく、一度作って使い回す
2. 区分ごとに外部 API の可否を決める。判断が割れるものは法務に確認する
3. 個人情報を含むなら、第三者提供にあたらないルートに乗るかを確かめる。海外に送るなら第 28 条の手続きを確認する
4. 機能ごとに区分を割り当てる。全部を最も厳しい区分に合わせない
5. 上の 5 行を見積依頼に書く。書いてから複数社に投げる

1 と 2 は一度やれば次の案件で再利用できる。止まっている 2 週間の正体は、たいていこの 1 と 2 を案件のたびにやり直していることである。

まとめ

外部 API に送ってよいデータを決める作業は、案件ごとの判断ではなく、一度作る区分表である。公開・社外秘・個人情報・機密の 4 区分に分け、区分ごとに可否を決めておく。

やることは 3 つ。区分表を先に作ること。個人情報を含むなら第三者提供にあたるかどうかを確かめること。そして、機能ごとに区分を割り当てて、全体を最も厳しい条件に引きずられないようにすること。 この 3 つができていれば、見積もりの条件は 5 行で書ける。

なお、この記事は一般的な整理であり、個別の案件については法務・監督官庁の一次情報を確認してほしい。