working-with-scouts

Signals スカウトの操作

スカウトは、一定の間隔で自動的に起動し、1 つの PostHog プロジェクトを確認して、Signals の受信トレイにレポートとして調査結果を書き込むか、何もなかったとして処理を終了するスケジュール実行エージェントです。 スカウトのチームは、あなたに代わって状況を監視するために雇った新人アナリストのチームだと考えてください。スカウトは人の手を介さずに作業し、証拠の基準を高く保ち、そして何より重要なことに、一緒に作業するほど精度が上がります。 あなたが書く却下理由、残すメモ、対応するレポートのすべてが、スカウトの次の動作に反映されます。

このスキルは、こうした協力関係の運用マニュアルです。監視業務を委任する方法、返ってきた内容に対応する方法、そしてチームが本当に重視することにスカウトのチームを近づける方法を説明します。 以下のワークフローで別のスキルに引き継ぐ場合は、関連する 3 つのスキルを参照してください。

スキル	対象
authoring-scouts	スカウトの作成、編集、調整：スキル本文、設定、メモの書き込み、テストループ
exploring-scouts	読み取り専用の可観測性：スカウトの一覧、実行履歴、スクラッチパッドのメモ、健全性の評価
inbox-exploration	受信トレイそのもの：レポートのトリアージ、詳細調査、対応、解決／却下／スヌーズ

まず、フリートは稼働していますか？

存在しないフリートに作業を委任してはいけません。 2つの読み取りで確認できます。posthog:scout-metadata-get では、プロジェクトがスカウトを実行するよう登録済みかどうかがわかり、posthog:scout-config-list はスカウトごとにスケジュール、enabled、emit の設定、description を示す一覧です。 一覧の内容にかかわらず、まず登録状況を確認してください。設定行は登録解除後も残るため、スカウトが有効なままでも、登録解除されたプロジェクトでは実行されないことがあります（すべてのスカウトで last_run_at が古いままなのが兆候です）。 （スカウトツールは最近 signals-scout-* から scout-* に名前が変更されました。scout-* の名前が不明と返された場合は、従来の signals-scout-* の名前を試してください。） ここでのアクセスルールはすべて共通です。スカウトの行はプロジェクトの正規の親プロジェクトに保存されるため、スカウトの読み取りと書き込みはすべて（この一覧の読み取りや、以下のメモおよび設定の調整も含め）、子環境だけを対象とする認証情報では 403 を返します。親プロジェクトから作業するか、親プロジェクトへのアクセス権を持つ認証情報を使用してください。

• 未登録 — アクティビティを作り上げるのではなく、Signals のスカウト設定、または PostHog Desktop のオンボーディングをユーザーに案内してください。
• 登録済みで一覧が空 — 登録したばかりで、最初のコーディネーターの実行を待っている可能性があります（設定はその時点で自動登録されます）。オンボーディングを再度案内するのではなく、その旨を伝えてください。
• 登録済みで行がある — 各スカウトの enabled、emit（false はドライランで、実行されますが何も書き込みません）、および status / pause_reason を確認してください。 一時停止中、またはドライランのスカウトであることが、「スカウトが何もしていない」という苦情の大半を、さらに調査する前に説明できます。 また、posthog:scout-project-profile-get の summary.emit_eligibility も確認してください（ゲートだけが必要な場合は summary_only=true を指定します）。can_emit が false の場合、スカウトの書き込みは受信トレイに届きません。対応を約束する前に remediation を提示してください。blocking_reason から、ゲートの種類を特定できます。ai_processing_not_approved または source_disabled はチーム内のすべてのスカウトに適用されます。scout_emit_disabled は、特定のスカウトがドライラン設定になっていることを示します。そのスカウトは、調査を続けますが、調査結果やレポートは出力しません。実行中でない場合、このツールはチーム全体の状態を返します。特定のスカウトの書き込み可否を確認するには、run_id を指定してください。 （読み取り側では、このプロファイルはスカウトの実行によって構築されるキャッシュ済みスナップショットです。そのため、404 は新しいプロファイルが存在しないことを意味し、適格性がないことを意味するわけではありません。posthog:inbox-source-configs-list で signals_scout のソース設定を確認し、プロファイルを根拠にブロックするのではなく、適格性は不明として扱ってください。）

