API 連携でデータを外部に渡して大丈夫か — 渡す相手・通り道・置き場所・やめるとき

調査の詳細

このページの答えは、以下の調べで出しました。対象・確認時期・出典を並べます。

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

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

なぜこの仕組みが要るのか

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

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

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

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

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

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

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

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

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

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

APIキーは「入館証」ではなく「合鍵」です

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

56件の認証方式

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

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

主な方式はこうです。

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-08-10

_{以前ここは手書きの表でした（7 件 ×「認証の方式」）。同じ内容が調査記録に在り、原文と調査日つきで出せるので調査記録から引きます。並べる 7 件は変えていません — この調査で値が読めた分です。}

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

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

② 通り道と、③ 置き場所

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

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

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

保管場所は15件で確認できず

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

書かれている例。

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

確認できなかった例。

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

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

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

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

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

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

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-08-04

_{以前ここは手書きの表でした（5 件 ×「解約時の持ち出し」）。同じ内容が調査記録に在り、原文と調査日つきで出せるので調査記録から引きます。並べる 5 件は変えていません — この調査で値が読めた分です。}

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

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

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

実際の記述を並べます

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

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

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

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

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

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

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

出口を先に見る理由

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

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

調査記録から: 経理・会計／人事・労務の「認証・保管・持ち出し」を横に並べる

（この表は調査記録から機械で描いています。記号や札をクリックすると、編集部の総結と原文・出典が出ます。）

経理・会計

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-09-03

人事・労務

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-09-03

ここでの調査範囲について

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

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