【Aiming】共通基盤なのに「共通化しない」課金・認証基盤「LINK」が選び取ったシングルテナント戦略と運用の秘訣

CEDEC2026で使用した資料

Transcript

1. 共通基盤なのに「共通化しない」 課⾦‧認証基盤「LINK」が選び取ったシングルテナント戦略と運⽤の秘訣
2. ⽬次 • • • • • • • 登壇者紹介‧会社紹介 課⾦‧認証基盤「LINK」の紹介 誕⽣と共通基盤への成⻑ 運⽤と苦難の歴史 シングルテナントで得た価値 今取り組んでいる課題 まとめ
3. 登壇者紹介 講演者プロフィール 2004年よりゲーム業界にて主にモバイル向けタイトルの開発‧運営に従事。 バンダイナムコスタジオではサーバーアーキテクト、テクニカルディレクターとし て技術的品質を担う業務を経て、エンジニアリングマネージャーとして組織開発 ‧⼈材育成へと活動の幅を広げる。 2021年9⽉弁護⼠ドットコム株式会社に⼊社後は、電⼦契約サービス「クラウドサ イン」の開発部⻑を務める傍ら、政府情報システムのためのセキュリティ評価制 度（ISMAP）取得‧維持のための活動に従事。 事業⽀援部 シニアマネージャー 井⽥ 浩義 2025年10⽉より株式会社Aimingに⼊社。 特技は打ち上げ花⽕。
4. 登壇者紹介 講演者プロフィール 2011年株式会社Aiming⼊社。 開発基盤、認証基盤、コミュニティサイト開発、ゲーム開発、マネージャーなど 様々なプロジェクトを担当し、現在はエキスパート職として認証‧決済基盤の開 発を担当。 事業⽀援部 シニアスペシャリスト 堀井 啓真
5. 会社紹介
6. 株式会社Aimingについて 面白いを カタチに変える。 社 名 ：株式会社 Aiming 設 立 ：2011年5月12日 所在地 ：〒 151-0051 東京都渋谷区千駄ヶ谷五丁目 31-11住友不動産新宿南口ビル 5F 事業内容：オンラインゲーム開発・企画プロデュース・運営
7. 株式会社Aimingについて Aimingの強み‧特徴 従業員数：約700名 市場：グロース市場上場 ゲーム事業に特化した「開発⼒」 ベンチャー気質の「挑戦‧スピード感」
8. 開発実績 剣と魔法のログレス いにしえの⼥神 陰の実⼒者になりたくて！マスターオ ブガーデン ドラゴンクエストタクト （スクウェア‧エニックス）
9. 開発体制
10. 使⽤している技術の紹介 開発ツール ゲームエンジン ⾔語/フレームワーク クラウドサービス データベース コンテナ技術 ネットワーク通信
11. イントロ
12. 「共通基盤」といえば、ふつうは相乗り
13. 相乗りモデルのメリットとデメリット • メリット ◦ ⼀つに集約するほど、コスト効率と⼀括運⽤が効く ◦ ミドルウェア対応もセキュリティ対応も⼀度で全体反映できる • デメリット ◦ 全員が同じルール‧同じ更新‧同じ制約に従う ◦ タイトルごとの個別の事情には応えにくい
14. しかし、Aimingの現実はバラバラだった • タイトルごとに利⽤するクラウドが異なる • 運⽤の途中で決済事業者の追加が起きる • 運営移管（他社への委託‧受け⼊れ）の検討が⼊る ステークホルダーの要望は、多岐にわたった…
15. 単⼀の基盤では、価値を届けきれない
16. 課⾦‧認証基盤「LINK」紹介
17. 「LINK」とは 定義した共通のルール‧フローで決済が⾏えるシステム
18. 「LINK」導⼊⾃体のメリット • ストア決済のトランザクションを LINK で管理できる ◦ ◦ 商品管理対応、決済のみなど、ストア特性に依存しない ストアごとに異なるタイミングを⼀意に制御できる • ストア決済のトランザクションの状況を LINK で確認できる • ゲーム側でストア決済処理をコーディングする必要がなくなる
19. 対応決済ストア etc...
20. 「LINK」の技術スタック 言語/フレームワーク データベース クラウドサービス コンテナ技術
21. 「LINK」 SDK ゲームクライアントと LINK及び決済プラットフォームとの連携ツール 各タイトルごとに課⾦決済処理を作ったり、 決済事業者特有の処理を作ったりしなくて済むようになっている
22. 「LINK」 SDK実態 Unity Package エディタ上でのimport
23. 「LINK」 SDK実態
25. 「LINK」サーバー構成図
26. 「LINK」の歴史 〜誕⽣と共通基盤への成⻑〜 ❏ ❏ ❏ ❏ 開発のきっかけ 共通基盤化の壁 運⽤の壁 インフラ⾯の困難
27. 開発のきっかけ
28. LINK誕⽣前は全て⾃前で実装していた タイトル内で個別に課⾦、認証を制作し ていた 切り出して共通化する考えもなかった。
29. 某タイトル開発がLINK誕⽣のきっかけ 海外タイトルの国内運営のために、 認証と課⾦処理のシステムとして実装 課⾦と認証だけが作られており、切り出 しやすい構造だった 開発後、他タイトルチームから需要があり、 だんだんと活⽤されるように。
30. 評判の⼀⽅で…… なし崩し的なシステムの広まりに、 現場では不安と危機感が⾼まる。
31. トップメッセージによる後押し
32. 企業資産としてのシステムへ エンジニアリーダーのメッセージから 本格的に共通基盤化することに！
33. 共通基盤化への壁
34. 「共通化」を前にした現実 新規機能が互換性に影響 コスト問題 運営中タイトルへの導⼊は困難 縮退運営中のタイトルはアップデートコストがかけられない ことも……。
35. 「共通化しない」― これが私たちの開き直り シングルテナントで運⽤！
36. 共通化への⽅針は定まったものの‥‥‥
37. 「運⽤」の課題 • 汎⽤機能にパブリッシャー側の 制約が混⼊ • 他タイトルの固有機能が混⼊
38. 状況を打破するために
39. 必要機能を選択可能にする、３つの戦略 コードベースの統合 フィーチャーフラグで 必要機能を選択 互換性のバージョン管理
40. コードベースの統合 • まずは⼀つに統合する • パブリッシャー制約は抽象度を⾼ めて⼀般化して統合した • タイトル固有機能も⼀定の汎⽤化 を⾏った上で統合した
41. フィーチャーフラグの導⼊ • 各タイトルで必要な機能をフィー チャーフラグで選択させるように • 環境変数やビルドパラメータ、管 理ツールでの切り替えなど、⽤途 に応じて必要なパラメータを操作 できるように
42. 互換性のバージョン管理 • セマンティックバージョニングを ⽤いアップデートコストを可視化 • タイトルがアップデートを⾏うか どうかを判断できるように
43. インフラ⾯の困難
44. 従来の課題 オンプレミス環境での 不安定なインフラ構築
45. インフラのモダナイゼーションで解決！ IaC（Infrastructure as Code） や コンテナ化の普及により、 安全かつ低コストな運⽤体制を実現
46. 「LINK」を シングルテナントで 運⽤するメリット ❏ ❏ ❏ ❏ ❏ 運⽤負荷分散 ミドルウェア対応コスト減 ⾃社環境への円滑な合流 セキュリティ診断も1度でOK 運⽤の柔軟性
47. シングルテナントモデルの採⽤で 負荷分散
48. スパイクが発⽣しても、他のタイトルへ影響しない １つのシステムだと… シグナルテナント（LINK） スパイクが他タイトルへ及ぶ 影響が隔離され、運⽤負荷も低い
49. ミドルウェアへの対応コスト減
50. ミドルウェアへの対応は⼀度で完了！ 各タイトルへの個別対応が不要に！
51. ⾃社環境への円滑な合流
52. 委託時は権限渡すのみでOK 委託時は権限を渡すだけ 他タイトル情報へ アクセスされる恐れがない
53. 堅牢で安価なセキュリティ
54. 無駄のないセキュリティ診断 ⼀度の診断で監査済みシステムを各タイトルへ適⽤できる！
55. タイトルの状況に合わせた、柔軟な対応
56. 好調タイトルへの対応 • 課⾦誘因施策の実装 • 決済⼿段追加による利便性の 向上 • タイトル固有の要望対応 アクティブな施策を積極的に導⼊！
57. 縮退運営タイトルへの対応 • コストをかけない運⽤ • バージョンを積極的には上げ ない • セキュリティリスクなど最⼩ 限の対応 コストの最適化を図る
58. 現在の取り組み 更なる成⻑と進化のために ❏ 課⾦状態の⼀元管理化 ❏ 認証と課⾦の分離 ❏ チームの成⻑
59. 「LINK」の、その先へ ― これからの全体像 課⾦状態の⼀元管理で、サ 認証と課⾦の分離で、複雑 開発者体験そのものを担う ポートコストを下げる 性‧認知負荷を下げる プラットフォームエンジニ アリングチームへ
60. 課⾦状態の⼀元管理 決済業者ごとに異なる状態管理を⼀元化し、サポートコストを軽減
61. 認証と課⾦の分離 それぞれの特性に合わせた最適化を可能にし、認知負荷を軽減
62. チームの成⻑ LINK以外にもCI/CDや分析基盤など、開発者体験向上を担うチームへ！
63. それでも、まだ道半ば ― 残る宿題 • リアーキテクチャや分離は進⾏中― ⼀度に終わるものではない • 取り組みの最中にも新たな要望や経営判断が⼊り、計画通りに は進まない • だからこそ、呼吸を乱さず進められる個別配布の構成が効いて くる
64. まとめ
65. 共通化しない共通基盤の正体と価値 要望の集約と個別配布 選択的バージョンアップ リスクまで共有しない 各タイトルの要望を集約して作ること で分散を防ぎつつ、配布は個別にする ことで⾃由度を上げている 共通基盤の運⽤が各タイトルの 運営の呼吸を乱さない 共通基盤のメリットを資産とし て共有しながらも、各種リスク は分散している
66. もう⼀度設計しても、同じ構成を選ぶ • 要望は集約しつつ、配布は個別に 。この分離が効いた • タイトルの状況に合わせ、運営の呼吸を乱さず運⽤できた • メリットは資産として共有し、リスクは分散できた 「共通化しない」という開き直りは、結果として正しかった
67. 我々はこれからも 「共通化しない」共通基盤と歩んでいく
68. ご清聴ありがとうございました