brief

ブリーフ管理

ブリーフは、ローカル SEO の業務で継続的に使う作業状態を保存します。1 つの拠点につきブリーフは 1 つです。複数拠点を扱う場合は、ブランド全体をまとめて管理します。スケジュールされたタスクの出力によってブリーフは時間とともに拡充され、各ビジネスのあらゆるスキャン、監査、レポート、調査結果の履歴が蓄積されていきます。

---

構成

briefs/
  {brand}/
    _brand.brief.md          ← config + rollup across all locations
    reports/                 ← brand-level rollup reports
    {location}/
      location.brief.md      ← always current, always lean
      reports/               ← weekly, monthly, QBR reports
      scans/                 ← geogrid scans, citation audits, page audits
      drafts/                ← GBP posts, review responses awaiting approval
      alerts/                ← monitoring alerts

---

初回実行の検出

ここは最も重要なセクションです。 ユーザーが特定のビジネスについて言及し、ブリーフが存在しない場合は、依頼にまだ着手しないでください。まずセットアップを実行してから、依頼された内容に戻ってください。

検出

特定のビジネスについて作業を始める前に、既存のブリーフがあるか確認してください。

• Claude Code：briefs/{brand-slug}/{location-slug}/location.brief.md を探します
• Claude Project：Project のナレッジベースで、このビジネスのブリーフファイルを確認します
• 見つかった場合：ブリーフからの再開に進みます
• 見つからない場合：初回セットアップに進みます

初回セットアップ

ユーザーに伝えます。

「[Business Name] のブリーフはまだありません。今後すべてを追跡できるよう、いくつか詳細を確認します。所要時間は約 2 分です。」

次の質問を一度に 1 つずつ尋ねてください。一度にすべて尋ねてはいけません。

Q1: 「上位表示を狙いたい主要キーワードは何ですか？（例：『plumber buffalo ny』）」

Q2: 「ウェブサイトの URL は何ですか？」

Q3: 「サービス提供エリアはどのくらいの範囲ですか？（例：5 マイル、20 マイル）」

Q4: 「これはクライアントのために管理していますか？それともご自身のビジネスですか？」

• クライアントの場合、次のように尋ねます：「レポート送付先となるクライアントのメールアドレスは何ですか？」
• 自社ビジネスの場合は省略します

Q5: 「アラートやレポートを Slack チャンネルに送信しますか？」（任意。不要との回答なら省略します）

以上です。本当に曖昧な点がない限り、これ以上質問しないでください。

質問の後

1. ブリーフのフォルダー構成を作成します。

   • briefs/{brand-slug}/{location-slug}/location.brief.md
   • briefs/{brand-slug}/{location-slug}/reports/
   • briefs/{brand-slug}/{location-slug}/scans/
   • briefs/{brand-slug}/{location-slug}/drafts/
   • briefs/{brand-slug}/{location-slug}/alerts/
   • briefs/{brand-slug}/_brand.brief.md

2. 回答と会話にすでに含まれるコンテキストから、Identity セクションを入力します

3. Q4/Q5 の回答をもとに、_brand.brief.md の承認ブロックを設定します

4. 許可を求めずに、初回監査を自動的に実行します。

   • LocalSEOData local_audit
   • LocalSEOData business_profile + profile_health
   • LocalSEOData geogrid_scan（7x7、主要キーワード、申告された半径）
   • LocalSEOData citation_audit
   • LocalSEOData review_velocity + google_reviews
   • LocalSEOData competitor_gap

5. 監査結果をもとに Findings を入力します

6. Next Action に、最優先の修正項目を 1 つ設定します

7. スケジュールされたタスクの設定を提案します。

   「ブリーフを作成し、初回監査が完了しました。[X 件の重大な問題、Y 件の重要な問題] が見つかりました。[最も重要な調査結果を一文で記載]。

   自動モニタリングを設定しますか？週次のランキングスキャン、レビューのモニタリング、GBP の変更検出、月次レポートを自動実行するよう設定できます。」

   はいの場合は、tasks/README.md のタスクリストを確認し、監査結果に基づいて推奨したうえで、/schedule から設定します いいえの場合は、元の依頼に進みます

8. その後、ユーザーが最初に依頼した内容に戻ります。

   「では、[元の依頼] を進めます……」

Claude Project / ブラウザーのユーザー向け

