MCP on KnightLiブログ

Firecrawlプロジェクト整理：AI Agent向けのWeb検索・スクレイピング・操作API

Wed, 15 Apr 2026 13:45:03 +0800

Firecrawl の位置づけは明確です。Webページを、AI Agentが扱いやすいデータに変換するためのツールです。単なるクローラースクリプトではなく、検索、単一ページのスクレイピング、サイト全体の巡回、ページ操作、構造化抽出、AgentワークフローをAPIとしてまとめ、モデルや自動化システムがWebページ内のノイズに悩まされにくくします。

01 何を解決するのか

多くのAIアプリケーションはWebページを読む必要があります。しかし実際のWebは扱いやすくありません。JavaScriptで描画されるページ、ポップアップ、ページネーション、ログイン状態、Bot対策、PDFやDOCXなどHTML以外のコンテンツ、本文とは関係のないナビゲーション、広告、スクリプト、スタイルが混在しています。

Firecrawl が解決しようとしているのは、この中間層の問題です。アプリケーションは「このページ/このサイト/このテーマのデータが欲しい」と指定するだけで、Firecrawlがページを開き、取得し、クリーニングし、LLMで使いやすいMarkdown、HTML、スクリーンショット、JSONとして返します。

この種のツールの価値は、「URLにリクエストできるか」ではありません。複雑なWebページを安定して使えるデータに変換できるかが重要です。RAG、AI検索、競合調査、自動資料収集、Webコンテンツ監視では、この層がシステム内の面倒な配管になりがちです。

02 主な機能

FirecrawlのREADMEでは、機能がいくつかの領域に分けられています。

Search：Webを検索し、検索結果ページの本文まで取得する。
Scrape：単一URLをMarkdown、HTML、スクリーンショット、構造化JSONに変換する。
Interact：ページを取得した後、プロンプトやコードでクリック、スクロール、入力、待機などを実行する。
Agent：欲しい情報を直接説明すると、Agentが自動で検索、遷移、結果の取得を行う。
Crawl：Webサイト配下の複数ページを取得する。
Map：Webサイト内のURLを素早く発見する。
Batch Scrape：大量のURLを非同期で一括取得する。

名前だけを見ると「スクレイピングサービス」に見えます。しかし機能全体を見ると、AIアプリケーションのデータ入口に近い存在です。検索は情報源を見つけ、スクレイピングは内容を整え、操作機能は動的ページを扱い、Agentは「情報を探す」という作業をさらに自動化します。

03 AI Agentに向いている理由

従来のクローラーは、URLが既知であり、ページ構造も理解していることを前提にする場合が多いです。しかしAgentの場面ではそうとは限りません。ユーザーは「ある会社の最新料金ページにあるプラン差分を調べて」と頼むだけかもしれません。システム側は自分で検索し、ページを開き、内容を比較し、出典を返す必要があります。

Firecrawlの Agent エンドポイントは、このようなタスクを想定しています。自然言語のプロンプトだけで動かすことも、指定したURL範囲に限定して動かすこともできます。構造化された結果が必要な場合は、schemaと組み合わせて固定フィールドで出力できます。

アプリケーション層にとっては、次の2つの利点があります。

Webサイトごとに個別のパーサーを書く必要がない。
返ってきた結果をLLM、データベース、後続の自動化フローに渡しやすい。

もちろん、すべてのカスタムクローラーを置き換えるわけではありません。制約が強く、高頻度で、大規模で、フィールドが非常に安定している取得タスクでは、専用の解析ロジックを書いたほうが安く、制御もしやすい場合があります。Firecrawlは、情報源が分散し、ページ構造が変わりやすく、AIワークフローに素早く接続したい場面に向いています。

04 MCP、CLI、インテグレーション

FirecrawlはAgent向けツールチェーンにも明確に寄せています。READMEにはMCP Serverの接続方法があり、AI coding agent向けのSkill/CLI初期化コマンドも用意されています。

