私たちのコードに組み込まれた法律

Premium を購入できるようにしたとき、私たちは法的な部分はフッターに置く数ページのテキストだと思っていました。それは間違いでした。義務の中には、そもそもテキストとして書くことができないものがあります。機能の作り方そのものを決めてしまうからです。

それが特にはっきりした例を4つ紹介します。誤解のないよう最初にお伝えしておくと、これは私たちの実装の説明であり、法的な助言ではありません。以下のルールは、AlphaCloud が事業を行っているドイツの法律です。

ログインがあってはならない解約ボタン

ドイツ民法典（BGB）第312k条は、オンラインで締結された契約について、直接アクセスできる解約の手段を用意することを求めています。そこから、あとから文言で付け足すことのできない要件が生まれます：

• ページはログインなしで動かなければなりません
• すべてのページのフッターに置かなければなりません
• 2つのステップが必要です。入力し、そのあと明確なラベルのボタンで確定します
• テキスト形式での受領確認を送らなければなりません

最後の点が設計を左右します。解約は一方的な意思表示であり、受領された時点で効力を持ちます。そのため、誰から来たものであっても、必ず記録し、確認を送らなければなりません。

フォームは決して申し込みを拒否してはならない

ここで、すぐ思いつくやり方のせいで、危うく間違いを犯すところでした。

すぐ思いつくやり方とは、サーバー ID とメールアドレスが有効なサブスクリプションと一致する場合にだけ解約を受け付けるというものです。もっともらしく聞こえますが、二重に間違っています。

1つ目に、メールアドレスを打ち間違えた人や、別のアドレスを入力した本物の顧客を締め出してしまいます。その人の解約は受領されなかったことになり、サブスクリプションは更新され、本人は解約しようとした証拠を持っていることになります。

2つ目に、こちらのほうが厄介なのですが、エラーメッセージそのものが答えになってしまいます。「サブスクリプションが見つかりません」と返された人は、そのサーバーが支払っていないことを知ります。Discord のサーバー ID は秘密ではありません。どのメンバーでも読み取れます。フォームが、他人のサーバーを探るための道具になってしまうのです。

解決策は、1つに感じられる2つのものを切り分けることです：

	条件
意思表示の受領	無条件。必ず記録し、確認を送る
解約の実行	送信されたメールアドレスが、登録されている購入者と一致する場合のみ

それ以外はすべてキューに入り、人が確認します。これが許されるのは、第312k条第2項が本人確認のための情報を求めることを明示的に認めているからです。禁止されているのは、その前にログインを置くことだけです。

同じ理由で、公開の応答で終了日を示せるのは、本人確認が済んだ場合だけです。そうしないと、確認メッセージがまた答えを漏らす仕組みになってしまいます。

あえてログインを置いている撤回

そのすぐ隣に、正反対の作り方をした機能があります。日割りでの返金を伴う撤回は、ログインの先にあります。

これは矛盾ではありません。第312k条が対象とするのは解約であって撤回ではなく、略式の手段が開かれている限り、オンラインの撤回フォームを用意する義務はそもそもありません。違いは結果にあります。解約は将来に対して作用しますが、返金はお金を今動かし、取り戻すことはできません。

そこから導かれる3つのルールがあり、私たちはこれを緩めません：

理由の入力は必須ではない。 第355条第1項は、理由を示さずに撤回することを明示的に認めています。統計のためには必須にしたくなるとしても、この欄は任意であり、任意のままでなければなりません。

14日を過ぎて断るのは自動処理だけで、意思表示そのものは決して断らない。 顧客が適切に説明を受けていなかった場合、期間は最長で12か月と14日まで延びます。一律に「期限切れ」とするのは、間違いになりうるのです。

二重払いを防ぐ仕組みは悲観的に作る。 印は返金が実行される前に付けます。そのあと返金が失敗した場合、印は残ったままで、人が引き継ぎます。二重に支払うことは、取り返しのつかない唯一の結果だからです。

Discord の DM は永続的な媒体ではない

第312f条第3項は、契約の確認を永続的な媒体で行い、与えられた同意の内容を再現することを求めています。

私たちは最初、Discord のダイレクトメッセージを送っていました。顧客がもともといるチャンネルだからです。それでは要件を満たしません。DM は私たちが管理していないプラットフォーム上にあり、この規定が意味するような形で保存も改変防止もできません。

そこでメールを追加しましたが、それとともに居心地の悪い依存関係も生まれました。メールの認証情報が設定されていないと、送信処理はログに警告を書き込むだけで、義務は果たされません。法的義務が環境変数にぶら下がっているというのは、意識しておくべき状態です。

付加価値税はかからない。そして、それをどこでも同じように伝えなければならない

AlphaCloud は、ドイツ付加価値税法第19条に基づく小規模事業者です。価格は最終価格で、付加価値税が表示されることはありません。

注釈のように聞こえますが、実際には多くの場所にまたがる一貫性の作業です。料金ページ、購入ダイアログ、利用規約、プライバシーポリシー、請求書のフッター、決済プロバイダーの設定が、すべて同じことを言わなければなりません。長い間「付加価値税別」と書かれたままの箇所があり、それは単純に間違っていました。

そして AI

2026年8月から、欧州 AI 法の透明性義務が全面的に適用されています。AI システムと話している人は、遅くとも最初のやり取りの時点で、そのことを認識できなければなりません。

その検討の中で、私たちにとって最も重要だった一文はこうです。フッターにある法的ページでは、おそらく要件を満たさない。 開示は、やり取りが行われる場所、つまり Discord のメッセージそのものの中で行われなければなりません。だからこそ、私たちの AI チケットサポートは聞かれる前に自分から名乗り、オフにするためのボタンをはっきり表示しています。詳しい評価は AI の透明性にあります。

共通点

4つの例はどれも同じ形をしています。義務はテキストのように見えて、実際には構造に対する要件でした。間違った場所にあるログイン、明かしすぎるエラーメッセージ、間違ったチャンネルでの確認、二重払いを許してしまう処理の順序。

そのため、私たちは今、法律の文章を仕様書のように読んでいます。そして逆方向の確認も行っています。コードは本当に、私たちの規約に書かれているとおりに動いているのか。まさにその問いについて、本物のずれが2つ見つかりました。それについては別の記事があります。