Solution Square (Global)
2025 – Present画面
目的
製品情報、技術資料、選定ツール、エンジニアリング知識を複数の地域と言語で提供するLS ELECTRICのグローバル顧客ポータルです。
役割 · 技術スタック
Java/Springベースのバックエンドサービスと、フロントエンドのリクエストを受けるAPIサーバー(BFF)、React・TypeScriptのフロントエンドで、製品・ダッシュボード・検索・AIサービスの開発に参加しました。
Java · Spring Boot · React · TypeScript · Azure · Elasticsearch · Jenkins
実績 01
認証ロジックの共通化
- 背景・原因
- グローバルポータルと資産管理サービスは同じルーツから出発した製品です。当初はフロントエンドのリクエストを受けて認証とバックエンド連携を担うAPIサーバー（BFF）も一つでした。担当組織の分離後、資産管理サービス側に同じ認証ロジックのハードコピーを持つAPIサーバーが生まれました。両者の挙動がずれて原因特定も難しくなっていました。
- 検討・選択理由
- 運用対象の増加と全リクエストへのネットワークホップを二つのサービス規模で受け入れる理由がないため、専用の認証サーバー案は見送りました。既存の共通モジュールの慣例に従い、セッション、認証トークン・SAMLユーティリティ、JWTの順で段階的に抽出しました。アダプターを置いたのも同じ理由で、二つのアプリケーションを一度に変えず接続点だけを置き換えるためです。
- 結果
- 認証ロジックの変更が一箇所の修正で完結し、両アプリケーションの認証挙動が同一になりました。移行で残ったデッドコードと重複依存を整理し、JWTライブラリも単一所有に統一しました。
- 振り返り
- レガシー改善では、一度に作り直すより既存の慣例に従って変更範囲を減らし、検証可能な単位に分けて移す方が安全です。
実績 02
通知テンプレート・受信者管理システムの構築
- 背景・原因
- メール通知テンプレートは言語別のHTMLファイル54個としてハードコードされていました。テンプレートごとにリクエストクラスとエンドポイントがありました。通知の種類とともにコードが増え、文言や受信者の変更にもデプロイが必要でした。
- 検討・選択理由
- 管理者がデプロイなしで文言と受信者を扱えるよう、テンプレートをコードからデータへ移しました。チャネル、イベントタイプ、サービスタイプ、言語の四軸で識別し、新しい通知を行の追加で済ませました。受信者レジストリの分離、管理画面用の統合API、共通のテンプレート送信により重複とAPI往復を抑えました。
- 結果
- 管理者がデプロイなしでテンプレートと受信者を動的に管理できるようになりました。後続の機能もコード追加なしで既存の送信ロジックを再利用できました。受信者・送信履歴は個人情報の暗号化対象としても整理しました。
- 振り返り
- 同じ形のコードが繰り返し増えるのは、データモデル不在の兆候です。識別軸をデータへ移せば、新しい要求をコード変更ではなく行の追加で終えられます。
実績 03
個人情報の暗号化と検索の両立
- 背景・原因
- 個人情報保護の基準を高めるには、氏名や連絡先のようなフィールドを暗号化する必要がありました。ただし暗号化すると、その値を条件にする既存の完全一致検索が壊れます。保護と検索可能性が正面から衝突していました。
- 検討・選択理由
- 検索を後回しにして平文検索の経路を残さないよう、エンベロープ暗号化とブラインドインデックスを最初から併せて設計しました。鍵バージョンを保存し、再暗号化の経路を残しました。書き込み、検索、バックフィルの順に段階を分け、運用データの移行中は平文と暗号文の両方を読めるようにしました。
- 結果
- 暗号化された値でも完全一致検索を維持したまま、運用中のデータへ段階的に適用しました。バックフィルは行の状態を基準に再開できるため、中断後の再実行も安全です。
- 振り返り
- 保全要件を運用中のシステムへ適用するには、機能を壊さない移行経路まで設計する必要があります。暗号化移行の各段階は再進入可能な状態にすべきです。
実績 04
デプロイ通知・連続デプロイの自動化
- 背景・原因
- 複数モジュールをデプロイする環境で、誰がいつデプロイしたかがチームに共有されていませんでした。コミット単位のレビューで見落としが生じる余地もありました。ビルドサーバーのメモリ制約で並列ビルドができず、人が前のビルドを待って次のデプロイを手動で開始していました。
- 検討・選択理由
- 一つのチャネル障害で自動化が途切れないよう、チームが日常的に見るTeamsを基本とし、送信失敗時はメールへフォールバックしました。AIレビューはマージリクエスト単位とプッシュ単位に分けました。デプロイはサーバーメモリを増やす代わりに、パイプラインが前の完了を検知して次のビルドとデプロイを自動で開始するようにしました。
- 結果
- デプロイの事実とレビュー結果が自動で共有され、連続デプロイで人が待つ必要がなくなりました。
- 振り返り
- 通知は成功経路だけでなく送信失敗時のフォールバックまで設計してこそ信頼できます。自動化では作業そのものだけでなく、作業の間の待ち時間も対象にすべきです。
実績 05
Java 11 → 21 → 25 ランタイム現代化
- 背景・原因
- モバイルクライアント認証と顧客サイト単位のファイル管理を担う新しいアプリケーションを追加する必要がありました。既存のJava 11の方式では実装に制約があり、古いランタイムを残すこと自体も長期的な保守リスクでした。
- 検討・選択理由
- 現代化は新規アプリケーションの構築と合わせて始めました。まずJava 21をマージし、新機能開発とランタイム移行を同じ期間に進めました。続いてJava 25へ上げ、Spring Boot 4のBOMでバージョン管理を統合しました。Jackson 3移行、JWTライブラリの単一所有への整理、モジュールごとのビルドJDK切り替えも併せて処理しました。モジュール間で依存が分かれないようにするためです。
- 結果
- アップグレードが壊したものも併せて復旧しました。SAMLヘッダー処理でのHTTPS判定の反転、entity-idのスキームと非標準ポートの問題が出ました。ステージングの403やプロキシ越しに失われたクライアントIPも、診断フィルターまで入れて原因を絞り戻しました。同じ流れでフロントエンドのビルドをCRAからViteへ移し、検索クライアントも9.xへ上げました。バックエンドとフロントエンドの古い依存を併せて取り除きました。この移行により、後のSAML標準化もフレームワークが支援する方式の上で進められました。
- 振り返り
- ランタイムのアップグレードで実際に手がかかるのは、バージョンを上げることではありません。環境差で静かに壊れた挙動を見つけて戻すことが本体です。
実績 06
SAML標準化とSSO拡張基盤
- 背景・原因
- 新しいパートナーIdPとのSSO連携が求められました。レガシーなSAML実装ではフレームワーク上、柔軟で拡張可能な構造を作ることが困難でした。特にSpring Boot 4では従来のIdP実装方式が制限されます。
- 検討・選択理由
- 独自方式を修正し続けるのではなく、フレームワークが支援する標準方式へ移行しました。標準の上にあればバージョンアップに耐え、拡張もフレームワークの流儀で扱えるからです。SSOプロバイダーレジストリで提供者ごとの分岐を置き換え、専用のセキュリティチェーンでIdPの規則を分離しました。汎用SAML 2.0 Mock SPで各パートナーの実環境を待たずに準拠を確認します。
- 結果
- IdP起点の自動ログインが動作する標準基盤を整えました。汎用SAML 2.0 Mock SPテストアプリケーションも用意し、新しい提供者との連携を繰り返し検証できるようにしました。
- 振り返り
- 次のフレームワーク版で制限される方式を先に確認して標準化すれば、目先の要求を超えた後続の拡張コストを下げられます。
実績 07
ルールベース製品構成ツール（Drive Panel Selector）
- 背景・原因
- 顧客は仕様に合うドライブ・パネル構成を探すたびに技術問い合わせを行う必要がありました。営業からは、システム内で相談から見積もり依頼までつながるツールが求められていました。
- 検討・選択理由
- 学習モデルではなく明示的なルールを採用したのは、製品構成がオプション間の制約が明確な工学的問題だからです。見積もりや受注につながる結果には説明可能性も必要です。前段の選択に応じて後段の選択肢を動的に絞り込みました。最終段階のモデル画像、顧客入力、問い合わせ履歴連携、重複依頼防止も相談・見積もりの流れにつなげました。
- 結果
- 顧客は技術問い合わせなしで仕様に合う構成を絞り込み、結果モデルに到達できます。その場で問い合わせや見積もり依頼へ進めるようにもなりました。
- 振り返り
- 推薦のように見える要求も、オプション間の依存関係を明示的なルールにすれば予測可能に扱えます。ツールは結果画面だけでなく、相談と見積もりまでつながって完成します。