JR東日本が開設した銀行「JREBANK」については、2024/04/17 JREBANKってできるらしいですけど で触れましたとおり、オンライン家計簿アプリとの連携機能がどのように実装されるのか、が気になっておりました。
メジャーな家計簿アプリ3社の対応は以下のようになっております。
JREBANKは楽天銀行のBaaS(Bank as a Service)により構築されており、オンライン家計簿アプリとのAPIによる連携機能は、楽天銀行を介して提供されるのだろう、と考えていましたが、実際そのとおりでした。取りあえず良かった。
新しい銀行ができるらしいですね（公式サイトのPDFはこちら）。そのサービス内容はともかくとして…当Blog的に気になるのが「銀行オープンAPIによるPFM※サービスとの連携機能は提供されるのか？」ということです。
※：Personal Financial Management：個人財務管理。マネーフォワードMEやZaimに代表される、金融機関から自動的に取引・残高データを取得してユーザーに提供するAccount Aggregation機能を提供するサービス。JREBANKは楽天銀行のシステムに相乗りする形で構築するそうです。マネーフォワードMEおよびZaimは楽天銀行とのAPI連携ができるので、仕組み的には実装できるのでしょうけど…JREBANK側が、PFM事業者（電子決済等代行業者）とAPI連携に関する個別契約を締結する、という事務手続きを落とさずにやっているか？ という点がちょっと心配です。わかってやっているといいんだけどなあ…
【追記】その後のフォローは 2024/08/04 JREBANKのオンライン家計簿アプリとの連携について を参照してください。
＿ネット上の記事で大変興味深いものを見つけました。オープンループ乗車システムはSuicaの地位を塗り替えるのか? という鈴木淳也氏の記事です。
＿オープンループとは、既存のクレジットカード等の決済システムを利用して別の決済システムを構築するもので、この場合は鉄道等の公共交通機関の運賃を決済する仕組みを構築するものを差します。その対語となるのがクローズドループであり、チャージから運賃引落しまでの全ての資金の動きを１つのシステム内で完結するものを差します。Suicaがその代表例です。
＿で、鉄道の自動改札機やバスの運賃収受機にクレジットカードをタッチして、直接的に運賃を決済する「オープンループ乗車システム」について述べているのが前述の記事というわけです。詳細についてはそちらをご覧いただくとして、筆者が興味があるのが「クレジットカードで運賃を決済した場合、履歴にはどれだけ詳細な情報が残るのか？」という点です。
＿Suica（およびモバイルSuica）の大きな欠点として、電子マネーとして買い物をした場合に、利用履歴に店舗名が残らず、全て「物販」となってしまう「物販の嵐」問題が挙げられます。しかし、ストアードフェアシステムとして利用した場合は「入 ○○○○ 出 ◇◇◇◇」のように入場した駅と出場した駅の名前がしっかり残るので、後でその日の行動を遡行するのに大変便利なのです。モバイルSuicaをサポートしたアカウントアグリゲーションサービスを利用すれば、そのまま家計簿データとして取り込むこともできますからね。
＿ただ、オープンループ乗車システムが普及するとなると…
＿この２点が厄介事になりそうです。
＿１．については、鉄道会社（等）とクレジットカード会社の個人情報に関する縄張り争いに過ぎませんが、この争いにクレジットカード会社側が勝利したら…？ クレジットカード会社は個人情報・決済情報（しかもかなり高額な範囲まで）を分析・活用する高度なノウハウを有しているところに、普段の公共交通機関の利用状況という非常に濃い情報を得ることになるわけです。こうなると、他の決済サービス（QRコード決済など）のライバルどころではない、強大過ぎる存在になるのではないかと思われるのです。
＿我が国では、SuicaをはじめとするFelicaベースの電子マネーが、（改札通過時の処理速度の関係から）当分の間は一定のシェアを維持し続けるでしょうが、電子マネーのシステムを維持するコストの大きさに耐えかねる動きもあります（例えば、広島電鉄は電子マネーからQRコードでの運賃決済に切り換えるそうです）。それと似た理由で、（すでに資金回収の仕組みを確立している）クレジットカード決済に乗り換える事業体も出てきそうです。たとえカード会社に手数料を払うとしても…
＿そうなったときに、当Blogの主題である家計管理にはどういう影響が出てくるでしょうか。上記の１．と２．が共にTrueとなったとき、クレジットカードの明細に入場駅・出場駅を含んだ情報が含まれるようになるのか…？ 筆者の関心は、世間とはちょっと違った方角に向きます。こちらの動向も横目で睨んでおきたいものです。
＿今回の主題は…家計簿アプリとデータをやりとりするときに使用するファイルの形式について、です。筆者がこれまでMFFマクロに対応させてきた家計簿アプリは27種類（Money通帳とあっと家計簿は別カウント）。まず、家計簿アプリからエクスポートする方向では↓のようになります。この表は、MFFマクロの動作概念図と順番を揃えてあります。
＿SHIFT-JisとUTF-8が拮抗していることが判ります。最近エクスポート機能を実装したアプリはUTF-8が優勢ですね。BOMの有無も混沌としています。
＿現状のMicrosoft Excelは、BOM無しのUTF-8でエンコードされたファイルを開くと文字化けしてしまうので、事情を知らない人は家計簿アプリのデータを活用したくてもできないという困った状態になっているはずです。本来ならExcel側で対処すべき問題、のようにも感じます。
＿なお、Excelファイルを出力できる家計簿アプリは少数派ながら存在しており、くだらないことで悩まなくてよい、というのはありがたいですね。
＿銀行法の改正により、2020年10月以降、オンライン家計簿サービスをはじめとするPFM（Personal Finance Management）事業者は、銀行サイトとの連携機能を、銀行側との個別の契約に基づいて（APIにて）提供することが義務化されました。APIによる連携は、それ以前のスクレイピングによる連携に比べてセキュリティやネットワーク負荷といった面で格段に優れているのですが、どうもここ最近、データ取得の頻度を銀行側が制限する動きが出ているようです。
＿Moneylookが2020年5月末日にサービスを全面刷新した頃、Moneylookの公式サイトに
銀行の口座管理が「オープンAPI」によって提供される銀行の情報取得は、月2回までとさせていただきます。また従来の画面操作による情報取得は不可となります。
＿という記載が出現しており（現在はこの告知文はリンク切れとなってます）、今思えば、このころにはすでにPFM事業者・銀行間でAPIによるアクセス回数を制限する動きが始まっていたわけですが…本日、Moneytreeと銀行サイトとの再連携を設定している際に、驚くべき表記を発見しました↓。
＿久しぶりの大ネタとして、家計簿アプリのデータインポート／エクスポート機能の性能比較表を作成してみました。まとめればたった二つの図版になるだけですが、過去の自分の記事を見返したり、アプリの動作を再確認したり…と、かなり手間がかかりました。
＿評点は、数字が低いものほど優れていることを示しています。
＿【2021/04/25追記】「らくな家計簿」について、評価した時点で実装されていたのに筆者が発見できていなかった機能が判明しましたので↓の表の評点を見直しました。
＿【2021/08/22追記】↓の表に新たな家計簿アプリを追加して更新しました。2021/08/22「家計簿アプリのデータインポート／エクスポート機能の性能比較」を更新しました を参照して下さい。
＿各項目の評点は、筆者の独断と偏見に基づき↓のように付けています。標準的な性能を3として、それより優れているものを1、それより劣っているものに3を超える数値を割り当てています。基本的に、ユーザーに手間を強いるものほど評点が高くなります。
＿となります。箇条書きのリンク先は、当Blogにおける、インポート機能に関する記事となっています。あっさりと記事を書いているアプリほど少ない手間でインポートができます。
＿MoneyProは、収入取引をまともに取り込めないという例の不具合さえ解消されれば、かなりいい線行っているのですがね…
＿が挙げられます。マスターマネーが優れているのは、データを抽出した結果を即座にそのままエクスポートできるためで、筆者が我が友と断言して憚らない理由がここにあります。がまぐち君も似た機能があるのですが、操作する場面によってデータ形式が微妙に変わることから、このリストには載ってきません。
＿筆者がアプリの機能を再発見したり、誤解していた等の理由で評価を見直すこともございますので、あくまで読者各位のご参考程度に、ということでお願いします。
個別のアプリに関する解説は 2021/02/04 第一弾 Dr.WalletとMoney Pro篇 以降の記事を参照して下さい。
＿2021/01/04「家計簿アプリのカレンダーを修正しましょう」で述べた件ですが、これまで当Blogで取り上げた家計簿アプリの対応状況は↓のようになります。改めてまとめてみると、カレンダー機能って結構アプリごとの差異が大きいんですね…。
＿今回は2021年の家計簿アプリ業界の展望らしきものをエラソーに語ってみたいと思います。
＿2018年に施行された改正銀行法により、それまで銀行と何の契約関係も無いままアカウントアグリゲーションサービス（AAS）を提供していたオンライン家計簿サービス各社（PFM事業者）は、銀行との個別契約に基づきAPI連携により残高・明細情報を取得することが義務づけられました。その期限は2020年5月末であったものが、新型コロナウィルスの影響により2020年9月末まで延長されましたが、各PFM事業者はそれまでに何らかの対応を迫られたわけです。
＿その影響と思われるものとして、
＿…という具合に、脱落あるいは縮退する動きが見られました。
＿2020年12月末現在、各PFM事業者が提供している口座連携機能（AAS）の状況をまとめると以下のようになります。筆者が把握していない情報があることはご容赦ありたく。
＿各社の金融機関の対応状況を、これらの資料と、筆者の独断と偏見で図式化すると↓のようになります。表中の色が濃いほど熱心に対応していることを表しています。
＿事業用ではない一般消費者向け家計簿アプリにAASを提供しているのは、2020年末時点で↑の7種類、というのが筆者の認識です。これ以外にもありましたらぜひご教示下さい。
＿2019年までの家計簿アプリは
＿でAASを提供していたわけですが、銀行との連携機能がAPI接続（有償）化されたことで、前者のビジネスモデルでAASを維持するのは困難になってきたと言えそうです。
＿また、API接続化により、（スクレイピングに求められていた）銀行サイトの仕様変更に追随していく情報収集力と開発力は必要無くなり、AAS間の能力差は縮小しました。今後は、未だスクレイピングのまま残っている、銀行以外のサイトとの接続維持と対象拡大で競争することになるでしょう。
＿そうなると…MoneyLookは銀行・クレジット・電子マネーに対象を絞ったことで一般消費者向けとしての戦闘力は大きく下がるのではないかと危惧されます。Dr.Walletも、2020/12/11の記事で述べたようにレシーピ！との統合による競争力強化が期待されますが、レシート入力・レシート認識に特化するのか、それとも銀行以外のサイトとの連携機能を強化する（というかデータ取得の確実性を他のAASの水準に追いつかせるのが先決ですが）のか、どのように方針を定めるのかが重要になるでしょう。
＿そして、LINE家計簿はどうするのか？…銀行だけ連携できても家計管理にはほとんど役に立たないので、2021年4月以降に開設するとされている いわゆるLINE銀行（みずほ銀行との提携による）やLINE Payと強固に連携して、LINE経済圏にユーザーを取り込むための家計簿アプリに特化するのでしょう。【追記】その後、LINEはLINE Pay・LINEポイント以外の連携機能の撤廃を3月31日をもって撤廃しました。
＿ところで、いち消費者として業界全体に求めたいのが…家計管理に必要な、残高や明細履歴（買い物履歴）といった情報について、銀行以外の各社が共通的なAPI接続の仕組みを構築することです。スクレイピングでは、セキュリティ確保、PFM事業者の開発リソース、ネットやサーバーへの負荷等、あらゆる点で問題がありすぎます。2021年はこの動きが出てくることに大いに期待したいところです。
＿家計簿アプリの業界は、「新年から家計簿を始めよう」という人を狙っていろいろ宣伝活動を強化するのだそうですが、筆者としましては、家計簿の記帳は旧年中から始めておくことを強くお奨めします。というのは…
＿…こういうことがあるからです。家計簿アプリの運営側に問い合わせたいと思っても、来週末にはお休みに入っています。
＿さらに、金融機関サイトも、年末年始はメンテナンスを入れたりするためにサービスを休止するところがあるので、いざ自分の口座の残高や取引情報を調べようとしてもできない→家計簿を付け始める際の最初にやらねばならない作業から頓挫する→「やあめた！」 という事態になるでしょう。
＿忙しい時期ですが、今すぐ取り掛かりましょう。
＿本日、ZaimのWeb版にアクセスしておりますと、↓のような表示が目に入りました。
＿今年の3月末でKakeibonがサービスを終了する前に似たような動きがあったので（※1）もしやと思いレシーピ！の公式サイトを見てみますと
＿…2ヶ月前の情報でした。
＿筆者は一定周期で金融機関サイトのログインパスワードを変更するようにしております。
＿これって、最近の通説では「定期的なパスワード変更をユーザーに強いると、ユーザーがパスワードを使いまわすようになり、却ってセキュリティレベルが下がるからやめたほうがいい」ということになっているらしいです。しかし、オンライン家計簿サービスを常用していると、金融機関サイトにログインする習慣が無くなることで
＿しかし、こういう作業は日曜日の夜にはやらない方がいいですね。金融機関サイトはメンテナンスを日曜日の夜に行うことが多いためです。
＿特に12/6はZaimのサイトメンテナンスも重なったので、金融機関サイトのパスワード変更を終えた後、Zaimに登録してあるパスワードを変更する（銀行はAPI連携になっていても、それ以外の金融機関はまだスクレイピング連携のままのところばかりですから）前にZaimにアクセスできなくなって大変困りました。アカウントアグリゲーションサービスでは、古いパスワードでアクセスして「違っているぞゴルア」と怒られてもしつこくアクセスを試みて、金融機関サイトから当該のIDをロックアウトされるケースがあるのです。
＿結局翌朝に大急ぎで作業して事なきを得ましたが…サイトメンテナンスのスケジュールは押さえておかないとダメですね。
＿以前から気になっていたことですが、携帯電話会社から請求される通信料の金額には、実は費目として「通信料」に含めるべきでないものが含まれていますよね？ 例えば有料アプリの料金とか、携帯電話会社が運営している通販サイトの代金とか。
＿そういった付帯サービスの決済額が通信料に対し小さいものであれば、まとめて「通信料」として記帳してもいいのでしょうが、そうでないとなると家計管理が不正確になってしまいます。買い物の履歴も残りませんし…
＿では、どうやってそういう付帯サービスの決済額を把握するか？ 例えば、auならauのサイトにau IDでログインして料金の内訳を確認すると、↓のように「auかんたん決済」の内訳が表示されます、が…
＿ドコモ口座事件を契機に、銀行口座からの不正引き出しが次々発覚しておりますけれども、SBI証券の件は愕然としましたな。SBI証券に口座に不正ログインした第三者が勝手に株式を売却し得た資金を、その証券口座の持ち主と同じ名義で作った銀行のニセ口座 に送金し引き出した、という様相です。この犯罪を成功させるには、被害者をAさんとして
＿の二つが必要なわけですが…前者の情報により後者の情報を参照することは出来るので、トリガーはやはり前者の情報がどこからか漏れた、あるいは窃取されたこと、になるのでしょう。
＿さて、そうなるとその漏れ口を塞いでいかねばなりません。そこで筆者がリスクであると思いますのがアカウントアグリゲーションサービス（AAS）です。
＿前回の記事で銀行とAASとのセキュリティ確保について述べましたが、実はAASのAPI接続化というのはあくまで銀行だけが対象であって、証券会社やクレジットカード、何とかPay、電子マネー等には全く及んでいないのです。つまり、PFM事業者がユーザーのIDとパスワードを保持し、サイトへのログインを代行するという構図は変わっていません。
＿そしてその中で、資産額の面で最も危険なのが証券会社ですね。もちろん、証券会社はログインパスワードの他に取引パスワードを設けて、顧客の資産に直結する操作にはセキュリティレベルを上げているわけですが… IDとパスワードまで漏れていれば、取引パスワードを窃取するまであと一歩なのですから破られるのは時間の問題です。対策としては、ユーザーが可能な限り長くランダムなパスワードを設定して、頻繁に更新するしかない…
＿そういうわけで、銀行APIの次は証券API、そしてクレジットAPI、電子マネーAPIの順に、AASを安全に活用できる道筋をつけることが必要でしょう。特に証券会社のサイトは、保有している銘柄の時価や評価損益など銀行以上に多くの情報を表示するためスクレイピングでの情報抽出は困難であり、API化は非常に有用・有益です。
＿今回のような不正引き出しは、完全撲滅がおそらく困難であり、早期発見・早期対処（例えば資金が流出した先の銀行口座を迅速に凍結するなど）が肝要で、AASによって自分の口座の残高の変動をモニタリングするしかありません。しかし、そのためにAASにリスキーな情報を預けるというのもナンセンスな話でしょう。そういう状況を一刻も早く解消すべく、証券業界の行動が望まれるところです。
＿例のドコモ口座事件に関してマスコミで喧伝されているのが「セキュリティの甘い地方銀行が狙われた」というキーワードです。このキーワードには
＿の二つの解釈ができ、マスコミは当然ながら前者で解釈されることを狙って庶民の不安を煽るわけです。
＿しかし…地方銀行って本当に（大手銀行に比して）セキュリティが甘いのか？ と言うと…以前からアカウントアグリゲーションサービス（以下、適宜AASと略します）を活用している筆者としては疑問に思います。そこで、今回は銀行とPFM事業者（Personal Financial Managementの略。ここではAASを提供している事業者）との間でどのようにセキュリティを確保してきたか、その変遷を解説したいと思います。
＿今から10年以上前から、NTT CommunicationsのAgurippa（MSN残高照会サービスはこれをベースに提供されていた）やMoneylookが提供していたアカウントアグリゲーションサービスの流れを↓に示します。マネーフォワードME・Zaim・Moneytreeも最近まで、2020年3月にサービス停止したKakeibon、2020年4月に銀行との連携を取りやめたDr.Walletもこの方式が主流でした。
＿ドコモ口座事件について続報。やはり、といいますか、アカウントアグリゲーションサービスに対する不安を払拭するため、両巨頭が動いています。こちらは↓マネーフォワードMEのお知らせ。
＿一方、こちらは↓Zaimのお知らせ。いずれもスマホアプリの通知機能で表明されているものです。
＿ちなみに、Moneytreeについては筆者が調べた限りでは動きは見られません。もっとも、調べなければ判らないような情報発信ではやっていないのと同じですけどね…
＿ところで、今回の事件は、
＿とのことで、筆者も心配になって両親に「通帳記帳をした方がいい」と連絡しました。何せ預金者当人が残高を監視していなければ被害に遭ったことを検出できないのですから。幸いにして被害はありませんでしたが… 今後、そういう動きが広がっていくのかもしれません。
＿「ドコモ口座」サービス悪用による銀行口座からの不正引き出しの件です（最初に本件のネット記事を見たときには「どこもろざ？」と勘違いしました）。様相についてはマスコミで既報のとおりかと思いますが、
＿銀行口座番号は社会一般でやり取りすることがあり得る情報ですが、暗証番号はそうではありません。しかしたった4桁の数字であり、ユーザーのプロフィールから高い確度で推測可能という脆弱性があります。街中のATMであれば人間が機械にアクセスする場面があるのに対し、オンラインでこの二つの情報だけで資金引き出しが出来てしまうというのは非常に危険です。そのリスクの対策として月間30万円までの制限を課していたようですが、被害を軽減する効果しかない…。
＿つまり、ドコモ側も銀行側も、セキュリティに関するバランス感覚がおかしいのです。
＿ドコモ側は、ユーザーの非常に危ない個人情報を預かるリスクを平気で犯しています。電子マネーのチャージであれば、普通はそういうリスクをクレジットカード会社と分担しますよね？
＿銀行側は、アカウントアグリゲーションサービスに対してあれだけセキュリティを問題視し、国を動かして規制をかけてまで銀行オープンAPIという仕組みに移行しているのに、一方でこんなにチョロい方法で資金引き出しができる仕組みを作ってしまう。普通ならオンラインバンキングサービスと紐づけさせるところでしょうし、そうしている銀行もあったそうです。
＿昨年の7Pay事件から得た「普及を急ぐあまり、セキュリティの甘いシステムを構築してしまうと痛い目に遭う」という教訓はどうなったのだろう…。セキュリティ上の手間を惜しむような（そうしなければキャッシュレスに取り組まないレベルの）ユーザーは置いて行っていっこうに構わないと思うんですがね。
＿当面、この被害を防ぐには、それこそアカウントアグリゲーションサービスで銀行口座の残高をモニタリングするしかない、という状況です。気を付けましょう。どんなところから口座番号が漏れているか知れたものでありません。
＿Zaimからは8/21、マネーフォワードMEからは8/28に、三菱UFJ銀行が発行するクレジットカード（スーパーICカード）と口座連携をしているユーザーに向けて「9月末をもって連携を取り止める」というメールが送付されました。
＿スーパーICカードの利用履歴等を確認できるサイトは、三菱UFJ銀行のサイトの内部にあります。よって、PFM事業者（アカウントアグリゲーションサービスを提供する事業者）が同カードの取引情報を取得するには、同行のサイトにアクセスして、そこからクレジットカードメニューに入り込まねばなりません。その手順はWebスクレイピングに拠っています。
＿しかし、三菱UFJ銀行の預金口座の取引情報を取得する手順は、改正銀行法によって正式にはAPIに拠ることになります。
＿つまり、同じPFM事業者が三菱UFJ銀行のサイトにアクセスする方法が2とおり存在することになり、セキュリティ面でのリスクが Webスクレイピング＞API である以上、Webスクレイピングによるアクセスを認めるわけにはいかない… となったようです。筆者は以前からスーパーICカードのこの問題については「どうするんだろう」と気にはなっていたのですが、アクセス取り止めっちゅうことで少々不便になってしまいますね。
＿特にマネーフォワードMEは、金融機関サイトと連携している口座へのデータの手入力ができないので、取引履歴が不連続になってしまい大変困ります（そして運営側はこういう事態に手立てをしない…）。Zaimはそれが出来るので、スーパーICカードのサイトからダウンロードした明細をユーザー側からアップロードすることもできます。
＿因みに、Moneytreeは…というと、筆者の場合は、6月中旬以降の取引データが取得できていません。その時期に三菱UFJ銀行の連携をスクレイピングからAPI接続に切り換えたか記憶が無いので何とも言えませんけど、少なくとも現在のAPI接続では、同行発行のクレジットカードとの連携機能は提供されていません。こちらはMoneytreeからの告知は無かったです。
＿さらにDr.Walletは…2020/05/22「銀行法改正に伴うオンライン家計簿サービスと銀行のAPI連携も一筋縄ではいかないようです」で既報のとおり、今年の4月末で銀行との連携機能を全面停止していますが、スーパーICカードについては連携機能をまだ提供しています。もっとも、例によって「現在取得に問題が発生しております。申し訳ございませんが、しばらくお待ち下さい。」という事実上の取得停止状態ですがね。
＿さて、スーパーICカードのデータ取得が（アカウントアグリゲーションサービス経由で）不可能になる件、どう対処したものですかね。同カードのサイトからダウンロードしたCSVファイルをMFF形式に変換するマクロを作るしか無いか…。
＿マイナンバーとキャッシュレス決済手段を紐づけることでポイント還元を受けられる「マイナポイント」にオンラインで申し込んでみました。筆者が選択した決済サービスは「モバイルSuica」（ポイント還元はJRE POINTで受けることになる）ですが、他でも多分ほとんど手順は変わらないでしょう。
＿まず、https://mynumbercard.point.soumu.go.jp/flow/mykey-get/にアクセスします↓。ここではマイナンバーカード対応のICカードリーダライタを持っている前提で、【パソコンの場合】の【インストール】を叩きます。
＿Impress Watchのこちらの記事によれば、MicrosoftがMicrosoft 365の新機能の一つとして「Money in Excel」のサービス提供を米国で開始したそうです。いずれは日本でも展開されるそうですが、現時点でMoney in Excelに関するネット上の情報は少ないです。筆者が既報で見つけられているのは
＿このようなところです。最も詳しいのは3番目の記事ですね。しかし、これでも、最も肝心なところが全然判りません。すなわち
＿さらに、大いに気になるのが、Impress Watchの記事の
金融口座を接続する処理にはWindows/Mac版の「Excel」が必要だが、
＿の部分です。
＿これを深読みすると、銀行サイトへの接続の認証情報（API接続のトークン）はローカルPCのアプリ版Excelに保持され、クラウドサービス的に使うことはできないものと予想されます。このようにすることで、PCのWindows10マシンへのログインとMicrosoft 365へのサインイン（筆者はこの言葉が嫌いなんですよね）をもってセキュリティを確保するのでしょう。
＿しかし、銀行だけでなく、クレジットカードや電子マネーへの対応はどうなるのか（API連携対応のところなんてほとんどありませんし、まさかスクレイピングエンジンをローカルPCにインストールするのか？）、とか、提供されるテンプレートは家計簿としてどれぐらい使えるのか（そもそも日本語対応なんだろうな？）とか、情報がまだまだ不足しております。何せ"Money in Excel"でググっても、英語のサイトか、上記の記事か、筆者の旧Blogの記事しかヒットしないんです。まいったなこりゃ。
＿2020年5月18日「銀行法改正に伴うマネーフォワードMEの銀行連携機能の変更」（旧Blog）で触れましたように、アカウントアグリゲーションサービスを提供するオンライン家計簿サービスが銀行とのAPIでの連携を拡大しています。今回の記事では、各サービスの動向について述べます。
