ワークフロー設定

はじめに

ワークフロー設定では、ワークフローの配信方法を設定し、実行を制限できます。これらの設定は以下に役立ちます：

  • ワークフローの対象国を特定する
  • 実行速度を制御する
  • デバイスの分散比率（%）を設定する（デスクトップ、モバイル、タブレット）
  • 配信実行優先順位を調整する（優先順位乗数）
  • スパムを防ぎ、トークン予算を保護する

Workflow settings

{info} アクセス: ワークフロー詳細ページの「設定」ボタンをクリックするか、新しいワークフローを作成するときにワークフロー設定を開きます。

ターゲティングと配信

国モード

国別にワークフローを配信する方法を選択します：

モード 説明 いつ使うべき？
すべての国 どの国からでもワークフローを実行可能 多様なグローバルトラフィックが欲しい場合
含めるのみ リスト内の国のみを許可 特定の国（VN、US、UKなど）からのトラフィックのみが欲しい場合
除外するのみ リスト内の国をブロック 特定の国以外のグローバルトラフィックが欲しい場合

例:

ケース1: ベトナムのウェブサイト
→ モード: 含めるのみ
→ 選択: VN
→ 結果: ベトナムのIPのみがワークフローを実行

ケース2: 国際的なウェブサイト、中国のトラフィックを避ける
→ モード: 除外するのみ
→ 選択: CN
→ 結果: 中国以外のすべての国

{warning} プラン要件: この機能にはBasicプラン以上が必要です。無料プランは「すべての国」に制限されています。

国の選択

「含める」または「除外する」モードが選択されている場合、国のリストを選択する必要があります：

選択方法:

  1. 検索: 国名またはコード（VN、US、UK...）を入力
  2. チェック: 国名の横にあるチェックボックスをクリック
  3. グループ選択: クイックグループボタン（SE Asia、Europe、English Speaking...）を使用
  4. 選択済みを表示: 「選択済みのみ」を切り替えて、選択された国のみを表示
  5. すべてクリア: 「すべてクリア」をクリックして選択を解除

国グループ

利用可能なクイック選択グループ：

グループ 国 数
SE Asia VN, TH, MY, SG, ID, PH, MM, KH, LA, BN, TL 11
English Spk US, GB, CA, AU, NZ, IE, ZA, IN, PK, NG 10
Europe GB, DE, FR, IT, ES, NL, BE, AT, CH, SE, NO, DK, FI, PL, PT, GR, CZ, HU, RO 19
North America US, CA, MX 3
East Asia CN, JP, KR, TW, HK, MO 6

ヒント: グループをクリックすると、そのグループ内のすべての国を一度に選択できます！

実行制限

これらの制限は、ワークフロー実行の速度と量を制御するのに役立ちます。

1時間あたりのビュー数

説明: ワークフローが1時間に実行できる最大ビュー数。

値:

  • 0 = 無制限
  • > 0 = 特定の制限（例：100ビュー/時間）

仕組み:

設定: views_per_hour = 50

ワークフローが午前10:00に実行開始
→ 10:00 - 11:00: 最大50実行
→ 11:00 - 12:00: リセット、再び最大50実行
→ 12:00 - 13:00: リセット、再び最大50実行

いつ使うべき？:

  • 安定したトラフィックが欲しい、急増を避ける
  • Googleが異常なトラフィックを検出するのを防ぐ
  • トラフィックの成長率を制御する

例:

ケース1: 新しいウェブサイト、自然なトラフィック
→ views_per_hour = 20
→ 理由: 急激な増加を避け、自然な成長をシミュレートする

ケース2: 大規模ウェブサイト、高速トラフィックが必要
→ views_per_hour = 200
→ 理由: 疑いを持たれずに高いトラフィックを処理できる

1日あたりのビュー数

説明: ワークフローが1日（24時間）に実行できる最大ビュー数。

値:

  • 0 = 無制限
  • > 0 = 特定の制限（例：1000ビュー/日）

仕組み:

設定: views_per_day = 500

1日目 (00:00 - 23:59): 最大500実行
2日目 (00:00 - 23:59): リセット、再び最大500実行

