gtm-ai-gtm
AIプロダクトの市場投入戦略を支援するスキル。AIの責任問題への反論処理、変動コスト型AIの価格設定、コパイロット/エージェント/チームメイトといったポジショニングの選択、エンタープライズへの自律型ツール販売など、AIプロダクト特有のGTM課題に直面した際に活用できます。
description の原文を見る
Go-to-market strategy for AI products. Use when positioning AI products, handling "who is responsible when it breaks" objections, pricing variable-cost AI, choosing between copilot/agent/teammate framing, or selling autonomous tools into enterprises.
SKILL.md 本文
AI製品のGTM
AI製品向けのゴー・トゥ・マーケット戦略。これらは汎用的なAI原理ではなく、エンタープライズに自律型AIエージェントを販売する際の実践的なパターンです。「自律型」という言葉に買い手が怖気づき、「チームメイト」というフレーミングで案件が進むようになった経験から生まれた戦略です。
使用時期
トリガー:
- 「このAI製品をどう位置付けるか?」
- 「買い手は『AIが本番環境を壊すことを心配している』と言っている」
- 「自律型と呼ぶべきか、それともコパイロットと呼ぶべきか?」
- 「AIの使用量が顧客によって10倍変わる場合、どう価格を決めるか?」
- 「エンタープライズのセキュリティはパスしたが、運用チームが却下した — なぜ?」
背景:
- AIエージェント・プラットフォーム(コーディング、サポート、運用)
- LLMベースのアプリケーション
- 実際に「何かをする」自律型ツール(単に提案するだけではない)
- AI インフラストラクチャ
- AIが意思決定を行うすべてのもの
コア・フレームワーク
1. 本当のエンタープライズAI異議 (思っているのとは異なる)
自律型AIエージェントを販売して学んだこと:
3か月目になると、エンタープライズのセキュリティ審査は高速に進むようになりました。良い兆候ですね?そしてパターンが見えてきました: セキュリティはパスするが、運用チームが却下する。
異議は「AIが本番環境を壊すか?」ではなく、彼らはいずれ壊すことを 前提 にしていました。本当の質問は以下です:
「エージェントが何か間違ったことをしたときに、誰が責任を取るのか?」
「エージェントを信頼するか?」ではなく、「自分たちの チーム がこれを処理できると信頼するか?」です。
なぜこれが重要か:
自律型エージェントは新しい運用負荷を生み出します。あなたが売っているのはAI能力ではなく、組織の対応能力です。あなたのエージェントが午前2時に本番環境を停止させたとき、誰がページャーで呼び出されるのか?誰が修正するのか?誰がVPに説明するのか?
フレームワーク: 責任の段階
AIエージェントをデプロイする前に、エンタープライズは明確な答えが必要です:
- L1対応: 誰がエージェントを監視するのか?(24/7運用チーム、またはオンコール開発チーム?)
- L2エスカレーション: エージェント・アクションが失敗したときに、誰がデバッグするのか?(エージェント・チーム、またはプロダクト・チーム?)
- L3所有権: 何かひどく壊れたときに、誰が顧客とのコミュニケーションを担当するのか?
これら3つすべてに答えられなければ、彼らは購入しません。AIがどんなに優れていても関係ありません。
これはセールス・プロセスをどう変えるか:
従来のアプローチ:
- AIをデモする
- 精度指標を表示する
- ROIについて話す
新しいアプローチ:
- AIをデモする
- 失敗モード を明確に示す
- 「あなたのチームの誰がこのシナリオを処理するのか?」と聞く
- インシデント対応プロセスを一緒に歩む
- AIの失敗を彼らの既存のランブックにマッピングする
質問による適格性調査:
「エージェントがワークフローを壊すアクションを取ったときに何が起きるかを説明してください。誰がアラートを受ける?誰が調査する?ロールバックするか、それとも前に進むかを誰が決定する?」
答えられなければ、彼らは準備ができていません。案件を一時停止して、まずプロセス構築を支援してください。
よくある間違い:
これを プロダクト 異議として扱う(「AIの精度を高くします」)。これは 組織 異議です。精度が上がっても「午前2時に誰がこれを所有するか?」は解決しません。
うまくいった例:
AIエージェントに成功している企業は既に以下を持っています:
- 本番環境システムのためのオンコール・ローテーション
- インシデント対応プレイブック
- 非難しない事後分析文化
- 明確なエスカレーション・パス
苦労している企業:
- 手動デプロイメント・プロセス
- ヒーロー文化(「Steveがすべてを修正する」)
- 公式なインシデント対応がない
- 責任を求める文化
意思決定基準:
エンタープライズに自律型AIをデモする前に、自問してください: 「これが彼らの本番環境を壊すとしたら、彼らのチームの誰がこの修正を所有するか?」答えられなければ、彼らは購入できません。
2. コパイロット vs エージェント vs チームメイト (3つの異なるGTMモーション)
位置付けの罠:
初期のエンタープライズ対話では、「自律型AIエージェント」と位置付けました。買い手は怖気づきました。1語の変更 — 「自律型」→「AIチームメイト」 — で案件進行が測定可能に改善しました。
なぜ?言葉の選択は買い手の心理を形成するからです。
3つのフレーミング:
1. コパイロット (最も安全、最小限の価値)
- 意味: AIが提案し、人間がいつも決定する
- 買い手の心理: 安全に感じ、脅威にならない
- GTMモーション: 開発者導入、ボトムアップ
- ユースケース: コード補完、ライティング支援、検索
- 異議: 「これに払う価値があるのか?」(低い価値認識)
2. エージェント (最も怖い、最高の価値)
- 意味: AIは自律的に行動し、人間は定期的にレビューする
- 買い手の心理: 怖い、人間の置き換えを示唆する
- GTMモーション: エンタープライズ営業、トップダウン
- ユースケース: バッチ処理、自動ワークフロー、運用
- 異議: 「本番環境を壊すとしたら?」(責任の不安)
3. チームメイト (最適な位置)
- 意味: AIと人間が協力し、仕事を分け合う
- 買い手の心理: パートナーシップ、置き換えではない
- GTMモーション: ハイブリッド(開発者導入+マネージャー承認)
- ユースケース: ほとんどのAIエージェント・プラットフォーム
- 異議: 「これを自分たちのワークフローにどう統合するか?」(プロセスの質問)
位置付けのシフト:
以前: 「複雑なワークフローをエンドツーエンドで処理する自律型AIエージェント」
- 開発者: 「クールだけど、怖い」
- マネージャー: 「これはチームを置き換えるのか?」
- 案件進行: 遅い
以後: 「複雑なタスクで自分たちのエンジニアと組むAIチームメイト」
- 開発者: 「これは自分を助ける」
- マネージャー: 「これはチームの生産性を高める」
- 案件進行: 4か月以上停滞していた3件のエンタープライズ案件が、このシフト後8週間以内にクローズ
重要だった言葉の選択:
❌ 言わないこと:
- 「自律型」(怖い)
- 「置き換える」(脅迫的)
- 「完全に自動化」(コントロールなし)
- 「AI-first」(そもそも何?)
✅ 言うこと:
- 「チームメイト」(協力的)
- 「強化する」または「加速する」(支援で、置き換えではない)
- 「あなたがコントロールを保つ」(安心)
- 「反復的な仕事を処理」(具体的な価値)
フレーミングの選択方法:
あなたのAIは人間の承認なしに意思決定を下しますか?
├─ はい → 開発者に売るか、エンタープライズに売るか?
│ ├─ 開発者 → 「エージェント」フレーミング(彼らは自律型を望む)
│ └─ エンタープライズ → 「チームメイト」フレーミング(彼らはコントロールを望む)
└─ いいえ → 「コパイロット」フレーミング(強化、自動化ではない)
厳しい事実:
あなたはエージェントを構築できますが、コパイロットとして位置付けられます。コパイロットを構築し、エージェントとして位置付けることはできません。プロダクト能力が天井を設定し、位置付けがその下のどこに着地するかを選びます。
よくある間違い:
「自律型」を使う理由が「印象的に聞こえるから」。印象的 ≠ 信頼できる。買い手があなたの位置付けに怖気づいたら、彼らを失いました。
3. AI価格設定問題 (使用量が10倍変わる場合)
パターン:
私が取り組んだすべてのAI企業が直面する問題です: 顧客AはAPIコール1,000回/月を使用。顧客Bは10,000回。顧客Bに10倍の料金を請求しますか?はいなら、チャーン。いいえなら、マージンが崩壊。
3つのモデル:
1. シート制 ($Xユーザー/月あたり)
- いつ機能するか: AIが予測可能に人間の仕事を強化する
- 例: コード補完、ライティング支援
- 問題: AIの価値スケーリングを捉えない
- 実際のリスク: 高使用量顧客が最高の顧客だが、低使用量顧客に補助金を出す
2. 使用量ベース ($Xあたり APIコール/予測/時間)
- いつ機能するか: AIが可変的な仕事をし、顧客がユニットを理解する
- 例: 画像生成、文字起こし、バッチML
- 問題: 高使用量顧客には衝撃的な価格
- 実際のリスク: 顧客はプロダクトの使用を 減らす 最適化をする
3. 成果ベース ($X成果達成あたり)
- いつ機能するか: 成果を確実に測定できる
- 例: 「バグ修正ごとに支払う」または「サポートチケット解決ごとに支払う」
- 問題: 測定が難しく、ゲーム化しやすい
- 実際のリスク: AIが性能を発揮しなければリスクをすべて負担
実際に機能すること (ハイブリッド):
基本料金(固定費をカバー) + 可変料金(価値に応じてスケール)。
例の構造:
- 基本: $X/月あたりチーム(プラットフォームへのアクセス)
- 可変: $Y成功したアクション/成果あたり
- なぜ機能するか:
- 基本がインフラ/サポート費用をカバー
- 可変が顧客価値と一致
- 高使用量顧客が罰せられない(より多くの価値を得る)
早期にしたかった価格設定対話:
使用量ベースのAIに価格を付けるとき:
顧客に聞く: 「これを手動でやるのにいくらかかるのか?」
1回のAPIコールが0.10ドルでも労力が2ドルを節約するなら、低く価格設定されています。1回のコールが0.50ドルでも0.40ドルを節約するなら、十分に使用されません。
価格設定ルール:
可変費用は 顧客の代替費用の20-30% である必要があります。価値を捉えるのに十分高く、自由に使用するのに十分低い。
よくある間違い:
OpenAIの価格設定をコピー(1Kトークンあたり0.01ドル)するのが「みんなやってる」から。あなたのコスト構造はOpenAIのコスト構造ではありません。あなたの価値はOpenAIの価値ではありません。あなたのビジネスのために価格設定してください。
4. AI信頼ラダー (登った人から)
パターン:
AIを「信頼してください、機能します」と言って売ることはできません。段階的に信頼を構築します。
第1段階: 透明性 (最初のデモの前)
これら3つのドキュメントをデモの前に送信:
- モデルカード(どのモデル、何で訓練された、どのベンチマークで精度)
- セキュリティホワイトペーパー(データはどこに行くか、どう処理されるか)
- 説明可能性ドキュメント(AI決定をどう解釈するか)
なぜ機能するか: 買い手はデューデリジェンスを行うことを期待しています。デモを求める 前 にドキュメントを送信すれば、自信があり信頼できるように見えます。
第2段階: コントロール (デモ中)
安全メカニズムを表示:
- ユーザーがどのようにAI提案を承認/却下するか
- キルスイッチとロールバック・メカニズム
- 信頼スコアとAIが「確実ではない」と言うとき
なぜ機能するか: 「暴走AI」への恐怖は本物です。コントロール・メカニズムを表示すれば、失敗モードを考慮したことが証明されます。
第3段階: パフォーマンス (週4-8)
機能することを証明:
- ベースライン(人間または以前のツール)との比較ベンチマーク
- 類似企業からのケーススタディ
- 彼らのデータでのライブデモ(可能であれば)
なぜ機能するか: 証拠は約束に勝ります。1つの顧客が「週Xアワーを節約した」と言う方が、100のマーケティング請求よりも価値があります。
第4段階: スケール (真剣に検討しているとき)
エンタープライズ対応を表示:
- エンタープライズ・デプロイメント例
- スケール時のパフォーマンス(レイテンシ、スループット、エラー率)
- コンプライアンス・ドキュメント(SOC 2、GDPR等)
なぜ機能するか: エンタープライズはMVPをデプロイしません。1000ユーザーで落ちないことが証明が必要です。
私がしたシマッタ:
AIの仕組みを説明する前にパフォーマンスを証明しようとしました。買い手はシステムを理解していないので、ベンチマークを信頼しませんでした。順序が重要です。
意思決定基準:
買い手が「これはどう機能するのか?」と聞く前に、デモをしていたら、透明性をスキップしました。戻ってドキュメントを送信してください。
5. エンタープライズAIデモ (成功だけでなく失敗を表示)
機能しないもの:
AIが魔法のようにすべてを解決する本番デモ。買い手は「これはうちのメチャクチャなデータでは機能しない」と思う。
機能するもの:
AIが間違いを犯し、回復するのを表示。本当に。
機能するデモ構造:
1. 問題 (30秒) 「あなたのエンジニアは[具体的なタスク]に時間を費やしています。それがどう見えるか。」
- 表示: 現在の手動ワークフロー
- 定量化: 時間 × エンジニア × 週 = 総コスト
2. AIの試み (60秒) 「AIが同じタスクを処理する方法です。」
- 表示: AIが分析、行動を取る
- キーの動き: AIがエラーまたは不確実性に直面させる
- 表示: AIが再分析、回復、またはヘルプを求める
- ナレーション: 「最初は完璧ではなかった。不確実性を人間のように扱います。」
3. 人間によるレビュー (30秒) 「エンジニアがAIの仕事をレビュー、承認するところです。」
- 表示: エンジニアがAIの仕事を検査
- キーの動き: エンジニアが何かをオーバーライドまたは調整する
- ナレーション: 「人間がコントロールを保つ。AIが反復的な仕事を処理、人間が判断的なコールを処理。」
4. 成果 (30秒) 「[X時間] → [Y分]。エンジニアが成果を所有、AIが実行を加速。」
- 定量化: 時間削減、コスト削減、解放される容量
なぜ機能するか:
- 失敗を表示 → 信頼を構築(隠してない)
- 回復を表示 → AIが堅牢であることを証明
- 人間のオーバーライドを表示 → コントロールを与える
- 節約を定量化 → ROIを具体化
見た例:
完璧なAIを示すデモ → 買い手は懐疑的 不完全で回復するAIを示すデモ → 買い手は関与
よくある間違い:
AIが100%正確な例を選別。買い手は現実世界のデータがメチャクチャであることを知っています。メチャクチャを表示しなければ、隠していると仮定されます。
6. 「誰がこれを所有するか?」異議ハンドラー
異議:
「これは素晴らしく見えますが、AIが何か間違ったことをすると何が起きるのか?」
悪い答え: 「弊社のAIは95%の精度であり、毎週改善しています。」 (翻訳: 「5%の時間に本番環境を壊す、幸運を祈る」)
良い答え: 「良い質問です。失敗シナリオを一緒に歩きましょう。」
その後、聞く:
- 「AIがエラーを引き起こすアクションを取ったときに、チームの誰が調査するか?」
- 「ツール失敗のためのインシデント対応プロセスを持っていますか?」
- 「ロールバック決定を誰が所有するか — それを承認したエンジニア、それとも運用チーム?」
これは何をするか:
- 「壊れるか?」(はい、壊れます)から「失敗をどう処理するか?」に移す
- 彼らの運用成熟度について考えるよう強制
- AIエージェントに対する準備ができているかどうかを明らかにする
フォローアップ:
「ここは推奨です: 低リスク環境で始めてください。AIに非重要なワークフローを2-4週間処理させてください。チームが間違いをどう処理するか見てください。その後、確信が持てたらスコープを拡大してください。」
なぜ機能するか:
完璧さを売っていません。運用成熟度を必要とするツールを売っています。成熟した買い手のためにフィルタリングすることは、未成熟な買い手を説得するより優れています。
パターン:
成熟した買い手: 「ツール失敗のためのランブックは既にあります、AIを追加します。」 未成熟な買い手: 「決して壊れないようにできますか?」
意思決定基準:
買い手が100%精度を要求したら、去ってください。彼らは準備ができていません。インシデント対応プロセスを持ったら戻ってください。
7. AI位置付けの罠 (非対称戦争に対抗)
パターン:
AIエージェント空間で競争しています。すべての競合他社のホームページは同じことを言っています: 「AIで[ワークフロー]を自動化」。あなたの差別化には、買い手が理解しない複雑な技術ベンチマークの説明が必要です。
これは位置付けの罠です: より資金が豊富な企業に対する機能競争をそれらのベースボールグラウンドで行う。
診断方法:
- 5-7の直接競合他社からホームページメッセージを収集
- 共有クレームを識別(これらはコモディティ化されている — ここで勝てない)
- 構造的利点を持つ場所をマップ(単なるプロダクト機能ではない)
- 競合他社が簡単にコピーできない位置を見つける
AIの位置付けで機能する構造的利点:
- ユニークなデータまたはワークフロー所有権(競合他社が複製できない何かを制御)
- デプロイメント柔軟性(オンプレ、プライベートクラウド、顧客管理インフラ)
- 価格設定モデル革新(成果ベース、競合他社がシート制のとき使用量ベース)
- コミュニティまたはエコシステム(時系列に増加するネットワーク効果)
持続しない機能利点:
- 「より高い精度」(競合他社は1スプリントで追いつく)
- 「より高速な推論」(インフラストラクチャはコモディティ化)
- 「より多くの統合」(コピーするのが簡単)
テスト:
すべての位置付けクレームについて、聞いてください: 競合他社が1回のプロダクト・スプリントでこれをコピーできるか?はいなら、これは防御できません。これに基づいてGTMを構築しないでください。
よくある間違い:
みんながすることで「より優れている」と主張。AIでは、ベンチマークは毎月変わります。何が一時的に優れているかではなく、何が構造的に異なるかについて位置付けてください。
8. 天井モーメント適格性 (高意図のAI買い手を見つける)
パターン:
AIエージェントの最高意図エンタープライズ買い手は、既に同等のツールを採用し、その限界に達した人々です。彼らは学習に投資し、問題空間を理解し、アップグレードのための明確なビジネスケースを持っています。
天井モーメントを識別方法:
見込み客は以下を持っています:
- コパイロット/支援ツールを6か月以上使用
- その制限に達した(複雑なタスクを処理できない、スタックと機能しない、十分に自律的ではない)
- 低い切り替え費用(メンタルモデルが転移)
- 明確なビジネスケース(「現在のツールでも手動で週Xアワーを費やしています」)
それらをターゲットする方法:
- あなたのAIプロダクトが補完または置き換わるツール(複数)を識別
- それらのツールが既知であるべき企業のターゲットリストを構築
- フィーチャーではなく制限に関するアウトリーチを作成:
- 「[既存製品]を使用しているチームはしばしば[あなたのプロダクトが提供する能力]が必要なときに天井に達します」
- 既存製品の価値を認める(けなさない)
- 「次のレベル」として位置付け、置き換えではなく
なぜこれはより良く変換するか:
天井モーメント対話はコールドアウトリーチより3-5倍変換するのは以下のため:
- 見込み客は既に問題を理解
- 彼らは既にカテゴリに投資
- 彼らは既に内部予算を割り当てている
- 彼らは何が不足しているかを明確に述べられる
適格性質問:
「現在のツールで自動化しようとした最も複雑なタスクは何で、どこで壊れましたか?」
彼らが具体的な答え、具体的な痛みを持っていたら、彼らは天井モーメント買い手です。「機能します」と言ったら、準備ができていません。
よくある間違い:
ツール素朴な見込み客にAIエージェント導入を説得しようとする。悪い変換率、長い教育サイクル、彼らは「何もしない」の代わりに「より良くやる」と比較します。既にカテゴリを信じる買い手をターゲットしてください。
決定木
どの位置付けを使うべきか?
あなたのAIは自律的に行動しますか(アクションごとに承認なし)?
├─ はい → 誰に売っていますか?
│ ├─ 開発者 → 「エージェント」フレーミング
│ └─ エンタープライズ → 「チームメイト」フレーミング
└─ いいえ → 「コパイロット」フレーミング
どの価格設定モデルを使うべきか?
顧客成果を確実に測定できますか?
├─ はい → 成果ベース(または成果成分を持つハイブリッド)
└─ いいえ → 続行...
│
使用量が顧客によって5倍以上変わりますか?
├─ はい → ハイブリッド(基本 + 使用量)
└─ いいえ → シート制
この買い手はAIエージェントに対して準備ができていますか?
ツール失敗のためのインシデント対応プロセスがありますか?
├─ はい → 続行...
│ │
│ 本番システムのためのオンコール・ローテーションがありますか?
│ ├─ はい → 適格な買い手
│ └─ いいえ → 最初にビルドを支援
└─ いいえ → 準備ができていない(6か月後に戻る)
よくある間違い
1. 「自律型」を使う理由が「印象的に聞こえるから」
- これが案件を遅くするのを見ました。「自律型」はエンタープライズを怖がらせます。「チームメイト」が高速に進みます。
2. AI失敗モードを隠す
- 買い手は現実世界のデータがメチャクチャであることを知っています。メチャクチャを表示しなければ、隠していると仮定されます。
3. 「本番環境を壊すか?」を異議として扱う
- 本当の異議: 「壊れたとき誰が責任を取るか?」組織的準備、精度ではない。
4. OpenAIのようにAIを価格設定する
- あなたのコスト構造は彼らのものではありません。顧客の代替費用の20-30%のために価格設定してください。
5. デモの前に透明性ドキュメントをスキップ
- 順序が重要。透明性 → コントロール → パフォーマンス → スケール。ステップをスキップしないでください。
6. 完璧なAIをデモ
- 間違い + 回復を表示。偽の完璧さより多くの信頼を構築します。
7. 100%精度を要求する買い手に売る
- 彼らは準備ができていません。インシデント対応プロセスを持つ成熟した買い手のためにフィルタリングしてください。
クイック・リファレンス
エンタープライズ異議チェックリスト:
- 「AIが本番環境を壊すとき誰がページャーで呼ばれるか?」 → オンコール・ローテーションにマップ
- 「AI失敗をデバッグするのは誰か?」 → インシデント対応にマップ
- 「顧客とのコミュニケーションを誰が所有するか?」 → エスカレーション・パスにマップ
位置付けの言葉の選択:
- ✅ チームメイト、強化、加速、あなたがコントロール
- ❌ 自律型、置き換え、完全に自動化、AI-first
デモ構造:
- 定量化されたコストを持つ問題(30秒)
- 失敗/不確実性を含むAIの試み(60秒)
- 人間によるレビューとオーバーライド(30秒)
- ROIを持つ成果(30秒)
信頼ラダー:
- 透明性(モデルカード、セキュリティ、説明可能性)
- コントロール(承認ワークフロー、キルスイッチ、信頼スコア)
- パフォーマンス(ベンチマーク、ケーススタディ、ライブデモ)
- スケール(エンタープライズ・デプロイメント、コンプライアンス、SLA)
価格設定ハイブリッド公式:
- 基本: $X/月(固定費をカバー)
- 可変: $Yあたりユニット(顧客の代替費用の20-30%)
関連スキル
- positioning-strategy: 一般的な位置付けフレームワークとテスト
- technical-product-pricing: AI固有パターンを含む価格設定モデル
- enterprise-account-planning: エンタープライズAI案件管理
開発者ツールとインフラストラクチャ全体のエンタープライズAIエージェントGTMに基づく。エンタープライズ案件サイクルで自律型AIプロダクトを販売する過程で引き出されたパターン — いくつかは直接実施、その他はセールス・リーダーシップと並行 — 機能競争から構造的差別化への移行を促進した位置付け罠診断、アウトバウンド変換を大幅に改善した天井モーメント適格性、セキュリティ、運用、エンジニアリング買い手ペルソナ全体でテストされたフレームワークを含む。理論ではなく、「自律型」が対話を殺し「チームメイト」が変換された案件からの教訓。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- github
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/github/awesome-copilot / ライセンス: MIT
関連スキル
agent-browser
AI エージェント向けのブラウザ自動化 CLI です。ウェブサイトとの対話が必要な場合に使用します。ページ遷移、フォーム入力、ボタンクリック、スクリーンショット取得、データ抽出、ウェブアプリのテスト、ブラウザ操作の自動化など、あらゆるブラウザタスクに対応できます。「ウェブサイトを開く」「フォームに記入する」「ボタンをクリックする」「スクリーンショットを取得する」「ページからデータを抽出する」「このウェブアプリをテストする」「サイトにログインする」「ブラウザ操作を自動化する」といった要求や、プログラマティックなウェブ操作が必要なタスクで起動します。
anyskill
AnySkill — あなたのプライベート・スキルクラウド。GitHubを基盤としたリポジトリからエージェントスキルを管理、同期、動的にロードできます。自然言語でクラウドスキルを検索し、オンデマンドでプロンプトを自動ロード、カスタムスキルのアップロードと共有、スキルバンドルの一括インストールが可能です。OpenClaw、Antigravity、Claude Code、Cursorに対応しています。
engram
AIエージェント向けの永続的なメモリシステムです。バグ修正、意思決定、発見、設定変更の後はmem_saveを使用してください。ユーザーが「覚えている」「記憶している」と言及した場合、または以前のセッションと重複する作業を開始する際はmem_searchを使用します。セッション終了前にmem_session_summaryを使用して、コンテキストを保持してください。
skyvern
AI駆動のブラウザ自動化により、任意のウェブサイトを自動化できます。フォーム入力、データ抽出、ファイルダウンロード、ログイン、複数ステップのワークフロー実行など、ユーザーがウェブサイトと連携する必要があるときに使用します。Skyvernは、LLMとコンピュータビジョンを活用して、未知のサイトも自動操作可能です。Python SDK、TypeScript SDK、REST API、MCPサーバー、またはCLIを通じて統合できます。
pinchbench
PinchBenchベンチマークを実行して、OpenClawエージェントの実世界タスクにおけるパフォーマンスを評価できます。モデルの機能テスト、モデル間の比較、ベンチマーク結果のリーダーボード提出、またはOpenClawのセットアップがカレンダー、メール、リサーチ、コーディング、複数ステップのワークフローにどの程度対応しているかを確認する際に使用します。
openui
OpenUIとOpenUI Langを使用してジェネレーティブUIアプリを構築できます。これらはLLM生成インターフェースのためのトークン効率的なオープン標準です。OpenUI、@openuidev、ジェネレーティブUI、LLMからのストリーミングUI、AI向けコンポーネントライブラリ、またはjson-render/A2UIの置き換えについて述べる際に使用します。スキャフォルディング、defineComponent、システムプロンプト、Renderer、およびOpenUI Lang出力のデバッグに対応しています。