各行の description には、そのスカウトが監視する対象が記載されています。スキル本文を読み込まずに「X を担当するスカウトはどれですか？」に答えるには、これを確認してください。 （description が空の行は、スキルが削除された孤立した項目であることが多く、実行できません。そのため、対応範囲に含めないでください。） PostHog には、多くのプロダクト領域（エラー追跡、ログ、ウェブ分析、AI の可観測性、実験、フィーチャーフラグ、セッションリプレイ、アンケート、収益など）を担当する専門スカウトに加え、プロダクト横断型のジェネラリストも用意されています。また、チームはそれ以外のカスタムスカウトも追加できます（スキル名は任意です。設定が自動登録されるのは signals-scout- のプレフィックスが付いた場合のみで、それ以外の名前のスカウトは posthog:scout-create から追加します）。 各行には scout_origin（canonical または custom）もあり、PostHog が用意したスカウトか、チームが作成したスカウトかがわかります。ただし、正規スカウトがその場で編集され、上流のものと異なる状態になっているかどうかは判別できません。その場合でも、その行は canonical と表示されます。差異が重要な場合は、その行の本文を PostHog リポジトリ内の正規ソース（products/signals/skills/<skill>/SKILL.md）と比較してください。posthog:skill-get が返すのはチームの最新の行で、編集済みのコピーです。

作業ループ

このスキルのすべては、継続的に実行する1つのループです。

1. 委任 — フリートに何を監視させるかを決め、適切なスカウトに監視させます。
2. 受信 — レポートが受信トレイに届き、スカウトがレビュー担当者を特定できた場合は、提案された担当者に振り分けられます。
3. 対応 — 指摘内容を確認して修正する（または修正しないと判断する）とともに、レポートに結果を記録します。
4. フィードバック — 結果とその理由を記した文章は、残したメモとともにスカウトに戻されます。
5. 調整 — フリートの健全性を定期的に確認し、繰り返し行われる指示を恒久的なポリシーに昇格させます。

最も重要な習慣は、レポートを放置しないことです。 レポートに対応することは、理由を添えて却下する場合でも、フリートの学習につながります。スカウトの受信トレイに届いたレポートに誰も対応しない状態が続くと、そのスカウトには自動的に警告が表示され、停止されます（Slack 経由で配信されるスカウトは、そこでの消費状況を測定できないため対象外です）。 受信トレイを放置すると、単に機能が低下するだけではありません。フリート全体が停止します。

ジョブの委任

何かを監視させたい場合は、監視を実現できる最も手軽な方法を選びましょう。ほとんどのジョブで、新しいスカウトは必要ありません。

状況	対応
標準スカウトがすでに対象範囲をカバーしている場合	新たに作成する必要はありません。有効になっていることを確認し、特定の対象に注意を向けたい場合はメモを残してください。
対象範囲はカバーされているものの、一時的または特定の観点に集中したい場合	expires_at を指定してメモを残してください。「今週はEUのサインアップファネルを監視する」「火曜日に新しいチェックアウトをリリースしたので、それ以降の変化は想定内です」などです。
カバー対象のスカウトが、構造的な事象を見逃し続ける（または過剰に報告する）場合	authoring-scouts を使って、除外条件、しきい値、スコープを編集し、調整してください。機能を追加するだけの場合は、別の名前の新しいスカウトを作成することをおすすめします。標準スカウトの行を編集すると内容に差異があるとマークされ、上流からの改善が反映されなくなるためです。
対象をカバーするスカウトがない場合（カスタムイベント、ニッチなファネル、外部システムなど）	authoring-scouts（posthog:scout-create）を使ってカスタムスカウトを作成してください。受信トレイの「スカウト」タブにある「このプロジェクトにおすすめ」の欄には、プロジェクト独自のデータに基づいたスカウトが提案され、「スカウトを提案」を選ぶと、チャットでスカウトの下書きを作成できます。カスタムの提案は同じ作成処理で追加されます。標準スカウトの提案は、無効になっている既存のPostHogスカウトです。これを承認すると、新しいスカウトを作成するのではなく、その設定が有効になります。
レポートではなく、繰り返し取得する指標が欲しい場合（クエリでは算出できない、主観的な品質・分類スコアなど）	構造化出力チャネルで測定スカウトを作成してください。測定スカウトは実行ごとにサンプルを評価し、インサイトでグラフ化できる（ワークフローからも利用できる）、スキーマで検証済みの$scout_structured_outputイベントを記録します。実質的な変化があった場合にのみレポートを作成します。authoring-scouts の繰り返し測定／LLMジャッジのパターンと、すでに測定値を記録するスカウトの実例については signals-scout-mcp-tool-calls を参照してください（グラフの作成方法は references/metrics-dashboard.md を参照）。
今すぐ、一度だけ回答が欲しい場合	スカウトは使わず、データを直接クエリしてください。スカウトは継続的な監視に使うものであり、一度きりの質問には使いません。
references/delegation-recipes.md には、新たにリリースされたイベントの監視、期間を区切ったファネルの監視、日次ダイジェスト、外部ステータスページ、ノイズの多いフリートの静音化など、よくある依頼に使えるレシピがあります。