いつ使うべき？:

  • 毎日のトークン予算を管理する
  • 実際のユーザーを模倣するためにトラフィックを制限する
  • ビューのスパムを防ぐ

例:

ケース: 1日50,000トークンの予算
ワークフローコスト: ~100トークン/実行
→ views_per_day = 500 (500 x 100 = 50,000トークン)

最大ビュー数

説明: ワークフローのライフサイクル全体の合計ビュー数。

値:

  • 0 = 無制限（永久に実行）
  • > 0 = 特定の制限（例：合計10,000ビュー）

仕組み:

設定: max_views = 10000

ワークフローは累積的に実行されます:
→ 1日目: 500ビュー (合計: 500)
→ 2日目: 800ビュー (合計: 1,300)
→ ...
→ 20日目: 400ビュー (合計: 10,000) → 永久に停止

いつ使うべき？:

  • 期限のあるキャンペーン
  • 総予算の管理
  • 必要以上にワークフローが実行されるのを避ける

例:

ケース: 新しい投稿のトラフィックをブースト
目標: 1ヶ月で5,000ビュー
→ max_views = 5000
→ 結果: 5,000ビューに達した後、ワークフローは自動的に停止します

{danger} 警告: max_viewsに達すると、ワークフローは永久に停止します。実行を継続するには、値を増やすか0に戻す必要があります。

ユニーク間隔

説明: 同じIPアドレスからの2回の実行間の最小時間（秒単位）。

注意: 各IPは複数の異なるワークフローを同時に実行できます（最大30スレッド）が、特定のワークフローはそのIPに対してunique_intervalごとに1回しか実行できません。

デフォルト値: 1800秒（30分）

仕組み:

設定: unique_interval = 1800 (30分)

IPアドレス 192.168.1.1:
→ 10:00 AM: スレッド1がワークフロー#100を実行 → OK
→ 10:05 AM: スレッド2がワークフロー#100を実行しようとする → ブロック (同じIP、まだ30分経過していない)
→ 10:05 AM: スレッド2がワークフロー#101を実行 → OK (異なるワークフロー)
→ 10:30 AM: スレッド1がワークフロー#100を2回目に実行 → OK (30分経過)

説明:

  • 同じIPは30分以内に同じワークフローを2回実行できません。
  • しかし、多くの異なるワークフローを同時に実行できます。

目的:

  • IPアドレスによる追跡: Google Analyticsが訪問者を追跡する方法と一致させます。
  • スパム防止: 同じIPが短期間に同じURLをスパムすることを防ぎます。
  • マルチスレッドのサポート: 各IPは30スレッドを実行でき、各スレッドは異なるワークフローを実行します。
  • 現実的なトラフィック: 30分で1つのIPは約180の異なるワークフローを実行できます（30スレッド × 6ワークフロー/スレッド）。
  • ローテーションプロキシ: 新しいIP = 新しい訪問者、制限なし。

推奨事項:

ワークフロータイプ unique_interval 理由
ホームページ、LP 3600s (1時間) 実際の人は1時間以内に戻ってくることは稀
ブログ記事 1800s (30分) 30分後に読み直す可能性がある
Eコマース商品 7200s (2時間) 購入者は通常より長く比較検討する

例:

実際のケース: 100個のIPアドレス、それぞれ30スレッド
システムには1000の異なるワークフローがある
unique_interval = 1800 (30分)

各IP:

- 30スレッドが同時に実行
- 各スレッド: 1ワークフロー/5分 = 12ワークフロー/時間
- IPあたりの合計: 30 × 12 = 360ワークフロー/時間
- 30分で: 30 × 6 = 180の異なるワークフロー

100 IP:
→ スループット: 100 × 360 = 36,000ワークフロー/時間
→ 多様なトラフィック: 100 IP × 180ワークフロー = 30分あたり18,000の組み合わせ
→ 各ワークフローは多くの異なるIPによって実行されます

追加設定

デバイスと分散比率設定

説明: ターゲットデバイスの種類を設定し、SEOキャンペーンの目的に合わせて各デバイスの実行割合（%）をカスタマイズします。

