調査日 2026-04-28 / Exa 4 サブエージェント並列 / 約292,000 tokens 精査 / 信頼度 高

学会演題登録〜査読移行システム 調査と実装プラン

Googleフォーム+GAS で演題登録 → Supabase で査読基盤 へ段階拡張するための、フィールド設計・実装パターン・段階別ロードマップ。
目次
  1. エグゼクティブ・サマリー
  2. 国内医療系学会の標準フィールド
  3. 査読移行用メタデータ(追加18列)
  4. Google Forms+GAS 連携パターン比較
  5. OSS/SaaS データモデル
  6. 実装プラン(Claude Code 一気通貫)
  7. 出典 URL

1. エグゼクティブ・サマリー

既存の抄録CSVスキーマv1(23列)は「抄録集の再構成」には十分だが、査読プロセス管理・COI構造化・査読者マッチング・通知CC・改訂履歴が欠落している。必須12列+任意6列=計18列を追加し、スキーマv2(41列)として運用すると、Phase 1(GAS+Sheets)→ Phase 2(Supabase)→ Phase 3(高度な査読UI)への段階拡張が破綻なく進む。

Phase 1: 1週間でMVP 既存スキル create-google-form 活用 100演題超で Supabase 移行 倫理項目 独立必須(無いと無効化)

主要な決定事項

追加列数
18列(必須12 / 任意6)→ v2 合計 41列
推奨実装順
Phase A(GAS HTML Service 査読UI / 1週間)→ Phase B(Supabase 同期 / 追加2週間)→ Phase C(改訂管理 / 追加2週間)
最重要の落とし穴
「倫理的配慮・説明と同意」200〜300字独立フィールドが無いと演題無効化(神経理学療法学会で明示)
共同演者上限
学会差大: 5名(作業療法)〜 15名(地域PT・神経PT)→ 設計は 15名対応で統一
抄録本文最長
3,000字(作業療法学会)に合わせれば全学会対応可能
COIの扱い
抄録内には記載しない。別シート保管 + 発表時スライド2枚目で開示
参照モデル
HotCRP(Bid+Topic マッチング)+ EasyChair(Meta-Review)が学術会議向けに最適
CRITICAL: 倫理項目を本文に統合する設計は避ける。Googleフォームのセクション分割で必ず独立フィールド化すること。複数学会で「無いと登録無効」明示。

2. 国内医療系学会の標準フィールド

2-1. 演者情報

フィールド必須制約・典型値出典学会
筆頭演者 氏名 + フリガナ必須テキスト全学会共通
筆頭演者 所属 + フリガナ必須複数施設対応全学会共通
筆頭演者 職種必須プルダウン20職種(PT/OT/ST/医師等)訪問リハ・作業療法
筆頭演者 会員番号条件付き協会会員8桁、非会員"0000"地域PT・神経PT
筆頭演者 メール必須受付通知用全学会
共同演者 氏名・所属任意5名(作業療法)〜15名(地域PT・神経PT)全学会
共同演者 フリガナ必須プログラム印刷用全学会
所属施設数 上限必須5施設訪問リハ・神経PT

2-2. 演題情報・文字数の典型値

フィールド典型値学会幅
演題名(日本語)50〜60字神経PT 50字 / 訪問リハ 60字
演題名(英語)25 words老年医学・神経PTで併記要件
抄録本文(日本語)600〜3,000字訪問リハ600 / 地域PT1,200 / 作業療法 3,000(最長)
倫理的配慮・説明と同意200〜300字独立フィールド・無いと無効化
キーワード3〜4個キーワード集3個 + 自由記述1個
総計上限750〜1,500字演題名 + 抄録 + 倫理の合計

2-3. 倫理・コンプライアンス

項目必須注記
倫理委員会承認番号必須「○○大学倫理委員会承認(承認番号:XXXX)」
患者同意取得必須チェック + 文章記載「説明と同意を得た」
COI 申告発表時必須抄録には不要 / スライド2枚目に過去1年の提供機関・金額
二重投稿確認必須「他学会未投稿」誓約
著作権譲渡一部学会老年医学・作業療法

2-4. 学会別差分の早見表

学会抄録最長共同演者上限倫理要件ユニーク要件
老年医学930字10名英語併記推奨
作業療法 第59回3,000字(最長)5名(最少)KW 3+自由1
地域PT1,200字15名高(300字独立)所属5施設
神経PT 第23回1,000字15名最高(無効化リスク)倫理200字独立
訪問リハ600字15名COI厳格

3. 査読移行用メタデータ(追加18列)

3-1. 査読者マッチング(5列)

列名必須用途
primary_keywordsTEXT (CSV/JSON)必須TPMS 自動マッチング、MeSH or 学会独自分類
keywords_normalizedJSON必須辞書照合結果フラグ
topic_category_primaryENUM必須一次分類(neurology / geriatrics / rehab)
topic_category_secondaryENUM任意副分類
reviewer_exclusion_listJSON array任意演者指定の除外査読者ID

3-2. COI・査読除外(4列)

