年間20兆円の決済システムを支えるGMOペイメントゲートウェイが内製開発で蓄積したクラウド活用の極意 【AWS Summit Japan 2025】

自己紹介/会社紹介

皆さまこんにちは。会場も広いので、ここにたどり着くまで大変だったんじゃないかと思いますが、ここに来てくださった皆さま、ありがとうございます。改めまして、GMOペイメントゲートウェイ（GMO-PG）でCTOをやっています三谷と申します。よろしくお願いします。
私からはこの約9年間、AWSのクラウドと向き合ってきた中での、いろいろな活動からのTipsみたいなものをお話ししたいと思っています。まず自己紹介からです。

前職は外資系のITベンダーで、スタートアップや中小企業を担当するアカウントSEのような仕事をしていて、その後メガバンクを担当するアーキテクトになり、長いこと金融系システムのインテグレーションをやっていました。その後シンガポールに赴任して4年くらい、グローバルのプロジェクトに従事しました。気がつくと人様のシステム作りばかりをずっとやっていたので、自分でシステムを作ってビジネスの場で戦っていきたいなと思い、9年前にGMO-PGにジョインしています。

2年前からは日本CTO協会という、「テクノロジー面で日本を良くしていこう」というスローガンの非営利団体で、理事も兼職しております。

だいぶ外れますが、最近は釣りにはまっていまして、東京湾や相模湾で食べたい魚を釣って、さばいて食べる、みたいなことをしています。こればっかりだと話が脱線するので戻します。

GMOペイメントゲートウェイとは

GMOペイメントゲートウェイという会社は、キャッシュレスやFinTech領域の企業で、現状、我々のシステム上を年間20兆円くらいのお金が流れる、そんなミッションクリティカルな決済システムを担っています。営業利益推移では、年平均25%成長を目標に増収増益を続けている会社です。

これをどう実現しているかというと、「内製化にこだわった決済のプロ集団」です。エンジニアは今250人くらいで、内製でスピードと品質を両立しながら開発をしています。オンプレとクラウドのハイブリッド構成で、クラウドは主にAWSを利用しています。25%成長を支えるにはサービスをどんどん増やして作っていかないといけないので、エンジニア採用・育成にも力を入れています。明日から20人くらい採用したいぐらいなので、ご興味ある方はぜひ。

クラウド活用の変遷（9年間の歩み）

この9年間、どんな歩みをしてきたか。目的は、開発や構築のスピード向上。以前はオンプレだったので、調達のリードタイムが非常にかかっていました。もう1つはエンジニアのモチベーション向上。9年前になりますが、「AWSを触ってみたい」という声が強くなってきて、「この会社ではAWSはやらないんですか？」と言われたのが最終的なきっかけです。「やらないのはまずいよな」ということで始めました。

やるからには「管理負荷を軽減したい」。
オンプレのものをそのまま持っていくのは基本禁止。EC2のような「OS・ミドルのパッチ適用を自分でやる」前提の構成に単純移行するのは避け、マネージドサービスを使う。コスト面でも、クラウドの特性（オートスケーリング等）を活かさないとメリットが出ないので、その前提でデザインする。

正直、一番の目的はエンジニアのモチベーション、つまり「触ってみたい」を実現することでした。

進め方は、最初から段取りを固めたというより、1年半〜2年ごとに次のステップに移っていった感じです。初めはすぐ使えるAmazon WorkSpacesやSageMakerから利用を開始。その後、開発・テスト・PoCに使い、この段階でDirect Connectで専用線を引き始めました。本番環境でも使うようになり、決済で扱うカード番号などの個人情報の塊を扱うため、PCI DSSやPCI 3DSといった認証を取得しながら本番に持っていきました。仕組みができると基幹系も行こう、ということでDirect Connectを増強・冗長化。

直近は、サービスが増えると品質の統一やコスト最適化が課題になるので、「クラウド警察」のように日々取り締まる体制を強化しています。放っておくとみんな湯水のように使うので（笑）

