G-gen の佐々木です。当記事では、Pub/Sub から直接 Vertex AI 上の AI モデルによる推論を取得することができる AI 推論 SMT 機能について解説します。 前提知識 Pub/Sub とは Single Message Transforms（SMTs） AI 推論 SMT の機能 基本事項 AI 推論 SMT の利点 使用できるモデル Model Garden で提供されているモデル Vertex AI Endpoints にデプロイしたモデル モデルの入力・出力 入力するメッセージの形式 推論後のメッセージの形式 制限事項 設定手順 手順の概要 サービスアカウントの作成・権限付与 定義ファイルの作成 トピックの作成 AI 推論 SMT を使用するサブスクリプションの作成 動作確認 メッセージのパブリッシュ メッセージの受信 前提知識 Pub/Sub とは Pub/Sub は Google Cloud におけるフルマネージドなメッセージングサービスです。 メッセージングサービスは、システム間に配置することでメッセージを非同期に中継することができます。これにより、システムの拡張性や保守性を向上することができます。 Pub/Sub を始めとしたメッセージングサービスの詳細やユースケースについては、以下の記事をご一読ください。 blog.g-gen.co.jp Single Message Transforms（SMTs） Single Message Transforms （以下、 SMTs ）は Pub/Sub を使用したストリーミング処理のパイプラインにおいて単純なデータ変換を実現する機能です。 この機能では、Pub/Sub のトピックとサブスクリプションのそれぞれに対して単純なデータ変換処理を実装します。これにより、データの形式の変換やマスキング、フィルタリングなどの処理を、メッセージの配信前に行うことができます。 SMTs の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp AI 推論 SMT の機能 基本事項 当記事で紹介する AI 推論 SMT （AI Inference Single Method Transform）は、SMTs の機能の1つであり、Vertex AI にある AI モデル（Gemini など）に Pub/Sub のメッセージを渡し、 推論を取得してメッセージに追加することができる 機能です。 通常の SMTs 同様に、AI 推論 SMT はトピックとサブスクリプションのどちらでも設定することができます。 トピックに設定した場合、推論結果がメッセージに追加されたあと、トピックに紐づくすべてのサブスクリプションにメッセージが配信されます。 トピックに対して AI 推論 SMT を設定した場合 サブスクリプションに設定した場合は、そのサブスクリプションでのみ推論を取得するような動作となります。Pub/Sub のユースケースに合わせて設定するとよいでしょう。 サブスクリプションに対して AI 推論 SMT を設定した場合 参考 : AI 推論 SMT 参考 : 単一メッセージ変換（SMT）の概要 - SMT のサンプル メッセージ フロー AI 推論 SMT の利点 AI 推論 SMT を使用してモデル推論とデータ変換を行う場合、以下のようなメリットがあります。 メッセージに対してリアルタイムで AI モデルによる推論結果を追加することができる（データ エンリッチメント） モデルから推論を取得するための処理をアプリケーション側に実装する必要がなくなる サブスクリプションに設定した場合、Pub/Sub はモデル エンドポイントの過負荷を回避し推論のスループットを最大化するため、リクエストレートを最適化する（フロー制御） ※ 単項 pull では最適化されない点に注意 参考 : AI 推論 SMT - メッセージ フロー 使用できるモデル Model Garden で提供されているモデル AI 推論 SMT では、トピックまたはサブスクリプションを作成する際にモデルの推論用のエンドポイントを指定します。 Vertex AI Model Garden で提供されているモデルを使用する場合、以下のような形式でエンドポイントを指定します。 - ai - aiInference : endpoint : "projects/<プロジェクトID>/locations/<モデルを利用するリージョン>/publishers/<モデルのパブリッシャー>/models/<モデル名>" 使用できるモデルの一覧については、以下のドキュメントで最新の情報を確認してください。 参考 : AI 推論 SMT - 互換性のある MaaS モデル Vertex AI Endpoints にデプロイしたモデル ユーザーが Vertex AI Endpoints を使用して Google Cloud 上にデプロイしたモデル（セルフデプロイ モデル）を推論に使用することもできます。 セルフデプロイ モデルを使用する場合は、モデルのエンドポイントの指定の仕方が異なります。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/<エンドポイントのリージョン>/endpoints/<エンドポイント>" 参考 : エンドポイントにモデルをデプロイする モデルの入力・出力 入力するメッセージの形式 AI 推論 SMT による推論を行うためには、Pub/Sub に入力されるメッセージが特定の形式になっている必要があります。 例えば gemini-2.5-flash のような Gemini 基盤モデルを使用する場合、 Chat Completions API を使用して Gemini が呼び出されるため、以下のように Pub/Sub トピックに送信するメッセージの形式を API の仕様に合わせます。 { " model ":" google/gemini-2.5-flash ", " messages ": [ { " role ": " user ", " content ": " Explain how AI works in a few words " } ] } 参考 : AI 推論 SMT - メッセージ処理 推論後のメッセージの形式 AI 推論 SMT によって取得したモデルのレスポンスは、以下のように元のメッセージに追加されます。 { " original_message ": " <元のメッセージ> ", " model_output ": " <推論によって取得したモデルのレスポンス> " } 制限事項 AI 推論 SMT には以下のような制限事項があります。 トピックまたはサブスクリプションに設定できる AI 推論 SMT の数は1つまで Vertex AI Endpoints のプライベート エンドポイントはサポートされていない（公開エンドポイントのみ使用可） グローバル エンドポイントは、Gemini 基盤モデルでのみサポートされる。その他のモデルではリージョン エンドポイントのみ使用可能 Pub/Sub 側では入力されたメッセージのデータ形式などの検証は行われない。トピックにメッセージを送信する前に検証する必要がある 1つのメッセージごとに1つの推論リクエストのみが可能であり、バッチ推論は不可 指定したモデルによる推論は60秒以内に完了する必要がある 推論が60秒を超過するとタイムアウトとなり、Pub/Sub に設定したメッセージ保持期間と再試行回数の上限まで再試行が行われ、その後デッドレタートピックにメッセージが転送されます。 その他、制限事項に関する最新情報は以下のドキュメントをご一読ください。 参考 : AI 推論 SMT - 制限事項 設定手順 手順の概要 当記事で紹介する手順は、サブスクリプションに対して AI 推論 SMT によるメッセージ変換を設定し、そのサブスクリプションのコンシューマーに対してのみ推論結果を含めたメッセージを配信できるようにするためのものです。 参考 : AI 推論 SMT - AI 推論 SMT を作成する サービスアカウントの作成・権限付与 AI 推論 SMT を使用する場合、Cloud Pub/Sub サービスエージェント（ service-<プロジェクト番号>@gcp-sa-pubsub.iam.gserviceaccount.com ）に対して Vertex AI サービス エージェント （ roles/aiplatform.serviceAgent ）ロールを付与するか、カスタムサービスアカウントに対して Vertex AI ユーザー （ roles/aiplatform.user ）ロールを付与します。 当記事ではカスタムサービスアカウントを使用します。 # サブスクリプション用のサービスアカウントを作成 $ gcloud iam service-accounts create pubsub-ai-inference-smt \ --display-name =" Pub/Sub AI Inference SMT " # Vertex AI ユーザー ロールの付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" serviceAccount:pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " 定義ファイルの作成 ai-smt.yaml という名前で AI 推論 SMT の定義ファイルを作成します。これをトピックもしくはサブスクリプションの作成時に指定することで、AI 推論 SMT を使用することができます。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/asia-northeast1/publishers/google/models/gemini-2.5-flash" unstructuredInference : { parameters : { "temperature" : 0.5 , "max_tokens" : 1000 } } serviceAccountEmail : "pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com" endpoint にはモデルのエンドポイントを指定します。 unstructuredInference.parameters には、モデルに推論リクエストを送信する際のパラメータや最大トークン数などを指定できます。 serviceAccountEmail には、先ほど作成したサービスアカウントを指定します。 トピックの作成 Pub/Sub のトピックを作成します。 # トピックの作成 $ gcloud pubsub topics create ai-smt-topic トピックに AI 推論 SMT を設定する場合、ここで --message-transforms-file オプションを使用します。 参考 : gcloud pubsub topics create AI 推論 SMT を使用するサブスクリプションの作成 トピックに紐付けるサブスクリプションを作成します。 当記事ではサブスクリプション側に AI 推論 SMT によるメッセージ変換処理を設定するため、 --message-transforms-file で先ほど作成した定義ファイルを指定します。 # AI 推論 SMT を使用するサブスクリプションの作成 $ gcloud pubsub subscriptions create ai-smt-topic-sub \ --ack-deadline = 600 \ --topic ai-smt-topic \ --message-transforms-file ai-smt.yaml 動作確認 メッセージのパブリッシュ 作成したトピックに対してメッセージをパブリッシュしてみます。 AI 推論 SMT で Gemini モデルを指定しているため、 --message には、 Chat Completions API の仕様に合わせた形式でメッセージを設定します。 # プロンプトを含むメッセージのパブリッシュ $ gcloud pubsub topics publish ai-smt-topic --message =$' { "model":"google/gemini-2.5-flash","messages":[{ "role": "user", "content": "Vertex AI について簡単に説明して" }] } ' 参考 : gcloud pubsub topics publish メッセージの受信 サブスクリプションに配信されたメッセージを確認します。 # メッセージを受信し、データを復号したあと JSON に変換 $ gcloud pubsub subscriptions pull ai-smt-topic-sub \ --auto-ack \ --format =" value(message.data.decode(base64)) " | jq . 受信したメッセージには、元のメッセージである "original_message" に加え、サブスクリプション側の AI 推論 SMT によって "model_output" が含まれていることがわかります。 以下は受信したメッセージの例です。 { " model_output ": { " choices ": [ { " finish_reason ": " stop ", " index ": 0 , " logprobs ": null , " message ": { " content ": " Vertex AI は、Google Cloud が提供する、**機械学習（ML）開発のための統合プラットフォーム**です。 \n\n 簡単に言うと、MLモデルを開発する際に必要な「データの準備」「モデルの構築」「トレーニング」「デプロイ（公開）」「監視・管理」といった**あらゆる工程を、一つの場所で効率的に行えるようにするための「ワンストップショップ」**のようなものです。 \n\n **主なポイント：** \n\n 1. **統合された環境:** これまでバラバラだったML開発のツールやサービスを一つにまとめ、開発プロセスをシンプルにします。 \n 2. **効率化と高速化:** データサイエンティストやMLエンジニアが、インフラの管理に時間を取られることなく、モデルの開発や改善に集中できるよう設計されています。 \n 3. **幅広い対応:** カスタムモデルの構築はもちろん、画像認識や自然言語処理などの特定のタスクに対応した事前学習済みモデルの利用や、AutoML（自動機械学習）機能も提供します。 \n 4. **スケーラビリティ:** Googleの強力なインフラ上で動作するため、大規模なデータや複雑なモデルのトレーニングも柔軟に対応できます。 \n\n 例えるなら、ML開発に必要なあらゆる道具が揃った「高機能な作業台」のようなものです。これにより、企業はより迅速にMLをビジネスに導入し、価値を生み出すことができるようになります。 ", " role ": " assistant " } } ] , " created ": 1775550770 , " id ": " MsHUaYLcFaKTp_QP1_SwiAw ", " model ": " google/gemini-2.5-flash ", " object ": " chat.completion ", " system_fingerprint ": "", " usage ": { " completion_tokens ": 263 , " completion_tokens_details ": { " reasoning_tokens ": 1066 } , " extra_properties ": { " google ": { " traffic_type ": " ON_DEMAND " } } , " prompt_tokens ": 6 , " total_tokens ": 1335 } } , " original_message ": { " messages ": [ { " content ": " Vertex AI について簡単に説明して ", " role ": " user " } ] , " model ": " google/gemini-2.5-flash " } } 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

