生成AI時代のシステム開発で重要な「データ設計」とは？AI活用を成功させるポイント

生成AIを業務に取り入れる企業が増えるなか、「どの生成AIを使うか」「どの業務にAIを組み込むか」といった点に目が向きがちです。しかし、生成AIを業務システムで本格的に活用するうえで、それ以上に重要なのがAIにどのようなデータを渡すかという視点です。

どれほど高性能な生成AIを導入しても、参照するデータの意味が曖昧だったり、同じ情報が異なる名称で管理されていたり、AIが扱いやすい形式になっていなかったりすれば、期待した回答を得られない可能性があります。

実際、資産運用の分野でも、投資信託に関するデータの整備状況が生成AI活用における課題として指摘されています。人間であれば文脈から理解できる情報でも、AIが正しく意味を判別できるとは限りません。

これは金融業界だけの問題ではありません。長年使われてきた業務システムには、人間が利用することを前提としてデータが蓄積されているケースが数多くあります。

生成AIを導入するのであれば、AI機能を追加するだけではなく、「AIが正しく理解し、利用できるデータになっているか」まで含めて業務システムを設計することが重要です。

本コラムでは、生成AIと業務システムを組み合わせる際にデータ設計が重要になる理由と、AIが正しくデータを利用できる業務システムを作るための考え方について解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【記事要約】生成AI時代の資産運用、投信データの未整備がAI活用の壁に

日本の投資信託では、信託報酬率や組み入れ銘柄、純資産額の推移など、多くの情報がコンピューターで比較・処理しやすいXBRL形式で整備されていない。このため生成AIが投信データを正確に読み取れず、「配当金」と「分配金」を混同するなど、誤った情報を提示するハルシネーションにつながる懸念がある。従来、業界ではデータを標準化するメリットが見いだされにくかったが、生成AIの普及で状況は変化している。三菱UFJ銀行も金融データインフラを活用した「Apps in ChatGPT」の提供を発表するなど、AIと金融データを組み合わせたサービス開発が進む。AIを資産運用に活用するうえで、正確に処理できるデータ基盤の整備が重要になっている。

出典：日本経済新聞「〈金融PLUS〉資産運用にAI利用、取り残される投信」2026年8月18日付朝刊

生成AI時代に浮き彫りになる「データ」の問題

生成AIの性能は急速に向上しています。その一方で、企業が生成AIを業務で利用しようとすると、AIそのものではなく、社内に蓄積されているデータが障壁になることがあります。

たとえば、社内に次のようなデータが存在しているケースです。

• 同じ意味の項目が複数の名称で登録されている
• 部署ごとにデータの入力ルールが異なる
• Excel、PDF、業務システムなどに情報が分散している
• コードや略称の意味を担当者しか理解していない
• 古いデータと最新データを判別しにくい
• 数値の単位や集計方法が統一されていない
• データ同士の関係がシステム上で明確になっていない

人間であれば、「この部署ではこの名称を使っている」「この項目は実質的に同じ意味だ」と経験から判断できる場合があります。

しかし、生成AIが利用する場合は事情が異なります。

AIにとって重要なのは、データが存在することだけではありません。そのデータが何を意味しているのか、ほかのデータとどう違うのかを正しく判別できる状態になっていることが重要です。

投信データの問題から見える生成AI活用の難しさ

日本の投資信託では、ファンド名や財務情報など一部のデータはXBRL化されているものの、信託報酬率、組み入れ銘柄、純資産額の推移など、多くの情報についてコンピューターが比較・処理しやすい状態になっていないことが課題として挙げられています。

その結果、生成AIが投信に関する情報を利用しようとしても、正しく意味を理解できない場合があります。

象徴的なのが、「配当金」と「分配金」のような似ているものの意味が異なる情報です。

人間であれば金融に関する知識や前後の文脈から違いを判断できます。しかし、元となるデータの定義や分類が曖昧であれば、生成AIが異なる概念を同じものとして扱ってしまう可能性があります。

そこで発生する問題の一つが、ハルシネーションです。

ハルシネーションとは、生成AIが事実とは異なる内容を、あたかも正しい情報であるかのように生成してしまう現象を指します。

もちろん、ハルシネーションにはAIモデル自体の特性などさまざまな要因があります。そのため、データを整備すれば完全になくせるわけではありません。

一方で、参照元となるデータそのものが曖昧であれば、正確な回答を期待することはさらに難しくなります。