委任で効果を発揮する 2 つの習慣：

• まず、実データに基づいてタスクを設定します。 スカウトにイベントや対象を調査させる前に、それが存在すること（posthog:scout-project-profile-get、posthog:read-data-schema）と、実際に一定の量があること（直近の期間を対象にした posthog:execute-sql による簡単な件数確認）を確かめます。プロファイルツールとスキーマツールは、新しいイベントやまれなイベントの件数を返しません。プロジェクトで収集されていないデータの監視は、始める前から失敗しています。
• 人に割り込む価値がある事柄としてタスクを明確に伝えます。 スカウトは報告基準（「この発見について、最初から最後まで責任を持って対応したいと思うか」）を設けています。「何か興味深いことがあれば教えて」という指示はノイズを生みますが、「流入数が安定しているのにチェックアウトのコンバージョン率が下がったら教えて」という指示は有益な情報を生みます。

返ってきた内容への対応

レポートのトリアージ方法については inbox-exploration を参照してください。ここで重要なのは、対応することが、指示の調整にもなるという点です。

• 実装する前に検証してください。 スカウトのレポートは LLM による診断であり、確定した事実ではありません。修正する前に、引用されているエンティティと挙動を実際のデータやコードで確認してください。 レポートの内容が裏付けられない場合は却下の候補です。そして、適切に却下することも価値のある作業です（以下を参照）。
• すべてのレポートを、実態に即したステータスで締めくくってください。 作業が完了した場合は resolved（PR に基づく修正はマージ時に自動的に解決されます。PR の作成時点では解決しないでください）、事実ではない、または修正する価値がないとして却下した場合は suppressed（dismissed）、事実ではあるものの先送りした場合は potential（snoozed）です。
• 却下メモは、進む方向を示すメッセージです。 却下、スヌーズ、復元を行うと、dismissal_note はそのレポートを作成したスカウトに転送され、以降のすべての実行で過去のコンテキストとして参照されます。wrong_assignee または wrong_repo による却下では、メモがなくても理由自体がルーティングに関するフィードバックとして転送されます。 読み手を意識して書いてください。「ステージング環境のトラフィックでは、ホスト名が *.dev.example.com に一致するため、このパターンは無視してください」のように、判断を裏付ける証拠を示し、結論だけを書かないでください。 適切に書かれた却下メモは、スカウトに加えられる変更の中で最も手軽なものです。理由のない却下からは何も学べず、同じレポートが再び上がってきます。 ただし、2 点注意が必要です。転送はベストエフォートであり、正規のプロジェクトで却下者がスカウト制御（skill-editor）アクセス権を持っている必要があります。また、子環境のレポートで行われた却下は一切転送されません。どちらの場合もメモはレポートに残りますが、スカウトには届きません。確実に定着させたい指示は、届いたことを確認する（posthog:scout-notes-list を使います。派生メモは task:read も持つ認証情報でないと表示されません）か、権限を持つ人に直接メモを残してもらってください。 転送されたメモは約 30 日で期限切れになります。スカウトがスクラッチパッドのメモリに取り込んだ場合にのみ永続化されます。その期間を超えて残す必要がある指示は、スキルの編集として上位に反映してください。
• さらに 3 つの受信トレイ操作も、同じように進む方向を示します。 レポートの「Discuss」ボックスに入力した質問、レポートに評価とともに残したメモ、提案されたレビュアーの追加または削除も、それぞれスカウトメモになります（posthog:scout-notes-list で確認でき、origin はそれぞれ report_discussion、report_feedback、report_reviewer_correction です）。 レビュアーの修正は、フリートにとって最も強いルーティングの根拠です。レポートを作成または編集したスカウトと、削除されたログイン名を reviewer: メモに記載しているスカウトに届きます（修正 1 件あたり最大 20 件までのため、レポートが非常に多忙な場合は一部に届かないことがあります）。誤ったルートのレポートをその場で修正することで、どの担当者がその領域を受け持つのかをフリートに伝えられます。 転送されるメモには GitHub ログイン名が含まれ、修正者が正規のプロジェクトで skill-editor アクセス権を持つ場合にのみ書き込まれます。そのため、このアクセス権を持たずに行った修正や、リンクされた GitHub アカウントのない user_uuid のレビュアーだけを追加または削除した場合、メモはレポートに残りますが転送されません。 ディスカッションと評価の経路では、完全なメモ書き込み権限（skill-editor アクセス権に加え、signal_scout:write／llm_skill:write のキー範囲）が必要です。この権限を持たない人が入力したメモは転送されません。ディスカッションの質問は引き続きレポートのスレッドに残りますが、評価メモは分析イベントにしか残りません。スカウトに確実に届ける必要がある場合は、権限を持つ人にスカウトメモとして残してもらってください。
• レポートを解決しても終わりではありません。修正が維持されたかどうかをチェックで測定します。 チェックとは、スカウト（またはレポートパイプライン）がレポートに添付するフォローアップ測定です。期待される結果 1 つと、それをテストする時期で構成されます。レポートを解決すると計測が始まり、様子見期間（デフォルトでは 24 時間。モバイルのリリースやキャッシュされたクライアントバンドルのように、修正がユーザーに届くまで時間がかかる場合は、それより長くなります）が過ぎると再測定され、その結果がレポートに記録されます。これにより、「実際にうまくいったのか？」が、誰かが覚えておいて再確認する必要のある事柄ではなく、保存された事実になります。 これによって、作業の進め方が 3 つ変わります。
  • 解決済みレポートのチェックを確認してから、完了と判断してください。 posthog:inbox-report-checks-list には、各チェックの status と last_outcome が表示されます。チェックがまだ進行中なら結果を待っている状態なので、手動で再測定する必要はありません。各行を確認するのは exploring-scouts の役割です。
  • チェックの失敗は、修正が維持されなかったことを意味します。 再発した問題は、解決済みレポートを再オープンするのではなく、そのレポートにリンクされた新しいレポートとして登録されます。解決済みレポートは受信トレイから外れているため、そこに登録しても誰にも読まれません。新しいレポートを対応中の項目として扱ってください。
  • 実態に即して、マージ時に解決してください。 早まって解決した日時を基準にしたチェックでは、修正がリリースされる前の期間を測定し、実際には機能している修正を失敗と判定する可能性があります。 チェックを書き込めるのはスカウトの実行とパイプラインだけであり、人が作成するための画面はありません。解決済みレポートに再測定が必要なのにチェックがない場合、スカウトに対応を促してください。チェックを添付するようメモを残すか、authoring-scouts を通じてスキルを編集します。
