「データ活用を推進できる人材が不足している」「せっかく人材を採用してもすぐに辞めてしまう」──。 DX推進において、多くの企業が「デジタル人材不足」を最大の課題として挙げます。しかし、その本質的な原因は市場の人材枯渇だけにあるのでしょうか。 dotDataでは以前、 データ活用推進のための人材と組織変革 において、データドリブンな文化を醸成するためには、経営トップのコミットメントと全社的な意識改革が必要であると述べました。この「文化」という土壌の上に、適切な「組織構造」という器があって初めて、デジタル人材は定着し能力を発揮します。 本連載の第1回 では「個人の役割（データアナリスト）」を定義しましたが、第2回となる今回は、その人材が活躍するための「組織設計」に焦点を当てます。データ活用を成功させるためのリーダーシップ（CDO/CAO）の定義と、日本企業の特性に合致した現実的な組織モデルについて解説します。 1. データ戦略を牽引するリーダーシップの欠如 DX推進において組織が機能不全に陥る要因の一つは、データ活用に関する責任と権限の所在が曖昧であることです。特に日本企業では、従来のIT部門（CIO）の管轄下でデータ活用が進められることが多く、「守り」と「攻め」のバランスを欠くケースが散見されます。 データドリブン経営を牽引するためには、以下の役割定義を明確にする必要があります。 CIO (Chief Information Officer)：IT基盤の守護神 CIOは、企業のIT戦略全体を統括し、基幹システムや業務システムの安定運用、コスト管理を担う責任者です。CIOの主眼はあくまで「システムの安定稼働」や「セキュリティ」に置かれることが多く、データを使ってビジネスモデルを変革する「攻め」の視点とは必ずしも一致しません。 CDO (Chief Data Officer)：データ資産の管理者 CDOは、企業が保有するデータ資産（Data Assets）を管理・統制する責任者です。データの品質管理、データガバナンス、プライバシー保護など、データを「資産」として整備し、守る役割（Defense）を担います。米国ではCIOから独立したポジションとして設置されることが一般的です。 CAO (Chief Analytics Officer)：ビジネス価値の創出者 CAOは、データ分析による価値創出を担う責任者です。データアナリストやデータサイエンティストを統括し、ビジネス視点で分析課題を設定し、業務改善や売上向上といった具体的な成果（Offense）を生み出すことをミッションとします。 CDAO (Chief Data & Analytics Officer)：攻守の統合 近年、グローバルで急増しているのが、CDO（守り）とCAO（攻め）を統合したCDAOという役割です。データ基盤の整備から分析活用までを一気通貫で統括することで、責任分界点の曖昧さを解消し、データドリブン経営の強力な旗振り役となります。 日本企業においては、「デジタル人材不足」以前に、この「攻め（CAO）」と「守り（CDO）」の役割が整理されておらず、IT部門（CIO）の片手間でデータ活用が進められていることが、成果が出ない構造的な要因となっている場合があります。まずは経営レベルで、データ活用にコミットする専任のリーダーシップ（CDAO等）を設置する（あるいはその責任を持つリーダーを明確化する）ことが、組織変革の第一歩です。 2. 組織モデルの選択肢：中央集権か、分散か リーダーが決まっても、実動部隊であるデータ分析チームをどこに配置するかという「組織設計」の問題が残ります。これには大きく分けて「中央集権型（CoE）」と「分散型（Embedded）」、そしてそのハイブリッド型が存在します。それぞれのメリット・デメリットを理解し、自社のフェーズに合ったモデルを選択する必要があります。 CoE（Center of Excellence）型：中央集権 全社のデータ人材を中央の一箇所（DX推進部やデータ分析部など）に集約するモデルです。 メリット： 人材の採用・育成・評価が一元化でき、ノウハウの蓄積や標準化が進めやすい点が挙げられます。特にデータ人材が不足している初期段階では効率的です。 デメリット： ビジネスの現場（事業部門）との距離が遠くなるため、「現場の業務課題がわからない」「分析結果が現場で使われない」という乖離が起きやすくなります。 Embedded型：事業部門完全分散 各事業部門の中にデータ人材を配置し、現場主導で推進するモデルです。 メリット： 現場の課題に即座に対応でき、業務変革（PDCA）のスピードが速いことが最大の利点です。 デメリット： 日本企業においてはこのモデルの難易度は高く、各部門でデータがサイロ化し、全社横断での統合やガバナンスが効かなくなるリスクがあります。また、事業部門単独での専門人材の採用・維持が極めて困難です。 3. 日本企業における現実解：「ハブ＆スポーク型」組織 前述の通り、完全な中央集権では現場に定着せず、完全な分散型では人材確保とガバナンスが破綻します。そこで、多くの日本企業にとって最も現実的かつ効果的な解となるのが、「ハブ＆スポーク型」の組織モデルです。 Hub（中央組織・CoE）の役割 中央の「ハブ」機能は、CDAOやCAOが統括し、以下のような全社共通の機能を担います。 高度専門人材の集約： 希少なデータサイエンティストやデータエンジニアを確保する。 技術基盤・ガバナンスの統括： 全社データ基盤の整備、分析ツールの標準化、セキュリティ基準の策定。 人材育成と技術支援： 社内研修の提供や、事業部門への技術サポート。 Spoke（事業部門）の役割 各事業部門の「スポーク」には、現場業務を理解したデータアナリストや、データ活用推進担当者を配置します。 業務課題起点の企画： 現場のリアルな課題を発掘し、データ活用のテーマを設定する。 現場への定着化： 分析結果を業務プロセスに組み込み、現場メンバーの活用を支援する。 成功のポイントは「連携」と「兼務」 このモデルの肝は、ハブとスポークが断絶せず、密接に連携することにあります。例えば、事業部門（スポーク）に配置されるデータアナリストが、組織上は中央（ハブ）にも所属する「兼務（マトリクス的な配置）」の形をとることが有効です。これにより、アナリストは現場の課題を深く理解しながら、中央の技術支援や評価制度の恩恵を受けることができ、孤立を防ぐことができます。 4. ビジネス部門とCDO組織のコラボレーション ハブ＆スポーク型組織を機能させるためには、全社横断のCDO組織と、事業部門配下のアナリティクスチームが、あたかも一つの生命体のように連動する必要があります。 戦略と実行の役割分担 CDO/CDAO組織は「戦略的方向性（Strategic Direction）」を示し、事業部門はそれを踏まえた「実行（Execution）」を担います。具体的には、CDO組織が「高度分析（AIモデル構築など）」や「データ基盤整備」「人材育成」といったインフラを提供し、事業部門のチームはそれを利用して「KPIモニタリング」や「施策立案」といった日々の業務改善を行います。 データのサイロ化を防ぐ「標準化」 事業部門が独自に走ると、KPIの定義が部門ごとにバラバラになるリスクがあります。これを防ぐため、CDO組織は「標準化・共有・教育」の役割を担い、全社共通のデータ定義や分析手法のテンプレートを提供します。 5. まとめ：組織設計こそが最大の投資 第2回では、データ活用を阻む壁の正体が「人材不足」だけではなく、「リーダーシップの欠如」と「組織設計の不備」にあることを解説しました。 ビジネスアナリティクスのブログシリーズ③ でも触れた通り、データドリブンな文化は一朝一夕には醸成されません。しかし、攻めと守りを統合したリーダーシップ（CDAO）を確立し、現場と中央をつなぐ「ハブ＆スポーク型」の組織を構築することで、文化が育つための強固な基盤を作ることができます。組織と人が揃っても、実際の業務プロセスが変革されなければ意味がありません。 最終回となる第3回では、データ活用プロジェクトを成功させるための具体的な「プロセス（企画・分析・活用）」と、その裏側を支える多様な「エンジニア」の役割について、実務的な視点から解説します。 The post データドリブン組織の設計図｜「デジタル人材不足」の正体は組織不全？ CDOが知るべき成功する組織モデル（連載 第2回） appeared first on dotData .

企業のデジタルトランスフォーメーション（DX）が「業務のデジタル化」から「データによるビジネス変革」へと深化するなか、データを活用した意思決定を担う データアナリストとは 何か 、どのようなスキルが求められるのかといった人材定義があらためて問われています。dotDataでは以前、ブログ記事『 データ活用推進のための人材と組織変革 』において、データドリブン経営に必要な文化醸成と人材育成の全体像について解説しました。しかし、実際に組織を設計しようとした際、「具体的にどのようなスキルセットを持った人間を、どこに配置すべきか」という詳細定義に悩む企業は少なくありません。 本連載では、企業がデータ活用を成功に導くために必要な人材・組織・プロセスの「設計図」を、全3回にわたり実践的に解説します。第1回の今回は、AI活用が一般化する時代において価値が高まる データアナリストとしての 役割定義 と、その中核スキルである「ビジネスアナリティクス（BA）」の本質について掘り下げます。 1. データ活用の目的と3つの分析アプローチ データ活用人材を定義するためには、まず「データ分析によって何を解決したいのか」という目的を明確にする必要があります。組織設計を行ううえでは、以下の3つのアプローチ（BI・BA・PA）を理解することが不可欠です。 これらの違いについては、以前のブログ『 データからインサイトへ：BI、BA、PAの統合ガイド 』で比較していますが、データアナリストの仕事や役割分担という視点で整理すると次のようになります。 ① ビジネスインテリジェンス（BI）：現状把握と可視化 ビジネスインテリジェンス（Business Intelligence）は、「何が起きているか（What is happening?）」を把握するためのアプローチです。KPIや市場動向など、売上データを含むさまざまなデータをダッシュボード化し、組織のメンバーが現状を客観的かつ直感的に把握できる状態をつくります。 ② ビジネスアナリティクス（BA）：要因特定とビジネス分析 ビジネスアナリティクス（Business Analytics）は、「なぜそうなっているのか（Why is it happening?）」という理由や要因を特定するためのアプローチです。BIによって可視化された現状に対し、特定のビジネス課題にフォーカスして分析結果を読み解き、「なぜ売上が落ちたのか？」「なぜこの施策は成功したのか？」といった改善のための具体的なインサイト（示唆）を導き出します。 データアナリストが 担う中心領域 でもあります。 ③ プレディクティブアナリティクス（PA）：将来予測と自動化 プレディクティブアナリティクス（Predictive Analytics）は、「これから何が起きるか（What will happen?）」を予測するためのアプローチです。統計数理や機械学習、AI技術を駆使して過去データを分析し、パターンを学習、未知の将来を予測することで、業務の自動化や最適化を実現します。 2. 成果創出の鍵を握る「ビジネスアナリティクス（BA）」 多くの日本企業において、データ活用が「レポート作成（BI）」で止まってしまう、あるいは「AI検証（PA）」が現場の実務と乖離するなど、成果に結びつかないケースが散見されます。成果につながる意思決定を支えるために最も強化すべき領域こそが、これらの中間に位置する「ビジネスアナリティクス（BA）」です。 「なぜ」を解明し、アクションへつなげる ブログ記事『 ビジネスアナリティクス：データに基づいた業務の分析 』でも触れた通り、BAの本質は、データを単に見るだけでなく、課題解決のPDCAサイクルに組み込むことにあります。 BIは汎用的な「見える化」に重点を置きますが、BAは特定の課題に対して「なぜ？」を問いかけます。要因が明確になれば、「マーケティング施策を見直す」「営業プロセスを最適化する」といった、実効性の高いアクションプランを設計することが可能になります。 高度な技術よりも「業務知見」が重要 人材定義において重要な点は、BAには必ずしも高度な統計解析や複雑なツールが必要なわけではないということです。簡単な相関分析やクロス集計であっても、そこに強力な「業務知識（ドメイン知識）」と「目的意識」があれば、極めて価値の高い知見が得られます。分析技術の専門家でなくとも、現場の業務担当者が主体的に データを分析し 、自らの業務経験を背景に考察を加えることで、課題解決の糸口が見つかります。 3. 「データアナリスト」と「データサイエンティスト」の明確な役割分担 ビジネスアナリティクスの推進にはどのような人材が必要でしょうか？ 日本では「データ活用人材」と一括りにされがちですが、実務においては「データアナリスト」と「データサイエンティスト」の役割を明確に分けることが、人材定義の第一歩となります。 データアナリスト：意思決定支援と課題解決のプロフェッショナル データアナリストは、主にBIとBAの領域を担当し、業務課題の解決や意思決定を支援する役割を担います。 主な手法：BI（可視化）、BA（ビジネス分析） 必須スキル：データの読み解き力に加え、 業務理解やコミュニケーションスキルが最重要視されます。ビジネス部門や経営層に対し、分析結果をわかりやすく説明・提案し、行動を促す力が求められます。 データサイエンティスト：予測モデル構築と高度技術の専門家 一方、データサイエンティストは、主にPAの領域を担当し、高度な予測モデルを構築して新たな価値を創出する専門職です。 主な手法：PA（予測分析）、機械学習、最適化 必須スキル：統計学、機械学習、モデリング、プログラミングといった、高度な技術的実装力が求められます。 米国ではこれらの職務定義は明確に異なっており、業務におけるデータ活用、つまりビジネスアナリティクスとデータドリブン経営の推進の多くをアナリストが担います。一方で、データサイエンティストはその専門性を生かした高度な技術的プロジェクトに取り組むという役割分担が確立されています。 4. データアナリティクスを推進する3つの機能 組織としてデータアナリティクスを推進するためには、単に「分析ができる人」を採用・育成するだけでは不十分です。データ活用プロジェクトを成功させるためには、以下のような3つのロール（役割）による三位一体のチーム体制が必要です。 ① 分析者（Analyst） これは前述のデータアナリストの役割に相当します。データの抽出・加工・可視化を行い、インサイトを提示する実務担当者です。 ② 企画者・推進者（Planner / Promoter） ビジネスとデータの「ハイブリッド型人材」です。企業や部門が抱える経営・業務課題を把握し、それをデータによってどう解決するかを構想（企画）する役割です。「データはあるが、どう活用して良いかわからない」という状況を打破し、プロジェクト全体を牽引します。 ③ 理解者・活用者（User） これは主に業務部門の現場担当者を指します。分析結果を適切に読み解き、自らの業務における意思決定やアクションに反映させる役割です。現場が分析結果を理解し、分析者と対話できるようになることで、初めてデータは価値を生みます。 5. まとめ：DXにおけるデータアナリストの真価 今回は、データ活用の種類（BI/BA/PA）と、その中核を担うデータアナリストの定義について解説しました。DXの本質がビジネスモデルや業務プロセスの変革にある以上、AIモデルを作る技術力だけでなく、データの中に潜む「なぜ（要因）」を解き明かし、具体的なビジネスアクションへと翻訳できる「データアナリスト」の存在こそが、組織の競争力を左右します。 次回（第2回）は、こうした人材が最大限にパフォーマンスを発揮するために必要な「組織設計」と「リーダーシップ（CDOの役割）」について、日本企業の特性を踏まえた現実的なモデルを解説します。 The post データドリブン組織の設計図｜データアナリストとは？役割とビジネスアナリティクスの本質（連載 第1回） appeared first on dotData .

金融業界では、AI技術や生成AIの実用化が進み、データ分析を基盤とした新しい金融サービス提供が競争優位性を左右する時代になっています。金融機関が直面する課題は、顧客対応の高度化、業務効率化、リスク管理の精度向上など多岐にわたります。こうした背景から、人工知能や機械学習を活用したユースケースが拡大し、データを起点とした変革が求められています。 本記事では、金融業におけるユースケースとdotDataの貢献領域をはじめ、具体的な導入事例、生成AIと統合した最新のデータ活用アプローチをお届けします。各事例の詳細については、三井住友信託銀行様・三井住友海上火災保険様・セブン銀行様の導入事例ページもあわせてご覧いただくと、より深い理解につながります。 営業・マーケティング支援：三井住友信託銀行株式会社様 金融機関が直面する営業課題とAI活用による解決 三井住友信託銀行様 は、個人顧客への営業活動をより精緻にするため、dotDataを導入しました。従来は経験則に基づいてターゲットリストを作成していましたが、精度には限界があり、人材不足や分析にかかる時間の長さも大きな課題となっていました。さらに、従来のAIツールは分析の根拠がブラックボックス化しやすく、営業担当者に納得感を持って活用してもらうことが難しいという問題もありました。 AIを活用した顧客ターゲティング精度の向上 導入後は、500万件に及ぶ膨大な顧客データを分析し、金融商品の成約率を予測するAIモデルを構築。その結果、dotDataが「ニーズあり」と判定した顧客は、「ニーズなし」とされた顧客に比べて成約率が約20倍高いという劇的な成果が得られました。 さらに、分析の過程では運用商品の提案先を絞り込む際に、「住宅ローンの残高」や「相続関連商品の保有状況」といった、従来は運用商品とは関係が薄いと考えられていた特徴量が数多く見つかりました。こうしたベテラン営業でも一部の人しか気がつかないような傾向をdotDataが発見することで、若手や新人の育成にも役立っています。結果として、営業ノウハウを組織全体で共有しやすくなり、営業力の底上げにつながりました。 また、dotDataは専門的なスキルがなくてもAIモデルを構築できるため、企画担当者が自らトライ&エラーを重ねながら分析の精度を高められる環境が整いました。これにより、分析時間の短縮と精度改善のサイクルが確立され、現場主導でのAI活用が定着しています。 営業支援システムとの連携：三井住友海上火災保険株式会社様 AI活用の広がりと代理店営業の課題 三井住友海上火災保険様 は、全国に約3万8,000拠点ある保険代理店の営業活動を支援するため、2020年2月に代理店支援システム「MS1 Brain」をリリースしました。代理店経由で顧客一人ひとりにパーソナライズされた体験を提供するには、経験や勘に頼る従来の営業スタイルでは限界がありました。しかし、社内のデータサイエンティストは少なく、外部人材に依存するとノウハウが社内に蓄積されないという課題がありました。さらに、AIモデルがブラックボックス化すると、なぜその提案が導かれたのかを現場が理解できず、活用が進まない懸念もありました。こうした背景から、効率的にAIモデルを構築でき、かつ説明可能性を備えた仕組みが求められていました。 AIが営業支援を変える、「MS1 Brain」による提案力の強化 こうした課題を解決するために、同社はAIエンジンにdotDataを採用し、特徴量の自動設計と可視化を活用してモデル設計・構築を効率化しました。その結果、過去の契約情報を分析し、「誰に・いつ・どの商品を提案すべきか」を具体的に提示できるようになり、アップセルやクロスセルの成約率は従来比で2〜3倍に向上しました。また、解約や他社切替のリスクが高い顧客を早期に特定でき、抑止活動を迅速に開始できるようになった点も大きな効果です。さらに、抽出された特徴量は「年間保険料が一定額を超える顧客は特定の特約を付帯しやすい」といった形で営業ノウハウとして定量化され、代理店向けのトークスクリプトに落とし込まれました。 成果は国内にとどまらず、海外の提携先での解約要因分析や、自動車買い替えタイミング予測といったユースケースに応用され、ビジネス価値の拡大につながっています。現場が理解し納得できる「見えるAI」を導入したことで、社員や代理店の間にデータドリブンな文化が根付き、DX推進が大きく加速しました。 グループ異業種連携：セブン銀行様 「金融×リテール」データ融合への挑戦 セブン銀行様 は、グループが保有する金融データと購買データを組み合わせ、より高度なマーケティングを実現することを目指していました。購買データには顧客の生活スタイルや価値観が色濃く表れるため、深い顧客理解につながる可能性がありました。しかし、金融機関にとって購買データは未知の領域であり、分析の「土地勘」がなく、どの切り口から仮説を立てればよいか判断が難しいという課題がありました。 AIを活用した購買データと金融データの統合分析 こうした課題に対し、セブン銀行様はdotDataを導入し、AIによる自動かつ網羅的な分析を活用することで、数十万から数百万に及ぶパターンの中からカードローンニーズと関連の深い特徴量を発見しました。その結果、購買データと金融データを組み合わせたターゲティング広告の精度が飛躍的に向上し、顧客獲得単価（CPA）は従来の半分に削減されました。 今後は、dotDataの誰でも高精度なデータ分析が行える特長を活かして、現場主導のAI・データ活用を広げていく方針を持っています。データサイエンティストが中心となって枠組みを整えつつ、段階的に利用部署を拡大し、将来的には購買データの活用を通じて新しい金融ビジネスの立ち上げにも取り組んでいく考えです。 地域連携：中国銀行様、ちゅうぎんフィナンシャルグループ様 AIの活用と地域DXの推進 2024年5月に ちゅうぎんフィナンシャルグループ様 （以下ちゅうぎんFG）が発表されたちゅうぎんDX戦略の資料では、dotDataは幅広い接点から生まれるデータをクラウド内で統合的に分析・活用するデータ基盤として位置づけられています。特徴量については「業務目的と関連が高いデータの重要なパターン」と記載されており、こうした仕組みを通じて分析基盤を整備し、誰もが高度にデータを活用できる環境を構築することが目指されています。データ起点の課題発見から、企画、分析、効果検証のサイクルをクイックに回し、誰もが高度にデータを活用してマーケティングをレベルアップすることを目指されています。 岡山モデルに広がる地域連携の取り組み 地域連携という点では、中国銀行様がリードして地域産業、行政、学術機関との連携を推進しており、dotDataは協業パートナーの一社として参画しています。成功事例を「岡山モデル」として他地域や他分野へ横展開することを目指されています。 また、地域連携の一環として、中国銀行様、岡山大学様、dotDataの3者協力により 大学生向けビジネスアナリティクス人材育成の公開講座 を実施しました。この講座は、岡山県内の大学生がビジネスベースの分析を学び、次世代のデータ活用人材となることを目指すものです。dotData提供のサービスをアレンジし、分析の理解から結果の読み解き、施策立案までをカバー。講義で標準的な考え方を学び、オープンデータやdotDataを使った実習を行う実践的なプログラムとなっています。この プログラムは企業向け にも多くの実績があり、データ活用による意思決定の文化を多くの部門に定着させる取り組みとして関心が高まっています。 まとめ 本記事では、dotDataが金融業において、営業・マーケティング支援、グループ異業種連携、地域連携といった多岐にわたる領域で貢献をしていることを、具体的なユースケースを通じて紹介しました。ご紹介した事例が、皆様のデータ活用戦略を検討される上での一助となれば幸いです。dotDataは今後もAIを活用したデータ分析や生成AI活用を軸に、日本の金融機関を支援していきます。今回取り上げた事例以外にも需要予測など多様な金融AI活用のユースケースがありますので、他の導入企業の事例もぜひご覧ください。 貴社でも「営業力強化」「顧客体験の向上」「新規ビジネス創出」を目指してみませんか？まずはお気軽に お問い合わせ ください。 The post 金融業界におけるdotDataの活用事例4社 – AIの統合や異業種連携で加速するデータ活用 appeared first on dotData .