ここに、企業が生成AIを導入する際に見落としやすいポイントがあります。

「生成AIを導入する」だけでは業務では使えない

生成AI導入を検討するとき、最初にAIサービスやAIモデルを選ぼうとする企業もあります。

しかし、本来はその前に、

「生成AIに何をさせたいのか」

を明確にする必要があります。

たとえば、営業担当者が生成AIに「この顧客に過去どのような提案を行ったか」と質問できるシステムを作るとします。

生成AIの機能だけを考えれば、質問を入力し、回答を表示する画面を作ればよいように思えます。

しかし、実際にはそう単純ではありません。

顧客情報はCRM、商談履歴は営業管理システム、契約情報は基幹システム、担当者とのやり取りはメール、提案資料はファイルサーバーに保存されているかもしれません。

さらに、「顧客」「取引先」「契約先」がそれぞれのシステムで異なるIDによって管理されていれば、同じ会社に関する情報であることを判別する仕組みも必要です。

生成AIが回答を作る前に、正しいデータを見つけ、同じ対象の情報を結び付け、必要な情報だけをAIへ渡す仕組みが必要なのです。

AIが正しく読めるデータ設計とは

では、生成AIを業務システムで活用する場合、どのようなデータ設計が必要なのでしょうか。

重要なのは、単純にデータを整理することではありません。

「将来的に誰が、どのような目的で、このデータを利用するのか」まで考えて設計することが重要です。

データの意味を明確にする

最初に必要なのは、それぞれのデータが何を意味するのかを明確にすることです。

たとえば、「売上」という項目一つをとっても、

• 受注時点の金額
• 契約金額
• 売上計上額
• 請求金額
• 入金済み金額

では意味が異なります。

人間同士であれば「このシステムの売上は請求金額のこと」と暗黙的に理解しているかもしれません。

しかし、生成AIに利用させるのであれば、このような暗黙知に依存しないデータ管理が重要になります。

表記や入力ルールを統一する

データの表記揺れもAI活用を難しくする原因になります。

たとえば、同じ会社が、

「ABC株式会社」
「（株）ABC」
「ABC」

と別々に登録されていれば、それぞれを同一企業として扱えない可能性があります。

会社名だけで判断するのではなく、一意のIDによって管理するなど、データ同士を正しく関連付けられる設計が必要です。

データの関係を明確にする

業務データは単独で存在しているわけではありません。

「顧客」に「商談」があり、「商談」に「見積」があり、「見積」から「契約」が生まれる、といったように、それぞれの情報には業務上の関係があります。

生成AIに高度な回答をさせるためには、この関係を正しくたどれることが重要です。

単に大量のデータをAIへ渡すのではなく、必要なデータへ正確にアクセスできる状態を作ることが求められます。

既存システムが「人間が使うこと」だけを前提にしていないか

生成AI時代のシステム開発では、もう一つ重要な視点があります。

それは、業務システムの利用者が人間だけではなくなる可能性があることです。

従来の業務システムでは、人間が画面を見て、情報を読み取り、必要な操作をすることが基本でした。

そのため、多少データの意味が曖昧でも、担当者の経験によって補完できるケースがありました。

しかし、生成AIが業務システムに組み込まれると、AI自身がデータを検索し、複数の情報を参照し、その結果を利用者へ提示するようになります。

つまり、これからの業務システムでは、

「人間にとって使いやすいか」

だけでなく、

「AIにとってデータを利用しやすいか」

という視点も必要になります。

生成AIを後付けするより「AI活用を前提」にシステムを考える

既存の業務システムに生成AIを追加すること自体は可能です。

しかし、既存システムのデータがAI活用を想定して管理されていなければ、生成AIとの接続部分だけを開発しても十分な効果を得られない場合があります。

そのため、新しい業務システムを開発するときには、現在必要な機能だけでなく、将来的なAI活用まで想定してデータを設計しておくことが重要です。

たとえば、現在は担当者が顧客情報を検索するだけのシステムでも、将来的には生成AIが、

「解約可能性が高い顧客を抽出する」

「過去の商談履歴を要約する」

「問い合わせ内容に応じて必要な情報を提示する」

「類似案件を検索して担当者に提案する」

といった役割を担うかもしれません。

こうした活用を想定していれば、システム開発の段階からデータの持ち方や関連付け方を考えることができます。

フルスクラッチ開発とAI時代のデータ設計

AI活用を前提とした業務システムでは、自社独自の業務をどこまでデータとして表現できるかが重要になります。

企業によって、顧客の定義、商談の進め方、承認ルール、価格決定の方法、契約条件、在庫管理、原価計算などは異なります。

特に、その企業の競争力につながっている業務ほど、一般的なパッケージの標準機能だけでは表現しきれないケースがあります。

フルスクラッチ（オーダーメイド）のシステム開発では、自社の業務フローや将来的な事業展開を踏まえて、必要な機能だけでなく、「どのようなデータを、どの粒度で、どのように蓄積するか」から検討できる点が大きな特徴です。

これは生成AIとの連携を考える場合にも重要です。

AI機能を追加すること自体を目的とするのではなく、

「将来AIにどのような判断を支援させたいのか」

「そのためには、今から何をデータとして残す必要があるのか」

「どの業務システムのデータと連携する必要があるのか」

まで逆算して設計することで、AIを実際の業務に活用しやすくなります。

AI導入プロジェクトではシステム開発会社の選び方も変わる

生成AIを組み込んだ業務システムを開発する場合、AIに詳しいかどうかだけでシステム開発会社を選ぶのは十分とはいえません。

重要なのは、業務そのものを理解し、必要なデータを整理できるかという点です。

なぜなら、生成AIに何を回答させるべきかを決めるには、その企業の業務を理解する必要があるからです。

営業支援システムであれば、どの情報が営業判断に必要なのか。受発注システムであれば、どのタイミングでどのデータが確定するのか。顧客向けサービスであれば、どの情報をどこまで利用者に提示してよいのか。

こうした業務上の前提を整理したうえで、データ設計、権限管理、外部システム連携、AIとの接続方法などを決めていく必要があります。

生成AI時代には、単に「AI機能を開発できる会社」ではなく、業務とデータとシステムを一体として考えられるシステム開発会社を選ぶことが重要になります。

まとめ

生成AIを業務システムに導入する際、成果を左右するのはAIモデルの性能だけではありません。

AIが参照するデータの意味が曖昧だったり、同じ情報が複数の名称で管理されていたり、必要なデータ同士を正しく関連付けられなかったりすれば、高性能な生成AIを導入しても十分に活用できない可能性があります。

投資信託のデータをめぐる課題は、生成AI時代におけるデータ設計の重要性を分かりやすく示す例といえます。

これからの業務システムでは、人間が操作しやすいことに加えて、AIが必要なデータを正確に取得し、その意味を適切に扱えることも重要になります。

生成AIを導入してからデータの問題に気付くのではなく、将来AIに何をさせたいのかを考え、そこから逆算して必要なデータを蓄積していくことが重要です。

生成AI時代のシステム開発では、「どのAIを使うか」だけでなく、「AIに何を読ませるか」「そのデータをどう作り、どう管理するか」まで含めて設計することが、AIを実際の事業価値につなげるための重要なポイントになります。

さいごに

生成AIを業務で活用するうえで重要なのは、AIを導入すること自体ではありません。AIが必要な情報を正しく参照し、業務に役立つ回答や提案につなげられるよう、データの持ち方まで含めてシステムを設計することが重要です。

特に、企業独自の業務ルールや判断基準、長年蓄積してきたノウハウは、汎用的なパッケージでは十分にシステムへ反映できない場合があります。将来的なAI活用まで見据えるのであれば、「現在どのような業務を行っているか」だけでなく、「どのデータを蓄積し、将来どのように活用したいか」まで整理したうえでシステムを作る必要があります。

当社フレシット株式会社では、フルスクラッチ（オーダーメイド）のシステム開発を専門としており、お客様ごとの業務や事業の特性を踏まえたシステムをご提案しています。決められた機能に業務を合わせるのではなく、実際の業務フローや必要なデータ、既存システムとの連携、将来的な機能拡張まで考慮して、一社一社に合わせたシステムを設計・開発できることが当社フレシット株式会社の強みです。

「生成AIを活用したいが、自社のデータをどのように整備すればよいかわからない」「既存システムではデータが分散しており、AI活用まで進められない」「将来のAI活用を見据えて業務システムを新しくしたい」といった段階からでもご相談いただけます。

生成AIを単なる便利な機能として追加するのではなく、自社に蓄積されたデータを将来の競争力へつなげる業務システムを作りたいとお考えでしたら、ぜひ当社フレシット株式会社へご相談ください。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら