表計算の「数字は合うのに間違っている」をAIで見つけられる？集計の意味を確かめる方法

内容確認：2026年10月10日。実際の公開日：2026-10-10。

AIは、表計算の集計で「数字は合うのに意味が違う」という問題を探す補助に使えます。ただし、何の数字を、どの期間、どの単位、どの状態で数えるかを渡さなければ、合計だけを見て業務上の正しさまで判定することはできません。 AIの指摘も候補です。元の行と集計の定義へ戻って確かめてから修正します。

たとえば、今月の入金額を知りたいのに、今月の申込額を足していた場合。足し算は正しくても、資金を確認する数字にはなりません。同じ金額の行が二つある場合も、重複入力なのか、二つの別の取引なのかは、金額だけでは決まりません。

この記事では、架空の小さな台帳を使い、計算の正しさと集計の意味を別々に点検します。難しい関数を増やす前に、集計の問いを一文にし、対象行と除外行の理由を残し、AIの指摘を人が判断できる形にする方法です。

台帳、団体、取引、金額、誤りの例はすべて説明用の架空データです。AIを実際に比較した実験結果、顧客の帳簿、経理上の正式な処理基準、節約時間の実測ではありません。金額の計算例はこの架空設定だけのもので、税務や会計の判断には使いません。

内容確認日：2026年10月10日。

計算が合っているのに、集計が間違うのはなぜですか？

表には二つの確認があります。一つは「選ばれた数字を正しく計算したか」。もう一つは「選ぶべき数字を選んだか」です。前者が合っていても、後者が違えば、知りたい問いへの答えにはなりません。

9月の入金を知りたいのに申込日で9月を選ぶと、9月に申し込んで10月に入金したものを含み、8月に申し込んで9月に入金したものを除いてしまいます。計算式を別の方法で再計算して同じ合計になっても、対象期間の定義が同じ誤りなら見逃します。

「Excelの合計とAIの合計が同じだった」という確認にも、この問題があります。AIへ合計対象の列だけを渡し、同じ対象を足すよう頼めば、同じ数になることはあり得ます。しかし、なぜその行を含むかは確かめられていません。

まず、集計を質問の形で言い直す

「9月売上」「今月実績」「件数」といった見出しは短い半面、意味を隠しやすい言葉です。「9月中に参加した人が何人か」「9月中に新しく申し込まれた件数か」「9月中に入金された金額か」は別の問いです。

次の一文を埋めるところから始めます。

この集計は、［誰／何］について、［いつ］の、［どの状態］にある記録を、［一件の定義］で選び、［単位］で［何の判断］に使う数字です。

すべてを長い見出しへ詰める必要はありません。表の上に短い名称を置き、その下か別の定義欄に条件を残します。数字を使う人が定義へ戻れることが大切です。

三つの「正しい」を区別する

これはこの記事で提案する整理です。組織の正式な監査分類ではありません。三つを分けると、「関数を直したので終わり」として、元データや条件の問題を残すことを避けやすくなります。

実例：架空の申込台帳で、何を数えるかを決める

架空の地域講座で、受付担当が「2026年9月に入金を確認した参加費の総額」を作るとします。対象の講座は一つ、通貨は日本円、ここでは金額を額面どおりに扱います。返金の処理、税、会計への計上はこの例の対象外です。

今回の定義

この例の問いは、次のように固定します。

目的：受付の入金確認状況を内部で見るための数字。
対象：2026年9月1日以上、2026年10月1日未満に入金確認した取引。
状態：入金確認済のみ。未入金・取消は含めない。
一件：入金取引IDが同じ記録を、一つの入金として扱う。
単位：円。同じ列に千円が混じっている場合は、そのまま足さない。
材料：この架空台帳と、その項目定義。
不明：入金日・単位・取引の同一性が確かめられない行は要確認。
修正：元台帳を上書きせず、確認表に候補と理由を書く。

ここで「入金確認日」は受付が確認した日という、この架空設定の名称です。実際の業務では着金日と確認日が違うことがあります。そのどちらを採るかは、利用目的に合わせて人が決めます。都合よく同じものとして扱わないでください。

問題を説明するための台帳

行番号R01などは、この説明で元へ戻るための識別子です。実際のExcelの行番号ではありません。

R02とR05は同じ取引の再取込、R07は同額でも別の取引という設定を、説明のために明示しています。実務で同じ見た目の行を見つけたとき、こうした説明が自動で分かるわけではありません。取引IDや元票の確認が必要です。

