C:/Users/kawag/work/ 配下に構築された全36プロジェクトの横断分析。医療・介護DXを中心に、臨床評価・業務効率化・学会運営・CRMまで幅広い領域をカバーする。

カテゴリ別プロジェクト一覧

医療・リハビリ評価ツール（8件）

学会・論文管理（2件）

人事・スタッフ管理（3件）

営業・CRM（1件）

調査・アンケート（2件）

医療サポートツール（3件）

データ分析・モニタリング（1件）

インフラ・自動化（2件）

デザインシステム（2件）

静的サイト（1件）

その他（データ分析・ツール類）

• cci-calculator — CCI計算ツール（Vercel: cci-calculator-ecru.vercel.app）
• dashboard_deploy — 経営ダッシュボード生成バッチ
• care-prevention-c_analysis — 介護予防C型フレイル改善解析（R/Python）

技術スタック分析

フレームワーク分布

バックエンド/DB分布

デプロイ先分布

AI統合

アーキテクチャパターン

1. 標準パターン: Next.js + Supabase + Vercel（最多）
2. Firebase統合: Vite/Next.js + Firebase（認証・DB・Hosting一体型）
3. エッジ軽量: Cloudflare Workers/Pages + D1（コスト最小化）
4. PWA: nurse-expense-app, docu-scan（モバイルファースト）
5. オフラインファースト: VoiceClip, productivity-health-survey（データ外部送信なし）

セキュリティ共通要件

• 全プロジェクトで .env 管理必須（Gitコミット禁止）
• 医療データ関連は RLS（Row Level Security）必須
• 患者情報を扱うプロジェクトはオフラインまたは匿名化必須
• CSP（Content-Security-Policy）ヘッダー設定

関連ページ

• 事業概要 — 全事業の位置づけ
• endai-system — 最大規模プロジェクト
• 川口脳神経外科リハビリクリニック — 臨床ツールの利用主体
• 枚方市BPO — データ分析プロジェクトの発注元

フレイルとリハマネ加算の関係は、「対象者像（誰に）」と「提供の仕組み（どう届け・算定するか）」の関係である。

関係の構造

4つの接点

1. 対象者の流入経路

KCL等でフレイルと判定された高齢者が、介護予防・訪問リハビリの対象となる。

2. 計画策定の義務

リハマネ加算(B)では、多職種によるリハビリテーション会議でフレイル状態に応じた計画を策定する。

3. 評価指標の連動

LIFEへのデータ提出（FIM、Barthel Index等）がフレイル改善の定量的エビデンスとなる。

4. 事業の接続

川口脳神経外科リハビリクリニックでは、介護予防C型事業（フレイル改善プログラム）と訪問リハビリ（リハマネ加算算定）が連続したサービスとして機能する。

事業における位置づけ

事業概要の「臨床サービス」の柱において、フレイルは対象者定義、リハマネ加算は収益・品質管理の根幹を担う。両者は切り離せない関係にある。

関連ページ

• フレイル — 対象者の状態像の定義と評価
• リハマネ加算 — 算定制度の詳細
• 川口脳神経外科リハビリクリニック — 実施主体
• 事業概要 — 全体像における位置づけ

本Wikiが対象とする事業体は、医療法人と株式会社の2法人で構成される。臨床（訪問リハビリ）・研究（フレイル改善解析）・DX（SaaS/BPO）を三位一体で展開し、高齢者医療・介護領域のDXを推進する。

法人構成

医療法人

• 施設名: 川口脳神経外科リハビリクリニック
• 所在地: 大阪府枚方市・寝屋川市
• 主要事業: 訪問リハビリテーション
• 収益基盤: 介護保険（リハマネ加算等）・医療保険（疾患別リハ）

株式会社

• 事業領域:
• DXコンサルティング
• 枚方市BPO（自治体向けデータ分析）
• 介護施設向けSaaS開発
• LINE CRM開発

事業の3つの柱

1. 臨床サービス（医療法人）

• 訪問リハビリテーションの提供
• 脳神経外科領域の専門性を活かした在宅リハビリ
• リハマネ加算に基づくPDCAサイクルの実践

2. 臨床研究

• フレイル改善プログラムの効果検証
• 介護予防C型事業のデータ分析
• 統計手法: GEE、GLMM、ロジスティック回帰
• 学会発表（日本公衆衛生学会、日本地域理学療法学会）

3. DX/テクノロジー（株式会社）

• 技術スタック: Next.js 15、Supabase、Vercel、Stripe
• 開発ツール: Claude Code、MCP連携、n8n
• 自治体向けBPO・SaaS・LINE CRMの開発・運用

規制環境

• 介護保険法: リハビリサービスの算定根拠
• 個人情報保護法: 患者データの取り扱い
• GL6.0: 医療情報システムの安全管理に関するガイドライン
• 診療報酬改定: 定期的な制度変更への対応

競合優位性

• 臨床現場を持つ法人がDXを自社開発 → 現場課題の直接的な解決
• データ分析能力（R/Python）と臨床知識の両方を保有
• 自治体との協働実績による信頼

今後の方向性

• 介護予防事業のエビデンス蓄積と学会発表
• SaaSプロダクトの本格展開
• LINE CRMによる患者エンゲージメント強化

関連ページ

• 川口脳神経外科リハビリクリニック — 医療法人の中核施設
• 枚方市BPO — 自治体向けDX事業
• フレイル — 臨床研究の中心テーマ
• リハマネ加算 — 収益の主要算定根拠

Firebaseには「ブラウザ用の道具」と「サーバー用の道具」がある。この2つの違いを理解すると、Firebaseプロジェクトのコードが読めるようになる。

たとえ話で理解する

Client SDK = 「生徒の学生証」

生徒（ブラウザ）が学生証（Client SDK）を使って図書室（Firestore）に入る。学生証には「何年何組のだれか」が書いてあるので、図書室のルール（Security Rules）が「この生徒は何の本を借りていいか」を判定する。

Admin SDK = 「校長先生の鍵束」

校長先生（サーバー）は鍵束（Admin SDK）で図書室の裏口から入れる。ルール（Security Rules）を完全に無視できる。全部の本を見れるし、生徒の借り出し記録も変更できる。

Client SDK（ブラウザで使う）

初期化

// nurse-expense-app: src/lib/firebase.ts
import { initializeApp, getApps } from "firebase/app";
import { getAuth } from "firebase/auth";
import { getFirestore } from "firebase/firestore";

// Firebase の設定（環境変数から取得）
const firebaseConfig = {
apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
// ...
};

// 同じアプリが何度も作られないようにチェック
// （Reactは再レンダリングで何度もこのコードを実行するから）
if (!firebaseConfig.apiKey) return null;  // ビルド時は環境変数がない
const app = getApps().length > 0 ? getApps()[0] : initializeApp(firebaseConfig);

export const auth = getAuth(app);     // ログイン/ログアウト用
export const db = getFirestore(app);  // データベース読み書き用

ログイン状態の監視（onAuthStateChanged）

// bento_order_web: src/contexts/AuthContext.tsx の仕組み

// 「ログイン状態が変わったら教えて」と登録する
const unsubscribe = onAuthStateChanged(auth, async (fbUser) => {
// fbUser が null → ログアウト状態
// fbUser がある → ログイン状態
  
if (fbUser) {
// Firestoreから追加情報を取得（名前、権限など）
const userData = await getUserData(fbUser.uid);
setUser(userData);
} else {
setUser(null);
}
});

