API連携でデータを外部に渡して大丈夫なのか調べてみた｜OAuth・APIキー・保管場所・やめ方を業務システム56件で【2026年8月調査】

Last updated at 2026-09-07Posted at 2026-08-30

「外部のサービスにデータを渡して、大丈夫なんですか」

社内で連携の話をすると、必ず出る質問です。そして、この質問には答えにくい。「大丈夫です」と言っても根拠がなく、「危ないです」と言えば話が止まるからです。

問題は、「安全か」が漠然としすぎていることです。分けて聞けば答えられます。

日本の業務システム56件について、認証方式・セキュリティの記述・データの保管場所・解約時の持ち出しを、公式資料から1件ずつ調べました。

結論から書きます。

データの保管場所を公開資料から確認できたのは、56件中41件。15件は書かれていません。
認証方式は48件、セキュリティの記述は53件、解約時の持ち出しは49件で確認できました。

「書かれていない」ことと「危ない」ことは別です。 ただし、社内で説明を求められたときに答えられない、という意味では同じ問題になります。

1. 「安全か」を4つに分ける

漠然とした不安を、聞ける形に分解します。

何が心配なのか	具体的に聞くこと
① 渡す相手	そのサービスは、何を読めて、何を書き換えられるのか
② 通り道	データはどこを通るのか。暗号化されているか
③ 置き場所	どこの国・どのデータセンターに保管されるのか
④ やめるとき	止められるか。データを持ち出せるか

この4つに分ければ、ベンダーが答えられる質問になります。「安全ですか」は答えられません。

そして意外に思われるかもしれませんが、④が一番の判断材料になります。 入るときより、出るときのほうが差が出るからです。

2. ① 渡す相手 — OAuth は「入館証」です

現代のWeb APIで広く使われているのが OAuth 2.0 という仕組みです。RFC 6749 という標準文書で定められています。

2-1. なぜこの仕組みが要るのか

素朴に考えると、外部サービスに連携させるにはそのサービスにIDとパスワードを教えることになります。これは危険です。渡した相手は何でもできてしまうからです。

OAuthは、パスワードを渡さずに、限定的な権限だけを渡す仕組みです。会社の建物に例えると、**受付が発行する「入館証」**です。

OAuthの言葉	建物に例えると
resource owner	建物の持ち主（＝あなた）
client	作業に入る業者
アクセストークン	入館証
scope	入れる範囲（どのフロアのどの部屋か）
有効期限	いつまで使えるか
取り消し	受付でその入館証だけを失効（ほかの入館証は無事）

「合鍵」に例えられることもありますが、合鍵は元の鍵の複製なので、この仕組みの説明としては逆です。合鍵は元の鍵と同じ扉が全部開き、期限がなく、無効にするには錠ごと替えるしかありません。OAuthはその3つとも反対──範囲が絞られ、期限があり、それだけを取り消せます。

RFC 6749 では、保護されたリソースへのアクセスを許可する主体を resource owner、それが人間である場合を end-user と呼んでいます。

つまり「データは利用者のもの」は、理念ではなく標準規格の用語定義です。

だから次の4つは、聞いて当然の質問になります。

「その連携ツールは、何を読めるのですか」
「何を書き換えられるのですか」
「そのアクセス権はいつまで有効ですか」
「利用を停止したいとき、どこから取り消せますか」

3つ目と4つ目について、正確に書いておきます。アクセストークン自体の期限は短くても（1時間などの例が多い）、多くの実装ではリフレッシュトークンという仕組みで自動更新され続けます。 つまり利用者の体感としては、「期限が来たら切れる」のではなく、**「取り消すまで続く」**ことになります。だから4つ目──取り消す場所──を先に確認しておく意味があります。取り消しは通常、各サービスの連携アプリ管理画面から行えます（規格側にもトークン失効の標準 RFC 7009 があります）。

なお、resource owner はOAuthにおけるアクセス許可の主体を表す規格上の用語であって、法律上のデータ所有権を定める言葉ではありません。ここは区別しておきます。

2-2. scope は実際にこう書かれています

抽象的な話に聞こえるかもしれませんが、実際のAPI仕様書に書かれています。

マネーフォワードクラウド経費のAPI仕様には、6種類のスコープが定義されています。office_setting:write（事業者の設定から従業員の設定まで管理）、user_setting:write（ユーザー自身の設定）といった具合に、何をどこまでできるかがスコープ名として明記されています。