セールスフォースを活用した営業改革の必要性 セールスフォースは、世界No.1のCRMツールとして、現代の営業活動において不可欠な存在となっています。特にSales Cloudは、営業活動の履歴や進捗、顧客情報を一元管理することで、営業担当者が必要な情報に迅速にアクセスし、チーム全体での情報共有も容易になっています。 しかし、セールスフォースを導入しても、そこに日々蓄積されている膨大なデータが必ずしも十分に活用されているわけではありません。営業活動の現場では、依然として「経験と勘」に頼った意思決定がなされる場面が少なくなく、データが持つ潜在能力が引き出し切れていないのが実情です。 本記事では、セールスフォースに蓄積されたデータを最大限に活用し、営業担当者の意思決定を科学的かつ効果的に進化させる具体的なアプローチについて、詳しく解説します。営業改革の成功には何が必要なのか、またそのためのツールや手法についても触れていきます。 セールスフォースデータ活用における主な課題 セールスフォースのデータは、営業活動の効率化や顧客との関係強化に大きな価値をもたらす可能性を秘めています。しかし、それを効果的に活用するには３つの課題があります。 1. オブジェクトの複雑な構成 出典： Sales Cloud Overview Data Model セールスフォースは多様なオブジェクト（テーブル）で構成されており、それぞれが密接に関連しています。Sales Cloudのデータモデルを確認すると、商談、顧客、活動履歴など多数のオブジェクトが複雑に関係していることが一目で分かります。この複雑さが、必要なカラムがどこに存在するか、オブジェクト間をどうリレーションすれば適切な分析ができるかを把握することを難しくしています。たとえデータサイエンティストであっても、構造を理解し、分析に活用するには相応の労力と時間が必要です。 2. データ品質の課題 セールスフォースのデータは入力時の自由度が高いため、データの質にばらつきがあるという課題があります。 課題１：表記ゆれ 業種や役職など、自由入力できる項目では表記が統一されていないことが多く、分析の妨げとなります。例えば役職1つ取っても「課長」「マネージャー」「Manager」と多様な記載が混在し、過去には1万種類以上の表記ゆれが存在したケースもありました。営業メモや日報といったテキストデータも同様に、分析に適さない形で残されていることが多いです。 課題２：商談履歴オブジェクトの加工 商談履歴（Opportunity History）は、ステージ変更や金額修正が行われるたびに新たなレコードが追加される縦持ち形式です。このままでは商談単位の分析が難しく、分析に適した形（横持ち）に変換する必要があります。そのオブジェクトの加工にスキルが必要になってきます。 課題３：情報リーク 商談の受注日を起点に分析すると、受注直前の行動（契約書作成など）が受注要因として抽出されてしまうことがあります。これでは「答えが漏れている」状態となり、真に価値あるインサイトが得られません。重要なのは、商談の初期フェーズでの行動や顧客特性など、早期段階の真の成功要因を抽出することです。 課題４：不正確な入力 営業担当者が感覚で見込み金額を入力したり、進捗更新を怠ったりすると、データの信頼性が低下します。不正確なデータでは、どんなに高度な分析をしても意味のある結果は得られません。 3. 横断的な分析テーマへの対応の難しさ セールスフォース（Sales Cloud）のデータは営業活動に特化しているため、マーケティング施策や人事施策、在庫状況など他部門との横断的な分析が必要な場合、セールスフォース単体では限界があります。より深いインサイトを得るためには、外部データとの連携が必須となります。 セールスフォースデータ活用の課題を解決するdotData Insight for Salesforce AIを活用した包括的なデータ分析プラットフォーム セールスフォースデータ活用の課題を解決するために、dotDataはAIを活用したデータ分析プラットフォーム「 dotData Insight 」と、セールスフォース専用ソリューション「 dotData Insight for Salesforce 」を提供しています。 dotData Insightは、営業活動で蓄積されたデータから、受注や成長に強い関係を持つデータパターン（特徴量）をAIが自動で抽出し、それを営業戦略に落とし込むための意思決定を支援します。 dotData Insight for Salesforceの主な機能 dotData Insight for Salesforceは、セールスフォースの営業データを最大限に活用し、データ・ドリブン営業DXを実現するための主な機能を備えています。 成功商談に共通する特徴をAIが自動発見 データの中から、成約した商談に共通する成功要因を自動で抽出します。 表記揺れや入力ミスの自動補正 生成AIによるデータクレンジング機能で、煩雑な表記統一作業を不要にします。 商談成否や優秀営業員の特徴など、典型的な分析結果を提供 営業活動改善に直結する具体的な知見を提示します。 セールスフォースデータの現状をプロがアセスメント データ品質や入力ルールを可視化し、改善方針を明確にします。 これらの機能を活用することで、セールスフォースに蓄積されたデータを「営業の武器」に変えることが可能になります。 セールスフォースデータを活用した標準3テーマ分析 Sales Cloudのデータ分析は多様なユースケースに適用できますが、特に多くの企業で有益な「標準3テーマ」は以下の通りです。 テーマ１：商談成約要因分析 受注商談と失注商談の差異を特徴量として抽出し、質の高い商談の共通要件を明確化します。営業担当者は、初期段階で取るべき具体的な行動が分かるため、受注確度を大幅に高められます。 テーマ２：セールスステージ遷移分析 商談がスムーズに次のステージへ進むために必要な要因を明らかにします。時間軸での詳細な分析により、各ステージでどんな活動をすべきかが明確になり、営業プロセス全体を最適化します。 テーマ３：優秀営業員の特徴分析 ハイパフォーマー（上位 ︎％の営業担当者など）の営業活動をデータで可視化し、そのアプローチを一般化します。これにより、営業チーム全体の底上げや人材育成の効率化を可能にします。 データ・ドリブンな営業DXを広げる追加ユースケース 標準テーマだけでなく、セールスフォースデータとdotData Insightを組み合わせることで、今後以下のような追加ユースケースへの展開が期待されています。 高単価受注要因分析：単価の高い案件の共通条件を明らかにし、高付加価値商談の創出に活かす。 高受注率顧客セグメント分析：高確率で受注に至る顧客像を特定。 パイプライン成長要因分析：営業パイプラインが拡大している要因を把握。 新規顧客獲得要因分析：未開拓市場への最適なアプローチ手法を抽出。 アップセル・クロスセル成功要因分析：既存顧客からの売上拡大のカギを特定。 LTV向上要因分析：顧客の長期的価値を高める要因を抽出。 顧客離反要因分析：離反の兆候を早期に察知し、維持施策を立案。 顧客ロイヤリティ向上要因分析：継続利用や推奨意向に寄与する要因を明らかに。 dotData Insight for Salesforceの導入プロセス dotData Insight for Salesforceの導入は、短期間で効果を実感できるトライアルプロセスからスタートします。Step1〜Step2で約3週間、Step3で約3週間、合計6週間のスケジュールで進行し、営業現場で活用できる具体的な成果を得ることができます。 Step1：データ準備・アップロード まずは、セールスフォースから必要なオブジェクトデータを抽出し、アップロードします。 データ定義書を見ながら抽出するほか、データコネクタを利用したテーブル抽出にも対応しています。営業部門が日常的に入力しているデータをそのまま利用するため、複雑な前処理や大規模なデータ整形は不要。最小限の作業で分析の準備が整います。 Step2：簡易実行とデータアセスメント 続いて、商談成約要因分析を簡易的に実行し、現状のデータでどの程度の分析が可能かを確認します。 同時に、入力の不正確さやフェーズ運用の歪み、表記揺れ、データの欠損などを専門家が精査し、データの品質を評価（アセスメント）します。これにより、「現状データで分析を進めて良いのか」「どこを改善すべきか」という方向性が明確になります。データ品質に不安がある企業でも、トライアル段階でGo/No-Goの判断ができるのが特徴です。 Step3：dotData Insightと特徴読み解き支援 本格的な分析フェーズでは、AIが「成約要因」「ステージ遷移」「優秀営業員」という標準3テーマをもとに特徴量を抽出します。 抽出された特徴量は営業部門でも理解しやすい文章と数値で提示され、読み解き会（ワークショップ）を通じて実際の営業施策に落とし込みます。これにより、データ分析に慣れていない現場でも成果をアクションにつなげられる状態になります。分析結果はCSV形式で出力可能なため、既存のダッシュボードやレポートにも容易に統合できます。 継続サービス：分析テーマの拡張 トライアル終了後は、標準3テーマだけでなく、顧客ごとの課題に合わせたカスタムテーマ分析に拡張可能です。 さらに、Salesforce外のCRM・ERP・HRデータとの連携や、商談スコアリングの継続運用など、より高度な営業DX施策へと広げていけます。 6週間の導入トライアルを経ることで、営業現場がすぐに実践できる具体的な示唆を獲得し、データ・ドリブンな営業の第一歩を踏み出せます。 データ品質課題を解決する具体的ソリューション 1. 生成AIを活用したデータクレンジング カテゴリデータの自動名寄せ 「課題１：表記ゆれ」で触れたように、役職・部門・業種などのカテゴリカラムには膨大な表記ゆれが存在します。これを生成AIが自動で検出・統合します。 たとえば、営業担当者が入力した「課長」「マネージャー」「Manager」といった異表記を「中間管理職」という統一カテゴリに自動変換します。これにより、手動で辞書を作成したり複雑な正規表現で対応する必要がなくなり、分析に適したデータが短時間で整備できます。 テキストデータの特徴量化 また、営業メモや日報、議事録といった自由記述のテキスト情報から重要な文脈を抽出し、Yes/Noやカテゴリ値として新たな分析用カラムに変換します。 たとえば、「予算が承認済みか」「部長クラス以上との面談があったか」といった重要情報を自動でラベル化。これにより、従来は扱いづらかったテキスト情報も数値データと同様に分析可能な形で活用できます。 2. ステージ遷移テーブルの作成 ステージ遷移テーブルとは？ 「課題２：商談履歴オブジェクトの加工」で指摘した問題に対応するため、dotDataは縦持ち形式で記録される商談履歴（Opportunity History）を、横持ち形式の「ステージ遷移テーブル」に変換します。実際のデータには、再登録や修正によって時系列に沿っていないケースもありますが、様々な例外処理ルールにより時系列に矛盾のないテーブルを作成します。 これにより、各商談がどのステージにいつ到達したかを1行で俯瞰でき、時系列分析が容易になります。 ステージ遷移テーブルを使った分析 このステージ遷移テーブルを用いることで、分析の基準時点を柔軟に制御できるようになります。たとえば、「セールスステージ2への遷移日」を基準日とし、そこから一定期間内に受注した商談を対象に、基準日以前の活動データから成功要因を探し出すことが可能です。 こうしたアプローチにより、受注直前の情報ではなく、営業プロセスの早期段階での活動や顧客属性など、真に受注に影響を与えた要因を特定でき、「課題３：情報リーク」も解決します。 3. データアセスメントによる改善提案 データアセスメントは、セールスフォースデータの品質を診断し、特に不正確な入力や運用上の歪みを把握・改善するための取り組みです。商談オブジェクトなどをカラムごとに精査し、クローズ定義や独自拡張による運用の癖を明らかにして、ベストプラクティスとの差異を洗い出します。そのうえで、分析に適したデータ構成や運用ルールへの見直しを提案し、クリーンで分析可能なデータ基盤を整備します。 こうした改善によってデータが整理され、現場での入力精度も向上し、「課題4：不正確な入力」も解消されます。 外部データ連携による横断的分析の実現 セールスフォースデータだけでは解決できない課題には、CRM、HR、ERPなど外部データの統合が有効です。 Salesforce + CRM：マーケティング施策の商談貢献度分析　など Salesforce + HR：人材施策と営業パフォーマンスの関係性分析　など Salesforce + ERP：在庫状況・価格変更が受注に与える影響分析　など これにより、営業活動の可視化から経営レベルの意思決定支援までを一貫して行えるようになります。 まとめ：セールスフォースデータを“営業の武器”に Salesforceを導入するだけでは、営業活動の効率化は限定的です。しかし、dotData Insight for Salesforceを活用すれば、営業データの可視化から高度なデータ分析、実践的なアクションプラン設計までをワンストップで実現できます。データ・ドリブンな営業DXは、単なるIT導入ではなく、営業プロセスそのものの進化です。 今こそ、自社に合った方法でセールスフォースデータを最大限活用し、営業改革の新たなステージへ進むべき時ではないでしょうか。dotDataの専門チームが、御社の課題に合わせた最適な活用プランをご提案します。まずは お気軽にご相談ください 。 The post セールスフォース活用事例：dotData Insight for Salesforceで実現するデータ・ドリブンな営業DX appeared first on dotData .

はじめに：データとAIの進化がもたらす新時代 2025年6月15日〜18日、カリフォルニア州サンフランシスコにて開催された「Databricks AI + Data Summit 2025」は、データとAIの最前線を体感できる世界最大級のカンファレンスとなりました。全世界から22,000名以上が集結し、日本からも280名以上の参加者が現地に足を運びました。本記事では、このサミットの模様を詳しくレポートするとともに、データレイクやAIエンジニアリング、セルフ分析の高度化といった最新トピックを紹介します。 その前にまず、今回のサミットを主催した「Databricks」という企業について、簡単に触れておきましょう。 Databricksとは何か：Apache Sparkから始まったデータ統合の挑戦 Databricksとは、クラウド型データプラットフォームを提供するアメリカの企業であり、2013年にカリフォルニア大学バークレー校の研究者たちによって設立されました。彼らは、大量データを高速処理するためのオープンソースフレームワーク「Apache Spark」の開発者たちであり、まさにビッグデータ処理の第一人者です。 設立当初はSparkの技術支援やコンサルティングを中心に活動していましたが、2015年ごろから方向性を大きく変え、クラウド型データプラットフォームの開発と提供に注力するようになりました。現在のDatabricksは、機械学習の基盤、生成AIの実行環境、データウェアハウスとデータレイクの統合といった領域でリーダーシップを発揮しており、企業におけるAI導入やデータ活用の中核を担っています。 売上規模においても急成長を遂げており、ARR（年間経常収益）は2020年時点で約1,000億円だったものが、5倍以上に到達する見込みとも言われています。 2024年12月時点の評価額は約10兆円 ともされ、日本企業で例えるならKDDIやリクルートに匹敵するほどの規模です。 Databricksの技術戦略における特筆すべき点は、オープン性と統合性です。Apache Sparkに加え、Delta LakeやLakehouseアーキテクチャ、Unity Catalogといったクラウドに最適化されたデータプラットフォームを提供し、しかもそれらの多くをオープンソースとして公開しています。これは、「データの民主化」というグローバルな潮流を体現するアプローチであり、今後のAI社会に不可欠な基盤技術といえるでしょう。 Databricksの主力製品「Lakehouse」とは 出典： Databricks概要 – データ+AIの民主化 (2024年) Databricksを語るうえで欠かせないのが、「Lakehouse（レイクハウス）」というアーキテクチャです。これは、従来別々に管理されていたデータウェアハウスとデータレイクを一元的に統合するモデルであり、構造化データと非構造化データを1つのプラットフォームで処理・分析できる点が最大の特徴です。 従来、企業ではこれらのデータを別々に扱う必要があり、層ごとの処理や分担が求められていました。こうした分断は、全社的な分析やAI活用の柔軟性を妨げる要因となっていました。 Lakehouseはこの課題を解消し、一貫性と柔軟性を両立する統合型のデータ基盤として設計されています。中核となるのは、オープンフォーマットのDelta Lakeであり、大規模データの信頼性ある処理とスケーラブルな運用をクラウド上で実現します。 実際、Databricksによると世界中のグローバル企業の74%がこのLakehouseを導入しており、Azure Databricksなどクラウドとの連携も強化されています。Databricksは、Microsoft AzureやAWS、Google Cloudといった主要クラウドプロバイダーとのパートナーシップも深めており、柔軟でスケーラブルなクラウドストレージ環境の中でデータ処理とAIの実行を効率化する統合プラットフォームを提供しています。 Data+AI Summit 2025（DAIS 2025）の概要と日本の存在感 ここからは、本記事の中心テーマである「AI & Data Summit 2025」についてご紹介します。 このイベントは、Databricksが毎年主催するグローバルカンファレンスであり、2025年は過去最大規模での開催となりました。6月15日から18日までの4日間、世界中のデータサイエンティスト、エンジニア、ビジネスリーダーがサンフランシスコに集結し、最新のAI技術やデータ戦略について活発な議論が行われました。 日本からも過去最多となる280名以上が現地に参加しており、日本語向けの振り返りセッションや懇親会も実施されるなど、日本市場への注力がうかがえました。 このような背景のもと、サミットのキーノートやセッションで繰り返し語られていたキーワードのひとつが、「データプロダクト」という考え方です。これは、次章で詳しく解説します。 データプロダクトとは：再利用性とスケーラビリティを高める概念 データプロダクトとは、単なるデータの集まりではなく、特定の利用者（市場）に対し、価値をもたらすよう”パッケージ化・品質保証”されたデータ資産を意味します。 従来、企業におけるデータ管理は部門ごとに分散し、それぞれが独自にクレンジングやETL（データ変換）、品質管理を行っていました。このような構造は、サイロ化の原因になり、データの再利用性が低く、全社的なデータ活用や意思決定のスピードが制約されてしまいます。 データプロダクトの考え方では、利用部門は「データのユーザー」であり、データ自体はあらかじめ利用方法や品質基準、メタデータ、モニタリング機能が付属された「再利用可能なコンポーネント」として提供されます。これにより、エンタープライズ全体でのデータの民主化とスケーラブルな活用が実現できるようになります。このようなデータプロダクトを実現するために必要不可欠なのが、統合されたデータ分析基盤です。 LakebaseとUnity Catalogによる「データ＋AI」の完全統合へ Databricks AI & Data Summit 2025において、データ基盤に関する最も注目すべき発表は、「Lakebase」と「Unity Catalogの拡張」でした。これらの発表は、Databricksの戦略と密接に結びついており、2024年に実施されたNeonおよびTabularの買収が背景にあります。Neonの技術はLakebaseに、Tabularの技術はUnity Catalogの新機能に直接活用されています。いずれも約1500億円（約10億ドル）規模の大型買収であり、今回の発表はあわせて3000億円規模の投資によるものです。 これらは、Databricksが長年掲げてきた「データとAIの統合」というビジョンを、さらに力強く前進させる重要なマイルストーンとなっています。 Lakebase：運用と分析を一元化する次世代データベース 「Lakebase」とは、運用データベース（OLTP）と分析データベース（OLAP）の境界を取り払うことを目的とした新アーキテクチャです。サーバーレスでPostgreSQL互換、しかもDelta Lakeベースで動作するこのデータベースは、ストレージとコンピュートを分離し、負荷に応じてスケーラブルにリソースを割り当てることができます。 出典： Data + AI Summit Keynote Day 1 たとえば、アプリケーションから発生したデータを即座に分析基盤へ連携し、リアルタイムで注文履歴を分析して業務に反映するといったシナリオが、ETLやリバースETLといった手間なしで実現されます。これは、運用と分析が融合した“完全統合型データ基盤”と呼ぶにふさわしい進化です。 このLakebaseの導入により、データウェアハウスとデータレイクの融合は次のステージへと突入しました。 Unity Catalogの進化：マルチプラットフォームでのデータガバナンス実現 Unity Catalogは、Databricks内外のデータやAIモデルを一元的に管理するメタデータカタログとして知られていましたが、今回のアップデートにより、その用途と柔軟性が格段に広がりました。主な新機能は次の2つです： 出典： Data + AI Summit 2025で発表されたDatabricks Unity Catalogの新機能 プラットフォームを統合 1. Iceberg REST Catalog APIのサポート Iceberg形式で保存されたデータを、Amazon EMR、Trino、Snowflakeなど他の分析エンジンからも参照可能にするAPIが追加されました。これにより、Databricks以外のシステムからも、統一されたメタデータでデータ活用が可能になります。 2. Iceberg Federationの導入 外部のIcebergテーブルをUnity Catalogに直接統合し、仮想的に統合されたデータ基盤を構築できます。これにより、クラウドアカウントやストレージにまたがるデータ統合もシームレスに実現されます。 ビジネスと分析組織を統合 Unity Catalog Metrics & Discovery 部門ごとにKPIの定義が異なり、Power BIやTableauで計算結果が食い違う、こうした課題を解決するのが、Unity Catalog MetricsとUnity Catalog Discoveryです。 ビジネス指標をレイクハウス層で定義し一元管理することで、どのツールを使っても一貫した結果が得られます。さらに、メトリクス定義やダッシュボード管理、承認プロセスの統合機能も強化され、データの整合性と信頼性を高めています。 出典： Data + AI Summit Keynote Day 2 このように、LakebaseとUnity Catalogを組み合わせることで、より統合されたデータ管理が実現し、企業のデータプロダクト活用を支援します。 データ分析・AIの進化 AIエンジニアリングの到来：複雑化するAI開発のプロフェッショナライズ 2025年のサミットで最も注目されたトピックのひとつが、「AIエンジニアリング」です。これは、ソフトウェアエンジニアリングの原則をAI開発・運用に適用し、安定性・保守性・品質を担保する技術体系を意味します。 2024年は、複数のAIエージェントが連携してタスクをこなす「複合AIシステム（Compound AI Systems）」が注目を集めましたが、2025年はそれをどうプロダクション品質で構築・運用するかが大きなテーマとなっています。 イベントでは、このAIエンジニアリングを支えるためのツールをいくつも発表しました。以下はその代表例です： MLflow 3.0：AIモデルやエージェントの性能評価・モニタリングに対応 DSPy 3.0：プロンプトを自動チューニングするAI AgentBricks：自然言語ベースでAIエージェントを設計・評価・改善できる新環境 これらのツールを活用することで、AIの開発・評価・改善の全工程が自動化・効率化され、AIの活用を一段階上の次元へと引き上げています。 MLflow 3.0：LLM Judgeによる品質管理の強化 出典：Wix社のブログ記事「 Customizing LLMs for Enterprise Data Using Domain Adaptation: The Wix Journey 」より 上の図は生成AIの品質をどのように担保していくかという点を端的に表現した図です。MLflow 3.0の中核となるのが「 LLM Judge 」の概念です。これは、AI出力の品質を別のAIが評価する仕組みで、従来のような期待出力との一致だけではなく、「その出力は適切か」「より良い回答か」といった柔軟な評価が求められる生成AI時代に対応しています。 LLM Judgeでは、入力と出力のペアに対し、「この結果は妥当かどうか」を判断する ジャッジ用プロンプト を用意し、その結果に基づいてプロンプトの改善やキャリブレーションを行います。人間の専門家が関与する場合もあり、出力の妥当性や改善点を精査します。 DSPy：プロンプトを自動チューニングするAI DSPyが提供するプロンプト自動チューニング技術の概要 出典：Chen et al., “ Optimizing Instructions and Demonstrations for Multi-Stage Language Model Programs ,” arXiv, 2024 これはプロンプトを自動で最適化することができるオープンソースで、AIが評価結果に基づいて自らプロンプトを調整・改善していきます。LLM Judgeによって成功・失敗のラベルが付いた出力をもとに、DSPyはFew-shot Exampleの追加や表現の微調整、失敗条件の回避といった形で、最適なプロンプトを自動生成します。さらに、評価データの拡充を促す機能も備えており、これらのプロンプト設計・チューニングもAIの仕事になりつつあります。 これらの機能は、AIがAIを自己評価・自己改善するという全く新しいパラダイムを実現しており、AI開発の属人性を排除し、高速・高品質なAI導入が可能となります。 AgentBricks：誰でもAIエージェントを開発できる時代へ 出典： Data + AI Summit Keynote Day 1 Databricksが新たに発表した「AgentBricks」は、AIエージェントの設計・開発・評価・改善を自然言語で完結できる統合開発環境です。これは、AIをデバッグするAI、と言えるものです。 以下は、AgentBricksの主な特徴です： 自然言語での要件入力：「こういうAIエージェントが欲しい」と記述するだけで構成が自動生成 エラーの自己診断と修正提案：ログを解析し、最適な修正案を提示 再学習・改善の自動化：Agentの振る舞いを継続的に改善・最適化 これらは、すべてDatabricksの統合プラットフォーム上で動作し、生成AI、評価AI、オーケストレーションAIが連携して一つのシステムを構築するという、非常に高度な連携が実現されています。 現時点ではまだまだAIエンジニアを対象とした機能ですが、将来的にはノーコードでのAI開発が一般化し、ビジネスユーザー自身がAIを活用する未来の実現が見えてきています。まさに、AIエージェントの民主化と呼べる流れです。 セルフ分析の高度化：自然言語で設計できるETLと、AIによるBI支援の進化 今回のキーノートでは、Databricksが長年掲げてきた「データ活用の民主化」に向けた大きな進展が示されました。特に注目を集めたのが、Lakeflow DesignerとAIによるBI支援機能の2つのデモです。 ノーコードTEL：LakeFlow Designerデモ 出典： Data + AI Summit Keynote Day 2 Lakeflow Designerは、自然言語による指示でETL処理を構築できるノーコードツールです。デモでは、コンタクトセンターの通話ログを用い、「案件がクローズされているか」を判定する列を追加し、担当者ごとのクローズ率を算出する処理が自然言語で実行されました。 処理内容は自動的に視覚化され、各ステップの入力・出力も容易に確認できます。さらに、プレゼンターが集計イメージ（画像）をアップロードし、「このように集計したい」と指示したところ、対応するSQLと処理フローが自動生成される様子が披露され、会場でも驚きの声が上がるほどの注目を集めました。 AIによるBI支援デモ（高度なクエリ例：なぜここで跳ねている？） 出典： Data + AI Summit Keynote Day 2 AIによる高度なクエリ処理の例として、BI分析が紹介されました。時間ごとのマーケティングインプレッションを示す折れ線グラフに急増箇所があり、その理由を自然言語で尋ねると、AIが関連テーブルを自動で検索し、「APAC地域のマーケティング活動が増加している」といった解釈を即座に提示してくれます。さらに、その根拠となるテーブルも自動表示され、背景まで把握できます。これまでこうした分析にはデータエンジニアの助けが必要でしたが、今後は自然言語だけで直感的に深い分析が行えるようになる点が、大きな進化として紹介されました。 dotDataの視点から見た3つの注目ポイント Databricks AI & Data Summit 2025の全体を通して、dotDataが特に注目したトレンドは次の3つです： データ基盤の整備による社内データの統合の加速 データプロダクトの概念の深化と基盤の拡充 自然言語によるAI活用の進展により、非エンジニアでもデータ加工やAI構築が可能になったこと 一方で、データ活用の「民主化」には未解決の課題も残ります。この10年、分析ツールやAutoMLなどの普及にも関わらず、多くのビジネスユーザーが深い分析や洞察を引き出せていないのが実情です。デモで示されたような高度なクエリ応答を実現するには、現場で価値を出し続けるためのデータ整備が必要ですが、データ整備には大きな労力とスキルが求められます。また、データが整備された上でも、ビジネスユーザーが深い洞察を得るには、データに対して正しい「問い」を立て、そこから得られる結果を深堀りしていくスキルが求められます。 dotDataのアプローチ：dotData InsightとdotData Feature Factory こうした課題に対し、dotDataはdotData InsightとdotData Feature Factoryという2つのソリューションを提供しています。 dotData Insight は、業務部門が主導するデータ分析をAIが支援する仕組みです。AIが業務データから自動で重要な特徴量を抽出し、ユーザーは専門知識がなくても「こういうことが知りたい」という問いをもとに分析を進められます。さらに生成AIがその結果に対する解釈や仮説設計を支援するため、分析のハードルが大きく下がります。 一方、 dotData Feature Factory は、Databricksと連携して、社内の構造化・非構造化データを特徴量化し、メタデータ付きの高品質なデータプロダクトとして活用できるようにする仕組みです。これにより、生の業務データを「シルバーデータ」や「ゴールドデータ」へと昇華させ、Unity Catalog上でガバナンスを効かせた管理が可能になります。 これらを組み合わせることで、dotData Insightは従来のBIやMLツールと連携しつつ、誰もが使える分析プラットフォームの実現を目指しています。さらに詳細なデモや活用事例について興味がある方は、ぜひお気軽に お問い合わせください 。 The post Databricks AI + Data Summit 2025レポート – AIエージェントからLakehouseまで、未来のデータ活用とは appeared first on dotData .

