Deep Researchをプラグイン可能な能力にする：NVIDIA AI-Q Skillが企業Agentアーキテクチャへ示すもの

2026年5月20日、NVIDIAはAI-QのDeep Research能力を、Claude Code、Codex、OpenCodeなどのagent harnessから呼び出せる「専門skill」としてpackage化する方法を紹介する技術記事を公開しました。重要なのは「AI toolがまた一つ増えた」ことではなく、企業Agentをより明確に階層化する方法を示した点です。汎用agent harnessは会話、tool orchestration、コード実行、ユーザーとのやり取りを担い、専門research backendは複数sourceの検索、計画、統合、引用、評価、企業データgovernanceを担います。(NVIDIA Developer)

1. 背景：汎用AgentがDeep Researchを直接担うべきでない理由

Claude Code、Codex、LangChain Deep Agentsのようなharnessは、開発者の対話入口に適しています。会話を維持し、toolを呼び、コードを実行し、ユーザーの意図を行動の列へ変えられます。しかしタスクが「複数の企業文書、内部データベース、外部資料、規制対象のデータsourceに基づき、引用つきの調査reportを作る」になると、複雑さは「数個のtoolを呼ぶ」から「完全な調査pipelineを構築する」へ急速に高まります。NVIDIAは、企業teamがデータ接続、認証、query routing、prompt調整、出力評価、引用の忠実性に対応する必要があり、各harnessで繰り返し実装すべきではないと明記しています。(NVIDIA Developer)

AI-Q Skillは、このためにあります。Deep Researchを移植可能なagent skillとしてpackage化し、harnessは調査タスクをローカルまたはhosted AI-Q serverへ提出して、構造化された引用つきreportを待つだけです。調査pipelineは企業が管理する環境内で動き続けるため、機密性のある生データを外部agent harnessへ公開する必要がありません。(NVIDIA Developer)

背景には重要なエンジニアリング判断があります。Deep Researchは「より長いprompt」ではなく、システムエンジニアリングです。タスク分類、明確化、検索、計画、反復、統合、引用検証、アクセス制御、非同期job管理、可観測性、評価loopが必要です。汎用Agentにその場で組み立てさせず、専門backendとして扱うほうが、企業導入には堅実です。

2. 中核概念：Harness、Skill、Research Backendの責務境界

このアーキテクチャでは、agent harnessが入口層です。開発者や業務ユーザーに向き、requestを理解し、contextを管理し、toolを呼び、結果を表示します。Skillは能力宣言層で、通常はSKILL.mdと補助scriptから構成され、いつ、どう能力を呼び出すかをharnessへ伝えます。research backendは実行層で、実際の調査flow、データaccess、report生成を担います。

NVIDIA AI-Qのskill packageは.agents/skills/aiq-research/にあります。install rootにSKILL.mdが必要で、scripts/aiq.py helperが/chat requestのrouting、非同期Deep Research jobの提出、status polling、report取得を行います。AI-Q文書にはClaude Code、Codex、OpenCode向けinstall pathの例もあります。(GitHub)

この分離には複数の利点があります。第一に、harnessが企業検索、RAG、MCP、認証、引用検証の詳細を知る必要がありません。第二に、一つのAI-Q serverを複数harnessで再利用できます。第三に、データaccess、監査、model routingを各開発toolやIDE pluginへ分散せず、管理されたbackendへ集中できます。

呼び出しの流れは次のように理解できます。

ユーザー / 開発者
    ↓
Agent Harness: Claude Code / Codex / OpenCode / Deep Agents
    ↓
AI-Q Research Skill: SKILL.md + scripts/aiq.py
    ↓
AI-Q Server: /chat + 非同期Deep Research job
    ↓
Research Pipeline: intent → clarify → shallow/deep research → 引用に裏づけられたreport
    ↓
引用つきの構造化report

3. AI-Qの調査Pipeline：一つのAgentではなく、評価可能なAgent群

AI-Qは大規模modelへ検索toolを接続しただけではなく、多段階の調査システムです。NVIDIA AI-Q BlueprintはNVIDIA NeMo Agent Toolkitを基盤とし、LangChain Deep Agentsを使います。素早い引用つき回答と、より深いreport形式の調査出力の両方を生成でき、benchmarkとevaluation harnessを内蔵して品質を継続的に測れます。(GitHub)