マネーフォワードクラウド請求書は mfc/invoice/data.read（参照）と mfc/invoice/data.write（更新）の2種類です。読むだけの権限を渡すという選択ができる、ということです。

連携ツールを入れるとき、「どのスコープを要求されますか」と聞けば、何を渡すことになるのかが分かります。

2-3. APIキーは「入館証」ではなく「合鍵」です

もう1つの方式が APIキーです。こちらは注意が要ります。

APIキーは、扉の鍵の複製──つまり「合鍵」に近い性質です。1つの文字列（キー）を持っていれば呼び出せるので、範囲も期限も基本的にありません。そして無効にするには「錠を替える」＝キーを再発行するしかなく、その鍵を使っている連携が全部止まります。 だから配り方と保管が問題になります。

方式	例えると	渡した後にできること
OAuth	入館証（受付が発行する）	入れる範囲と期限が決まっている。受付で即失効できる。相手にパスワードは渡らない
APIキー	合鍵（扉の鍵の複製）	範囲も期限も基本的にない。無効にするには錠を替える＝その鍵を使っている連携が全部止まる

boardはここを工夫しています。2方式の併用が必須で、①APIキー（アカウントで1つ発行）＋②APIトークン（複数発行可で、トークンごとに利用可能なエンドポイントを指定できる）という設計です。OAuthはありませんが、トークン単位で範囲を絞れるようにしてあります。

2-4. 56件の認証方式

編集部が調べた範囲では、48件で認証方式の記述を確認できました。

用語について1つ補足します。厳密には、OAuth 2.0 は**「認可」（何を許可するか）の枠組み**であって、「認証」（本人確認そのもの）は OpenID Connect などが担う別の話です。この記事では、各社の公式資料が「認証方式」という見出しで書いているのに合わせて、まとめて認証方式と呼んでいます。

主な方式はこうです。

システム	認証方式
freee会計	OAuth 2.0（authorization_code）
Salesforce Sales Cloud	OAuth 2.0（接続アプリを登録して認可フロー）
Google Workspace	OAuth（Google Cloud プロジェクトでスコープを定義、ユーザーの同意を経る）
HubSpot	OAuth。複数アカウントに入れるアプリやマーケットプレイス掲載アプリはOAuth必須
kintone	パスワード認証／APIトークン／セッション認証／OAuth の4方式
board	APIキー＋APIトークンの併用必須
SmartHR	アクセストークン方式

行政系は別の仕組みになっています。e-Gov電子申請はアカウントが3通り（e-Govアカウント／GビズID／他認証サービス）で、手続によっては電子証明書が別途必要です。サイト自身が「書面手続の実印・印鑑証明に相当する」と説明しています。

面白いのはjGrantsで、申請にはGビズIDが要る一方、補助金情報を読むだけの公開APIには認証の記述がなく、実際に鍵なしで応答します。 読むだけなら誰にでも開放する、という設計です。

3. ② 通り道と、③ 置き場所

3-1. セキュリティの記述は53件で確認できました

暗号化・認証取得（ISMSなど）・不正アクセス対策といった記述は、56件中53件にありました。ほとんどのサービスが何らかの説明を出しています。

ただし認証を取っている＝安全、と読み替えることはできません。 ISMS（ISO/IEC 27001）は「情報セキュリティを管理する仕組みが整っている」ことの認証であって、個々の事故が起きないことの保証ではありません。比較の材料の1つとして見てください。

3-2. 保管場所は15件で確認できず

ここがこの記事の中心です。データがどこの国・どのデータセンターに置かれるのかを公開資料から確認できたのは、56件中41件でした。

書かれている例。

システム	書かれていること
kintone	日本国内のデータセンター（金融機関向けFISC安全対策基準を満たす）。東日本の大災害に備え西日本にも冗長化
マネーフォワードクラウド会計	「サーバーは日本国内に設置し、信頼性の高いクラウドサービス事業者を利用」
Zoho CRM	2022年2月10日以降に日本から登録したアカウントは日本データセンター（東京プライマリー・大阪セカンダリー）。それ以前の登録は米国のままで、登録時期で保存先が決まり、後から変更できない
Shopify	データセンターの国・リージョンの明記なし。プライバシーポリシーで「カナダ企業として世界中でデータを処理し、米国を含む国外へ個人データを送ることがある」と明示

