【協賛レポート】JJUG Cross Community Conference 2025 Fall / 開発者向けブログ・イベント

国内最大級のJava技術者コミュニティイベント「JJUG Cross Community Conference 2025 Fall」に、GMOペイメントゲートウェイ株式会社がスポンサー協賛しました。当日は、決済と暗号技術の現場を担うエンジニアが登壇するセッションやLT、そしてブース展示まで、多彩なプログラムを展開。セッション内容と当日の様子をレポートします。

GMOペイメントゲートウェイ株式会社は、オンライン決済を中心とした総合的な決済関連サービス・金融関連サービスを提供する決済事業者です。クレジットカード決済やコンビニ決済、キャリア決済、銀行振込（バーチャル口座）、各種Pay系決済など、国内外あわせて30種類以上の決済手段を一括で導入できるPGマルチペイメントサービスをはじめ、多様な事業者の決済インフラを支えています。現在は16万店舗を超える加盟店にサービスを提供し、年間取扱高は13.1兆円規模に達するなど、日本のキャッシュレス社会を支える基盤として成長を続けています。

こうした中、2025年11月15日にベルサール新宿グランドコンファレンスセンターで開催されたのが、日本Javaユーザーグループ（JJUG）が主催するJJUG Cross Community Conference 2025 Fallです。日本最大級のJavaコミュニティイベントとして知られる本カンファレンスには多数のJavaエンジニアが集まり、Java関連技術や実案件の事例紹介、コミュニティ活動の報告など、多彩なセッションが展開されました。

GMOペイメントゲートウェイ株式会社は、本イベントにスポンサー協賛。決済インフラを支えるエンジニア組織としてスポンサーセッションとLT登壇、そしてブース出展を実施しました。今回は、GMOペイメントゲートウェイ株式会社前川篤史さんのセッション内容を中心に、イベント当日の雰囲気をお届けします。

セッション：BouncyCastleはPGP暗号化の最適解なのか？決済システムの現場で選んだ実装とそのポイント

スポンサーセッションに登壇したのは、GMOペイメントゲートウェイ株式会社で公共料金系決済サービスの開発に携わる前川篤史さん。「BouncyCastleはPGP暗号化の最適解なのか？」というテーマのもと、決済システムという高いセキュリティ要件の現場で求められる実装の判断基準や、その過程で直面した課題を共有してくれました。

2022年に同社へ入社した前川さんは、現在エンジニア4年目。これまではマルチビリングパッケージの保守開発を中心に担当されてきましたが、今回初めて暗号処理の新規開発に挑戦。「暗号技術にはあまり詳しくなかったのですが、この案件を機に一から学ぶことになりました。いま、数学を学び直したい気持ちでいっぱいです」と、等身大で語ります。

前川さんは冒頭、このセッションで参加者が得られる学びについて次の三つを挙げました。

PGPやハイブリッド暗号方式、デジタル署名などの暗号技術の仕組み
Javaでライブラリをどのように選定したのか（現場での判断基準・意思決定プロセス）
BouncyCastleまたはGPGコマンドを使った実装例（ミスしやすいポイントや実際に発生した課題の共有も）

続いて、今回の話題の前提となる案件についても説明がありました。前川さんが携わっているのは、電気・ガス・水道などの公共料金事業者向けに複数の決済手段を提供するマルチビリングパッケージ。

決済の流れとしては、電気・ガス・水道などの使用データが加盟店からGMO-PGに連携され、そこからカード会社・銀行へ処理が進み、最終的に結果が返却されます。

加盟店との接続方式としては、API・ファイル連携・管理画面という3つが用意されています。今回、セッションで説明されるのは、このうち「ファイル連携」の領域。ファイル連携におけるオプション機能として、PGPによる暗号化機能を新たに実装したことが、本セッションのテーマへとつながりました。

PGPとは何か

本セッションのテーマである「PGP」は、Pretty Good Privacy の略称で、電子メールやファイルに対して暗号化や署名を行う技術です。仕組みとしては、共通鍵暗号やハイブリッド暗号方式、デジタル署名、そして鍵管理などが含まれ、通信データそのものの保護を目的としています。