• レポートは担当者に割り当てられます。 妥当な担当者を特定できるスカウトは suggested_reviewers を設定し、受信トレイではその担当者の画面の上部にレポートが表示されます。 レビュアーは PostHog ユーザーです。スカウトは user_uuid（GitHub アカウント不要の、任意の組織メンバー）または github_login（メンバーに紐付けられた GitHub ID と照合）でルーティングします。いずれかが閲覧者に一致すると、その閲覧者に対して is_suggested_reviewer が有効になります。 ある領域のレポートが未割り当てや誤った割り当てのまま届き続ける場合は修正できます。レポート自体のレビュアーを変更する（変更は前述のとおり転送されます）、フリート全体に適用するルーティングメモを残す（skill_name を指定せずに posthog:scout-notes-create を使い、「課金に関連するレポートは Dana に割り当てる」と記載します）、またはメモやスキルの編集を通じて、該当領域の適切な担当者へルーティングするようスカウトに指示してください。pipeline:report-research のメモが影響するのは、クラスタリングされたシグナルからパイプラインが作成するレポートだけです。レポートを直接作成するスカウトは独自に suggested_reviewers を設定し、その対象を参照しません。

スカウトが変更した内容の監査

write_scopes（authoring-scouts 経由で付与）を持つスカウトは、プロジェクト内の実際のオブジェクトを変更します。各変更は、ほかの編集と同様にプロジェクトのアクティビティログに記録されます。 行にはスカウトの実行ユーザー（実行時にトークンを発行する際に使用されるユーザーの ID）が記載され、サーバーによって設定される scout:<skill_name> クライアントタグが付与されます。 このタグでスカウトは特定できますが、実行やスカウトが保持していたスコープは特定できません。 1 回の実行を監査するには、その実行時間と完了時の報告を照合する必要があります。

