はじめに：データ活用の理想と現実、そして進化するガバナンスの系譜 「データ駆動型経営」や「デジタルトランスフォーメーション（DX）の推進」が企業の至上命題となる中、多くの企業は依然としてデータからビジネス価値を創出するプロセスにおいて、大きな壁に直面しています。データサイエンティストが高度なAIモデルを構築し、経営層がデータドリブンな意思決定を目指す一方で、基盤となる「データ」そのものの管理と統制が追いついていないことが、プロジェクトの重大なボトルネックとなっています。 「経営会議において、営業部門とマーケティング部門から提出されたKPIの数値が合わず、議論が紛糾する」 「全社的な顧客データ統合プロジェクトが、部署ごとのデータサイロ化によって頓挫しかけている」 「IT部門はセキュリティや個人情報保護法を遵守するためデータ提供に慎重にならざるを得ず、結果としてビジネスのスピードを阻害してしまっている」 皆様の組織でも、このようなジレンマに心当たりはないでしょうか。これらの問題の根底にあるのは、個別のBIツールやETLツールの機能不足ではなく、組織として統一された「データガバナンス」——すなわちデータを企業の重要資産として管理し、安全に統制するための包括的なルールと技術的基盤——が不在であるという事実です。 真のデータガバナンスを設計するためには、過去数十年にわたるエンタープライズデータ管理のアーキテクチャの進化を俯瞰し、現代の要件を正確に捉える必要があります。データ管理のアプローチは、テクノロジーの進化とビジネス要件の変化に伴い、大きく3つの世代を経て発展してきました。 世代 主なアーキテクチャ 主導部門 核心概念 メリット 課題 第1世代 (〜2000年代前半) MDM, エンタープライズDWH IT部門 正確性, 中央集権的統制 高品質なデータ, 一貫性の担保 デリバリの大幅な遅延, 拡張性の欠如, ビジネスの変化への適応難 第2世代 (2010年代〜) クラウドデータレイク, モダンBI ビジネス部門, 分析部門 アジリティ, セルフサービス, データの民主化 高速な分析, 現場主導の柔軟な対応 データのサイロ化, 野良データマートの乱立, セキュリティリスク増大, 信頼性の低下 第3世代 (2020年代〜) 統合データプラットフォーム (レイクハウス, データクラウド) IT部門とビジネス部門の協調 ガードレール, コンテキスト, 統合ガバナンス 信頼とスピードの完全な両立, AI活用への適応 実装の技術的複雑性, 組織文化の変革の必要性 第1世代の中央集権型アプローチでは、IT部門が厳格なゲートキーパーとして機能し、堅牢なマスターデータ（MDM）を維持することに成功しましたが、ビジネスの意思決定速度に対するデータ供給の遅れが致命的でした。その反動として台頭した第2世代のセルフサービス型アプローチは、現場のアジリティを劇的に向上させたものの、自由の代償として「ガバナンスの欠如」を生み出しました。部門間でのKPI定義の不一致や情報漏洩リスクの増大が顕在化し、結果としてデータに対する組織的な信頼が損なわれる事態を招いています。 現在、エンタープライズアーキテクチャが目指すべき「第3世代」のモデルは、第1世代の「統制」と第2世代の「自由」を技術的に統合する試みです。この統合データガバナンスの核心は「ガードレール」と「コンテキスト」にあります。IT部門はユーザーの行く手を阻む「関所」ではなく、ユーザーが迷わず安全にデータを活用できる「舗装された高速道路（ガードレール付きの基盤）」を提供する役割へと進化しています。 本稿では、この第3世代のガバナンスをデータプラットフォームの内部に組み込み、パフォーマンスを犠牲にすることなくリアルタイムの統制を可能にする技術的イネイブラーとして、 Databricks の「Unity Catalog」と Snowflake の「Horizon Catalog」のアーキテクチャを紐解きます。さらに、これらの強固なガバナンス基盤の上で、dotData社の製品群がいかにして「セキュリティを担保したまま、業務部門主導の高度なAI分析」を実現するのか、その実践アプローチを紹介します。 データガバナンスの二面性：守りのブレーキと攻めのアクセル 最新の技術的詳細に踏み込む前に、現代のデータガバナンスが果たすべき本質的な役割を再定義します。データガバナンスは、相反するように見える二つの側面、「守りのブレーキ」と「攻めのアクセル」を同時に満たす、ビジネスのオペレーティングシステムとして機能しなければなりません。 守りのガバナンス（ブレーキ） とは、データ漏洩、不正利用、法令違反といった重大な事業リスクから企業を防衛するためのメカニズムです。一度の情報漏洩が経営に致命的なダメージを与えかねない現代において、個人情報保護法やGDPRといった厳格化する法規制への対応は、事業継続の必須要件です。 一方で 攻めのガバナンス（アクセル） とは、データの信頼性、正確性、鮮度をシステム的に担保し、誰もが安心してデータを利用できる環境を整備することです。信頼できるデータに迅速にアクセスできる状態こそが、新たなビジネスインサイトの発見を促し、データドリブンな意思決定を全社的に加速させる原動力となります。 かつてデータが複数のシステムに散在していた時代、ガバナンスもまたツールごとに分断され、サイロ化せざるを得ませんでした。しかし、Databricksが提唱する「レイクハウス」やSnowflakeが提供する「AI Data Cloud」によって、すべてのデータとAIワークロードが単一のプラットフォームに統合される時代が到来しました。これにより、メタデータとデータの実体が同一のセキュリティ境界内で管理され、アクセスポリシーの適用にタイムラグが生じない、真の「統合ガバナンス」が技術的に可能となったのです。 SnowflakeやDatabricksで実現する、次世代ガバナンスの「6つの技術的要件」 ここからは、AI時代のデータ活用に不可欠な要件を「6つの柱」として整理し、Databricks Unity CatalogとSnowflake Horizon Catalogがそれぞれの課題をどのように技術的に解決しているのか、具体的なコードスニペットや操作例を交えて解説します。自社に最適なアーキテクチャを設計する上で、両者のアプローチの違いを理解することは極めて重要です。 柱1：Databricks IQ/Snowflake Cortex AIによるアクティブメタデータ管理と自動カタログ化 データ活用の第一歩は、「自社にどのようなデータが存在し、どこにあるのか」を迅速かつ正確に把握することです。手作業でメンテナンスされる従来の静的なデータカタログは、すぐに陳腐化してしまうという課題を抱えていました。両プラットフォームは、AIを活用した「アクティブメタデータ」によってこの課題を解決します。 Databricks Unity CatalogとDatabricks IQによる自動文書化 Databricksでは、構造化・非構造化データに加え、機械学習モデルやダッシュボードといったAI資産までを一元管理可能です。 特筆すべきは、AIエンジン「Databricks IQ」が提供するアクティブメタデータ機能です。データの中身や実際のクエリ状況をAIが解析し、テーブルやカラムの説明文を自動生成・提案します。これにより、データエンジニアを悩ませていたドキュメント作成の工数が大幅に削減され、メタデータが常に最新の状態に保たれます。 SnowflakeのUniversal Searchとデータ分類の自動化 Snowflake Horizon Catalogは、大規模言語モデル（LLM）を内蔵したエンタープライズ検索エンジン「Universal Search」を提供しています。データベース内のオブジェクトだけでなく、Marketplaceのデータ製品に至るまで横断的な検索が可能です。 ユーザーがSnowsight（Web UI）の検索バーに「クローズしそうな営業案件」や「郵便番号」といった自然言語を入力すると、AIがオブジェクト名、コメント、過去のクエリ履歴から文脈を解析し、最適なテーブルを提示します。特筆すべきは、現在アクティブなロールがアクセス権限を持つオブジェクトのみが検索結果に表示される点です。権限のない機密データは完全に隠蔽されるため、データディスカバリと高度なセキュリティが両立します。 さらに、ガバナンスの基礎となる個人情報（PII）の所在を自動把握するため、データ分類の自動化機能を提供しています。 SQL -- 1. スキーマ全体のテーブルに対する分類ジョブをスケジュールし、自動タグ付けを有効化 CALL SYSTEM$CLASSIFY_SCHEMA('hr.tables', {'auto_tag': true}); -- 2. アカウント全体の最新の分類結果を監視システムで確認 SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.DATA_CLASSIFICATION_LATEST; -- 1. スキーマ全体のテーブルに対する分類ジョブをスケジュールし、自動タグ付けを有効化 CALL SYSTEM $CLASSIFY_SCHEMA( 'hr.tables' , { 'auto_tag' : true}); -- 2. アカウント全体の最新の分類結果を監視システムで確認 SELECT * FROM SNOWFLAKE . ACCOUNT_USAGE .DATA_CLASSIFICATION_LATEST; これにより、データスチュワードの運用負荷が劇的に軽減され、継続的なデータの棚卸しが実現します。 柱2：動的セキュリティ統制の実装：ABACをコードで定義・実現する例 「誰に、どのデータを、どこまで見せるか」。従来のロールベースアクセス制御（RBAC）では、組織やデータの増加に伴いロール数が爆発し、管理が破綻するケースが後を絶ちません。この課題に対し、ユーザー属性とデータ属性を動的に評価する属性ベースアクセス制御（ABAC）と、それをコードとして管理する「ポリシー as Code」のアプローチが標準となりつつあります。 Databricksにおける行フィルターと動的カラムマスキング Unity Catalogでは、SQL UDF（ユーザー定義関数）を用いて行フィルターやカラムマスクを定義し、ABACを実現します。 以下は、人事部門（HumanResourceDept）のメンバーにのみ社会保障番号（SSN）の平文を表示し、他部門にはマスクされた文字列を返す実装例です。 SQL -- マスキング用のSQL UDFを作成 CREATE FUNCTION ssn_mask(ssn STRING) RETURN CASE WHEN is_account_group_member('HumanResourceDept') THEN ssn ELSE '***-**-****' END; -- テーブル作成時にカラムマスクを適用 CREATE TABLE users ( name STRING, ssn STRING MASK ssn_mask ); -- マスキング用のSQL UDFを作成 CREATE FUNCTION ssn_mask (ssn STRING) RETURN CASE WHEN is_account_group_member( 'HumanResourceDept' ) THEN ssn ELSE '***-**-****' END ; -- テーブル作成時にカラムマスクを適用 CREATE TABLE users ( name STRING, ssn STRING MASK ssn_mask ); これらの関数はクエリ実行時に動的に評価されるため、データを物理的に分割して複数のビューを作成する手間が省け、運用の複雑性が劇的に低下します。 Snowflakeにおけるタグベースのマスキングと権限マッピング Snowflakeは、カラムごとではなく、付与された「タグ」に対してマスキングポリシーを紐付けるというスケーラブルなアプローチを採用しています。大規模環境であっても、数個のポリシーで全社のセキュリティ要件を網羅できます。 また行アクセスポリシーにおいては、ロジックをハードコーディングせず、権限マッピングテーブルを参照させる設計が推奨されています。組織変更時にも、ポリシー自体には触れずマスタデータの更新のみで即座に対応可能です。 SQL -- 1. セキュリティスキーマ内に権限マッピングテーブルを作成しデータを挿入 CREATE TABLE security.sales_entitlements (role_entitled string, region string); INSERT INTO security.sales_entitlements VALUES ('SALES_EU', 'eu'), ('SALES_US', 'us'); -- 2. マッピングテーブルを参照する動的な行アクセスポリシーを作成 CREATE OR REPLACE ROW ACCESS POLICY security.regional_access AS (region_val varchar) RETURNS BOOLEAN -> CASE WHEN IS_ROLE_IN_SESSION('GLOBAL_MANAGER') THEN TRUE WHEN EXISTS ( SELECT 1 FROM security.sales_entitlements WHERE IS_ROLE_IN_SESSION(role_entitled) AND region = region_val ) THEN TRUE ELSE FALSE END; -- 3. 保護対象テーブルにポリシーをバインド ALTER TABLE sales.raw_data ADD ROW ACCESS POLICY security.regional_access ON (region); -- 1. セキュリティスキーマ内に権限マッピングテーブルを作成しデータを挿入 CREATE TABLE security .sales_entitlements (role_entitled string, region string); INSERT INTO security . sales_entitlements VALUES ( 'SALES_EU' , 'eu' ), ( 'SALES_US' , 'us' ); -- 2. マッピングテーブルを参照する動的な行アクセスポリシーを作成 CREATE OR REPLACE ROW ACCESS POLICY security . regional_access AS (region_val varchar ) RETURNS BOOLEAN -> CASE WHEN IS_ROLE_IN_SESSION( 'GLOBAL_MANAGER' ) THEN TRUE WHEN EXISTS ( SELECT 1 FROM security . sales_entitlements WHERE IS_ROLE_IN_SESSION(role_entitled) AND region = region_val ) THEN TRUE ELSE FALSE END ; -- 3. 保護対象テーブルにポリシーをバインド ALTER TABLE sales . raw_data ADD ROW ACCESS POLICY security . regional_access ON (region); 柱3：リネージのリアルタイム管理・可視化による信頼性担保と品質監査の自動化 「このダッシュボードの売上数値は本当に正しいのか」「このテーブル定義を変更すると、どのAIモデルに影響が出るのか」 — データの出所と影響範囲を追跡するデータリネージと、品質状態を監視するオブザーバビリティは、経営層や事業部門からの「データに対する信頼」を勝ち取るための生命線です。 Databricksにおける自動化されたデータリネージ Unity Catalogは、Databricks上で実行されるすべての処理（SQL、Pythonなど言語を問わず）を監視し、データの流れをテーブルレベルのみならず、カラム（列）レベルで自動的かつリアルタイムに追跡します。エージェントのインストールやコード改修は一切不要です。 Catalog ExplorerのUIから「Lineage」タブを開き「See Lineage Graph」をクリックするだけで、データの依存関係が視覚的なグラフとして全画面表示されます。特定のカラムをクリックすれば、そのデータがどこから来て、どのダッシュボードへ流れていくのかが瞬時にハイライトされ、安全な変更管理と迅速な障害原因の特定が可能となります。 SnowflakeのData Quality Monitoring (DMF) Snowflakeは、Data Metric Functions (DMF) を用いてデータ品質を継続的かつ自動的に監査する仕組みを提供しています。ユーザー独自のビジネス要件に基づいた品質チェック（例：特定フォーマットのメールアドレスの割合）をカスタムDMFとして定義し、スケジュール実行させることができます。 SQL -- 不正なメールアドレス形式をカウントするカスタムDMFをバインドし、日次監査をスケジュール ALTER TABLE hr.tables.customers ADD DATA METRIC FUNCTION governance.dmfs.invalid_email_count ON (email); ALTER TABLE hr.tables.customers SET DATA_METRIC_SCHEDULE = 'USING CRON 0 8 * * * UTC'; -- 不正なメールアドレス形式をカウントするカスタムDMFをバインドし、日次監査をスケジュール ALTER TABLE hr . tables .customers ADD DATA METRIC FUNCTION governance . dmfs .invalid_email_count ON (email); ALTER TABLE hr . tables .customers SET DATA_METRIC_SCHEDULE = 'USING CRON 0 8 * * * UTC' ; 実行結果はSnowsightのUI上で時系列の折れ線グラフとして視覚化され、データマネジメント担当者はデータの異常値や劣化を一目で把握できます。 また、SnowflakeにおいてもDatabricksと同様に、自動でデータリネージを可視化する機能が備わっています。 柱4：ビジネス指標の計算ロジック一元化：Databricks Unity Catalog Metrics/Snowflake Semantic Views 「部門間でKPI（重要業績評価指標）の定義が異なり、数値が合わない」 — これは多くの企業で発生する根深い課題です。生データとBIツールやAIの間に立って「ビジネスの意味（セマンティクス）」を一元管理するのがセマンティックレイヤーです。 Databricks Unity Catalog Metrics Databricksでは、「Unity Catalog Metrics」を利用してビジネス指標の計算ロジックをUnity Catalog内に一元的に保存・管理できます。これにより、BIツール、ノートブック、AIエージェントのどこからアクセスしても、組織全体で同じ定義に基づいた一貫性のある数値を参照することが可能になります。 複雑な集計ロジックをSQLに都度記述するのではなく、MEASURE() 関数を利用してシンプルかつ安全に指標を呼び出します。 SQL SELECT `Order Month`, `Order Status`, MEASURE(`Order Count`), MEASURE(`Total Revenue`) FROM orders_metric_view GROUP BY ALL; SELECT `Order Month` , `Order Status` , MEASURE( `Order Count` ), MEASURE( `Total Revenue` ) FROM orders_metric_view GROUP BY ALL; Snowflake Semantic ViewsとCortex Analyst Snowflakeも同様に、YAML形式でビジネスロジックを定義する「Semantic Views」を提供しています。特筆すべきは、このモデル内に「検証済みクエリ」を組み込める点です。この定義は、自然言語を正確なSQLに変換する生成AI機能「Cortex Analyst」に対する強力なプロンプトとして機能します。RBACが完全に適用された状態で、生成AIがハルシネーション（もっともらしい嘘）を起こすことなく、正確なビジネスデータに基づいた回答を提示します。 柱5：データ複製を排除するZero-Copyアーキテクチャ：Delta SharingとSecure Data Sharing 外部ツールやパートナー企業と連携するためにデータをCSV等でエクスポートすると、その瞬間にデータの鮮度が失われ、ガバナンスの統制外に置かれるという致命的なセキュリティリスクが発生します。これを解決するのが、データを物理的に移動させることなくポインタの共有のみでライブデータへのアクセスを提供する「Zero-Copy（ゼロコピー）」アーキテクチャです。 DatabricksのDelta SharingとSnowflakeのSecure Data Sharing Databricksはオープンソースのプロトコルである「Delta Sharing」を、Snowflakeは「Secure Data Sharing」をそれぞれ提供しています。いずれも、提供側（Provider）が直感的なUIまたはシンプルなSQLでShareを作成し、受信側（Consumer）に権限を付与するだけで、データの複製を一切行うことなく、即座に最新のデータへのセキュアなアクセスを可能にします。 一方で、Zero-Copyアーキテクチャは本質的にデータ利用時にネットワーク通信が発生するため、データ転送にかかる時間がデータアプリケーションの応答性能に影響を与えることには注意が必要です。この影響を最小化するために、データ処理（SQLクエリ実行など）をデータソース側に実行させて転送データ量を小さくするクエリプッシュダウンの仕組みが備えられていることが多いです。 柱6：ベンダーロックインを回避するオープン規格（Iceberg/Delta/Unity Catalog/Polaris）の採用 特定のベンダーの独自フォーマットにデータがロックインされると、将来的なアーキテクチャ変更時に多大な移行コストが発生します。 Databricksは「Delta Lake」や「Delta Sharing」に加え、ガバナンスレイヤーである「Unity Catalog」そのもののオープンソース化を発表しました。一方のSnowflakeも、オープンフォーマットである「Apache Iceberg」をネイティブサポートし、オープンカタログ「Polaris」へのメタデータ自動同期機能を提供しています。これにより、企業は特定のベンダーに縛られることなく、将来にわたって柔軟で拡張性の高いデータエコシステムを維持できます。 境界を超える統制：外部アプリケーションとのセキュアな連携設計 SaaSやBIツール、高度なAIプラットフォームといった「外部アプリケーション」と自社のデータ基盤を連携させる際、従来の「パスワードを共有するシステム共通アカウント」は、担当者の異動に伴う管理漏れやブルートフォース攻撃に対する脆弱性という大きなリスクを抱えていました。 Databricksにおける「 サービスプリンシパル（Service Principal） 」や、Snowflakeにおける「 Service User 」は、自動化ツールやアプリケーションのために設計された「人間ではない」特別なアイデンティティです。 これらのアカウントはパスワード認証を排除し、OAuth 2.0のM2MトークンやRSAキーペア認証といったセキュアな方式を強制します。最も重要な点は、これらの外部連携アカウントもまた、Unity CatalogやHorizon Catalogの強固なガバナンス（ABAC、行フィルター、監査ログ）の完全な統制下に置かれるということです。 dotDataの実践アプローチ：「Data Gravity」がもたらすAIとガバナンスの統合 これまでに詳述した最先端のクラウドデータプラットフォームのガバナンス基盤を、いかにして高度なAIによるビジネス価値（ROI）の創出へと結びつけるか。IT部門の運用負荷を下げつつ、業務部門の自走化を促すための最も先進的な解答の一つが、エンタープライズAIの自動化リーダーであるdotData社の製品アプローチです。 従来のAI分析では、モデル学習や特徴量設計のためにデータウェアハウスから外部環境へ大量のデータを「抽出・エクスポート」する必要がありました。しかし前述の通り、データを外に出した瞬間にセキュリティリスクは増大し、ガバナンスは破綻します。 dotData社は、この構造的課題を根本から解決するため、 「Data Gravity（データの引力：データを動かすのではなく、データがある場所へ計算処理・AIを持ち込む）」 というアーキテクチャ思想を採用しました。そして、主力製品である「dotData Insight」と「dotData Feature Factory」の双方において、 DatabricksおよびSnowflakeの両プラットフォームとのネイティブ統合 を果たしています。各プラットフォームとのネイティブ統合の詳細については、 dotData on Databricks および dotData on Snowflake の各ページで詳しくご紹介しています。 業務部門が主役となる「dotData Insight」のデータ分析基盤統合 「 dotData Insight 」は、データサイエンティスト不在の業務部門であっても、直感的なUIを通じて高度なビジネスインサイトの発見や施策立案を自走化できるプラットフォームです。直近のアップデートにより、DatabricksおよびSnowflakeからデータをコピーせずに解析・特徴の抽出を実行できるようになり、それぞれのセキュリティを完全に継承するようになりました。 Databricksとのネイティブ統合 データはDelta Lake上に保持されたまま、Unity Catalogの高度なデータアクセス制御（ABAC等）を完全に享受できます。 dotDataのAIによる複雑な特徴量探索は外部の計算リソースに依存せず、Databricksの「Lakeflow Jobs」を通じて直接実行されます。これにより、各部門のニーズに合わせたセキュアな分析環境が即座に立ち上がります。 Snowflakeとのネイティブ統合 dotDataの心臓部である独自の特徴量自動設計エンジンが、Snowflake内の「Snowpark Container Services (SPCS)」上で直接実行されます。dotData InsightのWebサービスやコンテナはSnowflake環境の厳格なセキュリティ管理下で動作するため、Horizon Catalogで定義された行アクセスポリシーやマスキングルールが、AIエンジンに対して完全に強制・継承されます。 本番品質のAI実装を加速する「dotData Feature Factory」 データサイエンティストや機械学習エンジニア向けに、特徴量設計のプロセスを自動化・アセット化する「 dotData Feature Factory 」もまた、両プラットフォームに対応する柔軟なデプロイメントオプションを備えています。 Databricks環境でのLakeflow Jobsとカタログの活用 Databricks環境において、膨大な計算リソースを要求される「特徴量設計」のプロセスは、DatabricksのネイティブなワークフローエンジンであるLakeflow Jobsを通じて分散処理されます。ユーザー企業はUnity Catalogによる堅牢なアクセス制御を妥協することなく、dotDataの「世界最先端の特徴量自動設計」を利用可能になります。 Snowflake環境でのSPCS実行オプション 同様に、dotData Feature FactoryにはSnowflakeのSnowpark Container Services (SPCS) を活用して実行するオプションも搭載されています。これにより、Snowflake内に蓄積されたデータを外に出すことなく、大規模な特徴量空間の探索と生成をSnowflakeのコンピュートプール内で安全に完結させることができます。 特筆すべきは、これらの統合環境で発見された価値ある特徴量が、本番品質・スケーラビリティをもった「特徴量パイプライン」として自動生成される点です。従来、属人化して捨てられていたデータ加工プロセスが再利用可能な企業の「アセット」としてカタログ上に蓄積され、AI開発プロセス全体の効率と品質が飛躍的に向上し、PoC（概念実証）から本番運用への移行という「死の谷」をスムーズに越えることができます。 おわりに 本稿で詳述した通り、DatabricksのUnity CatalogやSnowflakeのHorizon Catalogに代表される次世代のデータガバナンスは、もはや単なる「コンプライアンスのための制限ルール」ではありません。それは、AIの持つ強大な力を安全かつ爆発的に引き出し、ビジネスの意思決定を全社規模で加速させるための、真の「エンタープライズのオペレーティングシステム」へと昇華しています。 ポリシーをコードとして管理し、AIを活用してアクティブにメタデータを生成し、ゼロコピーで安全にデータを連携する。この堅牢な基盤の上に、dotDataが提供する特徴量自動設計プラットフォームをネイティブに統合することで、企業は「IT部門が求めるセキュリティ・統制」と「業務部門が求めるアジリティ・インサイト」をかつてない高い次元で両立させることができます。 経営層、IT部門、そしてデータマネジメントを牽引する皆様にとって、これからの企業競争の優位性は「いかに迅速に、かつ安全に、現場の業務部門が自律してデータからビジネス価値を引き出せるか」に懸かっています。データのサイロ化や分析プロセスの属人化に終止符を打ち、攻めと守りを両立する統合データガバナンスの真の価値を体験する時が来ています。 dotDataと一緒に、新たなビジネスチャンスを見つけませんか？ dotDataの製品群は、お客様の組織のAI成熟段階に関わらず、データの加工から特徴量設計、機械学習モデルの構築に至るプロセス全体を自動化し、エンタープライズにおけるAIとデータ活用の民主化を強力に支援いたします。 DatabricksやSnowflakeの強固な統合データガバナンス基盤の上でシームレスに動作する、dotData Feature Factory による本番品質の特徴量パイプライン自動生成や、dotData Insightによる事業部門主導のビジネスインサイト自動探索・AIドリルダウン分析の真価を、ぜひご自身の環境でお確かめください。 様々なビジネス課題の解決やユースケースについてのご相談、最新の製品デモのリクエストにつきましては、以下の連絡先またはお問い合わせフォームよりお気軽にご連絡ください。経営層、事業部門、分析部門、IT部門のすべての皆様に、自動化による確かなビジネス価値をご提供いたします。 製品・サービスに関するお問い合わせ・デモのリクエスト： contact-j@dotdata.com Webお問い合わせフォーム： https://jp.dotdata.com/contact-us/   皆様のデータドリブンな組織変革とビジネスの飛躍を、dotDataが全力で伴走・サポートいたします。 The post 攻めと守りを両立する次世代データガバナンス：AI時代の統合データ基盤を実現するDatabricksとSnowflake appeared first on dotData .