アーキテクチャ上、AI-QはLangGraphベースの状態機械を使い、intent classifier、shallow researcher、deep researcherを中核とします。intent classifierはrequestがmeta型かresearch型かを判断し、さらにshallow researchとdeep researchのどちらへ進むか決めます。shallow researcherは高速で範囲の明確なtool強化検索、deep researcherは複数段階、長時間、計画と引用管理を伴う調査に適しています。(GitHub)

詳しくは、Intent Classifier、Clarifier Agent、Shallow Researcher、Deep Researcherと、それらを調整するChat Researcher Orchestratorへ分かれます。Clarifier Agentは特に重要です。deep researchの開始前にhuman-in-the-loopで計画を作り確認し、質問が不明確なまま高コストの検索と長文report生成へ入ることを防ぎます。(GitHub)

Deep Researcher内部はorchestrator、planner、researcher subagentで構成されます。NVIDIAの説明では、orchestratorがplannerを呼び調査計画を作り、plannerが検索して根拠あるoutlineを構築します。その後orchestratorがデフォルト二回の調査loopでresearcherへquery実行、関連内容の統合、draft更新、gap発見を割り当て、最後にcitation catalogとreportを生成します。(NVIDIA Docs)

AI-Qの「深度調査」は小規模な調査teamに似ています。タスク種別を判断する役、要件を明確化する役、素早く検証する役、体系的に計画する役、テーマ別に検索する役、reportと引用を統合する役があります。「単一Agent + 検索tool + 長いcontext」より、品質管理と障害箇所の特定が容易です。

4. 主要な革新：Deep ResearchをAgent Skillとして公開する

NVIDIA記事の最も重要な革新は、AI-Qの完全な調査pipelineをportable agent skillとして公開したことです。Claude Code、Codexなどの汎用agentは、稼働中のAI-Q serverへ調査タスクを提出し、整形された詳細な引用つきreportを受け取れます。skillはSKILL.mdとhelper scriptを含み、scriptがrequest routing、job提出、polling、結果取得を担います。(NVIDIA Developer)

単なるREST APIより一歩進んでいます。REST APIはprogrammer向け、skillはagent harness向けです。SKILL.mdはinterface文書だけでなく「能力仕様書」として、いつ能力を使い、どう呼び、何が返り、どの制限があるかをAgentへ伝えます。「ある規制テーマを調べ、社内policy文書からmemoを作る」のような自然言語で起動でき、harnessは検索やreport生成を自分で組み立てずAI-Qへ渡します。(NVIDIA Developer)

エンジニアリング上、skillは軽量ですが重要な「能力governance境界」です。社内knowledge base、複数sourceのfact check、compliance引用、長文report生成を含むタスクは必ずAI-Q research skillを通し、任意のagentが生データsourceを直接読まないよう規定できます。権限、監査、コスト制御、品質評価を集中できます。

5. 企業データ接続：MCPでAI-Qを既存システムへつなぐ

NVIDIAはMCP統合を特に強調しています。新しいAI-QはMCP clientとして認証済みMCP serverへ接続し、企業の既存システムをresearch pipelineのデータsourceとして公開します。AI-Q専用の並列検索stackを構築する必要がありません。三種類の認証modeとして、ユーザーごとの認証がないMCP server、backendまたはapplication credentialを使うMCP server、downstream APIがAI-Qユーザーのbearer tokenを信頼するcustom AI-Q toolを挙げています。(NVIDIA Developer)

MCP、Model Context Protocolは、AI applicationをlocal file、database、search engine、tool、workflowなどの外部システムへ接続するopen standardです。公式文書はMCPを「AI applicationのUSB-C interface」にたとえ、AI applicationと外部システムの統合複雑度を下げることを目的としています。(Model Context Protocol)

MCPはstdioとStreamable HTTPという二つの標準transportを定義します。企業環境ではStreamable HTTPがremote service、認証、複数client接続に適しています。MCP仕様はStreamable HTTP実装にOrigin headerの検証を要求し、local serviceを可能な限りlocalhostへbindし、適切に認証してDNS rebindingなどのriskを下げるよう求めています。(Model Context Protocol)

