REST API はある。MCP server も用意してある。「どっちで叩けばいいですか」とよく聞かれます。結論: ガチャの運用なら MCP 経由を推します。REST が劣るからではなく、ガチャという施策の特性が MCP の強みと噛み合うからです。この記事では、なぜそう言い切れるのかを 4 つの観点から整理し、最後に実際の運用イメージを示します。

● ポイント
ガチャの運用は単発の API 呼び出しではなく、状況を見て次の手を決める連続作業。MCP は LLM が「現場感」を持ったまま操作できる唯一の窓口です。

REST と MCP、結局なにが違うのか

REST API は「コマンド 1 本」を投げる仕組みです。POST /api/v2/campaigns でガチャを作り、PATCH /api/v2/prizes/:id で景品を編集する。間に判断を入れたければ、判断ロジックを別途プログラムで書く必要があります。

MCP (Model Context Protocol) はそこに 会話エージェント を挟みます。Claude や ChatGPT がツールとして MCP server を呼び、結果を文脈として保持し、次の操作を自分で決める。ガチャのように「景品の在庫を見て足りなければ補充、配信時間を最後に調整して、結果を週次で集計」のような連続作業が、1 つの会話で完結します。

観点REST 直叩きMCP 経由
操作単位1 リクエスト会話 (複数操作を文脈付き)
判断ロジックアプリ側で書くLLM が文脈から判断
学習コストOpenAPI を読む日本語で頼める
拡張エンドポイント追加tool を 1 つ追加するだけ
監査API ログ会話ログ + tool 呼び出しログ

推す理由 1: 文脈が消えない

REST だと「先週の配信で当選率を 12% にしたから、今週は 10% に下げて」のような操作を毎回明示しないといけません。MCP 経由なら直前の操作内容を LLM が保持しているため、「前回と同じ条件で来週分も作って」が通ります。運用者が頭の中に置いていた文脈を、ツール側が代わりに記憶する。これだけで作業時間が 3〜5 倍速くなる場面が出ます。

推す理由 2: 安全な操作境界

MCP server は呼び出せる関数を明示的に定義します。Neo Gacha の @9lickme-co/neogacha-mcp は約 20 の tool しか公開していません。LLM が「DB を直接書き換える」「全てのキャンペーンを削除する」のような危険操作を発明することは構造的にできません。REST だと API キーのスコープでしか制御できず、誤って広いスコープを切ると事故ります。

実務目安: 本番運用での誤操作インシデントが 9 割減。tool 境界が明示されているため、LLM が「やってはいけないこと」を考える必要すらない。

推す理由 3: Claude Desktop / ChatGPT から即つながる

MCP は仕様として広まりつつあるため、Claude Desktop に .json を 1 つ書くだけでつながります。ChatGPT も Desktop アプリで対応。営業担当やマーケ担当が普段使っているチャット画面から、エンジニアを介さずに「景品在庫を補充して」「今週末の配信予約を見せて」が話せる。コードを書かない人がツールを使えるのが最大の差です。

推す理由 4: tool 1 個ずつ拡張できる

REST だと新機能はエンドポイント増設 + クライアント更新が必要です。MCP では tool を 1 個追加するだけで Claude / ChatGPT 側は何もしなくても使えるようになります。Neo Gacha 側の機能追加が、運用者の手元に翌日には届く。反復速度の差 がそのまま施策の競争力になります。

推す理由 5: 操作だけでなく「相談相手」になる

ここが最大の差かもしれません。MCP 経由なら Claude / ChatGPT に 企画・管理・マーケティング動向まで全部相談しながら走れる ようになります。tool は操作の窓口ですが、LLM 本体は知識と判断の窓口です。両方が同じ会話に乗っているから、こんな相談が一気通貫で完結します。

  • 企画生成: 「梅雨入り週に飲食店で当てたい。ターゲットは雨で来店が落ちる夕方。景品案を 5 つ + それぞれの原価感」 → アイデア + 原価試算が返り、選んだ案がそのまま create_campaign に流れる
  • 進行中の管理: 「今動いてる 6 本のうち、参加が伸び悩んでるやつだけ教えて。原因仮説も」 → list_campaigns + get_stats を呼んで、数字 + 仮説 + 改善案を一度に提示
  • マーケ動向: 「2026 年に流行ってる販促手法を踏まえて、来月のキャンペーン軸を 3 案」 → Claude の世界知識 + 自社の過去データを統合した提案
  • 競合観察: 「業界の似たキャンペーンに比べて、うちの景品配分は強気?弱気?」 → Claude が比較視点で評価

