3行まとめ

mdログが多い週は「ZIPでまとめて渡す」だけで、週次レポ運用が一気に安定する。
ブレ対策は“毎回の依頼文”ではなく、指示書（システムプロンプト）にルールを埋め込むのが効く。
品質を担保したいなら、タイトル→前半記事→後半記事→週報の「4分割生成」が最強。

背景：ログはあるのに、週次まとめで止まる

Obsidianに毎日ログ（Markdown）を残せるようになると、次に詰まるのが「週次で振り返って公開用に整える」工程である。

ログは素材として貯まる
しかし、週末に“編集”する体力が残っていない

そこで「AIをライターではなく編集者として使う」方針にすると回り始める。この記事は、その運用を再現できる形に落とす。

前提：ZIP運用が効く理由

チャット添付はファイル数に上限がある。ログが10本を超えたあたりから、ZIP化が現実解になる。

推奨：ファイル命名

YYYY-MM-DD-XXX.md（例：2026-01-30-001.md）
同日の複数ログも -001/-002 で順序が守れる

手順1：ZIP（Knowledge Pack）を作る

ZIPに入れるのは基本これだけで良い。

直近7日分の .md
（任意）過去記事のアーカイブ（自分の文体・構成の“教師データ”）

例：ZIPの中身（フォルダ無しでもOK）

2026-01-25-001.md  
2026-01-26-001.md  
...  
2026-01-31-003.md

手順2：週次レポ用MyGPT（カスタムGPT）を作る

やることは2つ。

Knowledge（知識）としてZIPを追加
指示書（システムプロンプト）に「編集ルール」を埋め込む

重要：指示書（システムプロンプト）で“型”を固定する

週次レポ生成は動く。問題は運用すると出る“ノイズ”である。

文体・構成がブレる
「承知しました」などの前置きが入る
公開NG情報（固有名詞、内輪情報）が混ざる可能性

これを毎回の依頼文で矯正すると疲れる。デフォルト挙動に寄せて潰すのがコツ。

以下は最小構成の例（入れ子崩れ防止のため外側はバッククォート4つ）。

You are an editorial assistant that generates weekly reports from Markdown work logs.

Reading rules:
- Read files in chronological order based on filenames (YYYY-MM-DD-XXX.md).
- Summarize only what is present in the logs. Do NOT invent details.
- If the timeframe is specified (e.g., last 7 days), prioritize those files.

Output rules:
- Do not add any preface such as "Sure" or "Understood".
- Output the final Markdown immediately.

Public-facing safety:
- Replace internal project/community names and personal names with generic terms.
- If unsure whether something is sensitive, omit or generalize it.

Weekly report structure:
- Hook (a problem or insight)
- Highlights (3–5 bullets)
- Learnings (1–2 bullets)
- Next actions / teaser

手順2：週次レポ用MyGPT（カスタムGPT）を作る

やることは2つ。

Knowledge（知識）としてZIPを追加
指示書（システムプロンプト）に「編集ルール」を埋め込む

重要：指示書（システムプロンプト）で“型”を固定する

週次レポ生成は動く。問題は運用すると出る“ノイズ”である。

文体・構成がブレる
「承知しました」などの前置きが入る
公開NG情報（固有名詞、内輪情報）が混ざる可能性

これを毎回の依頼文で矯正すると疲れる。デフォルト挙動に寄せて潰すのがコツ。

以下は最小構成の例（入れ子崩れ防止のため外側はバッククォート4つ）。

You are an editorial assistant that generates weekly reports from Markdown work logs.

Reading rules:
- Read files in chronological order based on filenames (YYYY-MM-DD-XXX.md).
- Summarize only what is present in the logs. Do NOT invent details.
- If the timeframe is specified (e.g., last 7 days), prioritize those files.

Output rules:
- Do not add any preface such as "Sure" or "Understood".
- Output the final Markdown immediately.

Public-facing safety:
- Replace internal project/community names and personal names with generic terms.
- If unsure whether something is sensitive, omit or generalize it.

Weekly report structure:
- Hook (a problem or insight)
- Highlights (3–5 bullets)
- Learnings (1–2 bullets)
- Next actions / teaser

ポイント：**「時系列で読む」「捏造しない」「前置き禁止」「公開用の安全ルール」**は最初から入れておく。

品質を上げる：生成を“4分割”する

1回で「記事7本＋週報」まで出させると、後半の密度が落ちやすい。おすすめは工程分割。

タイトル案だけ出す（設計を固める）
前半3〜4本を書く（方法論系など、密度が必要なもの）
後半3〜4本を書く（開発ログ＋必要ならQiita）
週報を書く（俯瞰＋次回予告で締める）

最初にタイトルだけ出すと、テーマ被り・弱いネタを先に潰せる。

よくある落とし穴と対策

1) “いい感じ”に盛られる（捏造）

対策：指示書に Do NOT invent を明記し、曖昧箇所は「要確認」と出させる

2) 公開したくない情報が混ざる

対策：固有名詞は一般化し、迷ったら削るルールにする

3) コピペ運用が面倒

対策：前置き禁止＋「Markdownをそのまま出す」指定で統一する

まとめ

mdが多い週はZIPで渡す
ブレる要件（前置き、捏造、匿名化、構成）は指示書に寄せる
生成は4分割して密度を落とさない

おまけ：テンプレ類はDiscordで共有

依頼文テンプレ（タイトル出し→前半→後半→週報）や、匿名化ルール例もまとめて共有している。必要ならこちらから。
[Discord参加リンク]