事業活動を AI Ready にする攻めと守りのデータエンジニアリング / data-engineering-for-ai-ready-business

Data Engineering Summit 2026（2026-10-09）で発表した資料です。

https://conference.findy-code.io/conferences/data-engineering-summit26/35/sessions/758

AI は誰でも使えるようになり、既存の業務に AI を当てるだけでは差になりません。差を生むのは、事業レベルのコンテキストです。

AIという道具を全員が使えるようになった今、既存業務にAI適用するだけでは顧客から見た差は生めません。本質的な差を生むのは、AIが価値を生む業務プロセスと基盤そのものを作れるかどうかです。CARTAではRevOpsとデータプラットフォームを、マスターデータから同時に作り直しています。価値を生み出す「攻め」の施策があるからこそ、ガバナンスを効かせる「守り」が活きる。市場で置いていかれない速度を出しながら「事業をAI Ready」にするために、何を描き、何を捨て、どう作っているかをお話しします。

Transcript

1. 事業活動を AI Ready にする 攻めと守りの データエンジニアリング 2026-10-09 / Data Engineering Summit 2026
2. は、 事業活動に何をもたらしたか？ AI
3. 履くだけで速く走れる靴が出た 俗にいう、スーパーシューズ
4. 全員が買って履いたら？
5. 全員が等しく速くなる 顧客から見た差は、消える
6. 使わない方が合理的？
7. 履くだけで、速くなる 使わないと、遅れる
8. 使っても、差はつかない 使わないと、置いていかれる
9. 私たちはいま、 そういうゲームをやっている
10. どこで差がつくのか？
11. 年前、同じことが起きた 100
12. 年代、工場に電気モーターが入った 1890 当時の工場は、1台の蒸気機関で 全部の機械を動かしていました。 機械は、その1台から 力が届く位置に並べていました。 そこに、電気モーターが登場しました。 多くの工場は、蒸気機関を モーターに取り替えただけでした。 Paul A. David, "The Dynamo and the Computer" (1990) https://www.almendron.com/tribuna/wp-content/uploads/2018/0 3/the-dynamo-and-the-computer-an-historical-perspective-on-th e-modern-productivity-paradox.pdf 天井の軸からベルトで機械を回す（1925年頃） https://commons.wikimedia.org/wiki/File:AHW_Kamm garnspinnerei_Pfaffendorf_Leipzig_um_1925.jpg
13. 動力源を取り替えただけでは、 生産性は伸びなかった
14. 生産性が伸びたのは、工場を組み直してから 最初は、多くの工場が蒸気機関をモーターに取り替えるだけでした。 それでは、生産性は伸びませんでした。 1920年代、機械ごとにモーターを付け、 工場を仕事の流れに沿って作り直したところから、生産性が伸びました。 米国製造業の生産性の伸び率は、前の10年より年 5 ポイント上がりました。 その半分は、機械ごとのモーターの普及と相関していました。 Paul A. David, "The Dynamo and the Computer" (1990) https://www.almendron.com/tribuna/wp-content/uploads/2018/03/the-dynamo-and-the-computer-an-historical-perspective -on-the-modern-productivity-paradox.pdf
15. AI は、電気モーターの登場に 似ている
16. 成果物を作るのが、 人から AI に替わる
17. いまの工程や仕組みは、 人が成果物を生成する前提
18. そこを何も変えずに、 AI を使っていないか？
19. これまでと同じやり方では、 活かしきれない
20. とはいえ、AI を前提に 変えるのは簡単じゃない
21. 今日は、そこに対して いまやっていることを話します
22. アジェンダ 自己紹介 2. 戦術 AI と戦略 AI 3. ひとつなぎにするために、やっていること 4. 今あるデータで、AI を試す 5. まとめ 1.
23. 自己紹介 近森 淳平 / pei0804 株式会社CARTA ZERO / Vice President of Data Snowflake Data Superheroes (2024-2026) X: @pei0804
24. アジェンダ 自己紹介 2. 戦術 AI と戦略 AI 3. ひとつなぎにするために、やっていること 4. 今あるデータで、AI を試す 5. まとめ 1.
25. まず、目線合わせ 具体の話に入る前に、 AI を事業にどう活かそうとしているかを、共有します。
26. いまの業務に AI を足しても、 優位性は生まれない
27. いまの工程のまま、各社が速くしたら？ AI 導入前 AI 社 B社 C社 導入後（全員が同じ AI を使う） 社 B社 C社 A AI A 社とC社の差 リードタイム → A 各社から見れば、リードタイムは短くなりました。 しかし各社を並べると、差は前と変わっていません。 汎用 AI を既存業務に当てると、これが起き得ます。 AI AI 差は変わらない リードタイム →
28. 使うことを強いられるだけで、優位にはならない 「同じ場所にとどまるだけで、全力で走り続けなければならない。 どこか別の場所に行きたいなら、その倍の速さで走らなければならない」 赤の女王（ルイス・キャロル『鏡の国のアリス』1871年） この構図は、赤の女王効果と呼ばれます。 全員が同じ AI を使うと、使うことは強いられます。 ですが、相対的な差は生まれません。走り続けて、やっと同じ場所です。
29. どうすればいいのか？
30. 考えた答えが、戦略 AI
31. 戦術 AI と戦略 AI 戦術 AI：個々の工程を速くする 工程A AI → 工程B AI → 工程C → 速くなるが、他社もすぐやれる 戦略 AI：工程そのものを AI 前提で組み直す 工程A AI → → 工程C → 業務が不可逆的に速くなる AI
32. にとっての、 戦略 とは？ CARTA ZERO AI
33. の ひとつなぎのデータプラットフォーム CARTA ZERO
34. ひとつなぎのデータプラットフォームのコンセプト ここを見れば、 データが分かる。人が分かる。組織が分かる。事業が分かる。 同じ言葉、同じ意味で話す環境を構築し、 人同士のコミュニケーションを圧倒的にスムーズにする。 そして、来る AI 時代に備える。 上記は、この構想を社内向けに打ち出したときの文章です（2025年7月）。
35. なぜ、これを作りたいのか？
36. CARTA ZERO は、6社が2回の統合でできた会社 どれも CARTA HOLDINGS のグループ会社。グループの中で統合しました。いまは 1,000 名を超える規模です 2023年10月 4社統合 Zucks ATRAC PORTO CARTA AGE 年 月 3社統合 → CARTA MARKETING FIRM 2025 7 CARTA MARKETING FIRM CARTA COMMUNICATIONS Barriz → CARTA ZERO 元の法人ごとに、言葉の定義も、数字の出し方も違います。 財務会計や管理会計のレベルでは、共通化しています。 ですが、業務やデータは、まだまだ分散したままです。
37. CARTA ZERO を、一枚岩にする いろんな事業会社が集まった結果、カバー範囲が広くなっています。 これを一つの会社として提供できる価値に変えられれば、 本当にすごいことです。 ですが、いまは足元に課題があります。 同じ言葉、同じ数字を見るだけでも難しいです。
38. データというハード層から揃える 人同士でも、同じ言葉で話すのは難しいです。 口伝で揃えていくには、限界があります。 だからこそ、データから揃えるというスケーラビリティを活用します。 そうすれば、AI 活用も自ずとできます。
39. 何がやりたいのか？
40. 最終的に目指すのは、 一体感と、組織としての再現性
41. 違いが出るのは、組織力 私は、一体感は信頼感になると考えています。 担当者が変わった途端に軸がブレる会社は、信頼できません。 私はこれまで、サービスの導入検討や他社との協業に関わってきました。 同じようなものが簡単に作れる中で、違いが出るのは組織力です。 組織力は、裏側で部門同士が連携できているかで決まります。 ここをやりきる。それだけで、競争優位になります。 ここを、AI とデータで作っていきたいです。
42. 軸がない多様性は、 ただのカオス
43. 軸がある多様性を、 構造的に作り出したい
44. それが、 ひとつなぎ（人繋ぎ）
45. 「この人がすごい」から、 「この組織はすごい」へ
46. アジェンダ 自己紹介 2. 戦術 AI と戦略 AI 3. ひとつなぎにするために、やっていること 4. 今あるデータで、AI を試す 5. まとめ 1.
47. ひとつなぎ？ せや、全部繋げよう
48. よくある罠は、 とりあえず全部繋げること
49. 無作為に繋げても、 そこまで価値は出ない
50. 繋ぐものを、事業戦略で絞る 事業戦略に効くシステムと文脈に、絞って繋ぎます。 例えば、繋げたあとにどういう質問をしたくなるかを洗い出します。 それが、繋がっていないと答えられない問いなのか。 出してみるだけでも分かります。 繋げることでメリットが出ると分かったからこそ、 CARTA ZERO は RevOps を採用しています。
51. では、 繋ぐだけでは足りなかった CARTA ZERO
52. CARTA ZERO の現在地 役割 数 SFA 2 ERP 3 MA 3 データ基盤 広告レポート基盤 3 5 会社統合を繰り返す中で、 同じ役割のシステムが乱立しています。 どれも似たデータですが、微妙に違います。 維持し続けると、 メンテナンスコストも認知コストも高く、 当然、AI も活用しにくくなります。 役割ごとに統廃合し、 業務の主語を揃える必要がありました。
53. という 文脈に合わせて、作り直す CARTA ZERO
54. 作り直しの方針 正本の所在を決める。横断する場合は SSoT で見る 2. 業務システムは、標準があるなら Fit to Standard 3. ハブ&スポークで、入れ替えられる構造にする 4. MDM で、文脈を揃える 5. 作るべきものだけ作り、あとは買う 1.
55. 方針 1 正本の所在を決める 横断する場合は SSoT で見る
56. なぜ、正本の所在を決めるのか データ管理コストの最小化 「どのデータをどこに持つか」の都度検討や、データ探索の手間をなくす。 システムの単一責任化 正本の所在を明確にし、各システムが自身の管轄データにのみ集中することで、 責務の肥大化を防ぐ。 ロジックの分散防止 正本システム以外でのデータ生成を禁止し、 データに関するロジックを1箇所に集約する。
57. 横断して見るのは、SSoT 当然、正本システムだけでは見られないデータがあります。 それは、SSoT である Snowflake で統合して見ます。 Snowflake を、全てのデータの合流地点にします。 ここに Agent とコンテキストさえ置けば、 全てが把握可能という構造を作ります。
58. 方針 2 業務システムは、 標準があるなら Fit to Standard
59. 例えば、Salesforce は、 Fit to Standard で作り直す
60. なぜ、Fit to Standard か？
61. 対極の Fit to Business には、 どういうリスクがあるか？
62. リスク1 スケールできなくなる Salesforce Fit to Business 商流 A ✓ 商流 B ✗ 商流 C ✗ 商流 D ✗ Salesforce Fit to Standard 商流 A ✓ 商流 B ✓ 商流 C ✓ 商流 D ✓ （ （ ） ） 作り込むと、その瞬間の CARTA ZERO には、ぴったり合います。 でも、事業や商流が変わると、陳腐化しやすいです。 会社統合をはじめ、過去に何度も大きな変化がありました。 作り込みによるペインを、我々はよく知っています。
63. リスク2 ベンダーの投資を受けられない 自社要件の全体 Salesforce Fit to Business （ ） Salesforce Fit to Standard （ ） 標準 カスタム 標準 カスタム ベンダーが投資するのは、標準の部分だけです。 カスタムした部分は、恩恵を受けられず、保守運用も自分たちで抱えます。
64. リスク3 AI 活用に乗れない Salesforce Fit to Business Uriage__c Uriage2__c UriageUnyo__c Salesforce Fit to Standard StageName Amount CloseDate （ （ ） ） ？ 商談の段階 ？ 商談の金額 ？ 完了予定日 商談（Opportunity）のような標準のオブジェクトとフィールドの意味は、 AI が最初から知っています。 カスタムフィールドは、AI は知りません。全部説明が要ります。
65. 方針 3 ハブ&スポークで、 入れ替えられる構造にする
66. 直接繋ぐのをやめ、Snowflake を経由する これまで：ポイントツーポイント これから：ハブ&スポーク MA MA Snowflake SFA ERP SFA これまでは、システム同士を直接繋いでいました。 これからは、各システムをハブの Snowflake にだけ繋ぎます。 ERP
67. なぜ、ハブ&スポークなのか 切り替え 新しい → 合わなくなった MA MA ⇄ SFA API 連携のやり直し 過去の変化の中で、いまとなっては合わなくなったシステムもありました。 しかし、システム同士が密に連携していたため、 簡単には切り替えられませんでした。 変化は、これからも起き続けます。 だから、変えやすい構造にしたいと考えました。
68. ハブ&スポークなら、1つだけ差し替えられる 差し替え 旧 MA 新しい MA → そのまま SFA → そのまま ERP → ハブ Snowflake 各システムは、ハブの Snowflake とだけ繋ぎます。 入れ替えるときに揃えるのは、データのインタフェースだけです。 他のシステムには、大きく手を入れずに済みます。
69. 方針 4 MDM で、文脈を揃える
70. システムを横断して文脈を揃えるために、MDM なし MA → SFA → ERP → MDM MDM 株式会社A (株)A A社 → 同じ取引先か、分からない あり MDM 取引先 001 株式会社A ↓ ↓ ↓ MA SFA ERP 取引先 001 取引先 001 取引先 001 → どのシステムでも、同じ取引先 （マスターデータ管理）は、業務の主語を1か所で管理する仕組みです。 システムがいくつに分かれても、文脈を揃えられます。 MDM
71. MDM は、最初から Snowflake Ready MDM Snowflake Postgres Iceberg テーブルとして参照 ハブ Snowflake アプリケーションのデータベースに、 を採用しています。 採用した理由は、Snowflake とのデータ連携を標準で備えていることです。 別途連携の仕組みを作らずに、すぐ Snowflake で活用できます。 Snowflake に入ったマスターデータは、ハブから各システムへ配られます。 MDM Snowflake Postgres
72. 方針 5 作るべきものだけ作り、 あとは買う
73. Build か、Buy か Build 競争優位につながる領域に絞って 自社開発します。 Buy 競争優位にならない領域は、 積極的に SaaS を活用します。 システムの統廃合にあたり、従来の内製システムもこの軸で見直しました。 差別化につながらない領域は内製をやめ、SaaS への移行を進めています。
74. これが、作り直しの全体像 正本の所在を決める。横断する場合は SSoT で見る 2. 業務システムは、標準があるなら Fit to Standard 3. ハブ&スポークで、入れ替えられる構造にする 4. MDM で、文脈を揃える 5. 作るべきものだけ作り、あとは買う CARTA ZERO は、いまここに取り組んでいます。 1.
75. 作り直すには、時間がかかる AI 活用は、いつから？
76. 作り直しと AI 活用は、 並行して進める
77. アジェンダ 自己紹介 2. 戦術 AI と戦略 AI 3. ひとつなぎにするために、やっていること 4. 今あるデータで、AI を試す 5. まとめ 1.
78. 作り直しが終わったとき、 もう AI がある状態にする
79. AI がどこに効くかは、 まだ分からない
80. 分からないから、 実際にある問題で試す
81. どういうところから、 試すのか？
82. どのユースケースから、始めるか 次の4つが揃っている業務から始めます。 1. ニーズ：その業務の成果を必要としている人がいるか 2. 要求定義：何を入れて、何を出すかを定義できるか 3. データ：業務に必要なデータはあるか 4. 正解の定義：出てきた結果が正しいかを判断できる人がいるか
83. まずは、質問に答えることから始めた データアナリストに調べてもらう ベテランに聞けば分かる ビジネスパーソン アナリスト ビジネスパーソン → AI → 1人 ビジネスパーソン 例：「このペースだと、A プロダクトは 目標を達成できそうか？」 ビジネスパーソン ビジネスパーソン → AI → ベテラン ビジネスパーソン 例：「取引先から聞かれた取り組みを、 過去にやったことはあるか？」 質問がアナリストやベテランに集まるのは、よくある課題です。 要求があり、正解もあり、データもあり、ニーズもあります。 だから、質問をまず AI が受けて答えるところから始めました。
84. やってみて、分かったこと 試して分かったことを、4つ紹介します。 1. 条件が揃っていそうでも、意外と難しい 2. エージェントなら、掛け合わせられる 3. 画面は不要。必要なのは、AI に開いたインタフェース 4. AI 活用は、組織の動きにした方がいい
85. 条件が揃っていそうでも、意外と難しい やってみると、やる前には見えていなかった判断ポイントが出てきます。 AI でやれる限界、人との境界、本当に必要なデータは何か。 これをスキルやデータに落とし込むのは大変です。 ですが、ここが肝です。
86. エージェントなら、掛け合わせられる これまで いま これから A A の専門家 B エージェント A×B ↓ B ↓ の専門家 → その人に聞けば、答えが返る エージェント → その人の答えを、一部代行できる エージェント → 社内に存在しないスキルセットになる の専門家も、B の専門家もいます。 でも、両方を知る人は、社内にいないこともあります。 A × B の答えが正しいか、一気に確かめにくくなります。 だからこそ、この先が面白い。 A
87. 画面は不要。必要なのは、AI に開いたインタフェース 実際の業務でエージェントを活用して見えたのは、 画面（GUI）ではなく AI に開かれたインタフェースの必要性。 ユーザーが真に求めているのは、操作画面ではなく「結果」です。 手元のエージェントやコンテキストから、 データやシステムへ直接アクセスする。 仕事の入口が AI に集約されるなら、個別システムの画面は不要になります。 そうなってくると、画面操作しか提供できない従来のシステムは、 AI と繋げないという理由で敬遠されます。 そういう世界観になってきていると感じています。
88. AI 活用は、組織の動きにした方がいい 活用は、横断的な活動にした方が効くところがあります。 だからこそ、オーナーシップが失われやすくなります。 体制を作って取り組めるなら、それがベストです。 もっと言うと、予算とスポンサーを確保して取り組む方がいいです。 AI
89. アジェンダ 自己紹介 2. 戦術 AI と戦略 AI 3. ひとつなぎにするために、やっていること 4. 今あるデータで、AI を試す 5. まとめ 1.
90. 差がつくのは、戦略 AI 戦術 AI 戦略 AI 工程A AI → 工程B AI → 工程C AI 工程A → いまの業務に AI を足すだけ → 差はつかない → 工程C 工程そのものを組み直す → 差がつく AI いまの業務に AI を足すだけの戦術 AI では、差はつきません。 差がつくのは、戦略 AI です。
91. 守りと攻めを着実にやり、現実の問題に AI を届ける 現実の問題 AI 攻め 活用層 守り データ基盤層 アナリストへの質問 ベテランへの質問 ↑ ↑ ひとつなぎのデータプラットフォーム AI さらなるユースケース ↑ 活用基盤 Semantic View ・ Cortex Agent データとコンテキストのインフラ SFA ・ MA ・ ERP ・ MDM 守りは、AI 時代に向けて、データとコンテキストのインフラを作ります。 攻めは、AI 活用基盤で、いまやれる場所から現実の問題に届かせます。 この2層が、ひとつなぎのデータプラットフォームです。
92. 人も、データも、AI も、 ひとつなぎにする
93. それをやりきった文化が、 競争優位になると信じている
94. 一緒に作る仲間を募集しています データ&AIマネジメントエンジニア マスターデータの定義・設計と、 データガバナンスの仕組みづくり。 https://hrmos.co/pages/cartaholdings/jobs/zero-e06 データ&AIプラットフォームエンジニア Snowflake を中核に、 データ基盤と AI 基盤をコードで設計・運用。 https://hrmos.co/pages/cartaholdings/jobs/zero-e07
95. ありがとうございました 今日はブースもあります。ぜひ、話しましょう。