【備忘録】AI活用ではデータを「切り口」と「関係性」で見られる形にしておく（OLAPとグラフ的な発想）

はじめに

AI活用というと、プロンプト、RAG、エージェント、モデル選定などに目が行きがちです。

ただ、業務でAIを使うことを考えると、もう少し手前にある、かなり地味な問題にぶつかる気がしています。

それは、AIに渡す前の事実データを、あとから分析できる形で残せているかという問題です。

たとえば、次のようなことです。

• どの期間のデータを見るのか
• どの時点の状態を見ているのか
• 顧客別、商品別、担当者別、状態別など、どの切り口で見るのか
• 人、商品、問い合わせ、障害、対応履歴などの関係性をたどれるのか
• トラブルが起きたとき、どこから再処理・復旧できるのか

昔、OLAPやバッチ処理に触れたとき、正直「よくこんな難しいものを作るな」と思った記憶があります。

しかし今振り返ると、AI活用でも同じように、事実をためて、切り口を変えて、関係性をたどり、時点ごとの差分を見るという考え方が必要になる場面が増えるのではないかと思いました。

※本記事は個人の整理メモです。特定の製品やアーキテクチャを推奨するものではありません。

AIに聞く前に、まず「事実」を残す

AIに質問すると、それらしい答えは返ってきます。

しかし、その回答が業務判断に使えるかどうかは、AIそのものだけでなく、元になるデータの残し方にも大きく依存します。

たとえば、問い合わせ対応をAIで分析したい場合でも、次のような情報が残っていなければ、あとから見直すのは難しくなります。

• 問い合わせが発生した日時
• 顧客や契約の状態
• 問い合わせのカテゴリ
• 対応した担当者
• 参照したナレッジ
• AIに渡した入力
• AIから返ってきた出力
• 人間が最終的に採用・修正した内容

ここで大事なのは、AIの回答だけを保存するのではなく、AIが参照した事実、入力、出力、人間の判断を分けて残すことだと思います。

AIの出力は、あくまでその時点の入力に基づく生成結果です。あとから検証するには、「そのとき何を根拠にしたのか」を追える必要があります。

多次元的に見る：OLAP的な発想

OLAP（Online Analytical Processing）は、ざっくり言えば、業務データを複数の切り口から分析するための考え方です。

Microsoft Learnでは、Analysis Servicesの多次元モデルについて、cube構造を使ってビジネスデータを複数のdimensionにまたがって分析するものとして説明されています。

なお、現在はTabularモデルが広く利用されていますが、ここで借りたいのは製品選定の話ではなく、「同じ事実を複数の軸で見る」という発想です。

ここでいう「cube」や「dimension」という言葉を厳密に使わなくても、発想としては次のように捉えると分かりやすいです。

同じ事実データを、次のような複数の軸で見ます。

切り口	見たいことの例
時間	日別、週別、月別で傾向が変わっているか
顧客	どの顧客層で問い合わせや障害が多いか
商品・機能	どの機能に問題や改善要望が集まっているか
担当者・チーム	対応負荷がどこに偏っているか
ステータス	未対応、対応中、完了、再オープンがどう推移しているか
重要度	重大インシデントと軽微な問い合わせを分けて見られるか

AI活用でも、単に「問い合わせを要約して」ではなく、次のように聞きたくなります。

• 直近1か月で増えている問い合わせカテゴリは何か
• 特定顧客に関係する未解決課題は何か
• 先月と今月で、障害傾向はどう変わったか
• 重要度の高い問い合わせだけを見ると、原因の偏りはあるか

このような問いに答えるには、AIの賢さだけでなく、期間・分類・状態・担当・重要度などで切り出せるデータ構造が効いてくると感じています。

つまり、AI活用でもOLAP的な「切り口を変えて見る」発想はかなり効いてくるのではないか、ということです。

関係性を見る：グラフDB的な発想

一方で、OLAP的な切り口だけでは見えにくいものもあります。

それが、人・物・イベント・ドキュメントの関係性です。

グラフDBは、データを「つながり」そのものとして扱うデータベースです。Neo4jの入門ドキュメントでは、グラフDBは、データをノード・関係(リレーションシップ)・プロパティとして扱うデータベースという趣旨で説明されています。また、Amazon Neptuneのドキュメントでも、Neptuneは高度につながったデータセットを扱うアプリケーション向けのグラフデータベースサービスとして説明されています。　

たとえば、問い合わせ対応のデータを関係性として見ると、次のようになります。

顧客A
  ├─ 利用中の商品B
  ├─ 発生した障害C
  ├─ 関連する問い合わせD
  ├─ 参照されたナレッジE
  └─ 対応した担当者F

このような関係性が残っていると、AIに対して次のような問いを立てやすくなります。

