DEV Community: Hajime

間借り出店のプランを損益分岐点で比べる:会場費と売上の取り分を式にする

Hajime — Tue, 29 Sep 2026 04:45:35 +0000

飲食の間借りや一日店長のプランは、「会場費」と「売上のうち自分に入る割合」の組み合わせで性格が決まります。料金表を眺めているだけだと比較しにくいので、式に落として、数十行のコードで比べられるようにしてみました。

題材にしたのは、東京・大山のスタンドが公開している貸し切りプラン(一日店長)の料金です(2026年9月時点。税区分は問い合わせ時に案内とのことなので、以下の数字は税の扱い未確認のまま使っています)。

モデル化する

貸し切りプランは3スタイルあり、ドリンクの売上の扱いが違います。

スタイル	平日昼	平日夜	土日祝・金夜昼 / 夜	ドリンク売上の取り分
staffed(スタッフ付き)	24,000	29,000	37,000 / 47,000	50%
unstaffed(スタッフなし)	15,000	18,000	23,000 / 28,000	50%
self(ドリンク持ち込み)	18,000	22,000	27,000 / 35,000	100%

1日の手残りを次のように置きます。

profit = food * (1 - foodCostRate)
       + drink * share
       - (style === 'self' ? drink * drinkCostRate : 0)
       - fee

food:自分の料理・商品の売上
drink:ドリンクの売上
share:ドリンク売上の取り分(0.5 か 1.0)
drinkCostRate:持ち込みドリンクの原価率(self のときだけ自分で負担)
fee:会場費

お店のドリンクを使うスタイルでは、ドリンクの仕入れは店側なので原価を引かない、という前提にしています。ここは実際の契約内容で確認すべき仮定です。

コード

const FEES = {
  staffed:   { weekday: { day: 24000, night: 29000 }, weekend: { day: 37000, night: 47000 }, share: 0.5 },
  unstaffed: { weekday: { day: 15000, night: 18000 }, weekend: { day: 23000, night: 28000 }, share: 0.5 },
  self:      { weekday: { day: 18000, night: 22000 }, weekend: { day: 27000, night: 35000 }, share: 1.0 },
};

// 金曜の夜は土日祝料金
const dayType = (weekday, slot) =>
  weekday === 'sat' || weekday === 'sun' || weekday === 'holiday' || (weekday === 'fri' && slot === 'night')
    ? 'weekend' : 'weekday';

function profit({ style, weekday, slot, food, drink, foodCostRate = 0.35, drinkCostRate = 0.3 }) {
  const p = FEES[style];
  const fee = p[dayType(weekday, slot)][slot];
  const drinkIn = drink * p.share - (style === 'self' ? drink * drinkCostRate : 0);
  return Math.round(food * (1 - foodCostRate) + drinkIn - fee);
}

for (const style of Object.keys(FEES)) {
  console.log(style, profit({ style, weekday: 'wed', slot: 'night', food: 30000, drink: 20000 }));
}

原価率の 0.35 と 0.3 は例として置いた値で、どこかの実績値ではありません。自分のメニューの数字に差し替えてください。

損益分岐のドリンク売上を解く

料理の売上を固定したとき、ドリンクをいくら売れば手残りが0になるかは、式を drink について解けば出ます。

function breakEvenDrink({ style, weekday, slot, food, foodCostRate = 0.35, drinkCostRate = 0.3 }) {
  const p = FEES[style];
  const fee = p[dayType(weekday, slot)][slot];
  const perYen = p.share - (style === 'self' ? drinkCostRate : 0); // ドリンク1円あたりの手残り
  return Math.max(0, Math.ceil((fee - food * (1 - foodCostRate)) / perYen));
}

perYen が小さいほど、同じ会場費を埋めるのに必要なドリンク売上は増えます。取り分50%のスタイルでは1円売って0.5円、持ち込みで原価率30%なら0.7円が手元に残る計算なので、ドリンク中心の営業なら持ち込みのほうが分岐点は下がりやすい、ということが式からも読めます。

表計算でやる場合

スプレッドシートなら、スタイルを行、曜日と時間帯を列にした会場費の表を作り、VLOOKUP などで引いてから同じ式を当てるだけです。金曜の夜を週末扱いにする判定だけは忘れやすいので、別の列で明示しておくと事故が減ります。

前提として押さえておくこと

スタッフなしのスタイルは審査制で、スタッフ付きでの利用実績が必要(初回は選べない)
料理など自分の商品の売上がどう扱われるかは、ページからは読み切れないので契約時に確認
掲載の料金は予告なしに改定されることがある

条件を変えて何パターンか回してみると、「どのスタイルなら何を売ればいいか」がはっきりします。表を眺めて悩むより、数字を入れて比べるほうが早い、というのが今回の結論です。

本ページはプロモーションが含まれています

窓のない部屋で撮る:小劇場を配信・収録スタジオとして使うときの確認項目

Hajime — Sun, 27 Sep 2026 13:40:14 +0000

動画の収録やライブ配信の場所を決めるとき、機材より先に効いてくるのは「部屋の条件」です。外光が入る部屋では時刻によって色温度が変わり、カットをつないだときに違和感が出ます。生活音が入る部屋では、あとからノイズ除去をかけても声の質感が削れます。

撮影スタジオを借りれば解決しますが、照明や音響を追加していくと予算が膨らみがちです。そこで候補に入れたいのが、もともと人前で見せるために作られた小劇場です。ここでは、東京都板橋区にある客席30席の貸し劇場の公開情報(2026年9月時点)を例に、配信・収録の場所として評価するときの観点を整理します。

→ 配信・動画撮影に使える貸し劇場板橋シアター咲

1. 光:ゼロから組めるか

収録で一番ありがたいのは「暗くできる」ことです。真っ暗にできる部屋なら、画面に映る光はすべて自分で置いたものになり、再現性が上がります。複数日に分けて撮っても、同じ設定を当て直せば同じ画になります。

例に挙げた劇場は地下1階で窓がなく、昼間でも完全に暗転できると明記されています。備え付けの照明はLEDのパーライトが6灯と、DMXで制御する調光用コントローラーです。

確認したい点:

備え付け照明の色と明るさで、顔に当てる主光が足りるか(足りなければ持ち込みのライトをどこに置くか)
DMXコントローラーでシーンを切り替えられるなら、配信中の転換に使えるか
ステージ背面が白いホワイトボードなので、反射がカメラにどう写るか

背面はマグネットが使える一方、テープや粘着物は使えません。白背面へのマスキングテープも、許可がなければ不可という規約です。背景紙やロゴを貼りたい場合は、マグネットで留める前提で準備します。

2. 音:どこから入れて、どこへ出すか

音響はパワードスピーカー、ワイヤレスマイク、アナログマイク、CDプレーヤーが備え付けで、スピーカーにはPCやスマホからBluetoothで直接音を送れます。

配信で考えたいのは、会場に流す音と配信に乗せる音の経路を分けるかどうかです。

会場スピーカーへはBluetoothでBGMや効果音を送る
配信には、カメラ側・オーディオインターフェース側で拾ったマイク音を乗せる
会場スピーカーの音をマイクが拾う量(回り込み)を、事前にテストする

また規約上、監視カメラ・スピーカー・ミキサーの電源は切ってはいけないことになっています(切ると別途3,000円)。自前の音響系を組むときも、既存機材の電源を落とさない構成にする必要があります。

3. 回線:配信に耐えるか

高速Wi-Fiが用意されています。ただし実効速度は時間帯や接続台数で変わるので、配信本番の前に同じ時間帯で上り速度を測っておくのが安全です。

配信ソフトで要求するビットレートに対して、上りに余裕があるか
配信用PCとスマホ・タブレット(コメント確認用)を同時につないだときに落ちないか
回線が細い場合のフォールバック(モバイル回線)を持っていくか

4. 映像の出し入れ

プロジェクター(4K対応のストリーミング端末が接続済み)とBlu-rayプレーヤーがあります。スライドや映像を投影しながら話す収録、上映会の同時配信などに使えます。投影面と照明の干渉(照明が投影面に当たって白く飛ぶ)は、下見で確かめたいところです。

5. 広さと動線

床面積は54.04平方メートル、客席は最大30席、ステージは平台3台の構成です。三脚をどこに立てるか、ケーブルをどこに這わせるかは、間取り図を見て先に描いておくと当日が速くなります。

控室・更衣室と着替え用のパーテーションがあり、劇場のそばには時間貸しの楽屋もあります。出演者の待機場所と撮影エリアを分けられるので、オーディションや収録の順番待ちにも向いています。

6. 音量と近隣

