1 連絡・概要

1.1 大学入学共通テスト「情報」

2025/01/19 (日) に大学入学共通テスト「情報」が実施されました。以下のリンク先に「問題」と「解答例」を配置しています。60分・100点満点・マークシート式の試験です。高校 (≠高専) の「情報Ⅰ（＝主に高校1年で開講される2単位の必修科目）」の範囲から出題されるものです。

2025年度・大学入学共通テスト「情報」 @ Google Classroom

1.2 課題3 (最終課題の案内)

ページの最後に説明があります。確認しておいてください。

1.3 ゲーム\(\times\)IT業界フォーラム

業界研究&インターンシップ 「ゲーム\(\times\)IT業界フォーラム」の案内です。詳細はこちらから確認してください。

2/13 (木) と 14 (金) の 10:40-18:00 にオンライン形式で実施されます (要・事前登録)。

（１）「業界」や「会社」「仕事」について話が聞ける！
ゲーム・IT業界を代表する企業や急成長している企業から会社のことや仕事の話を聞き、理解を深められます。

（２）このイベントでしか得られないインターンシップ情報をGETできる！
就業体験の場であるインターンシップを行う企業から「実施内容」「スケジュール」「選考方法」などについて直接情報を得られます。（対応は企業により異なります）

1.4 概要

第04回講義と第05回講義で作成した「ToDoアプリ」は、GitHub Pages に デプロイ (＝展開・配置) して、インターネット上で公開することができました。これは「ToDoアプリ」が フロントエンドプログラム (つまりウェブブラウザ上で実行される JavaScript プログラムのみ) から構成されるため可能な手段でした。

しかし、現在、Next.js フレームワークを使って開発している「ブログアプリ」は、サーバ側で動作する バックエンドプログラムを含んでおり、それを動かすためには「Node.js の実行環境」が必要となります。そのため、GitHub Pages (＝Node.js 実行環境を持たない静的ホスティング環境) を利用してデプロイや公開をすることは で・き・ま・せ・ん。

以上のようなことから、この「ブログアプリ」については「Vercel」というクラウドプラットフォームにデプロイし、ウェブに公開しています。Vercel は「Next.js」や「v0」の開発元である Vercel社 が提供する「クラウドホスティングプラットフォーム (＝ホスティングサービス)」になります。

クラウドホスティングプラットフォームとは、ウェブアプリを実行するためのサーバインフラストラクチャ (サーバ環境) を提供し、インターネット上で公開できるようにしてくれるサービスのことです。同様のサービスは様々ありますが、Vercelの特徴として

Next.js に最適化された実行環境が提供されていること
GitHubリポジトリと連携した自動デプロイ (CI/CD パイプライン) が比較的簡単に構築できること
クレジットカード登録不要のフリープランが存在すること

…などが挙げられます。

(プロンプト例)

ウェブアプリ開発の文脈で「CI/CD」とは何ですか。Next.js でウェブアプリ開発をしている学習者向けに「概念」を解説してください。

現在開発している「ブログアプリ」を Vercel にデプロイすれば、スマートフォンや PC から 24時間どこからでも利用できるようになります。つまり、本格的なウェブアプリとして公開することができるようになります。

この Vercel によるデプロイは、Vercel と GitHub リポジトリの連携設定 をすることで「自動化」することができます。具体的には、Vercel にアカウントを作成して連携を設定すると、以降は GitHubリポジトリへの Push を Vercel が自動検知し、最新コードの取得とビルドを実行して本番環境としてデプロイするという「自動デプロイフロー」が構築されます。

Vercel でアカウントを作成し、GitHub リポジトリとの連携を設定
GitHub リポジトリへの Push を Vercel が自動検知
最新のコードを Vercel が取得
Vercel の実行環境でビルド (npm run build) を実行
本番環境へ自動デプロイ

1.4.1 定着確認

ウェブアプリ開発の文脈で「CI/CD」とは何の略語か答えよ。
- 答え: 「CI」は Continuous Integration (継続的インテグレーション)、「CD」は Continuous Delivery (継続的デリバリー) または Deployment Continuous (継続デプロイメント) の略語。

