ツール連携

openclawツール連携

`openclaw onboard --install-daemon`で手元のマシンにGatewayを常駐させると、セッション、ツール、イベント、チャネル接続がそこへ集約され、Control UI、CLI、TUI、接続済みのメッセージングチャネルが同じアシスタントを共有します。モデルはホスト型でもローカルでも構成でき、機能追加は本体の改造ではなくplugin SDKで作るプラグインを前提としています。一方で想定利用者は単独のオペレーターで、メインセッションのツールはサンドボックスを明示的に設定しない限りホスト上でそのまま実行され、DM可能なチャネルでは受信メッセージを未信頼の入力として扱う前提になっています。他のユーザーを参加させたりGatewayを外部へ公開したりする構成は、README自体がsecurityとsandboxingのガイドを先に読むよう促している領域であり、チームでの共有運用を第一に考えるなら選択肢から外れます。

hermes-agentツール連携

Nous Research自身が開発するエージェント本体で、TUIと単一のgatewayプロセスがTelegram、Discord、Slack、WhatsApp、Signal、Emailの会話を束ね、cronスケジューラ、隔離されたサブエージェント、local/Docker/SSH/Singularity/Modal/Daytona/Vercel Sandboxという7種類のターミナルバックエンドを備えます。核になるのは閉じた学習ループで、定期的な促しに応じて記憶を整理し、複雑なタスクの後に自らスキルを作り、FTS5とLLM要約で過去セッションを検索します。裏を返せば、有用さの源である状態が`~/.hermes`配下に溜まり続け、バージョン管理の外で育つため、定期的な棚卸しが前提になります。組み込み用のライブラリではなく運用するアシスタントであり、READMEが記載するのはhermesのサブコマンドとスラッシュコマンドで、埋め込み用のAPIではありません。自作コードから呼ぶエージェントループが欲しい用途には向きません。シェルを扱えるエージェントをチャット経由で露出させる以上、コマンド承認とDMペアリングの設定は任意の飾りではなくなります。

n8nワークフロー

数百のサービスをビジュアルキャンバス上で連携させるツールで、近年はそのフロー内にLLMエージェントを組み込む用途が増えています。最初に確認すべきはライセンスです。OSI承認のオープンソースではなく、Sustainable Use Licenseによるソース公開型にあたります。社内利用やセルフホストは可能ですが、ホスティングサービスとして再販することは認められていません。

LangChainフレームワーク

本当の価値は網羅性にあります。必要なモデル、ベクトルストア、APIのアダプタはたいてい既に存在し、着想からプロトタイプまでの距離が短くなります。抽象化の階層が深いという評価は根強く、多くのチームは連携部分にこれを使い、制御フローが複雑になった段階でより明示的な実装に移行しています。

Browser Useコンピュータ操作

スクリーンショットからクリック座標を推測させるのではなく、ページ上の操作可能な要素を抽出して構造化リストとしてモデルに渡します。この方式により、フォーム入力やスクレイピングでの安定性が明確に高くなります。一方でcanvas主体のアプリケーションや、bot対策の強いサイトでは読み取れるDOMが存在せず、精度が落ちます。

MCP Reference Serversプロトコル

Model Context Protocolを理解する最も確実な方法は、正しく実装されたサーバーを読むことであり、この集合がそれにあたります。実用的なコネクタとしても、自作する際に写経する雛形としても機能します。

skillsツール連携

Googleが自ら書いた運用知識を100件超のskillディレクトリに収めたリポジトリで、`npx skills add google/skills`から必要なものだけを選んで導入します。中心は`skills/cloud`で、GKEやBigQuery、Agent Platform、Well-Architected Frameworkの6つの柱までを扱い、`skills/ads`と`skills/analytics`にはGoogle Ads API、Google Mobile Ads SDK、IMA SDK、Google Analyticsの2種類のAPI向けのskillが並びます。厚みは一様ではなく、`skills/cloud/gke-*`だけで29件を占める一方、Cloud RunとFirebaseは各1件にとどまり、README自身がactive developmentの段階だと断っています。Google Cloudも広告・アナリティクス製品も使わない構成には得るものがなく、アプリ開発側の守備範囲もGoogle Mobile Ads SDKまでで、Android・Flutter・Dart・Genkit・ADKのskillはREADMEがリンクを張るだけの別リポジトリにあります。

codex-securityガードレール

基本形は`npx @openai/codex-security scan .`で、結果のJSONはstdoutに出ます。`--mode deep`ではworkerとsubagentを並べ、新しい検出が出なくなるまで探索を続けます。再スキャン時は`scans compare BEFORE_SCAN_ID AFTER_SCAN_ID`が根本原因で前回と突き合わせ、new／persisting／reopened／resolved／unknownに分類するため、差分だけを追えます。ただし探索は既定で96時間まで回る長丁場であり、コミット前の軽量チェックには向きません。実行にはCodex Securityへのアクセスが前提で、一部のサイバーセキュリティ要求やprotected findingsはTrusted Access for Cyberの承認が必要になる点も、導入前に確認しておきたいところです。

numbatガードレール

デスクトップ・CLI・IDE・ゲートウェイの各エージェントの動きをhookやplugin、OTLP/HTTPのログエクスポータ経由で取り込み、単一のイベントモデルへ正規化したうえでローカルのCELルールで評価し、events・findings・enforcement決定をバージョン付きNDJSONとして書き出します。`numbat scan`はディスク上のセッション成果物を読むため、事前に計装していなかった過去の作業も後から再構成できます。一方で遮断は保守的な設計で、enforceモードは既定で無効、同梱ルールはすべて監視専用なので、実際に止めるにはルールYAMLを運用側のディレクトリへ複製し、idを保ったままenforce: trueを追加してversionを上げる手順が必要です。観測できる範囲はエージェントとサーフェスごとにcoverage matrixで決まり、永続化されなかった活動は後から復元できず、findingsは実行された事実の証明ではなくルールの一致にすぎません。網羅的な記録や確定的な事実認定を期待する用途には向きません。