つまり、バックエンドサービスからAPIとして呼ぶだけでなく、Claude Code、OpenCode、Antigravity、MCPクライアントなどのワークフローに直接入ることも想定しています。Agentに調査、Web取得、内容整理をよく任せる人にとっては、API呼び出しを手書きするより軽い導入方法です。

Zapier、n8n、Lovableなどのプラットフォーム連携も挙げられています。この方向性は実用的です。Webデータは必ずしもコードにだけ入るわけではなく、自動化テーブル、ローコードフロー、コンテンツ制作システム、社内ナレッジベースにも流れます。

05 オープンソース、セルフホスト、ライセンス境界

Firecrawlはオープンソースプロジェクトです。メインリポジトリは主に AGPL-3.0 でライセンスされています。READMEでは、SDKと一部のUIコンポーネントは MIT ライセンスであり、詳細は各ディレクトリのLICENSEファイルを見る必要があるとも説明されています。

ここは注意が必要です。クラウドサービスとして使うだけなら、主な関心はAPIコスト、安定性、コンプライアンス上の境界です。一方で、セルフホストして外部にサービス提供するなら、AGPL-3.0 の義務をきちんと確認する必要があります。

READMEでは、Webサイトのポリシー、プライバシーポリシー、利用規約を尊重するようにも注意しています。また、デフォルトで robots.txt に従うと説明されています。この種のツールは強力になるほど、コンプライアンスと取得範囲の設計を後回しにせず、最初からシステムに組み込む必要があります。

06 向いている場面

Firecrawlを優先的に検討したいのは、次のような場面です。

RAGシステム向けにWeb資料を取得し、きれいなMarkdownを直接得たい。
AI検索や調査アシスタントで、検索後にページ全体を読む必要がある。
JavaScriptが重いサイトを取得したいが、自前でブラウザクラスターを保守したくない。
競合、価格、ドキュメント、ニュース、採用ページなどの公開情報を監視したい。
MCPクライアントやAI coding agentにリアルタイムのWeb読み取り能力を追加したい。
クローラー基盤を先に作るのではなく、Webデータ製品を素早く検証したい。

あまり向いていない場面もはっきりしています。

対象サイトのフィールドが少なく、構造も安定していて、簡単なスクリプトで十分な場合。
取得量が非常に大きく、開発保守コストより実行コストのほうが重要な場合。
データソース、リトライ戦略、Bot対策への振る舞い、監査要件を細かく制御する必要がある場合。
ライセンスやコンプライアンス要件として、AGPLコンポーネントや外部クラウドサービスを導入できない場合。

07 短い判断

Firecrawlの価値は、「WebページからAIで使えるデータへ」という面倒な流れをプロダクト化している点にあります。検索、取得、クリーニング、操作、バッチ処理、Agent型の資料収集を1つのインターフェースにまとめているため、AIアプリケーション開発者には使いやすい選択肢です。

モデルに実際のWebページを読ませる必要がよくあり、特に情報源が分散し、構造が不安定で、MCPやAgentワークフローにも接続したいなら、Firecrawlはツール箱に入れておく価値があります。逆に、固定サイトから低コストで大量収集するだけなら、従来のクローラーや専用パーサーのほうが適している場合があります。

Hermes Agent とは: 概要、利点、クイックスタート、OpenClaw との比較

Sun, 12 Apr 2026 14:07:58 +0800

最近オープンソース AI エージェントに注目している場合、Hermes Agent は注目に値する新しいプロジェクトです。ヌース・リサーチ社によって発売されました。その中心的なセールスポイントは、「別のチャットシェルを作成する」ことではなく、長期記憶、スキルの蓄積、コンテキストファイル、MCP 拡張機能、メッセージゲートウェイ、およびサブエージェントの並列処理の機能を統合エージェント実行環境に統合しようとすることです。

公式 README から判断すると、Hermes Agent の目標は非常に明確です。ローカル CLI アシスタントのように、またはクラウドに常駐するパーソナルアシスタントのようにターミナル内で動作し、Telegram、Discord、Slack、WhatsApp、Signal などのチャネルを通じて継続的に話しかけることができます。この位置付けは、「コードアシスタント」、「自動化アシスタント」、「パーソナル AI ワークベンチ」を 1 つのシステムに組み合わせたいユーザーにとって、非常に魅力的です。

