社内ツールからSaaSへ：銀行取引明細のダウンロードを自動化する
当社は、Wiseの銀行取引明細を自動でダウンロードするスクリプトを作りました。これは午後の数時間で済む作業です。より興味深く、答えを出すのにずっと時間がかかったのは、同じ課題を抱える他社にもこのツールを提供できるか、そして責任を持って提供するには何が必要かという問いでした。開発者のノートパソコンで動くCLIスクリプトから、メール通知付きのコンテナ型サービスへ移行する過程で、記録しておくべき判断がいくつも見えてきました。特に、社内の自動化を製品にする価値があるか検討しているチームには参考になります。
元の問題
Wiseには口座データへアクセスするAPIがありますが、多くの経理チームでは、毎月末にWeb画面へログインして取引明細のCSVを手動でダウンロードしています。一つの口座で一つの通貨を扱うだけなら、2分で済みます。しかし、地域ごとの決済がある企業によく見られるように、複数のWise口座で複数通貨を扱うと、誰かが忘れず、毎回同じように実行し、正しく整理・保存しなければならない定例業務になります。
Wise APIには、必要なエンドポイントがあります。プロファイル一覧と通貨ごとの残高を取得し、任意の期間の明細をCSVまたはPDFで書き出すよう要求できます。認証には、Wiseの開発者ダッシュボードで生成する個人アクセストークンを使います。適切に権限範囲を設定すれば口座データの読み取り専用となり、送金を実行できるトークンと同じリスクを負うことなく保存・利用できます。
最初の実装は約80行のPythonでした。環境変数から認証情報を読み込み、プロファイルと通貨別残高を順に処理し、前月分の明細を要求して、出力ファイルをローカルディレクトリに保存していました。手動で実行する仕組みで、当時の当社の用途には十分でした。
スクリプトからスケジュールされたサービスへ
「手動で実行する」から「自動で実行する」への移行では、別の種類の課題が生じます。手動実行したスクリプトが何も通知せずに失敗しても、すぐに気付きます。毎月1日に定期実行するスクリプトの場合、失敗に数か月気付かず、監査の際に明細の保管漏れが見つかることがあります。
当社はスクリプトをシンプルなエントリーポイントを持つDockerコンテナへ移し、成功・失敗のどちらでも完了時にメール通知するラッパーを追加しました。メールには、処理した口座と通貨、ダウンロードしたファイル数、ファイルサイズの要約を含め、失敗時にはエラー出力も添えます。可観測性への最小限の投資ですが、運用の前提は変わります。無人で実行していても、処理状況を監督できるようになりました。
スケジュール管理はコンテナ内のcronではなくGitHub Actionsで行います。毎月初めに実行するワークフローで、scheduleトリガーを使います。cronのスケジュールだけでは営業日を指定できないため、週末や祝日を除外するにはワークフロー内で日付を追加確認する必要があります。ワークフローはリポジトリをチェックアウトし、変更があればDockerイメージをビルドし、GitHub Secretsからシークレットを注入してコンテナを実行し、出力ファイルをワークフローのアーティファクトとしてアップロードします。アーティファクトは90日間保持され、ローカルのファイル保存先とは独立して取得できる保管場所になります。
サーバー上のcronジョブと比べたGitHub Actionsの実用上の利点は、実行状況が見えることです。履歴には、すべての実行、所要時間、終了コード、生成したアーティファクトが表示されます。サーバー上のcronはログを見落としやすく、サーバーの稼働状態にも依存します。月次処理なら、バージョン管理されたワークフロー定義で監査可能な実行履歴を残せる価値は、設定にかかる小さな負担を上回ります。
「マルチテナント」が実際に必要とするもの
コンテナ版が数か月にわたり安定稼働した後、他社の知人から使いたいという相談がありました。他の人もこのツールを実行できるかという単純な質問に聞こえます。しかし実際には、「他の人が使う」には、意味合いが大きく異なる幅広い運用モデルが含まれます。
最も簡単なのは、リポジトリとドキュメントを公開し、利用者が自分のGitHub ActionsやDocker環境で実行し、当社はサポートを提供しないモデルです。これはオープンソースとしての配布であり、SaaS製品ではありません。運用負荷はすべて利用者が負います。
次の段階は、当社がツールをホストし、利用者が設定画面から自分のWise APIトークンを提供する形です。この時点で、当社は認証情報を預かることになります。個人用の自動化とは性質の異なる、セキュリティとコンプライアンス上の責務が直ちに生じます。認証情報をどう保存し、誰がアクセスでき、保存先が侵害されたら何が起きるのか。利用者のWise口座が当社のプラットフォーム経由でアクセスされた場合、どのような責任を負うのか。これらに答えなければなりません。
その次の段階では、課金、サポート、サービスレベルの約束、複数ユーザー向けインフラを動かす運用負荷が加わります。いずれも解決不可能ではありませんが、どれだけの開発投資と継続的な運用コストを引き受けるか、それぞれ判断が必要です。
SaaS化の評価
当社は、最小限のマルチテナント版に必要な要件を列挙し、一つずつ現実的に費用を見積もりました。Wise APIトークンの安全な保存、管理UI、テナント間のアクセスを防ぐ制御といった認証情報の管理だけで、明細ダウンロード機能に着手する前に1週間の開発が必要です。さらにユーザー認証、課金、配信停止に対応するメール配信サービス、テナントごとのジョブ失敗監視を加えると、安全に維持するために継続的な投資を要する製品になります。
このツールの市場にも限りがあります。明細ダウンロードの自動化を必要とする規模の企業は、Wiseと直接連携する会計ソフトを使っていたり、経理チームが独自の方法ですでに解決していたりすることが少なくありません。対象となるのは、負担を感じる程度には規模が大きいものの、まだ統合された会計システムを使っていない中間層の企業です。
当社は、現段階ではこのツールをSaaS化するのは自社チームに適さないと判断しました。見込める収益は、開発と運用への投資に見合いませんでした。オープンソースとして配布すれば、維持できない責務を負わずに、実際の需要を満たせます。
維持したものと変更したもの
社内ツールは今も稼働しています。その後、CSVに加えてPDF出力に対応し、ワークフローのアーティファクトを取りに行く代わりに明細をメールへ直接送れるようにしました。対象期間も設定可能にし、定期の月次処理を変えずに、必要に応じて手動で明細を取得できるようにしています。
GitHub Actionsのワークフローが、標準のデプロイ方法になりました。リポジトリのREADMEには、6か月間ツールに触れていなかった人でも、何をする仕組みで、どう操作するか分かるだけの説明を載せています。これはあらゆる社内自動化に適用すべき習慣です。いつか実際に引き継ぐことになるため、他の人へ引き継ぐ前提で社内ツールを扱うべきです。
このプロジェクトで得た最も長く役立つ教訓は、「当社では使える」と「他社でも使える」の間にある隔たりです。社内ツールは、認証情報の管理方法、ファイルの保存規則、メール基盤など、自社固有の制約に合わせて作られています。他の人が使えるほど汎用化するには、設定ファイルを追加するだけでは足りません。他の人が使って初めて気付く暗黙の前提を、切り離す必要があります。