1 連絡・概要
1.1 大学入学共通テスト「情報」
- 2026/01/18 (日) に大学入学共通テスト「情報」が実施されました。Teams
に「問題」と「解答例」を配置しています。60分・100点満点・マークシート式の試験です。
- 高校 (≠高専) の情報I(=主に高校1年で開講される2単位の必修科目) の範囲から出題されるものです。
- 腕試しにトライしてみてください。
1.2 課題3 (最終課題の案内)
- ページの最後 に説明があります。確認しておいてください。
1.3 概要
第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.3.1 定着確認
- ウェブアプリ開発の文脈で「CI/CD」とは何の略語か答えよ。
- 答え: 「CI」は Continuous Integration (継続的インテグレーション)、「CD」は Continuous Delivery (継続的デリバリー) または Deployment Continuous (継続デプロイメント) の略語。
2 準備 1
今回の講義に先立ち、まずは次のコマンドを実行して、現時点でプロジェクトが正しくビルドできるか を確認してください。
npm run build
この際、以下のように ./src/generated/**
のファイルに関してエラーや警告が発生するときは、後述のように eslint.config.mjs
の書き換えをしてください。
Failed to compile.
./src/generated/prisma/client.js 5:23 Error: A require() style import is forbidden. @typescript-eslint/no-require-imports
~ 以下、大量のエラーや警告 ~
上記は、npx prisma generate によって自動生成された JavaScript
ファイル(./src/generated/**)に対して ESLint
のルールが適用されたことによる「警告」や「エラー」となります。これらの自動生成ファイルは
開発者が直接編集したり、保守したするファイルではない ため、ESLint
でコーディングスタイル違反や規約をチェックすることに実質的な意味はありません。
(プロンプト例)
Next.js + Prisma (v7) でウェブアプリ開発をしています。
プロジェクトをビルドしたところ、./src/generated/**にあるファイルが ESLint でエラーとなりました。先生によれば、それらのファイルはnpx prisma generateで自動生成されたものなので、ESLint でチェックする必要性はない (それらのファイルは ESLint 適用除外に設定してよい) 、と言われました。なぜ、これらのファイルを ESLint の適用外にしてよいのですか。
そのため、これらのファイルを Lint
の対象から除外します。次に示す手順に従って、プロジェクトルートにある
eslint.config.mjs を、以下のように書き換えてください。
import { dirname } from "path";
import { fileURLToPath } from "url";
import { FlatCompat } from "@eslint/eslintrc";
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
const compat = new FlatCompat({
baseDirectory: __dirname,
});
const eslintConfig = [
...compat.extends("next/core-web-vitals", "next/typescript"),
{
settings: {
tailwindcss: {
callees: ["cn", "twMerge", "tv"],
},
},
rules: {
"@typescript-eslint/no-unused-vars": "off",
},
ignores: [
"node_modules/**",
".next/**",
"out/**",
"build/**",
"next-env.d.ts",
],
},
];
export default eslintConfig;import { dirname } from "path";
import { fileURLToPath } from "url";
import { FlatCompat } from "@eslint/eslintrc";
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
const compat = new FlatCompat({
baseDirectory: __dirname,
});
const eslintConfig = [
{
ignores: [
"**/node_modules/**",
"**/.next/**",
"**/out/**",
"**/build/**",
"**/next-env.d.ts",
"**/src/generated/**", // Ignore generated Prisma client
],
},
...compat.extends("next/core-web-vitals", "next/typescript"),
{
settings: {
tailwindcss: {
callees: ["cn", "twMerge", "tv"],
},
},
rules: {
"@typescript-eslint/no-unused-vars": "off",
}
},
];
export default eslintConfig;ignores に "**/src/generated/**" を追加するとともに、ESLint
の除外設定を確実に適用するために、ignores の配置も変更しています。
自分のPCのローカル環境でビルドに失敗している状況では、Vercel でのビルドもほぼ確実に失敗します (ここから先の解説に従って作業しても失敗します)。
3 準備 2 (キャッシュ制御とリポジトリへのプッシュ)
準備として、次の2つを完了させておいてください。
3.1 キャッシュの制御
Vercel
にアプリをデプロイすると、特に「APIに対する「GET」リクエスト」において、意図せぬ
キャッシュ処理 が発生することがあります。例えば、「記事を新規投稿したのに一覧に表示 (反映) されない」
といったことが発生します。これは、サーバサイドのキャッシュに起因する現象なので、ブラウザで
F5 や Ctrl+F5 で再読込みをしても解消されません。
この問題を回避するために src/app/api/admin/posts や
src/app/api/posts などの GETリクエスト を処理する
route.ts に、以下のような2文 (第05行目 と
第06行目)
を追加してください。カテゴリ関連のGETリクエストを受付けるAPIについても、同様に追加してください。
これにより、<.>バックエンドにおけるキャッシュが無効化 できます。
import { prisma } from "@/lib/prisma";
import { NextResponse, NextRequest } from "next/server";
import { Post } from "@/generated/prisma/client";
export const revalidate = 0; // ◀ サーバサイドのキャッシュを無効化する設定
export const dynamic = "force-dynamic"; // ◀ 〃
export const GET = async (req: NextRequest) => {
// 以下省略(プロンプト例)
Next.js 15 の Route Handlers において、
export const revalidate=0;は、どのような意味を持ちますか?
Next.js 15 の Route Handlers において、
export const dynamic = "force-dynamic";は、どのような意味を持ちますか?
3.2 Push
プロジェクトを GitHubリポジトリ (main ブランチ) に発行しておいてください。
4 Vercel の利用登録と設定
Vercel を利用するためには、はじめに 登録 (サインアップ) が必要となります。登録には「GitHubアカウント」と「携帯電話 (SMS による認証に使用)」が必要になります。クレジットカードなどは不要です。
4.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」ボタンを押下してください。
状況にっては、以下の SMS (携帯電話) を使った本人認証 が要求されないこともあります。
つづいて、Vercel 側で SMS (携帯電話) を使った本人認証
が必要になります。手持ちの携帯電話の番号を入力してください。例えば、自分の携帯番号が「090-XXXX-YYYY」のときは「+81
90 XXXX YYYY」のように入力してください (+81 を付けるときは、先頭の
0 は不要になります)。
携帯電話に SMS で「認証コード」が届くので、それを入力して「Verify」ボタンを押下してください。
利用目的等のアンケート画面が表示されるので適当に入力して「Continue」ボタンを押下してください。
以上で Vercel のサインアップが「完了」しました🎉
つづいて、ブログアプリの「GitHubリポジトリ」と「Vercel」の連携を設定して、CD (=継続デプロイメント) を構築していきます。
4.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 ブランチが 本番環境
(プロダクションモードでビルドとデプロイをする対象) として取り扱われます。
上記の赤枠をクリックしていくことで「エラーの詳細」が確認できます。
さらに
さらに
ログを確認すると、ビルド処理の失敗原因は 「Supabaseの接続情報が取得できないこと」 であることが分かります (少しずつ、ログを読み解けるようになってくださいね)。
Supabase の接続情報 は src/lib/prisma.ts や
src/utils/supabase.ts において、以下のように process.env を使用して
「.env」で設定した環境変数
から取得するように実装していました。これは、接続情報をソースコードに直接記述すると GitHub に
Push した際に情報が流出してしまうのを防ぐための措置でした。
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」を選択してください。
次のように「Add Environment Variable」を押下してください。
さらに環境変数を .env
で設定していた環境変数を設定してください。最後に「Save」を押下してください。
なお、この際、いずれの設定値も ダブルクォーテーションで囲まない ように注意してください。また、設定値の前後にスペースなどを含まないように注意 してください。その他にも、独自の環境変数を追加している場合は、それも同様に設定してください。
以上で、環境変数の設定が完了しました。
4.3 再デプロイ処理
環境変数が設定できたので、再度、デプロイ処理を実行してみます。以下のように「Deployments」から、最新のコミット
(package.jsonを更新したコミット)
の三点リーダをクリックして、「Redeploy (再デプロイ)」を選択してください。
次のような確認画面が表示されるので「Redeploy」を選択してください。
デプロイ処理 (ビルド処理を含む) が再度実行されます。ここまでの設定に問題がなければ、しらばく待った後、次のような画面 (Statusが「Ready」の状態)になれば成功です🎉
❷の「URL」をクリックすると、Vercelにデプロイされ、全世界に公開された「ブログアプリ」にアクセスすることができます (「Visit」のボタンでもOKです)。スマートフォンからもアクセスすることができます。
4.4 公開URL (ドメインネーム) の変更
現在、ウェブアプリの公開アドレスは https://next-blog-app-*****.vercel.app/
のようになっていると思います。これは、次の手順で任意のものに変更することができます。ただし、既に誰かが使用している場合や、使用中ではないものの最近まで使用されていたドメインを使うことはできません
(例えば https://next-blog-app.vercel.app/ は使用できません)。
以下のように「Settings」から「Domains」を選択して、「Edit」ボタンを押下してください。
次のように任意のドメインネームを設定して、「Save」ボタンを押下してください。
「Remove old domain」を選択して、「Save」ボタンを押下してください。
これで https://next-blog-app-demo.vercel.app/
で自分のアプリにアクセスが可能になります🎉
4.5 CD (Continuous Delivery)
ここまでの設定により、CD (Continuous Delivery: 継続的デリバリ)
が構築できました。以降は、GitHub の main ブランチに対する Push
がトリガーとなって、自動的に Vercel でビルドとデプロイが実行されます。
実際に Push してから、デプロイ完了までは数分から数十分ほどかかります。ビルドやデプロイの状況は、Vecelのウェブサイトからプロジェクトを選択して確認することができます。
4.6 リージョン設定
リージョンを東京に変更します。これにより、国内からアクセスしたときの応答が早くなります。現在は「North America」のどこかに設定されているので、そのチェックを外してから、「Asia Pacific」の「Tokyo」にチェックをいれて「Save」を押下してください。
リージョンの変更は、再デプロイを実行すると反映されます。
5 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 で構築してみたいと思います。
5.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 してください。
5.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 しないと無効化 (停止) するので注意してください。
6 PWA機能の設定
Next.js 15 には、基本的な 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を有効化するための具体的な手順を示します。
6.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" }
]
}6.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
としてインストールできないので注意してください。
6.3 アイコンの入手
アイコンは自作するか、生成AIやFLATICONなどを利用して入手してください。
7 最終課題 (課題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点が下限)。
- 提出先 : Teamsの「PG3-課題3」にリポジトリのURLを提出
- 🚨提出するURLは「アプリをホストしている Vercel の URL」ではなく、「GitHub リポジトリの URL」としてください。
README.mdの先頭付近に「アプリをホストしている Vercel の URL」 を記載してください。また「開発期間: 2026.01.xx ~ 2026.02.xx (約XXX時間)」のような内容も必ず記載してください (位置は任意)。README.mdには 最低でも5枚以上のスクリーンショット を添えてください。アニメーションや動画でも可。
- 提出期限 : 2026年02月18日 (水) 23時
- 実際の内容評価 (採点) は、早ければ 02月24日 (火) から開始予定です。
- 提出された課題 (URL) は、知能情報コースの学生 (知能情報コースを志望する1年生を含む)、本校教員に共有します。また、この課題は、インターンシップや就職の選考にポートフォリオとして使えるもの (=自分のスキルをや経験を証明するもの) になるので、力を入れて取り組んで欲しいと考えています。
7.1 注意事項
- 開発したウェブアプリは、少なくとも 2026年3月31日 までは稼働している状態にしてください。
- Supabase は7日間アクセスがないと「停止モード」になります。課題評価時に「停止モード」になっていると、適切に評価できません。停止モードにならないるように GitHub Action で Ping を飛ばすようにしてください。
- アプリのなかで ログイン (認証) が必要なページや機能
について、実際に動作を見て欲しいものがあれば TeamsChat で認証情報を送ってください。
- ゲストログイン機能 (IDやパスワードを入力しなくとも、押下するだけでログインできる機能) を実装することもありです。
7.2 READMEの構成.mdについて
次のような内容を記載すること推奨します (あくまでも「例」です)。
基本的には情報量が多いほど「高評価」です。
# アプリの名前
- 概要。どのような利用者を想定した、どのようなアプリなのかを記述する。
- 開発の背景・経緯
- 特に完全オリジナルのアプリ開発の場合は、記載しないともったいない。
- 課題発見能力、課題解決能力、人となりなどを見てもらえます。
- 公開URL
## 特徴と機能の説明
- スクリーンショットや動画 (アニメ) を添えながら基本機能や工夫点を解説する。
- 最低でも3個ぐらいは、特徴を箇条書きしましょう。
- この項目の情報量が評価に大きく関係します。
- 特に認証をログインを必要とする画面や機能は、ここで記述しないと評価者に伝わらない。
## 使用技術 (技術スタック)
- 使用した言語やフレームワーク
- 少なくとも TypeScript と Next.js、Prisma は書いておくべき。
- その他、アプリを構成する主要なライブラリなどを記載する。
- ReReact Hook Form や zod、SWR を使っている場合は明示する。
- 開発に使用したツールやウェブサービス
- VSCode、Supabase、Vercel は書いておくべき。
- システム構成図
## 開発期間・体制
- 開発体制: 個人開発
- 開発期間: 2026.01.xx ~ 2026.02.xx (約XXX時間)
## 工夫した点・苦労した点
- 特に、技術的な目標や挑戦を持って取り組んだ場合は記載すると良いです。
## 既知の課題と今後の展望
- 改良・改善したいこと。
- 機能拡張のロードマップなど。
## 連絡先 (任意)
- 作品集としてのポートフォリオのURL
- SNSアカウント
- 所属などREADME については、生成AIにチェックしてもらうことをお勧めします。
以下の私のポートフォリオサイトの README.md を、新卒採用向けに添削してください:
目的:
- 技術力と学習意欲が伝わる内容にしたい
- 採用担当者が読みやすい文章にしたい
- 自分の特徴や強みが伝わるようにしたい
依頼事項:
1. 採用担当者目線で不足している情報はありますか?
2. より分かりやすい表現や構成はありますか?
3. 技術スタックの書き方は適切ですか?
4. コードの品質や開発プロセスをより効果的にアピールするには?
添削の際は以下の点も意識して修正をお願いします:
- 文章の簡潔さと分かりやすさ
- 技術的な深さと学習姿勢の表現
- 実装の工夫点や課題解決プロセスの見せ方
現在のREADME:
```
現在のREADMEの内容をここに貼り付け
```