💾 大規模ベクトル検索、もうメモリに全部乗せなくていい時代に。 📰 タイトル: HFresh: Memory-Efficient Vector Search 🔗 URL: Weaviateが、ディスクベースの新しいベクトルインデックス「HFresh」を発表しました。数十億件規模のベクトルを、限られたメモリで検索できるように設計されています。 注目ポイント 🧩 パーティション型アーキテクチャ HNSWのように全ベクトルをグラフで結ぶのではなく、小さな「postings」という領域に分割。インメモリのセントロイドHNSWで候補領域を絞り込み、該当するpostingsだけディスクから読み出して検索します。 📦 2段階の量子化戦略 セントロイドにはRQ8を使いメモリを約4分の1に圧縮しつつルーティング精度を維持。postingsにはRQ1を使い32bit floatと比べて最大32倍圧縮し、ディスクI/Oとストレージコストを削減します。 🔄 リビルド不要のバックグラウンド保守 Split・Merge・ReassignというLIRE由来の仕組みで、インデックス全体を作り直すことなく継続的に品質を維持します。 DBpediaの100万件データセットではヒープ使用量239MBと、非圧縮HNSWの6.67GBの約28分の1に抑制。10億件・256次元のベクトルでも動作を実証しており、メモリ制約のある環境や大規模スケールに最適な選択肢です。 #VectorSearch# #Weaviate#

TL;DR: 乱立するベクトル量子化手法を、共通の小さな部品（プリミティブ）の組み合わせとして統一的に扱い、同一条件で比較できるベンチマーク「VQ-bench」をPineconeが公開しました。 タイトル: VQ-bench: a Composable Vector Quantization Framework URL: ポイント 🧩 Center・Normalize・PCA・RandomRotateなど、量子化を構成する共通プリミティブを定義し自由に組み合わせ可能に 🔗 E-RaBitQなどの既存手法も「Center→Normalize→Random Rotation→Angular Cast」の4プリミティブの並びだけで再現 📊 VIBEの5データセット・14種類の量子化器をReconstruction MSE・Recall@10・エンコード時間で横並び比較 🥇 PQとOPQが一貫して最小のReconstruction MSEを記録 ⚡ EDENはPQ/OPQ/E-RaBitQより大幅に高速なエンコードを実現しつつRecallも高水準を維持 🛠️ 新規量子化器の追加は数行のコードで済み、新規プリミティブは既存の全部品と自動的に合成可能 バラバラだった量子化手法の評価が同じ土俵に乗ったことで、用途に応じた選定がしやすくなりそうです。 #ベクトル検索# #ベクトルDB#

📊 決算資料のグラフの中にしか答えがない質問、これまでのRAGだと拾えなかったんです。 タイトル: How to extract meaning from charts and tables in PDFs URL: PDFをテキスト抽出せず、ページをそのまま画像として検索対象にするアプローチをWeaviateが紹介しています。注目ポイントを3つに絞って紹介します。 🔍 OCR不要のマルチベクトル検索 ページ全体を1本のベクトルに圧縮せず、画像パッチごとに複数のベクトルを持たせ、クエリとのMaxSimで局所マッチングします。チャートやレイアウトの視覚情報を壊さずに検索できるのがポイントです。 🖼️ ドラッグ&ドロップで導入完了 Weaviate CloudにPDFを入れるだけで各ページを高解像度画像化しBLOB保存、専用モジュールが自動でベクトル化します。NVIDIAの決算資料92ページの取り込みはわずか約90秒でした。 🤖 出典付きで数値を回答 「自動車事業の売上推移は？」と聞くと、$346M→$586M（+69%）という五四半期分の棒グラフのページを正しく検出。Query Agentを使えば根拠ページの画像付きで回答も生成できます。 チャートだらけで扱いにくかったPDFこそ、実は一番おいしいユースケースだったという発想の転換が面白いところです。 #RAG# #Weaviate#

