Lambdaカクテル

Common LISPが好きなWeb屋さんです 自宅サーバやフロントエンドもできます

情報化時代の家計簿、銀行の認証、情報取得API

金銭管理は大事だと思って去年あたりからきっちり家計簿をつけている。

最近は便利なWebサービススマホアプリがあるもので、家計簿ツールKakeibonスマホから支出を記録できるZaimを使って支出を確認している。

KakeibonはAmazonにログインして買い物を自動的に家計簿に記録したり、ネット銀行の残高を表示してくれたりするけれど、それらのアカウントのIDとパスワードをみすみすKakeibonに教えなければならないのがかなり不安。GMailのように、アプリケーションごとに固有のトークンを発行してそれでデータを取得させるといった方法はいくらでもあるはずだが、体質が堅くてそもそもサービスにAPIの概念が無いような会社(銀行とか)はシステムが古いのでそういうのは全く対応していなくて頑なにIDとパスワード方式で管理しているイメージがある。実際そうなのだけれど。

Amazonはもう少し頑張ってくれるかと思ったが、これもIDとパスワードを教えないと情報を取得できない。

たかだか残額と取引履歴を照会するだけなのにIDとパスワードを教えてフルアクセスを許可しないといけないのはおかしい。当のKakeibonは金融機関並の暗号化だかなんだかを標榜している*1ものの、そういう問題ではないと思う。郵便を投函してもらうのであればポストがあればいいはずで、玄関の鍵を預ける必要性がどこにあるのか。信頼とかそういう情緒的な問題ではなく、そういう設計そのものが問題ではないか。いくらなんでもIDとパスワードを教えさせるのは実も蓋も無いやり方ではないか。原則的に、IDとパスワードは絶対に人に教えてはいけない。今時の高校生でも学校で習うではないか。それを大会社が破っていいの、と思う。

とはいえパスワードを教えないといけないのはなにもKakeibonに全責任があるわけではない。データ取得用APIやそれ用の認証機構を用意しない銀行もおかしい。ネット全盛期にそういうことをしない銀行は吸収合併とかでそのうち潰れると思っている。スマートなんとかとか言って変なプロダクトを作る前に、まずはAPIを整備してネットでの利用を促進する基盤を固めるのが筋ではないのか。だがそれはそれで、そういう状況のまま危険を承知でIDとパスワードをユーザに教えさせるKakeibonの危機意識もどうなのかと思うが。

結局Kakeibonは使っている。正直他のデキるサービスが出たら乗り替えたいけれど、問題の根本が銀行のAPIが無い事に起因しているからどうしようもない。僕の思っていたIT化とは違う時代になってしまった感じがある。

*1:「通信や暗号化は最高水準の方式を採用。金融機関レベルのセキュリティ監査を定期的に受け、セキュリティ維持に努めておりますので、安心してご利用ください。」 サービス機能紹介 | Kakeibon (旧OCN家計簿)