デバイス分散比率設定

1. サポートされているデバイスの種類

  • 🖥️ Desktop（デスクトップ）: 大画面とマウス操作を備えたデスクトップ/ノートPC（Windows、macOS、Linux）のブラウザ環境をシミュレートします。
  • 📱 Mobile（モバイル）: 縦型ビューポート、タッチ/スワイプ操作、モバイル用User-Agentを備えたスマートフォン（iOS、Android）をシミュレートします。
  • 📟 Tablet（タブレット）: 中型ビューポートとタッチイベントをサポートするタブレット端末（iPad、Android Tablet）をシミュレートします。

2. インタラクティブなドーナツUIと操作機能

  • インタラクティブなドーナツドラッグ操作 (Interactive Donut Dragging):
    • SVGドーナツチャート上のハンドル（Knob）を直接ドラッグして、デバイス間の比率を直感的かつリアルタイムに調整できます。
  • スマートスライダーとパーセント数値入力:
    • スライダーをドラッグするか、数値を直接入力できます。合計が常に100%になるよう、他のデバイスの値が自動的にバランス調整されます。
  • 柔軟なデバイスオン/オフ切り替え (Device Toggling):
    • 必要に応じて各デバイスを個別に有効化/無効化できます。デバイスをオフ（0%）にすると、その比率は残りの有効なデバイスに自動再配分されます。
    • 少なくとも1つのデバイスを有効にする必要があります（例: 100% Desktop または 100% Mobile）。
  • ワンクリック・クイックプリセット (Quick Presets):
    • ⚖️ 均等バランス: 34% Desktop - 33% Mobile - 33% Tablet
    • 💻 デスクトップ優先: 70% Desktop - 20% Mobile - 10% Tablet
    • 📱 モバイル優先: 15% Desktop - 70% Mobile - 15% Tablet
    • 🖥️ デスクトップのみ: 100% Desktop - 0% Mobile - 0% Tablet
    • 📲 モバイルのみ: 0% Desktop - 100% Mobile - 0% Tablet

3. 配信メカニズム（重み付けランダムサンプリング）

ワークフロー実行時、デスクトップ実行アプリ（Executor App）は重み付けランダムサンプリング（Weighted Random Sampling）アルゴリズムを使用して、設定された%比率に基づいてデバイスをランダムに選定します：

設定例: 70% Mobile - 20% Desktop - 10% Tablet

- 平均100回の実行: 約70回がMobile、約20回がDesktop、約10回がTablet
- 各実行ごとに、対応するデバイス仕様（User-Agent、解像度、デバイスピクセル比、タッチ操作）を完全にシミュレートします。

4. プラン要件とランタイムフォールバック機能

  • プラン要件: デバイス比率（%）のカスタマイズにはBasicプラン以上が必要です。無料プランはデフォルトの均等比率（34% Desktop - 33% Mobile - 33% Tablet）が適用されます。
  • ランタイムフォールバック（設定保持メカニズム）:
    • サブスクリプションが期限切れになり無料プランに移行した場合でも、カスタム設定はデータベース内に安全に保持されます。
    • タスク配信時に、システムは保存データを上書きすることなく、自動的にデフォルトの均等設定（34/33/33）を適用します。
    • サブスクリプションを再開またはアップグレードすると、保存されていたカスタム比率が即座に自動復元・適用されます。

5. Webサイトタイプ別の推奨比率

Webサイトタイプ / キャンペーン 推奨比率 戦略的根拠
ニュース・メディア・ブログ 60% Mobile - 30% Desktop - 10% Tablet モバイルでのニュース閲覧が多いユーザー行動に最適化。
Eコマース・通販サイト 70% Mobile - 20% Desktop - 10% Tablet スマートフォンでのオンラインショッピングのトレンドに適合。
SaaS・B2Bポータル 80% Desktop - 15% Mobile - 5% Tablet 業務利用やPCでのアクセスが中心となるサービス向け。
モバイルアプリ・ゲーム 100% Mobile - 0% Desktop - 0% Tablet アプリインストールLPやモバイル動線検証に特化。
一般的な汎用サイト 34% Desktop - 33% Mobile - 33% Tablet バランスの良いトラフィック構成で自然なSEO多様性を確保。

