本記事はデータ優先のアプローチです。持っているデータタイプ(とその品質)がわかれば、選択肢を素早く絞り込めます。すぐにデプロイ可能なパターンもあれば、先にデータ整備が必要なパターンもあります。特定の前提条件の問題を解決するまで手の届かないパターンもあります。始める前のデータタイプの全体的な分類については、ビジネスAIを支える7種類のデータが適切な入門資料です。

参照マトリクス

「適合度:高」はパターンがこのデータタイプを主要なインプットとして使用し、それを中心に設計されていることを意味します。「適合度:低」はパターンがこのタイプを使用できますが、補助的または状況依存的であることを意味します。「不可能」はパターンがこのデータタイプを意味のある形で処理できないことを意味します。

データタイプ	RAG Asst	Score+Route	Vision Extract	Meeting Intel	Anomaly Agent	Gen Research	Doc Review	Workflow Copilot	Personalization	Autonomous Agent
テキスト	高	低	低	低	低	高	高	高	低	高
構造化	低	高	低	低	高	低	低	低	高	高
画像	不可能	不可能	高	不可能	低	不可能	低	不可能	低	低
音声	不可能	不可能	不可能	高	不可能	不可能	不可能	不可能	不可能	低
動画	不可能	不可能	不可能	高	不可能	不可能	不可能	不可能	不可能	低
コード	低	不可能	不可能	不可能	低	低	高	高	不可能	高
時系列	不可能	高	不可能	不可能	高	不可能	不可能	不可能	高	低

これは第一段階のフィルターとして読んでください。主に利用可能なデータが音声録音であれば、Meeting Intelligenceを検討します。アウトカムラベル付きの構造化CRMレコードであれば、Scoring and RoutingとAnomaly Agentが最もデプロイしやすい選択肢です。そのデータタイプを持っていることは必要条件ですが、十分条件ではありません。パターンが実際に機能するかどうかはデータの品質とアクセス可能性によって決まります。GartnerのAIに対応したデータの要点に関する調査では、従来の基準による「高品質」データはAIに対応したデータと同じではないという重要な区別が示されています。AIのトレーニングには、従来のデータクリーニングが取り除くエッジケースを含む代表的なデータが必要です。Gartnerは2026年を通じて、組織が不十分なデータ準備を理由にAIプロジェクトの60%を中止すると予測しています。

Key Facts: エンタープライズのデータとAI準備状況

Gartnerによると、ビジネスデータの80〜90%は非構造化データであり、構造化データはわずか10〜20%です。ほとんどの企業は実際に持っているAI対応の構造化データの量を大幅に過大評価しています。

企業の10%だけがAIを採用するための完全な準備ができていると感じており、54%はデータベースインフラが整っていないと認めています。(Typedef AI Unstructured Data Report, 2025)

Gartnerは2026年を通じて、モデルの制限ではなく不十分なデータ準備を理由に組織がAIプロジェクトの60%を中止すると予測しています。

テキストデータ

テキストは最も汎用性の高いインプットです。4つのパターンがそれを主要なデータタイプとして使用します。

RAG Assistantはテキスト専用です。ナレッジベース(ポリシー、SOP、製品ドキュメント、過去のチケット)を取り込み、関連するドキュメントを取得し、回答を生成します。RAGが機能するには、テキストが検索可能(インデックス化されており、ファイル共有に散在していない)、最新(古いドキュメントは自信満々の誤った回答を生成します)、矛盾がない(反対のことを言う2つのドキュメントは一貫性のないアウトプットを生成します)必要があります。パターンは散文が整理されていない状態にはよく対応しますが、矛盾するソースドキュメントには対応できません。

Generative Researchは複数のソース(ウェブ、内部ドキュメント、独自のデータベース)からテキストを取り込み、統合します。ここでの品質要件はRAGとは異なります。構造よりも幅広さが必要です。パターンは異種のソースを処理できます。必要なのはAPI、スクレイピング、または直接のドキュメントアップロードを通じたソースへのアクセスです。

Document Reviewは会話的なテキストではなく構造化されたテキストが必要です。NDAやMSAには一貫したセクションと既知の条項パターンがあります。Generative Researchはブログ記事を処理できます。Document Reviewはテンプレートや基準に従ったドキュメントが必要です。フリーフォームのメールを入力すると、フラグ付けがノイズになります。

