AI Agent on KnightLiブログ

RAGFlowプロジェクト整理：オープンソースRAGエンジンの機能と使い方

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow は infiniflow によるオープンソースの RAG（Retrieval-Augmented Generation）エンジンです。単なる「ドキュメントをアップロードして質問する」ための薄いナレッジベース外殻ではなく、ドキュメント解析、チャンク分割、検索、リランキング、引用の追跡、モデル設定、Agent 機能、API 統合までを一つのワークフローにまとめることを目指しています。

企業向けナレッジベース、ドキュメント Q&A、サポートアシスタント、社内情報検索、あるいは LLM により信頼できるコンテキスト層を持たせたい場合、RAGFlow は重点的に見る価値のあるオープンソース案の一つです。

01 RAGFlow は何を解決するのか

一般的な RAG システムがぶつかりやすい問題は主に三つあります。

ドキュメント解析の品質が安定しない。特に PDF、スキャン文書、表、画像、複雑なレイアウトで起きやすい。
チャンク分割戦略が見えにくく、検索ヒットはしていても実際の文脈が不完全になりやすい。
回答に信頼できる引用がなく、利用者が出典を確認しにくい。

RAGFlow はまさにこの部分に力を入れています。README では Deep document understanding、テンプレート化されたチャンク分割、チャンクの可視化、引用のグラウンディング、多経路検索とリランキングが強調されています。つまり、単にベクトルデータベースとチャット UI をつなぐのではなく、「高品質な入力が高品質な回答につながる」ことを重視しているということです。

02 主な機能

1. 高度なドキュメント理解

RAGFlow は複雑な非構造化データから知識を抽出できます。README に挙げられている形式には Word、PPT、Excel、TXT、画像、スキャン文書、構造化データ、Web ページなどがあります。

これは企業ナレッジベースにとって非常に重要です。現実の資料はきれいな Markdown ではなく、契約書、レポート、表、スキャン PDF、製品マニュアル、スクリーンショット、Web ページが混在していることが多いからです。解析品質が低いと、その後のベクトル検索も LLM の回答も弱くなります。

2. テンプレート化されたチャンク分割

RAGFlow はテンプレートベースの chunking を提供します。ここでの価値は、チャンク分割がブラックボックスではなく、文書タイプに応じてより適切な戦略を選べることです。

たとえば通常の記事、論文、表、Q&A 文書、画像説明、契約条項では、チャンクの粒度や境界の考え方が異なります。テンプレート化された分割により、「文が途中で切れる」「表の文脈が失われる」「見出しと本文が分かれてしまう」といった問題を減らせます。

3. 追跡可能な引用

RAGFlow は grounded citations を重視しています。つまり、回答がどのソース断片に基づくのかを追えるということです。さらにチャンクの可視化もあり、解析結果やチャンク分割結果を人が確認して調整しやすくなっています。

これは本番環境では特に重要です。企業内 Q&A は、ただ「それっぽい答え」を返せばよいわけではなく、検証可能である必要があります。ポリシー、コンプライアンス、財務、技術文書、サポート情報のような分野では、引用と追跡性はほぼ必須です。

4. 自動化された RAG ワークフロー

RAGFlow は RAG の一連の流れを、より完成度の高いワークフローとしてまとめています。

ナレッジベースの作成
データのアップロードまたは同期
ドキュメント解析
チャンクの確認と調整
LLM と embedding モデルの設定
多経路検索とリランキングの実行
チャットアシスタントの構築
API 経由で業務システムへ統合

このため、単なるライブラリというより RAG プラットフォームに近い存在です。チームにとっては UI と API の両方が有用で、非エンジニアはナレッジベースを保守しやすく、エンジニアは既存システムへ組み込みやすくなります。

5. Agent、MCP、ワークフロー拡張

最近の RAGFlow には Agentic workflow、MCP、Agent Memory、コード実行コンポーネントなども含まれています。これは、従来型のナレッジベース Q&A にとどまらず、Agent シナリオにも広がっていることを示しています。

典型的には、Agent が信頼できる企業知識レイヤーとして RAGFlow を使い、必要なときにナレッジベースから検索し、引用付きで回答を生成し、必要に応じてツール呼び出しやワークフローと組み合わせる、という形です。

03 基本的な利用フロー

公式のクイックスタートに沿うと、RAGFlow の一般的な使い方は次のようにまとめられます。

1. 実行環境を準備する

README にある基本要件は以下の通りです。

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

コード実行用のサンドボックスを使う場合は gVisor も必要です。また、公式 Docker イメージは主に x86 向けです。ARM64 を使う場合は、公式ドキュメントに従って自分でイメージをビルドする必要があります。

2. プロジェクトを取得する

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. `vm.max_map_count` を確認する

RAGFlow のデプロイは Elasticsearch / OpenSearch のようなコンポーネントに依存するため、Linux では通常次を確認します。

`1`	`sysctl vm.max_map_count`

値が 262144 未満なら、一時的に次で設定できます。

`1`	`sudo sysctl -w vm.max_map_count=262144`

再起動後も維持したい場合は /etc/sysctl.conf に追加します。

4. Docker Compose で起動する

CPU モードはそのまま起動できます。

`1`	`docker compose -f docker-compose.yml up -d`