優先順位乗数

説明: 優先順位乗数は、実行キュー内でのワークフローの配信優先順位の位置を決定する1から20の数字です。

仕組み

基本原則:

  • 乗数が高いワークフローが優先的に配信・実行されます
  • 複数のワークフローが待機している場合、システムは最も高い乗数を持つワークフローを優先します
  • デフォルトの乗数: 1（基本優先順位）
  • 最大乗数: 20（最高優先順位）

実際の例:

現在のキュー:
┌──────────────────────────────────────┐
│ ワークフローA - 乗数: 20（最初に実行）│ ← 最初に選択される
├──────────────────────────────────────┤
│ ワークフローB - 乗数: 7              │
├──────────────────────────────────────┤
│ ワークフローC - 乗数: 5              │
├──────────────────────────────────────┤
│ ワークフローD - 乗数: 1（待機中）     │
└──────────────────────────────────────┘

いつ乗数を増やすべきですか？

✅ 以下の場合に増やしてください:

  • キャンペーンの結果が緊急に必要
  • 短期間でSEOを迅速に強化する必要がある
  • イベントのためにトラフィックを急増させたい
  • トライアルを実行中で、迅速な結果が必要

❌ 以下の場合には増やす必要はありません:

  • 長期的なワークフローで、緊急ではない → 1-3のままにする
  • 自然なトラフィック、期限なし
  • コストを節約したい

トークンコスト

⚠️ 重要: 優先順位乗数はコストに影響します！

優先順位乗数は、ワークフローの基本コストに直接乗算されて、支払うトークン数が計算されます：

実際のトークン = 基本トークン × 優先順位乗数

計算例:

ワークフローの基本コストが100トークンであるとします：

乗数 式 支払うトークン 備考
1 100 × 1 100 トークン 基本価格、優先順位なし
5 100 × 5 500 トークン より高い優先順位、5倍の価格
10 100 × 10 1,000 トークン より高い優先順位、10倍の価格
20 100 × 20 2,000 トークン 最高優先順位、20倍の価格

なぜ多く支払うのですか？

  • より高い乗数 → ワークフローが最初に実行される → 実行者がより多くのトークンを受け取る
  • これが市場の自己調整方法です：より高い優先順位を望むにはより多くのコストがかかります
  • 公平性を確保：より多く支払う人が最初にサービスを受けます

重要な注意点

{danger} コスト警告:

  • 優先順位乗数はコストを比例して増加させます
  • 乗数10 = 乗数1の10倍のトークンコスト
  • 本当に緊急に必要な場合にのみ高い乗数を使用してください
  • すべてのワークフローが高い乗数を使用する場合 → より多くのトークンを費やしますが、優先順位の利点はありません

設定方法

  1. ワークフロー詳細ページまたは新しいワークフローを作成する際に移動
  2. 「設定」ボタン（ワークフロー設定）をクリック
  3. 「優先順位とスケジュール」を見つける
  4. 「優先順位乗数」を1から20の間で調整
  5. 「保存」をクリック

コスト最適化の推奨事項

{danger} ポイント無駄遣い警告: ライバルの平均設定が x1 〜 x2 である場合、極端に高い乗数（x10 〜 x20 など）を設定しても配信優先度の追加効果はなく、トークン費用だけが10〜20倍に増大します。必ず「優先倍率分布」ボタンをクリックして最適な推奨値を確認してください！

乗数レベル コスト 効果の評価 実際の推奨設定
x1 x1 (最も節約) 100%コスト節約。 期限のない日次の自然なトラフィック維持に最適。
x2 - x3 x2 - x3 (推奨) 最も効率的なバランス。 通常、ライバルの上位95%〜98%を上回るのに十分です。 分析ツールの「x:multiplier を適用」ボタンを使用。
x4 - x5 x4 - x5 コストが4〜5倍に増加。 カテゴリ内のライバル密度が極めて高い場合にのみ使用。
x6 - x20 x6 - x20 (警告) 非常に無駄。 コストが6〜20倍。 テスト実行や緊急イベントを除き、設定を避けてください。

{success} ポイント節約のヒント:

  • 分布分析を開く: 調整前に必ず📊 優先倍率分布をクリックして競合密度を確認。
  • ワンクリック適用: 推奨される「x:multiplier を適用」ボタンを使用して、最小限のコストで100%の選択確率を達成。
  • x1へ戻す: 緊急キャンペーン終了後は、経済的な長期トラフィックのために x1 に戻す。

優先倍率分布とシステム容量

必要な速度を達成しながらポイントの無駄遣いを防ぐため、Traffic4SEOは優先倍率分布分析（Priority Distribution Analytics）ツールを提供しています。

優先倍率分布分析

1. 分析ツールの開き方
  • メインヘッダーから: メインヘッダーのオンライン状態の隣にある⚡ システム容量（デスクトップ）またはアイコン⚡（モバイル）をクリック。
  • ワークフロー設定から: ワークフロー設定パネル内の 優先順位乗数 ラベルの隣にある📊 優先倍率分布分析ボタンをクリック。
2. モーダル内の主要指標
指標 説明 意味
オンラインExecutor数 現在オンラインでアクティブな実行ワーカーIPのリアルタイム数。 システム全体の現在の処理容量を示します。
システム配信容量 システムが1分あたりに配信できる最大ビュー数（回/分）。 例: 20 Executor = 4 回/分（Google Search）または 120 回/分（その他のワークフロー）。
自動タグ判定カテゴリ Google Search ワークフロー と その他のワークフロー の2つのタブに分割。 ワークフローのタグを自動検出し、同じカテゴリ内の競合密度を正確に表示します。
推定待ち時間 各ビュー間の推定平均待機間隔（~ X/回）。 各乗数レベルでのビュー配信速度を予測するのに役立ちます。
選択確率（Pick Chance） ワークフローがシステムに選ばれて実行される確率レベル（非常に高い、中程度、低い）。 現在の乗数の競争力を評価するのに役立ちます。
最適推奨値 システムが提案する最適な優先度倍率（例: x2）。 ポイントを節約しながら100%の選択確率を達成できます。
3. スマート警告アラート

ツールはトークン消費を最適化するために自動的にアドバイスを生成します：

  • 🟢 最適推奨値: トップグループに入るために必要な最小倍率を表示。
  • 🟡 ポイント消費警告: 設定が必要以上に高い場合（例: x2で十分なのに x10 に設定している場合）に自動表示。ワンクリックで推奨値に下げてポイントを節約できます。
  • 🔵 優先度アップの機会: x1 から x2 または x3 に上げるだけで、最初の1分間に100%の選択確率が得られる場合に通知。
  • ⚠️ システム容量ボトルネック警告: アクティブなワークフロー総数がオンラインExecutorの処理速度を超えている場合に表示され、待機時間を短縮するために高めの倍率設定を提案。

{info} キャッシュ期間: 分布統計はシステムパフォーマンスを確保するため、Redisに15分間キャッシュされます。

ブラウザプロファイルとセッションの保持 (Profile Persistence)

説明: ブラウザプロファイルとセッションの保持（Profile Persistence）機能を使用すると、同一の実行マシン（Executor）上で連続してワークフローを実行する際に、ブラウザ状態（Cookie、LocalStorage、SessionStorage、キャッシュなど）を保持・再利用できます。

1. 仕組みと7日間の保持期間（7-Day Retention）

  • デフォルトは無効（false）: デフォルトでは、各ワークフロー実行は完全にクリーンで独立したブラウザ環境（クリーンコンテキスト）で開始されます。実行終了後、すべての一時データは即座に完全消去されます。
  • 有効化時（true）: 実行マシン（Executor）は単一の永続プロファイル（Persistence Profile）を使用して実行します。Cookieとストレージ（LocalStorage、SessionStorage）は保持され、初回実行から7日後に自動削除されます。