AWS利用の変遷

この右肩上がりのグラフはAWSの月額利用額です。初期は小さかったものの、周辺や本番、基幹と広げるにつれて急激に増加し、「これは管理しなきゃな」という現状です。AWS上で50を超えるシステムが動いており、主なものを紹介します。

まず「GMO Cashless Platform」。いわゆるQR決済など「◯◯Pay」を束ね、ワンストップAPIで提供するサービスです。店頭で多様な決済手段を我々のゲートウェイで各決済事業者につなぐ仕組みで、レイテンシ（数百ミリ秒単位）が問われます。AWSで構築したことで、他事業者様との接続もPrivateLinkで直結できます。

本番利用の初期例としては、「3DS 2.0ゲートウェイ」。ブランドルールで3DS 2.0必須化があり、それを司るゲートウェイです。PCI DSSや3DSの準拠を取っています。その後ろに「fincode byGMO」。これはスタートアップ向けの決済サービス（後ほど紹介）。さらに「GMO後払い」。これはハイブリッドクラウドを進化させ、ECS Anywhereを使った構成（後述）。「新与信システム」は、与信エンジンのコード化を図ったもので、NoSQL等を活用しています（これも後で構成図をお見せします）。

初期に大事にしていたのは「内製化を基礎に」。早い段階で、名前は違ったもののCCoE（Cloud Center of Excellence）的な組織を作り、リフト＆シフトは禁止にしました。オンプレをそのまま持っていくと高くつくので、リアーキテクティング（再設計）しないと持っていってはいけない、というルールです。

エンジニアの学習意欲が高かったので、AWSのトレーニングバウチャーをキャンペーン枠で大量に購入し、やりたい人にどんどんトレーニングを提供。すると、これまでインフラチームが主に作っていたものを、アプリ開発チーム側が「AWSなら自分でやるよ」という形に移ってきた。バウチャーで学んだ結果、「自分たちでもやれるじゃん」とフルスタック志向が広がった時期です。

3DSなどを使い始め、AWS費用も上がってきたので、想定していたしきい値に達した段階でEnterprise Supportに加入。右肩上がりに対して取り締まりを強化、という今の段階です。

基幹系への活用事例

予実管理（クラウド警察）

クラウド警察の話を少し。実際に「予実管理」をしています。新サービスはアプリ＋インフラを含めて稟議で決裁を取り、「5年間でいくら」という予算を確保。同時にAWSアカウントを作って、予実管理にその予算を入れます。利用が増えてきたら、実績コストを反映し、実績（青）と累計（オレンジ）で「このまま行くとあと何ヶ月で超えそう」とアラートを上げる。さらにAWSのAnomaly Detectionで、スケールしっぱなし・止め忘れ、パフォーマンステストの上げっぱなし、前月比の異常増加、特定サービスの急増などを検知して、各プロジェクトに確認する。超えそうなら追加決裁を取り、予実に反映、というサイクルです。

これはまだ構想段階ですが、将来的にはプロジェクトごとに見えるダッシュボードを作りたいですが、まだできていません。

fincode byGMO

基幹系への適用事例をいくつか。

まず「fincode byGMO」。開発者体験（DX）にこだわった新しい決済代行サービス。いろんな決済手段をワンストップでAPI提供します。構成は我々のベーシックな設計で、データベースはAmazon Aurora、アプリケーションはAmazon ECS Fargate、フロントのトラフィック制御にAmazon API Gateway。API Gatewayでの制御で、後段のAuroraに負荷をかけないため、手前でAmazon DynamoDBを使って流量のカウントアップ/ダウン、加盟店ごとの窓口数、決済手段ごとのスループット制御などを実装。特定の大量トラフィックやスローダウン時の影響範囲を限定する仕組みです。

新与信システム

