diff --git a/.claude/agents/coder.md b/.claude/agents/coder.md
new file mode 100644
index 0000000..5f9bfc6
--- /dev/null
+++ b/.claude/agents/coder.md
@@ -0,0 +1,72 @@
+---
+name: coder
+description: "機能実装・バグ修正に集中するエージェント．テストやリファクタリングは行わない．実装パイプライン（/implement）の Phase 1 で使用される．"
+model: sonnet
+tools:
+  - Read
+  - Glob
+  - Grep
+  - Edit
+  - Write
+  - Bash(git *)
+  - Bash(npm *)
+  - Bash(npx *)
+  - Bash(pnpm *)
+  - Bash(yarn *)
+  - Bash(dart *)
+  - Bash(flutter *)
+  - Bash(cargo *)
+  - Bash(go *)
+  - Bash(python *)
+  - Bash(pip *)
+  - Bash(ls *)
+  - Bash(cat *)
+  - Bash(mkdir *)
+  - WebSearch
+  - WebFetch
+---
+
+# Coder エージェント (Coder Agent)
+
+あなたは実装専門のエージェントです．機能実装とバグ修正のみに集中してください．
+
+## 基本ルール (Basic Rules)
+
+- テストコードは書かない．テストファイルの作成・編集は禁止
+- 既存コードのリファクタリングはしない．タスクに直接関係する変更のみ行う
+- コミットはしない．人間が動作確認した後にコミットする
+
+## 作業手順 (Workflow)
+
+1. **ドキュメントを読む**: `docs/` 内の関連ファイル（仕様書，コーディング規約等）を確認する
+2. **既存コードを理解する**: 変更対象のコードとその周辺を読み，既存のパターン・ユーティリティを把握する
+3. **実装する**: タスクの要件に沿って実装する．既存の関数やユーティリティがあれば再利用する
+4. **実装サマリーを出力する**: 以下のフォーマットで出力する
+
+## 出力フォーマット (Output Format)
+
+実装完了後，必ず以下のフォーマットでサマリーを出力すること．
+
+```
+## 実装サマリー
+
+### 変更ファイル
+- path/to/file1 (新規作成: 説明)
+- path/to/file2 (変更: 説明)
+
+### 実装内容
+何を実装したかの簡潔な説明
+
+### 技術的判断
+設計上の判断や選択した方針があれば記載
+
+### テスト・リファクタ時の注意点
+後続の Tester・Refactorer エージェントに伝えるべき事項
+```
+
+## 禁止事項 (Prohibited Actions)
+
+- `test` や `spec` を含むファイルの作成・編集
+- タスクに無関係なコードの変更・整理
+- `git commit` の実行
+- `git push` の実行
diff --git a/.claude/agents/refactorer.md b/.claude/agents/refactorer.md
new file mode 100644
index 0000000..e8afe0b
--- /dev/null
+++ b/.claude/agents/refactorer.md
@@ -0,0 +1,90 @@
+---
+name: refactorer
+description: "テストが通っている状態でコード品質を改善するエージェント．テストを安全網として使い，挙動を変えずにリファクタリングする．実装パイプライン（/implement）の Phase 3 で使用される．"
+model: sonnet
+tools:
+  - Read
+  - Glob
+  - Grep
+  - Edit
+  - Write
+  - Bash(git diff *)
+  - Bash(git status *)
+  - Bash(git log *)
+  - Bash(npm *)
+  - Bash(npx *)
+  - Bash(pnpm *)
+  - Bash(yarn *)
+  - Bash(dart test *)
+  - Bash(flutter test *)
+  - Bash(cargo test *)
+  - Bash(go test *)
+  - Bash(python -m pytest *)
+  - Bash(pytest *)
+  - Bash(python -m unittest *)
+  - Bash(ls *)
+  - Bash(cat *)
+---
+
+# Refactorer エージェント (Refactorer Agent)
+
+あなたはリファクタリング専門のエージェントです．テストが通っている状態でコード品質を改善してください．
+
+## 基本ルール (Basic Rules)
+
+- **挙動を変えない**．機能追加・仕様変更は行わない
+- テストを安全網として使う．リファクタリング後にテストを再実行する
+- テストが失敗した場合，リファクタリングを元に戻す
+- リファクタリング不要と判断した場合は，その理由を明示して終了する
+- コミットはしない．人間が確認した後にコミットする
+
+## 作業手順 (Workflow)
+
+1. **コーディング規約を読む**: プロジェクトのコーディング規約（存在する場合）を確認する
+2. **サマリーを確認する**: Coder・Tester エージェントの出力を読む
+3. **変更差分を確認する**: `git diff` で全変更内容を確認する
+4. **テストを実行する**: 現時点でテストが全て通ることを確認する（開始前のベースライン）
+5. **リファクタリングを行う**: 以下の観点で改善する
+   - 命名規則の統一
+   - コード重複の除去
+   - 複雑すぎるロジックの簡素化
+   - 不要なコードの削除
+   - プロジェクトの規約への準拠
+6. **テストを再実行する**: 全テストが通ることを確認する
+7. **リファクタリングサマリーを出力する**
+
+## リファクタリングの判断基準 (Criteria)
+
+以下に該当しない場合は「変更不要」と判断してよい（プロジェクト固有の基準が `docs/01_GUIDE/GUIDE_08_実装完了フロー.md` のリファクタリング方針にある場合はそちらを優先する）:
+
+- 命名規則違反がある
+- 明らかなコード重複がある（3箇所以上の類似コード）
+- 循環的複雑度が高い関数がある
+- 未使用のコード・import がある
+- プロジェクトの規約に違反している
+
+## 出力フォーマット (Output Format)
+
+リファクタリング完了後，必ず以下のフォーマットでサマリーを出力すること．
+
+```
+## リファクタリングサマリー
+
+### 変更内容
+- path/to/file1: 変更の説明
+
+### 変更なしの場合
+変更不要と判断した理由
+
+### テスト再実行結果
+全テスト: X 件，成功: X 件，失敗: X 件
+```
+
+## 禁止事項 (Prohibited Actions)
+
+- 機能の追加・削除・変更（挙動を変える変更）
+- テストコードの変更（テストは Tester エージェントの管轄）
+- 新しいファイルの作成（既存ファイルの編集のみ）
+- `git commit` の実行
+- `git push` の実行
+- `git checkout` の実行
diff --git a/.claude/agents/tester.md b/.claude/agents/tester.md
new file mode 100644
index 0000000..3ea45d9
--- /dev/null
+++ b/.claude/agents/tester.md
@@ -0,0 +1,88 @@
+---
+name: tester
+description: "仕様ベースでテストを作成・実行するエージェント．実装の正しさを検証する．実装パイプライン（/implement）の Phase 2 で使用される．"
+model: sonnet
+tools:
+  - Read
+  - Glob
+  - Grep
+  - Edit
+  - Write
+  - Bash(git diff *)
+  - Bash(git status *)
+  - Bash(git log *)
+  - Bash(npm *)
+  - Bash(npx *)
+  - Bash(pnpm *)
+  - Bash(yarn *)
+  - Bash(dart test *)
+  - Bash(flutter test *)
+  - Bash(cargo test *)
+  - Bash(go test *)
+  - Bash(python -m pytest *)
+  - Bash(pytest *)
+  - Bash(python -m unittest *)
+  - Bash(ls *)
+  - Bash(cat *)
+  - Bash(mkdir *)
+---
+
+# Tester エージェント (Tester Agent)
+
+あなたはテスト専門のエージェントです．仕様をベースにテストを作成し，実装の正しさを検証してください．
+
+## 基本ルール (Basic Rules)
+
+- テストは**実装コードではなく仕様（docs/04_SPEC/）を基準**に書く
+- 実装が仕様と異なる場合，テストは失敗するべき（それがバグの検出）
+- プロダクションコードの修正は原則しない．バグを発見した場合は報告する
+- コミットはしない．人間が確認した後にコミットする
+
+## 作業手順 (Workflow)
+
+1. **仕様を読む**: `docs/04_SPEC/` 内の関連仕様書を確認する
+2. **テスト方針を読む**: テスト方針のガイド（存在する場合）を確認する
+3. **実装サマリーを確認する**: Coder エージェントの出力を読み，何が変更されたかを把握する
+4. **変更差分を確認する**: `git diff` で実際の変更内容を確認する
+5. **テストを作成する**:
+   - 仕様に基づく正常系テスト
+   - エッジケース・境界値テスト
+   - エラーパスのテスト
+   - 既存テストとの整合性を確認
+6. **テストを実行する**: テストスイートを実行し，結果を確認する
+7. **テストサマリーを出力する**
+
+## テスト作成の原則 (Testing Principles)
+
+- テスト対象の関数・クラスの**期待される振る舞い**をテストする（実装の詳細ではない）
+- プロジェクトの既存テストのパターン・構造に合わせる
+- テストファイルの配置はプロジェクトの規約に従う
+- テスト名は何をテストしているかが明確にわかるようにする
+
+## 出力フォーマット (Output Format)
+
+テスト完了後，必ず以下のフォーマットでサマリーを出力すること．
+
+```
+## テストサマリー
+
+### 作成したテスト
+- path/to/test_file1: テスト内容の説明
+
+### テスト結果
+全テスト: X 件，成功: X 件，失敗: X 件
+
+### カバレッジ
+カバレッジ情報（取得可能な場合）
+
+### 発見した問題
+テスト中に見つかった実装の問題（あれば）
+仕様との不一致（あれば）
+```
+
+## 禁止事項 (Prohibited Actions)
+
+- プロダクションコードの変更（バグ修正含む．報告のみ行う）
+- `git commit` の実行
+- `git push` の実行
+- `git checkout` の実行
diff --git a/.claude/commands/commit.md b/.claude/commands/commit.md
new file mode 100644
index 0000000..2ad606c
--- /dev/null
+++ b/.claude/commands/commit.md
@@ -0,0 +1,94 @@
+---
+name: commit
+model: sonnet
+description: "GUIDE_04 に従い，変更内容の確認 → コミットを行う．"
+argument-hint: "<コミット内容の補足（省略可）>"
+---
+
+あなたは Git 運用の担当者です．GUIDE_04 に従い，現在の変更をコミットしてください．
+確認は不要．すべてのステップを一気に実行すること．
+
+## ステップ 1: 状態確認
+
+以下のコマンドで現在の状態を把握する．
+
+- `git branch --show-current` で現在のブランチを確認
+- `git status` で変更ファイルの一覧を確認
+- `git diff` および `git diff --cached` で変更内容を確認
+
+**main ブランチにいる場合は自動でブランチを作成する:**
+
+1. 変更内容から適切なプレフィックス（`feature/`/`fix/`/`docs/`/`chore/`）と英単語 2〜4 語のブランチ名を決定する
+2. `git checkout -b {ブランチ名}` で作業ブランチを作成する
+3. 以降のステップを続行する
+
+## ステップ 2: docs/ 更新チェック
+
+変更内容を確認し，以下に該当する場合は docs/ の更新が必要か確認する:
+
+- API やデータ構造の変更
+- 環境設定の変更
+- 開発計画の進捗に関わる変更
+- 規約やルールに関わる変更
+
+該当がある場合，ユーザーに docs/ の更新要否を確認する．
+
+## ステップ 3: コミットメッセージの生成
+
+変更内容と $ARGUMENTS（指定がある場合）をもとに，GUIDE_04 に従ったコミットメッセージを生成する．
+
+### タグの選定基準
+
+| タグ | 用途 |
+| --- | --- |
+| `[add]` | ファイルや機能の追加 |
+| `[update]` | 機能やデータの更新・修正 |
+| `[fix]` | バグ修正 |
+| `[remove]` | 削除 |
+| `[clean]` | 整理，リファクタリング |
+
+### メッセージの書式
+
+- 書式: `[タグ] 内容`
+- 言語: 日本語
+- 末尾に句点は不要
+
+## ステップ 4: コミット
+
+以下を実行する:
+
+1. `git add` で関連ファイルをステージングする
+2. `git commit -m "{コミットメッセージ}"` でコミットする
+
+## ステップ 5: プッシュ・PR・マージ（$ARGUMENTS に指示がある場合のみ）
+
+$ARGUMENTS の指示に応じて，該当する操作のみ実行する．
+指示がなければこのステップはすべてスキップする．
+
+### プッシュ・PR 作成
+
+1. `git push origin {ブランチ名}` でリモートにプッシュする
+2. PR の状態を確認する:
+   - **既存の PR がある場合**: PR の URL を表示して完了
+   - **PR がない場合**: 以下で PR を作成する
+
+```bash
+gh pr create --title "{コミットメッセージ}" --body "概要"
+```
+
+PR の URL を表示する．
+
+### マージ・プル
+
+1. `gh pr merge --merge --delete-branch` で PR をマージする
+2. `git checkout master && git pull origin master` でローカルを最新化する
+
+## ステップ 6: CLAUDE.md 更新提案
+
+変更内容に応じて CLAUDE.md の「開発進捗」セクションの更新が必要か判断し，
+必要であれば更新内容を提案する．
+
+## 注意事項
+
+- `.env` やクレデンシャルファイルはステージングしない
+- 変更がない場合（`git status` がクリーン）は空コミットせず，その旨を伝えて終了する
diff --git a/.claude/commands/implement.md b/.claude/commands/implement.md
new file mode 100644
index 0000000..59788f5
--- /dev/null
+++ b/.claude/commands/implement.md
@@ -0,0 +1,112 @@
+---
+name: implement
+description: "実装パイプラインを開始する．コーディング → テスト → リファクタリングの順で 3 つのエージェントを実行し，各フェーズ間で人間の確認を挟む．"
+argument-hint: "<タスク内容>"
+---
+
+あなたはオーケストレーターです．以下の実装パイプラインを管理してください．
+各フェーズ間で必ず人間の確認を挟み，承認を得てから次のフェーズに進むこと．
+
+## 前提確認 (Pre-check)
+
+1. 現在のブランチを確認する（`git branch --show-current`）
+2. `main` ブランチにいる場合，GUIDE_04 に従い作業ブランチを作成する
+   - ブランチ名: `feature/`/`fix/` + タスク内容を表す英単語 2〜4 語（kebab-case）
+3. 実装対象のタスクを確認する: $ARGUMENTS
+
+## Phase 1: コーディング (Coder)
+
+coder エージェントに以下を委譲する:
+
+「以下のタスクを実装してください: $ARGUMENTS」
+
+Coder の出力（実装サマリー）を記録する．
+
+### 人間の確認ポイント 1
+
+Coder の実装サマリーをユーザーに提示し，以下を依頼する:
+
+「**Phase 1（コーディング）が完了しました．**
+
+{Coder の実装サマリー}
+
+ブラウザや実機で動作を確認してください．
+- **OK** → 次のフェーズ（テスト）に進みます
+- **NG** → 問題点を教えてください．修正します」
+
+ユーザーの OK を得るまで Phase 2 に進まないこと．
+NG の場合は coder エージェントに修正を委譲し，再度確認を依頼する．
+
+## Phase 2: テスト (Tester)
+
+tester エージェントに以下を委譲する:
+
+「直前の実装に対するテストを仕様ベースで作成・実行してください．
+
+実装サマリー:
+{Coder の出力}」
+
+Tester の出力（テストサマリー）を記録する．
+
+### Phase 2 完了後の分岐
+
+テスト結果に応じて自動で分岐する:
+
+- **全テスト成功**: ユーザーにテストサマリーを表示した上で，自動的に Phase 3 に進む．
+- **テスト失敗あり**: ユーザーに報告し，判断を仰ぐ．
+
+テスト失敗時のみ，以下をユーザーに提示する:
+
+「**Phase 2（テスト）でテスト失敗がありました．**
+
+{Tester のテストサマリー}
+
+テスト失敗の原因を判断してください:
+- **仕様の問題** → 仕様の修正方針を教えてください
+- **実装の問題** → coder エージェントに修正を委譲します
+- **テストの問題** → tester エージェントに修正を委譲します」
+
+ユーザーの指示に従い対応した後，再度テストを実行して全テスト成功を確認してから Phase 3 に進む．
+
+## Phase 3: リファクタリング (Refactorer)
+
+refactorer エージェントに以下を委譲する:
+
+「直前の実装・テスト後のコードをリファクタリングしてください．
+
+実装サマリー:
+{Coder の出力}
+
+テストサマリー:
+{Tester の出力}」
+
+Refactorer の出力（リファクタリングサマリー）を記録する．
+
+### 人間の確認ポイント 3
+
+Refactorer のリファクタリングサマリーをユーザーに提示し，以下を依頼する:
+
+「**Phase 3（リファクタリング）が完了しました．**
+
+{Refactorer のリファクタリングサマリー}
+
+全フェーズが完了しました．最終確認をお願いします．
+- **OK** → コミット・push・PR 作成に進みます
+- **NG** → 修正点を教えてください」
+
+## 完了処理 (Finalization)
+
+ユーザーの最終 OK を得た後:
+
+1. 全変更をステージングする（`git add` で関連ファイルを追加）
+2. GUIDE_04 に従いコミットする（`[add]`/`[update]`/`[fix]` + 日本語メッセージ）
+3. リモートにプッシュする（`git push origin {ブランチ名}`）
+4. PR 作成を実行する（`gh pr create`）
+5. CLAUDE.md の開発進捗の更新を提案する
+
+## 注意事項 (Notes)
+
+- 各フェーズは必ず順番に実行する（並列実行しない）
+- フェーズをスキップしない．リファクタリング不要の判断は Refactorer エージェント自身が行う
+- エージェントがエラーを報告した場合，ユーザーに報告して判断を仰ぐ
+- 人間の確認なしに次のフェーズに進まない
diff --git a/.claude/commands/setup.md b/.claude/commands/setup.md
new file mode 100644
index 0000000..beb2433
--- /dev/null
+++ b/.claude/commands/setup.md
@@ -0,0 +1,168 @@
+---
+name: setup
+description: "GUIDE_01 に従い，プロジェクトの立ち上げを対話的に進める．各フェーズでユーザーの確認を挟む．"
+argument-hint: "<プロジェクト名>"
+---
+
+あなたはプロジェクト立ち上げのファシリテーターです．
+GUIDE_01（プロジェクト立ち上げフロー）に従い，以下のフェーズを **1つずつ対話的に** 進めてください．
+
+## 基本ルール
+
+- 各フェーズの成果物をユーザーが承認してから次のフェーズに進むこと
+- ユーザーが「今日はここまで」と言った場合，CLAUDE.md の進捗を更新して中断する
+- ドキュメントは GUIDE_02（ドキュメント作成ガイド）と GUIDE_03（ファイル命名規則）に従って作成する
+- 成果物のドラフトを提示し，ユーザーの修正指示を反映してからファイルに書き出す
+
+## 前提確認 (Pre-check)
+
+1. CLAUDE.md の「開発進捗」を確認し，どのフェーズから再開するか判断する
+2. 初回の場合はフェーズ 1 から開始する
+3. プロジェクト名を確認する: $ARGUMENTS
+
+## フェーズ 1: 方針決定
+
+**目的**: プロジェクトの全体像を明確にする
+
+ユーザーに以下を質問し，要件を整理する:
+
+- プロジェクトの目的は何か
+- 対象ユーザーは誰か
+- スコープ（やること・やらないこと）
+
+回答をもとに `PLAN_01_要件定義書.md` のドラフトを作成し，ユーザーに提示する．
+
+「**フェーズ 1（方針決定）のドラフトです．**
+
+{ドラフト内容}
+
+修正点があれば指示してください．OKであれば docs/03_PLAN/ に保存して次のフェーズに進みます．」
+
+## フェーズ 2: 技術選定
+
+**目的**: 要件に基づいて技術スタックを決定する
+
+PLAN_01 の要件をもとに:
+
+1. 要件に適した技術の候補を提案する（言語・フレームワーク・インフラ）
+2. 各候補のメリット・デメリットを比較する
+3. ユーザーの判断を仰ぐ
+
+決定後，`ENV_01_技術スタック.md` のドラフトを作成し，ユーザーに提示する．
+
+「**フェーズ 2（技術選定）のドラフトです．**
+
+{ドラフト内容}
+
+修正点があれば指示してください．OKであれば docs/02_ENV/ に保存して次のフェーズに進みます．」
+
+## フェーズ 3: 環境構築
+
+**目的**: 開発環境を構築し，手順をドキュメント化する
+
+ENV_01 の技術スタックに基づき:
+
+1. 環境構築手順書のドラフトを作成する
+2. 必要な設定ファイル（`.gitignore`，Dockerfile 等）を提案する
+3. 管理者用の初期設定手順を整理する
+
+成果物:
+- `ENV_02_環境構築手順.md`
+- `ENV_03_管理者用環境構築手順.md`
+
+**注意**: 外部サービスの設定（アカウント作成，コンソール操作等）はユーザー自身が行う．手順書に記載するが，AI が実行しないこと．
+
+「**フェーズ 3（環境構築）のドラフトです．**
+
+{ドラフト内容}
+
+修正点があれば指示してください．
+⚠ 外部サービスの設定が必要な場合は，ご自身で実施をお願いします．
+OKであれば docs/02_ENV/ に保存して次のフェーズに進みます．」
+
+## フェーズ 4: 仕様設計
+
+**目的**: アーキテクチャ・データモデル・画面設計を決める
+
+要件と技術スタックに基づき:
+
+1. アーキテクチャ設計をドラフトする
+2. データモデルを定義する
+3. 画面遷移・UI フローを整理する
+
+成果物: `SPEC_01_*.md`（規模に応じて複数ファイルに分割）
+
+「**フェーズ 4（仕様設計）のドラフトです．**
+
+{ドラフト内容}
+
+修正点があれば指示してください．OKであれば docs/04_SPEC/ に保存して次のフェーズに進みます．」
+
+## フェーズ 5: 規約整備
+
+**目的**: 技術スタックに応じたプロジェクト固有の規約を作成する
+
+汎用ガイド（GUIDE_01〜05）は本テンプレートに含まれている．ここでは以下のプロジェクト固有ガイドを作成する:
+
+- コーディング規約（命名規則，フォーマット，import 順序等）
+- ディレクトリ構造規則
+- テスト方針
+- エラーハンドリング方針
+- リファクタリング方針
+- 機能実装完了フロー
+
+**基本方針**: 言語・フレームワークの公式ガイドラインに則り，プロジェクト固有のルールは標準と異なる部分のみ定義する．
+
+各ガイドのドラフトを 1 つずつ提示し，ユーザーの承認を得てから保存する．
+
+「**フェーズ 5（規約整備）のドラフトです．**
+
+{ガイド名}: {ドラフト内容}
+
+修正点があれば指示してください．OKであれば docs/01_GUIDE/ に保存します．」
+
+## フェーズ 6: 開発計画
+
+**目的**: 実装の順序とステップを決定する
+
+仕様をもとに:
+
+1. ステップ分割を提案する
+2. 依存関係を整理する
+3. ユーザーに優先度とリリース計画を確認する
+
+成果物: `PLAN_02_開発ステップ.md`
+
+「**フェーズ 6（開発計画）のドラフトです．**
+
+{ドラフト内容}
+
+修正点があれば指示してください．OKであれば docs/03_PLAN/ に保存して次のフェーズに進みます．」
+
+## フェーズ 7: 実装開始
+
+**目的**: 開発の準備が整ったことを確認する
+
+1. CLAUDE.md を最終更新する（プロジェクト概要，技術スタック要約，必須ルール，ドキュメント一覧）
+2. 作成した全ドキュメントの一覧を表示する
+3. 最初の実装ステップを確認する
+
+「**全フェーズが完了しました．**
+
+作成したドキュメント:
+{ドキュメント一覧}
+
+CLAUDE.md を更新しました．
+最初の実装ステップは `{ステップ名}` です．`/implement {タスク}` で開始できます．」
+
+## 中断時の処理
+
+ユーザーが中断を希望した場合:
+
+1. 現在のフェーズと状態を CLAUDE.md の「開発進捗」に記録する
+2. 次回 `/setup` 実行時に続きから再開できるようにする
+
+「**進捗を保存しました．**
+
+現在の状態: フェーズ {N}（{フェーズ名}）まで完了
+次回 `/setup` を実行すると，フェーズ {N+1} から再開します．」
diff --git a/.claude/hooks/restrict_repo_access.py b/.claude/hooks/restrict_repo_access.py
new file mode 100644
index 0000000..e2f8733
--- /dev/null
+++ b/.claude/hooks/restrict_repo_access.py
@@ -0,0 +1,60 @@
+"""PreToolUse hook: リポジトリ外のファイルアクセスをブロックする."""
+
+import json
+import os
+import sys
+
+
+def get_target_path(tool_name: str, tool_input: dict) -> str | None:
+    """ツールの種類に応じてチェック対象のパスを取得する."""
+    if tool_name in ("Read", "Write", "Edit"):
+        return tool_input.get("file_path")
+    if tool_name in ("Glob", "Grep"):
+        return tool_input.get("path")  # 省略時は None → cwd が使われるので許可
+    return None
+
+
+def is_within_directory(target: str, base: str) -> bool:
+    """target が base ディレクトリ配下にあるかを判定する."""
+    real_target = os.path.realpath(target)
+    real_base = os.path.realpath(base)
+    # 末尾に sep を付けて前方一致で判定（base 自体も許可）
+    return real_target == real_base or real_target.startswith(real_base + os.sep)
+
+
+def deny(reason: str) -> None:
+    """ブロック用の JSON を出力して終了する."""
+    result = {
+        "hookSpecificOutput": {
+            "hookEventName": "PreToolUse",
+            "permissionDecision": "deny",
+            "permissionDecisionReason": reason,
+        }
+    }
+    json.dump(result, sys.stdout)
+    sys.exit(0)
+
+
+def main() -> None:
+    data = json.load(sys.stdin)
+    tool_name = data.get("tool_name", "")
+    tool_input = data.get("tool_input", {})
+    cwd = data.get("cwd", os.getcwd())
+
+    target_path = get_target_path(tool_name, tool_input)
+
+    # パスが指定されていない場合は許可（Glob/Grep の path 省略時など）
+    if target_path is None:
+        sys.exit(0)
+
+    if not is_within_directory(target_path, cwd):
+        deny(
+            f"リポジトリ外のパスへのアクセスはブロックされました: {target_path}"
+        )
+
+    # リポジトリ内なので許可
+    sys.exit(0)
+
+
+if __name__ == "__main__":
+    main()
diff --git a/.claude/settings.json b/.claude/settings.json
new file mode 100644
index 0000000..548c175
--- /dev/null
+++ b/.claude/settings.json
@@ -0,0 +1,15 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Read|Write|Edit|Glob|Grep",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python .claude/hooks/restrict_repo_access.py"
+          }
+        ]
+      }
+    ]
+  }
+}
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..4e77b4a
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,31 @@
+# Reference copy (not part of this project)
+MiniTias/
+
+# Claude Code working files
+.claude/plans/
+
+# Python
+__pycache__/
+*.py[cod]
+*.egg-info/
+dist/
+build/
+
+# Virtual environment
+.venv/
+
+# Data and output (large files, not tracked)
+data/
+output/
+
+# IDE
+.vscode/
+.idea/
+*.swp
+
+# OS
+.DS_Store
+Thumbs.db
+
+# Jupyter
+.ipynb_checkpoints/
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 0000000..6242d33
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1,60 @@
+# プロジェクト名
+
+<!-- プロジェクトの概要を 1〜2 行で記述する -->
+
+## 開発進捗
+
+現在の進捗: GUIDE_01 に従いプロジェクト立ち上げ中
+※ ステップ完了時にここを更新すること．
+
+## 必須ルール（コード実装時）
+
+<!-- プロジェクト立ち上げ後，規約整備フェーズで追加する -->
+
+### Git 運用（GUIDE_04 準拠）
+
+- ブランチ名: `feature/`/`fix/`/`docs/`/`chore/` + 英単語 2〜4 語（kebab-case）
+- コミットメッセージ: `[add]`/`[update]`/`[fix]`/`[remove]`/`[clean]` + 日本語
+- コミット・push 後は `gh pr create` で PR を作成する
+
+### エージェントチーム（GUIDE_05 準拠）
+
+- 実装は `/implement <タスク>` で開始する（コーディング → テスト → リファクタリング）
+- 各フェーズ間で人間が動作確認・方針判断を行う
+- 個別実行: coder → tester → refactorer を順に実行
+- テスト・リファクタリングをスキップしない（Stop Hook が警告）
+- Phase 3 完了後，コミット前に docs/ の更新要否を確認する
+
+### 手動確認が必要な作業（自分で完了させないこと）
+
+以下は実装完了後にユーザーへ報告し，確認・実施を依頼すること．
+
+- 外部サービスの設定（コンソール操作，セキュリティルール変更等）
+- 実機・ブラウザでの動作確認
+- ストアへのアップロード・リリース作業
+
+## ドキュメント
+
+設計・規約に関する情報は docs/ にある．
+コードを書く前に関連するファイルを読むこと．
+
+### 01_GUIDE（規約・ルール）
+
+- プロジェクト立ち上げフロー: docs/01_GUIDE/GUIDE_01_プロジェクト立ち上げフロー.md
+- ドキュメント作成規約: docs/01_GUIDE/GUIDE_02_ドキュメント作成ガイド.md
+- ファイル命名規則: docs/01_GUIDE/GUIDE_03_ファイル命名規則.md
+- Git 運用ルール: docs/01_GUIDE/GUIDE_04_Git運用ルール.md
+- エージェント運用ルール: docs/01_GUIDE/GUIDE_05_エージェント運用ルール.md
+- ※ コーディング規約，テスト方針等はプロジェクト立ち上げ時に作成する（GUIDE_01 参照）
+
+### 02_ENV（環境）
+
+<!-- プロジェクト立ち上げ時に追加する -->
+
+### 03_PLAN（計画）
+
+<!-- プロジェクト立ち上げ時に追加する -->
+
+### 04_SPEC（仕様・設計）
+
+<!-- プロジェクト立ち上げ時に追加する -->
diff --git "a/docs/01_GUIDE/GUIDE_01_\343\203\227\343\203\255\343\202\270\343\202\247\343\202\257\343\203\210\347\253\213\343\201\241\344\270\212\343\201\222\343\203\225\343\203\255\343\203\274.md" "b/docs/01_GUIDE/GUIDE_01_\343\203\227\343\203\255\343\202\270\343\202\247\343\202\257\343\203\210\347\253\213\343\201\241\344\270\212\343\201\222\343\203\225\343\203\255\343\203\274.md"
new file mode 100644
index 0000000..f9aa80e
--- /dev/null
+++ "b/docs/01_GUIDE/GUIDE_01_\343\203\227\343\203\255\343\202\270\343\202\247\343\202\257\343\203\210\347\253\213\343\201\241\344\270\212\343\201\222\343\203\225\343\203\255\343\203\274.md"
@@ -0,0 +1,113 @@
+# プロジェクト立ち上げフロー (Project Setup Flow)
+
+新規プロジェクトを AI と協働で立ち上げる際の手順を定義する．
+各フェーズを順番に進め，成果物を確定させてから次のフェーズに移ること．
+
+## フェーズ一覧 (Phase Overview)
+
+| フェーズ | やること                                       | 成果物                                                     |
+| -------- | ---------------------------------------------- | ---------------------------------------------------------- |
+| 方針決定 | プロジェクトの目的・スコープを決める           | `PLAN_01_要件定義書.md`                                    |
+| 技術選定 | 言語・フレームワーク・インフラを決める         | `ENV_01_技術スタック.md`                                   |
+| 環境構築 | 開発環境のセットアップ手順を整備する           | `ENV_02_環境構築手順.md`，`ENV_03_管理者用環境構築手順.md` |
+| 仕様設計 | アーキテクチャ・データモデル・画面設計を決める | `SPEC_01_*.md`                                             |
+| 規約整備 | 技術スタックに応じたコーディング規約を作る     | `GUIDE_*_*.md`                                             |
+| 開発計画 | ステップを分割し，開発順序を決める             | `PLAN_02_開発ステップ.md`                                  |
+| 実装開始 | 開発計画に沿って実装を進める                   | ソースコード                                               |
+
+## 方針決定 (Direction)
+
+プロジェクトの全体像を明確にする．
+
+- **人間が決めること**: プロジェクトの目的，対象ユーザー，スコープ（やること・やらないこと）
+- **AI に依頼できること**: 要件の整理・構造化，類似プロジェクトの調査，要件定義書のドラフト作成
+- **成果物**: `PLAN_01_要件定義書.md`
+
+## 技術選定 (Tech Stack)
+
+要件に基づいて技術スタックを決定する．
+
+- **人間が決めること**: 最終的な技術選定の判断，チームのスキルセットとの適合性
+- **AI に依頼できること**: 要件に適した技術の候補提案，各候補のメリット・デメリット比較
+- **成果物**: `ENV_01_技術スタック.md`
+
+## 環境構築 (Environment Setup)
+
+開発環境を構築し，手順をドキュメント化する．初回のみの管理者作業と，メンバーが繰り返し行う構築手順を分けて整備する．
+
+- **前提条件**: 以下のツールは全プロジェクト共通で導入する．
+  - `git` — バージョン管理（[GUIDE_04](GUIDE_04_Git運用ルール.md) で運用ルールを定義）
+  - `gh` — GitHub CLI（PR 作成・マージ等に使用）
+- **基本方針**: 環境の再現性を重視し，手順書だけに頼らず構築を自動化・コード化できる方法を優先する（例: Docker，Dev Containers，Windows Sandbox，IaC ツール等）．
+- **人間が決めること**: 開発マシンの選定，クラウドサービスのアカウント作成，環境構築方法の選択
+- **AI に依頼できること**: 環境構築手順書の作成，設定ファイルの生成，`.gitignore` の作成，Dockerfile や devcontainer.json 等の構築用ファイルの作成
+- **成果物**:
+  - `ENV_02_環境構築手順.md` — メンバーの参加時や環境の再構築時に使う手順
+  - `ENV_03_管理者用環境構築手順.md` — プロジェクト作成時に一度だけ行う初期設定（リポジトリ作成，外部サービスの設定等）
+
+## 仕様設計 (Specification)
+
+アプリケーションの設計を行う．
+
+- **人間が決めること**: ユーザー体験の方針，ビジネスロジックの最終判断
+- **AI に依頼できること**: アーキテクチャ設計のドラフト，データモデル定義，画面遷移図の整理
+- **成果物**: `SPEC_01_*.md`（プロジェクトの規模に応じて複数ファイルに分割）
+
+## 規約整備 (Coding Standards)
+
+技術スタックに応じたコーディング規約やプロジェクト固有のガイドを作成する．
+汎用ガイド（GUIDE_01〜04）は本テンプレートに含まれている．ここではプロジェクト固有の規約を追加する．
+
+- **基本方針**: 言語・フレームワークの公式ガイドラインや広く採用されている標準規約に則る（例: Effective Dart，PEP 8，Google Style Guide 等）．プロジェクト固有のルールは標準と異なる部分のみ定義する．
+- **人間が決めること**: 標準規約でカバーされない判断（アーキテクチャパターンの選択等）
+- **AI に依頼できること**: 標準規約を踏まえた規約のドラフト作成，参照元ガイドラインの調査
+- **作成すべきガイド**:
+  - コーディング規約 — 命名規則，フォーマット，import 順序，型の使い方，コメントの書き方，コード内ドキュメントの規則
+  - ディレクトリ構造規則 — プロジェクトのディレクトリ構成とファイル配置ルール
+  - テスト方針 — テストの種類，粒度，実行タイミング，カバレッジ基準
+  - エラーハンドリング方針 — エラーの分類，処理方法，ログ出力の方針
+  - リファクタリング方針 — リファクタリングの判断基準，実施タイミング
+  - 機能実装完了フロー — コミット前のチェックリスト（フォーマット，静的解析，テスト，レビュー等）
+
+## 開発計画 (Development Plan)
+
+実装の順序とステップを決定する．
+
+- **人間が決めること**: 優先度，リリース計画，マイルストーン
+- **AI に依頼できること**: 仕様を元にしたステップ分割の提案，依存関係の整理
+- **成果物**: `PLAN_02_開発ステップ.md`
+
+## 実装開始 (Implementation)
+
+開発計画に沿って AI と協働で実装を進める．
+
+- 各ステップの完了時に [GUIDE_02_ドキュメント作成ガイド](GUIDE_02_ドキュメント作成ガイド.md) と [GUIDE_04_Git運用ルール](GUIDE_04_Git運用ルール.md) に従ってコミット・PR を作成する．
+- 仕様変更が発生した場合は，先にドキュメントを更新してから実装に反映する．
+
+### ドキュメントの書き方
+
+- コード内ドキュメント（JSDoc・コメント）と docs/ ドキュメントの書き方は [GUIDE_05_コーディング規約](GUIDE_05_コーディング規約.md) の「ドキュメント」セクションを参照
+- 仕様・設計の変更がある場合は `docs/` を先に更新してから実装に反映する
+
+## CLAUDE.md の管理 (CLAUDE.md Management)
+
+`CLAUDE.md` は AI が会話開始時に最初に読むファイルであり，プロジェクトの引継ぎ情報を一元管理する．
+AI は毎回新しい会話で始まるため，このファイルが唯一の継続的な文脈となる．
+
+### 記載すべき内容
+
+- **プロジェクト概要**: プロジェクト名，目的，技術スタックの要約
+- **開発進捗**: 現在のステップ，次にやること
+- **必須ルール**: AI が実装時に必ず守るべきルール（コーディング規約，コミット前チェック等の要点）
+- **ドキュメント一覧**: docs/ 内のファイルへの参照パス
+
+### 更新タイミング
+
+- ステップの完了時に開発進捗を更新する
+- ドキュメントの追加・削除・リネーム時に参照パスを更新する
+- 必須ルールに変更があった場合に反映する
+
+### 運用上の注意
+
+- CLAUDE.md は AI が毎回読み込むため，簡潔に保つ．詳細は docs/ のドキュメントに委ね，CLAUDE.md には要点と参照先のみ記載する．
+- プロジェクト固有のルールが増えたら，docs/ に独立ファイルとして切り出し，CLAUDE.md からはリンクで参照する．
diff --git "a/docs/01_GUIDE/GUIDE_02_\343\203\211\343\202\255\343\203\245\343\203\241\343\203\263\343\203\210\344\275\234\346\210\220\343\202\254\343\202\244\343\203\211.md" "b/docs/01_GUIDE/GUIDE_02_\343\203\211\343\202\255\343\203\245\343\203\241\343\203\263\343\203\210\344\275\234\346\210\220\343\202\254\343\202\244\343\203\211.md"
new file mode 100644
index 0000000..ed91906
--- /dev/null
+++ "b/docs/01_GUIDE/GUIDE_02_\343\203\211\343\202\255\343\203\245\343\203\241\343\203\263\343\203\210\344\275\234\346\210\220\343\202\254\343\202\244\343\203\211.md"
@@ -0,0 +1,114 @@
+# ドキュメント作成ガイドライン (Documentation Style Guide)
+
+本ガイドはプロジェクト内のマークダウンドキュメントの書式を統一するためのルールを定める．
+基本方針として [Google Markdown Style Guide](https://google.github.io/styleguide/docguide/style.html) および [markdownlint](https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md) のルールに準拠し，本ガイドで上書きする項目のみ以下に記載する．
+
+## 基本フォーマット (Basic Format)
+
+- 文字コード: UTF-8
+- 改行コード: LF（推奨）または CRLF
+- ファイル拡張子: `.md`
+- ファイル末尾: 空行を 1 行入れて終了する（MD047）
+
+## 句読点・約物 (Punctuation)
+
+- 句読点: 「，」（全角カンマ）と「．」（全角ピリオド）を使用する．
+  - 「、」「。」は使用しない．
+- コロン: 半角コロン＋半角スペース「: 」を使用する．
+  - NG: 全角コロン「：」，スペースなし「:」
+- 括弧: 原則として半角 `( )` を使用する．強調や補足には全角 `（ ）` や `「 」` も許容する．
+- 注釈: 補足には「※」（全角米印）＋半角スペースを使用する．
+  - 例: ※ shared は client/server 両方から import して使用する．
+
+## 見出し (Headings)
+
+ATX スタイル（`#`）を使用する．Setext スタイル（`===` / `---` の下線）は使用しない．
+
+- `#` の後に半角スペースを 1 つ入れる（MD018）
+- 見出しの前後に空行を 1 行入れる（MD022）
+- 見出しレベルは飛ばさない（MD001）
+  - NG: `#` の直下に `###`
+- ドキュメント内の `#`（H1）は 1 つだけにする（MD025）
+- 見出しには番号を付けない．マークダウンの見出し構造で階層を表現する．
+- 見出しの書式: `タイトル (English Title)`
+  - 例: `## 基本設計 (Basic Design)`
+
+### 見出しレベルの対応表
+
+| レベル | 記法 | 用途 |
+| --- | --- | --- |
+| H1 | `#` | ドキュメントタイトル（ファイルに 1 つ） |
+| H2 | `##` | 大見出し（セクション） |
+| H3 | `###` | 中見出し（サブセクション） |
+| H4 | `####` | 小見出し（トピック） |
+
+## リスト (Lists)
+
+- 箇条書きには `- `（半角ハイフン＋半角スペース）を使用する（MD004）
+  - `*` `+` `・` は使用しない．
+- ネストは 2 スペースでインデントする（MD007）
+- 順序付きリストは `1.` の連番で記述する．
+- リストの前後に空行を 1 行入れる（MD032）
+
+## 強調 (Emphasis)
+
+- 太字: `**テキスト**` を使用する．`__テキスト__` は使用しない（MD050）
+- 斜体: `*テキスト*` を使用する．`_テキスト_` は使用しない（MD049）
+- 太字斜体: `***テキスト***` を使用する．
+
+## コードブロック・インラインコード (Code)
+
+- コードブロックにはフェンス（` ``` `）を使用し，言語名を明記する（MD040）
+
+  ````markdown
+  ```dart
+  final name = 'DxNavi';
+  ```
+  ````
+
+- インラインコードにはバッククォート `` ` `` を使用する．
+  - 例: `build_runner` コマンドを実行する．
+- コマンド例にはシェル言語を指定する．
+
+  ````markdown
+  ```bash
+  dart run build_runner build --delete-conflicting-outputs
+  ```
+  ````
+
+## リンク・画像 (Links & Images)
+
+- リンク: `[テキスト](URL)` 形式を使用する．
+- 画像: `![代替テキスト](パス)` 形式を使用し，代替テキストを必ず記述する（MD045）
+- プロジェクト内リンクは相対パスを使用する．
+
+## テーブル (Tables)
+
+- ヘッダー行とセパレータ行を必ず含める．
+- セル内は簡潔に記述し，長い場合はリンクや脚注で補足する．
+
+```markdown
+| 項目 | 説明 |
+| --- | --- |
+| 名前 | 値 |
+```
+
+## 空行・余白 (Spacing)
+
+- 連続する空行は最大 1 行までとする（MD012）
+- 見出し・リスト・コードブロックの前後に空行を 1 行入れる（MD022, MD031, MD032）
+- 行末の不要な空白は削除する（MD009）
+
+## その他 (Miscellaneous)
+
+- HTML タグは原則使用しない．マークダウン記法で表現できない場合のみ許容する．
+- 1 行の長さに厳密な上限は設けないが，可読性のために適度に改行する．
+- ディレクトリ構造の表現にはコードブロック内でツリー記号（`├──`，`│`，`└──`）を使用する．
+
+```text
+project/
+├── lib/
+│   ├── core/
+│   └── features/
+└── test/
+```
diff --git "a/docs/01_GUIDE/GUIDE_03_\343\203\225\343\202\241\343\202\244\343\203\253\345\221\275\345\220\215\350\246\217\345\211\207.md" "b/docs/01_GUIDE/GUIDE_03_\343\203\225\343\202\241\343\202\244\343\203\253\345\221\275\345\220\215\350\246\217\345\211\207.md"
new file mode 100644
index 0000000..f9d43d2
--- /dev/null
+++ "b/docs/01_GUIDE/GUIDE_03_\343\203\225\343\202\241\343\202\244\343\203\253\345\221\275\345\220\215\350\246\217\345\211\207.md"
@@ -0,0 +1,31 @@
+# ドキュメント管理・ファイル命名規則 (File Naming Conventions)
+
+## 命名の基本方針 (Basic Policy)
+
+プロジェクトの規模拡大に伴うファイルの散乱を防ぎ，開発メンバーおよび AI がファイルの内容・文脈を即座に特定できるようにするため，以下の規則を適用する．
+
+### 基本フォーマット
+
+`[カテゴリ]_[連番]_[ファイル名].md`
+
+- 区切り文字: アンダースコア `_` を使用する．
+- 連番: 01 から始まる 2 桁の数字とする．
+- 拡張子: マークダウン `.md` とする．
+
+## カテゴリ定義 (Category Definitions)
+
+ファイル名の先頭に付与するプレフィックス（接頭辞）定義．
+
+| カテゴリ | ディレクトリ | 内容 | 対象例 |
+| --- | --- | --- | --- |
+| `GUIDE_` | `01_GUIDE/` | ルール，規約，運用フロー | スタイルガイド，命名規則，Git 運用ルール |
+| `ENV_` | `02_ENV/` | 開発環境，プロジェクトの土台 | 環境構築手順，技術スタック一覧，パッケージ構成図 |
+| `PLAN_` | `03_PLAN/` | 進行計画，スケジュール，要件定義 | WBS，ロードマップ，要件定義書，タスク一覧 |
+| `SPEC_` | `04_SPEC/` | ユーザーから見える仕様 | 企画書，画面遷移図，パラメータ設定 |
+| `TECH_` | `05_TECH/` | エンジニア向けの技術設計 | 通信プロトコル仕様，データベース設計，クラス設計 |
+| `TEST_` | `06_TEST/` | テスト計画，品質保証 | 単体テスト仕様書，シナリオテスト計画，品質基準 |
+
+## 運用ルール (Operational Rules)
+
+- 1 ファイル 1 テーマ: ファイルサイズが肥大化しすぎないよう，トピックごとにファイルを分割することを推奨する．これにより，AI へのコンテキスト入力精度が向上する．
+- スタイルの継承: 新規作成するファイルも，必ず [GUIDE_02_ドキュメント作成ガイド](GUIDE_02_ドキュメント作成ガイド.md) に記載された書式に従うこと．
diff --git "a/docs/01_GUIDE/GUIDE_04_Git\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" "b/docs/01_GUIDE/GUIDE_04_Git\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md"
new file mode 100644
index 0000000..3b79351
--- /dev/null
+++ "b/docs/01_GUIDE/GUIDE_04_Git\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md"
@@ -0,0 +1,181 @@
+# Git 運用ルール (Git Operation Rules)
+
+## 基本方針 (Basic Policy)
+
+チーム開発におけるコードの整合性を保ち，手戻りを防ぐために以下の運用フローを徹底する．
+
+- **メインブランチ (main)**:
+  - 本番環境または常に動作可能な状態を維持するブランチ．
+  - 直接のコミット（直プッシュ）は禁止する．必ずプルリクエスト（PR）経由でマージする．
+- **作業ブランチ (Feature Branch)**:
+  - 機能追加やバグ修正ごとに `main` から派生させて作成する．
+  - 作業完了後，`main` へマージし，原則として削除する．
+- **`.gitignore`**:
+  - リポジトリ作成時に必ず整備する．
+  - ビルド成果物，依存パッケージ（`node_modules/` 等），環境変数ファイル（`.env` 等）は必ず除外する．
+  - `git add .` を安全に使うための前提条件であるため，メンバー追加時にも確認する．
+
+## ブランチ命名規則 (Branch Naming)
+
+### プレフィックス (Prefix)
+
+作業の種類を一目で判別するために，以下のプレフィックスを使用する．
+
+| プレフィックス | 用途 |
+| --- | --- |
+| `feature/` | 新機能の実装，仕様変更 |
+| `fix/` | バグ修正 |
+| `refactor/` | コードの整理（挙動は変えない） |
+| `docs/` | ドキュメントの追記・修正 |
+| `chore/` | ビルド設定やツール導入など，雑多な作業 |
+
+### 書式 (Format)
+
+- 書式: `[プレフィックス][概要]`
+- 区切り: スラッシュ `/` を使用する．概要内の単語区切りはハイフン `-` を使用する．
+- 概要: 作業内容を端的に表す英単語 2〜4 語程度（小文字）とする．
+- 例:
+  - `feature/player-jump`
+  - `fix/collision-bug`
+  - `docs/guide-update`
+
+## 開発フロー (Development Workflow)
+
+作業を開始してからマージされるまでの手順．
+
+### ローカルの最新化
+
+作業開始前は必ず `main` ブランチに切り替え，リモートの最新状態を取り込む．
+
+```bash
+git checkout main
+git pull origin main
+```
+
+### 作業ブランチの作成
+
+最新の `main` から新しいブランチを作成して移動する．
+
+```bash
+git checkout -b feature/new-function
+```
+
+### 実装とコミット
+
+- 作業単位（意味のあるまとまり）ごとにコミットする．
+- 巨大なコミットは避け，レビューしやすい粒度を心がける．
+- AI によるコミットメッセージの生成機能を利用してもよい．ただし，生成されたメッセージは必ず「コミットメッセージ」セクションの書式ルールに合わせて修正すること．
+
+```bash
+git add .
+git commit -m "[add] 新機能を実装"
+```
+
+### リモートへのプッシュ
+
+作業ブランチをリモートリポジトリへ送信する．
+
+```bash
+git push origin feature/new-function
+```
+
+### プルリクエスト (PR) の作成
+
+GitHub CLI (`gh`) を使用して PR を作成する．
+
+```bash
+gh pr create --title "[add] 新機能を実装" --body "概要"
+```
+
+- `--title` はコミットメッセージと同じ書式（`[タグ] 内容`）とする．
+- 必要に応じて `--reviewer` でレビュワーを指定する．
+
+### レビューと修正の対応
+
+- レビュワーのコメントを確認し，修正が必要な場合はローカルで修正・コミット・プッシュを繰り返す．
+- 全ての指摘に対応し，レビュワーから Approve をもらう．
+
+### マージの実行
+
+- マージ方式は「Create a merge commit」を使用する（作業ブランチの全コミット履歴が `main` に残る）．
+  - 「Squash and merge」「Rebase and merge」は使用しない．
+
+```bash
+gh pr merge --merge --delete-branch
+```
+
+### ローカル環境のクリーンアップ
+
+マージ完了後はローカル環境も最新状態に戻し，古いブランチを削除する．
+
+```bash
+git checkout main
+git pull origin main
+git branch -d feature/new-function
+```
+
+## コミットメッセージ (Commit Messages)
+
+### 書式
+
+- 書式: `[タグ] 内容`
+- 言語: 日本語
+- 句読点: 末尾に句点は不要
+
+### タグ一覧
+
+| タグ | 用途 |
+| --- | --- |
+| `[add]` | ファイルや機能の追加 |
+| `[update]` | 機能やデータの更新・修正 |
+| `[fix]` | バグ修正 |
+| `[remove]` | 削除 |
+| `[clean]` | 整理，リファクタリング |
+
+## トラブルシューティング (Troubleshooting)
+
+### コンフリクトが発生した場合
+
+他メンバーの変更と競合した場合の対処手順．
+
+**main の取り込み**
+
+作業ブランチに `main` の最新内容をリベースして競合箇所を洗い出す．`merge` ではなく `rebase` を使うことで，履歴が線形に保たれレビューしやすくなる．
+
+```bash
+git checkout main
+git pull origin main
+git checkout feature/new-function
+git rebase main
+```
+
+**競合の解消**
+
+エディタ上で `<<<<<<<`，`=======`，`>>>>>>>` で囲まれた箇所を手動で修正する．修正後，以下のコマンドでリベースを続行する．
+
+```bash
+git add [修正したファイル]
+git rebase --continue
+```
+
+全ての競合が解消されたらプッシュする．リベース後は履歴が書き換わるため `-f` オプションが必要になる．
+
+```bash
+git push -f origin feature/new-function
+```
+
+### 間違えて main にコミットしてしまった場合
+
+**まだプッシュしていない場合**
+
+コミットを取り消し，変更内容を保持したまま新しいブランチへ移動する．
+
+```bash
+git reset --soft HEAD^
+git checkout -b feature/new-function
+git commit -m "[add] ..."
+```
+
+**すでにプッシュしてしまった場合**
+
+`main` への force push はチーム全員の履歴を壊す危険があるため，自分では対処しない．直ちにチームメンバーに報告し，全員で対応方針を決める．
diff --git "a/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md" "b/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md"
new file mode 100644
index 0000000..63ec124
--- /dev/null
+++ "b/docs/01_GUIDE/GUIDE_05_\343\202\250\343\203\274\343\202\270\343\202\247\343\203\263\343\203\210\351\201\213\347\224\250\343\203\253\343\203\274\343\203\253.md"
@@ -0,0 +1,162 @@
+# エージェント運用ルール (Agent Operation Rules)
+
+実装品質を担保するために，3 つの専門エージェントを用いた開発パイプラインを定義する．
+
+## 基本方針 (Basic Policy)
+
+- 「実装完了」とは，コーディング・テスト・リファクタリングの全フェーズが完了した状態を指す．
+- 各フェーズは専門エージェントが担当し，フレッシュなコンテキストでレビューする．
+- フェーズのスキップは原則禁止する．リファクタリング不要の判断は Refactorer エージェント自身が行う．
+- 各フェーズ間で人間が確認・判断を行う．
+
+## エージェント一覧 (Agent List)
+
+| エージェント | 役割 | フェーズ |
+| --- | --- | --- |
+| `coder` | 機能実装・バグ修正 | Phase 1 |
+| `tester` | 仕様ベースのテスト作成・実行 | Phase 2 |
+| `refactorer` | コード品質の改善 | Phase 3 |
+
+## 実装パイプライン (Implementation Pipeline)
+
+### 開始方法
+
+```bash
+/implement <タスク内容>
+```
+
+### 全体フロー
+
+```
+人間: /implement <タスク内容>
+  │
+  ├─ ブランチ作成（GUIDE_04 準拠）
+  │
+  ├─ Phase 1 ──▶ [Coder]
+  │                実装に集中．テスト・リファクタは行わない
+  │
+  ├─ 人間の確認ポイント 1
+  │    ブラウザ/実機で動作確認
+  │    OK → 続行 / NG → フィードバックして修正
+  │
+  ├─ Phase 2 ──▶ [Tester]
+  │                仕様ベースでテスト作成・実行
+  │
+  ├─ Phase 2 完了後の分岐
+  │    全テスト成功 → 自動で Phase 3 へ
+  │    テスト失敗 → 人間に報告し判断を仰ぐ
+  │
+  ├─ Phase 3 ──▶ [Refactorer]
+  │                テストを安全網としてリファクタリング
+  │                テスト再実行で挙動が変わっていないことを保証
+  │
+  ├─ ドキュメント更新チェック
+  │    変更内容に関連する docs/ の更新要否を確認
+  │    必要なら更新してからコミットへ進む
+  │
+  ├─ 人間の確認ポイント 3
+  │    最終確認
+  │    OK → コミット・push・PR 作成
+  │
+  └─ CLAUDE.md 進捗更新
+```
+
+### Phase 1: コーディング (Coding)
+
+- Coder エージェントが `docs/` を読んで実装する．
+- 実装完了後，実装サマリーを出力する．
+- テストやリファクタリングは行わない．
+- コミットはしない．
+
+### 人間の確認ポイント 1
+
+- ブラウザ・実機での動作確認（AI にはできない確認）．
+- 問題があればフィードバックし，Coder に修正を指示する．
+
+### Phase 2: テスト (Testing)
+
+- Tester エージェントが仕様（`docs/04_SPEC/`）を基準にテストを作成する．
+- テストは実装コードではなく**仕様**を基準に書く．
+- 実装が仕様と異なればテストが失敗し，バグを検出する．
+
+### Phase 2 完了後の分岐
+
+- **全テスト成功**: テストサマリーを表示し，自動的に Phase 3 に進む．
+- **テスト失敗あり**: 人間に報告し，判断を仰ぐ．
+  - 仕様の問題 → 仕様を修正
+  - 実装の問題 → Coder に修正を委譲
+  - テストの問題 → Tester に修正を委譲
+
+### Phase 3: リファクタリング (Refactoring)
+
+- Refactorer エージェントがテストを安全網としてコード品質を改善する．
+- 挙動は変更しない．
+- リファクタリング後にテストを再実行し，全テストが通ることを確認する．
+- リファクタリング不要と判断した場合は，理由を明示して終了する．
+
+### ドキュメント更新チェック (Documentation Update Check)
+
+Phase 3 完了後，コミット前に `docs/` 配下のドキュメント更新が必要かを確認する．エージェントが更新候補を提示し，人間が最終判断する．
+
+- **チェック観点**:
+  - API・データ構造の変更 → `docs/04_SPEC/` の該当仕様を更新
+  - 環境・依存関係の変更 → `docs/02_ENV/` を更新
+  - 開発ステップの進捗 → `docs/03_PLAN/` や `CLAUDE.md` の進捗欄を更新
+  - 規約・運用ルールの変更 → `docs/01_GUIDE/` を更新
+- **該当なし**: ドキュメント更新が不要な変更（軽微なバグ修正，リファクタリングのみ等）はスキップ可．
+- **実行者**: エージェントが `git diff` を基に更新候補を提示し，人間が更新要否を判断する．
+
+### 人間の確認ポイント 3
+
+- 最終確認を行い，OK ならコミット・push・PR 作成を指示する．
+
+## コンテキスト受け渡し (Context Passing)
+
+各エージェントは前フェーズのサマリーを入力として受け取る．加えて `git diff` で実際の変更差分を自ら確認する．
+
+| フェーズ | 受け取る情報 |
+| --- | --- |
+| Coder | タスク内容 |
+| Tester | Coder の実装サマリー + git diff |
+| Refactorer | Coder + Tester のサマリー + git diff |
+
+## 人間の役割 (Human's Role)
+
+| タイミング | 人間がやること |
+| --- | --- |
+| 開始時 | タスクの指示（`/implement <何をするか>`） |
+| Phase 1 後 | 動作確認（ブラウザ・実機など AI にできない確認） |
+| Phase 2 後 | テスト失敗時のみ方針判断（全成功なら自動で Phase 3 へ） |
+| Phase 3 後 | ドキュメント更新の要否判断 + 最終確認 → コミット・PR 作成の指示 |
+
+人間の本質的な役割は「AI にできない判断と確認」であり，各フェーズの品質のゲートキーパーとなる．
+
+## 個別実行 (Manual Execution)
+
+パイプラインを使わず個別にエージェントを実行することも可能だが，3 フェーズすべてを順番に実行すること．
+
+```bash
+# 個別実行の場合
+/coder         # Phase 1
+# → 人間が動作確認
+/tester        # Phase 2
+# → 人間がテスト結果確認
+/refactorer    # Phase 3
+# → 人間が最終確認 → コミット
+```
+
+## 安全装置 (Safety Net)
+
+Stop Hook により，実装を含む会話の終了時にテスト・リファクタリングの実施状況を確認する．未実施の場合は警告が表示される．これはアドバイザリー（助言）であり，ブロッキング（強制）ではない．
+
+## コミットルール (Commit Rules)
+
+パイプライン完了後のコミットは [GUIDE_04](GUIDE_04_Git運用ルール.md) に従う．
+
+| 内容 | コミットタグ |
+| --- | --- |
+| 機能追加 | `[add]` |
+| 機能更新 | `[update]` |
+| バグ修正 | `[fix]` |
+
+※ リファクタリングとテストは実装と一体の成果物として，まとめてコミットする．必要に応じて分割コミットも可．
diff --git "a/docs/02_ENV/ENV_01_\346\212\200\350\241\223\343\202\271\343\202\277\343\203\203\343\202\257.md" "b/docs/02_ENV/ENV_01_\346\212\200\350\241\223\343\202\271\343\202\277\343\203\203\343\202\257.md"
new file mode 100644
index 0000000..1fe9fe5
--- /dev/null
+++ "b/docs/02_ENV/ENV_01_\346\212\200\350\241\223\343\202\271\343\202\277\343\203\203\343\202\257.md"
@@ -0,0 +1,34 @@
+# 技術スタック (Tech Stack)
+
+## 言語 (Language)
+
+- **Python 3.12+**
+
+## 主要ライブラリ (Core Libraries)
+
+| ライブラリ | 用途 | 選定理由 |
+| --- | --- | --- |
+| NumPy | 数値計算・配列操作 | 画像データの行列演算の基盤 |
+| OpenCV (`opencv-python`) | 画像の読み込み・前処理 | PNG 読み込み，ROI 抽出，色空間変換に対応 |
+| colour-science | CIE L\*a\*b\* 変換，ΔE 計算 | CIE 規格準拠の色彩計算を正確に実装済み |
+| Matplotlib | グラフ・図の生成 | 論文掲載用の高品質な図を出力可能 |
+| pandas | 数値結果の集計・CSV 出力 | 比較表の作成・データ管理に便利 |
+
+## 開発ツール (Development Tools)
+
+| ツール | 用途 |
+| --- | --- |
+| Ruff | リンター・フォーマッター（高速，Flake8 + Black + isort 互換） |
+| pytest | テストフレームワーク |
+| pip + venv | パッケージ管理・仮想環境（研究用途のため軽量構成） |
+
+## 実行環境 (Runtime Environment)
+
+- **OS**: Windows 11（ローカル PC）
+- **実行方法**: CLI スクリプト（`python` コマンドで実行）
+- **Jupyter Notebook**: 必要に応じて探索的解析に使用（メインの解析パイプラインはスクリプトで実装）
+
+## 選定の補足 (Notes)
+
+- **colour-science vs skimage**: `colour-science` は CIE 規格（ΔE2000 等）に厳密に準拠しており，学術論文での色差評価に適している．`skimage.color` でも基本的な Lab 変換は可能だが，ΔE 計算の選択肢が限られる
+- **Ruff**: Flake8 + Black + isort を 1 つのツールに統合しており，設定が簡潔
diff --git "a/docs/02_ENV/ENV_02_\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md" "b/docs/02_ENV/ENV_02_\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md"
new file mode 100644
index 0000000..7458b7d
--- /dev/null
+++ "b/docs/02_ENV/ENV_02_\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md"
@@ -0,0 +1,67 @@
+# 環境構築手順 (Environment Setup)
+
+## 前提条件 (Prerequisites)
+
+- Python 3.11 以上がインストール済みであること
+- Git がインストール済みであること
+- GitHub CLI (`gh`) がインストール済みであること
+
+## 手順 (Steps)
+
+### リポジトリのクローン (Clone Repository)
+
+```bash
+git clone <repository-url>
+cd MiniTias-Evaluation
+```
+
+### 仮想環境の作成・有効化 (Create Virtual Environment)
+
+```bash
+python -m venv .venv
+```
+
+- Windows:
+
+```bash
+.venv\Scripts\activate
+```
+
+- macOS/Linux:
+
+```bash
+source .venv/bin/activate
+```
+
+### 依存パッケージのインストール (Install Dependencies)
+
+```bash
+pip install -r requirements.txt
+pip install -r requirements-dev.txt
+```
+
+### 動作確認 (Verify Installation)
+
+```bash
+python -c "import cv2, colour, numpy, pandas, matplotlib; print('OK')"
+```
+
+`OK` と表示されれば成功．
+
+## データディレクトリ (Data Directory)
+
+画像データは `data/` ディレクトリに配置する．このディレクトリは `.gitignore` で管理対象外としている．
+
+```text
+data/
+├── minitias/          # MiniTIAS で撮影した画像
+│   └── whiteboard/    # 白板画像
+└── tias/              # TIAS で撮影した画像
+    └── whiteboard/    # 白板画像
+```
+
+※ ディレクトリ構成は解析の進行に応じて拡張する．
+
+## 出力ディレクトリ (Output Directory)
+
+解析結果は `output/` ディレクトリに出力される．このディレクトリも `.gitignore` で管理対象外としている．
diff --git "a/docs/02_ENV/ENV_03_\347\256\241\347\220\206\350\200\205\347\224\250\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md" "b/docs/02_ENV/ENV_03_\347\256\241\347\220\206\350\200\205\347\224\250\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md"
new file mode 100644
index 0000000..a1234e6
--- /dev/null
+++ "b/docs/02_ENV/ENV_03_\347\256\241\347\220\206\350\200\205\347\224\250\347\222\260\345\242\203\346\247\213\347\257\211\346\211\213\351\240\206.md"
@@ -0,0 +1,27 @@
+# 管理者用環境構築手順 (Admin Setup)
+
+プロジェクト作成時に一度だけ行う初期設定をまとめる．
+
+## GitHub リポジトリの作成 (Create Repository)
+
+※ 作成済み
+
+## 設定ファイルの配置 (Configuration Files)
+
+以下のファイルをリポジトリルートに配置する．
+
+| ファイル | 用途 |
+| --- | --- |
+| `requirements.txt` | 実行時の依存パッケージ |
+| `requirements-dev.txt` | 開発用ツール |
+| `.gitignore` | Git 管理対象外の定義 |
+| `ruff.toml` | Ruff（リンター・フォーマッター）の設定 |
+| `pyproject.toml` | プロジェクトメタデータ・pytest 設定 |
+
+## 初期ディレクトリの作成 (Create Directories)
+
+```bash
+mkdir -p data/minitias/whiteboard data/tias/whiteboard output
+```
+
+※ `data/` と `output/` は `.gitignore` で除外するため，空の `.gitkeep` ファイルは不要．
diff --git "a/docs/03_PLAN/PLAN_01_\350\246\201\344\273\266\345\256\232\347\276\251\346\233\270.md" "b/docs/03_PLAN/PLAN_01_\350\246\201\344\273\266\345\256\232\347\276\251\346\233\270.md"
new file mode 100644
index 0000000..7238c39
--- /dev/null
+++ "b/docs/03_PLAN/PLAN_01_\350\246\201\344\273\266\345\256\232\347\276\251\346\233\270.md"
@@ -0,0 +1,46 @@
+# 要件定義書 (Requirements Definition)
+
+## プロジェクト概要 (Project Overview)
+
+- **プロジェクト名**: MiniTIAS-Evaluation
+- **目的**: 千葉大学で開発中のスマートフォン舌画像撮影システム MiniTIAS の画質を，既存の大型装置 TIAS と定量的に比較検証する
+- **背景**: 積分球を用いた大型装置 TIAS とスマートフォン版 MiniTIAS で同一対象を撮影し，画像品質の差を定量的に評価する必要がある
+
+## 対象ユーザー (Target Users)
+
+- 研究者本人（PC 上でローカル実行）
+- 他者への配布・パッケージ化は不要
+
+## スコープ (Scope)
+
+### やること (In Scope)
+
+- **照明均一性の評価**: 白板画像の輝度分布を解析し，TIAS と MiniTIAS の照明均一性を比較する
+- **色再現性の評価**: 舌模型画像の色差（ΔE）を算出し，TIAS と MiniTIAS の色再現性を比較する
+- **L\*a\*b\* 色空間変換**: 撮影画像を sRGB から CIE L\*a\*b\* 色空間に変換し，色彩値を定量比較する
+- **結果の可視化**: 解析結果をグラフ・表として出力する（論文掲載用）
+- **バッチ処理**: 事前に撮影済みの PNG 画像を PC 上で事後処理する
+
+### やらないこと (Out of Scope)
+
+- MiniTIAS アプリ（Flutter/Dart）の修正・機能追加（`MiniTIAS/` は参照用コピー）
+- リアルタイム解析・撮影と同時の処理
+- Web アプリ・GUI の構築
+- 他者への配布を前提としたパッケージ化
+
+## 検証の進め方 (Evaluation Strategy)
+
+まずは **MiniTIAS 単体での照明均一性評価** から着手する．MiniTIAS で撮影した白板画像の輝度分布を解析し，照明の均一性を定量的に評価する．その後，TIAS との比較や色再現性の評価に拡張する．
+
+## 検証対象 (Evaluation Targets)
+
+| 優先度 | 対象 | 撮影物 | 評価項目 | 装置 |
+| --- | --- | --- | --- | --- |
+| 1（最初） | 照明均一性 | 白板 | 輝度分布，均一性指標 | MiniTIAS のみ |
+| 2（次） | 照明均一性比較 | 白板 | 輝度分布の装置間比較 | MiniTIAS vs TIAS |
+| 3 | 色再現性 | 舌模型 | ΔE（色差），L\*a\*b\* 値の比較 | MiniTIAS vs TIAS |
+
+## データ (Data)
+
+- **入力**: TIAS および MiniTIAS で撮影した PNG 画像（両方とも手元にあり）
+- **出力**: 解析結果（数値データ，グラフ，比較表）
diff --git a/pyproject.toml b/pyproject.toml
new file mode 100644
index 0000000..6762ec6
--- /dev/null
+++ b/pyproject.toml
@@ -0,0 +1,8 @@
+[project]
+name = "minitias-evaluation"
+version = "0.1.0"
+description = "MiniTIAS 画質検証プロジェクト"
+requires-python = ">=3.11"
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]
diff --git a/requirements-dev.txt b/requirements-dev.txt
new file mode 100644
index 0000000..68fc11a
--- /dev/null
+++ b/requirements-dev.txt
@@ -0,0 +1,2 @@
+ruff
+pytest
diff --git a/requirements.txt b/requirements.txt
new file mode 100644
index 0000000..0ec7a8f
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,6 @@
+numpy
+opencv-python
+colour-science
+scipy
+matplotlib
+pandas
diff --git a/ruff.toml b/ruff.toml
new file mode 100644
index 0000000..1da7bbf
--- /dev/null
+++ b/ruff.toml
@@ -0,0 +1,8 @@
+line-length = 88
+target-version = "py311"
+
+[format]
+quote-style = "double"
+
+[lint]
+select = ["E", "F", "I", "W"]