Zoho CRMの例は特に実務的です。 「日本のデータセンターです」と聞いても、あなたのアカウントがいつ作られたかで答えが変わります。しかも後から変更できません。

確認できなかった例。

freee会計：公式セキュリティページに暗号化・バックアップ体制・TRUSTe認証の記載はあるが、保管国の明示はなし
SmartHR：公式セキュリティページ・FAQに保管場所の記載を確認できず。導入検討者向けに「セキュリティチェックシート」を公開しており、詳細はそちらで確認する形になっている

SmartHRの例が示すように、公開ページに書いていない＝隠しているわけではありません。 検討者向けの資料として別に用意されていることがあります。

だから聞けば分かります。 この記事で言いたいのは、**「公開ページを見ただけでは分からないので、聞く必要がある」**ということです。

Salesforce Sales Cloudも微妙な例です。保存場所は Hyperforce で選べるという書き方ですが、そのページに明記されているオペレーションゾーンはEUとスイスだけで、日本の扱いはそこには書かれていません。

4. ④ やめるとき — 最も対応が分かれるところ

最後に、出口です。49件で記述を確認できました。

「解約したらデータはどうなるのか」は、入る前に確認すべきことです。

システム	解約時の扱い
kintone	解約日の翌日から30日後にデータを削除。期間内の再契約なら引き続き利用可
freee会計	支払い停止後は残存期間終了後に「プラン未契約」に戻る＝データは削除されない。再度有料プランを契約すれば過去のデータを参照できる。退会は3段階（①支払い停止 ②メール配信停止 ③事業所削除）
board	「登録したデータすべてをエクスポートできるわけではありませんが、主要なデータはCSVでエクスポートできる」。退会はいつでも可（最低契約期間なし）
弥生	データはもともと手元のPC内にあり、解約で消えるクラウド預かりではない。帳簿・伝票はテキストファイルに出力可能
SmartHR	セルフ退会できるのは特定のプラン・支払方法の場合のみ。それ以外は担当者またはチャットサポート経由

この5つは、扱いが全部違います。

kintone は30日で消えます
freee会計は消えません（プラン未契約状態で残る）
board は**「すべては出せない」と正直に書いています**
弥生はそもそも手元にあります
SmartHR はプランによってはセルフ退会できません

board の書き方は誠実です。 「主要なデータはエクスポートできるが、すべてではない」と、できない範囲まで明記されています。「エクスポートできます」とだけ書かれているより、確認すべきことが分かります。

4-1. 実際の記述を並べます

KING OF TIME — 締切が解約日当日

解約日の翌日から管理画面へのログインを含む全操作ができなくなり、「※データの閲覧や出力もできなくなります」

つまりデータを持ち出せる最終日は解約日当日です。公式ヘルプは「解約前のデータが必要な場合は、各製品のデータを事前にエクスポートしてください」と明記しています。

この1件を知るだけでも、出口を先に確認する意味が分かります。 「解約したあとで、必要になったら出せばいい」と思っていると、出せません。

ほかの5件も、出口の形はばらばらです。

システム	出口	公式に書かれている中身
Garoon	30日の猶予	「解約日の翌日から30日後にデータを削除いたします」（cybozu.com 共通の標準保存期間）。期間内に再契約すれば引き続き使える
HubSpot	プランで違う	Marketing Hub 有料は解約・満了後30日以内の書面請求で一時アクセスかコピー。Smart CRM と無料はアクセス提供がない
Jotform	ワンクリックでZIP	設定の Data タブから。フォームのHTML・回答のCSV・アップロードされたファイルが1つのZIPに入る
Microsoft Forms	2種類ある	「Excel で開く」はライブ接続つき（OneDrive／SharePoint に保存され新しい回答が反映される）。「コピーのダウンロード」が接続のないオフラインのブック
CLIUS	「可能です」だけ	他社カルテへ乗り換えるときの出力を、よくある質問で「可能です」と明言。形式・費用・範囲は書かれていない

読み取れることは3つです。

