智翔館 週間計画アシスタント（テスト版）

社内向けの Web チャットアプリ。ログインした社員が Claude API と会話しながら週間の行動計画を作る。 会話ログを記録（後の改善・人事評価用）、API キーはサーバ側のみ。

ローカル起動

1. npm install
2. cp .env.example .env.local して ANTHROPIC_API_KEY と ACCESS_CODE を設定
3. npm run dev → http://localhost:3000

Vercel デプロイ

1. このリポジトリを Vercel で Import
2. 環境変数を設定: ANTHROPIC_API_KEY / ACCESS_CODE /（任意）AGENT_MODEL
3. Deploy → 発行 URL を社内共有

中身の調整

• 会社情報・理念・社長方針・用語定義: knowledge/10_理念・方針/COMPANY.md（lib/core/companyKnowledge.ts が読み込み、全AI機能の前提として差し込む）
  • 会議AI（事前報告・月次報告・講習の結果報告）・中間報告・議事録のすべてが withCompanyKnowledge() を通して読む
  • 本日の日付と期（5月始まり・4月締め）は実行時に Asia/Tokyo で算出する。定数で持たない
  • 〔要確認〕と書かれた箇所は未確定。裏取りができ次第そこだけ差し替える
• 左メニュー（会議DX）: components/Sidebar.tsx
  • ダッシュボード・部門会議 ／ 全体会議（数値報告・会議AI・全体会議振り返り）
  • 要項QAと「ご意見・不具合の報告」は、総合メニューのアプリ「ヘルプデスク」（/helpdesk）へ移した（下の「ヘルプデスク」の節）
  • 「報告の転記」（/report）と「中間報告」（/progress）は hidden: true でメニューから外している（画面は URL で開ける）。戻すときは hidden を外す
  • ダッシュボードの「直近の事前共有事項」「直近の中間報告」も止めている（components/DashboardUI.tsx の SHOW_SHARE_ITEMS / SHOW_RECENT_PROGRESS を true に戻すと出る）
• 会話の進め方（プロンプト）: lib/systemPrompt.ts（会議AI「事前報告」モード）
• 数値報告（「数値報告」メニューの入力項目・対象期間・校舎のプルダウン）: lib/numberReports.ts
  • メニュー内で「月次（通常期）」と「講習期（春期・夏期・冬期）」を切り替える
  • 月次の項目は MONTHLY_FIELDS（生徒数・入会・体験・部門ごとのイベント等）、講習期の項目は SEASON_FIELDS
  • 生徒数（月末・昨年同月）と入会（実績・昨年同月）は、ポップアップで小2〜高3の学年別に今年・昨年を並べて入れ、画面には合計を出す。目標は合計を直接入力 （内訳は隠し項目 studentsByGrade / studentsLastByGrade / enrollByGrade / enrollLastByGrade としてシートの末尾の列に保存）
  • 総務・人事・支援・管理は校舎の代わりにグループ（管理・支援・経理）を選び、月次は「数値報告（自由記述）」1項目だけ（NO_STUDENT_DEPTS・freeNumbers。項目の出し分けは fieldsFor）
  • 「イベント等」欄に部門ごとに必ず入れてもらう数値は EVENT_GUIDES（RED個別：中3県一斉模試・中3パック受講数／小中等部：模試。いずれも今年／昨年）
  • 校舎の選択肢は CAMPUSES_BY_DEPT に並べる（無い部門は校舎名の自由入力欄になる）
  • 入力は スプレッドシート「月次数値」「講習数値」へ1行ずつ記録（apps_script/Code.gs の saveNumberReport_ / listNumberReports_）。 旧「夏期数値」シートは読み書きしない（2026年夏までの記録として残す）
• 月次報告（会議AI「月次報告」モード）: lib/monthlyPrompt.ts
  • 数値は対話で尋ねず、「数値報告」（月次）で登録済みのものを読み取る。未登録なら入力を促して止まる
  • 毎月の報告なので会議の開催日は聞かない。計画は内容を列挙させず、実践度合い（%）と理由だけを1問で聞く
  • 冒頭の1問で A（数値を含む報告：校舎部門責任者）/ B（数値を担当しない職員）に分岐。B は「その月の行動目標と結果」「成功事例」「共有・相談」だけを聞く
  • その月の計画の実践度合い（%・理由）、目標に届かなかった項目の要因、成功事例、共有/相談したいことを出力
• 講習の結果報告（会議AI「講習の結果報告」モード。旧「夏の結果報告」）: lib/seasonPrompt.ts
  • 数値は対話で尋ねず、「数値報告」（講習期）で登録済みのものを読み取る。未登録なら入力を促して止まる
  • 募集／継続／成績を振り返り、宿題の完了状況・成功事例・共有/相談したいことを出力
• 事前報告・月次報告・講習の結果報告の保存（「報告完了」で自動保存）: lib/reportSubmit.ts
  • AI は下書きを見せ、報告者が「報告完了」と送ったときだけ「＝＝＝ …（ここから）＝＝＝」の確定ブロックを出す
  • 画面（components/ChatUI.tsx）がそのブロックを見つけると /api/report へ送り、会議ドキュメントへ転記する
  • 事前報告も「報告完了」での保存で提出は終わり（会議ドキュメントへの貼り付けや LINE WORKS での完了報告は不要）
  • 自動で保存できなかったときの予備として「報告の転記」画面（/report）が残っている。左メニューには出さず、 会議AIの保存失敗の案内からだけ開く
  • 転記と同時に、報告文中の「■ 成功事例（全体共有）」を スプレッドシート「成功事例」へ自動で1件1行記録し、ダッシュボードに全部門分を表示 （抽出ロジック: lib/successCases.ts ／ 保存先: apps_script/Code.gs の saveSuccess_ / listSuccess_）
• 部門会議（「部門会議」メニュー。会議DXの基本機能。URL は /dept-minutes のまま）
  • 流れ（ループ）：1 会議情報を入力して［事前共有で報告する］→ 2 録音／録音ファイル添付／文字起こし貼り付け → 3 AIが議事録化 → 入力者が確認・修正 → 保存（決定事項が全部門で見える）→ 4［次回の事前共有をつくる］で、その議事録から次回の会議情報と議題の下書きを作る → 1 に戻る
  • 次回の下書き：会議名・場所・出席者はそのまま、開催日時は「■ 次回会議」の日付。議題には 「話し合えなかった議題（未実施）」「決定事項の進捗確認」「継続審議・保留」「未完了の ToDo」「持ち越し・準備事項」を引き継ぐ （組み立て: lib/deptMinutesPreshare.ts の buildNextAgenda ／ 議事録からの切り出し: lib/deptMinutesDraft.ts の draftForNext）
    • 保存済みの議事録からも、［詳細］→［次回の事前共有をつくる］で作れる（部門会議の画面・ダッシュボードの両方）
  • 事前共有：手順1の会議名・開催日時・場所・出席者・議題（レジュメ）を、ダッシュボードの 「部門会議の事前共有」と議事録画面の「これからの部門会議」に出す（出席者が議題を見ながら会議を進めるため）
    • 並べ方・外し方（議事録を保存した会議と、開催日から3日過ぎた会議は外す）: lib/deptMinutesPreshare.ts
    • 保存先: 「部門会議事前共有」シート（1会議1行）。議事録を保存すると「議事録ID」が入る （apps_script/Code.gs の saveDeptPreshare_ / listDeptPreshare_ / linkDeptPreshare_）
  • 議事録テンプレート（項目・書き方）: lib/deptMinutesTemplate.ts ★ここを直せば AI の出力・ 画面のヘルプ・会議の質チェックにまとめて反映される
  • AI への指示: lib/deptMinutesPrompt.ts
  • 保存先: 「部門会議議事録」シート（1会議1行）＋「部門決定事項」シート（1決定1行） （apps_script/Code.gs の saveDeptMinutes_ / listDeptMinutes_ / listDeptDecisions_）
  • テンプレートに沿わなかった点（話し合えなかった議題・結論の出なかった議題・担当や期限が 決まっていない決定など）は「会議の質チェック」として議事録の後ろに出力され、シートにも残る