1 回の実行による変更を再構成するには：

1. 実行を確認します（posthog:scout-runs-retrieve）。started_at、completed_at、metadata.write_scopes（実行が実際に権限を保持していた場合にのみ存在）、完了時の summary を確認します。実行プロンプトでは、権限を付与されたスカウトに、変更したすべてのオブジェクトを列挙するよう求めています。
2. 履歴を利用できるか確認します。 アクティビティ履歴が利用可能な場合は、MCP が提示するリーダーのガイダンスに従います。リーダーを利用できない場合、またはアクセスが拒否された場合は、その制約を記録し、その実行についてはそのリーダーの使用を中止します。制限を回避するために、リーダーの再検出やエンドポイントの探索を再試行しないでください。オブジェクト単位の履歴など、ほかに提示されている認可済みのリーダーは引き続き使用できます。利用できるリーダーがない確認項目だけを省略します。
3. 帰属を確認します。 実行時間には、実行ユーザーによるほかの書き込みが含まれる場合があります。それらの書き込みを区別できない履歴では、どの変更をスカウトが行ったかを特定できません。
4. 完了時の報告と照合します。 報告に記載されていない行や、裏付けとなる行がないのに報告に記載されている変更を確認します。

付与された各スコープによる書き込みが記録される scopes の値：

付与された書き込みスコープ	アクティビティの scopes の値
notebook:write	Notebook
dashboard:write	Dashboard
insight:write	Insight
annotation:write	Annotation
alert:write	AlertConfiguration
warehouse_view:write	DataWarehouseSavedQuery、DataQualityCheck
warehouse_table:write	DataQualityCheck
llm_skill:write	PersonalAPIKey
canvas:write	Canvas
experiment:write	Experiment、FeatureFlag

一部の権限は、その名前に含まれる対象以外のオブジェクトにも及びます。どちらのウェアハウス権限も、対象となるデータ品質チェックに及びます。experiment:write は、ローンチや一時停止によってリンクされた機能フラグをオンまたはオフにする場合、その機能フラグにも及びます。また、llm_skill:write はスキルストアのインストールコマンドにも及び、実行ユーザーのマーケットプレイス認証情報を発行またはローテーションします。 スコープ名に含まれるオブジェクト自体には、引き続き何も記録されません。スキル本文の編集（別のスカウトによるものも含む）とウェアハウステーブルへの書き込みは行を残さないため、代わりにスキルのバージョン履歴を確認してください。 キャンバスの公開もアクティビティ行を残しません。キャンバスのバージョン履歴を確認してください。スカウトが公開した各バージョンには、実行のタスクが記録されています。

解釈に影響する注意事項が 4 つあります：

• ウィンドウは帰属を示すものではありません。 スカウトタグがない場合、ウィンドウには実行ユーザーによる他の書き込みが含まれることがあります。タグがあっても、同じスカウトの実行が重複すると、そのタグを共有することがあります。実行終了時の報告と照らし合わせて、実行者、項目、タイムスタンプを比較してください。
• 履歴へのアクセスは任意です。 権限、Cloud Audit Logs の利用資格、プランの保持期間によっては、履歴を利用できない場合があります。履歴がないからといって、実行による変更がなかったとは断定できません。履歴に依存する結論は保留し、独立した確認を続けてください。アクセス制限が確認された場合は、ツールの不具合ではありません。
• ドライランでは権限が付与されません。 emit: false のスカウトは、ノートブックを含め、付与されたスコープを保持しないため、上の表にあるスコープの下で行を書き込みません。
• チームへのフォールバック実行では、デフォルトの権限のみが保持されます。 スカウトの作成者を解決できなくなると、実行は別のプロジェクトメンバーとして動作し、notebook:write（スカウトがまだこれを持っている場合）のみを保持します。そのため、Notebook の行だけが残ることがあり、それ以外は残りません。
• 拒否された書き込みは実行されていないため、ログに記録されません。 権限付与は上限であり、実行ユーザー自身の権限も引き続き適用されます。そのため、実行終了時の報告に拒否された書き込みが記載されていても、一致する行はありません。これは想定どおりの組み合わせであり、不一致ではありません。

調整の段階

スカウトの動作を変えたい場合は、最も手軽な方法から最も永続的な方法へと順に試し、目的を達成できる最も低い段階で止めてください。

