JLPT Étude

2. 毎日のレッスン The daily lesson

試験日・週に勉強できる日数・1日の上限時間から、毎日の新しい語・漢字・文法の数を計算します。実際の勉強ペースが予定より遅いと、アプリが知らせて計画を合わせます。
From the exam date, the study days per week and a daily time limit, the app computes how many new words, kanji and grammar points to learn each day. If the real pace is slower than planned, it says so and adapts the plan.

復習 Review 忘れる前に復習（間隔反復）。正解するほど間隔が長くなります。 Spaced repetition: the better you know an item, the later it comes back.
新出 Learn 5つずつ（文法は2つずつ）カードで覚えて、すぐに確認問題。 New items in batches of 5 (2 for grammar), each checked right after its card.
小テスト Test JLPT形式の問題（漢字読み、文法形式、文の組み立て★）。半分は苦手な項目から。 JLPT-style questions (kanji reading, grammar, ★ sentence order), half picked from weak items.
やり直し Retry 間違えた問題はレッスンの最後にもう一度（最大3回）。 Missed questions come back at the end of the lesson (up to 3 times).

3. 本番運用 Running it in production

よく聞かれる質問に、できていることと、できていないことの両方で答えます。2026年10月11日に、下の手順はすべて一度実行して確認しました。
Common questions, answered with what is in place and what is not. Every procedure below was run at least once on October 11, 2026.

ポッドやワーカーは？ Pods or workers in production?

ありません。Static Web AppsとAzure Functionsはマネージドサービスで、スケールもAzureが行います。アクセスが少ないアプリには、コストもほぼ0円で、パッチを当てるサーバーもありません。無料プランの上限（月100GBの転送量）を超えたら、App Serviceやコンテナへの移行を検討します。
None. Static Web Apps and Azure Functions are managed services that scale on their own. For a low-traffic app this costs close to nothing and leaves no server to patch. Past the free plan limits (100 GB of bandwidth per month), I would move to App Service or containers.

デプロイとロールバックは？ Deployments and rollbacks?

mainにプッシュすると、62のテスト → デプロイ → 確認が自動で走ります。テストが1つでも失敗するとデプロイしません。確認では /api/health が今デプロイしたコミットを返すまで待ちます。プルリクエストごとにプレビュー用のURLが作られ、閉じると消えます。ロールバックは任意のコミットを再デプロイするだけで、実測2分3秒。最初の試行では短いコミットIDを受け付けない不具合が見つかり、その場で直しました。
A push to main runs 62 tests → deploy → verification. A single failing test blocks the deploy. Verification waits until /api/health returns the commit that was just deployed. Every pull request gets its own preview URL, removed when it is closed. A rollback redeploys any earlier commit: measured at 2 min 03 s. The first attempt failed because short commit IDs were not accepted; I fixed it on the spot.

障害時の予備環境は？ Fallback if it crashes?

一番の守りはオフラインファーストです。APIが止まっても、学習データはブラウザに残り、復旧後に自動で同期されます。サーバーのデータは保存のたびにバージョンが残り、削除しても30日間は戻せます。復元スクリプトで、上書きされたデータの復元も試しました。まだないもの：別リージョンの待機環境。いまの利用規模では必要ないと判断しています。
The main safety net is offline first: if the API is down, progress stays in the browser and syncs automatically once it is back. On the server, every save keeps a version and deletions can be undone for 30 days; I tested restoring an overwritten file with the restore script. Not in place: a standby environment in another region, not needed at this scale.

アーキテクチャは？ Architecture?

上の図のとおりです。アドレスは jlpt.simondepussay.com（CloudflareのDNSからAzureへのCNAME、証明書はAzureが自動更新）。APIは4つのルートだけ。同じアカウントを2台で使っても、ETagで競合を検出し、決めたルールでマージするので、データは失われません。
See the diagram above. The address is jlpt.simondepussay.com (a CNAME from Cloudflare DNS to Azure, with a certificate renewed automatically by Azure). The API has only four routes. When the same account is used on two devices, ETags detect the conflict and the data is merged with defined rules, so nothing is lost.

ビジネスルールは実際にいくつ実装・テストされている？ How many business rules are really implemented and tested?

38のビジネスルール、10のデータチェック、14のAPIテストで、合計62。全部で約1秒、CIでは約15秒で終わります。下の表を参照してください。
38 business rules, 10 data checks and 14 API tests: 62 in total. They run in about 1 second locally and about 15 seconds in CI. See the table below.

24時間の保守は？ 24/7 maintenance?

個人プロジェクトなので、人によるオンコールはありません。そのかわり、30分ごとの死活監視（失敗するとメール）、デプロイ後の自動確認、Application Insightsでのエラー記録、2分のロールバック、30日分のバックアップ、そしてオフラインで動くアプリで、止まっても学習が続くようにしています。対応までの時間は、メールを読むまでの時間です。
It is a personal project, so there is no human on call. Instead: a health check every 30 minutes (e-mail on failure), automatic verification after each deploy, API errors logged in Application Insights, a 2-minute rollback, 30 days of backups, and an app that keeps working offline. Response time is the time it takes me to read the e-mail.

4. テスト Tests

分類 Area	数 Count	例 Examples
間隔反復 Spaced repetition	9	intervals 1/2/4 days then × ease, ease never below 1.3, cap at 365 days, levels
計画 Planning	9	new items per day = remaining ÷ study days, final review weeks, time cap, double day
実際のペース Real pace	7	no measure before 14 days, warning when below plan, streak, measured lesson time
同期 Sync	3	merge keeps the most-reviewed item, days combined, newest settings win
レッスン Lesson	7	order of steps, batches of 5, retry max 3 times, free practice leaves the plan untouched
問題・言語 Exercises & language	3	4 distinct choices, never another valid reading, FR/EN everywhere except Japanese
データ Data	10	every word and kanji translated, every quiz sentence translated, 4 distinct options
API	14	401 without session, 412 on conflict, 428 without If-Match, users isolated, account deletion

テストしていないもの：画面の見た目とブラウザでの通しテスト（E2E）。これは手作業で確認しています。
Not covered: visual rendering and end-to-end browser tests, which I still check by hand.

5. 設計で考えたこと Design decisions

オフラインファースト — アカウントがなくても使え、ログインするとそれまでの進捗がアカウントにマージされます。 Offline first — usable without an account; signing in merges the progress made so far into the account.
パスワードを持たない — Googleのトークンの署名をAPIで検証し、自分のセッションを発行するだけ。 No passwords — the API verifies Google's ID token signature and issues its own session.
上書きしない保存 — ETagのない書き込みは拒否（428）。古いデータで新しいデータを消せません。 No blind overwrites — writes without an ETag are refused (428), so stale data can never replace newer data.
2言語 — 日本語はそのまま、それ以外はすべてフランス語か英語。4 637項目の意味を両方の言語で用意しました。 Two languages — Japanese stays as is, everything else is fully French or fully English, with meanings for all 4,637 items in both.
データの品質 — 元のリストにあった下のレベルとの重複161語を除き、ユーザーが「N1ではない」項目を外せるようにしました。 Data quality — 161 duplicates of lower levels removed from the source list, and users can flag items that are not N1.

1. 全体の構成 Architecture