1998年にはPGPの仕様が OpenPGP としてRFC化され、標準規格として公開されました。その後、さまざまなOpenPGP実装が開発され、代表的なものとしてGnuPG（GPG）や、今回のセッションで取り上げられるBouncyCastleが挙げられます。

「なぜPGPを使うのか」に関して、前川さんはSSHとの比較を用いて説明します。SSHのように通信経路のみを暗号化する場合、通信中のデータは守られますが、サーバー上に保存されるデータは平文のままです。そのため、サーバーが侵害されると情報が漏洩する可能性があります。

これに対しPGPでは、通信データ本体が暗号化され、復号されるまで暗号化状態が維持されます。つまり、データがサーバー上に存在していても第三者が内容を取得できない、いわゆるエンドツーエンド暗号化を実現できる点が強みとなります。

また、暗号プロトコルには他にもSSL/TLSやS/MIMEなどが存在しますが、「ファイルなどの通信データそのものを汎用的に暗号化できる方式としてPGPは現在も主要な選択肢」だと言います。前川さんは「OpenPGPは2024年にも新たなRFCが公開されるなど、進化を続けている技術」と話し、その有用性を強調しました。

Javaで何を実装しなければならないのか

前提知識を踏まえ、セッションは「Javaで何を実装するのか」へと進みます。PGPで用いられるデジタル署名やハイブリッド暗号方式の仕組みを整理しながら、その処理をどのようにJavaとして落とし込んでいくかが解説されます。

「全体像としては複雑に見える処理フローですが、次の4つに分解すると分かりやすい」と前川さん。

デジタル署名の生成
署名付きデータの暗号化
暗号化データの復号
署名の検証

この4つが、そのままJavaでメソッドや処理単位として実装されていくことになります。

まずは、「デジタル署名の生成」と「署名の検証」について。「暗号化」がデータの内容を第三者に読まれないよう保護する機密性を担保するのに対し、「デジタル署名」は改ざんされていないことを保証する信頼性の役割を担います。

具体的な流れは以下の通りです。

【送信者側】

平文データをハッシュ関数に通す
ハッシュ値を秘密鍵で処理して署名を生成
平文と署名を結合して署名付きデータを作る

【受信者側】

復号後に署名付きデータを分離
送信者の公開鍵で署名を復元
同じハッシュ関数で平文データをハッシュ化し、その値が一致することで改ざんされていないことを確認

続いて、「署名付きデータの暗号化」と「暗号化データの復号」について。なお、こちらはPGP特有のものではなく、広くTLSなどでも採用されているハイブリッド暗号方式です。

【送信者側】

平文データ（署名付きデータ）を用意
乱数生成器からセッション鍵（共通鍵）を生成
本体データをセッション鍵で暗号化
さらに、そのセッション鍵を受信者の公開鍵で暗号化
暗号化されたセッション鍵とデータ本体を結合して送信

【受信者側】

暗号化されたセッション鍵を秘密鍵で復号
取得したセッション鍵で本体データを復号
中の署名付きデータを取り出し、先ほどの署名検証へ進む

このような構造になっている理由について、前川さんは「公開鍵暗号と共通鍵暗号の処理コストの違い」を理由として挙げます。

「公開鍵暗号は共通鍵暗号のおよそ1000倍の計算負荷がかかる。そのため、大きなデータは高速な共通鍵暗号で処理し、その鍵自体を安全に配送するためだけに公開鍵暗号を使う構造が採用されているのです」（前川さん）。

ここまでのプロセスを踏まえ、「PGPという名前が付いているからといって、何か特別な処理が行われているわけではない。むしろ一般的で標準化された暗号処理の組み合わせで構成されていることがお分かりいただけるでしょう」と前川さんは総括します。

PGPの利点はむしろ、プロトコルとして広く認知・標準化されており、システム間の互換性を確保できる点にあるのです。

Javaでどう実装したか

いよいよ、本セッションの核心である「どのように実装したのか」へ話が進みます。

実装方式として前川さんが比較したのは次の2つです。

GnuPG（GPG）を外部コマンドとして呼び出す方式
BouncyCastle（Java ライブラリ）を利用する方式

