Anthropicのリリースノートを眺めていたら、5月18日のアップデートで気になる一行を見つけた。ウェブ検索ツールがSECフィリングのデータをより豊富に返せるようになった、というやつだ。
自分は最近、決算情報を拾ってきてサマリーを出すエージェントを個人開発で触っていた。IRページのスクレイピングって意外と面倒で、PDFの構造が会社ごとにバラバラだし、引用元を正確に残すのも手間がかかる。そこをClaude APIのウェブ検索ツールが「primary sources with citations」付きで返してくれるなら、自分のコードのかなりの部分が不要になる。
今まで自分がやっていた実装はこんな感じだった。SEC EDGARのAPIを直接叩いてフィリングのURLを拾い、テキストを取得してからClaudeに渡す、という流れ。これだけで前処理コードが100行以上あった。
これがウェブ検索ツールにSECデータ対応が入ったなら、エージェント側でクエリを投げるだけで引用付きの一次ソース情報が返ってくる可能性がある。前処理パイプラインのコードを丸ごと捨てられるかどうか、まず検証したいと思っている。
5月12日のアップデートで、Fast modeがClaude Opus 4.7に対応した。`speed: "fast"`と`model: "claude-opus-4-7"`を組み合わせる形で、プレミアム価格ではあるけど出力トークン生成が大幅に速くなる。
リアルタイムに近い速度で決算情報を引っ張ってくるエージェントを作るなら、Fast mode + SECデータ対応の検索ツールという組み合わせは素直に魅力的だ。ただ、Fast modeはウェイトリスト制になっているので、まずウェイトリストに登録しないといけない。
5月13日のキャッシュ診断（cache diagnostics）も地味に使える。`diagnostics.previous_message_id`を渡すと`cache_miss_reason`が返ってきて、プロンプトキャッシュのプレフィックスがどこでズレたか分かる。複数ターンのエージェントループを書いていると、「なんかキャッシュが効いていない気がする」って状況が普通に起きるので、これはデバッグに直結する話だ。
今の自分のエージェント実装でキャッシュが思ったより効いていないケースがあった。原因が特定できずにいたけど、`cache-diagnosis-2026-04-07`ベータヘッダーを付けてリクエストすれば診断情報が取れるらしいので、来週これをまず試してみるつもりだ。キャッシュのズレを直すだけでAPIコストが結構変わると思っている。
自分は最近、決算情報を拾ってきてサマリーを出すエージェントを個人開発で触っていた。IRページのスクレイピングって意外と面倒で、PDFの構造が会社ごとにバラバラだし、引用元を正確に残すのも手間がかかる。そこをClaude APIのウェブ検索ツールが「primary sources with citations」付きで返してくれるなら、自分のコードのかなりの部分が不要になる。
具体的にどこが変わるか
今まで自分がやっていた実装はこんな感じだった。SEC EDGARのAPIを直接叩いてフィリングのURLを拾い、テキストを取得してからClaudeに渡す、という流れ。これだけで前処理コードが100行以上あった。
# 以前のアプローチ（前処理がとにかく多い）
response = edgar_api.get_filing(cid=company_id, form_type="10-K")
raw_text = extract_text_from_xbrl(response.body)
chunked = split_by_token_limit(raw_text, limit=50000)
result = claude_client.messages.create(model="claude-opus-4-7", ...)これがウェブ検索ツールにSECデータ対応が入ったなら、エージェント側でクエリを投げるだけで引用付きの一次ソース情報が返ってくる可能性がある。前処理パイプラインのコードを丸ごと捨てられるかどうか、まず検証したいと思っている。
同時期の他アップデートも組み合わせると面白い
5月12日のアップデートで、Fast modeがClaude Opus 4.7に対応した。`speed: "fast"`と`model: "claude-opus-4-7"`を組み合わせる形で、プレミアム価格ではあるけど出力トークン生成が大幅に速くなる。
リアルタイムに近い速度で決算情報を引っ張ってくるエージェントを作るなら、Fast mode + SECデータ対応の検索ツールという組み合わせは素直に魅力的だ。ただ、Fast modeはウェイトリスト制になっているので、まずウェイトリストに登録しないといけない。
5月13日のキャッシュ診断（cache diagnostics）も地味に使える。`diagnostics.previous_message_id`を渡すと`cache_miss_reason`が返ってきて、プロンプトキャッシュのプレフィックスがどこでズレたか分かる。複数ターンのエージェントループを書いていると、「なんかキャッシュが効いていない気がする」って状況が普通に起きるので、これはデバッグに直結する話だ。
今の自分のエージェント実装でキャッシュが思ったより効いていないケースがあった。原因が特定できずにいたけど、`cache-diagnosis-2026-04-07`ベータヘッダーを付けてリクエストすれば診断情報が取れるらしいので、来週これをまず試してみるつもりだ。キャッシュのズレを直すだけでAPIコストが結構変わると思っている。