HubSpot — 同じ会社の同じ製品群でも、プランによって出口が違います。
Microsoft Forms — 持ち出しのつもりで「Excel で開く」を選ぶと、実は持ち出せていません。 サービスを離れたら開けなくなります。
CLIUS — 「できます」と「どういう形で、いくらで、どこまで」は別の話です。ここは聞く項目です。

4-2. 出口を先に見る理由

入口（機能・価格）は比較サイトにたくさん載っています。出口の情報は、公式ヘルプの奥にしかありません。

そして出口の条件は、乗り換えのしやすさそのものです。「30日で消える」なら、乗り換えの計画は30日以内に立てる必要があります。「すべては出せない」なら、出せない分をどうするか決める必要があります。

5. 聞くべき質問リスト

以上を、そのまま使える形にまとめます。

5-1. 連携ツールの提供元に聞くこと

「この連携で、何を読めるようになりますか」

「何を書き換えられますか」

「要求されるスコープ（権限の範囲）を教えてください」

「アクセス権の有効期限はどうなっていますか」

「利用を停止したいとき、どこから取り消せますか」

5-2. サービス提供元（ベンダー）に聞くこと

「データはどこの国に保管されますか」

「登録時期やプランによって保管先が変わることはありますか」

「解約したらデータはどうなりますか。 いつ削除されますか」

「解約前に、どのデータをどの形式で持ち出せますか」

「持ち出せないデータはありますか」

10番目を聞いてください。 boardのように正直に答えてくれるところもありますし、聞かれて初めて確認する担当者もいます。

6. まとめ

「安全か」は4つに分けると答えられる質問になる（渡す相手／通り道／置き場所／やめるとき）
OAuth は入館証。 scope（入れる範囲）と有効期限が設定されていて、それだけを取り消せる。RFC 6749 で resource owner は利用者と定義されている
APIキーは合鍵。 範囲も期限も基本的になく、無効にするには錠を替える＝その鍵を使う連携が全部止まる。だから配り方と保管が問題になる
認証方式は48/56、セキュリティの記述は53/56で確認できた
保管場所は41/56。15件は公開資料から確認できない（書いていない＝危険、ではない。検討者向け資料で出す例もある）
登録時期で保管先が決まり、後から変えられない例がある（Zoho CRM）
解約時の扱いは49/56で確認できたが、中身は全部違う。30日で消える／消えない／すべては出せない
出口を先に見る。 乗り換えのしやすさは、そこで決まる

この記事の調査範囲について

対象は、編集部が一次調査を終えて公開している56システムです。日本の業務システム全体ではありません。
確認時期は2026年7月28日〜8月19日です。仕様も方針も、今後変わる可能性があります。
「安全です」「危険です」という評価はしていません。 書けるのは「公開資料にこう書いてある／書いていない」までです。
「公開資料に記載がない」と「対策していない」は別です。 15件は前者です。
resource owner はOAuth 規格上の用語であって、法律上のデータ所有権を定める言葉ではありません。
認証取得（ISMS など）の有無を、安全性の優劣として扱っていません。
インシデント事例は調べていません。

規格の出典は RFC 6749（The OAuth 2.0 Authorization Framework）です。各システムの「認証」「セキュリティ」「データ保管場所」「解約時の持ち出し」の欄は RenkeiMap で1件ずつ、出典URLと調査日つきで公開しています。

調査対象の56システム（全件・公式ページ）

※ 一次調査を終えて公開している 56 件です。判断の元にした記述・出典URL・調査日は RenkeiMap に1件ずつ載せています。

読者アンケート実施中
このテーマをもっと深掘りしてほしい方は、記事に「いいね」をお願いします。「いいね」の多いテーマから順に追加調査し、結果は新着記事でお知らせします（フォローしていただくと通知が届きます）。

【転載OK】本記事の転載について

本記事の文章・図表は、すべて転載 OK です。図は加工しないままお使いください。転載の際は、出典として renkeimap.jp もしくは本記事へのリンクをお願いします。事前の連絡は不要です。

※ 筆者は日立系ITベンダー・介護ソフトベンダー・大学病院IT部門を経て独立し、現在は中小企業のIT・DX支援をしながら、業務システムの「つながり」を一次資料で調べています。文中の「編集部」は、筆者が所属する IT連携マップ編集部のことです。誤りを見つけられましたら訂正窓口（無料・アカウント不要）へお願いします。訂正履歴も公開しています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up