2 デプロイ設定前の準備

準備として、次の3つを完了させておいてください。

2.1 キャッシュの制御

Vercel にアプリをデプロイすると、特に「APIに対する「GET」リクエスト」において、意図せぬキャッシュ処理が発生することがあります。例えば、「記事を新規投稿したのに一覧に表示 (反映) されない」といったことが発生します。これは、サーバサイドのキャッシュに起因する現象なので、ブラウザで F5 や Ctrl+F5 で再読込みをしても解消されません。

この問題を回避するために src/app/api/admin/posts や src/app/api/posts などの GETリクエスト を処理する route.ts に、以下のような1文を追加してください。カテゴリ関連のGETリクエストを受付けるAPIについても、同様に追加してください。

これにより、バックエンドにおけるキャッシュが無効化できます。

import prisma from "@/lib/prisma";
import { NextResponse, NextRequest } from "next/server";

export const revalidate = 0; // ◀ サーバサイドのキャッシュを無効化する設定

export const GET = async (req: NextRequest) => {
// 以下省略

(プロンプト例)

Next.js の Route Handlers において、export const revalidate=0; は、どのような意味を持ちますか？

2.2 ビルド

次のコマンドを使って本番環境用（プロダクション環境用）にアプリをビルドして「エラーが発生しないこと」を確認してください。また「警告 (ワーニング)」についても、可能な限り潰しておいてください。

npm run build

自分のPCのローカル環境でビルドに失敗している状況では、Vercel でのビルドもほぼ確実に失敗します (ここから先の解説に従って作業しても失敗します)。

2.3 Push

プロジェクトを GitHubリポジトリ (main ブランチ) に発行しておいてください。

3 Vercel の利用登録と設定

Vercel を利用するためには、はじめに 登録 (サインアップ) が必要となります。登録には「GitHubアカウント」と「携帯電話 (SMS による認証に使用)」が必要になります。クレジットカードなどは不要です。

3.1 サインアップ

Vercel のトップページ(https://vercel.com/)にアクセスして「Sign Up」ボタンを押下してください。ウェブブラウザのウィンドウ幅が狭い場合はボタンが隠れているので注意してください。

「I’m working on personal projects (Hobby)」を選択してください。

「Your Name」のテキストボックスに名前を入力して「Continue」ボタンを押下して選択してください。ここで設定した「名前」はプレビューモードでデプロイしたときに URLに含まれる文字列になります。プロダクションモードでデプロイした場合のURL (本番環境用のURL) には含まれません。

GitHub連携でログイン (ソーシャルログイン) をしたいので「Continue with GitHub」を選択してください。

GitHub にログインするための認証情報を入力してください。状況に応じて2段階認証や2要素認証が要求されることがあります。

内容を確認して「Authorize Vercel」ボタンを押下してください。

つづいて、Vercel 側で SMS (携帯電話) を使った本人認証 が必要になります。手持ちの携帯電話の番号を入力してください。例えば、自分の携帯番号が「090-XXXX-YYYY」のときは「+81 90 XXXX YYYY」のように入力してください (+81 を付けるときは、先頭の 0 は不要になります)。

携帯電話に SMS で「認証コード」が届くので、それを入力して「Verify」ボタンを押下してください。

利用目的等のアンケート画面が表示されるので適当に入力して「Continue」ボタンを押下してください。

以上で Vercel のサインアップが「完了」しました🎉

つづいて、ブログアプリの「GitHubリポジトリ」と「Vercel」の連携を設定して、CD (＝継続デプロイメント) を構築していきます。

3.2 GitHubリポジトリとの連携とデプロイ

現在、ウェブブラウザは、次のような画面に移動しているはずです。ここからは「Vercel にデプロイする GitHub リポジトリ」を設定していきます。画面内「Import Git Repository」のなかの ❶ をクリックして「＋Add GitHub Account」を選択してください。

Vercel にデプロイしたい「GiuHubリポジトリ」を選択していきます。

いまは、任意のリポジトリだけをデプロイしたいので「Only select repositories」を選んで、❷ で ブログアプリのリポジトリ (next-blog-app) を選択してください。そして「Install」ボタンを押下してください。

先ほどの画面に戻ってくるので、上記で選択したブログアプリのリポジトリの右隣の「Import」ボタンを押下してください。

「Project Name」と「Framework」を確認して「Deploy」ボタンを選択してください。なお「Framework」としては「Next.js」のほかに、「Vue.js」「Angular」「Vite」のような 様々なJavaScriptフレームワーク が利用可能です (例えば、先に作成した「ToDoアプリ」も Vecel にデプロイ可能です)。

「Deploy」ボタンを押下すると、実際に GitHubリポジトリからデータ (プログラムのソースコード) が取得され、Vercel のサーバ環境のなかで「ビルド処理」と「デプロイ処理」が実行されます。これらの処理には数十秒から十数分かかります。

しばらくすると、次のようにビルド処理で「失敗」することが確認できます。これは、Vercel が提供するビルド環境を想定した設定ができていないためです。一旦、「Go to Project」ボタンを押下して「プロジェクト画面」に戻ってください (あとで戻ってくるのでプロジェクト画面は閉じないでおいてください)。

ウェブブラウザで、別タブを立ち上げて「ブログアプリの GitHubリポジトリ」を確認してください。

こちらでも、デプロイ (Deployments) に「失敗」していることが確認できます。なお、Vercel のデフォルト設定では main ブランチが 本番環境 (プロダクションモードでビルドとデプロイをする対象) として取り扱われます。

3.3 ビルドスクリプトの編集

VSCode に戻って作業します。

プロジェクトフォルダの直下の package.json を開いて、以下に示す 第08行目 のように "vercel-build" というカスタムスクリプトを追加してください。

{
  "name": "next-blog-app",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "vercel-build": "prisma generate && next build",
    "start": "next start",
    "lint": "next lint"
  },
// 以下、省略
}

以上のように package.json の scripts セクションに "vercel-build" というカスタムスクリプトを定義しておくと、Vercelでは "build" スクリプトに代わって "vercel-build" がビルド処理に使われるようになります。

"vercel-build" の prisma generate && next build というコマンドは、以下の2つのコマンドを順番に実行することを意味します。

prisma generate : Prisma クライアントを生成します。これにより、データベーススキーマの型定義が TypeScript で利用可能になります。このコマンドの詳細は第08回講義を参照してください。
next build : Next.js アプリの本番用ビルド (プロダクションモードのビルド) を実行します。

複数のコマンドを && で連結することで最初のコマンドが成功した場合にのみ、次のコマンドが実行されるように処理されます。つまり、prisma generate が失敗すると next build は実行されず、ビルド全体が「失敗」として扱われます。

prisma generateの実行が必要な理由

prisma generate を実行すると、デフォルトでは node_modules/.prisma/client に PrismaClient が生成されます。しかし、.gitignore の設定によって node_modules 配下については GitHub に Push されません。

その結果、Vercel などのデプロイ環境ではビルド時に Prisma Client が存在しない状態となります。このため、ビルド処理として prisma generate を実行し、PrismaClient を生成する必要があります。

package.json を編集したら、再度、プロジェクトを GitHub に Push してください。

3.4 環境変数の設定

再び、ウェブブラウザで Vercel の「next-blog-app」のページ (プロジェクトのトップページ) に戻ってください。タイミングによりますが、以下のように GitHubへの Push を検知して、再度、ビルド処理が実行されています。

しばらくすると、次のようにビルド処理に「失敗した」という表示に切り替わります。クリックして詳細を確認してください。

ログを確認するとビルド処理の失敗原因は「Supabaseの接続情報が取得できないこと」だと分かります (少しずつ、ログを読み解けるようになってくださいね)。

Supabase の接続情報 は prisma/schema.prisma や src/utils/supabase.ts において、以下のように env() や process.env を使用して「.env」で設定した環境変数から取得するように実装していました。これは、接続情報をソースコードに直接記述すると GitHub に Push した際に情報が流出してしまうのを防ぐための措置でした。

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_URL")
}

