製造業のデータ利活用は、AIツールを導入する段階から、事業成長や顧客価値の創出につなげる段階へ移りつつあります。欧米の先進企業では、データを資産として扱うData as a Productの考え方を取り入れながら、生成AIだけでなく、物理世界を動かすフィジカルAIをコア業務や人材育成に組み込んでいます。これを実現する上で注目すべきは、ITなど一つの中央部門に依存せず、データ活用の主導権を各部門に分散して持たせるデータメッシュアプローチです。これらを通じて、データ基盤の再設計と組織変革を同時に推し進めています。 本記事では、Dow、Siemens、Rockwell Automationの取り組みをもとに、製造業のデータ利活用を成果につなげる企業の共通点を整理します。これらの製造業DX事例から見えてくるのは、DXの成否を分けるのは個別技術の導入ではなく、データを事業の勝ち筋に変える仕組みを持てるかどうかです。 製造業のデータ活用は「導入」から「成果」へ移っている 製造業におけるAI活用は、検証や一部業務の効率化にとどまらず、事業成果や競争優位につなげる段階へ移っています。2010年頃から、いわゆるビッグテック企業は世界の時価総額上位を占め、デジタルインフラに近い立ち位置を確立してきました。彼らの培ったテクノロジーとデータを活用してビジネスを最適化するアプローチは、金融や小売だけでなく、素材、電機、産業オートメーションなどの伝統的な製造業にも広がっています。 金融業界が伝統的な産業で先頭を切ってフィンテックやデジタル技術を取り入れて業態を変えていったように、製造業でも、これまでデータ活用と距離があった企業が、AIやデータを中核に据えた変革を進めています。 ただし、AIを導入すれば成果が出るわけではありません。2025年の マッキンゼーのAI導入調査 では、88%の企業がAIを導入している一方で、AIを利益の源泉として活用し、EBIT（利払前・税引前利益）の5%以上をAIで創出している「 AIハイパフォーマー 」は6%にとどまるとされています。 AIハイパフォーマーに見られる特徴は、主に次の3つです。 目的設定 : 単なるコスト削減をゴールとせず、売上成長や新規ビジネスの創出（イノベーション）を目的としている 手段の進化 : 新たな技術を積極的に取り入れ、スケールさせている。例えばAIエージェントは全体の62%が実験を開始する中、ハイパフォーマーは他社の3倍以上の割合でエージェントを実際の業務に組み込み「スケール」させている 組織の変革 : 既存業務にAIを足すのではなく、AIやエージェントの存在を前提としてワークフローや人材、業務を根本から再設計している (ハイパフォーマーは65%が実施、その他は23%) これらの「組織の変革」や「業務の再設計」という特徴は、特に製造業において重要な示唆を持ちます。製造業のデータ活用では、設備、工程、品質、在庫、販売、アフターサービスなど、多様なデータが存在します。だからこそ、個別のAIツール導入ではなく、全社としてデータを扱う体制・仕組み作りが重要になるのです。 データメッシュは現場主導のデータ活用を支える考え方 データメッシュとは、各部門が自部門のデータのオーナーシップと責任を持ち、他部門も再利用できる形で提供する分散型のデータ管理アプローチです。2019年に Zhamak Dehghani (martinfowler.com) が提唱した、シリコンバレーのテック企業でも見られるデータ管理の考え方であり、AI活用のスピードに中央集権型の体制だけでは追いつきにくくなったことを背景に広がっています。製造業でデータ活用を広げるうえでは、現場が必要なデータを必要なタイミングで使える状態を作る考え方として重要です。 従来のデータ活用では、IT部門やDX部門が中央集権的にデータを管理し、各部門からの依頼を受けて分析結果を返す形が一般的でした。この体制はガバナンスを保ちやすい一方で、現場が求めるAI活用のスピードや、日々の意思決定の速度に追いつきにくくなるという課題があります。 現場では、品質、設備、原材料、作業条件、需要、在庫などのデータが業務ごとに分かれて存在します。これらを中央の専門部署だけで分析を行う場合、現場特有の背景やニュアンスが十分に反映されなかったり、分析結果が出るまでに時間がかかったりします。 データメッシュの特徴は、次の4点に整理できます。 ドメイン思考の所有者 : 現場部門が、自部門(ドメイン)のデータに対する管理責任と所有権を持つ プロダクトとしてのデータ : データを一度きりの分析素材ではなく、再利用可能な「プロダクト」として扱う セルフサービス基盤 : 各部門が、中央組織を介さずに必要なデータや分析ツールを利用できる環境を整える 連携型ガバナンス : 中央組織は、データ品質、権限、セキュリティ、標準ルールなど、全体ルールを一元管理する このアプローチは、製造業のデータ活用における「現場を巻き込めない」「データがサイロ化している」「分析が一部の専門家に閉じる」といった課題の解決策になります。 中央でのポリシー管理と、現場での分散活用を高度に両立させる具体的な仕組みは、 AI時代のデータ活用の鍵を握る統合データガバナンス で解説しています。 特にAI活用では、モデルの精度だけでなく、モデルが使うデータの品質、定義、更新頻度、そして実際の業務にどう紐づいているか(業務との接続)が成果を左右します。データメッシュは、AIの前段にあるデータ基盤と業務設計を整えるためのアプローチだと言えます。 フィジカルAIは生成AIの次に来る製造業の重要テーマ フィジカルAIは、テキストや画像などの二次元のデジタル空間に閉じていた生成AIなどの技術を、機械、設備、ロボット、工場、車両などが存在する三次元の物理世界へと拡張・実装し、自律的な判断・実行を行うAI技術です（ NVIDIA の公式用語集 も同様に定義しています）。 生成AIが、文章作成、検索、要約、コード生成、業務支援など、主に情報処理の領域で力を発揮する一方で、フィジカルAIは、センサーデータ、シミュレーション、制御技術、現場からのフィードバックを高度に組み合わせ、物理世界の動的制御や状態の最適化に関わる判断と実行を担います。 生成AIとフィジカルAIの違いは、次のように整理できます。 項目 生成AI フィジカルAI 主な対象（AIが働きかける空間・対象物） デジタル空間（テキスト、画像、コード、文書など） 物理世界（設備、製造工程、ロボット、車両、工場など） 主な役割 情報の生成、要約、検索、対話、業務支援 物理世界の状態理解、シミュレーション、制御、最適化、自律的実行 製造業でのユースケース例 作業手順書の要約、PLCコード作成支援、保全履歴の検索 製造条件の最適化、設備制御、デジタルツイン、自律運用 必要なデータ 文書データ、業務データ（日報、マニュアル、FAQ等） センサーデータ、工程データ、制御データ 製造業にとって重要なのは、生成AIとフィジカルAIを対立するものとして捉えるのではなく、相互に補完し合うものとして活用することです。生成AIは、現場の情報探索や作業支援に優れ、フィジカルAIは、設備や工程の最適化、自律化に近い領域で価値を発揮します。 そして、この2つのAIを業務成果に結びつけるための共通の土台となるのが、データ基盤です。マニュアルや業務記録といったデジタルのデータ（IT）と、現場のセンサーや設備のデータ（OT）が分断・サイロ化されず、統合・整理されて常に使える状態になっていなければ、どんなに優れたAIも真価を発揮することはできません。 データ基盤そのものの考え方は、 データ基盤の基礎知識 で解説しています。 製造業のAI活用事例: 欧米先進企業3社に見るデータ利活用の共通点 欧米先進企業の事例から分かるのは、製造業のAI活用は「個別ツールの導入」ではなく、「データ基盤・人材・ユースケースを一体で設計する経営テーマ」だということです。3社はそれぞれ異なる強みを持ちながら、AIを業務の周辺機能ではなく、オペレーティングモデルを変える基盤として扱っています。 Dow: データの民主化により、全社の意思決定と研究開発を高度化している Siemens: 制御技術とデジタルツインを組み合わせ、フィジカルAI時代の顧客価値を作っている Rockwell Automation: ITとOTを統合し、自律工場やAI駆動型オペレーションへつなげている 3社に共通するのは、「データを集める」「AIを試す」段階で止まっていないことです。データ基盤や分析ツールを全社で再利用できる形に整備し、人材を育て、社内の成功モデルを顧客やエコシステムに広げています。 国内製造業での具体的なユースケースは、 製造業におけるAI活用事例 で紹介しています。 Dow: データの民主化で、現場データを競争力に Dow（ダウ）は、前半で解説したデータメッシュアプローチを、大規模な伝統的企業が実装し、成果を上げている先進事例です。この実現には、データ利活用を是とする組織文化の変革が必須であり、一般的にその実行難易度は非常に高いとされています。 同社はデータ活用を企業の競争力の中核に位置づけ、全社的なデータの民主化を進めてきました。世界中で事業を展開する同社には、もともと膨大なデータが蓄積されていたものの、全社で効果的に活用できる仕組みが十分に整っていないことが課題でした。そこで2022年、データの民主化を軸に据えた全社デジタル戦略を始動します。 Dowの取り組みで注目すべき点は、単に分析ツールを導入したことではありません。データ基盤、人材育成、ユースケースを一体で進めている点です。 主な取り組みは次の通りです。 データ基盤 : データメッシュ型の「Integrated Data Hub」を構築し、構造化データと非構造化データを統合 ガバナンス : 中央でルールを管理しながら、各現場がデータをプロダクトとして提供 人材育成 : 全従業員を対象に、役割別のData & Analytics Literacyプログラムを展開 ユースケース : Market Intelligence Hub、Carbon Footprint Ledger、Predictive Intelligenceなどへ活用 出典： Dow プレスリリース , Databricks Data+AI Summit 2025, “Manufacturing Cleaner: How Data Intelligence Cuts Carbon, Not Profits” by Dowを基に作成 同社は、現場主導の高度なユースケースを次々と生み出し、世界的に権威のあるITイノベーションの賞 「CIO 100アワード」を5年連続で受賞 するなど、顕著な成果を上げています。その代表的なユースケースは以下の通りです。 Market Intelligence Hub（市場分析の高度化） : 生成AIを活用し、社内外の膨大なデータから市場動向や競合状況などを瞬時に要約。市場の変化に対する迅速で戦略的な意思決定を可能にしています。 Predictive Intelligence（研究開発の短縮） : ポリウレタン事業において、100万以上のデータポイントを用いた機械学習シミュレーションを導入。従来は数ヶ月を要していた新素材の配合探索プロセスを大幅に短縮しました。 Carbon Footprint Ledger（環境負荷の可視化） : サプライチェーン、サステナビリティ、財務データを単一基盤に統合。製品ごとのカーボンフットプリントを可視化し、顧客に対して信頼性の高い証明書（PCF）を提供することで、バリューチェーン全体の脱炭素化に貢献しています。 Dowの事例から見えるのは、データ活用を一部の分析チームだけに閉じないという考え方です。現場やビジネス部門がデータを使える状態を作り、全社の意思決定スピードを高めることが、AI・データ活用の前提になっています。 Siemens: フィジカルAI時代を見据え、データ基盤とエコシステムを再設計 Siemens（シーメンス）は、データ・AIを活用して物理世界とデジタル世界を融合させる戦略で、製造業におけるデータ活用を進めている事例です。同社は、社会インフラ、工場設備、ソフトウェアまでを手掛ける総合電機メーカーです。前段で触れたフィジカルAIの台頭に対し、Siemensは長年培ってきた制御技術や物理的な動作原理への深いノウハウをAIと掛け合わせれば、他社を凌駕する価値を生み出せると考えました。 そのため同社は物理世界とデジタル世界を融合させる「ONE Tech Company」への変革を掲げ、全社で共通のデータ基盤「3つのFabric」を構築してきました。AIを機能させるにはビッグデータやグローバルなプラットフォームといった「規模」も不可欠になるとの考えに基づき、グローバルで組織の壁を打ち破り、データをリアルタイムでAIモデルに供給できる体制へと会社を作り替えたのです。 この事例で重要なのは、フィジカルAIを単なる先端技術として扱っていない点です。制御技術、物理的な動作原理、デジタルツイン、生成AIアシスタント、エコシステムを組み合わせ、業務と顧客提供価値の両方を再設計しています。 主な取り組みは次の通りです。 3つのFabric: データ基盤、テクノロジー基盤、セールス基盤を全社で一元化 Siemens Xceleratorを通じて、自社やパートナーのソリューションをデジタルマーケットプレイス上で提供 NVIDIAとの協業によるデジタルツイン構築など、エコシステム形成を推進 全従業員を対象にしたSiTecSkills Academyで、デジタルの「雇用適格性」を確保するためのリスキリングを体系的に実施 Microsoftとの協業で、製造現場向け生成AIアシスタント「Siemens Industrial Copilot」を開発 同社は、これらの基盤と世界のトップテック企業との協業を活かし、インフラや製造現場を自律化する高度なユースケースを次々と実装しています。代表的なものは以下の通りです。 Siemens Industrial Copilot（産業用生成AI）: Microsoftとの協業で開発。これまで高度な専門知識が必要だった自動化プログラム（PLCコード）の作成やデバッグを自然言語で瞬時に実行します。自動車部品大手Schaefflerなどの先行導入企業において、コード作成時間が劇的に短縮されたことが実証されています。 Building X （スマートビルの自律運用SaaS）: エネルギー管理や設備保全など分断されていたドメインデータを統合。AIが天候などの変化に適応してリアルタイムで最適化し、ビルのエネルギー消費量の30%削減と、純営業利益（NOI）の10%向上を実現しています。 産業用メタバースとデジタルツイン: NVIDIAとの協業により、現実とほぼ完全に同期する物理ベースのリアルタイムシミュレーションを構築。まずバーチャルのデジタルツインで試し、確信を持った結果のみ現実に反映するという次世代AI工場の実現を主導しています。 製造業におけるフィジカルAIの事例として、Siemensの取り組みは先進モデルと言えます。AIは単に現場作業を自動化するだけでなく、設計、制御、運用、販売、顧客向けサービスを横断して価値を生み出す基盤になりつつあります。 Rockwell Automation: 自律型AIと人材投資で、つながる工場を高度化 世界最大の産業オートメーション（FA）専業メーカーであるRockwell Automationは、ハードウェアの売り切り型ビジネスから脱却し、現場の設備とクラウド（SaaS）をシームレスに繋ぐ「The Connected Enterprise（つながる工場・企業）」戦略を推進しています。 同社は、製造業が直面する人手不足やサプライチェーンの複雑化といった課題を解決するためには、AIによる高度な自律化が不可欠であると考えています。その自律化の最大の障壁となるのが、「IT（情報技術）」と「OT（Operational Technology：運用技術）」の分断です。 OTとは、工場内のロボットやセンサー、生産設備を直接制御・監視するための技術です。従来、経営管理やデータ分析を担うITと、現場を直接動かすOTは別々のシステムとしてサイロ化されていました。 Rockwellは、現場のあらゆるOTデータを単一のアーキテクチャ（Logix）で統合し、それを経営層のITシステム（Plexなど）へリアルタイムに繋ぐという、強固なIT/OT統合データ基盤を構築し、この壁を打ち破っています。 このシームレスな統合基盤の上で、同社は 今後5年間で自社のインフラと人材に総額20億ドルという大規模投資をコミットし、社内では年間約100万時間の学習機会を提供 しています。さらに特筆すべきは、自社の枠を超えた取り組みです。ManpowerGroupと連携し、退役軍人を高度デジタル人材へリスキリングし、人材難に悩む顧客企業へ直接供給するという、業界全体の人材不足という構造的課題を主導して解決する取り組みも進めています。 シンガポールの自社工場では、大規模言語モデル（LLM）やデータの因果関係を理解する因果AI、自律実行するAgentic AIを組み合わせた「Factory AI（AIアシスタント）」を現場に導入しました。工場内で機械の停止や品質の異常など問題が発生した際、このAIアシスタントが即座に介入。リアルタイムの診断データから原因をAIが特定し、現場のオペレーターに対して「今、何をどうやって直すべきか」という復旧プロセスをガイドします。これにより、生産ラインの最適化、廃棄物の最小化、そしてダウンタイムの削減を実現しています。 この事例の最大の成果は、新規オペレーターの育成期間の大幅な短縮です。通常、組み立てラインに新しい従業員を配置して一人前に仕事ができるようになるまでには、約6ヶ月の期間を要していました。しかし、AIアシスタントがトラブル時の対応をリアルタイムで横からガイドし、AR/VRで手順を視覚的に教えることで、 この習熟期間をわずか数週間にまで短縮することに成功しました 。この画期的な取り組みは高く評価され、Dowと同じく、優れたITイノベーションに贈られる「CIO 100アワード」を受賞しています。 実務上の示唆: 統合: PlexとLogix Architectureで、経営・ITレイヤーと現場・OTレイヤーを接続 セキュリティ: SecureOTで、IT/OT統合に伴う産業環境のリスクに対応 現場価値: 予兆保全、品質最適化、AIアシスタントによるオンボーディング短縮に展開 Rockwell Automationの示唆は、AIを分析画面の中で完結させず、IT/OT統合とセキュリティを前提に現場の判断と実行へ近づける点にあります。 データ利活用で成果を出す企業に共通する3つのパターン Dow、Siemens、Rockwell Automationの事例に共通するのは、AIを単発のツール導入で終わらせていないことです。各社は、製造業のデータ活用を企業のオペレーティングモデルそのものの再設計として捉えています。 共通パターンは、次の3つに整理できます。 1. コア業務で成功モデルを作り、顧客価値へ広げる 成果を出す企業は、まず社内のコア業務でAI活用を試し、成功体験を蓄積しています。そのうえで、得られた知見を顧客向けサービスやパートナーとのエコシステムに広げています。 この流れは、製造業のデータ活用において重要です。品質改善、製造条件の最適化、需要予測、保全、製品開発など、社内で価値を確認できるユースケースから始めることで、AI活用の説得力が高まります。 2. 現場とビジネス部門がデータ活用を主導できる人材育成を行う データ活用は、データサイエンティストやIT部門だけでは定着しません。製造業では、現場の工程理解、設備知識、品質管理の経験、顧客やサプライチェーンへの理解が欠かせないためです。 先進企業は、全社展開のリテラシー向上プログラムや役割別の教育を通じて、ビジネス部門が自らデータを使い、AI活用を主導できる体制を整えています。 3. データを再利用できる資産として扱う AI活用の成果は、個別の分析テーマだけでなく、データを継続的に使える状態にできるかに左右されます。 データメッシュの考え方に代表されるように、先進企業はデータを分析のたびに集める素材ではなく、再利用可能なプロダクトとして扱っています。品質、説明可能性、権限、更新性を担保したデータを整えることで、AIモデルや分析業務の再現性が高まります。 日本の製造業では、現場データを活かす仕組みが鍵になる 日本の製造業でデータ活用を進める場合、重要なのは、現場の知見とデータを切り離さないことです。熟練者の経験、設備条件、品質データ、工程間の関係性を、AIが扱える形に変換し、現場の意思決定に戻す仕組みが必要です。 日本の事例として、 JFEスチール株式会社の取り組み があります。ハイテン鋼（高張力鋼）は従来の汎用鋼材と比べ、製造条件の微妙な変化が品質に大きな影響を与えます。大量生産を前提とする製鉄業では早くから統計的手法に基づく技術革新が図られ、同社においても従前よりハイテン鋼のデータ分析に取り組んできました。一方、従来の方法では、各種センサーの増設によるデータ量の飛躍的な増大もあり、ハイテン鋼に対応した緻密な解析は困難になりつつありました。 そこで、サイバー空間上に製造プロセスを再現するCPS（Cyber Physical System: サイバーフィジカルシステム）を展開し、現実世界から収集したデータをdotDataで解析しました。理想の品質を正解データとして入力し、関連するデータから品質に影響する複合的な要因やパターンを抽出し、現場のオペレーションにフィードバックする取り組みです。 dotDataによるデータ解析の結果、従来は気が付かなかった複数の要因による製造プロセスにおける相関関係が発見され、そこからの知見を元にオペレーションを最適化することにより、歩留まり率の向上につながりました。 取り組みの詳細は、 JFEスチールのハイテン鋼における歩留まり改善の導入事例 で紹介しています。 同社では、データサイエンティストによる高度なデータ分析も並行して行っていますが、dotDataを活用した現場エンジニアによるこうしたデータ利活用は、今後、より迅速な意思決定に大きな役割を果たしていくことが期待されています。 この事例が示すポイントは、単にAIモデルを作ることではありません。現場を熟知したエンジニアが解析に関わり、複数工程にまたがる要因を見つけ、意思決定のスピードを高めている点です。 製造業のデータ活用では、以下のような観点が導入判断の軸になります。 どの業務課題を、最初のユースケースにするか 現場部門がデータの意味を説明できる状態になっているか 設備、品質、工程、需要、在庫などのデータが連携できるか 分析結果を、現場のオペレーションに戻す仕組みがあるか AI活用を一部の専門家に閉じず、継続運用できる体制があるか 生成AI、データメッシュ、フィジカルAIは、それぞれ別々の流行語ではありません。製造業がデータ活用を事業成果につなげるために、情報処理、データ基盤、物理世界の制御や最適化をどうつなぐかという一連のテーマなのです。 まとめ: 製造業のデータ活用は、AIを使う業務設計から始まる Dow、Siemens、Rockwell Automationといった欧米先進企業の事例から見えてくる最大の共通点は、AIやデータの利活用を単なるIT部門のテーマや個別ツールの導入として終わらせず、経営課題と捉え、全社の取り組みとして推進しているという大前提です。 AI活用を経営課題とし、企業のオペレーティングモデルそのものを再設計している欧米先進企業の事例から見える共通点は、次の3つです。 コア業務でAI活用の成功モデルを作り、顧客価値やエコシステムへ広げる まずは自社のコア業務やR&DでAIを使い倒して生産性向上の成功モデルを確立し、その成果を顧客向けのサービスや、業界全体を巻き込んだ共創エコシステムへと昇華させています。 現場やビジネス部門がデータを使えるよう、人材育成と役割設計を進める データ活用を専門家だけに閉じず、全社展開のリテラシー向上プログラムや役割別の教育を通じて、現場の業務プロセスや設備を熟知したビジネス部門自らがAI活用を主導できる体制を築いています。 データを再利用可能なプロダクトとして扱い、ガバナンスとスピードを両立する データメッシュのアプローチに代表されるように、データを分析のたびに集める「素材」ではなく、他部署も利用可能な「プロダクト」として扱うことで、全社的なガバナンスを効かせながら現場の分析スピードを最大化しています。 日本の製造業においても、品質改善、製造条件の最適化、予知保全、需要予測、サプライチェーン最適化など、データ活用の余地は多くあります。重要なのは、個別のツール選定の前に、自社の業務課題とデータの使われ方を整理することです。 dotDataは、製造業におけるデータ活用やAI活用の支援を通じて、現場の知見とデータを結びつけ、 業務に使えるインサイト を引き出す取り組みを支援しています。また、データ主導の組織づくりを支える ビジネスアナリティクス人材育成サービス も提供しています。製造業でAI活用を検討する際は、まず自社のどの業務課題から始めるべきか、どのデータを活かせるかを整理することが、次の一歩になります。AI・データ活用のご相談や、貴社の課題に合わせた最適なアプローチについては、ぜひお気軽に お問い合わせ ください。 The post 製造業のデータ活用事例: 欧米先進企業に学ぶAI・データ基盤・人材変革 appeared first on dotData .