商店街の建物の地下にある劇場で、規約では出入口の扉とカーテンを完全に閉めて音漏れ・光漏れを防ぐこと、近隣に迷惑となる大音量は不可とされています。爆音を前提にした収録は計画段階で外すか、事前に相談が必要です。

7. 時間の見積もり

料金は時間帯×曜日の区分です。撮影なら、平日昼間(9:30〜16:30)が月〜金で5,000円という区分が使いやすい価格帯です。

注意点は、機材の搬入・設置・撤収・清掃まですべて利用時間に含まれること、延長は1時間2,000円で1分でも超えると1時間分になることです。

収録の時間割は次のように組むと見積もりやすくなります。

搬入・照明と音の仮組み
回線とマイクのテスト
本番(撮影 or 配信)
撤収・原状回復・清掃
施錠して退出(退出時刻を過ぎると入口のキーコードが変わる)

スタッフは常駐していないので、鍵の受け取りから施錠まで自分たちで行います。キーコードは利用日当日に送られてきます。

まとめ:下見で確かめるリスト

暗転した状態で、備え付け照明だけでどこまで撮れるか
白背面の反射と、貼り物の留め方
Bluetooth経由の再生音とマイクの回り込み
本番と同じ時間帯のWi-Fiの上り速度
三脚とケーブルの置き場所
撤収と清掃にかかる時間

利用前の下見は受け付けているとのことなので、配信の本番前に一度、上のリストを持って確認しておくと当日の事故が減らせます。

本ページはプロモーションが含まれています

同時視聴者数1万と記事3本を、同じ物差しに載せる

Hajime — Wed, 23 Sep 2026 13:38:57 +0000

複数の指標を1本のスコアにまとめる仕事は、見た目ほど単純ではありません。

「配信の同時視聴者数」と「メディアに出た記事の本数」を足したい、という場面を考えてみてください。前者は数万単位で動き、後者は0本から数本の間に収まります。そのまま足せば、前者がすべてを決めてしまう。重みで調整しようにも、そもそも単位が揃っていません。

ゲームタイトルの熱量を、配信・検索・記事・コミュニティなど10種類以上の公開データから合成しているダッシュボードがあります。その設計の考え方を材料に、単位の違う指標をどう1つの物差しに載せるかを整理します(公開情報は2026年9月時点)。

→ 10種類以上の公開データを合成したゲーム熱量スコアの GameAxiz

1. まず「その日の中での位置」に直す

最初の一手は、各指標を同じ範囲に写すことです。このダッシュボードでは、系列ごとにその日の全タイトル中の最大値を基準にして0〜100へ直しています。

// 系列ごとに、その日の最大値を 100 とする
function toRelative(value: number, dayMax: number): number {
  if (dayMax <= 0 || value <= 0) return 0;
  return Math.min(100, (value / dayMax) * 100);
}

この時点でスコアの意味が決まります。結果は絶対量ではなく、その日の顔ぶれの中での相対的な位置です。サイト側もこの点を明記していて、0〜100は「絶対的な人気を表すものではない」と断っています。

相対化の代償は、日をまたいだ比較が素直にできなくなることです。昨日の70と今日の70は、比べている相手が違います。変化を追うなら、スコアそのものより「1週間前との差」のように差分として扱うほうが扱いやすくなります。

2. 線形のままだと、下位が全部0に潰れる

上の関数には問題があります。視聴者数やレビュー数のような量は、上位と下位で桁が3つも4つも違います。

最大値が100万のとき、1,000の値は線形だと0.1点です。ランキングの大半が0点付近に貼り付き、中位の差がまったく見えなくなります。

こういう桁違いの差がつく量は対数に写すのが定石です。

function toRelativeLog(value: number, dayMax: number): number {
  if (dayMax <= 0 || value <= 0) return 0;
  return (Math.log10(1 + value) / Math.log10(1 + dayMax)) * 100;
}

1 + を入れているのは、値が1以下のときに負の対数が出ないようにするためです。これで最大100万に対して1,000は約50点になり、中位のタイトル同士の違いが目に見える幅で出てきます。

3. ただし、小さい整数を対数にすると逆に壊れる

では全部対数にすればいいかというと、そうはいきません。

記事の本数や大会の数のような小さな整数を対数に写すと、今度は1本あるだけで大きな点が付きます。最大が5本の日に1本は、対数だと4割近い点数になります。「1本出た」と「5本出た」の差が、実感よりずっと小さく見えてしまう。

そこで指標ごとに尺度を宣言します。

type Scale = "log" | "linear";
type Signal = { key: string; scale: Scale; weight: number };

function normalize(v: number, max: number, scale: Scale): number {
  return scale === "log" ? toRelativeLog(v, max) : toRelative(v, max);
}

判断の基準は「その量の分布が何桁にまたがるか」です。

量の性質	例	尺度
桁違いに開く	同時視聴者数、再生数、レビュー数	対数
小さな整数に収まる	記事本数、大会の件数	線形

4. ストックとフローを混ぜない

もう1つの落とし穴は、性質の違う量を同じ鍋に入れることです。

Steamのレビュー数やコミュニティの参加者数は、長い時間をかけて積み上がった量(ストック)です。一方、今日の配信視聴者数や今週の記事本数はいま起きていること(フロー)です。

ストックを熱量と同列に混ぜると、発売から何年も経った大型タイトルが、何も起きていない日でも上位に居座ります。「いま熱いもの」を見たいのに、「これまで大きかったもの」が答えとして返ってくるわけです。

このダッシュボードでは、ストックを「規模」として別枠にまとめ、総合スコアへは小さく効かせる形を取っています。規模を無視はしないが、日々の動きを覆い隠さない、というバランスです。

const flow = weighted(flowSignals);   // 配信・検索・記事など
const stock = weighted(stockSignals); // レビュー数・コミュニティ規模など
const total = mix(flow, stock);       // stock 側の比重は小さくとる

なお、この「規模」をそのまま売上と読むのは誤りです。サイトでも、販売規模はSteamのレビュー数を基にした推定であり、家庭用ゲーム機の売上は含まないと明記されています。指標の名前が読み手の期待とずれるときは、画面の上で但し書きを添えるのが誠実だと思います。

5. 地域ごとに別々に合成する

最後に、合成を1回で済ませない理由です。

国内で話題でも海外では静か、あるいはその逆、というタイトルは珍しくありません。両方をまとめて平均すると、偏りの大きいタイトルほど中くらいの点数に丸められ、特徴が消えます。

そこで重みのセットを地域ごとに持ち、国内スコアと海外スコアを別々に算出します。公開されている説明では、国内側は日本語版Wikipediaの閲覧数と国内メディアの記事本数が中心、海外側はTwitchの視聴者数と英語版Wikipediaが中心です。

詳細ページでは、総合・国内・海外の3つを並べ、どの指標が押し上げているかも表示しています。合成した数字を出すなら、分解した姿も一緒に出す。単一のスコアに対する疑問のほとんどは、内訳が見えるだけで解消します。

まとめ

単位の違う指標は、まず系列ごとに同じ範囲(0〜100)へ写す。結果は相対値になる
桁違いに開く量は対数、小さな整数は線形。指標ごとに尺度を宣言する
積み上がった量(ストック)は別枠にし、日々の動き(フロー)を隠さない比重で混ぜる
偏りそのものに意味があるなら、平均せずに軸を分けて合成する
合成スコアには内訳を添える

どれも個別には地味な判断ですが、1つでも抜けると「見た目はそれらしいのに、誰の実感とも合わない数字」ができあがります。

本ページはプロモーションが含まれています

写真から作る3D/ARをWebで配るとき、動作環境の下限をどこに引くか

Hajime — Tue, 22 Sep 2026 00:33:27 +0000

Webで3D/ARを配信するとき、実装より先に決めておいたほうがいいのが動作環境の下限です。

下限を決めないまま公開すると、動かない端末からの問い合わせが全部サポートに来ます。かといって広く取りすぎると、低スペック端末での読み込み時間に引きずられて、体験そのものが崩れます。

実際に下限を明示しているサービスがあったので、その引き方を材料に考えます。フラワースタンドを撮影して3D/ARのコンテンツにし、専用URLで配信するサービスです(掲載内容は2026年9月時点)。

→ アプリ不要でARを見せているクロリス

配信の形

まず構成を整理します。公開情報から読み取れるのはこの範囲です。

要素	内容
入力	完成した実物を、必要な角度から撮影した写真
生成	写真をもとに3D/AR表示用のデータを生成
配信	発行された専用URL
クライアント	スマートフォンのブラウザ。専用アプリのインストールは不要

エンドユーザーから見ると「URLを開くだけ」です。アプリを挟まない構成は導線が短い一方で、実行環境を選べないという代償があります。ネイティブアプリならストアの対応OSで足切りできますが、URLは誰でも開けてしまう。

