Google ログインを組み込んだ経緯と実装

こんにちは！アントロンのNaokoです。

いまは少人数で使う管理画面。利用する人が増えたときの費用や、作り直す手間まで考えると、どの方法で始めるか迷いませんか？

制作を担当している宿の予約システムでも、管理画面のログイン方法を検討しました。最初は Cloudflare Access を使う設計でしたが、ほかの施設にも導入する場合の利用人数と費用を試算し、最初から Google ログインを組み込む案を選びました。

プログラムの実装は Claude Code に頼みました。今回は方式を変更した経緯と、実装内容、テスト環境で確認できた結果を書きます。

解決案：いま使う人数と、増えた場合の人数で考える

今回検討したのは、Cloudflare Access を使う案と、予約システムに Google ログインを組み込む案です。どちらも、Google アカウントでログインできる設計でした。

方式を選ぶ際に検討したのは、人数が増えた場合の利用費用と、ログイン部分をいつ作るかです。当初の2アカウントだけでなく、ほかの施設にも導入する場合の人数を置いて考えました。

10月7日：2アカウントを想定して設計した

2026年10月7日の設計では、Cloudflare Access で管理画面を守ることにしました。Cloudflare Access は、決めた人だけがページを開けるようにする仕組みです。

当時は、無料プランが50人までという条件で考えていました。設計で参照した出典は、Cloudflare 公式ブログです。

想定した利用者とログイン方法は、次のとおりです。

• 利用を許可するのは、宿と私の2アカウント
• メールに届く番号を入れてログインする
• Google アカウントでのログインも付ける

Google アカウントでのログインについては、Cloudflare 公式ドキュメントを参照して設計しました。ここでは設計上の検討であり、Cloudflare Access を実際に使った結果ではありません。

同じ日：100施設まで広げた場合を試算した

同じ10月7日、ほかの施設にも導入する場合を考え、要件定義書に利用規模の見込みを加えました。

• 1施設の規模：客室300室まで
• 管理画面の利用者：1施設20アカウントまで
• 施設の数：100施設まで

1施設20アカウント×100施設で、合計は2,000アカウントです。実際の利用人数ではなく、将来の規模として置いた見込みです。

当初の2アカウントなら、当時前提にしていた50人の無料枠に収まります。一方、2,000アカウントまで広げる想定では、その枠を超えます。

同じ日のセッション記録では、有料で2,000アカウントを使う場合の費用も試算しました。その際は、人数に応じて利用費用が増える方式は、今回想定した規模には合わないと判断しました。

これは当時の人数と費用の試算に基づく判断です。Cloudflare Access が2,000アカウントを扱えないと確認したものではありません。

10月8日：最初から Google ログインを組み込む案を選んだ

10月7日の費用の試算後、次の2案を検討しました。

A案は、当初の2アカウントなら無料枠で始められます。ただし、この案では人数が増える前にログイン部分を変更する作業が残ります。

B案は、最初に作る手間が増える代わりに、当初から変更後の方式で作ります。1日ほどという数字は、10月7日に示された見積もりで、実際に増えた作業時間ではありません。

この初期の手間と後からの変更を検討し、10月8日にB案を選びました。

10月11日：Google ログインを用意した

10月11日、Google Cloud にプロジェクト untronc-yoyaku と OAuth クライアント（自分のサービスで Google ログインを使うための登録）を作りました。作成は私が行いました。

Google ログインに使うクライアントシークレット（秘密情報）は、Cloudflare Workers のシークレットの設定に置く設計です。

プログラムの実装は Claude Code が担当しました。同じ10月11日に、テスト環境の管理画面への Google ログイン成功を確認しました。

実装した内容と、自分で管理すること

コードで確認できたログイン処理は、次の内容です。これは実装内容の確認であり、各動作を実際の Google アカウントで確認した結果とは区別しています。

• Google から受け取ったメールアドレスを、施設の設定ファイルにある許可一覧と照らす
• 許可一覧にないアカウントは受け付けない
• ログイン状態を、署名付きの Cookie（ブラウザに保存する記録）で12時間保持する
• 管理画面へのアクセス時にも許可を確認し、一覧から外れたアカウントは受け付けない
• 最初のログインで Google アカウントの名前を取り込む

今回の管理画面は Google ログインだけを使う作りです。当初の設計にあった、メールに届く番号で入る方法は用意していません。利用する人には Google アカウントが必要です。

利用できるアカウントの追加・取り消しは、施設の設定ファイルにメールアドレスを追加・削除して、変更を反映する設計です。

Google による本人確認を使っても、管理画面の利用許可は自分で管理します。ログイン処理も予約システムの中に持つ方式を選びました。

10月14日：画面の表示を確認して撮影した

10月14日、記事に載せる画面を撮りました。画像01・03は、予約システムの同じプログラムをローカル環境（自分のパソコンだけで動かす環境）で動かした画面です。

画像01は、ログアウト用のページを Cookie（ブラウザに保存する記録）なしで開いて撮りました。ログインしてからログアウトする一連の操作を撮ったものではありません。

テスト環境の /admin を Cookie（ブラウザに保存する記録）なしで開くと、ボタンの画面を挟まず、そのまま Google のログイン画面へ移りました。画像02は、そのときの画面です。

画像03は、Google を通さず、署名した Cookie（ブラウザに保存する記録）で開いた管理画面です。Google ログイン完了後の画面として撮ったものではありません。

画像04は、10月11日に作った登録の一覧を Google Cloud で開いて撮りました。

この日の撮影で確認できたのは、Google のログイン画面への移動と、各画面の表示です。Google の画面での入力や、ログインからログアウトまでの一連の操作は試していません。

自分の利用人数と、変更が必要になる時期を書き出す

管理画面のログインを検討している方は、次の4点を1枚に書き出してみてください。

今回選んだのは、将来の利用人数を見込み、ログイン部分を最初から組み込む案でした。自分の条件でも、利用人数が増えたときに必要な費用と作業を並べてみてください。

管理画面のログインについて相談したいときは、お問い合わせフォームからどうぞ。

最後まで読んでくださりありがとうございました！