この定義に従う対象は、R01、R02、R06、R07の四つの取引です。R06を8,000円として扱えると確認した場合の合計は、4,000＋6,000＋8,000＋6,000＝24,000円です。単位の確認ができなければ、R06を勝手に換算せず、他の三取引16,000円と要確認の8千円を分けます。

全部足すと「32,008」になる

記載額の列をそのまま足すと、32,008になります。この足し算自体に間違いはありません。しかし、「円」と「千円」を混ぜており、9月の入金以外も含み、同じ入金を二度数えています。32,008に「円」という見出しを付けるだけでは正しくなりません。

ここには、計算結果へエラー表示が出ない誤りが複数あります。行を増やして高度な式で合計しても、定義を直さなければ同じ問題を大きくするだけかもしれません。

申込日で絞ると、別の数字になる

9月の申込日だけで絞り、状態を区別せず記載額を足すと、R01が抜け、残る七行は28,008です。これも選ばれた列の足し算としては合っています。入金確認額という問いには、前月申込の9月入金が抜け、10月入金や未入金、取消が入っています。

「先月より増えた」という文章をAIに書かせる前に、この数字がどの集団を表すかを確認します。意味が違う数字をグラフにすると、見た目が整うほど誤解を広げる場合があります。

AIへ表を渡す前に、何を準備しますか？

AIへ渡したいのは、行だけでなく、行の読み方です。列名が「日付」「金額」「区分」だけでは、どの日付か、何の金額か、どの区分が対象かが分かりません。

実データを使う場合は、利用するサービスと組織の情報管理ルールに従い、入力してよい項目と範囲を先に確認します。この記事の練習は架空データでできます。氏名、連絡先、顧客の事情、振込情報などを追加して練習する必要はありません。

項目辞書を作る

辞書は大げさな文書でなくても構いません。一行の説明を付けるだけでも、AIが列名から推測する箇所を減らす材料になります。人にも、集計の条件を確認しやすくなります。

元データ、表示、式を別の材料として渡す

画面のスクリーンショットだけでは、見えていない行、数式、セルの型、非表示の列を確認できません。画像を読めるAIであっても、画面にない情報を確かめたことにはなりません。

CSVや貼り付けた表も、元ブックのすべてを残すとは限りません。日付の型、式、表示形式、シート間の参照、更新日時など、点検に必要な材料を別に説明します。「このCSVだけでブック全体の正しさを証明してください」という依頼は避けます。

この記事の小さな例では、貼り付けた値と辞書だけを点検対象にします。実際のブック全体を検証したとは扱いません。まず範囲を明示することが、確認できたこととできていないことを分ける入口です。

正解を先に固定する

練習用の表では、問題を入れる前の正しい対象行、除外理由、単位、合計を別の答え表に残します。AIが出した値を後から正解にしてはいけません。

実務では正解そのものが不明な場合があります。そのときは、確かな元票と正式な集計定義へ戻り、どの条件が決まっていないかを整理します。AIの回答同士が一致することを、定義が確定した証拠にはしません。

AIには「合計して」より、どんな問いを渡しますか？

一度に「確認して直して」と頼むと、指摘と修正の間にある判断が見えにくくなります。まず対象と除外、次に疑いのある箇所、最後に修正候補という順番に分けます。

依頼1：対象行と除外理由を出す

次の文はこの記事で作った依頼例です。特定のモデルでの動作を保証するものではありません。

この架空台帳を点検してください。元表は変更しません。

知りたい数字：2026年9月に入金確認した参加費の総額。
対象期間：2026-09-01以上、2026-10-01未満。
対象状態：入金確認済。
一件の定義：入金取引IDごとに一件。
単位：円。千円の行は単位確認が必要です。

まず各行を「対象候補」「対象外」「要確認」に分けてください。
理由には、参照した列と値、対応する定義を書いてください。
同じ金額だけを根拠に重複と決めないでください。
材料から分からないことは未確認と書いてください。
まだ合計を一つに確定しないでください。

最初から合計を求めないのは、足す前の選び方を見るためです。R06の単位が不明なら、未確認のまま合計を分けてよいと伝えます。「必ず一つの数字を出す」が条件になると、判断できない行を無理に扱う原因になります。

依頼2：指摘を、証拠と不明点へ分ける

指摘候補を次の列で一覧にしてください。
行ID／疑いの種類／表で確認できる事実／
表だけでは確認できないこと／照合した定義／次に見る材料。

「重複に見える」と「同じ取引と確認した」を分けてください。
「日付が範囲外」と「業務上除外すべき」を分けてください。
金額を推測して書き換えないでください。