01 エルメス代理店紹介

Hermes Agent は、Nous Research が開発したオープンソースの自己改善型 AI エージェントです。 Nous Portal、OpenRouter、OpenAI、カスタム OpenAI 互換エンドポイントなど、複数のモデルプロバイダーをサポートします。また、ローカルターミナル、Docker、SSH、Daytona、Modal などのさまざまな実行バックエンドでの実行もサポートされます。

多くの「ツールを呼び出すことができるチャットボット」との最大の違いは、Hermes は 1 つのセッションでのツール呼び出しだけを重視するのではなく、セッション全体での継続的な機能構築を重視していることです。公式ドキュメントでは、このアイデアをいくつかの部分に分割しています。

永続メモリ: MEMORY.md および USER.md を通じて、環境、プロジェクト、およびユーザー設定に関する重要な情報を保存します。
スキルシステム: 複雑なタスクで学習したプロセスをスキルにまとめ、オンデマンドでロードします。
コンテキストファイル: AGENTS.md、SOUL.md、.cursorrules およびその他のファイルを自動的に読み取り、プロジェクト規約をセッションに直接挿入します。
MCP の統合: MCP 互換のツールサーバーに接続して、データベース、GitHub、ファイルシステム、クロールなどの機能を拡張できます。
メッセージゲートウェイ: CLI に加えて、Telegram、Discord、Slack、WhatsApp、Signal、電子メール、その他のポータル経由でも使用できます。

一言で要約すると、Hermes Agent は「メモリ、スキル、スケーラビリティ、およびマルチエンドアクセスを備えたユニバーサルエージェント操作層」に似ています。

02 そのメリットは何ですか?

1. CLI ワークフローとメッセージングワークフローの両方をカバーする

エージェントプロジェクトの多くは「端末内開発アシスタント」か「チャットプラットフォームロボット」のどちらかです。エルメスがやりたいのは、これら 2 つを融合することです。ターミナルで hermes を直接実行することも、ゲートウェイを起動して Telegram または Discord から同じアシスタントを継続することもできます。

このデザインの良いところは、エルメスが「コンピューターの前に座っているときにだけ使える」ということに限定されていないことです。クラウドまたは VPS に導入すると、常にオンラインのパーソナル AI アシスタントになります。

2.「長期使用」をより徹底して考える

ヘルメスは単にチャットやツールの調整を行うだけではなく、長期的な蓄積も重視しています。

無限のヒープコンテキストではなく、制限された永続メモリ。
成功したプロセスを保存して再利用できるスキルシステムがあります。
過去のセッションを検索し、セッション間の呼び出しを実行する機能。
プロジェクト内のコンテキストファイルを読み取ることができるため、プロジェクトの背景を毎回繰り返し説明する必要性が軽減されます。

これは、固定されたコードベース、固定されたワークフロー、固定されたチーム基準で繰り返し作業することが多いユーザーにとって重要です。これは、エージェントが「今回はあなたのために何かをしてくれる」だけではなく、徐々にあなたの環境をよりよく理解するようになるということを意味します。

3. MCP サポートにより拡張性が非常に強力になります

hermes の公式ドキュメントでは、MCP を明確にサポートしており、stdio と HTTP という 2 つのアクセス方法について説明しています。言い換えれば、外部システムにすでに MCP サーバーがある限り、Hermes は理論的には低コストでそれにアクセスできます。

これは、単一システムに対して毎回個別のプラグインを作成するよりも柔軟です。 MCP エコシステムに多数のツールを蓄積している人にとって、Hermes へのアクセスコストははるかに低くなります。

4. OpenClaw ユーザーに優しい

これはとても興味深いですね。 Hermes README には hermes claw migrate が直接提供されており、構成、メモリ、スキル、API キー、メッセージングプラットフォームの設定などを OpenClaw からインポートできることが記載されています。

これは、既存のエコロジーを完全に無視して車輪を再発明しているわけではなく、一部の OpenClaw ユーザーを潜在的な移行ターゲットとして明確にみなしていることを示しています。

