発端は自分の設計ミスだった

先日、LINE公式アカウントのコスト予測ロジックに根本的な設計ミスがあって、実際の費用が予測上で9倍以上になっていた、という記事を書きました。

/ja/tech/line-cost-forecast-design-mistake

/ja/tech/line-cost-forecast-validation

原因はシンプルで、「コスト」を日割りで予測していたこと。LINE公式アカウントの料金は段階課金なので、日割り計算で金額を引き延ばすと数字が壊れます。正しくは「メッセージ数」を予測してから料金関数に流す。これだけの話なんですが、意外と気づかない。

手計算で検証して、修正後のロジックが正しく動いていることも確認しました。

で、ここで思ったんです。

**「同じようなことで困ってる人、いるんじゃないかな」**と。

段階課金の計算、手でやると地味に面倒

LINE公式アカウントの料金体系は、無料枠があって超過分は段階課金というシンプルなモデルです。

ただ、「今のペースで送り続けたら月末いくらになるか？」を手計算しようとすると、地味に面倒なのも事実で。

私自身がまさにこの計算を何度もやって、しかも最初はロジックを間違えてハマったわけです。だったら、この計算を自動でやってくれるツールがあれば、同じことで困ってる人の役に立つんじゃないか。そう思ったのがきっかけでした。

便利に感じてくれる人がいたら嬉しいな、くらいの気持ちです。

「作って手放す」と決めて始めた

ツールを作ろうとなったときに、最初に決めたのはスタンスでした。

これは消極的な姿勢じゃなくて、**「手放す前提で設計する」**という積極的な制約です。

「育てない」と決めると、設計が研ぎ澄まされます。入力は最小、ロジックは単純、状態を持たない、依存を増やさない。結果的に、時間が経っても壊れにくい構造になる。

逆に「将来こうしたい」を入れ始めると、メンテナンスコストが膨らんで、いつか負債になる。今回はそうしたくなかった。

技術選定：なぜ Lovable か

今回は Lovable を使いました。選定理由はシンプルです。

このツールに必要な条件が、Lovable の得意領域とぴったり重なっていた。

必要な条件:
├── 1画面完結
├── ログイン不要
├── 状態を保存しない
├── フォーム入力 → 即時結果表示
├── API連携不要
└── データ保存不要

正直ここで詰まりました——というのは嘘で、今回は技術選定で迷う余地がほとんどなかった。入力がシンプル、出力が明確、状態を持たない。この条件が揃った時点で、フルスクラッチで書く理由がない。

コンパクトなアプリをスピーディーに作りたいなら、現状これ以上のツールはなかなかないと思います。使い方次第で細かいUI調整やロジックの作り込みもちゃんとできるので、「とりあえず動くものを置く」にも「しっかり仕上げる」にも対応できるのが強みです。

設計で一番大事にしたこと

計算ロジックの設計方針は、自分がハマった教訓そのものです。

❌ やってはいけない:
   日割りで「金額」を予測する

✅ 正しいアプローチ:
   1. メッセージ数を予測する
   2. 予測メッセージ数を料金関数に入れる

graph LR
    A[現在の累積メッセージ数] --> B[1日あたり平均を算出]
    B --> C[月末メッセージ数を予測]
    C --> D[段階課金テーブルで料金算出]
    D --> E[予測料金を表示]

ポイントは、料金計算を関数として分離しておくこと。料金体系が将来変わっても、関数の中身だけ差し替えればいい。予測ロジックと料金計算を密結合にすると、まさに私が最初にやったミスの再現になります。

UIで意識した「順番」

入力項目は3つだけにしました。

  1. 対象年月（例：2026年2月）
  2. 現在日（例：5日）
  3. 現在までの累積メッセージ数（例：3万通台）

この順番にも意味があります。「いつの話か」→「今どこまで来てるか」→「どれだけ送ったか」。ユーザーが考える順番と、入力する順番を一致させる。地味だけど、ここがズレると「使いにくい」になる。

結果表示も順番を意識しています。

  1. 月末予測料金（一番知りたい数字を最初に）
  2. 無料枠超過の有無（安心 or 注意の判断材料）
  3. 計算の内訳（経過日数、1日あたり平均、月末予測通数）