認証では、MCPのHTTP authorization仕様がOAuth 2.1、OAuth 2.0 Authorization Server Metadata、Dynamic Client Registration、Protected Resource Metadataに基づきます。保護されたMCP serverはProtected Resource Metadataでauthorization serverの場所を示し、MCP clientはmetadataからauthorization serverを発見します。(Model Context Protocol)

見落としやすい現実的な制限もあります。AI-Qがlogin済みユーザーのbearer tokenをdownstream APIまたはMCP gatewayへ転送するとき、job提出時にtokenを捕捉して非同期Dask workerで復元します。現行versionはjob実行中にtokenをrefreshしません。そのため調査タスクがaccess tokenのTTLを超えると、後続の認証つきtool callが失敗します。(NVIDIA Developer)

企業導入では重要です。Deep Researchは数分以上続く長いタスクになり得ます。access tokenのTTLが短い場合、設計段階でtoken refresh、job timeout、retry、権限低下、ユーザーの再認証を扱わなければ、重要な非同期段階で不安定になります。

6. デプロイ方式：データがある場所で調査システムを動かす

NVIDIA記事の別の重点は「researcher deployed where your data lives」です。AI-Q BlueprintはDocker ComposeとHelm chartsを提供し、同じblueprintを開発者のlaptop、localまたはcloud Kubernetes cluster、air-gapped data centerで動かせます。(NVIDIA Developer)

医療、金融、政府、製造では特に重要です。原文書と企業データを管理環境内へ残し、AI-Qが内部で検索、統合、report生成を行います。agent harnessは生データへ直接accessせず、引用つき出力だけを受け取ります。Nemotronなどのopen modelをNVIDIA NIMでlocal deployできる一方、cloudのfrontier modelも設定でき、コスト、compliance、性能に応じてmodel経路を選べます。(NVIDIA Developer)

AI-QのGitHub文書によれば、CLI、Web UI、非同期jobへ対応します。Web modeはbackend API serverとfrontend UIを起動し、Docker Composeはlocal no-auth setupにも使えます。(GitHub)

AI-Q APIはjob tracking、Dask scheduling、SQLite/PostgreSQL job store、SSE streaming、event replay、job cancellation、final report retrievalを含む非同期job能力も提供します。routeには/v1/jobs/async/submit、/v1/jobs/async/job/{id}/stream、/v1/jobs/async/job/{id}/cancel、/v1/jobs/async/job/{id}/reportがあります。(GitHub)

AI-Qはdemo chatbotではなく、製品へ統合できるbackend serviceです。長時間タスク、非同期実行、event stream、結果の永続化、本番database対応は、企業agent workflowに必要な能力です。

7. LangChain Deep Agentsとの関係

AI-QはLangChain Deep Agentsを置き換えるのではなく、専門的なresearch backendの中で利用します。公式文書はdeepagentsを長時間タスクagentを構築するharnessとし、task planning、file system context管理、subagent spawning、長期memoryを内蔵し、LangGraph runtimeによるdurable execution、streaming、human-in-the-loopも提供すると説明しています。(LangChain Docs)

AI-Q Deep Researcher文書も、create_deep_agentでagentを構築し、deepagents libraryでsubagent coordinationを管理すると明記しています。LangChain Deep Agentsが組み合わせ可能なagent runtime能力を提供し、AI-Qがそれを「企業Deep Research」向けの完全なblueprintへ組み込みます。(NVIDIA Docs)

開発者への示唆は、agent framework、agent harness、業務能力を混同しないことです。LangGraph、Deep Agents、NeMo Agent Toolkitはagent workflowを構築・実行する問題を解決し、AI-Q Research Skillは「企業Deep Researchを再利用可能な能力として他agentへ公開する方法」を解決します。

8. 最小構成でのAI-Q Skill統合手順

以下はteamがPOCを行うための簡略手順です。正確なコマンドは公式repositoryを基準にしてください。

まずAI-Q serverを準備します。

git clone https://github.com/NVIDIA-AI-Blueprints/aiq.git
cd aiq

./scripts/setup.sh

cp deploy/.env.example deploy/.env
# 编辑 deploy/.env，填入 NVIDIA_API_KEY、TAVILY_API_KEY、SERPER_API_KEY 等

./scripts/start_e2e.sh

