neuroarxiv

NeuroArxiv

バイブコーダーが何時間も無駄にするのは、スキルが足りないからではありません。難しい部分がすでに解決され、既知の失敗モードとともに公開されていないかを確認する前に、作り始めてしまうからです。arXiv は「これを誰かがすでにやったか」を調べるための世界最大の情報源ですが、コードを書こうとしている人のほとんどは、実際にまず読みません。このスキルを使うと、エージェントがまず arXiv を読みます。

事前確認（Phase 1 の前に実行）

このスキルはコストがかかります。実際の arXiv 検索に加え、論文ごとにおよそ 1 回の分離された Agent 呼び出し（通常 10～20 回）、さらにスコアリング、クラスタリング、収束が必要です。調べるべき先行研究が本当にない場合は、このコストをかけないでください。

Step 1. 明示的な呼び出しか確認します。

ユーザーが /neuroarxiv と入力した場合、または「arXiv を調べて」「先行研究を調べて」「NeuroArxiv を実行して」と明示的に依頼した場合は、このセクションの残りをスキップし、Phase 1 に進んでください。ユーザーは実行を選択しています。

Step 2. 自己判断します（Step 1 に該当しない場合のみ）。

次の 3 つの質問を自分に問いかけてください。どれか 1 つでも答えが「いいえ」なら、中止してください。

1. 調査すべき技術的な仕組みがありますか？ 変数の命名、CRUD フォームの配線、ドキュメント化された 2 つの SDK の接続には、調べる価値のある先行研究の問いはありません。一方、キャッシュ戦略、合意形成／調整方式、ランキングや検索手法、ML の学習または推論技術、新しいプロトコル、「単純な実装では規模が大きくなると破綻する」ようなものは対象になります。
2. ユーザーはこれに本格的な労力を投入しようとしていますか？ 一度きりのスクリプトでは、文献調査を行う価値はありません。アーキテクチャの中核となるコンポーネントや、誤った方法で構築すると後から作り直すコストが高いものなら、調査する価値があります。
3. ユーザーはアプローチを未決定のままにしていますか？ 使う特定のアルゴリズム、論文、ライブラリをすでに指定している場合や、「単純な方法で実装して」と言っている場合は、すでに方向性が定まっています。再検討しないでください。中止してください。

3 つの条件をすべて満たす場合は、Phase 1 に進んでください。

どれか 1 つでも満たさない場合は、中止し、直接実装に進んでください。必要に応じて、次の一文を追加できます。「arXiv の先行研究と照らし合わせてから進める場合は、/neuroarxiv <your problem> を実行してください。」

ループ

3 つのフェーズで構成されています。検索は発散ではありません。実際の文献を見つけ、それぞれを個別に読んでから、結論を出します。個別に読む手順を省くと、実際には読んでいない論文について LLM が推測するだけになってしまいます。

Phase 0 — 分類する

構築上の問題を、arXiv のサブジェクトカテゴリ 3〜5 個と、具体的な検索語 3〜6 個（技術的な仕組みを示す語。「キャッシュシステム」ではなく「キャッシュの無効化」）に対応付けます。以下の表から選ぶか、確信がある場合は別のカテゴリ ID を指定してください。

カテゴリ	対象
cs.AI	一般的な AI システム、エージェント、計画、知識表現
cs.LG	学習アルゴリズム、トレーニング手法、モデルアーキテクチャ
cs.CL	NLP、言語モデル、テキスト処理
cs.CV	画像・動画の理解、生成、認識
cs.IR	検索、ランキング、推薦、検索拡張システム
cs.DC	分散システム、コンセンサス、シャーディング、レプリケーション、スケジューリング
cs.DB	ストレージエンジン、クエリ処理、インデックス作成、トランザクション、一貫性
cs.SE	開発手法、テスト、プログラム解析、ツール
cs.PL	言語設計、型システム、コンパイラー、ランタイム
cs.CR	プロトコル、認証、敵対的ロバスト性、プライバシー
cs.NI	ルーティング、輻輳制御、エッジ/CDN
cs.OS	カーネル、スケジューラー、メモリ管理、仮想化
cs.HC	インターフェース設計、ユーザビリティ、インタラクションモデル
cs.MA	エージェント間の協調、交渉、創発的な振る舞い
cs.RO	制御、認識、操作、動作計画
cs.DS	アルゴリズム技法、計算量、データ構造設計
cs.GT	メカニズムデザイン、オークション、インセンティブ適合システム
stat.ML	統計的学習理論、確率モデル
eess.SP / eess.SY	信号処理 / 制御理論
math.OC	最適化、スケジューリング、リソース割り当て