2025年、サンフランシスコで開催された「Snowflake Summit 2025」は、「Build the Future of AI and Apps」をテーマに、世界中から約2万人が参加する過去最大規模のイベントとなりました。日本からも300名以上が現地に足を運び、クラウドデータやAI活用に対する関心の高さが伺えました。 本記事では、特に印象的だったキーノートや新機能の数々を紹介しつつ、Snowflakeがなぜ「次世代のクラウド型データプラットフォーム」として注目されるのか、その理由を掘り下げていきます。 Snowflakeとは？ Snowflakeは、クラウド上でデータウェアハウス、データレイク、データエンジニアリング、そしてAI・アプリケーション開発までを一貫して実行できる、統合型のクラウドデータプラットフォームです。AWS、Azure、Google Cloudといった主要クラウドに対応し、構造化・半構造化・非構造化データのすべてを扱える柔軟性を持つ点が特徴です。また、セキュリティやガバナンス、スケーラビリティに優れ、データの集約から分析、AI活用までをワンストップで支援する基盤として、世界中の企業で導入が進んでいます。 AI 時代におけるデータ戦略とデータ品質の重要性 出典： Snowflake Summit 2025 Opening Keynote With Sridhar Ramaswamy, Sam Altman, And Sarah Guo データ戦略なしにAI戦略はありえない Snowflake Summit 2025の初日のオープニングキーノートで、Snowflake CEOのスリダール・ラマスワミ氏は、「There is no AI strategy without a data strategy（データ戦略なしにAI戦略はありえない）」という明確なメッセージを発信しました。これは、AIを本格的にビジネスで活用するためには、まず堅牢で一貫したデータ戦略が不可欠であるということを強調するものです。 企業が競争力を維持・強化していくためには、構造化データや非構造化データを正確に収集し、適切に管理・活用するための基盤が必要です。Snowflakeはクラウドネイティブなデータプラットフォームとして、データの統合、ガバナンス、分析までをシームレスに実現できる環境を提供しており、まさに「AI Ready」を支えるインフラとしての役割を果たしています。 データの品質、「神聖さ」へのこだわり ニューヨーク証券取引所（NYSE）プレジデントのリン・マーチン氏が、「Sanctity of Data（データの神聖さ）」という表現を用い、AI活用におけるデータ品質の重要性について強く訴えました。「AIを真に機能させるには、信頼できる“真実の源（good source of truth）”が必要であり、それが欠けると、望ましくない結果（unfortunate outcomes）を招く」との指摘は、多くの参加者の印象に残ったはずです。 特に生成AIにおいては、事実に基づかない誤出力、いわゆる「ハルシネーション」がしばしば問題になります。こうした事象の多くは、元となるデータの質や構造に起因しているため、AIを有効に活用するには、信頼性の高いデータの整備と品質管理が欠かせません。この「データの神聖さ」という視点は、翌日のプラットフォームキーノートでも繰り返し取り上げられ、AI戦略を支える根幹として、データ品質の重要性が改めて強調されました。 「複雑をシンプルに」、テクノロジーの美学 ラマスワミ氏はまた、「The true magic of a great technology is taking something that’s very complicated and making it feel easy. The key to a great solution is simplicity.」（偉大なテクノロジーの真の魔法は、非常に複雑なものを簡単に感じさせることにあります。素晴らしいソリューションの鍵はシンプルさです。）とも語りました。これはまさに、私たちがプロダクト開発において最も大切にしている価値観の一つ、「シンプルさ」に通じる考え方です。 データサイエンスや統計といった領域は、ユーザーのスキルや知識レベルによって理解度が大きく異なります。だからこそ、dotDataでは、アドバンスドユーザーだけでなく、カジュアルに分析したい方にも最適な体験を提供できるよう、ユーザーに応じたベストなUXを日々追求しています。 AIやデータ活用が進む一方で、システムはますます複雑化しています。その結果、運用・管理が難しくなったり、理解に時間がかかるという課題も出てきています。Snowflakeはこうした状況に対し、「複雑なものをシンプルにする」ことを製品設計の中心に据えており、直感的で使いやすい体験を重視しています。この姿勢は、私たちが目指す製品開発の方向性とも一致しており、今後のAI時代においてさらに重要性を増していくと感じます。 サム・アルトマン氏とのパネルディスカッション オープニングキーノートにはOpenAI CEOのサム・アルトマン氏も登壇し、パネルディスカッションの中で2025年におけるAIとの向き合い方について問われました。その中でアルトマン氏は「Just do it（まずやってみること）」というシンプルな言葉を選びました。 AI技術が日進月歩で進化するなか、慎重に計画を練りすぎるよりも、まず小さくてもいいから実行に移すことが重要である──というアルトマン氏の考え方は、現場の担当者にも経営層にも強いインパクトを与えるものでした。AI時代の不確実性の中で、スピード感を持ってチャレンジする姿勢の大切さを再認識させられる発言でした。 Snowflakeの何がすごいのか？注目の最新アップデートを解説 2日目のプラットフォームキーノートではSnowflakeの執行役員製品担当クリスチャン・クレイナーマン氏らが、同社の主要なアップデートを紹介しました。 今回は、データとAIに関するイノベーションを、顧客の視点に立ってわかりやすく伝える工夫として、「I want…（〜したい）」というニーズ表現を軸に、さまざまなユースケースが提示されました。それに対してSnowflakeがどのような機能で応えるのかを、「You can…（〜できる）」という形で紹介する構成となっており、顧客のニーズとSnowflakeのイノベーションをつなぐ形で、各アップデートの意義が語られました。 将来性のあるデータアーキテクチャが欲しい（I want a data architecture that is futureproof） データのライフサイクル全体を支える単一プラットフォーム Snowflakeは、将来的な拡張性と柔軟性を備えた Single Unified Platform として進化を続けており、ビジネスの新たなニーズが発生した際にも、データの場所やシステムの違い、さらにはコンピューティングの環境差にもとらわれず、迅速に対応できる基盤を提供しています。これは、データのライフサイクル全体にわたってユーザーの取り組みを支援するという設計思想に基づいています。 Apache Icebergによる柔軟なデータ管理とOSS支援 その中核となるのが、オープンフォーマットである Apache Iceberg のサポートです。Iceberg は構造化・非構造化を問わず、大規模データを効率的に管理できるテーブルフォーマットであり、柔軟なデータアーキテクチャの構築を可能にします。SnowflakeはOSS開発支援にも積極的に取り組んでおり、Apache Iceberg の Variant 型のサポートなど、相互運用性とオープン性の向上に貢献しています。 Apache Polaris Catalogによるエコシステムの拡張性 さらに、Apache Polaris Catalogとの連携によって、Snowflake外部のクエリエンジンやデータ分析基盤との接続も可能となり、コンピューティングリソースを外部と柔軟に連携させながら、エコシステム全体としての拡張性を確保しています。これらの技術基盤により、Snowflake はAI時代のデータ活用に求められる「将来性のあるデータアーキテクチャ」の実現を支えています。 全てのデータをガバナンスしたい（I want to govern all my data） Snowflake Horizon Catalogによるデータガバナンス データガバナンスの観点では、Snowflake Horizon Catalog が中核機能として位置付けられており、データの発見・理解・アクセス制御ポリシーの適用・タグ付け・継承管理など、組織全体での安全かつ効率的なデータ活用を実現しています。たとえば、センシティブデータを自動的に検出・タグ付けし、その情報が派生テーブルにも引き継がれる仕組みにより、厳格かつ一貫性のあるデータ管理が可能です。 センシティブデータの自動管理 Snowflake Horizon Catalogでは、個人情報などのセンシティブデータを自動的に検出し、タグを付与する機能が備わっています。これにより、あるテーブルに機密性の高い情報が含まれている場合、そのデータを元に作成された新たなテーブルにも自動でタグが継承され、情報漏洩リスクを低減できます。 シンセティックデータ生成（Synthetic Data Generation） 機密データを直接扱えない開発・検証環境向けに、既存のテーブルをベースにしたダミーデータの自動生成機能も提供されています。ただのランダムデータではなく、元データの分布を模倣した構造になっており、分析可能な品質を保ちつつ、安全性も確保されています。 Internal Marketplaceとの連携 社内に存在するデータ資産やAIアプリケーションを横断的に管理・検索できる Internal Marketplaceも導入されています。利用者は目的のデータやアセットをポータル上で検索し、利用申請を行うことができます。管理者は申請の内容を確認し、使用目的やコストなどを把握した上で、承認・制御を行う仕組みとなっています。 この仕組みにより、大規模組織内での安全なデータ共有と再利用が促進され、データの価値を最大化しつつ、コンプライアンスやコスト管理との両立が可能になります。 さらに、このInternal Marketplaceは dotDataとの親和性も高く、たとえばdotDataで生成された新たな特徴量テーブルなどを、社内の他部門と安全かつ効率的に共有・利活用するためのデータ分析基盤としても機能します。特徴量というビジネスに意味のある情報を、Internal Marketplace上で「データプロダクト」として取り扱うことで、組織全体でのAI・分析活用を加速させることが可能です。 このように、SnowflakeとdotDataの連携によって、データのガバナンスと実用的な分析活用が一貫したプロセスで実現される点は、非常に大きな利点と言えるでしょう。 あらゆる種類のデータを統合したい（I want to integrate all types of data） 非構造化・ストリーミング・バッチすべてを取り込むSnowflake Openflow Snowflakeはもともと構造化データに特化したデータ分析基盤として発展してきましたが、AI時代を迎える中で、非構造化データやストリーミングデータも含めた統合的なデータ処理基盤へと進化を遂げつつあります。 今回発表された新機能「Snowflake Openflow」は、その象徴的な取り組みの一つです。Openflowは、バッチ処理、ストリーミング、ファイルベースなど多様なデータソースを、統一されたインターフェースでSnowflakeに取り込むことができるパイプラインサービスです。 Apache NiFiベースで柔軟なデータ取り込みを実現 Openflowは、オープンソースのApache NiFiを基盤としており、Snowflakeが公式にサポートしていないような特殊なデータソースにも柔軟に対応可能です。GUIベースで視覚的にパイプラインを構築できるため、エンジニア以外のユーザーにも扱いやすい設計となっています。 この仕組みにより、従来は複雑なETL開発が必要だった非構造化データやリアルタイムデータの取り込みが、よりスムーズにSnowflake上で実現できるようになりました。 Datavoloの買収による技術統合 このOpenflowの背景には、Snowflakeが買収したDatavoloの技術統合があります。買収後、自社プラットフォームに組み込まれたことで、Snowflakeとの親和性が飛躍的に向上。データの取り込みから活用まで、エンドツーエンドで支援する強力なデータパイプライン基盤として提供されています。 より大きなビジネスインパクトをもたらしたい（I want to deliver more business impact） データだけでなくアプリケーションも扱えるプラットフォームへ Snowflakeは、従来のデータウェアハウスの枠を超え、アプリケーションホスティング基盤としての機能拡張を進めています。データに加え、アプリケーションを同一基盤上で実行・管理できるようになることで、データドリブンな意思決定とアクションをシームレスにつなぐことが可能になります。 「Snowflake Postgres」でトランザクションアプリ開発を支援 今回新たに発表された「Snowflake Postgres」は、PostgreSQL互換のマネージドデータベースです。従来、Snowflakeは分析用途に最適化されたデータ基盤であり、トランザクション処理にはやや不向きとされてきました。しかし、Snowflake Postgresの登場により、業務アプリケーションやトランザクション系のシステム開発もSnowflake上で実現できるようになります。 たとえば、昨年 GA となった Snowflake 内でコンテナ化されたアプリケーションを実行・管理できるフルマネージドサービスの「Snowpark Container Services」と組み合わせることで、いわゆる業務アプリケーションをSnowflakeのセキュアで統制された環境内でホスティングすることができるようになっていくような方向性が考えられます。 これが実現すると、企業はデータ分析とアプリケーション実行の両面を同一基盤で管理できるようになり、開発・運用の効率性と一貫性が大幅に向上できそうです。 データから価値創出までを一気通貫で実現 Snowflakeのこうした進化により、データ分析から施策実行までをワンストップで行える環境が整いつつあります。データを集めて終わりではなく、インサイトを即座にアプリケーションやサービスに反映することで、ビジネスインパクトを最大化できるようになります。 もっと速いインサイトが欲しい（I want to get faster insights） 非構造化データをSQLで直接分析可能に Snowflakeが新たに発表した「Cortex AI SQL」は、構造化データと非構造化データの垣根を超えて、SQLで直接クエリを実行できる革新的な機能です。これまで、画像・音声・テキストなどの非構造化データを扱うには、ETL処理や特徴量の抽出、ラグ（RAG）の構築など、手間のかかる前処理が必要でした。 AISQLを使えば、こうした前処理を行わずに、直接SQLを使って非構造化データを分析することが可能になります。これは、構造化データ中心だった従来のBI・分析ツールとは一線を画す進化です。 生成AIを活用した柔軟なクエリ実行 AISQLでは、生成AIがクエリを補助することで、今まで困難だったユースケースも簡単に実現できます。たとえば、以下のような複雑な分析が可能になります。 バナー画像の類似検索とパフォーマンス比較 過去に使用されたバナー画像と似た画像をAIが検索し、それらのクリック率をSQLで比較・分析。どのビジュアルがより効果的かを可視化できます。 注目企業に関連するニュース記事の自動マッチング ウォッチ対象の企業リストと、ニュースデータをAIフィルターで自動的にジョインし、関連性の高い記事だけを抽出。投資判断やマーケティング分析に活用できます。 このように、SQLと生成AIを組み合わせることで、画像・テキストなどの非構造化データをシームレスに活用できる点がAISQLの大きな特長です。 幅広い業務シナリオに対応可能 AISQLの活用シーンは上記にとどまりません。たとえば、以下のような業務にも応用できます。 顧客からの問い合わせチケットと、社内ナレッジベースとの関連づけ カスタマーサポートのFAQ文書とチャットログとのマッチング 非構造化ドキュメント内の記述と業務フラグの相関分析　など これらをSQLベースで実現できることで、データサイエンスやMLの専門知識がなくても、高度な分析とインサイト抽出が可能になります。 データをAI対応にしたい（I want to get your data ready for AI） 自然言語での分析に欠かせない「意味」を備えたデータへ AI、とりわけ生成AIをビジネスで活用する際、壁となるのが「クラウドデータや構造化データに含まれる“意味”をAIが理解できていない」という課題です。たとえば、「売上」や「クリック率」といった言葉ひとつをとっても、組織ごとに定義や計算方法は異なります。Snowflakeのようなデータプラットフォーム上に蓄積されたビッグデータを、文脈に即して活用するには、システム的なデータとビジネス的な意味づけを橋渡しする仕組みが必要になります。 Semantic Viewでビジネスコンテキストを定義 Snowflakeは、この課題に対する解決策として「Semantic View」という新たなクラウド型データプラットフォーム機能を導入しました。Semantic Viewは、売上や利益といったビジネス用語と、Snowflakeのデータウェアハウス上にある実際のデータソースや計算式をひも付けて定義できるレイヤーです。この定義を通じて、生成AIは自然言語の質問に対して、どのテーブルの、どのカラムを、どのように集計すればよいのかを自動的に判断できるようになります。 正しい答えを導くための前提を整える 生成AIに対して「この月のクリック率を教えて」と質問しても、クリック率の算出式や参照すべき期間、使用するテーブルが明確でなければ、AIは正しいSQLを生成できません。実際、Snowflakeのセッションでは、Semantic Layerを使用した場合と使用しない場合で、自然言語クエリに対する正解率に明確な差が生じるという検証結果も共有されていました。Semantic Layerを適用したケースでは、AIが正しい回答を返す割合が大幅に向上しており、「意味を与えたデータ」がAI活用の前提であることが、改めて裏付けられました。 AI活用に不可欠な「データの意味」を組織で共有する Semantic Viewによって実現されるのは、単なるデータの補足情報ではなく、「組織として共通の意味でデータを見る」ためのフレームワークです。これにより、AIが人間のようにビジネスコンテキストを理解し、意図に即した答えを返すことが可能になります。AIの正確なアウトプットは、その背後にあるデータ構造と意味付けがいかに整備されているかにかかっています。SnowflakeのSemantic Viewは、まさにその要となる仕組みです。 AIエージェントでビジネス成長を加速したい（I want to accelerate business growth with AI agents） 人に代わって考え、提案し、動くAIエージェントの登場 Snowflake Summit 2025で最も注目を集めた機能のひとつが、「Snowflake Intelligence」と呼ばれるAIエージェント機能です。従来のBIツールやアシスタント機能では、あくまでユーザーが明確な意図を持って操作する必要がありました。しかし、Snowflake Intelligenceは、それを一歩進めて、「ユーザーの代わりに仮説を立て、適切な分析を行い、結果を提示する」ことが可能な、自律型のAIエージェントです。 自然言語での指示に自律的に対応 たとえば、ユーザーが「今月のフェスティバルチケットの販売トレンドを教えて」と自然言語で入力するだけで、Snowflake Intelligenceは内部のSemantic viewやユーザーの権限情報を参照し、必要なデータにアクセス。適切な分析処理を自動で行い、結果を可視化して提示してくれます。 この流れは、ユーザーが明示的に「どのテーブルを使って、どんな条件で分析するか」といったことを指定する必要がないため、非技術者でも容易に高度な分析を行えるという大きなメリットがあります。 Semantic Layerと連携して正確性を担保 AIエージェントの信頼性を支えているのが、前述のSemantic Viewとの連携です。単に生成AIが自由にSQLを作るのではなく、組織で定義されたビジネスロジックに基づいてクエリが生成されるため、「何となくそれらしい答え」ではなく、「ビジネス的に正しい答え」を導き出せるようになっています。この仕組みにより、「AIは何を根拠にその結論を出したのか？」という説明責任（Accountability）にも対応することができ、企業にとっても安心して導入できる要素となっています。 AI活用のハードルを一気に下げる革新 このようなAIエージェントの進化により、データ分析や活用のハードルは一気に下がりつつあります。これまで専門部署やデータサイエンティストに依存していた業務でも、現場の担当者が自らAIを活用して仮説検証や施策立案を行える時代が到来しようとしています。Snowflake Intelligenceは、その第一歩となる画期的な機能であり、「AIを使う」のではなく「AIと共に業務を進める」という新しい業務スタイルを現実のものにしようとしています。 Snowflake Summit 2025まとめ：AI活用に向けた「AI Ready」なデータ基盤へ Snowflake はクラウド型データプラットフォームとして、データウェアハウスとデータレイクの両方を兼ね備えたハイブリッドな構成を実現しており、クラウドネイティブなアーキテクチャにより、構造化データ・非構造化データの双方に柔軟に対応しています。 本サミットで発表された数々の機能は、まさに「AI時代に最適化されたクラウドデータ基盤」の方向性を示しています。クラウド上の膨大なデータをどのように統合し、どのように活用するか、その問いに、Snowflake は確かな答えを提供し続けているのです。 AI時代の競争力を高めるために、Snowflakeの導入を検討する企業が増えているのも納得です。今後、Snowflake と dotData の連携がさらに進むことで、日本企業のAI活用も次のステージへと進化していくことでしょう。 AI時代のデータ活用を加速する：dotDataとSnowflakeの連携 Snowflake Summit 2025では、「AI Ready（AI活用の準備が整った状態）」というキーワードが繰り返し登場しました。AIをビジネスで活用するには、単にデータを集めるだけでなく、整理・管理し、インサイトへと変換できる状態にしておくことが求められます。この「AI Ready」を実現するうえで、SnowflakeとdotDataの連携が重要な意味を持ちます。 Snowflakeは、構造化・非構造化を問わず、膨大なデータを効率的に蓄積・処理・ガバナンスできる、強力なデータ基盤を提供しています。しかし、蓄積された“生データ”は、ビジネスインサイトに直接つながるとは限らず、活用には仮説の立案やSQLの知識が必要になる場合もあります。 そこで有効なのが、dotDataが提供する dotData Feature Factory です。これは、Snowflakeに蓄積されたデータから、AIが特徴量（ビジネスの目的に対応するデータに隠れた重要なパターン情報）を自動生成する仕組みです。生成された特徴量は、Snowflake上でガバナンスを維持したまま、他部署やアプリケーションと安全に共有できます。 さらに、 dotData Insight と組み合わせることで、生成された特徴量からビジネスKPIへの影響要因を発見し、施策立案や対象リストの抽出までを、専門知識なしで直感的に実行することが可能になります。 このように、SnowflakeとdotDataを組み合わせることで、 蓄積されたデータの整備・変換 ビジネス視点でのインサイト抽出 アクションにつながる施策の実行 という一連の流れを、一気通貫で実現できます。 すでにSnowflakeを導入しており、次のステップとしてAI活用や高度な分析に取り組みたいとお考えの企業、あるいは可視化を超えた深い示唆を得たい企業にとって、この連携は極めて有効なアプローチとなるでしょう。自社のデータをもっと活かしたい、AI活用を次のフェーズに進めたいとお考えの方は、 ぜひ一度ご相談ください 。 The post Snowflake Summit 2025 レポート – AI時代に求められるクラウドデータプラットフォームの進化とは appeared first on dotData .

はじめに：製造業の生産性向上と品質改善の重要性 製造業における生産性向上や品質の確保は、企業の競争力と利益率の維持に直結します。特に歩留まり改善や不良品削減の取り組みは、全社的な生産性の向上に大きく寄与します。 たとえば、スクラップや手直し、リコールといった不良コスト（CoPQ）は、 売上の5〜30％ に及び、業界によっては運用コスト全体の約40％を占めることもあります。 マッキンゼーの事例 では、ある半導体メーカーが歩留まりの問題によって6,800万ドル（約100億円）の損失を被ったと報告されています。このような課題は、生産性を高める上でも無視できません。 製造業における生産性向上を阻む「複雑なデータ」 製造業の生産性を向上させるには、工程や品質に関するデータの活用が不可欠です。しかし、現代の製造プロセスでは、センサー（温度、圧力、振動）、MES（製造実行システム）、SCADA（監視制御およびデータ収集システム）、ERP（基幹業務システム）、環境、設備、オペレーター入力、顧客データなど、多種多様な情報が膨大に存在しており、これらを効率的に活用するのは容易ではありません。 企業では、初回合格率や不良率、直行率などのKPIを用いて生産性を測定していますが、これらは「結果」を示すだけで、「なぜ」生産性が低下したのかといった原因解明にはつながりにくいのが現状です。特に従業員ごとの作業ばらつきや、原材料のロット違いによる微細な差異を可視化するには、より深いレベルの分析が必要です。 データ量・幅・複雑さと生産性の関係 製造業で生産性を高める上で最大の障壁となるのは、データ量そのものではなく、データの項目数（＝幅）と、それに伴う複雑さです。 データ量とスピード：産業用IoTやPLC、各種制御機器からは、日々テラバイト規模のデータがリアルタイムで発生しており、それに対応するスピーディな分析が求められます。 データの多様性：パラメータや検査結果といった構造化データだけでなく、バッチログのような半構造化データや、メモ・画像といった非構造データまで含まれるため、扱いが複雑になります。 信頼性の確保：LIMS（ラボ情報管理システム）やヒストリアンなど、さまざまなシステムから集まるデータの正確性や一貫性を保つのは難しく、部門ごとのデータの分断（サイロ化）も生産性向上の妨げとなっています。 データの多次元性：1つの生産バッチで数百〜数千もの変数が記録されることもあり、それらの組み合わせが生産性にどう影響しているかを特定するのは非常に難しいのが実情です。 このような「広くて深い」データの中から、生産性の向上につながる具体的な要因を見つけるには、新しいアプローチが求められています。 従来の方法の限界と、製造業が生産性向上に取り組むうえでの課題 製造業が生産性向上に取り組む際、過去に利用されてきた分析手法には、いくつかの明確な制限があります。 1. 手作業によるデータ分析（Excel・スプレッドシート・現場経験） 従業員の経験や勘に基づき、データをExcelに手動で取り込み、グラフやピボットテーブルで仮説を立てるアプローチは今でも多くの製造業で見られます。 しかしこの方法は、以下のような問題があります： 分析に時間がかかり、生産性の低下を招く 数百列におよぶ複雑なデータに対応できない（拡張性がない） 担当者の経験や注目項目に左右され、属人性が高く再現性がない 人為的ミス（コピペ、数式間違い）が起きやすく、分析の信頼性が低い 2. 従来型のBI・可視化ツール（Tableau、Power BIなど） BIツールを活用してKPIをグラフで可視化する手法は、生産性の現状把握に役立ちます。ですが、なぜそのKPIが変動したのかを深く掘り下げるには限界があります。 仮説ベースの分析で、ユーザーが何を探すかを事前に知っていなければならない 数百〜数千の変数を同時に横断的に分析する機能が弱く、複雑な要因分析が困難 例えば「湿度が上がると不良率が増えた」というグラフが出ても、具体的な数字として「湿度55%以上のときに不良の93%が集中している」ことまでは自動的に示せない 3. 統計ツールやSPCソフト（SAS、R、Python、Minitabなど） これらは分析のプロやデータサイエンティスト向けの強力なツールですが、製造業における生産性向上を日常業務で実現するには以下の課題があります。 専門スキルが必要で、一般の従業員や現場担当者が使いこなすのは難しい 仮説を立てた上での検証には長い時間がかかり、リアルタイム性に欠ける 既知の変数しか扱えず、未知の組み合わせ要因（例：バルブAが開いていて、かつ化学品Xが5%未満）を発見できない 分析プロセスが複雑で保守・改修にコストがかかり、生産性向上への投資効果が低い こうした課題により、製造業では生産性の向上に向けた取り組みが断片的・属人的になりがちです。 dotData Insight が実現する、製造業の生産性向上と効率化 dotData Insight は、統計AIと生成AIを組み合わせることで、こうした課題を解決。製造現場に蓄積された複雑かつ膨大なデータを自動で深く分析し、生産性向上を強力に後押しします。 統計AIと生成AIによる高度な分析 dotData Insightは、構造化・非構造データを含む多様な情報を直接接続し、KPI（歩留まり、不良数、生産量など）に影響する重要な要因を自動的に探索します。その特長は以下の通りです： AIが膨大な製造データをくまなく探索 数百万通りのデータパターンを自動で調べ、歩留まりや不良率に影響を与えている「本当の原因」を見つけ出します。人手では気づけない複雑な要因もスコア付きで提示され、何が成果に影響しているのかが一目でわかります。 「見落とされがちな品質リスクが潜む要因」を自動で発見 たとえ仕様範囲内の条件であっても、性能に大きな影響を与える微細な条件や閾値（特徴量）をAIが自動で見つけ出します。これにより、従来のBIソリューションではできなかった運用効率の実現が可能。 複数の条件を組み合わせて、影響を深掘り分析 AIが見つけた複数の要因を組み合わせて、「夜勤×原料Y×装置Z」のようなミクロな集団を自動抽出。それぞれが成果にどう影響しているかを具体的に分析できます。 誰でも使える、ノーコードの使いやすい画面 専門的なプログラミングは不要。BIツールを使い慣れたユーザーや製造エンジニアでも直感的に操作できる、シンプルでわかりやすい画面設計になっています。 現場のデータにも柔軟に対応 リレーショナルデータやトランザクション、季節性・遅延・祝日を含む時系列データ、テキストデータ、位置情報など、製造業特有の“雑多で複雑なデータ”も扱えます。AIによるデータクレンジング機能も備えており、自動的に対処します。 dotData Insightは、これまで時間や労力を要していたディープアナリティクスのプロセスを自動化し、わかりやすく・すぐに使える形で提供することで、データ分析に費やす時間を削減。チームは、インサイトの活用やプロセス改善といった本来注力すべき業務に集中できるようになります。 製薬業における具体的な事例 製造業の中でも、製薬業界では特に工程条件が繊細で、生産効率や品質への影響が大きいという特徴があります。バイオリアクターなどの装置は、温度、pH、溶存酸素、通気、濃度など、複雑な条件のもとで稼働しており、わずかな変動が製品の歩留まりや品質に直結します。 今回は、「 Industrial Scale Penicillin Simulator 」で公開されているペニシリン発酵プロセスのシミュレーションデータを使用し、dotData Insightを活用した分析を行いました。 dotData Insightによる生産性向上の発見例： リアクター温度が0.05K変化しただけで歩留まりに有意な影響 冷却水の流量が150 L/h未満の条件で歩留まりが変化 これらの条件を組み合わせることで、全バッチのうち46％が該当し、平均より15％高い歩留まりを記録するセグメントが抽出されました このように、dotData Insightでは特徴量の発見と要因の組み合わせ分析によって、現場の生産性を高める具体的な条件を明確に把握できます。 さらに、生成AIによる自然言語での解釈によって、現場担当者やマネージャーが理解しやすい形で提示されます。以下は、温度条件に関するAIの自動解釈の一例です： 「過去7日間のバッチにおける総温度が298.05K〜298.32Kの範囲であった場合、温度制御にわずかな不安定性が存在する可能性があります。これらの変動が化学反応に影響を与え、生産量の低下や不良率の上昇を引き起こしている可能性があります。」 従来なら数週間から数か月かかっていた分析作業が、dotData Insightによって数分で完了し、生産性向上に即座に活かせる結果を得られるのが最大の特長です。 隠れたインサイトをビジネス価値に変える dotData Insight を活用することで、製造業における生産性の向上と品質改善が具体的に実現できます。以下は、実際に得られるメリットの一例です。 1. スクラップ・不良の削減 不良品の発生条件を特定し、標準作業手順（SOP）の見直しや制御限界の調整が可能になります。これにより、不良コストの削減が図れ、製造業における生産性の向上とコスト効率化が同時に実現します。 2. スループットと作業効率の向上 dotData Insightは、再作業やトラブルシューティングの時間を大幅に短縮し、現場の生産性を高めます。設備総合効率（OEE）の改善、設備故障の減少による生産ラインの安定化など、生産性向上に直結する効果が期待できます。 3. 製品の一貫性と品質の強化 主要な要因を継続的に監視・制御することで、製品品質のばらつきが抑えられ、労働生産性の安定化や出荷品の信頼性向上につながります。 4. 根本原因分析（RCA）の高速化 AIによって特定された要因やセグメントの活用により、トラブル発生時にも迅速な原因特定と対策実施が可能です。これは現場の効率化への大きな貢献となります。 5. データ主導の意思決定 たとえば「2番の炉が850〜875℃で稼働し、原料バッチがXJ-2のときに製品Zの歩留まりが4.5%向上する」といった具体的な分析結果をもとに、戦略的な改善施策を打つことが可能です。これは、生産性向上を実現する取り組みの成功事例といえるでしょう。 まとめ：勘や経験から脱却し、データで生産性を高める時代へ 今こそ、製造業が持つ膨大なデータの中にある「本質的な要因」を明らかにし、現場の生産性を向上させる具体的なアクションにつなげるときです。 従来の手作業やBIツール、統計ソフトでは、生産性の改善点を見逃しやすく、対応も遅れがちでした。しかし、dotData Insightのようなデータ分析プラットフォームを活用することで、「どの条件で生産量が最大化するのか？」「どの工程で不良率が高くなるのか？」といった問いに、もう勘や経験だけで答える必要はありません。データに基づいて正確に判断できる組織へとシフトしていきましょう。製造業の未来は、これまで見えなかった因果関係を“見える化”し、AIと人の力を融合させることで新たに切り拓かれていきます。 The post 製造業の生産性向上を導く、AIによる要因分析 appeared first on dotData .

