論文を読んで終わりにしないローカル研究ジムResearch Dojoを作った
はじめに
論文を読むときに、一番怖いのは「分かった気になる」ことだと思っている。
Abstractを読んで、Introductionを読んで、図を眺める。
なんとなく主張は分かった気がする。
でも、いざ人に説明しようとすると急に詰まる。
- 既存研究に対して何が新しいのか
- 手法のどの仮定が効いているのか
- 実験は本当にその主張を支えているのか
- 失敗条件はどこにあるのか
- 自分の研究に接続するなら何を検証すべきか
こういう問いに答えられないと、論文を「読んだ」とは言いづらい。
そこで作ったのが Research Dojo。
論文や技術トピックに対して、
読む -> 自分で答える -> 厳しく採点される -> 不足部分を知る -> 追加問題で鍛える -> 研究アイデアや実装タスクへ進める
というループを回すための、ローカル研究トレーニングアプリだ。
ポートフォリオ側に紹介動画も置いた。
何を作ったのか
Research Dojoは、研究論文・技術トピック・研究アイデアを扱うためのデスクトップアプリだ。
主な部屋はこうなっている。
- Paper Room
- Paper Idea Mode
- Topic Room
- Research Lab
- Codex Room
- Codex Tasks
Webアプリとして作ったNext.jsをElectronで包み、macOS / Windows向けにGitHub Releasesで配布している。
デスクトップ版はこちら。
中で動いているAI処理は、OpenAI APIキーをアプリに渡す方式ではない。
ローカルにログイン済みの codex CLIを使い、codex app-server を起動してJSON-RPCでやり取りしている。
つまり、Research Dojoはこういう構成になっている。
Research Dojo Desktop App
-> Next.js local server
-> local SQLite-compatible DB
-> spawn("codex", ["app-server"])
-> JSON-RPC
-> Codex logged-in environment
Paper Room
Paper Roomは、論文ごとの理解チェックをする部屋だ。
arXiv URLや論文メモを入れると、CodexがPaper Cardと問題セットを作る。
問題は単なる暗記確認ではなく、次のような観点を含めている。
- 研究の問題設定
- 既存研究との差分
- 手法の機構
- 実験設定
- 限界と失敗条件
- Reviewer視点の弱点
ユーザーは問題に対して自分で回答する。
そのあとCodexが100点満点でレビューする。
レビュー結果には次のような情報を含めた。
- total score
- rubric scores
- strengths
- fatal issues
- missing perspectives
- shallow phrases
- next fix
- revision challenge
- reading gaps
この中で特に大事なのは reading gaps。
単に「60点です」と言われても、次に何をすればいいか分からない。
そこで、回答から推測できる「読み込みが足りない箇所」や「再読すべき観点」を返すようにした。
たとえば、
- 実験節のbaseline比較が読めていない
- 手法の仮定と失敗条件が分離できていない
- 関連研究との差分が曖昧
- 評価指標が主張と対応していない
のような形で、次に読み直すべき場所を示す。
Adaptive Questions
最初の版では、問題を最初からまとめて出すだけだった。
ただ、それだと問題が溜まりやすい。
しかも、ユーザーがどこに弱いかが分かった後でも、最初に作られた問題を同じ重さで解くことになる。
そこで、回答履歴とレビュー結果を見て、次に出す問題を変えるようにした。
たとえば、あるユーザーが手法説明はそこそこできるが、実験設計が弱いとする。
その場合、次の問題では、
- baseline選定
- ablation設計
- metricの妥当性
- claimとevidenceの対応
- failure case
のような観点を重点的に問う。
これは、単なる問題生成ではなく「弱点に合わせて次の問いを出す」ための仕組みだ。
Paper Idea Mode
Paper Roomには、理解問題とは別にアイデアを育てるモードも入れた。
ここで意識したのは、AIにアイデアを出させすぎないこと。
研究アイデアは、自分で考えて、自分の仮説として育てる必要がある。
AIがそれっぽいアイデアを大量に出しても、自分の研究としては弱い。
なので、このモードではCodexは「答え」ではなく「厳しい問い」を返す。
たとえば、
- この論文の前提を1つ壊すならどこか
- 著者が見落としているデータ条件は何か
- この手法が失敗する分布シフトは何か
- 自分の研究テーマに接続するなら最小実験は何か
- そのアイデアは既存研究とどこで被りそうか
のような問いを出す。
ユーザーはその問いに答える。
その回答をCodexがまた採点する。
採点rubricは次のようにした。
| 項目 | 点 |
|---|---|
| 問題の具体性 | 20 |
| 新規性 | 20 |
| 論文への根ざし | 20 |
| 実現可能性 | 15 |
| 評価設計 | 15 |
| リスク認識 | 10 |
つまり、アイデア出しも「AIが案を出す」のではなく、「自分の案を査読される」形に寄せた。
Topic Room
Topic Roomは、特定の論文ではなく、広いトピックに対する理解度を見るための部屋だ。
たとえば、
機械学習
と入れると、Codexが中級者向けの診断問題を出す。
回答すると、
- 強い概念
- 弱い概念
- 足りない前提知識
- 次に出すべき問題方針
を返す。
論文に入る前の準備や、分野をまたいで勉強するときに使う想定。
Research Lab
Research Labは、研究アイデアや仮説を別の角度から見るための部屋だ。
ここでは、入力したアイデアに対して、Codexが次のようなレンズを返す。
- falsification tests
- weird angles
- minimal experiment
- reviewer attack
reviewer attack はかなり気に入っている。
自分のアイデアは、自分には良く見える。
でも査読者から見ると、だいたい突かれる場所がある。
- その仮定は本当に必要か
- 既存手法で十分ではないか
- 評価指標が都合よくないか
- 失敗条件を隠していないか
- 実験コストに対して貢献が弱くないか
こういう攻撃を先に受けることで、研究案を少し硬くできる。
Codex Room
一応通常の会話もCodexとできるようにしてある
Codex App Serverとの接続
Research DojoのAI処理は、codex app-server を使っている。
大まかな流れはこう。
spawn("codex", ["app-server"])
initialize
initialized
getAuthStatus
thread/start
turn/start
item/agentMessage/delta
turn/completed
Paper Card生成やレビューでは、CodexにJSON schemaを渡して、構造化された結果を返してもらう。
たとえばレビュー結果は、
- score
- rubric
- fatal issues
- missing perspectives
- next fix
- revision challenge
のような形でDBに保存する。
これにより、ただのチャットログではなく、後から集計できる学習履歴になる。
デスクトップアプリ化
最初はWebアプリとして作っていた。
ただ、Research Dojoは性質的にローカルアプリのほうが合っている。
理由は3つある。
1. 論文メモや回答はローカルに置きたい
研究メモや回答履歴は、公開サーバに置くよりローカルに置きたい。
2. Codex CLIはローカルにログインしている
Codex App Serverを使うなら、ローカルで動くほうが自然。
3. Codex Taskはローカルrepoに触る可能性がある
将来的に、研究アイデアを実装タスクに落としてCodexに渡すなら、ローカルのrepoを扱うことになる。
なので、Electronで包んでPCアプリ化した。
Next.jsのstandalone buildをElectronのresourcesに入れ、起動時にローカルサーバとして立ち上げる。
DBはアプリのuserData配下に保存する。
Macで spawn codex ENOENT になった問題
デスクトップ化したあと、Macで問題が出た。
ターミナルでは codex が使えるのに、アプリから見ると codex が見つからない。
原因は、FinderやElectronから起動したGUIアプリでは、ターミナルと同じPATHが入らないこと。
そのため、アプリ側で次の場所も探索するようにした。
/usr/local/bin/opt/homebrew/bin~/.local/bin~/.volta/bin~/Library/pnpm
さらに、Settings画面から codex login --device-auth を開始できるようにした。
ログインボタンを押すと、
- 認証URL
- ワンタイムコード
- Codex CLIの検出状態
- App ServerのJSON-RPC probe
- ログイン状態
が同じ画面に出る。
これで「ターミナルでやってください」だけではなく、アプリ内でログインフローを進められるようになった。
配布
GitHub Actionsで、タグをpushするとmacOS / Windowsのビルドを作る。
今は次を出している。
- macOS Apple Silicon DMG
- macOS Intel DMG
- Windows zip
- Windows installer
- Windows portable exe
リリースはこちら。
まだApple notarizationやWindows code signingはしていない。
なので、macOSでは初回起動時にGatekeeperの警告が出る。
現状は無料配布の範囲として、
- 一回アプリを開いて警告を出す
- システム設定
- プライバシーとセキュリティ
- このまま開く
- もう一度開く
という手順をREADMEとReleaseに書いている。
技術構成
ざっくりこう。
| 領域 | 技術 |
|---|---|
| UI | Next.js / React / Tailwind CSS |
| Desktop | Electron / electron-builder |
| AI runtime | Codex CLI / Codex App Server |
| DB | sql.js / local SQLite file |
| Release | GitHub Actions / GitHub Releases |
| Web prototype | Vercel |
作ってみて良かったところ
一番良かったのは、論文理解を「アウトプット前提」にできたこと。
要約を読むだけだと、理解したかどうかは曖昧なまま。
でも、自分で答える必要があると、曖昧さがすぐに表に出る。
そして、厳しめに採点されると、
- 自分はどの観点に弱いのか
- どの節を読み直すべきか
- 次に何を直すべきか
が見える。
これは、研究を進める上でかなり大事だと思う。
今後やりたいこと
まだやりたいことは多い。
- PDF取り込みの強化
- Zotero連携
- 論文ごとの読書履歴
- 回答履歴からの長期的な弱点プロファイル
- 研究テーマごとのカリキュラム生成
- Codex Task実行時のdiffレビューUI
- macOS notarization
- Windows code signing
特に、Codex Task周りはもっと伸ばしたい。
今は研究アイデアや実験案をタスク化するところまでだが、最終的には、
論文を読む
弱点を潰す
研究仮説にする
最小実験を作る
Codexに実装させる
結果をまたResearch Labで叩く
というループにしたい。
まとめ
Research Dojoは、論文を読んで、答えて、叩かれて、直して、実験へ進めるためのローカル研究ジムだ。AIに答えを出してもらうのではなく、自分の理解やアイデアをAIに厳しく見てもらう。
この方向は、研究とAIツールの組み合わせとしてかなり気に入っている。
リポジトリはこちら。
Discussion
バグなどがあればぜひ書いて欲しいです！
修正します！主はMacユーザなのでwindows環境でのデバックができないのでおそらくwindowsだとバグが多いのかもしれません；；