• ここを直すと全社員の AI に一括反映

問合せ管理アプリ（小中等部 問合せ管理の Web アプリ化）

スプレッドシート「2026小中等部問合せ管理」（校舎ごとのタブ）を置き換える台帳アプリ。 URL は /inquiry-board。会議DXのメニューには載せず、URL を直接共有して使う （ログインは会議DXと共通。ログアウト状態で開くとログイン画面を経て戻ってくる）。 問合せ管理の「AIに聞く」（問い合わせQA）と会議DXの目標管理は、この台帳のデータを参照する（下記「問い合わせQA」）。

• 画面: app/(board)/inquiry-board/（専用レイアウト・サイドバー無し）／ components/InquiryBoardUI.tsx
• API: app/api/inquiry-board/route.ts（GET＝全件、POST＝登録、PUT＝更新、DELETE＝削除）
• データ定義・選択肢・集計: lib/inquiryRecords.ts ★列や選択肢を増やすときはここ
• 保存: lib/inquiryStore.ts → apps_script/Code.gs の listInquiryRecords_ / saveInquiryRecord_ / deleteInquiryRecord_
• 閲覧できる部門: lib/inquiryBoardAccess.ts（小中等部・管理部門。個人情報を含むため）

できること

• 校舎タブ（日野校・駅前校・大野校・日宇校・県中・オンライン・その他・未分類）で切り替え、行を押すと編集。 「未分類」は校舎が決まっていない問い合わせの置き場（HP フォームで校舎が読めなかった分もここに入る）。 校舎タブの下の表示区分「追客／入塾済み／すべて」は既定が「追客」で、入塾した人は一覧から外れる（学年別集計は区分に関係なく全体で数える）。 旧シートの「県中対策」は通塾の「県中」とオンラインの「オンライン」に分けた（移行時は「県中」に入る）
• 元シートと同じ項目（No.・日付・生徒氏名・ふりがな・学校・学年・電話・媒体・受講期・連絡・体験日・体験・ 入塾提案面談日・本人OK・クローズ予定日・結果・備考・保護者名・郵便番号・住所・DM）＋ 入塾日（新設。「今月入会」を数えるため）＋紹介者（媒体が紹介のとき誰の紹介か）＋メールアドレス
• プルダウンの選択肢は元シートの各校舎の和集合（媒体に「講習会リピーター」「門配」を含む等）
• 件数カード（問合せ／追客中／入塾／申込／見送り／未着手／期限超過）を押すとその区分で絞り込み
  • 未着手＝連絡も結果も未記入、期限超過＝クローズ予定日を過ぎて結果が未記入。一覧でも左端に色が付く
• 画面上部の「今日の注意点」（AIアラート）：クローズ超過・未着手・体験後／面談後の結果未記入・長期滞留・ 入塾日の未記入と、今月入会・体験授業の実績（目標があれば対比）を出す。チップを押すとその区分で絞り込める
  • 件数はルールで数える（lib/inquiryAlerts.ts。閾値は THRESHOLDS）。AI には数えさせない
  • KPI の数字は会議DXアプリ「問い合わせQA」と同じ値にしている（画面ごとに数字が違うと混乱するため）。 今月入会など行動計画の指標は行動計画に入力された値（goalsFor と同じ）、体験授業は体験日が今月の件数、 「入塾／申込／見送り／追客中」は問い合わせ日が今月の行のその後（問い合わせQAのカードと同じ数え方）。 入塾日から数えた入会は AI への事実に「参考」として添えるだけで、画面の KPI にはしない。 行動計画に今月の行が無いときだけ台帳の入塾日・体験日で代用し、出所（カーソルを合わせると出る）にそう書く
  • AI の一言（3行）は lib/inquiryAlertsAi.ts が Claude に事実だけを渡して書かせる。 氏名は「田○」にマスクして渡す。ANTHROPIC_API_KEY が無ければ AI の行は出ず、ルールの行だけになる
  • AI の一言は 1日1回、全体（「すべて」＋件数のある校舎）をまとめて生成し、その日は変えない
    • 定時：vercel.json の cron が毎朝 7:00（JST）に /api/inquiry-board/alerts/daily を叩く。 Vercel は Authorization: Bearer <CRON_SECRET> を付けて来るので、環境変数 CRON_SECRET を設定する （Vercel の Hobby プランでは cron は 1日1回まで・時刻は前後することがある）
    • 保険：その日の分がまだ無いまま画面が開かれたら、最初の表示のときにまとめて生成して保存する
    • 生成した文は台帳スプレッドシートの「AI注意点」タブ（日付・対象・本文・生成日時）に残す。 ローカル開発では .data/ai-notes.json
    • 作り直したいときは管理部門でログインして /api/inquiry-board/alerts/daily?force=1 を開く
    • 件数・#No. の行（ルール）は保存のたびに数え直す。固定されるのは AI の3行だけ
  • 目標は「秋～冬行動計画」（GOALS_BOOK_ID）から。校舎タブなら校舎の行、「すべて」なら「中等部」の行
• 見出しを押すとその列で並び替え（昇順⇄降順。空欄は末尾）。見出しの下の絞り込み行で列ごとに絞り込める （選択肢の列は「未記入」も選べる。氏名・電話・学校・備考は「含む」で絞る）。「列で絞り込み」で行の表示を切り替え
• 「簡易表示」（ふだんの追客に要る列だけ）と「詳細表示」（全列）の切り替え、「文字：大」で一覧の文字を大きく。 いずれも端末ごとに覚える（localStorage）
• 一覧の枠は画面の残りの高さに合わせて内側でスクロールし、見出しは固定。横スクロールバーが常に画面内にある
• 月・キーワードで絞り込み、学年別の集計（元シート右側の表に相当）、CSV ダウンロード
• 重複の統合：同じ生徒が 2 行に分かれたとき、後から来た問い合わせを開き、編集画面の最上段「重複の統合」で 以前の問い合わせを選ぶと、古いほうの行にこの行をまとめる（lib/inquiryMerge.ts、POST /api/inquiry-board/merge）。 同じ氏名の行があれば最初から開き、候補の先頭に出る（1件なら選択済み）。「入れ替える」で残す行を反転できる
  • 残す行（古いほう）の値を優先し、空欄の項目だけもう一方の値で埋める。日付は早いほう。備考はつなげる
  • 両方にあって違う値は捨てず、備考に「採用しなかった値」として残す。まとめた行は削除（論理削除）
  • 実行前に何が変わるかを画面に出す。入力中の変更があるときは先に保存させる