Postgres で十分じゃん、というWebサイト。Postgresに限らずだけど、そんなにスケールする必要がないのはそうだと思う。 ・多くのシステムではキャッシュや検索などに別々のデータベースを使いすぎ ・時期尚早な最適化であり、運用や保守の負担を増大させるだけ ・目的ごとにRedisやElasticsearchなどを追加していくのがよくある開発パターン ・その結果、システムが複雑化し、監視やバックアップの手間が膨れ上がる ・データベースをPostgres一つに絞れば、運用や障害対応を一本化できる ・ただ、Postgresは大規模なシステムには向かないという批判をよく耳にする ・しかし、実際にそこまでの規模に達するプロジェクトは全体のわずか ・スタートアップ企業はインフラ構築よりも、本来の課題解決に労力を注ぐ方が良い ・多くのユーザーを抱える大企業でさえ、枯れた技術を信頼して活用している ・Postgresの処理能力の限界に達してから、別のシステムを追加しても遅くはない ・キャッシュ機能はRedisを使わなくてもPostgresの機能で代用できる ・ジョブキューや全文検索、ドキュメントの保存もPostgresの拡張機能で対応可能 ・AI向けのベクトル検索や時系列データの処理などもPostgresで実行できる ・もちろん、専用のデータベースが必要になる場面もある ・ただその導入のハードルは高く設定しておいて良い ・Postgresを限界まで使い倒してみよう ・それでも不足する場合にのみ新しいシステムを追加したら良い

