POSレジのCSVをExcelで整形する設計

「レジから出したCSVをExcelで開くと、また文字化けしている」「先月と同じ手直しを今月もしている」——多店舗の売上を集計している会社では、この繰り返しが毎月の固定作業になっています。

結論から言うと、毎月同じ手直しが発生するのは作業が遅いからではなく、手直しを「作業」として扱っているからです。同じ直しが再発するなら、それは設定と対応表で吸収できる部分が設定になっていないという意味です。

株式会社Fyveは中小企業のAI活用を月額で支援しています。この記事では、POSレジやハンディ端末から出るCSVをExcelで扱うときに崩れる原因を仕組みから分解し、二度と同じ手直しをしないための設計を整理します。AIに任せる部分と、設定で固定すべき部分の線引きも扱います。

毎月同じ手直しをしているなら、直す場所が違う

CSVの整形で消耗している会社に共通するのは、作業手順が人の頭の中にしかないことです。文字化けしたら文字コードを変えて開き直す、列がずれていたら手で寄せる、商品分類の表記が違っていたら置換する。この一連が担当者の手癖として定着していると、速さは上がりますが再発は止まりません。

ここで区別すべきことが1つあります。毎月変わるもの（データの中身）と、毎月変わらないもの（データの形）です。売上金額や商品名は毎月変わりますが、文字コード・区切り文字・列の並び・分類の命名規則は、レジの設定を変えないかぎり毎月同じです。つまり形に対する手直しは、本来1回だけ設定すれば済むはずのものです。

それが毎月発生しているということは、設定として固定できる作業を手作業でやり直しているということになります。整形の設計とは、この「毎月変わらない部分」を人の手から外していく作業です。

Copilotの基本操作から確認したい場合は、先に全体像をつかんでおくと以降の判断がしやすくなります。

CopilotExcelのCopilot使い方｜業務で効く操作

CSVが崩れる4つの原因

CSVの取り込みで起きるトラブルは、見た目が同じでも原因は別です。原因を分けないと、対処も再発防止も決められません。実務で遭遇するものは、ほぼ次の4つに収まります。

1. 文字コードの不一致

日本語のシステムから出るCSVは、UTF-8で書かれているものとShift-JIS系（コードページ932）で書かれているものが混在します。Excelがこれを取り違えると、日本語が読めない文字の列になります。ここで重要なのは、Excel側が自動で正しく判定してくれるとは限らないという点です。

Microsoftの公式ドキュメントは、Power QueryのText/CSVコネクタについて「現在、文字セットは推定されない」「UTF-8はUTF-8のBOMで始まる場合のみ推定される」と明記しています。つまりBOMの無いUTF-8ファイルは、こちらが明示的に指定しないと正しく読まれない可能性があるということです。文字化けは運の問題ではなく、指定していないことの結果です。

2. 区切り文字の想定違い

CSVという拡張子でも、実際の区切り文字がタブやセミコロンになっていることがあります。海外製のシステムや、地域設定の違う環境で出力されたファイルで起きます。区切りが違うと全部が1列に入るか、意図しない位置で分割されます。

公式ドキュメントによると、Power Queryで指定できる区切り文字はコロン、カンマ、等号、セミコロン、スペース、タブ、任意の文字列を指定できるカスタム、そして固定幅です。手作業で寄せる前に、区切り文字の指定で解決できないかを必ず先に確認します。

3. 引用符の中の改行

商品名や備考欄に改行が入っていると、1件のデータが2行に割れて読み込まれます。これは列がずれる原因としてかなり多く、しかも一部の行だけで起きるため気づきにくい種類のトラブルです。

公式ドキュメントには、ソースの設定を編集すると「Line breaks（改行）」のドロップダウンがあり、引用符内の改行を適用するか無視するかを選べると記載されています。「引用符で囲まれた改行を無視する」を選ぶと、改行後の文字列が同じ列の続きとして読み込まれます。手で行をつなぎ直す作業は、この設定1つで消えます。

4. データ型の誤推定

もっとも実害が大きいのがこれです。商品コードの先頭のゼロが消える、「1-2」が日付になる、電話番号が指数表記になる。原因は、取り込み時に列の型を自動判定していることです。

公式ドキュメントは、型の検出について先頭200行を基準にする／データセット全体を基準にする／自動検出をオフにして全列をテキストとして扱うの3つを選べると説明しています。さらに「推定は誤ることがあるので、読み込む前に設定を確認する」という注意も明記されています。先頭200行が数字で埋まっていて201行目以降に文字が混ざる列は、この仕組みで壊れます。

実務での結論は単純です。コード・番号・分類の列は、最初から全部テキストとして取り込む。数値として計算するのは金額と数量だけで、それ以外を数値にする必要はありません。

