この記事の要点
- ネット通販で仕入れて売る事業では、何をいくらで仕入れ、いくつ残っているかを商品単位で記録しないと、利益も在庫も確定しません。 その記録用のスプレッドシートを、当事務所は顧問先向けに作って配っています。
- 2022年に作ったあと4年近く手を入れられなかったこのツールを、AIを使って作り直しました。ただしAIが引き受けたのは「どう作るか」だけです。「何を作るべきか」と「出てきたものが正しいか」は、会計の要件と商売の都合の両方を知らないと決められませんでした。
- そして配った直後から壊れ始めました。 AIが下げたのは作るコストだけで、持ち続けるコストは下がっていません。
なぜ4年間、直せなかったのか？
技術的にできなかったからではありません。税理士が手を動かして直すには、時間がかかりすぎたからです。
最初にこのスプレッドシートを作ったのは2022年ごろ。毎年、確定申告が終わった4〜5月に更新して配り直す建て付けにしていました。
ただしそれは建て付けの話で、実際にはバージョン番号が変わるだけで、中身の構造は初期のままでした。 シートの分け方も、ポイントの扱いも、作った当時の判断がそのまま残り続けていた。
困りごとは毎年見えていました。アカウントを1つ増やすたびにシートが1枚増える設計だったので、シートが55枚を超えていた。 顧問先は入力したいシートを探すだけで一苦労で、しかもモールごとに列の並びが違うため、購入履歴から貼り付けるたびに手で直す必要がありました。
それでも直せなかったのは、税理士がスプレッドシートとGoogle Apps Script（スプレッドシートに付属する自動処理の仕組み）の設計に何十時間も向き合うわけにいかないからです。毎年「今年こそ」と思いながら、行を足したり関数を微調整したりする程度で終わっていました。
外注する選択肢もありました。ただし外注は「一度作って終わり」にならないのが難点です。制度もモールの仕様も毎年変わるので、直したいたびに発注することになります。顧問料の中でそれを続けるのは現実的ではありませんでした。
AIで、何が変わったのか？
手を動かす時間が短くなり、税理士本人が構造から作り直せるようになりました。
2026年5月、4年ぶりに作り直しました。結果はこうです。
| 前 | 後 | |
| シートの数 | アカウント1つに1枚で、55枚超 | モール別に7枚 |
| 列の並び | モールごとにバラバラ | 全モール共通 |
| 集計 | 仕入も経費も私用も混ざった合計 | 目的別・アカウント別に分離 |
| 旧台帳からの引っ越し | 手作業で数千行を転記 | 旧ファイルのURLを貼れば自動 |
| シート名を変えたとき | 集計が壊れる | 壊れない |
作業そのものの速さだけでなく、調べ方も変わりました。 売れ残った商品にチェックを入れる欄が行ごとにありましたが、作った側の感覚は「うまく使えている顧問先は、なんとなくいない気がする」。そこで配布済みのファイルを機械的に走査してチェック率を数えたところ、本格的に使っているところがごく一部あり、大半は0〜1%でした。数字を取る前に消していたら、使っていたところが困っていたことになります。
以前なら誰かが何日もかけるか、外注するしかなかった作業です。
AIが決められなかったのは、どこか？
「どう作るか」はAIが引き受けました。決められなかったのは「何を作るべきか」のほうです。
今回の作り直しで効いた判断を4つ挙げます。いずれも、会計の要件と商売の都合の両方を知らないと出てきません。
① 集計を2枚に分けた。 顧問先が見たいのは「アカウントごとの購入上限に張り付いていないか」です。モールには購入上限があり、超えると仕入れられなくなるので、商売として死活問題になります。一方、事務所が見たいのは「仕入高だけ」。経費や私用が混ざったままでは帳簿に使えません。1枚で両方をやろうとすると、どちらにとっても使いにくくなります。 分けるという判断は、両方の立場を知らないと出てきません。
② 在庫の記録を、期末にまとめて確定する方式に変えた。 売れるたびにチェックを付けていく方式は、理屈としては正確です（会計でいう継続記録法）。しかし入力が続かなければ、結局は不正確になります。 期末に数える方式（棚卸法）が中小企業の実務で広く使われているのは、そういう理由です。「正確な方式」と「続く方式」が違うことを知らないと、正確なほうを選んで失敗します。
③ ポイントの二重差引を直した。 支払いに使ったポイントと、その買い物でもらったポイントは別のものです。支払いに使った分は原価を動かしません（カードで払うかポイントで払うかの違いだけ）。もらった分は自己負担ベースの原価を下げます。両方を差し引くと、利益が実際より大きく見えます。 旧版はここを取り違えていました。ツールの作り手が会計の理屈を知らないと、そのまま実装されて誰も気づきません。
④ 台帳の数字と帳簿の数字を、あえて一致させなかった。 台帳の「実質仕入額」は、もらったポイントを原価から引いた自己負担ベースの数字です。一方、帳簿ではもらったポイントを原価のマイナスではなく収益として計上します。だから2つは一致しません。これは設計ミスではなく、見る目的が違うからです。 一致させるべきかどうかの判断は、両方の目的を分かっていないと下せません。
AIに「仕入台帳を作って」と頼めば、それらしいものは出てきます。ただしこの4つは、頼み方の問題ではありません。 業務の中で何が問題になるかを知っていて、初めて要件として書けるものです。
AIは、何を間違えたのか？
「業務の実態と突き合わせないと検証できない場所」に、きれいに集中しました。
今回AIが誤ったのは3か所です。
- 仕訳をまとめる単位。 モールでの購入を「商品ごとに1件」と結論づけました。実際は決済ごとに1件です。
- 恒久マニュアルへの、その年だけの記述。 毎年使うマニュアルに、その年の事情を書きました。
- 実在しない販売モール。 シートのタブ名から拡大解釈して、扱っていないモールをマニュアルに書きました。
共通しているのは、どれも文章として自然で、読んだだけでは誤りと分からないことです。文法も論理も通っていて、業務の実態と突き合わせて初めて誤りになる。逆に、計算違いのような「その場で分かる間違い」はほとんど出ませんでした。
だから確認する場所は絞れます。業務の実態と突き合わせないと検証できない箇所を、先にリストにしておく。 今回なら、仕訳の単位・勘定科目の判定・扱っているモールの範囲の3つでした。AIが下書きし、税理士が確認する順序は崩していません。
作った直後から、何が壊れたのか？
モールの表記が変わったり、自分で構造を変えたりするたびに壊れました。
| 原因 | 何が起きたか |
| 外の都合 | モールが明細の末尾に注記を1行足した結果、取引日を取り出す式が動かなくなった |
| 外の都合 | モールがキャンペーン名を変え、前年ベースで作った自動仕分けの表が使えなくなった |
| 自分の変更 | 台帳の構造を変えたら、その形を前提にしていた事務所側の作業が動かなくなった |
| 検証不足 | サンプルでは動いた引っ越し機能が、実際のデータ量では途中で止まった |
やっかいなのは、半分だけ壊れるときです。 取引日を取り出す式は「文字列の末尾から10文字を取れば日付になる」という前提で書かれていました。モールが末尾に注記を足したので、注記が付いた行だけ壊れ、付いていない行はたまたま正しく取れていた。ポイントの明細199行のうち、101行——ちょうど半分です。全部壊れていれば気づきますが、半分だと画面を見ても分かりません。
いちばん大きな反省は、下流を見ていなかったことです。 顧問先の入力を楽にするために、シートの分け方と列の並びを変えました。ところが事務所側には、その台帳から「会計ソフトが自動で取り込めない支払い」を抜き出して、取り込める形に加工する作業があります。この作業が、変更前の列の位置を前提に組まれていました。 列を動かした時点で動かなくなっていたのですが、それが表面化したのは切り替えの案内から約3週間後、月次の処理に入ったときでした。
もうひとつ。AIは、データが欠けていることを教えてくれません。 会計ソフトが取り込めない支払いを洗い出したとき、前年より極端に少ない結果が出ました。集計は正しく、入力のほうが欠けていた——実店舗ぶんの記録が、年の途中からしか入っていなかったのです。「やけに少ないな」と思うのは人間の仕事でした。
並べてみると、作るのが速くなったこととは無関係に壊れていることが分かります。モールが表記を変えるのも、キャンペーン名が変わるのも、こちらの都合とは関係なく毎年起きます。
つまり、AIで作れるようになったぶん、持ち物が増えます。 そして持ち物は毎年壊れる。作るのが速くなっても、壊れたときに原因を特定して直す手間は変わりません。
では、何を作らないと決めたのか？
壊れると分かっているものと、使われていないものです。
- 注文確認メールの自動読み取り。 作ること自体はAIで現実的になりました。それでも見送ったのは、モールがメールの書式を変えるたびに壊れ、そのたびに直し続けることになるからです。却下の理由が「作れないから」ではなく「持ち続けられないから」に変わりました。
- ポイント還元の詳細な自動計算。 還元のルールは毎年変わるので、作った時点で、いつ壊れるかが分かっています。 代わりに、還元率を1つ手で入れる簡素な形にしました。
- 使われていなかった在庫チェック欄。 廃止しました。使われていない機能を持ち続けるのは、保守の手間だけを払っている状態です。
作れるようになると、作りたくなります。今回いちばん効いたのは新機能ではなく、この3つの「作らない」判断でした。
自社で業務ツールを持つなら、何を先に決めるか？
その業務を分かっている人が、設計に入っているかどうかです。
AIがあれば、手を動かす部分はかなり短縮できます。ただし短縮できるのは「どう作るか」までで、何を作るべきかは業務が決めます。 順番としては、こうなります。
- その業務で、何が問題になるのかを言葉にする。 上の①〜④のような判断は、要件として書けなければAIには渡せません。ここを飛ばすと、それらしいけれど使えないものができます。
- 毎日触る人が、続けられる形か。 理屈として正確でも、入力が続かなければ結局は不正確になります。正確さと続けやすさが衝突したら、続けやすさを取る。
- いま使っている機能のうち、実際に使っているのはどれか。 使っていないものは捨てる。感覚で消さず、数えてから決める。
- 本番と同じ量のデータで通す。 サンプルで動いたことを、動いたと数えない。
- 壊れたとき、誰がいつ直すのかを決めておく。 外部サービスの仕様は毎年変わるので、壊れない仕組みは存在しません。作った人が抜けたら止まる構成にしない。
1番がいちばん軽視されます。 AIがあると2番以降が速く進むので、要件が曖昧なまま作り始めてしまう。会計と商売の両方に関わる領域では、ここを詰められる人が設計に入っているかどうかで結果が変わります。
NOMERAは、受託開発・SES・広告・ECなどデジタル領域の企業に特化した、東京・西新宿の会計事務所です。オンラインで全国対応しています。
顧問契約の範囲内で、経理まわりの手作業を減らす仕組みづくりのご相談も承っています。業種や規模によってできることは変わりますが、同じ業種の顧問先が複数いる領域では、専用の台帳をお渡しできる場合があります。
この記事の内容が自社に当てはまるかを確かめたい方は、お問い合わせフォームからご相談ください。現在の税理士がいる場合の、セカンドオピニオンとしてのご相談にも対応しています。
※本記事は2026年9月時点の公開情報にもとづく一般的な解説です。個別の取扱いは事実関係により結論が変わるため、実行前に税理士へご確認ください。
よくあるご質問
Q. AIに頼めば、うちでも同じようなツールを作れますか？
A. 手を動かす部分は、以前よりずっと短くなっています。ただしAIは「何を作るべきか」を決めてくれません。 本文の①〜④のような判断——集計をどう分けるか、在庫をどの方式で押さえるか、ポイントをどう扱うか——は、会計の要件と商売の都合の両方を知らないと要件として書けません。ここが曖昧なまま作ると、それらしいけれど実務で使えないものができます。
Q. AIが作ったものは、そのまま信用してよいのですか？
A. 今回AIが誤ったのは3か所で、共通しているのはどれも文章として自然で、読んだだけでは誤りと分からないことでした。逆に、計算違いのような「その場で分かる間違い」はほとんど出ていません。だから確認する場所は絞れます。業務の実態と突き合わせないと検証できない箇所を、先にリストにしておく。AIが下書きし、税理士が確認する順序は崩していません。
Q. スプレッドシートではなく、市販の管理ツールではだめですか？
A. 商品情報の取り込みや在庫管理には優れた市販ツールがあり、顧問先も使っています。ただしそれらは販売と仕入の管理が目的で、税務申告に必要な形にはなっていません。仕入・経費・私用の区分、消費税率、期末の棚卸——このあたりは会計側の要件です。市販ツールと会計ソフトのあいだが埋まらないので、そこを台帳が引き受けています。
Q. 台帳の提供や不具合対応は、顧問料に含まれますか？
A. 顧問先向けに配布しているものです。ただし正直に書いておくと、台帳そのものの不具合対応を無制限に引き受ける約束はしていません。この線引きは最初にお伝えしています。