KAZENAKAZENA
記事一覧へ

公式サンプルの64,000,000は、誰も払っていない金額だった

2026年9月14日 · Taro(KAZENA代表)

64,000,000という数字を、私は3週間ほど本物だと思っていました。年次の様式のために配られている、公式サンプルと呼ばれるXMLファイルの中に入っていた金額です。開くと、様式の要素がひととおり順番に並んでいて、その中に実額らしい数字が入っています。これが実際の申告の姿だ、と私たちは読みました。

どれくらい深く入り込んでいたかを書きます。手元に仕様をまとめた表があって、様式のどの欄に何を入れるかを1行ずつ書いています。その表の17行が、出典としてこのファイルの名前を挙げていました。テストに使う見本のファイルも、このサンプルを写して金額だけ差し替えたものです。つまり、私たちの出力が正しいかどうかを判定していたのは、このファイルでした。

気づいたのは偶然です。文字コードの確認をしたくて、整形せずにテキストエディタで開きました。先頭にコメントが1行入っています。Created with Liquid Technologies と書いてありました。少し下を見ると、納税者番号の欄が x を16個並べたものになっています。さらに読むと、任意の欄まで全部埋まっていて、文字列の欄はどれも、スキーマが許す最大の長さちょうどでした。

つまりこのファイルは、スキーマ(XSD)から機械が自動で作った見本です。要素の名前、並ぶ順番、入れ子の形、どれが必須でどれが任意か——形については、これ以上ないくらい正確です。一方で、中に入っている値は、その型の欄を埋めるために機械が置いたものです。64,000,000を払った人はいません。この金額を受け取った役所もありません。

何が起きたかを書きます。サンプルには任意の節まで入っていたので、私たちはその節を、条件に関係なく毎回出力していました。実際のCoretaxは、その節が付いたファイルを受け付けません。最初に拒否されたとき、私たちは自分の書いたコードの側を4日ほど探しました。出力の形はサンプルと1文字も違わないのだから、原因はこちらの別の場所にあるはずだ、と考えたからです。前提のほうが間違っているとは、考えていませんでした。

Vに聞きました。ジャカルタの会計士で、自分の事務所の実データでKAZENA Booksを試してくれている人です。実際に提出した年次の様式の中身はこの形か、と尋ねると、彼女は自分の事務所で出した分を開いて、どの要素が入っていて、どの要素が無いかを教えてくれました。問題の節は、最初から存在していませんでした。3週間サンプルを読んで分からなかったことに、現物が一度で答えました。

決めた規則を書きます。仕様の表の1行ごとに、出典と、その出典の格を書きます。格は4つです。1つ目は現物——実際のシステムが出した、あるいは受け付けたファイル。2つ目は人の確認——実務をしている人が本番の画面で確かめてくれたもので、確かめた日付も一緒に書きます。3つ目は制度の条文、またはスキーマそのもの。4つ目が、機械の作った見本と、こちらの推測です。そして、4つ目だけを根拠にした動きを、黙って製品に入れないことにしました。

この規則で17行を引き直しました。6行は現物に置き換わりました。5行は条文で裏が取れました。4行はVの確認で埋まりました。残った2行は、どこにも出典がありませんでした。サンプルにそう書いてあった、以外の理由が無かった、ということです。その2行が支えていた動きは、製品から外しました。

公式、という言葉が、ここでかなりの仕事をしていました。公式に配られているファイルなのだから、中の1バイトまで公式だろう、と私たちは読みました。実際に公式なのは、そのファイルが従っているスキーマのほうです。中の数字は、スキーマを説明するために置かれた飾りでした。悪いのはサンプルではありません。サンプルをサンプルとして読まなかったこちらです。

製品の側も直しました。以前は、入力が足りないときに、この欄は必須です、とだけ出していました。いまは理由を分けて書きます。スキーマで必須と決まっている欄と、無いまま出して実際に拒否された欄は、別の文にします。テストの見本も、サンプルの写しをやめて、実際に受け付けられたファイルを元にしました。番号は、明らかに作り物と分かる形に置き換えてあります。9を16桁並べたようなものです。本物の番号を、こちらのテストの中に置いておきたくありません。

役所のシステムに合わせて何かを作っている人に、ひとつだけ伝えたいことがあります。いま頼りにしている数字を、誰が作ったのかを確かめてください。機械がスキーマを埋めた値、資料に載っている値、実務家が記憶で答えてくれた値、そしてシステム自身が出したファイル——画面の上では、この4つは同じ顔をしています。同じ黒い文字で、同じ桁数で並びます。違うのは、それが外れていたときに、どこまで遡って直さなければいけないかです。

念のため書いておきます。私は税理士ではありません。年次の様式に何を書くか、どの欄が必須かは、制度の側で決まっていて、変わっていきます。ここに書いたのは、こちらが根拠の扱いを間違えたという記録です。実際の申告の判断は、必ず専門家に確認していただくようお願いします。

最後にお願いがあります。KAZENAの画面で、必須と書いてあるのに理由の分からない欄があれば、教えてください。こちらの根拠が、4つ目の格のままになっている可能性があります。根拠の格は、使う人には見えません。見えないものを正しく保つのは、こちらの仕事です。

あなたの声を聞かせてください

KAZENAのアプリを使った感想、直してほしいところ、「こんな機能が欲しい」という提案——インドネシアやフィリピンの中小企業オーナーさん、フリーランスの方の声こそ、私たちが一番聞きたいものです。インドネシア語・英語のメッセージには、現地を知り尽くした仲間が応えます。また、KAZENA Booksはフィリピンとインドネシアでの展開がすでに決まっています。それ以外の国で一緒に展開してくださるパートナー企業様、システムのご購入をご検討の企業様も、お気軽にご連絡ください。新しいシステム開発のご相談もお受けしています。少人数のチームのため、すぐの着手をお約束できないこともありますが——日本品質(メイド・イン・ジャパン)のものづくりで、現地の商売に寄り添う開発を、一件ずつ丁寧に。

お問い合わせへ

他の記事もどうぞ