// コンポーネントが消える時に監視を解除（メモリリーク防止）
return () => unsubscribe();

なぜuseEffectの中で使うか？: onAuthStateChangedは「ずっと見張り続ける」仕組み。コンポーネントが表示された時に監視を開始し、消える時に解除する。これがReactのuseEffectの役割。

リアルタイム監視（onSnapshot）

// bento_order_web: src/services/firestore.ts

// 「メニューが変わったら教えて」と登録する
export function subscribeToMenuItems(callback) {
const q = query(collection(db, "menu_items"), orderBy("createdAt", "desc"));
  
// onSnapshot = データが変わるたびに自動で呼ばれる
return onSnapshot(q, (snapshot) => {
const items = snapshot.docs.map(doc => ({
id: doc.id,
...doc.data()
}));
callback(items);  // 新しいデータでUIを更新
});
}

普通のデータ取得（getDocs）との違い:

• getDocs = 1回だけ取得して終わり（写真を撮る）
• onSnapshot = 変更があるたびに自動更新（ライブカメラ）

bento_order_webでは注文がリアルタイムで更新されるので、onSnapshotを使っている。

Admin SDK（サーバーで使う）

visitcareでの使い方

// visitcare: src/app/actions/auth.ts（Server Actions内）
"use server";

// Admin SDK はサーバーでしか動かない
import { getFirestore } from "firebase-admin/firestore";

export async function updatePatientRecord(patientId, data) {
const db = getFirestore();
  
// トランザクション = 「途中で失敗したら全部なかったことにする」仕組み
await db.runTransaction(async (transaction) => {
const patientRef = db.doc(patients/${patientId});
const patient = await transaction.get(patientRef);
    
if (!patient.exists) {
throw new Error("患者が見つかりません");
}
    
// 更新（トランザクション内なので、途中で他の人が同じデータを
// 変更しようとしたら、やり直しになる）
transaction.update(patientRef, {
...data,
updatedAt: new Date(),
});
});
}

Security Rules = データベースの門番

Client SDKを使う時は、Security Rulesがデータを守る。

// bento_order_web: firestore.rules

rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
    
// 注文データ: ログインユーザーだけ読み書きできる
match /orders/{orderId} {
allow read: if request.auth != null;
allow create: if request.auth != null
&& request.auth.uid == request.resource.data.userId;
// ↑ 自分のユーザーIDが入った注文だけ作れる（なりすまし防止）
}
    
// メニュー: 誰でも読める、管理者だけ書ける
match /menu_items/{itemId} {
allow read: if true;
allow write: if request.auth != null
&& get(/databases/$(database)/documents/users/$(request.auth.uid)).data.isAdmin == true;
}
}
}

読み方:

• request.auth != null → ログインしている
• request.auth.uid → ログインしている人のID
• allow read: if 条件 → 条件がTRUEならデータを読める
• allow write: if 条件 → 条件がTRUEならデータを書ける

Client SDK vs Admin SDK の使い分け

質問: そのコードはどこで動く？

→ ブラウザ（React コンポーネントの中）
→ Client SDK ✅
→ Security Rulesがデータを守る
    
→ サーバー（Server Actions, API Routes）
→ Admin SDK ✅
→ Security Rulesをバイパスできる（= 自分でチェックする責任がある）

Supabaseとの比較

関連ページ

• bento_order_web — Client SDK + onSnapshot の典型例
• nurse-expense-app — Client SDK + GAS連携
• drawing-cognitive-test — 生体情報保護のSecurity Rules
• Middleware認証パターン — サーバー側の認証との組み合わせ
• Supabase-RLSとService-Role — Supabase版の同等機能

Middlewareは、ユーザーがページを開く「前」に動くコード。「この人はこのページを見ていいか？」を入口でチェックする門番のような存在。

たとえ話で理解する

Middleware = 「ビルの警備員」

ビル（Webアプリ）に入ろうとする人を、入口（Middleware）で警備員がチェックする。

来訪者が入口に来る
→ 警備員「IDカードを見せてください」
→ IDカードなし → 「ログインページに行ってください」（リダイレクト）
→ IDカードあり → 「何階に行きますか？」
→ 3階（管理者エリア）→ 「管理者IDですか？」
→ YES → 通す
→ NO  → 「ダッシュボードに戻ってください」（リダイレクト）
→ 1階（一般エリア）→ 通す

2つの認証レイヤー

認証は「二重ロック」で守る。Middlewareだけに頼ると危険。

第1層: Middleware（入口の門番）
→ ページに到達する前にチェック
→ 画面遷移をブロック・リダイレクト
→ 「見せない」ことで守る

第2層: Server Actions / API Routes内のチェック（金庫の鍵）
→ データを操作する直前にチェック
→ 万が一Middlewareをすり抜けても、データは守られる
→ 「触らせない」ことで守る

なぜ二重にするか？: Middlewareは「ページを見せるかどうか」しか制御できない。ブラウザの開発者ツールから直接APIを叩かれたら、Middlewareは通らない。

endai-systemの実装

第1層: middleware.ts（ページレベルの門番）

// endai-system: middleware.ts の考え方

// 「どのページに何のロール（役割）が必要か」を定義
const ADMIN_PATHS = ["/admin"];      // 管理者だけ
const REVIEWER_PATHS = ["/review"];  // 査読者以上
const AUTH_PATHS = ["/dashboard"];   // ログインしていればOK

// ロール（役割）の強さの順番
const ROLE_HIERARCHY = {
admin: 4,       // 管理者（一番強い）
organizer: 3,   // 運営者
reviewer: 2,    // 査読者
author: 1,      // 著者（一番弱い）
};

// 実際のチェック処理
export async function middleware(request) {
// 1. ログインしているか確認
const user = await getUser(request);
  
if (!user) {
// ログインしていない → ログインページへ
return NextResponse.redirect("/login");
}
  
// 2. そのページに必要なロールを持っているか確認
if (isAdminPage && userRoleLevel < ROLE_HIERARCHY.organizer) {
// 管理者ページに一般ユーザーが来た → ダッシュボードへ
return NextResponse.redirect("/dashboard");
}
  
// 3. OK → そのまま通す
return NextResponse.next();
}

第2層: requireRole()（データレベルの金庫）

// endai-system: src/lib/auth.ts
"use server";

// ロールの強さの順番（Middlewareと同じ定義を持つ）
const ROLE_HIERARCHY = {
admin: 4, organizer: 3, reviewer: 2, author: 1
};

// 「この操作には最低○○のロールが必要」をチェックする関数
export async function requireRole(minimumRole: UserRole) {
// 1. Supabaseからログインユーザー情報を取得
const supabase = await createClient();
const { data: { user } } = await supabase.auth.getUser();
  
if (!user) {
throw new Error("認証エラー: ログインが必要です");
}
  
// 2. そのユーザーのロール（役割）をDBから取得
const { data: profile } = await supabase
.from("profiles").select("role").eq("id", user.id).single();
  
const userRole = profile?.role || "author";
  
// 3. ロールの強さを比較
if (ROLE_HIERARCHY[userRole] < ROLE_HIERARCHY[minimumRole]) {
throw new Error("権限エラー: この操作には権限がありません");
}
  
return { user, role: userRole };
}

