旧: ✅ タスクDBに並列タスクとして登録

単発でも複数ステップでも、タスクは常に並列（フラット）で登録する。

mcp__claude_ai_Notion__notion-create-pages:

• parent: data_source_id: 292cf503-a68f-81c6-b9dd-000b3ffdd2ce
• タスク名: タスク名（複数ステップの場合は各ステップを独立タスクに分解し、タイトル先頭に [テーマ名] プレフィクスを付ける。例：[違法石積み] 土木課に電話）
• ステータス: "inbox"
• 優先度: 活動内容から推定（高/中/低）
• 期限（あれば）: date:期限:start
• 相談元氏名・相談元連絡先（市民相談由来の場合）
• プロジェクト（該当する既存プロジェクトがあればリレーション設定）

旧: 🗂️ プロジェクトDB

プロジェクト化判定（基準A〜E、2026-05-01以降必須） — 1つ以上該当時にプロジェクト化を提案：

• A: 同一テーマで関連タスク2件以上 / B: 同テーマ散在3件以上
• C: 着手〜完了が2週間超 / D: 複数ステークホルダー絡み
• E: 「〜検討」「〜整備」「〜推進」等の継続性ある語感

重複判定回避: 既に「昇格判定日=今日」が入っているタスクは再判定スキップ（oyasumiとのダブル提案防止）。

提案文：「このタスク群は『{テーマ}』というプロジェクトとして管理するとよさそうです（基準{A,B,...}該当）。プロジェクトDB（🗂️）に作成しますか？」

yesの場合：

• parent: data_source_id: 292cf503-a68f-81fe-bd40-000b64314f2e
• プロジェクト名／ステータス="バックログ"／優先度／期間／要約／由来（既存タスク群統合/新規企画/市民意見起点/議会案件/その他）を設定
• 5-Aで作成した各タスクの プロジェクト リレーションで新プロジェクトに紐付け
• 各タスクに 昇格判定タグ（multi_select A/B/C/D/E）と 昇格判定日（今日）を必ずセット

禁止事項：タスク間で親子階層（親タスク／サブタスク）を作らない。プロジェクト間で親子階層（親プロジェクト／サブプロジェクト）を作らない（2026-04-24フラット2層運用）。グルーピングはタイトルプレフィクスとプロジェクトリレーションで表現する。

最終サマリー

全ステップ完了後、以下を出力する：

✅ 本日の活動を記録しました

📓 日次ログ: [NotionページURL]
[一般質問ネタDB登録があれば] 🗳️ 一般質問ネタ: [件数]件登録
[SNS登録があれば] 📣 SNS下書き: [NotionページURL]
[ブログ登録があれば] 📝 ブログ下書き: [NotionページURL]
[タスク登録があれば] ✅ タスク: [件数]件登録

注意事項

• 一般質問ネタ・コンテンツ生成は必ず確認を取ってから実行する（自動登録禁止）
• タスク以外の確認は飛ばさず全て聞く
• 全て日本語で応答する
• 今日の日付は currentDate コンテキストから取得する（なければシステム時刻を使う）
• ページURL取得に失敗した場合は「Notionで確認してください」と伝えれば十分

仕上げモード

ユーザーが「仕上げ」「モバイル記録を仕上げて」「モバイル下書きを仕上げ」等と発言した場合に起動する。スマホ（Claude.aiプロジェクト版 nichijo-mobile）で作成されたタイトル先頭 📱 付きの下書きを Notion 横断で検出し、深掘り調査＋サブエージェント群で仕上げ版を生成して 同じページを上書き するモード。

S1: 下書きの検出

以下3つの専用ビュー（タイトル前方一致 📱 + 未完成ステータス）を mcp__claude_ai_Notion__notion-query-database-view で並列クエリする。notion-search はセマンティック検索で絵文字プレフィクスを取りこぼすため使用禁止。

各ページの「タイトル・URL・data source 種別・本文・登録日・分野」を内部メモに保持。

本文（ページコンテンツ）が必要な場合は mcp__claude_ai_Notion__notion-fetch で個別取得する（ビューはプロパティのみ返す）。

S2: 一覧提示とユーザー選択

以下のフォーマットで提示し、ユーザーに選択させる：

【モバイル下書き一覧（仕上げ待ち）】

■ 一般質問ネタ（N件）
  ① 📱 [ネタ名] | [分野] | [登録日]
  ② ...

■ SNS投稿（N件）
  ③ 📱 [投稿タイトル] | [分野] | [登録日]
  ...

■ ブログ記事（N件）
  ⑤ 📱 [記事タイトル] | [分野] | [登録日]
  ...

どれを仕上げますか？（番号指定 / 全部 / 種類指定例: "SNS全部"）

0件の場合は「モバイル下書きはありません」と伝えて終了。

S3: 仕上げ実行

ユーザーが選んだ各項目について、種別に応じた処理を行う。処理は上書き更新のため、元の下書き本文は消える点に留意する。

S3-A: 一般質問ネタの仕上げ

1. policy-researcher と kameyama-researcher を並列起動：

