学会発表と論文の英文原稿を、投稿前に校正して用語と表記をそろえる

処理の起点を決める

研究員が原稿を書き終えて、チャット画面に貼り付けたときが起点です。自動実行はありません。

書き手が自分のタイミングで使える形にしておくことが重要です。承認のプロセスに組み込むと、「レビュー依頼の前に必ずAIを通す」という手順が増え、かえって面倒になります。自己校正の道具として、本人が使うものと位置づけてください。

入力データを集める

原稿が長くても、分割せずに一度に渡せます。 Gemini は100万トークン規模の入力を受け取れるモデルが提供されており、論文1本（1万語前後）は問題なく収まります。分割すると、前半と後半で用語の扱いが変わるため、一度に渡すほうが結果が安定します。

データの取得方法を決める

原稿： Word から本文をコピーして貼り付けます。数式や図が多い原稿は、テキストにしたときに崩れます。数式は原則としてAIに触らせないでください。 数式部分は [EQ1] のような目印に置き換えてから渡し、戻ってきた結果で元に戻します。

社内用語集： Excel の2列（日本語／英語）をコピーして貼り付けます。500行程度なら全部貼って構いません。よく使う50語に絞っても実用上は足ります。

投稿規程： 投稿サイトの「Author Guidelines」をコピーします。ここは毎回確認してください。 規程は改定されます。以前投稿したときの記憶で進めると、語数制限の変更を見落とします。

AIへ渡す前に整形する

1. 数式・化学式の退避 … [EQ1] [CHEM1] のような目印に置き換えます。AIが数式の記法を「直して」しまうことがあります
2. 引用表記の退避 … [Ref1] に置き換えます。文献番号を並べ替えられると、後の修正が大変になります
3. 未公開情報の確認 … 出願前の内容や、共同研究先の秘密情報が含まれていないかを確認します。含まれる場合は、この工程に入る前に知財部と確認してください
4. セクションの分離 … 要旨・本文・図表キャプションを分け、要旨には語数制限の確認を、キャプションには用語の統一を重点的にかけます

AIに処理させる

書き換えた全文を出させないでください。 全文を受け取ると、どこが変わったのか分からないまま採用してしまいます。必ず「原文／修正案／理由」の対比形式で出させます。 これが、この使い方でもっとも重要な設計です。

内容の追加もさせません。 「この主張を補強する文を足しましょうか」という提案は、書いていないことを書くことになります。論文では致命的です。

指示内容を固定する

あなたは、日本語を母語とする研究者が書いた英語論文を校正する編集者です。
下の原稿を校正してください。

【厳守事項】
- 原文の意味を変えないでください。主張の強さも変えないでください。
  「may contribute」を「contributes」に変える類の修正は禁止です。
- 書き換えた全文を出さないでください。必ず次の3列の表で返してください。
  該当箇所（原文そのまま） / 修正案 / 理由
- 内容を追加しないでください。文を足す提案をしないでください。
- [EQ1] [CHEM1] [Ref1] のような目印は、そのまま残してください。中身を推測しないでください。
- 数値、単位、試料名、装置名は変更しないでください。
- 下の用語集にある社内用語は、用語集の英語表記に統一してください。
  用語集にない語を勝手に統一しないでください。
- 下の投稿規程に反する箇所（語数、見出し、単位、略語の定義）を別枠で指摘してください。
- 論理の飛びがある箇所は、直さずに「指摘」としてだけ挙げてください。

【原稿】
{manuscript}

【社内用語集（日本語 / 英語）】
{glossary}

【投稿先の規程】
{author_guidelines}

「主張の強さを変えない」の1行が重要です。 英文校正は、控えめな表現を断定的に直しがちです。研究の主張を強めることは、書き手が意図していない内容に変えることを意味します。 査読で指摘されるのも、投稿後に問題になるのも、この種の変更です。

出力形式を固定する

チャット画面で使うなら、表形式で受け取れば十分です。API連携まで進める場合は、JSON Schema を指定して出力を固定します。OpenAI API では response_format に json_schema 型を strict で指定することで、応答を必ずスキーマどおりの形にできます。

{
  "corrections": [
    {
      "section": "",
      "original": "",
      "suggested": "",
      "reason": "",
      "category": "grammar | usage | consistency | glossary",
      "changes_meaning": true
    }
  ],
  "guideline_issues": [
    { "rule": "", "location": "", "detail": "" }
  ],
  "logic_notes": [
    { "location": "", "note": "" }
  ],
  "word_count": 0
}

changes_meaning は、その修正が意味を変える可能性があるかどうかをAI自身に申告させる項目です。ここが true の指摘だけを社内レビューへ回せば、レビュー側の負担が大きく減ります。

システムへ連携する

連携先はありません。 結果を見ながら Word の原稿を手で直します。

強いて仕組みを足すなら、指摘の一覧をスプレッドシートへ貼り付け、採否の列を付けて記録する程度です。これをためていくと、自分がどの文法項目でよく指摘されるかが分かります。 冠詞が毎回出てくるなら、次からはそこを意識して書けます。教育の材料になる、という意味では、この記録に価値があります。

英文校正会社に出す場合は、AIの指摘を反映した原稿を渡します。AIの指摘一覧そのものを校正会社へ渡す必要はありません。

人が確認する

全件、書き手が1件ずつ採否を決めます。一括で採用しません。

理由は、修正案の中に意味を変えるものが混ざるためです。英語として自然になる修正が、研究の主張としては正しくないことがあります。これを判断できるのは、その研究をやった本人だけです。

changes_meaning が true の指摘と、logic_notes に挙がった箇所は、社内レビューへ回します。ここが、英語の得意な研究員に見てもらうべき部分です。文法の修正案を人が見る必要はありません。

例外に対処する

記録を残す

チャット画面で使う場合、記録は自動では残りません。次の2つだけ、手元に残すことをおすすめします。

• 指摘の一覧と、採否の結果（スプレッドシート1枚）
• 使った用語集の版と、投稿規程を確認した日付

前者は、書き手ごとの弱点が見える材料になります。後者は、投稿後に規程違反を指摘されたときに、いつ時点の規程を見たかを示せます。

原稿そのものを外部サービスの履歴に残したくない場合は、履歴を残さない設定で使ってください。 未公開の研究内容を扱うため、ここは組織の方針に従います。