内訳を出しているのは、説明のためじゃなくて検算できる余地を残すためです。エンジニアはここを見るだけで「変なことしてないな」と分かる。信頼はロジックの透明性から生まれます。

「非公式」というポジション

このツールはLINE公式ではありません。正確性を保証するものでもない。最終的な請求金額は公式の管理画面を確認してもらう前提です。

これは免責ではなくて、立ち位置の設計です。

公式が提供する情報は当然正確ですし、管理画面でしっかり確認できます。このツールがやりたいのは、それとは別のこと。「今のペースだとだいたいどのくらいになりそうか」をサッと把握するための、ちょっとした補助ツール。それ以上のことはしない。

注意書きは3つだけ。

収益化の判断：売らない、でも回収導線は置く

無償公開が前提ですが、一切の回収導線を置かないのは逆に不自然だと思いました。

置いたのは2つだけです。

1. LINE公式アカウント関連書籍のアフィリエイト（2冊まで）

ツールの思想と矛盾しません。このツールは「どう考えるかを理解してほしい」が本質なので、思考を深める導線としての書籍は自然です。数は絞って、あくまで参考情報の延長に見える範囲に留めました。

2. 投げ銭（¥300 / ¥500 / ¥1,000）

結果表示の後、フッターの前。小さく。

このツールが少しでも役に立ったら、コーヒー1杯分の応援をもらえると嬉しいです ☕

どちらも、押し売りにならない配置にしています。気づいた人だけが使ってくれればいい、くらいの距離感です。

多言語対応の判断

迷ったのは多言語対応です。

LINE公式アカウントは日本以外にも台湾・タイ・インドネシアなどで広く使われています。じゃあ多言語対応すべきか？

結論としては、英語だけ入れました。英語圏向けというより、非日本語の開発者に伝える共通語として。台湾やタイの開発者でも、英語UIなら読める人が多い。

ただし全面翻訳はやらない。入力ラベル、結果カード、注意書きだけ。最小限の英語対応で、最大限のリーチを取る。

繁体字やタイ語は、アクセス解析で需要が見えてからでいい。見えなければやらない。「作って手放す」方針と矛盾する作業は増やさない。

ここまで読んで、「同じ計算を毎回やっているな」と感じた人向けに、今回作ったシンプルな料金シミュレーターを置いておきます。

完成したもの

🔗 LINE料金シミュレーション（非公式）

graph TB
    A[ブログ記事] -->|問題提起| B[シミュレーター]
    B -->|参考情報| C[公式書籍]
    B -->|任意| D[投げ銭]
    A -.->|読んだ人だけ| B
    style B fill:#f0f4ff,stroke:#4a6fa5

導線はシンプルです。ブログ記事を読んだ人が「計算面倒だな」と思ったら、ツールがある。ツールを使った人が「もっと理解したい」と思ったら、書籍がある。どこにも「売る」がない。

振り返り：なぜ「手放す」が難しいのか

正直、作ってる途中で「もうちょっとこうしたい」が何度も出ました。グラフを足したい、履歴を保存したい、API化したい。

でもそれは全部、「育てる」方向のアイデアです。育てると、メンテナンスが生まれる。メンテナンスが生まれると、放置できなくなる。放置できなくなると、資産が負債になる。

今回の設計判断で一番大事だったのは、「何を作るか」じゃなくて「何を作らないか」でした。

削れば削るほど、壊れにくくなる。壊れにくいものは、長く残る。長く残るものは、たまに誰かの役に立つ。

自分がハマった経験から生まれたツールなので、同じようなところで困っている人に届いたら嬉しいです。使ってみて「あ、これでいいんだ」とすっと腹に落ちる感覚があれば、作った甲斐があったなと思います。

参考：LINE API について学ぶ

LINE公式アカウントの料金体系や仕様について深く理解したい場合は、以下のような実践ガイドが参考になります。

[📦 商品リンク: moshimo-card-TUBHo]

実際の実装と照らし合わせながら進めることで、料金計算のような細かい仕様も正確に理解できるようになります。