# AIエージェントをソフトウェアに組み込むプラクティス # コンテキスト予算配分 🎯 「全部入れれば精度が上がる」は幻想です。コンテキストウィンドウは有限の予算として管理しましょう。 スロットごとに配分比率を決め、信号密度を最大化するパターンです。 🔥 解決する課題 RAGやメモリを使うエージェントでは、検索結果・会話履歴・システム指示・長期メモリが同じコンテキストウィンドウを奪い合います。情報を詰め込むほどコストは増え、会話が長くなるとシステム指示の割合が縮んで振る舞いが劣化します。さらに"Lost in the Middle"問題により、窓の中盤に置かれた重要な情報が実質的に無視されてしまいます。 💡 提案パターン コンテキストウィンドウをシステム指示・検索結果・会話履歴・メモリなどのスロットに分け、各スロットに最大占有率と優先度を設定します。システム指示は圧縮対象外の固定枠（10〜20%）として先に確保し、検索結果はリランク後にtop-k件に絞り、履歴は窓使用率が閾値を超えたら要約圧縮します。配置順序はLost in the Middle対策として、最重要情報を先頭に、直近入力を末尾に置きます。cost_sensitivityが高い環境ほどtop-kを絞り、圧縮閾値を下げ、履歴を短く保ちます。 ✅ 選定条件 使うとき： - RAGやメモリを使い、投入候補がモデル窓サイズの50%を超えうる - コスト感度が中以上で、投入トークンの増加がコストや推論時間に影響する - 複数ターンの会話で履歴が蓄積し、他の情報のスペースを圧迫する 使わないとき： - 投入情報がシステム指示＋単発入力のみで窓の30%未満に収まる場合 - ロングコンテキストモデルを使い投入量が窓の20%未満、かつコスト感度が低い場合 ⚠️ 落とし穴 - システム指示を圧縮対象にしてはいけません。ツール定義や安全指示が削られると振る舞いが壊れます - リランクなしのtop-kは信号密度が低いです。ベクトル検索上位20件からクロスエンコーダで3〜8件に絞りましょう - 要約圧縮は非可逆です。重要な決定事項や固有名詞が落ちるリスクがあるため、キーワード抽出を併用してください 🔧 実装方針 - コンテキストウィンドウをスロット（system/user/retrieval/history/memory）に分割し、各スロットに最大占有率・優先度・圧縮可否を定義した構造体で管理します - システム指示は圧縮対象外の最高優先度として先に確保し、残りの予算を他スロットに優先度降順で配分します - 検索結果はベクトル検索の上位候補をクロスエンコーダでリランクしてから予算内に収め、信号密度を最大化します - 履歴スロットが予算を超過した場合は要約圧縮を適用し、圧縮前にキーワード抽出して重要情報の欠落を防ぎます #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェント開発の意思決定ポイント 🎯 **ポイント** RAGのtop-k、なんとなく「5」にしていませんか？検索結果を多く入れれば根拠が増えると思いきや、LLMは中盤の情報を無視しがちで、コストだけが直線的に増加します。少なすぎればハルシネーション、多すぎればノイズと予算超過。このバランスを取るための実践的な考え方を解説します。 📋 **概要** 検索top-kは、RAG（Retrieval-Augmented Generation）において外部知識ストアから取得する文書チャンクの件数を制御するパラメータです。広義には「LLMのコンテキストウィンドウに投入する外部情報の量」を意味します。コンテキストウィンドウは有限の資源であり、システム指示・検索結果・会話履歴・長期メモリ・ツール出力が奪い合っています。検索結果を多く入れれば根拠は増えますが他の情報が押し出され、少なければ根拠不足でハルシネーションが増えます。 重要なのは件数だけでなく「何を上位に置くか」です。初期検索で広めに候補を取り、リランカーで信号密度の高い順に並べ替えて上位k件を投入するパイプラインが標準的です。 🔍 **意思決定のポイント** top-kの設定は主に以下の変数で決まります。 🔹 **コスト感度（cost_sensitivity）** — コスト感度が高いほどtop-kを絞ります。ただし最低限の根拠確保のためk=3を下回ることは稀です。kを5から20に増やすと検索結果部分のトークンは概ね4倍、コストもそれに比例します。 🔹 **失敗コスト（failure_cost）** — 失敗コストが高い領域では根拠の網羅性が重要。kを多めにとりリランクで品質を担保する戦略が有効です。ただしリランクスコアが閾値を下回る文書は切り捨てるべきです。 🔹 **説明責任（accountability）** — 回答の根拠として引用できる文書を確保する必要がある場合、kを増やすよりもリランクスコアの高い少数の文書を確実に含め、出典を明示する方が効果的です。 💡 **要点と詳細** 実践的な判定フローは以下の通りです。 1️⃣ 初期検索では広めに取得（概ねk=20〜50） 2️⃣ リランカーで関連性スコア順に並べ替え 3️⃣ スコアが閾値を超える文書のうち上位k件を投入 4️⃣ 投入後のトークン数がコンテキストウィンドウの50%を超えないよう制御 5️⃣ 超える場合は圧縮（要約）またはさらなる絞り込み 📊 目安値: - 初期検索の取得件数: 20〜50件（リランク用の候補プール） - リランク後の投入件数: 3〜8件（大半のユースケースで5件前後が出発点） - 検索枠のウィンドウ占有率: 20〜40%（50%超で圧縮検討） - チャンクサイズ: 200〜500トークン kの値は「件数の定数」ではなく「リランクスコアが閾値を超えた文書の件数（上限k件）」として動的に決めるのが理想です。高関連の文書が2件しかなければ2件だけ投入し、無理にk件まで埋めません。 ⚖️ **トレードオフ** 📉 top-kが小さすぎると — 回答に必要な情報が検索結果に含まれず、LLMが根拠なしに回答を生成します。特に複数文書からの情報統合が必要な場合（「A社とB社の比較」など）、1件では対応できません。取得件数が少ないと1件のノイズの影響も甚大で、k=2なら1件のノイズが50%を占めます。 📈 top-kが大きすぎると — "Lost in the Middle"問題が顕在化します。LLMはコンテキストの先頭と末尾に注意を集中させ、中盤の情報は実質的に無視される傾向があります。大量投入すると最重要情報が中盤に埋もれます。他の情報枠（システム指示・会話履歴・長期メモリ）も圧迫され、エージェント全体の振る舞いが劣化します。 🛠️ **ユースケース** ❓ **単純な事実質問**（「A社の設立年は？」）— k=2〜3で十分。単一の文書で回答可能なケースがほとんどです。 📊 **比較・分析質問**（「A社とB社の戦略の違いは？」）— k=5〜8が必要。複数ソースからの情報統合にはより多くの文書が必要です。クエリ分類器で場合分けすると効率的です。 🏥 **医療・法務の高精度Q&A** — 根拠の網羅性と出典の明示が両方求められる。初期検索を広く取りリランクで厳選、スコアの高い少数の文書を先頭または末尾に配置して"Lost in the Middle"を回避します。 リランカーを使わずにtop-kを増やすのは逆効果です。ベクトル検索の上位20件をそのまま投入するとノイズが大量に混入します。コンテキストウィンドウの使用率は常にモニタリングし、検索結果で投入した文書のうち実際に回答に使われた比率を追跡しましょう。使われない文書が多ければkを下げるか検索パイプラインの改善が必要です。 #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェントをソフトウェアに組み込むプラクティス # コンテキスト予算配分 🎯 「全部入れれば精度が上がる」は幻想です。コンテキストウィンドウは有限の予算として管理しましょう。 スロットごとに配分比率を決め、信号密度を最大化するパターンです。 🔥 解決する課題 RAGやメモリを使うエージェントでは、検索結果・会話履歴・システム指示・長期メモリが同じコンテキストウィンドウを奪い合います。情報を詰め込むほどコストは増え、会話が長くなるとシステム指示の割合が縮んで振る舞いが劣化します。さらに"Lost in the Middle"問題により、窓の中盤に置かれた重要な情報が実質的に無視されてしまいます。 💡 提案パターン コンテキストウィンドウをシステム指示・検索結果・会話履歴・メモリなどのスロットに分け、各スロットに最大占有率と優先度を設定します。システム指示は圧縮対象外の固定枠（10〜20%）として先に確保し、検索結果はリランク後にtop-k件に絞り、履歴は窓使用率が閾値を超えたら要約圧縮します。配置順序はLost in the Middle対策として、最重要情報を先頭に、直近入力を末尾に置きます。cost_sensitivityが高い環境ほどtop-kを絞り、圧縮閾値を下げ、履歴を短く保ちます。 ✅ 選定条件 使うとき： - RAGやメモリを使い、投入候補がモデル窓サイズの50%を超えうる - コスト感度が中以上で、投入トークンの増加がコストや推論時間に影響する - 複数ターンの会話で履歴が蓄積し、他の情報のスペースを圧迫する 使わないとき： - 投入情報がシステム指示＋単発入力のみで窓の30%未満に収まる場合 - ロングコンテキストモデルを使い投入量が窓の20%未満、かつコスト感度が低い場合 ⚠️ 落とし穴 - システム指示を圧縮対象にしてはいけません。ツール定義や安全指示が削られると振る舞いが壊れます - リランクなしのtop-kは信号密度が低いです。ベクトル検索上位20件からクロスエンコーダで3〜8件に絞りましょう - 要約圧縮は非可逆です。重要な決定事項や固有名詞が落ちるリスクがあるため、キーワード抽出を併用してください 🔧 実装方針 - コンテキストウィンドウをスロット（system/user/retrieval/history/memory）に分割し、各スロットに最大占有率・優先度・圧縮可否を定義した構造体で管理します - システム指示は圧縮対象外の最高優先度として先に確保し、残りの予算を他スロットに優先度降順で配分します - 検索結果はベクトル検索の上位候補をクロスエンコーダでリランクしてから予算内に収め、信号密度を最大化します - 履歴スロットが予算を超過した場合は要約圧縮を適用し、圧縮前にキーワード抽出して重要情報の欠落を防ぎます #AIエージェント# #ソフトウェアアーキテクチャ#