だからこそ、下限を文書で示す必要が出てきます。

実際に引かれていた線

公開されていた推奨環境はこうでした。

区分	発売時期の目安	OS / ブラウザ	代表機種
iOS	2021年以降のiPhone	iOS 18以降のSafari	iPhone 13シリーズ以降、iPhone SE(第3世代)など
Android	2022年以降のスマートフォン	Android 13以降のChrome	Google Pixel 7シリーズ以降、Galaxy S22シリーズ以降、Xperia 1 IV / 5 IV以降、AQUOS R7以降など

注目したのは、3つの異なる軸を併記しているところです。

発売時期(ハードウェアの世代の代理指標)
OSとブラウザのバージョン(APIの可用性)
代表機種(ユーザーが自分で照合できる形)

技術的に意味があるのは2だけです。1と3は、エンドユーザーが自分の端末を判定できるようにするための変換にすぎません。

なぜ3つ書くのか

ここが設計として学ぶところでした。

ユーザーは自分の端末のOSバージョンを知りません。「Android 13以降」とだけ書かれても照合できず、結局試してから問い合わせることになります。発売年と機種名を併記すると、その場で判断できる確率が上がります。

一方で、発売年だけにすると誤判定が起きます。新しい端末でもOSを更新していなければ条件から外れるからです。だから技術条件を正として書き、その横に照合用の目安を置くという並べ方になります。

サポート窓口の負荷を、ドキュメントの書き方で下げているわけです。

失敗モードを書いてある

もうひとつ実務的だったのが、下限を外れたときの挙動が書かれている点です。

年数が経った端末や最新版のSafari / Chromeに更新できない端末では、読み込みに時間がかかる、表示が途中で止まる、または表示されない場合がある、とありました。

3D/ARのWeb配信では、きれいに失敗しないのが厄介です。未対応を検出して明示的にエラーを出す経路もあれば、アセットの読み込み中にメモリを使い切って無反応になる経路もあります。後者はユーザーから見て「固まった」としか見えません。

ドキュメントに「途中で止まることがある」と書いてあるだけで、ユーザーは自分の操作ミスを疑わずに済みます。実装で防げないものを、文言で受け止めている例だと思いました。

案内されていた対処も、再読み込み・ブラウザの更新・通信環境の良い場所での再アクセスの3つで、いずれもユーザー側で完結します。

下限を決めるときの判断材料

自分で同種のものを作るなら、下限は次の順で詰めることになります。

必要なAPIの可用性から技術的下限を出す。 WebGLの実装差、WebXRを使うかどうか、テクスチャ圧縮形式の対応。ここが実際の足切り
メモリ上限から実効的な下限を出す。 モバイルSafariはタブあたりのメモリに上限があり、高解像度テクスチャを積むと技術的には対応していても落ちる
1と2の厳しいほうを採用する。 たいてい2が効く
それをユーザーが照合できる表現に変換する。 発売年と代表機種
外れたときの挙動と対処を書く

3を飛ばして仕様上の対応表だけ出すと、「対応と書いてあるのに動かない」という報告が来ます。

保証の範囲も文書にある

利用規約側にも対応する記述がありました。表示の精度・色味・形状・動作環境について完全性・正確性・特定目的適合性を保証しない、閲覧環境によっては一部または全部が正常に利用できない場合があることをあらかじめ了承する、という条項です。

写真から3Dを起こす処理は入力依存が強く、同じパイプラインでも対象によって結果が変わります。実物の形状や装飾、撮影環境によっては再現できない場合がある、という注記もありました。

再現度を数値で約束しないというのは、この種の生成処理を商用で出すときの現実的な線だと思います。出力が入力の質に左右される以上、SLAのように書ける性質のものではありません。

まとめ

アプリを挟まない配信は導線が短いが、実行環境を選べない
下限は技術条件で決め、ユーザーが照合できる形に変換して併記する
実効的な下限はAPIの対応表ではなくメモリで決まることが多い
失敗モードと対処を書いておくと、ユーザーが自分を疑わずに済む
入力依存の強い生成処理は、再現度を約束しない書き方になる

本ページはプロモーションが含まれています

「参加人数で課金」を実装するとき、何をもって1人と数えるか

Hajime — Sun, 20 Sep 2026 05:19:02 +0000

従量課金の設計で最初に決めるのは料率ではありません。1件を何で数えるかです。

ここが曖昧なまま実装に入ると、請求の根拠を後から説明できなくなります。利用者から「この数字は何ですか」と聞かれて答えられない課金は、値段が妥当でも信用されません。

位置情報を使うスタンプラリーのサービスが、この定義を公開していたので、設計の題材として読みます(2026年9月時点の掲載内容です)。

→ 参加人数を課金単位にしている ARスタンプラリー

候補になる数え方

「参加人数」と言ったとき、実装上の候補は複数あります。

A. 参加ページを開いた回数         → PV。水増ししやすい
B. 参加ページを開いた一意の端末数  → Cookie/LocalStorage 依存。消すと増える
C. 会員登録した人数               → 登録を必須にする設計が要る
D. 何らかの行為を完了した人数      → 定義が要るが、意味が明確

このサービスが採っていたのは D でした。定義はこうです。

初めてスタンプを1個以上取得した人数を数えます。ページを見ただけの人は含みません。(料金ページより)

なぜ D が扱いやすいか

3つあります。

1. 利用者に説明できる。 「現地へ行って1個押した人の数」で言い切れます。A や B は「なぜこの数字なのか」の説明が長くなります。

2. 告知の成否と課金が連動しない。 SNS で拡散して閲覧が跳ねても、請求は増えません。主催者は告知を躊躇しなくて済みます。A を採ると、拡散するほど費用が増えるという逆インセンティブが生まれます。

3. サーバー側のイベントで数えられる。 スタンプ取得はサーバーに記録が要る操作なので、クライアントの状態に依存せず数えられます。B はブラウザのストレージが消えると同じ人を二重に数えます。

3つ目は、この手のサービスでは特に大きい論点です。参加者に会員登録を強制しない設計(このサービスも会員登録は必須ではない)を採ると、一意な人の識別は本質的に困難になります。「初めてスタンプを取得した」というイベントを1回だけ記録する形にすれば、識別の精度が課金の精度に直結しません。

判定をどこに置くか

課金単位の話と地続きで、判定の置き場所も公開されていました。

位置の判定はすべてサーバー側で行い、押せる範囲・期間・回数はサーバーが持っている設定で確認します。参加者の画面から判定結果を書き換えることはできません。

「範囲・期間・回数」の3つを同じ場所で見ている、と明記されているのが要点です。範囲だけサーバーで見て、期間の判定をクライアントに置く、という混在をやると、期限切れのラリーに押せてしまいます。

課金の観点でも、押印イベントがサーバーに集約されていることが前提になります。クライアントが「押しました」と申告する形だと、課金対象の数を自己申告で作れてしまいます。

防げないものを、仕様に書く

興味深かったのは、限界も書いてあった点です。

位置情報を偽装するアプリを使われた場合は、GPSだけで完全に防ぐことはできません。

そのうえで、QRコードの併用・達成後の現地引き換え・押印の時刻や順序の確認、という運用側の対策が挙げられていました。

サーバー側判定で守れるのは「クライアントから判定結果を書き換えられないこと」であって、「クライアントが送ってくる位置が本物であること」ではありません。この2つは別物です。前者は設計で担保でき、後者は端末の外側の問題なので設計では閉じません。

ドキュメントでこの線を引いているかどうかは、そのサービスの設計を信頼できるかの目安になります。

上限に達したときの設計

人数課金には、上限に触れたときの振る舞いという論点もあります。

このサービスは、開催中でも上位の枠へ差額のみで変更でき、決済確認後に自動で枠が広がる、という形でした。ダウングレードはできません。

課金の設計として見ると、アップグレードのみ・差額精算・即時反映という組み合わせです。返金処理を持たずに済み、差額計算も単純な引き算になります。「小さく買って必要なら足す」に利用者を誘導する形なので、過大な枠を最初に売らない設計とも言えます。

まとめ

従量課金を設計するときのチェック項目として、今回読んだ内容はそのまま流用できます。

1件の定義を、利用者に1文で説明できるか
その定義は、サーバー側のイベントだけで数えられるか
告知の成否と請求額が連動していないか
判定の範囲・期間・回数が、同じ場所で評価されているか
設計で閉じない部分(端末の外側)を、ドキュメントに明示しているか
上限に触れたときの操作が、返金を伴わない方向に設計されているか

値段を決めるより先に、この6つを埋める。順番としてはそちらが先だと思います。

本ページはプロモーションが含まれています

「可・不可・要相談」の3値を媒体ごとに持つと、検索はどう変わるか