Introduction and Summary Hi, I'm Iwamoto. Last month, I had the opportunity to write an introductory post as the group manager of the My route Development Group. As it happens, I also serve as the manager of the Mobile App Development Group. In this article, I'd like to introduce the group and share a bit about how I came to manage both. About the Mobile App Development Group What is the Mobile App Development Group? Formed in early 2022, the Mobile App Development Group is a relatively new team made up of engineers who, as the name implies, specialize in mobile app development. With pride as a mobile app development specialist, we take full ownership of all mobile app projects involving KINTO Technologies, transcending the boundaries between individual services. Basically, we create mobile apps in collaboration with the development groups in charge of each service (mainly those responsible for backend API development), but our involvement doesn't end at delivery. We stay actively involved in post-launch development and enhancements, working closely with each service group to take shared responsibility in driving the service forward. Our Journey So Far Let’s explore how the Mobile App Development Group was formed. The Early Days of KINTO Technologies KINTO Technologies has its roots in the development department of KINTO Corporation. At the time, the service primarily handled applications via the web and had no mobile app. So, the engineering team was made up almost entirely of web engineers, with very few members having any experience in mobile app development. my route Development Amid these circumstances, KINTO Technologies was assigned to develop my route , a MaaS app that originally began as a pilot project by Toyota Motor Corporation. At the time, My Route was being developed under contract by a partner company, and our first mission was to bring that development in-house. Although the in-house development of backend APIs progressed smoothly, mobile app development remained heavily reliant on partner companies for quite some time due to a shortage of specialized engineers. To turn things around, we gradually built up in-house expertise by reassigning engineers with mobile app experience and actively hiring new talent. By fall 2021, we had a solid internal foundation in place and were ready to kick off our in-house mobile app development project. Development of Apps Other Than my route As the mobile app engineering team within the My Route Development Group grew more capable, we started receiving an increasing number of inquiries about mobile app development from teams outside of My Route. By that time, KINTO Technologies had started handling several mobile apps besides my route. However, due to the ongoing shortage of mobile app engineers, much of the development work was still outsourced to partner companies. I wouldn't say that was the sole reason, but it's true that many of those projects faced challenges and didn't go very well. As we continued offering support and assisting with these external projects, our involvement in services beyond my route gradually increased, even though we were still technically part of the my route Development Group. The Birth of Mobile App Development Group Before we knew it, nearly half of our members were working on services other than my route. At that point, it no longer made sense from an organizational or operational perspective for us to remain a team within the my route Development Group. As a result, the Mobile App Development Group was established as an independent team in January 2022. We also considered embedding mobile app engineers directly into the development teams for each individual service. However, since the team had only just been formed—bringing together engineers with diverse backgrounds and skill sets—there were concerns that spreading them out too soon would make it difficult for KINTO Technologies to establish a consistent standard for mobile app development. This led to the decision to create a dedicated mobile app development group. Thanks to that, about a year later, we have established a number of development standards, and the group has grown into an organization of engineers capable of delivering high-quality mobile applications. Features of the Mobile App Development Group Team Composition As of the end of 2022, the group's size has grown to about 25 people. The number of Android and iOS engineers is roughly half and half, and some members are skilled in both platforms or have multi-platform experience using tools like Flutter and Unity. We also have a few members called "producers," who take on PM-like roles. Currently, our development work is centered on native apps, so the team is broadly divided into Android and iOS groups. However, we are considering reorganizing into service-based teams in the future. This would allow us to strengthen ties to each service and make better use of engineers who have the skills to work across both operating systems. International Diversity Compared to other groups, our team has a notably high ratio of non-Japanese members. In particular, around 80% of our Android specialists are global talent. Our group includes members from a wide range of countries, including Korea, China, Taiwan, Myanmar, Poland, and Germany, making for a truly international environment. Many of our members are fluent in English, but since English has not yet been adopted as the company's official language, all members are able to communicate in Japanese well enough to perform their daily work. With people from many different cultural backgrounds, the team enjoys a lively atmosphere and open, energetic communication on a daily basis. The communication style can feel much more direct compared to all-Japanese teams, which can be surprising at times. Even so, we aim to be an organization that embraces and enjoys these differences. What kind of People Work Here? When it comes to hiring, technical skills in mobile app development are a given. What we value even more is a strong interest in the field and a proactive mindset toward staying up to date with the latest trends. That's because the mobile app development landscape is constantly evolving, with new technologies and techniques emerging every day. Relying solely on existing knowledge quickly leads to obsolescence in such a fast-paced environment. As a result, the team is made up of members who are truly passionate about mobile app development. Many go beyond their daily work to improve their skills, and study sessions are held regularly. To Our Future Members If you're looking to grow as a mobile app specialist and want to work with the latest technologies, this is the perfect environment for you. Even if you don't have much hands-on experience yet, we warmly welcome those who bring passion and a willingness to learn. Let's work together to create mobile applications that support Toyota Group!

