ClaudeでCRediTの著者貢献を共著者のメモから揃える手順
共著者の自己申告メモをCRediTの14役割に割り当て、重複と未割当をClaudeで点検して貢献記載の文案にする手順。割れやすい役割の境目と、AI利用の開示を混ぜない理由も示します。
投稿システムに「著者ごとにCRediTの役割を選んでください」という入力欄が出ると、共著者へのメール確認が始まります。返ってくるのは「データ取って、図も作りました」「全体を見ていました」といった自由記述のメモで、そのままでは14の役割に載りません。
この記事は、共著者の自己申告メモをClaudeに渡して役割へ割り当て、重複と未割当を点検し、貢献記載の文案にするまでの手順です。割り当ての案を出すのはClaudeで、誰がどの役割かを決めるのは著者自身です。その線引きも含めて示します。
CRediTが記載するのは「何をしたか」で、著者資格ではない
CRediT(Contributor Role Taxonomy)は、研究成果への貢献の種類を14の役割で表す分類です。2022年にANSI/NISO Z39.104-2022として承認され、CC-BY 4.0で再利用できます。
大事なのは、公式がこの分類を著者資格の判定に使わないと明記している点です。役割の定義ページには、出版社は著者資格について厳格な基準を持っており、CRediTはそれを決めるものではないと書かれています。実装ガイドも、著者資格の要件はICMJEやCOPEの指針を見るよう案内しています。
つまり、メモを役割に割り当てる作業は「この人を著者に入れてよいか」の議論とは別の層です。この2つを混ぜると、役割が少ない人を著者から外す話に飛び火しやすくなります。
メモを集める前に決めておく4つの約束
実装ガイドは、研究の早い段階で役割を合意しておくと、論文化の時点での混乱や争いを減らせると述べています。そのうえで、割り当てに共通する原則を挙げています。
割り当ての前提になる原則
- 1人が複数の役割を持ってよい
- 同じ役割を複数人に割り当ててよい
- 論文に当てはまらない役割は載せなくてよい
- 寄与の度合い(lead・equal・supporting)は任意で、CRediT標準の一部ではない
この4点は、Claudeへの指示にも入れておきます。入れないと、14役すべてを誰かに割り当てようとしたり、1役割に1人だけを選ぼうとしたりする出力が出ることがあります。
寄与の度合いは、出版社が求めたときだけ使う扱いです。求められていないのに「lead」などを付けると、共著者間の序列の議論を呼び込みます。
共著者に出してもらうメモの形
メモの形式を揃えておくと、割り当ての精度が上がります。自由記述でも構いませんが、次の3点を頼んでおくと後工程が楽です。
- 自分がやった作業を、動詞で1行ずつ書く(「質問票を設計した」「再現スクリプトを書いた」)
- その作業をした時期や対象(どの実験、どの章)を添える
- 他の人が主担当だった作業に手伝いで入った場合は、その旨を書く
「全面的に関わりました」のような総括は、役割に落とせません。作業の動詞が書かれていれば、Claudeは動詞から役割を提案できます。
Claudeに渡す指示文と出力表
ClaudeのProjectsに、CRediTの14役割の定義(上記の定義ページの英文)と、集めたメモを置きます。定義を貼らずに「CRediTの14役割で」とだけ頼むと、記憶に頼った言い換えが混ざるため、定義は必ず資料として渡します。
添付のCRediT定義(14役割)を唯一の基準にして、共著者メモを役割に割り当ててください。
- 出力は表: 著者 / 役割 / 根拠にしたメモの一文(原文のまま引用)
- 1人が複数の役割を持ってよい。同じ役割を複数人に割り当ててよい
- メモに根拠がない役割は割り当てない。推測で補わない
- 判断に迷う行は「要確認」とし、迷った理由を定義の語で書く
- 最後に、誰にも割り当てられなかった役割を一覧する「根拠にしたメモの一文を原文のまま引用させる」のが要点です。引用が付いていれば、著者が表を見て、その役割が本人の申告に基づくのかClaudeの推測なのかをすぐ見分けられます。引用がメモに存在しない行は、作り話の疑いとして真っ先に確認できます。
割れやすい役割の境目
メモの動詞が複数の役割にまたがるとき、迷いは同じ組に集中します。公式の定義文の差を押さえておくと、Claudeの「要確認」を著者が素早く裁けます。
| 迷う組 | 定義文の違い |
|---|---|
| InvestigationとData curation | 定義文の違い実験やデータ・証拠の収集を行うのがInvestigation。メタデータ付与、データの整理、再利用のための維持管理がData curation |
| MethodologyとSoftware | 定義文の違い方法の設計やモデルの作成がMethodology。プログラミング、コードの実装、既存コードの検証がSoftware |
| Formal analysisとValidation | 定義文の違い統計・数理・計算の手法で研究データを分析・統合するのがFormal analysis。結果や研究成果の再現性の検証がValidation |
| SupervisionとProject administration | 定義文の違い研究の計画と実行の指導・統率、チーム外へのメンターシップを含むのがSupervision。計画と実行の管理・調整がProject administration |
| Writing – original draftとWriting – review & editing | 定義文の違い最初の草稿の執筆(実質的な翻訳を含む)が前者。元の研究グループの人による批判的な査読、コメント、改訂が後者 |
とくに最後の組は、校正だけをした人に「Writing – original draft」を付けてしまう取り違えが起きやすい箇所です。定義上、前者は初稿を書いた人、後者は元の研究グループの人が行う批判的な見直しや改訂です。
もう1つ、Resourcesは試薬、試料、患者、計算資源、分析ツールなどの提供を指します。データそのものを集めた人ではなく、材料や環境を提供した人の役割です。メモに「研究室の装置を貸した」とあれば、Investigationではなくこちらです。
重複と未割当の点検
割り当て表ができたら、次の2つの表で点検します。Claudeに表を作らせ、著者が結果を読みます。
点検の順序
- 1
役割ごとの担当者表を作る
14役割を縦に並べ、担当者を横に並べ替えます。人ごとの表では見えない「同じ役割に3人いる」「誰もいない」が一目で分かります。
- 2
未割当の役割を分類する
誰もいない役割は、論文に当てはまらないから空なのか、メモが漏れているから空なのかを分けます。公式は当てはまらない役割を載せなくてよいとしているので、前者は問題ありません。
- 3
重複の役割を確認する
複数人が同じ役割を持つこと自体は許されます。確認するのは、その全員が本当にその作業をしたのかという点です。
- 4
著者本人に返して確認する
実装ガイドは、可能なら貢献者が自分に割り当てられた役割を確認できる機会を設けるよう勧めています。表をそのまま各共著者に返します。
たとえば、次のような架空のメモを渡したとします(以下は例示です)。
| 著者 | メモ |
|---|---|
| A | メモ研究の問いを立て、質問票を設計し、初稿を書いた |
| B | メモ調査を実施し、回答を集計し、図を作った |
| C | メモ補助金を取り、研究室全体の進行を管理した |
| D | メモ原稿を通読して修正案を出した |
このとき、期待される割り当ては次のような形になります。
| 著者 | 割り当て案 | 要確認 |
|---|---|---|
| A | 割り当て案Conceptualization / Methodology / Writing – original draft | 要確認「質問票の設計」はMethodologyで足りるか |
| B | 割り当て案Investigation / Formal analysis / Visualization | 要確認「集計」がFormal analysisに当たる範囲か |
| C | 割り当て案Funding acquisition / Project administration | 要確認研究の指導もしていればSupervisionを足す |
| D | 割り当て案Writing – review & editing | 要確認なし |
点検の結果、ResourcesとSoftwareとData curationは誰にも割り当てられません。調査研究でコードを書いていなければSoftwareは空でよく、Data curationは回答データの整理やメタデータ付与を誰かが担ったかを共著者に聞く価値があります。この判断はClaudeではなく、現場を知る著者がします。
貢献記載の文案にする
役割が確定したら、投稿先の指定に合わせた文案にします。実装ガイドによれば、出版社がCRediTを必須にしていない場合でも、「Author note」「Contribution statement」「Acknowledgement」のような節にCRediTの語で貢献情報を書けます。
一般的な書き方は、著者ごとにイニシャルと役割を並べる形です。Claudeに次のように頼むと、確定した表から整形できます。
確定した割り当て表から、Author contributions節の文案を作ってください。
- 形式: 「A.A.: Conceptualization, Methodology, Writing – original draft. B.B.: ...」
- 役割名はCRediT定義の表記(en dash付き)をそのまま使う
- 表にない役割は書き足さない
- 投稿規定の字数制限は別途私が確認する役割名は公式の表記をそのまま使います。「Writing – original draft」のダッシュを含め、略したり言い換えたりしないほうが、投稿システムや機械可読化の段階でずれません。公式は、CRediT情報をJATS XMLでマークアップするなど機械可読にすることを勧めており、Crossrefも2026年にメタデータスキーマへCRediTを加える計画を示しています。公式の実装ガイドには役割ごとの識別子(たとえばConceptualizationは8b73531f-db56-4914-9502-4cc4d4d8ed73)も載っていて、役割名の綴りではなくIDで受け渡す仕組みの土台になっています。
投稿システムで選択式の場合、文案は不要で、確定表の通りにチェックを入れるだけです。文案は選択欄がない雑誌向けの控えです。
AI利用の開示はCRediTの外に書く
最後に混ぜやすい点を挙げます。この作業にClaudeを使ったことは、貢献記載ではなく、AI利用の開示の側に書くものです。
ICMJEの勧告は、投稿時にAI支援技術の利用を開示するよう雑誌が求めるべきだとしています。そのうえで、チャットボットなどのAIツールは、正確性・完全性・独創性への責任を負えないため著者に載せてはならないと述べています。Nature PortfolioのAI方針も、著者資格や説明責任をAIに持たせることを、責任をAIに委ねた使い方として挙げています。
したがって、貢献記載にClaudeの欄を設けたり、役割の担当者にClaudeを並べたりしません。役割の割り当て案をClaudeが作ったとしても、確定するのは共著者です。どこまで開示するかは雑誌の規定に従います。開示事項の位置と書式の点検は、投稿規定への適合チェック表の手順が使えます。
つまずきやすい点
- メモの総括から役割を決めてしまう: 「全体を見ていた」は、SupervisionともProject administrationとも読めます。動詞を聞き直します。
- 定義を渡さずに頼む: 役割名だけで頼むと、定義から外れた分類が混ざります。定義ページの英文を資料に置きます。
- 推測で埋めた行を見逃す: 根拠の一文を原文で引用させ、メモに存在するか照合します。
- 役割の数を揃えようとする: 全員に同じ数の役割を付ける必要はありません。公式は、1人が複数の役割を持つことも、当てはまらない役割を載せないことも認めています。
- 著者資格の議論に使う: CRediTは著者資格を決めません。著者の範囲は、投稿先の基準で別に決めます。
再実装した結果を検証した人の役割を決めたいときは、論文の手法を再実装する手順の作業単位が、SoftwareとValidationの切り分けの参考になります。