import { createClient } from "@supabase/supabase-js";

export const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);

環境変数を設定した .env は、.gitignore の設定により、GitHub に Push されないようになっています。この結果、Vercel のビルド環境 (デプロイ環境) で「環境変数」が参照できず、上記のように処理に失敗しました。

以上のことからビルド環境 (デプロイ環境) で環境変数が参照できれば問題解決となります。Vercelの環境変数は、プロジェクトの設定画面から設定することができます。

以下のように「Settings」から「Environment Variables」を選択してください。

次のように .env で設定していた環境変数を設定してください。なお、この際、いずれの設定値もダブルクォーテーションで囲まないように注意してください。また、設定値の前後にスペースなどを含まないように注意 してください。その他にも、独自の環境変数を追加している場合は、それも同様に設定してください。

以上で、環境変数の設定が完了しました。

3.5 再デプロイ処理

環境変数が設定できたので、再度、デプロイ処理を実行してみます。以下のように「Deployments」から、最新のコミット (package.jsonを更新したコミット) の三点リーダをクリックして、「Redeploy (再デプロイ)」を選択してください。

次のような確認画面が表示されるので「Redeploy」を選択してください。

デプロイ処理 (ビルド処理を含む) が再度実行されます。ここまでの設定に問題がなければ、しらばく待った後、次のような画面 (Statusが「Ready」の状態)になれば成功です🎉