ファイルシステムにアクセスできない場合は、同じ会話と監査を実行し、セットアップの最後に整形したテキストとしてブリーフを出力します。

「こちらがブリーフです。次回も参照できるよう、Project のナレッジベースに追加してください。」 [ブリーフの内容]

---

ブリーフを作成するタイミング（初回実行以外）

初回実行以外では、次の場合にセッションの途中でブリーフを作成します。

• ブリーフのないビジネスについて、ツールを呼び出そうとしている
• ユーザーが明示的に作成を依頼した

次の場合はブリーフを作成しないでください。

• 特定のビジネスを指定しない一般的なローカル SEO の質問
• ツールやスキルの説明
• ライブデータを使用しない単発の質問への回答

概要の場所

Claude Code / Cowork:

briefs/{brand-slug}/{location-slug}/location.brief.md

Claude Project: 作成後、概要ファイルをProjectのナレッジベースにアップロードします。まだアップロードしていない場合は、ユーザーにその旨を伝えてください。

---

概要の更新（手動セッション）

各セッションの終了時に、次の内容を更新します。

1. セッションログ。 1行で記載します：日付＋作業内容
2. 実行したツール。 各ツール呼び出しについて、日付、ツール、エンドポイント、1行の所見を記載します
3. 所見。 新たな問題を「重大」「重要」「監視」に分類します
4. 成果物。 完了した項目に印を付け、新たな保留項目を追加します
5. 次のアクション。 最も重要な次のステップを1つだけ残して上書きします

---

スケジュールされたタスクの出力を受け取る

スケジュールされたタスクが出力ファイルを書き込んだ場合：

1. 出力ファイルを読みます
2. セッションログに次の形式で1行追加します：[DATE] | {task type} → {one-line finding} → see {output path}
3. 新たに重大な所見があれば、「所見」セクションを更新します
4. タスクによって現在のものより優先度の高い項目が明らかになった場合は、「次のアクション」を更新します
5. この場所に対応する _brand.brief.md の「場所」テーブルの行を更新します

概要は簡潔に保ちます。詳細は出力ファイルに記載します。概要はインデックスです。

---

概要から再開する

ユーザーがビジネスに戻ってきたら：

1. 概要を読みます
2. 各サブフォルダー内の最新の出力ファイルを読み、現在の状態を確認します
3. 実施済みの内容、主な所見、現在の状態を2～3文で要約します
4. 次のアクションを伝えます
5. 「ここから再開しますか、それとも何か特定のことをしますか？」と尋ねます

ユーザーからの依頼がない限り、scans/ に結果があるツールは再実行しません。ただし、データが30日を超えて古い場合は除きます。

---

複利的な価値

スケジュールされたタスクが概要に書き込む状態が数か月続くと、履歴を検索できるようになります。

• 「3月にランキングが下がったのはなぜ？」と聞かれたら、その期間の scans/ を確認します
• 「今年のレビューの推移は？」と聞かれたら、reports/ のレビュー監視データを確認します
• 「この競合他社はいつ登場した？」と聞かれたら、競合他社の監視データを確認します

出力ファイルは絶対に削除しないでください。 フォルダーが扱いにくくなった場合は、アーカイブします。履歴にこそ価値があります。

---

学びのフライホイール

手動かスケジュール実行かを問わず、すべてのセッションで次の点に注意します。

• ツールがスキルファイルの記述と矛盾するデータを返す
• 3か所以上にわたってパターンが見られるが、どこにも記録されていない
• GBP、アルゴリズム、またはAIプラットフォームの動作が、記録された想定と異なる
• ツールのエンドポイントが予期しない動作をする

このようなことに気づいたら、明確に伝えます。

「このセッションで[X]に気づきました。このパターンはスキルファイルに記載されていません。確認用に meta/lessons.md に追加しましょうか？」

確認を待ってから、学びを書き込みます。

---

複数拠点を持つブランド

各拠点のセッション後：

• _brand.brief.md の「場所」テーブルで、その拠点の行を更新します
• パターンが3か所以上で見られる場合に限り、「ブランドレベルのメモ」に追加します

---

スラッグ形式

小文字とハイフンを使い、分かりやすくします。

• ブランド：keystone-insurance、mikes-plumbing
• 拠点：buffalo、downtown-chicago、pittsburgh-pa