「R05は誤りです」という答えだけでは、承認しにくいものです。「入金取引IDと元票がR02と同一という設定により、同じ入金の再取込と判断できる」と理由が残れば、どこを人が確認すべきか分かります。

依頼3：修正候補を別表へ置く

確認済みの判断だけを使い、集計用の別表案を作ってください。
元の行IDと元の記載額は保持してください。
採用／除外／保留、採用理由、正規化後の金額、単位の根拠を別列にします。
元データを削除する案は作らず、集計から除外する案にしてください。
未確認の行は保留して、確定分と保留分を分けて表示してください。

これらの文を使っても、誤りがなくなるとは限りません。依頼の目的は、AIの結論を信用する理由を作ることではなく、結論を元へ戻して確認できる形にすることです。

架空台帳では、どの指摘を採用し、どれを保留しますか？

次の点検表は、人が説明用に作ったものです。実際のAIの回答を編集した表ではありません。

R03のデータが間違っているとは言っていません。入金確認日は10月1日で正しいかもしれません。今回は9月の集計に含めないという判断です。「対象外」と「誤入力」を同じラベルにすると、正しい履歴を壊すおそれがあります。

R04やR08も、行が存在すること自体は誤りではありません。申込の管理には必要な行です。入金集計の対象でないというだけです。集計に合わせて元台帳を削るより、問いに合わせて対象を選びます。

R05を除外してよいのは、同一取引の根拠があるから

同じ申込IDでも、分割して二回入金している業務なら別の取引かもしれません。同じ入金取引IDでも、登録ミスで別の入金へ同じIDを付けた可能性は、実務では検討が必要です。

この例は同じ受付票の再取込という設定があるので、同一と判断できます。実務でその材料がない場合は、「IDが同じ」「日付が同じ」「金額が同じ」を疑いの根拠として残し、元票や登録経路で確認します。

R07を残すことも、点検の重要な成果

AIが「6,000円の行は重複です」と広く指摘すると、R07まで削るかもしれません。指摘が多いほど良い点検とは言えません。正しい行を残せたかも見ます。

誤りを探すときは、「これは正しいが怪しく見える」という反例を用意します。同額の別取引、期間境界の正しい行、意味のある空欄などです。その反例にまで修正を求めるAIなら、確認者の負担が増えることがあります。

集計式は、何を確認してから使えばよいですか？

式は定義を実行する道具です。式が書けたことと、業務の問いが決まったことを分けます。ここではExcelとGoogle Sheetsの公式案内で確認できる関数の範囲を参考にしながら、独自の練習例を考えます。

MicrosoftのSUMIFS案内では、複数の条件に合う対応する値を合計する関数として説明されています。合計範囲と条件範囲を対応させる必要があります。これは条件を指定する機能であり、どの条件が業務上正しいかを決める機能ではありません。Microsoft：SUMIFS function

Google SheetsにもSUMIFSの公式案内があり、複数の条件による合計と引数の構造が説明されています。今回の「期間と状態で対象を選ぶ」という考え方は、特定のAIや表計算ソフトだけに限定しません。Google：SUMIFS function

条件を列に書き出してから式にする

架空の集計用別表では、元の値を残し、次の列を追加する方法があります。

すべてを一つの長い式へ押し込むと、誤りがどの条件から来たか読みにくくなる場合があります。途中の判定を見える列にすると、人が対象行を確かめやすくなります。ただし、列を増やすだけで質が上がるわけではなく、確認する人が分かる名称を付けることが必要です。

独自の練習式

次の式は、この記事で作った集計用別表を想定します。H列を確認済みの正規化額円、E列をExcel上の日付値の入金確認日、F列を状態、I列を人が承認した採用区分とします。2〜9行だけを対象にする架空例です。

=SUMIFS(H2:H9,E2:E9,">="&DATE(2026,9,1),E2:E9,"<"&DATE(2026,10,1),F2:F9,"入金確認済",I2:I9,"採用")

文字の「2026-09-02」がそのまま貼り付いているだけなら、日付値として扱われるとは限りません。ここでは日付値を入れた練習表という前提です。実際のデータで使う前に、日付と数値の型、範囲、地域設定、結果を確かめます。

この式には、重複の判断を自動で行う処理はありません。I列で採用区分を決める前の確認を省くと、同一取引が二度足されます。式の見た目を複雑にしても、元票の確認を代わりに済ませたことにはなりません。

同じ対象で二度計算するより、対象を違う経路で確かめる