Hajime — Sat, 19 Sep 2026 03:48:21 +0000

人と案件をつなぐサービスを作るとき、プロフィールは「できること」の集合として設計されがちです。スキルタグを持たせて、部分一致で引く。実装としては素直ですが、できないことが表現できないという弱点があります。

キャスティングのサイトを読んでいて、ここを正面から持っているデータ設計を見かけたので、構造として何が起きるのかを書きます(掲載内容の確認は2026年9月時点)。

→ 対応可否を媒体ごとに登録できる NEXT CAST

持っているのは (媒体 × 3値) と NG 事項

登録するタレントは、SNS や媒体ごとに「対応可 / 不可 / 要相談」を登録し、加えて NG 事項を明記します。

素朴に書くと、プロフィールはこうなります。

Talent
  id
  category            # 芸人 / インフルエンサー / アーティスト / その他
  intro               # 紹介文(必須)
  availability[]      # (media, status, condition)  status ∈ {ok, ng, negotiable}
  ng_notes[]          # 受けない案件の種類

availability を 2値(できる / できない)ではなく 3値にしているのが肝です。

2値にすると「要相談」が消える

3値を2値に落とすと、negotiable はどちらかに寄せることになります。

ok に寄せる → 検索結果に出るが、打診すると断られる。偽陽性が増える
ng に寄せる → 条件次第では受けられた案件が、そもそも表示されない。偽陰性が増える

現実の運用では、後者のほうが見えにくく、損も大きくなります。出てこなかった候補は、誰にも気づかれないからです。

3値のまま持てば、検索側で「可のみ」と「可+要相談」を出し分けられます。UI としては、絞り込みの既定値をどちらにするかという問題に変わります。

条件は構造化しないほうが通ることもある

condition と ng_notes は自由記述です。ここを無理に enum へ落とさないのは、実務上は妥当だと思います。

受けない案件の理由は、業種、商材、表現、時期、共演者と、軸がばらばらです。列挙しようとすると、どの軸でも取りこぼす。検索の絞り込みには媒体 × 3値を使い、細部は人が読む。役割を分けた形です。

依頼側にも必須項目がある

このサービスで面白かったのは、依頼する企業側にもプロフィールの公開が必須な点でした。

会社名・キャスティングの希望・企業ロゴの登録が、タレント検索と依頼の必須条件とされています。タレント側も、紹介文の登録が公募案件の検索・応募の必須条件です。

つまり検索できる状態になるまでに、両側でバリデーションが1回ずつ入ります。「空のプロフィールで一覧だけ眺める」ができないので、検索に出てくるレコードの質が上がります。

公開前に人の確認が入る

タレントの掲載も、企業の公募案件も、公開前に運営が内容を審査します。差し戻しの場合は理由がマイページに表示され、修正して再申請できるとありました。

状態としては draft → in_review → published、差し戻しで rejected(reason) を経て draft に戻る形です。理由を保持して画面に出す前提なので、rejected は状態フラグではなくメッセージ付きのレコードになります。

掲載基準も、値として効いてくる

掲載基準には、18歳以上、本人が運用する公開アカウントで活動実態が確認できること、フォロワーの購入・水増しが疑われる場合は掲載を見送ること、といった条件が並びます。

SNS を主な媒体とする人は合計フォロワー1,000人以上が目安、ただし目安未満でも活動実績・専門性・独自性を含めて総合判断、とも書かれています。

しきい値を公開しつつ、しきい値だけで機械的に切らない。審査を人が持っている設計とセットで読むと筋が通っています。

契約の形は1つに絞られている

扱うのは業務委託の案件のみで、雇用契約の募集は掲載できません。企業とタレントが直接契約を結ぶ場の提供であり、雇用のあっせんは行わないと明記されています。

扱う契約が1種類だと、通知も、案件の状態遷移も、分岐が減ります。何でも載る場にしないことが、そのまま実装の単純さになっています。

まとめ

できないことを持てる構造(3値 + NG)は、検索の精度に直結する
2値へ落とすと偽陰性が増え、しかもそれは観測しづらい
絞り込みは構造化データ、細部は自由記述、と役割を分ける
両側に必須項目を置くと、検索対象のレコードが痩せない

本ページはプロモーションが含まれています

日時が決まっている役務の販売で、返金と振替をどう分けて持つか

Hajime — Thu, 17 Sep 2026 22:36:56 +0000

物を売るテーブルをそのまま使って、日時指定のオンライン役務を売ろうとすると、たいてい返金のところで破綻します。

商品は「渡したか、渡していないか」の2値ですが、日時の決まった役務は「時間が来たか」「実施されたか」「誰の理由で実施されなかったか」の3つが独立しているからです。

オンラインで1対1のイベントを販売できるサービスの規約が、この3つをきれいに分けて書いていたので、データ設計として読み直してみます。

→ 日時指定のオンラインイベントを販売できる 1to1live

規約に出てくる場合分け

公開されている規定を、そのまま分岐として書き出します。

購入者都合(遅刻・不参加・途中退室・端末や通信の不具合・カメラマイクの許可失敗) → 返金しない
販売者都合の中止 → 全額返金
販売者が開始時刻に入室しない → 申告 → 事実確認 → 返金または権利の再付与(振替)
提供側のシステム障害 → 振替または返金
規約違反による強制終了 → 返金しない

ここで重要なのは、「返金」と「権利の再付与」が別の結果として並んでいることです。同じ「実施されなかった」でも、出口が2つある。

チケットを金額ではなく権利として持つ

出口が2つあるということは、購入 = 決済の成功、ではないということです。決済とは別に、特定の日時に役務を受ける権利を独立させて持つ必要があります。

payment     決済そのもの(Stripe 側の事実)
entitlement 権利。どのコマに、誰が、いくつ
slot        コマ。開始日時・長さ・販売者

金額しか持っていないと、振替のときに「返金して買い直してもらう」しかなくなります。決済をやり直せば手数料が二重にかかり、実際この規定でも返金時に決済手数料は戻らないと明記されています。権利を持ち回せるなら、その損失を出さずに別のコマへ移せます。

状態は「誰の理由か」まで持つ

cancelled のひとことにまとめると、あとから集計もサポートもできません。最低限、理由の主体を残します。

entitlement.status:
  active            購入済み・未実施
  consumed          実施済み
  no_show_buyer     時間が過ぎた(購入者が来なかった) -> 返金しない
  failed_seller     販売者が来なかった -> 返金 or 振替
  failed_system     障害 -> 振替 or 返金
  cancelled_seller  販売者都合の中止 -> 全額返金
  revoked           規約違反による終了 -> 返金しない

no_show_buyer と failed_seller は、外から見ると同じ「通話が行われなかった」です。区別できるのは入退室の記録だけなので、ログを商品データの一部として扱う必要があります。

規定側にもこれに対応する記載があって、不審請求(チャージバック)の際に入退室のログと通話の実施記録を提供するとされています。ログが後から証拠になる前提で設計されている、ということです。

時間の境界を3つ持つ

「開始時刻」だけだと足りません。この規定には開始30分前から控室に入室できるとあり、通話画面には残り時間が出ます。つまり境界が3つあります。

open_at   = start_at - 30min   控室に入れる
start_at                        実施の開始
end_at    = start_at + duration 自動退室

open_at を持たずに start_at だけで判定すると、「10分前に来たのに入れない」という問い合わせが必ず出ます。そして end_at を計算で出していると、途中で長さを変えたときに既存の権利の終了時刻が動きます。発行済みの権利には、その時点の長さを固定して持たせるのが安全です。

購入後に価格を変えられるようにしない

コマの価格を slot.price から直接引いていると、販売者が後から価格を変えたときに、返金額が購入時と違う額になります。

決済のたびに購入時の金額・手数料率を権利側に固定しておく。返金は権利に固定された金額を参照して計算する。ここは例外なく固定側に倒すところです。

実際、この料金体系は利用料が売上の5%(税込)、決済手数料が3.6%で、返金時は利用料だけが戻る形でした。返金の計算に2種類の率が出てくる以上、率そのものを購入時点でスナップショットしておく必要があります。

まとめ

日時指定の役務を扱うときに、最初から入れておきたいのはこの5つでした。

決済・権利・コマを別のテーブルに分ける
状態に理由の主体を残す(購入者 / 販売者 / システム / 違反)
返金と振替を別の出口として実装する
時刻の境界を3つ(入室可・開始・終了)持ち、権利側に固定する
金額と手数料率は購入時点のスナップショットを持つ

規約の場合分けは、そのまま状態遷移図になります。実装の前に読むと、あとから足りなくなるカラムが減ります。

本ページはプロモーションが含まれています

「無料キャンペーン中」の価格を、恒久価格と同じ場所に置かない

