松尾研究所テックブログ
📝

Claude codeと論文書いたら良い論文“は”できた

Taisei Ozaki
に公開
NLP
llm
論文執筆
Claude Code
Codex CLI
tech

こんにちは，松尾研究所の尾崎です．25卒でデータサイエンティストをやっています．

皆さん，CLI Agent使いこなせてますか？

自分はClaude CodeをオーケストレーターとしてCodex CLI・Gemini CLI・Opusサブエージェントを協調させる開発環境Claude Code Orchestraを作ってきましたし，最近は自分のObsidian vaultを複数エージェントで回すClaudian Orchestraという環境も育てています．

今回はCLI Agentと論文執筆にチャレンジしたので，備忘録を作ります．先月ARR（ACL Rolling Review）に投稿した分析論文を，Claude Code Orchestraと一緒に約 7 週間かけて実験から執筆まで回してみました．タイトルのとおり，大変でしたが，良い論文”は”できました．

TL ; DR

  • AI研究における学習→評価→分析の反復はLLMの台頭で高速化が予見され，CLI Agent化によって現実に速くなりました．この7週間での結果量はAI時代以前であれば倍以上の時間がかかっていたと思います．
  • ただし，結果から「意味のある示唆」を取り出すところは，スキルを足す程度の工夫では自動化できませんでした．研究のいちばん重要なところは，まだ人間の仕事だなという所感です．
  • バイブコーディングに対する「バイブライティング」の仕組みづくりは，まだ誰もベストプラクティスを持っていないと思います．Overleafの使い方を覚えるのと同じくらい当たり前のものとして，これから皆で開拓していく領域だと感じています．

1. なぜ論文執筆をCLI Agentでやるのか

「AIで論文を書いてみた」という体験談自体は，もう珍しくありません．橋本幸士氏（京都大学・理論物理）の「約 1 時間で論文原稿」デモ（堀田昌寛氏の論考），genkAIjokyoによるAI特有の「9 のクセ」の整理，医学系のIMRAD連載など，事例と知見は着実に蓄積されてきています．

そして，コーディングの世界ではCLI Agentに設計と実装を委ねる「バイブコーディング」がすっかり定着しました．論文執筆も本質的には「リポジトリの中でコードとテキストと図表を育てる」作業なので，現在のCLI Agentと論文を書くのはバイブコーディングするのと同じくらい自然なはずです．「アカデミック バイブライティング」とでもいいましょうか．(Vibe Writing自体は色々なところで言われているようです．)

今後の科学では，AIと一緒に研究活動を行い，AIと一緒に論文を書くことは規定路線ですし，なんならAIだけで執筆まで行われる世界になります．その過渡期にあるなかで，（少なくともコーディングにおいては成熟を見せている）CLI Agentsを適切に使用し，研究ワークフロー全体をオーケストレーションしたらどこまでいけるのか．それを確かめたのが今回の 7 週間でした．

2. 今回の論文執筆の前提と取り組み

2.1 研究の流れ：「事後学習→評価→分析→示唆→整理」の大量反復

今回の研究は，「LLMの事後学習→評価→分析→示唆の取り出し→整理」というループを大量に繰り返す必要がある分析研究でした．書き始めた時点で持っていた仮説に基づいてアブレーションスタディをリストアップし，実際に学習を回し，評価し，分析し，示唆を取り出す．これを仮説が検証しきれるまで回し続けます．

仮説 → アブレーションのリストアップ → 事後学習（SFT/DPO/RL） → 評価 → 分析・可視化 → 示唆の取り出し → 整理 →（仮説の更新に戻る）

環境はClaude Code Orchestraです．実験コード・結果JSON）・図表・先行研究メモ・論文原稿を 1 つのリポジトリに同居させ，CLI Agentがすべてをファイル参照できる状態で走りました．役割分担はざっくりこうです．

工程 主担当
先行研究サーベイ Opusサブエージェント（1M context + WebSearch）
論文PDFの精読 Gemini CLI（マルチモーダル）(当時はまだGemini CLI現役)
実験設計・RQレビュー Codex CLI
実験コードの実装 /team-implement（Agent Teams）
再現性・品質レビュー /team-review
査読者視点レビュー /codex:adversarial-review
ドラフト執筆・統括 Claude Code（指揮者）