• No. は校舎ごとに自動採番（空欄で登録したとき）。誰がいつ登録・更新したかを残す

セットアップ

1. apps_script/Code.gs を最新にして再デプロイする（新しい action が増えている）
2. 台帳の置き場所を決める
   • 既定では Apps Script がバインドされたスプレッドシートに「問合せ台帳」タブができる
   • 生徒・保護者の個人情報を1件1行で持つので、別のスプレッドシートにすることを勧める。 その場合は新しいスプレッドシートを作り、その ID を Code.gs の INQUIRY_DB_ID に入れる （閲覧できる人をそのファイルの共有設定だけで絞れる）
3. 旧スプレッドシートの行を移す・差分を取り込む：Code.gs の INQUIRY_BOARD_ID に旧シートの ID が入っている状態で、 GAS エディタから previewLegacyDiff()（確認のみ）→ applyLegacyDiff()（反映）の順に実行する。 importLegacyInquiryBoard() は applyLegacyDiff() と同じ。初回の一括取り込みも、並行運用中の差分取り込みも同じ手順
   • 結果は台帳スプレッドシートの「旧シート差分」タブに書かれる（追加／空欄を埋める／備考に追記／競合）
   • 突き合わせは校舎＋生徒氏名（同名が複数なら No. でも絞る。同じ校舎に無ければ他校舎の同名を探す）。 台帳で削除済みの人は復活させない
   • 台帳に無い人は追加。No. は旧シートの番号を使うが、台帳の別人と重なれば次の番号にして備考に「旧シートNo.xx」と残す
   • 台帳にある人は空欄の項目だけ旧シートの値で埋め、備考は旧シートにあって台帳に無い行だけ末尾に足す
   • 両方に値があって違う項目（結果・連絡・体験・日付など）は台帳（アプリ）を優先し、「競合」として一覧に出すだけ
   • 「県中対策」タブの行は「県中」に入る。オンライン受講の人は移行後に校舎を「オンライン」へ直す
   • 「5/21」のような年無しの日付は LEGACY_START_YEAR（期の開始年）で補う。 「5/21.6/29」のような複数日は文字のまま移し、画面では文字入力として出る（消さない）
   • 移した行は作成者が「旧シート移行」になる。入塾日は空なので、担当者が分かる範囲で埋める
4. /inquiry-board を小中等部の担当者に共有する

APPS_SCRIPT_URL が無いローカル開発では .data/inquiry-board.json に保存される（git には入らない）。 Vercel 本番で未設定なら画面に「未設定」と出る。

触るときの注意

• 列を増やすときは lib/inquiryRecords.ts の RECORD_FIELDS と Code.gs の INQUIRY_DB_HEADERS を 同じ順で両方直す。台帳は見出し名で列を引くので、既存の台帳には見出しが自動で足される
• 削除は「削除」列に 1 を立てる論理削除。誤って消したら、シートでその 1 を消せば戻る
• 日付は「YYYY-MM-DD」の文字列で持つ（列の書式を @ にしてある）。シート側で日付型に変えないこと
• HP の問い合わせフォームは、通知メールを Apps Script で旧シートへ転記する仕組み（「メール転記」タブ）から、 下の「HP フォームからの直接取り込み」に切り替える。切り替えたらメール転記は止める（二重登録になるため）

HP フォームからの直接取り込み（WordPress → 台帳）

WordPress の問い合わせフォームの送信先（Webhook）にこのアプリを指定すると、メールを介さず台帳に1件登録される。

• 受け口: POST https://<このアプリ>/api/inquiry-board/intake（app/api/inquiry-board/intake/route.ts）
• 認証: Vercel の環境変数 INQUIRY_INTAKE_TOKEN に合言葉を入れ、WordPress 側から ヘッダ X-Intake-Token: <合言葉>（ヘッダを付けられないプラグインなら URL に ?token=<合言葉>）で送る。 未設定のあいだ受け口は閉じている（503）
• 項目の対応: lib/inquiryIntake.ts の FIELD_ALIASES。通知メールと同じ項目名（お子様名・ふりがな・保護者名・ 保護者名ふりがな・郵便番号・住所・電話番号・メールアドレス・学校名・学年・希望コース・受講校舎・相談事項・ お問い合わせ内容）と、英語名（student_name / student_kana / guardian_name / guardian_kana / postal / address / phone / email / school / grade / course / campus / consult / message / submission_id）のどちらでも受け付ける。 JSON・form-urlencoded・multipart のいずれでもよい

WordPress 側の設定（Contact Form 7 の場合。フォームごとに設定する）:

1. プラグイン「CF7 to Webhook」（Contact Form to Any API 等でも可）を入れる
2. お問い合わせ → 対象フォーム → 「Webhook」タブで、送信先 URL に https://<このアプリ>/api/inquiry-board/intake?token=<合言葉>&form=<フォーム名> を入れる （このプラグインはヘッダを付けられないため URL に付ける）。form= はフォームごとに変える（例 &form=資料請求 &form=テスト対策）。備考の1行に「HPフォーム:資料請求」のように出て、どのフォームから来たか分かる
3. 実際のフォームのタグは your-name（お子様名）/ your-parent（保護者名）/ your-school / your-class（学年）/ your-tel / your-email / your-message で、これらは対応表に入っている。 講座ごとのフォームには校舎・希望コースの項目が無いので、「フォーム」タブに [hidden your-campus "日宇校"] [hidden your-course "中学生向け定期テスト対策"] のような hidden タグを足す （複数校舎で共用するフォームなら [select* your-campus "日野校" "駅前校" "大野校" "日宇校" "県中" "オンライン"] を置く）。 無ければ「その他」に入り、備考に【校舎不明】が付く
4. 送る項目名が上の一覧に無い名前なら、FIELD_ALIASES にその名前を足して push する
5. テスト送信して /inquiry-board に出ることを確認。Vercel のログに [INQUIRY_INTAKE] が残る
6. 「メール」タブの送信先（担当者への通知メール）はそのままでよい。取り込みはメールとは独立して動く
7. 取り込みに失敗しても（合言葉の違い・台帳に書けない等）受け口は HTTP 200 で { ok:false, reason } を返す。 CF7 to Webhook は 200 番台以外が返るとフォームの送信結果を「送信に失敗しました」に変えてしまうため。 失敗は Vercel のログに [INQUIRY_INTAKE_ERROR] で残るので、台帳に出ないときはそこを見る （reason: invalid_token なら URL の token と Vercel の INQUIRY_INTAKE_TOKEN が一致していない）

取り込みの決まり（lib/inquiryIntake.ts の decideIntake）:

• 媒体は「HP」、日付は受信日、結果は空（追客中）で登録する。希望コースから受講期を読み替える （「模試」→模試、「講習」→講習会、「体験・イベント」→その他イベント、それ以外→通常）
• 受講校舎は「佐世保駅前校」→「駅前校」のように部分一致で寄せる。読めなければ「未分類」に入れ、 備考に【校舎不明】と元の入力を書く（捨てない）。担当者が校舎タブで振り分ける
• 高校生は小中等部の対象外だが、備考に【高校生】と書いて残す（高等部へ引き継ぐ）
• 同じ氏名の行があれば新規にせず、その行の備考の先頭に「[9/18 14:05 HPフォーム:資料請求] …」を追記する （旧メール転記の「既存行のため備考に追記」と同じ）。資料請求のあとテスト対策に申し込む、のように同じ人から 何度来ても送信ごとに1行ずつ積み上がる。同じ分・同じフォーム・同じ内容の行が既にあるときだけ二重送信として飛ばす。空欄だった連絡先だけ埋め、担当者が直した値は上書きしない。
  • 既存行は「同じ校舎 → 電話番号も一致 → 氏名一致が1件だけ」の順で探す。校舎が違えば備考に【校舎違い】と書く
• 電話番号は全角を半角にし、先頭の 0 が落ちた 9〜10 桁（数値扱いで落ちたもの）は 0 を補う。 台帳への追記は先に文字列書式を付けてから書く（appendRow だと 0 が落ちる） 電話番号だけで寄せると兄弟の行に追記してしまうので、電話番号で探すのは氏名が無いときだけ
• 送信ID（submission_id）が同じものは二重登録しない（WordPress の再送対策）。台帳の「受付ID」列に残る

問い合わせQA（小中等部 問合せ管理）

小中等部の問合せ管理を読み、各校舎の状況を AI が答える（問合せ管理アプリの「AIに聞く」・/inquiry-board/qa。テスト中）。 旧 URL の /inquiry-qa は /inquiry-board/qa へ転送する。 職員からのアプリへの意見・不具合の報告（ヘルプデスクの「ご意見・不具合の報告」）とは別物。

読む先は 問合せ管理アプリの台帳「問合せ台帳」を優先し、台帳が空のあいだは旧スプレッドシート （INQUIRY_BOARD_ID）を校舎タブごとに読む（apps_script/Code.gs の listInquiryBoard_）。 どちらから読んでも同じ形（校舎・No.・日付・…・結果・入塾日・備考）で返り、個人情報は同じように落とす。

• 画面: app/(board)/inquiry-board/qa/page.tsx ／ components/InquiryQaUI.tsx（開ける部門は問合せ管理と同じ lib/inquiryBoardAccess.ts）
• API: app/api/inquiry-qa/route.ts（GET＝校舎別の集計、POST＝QA のストリーム）
• 読み取り・集計: lib/inquiryBoard.ts ／ プロンプト: lib/inquiryQaPrompt.ts
• 取得元: apps_script/Code.gs の listInquiryBoard_（別スプレッドシートを ID 指定で開く）

セットアップ

1. apps_script/Code.gs の INQUIRY_BOARD_ID に問合せ管理スプレッドシートの ID を入れる （URL の /d/ と /edit の間）。空のままだと画面に「未設定」と出る。
2. Apps Script を再デプロイする（実行ユーザーがそのシートを閲覧できる必要がある）。
3. 校舎ごとのシートを自動で見つける。判定は「見出し行に『生徒氏名』と『結果』が 両方ある」こと。転記ログや集計シートは自動で除外される。校舎名＝シート名。
4. 列は見出し名で拾う。校舎ごとに列の位置が違っても動く（日野校だけ「住所あり」列がある等）。

個人情報の扱い（重要）

• Apps Script が返す前に、生徒氏名を「佐○」にマスクし、 電話番号・住所・郵便番号・保護者名・メール・ふりがなの列は落としている。 アプリにも Claude にも渡らない。
• ただし備考の自由記述までは機械的に消せない（「壱心の弟」等）。 そのためこの機能は小中等部と管理部門のみが開ける（画面とAPIの両方で制限）。
• 個別の件は「校舎名 #No.」で示すので、担当者は元シートを引いて確認する。
• 会話は他機能と同じく [CHAT_LOG] に残る。ログの保存先を変える場合はこの点に注意。

目標管理（秋～冬行動計画）

当月カードに「実績/目標」を重ねる。目標は中等部会議議事録の**タブ「秋～冬行動計画」**から読む。

• 取得: apps_script/Code.gs の listGoals_（GOALS_BOOK_ID / GOALS_SHEET_NAME）
• 突き合わせ: lib/goals.ts

タブは名前で引くこと。位置や順番で探してはいけない。 旧タブに 「このシート内容を『秋～冬行動計画』に移行しました。こちらのシートは削除します。（小山）」 と注記があり、タブの並びが変わる前提のため。

実績の出所は指標ごとに変える:

指標	実績	理由
体験授業	問合せ管理から自動計算（体験日の月）	体験日の列がある
今月入会	行動計画の手入力値	問合せ管理に入塾日の列が無い（下記）
サイトク・模試 等	行動計画の手入力値	問合せ管理に該当データが無い

「今月入会」を自動計算してはいけない（当面）。 旧シートの日付列は問い合わせ日であって入塾日ではない。「結果=入塾」を問い合わせ日の月で 数えると、行動計画の「今月入会」とは別物になる。実データでは入塾42件の問い合わせ日が 5月7件・6月13件・7月15件に集中し、9月に問い合わせた行の入塾は0件だった （9月に入会した人の行は5〜7月にある）。備考に「6/2入会」とある行は42件中1件だけで抽出もできない。 → 問合せ管理アプリには「入塾日」列を設けた。AI には「入塾日から数えた入会（参考）」として 入塾日が記入された分だけの件数と、入塾日が未記入の入塾行の数を渡している（lib/inquiryBoard.ts の enrollmentsInMonth）。旧シートから移した行は入塾日が空なので、担当者が埋め終わってから lib/goals.ts の AUTO_METRICS に「入会」を足して自動計算へ切り替える。

体験は逆に、問い合わせ日ではなく体験日の月で数える。 8月に問い合わせて9月に体験した人を8月側に入れると行動計画とずれるため（trialsInMonth）。

画面では指標名にカーソルを合わせると出所が出る。AIも回答時に出所を明示する。 数字の出所が分からないまま判断されるのを防ぐため。

※「中等部」（4校舎合計）の行は校舎カードが無いため画面には出ない。チャットでは答えられる。

集計の考え方

• 件数は lib/inquiryBoard.ts で先に計算し、その数字をプロンプトに「正」として渡す （AI に数えさせると間違えるため）。
• 「結果」が空＝追客中。入塾／講習会申込／見送り以外の値が入っていたら「その他」として 分けて出す。黙って追客中に混ぜない。
• 空欄は「未記入」と呼ぶ。記入漏れと実績ゼロを混同しないため。

音声の文字起こしについて（部門会議）

Claude は音声を直接読めないため、文字起こしだけ Google AI Studio（Gemini API） に任せ、 その結果を Claude に渡して議事録化している。

1. https://aistudio.google.com/apikey で API キーを発行
2. Vercel の環境変数に設定：GEMINI_API_KEY（必須）／ GEMINI_API_KEY_2〜_5（任意・予備キー）／GEMINI_RPM（任意・既定 5）／ GEMINI_MODEL（任意・既定 gemini-3.6-flash）／GEMINI_API_URL（任意・通常は不要）
3. 未設定のままでもアプリは壊れない。画面が「音声の自動文字起こしは未設定」と表示し、 他アプリで文字起こししたテキストの貼り付けだけが使える状態になる
4. 設定できたら「部門会議」画面の ［文字起こしの接続テスト］ を押して確認する。 キーが無効／モデル名が違う／枠を使い切っている場合は、その場で理由が出る （キーを複数入れているときは「キー1：使えます／キー2：1日の枠を使い切り」のように1本ずつ出る）