❷の「URL」をクリックすると、Vercelにデプロイされ、全世界に公開された「ブログアプリ」にアクセスすることができます (「Visit」のボタンでもOKです)。スマートフォンからもアクセスすることができます。

3.6 公開URL (ドメインネーム) の変更

現在、ウェブアプリの公開アドレスは https://next-blog-app-*****.vercel.app/ のようになっていると思います。これは、次の手順で任意のものに変更することができます。ただし、既に誰かが使用している場合や、使用中ではないものの最近まで使用されていたドメインを使うことはできません (例えば https://next-blog-app.vercel.app/ は使用できません)。

以下のように「Settings」から「Domains」を選択して、「Edit」ボタンを押下してください。

次のように任意のドメインネームを設定して、「Save」ボタンを押下してください。

3.7 CD (Continuous Delivery)

ここまでの設定により、CD (Continuous Delivery: 継続的デリバリ) が構築できました。以降は、GitHub の main ブランチに対する Push がトリガーとなって、自動的に Vercel でビルドとデプロイが実行されます。

実際に Push してから、デプロイ完了までは数分から数十分ほどかかります。ビルドやデプロイの状況は、Vecelのウェブサイトからプロジェクトを選択して確認することができます。

3.8 リージョン設定

リージョンの変更は、再デプロイを実行すると反映されます。

4 GitHub Actions による定期処理

前々回の講義で解説したように Supabase で作成したプロジェクトは約7日間放置すると (Supabase のウェブサイトからプロジェクトの DB を参照したり、アプリからウェブAPIにアクセスしないと)、停止状態 (Paused) になってしまいます。

開発中は (デバッグのために頻繁にウェブAPIにアクセスするため) 停止状態になることは稀です。しかし、開発が一段落すると、気付いたときには停止状態になっていることがよくあります (＝就活のポートフォリオとしては致命的です)。この「ブログアプリ」については、1日1回、トップページにアクセスすれば GET /api/posts リクエストが発生して、内部で prisma.post.findMany() が実行されるため、Supabase が停止状態になることを回避できます。

この定期的なアクセス処理はGitHub Actionsを使って自動化することができます。GitHub Actions は CI/CD のための機能で時間指定による処理の定期実行が可能です (その他、GitHub Actions には様々な機能があります)。

ここでは1日1回、日本時間の10時15分 (＝UTC: Coordinated Universal Time (協定世界時) の 01時15分) に https://hoge.vercel.app/ にGETリクエストを送信するような処理を GitHub Actions で構築してみたいと思います。

