ワークフロー設定
はじめに
ワークフロー設定では、ワークフローの配信方法を設定し、実行を制限できます。これらの設定は以下に役立ちます：
- ワークフローの対象国を特定する
- 実行速度を制御する
- ターゲットデバイス（デスクトップ、モバイル、タブレット）を選択する
- 配信実行優先順位を調整する（優先順位乗数）
- スパムを防ぎ、トークン予算を保護する
{info} アクセス: ワークフロー詳細ページの「設定」ボタンをクリックするか、新しいワークフローを作成するときにワークフロー設定を開きます。
ターゲティングと配信
国モード
国別にワークフローを配信する方法を選択します：
| モード | 説明 | いつ使うべき？ |
|---|---|---|
| すべての国 | どの国からでもワークフローを実行可能 | 多様なグローバルトラフィックが欲しい場合 |
| 含めるのみ | リスト内の国のみを許可 | 特定の国（VN、US、UKなど）からのトラフィックのみが欲しい場合 |
| 除外するのみ | リスト内の国をブロック | 特定の国以外のグローバルトラフィックが欲しい場合 |
例:
ケース1: ベトナムのウェブサイト
→ モード: 含めるのみ
→ 選択: VN
→ 結果: ベトナムのIPのみがワークフローを実行
ケース2: 国際的なウェブサイト、中国のトラフィックを避ける
→ モード: 除外するのみ
→ 選択: CN
→ 結果: 中国以外のすべての国{warning} プラン要件: この機能にはBasicプラン以上が必要です。無料プランは「すべての国」に制限されています。
国の選択
「含める」または「除外する」モードが選択されている場合、国のリストを選択する必要があります：
選択方法:
- 検索: 国名またはコード（VN、US、UK...）を入力
- チェック: 国名の横にあるチェックボックスをクリック
- グループ選択: クイックグループボタン（SE Asia、Europe、English Speaking...）を使用
- 選択済みを表示: 「選択済みのみ」を切り替えて、選択された国のみを表示
- すべてクリア: 「すべてクリア」をクリックして選択を解除
国グループ
利用可能なクイック選択グループ：
| グループ | 国 | 数 |
|---|---|---|
| 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によって実行されます追加設定
デバイス
説明: ワークフローを実行できるデバイスの種類を選択します。
オプション:
- 🖥️ Desktop - コンピュータ (Windows, Mac, Linux)
- 📱 Mobile - 携帯電話 (iOS, Android)
- 📱 Tablet - タブレット (iPad, Android Tablet)
仕組み:
アプリインスタンスがワークフローを実行するとき、システムは以下を行います：
- 選択されたリストからランダムに1つのデバイスを選択します。
- そのデバイスをシミュレートします（ユーザーエージェント、画面サイズ、タッチイベント...）。
- 選択されたデバイスでワークフローを実行します。
例:
選択: Desktop + Mobile
実行1 → システムはDesktopを選択
実行2 → システムはMobileを選択
実行3 → システムはDesktopを選択
...
→ デスクトップとモバイル間の多様なトラフィック推奨事項:
| ウェブサイトタイプ | 推奨デバイス | 理由 |
|---|---|---|
| ブログ、ニュース | Desktop + Mobile | 50/50の混合トラフィック |
| Eコマース | Mobile (70%) + Desktop (30%) | モバイルでのショッピング傾向 |
| SaaS、ダッシュボード | Desktop | ユーザーは主にデスクトップを使用 |
| モバイルゲーム | Mobile | 100%モバイルトラフィック |
{warning} プラン要件: この機能にはBasicプラン以上が必要です。無料プランはデフォルトで3つのデバイスすべてで実行されます。
{info} 注: 少なくとも 1つのデバイスを選択する必要があります。何も選択されていない場合、システムはデフォルトでデスクトップ + モバイルに設定されます。
優先順位乗数
説明: 優先順位乗数は、実行キュー内でのワークフローの配信優先順位の位置を決定する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から20の間で調整
- 「保存」をクリック
コスト最適化の推奨事項
{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分間キャッシュされます。
プラン制限
一部の設定機能には上位プランが必要です：
| 機能 | Free | Basic | Pro | Enterprise |
|---|---|---|---|---|
| 国モード | すべて | すべて/含む/除外 | すべて/含む/除外 | すべて/含む/除外 |
| デバイス選択 | すべて | カスタム | カスタム | カスタム |
| 優先順位乗数 | 1 - 20 | 1 - 20 | 1 - 20 | 1 - 20 |
| 実行制限 | ✅ | ✅ | ✅ | ✅ |
プランに含まれていない機能を使用する場合:
- システムはデフォルト値を適用します。
- プランをアップグレードするための通知が表示されます。
よくある質問
❓ 新しいウェブサイトにはどのような制限を設定すべきですか？
安全な推奨事項:
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にリセットします（管理者に連絡）。
❓ 制限に達していないのにワークフローが実行されないのはなぜですか？
以下の条件を確認してください:
- ワークフローのステータス: "アクティブ"でなければなりません。
- トークン: アカウントに十分なトークンが必要です。
- 時間/日次制限: 制限に達している可能性があります。
- アプリインスタンス: アプリインスタンスはオンラインですか？
- 国: オンラインのアプリインスタンスはcountry_modeと一致していますか？
❓ トークン（ポイント）が十分にあるのに、なぜワークフローのビュー獲得が遅いのですか？
アカウントに十分なトークンがあるにもかかわらずビューの増え方が遅い場合、通常は以下の2つの設定原因が考えられます：
- ユニーク間隔（Unique Interval）が長すぎる:
- 原因:
unique_interval = 1800（30分）に設定している場合、オンラインの各ワーカーIPは、一度実行した後にこの特定のワークフローを再実行できるようになるまで正確に30分間待機する必要があります。 - 解決策: ユニーク間隔を短い時間（例:
600s- 10分 または300s- 5分）に短縮し、オンラインワーカーIPがより頻繁にワークフローを訪問・実行できるようにします。
- 原因:
- 優先順位乗数（Priority Multiplier）が低すぎる:
- 原因: ワークフローの乗数がデフォルトの
x1のままになっており、同じカテゴリ（例: Google Search）の競合ワークフローがより高い乗数（x2やx3）を設定しているため、システムが競合のビューを優先して配信しています。 - 解決策: ワークフロー設定を開き、
📊 優先倍率分布をクリックして「x:multiplier を適用」をクリックします（通常、x1からx2またはx3に引き上げるだけで、ポイントを無駄に消費することなく最初の1分で 100%の選択確率 を達成できます）。
- 原因: ワークフローの乗数がデフォルトの
まとめ:
- ワークフロー設定は、実行の分散と速度を制御するのに役立ちます。
- 合理的な制限により、トラフィックがより自然になり、トークンを節約できます。
- ワークフローを停止せずに、いつでも設定を変更できます。
- 一部の機能にはBasicプラン以上が必要です。