単一文書のQ&Aから、数千文書を横断する分析へ——10万社が使うBoxが、Deep Agentsで「AIネイティブ」に生まれ変わった事例です📦 タイトル: Building Box AI: How an Enterprise Content Platform Went AI-Native with Deep Agents URL: 📦 概要 コンテンツ管理プラットフォームBoxが、Deep Agentsを採用して高度な複数文書分析を実現した事例です。親の「Global Agent」がリクエストの意図を分類し、必要に応じて子エージェントをツールとして動的に生成する階層型システムを構築しました。 ❓ 解決する課題 当初のBox AIは単一文書のQ&Aや知識ハブが中心でした。 ・しかし顧客は、数千文書を横断した調査の統合や、契約書をリスクフレームに照らした分析を求めました ・こうした多段階・分野横断のタスクは、従来のRAGベース検索では扱いきれませんでした 💡 方法論と提案手法 ・親のGlobal Agentが意図を分類し、単純なものは自分で、複雑なものは子エージェントを動的に生成して処理します ・全エージェントが共通ツール（BM25・ベクトル検索・構造化Q&A・ファイル操作）にアクセスできます ・子エージェントは隔離コンテキストで動き、ミドルウェア経由で結果を報告します ・ミドルウェアが本番の要：引用生成、プロンプトキャッシング、17万トークン超で自動要約するコンテキスト管理 ・Deep Agents採用の理由は、モデル非依存（OpenAI/Anthropic/Google）と反復速度です 📊 実験結果 / 実績 ・新エージェントの投入が、数ヶ月から数週間に短縮 ・再帰的な親子システムは、当初の専門エージェント構成より4倍速く出荷 ・単純なクエリは子生成をバイパスし、不要なレイテンシを排除 #AIエージェント# #エンタープライズAI#