4.1 ワークフローの設定ファイルの作成

VSCode で作業します。プロジェクトフォルダの直下に .github というフォルダを作成し、そのなかに workflows というフォルダを作成し、そのなかに daily-ping.yaml というファイルを新規作成してください。

ここで .github と workflows というのは GitHub Actions で指定された 特別な名前 なのでスペルミスに注意してください。

作成した daily-ping.yaml に、以下の内容を貼り付けてください。第06行目 は「定期実行時刻」を設定します。UTC で設定することに注意してください。指定の書式は Linux のcronと同じです。また、第18行目 の URL は各自のデプロイ先にあわせて変更してください。

name: Prevent Supabase Sleep (Daily Ping)

on:
  schedule:
    # UTC 01:15 AM に実行 (JST 10:15 AM)
    - cron: "15 1 * * *"
  workflow_dispatch:

jobs:
  make_request:
    runs-on: ubuntu-latest
    env:
      TZ: "Asia/Tokyo"

    steps:
      - name: Send HTTP GET request
        run: |
          curl -X GET "https://next-blog-app-demo.vercel.app/" -v --fail || exit 1

      - name: Log request time
        run: |
          echo "Keep-alive ping completed at $(date)"

ファイルの編集と保存が完了したら、コミットして GitHub に Push してください。

4.2 動作確認のための手動実行

ワークフローの設定が適切にできたかを確認していきます。

ウェブブラウザから GitHub リポジトリにアクセスして「Actions」のタブに移動してください。さらに、Prevent Supabase Sleep (Daily Ping) (＝ daily-ping.yaml の 第01行目で設定した名前が表示されています) を選択してください。

このワークフローは、スケジュール実行を想定したものですが daily-ping.yaml の 第07行目 で workflow_dispatch: を記述しているのでユーザ操作による手動実行も可能になっています。

手動実行するために「❸ Run workflow」から「❹ Run workflow」を押下してください。❹ を押下すると、GitHub の裏側で daily-ping.yaml の 第11行目 で指定した環境 (最新版 Ubuntu Linux) の仮想マシンが起動し、第18行目 と 第22行目 のコマンドが実行されます。※ 仮想マシンが起動するまでに十数秒かかることがあります、反応がないからといって「Run workflow」ボタンを連打しないようにしてください。

ワークフローの実行中は以下のような表示になります。

正常完了すると、次のような「緑のチェックマーク」になります。

後日、同画面を再確認して、以下のように Scheduled で「緑チェックマーク」がついていれば、スケジュール実行が正常に動作していると言えます。なお、スケジュール実行の時刻には5分程度の誤差が生じることもあるので注意してください。

GitHub Actions のスケジュールワークフローは、当該リポジトリに 60日間、何も Push しないと無効化 (停止) するので注意してください。

5 PWA機能の設定

Next.js 14 には、基本的な PWA機能 がデフォルトで組み込まれています。PWA とは Progressive Web App の略語で、「ウェブアプリ」を「ネイティブアプリ」のように利用 (インストールや起動) できる技術 になります。なお、基本的な機能に加えてオフライン環境での実行といった高度なPWA機能を使用したい場合は next-pwa というパッケージのインストールが必要になります。

ここでは、Next.js にデフォルトで組み込まれている基本的なPWAの利用方法について解説します。

PWAを有効化するためには、プロジェクトフォルダの所定の位置に設定ファイル (manifest.json) と画像ファイル (アイコン用) を配置します。PWAが有効化されると、ユーザはウェブアプリを「ネイティブアプリ」のようにデバイスにインストール＆起動できるようになります。

ユーザが、ウェブアプリを PWA としてインストールする方法はOSやブラウザにより異なります。

例えば、PC版の Chrome では、アドレスバー右側に表示されるアイコンを押下して、インストールすることができます。インストールすると、デスクトップにアイコンが作成されます。

Android版の Chrome では、ブラウザ右上の3点メニューから「ホーム画面に追加」を選択してインストールすることができます。

iOS の Safari では、次のようにインストールすることができます。