Excelで開くのをやめて、取り込みに変える

ここまでの4つの原因を見ると、共通点があります。どれも「取り込みの設定」で決まるということです。ところがCSVをダブルクリックしてExcelで開く操作には、この設定を明示する機会がほとんどありません。だから毎回結果が運任せになり、開いた後に手で直すことになります。

設計としての答えは、開くのではなく取り込むことです。Excelの「データ」タブからText/CSVとして取り込むと、文字コード（ファイルの元）・区切り文字・型の検出方法を明示的に指定できます。そして指定した内容は取り込み手順として保存されるので、翌月は同じ手順を再実行するだけで済みます。

取り込み手順として残すことの意味

手作業とのいちばん大きな違いは、手順が目に見える形で残ることです。手作業の整形は担当者の記憶に残りますが、記憶は共有できず、引き継げず、検証もできません。取り込み手順として残しておけば、何をどう変換しているかを他の人が読めます。

これは属人化の解消というより、間違いを特定できる状態にするための設計です。数字が合わないときに、どの変換が原因かを追える。手作業では「どこかで間違えた」しか分かりません。

ファイルの置き場所と名前を固定する

取り込み手順を作るなら、取り込み元のファイルの場所と名前を固定しておく必要があります。毎月違う場所に違う名前で置かれると、手順を再利用できません。地味ですが、ここを決めないまま自動化に進むと必ず戻ってきます。

• 置き場所は月をまたいでも変わらない1つのフォルダにする
• ファイル名の規則を決める（例: 拠点コード＋年月＋種別）
• ファイル名に日本語や空白を入れない
• 取り込み済みのファイルは別フォルダへ移す（二重取り込みの防止）

列の増減で壊れる仕組みを知っておく

取り込み手順を作ったあとに起きる代表的な事故が、レジ側の設定変更で列が増えたときに気づけないというものです。列が増えたのに手順が古い列構成のままだと、新しい列が無視されるか、位置がずれたまま集計されます。

公式ドキュメントには、Power BI DesktopでCSVをインポートすると `columns=x` というステップが生成され、xは初回インポート時の列数になる、という記述があります。そして後で列を増やしてデータソースを更新しても、更新処理には初回のx列を超える列が含まれないと明記されています。これはPower BI Desktopについての説明ですが、列数を前提として持つ取り込み手順が、列の増加に自動では追随しないという性質を示しています。

したがって運用側で必要なのは、列構成が変わったことを検知する仕組みです。難しいことは要りません。

• 取り込んだ後に、列数と列名の一覧を1つのシートに残しておく
• 前月の列名一覧と比較して、差分があれば止める
• レジやシステムの設定を変えたら、集計担当に必ず伝えるルールにする

3つ目は仕組みではなく約束ですが、これが無いと1つ目と2つ目は事後対応にしかなりません。データの形を変える権限を持つ人と、集計する人の間に連絡経路を1本引くことが、実は最も効きます。

マクロで整形している場合の注意

すでにVBAマクロで整形している会社では、列の増減がマクロの中に埋まった列番号と衝突します。マクロは列を番号で指定していることが多いため、列が1つ増えるだけで全体が1つずれ、しかもエラーにならず間違った列を処理し続けるという最悪の壊れ方をします。

この状態のマクロをAIに直させようとすると、たいてい元より複雑になります。理由と対処はAIにマクロを頼むと複雑化する理由と対処で構造から整理しました。整形処理は、マクロを直すのではなく取り込み手順に置き換えるほうが結果的に短く終わることが多い工程です。

商品分類の表記ゆれは「直す」のではなく「当てる」

CSV整形でもっとも時間を食うのが、商品分類の修正です。同じ区分が「ドリンク」「飲料」「ソフトドリンク」と別の表記で入っている。新商品が「その他」に入ったままになっている。担当者が毎月これを目で見て直しています。

ここで発想を変える必要があります。表記ゆれを直すのではなく、表記ゆれを許したまま正しい分類に当てるという設計です。

対応表（マスタ）を1枚用意する

やることは単純です。「元データに出てくる表記」と「集計で使う分類」を対応させた表を1枚作ります。

• 左の列: 元データにそのまま出てくる商品名・商品コード・分類名
• 右の列: 集計で使う正式な分類（大分類・中分類など）

取り込み手順の中でこの対応表を突き合わせれば、元データの表記が何であっても正しい分類に変換されます。元データは一切修正しないという点が重要です。元データを直す設計にすると、直す作業が毎月発生し、しかも元データと集計値が食い違って原因追跡ができなくなります。

対応表に無い値を必ず可視化する