Hajime — Thu, 17 Sep 2026 08:37:27 +0000

料金表を実装するとき、いま無料であることと本来いくらであることを同じフィールドに入れると、あとで必ず壊れます。

キャンペーンが終わったときに、何を元の値に戻せばいいのか分からなくなるからです。上書きしてしまったなら、戻す先がありません。

音楽人材のマッチングサービスの料金表が、この構造をきれいに持っていたので、設計として整理します(2026年9月9日に確認した内容)。

→ 音楽の仕事の料金体系を確認するなら Music Chronicle

元の記載

サイトにはこう書かれていました。

スカウト送信 — 無料(通常チケット1枚)
単発依頼の掲載 — 無料(通常チケット1枚)
継続募集の掲載 — 無料(通常チケット3枚)
ポートフォリオの掲載・動画公開 — 無料(掲載は今後も無料)
仕事への応募 — 無料
メッセージのやり取り — 無料

注目すべきは、上3つと下3つで「無料」の意味が違うことです。

上3つは期間限定の無料で、括弧の中に通常価格が残っています。下3つは恒久的に無料です。ポートフォリオの掲載には「今後も無料」と明記されていました。

同じ「無料」という表示が、2種類ある。これを1つのフィールドで表すことはできません。

型で分ける

価格を、恒久的な定義と、いま適用されている条件に分けます。

type Feature = {
  id: string;
  name: string;
  /** 恒久的な価格。キャンペーンでも書き換えない */
  standard: { kind: 'free' } | { kind: 'tickets'; count: number };
  /** 現在適用中の上書き。無ければ standard がそのまま適用される */
  override?: { kind: 'free'; campaign: string; announced_end: string | null };
};

これで、2種類の無料が区別できます。

[
  { "id": "portfolio", "name": "ポートフォリオの掲載・動画公開",
    "standard": { "kind": "free" } },

  { "id": "scout", "name": "スカウト送信",
    "standard": { "kind": "tickets", "count": 1 },
    "override": { "kind": "free", "campaign": "beta", "announced_end": null } },

  { "id": "job_continuous", "name": "継続募集の掲載",
    "standard": { "kind": "tickets", "count": 3 },
    "override": { "kind": "free", "campaign": "beta", "announced_end": null } }
]

standard は絶対に書き換えません。キャンペーンは override を足すだけ、終了は override を外すだけ。これで元に戻せます。

announced_end を null にできるようにする

サイトには、有料化の開始時期は事前に告知されると書かれていました。つまり、現時点で終了日は決まっていません。

ここで announced_end を適当な日付で埋めると、決まっていないことを決まっているように表示することになります。

null を許容し、表示側で分岐させます。

const endLabel = (o) =>
  o.announced_end ? `${fmt(o.announced_end)}まで` : '終了時期は事前告知';

「いつまでか未定」と正直に出すほうが、後から日付がずれて信用を失うより安全です。

表示は「いまの価格」と「通常価格」を並べる

override があるときの表示は、片方だけにしないほうがいい。

スカウト送信        無料   （通常 チケット1枚）
継続募集の掲載      無料   （通常 チケット3枚）
ポートフォリオ掲載  無料   （今後も無料）

通常価格を隠すと、終了時に利用者が驚きます。逆に恒久無料のものには「今後も無料」と書く。同じ「無料」でも、後で変わるかどうかが一目で分かります。

これは実装の都合ではなく、元データが2種類を区別して持っているからこそ書ける表示です。

チケットは残高ではなく、期限付きのロットで持つ

もう一つ、設計が効くところがあります。チケットの条件です。

1枚3,000円(税込)。クレジットカード(Stripe)で1〜10枚をまとめて購入できる
期限は購入日から180日。過ぎた未使用分は失効する
未使用チケットの払い戻しは原則行わない
審査で不承認になった掲載については、消費分が自動で返却される

期限が購入から180日なので、残高を1つの整数で持つことはできません。

// ダメな例
user.tickets = 7;   // ← どれがいつ失効するのか分からない

購入した単位(ロット)で持ちます。

{
  "lots": [
    { "id": "L1", "purchased_at": "2026-04-01", "expires_at": "2026-09-28", "count": 3, "used": 3 },
    { "id": "L2", "purchased_at": "2026-08-15", "expires_at": "2027-02-11", "count": 5, "used": 1 }
  ]
}

消費は期限が近いロットから。これを間違えると、まだ使えたはずのチケットが失効します。

function consume(lots, n, now) {
  const live = lots
    .filter((l) => l.expires_at > now && l.count > l.used)
    .sort((a, b) => a.expires_at.localeCompare(b.expires_at));   // 期限が近い順
  // …live の先頭から n 枚を引き当てる
}

返却は「取り消し」であって「付与」ではない

審査で承認されなかった場合の自動返却が、ここで効いてきます。

返却を新しいロットの付与として実装すると、期限が延びます。4月に買ったチケットを使い、9月に不承認になって返却されたとき、新規ロットにすると期限が2027年3月まで延びてしまう。

正しくは、消費した記録を取り消す処理です。

function refund(lots, consumption) {
  // consumption は「どのロットから何枚引いたか」の記録
  for (const { lot_id, n } of consumption.entries) {
    const lot = lots.find((l) => l.id === lot_id);
    lot.used -= n;        // 元のロットに戻す。期限は元のまま
  }
}

つまり、消費のときに「どのロットから引いたか」を記録しておく必要があります。残高を整数で減らす実装では、返却を正しく処理できません。

なお、期限切れのロットに戻すことになる場合もありえます。そのときどうするかは仕様の問題なので、勝手に延長せず、仕様として明記されている扱いに従うことになります。

購入の上限も制約として持つ

1〜10枚という購入単位の上限も、UI の都合ではなくデータ側の制約として持ちます。

{ "purchase": { "min": 1, "max": 10, "unit_price_incl_tax": 3000 } }

税込価格であることを、フィールド名に入れておくこと。税区分が曖昧な price は、いずれ必ず事故ります。

課金しない機能も、同じテーブルに置く

最後に、料金表の外にある機能について。

このサービスでは、音楽シーンの公式データを扱う面(音楽ランキング / 動画ランキング / 公式ニュース / プレス・IR)があり、会員登録・閲覧はすべて無料でした。アーティストのお気に入り登録とマイダッシュボードが使えるとのことです。

これらは「キャンペーンで無料」ではなく「そもそも課金対象ではない」ものです。先ほどの型で言えば standard: { kind: 'free' } で、override を持ちません。

課金対象でないものを料金表から除外すると、あとで「これは有料ですか」という問い合わせが発生します。同じテーブルに入れて、恒久無料として明示するほうが親切でした。

まとめ

standard と override を分ける。キャンペーンで恒久価格を書き換えない
終了日が未定なら null。決まっていないことを日付で埋めない
表示では「いまの価格」と「通常価格」を並べる
チケットは整数の残高ではなく、期限付きのロットで持つ
消費は期限が近い順。どのロットから引いたかを記録する
返却は消費の取り消し。新規付与にすると期限が延びる
税区分をフィールド名に入れる
恒久無料の機能も料金表に載せ、「今後も無料」と明示する

料金や条件は変わることがあります。実装に取り込むなら、取得日を添えて持ってください。

本ページはプロモーションが含まれています

見積と請求の差を、説明のつく差とつかない差に分ける

Hajime — Wed, 16 Sep 2026 00:03:23 +0000

見積と請求の差を、説明のつく差とつかない差に分ける

見積書と請求書を突き合わせる処理を書くと、最初は単純な引き算に見えます。

const diff = invoice.total - estimate.total;

これでは使えません。差が出ること自体は異常ではないからです。必要なのは、差があるかどうかではなく、その差に説明が付くかどうかの判定です。

葬儀の見積書と請求書を題材に、この判定をどう組むかを考えます(2026年9月9日に確認した内容を使います)。

→ 見積書と請求書の差額を確認するなら弁護士による葬儀ガード

費目には2種類ある

前提として、参照したコラムに費目の分類がありました。

動かない側は、祭壇、棺、寝台車、式場代、火葬料。動く側は、料理、返礼品、礼状、安置料、ドライアイス。動く理由は人数と日数です。

この分類が、そのまま判定ロジックの土台になります。

const KIND = {
  fixed:    ['祭壇', '棺', '寝台車', '式場代', '火葬料'],
  variable: ['料理', '返礼品', '会葬礼状', '安置料', 'ドライアイス'],
};

fixed に差が出たら、原則として説明が要る
variable に差が出るのは正常。ただし傾きと整合しているかを見る

差分の絶対値だけを見ると、この違いが消えます。

変動費目は「単価 × 数量」に分解して比べる