Workflow CopilotはユーザーのCurrentコンテキストにあるテキストを使用します。下書き中のメール、解決中のチケット、開いているアカウントのCRMメモなどです。品質要件は過去のボリュームではなく、コンテキストの鮮度です。Copilotは過去のアーカイブではなく、現在の状態のテキストへのリアルタイムアクセスが必要です。

構造化データ

構造化データとは、数値、カテゴリ、日付、スキーマに一致するレコードです。3つのパターンが最も直接的にそれに依存します。

「アウトカムラベルのフィールド完成率が80%未満のCRMデータセットでScoring and Routingモデルをデプロイしようとする企業は、シグナルではなくノイズとして機能するモデルを生成します。高スコアのLeadは低スコアのLeadと同じ率でクローズします。問題はモデルではありません。インプットです。」(Rework Data Readiness Analysis, 2026)

**Scoring and Routing**には3つの特性を持つ構造化データが必要です。十分なボリューム(通常1,000件以上の過去のレコード)、アウトカムラベル(勝/負とマークされたディール、コンバートした/しないとマークされたLead、不正/正当とマークされた請求)、フィールドの完成率(主要フィーチャーのレコードの40%にnull値がある場合、モデルは不完全なシグナルから学習します)。これはCRMのデータ品質が不完全な場合に最も直接的にブロックされるパターンです。ラベル付きアウトカムを持つクリーンな構造化データセットは、企業が持てる最も価値のあるAI資産の1つです。Wikipediaの構造化データの概要はここで有用な基本的な区別を提供しています。構造化データはあらかじめ定義されたスキーマに従いますが、エンタープライズデータの約90%は非構造化です。ほとんどの企業はAIプロジェクトを計画する際に想定するよりも後者がはるかに多く、前者がはるかに少ない状態です。

Anomaly Agentには安定したベースラインを持つ構造化データが必要です。時系列の指標、取引レコード、イベントログなどです。モデルは「正常」の状態を学習し、逸脱にフラグを立てます。品質要件: ベースラインデータがクリーンであること(トレーニング期間の異常がモデルを混乱させます)、一貫していること(時間の経過に伴って同じフィールド、同じスキーマ)、十分に長いこと(最低60日、季節性のあるビジネスは丸1年)。

**Personalization Engine**は構造化された行動データを使用します。ユーザーがクリックしたもの、購入したもの、ページに滞在した時間、評価したもの。パターンは行動イベントが一貫して追跡されているとき、各イベントにユーザー識別子があるとき、個別プロフィールを構築するのに十分なユーザー単位のボリュームがあるときに最もうまく機能します。トラフィックが少ない製品やユーザー数が少ないB2Bでは、パーソナライズするのに十分なユーザー単位の行動がないため、このパターンを効果的にデプロイできないことが多いです。

画像データ

画像は最も制約の多いデータタイプです。1つのパターンがそれを中心に構築されており、その他いくつかは状況に応じて使用します。

Vision Extractは標準的な画像パターンです。画像やスキャンされたドキュメントを取り込み、構造化フィールドを抽出し、記録システムにレコードをプッシュします。ここでの品質要件は具体的で交渉の余地がありません。画像解像度はテキストを明確に読むのに十分でなければならず、ドキュメントのバリエーションはトレーニングデータに含まれている必要があり(ベンダーAの請求書はベンダーBのものと異なって見えます)、ターゲットフィールドはモデルが確実に見つけられるよう十分に一貫している必要があります。詳細な品質基準についてはVision Extract: 画像を構造化データに変換するをご覧ください。

Personalization Engineは製品画像をレコメンデーションのシグナルとして使用できます(このブルーのスニーカーを見たなら、こちらのスタイルもどうぞ)。しかしこれは単独の機能というよりは特定の機能です。Personalization Engineのほとんどのミッドマーケットデプロイメントは、RAWの画像シグナルではなく行動的な構造化データを使用します。

Anomaly Agentは特定のデプロイメントで視覚的な異常(隙間のある商品棚、欠陥のある製造部品)にフラグを立てることができます。しかし、これには標準的なビジネスAIデプロイメントではなく、専用のコンピュータビジョンパイプラインが必要です。

音声データ

音声はビジネスAIではほぼ単一目的です。

**Meeting Intelligence**は音声パターンです。通話とミーティングの音声録音を取り込み、文字起こし、トピックとアクションアイテムを抽出し、サマリーを生成し、構造化データをCRMにプッシュします。品質要件は実践的なものです。通話録音が有効になっていること(多くの管轄区域では参加者の同意が必要です)、音声品質が文字起こしに十分であること(悪いモバイル接続は質の低いトランスクリプトを生成し、それが後続のすべてのステップに伝播します)、そして発話者識別(どの声が誰のものかを知ること)が帰属管理に重要です。