03 すぐに始める方法

公式に推奨されている Hermes Agent のインストール方法は非常に簡単です。

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

公式の手順では、Linux、macOS、WSL2、Android の Termux がサポートされています。 README には、ネイティブ Windows はまだサポートされていないため、Windows ユーザーには WSL2 を使用することが推奨されていることが明記されていることに注意してください。

インストールが完了したら、通常は最初にシェルを更新します。

`1`	`source ~/.bashrc`

その後、直接開始できます。

hermes

段階的に完全な初期化を完了したい場合、最も心配のないコマンドは次のとおりです。

`1`	`hermes setup`

公式ドキュメントと README によると、初めて開始するには次の手順に従うことができます。

hermes setup を実行して、基本構成を完了します。
hermes model を使用して、モデルプロバイダーとモデルを選択します。
hermes tools スイッチにはツールセットが必要です。
hermes を直接実行して対話型 CLI に入ります。
Telegram や Discord などのチャネルに接続する場合は、hermes gateway の構成を続けます。

OpenClaw ユーザーの場合は、移行コマンドを確認することもできます。

`1`	`hermes claw migrate --dry-run`

正式にインポートするかどうかを決定する前に、移行可能なコンテンツをプレビューします。

04 と OpenClaw はどうですか?

公式ドキュメントや README から判断すると、Hermes Agent と OpenClaw は単に「誰が誰を置き換えるか」というだけではなく、位置づけにおいては明らかに重複していますが、焦点は異なります。

ヘルメスエージェントとはどのようなものですか?

エルメスはどちらかというとエージェントコアとワークフローシステムに重点を置いた製品です。それが強調していることは次のとおりです。

CLI の経験
記憶とスキルの蓄積
プロジェクトコンテキストファイル
MCP拡張子
サブエージェントの並列処理
ローカル、コンテナ、リモート、サーバーレス環境間で実行バックエンドを切り替える

あなたの主な要求が「エージェントにプロジェクトをよりよく理解させ、継続的な再利用機能を向上させ、MCP と開発ワークフローへの接続を容易にする」ことである場合、Hermes の方向性はより便利になります。

OpenClaw とはどのようなものですか?

OpenClaw は、パーソナル AI アシスタントとメッセージングゲートウェイを中心としたプラットフォームです。それは次のように強調します。

メッセージチャネルへの非常に豊富なアクセス
ゲートウェイを実行する常駐者
ブラウザーでの UI の制御
デバイスのペアリング、リモートアクセス、ステータス管理
音声、モバイル、キャンバスなどの強力なアシスタント形式。

「さまざまなチャットチャネルやデバイス上でパーソナル AI アシスタントを安定させる」ことが主なニーズであり、コントロールパネルを使用して均一に管理したい場合は、OpenClaw の製品感が強くなります。

より現実的な選択の提案

この 2 つは単純に次のように理解できます。

ヘルメスエージェント：「成長する総合エージェントのワークベンチ」
OpenClaw: 「マルチチャネル常駐パーソナル AI アシスタントプラットフォーム」のようなもの

もちろん、この違いは絶対的なものではなく、双方とも機能を拡張し続けており、Hermes は OpenClaw からの移行パスも提供しています。しかし、少なくとも現在の公開情報から判断すると、Hermes は「メモリ、スキル、コンテキスト、MCP、開発ワークフロー」の分野でより顕著です。 OpenClaw は、「ゲートウェイ、マルチチャネル、コントロール UI、デバイスアクセス」の分野でより成熟しています。

05 どんな人に試してほしいの？

あなたが次のカテゴリーに属する人であれば、Hermes Agent を最初に試してみる価値があります。

あなたはターミナルで AI ツールを広範囲に使用しており、エージェントがコードベースとプロジェクトルールをよりよく理解できるようになることを期待しています。
AGENTS.md、スキル、記憶、MCP 能力を組み合わせたいと考えています。
単一のモデルベンダーに縛られることなく、柔軟にプロバイダーを切り替えられるようにしたいと考えています。
以前に OpenClaw を使用していましたが、今度はよりエージェント指向のワークフローの方向を試したいと考えています。