コラムには、あるべき書き方の例が挙げられていました。料理は「1人前◯円 × ◯人分」、返礼品は「1個◯円 × ◯個」、会葬礼状は「1枚◯円 × ◯枚」。安置・保管は「1日◯円 × ◯日」、ドライアイスは「1回◯円 × ◯回」、寝台車・霊柩車は「◯km以内◯円 × ◯回」という形です。

この形で両方が書かれていれば、差の原因を単価側と数量側に切り分けられます。

function explain(est, inv) {
  if (est.unit === inv.unit && est.qty !== inv.qty) {
    return { verdict: 'qty_changed', delta_qty: inv.qty - est.qty };   // 想定内
  }
  if (est.unit !== inv.unit) {
    return { verdict: 'unit_changed', from: est.unit, to: inv.unit };  // 要確認
  }
  return { verdict: 'same' };
}

数量が増えたのは説明が付きます。単価が変わったのは、説明を聞く必要があります。総額だけを比べていると、この2つが同じ「増えた」になってしまいます。

「一式」は判定不能として返す

現実のデータでは、この分解ができないことがあります。

「葬儀一式 ◯◯万円」としか書かれていない場合です。コラムには、この書き方だと後から何が含まれていたのかを確かめられないとありました。

ここで qty = 1, unit = 総額 と補完してはいけません。分解できていないという事実そのものが、確認すべき点だからです。

if (est.unit == null || est.qty == null) {
  return { verdict: 'not_comparable', reason: 'lump_sum' };
}

not_comparable を same に倒さないこと。比較できなかったものを「差がなかった」と表示するのが、いちばん危ない実装です。

なお、コラムには、その場で「項目ごとの金額を入れた見積書をいただけますか」と伝えてよいとありました。データが取れないなら、取れる形で出し直してもらうのが正しい対処です。

見積に無い行が請求に出てくる

もう1つのパターンが、片側にしか存在しない行です。

別会計になりやすい項目として挙がっていたのは、火葬料、式場使用料、宗教者へのお布施・御車代・御膳料、安置が延びた分の追加保管料、参列者が増えた分の料理・返礼品でした。火葬料は自治体や施設で差があり、無料のところも十数万円のところもあるとのことです。

これらは見積書に載っていないのが正常な場合があります。載っていないから不正、ではありません。

const reconcile = (est, inv) => ({
  matched:   join(est, inv),
  only_in_estimate: est.filter(r => !inv.some(i => i.name === r.name)),
  only_in_invoice:  inv.filter(r => !est.some(e => e.name === r.name)),
});

only_in_invoice に出たものは、「想定されていた範囲外の項目」のリストとして出します。異常として赤くするのではなく、確認対象として並べる。判定を下すのは人の仕事です。

規模感を持っておく

どの程度の差なら想定内か、という感覚を持つために数字を引いておきます。

紹介されている調査の平均額は、総額が96.73万円。その内訳として飲食費が11.67万円、返礼品費が13.03万円でした。合計すると約25万円。総額の4分の1ほどが、契約の時点では未確定という整理です。

つまり、総額の25%前後は動きうるという前提で設計する必要があります。「5%以上の差でアラート」のような閾値を総額に対して置くと、正常な差で鳴り続けます。

閾値を置くなら、variable の行に対して数量の変化率で置くほうが筋が通ります。

傾きを先に取っておく

差分を後から説明するより、事前に傾きを記録しておくほうが確実です。

参照したコラムには、時間がないときに確認する項目が3つ挙げられていました。

見積もりに含まれない項目
参列者が1人増えたときの増加額
安置が1日延びたときの増加額

データ設計としては、これがそのまま入力項目になります。

{
  "excluded": ["火葬料", "式場使用料", "お布施"],
  "slope": {
    "per_attendee": 0,
    "per_storage_day": 0
  },
  "recorded_at": "…",
  "confirmed_by": "email"
}

confirmed_by を持たせているのは、コラムに答えはその場でメモし、できればその日のうちにメールで送って確認しておくとあったからです。口頭の記録と、書面で確認済みの記録は、あとで差分を検証するときの重みが違います。

前提条件が違えば、そもそも比較できない

見積どうしを比べる場合には、もう1つ条件があります。

そろえるべき項目として、参列者の人数・式場・通夜の有無・安置日数・火葬料の扱いという5つが挙げられていました。

この5つを比較のキーとして持ち、一致しない場合は比較を実行しない設計にします。

const COMPARE_KEYS = ['attendees', 'venue', 'wake', 'storage_days', 'cremation_fee_handling'];
if (COMPARE_KEYS.some(k => a[k] !== b[k])) {
  return { verdict: 'precondition_mismatch', keys: COMPARE_KEYS.filter(k => a[k] !== b[k]) };
}

条件が違うのに数字を並べて表示しない。並べた時点で、利用者は比べてしまいます。

出力の形

最終的に出すのは、判定ではなく分類です。

■ 想定内（数量の変化で説明が付く）
   料理        50人 → 63人   単価は同じ
   安置・保管   3日 → 4日     単価は同じ

■ 確認したい（単価が変わっている）
   返礼品      単価 ◯円 → ◯円

■ 見積に無かった項目
   式場使用料

■ 比較できなかった
   葬儀一式（内訳なし）

「異常あり／なし」を返さない。金額の妥当性は、このデータだけでは判断できません。できるのは、人が確認すべき箇所を絞り込むところまでです。

人に見てもらう前提を織り込む

実際のところ、この整理をした先で判断が要ります。

弁護士が中立の立場で見積書・契約書・請求書を確認するサービスがあり、葬儀後の請求確認として、見積書と請求書の差額や追加請求の内容を検証する、という範囲が示されていました。葬儀が終わった後でも相談できるとのことです。相談は何度でも無料、24時間受付、匿名相談可とも書かれていました。

葬儀社から紹介料・広告料等の金銭を一切受け取らず、葬儀社の紹介・斡旋は行わない、という記載もあります。

ツールが出すのは材料まで、というのは、設計上も割り切っておいたほうがいい線引きだと思います。

まとめ

差分を単一の数値で判定しない。費目の種類で扱いを分ける
変動費目は単価と数量に分解し、どちらが動いたかを返す
分解できないものは not_comparable。「差なし」に倒さない
片側にしかない行は、異常ではなく確認対象として出す
閾値を総額に対して置かない。25%前後は動きうる前提で考える
傾き(1人あたり・1日あたり)を事前に記録しておく
前提条件が違う見積は並べて表示しない

書式も条件も発行元によって変わります。実装に取り込むなら、対象の書面の様式を確かめたうえで行ってください。

本ページはプロモーションが含まれています

推奨環境の外に落ちた端末に、何を見せるか

Hajime — Tue, 15 Sep 2026 05:09:23 +0000

推奨環境の外に落ちた端末に、何を見せるか

ブラウザで動く AR を使った施策を設計するとき、いちばん手薄になるのが推奨環境を外れた端末の扱いです。

動くケースの設計は誰でもやります。動かないケースは「動きません」で済ませがちで、その結果、利用者の画面には何も起きないか、真っ黒な画面が出ます。何も起きないのがいちばん悪いというのが、この記事の主張です。

題材として、ある WebAR グッズ制作サービスが公開している動作条件を使います(2026年9月9日時点)。

→ ブラウザで動くARグッズを作れる AR Goods Makers

条件は2つある

公開されている条件を、そのまま書き出します。

1. 端末が2台必要

AR体験には、ARを起動するスマートフォンと、体験用画像を表示する別の端末が必要です。組み合わせは PC と1台、あるいは2台のスマートフォン。1台きりでは成立しません。

2. 推奨環境

iOS は18以降でSafari、Android は13以降でChromeが推奨とされ、そこから外れた環境は動作保証もサポートも対象外です。

設計者として重要なのは、この2つが独立した条件だという点です。推奨環境を満たしていても端末が1台なら体験できないし、端末が2台あっても古い OS なら動きません。よくある実装は、この2つを1つの isSupported に潰してしまいます。

失敗の種類を分ける

判定を1つのブール値にすると、利用者に出せるメッセージも1種類になります。「お使いの環境では利用できません」。これでは利用者は次の行動を取れません。

分けます。

function diagnose(ua, caps) {
  const os = detectOs(ua);                    // { name: 'ios'|'android'|'other', major: number }

  if (os.name === 'ios'     && os.major < 18) return 'os_too_old';
  if (os.name === 'android' && os.major < 13) return 'os_too_old';
  if (os.name === 'other')                    return 'os_unsupported';
  if (!caps.isTargetBrowser)                  return 'browser_mismatch';
  if (!caps.hasCamera)                        return 'no_camera';
  if (!caps.cameraPermission)                 return 'permission_denied';
  return 'ok';
}

