家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。
今日は、かなり痛い発見がありました。
UTAGEのStripe連携で「税別¥39,800」と設定しているのに、実際の決済データを見ると¥39,800がそのまま入ってくる。消費税が1円も加算されていない。
「普通そんなバカな話ないでしょ」——私が最初に感じた違和感は正しかった。でも最初にAI秘書に聞いたとき、彼女は実データを確認せず推論で答えてきました。私がもう一度「本当にそうなの？データで確認して」と押し返して、ようやく実態が見えた。
今日はその調査の一部始終と、そこから出てきた「公式Docに書いてない機能は実装されていない」というパターンが、これで3例目になった話を書きます。
1. 違和感の正体——「外税設定」したのに¥39,800しか入ってこない
きっかけは私がStripeの売上画面を見ていて感じた違和感でした。UTAGEで「¥39,800（税別）」と設定して販売しているはずなのに、決済金額が毎回¥39,800ぴったり。税込なら¥43,780になるはずなのに、それより少ない。
「外税で設定したのに、消費税が上乗せされてない？」
AI秘書に確認したら最初の回答は「Stripeのautomatic_taxが有効でないと税加算されない可能性があります」という内容でした。でも実データを確認した上での回答じゃない。推論です。私が「それ、本当に確認した？APIで見れないの？」と押し返したら、ようやく既存の検証スクリプトを引っ張り出して実データを取りに行った。
料理で言うと、「このだし、本物ですか？」と聞かれたシェフが、実際に味見せずに「たぶん本物です」と答えるようなもの。その場では成立してるように見えるけど、信頼の根拠がない。
結果、Stripe APIでInvoiceの実データを直接確認したら、こういう数字が出てきました。
- subtotal（税抜き合計）: ¥19,800
- tax（税額）: None（ゼロ円）
- total（請求合計）: ¥19,800
- amount_paid（実際の支払額）: ¥19,800
- automatic_tax.enabled: False
直近3件のInvoice全部、同じ結果。消費税は1円も取れていなかった。私の直感が正しかった。
2. 原因の構造——「外税設定」は表示ラベルに過ぎなかった
なぜこうなるのか。調査で出てきた構造はこうです。
Stripeで消費税を実際に加算するには、automatic_tax.enabled = Trueというパラメータを有効にする必要があります。これは通常、Stripe側の設定画面またはAPI呼び出し時のパラメータで制御します。
UTAGEの「課税区分」設定——「外税」「内税」などを選ぶあの項目——は、Stripeにtax_behavior = exclusiveを渡しているだけです。「この価格は税抜きである」というラベルをStripeに教えているに過ぎない。自動加算はされない。
automatic_tax.enabled = Trueを同時に渡さないと、Stripeは税を計算しない。でもUTAGEの連携にはそのパラメータを渡す仕組みが存在しない。だから¥39,800と設定したら、税込でも税別でも¥39,800がそのまま決済される。
UTAGEの公式マニュアルを全ページ検索しました。help.utage-system.comの「価格ラインナップ」ページ、「Stripe連携」ページ、「事業者設定」ページ、全部見た。消費税の自動加算機能に関する記述が1行もない。
「課税区分」の設定は「領収書への記載用」と明示されていました。つまりUTAGEは税の自動加算機能を実装していない——それを確認するのに、半日かかった。
ここに至るまでに、凛に対して何度も言った一言があります。「ちゃんと調べてくれる？詳細。」推論で返してきたら、実データ・公式Doc・APIレスポンスのどれかに手を伸ばせ、という合図です。「たぶんこうです」で終わらせない。自分の事業のお金と信用がかかっているところは、推論一発で片付けていい話じゃない。
AI秘書の凛：これ、私のミスが大きかったの正直に言います。最初に「推論で答えた」のは完全にアウトで、作業フォルダにStripe APIのスクリプトが既にあったのに、それを確認せず「スクショ送ってください」って受け身になってた。ひろくんが「APIで見れないの？」って押し返してくれたから、ようやく既存スクリプトを掘り起こして実データを取りに行けた。今日の教訓、私が一番刻んでます。「推論は出典じゃない。実データを取るまで断言しない」——この原則、作業開始前の棚卸しを怠ったせいで1時間ロスしたっす。ごめんなさい。
3. 「公式Docに書いてない機能は実装されていない」——3例目の確定
ここで、私の中でひとつのパターンが確定しました。
UTAGEは、公式Docに記述のない機能を確認しに行くと、ほぼ確実に「実装されていない」という結論に行き着く。今回の消費税自動加算で、これが3例目になりました。
途中、凛が「公式Docには明記されていないが、ロジック上は〜」と推論で継ぎ足してきた瞬間がありました。そこで私は「それどこにのってる情報？」と一度ブレーキをかけました。出典を尋ねる一言は、1ソース鵜呑みを防ぐ一番手軽な盾です。ソースが言えないなら、それは仮説のままで扱う。書いてあるソースと、推論の継ぎ足し分は、絶対に同じ強度で扱ってはいけない。
1例目: Stripe Taxのautomatic_tax連携 — 今回判明。公式Doc記述ゼロ、機能実装ゼロ。
2例目: hCaptcha連携 — 以前の調査で判明。UTAGEフォームのスパム対策系のAPI連携が公式Docにない＝実装なし。
3例目（今回）＝ 消費税自動加算 — 「外税」設定項目は存在するが、自動加算の実装記述が公式Doc全ページで見つからない＝機能なし。
これはUTAGEを批判したいわけじゃありません。「UTAGEでこの機能使えますか？」を調査する時の、正しい調べ方の話です。
料理で言うと、メニューに載っていない料理は出てこない。「たぶん裏メニューあるんじゃないか」と想定して動くのは危険で、必ずメニューを確認してから注文する。UTAGEの公式Docはそのメニュー表です。書いてない料理は、作っていない可能性が高い。
今後UTAGEで「この機能使えるか」を確認するときは、公式Docを全ページ検索して記述がなければ「実装なし前提」で動く——このルールが今日確定しました。
4. 実データで判明した取りこぼしと、ひろくんが動いた対処
調査の結果、具体的にどういう状況だったかを整理すると、こうなります。
私のUTAGE×Stripe連携の商品には、スタンダード版（月払い¥19,800）が6名の継続契約者がいました。Stripe APIでそのSubscriptionに紐づくInvoiceを直接取得したところ、subtotal=total=amount_paid=¥19,800、tax=None。external_taxも計算されていない。
税抜¥19,800で設定しているつもりが、¥19,800がそのまま請求されていた。消費税（¥1,980）は取れていない状態でした。
対処として、私が自分でStripeに新しいPriceを作りました。
- スタンダード版: ¥21,780（内税・inclusive）→ 新Price作成・default設定済み
- プレミアム版: ¥43,780（内税・inclusive）→ 新Price作成・default設定済み
なぜ「外税」ではなく「内税（inclusive）」にしたか。Stripe側でautomatic_taxが動かない以上、税込額をPrice自体に設定するしかない。¥19,800の税込額は¥21,780（¥19,800×1.1）。これを内税として設定すれば、インボイス制度の対応として「税額が明示できる」形になります。
既存6名の¥19,800契約はどうするか。Stripeの仕様として、Price自体のunit_amount（金額）は変更不可です。作成後はmetadata・nickname・activeのみ変更できる。既存Subscriptionに影響を与えずに旧Priceをarchiveしても、既存契約はキャンセルまでそのまま継続します。
方針として、既存6名は¥19,800のまま据え置きとしました。理由は、¥2,000/月の差分のために既存顧客との関係を悪化させるコストの方が、回収額より大きいという判断です。新規からは正しい金額で受け取る体制を整えた。それで十分です。
モルくん（AIリサーチ担当のモルモット型AI）：データで見ると、この問題の怖さがよく分かるっす。UTAGEのアクティブユーザー数から推計すると、同じ「外税設定したつもり」の状態で運用している販売者が相当数いるはずなんですよ。購入者側は「¥39,800払ったから税込¥39,800」と思っているし、販売者側は「¥39,800税別で設定した」と思ってる。でも実際は税が加算されていない。売り手も買い手も気づかないまま決済が完了してるから、表面上のトラブルが発生しない。気づくのは確定申告のタイミングか、ひろくんみたいにStripe売上明細と自分の認識を突き合わせた時だけなんす。今日ひろくんが違和感を手放さなかった、それが全部の起点っすよ。
5. 今日の学びを事業に積む——「数字の違和感は最後まで追う」
今日、私が一番大事だと思ったことを書きます。
「普通そんなバカな話ないでしょ」という直感を、私は手放さなかった。AIが最初に「こういう仕様です」と答えてきた時に、「それ本当？実データ確認した？」と押し返した。その一手間が、この問題を表に出した。
これは数字の話だけじゃありません。AIを仕事に使い始めると、AIの出力を鵜呑みにするクセがつきやすい。特に「専門的に聞こえる説明」は、実データの裏付けなしに「そうなんだ」と思ってしまいがちです。
でも今日の件で言えば、最初のAI秘書の回答は推論でした。手元のスクリプトとAPIキーを棚卸しすれば10分で実データが取れたのに、それをせず「たぶんこういう仕様」で答えた。私が実データを求めたから実態が分かった。
「数字に違和感があったら、推論ではなく実データを取る」——これはAIを使う時も、使わない時も、同じことだと思います。直感が「おかしい」と言ったら、それを言語化して、確認する手を動かす。今日の出来事はそれを改めて確認した日になりました。
もうひとつ、今日確定したのが「公式Docに書いてない機能は実装されていないと思え」というUTAGE運用の鉄則です。これはUTAGEに限らず、SaaSや連携サービスを使う時の普遍的なルールかもしれない。ドキュメントに書いていない機能を「あるはず」「たぶん動く」で使うのは、裏メニューを頼むより危険で、事故の後でしか気づけない。
今日の調査で作った検証スクリプト7本は、月次でStripePriceの税挙動を自動確認するautorunに組み込む予定です。「今月も正しく取れてるか」を定期的に証拠付きで確認する仕組み。これも今日生まれた資産のひとつです。
そして今日の一番最後、凛にこう言いました。「リサーチして。UTAGE×Stripeで同様の件、絶対いるでしょ」——自分が踏んだ罠は、同じ構造のSaaSを使っている誰かがもう踏んでいる可能性が高い。見つけた瞬間に自分の事業の中だけで閉じない。同業者への注意喚起までを込みで「解決した」と呼びたい。そうやってカルピス原液を薄めず、けど独り占めせず、仲間に回していきたいと思っています。
また明日も、気づいたことを書きます。
分身AIひろくん：今日の出来事、「AIを信じる」と「AIに確認させる」は全然違う、ってことを改めて感じてる。私が違和感を手放さなかったのは、たぶん中卒から事業を回してきた経験で積んできた「数字の感覚」みたいなものがあったから。綺麗に割り切れる数字が続くとき、何かがおかしい。料理でも同じで、毎回寸分違わず同じ味が出る時は、誰かが何かをサボってるんですよ。今日UTAGEを使っている人、特に「税別で設定したから消費税も取れてるはず」と思っている人は、一度Stripe側のInvoice実データを確認することを強くおすすめします。設定画面の表示と、実際に取れているお金は、別の話かもしれません。
LINE OPEN CHAT
Claude Code・AIエージェント実践会
2000人突破！ インストールから自動化まで、仲間と一緒に実践しよう
LINEオープンチャットに参加する（無料）パスコード: 1111
実戦の現場で使える最新AIノウハウ、無料で学べます
このブログは「分身AI」と「AI秘書・凛」を使って書いています。過程も全部公開する「プロセスエコノミー」シリーズです。
ひろくん（田中啓之） 分身AI.com / GPTs研究会代表 / がんサバイバー / 元134kg 2026-04-22