# ADKの便利で実践的な使い方 🔌 GitHub、Linear、Chroma、n8n — 既存のMCPサーバーをADKエージェントにそのまま統合できるMCP Toolsは、ツールエコシステムへの最速の接続手段です。 📌 タイトル：MCP Tools — MCPサーバーとの統合 🔗 URL： 🧩 概要 ADKのMcpToolsetは、Model Context Protocol（MCP）サーバーのツールを自動検出し、ADKエージェントのツールとして利用可能にします。Stdio、SSE、Streamable HTTPの3つのトランスポートに対応し、GitHub MCP、Linear MCP、Chroma MCP、n8n MCPなど、既存のMCPサーバーエコシステムをそのまま活用できます。GKEではサイドカーパターンでのデプロイも可能です。 🛠 使い方 各トランスポートでのMcpToolsetの設定例です。 Stdioトランスポートでは、` から `McpToolset` と `StdioServerParameters` をインポートし、`McpToolset(connection=StdioServerParameters(command="npx", args=["-y", "@modelcontextprotocol/server-github"], env={"GITHUB_TOKEN": "ghp_..."}))` のようにローカルプロセスとしてMCPサーバーを起動します。作成した `McpToolset` インスタンスを `Agent` の `tools` リストに渡すだけで、GitHub MCPサーバーのツールがエージェントから利用可能になります。 SSEトランスポートでは、`SseServerParams` を使い、`McpToolset(connection=SseServerParams(url="http://localhost:3001/sse"))` のようにリモートサーバーのSSEエンドポイントに接続します。 Streamable HTTPトランスポートでは、`StreamableHTTPServerParams` を使い、`McpToolset(connection=StreamableHTTPServerParams(url="http://localhost:3001/mcp"))` のように最新のHTTPベースで接続します。 🏗 実践的な使い方 **MCPサーバーの選択と組み合わせ**: プロジェクト管理にはLinear MCP、コード管理にはGitHub MCP、ベクトル検索にはChroma MCP、ワークフロー自動化にはn8n MCPを組み合わせることで、強力な開発支援エージェントを構築できます。 複数のMCPサーバーを組み合わせるには、GitHub用の `McpToolset` を `StdioServerParameters(command="npx", args=["-y", "@modelcontextprotocol/server-github"])` で、ベクトルDB検索用の `McpToolset` を `StdioServerParameters(command="uvx", args=["chroma-mcp"])` でそれぞれ作成し、両方を `Agent` の `tools` リストに `tools=[github_tools, chroma_tools]` として渡します。これにより、1つのエージェントからGitHub操作とChromaベクトル検索の両方が利用可能になります。 **GKEサイドカーパターン**: Kubernetes環境では、MCPサーバーをサイドカーコンテナとしてPodに配置し、localhostでStdio/SSE接続することで、ネットワーク遅延を最小化しつつセキュアな通信を実現できます。 **ツールの自動検出**: McpToolsetはMCPサーバーが公開するツールを自動検出するため、サーバー側でツールが追加された場合、ADK側のコード変更なしに新しいツールが利用可能になります。 💡 ユースケース 🐙 GitHub MCPでIssue/PR管理を自動化 📋 Linear MCPでプロジェクトタスクの追跡と更新 🔍 Chroma MCPでRAGベースの知識検索 🔄 n8n MCPでワークフロー自動化との連携 ⚠️ 注意点 - MCPサーバーのプロセス管理に注意してください。Stdioの場合、エージェント終了時にMCPプロセスも適切にクリーンアップする必要があります。 - MCPサーバーが公開するすべてのツールがエージェントに見えるため、不要なツールが多いとLLMの判断が複雑になります。 - 外部MCPサーバーのセキュリティ（認証トークンの管理、通信の暗号化）には十分注意してください。 ✨ MCP Toolsを使えば、豊富なMCPエコシステムのツールをADKエージェントにワンステップで統合できます。車輪の再発明をせず、既存のツールを最大限活用しましょう！ #ADK# #AIAgent#