使い方:

// Server Action内で使う
"use server";
export async function deleteAbstract(id: string) {
// 管理者以上でないと削除できない
await requireRole("organizer");
// ... 削除処理
}

Firebase版の認証パターン（bento_order_web）

bento_order_webはVite+Reactなので、Middlewareがない。代わりにReact Contextでブラウザ側で管理する。

// bento_order_web: src/contexts/AuthContext.tsx の考え方

// 「ログイン状態が変わったら教えてね」とFirebaseに頼む
useEffect(() => {
const unsubscribe = onAuthChange(async (fbUser) => {
if (fbUser) {
// ログインした → ユーザー情報をDBから取得
const userData = await getUserData(fbUser.uid);
setUser(userData);  // アプリ全体に共有
} else {
// ログアウトした
setUser(null);
}
setLoading(false);
});
return unsubscribe;  // クリーンアップ
}, []);

⚠️ 要確認：ブラウザ側のチェックだけでは不十分。Firestore Security Rulesが第2層の役割を果たしている。

プロジェクト別の認証パターン

まとめ: 認証設計の判断基準

質問1: ロール（役割）が複数ある？
→ YES → middleware.ts でページレベルの制御が必要
→ NO  → middleware不要（Firebase Rulesで十分）

質問2: Next.jsを使っている？
→ YES → Server Actions内でも requireRole() / requireAuth() でチェック
→ NO  → Firestore Security Rules / Supabase RLS に頼る

質問3: 外部サービスからのアクセスがある？
→ YES → API Routes内で署名検証（line-crmパターン）
→ NO  → 通常の認証フローでOK

関連ページ

• endai-system — middleware.ts + requireRole() の二重認証
• Server-Actionsの仕組み — Server Actions内での認証チェック
• Supabase-RLSとService-Role — データベースレベルの保護
• Firebase認証パターン — Firebase Authの仕組み

Server ActionsとAPI Routesは、どちらも「サーバー側で動くコード」だが、役割が違う。この2つの使い分けが、Next.jsプロジェクトの設計の基本になる。

たとえ話で理解する

Server Actions = 「教室の先生に直接質問する」

教室（ブラウザ）にいる生徒（ユーザー）が、先生（サーバー）に直接手を挙げて質問する。先生はその場で答えを返す。教室の中だけの会話。

ボタンを押す → サーバーが処理する → 結果が画面に反映される

API Routes = 「学校の受付窓口」

学校の受付窓口（URL）があって、誰でもそこに来れば対応してもらえる。生徒だけでなく、郵便屋さん（外部サービス）や他の学校（別のアプリ）も使える。

HTTPリクエスト → サーバーが処理する → JSONを返す

実際のコードで見る

Server Actions（endai-systemの例）

endai-systemでは40以上のServer Actionsがある（src/lib/actions/）。

// ファイルの先頭に "use server" と書くだけで、サーバーで動くコードになる
"use server";

// 演題を保存するServer Action
export async function saveAbstract(data: FormData) {
// 1. ログイン確認（サーバー側で安全にチェック）
const { user } = await requireAuth();
  
// 2. データを検証（おかしなデータを弾く）
const parsed = abstractSchema.safeParse(data);
if (!parsed.success) {
return { error: "入力内容に問題があります" };
}
  
// 3. データベースに保存
const supabase = await createClient();
await supabase.from("abstracts").insert({ ...parsed.data, author_id: user.id });
  
return { success: "保存しました" };
}

ポイント: ブラウザから関数を直接呼ぶように見えるが、実際にはNext.jsが裏でHTTPリクエストに変換している。

API Routes（line-crmの例）

line-crmではServer Actionsを使わず、API Routesだけで動いている。

// app/api/webhook/line/route.ts
export async function POST(request: Request) {
// 1. LINEから送られてきたデータを受け取る
const body = await request.text();
const signature = request.headers.get("x-line-signature")!;
  
// 2. 本当にLINEから来たか確認（署名検証）
const isValid = await verifySignature(body, signature);
if (!isValid) {
return new Response("不正なリクエスト", { status: 401 });
}
  
// 3. メッセージを処理
const events = JSON.parse(body).events;
// ... イベント処理
  
return new Response("OK");
}

ポイント: LINEのサーバーが呼び出す「窓口」なので、API Routesでないと対応できない。

いつどちらを使うか？（判断基準）

質問: そのコードを呼び出すのは誰？

→ 自分のアプリのブラウザ画面だけ
→ Server Actions を使う ✅
    
→ 外部サービス（LINE, Stripe, GAS等）も呼び出す
→ API Routes を使う ✅
    
→ ファイルダウンロード（CSV, PDF等）を返したい
→ API Routes を使う ✅

プロジェクト別の実際の選択

よくある間違い

間違い1: 全部API Routesで書く

Server Actionsの方がコードが短くて安全。フォーム処理なら Server Actions 一択。

間違い2: Server Actionsで外部Webhook受信

外部サービスは「URL」にリクエストを送るので、Server Actionsでは受け取れない。

間違い3: "use server" の書き忘れ

ファイルの先頭に "use server" がないと、ブラウザで動いてしまう（秘密の情報が漏れる危険）。

endai-system特有の制約（Next.js 16 Turbopack）

// ❌ ダメ: re-exportは禁止
"use server";
export { foo } from "./other";

// ✅ OK: import してから export
"use server";
import { foo } from "./other";
export { foo };

関連ページ

• endai-system — Server Actions を最も多く使うプロジェクト
• line-crm — API Routes のみで構築したプロジェクト
• Middleware認証パターン — Server Actions と組み合わせる認証
• Webアプリポートフォリオ — 全プロジェクトの技術選択一覧

Supabaseのデータベースには「誰がどのデータを見れるか」を制御する仕組みがある。これがRLS（Row Level Security）。そしてRLSを「無視」できる特別な鍵がService Role Key。

たとえ話で理解する

RLS = 「自分のロッカーしか開けない鍵」

学校のロッカーを想像しよう。生徒Aは自分のロッカーだけ開けられる。生徒Bも自分のだけ。たとえハッカーが「全員のロッカーを開けろ」と命令しても、自分の鍵では自分のしか開かない。

-- 「自分のデータだけ読める」というルール
CREATE POLICY "自分のデータだけ読める"
ON abstracts FOR SELECT
USING (author_id = auth.uid());
  
-- auth.uid() = 今ログインしている人のID
-- ハッカーが全件取得しようとしても、自分のデータしか返ってこない

Service Role Key = 「校長先生のマスターキー」

校長先生は全員のロッカーを開けられる。でもこの鍵は校長室（サーバー）にしかない。生徒（ブラウザ）には絶対渡さない。

2種類のクライアントの使い分け

普通のクライアント（Anon Key）— ほとんどの場面で使う

// endai-system: src/lib/supabase/server.ts
export async function createClient() {
const cookieStore = await cookies();
return createServerClient(
SUPABASE_URL,
SUPABASE_ANON_KEY,  // ← 一般の鍵（RLSが効く）
{ cookies: { getAll() { return cookieStore.getAll(); }, ... } }
);
}

何が起きているか:

1. ユーザーのログイン情報（cookie）を読み取る
2. その情報でSupabaseに接続する
3. RLSが「このユーザーが見ていいデータ」だけ返す

Service Roleクライアント（マスターキー）— 特殊な場面だけ

