本ブログは ミツイワ株式会社 様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 企業の DX 推進が加速する中、IT インフラの迅速な構築と安定運用は、ビジネスの成否を左右する重要な要素となっています。特に、新しいアプリケーションやサービスを導入する際、実行基盤の準備に時間がかかり、サービス開始までのリードタイムが長期化することは、多くの企業が直面する課題です。 従来のインフラ構築では、顧客からの問い合わせ内容の整理、要件定義、環境設計、構築作業、そして運用設定まで、多くの工程で人手を介する必要がありました。その結果、担当エンジニアの負担が大きく、品質のばらつきや属人化といった問題も発生していました。また、最新の IT サービスを導入するためには専門領域外の高度な学習が必要となり、技術の習得コストも課題となっていました。 今回ご紹介するのは、ミツイワ株式会社様が、Amazon Bedrockと AWS CloudFormation を活用して、インフラ構築プロセスを一気通貫で自動化した先進的な事例です。 ミツイワ株式会社様の状況と課題 ミツイワ株式会社様は、ICT サービス事業を核に、企業の情報システム導入から運用、さらには最先端の DX 推進まで、ICT ライフサイクル全体をサポートするワンストップソリューションを提供されています。マネージドサービスを通じて多くの企業の IT インフラを支えてきた同社ですが、急速な IT 技術の進化に伴い、以下のような課題に直面していました： リードタイムの長期化 顧客からの問い合わせが未整理のまま届き、内容確認と要件整理に多くの時間を要していた 業務課題を解決するために新たなアプリケーションを導入しようとしても、実行基盤の準備に時間がかかり、実際のサービス開始まで長期間を要していた 顧客ごとに異なる環境を手作業で構築するため、リードタイムの長期化と品質のばらつきが発生していた 品質維持と運用負荷 クラウド環境の構築依頼から完了まで、担当エンジニアの負担が大きく、本来注力すべき業務改善に時間が割けない状況であった 導入したアプリケーションや実行基盤の品質維持に多くの工数が割かれていた 運用設計の標準化が不十分で、属人化のリスクがあった 学習コストと属人化 最新の IT サービスを導入するために、専門領域外の高度な学習が必要となり、技術習得に時間がかかっていた 技術が属人化しやすく、担当者の異動や退職時に業務の継続性に懸念があった ミツイワ様はこれらの課題を解決するため、自社のマネージドサービスを進化させ、顧客の価値向上に繋げるべく、生成 AI と IaC を活用した次世代インフラ自動構築ソリューションの開発に至りました。 ソリューション ミツイワ株式会社様は、AWS の生成 AI サービスとマネージドサービスを最大限活用し、以下のようなアーキテクチャを構築しました： Amazon Bedrock による解析の自動化 顧客からの問い合わせ内容を Amazon Bedrock が自動で解析し、要件を構造化 解析結果に基づいて、最適な AWS CloudFormation テンプレートを自動選定 生成 AI の自然言語処理能力により、未整理の問い合わせでも適切に解釈し、必要な AWS リソースを特定 AWS CloudFormation によるコード管理 AWS のリソース構築や運用設計をあらかじめテンプレート化し、高い再現性と品質を確保 AWS CloudFormation により、インフラのプロビジョニングと設定を自動化し、手作業によるミスを排除 テンプレートのバージョン管理により、環境の変更履歴を追跡可能にし、必要に応じてロールバックを実現 サーバーレスな高速構成 AWS Lambda のサブプロセスで MCP サーバーを起動し、高速かつサーバーレスな構成を実現 ジョブ型非同期処理により、利用者が処理状況を追跡可能となり、ユーザーエクスペリエンスが向上 サーバー管理が不要なサーバーレスアーキテクチャにより、運用負荷を最小化 一気通貫の自動化フロー 本ソリューションは、以下のような一連のプロセスを人手を介さずに自動化します： 1. 問い合わせ受付: 顧客からの問い合わせを受付 2. 要件解析: Amazon Bedrock が問い合わせ内容を解析し、必要な AWS リソースを特定 3. テンプレート選定: 解析結果に基づき、最適な AWS CloudFormation テンプレートを自動選定 4. 環境構築: AWS CloudFormation により AWS 環境を自動構築 5. 初期設定: 運用に必要な初期設定を自動適用 6. 完了通知: 構築完了を利用者に通知 この自動化により、従来は数日から数週間かかっていたプロセスを、大幅に短縮することが可能になりました。 導入効果 AWS の生成 AI と IaC を活用した次世代インフラ自動構築ソリューションの導入により、以下の効果が得られました： リードタイムの大幅短縮 問い合わせの受付から基盤の準備、初期設定までを標準化・自動化し、サービスインまでの期間を大幅に短縮 AWS のサービスを使うことで短期間で依頼内容の整理から環境構築まで自動化され、ビジネスの俊敏性が向上 業務時間の再配分 構築・運用の自動化により、余剰となった時間を業務改善や新たな価値創出へ再配分することが可能に エンジニアが本来注力すべき業務に集中できるようになり、顧客への提供価値が向上 安定稼働と継続性の向上 運用設計をテンプレート化したことで学習コストと属人性を抑制 サポートセンターによる運用と合わせて、システムの安定稼働と継続運用性を向上 AWS CloudFormation によるコード管理により、環境の再現性が格段に向上し、品質のばらつきを解消 ユーザーエクスペリエンスの向上 ジョブ型非同期処理により、利用者が処理状況を追跡可能となり、透明性が向上 自動化により、迅速かつ正確なサービス提供が可能になり、顧客満足度が向上 お客様の声 Amazon Bedrock と AWS CloudFormation を組み合わせることで、インフラ構築の全自動化を実現できました。特に、AWS Lambda 上で MCP サーバーを起動するサーバーレスな構成は、高速かつ運用負荷の少ないアーキテクチャを実現する上で非常に効果的でした。問い合わせ解析から AWS 環境構築までを一気通貫で自動化したことで、エンジニアの工数を大幅に削減し、本来注力すべき業務に集中できるようになりました。また、AWS CloudFormation によるテンプレート管理により、環境の再現性と品質が向上し、属人化のリスクも軽減されました。 今後の展望 ミツイワ株式会社様は今後、以下の取り組みを通じて、さらなる顧客価値の最大化を目指しています： ITSM 連携の強化 利用申請からサービスの提供、その後の設定変更の管理やインシデント管理に至るまで、自動化の範囲を拡大 IT サービスマネジメント（ITSM）ツールとの連携により、エンドツーエンドの自動化を実現 マルチアカウント展開 複数の AWS アカウントにまたがる環境構築を自動化し、大規模な組織での展開を支援 AWS Organizations と連携した、ガバナンスとセキュリティを考慮した自動構築を実現 継続的な改善 生成 AI の進化に合わせて、解析精度と自動化の範囲を継続的に拡大 顧客からのフィードバックを基に、テンプレートの拡充とプロセスの最適化を推進 まとめ 本事例は、Amazon Bedrock と AWS CloudFormation を組み合わせることで、インフラ構築プロセスの全自動化を実現した先進的な取り組みです。生成 AI による問い合わせ解析と、IaC による環境構築の自動化により、リードタイムの大幅短縮、品質の向上、そして属人化の解消を同時に達成しました。特に注目すべきは、AWS Lambda 上で MCP サーバーを起動するサーバーレスな構成により、高速かつ運用負荷の少ないアーキテクチャを実現している点です。本事例が、インフラ構築の自動化や生成 AI の活用をご検討中のお客様の参考になれば幸いです。 ミツイワ株式会社（左から）： AWS技術監修：福園　智憲様 ソフトウェア開発担当：芳我 俊祐様 AWSインフラ担当：浅羽　瞬様（パーソル＆サーバーワークス株式会社よりプロジェクト参画） Amazon Web Services Japan 合同会社： アカウントマネージャー 植木 輝（右端） ソリューションアーキテクト 森 瞭輔（左端）