以下に、PWAを有効化するための具体的な手順を示します。

5.1 manifest.json の作成と配置

プロジェクトフォルダの src/app の直下に manifest.json を新規作成してください。

📂 src/
└─ 📂 app/
    └─ manifest.json

ファイルには以下の内容を貼付けてください。設定 (name や ***_color など) は、各自のアプリにあわせて変更してください。項目の詳細についてはNext.js14でPWA構築してみたやWeb Application Manifest (日本語訳)を参照してください。

{
  "name": "Next-Blog-App",
  "short_name": "BlogApp",
  "description": "",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#fff",
  "theme_color": "#fff",
  "icons": [
    { "src": "/android-chrome-192x192.png", "type": "image/png", "sizes": "192x192" },
    { "src": "/android-chrome-512x512.png", "type": "image/png", "sizes": "512x512" }
  ]
}

5.2 アイコン用の画像の配置

各種OSに対応させるために、次の4つのアイコン用の「画像」を用意します。

favicon.ico (このファイル名にすること)
apple-icon.png (180x180px。このファイル名にすること)
android-chrome-192x192.png (manifest.json で指定した名前にすること)
android-chrome-512x512.png ( 〃 )

これらのファイルは、https://favicon.io/ を利用して一括作成することができます。サイトにアクセスして「Favicon Generators」の「PNG→ICO」を選択して、縦横比 1:1 の画像 (512x512のPNGを推奨) をドラッグアンドドロップして、「Download」のボタンを押下してください。

favicon_io.zip というファイルがダウンロードされるので、それを解凍してください。次のようなファイルが得られます。

apple-touch-icon.png は apple-icon.png にリネームしてください。

そして、以下のようにプロジェクトフォルダに配置してください。favicon-16x16.png、favicon-32x32.png、site.webmanifest については使用しません。

📂 public/
│   ├─ android-chrome-192x192.png
│   └─ android-chrome-512x512.png
📂 src/
└─ 📂 app/
    ├─ favicon.ico
    ├─ apple-icon.png
    └─ manifest.json

あとは、Vercel にデプロイ (GitHubリポジトリにPush) すれば完了です。

なお、開発モード (npm run dev) で起動したときや、ウェブブラウザのシークレットモードやゲストモードを使用しているときには、PWA としてインストールできないので注意してください。

5.3 アイコンの入手

アイコンは自作するか、生成AIやFLATICONなどを利用して入手してください。

6 最終課題 (課題3)

最終課題 (課題3) として、Next.js をフレームワークとした「オリジナルのウェブアプリ」を開発してください。また、Vercel に デプロイ/公開 してください。オリジナルアプリは完全な新規開発でも、ここまで開発してきたブログアプリをベースに独自機能やカスタマイズをくわえたものでも結構です。後者の場合は、現在のブログアプリのリポジトリをそのまま使用する形でもOKです。

この「課題」は、ソフトウェア系 (特にウェブ系) のインターンシップや就職の「選考」で、非常に強力な武器 (自己PRの素材、技術や意欲を証明するもの) になります。書類選考 でも 面接選考 でも使える素材になります。将来を切り開くための準備・投資としても頑張ってみてください。

具体的には以下の内容に取り組んでください。

GitHub をリモートリポジトリに設定して「オリジナルウェブアプリ」を開発する。
オリジナルウェブアプリをVercelにデプロイ・公開する。
Supabase が停止モードにならないように GitHub Actions を利用して定期的に Ping を飛ばす処理を設定する (ログから正常動作することも確認する)。
2年次に作成した作品置き場としての ポートフォリオ (GitHubPagse) のなかに、開発したウェブアプリの「タイトル」「概要（スクリーンショット2枚以上）」「リポジトリ (URL)」「公開URL」を掲載する。
- 注意 : 学校の授業の課題として開発した (単位取得のために開発した) というニュアンスを持った記述は、就活用のポートフォリオとしてはマイナス印象です。