決済や送金などを扱うFinTechシステムでは、「一般的なWebシステムと同じテストをすれば十分なのか」と判断に迷う場面があります。 画面や機能が仕様どおり動くことはもちろん重要ですが、金融サービスでは、わずかな処理ミスでも残高不整合や二重決済といった大きな問題につながる可能性があります。 そのため、 取引・データの正確性、API（アプリケーション・プログラミング・インターフェース）による外部連携、性能、セキュリティ、障害時の復旧 まで含めて考えることが欠かせません。 また、テスト項目を大量に増やせば安心できるわけでもありません。 金融システムでは、システム障害やサイバー攻撃が事業や顧客へ与える影響を踏まえ、重要なリスクから優先して確認する考え方が必要です。 テストの完了だけをゴールにせず、障害発生時の復旧や代替手段まで確認し、リリース後もサービスを継続できる状態を作ることが重要になります。 そこで今回は、 FinTechシステムで押さえたいテストの全体像から7つの重要観点、効率化、リリース判断までを実務の流れに沿って整理しました！ 「何を、なぜ、どこまで確認すればよいのか」を整理し、テスト計画の抜け漏れを防ぐための判断材料として活用できます。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 FinTechのシステムテストは何が違う？まず押さえたい基本と重要性 FinTechのシステムテストでは、単に「仕様書に書かれた機能が動いた」という結果だけでは品質を判断できません。 金融サービスではシステムの停止や誤作動、不正利用などによって顧客や事業者が損失を受ける可能性があり、安全かつ安定的に稼働すること自体がサービスへの信頼につながります。 さらに、近年の金融システムはクラウドや外部サービス、APIなどを組み合わせて構築されるケースが増え、障害の原因が自社システム内部だけにあるとは限りません。 接続先の停止や通信遅延、不正なアクセス、データ連携の失敗まで含め、 サービス全体を一つのシステムとして捉える視点 が求められます。 また、品質を高めようとして確認項目を無制限に増やすと、開発期間やコストが膨らみます。 重要なのは、システムが抱えるリスクを整理し、影響の大きな領域へテスト工数を優先的に配分することです。 FinTechのテストでは、 品質、スピード、リスク管理を同時に成立させること が大きなテーマになります。 FinTechでは「動くこと」だけでなく「正しく安全に取引できること」を確認しよう！ 一般的なシステムテストでは、システム全体が要件を満たしているかを確認しますが、FinTechでは特に 取引結果の正確性 が重要です。 送金額や残高、手数料、決済ステータスなどが一つでも誤れば、単なる表示不具合では済まず、実際の資産や会計処理へ影響する可能性があります。 正常に処理できるケースだけでなく、通信が途中で切断された場合、外部APIから応答が返らない場合、同じ要求が複数回届いた場合なども確認する必要があります。 たとえば決済処理の途中でタイムアウトが発生した際、画面では「失敗」と表示されたにもかかわらず、実際には決済だけ完了している状態になれば、再操作によって二重決済が起こる可能性があります。 APIについても認証や認可、不適切なデータアクセス、外部APIの安全でない利用など、機能面とは別のリスクがあります。 FinTechではテストケース数の多さより、 誤取引やサービス停止につながる重要な失敗パターンを想定できているか を重視することが大切です。 単体・結合・システム・受け入れテストの役割を混同しない！ FinTechシステムの品質を効率よく確認するには、それぞれのテスト工程で「何を保証するのか」を明確にしておく必要があります。 単体テストでは、金額計算や入力チェックなど、プログラムや機能単位で想定した結果になるかを確認します。 結合テストでは、画面とAPI、APIとデータベース、決済基盤と自社サービスなど、複数の機能を接続した際に正しく連携できるかを確認します。 システムテストでは、本番に近い構成を用意し、機能だけでなく性能やセキュリティ、障害対応を含めてサービス全体の品質を評価します。 受け入れテストでは、実際の業務や利用シーンを想定し、業務要件を満たした状態でサービスを提供できるかを確認します。 特に金融システムでは、ユーザー部門とシステム部門の認識差や業務要件の漏れが障害原因になることがあるため、設計・開発段階から各工程の検証と承認を明確にすることが重要です。 どの工程で、誰が、何を確認するのか を決めておけば、同じ確認の繰り返しと重要項目の確認漏れを同時に減らせます。 金融システムならではのリスクをテスト計画の出発点にしよう！ FinTechのテスト計画では、機能一覧からテストケースを作り始める前に、サービスで発生すると困る事象を洗い出すことが重要です。 最初に考えたいのは、 誤送金、二重決済、残高不整合、情報漏えい、サービス停止 など、顧客や事業への影響が大きいリスクです。 次に、それらの問題がどの機能やシステム連携で発生し得るのかを整理し、重要度の高い領域へテストを割り当てます。 24時間提供するサービスであれば、「障害を発生させないこと」だけではなく、障害発生後に代替手段へ切り替えられるか、必要な時間内に復旧できるかという観点も欠かせません。 金融分野では、サイバーセキュリティだけでなく、障害や外部環境の変化が起きても重要な業務を維持・復旧できる ITレジリエンス も重視されています。 外部API、クラウド、決済事業者、認証サービスなどへの依存関係も可視化し、自社以外の障害を含めたシナリオを用意すると、より実運用に近いテスト計画になります。 抜け漏れを防ぐ！FinTechシステムで優先したい7つのテスト観点 FinTechシステムには多くの確認項目がありますが、すべてをばらばらに考えるとテストケースが膨大になり、優先順位を付けにくくなります。 そこで、 ①機能・取引、②API・外部連携、③データ整合性・同時実行、④性能・負荷、⑤セキュリティ、⑥障害・復旧、⑦規制・監査・証跡 の7つに分けて整理すると、全体像を把握しやすくなります。 重要なのは、7種類を同じ密度で実施することではありません。 決済サービスであれば取引処理や外部連携、個人情報を多く扱うサービスであれば認証・権限やデータ保護など、事業特性によって優先順位を変えます。 また、システムの重要度やリスクに応じた安全対策を考えることは、金融情報システム全体の安全性を確保するうえでも重要な考え方です。 以下の7つをチェックリストとして機械的に消化するのではなく、 重大事故を防ぐための確認軸 として活用することがポイントです。 ①機能・取引テスト｜「正しく処理されたか」を金額とステータスまで確認！ 機能・取引テストでは、入金、出金、送金、決済、返金、取消など、サービスの中核となる取引が仕様どおり処理されるかを確認します。 特にFinTechでは、画面上で「成功」と表示されることだけでなく、 金額、残高、手数料、取引ステータス、後続処理まで一貫して正しいか を見ることが重要です。 正常系だけでなく、残高不足、上限超過、不正な入力、処理途中の通信断なども確認対象になります。 同じ決済要求が何らかの理由で再送された際に、二重で処理されないことも重要な確認ポイントです。 処理途中で障害が起きた場合は、取引を取り消すのか、途中から再開するのか、最初からやり直すのかを仕様として明確にし、その結果がデータベースや外部サービスにも正しく反映されるか確認します。 金融システムでは誤作動そのものが顧客や事業者の損失につながり得るため、 画面表示ではなく取引全体の最終状態を確認する ことが基本となります。 ②API・外部連携テスト｜接続先が変わっても止まらない仕組みを確認！ FinTechサービスでは、決済、本人確認、認証、銀行口座連携などを外部サービスのAPIと組み合わせて提供することがあります。 そのためAPI・外部連携テストでは、正常なデータ交換だけでなく、 接続先で異常が起きた場合の振る舞い まで確認することが重要です。 タイムアウト、通信切断、エラー応答、想定外のデータ、レスポンス遅延などを発生させ、待機や再試行、エラー処理が設計どおり機能するかを確認します。 再試行の結果として同じ取引が重複しないことや、アクセス権限のないデータをAPI経由で取得・更新できないことも確認が必要です。 APIではオブジェクト単位の認可不備、認証の問題、リソース消費の制御不足、外部APIを安全性の確認なしに利用する問題など、さまざまなセキュリティリスクも想定されています。 外部サービスを自由に停止させられない場合はモックやサービス仮想化を使い、異常応答を再現して、 接続先に問題が起きても自社サービスが安全に振る舞えるか を確認します。 ③データ整合性・同時実行テスト｜残高や取引履歴のズレを防ぐ！ FinTechでは、一つの取引情報が画面、API、データベース、会計システム、外部決済基盤など複数の場所へ反映されることがあります。 このとき一部の処理だけが成功すると、利用者が確認する残高と実際の取引記録が異なるなど、深刻な不整合につながります。 データ整合性テストでは、 一つの取引が関係するすべてのシステムで同じ状態になっているか を確認します。 また、複数の利用者や処理が同時に同じ口座やデータへアクセスする状況も重要です。 同時更新によって残高計算がずれる、更新内容が上書きされる、処理が互いに待ち続けるといった問題が起きないかを確認します。 日次や月次のバッチ処理、締め処理とオンライン取引が重なる時間帯など、実際の運用で発生する組み合わせもテスト対象に含めます。 少量のテストデータでは発生しない問題もあるため、本番に近い件数や処理パターンを使い、 取引量が増えても正しいデータ状態を維持できるか を見ることが重要です。 ④性能・負荷テスト｜アクセス集中時でも取引を止めない！ 性能・負荷テストでは、通常時に画面が速く表示されるかだけでなく、アクセスや取引が集中した際にも要求するサービス水準を維持できるか確認します。 FinTechでは給与日、キャンペーン、相場の急変、サービス開始直後など、短時間に利用が集中する場面を想定する必要があります。 実際に近い同時アクセス数や取引件数を発生させ、 応答時間、処理件数、エラー率、システム資源の使用状況 などを確認します。 負荷が上がった際には、Webサーバーだけではなく、API、データベース、外部サービスなど、どこがボトルネックになるかを切り分けることも重要です。 さらに、処理能力の限界を超えたときにシステム全体が一斉に停止するのか、アクセス制御や一部機能の制限によって重要サービスを継続できるのかも確認します。 金融サービスでは安全かつ安定的な稼働が重要であり、障害時の迅速な復旧もシステムリスク管理の重要な要素です。 平均的な性能だけでなく、最も厳しい利用状況でも重要取引を維持できるか まで確認することが大切です。 ⑤セキュリティテスト｜顧客の資産と情報を守れるか確認！ FinTechシステムでは個人情報や口座情報、取引情報などを扱うため、セキュリティテストを機能テストとは別の重要領域として考える必要があります。 まず、ログインや本人確認、多要素認証、権限管理が設計どおり働き、権限を持たない利用者が他人の情報や管理機能へアクセスできないことを確認します。 APIでも認証やオブジェクト単位のアクセス制御不備は重要なリスクとなるため、IDなどの値を書き換えるだけで他者の情報を参照できないかといった確認が必要です。 さらに、脆弱性診断や必要に応じた侵入テストを実施し、外部から悪用できる弱点が残っていないかを確認します。 通信時や保存時のデータ保護に加え、アプリケーションログへパスワードや認証情報、不要な個人情報が出力されていないかも確認したいポイントです。 金融分野ではサイバー攻撃への対応力と復旧力の強化が継続的な課題となっています。 そのため、 リリース前の一度だけ確認するのではなく、変更や脅威の変化に合わせて継続的に検証する仕組み まで考えることが重要です。 ⑥障害・復旧テスト｜「壊れない」だけでなく「壊れても戻せる」を確認！ どれだけ対策しても、システム障害を完全になくすことは困難です。 そのためFinTechでは、障害を防ぐテストに加え、 障害が起きても重要な取引を守り、サービスを復旧できるか を確認します。 サーバー、ネットワーク、データベース、クラウドサービスなどに障害が発生した状況を作り、冗長化された環境へ正しく切り替わるかを検証します。 切り替えそのものが成功しても、処理途中だった取引が消えたり二重になったりしては問題があるため、復旧後のデータ整合性まで確認することが必要です。 バックアップについても「取得できている」だけではなく、実際に戻せるか、必要な時間内にサービスを再開できるかをテストします。 障害時の代替手段やコンティンジェンシープラン（緊急時対応計画）は、文書を用意するだけでなく、実際に訓練し、結果を踏まえて改善することが重要です。 障害を起こさない設計と、起きたときに戻せる設計をセットで検証する ことで、サービス全体のレジリエンスを高められます。 ⑦規制・監査・証跡テスト｜「なぜリリースできるのか」を説明できる状態に！ FinTechでは、システムが正常に動くことに加えて、適用される法令や監督上の要求、社内ルール、契約上の条件を満たしているかも確認する必要があります。 ただし、すべてのFinTechサービスへ同じ規制が適用されるわけではないため、提供するサービスや事業形態に応じて確認対象を整理することが大切です。 金融情報システムの安全対策を考える際には、FISC（金融情報システムセンター）の安全対策基準なども、開発・導入・運用における安全対策を整理する材料となります。 テストでは、監査ログが適切に記録され、 誰が、いつ、どの情報や取引へ、どのような操作を行ったか を追跡できるか確認します。 さらに、テスト結果だけでなく、発見した不具合、修正内容、再テスト結果、残っているリスクまで記録しておくことが重要です。 金融システムの移行判断では、必要なテストやリハーサルなどを終え、判断に必要な材料を揃えておく考え方が重視されています。 「テストを実施した」という記録ではなく、「主要なリスクを確認し、この根拠でリリースできる」と説明できる証跡 を残すことがポイントです。 品質とスピードを両立！失敗しにくいテスト計画と効率化の進め方 FinTechのシステムテストでは、安全性を重視するあまりテスト項目を増やし続けると、開発期間やコストが膨らみます。 反対に、納期を優先して必要な検証を省けば、本番障害や手戻りによって結果的に大きな負担が発生する可能性があります。 金融システムの開発では、納期を優先するあまり各工程の完了基準を満たさないまま次工程へ進まないことも重要な管理ポイントです。 そこで必要になるのが、 テストの量を増やすのではなく、リスクに応じて実施内容を最適化する考え方 です。 重大な影響につながる機能へ工数を集中させ、繰り返し確認する部分は自動化し、外部環境の待ち時間はモックなどで減らします。 さらに、「全ケースを消化したら終了」という管理から、品質基準と残存リスクを確認してリリース可否を判断する管理へ切り替えることも重要です。 これらを組み合わせることで、品質を犠牲にせず、限られた期間と人員の中でテストを進めやすくなります。 まずはリスクの高い機能から！優先順位を決めてテスト計画を作ろう テスト計画を作る際は、すべての機能を同じ深さで確認するのではなく、障害が発生した場合の影響と発生可能性を考えて優先順位を付けます。 たとえば金銭処理、本人認証、権限管理、個人情報、主要な外部連携、停止すると業務継続が難しくなる機能などは優先度が高くなりやすい領域です。 まず「 この機能が壊れた場合、顧客や事業に何が起こるか 」を整理し、その結果から必要なテストの種類と深さを決めます。 性能であれば許容する応答時間や処理件数、復旧であれば許容できる停止時間など、非機能要件についてもテスト前に合格条件を明確にしておきます。 要件とテストケースを対応付ければ、どの要件が確認済みで、どの部分が未確認なのかも把握しやすくなります。 また、ユーザー部門とシステム部門の認識差や要件漏れを後工程まで持ち越さないため、設計・開発の早い段階から品質確認を行うことが重要です。 リスクを先に決め、必要なテストを後から割り当てる 順番にすると、限られた工数を重要な確認へ使いやすくなります。 テスト自動化は「繰り返すもの」から始めよう！ テスト自動化では、「自動化率を高くすること」を目標にすると、作成や保守にかかる工数が増え、期待した効果が得られない場合があります。 まず候補にしたいのは、 何度も同じ条件で実行し、結果を機械的に判定できるテスト です。 たとえばAPIの基本的な正常系・異常系、回帰テスト、定型的なデータ検証などは、自動化によって繰り返し確認しやすくなります。 一方、仕様や画面変更が頻繁な部分、操作感や表示内容を人が判断する必要がある部分などは、手動テストのほうが効率的な場合があります。 CI/CD（継続的インテグレーション／継続的デリバリー）と自動テストを連携すれば、プログラム変更のたびに重要な確認を実行し、不具合を早い段階で発見しやすくなります。 セキュリティ領域でも、APIの代表的なリスクを対象とした自動テストの仕組みが整備されており、継続的な検証という考え方と相性があります。 ただし、 自動化はテスト設計の代わりではありません 。 重要なリスクが変化していないかを定期的に見直し、自動テストそのものも更新することが必要です。 外部環境の待ち時間を減らし、テストを前倒ししよう！ 複数企業やシステムが関わるFinTech開発では、「接続先がまだ完成していないためテストできない」という状況が起こりやすくなります。 外部APIの完成を待ってからテストを始めると、不具合の発見がプロジェクト終盤へ集中し、修正や再テストの時間を確保しにくくなります。 そこで活用できるのが、実際の接続先の代わりとなるモックやサービス仮想化です。 正常なレスポンスだけでなく、 タイムアウト、エラー、異常データ、応答遅延 などを意図的に返す環境を用意すれば、実サービスでは再現しづらい条件も早期に検証できます。 これにより、開発とテストを並行して進めやすくなり、外部環境が完成してから初めて連携不具合が見つかるリスクを減らせます。 ただし、仮想環境ですべての問題を再現できるわけではありません。 金融システムでは実際の接続条件を踏まえた接続テストも重要であり、過去の障害を踏まえて十分な接続テストを計画する考え方が示されています。 開発中は仮想環境で前倒しし、最終段階では本番に近い実環境で確認する という使い分けが効果的です。 「テスト完了」ではなく「リリースしてよい条件」を決めよう！ テストケースを100％実施しても、重大な不具合が残っていれば安全にリリースできるとは限りません。 一方で、軽微な表示上の問題が一件残っているだけで、必ずしもサービス全体を延期する必要があるとは限りません。 そのためリリース判断では、 テスト消化率ではなく、重要要件の達成状況、未解決不具合、性能・セキュリティの評価、残存リスク を組み合わせて確認します。 重大度ごとに未解決不具合をどこまで許容するか、性能や復旧能力をどの水準まで求めるかなどを事前に決めておくと、プロジェクト終盤で判断がぶれにくくなります。 未解決リスクを受容する場合は、内容と影響、代替策、判断者を記録し、後から経緯を確認できる状態にします。 金融システムの移行では、必要なテストやリハーサルなどを移行判定までに終え、安全性・安定性を踏まえた基準に沿って判断する考え方が重視されています。 つまり重要なのは、「予定していたテストが終わったか」ではなく、「 主要リスクが許容できる状態になり、その根拠を説明できるか 」です。 まとめ｜FinTechのシステムテストは「重要リスクから逆算」が成功のカギ！ FinTechのシステムテストでは、機能が仕様どおり動くことだけでなく、取引の正確性、API連携、データ整合性、性能、セキュリティ、障害復旧、規制・監査まで幅広く確認する必要があります。 特に金融サービスでは、システムの停止や誤作動、不正利用などが顧客や事業へ大きな影響を与えるため、安全かつ安定的な稼働を前提としてテストを設計することが重要です。 ただし、すべての機能を同じ密度でテストすると、工数や期間が膨らみます。 そこで、 重大障害につながるリスクから逆算して優先順位を決めること が、品質と効率を両立するポイントになります。 繰り返す確認は自動化し、外部環境を待つ工程はモックなどで前倒しすることで、重要な判断や探索的なテストへ時間を使いやすくなります。 また、障害対応や復旧計画は資料として整えるだけでなく、実際の訓練やリハーサルによって実効性まで確かめることが欠かせません。 最終的なゴールは「すべてのテストケースを消化した状態」ではなく、 主要なリスクを把握し、許容できる水準まで抑え、その根拠を関係者へ説明できる状態 です。 まずは開発中のサービスで障害が起きた場合に最も大きな損失につながる機能を洗い出し、7つの観点から現在のテスト計画に抜け漏れがないか確認するところから始めてみましょう。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