1. 出力に反応する。 根拠を示した具体的なメモを添えて却下／スヌーズする、［Discuss］ボックスで質問する、メモを添えて評価する、またはレビュー担当者を修正する（いずれも自動的にスカウトへ転送されます）。 適している場面：誤ったレポートが1件あった場合、既知のノイズパターンが初めて表面化した場合、レポートの振り分け先が間違っていた場合。
2. 1回の実行を誘導する（posthog:scout-run-now に note を指定）。 適している場面：「チェックアウトのリグレッションを調べる」のように、今すぐ確認してほしい一度限りの焦点がある場合。後でスケジュール実行が読み取る情報は残しません。 メモはその実行のみを誘導し（最大1,000文字）、後続の実行にメモとして渡されることはありません。ただし、後の実行が履歴を読む際には、その実行のメタデータに表示され続けるため、「今日のみ：…」のように日付を限定した一度限りの指示として書いてください。通常の手動実行と同様に、1日の実行予算を1回分消費します。また、signal_scout:write に加えて llm_skill:write と、プロジェクトでのスキル編集権限が必要です（権限がなければ403エラーになります）。そのアクセス権限のない呼び出し元でも、メモなしでスカウトを実行できます。
3. メモを残す（スカウトごと、または全スカウト対象。必要に応じて expires_at で有効期限を設定できます）。 適している場面：有効期間のあるフィードバック、手がかり、コンテキスト。「何度も指摘している急増は既知のノイズです」「今週はEUのサインアップを詳しく調べてください」「新しいチェックアウトは火曜日にリリースされました」などです。 メモは助言として扱われます。注意を向けさせますが、証拠の基準を下げたり、レポートを強制したりすることはありません。 クラスタ化されたシグナルから構築されるレポートの調査、判定、振り分け方法をパイプラインに指示するには、skill_name: "pipeline:report-research" を指定します。スカウトが作成したレポートはこの段階を経由しないため、それらの振り分けルールは、全スカウト対象のメモ（skill_name の指定なし）か、スカウトごとのメモに記載してください。
4. 設定を調整する（posthog:scout-config-update）。 適している場面：実行するタイミングや実行するかどうか、アクセスできる範囲を変更したい場合です。調査対象を変える用途ではありません。頻繁に実行されるスカウトを遅くする（run_interval_minutes。設定に run_cron_schedule がある場合はそちらが優先されるため、併せて更新またはクリアしてください）、スカウトを一時停止する（enabled=false）、リスクのあるスカウトをドライランにする（emit=false）、外部へのアクセスを許可する（network_access=full）、コードスカウトに読み取り専用のチェックアウトを提供する（repositories=["organization/repository"]）、意図的に静かなウォッチドッグが自動一時停止されないようにする（auto_pause_exempt=true）、レポートを受信トレイに加えてSlackチャンネルまたはDMにも送信する（output_destinations.slack）、あるいは実行するモデルを固定する（model）場合などです。
5. スキル本文を編集するか、新しいスカウトを作成する（authoring-scouts を使用）。 適している場面：除外条件、しきい値、スコープの変更、新しい対象領域など、恒久的なポリシーを定めたい場合です。 カスタムスカウトの場合、これが最も強力な調整方法です。スキル本文は自由に編集でき、繰り返し寄せられるメモや却下理由を反映する場所です。 標準スカウトの場合、同じ編集を行うとフォークされます。チームのコピーには乖離のマークが付き、それ以降はPostHogの標準同期の対象外となるため、そのスカウトに対する上流の改善も受け取れなくなり、自分たちで保守する必要があります。 自分たちで管理したいスカウトであれば、そのトレードオフに見合う場合があります。ただし、追加の動作を実現したいだけなら、新しい名前のスカウトを作成し、標準スカウトは変更せずに保守される状態を保つことをおすすめします。

繰り返される調整は昇格させましょう。 何度も書き残すメモや、3回も書いた却下理由は、スキル編集を検討すべきサインです。スキル本文に反映し、同じことを繰り返し伝えなくてもスカウト群が対応できるようにしましょう。 逆の場合も同様です。編集として確定する前に、まずメモで試してみてください。 メモの整理は人間が行います。スカウトがメモを削除することはないため、対応済みのメモは削除するか、あらかじめ expires_at を設定して、チャンネルのシグナル品質を保ってください。

あなたがいなくてもフリートが学習すること

一部のフィードバックループは自動で動作します。その存在を知っておくと、作業の進め方が変わります。