重要な区別として、音声ファイルと音声トランスクリプトは異なるものです。RAW音声を取り込むMeeting Intelligenceのデプロイメントは、事前に文字起こしされたテキストを取り込むものよりも複雑なパイプラインを稼働させています。多くのチームはRAW音声の取り込みをスキップし、トランスクリプトサービス(Otter.ai、Zoomの文字起こし、Teamsの文字起こし)を前ステップとして使用し、そのトランスクリプトを分析レイヤーに送ります。これは有効なアーキテクチャであり、多くの場合よりコスト効率が高いです。

Autonomous Agentは原則的に音声を処理できます(音声インターフェースのAgent)が、これは標準的なビジネスデプロイメントではまれです。ほとんどのAutonomous Agentの作業は、テキストまたは構造化データのインプットで動作します。

動画データ

動画はデータタイプの中で最も処理オーバーヘッドが高く、主に音声のスーパーセットとして関連します。

Meeting Intelligenceはビデオ通話を処理します。動画コンポーネントは視覚的な情報を追加します(見込み客は頷いているか、カメラはオフか)が、デプロイされているほとんどのMeeting Intelligenceツールは動画ストリームではなく音声トラックとトランスクリプトを分析します。動画固有の機能(エンゲージメントシグナル、視覚的なキュー)はGongなどの製品に存在しますが、通話内容分析の補助的なものです。Meeting Intelligence用に音声録音と動画録音のどちらかを選ぶ場合、音声はほとんどのユースケースで十分です。

オーバーヘッドが重要です。動画ファイルは同じ時間の音声ファイルより10〜100倍大きくなります。動画を大規模に保存、処理、インデックス化するには、音声のみのパイプラインよりも大幅に多くのインフラが必要です。初めてMeeting Intelligenceを実装するほとんどのチームは音声から始めるべきです。

ビジュアルナビゲーションコンテキストのAutonomous Agent(画面を見る必要があるブラウザコントロールAgent)は動画またはスクリーンショットをインプットとして使用します。これは標準的なビジネスAIのWorkflowではなく、特殊なデプロイメントパターンです。

コードデータ

コードはテキストですが、散文ではありません。コードを処理するパターンはそれを異なる方法で扱います。

Workflow Copilotは標準的なコードパターンです。GitHub Copilot、Cursorなどのツールは、コーディングのコンテキストに特化したWorkflow Copilotです。エディタで開いているファイル、リポジトリのコンテキスト、ユーザーが進行中の編集を取り込み、補完の提案、リファクタリング、新しい関数を生成します。品質要件: コードがツールにアクセス可能であること(ローカルリポジトリ、IDEの統合)、コードの依存関係がファイルにまたがるため、散文のCopilotよりもコンテキストウィンドウが重要です。

Document Reviewはコンプライアンスやセキュリティのコンテキストでコードに適用します。OWASPの脆弱性についてコードをレビューするセキュリティ監査、またはAPI統合がベンダーの利用規約に違反していないかどうかを確認する法的レビューは、ドキュメントとしてコードに適用されるDocument ReviewのWorkflowです。標準的なDocument Reviewツールはこれをサポートしていません。コード分析のために特別に構築されたツールが必要です。

スペクトルのコーディング側でのAutonomous Agent(イシューを読み、コードを書き、テストを実行し、プルリクエストを開くAgent)はコードをインプットとアウトプットの両方として扱います。AgentはGitHubのイシュー(テキスト+コードコンテキスト)を取り込み、スコープを分析し、修正を生成し、コミットとテスト実行を実行します。これは2026年において最も成熟したAutonomous Agentのアプリケーションの1つです。

時系列データ

時系列データは時間でインデックスされた任意の測定値です。指標、センサーの読み取り値、取引ログ、使用イベントなどです。3つのパターンがそれを使用します。

Anomaly Agentは主要な時系列パターンです。安定した時系列がどのように見えるかを学習し、逸脱にフラグを立てるように構築されています。鮮度と一貫性が最も重要な2つの品質要件です。途中で計測が変わる指標ストリームは、計測変更の時点で誤った異常を生成します。欠損データポイント(ストリームのギャップ)は見逃しを生成します。モデルはギャップを正常として扱うため、ギャップ中に発生する異常は検出されません。