式と手計算で24,000円が一致したら、選んだ四取引の足し算については確認が増えます。対象の選び方には、別の点検が必要です。

一つは、行ごとに期間、状態、取引の同一性、単位を見る点検。もう一つは、対象期間の入金元票を起点に、台帳へ全部たどれるかを見る点検です。台帳から元へ戻るだけだと、台帳にない元票を見つけられません。

実務の正式な照合方法は対象の業務で決めます。小さな練習でも、選ばれた数字の一致と、必要な記録が揃っている確認を別にすると、「合計が同じだから全部正しい」という飛躍を防ぐ考え方になります。

重複、期間、単位の誤りは、どの順番で見るとよいですか？

この記事では、元の値と意味を確認し、対象を選び、最後に合計する順番を提案します。これはすべての業務に共通する唯一の順序ではありません。点検の途中で条件が変わったら、前の段階へ戻る必要があります。

1．単位を揃える前に、単位が分かるかを見る

「8」は円なのか千円なのか、8人なのか8件なのか。列名だけで分からない場合は、資料の説明や元様式を見ます。AIが周囲の数字から推測して「8,000円」と埋めても、根拠にはなりません。

確認できた換算は、元の値、元の単位、換算後、換算根拠を残します。元の8を消して8,000へ上書きするより、どこで変えたか分かる別列を使う方法があります。確認できない場合は保留します。

単位が明確でも、税込と税抜、総額と差額、数量と人数は別の意味です。本記事の例では税を扱いませんが、実務で「金額」列を一緒にする前に、何の金額かを確かめる必要があります。

2．一件を決めてから、重複を探す

参加人数を知りたい表で、申込IDの数を数えても、一つの申込に複数人が含まれれば人数になりません。反対に入金回数を知りたいとき、同じ人の二回の入金を一回へまとめると対象が変わります。

重複とは、同じ値が並ぶことではなく、今回一つとして数える事実を二度数えることです。一件の定義が曖昧なら、どの重複を除くべきかも曖昧です。

Microsoftの重複確認の案内は、重複が役立つ場合もあること、強調表示して確認できること、重複削除ではデータが削除されることを説明しています。練習でも元の表を保持し、まず候補の確認に留めます。Microsoft：Find and remove duplicates

3．日付の種類と境界を決める

「9月」だけでは、申込、提供、請求、入金、受付確認のどの日付か分かりません。対象の日付列を名指しします。開始と終了の含み方も決めます。

日付だけの小さな例では「9月1日以上、10月1日未満」と書くと、期間の入口と出口を説明しやすくなります。時刻付きのデータでは、「9月30日まで」が30日の午前0時を意味していないかにも注意します。時間帯の違うシステムをつなぐ場合は、その扱いも別途確認します。

境界の確認は大量のデータがなくてもできます。8月31日、9月1日、9月30日、10月1日という四つの架空行を作り、どれを含むか先に決めて、式と照合します。時刻付きなら境界前後の記録を追加します。

4．状態を決めてから集計する

申込済、承認済、提供済、入金済という状態は、業務の段階を表します。「完了」の意味が担当者ごとに違えば、同じ表でも対象が変わります。

たとえば制作担当には納品した時点が完了でも、受付担当には顧客の確認を受けた時点が完了かもしれません。表の状態をAIに整えてもらう前に、何を表す状態かを確認します。未入金と取消をまとめると、次に連絡する対象が変わる可能性があります。

フィルターや非表示の行は、どう扱えばよいですか？

表の画面から消えた行と、集計から除外された行は同じとは限りません。画面に見える合計を読むときは、どの範囲と関数を使ったかも確認します。

MicrosoftのSUBTOTAL案内では、フィルターで除外された行を計算に含めないこと、手動で非表示にした行の扱いは関数番号によって異なることが説明されています。見た目の非表示だけで判断せず、使用した関数の仕様へ戻ります。Microsoft：SUBTOTAL function

この機能を使うかどうかは、集計の目的で決めます。画面に見える絞り込みの結果を知りたいのか、全体の正式な対象を知りたいのかが違うからです。フィルターの操作がそのまま集計定義になる設計なら、その条件も記録する必要があります。

「見えている行だけ」の依頼には限界がある

スクリーンショットに六行が見えている場合、AIが六行の値を足すことはできるかもしれません。しかし、元台帳にほかの行があるか、表示外に対象が残っているかは、画面だけでは分かりません。

確認の結果には、「提供された六行について確認した」「元ブックの全件については未確認」と範囲を残します。これを「台帳の合計は正しい」へ言い換えると、確認した範囲が広がってしまいます。