• この障害に影響を受けた顧客は誰か
• 同じナレッジを参照している問い合わせに共通点はあるか
• 特定の商品と特定の問い合わせカテゴリに関係はあるか
• ある担当者に集中している対応は、どの顧客・機能に紐づいているか

ここで大事なのは、必ずしも最初からグラフDBを導入することではありません。

RDBの外部キー、履歴テーブル、イベントログ、DWH、ドキュメントDBなどでも、関係性をある程度たどる設計はできます。

記事で言いたいのは、グラフDBを使うべきという話ではなく、AI活用では関係性をたどれるように事実を残す発想が重要になりそう、という話です。

スナップショットで「時点」を残す

AI活用で見落としやすいのが、いつ時点の状態を見ているのかです。

業務データは常に変わります。

• 顧客の契約状態が変わる
• 問い合わせのステータスが変わる
• ナレッジ記事が更新される
• 商品構成が変わる
• AIの分類ロジックやプロンプトが変わる

そのため、現在のDBだけを見ても、「過去のある時点でAIが何を見て、どう判断したのか」を再現できないことがあります。

この点では、定期的なスナップショットや、Temporal Tableのような履歴管理の考え方が重要になります。

たとえばSQL Serverのsystem-versioned temporal tablesは、Microsoft Learnで「任意の時点におけるテーブル内データの情報を提供する組み込みサポート」と説明されています。また、過去時点の状態の再構築、時間の経過に伴う傾向の計算、誤変更やアプリケーションエラーからの復旧などの用途が挙げられています。

AI活用に置き換えると、次のようなものを残しておくイメージです。

2026-08-01 時点の顧客状態
2026-08-01 時点の問い合わせ一覧
2026-08-01 時点のナレッジ構成
2026-08-01 時点のAI分類結果

これを定期的に残しておくと、あとから次のような分析ができます。

• 先月と今月で問い合わせ傾向がどう変わったか
• あるナレッジ更新の前後で、問い合わせ件数は変わったか
• AIの分類ルールを変えたあと、分類結果にどんな差分が出たか
• 障害発生前後で、顧客やシステムの状態にどんな変化があったか

つまり、ここでいうスナップショットや履歴は、単なるバックアップとしてだけでなく、つまり、スナップショットは単なるバックアップではなく、過去・現在・未来をつなげて分析するための観測点として使えるのではないかと思います。

過去・現在・未来をつなげる

AIが本当に役に立つのは、単発の要約だけではなく、過去から現在への変化を見て、次に何を確認すべきかを考える場面かもしれません。

たとえば、次のような流れです。

過去：過去3か月の問い合わせ、障害、対応履歴を確認する
現在：今月の状態をスナップショットとして見る
未来：次に増えそうな問い合わせ、注意すべき顧客、改善すべきナレッジを考える

このとき必要になるのは、次の3つです。

1. 事実データ
   何が起きたかを残す。

2. 切り口
   期間、顧客、商品、状態、担当などで見られるようにする。

3. 関係性
   顧客、商品、障害、問い合わせ、ナレッジ、担当者のつながりをたどれるようにする。

この3つがそろうと、AIは単なる文章生成ではなく、分析の補助として使いやすくなります。

もちろん、AIが出した未来予測をそのまま信じるべきではありません。特に業務判断では、人間による確認、根拠データへのリンク、再現可能な集計条件が必要です。

ただ、過去と現在を構造化して残せていれば、AIに「どこを見るべきか」「どんな仮説がありそうか」を出してもらう使い方はしやすくなると思います。

バッチ処理で苦労した記憶

ここで思い出すのが、昔のバッチ処理や集計処理で苦労した記憶です。

ある期間でデータを区切って処理する。日次、月次、締め処理のように、決められたタイミングでデータを固める。

言葉にすると単純ですが、実際にはかなり難しいです。

• 期間の境界にあるデータをどう扱うか
• 遅れて到着したデータをどう反映するか
• 処理途中で障害が起きたとき、どこから再開するか
• 一部だけ再処理したとき、集計結果が二重計上されないか
• 処理前、処理中、処理後のどの状態が正しいのか

Azure Architecture Centerのバックグラウンドジョブ設計のベストプラクティスでも、ジョブの信頼性、監視、失敗時の扱い、再試行などが重要な観点として扱われています。

AI活用でも、定期的にデータを集めて分析するなら、似た問題が起きます。

たとえば、毎朝AIで問い合わせ傾向を分析する処理を作ったとしても、次のような問題が出ます。

• どの時刻までの問い合わせを対象にするのか
• 前回処理済みのデータをどう判定するのか
• 途中でAI API呼び出しが失敗したら、どこから再実行するのか
• 同じデータを再処理したとき、結果が上書きされるのか、履歴として残るのか
• プロンプトやモデルを変えた場合、過去の分析結果と比較できるのか

このあたりは、生成AI特有というより、昔からあるデータ処理・バッチ処理・分析基盤の問題に近いです。

