AIがコードを書く前に調べる理由

AIがコードを書く前に「論文を読む」とはどういうことか

コード生成の速さに慣れると、つい見落とす問題がある。AIは既知の情報を組み合わせるのは得意だが、「その実装が本当に正しいか」を自ら検証しながら書くわけではない。ここにResearch-Driven Agentsという発想が食い込んでくる。

Research-Driven Agents: When an agent reads before it codesが示した実験は、構造はシンプルだが示唆は鋭い。エージェントにllama.cppの最適化を任せる際、コードを書く前に文献調査フェーズ（autoresearch/pi-autoresearchループ）を挟む。対象はTinyLlama 1.1B（Q4_0量子化）のCPU推論スループットで、ベンチマークはllama-benchを-p 512 -n 128 -t 8 -r 5で実行し、プロンプト処理（pp）とテキスト生成（tg）のtokens/secondを測定する設計だ。

結果として、約3時間・総コスト約$29で5件の最適化候補が生成された。VMはAWS c6i.2xlarge（Intel Xeon Ice Lake、AVX-512）を4台使い、後にARM系のc7g.2xlarge（Graviton3、NEON）を追加して移植性も確認している。コスト内訳はCPU VMで$20、API呼び出しで$9。研究者が週単位でこなす作業を、エージェントが数時間で終わらせた計算になる。

実験の中身：エージェントは何を「読んで」何を「書いた」のか

生成された最適化のうち実際に効いたものを見ると、いずれも「複数パスを1パスに融合する」という方向性を持つ。

Softmax fusionとRMS norm fusion

flash attentionのQK tileに対するコピー→スケール→マスク加算という3パス処理を、wp[i]=sp[i]*scale+mp_f32[i]を1ループで計算するAVX2 FMAループに融合した。RMS normも同様で、memcpyとggml_vec_scale_f32の2パスをy[i]=x[i]*scaleの1パスに置き換えている。地味に見えて、CPUのメモリ帯域を直撃する改善だ。

Adaptive from_float parallelization

プロンプト処理（行数が多い）とテキスト生成（行数が少ない）で分割戦略を切り替える適応的な並列化だ。行数が多い場合は行単位、少ない場合は要素単位で分割する。同一VMでのA/B比較（flash attentionなし）では、ppがベースライン210.65から215.97へ（+2.5%）、tgが48.90から49.33へ（+0.9%）改善した。

既存研究の発見と実験管理

注目すべきは、エージェントが既存の研究成果も発見している点だ。ik_llama.cppのrow-interleaved quantization repackingはPPを2.9倍改善し、Q4_0_8x8 repack形式としてすでにmainlineのllama.cppにアップストリームされていた。エージェントは「すでに解かれた問題」と「まだ解かれていない問題」を区別しながら実験を設計した。

実験の管理はexperiment.yamlテンプレートで行い、SkyPilotが各VMへのビルド・ベンチマーク・正しさチェック・メトリクス報告を分散実行した。sky logsで結果を確認し、勝者をコミットして次の波をキューに追加するサイクルは、CIパイプラインに近い構造を持つ。

コンテキストをどこに持つか：DisCEdgeが解こうとしている問題

Research-Driven Agentsが「書く前の設計」を変えるなら、DisCEdgeは「動かしながらの状態管理」を変えようとしている。出発点はシンプルだ。LLMはステートレス（状態を持たない）なので、会話の文脈やユーザーの好みはどこかに保存しなければならない。

クラウド集中型なら問題は小さい。しかしエッジノードに分散してLLMを動かすと、「どのノードにリクエストが来ても同じ文脈を参照できるか」という問題が生じる。既存の解決策はクライアント側でコンテキストを持つことだったが、これはリクエストのたびに大量のトークン列を送り返すことを意味する。ネットワーク帯域を食い、せっかくのエッジ配置による低遅延効果を打ち消す。

DisCEdge（EuroMLSys '26採択、arXiv初回投稿2025年11月27日）はコンテキストをトークン列のままエッジノード側に保存・複製する設計を採る。クライアントの送信データを中央値で90%削減し、応答時間の中央値を最大14.46%改善、ノード間の同期コストを最大15%低下させるという結果が、実際のエッジ環境でのオープンソースプロトタイプ評価から得られた。

「トークン列のまま保存する」という設計が鍵だ。テキストに戻してから再度トークン化するような二重変換を省き、ノード間でそのまま複製できる。データの整合性保証も設計に含まれており、「どのノードに当たっても同じ答えが返る」という分散環境の要件を満たす。

Claude Code/Cursor時代の開発フローに何が変わるか

この2つの研究が示すベクトルは、一本の線でつながる。

Research-Driven Agentsが証明したのは、「AIに実装を任せる前に、既存知識を体系的に調査させるステップを明示的に設計すること」の有効性だ。Claude CodeやCursorを使う開発者が今やっている「プロンプトを工夫して精度を上げる」という努力は、エージェントのワークフロー設計にシフトしていく。どんなドキュメントを読ませるか、どんな検証ループを組むか、実験をどう並列化するか——問われる場所が変わる。

エージェントはベンチマークスクリプト（autoresearch.sh）と正しさチェック（autoresearch.checks.sh）を作成し、SkyPilotでクラウドVMに実験を分散させた。各実験は個別のVMで行われ、ビルド、ベンチマーク、正しさチェック、メトリクス報告を実施した。

一方DisCEdgeが示すのは、AIエージェントが複数ノードをまたいで動作する場面での「コンテキスト管理のコスト」だ。単一のClaude Codeセッションなら問題は顕在化しない。しかし複数のエージェントが並列に動き、ユーザーの状態を共有しながら協調するシステムを設計するとき、コンテキストをどこに持ち、どう同期するかは設計上の重要な決定点になる。

「調べてから書く」ワークフロー設計と「コンテキストをどこに置くか」という基盤設計の両方が整って初めて、AI駆動開発は再現性のある生産フローになる。どちらか一方だけでは、精度か速度かのトレードオフに留まる。

まとめ

Research-Driven Agentsは$29・3時間という具体的なコストで、「文献を読んでから実装する」サイクルの実現可能性を示した。DisCEdgeはエッジ分散環境でのコンテキスト管理コストを定量化し、設計の選択肢を広げた。AI駆動開発を「使ってみる」から「設計する」段階に進めるなら、まずワークフローに調査フェーズを組み込むこと、そしてコンテキストの置き場所を意識すること——この2点が現実的な出発点になる。