Strands と Exa で Web Search Agent を作る方法（2026）

Q: 最初から deep search mode を使うべきですか？

通常は不要です。最大 coverage が明確に必要で、latency を許容できる場合を除き、auto から始めます。deep-reasoning は、reviewer、cost budget、simple retrieval が重要 source を落としている理由があるときだけ使ってください。

まず結論

毎回 messy な browser scrape にせず、live web を検索できる AI agent が必要なら、Strands + Exa はいま実用的にコピーしやすい構成です。

重要なのはニュース見出しそのものではありません。AWS が 2026-05-11 に公開した記事が示したワークフローです。Strands に agent loop を任せ、Exa に web search と page extraction を任せ、最後に人間がレビューできる範囲までタスクを狭めます。

2026-05-13 時点では、この構成は research brief、fact-checking、market scan、competitor monitoring に向いています。一方で、source completeness を保証する必要がある仕事、重い spreadsheet logic、または大規模にゼロコストで回したい用途には向きません。Exa は有料 API であり、live web search には自然にノイズが入るからです。

2026-05-11 の更新で何が変わったか

AWS は 2026-05-11 に公式記事を公開し、Exa search tools を Strands Agents SDK に接続する方法を示しました。これにより、「agents can browse the web」という曖昧な話が、実装できるパターンになりました。

パターンは単純です。

Strands が agent loop を動かす。
Exa が semantic search と content extraction を提供する。
モデルが、いつ検索し、いつ full page を取得し、いつ止まるかを決める。

内部 AI workflow を作るチームにとっては、一般論よりもこの役割分担の方が役に立ちます。

この構成が向いている条件

次の条件の多くが当てはまるなら、Strands + Exa を検討できます。

uploaded files だけでなく、current web information が必要
agent に実 URL を citation または source として出させたい
タスクを research、validation、structured summarization として定義できる
business action の前に最終出力を人間がレビューできる
generic な snippet-heavy search API より agent 向きの検索入力がほしい

逆に、次のような場合はまだ避けた方が安全です。

financial、legal、compliance completeness が必要
毎回 deterministic で同一の出力が必要
有料依存を増やしたくない
チームが「良い回答」の基準を決めていない
自社文書だけを対象にする通常の RAG の方が向いている

各パーツが実際に担うこと

パーツ	役割	なぜ重要か
Strands Agents	agent loop と tool calling を動かす	workflow glue を減らし、いつ tool を使うかをモデルに任せられる
Exa `exa_search`	semantic search と filter で関連 source を探す	raw search snippet より agent workflow の出発点として使いやすい
Exa `exa_get_contents`	agent が見つけた URL から page text を取得する	title だけでなく実際の page content を扱える
System prompt	scope、source preference、output format を定義する	品質改善の多くはまだここで決まる

Exa の公式 search API docsで重要なのは、search API が複数の search type を持つことです。auto、fast、instant、neural、deep-lite、deep、deep-reasoning に加え、category や domain などの filter も使えます。つまり、すべてのタスクに同じ検索戦略を使う必要はありません。

始める前に必要なもの

接続する前に、次を確認してください。

項目	確認すること	なぜ重要か
Python	Python 3.10 以上	AWS 記事と Strands SDK setup はこの前提で書かれている
Model provider	Bedrock、OpenAI、Anthropic、Gemini、または対応 provider	Strands は model-agnostic だが、実際の model backend は必要
Bedrock access（AWS path を使う場合）	AWS credentials、model access、対応 region	Bedrock が selected model を呼べないと、search の前に script が失敗する
Exa API key	Exa dashboard の有効な key	key がないと search tools は動かない
Packages	`strands-agents` と `strands-agents-tools`	Exa integration は tools package に入っている
狭いタスク	成功基準が明確な research question	広すぎる prompt はすぐ高コストで雑になる

最短で安全にセットアップする

Step 1: package をインストールする

clean environment を作り、AWS の例で使われている 2 つの package を入れます。

python3 -m venv .venv
source .venv/bin/activate
pip install strands-agents strands-agents-tools

Step 2: Exa API key を設定する

Exa docs と AWS tutorial はどちらも EXA_API_KEY environment variable を使っています。

export EXA_API_KEY="your_exa_api_key_here"

team で secrets manager や CI runner を使っているなら、key は script に直書きせず、そちらに置いてください。

Step 3: 境界のある research task から始める

最初から「research anything about AI」とは頼まないでください。

終点が見えるタスクから始めます。たとえば次です。

3 つの competitor の latest product announcements を比較する
1 つの API change に関する最新 official docs を探す
狭い category における recent vendor moves をまとめる
product brief 用に source-backed notes を集める

悪い最初のタスクはこうです。

monitor the entire market and tell me what matters

このタイプの prompt は token を消費し、検索しすぎ、最後は曖昧な答えになりがちです。

Step 4: Exa tools を登録する

公式例の最小 setup は短いです。

from strands import Agent
from strands_tools.exa import exa_search, exa_get_contents

agent = Agent(tools=[exa_search, exa_get_contents])

Strands が tool signatures を読み取り、loop の中で各 tool をいつ呼ぶかを決めるため、これで動きます。

Step 5: scope を絞る prompt を使う

最初の prompt では、source preference、time window、output structure を指定します。

You are a research assistant for product and strategy work.

Task:
- Find official or primary sources about recent changes in AI coding agents.
- Prefer official company blogs, docs, release notes, and GitHub repositories.
- Focus on changes published in the last 14 days.
- Avoid duplicate reporting of the same announcement.

Return format:
1. Key updates
2. Why each update matters
3. Source list with URLs
4. Open questions or gaps

これは generic な「search the web and summarize trends」より、かなり良い出発点です。