前川さんが出した結論は、「どちらが最適かは、運用前提・データサイズ・性能要件によって異なる」というもの。唯一の正解は存在しないとしたうえで、今回の案件でBouncyCastleを採用した理由が語られることになります。

まずは、GnuPG（GPG）方式です。GnuPG（GPG）はPGPのオープンソース実装として広く利用され、OpenPGPに準拠し、OSを選ばず利用できる汎用性が魅力です。とくにLinux環境では、

署名＋暗号化
復号＋署名検証

の処理が、それぞれ1つのコマンドで完結するほどシンプルに実行できます。

Java側の処理も

暗号化対象ファイルの取得
GPGコマンドを組み立てて呼び出し
結果をチェックし、エラーハンドリングを行う

という実装で済むため、非常に短いコードで書ける点が利点です。「さらに、GPG方式は他部署でも長年運用されてきた実績があり、現場での信頼性も高かった」と前川さんは話します。

一方で、デメリットも明確です。

１．独立性が低い（外部プロセス依存）

Javaアプリ単体では完結せず、実行環境にGPGがインストールされている必要がある
テスト時にGPGのモック実装が必須

２．境差分による挙動の不一致

サーバごとにGPGのバージョンが異なる場合、対応アルゴリズムが違う
検証環境では動作しても本番では動かないリスク

３．エラーハンドリングの難しさ

GPGが返す結果は「ファイルが生成された / されない」で判定するため、エラー理由がJava側で例外として取得できない
特に加盟店との毎日のデータ連携では、原因特定の迅速性が求められるため、この点は大きな懸念となる

これらの背景から「Java単体で完結する方式」を検討した結果、候補として浮上したのが BouncyCastleだったと言います。BouncyCastleはJava上でPGP処理を実装できるライブラリとして高く評価されており、特にOpenPGP関連の機能に強みがあります。

BouncyCastleによる実装では、処理全体が明確な4ブロックに分かれ、上部で鍵を取得し、下部でデータを生成するという構造になります。ただし、GPGのような単純な呼び出しではなく、PGPプロトコルの処理理解が必要となるため実装コストは高く、学習負荷が大きくなります。

ここで前川さんは、具体的な実装の例として「PGP署名付きデータの構造」を挙げました。署名付きデータは次の3パケットで構成されます。

署名のメタ情報パケット
本体データパケット
署名パケット

Javaプログラム上では、これらを順番に生成し、ファイルへ書き込んでいく流れとなります。「エンジニアとして興味深かったのは、本体データを出力しながら逐次的にハッシュ計算を行う点。これは実装して初めて、体感的に理解できた」と前川さんは話しました。

PGPの構造を一つずつ理解しながら組み上げる必要があるため、BouncyCastleの実装は決して容易ではありませんが、「得られるメリットは明確」とのこと。具体的なメリットとして、次の3点が挙げられました。

❶外部プロセスに依存しない（独立性が高い）> Javaアプリ単体で完結するため、環境差分による影響が最小限に抑えられる

❷テストしやすい > JUnitによるテストが容易で、ローカルでの検証もスムーズに行える

❸エラーハンドリングが柔軟 > 発生したエラーを例外として取得できるため、何が原因で、どの処理で問題が起きたのかを特定しやすく、運用上の安全性・保守性の向上につながる

一方で、最後の判断材料となった処理速度については、興味深い比較が示されました。

小さいファイルサイズ（数KB〜数十KB）では差はほぼない
大容量ファイルではGPGが有利（1GB処理時に約8倍高速）

そのため今回の案件では、

取り扱うファイルサイズが小さいこと
性能要件が厳しくないこと

この2点から BouncyCastleを採用する判断に至ったと言います。「逆に、日常的にGB級のファイルを処理するワークロードであれば、GPG方式が適している」と前川さんは補足しました。

さらに前川さんは、実装過程での「しくじり」についても共有しました。

まず1点目が、ファイルサイズのテスト不足による問題です。実運用では小さいファイルしか扱わなかったため、単体テストも8KB程度で十分だと判断。その状態で、「問題なく処理が成功」と判断していました。