より多くのモバイルリーチ、さまざまな IM プラットフォームへのアクセス、ブラウザコンソール、および「常時接続のパーソナルアシスタントの感覚」を重視する場合は、OpenClaw が依然として魅力的です。

参考リンク

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
ヘルメスエージェントドキュメント: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

MCPを捨てますか？ CLI がエージェントのデフォルトのツール層になりつつある理由

Fri, 10 Apr 2026 21:55:12 +0800

過去 1 年間、エージェントツールチェーンに関する議論は、次の 1 つの問題にますます集中してきました。

MCP (モデルコンテキストプロトコル) はツールの呼び出しを簡単にしますか? それとも、もともと単純だったものを複雑にしますか?

CLI は、ほとんどの日常的な開発タスクにとって、より実用的なデフォルトになりつつあります。

コストの違いは「経験の問題」ではなく、桁違いの問題です

MCP に対する実際の最大のプレッシャーはトークンのオーバーヘッドです。

一般的なシナリオでは、MCP は実際にタスクを実行する前に、多数のツールスキーマをロードする必要があります。 GitHub MCP サーバーを例に挙げると、初期化で数万のトークンが消費される可能性があります。長いタスクの場合、これはコンテキストバジェットを直接圧迫します。

コミュニティのベンチマークは、同じ結論を繰り返し示しています。

1 回の MCP 呼び出しのコストは、通常、CLI の数倍から数十倍になります。
失敗した再試行のコストも高くなります (接続の再構築とコンテキストの再ロード)。

これは「遅い」というギャップではなく、むしろ API 料金、レイテンシー、安定性の問題にまで拡大します。

モデルが自然に「CLI に精通している」理由

見落とされがちな事実は、トレーニングの分布です。

LLM は、トレーニング中にコマンド、出力、エラーレポート、スクリプト、マニュアルページなどの大量の端末テキストを確認しました。言い換えれば、CLI 対話モードは本質的にモデルの「母国語入力」に近いものになります。

それどころか、MCP の JSON-RPC とツールスキーマは、ここ 2 年間で大規模に登場したばかりの新しいパラダイムです。モデルは確かに学習できますが、親しみやすさと圧縮効率は通常、CLI などの歴史的コーパスほど良くありません。

これは、その理由を何度も説明するものでもあります。

目標は同じですが、CLI 命令は短くなります
出力は推論を直接続行するのにより適しています。
エラー回復パスの安定性が向上

安全と隔離：MCPにはまだ補講の余地があります

MCP がセキュリティを実現できないわけではありませんが、エコシステムはまだ初期段階にあります。

現在の一般的な懸念事項は次のとおりです。

ツール中毒
サービス動作のドリフト (ラグプル)
同名のツール「シャドウイング」

もちろん、CLI にもセキュリティの問題 (インジェクション、不正アクセス、パスのリスク) がありますが、そのプロセスモデル、権限の境界、監査リンクは数十年にわたるエンジニアリングの実践によって検証されています。本番環境では、この「予測可能性」が重要です。

これはMCPが無価値であるという意味ではありません

私はMCPを放棄すべきではないと思います。

より合理的な位置付けは次のとおりです。

CLI は実行層 (ローカル、低遅延、高頻度の呼び出し) を担当します。
MCP は接続層 (リモートサービスディスカバリ、統合認証、監査、マルチテナント) を担当します。

一般に、ハイブリッドアーキテクチャ: CLI + MCP Gateway とも呼ばれます。

多数のリモートシステムに接続し、統合された権限管理とコンプライアンス監査を実行する必要がある場合、MCP には依然として明白な価値があります。しかし、「エージェントが開発タスクを迅速に完了できるようにする」という点では、多くの場合、CLI ファーストの方が現在のモデルの機能の境界に沿っています。

今日のエンジニアリングの現実では、CLI はエージェントの母国語に似ています。 MCP は、唯一の実行プロトコルではなく、接続プロトコルとして適しています。