ビジネスAIを動かす7つのデータタイプ
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Rachelのことを思い浮かべてください。彼女は65人規模のプロフェッショナルサービス会社を経営しています。ビジネスは堅調で、主にリファラルとリピート顧客から成り立っています。
しかし先月、Rachelの運営責任者が不都合な事実を持ち込みました。「AIツールを買い続けているのに、デモで約束された通りに機能するものが一つもない」と彼は言いました。
彼は最近購入した3つのツールを取り上げました。名前を正確に識別できず「Speaker 1」「Speaker 2」というラベルばかりが並ぶ文字起こしを生成するMeeting Intelligenceツール。すべての受信リードを10点満点中7点と評価するリードスコアリングモデル。2年前に提供をやめたサービスを引き続き引用するプロポーザル生成ツール。年間5万ドルのサブスクリプション費用。ほぼゼロの有用なアウトプット。
Rachelは当然の疑問を尋ねました：AIが悪いのか？運営責任者は首を振りました。「AIは問題ないと思う。データが問題だと思う。でも、それをどう証明し、どう修正するかわからない」
この記事はRachelのため、そしてAIの問題が実はデータの問題だと感じていながらも、まだその語彙を持っていないすべての創業者やオペレーターリーダーのためのものです。
データタイプが他のすべてより重要な理由
ビジネスAIのACEフレームワークでは、Dataはすべての5つの機能（Ingest、Analyze、Predict、Generate、Execute）の下、パターンの下、エージェントの下にあるFoundationレイヤーに位置します。これは謙遜からではありません。因果関係です。すべてのAI機能は原材料としてデータを必要とします。そのデータの品質、フォーマット、アクセシビリティを変えると、AIができることが変わります。
7つの標準的なデータタイプは、ビジネス内に情報が存在する異なるフォーマットを表します。それぞれは格納するための異なるインフラ、移動するための異なるパイプライン、処理するための異なるAIモデルを必要とします。これを理解することは学術的なことではありません。契約に署名する前にAIツールが実際に機能するかどうかを知るための最初の実践的なステップです。
これがその一覧です。リファレンスとして読んでください。その後、記事末尾のチェックリストを使って自社のスタックを監査してください。
1. テキスト
テキストはほぼすべてのビジネスで最も豊富なデータタイプであり、同時に最も構造化されていないため、AIにとって最大の機会であると同時に最大の課題の一つでもあります。
どこに存在するか：Gmail、Outlook、Slack、Microsoft Teams、Notion、Confluence、Salesforce CRMノート、Zendesk チケット、Google Docs、契約フォルダー、カスタマーレビュー、アンケート回答。
AIが得意とすること：意図検出（このメールは緊急かFYIか？）。要約（40件のメッセージスレッドを3つの箇条書きに凝縮する）。抽出（PDFからベンダー名、契約日、更新条項を取り出す）。分類（このサポートチケットを「請求」「バグ」「機能要望」にタグ付けする）。生成（会話全体のコンテキストに基づいてフォローアップを下書きする）。
よくある問題：互いに連携しない20のツールに分散している。スキーマがない（フリーテキストフィールドは担当者ごとに「次のステップ」の書き方が異なることを意味する）。業務データと混在する機密データがコンプライアンス上のリスクを生む。
正直な失敗モード：Rachelのプロポーザルツールが古いサービスを引用したのは、テキストコーパスに最新性の重み付けのない古いピッチデッキやメールスレッドが含まれていたからです。AIはすべてを平均化し、2019年のサービス説明を2026年のものと同等に扱いました。
2. 構造化データ
構造化データは明示的なフィールド名を持つ行と列に整理された情報です。AIが最も長く取り組んできたデータタイプであり、予測AI機能が最も大きく依存するデータタイプでもあります。
どこに存在するか：Salesforce、HubSpot、Pipedrive（CRMレコード）、Snowflake、BigQuery、Redshift（データウェアハウス）、Excel、Google Sheets、NetSuiteやSageのようなERP、フォーム送信、APIレスポンス。
AIが得意とすること：リードスコアリング（18のシグナルに基づいて73%のクローズ確率）。パイプライン予測（Q2のクローズド成約収益が380万〜440万ドル）。異常検出（この経費は平均の340%上回っている）。Churn予測。スケールでの分類とセグメンテーション。
よくある問題：古いレコード（4,000件のエントリに間違った役職と無効なメールアドレスが含まれる1万2,000件のCRMは、信頼できないスコアを生み出す）。欠落フィールド（クローズド成約レコードの60%に「ソース」フィールドがなければ、モデルはどのソースがコンバートするかを学習できない）。サイロ化されたシステム（NetSuiteのFinance、SalesforceのSales、GainsightのCustomer Successが統合なしに連携されていない）。
3. 画像
画像AIのビジネスユースケースはEコマースや製造業をはるかに超えています。スキャンした請求書から製品写真、ダッシュボードのスクリーンショットまで多岐にわたります。
どこに存在するか：ファイルストレージ（Google Drive、Dropbox、SharePoint）、顧客アップロードポータル、Eコマースカタログ（Shopify、WooCommerce）、マーケティングアセットライブラリ、製造品質管理システム、スキャン文書リポジトリ。
AIが得意とすること：OCR（スキャンしたテキストを機械読み取り可能な文字に変換する。請求書処理に不可欠）。視覚分類（製造ラインでの不良品と正常品の判別）。物体検出。KYCフローの身元確認。画像生成（製品ショットのバリエーション、マーケティングビジュアル）。
よくある問題：品質の不一致（クリーンなスタジオ写真でトレーニングされたモデルは、ぼやけた現場のアップロードで失敗する）。生成ツールからのIPと著作権リスク。顧客がアップロードした文書には多くの場合PIIが含まれており（パスポート番号、医療フォーム）、データが視覚的であってもガバナンス要件が適用されます。
4. 音声
音声データはB2Bで最も高ROIのAIユースケースの一つを可能にします：Meeting Intelligenceです。セールスコールやカスタマーサポートの会話が文字起こしされ分析できる瞬間、ビジネスはそれまで持っていなかったデータタイプを得ます——すべての口頭でのやり取りの検索可能な記録です。
どこに存在するか：Gong、Chorus、Fireflies（セールスコール録音プラットフォーム）、Zoomクラウド録音、Microsoft Teams、コールセンターシステム、ボイスメールテキスト変換サービス。
AIが得意とすること：文字起こし。センチメント分析（コール終了時に顧客は不満を感じていたか？）。トピック抽出（どんな異議が出たか？）。話者識別。コールスコアリング（担当者は十分な発見の質問をしたか？）。コンプライアンスモニタリング。
よくある問題：同意要件（全当事者の同意なしに録音することは米国の複数の州や多くの国で違法です。導入前に法的レビューが必須）。背景雑音と話者の重なりが文字起こし精度を低下させます。RachelのMeeting Intelligence失敗はその典型的な例です——文字起こしモデルは正常に機能していましたが、話者識別のステップがカレンダーやCRMの連絡先リストにアクセスできませんでした。パイプラインに接続が欠けていたのであり、AIが欠けていたわけではありません。
5. 動画
動画は音声に画像と時間を加えたものであり、最も豊かで最もコストがかかるデータタイプです。動画の処理には他のタイプよりも大幅に多くのコンピューティングが必要なため、ROIの閾値が高くなります。
どこに存在するか：YouTube（自社チャンネル）、Loom（非同期メッセージング）、Zoomクラウド録音、Vimeo（トレーニングコンテンツ）、セキュリティカメラシステム、製品デモライブラリ。
AIが得意とすること：文字起こし（動画には音声が含まれるため）。シーン理解。ハイライト抽出。チャプター生成。コンテンツモデレーション。動画生成（合成アバター、デモクリップ）。
よくある問題：ストレージコストが急速に増大します（1080p動画1時間分は2〜4GB。週200件の録画ミーティングはすぐに膨大な量になります）。長尺コンテンツの処理コストは相当なものです。同意と生体データの要件が適用されます。動画は顔を捉えるため、音声だけの場合を超えて、BIPA（イリノイ州）やGDPRのような法律に基づく義務が加わります。
6. コード
コードは形式的な構文を持つ構造化テキストですが、自然言語とは異なる動作をするため独自のカテゴリを持ちます。コード向けに作られたAI（GitHub Copilot、Amazon Q Developer、Cursor）は、散文に微調整されたのではなく、その構文パターンのために専用に構築されています。
どこに存在するか：GitHub、GitLab、Bitbucket（リポジトリ）、CI/CDシステム（Jenkins、GitHub Actions）、ログアグリゲーター（Datadog、Splunk、Sumo Logic）、Infrastructure as Codeファイル（Terraform、Ansible）。
AIが得意とすること：コード生成。コードレビュー（セキュリティ脆弱性、スタイル違反、パフォーマンス問題のフラグ）。ドキュメント作成。エラーログからのデバッグ。リファクタリング。脆弱性スキャン（ハードコードされた認証情報を検出）。ログ分析。
よくある問題：コンテキストウィンドウの制限（AIは単一ファイルについてはうまく推論できますが、50万行のモノリポジトリ全体では苦労します。CursorなどのツールはRetrievalストラテジーでこれを処理します）。リポジトリ内のシークレット（コードにコミットされたAPIキーと認証情報は、AIアシスタントに接続すると攻撃対象領域を大幅に拡大します）。意図の欠如（AIはコードが何をするかは読めますが、なぜそうするのかは通常読めません——ドキュメントとコメントが橋渡しをします）。
7. 時系列データ
時系列データは定期的な間隔で記録された測定値——午前9時、9時1分、9時2分のメトリクスです。オペレーション、財務、インフラモニタリングのネイティブ言語であり、他のデータタイプでは代替できない予測と異常検出を可能にします。
どこに存在するか：モニタリングツール（Datadog、New Relic、Prometheus）、IoTセンサーシステム、財務システム（日次収益、経費、ヘッドカウント）、ウェブサイト分析（Google Analytics、Mixpanel、Amplitude）、POSシステム（時間帯・曜日別の取引量）。
AIが得意とすること：予測（来月の収益、来四半期のChurn率）。異常検出（このメトリクスはローリング基準値から3.4標準偏差外れている）。トレンド分析（サポート量が収益よりも早く増加している）。季節性モデリング。
よくある問題：クロックドリフトとタイムスタンプの欠損が、時系列モデルが前提とする規則的な間隔を壊します。サンプリング粒度の混在（1つのシステムが毎分ログを取り、別のシステムが毎時ログを取る）は信頼性のないベースラインを生み出します。不十分な履歴が最も一般的なギャップです——3ヶ月のデータでトレーニングされた予測モデルは年間パターンを確実に予測できません。経験則として、モデル化しようとしているパターンの完全なサイクルを2〜3周分のデータが必要です。
データタイプが実際のユースケースで組み合わさる方法
ほとんどのビジネスAIユースケースは2〜3つのデータタイプにまたがります。組み合わせを理解することで、どのパイプラインを構築し、どのデータレディネス問題を最初に解決するかがわかります。
| ユースケース | データタイプ | ACE機能 |
|---|---|---|
| セールスコールインテリジェンス（Gong方式） | 音声＋テキスト＋構造化データ | Ingest + Analyze + Generate |
| リードスコアリング（Salesforce Einstein方式） | 構造化データ＋テキスト | Analyze + Predict |
| 請求書処理（AP自動化） | 画像＋構造化データ | Ingest + Analyze + Execute |
| サポートチケットトリアージ（Zendesk AI方式） | テキスト | Analyze + Predict + Execute |
| 不正検出（Stripe Radar方式） | 構造化データ＋時系列データ | Ingest + Analyze + Predict + Execute |
| DevOpsログ分析 | コード＋時系列データ | Ingest + Analyze + Predict |
| 製品デモ分析 | 動画＋テキスト＋構造化データ | Ingest + Analyze + Generate |
ベンダーがAIツールをピッチするとき、どのデータタイプを消費するかを尋ねてください。これらのタイプがスタック内でクリーンかつアクセス可能に適切に接続されていなければ、基礎となるモデルがどれほど優れていても、ツールは約束通りのパフォーマンスを発揮しません。
どのデータタイプがどのACE機能を支えるか
このマトリクスは7つのデータタイプを5つのACE機能に対してマッピングします。「高」はそのデータタイプが主要な入力であることを意味します。「中」は補助的または支持的であることを意味します。「低」は接続が珍しいことを意味します。
| データタイプ | Ingest | Analyze | Predict | Generate | Execute |
|---|---|---|---|---|---|
| テキスト | 高 | 高 | 中 | 高 | 低 |
| 構造化データ | 中 | 高 | 高 | 中 | 中 |
| 画像 | 高 | 高 | 低 | 高 | 低 |
| 音声 | 高 | 高 | 低 | 中 | 低 |
| 動画 | 高 | 中 | 低 | 中 | 低 |
| コード | 中 | 高 | 低 | 高 | 中 |
| 時系列データ | 中 | 高 | 高 | 低 | 中 |
このマトリクスから3つのことが際立っています。
Ingestは非テキストタイプのエントリーポイントです。 画像、音声、動画は直接推論できません。まず変換が必要です（OCR、文字起こし、シーン分析）。Ingestパイプラインが壊れていると、下流のすべてが失敗します。
Analyzeは普遍的です。 情報を取り込んだ後は常に理解が続くため、すべてのデータタイプがAnalyzeに供給されます。これがAnalyze機能がほぼすべての実際のAIユースケースに登場する理由です。
Predictは構造化データと時系列データで動きます。 予測とスコアリングには構造化形式の過去のパターンが必要です。汚い構造化データや短い時系列の履歴は、良いモデルを使っても性能が落ちます。
AIプロジェクトを始める前に：データインベントリチェックリスト
ベンダー契約に署名したり社内イニシアチブを立ち上げたりする前にこれを実行してください。1時間もかからず、最も高コストな間違いを防ぎます。
1. このユースケースにはどのデータタイプが必要か？ 具体的に書き出してください。一般的な「データ」ではなく。テキスト（どこから？）、構造化データ（どのシステムから？）、音声（どの録音？）などです。
2. そのデータを今すぐ持っているか？ 収集する予定のデータはカウントしないでください。現在持っているデータだけをカウントしてください。ユースケースに18ヶ月のセールスコール録音が必要で、Gongを使い始めて4ヶ月しか経っていない場合、そのデータは持っていません。
3. AIツールからアクセスできるか？ 存在するが到達できないデータは、持っていないデータと同じです。よくある障壁：APIがない、統合が構築されていない、オンプレミスアクセスが必要、IT部門がまだ接続を承認していない。
4. 有用なほどクリーンか？ 構造化データの場合：主要フィールドが入力されているレコードの割合は？テキストの場合：システム間で分散しているか？音声の場合：実際に録音・保存されているコールの割合は？
5. 適切に権限設定されているか？ 顧客音声、従業員のコミュニケーション、財務記録はすべてデータ処理義務を負います。接続前にベンダーとのDPAおよび社内ポリシーを確認してください。
6. 最初に解決すべきデータレディネスの問題はどれか？ ここがほとんどのAIプロジェクトが行き詰まる場所です。ツールは準備できているが、その下のデータが準備できていない。データの問題を修正してから、それに依存するAIを導入してください。地味な順序ですが、機能する順序です。
Rachelの問題について分かること
Rachelの3つの失敗したAIツールは、それぞれAIの問題ではなく特定のデータの問題を抱えていました。
Meeting Intelligenceツールが「Speaker 1」というラベルを生成したのは、ベンダーのパイプラインが彼女のカレンダーやCRMと統合されていなかったからです。文字起こしは正常に機能していました。話者識別のステップが、声を名前に照合するために必要な連絡先データを受け取ることができなかっただけです。
リードスコアリングモデルが全員に7/10を返したのは、CRMに差別化された過去のデータが欠けていたからです。クローズド成約レコードの多くに欠落フィールド（ソース、業界、企業規模）がありました。モデルは特徴的なパターンを見つけられず、平均にデフォルトしました。
プロポーザルツールが古いサービスを引用したのは、テキストコーパスに最新性の重み付けがなかったからです。2019年のサービス説明は2026年のものと同じ重みを持っていました。
いずれの場合も、AIは意図した通りに機能していました。そしてRachelは今や特定のデータタイプを名指しし、ギャップがどこにあったかを特定し、何が変わる必要があるかを説明できます。それがデータインベントリの価値です：単なるリストではなく、診断ツールです。
次に読むべきコンテンツ
この記事ではカタログをご紹介しました。次のステップは、これらのデータタイプをAIに使えるようにするものを理解することです。
- AIのためのデータレディネス — 実践的な前提条件：アクセス可能、構造化、最新、権限設定されたデータとはどういうものか、そしてどう達成するか
- クリーンデータフィールドガイド — プロジェクトを沈める前にデータ品質の問題を診断する
- Ingest — 最初のACE機能、画像・音声・動画データがワークフローに入るかどうかを決定する機能
- Analyze — すべてのデータタイプに適用される機能、生データがビジネスインサイトになる場所
- ACEフレームワーク — データ、機能、パターンがどのように接続されるかを示す6層スタックを持つ完全な周期表
Senior Operations & Growth Strategist