遠藤が副主査として開催した研究会がオンライン開催されました。
銀行APIの動向に関する大変興味深い内容ですのでレポートを纏めました。
日時：2020年8月3日（水）18：30～20：20
テーマ：電子決済等代行事業者協会の取組みとFinTechの最新動向
講師：吉本憲文氏（電子決済等代行事業者協会理事）
出席者：85名
■要旨
日本で2018年の銀行法改正により、電子決済等代行業が法律に追加され、2020年には、銀行との接続の契約を結ぶことが義務付けられるなど、API開放が本格化した。銀行API（Application Programing Interface）の具体的事例や、4月に発表された公正取引委員会の報告を中心に、業界の動向とAPIの普及に向けた課題を説明いただいた。最後に、これからのFinTech全般に関する予想についてお話しいただいた。
０．講演者の紹介（司会より）
吉本憲文氏は、Yahoo! JAPAN、野村総合研究所などを経て、2015年から住信SBIネット銀行で、FinTech事業企画部長として、API開放に取り組まれ、家計簿アプリ、クラウド会計等への接続を率先して行った。特に2016年12月には、更新系銀行APIの開放を、金融界の先頭を切って行った。そのかたわら、経済産業省のFin Tech研究会や、全国銀行協会の『オープンAPIのあり方に関する検討会』等のメンバーも歴任され、2017年からは電子決済等代行事業者協会の理事として、日本における銀行API活用の推進を図っている、日本の銀行APIの第一人者である。
１．電子決済等代行業
１－１．電子決済等代行業
電子決済等代行業は、2018年銀行法改正で新たに可能となった「業」であり、登録業務である。登録業務とは、参入規制の「許可、免許または承認」「認可」、「登録」、「届出」の4段階の下から2番目である。一定の審査を受けて登録して、初めてこの業を営むことができるものである。電子決済等代行業は、マネーフォワードやfreee等の家計簿ソフトやクラウド会計ソフトのように、銀行APIを活用するいわゆるFinTech企業がなる業というイメージだが、実際の法律の対象範囲はもう少し広い。金融庁のHPの電子決済等代行業者一覧で業者の名前や法人番号を見ることができる。家計簿ソフトやクラウド会計の企業以外にも、証券会社やITの大手企業や銀行などが含まれている。
電子決済等代行業者には、1号事業者（更新系）と2号事業者（参照系）がある（表1）。
表1 電子決済等代行業者の種類と対象例
| 種類 | 対象例 |
| 1号事業者（更新系） | ・更新系（振込）APIを用いて、利用者の振込指示を銀行に伝達する事業者 ・Pay‐easyサービス（情報リンク方式）を提供する事業者 等 |
| 2号事業者（参照系） | ・個人資産管理（Personal Financial Management）サービス事業者 ・クラウド会計サービス事業者 等 |
また、電子決済等代行業は、①顧客の委託を受けて、②顧客の口座に対して、③電子的に指示を出す、以上3つの要件を満たす業務を行うものである。電子決済等代行業に該当しない例と対比したのが表2である。
ただし、銀行法施行規則第1条の3の3で、定期的な口座振替サービス、公金の支払い、自己債権の回収、インターネットモール等は、適用除外と定められている。
表2 電子決済等代行業の3要件
| 電子決済等代行業の3要件 | 電子決済等代行業に該当しない例 | |
| １ | 顧客の委託を受けて | 銀行の委託を受けている |
| ２ | 顧客の口座に対して | 顧客の属性に対して指示を出す（住所変更等） |
| ３ | 電子的に指示を出す | 磁気テープに記録して手渡し |
1－2．スクリーンスクレイピングと問題点
APIの背景となった重要な要素技術として、スクリーンスクレイピングがある。マネーフォワードやfreeeがAPI接続以前に主力として扱っていた技術で、今でもこの技術を使って接続していることもある。図1で言えば、ユーザーは、インターネットバンキングにログインIDやパスワードを直接入力するのではなく、クラウド会計ソフトに預け、クラウド会計ソフトがユーザーに成り代わる形でログインし、そこに表示されている残高情報や入出金情報をシステム的にキャプチャーして表示するものである。
図１ スクリーンスクレイピング
このスクリーンスクレイピングの歴史は古く、検索エンジンの概念にも用いられる技術であるが、金融情報でこれを利用すると情報セキュリティ上問題になるポイントから3点を説明する。
第一にアクセス元（IPアドレス等）情報の重複である。例えば銀行に複数の顧客から情報の照会が同じアドレスから入る形になり、詐欺集団がログイン情報を収集してアクセスしているのと同じにしか見えない形になる。銀行としては、犯罪集団を見抜きにくくなるという問題である。
第二にクローラー負荷問題がある。通常、銀行の顧客は、毎日複数回も銀行口座の情報を見るようなことはしないが、スクリーンスクレイピング技術を使っている会社は、銀行の口座の異動を高頻度でアクセスすることになり、インターネットバンキングを提供する銀行としては、顧客がアクセスしていた時以上に高負荷のアクセスに耐える設計をしなければならなくなるという課題が出る。
第三に、ハッキングに狙われるという課題がある。多数の顧客がログインIDやパスワードを預けているので、ハッキングに成功すれば、大量のアカウント情報を入手することが可能になるという課題である。
１－3．オープンAPI 制度化の時系列
概観すると、欧州では2015年から検討が始まり、2016年に制度化して、2018年に施行された。日本はやや遅れて、2016年に検討が開始され、2017年に制度化され、2018年に電子決済等代行業という形で施行された。
EUでは2015年12月にEU第二次決済サービス指令（PSD2）が公布された。英国でも2016年2月にOpen Banking Standardが公表され、法制度化の検討がキックオフされた。
EUのPSD２は、更新系を扱う決済指図伝達サービス提供者（PISP：Payment Initiation Service Provider）と、参照系を扱う口座情報サービス提供者（AISP：Account Information Service Provider）に対し、一定のルールを守ることが提唱された。法制度も日本の銀行法と違って、銀行側は、これらの事業者からの接続を拒否することはできないというかなり強めの法律となっている。
日本では、実際の事例が先行した。2016年3月に、住信SBIネット銀行が日本で最初にAPI開放を行った。翌4月には地方銀行の事例が続いた。2015年12月の金融審議会の決済高度化ワーキンググループの報告書や2016年6月の日本再興戦略2016でAPI公開の検討が指示された。これらを受けて、2016年10月に全銀協に銀行界、IT事業者、FinTech企業、学者、弁護士、消費者団体、金融庁等の関係者をメンバーとする「オープンAPIのあり方に関する検討会」が設置され、吉本氏も検討会メンバーとなった。この時点では立法化を視野に入れたわけではなく、APIはどうあるべきかを検討するものであった。
2016年12月の金融審議会の金融制度ワーキンググループの報告書では、「電子決済等代行業者（フィンテック企業）」の登録制導入、情報管理、業務管理体制の整備と金融機関側のオープンAPI の整備、顧客に損失が発生した場合の、責任分担ルールの策定などの法整備が打ち出された。2017年の3月に、更新系と参照系で3つの要件を定義した銀行法の改正法案が提出された。
「オープンAPIのあり方に関する検討会」でもオープンAPIのあり方の検討から、法制度整備への対応の検討に軌道修正され、法案が成立したのを受けて7月に報告書を取りまとめた。法案の審議と並行しての報告書の取りまとめには、苦労があった。
法はシンプルであるが、実際の事業者への適用については、政省令で定めていくので、246件に及ぶパブリックコメントが寄せられた。その中では、電子決済等代行業者が必ずしもAPIを使用する事業者に限られないという回答もあった。また参照系CMSや収納代行業者も該当するなどの回答がなされ、当該事業者を震え上がらせた。結果として電子決済等代行業は、APIを主軸としながらも、かなり幅広いユースケースを持つ法律として定められたといえる。
2．そもそもAPIとは
2－１．API
ユーザーデータを管理するリソースサーバーに対して、クライアントアプリがユーザーデータを要求する時の、ユーザーのデータをやり取りする口が「API」である（図2）。
人が使うためのインターフェースすなわちユーザーインターフェース（UI）に対して、APIは、プログラムが使うためのインターフェースである。
図２ API
出典：川崎貴彦「一番分かりやすいOAuthの説明」https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be
2-2．「良いAPI」と「イケてないAPI」
「良いUI」と「イケてないUI」があるのと同じように、APIにも「良いAPI」と「イケてないAPI」がある。具体的なAPIの例として残高照会の場合を示す（図3）。この事例は、世界標準的な考え方で実装されていて、残高の値を返すだけでなく、日付や時点、通貨単位、前日残高、前月残高の情報なども返ってくる優れたものである。
図3 具体的なAPI 残高照会
出典：GMOあおぞらネット銀行のAPI仕様書
https://gmo-aozora.com/business/service/pdf/api-spec-indivisual.pdf
残高照会のUIの場合は、各社独自の画面表示をしており、残高の表示位置や基準日、名称などは様々である。スクリーンスクレイピングの技術では、各社ごとのログイン後の画面のどこに必要な情報が表示されているかを人力で登録し、機械的に巡回取得している。
次に、残念なAPIの例（架空のもの）を示す（図４）。
第一に呼び出しの仕様が「Zandaka」とローマ字表記である。
第二にいつの時点の情報がわからないので、データ取得時点をクライアントで記録するしかない。ただし、リソースサーバー側の障害や遅延などしている可能性が排除しきれず、正しい値が出ているのか検証不能であり、障害連絡が来たら遡ってデータ修正が必要になる。
第三に通貨単位が、ユニバーサルな通貨コード（JPYなど）ではなく、独自のテーブルを用いている。マッピングテーブル（０１＝JPYなど）を事前に受領したうえで、クライアント側で都度変換しないと、理解できないものになっている。
図４ 残念なAPI 残高照会
2-3．IB（インターネットバンキング）接続型の課題
例えばマネーフォワードのような会社は、国内の140行程度のすべての銀行と接続をするニーズを満たさなければいけないので、相当大変であることが想像できる。
このようなことが発生する理由の一つは、API基盤の作り方に起因している。日本の銀行は、勘定系直結型とIB（インターネットバンキング）接続型のどちらかのパターンで、API基盤を構成しているが、IBシステム接続型で問題になることがある。
IB接続型の場合、IBに依存することになる。IBのシステムは、画面表示で最適な情報のみを表示するが、それをそのままAPIにすると、必要なデータが渡されなかったり、画面制御のための情報など、APIでは必要のない情報が渡されたりすることになる。例えば入出金明細照会の場合、画面上で1ページに表示できない場合、「次へ」といったボタンで、続きの明細を出す仕様にすることがある。APIがそのままの仕様で作られると、クライアントアプリが何度も繰り返して情報を取る必要がある。またクライアント側で、必要としない情報を削除の上、合算するなどのコントロールを行う必要が生じることもある。参照系であればまだ良いが、リアルタイムの更新系のAPIでは、このような仕様は、時間切れ等の課題となる。
３．直近の電子決済等代行業界の状況
3-1．現在の状況
金融機関と電子決済等代行業者とのAPI接続が進んでおり、スクレイピングで接続している業者が、API接続に切り替えるタイムリミットが2020年5月末であった。コロナの影響で、基本的な合意をしていれば、9月末までの猶予が追加的に認められている。ただ多くは、5月末に金融機関との間に契約を締結し、API接続に切り替えている状況である。
3-2．公正取引委員会の報告書（4月21日）
契約期限が5月末に迫る中で、4月21日に公正取引委員会が、「フィンテックを活用した金融サービスの向上に向けた競争政策上の課題について」という報告書を公表した。この報告書の背景は2点ある。
第一に、家計簿サービス等を営む事業者と銀行とのAPI接続等の契約の進展が芳しくないという情報があったことから、何が問題なのかを明らかにするものである。
第二に、PayPay等コード決済事業者の台頭を背景に、キャッシュレスの進展等、利用者の決済のあり方が変容しつつあることから、現状に問題ないのかを確認する意味合いがある。
これら2点に関して、銀行のデータ参照・送金等にかかるコスト等がその進展の妨げになっていないかを調査報告したものである。
公正取引委員会の報告書は、以下の4つの文書からなる。
| １．フィンテックを活用した金融サービスの向上に向けた競争政策上の課題についてhttps://www.jftc.go.jp/houdou/pressrelease/2020/apr/chouseika/200421_honbun.pdf
２．報告書概要 ３．家計簿サービス等に関する実態調査報告書https://www.jftc.go.jp/houdou/pressrelease/2020/apr/chouseika/200421_houkokusyo_1.pdf ４．QRコード決済を用いたキャッシュレス決済に関する実態報告書https://www.jftc.go.jp/houdou/pressrelease/2020/apr/chouseika/200421_houkokusyo_2.pdf |
全体を把握するには２．の報告書概要を読むのが良いが、詳細を知るには、３．４．の調査報告書本文を読み込むのも良い。報告書の本文の構成は、前半に調査の概要、最後に競争政策上及び独禁法上の考え方が記載されている。業界事情に詳しい人は、最後のところだけを読むのでも内容を理解できる。業界内がどうなっていたのかを知りたい人は前半を読むと、実態を知ることができる。
報告書概要の家計簿サービス等に関する実態調査では、以下を報告書にまとめている。
①の銀行と電子決済等代行業者の関係（図5の中央部）では、銀行から電子決済等代行業者に口座情報提供がある一方で、業者からは接続料等支払がされる利害関係を示している。
②の銀行とシステムベンダーの関係（図5の上部）では、銀行はシステムベンダーに初期費用やランニングコストを払う代わりに、システムベンダーにAPI接続基盤の整備や運用をしてもらうという利害関係を示している。
図5 家計簿サービス等に係わる取引構造
そして①銀行と電子決済等代行業者（以下電代業者）の関係、②銀行とシステムベンダーの関係のそれぞれで、競争政策上の考え方と独占禁止法上の考え方を示している。銀行宛の指摘が7点、システムベンダー宛の指摘が2点ある。
| （銀行宛） 1．電代業者向けの接続の確保に向けた更なる方策の検討 2．API接続で取得可能な情報範囲の拡大 3．電代業者向けの契約における不当な見直し 4．競争者の市場排除を目的とした、電代業者向けの取引拒否や情報制限 5．一部の電代業者に対してのみ差別的な取り扱い 6．複数のシステムベンダーから見積もりを取るなど、システム調達の方法に十分な競争性が確保されること 7．人材の育成等によるシステムに対する知見や専門性の確保を図ること （ベンダー宛て） 8．既存ベンダーが、合理的な理由なく仕様公開を拒むなどして、他社ベンダーから受託することを不当に妨害すること 9．既に提供している勘定系システムやIBシステムの提供の停止を示唆することにより、自社とのAPI接続基盤の取引を強要し、不当に、銀行が他社ベンダーに委託できないようにする |
3-3．公正取引委員会報告書のキャッシュレス決済編（参考）
以下の通り独占禁止法上ないし競争政策上の指摘が9点ある。
| （銀行宛） １．コード決済事業者とのチャージ等取引を拒絶することやチャージ等取引に係る手数料を事実上拒絶と同視し得る程度まで引き上げること ２．①銀行自らが提供するコード決済サービスの加盟店開拓を行わせること、 ②キャンペーン費用の負担を要請すること、 ③ノンバンクのコード決済事業者の保有するデータを提供させることなどにより、相手方に正常な商慣習に照らして不当に不利益を与えること （NTTデータ宛） 3．CAFISの利用料金が固定的であることは、銀行口座からのチャージ等に係る費用を高止まりさせることにもつながるおそれ （銀行宛） 4．各銀行は、決済インフラへの競争圧力を高めるため、更新系APIの利用を簡便に行える環境の整備を検討 5．資金移動業者のアカウントへの賃金支払の解禁が行われた場合には、銀行とノンバンクのコード決済事業者間のコード決済における競争条件のイコールフッティングの確保に好ましい影響が生じる （全銀協宛） 6．銀行間手数料の必要性を含めた検討を行った上、設定水準、設定根拠に関する説明責任を十分果たすことにより、事務コストを大きく上回る銀行間手数料の水準が維持されている現状の是正に向けて取り組むべき （全銀ネット宛） ７．全銀ネットは、エンドユーザーのニーズを反映できるようガバナンス体制を強化することが望ましい 8．全銀ネットは、全銀システムを利用した取引コストの透明性を確保することが望ましい 9．全銀ネットは、全銀システムへの接続に求められる条件を整理し、条件を満たす資金移動業者に対しては、アクセス開放を検討することが望ましい |
４．これからのFinTech予想
4-1．キャッシュレスの未来
消費税増税還元施策は、6月末で終了したが、マイナポイントの還元施策や、公正取引委員会の報告書、コロナ禍の影響でECサイトの利用や店頭でのキャッシュレス支払が進展している。
キャッシュレスがらみでは、冷蔵庫にセンサーとAIがついていて、「たまご」の利用スピードを把握して、無くなる直前に適量をAPIで発注する世界が来る可能性がある。APIは本質的に、このように自分の認識していないところで自動的につないでいくことに相性が良い。
キャッシュレスは過程に過ぎず、ペイメントレスの兆候ではないかと考える。なぜなら「移動したい」「モノが欲しい」「コトが体験したい」わけであって、「お金を払いたい」わけでは無いからである。組み合わせによるAPI活用が新たなユーザー体験の創出につながると予想する。その際、IOTで機器が判断して取引を行うAPI×IOT決済の世界では、手数料体系も高速トランザクションの世界に対応した新たな体系が必要となる。
4-2．銀行や決済周りで起きること（予想付）
①全銀ネットに銀行以外が接続できるようになる。
例えば○○Payから証券会社に振り込めるとか、クレジットカード支払いを○○Payで行えるなど。
②○○Payで給与を受けとれるようになり、海外から来た労働者も給与を受け取りやすくなる。
③全銀送金手数料の大幅値下げにより、100円未満の少額チップの送金や、オンラインスポーツ観戦に対する投げ銭やアイドルの応援ができる。
4-3．金融サービス仲介法制
2020年国会にて金融関連で2つの法改正が成立した。金融サービス仲介法制と資金移動業の三類型化である。金融サービス仲介業は、銀行のみならず、証券や保険にまたがった仲介業を創設するものである。具体的な提案イメージは以下のようなものがある。
①家計簿ソフトで連携している銀行が取り扱う住宅ローンの金利を表示して並べて提案する。
②住宅ローンを提案したお客さまに、その後の資産運用を提案する（銀行を紹介した後、証券を紹介する）。
③オークションやフリーマーケットの売上から直接株式が買える。
④スーパーアプリで旅行を予約すると旅行保険が提案される。
金融サービス仲介は、既存の業者が存在している領域に法律を設置するというアプローチではなく、誰がプレーヤーとして出現するかは未知数である。法施行は2021年秋ごろと言われており、現在自主規制団体設立に向けた議論が始まったばかりである。
4-4．その先の規制改革領域
規制改革推進会議の投資等ワーキンググループで議論されている証券業や資産運用業ではないかと考えている。米国でできて日本ではできないこととして、以下がある。
①未公開企業の資金調達に関する証券会社による募集行為…ユニコーン企業を生む出すために、有効ではないか。
②特定の株式と交換できる、コンビニプリペイドカードの販売
③デビットカードで決済すると、ポイントの代わりに、買い物した会社の端数株式が貰える。
4-5おわりに
諸外国の動向も踏まえて、電子決済等代行業という業が誕生したが、APIを用いた真のサービス活用はまさにこれからである。関連する法制度改革は現在も進行中である。海外事例を少し見るだけでも、日本でも法制度をちょっと改正すればできるような面白いサービスはたくさんある。
日本でもこれから面白いサービスがたくさん誕生するのではないかということで、楽しい「FinTech JAPAN」みたいなことが、今後も起きていくと考えていただければ、私の今日お伝えしたかったことが伝わったと思う。ご清聴に感謝する。
【質疑】
質問：簡単に言うと電子決済等代行業者と資金決済業者の違いはなんでしょうか。
回答：電子決済等代行業者は、銀行との関わりが必須で指図をする立場だが、資金決済業者は顧客からの資金を預かり、送金や決済を行うものである。
質問：ポイント業者から銀行口座に逆チャージする場合に、何か法的問題はありますか。
回答：ポイントは、金融機関が発行したもの等でない限り、基本的に口座に現金換金することはできません。
質問：金融機関ごとにAPIの仕様は異なるのでしょうか。仕様を統合する動きはないのでしょうか。XMLのメタデータ付き変換には対応していますか。全銀EDI（ZEDI）とも関係しますか。
回答：銀行ごとに画面が異なるように仕様は異なっている。全銀のAPIの報告書で、最低限の標準化の議論はあるが、細部まで統一すると、ハッキングされやすくなるということなどもあり、一定程度自由度を持たせている。銀行APIの仕様としては、最も軽量化を図れるJSON APIを採用した。XMLでは高頻度のトランザクションが発生する際に、ボリュームが増えてボトルネックになる可能性があるためである。全銀EDI（ZEDI）については、直接APIとは関係ない。
質問：現金での支払いを拒否することを禁じる法律についてどう考えるか。
回答：災害時等を考えると、法定通貨はどこでも使えることが必要である。特に日本のような人口規模の場合、現金受入れを許容することが必要と考える。
質問：電子決済代行事業者間の競争については、どのような策を法で取られているのでしょうか。
回答：電子決済等代行業者間については、法での規定はなく、自由競争下にある。電子決済等代行業者としての顧客保護等の観点で一律の指導が入っている状況である。
質問：決済等代行業というと、BtoBのビジネスで、売掛金の取立てに発展することになるのか、電子手形の延長になる可能性はありますか。
回答：電子決済等代行業者としては、例としてマネーフォワードを出したので、BtoCのイメージが強かったかもしれないが、BtoBでも3条件を満たせば対象になる。キャッシュマネジメントサービス（CMS）として、大手企業のグループ間のサプライチェーンを担っているような会社も、資金決済を担っていれば対象となる。売掛金の回収や指示を電子的に行えば、電代業にあたるという整理になる。電子手形については、3条件に当てはまれば電代業になるし、違う観点であれば関係ないということになる。
質問：銀行と一口で言ってもメガバンクと地銀クラスではIT部門の体制も大きく違うので、規模に応じた解釈をするのでしょうか。
回答：一律に適用というものではなく、ご指摘の通り、規模に応じた解釈をすると考えられる。
質問：全銀ネットはトランザクションの金額によらず、同一のセキュリティレベルを担保し、これが高コストの原因の一つと思うのですが、例えば3万円以下のトランザクション専用のネットは考えられないでしょうか。
回答：少額決済について、「全銀LITE」検討の議論が既になされている。
質問：金融サービス法案の原文や審議状況はどこで確認できますか。
回答：金融審議会のサブグループである「決済法制及び金融サービス仲介法制に関するワーキンググループ」で議論された。
質問：日本における電子決済等代行業の普及促進に係る阻害要因とその対応策は何か
回答：様々な要因が複雑に絡み合っているのだと思う。銀行がAPI開放したくないとか、仕様が今一つであるということで、銀行がやり玉にされているようなところもあるし、インフラを提供する会社がコストの高いものを銀行に提供しているため、あまり使われていないという流れもある。家計簿ソフトや会計ソフトが諸手を挙げて素晴らしいという状況でない点もあり、電子決済等代行業者側の努力も必要かと思われる。これらが少しずつでも進歩して、いい方のスパイラルに入っていけばよいと、電子決済等代行事業者協会の理事として考えている。
質問：米国でのAPIの状況はどこで見れば良いですか。
回答：米国は日本より進んでいない。国を挙げてAPI化を図ろうとはしていないので、お示しできるものはない。
質問：システム監査の目線で言うと、不適切な契約などは検証できそうですが、「契約しない」というのは、検証が難しいと思いました。
回答：銀行には連携及び協働に係る方針の公表義務があり、そこに連絡先窓口も公表されている。例えばこちらへの問い合わせの総数を分母に、業務監査に関しては、問合わせが来ているのに放置していることを、監査できるかもしれない。
質問：小規模な電子決済代行業者にとっては、銀行のセキュリティ等の要件のハードルが高くて、対応しきれないということが発生する可能性はないか。
回答：銀行が電子決済等代行業者と契約を締結する際に用いる、FISCのチェックリストがある。この基準に逸脱していないかどうかを確認することで対応できると思われる。
質問：今の議論の関連で、電子代行業者の事業継続に係る主なリスク事項と監査に期待することは何かありますか。
回答：今までは、万一サービスが無くなっても、不便にはなるが、大きな混乱は生じないという整理だった。しかし今後は電子決済等代行業者の事業継続性をサポートすることありうるのではないかと考える。
質問：APIからのDDOS攻撃への対策を考える必要はないか。
回答：銀行APIの機能は、「認証認可の画面」「APIそのもの」の２つに分けられるが、画面についてはそもそも銀行のインターネットバンキング自体で対策が打たれている。APIそのものについては、接続先である電子決済等代行事業者にアクセス元が限定されているので、APIがまとめて打撃を受ける可能性としては小さいのではないか。
（文責遠藤正之）