評価 : GitHubリポジトリの README の内容を「5点満点」、アプリ本体やソースコードを「5点満点」で、「合計10点満点」で評価します。「7.6点」を標準とします。
- ゼロベースの新規開発に取り組んだ場合は、上記の合計に加点します (10点が上限)。
- 「Vercel にデプロイ・公開されていない」「提出上の不備がある (提出遅れやURLの記述ミスを含む)」「作品集としてのポートフォリオに記載がない」などは、上記の合計から減点します (0点が下限)。
提出先 : Microsoft Forms
- OMUIDによるログインが必要、期間内は再編集可、期限後は回答不可
提出期限 : 2025年02月19日 (水) 13時 (時刻に注意)
- 実際の内容評価 (採点) は、早ければ 02月22日 (土) から開始予定です。
提出された課題は、教員と知能情報コースの学生に公開します。

6.1 注意事項

開発したウェブアプリは、少なくとも 2025年3月31日 までは稼働している状態にしてください。
Supabase は7日間アクセスがないと「停止モード」になります。課題評価時に「停止モード」になっていると、適切に評価できません。停止モードにならないるように GitHub Action で Ping を飛ばすようにしてください。
アプリのなかで ログイン (認証) が必要なページや機能 について、実際に動作を見て欲しいものがあれば TeamsChat で認証情報を送ってください。
- ゲストログイン機能 (IDやパスワードを入力しなくとも、押下するだけでログインできる機能) を実装することもありです。

6.2 READMEの構成.mdについて

次のような内容を記載すること推奨します (あくまでも「例」です)。

基本的には情報量が多いほど「高評価」です。

# アプリの名前

- 概要。どのような利用者を想定した、どのようなアプリなのかを記述する。
- 開発の背景・経緯
  - 特に完全オリジナルのアプリ開発の場合は、記載しないともったいない。
  - 課題発見能力、課題解決能力、人となりなどを見てもらえます。
- 公開URL

## 特徴と機能の説明

- スクリーンショットや動画 (アニメ) を添えながら基本機能や工夫点を解説する。
- 最低でも3個ぐらいは、特徴を箇条書きしましょう。
- この項目の情報量が評価に大きく関係します。
    - 特に認証をログインを必要とする画面や機能は、ここで記述しないと評価者に伝わらない。

## 使用技術 (技術スタック)

- 使用した言語やフレームワーク
    - 少なくとも TypeScript と Next.js、Prisma は書いておくべき。
    - その他、アプリを構成する主要なライブラリなどを記載する。
    - ReReact Hook Form や zod、SWR を使っている場合は明示する。
- 開発に使用したツールやウェブサービス
    - VSCode、Supabase、Vercel は書いておくべき。
- システム構成図

## 開発期間・体制

- 開発体制: 個人開発
- 開発期間: 2024.12 ~ 2025.2 (約XXX時間)

## 工夫した点・苦労した点

- 特に、技術的な目標や挑戦を持って取り組んだ場合は記載すると良いです。

## 既知の課題と今後の展望

- 改良・改善したいこと。
- 機能拡張のロードマップなど。

## 連絡先 (任意)

- 作品集としてのポートフォリオのURL
- SNSアカウント
- 所属など

システム構成図の例
- 例1
- 例2
- 例3

README については、生成AIにチェックしてもらうことをお勧めします。

以下の私のポートフォリオサイトの README.md を、新卒採用向けに添削してください：

目的：
- 技術力と学習意欲が伝わる内容にしたい
- 採用担当者が読みやすい文章にしたい
- 自分の特徴や強みが伝わるようにしたい

依頼事項：
1. 採用担当者目線で不足している情報はありますか？
2. より分かりやすい表現や構成はありますか？
3. 技術スタックの書き方は適切ですか？
4. コードの品質や開発プロセスをより効果的にアピールするには？

添削の際は以下の点も意識して修正をお願いします：
- 文章の簡潔さと分かりやすさ
- 技術的な深さと学習姿勢の表現
- 実装の工夫点や課題解決プロセスの見せ方

現在のREADME：

```
現在のREADMEの内容をここに貼り付け
```