// line-crm: lib/supabase/server.ts
export function createServiceClient() {
return createServerClient(
SUPABASE_URL,
SUPABASE_SERVICE_ROLE_KEY!,  // ← マスターキー（RLSを無視）
{ cookies: { getAll: () => [], setAll: () => {} } }  // cookieは不要
);
}

なぜcookieが空なのか: マスターキーで接続するので「誰がログインしているか」は関係ない。全データにアクセスできる。

いつService Role Keyを使うのか？

質問: そのデータ操作は「誰」がやっている？

→ ログイン中のユーザー本人
→ 普通のクライアント（Anon Key）✅
    
→ ユーザーではなく「システム」がやっている
→ Service Roleクライアント ✅

具体例: line-crmでなぜService Roleが必要か

1. 患者AがLINEで「明日休みます」とメッセージを送る

LINEのサーバーがline-crmのWebhookを呼ぶ
line-crmがメッセージをデータベースに保存したい


問題: この時「ログインしているユーザー」はいない！
LINEのサーバーが呼んでいるだけ。
普通のクライアントだとRLSで弾かれてしまう。

解決: Service Role Key（マスターキー）でRLSをバイパスする。

プロジェクト別の使い分け

プロジェクト	Anon Key	Service Role	理由
endai-system	✅	❌	全操作がログインユーザー経由
line-crm	✅	✅	Webhook（LINEサーバー経由）でDB書き込みが必要
visitcare	✅	❌	全操作がログインユーザー経由

絶対に守るルール

1. Service Role Keyをブラウザに渡さない

// ❌ 絶対ダメ: NEXT_PUBLIC_ で始まる環境変数はブラウザに見える
NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY=xxx

// ✅ OK: NEXT_PUBLIC_ なし → サーバーだけで使える
SUPABASE_SERVICE_ROLE_KEY=xxx

NEXT_PUBLIC_ がつくと、ブラウザのJavaScriptに含まれてしまう。マスターキーが全世界に公開される。

2. Service Roleクライアントを使う場所を限定する

OK な場所:

API Routes（app/api/の中）
Webhookハンドラ


NG な場所:

Server Components（必要ない）
Client Components（論外）
Server Actions（ログインユーザーがいるはず）

3. 環境変数の存在確認を起動時にやる

// endai-system のパターン（推奨）
const SUPABASE_URL = process.env.NEXT_PUBLIC_SUPABASE_URL;
if (!SUPABASE_URL) {
throw new Error("NEXT_PUBLIC_SUPABASE_URL が未設定です");
}
// → 設定忘れをデプロイ前に気づける

RLSポリシーの読み方

-- endai-systemの例: 演題テーブルのRLS
-- 「自分が著者の演題だけ読める」
CREATE POLICY "著者は自分の演題を読める"
ON abstracts FOR SELECT
USING (author_id = auth.uid());

-- 「管理者は全部読める」
CREATE POLICY "管理者は全演題を読める"
ON abstracts FOR SELECT
USING (
EXISTS (
SELECT 1 FROM profiles
WHERE profiles.id = auth.uid()
AND profiles.role IN ('admin', 'organizer')
)
);

読み方: USING (条件) の条件がTRUEのデータだけ見える/操作できる。

関連ページ

• endai-system — Anon Keyのみ使用、RLSでデータ保護
• line-crm — Service Role Key使用（Webhook処理のため）
• visitcare — 患者データのRLS保護
• Server-Actionsの仕組み — Server Actions内でのSupabaseクライアント使用

テストは「コードが正しく動いているか自動で確認する仕組み」。手動で毎回ボタンを押して確認する代わりに、コンピュータが代わりにチェックしてくれる。

たとえ話で理解する

Unitテスト = 「部品の検品」

車を組み立てる前に、エンジン、タイヤ、ブレーキなどの部品を1つずつ検品する。部品（関数）が単体で正しく動くか確認する。

// 「消費税を計算する関数」のテスト
test("1000円の10%は100円", () => {
expect(calcTax(1000, 0.1)).toBe(100);
});

test("0円なら税金も0円", () => {
expect(calcTax(0, 0.1)).toBe(0);
});

E2Eテスト = 「完成車の試乗」

組み立てた車を実際に道路で走らせる。エンジンかけて、ハンドル切って、ブレーキ踏んで。ユーザーと同じ操作を自動で再現する。

// 「ログインしてダッシュボードが表示される」テスト
test("ログインできる", async ({ page }) => {
await page.goto("/login");
await page.fill('[name="email"]', "test@example.com");
await page.fill('[name="password"]', "password123");
await page.click('button[type="submit"]');
  
// ダッシュボードに遷移したか確認
await expect(page).toHaveURL("/dashboard");
await expect(page.locator("h1")).toContainText("ダッシュボード");
});

セキュリティテスト = 「防犯テスト」

泥棒（ハッカー）のフリをして、家（アプリ）に侵入できないか試す。

# endai-system: npm run security-check
# → APIキーがコードに直書きされていないか
# → SQLインジェクション（悪意のあるSQL）が入り込めないか
# → ログイン情報が漏れる場所がないか

3種類のテストの関係（テストピラミッド）

        /\
/  \      E2Eテスト（少数・遅い・高コスト）
/    \     → 全体が動くか確認
/------\
/        \   Integrationテスト（中程度）
/          \  → 複数の部品が組み合わさって動くか
/------------\
/              \ Unitテスト（多数・速い・低コスト）
/________________\ → 部品が1つずつ正しいか

下（Unit）ほどたくさん書く。上（E2E）は重要な操作だけ。

実際のプロジェクトでのテスト

endai-system（最も充実）