DeepDoc を GPU で高速化したい場合、README では .env に DEVICE=gpu を追加してから起動する方法が示されています。

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

起動後はログを確認します。

`1`	`docker logs -f docker-ragflow-cpu-1`

サービスが立ち上がったら、ブラウザでサーバーのアドレスを開きます。デフォルト構成では通常次のようになります。

`1`	`http://IP_OF_YOUR_MACHINE`

5. モデル API Key を設定する

RAGFlow では LLM と embedding モデルの設定が必要です。README では service_conf.yaml.template 内でデフォルトの LLM factory を選び、対応する API_KEY を更新する流れが説明されています。

実際には、使うプロバイダーに合わせて次を設定します。

チャットモデル
embedding モデル
rerank モデル
PDF / DOCX 内の画像も理解したい場合はマルチモーダルモデル

6. ナレッジベースを作成して文書を取り込む

サービス起動後の典型的な流れは次の通りです。

Web UI にログインする。
dataset / knowledge base を作成する。
文書をアップロードするか、データソース同期を設定する。
解析完了を待つ。
チャンク結果を確認し、必要なら調整する。
チャットアシスタントを作成し、知識ベースを関連付ける。
回答品質と引用元を確認する。

業務システムに組み込みたい場合は、RAGFlow の API や SDK を使って、検索とチャット機能を自分のアプリに接続できます。

04 向いている場面

RAGFlow は次のような用途に向いています。

企業内ナレッジベース Q&A
製品マニュアル、技術文書、FAQ の検索
カスタマーサポートや営業支援アシスタント
契約書、レポート、規程文書に対する追跡可能な Q&A
複数形式の資料を一元的に扱いたい場合
UI による運用と API 統合の両方が必要なチーム
Agent のコンテキスト層として RAG を使いたいシステム

特に、文書形式が複雑で、引用が重要で、人が解析結果を確認・調整したい場合に向いています。

05 使うときの注意点

第一に、RAGFlow は軽量スクリプトではありません。ある程度のインフラ要件があります。公式の推奨は最低 4 コア CPU、16GB RAM、50GB ディスクです。少量の Markdown に対して Q&A をしたいだけなら、ここまで大きなプラットフォームは不要かもしれません。

第二に、文書品質は依然として重要です。RAGFlow は解析やチャンク分割を改善できますが、質の低い資料、古い資料、矛盾する資料を自動で信頼できるものに変えることはできません。本番導入前にはナレッジベースの運用設計が必要です。

第三に、モデル設定は結果に直結します。embedding、rerank、チャットモデル、マルチモーダルモデルの選択は、検索品質と回答品質の両方に影響します。RAGFlow はワークフローを提供しますが、最終的な品質はデータ、モデル、パラメータ調整の組み合わせで決まります。

第四に、本番環境では権限とデータセキュリティに注意が必要です。企業ナレッジベースには社内文書が含まれることが多いため、デプロイ方式、アクセス制御、ログ、API Key、モデル提供者側のデータポリシーまで事前に設計するべきです。

06 短い判断

RAGFlow の強みは、RAG で最も面倒な部分をプラットフォーム機能としてまとめていることです。複雑な文書解析、説明可能なチャンク分割、引用のグラウンディング、多経路検索、リランキング、モデル設定、Web UI、API、Agent 拡張までを一式で備えています。

検証可能で保守しやすく、業務システムにも接続できる企業ナレッジベースを作りたいなら、RAGFlow は「ベクトルデータベース + 簡単なチャット UI」より完成度の高い選択肢です。逆に、個人用途の小規模な Q&A や、扱うデータ形式が非常に単純な場合は、より軽量な RAG フレームワークのほうが扱いやすいかもしれません。

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はツール箱に入れておく価値があります。逆に、固定サイトから低コストで大量収集するだけなら、従来のクローラーや専用パーサーのほうが適している場合があります。

OpenHarness とは: このオープンソースの Agent Harness では何ができるのですか?

Sun, 12 Apr 2026 23:45:00 +0800

最近オープンソースの AI エージェントツールに注目している場合、HKUDS/OpenHarness は注目に値する新しいプロジェクトです。これは単なる「チャットシェル」ではなく、実行可能、スケーラブル、管理可能なエージェントインフラストラクチャをオープンソースの エージェントハーネスに分離します。

公式 README によると、OpenHarness は主に、ツールの呼び出し、スキルの読み込み、メモリメカニズム、権限管理、マルチエージェントの調整など、軽量のエージェントの基本機能のセットを提供します。およびそれに付随する ohmo は、このインフラストラクチャ上に構築されたパーソナル AI アシスタントアプリケーションです。

01 オープンハーネスとは何ですか？

OpenHarness は、「大きなモデルに手、足、メモリ、境界をインストールする」ランタイム層として理解できます。

大規模なモデル自体は推論と生成に優れていますが、それを本当に長期間動作できるエージェントにしたい場合は、通常、次の周辺機能が必要です。

テキストを出力するだけでなくツールを調整する
ファイルの読み取りと書き込み、コマンドの実行、検索機能と Web 機能へのアクセス
長時間のセッションでもコンテキストとメモリを保持
危険な操作に対する権限の制御
大きなタスクを複数のサブエージェントに分割して並列処理する