送信の間隔（GEMINI_RPM）— 無料枠で詰まらせないために

無料枠を止めるのは1日の総量ではなく 1分あたりの回数（RPM） のほう。 gemini-3.6-flash の無料枠は 5 RPM しかない。1区間はおよそ10秒で終わるので、 間隔をあけずに続けて送ると 6回/分 になり、必ず 429（TooManyRequests）で弾かれる。

そこで画面は GEMINI_RPM（キー1本あたり・既定 5）から送信間隔を決め、 はじめから上限を超えない速さで送る。断られてから待ち直すより速く、確実に終わる。

RPM は Google のプロジェクト単位なので、別アカウント（別プロジェクト）のキーを足すと 全体の上限は本数ぶん増える。画面は「いちばん早く空くキー」を選んで順番に使い、 どのキーを使うかを keyNo でサーバへ渡す。

APIキー	1分あたり	1時間の会議（40区間）の目安
1本	5回	約9分
2本（別アカウント）	10回	約5分

• 実際の上限は Google AI Studio の 「レート制限」 画面で確認できる（7 / 5 のように出る）
• 有料枠（課金を有効化）にしたらこの値を上げる。上げた分だけ文字起こしが速くなる
• 同じプロジェクトのキーを2本登録しても上限は増えない（枠を分け合うだけ）ので、 その場合は GEMINI_RPM を上げてはいけない

★どのキーを使うかはサーバではなく画面が決めている。 サーバの関数は呼び出しごとに別の実体で動くことがあり、そのたびに「前に通ったキー」の記憶が 消えて1本目に偏る。1つのタブが順番に送る画面側で決めることで、本数ぶんを均等に使える。

モデルの予備（「混み合っています」の自動回避）

無料枠のモデルは混雑すると 503（The model is overloaded） を返す。これは利用枠の問題ではないので、 待っても同じモデルが空くまで直らない。

そこで 503（または存在しないモデル名の 404）が返ったときは、同じ音声を別のモデルで送り直す。

• 使う予備は GEMINI_MODEL_FALLBACK（カンマ区切り）。空のままでよい
• 空のときは、そのキーで実際に使える flash 系モデルを一覧から自動で選ぶ（最大2つ）
• モデル一覧の取得（ListModels）は利用枠を消費しない
• 1区間あたりの呼び出しは最大6回まで。サーバ関数の残り時間も見て打ち切る
• 全部のモデルが混み合っていたときだけ「混み合っています」と表示して止まる

★503 はモデル側の混雑なので、キーを替えても直らない（キーの切り替えは枠切れ・制限・無効のときだけ）。

APIキーの予備（枠切れの自動切り替え）

GEMINI_API_KEY_2〜_5 を入れておくと、1本目が 1日の利用枠を使い切った／短時間の送りすぎで 断られた／キーが無効 のときに、その区間をそのまま次のキーで送り直す。利用者側の操作は要らない。

• 通ったキーは覚えておき、次の区間はそこから始める（枠切れのキーに毎回当たりに行かない）
• Gemini 側の不調（5xx）やタイムアウトでは切り替えない。どのキーでも同じ結果になるため （こちらは画面側が待ってから送り直す）
• 全部のキーが枠切れのときだけ、画面に「すべてのキーが1日の枠を使い切りました」と出して止まる
• GEMINI_API_KEY にカンマ区切りで複数まとめて書く形でもよい

★無料枠は Google のプロジェクト単位なので、予備キーは別の Google アカウントで発行すること。 同じアカウントで2本目を作っても、同じ枠を2本で分け合うだけで総量は増えない。 Google AI Studio の「使用量」画面でキーごとの内訳が見えるが、同じプロジェクトに並んでいるキーは 枠を共有しているので、切り替えても 429 は減らない。その場合は上の GEMINI_RPM で間隔をあけるか、 課金を有効にして上限そのものを上げる。

音声の形式と分割（触るときの注意）

Gemini が受け付ける音声は WAV / MP3 / AIFF / AAC / OGG / FLAC で、 ブラウザ録音の webm は受け付けない。そのため録音・添付ファイルのどちらも、 送信前に lib/audioChunk.ts で 16kHz モノラルの WAV に変換している。

あわせて、長い会議は90秒ごとの区間に分けて順番に送る（1区間およそ2.9MB）。 WAV は圧縮しないので通信量は増える（1時間の会議でおよそ110MB＝2.9MB×40回）。 その場で録音する場合は会議中に少しずつ送るので気になりにくいが、 長い録音ファイルを後から添付する場合は回線に余裕のある場所で行うこと。 サーバ関数の実行時間・リクエストサイズの上限に収めるための分割なので、 区間の長さを変えるときは lib/audioChunk.ts の SEGMENT_SECONDS を直し、 app/api/dept-minutes/transcribe/route.ts の実行時間上限に収まるか必ず確認すること （録音の区切りは components/DeptMinutesUI.tsx で SEGMENT_SECONDS に合わせてある）。

全体研修会アンケート（/kenshu）

10/31（土）全体研修会の事前アンケート。総合メニューの独立アプリで、全部門が利用できる。 質問は2つだけの自由記述で、この1年で「仕事」「人生・プライベート」それぞれで達成したいこと・やってみたいことを、 1行に1つずつ、いくつでも書く。

• 画面: app/(kenshu)/kenshu/（専用レイアウト・サイドバー無し。ヘッダは components/AppHeader.tsx）／ components/KenshuSurveyUI.tsx
• API: app/api/kenshu/route.ts（GET＝自分の回答、POST＝保存。ログインしている本人の分だけを読み書きする）
• 質問文・研修会の日付・対象期間: lib/kenshu/survey.ts ★次の研修会で使い回すときはここ （SURVEY.id を変えると別の回答として保存される。前回の回答はシートに残る）
• 保存: lib/kenshu/store.ts → apps_script/Code.gs の getKenshuAnswer_ / saveKenshuAnswer_ → スプレッドシート「研修会アンケート」タブに1人1行（研修会×部門×氏名）。送り直すと同じ行を上書きする （「提出日時」は最初のまま、「更新日時」が入る）
  • 「仕事」「人生・プライベート」の列には、書いたものを改行でつないで1セルに入れる。件数の列もある（集計用）
  • APPS_SCRIPT_URL が無いローカル開発では .data/kenshu.json に保存する

できること

• 最初は質問ごとに5行（lib/kenshu/survey.ts の MIN_ROWS）。Enter で次の行へ（日本語の変換を確定する Enter では動かない）。末尾にはいつも空の行が1つある
• メモ帳などに書いた箇条書きをまとめて貼り付けると、「・」「1.」「①」などの印を外して1行ずつに分ける
• 質問ごとに書いた数と一言（5個・10個・20個で変わる）を出す。「思いつかないときは」を開くと問いかけが出る
• 書きかけはその端末（ブラウザ）に残り、提出すると消える。どちらの質問にも1つ以上書くと提出できる
• 提出後に開くと「わたしのやりたいことリスト」が出る。［内容を直す］から何度でも出し直せる
• 1つの質問に100個まで、1行300文字まで（スプレッドシートの1セルに収めるため）