endai-system/
├── e2e/                    # E2Eテスト（Playwright）
│   ├── auth.spec.ts        # ログイン・ログアウト
│   ├── abstract.spec.ts    # 演題の登録・編集・削除
│   └── ... (30+ ファイル)
├── src/lib/**/*.spec.ts    # Unitテスト（Vitest）
│   ├── auth.spec.ts        # 認証関数のテスト
│   └── validations/*.spec.ts # バリデーションのテスト
└── scripts/
└── security-review.sh  # セキュリティチェック一括実行

実行コマンド:

# Unitテスト（速い・頻繁に実行）
npx vitest run

# E2Eテスト（遅い・デプロイ前に実行）
npx playwright test

# セキュリティチェック（デプロイ前に実行）
npm run security-check

bento_order_web（E2Eのみ）

bento_order_web/
└── e2e/
├── tests/     # テストファイル
└── pages/     # Page Object Model

Page Object Model（POM）とは: テストコードを「ページごとのクラス」にまとめるパターン。UIが変わった時に修正箇所が1箇所で済む。

// Page Object（ページの操作をまとめたクラス）
class LoginPage {
constructor(private page: Page) {}
  
async login(email: string, password: string) {
await this.page.fill('[name="email"]', email);
await this.page.fill('[name="password"]', password);
await this.page.click('button[type="submit"]');
}
}

// テスト（Page Objectを使うと読みやすい）
test("ログインできる", async ({ page }) => {
const loginPage = new LoginPage(page);
await loginPage.login("test@example.com", "pass123");
// ...
});

デプロイ前のCSPチェック（重要）

CSP（Content Security Policy）= ブラウザに「どこからのスクリプト/データを許可するか」を伝えるルール。ビルド（tsc/vite build）では検出できないため、ブラウザで実行して初めて分かる。

// Playwrightでコンソールエラーを検出する
test("CSPエラーがないこと", async ({ page }) => {
const errors = [];
  
// コンソールのエラーを全部記録
page.on("console", msg => {
if (msg.type() === "error") errors.push(msg.text());
});
page.on("pageerror", err => errors.push(err.message));
  
// ページを開く
await page.goto("http://localhost:3000");
  
// エラーが0件であることを確認
expect(errors).toHaveLength(0);
});

過去の事故例:

→ 全部Playwrightでブラウザ実行しないと見つからない

テストの書き方の判断基準

質問1: 何をテストしたい？

→ 関数の計算結果・バリデーション
→ Unitテスト（Vitest）✅
    
→ ユーザーの操作（ログイン→注文→確認）
→ E2Eテスト（Playwright）✅
    
→ セキュリティ（APIキー漏れ、SQLインジェクション）
→ セキュリティチェック（Semgrep + ESLint）✅

質問2: いつテストを実行する？

→ コードを書いた直後（頻繁）
→ Unitテスト ✅（数秒で終わる）
    
→ コミット/プッシュ前
→ Unitテスト + E2Eテスト ✅
    
→ デプロイ前
→ 全部 + CSPチェック + セキュリティチェック ✅

プロジェクト別のテスト状況

⚠️ 要確認：line-crm, visitcare, nurse-expense-appにはテストがない。特にline-crmはWebhookの署名検証テストが重要。

関連ページ

• endai-system — 最もテストが充実したプロジェクト
• bento_order_web — E2E + CSPチェックの実装例
• Webアプリポートフォリオ — 全プロジェクトのテスト状況

フレイル (Frailty) は、加齢に伴い心身の活力（運動機能、認知機能等）が低下し、要介護状態に至る前段階の状態を指す。適切な介入により改善・進行抑制が可能であることが特徴。

定義と分類

Friedの表現型モデル (Phenotype Model)

以下の5項目中3項目以上該当でフレイル、1-2項目でプレフレイル:

1. 体重減少 — 意図しない体重減少（6か月で2-3kg以上）
2. 疲労感 — 主観的な疲労の訴え
3. 活動量低下 — 身体活動レベルの低下
4. 歩行速度低下 — 通常歩行速度の低下
5. 握力低下 — 握力の低下

基本チェックリスト (KCL: Kihon Checklist)

• 日本の介護予防事業で広く使用される25項目の質問紙
• 運動機能、栄養、口腔機能、閉じこもり、認知機能、うつの6領域+総合
• カットオフ: 総合7点以上でフレイル該当

サルコペニア (Sarcopenia) との関係

• サルコペニア = 加齢性筋肉減少症（筋量・筋力・身体機能の低下）
• フレイルの身体的側面の主要因がサルコペニア
• AWGS2019基準: 握力（男性<28kg, 女性<18kg）+ 歩行速度(<1.0m/s)

評価指標

指標	種類	用途
KCL (基本チェックリスト)	質問紙	介護予防スクリーニング
Friedの5項目	身体測定+質問	研究でのフレイル判定
BREQ-3	質問紙	運動動機づけ評価
握力・歩行速度	身体測定	サルコペニア/フレイル判定
2ステップテスト	身体測定	歩行機能評価

統計的分析手法

フレイル関連研究で使用される主な手法:

• GEE (一般化推定方程式) — 反復測定データの群間比較。対象者内の相関を考慮
• GLMM (一般化線形混合モデル) — ランダム効果を含む縦断解析
• ロジスティック回帰 — フレイル該当/非該当の二値アウトカム解析

介護予防事業との関連

• 介護予防・日常生活支援総合事業のC型（短期集中予防サービス）でフレイル改善を目指す
• 川口脳神経外科リハビリクリニックが枚方市で実施するC型事業でのデータ蓄積
• KCLレスポンダー（改善者）の特徴抽出が今後の課題

関連ページ

• リハマネ加算 — フレイル高齢者へのリハビリ提供の算定根拠
• 川口脳神経外科リハビリクリニック — フレイル改善事業の実施主体
• 枚方市BPO — フレイル評価データの分析事業
• 事業概要 — フレイル関連事業の位置づけ

リハビリテーションマネジメント加算（リハマネ加算）は、介護保険サービスにおいてリハビリテーションの質を担保するための加算制度である。多職種連携による計画策定と定期的な見直しを要件とする。

制度概要

• 根拠法令: 介護保険法に基づく介護報酬
• 対象サービス: 訪問リハビリテーション、通所リハビリテーション
• 目的: PDCA サイクルに基づくリハビリテーションの質の向上

加算区分（令和6年度改定）

⚠️ 要確認：令和8年度改定で加算体系が変更される可能性あり。最新の告示を確認すること。

リハマネ加算(A)

• 要件: リハビリテーション計画の作成、医師の詳細な指示
• 算定: 月1回

リハマネ加算(B)

• 要件: (A)の要件に加え、リハビリテーション会議の開催、関係者への計画書交付
• 算定: 月1回
• リハビリテーション会議: 医師・PT/OT/ST・ケアマネジャー・サービス事業者等が参加

算定要件の主なポイント

1. リハビリテーション実施計画書の作成
2. 別紙様式2-1（リハビリテーション実施計画書）を使用
3. 医師の指示のもとPT/OT/STが作成
4. 本人・家族への説明と同意
1. リハビリテーション会議
2. 原則3か月に1回以上開催
3. ICTを活用したリモート参加も可
4. 会議録の作成と保管
1. LIFE（科学的介護情報システム）へのデータ提出
2. 対象加算によりLIFEへのデータ提出が要件化
3. FIM、Barthel Index等の評価データ

疾患別リハビリテーションとの関係

• 医療保険の疾患別リハ（脳血管疾患等リハI-III）から介護保険リハへの移行時に重要
• 移行期のリハビリテーション計画の連続性を確保
• 川口脳神経外科リハビリクリニックでは脳神経外科領域の疾患別リハからの移行を多く担当

フレイル高齢者への適用

• フレイル状態の高齢者は訪問リハビリの主要対象
• KCL等のスクリーニングで該当した対象者へのリハビリ計画策定
• 短期集中リハと維持期リハの使い分けが重要

関連ページ

• 川口脳神経外科リハビリクリニック — リハマネ加算を算定する訪問リハビリ事業所
• フレイル — リハビリ対象となる高齢者の状態像
• 事業概要 — リハビリ事業の経営的位置づけ

外部サービス（LINE、Google Apps Script、Claude API等）とWebアプリを繋ぐパターン。大きく分けて「こちらから呼ぶ」と「向こうから呼ばれる」の2種類がある。

たとえ話で理解する

こちらから呼ぶ = 「電話をかける」

自分から相手に電話をかけて、答えを聞く。

docu-scan → Claude Vision APIに画像を送る → 文字認識結果を受け取る

向こうから呼ばれる = 「電話がかかってくる」（Webhook）

相手から突然電話がかかってくる。受話器を取る人（API Route）が必要。

患者がLINEで「明日休みます」→ LINEサーバー → line-crmのWebhookに通知

パターン1: こちらから呼ぶ（API Call）

Claude API（endai-systemの例）

// endai-system: src/lib/claude-client.ts の考え方

// 1. 患者名などの個人情報を取り除く（匿名化）
const { anonymizedText } = anonymize(abstractBody, speakerNames);

// 2. Claude APIに送る
const response = await fetch("https://api.anthropic.com/v1/messages", {
method: "POST",
headers: {
"x-api-key": process.env.ANTHROPIC_API_KEY!,  // サーバーだけが持つ鍵
"content-type": "application/json",
},
body: JSON.stringify({
model: "claude-sonnet-4-6-20250514",
messages: [{ role: "user", content: anonymizedText }],
}),
});

// 3. 結果を受け取る
const result = await response.json();

重要なポイント:

• APIキーはサーバーだけに置く（NEXT_PUBLIC_ をつけない）
• 個人情報は送る前に取り除く（匿名化）
• エラーが起きた時の対処（リトライ、タイムアウト）を入れる

Google Apps Script（nurse-expense-appの例）

// nurse-expense-app の仕組み

// ブラウザ → GAS（Google Apps Script）→ Gemini Vision API

// 1. ブラウザから撮影画像をGASに送る
const response = await fetch(process.env.NEXT_PUBLIC_GAS_OCR_URL!, {
method: "POST",
body: JSON.stringify({ image: base64Image }),
});

// 2. GAS側（gas/ocr.gs）でGeminiを呼ぶ
//    なぜGAS経由？ → Gemini APIキーをブラウザに持たせたくないから
//    GASは無料でサーバーの役割を果たしてくれる

// 3. GASが結果を返す
const ocrResult = await response.json();
// { amount: 1500, date: "2026-04-01", store: "コンビニA" }

なぜGAS経由にするか？:

直接呼ぶ場合（❌ 危険）:
ブラウザ → Gemini API（APIキーがブラウザに見える！）

GAS経由（✅ 安全）:
ブラウザ → GAS（APIキーはGAS内に隠れている）→ Gemini API

パターン2: 向こうから呼ばれる（Webhook）

LINE Webhook（line-crmの例）

患者がLINEでメッセージを送る
→ LINEのサーバーが line-crm の /api/webhook/line に POST する
→ line-crm が受け取って処理する

ステップ1: 本物のLINEからの通知か確認する（署名検証）

// line-crm: lib/line/webhook.ts

export async function verifySignature(body: string, signature: string) {
const secret = process.env.LINE_CHANNEL_SECRET!;
  
// 「body（メッセージ内容）」と「secret（秘密の鍵）」を
// 混ぜ合わせて暗号化したものが、LINEが送ってきた signature と一致するか確認
  
const encoder = new TextEncoder();
const key = await crypto.subtle.importKey(
"raw", encoder.encode(secret),
{ name: "HMAC", hash: "SHA-256" }, false, ["sign"]
);
  
const signatureBuffer = await crypto.subtle.sign(
"HMAC", key, encoder.encode(body)
);
  
const computed = btoa(String.fromCharCode(...new Uint8Array(signatureBuffer)));
  
return computed === signature;  // 一致すればLINE本物
}

なぜ署名検証が必要か？: 悪意のある人が「LINEのふりをして」偽のメッセージを送ってくる可能性がある。署名検証で「本当にLINEから来たのか」を確認する。 署名検証のたとえ: 手紙に蝋印（ろういん）が押してあるようなもの。蝋印のデザイン（secret）を知っているのはLINEと自分だけ。偽物は同じ蝋印を作れない。

ステップ2: メッセージを処理する

// line-crm: app/api/webhook/line/route.ts

export async function POST(request: Request) {
const body = await request.text();
const signature = request.headers.get("x-line-signature")!;
  
// 署名検証
if (!await verifySignature(body, signature)) {
return new Response("不正", { status: 401 });
}
  
// イベントを処理
const { events } = JSON.parse(body);
for (const event of events) {
if (event.type === "message" && event.message?.type === "text") {
// テキストメッセージを受信した
await handleTextMessage(event);
}
if (event.type === "follow") {
// 友だち追加された
await handleFollow(event);
}
}
  
return new Response("OK");
}

パターン3: ブラウザ → GAS → スプレッドシート

docu-scan の流れ:

スマホで書類を撮影
Claude Vision APIで文字を読み取る
読み取ったデータをGASに送る
GASがスプレッドシートに書き込む


nurse-expense-app の流れ:

スマホで領収書を撮影
GASに画像を送る
GAS内でGemini Visionが文字を読み取る
結果をブラウザに返す

統合パターンの判断基準

質問1: 自分のアプリから外部サービスを呼ぶ？ それとも外部サービスから呼ばれる？

→ 自分から呼ぶ
→ APIキーが必要？
→ YES → サーバー側（Server Actions / API Routes）から呼ぶ
→ NO  → ブラウザから直接呼んでもOK
    
→ 外部から呼ばれる（Webhook）
→ API Routes で受け口を作る
→ 署名検証を必ず入れる
→ Service Role Key で DB書き込み（ログインユーザーがいないから）

質問2: 無料でサーバー処理したい？
→ GAS WebApp を中継サーバーとして使う（nurse-expense-appパターン）

プロジェクト別の外部API統合

関連ページ

• line-crm — Webhook署名検証の実装例
• docu-scan — Claude Vision API統合
• nurse-expense-app — GAS経由のGemini統合
• endai-system — Claude API統合（匿名化付き）
• Server-Actionsの仕組み — サーバー側のコード実行

Reactアプリで「データをどこに持つか」を決めるのが状態管理。小さいアプリならuseStateで十分だが、アプリが大きくなると「どのコンポーネントからでもデータにアクセスしたい」問題が出てくる。

たとえ話で理解する

useState = 「自分の筆箱」

自分の机に置いてある筆箱。自分だけが使う。隣の席の人には見えない。

// ボタンを押した回数を数える（このコンポーネント内だけ）
const [count, setCount] = useState(0);

Context = 「教室の掲示板」

教室に貼ってある掲示板。教室にいる全員が見れる。でも隣の教室には見えない。

// AuthContextの例: 「今ログインしている人は誰か」を教室全体に共有
<AuthProvider>    {/* ← 掲示板を教室に設置 */}
<Header />      {/* ← ログインユーザー名を表示できる */}
<Sidebar />     {/* ← ログイン状態に応じてメニューを変えられる */}
<MainContent /> {/* ← ログインユーザーのデータを取得できる */}
</AuthProvider>