列名必須用途
coi_declaration_statusENUM必須none / declared / pending_review
coi_financialJSON必須金銭的COI(パテント/グラント/講演料/株主)
coi_non_financialJSON必須非金銭的COI(親族/同一所属/恩義)
coi_competing_interests_textTEXT任意自由記述補足欄

3-3. 査読プロセス管理(4列)

列名必須用途
submission_idUUID/STRING必須自動採番、改訂版も同一ID
submission_timestampTIMESTAMP必須初回投稿確定日時(タイムゾーン含む)
review_statusENUM必須submitted → assigned → under_review → decision_pending → major_rev/minor_rev/accepted/rejected
revision_roundINT必須初回0、改訂回数でインクリメント

3-4. 通知(3列)+ 改訂・採否(3列)

列名必須用途
corresponding_author_emailEMAIL必須査読通知主送信先
notification_cc_listJSON array任意CC通知(指導教員・所属長)
communication_language_preferenceENUM任意ja / en
revision_deadlineTIMESTAMP任意決定通知から自動計算(例:30日後)
revision_history_jsonJSON array任意改訂版履歴(version, ts, by, summary)
editor_decision_textTEXT任意エディタ決定理由・テンプレ選択

3-5. 段階別実装優先度

Phase 1(査読化の最初の山)必須7列
submission_id / submission_timestamp / review_status / revision_round / primary_keywords / coi_declaration_status / corresponding_author_email
投稿→査読割当→ステータス追跡 の基本ワークフロー成立
Phase 2(査読者自動マッチング)+5列
keywords_normalized / topic_category_* / reviewer_exclusion_list / coi_financial / coi_non_financial
自動マッチングシステムの導入
Phase 3(高度な改訂管理)+3列
revision_deadline / revision_history_json / editor_decision_text
改訂ワークフロー・採否理由の詳細追跡

4. Google Forms+GAS 連携パターン比較

パターンコスト実装期間スケールUI自由度推奨規模
A. GAS HTML Service無料2〜3日〜100演題小〜中
B. Firestore/Supabase 同期無料〜従量5〜7日大規模100演題+
C. n8n/Zapier Webhook$0〜$20/月3〜4日自動化重視
D. 既存査読SaaS(HotCRP等)¥3,000〜/月0日業界標準大規模学会
E. メール+手動無料1日〜20演題超小規模
推奨: パターン A(GAS HTML Service)でMVP → 演題100超で Supabase(Phase B)に段階移行。Google Workspace 完結 / 既存スキル create-google-form + テンプレート ~/work/rehab-data/forms/_template/ ですぐ着手可能。

サンプルコード抜粋(onFormSubmit + 査読者割当 + リマインダー)

// onFormSubmit: 受付番号採番 + 査読者割当 + メール通知
function onFormSubmit(e) {
  const ts = e.timestamp;
  const r = e.namedValues;

  const submissionId = generateSubmissionId(); // CONF2026-00001
  const reviewer = assignReviewer(r['カテゴリ'][0]);

  const sheet = SpreadsheetApp.getActive().getSheetByName('submissions');
  sheet.appendRow([
    submissionId, ts, 'submitted', 0,
    r['キーワード'][0], r['カテゴリ'][0],
    r['筆頭演者メール'][0], reviewer.id
  ]);

  GmailApp.sendEmail(reviewer.email,
    `査読依頼: ${r['演題タイトル'][0]}`,
    `演題: ${r['演題タイトル'][0]}\n受付番号: ${submissionId}\n` +
    `ダッシュボード: ${getReviewDashboardUrl()}\n` +
    `査読期限: ${addDays(ts, 14).toLocaleDateString()}`
  );

  GmailApp.sendEmail(r['筆頭演者メール'][0],
    `[${submissionId}] 演題登録を受付ました`,
    `受付番号: ${submissionId}\n査読期間: 約2週間`
  );
}

// time-driven trigger: 査読期限72h前リマインダー
function remindOverdue() {
  const sheet = SpreadsheetApp.getActive().getSheetByName('submissions');
  sheet.getDataRange().getValues().forEach(row => {
    const [id, ts, status, , , , , reviewerId] = row;
    if (status !== 'assigned' && status !== 'under_review') return;
    const deadline = addDays(new Date(ts), 14);
    const hours = (deadline - Date.now()) / 3600000;
    if (hours > 0 && hours < 72) {
      const reviewer = lookupReviewer(reviewerId);
      GmailApp.sendEmail(reviewer.email,
        `[リマインド] ${id} 査読期限まで残り${Math.round(hours)}時間`,
        `${getReviewDashboardUrl()}?sid=${id}`);
    }
  });
}

参考実装

5. OSS / SaaS データモデル

HotCRP(推奨度 ★★★★★)