OpenHarness の目標は、この「モデル周辺のエンジニアリング層」を、明確でオープンソースでチェック可能な Python 実装に変えることです。これは、特定のモデルや特定のチャットインターフェイスのみを強調するのではなく、エージェントの操作ベースに似ています。

02 本プロジェクトの基本機能

現在の GitHub ホームページと README から判断すると、OpenHarness のコア機能は主に次の領域に集中しています。

1. Agent Loop

これは、エージェントが継続的に動作できるコア実行ループです。公式ハイライトは次のとおりです。

ストリーミングツール呼び出しループ
API の再試行と指数バックオフ
ツールの並列実行
トークンの統計とコストの追跡

この部分の重要性は、エージェントが単なる「1 つの質問と 1 つの回答」ではなく、継続的に観察し、考え、ツールを呼び出し、結果を読み取り、タスクの次のステップに進むことができることです。

2. ツール、スキル、プラグインシステム

OpenHarness により、ツール層が比較的完全になりました。プロジェクトのホームページには、ファイル、シェル、検索、Web ページ、MCP などのツールが組み込まれており、オンデマンドでの Markdown スキルファイルの読み込みをサポートしていると記載されています。

その価値は「より多くのツール」だけではありませんが、さらに重要なのは、その組み合わせ方法が比較的オープンであることです。

組み込みツールを直接使用可能
スキルはタスクごとにロード可能
フック、スキル、エージェントはプラグインを通じて拡張可能
anthropics/skills および関連プラグインエコロジーと互換性があります

このレイヤーは、毎回プロンプトによる一時的な説明に依存するのではなく、特定の固定プロセスを再利用可能な機能にまとめたい場合に役立ちます。

3. コンテキストと記憶

この部分は OpenHarness の重要な差別化ポイントです。公式キーワードには次のようなものがあります。

CLAUDE.md の検出と挿入
自動コンテキスト圧縮
MEMORY.md 永続メモリ
セッションの回復と履歴の継続

これは、現在のラウンドの入力を処理するだけでなく、「プロジェクトのコミットメント」、「過去のタスク」、および「長期的な設定」を保持しようとすることを意味し、エージェントを毎回最初から開始するのではなく、継続的な作業により適したものにします。

4. 当局のガバナンスとセキュリティ境界

エージェントが実際にファイルシステム、端末、ネットワークに入った後は、ガバナンスが非常に重要になります。 OpenHarness はこのセクションで次のことを提供します。

マルチレベル権限モード
パスとコマンドベースのルール制御
PreToolUse / PostToolUse hooks
インタラクティブな承認ポップアップウィンドウ

簡単に言うと、エージェントが「できること」だけでなく、「直接実行できることと、最初に確認しなければならないこと」を考慮します。

5. マルチエージェントの調整

OpenHarness は、処理のためにタスクをサブエージェントにオフロードすることもサポートしています。現在の公開情報で言及されている機能には次のものが含まれます。

サブエージェントの作成と委任
チーム登録とタスク管理
バックグラウンドタスクのライフサイクル管理

複雑なタスクの場合、これは、1 つのエージェントに依存して逐次的に進めるだけでなく、並行して共同作業を試みることもできることを意味します。

6. マルチプロバイダーのワークフロー

OpenHarness は現在、プロバイダーを単なる基盤となる API 名とは見なさず、それをワークフロー + プロファイルに抽象化します。 README によると、現在サポートされている指示は次のとおりです。

Claude / Anthropic-compatible
OpenAI-compatible
Codex Subscription
GitHub Copilot
Moonshot (Kimi)、GLM、MiniMax、およびその他の互換性のあるバックエンド

これにより、特定のサービスプロバイダーに束縛されるのではなく、「マルチモデル、マルチエントリー」エージェント実行フレームワークに似たものになります。

7. React TUI と非対話型モード

OpenHarness にはターミナルの対話型インターフェイスが付属しており、oh を実行した後に React/Ink TUI に入ることができます。公式の README には、以下をサポートしていると記載されています。

コマンドセレクター
許可の確認
機種切り替え
プロバイダースイッチ
セッションの再開

対話型インターフェイスに入りたくない場合は、結果を標準出力、JSON、またはストリーミング JSON に出力するなど、非対話モードで単一のタスクを直接実行することもできます。これは、スクリプト作成や自動化のシナリオに適しています。

03 `ohmo`とは

OpenHarness が基盤となるインフラストラクチャである場合、ohmo は、このインフラストラクチャ上に構築された「パーソナルエージェントアプリケーション」です。

ohmo の位置付けはプロジェクトのホームページで非常に明確です。これは通常のチャットボットではなく、長時間の会話でも機能し続けるパーソナルアシスタントです。公式説明には、Feishu、Slack、Telegram、Discord、その他のチャネルでユーザーと対話し、次のようなタスクを実行できると記載されています。

フォークブランチ
コードを書く
テストの実行
PRを始める

さらに、README では、ohmo は既存の Claude Code または Codex サブスクリプション上で実行でき、必ずしも新しい API キーの追加アプリケーションを必要としないことも強調しています。これらのサブスクリプションツールをすでに使用しているユーザーにとって、これは比較的参入障壁が低いです。

