
Excelで合計が合わない|エラーが出ないまま数字が変わる4つの場面
受注の一覧と、商品の一覧。
この2つをつないで、商品ごとの売上を出しました。
出てきた合計が、実際より大きい。
エラーは出ていません。
数式も間違っていません。
この記事では、集計の途中で数字が変わってしまう事故を4つ扱います。
つないだら行が増える。つないだら行が消える。未回答を0で埋める。そして、金額に小さな誤差が出る。
4つに共通しているのは、どれもエラーが出ないことです。
赤い警告も、メッセージも出ません。
ただ、違う数字が出てきます。
先に、調べていていちばん意外だったことを2つ書いておきます。
1つ目。
表と表をつなぐ画面には、つなぐ前に「何行が一致するか」が出ています。
Microsoftは、そのメッセージについて「非常に重要です」と書いています。
ほとんどの人が、読まずに実行を押しています。
2つ目。
金額の丸め方は、国が決めている場面があります。
国税庁は、商品ごとに端数処理をして合計するやり方を「認められません」と書いています。
この記事は、Microsoft の Power Query のマージ関連ドキュメント5ページ、Excel の AVERAGE 関数と浮動小数点演算のページ、PostgreSQL 18 の集約関数のドキュメント、国税庁のインボイス制度に関するQ&A問57をもとに、2026年9月12日時点の内容にしています。
つないだだけで、行が増える
右に2行あれば、左の1行は2行になる
まず、何が起きているかです。
表と表をつなぐとき、私たちはある列を手がかりにします。
商品コード、取引先コード、社員番号。
そういう列です。
このとき、左の表の1行に対して、右の表に一致する行が2つあったらどうなるか。
結果は2行になります。
左の1行が、2行に増えます。
3つ一致すれば3行です。
金額も、その回数だけ足されます。
1000件の受注をつないだら1200件になっていた、という状態です。
合計は、増えた分だけ大きくなります。
Microsoftは「デカルト積」と書いている
この挙動を、公式の資料がはっきり書いています。
Microsoftのデータ整形ツールであるPower Queryのヘルプに、クロス結合という操作の説明があります。
クロス結合は、結合内のテーブルから行のデカルト積を返す結合の一種です。 つまり、最初のテーブルの各行と 2 番目のテーブルの各行が結合されます。
すべての組み合わせを作る操作です。
製品と色の組み合わせ一覧を作るときのように、意図して使うものです。
ところが、キーが重複していると、その一致した範囲の中で、同じことが小さく起こります。
左の1行と、右の2行。
組み合わせは2つ。
だから2行になります。
事故のほうは、意図しないクロス結合が部分的に起きている状態だといえます。
マスタは、使っているうちに1件1行でなくなる
ここが実務の話になります。
右に置く表は、たいてい「マスタ」と呼ばれるものです。
商品マスタ、取引先マスタ、社員マスタ。
1件1行のつもりで作ります。
しかし、運用しているうちに履歴が入ります。
価格を改定したので、旧価格の行と新価格の行が並んでいる。
取引先の住所が変わったので、旧住所の行が残っている。
担当者が異動したので、異動前の行と異動後の行がある。
同じ会社に枝番が振られていて、コードが複数ある。
どれも、消さずに残しておきたい理由があって残っています。
その結果、マスタは「現在の姿」ではなく「履歴」になります。
履歴になった表を右に置いてつなぐと、行が増えます。
つなぐ前に、画面に出ている数字を読む
一致する行数は、実行の前に表示されている
対策は、道具を増やすことではありません。
画面に出ているものを読むことです。
Power Queryのマージ画面について、ヘルプにこう書かれています。
選択を行うと、ダイアログ ボックスの下部に推定一致数を含むメッセージが表示されます。
つなぐ前に、何行が一致するのかが画面に出ます。
内部結合の解説ページには、このメッセージについての注意が別に書かれています。
このメッセージは、この操作から得られる結果を理解するうえで非常に重要です。
非常に重要です、と書いてあります。
ここを読まずに実行を押すのが、いちばん多い事故の入口です。
列の型がそろっていないと、正しい結果にならない
同じページに、もう1つ条件が書かれています。
ただし、列は同じデータ型である必要があることに注意してください。そうしないと、マージ操作によって正しい結果が得られない可能性があります。
片方が数値で、もう片方が文字列。
見た目は同じ「1001」でも、型が違えばつながりません。
CSVを開いた時点で型が決まってしまう話は、この連載の別の記事で扱っています。
記事末にリンクを置きます。
いちばん簡単な点検は、件数を並べて書くこと
道具がなくてもできる点検が1つあります。
つなぐ前の左の表の行数と、つないだあとの行数を並べて書く。
増えていたら、右の表に重複があります。
表計算ソフトだけで確かめるなら、COUNTIF関数でキーごとの件数を出して、2以上の行がないかを見ます。
そして、気づき方の話をもう1つ。
合計金額が1割増えても、人は気づきません。
売上は毎月動くものなので、少し大きい数字が出ても「今月は良かった」と読めてしまいます。
件数は違います。
受注1000件のはずが1200件になっていれば、おかしいと分かります。
件数は、たいてい別の場所でも把握しているからです。
集計の点検は、金額ではなく件数から入ります。
逆に、行が黙って消えることもある
内部結合は、一致した行だけを残す
今度は逆です。
つないだら行が減ります。
受注が1000件あったはずなのに、集計してみたら920件分しかない。
これもエラーは出ません。
減った80件は、どこにも表示されないまま消えています。
Power Queryのヘルプには、選べる結合の種類が表で並んでいます。
そのうち3つを引用します。
内部結合の説明。
両方のテーブルの一致する行のみ
左外部結合の説明。
左側のテーブルのすべての行 (右側のテーブルの行と一致)
左アンチ結合の説明。
左側のテーブルの行のみ
問題は1つ目です。
内部結合は、両方に存在する行だけを残します。
左にあって右にない行は、結果に出てきません。
マスタに登録されていない取引先の受注は、そこで落ちます。
公式の例では、4行が1行になる
この落ち方が、どのくらい大きいか。
Microsoftの内部結合の解説ページに、具体的な数字が出ています。
売上の表と国の表をつなぐ例です。
Sales テーブルでは、CountryID が 1 と 2 ですが、どちらの値も Countries テーブルには見つかりません。 そのため、左側の (最初の) テーブルで 4 行のうち 1 行しか見つかりません。
4行が1行になっています。
説明用の小さな例ですが、起きていることは実務と同じです。
右の表に無いキーを持った行は、黙って落ちます。
なぜ、キーが一致しないのか
理由は、たいてい次のどれかです。
1つ目、まだマスタに登録していない。
新規の取引先、今月から扱い始めた商品。
2つ目、コードの書き方が違う。
片方は0001で、もう片方は1。
前のゼロがあるかないかで、別のものになります。
3つ目、全角と半角が混ざっている。
英数字は、見た目がほとんど同じです。
4つ目、余分な空白が入っている。
コピーして貼ったときに付いてきたものです。
5つ目、廃番になった商品をマスタから消した。
過去の受注は、そのコードのまま残っています。
6つ目、先ほどのデータ型の違いです。
どれも、人の目では同じに見えます。
そして、一致しなかったという事実は、結果の表には出てきません。
出てこないので、探しようがありません。
消えた行だけを、取り出す
左外部結合にすると、行は残る
対処は2段階あります。
1つ目は、つなぎ方を変えることです。
左外部結合にすると、左の表の行は全部残ります。
左外部結合の解説ページに、こう書かれています。
左右のテーブル間に一致がない場合、null 値はその行のマージの結果になります。
nullというのは、値が入っていない状態のことです。
空欄で残るので、少なくとも行数は変わりません。
件数を突き合わせれば、すぐ分かります。
ただし、ここで注意が要ります。
空欄のまま合計すると、商品名なしの行として集計されます。
金額は正しく足されますが、「分類不明」という塊ができます。
その塊を見なかったことにすると、結局同じことになります。
左アンチ結合は、つながらなかった行だけを出す
2つ目が、点検としていちばん使える方法です。
左アンチ結合という種類があります。
解説ページの説明はこうです。
これは、右のテーブルの一致する行がない左のテーブルの行のみを取り込みます。
右に相手がいなかった行だけを取り出す操作です。
つまり、マスタに無いコードの一覧が、そのまま出てきます。
新規登録し忘れている取引先、書き方が揺れているコード、廃番になった商品。
月に1回これを実行して、出てきた行がゼロなら、その月の集計は全件つながっています。
ゼロでなければ、そこに直すべきものがあります。
集計を直すのではなく、マスタを直す。
これが正しい順番です。
PR
空欄と0は、画面では見分けがつかない
表示の設定ひとつで、同じ見た目になる
3つ目の事故に移ります。
社内アンケートを取りました。
満足度を5段階で聞いています。
50人に配って、40人が回答しました。
10人は未回答です。
集計するとき、その10人の欄をどうしたでしょうか。
空欄のままにしたか、0を入れたか。
表計算ソフトには、値がゼロのセルにゼロを表示するかどうかを切り替える設定があります。
ゼロを表示しない設定にしていると、0が入っているセルも空欄に見えます。
画面の上では、何も入っていないセルと、0が入っているセルが、まったく同じ見た目になります。
Excelは、空欄を無視して、0を数える
ところが、計算の扱いは正反対です。
MicrosoftのAVERAGE関数のヘルプに、はっきり書かれています。
引数として指定したセル範囲またはセル参照に文字列、論理値、または空白セルが含まれている場合、これらは無視されます。ただし、値 0 (ゼロ) を含むセルは計算の対象となります。
空白セルは無視される。
0は計算の対象になる。
同じページには、見た目との食い違いについての注意も書かれています。
セルを平均化するときは、特に、Excel デスクトップ アプリケーションの [Excel のオプション] ダイアログ ボックスで、[ゼロ値のセルにゼロを表示する] チェック ボックスをオフにした場合は、空のセルと値がゼロのセルの違いに注意してください。 このオプションを選択すると、空のセルはカウントされませんが、ゼロの値はカウントされます。
先ほどの例で確かめます。
40人が回答し、点数の合計が160点だったとします。
空欄のままなら、分母は40です。
平均は4.0。
10人分に0を入れたら、分母は50になります。
合計は160のまま、平均は3.2。
0.8点下がりました。
データベースも、同じ考え方をしている
これは表計算ソフトだけの話ではありません。
PostgreSQLという広く使われているデータベースの公式ドキュメントに、集約関数の一覧があります。
行そのものを数える関数の説明です。
Computes the number of input rows.
入力された行の数を数える、という意味です。
列を指定して数える関数の説明です。
Computes the number of input rows in which the input value is not null.
入力された値がnullでない行の数を数える、という意味です。
そして平均を出す関数の説明です。
Computes the average (arithmetic mean) of all the non-null input values.
nullでない入力値すべての平均を計算する、という意味です。
データベースでも、値が入っていない行は平均の分母から外れます。
0は分母に入ります。
表計算ソフトと同じ設計です。
道具を変えても逃げられない、ということでもあります。
0で埋めた瞬間に、意味が変わる
値が入っていないことには、意味があります。
「聞いたが答えなかった」「まだ届いていない」「そもそも対象外」。
これを0にすると、「答えた結果が0だった」に変わります。
別の言い方をすると、無回答が、最低評価として数えられます。
同じことは、あちこちで起きます。
在庫の欄が空のままなら「棚卸しがまだ」ですが、0にすると「在庫なし」になります。
発注の判断が変わります。
月次売上の欄が空のままなら「まだ締めていない」ですが、0にすると「その月は売上ゼロ」になります。
前年比の計算が変わります。
検温の記録が空なら「測っていない」ですが、0にすると異常値になります。
どれも、埋めた本人は親切のつもりです。
表に穴があると気持ちが悪いからです。
実務としての答えは、3つ
1つ目、空欄は空欄のまま置く。
穴が空いていて構いません。
集計する側の道具は、空欄を無視するように作られています。
2つ目、どうしても何か入れたいなら、0ではない印を使う。
「未回答」「未入力」「対象外」と文字で書いておけば、数値として計算されません。
ただし、その列の合計を出そうとするとエラーになるので、列を分けるほうが安全です。
3つ目、回答数を必ず併記する。
平均だけを書いた資料は、読む人が分母を確かめられません。
「平均4.0(回答40件、配布50件)」と書けば、0で埋めたかどうかがひと目で分かります。
この3つ目が、いちばん効きます。
分母を書く習慣があれば、途中で誰かが0を入れても、そこで気づけます。
金額の誤差は、仕様どおりに起きる
IEEE 754という国際的な仕様がある
最後の事故です。
請求書の合計が、1円合わない。
2つのセルを比べて、同じはずなのに等しいと判定されない。
桁を増やして表示すると、0.9のはずの数字が0.89999999999999999になっている。
機械の故障ではありません。
表計算ソフトの不具合でもありません。
Microsoftの公式資料に、こう書かれています。
Microsoft Excel は、IEEE 754 仕様を中心に設計され、浮動小数点数の格納方法と計算方法を決定しました。
IEEE 754というのは、小数をコンピューターに格納する方法を定めた国際的な仕様です。
Excel独自のやり方ではありません。
同じページに、具体的な例が載っています。
セルに「=(43.1-43.2)+1」と入力し、表示形式を科学表記にして小数点以下15桁にすると、どうなるか。
0.9 を表示する代わりに、Excel では 0.89999999999999999 が表示されます。
公式の資料が、こうなりますと書いています。
10進数の小数は、二進数では終わらない
なぜこうなるのか。
コンピューターは、数字を二進数で持っています。
0と1だけの世界です。
10進数の小数は、二進数にすると終わりのない循環小数になることがあります。
10 進数 0.0001 などの一般的な小数部であっても、バイナリで正確に表すことはできません。
分かりやすいたとえも添えられています。
これは、分数 1/3 を 10 進数で正確に表現できない理由と似ています (繰り返し 0.333333333333333)。
3分の1を小数で書こうとすると、0.3333と永遠に続きます。
どこかで切るしかありません。
切った時点で、ほんのわずか足りない数になります。
同じページは、その「わずか」の大きさまで書いています。
これにより、格納時に約 -2.8E-17、または 0.00000000000000028 というエラーが発生します。
そして、切り捨てた分は足し続けると積み上がります。
同じページにある例では、0.0001を1万回足しています。
答えは1になるはずです。
これにより、出力として 0.99999999999996 が出力されます。
1回あたりの誤差は見えないほど小さいものです。
1万回で、見える大きさになります。
なお、16桁以上の数字がそもそも保持されないという別の制限もあります。
そちらは、この連載のExcelとCSVの記事で扱っています。
0に近いときだけ、直してくれる
ここに、ややこしい事情があります。
同じページには、Excelが一部だけ補正していることも書かれています。
加算演算または減算演算の結果、値が 0 または非常に近い場合、Excel 97 以降は、オペランドをバイナリとの間で変換した結果として発生したエラーを補正します。
足し算や引き算の結果が0になるとき、あるいは0に非常に近いときだけ、誤差を打ち消してくれます。
差し引きゼロになるはずの計算は、きれいに0になります。
一方、0.9になるはずの計算は、先ほどのとおり0.89999999999999999のままです。
ここが厄介です。
試しに引き算をしてみて、0になったから大丈夫だと判断すると、間違えます。
0のときだけ特別に手当てされているからです。
対策は、丸める場所を決めること
資料には、2つの方法が挙げられています。
1つ目はROUND関数です。
計算の結果を、必要な桁で丸めます。
金額なら、足す前ではなく、比較したり出力したりする直前に丸めます。
2つ目は、ブック全体の設定で、表示されている桁数のとおりに値を丸めてしまう方法です。
こちらには強い注意が書かれています。
このオプションを元に戻して、失われたデータを回復することはできません。
元に戻せません。
単価に小数を持たせている場合、その小数がまとめて消えます。
実務としては、1つ目を使ってください。
設定を触るのは、影響範囲がブック全体に及ぶので勧めません。
もう1つ、日常で効く注意があります。
小数を等しいかどうかで比べないことです。
「A1とB1が等しければ」という判定は、見た目が同じでも成立しないことがあります。
比べるなら、両方をROUNDで丸めてから比べます。
どこで丸めるかは、制度でも決まっている
丸める場所を決める、というのは実務の工夫の話に聞こえます。
ところが、場面によっては制度が決めています。
国税庁のインボイス制度に関するQ&Aの問57です。
適格請求書の記載事項である消費税額等に1円未満の端数が生じる場合は、一の適格請求書につき、税率ごとに1回の端数処理を行う必要があります
1枚の請求書につき、税率ごとに1回。
切上げ、切捨て、四捨五入のどれを使うかは任意だ、とも書かれています。
そして、注として、やってはいけない形が名指しされています。
一の適格請求書に記載されている個々の商品ごとに消費税額等を計算し、1円未満の端数処理を行い、その合計額を消費税額等として記載することは認められません。
商品ごとに消費税を計算して、1円未満を丸めて、その合計を書く。
これは認められません。
ここまで読んできた話と、同じ形をしています。
丸めを早く入れるほど、誤差が積み上がる。
だから、丸めるのは最後に1回。
税の世界では、それが「任意」ではなく要件になっている、というだけのことです。
インボイス制度そのものは、この連載の別の記事にまとめてあります。
2026年9月時点の最新状況
この記事で引いた資料は、更新の時点がばらばらです。
同じ製品のドキュメントでも、ページごとに違います。
Power Queryの5ページは、更新日が2年ぶん離れている
ページのメタデータ上の日付は、次のとおりです。
マージ クエリの概要:2026年4月8日
クロス結合:2026年1月29日
左アンチ結合(日本語のページ名は「左結合」):2025年8月29日
左外部結合:2025年7月16日
内部結合:2024年6月12日
内部結合のページだけが2024年6月のままです。
この記事で「4行が1行になる」として引用した例は、このページのものです。
引用するときは、ページごとの日付を見る必要があります。
日本語のページ名に、機械翻訳の癖が残っている
左アンチ結合のページは、日本語版の見出しが「左結合」になっています。
本文の1行目は「左の結合です」で、左外部結合とは別のものを指しています。
検索して開くときに取り違えやすいので、URLの末尾(merge-queries-left-anti)で確かめるほうが確実です。
PostgreSQLは18が現行版である
この記事で引いた集約関数のドキュメントは、PostgreSQL 18のものです。
count関数とavg関数のnullの扱いは、この製品では古くから変わっていません。
Excelの浮動小数点のページは2026年3月30日更新
対象として挙げられているのは、Excel for Microsoft 365、Excel for Mac for Microsoft 365、Microsoft Excel 2024、Microsoft Excel 2021、Microsoft Excel 2016です。
インボイスのQ&Aは、2026年10月に周辺が動く
引用した問57は、令和6年4月改訂のものです。
端数処理のルール自体は、いまのところ変わっていません。
一方で、2026年10月1日には、免税事業者からの仕入れに対する経過措置が8割控除から7割控除に変わります。
計算する数字のほうが変わるということです。
そちらは、この連載のインボイスの記事にまとめてあります。
出てきた数字を見ても、気づけない
4つを並べると、同じ形が見えます。
右の表にキーが重複していると、行が増える。合計も増える。
内部結合でつなぐと、マスタに無いキーの行が落ちる。合計は減る。
未回答を0で埋めると、平均の分母が変わる。
小数の計算には、仕様として避けられない誤差がある。
どれもエラーが出ません。
だから、出てきた数字を見て気づくことはできません。
できるのは、出てくる前に条件を確かめることだけです。
つなぐ前に、画面の一致数を読む。
つないだあとの件数を、つなぐ前と並べて書く。
月に1回、つながらなかった行だけを出してみる。
平均には分母を添える。
金額は、丸めてから比べる。
どれも、新しい道具を買う話ではありません。
いま使っている画面に出ているものを読むか、紙に1行書き足すか、そのどちらかです。
そして、この5つのうち4つは、集計そのものではなく、集計の前後に置く手順です。
集計を上手にするより、集計の前後を決めるほうが早い、ということでもあります。
まとめ
右の表に同じキーが2行あれば、左の1行は2行に増える。金額もその回数だけ足される。Power Queryのヘルプは、すべての組み合わせを作る操作を「デカルト積」と説明している
マスタは、価格改定・住所変更・異動・枝番を残すうちに1件1行でなくなる。履歴になった表を右に置くと行が増える
つなぐ前に、ダイアログの下部に推定一致数が表示される。Microsoftは、このメッセージが「非常に重要です」と書いている
列は同じデータ型である必要がある。そうでないと正しい結果が得られない可能性がある、と明記されている
内部結合は「両方のテーブルの一致する行のみ」を残す。マスタに無いキーの行は、エラーも出さずに落ちる。公式の例では4行が1行になっている
左外部結合にすれば行は残り、一致しなかったところはnullになる。左アンチ結合を使えば、つながらなかった行だけを取り出せる
直すのは集計ではなくマスタ。月1回、左アンチ結合の結果がゼロなら、その月は全件つながっている
Excelは空白セルを無視し、0は計算の対象にする。ゼロを表示しない設定にしていると、この2つは画面で見分けがつかない
PostgreSQLも同じで、行そのものを数える関数は行数を数え、列を指定して数える関数と平均を出す関数は、nullでない値だけを数える
未回答を0で埋めると、答えなかった人が最低評価として数えられる。在庫も売上も同じ。平均には分母を併記する
ExcelはIEEE 754にもとづいて小数を扱う。「=(43.1-43.2)+1」を15桁で表示すると0.89999999999999999になり、0.0001を1万回足すと0.99999999999996になる
結果が0または0に非常に近いときだけ、Excelは誤差を補正する。だから0で試すと誤差が見えない
対策はROUND関数。ブック全体の設定で丸める方法は、元に戻せない
丸める場所は、制度が決めている場面もある。適格請求書は「一の適格請求書につき、税率ごとに1回」で、商品ごとに丸めて合計する方法は認められない
4つとも、操作した本人の画面ではエラーが出ません。
だから、点検は数字を見ることではなく、条件を確かめることになります。
皆さんの手元の集計表で、元の件数と出てきた件数は、並べて書かれているでしょうか。
参考・引用元
Microsoft(Power Query)
Microsoft「マージ クエリの概要」(2026年4月8日) https://learn.microsoft.com/ja-jp/power-query/merge-queries-overview
Microsoft「クロス結合機能の説明」(2026年1月29日) https://learn.microsoft.com/ja-jp/power-query/cross-join
Microsoft「内部結合」(2024年6月12日) https://learn.microsoft.com/ja-jp/power-query/merge-queries-inner
Microsoft「左外部結合」(2025年7月16日) https://learn.microsoft.com/ja-jp/power-query/merge-queries-left-outer
Microsoft「左結合(左アンチ結合)」(2025年8月29日) https://learn.microsoft.com/ja-jp/power-query/merge-queries-left-anti
Microsoft(Excel)
Microsoft「AVERAGE 関数」 https://support.microsoft.com/ja-jp/excel/functions/average-function
Microsoft「浮動小数点演算を使用すると、Excel で不正確な結果が得られます」(2026年3月30日) https://learn.microsoft.com/ja-jp/troubleshoot/microsoft-365-apps/excel/floating-point-arithmetic-inaccurate-result
PostgreSQL
PostgreSQL 18 Documentation「9.21. Aggregate Functions」 https://www.postgresql.org/docs/current/functions-aggregate.html
国税庁
国税庁「消費税の仕入税額控除制度における適格請求書等保存方式に関するQ&A」問57(適格請求書に記載する消費税額等の端数処理、令和6年4月改訂) https://www.nta.go.jp/taxes/shiraberu/zeimokubetsu/shohi/keigenzeiritsu/pdf/qa/57.pdf
国税庁「特集 インボイス制度」 https://www.nta.go.jp/taxes/shiraberu/zeimokubetsu/shohi/keigenzeiritsu/invoice.htm
実務で使う書式について
この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。規程のひな形、対応フロー、チェックシート、報告書式などです。
実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40
関連する記事
つなぐ前に値が壊れる話は、別の記事で扱っています。
先頭の0が消える理由と、16桁以上が戻らない理由をまとめています。
https://note.com/yunta_fukurou/n/n8bb215311d9d
渡したファイルに付いてくる見えないデータは、こちらで扱っています。
Excelの非表示の行・列・ワークシートと、PDFの黒塗りをまとめています。
https://note.com/yunta_fukurou/n/n08277ce46aef
端数処理を決めている制度の側は、別の記事で扱っています。
2026年10月1日からの7割控除と、そのあとの選択肢をまとめています。
https://note.com/yunta_fukurou/n/n7f4ecbeb1cb7
そもそも人が転記しない渡し方は、こちらで扱っています。
デジタルインボイスとPeppolの仕組みをまとめています。
https://note.com/yunta_fukurou/n/nd073723cd005
エラーが出ないまま間違いが通る話は、AIの側でも起きます。
渡す資料の量と、返ってきた表の確かめ方をまとめています。
https://note.com/yunta_fukurou/n/n16e5c1ca350a
作った表を相手が見るときに何が要るかは、別の記事で扱っています。
グラフと元データの置き場所と、見る側の契約をまとめています。
https://note.com/yunta_fukurou/n/ncc427cdd07c9