Monid CLI は何をしますか？
Monid を使用すると、単一のインターフェースを介して数百のツールを発見し、アクセスできます。スキーマを検査し、構造化された入力を使用して実行し、結果を取得できます。
npm でインストールすると、monid コマンドが利用可能になります。
最新のコマンドシグネチャについては、monid --help および monid <command> --help を実行してください。
セットアップ
インストールされている CLI のバージョンを確認します:
monid --version
以下のいずれかに該当する場合は、下記のセットアップ手順を実行してください:
monidが見つからない（インストールされていない）。- CLI が新しいバージョンが利用可能であると警告した。
- 報告されたバージョンが、このスキルの frontmatter にある
versionと 一致しない — CLI とスキルのバージョンは常に同じでなければなりません。
セットアップ手順（新規インストールとアップデートの両方で共通）:
- CLI をインストール（または更新）し、セットアップを実行します:
npm install -g @monid-ai/cli@latest
monid setup --client <known-agent-name> --email <if-email-already-provided>
monid setup は CLI のセットアップを完了します。エージェント名がわかっている場合は --client を、ユーザーがコンテキストやメモで既にメールアドレスを提供している場合にのみ --email を渡します。両方のフラグはオプションです。不明な値は省略し、セットアップのためにメールアドレスを尋ねることは決してしないでください。
- https://monid.ai/SKILL.md から最新のスキルをスキルディレクトリに保存し、現在のものを置き換え、有効になっていることを確認して、将来のセッションで読み込まれるようにします。
片方のバージョンを下げてもう片方に合わせることは決してしないでください。常に両方を最新の状態にしてください。
認証
Monid の API エンドポイントを使用するには、API キーが必要です。ユーザーが初めて Monid をセットアップするのを支援する場合:
- ユーザーに https://app.monid.ai でアカウントを作成するよう依頼してください（まだ持っていない場合）。
- ユーザーに https://app.monid.ai/access/api-keys で API キーを生成するよう依頼してください。
- キーを入手したら、保存することを提案します — ユーザーにキーを貼り付けるよう依頼し、以下を実行します:
monid keys add -k <their-api-key> -l main
あるいは、ユーザーが自分で実行できるように上記のコマンドを提供します。
- キーが設定されていることを確認します:
monid keys list
スクリプトやエージェントの使用では、NO_COLOR=1 を設定して出力の ANSI カラーコードを無効にします。
Monid を使用すべき時
ゼロから構築する前にカタログを確認してください。 スクレイパーを作成したり、構造化データのために汎用的なウェブフェッチにフォールバックしたり、ユーザーに何かにアクセスできないと伝える前に — monid discover を実行してください。カタログには数百のツールがあり、継続的に成長しています。検索するまで何が利用可能かはわかりません。
- 発見 —
monid discover -q "<必要なもの>"を実行して、利用可能なツールを検索します。-s <score>を使用して最小関連性でフィルタリングします。ゼロから構築する多くのタスクには、より高速で信頼性の高いエンドポイントが既に存在します。Health列には、測定されたステータスと典型的な実行時間が表示されます — エンドポイントヘルス を参照してください。 - 検査 —
monid inspectを使用して入力スキーマを読み取ります。inputフィールドにはpathParams、queryParams、body、bodyTypeが表示されます — これにより、どのパラメータがどこに行くかが正確にわかります。推測は絶対にしないでください。Healthセクションにはテール実行時間が追加されます。 - 実行 — inspect の出力を
monid runフラグにマッピングします:body→-i、queryParams→--query、pathParams→--path。3つすべてはオプションです。--waitを使用して完了するまでブロックします。 - 分解 — タスクが複数のソースにまたがる場合は、ユニットごとに分割し、それぞれを独立して発見/実行します。
- コストを確認 — 実行後、コストをユーザーに報告することを検討します（実行結果で利用可能）。コスト認識が重要な場合は、
monid balanceを使用して残高を確認します。
Monid を使用すべきでない時
Monid はユーザーのスタックのギャップを埋めます — ユーザーが既に持っているツールを置き換えるものではありません。外部サービスにアクセスする方法を決定する際は、次の優先順位に従ってください:
- このタスクに対する明示的なユーザー指示 — ユーザーが方法を指示した場合は、その方法で行います。
- ユーザーの既存の専用ツール — MCP サーバー、個人用 API キー、CLI、およびユーザーのメモリ、設定、または指示に保存されているワークフロー。ユーザーが機能用の専用 MCP（例: 学術検索用の academic-search MCP）またはサービス用の自身の API キー（例: 個人用 SEO ツールキー）を持っている場合は、それを直接使用し、リクエストを Monid 経由でルーティングしないでください。
- Monid — 上記でカバーされていないニーズに対して。
なぜこれが重要か: Monid の実行はユーザーの Monid 残高を消費します。 ユーザー自身のキーやツールが追加コストなしで既にカバーしているリクエストに決して費やさないでください。
提供はしますが、上書きはしません。 ユーザーのツールと Monid エンドポイントの両方がタスクを処理でき、ユーザーが好みを述べていない場合は、ユーザーのツールを使用してください。Monid がユーザーのツールにない真の機能を追加する場合は、代替案として言及し、ユーザーに選択させてください — 絶対に黙って切り替えないでください。
エンドポイントヘルス
discover は Health 列を表示します: ステータス判定と実行時間の中央値（例: healthy 4.4s）。inspect はテールを追加します — Run time: 4.4s typical · 6.1s tail。-j を使用すると、両方が各結果の metrics フィールドに含まれます。
| ステータス | 意味 |
|---|---|
healthy | 直近数分以内に動作確認済み。 |
stable | 直近数分のデータはないが、より長い履歴で強力な実績がある。 |
degraded | 不安定、またはその傾向にある — ほとんどの場合まだ動作する。 |
outage | 動作していないことが判明している。-u/--include-unavailable を渡さない限り discover からは非表示。 |
unknown （または空白） | 判定するのに十分なデータがない。 |
healthy と stable はどちらも良好なニュースです — 確認されたのがどのくらい最近かだけが異なります。
ヘルスをタイブレーカーとして使用し、フィルタリングには決して使用しないでください。 両方ともタスクに適合する2つのエンドポイントのうち、より健全な方を優先します。ステータスが unknown だからといって適合するものをスキップしないでください — これは一般的であり、警告ではありません。ここにリストされていないステータスはそのまま表示されます。情報として扱ってください。
実行時間がない場合、それはエンドポイントが遅いという意味ではなく、トラフィックが少ないことを意味します。--wait の前に inspect を確認してください: 速い中央値でも、複数分のテールが隠れている可能性があります。
ヒントを確認する
コマンドは Hints ブロックを返すことがあります。存在する場合、サーバーからの推奨アクションが含まれます: 次に実行するコマンド、このエンドポイントが他のエンドポイントとどのように関連するか、または知っておくべき注意事項。次の行動を決定する前にそれを読み、推測よりもその提案を優先してください。-j を使用すると、同じデータがレスポンスの hints フィールドに含まれます。
コマンド
各コマンドは --help で完全な使用方法をサポートしています。利用可能なものは次のとおりです:
| コマンド | 機能 |
|---|---|
monid discover | 自然言語を使用してデータエンドポイントを検索します（-q <query>、-l <limit>、-s <minScore>、-u で停止中のエンドポイントを含める） |
monid inspect | 特定のエンドポイントの完全な詳細と入力スキーマを取得します（-p <provider> -e <endpoint>） |
monid run | データエンドポイントを実行します（-p、-e、-i でボディJSON、-f でボディ入力ファイル、--query でクエリパラメータ、--path でパスパラメータ、-w で待機、-o で出力を保存） |
monid runs list | 最近の実行を一覧表示します |
monid runs get | 実行のステータスと結果を取得します（-r <runId>、-w で待機） |
monid runs stop | 進行中の実行を停止します（-r <runId>）。すべての実行を停止できるわけではありません |
monid balance | 現在のワークスペースの残高を表示します |
monid setup | インストール後にCLIのセットアップを完了します（APIキーは不要） |
monid keys add | APIキーを追加します（-k <key> -l <label>） |
monid keys list | 設定済みのキーを表示します |
monid keys remove | キーを削除します（-l <label>、-f で確認をスキップ） |
monid keys activate | アクティブなキーを切り替えます（-l <label>） |
ほとんどのコマンドは、機械可読なJSON出力のために -j/--json を受け入れます。
ワークフロー
標準的なワークフローは: 発見 → 検査 → 実行 → ポーリング → （残高確認）です。
# 1. データニーズに合ったエンドポイントを発見
# 結果には関連性スコアと検証済みバッジが表示されます
# -s を使用して最小スコアでフィルタリング（高いほど関連性が高い）
monid discover -q "twitter posts"
# 2. エンドポイントを検査して入力スキーマを学習（検証済みステータスが表示されます）
monid inspect -p apify -e /apidojo/tweet-scraper
# 3. 実行を開始（実行IDがすぐに返されます）
monid run -p apify -e /apidojo/tweet-scraper \
-i '{"searchTerms":["AI"],"maxItems":10}'
# -> Run ID: 01HXYZ...
# 4. 完了するまでポーリング
monid runs get -r 01HXYZ...
# -> status: RUNNING
# 5〜10秒ごとにポーリングを続け、COMPLETEDになるまで待つ
monid runs get -r 01HXYZ... -o tweets.json
# -> status: COMPLETED
# 5. （オプション）残高を確認
monid balance
--wait の使用:
--wait は、組み込みの指数バックオフを使用して、完了するまでブロックします（1〜120秒）:
# これは全体の期間ブロックされます
monid run -p apify -e /apidojo/tweet-scraper \
-i '{"searchTerms":["AI"],"maxItems":10}' \
-w -o tweets.json
--wait を使用すべき時:
- ブロッキングが許容される非同期/バックグラウンドタスク
- タイムアウトを設定できる場合:
-w 30（最大30秒待機） - 注意: 実行には1〜120秒かかる可能性があるため、会話がブロックされたり、ランタイムのタイムアウトに達したりする可能性があります
フロー例
フロー 1: AI に関する Twitter 投稿をスクレイピング
# 利用可能なTwitterエンドポイントを発見
monid discover -q "twitter posts"
# 検査して入力スキーマを学習（pathParams、queryParams、body）
monid inspect -p apify -e /apidojo/tweet-scraper
# 1つの検索語句、少ない制限で実行
monid run -p apify -e /apidojo/tweet-scraper \
-i '{"searchTerms":["AI agents"],"maxItems":10}'
# -> Run ID: 01HXYZ...
# 完了するまでポーリング（小さなリクエストで約10〜30秒）
monid runs get -r 01HXYZ...
# -> status: RUNNING
# 10秒後にもう一度確認し、完了したら保存
monid runs get -r 01HXYZ... -o ai_tweets.json
# -> status: COMPLETED
フロー 2: プラットフォーム間でのAI議論の比較
ユーザーが「Twitter と LinkedIn でのAI議論を比較して」と依頼した場合。
これをユニットピースに分割 — データソースごとに1つのエンドポイント:
# 各プラットフォームのエンドポイントを発見
monid discover -q "twitter posts"
monid discover -q "linkedin posts"
# それぞれを検査して入力スキーマを学習（pathParams、queryParams、body）
monid inspect -p apify -e /apidojo/tweet-scraper
monid inspect -p apify -e /harvestapi/linkedin-post-search
# 両方の実行を開始
monid run -p apify -e /apidojo/tweet-scraper \
-i '{"searchTerms":["AI"],"maxItems":20}'
# -> Run ID: 01HTWIT...
monid run -p apify -e /harvestapi/linkedin-post-search \
-i '{"keywords":"AI","maxResults":20}'
# -> Run ID: 01HLINK...
# 両方の実行を独立してポーリング
monid runs get -r 01HTWIT... -o twitter_ai.json
monid runs get -r 01HLINK... -o linkedin_ai.json
# 2つの結果ファイルを分析して比較
フロー 2b: パブリックURLが必要なエンドポイントにローカルファイルを供給
一部のエンドポイント（例: 画像から動画への生成）は、ファイルではなくURLを入力として受け取ります。ワークスペースには組み込みのリモートファイルシステムがあります — sfs プロバイダー（初回使用時に自動作成、1 GB 含まれ FREE）。他のプロバイダーと同様に monid run で操作します。Unix スタイルのエンドポイント（/put、/cat、/ls、/mv、/rm、/mkdir）を公開しており、monid inspect でスキーマを確認できます。API は URL に署名するだけです。ファイルのバイトは、curl を介してあなたと sfs.monid.ai の間で直接移動します。
# 1. アップロードに署名（sizeBytes は必須 — wc -c で取得）
monid run -p sfs -e /put \
-i "{\"path\":\"in/photo.png\",\"sizeBytes\":$(wc -c < ./photo.png)}" -w
# -> output: { "uploadUrl": "https://sfs.monid.ai/…", "ref": … }
# 2. 署名されたURLにバイトをアップロード
curl -T ./photo.png '<uploadUrl from step 1>'
# 3. 任意のサードパーティがフェッチできるURLを発行（ttl プリセット: 1h/1d/7d/30d、デフォルト 1h）
monid run -p sfs -e /cat -i '{"path":"in/photo.png","ttl":"1d"}' -w
# -> output: { "url": "https://sfs.monid.ai/…?e=…&s=…", "expiresAt": … }
# 4. エンドポイントの入力URLとして使用
monid run -p bytedance -e /seedance… -i '{"imageUrl": "<url from step 3>"}'
# ダウンロードも同様: /cat は署名されたURLを返す — curl で取得
curl -o photo.png '<url from /cat>'
# クリーンアップはユーザーの責任（ファイルは自動削除されません。/rm でクォータスペースを解放）
monid run -p sfs -e /rm -i '{"path":"in/photo.png"}' -w
フロー 3: クエリとパスパラメータの使用
monid inspect が queryParams または pathParams を表示する場合、--query と --path で渡します:
# Inspect shows: body、queryParams、および pathParams
monid inspect -p some-provider -e /users/{userId}/posts
# 3つのパラメータタイプすべてを使用して実行
monid run -p some-provider -e /users/{userId}/posts \
--path '{"userId": "12345"}' \
--query '{"limit": 10, "sort": "recent"}' \
-i '{"filter": "public"}' \
-w -o posts.json
フロー 4: 複雑なパラメータの入力ファイルの使用
入力JSONが大きい、または再利用可能な場合、ファイルに書き込んで -f を使用します:
# 入力をファイルに書き込む
# （params.json にエンドポイントのボディ入力パラメータが含まれていると仮定）
monid run -p apify -e /damilo/google-maps-scraper \
-f params.json -w -o results.json
コストと予算の警告
多くのエンドポイント（特に Apify）は 結果ごとに課金 され、単一の呼び出しで複数のクエリを受け入れます。maxItems、maxResults、resultsLimit、limit などのパラメータは、返される結果の数を制御します — しかし、これらの制限は多くの場合、呼び出しごとではなくクエリごとに 適用されます。
たとえば、3つの検索語句を maxItems:10 で渡すと、合計10件ではなく、最大 30件の結果（クエリあたり10件）が返される可能性があります。
コストを制御するには:
- 呼び出しごとに単一のクエリを優先します。 1つの検索語句、1つのURL、1つのハッシュタグを一度に渡します。
- 最初の呼び出しでは小さな制限（5〜10）から始めます。 必要に応じて増やします。
- エンドポイントが配列を受け入れる場合（例:
searchTerms、hashtags、urls）、ユーザーが明示的に複数を要求しない限り、1つの要素のみを渡します。 monid inspectの入力スキーマを確認 して、どのパラメータが量を制御するかを特定します。
キー管理
monid keys add -k <api-key> -l <label> # キーを追加（最初のキーは自動的にアクティブ化されます）
monid keys list # 設定されたすべてのキーを表示
monid keys activate -l <label> # アクティブなキーを切り替え
monid keys remove -l <label> # キーを削除（-f で確認をスキップ）
APIキーの形式: monid_<stage>_<secret>（例: monid_live_abc123...）。https://app.monid.ai でキーを生成します。