House Duck
← すべての記事

HOUSE DUCK · AUTOMATIC TRANSLATION

ゲーム管理者ページ作成 | ユーザーもいないのに管理画面から作った理由

結論から言うと、

私はSupabaseを直接触りたくなくて

ゲーム管理者コンソールを作ったわけではない。

 

Vibe Codingをする時もターミナルを好む人がいれば、

デスクトップアプリやGUIを好む人もいる。

 

私は間違いなく後者だ。

 

サーバー運用もログやテーブルを一つずつ開いて確認するより

必要な情報が加工された画面で見たかった。

 

可能であればノートPCを開かなくても、

スマホで状態を確認し、必要な運用まで終わらせたかった。

 

許可されたGoogleアカウントのみアクセス可能な House Duck 非公開コンソール

 

ユーザーもいないのに管理画面から作った。

まだ Quirky Ball は正式リリース前だ。

 

それなのに House Duck Consoleにはすでに

分析、プレイヤー、運用、購入・払い戻し、カスタマーサポート、監査ログのメニューがある。

 

少し順番がおかしく見えるかもしれない。

 

しかしゲームをリリースして問題が発生した後、

その時に慌てて運用ツールを作るのでは遅すぎると考えた。

 

ユーザーがゲームをどれくらい長くプレイしたか、

どこで離脱したか、

翌日また戻ってきたか、

広告が頻繁に出すぎていなかったかを

リリース後に初めて悩みたくはなかった。

 

すでに業界で働きながら

数々の試行錯誤を見て

下した結論だった。

 

どうせ要件さえ明確であれば

すべてやり遂げてくれるAIがいるのに、何が問題だろうか?

 


 

ターミナルの代わりに一つの画面で判断したかった。

Supabaseはゲームのデータを保存し、

認証とサーバー機能を接続する基盤だ。

 

しかしデータベースのテーブルは、

管理者がすぐに答えを得られる画面ではない。

 

プレイ時間と完了率、再訪問率、広告視聴率、

ジェムとスタミナの使用量をそれぞれ探すことと、

「今このゲームで異常な部分はどこか?」を一目で把握することは違う。

 

だから生データを

ただ見栄えよく並べるだけで終わらせず、

自分が実際に判断するための問いに置き換えようとした。

 

プレイヤーがさらに蓄積されてから判断すべきであれば、

無理にもっとらしい結論を作らず、そのまま表示する。

 

プレイ時間・完了率・再訪問・広告を質問の形式で整理した実際の分析画面

 

自分に必要なのは綺麗なグラフではなく、

次のアップデートで何を優先して修正すべきか教えてくれる画面だった。

 


 

分析画面で異常なユーザーを見つけたら、その場で直ちに対処したかった。

インサイトを確認した後、

再びSupabaseなどのツールを開きたくなかった。

 

プレイヤーリストでニックネームと表示コードを検索し、

ゲーム数や最高スコア、財貨、直近のプレイを確認する。

 

異常なスコアはランキングから除外または補正し、

必要に応じてアイテムの支給や回収を行い、

特定のユーザーに報酬メールを送れるようにした。

 

運用画面では、

最小サポートバージョンとアナウンスを変更でき、

全体報酬メールの送信も可能だ。

 

購入と払い戻しの履歴を確認し、

support@houseduck.inに届いた

問い合わせを同じコンソール内で処理するフローも組み込んだ。

 

私の言うユーザー制裁とは、

ボタン一つで人をブロックするような自動制裁ではない。

 

実際の記録を確認し、

スコアの除外やアイテムの回収のように

必要な措置のみを選択する方式に近い。

 

重要な変更には理由を入力してもう一度確認させるようにし、

誰が何を変更したのかも監査ログに残す。

 


 

ノートPCの前にいる時だけ運用したくはなかった。

1人の開発者は、開発者でありながらQAであり、

プランナーでありながらカスタマーサポートでもある。

 

常に机の前に座っていられるわけではない。

 

外出先からエラーの報告が入ったり、

アップデート直後に指標がおかしくなったりした時、

スマホで状態を把握し、制限された運用機能を実行したかった。

 

もちろん、すべての危険な機能をモバイルに開放するという意味ではない。

 

照会は素早く、

変更は必要なものだけに絞り、

取り返しのつかない作業は確認と記録を経るようにすることが目標だ。

 

GUIが良かった理由もここにある。

小さな画面でも今どこを見ていて、

どのボタンが実際のデータを変更するのか区別しやすかった。

 


 

セキュリティは確実に処理した。

コンソールは外部に公開するサービスではない。

 

まず許可されたGoogleアカウントでログインし、

その次に自分だけがすぐに思い浮かべられる質問にもう一度答えて初めて開く。

 

Googleログインの後にもう一度確認する個人質問

 

「自分が最初にやったゲームの名前は?」

 

大層なセキュリティ技術のように見せかけるために作った装置ではない。

 

実際の権限はサーバーで改めて確認し、

この質問は誤って別のアカウントや開きっぱなしのブラウザから侵入されることをもう一度防ぐ扉に近い。

 

バイブコーディングで機能を迅速に増やすにつれて

こうした小さな境界がより重要になると感じた。

 


 

バイブコーディングだからこそGUIがさらに必要だった。

AIはコードを素早く作ってくれる。

 

しかし、自分が毎回テーブル名やコマンドを記憶し、

どの作業にどの値が必要なのかを再び説明しなければならないのであれば

運営するたびに開発モードに戻らなければならない。

 

管理画面はそのプロセスをボタンとフォームで固定してくれる。

 

自分が意図した順序通りに確認し、

定められた入力だけを受け付け、

危険な作業はもう一度問いかける。

 

ターミナルをなくすためではなく

繰り返される運営業務こそGUIで製品化したようなものだ。

 


 

まだ完成した管理画面ではない。

機能を作ったからといってすぐに運営できたわけでもない。

 

サーバー関数が抜けていてボタンが失敗することもあれば、

権限設定と実際の運営データが噛み合わずに直したことも何度もある。

 

Project K メニューはまだ外殻に近く、

ストアの返金通知のように自動で連携できていない領域も残っている。

 

正式リリース前のためデータが不足しているカードも多い。

 

それでも今から作っておけば

最初のユーザーが入ってきた後に何を確かめるべきか右往左往せずに済む。

 

House Duck Consoleは見栄えだけのダッシュボードではない。

 

ゲームの状態を一目で把握し、

いつでもどこでも必要な業務だけを慎重に処理するために作った

自分だけの運営用デスクトッププログラムに近い。