AI-Q READMEによれば、./scripts/setup.shはPython仮想環境を作り、core dependency、frontend、benchmark、data sourceをinstallします。Web UI modeは./scripts/start_e2e.shでbackend API serverとfrontend UIを起動します。(GitHub)

次にAI-Q skillをharnessのskills directoryへinstallします。Claude Codeのrepo-local skillの場合：

mkdir -p .claude/skills
ln -s ../../.agents/skills/aiq-research .claude/skills/aiq-research

OpenCodeのユーザーlevel directoryは次のとおりです。

mkdir -p ~/.config/opencode/skills
cp -R .agents/skills/aiq-research ~/.config/opencode/skills/aiq-research

AI-Q agent skills文書によれば、Claude Codeは.claude/skills/、OpenCodeは~/.config/opencode/skills/を使います。CodexなどAgent Skills互換toolでは、対応するruntimeのskills directoryへaiq-researchをinstallし、SKILL.mdとscripts/aiq.pyを含めます。(GitHub)

APIからDeep Research jobを直接テストする場合は、次のような呼び出しを使います。

curl -X POST http://localhost:8000/v1/jobs/async/submit \
  -H "Content-Type: application/json" \
  -d '{
    "agent_type": "deep_researcher",
    "input": "Research the regulatory landscape for AI agents in financial services and produce a cited executive memo."
  }'

curl http://localhost:8000/v1/jobs/async/job/{job_id}/stream

curl http://localhost:8000/v1/jobs/async/job/{job_id}/report

AI-Q API文書によれば、deep_researcherは包括的なmulti-loop deep research、shallow_researcherは素早いsingle-turn researchに使います。job streamはjob.status、workflow.start、llm.chunk、tool.start、artifact.update、job.errorなどを出力します。(GitHub)

9. エンジニアリングの発展：企業はどう製品化すべきか

第一に、統一Research Skill Gatewayを作ります。各teamのClaude Code、Cursor、内部chatbot、Slack botを異なるデータsourceへ直接つなげず、「企業データを必要とするDeep Researchタスク」を統一gatewayへ入れます。Gatewayは認証、権限mapping、tenant isolation、rate limit、監査、model routing、コスト記録を担い、AI-Q serverは中核research runtimeになります。

第二に、Data Source Registryを作ります。AI-Qはdata source registryへ対応し、request payloadからweb、paper、enterprise、collaboration、knowledge-layerなどを選べます。Knowledge Layerはdocument ingestionとretrievalの差し替え可能な抽象も提供し、application codeを変えずbackendを交換できます。(GitHub)

第三に、MCP serverを企業システムの「管理されたtool層」とします。issue tracker、wiki、code repository、文書store、CRM、BI system、内部APIへの接続に適していますが、すべてのtool descriptionを最初からmodel contextへ入れてはいけません。多数のserverと数百・数千toolを持つhostが全definitionを最初に入れると、tokenを浪費し、遅延が増え、性能が下がるとMCP client best practicesは指摘します。progressive discoveryとprogrammatic tool callingがより拡張可能です。(Model Context Protocol)

第四に、評価をCI/CDへ組み込みます。AI-Q READMEはDeep Research Bench、FreshQAなどのevaluation pipelineを内蔵すると述べ、Deep Researcher文書はDeep Research BenchのRACE、FACT metricsでreportを評価すると説明します。(GitHub)

企業固有のgolden setとして、過去12か月の規制変更まとめ、競合のprospectus分析、内部incident review、顧客SLA risk判断などを追加できます。指標にはmodel scoreだけでなく、source recall、citation precision、unsupported claim ratio、freshness、latency、cost、auth failure rate、human override rateを含めます。

第五に、可観測性を優先します。NVIDIAによればNeMo Agent ToolkitはOpenTelemetry traceを出し、compliance teamがどのsourceを検索し、どう利用し、最終回答をどう生成したかを確認できます。OpenTelemetryはcloud-native software向けのopen-source observability frameworkで、trace、metric、logを収集します。(NVIDIA Developer)

Agentシステムではtraceは障害調査toolだけでなくgovernanceの基盤です。Deep Researchは最低でも、ユーザー、タスク、shallow/deepのroute、呼び出したMCP server、使用credential、読んだ文書、引用へ入ったsourceと拒否されたsource、各planner/researcher roundのtokenとlatency、最終reportの引用検証結果を追跡すべきです。