こんにちは。メルペイの Balance Team で Tech Lead をしている @kobaryo です。この記事は「 Merpay & Mercoin Tech Openness Month 2026 」の18日目の記事です。 はじめに Balance Team では お客さまの残高やポイントを扱うマイクロサービスをはじめ、債権を取り扱う Debt Service も管理しています。先日公開された @imamu さんの「 事業者請求払いのための与信管理マイクロサービスの設計 」で、与信を扱う Credit Service を中心に事業者請求払いの設計が紹介されましたが、本記事ではその中で取り上げられた「債権を任意の軸で集計する仕組み」を Debt Service 上でどのように表現したのかについて紹介します。 事業者請求払いでは、与信管理のために「与信枠ごとの未返済債権」を高速に取り出したい、また請求のために「請求先ごとの債権の一覧」を把握したい、という2つのニーズが生まれます。お客さまや事業者ごとの残債を管理する既存のテーブル DebtAccount はお客さまや事業者を表す ID という単一の軸に縛られており、この2つの独立した軸を同時に管理できませんでした。この壁を越えるために、「DebtAccount は債権の操作ログ DebtLog を集計したビューである」という発想から DebtAccountView を設計しました。1つの DebtLog を異なる軸で集計された複数のビューに畳み込むことで、与信枠軸と請求先軸を独立して管理でき、将来の新しい集計軸も最小限の変更で追加できます。 Debt Service が管理する「債権」とはなにか 事業者請求払いでは、我々が取引のたびに代金を立て替え、後からまとめて事業者に請求します。この立替金の記録が 債権（Debt） です。Debt Service はメルペイの中で債権を一元管理するマイクロサービスで、事業者向けのみでなくお客さま向けのメルペイのクレジットなど、複数のサービスから呼ばれる下位レイヤーとして機能します。 各 Debt は「誰の（CustomerId）」「何の種別の（DebtType）」「いくらの（Amount）」立て替えかを保持します。DebtType は決済の種別や精算方法を区別するための分類で、お客さま向けの月次清算を表すものや事業者向けの請求書払いを表すものなど複数の種別が存在します。 個別の Debt が増えていくと、「ある事業者の現時点での残債はいくらか」を素早く知りたい場面が増えます。Debt を1件ずつスキャンして合算するアプローチは、Debt の件数に比例して計算コストが大きくなるため、取引のたびに現在の残債が与信上限を超えないかをリアルタイムで確認するには向きません。そのために DebtAccount というテーブルでお客さまや事業者ごと、かつ種別ごとに残債を保持しています。Debt の作成や返済が発生するたびに DebtLog （債権の操作ログ）が記録され、それに応じて DebtAccount の Amount が更新される仕組みです。 「1口座1軸」という壁 DebtAccount の設計はシンプルです。Unique key (CustomerId, DebtType) によって、「この事業者の、この種別の残債はいくらか」という問いに即座に答えられます。お客さま向けのメルペイのクレジットなど既存のユースケースではこれで十分対応できました。 請求書払いプロジェクトでは、この設計に2つの新しい要件が加わりました。1つは与信管理の要件です。詳細な説明は上述の @imamu さんの記事 に委ねるのですが、今回店舗や部門ごとなど1事業者が複数の与信枠を持てる設計を目指しています。そのため、与信枠を扱う Credit Service は決済フローの中で「ある与信枠に紐づく残債」をリアルタイムに取得できなければなりません。もう1つは請求の要件です。Invoice Service は請求先の軸でまとめた債権から請求書を発行するため、「ある請求先に紐づく債権の一覧」を取得できなければなりません。与信の軸（与信枠）と請求の軸（請求先）は完全に独立しており、1つの債権が両方に同時に紐づきます。またこれらの軸はどちらも CustomerId すなわち既存の事業者IDと独立しているため、既存の DebtAccount を用いて集計することはできません。 2つの要件はそれぞれ性質が異なります。与信計算は決済フローの中でリアルタイムで行われ、応答時間が Debt の件数に依存してはならないため、与信枠の軸でも既存の DebtAccount と同じ「1行参照で残債がわかる」事前集計が必要です。請求の要件は残債の集計ではなく、明細の作成や債権の返済のためにどの債権がどの請求先に属するかという紐づけを保持しておくことです。ただし後々事業者向けに請求額を確認できるダッシュボードを提供したいなど、請求先軸でも事前集計する必要が出てくるかもしれません。またこれらに追加して3軸目がこの先登場しないとも限りません。このように考えた場合、我々に必要なものは多軸で残債を集計でき、かつその軸と債権を紐付けておく汎用的な仕組みでした。 1つの操作を複数の軸で同時に集計する DebtAccountView この仕組みを実現するヒントは、DebtAccount の性質そのものにありました。DebtAccount は「口座」という名前のとおり実体を持つ台帳のように見えます。しかし、すべての事実は DebtLog に記録されており、DebtAccount はその DebtLog を (CustomerId, DebtType) 軸で集計し、現時点の残債を1行に集約したビューです。この捉え方に立つと、「同じ DebtLog を別の軸で畳み込んだビューが複数あってもよい」という発想が生まれます。これが DebtAccountView の設計の直感的な出発点です。 口座を分割するのではなく、集計の軸を並列に増やすというのが、設計の方向です。DebtLog は従来 DebtAccount という1つの集計ビューだけを更新していました。ここで、1つの DebtLog が既存の DebtAccount に加えて任意の数のビューを同時に更新できるようにしました。 各 DebtAccountView は既存の DebtAccount と同じ物理構造を持つ集計テーブルです。DebtAccount の設計思想をそのまま踏襲しているため、DebtAccountView 専用の新しい運用パターンを考える必要はありません。従来「1 DebtLog が1 DebtAccount を更新する」ところを「1 DebtLog が1 DebtAccount + N 個の DebtAccountView を更新する」に拡張した形です。 3つのテーブルが作る台帳の構造 この仕組みを支えるのが3つのテーブルです。 DebtAccountViews （集計した残債）、 DebtAccountViewItems （Debt と DebtAccountView の所属関係）、 DebtAccountViewLogs （Debt Account View の変動履歴）がそれぞれの役割を担います。この機能に関わる主要な3テーブルのスキーマを示します。 -- 集計した現在の残債 CREATE TABLE DebtAccountViews ( DebtAccountViewId STRING(100) NOT NULL, ViewKeyType INT64 NOT NULL, -- 1=請求先 ID, 2=与信付与先 ID, ... ViewKeyId STRING(MAX) NOT NULL, -- 指定した ViewKeyType の中の ID CustomerId INT64 NOT NULL, DebtType INT64 NOT NULL, Amount INT64 NOT NULL, ) PRIMARY KEY(DebtAccountViewId); CREATE UNIQUE INDEX DebtAccountViewsByViewKey ON DebtAccountViews(ViewKeyType, ViewKeyId, DebtType, CustomerId); -- どの Debt がどの DebtAccountView に属するか（請求書作成時に使用） CREATE TABLE DebtAccountViewItems ( DebtAccountViewId STRING(100) NOT NULL, DebtId STRING(100) NOT NULL, ) PRIMARY KEY(DebtAccountViewId, DebtId); -- 残高変動の履歴 CREATE TABLE DebtAccountViewLogs ( DebtAccountViewLogId STRING(100) NOT NULL, DebtAccountViewId STRING(100) NOT NULL, DebtAccountLogId STRING(100) NOT NULL, -- DebtLog に対応する DebtAccountLog（DebtAccount の変動ログ）を DebtAccountView に紐付けることで、間接的に DebtLog と紐付けている ) PRIMARY KEY(DebtAccountViewLogId); 上流マイクロサービスは、債権を作成する際に ViewKeyType （集計の軸）と ViewKeyId （ある集計軸における集計ID）を指定すれば、あとはその債権が返済・取消など操作されるたびに自動的に DebtAccountView が更新されます。また軸の種類を増やす際は単に ViewKeyType の種類を増やすだけで十分です。 今後の展望 現状の実装では、一度の債権の操作で更新する DebtAccountView が多くなる、すなわち集計軸が増えていくと、債権操作のレイテンシが上昇してしまいます。そこで考えられる拡張が ViewKeyType ごとに更新の同期・非同期を切り替えられる設計です。初期実装では全 ViewKeyType をデータ書き込みと同じトランザクションで同期的に更新していますが、将来同期的に反映しなければならない与信枠などの軸は同期的に、債権の変動と集計する間にタイムラグがある請求先の軸は非同期で反映するという拡張を予定しています。 また今回事業者請求払いのために DebtAccountView を設計しましたが、toB toC 問わず与信を分割したり与信を付ける先と請求する先が異なる任意のビジネスに適用できます。また、設計の本質は変動ログをピックアップし集計する汎用的なものであるため、債権に限らず残高やポイントを管理する Balance Service に導入して利用することも考えられます。 おわりに DebtAccountView は、「1つの債権に複数の集計軸を持たせたい」という要件から生まれた機能です。既存の DebtAccount 設計をベースに、「1 DebtLog → N View を更新する」という拡張を汎用的かつシンプルに実現することにこだわりました。また将来のユースケースや拡張も考え抜けたことは、実装を通じて得た達成感の一つです。 事業者請求払いはメルペイの Payment Platform としてまだ進化の途中にあります。与信管理、債権管理、請求、精算という一気通貫のプラットフォームを、各サービスの責務を保ちながら積み上げていくことは、技術的にもドメイン的にも自信を持って面白いと言えます。もしこうした課題に興味を持っていただけたら、ぜひ Balance Team やメルペイの採用・インターン情報も覗いてみてください。この記事が、Fintech や決済基盤のドメイン設計に興味を持つエンジニアにとって何らかのヒントになれば幸いです。 次の記事は yogawaさん と haoyuさん です。引き続きお楽しみください。 Appendix: 採用しなかったその他の選択肢 既存の事業者IDのみでなく与信枠軸や請求先軸など任意の単位での集計を実現する手段として、DebtAccountView 以外にもいくつかの案を検討しました。 1つ目は与信枠ごとに DebtAccount を分割し、請求先の情報は Debt に持たせる方法です。現状のスキーマの延長線上で実装することができとてもシンプルですが、請求先情報という Debt ドメインに関わりが深くない情報を列に直接追加するのはあまりに汎用的でありません。 2つ目は DebtAccount を親子関係で分割する案です。事業者全体の DebtAccount を親として、その子は与信枠の軸で分割、さらにその子は請求先の軸で分割するといったものです。DebtAccount を分割するための軸という概念を追加しそこに与信枠軸や請求先軸を入れるので、1つ目の案よりは汎用的です。しかし与信枠の軸と請求先の軸は互いに独立しているので、与信枠の軸での集計は効率よく行えるものの、請求先の軸での集計は依然効率よく行えません。加えて、与信枠軸や請求先軸のみでなく効率良く集計する必要のある3軸目が登場した場合に、1つ目の案とこの2つ目の案は対応することができません。 3つ目は Debt Service 内でなく、上流サービス側で集計を持つ方法です。Credit Service が与信枠ごとの残債を管理し、Invoice Service が請求先ごとの集計を管理する設計です。しかし Debt Service を使うサービスが増えるたびに、同じ集計ロジックを各サービスが個別に実装することになります。Debt Service 内で集計済みの情報を管理すれば、債権の元データを唯一の情報源として、各サービスへの変更通知なしに信頼性の高い集計を一元的に提供できます。この仕組みを Debt Service に置くことは、将来債権を取り扱う新しいビジネスが高パフォーマンスな集計を必要としたとき、プラットフォームとして即座に応えられる基盤への投資でもあります。