Claudeで学会発表の要旨(アブストラクト)を規定の字数に収める手順
学会の募集要項から字数・構成・図表可否を抜き出し、研究メモの数値を台帳にして規定内の要旨案を作る手順。字数の数え直しと、圧縮で落ちやすい数値・限定語の点検まで示します。
学会発表の要旨が差し戻される理由は、研究の中身より規定です。「800字以内」「背景・目的・方法・結果・結論の順」「図表は不可」といった条件を満たさないまま提出すると、査読に回る前に修正を求められます。
ClaudeのProjectsに募集要項と研究メモを置き、規定を先に表へ分解してから要旨案を作らせると、字数と構成の食い違いを提出前に潰せます。この記事は、規定の読み出し、研究メモの整え方、圧縮の指示、字数の数え直しを順に示します。
先に決めるのは「何字で、どう数えるか」
「800字以内」とだけ書かれた規定でも、数え方は複数あります。タイトルや著者名、キーワードを含めるのか、スペースや改行を数えるのか、全角と半角を同じ1字とするのかで、同じ文章の字数が変わります。
要旨案を作らせる前に、募集要項からこの条件を表に抜き出します。表の項目は次のとおりです。
| 項目 | 確認すること | 募集要項に書かれていないとき |
|---|---|---|
| 字数の上限 | 確認すること本文のみか、タイトル・著者・キーワードを含むか | 募集要項に書かれていないとき学会の事務局に問い合わせる |
| 字数の下限 | 確認すること下限の有無 | 募集要項に書かれていないとき下限なしとは決めつけない |
| 数え方 | 確認することスペース・改行・全角半角の扱い | 募集要項に書かれていないとき学会指定の書式ファイルのカウントに合わせる |
| 構成 | 確認すること必須の見出し、順序、見出し自体の字数算入 | 募集要項に書かれていないとき構造化要旨か自由形式かを確認 |
| 図表 | 確認すること要旨に図表を入れてよいか | 募集要項に書かれていないとき入れない前提で作る |
| 参考文献・謝辞 | 確認すること要旨内に書くか、字数に入るか | 募集要項に書かれていないとき入れない前提で作る |
| 言語 | 確認すること日本語要旨か英語要旨か、両方か | 募集要項に書かれていないとき両方求められる場合は字数も別々に確認 |
右の列は、規定が沈黙しているときの扱いです。ここを埋めずに進めると、Claudeが一般的な要旨の常識で補い、募集要項に無い条件を前提にした文面ができます。
Projectsに置くものと、置き方の注意
Projectsは、独自のチャット履歴とナレッジベースを持つ作業場です。文書をナレッジベースに置くと、そのプロジェクト内のチャットで文脈として使われます。プロジェクトごとの指示も設定できます。
置くものは3種類です。
- 募集要項(ファイル名に取得日を入れる。例:
callforabstracts_2026-10-20.pdf) - 研究メモ(結果の数値と手法の要点をまとめたもの)
- 規定の表と、前年度の採択要旨など書式の見本(あれば)
置き方で押さえる点が3つあります。
- プロジェクトの名前と説明はClaudeに渡されません。学会名や発表区分(口頭かポスターか)は、名前に入れるだけでなく、ファイルか指示の中にも書きます
- チャットをまたいで文脈は共有されません。規定の表をナレッジベースにファイルで保存しておかないと、別のチャットでは参照できません
- 無料プランで作れるプロジェクトは最大5つです。学会ごとにプロジェクトを分けると上限に近づくため、終わった学会の分は退避します
ここで述べた画面と動作は、Projectsの現行版の説明に沿っています。新しい版のProjects(ベータ)が一部のPro・Maxユーザーに順次提供されており、画面や挙動が異なる場合があります。
ファイル形式と読み取りの範囲
アップロードできる文書形式には、PDF、DOCX、TXT、HTMLなどがあります。プロジェクトのファイルは1ファイル30MBまでです。
読み取りの範囲は形式で違います。Word形式などのPDF以外では、テキストだけが抽出され、埋め込まれた画像は読まれません。PDFは100ページ以下なら図や表も解析されます。募集要項の中に、図入りの書式例や記入例の画像があるときは、PDFで置きます。
PDFのページを指して聞くときは、紙面に印字された番号ではなく、PDFビューアーに表示される番号を使います。
研究メモを「事実台帳」にしてから要旨に進む
要旨の圧縮でいちばん起きやすい事故は、字数を減らす過程で数値や条件が落ちる、または別の言い回しに変わることです。これを防ぐため、研究メモを要旨にする前に、番号付きの台帳に整えます。
台帳の1行は、要旨に書きうる主張1つです。
| ID | 区分 | 内容 | 数値・条件 |
|---|---|---|---|
| F1 | 区分背景 | 内容先行研究の到達点と未解決の点 | 数値・条件引用する文献の著者年 |
| F2 | 区分目的 | 内容何を明らかにするか | 数値・条件 |
| F3 | 区分方法 | 内容対象、手法、期間 | 数値・条件対象数、群の数、期間 |
| F4 | 区分結果 | 内容主要な結果 | 数値・条件効果量、p値、信頼区間など |
| F5 | 区分結論 | 内容結果から言えること | 数値・条件一般化できる範囲の限定 |
台帳を作る指示では、研究メモに書かれていない数値や結論を足さないことを明示します。
research_notes.docx を読み、要旨に書きうる主張を
「ID / 区分 / 内容 / 数値・条件 / メモ内の根拠箇所」の表にしてください。
区分は、背景・目的・方法・結果・結論の5つです。
- メモに書かれていない数値、手法、結論を足さないでください
- 数値は、メモの表記のまま(桁数、単位、有意水準)写してください
- メモの記述が曖昧な項目は、推測で埋めずに「要確認」と書いてください台帳は、著者がメモと見比べて検収します。確かめるのは、数値がメモと一致しているか、「要確認」の項目を著者が埋めたか、結論の範囲が研究の対象を超えていないか、の3点です。検収した台帳は facts_checked.docx のような名前でプロジェクトに保存します。
規定内の要旨案を作らせる
台帳と規定の表がそろったら、新しいチャットで要旨案を作らせます。指示のポイントは、台帳の番号で主張を指定させることと、字数の配分を先に決めることです。
字数の配分は、構成の各区分に割り振ります。たとえば800字なら、次のように決めてから書かせます。この比率は例であり、学会や分野で変わります。
| 区分 | 配分の例 | 台帳の行 |
|---|---|---|
| 背景 | 配分の例150字 | 台帳の行F1 |
| 目的 | 配分の例100字 | 台帳の行F2 |
| 方法 | 配分の例200字 | 台帳の行F3 |
| 結果 | 配分の例250字 | 台帳の行F4 |
| 結論 | 配分の例100字 | 台帳の行F5 |
requirements_table_checked.docx の規定に従い、
facts_checked.docx の台帳から要旨案を作ってください。
- 構成は規定の順序と見出しに合わせます
- 区分ごとの字数は、背景150・目的100・方法200・結果250・結論100を目安にします
- 各文の末尾に、根拠にした台帳のIDを [F4] の形で付けてください
- 台帳にない数値や主張は書かないでください
- 書き終えたら、全体の字数と区分ごとの字数を、数え方を添えて示してください文末にIDを付けさせるのは、要旨のどの文がどの事実に基づくかを、著者があとから追えるようにするためです。提出用の文面にはIDを残さず、検収が終わってから削ります。
字数は数え直す
Claudeが示した字数は、そのまま採用せず、著者が一度確かめる値として扱います。理由は、数え方の定義が学会ごとに違うためで、Claudeの数え方と学会の数え方が一致するとは限りません。
確かめ方は2通りあります。
- 要旨案をWordなどに貼り、文字数カウントを学会の数え方に合わせて読む。スペースを含めるか否かは、カウント機能の設定で切り替えられる
- Claudeにコード実行で数えさせ、除外した範囲を答えに書かせて、手元の数と照らす
コード実行とファイル作成は、Free・Pro・Maxプランでは既定で有効です。Team・Enterpriseプランでは組織の管理者が無効にしている場合があります。使える環境なら、数える処理は次の考え方で指示できます。
import re
text = open("abstract.txt", encoding="utf-8").read()
# 数え方の例: 改行と空白を除いた文字数
no_space = len(re.sub(r"\s", "", text))
# 数え方の例: 空白を含め、改行のみ除いた文字数
with_space = len(text.replace("\n", ""))
print(no_space, with_space)この断片は考え方の例です。規定が「半角2字を全角1字と数える」ような換算を求めるなら、その換算を指示に書き足します。2つの数え方で結果が大きく違うときは、募集要項の記述をもう一度読み、どちらが規定に合うかを著者が決めます。
数が合わないときの原因は、たいてい数え方の違いです。タイトルや見出しの算入、記号の扱い、改行の扱いの3点から見ます。
圧縮で落ちるもの、変わるものを点検する
字数を詰める指示を重ねるほど、意味が変わる危険が増えます。規定に収まった要旨案は、次の観点で台帳と突き合わせます。
| 点検すること | 起きやすい変化 | 見方 |
|---|---|---|
| 数値 | 起きやすい変化桁、単位、有意水準が落ちる | 見方要旨の数値を台帳の数値と1つずつ照合 |
| 限定語 | 起きやすい変化「一部の条件で」「本研究の対象では」が消える | 見方結論の文の限定語を台帳F5と比べる |
| 因果と相関 | 起きやすい変化「関連した」が「影響した」に変わる | 見方動詞を台帳の記述と見比べる |
| 略語 | 起きやすい変化初出の正式名称が落ちる | 見方略語の初出に正式名称があるか |
| 新規の主張 | 起きやすい変化台帳にない一般論が足される | 見方文末のIDが付いていない文を探す |
結論の限定語は、圧縮でもっとも削られやすい部分です。「〜が示唆された」を「〜が明らかになった」に変えると、字数は減っても主張が強くなります。強さを変える修正は、字数のためであっても著者が判断します。
詰める順序を指示しておく
字数が足りないときに何を削るかを決めておかないと、Claudeが結果や方法の中身から削ることがあります。削る順序を先に指示します。
- 背景の一般的な説明(先行研究の列挙は最小限にする)
- 方法の詳細(測定器の型番や手順の細部)
- 重複している表現や、前後の文で言い直している箇所
- 結論の一般論(研究の範囲を超えた意義づけ)
結果の数値と結論の限定語は、削る対象から外します。これは台帳の「数値・条件」列に書いたものと一致します。
図表と参考文献の扱い
募集要項が図表を不可としているなら、図表で示すはずだった結果を文章で書き直す必要があります。このとき、要旨に収まるのは主要な結果1〜2点です。台帳の結果の行に優先順位を付けておくと、Claudeがどれを残すかを迷いません。
引用文献は、要旨内に書く形式と字数への算入が学会ごとに違います。規定の表で確認した条件に従います。本文中の引用と文献リストの対応を点検する手順は、卒論を例にしたClaudeで卒論の参考文献と本文引用を点検する手順がそのまま使えます。
投稿規定との違いと、採択後の流れ
学会要旨の規定は、論文の投稿規定より項目が少ない一方、字数が厳しく、1文ごとの削り方が採否を左右します。規定の全項目を点検するチェック表の作り方はClaudeで論文の投稿規定への適合をチェック表で点検する手順にあり、本記事の規定の表はその簡易版にあたります。
採択後の査読コメントへの回答はClaudeで査読コメントへの回答書を下書きするで扱っています。発表用の図をmatplotlibで描くなら、Claude Codeでmatplotlibの論文図を投稿規定のdpiとフォントに揃えるの手順が使えます。
知識ベースが大きくなったときの落とし穴
有料プラン(Pro、Max、Team、Enterprise)では、プロジェクトの知識がコンテキストウィンドウの上限に近づくと、RAGモードに自動で切り替わります。RAGモードでは、プロジェクト知識検索ツールで関連箇所を探して答えるため、容量は最大10倍まで広がります。
過去の学会の要項や、何版もの研究メモを置いたままにすると、RAGに入りやすくなります。検索で拾われなかった条項が点検から落ちる可能性があるため、次の対策を取ります。
- 規定は、全項目を表の行として固定し、1行ずつ照合させる。規定を探させる使い方をしない
- ファイル名は中身が分かる名前にし、聞くときに文書名を指定する
- 終わった学会の要項と、古い版のメモは、プロジェクトから外す
未発表の研究を置く前に確認すること
要旨の段階の研究は、多くが未発表です。Team・Enterpriseプランでは、プロジェクトを組織のメンバーと共有できます。権限は「閲覧のみ」と「編集可」の2段階で、管理者が共有を止めている組織では使えません。個人のプロジェクトでも、共有設定が意図どおりかは、置く前に確かめます。
共同研究者や企業との契約、所属機関の方針で、未発表データを生成AIに入力できない場合があります。入力してよいかは、所属機関と共同研究先の規程で決まります。置く前に、その点を確認してください。
よくある質問
英語の要旨と日本語の要旨の両方が必要なときは
日本語の要旨を先に確定してから、英語を作ります。英語の字数(語数)の数え方は日本語と別に確認します。英訳した結果の数値と限定語は、台帳と照合して著者が確かめます。
発表形式が口頭とポスターで要旨の規定が違うときは
規定の表を発表形式ごとに分け、ファイル名に区分を入れます。2つの表を同じチャットで渡すと混ざるため、要旨案はチャットを分けて作ります。
採択後に要旨を修正するよう求められたときは
修正後の規定と、修正前の要旨、査読者のコメントをプロジェクトに置き、変更箇所の台帳IDを追って直します。IDを付けておくと、どの事実に手を入れたかを追えます。