WebReaderAPIでn8n AIエージェントからWebページを読む

なぜHTTP Requestノードをツールとして使うのか？

このAPIに必要な処理をすでにすべて備えているからです。GETリクエスト1回、ヘッダー1つ、クエリパラメータ2つだけです。n8nのドキュメントには、HTTP Requestノードは通常のノードとしても、AIエージェントにツールとして接続しても実行でき、一部のオプションはツール形式でのみ存在すると記載されています。

インストールや更新が必要なものはなく、キーはワークフロー内ではなくn8nの認証情報ストアに保管されます。n8n専用のキーを発行しておけば、他のスクリプトとは別に使用状況を確認でき、そのキーだけを無効化できます。APIキーは複数作成できます（例：エージェントやプロジェクトごとに1つ）。ダッシュボードからいつでも失効できます。

モデルはどうやって読み取るURLを選ぶのか？

urlパラメータをモデルに定義させます。n8nは該当するパラメータフィールドの横にボタンを表示し、値をモデルに渡せるようにしています。n8nの$fromAI()関数を使って自分で式を書くこともできます。キー、説明、型、任意のデフォルト値を指定でき、たとえばキーurl、説明「The http or https address of the page to read」、型stringとします。

n8nのドキュメントによると、$fromAI()はAI Agentノードに接続されたツールでのみ動作します。ツールの説明も「Reads a public web page and returns its main content as Markdown」のように平易な言葉で書き、エージェントがいつ呼び出すべきか分かるようにします。

なぜOptimize Responseをオンにするのか？

ツールが返すものはすべてモデルのコンテキストに入るからです。Optimize Responseはツール専用のオプションで、モデルに渡すデータを削減します。JSONレスポンスタイプでは選択したフィールドだけを含められます。title、final_url、markdownを残し、それ以外は削除します。

長さはmax_charsでこちら側で制限できます。APIから出る前にMarkdownが切り詰められます。ノードのHTMLおよびTextレスポンスタイプには独自のTruncate Responseオプションがありますが、当社のJSONレスポンスではmax_charsのほうがシンプルな制御方法です。

スケジュール実行ワークフローでAPIを使うには？

HTTP Requestノードをツールではなく通常のノードとしてSchedule Triggerの後ろに置きます。urlを固定値で指定し（追跡している変更履歴や料金ページなど）、markdownフィールドを次のノードに渡します。ファイル、データベース、チャットメッセージ、または前回の実行結果との比較などです。

1回の実行でURLごとに1ページを読みます。ブラウザを使わないページなら、20ページを1日1回監視しても月に約600クレジットなので、10,000ページ（$3.75）で1年以上もちます。プリペイドクレジットに有効期限はありません。未使用のページは使うまでアカウントに残ります。

サイトが読み取りを拒否した場合はどうなりますか？

ノードがblocked_by_robotsやtarget_refusedなどのコードのエラーレスポンスを受け取ることがあり、課金は発生しません。当社はrobots.txtを尊重します。クローラーはWebReaderAPIとして名乗り、自身向けまたはすべてのロボット向けに書かれたルールに従い、サイトが禁止したページは読み取りません。拒否されたページは課金されません。エージェント内では、ツールがエラーを返すようにしてモデルが説明したり別のソースを試したりできるようにします。スケジュール実行ワークフローでは、エラーをログ記録するブランチに振り分けます。errorsページにはすべてのコードが掲載されています。

ワークフローを構築する前に呼び出しを試せますか？

curlレシピに示すように、ターミナルで同じ呼び出しをcurlで実行してください。そこで成功してn8nで失敗する場合は、原因はノード設定にあります。多くは認証情報の値にBearer プレフィックスがない、またはurlパラメータが空のままになっていることです。