製造業の現場におけるAI導入の課題 AI技術の進化により、企業が持つ膨大なデータを活用しやすくなった今、製造業でもAIの導入は避けて通れないテーマとなっています。生産性向上、業務効率化、品質の安定といった目的を達成するために、AIを活用した取り組みが進められています。 しかし、現場には「分析の進め方がわからない」「AIの結果がブラックボックスで理解できない」「導入後の運用に不安がある」といった課題が根強く残っています。こうした壁を乗り越えるためには、単にAIを導入するだけではなく、現場で実際に活用される仕組みが求められます。 その解決策の一つが、dotDataが提供する特徴量自動設計技術です。dotDataは、AIが膨大なデータの中から有効な特徴量を自動抽出し、人間が理解しやすい形で提示することで、専門知識のない担当者でも分析結果を業務に活かすことを可能にします。生成AIを用いたデータ活用の実現により、製造業でもAIを活用した意思決定が現実のものとなりつつあります。 この記事では、AI活用の先進的な導入事例として、横浜ゴム株式会社様、株式会社JALエンジニアリング様、キリンビール株式会社様、日本ゼオン株式会社様という4社の取り組みを紹介します。 1. 横浜ゴム株式会社様：人とAIの協奏による「ものづくり革命」 横浜ゴム様 は、タイヤ製造を中心とするグローバル企業として、早くからAIを導入し、製造現場の革新に取り組んでいます。横浜ゴム様のAI活用の核となるのが「人とAIの協奏」というコンセプトです。AIで得られた洞察を人間が解釈し、“気づき”や“ひらめき”として業務改善につなげるアプローチです。 この構想の実現を支えたのが、dotDataの特徴量自動設計でした。タイヤの試作評価データや製造プロセスのデータをdotDataに投入することで、どの因子が性能向上に寄与しているのかをAIが自動的に抽出。それを開発メンバーが評価・検証しながら新たな試作に反映するサイクルを確立しました。 特に成果が顕著だったのが、高性能タイヤの設計と、ゴム混合プロセスの最適化です。複数の要素が絡み合う中で、外気温、混合時間、ロータの回転速度などの複合因子を抽出し、従来の方法では得られなかった知見を得られたことで、生産性の向上と品質の安定化が同時に実現されました。 さらに、スタッドレスタイヤにおける氷上制動性能の予測にも活用が広がり、試作前の段階で性能を予測できるようになったことで、試作回数の削減と開発スピードの向上にもつながっています。 2. 株式会社JALエンジニアリング様：AIによる故障予測で「ゼロゼロ100」へ JALエンジニアリング様 は、「イレギュラー運航ゼロ」、「飛行中の不具合ゼロ」、「定時出発率 100％」を目指す「ゼロゼロ100」を掲げ、故障予測の高度化に取り組んでいます。従来は、整備士の経験に基づく仮説をもとにデータを検証する「仮説検証型分析」が主流でした。 しかし、センサーから得られる膨大な飛行データを前に、仮説を立てること自体が困難なケースも多く、AIによる新たなアプローチが求められていました。そこで採用されたのが、dotDataによる「仮説探索型分析」です。これは、AIが人間の仮説に頼らず、データから兆候を自動的に見つけ出す手法です。 dotDataは異常フライトと正常フライトのデータを比較し、AIが有意な特徴量を抽出します。抽出された特徴量の中から整備的に意味があるものをピックアップし、それを再度仮説検証するという、探索型と検証型を融合させた運用が実現されました。 この手法により、ボーイング787のエアコンシステム部品の故障予兆の検知に成功し、航空技術協会からの表彰も受けています。AIの導入により予測整備の質が向上し、安全性と運航の安定化という2つの柱が強化されました。 3. キリンビール株式会社様：「人に優しい工場」を支える生成AIの活用 キリンビール様 では、工場の負担軽減とさらなる品質向上を目指し、製造工程にAIを本格的に導入しています。キリンビール様はもともと熟練技能者の経験と勘に依存する場面が多く、そこにAIを用いた定量的な支援を組み合わせることで、現場の効率化を実現しています。 dotDataの活用により、ビールの品質予測、排水処理の負荷予測、冷凍設備の故障予知という3テーマでの実証実験が行われました。特に、温度や原材料などの特徴量を自動抽出し、それを人間が理解できるかたちで説明するdotDataの特性は、現場の理解促進に役立ちました。 また、現場でAIを運用するには、モデルの柔軟な更新や現場の声を反映したチューニングが欠かせません。キリンビール様は、パートナーの大塚商会様との連携により、現場の声を踏まえた実装を実現。AIの導入により、品質管理と省力化が同時に進み、より「人に優しい工場」へと近づいています。 4. 日本ゼオン株式会社様：AIで研究開発と製造現場に革新を、データ民主化の実現へ 日本ゼオン株式会社様 では、研究開発の高度化と生産効率の向上を目指し、AIの活用を本格化。その一環として、dotDataを導入しました。 従来は、数千の変数を手作業で解析し、膨大な工数と人的負担が課題でしたが、dotDataによりコーディング不要で高度な分析が可能に。自動で有用な特徴量を抽出できる点や、誰でも使いやすいインターフェースも導入の決め手となりました。 製造現場では、約1500のセンサーデータから重要な数個に絞り込むことで不良率を改善。解析時間も従来の100分の1に短縮されました。また、汎用ゴムの製造分析では、新たな改善の糸口が得られています。 dotData導入を契機に、専門知識がなくても現場担当者が自ら分析を行えるようになり、データ活用の文化が社内に定着。「読み書き・そろばん・AI」を基本スキルとする取り組みが進んでいます。 製造業におけるAI導入成功のポイントとは 4社の事例から浮かび上がるのは、AI技術の高度さだけでなく、現場にどう定着させるかという視点の重要性です。AI活用の成果は、単にツールを導入しただけでは得られません。導入後に、現場と連携して運用・改善を繰り返すことで、初めて実用的な成果に結びつきます。 dotDataのような、人が理解できる特徴量を提示するAIプラットフォームは、現場とデータ分析の橋渡し役として、製造業におけるAI導入の加速を支えています。今後、生成AIの技術がさらに進化する中で、製造業でAIを活用した課題解決の可能性はますます広がっていくでしょう。実際にどのような成果が出ているのか、 他の導入企業の事例 もぜひご覧ください。 The post 製造業で広がるAI – 現場で成果を出した4社の活用事例 appeared first on dotData .

Salesforceをご利用中の方であれば、リードや商談、取引先、担当者、活動履歴など、日々膨大な営業データに囲まれているのではないでしょうか。ダッシュボードには、コンバージョン率やパイプラインの金額、成約件数といった主要なKPIが並びます。しかし、こうした数値だけでは、顧客の行動や意思決定の背景までは見えてこず、「なぜこの結果になったのか」「次に何をすべきか」といった深いインサイトを得るのは容易ではありません。 たとえば、以下のような疑問はありませんか？ なぜ、見た目は似ているリードでも、成約に至るケースとそうでないケースがあるのか？ どのような営業活動の順序や条件が、有望な見込み客を見極める手がかりになるのか？ 成果が伸び悩む営業担当者が、どうすればトップセールスに近づけられるのか？ 営業マネージャーがSalesforceレポート作成に追われることなく、戦略の立案や成果の最大化に注力するにはどうすればよいのか？ こうした問いに答えを見つけられれば、営業・マーケティング・アナリストなど、さまざまなチームの生産性を大きく高め、売上の拡大につなげる強力な原動力になるはずです。 出典： Salesforce Developers「Sales Cloud Overview Data Model」 上の図は、Salesforce Sales Cloudにおける基本的なデータ構造を示しています。ご覧の通り、複雑に絡み合ったデータの中から、本質的なビジネスシグナルを見つけ出し、それを次のアクションにつなげていくことが営業分析の役割です。 しかし実際には、このようなマルチオブジェクトにまたがるデータ分析は、高度なスキルを持つアナリストにとっても簡単な作業ではありません。従来の営業分析ツールは強力ではありますが、使いこなすには専門知識や手間のかかる設定が求められ、分析結果に至るまで時間がかかります。その解決策として注目されているのが、AIによる営業分析です。AIを活用することで、データの準備や分析モデルの構築といったプロセスの多くを自動化でき、より迅速かつ手軽にビジネス上のインサイトを得ることが可能となります。 本記事では、「リードから商談へのコンバージョン分析」という、実際の現場でもよく直面する重要なユースケースを取り上げながら、SalesforceのCRM AnalyticsやTableauによる従来型のアプローチと、dotData Insightが提供する新しいAIドリブンなアプローチを比較していきます。 商談成約の背景にある“本当の要因”は、フラグ管理だけでは見えてこない リードが商談に転換したかどうかは、Salesforce上では「IsConverted = True」というフラグで簡単に判定できます。基本的なレポート機能でも把握可能です。 しかし、本当に知りたいのはその先にある「なぜこのリードは成約に至ったのか？」という問いへの答えです。リードがどんな経路で流入し、どのような接点を経て、どう動いたのか。その一連の流れを時系列で捉え、背景まで掘り下げて初めて、有益な気づきや改善のヒントが得られます。 営業活動を改善するために本当に答えを知りたいのは、次のような問いではないでしょうか？ ユーザーへの影響 ：あるマーケティングキャンペーンから獲得したリードは、特定の営業チームが対応したほうが商談化までのスピードが早いのでは？ コンタクトの頻度 ：メール・電話・面談など、商談につながるまでにどれくらいの接触回数が最適なのか？リードの流入元や業種によって違いはあるのか？ タイミング ：ミーティングの設定や電話のタイミングなど、営業活動が行われた「いつ」が商談の成否に影響しているのか？ 属性情報 ：顧客の業種や規模、関係する担当者の役職などが、商談の成否にどう影響しているのか？ 製品 ：リードの段階で興味を示していた製品は、その後の成約率や顧客のLTVとどんな関係があるのか？ こういった問いに答えるためには、Salesforceに散らばるデータをひとつにつなぎ、全体を俯瞰して分析することが重要です。 リード（Lead） ：見込み客の初期情報やステータスを保持する核となるレコード 取引先（Account） ：リードが属する企業情報 取引先責任者（Contact） ：リードや商談に関連する個人情報 商談（Opportunity） ：商談成立時に作成される契約の詳細レコード イベント（Event） ：リード、取引先責任者、取引先、商談に紐づく会議や予定 タスク（Task） ：電話、メール、ToDoなどの記録 リード履歴（Lead History） ：リードのフィールド変更、ステータス更新、所有権移動の履歴 こうしたマルチオブジェクトのデータに時間軸（タイミングや履歴の変化）という要素が加わると、分析の複雑さは一気に増します。標準的なSalesforceのレポート機能では限界があり、本質的なインサイトを得るには、マルチオブジェクトに対応した高度な分析手法が必要になります。 従来のCRM AnalyticsとTableauによる営業データ分析 営業データ分析のツールは数多くありますが、Salesforceユーザーの多くは、Salesforceが提供する2つの強力な分析プラットフォーム、「CRM Analytics」（旧：Tableau CRM / Einstein Analytics）と「Tableau」を活用しています。どちらも優れたツールですが、そのアプローチには違いがあります。 出典： Salesforce「CRM Analytics ダッシュボードを使ってみる」 Salesforce CRM Analyticsのダッシュボードは視覚的に洗練されていますが、構築には手間がかかり、詳細な分析機能が不足することもあります。 CRM Analytics：Salesforceネイティブならではの分析体験 CRM AnalyticsはSalesforceに統合されたBIツールで、Salesforce特有のデータ構造に最適化されている点が大きな強みです。 利用の流れ データ準備（データフロー/レシピ）： 最初に、Salesforce上の各オブジェクト（リード、取引先、担当者、商談、ToDo、活動、リード履歴など）から過去の営業データを取り込みます。取り込みには、レシピビルダーまたはより複雑なデータフローエディタを使い、オブジェクト間の結合関係（例：リードと活動、コンバージョン後の商談など）を定義します。リード履歴から時系列の変化やステータス更新を読み取るには、丁寧な変換ロジックが求められます。 データセットの作成： 準備したデータは、CRM Analytics内のデータセットとして保存されます。データ量や結合が多い場合は、パフォーマンスを意識した設計が必要です。 分析と可視化（レンズ/ダッシュボード）： 作成したデータセットをレンズで探索し、グラフやチャートを作成します。たとえば「第4四半期に商談化したリードの傾向を分析する」などの比較分析には、Compare Tablesの活用や、場合によってはSalesforce独自のSAQL（Salesforce Analytics Query Language）によるカスタムロジックの記述が必要になります。 ダッシュボードの組み立て： 複数のレンズを組み合わせてインタラクティブなダッシュボードを作成し、関係者に共有します。 出典： Salesforceヘルプ「データプレップを使用したレシピの作成」 結果、Salesforce CRM Analyticsのレシピは、構築が進むにつれて急速に複雑化する傾向があります。 ユーザーの使用感 使いやすさ レシピは視覚的なUIで基本操作は直感的ですが、複雑な結合や変換には一定の学習コストが必要です。SAQLを使う場面ではコーディングスキルも求められます。 営業分析のスピード 初期設定（レシピ作成・データ結合）には時間がかかります。セットアップが完了すれば高速に探索できますが、分析内容を変えるには準備工程からのやり直しが必要になることもあります。 作業負荷 マルチオブジェクトの結合や変換、SAQLの記述には、相応の工数と知識が求められます。 必要なスキル 本格的なマルチオブジェクト分析には、CRM Analyticsに精通した人材やデータモデリングスキルが必要です。セールスオペレーション担当が自力でセットアップするには、専門的なトレーニングが前提となるでしょう。 CRM Analyticsのまとめ メリット：Salesforceネイティブで、オブジェクト構造やデータの関係性をそのまま活用できる。 デメリット：初期構築に時間と専門知識が必要。SAQLやデータ変換ロジックの設計は非エンジニアにはハードルが高い。 必要なもの：CRM Analyticsのスキル、データ構造の理解、初期セットアップにかかる時間と労力。 Tableau：営業分析のための柔軟な強力ツール Tableauは、豊富な可視化表現と、Salesforceを含むさまざまなデータソースとの接続性に優れたBIツールです。ダッシュボードは視覚的に洗練されており、Salesforce画面内に埋め込むことも可能です。 出典： Tableau Insights Delivered Directly to Salesforce Tableauのダッシュボードとレポートは視覚的に魅力的で、Salesforceに埋め込むことができます。ただ、生データからダッシュボードを作成するには時間がかかります。 利用の流れ データ接続と抽出 Salesforce用の組み込みコネクタで、必要なオブジェクト（リード、取引先、担当者、商談、ToDo、活動など）を選択・接続します。オブジェクト間のリレーションは自動検出される場合もありますが、正確な分析のためには手動での確認・調整が望まれます。特にアクティビティログなどの大規模データは、抽出時のフィルタ設計が重要です。 データ準備（Tableau Prep/Desktop） Tableau Desktopでの結合やブレンド、あるいはTableau Prepでの変換・クリーニング処理によって、複雑なデータの整形が可能です。たとえばリードコンバージョン前の活動ログの分析には、時系列順や関連性の考慮が不可欠です。 ワークシートおよびダッシュボードの作成 ドラッグ＆ドロップで直感的にグラフを作成できますが、条件が複雑になると計算フィールドやLOD（詳細レベル表現）の活用が必要です。たとえば「特定業界×役職のToDoを持つリードの成約率分析」など、高度なセグメント分析には綿密なロジック設計が求められます。 ダッシュボードの公開と共有 完成したダッシュボードは、Tableau ServerやCloudを通じて社内の関係者と共有・展開できます。 Tableauは強力なデータ準備機能 を備えていますが、その効果を最大限に引き出すには高度な知識と一定の作業時間を要する場合があります。 ユーザーの使用感 使いやすさ 視覚的操作はわかりやすく、基本的な可視化はスムーズに行えます。ただし、Salesforce特有のデータ構造に基づいたマルチオブジェクト分析を行うには、結合・ブレンド・LODなどの高度な機能理解が必要です。 営業分析のスピード 接続・抽出から分析までには一定の準備時間がかかります。特にデータ量が多いSalesforce環境では、モデル設計やパフォーマンス調整に工夫が必要です。 作業負荷 オブジェクト間の関係性を正確に保ったデータ準備には、相応の時間と専門性が求められます。複雑な分析では計算式やフィールド設計の負担も大きくなります。 必要なスキル 高度な分析には、Tableauの中～上級スキルに加え、Salesforceのデータ構造への深い理解が必要です。 Tableauのまとめ メリット：豊富な可視化機能と柔軟なデータ接続。Salesforce以外のデータとも組み合わせやすい。 デメリット：Salesforceの複雑な構造に対するデータ準備には時間がかかり、パフォーマンス面での課題も。追加ライセンスや専用スキルが必要。 必要なもの：Tableauのデータ準備スキル、Salesforceの構造理解、設計・試行錯誤にかかる時間。 dotData InsightによるAIドリブンな営業分析 CRM AnalyticsやTableauは優れた営業分析ツールですが、リードから商談へのコンバージョンといったマルチオブジェクトにまたがる深いインサイトを得るには、データ準備やモデリング、分析に多くの手作業と専門知識を要するケースが少なくありません。 こうした課題を解決する新しいアプローチが、dotData InsightのようなAIドリブンな分析です。 まずは、dotData Insightを使ってSalesforceデータを迅速かつ効果的に分析する流れをハイライト動画でご覧ください。 作業の進め方 接続と選択 まずSalesforceに接続し、対象テーブル（今回はリード）とKPI（たとえば「isConverted = true」）を指定します。次に、AIに探索させたい関連オブジェクト（アカウント、コンタクト、商談、タスク、イベント、リード履歴など）を選びます。 dotDataのAIによる特徴量の自動抽出機能 ここからがdotData Insightの本領発揮です。従来のように手作業で結合や変換を定義する必要はありません。dotDataのAIが数千通りのパターンを高速かつ自動で探索し、「キャンペーンX経由で流入し、Z日以内にアクティビティYが発生した場合」や「業界Aのアカウントに、職種Bのコンタクトがいる場合」といった、成約率に影響を与える有意なルールを発見します。 ビジネスセグメントの分析 発見された特徴量は、「ビジネスセグメント」として自動的に整理され、ユーザーは数百の候補をレポート形式で確認できます。たとえば、「10〜12月にスケジュールされた会議があった」「リードソースがパートナー紹介」「最終コンタクトが成約の5日前」などの条件が、影響度と対象母集団の大きさとともに数値化されて表示されます。 ビジネスの仮説を構築 複数のセグメントを組み合わせることで、KPIに与える影響を具体的に可視化できます。日付や数値に関しては、AIが自動的に最適な閾値を提示します。たとえば「10〜12月にミーティングを実施した場合、コンバージョン率が上がる」という発見に対し、その範囲をそのまま使うことも、業務知識に基づいて調整することも可能です。dotData Insightは、以下のように複数の要因を積み重ねた影響もすぐに表示します。 要因1：「10〜12月にスケジュールされた会議」→ 成約率が8%から12%に上昇 要因2：「関心製品にXが含まれていない」→ 12% → 16%に上昇 要因3：「週末にディスクオリファイされた」→ 16% → 20%に上昇 これらは、過去のデータからdotDataが自動的に見つけた「コンバージョン率の高いセグメント」の具体例です。 ユーザーの使用感 使いやすさ dotData Insightは、高度な分析処理をすべてAIが自動で行うため、ユーザーはKPIと対象データを指定するだけで分析を始められます。パターンの確認やセグメントの組み合わせも直感的に操作でき、SQLやデータモデリングの知識は不要です。 営業分析のスピード 従来の手動分析に比べ、圧倒的に短時間でインサイトを得られます。複雑な準備や繰り返しの検証も不要で、オブジェクトをまたぐパターン探索が一気に加速します。 作業の負担 仮説を立てて検証する、という従来のプロセスから、AIが発見したインサイトを活用するスタイルに変わります。分析担当者は、検証よりも「どう活かすか」に集中できるようになります。 必要スキル プログラミングや統計の知識がなくても利用可能で、営業マネージャーや業務部門のユーザーにも親しみやすい設計です。統計解析はAIが担うため、ユーザーはビジネスの視点で操作するだけでOKです。 dotData Insightのまとめ メリット：マルチオブジェクトを横断したパターン探索や要因分析を、AIが短時間で自動化。手間のかかるデータ準備や仮説検証を省き、インサイトをすばやく提供。専門知識なしで高度な分析が可能。 デメリット：AIが発見したパターンの意味を読み解き、どう活用するかは、ユーザーのビジネス理解に委ねられます。また、dotData Insightは営業ダッシュボードではないため、CRM AnalyticsやTableauの代替ではなく、あくまで“補完・強化”する存在です。 必要なもの：KPIとSalesforceデータに対するビジネス的な理解、そしてAIが導く発見を活かす意欲と判断力。 リードコンバージョンを超えて広がるAIドリブン営業分析 dotData Insightのように、Salesforce全体にまたがる複雑なパターンをAIが自動で発見できる仕組みは、リードの分析だけでなく、あらゆる営業・顧客活動に応用可能です。たとえば以下のような活用が考えられます： 初年度解約の予測：アカウント属性やケース履歴、アクティビティの組み合わせから、離脱の兆候を早期に検出。 アップセル/クロスセル機会の特定：過去の成約パターンを学習し、製品ごとに反応しやすいアカウントや商談を抽出。 営業・マーケティング施策の最適化：キャンペーン参加と行動ログ、商談結果を一体で分析し、効果的な施策の条件を特定。 営業パフォーマンスとプロセスの効率化：タスクの連鎖やイベントの頻度、ステージごとの滞留時間と成果の相関を可視化し、ボトルネックを明らかに。 これらに共通するのは、あらかじめ用意されたダッシュボードでは捉えきれない、データそのものが持つ複雑な相関関係をAIが自動的に浮かび上がらせるという点です。そして、それらは最終的に収益成長や顧客体験の向上といった、より大きなビジネス成果へとつながります。 セールスデータを新しい視点で見てみませんか？ 膨大なデータの整理に時間を費やし、手探りでリードと成約の関係を探る作業はもう終わりにしましょう。AIを活用した営業分析で、Salesforceデータにある潜在的なニーズやインサイトを発見し、営業戦略の最適化を実現しましょう。 The post Salesforceダッシュボードだけでは見えないインサイト – 営業の成果をあげるデータ分析とは appeared first on dotData .

今日のビジネス環境は変化が激しく、競争力を維持するためにはデータ活用が不可欠となっています。しかし、「データ活用」と一口に言っても、実際に推進するには様々な課題が存在するのが現場の実情です。本ブログでは、なぜ今データ活用が重要なのか、その推進を支えるデータ基盤とは何か、そしてデータをより効果的に活用するためのデータモデリングについて解説します。 なぜ今、データ活用が重要なのか？ データ活用の重要性が高まっている背景には、大きく分けて ２つの時代の潮流 があります。１つは 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 .

