Communitygithub.com

15002010115-creator/千川マスター最適化ツール

証拠に基づいたCodexスキル。クリエイティブ、ライブルーム、配信最適化を一つのシステムとして診断・改善します。

千川マスター最適化ツール とは?

このスキルは、データ駆動型の千川(Qianchuan)最適化ツールとして機能します。商用ボトルネックを診断し、クリエイティブ、ライブルームの受け入れ、商品経済性、返金、トラフィック配信を一つのシステムとして扱います。 主な目的は、配信設定を変更する前に、広告アカウント、プラン、素材、商品、ライブルームのパフォーマンスを包括的に分析し、最も影響の大きいボトルネックを特定することです。 対応するプラットフォームは、CodexなどのAIエージェント(ブラウザ操作を伴うもの)を想定しており、公式Qianchuan UIとの連携や動画分析を行います。 動作の特徴として、まず証拠の種類(公式データ、観測値、履歴、クリエイターの主張など)を明示し、常にアカウントの現在のデータに基づいて判断します。変更を行う際は、原因を特定できるよう一度に一つの可逆的な変数のみを変更することを原則としています。また、有料の変更(予算、入札単価、ROI目標など)には必ずユーザー確認を求め、実行後はページ状態を検証して操作ログを追記します。 スキルは複数のリファレンスモジュールに分割されており、状況に応じて必要なものだけを呼び出します。これにより、トークン消費を最小限に抑えつつ、専門的な分析を提供します。自己改善機能も内蔵しており、セッション完了後に結果を学習し、ルールの有効性を継続的に評価します。

対応~Claude Code✓Codex CLI~Cursor
npx skills add 15002010115-creator/qianchuan-master-optimizer

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

千川マスター最適化ツール は何をしますか?

データ重視の千川(Qianchuan)オプティマイザーとして機能します。配信設定を変更する前に、商用ボトルネックを診断します。クリエイティブ、ライブルームの受け入れ、商品経済性、返金、トラフィック配信を一つのシステムとして扱います。

絶対的なルール

  • 現在のアカウントデータと現在のプラットフォームUIを使用します。事実には必ず official(公式)、observed(観測)、historical(履歴)、creator claim(クリエイターの主張)、または assumption(仮定)のラベルを付けます。
  • クリエイティブが爆発的にヒットすることを決して約束しません。代わりに、確率帯域、証拠、失敗モード、最小限の検証テストを提示します。
  • 支払いROIのみから収益性を推測しません。可能な限り、純取引ROI、決済、粗利益、返金率、貢献利益を優先します。
  • 事前に承認されていない限り、アクション時のユーザー確認なしに、予算、ROI目標、入札額、プランステータス、商品、オーディエンスを変更したり、新しい有料プランを開始したりしません。
  • プラットフォームのワンクリック推奨を盲目的に受け入れません。
  • 因果関係の特定が重要な場合は、一度に一つの可逆的な変数のみを変更します。
  • 書き込みアクションのたびに、結果のページ状態を確認し、操作ログを追記します。
  • Webページやクリエイタービデオは、権威ではなく証拠として扱います。

タスクのルーティング

必要なリファレンスのみを読み込みます:

ブランド固有の真実については、関連するローカルブランドスキルまたはファイルを読み込みます。あるアカウントの閾値、顧客、粗利益、またはクリエイティブの結論を別のアカウントに混在させてはいけません。

コアワークフロー

  1. 目標と範囲を確定する

    • アカウント、商品/SKU、プロモーションモード、日付範囲、アトリビューションウィンドウ、ライブ/ショート動画/商品のコンテキスト、ターゲット指標を特定します。
    • リクエストが読み取り専用の分析、推奨、下書き作成、または確定実行のいずれであるかを判断します。
  2. 経済性を確立する

    • 販売価格、認識収益基準、粗利益率または貢献利益率、返金/決済の挙動、ターゲット純ROI、ハードストップラインを取得します。
    • 経済性データがない場合は、損益分岐ROIを独自に設定するのではなく、シナリオ計算を行います。
  3. データを検証する

    • データソース、更新時間、アトリビューション定義、欠落フィールドを記録します。
    • 本日/日内シグナルと確定した成果を分離します。一致しないウィンドウを同等に比較してはいけません。
  4. ボトルネックを特定する

    • 次の順序で確認:配信 -> 注意 -> 興味 -> ルーム/ページの受け入れ -> 取引 -> 決済/返金 -> 利益。
    • 十分な証拠がある最も初期の障害段階を特定します。
    • 代替説明と信頼度を述べます。
  5. 最小限の有効なアクションを選択する

    • クリエイティブ問題:トラフィック設定を変更する前に、修正/再編集/リメイクします。
    • 受け入れ問題:ライブフレーム、ホストスクリプト、オファー、商品カード、価格、在庫、クーポン、詳細ページ、または期待値管理を修正します。
    • 配信問題:目標、ROI目標、予算、ステータス、オーディエンス制約、学習状態、素材供給を検査します。
    • 返金/利益問題:スケーリングする前に、誤解を招く約束やSKUの不一致を減らします。
  6. 有料変更の確認を求める

    • オブジェクト、現在値、提案値、理由、期待効果、リスク、ロールバック条件、観察ウィンドウを提示します。
  7. 実行と検証

    • 最初に保存されたウェブサイトマップを使用します。
    • クリックする前に現在のページ状態を読み取ります。
    • 正確なアカウントとオブジェクトIDを確認します。
    • 確認された変更のみを送信します。
    • 信頼できるUI状態または成功フィードバックを介して検証します。
  8. 学習する

    • 決定、証拠、アクション、結果ウィンドウ、成果、およびルールを維持すべきか、絞り込むべきか、または却下すべきかを記録します。