2つ目は「新与信システム」。ルールベースと機械学習ベースのエンジンを併用しています。与信対象は、オンプレで動く「GMO後払い」と、AWSクラウドで動くBNPL事業「アトカラ」でこの2つからの与信をつかさどっています。

データストアは主に3種類（RDB（SQL）、NoSQL、KVS）を使い分け、「このルールはこっち」という形で最適化しています。それぞれレスポンス要件が厳しいので、数ミリ秒で数千の与信ルールを捌く必要があるため、どこが最適なのかでデータストアを分けています。加えてSageMakerの機械学習モデルも適用。さらに4つ目のデータストアとしてベクターデータベースの試行も進めています。こうご期待という形です。

後払い

3つ目は「後払い」の仕組みで、オンプレに既存のDBやVMベースの基盤が動いているところに、追加のアプリケーションをコンテナで載せたいケースです。最初はKubernetesやOpenShiftをオンプレに立てることも考えましたが、更新ペースの速さ、オールインワンではなく構成要素が多く依存関係が複雑で何かがアップデートされると他が動かなくなるということで断念。また、コントロールプレーンのバージョン管理ですが、決済に関わるサービスのため、24/365で止められず、サービスごとに止めやすさが異なり複数コントロールプレーン運用が現実的でないことなどから断念。

代わりに、使い慣れたECRとECSをベースに、ホストOSのコンテナ基盤だけをオンプレに置くECS Anywhereを採用しました。右側のAWSクラウド（コントロールプレーン＋ECRリポジトリ）とDirect Connectで接続し、オンプレ側の自分たちで立てたLinuxホスト上にECSエージェントを入れて、自社のプロキシやアプリのコンテナを載せる構成。OpenShift案と2択でしたが、比較すると、当社試算でコストを約78%削減できる見込みだったため、OpenShiftは諦めました。

非機能要件への対応例

我々は金融・決済を扱うため、非機能要件が非常に厳しい分野にあります。ここでは、その中でも2つの対応例についてご紹介します。

セキュリティ対策

1つ目はセキュリティ対策です。コンテナ化を進めるにあたり、NISTのフレームワークでは「この程度の対策は必須である」と定められています。それに対して当社では、まずマネージドサービスを活用し、責務の範囲を明確化することで運用負荷を軽減しました。次に、コンテナイメージ自体に入り込む脆弱性への対応として、スキャン体制を強化しました。さらにランタイム環境にも防御策を講じる必要があり、加えて横断的なモニタリング体制を整備しています。大きく分けて、これら4点を重点的に実施しています。以下で順に説明します。

コンテナセキュリティ

この図は、左側がステージング環境（テストして、結果を右側のプロダクションに持っていく流れ）です。ステージング上では、プルリク→ビルド→デプロイ→テストの中に、ウイルススキャンや脆弱性スキャンを組み込みました。

右側のプロダクションには、リポジトリtoリポジトリでコピーする際にもスキャンを走らせる仕組みにしています。さらにランタイム対応として、実際に動くコンテナからのアウトバウンド通信に出口対策を入れています。アウトバウンドプロキシを用意して、FQDNフィルタリングをする仕組みです。

整理すると、まずAmazon ECSを使ってマネージドサービスでクリアした部分と、コンテナイメージのスキャンは脆弱性スキャンとマルウェアスキャンで対応。もう1つ、コンテナのランタイム対策として、ECS上のコンテナをRead-Onlyに設定しました。Read-Onlyにしないと、脆弱性が見つかったときにコンテナ内にファイルを置かれるリスクがある。そこでRead-Onlyコンテナで書き込みを不可にしています。

当初はサイドカーを仕込むようなランタイムスキャンも検討しましたが、非常に負荷が重かったため、がんばってRead-Only化することでセキュリティを担保しました。

モニタリング

4つ目がモニタリングです。セキュリティ対策は、やってもキリがない。100点は取れないので、モニタリングをする運用の仕組みが非常に重要だと思います。