Zustand = 「学校の放送室」

放送室からアナウンスすると、全教室に聞こえる。教室（コンポーネント）をまたいで情報を共有できる。しかもContextよりセットアップが簡単。

// visitcareの例: 患者の選択状態をアプリ全体で共有
const usePatientStore = create((set) => ({
selectedPatient: null,
setPatient: (patient) => set({ selectedPatient: patient }),
}));

// どのコンポーネントからでも使える
function PatientHeader() {
const patient = usePatientStore(state => state.selectedPatient);
return <h1>{patient?.name}</h1>;
}

4つの選択肢と使い分け

1. useState — 1つのコンポーネント内で完結するデータ

// フォームの入力値、モーダルの開閉、ローディング状態など
const [isOpen, setIsOpen] = useState(false);
const [formData, setFormData] = useState({ name: "", email: "" });

使う場面: そのコンポーネントだけで使うデータ

2. React Context — アプリ全体で共有する「変わりにくい」データ

// bento_order_web: src/contexts/AuthContext.tsx
// ログインユーザー情報 = めったに変わらない → Context向き

const AuthContext = createContext(null);

export function AuthProvider({ children }) {
const [user, setUser] = useState(null);
// ... Firebase Auth 監視
return (
<AuthContext.Provider value={{ user, loading }}>
{children}
</AuthContext.Provider>
);
}

// 使う側
function ProfilePage() {
const { user } = useAuth();  // どこからでもユーザー情報にアクセス
return <p>{user.name}さん、こんにちは</p>;
}

使う場面: 認証情報、テーマ（ダークモード）、言語設定など 注意点: Contextの値が変わると、その中の全コンポーネントが再描画される。頻繁に変わるデータには向かない。

3. Zustand — アプリ全体で共有する「頻繁に変わる」データ

// visitcareのパターン
import { create } from "zustand";

// store（データの置き場）を定義
const usePatientStore = create((set) => ({
// データ
selectedPatient: null,
records: [],
  
// データを変更する関数
setPatient: (patient) => set({ selectedPatient: patient }),
addRecord: (record) => set((state) => ({
records: [...state.records, record]  // 既存の配列に追加（immutable）
})),
}));

Contextより優れている点:

• 値が変わっても、その値を使っているコンポーネントだけ再描画される
• Providerで包む必要がない（コードが短い）
• devtoolsで状態の変化を追跡できる

使う場面: 患者の選択状態、カートの中身、フィルター条件など

4. Server Components（データをサーバーで取得して渡す）

// endai-systemのパターン
// Server Component = サーバーで動く → データベースに直接アクセスできる

// app/dashboard/page.tsx（Server Component）
export default async function DashboardPage() {
// サーバーで直接データを取得（ブラウザには取得コードが送られない）
const supabase = await createClient();
const { data: abstracts } = await supabase.from("abstracts").select("*");
  
// 取得したデータをClient Componentに渡す
return <AbstractList abstracts={abstracts} />;
}

// components/AbstractList.tsx（Client Component）
"use client";
export function AbstractList({ abstracts }) {
// ブラウザで動くコード（フィルター、ソートなどのUI操作）
const [filter, setFilter] = useState("");
const filtered = abstracts.filter(a => a.title.includes(filter));
return <>{filtered.map(a => <div key={a.id}>{a.title}</div>)}</>;
}

使う場面: ページの初期データ読み込み。Next.js App Routerなら最初の選択肢。

判断フローチャート

そのデータは誰が使う？

→ 1つのコンポーネントだけ
→ useState ✅

→ 複数のコンポーネントで共有したい
→ Next.js App Router を使っている？
→ YES → まずServer Componentで取得してpropsで渡す ✅
→ それでも足りない場合（ユーザー操作で変わるデータ）
→ 頻繁に変わる → Zustand ✅
→ めったに変わらない → Context ✅
→ NO（Vite + React）
→ 認証情報 → Context ✅
→ それ以外 → Zustand ✅（アプリが大きいなら）
→ useState + props ✅（アプリが小さいなら）

プロジェクト別の実際の選択

パターン: Next.jsプロジェクトはServer Componentsが主力。Vite+ReactプロジェクトはContextが認証の中心。Zustandはvisitcareのように状態が複雑なプロジェクトで活躍。

関連ページ

• visitcare — Zustand を使用するプロジェクト
• bento_order_web — React Context パターンの典型
• endai-system — Server Components 中心の設計
• Server-Actionsの仕組み — サーバー側のデータ操作

VoiceClip-Onlineは、ブラウザベースの音声文字起こしアプリ。Web Speech APIとfaster-whisperのデュアルエンジンで、医療・リハビリ現場での記録を効率化する。

技術スタック

• フレームワーク: Vite + React 19 + TypeScript
• STTエンジン: Web Speech API（フォールバック）+ faster-whisper（高精度、Pythonバックエンド）
• 後処理: フィラー除去、句読点自動挿入
• デプロイ: Vercel

デュアルエンジン設計

• 通常はfaster-whisperを使用、接続不可時にWeb Speech APIへフォールバック

オフライン版

• VoiceClip（Pythonローカル版）は医療データを外部送信しない完全オフライン仕様
• 個人情報保護が厳密に求められる場面で使用

パス

• オンライン版: C:/Users/kawag/work/VoiceClip-Online/
• オフライン版: C:/Users/kawag/work/VoiceClip/

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• 川口脳神経外科リハビリクリニック — 臨床現場での利用

bento_order_webは、介護・リハビリ施設向けの弁当注文Webシステム。スタッフがスマホから弁当を注文し、管理者が集計・発注を行う。

技術スタック

• フレームワーク: Vite + React + TypeScript
• DB/Auth: Firebase (Firestore + Storage + Auth)
• デプロイ: Firebase Hosting
• 連携: Google Apps Script (GAS)

主な機能

• スタッフによる弁当メニュー選択・注文
• 管理者による注文集計・発注管理
• GAS連携による外部通知

セキュリティ

• CSP設定厳密
• Firestore Security Rules適用
• 保護ファイル: firestore.rules（エミュレータテスト後のみ変更可）

デプロイ

• 本番URL: https://bento-order-system-27e5c.web.app

パス

• ソース: C:/Users/kawag/work/bento_order_web/

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• 川口脳神経外科リハビリクリニック — 利用施設

dementia-risk-suiteは、Lancet 2024論文に基づく認知症リスク評価スイート。14のリスク因子評価と5領域の認知機能テストを統合したWebアプリ。

技術スタック

• フレームワーク: React 18 + TypeScript + Vite
• DB: Cloudflare D1（エッジDB）
• デプロイ: Cloudflare Pages
• コスト: 無料

主な機能

エビデンス

• Lancet Commission 2024の修正可能なリスク因子に準拠
• 14因子: 教育不足、難聴、外傷性脳損傷、高血圧、過度飲酒、肥満、喫煙、うつ、社会的孤立、運動不足、大気汚染、糖尿病、視力低下、高LDLコレステロール

パス

• ソース: C:/Users/kawag/work/dementia-risk-suite/（Cloudflare版: dementia-cf-suite/）

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• drawing-cognitive-test — 認知機能評価の別アプローチ
• フレイル — 認知フレイルとの関連

docu-scanは、書類スキャナーPWA。カメラで書類を撮影し、Claude Vision AIが丸囲み・チェック文字を抽出、GAS経由でGoogleスプレッドシートに自動転記する。

技術スタック

• フレームワーク: Next.js 14 + TypeScript + Tailwind
• AI: Claude Vision API
• 連携: GAS WebApp → Google Sheets
• デプロイ: Vercel
• 形態: PWA

処理フロー

1. スマホカメラで書類を撮影
2. Claude Vision AIが画像解析（丸囲み・チェック文字の抽出）
3. 抽出データをGAS WebApp経由でスプレッドシートに送信
4. スプレッドシートでデータ確認・集計

パス

• ソース: C:/Users/kawag/work/docu-scan/

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• nurse-expense-app — 同じくAI-OCRを活用

drawing-cognitive-testは、図形描画による認知機能テストアプリ。患者がタブレット/スマホ上で図形を描画し、その正確性から認知機能を評価する。

技術スタック

• フレームワーク: Next.js + TypeScript + Tailwind
• DB/Auth: Firebase
• デプロイ: Firebase

用途