しかし、「興味本位」で1GBのファイルを処理したところ、署名検証でエラーが発生。本体データパケットをすべて読み切る前に署名パケットを処理し始めていたことと、小さいファイルではバッファ内に収まるが、大容量では処理が破綻するという、構造的な問題でした。

もう1つの学びが、接続先との連携テストの重要性です。上で挙げたような失敗は、実運用時に接続先でも同様に発生する可能性があるものです。前川さんは、「自社環境で正しく処理できているだけでは不十分。早期に接続先と相互検証することが必須」と総括しました。

「PGPの実装については、使用するファイルサイズや運用要件によって最適解が変わるものの、ファイルサイズが十分に小さいケースでは Bouncy Castleをおすすめできる」と前川さんは結びます。「今後の改善のヒントや運用のポイントがあれば、ぜひ共有してほしい」と呼びかけ、セッションを締めくくりました。

スポンサーLT：エンジニアが紹介するGMOペイメントゲートウェイ

会場ではスポンサーLTも行われ、決済代行を軸に幅広くサービスを展開する同社の事業内容や、PGマルチペイメントサービスの役割、そしてエンジニアとしての働き方について紹介がありました。

「バックエンドはすべてJavaとSpring Bootで構築されており、AI活用も進めています。そして、内製開発であるために自分たちの裁量でプロダクトを育てられる環境であることが大きな魅力です。企画から運用までフルフェーズで関われるので、エンジニアとしてのキャリアを自由に広げられます」

参加者の皆さんも、コーヒーを片手にリラックスした雰囲気で耳を傾けていました。

ブース紹介：決済の裏側を見て・触れて・話して知る

最後にご紹介するのは、会場に設けられたGMOペイメントゲートウェイ株式会社のブースです。

もっとも参加者の目を引いたのは、オンライン決済がどのような仕組みでつながっているのかを、図解を通して直感的に理解できるパネルです。エンドユーザーが事業者を通じて支払いを行う際に、GMOペイメントゲートウェイ株式会社の各サービスを経由しながら、最終的にカード会社やPayPayなどの決済手段につながっていく流れがひと目で分かる構成になっていました。

また、ポストイット形式で「皆さんがお使いのIDEは？」「どんなAIツールを使っていますか？」というアンケートも実施。これをきっかけに参加者との交流が多く生まれました。ブース担当の奥山貴大さん（GMOペイメントゲートウェイ株式会社）は「新卒からずっとGMOペイメントゲートウェイ株式会社に在籍しています。出展を通じて、他社のエンジニアが何を考えているのか直接聞ける機会はとても貴重です」と笑顔を見せました。

同じく注目を集めていたのが、オンライン決済サービス「fincode byGMO」による生成AIデモです。チャットライクな画面に「クレジットカード決済で、●●円を支払いたいです」などと入力すると、AIが即座に支払い用URLを発行してくれました。「最先端のAIを活用しながら決済まわりを自動化することで、事業立ち上げのハードルを下げたい」と奥山さんは笑顔を見せます。

ブースでは、こんなプレゼントも配布されていました。

■ ワイヤレス充電器

アンケートに回答してくださった来場者の皆さんへ、GMOペイメントゲートウェイ株式会社のロゴ入り充電器をプレゼント。用意した分があっという間になくなるほどの人気ぶりでした。

■ ミニポーチ

「fincode byGMO」のロゴ入りミニポーチ。エンジニアに優しい仕様を目指すサービスの世界観を、身近なアイテムとしてデザインに落とし込んだノベルティです。

■ 技術書の合同誌

GMOインターネットグループのエンジニア有志が制作した技術書の合同誌。GMOインターネットグループ全体の「つくる文化」に触れていただきました。

ブース担当の奥山さんよりメッセージ

「GMOペイメントゲートウェイ株式会社の魅力は、成長の機会がたくさんあることです。Javaエンジニアとして、さまざまなビルドツールやバージョンのシステムに触れられる環境には手応えがあります。弊社が提供するサービスやシステムは今も増え続けています。大きなシステムを育ててみたいと考えている方はぜひ、弊社のサイトを覗いてみてください！」