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参加リンク]