集計条件の保存と、画面の見やすさを分ける

作業用の画面では、見たい行だけへ絞ってもよい場面があります。提出する数字は、誰が開いても同じ条件になる方法で作る必要があります。画面操作の記憶だけに頼ると、翌日に同じ数字を再現できないかもしれません。

採用区分を列へ残す、条件を表の上へ書く、集計時点を記録するなど、再現できる材料を残します。方法は一つではありません。読む人が条件を知り、作る人が再計算できることを目標にします。

AIの誤指摘を信じて、正しい数字を変えないためには？

「間違いを探してください」という依頼は、正しい行も疑いに見せることがあります。モデルごとの発生率をここで断定するのではなく、指摘が間違う可能性を点検に組み込みます。

指摘を三段階に分ける

「AIが誤りと言った」という一つの欄を作るより、何の根拠で、何がまだ分からないかを残します。指摘候補を人が採用した理由も別に書きます。

元データを触らない試行にする

まず練習用のコピーか別表で候補を試します。元データは保持します。別表でも、対象から外した理由と元の識別子を残します。正しい行を誤って除外しても、戻れるようにするためです。

この手順は、保存義務や正式な処理のルールを置き換えるものではありません。正式な帳簿や業務システムを変更する場合は、定められた承認と訂正手順を使います。この記事の点検表は、判断材料を作る補助です。

人の反対意見も、理由で確認する

AIが「R07は重複」と指摘して、人が「いつもこの金額だから大丈夫」と返すだけでは、根拠が揃いません。人の思い込みをAIの思い込みと入れ替えるだけになるからです。

「R07はP005という別の入金で、元票もR02と異なる」と、今回の一件の定義に沿って確認します。AIの指摘にも、人の拒否にも、同じ根拠の基準を使います。

不明を残した出力を採用できるようにする

表が不完全なとき、AIが「要確認」と出した結果を失敗として扱うと、担当者は無理に答えを作りたくなります。確定分と不明分を分ける出力なら、そのまま確認の仕事へつなげられます。

「確定済み16,000円、単位確認待ち1取引、未確認の値8千円」という説明は、確認前に24,000円と断定するより、現在の状態を正しく伝えます。確認後に24,000円へ更新したときは、何を確認したかも残します。

誤り注入の比較実験では、何を確かめますか？

ここからは未実施の比較計画です。実際のAIの成績を示すものではありません。自分の環境で小さく試すために、同じ表と正解表を使い、依頼の条件だけを変える方法を提案します。

基準になる表と、問題を入れた表を分ける

基準表には、正しい四取引を円に揃えて記録します。そこから別のコピーへ、重複、対象期間のずれ、単位のずれを一つずつ入れます。何を入れたかを答え表へ残し、AIへ渡す点検用の表には正解を含めません。

三つの誤りを最初から同じ表に入れると、どの変化で指摘が変わったか分かりにくくなる場合があります。まず一種類ずつ、次に組み合わせて試すと、確認の弱い箇所を見やすくなります。

この記事のR01〜R08表は説明用に複数の問題を一緒に示しました。比較実験で使う場合は、元の四取引と除外行の扱いを先に固定し、どのコピーへどの問題を入れたかを記録してください。

依頼の三条件

Aが必ず悪くCが必ず良いという結果は、まだありません。BやCでも誤指摘が増えるかもしれません。比較の目的は「一番長いプロンプトが勝つ」と示すことではなく、何の情報を渡すと、どの確認が変わるかを見ることです。

正しいのに怪しく見える行も入れる

重複を入れた表だけでは、全部を重複と呼ぶ点検でも当たりが増えます。R07のような同額の別取引を残します。期間の境界では、9月1日と9月30日の正しい対象も入れます。単位では、正しい小額の円も入れます。

「8円は小さすぎるから8,000円に直す」と指摘するなら、単位を数字の大きさから推測している可能性があります。小額の正しい取引を用意すると、その点を確かめる材料になります。

記録する指標

検出数を数える前に、何を一つの問題として数えるか決めます。重複の行を二つ指摘して一つの同一取引問題を二件と数えると、条件間の比較が歪みます。

「誤りがある」と気づいたことと、「どこをどう直すかまで正しい」ことも別です。単位の問題を見つけたAIが、円と千円の換算方向を反対にするかもしれません。修正候補まで採点する場合は、別の欄にします。

少数の練習から、AI全体の能力を断定しない