04 どんなシーンに適していますか？

このプロジェクトで現在公開されている機能から判断すると、OpenHarness は次のタイプの人々に適しています。

本番レベルのエージェントがどのような基本モジュールで構成されているかを調べたいと思っています。
スケーラブルなオープンソースのエージェントオペレーティングレイヤーを自分で構築したい
ツール、スキル、メモリ、権限、マルチエージェントの調整を同じフレームワークに組み込みたい
単一のモデルメーカーや単一の顧客フォームに束縛されたくない
既製のアーキテクチャに基づいた垂直分野のエージェントまたはパーソナルアシスタントであり続けたいですか?

あなたの目標が単に「直接チャットできる完成したアシスタントを見つける」ことである場合、OpenHarness オントロジーは最も軽い選択肢ではないかもしれません。ただし、エージェントのインフラストラクチャ、エンジニアリングの制御性、およびその後の拡張にもっと関心がある場合は、このプロジェクトを検討する価値があります。

05 位置付けをすぐに理解する

一文の要約:

**OpenHarness は、大規模なモデルを実際にタスクを実行できるエージェントに変換する責任を負い、ohmo は、この一連の機能を、長期間使用できるパーソナルアシスタントにパッケージ化する責任があります。 **

2 つのレイヤーに分割して確認することもできます。

OpenHarness: オープンソースの Agent Harness、本質はインフラストラクチャです
ohmo: このインフラストラクチャ上に構築されたパーソナルエージェントアプリ

2026 年 4 月 12 日の時点で、プロジェクトの GitHub ホームページには、更新が v0.1.6 (2026 年 4 月 10 日) に進み、引き続き自動コンテキスト圧縮、MCP 転送機能、React TUI、およびマルチエージェント実行の安定性に重点が置かれていることが示されています。これは、まだ急速な進化段階にあることを示していますが、方向性はすでに非常に明確です。

参考リンク

GitHub プロジェクトのホームページ: https://github.com/HKUDS/OpenHarness
英語の README: https://github.com/HKUDS/OpenHarness/blob/main/README.md
中国語の README: https://github.com/HKUDS/OpenHarness/blob/main/README.zh-CN.md

Playwright CLI の入門: インストール、スキル、セッション管理、および一般的なコマンド

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

現在、ブラウザ自動化に Claude Code、GitHub Copilot、またはその他のコーディングエージェントを使用している場合、microsoft/playwright-cli は注目に値する新しいツールです。これは、「コマンドを手動で入力するために使用される」従来の意味でのブラウザガジェットではなく、エージェントをコーディングするための Playwright CLI であり、トークンオーバーヘッドの低減、軽量のコマンドインターフェイス、およびスキルワークフローとの統合を重視しています。

公式 README から判断すると、Playwright CLI の核となる考え方は非常に明確です。モデルコンテキストに多数のツールスキーマとページ構造を詰め込む MCP と比較して、CLI コマンド方式はよりコンパクトで、大規模なコードベース、テストタスク、ブラウザ自動化の間を行き来するエージェントワークフローにより適しています。

01 Playwright CLIとは何ですか?

playwright-cli は、Microsoft がオープンソース化した Playwright コマンドラインツールです。公式説明は「一般的な Playwright アクション用の CLI」です。主に次のことを実現するために使用されます。

ページを開いてブラウザを起動します
Playwright コードを記録して生成する
ページのスナップショットを取得し、要素の参照を取得します
スクリーンショット、PDF のエクスポート
コーディングエージェントと連携して自動テストとWebページ運用を行います。

現在の GitHub README では、これを非常に明確に位置づけています。コーディングエージェントを使用している場合は、Playwright MCP よりも CLI の方が適していることがよくあります。永続的な状態、豊富なイントロスペクション、長いエージェントループが必要な場合でも、MCP には価値があります。

言い換えれば、Playwright CLI は、人間のエンジニアが Web ページを手動でクリックするための単なるツールではなく、「AI コーディングアシスタントのためのブラウザ自動化インターフェイス」に近いものです。

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

1. エージェントのワークフローにさらに適した

公式READMEには、最初の利点がToken-efficientとして直接書かれています。データのページ全体を LLM コンテキストに強制的に組み込むのではなく、エージェントはより短く、より特殊なコマンドを通じてブラウザを操作できるようになります。

これはエージェントのコーディングにとって重要です。実際のプロジェクトでは、エージェントはブラウザを実行するだけでなく、コードの読み取り、ファイルの変更、テストの実行、ログの読み取りも行うためです。ブラウザツール自体が非常に「コンテキストを食べる」場合、全体の効率が大幅に低下します。

2. スキルを使って作業する能力

README では特に playwright-cli install --skills を強調しています。これは、公式がこれを単なるシェルツールとして捉えておらず、Claude Code や GitHub Copilot などのエージェントが直接利用できるスキルの入り口として設計していることを示しています。

ワークフロー自体がスキルに基づいて構築されている場合は、Playwright CLI への接続がより自然になります。

3. セッション管理が比較的完了している

Playwright CLI はセッションをサポートします。デフォルトでは、ブラウザプロファイルはメモリに保存され、同じセッション内の Cookie とストレージは複数の CLI 呼び出し間で保持されます。 --persistent が追加された場合、プロファイルをディスクにドロップし、ブラウザを再起動しても引き続き使用することもできます。