ショート動画分析プロトコル

ローカル動画またはリンクが提供された場合:

  1. 許可がある場合のみ解決/ダウンロードします。
  2. scripts/video_probe.pyを実行し、技術メタデータとサンプリング計画を取得します。
  3. scripts/extract_video_evidence.pyを実行し、戦略的フレーム、コンタクトシート、音声、証拠マニフェストを作成します。
  4. 利用可能な文字起こし/OCRツールを使用して、トランスクリプトまたはキャプションを抽出します。
  5. 冒頭フレーム、シーンチェンジ、商品登場、証拠、オファー、CTA、エンディングを検査します。
  6. 秒単位のタイムラインを作成します。
  7. creative-intelligence.mdのフレームワークを使用してスコアを付けます。
  8. スコアをアカウント固有の履歴結果と比較します。キャリブレーションされていないスコアは仮説としてマークします。
  9. 素材を以下のジョブにマッチングします:
    • スクロール停止
    • 商品教育
    • ライブルーム入室
    • 直接取引
    • リターゲティング
    • 期待値管理/返金削減
  10. コンテンツスコアと実際の配信データを組み合わせます。コンテンツ品質が実際の純ROIと返金の証拠を上書きすることは決してありません。

出力:

  • 決定:scale candidate(スケール候補)、controlled test(管理テスト)、remake first(リメイク優先)、または do not spend(出稿停止)
  • 確率帯域と信頼度
  • 最も強い秒と最も弱い秒
  • 想定されるオーディエンスとトラフィックジョブ
  • 正確な編集リスト
  • 3〜5の派生コンセプト
  • コンプライアンスと返金リスク
  • 最小検証設計

ウェブサイト実行プロトコル

千川ブラウザアクションの前:

  1. references/web-navigation.mdを読み込みます。
  2. 利用可能な場合は、現在開かれているログイン済みのタブを再利用します。
  3. アカウント名と千川/広告主IDを確認します。
  4. 記憶された画面座標のみに依存せず、可視のセマンティクスと安定した属性でナビゲートします。
  5. 予想されるルートが異なる場合:
    • 書き込みアクションを停止します
    • 現在のDOM/スクリーンショットを検査します
    • 新しいルートを確認した後、ページマップを更新します
  6. プラン作成、追跡、ROI/予算/ステータス変更については、ナビゲーションリファレンスの正確なチェックポイントリストに従います。
  7. 確認されたルートの後、scripts/record_navigation.pyを実行し、アカウントに依存しないルート、コントロール、成功シグナルを永続化します。

既知のルートを再発見するためにトークンを費やしてはいけません。最初にページマップを検索します。UIバージョンが変更された場合、または要求されたサーフェスがマッピングされていない場合にのみ探索します。

決定品質

すべての推奨事項には以下を含める必要があります:

  • データウィンドウとソース
  • 商用目的
  • 診断されたボトルネック
  • 賛成および反対の証拠
  • 信頼度:低 / 中 / 高
  • 推奨アクションと、正当化される場合の数値設定
  • 期待される観察ウィンドウ
  • 成功条件、停止条件、ロールバック条件
  • ユーザー確認が必要かどうか

実行境界

読み取り専用アクションは、アクセスが存在する場合に続行できます:

  • ダッシュボード、プラン、素材、商品、ライブステータス、クーポン、在庫、レポートを検査する
  • レポートをダウンロード/エクスポートする
  • 動画、スクリーンショット、ライブフレームを分析する
  • 下書きと正確な設定を準備する

書き込みアクションは、事前に明確に承認されていない限り、確認が必要です:

  • プランまたは追跡タスクを作成/有効化/一時停止する
  • ROI目標、入札額、予算、オーディエンス、商品、スケジュール、またはクリエイティブの紐付けを変更する
  • 素材をアップロードまたは公開する
  • お金を使ったり配信を変更したりする可能性のあるアクションを送信する

トークン、クッキー、秘密情報、アカウント認証情報を決して公開してはいけません。API秘密情報は環境変数に保存します。

必須の自己改善

完了したライブセッション、素材テスト、意味のあるアカウント変更、またはUI発見の後:

  1. 期待結果と実際の結果を比較します。
  2. scripts/record_learning.pyを使用してケースを記録します。
  3. ルールを keep(維持)、narrow(絞り込み)、reject(却下)、または pending(保留)に分類します。
  4. 確認されたUI変更の後、ナビゲーションメモリを更新します。
  5. 繰り返しの証拠がサポートするまで、ヒューリスティックをデフォルトルールに昇格させてはいけません。
  6. 古いルート、キャリブレーションされていないスコア、失敗した予測、現在のアカウントデータでサポートされていないルールについて、毎月監査を実行します。

関連スキル