※細かな各スキルはClaude Code Orchestra提案のテックブログ，リポジトリをご覧いただけますと！

2.2 学習から評価・可視化までは，圧倒的にスムーズだった

Claude Code Orchestraがもともとコーディングエージェントの環境としてデザインされていることもあり，学習から評価までのパイプラインはスムーズに整理できました．実験の実装は /team-implement でファイル所有権を分けて並列化し，再現性（seed固定・設定の外出し・結果JSONへの集約）は /team-review でチェックする，という開発ワークフローがそのまま研究に流用できたわけです．

wandbから学習中のrolloutを取り出して眺める，分析結果から図表を量産する，といった周辺作業も，「同じ操作を 2 回やったらスキルにする」を繰り返すうちに自動化されていきました（スキルは最終的に 34 個）．7 週間の実測値はこんな感じです．

指標 値
プロジェクト期間 約 7 週間
実験run数 約 108
分析コード（Python） 約 46,000 行
図表ファイル 432 枚
先行研究の整理本数 46 本
Codex CLI呼び出し / Gemini CLI呼び出し 90 回 / 62 回
論文執筆用カスタムスキル 34 個

※実際は学習コードや評価用コードは別途存在していたので，全体では約124k行程度でした．論文執筆を本格化してからの分析関連コードがClaude Code Orchestra担当リポジトリにありました．
※Codex CLI / Gemini CLIの呼び出し回数は，スキル経由の明示的な委譲回数です．Claude Code自身の推論・文書生成のAPIコールはこの数字に含まれていません．

run数が増えるにつれて，「どれが正規の比較対象か」の管理が煩雑になるのも確かです．wandbで追跡はできていましたが，108 本のrunの中から意味のある比較を人間が把握し続けるコストは無視できませんでした．KagglerコミュニティでもCLI Agent時代の実験管理は議論が続いており，ベストプラクティスはまだ開拓中です．

今回の 7 週間で取り出せた量は，AI時代以前なら明らかに 2〜3 か月はかかっていたはずです．少なくとも「実験を回して結果を積む」フェーズに関して，CLI Agentは文句なしに強力でした．

2.3 本丸は「示唆の取り出しと整理」で，そこが難しかった

ただ，研究活動においていちばん重要なのは，結果に基づいて示唆を取り出すところです．立てた仮説を適切に検証しつつ，意味のある知見を取り出せるか．この観点では，既存のClaude Code Orchestraにちょっと思いつく限りの工夫（スキルの追加など）を足した程度では，正直難しかったです．

具体的な症状として現れたのが，論文構造の作り直しです．432 枚の図表と約 108 本のrunが手元にあっても，「どの結果がどの主張を支えるのか」「この差分は仮説に対して何を意味するのか」は自動では立ち上がってきませんでした．CLI Agentはもっともらしい解釈を量産してくれますが，それが仮説に照らして意味のある示唆なのかの判断は毎回人間の介入が避けられないなぁとの所感を持ちました．結果として論文構造はv3 → v10 まで 7 回作り直すことになりました．

逆の見方をすれば，CLI Agentがあってこそ 7 回の作り直しが現実的なコストで完遂できた，とも言えます．大部分が揃った段階で複数人が共同執筆しているOverleafドキュメントは構成を崩しにくいものですが，Vibe Writingはアジャイルで，構造を一から組み直すことへの心理的・時間的コストが格段に小さくなっています．

3. CLI Agentと論文を書くということ

3.1 バイブライティングの仕組みづくりは，皆で開拓していく段階

Overleafの使い方を学ぶのと同じくらい，「バイブライティングをうまくワークさせる仕組みづくり」は論文を書く人の基礎教養になっていくと思っています．そして自分たちはまだ，そのベストプラクティスを見つけられていません．昨今，PKB（個人の知識基盤）の構築がプロトコル化されつつあり（前記事のClaudian Orchestraもその流れのひとつです），CLI Agentでのバイブライティングにおけるエンジニアリングも，これから同じように開拓されていくはずです．