これにより、「コマンド 1 つでブラウザを開いて実行後に破棄する」というおもちゃのツールよりも実用的となり、継続的なデバッグやエージェントの長時間プロセスの実行にも適しています。

4. 視覚監視パネルが付属しています

playwright-cli show は README に含まれており、ダッシュボードを開いて実行中のすべてのブラウザーセッションを監視および制御するために使用されます。これは、ただやみくもに実行するのではなく、いつでも引き継ぎ、監視、トラブルシューティングを行うことができるため、エージェントがバックグラウンドで自動化されたタスクを実行するシナリオで役立ちます。

03 設置および環境要件

現在の GitHub README によると、Playwright CLI の基本要件は次のとおりです。

Node.js 18 以降
Claude Code、GitHub Copilot、またはその他のコーディングエージェント

インストールコマンドは以下のとおりです。

1
2

npm install -g @playwright/cli@latest
playwright-cli --help

ここには特に注意しなければならない非常に簡単な落とし穴があります。

現在推奨されている公式インストールは @playwright/cli です。
これを、npm 上の歴史的で非推奨となった古いパッケージ playwright-cli と混同しないでください。

つまり、実際にインストールする必要があるのは、古い時代からの同名の履歴パッケージではなく、スコープ指定されたパッケージです。

04 始め方

1. スキルをインストールする

コーディングエージェントに Playwright CLI を直接使用させたい場合は、最初にスキルをインストールすることが公式推奨されています。

`1`	`playwright-cli install --skills`

README には、Claude Code や GitHub Copilot などのツールがローカルにインストールされたスキルを使用することが明確に記載されています。

2. エージェントに CLI を直接呼び出させる

最初にスキルを処理したくない場合は、エージェントに CLI ヘルプ情報を直接読み取らせることもできます。

1
2

Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.

正式にはこの方法を「スキルレス操作」といいます。これは、スキルがプリインストールされていない場合でも、CLI 自己記述機能を通じてエージェントを駆動できることを意味します。

3. 最小限の工程を手動で体験

README には、開始するのに非常に適した一連の TodoMVC サンプルが含まれています。

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli type "Water flowers"
playwright-cli press Enter
playwright-cli check e21
playwright-cli check e35
playwright-cli screenshot

このコマンドセットの価値は、Playwright CLI がどのように対話するかをすぐに理解できることです。

open はページを開く責任があります
type および press は入力を担当します
check 要素参照を使用したチェックボックスの操作
screenshot 結果を保存

05 `--headed`、セッションおよびモニタリングパネル

`--headed`

Playwright CLI はデフォルトではヘッドレスです。ブラウザウィンドウを直接表示したい場合は、--headed を open に明示的に追加する必要があります。

`1`	`playwright-cli open https://playwright.dev --headed`

これは、セレクター、ログインプロセス、検証コードの前後のインタラクティブな観察のデバッグに便利です。

session

公式 README ではセッションの使用法が強調されています。異なるセッションを使用して、異なるプロジェクトまたは Web サイトを分離できます。

1
2
3

playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list

エージェントを長時間動作させたい場合は、環境変数を直接指定することもできます。

`1`	`PLAYWRIGHT_CLI_SESSION=todo-app claude .`

一般的に使用されるセッション管理コマンドには次のものがあります。

1
2
3

playwright-cli list
playwright-cli close-all
playwright-cli kill-all

で：

list はすべてのセッションをリストするために使用されます
close-all は、すべてのブラウザを通常どおり閉じるために使用されます。
kill-all は、すべてのブラウザプロセスを強制的に終了するために使用されます。

監視パネル

ブラウザでエージェントが現在何を行っているかを確認したい場合は、次のコマンドを実行できます。

`1`	`playwright-cli show`

README によると、このダッシュボードには主に 2 つのビューがあります。

セッショングリッド: すべてのアクティブなセッションをワークスペースごとに表示し、ライブビュー、URL、ページタイトルを表示します。
セッションの詳細: 単一セッションのリアルタイムインターフェイスを表示し、マウスとキーボードを引き継ぐこともできます

これにより、Playwright CLI は「コマンドラインが利用可能」になるだけでなく、比較的成熟した可観測性も備えます。

06 最初に覚えるべき一般的なコマンドはどれですか?

Playwright CLI を初めて使用する場合は、最初からすべてのコマンドを覚える必要はありません。最初に次の中心点を覚えておくだけで十分です。

ページとインタラクション

playwright-cli open [url]
playwright-cli goto <url>
playwright-cli click <ref>
playwright-cli fill <ref> <text>
playwright-cli type <text>
playwright-cli hover <ref>
playwright-cli press <key>

ページ構造を取得する

playwright-cli snapshot
playwright-cli snapshot <ref>
playwright-cli snapshot --depth=N
playwright-cli eval <func> [ref]

後続の多くの操作は要素参照 ref に依存するため、snapshot は重要です。通常は、最初にスナップショットを取得し、次に返された要素番号を使用してクリック、入力、チェック、またはスクリーンショットの取得を行います。

出力結果

1
2

playwright-cli screenshot
playwright-cli pdf

