『株式会社ずんだもん技術室AI放送局 podcast 20260226』のカバーアート

株式会社ずんだもん技術室AI放送局 podcast 20260226

株式会社ずんだもん技術室AI放送局 podcast 20260226

無料で聴く

ポッドキャストの詳細を見る

概要

 youtube版(スライド付き) 関連リンク ClaudeはなぜRAGを捨てたのか？コード生成における「エージェント型検索」の優位性 LLM（大規模言語モデル）に特定の知識を与える手法として、現在は「RAG（検索拡張生成）」が主流です。しかし、Claudeの開発元であるAnthropic社は、コード生成の領域においてRAGから「エージェント型検索（Agentic Search）」へと舵を切りました。本記事では、その背景にある技術的な理由とメリット・デメリットを解説しています。 1. エージェント型検索とは何か？ 従来のRAGは、事前にドキュメントをベクトル化（インデックス化）して保存し、LLMが関連しそうな情報を「受動的」に受け取る仕組みでした。 対して「エージェント型検索」は、AIエージェント自身にgrepやglobといった標準的な検索ツールを渡します。AIは「この機能の実装箇所を探そう」といった仮説を立て、必要な情報が見つかるまで自律的に検索と読み込みを繰り返します。いわば、AIがエンジニアのように「自分でリポジトリを歩き回る」手法です。 2. Anthropicがエージェント型検索を選んだ3つの理由 圧倒的なパフォーマンスと「使用感」： ベンチマーク上の数値だけでなく、実際に使った際の「直感的な精度の高さ（Vibes）」が劇的に向上しました。「情報の鮮度」問題（Code Drift）の解消： コードは頻繁に更新されるため、RAG用のインデックスはすぐに陳腐化します。エージェント型検索は「現在の生のコード」を直接読みに行くため、常に最新の状態を反映できます。セキュリティとリスクの低減： 外部のベクトルデータベースに機密データを複製して保存する必要がなく、既存の安全な環境内のツールを利用するだけで済むため、情報漏洩リスクを抑えられます。 3. トレードオフ（代償） この手法は万能ではありません。AIが何度も検索試行を繰り返すため、RAGと比較して「応答の遅延（レイテンシ）」が大きく、また「消費トークン量（コスト）」も跳ね上がります。しかし、Anthropicは「精度とセキュリティのメリットは、コストを支払う価値が十分にある」と結論づけています。 まとめ AIアプリケーションの設計は、「静的なデータを検索する」形から、「AIエージェントが動的に探索する」形へとパラダイムシフトが起きています。特に情報の鮮度が重要なソフトウェア開発において、この「エージェント型検索」は今後のスタンダードなアーキテクチャになる可能性があります。新人エンジニアの皆さんも、単にRAGを組むだけでなく、AIに「道具（ツール）」を使わせて自律的に動かすという考え方に注目してみると、より高度なAI活用ができるようになるでしょう。 引用元: https://zenn.dev/manntera/articles/f3017ecba9c9c1 #2｜スラッシュコマンドで回す開発 — プロセスを分解してAIに割り当てる 本記事は、AIを開発プロセスに本格的に組み込む「AI駆動開発」の第2段階（Phase 2：Hybrid Co-Driving）における具体的な設計思想と実践方法を解説したものです。新人エンジニアの方にとっても、将来的にAIを良きパートナーとして使いこなすための道標となる内容です。 1. 「人間が運転し、AIが実行する」分業モデル Phase 2では、人間が「運転席」に座り、意思決定と品質判断を担います。一方で、具体的な作業の実行はAIに任せます。この分業をスムーズにするために導入されたのが「スラッシュコマンド」という概念です。 これまでエンジニアが手作業で行っていた「ブランチ作成」「コードレビュー」「プルリクエスト（PR）作成」といった定型作業を、/branch-create や /code-review といったコマンドとして定義し、AIに実行を依頼するスタイルをとります。 2. プロセスの細分化と設計原則 AIに指示を出す際、「設計して」といった大きな粒度で投げると精度が安定しません。そこで重要なのが、業務プロセスを「入力・処理・出力」が明確なサブプロセスにまで分解することです。 コマンド設計においては、以下の2つの原則が挙げられています。 単一責任の原則（UNIX哲学）: 1つのコマンドには1つの責務だけを持たせます。複数の役割を詰め込むとAIが混乱し、品質が低下するためです。パイプライン化: 小...
まだレビューはありません