自分たちが 7 週間の試行錯誤から学んだ「仕組みの種」としてはこのあたりがありました．

  1. 骨子は人間が最初に固めて，確定版としてrepoに置く：RQ・主張ツリー（claim → sub-claim → evidence）・「どの実験runがどの主張を支えるか」のマッピングを人間が確定し，.claude/rules/ に書き込んで毎回コンテキストとして与える．CLI Agentは会話の勢いで平気で構成を“改善”しようとしてくるので，「骨子の変更は人間どうしの合意が先」と機械的に線を引けるようにしておく．自分たちはここを後回しにして，v3 → v10 の作り直しというツケを払いました
  2. 人間とCLI Agentの共同執筆プロトコルを最初に決める：CLIに指示して書く人とOverleafに直接書く人が混在した結果，版の衝突が頻発しました（最終的に「全員Overleaf直接」で収束）．実はKordingLab（Duke）のLLM4Papers（2024）が，clobber-avoidance（人の編集中はLLMが待つ）・debouncing・明示的トリガ（% @ai: コメントの箇所だけ編集）という形で，この問題を 2 年前に扱っています．知らずに走って同じ穴に落ちました
  3. 研究関連物はできるだけ 1 つのリポジトリで管理する：実験コード・結果JSON・図表・先行研究・原稿が同じrepoにあると，本文の数字 → 結果JSON → 生成スクリプトの遡行がCLI Agentにとって単なるファイル参照になります．主張と証拠の整合チェック（claim-evidence-audit スキル）が実用になったのはこのおかげです．ただし人間どうしの共有はGoogle Spreadsheetのほうが楽な場面もあり，そこにGWS CLIでCLI Agentをつなぐといった工夫の余地があります

3.2 変わらないこと

一方で，AIと書くようになっても変わらないものもはっきり見えました．研究と論文執筆の古典的なノウハウです．森畑明昌氏の「研究とは何か」や松尾豊氏の「論文の書き方」にまとまっているような，「人類の知識の総量を増やしてゆく活動」としての研究の捉え方，「前提＋主張＋ディフェンス」という論の組み方，「勝負は評価実験前に」という考え方は死にません．むしろCLI Agentが下流の作業を肩代わりするほど，上流にあるこの部分の重みが増す感覚がありました．執筆研究の世界でFlower & Hayes（1981）以来ずっと言われてきた「計画段階が品質を決める」という命題も，そのまま生きています．

研究倫理も変わりません．引用の捏造（hallucinated citation）は査読コミュニティで強く問題視されていて，NeurIPS 2025 のaccepted papersの約 1 % にあたる論文から合計 100 件規模の捏造引用が検出されたという報告（GPTZeroの調査）や，ChatGPT-4 生成の引用文献は最大 7 割が偽物だったという報告（Kacena et al., 2024）もあります．自分たちは「引用は必ず人手で原典（arXiv / ACL Anthology / DOI）に当たって実在確認する」「本文の数字は必ず生データ（結果JSON・ログ）と照合する」「最終的な主張の責任は著者が持つ」をプロジェクトのルールとして守りました．ちなみにElsevier / Springer Nature / Wileyをはじめとする主要出版社は，いずれもAIを著者・共著者として記載することを禁止しています．責任は人間にしか持てない，という立場です．

3.3 変わること：示唆がループの起点になる

いま現在，CLI Agentが出してくる示唆の品質は正直まだ悪いです．適切なコンテキスト（分析・結果）を与えても，いい示唆を取り出せるとは言えません．何をもって「いい示唆」とするかの言語化が，自分たちの側でもまだ足りていないという側面もありますが．

ただ，いつかそれもできるようになるかもしれません．Sakana AIのAI Scientist-v2が「100% AI生成の論文がICLR 2025 ワークショップの査読を通過した初の事例」を作った（採択は 3 本中 1 本で，本会議の基準には届かないと同社自身が評価し，事前の取り決めどおり取り下げています）ように，autoresearchの概念は着実に成熟しています．Sakana AI以外にもAI-driven scientific discoveryを目指すシステムが複数のチームから相次いで発表されており，autoresearch自体が 1 つの研究分野として立ち上がりつつある状況です．もしこれを書いていた時期にFable 5やgpt-5.6があれば話は変わったかもしれません．ただ「結果から示唆を取り出し，それを論文に落とし込む」ところが次の大きな開拓地だと理解し，Harness・Loopをデザインしていく姿勢が必要ですね．