タブページ

playwright-cli tab-list
playwright-cli tab-new [url]
playwright-cli tab-close [index]
playwright-cli tab-select <index>

07 どんな人に向いていますか？

次のいずれかのシナリオに該当する場合は、Playwright CLI を試してみる価値があります。

E2E テストに Claude Code、Copilot、またはその他のコーディングエージェントを使用している
ブラウザ自動化インターフェイスをより軽量にしたいが、コンテキストに多くのページ構造を詰め込みたくない場合
複数のコマンド間で同じブラウザセッションを維持したい場合
エージェントが Web ページタスクを自動的に実行するとき、いつでも監視パネルを開いて進行状況を観察したいと考えています。

「ブラウザの自動化がコーディングエージェントとどのように効果的に連携できるか」が仕事の焦点である場合、Playwright CLI は従来の人による手動のデバッグ方法よりも便利である可能性があります。

参考リンク

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

OpenClaw 脳に似た記憶アルゴリズム夢を見る: 機械は夢を見始めるが、人間は不眠症になる

Sun, 12 Apr 2026 12:41:34 +0800

大規模モデルの長期記憶は常に問題でした。コンテキストが蓄積すればするほど、情報が混乱しやすくなります。知的なエージェントはすべてを覚えているように見えますが、実際には、何が重要で、何が忘れるべきかを判断することがますます困難になります。

4 月 5 日、OpenClaw は新バージョンの実験機能「Dreaming」を開始しました。これは派手な名前ではなく、人間の睡眠プロセスを模倣する一連のバックグラウンド記憶構成メカニズムです。目標は非常に単純で、知的エージェントが目覚めた後により正確に記憶できるようにすることです。

01 睡眠アルゴリズム：記憶整理を3段階に分ける

夢を見ることは単にインデックスを作成することではなく、人間の睡眠中のさまざまな機能に対応して、記憶を 3 つの論理的な段階に編成します。

浅い睡眠: システムは最初に最近の会話と思い出の記録をスキャンし、重複の削除と予備的なスクリーニングを実行して、候補コンテンツを生成します。この段階では、一時的な保存のみが実行され、コアメモリファイル MEMORY.md は直接変更されません。

ディープスリープ: システムは、ルールに従って価値の高い情報のフィルタリングを開始します。最低の評価、最低のリコール数、最低の固有クエリ数を満たす情報のみが次のステップに進みます。書き込む前に、最新のログが再度比較され、古い内容が削除されます。最後に、結果は MEMORY.md に追加され、ディープスリープの概要が DREAMS.md に残ります。

急速眼球運動段階 (REM): 記憶が定着した後、システムはさらに短期の行動追跡を分析し、異なる情報間の潜在的なつながりを探し、パターンの要約と反映内容を生成します。この部分は、エージェントが複雑なタスクを処理するときに全体の状況をより簡単に把握できるように、専用の REM ブロックに書き込まれます。

マシン自体の記憶整理メカニズムに加えて、Dreaming は人間の読書により適した「夢日記」も生成します。素材がある程度溜まるとバックグラウンドサブエージェントがデフォルトモデルを呼び出してDREAMS.mdに簡潔な記述を追加します。

02 採点の仕組み：何を残し、何を忘れるべきかを決める

夢を見るための鍵は「整理する」だけではなく「ふるい分ける」ことです。 OpenClaw は、大規模なフルスケールストレージを使用し続ける代わりに、重み付けされたスコアリングメカニズムを使用して、どの情報を長期記憶に入れる価値があるかを判断します。

このメカニズムは主に次の 6 つの次元に注目します。

関連性の重み (30%): 情報が検索されたときに役立つかどうかを測定します。
頻度重み付け (24%): ある情報が繰り返し言及された回数をカウントします。
クエリの多様性 (15%): さまざまな質問やシナリオにわたってそれが現れるかどうかを確認します。
適時性の重み (15%): より新しい情報に高い優先度を与えます。
統合の重み (10%): 情報が複数の日に渡って安定して表示されるかどうかを確認します。
コンセプトの豊富さ (6%): その背後にある関連コンセプトが十分に充実しているかどうかを判断します。

これは、システムが長期記憶にすべてを詰め込むのではなく、繰り返し表示され、問題を解決し、時代を超えた情報を保持することを優先することを意味します。

03 なぜクロードの「夢」の考えを人々に思い出させるのでしょうか?

一部の開発者は、OpenClaw の Dreaming アップグレードの背後にあるアイデアが、Claude Code の漏洩コードに登場した KAIROS 自動ドリーミングメカニズムと非常によく似ていると信じています。以前は、MEMORY.md 全体の読み取りと書き込みを繰り返す方法では、後の段階でメモリシステムがますます肥大化する可能性がありました。一方、Dreaming はプロセスを浅い睡眠の統合、深い睡眠の固化、REM の関連付けに分割します。ロジックは明らかにより明確で、「最初に組織化し、次に沈殿させ、次に精製する」というアイデアに近くなります。

神経科学の観点からこのデザインを肯定する人もいます。なぜなら、夢、浅い睡眠、深い睡眠、レムの概念は単なるランダムな名前ではなく、記憶を定着させるために明らかに人間の睡眠モデルから借用したものだからです。