一つのモデル、一つの表、一回の依頼での結果は、その試行の記録です。「AIは表計算の意味を理解できる」「AIは経理に使えない」といった広い結論には足りません。

利用したサービス、モデルが分かる場合はその名称、実施日、入力、依頼、出力、確認結果を残します。モデル名が分からないサービスなら、分からないと記します。実施していない回数や時間を補いません。

合計が同じでも、対象が違う表を作って比べる

「数字が合うのに間違う」を体験するには、合計が変わらない反例が有効です。次は、意味の違いだけを見せるために人が作った架空の二表です。

二つの表の合計は同じです。もし「合計が24,000円なら正解」という採点だけをすると、両方が正解になります。しかし後者は取引の内訳が間違っています。

AIへ「合計に間違いはありますか」とだけ尋ねたら、足し算が合っているという答えになるかもしれません。「今回の対象取引が過不足なく一度ずつ含まれるか、取引IDを元表と照合してください」と問いを変えると、確認の対象が変わります。

内訳の一致を確かめる

必要なのは、合計の一致だけでなく、対象IDの集合と各IDの扱いの一致です。小さな表なら、取引IDを一覧にし、元票と集計表を一本ずつ照合できます。

大きな表で自動化する場合も、「同じIDが二度」「必要なIDが欠け」「不要なIDが追加」という三方向を確認する考え方は使えます。具体的な実装はデータ構造により異なります。AIにコードを作らせたら、そのコードがこの三方向を見るか、練習データで別途確かめます。

差額ゼロを合格条件にしない

過大な6,000円と不足の6,000円が相殺されれば、差額はゼロです。差額の確認は役立ちますが、相殺される誤りを見逃す可能性があります。

「差額がゼロ、内訳も一致、未確認なし」といった複数の条件へ分けると、数字だけ合った状態を区別できます。未確認が残るときは、差額ゼロでも未完了として扱う設計が必要です。

平均、割合、人数では、どんな意味のずれがありますか？

合計だけでなく、平均や割合でも、算式は正しく対象が違うことがあります。この記事では数学の複雑な説明より、分子と分母の問いを言い直す方法を使います。

平均の平均を、そのまま全体平均にしない

架空の二つの講座で、講座Aの回答者が2人で平均4、講座Bの回答者が8人で平均3とします。二つの平均を足して2で割ると3.5です。一方、全10人の回答を同じ重みで扱う平均は、合計点32を10人で割る3.2です。

3.5は、二つの講座の平均を同じ重みで平均した数字としては計算が合っています。3.2は、10人の回答を同じ重みで平均した数字です。どちらを知りたいのか、単位を人にするか講座にするかで答えが違います。

この数値は説明用の設定です。実際の調査ではありません。AIが「満足度は3.5」と書いたとき、何を一つとして平均したのかを確かめます。

割合は、何を分母にしたかを残す

「参加率80％」だけでは、申込者のうち参加した人数なのか、定員のうち埋まった席なのか、開催した回のうち参加した回数なのか分かりません。分子と分母を同じ対象と期間で説明します。

架空例で、申込10人のうち8人が参加したなら、申込者に対する参加割合は80％です。定員20人に対する参加人数の割合は40％です。同じ8人を使っても、問いが違えば数値が変わります。

AIに「分かりやすい割合にして」と頼む前に、読む人が何を判断する割合かを決めます。空席を考えるのか、欠席への対応を考えるのかで、必要な分母が違います。

延べ人数と実人数を混ぜない

一人が三回参加したとき、延べ参加人数は三、実人数は一という定義があり得ます。この二つの数字を同じ「参加者数」という列へ入れると、合計の意味が不明になります。

AIが重複除去した結果は、実人数を求めたいなら候補になりますが、延べ人数を知りたいなら必要な参加記録を消しているかもしれません。誤りに見える繰り返しが、問いにとって必要な事実という場合もあります。

修正後の表は、何を確認すれば完成といえますか？

合計が期待値になっただけでは、修正が正しいとは限りません。偶然同じ数字になった可能性もあります。対象、除外、保留、根拠が説明できるかを確かめます。

元の行へ戻れるか

集計用別表の一行から、元のR番号と元票をたどれるかを確認します。単位を変えた行には、元の値と根拠が残っているかを見ます。除外した行も、存在と理由を記録します。

元データが消えてしまうと、AIの指摘が間違っていた場合にやり直しにくくなります。履歴を残す方法はツールと運用によって違いますが、「何を変え、何を根拠に変えたか」という情報は必要です。