2. 目的と主なSEO効果

  • 🔄 リピーター（Returning Visitors）比率の向上: アクセス解析システムにおいて、リピート訪問者は高いエンゲージメントシグナルとドメイン信頼性評価をもたらします。
  • 🛡️ ブラウザの信頼性（Trust Browser）向上: 実際のブラウジング履歴とCookieを保持することで、高度なボット対策や防御機能を備えたサイトでもスムーズに通過しやすくなります。
  • 🎯 トラッキングとコンバージョン計測の最適化: 複数回の訪問にわたるマルチタッチアトリビューションやコンバージョンファネルを自然に再現します。

{warning} トラフィック計測と実行間隔に関する重要事項:

  • ユーザー数（Users）への影響: このモードを有効にすると、同じプロファイルからの訪問がリピーター（Returning Visitors）としてカウントされるため、新規ユーザー数は減少します。
  • セッションやページビューへの影響なし: セッションは通常30分ごとにリフレッシュされるため、セッション数やページビュー数には影響しません。
  • Unique Intervalの設定: 各実行が新しい有効なセッションとして計測されるよう、unique_intervalを1800秒（30分）以上に設定してください。

3. プラン要件とランタイムフォールバック機能

  • プラン要件: プロファイル保持機能にはBasicプラン以上が必要です。無料プランでは常にクリーンコンテキストで実行されます。
  • ランタイムフォールバック（設定保持メカニズム）:
    • 有料サブスクリプションが期限切れになり無料プランに移行した場合でも、設定されたプロファイル保持の有効状態はデータベース内に安全に保持されます。
    • タスク実行時、システムは保存データを上書きすることなく自動的にクリーンコンテキスト実行へとフォールバックします。
    • サブスクリプションを再開またはアップグレードすると、保存されていたプロファイル保持設定が即座に自動復元・適用されます。

プラン制限

一部の設定機能には上位プランが必要です：

機能 Free Basic Pro Enterprise
国モード すべて すべて/含む/除外 すべて/含む/除外 すべて/含む/除外
デバイス分散比率 (%) デフォルト (34/33/33) 比率%カスタマイズ 比率%カスタマイズ 比率%カスタマイズ
優先順位乗数 1 - 20 1 - 20 1 - 20 1 - 20
プロファイル保持 (Profile Persistence) ❌ (クリーンコンテキスト) ✅ (7日間保持) ✅ (7日間保持) ✅ (7日間保持)
実行制限 ✅ ✅ ✅ ✅

プランに含まれていない機能を使用する場合:

  • システムはデフォルト値を適用します。
  • プランをアップグレードするための通知が表示されます。

よくある質問

❓ 新しいウェブサイトにはどのような制限を設定すべきですか？

安全な推奨事項:

views_per_hour = 10-20
views_per_day = 100-200
unique_interval = 3600 (1時間)

理由: 新しいウェブサイトは、Googleからの疑いを避けるために徐々にトラフィックを増やすべきです。

❓ views_per_hourとviews_per_dayの違いは何ですか？

views_per_hour: 速度を制限します（1時間の急激なスパイクを回避）。 views_per_day: 総量を制限します（毎日の予算を管理）。

例:

views_per_hour = 50
views_per_day = 500

→ 1時間あたり最大50実行
→ 1日あたり最大500実行
→ 安定して実行する場合: 50実行/時間 x 10時間 = 500実行/日

❓ views_per_hour = 100だがviews_per_day = 500に設定した場合はどうなりますか？

システムは先に到達した制限を優先します：

1時間目: 100実行 (合計: 100)
2時間目: 100実行 (合計: 200)
3時間目: 100実行 (合計: 300)
4時間目: 100実行 (合計: 400)
5時間目: 100実行 (合計: 500) → 1日の制限に到達
6〜24時間目: 停止 (1日の制限に到達)

❓ ワークフロー実行中に設定を変更できますか？

はい！ いつでも設定を変更できます：

  • 変更は後続の実行に即座に適用されます。
  • すでに進行中の実行には影響しません。

❓ unique_intervalはいつリセットされますか？

unique_intervalは、各IPアドレスの最後の実行から計算されます：

IPアドレス 192.168.1.1:
→ ワークフロー#100を1回目実行: 10:00 AM
→ unique_interval = 1800s (30分)
→ ワークフロー#100を再度実行可能: 10:30 AM

