reviewing-ai-papers

AI 論文のレビュー

ユーザーが AI／ML の技術コンテンツ（論文、記事、ブログ投稿）の分析を依頼した場合は、エンタープライズ AI エンジニアリングの視点で実用的な知見を抽出し、セッションをまたいで呼び出せるよう、価値のある発見をメモリに保存します。

このスキルを使用しない場合

対象は機械学習に関するものでなければなりません。次のような、隣接するものの対象外となる依頼の場合は、以下を使用してください。

状況	使用するもの
「この文章は AI が書いたように読めますか？」	declauding
下書きの文体や語調の確認	declauding
プルリクエストや差分のレビュー	code-review
ML 以外の分野の論文	直接読んでください。このスキルの視点は適しません

依頼文に「AI」が登場することがきっかけではありません。きっかけとなるのは、AI が文書のトピックであることです。

文脈に応じた優先事項

技術アーキテクチャ:

• RAG システム（セマンティック検索／字句検索、ハイブリッド検索）
• ベクトルデータベースの最適化と埋め込み戦略
• 専門的な科学分野向けのモデルファインチューニング
• セキュアなオンプレミス展開のための知識蒸留

実装と運用:

• プロンプトエンジニアリングとインコンテキスト学習の手法
• AI システムにおけるセキュリティと知的財産の保護
• 科学的な正確性とハルシネーションの抑制
• AWS との統合（Bedrock／SageMaker）

エンタープライズと導入:

• 規制対象環境におけるエンタープライズ展開
• 科学・法務関係者との信頼関係の構築
• 社内顧客の成功を支援する戦略
• 内製か購入かを判断するフレームワーク

分析基準

• 客観性を保つ: 情報源の誇張を助長せず、事実に基づく知見を抽出します
• 新規性の主張を検証する: 実務者がすでにベースラインとして使用しているものを特定します。「既存の手法を適用している」ことと「真に新しい手法である」ことを区別します。その手順は、以下の「論文で実施されなかったアブレーション」です。実行し、独自の判断で代用しないでください
• 厳密さと新規性を分ける: 標準的な手法を適切に実行した研究は、方法論上のブレークスルーとは異なります
• 確信度を明示する: 確立された事実、新たな傾向、推測的な主張を区別します
• 文脈に応じて絞り込む: 現在の課題に対応する知見を優先します

論文が実施しなかったアブレーション

評価のどの部分を書く前にも、これを実行してください。論文自身の表から読み取れるため、コードも再実装もデータへのアクセスも必要ありません。

論文のアブレーション表には、著者が検証可能だと考えた要素が示されています。すべての行で固定されている軸は、誰も異議を唱えなかった軸です。そして、根拠のないメカニズムが査読を通過してしまうのは、その軸です。

4つの手順：

1. 論文が報告しているアブレーションをすべて列挙し、それぞれで変えている軸を示します。
2. どの行でも変えていない軸を示します。
3. その軸について、同じ出力形式を生み出す最も手軽なメカニズムを示します。つまり、論文を読んだことのない実務者が何を選ぶかを示します。
4. 論文がそれを実施したかどうかを判断します。

すべてのレビューにこのブロックを含めてください。これがないレビューは不完全です。

VARIED:               <axes the paper ablates>
HELD FIXED:           <the axis no row varies>
CHEAPEST ALTERNATIVE: <what a practitioner would use on that axis>
RAN IT:               yes | no | partially, against <what>

手順3で見落としが起きます。論文が反論の対象としている代替手法は、そのメカニズムが打ち負かすために作られたものであり、それを比較対象にすると、論文の枠組みをそのまま引き継いでしまいます。論文が選んで挙げた代替手法ではなく、実務者が使うであろう方法を基に比較対象を書いてください。

実施済み：いいえは、論文がどこまで検証したかを示すものです。それだけで手法が機能するかどうかが決まるわけではありません。欠けている比較によって何が明らかになるのか、また、それを実施するコストはいくらかを述べてください。メカニズムが手軽な代替手法に勝つ可能性はありますが、論文はまだそれを示していません。答えがはいの場合は、信頼性評価でその点を述べてください。比較を実施した論文は、実施したという点でより強い評価に値します。