今日のビジネス環境は変化が激しく、競争力を維持するためにはデータ活用が不可欠となっています。しかし、「データ活用」と一口に言っても、実際に推進するには様々な課題が存在するのが現場の実情です。本ブログでは、なぜ今データ活用が重要なのか、その推進を支えるデータ基盤とは何か、そしてデータをより効果的に活用するためのデータモデリングについて解説します。 なぜ今、データ活用が重要なのか？ データ活用の重要性が高まっている背景には、大きく分けて ２つの時代の潮流 があります。１つは ITの技術革新 で、AIやLLM（大規模言語モデル）が急速に発展し、データを活用した予測や意思決定が高度化しています。もう１つは データの多様化 です。これまでは基幹システムの一部のデータしか活用できませんでしたが、現在ではデバイスデータ、IoTデータ、オープンソースデータなど、様々な種類のデータが利用可能になっています。 この２つにより、かつては経営やリスク管理、社内業務改善が中心でしたが、今では商品・サービスの高度化や新たな価値創造へと広がっています。さらに顧客行動履歴分析によるパーソナライズ、サプライチェーン最適化、MaaSやBPaaS、ロボティクス、スマートシティといった新たなサービスの創出が可能になっています。 このように、高度なデータ活用は企業の競争力の源泉となっています。市場で勝ち抜くためには、自社のデータを見直し、高度に活用していくことが不可欠です。 データ活用を阻む壁とその解決策 ここまででデータ活用の重要性は理解しても、現実はそう簡単ではありません。データ活用を推進する上で立ちはだかる代表的な課題が３つあります。 1. 人材・文化の課題 出典: DX動向 2024 / IPA IPAの2023年の調査によると、企業の57.5%がデータの整備・管理・流通における最大の課題として「人材の確保の難しさ」を挙げています。特に、高度化する技術や多様なデータを活用できる人材、すなわちデータサイエンティストやエンジニアなどの高度人材が不足している実態が浮き彫りになっています。 さらに、同調査では約40%の企業が「全社的な方針や文化の欠如」も課題に挙げており、データの整備が進んでも、現場の担当者がその活用方法を理解できず、結果としてデータ利活用が進まないケースも多いことが示されています。 2. データのサイロ化の課題 データのサイロ化とは、部門やシステムごとにデータが分断され、相互に連携されていない状態を指します。このような状況では、企業全体として多くのデータを保有していても、特定の目的に必要な情報を横断的に集めることが困難になります。また、同じ「売上」といった指標であっても、部門やシステムごとに定義や計測方法が異なる場合があり、こうした不一致が分析結果にばらつきを生じさせたり、誤った意思決定につながったりするリスクがあります。サイロ化は、データ活用の効率や精度を大きく損なう要因の一つです。 3. データガバナンスの課題 たとえ課題を乗り越えてデータの活用が進んだとしても、そこには新たなインシデントのリスクが伴います。まず懸念されるのがセキュリティリスクです。データ量が増加する中で、一元的な管理体制が整っていないと、アクセス権限の管理や監査体制が不十分になり、不正利用やプライバシー情報の漏洩といったリスクが高まります。加えて、データの定義や前提が組織内で十分に共有されていない場合、誤った解釈にもとづくデータ利用が発生するおそれがあります。その結果、活用によって得られるはずの知見や判断が不正確となり、期待していた効果が得られなくなってしまいます。 これらの課題を解決し、データ活用を円滑に進めるための仕組みが、データ基盤です。 データ基盤とは？ データ基盤とは、企業や組織が様々なデータを集約し、一元的に管理、分析、活用するための基盤です。大量かつ多様なデータをビジネス上の意思決定やサービス開発に生かす仕組みを統合的に提供し、様々なデータを集約し、ビジネスに活かすことがデータ基盤の要となります。 データ基盤のもつ4つの機能 一般的なデータ基盤は、データをビジネスに活用するための一連のプロセスを担っています。その主な機能は、大きく4つの段階に分けて捉えることができます。 まず初めに行われるのが 「データの収集と保管」 です。これは、データベースやIoTデバイスなど、多様なソースからデータを取り込み、整形せずにそのまま保存するフェーズです。構造化データ・非構造化データのいずれにも対応する必要があり、後の処理に備えて、なるべく生データのまま保持しておくことが重要です。 次に、その収集データに対して 「整形処理」 を施します。ここでは、表記ゆれの統一、重複の排除、個人情報のマスキングなど、データの品質を高めるためのクリーニング作業が行われます。この段階を経ることで、分析や利活用に適した状態へと整えられていきます。 整形されたデータは、その後 「蓄積」 されます。このフェーズでは、単に保存するだけでなく、実際のユースケース――たとえば分析やサービス提供――に応じて、最適な形式で保持されます。収集・保管との違いは、この”目的に応じた再編成”にあります。 そして最終的に、 「活用」 の段階へと進みます。蓄積されたデータは、BI（ビジネスインテリジェンス）やBA（ビジネスアナリティクス）ツールを通じた意思決定支援に使われたり、データアプリケーションとしてサービスやプロダクトに組み込まれたりします。こうして、データは具体的なビジネス価値へと変換されていくのです。 データ基盤構築を支える技術要素 上記の機能を具体的なシステムとして実現するための技術要素が以下の７つです。 1. データコネクター データコネクター（Data Connector）は、様々なデータソースからデータレイクにデータを収集・転送する仕組みです。多種多様なデータソースへの接続管理を担います。Fivetransやtoroccoなど、この責務に特化したSaaSもあります。 2. データレイク データコネクターから転送されたデータを、ありのままの形で大量に蓄積するための仕組みがデータレイク（Data Lake）です。構造化データ、半構造化データ（JSONなど）、非構造化データ（画像、音声、テキストなど）を問わず、あらゆる形式のデータを保存できるのが特徴です。データレイクを設けることで、後工程でのETLやモデリングを効率的に検討できるようになります。データウェアハウスと異なり、収集時にデータの形式やモデリングを厳密に定義する必要がありません。 補足：構造化データはRDBやCSVのようなテーブル形式のデータ。非構造化データは画像や音声、テキストなど。半構造化データはJSONのようにカラムが固定されていないデータ。 3. ETL Extract（抽出）、Transform（変換）、Load（格納）の略で、データレイクからデータを抽出し、活用しやすいように加工・整形し、データウェアハウスなどに格納する仕組みです。データ品質の管理やセキュリティ対策もここで行われます。定期的なバッチ処理で実行されることが多いです。 4. データウェアハウス（DWH） データウェアハウス（DWH）は　企業内外のさまざまなデータを分析・レポート用途に最適化して蓄積するためのデータストアです。単なる“データを保存する場所”ではなく、大量データを効率的に集計できるよう設計された分析専用の基盤で、データ基盤の「肝」となる要素と言えます。 5. データマート データマート（Data Mart）は、データウェアハウスの中から、特定の利用部門や分析テーマに合わせて必要なデータを切り出し、使いやすい形にまとめた小規模なデータウェアハウスです。データウェアハウスが大規模で全社的に使われる場合に、部門ごとに小回りの利くデータを利用したいという場合に作成されます。ただし、データマートを無計画に乱立させると、先に述べたデータのサイロ化を招く可能性があるため注意が必要です。 6. 活用 データ基盤の最終目的は、収集・整形・蓄積したデータを活用することです。具体的には、 サービス支援 として商品やサービスの向上、ユーザー体験の改善、業務効率化に活用され、例えば機械学習による予測やレコメンドシステムが含まれます。また、 意思決定支援 としては、経営層やアナリストがBIツールやダッシュボードを用いてデータに基づいた判断を行い、戦略を決定します。データは、ビジネス価値を創出するために活用される重要な要素です。 7. データカタログ データカタログ（Data Catalog）とは、データの場所や意味、使用方法を整理し、必要な人が簡単にアクセスできるようにします。メタデータには、ファイル名やテーブル名の基本情報に加え、データの定義や更新頻度、保存期間なども記録され、部門間での共有を助けます。リネージ情報は、データの出所や変換経路を追跡でき、品質問題の原因を特定するのに役立ちます。最近では、Apache IcebergやApache Hudiなどのオープンソース技術も普及しています。 これらの技術要素が連携することで、データ収集から活用までの一連のプロセスが実現されます。 データモデリングとは？ データモデリングとは、組織が必要とするデータの構造や関係性を整理・定義し、システムや業務に活用できる形に設計するプロセスです。特にデータ基盤においては、データウェアハウスやデータマートにどのような形式でデータを格納すると、より正確で再利用しやすく、分析しやすいデータになるかを設計する役割を担います。データ基盤を「より良いものにするため」にデータモデリングが存在すると言えます。 目的の違いによるデータモデリング データモデリングには、大きく分けて二つのカテゴリーがあり、 業務システム用 と データ分析用 にわけられます。 業務システム用データモデリングは、日常業務のトランザクション処理（データの書き込みや更新）に最適化されたモデリングです。データ構造は正規化を行い、データの冗長性を排除し、整合性を保つことを重視します。また重要な処理として書き込み、更新があり、正確性とパフォーマンスが求められます。更新頻度はユーザが絶え間なく使うことが一般的なため、リアルタイムです。 一方、データ分析用データモデリングは、データの検索や集計といった分析処理に最適化されたモデリングです。ディメンショナルモデリングとも呼ばれます。データ構造は正規化はせずに、分析に必要なデータを結合して持ち、集計のパフォーマンスを向上させることを重視します。重要な処理は検索、集計で、分析者が直感的にデータを理解し、高速にクエリを実行できることが求められます。更新頻度はETLの実行タイミングなど、定期的に行われます。 両者の違いを具体例で見てみましょう。例えば、「先月の特定店舗の売上合計」を分析したい場合、業務システム用モデルでは正規化されているため、複数のテーブルを結合（Join）して集計する必要があります。分析者はどのテーブルがあり、それらをどう結合すれば目的のデータが得られるかを理解している必要があります。一方、分析用モデルでは、売上という分析対象（ファクト）を中心に設計されているため、日付や店舗といった条件（WHERE句）を指定するだけで簡単に集計できます。これにより、分析者は直感的に、かつ高性能なクエリを実行できるのです。アジャイルデータモデリングに関する書籍でも、正規化はビジネスステークホルダーにとって複雑すぎるという指摘がある通りです。 分析用モデリングの中心：スタースキーマ 分析用データモデリングで最も有名なものの1つがスタースキーマです。これは、ファクトテーブルとディメンションテーブルの2種類のテーブルを用いてデータ構造を設計する方法です。 出典: 『実践的データ基盤への処方箋〜ビジネス価値創出のための データ・システム・ヒトのノウハウ』技術評論社 ファクトテーブル とは、ビジネス観点で計測・分析したい対象を表します。例えば、売上合計や商品購入といった「事象」や「測定値」がこれにあたります。分析の要望を基に、まずファクトテーブルを定義するのが最初のステップです。 ディメンションテーブル は、ファクトテーブルをどのような切り口で分析したいかを表します。日付、商品、ユーザー、店舗、金額帯などがディメンションにあたります。 スタースキーマでは、中央にファクトテーブルがあり、その周りをディメンションテーブルが取り囲む構造になります。この形が星のように見えることから「スタースキーマ」と呼ばれています。分析したい対象（ファクト）ごとにスタースキーマが作成されるイメージです。 データモデリングを成功させるアプローチとは データ基盤構築とデータモデリングは、一度行って終わりではありません。ソースでは、以下のようなプロセスが推奨されています。 議論・設計：分析の目的や要件について話し合い、データモデルを設計します。 ETL構築：設計したモデルに合わせてETL処理を構築します。 活用：構築されたテーブルを使ってデータ活用を行います。 レビュー：結果を評価し、改善点を見つけます。 このプロセスは、矢印が双方向になっているように、行き来しながら進めることが重要です。ETL構築中に設計上の問題が見つかったり、活用から新たな分析ニーズが生まれたりすれば、議論や設計に戻って見直しを行います。 さらに、このプロセスをアジャイルに、すなわち反復的、段階的、協調的に進めることが、よりビジネス価値を創出するデータモデルを作る上で重要とされています。例えば、2週間や1ヶ月を1イテレーション（繰り返し）として、その期間内に議論、設計、構築、活用、レビューの一連のプロセスを行います。 これは、ソフトウェア開発におけるアジャイル開発の考え方と共通しています。データモデリングも同様に、小規模なサイクルで議論・設計、ETL構築、活用、レビューを回すことで、インクリメンタルに価値を実感しながら進めることができ、間違った方向へ進むリスクを減らし、チームの効果的な動きを促進できます。 自社のデータを最大限活かすdotDataのデータ活用支援 dotDataは、このようなデータ活用を強力に支援するアプローチをとっています。その特徴は、一気通貫でのデータ活用サポートです。データ基盤を構成する様々な要素・機能を、自社のプロダクト群で担当しています。 BA教育（dotData ビジネスアンリティクス人材育成サービス） データウェアハウスに蓄積されたデータをいかに活用するかという教育プログラムを提供し、組織全体のデータ活用能力の底上げを図ります。 dotData Feature Factory Pythonで利用可能なプロダクトで、データレイクのデータから活用までを一気通貫で実現できます。 dotData Enterprise / dotData Ops 主にデータウェアハウスのデータを用いて、サービス支援（予測など）を行い、業務やプロダクトの改善を支援するプロダクトです。 dotData Insight データウェアハウスのデータを用いた意思決定支援に特化したサービスです。dotDataの持つ特徴探索技術と生成AIを組み合わせることで、高いスキルを持たないユーザーでも効率的に分析や仮説検証を行える機能を提供します。これにより、人材・文化の課題解決に貢献します。 dotDataのプロダクト群を活用することで、データモデリングのアジャイルプロセス（議論、設計、ETL構築、活用、レビュー）を高速化することが可能です。これにより、イテレーションの速度が向上し、結果として得られるビジネス価値も拡大・改良されます。 まとめ 激しい環境変化の中で、競争力を保ち続けるためにデータ活用の重要性はますます高まっています。しかし、単にデータを集めるだけでは不十分で、それを価値に変えるためには、課題の克服と基盤の整備が欠かせません。dotDataは、こうしたデータ基盤の構築やデータモデリングを含むデータ活用プロセス全体を強力に支援しています。もしデータ活用にご興味をお持ちであれば、ぜひお気軽に お問い合わせ ください。 The post データ活用のためのデータ基盤とは？構築プラクティスとアジャイルデータモデリング appeared first on dotData .