データモデル
papers / reviewers / review_assignment / reviews / topics / paper_topics
マッチング
Bid(−100〜20)+ Topic Expertise + Conflict 自動検出
ライセンス
BSD(GitHub
実績
大規模国際会議多数

OJS / OCS(PKP)

フロー
Submission → Review → Copyediting → Production
特徴
Revision Round 管理 / Editorial History トラッキング
ライセンス
GPL(公式

EasyChair(推奨度 ★★★★)

特徴
軽量実装 / Topic Expertise + Meta-Review 機能
実績
国際ワークショップで採用多数(公式

Confit(杏林舎)— 国内デファクト

特徴
国内学会標準 / 詳細スキーマは非公開
採用
JSPT系含む多数(公式

標準化データモデル(独自実装の参考)

1. submissions       (id, title, abstract, keywords, track, authors, status, dates)
2. reviewers         (id, email, name, affiliation, expertise_keywords, max_reviews, conflicts)
3. review_assignments(id, submission_id, reviewer_id, invitation_date, deadline, status)
4. reviews           (id, assignment_id, score, recommendation, comments, anonymous)
5. decisions         (id, submission_id, final_decision, decision_date, decided_by, reason)
6. revisions         (id, submission_id, revision_round, due_date, new_files, author_response)
7. meta_reviews      (id, submission_id, meta_reviewer_id, summary, final_recommendation)
流用すべき: COI 自動検出(メールドメイン照合 + 自由申告)/ Reviewer Bidding / Topic-based Matching / Round-trip Revision / CSV Export
避けるべき: 一度に全ユーザー登録(→ 分割招待)/ Review と Decision を同テーブル混在 / Keyword をフリーテキストのみ / 複数言語を初版で対応

6. 実装プラン(Claude Code 一気通貫)

Phase 1(1週間): Google Forms + GAS HTML Service 査読UI

Dayタスク成果物
1フォーム生成(create-google-form Skill / Sec.2 のフィールド網羅 / 共同演者15名対応)~/work/rehab-data/forms/{学会名}-cfp/
2onFormSubmit トリガー: 受付番号採番(CONF2026-XXXXX)/ submissions シート記録 / 演者受付メールCode.gs 拡張
3査読者マスタシート(id, name, email, expertise_keywords, max_reviews, available)+ ラウンドロビン割当ロジックreviewers シート + assignReviewer()
4GAS HTML Service 査読UI(doGet で割当一覧 / google.script.run で reviews シートへ書き込み)dashboard.html + saveReview()
5査読者通知メール(割当時 + 期限72h前リマインダー)/ time-driven trigger 設定notify.gs + 定期実行
6採否決定UI(chair 専用 / 投票集計 / 演者への結果通知)decide.html + sendDecision()
7統合テスト(テスト演題3件 + 査読者2名 + 採否) / README整備 / 学会本番デプロイテスト記録 + 公開URL

Phase 2(追加2週間): Supabase 同期で大規模対応

トリガー: 演題数100超 or 査読者20超

  1. saas/endai-system 流用 / Supabase に submissions / reviewers / reviews / decisions テーブル作成(v2 41列準拠)
  2. onFormSubmit から Supabase REST API への二重書き込み → 切替期間後シートを read-only 化
  3. RLS 設定: 査読者は自分の割当のみ閲覧 / chair は全件 / 演者は自演題のみ
  4. Next.js 査読UI(既存 endai-system パターン流用 / shadcn-ui / Tanstack Query)
  5. 査読者自動マッチング: topic_category_primary + keywords_normalized + reviewer_exclusion_list で MILP 風スコアリング

Phase 3(追加2週間): 改訂管理・採否ワークフロー

既存資産との接続マップ

~/work/rehab-data/forms/_template/        → フォーム雛形(Code.gs/appsscript.json/README.md)
~/work/knowledge/abstract-csv-schema.md   → v1 23列 + Phase1で +7列、最終 v2 41列
~/work/saas/endai-system/                 → Phase 2 で Supabase 移行先(要連携調査)
~/work/docs/abstract-builder/             → 抄録集 PDF 生成(採択後の最終出力)
~/.claude/skills/create-google-form/      → Step 1-3 自動化

Claude Code への次の指示テンプレ(Phase 1 着手時)

1. /create-google-form  [学会名]
   → Sec.2 のフィールド定義を CONFIG に流し込む

2. ~/work/knowledge/abstract-csv-schema.md  に v2 列定義を追記
   → Sec.3-5 Phase 1 の7列をマージ

3. Code.gs に Sec.4 のサンプルコード
   (onFormSubmit + assignReviewer + remindOverdue)を実装
   → reviewers マスタシート手動入力後に testTrigger() で動作確認

リスクと対策

リスク対策
Google Forms の制約(条件分岐の表現力低い)学会別バリデーションは Code.gs 側で実装
GAS の実行時間制限(6分/run)査読者多数時は dispatch を分割 / time-driven trigger で分散
COI構造化データを抄録に混入スプレッドシート列を分離、エクスポート時に除外
倫理項目(300字独立)を本文に統合フォーム設計時から独立フィールド化(Skill CONFIG で type=para)
後発の Supabase 移行時のデータ整合性submissions シートに submission_id(不変)を必ず設置

7. 出典 URL

国内学会

標準・データモデル

OSS / SaaS

実装事例