OpenClaw の既存の IDENTITY.md、USER.md、HEARTBEAT.md はすでにエージェントの個性、ユーザーコンテキスト、実行継続性を提供していますが、DREAMS.md が追加するのは「どの記憶を保持するか」を指定する機能です。

04 最も皮肉なシーン: 機械は夢を見ることを学ぶが、人間は眠れない

Dreaming の本当の価値は、AI にすべてを記憶させることではなく、短期記憶を見直し、基礎となるパターンを抽出し、ノイズをフィルターする方法を学習させることです。本当に役立つエージェントは、モバイルハードドライブのように丸暗記するのではなく、ユーザーの好み、目標、背景をますます理解する必要があります。

工学的な観点から見ると、このメカニズムの最も注目すべき点は、それが神秘的ではないということです。これはブラックボックスマジックではなく、ステージ、しきい値、反映、および忘却ルールを備えた一連のバックグラウンドプロセスです。この設計により、AI の記憶メカニズムが、単なる「コンテキストの無限のヒープ」ではなく、初めて「制御可能なシステム」のように見えます。

しかし、それが全体を少し皮肉なものにしているのです。私たちは機械に人間のように夢を見る方法を教えるために多大なリソースを投資していますが、同時に多くの人々がこれらのますますスマート化するシステムに取って代わられるのではないかという恐怖で眠れなくなっています。

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 は、唯一の実行プロトコルではなく、接続プロトコルとして適しています。

OpenClaw と Agent Harness: なぜ AGI のように見えるのか

Fri, 10 Apr 2026 09:16:17 +0800

初めて OpenClaw に触れた人の多くは、「チャットボットというよりも、何かができる同僚に近い」と感じるでしょう。

この感覚には何も不思議なことはありません。重要な点は、OpenClaw は単一モデルの機能を飛躍的に向上させたものではなく、完全な エージェントハーネス であるということです。

結論を先に言ってください

OpenClaw の本質は次のように要約できます。

モデルは理解と意思決定を担当します
ハーネスはメモリ、ツール、トリガー、実行、出力を担当します。
両者はサイクルを通じて協力し、「継続的なアクション」の体験を形成します。

したがって、それが「AGI に似ている」主な理由は、モデルが突然全能になることではなく、システムエンジニアリングによってモデルの実行可能性が増幅されることです。

ハーネスとは

ハーネスは「モデルが着用する外骨格」と理解できます。

スタンドアロン LLM は通常、単一のリクエストでのみ回答を提供でき、Harness はこれらの機能を完了します。

セッションと状態の管理: 複数のラウンドのタスクをつなぎ合わせる
メモリメカニズム: オンデマンドでコンテキストを保存および呼び出し
ツールシステム: ブラウザ、端末、ファイル、外部 API の呼び出し
トリガーメカニズム: タイマーまたはイベントによって起動し、毎回誰かが質問するのを待つ必要はありません。
出力チャネル: 単なるテキストではなく、結果をシステムに書き戻します。

これらの機能が同じループに接続されると、モデルは「レスポンダー」から「エグゼキューター」に変わります。

OpenClaw の外観が異なる理由

従来のチャットボットは「1 回質問し、1 回回答」です。

OpenClaw は、「観察 -> ツールの調整 -> 結果の確認 -> 意思決定」という閉ループに似ています。クローズドループが確立されると、タスクを継続的に進める能力を発揮します。

これは、OpenClaw について学ぶべき最も価値のあることでもあります。

エージェントのエクスペリエンスは主にアーキテクチャ設計から得られることが証明されています
「自律性」をエンジニアリングモジュールに分割します

価値観と境界線

OpenClaw の利点は多用途性と柔軟性があることですが、価格も明らかです。

コンテキストとツールの定義が増えるほど、コストが高くなります
システムが一般的であればあるほど、デバッグと管理はより複雑になります

本番環境のシナリオでは、多くのチームが「万能エージェント」ではなく、より小規模で専門性の高いエージェントを選択します。

Anthropic による OpenClaw 禁止の完全なタイムライン

Wed, 08 Apr 2026 19:48:42 +0800

イベントの背景

2026 年 4 月 4 日、Anthropic は、OpenClaw などのサードパーティツールに対するクロードのサブスクリプションの対象を打ち切ると発表しました。

ユーザーレベルへの直接的な影響は、もともとサブスクリプションパスに依存してクロードにアクセスしていたサードパーティプロセスを、他のアクセス方法に変更するか、他のモデルに切り替える必要があることです。

タイムライン（2026年1月から4月）

2026年1月

公開報道によると、Anthropic は、当時 Clawdbot として知られていたこのプロジェクトに対し、発音がクロードに近いことから名前の変更を求めたという。

同じ段階で、サードパーティがサブスクリプション認証情報を介して通話できる機能が限られているというフィードバックがコミュニティから出始めました。

2026年2月

関連する制限はサービス規約に記載されており、サブスクリプションとサードパーティの自動呼び出しとの境界がさらに明確になります。

同月、OpenClaw は v4.0 をリリースし、基礎となるアーキテクチャがプラグイン可能なモデルバックエンドに変更されました。つまり、モデルは単一の固定された入り口ではなくなり、複数のモデルプロバイダーの間で切り替えることができます。

