月次決算が "確認するだけ" になっていた — Power Query 派が AI 集計に任せて見えたこと

2026-05-17 ／ 第11号 ／ 公開時点では下書き

第7号で「朝風呂・散歩・昼食のあいだに、Claude が Microsoft 365 を 5 ラウンド武装化していた話」を書いた。
あれは セキュリティ設定 という、Claude が世界中のドキュメントから型を知っている領域での「ほぼ自動」だった。

今日（2026-05-17）気づいたのは、同じ手触りが 会計業務 にも到達していた、ということ。「気づいた」というのが正確で、私はもう何ヶ月もこのモードで月次入力をしている。
つまり 気づかないうちに自動化が成立していた。

前提：私は Power Query 派

本題の前にひとつ告白しておくと、私は Power Query と ピボットテーブルで大量の CSV を捌くのには、そこそこ自信がある 側の人間。
Amazon の全注文レポート、ヤマト運輸の請求 CSV、メルカリ Shops の売上明細、Square の決済明細。
列の意味と前処理の順序さえ決まれば、月次集計は組める。

言い換えると 「集計を AI に丸投げしなくていい」立場 から、今の自動化を作っている。これは今日の本題に効いてくる。

会計業務の現状（個人事業主・一人 EC）

うちは BASE / Qoo10 / カラーミー / Yahoo!ショッピング の 4 モール + Amazon + メルカリ Shops + Square で売っている。会計ソフトは やよいの青色申告オンライン。

月次の入力ルーチンは大きく 3 つの「日」に分かれる：

・月初：前月分の売上系（モール各社の精算明細・配送業者の請求・ポイント還元・共益費 など 10 タスク）
・11 日：ヤフー 10 日締 ＋ アマゾン売上＋アマゾン手数料＋アマゾン経由の配送料 ＋ 弥生月次レポート DL
・21 日：各種カード明細、その他継続課金系

このうち、ほぼ全部が Claude + 自作 Python ツール（yayoi_auto）+ Chrome 拡張 で自動化されている。流れはどれも同じ：

1) Claude が各サイトに既存セッションで入って明細を取得（Web 画面・PDF・API）
2) 取得した生データをアダプタで RawTxn に正規化
3) 仕訳ルール（科目・補助科目・税区分・取引先・適格情報）を YAML 1 枚 で先勝ち判定
4) 弥生の取込フォーマット（27 列・CP932・CRLF）の CSV に書き出し
5) 弥生「仕訳の取込み」に投入 → 取り込まれた行を私が確認

私の作業は (5) の確認だけ。ファイルが入ったか、金額が一次ソースと一致するか、税区分・補助科目・取引先が既存と揃っているか。
月次決算（残高推移表の Excel DL）も自動化済みで、毎月のスナップショットが OneDrive の所定フォルダに静かに積み上がっていく。

昨日の実例：11 日タスク

昨日（2026-05-16）の 11 日タスクは、こうだった。所要は実質 30 分ぐらい：

「配送料の PDF を Read で開いて金額を一次確認」だけが、私の手で必須にしているチェック。
Web 画面 OCR は過去に 誤読 したことがあるので、税込総額は PDF 本文から取る、と決めている。

ついでに：今日 AI に集計を頼んでみた

今日の本題は別件。新しく届いた Amazon の全注文レポート（CP932・タブ区切り・数千行・複数ヶ月分）を Claude に渡して、月別売上を集計してくれと頼んだ。
これは 確認用の一時集計。本番仕訳は別ルートで既に入っているので、正解は私が握っている状態。先月分・最大月・たまたま 1 件しかなかった月、それぞれ「弥生上のいくら」かを言える。

3 回の往復が要った：

1 回目：Claude は item-price + item-tax + ship-price + ship-tax を全部足してきた。item-tax は item-price に 内包 されている数字なので、全体的に売上が約 1 割過大になった。私が「最大月の数字が違うはず」と指摘。

2 回目：今度は item-price 単独に修正。大半の月は正解になったが、送料が別建ての月（1 件しかなかった例の月）で 送料分を落としてしまった。私が「その月の正解はこの数字」と指摘。

3 回目：item-price + shipping-price（送料がある月だけ加える形）に揃えて、ようやく全月正解に着地。

今日の学び：条件を揃えないと、AI 集計は危険

列名（item-price / item-tax / shipping-price）は誰が見ても同じだが、「item-price は税込か税抜か」「shipping は item-price に含まれるのか別か」 はベンダーごとに違う。Amazon JP の場合：

・item-price = 商品代金（税込総額）
・item-tax = うち消費税（情報のみ。足してはいけない）
・shipping-price = 送料（税込・別建て、足す）

Power Query で組むときは 列の意味を自分で決めてから関数を書く ので、こういう取り違えは初期段階で潰れる。
逆に AI に「集計して」と渡すだけだと、AI は 名前から推測 するしかない。今日の 3 回往復は、まさにその推測が外れた回数。

結論はシンプル：

答えを知っているチェッカーが横にいれば、AI 集計は便利な下書き生成機になる。
答えを知らないままに「集計して」と頼むのは危ない。

今回うまく着地したのは、2026-04 と 2025-12 の正解値を私が握っていた からだった。手元に正解がない状態だったら、3 回目の集計表をそのまま信じて記事にしていたかもしれない。

会計業務の自動化が成立している条件

振り返ると、今の状態が成り立っているのは 4 つの安全装置 があるから。

1) 仕訳ルールはコード（YAML）で固定。摘要・補助科目・税区分・適格情報まで含めて、弥生の既存仕訳と完全一致する形で 1 ヶ所に書いてある。AI に「いい感じに分けて」とは絶対に頼まない。

2) 一次ソース原則。PDF が一次ソースのもの（ヤマト・Amazon 手数料・配送料）は、Web 画面の数字ではなく PDF 本文を Read tool で開いて確認する。Web OCR は誤読する。

3) 既入力チェック必須。新規仕訳を入れる前に、弥生の「仕訳の入力」で同じ摘要・取引先を検索して、二重計上を物理的に防ぐ。

4) ルールに当たらないものは「未確定」勘定で隔離。判断が要る取引は 未確定 / 未確定 の仕訳になって、私が後から手で分類する。AI の推測で勝手に科目を選ばない。

この 4 つが揃っているから「任せられる」。1 個でも欠けたら、私は怖くて月次を任せていない。第7号で M365 を任せられたのと同じ構造。

次回

来週はたぶん、第10号で揃えた 4 モールの注文オペレーション（受注 → 梱包 → 発送 → 通知）を回す話か、あるいは今日の yayoi_auto を別ドメイン（karaha.org の収支管理）に移植する話。
どっちにしろ、書く。