• スクラッチパッドメモリ。 スカウトはチームごとの永続的なメモリ（ベースライン、ノイズパターン、重複排除ゲート、許可リスト）を書き込み、実行を重ねるごとにノイズが減り、精度が高まります。 スカウトが何かを報告しなくなった場合、故障だと判断する前にスクラッチパッド（noise:／addressed:／dedupe:／allowlist: エントリを対象とする posthog:scout-scratchpad-search）を確認してください。意図的にそれを抑制するよう学習したのかもしれません。
• 自動一時停止。 誰もレポートに反応しない（開かない、評価しない、対応しない）スカウトには警告が表示され（status=pending_pause）、その後、一時停止されます（paused_by_system、pause_reason=ignored）。読むことも反応としてカウントされますが、現在、開封を記録できるのはクラウドのウェブ受信トレイだけです。他のクライアント（デスクトップ、モバイル）で読んでも、まだ記録されないため、そこでのみ利用するスカウトには auto_pause_exempt が必要です。 反応が少ないだけのスカウトはフラグが付くだけで、一時停止されることはありません。何も起きないことが役割の場合もあるためです。また、Slack に配信されるスカウトは対象外です。利用状況をスイープで確認できない場所で消費されるためです。 このスイープによって一時停止されたスカウトを再度有効にすると、新たな猶予期間とともに再開されます。そのため、スイープは約 2 週間待ってから判定を再導出し、再び評価します。スイープに決して評価させたくないスカウトには、auto_pause_exempt を明示的に設定してください。
• 失敗ブレーカー。 12 時間の障害で説明できる範囲を超えて、スケジュールされた実行がすべて失敗するスカウトは、間隔ごとにサンドボックスを消費し続けないよう、pause_reason=repeated_failures で一時停止されます。 しきい値はスケジュールに応じて変わります。12 時間に収まる実行回数を超える失敗回数で、最低 5 回、最高 25 回です。毎日実行するスカウトは 5 回で一時停止し、ローリング式の毎時実行スカウトは 13 回で一時停止します。cron スケジュールでは、夏時間によるずれを考慮して余裕を持たせた期間内の実行枠を数えるため、毎時実行の cron は 15 回で一時停止します。 非アクティブによる一時停止とは異なり、こちらはハーフオープン方式です。コーディネーターは一時停止中のスカウトを 1 日に 1 回プローブし、正常に実行できれば再開します。そのため、原因（期限切れの認証情報や名前が変更されたテーブルなど）を修正すれば、自動的に復旧できます。プロジェクトが有効なスカウトの上限に達している場合、再開は拒否されます。同じ理由で手動での有効化も拒否されるため、正常なプローブの後も行が paused_by_system のままなら、まず別のスカウトを一時停止するか削除してください。 設定行の consecutive_failure_count には連続失敗回数が表示されます。加算されるのはスケジュールされた実行の失敗だけです。どのトリガーによる実行でも正常に完了すればリセットされ、設定を編集してもリセットされます。実行の failure_reason（posthog:scout-runs-list）には、失敗の原因が記載されています。
• 自己改善の提案。 カスタムスカウトは、独自のスキル本文に誤った方向へ導かれていると気づくと、improve:<skill-name>:<topic> というスクラッチパッドエントリを書き込みます。また、レポートチャネルを使うカスタムスカウトは、繰り返し発生する提案を「Scout self-improvement: …」というタイトルの受信トレイレポートにして、オーナーに送ります（従来のシグナルチャネルのスカウトはレポートを作成できないため、提案はスクラッチパッドにのみ保存されます）。 これは、フリートが自らのコードレビューを求めているということです。複数回の実行で再確認されたエントリは、通常、最も有益な編集の手がかりになります。 これらは指示ではなく、入力として扱ってください。採用するかどうかはオーナーが判断し、採用した提案は authoring-scouts を使って反映します。 （標準スカウトはスキルの不足を上流の PostHog に報告するため、improve: エントリは残しません。）

時間をかけて調整する

放置されたフリートは徐々にずれていきますが、ときどき見直すフリートは成果を積み重ねます。 数週間ごと（または誰かが「スカウトって本当に役に立っているの？」と言ったとき）に、調整を行います。