# AIエージェントをエンタープライズシステムに組み込む意思決定ポイント # ツール露出数｜Tool Exposure 🎯 ポイント エージェントに使えるツールを「とりあえず全部渡す」設計になっていませんか？ 実はLLMが一度に見渡せるツール数には認知的な限界があり、10〜20が安定ゾーン、30を超えると選択精度が有意に落ちます。ツールが多いほどモデルは「正しいツールを選ぶ」という認知負荷に晒され、誤選択やトークン浪費が増えていきます。SaaS連携が増えるエンタープライズ環境では、この制御が品質の生命線です🎛️ 📋 概要 ツール露出数とは、エージェントに一度に見せるツール（関数・API）の数を制御する程度のことです。多すぎるとモデルの選択精度が落ち、少なすぎるとユーザーの要求に応えられません。「どんな要求にも対応できる」と「正確にツールを選べる」は本質的にトレードオフの関係にあり、業務ドメインやユースケースに応じて意図的に設計する必要があります。ツールの「量」だけでなく、ツール説明（description）の「質」も選択精度に直結する点を見落とさないでください。 🔍 意思決定のポイント このダイヤルは「ツール数の規模」と「ツール説明の品質」の2軸で決めます。 ツール数が10〜20 → 静的定義で十分。グルーピングで管理可能 ツール数が20〜30 → ドメイン別のサブエージェント分割を検討 ツール数が30超 → Tool RAG（動的選択）またはルーター＋サブエージェント＋Tool RAGのハイブリッド構成が必須 ツール数を減らす前に、まずツール説明の品質を見直すことが重要です。名前が動詞＋名詞で一意か、「いつ使うか・使わないか」が明記されているか、引数の型・制約・デフォルト値が明示されているか。ここが曖昧だとツールを絞っても誤選択は減りません⚡ 💡 要点と詳細 ツール数が増えた場合の3つの対処パターンがあります： Tool RAG（動的選択） — ユーザーの発話をベクトル検索し、関連ツール上位N件だけをプロンプトに注入します。SalesforceやServiceNowのようにAPIが数百に及ぶSaaS連携では必須に近い手法です。 サブエージェント分割 — 業務ドメインごとにサブエージェントを分け、ルーターが振り分けます。「人事系（Workday）」「ITヘルプデスク（ServiceNow）」「営業支援（Salesforce）」のように明確に分割できるケースで有効です。 ハイブリッド — ルーターでドメイン分割した上で、各サブエージェント内でもTool RAGを使う二段構成です。超大規模統合で採用されます。 計測すべき指標は、ツール選択正答率（正しいツールが呼ばれた割合）、ツール未選択率（適切なツールがあるのに「できません」と回答した割合）、誤選択によるエラー率、そしてツール説明のトークン消費量です。ツール説明がコンテキストの20%を超えたら、Tool RAGへの移行を本格検討してください📊 ⚖️ トレードオフ ツールを多く公開しすぎると、モデルの選択精度が低下します。名前や説明が似たツールが増えるほど誤選択の頻度が上がり、ツール説明のトークン消費がコンテキスト予算を圧迫します。ユーザーの要求に対応できる幅は広がりますが、「間違ったツールを選ぶ」リスクが確実に増大します😰 一方、ツールを絞りすぎると、ユーザーが「できるはずのこと」を断られる場面が増えます。体験品質が低下し、エージェント導入の価値が問われます。さらにツール追加のたびに分割設計の見直しが必要になり、開発速度も落ちます。重要なのは選択正答率90%を維持しつつ、fallback率5%以下を目指すバランスです⚠️ 🛠️ ユースケース Slack社内統合ボット：初期はITヘルプデスク（5ツール）から始め、HR・経費・施設と段階的に追加します。15ツールを超えた時点でTool RAGを導入し、選択精度を維持します。最終的に30ツール超の統合も、ルーター＋Tool RAGのハイブリッドで安定運用できます📚 Zendesk顧客対応エージェント：FAQ検索・チケット作成・ステータス確認・エスカレーションの4ツールに絞り、選択精度95%以上を維持します。顧客対応では誤ったツール呼び出しが直接的な体験毀損につながるため、少数精鋭が正解です🎯 Jira＋Confluence＋GitHub開発支援：各サービス5〜8ツール、合計20前後。サービスごとにサブエージェントを分割し、ルーターが「これはJiraの話か、GitHubの話か」を判断して振り分けます。ツール追加は該当サブエージェント内で完結するため、他に影響を与えません🔧 実践のコツ：ツール選択正答率が90%を下回ったらツール数の削減かTool RAG導入を検討し、新ツール追加のたびに既存ツールとの名前・説明の重複をチェックしてください。調整は週次のeval結果をもとに行い、一度に大幅な変更は避けるのが安全です💪 #AIエージェント# #エンタープライズアーキテクチャ#