背景・課題 料金・ポイント計算処理の現状整理と課題、改善策 前提）宿泊システムでの料金とポイント計算 1. 料金・ポイント計算をどんな業務で使っているか 2. 料金・ポイント計算各業務の特徴と違い 3. 本来あるべき料金・ポイント計算ロジックの姿と、現状のギャップは何か（課題） 4. 本来あるべき姿に向けて、現状からどう改善していくか 現状と今後の展望 まとめ おわりに 宿泊プロダクト開発部の田中（ id:kentana20 ）です。 このエントリーは 一休.com Advent Calendar 2025 の11日目の記事です。 今回は、一休.com宿泊で進めている 「ホテル/旅館の宿泊料金・ポイントを計算する処理が複数のシステムに分散している状態を改善している」 という取り組みについてご紹介します。 背景・課題 一休.com 宿泊には、いくつか重要な業務が存在しますが、その1つに「宿泊料金・ポイントの計算処理」があります。 各ホテル・旅館が設定した料金 サイトを閲覧しているユーザー（会員）の状態 ユーザーが指定している検索条件（日付、人数など） 期間限定で実施しているポイントX倍、のようなプロモーション などの情報に基づいて、宿泊料金を算出したり、予約で得られるポイント数を計算する処理です。 この料金・ポイント計算処理は、以下のような背景・課題がありました。 歴史的経緯から、料金・ポイント計算ロジックが複数のシステムに分散して存在している （複数システムに分散しているため）ロジックの変更を行う際に、複数のシステムに対して同じ変更を繰り返し実施する必要がある 「今年の冬は、こういうポイントアップのプロモーションを実施したい」というビジネスのニーズに対して、必要以上に対応コストがかかってしまう 昨今、ECをはじめとするWebサービスにおいてポイントやクーポンといった販促・インセンティブ機能はビジネス上も重要な要素となっており、一休.com 宿泊においても例外ではありません。 これを踏まえて、各システムで実施している料金・ポイント計算処理を整理し、本来あるべき姿を検討して改善を進めることにしました。 料金・ポイント計算処理の現状整理と課題、改善策 本来あるべき形を検討するにあたり、まずは現状の料金・ポイント計算処理がどうなっているかを整理するところから始めました。 整理については 料金・ポイント計算をどこで、どんな業務で使っているか それぞれの業務で、料金・ポイント計算にどんな特徴・違いがあるか 本来あるべき料金・ポイント計算ロジックの姿と、現状のギャップは何か（課題） 本来あるべき姿に向けて、現状からどう改善していくか という4ステップで考えて進めました。 前提）宿泊システムでの料金とポイント計算 ホテル、旅館の宿泊料金は以下のように決まっています。 ホテル・旅館 部屋タイプ 宿泊プラン 宿泊日 この4つの要素の組み合わせごとに料金が設定されています。 ホテル・旅館 部屋タイプ プラン 宿泊日 料金 補足 ホテルA スタンダードツイン 朝食付きプラン 2025/12/11 25,000 ホテルA スタンダードツイン 朝食付きプラン 2025/12/12 30,000 ホテルA スタンダードツイン 朝食付きプラン 2025/12/13 40,000 同じ内容でも日付ごとに料金が異なる（土曜は高い） ホテルA スタンダードツイン 朝食付きプラン 2025/12/14 25,000 ホテルA スタンダードツイン 朝食付きプラン 2025/12/15 20,000 ホテルA デラックスダブル 素泊まりプラン 2025/12/11 - 料金が設定されていない日もある ホテルA デラックスダブル 素泊まりプラン 2025/12/13 60,000 こんなイメージです。 また、ポイント計算は以下のような要素が絡んできます。 ユーザーの会員ランク（会員ランクによってポイント付与率が変わる） ポイントアップキャンペーン（期間限定でポイント付与率が変わる） クーポン利用（クーポン利用時の割引額を考慮する必要がある） 一休.com宿泊では「予約で付与されるポイントを、その場で使える（ポイント即時割引）」という機能があるため、ユーザーには 元の宿泊料金（値引き前） 即時割引のポイント数（ポイント付与率） 実際に支払う料金（値引き後） の3つをわかりやすく表示する必要があります。 ユーザーに表示する料金の例 1. 料金・ポイント計算をどんな業務で使っているか 初手として、各システムが料金・ポイント計算処理をどこで、どんな業務で使っているかを整理しました。 (a) 検索を高速に行うためのデータ作成・更新業務 後続の検索業務に必要なホテル・旅館の料金を確定するために必要な情報を非正規化して作成・更新する *1 (b) 検索業務 ユーザーが指定する条件に合わせて予約可能なホテル、旅館や宿泊プランを抽出して画面に表示する (c) 社内でのマーケティング用途向けのデータ作成・更新業務 社内でのデータ分析業務に必要な宿泊プランの料金情報を作成・更新する ユーザーに送る販促メールなどに掲載する宿泊プランの料金を計算する (d) 予約業務 最終的にユーザーが選択した宿泊プランのリアルタイムな料金を計算し、予約を確定する (e) ポイント、クーポンなどの割引計算業務 検索、予約どちらでも、指定条件に対して適用できるポイント、クーポンを抽出・計算する などです。 2. 料金・ポイント計算各業務の特徴と違い 1の整理を踏まえて、各業務での料金・ポイント計算にどんな特徴があるかを見ていきました。 結果として以下のような違い（特徴）があることがわかりました。 情報の鮮度に関する違い ある程度の精度・鮮度で料金を計算できればよい業務（検索） リアルタイムに正確な料金を計算する必要がある業務（予約） 扱うデータ量の違い 大量の宿泊プランのデータを一括で処理する業務（検索用データ作成・更新、マーケティング用途向けデータ作成・更新） 指定の条件にあった宿泊プランをリアルタイムに処理する業務（予約） 必要な情報の違い 検索では指定条件でトータルのポイント付与率、ポイント数がわかればよい 予約ではプロモーション単位でポイント付与率、ポイント数がわかる必要がある これを抽象的に捉えると バッチ処理として大量のデータを一括で処理する業務 リアルタイムに個別のデータを処理する業務 の2つに大別できることがわかりました。 また、各業務を整理する中で「料金」と呼んでいるものが複数存在していて、呼び名が統一できていないこともわかりました。 宿泊料金（ホテル・旅館が設定した基本料金） ポイント値引き後の料金 クーポン・ポイント値引きなど、すべての割引を適用した後の最終的な支払料金 などです。これについては、料金の種類を整理してどこでどの料金を使う必要があるのかをまとめました。 3. 本来あるべき料金・ポイント計算ロジックの姿と、現状のギャップは何か（課題） 次のステップとして、それまでの整理をもとに、現状の課題を洗い出して本来あるべき姿を検討しながら、取り組む課題を明確にしていきました。 課題: 宿泊サービスの中で、料金・ポイント計算ロジックが複数のシステムに分散して存在している 長くサービスを運用しているため、新旧それぞれのシステムで料金・ポイント計算ロジックが実装されている状態になっている システム移行の過程では避けられない側面もあります 一方で、新しいシステムの中でもロジックは共有しきれておらず、用途によって分けたシステムごとにロジックが分散している状態になっている 検索用のインデックスデータとマーケティング用データの作成・更新処理がサブシステムに分かれており、ロジックが共有できていない 等 これに対して、本来あるべき姿は、料金・ポイント計算ロジックは1箇所に集約し、各システムから共通で利用できる形にすることと考えて、ロジックの集約に向けた取り組みを行うことにしました。 4. 本来あるべき姿に向けて、現状からどう改善していくか 課題を踏まえて、本来あるべき姿に向けてどう改善していくかを検討しました。 改善のステップとして、以下を考えて進めています。 新システム内でのロジック集約・共通化 ステップ1: バッチ処理として大量のデータを一括で処理する業務内でロジックを集約・共通化 ステップ2: リアルタイムに個別のデータを処理する業務内も含めてロジックを集約・共通化 システム全体でのロジック集約・共通化 ステップ3（案）: 既存システムから新システムのロジックを呼び出し、システム全体でロジックを集約・共通化 現状と今後の展望 現在は、ステップ1として「バッチ処理として大量のデータを一括で処理する業務内でロジックを集約・共通化」を進めており、先に挙げた業務のうち (a) 検索を高速に行うためのデータ作成・更新業務 後続の検索業務に必要なホテル・旅館の料金を確定するために必要な情報を非正規化して作成・更新する (c) 社内でのマーケティング用途向けのデータ作成・更新業務 社内でのデータ分析業務に必要な宿泊プランの料金情報を作成・更新する ユーザーに送る販促メールなどに掲載する宿泊プランの料金を計算する の2つの業務を扱うバッチ処理に対して、1つの料金・ポイント計算ロジックを使う形に改善を進めています。今月ようやくプロトタイプが動くようになり、来年1月頃のリリースを目指して進行中です。 リリース後は引き続き、ステップ2を進めていく予定です。 まとめ 今回は、一休.com宿泊で進めている「宿泊料金・ポイント計算処理の改善」という取り組みについて紹介しました。個人的な所感として、既存システムの現状・課題を整理したことで まだその業務を十分に知らないメンバーが理解するために役立った ほかのサービスで同様の課題を考える際に参考になった といった出来事があり、宿泊システムの改善を考える以外の面でもプラスの効果があったと感じています。 おわりに 一休では、事業の成果をともに目指しつつ、システムの改善も進めていく仲間を募集しています。 www.ikyu.co.jp まずはカジュアル面談からお気軽にご応募ください! https://hrmos.co/pages/ikyu/jobs/1745000651779629061 hrmos.co 明日は @rotomx の「一休の情シス / コーポレートIT 2025」です。お楽しみに! *1 : 一休宿泊では、ユーザーが指定した条件で検索結果を素早く表示する必要があるため、Solr（検索エンジン）に必要な情報をインデックスしています