• 神経疾患（パーキンソン病・脳卒中等）の認知機能スクリーニング
• 図形認知能力の定量評価
• 川口脳神経外科リハビリクリニックの臨床評価で活用

セキュリティ

• 保護ファイル: firestore.rules（生体情報保護ルール、エミュレータテスト後のみ変更可）

パス

• ソース: C:/Users/kawag/work/drawing-cognitive-test/

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• 川口脳神経外科リハビリクリニック — 臨床利用施設
• dementia-risk-suite — 認知症関連の評価ツール

endai-systemは、学会演題管理プラットフォーム。学術大会の演題登録・査読・プログラム編成・参加登録・決済までを一元管理する最大規模のプロジェクト。

技術スタック

• フレームワーク: Next.js 16 (Turbopack)
• 言語: TypeScript
• DB/Auth: Supabase (PostgreSQL + Auth + RLS)
• デプロイ: Vercel
• AI: Claude API (Sonnet 4.6)
• UI: Tailwind CSS

コア機能

AI機能

• 演題フォーマット検査: Sonnet 4.6で投稿された演題の形式をチェック
• カテゴリ提案: 演題内容からカテゴリを自動推定
• 自動返信案生成: 査読結果に基づく著者への通知文案を生成

セキュリティ

• Supabase RLS厳密適用
• Server Actions使用（Turbopack制約あり）
• 保護ファイル: supabase/migrations/（37件、新規追加のみ、既存編集禁止）

パス

• ソース: C:/Users/kawag/work/endai-system/

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• 事業概要 — 事業における位置づけ

line-crmは、LINE公式アカウントを活用したCRMシステム。L-step/Utageの代替として自社開発。ステップ配信・受診リマインド・分析ダッシュボードを備える。

技術スタック

• フレームワーク: Next.js 15 + TypeScript
• DB/Auth: Supabase (PostgreSQL + Auth + RLS)
• API: LINE Messaging API
• デプロイ: Vercel (Hobby無料枠)
• 通知: Slack Webhook（スタッフ通知）

主な機能

アーキテクチャ

• Edge RuntimeでLINE Webhook受信
• Supabase RLSで患者データ保護
• 全9Phase実装完了（2026-03-26）

デプロイ前の要件

⚠️ 要確認：デプロイ前にAuth + RLS設定が必要（MEMORY.mdに記載あり）

パス

• ソース: C:/Users/kawag/work/line-crm/

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• 事業概要 — CRM事業の位置づけ
• 川口脳神経外科リハビリクリニック — LINE公式アカウント運用主体

nurse-expense-appは、訪問看護ステーション向けの経費精算PWA。スマホで領収書を撮影し、AIがOCRで読み取り、申請→承認→CSV出力まで完結する。

技術スタック

• フレームワーク: Next.js 14 + TypeScript + Tailwind
• DB/Auth: Firebase (Auth + Firestore + Storage)
• AI: Gemini Vision API（無料枠）
• 連携: GAS WebApp
• デプロイ: Vercel
• 形態: PWA（Androidホーム画面追加対応）

主な機能

パス

• ソース: C:/Users/kawag/work/nurse-expense-app/

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• docu-scan — 同じくAI-OCRを活用するプロジェクト

rehab-monitoring-systemは、Flutter製のリハビリテーション活動モニタリングアプリ。患者の歩数・活動量をスマホのヘルスデータから取得し、セラピストと共有する。

技術スタック

• フレームワーク: Flutter + Dart
• DB/Auth: Firebase (Auth + Firestore + Storage)
• ヘルスデータ連携:
• iOS: HealthKit
• Android 14+: Health Connect
• Android旧版: Google Fit

主な機能

Flutter Web の技術知見

• CanvasKit使用 → E2Eテストは座標ベースクリック（DOM要素なし）
• CSPヘッダー: 'wasm-unsafe-eval' + connect-src にgstatic/fonts必須
• ビルド: C:/flutter/bin/flutter.bat build web --release
• デプロイ: firebase deploy --only hosting

パス

• ソース: C:/Users/kawag/work/rehab-monitoring-system/

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• 川口脳神経外科リハビリクリニック — 患者モニタリングの主体
• visitcare — 訪問リハビリのケア記録との連携可能性

visitcareは、訪問リハビリテーションのケア記録・管理システム。セラピストが訪問先で記録を入力し、管理者が一覧・分析を行う。

技術スタック

• フレームワーク: Next.js 14 + TypeScript + Tailwind
• DB/Auth: Supabase (Auth + PostgreSQL + RLS)
• デプロイ: Vercel

主な機能

• 訪問リハビリのケア記録入力
• 患者情報管理
• 記録の一覧・検索・分析

セキュリティ

• Supabase RLS厳密適用（患者テーブル + RLSポリシー）
• 保護ファイル: supabase/migrations/（新規追加のみ、既存編集禁止）
• 保護ファイル: .env.local（読取・コミット禁止）

パス

• ソース: C:/Users/kawag/work/visitcare/

関連ページ

• Webアプリポートフォリオ — 全プロジェクト横断分析
• 川口脳神経外科リハビリクリニック — 訪問リハビリ事業の主体
• リハマネ加算 — ケア記録と算定の連動

川口脳神経外科リハビリクリニックは、大阪府枚方市・寝屋川市を中心に訪問リハビリテーションを提供する医療法人である。

基本情報

• 法人形態: 医療法人
• 所在地: 大阪府枚方市・寝屋川市エリア
• 主要サービス: 訪問リハビリテーション
• 対象疾患: 脳神経外科領域を中心とした疾患別リハビリテーション

提供サービス

訪問リハビリテーション

• 脳血管疾患等の患者への在宅リハビリ提供
• リハマネ加算に基づくリハビリテーション計画の策定・実施
• 多職種連携によるリハビリテーション会議の実施

関連事業

• 株式会社としてDXコンサルティング・枚方市BPO事業を展開
• 介護予防事業（C型）でのフレイル改善プログラムの実施・研究

システム環境

• 既存システム: ほのぼのミニ2、ワイズマンSP
• DX基盤: Next.js 15、Supabase、Vercel、Claude Code

関連ページ

• 枚方市BPO — 枚方市との協働DX事業
• リハマネ加算 — 訪問リハビリの算定加算
• 事業概要 — 法人構成と事業全体像
• フレイル — 介護予防C型で取り組む虚弱改善

枚方市BPOは、枚方市から受託するビジネス・プロセス・アウトソーシング事業である。リハビリテーション評価データの分析を中心に、自治体の介護予防施策を支援する。

事業概要

• 委託元: 枚方市
• 事業主体: 株式会社（川口脳神経外科リハビリクリニック関連法人）
• 主要業務: リハビリ評価データ分析、介護予防事業の効果測定

業務内容

データ分析

• 介護予防事業（A型・C型）の参加者データ集計
• フレイル指標（基本チェックリスト等）の前後比較分析
• 統計解析レポートの作成・提出

医療情報システム安全管理

• 個人情報保護法に準拠したデータ取り扱い
• GL6.0（医療情報システムの安全管理に関するガイドライン）対応

技術スタック

• データ集計: Python (pandas), R (tidyverse)
• レポート: HTML資料、PowerPointスライド
• 基盤: Claude Code + MCP連携による業務自動化

関連ページ

• 川口脳神経外科リハビリクリニック — 母体医療法人
• 事業概要 — 法人構成と全事業
• フレイル — 分析対象となる虚弱指標