Scoring + Routingは時系列フィーチャーをスコアリングモデルへのインプットとして組み込むことができます(過去30日間のサポートチケット数は？過去4四半期でNPSはどのようにトレンドしているか？)。しかし、それらの時系列をまず構造化フィーチャーにサマリーとして集約する必要があります。RAWの時系列は、スコアリングのインプットとして有用になる前に前処理(集約、ウィンドウ化、サマリー化)が必要です。

Personalization Engineは暗黙的に時系列を使用します。ユーザーの閲覧履歴、購入頻度、季節的なパターン: これらは時系列の行動シグナルです。パターンは特定の時点のスナップショットだけでなく行動のトレンドを確認できると、より良く機能します。

マルチモーダルの組み合わせ

最も高性能なデプロイメントの一部はデータタイプを組み合わせます。

Meeting Intelligence + CRMの構造化データ: 通話で何が言われたか(音声)は、アカウントについてCRMが何を言っているか(構造化)と組み合わせると、より強力になります。「見込み客が価格への懸念を述べた」という通話サマリーは、「このアカウントは30日間リスクステージにある」とシステムが示せるとより有用です。組み合わせにより、Generateのステップがより豊かなコンテキストを生成できます。

Personalization Engine + テキストコンテンツ: 構造化された行動データ(ユーザーがクリックしたもの)とテキストメタデータ(そのコンテンツがどのトピックについてだったか)を組み合わせると、エンジンはアイテムレベルだけでなくコンテンツレベルでパーソナライズできます。「あなたのような人はこの製品を購入しました」の代わりに、「あなたの読書パターンを持つユーザーは価格よりもコンプライアンスを重視する傾向がある」という情報が得られます。

Vision Extract + 構造化された記録システムのテンプレート: 抽出モデルで請求書がどのように見えるかを知ることは、モデルが抽出したベンダー名を確認するためにベンダーマスターにクエリできる場合により良く機能します。構造化データベースが画像抽出のアウトプットを検証します。

マルチモーダルの組み合わせは可能性を拡大しますが、データ準備の要件を乗算します。組み合わせるすべてのデータタイプのアクセス、品質、権限が必要です。

データパターンマトリクス

データパターンマトリクスは、7つのエンタープライズデータタイプ(テキスト、構造化、画像、音声、動画、コード、時系列)を10のAIパターンに3つの適合度評価でマッピングする意思決定ツールです。適合度:高(パターンがこのデータタイプを主要なインプットとして使用)、適合度:低(補助的または状況依存的な使用)、不可能(パターンがこのデータタイプを意味のある形で処理できない)です。マトリクスは第一段階のフィルターとして機能します。最も優れた利用可能なデータが計画しているパターンの「適合度:高」のインプットとして表示されない場合、モデルの品質に関わらずデプロイメントはパフォーマンスを発揮しません。

Rework分析: Gartnerの調査(エンタープライズデータの80〜90%が非構造化データであり、AIに対応したデータが不足しているAIプロジェクトの60%が中止される)に基づくと、データパターンマトリクスは最も一般的なAI計画エラーに対応しています。それはインプット要件ではなくアウトプット能力に基づいてパターンを選択することです。Reworkの実装経験では、パターンにコミットする前に実際に利用可能なデータに対してマトリクスを実行するチームは、主要なデータタイプが選択したパターンをサポートしないという統合の途中での発見を回避するため、Time-to-Valueを平均8週間短縮します。

データ準備の最短経路

各データタイプから最も速くデプロイできるパターンを探している場合:

最も優れたデータが...	これから始める...	理由...
クリーンなテキストドキュメント(ポリシー、SOP、製品コンテンツ)	RAG Assistant	データ準備のオーバーヘッドが低く、ナレッジワーカーへの即時価値が高い
12ヶ月以上のラベル付きアウトカムを持つCRMレコード	Scoring + Routing	リードの優先付けにROIが明確。すでに持っているデータでモデルをトレーニングできる
請求書、領収書、またはスキャンされたフォーム	Vision Extract	構造化アウトプットが即座に有用。ROIは処理時間で測定可能
営業またはサポートの通話録音	Meeting Intelligence	文字起こしの精度が高い。CRM統合が初日から価値を提供
90日以上の履歴を持つ取引ログまたは指標ストリーム	Anomaly Agent	ベースラインが確立されている。フラグ付けをほぼ即座に開始できる
複数ソースのウェブおよび内部ドキュメント	Generative Research	構造化データ不要。リサーチ品質が即座に向上する
Openイシューバックログを持つコードリポジトリ	Workflow Copilot	開発者ツールが成熟している。IDEに統合すると採用率が高い