それぞれに、利用者が実際に取れる行動を割り当てます。

判定	画面に出すもの
`os_too_old`	必要な OS のバージョンを明示する。「対応していません」で止めない
`browser_mismatch`	標準ブラウザで開き直す導線。URL をコピーできるようにする
`permission_denied`	許可の出し直し方を、OS ごとの手順で示す
`no_camera`	代替コンテンツへ(後述)
`os_unsupported`	代替コンテンツへ

browser_mismatch は実際によく踏みます。QR コードを読み取ったアプリの内蔵ブラウザで開かれる場合があるためです。ここで「動きません」と出すのは、あと一手で成功できる利用者を取り逃がしていることになります。

端末が2台という条件は、検出できない

やっかいなのが1つ目の条件です。「利用者がもう1台端末を持っているか」は、ブラウザからは分かりません。

検出できない条件を設計に組み込むには、前提のほうを動かすしかありません。選択肢は3つです。

こちらで表示用の端末を用意する — 会場やイベントで配る場合。据え置きの画面を1つ置けば、利用者は自分のスマートフォン1台で済む
案内に先出しする — 持ち帰ってもらう場合。配布物の紙面や案内ページに、必要な環境を書いておく
代替を用意する — AR を使わない形でも中身が伝わるようにする

実務では、QR の遷移先を分岐させるのがいちばん効きました。遷移先の1枚目を「体験の入り口」にして、そこで条件を説明し、2台ある人だけが次へ進む。いきなり AR を起動しません。

代替コンテンツは「劣化版」にしない

no_camera や os_unsupported に落ちた利用者へ、何を出すか。

ここでよく作られるのが「AR の代わりに静止画」という劣化版です。体験の価値が落ちるので、利用者は損をした気分になります。

このサービスには、AR 体験とは別にデジタルコンテンツの配信という機能がありました。特典画像・PDF・動画・音声を届けられるもので、画像と PDF はダウンロードでき、動画と音声はストリーミングが基本、回数制限付きダウンロードにも対応するとされています。

つまり、AR とは独立した配信経路があるということです。設計としてはこう置けます。

QR → 入口ページ
        ├─ 条件を満たす → AR 体験
        └─ 満たさない   → デジタルコンテンツの配信（AR の代替ではなく、それ自体が特典）

代替を「AR のかわり」と説明しないことが肝心です。最初から2つの受け取り方があるという見せ方にすれば、どちらに落ちても利用者の体験は完結します。

容量の制約を先に見る

代替経路を用意すると、配信するファイルが増えます。ここで容量の上限に当たります。

配信データの枠は基本3GBで、そこを超えると1GBあたり2,000円の初回費用が乗ります。

AR 用のアセットと配信用の特典が同じ枠を食うなら、枠の割り当てを先に決めてからエンコードの設定を決めることになります。逆順にすると、必ず超えます。

権利の処理も分岐に影響する

音を使う場合、JASRAC／NexTone の管理楽曲は、商品税抜販売価格 × 数量 × 1.5% の費用が発生します。

計算式に販売価格と数量が入っているため、AR 体験と代替コンテンツで同じ曲を使うかどうかが金額の話になります。設計段階で決める項目に入れておきます。

計測しないと直せない

最後に、判定結果をログに残す話です。

diagnose() の戻り値を、そのままイベントとして送っておきます。すると運用が始まってから、どの理由で何%が落ちているかが分かります。

browser_mismatch が多い → 入口ページの案内を直す
os_too_old が多い → 推奨環境の告知を配布物の紙面に入れる
permission_denied が多い → 許可を求める前の説明文を直す

「動かなかった」を1つのカウンタで数えていると、どれも直せません。理由ごとに数えていれば、次に打つ手が決まります。

まとめ

動作条件は独立した複数の条件。1つのブール値に潰さない
失敗の理由ごとに、利用者が取れる行動を出す
検出できない条件(端末の台数)は、前提のほうを動かして解決する
代替は劣化版にしない。独立した受け取り方として設計する
容量と権利は、分岐を増やすと効いてくる。先に枠を決める
判定結果を理由別に計測する

動作条件は更新されることがあります。実装に入る前に、最新の記載を見てください。

本ページはプロモーションが含まれています

締切・予選・本戦を同じカレンダーに入れると、締切が消える

Hajime — Mon, 14 Sep 2026 09:13:20 +0000

締切・予選・本戦を同じカレンダーに入れると、締切が消える

大会の予定をカレンダーに入れる仕組みを作ると、ほぼ必ず同じ不具合が出ます。

応募の締切が、一覧から消えます。

理由は単純で、「今月の予定」を出すときに開催日で絞り込むからです。本戦が12月にあるイベントは12月の欄に入り、9月に閉まる応募期限は、9月の一覧のどこにも出てきません。

実際のデータで確かめてみます(2026年9月9日に確認した内容)。

→ 大会の日程と応募期限を確認するなら e-Sports TODAY

問題が起きる実例

こういう予定がありました。

JeSU「全国都道府県対抗eスポーツ選手権 2026 オンライン - Road to the NEXT -」は 12月12日・13日。ただしグランツーリスモ7部門の予選は9月6日まで
全日本高校eスポーツ選手権は、エントリーが9月10日18時までで、予選は9月26日開始

上のイベントは、開催日だけを持つと12月の予定になります。しかし、9月6日を過ぎたら出られません。9月上旬の画面に何も出ないまま、機会が閉じます。

下のイベントも同様で、エントリーの締切と予選の開始が別の日にあります。しかも締切には時刻まで付いています。18時。

1つのテーブルに入れない

素直にやると、こうなります。

{ "name": "…", "date": "2026-12-12" }

ここに締切を足そうとして、フィールドを1つ増やす方向へ行くと破綻します。

{ "name": "…", "date": "2026-12-12", "deadline": "2026-09-06" }   // ← 部門ごとに違う

先ほどの例では、締切はグランツーリスモ7部門のものでした。イベント全体の締切ではありません。1イベント1締切を前提にした時点で、表現できない現実が出てきます。

分けます。イベントと、そこに紐づく期限を別の実体にする。

{
  "event_id": "jesu-kokutai-2026",
  "name": "全国都道府県対抗eスポーツ選手権 2026 オンライン - Road to the NEXT -",
  "phases": [
    { "kind": "final", "from": "2026-12-12", "to": "2026-12-13" }
  ],
  "gates": [
    { "kind": "entry_close", "scope": "グランツーリスモ7部門", "at": "2026-09-06", "precision": "day" }
  ]
}

phases — 期間を持つもの。開催・予選・本戦
gates — 時点で閉まるもの。エントリー期限、申込期限

この2つは、カレンダー上での扱いがまったく違います。期間は「その間ずっと」ですが、時点は「そこを過ぎたら終わり」です。同じ配列に入れると、必ずどちらかの表示が壊れます。

precision を持たせる

締切に時刻が付く場合と付かない場合があります。

グランツーリスモ7部門の予選: 9月6日まで(日付のみ)
全日本高校eスポーツ選手権のエントリー: 9月10日18時まで(時刻あり)

ここで全部を 2026-09-06T23:59:59 のように正規化すると、書かれていない情報を足したことになります。「まで」が当日いっぱいなのか、営業時間内なのかは、発表されていない限り分かりません。

precision: "day" | "minute" を持たせて、表示のときに切り替えます。

const label = (g) =>
  g.precision === 'minute'
    ? `${fmtDate(g.at)} ${fmtTime(g.at)}まで`
    : `${fmtDate(g.at)}まで`;

推測して埋めた時刻を、確定した時刻の顔で表示しない。これが要点です。

一覧の絞り込みを2本立てにする

データを分けたら、取り出し方も分けます。

// 期間もの: その月に「かかっている」ものを拾う（またぐイベントを落とさない）
const phasesIn = (month) => events.flatMap(e =>
  e.phases.filter(p => overlaps(p, month)).map(p => ({ e, p }))
);

// 時点もの: その月に「閉まる」ものを拾う
const gatesIn = (month) => events.flatMap(e =>
  e.gates.filter(g => inMonth(g.at, month)).map(g => ({ e, g }))
);

期間ものに overlaps を使うのが大事で、開始日だけで絞るとまたぐイベントが消えます。

たとえば、第20回アジア競技大会(2026/愛知・名古屋)のeスポーツ競技は9月23日から10日間です。開始日で絞ると10月の一覧に出ません。東京ゲームショウ2026 の9月17日〜21日のような5日間のものも同じ理屈で、月をまたぐ配置なら消えます。

締切のほうを先に出す

表示の順序も設計の一部です。

9月の画面を作るなら、こうします。

