ポートフォリオのアプリを作ったものの、採用担当者にも新規登録してもらうべきか、テストアカウントを渡すべきか、ゲストログインを用意するべきか迷っていませんか。ログイン後の機能を見せたい一方、誰でも編集や削除ができる状態にするのも気になります。
ポートフォリオにゲストログインが必須とは限りません。見てほしい機能を、登録の負担を抑えながら試せる方法を選び、デモ用データ・操作範囲・初期状態に戻す方法をそろえます。ログイン不要の公開画面、テストアカウント、ゲストログインは、作品の性質に合わせて組み合わせられます。
この記事では、作品を作り終えた人向けに、採用担当者が使うデモ環境の準備と公開前確認を整理します。特定の言語の実装コードや、履歴書に作品URLを載せる方法ではなく、そのリンク先で何を試せるようにするかを扱います。
デモの準備とあわせて、作品の目的・担当範囲・検証の説明や応募書類も整えたい人は、IT・Web就職の全体ガイドのポートフォリオと応募書類の章を確認できます。
ゲストログインが必要かは、見せたい機能から判断する
まず、作品の中で確認してほしい操作を書き出します。公開情報の検索やグラフ表示など、ログインなしで主要機能を使える作品なら、ゲストログインを追加しなくても確認してもらえる場合があります。
一方、投稿、保存、タスクの管理など、ログイン後の操作が中心なら、その機能へ入る方法を用意すると試す手順を短くできます。新規登録をしなければ何も見られない状態と、サンプルデータで主要機能を試せる状態では、案内する手順が異なります。
Qiitaには、ポートフォリオの確認時に新規登録を省けるよう、ゲストログインを実装した個人の事例があります。ただし、そうした実装例があることは、全作品に同じ機能が必要という意味ではありません。
- ログイン前に、作品の目的と主要な画面を確認できるか
- 見せたい操作は、閲覧だけか、登録・編集まで含むか
- 本人のメールアドレスなどを入力しなくても試せるか
- 応募先から、アカウントやデモの形式が指定されているか
企業から指定された課題なら、その提出条件を優先してください。「確認しやすいはず」と考えて、指定された認証や登録の要件を省略してよいわけではありません。
ログイン不要・テストアカウント・ゲストログインの比較
ここでは、テストアカウントを「デモ専用のID・パスワードなどで入る方法」、ゲストログインを「登録情報を入力せず、用意された操作からデモを始める方法」として整理します。名称だけでは、実際に与えられる権限は決まりません。
| 見せ方 | 合いやすい作品・目的 | 準備と確認 |
|---|---|---|
| ログイン不要の公開画面 | 検索・一覧・グラフなど、公開情報の閲覧や操作が中心。作品の概要を最初に見せたい場合 | 公開してよいデータを用意し、未ログインでも主要機能へ進めるか確認。会員向け機能は別に案内する |
| デモ用テストアカウント | 通常のログイン画面を通して確認してほしい場合。利用者と管理者など、役割を分けて示す場合 | 専用アカウントと必要な権限を用意。ログイン情報、利用範囲、変更・失効の扱いを確認する |
| ゲストログイン | 個人の登録情報を入力せず、ログイン後の主要機能を試してほしい場合 | 共用か利用者ごとに分けるかを決め、データ・操作範囲・終了や初期化の方法を用意する |
例えば、公開画面で作品の概要とサンプルを見せ、編集を試すときだけゲストで入る構成も考えられます。すべてを一つのログイン方式にそろえる必要はありません。
テストアカウントを渡す場合は、デモ専用のものを作り、自分の日常利用や外部サービスの認証情報を使い回さないでください。公開するID・パスワードで操作できる範囲を、デモに必要なものへ絞ります。
また、ゲストログインが共用アカウントへ入る仕組みなら、他の閲覧者と同じデータを操作することがあります。ボタンを用意するだけで、データの混在が解消するとは考えず、次の準備を進めましょう。
デモ用データを入れ、確認してほしい操作を短く案内する
ログインできても、空の一覧だけでは何を確認すればよいか分からないことがあります。検索、絞り込み、集計、状態の変更など、主要機能を試せるサンプルデータを用意してください。
デモには、架空の利用者・投稿・取引など、公開と操作を前提に作ったデータを使います。実際の顧客情報や、前職・学校などで扱った非公開データを、そのまま移さないようにしましょう。画像や添付ファイルも、デモで使えるものかを確認します。
サンプルの件数を増やすことより、見せたい動作に必要な条件をそろえることが大切です。例えば状態別の絞り込みを見せるなら、異なる状態のデータを入れます。検索を見せるなら、どんな語を入れると結果が出るかを案内できます。
- 最初に開く画面で、作品の目的とデモの入口を示す
- サンプルデータを使って、最初に試す操作を案内する
- 結果のどこを見れば機能を確認できるかを示す
- 編集などができる場合は、操作後の戻し方を案内する
最初から全機能の説明を並べるより、「サンプルを開く→条件を変える→結果を確認する」のように、一つの流れを用意すると試す場所が分かります。管理者だけの機能など、別の役割で確認してほしいものは、必要に応じて案内を分けてください。
操作可能な範囲を決める｜削除・メール送信・アカウント変更
デモで操作できることは、機能ごとに決めます。何でも禁止すると作品の特徴が伝わらない一方、データやアカウントを自由に変えられると、次の人が同じように試せなくなることがあります。
| 機能 | デモで決めること | 公開前に確かめること |
|---|---|---|
| 閲覧・検索 | 見せるサンプルと、公開しない情報の範囲 | 必要なデータが表示され、公開対象外の情報へアクセスできない |
| 登録・編集 | 自分の試用データだけか、共用データも変更できるか | 編集結果が想定の範囲に反映され、他のデモを壊さない |
| 削除 | 試用中に作ったデータだけを削除可能にするか、閲覧のみとするか | 必要なサンプルや他の利用者のデータを消せない。削除後も試せる |
| メール・通知 | 外部送信を止めるか、デモ専用の受け取り先・確認方法を使うか | 通常の宛先へ送られず、表示した説明と実際の処理が一致する |
| 認証情報・退会 | 共用アカウントのパスワード・メール変更や退会を制限するか | 一人の操作で、次の閲覧者がログインできなくならない |
| 初期化・管理機能 | 試用データのリセットと、運営者だけが行う処理を分ける | 一般のデモ利用者が全体の初期化や管理者の操作を実行できない |
画面のボタンを隠すことと、操作を制限することは別
OWASPの公式資料では、必要な権限だけを与え、リクエストごとに権限を確認することを勧めています。画面側のチェックだけに頼らず、サーバー側などでアクセスを制御することも示されています。
「削除ボタンを表示しない」「ゲストと表示する」だけで、削除や管理操作を防げるとは限りません。デモ用の権限で許可する操作と、許可しない操作を決め、処理側でもその範囲が守られるようにします。自分のアプリで、制限した操作が実行されないことまで確認してください。
メールは、実際に外部へ送るかどうかを分ける
メール機能を見せる場合は、入力した宛先へ本当に送るのか、内容だけを確認するのかを決めます。「送信しました」と表示しても外部送信しないデモなら、その制限が分かる案内を添えましょう。
実際に送らず内容を確認する仕組みの例として、Djangoの公式資料には、開発・テスト用のメールバックエンドや、テスト時に送信内容を保存する機能があります。ただし、これは開発・テスト向けの説明です。公開したデモで自動的にメール送信が止まるとは考えず、使っている環境の設定と実際の処理を確認してください。
外部サービスへの連携も同様に、デモで動かす範囲を決めます。見せる必要がなければ、その操作を利用不可にする方法もあります。動かす場合は、サービスの公式資料に沿ったテスト方法や専用環境を用意し、通常運用のデータや宛先へ影響しないことを確かめます。
初期状態に戻す方法を決め、次の人も試せるようにする
デモを繰り返し使ってもらうには、データが変更されたあとの状態も考えます。最初の閲覧者がデータを消したり、設定を変えたりすると、次の人が確認したい画面を開けないことがあります。
作品に合わせて、次のような方法を選べます。
- 閲覧中心にする：サンプルの変更を制限し、操作を見せる部分だけ別に用意する
- 利用者ごとに試用データを分ける：それぞれが自分の範囲で登録・編集し、自分のデータだけ戻せるようにする
- 共用データを復元する：保存した初期データなどから、運営者が決めたタイミングでデモを戻す
どの方法でも、何を戻し、何を残すかを決めます。投稿だけでなく、添付ファイル、設定、関連データなど、デモの動作に必要なものも確認してください。利用者ごとにデータを作る場合は、試用終了後や期限後の片付け方も用意します。
共用データを復元する方法では、誰かが試している途中に状態が変わる可能性があります。いつ初期化するかを案内し、更新や削除を広く試してほしい作品なら、利用者ごとに分ける方法も検討しましょう。
データを戻すことは、すでに送信したメールなどの外部への処理を取り消すことではありません。外部送信や連携の扱いは、初期化とは別に決めます。
リセットを行うときは、デモ専用の対象へ限定し、通常運用のデータを触らない構成にします。全体の初期化を誰でも押せるボタンとして公開するより、自分の試用範囲を戻す操作と、運営者だけの復元作業を分けてください。
公開前には、データを変更する、決めた方法で初期化する、再び主要機能を試す、という一連の動作を確認します。「戻す方法を書いた」だけでなく、戻したあとの画面が確認できることまで見ましょう。
新規登録が必要な機能も、確認方法と制限を案内する
ゲストで入れるようにしても、新規登録、メール確認、ログイン、パスワード再設定など、認証まわりの機能をすべて確認できるわけではありません。それらが作品の重要な部分なら、別の確認方法を示します。
例えば、デモ用の受け取り環境を使った確認、面接での画面共有、個人情報を含まない操作動画などが考えられます。動画や画面画像は補足として使えますが、応募先が動くアプリでの確認を求めている場合は、代わりになると決めつけないでください。
また、ゲストのために通常の認証手順を無条件に通るよう変えると、何を実装したのかが分かりにくくなります。通常利用の機能と、デモ用の入口・制限を分け、確認方法を説明します。
案内文には、デモの入口、見てほしい操作、できない操作、データの戻し方を載せます。次は、利用者ごとに試用データを分けたタスク管理アプリを想定した記入例です。自分の実装に合わせて置き換え、用意していない機能や確認方法は書かないでください。
このデモでは、サンプルのタスクを使って登録・編集・絞り込みを試せます。トップページの「ゲストとして試す」からお入りください。新規登録は不要です。
最初にサンプルを開き、状態による絞り込みをお試しください。その後、試用データへタスクを追加し、状態を変更できます。
デモではメールの外部送信と認証情報の変更はできません。通常の登録・メール確認の流れは、別途掲載した操作記録で紹介しています。
「試用データを戻す」で、ご自身のデモデータを初期状態へ戻せます。他の利用者のデータは変更しません。
共用アカウントを使う作品なら、「他の方の操作が反映される場合がある」など、実際の扱いに合わせた説明へ変えます。更新できない閲覧専用デモなら、そのことを入口で示してください。
公開前は、自分の普段のログイン状態を使わずに試す
開発者のアカウントで使えることだけでは、採用担当者が同じように試せるか分かりません。ログアウト状態や別のブラウザーセッションから、渡す予定のURLと案内文でデモを始めると、入口や権限の違いを確認できます。
- 作品URLを開き、目的とデモの入口が分かるかを確認する
- 案内した方法で入り、個人の登録情報なしで試せる範囲を確認する
- サンプルデータを使い、主要な操作と結果を確認する
- 制限した変更・削除・管理操作が、デモ用の権限では実行されないことを確認する
- メールや外部連携が、説明したデモの範囲で動くことを確認する
- データを戻し、もう一度同じ手順で主要機能を試す
- データを利用者ごとに分ける場合は、別のセッションからも入り、相互に影響しないか確認する
- 未確認の機能とデモの制限を、案内文やREADMEへ反映する
テストアカウントを使う場合は、案内した認証情報が有効かも確認します。公開中に認証情報やURLを変更したら、応募先へ渡した案内との食い違いがないかを見直してください。
企業の課題としてリポジトリとアプリのURLを提出する人は、デモ環境を整えたあと、READMEと提出する版の対応も確認しましょう。GitHub提出全体の確認事項は、次の記事で扱っています。
ゲストログインを追加するかどうかは、作品の主要機能を確認してもらえるかで判断します。入口を分かりやすくし、データと操作範囲、繰り返し試す方法をそろえることで、作品の特徴を実際の動作で案内できます。
参考資料
- Qiita：ポートフォリオのゲストログイン機能の実装方法 — 作者自身による2021年の実装事例。すべての作品への必須要件や、現在の汎用的な実装手順の根拠としては扱っていません。
- OWASP：Authorization Cheat Sheet — 必要な権限への限定、リクエストごとの確認、画面側だけに依存しないアクセス制御。
- Django公式資料：Sending email — 開発・テスト用のメールバックエンド。公開デモ向けの設定保証ではありません。
- Django公式資料：Testing tools／Email services — 実際にメールを送らず、テストで送信内容を確認する方法。
資料の確認日：2026年10月3日。実装方法は利用している技術の公式資料で確認し、企業の課題では提出条件を優先してください。