Agent(subagent_type="policy-researcher",
  prompt="テーマ「{ネタ名}」について以下を調査。
  1. 国の政策・法制度（名称・年月日明記）
  2. 統計データ（全国・三重県・亀山市）
  3. 先進自治体の具体事例（人口4.5万人規模優先・最低3自治体）
  4. 失敗事例・中止事例")

Agent(subagent_type="kameyama-researcher",
  prompt="テーマ「{ネタ名}」について亀山市の現状を agents/kameyama-researcher.md に従い調査。
  現状・既存施策・担当課・議会過去質問・三重県動向・政策提言の核心")

2. 両結果を統合してメモ／根拠を再構成し、mcp__claude_ai_Notion__notion-update-page でページを更新：
   • タイトル: 📱 プレフィクスを削除（純粋な「ネタ名」に戻す）
   • 状況: "下書き" に更新
   • メモ／根拠: 調査結果を反映した厚いメモで上書き
   • ページ本文: 調査サマリ＋論点＋引用をMarkdown構造で記載

S3-B: SNS投稿下書きの仕上げ

1. 元ページ本文から活動要旨を抽出
2. content-pipeline Step 1.5（policy-researcher + kameyama-researcher 並列調査）を実行し、亀山市の文脈と他自治体事例を収集
3. sns-content-creator エージェントを起動し、Threads/X/Instagram/Facebook（+ 元々の LINE 文は活かすか再生成）の仕上げ版を生成
4. 【必須3ゲート通過】 以下を順に実行（CLAUDE.md「発信物の安全ゲート」ルール）：
   • 4-a. content-editor（媒体別品質スコア） → pass
   • 4-b. content-fact-checker（数値・固有名詞・法令の一次情報検証） → APPROVE
   • 4-c. content-risk-reviewer（公選法・個人情報・名誉毀損等の8軸） → APPROVE
   • HIGH検出時は草川にASK_USERで問いかけ・本人判断後に進む
   • CRITICAL検出時は即停止し草川に通知（Notionは更新しない）
5. mcp__claude_ai_Notion__notion-update-page でページを更新（ゲート全通過後のみ）：
   • 投稿タイトル: 📱 プレフィクスを削除
   • ステータス: "下書き完成"
   • ページ本文: 5媒体の仕上げ版で完全に上書き
   • メモ欄: 各ゲートの判定結果（editor:pass/fact:APPROVE/risk:APPROVE）を記録

S3-C: ブログ記事下書きの仕上げ

1. 元ページ本文からテーマ・骨子を抽出
2. ブログモードの確認（必須・ユーザーに質問）: ブログ仕上げは blog-writer（深掘り）と blog-writer-normal（ノーマル）のどちらを使うかで性格が大きく変わる。以下を提示してユーザーに選ばせる（選択を得るまで次に進まない）：

---

## 📝 「[記事タイトル]」のブログ仕上げモード確認

**①深掘りモード（blog-writer）**
1500〜2500字・5段構成・政策論型・高ファクト密度。議会引用可能な骨太の論考。

**②ノーマルモード（blog-writer-normal）**
800〜1500字・柔軟構成・読みやすさ重視・専門用語回避。普段政治に関心のない市民向け。

**①深掘り / ②ノーマル** のどちらで仕上げますか？
---

複数記事を一括仕上げする場合は「全部深掘り」「全部ノーマル」「個別指定」も受け付ける。

3. content-pipeline Step 1.5（policy-researcher + kameyama-researcher 並列調査）を実行

4. 選択されたモードのエージェントを起動：

   • 深掘り → blog-writer エージェント（content-pipeline Step 2-A と同じプロンプト）
   • ノーマル → blog-writer-normal エージェント（content-pipeline Step 2-B と同じプロンプト）

   どちらもタイトル先頭の 【草川たくや 亀山市】 は維持する（パターンC セリフ引用型の場合はその限りではない）。

5. 【必須3ゲート通過】 以下を順に実行（CLAUDE.md「発信物の安全ゲート」ルール）：

   • 5-a. content-editor（5軸品質スコア・mode引数で深掘り/ノーマル切替） → pass
   • 5-b. content-fact-checker（数値・計画名・条例名・法令を一次情報まで遡って検証） → APPROVE
   • 5-c. content-risk-reviewer（公選法・個人情報・名誉毀損等の8軸） → APPROVE
   • HIGH検出時は草川にASK_USERで問いかけ・本人判断後に進む
   • CRITICAL検出時は即停止し草川に通知（Notionは更新しない）

6. mcp__claude_ai_Notion__notion-update-page でページを更新（ゲート全通過後のみ）：

   • 記事タイトル: 📱 プレフィクスを削除
   • ステータス: "下書き完成"
   • ページ本文: 仕上げ版で完全に上書き
   • メモ欄: 使用したモード（深掘り/ノーマル）＋各ゲート判定（editor:pass/fact:APPROVE/risk:APPROVE）を記録

S3.5: タスク抽出と登録（確認あり）

S3 で仕上げた各ページから、具体的な次アクションを抽出してユーザーに提案する。ユーザーの同意が得られた項目のみTodoistに登録する（td.py add）。

抽出ロジック

一般質問ネタ（S3-A）を仕上げた場合
policy-researcher / kameyama-researcher の調査結果から、以下の観点で次アクションを3件以内で抽出：

• 対象定例会での一般質問（通告案・再質問案の作成）
• 担当課（想定）への事前ヒアリング
• 先進自治体や県への運用照会・情報請求
• 未確認事項の追加調査（公式未確認と判明した項目があれば）

SNS投稿（S3-B）を仕上げた場合

• 各媒体への投稿実施（予定日の決定）
• 投稿に必要な画像・動画素材の準備
• 反応確認・返信対応のリマインド

ブログ記事（S3-C）を仕上げた場合

• 公開予定日の決定・投稿作業
• アイキャッチ画像の準備
• SNS連携投稿の手配

提示フォーマット

仕上げ対象ごとに以下のように提案する（複数ページを一括仕上げした場合はまとめて提示）：

【タスク候補】

■ [🗳️/📣/📝 ネタ名 or タイトル]
  ① [タスク名] | 優先度: [高/中/低] | 期限案: [YYYY-MM-DD（既定=今日+3日）] | 〔登録先箱〕
  ② [タスク名] | ...
  ③ [タスク名] | ...

■ [次のページ...]
  ④ ...

これらをTodoistに登録しますか？
（全部 / 番号指定 / スキップ）

0件抽出された場合は「このページからは追加タスクを検出できませんでした」と伝えてスキップする。

登録先の振り分け

仕上げ対象の種別ごとに登録先DBを使い分ける：

🔴 登録先はすべて Todoist（td.py add／該当の地区・イベント・政策箱・期限つき）。一般質問ネタ抽出は📝一般質問ネタDB(42716725)へ、PJ束ねは🗂プロジェクト・プラットフォーム(8975c6a9)経緯ログへ。以下のNotion✅タスクDB手順は無効（参照のみ）：

登録処理

🔴 ユーザーが「全部」または番号を指定した場合のみ登録する。登録先はTodoist（python3 ~/.claude/scripts/todoist/td.py add）。Notion✅タスクDBへのcreateは廃止。

一般質問ネタ発のタスク

1. （必要なら）🗂プロジェクト・プラットフォーム(ds=8975c6a9)に束ね用PJページを作成 or 既存PJの📅経緯ログに追記
2. 抽出したアクションを Todoist該当箱（地区/イベント/政策箱）に td.py add "[{ネタ名}] {アクション}" --project <箱> --due <期限> --priority <1-4> で登録。ネタ自体は📝一般質問ネタDB(42716725)へ

SNS投稿・ブログ記事発のタスク（単発並列）

• td.py add "<タスク名>" --project "📣 発信" --due <期限> --priority <1-4>（タスク名25字以内目安・期限未指定は今日+3日）

元ページとの紐付け

• --desc に 参照: [元仕上げ対象ページURL] を記載する

既存Todoistプロジェクトとの連携
一般質問ネタが既存プロジェクトの一部（例：「子育て支援テコ入れ2026」等）の場合、ユーザーに確認の上、td.py projects で実在名を確認して該当サブプロジェクトに --project で登録する（🗂プロジェクト・プラットフォームに対応PJページがあれば📅経緯ログにも1行追記）。

エラーハンドリング

• タスク登録に失敗した場合は最大2回リトライし、失敗したタスク名とエラー要旨を報告する
• 他のステップ（S4サマリー）は通常通り進める

S4: サマリー出力

全選択項目の処理完了後：

✅ モバイル下書きを仕上げました

🗳️ 一般質問ネタ: [件数]件仕上げ
  - [ネタ名] [URL]
📣 SNS投稿: [件数]件仕上げ
  - [投稿タイトル] [URL]
📝 ブログ記事: [件数]件仕上げ
  - [記事タイトル] [URL]
✅ タスク: [件数]件登録（スキップ時はこの行を省略）
  - [タスク名] [優先度]

⚠️ 元のモバイル下書き本文は上書きされました（Notion の版履歴から復元可能）。

S5: 当日活動ログへの自動追記（必須・確認不要）

S4 サマリー出力後に、本日の仕上げ作業を「2026-04-29 活動ログ」のような当日 YYYY-MM-DD 活動ログ（日次ルーティンログDB f6d15ac0-73fa-414f-8242-03e8f06aa4e3）へ自動追記する。確認は不要・自動実行。

処理フロー

1. mcp__claude_ai_Notion__notion-search で当日タイトル YYYY-MM-DD 活動ログ を日次ログDB内検索
2. 既存ページがある場合: notion-update-page の update_content で末尾に追記
3. 存在しない場合: 2-C と同じ手順で新規作成し、本セクションを最初の本文として配置

追記内容（テンプレート）

---

### 追記 [仕上げモード / 📱モバイル下書き仕上げ]

「仕上げ（モバイル下書き単独）」モードを実行。📱付き下書きの上書き仕上げを完了。

#### 仕上げ対象と生成物
- 🗳️ 一般質問ネタ: [件数]件
  - [ネタ名] → [Notion URL]（policy-researcher + kameyama-researcher 並列調査済み）
- 📣 SNS投稿: [件数]件
  - [投稿タイトル] → [URL]
- 📝 ブログ記事: [件数]件
  - [記事タイトル]（[深掘り/ノーマル]） → [URL]

#### S3.5 で派生したタスク
- [タスク名] [優先度] → Todoist〔登録先箱〕
  （件数0の場合は本セクション省略）

#### 重要な軌道修正・学び
- 仕上げ過程で発覚した事実誤認の修正、policy-researcher/kameyama-researcher が示した重要発見、voice-dna整合の見直し点があれば必ず記録
- なければ本セクション省略

⚠️ 元下書き本文は上書き済み（Notion 版履歴から復元可能）

追記成功後、サマリー（S4）の末尾に「📓 日次ログ追記: [当日活動ログURL]」を1行追加する。

仕上げモードの注意事項

• 上書き方式のため、元のモバイル下書きは本文ごと置き換わる。Notion の版履歴から復元可能だが、念のためサマリーで注意喚起する
• 📱 プレフィクスは仕上げ完了時に必ず削除する（再度仕上げ対象として検出されないため）
• 一度に多数選択されると調査・生成に時間がかかる。5件を超える場合は「分割して実行しますか？」と確認
• kameyama-researcher / blog-writer / sns-content-creator / policy-researcher / notion-saver は content-pipeline 配下のエージェント定義に従う
• S3.5 タスク抽出は確認必須。自動登録禁止（誤タスクを量産しないため、ユーザーのyesまたは番号指定が必要）

コンテンツ抽出モード（今日まるごと → ブログ・SNS）

ユーザーが「今日のコンテンツ抽出」「今日のネタを全部出して」「今日まるごと抽出」「今日の活動からブログ/SNS作って」「今日のコンテンツ素材」等と発言した場合に起動する。当日の活動・市民相談・ニュース・一般質問ネタ・完了タスク・政策候補をNotion横断スキャンし、ブログ／SNSに使えるテーマを横断的に抽出してユーザーに提示し、GOサインが出たテーマについてのみ content-pipeline 経由で生成→Notion保存する。

仕上げモード（📱付き下書きの個別仕上げ）と異なり、下書きが無くてもゼロから当日情報をスキャンして発信ネタを発掘するのが特徴。

C1: 当日情報の横断スキャン（並列クエリ）

以下を mcp__claude_ai_Notion__notion-query-database-view / mcp__claude_ai_Notion__notion-fetch / mcp__claude_ai_Notion__notion-query-meeting-notes で並列取得する。当日 = currentDate（YYYY-MM-DD）。

各ソースから取得した情報を内部メモにまとめ、{ソース種別 / タイトル / 要旨 / 登録日 / 元URL} を保持する。並列クエリで取得時間を最小化する。

該当データが0件のソースはスキップしてC2へ。全ソースが0件の場合は「本日のコンテンツ素材になりうる情報が見つかりませんでした」と伝えて終了。

C2: テーマ候補の抽出と評価

横断情報から ブログ／SNSに使えるテーマ候補を5〜10件 に絞る。各候補に以下のメタデータを付ける：

• テーマ名: 具体的・読み手が引っかかるタイトル案（30字以内目安）
• ソース: 上記7カテゴリのどれか（📓/💬/🗳️/📰/🤝/🎯/✅。複数ある場合は主要1つ＋補助を併記）
• 媒体相性: ブログ向き / SNS向き / 両方OK
  • SNS向き = 短く感情訴求できる／写真がある／即時性が高い／実績報告
  • ブログ向き = 文脈の説明が必要／データ豊富／政策論型／賛否ある論点
• 発信角度: 現場報告 / 市民共感 / 政策提言 / 啓発 / 警鐘 / お知らせ / 感謝・連帯
• 優先度: 高 / 中 / 低（時事性・市民関心・草川独自性で評価）
• 要旨: 1〜2文で内容をまとめる
• 注意点: 個人情報秘匿／進行中案件で発信不可／iJAMP原文転載禁止（要約反映可）／公選法配慮 等

抽出時の判断ルール（必読）

• Calendar当日分の取り扱い：参加した／参加予定の地域イベント・街頭演説・挨拶まわり・後援会活動はテーマ化候補。ただし事前予定（未開催）はリアルタイム発信／予告系の素材として SNS 向きに分類し、ブログ深掘りには回さない（実施後に書く）。家族・個人系は Step 1.5 で除外済みなので候補に上げない
• 市民相談の個人情報は絶対に出さない：氏名・住所・連絡先・特定可能な業種/店舗名はテーマ化時点で一般化する
• iJAMP（時事通信社配信記事）は原文転載禁止・要約反映は可：ニュースDBに保存されているiJAMPメールの要約・議会活用視点はテーマ抽出の素材として活用してよい。ただし原文の文章をブログ・SNSに直接転載・コピペ・長文引用することは禁止。取り上げる場合は草川自身の言葉でリライトし、必要なら「時事通信社の報道によると」程度の短い出典言及にとどめる（運用ルール 2026-04-27 補正）
• 進行中の市民相談（対応状況≠"完了"）は具体名なしで一般論として扱う
• 完了タスクは「やったこと報告」として SNS と相性が良い（写真があればなお良い）
• 一般質問ネタで「未整理」状態のものはブログ深掘り向き、議会終了後の振り返りはブログ向き
• 🤝 ミーティングノートの取り扱い：会議の場で出た発言・決定事項のうち、公開可能なものだけをテーマ化する。具体的には(1)会議の存在・概要報告、(2)草川自身の発言・気付き、(3)既に対外公表された決定事項、はOK。(a) 他者の未公表発言の引用、(b) 非公開会議（会派内・関係者ヒアリング・職員ブリーフィング）の内容、(c) 個人の名指し批判は禁止。判断に迷う場合は候補から除外する
• 公選法配慮：候補者・政党比較や対立候補ネガティブ言及は提案しない
• 重複排除：同じ事象が複数DBに記録されている場合（例：相談→タスク→活動ログ）は1テーマに統合し、ソース欄に複数明記
• 草川の禁止用語リストを踏まえる（「悉皆」等は使わない／市民向け平易な日本語）

C3: テーマ一覧の提示とユーザー選択（GOサイン取得）

以下のフォーマットで提示する：

【今日のコンテンツ素材候補】（YYYY-MM-DD分）

① [テーマ名]
   ソース: [📓活動ログ/💬市民意見/🗳️質問ネタ/📰ニュース/🤝会議メモ/🎯政策候補/✅完了タスク]
   媒体: [ブログ向き/SNS向き/両方OK] | 角度: [発信角度] | 優先度: [高/中/低]
   要旨: [1〜2文]
   ⚠️ [注意点があれば（なければ省略）]

② [テーマ名]
   ...

③ ...

──────────
発信したいテーマを教えてください。

回答例：
- 「①③⑤を両方」「②をSNSのみ」「④をブログ深掘り」
- 「全部」「優先度高だけ」「SNS向きだけ」
- 「スキップ」（生成しない）

候補が0件の場合は「本日のコンテンツ素材候補はありません（情報源には●件あったがすべて発信不適）」と伝えて終了。

C4: 媒体・モードの最終確認

ユーザーが選んだテーマごとに、以下を確認する（C3で一括指定があれば省略）：

• 媒体: ブログのみ / SNSのみ / 両方（C3で未指定の場合）
• ブログモード（ブログを作る場合）: ①深掘り（blog-writer：1500〜2500字・政策論型）／②ノーマル（blog-writer-normal：800〜1500字・市民向け）

複数テーマある場合は「全部深掘り／全部ノーマル／個別指定」も受け付ける。

C5: コンテンツ生成（content-pipeline 委任）

選ばれた各テーマについて、content-pipeline スキルを起動する。content-pipeline には以下の素材セットを渡す：

• テーマ名（生成のメインテーマ）
• 元ソース本文（C1で取得した該当部分。市民相談由来の場合は個人情報を除いた一般化版）
• 発信角度（C2で決めた角度をプロンプトのトーン指示として）
• 媒体指定（ブログのみ／SNSのみ／両方）
• ブログモード指定（深掘り／ノーマル）

content-pipeline 内で以下が実行される：

• Step 1.5: policy-researcher + kameyama-researcher 並列調査（必要に応じて）
• Step 2: blog-writer or blog-writer-normal で本文生成（冒頭定型挨拶必須）
• Step 2.5: content-editor で品質チェック
• Step 3: sns-content-creator で SNS 5〜7媒体生成
• Step 4: Notion 保存（ブログ記事管理DB dcdf44af-... / SNS投稿管理DB 1bd98deb-...）

複数テーマを一括処理する場合は1テーマずつ順次処理し、各テーマ完了時に進捗を逐次報告する。5件超過時は分割を提案（「処理に時間がかかるため3件ずつに分けますか？」）。

C6: サマリー出力

全テーマ処理後：

✅ 今日のコンテンツを生成しました（[件数]テーマ）

📝 ブログ記事: [件数]件
  - [テーマ名]（[深掘り/ノーマル]） [Notion URL]
  - ...
📣 SNS投稿: [件数]件
  - [テーマ名] [Notion URL]
  - ...

🌱 元ソース内訳:
  📓活動ログ●件 / 💬市民意見●件 / 🗳️質問ネタ●件 / 📰ニュース●件 / 🤝会議メモ●件 / 🎯政策候補●件 / ✅完了タスク●件

C7: 当日活動ログへの自動追記（必須・確認不要）

C6 サマリー出力後に、本日のコンテンツ抽出・生成作業を当日 YYYY-MM-DD 活動ログ（日次ルーティンログDB f6d15ac0-73fa-414f-8242-03e8f06aa4e3）へ自動追記する。確認は不要・自動実行。

処理フロー

1. mcp__claude_ai_Notion__notion-search で当日タイトル YYYY-MM-DD 活動ログ を日次ログDB内検索
2. 既存ページがある場合: notion-update-page の update_content で末尾に追記
3. 存在しない場合: 2-C と同じ手順で新規作成し、本セクションを最初の本文として配置

追記内容（テンプレート）

---

### 追記 [コンテンツ抽出モード / 当日素材→ブログ・SNS生成]

「今日のコンテンツ抽出」モードを実行。当日情報をスキャンして発信ネタを発掘し、選択テーマを生成・保存。

#### 元ソース内訳（C1スキャン結果）
📓活動ログ●件 / 💬市民意見●件 / 🗳️質問ネタ●件 / 📰ニュース●件 / 🤝会議メモ●件 / 🎯政策候補●件 / ✅完了タスク●件

#### 選択された生成テーマと生成物
- [テーマ名] | ソース: [📓/💬/🗳️/📰/🤝/🎯/✅] | 媒体: [ブログ/SNS/両方] | 角度: [角度] | 優先度: [高/中/低]
  - 📝 ブログ（[深掘り/ノーマル]）: [Notion URL]
  - 📣 SNS: [Notion URL]

#### 重要な軌道修正・学び
- 生成過程で発覚した事実誤認の修正、policy-researcher/kameyama-researcher が示した重要発見、voice-dna整合の見直し点があれば必ず記録
- 過去発言との連続性として記事に織り込んだ事実があれば記録（産業建設委員会提言・過去定例会答弁等）
- なければ本セクション省略

#### 議会で問う論点（記事内で明示したもの）
- 主要論点があれば箇条書き
- 後日の振り返り・週次レポート（oyasumi金曜）参照用

追記成功後、サマリー（C6）の末尾に「📓 日次ログ追記: [当日活動ログURL]」を1行追加する。

コンテンツ抽出モードの注意事項

• 市民相談の個人情報は絶対に出さない。氏名・住所・連絡先・特定可能な業種/店舗名は内部メモから外し、テーマ化時点で一般論に変換する
• iJAMP記事は原文転載禁止・要約反映は可（運用ルール 2026-04-27 補正）。ニュースDBのiJAMPメール要約はテーマ抽出の素材として活用してよいが、原文の直接転載・コピペ・長文引用は禁止。草川自身の言葉でリライトし、出典言及は「時事通信社の報道によると」程度の短い形にとどめる
• 公選法配慮：候補者・政党比較や対立候補ネガティブ言及は提案しない
• GOサイン必須：C3で「スキップ」または番号未指定の場合は何も生成・保存しない（自動生成禁止）
• content-pipeline への委任時のみ Notion 保存が走る
• ブログ冒頭は必ず「こんにちは、亀山市議会議員の草川たくやです。」で開始（既存ルール踏襲）
• 禁止用語（「悉皆」等の難読語）は使わず、市民向け平易な日本語に置換する

整理モード（当日新規ページ整理）

ユーザーが「整理」「ページ整理」「当日整理」「今日のページ整理」「Notion整理」「ページを仕分けて」等と発言した場合に起動する。当日Notionで新規作成された全ページ（AIミーティングノート含む）をスキャンし、未分類のものを適切な保存先（📅ミーティングノートDB／市民意見リストDB／Todoist（タスク）／一般質問ネタDB／ブログ／SNS等）へ振り分け、必要に応じてページ内のコンテンツも構造化する。

「記録モード」が新しい活動を新規記録するのに対し、「整理モード」は既にNotionに点在している当日作成ページを後追いで分類・整理するのが特徴。仕上げモード（📱付き下書き仕上げ）やコンテンツ抽出モードと組み合わせて、1日の終わりにNotionを綺麗にする用途を想定。

R1: 当日新規作成ページの全件取得

以下を並列クエリで取得する：

R1-A: notion-search による当日作成ページ取得

mcp__claude_ai_Notion__notion-search を使用：

{
  "query": "",
  "filters": {
    "created_date_range": {
      "start_date": "YYYY-MM-DD",   // 当日
      "end_date": "YYYY-MM-DD"      // 当日（同じ）
    }
  },
  "page_size": 25
}

queryが空文字で受け付けない場合は "." か " " を試す。page_sizeは25（最大）で取り、has_moreがあれば追加クエリ。

R1-B: AIミーティングノートDBの当日分取得

mcp__claude_ai_Notion__notion-query-meeting-notes を使用：

{
  "filter": {
    "operator": "and",
    "filters": [{
      "property": "created_time",
      "filter": {
        "operator": "date_is",
        "value": {"type": "exact", "value": {"type": "date", "start_date": "YYYY-MM-DD"}}
      }
    }]
  }
}

R1-C: 既振り分け済みページのフィルタリング（2026-05-01 燃費精査・改訂）

🚨 個別 notion-fetch を発射する前に、以下の安価な判定で大半をフィルタすること（過去事故：2026-04-30 仕上げモードで20件中10件を fetch → 70%が既に正DB配下と判明 = 9件分のトークン浪費）。

Step 1: search 結果の highlight と url 体系で一次判定（fetch 不要）

R1-A の notion-search 結果には各ページの highlight（本文の先頭抜粋）と url が含まれる。さらに、search の type が page でも内部の親DBは highlight や mention でほぼ推測可能：

• highlight に「2026-04-30 活動ログ」等の日次ログ参照 → 日次ルーティンログDB
• highlight に「📋市民意見受付BOX」「フォーム送信ID」等 → 市民意見受付BOX
• highlight に「session ID」「AIインタビュー」等 → AIインタビュー設定DB／市民意見受付BOX
• highlight に「[meta]」「文字数:」「投稿予定日」等 → SNS投稿管理DB
• highlight に「政策ID」「Why/What/How」等 → 🎯政策候補DB
• highlight に「ネタ名」「対象（定例会/時期）」等 → 一般質問ネタDB

Step 2: タイトル接頭辞パターンによる二次判定（fetch 不要）

タイトルの接頭辞・命名規則で親DB特定可能な代表例：

Step 3: 上記2段階で「親DB不明」と残ったページのみ notion-fetch（最大2〜3件）

3件超になる場合は、まず最も判定しにくい代表ページを2件 fetch して類推し、残りは類推結果を流用してスキップ判断。

スキップ対象（既振り分け済み）

• 親が既知DB（日次ルーティンログ／市民意見リスト／タスクDB／🗂️プロジェクトDB／ブログ記事管理DB／SNS投稿管理DB／一般質問ネタDB／🎯政策候補DB／📰ニュースDB／📅ミーティングノートDB／🏛会議体マスタDB／🗺️地区別関係性メモDB／📡AIインタビュー設定DB／📂Drive資料サマリDB／📋市民意見受付BOX）と判定されたもの
• タイトルが [重複] 〜 → masterへ統合済 などで明示的にマージ済みと宣言されているもの
• データベース自体（type=database）

例外：AIミーティングノートDB配下

AIミーティングノートDB（system collection・読取専用）配下のページは、📅ミーティングノートDBへ未登録のものを「未整理」として扱う（AI元ノートURLでの紐付けが必要）。📅DBで AI元ノートURL フィルタを当日URL一覧で照合し、未紐付けのものを抽出。

残ったページ＝整理対象として内部メモに保持：{タイトル / URL / parent種別（推測） / 一次判定根拠（highlight or 接頭辞）}

整理対象が0件の場合は「本日の新規作成ページは全て整理済みです」と伝えて終了。

R2: 各ページの分類

整理対象の各ページについて、タイトル＋（必要なら）冒頭本文から以下のいずれかに分類する：

判断基準が曖昧なページは、まずR1-CのStep 1〜2（highlight・タイトル接頭辞）で再判定し、それでも不明な場合のみ notion-fetch で本文先頭500字を取得する（1回のR2全体で最大2〜3件まで・2026-05-01 燃費精査）。それでも不明なら「❓ 不明」に振り分ける。

R3: 整理プラン提示と承認（GOサイン取得）

以下のフォーマットで一覧を提示する：

【当日新規作成ページ整理プラン】（YYYY-MM-DD・整理対象N件）

🤝 ミーティング系（●件）
  R-① [タイトル] | 推定種別: [議会公務/地域・団体/市民相談/その他/未分類] | 既存会議体マッチ: [会議体名 or なし] | URL
  R-② ...

💬 市民相談系（●件）
  R-③ [タイトル] | 推定分類: [道路/福祉/...] | URL
  ...

✅ タスク系（●件）
  R-④ [タイトル] | 推定優先度: [高/中/低] | URL
  ...

🗳️ 一般質問ネタ系（●件）
  R-⑤ [タイトル] | 推定分野: [...] | URL
  ...

📝/📣 コンテンツ系（●件）
  R-⑥ ...

🏛 会議体新規登録候補（●件）
  R-⑦ [タイトル] → 会議体マスタへ「[会議体名]」として登録案 | URL
  ...

❓ 不明・要判断（●件）
  R-⑧ [タイトル] | URL ← どの種別か教えてください

──────────
【ページ内整理オプション】
- 「本文も整理」: 該当ページの本文をMarkdown構造化（見出し・表組み・チェックボックス・ToDo整形）
- 「DB登録のみ」: 振り分け先DBにレコード作成のみ、本文は触らない（既定）

──────────
回答例：
- 「全部DB登録のみ」「全部本文も整理」
- 「R-①〜③をDB登録、R-④は本文も整理」
- 「R-⑧はミーティングに振り分けて」
- 「スキップ」（何もしない）

整理対象0件の場合は R1 で既に終了している。0件のサブセクションは省略。

R4: 整理処理の実行

ユーザーが選択した各項目について、分類に応じた処理を実行する：

R4-A: 🤝 ミーティング系 → 📅 ミーティングノートDBへ登録

1. mcp__claude_ai_Notion__notion-create-pages で 📅ミーティングノートDB（26d7848d-ad1a-4e84-806f-a8dbccb1872b）に新規レコード作成：

   • タイトル: 元タイトル（先頭の ‣ 等の余計な記号は除去）
   • date:開催日:start: 当日の日付
   • 会議種別: R2で推定した値（議会公務/地域・団体/市民相談/その他/未分類）
   • 会議体（relation）: 既存会議体マスタとマッチした場合のみ。マッチ判定は会議体名がタイトルに含まれるかで行う（コスモス祭り→コスモス三寺、JC関連→亀山JC、応援団→三重大学応援団、eスポーツ→亀山市eスポーツ協会等）
   • AI元ノートURL: 元ページURL（特にAIミーティングノートDB由来のとき必須）
   • ステータス: "開催済み"
   • 作成元: "nichijoスキル"

2. ユーザーが「本文も整理」を選んだ場合のみ：元ページの本文を構造化する：

   • mcp__claude_ai_Notion__notion-fetch で本文取得
   • Markdown構造に整形（見出し階層／表組み／チェックボックスToDo／決定事項リスト等）— 過去事例「亀山市eスポーツ協会ミーティングノート」のような整形パターンを参考
   • mcp__claude_ai_Notion__notion-update-page の replace_content で上書き（既存子ページがある場合は警告して update_content にフォールバック）

3. 既存会議体マスタにマッチしない継続体らしきページ（例：新たに登場した自治会・協会等）は、ユーザーに「会議体マスタに新規登録しますか？」と確認して、yesなら R4-G を実行

R4-B: 💬 市民相談系 → 市民意見リストDB登録

Step 2.5 と同じ処理：

• parent: data_source_id: c2c34bd8-1e16-492e-aab0-d3f497d18d4d
• 件名／分類タグ／対応状況／受付日／意見内容／担当課／次アクション／経路／匿名フラグ／（あれば）相談者・連絡先

タスクが派生する場合は R4-C も並行実行。

R4-C: ✅ タスク系 → Todoist登録（td.py add）

Step 5-A と同じ処理（🔴 登録先はTodoist・旧✅タスクDB 292cf503-... は廃止・書込禁止）：

• 登録候補を「タスク名＋登録先箱＋期限案（既定=今日+3日）＋優先度」で提示→草川承認後に python3 ~/.claude/scripts/todoist/td.py add "<タスク名>" --project <該当箱> --due <期限> [--priority 1-4]
• 複数ステップなら各ステップを独立タスクに分解（タスク名先頭に [テーマ名] プレフィクス）
• 元ページURLは --desc に参照として記載

複数ステップなら並列タスクとして登録、必ず 5-B のプロジェクト化判定（基準A〜E）を実施してA〜E該当時はプロジェクト化提案（束ね先はTodoistサブプロジェクト＋🗂プロジェクト・プラットフォーム(8975c6a9)のPJページ）。判定基準は仕上げモード S3.5 と同じく A〜E のいずれか1つ以上該当でプロジェクト化候補。

R4-D: 🗳️ 一般質問ネタ系 → 一般質問ネタDB登録

Step 3 と同じ処理：

• parent: data_source_id: 42716725-fece-497f-9782-705076539de4
• ネタ名／ネタ元／分野／優先度／状況="未整理"／メモ・根拠

R4-E: 📝/📣 ブログ・SNS素材系 → コンテンツDB登録

簡易登録（フル生成はしない）：

• ブログ → 📣 投稿管理DB（1bd98deb-...）にプラットフォーム["ブログ"]／ステータス"未着手"／ネタ元"日次活動"で登録
• SNS → SNS投稿管理DB（1bd98deb-...）にステータス"未着手"で登録
• 元ページURLを「ネタ元URL」フィールドまたは本文末尾に記載

フル生成が必要な場合は「/コンテンツ抽出 で content-pipeline 経由生成しますか？」と提案。

R4-F: 📓 日次活動ログ系 → 日次ルーティンログDB

Step 2 と同じ処理：

• 既存当日ページがあれば追記（2-B）
• なければ新規作成（2-C）

R4-G: 🏛 会議体新規登録 → 会議体マスタDB

mcp__claude_ai_Notion__notion-create-pages で 🏛会議体マスタDB（46414643-9717-404f-9572-2908c2c0a7f3）に新規レコード作成：

• 会議体名／会議種別（推定）／開催頻度（推定）／通常開催（あれば）／草川の役割（推定）／関連リンク（元ページURL）／アクティブ状態="継続中"／備考

R4-H: 🏘️ 地域関係性・自治会系 → 🏘️ 自治会別訪問管理DB

2026-05-03 大幅再設計: 「1地区=1ページ」から「1自治会=1ページ」運用へ移行。書込先を collection://520fe503-...（旧地区別関係性メモDB）から collection://996b1d15-2454-4667-9702-05d6d0faa75c（新自治会別訪問管理DB）へ変更。

地域・選挙活動の記録（市政報告会・挨拶回り・地区集会・戸別訪問・地区イベント参加）は自治会単位で蓄積する。

Step 1: 自治会名の特定

活動内容のテキストから自治会名を検出する。例:

• 「○○町自治会」「○○自治会」「○○町内会」明示あり → そのまま自治会名として使用
• 「○○町で〜」「○○地区の〜」 → 町名／地区名から自治会名を推定（曖昧な場合は町名を仮の自治会名にする）
• 自治会名が完全に判別できない場合は「<町名/地区名>(自治会未確定)」というタイトルで仮登録

Step 2: 該当自治会レコードの検索

mcp__claude_ai_Notion__notion-search で data_source_url: collection://996b1d15-2454-4667-9702-05d6d0faa75c 内を自治会名でクエリ。

Step 3-A: 既存レコードがある場合（推奨ルート）

mcp__claude_ai_Notion__notion-update-page の update_content コマンドで該当ページに追記:

戸別訪問の場合（最重要・2026-05-04運用追加）

1. プロパティ加算更新: 訪問完了日（最新日付）／訪問済軒数（既存値+今回値）／在宅対面・在宅拒否・不在投函・後援会入会 を加算（fetch→加算→update）
2. ページ本文「## 📅 訪問ログ」セクションに時系列追記:

   - YYYY-MM-DD: <n>軒（在宅<m>人/不在<k>人）— <短いメモ・特記>

   セクション内の「(まだ訪問記録がありません)」プレースホルダーを置換／不在の場合は新規セクション追加

市政報告会の場合

• 自治会DB側: 「市政報告会開催済」=true、「市政報告会日」=YYYY-MM-DD、「市政報告会メモ」に内容追記
• 🎤市政報告会DB側: R4-H2 の手順に従い1開催1レコード作成

挨拶回り・地区集会の場合

• 「直近の場での発言」フィールド or ページ本文の「## 🤝 関係性メモ」内「### 直近の場での発言」セクションに YYYY-MM-DD: <イベント名> - <主な内容> 形式で追記
• 草川が約束した内容があれば「過去の約束」フィールド or 同セクションの「### 過去の約束」に追記

共通

• 主要連絡先・自治会長・副会長・キーパーソン情報の更新があれば「## 👥 主要メンバー」セクションを更新

Step 3-B: 既存レコードが無い場合（新規作成）

mcp__claude_ai_Notion__notion-create-pages で新規作成:

• parent: data_source_id: 996b1d15-2454-4667-9702-05d6d0faa75c
• 自治会名（title）
• 地区（select：亀山地区/関地区/井田川地区/川崎地区/昼生地区/神辺地区/白川地区/野登地区/加太地区/南部 のいずれか）
• 関係性温度（select：強支持/支持/中立/要注意/未評価。デフォルト「未評価」）
• 主要課題（multi_select：通学路/公共交通/水道/防災/空き家/高齢化/子育て/道路/農業/その他）
• 自治会長（text・判明していれば）
• 直近の場での発言（今回のイベント記録）
• 戸別訪問なら：訪問完了日／訪問済軒数等を初期値で入力
• 市政報告会なら：市政報告会開催済=true／市政報告会日／市政報告会メモ

注意:

• 旧「🗺️地区別関係性メモDB」(520fe503-) と「📊9地区進捗DB」(1d9e870c-) は 2026-05-03 に廃止アーカイブ化済。新規書き込み禁止
• 旧「地域別活動DB」(3d08102d-) も 2026-05-02 に廃止アーカイブ化済

R4-H2: 🎤 市政報告会の場合（追加書込・2026-05-04新設）

活動が市政報告会（明示的に「市政報告会」「報告会」「タウンミーティング」キーワードが含まれる、または直前に開催案内チラシ配布が記録されている）の場合、R4-H の自治会DB書込に加えて 🎤 市政報告会DB（collection://df08b5ea-f5ff-4022-afe2-c8073fbe341a）に1レコード作成する。

Step 1: 市政報告会DBへ新規レコード作成（プロパティ＋運営計画テンプレ）

mcp__claude_ai_Notion__notion-create-pages で:

• parent: data_source_id: df08b5ea-f5ff-4022-afe2-c8073fbe341a
• タイトル: <開催地区/自治会> 市政報告会 <YYYY-MM-DD> 例「みずきが丘市政報告会 2026-05-16」
• 開催日: YYYY-MM-DD
• 開催地区: select（22地区＋複数地区合同＋市外）
• 開催自治会: relation（R4-H で更新したJKレコードのpage_idを紐付け）
• 形態: select（自治会単位/複数自治会合同/地区全体/オンライン主/ハイブリッド/街頭ミニ。デフォルト「自治会単位」）
• 会場: text（記録テキストから抽出）
• 参加者数: number（「参加〇人」「来場〇人」から抽出）
• 質問件数: number（「質問〇件」から抽出）
• 主な意見・要望: text（記録の意見/要望抜粋）
• 議会で取り上げる課題: text（草川判断で議会対応する案件）
• 進捗ステータス: status（未着手/進行中/完了 のいずれか。記録時点では「完了」、案内中・準備中は「進行中」、計画段階は「未着手」）
• 配布チラシ: text（チラシ名/版数を記録）
• 動画URL/写真URL: 記録テキストにURLがあれば
• メモ: 補足

ページ本文（content）に標準運営計画テンプレを展開（2026-05-04追加）

新規レコード作成時、ページ本文に以下のテンプレを生成。既知情報は埋め、不明箇所は「（調査中）」「（追記待ち）」プレースホルダー:

## 🎯 プロジェクト趣旨

<開催地区/自治会の特徴・有権者数・投票率・なぜここで開催するかの戦略的理由>

## 👥 ターゲット解像度

- 世帯像: <共働き/高齢/子育て等>
- 動ける時間: <平日夜/土日昼等>
- デバイス: <スマホ8割/PC等>
- 顔出し: <抵抗あり/問題なし>
- 帰属意識: <高/中/低>
- 信頼形成: 単発か継続かの方針

## 🏗️ 開催設計（3層）

### 第1層: メイン開催
- 頻度・時間・場所・プラットフォーム

### 第2層: 継続接点（あれば）

### 第3層: 常設接点（あれば、LINE/SNSグループ等）

## ⏱️ タイムライン

<HH:MM-HH:MM ___> を時系列で

## 🎤 オープニング・進行原稿

> 「（オープニングセリフ）」

## 🎯 KPI

- 参加者: ___名
- 質問件数: ___件
- LINE/SNS新規登録: ___名
- 議会で取り上げる課題確定: ___件
- 次回参加意向: ___%

## 📣 集客動線

1. 後援会員個別連絡
2. SNS拡散
3. ポスティング
4. 地域メディア（PTA/まちづくり協議会等）

## 📄 配布資料

1. 市政報告レポート
2. 質問記入用紙＋連絡先カード

## ⚖️ 公選法遵守

- タイトルに「選挙」「投票」を入れない
- 「投票してください」「次の選挙では」表現禁止
- 公的施設使用は政党色を出さない
- 参加者の顔・声写り込みを冒頭で告知・同意取得、子どもはモザイク処理

## 📝 議事録・参加者の声

（開催後追記）

## 🎬 関連メディア

- 動画URL:
- 写真URL:
- アーカイブ:

既存レコード（みずきが丘5/16・安知本5/31）はリファレンスとして参照し、開催地区・自治会の特性に応じて内容をカスタマイズ。

Step 2: 自治会DBの「市政報告会開催済」フラグも更新

R4-H Step 3-A の「市政報告会の場合」処理に従い、自治会レコードの:

• 市政報告会開催済 = true
• 市政報告会日 = YYYY-MM-DD（最新開催）
• 市政報告会メモ = 内容追記

を併せて実行する（自治会DB側は累積管理、市政報告会DB側は1開催1レコード）。

例:

「記録: 5/16 みずきが丘自治会で市政報告会 参加18人 質問8件 主な意見=通学路の安全、水道濁り改善要望」

→ 市政報告会DBに新規レコード作成:

• タイトル「みずきが丘市政報告会 2026-05-16」/ 開催日 2026-05-16 / 開催地区 井田川地区北 / 参加者数 18 / 質問件数 8 / 主な意見・要望「通学路の安全、水道濁り改善要望」/ 進捗ステータス 完了
  → かつ自治会DBのみずきが丘レコード:
• 市政報告会開催済=true / 市政報告会日 2026-05-16 / 市政報告会メモに追記

R4-I: ❓ 不明・要判断

ユーザーが分類を指定するまで保留。指定されたら該当の R4-A〜H に流す。

共通の元ページ処理

各DB登録後、元ページは原則そのまま残す（移動しない＝リンク切れ回避）。元ページにDB登録レコードへのリンクを追記するかは、「本文も整理」モードで上書き整形時に併せて行う。

R5: サマリー出力

全選択項目処理後：

✅ 当日新規ページ整理完了（YYYY-MM-DD）

🤝 ミーティング → 📅DB登録: ●件
  - [タイトル] [📅DBレコードURL] (会議体: [マッチ会議体 or なし])
  ...
🏛 会議体マスタ新規登録: ●件
  - [会議体名] [マスタURL]
💬 市民意見リスト登録: ●件
  - [件名] [URL]
✅ タスク登録: ●件
  - [タスク名] [優先度]
🗳️ 一般質問ネタ登録: ●件
  - [ネタ名] [URL]
📝/📣 コンテンツ素材登録: ●件
📓 日次ログ追記/作成: ●件
🌍 地域活動登録: ●件
❓ 未判断保留: ●件（次回手動で振り分けてください）

📄 ページ内整理（本文整形）: ●件
  - [タイトル] [URL]

⚠️ 元ページは保持。重複登録を避けたい場合は元ページに「📅DB登録済み」等のメモを追記推奨。

該当0件のセクションは省略する。

整理モードの注意事項

• 元ページは移動しない：会議ハブ等への移動は行わず、元の場所に保持してリンク切れを防ぐ。代わりに振り分け先DBレコードへrelation／URL参照で紐付け
• 重複登録の回避：📅DBへ既登録のAIミーティングノートは AI元ノートURL で照合してスキップ
• 会議体マスタの自動マッチ：以下4件は既登録のマッチ対象として自動振り分け：
  • コスモス祭り／コスモス畑 → コスモス三寺
  • JC関連／青年会議所／三重ブロック／会員会議所 → 亀山JC
  • 応援団（三重大学応援団・野球応援団） → 三重大学応援団
  • eスポーツ → 亀山市eスポーツ協会
• 市民相談の個人情報秘匿：氏名・連絡先は市民意見リストDBにのみ記録。Todoistタスクには個人情報を書かず、--desc に市民意見リストページURLの参照のみ記載
• 本文整形は明示選択時のみ：「本文も整理」を選んでいない項目はDB登録のみで本文は触らない（誤って既存メモを破壊しない）
• 未分類フォールバック：会議種別が判定できない場合は📅DBに「未分類」種別で登録 → 後日棚卸し
• 0件処理時の終了：整理対象0件なら即座に「整理済み」と伝えて終了（不要な確認ループを避ける）

統合仕上げモード（「仕上げ」単独トリガー）

ユーザーが「仕上げ」「仕上げて」「仕上げお願い」等と発言した場合、仕上げモード（S1〜S4）／コンテンツ抽出モード（C1〜C6）／整理モード（R1〜R5）／タスク進捗レビューモード（T1〜T4）の4系統を統合実行する。確認なし即時起動。

ロジックは以下の流れで4モードを並行進行させ、ユーザーには1回の選択UIで済むようにする。

U1: 並列スキャン（S1 ＋ C1 ＋ R1 ＋ T1 同時）

以下を並列で実行する：

• S1（モバイル下書き検出）: 一般質問ネタDB／SNS投稿管理DB／ブログ記事管理DBの📱付き下書き専用ビューを notion-query-database-view で並列クエリ
• C1（当日情報横断スキャン）: 日次ルーティンログ／📅 Google Calendar（当日／kusakawa.taku@gmail.com のみ）／市民意見リスト／一般質問ネタDB（直近1週間）／ニュースDB／🤝ミーティングノート（当日分）／政策候補DB／Todoist当日close分（td.py）を並列取得
• R1（当日新規作成ページ取得）: notion-search で created_date_range = 当日のページを全取得＋AIミーティングノートDB当日分取得＋既知DB配下のものをフィルタリング除外
• T1（タスク進捗レビュー対象取得）: 🔴Todoist（python3 ~/.claude/scripts/todoist/td.py overdue ／ today ／ nodue）で取得。Notion✅タスクDB(292cf503)は廃止・書込禁止（過去データ参照のみ）：
  • T1-a 期限到達／超過分: td.py overdue（期限超過）＋td.py today（本日期限）
  • T1-b 期限なし放置分: td.py nodue（期限なし＝inbox的。作成日が取れる場合は30日超を優先表示、取れなければ全件を対象に草川判断）
  • td.py はBash 1回にまとめて実行（overdue && today && nodue）。出力は簡潔形式（タスク名／期限／ラベル／〔箱名〕）で、これ以上のプロパティは取らない（軽量化）
  • 過去事故防止: ohayo は期限なしタスクを構造的に拾えない盲点（feedback_ohayo_deadline_null_blindspot）があったため、T1-b で必ず期限なし分を捕捉する

4系統の結果を内部メモに格納する。重複ハンドリング：

• 一般質問ネタDBの結果はS1とC1で重複し得るので、📱付きはPart A、📱無しはPart Bとして振り分ける
• AIミーティングノートDBの当日分はC1（情報源としての利用）とR1（整理対象としての登録）両方で出るが、Part Cでは📅DB未登録のもののみ整理対象とし、Part Bでは情報源として参照（重複登録は防ぐ）
• 既にPart A／Bで処理対象となっているページは Part C の整理対象から除外
• T1 は他Partと独立スコープ（Todoistのみ）なので重複ハンドリング不要

🚨 R1 整理対象の親DB判定は R1-C 改訂版（2026-05-01）に従う：

• search の highlight・タイトル接頭辞・url体系で一次判定 → 大半は fetch 不要で振り分け先確定
• 個別 notion-fetch は本当に親DB不明なものに限り最大2〜3件まで
• 過去事故：2026-04-30 仕上げモードで20件中10件をfetch → 9件分のトークン浪費

T2: 推奨スタンス算定ロジック（T1取得後、内部処理）

T1で取得した各タスクに対して以下のロジックで推奨スタンスを算定する：

プロジェクト箱の紐付け表示: 📦退避・削除候補のタスクがInbox以外のTodoistプロジェクト箱に属する場合は、表示時に「⚠️PJ紐付け〔箱名〕」マークを付ける（草川が個別判断できるよう。td.py出力の〔箱名〕で判定）。

U2: 統合一覧の提示（GOサイン取得）

以下のフォーマットで一括提示する：

【仕上げ対象一覧】（YYYY-MM-DD）

■ Part A: モバイル下書き（📱付き・上書き仕上げ対象）
  A-① 📱 [ネタ名] | 🗳️一般質問ネタ | [登録日]
  A-② 📱 [タイトル] | 📣SNS | [登録日]
  A-③ 📱 [タイトル] | 📝ブログ | [登録日]
  ...

■ Part B: 今日のコンテンツ素材候補（情報源スキャンから新規抽出）
  B-① [テーマ名]
       ソース: [📓/💬/🗳️/📰/🎯/✅] | 媒体: [ブログ/SNS/両方] | 角度: [角度] | 優先度: [高/中/低]
       要旨: [1〜2文]
       ⚠️ [注意点があれば]
  B-② ...

■ Part C: 当日新規作成ページの整理対象（DB未振り分けのもの）
  🤝 ミーティング系 ●件
    C-① [タイトル] | 推定種別: [議会公務/地域・団体/...] | 既存会議体マッチ: [〇〇 or なし] | URL
    C-② ...
  💬 市民相談系 ●件
    C-③ [タイトル] | 推定分類: [...] | URL
  ✅ タスク系 ●件
    C-④ ...
  🗳️ 一般質問ネタ系 ●件
    C-⑤ ...
  📝/📣 コンテンツ素材系 ●件
    C-⑥ ...
  🏛 会議体新規登録候補 ●件
    C-⑦ [タイトル] → [会議体名]として登録案 | URL
  📓 日次ログ・🌍 地域活動・❓ 不明: それぞれ●件

■ Part T: タスク進捗レビュー（超過＋本日＋期限なし・Todoist）
  ⚠️ 超過15日以上 ●件（退避推奨）
    T-① [タスク名] | 期限: YYYY-MM-DD（●日超過） | 〔箱名〕@ラベル | 推奨: 📦退避（Done確認/@保留/削除候補） | id
  ⏰ 超過4〜14日 ●件（延期 or 退避検討）
    T-② [タスク名] | 期限: YYYY-MM-DD（●日超過） | 〔箱名〕 | 推奨: ⏰+3日延期 → YYYY-MM-DD | id
  ⏰ 超過1〜3日 ●件（+3日延期推奨）
    T-③ [タスク名] | 期限: YYYY-MM-DD（●日超過） | 〔箱名〕 | 推奨: ⏰+3日延期 → YYYY-MM-DD | id
  ✅ @結果待ち×超過 ●件（Done化確認 or 再連絡推奨）
    T-④ [タスク名] | 期限: YYYY-MM-DD（●日超過） | 〔箱名〕@結果待ち | 推奨: ✅Done化確認 or 再連絡 | id
  📅 本日期限 ●件（継続）
    T-⑤ [タスク名] | 期限: 今日 | 〔箱名〕 | 推奨: 🔄継続 | id
  🕰️ 期限なし放置 ●件（期限設定 or 退避推奨）
    T-⑥ [タスク名] | 期限: なし | 〔箱名〕 | 推奨: 期限設定（今日+3日）or 📦退避 | id

  ※ ⚠️PJ紐付け〔箱名〕マークが付いた退避推奨は、箱の残タスク（`td.py list <箱名>`）を確認してから判定

──────────
どれを処理しますか？

回答例：
- 「全部」「A全部」「B全部」「C全部」「T全部推奨通り」
- 「A-①、A-③、B-②を両方、C-④はDB登録のみ」
- 「Aは全部、Bは優先度高だけ、Cは全部DB登録のみ、Tは推奨通り」
- 「Cの🤝ミーティング系は本文も整理」「C-①〜③本文も整理」
- 「T-①Done、T-③+3日延期、T-⑥は@保留に退避」「Tだけ全部」「Tスキップ」
- 「スキップ」（何もしない）

4Partとも0件の場合は「本日は仕上げ対象がありません（モバイル下書き0件・コンテンツ素材0件・整理対象0件・タスクレビュー対象0件）」と伝えて終了。

0件のPartは見出しごと省略し、残ったPartだけ提示する（選択肢の文言を調整）。

U3: 選択ごとの処理振り分け

ユーザーが選んだ項目を Part に応じて振り分けて処理する：

T項目（タスク進捗レビュー）

• 各タスクに対して、ユーザー指定の処理（推奨通り or 個別指定）を Todoist に一括適用：
  • ✅Done化: td.py done <task_id>
  • ⏰延期 +N日／期限設定: Todoist MCP reschedule-tasks（td.pyに期限変更cmdは無い。MCP不可時はAPI /api/v1/ 直叩き。デフォルトN=3、feedback_task_deadline_3days準拠）
  • 📦退避: @保留／@アイデア ラベル付与（Todoist MCP update-tasks）。削除（td.py rm）は草川が明示的に「削除」と指定した場合のみ
  • 🔄継続: 何もしない
• 注意: Todoistにステータス概念はない（旧inbox/Wish List/進行中/Archiveは期限＋ラベルで読み替え）。旧Notion✅タスクDBへの書込は禁止
• バッチ承認の解釈:
  • 「T全部推奨通り」→ 表の「推奨」列をそのまま全件適用
  • 「T-①Done、T-③+3日延期、T-⑥は@保留に退避」→ 指定分だけ個別処理、他は推奨通り適用
  • 「Tだけスキップ」→ 何もしない
  • 曖昧な場合はその件だけ草川に確認、他は推奨通り適用
• プロジェクト連動チェック: 退避・削除するタスクがInbox以外の箱に属する場合、サマリー出力時に「〔箱名〕の残タスク数が変わりました」と1行通知（プロジェクト本体は触らない）

A項目（モバイル下書き仕上げ）

• 種別ごとに S3-A／S3-B／S3-C を実行（policy-researcher＋kameyama-researcher並列調査→上書き仕上げ）
• 仕上げ後 S3.5（タスク抽出・確認あり） を実行

B項目（コンテンツ素材から新規生成）

• C4（媒体・モード確認） をPart Bの選択分について実行（C3で媒体・モード未指定の場合のみ。指定済みならスキップ）
• C5（content-pipeline 委任） で生成・Notion保存

C項目（当日新規ページ整理）

• 分類ごとに R4-A〜R4-I を実行（📅DB登録／市民意見／タスク／質問ネタ／コンテンツ／会議体マスタ／日次／地域活動／不明）
• 「本文も整理」が指定された項目のみ、元ページの本文をMarkdown構造化（過去事例「亀山市eスポーツ協会ミーティングノート」整形パターン参考）

処理順序

• T項目→C項目→A項目→B項目の順で処理
  • T項目: 最軽量（プロパティ更新のみ、本文生成なし）。先にタスクの視界をクリアにする
  • C項目: 軽量・確認少（DB登録のみが多数）。次にNotionの状態を綺麗に
  • A項目: 既存ページ上書きで中重量
  • B項目: policy/kameyama-researcher＋content-pipeline で最も重い
• 合計5件を超える場合は「処理に時間がかかるため分割しますか？」と確認（T/CはDB登録/プロパティ更新のみのため軽量で別カウント可）

U4: 統合サマリー出力

全処理完了後：

✅ 仕上げ完了（YYYY-MM-DD）

■ Part A: モバイル下書き仕上げ
  🗳️ 一般質問ネタ: ●件
    - [ネタ名] [URL]
  📣 SNS投稿: ●件
    - [投稿タイトル] [URL]
  📝 ブログ記事: ●件
    - [記事タイトル]（[深掘り/ノーマル]） [URL]
  ✅ タスク登録: ●件（S3.5から）
    - [タスク名] [優先度]

■ Part B: 新規コンテンツ生成
  📝 ブログ: ●件
    - [テーマ名]（[深掘り/ノーマル]） [URL]
  📣 SNS: ●件
    - [テーマ名] [URL]
  🌱 元ソース内訳: 📓●/💬●/🗳️●/📰●/🤝●/🎯●/✅●

■ Part C: 当日新規ページ整理
  🤝 ミーティング → 📅DB登録: ●件（うち本文整形●件）
    - [タイトル] [📅DBレコードURL]（会議体: [マッチ or なし]）
  🏛 会議体マスタ新規登録: ●件
    - [会議体名] [マスタURL]
  💬 市民意見リスト: ●件
  ✅ タスク: ●件
  🗳️ 一般質問ネタ: ●件
  📝/📣 コンテンツ素材: ●件
  📓 日次ログ追記: ●件
  🌍 地域活動: ●件
  ❓ 未判断保留: ●件

■ Part T: タスク進捗レビュー（Todoist）
  ✅ Done化: ●件
    - [タスク名]
  ⏰ 延期・期限設定: ●件（平均+●日）
    - [タスク名] 旧期限YYYY-MM-DD → 新期限YYYY-MM-DD
  📦 退避（@保留/@アイデア）: ●件（削除は明示指定分のみ ●件）
    - [タスク名]
  🔄 そのまま継続: ●件
  📊 処理後の残在庫（`td.py audit`）: 期限超過 ●件 / 期限なし ●件 / @結果待ち ●件 / @保留 ●件
  🗂️ 影響プロジェクト箱: ●件（タスク残数変更）
    - 〔箱名〕残タスク▲●件

⚠️ A項目の元下書き本文は上書き済み（Notion 版履歴から復元可能）
⚠️ C項目の元ページは保持。重複登録回避のため「📅DB登録済み」等のメモ追記推奨

該当0件のサブセクションは省略する。

U5: 当日活動ログへの自動追記（必須・確認不要）

U4 統合サマリー出力後に、本日の4系統仕上げ作業を当日 YYYY-MM-DD 活動ログ（日次ルーティンログDB f6d15ac0-73fa-414f-8242-03e8f06aa4e3）へ自動追記する。確認は不要・自動実行。

処理フロー

1. mcp__claude_ai_Notion__notion-search で当日タイトル YYYY-MM-DD 活動ログ を日次ログDB内検索
2. 既存ページがある場合: notion-update-page の update_content で末尾に追記
3. 存在しない場合: 2-C と同じ手順で新規作成し、本セクションを最初の本文として配置

追記内容（テンプレート）

---

### 追記 [統合仕上げモード / Part A・B・C・T]

「仕上げ」単独トリガーで統合仕上げモードを実行。Part A（モバイル下書き仕上げ）・Part B（コンテンツ抽出→生成）・Part C（当日新規ページ整理）・Part T（タスク進捗レビュー）の4系統を統合実行。

#### Part A: モバイル下書き仕上げ
- 🗳️ 一般質問ネタ: [件数]件 / 📣 SNS: [件数]件 / 📝 ブログ: [件数]件
  - [ネタ名 or タイトル] → [URL]
- ✅ S3.5 派生タスク: [件数]件
（0件のPart A は本セクション省略）

#### Part B: 新規コンテンツ生成
- 元ソース内訳: 📓●/💬●/🗳️●/📰●/🤝●/🎯●/✅●
- 📝 ブログ: [件数]件
  - [テーマ名]（[深掘り/ノーマル]） → [URL]
- 📣 SNS: [件数]件
  - [テーマ名] → [URL]
（0件のPart B は本セクション省略）

#### Part C: 当日新規ページ整理
- 🤝 ミーティング → 📅DB登録: ●件（うち本文整形●件）
- 🏛 会議体マスタ新規登録: ●件
- 💬 市民意見/✅タスク/🗳️質問ネタ/📝SNS素材/📓日次/🌍地域/❓不明: それぞれ●件
  - 主要登録項目があれば [タイトル] → [URL] で列挙
（0件のPart C は本セクション省略）

#### Part T: タスク進捗レビュー（Todoist）
- 対象: 超過●件 + 本日●件 + 期限なし●件
- ✅ Done化: ●件 / ⏰ 延期・期限設定: ●件（平均+●日）/ 📦 退避: ●件 / 🔄 継続: ●件
- 主要処理: [タスク名] → [処理内容]
- 処理後の残在庫（`td.py audit`）: 期限超過 ●件 / 期限なし ●件 / @結果待ち ●件 / @保留 ●件
- 影響プロジェクト箱: 〔箱名〕残タスク変更
（0件のPart T は本セクション省略）

#### 重要な軌道修正・学び（最重要セクション）
- Part A/B 生成過程で発覚した**事実誤認の修正**は必ず記録
- policy-researcher/kameyama-researcher が示した**重要発見**（PDF実物確認による前提修正等）
- 草川議員の**過去発言との連続性として記事に織り込んだ事実**（産業建設委員会提言・過去定例会答弁等）
- voice-dna整合の見直し点・新たに気づいた声のDNA要素
- なければ本セクション省略可だが、Part B 生成時は基本的に何かしらの学びがあるはず

#### 議会で問う論点（Part B 記事内で明示したもの）
- 主要論点があれば箇条書きで記録
- 後日の振り返り・週次レポート（oyasumi金曜）・voice-dna整合性チェック用

⚠️ A項目の元下書き本文は上書き済み（Notion 版履歴から復元可能）
⚠️ C項目の元ページは保持
⚠️ T項目の更新はTodoist側のみ（done／期限／ラベル）。Notionは触らない

追記成功後、U4サマリー末尾に「📓 日次ログ追記: [当日活動ログURL]」を1行追加する。

なぜこのステップが必要か（背景）

2026-04-29仕上げで、太陽光条例案の検証ブログ＋SNSを生成し、当初前提「届出制」→PDF実物確認後「許可制」への重要な軌道修正を行ったが、これらが当日活動ログに自動反映されず、ユーザー指摘で初めて気づく事故が発生。日次ログは1日の活動の起点・統合ビューであり、生成コンテンツへのリンクや軌道修正の学びが残らないと、後日の振り返り・週次レポート（oyasumi金曜）・voice-dna整合性チェックが弱くなる。**仕上げモードU4の終わりは「日次ログ追記まで含めて完了」**と定義し直す（2026-05-28: Part T も追記対象に含める）。

統合仕上げモードの注意事項

• 「仕上げ」単独発言時の既定動作は4系統統合実行（確認なし）。単独実行したい場合だけ「モバイル下書きだけ仕上げ」「今日のコンテンツ抽出だけ」「整理だけ」「タスク進捗レビューだけ」と明示してもらう
• 市民相談の個人情報秘匿・iJAMP原文転載禁止（要約反映は可）・公選法配慮・GOサイン必須・ブログ冒頭の定型挨拶・禁止用語回避は4Partで共通適用
• 一般質問ネタDBで📱付き（A）と📱無し直近（B）が併存する場合、同じネタが両Partに重複しないようU1の振り分け時に重複排除する（📱付き優先＝Aに寄せる）
• AIミーティングノートDB当日分は📅DB未登録のものをCに振り分け、Bでは情報源としてのみ参照（重複登録回避）
• 5件超過時は分割実行（T→C→A→Bの順で先に処理し、後段は「続きを処理しますか？」と確認）。T/CはDB登録/プロパティ更新のみのため軽量で別カウント可
• 並列スキャンU1で1系統がエラーになった場合、残り3系統だけで進める（エラー発生は最終サマリー直前に1行報告）
• Part T はあくまで「節目の進捗確認」。task-audit スキル（6軸完全監査・PJ化候補抽出）の置き換えではない。期限なし・停滞・長期@結果待ち・PJ化判定が溜まった時は task-audit を別途起動（feedback_ohayo_task_audit_signal の閾値超過時）
• Part T で全件処理する設計ではない。草川が見て即判定できる案件だけ「推奨通り」で流し、判断つかないものは「継続」のままにして翌日以降に持ち越し可

📌 DB統一override（2026-07-05・本文の旧記述より優先）

• 🎯政策候補DB（ds 6f1895ac- / page b9f8d42a）は凍結済み・新規書込禁止。🗄️旧アーカイブ内に参照専用で保管（過去分の参照・引用はOK）。
• 政策ネタ・一般質問ネタの登録/更新はすべて「🎯政策・質問ネタDB（統一パイプライン）」1本：data_source 42716725-fece-497f-9782-705076539de4 / page cb47d25e30b14b61b39f56254bf9432a（🎯政策・質問ハブ=34bcf503-819e配下）。
• 統一DBの使い方：状況=収集→未整理→調査中→質問案→提出/通告→実施→完了／時間軸=議会直近（3か月以内の議会論点）・中長期（旧政策候補相当）・観察／ネタ元に「市政報告会・政策スキャン・AIインタビュー・地域訪問」追加済み。
• 本文中の「政策候補DBへ保存」は「統一DBに時間軸=中長期で保存」と読み替える。凍結DBの案件を再開する時は、その1件だけ統一DBへ昇格させる。

📌 Step 2.7: 人名・地域検知→👥後援会員DBへの追記提案（2026-07-05新設・承認制）

記録モードの活動内容に個人名（フルネーム／姓＋さん・会長・氏等）が含まれる場合、Step 2.6（自治会DB追記）に加えて必ず実行する：

1. 検知: 人名＋文脈（地区・自治会・出来事・約束・入会意向）を抽出。除外＝他議員・市職員・公人・家族・敬称のない一般名詞。
2. 照合: 👥後援会員DB（data_source 04cc3a1c-f59a-409d-8406-ff4de19eea45）を氏名で検索（notion-search + data_source_url）。
3. 提案（1回にまとめて提示）:
   • 既存会員に一致 → 接触履歴に「YYYY-MM-DD: 出来事」追記＋最終接触日更新＋（地区/自治会が判明していれば補完）の案を提示
   • 未登録 → 新規レコード案（氏名・地区・自治会relation・関係性=「市政報告会で出会う/戸別訪問・街頭で出会う/イベント・行事で出会う」等の出会いの場・区分=関係者・接触履歴初回行）を提示
4. 保存: 草川の承認（yes/番号指定）を得てから一括保存。個人情報のため承認なしの自動保存は禁止。曖昧な同姓は必ず確認。
5. サマリー末尾に「👥後援会員DB: [氏名] - [追記/新規] - URL」を記載し、🔖台帳1行にも含める。

📌 報告会の声の締め工程 追加ルール（2026-07-05・冒頭「最優先モード」に追加）

• 手順2（🎤報告会DB「主な意見・要望」追記）の後に、各声を📝市民意見リスト（c2c34bd8）にも1声1レコード登録する（件名=「【〇〇報告会】声の要旨」・経路/出所=市政報告会・個人名は本人了解が無い限り伏せる）。
• 報告会のAIミーティングノート（議事録）がある場合は、議事録本文からも市民の声を抽出して同様に登録（重複チェック：既存意見リスト・統一ネタDB）。
• 一般質問ネタ化候補は🎯政策・質問ネタDB（統一・42716725）へ「ネタ元=市政報告会」で登録提案。

📌 Step 2.6 実行担保（2026-07-05修理・重要）

検証の結果、2026-05-14以降 Step 2.6（🏘️自治会別訪問管理DBへの自動追記）が実行されていなかった（城東=7/4報告会未反映・太岡寺=6/25未反映）。再発防止として：

1. 記録モードで地名・自治会名・地区名を検出したら、Step 2.6 を省略禁止の必須工程として実行する（「該当なし」と判断した場合もサマリーに「🏘️自治会DB: 該当地区なし」と明示的に1行残す）。
2. 市政報告会の記録（最優先モード）では、🎤報告会DB更新に加えて必ず該当自治会レコードの 市政報告会開催済✔・市政報告会日・市政報告会メモ・直近の場での発言 を更新する。
3. サマリー末尾の「🏘️自治会別訪問管理DB追記: …」行が無い記録は未完了とみなす（自己チェック）。
4. 5/14〜7/5の間に実施済みの報告会（御幸5/30・小下5/31・木下6/13・太岡寺6/25・安知本6/27・城東7/4）の自治会DB反映漏れは、次回「整理」モード実行時にまとめてバックフィルを提案する。