事後に発見された診断例が2件あります。

• SPD/hLLM（arXiv:2609.01807、2026-09-08）。表3と表4では、スコアリングヘッド、学習シグナル、バックボーンをアブレーションしています。デコーダーを変えた行はなく、ハンガリアン法による求解が論文の貢献です。事後に測定したところ、スコア行列の1列をソートするだけで割り当ての求解と同等の結果となり、1,785個のスレートでNDCG@10の差は+0.0008［−0.0028、+0.0044］でした。論文自身の比較対象である、修正を加えた行ごとのargmaxはハンガリアン法に劣るため、論文のアブレーションはその範囲では妥当です。この発見は、その一歩先にあります。（oaustegard/experiments PR #92。）
• TTT-Embed（arXiv:2608.12569、2026-08-14）。報酬の適用範囲と報酬予算をアブレーションしています。貢献である残差クエリベクトルの取得方法を変えた行はありません。同じ対象を構成するラベル不要の方法が2つあり、どちらも報酬予算を消費しませんが、実施されていません。上位k件の検索文書に対するRocchio法と、クエリ・文書間のモダリティギャップの方向です。（Memory 7461f178。）

分析の構成

内容に実質がある場合

記事の評価（2〜3文）

• 中心的なテーマと主な主張
• 信頼性：著者の専門性、証拠の質、方法論の厳密さ

優先度別の洞察

• 高優先度：進行中のプロジェクトへの直接的な応用
• 中優先度：動向を追う価値のある関連技術
• 低優先度：興味深いものの、すぐには実行に移せない内容

技術的評価

• 新規手法と、標準的な手法を革新として提示しているものを区別する
• 実装上の課題、リスク、必要なリソースを指摘する
• 確立されたベストプラクティスとの矛盾に留意する

実行可能な推奨事項

• さらに調査する：追加調査が必要な具体的な領域
• 実装を評価する：試作する価値のある技術
• チームで共有する：この内容が役立つチーム
• 動向を追跡する：追跡すべき新たな領域

すぐに応用できること 洞察を現在のプロジェクトに結び付けます。すぐに実行できる成果や、概念実証（POC）の機会を特定します。

内容が薄い場合

• まず制約を述べる
• あれば、わずかな洞察も取り出す
• そのトピックが重要であれば、代替案を推奨する
• 簡潔にまとめる

メモリーの統合

自動保存のトリガー：

• 優先度の高い洞察（直接応用できるもの）
• プロトタイプを作成する価値のある新しい手法
• 論文を横断して認識されたパターン
• 確立された実践との矛盾

保存形式：

remember(
    "[Source: {title or url}] {condensed insight}",
    "world",
    tags=["paper-insight", "{domain}", "{technique}"],
    conf=0.85  # higher for strong evidence
)

圧縮ルール：

• 詳細な分析 → 会話（ユーザーに表示される内容）
• 要約した洞察 → メモリー（出典情報付きの検索可能な要点）
• 分析全体ではなく、実践に役立つ核心を保存する

例：

分析：「ハイブリッド検索（BM25 + dense）は、科学分野のクエリにおいて純粋なセマンティック検索より23%向上します。2段階のアプローチ……」

保存内容："[Source: arxiv.org/abs/2401.xxxxx] ハイブリッドBM25+dense検索：科学分野のコーパスでセマンティック検索のみの場合より23%向上。ファインチューニングの効果を得るには、ドメイン固有の例が1万件以上必要。"

タグ：["paper-insight", "rag", "hybrid-retrieval", "scientific-domain"]

出力基準

• 簡潔さ：内容の言い換えではなく、実践に役立つ洞察を示す
• 正確さ：「実証している」「示唆している」「主張している」「推測している」を区別する
• 関連性：注力分野との関連を示すか、関連がないことを明記する
• 深さの調整：内容の価値に応じて長さを調整する

制約

• 誇張を助長しない
• 求められない限り、時系列を示さない
• 記事の範囲を超えて推測しない
• 矛盾は明示する
• 内容が乏しい場合は、その限界を明記する