顧客一覧
契約中の顧客と提供形態。ライセンス数を超える端末は登録できないが、顧客は管理画面でいつでもライセンスを追加できるため、営業が止まることはない。
顧客数
6
稼働 5 / 停止 1
POS端末（当月最大）
6,412
初期契約 合計 12,000
WEB利用者（当月最大）
1,043
T3以上のみ
店舗数
2,187
全顧客合計
顧客
| 顧客ID | 顧客名 | プラン | 店舗 | 初期契約 | POS実績 | WEB契約 | WEB実績 | 認証 | 状態 | |
|---|---|---|---|---|---|---|---|---|---|---|
| alpha | アルファ製菓 株式会社 | T1 専有 | 1,240 | 4,000 | 3,318 | 800 | 612 | SSO | 稼働 | |
| bravo | ブラボー洋菓子 株式会社 | T2 VPC | 352 | 2,000 | 1,486 | 1,000 | 358 | SSO | 稼働 | |
| charlie | チャーリー食品 株式会社 | T3 共同 | 84 | 400 | 271 | 120 | 73 | パスワード | 稼働 | |
| delta | デルタ商会 株式会社 | T4 サーバレス | 498 | 3,000 | 1,204 | — | — | — | 稼働 | |
| echo | エコー製パン 株式会社 | T4 サーバレス | 12 | 50 | 18 | — | — | — | 稼働 | |
| foxtrot | フォックス物産 株式会社 | T4 サーバレス | 1 | 10 | 115 | — | — | — | 停止 |
foxtrot は初期契約 10 に対して実績 115
上限は設けず、超過でも端末は止めない（止めると店舗が営業できない）。
実績で請求するため精算は自動。ただし急増はバグや不正の兆候でもあるため通知する。
超過を検知して請求時に精算するか、営業に通知するかは要判断。
新規顧客の追加
登録するとバケットが作成され、初期登録トークンが発行される。
プラン
1,000店舗以上の目安。AWSアカウントを専有する。
上限ではなく初期の契約数。
課金は「その月の最大登録台数」で算定するため、顧客が端末を増減しても手続きは不要。
上限を設けない代わりに、急増を検知して通知する。
T3以上は必要数を登録する。
顧客情報
変更不可。バケット名とサブドメインに使うため。
半角英小文字・数字・ハイフン（3〜24字）。
バケット: salasee-alpha / -out / -in 管理画面: alpha.salasee.com（T2以上）
バケット: salasee-alpha / -out / -in 管理画面: alpha.salasee.com（T2以上）
法人情報
レシートに印字するため必須。
機能のON/OFF
| 機能 | 状態 | 備考 |
|---|---|---|
| 売上確認 | ON | WEBを使う場合は必須。ここがOFFなら実質 T4 |
| 在庫管理 | ON | WEBを提供する顧客でも売上しか要らない場合はOFF |
| 棚卸登録 | ON | 在庫管理がOFFなら選択不可 |
| ロス登録 | ON | 同上 |
| 賞味期限登録 | ON | 菓子・食品業態向け |
| 売上バッチ連携 | ON | CSV / JSON を S3・SFTP へ指定間隔で出力 |
プランと機能は別物。プランは請求の単位で、機能は個別に設定する。
「T3 だが在庫管理は不要」という顧客がいる。
WEB管理画面の認証方式
SSO の場合、顧客側 IdP のメタデータを別途登録する。
作成されるもの
| S3 バケット ① Salasee | salasee-alpha |
| プレフィックス | tx/ cash/ settle/ stock/ report/ notice/ image/ log/ |
| 顧客への権限 | 与えない。端末とSalaseeのみ |
| S3 バケット ② 売上連携 | salasee-alpha-out |
| プレフィックス | sales-out/ |
| 顧客への権限 | Get / Delete のみ（Put を与えない ── 売上データを差し替えられないようにする） |
| S3 バケット ③ マスタ | salasee-alpha-in |
| プレフィックス | master-in/ |
| 顧客への権限 | Put のみ（Get / Delete を与えない ── 送った値を消せないようにする） |
| IAM ロール（STS引受用） | salasee-tenant-alpha（端末用）／ -out・-in（顧客基幹用） |
| KMS キー | alias/salasee-alpha |
| 初期登録トークン | 発行（設定QRに埋め込む） |
| Object Lock | tx/ のみ有効（7年・ガバナンスモード） |
アルファ製菓 株式会社
alpha T1 エンタープライズ 稼働
POS端末（当月最大）
3,318
初期契約 4,000
WEB利用者（当月最大）
612
WEBライセンス 800
店舗数
1,240
稼働 1,198
当月の取引
1.27M
S3 オブジェクト数
契約情報
変更不可
AWS リソース
| バケット ① Salasee | salasee-alpha | 正常 |
| バケット ② 売上連携 | salasee-alpha-out | 正常 |
| バケット ③ マスタ | salasee-alpha-in | 正常 |
| KMS キー | alias/salasee-alpha | 正常 |
| STS 引受ロール | arn:aws:iam::xxxxxxxxxxxx:role/salasee-tenant-alpha | 正常 |
| 専有アカウント | xxxxxxxxxxxx | 正常 |
| Object Lock | tx/ 7年（ガバナンスモード） | 有効 |
バケットを3つに分ける理由 ── 基準が2つある
① Salaseeバケットには顧客のアクセス権限を与えない。
一方、売上連携・マスタバケットは顧客の基幹システムが直接読み書きし、
取得後にファイルを削除する処理を顧客が自前で作る可能性がある（特に T4、T3 でもあり得る）。
Delete 権限を渡す先と渡さない先を同じバケットに置けないため、物理的に分ける。
共通バケット（Salasee側が全顧客分を1つに持つ形）でも運用できる構成にしておく。
機能のON/OFF
| 機能 | 状態 | 備考 |
|---|---|---|
| 売上確認 | ON | WEBを使う場合は必須 |
| 在庫管理 | ON | — |
| 棚卸登録 | ON | — |
| ロス登録 | ON | — |
| 賞味期限登録 | ON | — |
| 売上バッチ連携 | ON | 基幹へ日次 CSV を SFTP 出力（22:00） |
端末（代行操作）
端末の解放は顧客のWEB管理画面の機能
課金が実績ベースなので、顧客が自分で解放できないと使っていない端末の分を払い続けることになる。
ここに置くのは、顧客が操作できない状況の代行のみ。
| 店舗ID | 端末ID | 機器ID | 最終認証 | アプリ版 | 状態 | |
|---|---|---|---|---|---|---|
| 0001 | 01 | a3f9…c214 | 2026-09-02 09:12 | 1.0.4 | 正常 | |
| 0001 | 02 | 7b21…88de | 2026-09-02 09:08 | 1.0.4 | 正常 | |
| 0042 | 01 | e08c…41a7 | 2026-08-24 18:40 | 1.0.3 | 9日未接続 | |
| 0117 | 03 | 2d55…9f0b | 2026-07-30 20:02 | 1.0.1 | 猶予期間超過 |
危険な操作
顧客の削除とバケットの削除は分ける
契約終了後もジャーナルの保存期間が残るため、顧客を削除してもバケットは残す。
バケットの削除はジャーナルの引き渡し（顧客による全ダウンロード）を確認してから、別操作で行う。
Object Lock はガバナンスモードにする
コンプライアンスモードはAWS の root ユーザーでも期間中は削除できないため、
契約終了時にバケットを消せなくなる。ガバナンスモードなら誤削除とランサムウェアを防ぎつつ、
正当な手続きで削除できる。
ライセンス実績
課金の元になる数値。その月に一度でも登録された端末を数えるため、月末に外して翌月頭に戻しても減らない。
初期契約数と課金を分離する
契約数は初期の目安にとどめ、金額は実績で決める。
これにより顧客が端末を増減してもSalaseeAI側の作業が発生しない。
顧客が節約したい場合は自分で端末を解放し、翌月から自動的に安くなる。
2026年8月
| 顧客 | プラン | 初期契約 | POS最大 | POS平均 | WEB最大 | 超過 |
|---|---|---|---|---|---|---|
| アルファ製菓 | T1 | 4,000 | 3,318 | 3,102 | 612 | — |
| ブラボー洋菓子 | T2 | 2,000 | 1,486 | 1,440 | 358 | — |
| チャーリー食品 | T3 | 400 | 271 | 265 | 73 | — |
| デルタ商会 | T4 | 3,000 | 1,204 | 1,180 | — | — |
| エコー製パン | T4 | 50 | 18 | 18 | — | — |
| フォックス物産 | T4 | 10 | 115 | 98 | — | +105 |
アルファ製菓 ─ 登録端末数の推移
2025-092026-02 繁忙期2026-08
2月に催事で端末が増える。上限を設けない方針なので止まらないが、請求はこのピーク月だけ高くなる。
料金体系
T1・T2 は個別契約。T3・T4 は定型の体系とし、顧客が自分で増減できる形にする。
ライセンスは顧客が管理画面でいつでも増減できる
ライセンス数を超える端末は登録できないが、
顧客が権限を持つ管理者の操作で即座に追加できるため、営業が止まることはない。
削減は当期の利用実績以下にはできない（月額のため）。当期の計上は翌期から外れる。
T3 スタンダード（WEB管理機能あり）
| 項目 | 単価 | 込み・条件 |
|---|---|---|
| 店舗料金 | ¥5,000 / 店 | POS端末2台込み。機能ON/OFFで変わらない（固定） |
| POS端末（追加） | ¥1,000 / 台 | 機能ON/OFFで変わる（例: 在庫管理OFF → ¥900） |
| WEBアクセス | 込み | 店舗数 ＋ 切り上げ(店舗数 ÷ 10) 個（店長用＋本部用）。100店舗なら 110個 |
| WEBアクセス（追加） | ¥1,000 / 個 | 込み数を超える分 |
1店舗あたり POS 2台が込みなのは、予備端末を持たせるため
1台しかない店舗で端末が壊れると営業が止まる。
2台目は「サービスで付いてくる1ライセンス」という見せ方にする。
そのため各店舗の枠を2台未満にはできない（2店舗5台で「A店1台・B店4台」は不可）。
T4 サーバレス（S3のみ）
| 項目 | 単価 | 込み・条件 |
|---|---|---|
| 基本 | ¥1,000 / 月 | POS端末2台まで（1台でも2台でも ¥1,000） |
| POS端末（追加） | ¥1,000 / 台 | 3台目から |
| WEBアクセス | 込み | 1名のみ。ライセンスの増減操作だけを行える |
T4 は店舗数で課金しない
S3 のみで店舗管理を持たないため、課金の単位は端末数だけになる。
規模は問わない ── 個人店から数万店舗まで同じ体系。
自前でサーバを持っている大手が「上位システムは自社にあるので S3 だけでよい」と選ぶこともある。
最初の2台が同額なのも、予備機を持たせるため
個人店でもコールドスタンバイの1台があれば、故障してもすぐ交換できる。
WEBアクセスライセンスの込み数
| 店舗数 | POS端末（込み） | WEBアクセス（込み） | 店舗料金 |
|---|---|---|---|
| 1 | 2 | 2 | ¥5,000 |
| 5 | 10 | 6 | ¥25,000 |
| 10 | 20 | 11 | ¥50,000 |
| 11 | 22 | 13店長11＋本部2 | ¥55,000 |
| 20 | 40 | 22 | ¥100,000 |
| 50 | 100 | 55 | ¥250,000 |
| 100 | 200 | 110 | ¥500,000 |
計算式は「店舗数 ＋ 切り上げ(店舗数 ÷ 10)」（2026-09-09 確定）
内訳は店舗ごとの店長用1個と、10店舗ごとの本部管理者用1個。
店舗数が多い企業は本部の人数も多くなるため、本部側の枠を店舗数に比例させている。
端の挙動は切り上げである ── 1店舗で 2個（店長1＋本部1）、 11店舗で 13個（店長11＋本部2）、100店舗で 110個（店長100＋本部10）。 切り捨てだと1店舗のときに本部用が 0個になり、成立しない。
端の挙動は切り上げである ── 1店舗で 2個（店長1＋本部1）、 11店舗で 13個（店長11＋本部2）、100店舗で 110個（店長100＋本部10）。 切り捨てだと1店舗のときに本部用が 0個になり、成立しない。
所属は「本部」か「特定の店舗」かを自由に選べる
ライセンス数の範囲内であれば、何個を本部に割り当ててもよい。
店舗所属の利用者はその店舗のデータだけが見える。
ボリュームディスカウント
未決
「ボリュームディスカウントを自動算出する」方針は決まっているが、段階と率が未定。
T1・T2 は個別契約なので対象外。
セルフサインアップ（www.salasee.com）
未決
自由に申込・アプリDL・お試し利用ができる形が理想。
ただし本画面（管理者が顧客を追加する）とは別のフローが必要。
決めることはカード登録の有無／トライアルのデータを本番契約に引き継ぐか／
トライアルの端末数・期間の上限／無料枠の使い回し対策。
リリース管理
ビルド済みの成果物を、どの顧客に、いつ出すかを人が決める画面。ビルド自体は自動。
CI/CD と「リリース操作」は別のもの
Backlog Git への push でビルドまでは自動で走り、成果物（ダイジェスト固定）が並ぶ。
そこから先、どの顧客に配るかはここで人が決める。
T1・T2 は環境が分かれているため、顧客単位でデプロイを制御できないと運用が成立しない。
副産物として顧客単位のカナリアリリースができる。
Backlog Git は CodePipeline のソースに指定できない
CodePipeline が対応するのは S3 / CodeCommit / ECR / GitHub / GitHub Enterprise Server / Bitbucket / GitLab。
Backlog は含まれない（CodeCommit は新規受付停止のため選べない）。
経路は Backlog Webhook → Lambda → CodeBuild（Backlog から clone）→ S3/ECR → CodeDeploy。 clone 用の認証情報は Secrets Manager に置く。
これは現行 Jenkins がやっていること（clone → S3 → 各サーバへ配布）と同じ流れで、 担い手を Jenkins から CodeBuild / CodeDeploy に置き換えるだけ。EC2 とプラグインの保守が消える。
経路は Backlog Webhook → Lambda → CodeBuild（Backlog から clone）→ S3/ECR → CodeDeploy。 clone 用の認証情報は Secrets Manager に置く。
これは現行 Jenkins がやっていること（clone → S3 → 各サーバへ配布）と同じ流れで、 担い手を Jenkins から CodeBuild / CodeDeploy に置き換えるだけ。EC2 とプラグインの保守が消える。
ビルドする
最新コミット f2a91c3（2026-09-02 10:58 森永）
ブランチは選ばせるが、配布するのはコミットハッシュ
ブランチは動く的で、同じ develop を2回配っても中身が違う。
ブランチ名だけを記録すると、後から何を配ったか再現できない。
ビルド時にコミットハッシュへ固定し、配布と履歴はそのハッシュで扱う。
ロールバックは「前のハッシュを配り直す」だけになる。
配布可能なバージョン
| 版 | ダイジェスト | ビルド | コミット | 申請者 | 承認者・承認日時 | 状態 | |
|---|---|---|---|---|---|---|---|
| 1.1.0 | sha256:9c1e…a740 | 2026-09-02 11:20 | f2a91c3 | 森永 | — | 承認待ち | |
| 1.0.5 | sha256:41bb…08e2 | 2026-08-28 19:04 | 7d0e8ba | 森永 | 五城 / 2026-08-28 19:41 | 承認済 | |
| 1.0.4 | sha256:cc07…5f31 | 2026-08-14 10:52 | b1394ef | 森永 | 五城 / 2026-08-14 11:30 | 承認済 |
承認は J-SOX で「必須」ではないが、無いと職務分離を説明できない
基準に「承認ボタンを作れ」という条文はない。求められるのは
開発した人が単独で本番に反映できないことと、
その事実が記録として残っていること。
弊社は人数が少ないため、ここが実質的な論点になる。 申請者と承認者は別アカウントとし、同一人物の自己承認はシステムで拒否する。 承認の対象はダイジェスト（版）で、承認済みの版だけが「配布する」を押せる。
弊社は人数が少ないため、ここが実質的な論点になる。 申請者と承認者は別アカウントとし、同一人物の自己承認はシステムで拒否する。 承認の対象はダイジェスト（版）で、承認済みの版だけが「配布する」を押せる。
顧客の承認を挟む案（2026-09-10）
この画面の承認は弊社内の職務分離のためのもの。
それとは別に、顧客のWEB管理画面でも承認ボタンを押してもらう案がある。
顧客ごとの設定で ON / OFF する。下の「顧客承認つきリリース」を参照。
顧客承認つきリリース 設定が ON の顧客のみ
3段階の関門を通らないとリリース作業ができない
① 弊社が承認依頼を作成（リリース予定日時＝期間指定、リリース内容）
→ ② 顧客が内容を確認して承認（顧客のWEB管理画面）
→ ③ 弊社の2名以上が確認 → リリース作業が可能な状態になる。
③を2名以上にしているのは、顧客の承認を取ったことの確認を1名に委ねないため。 ①の作成者は③の確認者に数えない（自己承認の禁止）。
③を2名以上にしているのは、顧客の承認を取ったことの確認を1名に委ねないため。 ①の作成者は③の確認者に数えない（自己承認の禁止）。
–
期間で指定する。顧客はこの時間帯に営業できない可能性を見て承認する
| 顧客 | 版 | 予定日時 | ① 依頼 | ② 顧客の承認 | ③ 弊社の確認（2名） | |
|---|---|---|---|---|---|---|
| アルファ製菓 | 1.1.0 | 09-20 02:00–04:00 | 森永 / 09-10 11:02 | 未承認 | — | |
| ブラボー洋菓子 | 1.0.5 | 08-29 02:00–04:00 | 森永 / 08-27 09:14 | 承認済先方 経理部長 / 08-28 10:30 | 1 / 2五城 / 08-28 18:20 | |
| チャーリー食品 | 1.0.4 | 08-15 01:00–03:00 | 森永 / 08-12 14:40 | 承認済先方 情報システム室 / 08-13 09:05 | 2 / 2五城・清水 |
どの顧客で ON にするかは要判断
全リリースで承認を取ると承認が形式化して統制の意味が薄れる。
T1・T2（環境が専有で、顧客自身の変更管理の対象になる）と、
会計数値に影響する変更（税率・締め処理・端数処理・帳票様式）に限る案が考えられる。
T3 でも顧客単位のリリースはできる。 共有しているのは EC2 と Aurora のインスタンスであって、 WEBアプリは仮想ディレクトリが顧客ごとに分かれており、DBもスキーマが分かれているため、 アプリの配付も DDL も顧客単位で当てられる。
顧客単位にできないのは OS とミドルウェア（および共通スキーマを設ける場合はそれ）。 ここは全顧客に一斉に効くので、承認の対象外とする。
T3 でも顧客単位のリリースはできる。 共有しているのは EC2 と Aurora のインスタンスであって、 WEBアプリは仮想ディレクトリが顧客ごとに分かれており、DBもスキーマが分かれているため、 アプリの配付も DDL も顧客単位で当てられる。
顧客単位にできないのは OS とミドルウェア（および共通スキーマを設ける場合はそれ）。 ここは全顧客に一斉に効くので、承認の対象外とする。
未決 ── 顧客はどこで内容を確認するか
承認環境（4環境の1つ）で実物を触ってから承認するのが自然だが、
そうすると端末をその環境へ向ける運用が要る。
これは Docs/設計整合性_森永側回答.md 5-1 ③（承認環境を顧客が触るか）と同じ論点。
期限までに顧客が承認しない場合の扱い（延期するのか、承認なしで進める経路を持つのか）も未決。
期限までに顧客が承認しない場合の扱い（延期するのか、承認なしで進める経路を持つのか）も未決。
顧客ごとの適用状況
| 顧客 | プラン | 環境 | WEB版 | 端末アプリ版 | 最終デプロイ | |
|---|---|---|---|---|---|---|
| アルファ製菓 | T1 | acct 4458… | 1.0.5 | 1.0.4 | 2026-08-29 02:10 | |
| ブラボー洋菓子 | T2 | vpc-0a3f… | 1.0.5 | 1.0.4 | 2026-08-29 02:24 | |
| チャーリー食品 | T3 | 共用 / ec2-b | 1.0.4 | 1.0.3 | 2026-08-15 01:40 | |
| デルタ商会 | T4 | S3 のみ | — | 1.0.4 | 2026-08-14 — |
端末アプリの版は「配布」ではなく「許可」になる
WEB は CodeDeploy で押し込めるが、端末アプリはストア配布・自動更新のためこちらから即時に差し替えられない。
ここで持てるのは「この顧客が使ってよい最低版・最新版」であり、実際の更新は端末側の判断になる。要判断。
デプロイ履歴
–
| 日時 | 顧客 | 版 | コミット | 実施者 | 承認者 | 方式 | 結果 |
|---|---|---|---|---|---|---|---|
| 2026-08-29 02:24 | bravo | 1.0.5 | 7d0e8ba | 五城 | 五城 | Blue/Green | 成功 |
| 2026-08-29 02:10 | alpha | 1.0.5 | 7d0e8ba | 五城 | 五城 | Blue/Green | 成功 |
| 2026-08-28 23:31 | alpha | 1.0.5 | 7d0e8ba | 五城 | 五城 | Blue/Green | ロールバック戻し先 1.0.4 |
顧客の監査で提出するのはこの履歴の期間指定エクスポート
CSV 出力は最初から作る。後から足すと、過去分の項目が埋まらない。
配布の記録はコミットハッシュで持つ（ブランチ名では後から再現できない）。 ロールバックは「前のハッシュを配り直す」なので、戻し先の版も履歴に残す。
配布の記録はコミットハッシュで持つ（ブランチ名では後から再現できない）。 ロールバックは「前のハッシュを配り直す」なので、戻し先の版も履歴に残す。
未決 ── 緊急リリースの経路
承認を必須にすると障害対応が止まり、抜け道を作ると統制が無意味になる。
事後承認を必須とし、未承認のまま一定期間が経過したら警告を出す形が現実的だが、
期間と警告先が未定。
利用者管理
サービス管理WEB を使える人。顧客側の利用者ではない。
最初のユーザーだけ自動で全権限になる
2人目以降は未承認として登録され、承認されるまで何も操作できない。
同時アクセスで2人が管理者になる競合を防ぐため、初回判定は一意制約で原子的に行う。
未承認ユーザー 3件
| メールアドレス | 表示名 | 初回アクセス | |
|---|---|---|---|
| ymorinaga@asx.bz | 森永 | 2026-09-02 10:14 | |
| kmatsui@asx.co.jp | 松井 | 2026-09-02 09:47 | |
| sshimizu@asx.co.jp | 清水 | 2026-09-01 16:22 |
承認済みユーザー
| メールアドレス | 表示名 | 権限 | 承認者 | 最終ログイン | |
|---|---|---|---|---|---|
| mitsuki@asx.co.jp | 五城 | 初期管理者 | —（自動） | 2026-09-02 10:31 | |
| ykawamatsu@asx.co.jp | 川松 | 承認済み | 五城 | 2026-08-29 14:02 |
権限は一旦共通
承認済みなら全機能が使える。将来分けるなら、少なくとも
「顧客を削除できる人」と「見るだけの人」は分けたい。
契約停止・顧客削除・端末解放は影響が大きい。
操作ログ
誰がいつ何をしたか。顧客の追加・削除・端末解放・ライセンス変更は必ず記録する。
直近の操作
| 日時 | 実施者 | 対象 | 操作 | 内容 |
|---|---|---|---|---|
| 2026-09-02 10:31 | 五城 | 利用者 | 承認 | ykawamatsu@asx.co.jp を承認 |
| 2026-09-02 09:05 | 五城 | alpha | 端末解放 | 店舗0117 端末03（猶予期間超過） |
| 2026-09-01 17:48 | 川松 | echo | 上限変更 | POS上限 30 → 50 |
| 2026-08-28 11:20 | 五城 | echo | 顧客追加 | T4 / バケット salasee-echo 作成 |
| 2026-08-20 15:02 | 五城 | foxtrot | 契約停止 | 理由: 支払遅延 |
| 2026-08-15 09:30 | —（システム） | 利用者 | 初期登録 | mitsuki@asx.co.jp を初期管理者として自動登録 |