コピーして使える starter script

AWS 記事は Bedrock ベースの例を示しており、Strands の official repo も、AWS credentials がある場合は Bedrock が default provider だと説明しています。次の script はその流れに近く、タスクの範囲も実用的に絞っています。

実行前に、選択した region で selected Bedrock model を AWS profile が呼べることを確認してください。account でその model が有効になっていない場合は、Exa tools を疑う前に model_id と region_name を変更します。

from strands import Agent
from strands.models.bedrock import BedrockModel
from strands_tools.exa import exa_search, exa_get_contents

model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-6",
    region_name="us-west-2",
    max_tokens=8000,
)

agent = Agent(
    model=model,
    tools=[exa_search, exa_get_contents],
    system_prompt="""
You are a research agent.
Prefer official sources, product docs, release notes, and GitHub repos.
Use web search only when needed.
When multiple articles repeat the same announcement, keep the primary source.
End with a concise brief and a source list.
""",
)

question = "Find the most important official updates in AI coding agents from the last 14 days and summarize what changed for technical teams."

response = agent(question)
print(response)

自分の stack に合うなら、Bedrock を別の Strands-supported model provider に置き換えて構いません。重要なのは Bedrock そのものではなく、search と page retrieval を separate tools として保つことです。1 つの不透明な prompt に隠さないでください。

Exa search mode の選び方

この選択は cost と output quality の両方に効きます。Exa の現在の docs には、AWS example の簡略表現より多くの mode があるため、最初の deployment は保守的に始めます。

Mode	向いている用途	トレードオフ
`instant`	voice や live suggestion flow	latency は最小、depth は弱い
`fast`	1 つの workflow 内で繰り返す agent tool calls	速いが、深い search より coverage は弱い
`auto`	ほとんどの初回 deployment	Exa に search path を選ばせるので、returned cost と source quality を確認する
`neural`	source 重視の通常 semantic retrieval	deep modes より浅い
`deep-lite`	難しめの question に対する軽量 synthesis	simple retrieval より latency と cost が増える
`deep`	難しい research や competitive scans	通常 `neural` より遅く高コスト
`deep-reasoning`	missed context のコストが高い research	最も深い選択肢なので reviewed workflow に限定する

迷うなら auto から始めます。missed-source risk が追加 latency と API cost を上回るときだけ、deep または deep-reasoning に移ります。本番の cost control では、mode 名だけで推測せず、Exa が返す cost fields を log してください。

最初に試しやすい用途：competitor update brief

この構成が本当に役立つのはここです。

AI coding tools を追う product team の weekly workflow を想像してください。agent は次を実行できます。

recent official announcements を検索する
最も relevant な pages を取得する
重複 reporting を除く
URL と open questions を含む短い brief を返す

freeform research prompt より良い prompt は次です。

You are preparing a weekly competitor brief.

Focus:
- AI coding agents
- official product announcements only when possible
- changes published in the last 7 days

For each item, return:
- company or product name
- what changed
- who should care
- one practical implication for a dev tools team
- source URL

Do not include rumors, fundraising news, or commentary unless it changes product availability.

この use case が向いている理由は明確です。

time window が明確
source preference が明確
duplicate reporting が多く、Exa の retrieval step が役立つ
誰かが行動する前に出力を review できる

agent が雑にならないようにする

web-enabled agent は、制約されているときだけ役に立ちます。

初日から次の guardrails を入れてください。

prompt で official domains を優先させる
7、14、30 日など実際の time window を指定する
毎回 URL を出させる
facts と open questions を分けさせる
最終 format は本当に review できる短さにする

簡単な acceptance checklist も有効です。

回答に primary URLs が含まれているか
duplicate coverage をまとめているか
古い explainer ではなく current pages を取得しているか
manual review が必要な unsupported claims があるか

この構成がまだ失敗するところ

news-driven な記事では、この部分がよく抜けます。

Live search にはまだノイズがある

検索 layer が良くても、mixed-quality pages、stale commentary、topic に触れているだけで本当の source ではない pages が返ることがあります。

好奇心は cost を増やす

agent が検索し、fetch し、再確認する回数が増えるほど、tokens と API cost は増えます。粗い prompt は、小さな brief を長い tool call chain に変えてしまいます。

Search は compliance record ではない

source-backed answer は uncited answer より良いですが、legal、finance、audit-grade process ではありません。

Full-page extraction は full understanding ではない

exa_get_contents は model により多くの context を渡します。それでも model は page を読み違えたり、nuance を圧縮しすぎたり、前の version から何が変わったかを見落としたりします。

別の方法を使うべきとき

Strands + Exa は、すべての research workflow の最適解ではありません。

需要	より良い starting point	理由
自社文書だけから回答する	internal corpus 上の RAG	live web search は不要な noise を足す
人間向け research chat と manual browsing	Perplexity または通常の browser workflow	setup が少なく、非開発者にも簡単
深い spreadsheet-heavy analysis	Python notebook と manual sources	agent loop が難所ではない
low-cost high-volume monitoring	feed processing と rules	always-on agent search はすぐ高コストになる

AWS official post：2026-05-11 announcement、two-tool Exa integration shape、prerequisite list、sample Bedrock model path を確認：https://aws.amazon.com/blogs/machine-learning/building-web-search-enabled-agents-with-strands-and-exa/
Strands Agents official site と GitHub repo：Python 3.10+、package names、Bedrock default guidance、multi-provider support を確認：https://strandsagents.com/ と https://github.com/strands-agents/sdk-python
Exa official API docs：search endpoint、supported search types（auto、fast、instant、neural、deep-lite、deep、deep-reasoning）、categories、returned cost fields、API key usage を確認：https://exa.ai/docs/reference/search