背景
最近、Software Engineeringの現場で生成AIを使っていて、少し気になっていることがあります。
公開論文や公式ドキュメントで新しい手法を見つけても、実際のアプリケーションで試すまでには、意外と時間がかかります。
従来であれば、まず次のようなものを探していたと思います。
- 誰かが公開したGitHub Repository
- 既存のOSS Package
- FrameworkのPlugin
- 実装方法を紹介したBlog
- 利用しているProgramming Language向けのSample Code
もちろん、既存実装を使うこと自体は悪くありません。
十分に利用されていて、保守されていて、LicenseやSecurity上の問題がなければ、自分たちで実装するより合理的な場合も多いです。
一方で、公開論文にはアルゴリズムや評価方法が書かれているのに、利用している言語向けのPackageが存在しないため、検証を先送りすることもあります。
正直、ここには少し違和感があります。
現在のCoding Agentは、論文、公式仕様、既存コード、Software EngineeringのBest Practiceを同時に読み、対象アプリケーションに合わせた最小実装を作成できます。
つまり、状況によっては、
「誰かが実装してPackageとして公開するのを待つ」必要が減る可能性があります。
公開されている論文やBest Practiceに、アルゴリズム、入出力、制約、評価方法が十分に記載されていれば、Coding Agentを使って、現在のProgramming Languageと既存設計に合わせたMockを比較的早く作れるためです。
これは、他の人が開発したものを使わなくなる、という話ではありません。
他人の実装を採用する以外に、自分たちの要件に合わせて小さく実装し、先に価値を測定する選択肢を持てるようになる、という話です。
今回、題材として取り上げるのは、AI Agentにおける「Search Tool」です。
AI Agentへ登録するToolやSkillが増えると、Tool定義だけでContextを大きく消費するようになります。また、似たToolが増えることで、Agentが適切なToolを選びにくくなる場合があります。
そこで、すべてのToolを最初からLLMへ渡すのではなく、ユーザーの要求に関連するToolだけを検索し、その定義を遅延ロードする方式が出てきています。
Anthropicの公式ドキュメントでは、RegexまたはBM25を利用したTool検索と、Tool定義のDeferred Loadingが提供されています。必要なToolが検索された時点で、その完全な定義がContextへ展開される仕組みです。
ただし、今回の記事で重要なのはSearch Toolそのものではありません。
Search Toolを例として、
公開論文やBest Practiceを調査し、価値を測り、既存アプリケーションへ安全に組み込むまでを、どのようなPromptに分割するか
を整理します。
注意点 / 前提
最初に、前提を書いておきます。
この記事は、私がCoding AgentをSoftware Engineeringの作業へ組み込む際の考え方を整理したものです。
すべてのプロジェクトへ、そのまま適用できる方法ではありません。
アプリケーションの規模、組織のReview Process、Security要件、利用しているAI Agent、Programming Languageによって、現実的な進め方は変わります。
また、論文からコードを生成できることと、そのコードをProductionへ投入できることは同じではありません。
論文では、次の要素が省略されていることがあります。
- 障害時の動作
- Security
- AuthenticationとAuthorization
- Error handling
- Observability
- Data migration
- Backward compatibility
- 実運用時のPerformance
- License
- 長期的な保守性
したがって、本記事で扱う「即座に実装できる」とは、
論文や公式資料から、検証可能な最小実装やMockを作り、導入価値の測定を始められる
という意味です。
論文を読んだ直後に、無条件でProductionへReleaseできるという意味ではありません。
また、既存Packageの利用を否定する意図もありません。
実務では、次の比較が必要です。
- 既存Packageを利用する
- AI PlatformのNative機能を利用する
- 既存アプリケーションの機構を拡張する
- 論文や仕様から必要最小限を自作する
- 現時点では導入しない
重要なのは、既存Packageが存在するかどうかだけで、技術の検証可否を決めないことです。
公開されている知識を、現在のコードベースで検証可能な形へ変換できるか
を、まず確認します。
なお、以下に掲載するPrompt部分は、コピーアンドペーストできるようにしています。
Search Toolを題材にしていますが、Prompt自体は、Cache、Authentication、Observability、Database、Search、Queue、AI Agentなど、一般的な機能追加へ転用できる構造です。
整理・考え方
ここで一度、整理してみます。
何が変わったのか
従来、公開論文から実装するには、少なくとも次の作業が必要でした。
- 論文を読む
- アルゴリズムを理解する
- 疑似コードを作る
- 利用する言語へ変換する
- 既存アプリケーションの拡張点を調べる
- Packageを調査する
- Mockを実装する
- 評価データを作る
- Baselineと比較する
- Production向けの設計へ変換する
この中には、かなり時間のかかる作業があります。
特に、論文上の概念と、現在のアプリケーションの実装を対応付ける作業は簡単ではありません。
Coding Agentを使うと、この作業を完全に無くせるわけではありません。
ただし、次の作業はかなり進めやすくなります。
- 論文と公式ドキュメントの横断調査
- アルゴリズムの疑似コード化
- 現在の言語への変換
- 既存コード内の類似機能調査
- 最小のMock作成
- Benchmark作成
- 実装Taskへの分解
- Review観点の生成
- 実装後のRegression確認
ここで重要なのは、Coding Agentに最初から「実装してください」と頼まないことです。
いきなり実装を依頼すると、Agentが最初に見つけたPackageを導入したり、既存コードに似た機能があるにもかかわらず、新しい実装を追加したりする可能性があります。
また、「論文で良い結果が出ている」という理由だけで、現在のアプリケーションにも効果があると判断する可能性があります。
そこで、作業を次の5段階に分けます。
- 対象機能の調査
- 効果測定
- 詳細な実装プランの作成
- 設計プランの敵対的レビュー
- Task単位の実行
この分割で意識しているのは、次の3つです。
調査と実装を分ける
調査中はコードを変更しません。
先にコードを書き始めると、その実装を正当化する方向へ調査結果が偏る可能性があるためです。
外部の結果と自分たちの結果を分ける
論文やVendorのBenchmarkは、導入を検討する根拠にはなります。
しかし、現在のアプリケーションでの効果を保証するものではありません。
Search Toolを例にすると、Tool定義のContext量は減っても、検索処理や追加のAgent turnにより、End-to-end latencyが増える可能性があります。
また、Tool retrievalの品質が低い場合、必要なToolがCandidateへ含まれず、最終的なタスク成功率が下がる可能性があります。ToolRetの研究でも、一般的な情報検索で強いRetrieverが、Tool retrievalでは十分な性能を出さず、その検索品質がAgentのTask pass rateへ影響する結果が報告されています。
そのため、Context量、検索Recall、Tool Selection、最終タスク成功率、Latencyを分けて測定します。
MockとProduction実装を分ける
Mockの目的は、対象機能に価値があるかを安価に測ることです。
Production向けのFrameworkや抽象化を先に作る必要はありません。
Regexや単純なScore計算で仮説を検証できるなら、最初はそれで十分です。
ここに、公開論文やBest Practiceから直接実装する価値があります。
既存Packageを探して導入する前に、論文や仕様から最小のCandidateを作り、実際のアプリケーションデータで効果を測れます。
その結果、価値がなければ導入しません。
価値がある場合だけ、Native機能、OSS Package、自作のどれを採用するか比較できます。
他人の実装への依存を最初から前提にしないことで、技術選択の順番を変えられます。
本文
Prompt全体で使用する変数
以下のPromptでは、対象機能を変数として指定します。
<FEATURE_NAME> 導入を検討する機能
<FEATURE_DESCRIPTION> 機能の定義
<BUSINESS_GOAL> 解決したいビジネス上または運用上の問題
<QUALITY_GOALS> 性能、精度、信頼性などの品質目標
<REPOSITORY_ROOT> リポジトリのルート
<REPORT_PATH> 調査レポートの保存先
<EXPERIMENT_PATH> 検証コードと測定結果の保存先
<PLAN_PATH> 実装プランの保存先
Search Toolの場合は、例えば次の値を設定します。
<FEATURE_NAME>
Search Tool
<FEATURE_DESCRIPTION>
ユーザー要求に関連するToolまたはSkillを検索し、
必要な定義だけをLLMのContextへロードする機能
<BUSINESS_GOAL>
Agentの利用コストと応答待ち時間を抑えながら、
Tool数を増やせる状態を作る
<QUALITY_GOALS>
Contextサイズ削減、応答速度改善、Tool Selection精度維持または改善
この変数化には理由があります。
Promptを特定の技術名へ固定すると、次の機能を調査するときにPrompt全体を書き直す必要があります。
一方、機能名、ビジネス目的、品質目標、成果物の保存先を変数として分けておけば、同じ流れを別の機能へ適用できます。
ただし、Promptを共通化しすぎると、対象システム固有の制約が消えてしまいます。
そのため、共通化するのは作業手順であり、調査項目や成功条件は対象機能ごとに設定します。
Step 1：対象機能の調査
最初のStepでは、実装を許可しません。
ここで確認したいのは、主に次の2点です。
- 本当に解決すべき問題があるか
- 既存アプリケーションに、すでに似た機能がないか
新しい技術を見つけると、どうしても導入する方向で考えやすくなります。
しかし、実務では話が変わることが多いです。
例えば、Search Toolに似た仕組みが、すでに次の名前で実装されているかもしれません。
- Tool Router
- Capability Registry
- Dynamic Tool Loader
- Function Filter
- MCP Tool Selector
- Skill Resolver
名称だけを検索しても見つからないことがあります。
そのためPromptでは、コード上の処理経路まで確認するようにしています。
また、外部情報については、Vendorの公式ドキュメント、原著論文、標準化団体の資料を優先します。
公開論文やBest Practiceを、単なる参考資料として読むのではなく、
実装可能な仕様、制約、評価方法を抽出するための入力データ
として扱います。
Promptサンプル
あなたは、既存アプリケーションへの機能追加を調査する
Senior Software Engineerです。
## 対象
- 機能名: <FEATURE_NAME>
- 機能の定義: <FEATURE_DESCRIPTION>
- ビジネス上の目的: <BUSINESS_GOAL>
- リポジトリ: <REPOSITORY_ROOT>
- レポート保存先: <REPORT_PATH>
## 目的
対象機能を実装する前に、次の2点を明らかにしてください。
1. 対象機能に、導入コストを上回る効果が期待できるか
2. 既存アプリケーションに同一または類似機能が存在しないか
このステップでは、ソースコード、設定、依存関係を変更しないでください。
## 1. リポジトリ調査
最初にリポジトリを調査し、次を特定してください。
- 使用言語とRuntimeのバージョン
- Frameworkと主要ライブラリ
- パッケージマネージャー
- 対象機能に関係する処理のEntry Point
- 関連するインターフェース、クラス、関数、設定
- 既存の類似機能
- 対象機能を挿入できる拡張点
- 関連するテスト
- 関連するログ、メトリクス、Telemetry
- 認証、認可、個人情報、機密情報への影響
- 現時点で測定可能なBaseline
単純なキーワード検索だけで判断せず、
入力から出力までの処理経路を追跡してください。
類似機能を発見した場合は、次を記録してください。
- ファイルパス
- Symbol名
- コード位置
- 現在の責務
- 対象機能との共通点
- 不足している点
- 既存実装の拡張で対応できる可能性
発見できなかった場合は、
「存在しない」ではなく「調査範囲では確認できなかった」
と記載してください。
## 2. 外部調査
Web検索を使用し、次の優先順位で情報を調査してください。
1. 公式仕様、公式ドキュメント
2. 原著論文または著者公開論文
3. 標準化団体、公的機関の文書
4. FrameworkまたはPackageの公式文書
5. 信頼できる技術記事
まとめ記事だけを主要な根拠にしないでください。
各情報について、次を記録してください。
- 文書名
- 発行元
- 公開日または更新日
- 確認日
- URL
- 情報源の種類
- 情報源が直接述べている内容
- 適用条件
- 制約
- 反対証拠
- 現在のアプリケーションへ適用できるか
- 事実、情報源の主張、推論の区分
ベンダーが公表したBenchmarkは、
独立した研究結果として扱わないでください。
## 3. ビジネス効果
効果候補を次の形式で整理してください。
| 効果候補 | 効果が生じる仕組み | 測定指標 | 適用条件 | 負の影響 | 根拠 |
|---|---|---|---|---|---|
売上増加や工数削減など、因果関係を確認できない効果を
確定事項として記載しないでください。
## 4. 技術的実現可能性
次を調査してください。
- 利用中のPlatformまたはSDKが提供するネイティブ機能
- 現在の言語で利用できるPackage
- 既存依存関係で実現できる方法
- 小規模な自作で実現できる方法
- 新しい依存関係の必要性
- License
- 保守状況
- 既知の制約
- Vendor lock-in
- セキュリティ上の影響
- 運用上の影響
## 5. レポート構成
<REPORT_PATH>に、次の構成で保存してください。
1. Executive Summary
2. 対象機能の定義
3. ビジネス上の目的
4. 現在のアプリケーション構成
5. 既存の類似実装
6. 外部調査
7. 期待できる効果
8. 負の影響とリスク
9. 技術的な実現方式
10. 候補Packageまたはネイティブ機能
11. セキュリティ上の考慮事項
12. 検証すべき仮説
13. 未確認事項
14. 参考文献
## 捏造防止
- 確認していないコードの動作を断定しないでください。
- 存在しないファイル、API、Package、論文を記載しないでください。
- 推測は「推測」と明記してください。
- 根拠を示せない数値は使用しないでください。
- アクセスできない情報は「確認不能」と記載してください。
- 不明な点を都合のよい前提で補完しないでください。
## 完了条件
- <REPORT_PATH>が作成されている
- リポジトリと外部情報の両方を調査している
- 重要な主張に出典がある
- 類似実装の判断にコード上の根拠がある
- 利点だけでなく制約と負の影響を記載している
- ソースコードを変更していない
なぜこのPromptを実行するのか
このPromptのポイントは、調査レポートの作成とコード変更を分離していることです。
Agentへ調査と実装を同時に頼むと、最初に見つけた解決方法へ引っ張られやすくなります。
例えば、最初に特定のPackageを見つけた場合、そのPackageを利用する前提で既存コードを読み始めるかもしれません。
一方、先に次の事実を整理すれば、選択肢が増えます。
- Native機能がある
- 既存アプリケーションに類似機能がある
- 小規模な自作で十分である
- 既存Packageが適している
- 現在のTool数では、そもそも導入価値が小さい
論文やBest Practiceから直接実装する可能性も、この段階で候補に含めます。
これは、既存Packageの有無を調べるだけの調査ではありません。
公開資料から、次の情報を抽出します。
- 何を入力するか
- どのようなアルゴリズムを使うか
- どのような制約があるか
- 何を測定すべきか
- どの条件で効果が出ないか
これらが確認できれば、誰かが公開した実装がなくても、次のStepでMockを作れる可能性があります。
Securityを調査段階から含めるのも重要です。
NIST SSDFは、Secure Software DevelopmentのPracticeを特定の工程だけでなく、SDLCへ統合する考え方を示しています。機能を作り終わった後にSecurityを追加するのではなく、調査、設計、実装、検証の各段階で考慮します。
Step 2：効果測定
ここが、今回もっとも強調したいStepです。
公開論文や公式ドキュメントを見つけたとき、従来は「利用できるPackageがあるか」を先に探していました。
Packageがなければ、誰かが実装するまで待つ、別の技術を探す、検証を後回しにする、といった判断になりやすかったと思います。
しかし、Coding Agentがある場合は、順番を変えられます。
- Native機能を確認する
- 既存Packageを確認する
- 既存アプリケーションの機能で実現できるか確認する
- 論文や仕様から最小実装を作れるか確認する
- Baselineと比較する
つまり、
第三者が完成された実装を公開していなくても、公開された知識から、自分たちのアプリケーションで価値を検証できる可能性があります。
Search Toolであれば、Production向けの高度なRetrieverを最初から作る必要はありません。
Regex、Keyword matching、BM25などの決定論的な方式で、まず仮説を測定できます。
AnthropicのTool SearchもRegexとBM25の方式を提供しており、Tool名、説明、引数名、引数説明を検索対象としています。
重要なのは、同じ実装を再現することではありません。
現在のアプリケーションにおいて、
- Contextが減るか
- Latencyが改善するか
- Tool Selectionが改善するか
- Task success rateが落ちないか
を測ることです。
Promptサンプル
あなたは、対象機能の導入価値を検証する
Software Performance Engineerです。
## 入力
- 機能名: <FEATURE_NAME>
- 品質目標: <QUALITY_GOALS>
- 調査レポート: <REPORT_PATH>
- リポジトリ: <REPOSITORY_ROOT>
- 実験成果物の保存先: <EXPERIMENT_PATH>
## 目的
対象機能を本番実装する前に、
BaselineとCandidateを同一条件で比較し、
導入する価値があるかを測定してください。
このステップでは、本番コードへ統合しないでください。
## 1. 仮説の定義
品質目標を、反証可能な仮説へ変換してください。
各仮説について次を定義してください。
- 仮説
- Primary metric
- Guardrail metric
- Baseline
- Candidate
- 測定方法
- 成功条件
- 失敗条件
- 測定できない場合の理由
成功条件が要件や既存SLOから決められない場合は、
恣意的な数値を設定せず、測定結果を提示した上で
Product Ownerの判断が必要と記載してください。
## 2. 実現方式の選定
次の優先順位で、最小の実験方式を選んでください。
1. 利用中のPlatformまたはSDKのネイティブ機能
2. 既存アプリケーションが利用しているPackage
3. 現在の言語で利用可能な保守中のPackage
4. 決定論的な小規模実装
5. 実験専用StubまたはMock
新規に機械学習モデルを学習する方式、
Fine-tuningを必要とする方式は採用しないでください。
Packageが存在しないことだけを理由に、
開発不能と判断しないでください。
単純なルール、全文検索、既存のデータ構造などで
仮説を検証できるか確認してください。
次の場合に限り、開発または測定不能と判断してください。
- 必要な拡張点が存在しない
- 利用中のSDKが必要な動作を許可しない
- 必要なデータへアクセスできない
- BaselineとCandidateを比較できない
- 禁止された方式以外では仮説を検証できない
- 実行環境、認証情報または権限が不足している
その場合は、確認した根拠を示し、次の形式で報告してください。
「現在確認できる制約の範囲では、
この機能の開発または効果測定はできません。」
## 3. BaselineとCandidate
### Baseline
現在の本番実装と同じ処理方式を再現してください。
### Candidate
対象機能を必要最小限のコードで再現してください。
Candidateへ、実験に不要な次の要素を追加しないでください。
- 汎用Framework
- 将来用の拡張ポイント
- 未使用の設定
- 複数Backend対応
- 管理画面
- 本番用の永続化
- 分散処理
- 新しい抽象レイヤー
## 4. 評価データ
可能な限り、実際の利用状況を反映したデータを使用してください。
評価データには、次を含めてください。
- 正常系
- 境界値
- 対象機能が不要なケース
- 対象機能が有効なケース
- 類似する候補から選択するケース
- 適切な候補が存在しないケース
- 頻出ケース
- 低頻度ケース
- 既知の失敗ケース
正解が仕様または既存テストで確認できない場合は、
「暫定Ground Truth」と明記してください。
合成データを使用する場合は、
実データの結果と分けて報告してください。
## 5. 測定指標
対象機能に応じて、必要な指標だけを選んでください。
### Performance
- End-to-end latency
- 処理段階別Latency
- p50
- p95
- p99
- Throughput
- CPU
- Memory
- I/O
- 測定回数
### Correctness
- Accuracy
- Precision
- Recall
- Recall@K
- False positive rate
- False negative rate
- 最終タスク成功率
- Error rate
### Cost
- API call数
- Input量
- Output量
- Token数
- Storage使用量
- Network転送量
- 推定費用
### Operability
- 依存関係の追加数
- 設定変更数
- 障害時のFallback
- 観測可能性
- Rollback可能性
平均値だけでLatencyを評価しないでください。
測定可能であれば分位点も報告してください。
## 6. 実験条件
比較時には、可能な限り次を固定してください。
- 入力データ
- Runtime
- Hardware
- Modelまたは外部API
- 設定
- Cache条件
- Retry条件
- Network条件
- 同時実行数
固定できない条件と結果への影響を記録してください。
単発測定だけで結論を出さないでください。
## 7. 成果物
<EXPERIMENT_PATH>に次を保存してください。
- README.md
- Baseline実装
- Candidate実装
- Fixture
- 評価コード
- 実行コマンド
- 生の測定結果
- 集計結果
- 制約
- 再現手順
- 導入判断
導入判断は、次のいずれかにしてください。
- 導入を推奨
- 条件付きで推奨
- 追加検証が必要
- 導入を推奨しない
- 現在の条件では測定不能
## 完了条件
- BaselineとCandidateを比較している
- 同一条件で測定している
- 成功条件と失敗条件が明示されている
- 実験を再現できる
- 測定結果と推論を区別している
- 本番コードへ統合していない
なぜこのPromptを実行するのか
このPromptでは、「新しい機能は良いものだ」という前提を置いていません。
品質目標を、反証可能な仮説へ変換します。
例えば、Search Toolなら次のようになります。
| 仮説 | Primary metric | Guardrail metric |
|---|---|---|
| Tool定義のContext量を削減できる | Tool定義のToken数またはByte数 | 最終タスク成功率 |
| Tool Selectionを改善できる | Tool Selection accuracy | Recall@K |
| 応答を高速化できる | End-to-end p50、p95 | Tool検索失敗率 |
| API費用を削減できる | 1リクエスト当たりInput Token | 追加API call数 |
| 多数のToolへ拡張できる | Tool数増加時の成功率 | Index更新時間 |
ここで、検索が成功したかどうかと、Agent全体が成功したかどうかを分けます。
Tool Retrieval
ユーザー要求に必要なToolが上位K件へ含まれるか
Tool Selection
検索結果の中からAgentが正しいToolを選ぶか
Argument Accuracy
選択したToolへ正しい引数を渡すか
Task Success
Tool実行後にユーザーの目的を達成できたか
Retrieverが必要なToolを返しても、Agentが別のToolを選ぶことがあります。
逆に、Retrieverの順位が低くても、Candidate内に正解Toolが含まれていれば、Agentが正しく選べる可能性があります。
そのため、各段階を分けて測定します。
また、Latencyは平均値だけで見ません。
Google SREでは、50th percentileを典型的なケース、99thや99.9th percentileを遅い側の挙動を把握する指標として扱い、Latency分布を見る方法を説明しています。
実務では、一部の遅いRequestがユーザー体験やTimeoutに影響することがあります。
平均値が改善していても、p95やp99が悪化している可能性があるためです。
そして、ここでもっとも重要なのが、次の順序です。
1. Native機能
2. 既存依存
3. 保守中のPackage
4. 決定論的な小規模実装
5. 実験専用Mock
この順序によって、何でも自作することを防ぎつつ、Packageが見つからないだけで検証を諦めることも防ぎます。
論文やBest Practiceから最小実装を作ることは、最後の手段ではありません。
価値を測るための現実的な選択肢の一つです。
とはいえ、機械学習モデルの学習やFine-tuningまで必要になると、Mockの範囲を超える場合があります。
その場合は、作れないことを明確に報告させます。
無理に似たものを作り、測定できたように見せるより、その方が実務では信頼できます。
Step 3：詳細な実装プランの作成
効果が確認できたら、すぐにProductionコードへ移植したくなります。
ただし、MockとProductionコードでは目的が違います。
Mockは、仮説を検証できれば十分です。
Productionでは、次の点を考える必要があります。
- 既存Architectureとの整合
- Failure mode
- Security
- Observability
- Rollback
- Configuration
- Backward compatibility
- Test
- 運用負荷
そのため、実装前に詳細なPlanを作ります。
ここでのポイントは、Taskを小さくすることです。
ただし、行数だけを小さくするわけではありません。
1つのTaskを、独立して理解、実装、Test、Reviewできる意味単位にします。
GoogleのEngineering Practicesでも、変更を小さく自己完結させることで、Reviewしやすくなり、問題の発見やRollbackがしやすくなると説明されています。関連するTestは同じ変更へ含める考え方です。
Promptサンプル
あなたは、既存アプリケーションへの変更を設計する
Software Architectです。
## 入力
- 会話セッションの内容
- 調査レポート: <REPORT_PATH>
- 実験結果: <EXPERIMENT_PATH>
- リポジトリ: <REPOSITORY_ROOT>
- 実装プラン保存先: <PLAN_PATH>
## 目的
承認後に別のEngineerまたはCoding Agentが
迷わず実装できる詳細な実装プランを作成してください。
このステップではコードを変更しないでください。
## 1. 導入判断
最初に、実験結果を基に次を記載してください。
- 解決する問題
- 導入する機能
- 導入しない機能
- 採用する方式
- 採用しなかった方式
- 判断根拠
- 未解決のリスク
- 想定するRollback方法
実験で効果が確認できていない事項を、
導入効果として断定しないでください。
## 2. 変更範囲
次を特定してください。
- 変更するファイル
- 新規作成するファイル
- 削除するファイル
- 変更しない領域
- Public APIへの影響
- DatabaseまたはSchemaへの影響
- Configurationへの影響
- Dependencyへの影響
- Securityへの影響
- Observabilityへの影響
- Documentationへの影響
コード上の根拠が確認できない変更を追加しないでください。
## 3. タスク分割
各タスクを、独立して理解、実装、テスト、レビューできる
最小の意味単位へ分割してください。
単なる行数削減を目的に、
意味のない細分化はしないでください。
各タスクについて次を記載してください。
- Task ID
- 目的
- 入力
- 出力
- 事前条件
- 作成するファイル
- 編集するファイル
- 変更内容
- 変更しない内容
- テスト
- 完了条件
- 後続タスク
- Rollback方法
1つのタスクへ、無関係なRefactoringと機能変更を
同時に含めないでください。
## 4. 依存関係
タスク間の依存関係を示してください。
各タスクを次のいずれかへ分類してください。
- 直列実行が必要
- 並列実行可能
- 条件付きで並列実行可能
並列実行可能とする場合は、
次を確認してください。
- 編集ファイルが競合しない
- 同一の共有状態を変更しない
- 入出力の依存がない
- 個別にテストできる
- 個別にRollbackできる
実行順序をMermaidのDAGまたは表で表現してください。
## 5. 不明点
少しでも設計判断が必要な事項は、
次の形式で番号を付けてください。
### 不明点 N
- 不明点:
- 判断が必要な理由:
- 選択肢:
- A:
- B:
- C:
- デフォルトの選択肢:
- デフォルトを選んだ理由:
- 各選択肢の影響:
- 回答が必要になるTask:
選択肢を作るためだけに、
実際には不要な選択肢を捏造しないでください。
既存コード、要件または実験結果によって一意に決まる事項は、
不明点として列挙しないでください。
## 6. オーバーエンジニアリングの禁止
次を追加しないでください。
- 要件にない汎用化
- 将来利用を想定した拡張ポイント
- 未使用のInterface
- 未使用の設定
- 不要なFeature flag
- 単一実装のためだけのFactoryまたはStrategy
- 予防目的だけの過剰な例外処理
- 既存機構で十分な箇所への新規Dependency
- 実験で必要性を確認していないOptimization
- 対象機能と無関係なRefactoring
必要性を説明できないTaskは削除してください。
## 7. テストプラン
少なくとも次を検討してください。
- Unit test
- Integration test
- Regression test
- Error case
- Boundary case
- Security test
- Performance regression
- Rollback確認
すべてを必須にせず、
変更内容に必要なテストだけを選択してください。
## 8. 承認ゲート
実装は開始しないでください。
最後に次を表示して停止してください。
- Task数
- 直列Task数
- 並列可能Task数
- 変更予定ファイル
- 新規Dependency
- 未解決の不明点
- 主要リスク
- 推奨する実行順序
- ユーザーに回答してほしい選択肢
「このプランの承認または選択肢の回答を待っています」
と記載してください。
## 完了条件
- <PLAN_PATH>が作成されている
- コードが変更されていない
- 各Taskとファイルがマッピングされている
- Taskの依存関係が明確である
- テストと完了条件が定義されている
- 不明点にデフォルトと理由がある
- 不要な抽象化が含まれていない
なぜこのPromptを実行するのか
このPromptでは、実装Taskと編集ファイルを対応付けています。
Coding AgentのContext Windowは有限です。
1つのTaskへ多数の目的とファイルを詰め込むと、以前に確認した制約や設計判断がContextの中で弱くなる可能性があります。
Taskを小さくすることで、各Taskの実行時に必要な情報を限定できます。
ただし、Taskを細かくすればよいわけではありません。
例えば、関数の宣言だけを作るTaskと、関数の中身を書くTaskを分けると、個別には価値がなく、Reviewもしにくくなります。
1つのTaskは、動作または設計上の意味を持つ単位にします。
また、Taskごとに「変更しない内容」を記載します。
Agentは、対象コードの近くに改善できそうな箇所を見つけると、依頼されていないRefactoringまで行うことがあります。
そこで、対象外を明示します。
オーバーエンジニアリングを禁止する考え方はYAGNIと関係します。
YAGNIは、将来必要になると推測したCapabilityを、必要になる前に実装しないという考え方です。ただし、Codebaseを変更しやすく保つRefactoringやTestまで否定するものではありません。
つまり、
- 将来使うかもしれないBackend interface
- まだ必要のないFeature flag
- 1種類しかない実装のFactory
- 想定されていない複数Provider対応
を先回りして追加しない、ということです。
一方で、変更を安全にするためのTestや、明らかに必要なRollback手段は含めます。
Architecture上の重要な判断がある場合は、ADRを残す方法もあります。
ADRは、Architectureに影響するDecisionと、そのContextやConsequencesを小さな文書として残す考え方です。大きな設計文書ではなく、重要な意思決定を個別に記録します。
ただし、すべての小さな変更へADRを要求する必要はありません。
実務では、Dependency、Interface、Non-functional requirement、長期的な構造へ影響するDecisionに限定するのが現実的です。
Step 4：設計プランの敵対的レビュー
このStepでは、作成したPlanをそのまま信じません。
設計を作成したAgentは、自分が置いた前提を正しいものとして扱いやすいためです。
そこで、作成者とは別のReviewerとしてPlanを確認します。
ただし、「敵対的」という言葉には注意が必要です。
目的は、無理に問題を作ることではありません。
証拠に基づいて、次のような問題を探すことです。
- 要件を満たせない
- 実験結果と設計が一致しない
- Taskの依存関係が誤っている
- Security上の見落としがある
- Rollbackできない
- Testで完了条件を確認できない
- 不要な抽象化が追加されている
- 未確認事項を事実として扱っている
元のPromptでは、問題を15件から100件出す指定がありました。
この下限は、捏造禁止と衝突します。
実際の問題が5件しかない場合でも15件を要求すると、Agentは好みの違いや仮定上の懸念を問題として水増しする可能性があります。
そのため、件数の下限は設定しません。
Reviewの品質は指摘数ではなく、根拠、発生条件、重大度、修正可能性で判断します。
Promptサンプル
あなたは、対象プランを作成していない独立した
Software Design Reviewerです。
作成者の意図を擁護せず、
要件未達、誤った前提、変更リスクの発見を優先してください。
## レビュー対象
- 実装プラン: <PLAN_PATH>
- 調査レポート: <REPORT_PATH>
- 実験結果: <EXPERIMENT_PATH>
- リポジトリ: <REPOSITORY_ROOT>
- 元のユーザー要件
- この会話で確定した選択肢
レビュー前に、元の目的と成功条件を要約してください。
## 検証軸
### 1. 目的適合性
- 依頼内容と一致しているか
- 必要な成果物が揃っているか
- スコープが不足または超過していないか
- 実験結果と導入判断が一致しているか
### 2. 内容の妥当性
- 前提は正しいか
- 設計が既存コードに適合するか
- Task分割が実装可能か
- 依存関係が正しいか
- テストで完了条件を検証できるか
### 3. 整合性
- 文書内に矛盾がないか
- 調査レポートと矛盾しないか
- 実験結果と矛盾しないか
- 既存コードと矛盾しないか
- 用語とファイル名が一貫しているか
### 4. 品質・運用性
- 可読性
- 保守性
- テスト容易性
- Observability
- Rollback
- Failure mode
- Security
- Dependency管理
- 運用負荷
### 5. 根拠性・不確実性管理
- 根拠のない断定
- 未確認事項の事実化
- 推測の混入
- 存在しない問題の指摘
- 必要な留保の欠落
- ベンダーの主張と実測値の混同
## 重大度
### Critical
次のいずれかに該当するものです。
- 要件を満たせない
- データ破損または消失の現実的リスク
- 認証または認可の欠陥
- 機密情報漏えいの現実的リスク
- 本番停止につながる設計欠陥
- Rollback不能
- 実装を開始できない重大な矛盾
### Major
- 設計上の懸念
- テスト不足
- 不正確な依存関係
- 運用上の重大な不足
- 保守性の悪化
- 実験結果と設計の不一致
### Minor
- 読みやすさ
- 用語の不統一
- 説明不足
- 任意の改善
Criticalを安易に使用しないでください。
具体的なFailure scenarioを説明できない場合は、
Criticalとして分類しないでください。
## 指摘件数
指摘数に最低件数を設けません。
確認できた問題だけを報告してください。
問題が存在しない場合は0件でも構いません。
最大100件までとし、
同じ原因による重複指摘は統合してください。
## 出力形式
| No. | 軸 | 重大度 | 指摘箇所 | 根拠 | 問題の説明 | 発生条件 | 修正案 |
|---|---|---|---|---|---|---|---|
各指摘には、可能な限り次の根拠を付けてください。
- 文書のSection
- Task ID
- ファイルパス
- Symbol名
- コード位置
- 実験結果
- 元の要件
根拠が確認できない懸念は、
確定した問題ではなく「要確認」としてください。
## サマリー
- Critical: X件
- Major: Y件
- Minor: Z件
- 要確認: N件
- 合格判定:
- PASS: Criticalが0件
- FAIL: Criticalが1件以上
Criticalが0件でも、
Majorの内容によって条件付きPASSと判断して構いません。
## 修正
レビュー表を完成させた後、
実装プランを次の規則で修正してください。
- Criticalはすべて修正
- Majorは修正する
- Majorを修正しない場合は理由を記載
- Minorは修正価値が高いものだけ修正
- 要確認事項を、確認済みとして勝手に補完しない
修正により新しい設計判断が必要になった場合は、
不明点として追加し、デフォルトの選択肢と理由を示してください。
## 再レビュー
修正後のプランに対して、次だけを再確認してください。
- Criticalが解消されたか
- 修正による矛盾が発生していないか
- スコープが拡大していないか
- 新しい未確認事項を事実化していないか
- オーバーエンジニアリングが追加されていないか
再レビュー結果を報告して停止してください。
コード実装は開始しないでください。
なぜこのPromptを実行するのか
Coding AgentによるPlanは、詳細に見えても、前提が誤っていることがあります。
例えば、実際には同期APIしかないのに非同期処理を前提としていたり、利用できない拡張点を前提にTaskを組んでいたりするケースです。
また、Mockで効果が出た部分と、Production設計で追加された部分が混ざることもあります。
そこで、Reviewでは、元の要件、調査レポート、実験結果、既存コード、Planを横断して確認します。
GoogleのCode Review Practicesでも、Review対象として、Design、Functionality、Complexity、Tests、Naming、Comments、Style、Documentationなどが挙げられています。また、小さな複雑性の追加が積み重なってCodebase全体を複雑にするため、新しい変更に含まれる不要なComplexityを確認する考え方が示されています。
Reviewで重要なのは、作成者を否定することではありません。
変更後のCodebaseの健康状態を維持することです。
そのため、指摘には必ず根拠と発生条件を要求します。
「将来的に問題になるかもしれない」だけでは、確定した問題として扱いません。
Step 5：Taskの実行
最後に、承認済みPlanを実行します。
このStepでも、一度に全Taskを実行しません。
Taskを1件実装した後、Testと敵対的Reviewを行い、指摘を反映してから次へ進みます。
この方法は、実行速度だけを見ると遅く感じるかもしれません。
ただ、実務では、まとめて多数のファイルを変更し、最後にまとめて問題を調べる方が時間がかかることがあります。
Taskごとに完了条件を確認することで、問題が発生した範囲を限定できます。
また、Plan上は並列実行可能なTaskを特定しますが、同じWorking Treeでは逐次実行します。
並列実行する場合は、Branch、Worktree、独立したAgentなどで変更を分離する必要があります。
Promptサンプル
承認済み実装プランに従って、
Taskを1件ずつ実行してください。
## 入力
- 承認済みプラン: <PLAN_PATH>
- リポジトリ: <REPOSITORY_ROOT>
- ユーザーが回答した選択肢
- Step 4のレビュー結果
## 選択肢
ユーザーが次の形式で回答した内容を適用してください。
例:
1: A
2: B
5: C
ユーザー回答がない不明点には、
プランに記載されたデフォルトの選択肢を適用してください。
デフォルトが定義されていない重要事項を、
勝手に決定しないでください。
## 実行規則
- Task IDの順序と依存関係に従ってください。
- 一度に実行するTaskは1件だけです。
- 現在のTaskが完了するまで次へ進まないでください。
- 現在のTaskにマッピングされていないファイルを変更しないでください。
- 無関係なRefactoringを行わないでください。
- 新しいDependencyを無断で追加しないでください。
- 実装中にスコープ不足を発見しても、勝手に拡大しないでください。
- 実装プランとコードが矛盾する場合は停止してください。
プランで並列実行可能とされたTaskも、
このセッションでは逐次実行してください。
別Branch、Worktreeまたは独立Agentによる並列実行は、
ユーザーが明示的に指示した場合だけ実施してください。
## 各Taskの実行手順
### 1. 事前確認
実装前に次を確認してください。
- Task ID
- 目的
- 入力
- 事前条件
- 編集対象ファイル
- 作成対象ファイル
- 完了条件
- 必要なテスト
事前条件を満たしていない場合は停止してください。
### 2. 実装
承認済みプランの範囲内で、
必要最小限の変更を行ってください。
既存の次の方式を優先してください。
- 命名規則
- Error handling
- Logging
- Configuration
- Dependency injection
- Test framework
- Formatter
- Linter
既存方式を変更する必要がある場合は、
理由を報告して停止してください。
### 3. 検証
Taskに対応する次の検証を実施してください。
- Formatter
- Linter
- Type check
- Unit test
- Integration test
- 対象機能の確認
- Regression test
リポジトリに存在しないコマンドを捏造しないでください。
既存のREADME、package script、CI設定などから
正しいコマンドを確認してください。
### 4. 敵対的レビュー
実装者とは別のReviewerとして、変更差分を確認してください。
次を検証してください。
- Taskの目的を満たしているか
- スコープ外の変更がないか
- 既存動作を壊していないか
- 不要な抽象化がないか
- Error caseが不足していないか
- Security上の問題がないか
- テストが実装を正しく検証しているか
- テストが常に成功するだけの無意味な内容になっていないか
- コメントとドキュメントが実装と一致しているか
確認できた問題だけを報告してください。
指摘件数に最低件数を設けないでください。
### 5. 修正
レビューで確認された問題を修正してください。
- Criticalはすべて修正
- Majorは修正
- 修正しないMajorは理由を報告
- Minorは必要なものだけ修正
修正後、関連する検証を再実行してください。
### 6. 完了報告
各Taskの完了時に、次を報告してください。
- Task ID
- 実施内容
- 作成ファイル
- 編集ファイル
- 実行した検証
- 検証結果
- レビュー指摘
- 反映した修正
- 未解決事項
- 完了条件の判定
完了条件を満たした場合だけ、
次のTaskへ進んでください。
## 停止条件
次の場合は作業を停止し、ユーザーへ報告してください。
- データ損失の可能性がある
- Security上の重大な判断が必要
- Migrationが不可逆
- 認証または権限が不足
- プラン外の大規模変更が必要
- 新しい有料サービスが必要
- 実験結果と異なる挙動が発生
- 既存テストの失敗原因が判断できない
- ユーザー判断が必要な不明点を発見
- 完了条件を検証できない
## 全Task完了後
次をまとめて報告してください。
- 完了したTask
- 変更ファイル一覧
- 新しいDependency
- テスト結果
- 未解決事項
- 既知の制約
- Rollback手順
- 実験時の効果が維持されているか
- 本番反映前に必要な作業
なぜこのPromptを実行するのか
実装時に重要なのは、Agentへ自由を与えすぎないことです。
一方で、すべての操作に対して確認を要求すると、作業が細切れになります。
そのため、このPromptでは、承認済みPlan内の非破壊的な変更とTestは実行させ、次の場合に停止させます。
- データを失う可能性がある
- Security上の判断が必要
- Plan外の変更が必要
- 有料サービスや新しいDependencyが必要
- 完了条件を検証できない
つまり、実装の細部はAgentへ任せますが、Scope、Risk、Costに関わる判断は人間へ戻します。
Taskごとに敵対的Reviewを行う理由は、最後にすべての変更をまとめてReviewすると、どのTaskで問題が入ったか分かりにくくなるためです。
小さな単位で、
実装
↓
Test
↓
Review
↓
修正
↓
再Test
↓
完了
まで閉じます。
まずはここまでで十分です。
実際のDeployment、Feature flag、Canary release、Production Monitoringは、対象アプリケーションのRelease Processに合わせて追加します。
公開論文やBest Practiceから、直接実装するという選択肢
ここまでの5段階を通して、私が特に重要だと考えているのは、
公開論文やBest Practiceを、知識として読むだけでなく、検証可能な実装仕様として利用できる
という点です。
これまで、論文で新しい手法を見つけても、実装には次のような制約がありました。
- 公式実装がPythonしかない
- 利用している言語向けPackageがない
- Sampleが研究用で、既存アプリケーションへ統合しにくい
- OSSが長期間更新されていない
- 大きなFrameworkへ依存する
- Licenseが自分たちの利用条件に合わない
- 実装が複雑すぎて、検証だけでも時間がかかる
Coding Agentは、これらを自動的に解決するわけではありません。
ただし、公開資料に十分な情報があれば、次のような進め方ができます。
- 論文からアルゴリズムと制約を抽出する
- 公式ドキュメントからAPIの利用条件を確認する
- 現在のコードベースで類似機能を調査する
- 現在の言語で最小実装を作る
- 実データまたは代表データで評価する
- 効果があった場合だけProduction設計へ進む
これにより、
誰かが自分たちの環境向けに実装してくれるまで待つ必要が減ります。
例えば、論文でRanking手法が公開されている場合、必ずしも著者のRepositoryをそのまま導入する必要はありません。
必要な部分だけを、現在のアプリケーションのデータ構造とProgramming Languageに合わせて実装できます。
また、Best Practiceに手順と評価基準が書かれている場合、それをAcceptance CriteriaやReview項目へ変換できます。
これは単なるコード生成ではありません。
公開されたSoftware Engineeringの知識を、
調査項目
↓
仮説
↓
Mock
↓
Benchmark
↓
実装Plan
↓
Review基準
↓
Production Code
へ変換する作業です。
とはいえ、万能ではありません。
次のケースでは、既存実装を利用する方が合理的です。
- 暗号処理
- Database driver
- Protocol implementation
- Parser
- 認証基盤
- 高度に最適化された検索エンジン
- 長期間の互換性維持が必要なLibrary
- 標準準拠の実装
- Security review済みのComponent
これらを安易に自作すると、検証コストや保守コストが大きくなります。
したがって、目的は「何でも自作する」ことではありません。
既存実装を使うか、自分たちで小さく作るかを、Packageの有無ではなく、要件、効果、Risk、Costで選べる状態にすることです。
Search Toolのような機能は、その違いが分かりやすい例です。
RegexやBM25による小規模な検索で価値を測れるなら、最初から大きなRetrieval基盤や機械学習モデルを導入する必要はありません。
一方、検索品質がビジネス上重要で、高度なRetrieverが必要だと分かった時点で、専門Packageや外部Serviceを比較すればよいです。
参考資料
今回の考え方では、次の資料を参照しています。
-
Anthropic「Tool search tool」
Regex／BM25を利用したTool検索、Deferred Loading、検索後のTool定義展開に関する公式ドキュメントです。 -
Shi et al.「Retrieval Models Aren't Tool-Savvy: Benchmarking Tool Retrieval for Large Language Models」
7,600件のRetrieval taskと43,000件のToolからなるToolRet Benchmarkを提示し、一般的なIR性能がTool retrieval性能へそのまま結び付かないことを報告した論文です。 -
Google Engineering Practices「Small CLs」
小さく自己完結した変更と、Review、Test、Rollbackのしやすさに関するPracticeです。 -
Google Engineering Practices「What to look for in a code review」
Design、Functionality、Complexity、Tests、Documentationなど、Code Reviewで確認する観点を整理しています。 -
Google SRE「Service Level Objectives」「Monitoring Systems with Advanced Analytics」
Latencyを平均値だけでなく、50th、95th、99th percentileなどの分布で確認する考え方を説明しています。 -
NIST SP 800-218「Secure Software Development Framework」
Secure Software Development PracticeをSDLCへ統合するためのFrameworkです。 -
Martin Fowler「Yagni」
将来必要になると推測したCapabilityを、必要性が確認される前に追加しない考え方です。 -
Michael Nygard「Documenting Architecture Decisions」
Architecture上重要なDecisionを、小さなADRとして記録する考え方です。
ここまでの整理
ここまでの内容を整理します。
良い点
- 公開論文や公式ドキュメントから、最小実装を作成できる
- 誰かがPackage化するまで待つ必要が減る
- 現在利用しているProgramming Languageへ変換できる
- 既存アプリケーションに合わせたMockを作れる
- Baselineと比較して、導入前に価値を測定できる
- 既存Package、自作、Native機能を同じ基準で比較できる
- 調査、検証、設計、Review、実装を分離できる
- Taskを小さくし、Coding AgentのContextを限定できる
- 実装前にScopeとRiskを確認できる
注意点
- 論文の結果が現在のアプリケーションで再現されるとは限らない
- VendorのBenchmarkは独立した検証結果ではない
- MockをそのままProductionへ投入しない
- Security、License、運用、Rollbackを別途確認する
- Ground Truthがない評価は暫定値として扱う
- LatencyとContext削減を同じ効果として扱わない
- Packageがないことと、実装不能であることを混同しない
- 自作すること自体を目的にしない
- Reviewの指摘数を品質指標にしない
- 未確認事項をAgentに補完させない
限界
- 論文に実装可能な詳細がない場合がある
- 学習済みモデルや大規模Datasetが必要な方式は再現できないことがある
- HardwareやAPI権限が不足している場合がある
- Production相当のLoadを再現できないことがある
- Security-sensitiveなComponentは自作に向かない
- 長期保守や標準準拠では、成熟した既存実装が有利な場合がある
- Coding Agentの出力にもReviewが必要
- 調査対象が大きい場合、Context管理そのものが課題になる
まとめ
Coding Agentを使う価値は、コードを速く書けることだけではありません。
私は、公開されている論文、公式ドキュメント、Best Practiceと、現在のコードベースの距離を縮められることが大きいと考えています。
これまでであれば、論文を読んだ後に、
- 実装者を探す
- OSSを待つ
- 対応LanguageのPackageを探す
- Sampleを現在の環境へ移植する
といった作業が必要でした。
現在は、資料に必要な情報が公開されていれば、Coding Agentへ調査、Mock作成、Benchmark、設計まで依頼できます。
その結果、他の人が開発したものを使うしかない場面や、誰かの実装を待つ場面は、減る可能性があります。
ただし、これは既存OSSやPackageが不要になるという意味ではありません。
成熟した実装を使う方が安全で、安価で、保守しやすい場合は多くあります。
現実的な落としどころは、最初から自作かOSSかを決めることではありません。
まず、公開されている知識から最小のCandidateを作り、現在のアプリケーションで価値を測ります。
その後で、
- Native機能を使う
- 既存Packageを使う
- 既存コードを拡張する
- 必要最小限を自作する
- 導入を見送る
のいずれかを選びます。
そのための手順が、今回の5段階です。
調査
↓
効果測定
↓
詳細設計
↓
敵対的レビュー
↓
Task単位の実装
新しい論文やBest Practiceを見つけたとき、すぐにProductionへ入れる必要はありません。
まず、既存アプリケーションのデータと制約を使って、小さく検証できるかを確認します。
公開された知識を、実務で判断できる証拠へ変える。
Coding Agentとの向き合い方としては、まずはここまでで十分だと思います。
最後に。
私が、自分のアプリに、Search Toolのコードとドキュメントと統計情報の機能を組み込むのに費やしたリソースは以下です。
- 主要モデル: Opus 5 - Ext High
- 営業日: 2日
- 作業時間: 30分程度 = GitHub CopilotにPromptを考えて入力をする時間
つまり、殆どが待ち時間です😎
この間は、別のお仕事をしていましたーーー
私の実装結果😎
1. トークン削減（ToolRet ベンチマーク）
ベンチマーク: ToolRet（44,000+ tools / 7,000 queries）。
Tool 数を増やしながら、全 Tool 前渡し（prompt caching 有効）と tool search を比較。
| Toolbox の Tool 数 | トークン削減率 |
|---|---|
| 50 | 60% 超 |
| 1,000 | 97% 超 |
補足: prompt caching は既定で有効だが、キャッシュ済みトークンは通常入力の約 90% 安いだけで無料ではない。
かつキャッシュ済みコンテキストもモデルの注意を奪う（ブログ「The default agent tax」節）。
2. 検索品質（Recall@10）
| 手法 | Web | Code | Customized |
|---|---|---|---|
| Tool search | 45.99% | 39.56% | 41.36% |
| BM25s | 24.62% | 28.23% | 32.39% |
| BGE-reranker-v2-gemma | 45.94% | 38.23% | 49.43% |
BM25s / BGE-reranker-v2-gemma の数値は ToolRet 論文由来。
Tool search は 3 カテゴリ全てで BM25s を上回り、GPU リランカーと Web でほぼ同等・Code でわずかに上回る。
3. メタデータ調整の効果
additional_search_text によるチューニング後（ブログ「Tuning the search space」節）:
- 検索ヒット率: 約 +56%
- end-to-end 精度: 約 +55%
- 全 Tool 前渡しベースラインとの差: 約 4% 以内まで回復
つまり 97% のトークンを削減しつつ、精度低下を 4% 以内に抑えられる。
以上ーーー!!!😎