セットアップ

1. apps_script/Code.gs を最新にして再デプロイする（action:'getKenshuAnswer' / 'saveKenshuAnswer' が増えている）。 再デプロイするまでは提出できない（「スプレッドシートに保存できませんでした」と出る。古いスクリプトは知らない action を会話ログとして扱うため、画面を開くたびに「会話ログ」へ空の行も残る）。職員に案内する前に済ませること
2. 総合メニューに「全体研修会アンケート」のカードが出る（lib/portalApps.ts）。URL /kenshu を職員に案内する
3. 回答はスプレッドシートの「研修会アンケート」タブで見る（「仕事」「人生・プライベート」の列は折り返し表示にする）

触るときの注意

• プライベートの内容も入る。回答シートの共有範囲を、研修会の運営に必要な人に絞ること
• 研修会が終わってアンケートを閉じるときは、lib/portalApps.ts のカードを外すか status: 'soon' にする

ヘルプデスク（要項QA・マニュアル・ご意見・不具合の報告）

困ったときに開く画面をまとめた、総合メニューのアプリ（URL は /helpdesk）。全部門が利用できる（どれも個人情報を含まないため）。 上のタブで「要項QA」「マニュアル」「ご意見・不具合の報告」を切り替える。要項QAとご意見・不具合の報告は、v0.16 までは会議DXの左メニューにあった。

タブ	URL	中身
要項QA	/helpdesk	下の「要項QA」の節
マニュアル	/helpdesk/manual	操作マニュアル（PDF）と動画マニュアルのダウンロード・再生。並べる資料は lib/manuals.ts、ファイルは public/manual/
ご意見・不具合の報告	/helpdesk/feedback	アプリへの意見・不具合の報告と、管理部門の回答（components/InquiryUI.tsx、API は app/api/inquiry/route.ts）

• 画面: app/(helpdesk)/helpdesk/（専用レイアウト・サイドバー無し。ヘッダは門配管理などと同じ components/AppHeader.tsx）
• 旧 URL の /yoko-qa は /helpdesk へ、/inquiry は /helpdesk/feedback へ転送する（API の URL は変えていない）
• ダッシュボードの「実施期間中の要項」は会議DXに残したまま。「要項QAで聞く」からヘルプデスクの要項QAへ移る
• マニュアルのファイル（public/manual/）は、ログインしている人だけが開ける（middleware.ts が見張る。静的ファイルは画面のレイアウトの ログイン確認を通らないため）。Vercel の関数は約4.5MBより大きいファイルを返せないので、API を通さず静的ファイルとして配る
• 操作マニュアルの原稿・写真・作り方は docs/manual/（README.md）。作り直したら PDF を public/manual/ に置き、lib/manuals.ts の版を直す

要項QA（実施要項の確認）

講習会・イベントの実施要項について、申込方法・申込期限・受講料・支払い方法・日程などを AI が答える（ヘルプデスクの「要項QA」・/helpdesk）。全部門が利用できる（個人情報を含まないため）。

• 画面: app/(helpdesk)/helpdesk/page.tsx ／ components/YokoQaUI.tsx
• API: app/api/yoko-qa/route.ts（GET＝要項の一覧、POST＝QA のストリーム）
• 読み込み: lib/core/knowledgeDocs.ts ／ プロンプト: lib/yokoQaPrompt.ts
• 要項の本体: knowledge/40_要項/ 配下の Markdown

なぜ Google ドキュメントを直接読まないか

要項ドキュメントには編集中の案が混ざっている（「原案）」「（案）」、小等部夏期は１案・第２案・ ３案が並立）。案ごとに受講料や期限が違うため、そのまま読ませると矛盾した回答になる。 保護者に誤った金額を伝える事故につながるので、担当者が確認したものだけを git に置いて読む。

要項を追加・更新する手順

1. 要項ドキュメントを Markdown で書き出す（ファイル > ダウンロード > Markdown）。 タブが複数あるドキュメント（04要項 のテンプレート）は、Docs API の documents.get の JSON （Google Docs コネクタの read_doc でも取れる）を node scripts/export-yoko-doc.mjs <JSON> <出力先> に渡すと、タブごとの Markdown になる（--list でタブ名・講座名・ステータスの一覧だけ出す）。 テンプレート本体のタブと、複製時に残った冒頭の「使い方」は自動で落とす。
2. node scripts/import-yoko.mjs <書き出したファイル> を実行
   • 太字でない # 見出し（ドキュメントのタブ見出し）を区切りとして1件1ファイルに割る
   • 既にあるファイルは上書きしない（確定済みを壊さないため）
   • 生成されるファイルはすべて status: 下書き
3. 担当者が内容を確認したファイルだけ、front matter を status: 確定 に変え、owner に名前を入れる
4. commit & push すると Vercel が再デプロイし、確定したものだけが回答に使われる

status: 確定 以外は AI に本文を渡さない。画面の「未確定の要項」に名前だけ出るので、 聞かれた場合 AI は「まだ確定していないため回答できません」と答える。

要項テンプレート（本番の記入先）

要項は Google ドキュメントのテンプレートで書く。有料講座と無料講座で2種類あり、 Google ドライブの「14_教務運営 > 04要項」フォルダに置いている（担当者への共有用）。 https://drive.google.com/drive/folders/1IwwmmjAqh7yznmtOgFSkTDZrNS3_x-L5

種類	Google ドキュメント	リポジトリ側の控え
有料講座	「有料講座_要項テンプレート（記入用）」 https://docs.google.com/document/d/1ZoGnYxV424TelGRnZuAEmCgVIDt5nKXH1d7-OAYc5wc/edit	knowledge/40_要項/_TEMPLATE_有料講座.md
無料講座（無料体験・説明会・セミナー・無料模試など）	「無料講座_要項テンプレート（記入用）」 https://docs.google.com/document/d/1MoDgNhn0i5kUV0D_qaUBuf5GevbX5AG_QTxGCVApYL0/edit	knowledge/40_要項/_TEMPLATE_無料講座.md

テンプレートのタブを複製 → 講座名にリネーム → 上から埋める → ＜基本情報＞の「ステータス」を「確定」にする。 _ で始まるファイルは要項QAに読み込まれない。取り込み時は、タブ名が _ で始まるものと 「テンプレート」を含むものを飛ばすので、テンプレート本体のタブは取り込まれない。

旧テンプレート（https://docs.google.com/document/d/1zCh_tpiwfJBbru0Df3T5VFLsn4AQ66RDdmzuAW0BJHQ/edit）は 2026-09-16 に上の2種類へ置き換えた。旧テンプレートで書いた要項も取り込みはできる。

新テンプレートで変わった点:

• ＜経理連絡事項＞を「講座担当が記入」と「経理記入欄」に分けた。請求方法（口座引き落とし／ コンビニ払込票など）・引き落とし日・締日・計上月は経理が決めるので経理記入欄にあり、 講座担当は空欄のままにする（記入ルール「空欄にしない」の唯一の例外）。 「確定」にする前に経理記入欄が埋まっているかを確認する。
• ＜広報物・制作物＞を追加。LP・チラシ・ポスター（校舎内）・ポスター（校舎外）・サイネージ のうち希望するものの行だけ残し、制作依頼日と納品希望日を書く（テンプレートで唯一、行を 消してよい欄）。制作はすべて NEP事業部（安藤）が担当するので担当者欄は無く、仕様（新規か 流用か）も NEP が判断する。 募集開始（申込開始日）の10日前までに要項を確定する。納品希望日は制作依頼日の10日以上後に する。制作物ごとに制作費がかかり、10日以内の特急は割り増しになる。 制作費の目安（新規作成時・税込）はテンプレート内に載せている。出典は NEP の 「制作物_業務委託単価表（案B・2026年7月30日）」 （https://docs.google.com/spreadsheets/d/1rHYrTdRoz-ofwSfJNJGGCcmrmHYOrzqDW7I3ZjXMgcE/edit）。 単価表を改定したらテンプレートの目安も直すこと。
• 無料講座は＜受講料＞が「塾生：無料／一般生：無料＋教材費等」の形で、割引の節が無い。

＜基本情報＞は front matter に転記される（取り込みスクリプトが読む）:

ドキュメントの項目	front matter
講座名	title
作成者	owner
ステータス	status（「確定」だけがAIに渡る）
作成日	updated
部門	dept

書くときの原則（テンプレート内にも記載）:

• 塾生と一般生で扱いが違う項目は必ず両方書く。片方だけだと現場で取り違えが起きる
• 金額は税込で書く。税抜なら「（税抜）」を添える。AIは書かれた通りにしか答えない
• 日付は「7/30」ではなく「2026年7月30日（木）」。年が無いと翌年に誤答する
• 未定は空欄にせず「未定」、無い項目は「なし」と書く。空欄は書き忘れと区別できない
• 本文に見出し1（#）を使わない。取り込み時に別の要項として切り出されてしまう
• 案を複数並べない。並べるとAIが違う金額を答える。案の段階は「下書き」のままにする

取り込み時は次を自動で行う:

• 「_」で始まるタブ（記入用テンプレート本体）は取り込まない
• 「◆記入例…◆」の節は削除する。消し忘れたまま取り込むと、 AIが例の金額（25,300円など）を実際の受講料として答えてしまうため
• 作成者・ステータスの未記入、「（例：…）」の残りを警告する

確定後に誤りを直すとき（ステータスの扱い）

• ステータスは「確定」のまま直す。「下書き」に戻すと要項QAが「未確定」と答えて実施中の講座に答えられなくなる。
• ＜基本情報＞の「更新履歴」に日付・直した内容・名前を書く（例：2026年9月18日 一般生受講料 29,700→30,800円（安藤））。 「作成日」も直した日に更新する（画面の更新日として出る）。
• ドキュメントの「ステータス」は「確定」を含んでいれば確定扱い（「確定（9/18訂正）」でもよい）。 リポジトリ側の Markdown を直接直すときは status: を「確定」と完全一致にし、updated を直した日にする。
• 正しい値がまだ決まっていないときだけ「下書き」に戻し、決まってから「確定」に戻す。
• 取り込みスクリプトは既存ファイルを上書きしないので、確定済みを直したときは Markdown を直接直すか、 古いファイルを消してから取り込み直す。

経理への自動連絡（LINE WORKS Bot）

確定・金額訂正・経理記入完了を経理へ自動で知らせる。実体は apps_script/YokoNotify.gs。 要項テンプレートの Google ドキュメント（04要項 フォルダの2つ）に、コンテナバインドの Apps Script として貼る。

出来事	検知のしかた	通知
確定	ステータスが「確定」になった	経理へ「経理記入欄の記入をお願いします」＋担当者記入の経理連絡事項
金額訂正	確定済みのまま、＜受講料＞・＜申込＞の支払い方法・＜経理連絡事項＞の担当者記入が変わった	経理へ【至急】。変わった行を「− 前／＋ 後」で示し、更新履歴を引用
経理記入完了	経理記入欄の「経理記入日」が入った	講座担当へ「経理側の記入が終わった。取り込みを依頼してください」
確定取り下げ	確定 → 下書き に戻った	経理へ「請求処理を止めてください」
リマインド	経理記入待ちのまま 20 時間（REMIND_HOURS）経過	経理へ再通知（走査のたび）

経理が経理記入欄を書いても「金額訂正」にはならない（経理記入欄より前だけを比べる）。

動かし方:

• 1日1回の自動確認: 時間主導トリガーで dailyScan が 04要項 フォルダの全ドキュメント・全タブを走査する。 setupDailyTrigger を1回実行すると毎日 9〜10 時のトリガーができる。どちらか片方のドキュメントにだけ設定する。
• 更新ボタン: ドキュメントのメニュー「要項連絡 > このタブを今すぐ確認して連絡」。編集直後に担当者が押すと、 そのタブだけ台帳と比べて通知する。変化が無いときは「それでも送るか」を聞いてから手動連絡を送る。
• 台帳: 04要項 フォルダに「要項台帳」スプレッドシートが自動でできる。シート「台帳」は前回値なので手で直さない。 シート「担当者」に「作成者の名前 → LINE WORKS ユーザーID」を書くと、その人にも個別トークで届く（空でも動く）。 台帳はフォルダ内を名前で探して、有料講座・無料講座の両スクリプトで1つを共有する。 （2026-10-02 に通知が二重になった原因: スクリプト プロパティはプロジェクトごとに別なので、 ID をプロパティだけで持っていた旧版では台帳が2つでき、両方のトリガーがそれぞれ「確定」を検知した。） 同時走査の保険として、直前10分以内に別の走査が始まっていれば見送る（シート「状態」）。
• トリガーは片方のドキュメントだけ。両方に作ってしまったら、片方の Apps Script で removeDailyTrigger を実行する。

セットアップ（初回のみ）:

1. LINE WORKS Developer Console で Bot を作り、通知先のトークルームに Bot を入れる。 アプリ（Service Account 認証）を作り、Scope に bot を付け、Client ID / Client Secret / Service Account / Private Key を控える。
2. 通知先トークルームの Channel ID と Bot ID を控える。
3. 各テンプレートドキュメントの「拡張機能 > Apps Script」に YokoNotify.gs を貼り、 「プロジェクトの設定 > スクリプト プロパティ」に LW_CLIENT_ID LW_CLIENT_SECRET LW_SERVICE_ACCOUNT LW_PRIVATE_KEY LW_BOT_ID LW_CHANNEL_ID を入れる（両方のドキュメントに同じ値）。 LW_PRIVATE_KEY は Developer Console からダウンロードした private_xxxx.key の中身 （-----BEGIN PRIVATE KEY----- で始まる）をそのまま貼る。入力欄で改行が消えて1行になっても、 改行を文字の \n で書いても、スクリプト側で整形するので動く。 エラーが出るときは Apps Script エディタで checkPrivateKey を実行し、実行ログの診断を見る。
4. ドキュメントを開き直し、メニュー「要項連絡 > LINE WORKS 接続テスト」で部屋にテスト文が届くことを確認する。
5. 片方のドキュメントで seedLedger を実行する。台帳に現在の状態が記録されるだけで通知は出ない。 これを飛ばすと、次の走査で既に「確定」の要項がすべて「確定」として通知される。
6. 同じドキュメントで setupDailyTrigger を実行する。