本記事は、2026 年 1 月 30 日に公開された BMW Group unlocks insights from petabytes of data with agentic search on AWS を翻訳したものです。 ドイツのミュンヘンに本社を置く BMW Group は、15 か国の 30 か所以上の生産・組立施設で 159,000 人の従業員を雇用しています。BMW Group は自動車イノベーションのリーダーとして、データと人工知能 (AI) を活用し、デジタルトランスフォーメーションの最前線に立ち続けています。2020 年、BMW Group は Cloud Data Hub (CDH) を立ち上げました。現在、これは Data Lakehouse として運用されており、クラウド上で全社的なデータとデータソリューションを管理するための BMW Group の中央プラットフォームとなっています。これにより、全社の従業員に対し、データ駆動型アプリケーションの実装とデータインサイト生成の中心的な基盤を提供しています。 現在、CDH は 20 PB のデータを保存し、1 日平均 110 TB のデータを取り込んでいます。この膨大なデータから洞察を抽出することは、特に技術的および分析的な専門知識を持たないユーザーにとっては困難な場合があります。関連するデータソースを特定し、複雑なクエリを構築し、表形式の出力を解釈する必要があるためです。 本記事では、BMW Group が AWS Professional Services と協力して、 Amazon S3 Vectors 、 Amazon Bedrock 、 Amazon Bedrock AgentCore の機能を組み合わせたエージェンティック検索ソリューションを開発した方法を説明します。このソリューションは、技術スキルに関係なく、BMW Group のユーザーが自然言語を使用して大規模なデータセットから実用的なデータインサイトを抽出できるように設計されています。 課題: データとインサイトのギャップの解消 従来のデータ分析ワークフローは複雑で時間がかかり、企業データから価値ある洞察を迅速に引き出すことを妨げる障壁となっています。プロセスはデータの発見から始まり、ユーザーは適切なデータソースを見つけるために、数十、数百、あるいは数千ものデータアセットを検索する必要があります。次に、ユーザーは SQL クエリを記述して実行する必要があり、複雑な結合や集計にはスキーマの知識が必要です。クエリ結果を生成した後、生の表形式の出力を実用的な洞察に変換するには、特定のドメイン専門知識が必要になることがよくあります。これらの課題は、特に構造化データと非構造化データを組み合わせる場合、組織がデータアセットを効果的に活用する能力を著しく制限する可能性があります。 ソリューション概要 BMW Group のエージェンティック検索ソリューションは、AI エージェントフレームワーク内で 3 つの補完的な検索アプローチを組み合わせることで、大規模なデータセットからインサイトを抽出するという課題に対処します。このソリューションにより、ユーザーは自然言語を使用してペタバイト規模の構造化データと非構造化データをクエリでき、クエリの特性に基づいて最適な検索戦略が自動的に選択されます。 本記事では、車両テストで報告された問題の詳細な記録を収集する製品品質システムのデータセットを使用してソリューションを紹介します。各レコードには、問題の説明、分類、技術的な詳細がドイツ語と英語の両方で含まれており、世界中の生産施設やサービスセンターから蓄積されたものです。このデータセットは、何年にもわたる品質エンジニアリングの知識を表しており、意味的に類似した問題がチームや言語によって異なる用語で記述されています。 このアーキテクチャは、それぞれ特定の検索パターン向けに設計された 3 つの専門ツールで構成されています。 ハイブリッド検索: セマンティック検索と SQL フィルタリングを組み合わせて、概念的に類似したデータを効率的に取得します。このツールは、まずベクトルベースのセマンティック検索を実行して関連するレコードを特定し、次に SQL フィルタを適用して正確に絞り込みます。「特定の車両モデルのブレーキシステムに関するフィードバックを検索する」など、概念的な理解と構造化されたフィルタリングの両方が必要なクエリに最適です。 網羅的検索: AI を活用した評価を使用して、セマンティック検索だけでは用語のバリエーションにより関連する結果を見逃す可能性がある場合に、一致するすべてのレコードを包括的に分析します。このツールは SQL クエリを実行して候補レコードを取得し、次に大規模言語モデル (LLM) を使用して各結果を評価し、詳細な推論で関連性を判断します。「ブレーキ関連の問題は何件発生しましたか？」など、完全なカバレッジが不可欠な質問に特に効果的です。 SQL クエリ: セマンティック分析が不要な場合に、正確なデータ取得のための直接的な構造化クエリ機能を提供します。このツールは、構造化されたデータフィールドに対する集計、カウント、統計分析などの純粋な分析クエリを処理します。 AI エージェントがこれらのツールを統制し、各ユーザークエリを分析して最も適切な検索戦略を決定します。エージェントは、概念的なクエリにはセマンティック検索、包括的な分析には網羅的検索、構造化された分析には直接 SQL を自動的に切り替えます。これらすべてが単一の会話型インターフェースを通じて実行されます。このインテリジェントなルーティングにより、ユーザーは基盤となる技術的な複雑さを理解したり、検索方法を手動で選択したりすることなく、関連する結果を受け取ることができます。 アーキテクチャの詳細 次のアーキテクチャ図は、これらのコンポーネントがどのように連携してエージェンティック検索体験を提供するかを示しています。 図 1. エージェンティック検索ソリューションのアーキテクチャ コアコンポーネント データストレージとベクトル検索 Amazon S3 Vectors (S3 Vectors) は、ベクトル埋め込みに対するセマンティック検索を可能にし、専用のベクトルデータベースインフラストラクチャを必要とせずに、数百万のデータポイントにわたる効率的な最近傍クエリをサポートします。S3 Vectors の構造化データに対しては、 Amazon Athena (Athena) がサーバーレス SQL クエリ実行を提供し、元のソースデータに対するアドホック分析と構造化フィルタリングを可能にします。 LLM とエージェントの実装 Amazon Bedrock (Bedrock) は、複数の LLM でソリューションを強化します。ベクトル埋め込みの生成には Amazon Titan Text Embeddings V2 (Titan Text Embeddings) を使用し、エージェントのオーケストレーションのための主要な推論モデルとして Anthropic の Claude Sonnet 4.5 を使用し、網羅的検索におけるコスト効率の高い分類タスクには Anthropic の Claude Haiku 4.5 を使用します。AWS のオープンソースフレームワークである Strands Agents は、ツールの選択、会話フロー、モデルとのインタラクションを管理しながら、本番環境レベルの信頼性を維持して AI エージェントをオーケストレーションします。 データ取り込みとベクトルインデックスの作成 エージェンティック検索ソリューションがクエリに回答する前に、ソースデータを処理し、セマンティック検索用にインデックス化する必要があります。ここでは、 AWS Lambda (Lambda) を使用してサーバーレスの取り込みパイプラインを実装し、タイトルや説明などの自由形式のテキスト属性を含む構造化データベースレコードを、検索可能なベクトル埋め込みに変換しました。 取り込みプロセスは、次のステップに従います。 データ抽出: Lambda 関数は Amazon Athena でソースデータベーステーブルをクエリし、ドイツ語と英語の両方で問題の説明、タイトル、分類を含む製品品質レコードを取得します。 テキスト準備: 各レコードに対して、パイプラインは意味的に関連するフィールド (クラスター名、問題タイトル、説明) を連結し、埋め込み生成に適した統一されたテキスト表現を作成します。 埋め込み生成: 準備されたテキストは Titan Text Embeddings に送信され、各レコードの意味的な意味を捉える 1,024 次元のベクトル埋め込みが生成されます。 ベクトルストレージ: 埋め込みは S3 Vectors インデックス形式を使用して Amazon S3 に保存され、各ベクトルには検索操作時の取得のために対応するレコード ID がタグ付けされます。 メタデータの永続化: 元の構造化データは S3 に残り、Athena 経由でクエリできるため、エージェンティック検索ツールは意味的類似性と SQL ベースのフィルタリングを組み合わせることができます。 このインジェストアーキテクチャはデータを増分処理するため、BMW Group は新しい製品品質問題が報告されるたびに、データセット全体を再処理することなく、ベクトルインデックスを継続的に更新できます。 ハイブリッド検索 ハイブリッド検索ツールは、セマンティック類似性と SQL フィルタリングを組み合わせることで、ユーザーが正確なビジネス制約を適用しながら、概念的に関連するレコードを見つけることを可能にします。例えば、「前四半期の F09 車両におけるブレーキシステムのフィードバックを見つける」というクエリは、セマンティックな理解 (何が「ブレーキシステムのフィードバック」に該当するか) と構造化されたフィルタリング (特定の車両モデルと時間範囲) の両方を必要とします。 仕組み: ユーザーがクエリを送信すると、エージェントは 3 つのパラメータを使用してハイブリッド検索ツールを呼び出します。 1) 検索する概念を説明するセマンティッククエリ (例:「ブレーキシステムのフィードバック」)、 2) 取得する類似レコードの数を指定する top_k 値 (例: 100)、 3) フィルタリング用のプレースホルダー {semantic_ids} を含む SQL クエリテンプレートです。その後、ツールは複数のステップからなるプロセスを実行して、関連性の高い結果を提供します。 ステップ 1 – セマンティック検索フェーズ: ツールはまず、セマンティッククエリを Titan Text Embeddings に送信してクエリベクトルを生成します。次に、このベクトルを使用して、コサイン類似度 (cosine similarity) に基づいて最も類似した top_k 件の製品品質レコードを S3 Vectors インデックスから検索します。S3 Vectors API は、クエリとのセマンティックな関連性によってランク付けされた ID のリストを返します。 入力例: 「ブレーキシステムのフィードバック」 出力例: 類似度でランク付けされた ID: [12847, 9203, 15634, 8821, … ] (ブレーキパッドの摩耗、ブレーキフルードのチェック、ブレーキ性能などに関する上位 100 件のレコード) ステップ 2 – SQL フィルタリングフェーズ: セマンティック ID が SQL クエリテンプレートに注入されます。その後、Athena がこの SQL クエリを実行します。このクエリには、追加の WHERE 句、JOIN、集計、またはその他の有効な SQL 操作を含めることができ、日付、重要度レベル、車両モデルなどの構造化データ属性に基づいて結果をさらに絞り込むことができます。 入力 SQL テンプレートの例: SELECT * FROM quality_records WHERE record_id IN ({semantic_ids}) AND vehicle_model = ‘F09’ AND report_date >= DATE ‘2025-10-01’ 実行されたクエリの例: SELECT * FROM quality_records WHERE record_id IN (12847, 9203, 15634, 8821, …) AND vehicle_model = ‘F09’ AND report_date >= DATE ‘2025-10-01’ 出力例: セマンティック類似性と構造化フィルタの両方に一致する 7 件のレコード ステップ 3 – 結果の統合: フィルタリングされた結果がエージェントに返され、エージェントは Anthropic の Claude Sonnet 4.5 を使用して自然言語の応答を合成し、関連する詳細と洞察を含むユーザーフレンドリーな形式で調査結果を提示します。 ユーザーへの出力例： 「2024 年第 4 四半期の F09 車両において、ブレーキ関連の記録が 7 件見つかりました。最も多かったのは、ブレーキパッド点検 (3 件)、ブレーキフルード交換 (2 件)、ブレーキ性能チェック (2 件) です。」 このハイブリッドアプローチにより、結果がセマンティックに関連性があり (「ブレーキシステムのフィードバック」にはブレーキパッドの摩耗、ブレーキフルードのサービスなどが含まれることを理解)、かつ正確にフィルタリングされる (F09 のみ、直近の四半期のみ) ことが保証されます。このアプローチは、自然言語理解の柔軟性と構造化クエリの精度を組み合わせることで、セマンティックに関連性があり、ビジネス要件に従って正確にフィルタリングされた結果をユーザーに提供するように設計されています。次のシーケンス図は、完全なワークフローを示しています。 図 2. ハイブリッド検索のシーケンス図 包括的な分析のための網羅的検索 ハイブリッド検索は意味的に類似したレコードを見つけることに優れていますが、一部のクエリでは完全なカバレッジを確保するために、一致するすべてのレコードの包括的な分析が必要です。「F00 モデルでブレーキ関連の問題は何件発生しましたか？」のような質問では、用語のバリエーション (例: 「ブレーキ」、「ブレーキシステム」、「ブレーキパッド」、「ABS」 ) によってセマンティック検索が関連するケースを見逃す可能性があるため、網羅的な評価が必要です。網羅的検索ツールは、SQL ベースの候補取得と AI による関連性分類を組み合わせることで、この課題に対処します。 網羅的検索ワークフローは、エージェントがクエリに対して類似性ベースの検索ではなく包括的なカバレッジが必要であると判断したときに開始されます。このツールは 2 つのパラメータを受け取ります。データベースから候補レコードを取得する SQL SELECT クエリと、関連性のある結果を構成するものを定義する検索問題の説明です。 候補の取得: エージェントは、用語の不一致を避けるため、セマンティックな概念ではなく構造化されたフィルタのみを使用して SQL クエリを生成します。たとえば、「ブレーキ関連の問題」のようなセマンティックな用語でフィルタリングする代わりに、クエリは正確なカラム値を使用します: SELECT * FROM quality_records WHERE vehicle_model = ‘F00’ これにより、LLM がデータセットから正しい用語を推測することに依存せずに、構造化された条件に一致するすべてのレコード (潜在的に数千の候補) を取得できます。このツールには再試行メカニズムが含まれています。Athena がエラー (無効なカラム名、構文エラー、またはその他の SQL エラー) を返した場合、エラーメッセージがエージェントに返され、修正されたクエリを再生成できます。これにより、ハルシネーションによる SQL が暗黙的に失敗するのを防ぎ、エージェントが実際のスキーマ情報に基づいて自己修正できるようサポートします。 バッチ処理による LLM 分類: すべての候補を一度に処理するのではなく、このツールは効率的な処理のために候補を 20 件のレコードのバッチに分割します。各バッチはマークダウンテーブルとしてフォーマットされ、Bedrock 経由で小型の LLM (Anthropic の Claude Haiku 4.5) に送信されます。モデルは各レコードを検索問題に照らして評価し、関連性があるかどうかを判断し、その判断に対する簡潔な根拠を提供します。20 という数は、モデル呼び出しの回数と コンテキストの劣化 (コンテキストウィンドウ内のトークン数が増加すると、そのコンテキストから情報を正確に想起するモデルの能力が低下する) の間の良いトレードオフであることがわかりました。バッチは並列処理され、総処理時間が大幅に短縮されます。この並列化により、分類タスクに小型で高速なモデルを使用してコスト効率を維持しながら、数千のレコードを数秒で評価できます。 結果の集約: すべてのバッチが完了した後、ツールは関連する結果を集約し、各レコードに LLM の判断根拠を含む _reason_for_match フィールドを追加して充実させます。この透明性により、ユーザーは特定のレコードが含まれた理由を理解でき、LLM を活用したフィルタリングへの信頼を構築できます。 網羅的検索アプローチは、関連するケースを見逃すとビジネス上の意思決定に影響を与える可能性がある重要なクエリに対して、完全なカバレッジを提供します。SQL の構造化されたフィルタリングと LLM のセマンティック理解を組み合わせることで、このツールはどちらのアプローチ単独では実現できない精度と再現率の両方を達成します。次のシーケンス図は、完全なワークフローを示しています。 図 3. 全探索のシーケンス図 主なメリットと成果 構造化データと非構造化データへの統一的なアプローチ ハイブリッド検索、網羅的検索、SQL クエリの組み合わせにより、このソリューションは単一の会話型インターフェース内で構造化データと非構造化データの両方をシームレスに処理できます。ユーザーは、概念的な理解を必要とする質問 (「類似のブレーキシステムのフィードバックを見つける」)、正確なフィルタリング ( 「前四半期のブレーキ問題の数を数える」 )、または包括的な分析 ( 「安全関連のすべてのインシデントを評価する」 ) を、ツールを切り替えたりクエリを再構成したりすることなく行うことができます。エージェントのインテリジェントなツール選択により、各クエリタイプが最も適切な方法で処理され、一貫した自然言語のユーザーエクスペリエンスを維持しながら正確な結果を提供します。 コスト効率の高いサーバーレスアーキテクチャ サーバーレス AWS サービス で完全に構築されているため、ソリューションコンポーネントは使用していないときはゼロにスケールし、コンピューティングリソースはオンデマンドで割り当てられ、実際の使用量に対してのみ料金が発生します。サーバーレスアーキテクチャにより、従来のインフラストラクチャの運用オーバーヘッドや固定コストなしに、AI を活用した高度なデータ分析プラットフォームを開発できます。 まとめ このエージェンティック検索ソリューションは、AWS の生成 AI サービスがユーザーとデータのインタラクション方法をどのように変革できるかを実証しています。ユーザーとインサイトの間の従来の障壁を軽減することで、このアプローチにより、エンタープライズアプリケーションに必要な精度とスケールを維持しながら、すべてのユーザーがデータインサイトを生成できるようになります。組織が生成するデータ量が増加し続ける中、このようなソリューションは、エンタープライズデータ資産の価値を最大限に引き出すために不可欠なものとなっています。 AWS で AI を活用したデータソリューションの構築について詳しく知りたい方は、 生成 AI リソース をご覧ください。 Ruben Simon Ruben Simon は、BMW 最大のデータプラットフォームである Cloud Data Hub のベテランプロダクトマネージャーです。データ、アナリティクス、AI分野におけるデジタルトランスフォーメーションの推進に情熱を注ぎ、国際的なチームとの協働を生き甲斐としています。仕事以外では家族との時間を大切にし、継続的な学びに強い関心を持っています。 Fabian Söllner Fabian Söllner は BMW Cloud Data Hub チームのソフトウェアエンジニアである。最先端のビジネスインテリジェンスと人工知能ソリューションを提供することで、組織全体の同僚を支援することに尽力している。仕事以外では、様々なスポーツ、特にロードサイクリングとトライアスロンへの情熱を巧みにキャリアと両立させ、個人と職業の両面での自己研鑽への意欲を示している。 Florian Seidel Florian Seidel は AWS のグローバルソリューションアーキテクトとして自動車分野を専門としています。戦略的顧客がクラウド技術の潜在能力を最大限に活用し、自動車産業の革新を推進するよう導いています。アナリティクス、機械学習、AI、耐障害性分散システムへの情熱を持ち、最先端の概念を実用的なソリューションへと変革する支援を行っています。クラウド戦略の設計以外の時間には、家族や友人のための料理や電子音楽制作の実験を楽しんでいます。 Khalid Al Khalili Khalid Al Khalili は、BMW グループのデータアーキテクトであり、BMW のデータイノベーションの中心的なプラットフォームである Cloud Data Hub のアーキテクチャを統括しています。彼は、シームレスなデータ体験の創出、複雑な要件を効率的でユーザーフレンドリーなソリューションへと変換することを強く提唱しています。新機能の開発に携わっていないときは、同僚や部門横断的なチームと協力して BMW のデータ戦略を推進・形成し、急速に進化する環境において BMW が常に先頭を走り続けることを確保することに喜びを感じています。 Martin Maritsch Martin Maritsch は、AWS ProServe のシニア生成型 AI アーキテクトであり、生成型 AI および MLOps を専門としています。AWS クラウド上の AI/ML サービスの可能性を最大限に引き出すことで、企業顧客がビジネス成果を達成できるよう支援しています。 Shukhrat Khodjaev Shukhrat Khodjaev は、AWS ProServe のシニア・エンゲージメント・マネージャーであり、AI を専門としています。顧客が AI 変革を加速し、イノベーションを推進し、AI アプリケーションの限界を押し広げて、具体的なビジネス成果を生み出すことを支援しています。 本記事は Senior Solutions Architect の 長谷川 仁志 が翻訳しました。

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 社内で口癖のように使っている「製品解像度」と「UX志向」について自分の思考の整理もかねて記事にまとめてみました。 はじめに：私たちは「誰」を見ているのか？ 「製品解像度」とは何か？ まず押さえたい：製品解像度が低いと起きる“あるある” なぜ「お客様解像度」だけでは不十分なのか？ 質の高いアウトプットを生む土壌 UX志向を支える「意思決定」の力 「OR」ではなく「AND」を模索する 「架け橋」としての役割 ラクス プロダクト部としての「UX志向」 製品解像度を高めるために 1. 「越境」を恐れない 2. 「なぜ？」を問い続ける 3. プロダクトの「歴史」と「未来」を知る 製品解像度が上がると何が起きるか：アウトプットの質が変わる 1) 要求仕様が“外れにくくなる” 2) トレードオフの説明責任が果たせる 3) 「事実に基づく」文化が回りやすくなる 4) “作って終わり”から“学習して伸ばす”に変わる おまけ：製品解像度を上げるための「10の問い」（会議で使える） おわりに：最高のUXへの近道 はじめに：私たちは「誰」を見ているのか？ 「UX（ユーザーエクスペリエンス）志向」 「ユーザー中心設計」 「顧客視点」プロダクト開発の現場にいると、これらの言葉を聞かない日はありません。私たちプロダクトに関わるメンバーは、常にお客様のことを考え、彼らの課題に寄り添い、最高の体験を届けようと日々奮闘しています。しかし、ここで一度立ち止まって考えてみたい問いがあります。 「お客様のことさえ深く理解していれば、本当に優れたプロダクトは作れるのだろうか？」 という問いです。自分としての結論は“お客様理解だけでは足りない”です。 もちろん、お客様を理解することは不可欠です。しかし、それだけでは「良いプロダクト」を継続的に生み出し、育てていくことはできません。 時に「お客様のため」を思うあまり、ビジネスとして成立しない機能を作ってしまったり、技術的に無理のある実装を強いてプロジェクトを破綻させてしまったりすることさえあります。 では、私たちには何が必要なのか？ そこで私が提唱したいのが、 「製品解像度」 という概念です。 今回は、単なる「お客様解像度」を超え、真の意味でプロダクトを成功に導くための「製品解像度」について、その定義となぜそれが不可欠なのかを紐解いていきます。 「製品解像度」とは何か？ まず、「解像度」という言葉についてです。自分の中では解像度は写真の比喩が一番しっくりきます。ピントが合っていない写真は、全体の雰囲気はわかるけれど、重要なディテール（表情・文字・境界線）が見えません。プロダクトでも同じで、解像度が低いと、議論が抽象的になり、判断が“気分”や“声の大きさ”に引っ張られます。逆に解像度が高いと、論点が具体になり、仮説と事実が整理され、意思決定が速くなる。 この「ピントの合い方」を、製品を取り巻く全体に広げたものが“製品解像度”として自分は定義しています。具体的には、次のような観点です。 お客様：誰が、どんな状況で、どんな目的で使っている／使おうとしているか （運用中・導入準備中・導入検討・未検討といったフェーズも含む） システム：制約、データの流れ、既存アーキテクチャ、運用条件 UI/UX：主要導線、つまずきポイント、体験の一貫性 ドメイン：業務知識、法令、慣習、現場の「当たり前」 自組織／他組織：意思決定構造、責任分界、依存関係、コミュニケーション経路 事業戦略：何を伸ばし、何を守り、何を捨てるのか（優先順位） 市場：競合、代替、ポジショニング、差別化要因 未来：中長期の方向性、ロードマップ上の“意味” 開発プロセス／役割：どう作り、どう届け、どう改善していくか 製品解像度とは、 プロダクトを取り巻くエコシステム（生態系）全体に対する理解の深さ を意味します。これら全てを網羅し、それぞれの要素がどう絡み合っているかを理解している状態こそが、「製品解像度が高い」状態と言えます。 まず押さえたい：製品解像度が低いと起きる“あるある” 製品解像度が低い状態は、努力不足というより「見えていないから判断できない」状態です。現場でよく起きる症状を挙げます。 顧客要望をそのまま機能要件に翻訳してしまい、根っこのジョブや制約を見落とす 「これが良さそう」という仮説だけで意思決定してしまい、後から前提が崩れて手戻りする “十分な検討のないトレードオフ”になり、関係者の納得が得られない リリース後、成果が測れず、改善が続かない（やりっぱなしになる） 部署間の認識がズレて、会議で「それは誰が決めるの？」が発生する どれも、個人の能力というより「判断材料が揃っていない」ことが原因です。だからこそ、解像度を上げることが、チームの再現性をつくります。 なぜ「お客様解像度」だけでは不十分なのか？ 「お客様第一」は美しい言葉ですが、プロダクトマネジメントの現実はもっと複雑で泥臭いものです。なぜ「お客様解像度」だけでは戦えないのか、その理由を構造的に解説します。 The Product Management Triangle Posted by Dan Schmidt, Product Logic ※ラクスのプロダクト部向けにカスタマイズ プロダクト開発には有名な「プロダクトマネジメント・トライアングル」という概念があります。これは、プロダクトが以下の3つの要素のバランスで成り立っていることを示しています。 開発者（Developers） お客様（Customers） ビジネス（Business） この3つの頂点を繋ぐ辺（関係性）を見てみましょう。 お客様 × 開発者 ＝ UX（ユーザー体験） お客様のニーズを技術でどう解決するか。ここから優れたUXが生まれます。 お客様 × ビジネス ＝ 価値交換（収益） お客様への価値提供が、いかに対価としてビジネスに還元されるか。ここから利益が生まれます。 3. 開発者 × ビジネス ＝ 実現可能性（デリバリー） ビジネスの要求を、限られたリソースと技術でどう実現するか。ここから製品が世に出ます。 もし、あなたが「お客様解像度」しか持っていない場合、見えるのは「1. UX」の領域だけです。 「お客様がこう言っているから機能を追加しよう」と提案しても、それがビジネス的に採算が合わない（2の視点の欠如）ものであれば却下されるでしょう。また、技術的に莫大なコストがかかる（3の視点の欠如）ものであれば、開発チームとの信頼関係を損なうかもしれません。 「製品解像度」を持つということは、このトライアングル全体を俯瞰し、3つの辺すべてを 健全に機能させる視点を持つ ということです。 質の高いアウトプットを生む土壌 「アウトプットの質」とは何でしょうか？ 単に「見た目が美しいUI」や「バグのないコード」のことでしょうか？ プロダクト開発における「質」とは 、「実現可能性（Feasibility）」と「事業性（Viability）」と「有用性（Desirability）」が高い次元で融合していること です。 お客様の要望（顕在ニーズ）に応えることは重要です。しかし、プロフェッショナルであるならば、その要望をそのまま形にするのではなく、「技術的に最も効率的で」「ビジネスとして持続可能で」「かつユーザーの課題を根本から解決する」ソリューションを導き出さなければなりません。 システム構造を知らなければ、非効率なUIを設計してしまうかもしれません。 事業戦略を知らなければ、来年には不要になる機能を作り込んでしまうかもしれません。製品解像度を高めることは、これら「見落とし」をなくし、手戻りを防ぎ、最初から精度の高いアウトプットを生み出すための必須条件だと考えています。 UX志向を支える「意思決定」の力 プロダクト開発は「意思決定」の連続です。 「Aという機能を優先するか、Bという改善を優先するか」 「リリースを早めるか、品質を高めるか」 こうした岐路に立ったとき、製品解像度の差が如実に現れます。 「OR」ではなく「AND」を模索する 解像度が低いと、安易なトレードオフ（ORの決断）に逃げがちです。 「ビジネス側の要求だから、UXは諦めよう（Business OR UX）」 「技術的に難しいから、仕様を落とそう（Tech OR UX）」 しかし、製品解像度が高い人は、各要素のつながりが見えているため、「AND」の解を模索できます。 「技術的にはこの制限があるが、UIの工夫でユーザーの負担は減らせるのではないか？」 「ビジネス目標のKPIは、この機能を少し簡略化しても達成できるのではないか？」 ビジネスの制約（利益・コスト）、技術的な制約、そしてお客様のニーズ。これら全てを深く理解しているからこそ、単なる妥協ではない、創造的な第三の案を生み出すことができるのです。 「架け橋」としての役割 プロダクト部のメンバーには、ビジネスチームと開発チームの「架け橋」としての役割が求められます。 通訳をイメージしてください。英語しか話せない人と日本語しか話せない人の間に入る通訳が、片方の言語しかわからなかったらどうなるでしょうか？ 会話は成立しません。 これと同じです。 ビジネスサイドの言語（売上、KPI、市場シェア）と、開発サイドの言語（アーキテクチャ、工数、技術的負債）。そしてお客様の言語（使いやすさ、課題解決）。 これら全ての「言語」を理解し、翻訳できるのが「製品解像度が高い人」です。 ビジネスチームには「なぜこのUX改善が将来の売上につながるのか」をロジカルに説明し、開発チームには「なぜこのビジネス要件が重要で、どう実装するのが最適か」を技術背景を踏まえて相談する。 この動きができる人材こそが、組織の中で真に信頼されるプロダクトパーソンとなれるのです。 ラクス プロダクト部としての「UX志向」 プロダクト部では本組織が組成される前（PdM組織の頃）から、以下を提示して、メンバーや自分自身もこれに従うようにしています。 製品解像度を高めるために では、どうすれば製品解像度を高めることができるのでしょうか？ 明日からできるアクションをいくつか提案します。 1. 「越境」を恐れない 自分の担当領域の外に出ましょう。デザイナーなら、売上の数字を見てみる。エンジニアなら、営業に同行してお客様の声を聞く。プロダクトマネージャーなら、システム構成図を書いてみる。 「それは私の仕事ではない」と線を引いた瞬間、解像度の上昇は止まります。 2. 「なぜ？」を問い続ける 仕様書や要件定義書を見たとき、そこに書かれていることの背景を想像してください。 「なぜこの機能が必要なのか？（ビジネス背景）」 「なぜこの実装方法なのか？（技術背景）」 「なぜ今なのか？（市場背景）」 わからないことは、その領域のプロフェッショナル（営業担当やエンジニア）に質問しましょう。彼らは自分の領域に関心を持ってくれる人を歓迎するはずです。 3. プロダクトの「歴史」と「未来」を知る 過去の意思決定の経緯（なぜこの機能があるのか）を知ることで、現在の制約の意味がわかります。そして、ロードマップ（未来の構想）を知ることで、今作るべきものの優先順位が見えてきます。点ではなく、線でプロダクトを捉えましょう。 製品解像度が上がると何が起きるか：アウトプットの質が変わる 製品解像度の価値は、抽象論ではなく、アウトプットに表れます。具体的には次の変化が起きます。 1) 要求仕様が“外れにくくなる” 解像度が高いと、論点の抜け漏れが減り、前提が揃うので、要求仕様（PRD）やデザインが当たりやすくなります。組織の重点取り組みでも「製品を取り巻く解像度を向上し、外れのない要求仕様を策定して開発に提供できる状態」を目指す、と明確に言語化されています。まさにここが、製品解像度が“成果”に変わる瞬間です。 2) トレードオフの説明責任が果たせる UXは必ずトレードオフの連続です。どれを捨て、どれを採るか。その判断が“十分な検討のないトレードオフ”になってしまうと、ステークホルダーは納得しないし、ユーザーも幸せにならない。製品解像度が高いチームは、制約を含めて説明できるので、合意形成が進みます。 3) 「事実に基づく」文化が回りやすくなる お客様の声、利用データ、市場情報、開発・運用の実態。これらを同じテーブルに乗せられるようになると、仮説と事実が区別され、議論の質が上がります。「なんとなくこう思う」から、「この事実があるからこう判断する」へ。UX志向の行動原理と相性が良いのはここです。 4) “作って終わり”から“学習して伸ばす”に変わる 解像度が高いチームは、指標（NSMや関連指標など）を置き、リリース後に成果を回収し、開発にも共有して次に活かします。改善が単発のイベントではなく、学習ループになります。 おまけ：製品解像度を上げるための「10の問い」（会議で使える） この問いは、答えを完璧に揃えるためというより、「ピントが合っていない領域」を早めに炙り出すために使ってもらえればと思います。 おわりに：最高のUXへの近道 「製品解像度を持つべきだ」という主張は、一見するとUX志向とは対極にある「ビジネス寄り」「システム寄り」の話に聞こえるかもしれません。 しかし、逆です。 本当に優れたUXを実現したいのであれば、製品解像度を高めることが一番の近道 なのです。 お客様のことしか見ていない「優しさ」は、時にプロダクトを脆弱にします。 ビジネスと技術という現実の厳しさも含めてプロダクトを愛し、理解する「強さ」こそが、長く愛され続けるサービスを育てる土壌となります。 私たちプロダクト部のメンバー一人ひとりが、お客様解像度だけでなく、この「製品解像度」という武器を持ったとき。私たちの組織は、ビジネスの要請にも、技術の進歩にも、そして何よりお客様の期待にも、かつてない高いレベルで応えられるようになるはずです。 まずは今日、隣の席の別職種のメンバーに、彼らが見ている「製品の景色」について聞いてみることから始めてみませんか？ 製品解像度を上げることは、意思決定の質を上げるだけでなく、結果として“お客様の業務が止まらない/迷わない”体験に直結すると自分は思っています。 記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー career-recruit.rakus.co.jp