【要約】Stena Expenseの検知アーキテクチャ ── Go × Python × gRPCで不正検知を実現する仕組み [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
膨大な経費データの目視確認は、コストと精度の面で限界がある。解決すべき課題は以下の通り。
- ・組織ごとに異なるデータ形式への対応。
- ・重複申請や統計的異常など、多様な不正パターンの検知。
- ・データ取り込みから集計まで、多段階の複雑な工程と状態管理。
- ・生成AIのみでは、これら複雑なワークフローと精度の両立が困難。
// Approach
1.**ハイブリッド構成**: Go（Controller）でドメイン管理を行い、Python（Predictor）でML処理を分離。
2.**ワークフロー制御**: Google Cloud WorkflowsとCloud Run Jobを用い、各ステップを順次実行。
3.**gRPCコールバック**: PredictorからControllerへ直接結果を送信。Cloud Run Jobによるデータ中継を排除し、メモリ効率を向上。
4.**動的モデルロード**: preprocessorとdetectorをPickle化してGCSに保存。アプリの再デプロイなしでモデル更新を実現。
5.**厳密な状態管理**: Goのドメインモデルで検知ステータスを管理。不正な状態遷移を防止。
// Result
- ・言語の強みを活かした、堅牢かつ柔軟な検知基盤の実現。
- ・検知モデルの更新とプロダクトのデプロイサイクルの完全分離。
- ・大量の検知結果に対するメモリ効率とスケーラビリティの確保。
Senior Engineer Insight
>
GoとPythonの役割分担が極めて合理的だ。ビジネスロジックの堅牢性とMLの柔軟性を、gRPCコールバックという高度な通信手法で繋いでいる。特に、Cloud Run Jobを単なる中継器にせず、PredictorからControllerへ直接結果を叩き込む設計は、メモリ効率とネットワーク負荷の観点から実戦的だ。Pickleによる動的ロードも、モデル更新頻度が高いML領域では運用コストを劇的に下げる。ただし、分散システムにおける状態管理の複雑性は、厳密なステートマシン設計で補完する必要がある。