こんにちは。検索領域でエンジニアをやっております、shinpeiです。 本記事は 連載企画：メルカリ初の世界共通アプリ「メルカリ グローバルアプリ」の開発舞台裏 の一環として、メルカリグローバルアプリの検索バックエンドをスクラッチで開発することに伴い、大事にした設計のポイントをご紹介します。また今回の新たな要求を契機に既存の検索基盤の拡充が必要だったのでそれについても書かせていただきました。 グローバルアプリでの検索の要件と課題 先日、弊社からの発表の通り、メルカリはグローバルアプリの提供を開始しました。これに合わせて、検索もグローバルな検索を作るべく準備をすすめてきました。 グローバル展開にむけたアプリと基盤の再構築 で紹介したようにグローバルアプリを提供するにあたりバックエンド基盤の再構築を行っています。基盤を活かしながら必要な部分は新しく作り直すアプローチをとっており、検索バックエンドもそれに合わせて再設計を行いました。最低要件は、3年で50カ国展開。出品数は累計40億です（2025年9月時点）。日本事業（日本のお客さま向けメルカリアプリ）の検索との違いは複数ありますが、主なものは以下です。 複数国展開をするための多言語対応 検索対象として、アイテムモデルとプロダクトモデルとの両立 越境事業においてフォーカスしていく際のエンタメホビー領域に特化できるような独自の検索結果チューニング 1.は日本語以外を扱うための要件です。世界展開となれば、言語の壁は避けては通れない課題です。全文検索はそれぞれの言語自体を処理する必要があります。中国語のクエリ、英語のクエリ、フランス語のクエリ。これらを商品情報とマッチさせる必要があります。現在は日本で出品された日本語の商品をメインに扱っていますが、長期的には日本語以外の商品を扱う可能性も考慮する必要がありました。 2.は検索エンジンで検索対象として扱うデータモデルの話です。アイテムとは、現在のメルカリの主流である、単一の商品が検索対象となるようなデータモデルです。一方、プロダクトモデルとは、一つの検索対象だけど、例えば色違い（バリアント）が複数存在させることができるようなデータモデルです。C2Cの商品はアイテムモデルで対応できるのですが、B2Cの商品の一部はバリアントを持つため、プロダクトモデルが必要になります。メルカリはC2Cマーケットプレイスとしてスタートしたため、日本事業の検索では今もなお、アイテムモデルで動いていますが、グローバルアプリではアイテム、プロダクト双方を同等に扱える必要があります。 3.はグローバルアプリは検索結果を独立してコントロールしたいという意味です。グローバル展開を考えたときに国ごとのチューニングや事業の方向性に合わせた柔軟性が必要になります。例えば、クエリを自分たちで組み立てて、自由に検索結果をチューニングもできるように作る必要があります 。検索は日本事業と越境事業両方で重要な機能であり、開発の優先度やリソースなどい違いに影響を受けないようにすることも重要です。 Vertex AI Search for Commerce の採用 日本事業の検索ではElasticsearchを使っています。グローバルアプリでは日本にある商品全体を扱う予定だったので、売上に比べてデータ量が桁違いに大きい状態です。売上とコストを両立させるにはElasticsearchの再利用くらいしか思いつきませんでしたが、多言語対応や独立性の確保、リリースまでの時間と開発リソースを考えると、どうしてもその前の交通整理に長い時間がかかります。どうやるか思案していた時に、思いがけず案に上がってきたのがGoogleが提供してるVertex AI Search for Commerce（以下、VAIS:C)です。今回の例では以下の点で魅力的でした。 フルマネージドな小売サイト向け検索サービス リクエストベースの課金モデル（トラフィックがなければ課金されない） 多言語対応あり 入力するデータはプロダクトモデル（バリアントあり） ある程度の検索結果チューニングが可能 ユーザーイベントベースの検索結果最適化あり グローバルエンドポイント（世界中から使える） これだ！と思いました。要件とVAIS:Cができることを見比べていただければわかりますが、グローバルアプリにとって必要な要求をほぼ満たしており、ネックなのはコストだけです。そこで我々が立てた戦略は以下です。 VAIS:Cを導入し、素早くスモールスタートする トラフィックが伸びてきて、ペイできないレベルになれば、Elasticsearchに切り替える この方法であれば、Elasticsearch側をグローバルアプリに適用するために必要な準備期間も稼げると思いました。一方で、ビジネス側の懸念は現在の日本事業の検索と、同様の売り上げを得る検索結果をだすことができるかどうか、でした。そこはやってみなければわからなかったので、A/Bテストを行うことになりました。 簡単にVAIS:Cを説明しますと、商品情報と、ユーザーイベントを入れると、最適な検索結果が返ってくるというものです。最適化に必要となるユーザーイベントは、Google Analytics 4(以下、GA4)で収集したものが前提となってましたが、スキーマさえ合わせれば独自イベントの入力も可能でした。メルカリはGA4ではなく、独自のイベント基盤を持っているため、なんとか変換して動かしました。（Google Cloud Japanの皆様には多大なるご協力をいただきまして、大変お世話になりました。） 結果的には、我々の商品情報と、なんとか変換したユーザーイベントでは、日本事業の検索よりも結果が劣ることを確認できました。また、後述するいくつかの要件を満たすことが難しいこともわかりました。ですが、このリスクを補ってあまるメリットがあるのも事実です。（これを全部、私一人でできてるのですから！）検索エンジンが変わることでのリスクは合意した上で、グローバルアプリの初期リリースはVAIS:Cで行う、と決めました。 新しい検索バックエンドの設計 検索エンジンの目処が立ったので、次はバックエンドの話です。ここでは、特にこだわった点をご紹介します。 私は7年前、現在の日本事業の検索システムの設計にも関わっていました。当時は理想や期待を込めて設計しましたが、実際に運用を続ける中で「これは設計から見直した方がいい」と感じる部分も多く、今回はそれらを改善する形にしています。 データモデルに依存したAPI データを取得するタイプのインターフェースは”どんなデータ”を対象とするかでガラッと設計が変わります。汎用的になものを作ろうとすると、抽象化が進みすぎて、余計わかりにくくなってしまいがちです。対象が無限に増えるわけではないので、汎用化はせずに、たとえばProductをSearchするためのエンドポイント、というふうに割り切りました。Productのデータモデルは決まっています。タイトルがあって、商品の説明があって、値段があって、、、と、どこに行っても同じです。 柔軟な処理を可能にするプラグイン機構 ElasticsearchやSolrなどにもあるように、検索クエリや結果に対して独自の処理を加えたいというニーズはどの検索システムにもあります。日本事業の検索開発でも、これまで多くの条件分岐（if文）がコードに埋め込まれ、整理が難しくなっていました。そこで、今回のグローバルアプリ向け検索バックエンドでは、クエリの前処理・後処理をフックできるプラグイン機構を導入しています。検索機能の開発者は、必要な処理をプラグインとして追加するだけで拡張が可能です。多くのソフトウェアでも似たような仕組みが使われていますが、結局この方法に行き着くよな、という実感があります。 検索エンジン機能の実装と抽象をわける 基本的なロジックは抽象層にまとめ、実装部分は切り替え可能な構成にしています。もともと、VAIS:CとElasticsearchの両方で動く必要がありましたが、この要件がなくても同じ設計にしたと思います。というのも、検索エンジンの世界はまさに“戦国時代”で、Vector検索に強い新しいエンジンなど、次々と登場しています。現在はElasticsearchを使っていますが、将来的に他の選択肢が有力になる可能性もあります。このため、抽象化しておくことで、後々の移行や比較コストを大きく減らせると考えてます。 その他 グローバルアプリでは、もともとバックエンド全体に関する設計方針が明確にあります ( グローバル展開を支える基盤の裏側 を参照)。このおかげで、何がどこにあるかが、ある程度明確になってます。特に大事だと思うのは、BFFの切り分けです。BFFはここにあるよ（逆にいうと、ここにしかないよ）というのは、見る箇所が限定できるので探索のコストが減るのです。これまでのマイクロサービスでは、どこの誰が検索APIを叩いて、それをお客さまに出しているかをこちらから把握するのは困難でした。検索バックエンドでも、ドメイン特化のノウハウがあります。何をどこに実装するかを明確に提示してるのは新しい検索バックエンドの特徴です。バックエンド全体の設計でも、期せずして同じようなことをしているのは、これまでの苦痛が似ているからだと思います。だれでもなんでもどこにでも作れるというのは、メンテナンスコストを上げる結果になっているという経験則だと思います。 プロダクトオーナーからの想定外の要求で冷や汗 最初はVAIS:Cを使うとはいえ、長期的にはElasticsearchに切り替えなければなりません。私はこれまで、Elasticsearch as a Service (以下、EaaS) という、 ECK などをベースに作った社内のElasticsearchホスト基盤を開発＆運用してきました。チームの活躍で、グループ内のほぼすべての検索サービスはEaaSの上で動いてると言えるところまで来ています。関連するエコシステムも充実させてきました。カスタマイズ性も高く、実際、メルカリの複数のビジネスで使われていることがその証左です。グローバルアプリの準備期間中、責任者である@Suwenさんと直接話す機会が多く、EaaSはなんでもできるので安心してください、と伝えてました。そこで何度もフィードバックされたのが、以下のような点です。 「日本事業のこの検索機能、グローバルアプリでも使いたいな」「日本事業のこの機能、グローバルアプリだったらこういうふうにカスタマイズしたらいいよね」 さぁ、ここで私の過去の記事を読んでいただけたみなさまなら、私が冷や汗を流した理由がおわかりですね？EaaSは、Elasticsearchの提供が主であり、その上に作られた機能の再利用までは責任を持っていません。もちろん、プラットフォームとして、機能の再利用性を無視していたわけじゃありません。Elasticsearchにはプラグイン機構があり、実際にそのプラグインを用いた機能なら再利用できます。しかしメルカリではJavaエンジニアは少数派で、Elasticsearchプラグインの開発はほぼ進みませんでした。機能のほぼ全てはGoのマイクロサービスに作り込まれています。以下に、課題感を説明するのに使ったスライドの一部を晒します。日本事業の作り込んだ検索機能資産が使いたいけど、使えないという状態です。 実はこの問題は以前にもぶつかってました。広告事業からも、EaaSを使ってもらっていたのですが、ビジネス側からの期待値は、EaaSを使えば、日本事業の検索と同じクオリティの検索結果がでてくると思われていたのです。実際には、EaaSは日本事業の検索と同じ検索結果を提供するわけではないので、この時は日本向けに作られたシノニムや日本語形態素解析などのライブラリを広告チームのバックエンドから再利用してもらう形で落ち着きました。この頃にスライドを書き、日本の検索チームへ、Goで作られた検索機能の再利用性を高めるべきだとの問題提起はしてきました。が、当時の日本事業の優先度的には、再利用性にリソースを割いてもらうことはなかなか難しかったのです。 All for oneで検索基盤の拡充へ 私はここからは迷走しました。日本事業の開発や優先度を邪魔しない範囲で、なんとか機能の再利用化を進める案を捻り出そうとしました。一時は、必要な機能をElasticsearchプラグインで書き直すか、とまで考えていました。ここで肝となった問題点を整理します。 EaaSは最初から複数事業での利用を見据えた設計であるが、その上に作った日本事業の検索サービスは日本事業に強く結合しているため、他事業からの再利用が困難である 日本事業の検索は7年運用してきたコードベースであり、前述のとおり、うまく整理されていないなどの負債がある 日本事業の検索は引き続き重要であり、このコードベース自体を再利用できるように改変しつつ、日本事業向けの開発を同時並行するのは困難 グローバルアプリの技術責任者である@deeeeetとも議論を重ねて、以下のような案を出しました。いまあるEaaSの上に、再利用可能な機能を一個ずつ切り出して使用するというものです。 日本事業側にも問題と案を再掲示し、議論を重ねました。最終的に、グローバルアプリの優先度が上がったこともあり、日本事業側からも積極的に動いてくれて、日本事業の検索機能を再利用するための新しい層を作ることが決まりました。この層に関しては、主導権があるわけではないので、私からはEaaSというプラットフォームが大事にしているところをなるべく共有して、いまのところ共通した方針のもと一緒に作っています。具体的には以下です。 Platformがその下で使われてるオープンソースソフトウェアに必要以上の制約を加えないこと ここでいうオープンソースソフトウェアとは、我々の場合はElasticsearchです。Elasticsearchには我々がただ使ってないだけで、まだまだたくさんの可能性があります。これを現時点では使わないからという理由で上のプラットフォームを経由すると使えなくなるのは本末転倒だと思ってます。実はここは議論になりやすい点で、制約を加えた方が不可測事態が避けられて、メンテが楽になるという話もありますので、慎重な説得と周りの理解が必要です。 各ビジネスドメインから独立して使えること 共通基盤を作って、それを複数のオーナーから利用する時に問題になるのは機能の開発優先度だと思います。事業Aは規模が小さいから後回し。事業Bのオーナーは発言力があるから、優先。。などなど、いわゆる”政治”になりやすいところだと思います。完全な独立は不可能ですが、これをなるべく避けるためには、基盤への開発が開かれていることが重要です。開かれていると言っても、自由に作れるとはまた違います。ブログの前段で説明した通り、どこでもだれでもいじれると収拾がつかなくなってしまいます。それを解決する一つの手はプラグイン機構です。どこをどうフックするかはまだまだ議論していく必要があるのですが、基本的な方針に関しては同意できています。 こうして、現在のグローバルアプリの検索は、VAIS:CとEaaSの上に作られた新しい仕組みとのハイブリッドで稼働しています。 まとめ 今回はグローバルアプリでの新たな検索要求に対してどのような方針で対処したのかについて書かせていただきました。従来の日本事業の検索とは毛色の違う要求をこなすために、フルマネージドの検索サービスである、VAIS:Cを一時的に導入しました。また、グローバルアプリの開発要求を起点に議論が広がり、社内検索基盤を拡充させることで、今後の要求についても対処できるように基盤を作っていることについても触れさせていただきました。具体的な多言語対応方法など、今回、書ききれなかった部分もあるので、また次回以降でご紹介できればいいなと思ってます。 参考 ”メルカリの検索基盤の変遷について” https://engineering.mercari.com/blog/entry/20220207-776318b784/ 月間2000万人が使う　メルカリ検索機能のアーキテクチャ https://findy-tools.io/articles/mercari-elasticsearch/38