1. 健全性を確認する — exploring-scouts の評価を実施します（scripts/assess_health.py が、実行頻度の遵守率、成功率、レポート率、メモリの増加といった実行レベルの分析を担います）。 このスクリプトは対象期間内に実行記録があるスカウトのみを評価するため、有効になっているのに最近の実行行がないスカウトについては、名簿を確認してください。 実行記録がない原因を調べる前に、authoring-scouts → references/scheduled-precheck.md →「実行行がないティックを診断する」の手順に従い、記録された last_precheck_at と last_precheck_outcome を確認してください。 最近記録された skip は、活動が静かな理由にはなり得ますが、全体の健全性を示すものではありません。結果データが古い、または存在しない場合、原因は不明のままです。クエリのテストにはドライランを使用してください。 このスクリプトは結果ではなくレポートの書き込み件数も数えるため、posthog:inbox-reports-list で書き込まれたレポートを特定し、ステータスを確認して、シグナルとノイズの比率を判断してください。 健全な実行の多くは、何も見つからずに終了することを忘れないでください。静かな実行が続くのは、フリートが正常に機能している証拠であり、故障ではありません。
2. フリートからの要望を確認する — posthog:scout-scratchpad-search {"text": "improve:"} と、受信トレイの Scout self-improvement: レポートを調べ、再確認された提案を適用します。 検索結果にはデフォルトで新しいものから20件が返されます。フリートの規模が大きい場合、古い提案が見落とされないように limit を増やすか、date_to を指定して過去にさかのぼってください。
3. 指針を反映し、整理する — 繰り返し寄せられるメモや、却下理由をスキル本文の編集に反映し、古いメモは削除します。
4. 名簿を適切な規模にする：チームが使わなくなった対象ではスカウトの実行頻度を下げるか一時停止するか、スケジュール済み事前チェックを設定して新しい情報がある場合にのみ開始するようにします（手順は authoring-scouts を参照してください）。pending_pause / paused_by_system の行を確認し、デフォルトの動作に任せるのではなく、pause_reason に基づいて判断します（ignored：再開するか、停止したままにします。repeated_failures：最新の実行の failure_reason を確認して原因を修正します。修正するとプローブによって再開されます）。また、チームが新たに重視し始めたのに、監視するスカウトがいない対象には、新しいスカウトを検討してください。スカウトタブの「このプロジェクトにおすすめ」欄は、候補を見つける手軽な方法です。
5. ルーティングを確認する：共有受信トレイに未割り当てのレポートがたまっている場合は、調査結果が対応する人に届くよう、レビュー担当者のルーティングを修正します。誤った送信先に転送されたレポートのレビュー担当者を正しく設定し（フリートに転送済み）、担当ルールをフリート全体のメモに残します（pipeline:report-research のメモが届くのはシグナルから生成されたレポートのみです）。また、既知の担当者に向けてスカウトを誘導します。

よくある依頼と対応先

ユーザーの発言…	対応
「X を監視するスカウトを用意して」／「Y が急増したら知らせて」	上記の委任表。レシピはreferences/delegation-recipes.mdを参照してください。
「スカウトは何をしている？」／「スカウトは動いている？」	exploring-scouts
「何を確認すればいい？」／「スカウトは何を見つけた？」	inbox-exploration
「このスカウトのレポートを修正して」／「このレポートは本物？」	inbox-exploration（まず検証）、その後に対応し、状態とメモを残して完了させます。
「これの報告を止めて」／「その発見はノイズだ」	根拠を含むメモを添えて却下します。再発する場合は、除外条件の編集に昇格させます。
「今週は X に集中して」	期限付きのメモ（expires_at）
「今すぐ X を確認して」	1 回限りの実行用noteを指定してposthog:scout-run-nowを実行します。
「このスカウトのレポートを Slack に送って」	output_destinations.slackを指定してposthog:scout-config-updateを実行します。手順はauthoring-scoutsを参照してください。
「これらのレポートをに回して」	レポートのレビュアーを修正します。継続的なルールには、全スカウト共通または個別スカウトのメモを設定します。
「スカウトの報告が多すぎる／少なすぎる」	上記の調整を行い、その後、問題のスカウトに対して段階的な調整を適用します。
「スカウトを作成／編集／再調整して」	authoring-scouts
「スカウトが X に警告を出さなくなったのはなぜ？」	まずスクラッチパッド（noise:／addressed:／dedupe:／allowlist:）、次にメモ、最後に設定を確認します。
「このスカウトは何を変更した？」	上記の「スカウトが変更した内容の監査」を参照してください。実行期間と利用可能な履歴を確認します。
「その修正はちゃんと維持された？」	解決済みレポートに対してposthog:inbox-report-checks-listを実行します。手順はauthoring-scoutsを参照してください。