対応表の運用でいちばん危険なのは、対応表に載っていない新しい表記が黙って「その他」に落ちることです。これが起きると、新商品の売上が丸ごと見えなくなります。

設計としては、対応表に一致しなかった値を必ず一覧として出します。件数がゼロでない月は、対応表に追記してから集計を確定する。この1工程を入れるだけで、「気づかないうちに数字が抜けていた」という事故が止まります。

対応表のメンテナンス責任を決める

対応表は生き物です。商品が増えれば追記が必要で、放置すれば「その他」が膨らみます。誰が追記するのか、いつ追記するのか（新商品登録時か、月次の集計前か）を決めておかないと、半年で使えなくなります。

実務的には商品を登録する人が対応表も更新するのが自然です。集計担当が後から推測して当てる運用は、推測が入るぶん精度が落ちます。分類は商品を知っている人が決めるべき情報です。

AIが効く工程と効かない工程

ここまで設定と対応表の話をしてきました。ではAIはどこで効くのか。線引きは明確です。

効く工程

• 対応表の初期作成——元データに出てくる表記を一覧で渡し、分類の候補を出させる。ゼロから手で作るより速く、人が確認して確定する前提なら実用的です
• 新しい表記の分類候補——対応表に一致しなかった値について、既存の分類から近いものを提案させる
• 変換ルールの説明——既存の取り込み手順や数式が何をしているのかを説明させる。引き継ぎのときに効きます
• 集計後の要約と可視化——整形が終わったデータについて、傾向やグラフの作成を依頼する

効かない、または任せてはいけない工程

• 毎月の変換そのもの——同じ変換を毎月AIに頼むのは設計として誤りです。結果が毎回同じである保証がないうえ、履歴も残りません。決まった変換は設定に固定します
• 分類の最終確定——どの商品をどの分類に入れるかは経営判断です。AIの提案は候補で、確定は人が行います
• 金額の計算——後述しますが、公式が明確に非推奨としています

この線引きの根拠になる公式記述があります。Excelの数式として使えるCOPILOT関数について、公式ドキュメントは「モデルは今後改善されるため、同じ引数でも結果が時間とともに変わる可能性がある」と明記し、正確さと再現性が必要な数値計算にはSUM・AVERAGE・IFなどのネイティブ関数を使うよう案内しています。さらにCOPILOT関数がアクセスできるのは渡した引数の範囲だけで、ブックの他のデータや社内データには一切アクセスしないとも書かれています。

毎月の変換を「同じ結果が返る保証のない仕組み」に載せてはいけない、というのはここから直接導けます。AIは候補を出す側、設定は結果を固定する側です。

Copilotが業務のどこまで踏み込めるかは業務別の活用事例にまとめてあるので、任せる範囲を決める材料に使ってください。

複数店舗・複数月をまとめる

多店舗の飲食業のように、拠点ごとに同じ形式のCSVが出てくるケースでは、フォルダ単位の取り込みが効きます。公式ドキュメントによると、フォルダーコネクタはフォルダとサブフォルダにある全ファイルを同じ方法で処理し、その結果を結合する仕組みです。処理方法は、こちらが選んだサンプルファイルによって決まります。

ここから運用上の条件が2つ出てきます。

• 全ファイルの形式と構造をそろえる——公式も、結合が正しく動くようにフォルダとサブフォルダの全ファイルが同じファイル形式・同じ構造であることを確認するよう案内しています。1店舗だけ列の並びが違うと結合が崩れます
• 除外したいファイルがあるなら、結合の前に絞る——公式は、一部のファイルを除外したい場合はCombineではなくTransform dataを選び、ファイル一覧の段階で絞り込んでから結合するよう説明しています

1つ目は、拠点ごとにExcelを自由に改造している会社にとっては重い条件です。ただし逆に言えば、フォーマットをそろえること自体が集計の自動化の前提だということです。ここを飛ばして自動化しようとすると、例外処理が積み重なって誰も保守できない仕組みになります。

なお公式には、大きなCSVをPower Query Onlineの編集画面で扱うとInternal Errorになることがあり、小さいファイルで手順を作ってから大きいファイルへパスを差し替える方法が案内されています。手順を作る段階と本番のデータを分けて考える、という発想はここでも有効です。

手直しをゼロに近づける運用チェックリスト

設計が済んだあと、運用で確認する項目を並べます。毎月このリストを見るだけで、再発の大半は防げます。

