結論:大学研究室の論文管理業務は、Claude Code を「PDF要旨抽出パイプライン」「BibTeX 整形ボット」「進捗ダッシュボードジェネレータ」として組み込むことで、サーベイ初動から卒論レビュー対応までの所要時間を体感で半分以下に圧縮できる想定が立ちます。学術判断そのものは研究者が握り続け、Claude Code は「読む候補を絞る・形を整える・状態を見える化する」周辺工程を担当させるのが現実的な落としどころです。
要点:
- 先行研究サーベイは「検索キーワード設計 → 要旨スクリーニング → メタ情報抽出」をスクリプト化することで、人間が判断に集中できる状態を作れる
- Zotero / Mendeley の BibTeX エクスポートを Claude Code でリンタ的に整え、共著者間で揺れがちな表記を共通フォーマットに寄せられる
- 卒論・修論の進捗は
.mdファイルベースで管理し、章ごとの語数・図表数・引用数を Claude Code に集計させて週次レポート化すると、指導教員レビューが噛み合いやすくなる
対象読者:修士課程・博士課程の大学院生、研究室を運営する助教・准教授・教授、研究室の RA(リサーチアシスタント)、論文を書くたびに Mendeley と Word の往復で疲弊している学部4年生。
今日読めること:Claude Code を研究室業務に組み込む 5 本のプロンプト・コード例、研究倫理上の注意点、Zotero / Mendeley 連携のスクリプト、卒論進捗ダッシュボードの最小構成、よくある失敗パターンの回避策。
はじめに:「読む論文の山」が研究を止めていた話
研究室の現場で起きていることを、まず一つ書かせてください。これは特定の誰かの話ではなく、私(佐藤)が複数の大学の研究者と Claude Code 導入の話をしてきた中で、繰り返し聞いてきた「あるある」を合成した、想定シナリオとしての描写です。
修士 2 年の学生 A さんは、修論の中間発表まで残り 6 週間。指導教員からは「先行研究のサーベイがまだ薄い、関連分野の論文をあと 30〜50 本は読み込んで」と指示されました。Google Scholar で検索キーワードを打ち込むと、ヒットは 1,400 件。タイトルとアブストを眺めて関連がありそうなものをポチポチ Mendeley に放り込んでいくのですが、気づけば「ダウンロードした PDF が 60 本フォルダに溜まっているのに、要旨を読み終えたのは 8 本」という状態。さらに、参考文献の BibTeX をエクスポートすると、ジャーナル名が略記揺れ(Proc. Natl. Acad. Sci. U.S.A. と PNAS が混在)、著者表記が Smith J と Smith, J. でバラバラ、DOI が抜けているエントリも散見される。これを手で直していたら 1 日が終わります。
こうした「読むのに辿り着く前で詰まっている」「形式の整備で疲弊している」状態を、Claude Code を CLI 兼スクリプトランナーとして使うことで、かなり手前に押し戻せます。本記事では、研究室の論文管理業務に Claude Code を組み込む想定シナリオを 5 本のプロンプト・コード例とともに紹介します。
もう少し具体的に書くと、私がこれまでに研究室の助教・大学院生と話してきた中で、Claude Code が刺さりやすい場面は次のような兆候が見えるときでした。「Mendeley のフォルダに『あとで読む』タグが付いた PDF が常に 100 本以上ある」「BibTeX を共著者から受け取るたびに、自分のスタイルに直す手作業が発生している」「卒論の進捗を聞かれても、感覚値でしか答えられない」「英文論文の精読ノートが、Word ファイルとして散在しているが、後で検索できる構造になっていない」。一つでも当てはまる研究室であれば、本記事のスクリプトは、ほぼそのままワークフローに組み込めると思います。
逆に、Claude Code を組み込んでもあまり効かない場面もあります。たとえば「サーベイ自体が必要なほど論文を書いていない」「すでに自前で完璧な BibTeX 管理スクリプトが Git で運用されている」「研究室の文化として、AI ツールを使うこと自体が許容されていない」といった状況です。前者 2 つは投資対効果の問題、最後の 1 つは文化・ポリシーの問題なので、研究室全体の合意形成から始める必要があります。後者については本記事の「研究倫理と AI 利用」セクションで詳しく扱います。
重要な前置きとして、Claude Code は「サーベイ補助」「形式整備」「進捗の見える化」を担当する道具であり、学術的な妥当性判断・引用の正当性・新規性の評価は、研究者本人と指導教員が責任を持って行うものです。本記事のスクリプトはすべて、最終チェックを人間が行う前提で設計します。
想定シナリオ全体像:研究室業務のどこに Claude Code を差し込むか
研究室の論文関連業務を、ざっくり 5 つの工程に分けて整理します。それぞれに Claude Code を差し込むポイントと、人間が握り続けるべき判断が存在します。
| 工程 | 従来の進め方 | Claude Code を入れた後 | 人間が握る判断 |
|---|---|---|---|
| 1. 検索キーワード設計 | 頭に浮かぶ単語で Google Scholar 検索 | 研究課題の英訳・同義語展開・関連分野キーワード提案 | 分野固有の専門用語の追加、検索範囲の最終決定 |
| 2. 要旨スクリーニング | タイトル+アブストを目視で 1 本ずつ判断 | PDF を一括で読み込み、関連度スコア+抽出要旨を表形式で出力 | 関連度スコアの境界線、最終的に読む候補の決定 |
| 3. 文献メタ情報整理 | Zotero / Mendeley に手で入力、BibTeX が揺れる | BibTeX を一括リンタ的に整形、欠損 DOI 検出 | 引用スタイル(APA / IEEE / 学会指定)の選定 |
| 4. 英文論文の和訳ノート作成 | DeepL に貼って、自分でメモを Word に転記 | セクションごとに和訳 + 主要主張・実験条件・限界を抽出 | 翻訳精度の最終確認、専門用語の訳語統一 |
| 5. 卒論・修論進捗の可視化 | 章ごとに Word で書く、進捗は感覚値 | 章ごとの語数・図表数・引用数を集計、週次レポート生成 | 章構成の妥当性、議論の論理一貫性 |
この 5 工程のうち、ボトルネックになりやすいのが「2. 要旨スクリーニング」と「3. 文献メタ情報整理」です。サーベイの初動で 30〜50 本の要旨を読む作業に 1 週間溶かすか、3 日で抜けるかで、研究全体のスピードが変わります。
実装手順 1:先行研究の検索キーワード設計をエージェント化する
サーベイの初動で多くの大学院生がつまずくのが、「自分の研究テーマを、英語論文の検索に通じる適切なキーワード列に翻訳する」工程です。日本語で「視線計測を使ったユーザビリティ評価」と書いても、論文検索では eye tracking / gaze tracking / usability evaluation / fixation analysis など複数の単語の組み合わせ、さらにブール演算子を含めて初めて適切なヒットが返ります。
Claude Code を起動して、研究テーマと初期キーワードを渡し、検索戦略を組み立ててもらうプロンプトの例を示します。
あなたは大学院生のリサーチアシスタントです。
私の研究テーマは「○○○○○」(日本語で記述)です。
以下を出力してください:
1. 研究テーマの英語ワンセンテンス要約(30 words 以内)
2. 主要キーワード(5-8 個、英語、同義語含む)
3. 関連キーワード(10-15 個、隣接分野・周辺手法)
4. Google Scholar 用検索クエリ案(ブール演算子付き)を 5 パターン
- 広いクエリ(recall 重視)
- 狭いクエリ(precision 重視)
- 過去 5 年限定クエリ
- レビュー論文限定クエリ
- 否定演算子付きクエリ(除外したい単語あれば明記)
5. 検索対象として有用と思われるジャーナル名・国際会議名のリスト(最低 8 件)
出力は Markdown のテーブル形式で。
各クエリには「想定ヒット件数のオーダー」と「絞り込みのコツ」も併記してください。
このプロンプトのポイントは、「広い検索」と「狭い検索」を両方出させること、ジャーナル・会議名まで出させることです。分野によっては Nature / Science のような総合誌よりも、その分野の専門会議(ACL、NeurIPS、CHI、IEEE VIS など)の方が一次情報として価値が高い。Claude にこのリストを出させたうえで、人間が「この会議は分野的に違う」「これは追加したい」と編集する流れが現実的です。
なお Claude Code は CLI 上で対話的に動くので、出力をそのまま ~/research/keywords.md のようなファイルに保存し、後段のスクリプトから参照できます。研究室全体でこのファイルを Git 管理しておけば、共著者間でキーワード戦略のすり合わせが楽になります。
研究倫理上の注意:検索ログ自体は問題ないが、未公開アイデアの扱いに注意
検索キーワード自体は外部に出ても基本的に問題ありませんが、「研究テーマそのもの」を Claude に詳細に書き込むかどうかは、研究室のポリシー・所属機関のガイドラインに従うべきです。Anthropic の Claude は API 経由のデータを学習に使わない設定が可能ですが、未発表のアイデアを書き込む場合は、Claude for Work / Enterprise 契約や、所属機関での AI 利用ポリシーを確認してから使うのが安全です。
実装手順 2:PDF 文献の要旨抽出を一括スクリプト化する
Mendeley / Zotero でダウンロードした PDF が 30〜50 本溜まっている状態で、「これ全部読むの絶対無理」となるのは大学院生あるあるです。ここで Claude Code に「フォルダ内の PDF を全部開いて、それぞれ要旨を構造化テキストで出力する」スクリプトを書かせて回します。
下記は Python での実装例です。pypdf でテキスト抽出して、Anthropic の API を叩く形を想定しています。Claude Code を CLI から呼び出して、このコード自体を生成してもらうこともできますし、自分で書いたコードを Claude Code にレビューしてもらうこともできます。
"""
survey_screening.py
指定フォルダ配下の PDF を全部読み、各論文の構造化要旨を CSV と
Markdown で出力するスクリプト(想定実装)。
"""
import os
import csv
import json
from pathlib import Path
from pypdf import PdfReader
from anthropic import Anthropic
client = Anthropic() # ANTHROPIC_API_KEY を環境変数で設定済み前提
MODEL = "claude-opus-4-7" # ご利用環境に合わせて選択
PROMPT_TEMPLATE = """\
あなたは大学院生のサーベイ補助 AI です。
以下は学術論文 PDF から抽出した本文テキスト(先頭 12,000 字程度)です。
この論文について、以下の項目を JSON で返してください。
- title: 論文タイトル
- authors: 著者名リスト(最大 8 名、超える場合は最後に "et al." を追加)
- year: 出版年(不明なら null)
- venue: ジャーナル名 or 会議名(不明なら null)
- abstract_ja: 日本語で 200-300 字の要約
- contributions: 著者の主張する貢献 3-5 点(箇条書き、各 1 文以内)
- methods: 使用された手法・モデル・データセット
- limitations: 著者が認めている限界、または読者が気付くべき限界
- relevance_score: 私の研究テーマ「{research_theme}」との関連度を 0-10 で
- relevance_reason: スコアの根拠 1-2 文
==== 論文テキスト開始 ====
{paper_text}
==== 論文テキスト終了 ====
必ず JSON のみを返してください。コードブロックも不要です。
"""
def extract_pdf_text(pdf_path: Path, max_chars: int = 12000) -> str:
reader = PdfReader(str(pdf_path))
text_chunks = []
total = 0
for page in reader.pages:
chunk = page.extract_text() or ""
text_chunks.append(chunk)
total += len(chunk)
if total >= max_chars:
break
return "".join(text_chunks)[:max_chars]
def screen_one_paper(pdf_path: Path, research_theme: str) -> dict:
paper_text = extract_pdf_text(pdf_path)
if len(paper_text) < 500:
return {"error": "text extraction failed", "file": pdf_path.name}
msg = client.messages.create(
model=MODEL,
max_tokens=2000,
messages=[{
"role": "user",
"content": PROMPT_TEMPLATE.format(
research_theme=research_theme,
paper_text=paper_text,
),
}],
)
raw = msg.content[0].text.strip()
try:
data = json.loads(raw)
except json.JSONDecodeError:
return {"error": "json parse failed", "file": pdf_path.name, "raw": raw[:300]}
data["file"] = pdf_path.name
return data
def main(pdf_dir: str, research_theme: str, out_csv: str, out_md: str):
pdf_paths = sorted(Path(pdf_dir).glob("*.pdf"))
results = []
for i, p in enumerate(pdf_paths, 1):
print(f"[{i}/{len(pdf_paths)}] {p.name}")
results.append(screen_one_paper(p, research_theme))
# CSV 出力
fieldnames = ["file", "title", "year", "venue", "relevance_score",
"relevance_reason", "abstract_ja"]
with open(out_csv, "w", encoding="utf-8") as f:
w = csv.DictWriter(f, fieldnames=fieldnames, extrasaction="ignore")
w.writeheader()
for r in results:
w.writerow(r)
# Markdown 出力(関連度順)
sorted_results = sorted(
[r for r in results if "relevance_score" in r],
key=lambda r: r.get("relevance_score", 0),
reverse=True,
)
with open(out_md, "w", encoding="utf-8") as f:
f.write(f"# 先行研究サーベイ結果(テーマ: {research_theme})\n\n")
for r in sorted_results:
f.write(f"## [{r.get('relevance_score')}/10] {r.get('title')}\n")
f.write(f"- 著者: {', '.join(r.get('authors', []))}\n")
f.write(f"- 出典: {r.get('venue')} ({r.get('year')})\n")
f.write(f"- ファイル: `{r.get('file')}`\n\n")
f.write(f"**要旨**: {r.get('abstract_ja')}\n\n")
f.write(f"**貢献**:\n")
for c in r.get("contributions", []):
f.write(f"- {c}\n")
f.write(f"\n**限界**: {r.get('limitations')}\n\n")
f.write(f"**関連度根拠**: {r.get('relevance_reason')}\n\n---\n\n")
if __name__ == "__main__":
main(
pdf_dir="~/research/papers_inbox",
research_theme="視線計測を使ったユーザビリティ評価",
out_csv="~/research/survey_results.csv",
out_md="~/research/survey_results.md",
)
このスクリプトを Claude Code から起動するときは、次のように依頼します。
~/research/papers_inbox/ にある PDF を全部、survey_screening.py で処理して。
研究テーマは「視線計測を使ったユーザビリティ評価」。
処理が終わったら、survey_results.md の中身を関連度スコア降順で先頭 10 件だけ
表形式で要約して表示して。
Claude Code はターミナル経由で python survey_screening.py を実行し、終わったら生成された Markdown を読み込んで、関連度の高いものから先頭 10 件をテーブル化してくれます。これで「30 本の PDF からどの 10 本を本気で読むか」を、人間が判断する段階まで一気に進められます。
API コストの目安
1 本あたり入力 12,000 字 + 出力 2,000 トークン程度なので、Opus 系モデルを使うと 1 本数十円〜100 円弱、Sonnet 系モデルなら 1 本 10〜30 円程度のコスト感です(モデル・契約・為替で変動します)。30 本処理しても数百円〜数千円のオーダーなので、サーベイの初動投資としては十分割に合います。研究費から落とせる範囲か、所属研究室の経理ルールに従って利用してください。
実装手順 3:Zotero / Mendeley の BibTeX を Claude Code でリンタ的に整形する
Zotero や Mendeley から BibTeX をエクスポートすると、共著者間・コレクション間で表記揺れがどうしても出ます。代表的なのは次のパターンです。
- ジャーナル名の略記揺れ(
PNAS/Proc. Natl. Acad. Sci. U.S.A./Proceedings of the National Academy of Sciences) - 著者名の表記揺れ(
Smith J/Smith, John/J. Smith) - DOI 欠損
- BibTeX のエントリ ID(
@article{smith2020,のsmith2020部分)の衝突 - ページ番号のハイフン揺れ(
123-145/123--145)
これを Claude Code に「BibTeX リンタとして振る舞ってくれ」と依頼します。
~/research/references.bib を読み込んで、以下の規則で整形した新ファイル
~/research/references.clean.bib を出力して。
整形ルール:
1. ジャーナル名は IEEE 略記スタイルに統一(不明な場合は元の表記を保持)
2. 著者名は "Last, First Middle" 形式に統一(複数著者は " and " で連結)
3. DOI が欠損しているエントリには [TODO: DOI] というプレースホルダを入れる
4. エントリ ID は "{先頭著者姓Lower}{年}{タイトル先頭単語Lower}" 形式に統一
- 衝突する場合は末尾に a, b, c... を付与
5. ページ番号は "123--145" 形式(LaTeX em-dash)に統一
6. 全エントリのフィールドの順序は title, author, journal, year, volume,
number, pages, doi, url の順に揃える
7. 修正したエントリのリストと、修正できなかったエントリを別ファイル
~/research/bibtex_report.md にレポートとして出力
その後、修正前後の差分を簡単に要約して教えて。
このプロンプトの強みは、「ルールベースで機械処理できる部分」と「曖昧で人間判断が必要な部分」を、Claude が分けて処理してくれることです。完全自動化ではなく、bibtex_report.md に「これは確信が持てなかった」というエントリを残してくれるので、それを人間がチェックする流れになります。
Zotero ユーザーであれば、Better BibTeX for Zotero をすでに使っていることが多いと思います。Better BibTeX のキー生成ルール(auth.lower + year + shorttitle.lower など)と上記の Claude プロンプトのキー生成ルールを揃えておくと、Zotero 側で再エクスポートしたときの整合性も保てます。
失敗しがちなポイント
注意点として、Claude Code に大量の BibTeX エントリを一度に渡すと、コンテキストウィンドウを圧迫します。500 エントリを超えるような大規模ライブラリの場合は、コレクション単位 / 章単位で分割して処理するか、Sonnet 系の長コンテキストモデルを使って、エントリ単位の差分だけを返してもらう設計にした方が安全です。一発勝負で「全部やり直して」と頼むと、途中で出力が打ち切られて、元ファイルより悪い状態の .bib ができることがあります。
実装手順 4:英文論文の和訳ノート作成パイプライン
関連度スコア上位の論文を、いざ精読する段階で多くの大学院生がやっているのが、「DeepL に貼って訳文をコピペ、メモを Word に転記、図のキャプションも翻訳」という手作業の連続です。Claude Code を使うと、これを一つのスクリプトに収められます。
次の例は、PDF から各セクション(Abstract / Introduction / Methods / Results / Discussion)を取り出し、それぞれを和訳 + 要点抽出する構造化ノートを Markdown で生成します。
"""
make_reading_note.py
指定 PDF からセクション分割した和訳ノートを Markdown で生成。
"""
import re
import sys
from pathlib import Path
from pypdf import PdfReader
from anthropic import Anthropic
client = Anthropic()
MODEL = "claude-opus-4-7"
SECTION_HEADERS = [
"Abstract", "Introduction", "Background", "Related Work",
"Methods", "Methodology", "Materials and Methods",
"Experiments", "Experimental Setup",
"Results", "Discussion", "Conclusion", "Conclusions",
"Limitations", "Future Work",
]
NOTE_PROMPT = """\
あなたは大学院生の精読補助 AI です。
以下は英語論文の「{section_name}」セクションのテキストです。
このセクションについて、Markdown で次の構造で日本語ノートを作成してください:
### 和訳(forward translation)
- 段落単位で自然な日本語に訳す(直訳すぎず、研究分野の慣用表現を使う)
### 要点(3 bullets max)
- 著者が言いたいことを 3 つに圧縮
### 専門用語メモ
- 訳語に迷う用語 / 日本語訳が定まっていない用語を 5 つまで列挙
- 各用語に対して「想定される日本語訳の候補」を併記
### 私の研究との接続点(推測 OK、明記すること)
- このセクションが、研究テーマ「{theme}」とどう接続しうるか
- 推測の場合は「(推測)」と明記
==== セクション本文 ====
{section_text}
"""
def split_sections(full_text: str) -> dict:
"""雑にセクション分割。論文によって精度はまちまち。"""
pattern = "|".join(re.escape(h) for h in SECTION_HEADERS)
matches = list(re.finditer(rf"(?im)^\s*({pattern})\s*$", full_text))
sections = {}
for i, m in enumerate(matches):
start = m.end()
end = matches[i+1].start() if i + 1 < len(matches) else len(full_text)
sections[m.group(1)] = full_text[start:end].strip()
return sections
def extract_full_text(pdf_path: Path) -> str:
reader = PdfReader(str(pdf_path))
return "\n".join((p.extract_text() or "") for p in reader.pages)
def make_note_for_section(section_name: str, section_text: str, theme: str) -> str:
if len(section_text) < 200:
return f"### {section_name}\n(テキスト抽出不可、もしくはセクション本文が短すぎます)\n"
msg = client.messages.create(
model=MODEL,
max_tokens=4000,
messages=[{
"role": "user",
"content": NOTE_PROMPT.format(
section_name=section_name,
section_text=section_text[:8000],
theme=theme,
),
}],
)
return f"## {section_name}\n\n{msg.content[0].text}\n\n"
def main(pdf_path: str, theme: str, out_md: str):
full = extract_full_text(Path(pdf_path))
sections = split_sections(full)
print(f"検出セクション: {list(sections.keys())}")
out = [f"# 精読ノート: `{Path(pdf_path).name}`\n",
f"研究テーマ: {theme}\n\n"]
for name, text in sections.items():
print(f"-> {name} 処理中 ({len(text)} chars)")
out.append(make_note_for_section(name, text, theme))
Path(out_md).write_text("".join(out), encoding="utf-8")
print(f"完了: {out_md}")
if __name__ == "__main__":
main(
pdf_path=sys.argv[1],
theme=sys.argv[2],
out_md=sys.argv[3],
)
このスクリプトを Claude Code から呼び出す典型的なフローは次のようになります。
make_reading_note.py を使って、~/research/papers_inbox/ の中で
関連度スコア 8 以上だった論文 5 本について、それぞれ精読ノートを
~/research/reading_notes/ 配下に生成して。
生成が終わったら、5 本のノートを横断して共通する研究上の限界を
3 つ抽出し、私の研究のポジショニング案として 2-3 段落で書いて。
「共通する限界の抽出」のような横断分析は、ノートが一度 Markdown ファイルになっていれば、Claude Code がもう一度ファイル群を読み込んで再分析してくれます。「PDF → 構造化ノート → 横断分析」という多段パイプラインを、ローカルファイルを介在させて組めるのが、Claude Code を CLI として使うことの強みです。
翻訳精度と専門用語の扱い
Claude の和訳は、DeepL や Google 翻訳と比べて「自然な研究分野慣用表現」が出やすい一方で、専門用語の訳語選択は分野によってブレます。たとえば「attention(注意機構)」「attention(注視)」のように、同じ英単語が分野によって違う日本語訳になる用語は、論文の冒頭で「訳語ポリシー」を Claude に渡しておくのが安全です。
この精読タスクでは、以下の訳語ポリシーで統一してください:
- attention → 「注意機構」(深層学習文脈)
- transformer → 「Transformer」(カタカナにせず英語そのまま)
- fine-tuning → 「ファインチューニング」
- benchmark → 「ベンチマーク」(評価用の意味で)
- agent → 「エージェント」
分野の慣例と異なる場合は、注釈で「(原文: agent)」と併記してください。
実装手順 5:卒論・修論進捗の自動可視化ダッシュボード
卒論・修論の進捗管理を、Word ファイルのバージョン管理だけで回しているケースがほとんどだと思いますが、これだと「今、序章は何字書けていて、結論は何字足りないか」「先週から今週でどれだけ進んだか」が見えづらい。Markdown + Git で書くか、もしくは Word から PDF / テキスト経由で抽出するかして、章ごとの状態をスクリプトで集計します。
下記は、Markdown で書かれた卒論ディレクトリを集計するスクリプトの例です。
"""
thesis_progress.py
~/thesis/chapters/ 配下の Markdown 章ファイルを集計し、
週次レポートを Markdown で出力する想定スクリプト。
"""
import re
from pathlib import Path
from datetime import datetime
CHAPTERS_DIR = Path.home() / "thesis" / "chapters"
TARGET_WORDS = {
"01_intro.md": 6000,
"02_related.md": 12000,
"03_method.md": 15000,
"04_experiment.md": 12000,
"05_discussion.md": 8000,
"06_conclusion.md": 3000,
}
def count_japanese_chars(text: str) -> int:
# 全角文字をざっくり1文字としてカウント、半角は0.5換算
full = sum(1 for ch in text if " " <= ch <= "鿿" or "" <= ch <= "")
half = sum(1 for ch in text if ch.isascii() and not ch.isspace())
return full + half // 2
def count_figures(text: str) -> int:
return len(re.findall(r"!\[[^\]]*\]\([^)]+\)", text))
def count_citations(text: str) -> int:
# \cite{...} と [@key] の両方をカウント
n1 = len(re.findall(r"\\cite\{[^}]+\}", text))
n2 = len(re.findall(r"\[@[^\]]+\]", text))
return n1 + n2
def main():
report = [f"# 卒論進捗レポート ({datetime.now().strftime('%Y-%m-%d')})\n\n"]
report.append("| 章 | 現在字数 | 目標字数 | 達成率 | 図数 | 引用数 |\n")
report.append("|---|---:|---:|---:|---:|---:|\n")
total_now = 0
total_target = 0
for fname, target in TARGET_WORDS.items():
path = CHAPTERS_DIR / fname
if not path.exists():
report.append(f"| {fname} | 未作成 | {target} | 0% | 0 | 0 |\n")
total_target += target
continue
text = path.read_text(encoding="utf-8")
now = count_japanese_chars(text)
figs = count_figures(text)
cites = count_citations(text)
rate = round(now / target * 100, 1) if target else 0
report.append(f"| {fname} | {now:,} | {target:,} | {rate}% | {figs} | {cites} |\n")
total_now += now
total_target += target
total_rate = round(total_now / total_target * 100, 1) if total_target else 0
report.append(f"\n**合計: {total_now:,} / {total_target:,} 字 ({total_rate}%)**\n")
out = CHAPTERS_DIR.parent / "PROGRESS.md"
out.write_text("".join(report), encoding="utf-8")
print(f"出力: {out}")
if __name__ == "__main__":
main()
このスクリプトを毎週末に cron で走らせて、生成された PROGRESS.md を Claude Code に読ませる。すると、定性的なレビューまでセットで返ってきます。
~/thesis/PROGRESS.md と、~/thesis/chapters/04_experiment.md を読んで、
次の観点でレビューして:
1. 全体の達成率に対して、章間のバランスが取れているか
2. 04_experiment.md の図数と引用数が、内容に対して妥当か(少なすぎないか)
3. 04_experiment.md の中で、論理の飛躍がありそうな箇所、または
「ここに引用が必要なはずだ」という箇所を 3 つ指摘して
4. 来週の作業として優先すべき 3 つを、優先度順に提示して
なお、学術的な妥当性の最終判断は私と指導教員がするので、
あなたは「気付きの提示」と「形式上のチェック」に徹してください。
このプロンプトのポイントは、最後の一文です。「学術的判断は人間がする、Claude は気付きの提示と形式チェックに徹する」と明示することで、Claude が「これは新規性が高い研究です」のような、Claude には判断できない断定を返すのを抑制できます。
指導教員レビュー対応の効率化
指導教員から返ってくる赤入れ・コメントへの対応も、Claude Code に下準備をさせると楽になります。たとえば、PDF にコメントで「ここの引用、もっと最近のレビューを当たって」と書かれた場合、その引用文を Claude に渡して、「同じ主題のレビュー論文を、過去 3 年から探す検索クエリ案を 5 つ」と頼むと、検索の入り口を短時間で揃えられます。最終的に「どのレビューを引くか」は研究者本人が判断します。
Zotero / Mendeley との連携:ローカルファイル経由が一番素直
Zotero と Mendeley、どちらを使っていても、Claude Code との連携で最も素直なのは「ローカルファイル経由」です。具体的には次の流れになります。
- Zotero / Mendeley でコレクション(フォルダ)を作り、関連論文を放り込む
- Better BibTeX(Zotero)または Mendeley のエクスポート機能で
references.bibをローカルに出す - 添付 PDF も同じディレクトリにエクスポート(または Zotero のストレージディレクトリを直接参照)
- Claude Code を起動して、そのディレクトリを
cdで指して作業する
Zotero の場合、Better BibTeX の Automatic export 機能で、コレクションの内容が更新されるたびに自動で references.bib を書き出してくれるので、上記フローがほぼ自動化できます。Mendeley の場合は手動エクスポートになりますが、それでも週に 1 回エクスポートしておけば十分です。
API 連携を直接叩く方法もあります。Zotero Web API を使えば、コレクションの内容を JSON で取得して、Claude Code 経由で処理を回すこともできますが、API 経由は認証・レート制限・スキーマ理解のオーバーヘッドが大きいので、まずはローカルファイル経由で十分にワークフローを回してから API 化を検討するのがおすすめです。
効果指標:何がどれくらい改善する想定か
具体的な数値は研究分野・研究室文化・既存ツールの習熟度に大きく依存するので、ここでは「想定される改善幅のレンジ」として書きます。実数値ではなく、Claude Code を業務に組み込んだ複数の研究者・研究室の運営者から聞いた感覚値の合成です。
| 業務 | 従来の所要時間(目安) | Claude Code 組み込み後(想定) | 削減幅レンジ |
|---|---|---|---|
| サーベイ初動(キーワード設計〜30本要旨スクリーニング) | 1〜2 週間 | 3〜5 日 | 50〜70% |
| BibTeX 整形(500 エントリ) | 半日〜1 日 | 30 分〜1 時間(最終チェック込み) | 70〜85% |
| 英文論文 1 本の精読ノート作成 | 3〜5 時間 | 1〜2 時間(人間レビュー込み) | 50〜60% |
| 卒論進捗の集計・週次レポート | 2〜3 時間 / 週 | 5〜10 分 / 週(スクリプト自動化) | 90%以上 |
| 指導教員レビュー対応(検索クエリ案出し) | 1〜2 時間 | 15〜30 分 | 70〜80% |
誤解のないように補足すると、これは「Claude Code で 80% 削減できる!」という派手な数字を出したいわけではなく、「読む」「考える」「書く」という研究の本丸の時間は変わらないということです。むしろ、本丸の時間が確保できるように、その前後の整備工程の時間を圧縮するのが Claude Code の使い所、ということになります。
【要注意】よくある失敗パターン 4 つと回避策
失敗パターン 1:Claude の出力をそのまま論文に引用する
❌ NG:Claude に「○○分野の最新研究をまとめて」と依頼し、出力されたテキストをそのまま卒論の「2 章 関連研究」に貼り付け、引用も Claude が出した参考文献リストをそのまま記載する。
⭕ OK:Claude にはサーベイの「入り口」だけ作らせる。出力された論文タイトル・著者名・発表年は必ず Google Scholar / arXiv / 各学会の論文 DB で実在確認する。引用するなら、必ず原文 PDF を入手して、本文を読んでから引用する。
Claude を含む LLM は、もっともらしい論文タイトル・著者名・DOI を「ハルシネーション(幻覚生成)」することが知られています。実在しない論文を引用してしまうと、研究倫理上の重大な問題になります。特に、卒論・修論の口頭試問で「この引用、見つからないんだけど」と指摘されると、信用問題に直結します。
失敗パターン 2:未発表の研究アイデアを無制限に Claude に書き込む
❌ NG:研究室独自の研究アイデア、論文投稿前の手法、特許出願前の発明内容を、API キーが学習に使われる設定のまま Claude に書き込む。
⭕ OK:所属機関の AI 利用ポリシー(多くの大学・研究機関で 2024〜2025 年にかけて整備されています)を確認する。Anthropic Claude の API は、デフォルトでユーザーの入力をモデル学習に使わない設定ですが、契約形態・使用するインターフェース(Web チャット vs API vs Claude for Work)によって扱いが異なるので、所属機関の情報セキュリティポリシーと、Anthropic の利用規約・データ取り扱いポリシーを両方確認してから使う。判断に迷うときは、研究室の指導教員・所属機関の知財担当に確認する。
失敗パターン 3:「論文の新規性」を Claude に判定させる
❌ NG:「私の研究は新規性ありますか?」「この研究は既存研究と十分に差別化できていますか?」と Claude に判定を求め、Claude が「はい、十分に新規性があります」と答えたのを根拠に、そのまま研究を進める。
⭕ OK:Claude には「既存研究との重なり可能性が高い論文を 10 本挙げて」「あなたが知る限りの類似研究を時系列でリストアップして」という「事実列挙」だけを頼む。新規性の判断は、指導教員と共著者の人間の専門家が、Claude が出したリストと、自分たちで追加検索した結果を突き合わせて、合議で決める。
新規性判定は学術研究の核心であり、Claude が学習時点で持っている知識には必ず時間的・分野的な穴があります。新しい論文がプレプリントで出ている可能性、別言語で出ている可能性、別分野で同じ手法が使われている可能性を、人間が補完する必要があります。
失敗パターン 4:BibTeX の自動整形を全件確認なしで commit する
❌ NG:500 エントリの BibTeX を Claude Code に整形させ、差分も見ずに git commit し、共著者に push する。後日「DOI が違うエントリがある」「タイトルが微妙に違う」と指摘される。
⭕ OK:整形前後で必ず git diff を取り、差分が大きいファイル(極端に多いエントリで変更が入った場合)は人間が目視確認する。Claude Code に「変更が入ったエントリのうち、機械的な整形では説明できない変更(タイトル文字の差し替え・著者名の追加削除・DOI の置換)があれば、別ファイルにレポートとして出して」と頼んでおくと、差分レビューが現実的な作業量に収まります。
研究倫理と AI 利用:研究室として整備しておきたい 5 点
Claude Code を研究室業務に組み込むうえで、研究室として明文化しておくと事故が減るルールが 5 つあります。所属機関のポリシーがすでにある場合は、それを優先してください。
- AI への入力範囲:未発表アイデア・未公開データ・被験者個人情報を、どのモデル / どの契約形態に書き込んでよいかを明文化する
- 引用の事実確認義務:AI が出した文献情報は、必ず一次ソース(論文 PDF・公式 DB)で実在確認する
- AI の関与表記:論文の謝辞・方法論セクションで、AI ツールをどの工程で使ったか明記する(多くの学会・ジャーナルが 2024〜2025 年に方針を整備)
- 共著者間の運用共有:BibTeX 整形ルール・進捗管理スクリプト・キーワード設計を、研究室の Git リポジトリで共有する
- レビューの最終責任:AI が生成した訳文・要旨・要約は、必ず人間(できれば著者本人 + 指導教員)が最終チェックする
これらをまとめて、研究室の README.md や AI_USAGE_POLICY.md として 1 ファイルに書いておくと、新しく入ってきた学生・研究員にも引き継ぎやすくなります。
研究室導入の現実:Mendeley から Zotero への移行コストをどう見るか
「Claude Code と連携しやすいから Zotero に移行したい」と思っても、研究室全体で何百本という蓄積を Mendeley で持っているケースが多く、移行コストが論点になります。ここを軽く整理しておきます。
Mendeley から Zotero への移行は、Zotero 公式が提供している Mendeley インポート機能を使うと、コレクション構造・タグ・添付 PDF・ハイライト・ノートまで、おおむね保持された状態で移せます。完全ではなく、Mendeley のグループ機能の権限や、独自のメタデータ拡張は移行で落ちることがあります。研究室として移行を決める場合は、まず代表者 1 人が自分のライブラリで移行検証してから、研究室全体に展開する手順を推奨します。
とはいえ、本記事のスクリプトの大半は BibTeX エクスポートが取れさえすれば動くので、Mendeley のまま使い続けても、Zotero に移行しても、どちらでも Claude Code との連携は成立します。「Claude Code 連携のためだけ」に移行コストを払う必要はありません。すでに研究室で定着している参考文献マネージャを尊重しつつ、エクスポートの周期を「週 1 回・コレクション単位」に揃えることが、最小投資で最大効果を出すアプローチです。
共著者間でのワークフロー共有:Git とディレクトリ構成のおすすめ
研究室や共著者間で Claude Code 由来のワークフローを共有するとき、ファイル構成を最初に決めておくと衝突が減ります。ここでは、修士論文・共同研究プロジェクトのどちらでも使える、シンプルなディレクトリ構成を提案します。
~/research/
├── README.md # プロジェクト全体の説明
├── AI_USAGE_POLICY.md # AI 利用ポリシー(研究室として明文化)
├── keywords/
│ ├── 2026Q2_keywords.md # 四半期ごとの検索キーワード戦略
│ └── archive/ # 過去のキーワード戦略
├── papers_inbox/ # ダウンロードしたばかりの PDF を放り込む場所
├── papers_screened/ # スクリーニング済み(関連度スコア付き)の PDF
├── reading_notes/ # 精読ノート(Markdown)
│ ├── 2026-05-15_smith2024_eyetracking.md
│ └── 2026-05-17_tanaka2025_usability.md
├── references.bib # Better BibTeX 自動エクスポートの出力先
├── references.clean.bib # Claude Code でリンタ整形済み
├── bibtex_report.md # 整形時に Claude が出したレポート
├── survey_results.csv # スクリーニング結果(CSV)
├── survey_results.md # スクリーニング結果(Markdown、関連度降順)
└── scripts/ # Claude Code とやり取りするスクリプト群
├── survey_screening.py
├── make_reading_note.py
└── thesis_progress.py
このディレクトリ構成のポイントは、「人間が読むファイル」と「機械が処理するファイル」を、トップレベルでは混在させないことです。共著者が初めてこのリポジトリを開いたとき、README.md と reading_notes/ を見れば概要が掴め、scripts/ を見れば自動化の中身を理解できる、という分離になっています。
Git で管理する場合、papers_inbox/ と papers_screened/ 配下の PDF は容量と著作権の問題でリポジトリに入れず、.gitignore で除外するのが標準的です。Git 管理対象は、.md ファイル、.bib ファイル、scripts/ 配下の Python ファイル、AI_USAGE_POLICY.md の 4 種類に絞ると、リポジトリが軽く保てます。
研究室ミーティングでのレビュー対応:「読む候補リスト」を画面共有する
週次の研究室ミーティング、もしくは指導教員との 1on1 で、Claude Code が生成したサーベイ結果と進捗ダッシュボードを画面共有すると、レビューがかなり噛み合いやすくなります。具体的にどの場面で何を見せるかを、想定シナリオとして整理します。
場面 1:サーベイ初動の方向性確認(ミーティング 15〜20 分)
Claude Code が出した survey_results.md のうち、関連度スコア上位 10 本を画面に表示しながら、「この 10 本のうち、先生から見て『これは絶対に外せない』『これは関係薄い』はどれですか」と問う。Claude のスコアと指導教員の判断のズレが明確になり、検索キーワードを修正するヒントになります。
場面 2:論文構成の議論(ミーティング 20〜30 分)
進捗ダッシュボード(PROGRESS.md)を画面に出し、章ごとの達成率と引用数を見せる。「3 章メソッドは目標字数の 80% まで来ているが、引用が 5 本しかない。2 章で引用した先行研究との対比をもう少し書きたい」のような、構造レベルの議論ができます。
場面 3:精読ノートのレビュー(ミーティング 30 分〜)
関連度スコア上位の論文について、reading_notes/ 配下の精読ノートを 1 本見せる。「この論文の限界は、私の研究でどう乗り越えられそうですか」と問う。Claude が抽出した「限界」と、指導教員の経験的判断が噛み合うと、研究のポジショニングが具体化します。
これらの場面で重要なのは、Claude の出力を「最終答案」ではなく「議論の叩き台」として扱うことです。指導教員も、白紙の状態から議論を始めるより、Claude が出した構造化された叩き台があった方が、コメントを返しやすい。これは Claude Code 単体の効果というより、「人間同士のレビューの質を上げる装置」としての効果と言えます。
分野ごとの相性:理工系・人文社会系・医歯薬系で何が違うか
本記事のワークフローは分野横断で使える設計ですが、分野ごとに微妙な調整が必要です。
理工系(情報・電気・機械・物理・化学など):本記事のスクリプトがほぼそのまま動きます。論文は英語・PDF 中心、引用は IEEE / ACM スタイル、図表が多く、コード・データの再現性がレビュー対象になることが多い。Claude Code は実験コードのレビュー、データ解析スクリプトの補助、図のキャプション翻訳まで含めて活躍できます。
人文社会系(文学・歴史・哲学・社会学・教育学など):論文 PDF のテキスト抽出が、理工系より難航することがあります(古い論文のスキャン PDF・縦書き日本語など)。OCR の事前処理を挟む、もしくは Mistral OCR のような OCR 系サービスを噛ませる工夫が必要です。引用スタイルも APA / Chicago / 学会独自など多様で、BibTeX 整形のルールセットを分野に合わせて作る必要があります。質的研究の場合、Claude を「インタビュー逐語録のコーディング補助」に使う応用もあります。
医歯薬系(医学・歯学・薬学・看護など):PubMed の検索戦略がサーベイの中核になります。Claude に「PubMed の MeSH タームを使った検索クエリを出して」と頼めば、MeSH の階層構造を意識したクエリ案を返します。一方で、患者データ・臨床データの取り扱いは、所属機関の倫理委員会の規程が厳しく、Claude への入力可否は必ず倫理委員会・所属機関の AI 利用ガイドラインで確認してください。
分野が違えば最適な使い方も違いますが、「読む候補を絞る」「形を整える」「進捗を可視化する」という 3 つの軸は普遍的に効きます。まずはこの 3 軸から始めて、分野固有の応用は、研究室で 2〜3 ヶ月運用しながら追加していくのがおすすめです。
関連する Claude Code 活用事例
大学・研究機関での Claude Code 活用は、論文管理だけにとどまりません。教育・研究の周辺領域での実装事例も、合わせて参照してください。
- 教育機関でのコードレビュー自動化(Claude Code 活用事例) — 学生コードの初期レビューを Claude Code に任せ、教員レビューの所要時間を圧縮した事例。研究室での「学生の実装コードを Claude にレビューさせる」設計のヒントになります。
- 学習分析パイプラインの構築(Claude Code 活用事例) — 教育データの収集・前処理・可視化パイプラインを Claude Code で組んだ事例。卒論進捗の可視化や、研究室ダッシュボードの設計に応用できます。
- 特許の先行技術調査を Claude Code で 5 ステップ化 — 特許文献のサーベイを Claude Code で構造化した事例。学術論文サーベイと共通点が多く、検索戦略設計の参考になります。
コスト試算と運用判断:研究室予算でどう正当化するか
大学院生個人で Claude Code を導入する場合と、研究室として導入する場合では、コスト試算と稟議の通し方が違います。ここを整理しておきます。
個人利用の場合:Claude の Pro プラン(月額相当のサブスクリプション)でも、Claude Code は使えます。論文サーベイで月 30〜50 本の PDF を処理する程度であれば、Pro プランの枠内でおおむね収まる想定です。重い処理を回す日と、軽い日を分散させると、無理なく運用できます。学生個人の研究費から落とせない場合は、自費で導入して「研究投資」と割り切る判断もあります(書籍代と同じ感覚です)。
研究室全体で導入する場合:研究員・大学院生 5〜10 名規模であれば、Claude for Work / Team プラン相当の契約を検討します。研究費・科研費から支出する場合、「ソフトウェアライセンス費」「クラウドサービス利用料」として計上できることが多いですが、機関ごとに勘定科目の扱いが違うので、事務担当に必ず確認してください。稟議資料には、本記事の「効果指標」セクションの想定削減幅を引用したうえで、研究室独自の実測値(最初の 1 ヶ月で何時間削減できたか)を追記すると説得力が出ます。
機関契約・大学全体の包括契約の場合:近年、生成 AI の機関包括契約を結ぶ大学が増えています。所属機関の情報基盤センター・図書館・産学連携部門に「Anthropic Claude の機関契約はあるか」を問い合わせるのが第一歩です。ある場合、研究室個別の契約より、機関契約の方が単価が下がる・データ取り扱いポリシーが整備済み・利用ガイドラインが共有されているなどの利点があり、迷わず機関契約を使うべきです。
コスト面で見落としがちなのが、「Claude Code を使いこなすための学習コスト」です。研究室メンバーが Claude Code に慣れるまでに、1 人あたり 5〜10 時間のトライアル期間が必要です。この学習コストを「業務時間」として認めるかどうかが、研究室文化として導入を加速するか減速するかの分かれ目になります。指導教員が「最初の 2 週間はワークフロー試作に時間を使ってよい」と明示することが、現実的な後押しになります。
次の一歩:明日から研究室で試せる 3 ステップ
本記事の内容を一気に全部実装するのは大変なので、明日から試せる小さな 3 ステップに切り分けます。
- Step 1(30 分):自分の研究テーマで「キーワード設計プロンプト」を Claude Code に投げ、出力された検索クエリを Google Scholar で 1 つ試す。ヒット件数の妥当性を確認する
- Step 2(1〜2 時間):
survey_screening.py相当のスクリプトを Claude Code 自身に書かせて、自分のpapers_inbox/配下の PDF を 5〜10 本だけ処理する。出力された関連度スコアを目視確認する - Step 3(30 分):進捗管理スクリプトを
~/thesis/chapters/配下で 1 回走らせて、現在の章別字数を可視化する。指導教員との次回ミーティングで、このダッシュボードを画面共有する
3 ステップ全部やっても 1 日かかりません。小さく試して、ワークフローに合うものだけ研究室の標準フローに組み込んでいくのが、現実的な導入手順です。
まとめ:Claude Code は「研究の前工程」を担当する道具
本記事では、大学・大学院研究室の論文管理業務に Claude Code を組み込む 5 本のプロンプト・コード例を紹介しました。あらためて整理すると、Claude Code が向いているのは次の領域です。
- サーベイの初動(キーワード設計・要旨スクリーニング)
- 文献メタ情報の形式整備(BibTeX リンタ)
- 英文論文の精読ノート作成(和訳 + 要点抽出)
- 卒論・修論の進捗可視化(章別字数・図数・引用数の集計)
- 指導教員レビュー対応の下準備(検索クエリ案出し)
一方で、Claude Code には任せられない、人間(研究者本人・指導教員)が責任を持ち続けるべきなのは次の領域です。
- 研究の新規性判定
- 引用の正当性確認(実在確認)
- 翻訳精度の最終確認
- 論文の論理一貫性
- 研究倫理上の判断
この「任せられる工程」と「任せられない工程」の境界を、研究室として明文化したうえで、5 本のスクリプトを少しずつ標準化していくと、修論・博論期の「読む論文の山」が、確実に手前に押し戻されます。
参考出典
- Anthropic 公式 https://www.anthropic.com/ — Claude / Claude Code の最新情報、データ取り扱いポリシー、エンタープライズ向け契約形態の確認
- Claude Code 公式ドキュメント https://code.claude.com/ — Claude Code の CLI 仕様、API キーの設定方法、対応モデルの一覧
- Zotero 公式 https://www.zotero.org/ — 参考文献管理ツール Zotero の公式サイト。Better BibTeX プラグインや Web API のドキュメントも参照可
- Mendeley 公式(Elsevier)https://www.mendeley.com/ — Mendeley の公式サイト。BibTeX エクスポート、デスクトップアプリ、リファレンスマネージャ機能
- Google Scholar https://scholar.google.com/ — 学術論文検索の事実上の標準。Claude が提案した検索クエリの実行先として使用
著者プロフィール
佐藤傑(さとう・すぐる)。株式会社Uravation 代表取締役。X(@SuguruKun_ai)フォロワー約10万人。これまで100社以上の企業向けに生成AI研修・AI導入支援を実施。Claude Code を中核とした AI エージェント活用支援に注力し、教育機関・研究機関での導入相談にも応じています。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank ビジネス+IT 連載執筆中。
次のアクション
Claude Code を研究室業務に組み込みたい方は、次の 3 つのいずれかから始めてみてください。
- 個人で試す:本記事の「次の一歩」3 ステップを、自分の手元で 1 日かけて試す。手応えがあれば、研究室の同僚・後輩に共有する
- 研究室で標準化する:本記事のスクリプトを研究室の Git リポジトリに置き、共著者間で BibTeX 整形ルールと進捗管理スクリプトを共通化する
- 導入支援を相談する:研究室・研究機関単位での Claude Code 導入、研究倫理上のポリシー設計、研究員向けトレーニングなどは、Uravation の Claude Code 個別指導・導入支援コンサルでも対応しています。お気軽にお問い合わせください
※本記事のスクリプト・プロンプトはすべて想定実装例です。実環境で使用する場合は、所属機関のポリシー・利用規約を確認のうえ、ご自身の責任でご利用ください。Claude Code はサーベイ補助・形式整備を担当する道具であり、学術的判断は研究者・指導教員が最終責任を持つことを、改めてご認識ください。本記事に登場する数値・所要時間レンジは、複数の研究室運営者・大学院生から聞いた感覚値の合成であり、個別研究室の実数値ではありません。実装結果は研究分野・既存ワークフロー・チーム規模・利用モデルによって大きく変動します。ご自身の研究室での実測値が出てきたら、本記事のスクリプトと併せて、研究室内のドキュメントに残していくことを強くおすすめします。