我々はオンプレとクラウドの両方にシステムがあるので、クラウド側はSecurity HubやGuardDutyでイベントを拾い、AWS Lambdaで通知します。オンプレ側はZabbixベースで同様に通知する仕組みです。

クラウド・オンプレをまたぐトラフィックも多いので、オブザーバビリティはNew Relicを使ってモニタリングをしています。これのおかげで、これまで多かった「謎のパフォーマンス障害」もだいぶ解決できたかなという印象です。

ログは、クラウド側はAmazon S3に格納し、オンプレ側もFilebeat／LogstashでS3に準リアルタイム集約しています。これを用いて、まずSageMakerでAI（先ほどの与信のところなど）のモデリングを作ったり、ダッシュボードはAmazon QuickSight（S3上のParquetファイル）で提供しています。

もともとはTableau、その後DOMOも使ったのですが、エンドユーザーが使いこなせず、結局システム側に「このビューを作ってください」と依頼が来る状況は変わらなかったんです。コスト面も踏まえ、今はQuickSightに落ち着いています。

データ量が増えると、バッチや分析が回り切らない課題が出るので、ここはDatabricksさんにご協力いただいて、高速に分析できる基盤を整え始めています。

さらに、ログ上の相関関係を分析してアラート検知しないと手が打てないので、SIEMの部分はElastic Stack（Elasticsearch/Kibana）で対応しています。スライド右上を紹介し忘れましたが、アラートの連携基盤や外向けステータス公開は、AtlassianさんのOpsgenie/Statuspageを活用しています。これがモニタリングの全体像です。

バースト対応

2つ目の非機能要件はバースト対応です。ECサイトだと、色々なセールやレア商品の販売で、ボットも含めてトラフィックが平時の100倍とか来るんですよね。さすがにオートスケールでも厳しく、他サービスに影響が出ることがありました。

これはオンプレの処理だったので、その手前のCDNを活用してスロットリングしました。Lambda@Edge＋DynamoDBを使って、加盟店ごと・決済手段ごとの流量制御（カウントアップ/ダウン）を行います。たとえば「100セッション以上はエラーで返す」といった制御をCDNで前詰めすることにしました。

これにより、100倍のトラフィックがあるお店で発生しても5倍までは入れて、残りはエラーで返す。ずっと待たされた末にエラーになるより、早めにエラーが表示されてリトライできたほうが体感は良い、という判断です。

このLambda＋DynamoDBの仕組みは、先ほどのfincodeのAPI Gateway＋Lambda＋DynamoDBで作ったものを、ほぼそのまま流用しています。

今後の展望

昨今、LLMが開発者の間でも広がっており、生産性や品質向上に取り組み中です。Copilot、Cursor、Devin、Codex、Claude Codeなど、日々アップデートされるものを試行しています。Amazon Q Developerを使ってみたり、GMOインターネットグループ内の「天秤AI byGMO」という、同じプロンプトを複数モデル（Claude/ChatGPT/Geminiなど）に投げて比較できる仕組みも活用。メトリクスはFindy Team+やTeamSpirit（チムスピ）で集計し効果検証、GitHub Actionsで自動化、コードレビューは今のところQodo Merge＋Amazon Bedrock等の活用も試行しています。

この9年間を振り返ると、フラットな情報共有と「触ってなんぼ」の世界なので、教育以前に、まずは実プロジェクトで触ってみること。そして「やってみたい」という気持ちが一番大事。LLMはもう避けて通れないので、AIと仲良くなることを目指しつつ、最終的にはやっぱり人。「企業は人なり」。いかに人が成長していけるかを考えながら、日々エンジニアリングしています。

ご清聴ありがとうございました。

（by あなたのとなりに、決済を 編集チーム）

※本コンテンツ内容の著作権は、GMOペイメントゲートウェイ株式会社に属します。

---

エンジニアイベント書き起こし記事一覧はこちら

採用情報はこちら

パートナーインタビュー記事一覧はこちら