注意: このIPは待機中に他のワークフロー（101, 102, ...）を実行できます。

views_per_hourやviews_per_dayのように日/時間でリセットされません。

❓ unique_intervalはインスタンスまたはIPごとに追跡されますか？マルチスレッドにどう影響しますか？

インスタンスIDではなく、IPアドレスごとに追跡されます。

マルチスレッド:

  • 1つのIPは最大30スレッドを同時に開くことができます。
  • 各スレッドは異なるワークフローを実行できます。
  • しかし、unique_interval内に同じワークフローを2回実行することはできません。

例:

IP 192.168.1.1 (30スレッド) (10:00 AM):
スレッド1: ワークフロー#100を実行 → OK
スレッド2: ワークフロー#101を実行 → OK
スレッド3: ワークフロー#102を実行 → OK
... (30スレッドが30の異なるワークフローを実行)

スレッド5: ワークフロー#100を実行しようとする（スレッド1によって既に実行済み）→ ブロック
→ 理由: 同じIP、ワークフロー#100はまだunique_intervalをクリアしていません。
スレッド5: ワークフロー#131を実行 → OK (まだ実行されていないワークフロー)

10:35 AM (35分後):
スレッド10: ワークフロー#100を再度実行 → OK (30分経過)

❓ views_per_hour = 0はどういう意味ですか？

0 = 無制限

views_per_hour = 0 → 1時間あたり無制限の実行
views_per_day = 0 → 1日あたり無制限の実行
max_views = 0 → 永久に実行

❓ より多くの国を選択するとトークンコストが高くなりますか？

いいえ。国の数はトークンコストに影響しません。

コストは以下にのみ依存します：

  • ワークフロー内のノード数
  • 待機時間
  • 優先順位乗数

❓ ワークフローがmax_viewsに達しました。どうすれば継続できますか？

方法1: max_viewsの値を増やします。 方法2: 0（無制限）に設定します。 方法3: total_viewsを0にリセットします（管理者に連絡）。

❓ 制限に達していないのにワークフローが実行されないのはなぜですか？

以下の条件を確認してください:

  1. ワークフローのステータス: "アクティブ"でなければなりません。
  2. トークン: アカウントに十分なトークンが必要です。
  3. 時間/日次制限: 制限に達している可能性があります。
  4. アプリインスタンス: アプリインスタンスはオンラインですか？
  5. 国: オンラインのアプリインスタンスはcountry_modeと一致していますか？

❓ トークン（ポイント）が十分にあるのに、なぜワークフローのビュー獲得が遅いのですか？

アカウントに十分なトークンがあるにもかかわらずビューの増え方が遅い場合、通常は以下の2つの設定原因が考えられます：

  1. ユニーク間隔（Unique Interval）が長すぎる:
    • 原因: unique_interval = 1800（30分）に設定している場合、オンラインの各ワーカーIPは、一度実行した後にこの特定のワークフローを再実行できるようになるまで正確に30分間待機する必要があります。
    • 解決策: ユニーク間隔を短い時間（例: 600s - 10分 または 300s - 5分）に短縮し、オンラインワーカーIPがより頻繁にワークフローを訪問・実行できるようにします。
  2. 優先順位乗数（Priority Multiplier）が低すぎる:
    • 原因: ワークフローの乗数がデフォルトの x1 のままになっており、同じカテゴリ（例: Google Search）の競合ワークフローがより高い乗数（x2 や x3）を設定しているため、システムが競合のビューを優先して配信しています。
    • 解決策: ワークフロー設定を開き、📊 優先倍率分布をクリックして「x:multiplier を適用」をクリックします（通常、x1 から x2 または x3 に引き上げるだけで、ポイントを無駄に消費することなく最初の1分で 100%の選択確率 を達成できます）。

まとめ:

  • ワークフロー設定は、実行の分散と速度を制御するのに役立ちます。
  • 合理的な制限により、トラフィックがより自然になり、トークンを節約できます。
  • ワークフローを停止せずに、いつでも設定を変更できます。
  • 一部の機能にはBasicプラン以上が必要です。

次のステップ