明らかな技術的仕組みがなく、純粋に製品・ビジネスの観点から捉えた問題であれば、その旨を明言してください。ただし、最善を尽くして技術的な切り口も提示してください。構築上の問題のほとんどには、表現されていなくても、技術的な仕組み（キャッシュ、一貫性、ランキング、スケジューリング、検索など）が関係しています。

Phase 1 — 取得（実際の HTTP リクエスト。生成は禁止）

選択した各カテゴリについて、arXiv の実際のエクスポート API に対して WebFetch を呼び出してください。この手順を記憶から言い換えるのではなく、実際に取得してください。

https://export.arxiv.org/api/query?search_query=cat:<CATEGORY>+AND+(all:"<term1>"+OR+all:"<term2>")&start=0&max_results=4&sortBy=relevance&sortOrder=descending

各 <entry> について、arXiv ID、タイトル、要旨、著者、公開日、abs / pdf リンクを、要約せず、フィードから一字一句そのまま返すよう WebFetch に指示してください。これは実際の Atom XML フィードです。各フィールドを事実として扱い、レスポンスにない論文、ID、詳細を決して捏造しないでください。

カテゴリの結果が 2 件未満の場合は、そのカテゴリのクエリから検索語を除いて再試行してください（cat:<CATEGORY> のみを指定します）。目標件数に達するために、関連性のない結果を追加してはいけません。結果が全体的に乏しい場合は、調査結果を捏造せず、その旨を出力してください。

お願い： arXiv は、数秒間隔で一度に 1 件ずつリクエストを送信するよう求めています。カテゴリは並行ではなく、順番に取得してください。

フェーズ 2 — 発散（論文を1本ずつ個別に読む）

フェーズ 1 で収集した論文ごとに、並列で Agent/Task 呼び出しを起動します。論文1本につき1回です。各 Agent に渡すのは次の情報だけです。

• 構築する対象の問題
• その1本の論文のタイトル、要旨、著者、出版年 — ほかの論文は渡しません
• 以下の指示

あなたは「発散的読解」モードです。手元にあるのは、論文1本のタイトルと要旨、および構築する対象の問題だけです。ほかにどのような論文があるかは知りません。より広範な調査を想定したり、でっち上げたり、ほのめかしたりしないでください。 これから対象のものをゼロから構築する人のために先行研究を探すつもりで、この要旨を読んでください。連続する数語を超えて要旨をそのまま引用せず、自分の言葉で言い換えてください。 次の項目を抽出してください。approach（1〜2文、核となる仕組み）、borrow（1文、実装可能な最も具体的な要点を1つ。命令形で「Yを行うにはXを使う」とします。関連性が低すぎる場合は、そう明言します）、limitation（1文、根本的な弱点または機能しなくなる条件）、relevanceNote（対象の問題との適合性に関する短い句を1つ）。 JSON のみを出力してください：{"approach":"...","borrow":"...","limitation":"...","relevanceNote":"..."}

重要な不変条件。 これらの呼び出しは並列かつ互いに隔離して実行する必要があります。ほかの論文の要旨を読んだ状態で読むと、目の前の1本の論文に基づくのではなく、論文全体の要約を始めてしまいます。これは ADHD のクロストークによる破綻よりも見つけにくい微妙な失敗であり、出力が依然として論文ごとの内容に見えるため、見過ごされやすい問題です。

フェーズ 3 — 収束（候補一覧ではなく、1つの道筋を選ぶ）

すべての読解結果がそろったら、次の手順を実行します。