急速に変化し競争が激化する製造業界において、組織は製品開発プロセスを加速および最適化するために、エンジニアリングシミュレーションなどの仮想エンジニアリングワークフローの採用を増やし続けています。性能、コスト、信頼性、製造性、組立性などの主要な性能指標を評価するための複雑な設計研究への需要が高まる中、シミュレーションプロセス・データ管理（SPDM）は、組織がシミュレーションデータを製品ライフサイクル管理（PLM）システムに管理および統合できるようにすると同時に、製品設計者、シミュレーションアナリスト、製造エンジニアを含む機能横断的なチーム間の相互作用とコラボレーションを促進する重要な記録システムになりつつあります。ただし、世界中に分散しているエンジニアリングチームの性質に対処し、インフラストラクチャコストを管理し、柔軟なデータ移動を実現するには、SPDM 導入の近代化が不可欠です。このブログでは、お客様の製品エンジニアリング変革をサポートするために、Amazon Web Services（AWS）クラウドインフラストラクチャを活用して、費用対効果が高く、安全でスケーラブルな SPDMを構築する方法について説明します。 シミュレーションデータ管理とインフラストラクチャ制約の課題 さまざまな市場への対応が求められることによって、あらゆる業界が製品の複雑化に直面しており、その結果、製品のバリエーションや構成が多様化しています。計算流体力学（CFD）や有限要素解析（FEA）などのデジタルエンジニアリングシミュレーションは、製品の複雑性を管理し、効率的な製品開発を実現するために不可欠であると広く認識されていますが、シミュレーションプロセス自体が大きなボトルネックになることがよくあります。分析チームは、バージョン管理が適切でない古いデータや、結果の提供が遅すぎて設計の方向性に影響を与えられないようなデータを扱うことがよくあります。分野の専門家は、相関作業を行う際に、物理テストとシミュレーションのデータセットを一致させるのに苦労することがよくあります。コンピュータ支援エンジニアリング（CAE）の結果はアナリストの支援がないと閲覧できないため、プログラムマネージャーは多くの場合、可視性に乏しく、洞察を得ることができません。重要なのは、設計者やアナリストが不在の場合、適切なデータに適切なタイミングでアクセスして、情報に基づいたビジネス上の意思決定を行うことが制限要因になるということです。さらに、設計バリエーションの数と実行される関連シミュレーションの数が指数関数的に増加するにつれて、チームが生成する膨大な量のデータで行き詰まる危険性があります。 従来のオンプレミス環境では、最新のセキュリティ標準への対応が困難で、スケーラビリティが限られ、インフラストラクチャコストが高額になるため、これらの問題がさらに悪化します。このような(オンプレミス)環境では容量が固定されており、多くの場合、シミュレーションのニーズに応じてコンピューティングリソースを迅速に拡張できないため、プロジェクトが遅れる可能性があります。さらに、多くの場合、堅牢なディザスタリカバリおよびバックアップ機能が不足しており、システム障害が発生した場合にデータや運用を迅速に復元することが困難です。 Teamcenter Simulation Teamcenter Simulation は、エンジニアリングワークフローに携わるエンジニアやアナリスト向けに設計されたシミュレーションプロセス・データ管理（SPDM）ソリューションです。 Siemens Xcelerator ビジネスソフトウェアプラットフォーム内の製品ライフサイクル管理（PLM）ソリューションであるTeamcenterを基盤とするこのツールは、シミュレーションと物理試験のプロセス、データ、ツール、ワークフローを包括的に管理できます。既存の製品データとシームレスに統合し、すべての関係者に完全なトレーサビリティと可視性を提供します。Teamcenter Simulationを利用することで、エンジニアリングチームはデジタルスレッド全体で効果的に共同作業を行うことができ、一貫性のある効率的な製品開発プロセスを実現できます。 シミュレーションと製品データの連携 シミュレーションデータ管理の課題に対処するには、製造会社はシミュレーション業務をPLM戦略全体の重要な要素として管理する必要があります。Teamcenter Simulationを使用すると、組織はエンジニアリングシミュレーションのデータとプロセスをより適切に管理、理解、再利用できるようになり、製品開発ライフサイクル全体にわたる制御と効率性が向上します。Teamcenter SimulationはTeamcenterプラットフォームに不可欠なモジュールであるため、コンピューター支援設計（CAD）、材料データ、製品パラメーター、製品要件など、シミュレーションに関連するすべてのデータを製品データと関連付けて管理できます。AWS上のTeamcenterを使用することで、組織全体の信頼できる唯一の情報源を確保し、シミュレーションアクティビティを組織のデジタルスレッドに接続できます。この接続は、モデルベースシステムエンジニアリング (MBSE) やモデルベーステスト (MBT) の導入など、企業レベルのデジタルスレッド構想を実現するために不可欠です。デジタルスレッドにより、シミュレーションチームは最新の製品データをシミュレーションの入力として使用し、すべての意思決定者と利害関係者が主要なシミュレーション結果に簡単にアクセスできるようにすることで、製品ライフサイクルを完全にサポートできます。 AWS 上の Teamcenter Simulation による組織的メリット AWS上のTeamcenter Simulationは、お客様のSPDMプロセスとインフラストラクチャのニーズに合わせてカスタマイズできます。AWS のサービスは、スケーラブルなインフラストラクチャとストリーミングサービス、運用コストの削減、従来のオンプレミス環境を上回る堅牢なセキュリティと信頼性により、Teamcenter Simulation インフラストラクチャの課題を克服するのに役立ちます。次のセクションでは、  Well-Architected Framework の原則に基づいて、AWS上にTeamcenterを展開するメリットについて詳しく説明します。 セキュリティの向上 : オンプレミスのTeamcenter実装を管理している組織は、多額のコストと従業員のスキルセットギャップにより、現在のセキュリティプロトコルと暗号化標準を維持する上で課題に直面することがよくあります。さらに、これらの組織は進化する基準へのコンプライアンスを保証する責任を負っており、これはAWS の継続的に更新されるインフラストラクチャが本質的に提供する堅牢なセキュリティおよびコンプライアンス認証と比較すると困難です。また、要件、部品表（BOM）、CADファイル、シミュレーション結果など、Teamcenterで管理される機密性の高い製品情報は、AWSサービスを使用して保存時と転送中の両方で暗号化できます。これにより、重要な製品データの機密性、一貫性、整合性が保証されます。 信頼性の向上 :  AWSリージョン内の複数の アベイラビリティーゾーン により、高可用性とデータレプリケーションが確保されます。Teamcenter Simulationを高可用性アーキテクチャで導入することで、企業は個別のハードウェア障害とデータセンター停止の両方から保護され、重要なPLMデータとプロセスへの継続的なアクセスを確保できます。さらに、AWS のグローバルなリージョンネットワークにより、組織はクロスリージョンレプリケーションによる災害復旧戦略を実装でき、事業継続性をさらに強化し、企業の厳しい稼働時間要件を満たすことができます。対照的に、オンプレミス環境では、ハードウェア障害、停電、拡張性の制限といった脆弱性により、このレベルの信頼性に欠けることが多く、深刻なダウンタイムやデータ損失につながる可能性があります。 コスト最適化 : TeamcenterをAWS上に展開することで、お客様はオンプレミスインフラストラクチャに関連する初期投資を回避できます。その代わり、コンピューティング、ストレージ、ストリーミング、データ処理 (ML と Analytics)、およびその他の使用したリソースに対してのみ料金を支払います。この従量課金モデルは、特にワークロードが変動する組織では、必要に応じてリソースをスケールアップまたはスケールダウンできるため、大幅なコスト削減につながります。企業は AppStream 2.0 サービスを活用して、シミュレーションソフトウェアと統合されたTeamcenter Simulationクライアントをストリーミングできます。このアプローチにより、エンジニアが高価なローカルワークステーションを所有する必要がなくなり、エンドユーザーのITハードウェアとソフトウェアの管理が簡素化されます。 パフォーマンス効率 : お客様は、TeamcenterとCAEアプリケーションの両方に対してカスタマイズされたコンピューティング構成とGPU設定を通じて性能を最適化することができます。CAEシミュレーションでは、効率的な実行と結果取得時間の短縮のために多大な計算能力が必要となるため、オーバープロビジョニングすることなく、必要に応じてコンピューティングリソースをスケールアップまたはスケールダウンし、最適なパフォーマンスを確保することが重要です。 運用効率 : AppStream 2.0では、TeamcenterおよびSimulationアプリケーションを事前構成したカスタムイメージを作成できるため、IT組織はエンドユーザー環境を効率的に管理できます。さらに、 Amazon Relational Database Service for Oracle や FSx for NetApp ONTAP などのマネージドサービスは、データベースとファイルシステムの管理をオフロードします。これにより、組織はITインフラストラクチャとプロセスが合理化され、Teamcenterの管理者はコアアプリケーション管理に集中できるようになります。 AWS 上の Teamcenter Simulation アーキテクチャ AWS では、ウェブサーバー、エンタープライズサーバー、FMS サーバー、ビジュアライゼーション、および Solr サーバーを、異なるアベイラビリティーゾーンの複数の Amazon EC2 インスタンスに分散させることで、Teamcenter を高可用性アーキテクチャで実装できます。このセットアップでは、Amazon RDS for Oracleをフルマネージド型の商用データベースとして使用し、Teamcenter ボリュームストレージは FSx for NetApp ONTAP または Amazon EFS を使用してプロビジョニングされます。このアーキテクチャの中心的な要素は、マネージドストリーミングサービスであるAmazon AppStream 2.0の統合です。これにより、Teamcenter Simulationクライアントをシミュレーションソフトウェアに統合して配信できます。AppStream 2.0 は、高性能な NVIDIA GPU 搭載インスタンス (グラフィックス G4dn、G5、Graphics Pro ファミリーなど) を活用して、シミュレーションワークロードに必要な高度な可視化ニーズをサポートします。 図1 : Siemens Teamcenter Simulation アーキテクチャ AWS Marketplace Siemens Xceleratorのソフトウェアとソリューションのポートフォリオへのシームレスなアクセスは、日々のシミュレーションワークフローにシミュレーションプロセスとデータ管理をうまく実装するために不可欠です。AWS Marketplace では、Siemens Xcelerator 製品の購入を含め、お客様が AWS 上で動作するソフトウェアの発見、導入、管理をより簡単に行うことができます。AWS Marketplace が提供する柔軟な価格体系と透明性の高い請求システムにより、IT 管理者はソフトウェアの消費を効率的に監視し、コスト管理を維持できます。AWS Marketplace でSiemensのソフトウェアを購入するメリットをより包括的に理解するには、Siemensのブログ「 AWS Marketplace がクラウドでの購入体験をどのように変えるか 」を参照してください。 まとめ Teamcenter Simulation はお客様のAWS環境にデプロイすることも、AWS上のTeamcenter Xを介してSaaSソリューションとして導入することもできます。Teamcenter Simulation ソフトウェアをAWSに展開することで、インフラストラクチャコストの削減、コラボレーションの強化、データトレーサビリティ、データ整合性の向上、SPDM実装の最新化など、様々なメリットがあります。AWS のクラウドネイティブサービスを利用することで、組織は Well-Architected SPDM ソリューションを構築し、製品ライフサイクルを管理するための安全でスケーラブルで高性能な基盤を提供できます。 AWS Marketplace   は、Siemens Digital Industries Softwareのソリューションを幅広く提供しています。AWS Marketplace で入手可能なSiemens製品の全リストをご覧ください。また、AWS とシーメンスのコラボレーションの詳細については、公式 パートナーシップウェブサイト をご覧ください。 このブログにご協力いただいた以下の方々にも心より感謝申し上げます。 ·       Noah Jackson (AWS グローバル EUC ソリューションアーキテクト) ·       Indrakanti Chakravarthy（Siemens 戦略プログラムマーケティングディレクター） Chandan Murthy Chandan Murthy は AWS でシニアパートナーソリューションアーキテクトを務め、AWS の戦略的パートナーが AWS プラットフォーム上で非常に効率的でスケーラブルなソリューションを設計および構築できるよう支援することに専念しています。20 年の経験を持つ Chandan は、Teamcenter や Mendix などのプラットフォームでの技術ソリューション設計の確固たる基盤を持っています。この専門知識と AWS での職務により、AWS のお客様が PLM やローコード産業用ソリューションを AWS に実装できるよう支援しています。 Vedanth Srinivasan Vedanth Srinivasan は、アマゾンウェブサービスのエンジニアリング&デザインおよび市場開拓 (GTM) 向けソリューションの責任者です。業界横断型ソリューションに重点を置いているのは、ハイパフォーマンスコンピューティング (HPC) や製品ライフサイクル管理 (PLM) などのコンピュータ支援エンジニアリング (CAE)、製品ライフサイクル管理 (PLM) のほか、モデルベースシステムエンジニアリング (MBSE)、デジタルスレッド、デジタルツインソリューションなどの高次ワークロードです。自動車、航空宇宙、防衛、石油・ガス、ヘルスケア業界にわたる高度なエンジニアリング・ワークフローの開発と展開において 20 年以上の経験があります。 Wouter Dehandschutter, PhD Wouter は、シーメンス・インダストリー・ソフトウェアのテクニカル・プロダクト・マネジメント・ディレクターであり、シーメンスのシミュレーション・プロセスおよびデータ管理（SPDM）の戦略とロードマップを担当しています。ベルギーのルーベン大学でメカトロニクス・エンジニアとして卒業し、ルーベン大学で博士号を取得しました。Lernout & Hauspie や、後にシーメンス・インダストリー・ソフトウェアに買収された LMS International で職務を歴任しました。シーメンスでは、耐久性試験と解析、試験データ管理、メカトロニクス・システム・シミュレーションとシミュレーション・モデル管理のためのCAEアプリケーションの製品開発と製品管理で複数の役職を歴任してきました。現在、Wouter は Teamcenter Simulation の製品ロードマップを管理し、製品ライフサイクルと密接に関連するシミュレーションプロセスとデータのマルチドメイン管理を行っています。 翻訳はソリューションアーキテクトの 山田航司 が担当しました。原文は こちら です。