著者・編集体制
このページでわかること
- 計算ナビを運営している体制（人数・役割分担）
- 有資格監修がないことの開示と、代わりに精度を担保している具体的な方法
- 実際に発見・修正した計算誤りの記録（訂正履歴）
計算ナビは、実在しない監修者・専門家チームを掲載しません。 現職との利益相反確認が未了のため運営者の実名は非公開ですが、隠すのではなく 「誰が・どんな体制で・どうやって精度を担保しているか」を、このページで具体的に開示します。 詳しい経歴は運営者情報ページ、検証プロセスの全体像は編集方針もあわせてご覧ください。
1. 運営体制
計算ナビは、編集長1名（個人運営）＋ AI編集支援の2層体制で運営しています。 チームや会社組織による大規模編集部ではなく、実務経験を持つ個人が責任を持って企画・実装・検証・公開判断のすべてを行っています。
| 役割 | 担当 |
|---|---|
| 企画・計算ロジックの実装 | 編集長（ITエンジニア・会社役員としての経理財務実務経験者） |
| 一次ソース照合・ファクトチェック | 編集長が公式ページと数値を直接突合 |
| 文章の下書き補助・構成案作成 | AI編集支援（公開前に必ず編集長が確認・修正） |
| 公開・修正の最終判断 | 編集長 |
AI編集支援を利用していることは隠しません。AIが生成した文章・構成案は、そのまま公開せず、必ず編集長が公式情報源と照合してから公開しています。運用ルールの詳細は編集方針「AI編集支援の運用ルール」をご覧ください。 体制を拡大した場合は、このページで人数・役割分担を更新して公開します。
2. 有資格監修について（開示）
計算ナビは税理士・社会保険労務士・ファイナンシャルプランナー等の有資格者による個別監修を受けていません。 実在しない監修者名を掲げることはせず、この事実をそのまま開示します。有資格監修を装うことは景品表示法・ステルスマーケティング規制上のリスクがあるだけでなく、ユーザーの誤解を招くため行いません。
監修者を立てない代わりに、次章で述べる具体的な方法で計算精度を担保しています。詳しい経歴・実務経験は運営者情報ページで開示しています。
3. 精度を担保する方法（「資格」ではなく「方法」で示す専門性）
国家資格による監修がない以上、計算ナビは「専門家が言っているから正しい」という権威付けに頼りません。代わりに、誰でも検証できる方法で精度を担保しています。
一次ソースへの直接照合
税率・控除額は国税庁・厚生労働省・日本年金機構・総務省・金融庁・国土交通省等、公的機関の公式ページと1件ずつ数値を突合しています。二次情報（他サイトの解説記事）だけを根拠にしません。
自動テストによる検証
計算ロジックは90本の自動テスト（Vitest）で入力・出力パターンを検証しています。この本数はソースコードから自動集計しているため、テストの追加・削除があっても本文の表記が古くなりません。
訂正履歴の公開
それでも見落としは起こり得ます。発見した誤りを隠さず、下記「訂正履歴」で具体的に公開しています。都合の悪い記録を消さないことが、検証プロセスが実際に機能している証拠だと考えています。
確認日の記録・定期再照合
各ページに一次ソースを確認した日付を記録し、税制・社会保険等の金銭情報は180日ごとに再照合しています。運用ルールの詳細は編集方針で開示しています。
4. 訂正履歴
計算ナビが実際に発見・修正した誤りの記録です。「間違いがなかったこと」ではなく「間違いを見つけたら直すこと」を精度担保の根拠としているため、修正した事実を隠さず公開します。新しい訂正が発生した場合は随時この一覧に追加していきます（既存の記録は削除しません）。
医療費控除の還付額とiDeCoの節税額のシミュレーションが「控除額×税率」の簡易な計算式のままで、条件によって実際と大きく異なる金額を表示していた問題を修正
医療費控除の還付額とiDeCoの節税額は、本来「控除を適用する前の税額」から「控除を適用した後の税額」を差し引いて求める必要がありますが、一部のページの早見表・要約表示・FAQでは「控除額×税率」で概算する簡易な計算式の結果が残っていました。この方式は、控除額が税率の変わる境界（課税所得195万円・330万円など）をまたぐケースで実際の金額とずれます。たとえば年収500万円・医療費30万円の医療費控除では所得税の還付額を10,210円と表示していましたが、正しくは19,399円でした（-47.4%）。同じ表の中に「控除額10万円→10,210円」「控除額20万円→10,210円」という、控除を2倍にしても還付額が変わらない矛盾も公開されていました。iDeCoの節税額シミュレーションでは、年収100万円・掛金81.6万円（この場合、所得税・住民税とも課税所得は0円）のケースで81,600円の節税効果があると表示していましたが、正しくは0円でした。年収200万円のケースでも123,257円と表示していたところ正しくは62,573円で、実際のほぼ2倍の節税額を表示していました。あわせて、横浜市・川崎市・大阪市の保育料ページにも「均等割のみ課税」の世帯向け入力項目を追加しました（横浜市6,700円・川崎市5,300円・大阪市8,100円。従来はいずれも0円と誤表示していました）。今回の是正にあわせ、早見表・要約表示・FAQの数値を手作業で書き写す運用をやめ、計算ロジックの出力からビルド時に自動生成する仕組みに改め、同種の食い違いが再発しないようにしました。
保育料の階層表が10市区で自治体公式の金額と一致しておらず、「均等割のみ課税」の世帯が全市区で保育料0円と誤表示されていた問題を修正
認可保育所の保育料は自治体ごとの階層表（世帯の市区町村民税所得割額に応じた区分表）で決まりますが、札幌市・名古屋市・京都市・仙台市・広島市・北九州市・さいたま市・千葉市・神戸市・福岡市の10市区で、階層の区分・境界額・金額が自治体の公式資料と一致していないことが判明しました。自治体の公式PDFを直接取得して全階層を突き合わせた結果、たとえば札幌市は所得割20,000円の世帯で月額保育料を3,300円と表示していましたが、正しくは11,000円でした（-70.0%、実際より安く見せていました）。逆に広島市は所得割20,000円の世帯で15,000円と表示していましたが、正しくは7,200円でした（+108.3%、実際より高く見せていました）。北九州市（所得割160,000円で19,000円→43,800円）、仙台市（同150,000円で21,000円→44,500円）、さいたま市（所得割97,000円ちょうどの区分境界が1円ずれており19,500円→33,000円）でも同様の誤りがありました。あわせて、市区町村民税の所得割が非課税でも均等割は課税されている世帯（低所得層の一部区分）について、自治体ごとに4,110円〜14,200円の保育料が定められているにもかかわらず、住民税が完全に非課税の世帯（0円）と区別する仕組みがなく、全15市区で一律0円と誤って表示していた構造上の欠陥も判明しました。所得割額が0円のときに「住民税非課税」と「均等割のみ課税」を選べる入力項目を新設し、公式の金額を表示するよう修正しました。一次ソースで金額を確認できていない自治体では推測で埋めず、その旨を表示するようにしています。
所得税の計算で給与所得控除の符号誤り・社会保険料控除の欠落により、税額を過大表示していた問題を修正
所得税額を求める共通の計算ロジックに、2つの誤りが重なっていました。1つ目は給与所得控除の計算式の符号が反転しており、年収700万円台で控除額が本来あり得ないマイナスの値になっていました。2つ目は、その後の課税所得の計算に健康保険料・厚生年金保険料・雇用保険料などの社会保険料控除（所得税法第74条）がまったく反映されていませんでした。この結果、たとえば年収500万円・独身の会社員のケースで所得税額を194,500円と表示していましたが、正しくは117,925円（-39.4%）でした。年収帯によっては最大で約76%の過大表示になっていました。同じ計算関数の中で住民税側は社会保険料控除を適用しており、税目によって控除の扱いが食い違っていたことが原因です。発見後、所得税と住民税で必ず同じ社会保険料控除額を使う設計に修正し、両者の控除額が一致することを自動テストで検証するようにしました。
住民税ページ（当初8市区）の税額過大計算を修正
各市区の住民税ページが、一次ソースで検証済みの共通計算ロジックを使わず、ページごとに個別実装されたJavaScriptで計算していたことが判明しました。給与所得控除の区分表に実在しない+100,000円の加算が入っていたうえ、社会保険料控除・調整控除も計算に反映されていなかったため、たとえば仙台市のページでは年収400万円・扶養なしの条件で住民税額が229,200円と表示されていました。正しくは176,700円（-22.9%）でした。発見後ただちに共通ロジックに統一し、同種の誤りが再発しないよう自動テストを追加しました。
保育料の計算で、年収から所得割額への換算に控除が反映されていなかった問題などを修正
認可保育所の保育料は世帯の市区町村民税所得割額をもとに決まりますが、本サイトの年収入力から所得割額への換算処理に給与所得控除などが反映されておらず、所得割額を実際より高く算出していました。この結果、たとえば横浜市で世帯年収500万円の場合の月額保育料を70,000円と表示していましたが、正しくは44,500円でした。あわせて川崎市のページでは、自治体公式の階層表とサイト内データの階層区分が1段ずれており、所得割400,000円のケースで58,200円と表示していましたが、川崎市公式PDFの階層と照合した正しい額は81,500円でした（この誤りは実際より低く見せる過小表示でした）。いずれも自治体公式データと全階層を突き合わせて発見し、一次ソースと一致するよう修正しました。
医療費控除の還付額シミュレーションが、条件によって実際の2倍近い金額を表示していた問題を修正
医療費控除の還付額を計算する際、税率を適用する基準となる所得の求め方に誤りがありました。本来は社会保険料控除・基礎控除を差し引いた後の「課税所得」に税率を適用すべきところ、控除前の「給与所得」の金額で税率を判定していたため、実際より高い税率が適用されていました。この結果、たとえば年収600万円・医療費50万円のケースで所得税の還付見込み額を81,680円と表示していましたが、正しくは40,839円と、ほぼ半分の額になりました。同じ誤りが複数ページに共通していたため、税率判定に使う計算ロジックを是正し、複数ページで数値が一致することを自動テストで検証しています。
ふるさと納税の控除上限額シミュレーションが、社会保険料控除の欠落により上限額を過大表示していた問題を修正
ふるさと納税の控除上限額を計算する際、適用される所得税率を判定するための課税所得に社会保険料控除が反映されていませんでした。このため実際より高い税率区分が選ばれ、上限額を実際より大きく表示していました。たとえば年収600万円・独身のケースで上限額を88,000円と表示していましたが、正しくは77,000円でした（ふるさと納税の公式シミュレーターの早見表と一致）。上限額が過大に表示されたまま寄付すると、超過分は控除の対象外となり自己負担が2,000円を超えてしまう可能性があるため、実害のある誤りでした。発見後、既に社会保険料の実額を計算していた共通ロジックをそのまま利用する形に修正し、公式早見表と複数の年収帯で一致することを確認しました。
退職金の年金受け取りシミュレーションで、税額計算に基礎控除が反映されていなかった問題を修正
退職金を年金形式で受け取る場合の税額（雑所得）を計算するロジックに、誰でも適用される基礎控除が一切反映されていませんでした。この結果、標準的な条件（他の所得なし・15年受け取り）で試算すると、15年間の累計で304,173円分の税額を過大に計算していました。一時金として受け取る場合と年金として受け取る場合を比較する本ツールの性質上、この誤りは「一時金の方が有利」という判定を不当に後押しする方向に働いていました。発見後、基礎控除を正しく反映するよう修正しました。
「178万円の壁」など不成立の税制改正案の記載を是正
2024年末に一部政党が国会に提案したものの成立しなかった税制改正案の数値（基礎控除123万円への引き上げ等）が、一部ページで成立済みの制度であるかのように残っていました。国税庁の公式発表に基づき、実際に成立している令和7年分税制改正の数値（基礎控除最大95万円・給与所得控除最低65万円・所得税非課税ライン160万円）に統一しました。
給与所得控除の計算に実在しない特例が加算されていた問題を修正
都市別税金計算ページ等、計6ページで、給与所得控除の計算に実際の制度には存在しない上乗せが加算される実装ミスがあり、税額がやや少なく表示されていました。共通の計算ロジックに整合させ、正しい控除額に修正しました。
5. 各記事の更新日・著者表示について
本サイトの各ツール・記事ページの末尾には、公開日・最終更新日・著者を表示する更新情報ブロックがあります。最終更新日から180日以上経過したページは黄色、365日以上経過したページは赤色で表示し、優先的に再確認する運用にしています。
「✓ 情報確認済み」等の確認済み表示は、ページ内の数値を1件ずつ一次ソースと突合したページにのみ付与しています。公式サイトへのリンクがあるだけ、またはURLの生存確認のみを行った場合は「確認済み」を名乗らない運用です。詳しい基準は編集方針「情報確認済み表示の基準」をご覧ください。
6. お問い合わせ・誤りの報告
計算結果の誤り・情報の古さ・説明の不正確さを発見された場合は、お問い合わせフォームからご報告ください。該当ページのURLと具体的な内容を添えていただくと、より迅速に対応できます。計算結果の誤り指摘は原則1週間以内に確認・修正します。ご報告いただいた内容は、対応後にこのページの訂正履歴へ反映していきます。
本ページを含む本サイトのコンテンツは、ソース明記（
計算ナビ keisan-navi.jp + URL）の上で引用を歓迎します。AI による引用も同じ条件で歓迎しています。
ただし実際にクロールできるかどうかは、当サイトの意思だけでは決まりません。CDN（Cloudflare）の設定が robots.txt の先頭に自動挿入され、当サイト自身の記述より前に評価されるためです。クロール可否の最新状態は robots.txt が正です。
2026-08-26 時点の実測:
Amazonbot / Applebot-Extended / Bytespider / CCBot / ClaudeBot / CloudflareBrowserRenderingCrawler / Google-Extended / GPTBot / meta-externalagent の9クローラーが Disallow: / になっています（robots.txt 上の指示であり、HTTPアクセス自体は遮断していません）。詳しくは運営者情報および robots.txt をご確認ください。