本記事は 2026 年 1 月 26 日 に公開された「 Top 10 best practices for Amazon EMR Serverless 」を翻訳したものです。 Amazon EMR Serverless は Amazon EMR のデプロイオプションの 1 つで、 Apache Spark や Apache Hive などのオープンソースビッグデータ分析フレームワークを、クラスターやサーバーの設定・管理・スケーリングなしで実行できます。EMR Serverless は、データストレージ、ストリーミング、オーケストレーション、モニタリング、ガバナンスにわたる Amazon Web Services (AWS) サービスと統合し、サーバーレス分析ソリューションを実現します。 本記事では、EMR Serverless ワークロードのパフォーマンス、コスト、スケーラビリティを最適化するためのベストプラクティス 10 選を紹介します。EMR Serverless を使い始めたばかりの方も、既存の本番ワークロードを改善したい方も、効率的でコスト効率の高いデータ処理パイプラインの構築に役立つ内容です。以下の図は、EMR Serverless のエンドツーエンドアーキテクチャを示しており、分析パイプラインへの統合方法を表しています。 1. アプリケーションは一度定義して繰り返し使う EMR Serverless アプリケーション はクラスターテンプレートに相当し、ジョブ送信時にインスタンス化され、再作成せずに複数のジョブを処理できます。アプリケーションを再利用することで起動レイテンシーを削減し、運用管理を簡素化できます。 EMR on EC2 一時クラスターの一般的なワークフロー: EMR Serverless の一般的なワークフロー: アプリケーションは自己管理型のライフサイクルを備えており、必要なときに手動操作なしでリソースをプロビジョニングします。ジョブが送信されると自動的にキャパシティをプロビジョニングします。事前初期化キャパシティのないアプリケーションでは、ジョブ完了後すぐにリソースが解放されます。事前初期化キャパシティが設定されている場合、設定されたアイドルタイムアウト (デフォルト 15 分) を超えるとワーカーが停止します。このタイムアウトは、 CreateApplication または UpdateApplication API の AutoStopConfig でアプリケーションレベルで調整できます。たとえば、ジョブが 30 分ごとに実行される場合、アイドルタイムアウトを延長すると実行間の起動遅延を解消できます。 ほとんどのワークロードには、オンデマンドキャパシティが適しています。ジョブの要件に基づいてリソースを自動スケーリングし、アイドル時には課金されません。ETL ワークロード、バッチ処理ジョブ、最大限のジョブ回復力が必要なシナリオなど、一般的なユースケースに適したコスト効率の高いアプローチです。 即時起動が厳密に求められるワークロードには、オプションで 事前初期化キャパシティ を設定できます。事前初期化キャパシティは、数秒以内にジョブを実行できるドライバーとエグゼキューターのウォームプールを作成します。ただし、パフォーマンスが向上する分、コストは高くなります。事前初期化ワーカーはアプリケーションが停止状態になるまでアイドル中も継続的に課金されます。また、事前初期化キャパシティはジョブを単一のアベイラビリティゾーンに制限するため、回復力が低下します。 事前初期化キャパシティを検討すべきケース: 起動レイテンシーが許容できない、サブ秒の SLA 要件がある時間的制約の厳しいジョブ ユーザー体験が即時応答に依存するインタラクティブ分析 数分ごとに実行される高頻度の本番パイプライン それ以外のほとんどのケースでは、オンデマンドキャパシティがコスト、パフォーマンス、回復力のバランスに優れています。 リソースの最適化に加えて、ワークロード全体でのアプリケーションの整理方法も検討してください。本番ワークロードでは、ビジネスドメインやデータの機密レベルごとに別々のアプリケーションを使用しましょう。アプリケーションを分離することでガバナンスが向上し、重要なジョブと重要でないジョブ間のリソース競合を防げます。 2. AWS Graviton プロセッサ で価格性能比を向上 適切なプロセッサアーキテクチャの選択は、パフォーマンスとコストの両方に大きく影響します。 Graviton ARM ベースプロセッサは、x86_64 と比較して優れた価格性能比を実現します。 EMR Serverless は最新のインスタンス世代が利用可能になると自動的に更新されるため、追加設定なしで最新のハードウェア改善の恩恵を受けられます。 EMR Serverless で Graviton を使用するには、 CreateApplication でアプリケーション作成時に architecture パラメータで ARM64 を指定するか、既存のアプリケーションには UpdateApplication API を使用します: aws emr-serverless create-application \   --name my-spark-app \   -- SPARK \   --architecture ARM64 \   --release-label emr-7.12.0 Graviton 使用時の考慮事項: リソースの可用性 – 大規模ワークロードの場合、Graviton ワーカーのキャパシティプランニングについて AWS アカウントチームに相談することを検討してください。 互換性 – 一般的に使用される標準ライブラリの多くは Graviton (arm64) アーキテクチャと互換性がありますが、使用しているサードパーティパッケージやライブラリの互換性を検証する必要があります。 移行計画 – Graviton の導入には戦略的なアプローチを取りましょう。新しいアプリケーションはデフォルトで ARM64 アーキテクチャで構築し、既存のワークロードは中断を最小限に抑える段階的な移行計画で 移行 します。段階的に移行することで、信頼性を損なわずにコストとパフォーマンスを最適化できます。 ベンチマークの実施 – 正確な価格性能比はワークロードによって異なります。ワークロード固有の結果を把握するために、独自のベンチマークを実施することを推奨します。詳細は「 Achieve up to 27% better price-performance for Spark workloads with AWS Graviton2 on Amazon EMR Serverless 」を参照してください。 3. デフォルトを活用し、必要に応じてワーカーを適正化 ワーカー はワークロードのタスクを実行するために使用されます。EMR Serverless のデフォルト設定はほとんどのユースケースに最適化されていますが、処理時間の改善やコスト効率の最適化のためにワーカーのサイズを適正化する必要がある場合があります。EMR Serverless ジョブを送信する際は、メモリサイズ (GB) やコア数などのワーカー設定を Spark プロパティで定義することを推奨します。 EMR Serverless のデフォルトワーカーサイズは 4 vCPU、16 GB メモリ、20 GB ディスクです。一般的にほとんどのジョブにバランスの取れた構成ですが、パフォーマンス要件に応じてサイズを調整することもできます。事前初期化ワーカーに特定のサイズを設定している場合でも、ジョブ送信時に必ず Spark プロパティを設定してください。事前初期化キャパシティを超えてスケールする際に、デフォルトプロパティではなく指定したワーカーサイズが使用されます。Spark ワークロードの適正化では、ジョブの vCPU:メモリ比率が重要です。エグゼキューターの仮想 CPU コアあたりに割り当てるメモリ量は、この比率で決まります。Spark エグゼキューターはデータを効果的に処理するために CPU とメモリの両方が必要で、最適な比率はワークロードの特性によって異なります。 まずは以下のガイダンスを参考にし、ワークロード固有の要件に基づいて設定を調整してください。 エグゼキューター設定 以下の表は、一般的なワークロードパターンに基づく推奨エグゼキューター設定です: ワークロードタイプ 比率 CPU メモリ 設定 コンピューティング集約型 1:2 16 vCPU 32 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=32G 汎用 1:4 16 vCPU 64 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=64G メモリ集約型 1:8 16 vCPU 108 GB spark.emr-serverless.executor.cores=16spark.emr-serverless.executor.memory=108G ドライバー設定 以下の表は、一般的なワークロードパターンに基づく推奨ドライバー設定です: ワークロードタイプ 比率 CPU メモリ 設定 汎用 1:4 4 vCPU 16 GB spark.emr-serverless.driver.cores=4spark.emr-serverless.driver.memory=16G Apache Iceberg ワークロード 1:8 (メタデータルックアップ用の大きなドライバー) 8 vCPU 60 GB spark.emr-serverless.driver.cores=8spark.emr-serverless.driver.memory=60G 設定をさらにモニタリングおよびチューニングするには、 Amazon CloudWatch ジョブワーカーレベルメトリクス でワークロードのリソース消費を監視し、ボトルネックを特定します。CPU 使用率、メモリ使用量、ディスク使用率のメトリクスを追跡し、以下の表を参考に設定を調整してください。 観測されたメトリクス ワークロードタイプ 推奨アクション 1 高メモリ (>90%)、低 CPU (<50%) メモリバウンドワークロード vCPU:メモリ比率を増加 2 高 CPU (>85%)、低メモリ (<60%) CPU バウンドワークロード vCPU 数を増加し、1:4 比率を維持 (例: 8 vCPU 使用時は 32 GB メモリ) 3 高ストレージ I/O、通常の CPU/メモリ、長いシャッフル操作 シャッフル集約型 サーバーレスストレージ または シャッフル最適化ディスク を有効化 4 全メトリクスで低使用率 過剰プロビジョニング ワーカーサイズまたは数を削減 5 一貫して高使用率 (>90%) 過少プロビジョニング ワーカー仕様をスケールアップ 6 頻繁な GC 一時停止** メモリ圧迫 メモリオーバーヘッドを増加 (10〜15%) **頻繁なガベージコレクション (GC) の一時停止は、Spark UI の Executors タブで確認できます。GC time 列があり、一般的にタスク時間の 10% 未満であるべきです。また、ドライバーログに GC (Allocation Failure)] メッセージが頻繁に含まれている場合もあります。 4. T シャツサイジングでスケーリング境界を制御 デフォルトでは、EMR Serverless は 動的リソース割り当て (DRA) を使用し、ワークロードの需要に基づいてリソースを自動スケーリングします。EMR Serverless はジョブのメトリクスを継続的に評価してコストと速度を最適化するため、必要なワーカー数を見積もる必要がありません。 コスト最適化と予測可能なパフォーマンスのために、以下のいずれかのアプローチでスケーリングの上限を設定できます: ジョブレベルで spark.dynamicAllocation.maxExecutors パラメータを設定 アプリケーションレベルの最大キャパシティ を設定 各ジョブの spark.dynamicAllocation.maxExecutors を個別に細かく調整するのではなく、ワークロードプロファイルを表す T シャツサイズとして設定を考えることができます: ワークロードサイズ ユースケース spark.dynamicAllocation.maxExecutors Small 探索的クエリ、開発 50 Medium 定期的な ETL ジョブ、レポート 200 Large 複雑な変換、大規模処理 500 この T シャツサイジングアプローチにより、キャパシティプランニングが簡素化され、個々のジョブを最適化するのではなく、ワークロードカテゴリに基づいてパフォーマンスとコスト効率のバランスを取れます。 EMR Serverless リリース 6.10 以降では、 spark.dynamicAllocation.maxExecutors のデフォルト値は無制限ですが、それ以前のリリースでは 100 です。 EMR Serverless はジョブの各ステージで必要なワークロードと並列性に基づいて、ワーカーを自動的にスケールアップまたはスケールダウンします。ジョブのメトリクスを継続的に評価してコストと速度を最適化するため、ワーカー数を見積もる必要がありません。 ただし、予測可能なワークロードの場合、エグゼキューター数を静的に設定したい場合があります。その場合は DRA を無効にしてエグゼキューター数を手動で指定します: spark.dynamicAllocation.enabled=false spark.executor.instances=10 5. EMR Serverless ジョブに適切なストレージをプロビジョニング ストレージオプションを理解し、適切にサイジングすることで、ジョブの失敗を防ぎ、実行時間を最適化できます。EMR Serverless は、ジョブ実行中の中間データを処理するストレージオプションが複数あります。選択するストレージオプションは EMR リリースとユースケースによって異なります。EMR Serverless で利用可能なストレージオプションは以下のとおりです: ストレージタイプ EMR リリース ディスクサイズ範囲 ユースケース メリット サーバーレスストレージ (推奨) 7.12+ N/A (自動スケーリング) ほとんどの Spark ワークロード、特にデータ集約型ワークロード ストレージコストなし 自動スケーリング ディスク障害の削減 最大 20% のコスト削減 標準ディスク 7.11 以前 ワーカーあたり 20〜200 GB 10 TB 未満のデータセットを処理する小〜中規模ワークロード シンプルな設定 デフォルト 20 GB でほとんどのワークロードに対応 最適なスループットには最大 200 GB シャッフル最適化ディスク 7.1.0+ ワーカーあたり 20〜2,000 GB マルチ TB を処理する大規模 ETL ワークロード 高 IOPS とスループット ワーカーあたり最大 2 TB のキャパシティ ストレージ設定をワークロードの特性に合わせることで、EMR Serverless ジョブを大規模でも効率的かつ安定的に実行できます。 6. マルチ AZ がデフォルトで組み込みの回復力を提供 EMR Serverless アプリケーションは、事前初期化キャパシティが有効でない場合、最初からマルチ AZ です。フェイルオーバーが組み込まれているため、手動操作なしで AZ 障害に対応できます。単一のジョブは単一のアベイラビリティゾーン内で動作し、クロス AZ データ転送コストを防ぎます。後続のジョブは複数の AZ に適切に分散されます。EMR Serverless が AZ の障害を検出すると、新しいジョブを正常な AZ に送信し、AZ 障害にもかかわらずワークロードの実行を継続できます。 EMR Serverless のマルチ AZ 機能を最大限に活用するには、以下を確認してください: 複数のアベイラビリティゾーンにまたがるサブネットを選択して VPC へのネットワーク接続 を設定 アプリケーションを単一の AZ に制限する事前初期化キャパシティを避ける ワーカーのスケーリングをサポートするために各サブネットに十分な IP アドレスがあることを確認 マルチ AZ に加えて、Amazon EMR 7.1 以降では ジョブの回復力 を有効にでき、エラーが発生した場合にジョブを自動的にリトライできます。複数のアベイラビリティゾーンが設定されている場合、別の AZ でもリトライされます。この機能は バッチ ジョブと ストリーミング ジョブの両方で有効にできますが、リトライ動作は両者で異なります。 最大リトライ回数を定義するリトライポリシーを指定してジョブの回復力を設定します。バッチジョブのデフォルトは自動リトライなし (maxAttempts=1) です。ストリーミングジョブでは、EMR Serverless は無制限にリトライし、1 時間以内に 5 回失敗するとリトライを停止するスラッシング防止機能が組み込まれています。このしきい値は 1〜10 回の間で設定できます。詳細は「 Job resiliency 」を参照してください。 ジョブをキャンセルする必要がある場合、デフォルトの即時終了ではなく、ジョブをクリーンにシャットダウンするための 猶予期間 を指定できます。カスタムクリーンアップアクションを実行する必要がある場合は、カスタムシャットダウンフックも含められます。 マルチ AZ サポート、自動ジョブリトライ、グレースフルシャットダウン期間を組み合わせることで、中断に耐え、手動操作なしでデータの整合性を維持できる EMR Serverless ワークロードを構築できます。 7. VPC 統合でセキュリティと接続性を拡張 デフォルトでは、EMR Serverless は Amazon Simple Storage Service (Amazon S3)、 AWS Glue 、 Amazon CloudWatch Logs 、 AWS Key Management Service (AWS KMS)、 AWS Security Token Service (AWS STS)、 Amazon DynamoDB 、 AWS Secrets Manager などの AWS サービスにアクセスできます。 Amazon Redshift や Amazon Relational Database Service (Amazon RDS) など VPC 内のデータストアに接続するには、EMR Serverless アプリケーションの VPC アクセスを設定する必要があります。 EMR Serverless アプリケーションの VPC アクセスを設定する際は、最適なパフォーマンスとコスト効率のために以下の考慮事項に留意してください: 十分な IP アドレスを計画 – 各ワーカーはサブネット内で 1 つの IP アドレスを使用します。ジョブのスケールアウト時に起動されるワーカーも含まれます。IP アドレスが不足すると、ジョブがスケールできず、ジョブの失敗につながる可能性があります。最適なパフォーマンスのために サブネットプランニングのベストプラクティス に従っていることを確認してください。 プライベートサブネットのアプリケーションには Amazon S3 用ゲートウェイエンドポイント を設定 – VPC エンドポイントなしでプライベートサブネットで EMR Serverless を実行すると、Amazon S3 トラフィックが NAT ゲートウェイ経由でルーティングされ、追加のデータ転送料金が発生します。S3 用 VPC エンドポイントにより、トラフィックを VPC 内に保持し、コストを削減して Amazon S3 操作のパフォーマンスを向上できます。 ネットワークインターフェースの AWS Config コストを管理 – EMR Serverless は各ワーカーに対して AWS Config にエラスティックネットワークインターフェースレコードを生成し、ワークロードのスケールに伴いコストが蓄積される可能性があります。EMR Serverless ネットワークインターフェースの AWS Config 追跡が不要な場合は、リソースベースの除外やタグ付け戦略を使用してフィルタリングし、他のリソースの AWS Config カバレッジは維持することを検討してください。 詳細は「 Configuring VPC access for EMR Serverless applications 」を参照してください。 8. ジョブ送信と依存関係管理を簡素化 EMR Serverless は StartJobRun API による柔軟なジョブ送信をサポートしており、完全な spark-submit 構文を受け付けます。ランタイム環境の設定には、 spark.emr-serverless.driverEnv と spark.executorEnv プレフィックスを使用して、ドライバーとエグゼキュータープロセスの環境変数を設定します。機密設定やランタイム固有の設定を渡す際に特に便利です。 Python アプリケーションの場合、venv を作成し、tar.gz アーカイブとしてパッケージ化するか、 spark.archives を使用して Amazon S3 にアップロードし、適切な PYSPARK_PYTHON 環境変数を設定して、仮想環境で依存関係をパッケージ化すると、ドライバーとエグゼキューターワーカー全体で Python の依存関係を利用できます。 高負荷時の制御を向上させるには、 ジョブの同時実行とキューイング (EMR 7.0.0+ で利用可能) を有効にして、同時に実行できるジョブ数を制限します。この機能により、同時実行制限を超えて送信されたジョブは、リソースが利用可能になるまでキューに入れられます。 ジョブの同時実行とキュー設定は、 CreateApplication または UpdateApplication API の SchedulerConfiguration プロパティで設定できます。 --scheduler-configuration '{"maxConcurrentRuns": 5, "queueTimeoutMinutes": 30}' 9. EMR Serverless の設定で制限を適用 EMR Serverless はワークロードの需要に基づいてリソースを自動スケーリングし、ほとんどのユースケースで Spark 設定のチューニングなしで機能する最適化されたデフォルトが用意されています。コスト管理のために、予算とパフォーマンス要件に合ったリソース制限を設定できます。高度なユースケースでは、リソース消費を細かく調整し、クラスターベースのデプロイメントと同等の効率を実現する設定オプションも提供しています。制限を適切に設定することで、パフォーマンスとコスト効率のバランスを取れます。 制限タイプ 目的 設定方法 ジョブレベル 個々のジョブのリソースを制御 spark.dynamicAllocation.maxExecutors または spark.executor.instances アプリケーションレベル アプリケーションまたはビジネスドメインごとのリソースを制限 アプリケーション作成時または更新時に最大キャパシティを設定 アカウントレベル 全アプリケーションにわたる異常なリソーススパイクを防止 自動調整可能なサービスクォータ「 Max concurrent vCPUs per account 」。 Service Quotas コンソール から引き上げをリクエスト これら 3 つのレイヤーの制限が連携して、異なるスコープで柔軟にリソースを管理できます。ほとんどのユースケースでは、T シャツサイジングアプローチによるジョブレベルの制限設定で十分であり、アプリケーションレベルとアカウントレベルの制限はコスト管理の追加的なガードレールになります。 10. CloudWatch、Prometheus、Grafana でモニタリング EMR Serverless ワークロードのモニタリングにより、デバッグ、コスト最適化、パフォーマンス追跡が容易になります。EMR Serverless は連携する 3 つのモニタリング階層があります: Amazon CloudWatch、 Amazon Managed Service for Prometheus 、 Amazon Managed Grafana です。 Amazon CloudWatch – CloudWatch 統合 はデフォルトで有効になっており、AWS/EMRServerless 名前空間にメトリクスを発行します。EMR Serverless はアプリケーションレベル、ジョブ、ワーカータイプ、キャパシティ割り当てタイプレベルで毎分 CloudWatch にメトリクスを送信します。CloudWatch を使用して、ワークロードの可観測性を高める ダッシュボード を設定したり、ジョブの失敗、スケーリングの異常、SLA 違反に対する アラーム を設定できます。CloudWatch と EMR Serverless を使用することで、ユーザーに影響が出る前に問題を検知できます。 Amazon Managed Service for Prometheus – EMR Serverless リリース 7.1+ では、Prometheus を有効にして詳細な Spark エンジンメトリクス を Amazon Managed Service for Prometheus にプッシュでき、メモリ使用量、シャッフルボリューム、GC 圧力などエグゼキューターレベルで可視化できます。メモリ制約のあるエグゼキューターの特定、シャッフルが多いステージの検出、データスキューの発見に活用できます。 Amazon Managed Grafana – Grafana は CloudWatch と Prometheus の両方のデータソースに接続し、可観測性と相関分析を統合した単一画面として利用できます。3 つの階層を組み合わせることで、インフラストラクチャの問題とアプリケーションレベルのパフォーマンス問題を関連付けられます。 追跡すべき主要メトリクス: ジョブの完了時間と成功率 ワーカーの使用率とスケーリングイベント シャッフルの読み取り/書き込みボリューム メモリ使用パターン 詳細は「 Monitor Amazon EMR Serverless workers in near real time using Amazon CloudWatch 」を参照してください。 まとめ 本記事では、パフォーマンスの最適化、コスト管理、大規模での安定した運用を実現するための Amazon EMR Serverless のベストプラクティス 10 選を紹介しました。アプリケーション設計、ワークロードの適正化、アーキテクチャの選択に注力することで、効率的で回復力のあるデータ処理パイプラインを構築できます。 詳細は「 Getting started with EMR Serverless 」ガイドを参照してください。 著者について Karthik Prabhakar Karthik は、Amazon Web Services (AWS) の Amazon EMR データ処理エンジンアーキテクトです。分散システムアーキテクチャとクエリ最適化を専門とし、大規模データ処理ワークロードにおける複雑なパフォーマンス課題の解決をお客様と共に取り組んでいます。エンジン内部、コスト最適化戦略、ペタバイト規模の分析を効率的に実行するためのアーキテクチャパターンに注力しています。 Neil Mukerje Neil は、Amazon Web Services のプリンシパルプロダクトマネージャーです。 Amber Runnels Amber は、Amazon Web Services (AWS) のシニアアナリティクススペシャリストソリューションアーキテクトで、ビッグデータと分散システムを専門としています。AWS のデータサービスでワークロードを最適化し、スケーラブルで高パフォーマンス、コスト効率の高いアーキテクチャの実現をお客様に支援しています。 Parul Saxena Parul は、Amazon Web Services (AWS) のシニアビッグデータスペシャリストソリューションアーキテクトです。高度に最適化されたスケーラブルでセキュアなソリューションの構築をお客様やパートナーに支援しています。Amazon EMR、Amazon Athena、AWS Lake Formation を専門とし、複雑なビッグデータワークロードのアーキテクチャガイダンスや、組織のアーキテクチャモダナイゼーションと分析ワークロードの AWS への移行を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。

2026年4月8日（水）～4月10日（金）の3日間、Japan DX Weekに出展いたします。 生成AIの活用が進む中、OSSライセンスや著作権リスクはますます見えにくくなっています。 サイオステクノロジーのブースでは、コード解析によりOSSを可視化する「SCANOSS」をご紹介します。ソースコードレベルでOSSの利用状況を把握し、リスクの早期発見と適切な管理を支援します。 「サイオスOSSよろず相談室」では、SCANOSSと親和性の高いSBOM管理ツールの導入・運用もサポートします。 あわせて、Excel AIエージェントやRAG構築、AI駆動開発など、AIを”現場の即戦力”にする取り組みもご紹介します。   展示のご紹介はこちら   無料のお申込みはこちら The post 4/8(水)～4/10(金) Japan DX Weekに出展します first appeared on SIOS Tech Lab .