■ 今月閉まるもの
  09/06  グランツーリスモ7部門 予選エントリー（全国都道府県対抗 2026）
  09/10 18:00  全日本高校eスポーツ選手権 エントリー

■ 今月ひらくもの
  09/13        ALGS Year 6 Split 2 APAC North リージョナルファイナル
  09/17〜09/21 東京ゲームショウ2026（幕張メッセ）
  09/23〜      第20回アジア競技大会 eスポーツ競技（Aichi Sky Expo 展示ホールD）
  09/24〜      VALORANT Champions 2026（上海）
  09/26        全日本高校eスポーツ選手権 予選開始

閉まるものを上に置く。開くものは見逃しても次があることが多いですが、閉まるものは一度きりです。

種目とタイトルが1対1ではない

もう1つ、phases の中でつまずく点があります。

アジア競技大会のeスポーツ競技は、10日間で11種目13タイトルと記載されていました。種目数とタイトル数が一致していません。

つまり、phases の1件に対して、実施される中身が複数あります。開催期間だけを持って「1イベント」として扱うか、種目単位まで割るかは、何を見せたいかで決めます。一覧に出すだけなら前者で足りますが、「この日に何があるか」を出すなら後者が要ります。

最初から後者で作ろうとすると、データが集まらずに詰まります。先に前者で動かして、必要になったら割るほうが現実的でした。

出場枠の数は、日程ではない

ついでに注意点を1つ。

ALGS の APAC North リージョナルファイナルは上位20チーム
VALORANT Champions 2026 は出場16チーム

こういう数字を phases に混ぜたくなりますが、枠の数は日程の属性ではありません。別のフィールドに置きます。混ぜると、日程を更新するたびに枠の数まで書き換えることになります。

まとめ

期間もの(phases)と時点もの(gates)を分ける。同じ配列に入れない
締切は部門ごとに違いうる。1イベント1締切にしない
時刻の有無を precision で持つ。書かれていない時刻を補わない
期間の絞り込みは overlaps。開始日だけで絞るとまたぐイベントが消える
表示は閉まるものを先に出す
枠の数など、日程以外の属性を phases に混ぜない

日程は変更されることがあります。取り込むなら取得日を添えて持ってください。

本ページはプロモーションが含まれています

特典と引き換えに受け取ったメールアドレスを、あとから止められる形にしておく

Hajime — Sun, 13 Sep 2026 08:13:28 +0000

特典と引き換えに受け取ったメールアドレスを、あとから止められる形にしておく

配布物から個人情報を受け取る導線は、作るのは簡単で、やめるのが難しいという性質があります。

紙に印刷したQRコードは回収できません。入口を閉じても、あとから読み取る人は出てきます。受け取ったアドレスは、送るのをやめても手元に残ります。始める前に、やめ方を決めておく話です。

題材として、AR対応の販促カードが公開している仕様を使います(2026年9月9日時点)。

→ 認証付きのAR対応カードを検討するならデジスタカード

どこで個人情報が入ってくるか

カードのプランは3つあり、そのうち認証付きのものが該当します。

シリアルコードやログイン認証で対象者だけに中身を公開でき、認証でのメール収集に対応すると記載されています。

流れとしてはこうなります。

カード（QR）→ AR体験 → 認証（シリアル or ログイン）→ 特典の公開
                                   └─ ここでメールアドレスを受け取る

設計上の要点は、認証と収集が同じ画面に同居していることです。利用者から見れば「特典を見るための手続き」であって、「メールアドレスを渡す手続き」という自覚は薄い。ここを混ぜたまま作ると、後から説明できなくなります。

目的ごとに分けて受け取る

最低限、認証のために必要な入力と、継続的な連絡のための同意を分けます。

{
  "serial": "XXXX-XXXX",
  "email": "…",
  "purposes": {
    "unlock":   { "granted": true,  "at": "2026-09-09T12:00:00+09:00" },
    "newsletter": { "granted": false, "at": null }
  },
  "source": { "campaign": "card-2026-autumn", "plan": "auth" }
}

unlock は、特典を開くために必要な処理
newsletter は、それとは独立した同意

既定値を false にしておくこと。そして at を必ず持つこと。「いつ同意を得たか」が残っていないと、後から確認できません。

source.campaign を入れておくのも効きます。どの配布物から入ってきたアドレスかが分かると、その配布物ぶんだけを止めるということができます。全部まとめて止めるか続けるか、の二択にしないためです。

「やめる」を3段階で用意する

撤退の粒度を分けておきます。実際に必要になる場面が違います。

段階	何を止めるか	いつ使うか
配信停止	そのアドレスへの送信	利用者からの申し出
導線停止	新規の受け付け	キャンペーン終了時
削除	保持しているデータ	保存期間の満了、利用者からの請求

多いのは、配信停止だけ実装して残り2つを忘れるパターンです。

とくに2番目が抜けやすい。キャンペーンが終わっても、カードは配られたまま世の中にあります。QRを読み取った人が入力欄にたどり着いて、どこにも届かないアドレスを入力する、ということが起こります。

入口を閉じるときは、閉じたことが分かる画面を出します。入力欄を残したまま送信だけ捨てるのは最悪の形です。

if (campaign.status === 'closed') {
  return renderClosed({
    message: 'このキャンペーンの受け付けは終了しました。',
    // 特典そのものは見られる形にできるなら残す
    contentStillAvailable: campaign.contentPublic,
  });
}

期限は印刷物の寿命より長く見積もる

カードは財布に入ります。数年後に出てくることがあります。

ですから、キャンペーンの終了日 = 導線の終了日にしないほうがいい。終了後も「終了しました」と表示するページは生かしておきます。QRの遷移先が404になるのは、体験としても、信頼の面でも悪い。

保持期間は逆に、必要な期間で切る。両者は別のタイマーです。同じ設定値で動かさないようにします。

認証方式で、集まるものが変わる

認証にはシリアルコードとログイン認証の2通りが挙げられていました。性質が違います。

シリアルコード — カードに印刷された値。刷った時点で確定し、後から変えられない
ログイン認証 — 利用者のアカウントに紐づく。カード側は入口だけを持つ

シリアルは、印刷物の性質をそのまま引き受けます。発行数は刷った枚数で固定され、流出しても差し替えられません。1枚1コードにするのか、全枚数で共通コードにするのかを、入稿前に決める必要があります。

共通コードは運用が楽ですが、1人に配ったつもりが共有されます。個別コードは管理が要りますが、誰が開いたかが分かるので、配信停止の対象を特定できます。

撤退可能性の観点では、個別コードのほうが扱いやすい。ただし、刷り直しはできないという前提は変わりません。

LINE連携を足す場合、止める対象が増える

オプションとして、AR体験を入口に LIFFブラウザ経由でLINEミニアプリを起動する構成や、公式アカウントの友だち追加へ誘導する導線を設計できる、という機能が用意されていました。その先にスタンプ配布やキャンペーンを重ねる使い方も挙がっています。

導入には企業側の準備が要ります。LINE公式アカウントの開設、LINE Developers での設定(プロバイダー / LIFFアプリ)、アカウントの管理・設定対応。LINEの仕様により、構成や運用方法に応じて設計の調整が必要になる場合がある、とも書かれていました。

ここで効いてくるのが、FAQ にあったこの記述です。

プロバイダーへの公式アカウントの紐付けは1回限りで、あとから差し替えられません。自社環境で構築して紐付けるのが最も安全なフローとして案内されています。

これは撤退可能性が最も低い項目です。アドレスは消せますが、紐付けは戻せません。着手の順序としては、ここを最初に決めます。

なお、利用者が新しくアプリを入れる必要はなく、LINEアプリの上でミニアプリとして起動する、ともありました。利用者側の負担は増えません。増えるのは運用する側が止められないものの数です。

期間

カード自体の製造は、仕様確定後通常1〜2週間程度。LINE連携の組み込みやスタンプの申請(LINE側の審査期間を含む)は、アカウントの準備状況で変動する、とされています。

実装側から見ると、製造期間のほうが読めるということになります。詰まるとしたらアカウント周りです。

チェックリスト

着手前に決めておく項目を並べます。

[ ] 認証のための入力と、継続連絡の同意を別のフラグで持つ
[ ] 同意の取得日時を保存する
[ ] 配布物を識別する値(campaign)を、受け取るデータに含める
[ ] 配信停止・導線停止・削除を別々の操作として実装する
[ ] 終了後に表示するページを用意する。404にしない
[ ] シリアルを個別にするか共通にするかを、入稿前に決める
[ ] 保持期間のタイマーと、導線の公開期間のタイマーを分ける
[ ] LINEのプロバイダー紐付けを、着手の最初に決める

仕様は更新されることがあります。設計に入る前に、そのときの記載を確認してください。

本ページはプロモーションが含まれています