定義を変えずに、再計算できるか

対象期間、状態、一件、単位を再び読んで、同じ条件から同じ内訳を作れるか見ます。数字の一致に加えて、四つの対象取引が一回ずつ残るかを確認します。

別の担当者に渡せるなら、「元データと定義から対象を選び直す」確認が役立ちます。先に完成合計だけを見せると、その数字へ合わせようとする可能性があるため、確認の目的と材料を整理します。

次の行が入っても条件が保たれるか

毎月使う表なら、今回だけ正しくても、次に行を追加したとき範囲から外れるかもしれません。練習用コピーへ対象の一行、対象外の一行、保留の一行を追加し、扱いを確認します。

対象行が増えた分だけ合計に反映され、対象外と保留は勝手に混ざらないかを見ます。実際の提出済み表へ問題を入れて試す必要はありません。テスト用のコピーで行います。

訂正と条件変更を分ける

「R05の二重取込を除く」は、今回の定義のままデータの扱いを訂正する話です。「次月から入金確認日ではなく着金日で集計する」は、集計定義を変更する話です。

両方を「修正」とだけ書くと、前月の数字と比較できるか分からなくなります。何が変わったか、いつから効くか、過去分を再集計するかを別に決めます。AIが旧定義の表と新定義の表を同じ基準とみなして増減を説明しないようにします。

点検結果を、数字を使う人へどう伝えますか？

点検者だけが条件を知っていても、読む人が「9月実績24,000円」としか見ないと、別の意味で使うかもしれません。短い見出しと、使ってよい範囲、未確認をセットで伝えます。

架空の提出メモ

集計：2026年9月の入金確認額
結果：24,000円、四つの入金取引を対象
目的：架空講座の受付確認状況を内部で見る
期間：2026-09-01以上、2026-10-01未満の入金確認日
状態：入金確認済
除外：10月確認、未入金、取消、同一取引の再取込
単位：円。8千円の旧様式は確認して8,000円へ換算
未確認：この架空例では単位確認後を想定してなし
範囲：この記事の八行だけ。実際の元帳・会計・税務の確認ではない

これは長い注記に見えるかもしれませんが、数字を何に使うかを決める情報です。日常の報告では、表の上に短く条件を置き、詳細を別の確認メモへつなぐ方法もあります。

未確認がある場合の提出メモ

R06の単位を確認できない場合は、次のように分けます。

確定済みの対象：三取引、16,000円
保留：R06の一取引、元記載は8千円
確認すること：旧様式の単位と取引P004の元票
完成条件：確認した円換算額を反映し、四取引の内訳を再点検する

保留の金額を暫定で含める必要がある場合も、その運用は人が決めます。「暫定」「確認待ち」を見える位置へ置き、確定値と混同しないようにします。この記事の例では、無理に一つへまとめる必要がない設定です。

数字から文章へ変える段階も点検する

AIが集計結果を説明文へ変えるとき、「入金確認額」を「売上」、「申込件数」を「参加人数」と言い換えるかもしれません。文章が自然でも、数字の名称が変われば意味も変わります。

出力には集計名を固定して渡し、言い換えてよい表現と、変えてはいけない項目名を区別します。「24,000円だから好調」といった評価も、比較対象や目標がないなら材料から言えません。数値と判断を分けて確認します。

点検を続ける運用では、何を決めておきますか？

一度の点検を毎月の仕事へ変えるなら、誰が条件を決め、誰がデータを確認し、誰が数字の使用を承認するかを明らかにします。AIの役割は、候補を出す、行を整理する、差分を示すなど、確認できる単位へ分けます。

条件の版を残す

集計定義に「2026年9月版」などの識別を付け、変更日と変更理由を残します。日付の種類、一件の定義、状態区分が変わると、数字の比較にも影響します。

過去の数字を作り直すかどうかも別の判断です。AIが新しい条件を過去へ勝手に当てはめたり、旧条件を現行として使ったりしないよう、どの集計がどの定義で作られたかを記録します。

指摘の記録を、次回の材料にする

AIの指摘を採用したもの、拒否したもの、保留したものを残します。拒否した理由が「同額でも別の取引」なら、次回はその定義を先に渡せます。採用した理由が「単位の旧様式」なら、入力の段階で単位を揃える改善を考えられます。

ただし、一回の指摘から全体の原因を断定しません。旧様式が一つあったからといって、すべての入力ミスの原因が様式だとは限らないからです。まず確認できた範囲を記録します。

確認を減らす場所も考える