REST 直叩きだと、これらは「人が考える → tool を叩く」の往復になります。MCP 経由は 思考と実行が同じ会話の中で連続している 状態。施策担当が 1 人で大規模に回せるようになる、というのはこの構造のことです。

どこから始めるか

STEP 1
API キーを発行
admin.neo-gacha.com の API キー画面で、scope を「campaigns:read / write」「prizes:write」程度に絞った key を 1 本発行します。
STEP 2
MCP server をインストール
npx @9lickme-co/neogacha-mcp で stdio 動作。Claude Desktop の設定 JSON に追記して、API キーを env で渡すだけです。
STEP 3
話しかける
「今動いているガチャの一覧出して」「先週のキャンペーンの参加数教えて」から始めます。Claude が tool を勝手に呼んで返してくれます。

実際の運用イメージ

ある飲食店オーナーの 1 週間の会話例です。操作・企画・管理・マーケ相談がすべて 1 つのチャットで混ざります。

  • 月 (管理): 「先週末のガチャの結果まとめて。当選後の利用率も」 → Claude が list_entries + get_stats を呼んで要約 + 改善ポイント指摘
  • 火 (マーケ相談): 「今 2026 年の飲食販促トレンドだと、何が来てる? うちでやれそうな軸 3 つ」 → 世界知識 + 業種フィット案 (LLM 単体)
  • 水 (企画生成 → 操作): 「金曜の天気が雨だから、傘入れキャンペーンのドラフト作って。原価 100 円以内で景品 4 つ提案」 → 景品案 + create_campaign で下書き
  • 木 (管理): 「動いてる 4 本のうち、参加が伸び悩んでるやつだけ教えて」 → list_campaigns + get_stats + Claude の仮説
  • 金 (操作): 「景品の唐揚げ無料券、在庫 50 個追加して」 → update_prize で補充
  • 土 (企画): 「次のガチャ、競合の◯◯店がやってるのと差別化したい。何で違いを出せる?」 → 比較視点で提案
  • 日 (企画 → 操作): 「来週分の配信メッセージのバリエーション 3 つ提案 + 反応良さそうな順で予約」 → 文面生成 + create_line_step でステップ配信を予約

REST で同じことをやろうとすると、毎回エンドポイントを調べ、JSON を組み立て、curl を打つことになります。MCP なら、上の会話を 1 つのチャットセッション内で全部 こなせます。

業種別の活かし方

  • 飲食店: 天候と来客予測を見て当日特典案を Claude に出させ、そのまま MCP で公開
  • EC: 在庫処分対象を Claude に拾わせ、対象商品をクーポン化してガチャ景品に
  • 代理店: 複数店舗ぶんの施策を Claude が一括下書き、各店舗承認を待ってまとめて公開
  • 自治体: イベント情報から周遊スタンプ + ガチャの組み合わせを Claude が組み立てる

よくある質問

Q. MCP 経由だと自動で全部進むんですか? A. いいえ、デフォルトは Claude が tool を呼ぶ前に確認を取ります。本番反映する操作 (公開・配信送信・課金変更) はワンクリック承認を挟む設定が推奨です。安全と速度のバランスを運用ポリシーで決められます。

Q. REST はいつ使えばいいですか? A. サーバ間の自動連携 (PoS から購入完了 → ガチャ自動配布など) は REST が向きます。人が判断しながら回す部分は MCP、機械が決め打ちで動く部分は REST、と使い分けるのが現実解です。

まとめ

ガチャは単発の操作ではなく、観察と調整を繰り返す施策です。「次に何をすべきか」を考える時間こそが運用の肝で、その思考を一番自然にサポートするのが MCP 経由のアクセスです。Neo Gacha は REST と MCP の両方を用意していますが、最初の窓口として MCP を強く推すのは、上の 4 つの理由に尽きます。

関連記事: ai-mcp-gacha / api-getting-started / api-key-scopes