だからこそ、AI活用を考えるときも、プロンプトだけでなく、データの区切り方、再処理、復旧、履歴管理を最初から考えておく必要があるのではないかと思います。

AI時代のデータ設計で意識したいこと

自分用のメモとして、AI活用で意識したいことを整理すると、次のようになります。

1. 元データとAI生成結果を分ける

AIの出力だけを残すのではなく、元データ、AIへの入力、AIの出力、人間の判断を分けて残します。

元データ
  ↓
AIへ渡した入力
  ↓
AIの出力
  ↓
人間の確認・修正・採用判断

これにより、あとから「AIが何を見てそう答えたのか」を追いやすくなります。

2. 期間・時点・抽出条件を残す

「今月のデータ」と書くだけでは、あとから再現できないことがあります。

• 対象期間
• 抽出時刻
• タイムゾーン
• フィルタ条件
• 除外条件
• 再処理か初回処理か

このあたりを残しておくと、分析結果の再確認がしやすくなります。

3. 切り口を変えられる粒度で保存する

最初から集計済みの結果だけを保存すると、あとから別の切り口で見たくなったときに困ります。

たとえば「月別件数」だけでは、顧客別、商品別、担当者別には見られません。

もちろん生データをすべて無制限に残せばよい、という話でもありません。コスト、個人情報、保存期間、権限管理とのバランスが必要です。

ただ、AIであとから分析する可能性があるなら、どの粒度で残すと後から切り直せるかは重要な設計ポイントになります。

4. 関係性をたどれるIDを残す

AIに自然文を渡すだけでは、あとから関係性を追いにくくなります。

最低限、次のようなIDや参照関係は残しておきたいです。

• 顧客ID
• 契約ID
• 商品・機能ID
• 問い合わせID
• 障害ID
• ナレッジID
• 担当者ID
• AI実行ID

これらがあると、グラフDBを使わなくても、関係性をたどる入口になります。

5. 再実行できるようにする

AI APIの呼び出し、バッチ集計、データ抽出は失敗する前提で考えた方が安全です。

• どこまで成功したか
• どこから再開できるか
• 同じ処理を再実行しても二重登録されないか
• 入力データと出力データの対応が残っているか
• プロンプトやモデルのバージョンが残っているか

このあたりがないと、障害時に「何が正しい状態なのか」が分からなくなります。

6. AIの答えではなく、分析可能な履歴を残す

AIの回答は便利ですが、回答そのものだけを残しても、将来の分析には使いにくい場合があります。

大事なのは、AIの回答を最終成果物としてだけ扱うのではなく、分析可能な履歴の一部として残すことだと思います。

小さく始めるなら

いきなりDWH、OLAP、グラフDB、履歴管理、バッチ基盤を全部作るのは重いです。

小さく始めるなら、次のような形でも十分だと思います。

項目	最初の実装例
事実データ	CSV、RDBテーブル、スプレッドシート
スナップショット	日付付きのテーブル、日次エクスポート、履歴テーブル
切り口	日付、カテゴリ、顧客、ステータスなどの列を持つ
関係性	ID列、参照ID、リンクテーブルを残す
AI入出力	prompt、model、input_id、output、created_at を保存する
再処理	run_id、status、started_at、finished_at、error を残す

最初から立派な基盤を作るというより、あとから見直せる最低限の観測点を残すことが大事そうです。

まとめ

AI活用では、AIに何を聞くかだけでなく、AIに渡す前のデータをどう残すかが重要になると思います。

今回の整理では、次の4つが特に大事だと感じました。

• OLAP的に「切り口」を変えて見る
• グラフ的に「関係性」をたどる
• 履歴・スナップショットで「時点」を残す
• バッチ処理的に「再処理・復旧」を考える

AIが賢くなっても、元になる事実データが曖昧だったり、期間や条件を再現できなかったり、障害時にどこからやり直せるか分からなかったりすると、業務では使いにくくなります。

昔はOLAPやバッチ処理を見て「よくこんな難しいものを作るな」と思っていました。

でも今考えると、その難しさの中には、AI活用にも通じる大事な知見がかなり含まれていたのかもしれません。

参考（公式情報・一次情報）

※各リンクの確認日: 2026-08-22

• Microsoft Learn: Multidimensional models
  https://learn.microsoft.com/en-us/analysis-services/multidimensional-models/multidimensional-models-ssas?view=asallproducts-allversions
• Neo4j Docs: What is a graph database
  https://neo4j.com/docs/getting-started/graph-database/
• Microsoft Learn: Temporal Tables - SQL Server
  https://learn.microsoft.com/en-us/sql/relational-databases/tables/temporal/overview?view=sql-server-ver17
• Microsoft Learn: Best Practices for Background Jobs - Azure Architecture Center
  https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs