AIエージェントの集計｜用語と単位をそろえる
AIがデータを正しく取得できても、「売上」や「件数」の意味が違えば答えはそろいません。AWSの11月3日の技術解説を手がかりに、業務用語・計算単位・期間・集計方法を定義し、担当者と照合する手順を整理します。
AIエージェントに「今月の売上を教えて」と頼んだら、営業会議で使っている数字と違う答えが返ってきた。接続先も計算処理も動いているのに、なぜ差が出るのでしょうか。
確認したいのは、AIが読み取ったデータの意味です。受注金額を足すのか、入金済みの金額を足すのか。一行は注文一件なのか、商品の明細一件なのか。同じ言葉で、同じ対象・単位・期間を数えているかをそろえる必要があります。
2026年11月3日、AWSはEDB Postgres AIとAmazon Bedrock AgentCoreを組み合わせ、データの意味をAIへ伝える構成の技術解説を公開しました。本記事ではその考え方を、企業担当者が集計業務をAIに任せる際の確認手順へ置き換えます。以下の金額や受付業務は説明用の仮想例であり、IvyLeapの導入実績ではありません。
AWSの解説が扱う「意味を伝える層」とは
AWSの記事は、AIが質問から問い合わせを作る部分、データの意味を伝える部分、実行やアクセスを管理する部分を分けています。紹介された構成では、データベースの表や列への説明、表同士のつながり、業務上の定義を使って、AIが参照先を選べるようにします。AWS公式解説
ここで大切なのは、列の名前だけから意味を推測させないことです。AWSの例も、価格の列を単価と読むか、注文の合計額と読むかで集計が変わる点を示しています。これは技術構成の解説であり、11月3日を各製品の新規提供開始日とする案内ではありません。
EDBの公式資料は、こうした仕組みが表・列・説明などの構造を検索するもので、文書や行の内容を検索する知識ベースとは対象が異なると説明しています。業務用語の意味を整える作業と、資料を検索できる状態にする作業を分けて考えます。EDB公式資料：Semantic knowledge bases
まず一つの数字について、定義を書き出す
全社の用語を一度に整理するより、実際にAIへ質問したい数字を一つ選びます。「今月の売上」であれば、担当部署が日常的に使っている集計の基準を確認します。
定義に残したい項目は、次の五つです。
- 対象：どの部門、取引、状態の記録を含めるか。
- 値と単位：金額か数量か、明細の値か注文全体の値か。
- 期間：受注日・出荷日・入金日など、どの日付で区切るか。
- 除外と調整：取消、返品、重複、未確定の記録をどう扱うか。
- 確認先：定義を決める部署と、変更を確認する担当者。
例えば「今月」が、今日までの暦月なのか、締め日を基準にした期間なのかで、集計対象は変わります。AIがもっともらしい解釈を選ぶ前に、業務側の基準を明示します。
質問に複数の意味が残る場合は、確認してから集計するか、回答に採用した定義を添えるかを決めます。「何を数えたか」を見えなくしたまま、数字だけを返す設計を避けます。
単価と合計額、注文と明細を取り違えない
仮に、ある注文の合計額が30,000円、数量が3と記録されているとします。金額の列がすでに注文全体の合計を表しているなら、さらに数量を掛けると90,000円になり、意図した集計から外れます。この金額は説明用に作った例です。
また、注文一件に三つの明細があり、注文の合計額が各明細に繰り返し表示されている場合、行をそのまま足すと同じ注文を重ねて計上する可能性があります。
開発担当者には、「この表の一行は何を表していますか」「別の表と結び付けたとき、行数は増えませんか」と確認します。集計元の項目名だけでなく、一行の単位と結び付け方を見てもらうことが重要です。
確認用の少数データでは、担当者が注文IDごとの正しい結果を計算し、AIが使った対象と照合します。合計が一致しただけで終えず、相殺する誤りや、同額の別注文が混ざっていないかも見ます。
共通の定義を、複数のAIや画面から参照する
同じ「売上」の定義を、部署ごとのプロンプトへ別々に書くと、修正漏れを管理しにくくなります。業務側で合意した定義を、どこを基準に保守するか決めます。
AWSの構成は、業務用語をデータベースのビューとその説明で表す方法を紹介しています。ビューは、元の記録から必要な項目や計算結果を取り出すための、名前を付けた参照先と考えると分かりやすいでしょう。AWS公式解説：業務定義の配置
自社で同じ製品構成を採る必要があるとは限りません。既存の業務システムが提供する集計機能や、管理者が保守する定義済みの参照先を使えるか、まず確認します。AI向けに複製した計算式と、会議資料の計算式が別々に更新されない仕組みを選びます。
導入時には、用語の説明を渡すことに加えて、その説明に対応した集計処理が使われたかを確かめます。用語集を読めた表示だけでは、計算方法まで一致したとは判断できません。
AIコールセンターでも「一件」の意味をそろえる
この確認は、金額の集計に限りません。AIコールセンターで「今週の未解決件数」を聞く場面でも、通話の本数、問い合わせ案件の数、顧客の人数は別の指標です。
例えば、一つの問い合わせについて、最初の電話と折り返しで二回通話する仮想例を考えます。通話の数は二本でも、問い合わせ案件は一件として扱う業務かもしれません。反対に、一回の電話で複数の用件を受け付ける場合もあります。
定義を作る際は、何を一件とするか、どの状態で解決と扱うか、後で再開した案件をどの期間に含めるかを決めます。そのうえで、通話ID・案件IDなど、どの単位で集計したかを確認できるようにします。
応対品質と実際の処理結果の測り分けは、AIコールセンターの業務成果で扱っています。本記事の焦点は、測定に使う言葉と計算単位をそろえることです。
定義を変えるときは、過去との比較条件も残す
業務の変更で、集計の定義を見直すことがあります。その場合は、変更日、適用するデータの期間、変わった条件、確認者を記録します。
例えば「未解決」に保留中の案件を含めるよう変更したなら、変更前後の件数の差には、業務の変化と定義の変化が含まれる可能性があります。数字が増減した理由を、AIの改善や悪化だけで説明しません。
過去の数字を新しい定義で計算し直すのか、以前の定義のまま表示するのかも決めます。同じ表に並べる場合は、担当者が比較条件を確認できるようにします。
検索できる範囲と実際の利用者の権限については、AIエージェントの検索権限も併せて確認してください。共通の業務定義を使っても、全員に同じデータを見せる必要があるわけではありません。
導入前に試したい六つの場面
架空のデータを使い、担当者が正解を説明できる小さな範囲から確かめます。
- 単価と注文合計が異なる。 数量を二重に掛けず、合意した列と計算方法を使えるか。
- 一つの注文に複数の明細がある。 表の結び付けで行が増えても、同じ注文を重ねて数えないか。
- 期間の境目に記録がある。 採用する日付と締めの条件に従って含められるか。
- 取消や未確定の記録がある。 合意した除外条件が、実際の対象へ反映されるか。
- 同じ言葉に複数の意味がある。 必要な確認を行うか、採用した定義を回答に明示できるか。
- 業務定義を変更する。 新しい計算と過去の計算を区別し、比較条件を追えるか。
結果には、質問、用語の定義、対象のID、採用した日付、計算方法、担当者の期待値、AIの回答を並べます。数字が合わない場合は、文章を言い換える前に、対象・単位・期間のどこが違うかを確かめます。
AIへ業務データをつなぐ準備では、何を読めるかと一緒に、読んだ値が何を意味するかを整えることが大切です。まずは会議でよく使う指標を一つ選び、担当者と開発者が同じ説明で計算できるか確認してみてください。
IvyLeapのAIエージェント構築支援では、業務システムとの連携や確認手順を整理できます。AIに答えてほしい質問と、現在使っている集計基準をまとめて、お問い合わせください。
※AWS記事の掲載日は2026年11月3日。AWS・EDBの公式資料は11月4日に確認しました。紹介された技術構成の動作を、IvyLeapの環境で検証したという意味ではありません。