生成AI（LLM） の急速な進化と普及は、私たちの働き方やサービス提供のあり方を大きく変えつつあります。日々の業務でLLMを活用することで生産性を向上させたり、LLMを組み込んだ革新的なサービスを提供したりするなど、「攻め」の姿勢でAIを活用する動きが加速しています。しかし、その利便性の裏側には、従来のシステムとは異なる新たなセキュリティリスクが潜んでおり、これらのリスクに適切に対応するための「守り」の戦略が不可欠となっています。 本ブログでは、LLMアプリケーションのセキュリティの難しさ、OWASP Top 10に見る具体的な脅威、そしてエンタープライズ向けに製品を提供するdotDataがどのようにこれらの課題に取り組んでいるのかをご紹介し、組織における生成AI活用の「攻め」と「守り」のバランスについて考察します。 生成 AI のセキュリティは何が難しいのか LLMのセキュリティを考える上で、まず理解すべきは従来のシステムとの構造的な違いです。従来のシステムは、入力、処理、出力という一連の流れの中で、処理部分（プログラムロジック）が固定されています。そのため、同じ入力値を与えれば必ず同じ出力値が得られるという前提でシステム設計やセキュリティ対策が行われてきました。システムに特定のインプットを与えて異なる結果が出力されれば、それは「バグ」と捉えられてきました。 一方、LLMはより人間らしい振る舞いをします。人間が同じ質問をされても、気分や状況、あるいは時間の経過による成長によって回答が変わる可能性があるのと同様に、LLMアプリケーションでは同じ入力を与えても出力が一概に一定になるとは限りません。これにより、特に入出力のコントロールが難しくなるという点が、生成AIにおけるセキュリティ対策の難しいポイントとなります。この入出力の制御の難しさが、従来のシステムにはなかった、あるいはより複雑になった脅威を生み出しています。 基本的な生成AIに対するセキュリティ対策は変わらない ただし、LLMアプリケーションのセキュリティ対策の基本的な部分は、従来のシステムと大きく変わるわけではありません。入力の制御、出力の制御、サプライチェーンリスクへの対応などは引き続き重要です。 出典： Top 10 for LLMs and Gen AI Apps 2023-24 入力の制御: 悪意のある入力が入ってこないように、可能な限りバリデーションを行います。また、そもそもアクセス権のない相手には触らせないように、ファイアウォールによる制御や、認証・認可によるアプリケーションレイヤーでの制御も有効です。 出力の制御: 機密情報や個人情報など、出力されては困る情報が漏洩しないように制御を行います。 サプライチェーンリスク: LLMアプリケーションを構築する際に利用するプラグインやライブラリの信頼性を確認し、脆弱性がないかどうかのチェックが必要です。 これらの基本的な対策に加え、前述の「入出力のコントロールの難しさ」に起因する新たな脅威への対策が必要となります。 LLMセキュリティの「教科書」：OWASP Top 10 for LLM Applications LLMセキュリティのリスクと対策を体系的に理解する上で、OWASP Top 10 for LLM Applicationsは非常に有効な「教科書」となります。これは、LLMアプリケーションにおける上位10個の脅威とその対策がまとめられたものです。 私たちが昨年のウェビナーで参照したものは2023年版でしたが、2025年版へのアップデートが2024年11月17日に行われています。名称も「OWASP Top 10 for LLM Applications 2025」に変更されました。約8割の項目は大きく変わっていませんが、新たに2つの脅威がランクインし、一部の脅威の名称や解釈も変更されています。 2025年版で新登場した脅威は以下の2つです。 第7位：システムプロンプトの流出 ユーザーがLLMに直接入力する「ユーザープロンプト」とは異なり、「システムプロンプト」はシステムがLLMに「このように振る舞ってほしい」というルールや指示を定義するために内部的に使用するものです。ここに認証情報や機密情報が書き込まれている場合、そのシステムプロンプトが流出すると情報漏洩のリスクが発生します。したがって、システムプロンプトを定義する際には、機密情報を記述しないように注意する必要があります。 第8位：ベクトル化と埋め込みの脆弱性 これは特にRAG（Retrieval-Augmented Generation）と呼ばれる、外部データソースを参照してLLMの回答を補強する仕組みに関連する脆弱性です。外部データソースに対してデータポイズニング（データの汚染）を行ったり、外部ソースを経由することで本来LLMから引き出すべきではない情報を引き出すようなプロンプトを組んだりする脅威が含まれます。 また、既存の脅威についても、名称や解釈の変更が見られます。 前回第2位だった「安全でない出力ハンドリング」は、今回 第5位「不適切な出力ハンドリング」 に、前回第3位だった「学習データの汚染」は、今回 第4位「データやモデルの汚染」 、前回第4位だった「モデルの可用性侵害攻撃」は、今回 第10位「再限のない消費」 に変更されています。これは、従来の可用性侵害（DoS）の観点だけでなく、モデルに対するDoS攻撃によってAPI利用料が高騰し、コスト増につながるという側面も含む表現となっています。 これらの変更は、この1年半ほどの間にLLMアプリケーションの実装が進む中で、より具体的で解像度の高い脅威が認識されるようになった結果と言えます。今後は、この2025年版のOWASP Top 10を参考に、LLMセキュリティのリスクと対策を検討していくのが良いでしょう。 LLMを取り巻く最近の動向：モデル進化と法規制 過去1年間には、主要なLLMモデルの進化（GPTシリーズ、Gemini、Claude、DeepSeekなど）が見られました。マルチモーダル対応（言語だけでなく画像や動画の処理）、推論能力の強化、用途に応じた軽量化や高速化、そしてコスト削減といった進展がありました。 このような進化の裏側で、セキュリティに関するインシデントも発生しています。やはり最も多く見られる脅威はプロンプトインジェクションによる脆弱性を突いたものです。Slack AIやMicrosoft 365 Copilotといった有名なサービスでも、情報漏洩につながるプロンプトインジェクションが検出されています。また、今年話題になったDeepSeekに関しては、登場して間もなく米国ユーザーのデータが中国に漏洩したというニュースがあり、DeepSeek=危険という印象付けがされたこともありました。 法規制の面でも動きが見られます。欧州ではAI法の成立・施行など、厳しく規制する方向に進んでいます。米国では、前政権の規制強化の流れを現政権が撤廃するなど、比較的緩やかな方向に向かっています。日本では、今年の2月に罰則のない法令が閣議決定されています。このように、各国で規制の方向性が異なっており、経済成長を期待する流れと、リスクに対応する流れが入り混じっているのが現状と言えます。 企業としてdotDataにおける生成AIセキュリティへの取り組み データを取り扱う製品をエンタープライズのお客様に多く提供しているdotDataとしては、お客様に安心して製品を利用していただくことが非常に重要です。そのため、技術面、組織面の両面から包括的なセキュリティ対策を行っています。SOC 2 Type 2認証取得などもその一環です。アカウント管理、端末管理、従業員へのセキュリティ研修なども基本的な対策として実施しています。 生成AI機能の開発においても、これらのセキュリティ対策は適用されます。dotDataでは、お客様が生成AIを積極的に活用したい場合も、非常に保守的に利用したい場合もあることを考慮しています。また、組織によっては生成AIの利用自体に制限があったり、利用して良いデータが決まっていたりする場合もあります。どれだけ利用部門が生成AI機能の導入を望んでも、組織全体のガバナンスやセキュリティポリシーに合致しない製品は導入できません。 このような背景から、dotDataでは生成AI機能のセキュリティ要件を策定し、製品の新バージョンをリリースする際に、これらの要件を満たしているかどうかの評価（アセスメント）を必ず行っています。 具体的な取り組みの例として、以下のようなものがあります。 生成AI機能のオプショナル化 生成AI機能は非常に便利ですが、dotData製品の機能は生成AIに完全に依存しているわけではありません。生成AIがなくても dotData の特徴量自動設計などの主要機能は利用できます。これにより、生成AIの利用に慎重なお客様でも製品をご利用いただけるようにしています。 徹底した情報開示 お客様が製品のリスクアセスメントを適切に行えるよう、どのようなデータがLLMに送られるのかを明確に開示しています。特に、ユーザーが自由にテキストを入力できる機能（例：AIとの対話機能）では、どのようなデータでも入力されうるため、お客様が最も懸念しやすい部分です。マニュアルなどで、機能ごとにどのようなデータがLLMに通信されるかを具体的に記載しています。 OWASP LLMガイドラインに基づくアセスメント OWASP Top 10 for LLM Applicationsなどのガイドラインを参照し、ユーザーとLLMアプリケーション、LLM（モデル）、そしてアプリケーションが扱うデータの間で発生しうるリスクに対して、どのような対策が講じられているかを具体的に評価しています。入力されるデータ、LLMに送られるデータ、出力される結果がアプリケーション内でどのように利用されるかなどを細かくチェックし、予期せぬ挙動が起きないかなどを検討しています。これらのアセスメント結果は、開発段階だけでなく、リリース前の承認プロセスで利用されています。 データプライバシーと接続方法への配慮 特に金融機関や政府機関など、データの活用に厳しい規制が存在するお客様の場合、データの国外転送やインターネット経由の通信が許可されないケースが多くあります。 国外データ送信の回避 例えば、OpenAIのような米国のサーバーでホスティングされているLLMモデルを直接利用する場合、お客様が入力したデータが米国に送信されてしまう可能性があります。これは日本の規制では問題となる場合があります。dotDataのSaaS版が日本国内でホストされていても、LLMへのリクエストが海外サーバーに向かえば同じ問題が発生します。この解決策の一つとして、AWS Bedrockのようなサービスを活用した閉域接続をサポートしています。 これにより、dotData製品（AWS東京リージョンでホスト）からAWS Bedrock（同じく東京リージョン）内のLLMモデル（Claudeなど）を利用する際に、通信がAWSのVPC内で完結し、データが国外に送信されることを回避できます。Bedrockを介することで、LLMモデル自体もAmazonのインフラ上でプライベートな通信で利用可能になります。 オンプレミス環境での対応 お客様のオンプレミス環境で生成AIを利用したいというニーズにも対応するため、dotData製品（ dotData Feature Factory など）では、VLLMのようなオープンソースソフトウェアと、LlamaやDeepSeekのようなオープンモデルを組み合わせて、オンプレミス環境内で推論を完結させる仕組みを提供しています。 この取り組みにより、外部のLLMサービスに接続できない環境でも生成AIを利用可能にしています。ただし、この場合でも、利用するモデルが汚染されていないかなど、OWASP Top 10の観点から考慮すべき点は存在します。 これらの対策や、安全な利用のための情報（製品マニュアルやデプロイメントガイドなどでの補足）を提供することで、お客様が安心してdotData製品の生成AI機能を利用できるよう配慮しています。 組織における生成AI活用の課題：スピードとセキュリティのバランス 組織内で生成AIツールを積極的に活用し、生産性向上を目指す上で、多くの企業が直面している課題があります。それは、新しいツールやモデルが日々登場し、進化していくスピードに対して、それらを評価・導入するためのセキュリティチェック体制が追いつかないという問題です。特に大規模な組織ほど、既存のソフトウェア導入フローに則ってセキュリティチェックを行う必要があり、これが数週間から数ヶ月かかる場合があります。このチェックがボトルネックとなり、新しい便利なツールを迅速に導入できない状況が生まれます。 もしチェック体制が弱ければ、リスクを十分に評価せずにツールを導入してしまい、情報漏洩などのインシデントにつながる可能性があります。逆に、全てを厳格にチェックしようとすると、ツールの導入が滞り、イノベーションの機会を失ってしまうことになります。これは、まさに「攻め」と「守り」のバランスをどのように取るかという課題です。 この課題に対し、dotDataを含む多くの企業が取り組んでいるのは、ツールの利用・導入フローを整理し、リスクに応じた段階的なアプローチを取ることです。 データの機密性に応じた利用レベルの設定 例えば、トライアル段階では機密性の低いデータのみを扱う、仮導入段階では一定のアセスメントを通過したデータのみを扱う、本格導入段階では完全に安全性が確認された上で、より機密性の高いデータも扱い得る、といったように、利用するデータの種類やリスクレベルに応じてツールの利用範囲や許可レベルを段階的に設けます。 扱う情報に応じた区別 開発におけるコード生成の例で言えば、誰が書いても似たようなコードになる「ボイラープレート的なコード」と、企業のコア資産となるような機密性の高いコードを分けて考え、生成AIへの入力可否を判断するといった方法が考えられます。 環境の分離 本番環境や本番データと、開発環境を明確に分離し、本番データが生成AIに安易に入力されないように制御します。 このような段階的かつ柔軟なアプローチを取ることで、完全に安全性が確認されるまで待つことなく、リスクをコントロールしながら新しいツールを試したり、限定的に導入したりすることが可能になります。これにより、セキュリティを維持しつつ、イノベーションの機会を最大限に活かすことを目指します。 攻めと守りのバランス、そして今後の課題 生成AIの活用は、生産性向上や新たなサービス創出といった「攻め」の機会をもたらします。しかし、その進化の速さや新しい脅威の出現は、常にセキュリティ上の「守り」を意識することを私たちに要求します。 Model Contamination Protocol (MCP) のような、LLMが外部リソース（プラグインやエディタなど）と連携する仕組みが登場する中で、これらの信頼性をどう評価するかが新たな課題となっています。これは従来のオープンソースライブラリの利用と似た側面もありますが、LLM自体の不確実性（例：「嘘をつく」可能性）が加わることで、評価はさらに複雑になります。生成AIが安全かどうかを生成AIに聞くといった状況に陥る可能性も指摘されています。 結局のところ、セキュリティリスクを完全にゼロにすることは不可能です。どこかでリスクを受け入れ、最低限のチェックを行った上で利用を判断する必要があります。クラウド移行期に設定ミスによる情報漏洩が増加したのと同様に、LLMにおいても、脆弱性を突いた攻撃や意図しない設定ミスによる情報漏洩が増加する可能性があります。 したがって、私たちは常に新しい脅威や対策に関する情報をキャッチアップし、変化に適応していく必要があります。組織における生成AI活用の成功は、この「攻め」と「守り」のバランスをいかに賢く取り、リスクと向き合っていくかにかかっていると言えるでしょう。 The post 生成AIセキュリティの最前線：LLM活用で考える「攻め」と「守り」のバランス appeared first on dotData .

2025年2月27日、dotDataと岡山大学、中国銀行は、ビジネスアナリティクス人材育成のための公開講座を実施しました。本講座は、岡山大学と中国銀行が2021年2月に締結した連携協定「おかやま未来共創アライアンス」に基づく取り組み及び内閣府「令和6年度地域中核大学イノベーション創出環境強化事業」の一環として実施されました。産学金の連携を通じて地域全体の課題解決と発展を目指すこのアライアンスにおいて、今回の講座は、次世代のデータ活用人材を育てる重要な試みとなりました。このブログでは、当日の様子や参加者の声をお届けします。 背景：地域共創とデータ活用人材の育成 近年、企業におけるDX（デジタルトランスフォーメーション）の推進が加速しており、データ活用は必要不可欠な要素となっています。中国銀行は、岡山大学との連携を通じて、産学金が連携し、地域全体の課題解決と持続可能な発展を目指す「岡山モデル」を掲げています。その中で、中国銀行で実績のあるdotDataのビジネスアナリティクス人材育成を、岡山大学と連携することで、地域におけるデータ活用人材の育成を広めるというビジョンに、岡山大学、中国銀行、dotDataが賛同し、本講座の実施に至りました。 公開講座の概要：座学ではなく実践的なデータ活用や最先端のAIを体験 本講座は、岡山県内の学生を対象に、統計やデータ分析の基礎的な知識ではなく、社会や企業で求められるビジネスアナリティクスや最先端のAIツールを用いた実践的な分析体験まで、幅広い内容で構成されました。 件名: 岡山大学向けビジネスアナリティクス人材育成公開講座 開催日時: 2025年2月27日 対象者: 岡山県内学生（岡山大学、岡山理科大学、岡山県立大学より参加） 本講座は、通常企業向けに3日間かけて実施するプログラムを、学生向けに1日に凝縮したものです。AIや分析に初めて触れる学生も多い中、短時間ながらもインタラクティブな演習やグループワークを取り入れることで、実践的かつ理解しやすい内容となるよう設計しました。 学生の高い意欲と積極的な姿勢が印象的 岡山大学では春休み期間中にも関わらず、データ活用への興味を持つ学生が自発的に集まり、公開講座が開催されました。普段触れる機会の少ないビジネスシーンでのデータ活用というテーマに対し、学生たちは高い熱意と真摯な姿勢で取り組んでいました。 グループワークやプレゼンテーションの場面で、参加者同士が活発に意見を交わしながら課題に取り組む様子です。専門的な知識がない中でも、実際のビジネスデータを分析し、自分たちなりの仮説を立てて発表する姿には、社会人に引けを取らないレベルの熱意と探究心が感じられました。 また、各グループで役割分担をしながら限られた時間の中で成果を出そうとする協働力も見られ、今後の成長が楽しみな学生たちの姿が印象的でした。 参加者の声：AIとデータ分析の新たな可能性に触れる 講座終了後のアンケートでは、多くの参加者が「期待以上だった」と回答しており、学びの深さと実践的な体験への満足感がうかがえました。 「グループワークでの作業や発表を通して、データ分析の醍醐味ともいえる様々な着眼点に気づかされた」 「AIを活用することで、複数のデータを効率的に分析できることに感動した」 「ビジネスアナリティクスの現状や考え方まで学べた」 「チームで協力しながら楽しくワークを進めることができた」 などの声が寄せられました。 また、「データ分析に自信がなかったが、ツールの直感的な操作性と講師の丁寧なサポートで理解しやすかった」という声や、「AIを用いた分析手法が、どのように意思決定につながるのかが実感できた」といった感想もあり、また、多くの学生が「本講座を他の人に推薦したい」と回答しており、「データ分析は今後のキャリアで非常に重要になる」という意見が多く見受けられ、データ活用の現場を体感する貴重な機会となったことが伝わってきます。 また、講座で使用した弊社のAIツール「dotData Insight」に対しても、 「簡単な操作で複雑な分析ができる点に驚いた」 「結果の解釈をサポートしてくれる機能が面白かった」 「大学の研究でも使ってみたいと思った」 といった声があり、分析スキルに関わらずデータから価値ある洞察を得られるツールとして評価をいただきました。将来的に、実務や研究活動の中でもAIを活用したデータ分析がより身近な存在になっていく可能性を強く感じさせる反応でした。 関係者からの声：今後の連携強化と地域貢献への期待 講座終了後には、岡山大学・中国銀行・dotDataの関係者間で意見交換が行われ、今回のような教育支援を継続的に展開していくことへの期待が高まりました。具体的には、データ活用人材の育成から地域社会での活躍促進、大学における継続的なデータ活用教育の提供など、今後の協力関係の発展に繋がる可能性について、前向きな意見交換が行われました。こうした取り組みを通じて、地域に根ざした形でのDX推進と、若い世代の成長機会の創出が両立できることが期待されます。 今後の展望：地域社会への貢献を目指して 今回の公開講座を通して、データ活用やAIに対する学生の関心の高さ、そして学びに向かう真摯な姿勢を強く感じることができました。dotDataは、今後も教育機関との連携を通じて、AI・データ分析技術の普及と人材育成に貢献してまいります。 地域社会の中で、実践的かつ意味のある学びの場を提供し、次世代を担う人材が自信を持って社会に羽ばたいていけるよう、継続的な取り組みを進めていきます。 終わりに 今回の講座にご協力いただきました岡山大学様、中国銀行様、そして参加者の皆様に、心より感謝申し上げます。今後もこうした産学連携の取り組みを通じて、データとAIの力で地域社会の発展に貢献してまいります。 The post 岡山大学でビジネスアナリティクス人材育成公開講座を実施！学生たちの高い関心と熱意のもと、実践的なデータ活用を体験 appeared first on dotData .

1. AIモデルの進化 近年、生成AIの進化は飛躍的に進んでおり、特に大規模言語モデル（LLM）の発展は目覚ましいものがあります。GPT-3が登場した2020年以降、AIモデルはより高精度で柔軟なテキスト生成を可能にする方向へと進化してきました。GPT-3.5、GPT-4といったOpenAIのモデルの発展に加え、AnthropicのClaudeシリーズ、MetaのLlamaシリーズ、Google DeepMindのGeminiシリーズなど、各社が競争を繰り広げています。 この進化の背景には、モデルサイズの増加や学習データの拡充、そして推論速度や効率性の向上が挙げられます。モデルサイズの増加によって高度な推論が可能になり、学習データの拡充によってAIの知識範囲や応答の精度が向上しました。また、推論速度の最適化には量子化技術の導入や並列処理が活用されており、特にFP8量子化やカスタムアクセラレータの利用によって、推論の実行速度とリソース消費の最適化が進んでいます。さらに、最新のモデルではテキストだけでなく、画像や音声も処理可能なマルチモーダル対応が強化され、より高度な情報処理が可能になっています。 近年は数多くのLLMが登場し、各社は技術的な特徴や独自の強みを前面に押し出しています。たとえば、精度の向上を重視するモデルや推論速度を最適化したモデル、コストパフォーマンスに優れたモデルなど、さまざまな用途に応じた選択肢が広がっています。しかし、選択肢が増えた一方で、ユーザーにとってどのモデルを採用すべきか判断が難しくなっているのも事実です。精度や速度、コスト、セキュリティ、運用の自由度など多岐にわたる要素を総合的に検討する必要があり、単純な比較だけでは決められないケースも増えています。 本ブログでは、 dotData Insight の開発において、OpenAIのGPT-4o、Amazon Bedrock上のClaude 3.5 Sonnet、そして自己ホスト型のLlama-3.1-70B-Instructを比較し、それぞれの精度、速度、コスト、セキュリティ、キャパシティの観点から評価した結果を解説します。 2. GPT-4o、Llama3.1、Claude 3.5 ここでは、各モデルの概要と、本評価における比較対象について説明します。 GPT-4o（OpenAI） OpenAIが提供するGPT-4oは、従来のGPT-4に比べて大幅に速度とコストの最適化が施されたモデルです。GPT-4oはマルチモーダル対応が強化されており、テキストに限らず画像や音声を処理する能力を備えています。モデルの訓練には膨大なデータが活用され、トークンごとの最適化が行われています。 API経由で利用できることから導入が容易であり、運用やメンテナンスの負担を大幅に軽減できる点が強みです。OpenAIのクラウドインフラを活用できるため、常に最新のモデルアップデートを受けられるほか、高水準のセキュリティ対策や負荷分散機能が提供されるため、ユーザーはインフラ管理の手間を最小限に抑えることができます。 Claude 3.5 Sonnet（Anthropic / Amazon Bedrock） Claude 3.5は、Anthropicが開発した大規模言語モデルで、安全性と倫理的なバイアス対策に重点を置いた設計が特徴です。長いコンテキストウィンドウをサポートしているため、大量の履歴を保持したまま推論を行うことができ、特に対話型アプリケーションとの相性が良いとされています。 Amazon Bedrock上で提供されているため、AWS環境との連携が容易です。これによりスケーラビリティやコスト管理がしやすくなる一方、API経由でしか利用できないため、リアルタイムの最適化や大規模カスタマイズには制限がある可能性があります。今回の評価では、Amazon Bedrockを通じてClaude 3.5 Sonnetを利用しました。 Llama-3.1-70B-Instruct（Meta / AWS上にホスティング） Llama-3.1-70B-Instructは、Metaが提供するオープンソースの大規模言語モデルであり、自己ホストが可能な点が大きな強みです。700億パラメータを有しており、特に指示応答（Instruct）タスクに最適化されています。FP8量子化に対応しているため、推論を高速化しつつ、メモリ使用量の削減も期待できます。 自己ホスト環境では、インフラの選定や推論エンジンの構成が重要になります。今回の評価では、Llama-3.1-70B-InstructをFP8量子化したモデルをg5.12xlargeで動作させ、推論エンジンとしてvLLMを採用することで高速化とメモリ効率の向上を図りました。 3. dotData Insightの生成AIによる特徴量の読み解き dotData Insightは、dotDataの独自のAIが、業務目的と強く相関する業務データの重要なパターン（特徴量）を抽出します。そして、データからわかる統計的な事実としての「特徴量」を、生成AIの知識で補完し、実用的なビジネス仮説の検討を支援します。この融合により、業務部門はデータの洞察を直感的に理解し、新しいビジネス仮説を立て、戦略立案や施策実行をより効果的に行うことができます。より具体的には、dotData Insightは、特徴量の説明文（dotDataのAIが自動生成）や特徴量・目的変数の分布に関する情報を生成AIのプロンプトの一部として入力し、特徴量の解釈やビジネス仮説立案を実行します。 消費者ローンに関するデータを使い、債務不履行の確率が高くなる顧客の特徴量をdotData Insightで分析した例を使い具体的に見ていきましょう。dotData Insightが発見した特徴量および、dotData Insightに組み込まれた生成AIによるビジネス仮説立案の例を以下に示します。 特徴量： 「直近3年間、申請対象が’モバイル機器’の過去ローン申込数が1件以上あるとローンの債務不履行率が1.1倍に上昇する」 解釈： 「携帯電話購入のための頻繁な借入」 ビジネス仮説： 「直近3年間で携帯電話購入のためのローン申込履歴がある顧客は、最新のスマートフォンを頻繁に購入する傾向があります。これは、必要以上の消費行動や衝動買いを示唆し、財務管理能力が低い可能性があります。結果として、複数のローンの返済負担が重なり、収入に対する債務比率が高くなることで、不履行のリスクが増加します。」 解釈を見ると、特徴量で言及されているモバイル機器は一般的には携帯電話のことを指しており、さらに申込数が１件以上とは、頻繁に借り入れを行っている顧客を指している、ということがわかります。つまり、この特徴量は、携帯電話購入のために頻繁に借入を行う人たちのことを指していると、よりイメージがつく解釈が得られます。また、携帯電話購入のための頻繁な借入が、なぜ債務不履行につながるかの仮説が、説明されています。頻繁な借入から、複数ローンの返済負担が重なり不履行となる具体的な仮説が示されており、対策を検討する上での有用性が高まります。 このように、dotData Insightでは、dotDataのAIの発見する特徴量と生成AIを掛け合わせることで、有用な仮説をユーザーに提供しますが、仮説生成の品質は生成AIの能力に大きく依存します。次章では、dotData Insightの開発の中で実施した、GPT-4o、Llama 3.1、Claude 3.5の比較について、具体的な評価結果を解説します。 4. 評価結果 評価の観点 GPT-4o、Llama 3.1、Claude 3.5の比較は、以下の観点から多面的に評価を実施しました。 精度：ビジネス仮説立案が、人間からみて妥当な結果と言えるか？（定性評価） 速度：推論にかかった時間 コスト：推論の実行にかかる費用 セキュリティ：閉塞網での利用や、日本リージョンでの利用の可否 キャパシティ：TokenやAPIアクセス数に対する制限 評価結果 精度 精度は、各LLMの回答を主観的に評価をしたため、まずは各LLMが生成した具体的な回答を見てみます。dotData Insightがデータから導き出した「住宅ローンの不履行率が高くなる条件：過去3年間に新規顧客が’true’である過去のローン申し込みがある」について、各LLMに仮説を立てさせた結果を以下に示します。 GPT-4oの回答：OK 「新規顧客は、金融機関に対して十分な信用履歴を持っていないことが多いため、信用リスクが高くなります。過去にローン申込がある場合でも、信用履歴が短いため、返済能力や信用度を正確に評価するのが難しく、不履行のリスクが高まります。」 Llama 3.1の回答：NG 「新規顧客が過去にローン申込をしていて、その申込が承認されたことがある場合、信用履歴が良くない可能性があります。このため、不履行のリスクが高くなります。過去のローン申込が承認されたことがある顧客は、将来も不履行する可能性が高いため、不履行率が高くなります。」 Claude 3.5の回答：OK 「直近3年間に新規顧客として過去ローン申込のレコードがある顧客は、比較的信用履歴が浅いと考えられます。信用履歴が短いため、返済能力や信用度の正確な評価が難しく、結果として不履行リスクが高くなります。長期的な返済実績がないため、予期せぬ経済的困難に直面した際の対応力も未知数であり、不履行率の上昇につながっています。」 GPT-4oとClaude 3.5は、ともに「新規顧客」という点を重視し、信用履歴の短さや評価の難しさを指摘しています。これは、金融機関が新規顧客のリスクを評価する際の一般的な考え方と一致しており、妥当なビジネス仮説と考えられます。一方で、Llama 3.1の回答は、GPT-4oやClaude 3.5とは異なり、過去のローン申し込みが承認されたことがある顧客は、将来も不履行する可能性が高いと述べています。この点は、一般的な考え方とは逆であり、違和感があります。 上記のようなビジネス仮説立案を10パターン実施し、違和感のあった回答数の比較を以下に示します。 GPT-4o Llama 3.1 Claude 3.5 違和感のある回答数 0/10 3/10 1/10 この結果から、精度の面ではGPT-4oとClaude 3.5が優位であることが伺えます。一方で、Llama3.1は、特徴量のビジネス解釈という本アプリケーションでは、他のLLMと比較して違和感のある回答が多い傾向にあります。 速度 1回のビジネス仮説立案生成にかかる時間の比較を以下に示します。 GPT-4o Llama 3.1 Claude 3.5 応答時間（秒） 1.9 6.6 5.8 3つのLLMの速度を比較した結果、GPT-4oが最も高速で、応答時間は1.9秒でした。Claude 3.5は5.8秒、Llama3.1は6.6秒でした。この結果から、GPT-4oは他の2つのモデルと比較して、応答速度において優位性があることがわかります。 コスト 10パターンのビジネス仮説立案生成にかかったコストの比較を以下に示します。 GPT-4o Llama 3.1 Claude 3.5 料金（ドル） 0.065　※1 0.15　※2 0.069　※1 ※1　GPT-4oはOpenAIの料金（ 参照元 ）、Claude 3.5はAWS Bedrock アジアパシフィック（東京）リージョンでの料金（ 参照元 ）で計算されています。 ※2　Llama 3.1は、AWSのアジアパシフィック（東京）リージョンで、 g5.12xlarge インスタンスを使い動作させた料金（ 参照元 ）で、vLLMの起動やモデルのロード時間を除き、純粋に推論のみにかかった時間での金額での算出です。 コストの観点から3つのLLMを比較した結果、GPT-4oとClaude 3.5が料金面で優位であることがわかります。GPT-4oは10リクエストあたり0.065ドル、Claude 3.5は0.069ドルで利用できます。一方、Llama 3.1は10リクエストあたり0.15ドルと、他の2つのモデルと比較してコストが高くなっています。 また、Llama 3.1は自己ホストで評価したため、インスタンスの稼働時間に対して料金が発生します。リクエストを処理していない時間も金額がかかり続けるため、ある程度以上のリクエスト数が見込めなければ、コスト効率がさらに悪くなる可能性があります。GPT-4oとClaude 3.5は、API経由での利用となるため、利用トークン数に応じた従量課金制です。そのため、Llama 3.1と比較して、無駄なコストが発生しにくく、コスト効率が良いと言えます。 セキュリティ 閉塞網での利用や、日本リージョンでの利用の可否の比較を以下に示します。 GPT-4o Llama 3.1 Claude 3.5 閉塞網での利用 不可 可 可 日本リージョンでの閉塞網での利用 不可 可 可 Llama 3.1は自己ホストが可能であるため、閉塞網での利用や日本リージョンでの利用が可能です。また、Claude 3.5はAWS内において日本リージョンを含め、閉塞網での利用が可能です。一方、OpenAIのGPT-4oは、インターネット経由のアクセスとなるため、閉塞網での利用ができません。（AzureOpenAIを使うことで、Azure内での閉塞網での利用が可能ですが、特に日本リージョンでは閉塞網での利用が現在できません。日本リージョンで利用可能なGPT-4oはグローバル標準モデルであるため、データが他のリージョンに転送される可能性があります。 参照元 ） キャパシティ TokenやAPIアクセス数に対する制限に関する比較を以下に示します。 GPT-4o Llama 3.1 Claude 3.5 1分間のリクエスト数 10K　※1 無し　※2 20　※3 1分間のトークン数 2M　※1 無し　※2 200K　※3 ※1　OpenAI tier4 organizationでの上限値。（ 参照元 ） ※2　自己ホストのため制限はありませんが、リクエスト数やトークン数が増えると応答時間が長くなるため、1台のマシンで処理できるリクエスト数には実質的に上限が存在します。dotData Insightのビジネス仮説立案は、同時3リクエストで応答時間が10秒を超えてきており、リアルタイム性を考慮すると同時3リクエスト程度がg5.12xlarge（1台）の実質的なキャパシティーと考えられます。 ※3　AWS Bedrock アジアパシフィック（東京）リージョンでの上限値。（ 参照元 ） キャパシティの観点から3つのLLMを比較した結果、GPT-4oは1分間のリクエスト数とトークン数において、Claude 3.5よりも大きなキャパシティを持つことがわかります。ただし、OpenAIは閉塞網で利用できないことに注意が必要です。一方、Claude 3.5は、日本を含め閉塞網で利用可能ですが、特に日本では1分間のリクエスト数が20、トークン数が200Kと上限が小さいことに注意が必要です。Llama 3.1は自己ホストのため、リクエスト数やトークン数に制限はありませんが、リクエスト数の増加に伴い応答時間が長くなるため実質的な上限は存在します。（※2参照） 5. 結論 現時点では、精度・速度・コスト・セキュリティ・キャパシティのいずれにおいても、単一のLLMがすべてを圧倒する状況には至っていないため、利用目的やビジネス要件に応じて複数のモデルを使い分けることが重要と考えられます。特に、金融や医療などの高度なセキュリティ要件が求められる分野では自己ホスト型のLLMを選択する価値が高い一方、短期的な開発スピードや柔軟性が必要とされる場合にはクラウドサービス型のLLMが有効です。 dotDataでも、各製品がOpenAIやBedrockなど複数のモデルを切り替えられるように整備しており、ユーザーが自社の要件に最適なLLMを選択できるようにし、高い精度を要する場合、コストを抑えたい場合、あるいはセキュアな閉塞網での利用が必須の場合など、多種多様なニーズに対応しています。今後は、モデル自体の性能向上だけでなく、リージョンやAPIアクセスの選択肢も増えていくことが予想されるため、最適なLLMを選択するプロセスはより複雑化していくかもしれません。しかし、その分だけビジネスでの活用可能性は広がると考えられ、AIの利活用が一層進む未来に備えて、継続的なモニタリングと評価を実施することが重要です。 The post AIモデルの比較評価 – GPT-4o, Llama 3.1, Claude 3.5 on Bedrock appeared first on dotData .

1. 企業におけるテキストデータの活用 企業が日々蓄積するデータの多くは、数値データだけでなく、メール、営業日報、コールセンターの記録、社内文書などのテキストデータが含まれます。。これらのデータは非構造化データと呼ばれ、構造が無いために分析しづらい一方で業務改善や意思決定に役立つ隠れたインサイトが含まれている可能性が高いです。。従来では、テキストマイニングツールを活用し、自然言語処理（NLP）技術によってテキストデータを解析する方法が採用されていましたが、以前のNLP技術を活用したテキストマイニングは主に単語や文の統計的性質に基づいて処理されることが多く、文脈の深い理解には限界がありました。 しかし、近年の生成AIの登場により、BERTやGPTといった高度なモデルがテキストの意味やコンテキストをより深く理解し、それに基づく分析が可能になっています。生成AIは、従来の自然言語処理技術では困難だった文脈の理解や、複雑な情報の抽出・整理を容易にすることで、企業のテキストデータ活用に新たな可能性をもたらしています。この進化により、テキストマイニングの手法も大きく変わり、単なる統計分析にとどまらず、より高度な洞察を得るためのツールへと発展しています。次世代のテキストマイニングを活用することで、従来技術では困難だった文脈の理解や、複雑な情報の抽出・整理を容易にし、企業のテキストデータ活用に新たな革新を生み出します。 本ブログでは、企業におけるテキストデータ活用の中でも、特にテキストデータの分析に焦点をあて、具体的な事例を紹介するとともに、従来の自然言語処理技術と生成AIを用いたテキスト分析との違いや、それぞれの利点・課題について掘り下げ、その実用性や使い分けのポイントについても詳しく解説します。 2. 活用事例 テキストデータの分析は、企業のさまざまな分野で活用され、業務改善や意思決定の質を向上させています。以下に、具体的な事例を紹介します。 2.1 営業日報による商談成否の要因分析 営業担当者が記録する営業日報には、商談の進捗状況や顧客の反応が詳細に書かれています。これらのテキストデータを分析することで、成功する商談の特徴や、失敗につながる要因を特定できます。例えば、特定のキーワード（価格交渉、競合比較、導入時の課題など）が頻出する商談の成約率を分析し、勝率の高い営業トークや顧客の関心ポイントを可視化することが可能です。また、特定の条件（業界、企業規模、意思決定プロセス）ごとに成功確率の高い営業戦略を導き出すことができます。 2.2 コールセンターのお客様の声分析による解約予兆の特定 コールセンターには、顧客からの問い合わせやクレームが日々蓄積されています。これらのデータをテキスト分析することで、顧客の不満や要望を抽出し、解約の予兆を特定することが可能です。例えば、解約に至った顧客が過去にどのような発言をしていたかを分析し、頻繁に登場するフレーズ（「使いづらい」「料金が高い」「サポートが遅い」など）を特定することで、早期にリスクを察知できます。センチメント分析や共起分析を用いることで、ネガティブな感情の強さや、解約を示唆する発言を分類し、適切なフォローアップ施策を講じることができます。 2.3 人事評価や社員アンケート分析による従業員エンゲージメントの向上 社員のモチベーションや職場環境の課題を把握するために、人事評価やアンケート結果の分析が重要視されています。従来、数値化された評価指標をもとに分析することが一般的でしたが、テキストデータの分析により、社員の自由記述から組織の課題をより深く理解できます。従来、テキストデータは定性データと呼ばれ数値化が困難でしたが、例えば、「上司との関係」「キャリア成長の機会」「ワークライフバランス」といったテーマごとに分類し、整理することで定量データとして扱い、エンゲージメント向上の阻害要因を特定できます。さらに、ネガティブなフィードバックがどの部署で多いのか、どの要素が離職リスクを高めるのかを分析することで、より戦略的な人事施策を打ち出すことが可能です。 2.4 IR資料のテキスト分析による投資家コミュニケーションの強化 企業が発表する決算報告書やIR向け資料には、投資家が企業の成長性やリスクを評価するための重要な情報が含まれています。定量データとこれらのテキストを分析することで、投資家の関心や反応を予測し、効果的なコミュニケーション戦略を構築できます。例えば、過去のIR資料と株価の変動を比較し、ポジティブな表現やネガティブな表現が投資家の意思決定にどのような影響を与えるかを分析することが可能です。また、競合企業のIR資料と比較し、自社のポジショニングを明確化することで、より説得力のある情報発信を行うことができます。 これらの事例から、テキストデータの分析が企業の課題解決や業務改善に大きく貢献することがわかります。2.1から2.4は活用事例の一部に過ぎず、テキストデータ分析の活用可能性はさらに幅広く存在します。例えば、製造業における品質管理のための作業報告分析、医療分野での電子カルテのテキスト分析による診断補助、法律分野での契約書や判例分析によるリスク評価など、業界ごとに多様な応用が考えられます。適切な分析手法を導入することで、より深い洞察を得て、戦略的な意思決定を支援することが可能です。 3. 自然言語処理に基づくテキスト分析の代表的な手法 N-gram N-gramは、テキストを連続するN個の単語や文字の単位に分割して分析する手法です。特に、単語やフレーズの頻出パターンを把握するのに役立ちます。例えば、顧客のレビューやコールセンターの会話データを分析し、頻出するフレーズを特定することで、特定の商品に関する評価傾向や問題点を抽出できます。N-gramの欠点として、単語の文脈を考慮しないため、長文の意味を正確に捉えることが難しい点が挙げられます。また、Nの値が小さすぎると文脈の理解が浅くなり、大きすぎるとデータスパースネス（データの不足）が発生しやすくなります。 トピックモデリング トピックモデリングは、大量のテキストデータやサイトから文書に潜むテーマ（トピック）を自動的に抽出する手法です。代表的なアルゴリズムとしてLDA（Latent Dirichlet Allocation）があり、異なる文書群の中で共通するトピックを分類するのに活用されます。例えば、社内の問い合わせ履歴を分析し、よくある質問のカテゴリーを特定することで、FAQの最適化に活用できます。トピックモデリングの欠点として、トピックの解釈が必ずしも直感的でない場合があることが挙げられます。また、教師なし学習であるため、結果の品質がアルゴリズムのパラメータ調整や前処理の精度に大きく依存します。 Word/Document Embedding Word/Document Embeddingは、単語や文書をベクトル形式に変換する技術で、文脈の類似性や関係性を数値的に表現することが可能です。代表的な手法にはWord2VecやBERTなどがあります。この技術を用いることで、例えば、求人情報と応募者の履歴書を比較し、適切なマッチングを自動化することができます。Word/Document Embeddingの欠点は、学習データに依存するため、ドメイン固有のデータに対しては適切な意味表現が得られない可能性があることです。 4. 生成AIによるテキスト意味特徴量の抽出 従来のNLPに基づいたテキスト解析の共通する短所として、単語の出現のような統計的な性質を分析しており、必ずしもその背後にある意味やコンテキストまでは理解できていない点が挙げられます。例えば、「製品A, 訪問」というN-gramを考えた場合に、「製品Aに関してお客様を訪問した」、「製品Aに関してお客様を訪問しようとしたが予定が合わなかった」は、全く意味が異なりますが、N-gram表現としては同じになってしまいます。結果として、テキストから抽出された特徴の解釈が難しくなり、元の文章を辿って確認をしないと、施策の立案や意思決定が難しくなるという課題があります。 そこで、当社dotDataでは、このような文章をAIに解釈させ、テキストに含まれる意味を抽出する、というアプローチを開発しています。例えば、営業日報のデータで成約率を分析するケースであれば、「営業とお客さんは面談できているか？」「お客さんに紹介している商品は何か？」という意味を特徴化することで、精度と解釈性の両面で、従来のテキスト特徴量よりもよい洞察が得られる可能性があります。 実際にどんな精度でこれが実現できるのか実例を見てみましょう。ここでは具体的なデータを用いたタスクとして、 大学に対する不満データ を使用して、述べられている不満が、 食事・カフェテリアに関する不満 オンライン授業に関する不満 学生課に関する不満 就職機会に関する不満 アクティビティ・イベントに関する不満 健康問題・福祉に関する不満 その他の不満 のどのカテゴリに属するかの分類を実施しました（生成AIが推定した不満の分類結果が、意味ラベルとして特徴化されます）。この評価では、ランダムに抽出した215件のテキストに対し、dotDataの生成AIによる意味抽出結果と、人間が分類した結果と比較しました（人間による分類を正解として、生成AIによる意味抽出結果を評価）。 最新の４つの生成AIモデルをdotDataのテキスト意味特徴ツールに接続した評価結果が以下の表となります。モデルにより若干の差はあるものの、ほぼ人間が分類したものと同じ分類ができていることがわかります（なお、Claude 3では、精度が70%程度と大きく劣化したため、最新のLLMの進化が伺えます）。 なお、誤分類のケースを見ると、 [誤分類例1] 文書：「キャンパスの自動販売機がよく故障していて不便です。」 人間による分類：「食事・カフェテリアに関する不満」 AIによる分類：「その他の不満」 [誤分類例2] 文書：「キャンパスの多様性をありがたく思っていますが、時々、異なる文化的グループの間に理解が欠けているように感じます。もっとお互いに交流し、学び合う機会が増えればいいのにと思います。」 人間による分類：「その他の不満」 AIによる分類：「アクティビティ・イベントに関する不満」 のように、人間でも完全な判断が難しいというケースが多いようです。 このように、生成AIを利用したテキストからの意味抽出は非常に強力なツールとなり得ますが、現状ではコスト面の課題があります。以下の表は、dotDataの意味特徴量の抽出ツールで、10万文書x1000文字のテキストに10種類の意味ラベルを付与する際にかかるコストを整理しました。 利用する生成AIによって10倍以上のコスト差があり、また10万文書に対するコストの絶対値として高いと見るか低いと見るかはアプリケーション次第ですが、無制限に使えるコスト感ではないため、目的をしっかりと定めて利用する必要がありそうです（なお、比較として、N-gram特徴などは、同規模のテキストデータであれば、無視できる程度のコストで実行することができるため、意味まで抽出可能な高精度な推論は魅力的である一方で、コストやスケーラビリティとしては従来の自然言語処理に基づく方法にも利点があります）。 dotDataの提供する、生成AIによる意味特徴抽出ツールは、単に生成AIによって意味ラベルを付与するだけではなく、企業での利用を想定して、以下のような機能が備わっています。 AIによる意味ラベルの推薦 ：テキストから抽出したい意味は、コンテキスト依存ですが、データセットを入力すると、テキストの内容から「どのような意味を抽出するとよいか」について、AIが自動的に分析して推薦してくれる機能です。これによって、ユーザーは、抽出すべき意味に素早くあたりをつけることができ、テキスト分析や、分析対象のデータに一定不慣れでも、簡単にテキストから意味を抽出することができます。 意味抽出精度の高速で低コストの評価 ：抽出可能な意味やその抽出精度は、ユーザーがプロンプトとして与える「意味の定義」の正確性に依存します。プロンプトを事前に正確に定義することは難しく、必然的に結果を見ながらのチューニングを伴いプロセスとなりますが、そこで生成AIのコスト（上述）が問題となります。dotDataの提供する、生成AIによる意味特徴抽出ツールは、全量データにプロンプトを適用する前に、低コストかつ高速に意味ラベルの精度評価をしながら、ユーザーがプロンプトをチューニングするための機能が備わっています。 dotDataの特徴量自動設計との連携 ：テキストからの意味特徴の抽出は、それ自体が有用な情報となりますが、それらの情報を加工することで、さらに深い洞察を抽出することができます。例えば、「1ヶ月間で、サービス品質に関する不満を３回以上、サポートに問い合わせたお客様は、その後３ヶ月以内に、サービスを退会する可能性が高まる」と言った形で、サポートのお問い合わせから「サービス品質に関する不満」という意味を抽出した上で、それをユーザーごとに１ヶ月間集計をした特徴は、解約の強い予兆となる特徴と言えます。 5. まとめ 本稿で紹介した従来の自然言語処理と生成AIを組み合わせたテキスト分析の事例から、今後は大規模言語モデルのさらなる性能向上や推論コストの最適化が見込まれ、企業が抱える膨大なテキストデータを深く分析するハードルは一層下がると考えられます。これにより、従来のNLP技術を補完しながら文脈や意味を考慮した高度な洞察を得る手法が定着し、企業におけるテキストデータの新たな活用方法が生まれるでしょう。企業としては、目的に応じた生成AI活用や、意味抽出の精度評価・運用ノウハウを蓄積することで、テキストデータの価値を最大限に引き出しながら、より的確な意思決定やイノベーションを推進できる未来が期待されます。 The post 生成AIによる企業におけるテキスト分析の進化と活用事例 appeared first on dotData .

1. データ分析のエージェントAI 「 生成AIとは？ – 生成AIは企業のデータ活用をどのように進化するのか？ 」で解説したように、生成AI（ジェネレーティブAI / 生成系AI）は、さまざまな業界で大きな変革をもたらしている。特に最近では、「エージェントAI（Agentic AI）」というキーワードが注目されており、これまで高度な専門教育を受けた人間の専門家しか実行できなかった業務を、AIが自律的に実行する世界が現実のものとなりつつある。例えば、顧客対応の自動化、財務データの異常検知、医療診断の補助など、さまざまな分野でエージェントAIの実用化が進んでいる。各企業はこの分野に注力しており、多くのキーワードやアーリーステージの関連サービスが登場している。 このトレンドは、企業のデータ活用においても例外ではない。生成AIとエージェントAIの発展により、これまで計算機科学（コンピューターサイエンス）の専門教育を受けたデータサイエンティストやデータアナリストが担っていた「データ分析」の業務が、エージェントAIによってコストの削減と自動化が進む可能性が高まっている。特に、BIツールとエージェントAIの融合が進むことで、より直感的な分析が可能になり、データ分析の障壁が大幅に下がると期待されている。 BIサービスの領域では、Amazon QuicksightのエージェントAIを活用することで、従来のBIツールよりも高度なデータ可視化やレポート作成が可能となり、データの活用方法が劇的に変わると考えられている。 本ブログでは、2024年12月のAWS re:Inventで発表されたAmazon Q in Quicksightのクイックレビューを行い、データ分析におけるエージェントAIの現状と今後の可能性について考察する。 2. Amazon Q in Quicksightとは？ Amazon Quicksightは、AWSが提供するBI（ビジネスインテリジェンス）ツールで、Amazon Q in Quicksightは、そのAmazon Quicksightに統合された生成AIベースのアシスタントである。Amazon Quicksight自体は、クラウドネイティブなBIツールとして知られており、企業のデータ可視化やレポート作成を支援するサービスだが、Amazon Qの導入により、従来のBIとは全く異なる体験を提供しようとしている。 Amazon Qは、ユーザーが自然言語で質問を入力することで、BIダッシュボードの作成やデータ分析を支援する。従来であればBIツールの活用において、SQLクエリの記述やデータモデルの理解が必要だったが、Amazon Qを利用することで、データを入力し、簡単な指示を与えるだけで、データの傾向分析や異常値の検出、基本的な要因分析などが自動で実行できるという点を特長としている。また、Amazonのクラウド技術であるAWSサービスを用いて大量のデータ処理を高速かつ効率的に行うことが可能になり、分析環境の最適化を図ることができる。 ユーザーの悩みの種となるBIツールの操作性においても、Amazon Qは直感的なUIを提供し、より多くのビジネスユーザーが活用しやすい設計になっている。 主な機能として、 自然言語クエリ : ユーザーが「今月の売上トレンドを教えて」と入力すると、自動的に関連するデータを抽出し、適切なグラフを作成する。 データインサイトの分析 : データセットを解析し、異常値の検出やトレンド分析を自動的に提示する。 ダッシュボードの作成支援 : 自然言語での指示に基づき、ユーザーが希望する視覚的なレポートを簡単に作成できる。さらに、Amazon Quicksightを利用することで、データソースの埋め込みを活用し、BIダッシュボードを外部ポータルサイトや社内システムに統合できる。 このように、Amazon Q in Quicksightは、ユーザーの意図を理解し、適切なデータ処理や視覚化を行うことで、BIの領域におけるエージェントAIの役割を果たしている。これにより、従来はデータアナリストやBIエンジニアが対応していたデータ分析の一部が、より幅広いビジネスユーザーにも開放されることになる。企業は、Amazon Qを活用することで、データドリブンな意思決定を加速させ、競争優位性を高めることが期待されている。Amazon Q in Quicksightの登場は、BIと生成AIの融合の一例として、今後のデータ分析のあり方を大きく変える可能性を秘めている。 次のセクションでは、実際にAmazon Q in Quicksightを試してみた結果を紹介する。 3. Amazon Q in Quicksightを触ってみた Amazon Q in Quicksightの基本的な使い方は、使いたいデータセット（テーブル）を指定した上で、データに関する質問をAmazon Qに対して問いかける。例えば、以下の例は、クーポン利用に関する３つのCSVファイル（Redemption.csv、Transaction.csv、Customer.csv）を指定し、「Low coupon redemption rate（クーポンの利用率が低い）」と指示を出すと、以下のスクリーンショットにあるように、クーポンの利用率が低い原因についての分析を自動的に実施する。注目すべきは、ユーザーが指示を出さなくても、Amazon Qがデータの読み込み、分析、可視化を自動で実行する点である。 また、必要に応じて、簡単なテーブルの結合を自動的に実施してくれる。以下は、クーポン利用に貢献している要因を問い合わせたところ、「Customer.csv」と「Redemption.csv」を自動的に結合し分析してくれた。結合自体は単なるIDマッチであるが、どのテーブルを組み合わせるべきか？をAmazon Qが自動的に検討している点が興味深い。 しかし、一部の分析結果については検証が必要なケースも多く、誤った解釈を提示する場合もある。例えば以下の例では銅の価格変動について分析をしようとしているが、「The data shows no instances of decreasing copper prices（データソースには銅の価格が下落しているケースが存在しない）」という誤った返答（実際にはCopper.csvが銅の価格変動のデータとなっており、このデータを分析することで、価格の下落要因を分析することができる）をしてしまっている。 また、以下のケースでは、従業員の基本情報（年齢、勤続年数、職種）と離職者のデータを入力して、離職要因の分析を実行しようとしたが、「We need additional information to fully address your request（要望された分析の実行には追加の情報が必要）」として分析が実行できない。このように、Amazon Q in Quicksightは、簡単な分析であっても分析に失敗してしまうケースもまだまだ多いようである。 Amazon Q in Quicksightを触っての総括としては、 データを入れるだけで非常に手軽に簡易分析や可視化を、ほぼ工数０で実施できる驚異的な手軽さは魅力。 高度なデータ加工や、データクレンジングなどを実施してくれるわけではないため、入力前に綺麗なデータを準備しておく必要がある。 現状では、分析の失敗や、分析自体の誤り（信頼性）の問題があり、データ分析に詳しくない業務部門が使うツールというよりは、データ分析に詳しい分析者の補助ツール。 現状はベータ版のためレイアウトの乱れや予期せぬエラーが多く、特定のデータセットでは期待した分析結果が得られない場合がある。特に、データの結合や前処理に関する機能が限定的であり、ユーザーが手動で調整する必要があるケースが多い。正式リリースに向けて、分析の精度向上やユーザーインターフェースを期待。 Amazon Q in Quicksight自体は、まだアーリーステージの試行段階という印象であり、特定のデータセットでは期待通りの分析ができないケースや、誤った解釈を提示する場面が見受けられる。特に、データの結合やクレンジング機能が限定的であり、分析の精度や一貫性の面で課題が残る。しかしながら、エージェントAIがデータ分析の在り方を大きく変える可能性を示している点は注目に値する。 4. データ分析におけるエージェントAIの可能性とdotData Insight 上記のクーポン利用率、銅の価格下落、従業員の離職の要因をデータから分析する場合には、一般的には以下のようなステップとなる。 業務課題を分析して、データを活用した課題解決の企画を実施する（ユースケースの分析） ユースケースに対して利用可能なデータ（テーブル）を検討し収集する データの品質や、複数のテーブル間の名寄せ問題など、データクレンジングやデータ加工を実施する ユースケースで必要な目的がデータ化されていない場合には、目的変数（或いは目的となるKPI）を作成する 要因の候補の仮説を検討し、データを加工してその仮説を説明変数（特徴量）として作成する 目的変数と説明変数（特徴量）の間の関係を可視化、統計分析し、要因候補を絞り込む 要因候補としての説明変数に対して、業務施策として活用する（例えば、クーポン利用率を高めるための施策を検討する）ために、業務観点での解釈を与える Amazon Q in Quicksightは、ステップ1から5のプロセスを外部で実施した後の、整備されたデータを入力として活用し、主にステップ6（＋簡易的なデータ加工）を自動で実施する役割を果たしていると言える。 dotData Insight は、生成AI時代のデータ分析プラットフォームとして、ユースケースの分析から、データクレンジング、特徴量の発見、業務施策の提案までを包括的に支援する。Amazon Qが既に整備されたデータを活用して簡易的な分析を行うのに対し、dotData Insightはデータクレンジングや特徴量の自動生成を含む高度なデータ処理を可能にする。これにより、データ分析のプロセス全体をAIが支援できる点が大きな特長となる（一方で、dotData Insightは、現状ではAmazon Q in Quicksightのような統合的な対話インターフェースは持っていない）。 ユースケースアドバイザー によって、AIがユースケースの分析や有効なデータの検討、目的変数の作成方法をアドバイスする（上記のステップ１、ステップ２、ステップ４） AIデータクレンジング によって、AIがデータの品質問題を自動検出し、解決方法を自動的に生成する（上記のステップ３） AIが複数のテーブルの複雑な関係性を網羅的に解析、加工を実施し、特徴量を自動的に発見する（上記のステップ５とステップ６） 統計的な事実としての特徴量に対して、生成AIがビジネス解釈を与え、業務を改善するための施策を提案する dotData Insightは、これらの非常に強力なAIの要素を統合的に活用し、データ分析を実施するエージェントAIとしての進化を目指していく。 The post Amazon QuickSight x 生成AI – Amazon Q in QuickSightを触ってみた appeared first on dotData .

導入 データ分析を前提としたデータ管理のアーキテクチャは、メダリオンアーキテクチャのような革新的なフレームワークへ進化しています。このアプローチは、データパイプラインの管理とデータガバナンスの強化に対する体系的な方法を提供します。このブログでは、メダリオンアーキテクチャのコンポーネントとして、特に、Databricks Delta Lake、Unity Catalog、およびdotData Feature Factoryに焦点を当て、企業におけるデータ利活用を圧倒的に加速する、最新のアーキテクチャを紹介します。 メダリオンアーキテクチャ、Databricks Delta Lake、Unity Catalogとは 引用： メダリオンアーキテクチャとは？Databricks メダリオンアーキテクチャは、データを論理的に整理するためのデータ設計パターンで、アーキテクチャの各層を通じてデータの構造と品質を段階的に向上させることを目的としています。レイクハウスに蓄積された未加工データを、それぞれ特定の機能を持つ3つの異なる層に分割する多層アプローチです： ブロンズレイヤー : この層は、データレイクへの生データ取り込みを担当し、さまざまなソースからデータを最も細かい粒度で蓄積、保存します。 シルバーレイヤー : この中間層では、データクレンジングと変換プロセスが行われ、一貫性と信頼性が確保されます。この層は、データを標準化することで、特定の目的に依存しない分析の基礎となるデータを蓄積、管理します。 ゴールドレイヤー : 最終層は、分析用に調整されたデータに焦点を当てています。シルバーのデータに対して、さらなる変換と集約を伴い、高度な分析、レポート、および機械学習アプリケーションなど、特定の目的に最適化された精緻なデータセットを作成します。 Delta Lakeは、ACID（原子性、一貫性、独立性、永続性）トランザクションを備えたストレージ層を提供することでメダリオンアーキテクチャをサポートします。また、スキーマの適用とタイムトラベルも提供するため、ユーザーは以前のバージョンのデータにアクセスして戻すことができます。これらの機能により、Delta Lakeは信頼性が高く効率的なメダリオンアーキテクチャの構築に不可欠な要素となります。 Unity Catalogは、一元化されたデータガバナンスとセキュリティを提供し、Delta Lakeを補完します。Unity Catalogは中央集権のガバナンスを提供し、データポリシーを管理および適用するための単一のコントロールプレーンとして機能します。また、きめ細かいアクセス制御も備えており、テーブル、行、および列レベルで詳細なアクセス制御を提供し、データの系統を追跡します。 Delta LakeとUnity Catalogを統合することで、組織はシームレスで安全かつガバナンスされたデータパイプラインを構築し、データのライフサイクル全体を通じてデータの品質と整合性を維持できます。一方で、DeltaとUnity Catalogは、メダリオンアーキテクチャのためのフレームワークであり、シルバーレイヤーのデータから、目的ごとにゴールドレイヤーのデータを作成するには「特徴量エンジニアリング」を実施する必要があります。 シルバーとゴールドの橋渡し：特徴量エンジニアリングとは メダリオンアーキテクチャからみた 特徴量エンジニアリング は、シルバーレイヤーからゴールドレイヤーへのデータ変換に相当します。シルバーデータから、分析やデータ活用の目的に応じた新しい特徴量を作成するプロセスです。このプロセスは複雑で時間がかかることが多く、高品質ですぐに分析できるゴールドレイヤーのデータを作成するための重要なステップです。 特徴量エンジニアリングの重要性とその難しさ 特徴量はモデル分析に使用される入力変数であり、特徴量エンジニアリングは、ドメイン知識を使用してデータから特徴量を作成するプロセスです。これらの特徴量には、機械学習による予測モデリングや、ビジネスインテリジェンスによるデータインサイトの発見などに役立つあらゆる属性やプロパティが含まれます。 特徴量エンジニアリングには、次のようなさまざまな課題があります。 欠損データ : 不完全なデータエントリ。欠損値を適切に処理しないと、分析結果に偏りがである可能性があります。 データスケーリング : 分析目的に合わせた形にデータを変換すること。数値の正規化やMin-Maxスケーリングなどが含まれます。 データリーケージ : 予測時には利用できない情報を特徴量に利用すること。目的変数や、未来のデータに関する情報が含まれるなどがあります。 カテゴリエンコーディング : 質的変数を分析しやすい量的変数に変換するために、カテゴリデータを数値形式に変換すること。 特徴量エンジニアリングの具体例 特徴量エンジニアリングの例として、scikit-learnのBike Sharing Demandデータセットを使用して、その重要性と影響を説明します。 例: 自転車シェアリングの需要データ Bike Sharing Demandデータセットには、気象条件やタイムスタンプに関する情報など、自転車レンタルに関するタイムスタンプ付きデータが含まれています。各時間帯にレンタルされる自転車の総数を予測すると仮定します。この例では、特徴量エンジニアリングを、特徴量抽出、特徴量変換、および特徴量選択に分けて説明します。以下の例は、データをより意味のある特徴量に変換し、機械学習モデルの予測力を向上させるプロセスで、メダリオンアーキテクチャにおけるシルバーレイヤーとゴールドレイヤーを繋ぐステップとなっています。 1. 特徴量抽出 特徴量抽出のステップでは、モデルの入力となる特徴量をデータから作成ます。時系列データの文脈では、タイムスタンプからデータの時間要素を抽出することを意味します。 この例では、datetime列から時間、曜日、月を抽出し、時間に関連するパターンを捉えるための新しい特徴量を作成しています。 2. 特徴量変換 特徴量変換は、既存の特徴量をさらに変換したり、または複数の特徴量を組み合わせたりして新しい特徴量を作成します。特徴量変換では、ドメイン知識に基づいて、データの挙動をうまく表現できる特徴量の変換規則を見つけ出すことがよく行わなれます。 この例では、時間データの周期性をよりよく捉えるために、「時間」のカラムから周期的な特徴量を作成しています。 3. 特徴量選択 特徴量選択は、目的と関連性の高い特徴量を選び、モデルをシンプルにし、かつ過学習を防止してパフォーマンスを向上させます。 この例では、目的変数「count」との相関が最も高い上位3つの特徴量を選択しています。 この例は、生データをより意味のある特徴量に変換し、機械学習モデルの予測力を向上させる方法を示しており、メダリオンアーキテクチャにおけるシルバーレイヤーとゴールドレイヤーの橋渡しを実現します。 dotData Feature Factoryによる特徴量自動設計 上記で述べた特徴量を作成における特徴量の加工に加えて、どのような特徴量を作成すべきかを知ること、つまり特徴量の発見や発想が課題として挙げられます。特徴量の発見は、ドメインに対する深い、或いは広い理解を必要とし、多くのケースでは、手作業による反復作業が必要となります。 dotDataのFeature Factory は、このプロセスを簡易化する新しいパラダイムを提供します。 dotData Feature Factoryは、異なるデータソースに対するデータセットの管理を簡素化し、アナリスト、 データサイエンティスト 、データエンジニアなど、さまざまな背景を持つユーザーの実施する、データ加工に関するワークフローを簡略化します。 dotData Feature Factoryは、結合、フィルタ、集約など、複数表の組み合わせを通じて特徴量発見プロセスを自動化し、大規模かつ複雑なデータに適用可能です。また、時間的結合を自動的に処理することでデータリーケージを防止し、広大な特徴量空間を効率的に管理します。このように、dotData Feature Factoryは、最適な特徴量を体系的に探索および選択するツールを提供し、ユーザーは特徴量の重要性と関連性に基づいて評価し、モデルを正確かつ容易に調整できます。 dotData Feature Factoryは、Widgetまたはプログラム上から、ユーザーが自身のニーズに合わせて柔軟に特徴量空間をカスタマイズできるように設計されています。これによって、ドメインに特有の要件にしたがう新しい特徴量を探索に含めることができます。dotData Feature Factoryで定義された、データ前処理から特徴量エンジニアリングまでの全ての処理は、「特徴量パイプライン」に変換されます。特徴量パイプラインは、効率と一貫性を重視して設計されており、機械学習モデルやその他のアプリケーションに直接統合することができます。 dotData Feature Factoryは、特徴量エンジニアリングの試行錯誤を再利用可能なアセットへと変換し、従来の手作業かつ属人性の高いプロセスから脱却します。これによって、特徴量エンジニアリングは、アドホックな使い捨ての作業ではなく、データドリブンな意思決定を強化するためのアセットを蓄積する重要なプロセスとなります。 要するに、Feature Factoryは特徴量発見と特徴量エンジニアリングのすべての課題を一挙に処理します。これは、入力されたデータから新しい特徴量を発見し、これらの特徴量を機械学習対応の特徴量テーブルに生成するアイデアエンジンです。独自のアルゴリズムにより、膨大な特徴空間から最適な特徴量を見つけ出し、ユーザーが数十万もの新しい特徴量を精査できるようにします。Feature Factoryは、Databricksを含むさまざまなプラットフォームと容易に統合できます。 Unity Catalogを使用したリネージ追跡 Unity Catalogのリネージ追跡機能は、Databricks環境内でのデータのライフサイクル全体を可視化します。この機能は、データの透明性を高め、データの問題を発見、修正し、データ使用状況を監査し、データパイプラインでエラーが生じた際に根本的な原因を分析することができます。 リネージ追跡の主な機能 透明性と可視性: データワークフローの透明性と可視性を提供し、データライフサイクル全体でデータの出所や変換過程を追跡します。これにより、データの信頼性と品質を確保し、データ活用の効果を最大化します。 デバッグとエラー解決: データパイプラインでエラーが発生した際に、ソースに遡って追跡し根本的な原因の分析に役立ちます。これにより、問題の発見と修正が迅速に行えます。 監査とコンプライアンス: データの使用状況や変換が詳細に記録され簡単に追跡できることで、内部監査はもちろん、GDPRやHIPPAのようなコンプライアンス規制に準拠することを保証します。 実践ガイド 以下に、Unity Catalogのリネージ追跡機能の活用方法を説明します。 データの書き込み: Unity Catalogにデータを書き込み、安全に保存および管理されていることを確認します。  dotDataによるデータ変換: dotDataを使用して変換を適用し、すぐに分析可能なデータセットへと強化します。  結果の読み書き: Unity Catalogから変換されたデータを読み取り、リネージ追跡を利用して各ステップを確認しながら結果を書き戻します。 ロバストで透明性の高いデータ管理システムを維持するために、Unity Catalogのリネージ追跡が実際にどのように適用されるのか、具体的な操作をご紹介します。 これらの手順に従うことで、Unity Catalogのリネージ追跡を利用して、ロバストで透明性の高いデータ管理システムを維持できます。データの読み取りから変換、そして書き込みまでの各操作が追跡されるため、データの流れが明確になり、データの整合性とコンプライアンスが確保されます。 詳細については、Unity Catalog とそのリネージ追跡機能に関する こちら のDatabricksの公式ドキュメントを参照してください。 Databricks Delta LakeとUnity Catalog にdotData Feature Factory を統合 Databricks Delta Lake と Unity Catalog に dotData Feature Factory を組み合わせることで、強力なシナジーが生まれます。 Delta Lakeは、ACIDトランザクション、スキーマの適用、およびタイムトラベルなどの機能を通じて、信頼性の高いデータストレージと一貫性のあるデータ処理を実現します。これらの機能は、データの整合性を維持し、バッチ処理とストリーミング処理をシームレスに行うことができます。 Unity Catalogは、詳細なアクセス制御でセキュリティとコンプライアンスを確保し、データリネージ追跡でデータの出所と変換過程を追跡します。また、データディスカバリー機能によりデータを簡単に検索・共有し、効率的なコラボレーションを促進します。 dotData Feature Factoryは、複雑で時間のかかる特徴量エンジニアリングのプロセスを自動化します。特徴量の作成、発見、管理を簡素化することで、データからすぐに分析できるデータセットへの移行を加速させます。 これらの技術を組み合わせることで、データライフサイクル全体を強化し、メダリオンアーキテクチャのシルバーレイヤーからゴールドレイヤーへの移行が飛躍的に効率化され、高品質で豊かなレイヤーを実装できます。 The post Databricks DeltaとUnity Catalogを超えて：dotDataのFeature Factoryによるメダリオンアーキテクチャの革新 appeared first on dotData .

DatabricksのFeature StoreとAutoMLの紹介 DatabricksのAutoMLと特徴量ストアとは、Databricksのエコシステムにおいて重要な組み合わせで、データサイエンスと機械学習の分野に革新をもたらします。このブログでは、これらのツールの基本を解説し、これらが機械学習モデルのトレーニングと管理を簡単にするだけでなく、効率的でスケーラブルにする方法を見ていきます。また、DatabricksとdotData Feature Factoryの統合について深く掘り下げ、そのメリットを理解し、データサイエンスプロジェクトで効果的に活用するための実践的なヒントとステップを紹介します。 Databricks Feature Storeとは何か Feature Store（特徴量ストア）は、複数のモデルにまたがる機械学習の特徴量の検出し、一元的に管理、共有するためのリポジトリを提供します。特徴量を簡単に保存、検索できる統一的なインタフェースを提供することで、データサイエンティストの特徴量エンジニアリングを効率化します。Databricks Feature Storeは、統合されたDatabricksのエコシステムの一部であり、DatabricksおよびdotDataを使用する際に、さまざまな利点をもたらします。Feature StoreはDatabricksの他のコンポーネントと完全に統合されているため、ツール間の連携がスムーズです。例えば、DatabricksのワークスペースからアクセスできるFeature StoreのUI（特徴量を管理するためのインターフェース）は直感的で、既存の特徴量をブラウズまたは検索できます。これにより、データサイエンティストは既存の特徴量を迅速に見つけて再利用でき、新たな特徴量の開発を効率化することができます。 また、モデルのスコアリングとサービングとも統合されていることもメリットの１つです。モデルのトレーニングに使用される特徴量がFeature Storeから選択されると、そのモデルは特徴量メタデータと関連付けられます。バッチスコアリングやオンライン推論の操作中に、Feature Storeから必要な特徴量を自動的に取得します。これにより、運用する側は特徴量について気にする必要はなく、簡単にモデルのデプロイや更新ができます。 さらに、Databricksは各特徴量の正確なリネージを保証します。このリネージ機能により、特徴量の元となるデータソースだけでなく、特徴量を使用する全てのモデル、ノートブック、ジョブ、エンドポイントにアクセスできるようになります。ユーザーが特徴量の依存関係やプロジェクトでの使用状況を確実に把握できるように、リネージによってデータの透明性を高めることができます。 Databricks AutoML（機械学習自動化）とは Databricks AutoMLは、モデル学習に直感的なアプローチを採用し、回帰、分類、予測など、それぞれの問題に合わせて多様な機械学習アルゴリズムに基づいてモデルを学習、評価します。これには決定木 、ロジスティック回帰 、アンサンブル学習などが含まれます。そして、モデルの評価では、再現率や平均二乗誤差（MSE）といったさまざまな評価指標が表示され、各モデルのパフォーマンスを比較できます。各モデルにはPythonノートブックが添付されています。そのため、どのようにモデルが学習され評価されたのかソースコードを確認することができ、機械学習プロセスを確認、再現、修正できることで、機械学習プロジェクトの透明性が高まります。さらに、データセットの全ての統計量サマリ は、後の詳細な分析のために保存されます。このように、複数のアルゴリズムでモデルを生成し、それぞれのパフォーマンスを比較でき、さらにモデル学習に利用したデータの特徴を視覚的に理解できるため、より信頼性の高い意思決定が可能となります。 Databricks AutoMLでは、データセット内の数値、二値、カテゴリ値の変数を処理することができます。Databricks AutoMLは柔軟なデータ分割オプション、たとえばランダム分割、時系列分割、手動分割などを提供し、分析の性質に応じて、データを学習用、評価用、テスト用に分割し適用することができます。また、大規模なデータセットに対しては、学習に必要なメモリを自動推定し、必要に応じてデータの整合性を損なうことなくサンプリングを行い、メモリ不足によるエラーを防止することができます。さらに、Databricks AutoMLは不均衡なデータセット（たとえば正例と負例の比率が1対99のようなデータ）に対して、主要クラスをダウンサンプルし重みを追加することで、不均衡なデータセットの問題を解決し、バランスの取れた学習とロバストなモデルを実現します。 特徴量エンジニアリングのための Apatch Spark SQLとSpark DataFramesの利用 特徴量エンジニアリングは機械学習パイプラインの重要なステップであり、モデルを構築するために、生データを前処理し学習に適した形式に変換するプロセスです。Databricksでは、Spark SQLとSpark DataFramesを使用することで、このプロセスを大幅に強化することができます。 Spark DataFramesはpandas DataFramesに似ていますが、分散処理を前提として設計されており、大規模データに対してより高いパフォーマンスを発揮します。また、データ操作、集約、変換のための関数を豊富に提供します。Spark DataFramesは、名前付きのカラムでまとめられるデータの分散型コレクション（データを分散して格納し、並行処理を行うことで大規模データセットを効率的に処理する仕組み）です。概念的にはリレーショナルデータベースにおけるテーブルや、RやPythonにおけるデータフレームと同じものですが、内部ではさまざまな最適化が行われています。Spark DataFramesは幅広いデータフォーマット（CSV、JSON、Parquetなど）やデータソース（構造化データファイル、Hiveテーブル、外部データベース、既存のRDDなど）をサポートしており、多様なデータセットに対応できます。このSpark DataFramesをDatabricks Feature Storeと組み合わせて利用することで、スケーラブルで効率的なデータ処理を可能にし、特徴量エンジニアリングのプロセスを迅速に進めることができます。  Spark SQLは、データを使用しSQLとして操作するための機能を提供し、Dataframeに展開されたデータに対して、データの操作や分析が直感的かつ効率的に行えます。Spark SQLは分散処理を利用して大規模なデータセットに対して高速にクエリを実行でき、データ分析や処理の効率を大幅に向上させます。Spark SQLをDatabricksに統合することで、使い慣れたSQL構文を使用して簡単に特徴量を作成できるようになり、生産性が向上します。また、さまざまなデータソースに簡単にアクセスでき、Spark SQLを使って一貫した方法でデータ操作ができるため、データ統合と管理が容易になります。 dotData Feature Factoryによる特徴量自動設計 特徴量の発見はデータサイエンスの重要な要素ですが、従来、ドメインの専門家の知識と、職人芸とも言える経験と勘による手作業と反復作業を必要としてきました。しかし、dotData Feature Factoryは、このプロセスを簡易化する新しいパラダイムを提供します。 dotData Feature Factoryについて dotData Feature Factoryは、異なるデータソース間に対するデータセットの管理を簡素化し、アナリスト、データサイエンティスト、データエンジニアなど、さまざまな背景を持つユーザーの実施するデータ加工に関するワークフローを簡略化します。このように、チーム間の連携を強化し、データを統合することで、大規模なデータもつ企業に対して、オープンでスケーラブルなデータソリューション開発を実現します。 dotData Feature Factoryは、結合、フィルタ、集約など、複数表の組み合わせ通じて特徴量発見プロセスを自動化し、大規模かつ複雑なデータに適用可能です。また、時間的結合を自動的に処理することでデータリーケージを防止し、広大な特徴量空間を効率的に管理します。このように、dotData Feature Factoryは、最適な特徴量を体系的に探索および選択するツールを提供し、ユーザーは特徴量を重要性と関連性に基づいて評価し、モデルを正確かつ容易に調整できます。 dotData Feature Factoryは、Widgetまたはプログラム上から、ユーザーが自身のニーズに合わせて柔軟に特徴量空間をカスタマイズできるように設計されています。これによって、ドメインに特有の要件にしたがう新しい特徴量を探索に含めることができます。dotData Feature Factoryで定義された、データ前処理から特徴量エンジニアリングまでの全ての処理は、「特徴量パイプライン」に変換されます。特徴量パイプラインは、効率と一貫性を重視して設計されており、機械学習モデルやその他のアプリケーションに直接統合することができます。 dotData Feature Factoryは、特徴量エンジニアリングの試行錯誤を再利用能なアセットへと変換し、従来の手作業かつ属人性の高いプロセスから脱却します。これによって、特徴量エンジニアリングは、アドホックな使い捨ての作業ではなく、データドリブンな意思決定を強化するためのアセットを蓄積する重要なプロセスとなります。dotData Feature Factoryは、Databricksを含むさまざまなプラットフォームと簡単に統合できるため、既存のワークフローにシームレスに適合し、データサイエンスチームが企業データを効果的に活用できるようにします。 Databricks Feature StoreとAutoMLにdotData Feature Factoryを統合 dotData Feature Factoryは、Databricks内のデータワークフローを自動化および最適化し、スケーラブルな機械学習モデルの構築とデプロイを簡素化します。dotData Feature FactoryをDatabricks Feature StoreとAutoMLと組み合わせてワークフローに組み込むことで、機械学習プロセスの自動化を強化し、高いスケーラビリティと効率性を実現します。 Databricks Feature StoreとdotData Feature Factoryを組み合わせることで、機械学習における特徴量の管理を目的とした、便利で効率的な特徴量ストアが実現します。dotData Feature Factoryで作成した特徴量テーブルは、Delta Lake上に構築されたDatabricks Feature Storeに格納できるので、高い信頼性とパフォーマンスの元、データを管理できます。これらのテーブルの作成はSpark DataFramesから行われ、Feature Storeに登録すると、ソース情報、変換用ノートブック、計算ジョブに関する情報を含むメタデータも更新されます。これにより、学習や推論ワークフロー全体での特徴量データの管理が非常に容易になります。 Databricks Feature StoreにはFeatureLookupという、機械学習モデルに必要な特徴量を特定のキーに基づき検索し、結合する機能があります。 この機能を利用することで、複数のdotDataの特徴量テーブルから必要な特徴量を検索し、データセットに結合できます。また、時系列データにも対応可能で、過去の取引履歴やセンサーデータなど、時間軸に沿ったデータを適切に結合し、時系列特徴量を生成することで、データリーケージを防止しながら学習用のデータセットやリアルタイム予測に必要なデータを効率的に取得できます。 例：Databricks Feature Storeを使用した特徴量の検索 このように、Databricks Feature Storeは、再利用可能な特徴量のデータセットを迅速に構築でき、データの一貫性が保たれるため、特徴量エンジニアリングを通じて発見されたデータを使用してモデルの学習、デプロイまで、機械学習のライフサイクルが効率化されます。詳しくは、「 Feature Storeとは 」を参照ください。 以下に、Databricks Feature Storeを使用して、特徴量テーブルを作成し、FeatureLookupを設定する例を示します。 dotDataとDatabricks AutoMLの統合による効率的な機械学習 複数の自動化ツールを統合することで、機械学習モデルの開発とデプロイプロセス全体を自動化することができます。この目的のため、dotData Feature FactoryをDatabricks AutoMLを組み合わせることで、特徴量エンジニアリング、特徴量選択、それに続くモデル選択、ハイパーパラメータ調整のプロセスを自動化します。 引用： AutoML Databricks この統合の概要： dotData Feature Factoryを活用することで、データサイエンティストは特徴量エンジニアリングを素早く正確に行うことができます。特徴量の抽出と検証を対話的に繰り返せることで、高次の特徴量を導き出すことができます。 dotDataが生成した特徴量テーブルをDatabricks内で利用することで、データの一貫性と再利用性が確保されます。これにより、特徴量エンジニアリングが効率化され、学習データの準備を迅速に行え、モデル開発のスピードが改善されます。  Databricks AutoMLは、モデルの学習と評価を自動化し、dotDataの特徴量を活用することで、より高品質なモデルを構築し、最も効果的なモデルを簡単かつ迅速に選択します。 Databricks AutoMLで生成されたモデルをMLflowにログ（記録）することで、モデルのトラッキングと管理が容易になります。これにより、モデルのバージョン管理や再現性が確保され、実験結果の共有と比較が効率的に行えます。 このように、dotData Feature FactoryとDatabricks AutoMLを統合することで、効率性、モデル精度、ロバスト性、スケーラビリティ、ガバナンスにおいて大きなメリットが得られます。 例：dotDataで生成した特徴量テーブルでAutoMLを実行 以下に、Databricks AutoMLを使用して、特徴量テーブルから分類モデルを学習し、予測を実施する例を示します。 まとめ dotData Feature FactoryをDatabricks AutoMLとFeature Storeに組み込むことで、機械学習パイプラインの効率が向上するだけでなく、複雑なモデル学習と特徴量エンジニアリングに簡単に対応できるようになります。このワークフローにより、プロセス全体にかかる時間を大幅に短縮できるだけなく、機械学習モデルの精度と信頼性が高まります。 DatabricksのAutoMLの詳細については、 Databricks AutoMLの公式ドキュメント を参照ください 。公式ドキュメントでは、Databricks AutoMLが、特徴量の前処理からハイパーパラメータ調整まで、機械学習のライフサイクルのさまざまな段階をどのように簡素化し、自動化するかについて説明しています。 Databricks Feature StoreとAutoMLをdotData Feature Factoryに統合することで、ワークフローの合理化が促進され、機械学習モデルのパフォーマンスが向上します。これらのツールを活用することで、これまでデータサイエンティストが手作業で行ってきた作業を最小限に抑え、モデルの精度を高め、最終的にデータソリューションを市場へ素早くリリースすることができます。 次回のブログでは、Databricks Delta Lake、Unity Catalog、そしてdotData Feature Factoryに重点を置き、企業におけるデータ活用を飛躍させる最新のアーキテクチャを紹介します。詳細につきましては、 こちら を参照してください。 The post Databricksの特徴量ストア（Feature Store）とAutoMLの力を最大限に活用 appeared first on dotData .

特徴量設計とは？ 例えば、機械学習や人工知能を応用した顧客の解約予測、製品需要予測、商品の売上予測など、ビジネス上の重要かつ複雑な問題に取り組んでいるとしましょう。機械学習による予測分析では、よりよい機械学習のアルゴリズムや手法を選ぶことが成功の鍵であると思われがちです。ロジスティック回帰、決定木、ブースティング、ニューラルネットワークなど、適切な機械学習のモデルを選び、予測精度と解釈性のトレードオフを考慮しながらモデルをチューニングする作業も、モデル開発にとって欠かせない工程です。一方で、Garbage-in, Garbage-out（ゴミを入力すると、ゴミが出力される）という有名な言葉の通り、機械学習モデルを訓練するための入力データの準備が、多くの場合、機械学習の成否を決めます。この、機械学習モデルを訓練するための入力データ（説明変数）の準備を、特徴量設計、或いは、特徴量エンジニアリング、といい、特徴量とは説明変数とほぼ同じ意味と考えることができます（現代機械学習における特徴量は、ディープラーニングに非構造化データからの特徴量を含み、古典統計における特徴量よりも広い意味で使われます）。 機械学習や統計の教科書では、目的変数（Y）と説明変数（X）があり、その関係性を統計的に学習或いはモデル化すると説明されています。また、説明変数Xに対して、例えば、 カテゴリ変数に対してワンホットエンコーディング を適用したり、数値変数に対する四則演算或いはlog変換を適用したり、或いは主成分分析のような多変量解析を利用して、Xから新しい変数を作成する工程が特徴量設計として説明されています。 この「説明変数（X）」は、どこからやってくるのでしょうか？実際の業務データは、顧客、製品、従業員などエンティティの異なるマスターテーブルや、履歴テーブルや時系列データのようなトランザクションなど、様々な形の異なるテーブルにデータが分かれて、データベースに蓄積されています。現実の機械学習プロジェクトにおける特徴量設計とは、このように業務のために蓄積されたローデータからドメイン知識に基づいて機械学習に入力できる説明変数（一枚表）を作成するプロセスです。目的変数（業務課題）に対して適切な特徴量を設計するためには、業務知見、データ加工、数学・統計など、さまざまなスキルが必要になります。特徴量を設計するためには、通常、SQLなどを駆使して多数のクエリを実装し、多くのデータ操作と変換を実行する必要があります。以下の模式図は、構造化データ（業務データの多くは、構造化されデータベースに蓄積されています）を特徴量に変換する様子を表しています。 なお、本ブログでは、特徴量エンジニアリングの中でも、複数のテーブルに分かれた業務データから機械学習の入力となる説明変数（特徴量）を見つけ出す工程に焦点をあて、特徴量選択には深く踏み込みません。特徴量の選択は多数の特徴量の候補がから、有効な特徴量を選択する重要な工程ですが、説明変数Xが準備されてから適用することができます（なお、dotDataの特徴量自動設計のように数百万もの特徴量を探索させる場合には、Xをメモリ上に展開することができないため、特殊な特徴量選択のテクニックが必要となります）。 特徴量設計の重要性 前節で説明したように、機械学習による予測モデルの品質や予測精度は、入力データとなる特徴量の品質に左右されます。例えば、顧客が短期間のうちにコールセンターに何度も問い合わせをしてきた場合には、顧客が何らかの不満やトラブルを抱えている可能性が高く、例えば「３日間のコールセンターへの問い合わせ回数」は、解約予測のための有効な特徴量となるかもしれません。或いは、小売り店舗にとって、「周辺2km以内で体育祭をやる学校があるかどうか」が、商品の需要予測精度向上に効く特徴量になるでしょう。 このように、特徴量設計は、予測精度を高めるための複雑な数学や統計的な変換を見つけ出す以上に、目的変数（ビジネスの課題）と関係性の深い意味のある「特徴」を見つけ出すことが重要です。一方で、そのような特徴量を見つけ出すためには、ドメインの知識（業務に関する知識や、ビジネス課題に対する経験と直感）、データの知識（データ項目の意味や、テーブル間の関係性）、統計・機械学習の知識（統計的な安定性や予測力）といった様々な知識が求められ、特徴量設計は機械学習モデルを開発するプロセスの中で、最も重要かつ最も難しい工程と言われています。データ加工、特徴量設計、機械学習と可視化という一連のプロセスの中で、機械学習は統計数理という業界非依存のスキルとして比較的身につけやすい一方で、データ加工や特徴量設計は、業界や業務、或いは個別企業に特有のデータやドメインの知識が求められるため、知識やノウハウの蓄積が非常に重要になります。 特徴量設計の代表的な手法 特徴量設計には、様々な手法がありますが、大きくは入力データのタイプによって分類することができます。 例えば、カテゴリ属性に対する最も一般的な特徴量設計の方法は、カテゴリ属性を数値表現に変換するというものです。これは、カテゴリ値を数値へとエンコード（符号化）し、これによって多くの機械学習アルゴリズムにとって扱いやすい新しい数値属性を生成します。基本的なワンホット・エンコーディングやラベル・エンコーディング、目的変数の情報を考慮したターゲット・エンコーディングなどが代表的です（各手法の詳細は、 カテゴリ属性に対する特徴量設計 を参照してください）。 時間情報に基づく特徴量も非常に重要かつ、特に時系列予測において、機械学習モデルの予測精度の向上に大きく寄与します。時系列データに対する特徴量には、ラグ特徴、時間間隔特徴、タイムスタンプと時間的イベント、フーリエ変換やウェーブレット変換などより高度な数学的変換に基づく特徴などが代表的です（各手法の詳細は、 時系列データの特徴量設計 – パート2 を参照してください）。 その他にも、 位置・空間情報に基づく特徴量 や、テキストや音声などの非構造化データからの特徴量など、データの性質や、ビジネスの課題（目的変数）によって、特徴量とは無限に可能性があり、特徴量設計は分析者のアイデアやスキルといった属人性が高くなりがちです。 業務データからの特徴量設計 前節で、いくつかのデータタイプに関する特徴量と特徴量設計について説明しましたが、このブログの冒頭で説明したように、現実のプロジェクトにおける特徴量設計の難しさは、多数の異なるテーブルから特徴量のアイデアを考え、そのデータを加工する複数表の取り扱いにあります（複数表からなる業務データからの特徴量設計については、 このブログでより詳細を解説 します） 例えば、クレジットカードの解約予測を考えてみます。解約者の情報、顧客マスター、支払い履歴という３つのテーブルがあったとします。この例では、例えば、顧客の職種という特徴は、顧客マスターと解約者テーブルを結合（join）すれば特徴量化することができますが、支払い履歴は一人の顧客が複数レコードを持つために、各顧客ごとにどの期間のデータを紐づけるのか？また複数のレコードをどのように集約して一つの特徴量とするのか？といった問題があります。さらに、男性の顧客に限定して支払い履歴を分析しようとすれば、顧客マスターと支払い履歴のテーブルの組み合わせを考えることが必要になります。 テーブル数が３つのケースであれば、まだ手作業による特徴量設計もできそうですが、現実の業務データはさらに多数のテーブルが、より複雑な関係性でつながっています。このような複雑なデータに対して、経験や直感、属人的なスキルによって特徴量を設計することは容易ではなく、経験豊富な専門家であっても、一つの機械学習プロジェクトに対して数週間から数ヶ月もの時間がかかる大きな要因となっています。 特徴量を自動的に抽出し、機械学習による高度な予測や、ビジネスの洞察を導き出す dotDataは、独自のAI（特徴量自動設計技術）の導き出す特徴量によって、全ての企業がデータに基づき、より良い製品やサービスを生み出すことができる世界を目指し、特徴量を自動的に抽出し、高度な予測分析やビジネスの洞察を導き出します。 特徴量設計の自動化は、従来のデータ分析や機械学習のプロセスを大きく変える可能性を秘めています。スキルの障壁を大幅に下げ、手作業による何百、何千ものSQLクエリ実装作業を排除し、完全なドメイン知識がなかったとしても、素早く分析プロジェクトを回すことができます。また、膨大な特徴の仮説をわずか数時間で探索し、これまで気づかなかったデータに隠された知見を発見し、データから得られるビジネスの洞察を強化します。 dotData Feature Factory は、特徴量エンジニアリングをデータ中心のアプローチへと進化させます。特徴量空間をプログラム的に定義することで、手作業では不可能な圧倒的に広い範囲の特徴量仮説を自動生成し、ユーザーのデータや業務に関する知識を再利用可能なプロセスとして分析データベースに記憶します。また、発見した新しい特徴量を、本番環境で利用可能な特徴量パイプラインを自動生成ます。 dotData Enterprise は、特徴量自動設計と機械学習自動化（AutoML）によって、AIの専門知識やコーディングなしで、業務データから特徴量の抽出、そして機械学習による予測モデルの構築まで、ワンストップでAIを開発することができます。 dotData Insight は、特徴量を、生成AIの「世界知識」で補完し、実用的なビジネス仮説を生み出す ビジネスアナリティクス のプラットフォームです。この融合により、業務部門は、データの洞察を直感的に理解し、新しいビジネス仮説を立て、戦略立案や施策実行をより効果的に行うことができます。 The post 解説：機械学習のための特徴量設計 appeared first on dotData .

生成AIは、さまざまな業界で大きな変革を起こし始めています。このブログシリーズは、企業におけるデータ活用の新しい地平を開く、生成AIの可能性について解説します。その第四弾となる本ブログでは、 生成AI の仕組みを解説し、生成AIを効果的に使う上で最も重要な技術である、プロンプトエンジアリングについて解説します。 生成AIの仕組みとプロンプト 生成AIは機械学習の技術を元に作られています。機械学習は、コーパスと呼ばれる入力と期待する出力のデータのペアを元に、入力と出力の関係をモデルとして学習し、入力のみが与えられた場合に、出力を返す、という技術です。この観点では、生成AIも機械学習の技術の1つと捉えられます。 しかし、従来のAIと、生成AIの大きな違いは、規模と汎用性にあります。従来のAIは、特定のタスク、例えば、機械翻訳、文書要約、画像認識といったタスクに特化されてきました。このため、タスクに特化したコーパスが用意され、学習したモデルはそのタスクでしか使用できません。これは、入力と出力の関係は非常に複雑で、その関係をモデル化するには各タスクに特化したアルゴリズムが必要であり、一つのモデルが複数のタスクをこなすことは難しいと考えられていたためです。 しかし、深層学習技術の発展と計算機の進化により、生成AIが登場しました。生成AIは、桁違いに大きいコーパスで、桁違いに大きいパラメタを持つニューラルネットワークを学習させたAIモデルです。例えば、OpenAIのGPT 4.0では、5000億から数兆のパラメタを持つ、と言われています。これにより汎用的な入力と出力の関係をモデル化できるようになり、タスクを定義するテキスト自体も入力に含めて処理できるようになりました。 生成AIは、大規模コーパスに含まれる知識が詰まった知識ベースとして考えることができます。これを活用するために重要になるのが、生成AIに与える「指示」です。　この「指示」は、プロンプトと呼ばれており、生成AIをうまく使うための重要なコンセプトになっています。 プロンプトエンジアリングとは？ プロンプトエンジニアリングとは、生成AIを効果的に活用するために、言語モデルへの命令（プロンプト）を最適に設計する技術で、学問分野としても認知されるようになってきています。例えば、ChatGPTへ効果的な命令（プロンプト）をすると質の良い対話ができるように、プロンプトは生成AIがどのような情報を出力するかを決定する重要な要素であり、正確で適切なプロンプトを設計することが重要であるとともに、few shot promptingのように具体的な例示をすることで、生成AIから狙った回答を引き出すことができます。 プロンプトエンジニアリングについては様々な情報が公開されていますが、ここではOpenAPIが公式に提供している プロンプトエンジニアリングのガイド で述べられている6つのポイントを紹介します。この文書は多様なユースケースを考え長い内容になっているため、本ブログでは、企業内のデータ分析のユースケースにおいて、具体例を交えてエッセンスを絞り紹介することで、データ分析の文脈で生成AIを効果的に使う方法をお伝えします。 プロンプトエンジニアリングの6つのガイドライン 1.明確な指示を書く 生成AIは人間と同じく指示が不十分だと期待しない結果を返すことがあります。また、データ活用のコンテキストでは、生成AIの出力を別のプログラムで処理したいことが多く、厳密に出力フォーマットを定義することが重要になります。「明確な指示」という言葉自体が曖昧ですので、ここでは自然言語で書かれたアンケートの集計を行う、というユースケースの例を見てみましょう。あなたは千件以上の自由記述アンケートのデータを持っています。これを目で読むのは大変なので、それを生成AIに集計させることにしました。 良いプロンプトの例： このプロンプトでは以下の点がポイントになっています。 背景も含めて説明する（1行目） 実現したいタスクを具体化し過不足なく記載する（2行目) 特にここでは集計の観点「待ち時間に対する不満」までを具体的に指示するようにしています。この場合、観点ごとにプロンプトを作る必要がありますが、こういった観点自体を生成AIに考えさせ、プロンプト自体を作成させる、という使い方も考えられます。 曖昧性が生じそうな部分には補足を与える(3行目) 区切り文字(“””)などで、データと指示を明示的に分ける(4行目、14行目) 出力フォーマットを例示する(最後の5行) 2.根拠を出すよう指示する 生成AIには、 ハルシネーション と呼ばれる問題があります。生成AI、事実とは異なるそれらしい回答を出すことがあります。嘘の無い結果を得るには、根拠を示すよう指示することが有効です。 先ほどと同じアンケートの集約の例では「各回答に「待ち時間に対する不満」が含まれるか否かを判定し、含まれるか否かをYesかNoで回答してください。 さらに、その不満を言及している箇所も出力してください。 」と指示することが有効です。 3.複雑なタスクをより単純なサブタスクに分割する 複雑なタスクを曖昧なまま与えると生成AIが誤った理解に基づき出力を出すため、期待と異なる結果を返す可能性が増えます。生成AIに実行させたいタスクがサブタスクに分割できる場合、ステップバイステップで指示を与えることが好ましいです。例えば、顧客との会議の書き起こしデータを要約させるユースケースを考えます。 悪いプロンプトの例： 良いプロンプトの例： 4.モデルによく考えさせる指示を与える 一般に、端的な指示を与えることは良いことですが、生成AIに端的な質問のみを与えると単純なつまらない回答を示す傾向があります。生成AIにより深い洞察を期待する際には、生成AIにどのような観点での洞察を求めるかを指示したり、出力の数を増やして指定することで、深く、幅広く考えさせることが重要です。深い洞察を期待するタスクの例として、データ分析で得られた情報の解釈を生成AIに手伝ってもらう、というユースケースを考えます。 悪いプロンプトの例： 良いプロンプトの例： 5.外部のツールを使用する 生成AIは汎用的なツールですが、他のツールを用いた方が効果的なシーンがたくさんあります。例えば、現状の生成AIに表構造のデータそのものを入力として与え、データ分析を行わせることは効果的ではありません。一つ上の解約分析の例では、「40代の女性の顧客は、一般の顧客に比べ、入会後3ヶ月に解約する確率が1.5倍以上である」という分析結果だけを生成AIに与えています。データ内から統計的なパターンを見つけ出す作業は、それに特化した別のツールで実施した方が、正確性やスケーラビリティなど、さまざまな観点でメリットがあります。このように、プログラムや他のツールで実施可能なところは他のツールで解消し、生成AIに与えるべきタスクをよく考えることが重要になります。 6.修正を体系的に評価する プロンプトのチューニングにおいては、プロンプトの修正を行った後その結果をきちんと評価し改善していくことが重要です。この際のポイントとなるのは、期待する結果の正解を用意しそれと比較して評価すること、そして、比較による評価指標を定義し、その指標に基づき各プロンプトの良さを定量的に評価することです。 例えば、一つ目の例で示した、自然言語で書かれたアンケートの集計を自動化するプロンプトの設計を考えてみましょう。 このタスクでは、各回答に「待ち時間に対する不満」が含まれるかどうかを判断するものでした。この場合、最初に少数のデータを人間が読み、正解の例を作ること、そして、このデータをテストデータとしてあるプロンプトで生成AIが出力した結果と比較し、何％の精度が出るかを確認することをお勧めします。 要約のような結果の正解判定が難しいようなケースでは、評価用のプロンプトで生成AIを使って評価することをお勧めします。例えば、会議書き起こしの要約タスクの例では、人間が作った要約と生成AIが作成した要約と比較するプロンプトを作り、その結果を元に生成AIで評価することが推奨されています。 要約結果を評価する指示の例： dotData Insight – 特徴量と生成AIが変革するビジネスアナリティクス dotDataでは、「データからの知識」である特徴量と、生成AIを融合した dotData Insight によって企業の ビジネスアナリティクス を推進しています。生成AIは、企業内のデータ活用において、データの加工・解釈を助ける重要なツールになりうる存在ですが、生成AIだけで全てが解決できるわけではありません。dotData Insightは、dotDataの独自のAIが、従来の手作業による分析では発見することができなかった、或いは、数週間から数ヶ月もの時間がかかっていた、複雑な業務データの重要なパターン（特徴量）を抽出し、そのパターンの解釈を生成AI、LLM（大規模言語モデル）が支援することで、データからの仮説立案や施策設計を支援します。 生成AIに関するブログシリーズ 生成AIブログ – パート1　： 生成AIとは？ – 生成AIは企業のデータ活用をどのように進化するのか？ 生成AIブログ – パート2　： LLMとは？ – 大規模言語モデルのデータアナリティクス応用 生成AIブログ – パート3　： 生成AIとLangChain 生成AIブログ – パート4　：生成AIの可能性を引き出す効果的なプロンプトエンジニアリングの方法　（このブログ） 生成AIに関するウェビナー 生成AIのセキュリティ 併せて読みたい： 生成AIによる業務効率化の方法9選を解説！メリットや導入方法も紹介 The post 生成AIの可能性を引き出す効果的なプロンプトエンジニアリングの方法 appeared first on dotData .

はじめに 生成AIは、さまざまな業界で大きな変革を起こし始めています。このブログシリーズは、企業における データ活用 の新しい地平を開く、 生成AI の可能性について解説します。その第三弾となる本ブログでは、テキストの生成AIである大規模言語モデル（LLM）を使ったアプリケーションの開発を効率化するフレームワークであるLangChainを紹介します。 現在、様々な大規模言語モデルが発表され、それぞれのモデルは急速な進化を続けています。新しいモデルが発表されるたびに各ベンチマークにおけるランキングは変わり、またドメイン特化型のモデルなども登場してきています。LLMを用いた分析ツールやアプリケーションの開発において、新しいモデルへの対応や、分析ドメインに応じたモデルの切り替えなどが非常に重要なってきており、LangChainを使用することで開発を非常に効率的に進めることが可能になります。 生成AIの種類と進化 ここでは特にテキストの生成AIである 大規模言語モデル（LLM）について 、その種類と進化について見ていきたいと思います。代表的なものでも、OpenAI社のChatGPT（チャットGPT）、Google社のGemini（ジェミニ）、Meta社のLlama（ラマ）、Anthropic社のClaude（クロード）といった様々なLLMあるいはLLMフレームワークが発表されています。また、日本語などのある特定の言語に特化したLLMや、医療などの特定のドメインに特化したLLMも出てきています。各LLMの評価には、様々な観点でのベンチマークがあり、例えば、言語理解テスト、テキスト推論テスト、数学テスト、コーディングテストなどにおけるスコアが比較されています。評価の観点によってどのLLMが良いかも変わり、さらに新しいLLMが登場するたびにそのランキングは常に変化しています。LLMアプリケーションを開発する際には、目的にあったベンチマークスコアや、実際に使ってみた応答を評価して、適したLLMを選ぶことが重要です。また、精度以外にも、暴力的、性差別的、人種差別的などの表現がないかといった倫理的な観点もあり、様々な視点で総合的に判断する必要があります。 これらの大規模言語モデルはここ数年で急速な進化を続けています。OpenAI社のGPTを例にその進化を見てみましょう。2018年に、OpenAI社は最初のGPTシリーズのモデルGPT-1を発表しました。トランスフォーマーと呼ばれる画期的な深層学習の手法を導入することで、当時のさまざまなベンチマークにおいて、最高レベルの性能を達成しました。2019年、2020年と、OpenAI社は、より多くの深層学習のパラメータ、学習データサイズを用いた新しいモデルGPT-2、GPT-3を発表しました。2022年、人間によるフィードバック技術によるさらなる回答性能の改善がおこなわれ、さらにチャットというインタフェースを持ったChatGPT3.5が登場しました。そして2023年には、テキストに加え画像データにも対応したGPT4が登場しました。GPT4は、米国司法試験で400点満点中298点という上位10%に含まれるスコアを出してことでも話題になりました。以上見てきたように、生成モデルの進化は非常に早く、毎年のように新しいモデルが発表されます。 大規模言語モデルにはさまざまな種類があり、目的に応じてどれが良いかが変わってくること、さらにそれらのモデルは毎年のように新しいモデルが発表されることを見てきました。最適なモデルを使い続けるには、こうしたモデルの変化に追従していくことが必要になります。 LangChainとは？ LangChainは、大規模言語モデルを活用したアプリケーションを開発するためのフレームワークです。前節で見たように、モデルの進化のスピードは速く、新しいモデルに素早く追従するのは容易ではありません。LangChainを用いることで、具体的なモデルを隠蔽した抽象レイヤーを用いてモデルを扱うことができ、複数の異なるモデルへの対応や、新しいモデルが出た時の対応も容易に行うことができます。それらのメリットに加え、LangChainを用いて大規模言語モデルを活用したアプリケーションを構築することで、開発者には以下のような様々なメリットがあります。 複数モデルへの対応、新しいモデルへの対応の容易化 LangChainを使うと、各具体的なモデルやその操り方を隠蔽した抽象レイヤーを用いて、アプリケーションを記述することができます。これにより、アプリケーションのロジックは、具体的なモデルには非依存になり、複数の異なるモデルへの対応や、新しいモデルへの対応が容易に行えることになります。 アプリケーション実装の効率化 LangChainのビルディングブロックやコンポーネントを組み合わせるだけでアプリケーションを構築することができます。また、典型的なアプリケーションのテンプレートが用意されているため、一からアプリケーションを書かなくても、必要な箇所を修正するだけでアプリケーションを実装することができます。 デバッグ、テストの効率化 LangChainの機能の1つであるLangSmithを使用すると、大規模言語モデルを利用したアプリケーションにおける、モデルの応答を容易に検査、監視、評価することができ、デバッグとテストを効率的に行うことができます。 デプロイの効率化 LangChainの機能の1つであるLangServeを使用すると、大規模言語モデルへの問い合わせを行うアプリケーションを、すぐにWebAPIに変換することができます。 LangChainは、アプリケーションと大規模言語モデルの間に抽象レイヤーを提供し、多モデル対応や新モデル対応を容易にするとともに、大規模言語モデルのアプリケーション開発における各工程の効率化に必要なさまざまな機能を提供していることがわかります。 LangChainってどのように動作するの？ LangChainの主要コンポーネントは以下の図に示されるように、レーヤの下からLangChain-Core、LangChain-Community、LangChain、Templates、LangServe、LangSmithの6つのコンポーネントに分かれています。 出典： LangChain Introduction LangChain-Core 基本的なコンポーネントの抽象化とLangChainの記述言語であるLangChain Expression Language (LCEL)を提供します。LCELを使うことで、基本的なコンポーネントを組み合わせ、複雑なチェーンを容易に構築することができるようになります。 以下では、基本的なコンポーネントとしてPrompt, ChatModel, Output Parserを組み合わせたサンプルプログラムを示します。Promptは”tell me a short joke about {topic}”（{topic}部分は変数で後に具体的な値に置き換えられる）、ChatModelはOpenAIのgpt-4、Output Parserは出力を単に文字列として解釈するStrOutputParserを用います。「|」記号はUnixのパイプ演算子に似ており、異なるコンポーネントを連結して、コンポーネントの出力を次のコンポーネントの入力として供給します。このchainでは、ユーザー入力がプロンプトテンプレートに渡され、次にプロンプトテンプレートの出力がモデルに渡され、その後モデルの出力が出力パーサーに渡されます。 出典： LangChain Get started : Basic example: prompt + model + output parser LCELを用いると、多段に言語モデルに問い合わせるような複雑なアプリケーションでも、簡潔に記述することができます。また、Prompt, ChatModel, Output Parserは様々なもの種類のものがあらかじめ準備されているため、コンポーネントを入れ替えたりすることも容易に行えます。 LangChain-Community サードパーティーのパッケージ(e.g., langchain-openai, langchain-anthropic, etc.)で構成され、各社固有のコンポーネント（ChatModelなど）を提供します。以下は、OpenAI社のgpt-3.5-turboとAnthropic社のclaude-3-opusのChatModelを作成するコードです。 chat1 = ChatOpenAI(model=”gpt-3.5-turbo-0125″) chat2 = ChatAnthropic(model_name=”claude-3-opus-20240229″) どちらのモデルも、BaseChatModelを継承しているため、共通のIFをつかってアクセスすることができます。 LangChain アプリケーションの認知アーキテクチャを補完するために、よりユースケースに特化したChain、Agent、検索メソッドを提供します。 Templates Templatesは、大規模言語モデルを使った典型的なアプリケーションのテンプレート集です。テンプレートを使うと、一からアプリケーションを書かなくても、必要な箇所を修正するだけでアプリケーションを実装することができます。最も人気のテンプレートとして、rag-conversationと呼ばれるテンプレートがあります。こちらは、社内データなどのWebにはない情報を知識ベースとして、大規模言語モデルによる問い合わせを実現するアプリケーションです。数行のコードを追加実装することで、ユーザ独自のデータを知識ベースとして、対話を行うアプリケーションを構築することができます。 利用可能なテンプレートの一覧は以下から確認することができます。 https://templates.langchain.com/ LangServe LangServeは、FastAPIをラップして、LangChainオブジェクトのためのエンドポイントを自動的に生成するライブラリです。これを用いることで、作成したchainを公開するためのWebAPIを即座に作ることができます。 LangSmith LangSmithは、大規模言語モデルを利用したアプリケーションのデバッグ、テスト、評価、およびモニタリングを行うことができるプラットフォームです。LangSmithのAPI_KEYやEndopointなどを設定して、LangChainを利用したアプリケーションを実行することで、モデルとのやりとりが記録され、LangSmithのウェブサービスから、モデルとのやりとりをモニターすることができます。LangSmithには以下の主な機能があります。 実行トレース 大規模言語モデルへの問い合わせ文や回答をウェブサービスから確認することができます。複雑なChainを持つアプリケーションでは、どの時点での回答が不具合の原因になったのかを容易に確認でき、デバッグが効率的に行えます。実行回数、レイテンシー、トークン使用量などのメトリクスも時系列グラフでモニターすることができます。 評価 データセットとして登録した入出力文に対して、複数の評価指標で品質スコアを自動的に算出することができます。有害性（harmfulness）、女性差別（misogyny）などのいくつかの観点についてはEvaluatorが定義されており、すぐに利用することができます。また、自分で独自のEvaluatorを定義することもできます。アプリケーションの運用ログを自動評価し、そのデータセットを使い、大規模言語モデルのファインチューニングや、Fewshotに加えることで回答品質を上げるといったLLMOpsのサイクルをLangSmithを用いて回すことができます。 プロンプトハブ プロンプトハブは、プロンプト登録することで他のユーザと共有することができます。公開されているプロンプトを検索し、Playgroundで実行して動作を容易に確認することができます。また、プロンプトはバージョン管理することができます。 LangChain利用時に注意すべきこと LangChainはv0.1.0で初の安定版がリリースされましたが、まだ開発の途上にあると言えます。開発初期のライブラリに注意すべき一般的な事として、API変更、ドキュメントの不足、セキュリティ、継続開発の不確実性、などが挙げられます。また、LangSmithを利用する場合には、LLMへの問い合わせ文が、LangSmithのウェブサービスに送信されるため、顧客のデータを扱う場合には、そのセキュリティ面での注意が必要となります。 dotData Insight – 特徴量と生成AIが変革するビジネスアナリティクス dotDataでは、「データからの知識」である特徴量と、生成AIを融合した dotData Insight によって企業の ビジネスアナリティクス を推進しています。dotDataの独自のAIが、従来の手作業による分析では発見することができなかった、或いは、数週間から数ヶ月もの時間がかかっていた、複雑な業務データの重要なパターン（特徴量）を抽出します。dotData Insightでは、特徴量（データからの知識）、ドメイン知識、世界知識を融合するために、様々なシーンでLLMを利用し、LangChainを利用して利用シーンに応じて適切な生成AIの切り替えをしています。これによって、dotData Insightは、最新のLLMを素早く取り込み、またユーザーが独自の知識を覚え込ませた生成AIを組み込むことを可能としています。 生成AIに関するブログシリーズ 生成AIブログ – パート1　： 生成AIとは？ – 生成AIは企業のデータ活用をどのように進化するのか？ 生成AIブログ – パート2　： LLMとは？ – 大規模言語モデルのデータアナリティクス応用 生成AIブログ – パート3　：生成AIとLangChain　（このブログ） 生成AIブログ – パート4 ： 生成AIの可能性を引き出す効果的なプロンプトエンジニアリングの方法 生成AIに関するウェビナー 生成AIのセキュリティ The post 生成AIとLangChain appeared first on dotData .