毎回同じ不明点をAIへ聞くより、入力項目を改善した方が役立つ場合があります。「金額」の隣に単位を必須で置く、「日付」を入金確認日へ名称変更する、一件を識別する項目を定義する、といった変更です。

変更は担当者が運用できる範囲で行います。入力を複雑にすれば、別の誤りが増える可能性もあります。項目を増やすことを目的にせず、どの判断を明確にしたいかを決めて試します。

AIなしでも点検できる状態を保つ

AIの利用が止まっても、項目辞書、集計定義、元データ、採用区分、確認履歴があれば、人が点検を続けやすくなります。AIとの会話だけに判断の根拠を置かず、正式な確認表へ残します。

担当者の頭の中にある暗黙の条件を文章へ出すことは、AIのためだけの準備ではありません。引き継ぐ人や、数字を読む人にも役立つ材料です。

読み手の問いから点検する、短い会話の例

次の会話は、集計の意味を確認するための架空のやり取りです。実際の利用者への聞き取りではありません。

管理担当：「9月の実績は24,000円ですよね。来月の講座を増やす判断に使えますか。」

受付担当：「この数字は9月に入金を確認した金額です。申込人数や参加人数、講座の利益は含めていません。」

管理担当：「では、参加した人数とは違うのですね。」

受付担当：「違います。前月申込の入金も入っています。参加人数を知るなら、参加記録から別の定義で集計します。」

管理担当：「AIが『今月の売上が増えた』と書いていたのですが。」

受付担当：「比較の材料も、売上の定義も渡していません。その文章は採用せず、今回確認した入金確認額へ戻します。」

この会話のポイントは、数字を否定することではありません。数字が答えている問いを明らかにし、答えていない問いへ流用しないことです。

よくある質問

AIにExcelファイルを渡せば、全部の間違いを見つけてもらえますか？

全部見つけられるとは保証できません。ファイルの読み取り範囲、シート、式、元資料、定義、使うサービスによって確認できることが違います。まず小さな対象を決め、「どの行とどの定義を確認したか」を結果に残します。

合計を電卓で確認すれば十分ではありませんか？

選んだ値を正しく足したかを見るには役立ちます。ただし、対象期間、一件の定義、単位、状態が違う問題は、同じ対象を再計算するだけでは見つかりません。対象IDと除外理由も確認します。

同じ金額と日付があれば、重複として消してよいですか？

それだけでは決められません。別の人が同じ日に同額を入金することもあります。一件の定義と取引識別子、元票、登録経路を確認します。まず候補として残し、元データを削除しない方法で試します。

単位が混じったとき、AIに揃えてもらえばよいですか？

単位の根拠が確かなら、変換案を作る補助に使えます。根拠がないときはAIに推測させません。元の値と単位を保持し、換算後の値と確認理由を別に記録します。

AIの回答が毎回違います。どれを選べばよいですか？

もっとも自然な文章や多数派の答えで選ばず、行と定義へ戻って照合します。違いが対象の選び方から来るのか、単位の推測から来るのか、計算から来るのかを分けます。定義そのものが曖昧なら、人が確定する必要があります。

AIに修正を任せず、候補だけ出させても意味がありますか？

候補が元の行と理由へつながっていれば、人の点検材料になります。役立つかどうかは、指摘の正しさだけでなく、誤指摘の数と確認負担も含めて小さく試します。候補が多いこと自体を成果にはしません。

本文の24,000円は、AIが実際に出した数字ですか？

違います。架空の四取引を用いた、人が説明用に作った計算例です。三条件のAI比較も未実施の計画です。実際に試すときは、入力と出力を記録し、本文の例とは分けて結果を残してください。

どんな表から練習するのがよいですか？

自分で正解を説明できる小さな架空表から始めます。正しい行、誤りを入れた行、材料不足の行を分け、対象と除外の理由を先に決めます。実データを使う必要がある段階では、入力してよい情報と正式な訂正手順を確認します。

最初の一枚は、合計より「含む理由」を書く

まず、一つの集計を選び、「何を、いつ、どの状態で、一件を何として、どの単位で数えるか」を一文にします。その定義で対象行と除外行を選び、元へ戻れる理由を残します。合計はその後に確認します。

AIには、結果を断定する役より、条件とのずれを候補として示す役を渡します。候補を採用する人は、表の事実、集計定義、元資料の三つを照合します。分からないものは、分からない状態で確認へつなぎます。

「数字が合った」は一つの確認です。「その数字は何を表し、何には使えないか」まで説明できたとき、表は次の判断に使いやすくなります。