これらは出発点であり、最終的なアーキテクチャではありません。最も速くデプロイできるパターンが常に最も高い長期ROIを持つとは限りません。しかし最も強いデータで始めることで組織の信頼が構築され、測定可能な結果が生まれ、後でより複雑なパターンに必要なラベル付きアウトカムが生成されます。

このマトリクスが教えてくれないこと

データタイプを持っているからといって、対応するパターンをデプロイする準備ができているとは限りません。AIパターン別のデータ準備チェックでは、各パターンが必要とする具体的な品質しきい値についてより詳しく説明しています。例えば、構造化CRMデータはScoring + Routingに必要ですが、アウトカムフィールドが60%しか完成していない構造化データは準備ができていません。

マトリクスはパターン間の依存関係も扱いません。Meeting Intelligenceは音声データからデプロイ可能ですが、そのアウトプットをScoring + Routingに供給したい場合は、構造化レイヤーも機能している必要があります。パターンの依存関係と前提条件では、パターンが互いにどのように依存しているかを説明しています。

またAIパターンとは何かを初めて学ぶ方は、このマトリクスを選択ツールとして使用する前に、そちらから始めることをお勧めします。

データは基盤です。マトリクスは現在地点からどのドアが開いているかを示します。準備状況のチェックはそのドアを実際に通り抜けられるかどうかを示します。

よくある質問

AIパターン選択で最も一般的な間違いは何ですか？

必要なインプットではなく、約束されたアウトプットに基づいてパターンを選択することです。Scoring and Routingモデルにはラベル付きの過去のアウトカムを持つ構造化CRMデータが必要です。Anomaly Agentには60〜90日間のベースライン時系列データが必要です。RAG Assistantには維持された最新のナレッジベースが必要です。ほしいアウトプットではなく持っているデータから始めることが、デプロイ可能な最初のパターンへの最も信頼性の高い方法です。

過去のトレーニングデータなしにデプロイできるAIパターンはどれですか？

RAG Assistant、Generative Research、Document Review、Workflow Copilotは、特定のアウトカム履歴でトレーニングされたモデルではなく、事前トレーニング済みの言語モデルを使用するため、すべて過去のトレーニングデータなしにデプロイできます。Vision Extractは特定のドキュメントタイプのトレーニングサンプルが必要ですが、アウトカムラベルは不要です。Scoring、Routing、Anomaly Agent、Personalization Engineはすべて自社環境に固有の過去のデータが必要です。

実際に構造化されているエンタープライズデータは何パーセントですか？

Gartnerはエンタープライズデータの80〜90%が非構造化であり、構造化データはわずか10〜20%と推定しています。このギャップが、ほとんどの企業が最初のデプロイメントを計画する際に想定するよりもAI対応データがはるかに少ない理由です。構造化データに最も依存するパターン(Scoring and Routing、Anomaly Agent、Personalization Engine)は、チームが最初にデプロイする予定の多くのパターンでもあります。それも、構造化データが実際に存在し、十分な品質を持っていることを確認する前に計画することが多いです。

Meeting Intelligenceはゼロからの音声の代わりに事前に文字起こしされたテキストで機能しますか？

はい。多くのデプロイメントではトランスクリプトサービス(Zoom、Teams、Otter.ai)を前ステップとして使用し、そのトランスクリプトを分析レイヤーに送ります。これは有効でしばしばよりコスト効率の高いアーキテクチャです。ゼロからの音声と事前文字起こしパイプラインの品質の差は、ほとんどのユースケースで控えめです。主なトレードオフは、事前文字起こしパイプラインは文字起こしサービスの品質に依存し、ゼロからの音声パイプラインは文字起こし品質をより詳細にコントロールできる点です。

最も多くのパターンが処理できるデータタイプはどれですか？

テキストと構造化データはそれぞれ最も広いパターン互換性を持っています。テキストはRAG Assistant、Generative Research、Document Review、Workflow Copilotの主要なインプットであり、他のいくつかのパターンでも補助的に使用されます。構造化データはScoring and Routing、Anomaly Agent、Personalization Engineの主要なインプットです。ほとんどのエンタープライズのAIポートフォリオは最終的に両方を組み合わせます。これがテキスト+構造化の組み合わせが最も豊かなパターンセットを生み出す理由です。

Victor Hoang

Co-Founder & CMO, Rework

AI Patterns

データタイプ別のパターン選択: あなたのデータで機能するAIパターン