共著で原著論文を書いていると、メール添付の Word が何往復もして「いま最新版どれ？」「このコメント、もう反映した？」「先生からの返事はどのメールに埋もれた？」となりがちです。
先日、共著の原著論文を仕上げる過程で 自前の "論文コラボサイト" を立てたら、一気にやりとりがラクになりました。研究の中身は伏せますが、システムの骨組みと、地域・大学にこそおすすめしたい理由をやさしく整理してみます。
はじめに
このシリーズは、自分の 学び直しを兼ねて整理しているもの です。
筆者は臨床工学技士 × AI エンジニアで、教育関係の仕事もしています。医療と IT のあいだで動いている立場 として、研究や論文執筆まわりで「もうちょっと仕組みでラクできるのに……」と感じる場面を、毎回つまづくポイントごと整理しています。
今回は 「共同で論文を書くときの作業環境」 を題材にします。研究テーマには触れず、仕組みの話だけ をします。
1. 共同で原著論文を書くって、想像以上にカオス
ひとことで言うと「情報源がバラバラに散らかる」のが本当の敵です。
イメージとしては、こんな状態です。
- Word ファイル：v1.docx / v2.docx / v2_先生コメント反映.docx / v2_final.docx / v2_final_本当に最終.docx
- メール：4 人 × 数往復 × 別スレッド
- PDF：図だけ送ったやつ / 全文 PDF / 印刷した紙
- Zoom 議事録：Google Drive のどこかにある
- チャット：LINE か Slack か Teams か、相手によって違う
これ、共著者が 3〜5 人 くらいになるとあっという間に 誰もが迷子 になります。
🔰 「共著（コーオーサー）」って何？
ひとつの論文を、複数の研究者で一緒に書く ことです。
ふつうは:
- 筆頭著者: 一番中身を動かす人（多くの場合、若手や学生）
- 指導側: アイデア出し・全体監修・査読対応
- 海外の共同研究者: 英語表現の最終調整、別の専門知識を持ち寄る人
- 責任著者（コレスポンディングオーサー）: 雑誌側との窓口になる人
これだけ役割が違う人が同じファイルに手を入れに来るので、情報を一か所に集める箱 がないと事故ります。
2. じゃあ何を作ったの？（システムの輪郭）
ざっくり言うと 「共著者専用の、ログイン制 Web サイト」 です。
中身は派手なものではありません。こんな機能だけ あります。
| 機能 | やってくれること |
|---|---|
| ドラフト本文の表示 | Markdown で書いた論文ドラフトをきれいに表示 |
| 日本語 / 英語の切り替え | ボタン一発で本文を JA ⇄ EN に切り替え |
| コメント欄（Slack 風スレッド） | 段落・図ごとに議論、返信スレッドもつけられる |
| スクショ貼り付け |
Ctrl+V で画像をそのまま貼れる |
| 自動翻訳（EN ⇄ JA） | 投稿したコメントが裏で自動翻訳される |
| 図ギャラリー | 論文に出てくる図をまとめて閲覧 |
| 投稿先バナー | 「いまどの雑誌に出す予定か」を常時表示 |
| 経緯タブ | 投稿先変更・メールでの合意などを タイムライン化 |
実装は Next.js + Clerk + Supabase + Netlify/Vercel を組み合わせただけ、という構成です。
🔰 「Next.js」って何？
Web サイトを作るための 土台フレームワーク です。React という UI 部品の仕組みに、ページ遷移・API・SEO 対応などの "地味だけど面倒な配線" を最初から組み込んでくれています。
例えるなら "住居つきの建売住宅"。土地から基礎まで自分で打たなくても、ある程度家として住める状態でスタートできるイメージです。
🔰 「Clerk」って何？
ログイン機能を外注できるサービス です。
ID・パスワード管理、Google ログイン、メール認証、2 段階認証……これを自分で実装すると 半年単位の地獄 ですが、Clerk に任せると数十分でだいたい終わります。
例えるなら マンションのオートロック業者。鍵の制度設計を自分で発明しなくても、業者が用意した堅い仕組みをそのまま借りられます。
🔰 「Supabase」って何？
データベース＋ファイル保管庫の "貸し倉庫" サービス です。
PostgreSQL という由緒正しいデータベースを、ブラウザの設定画面と簡単な API で触れます。コメント・ユーザー情報・画像などをここに保管しています。
例えるなら 24 時間営業のトランクルーム。中身（コメント・画像など）を放り込んでおけば、サイトのどこからでも取り出せます。
3. ある日、ドラフト共有のしんどさが消えた
仕組みを立ち上げた瞬間、いくつか 明らかに楽になった瞬間 がありました。
「先生、修正版送りました！」
「あれ？ どこに？」
「メールで……あ、別のスレッドに行ってる……」
このやりとり、本当によくあります。
コラボサイトを立てると、こうなります。
「サイトの "論文ドラフト" タブ見てください」
「OK」
それだけです。
🔰 「ドラフト」って何？
まだ世に出る前の、書きかけの原稿 のことです。学校でいう「下書き」「清書前のレポート」と同じ立ち位置です。
論文の場合、ドラフトは v1, v2, v3 ……と何度も育つ ので、どこが最新なのかを共有する仕組みがとても大事になります。
🔰 「コメントスレッド」って何？
LINE や Slack のように、ひとつの発言にぶら下げて返信できる仕組み です。
「Figure 3 の表記揺れがある」というコメントに対して、別の人が「直しました」とぶら下げて返信できる。論点が散らからない ので、議論が後から追えます。
4. 「メール + Word」運用と「自前コラボサイト」を並べてみる
口で説明しにくいので、表で比較 します。
| 観点 | メール + Word | 自前コラボサイト |
|---|---|---|
| いま最新版がどれか | わからない | サイトに 1 個しかない |
| 過去のコメント | メールフォルダの海 | ドラフトに紐づいて全部残る |
| 海外共著者との言語差 | 各自で翻訳 / DeepL 行き来 | サイト内で自動翻訳 |
| 画像・スクショ共有 | 添付 → 添付の往復 |
Ctrl+V で即貼り付け |
| 投稿先が変わったとき | 全員に説明メール | バナー＋経緯タブで一発共有 |
| 過去の合意 | メール検索 | 経緯タイムラインに固定 |
カオスの正体は "情報源の数" です。
箱を 1 個に絞るだけで、これだけ落ち着きます。
🔰 「投稿先（ターゲットジャーナル）」って何？
その論文を どの学術雑誌に投稿しようとしているか のことです。
投稿先が変わると、章立て・必須項目・字数・スタイル すべてが少しずつ変わります。「いまどこに出す予定か」が全員に共有されていない と、書き方を間違える事故が起きます。
サイトのヘッダーに 「Target: ◯◯ · 旧: △△ · YYYY-MM-DD 変更」 と表示しておくだけで、これがゼロになります。
🔰 「i18n（多言語対応）」って何？
Internationalization の頭と尻を取って i と n、間に 18 文字 あるから i18n です（業界の謎の符牒です）。
要は 「同じサイトを多言語で見られるようにする」 こと。日本人著者と海外共著者で 同じドラフト・同じコメント を見られるのは、ちょっとした神機能でした。
5. 地域や大学に「こういうのが 1 つあると便利だよ」と言いたい理由
ここがこの記事のいちばん伝えたい話です。
5-1. 同じ仕組みを使い回せる
一度立てると、次の論文・次のチーム・次の学生 にもそのまま使えます。
研究室や地域の研究グループって、論文を 1 本出して終わり にはなりません。先輩 → 後輩 → さらに後輩、と引き継がれていきます。一度しっかり作った "箱" は、永遠にコスパが効くインフラになります。
5-2. 新人・学生のオンボーディングが圧倒的に楽
新しく入った学生に対して、
- 「過去のやりとりはこのサイトの経緯タブを上から見て」
- 「コメントはここ、ドラフトはここ」
これだけで 数十分 でだいたい雰囲気がつかめます。
これを「メールフォルダを掘って」「Drive のどこかにある」でやってもらうと、初日で挫折 します。
5-3. 海外との温度差を機械で埋められる
海外の共著者にとって、日本語でやりとりされたコメントは 「読めない壁」 です。
自動翻訳がサイト内に組み込まれていると、英語側は英語のまま、日本語側は日本語のまま 議論ができます。「翻訳作業」というタスク自体が消えます。
5-4. 「地域単位」だと運用コストが分散される
1 つの研究室で立てると個人負担になりますが、地域の研究会・複数の大学共同・学会単位 で 1 つ立てておくと、
- 月額のクラウド代を 割り勘 にできる
- 管理者を交代制 にできる
- 学生バイト・院生・若手研究者の 腕試しの場 にもなる
「地域でこういう箱があると便利だよね」 と言いたいのは、ひとりで抱えるとしんどい からです。
🔰 「バージョン管理」って何？
文書やプログラムの 「いつ・誰が・どこを変えたか」を全部記録する仕組み のことです。
ふだん意識しないかもしれませんが、Word の「変更履歴」も簡易バージョン管理です。コラボサイトでは、ドラフト v6, v7 …… と段階を踏める ので、「あの修正前の状態に戻りたい」が現実的に可能になります。
🔰 「経緯（タイムライン）」って何？
起きたことを古い順に並べた記録 です。
論文プロジェクトでいうと、
- いつ着想した
- いつ投稿先を決めた
- 誰が何の修正を入れた
- どの先生にいつ合意をもらった
これを 1 つの画面に並べておく と、トラブったときの戻り先がはっきりします。
6. よくある誤解・注意点
6-1. 「セキュリティが心配」
当然です。 共著論文の原稿は 発表前の知的財産 なので、外に漏れたら一大事です。
最低限ですが、以下くらいは必須にしておくと安心です。
- 必ずログイン制（誰でも見られる状態にしない）
- 共著者のメールアドレスを許可リストに登録
- 無関係な人の登録は管理者が止める
- 本番 URL を SNS にうっかり貼らない
- 画像・スクショに患者情報・実名が写り込んでいないか毎回確認
6-2. 「自分でサーバ建てなきゃいけないんでしょ？」
実は クラウドサービスをつなぐだけ で動きます。
- 表示部分 → Vercel / Netlify（無料枠で十分）
- ログイン → Clerk（無料枠あり）
- データ保管 → Supabase（無料枠あり）
最初の数か月は 0 円〜数百円 で運用できるレンジです。
6-3. 「コードが書けないと無理？」
ある程度は必要です。 ただし「ゼロから全部書く」必要はありません。
- 既製テンプレートを 改造する
- 生成 AI に 章立て・コメント機能の雛形 を作ってもらう
- 詰まったら 共著者の中で技術寄りの人を 1 人巻き込む
「全部いきなり完璧にしなくて大丈夫」です。コメント欄だけ動く最小版 から始めて、半年かけて経緯タブや翻訳機能を生やす、で十分間に合います。
7. 立ち上げのコツ — 最低限チェックリスト
「自分の周りでも作ってみたい」となったときの、最初の 1 週間でやること をまとめておきます。
- 共著者の メールアドレス一覧 を確定する（ログイン許可用）
- ドラフトを Markdown で書く運用 に切り替える
- コメント欄だけ動く 最小版をまず立ち上げる
- 誰でもドラフトを書き換えられる状態にしない（編集権限は管理者だけ）
- バックアップを 週 1 回 は別の場所に取る
- 翻訳機能・経緯タブなどは 後から増やす 方針にする
最初から全部入りを狙わない、これだけ守れば事故りません。
まとめ — 論文コラボサイトは "情報源を 1 つにする箱"
最初に出した表の通り、共著論文の本当の敵は 「情報源が散らかっていること」 でした。
論文の中身が高度なのは仕方ない。
でも 「やりとりの場所」 は、技術でほぼ全部、整理整頓できます。
| 起きていたこと | 仕組みで起きるようになったこと |
|---|---|
| メールで最新版が迷子 | サイトに 1 個だけ存在 |
| 翻訳で疲弊 | 自動で両言語表示 |
| 投稿先の変更が伝わらない | バナー＋経緯タブで自動共有 |
| 過去の合意が掘れない | タイムラインに残る |
| 新人が浦島太郎 | 経緯タブ + ドラフトでオンボーディング完結 |
「面倒なやりとり」 が 「育てるインフラ」 に反転するイメージです。
地域や大学に 1 つこれがある だけで、論文の本数も学生の育ち方も静かに変わります。今ちょうど共同で論文を進めている方、所属で原著論文を書く機会がある方は、研究テーマと独立に、まず "やりとりの箱" から整えてみるのを強くおすすめします。
全部いきなり完璧にしなくて大丈夫。コメント欄だけ動く最小版から、一歩ずつで OK です。
参考資料
- Next.js 公式ドキュメント
- Clerk 公式ドキュメント
- Supabase 公式ドキュメント
- MDPI 投稿規程（投稿先選定で迷う方向け、ただし雑誌ごとに章立てが異なるので個別確認推奨）
著者について
臨床工学技士 × AI エンジニア。教育関係の仕事もしています。
医療と IT のあいだで動きながら、現場目線で発信中です。
- note: https://note.com/taichi_endoh
- Qiita: https://qiita.com/TaichiEndoh
- X: https://x.com/endoh_taichi
質問・情報提供・コラボ提案、いつでも歓迎です。