10. よくあるリスクと設計案

第一は権限漏えいです。AI-Qは生データを企業環境内へ残せますが、MCP serverの権限が広すぎる、service accountがユーザーを区別できない、downstream APIがrow-level securityを無視する場合、agentが越権accessする可能性があります。本番環境ではper-user authorizationまたは厳格にscopeしたservice accountを優先し、modelへ返す前にfield-level filterを行います。

第二は引用ハルシネーションです。AI-Qはcitation managementとcitation-backed reportを重視しますが、各引用が検索結果に本当に由来するか、引用段落が結論を支えるか、偽URLを生成していないか、古い文書を引用していないかをpost-processingで検査すべきです。AI-Qアーキテクチャ文書も、調査responseをdeterministicなpost-processing pipelineへ通し、実際の検索sourceと引用を照合してaudit trailを生成すると説明します。(GitHub)

第三は長時間タスクの不安定性です。Deep Researchは非同期、長時間、複数tool呼び出しのタスクで、token TTL、network timeout、search API rate limit、一時的model failure、worker restartの影響を受けます。AI-Q APIのjob status、SSE stream、event replay、cancel、final report endpointは基礎ですが、企業はjob idempotency、checkpoint restore、dead-letter queue、retry budget、ユーザー向けprogress summaryも追加する必要があります。(GitHub)

第四はコスト制御不能です。Deep Researchは複数回の検索、複数model呼び出し、長いcontextの統合、citation verificationを実行する可能性があります。request層でtask class、max loops、tool-call budget、source whitelist、model routing policy、cost ceilingを設定し、評価層では一回のtoken消費ではなく「受け入れ可能なreport一件当たりの平均コスト」を観測します。

第五はtool/contextの膨張です。MCP serverとtoolが増えるほどAgentのaction surfaceは複雑になります。contextを増やし続けるのではなく、tool階層化、必要時の発見、task routing、skill化を行い、「いつどの能力を使うか」をSkillまたはGateway policyへ明示的に符号化します。

11. 推奨する企業導入ロードマップ

第1段階はlocal POCです。すべての企業データへ接続せず、AI-Q server、skill呼び出し、shallow/deep routing、非同期job、report生成、引用表示を検証します。web search、paper search、少数の匿名化文書から始められます。

第2段階は管理されたデータ接続です。公開policy、製品文書、過去FAQ、開発RFCなど、低riskだが実在する業務knowledge baseを選びます。Knowledge LayerまたはMCP serverで接続し、権限、引用、更新頻度、検索品質を検証します。

第3段階は評価loopです。事実QA、比較分析、trend summary、compliance memo、内部文書統合を扱う50〜200件の代表タスクを作ります。prompt、model、retriever、data sourceを変更するたびに評価を実行し、品質、遅延、コスト、失敗種別を記録します。

第4段階は本番化です。Kubernetes/Helm、PostgreSQL job store、集中log、OpenTelemetry trace、secret management、tenant isolation、RBAC、DLP、audit report、人の承認flowを導入します。AI-Qは調査demoではなく、企業内部のResearch Capability Serviceになります。

第5段階は複数harnessでの再利用です。Claude Code、Codex、OpenCode、内部Web Chat、Slack bot、IDE pluginを、同じResearch Skill Gateway経由でAI-Qへ接続します。企業はDeep Research能力を一度だけgovernanceし、複数の開発・業務入口から再利用できます。

結論：Agentの未来は「一つの万能な頭脳」ではなく「管理可能な能力network」

NVIDIA記事の価値は、Deep Researchを強いchatbotと表現せず、再利用、deploy、認証、監査、評価が可能な企業能力へ分解したことです。汎用agent harnessが対話とorchestration、AI-Q skillが能力公開、AI-Q serverがDeep Research pipeline、MCPが企業データsourceへの接続、OpenTelemetryとevaluation harnessがgovernance loopを担います。

エンジニアリングteamへの最重要の示唆は、各Agentプロジェクトで不完全なresearch pipelineを作り直さないことです。Deep Researchを専門backend skillにし、標準skill、MCP、非同期API、統一governance層を通じて公開することが、本番品質のAgentシステムに近い方向です。