毎回、論文を書くたびに似たような指示を AI に出しているのが面倒になってきたので、論文制作を補助するエージェントを作ることにした。
実際にやらせてみると便利な一方で、かなり危ない失敗もあった。この記事では、失敗例と対策を記録しておく。
AI に論文の構成を任せると、1つのファイルで完結させようとすることがある。長文の論文が必要でも、全体を短くまとめてしまい、そのうち「丸めたこと」自体を忘れて、ロジックを進めてしまう。
2026年5月時点では、AI に論文を書かせる場合、コンテキストサイズの制限をかなり意識する必要がある。
特に重要なのは、次の指示である。
簡略化を依頼していない。 読者向けに分かりやすくすることは、削除・縮約・丸め込みではない。
AI は「読者目線」「平易化」を「短くする」「削る」と解釈しがちである。これは構造的な問題として警戒したほうがよい。
私はプログラミングの知識を論文構成に応用している。しかし、AI にその比喩を説明すると、論文本体に Controller や Service のような単語が漏れることがある。
これは読者向けの本文ではなく、内部設計用の比喩である。本文には出してはいけない。
AI に悪意があるわけではない。しかし、次の性質が組み合わさると、結果として「悪意のような破壊」が起きる。
迎合的傾向 直近の指示に過度に従い、過去の蓄積を軽視する。
簡略化偏向 「短く」「読みやすく」を優先しすぎて、深い構造を削る。
外部評価追従 別 AI の意見を権威化し、自分で判断しなくなる。
反復ドリフト イテレーションを繰り返すうちに、少しずつ同じ方向へ寄りすぎる。
既存資産無視 文脈に入っていない過去の蓄積を、存在しないものとして扱う。
AI の主観的「分かりやすさ」判定 AI は論文全体を一度読んで内部辞書を作っているので、初出語の説明欠落に気づきにくい。読者は上から順に読むため、初出時に説明がなければそこで脱落する。
論文ソースには、読者に見せる文章と、内部の構成管理メモが混ざりやすい。AI エージェントには、この区別を明示しないと混同する。
本文に内部管理用語が漏れると、読者には「何の話だろう」と見える。また、「小学生向け解説」のような見出しは、内容としては平易な説明を意図していても、読者を小学生扱いしているように受け取られかねない。
本文に漏れやすい語の例：
ChatGPT 観点 N 採用編集段階 123Layer 1 / Layer 2glossary林命名指針ViewportCore2小学生向け解説これらは内部管理用語である。残したい場合は削除せず、HTML コメントに退避する。
<!-- 内部編集メモ: ChatGPT 観点 2 採用。本文には出さない。 -->重要なのは、読者向けではない = 削除 と短絡しないことだ。 可視性と価値は別軸である。
AI は専門用語を理解した状態で文章を読み返す。そのため、初出語に説明がなくても自然に読み飛ばしてしまう。
しかし読者は線形に読む。初出時に説明がなければ、以降の本文が暗号になる。
対策：
AI は高速に文章を処理する際、並列にチャンクごとに処理しがちである。そのため、各チャンクは正しくても、読者が上から読んだときの感情の流れを見落とすことがある。
論文では、局所的な正しさとは別に、読者の状態を順に追う必要がある。
チェックすべき読者状態：
reader_state =
現在地が分かるか
次に何が出るか予告されているか
未説明語で不安になっていないか
数式負荷が急に上がっていないか
内部メタ情報で集中が切れていないか
次の段落へ自然につながっているかこれは「チャンクごとの正しさ」ではなく、「上から読んだときの読者体験」のチェックである。
長文論文では、AI のコンテキスト制限があるため、文章をチャンクに分けること自体は避けられない。
問題は、チャンクを並列に処理してしまうことである。並列処理すると、各チャンクは局所的に読みやすくなっても、読者が上から読んだときの理解状態が次のチャンクに引き継がれない。
そのため、長文論文を AI に点検させるときは、チャンクごとに reader_state を引き継がせる。
reader_state =
ここまでで読者が理解したこと
まだ仮置きの言葉
次に説明されると予告されたこと
読者が不安に思っていそうなこと
数式負荷が高かった箇所
直前チャンクからの未回収の問い各チャンクの最後に、AI は次のチャンクへ渡す引き継ぎメモを書く。
next_reader_state =
読者は「観測の窓」が何かは理解した
ただし Q0 はまだ名前だけで、意味は十分に説明されていない
次チャンク冒頭では Q0 を一行で説明してから式に入るべき
直前に数式が続いたので、次は一般語の橋文を置くとよい次のチャンクは、この next_reader_state を入力として処理を始める。
つまり、AI に必要なのは単なるチャンク処理ではなく、読者状態を持った逐次チャンク処理である。
AI エージェントを複数使う場合、会話だけでは状態管理が破綻する。そこで、AI 同士が読める掲示板を作るとよい。
最低限、次の2つがあればよい。
AI掲示板.jsonl
AI掲示板.htmljsonl は機械処理用、html は人間確認用である。
掲示板には次を記録する。
例：
※ 林 の部分は、各自の名前やプロジェクト名に読み替えてほしい。
{
"id": "codex-2026-05-25-s4-primary-base-adopted",
"from": "Codex",
"to": ["Claude Code", "林さん"],
"status": "ADOPTED",
"topic": "林S4主母体",
"action": "林S4四次調和母体読取基底を主母体として採用。S2/H11 は読取インターフェースとして扱う。",
"next": "S4->S2 と S4->H11 の二つの変換補題として整理する。"
}GitHub Issues や Forgejo の issue 管理は便利である。しかし、AI 時代には、AI が自分たちの作業に合わせた軽量な issue 管理を用意できる。
人間用の issue tracker ではなく、AI が読み書きしやすい掲示板を作る。これはかなり有効だった。
AI は「確認待ち」に逃げやすい。もちろん、人間の判断が必要な場合は止まるべきである。しかし、補助補題、表記ゆれ、参照補強、読者向け説明、source 経由の再生成などは、AI 側で進めてよいことが多い。
そのため、掲示板やプロンプトに次のルールを入れておく。
人間の判断が必要なもの:
- 中核主張
- 母体構造
- 用語体系
- 分割方針
- 保存運用
- 既存裁定との衝突
- 生成物の直接編集
AI 側で進めてよいもの:
- 補助補題
- 一般語説明
- 型定義
- 射影列
- 数式導出
- 参照補強
- 局所用語表
- 表記ゆれ修正
- 読者誘導リンク
- source 経由の再生成さらに、AI にこう伝える。
推奨行動があるなら、そこで止まらずに進める。 判断が必要な場合だけ、人間に確認する。
これにより、「はい、お願いします」という無駄な介入を減らせる。
長文論文は、1つの巨大 Markdown に直接書くより、source を分割して、最後にコンパイルするほうがよい。
考え方はプログラムに近い。
論文にも「未宣言変数はコンパイルエラー」という発想を持ち込む。未説明の専門用語は、論文における未宣言変数である。
AI に伝えると有効だった考え方：
特に重要なのは、命名である。短くてかっこいい名前より、混線しにくく型安全な名前のほうが論文では強い。
AI に論文を書いてもらうときには、フェーズを分けるとよい。
補題は階層的に増えるため、Excel や表で管理するとよい。インデント付きで補題の親子関係を持たせると、かなり見通しがよくなる。
ブラッシュアップでは、次を確認する。
「小学生向け」という見出しは使わない。読者を見下しているように見えるためである。代わりに「平易な比喩」「直感的説明」と書く。
Markdown で正しく見えても、PDF で壊れることがある。Markdown → HTML → PDF の各段階に独自の前提があるためである。
確認すべき点：
$...$ が残っていないかtext などの言語指定があるか内部メモ漏れの grep 例：
grep -E "ChatGPT 観点|編集段階|林命名指針|Layer [0-9]|局所 glossary|Reviewer [0-9]" paper_public.md0件になるのが理想である。
AI が何かを削除しようとしたら、必ず次を確認する。
読者に見せる必要がなく、管理者に価値があるなら、削除ではなく HTML コメントへ退避する。
用語を置換する時は、次を確認する。
新しい専門用語・固有名詞・略号を出す時は、次を確認する。
AI が理解していることと、読者が理解できることは違う。
ここまで書いた内容は、振り返ってみるとほぼ毎回 AI に同じ趣旨で頼んでいることだった。指示を出すたびに「またこれか」と思うのも疲れる。なので、最近よく出している指示そのものを、5 つの「お願い」として残しておく。次に同じズレが起きたら、「ブログのここを読んで」 と AI に投げて済ませる。
内容を弱めるんじゃなくて強化。内容を薄めるんじゃなくて、説明の階段を作る方針でお願いします。
AI に「初学者には難しい」と指摘すると、AI は文章を短くカットする方向に動きやすい。これは「悪意のような破壊」の 簡略化偏向 と同じ問題だ。
正しいのは 階段 ── 初学者向けの直感説明と、上級者向けの専門用語を、両方並べる。両方の読者が同時に読める文章にする。
階段の例：
初学者は最初の文で意味を取り、上級者は括弧内で専門用語の対応を確認する。
ルール化：
長文だから計画立てて進めないといけないよな。AI だってコンテキストサイズの制限という弱点あるから、チャンクに区切って確認しないとな。なので、チャンクごとにペルソナの状態を次のチャンク読み取り開始に引き継ぐことが必要だな。サブエージェントを使う必要があるかもな。計画して、チャンク間のペルソナというバトンタッチをする感じだな。
これは前述の「チャンク処理はしてよいが、読者状態を引き継ぐ」を運用ルールに落としたもの。
長文を AI に読ませてレビューさせると、一度に全部読むと劣化するし、ペルソナを保ったまま長時間読書するとペルソナがブレる。なので：
reader_state を JSON で構造化する。next_reader_state をバトンタッチする。ペルソナ自体も JSON で固定する。「修士 1 年、Bell 不等式は教科書レベル、Kerr 計量は名前のみ、BCS 理論は学部レベル」のように、既知・未知のリストを明示する。
括弧書きで難しい単語の説明書いてくれてありがとう。でもね。その括弧の中が難しいとよくないと思うんだ。括弧で説明を書いたときに、はたして初学者向けの説明になっているかどうかが必要だと思う。BCS理論が説明の中に書かれていて、それも説明の対象だよな。って思ったんだ。入れ子で説明してもいいけどもっといい書き方があるかもしれないからくふうしてみてほしい。
お願いその 1 で「階段を作って」と頼むと、AI がやりがちな失敗：
これは循環している。「BCS 理論」を説明するのに「BCS 理論」を使っている。読者には何も伝わらない。
ルール化：
修正例：
ついでに、同じお願いの後半でこうも言っている。
ペルソナで読み進めてほしいけど、その際に課題を上げていってほしいんだ。課題で横展開できそうなものがいくつか上がったら、いったんペルソナで進めるのを中断して、文章のブラッシュアップをしたほうがいいかもな。
これは 中断ルール だ。ペルソナ読書中に同じ課題が複数箇所で見つかったら、読書を中断して文章を直す。直してから読書を再開する。線形読書を死守しつつ、横展開できる課題は一括解決する。
読者のペルソナを作って、上から順に読書体験をしていき読者が抱く感想、疑問、感情を逐次加筆修正し、読者が自分の時間を削ってでも読みたいかどうかシミュレーションしてみてほしい。また読者の理解がこちらの伝えたい内容と合うのか確認してほしい。これは並列処理を使ってはならない。上から順に読む人間のようにやってみてほしい。AI であるあなたはいろいろ理解しているが、このペルソナでは論文についてはまだ知らされてない想定をしてどうなるか確認してほしい。
「読者目線でレビューして」と頼むと、AI は並列で論文全体を grep して「だいたい OK」と返してくる。それは AI のレビューであって、人間の読書ではない。
人間の読者は線形に上から下に読む。途中で詰まれば離脱する。これをシミュレートするには、AI に 「並列禁止、上から順、知っている知識を封印」 と明示する必要がある。
ルール化：
ポイントは、AI である自分が知っている知識を意識的に封印すること。AI は論文を最初から全部読んで内部辞書を作っているので、初出単語の説明欠落を主観的には検出できない。ペルソナでこれを矯正する。
残すべき項目を一覧表にして詰めていきましょう。何かファイルを決めて管理しましょう。それぞれの進め方の基本は、まず、林命名指針を意識して、小学生でもわかるように解説する。次に関連しそうなルールを並べる。既存の論文を探してもいいかもしれない。そのうえでシャーロックホームズモードで眺めてみる。一番親和性の高そうなものベースにする。進め方は、補題をたてて、詰める。というイテレートを区切りのいいところまで進める。一覧表の進捗を更新する。
論文の残課題が積もると、AI は「全部やります」と言って何も終わらない。これを防ぐのが 一覧表管理 だ。
運用フロー：
ルール化：
c_lemma_list.md)。| お願い | 一言で | 対応する本記事のセクション |
|---|---|---|
| その 1 | 弱めずに強化、薄めずに階段 | 内部管理用語の本文漏れ |
| その 2 | チャンク + ペルソナバトンタッチ + サブエージェント | チャンク処理はしてよいが、読者状態を引き継ぐ |
| その 3 | 括弧の中身も平易に (入れ子説明禁止) | 新出語の説明欠落 |
| その 4 | ペルソナで線形読書 (並列禁止、知識封印) | 読者はチャンクではなく上から読む |
| その 5 | 課題一覧 + シャーロックホームズモード + 補題イテレート | フェーズ管理 |
「悪意のような破壊」6 項目が AI 側の構造的傾向 だとすると、この 5 つは AI を動かすときの戦術ルール である。両方を持って運用すると、AI と論文を作る作業がぐっと安定する。
ここまでで AI への指示ルールを「5 つのお願い」として整理した。しかし、ルールだけでは足りない場面がある。AI がルールを無視して暴走したとき、人間が気づくまで止められないからだ。
実際に私の場合、「作業ディレクトリを勝手に切り替える」「他論文を削除する」「巨大 commit を 1 つで通す」といった事故が積もり、ある朝に I: ドライブの物理故障と重なって大規模な復旧作業を強いられた。
このとき気づいたのは、Claude Code 自体が標準機能で多くの予防策を提供している ということだった。CLAUDE.md (advisory) で「ダメと書く」だけでは足りず、Hooks (mandatory) で harness レベルで強制する 必要がある。
| 困ったこと | 標準機能で解決 | 追加 plugin / 既存 agent で解決 |
|---|---|---|
| AI が論文 dir を勝手に削除 | Hooks (PreToolUse) で rm -rf を事前確認 |
security-engineer agent |
| AI が作業 dir を勝手に切り替え | Hooks で cd 系を検出 + 通知 |
devops-architect agent |
| 編集ミスでファイル消失 | /rewind Checkpoints (Claude 編集前の自動 snapshot) |
git の commit 粒度を細かく |
| 同じ指示を毎回出す | Skills (.md template、Claude 自動 invoke) |
wshobson/agents から流用 |
| 並行作業で状態管理が破綻 | Subagents で context isolation | barkain/workflow-orchestration |
| AI が独断で大規模 commit | git-commit-manager agent を明示起動 |
Hooks で commit ファイル数閾値 |
| 物理ドライブ破損 (進行性) | 定期 git push、複数物理ドライブにミラー |
GitHub Actions で自動 backup |
| AI のレビューが「だいたい OK」で終わる | Subagent で 既知知識を封印 したペルソナ | paper-audit-watchdog のような自作 agent |
Anthropic 公式が示すのは、次の 3 層構造である。
| Layer | 用途 | 性質 | 林さん事故への効果 |
|---|---|---|---|
Skills (.md template) |
reusable prompt template、Claude が文脈で自動 invoke | advisory | 「5 つのお願い」を skill 化して移植可能に |
Hooks (settings.json) |
lifecycle automation、pre/post tool 介入 | mandatory | 削除・破壊コマンドを harness レベルで止める |
| Subagents | parallel task delegation、別 context | isolated | バックアップと議論を並行、メイン汚染なし |
要点:
私の今回の最大の事故は「F:\prj で他論文を勝手に削除した」ことだった。CLAUDE.md に「削除禁止」と書いてあっても、AI が判断ミスで実行してしまえば止められない。
これは Hooks で防げる。~/.claude/settings.json に次を追加する。
{
"hooks": {
"PreToolUse": [{
"matcher": "Bash|PowerShell",
"hooks": [{
"type": "command",
"command": "block_destructive.sh"
}]
}]
}
}block_destructive.sh の中身は、引数 (= 実行されるコマンド) に rm -rf / Remove-Item.*-Recurse / git reset --hard / git push.*--force が含まれていたら exit 1 で停止 する単純なスクリプトでよい。
これで、AI が rm -rf を実行しようとすると harness が止める。CLAUDE.md と違って、AI 側で「今回は例外」と判断する余地がない。
/rewind) — Claude 編集前の自動 snapshotClaude Code は、ファイル編集前に 自動的に session-level snapshot を作る。これは /rewind コマンドで巻き戻せる。
注意点として、これは Claude の編集だけ を track する。外部プロセス (今回の I: ドライブ破損のような物理層の問題) は対象外である。git の代替ではない。
それでも、AI による直近の編集事故 (数十分以内) なら、/rewind で即時復元できる。覚えておくと一段安全になる。
今回、「バックアップ作業」と「議論」を同じセッションで進めようとして、状態管理が破綻した。途中で並行セッションを作ろうとして手書きのプロンプトを 1500 字書く羽目になった。
これは Subagent で解決する。
親エージェント:
└─ subagent: F:\ への退避 (context isolation)
└─ subagent: 削除事故の root-cause 分析
└─ subagent: git worktree での iter32 統合各 subagent は独立した context で動く。親エージェントは state 管理に専念する。同じファイルを 3 つの subagent が触ろうとしたら、親エージェントが調停する。
ペルソナ読書も同じ。修士 1 年 / 学部 1 年 / 専門家の 3 ペルソナを並行で読ませる場合、subagent 化すれば各ペルソナの「知らないふり」が混線しない。
「Claude Code Plugins」という公式ライクなマーケットがあり、コミュニティ製の plugin / skill / MCP server が大量に集まっている。主要なものをメリデメで比較する。
| Plugin / Platform | メリット | デメリット | 私の状況への適合度 |
|---|---|---|---|
| wshobson/agents | 83 plugins / 191 agents / 155 skills / 102 commands (最大級)。Codex CLI / Cursor / OpenCode / Gemini と互換、MD source 1 つで多 CLI 対応 | 規模が大きく取捨選択必要 | ★★★ Codex CLI と併用する環境にマッチ |
| barkain/workflow-orchestration | 自動タスク分解、並列 agent 実行、専門 agent delegation、約 6.6K tokens 節約 | 2026 リリースで stability 未知、Claude Code 専用 | ★★★ 並列作業の自動化に直結 |
| Shipyard | production-ready managed platform | 有料、vendor lock-in、local control 失う | ★ 個人運用には過剰 |
| Ruflo | 311 MCP tools registered、verification pipeline 付き | 新興 platform で信頼性未確立、context 圧迫リスク | ★ 大規模 team 向け |
| jmanhype/plugin-marketplace | 19 plugins (multi-agent trading / swarm / GitHub 自動化) | 用途偏り (trading 等)、論文管理向きでない | ☆ 不適合 |
| ccstatusline | real-time 異常監視、大量削除検出 | install 必要、カスタマイズ要 | ★★ 監視層として追加 |
Claude Code には、ローカルに専門 agent を置ける仕組みがある (~/.claude/agents/*.md)。私の場合、すでに用意してあるのに 明示起動しなかった ことで事故を招いた。
| Agent | 使うべきだった場面 |
|---|---|
root-cause-analyst |
ドライブ破損の根本原因分析 (私は独断で「物理故障」と判断) |
devops-architect |
F: → 新 SSD 移行計画 (私が即興で立案) |
git-commit-manager |
1194 ファイルの commit 分割 (私が 1 commit で push) |
security-engineer |
削除コマンドの事前検査 (起きなかった) |
paper-audit-watchdog (自作) |
論文の中核破壊検出 (この 1 つだけは活用済み) |
pure-persona-naive-reader (自作) |
読者目線検証 (これも活用済み) |
ルール化:
root-cause-analyst を起動して」と指示する。paper-audit-watchdog のような) で 林命名指針 を強制できる。中核用語の出現数を git commit 前後で diff し、急減を検出したら警告する。私の理想的な運用は、次のようになる。
.md template 化して、Claude が文脈で自動 invoke する。root-cause-analyst 等) を明示起動して、私 (人間) の代わりに専門判断させる。wshobson/agents や barkain/workflow-orchestration を install して、orchestration 層を自動化する。/rewind Checkpoints で直近事故の即時復旧、git push の高頻度化で長期事故の備え。これらを揃えると、「悪意のような破壊」の 6 項目 (迎合 / 簡略化 / 外部評価追従 / 反復ドリフト / 既存資産無視 / 主観的分かりやすさ) は 構造的に発生困難 な状態になる。
ルールだけで AI を縛るのではなく、ツールで予防する。これが、AI と論文を作る作業を長期で安定させる最後の砦である。
論文を書く AI エージェントには、単に「文章を書け」と指示するだけでは足りない。
必要なのは、次の仕組みである。
AI は高速に大量の文章を処理できる。しかし、その高速さゆえに、読者が上から読んだときの不安や脱落を見落とす。
だからこそ、論文制作エージェントには「正しい文章を書く能力」だけでなく、「読者が順に理解できるように運用する仕組み」が必要である。