1. 評価する。 各読解結果を、関連性（対象の問題との適合度）、実用性（特殊なインフラなしに小規模チームで構築できるか）、厳密性（要旨自体に、ベンチマーク、証明、リリース済みシステムといった実証が示されているか、単なる概念にとどまるか）の各項目について、0〜10 点で評価します。論文自身が記した制限から、構築者が苦労して初めて気づくであろう失敗モードが示唆される場合は、「落とし穴」としてフラグを付けます。その場合は必ず「強み」も併記します。その論文のアプローチが具体的にうまくできている点を1つ挙げてください。
2. クラスタリングする。 論文別でもキーワード別でもなく、根底にあるアーキテクチャ上の方向性に基づいて、読解結果を3〜6個のクラスタに分類します。「キャッシュ無効化の手法」「コンセンサス不要の手法」「学習型インデックスの手法」などです。
3. 1つを選ぶ。 関連性と実用性の組み合わせが最も優れているクラスタを選びます。最も目新しいものでも、最も引用されたものでもなく、エンジニアが実際に構築すべきものを選んでください。これは自由な発想を広げる段階から一歩踏み出す地点です。NeuroArxiv は単一の推奨案に絞ります。「論文を4本挙げるので、あとは自分で決めてください」では、まさにこのスキルが防ごうとしている時間の浪費になります。
4. 統合する。 選んだクラスタについて、以下を提示します。4〜8文の実装案（実行可能な内容とし、文献レビューの要約にはしません）、引用（論文 ID、タイトル、URL、役割 — 「主要な仕組み」「裏付けとなる証拠」「避けるべき失敗モード」— 取得したデータのみに基づく）、最初の具体的な手順、根本的なリスク、そしてすべての論文の制限から抽出した「避けること」のリスト（選ばれた論文だけではありません。不採用のクラスタの論文が挙げた落とし穴も、避ける価値があります）。
5. 次点を示す。 選ばれなかった各クラスタについて、選ばなかった実際のトレードオフを、率直な1文で述べます。切り捨てるのではなく、構築者が後から道筋を切り替える場合に、その理由がわかるようにしてください。
6. 未解決の問いを1つ挙げる。 読んだ論文が提起しているものの、答えていない問いを挙げます。リリース前の設計レビューで確認する価値がある問いです。

出力形式

1. 検索内容。 カテゴリ、検索語、論文数。
2. 読んだ論文。 クラスターごとにグループ化します。各論文について、ID、タイトル、アプローチを1行で示し、スコアチップ [rel8 prac6 rig7] を付けます。
3. 先行研究から学ぶ落とし穴。 制約が実際の落とし穴を示している論文を、結論ではなく注意点として別に列挙します。
4. THE PATH。 選んだ1つのクラスター：概要、引用、最初のステップ、最も重大なリスク、回避リスト。これが成果物です。論文リストの下に埋もれないよう、太字で目立たせてください。
5. 検討したが選ばなかった代替案。 それぞれ1行。
6. 未解決の論点。 未回答の質問。

アンチパターン

• 相互に汚染された読み込み。 論文の読み込みに「ここにある他の論文と比較して」や「これらを総合すると」といった記述がある場合は、独立性が失われています。その読み込みを破棄し、単独で再実行してください。
• 引用の捏造。 実際に取得した要旨に記載されていない論文の詳細（数値、主張、結果など）は、決して述べないでください。確信がなければ、タイトルから推測せず、再取得してください。
• 候補リストでの逃げ。 「有力な選択肢を3つ紹介します」としてフェーズ3を終えるのは、1つの推奨案を示す目的に反します。決断してください。
• 少ない検索結果の水増し。 関連論文がゼロ件または少数件なのは、有効な発見です。仕組みが本当に新しいか、検索語が適切でなかったことを意味します。そのように述べてください。網羅性を装うために、関連の薄い論文を無理に含めないでください。
• 論文の要旨を論文全体として扱う。 要旨は手がかりであり、記載されていない実装の詳細を裏付ける根拠ではありません。「取り入れる点」と「避ける点」は、要旨が実際に裏付ける範囲にとどめてください。

目安

• 論文は何件か。 既定では、カテゴリごとに4件 × 3〜5カテゴリ ≈ 12〜20件です。対象が狭い、またはよく知られた仕組みの場合は減らし（範囲が狭ければカテゴリごとに2件で十分です）、本当に不明確な領域では増やしてください。
• 検索範囲を広げるのはいつまでか。 カテゴリに絞って再試行し（検索語を外しても）使える結果が得られない場合は、その旨を伝えて次に進んでください。件数を増やすために無関係なカテゴリまで広げないでください。

コスト

1回の分類 + N回の独立した読み込み（通常12〜20回）+ 1回のスコア付け + 1回のクラスター化 + 1回の収束 ≈ N+4回のエージェント形式の呼び出しに加え、実際の arXiv HTTP 取得（カテゴリ間に約3秒の待機時間を設けます）が必要です。すべての設計判断に使うのではなく、アーキテクチャを誤ると大きな手戻りが発生する判断に使ってください。

コンパニオンライブラリと CLI

このリポジトリには、実際の arXiv HTTP と Claude Agent SDK に対して同じループを実行する Node/TS 実装（src/）も含まれています。Claude Code の外部での利用、スクリプト化／バッチ実行、または WebFetch 呼び出しの代わりに取得と解析を決定的なコードで行いたい場合に便利です。

npm install
npm run build
neuroarxiv "how should I cache LLM completions across requests?"

上記のスキルを使えば、インストール不要で Claude Code 内で同じループを実行できます。