はじめに
こんにちは！コインチェック株式会社（以下、コインチェック）トレジャリー部リクイディティオプティマイゼーショングループ（以下、リクオプGr）の梅下です。私のグループでは、主にディーリング業務やリスク管理業務（※）に関するデータ分析を担当しています。
業務の1つとして「資金管理最適化」を行っております。この分析業務の運用で、分析の作業効率を高める取り組みを行いましたので、紹介したいと思います。
※ ディーリング業務やリスク管理業務：コインチェックが保有する暗号資産の残高・ポジション管理、および自社取引所・外部取引所への注文（カバー取引）・約定管理を行う業務。また、それら暗号資産のリスク管理業務。
対象読者
この記事は、以下のように「分析業務を効率的に運用に乗せていきたい」という課題を持っている方を対象としています。
- 特定メンバーがローカルでPythonのスクリプトを動かしながら行っている分析を、誰でもすぐに実行できるように改善したい
- コードを変更せずに、分析のパラメータ調整や結果確認ができる仕組みを作りたい
この記事の要約
- 資金管理最適化の分析業務では、立ち上げフェーズではローカルでPythonスクリプトを実行して分析を行っていましたが、運用フェーズに移行するにあたり、分析の作業効率や結果共有のしやすさの面で改善が必要でした
- Google Cloud（Cloud Run）上にStreamlitの画面を構築し、ブラウザから分析を実行できる仕組みに移行しました
- 分析結果はBigQuery・Cloud Storageに自動保存し、スプレッドシート・Looker Studioで結果表示することで関係者に共有できるようにしました
- これにより、1回の分析にかかる作業時間が約30分かかっていたのが5〜10分に短縮され、環境構築なしで誰でも分析を実行できるようになりました
背景
分析内容
「資金管理最適化」の分析の1つとして「自社ホットウォレットの基準値最適化」があります。
コインチェックでは、顧客の出金などに対応するために、ホットウォレット（即座に送金可能な状態で保管している、インターネットに接続されたウォレット）に一定量の暗号資産を保有しています。
保有量が多いほどオペレーションはしやすくなりますが、その分リスクも大きくなります。
この「運用のしやすさ」と「リスク量」のバランスが取れるホットウォレット基準値を、過去の入出金データなどをもとに分析・提案しています。
関係者と役割
この分析では、私が所属するリクオプGrが分析をもとにホットウォレット基準値を算出し、同じトレジャリー部のマーケットリスクコントロールグループ（以下、マケリスGr）へ提案します。
マケリスGrが運用面を考慮した上で、システム上のホットウォレット設定値を決定・反映するという流れで運用しています。
分析フェーズ
私が参画した時点では、分析モデル作成や検証を行う立ち上げフェーズが完了し、定常的に分析を回していく運用フェーズに移行するタイミングでした。
立ち上げフェーズでは、複数のPythonスクリプトをローカルで実行して分析を行っており、分析モデルの構築や検証を進める上ではこの方法で十分でした。一方で運用フェーズでは、パラメータを変えながら繰り返し分析を回せるように分析の作業効率を上げることや、関係者への分析結果の共有のしやすさが求められました。
そのため、以下のような点を改善する必要がありました。
- 分析実行の手軽さ: メンバーがローカルでPython環境を構築したり、実行手順・コマンド操作方法を把握してなくても、手軽に分析を実行できるようにする
- パラメータ管理: コードを編集せずに（分析対象通貨や分析日数などの）パラメータを変更でき、過去の実行条件も追跡できるようにして再現性を高める
- 結果の確認・共有: ローカルで分析結果のグラフ画像やCSVファイルを手動で確認・共有するのではなく、関係者全員がアクセスできる場所に自動保存されるようにする
運用方針
背景で述べた運用に向けた改善点を踏まえ、以下のような方針を立てました。
- 分析の実行: リクオプGrがブラウザで分析用の画面にアクセスし、パラメータ設定から分析実行までを画面上で行う
- 結果の保存: 数値データはBigQueryに、グラフ画像や分析で扱った入出力データ（CSVファイル）はCloud Storageにそれぞれ自動保存される
- 結果の共有: 社内メンバーに数値を共有するため、BigQueryのデータはスプレッドシートに、Cloud Storageの画像はLooker Studioに自動連携し、マケリスGr・リクオプGrが結果を確認する
※ 結果表示では、ダッシュボードなど画面を自作することも可能でしたが、工数やメンテナンスコストを抑えるために、手軽に使えるスプレッドシート・Looker Studioを使用しました。
技術選定
運用方針を実現するにあたり、インフラ基盤としてGoogle CloudのCloud Runを、UIフレームワークとしてStreamlitを採用しました。それぞれの選定理由を紹介します。
Cloud Run
ブラウザから分析を実行できる環境として、Cloud Runを選びました。主な理由は以下の3点です。
- BigQueryとの親和性: コインチェックの分析データはBigQueryに蓄積されており、同じGoogle Cloud上で動作するCloud Runからスムーズにデータ連携が行えると考えました
- 既存の知見の活用: 別の分析基盤構築でCloud Runサービスを利用した経験があり、その知見を活かして素早く仕組みを構築できると判断しました
- IAP認証による手軽なアクセス管理: Google CloudのIAP（Identity-Aware Proxy）認証をCloud Runに適用することで、社用Googleアカウントによる認証が可能になります。社員全員がGoogleアカウントを持っているため、別途認証基盤を用意することなく、必要なメンバーだけにアクセスを絞ることができ、手軽に権限管理が行えると考えました
Streamlit
分析画面のUIフレームワークとして、Pythonだけで画面を構築できるライブラリを検討しました。
候補としてStreamlitとGradioの2つを挙げて、以下の観点で比較してStreamlitを採用しました。
| 観点 | Streamlit | Gradio |
|---|---|---|
| 主な用途 | データアプリ・ダッシュボード向けで、データの可視化に強い | 機械学習モデルのデモ向けで、機械学習のワークフロー構築に強い |
| コンポーネントの充実度 | グラフ描画やデータ表示系のコンポーネントが充実している | 画像・音声・動画・チャットボットUIなど、機械学習の入出力系コンポーネントが充実している |
| 記述スタイル | 命令型（上からコードを書いた順に処理が実行される） | 宣言型（UIコンポーネントとコールバックを定義する） |
| 情報量の多さ | Google Trendsでの検索ボリュームがGradioの約4倍あり、利用者・情報量がより多いと考えられる | Streamlitと比較すると検索ボリュームは少なめ |
今回の事例をきっかけに、将来的に別プロジェクトでも同じフレームワークを使いたいと考えていたため、自グループの分析の特徴に合ったフレームワークを選ぶことを重視しました。
自グループでは数理的な手法を使うことが多く、トレンドグラフや分布の可視化が頻繁に発生します。そのため、グラフ描画のコンポーネントが充実しているStreamlitの方が自グループの用途に合っていると考えました。
また、Streamlitは上からコードを書いた順に処理が実行される命令型の書き方をします。自グループのPythonコードは命令型の書き方が中心だったため、グループメンバーにとってStreamlitの方が直感的に読み書きしやすいと判断しました。
実装
実装に関してはポイントとなる部分のみを紹介します。
Cloud RunでのIAP認証
Cloud RunサービスのIAP認証を有効化し、社内の特定メンバーのみがアクセスできるようにしました。
以下はTerraformでの設定例です。Cloud Runサービスの定義で iap_enabled = true を指定してIAPを有効化し、invoker_iam_disabled = true でIAPを唯一の認証ゲートにしています。
# 主要部分のみ記載 # Cloud Run の IAP 機能は google-beta プロバイダで提供されている terraform { required_providers { google-beta = { source = "hashicorp/google-beta" } } } resource "google_cloud_run_v2_service" "hw_optimization" { provider = google-beta ingress = "INGRESS_TRAFFIC_ALL" # IAP経由のアクセスを受けるため全トラフィックを許可する invoker_iam_disabled = true # IAPを唯一の認証ゲートにする iap_enabled = true # IAPを有効化する }
分析画面にアクセスできるメンバーを集約したGoogle Groupsを作成し、google_iap_web_cloud_run_service_iam_member リソースで、そのGoogle Groupsに以下のように権限を付与しています。
Google Groupsへメンバーを追加・削除することで、コードを変更せずにメンバーの権限管理を行えるようにしました。
resource "google_iap_web_cloud_run_service_iam_member" "hw_optimization_auth" { cloud_run_service_name = google_cloud_run_v2_service.hw_optimization.name for_each = toset([ "group:example-group1@example.com", "group:example-group2@example.com" ]) member = each.value role = "roles/iap.httpsResourceAccessor" }
Streamlitの利用
StreamlitではPythonを使って画面を作成できます。以下は分析画面のパラメータ入力部分の簡易的なサンプルコードです。
import streamlit as st import pandas as pd st.title("💡 HW基準値最適化の実行") # 数値の入力ボックス st.subheader("全通貨共通パラメータ") admin_days = st.number_input("全通貨共通の分析日数", min_value=1, value=30) # 表形式の入力ボックス st.subheader("通貨別パラメータ") default_df = pd.DataFrame({"通貨": ["btc"], "通貨別の分析日数": [90]}) # num_rows="dynamic" を指定すると画面上で行の追加・削除ができ、通貨ごとのパラメータを管理できる edited_df = st.data_editor(default_df, num_rows="dynamic") # ボタンとクリック時の挙動制御 if st.button("🚀 分析実行"): with st.spinner("分析中... パラメータによっては数分かかることがあります"): # ここで分析処理を実行する st.toast("分析が完了しました")
実際の画面は以下のようになります。
以下のように、同じ画面で分析結果を表示・保存する部分も作りました。
スプレッドシートでの数値共有
スプレッドシートの「データコネクタ」機能を使ってBigQueryに接続し、分析結果の最適値をスプレッドシートに表示しました。
ポイントとしては、単に分析ロジックによる最適値を提案するのではなく、リクオプGrの分析者が精査した後に提案するため、以下の3軸に分けてスプレッドシート上で数値を追跡できるようにしました。（画像赤枠）
- 分析ロジックにより算出された最適値（BigQueryに保存されている値）
- リクオプGrの分析者が精査した後の最適値（マケリスGrへの提案値）
- マケリスGrが実際に採用したシステムの設定値
また、Cloud Storageに保存されている過去のグラフ画像へのリンクもスプレッドシートに出力することで、過去の分析結果の画像も追跡できるようにしました。（画像青枠）
結果
背景で述べた3つの改善点に対して、以下の結果が得られました。
- 分析実行の手軽さ: 画面上で分析を実行できるようになり、分析時にはローカルでの環境構築や実行コマンドの把握が不要になりました。結果、「分析パラメータ設定〜提案値の整理」に要する時間は、1回あたり約30分かかっていたのが5〜10分に短縮されました
- パラメータ管理: 実行時のパラメータはCloud Storageに自動保存されるため、過去の実行条件を追跡できるようになり、分析の再現性が高まりました
- 結果の確認・共有: 数値結果をBigQueryに保存してスプレッドシートに連携したことで、過去の提案値や設定値を見返しやすくなり、数値の変動を追跡しやすくなりました。グラフ画像もLooker Studioを通じて関係者が分析直後に確認できるようになりました
おわりに
本記事では、分析業務の立ち上げフェーズから運用フェーズへの移行にあたり、ローカルでPythonスクリプトを実行していた分析をCloud Run上のStreamlit画面からブラウザで実行できる仕組みに移行した取り組みを紹介しました。
この記事が、同じように分析業務の運用改善に取り組んでいる方の参考になれば幸いです。