なぜここが大きいかというと，取り出された示唆は，その研究を引用する次の論文のRQになるからであり，示唆が立てば問いが立つ．問いが立てば，それをもとにまたAIが研究できる．loopが回るわけです．研究のボトルネックが「実験を回す速さ」から「意味のある問いを立てる速さ」へ移っていく，と言い換えてもいいかもしれません．

3.4 autoresearchの世界で研究者は何をするのか

では，そのloopが回り始めた世界で，研究者は何をするのでしょうか．無限に取り出される知見を，人間はどう咀嚼するのか．ここで必要になるのが「認知のプロトコル化」だと思っています．

認知のプロトコル化とは，人間がどの粒度で・どのタイミングで・何を判断するかをあらかじめ設計しておくことです(Human-on-the-loopの考え方)．そしてそれはUIを考えるということ，つまりCLI Agentと人間の対話のプロトコルを考えることに等しいと考えられます．今回の論文執筆でも，CLI Agentによって一見スムーズに進んでいく研究に対して，人間が適切に介入するためのプロトコル作り（どこで承認を挟むか，何を人間の判断点として残すか，ほぼ無限に生み出される知見を人間はどういう形で摂取するべきなのか）は非常に重要なテーマだと感じました．

自分たちの現時点の答えが，§3.1 に挙げた「骨子を確定版としてrepoに置き，変更には人間の合意を要求する」「執筆経路を 1 本に絞る」といった仕組みたちです．どれも地味ですが，AIが速くなるほど人間の判断点の設計が効いてきています．昨今はLoopの監査役を人間が担うHuman-on-the-Loopが注目されますが，論文執筆といったより長期のCLI Agentとの協調においては，定期的なHuman-in-the-Loopを前提にしておくことも必要かもしれないと考えています．Human-out-of-the-loopの"時間"が長くなれば，その分一度に人間が認知しないといけない情報量が莫大になります．監査以外に認知することそのものが人間の作業と考えると定期的なHuman-in-the-loopを事前にデザインしておくHuman-on-the-loopの考え方が重要なように思います．

まとめ

タイトルに戻ると，CLI Agentと論文を書くのは大変でした．でも良い論文”は”できました．「は」に込めたのは，成果物の品質と，そこに至る過程の整い方はまだ別物だ，という感覚です．

「RQ設計 → 実験ループ → 論文化」の各フェーズでCLI Agentがどれほど効いたかを振り返ると，大まかにこんな感じでした．

フェーズ CLI Agentの貢献 コメント
RQ設計・仮説立て △ 壁打ち相手にはなるが，問いの良し悪しは人間が判断
アブレーション設計 ○ Codex CLIでリストアップ・整理
事後学習・評価実行 ◎ パイプライン自動化でほぼノータッチ
分析・可視化 ◎ スキル化で自動化（ファイル参照で一気通貫）
示唆の取り出し △ もっともらしい解釈は量産されるが，仮説照合は人間必須
論文執筆（文章化） ○ 骨子さえ固まれば速いが，骨子自体は人間の仕事
  • 学習→評価→分析の反復は，CLI Agentで劇的に速くなりました
  • 研究の本丸である「示唆の取り出し」は，まだ人間の仕事でした
  • バイブライティングの仕組みづくりは，Overleafの使い方と同じように，これから皆で開拓していくものだと思います

AIと一緒に論文を書くことが当たり前になっていく過渡期の記録として，本記事がどこかの研究チームの参考になれば嬉しいです．

何か質問やフィードバックがあれば，ぜひGitHubのIssueやXでお知らせください．

参考リンク

関連記事・テンプレート

研究・論文執筆の古典ノウハウ（§3.2）

AI×論文執筆の事例・先行知見（§1 / §3）

GitHubで編集を提案
松尾研究所テックブログ
松尾研究所テックブログ

株式会社松尾研究所のテックブログです。

Discussion