純粋関数（解析・差分・出来事判定・通知文）は node scripts/test-yoko-notify.mjs で確認できる。

確定前のチェック

node scripts/check-yoko.mjs             # 全件
node scripts/check-yoko.mjs --confirmed # 確定のものだけ（不足があれば exit 1）

必須項目（対象・日程・受講料・申込開始日・申込期限・申込方法・支払い方法・連絡先・ 経理連絡事項（経理記入欄））が書かれているかを見る。あわせて「記入例」「（例：…）」の消し忘れと、 確定済みなのに経理記入欄の「経理記入日」が空のものを指摘する。 要項QAは書かれていることしか答えられないため、確定にする前に通す。

触るときの注意

• knowledge/ の置き場所を変えたら next.config.mjs の outputFileTracingIncludes も直すこと。 Next はコードから辿れないファイルをサーバ関数に含めないため、変え忘れると本番だけ 0 件になる。
• 確定済みの要項は全文がプロンプトに載る。全33件を確定にすると約5万字（≒4万トークン）。 キャッシュが効くので実運用のコストは小さいが、古い要項は knowledge/90_archive/ へ移すか status を戻して外すこと。
• 個人情報は入れない（要項は対外資料なので通常は問題ないが、社内共有メモ等を混ぜないこと）。

適性検査アプリ（講師・事務スタッフ・社員の採用選考）

現行の「塾講師適性検査」（Zinzycle社の受託システム。100問・はい／いいえ・A/B/C判定）を移したもの。 講師（学生パート講師）だけでなく、事務スタッフ・社員も判定できる。設計の詳細は docs/superpowers/specs/2026-10-08-aptitude-test-design.md。

• URL：職員側 /aptitude（メニューの「適性検査」カード）／受検者側 /exam/<トークン>（ログイン不要）
• 開ける部門：管理部門（総務・人事・支援・管理）のみ。lib/aptitude/access.ts ★部門を変えるときはここだけ
• 保存先：Supabase（supabase/migrations/0002_aptitude.sql）。手元の開発だけ .data/aptitude.json。 本番で Supabase が未設定なら画面に「未設定」と出る（個人情報なのでスプレッドシートには置かない）

使い方

1. ［＋ 受検者を登録］で氏名・職種（講師／事務／社員）・拠点（智翔館／NEP／JEO）を入れる
2. 詳細の画面で［受検URLを発行］→［案内文をコピー］して LINE WORKS やメールで送る（メールの自動送信は無い）
   • 有効期限は7日（lib/aptitude/model.ts の TOKEN_DAYS）。［期限を延ばす］［取り消す］ができる。再発行すると前の URL は使えなくなる
   • 紙で受けた人は［紙の回答を入力］で回答用紙と同じ 10×10 のマス目に ○× を入れる（○＝O/Y/1、×＝X/N/2 のキーでも可。まとめて貼り付けも可）
3. 受検者はスマホで開き、説明と同意（利用目的・保存期間）→ フリガナ等の確認 → 1画面10問 × 10ページ。 ページごとに保存されるので、閉じても同じ URL で続きから再開できる
4. 完了すると自動で採点され、詳細の画面に判定・判定の理由・面接での確認ポイント・グラフ・他の職種で見た判定が出る
5. 選考が終わったら「採用結果」を入れる。入社後しばらくしたら「入社後の評価（1〜5）」も入れる（校正用CSVに出る）

採点（lib/aptitude/scoring.ts。テストは npm test）

• 10尺度×10問。設問番号の一の位で尺度が決まる（1＝虚偽、2〜6＝エゴグラム CP/NP/A/FC/AC、7＝ストレス耐性、 8＝情緒不安定・攻撃性、9＝対人回避、0＝未成熟・子ども志向）
• 適性スコア（0〜100）＝ Σ(重み×尺度得点) ÷ Σ(重み×10) × 100 → A/B の基準で A/B/C
• リスク尺度が「注意」以上なら判定は B まで、「要注意」以上なら C。虚偽が高い・回答が速すぎる（平均1秒/問未満）ときは判定を変えず「参考値」
• 重み・閾値・確認ポイントは職種ごと。同じ回答でも職種で判定が変わる（初期値は lib/aptitude/seed.ts。暫定）
• 得点の計算はサーバだけ。受検者には得点・判定・尺度名・設問番号を返さない。設問の表示順は受検ごとにランダム

設問・判定基準を直すとき（/aptitude/master）

• 設問・尺度・判定基準は「版」で持つ。公開中・終了した版は変えられない（結果がその版で計算されているため）
• ［コピーして下書きを作る］→ 下書きを直す →［公開する］。以降に発行する受検URL・紙回答の入力は新しい版で採点する。 すでに受けた結果は受けたときの版のまま（詳細の画面に版が出る）
• 設問ごとに「反転（いいえで1点）」「使う／使わない」を切り替えられる。使わない設問は採点から外し、尺度の満点を減らして10点満点に換算する
• 備考に「要確認」がある設問（⚠）：
  • 10・20・90・100 … 異性観・家族に関する設問。公正な採用選考（厚労省）の観点で、許諾の範囲で削除・差し替えできるか確認する
  • 17・57・97 … ストレス耐性の反転項目かどうか未確認（初期値は「はい」で加点）。Zinzycle社の資料と照合する
• 判定基準は過去の判定・入社後の評価と突き合わせて校正する（一覧の［校正用CSV］。氏名・連絡先は入らない）

権限・記録・保存期間

• 結果の閲覧・CSV出力・紙回答の入力・削除・版の公開などを記録し、詳細の画面の「閲覧ログ」に出す
• 保存期間（lib/aptitude/model.ts の RETENTION）：不採用・辞退になってから 365日、画面で削除してから 30日 で、 受検者・受検・回答・結果を完全に削除する
  • vercel.json の cron が毎日 3:00（JST）に /api/aptitude/purge を叩く。環境変数 CRON_SECRET が必要
  • 手で実行するときは管理部門でログインして /api/aptitude/purge を開く
  • ★日数を変えたら、受検画面の同意文（components/ExamUI.tsx）も確かめる

セットアップ

1. Supabase の SQL Editor で supabase/migrations/0002_aptitude.sql を実行する（dev＝chishokan_dev、本番＝chishokan_prod の2回。手順は supabase/README.md）
2. 門配管理で SUPABASE_URL などを設定済みならそのまま動く。初回に画面を開くと、初期の版（v1：設問100問・判定基準）が自動で入る
3. Vercel に CRON_SECRET を設定する（問合せ管理の cron と共通）

ログ / セキュリティ（テスト版のため要ハードニング）

• 会話は Vercel のログに [CHAT_LOG] として出力。durable 保存は lib/core/log.ts で DB 追加。
• 認証は簡易版（氏名＋校舎＋合言葉）。本番は Google SSO 等へ。
• ログを人事評価に使う場合は社員への周知・同意を。API キーはサーバ環境変数のみ。