Blacksmith CI 請求論争：無料トライアルユーザーへの請求

Blacksmith が無料トライアルユーザーに $1,000 超過料金を請求

Blacksmith は、GitHub Actions の代替として YC の支援を受けているサービスで、サインアップ時にクレジットカード不要の「無料で試す」プランにもかかわらず、利用料として $1,000 超過分を請求したことが問題視されています。この事例は、無料トライアルは通常、サービス利用の上限をハードキャップとして設定するという SaaS の慣行から大きく逸脱していることを示しています。

このケースでは、ユーザーは無料分の分数を超えた後に「サービスの中断」を防ぐためにクレジットカードを追加するよう警告を受けました。しかし、Blacksmith のサポートは後に「中断」とはサービスが停止することではなく、アカウントがレビューや停止の対象になる可能性があることを意味すると説明しました。CI ワークフローを停止せずにそのまま実行させ、公開料金で課金を続けた結果、最終的に $1,081.45 の請求書が発行されました。

慣例と利用規約の対立

ほとんどの SaaS ユーザーは、クレジットカード不要の無料トライアルは課金が発生しないイベントであると期待しています。すなわち、サービスは無料で継続するか、上限に達した時点で利用できなくなるかのどちらかです。Blacksmith のアプローチは、事前支払い／上限モデルから事後支払い／請求モデルへと、ユーザーの明示的な同意なしに移行させた点で問題視されています。

主な争点

曖昧なコミュニケーション："disruption to service"（サービスの中断）という表現は、ユーザーにはサービス停止と解釈されましたが、会社側は管理上のフラグ付けプロセスを指していました。
利用規約：一部の観察者は、Blacksmith の利用規約が「支払い情報の提供があった場合にのみ請求できる」ことを示唆しており、実際の請求行為と規約の間に矛盾がある可能性を指摘しました。
業界標準：コメント投稿者は、従来の事前支払いサービスに事後支払い価格を適用することは「ダークパターン」または「詐欺的な手法」だと論じ、ユーザーの前提に依存して収益を上げようとしていると批判しました。

Blacksmith の回答と正当化

Blacksmith のプロダクトリードである Greg は、ユーザーが価値を感じなかった場合は請求を積極的に追求しないと述べ、ポリシーの背景を次のように説明しました。

摩擦の削減：クレジットカードを事前に要求しないことで、より多くの無料ユーザーや OSS プロジェクトを支援したいという意図がありました。
ビルド失敗の回避：CI ワークロードを完全に停止させることは過酷すぎると考え、ビルドが失敗し、手動でコードを修正しなければならない事態を防ぎたかったのです。

Blacksmith は二つの主要な改善策を約束しました。まず、無料枠が使い切られた後にランナーを停止するか継続させるかをユーザーが明示的に選択できる「Wallet」機能の実装、次に請求やメトリクスの表示を改善し、可視性を高めることです。

コミュニティの視点と代替案

議論は、実務的な開発者とこのような請求慣行を信頼の裏切りと見る人々の間で深い分断を浮き彫りにしました。

"開発中に CI を突然止めたくないという気持ちは分かりますが、無料分を負債に変える前に非常に明確な同意ステップが必要です。"

元投稿者は GitHub Actions に比べてパフォーマンス上の利点があるため Blacksmith の利用を続けることにしましたが、他の開発者は同様の請求サプライズを回避するために以下の代替案を提案しています。

セルフホストランナー：VPS 上で Woodpecker などのツールを使う、あるいは AWS 上で Firecracker VM をオーケストレーションする。
代替ランナーサービス：Depot、WarpBuild、Namespace.so、Avrea といったプロバイダーを紹介。
Runs-on.com：AWS 上で GitHub のセルフホストランナーを管理し、予算アラートを設定できるサービス。

SaaS プロバイダーへの教訓

この事例は、SaaS ベンダーにとって「信頼予算」の重要性を示す警鐘です。無料トライアルのハードキャップという慣行を破ると、たとえユーザー体験向上（例：ビルド失敗防止）を目的としていても、 goodwill（善意）を大きく失うリスクがあります。これを防ぐために、プロバイダーは次の点に留意すべきです。

明示的な同意を取る：無料ユーザーを有料・請求ステータスに移行させる前に、積極的な「オプトイン」を必須とする。
"disruption" の明確化：自動警告で曖昧な表現を避け、サービスが停止するのか、費用が発生するのかを明示する。