• 取り込み時の文字コードを明示的に指定しているか（自動任せにしていないか）
• 区切り文字を明示しているか
• コード・番号・分類の列をテキストとして取り込んでいるか
• 引用符内の改行の扱いを指定しているか
• 列名の一覧を保存し、前月と比較しているか
• 対応表に一致しなかった値の一覧を確認しているか（件数がゼロか）
• 元データを直接編集していないか
• 取り込み済みファイルを別フォルダに移しているか
• 拠点ごとのファイル形式がそろっているか
• 件数と合計を明細と突き合わせているか

最後の項目は整形ではなく検算ですが、整形の成否はここでしか分かりません。整形した結果が正しいことを、整形した手順そのもので確認することはできないからです。

このチェックリストを毎月の締め作業に組み込むと、整形が締め全体のどこに位置しているかも見えてきます。整形が速くなっても締めが終わらない場合、ボトルネックは別の工程にあります。原因の分解の仕方は月次のExcel締めが遅い原因と短縮の設計にまとめました。

整形が終わったデータをどう集計設計に載せるかは、売上集計そのものの設計として別記事に整理しました。入り口が整った次の工程です。

CopilotCopilotで売上集計Excelを自動化する設計

よくある質問

CSVをExcelで開くと文字化けします。どう直すのが正しいですか

開いた後に直すのではなく、取り込み時に文字コードを明示するのが正しい対処です。Power QueryのText/CSVコネクタでは「ファイルの元」で文字セット（コードページ）を選べます。公式は文字セットが自動で推定されないこと、UTF-8はBOMで始まる場合のみ推定されることを明記しているので、指定は必須の工程だと考えてください。

商品コードの先頭のゼロが消えます

取り込み時に列の型が数値として推定されているためです。公式は型の検出方法として先頭200行・データセット全体・自動検出オフ（全列テキスト）の3つを選べると説明しています。コードや番号の列はテキストとして取り込むのが確実です。すでに消えてしまったデータは復元できないので、取り込みからやり直します。

分類の修正をCopilotに毎月やらせてもいいですか

おすすめしません。毎月同じ結果が返る保証がなく、何をどう変えたかの履歴も残らないためです。分類の変換は対応表と取り込み手順で固定し、Copilotには対応表に無い新しい表記の候補出しを担当させるのが役割分担として適切です。

対応表はExcelで作るべきですか、別のシステムに持つべきですか

最初はExcelの1シートで十分です。重要なのは置き場所ではなく、1か所にしかないことと、誰が更新するか決まっていることです。コピーが複数できた時点で、どれが正しいか分からなくなり対応表としての機能を失います。

レジの設定で出力形式を変えられる場合、どこまで変えるべきですか

出力側で変えられるものは、できるだけ出力側で変えます。文字コード・区切り文字・列の並び・分類コードの出力有無などです。取り込み側で吸収する処理は、増えるほど保守の対象が増えます。上流で解決できることを下流で解決しないのが原則です。

Copilotが使えない環境でもこの設計は有効ですか

有効です。この記事で扱った取り込みの設定と対応表の設計は、Copilotの有無に関係なく効きます。むしろ先にこの設計を済ませておかないとCopilotを入れても効かないという順番です。Copilot側の前提条件（自動保存、テーブル形式、ファイル形式など）で詰まっている場合は、使えないときの確認手順を先に見てください。

整形の作業時間はどれくらい短くなりますか

短縮幅は、現在どの工程に何分かけているかによって全く変わるため、事前に一般化した数字を出すことはできません。着手前に工程ごとの所要時間を記録しておいてください。記録が無いと、設計を入れた後で効果を説明できず、次の投資判断ができなくなります。測るべきものは所要時間だけでなく、差し戻しの回数と集計後に数字を直した回数です。この2つが減ることが、設計が効いた本当の証拠になります。

まとめ

POSやレジから出るCSVの整形で毎月同じ手直しが発生しているなら、直す場所は作業手順ではなく設計です。文字コード・区切り文字・改行の扱い・型の検出はすべて取り込み時に明示できる設定であり、公式ドキュメントも自動推定に頼らないよう注意しています。開くのをやめて取り込みに変えるだけで、この4つは固定されます。

商品分類の表記ゆれは、直すのではなく対応表で当てる。元データは修正せず、対応表に無い値だけを毎月確認する。この形にすると、修正作業が「毎月の手直し」から「新しい商品を登録したときの追記」に変わります。回数が桁違いに減るのは、速くなったからではなく、やることの性質が変わったからです。

そしてAIは、この設計を置き換えるものではありません。対応表の初期作成、新表記の候補出し、既存処理の説明、集計後の可視化——人が確認する前提の工程で効きます。私たちが支援に入るときも、まずこの線引きから始めます。設定で固定できるものを固定し終えてからAIを載せる。順番を逆にすると、毎月の手直しがAIへの依頼に置き換わるだけで、作業量は減りません。