2026年3月

Anthropic は、リモートタスクの実行やデスクトップ操作などの機能をカバーする、Claude Dispatch と Computer Use をリリースします。

OpenClaw は今後のアップデートでも互換性レイヤーを推進し、異なるモデルの認証方法、ツール呼び出し形式、戻り構造の違いを統一し、モデルを切り替える際の移行コストを削減します。

公開レポートでは、OpenClaw チームが 3 月下旬に Anthropic と連絡を取ったとも述べられていましたが、最終的な戦略的方向性は変更されませんでした。

2026 年 4 月 4 日

Anthropic は、サードパーティツールのサブスクリプション適用範囲の打ち切りを正式に実装します。

これは、過去数か月間に行われた戦略的調整の実施段階を示します。

2026 年 4 月 5 日

OpenClaw は v4.5 をリリースします。主なアクションには次のようなものがあります。

ブートストラッププロセス中にモデルエントリの優先順位を調整する
GPT-5.4 などの代替モデルパスにアクセスする
タスクのプロセスとインタラクティブなエクスペリエンスに適応し続ける

リリース時期から判断すると、OpenClaw のスイッチング機能は完全に一時的なビルドではなく、2 月以降のマルチモデルアーキテクチャの変革に基づいています。

プロセスにおける 2 つの平行した方向

タイムラインを見ると、両当事者は同じ期間に異なる方向に前進しました。

Anthropic: サブスクリプションの境界を厳格化し、公式の製品機能の統合を促進します。
OpenClaw: モデルの置換可能性を強化し、モデル間の互換性を向上させます。

この 2 つのルートは矛盾するものではありませんが、「エントリーの所有権」と「ユーザーのワークフローの登録位置」という点で競合関係が生じます。

現状（2026年4月現在）

公開されている情報に基づいて、次の事実が確認できます。

サブスクリプションオーバーライドのカットオフが実行されました
OpenClaw はメジャーモデルパスの切り替えを完了し、バージョンの反復を維持しました
ユーザーが大きな変化を感じるかどうかは、元のワークフローが単一モデルの機能にどの程度依存しているかによって決まります。

経過観察のポイント

次に注目すべきは、その事件そのものではなく、次の 3 つの点です。

サブスクリプションプランと API 呼び出しの間の境界は今後も改善されていくのでしょうか?
安定性、コスト、エクスペリエンスの観点からマルチモデルエージェントの長期的なパフォーマンスを実現
ユーザーのワークフローは最終的にモデル層、ツール層、あるいはその 2 つの間のハイブリッド層に落ち着きますか?

AI Agent on KnightLiブログ

RAGFlowプロジェクト整理：オープンソースRAGエンジンの機能と使い方

01 RAGFlow は何を解決するのか

02 主な機能

1. 高度なドキュメント理解

2. テンプレート化されたチャンク分割

3. 追跡可能な引用

4. 自動化された RAG ワークフロー

5. Agent、MCP、ワークフロー拡張

03 基本的な利用フロー

1. 実行環境を準備する

2. プロジェクトを取得する

3. vm.max_map_count を確認する

4. Docker Compose で起動する

5. モデル API Key を設定する

6. ナレッジベースを作成して文書を取り込む

04 向いている場面

05 使うときの注意点

06 短い判断

関連リンク

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

01 何を解決するのか

02 主な機能

03 AI Agentに向いている理由

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

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

06 向いている場面

07 短い判断

関連リンク

OpenHarness とは: このオープンソースの Agent Harness では何ができるのですか?

01 オープンハーネスとは何ですか？

02 本プロジェクトの基本機能

1. Agent Loop

2. ツール、スキル、プラグインシステム

3. コンテキストと記憶

4. 当局のガバナンスとセキュリティ境界

5. マルチエージェントの調整

6. マルチプロバイダーのワークフロー

7. React TUI と非対話型モード

03 ohmoとは

04 どんなシーンに適していますか？

05 位置付けをすぐに理解する

参考リンク

Playwright CLI の入門: インストール、スキル、セッション管理、および一般的なコマンド

01 Playwright CLIとは何ですか?

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

1. エージェントのワークフローにさらに適した

2. スキルを使って作業する能力

3. セッション管理が比較的完了している

4. 視覚監視パネルが付属しています

03 設置および環境要件

04 始め方

1. スキルをインストールする

2. エージェントに CLI を直接呼び出させる

3. 最小限の工程を手動で体験

05 --headed、セッションおよびモニタリングパネル

--headed

session

監視パネル

06 最初に覚えるべき一般的なコマンドはどれですか?

ページとインタラクション

ページ構造を取得する

出力結果

タブページ

07 どんな人に向いていますか？

参考リンク

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

01 エルメス代理店紹介

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

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

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

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

4. OpenClaw ユーザーに優しい

03 すぐに始める方法

04 と OpenClaw はどうですか?

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

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

より現実的な選択の提案

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

参考リンク

3. `vm.max_map_count` を確認する

03 `ohmo`とは

05 `--headed`、セッションおよびモニタリングパネル

`--headed`

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

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

OpenClaw 脳に似た記憶アルゴリズム夢を見る: 機械は夢を見始めるが、人間は不眠症になる