| 提案先 | 北海道ホテル＆リゾート株式会社 御中 |
|---|---|
| ご提案 | 株式会社etika（構築・保守）／株式会社LANTERN（窓口） |
| 作成日 | 2026年7月29日 |
| 本書の主旨 | 現行のポイントプログラムを、御社内で運用できる形に作り替えたうえでお引き渡しするご提案 |
御社が進めておられるポイントプログラムの内製化について、現行の仕組みをそのままお引き渡しするのではなく、内製化後に御社ご自身で運用できる形に作り替えたうえでお渡しすることをご提案します。
| 目的 | ポイント・クーポンプログラムの運用を、御社内で完結できる状態にする |
|---|---|
| 手段 | 現行の Airtable + Make.com 構成を、モダンな Web アプリケーション構成へ作り替える |
| 主な効果 | ① ランニングコストの低減 ② これまで外部依頼が必要だった運用変更を御社の手元で実施可能に ③ 将来の Salesforce 連携が容易に ④ 会員数増加・複数業態展開に耐えられる基盤 |
| 進め方 | フェーズ0（要件定義）→ フェーズ1（構築・移行）→ フェーズ2（引き渡し・内製化支援）の段階契約 |
| 工数 | 標準ケース 56人日（想定レンジ 50〜65人日）／期間 約3〜4ヶ月 |
| 費用 | フェーズ0：確定見積り／フェーズ1：概算レンジ（フェーズ0完了時に確定）／保守：月額（要否は御社ご判断） |
現行のポイントプログラムは、以下の構成で稼働しています（2026年7月29日時点）。
| 構成要素 | 現状 |
|---|---|
| 業務ロジック | Make.com の常時運用シナリオ13本に加え、配信予約中の単発シナリオ4本が有効。最大のもの（LINEの動作）は 55モジュール |
| データベース | Airtable 11テーブル（顧客データ 47フィールド） |
| 配信メッセージ | リポジトリ内に配信JSON・テンプレート等 62本。ファイルを複製し手作業で編集する運用 |
| 顧客向け画面 | 自前実装なし。Airtable フォーム＋LIFF URL に依存 |
| 会員証・クーポン | LINE リッチメニューに固定画像として設定 |
現行の仕組みをそのままお引き渡しした場合、御社は以下を引き受けることになります。
上記1〜5は、いずれも引き継ぎのレクチャーでは解消しない、仕組みそのものに起因する課題です。内製化を成功させるためには、引き渡し前にこれらを解消しておく必要があると考えます。
[会員（LINEユーザー）] │ LINEログイン認証（現行の仕組みをそのまま応用） ▼ [会員向けWebページ] ← 新規 ├─ 現在のグレード／保有ポイントの表示 ├─ そのグレードに紐づくクーポンの動的表示 ├─ QRポイント読込 └─ 各種フォーム（詳細アンケート・誕生日入力） │ ▼ [アプリケーション本体（サーバサイド）] ← Make.com から移行 ├─ LINE Webhook受信・応答 ├─ ポイント加点・1日1回制限・修正処理 ├─ グレード判定バッチ（年2回） ├─ セグメント配信 └─ エラー監視・通知 │ ▼ [データベース] ← Airtable から移行 顧客／ポイント履歴／グレード履歴／クーポン／グレード定義 └─ 外部連携用API（将来のSalesforce等との日次同期に使用） [運用管理画面] ← 新規（御社運用担当者様が使用） 配信作成・プレビュー・クーポン設定・グレード閾値設定・会員検索
| 領域 | 現行 | 新システム |
|---|---|---|
| 業務ロジック | Make.com の常時運用13本＋企画ごとの単発配信 | アプリケーションコード＋管理画面からの配信設定（御社資産として保有） |
| データベース | Airtable（プラン別のレコード上限・編集者数課金） | モダンDB（上限に余裕、低ランニングコスト） |
| 会員証・クーポン | リッチメニューに固定画像 | Webページ上に、その会員のグレードに応じて動的表示 |
| フォーム | Airtable フォーム（ID紐付けが不安定・補正処理で回避） | 自前実装（LINEユーザーIDを確実に取得。補正処理そのものが不要に） |
| 配信作成 | JSONファイルを手作業編集 | 管理画面から入力・プレビュー・配信 |
| 運用変更 | 都度 etika へ依頼 | 管理画面から御社で実施（範囲は3章） |
現在は「リッチメニュー＝クーポン」という作りのため、グレードや期間で出し分けるには運用側の差し替え作業が発生します。
新システムでは、会員様がアクセスした時点で、
が動的に表示されます。運用側はクーポンとグレードの対応を管理画面で設定するだけで、会員ごとの出し分けはシステムが行います。会員数が増え、業態やプログラムの種類が増えるほど、この差は運用工数の差として効いてきます。
内製化の成否は、「開発を伴わずに運用変更ができる範囲」がどこまで広いかで決まります。本提案では以下の線引きを想定しています。
| 項目 | 管理画面から 御社で変更 | 開発（改修） が必要 |
|---|---|---|
| 配信メッセージの文面・画像・リンク | ○ | |
| 配信対象セグメントの選択（既存条件の組み合わせ） | ○ | |
| 配信の予約・停止 | ○ | |
| クーポンの内容・有効期限・対象グレード | ○ | |
| グレードの閾値（昇格に必要な利用回数など） | ○ | |
| LINEキーワード応答の文言・キーワード追加 | ○ | |
| 会員情報の検索・個別修正（ポイント誤登録の修正等） | ○ | |
| 新しい判定ロジックの追加（まったく新しいグレード制度など） | ● | |
| 新規業態・新規施設の追加 | 設定で対応 （範囲はフェーズ0で確定） | 大幅な仕様変更時は● |
| LINE以外のチャネル追加 | ● |
この表の内容が、そのまま「内製化できたと言える範囲」の定義になります。フェーズ0で御社の運用実態を伺ったうえで確定させたい部分です。
Salesforce の導入時期・構成が未定であること、および Salesforce の標準項目と現行会員データの間で、初回照合に使う共通キーが未確定であることから、連携の具体設計（どの項目をキーに会員を突き合わせるか、どのオブジェクトに何を持たせるか）は、導入をご検討される時点で確定させる必要があります。
したがって本提案では、次の2点に留めます。
Salesforce 導入が決まった時点で、突き合わせキーとオブジェクト構成を詰めたうえで連携を構築する、という段取りになります。本提案のスコープは「後から連携を追加できる状態にしておくこと」までとし、連携そのものの実装は含みません。
LINEユーザーIDは、連携後に Salesforce のカスタム項目へ保持し、以後の対応付けに使うことができます。ただし、既存の Salesforce 顧客と初めて結び付ける時点では共通の識別子がないため、別の項目による照合が必要です。
| キー候補 | 論点 |
|---|---|
| 電話番号 | 有力候補。ただし現行 Airtable には電話番号項目がないため、今後取得するかの判断が必要。表記ゆれと家族間の重複も論点 |
| メールアドレス | 現行 Airtable に項目はある。未入力率・重複率を確認し、一意に照合できるかを判断する必要がある |
| 氏名＋生年月日の組み合わせ | 単独キーとしては精度が不足。補助的な照合手段 |
| LINEユーザーID | 初回照合には使えないが、一度結び付けた後は Salesforce 側のカスタム外部IDとして保持可能 |
現時点で確定させることはできませんが、いま打てる手は「将来キーになり得る属性を、新システム側で保持・補完できる構造にしておく」ことです。 会員登録時・アンケート時に取得する項目についても、フェーズ0で見直しの余地を確認します。
将来の連携時は、会員の現在値と履歴を分けて扱える構成を想定します。Salesforce 側の具体的な格納先は、導入目的と既存組織の設計を確認してから確定します。
| データ | 想定する持たせ方 | 理由 |
|---|---|---|
| 会員（本体） | Contact（または Person Account）の候補 | 初回照合後、LINEユーザーIDとの対応を保持する |
| 現在グレード・利用カウント | Contact の集約項目、または関連カスタムオブジェクト | Salesforce 側での利用目的に応じて決定する |
| ポイント履歴 | 関連カスタムオブジェクト（追記型） | 加点・修正をイベント単位で保持し、Salesforce 側で集計できる |
| アンケート回答 | 関連カスタムオブジェクト等 | 設問の追加・変更のたびに Contact へ項目が増えるのを避ける |
新システム側では、会員本体とポイント・グレード・回答等の履歴を分けて保持します。これにより、Salesforce 側で Contact の項目に持たせる場合と関連オブジェクトへ分ける場合のどちらにも対応しやすくします。
上記の備えは、現行構成のままでは実現しにくく、新システムであれば設計として織り込めます。
| 観点 | 現行（Airtable + Make.com） | 新システム |
|---|---|---|
| 連携の口 | Airtable の API を Make.com のシナリオ経由で叩く形。同期処理もシナリオとして作り込む必要がある | アプリケーションに連携用のAPIを設計として持たせられる。同期先が Salesforce 以外に増えても同じ口を使える |
| 突き合わせキーの後付け | 項目の追加は可能だが、既存レコードへの一括補完・重複の解消は画面上の手作業になりがち | 補完・名寄せ処理をコードで一括実行でき、やり直しも効く |
| 履歴データの保持 | プラン別のレコード数上限があるため、ポイント履歴を長期に残すほど上限管理が必要 | 上限に余裕があり、履歴を残し続ける前提の設計に耐える |
| 関連オブジェクト構成 | テーブル間のリンクで表現はできるが、Salesforce 側の構造との対応付けは都度シナリオで実装することになる | リレーショナルに設計できるため、Salesforce の「Contact＋関連オブジェクト」構成と対応付けやすい |
| 日次同期の運用 | シナリオの実行回数・処理量が課金と上限に影響する | 日次バッチとして実装。件数が増えても追加コストが小さい |
Salesforce の導入前にデータ基盤を移しておく方が、導入時に決めるべきことが「キーとオブジェクト設計」に絞られ、連携構築の工数は小さくなります。
今回のスコープは「現行機能の移行＋運用管理画面＋動的クーポン表示」ですが、会員データ・利用履歴・配信ロジックが御社側に揃うことで、以下は「追加開発すれば実現できる」状態になります。 現行の Airtable + Make.com 構成では、実現できないか、施策ごとにシナリオを作り込む必要がありました。
| 拡張案 | 内容 | 新システムだから可能になる理由 | 追加工数 の目安 |
|---|---|---|---|
| ステップ配信 （シナリオ配信） | 友だち追加・初回来店・グレード昇格・最終来店からの経過日数を起点に、複数通を自動で順次配信 | 起点となるイベント（来店・加点・グレード変更）が自社DBにあるため、LINE標準のステップ配信では条件に使えない自社データ（グレード・来店履歴・ポイント）を分岐条件にできる | 5〜8人日 |
| AIによる 個別メッセージ 生成・配信 | 利用履歴・グレード・アンケート回答をもとに、会員1人ずつ文面を生成して配信（例：「前回の芦別スターライトホテルのご利用から3ヶ月」） | 会員ごとの文脈データがDBに揃い、配信処理が自社コードであるため、生成 → 検品 → 送信を一連の処理として組み込める | 8〜12人日 |
| 離反予兆の検知と 自動フォロー | 通常の来店間隔を超えた会員を自動抽出し、離反する前にクーポンを配信 | 来店間隔の算出には履歴データの蓄積と集計が必要。レコード数上限のある構成では持ちにくい | 4〜6人日 |
| A/Bテスト配信 | 2案を分割配信して反応率を比較し、勝ちパターンを次回に採用 | 配信ログと来店データを同一DBで突き合わせられる | 3〜5人日 |
| 配信タイミングの 最適化 | 曜日・時間帯ごとの反応率を蓄積し、会員ごとに届きやすい時間に送る | 同上 | 3〜5人日 |
| 拡張案 | 内容 | 新システムだから可能になる理由 | 追加工数 の目安 |
|---|---|---|---|
| 自然言語での セグメント作成 | 「札幌で3ヶ月来ていないゴールド会員」と入力すると抽出条件が生成される | 管理画面と検索条件が自社実装のため、AIの出力を抽出条件に変換できる。運用担当者様が条件式を書けなくても使える＝内製化の実効性が上がる | 4〜6人日 |
| 配信効果レポートの 自動生成 | 配信数・反応・来店転換・グレード分布を自動集計し、月次レポートとして出力 | 現在 etika が手作業で作成している月次レポートを、御社側で自動出力できる状態にする | 5〜8人日 |
| アンケート自由記述の AI要約・分類 | 施設別・テーマ別に自動分類し、改善の示唆を抽出 | 回答データが自社DBにあり、まとめて処理できる | 3〜5人日 |
| 拡張案 | 内容 | 新システムだから可能になる理由 | 追加工数 の目安 |
|---|---|---|---|
| LINEでのAI応答 （問い合わせ一次対応） | 「ポイントいくつ？」「今使えるクーポンは？」等の自然文に、会員データを参照して回答 | 現行はキーワード完全一致の分岐。会員データを参照した応答は自社実装が前提 | 8〜12人日 |
| 複数業態をまたいだ クロス送客 | 温浴の利用者に宿泊を、宿泊の利用者に飲食を案内 | 業態を横断した利用履歴が1つのDBに揃う | 4〜8人日 |
| 記念日起点の 自動配信の拡張 | 現行の誕生月特典を、入会記念日・初回来店記念日などへ横展開 | 日付起点の配信を汎用的に定義できる | 2〜4人日 |
| 店舗スタッフ向け 会員照会画面 | 店頭で会員のグレード・来店履歴・保有クーポンを確認して接客 | 会員データへの参照APIが備わる。将来 Salesforce を導入された際の「店舗での即時参照」要件にもつながる | 5〜8人日 |
見積りとスケジュールを確実にするため、範囲を明確にします。
| フェーズ | 内容 | 主な成果物 |
|---|---|---|
| フェーズ0 要件定義・現行仕様の確定 | 取得済み資料をもとに常時運用13シナリオの現行差分を確認し、仕様として確定。運用実態のヒアリング。管理画面の要件確定。技術構成の確定。移行計画とフェーズ1の確定見積り作成 | 現行仕様書／新システム要件定義書／確定見積り |
| フェーズ1 構築・データ移行・並行稼働 | 新システムの構築、既存データ移行、旧システムと並行稼働させながらの検証 | 新システム（検証環境→本番） |
| フェーズ2 切替・引き渡し・内製化支援 | 本番切替、運用レクチャー、ドキュメント引き渡し、旧環境（Make.com／Airtable）の停止・解約 | 運用手順書／レクチャー／解約完了 |
内製化を実質的に成立させるため、以下を納品物とします。
| 分類 | 納品物 |
|---|---|
| ソフトウェア | アプリケーション一式（ソースコード。御社リポジトリへ引き渡し） |
| インフラ | 本番環境の構築・設定。契約名義の移管手続き |
| ドキュメント | 要件定義書／システム構成図／データベース定義書／運用手順書／障害時の一次対応手順 |
| データ | 移行済みの会員データ・ポイント履歴（移行結果の突合レポート付き） |
| 引き継ぎ | 運用担当者様向けレクチャー（管理画面操作／日常運用）、技術担当者様向けレクチャー（構成・改修の勘所） |
引き渡し後に御社ご自身で改修・拡張いただけるよう、ドキュメントとコードの可読性を納品要件に含めています。
本見積りは、すでに取得済みの Make.com ブループリント、シナリオ構造資料、Airtable 項目定義、既存テスト資料を再利用し、現行調査をゼロからやり直さない前提で算出しています。
次の作業は人による確認が不可欠なため、過度に圧縮しません。
| フェーズ | 作業項目 | 概算 （人日） | 備考 |
|---|---|---|---|
| 0 | 現行 Make.com 常時運用13本のロジック確認・仕様化 | 2 | 取得済みブループリント・構造資料を再利用し、現行との差分だけを確認 |
| 0 | Airtable 11テーブルのデータモデル確認・移行方針策定 | 1 | 項目定義は取得済み |
| 0 | 運用実態のヒアリング・整理 | 2 | 現場確認が必要 |
| 0 | 管理画面の要件定義（3章の線引き、権限、変更履歴） | 2 | |
| 0 | 技術構成の確定・疎通確認（PoC） | 1 | |
| 0 | 移行計画・テスト計画、フェーズ1の確定見積り | 2 | |
| 0 | フェーズ0 小計 | 10 | |
| 1 | 基盤構築（実行環境・自動反映・秘密情報管理） | 2 | |
| 1 | データベース設計・実装 | 2 | |
| 1 | LINE Webhook受信・応答（55モジュール相当の分岐移植） | 4 | ポイント・グレード処理は下記項目へ分離 |
| 1 | ポイント加点・1日1回制限・加点ミス修正 | 3 | |
| 1 | グレード判定バッチ＋事前試験機能 | 2 | |
| 1 | 共通セグメント配信・予約（再試行・送信量制御） | 2 | 単発シナリオの都度作成を廃止 |
| 1 | エラー監視・通知 | 1 | |
| 1 | 会員向けWebページ（LINEログイン／グレード・ポイント表示／動的クーポン／QR読込／各種フォーム） | 5 | |
| 1 | 運用管理画面（認証・権限／配信／クーポン／グレード／キーワード／会員検索） | 7 | 範囲は3章の線引きに依存 |
| 1 | 外部連携用API（日次同期に備えた受け口） | 1 | Salesforce連携そのものは対象外 |
| 1 | データ移行（スクリプト作成・実行・突合検証） | 3 | |
| 1 | テスト整備（自動試験・画面を通した一連の試験） | 4 | 正常・異常・境界条件を含む |
| 1 | 並行稼働・検証・不具合対応 | 2 | カレンダー上の観察期間は別途確保 |
| 1 | フェーズ1 小計 | 38 | |
| 2 | 本番切替（手順書・リハーサル・当日作業） | 2 | |
| 2 | ドキュメント整備（要件・構成・DB・運用・復旧） | 2 | |
| 2 | レクチャー（運用担当者様・技術担当者様） | 1 | |
| 2 | 切替後の監視・初期対応（7日間） | 2 | |
| 2 | 旧環境（Make.com／Airtable）の停止・解約支援 | 1 | |
| 2 | フェーズ2 小計 | 8 | |
| — | 合計（標準ケース） | 56 | 想定レンジ 50〜65人日 |
| フェーズ | 期間の目安 |
|---|---|
| フェーズ0：要件定義 | 2〜3週間 |
| フェーズ1：構築・移行・並行稼働 | 7〜9週間 |
| フェーズ2：切替・引き渡し | 2〜3週間 |
| 全体 | 約3〜4ヶ月 |
2026年9月に着手した場合、2026年10月1日のグレード判定は現行システムで実施し、その後に並行稼働と切替を行います。2027年4月1日の判定を、事前試験を経た新システムで迎える形とし、7.2の推奨と整合させます。
| 区分 | 内容 | 工数 | 金額 |
|---|---|---|---|
| フェーズ0：要件定義 | 現行仕様の確定・新システム要件定義・確定見積り作成 | 10人日 | ［要決定］ 確定金額で提示 |
| フェーズ1：構築・移行 | 開発・データ移行・並行稼働検証 | 38人日 | ［要決定］ 標準ケース。フェーズ0完了時に確定 |
| フェーズ2：切替・引き渡し | 本番切替・レクチャー・ドキュメント引き渡し | 8人日 | ［要決定］ |
| 保守サポート（任意） | 月額 | — | ［要決定］ |
内製化後、日常の運用変更は御社で実施いただけます。保守サポートは主に以下を対象とします。
御社の体制に応じて、契約する／しない／期間限定で契約するをお選びいただけます。
2026年7月29日時点の契約・支払履歴をもとにした比較です。Airtable は2025年5月12日に Business プランの月払いへ変更され、請求対象ユーザーはオーナー1名です。Make.com の追加クレジットは月ごとの変動があるため、2026年1〜6月の6か月平均を用いています。
| 区分 | 現行 | 新システム想定 | 算定の考え方 |
|---|---|---|---|
| Make.com 基本利用料 | 29.00ドル／月 | — | Core 年額348ドルを12ヶ月で換算。月4万クレジット |
| Make.com 追加クレジット | 48.69ドル／月 6か月平均 | — | 2026年1〜6月の合計292.11ドル÷6。7月20日時点は27.39ドル |
| Airtable | 54.00ドル／月 | — | Business 月払い・請求対象ユーザー1名の公式価格 |
| Cloudflare Workers Paid＋D1 | — | 5.00ドル／月から | 現行規模は基本枠内を想定。利用量超過分は従量 |
| 通知・監視等の追加サービス | — | 0〜10ドル／月 | 選定するサービスにより変動 |
| 合計 | 約131.69ドル／月 | 約5〜15ドル／月 | LINE公式アカウント料金はどちらでも継続するため除外 |
想定削減額は 月約117〜127ドル（年約1,400〜1,520ドル）です。割合では大きく下がりますが、ランニングコスト削減だけで構築費を回収する性質の投資ではありません。運用変更の内製化、単発シナリオ作成の削減、障害回避、将来拡張を含めて投資効果を評価する前提です。
注：2025年3月22日のAirtable 240ドルは、変更前のTeamプラン年払いのため現在費用には含めていません。Airtableの54ドルは公式月額です。税・個別割引がある場合は、Organizationの直近請求額で差し替えます。
参考： Make.com Pricing ／ Airtable Plans ／ Cloudflare Workers Pricing ／ Cloudflare D1 Pricing
| # | 確認事項 | 理由 |
|---|---|---|
| 1 | 内製化後の運用担当・技術担当の体制 | 管理画面の要件と、保守サポートの要否判断に直結します |
| 2 | Salesforce 導入の想定時期・構成 | 連携方式の設計に影響します。ただし詳細は導入検討時に詰める前提です（4.1） |
| 3 | 現行ではメールアドレスを保持していますが、電話番号も今後取得するか | Salesforce の既存顧客との初回照合キーに影響します。入力率・重複率もフェーズ0で確認します（4.2） |
| 4 | 複数業態展開の想定（対象業態・時期・会員プログラムを共通化するか分けるか） | データ構造の設計に影響します |
| 5 | 会員数の現状と見込み | インフラ構成とコスト試算の前提になります |
| 6 | 切替の希望時期 | 2026年10月1日のグレード判定との前後関係を確定させます |
| 7 | 5章の拡張機能のうち、優先度の高いもの | 今回の設計に「後から足しやすくしておく」度合いを調整します |
| 8 | クーポンの利用済み管理・店頭消し込みを今回含めるか | 現見積りは動的表示までで、利用済み管理・POS連携は含みません |
| 9 | Airtable Organization の直近実請求額 | 税・個別割引がある場合に、9.6の公式月額を実支払額へ置き換えるために必要です |