本文へ移動
cccskills
無料GitHub で公開

shukkou-kanri

新聞・報道編集部の出稿管理を支援する。原稿の進行(出稿状況)の管理、締切・降版スケジュールの管理、編集カレンダーの作成、取材・原稿の担当割り当て、記者とデスクの引き継ぎ手順、デスク・整理・校閲の連携までを扱う。「出稿表を作りたい」「締切・降版を管理したい」「担当割りを整理したい」「引き継ぎの手順を決めたい」などの依頼で使う。

sgbms1/ja-news-skillsスター 3(GitHub 3 + cccskills 0)

実行スコア 未検証

インストール方法を見る

含まれるファイル(1)

  • SKILL.md21.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

出稿管理(編集ワークフロー)

編集部は仕組みで回る。このスキルは、原稿の進行を追い、締切と降版を管理し、記者・デスク・整理・校閲の間を調整するためのテンプレートと手順を提供する。

注意:版立て・締切・降版時刻・組版や編集システムの運用は、社・媒体・地域(本社/支社)・朝夕刊で大きく異なる。本スキルは一般的なひな形であり、各編集部の実際の運用ルールに合わせて調整すること。固有の時刻・様式は自部署の最新の取り決めで確認する。

いつ使うか

  • 原稿の進行管理(出稿状況のトラッキング)を立ち上げるとき
  • 編集カレンダー(週間・日次の予定表)を作るとき
  • 担当割り当てと引き継ぎの手順を整えるとき
  • 複数の原稿と締切を同時に回すとき
  • 新任デスク・新人記者にワークフローを教えるとき

原稿の進行状態(ステータス)

標準のステータス

状態意味主担当
企画ネタを提案、採否待ち記者
割当採用、記者が着手記者
取材中取材・取材進行中記者
初稿初稿を出稿(提出)デスク
デスク中デスクが手入れ中デスク
戻し直しのため記者に差し戻し記者
校閲校閲・用語チェック段階校閲
整理見出し付け・レイアウト・割付整理
完成掲載可(出稿確定)デスク
組み待ち特定の版・面に予定済みシステム/整理
掲載済紙面・配信で出た完了
保留一時停止、ボツではないデスク
ボツ不採用・取りやめデスク

進行の流れ

企画 → 割当 → 取材中 → 初稿 → デスク中 → 戻し(往復) → 校閲 → 整理 → 完成 → 組み待ち → 掲載済
                                  ↓
                               保留/ボツ

メモ:紙面では「整理」が見出し・割付・組版を担い、Web配信では公開枠の予約や入稿が同等の工程になる。媒体に合わせて「整理/組み待ち」を読み替える。

取材・原稿の担当割り当て(出稿割り)

担当割り当て票のテンプレート

## 原稿:[仮見出し/識別名(スラッグ)]

### 割り当ての基本情報
- **担当記者:** [氏名]
- **出稿デスク:** [氏名]
- **割当日:** [年月日]
- **締切:** [年月日 時刻]
- **掲載予定:** [媒体・面/配信枠(例:朝刊社会面/Web速報)]

### 原稿の仕様
- **種別:** [ベタ/本記/解説/企画・連載/特集 など]
- **行数・字数:** [目標。段数・行数 or 字数]
- **写真・図版:** [写真、動画、図表・グラフィックの要否]
- **取材源:** [最低限必要な取材先・裏取りの数]

### 出稿内容(指示)
[何を書くか。切り口、必ず入れる要素]

### 主な取材先・連絡先
[取材対象、広報窓口、識者・専門家]

### 背景・参考資料
[過去記事、資料、データへのリンク]

### 出稿表用の一行(budget line)
[編集会議の出稿表に載せる一文要約]

### 状態の履歴
| 日付 | 状態 | メモ |
|------|------|------|
| [日付] | 割当 | |
| [日付] | [状態] | [メモ] |

割り当て引き継ぎチェックリスト

原稿を割り当てるとき:

## 出稿割りの引き継ぎ

### デスク → 記者
- [ ] 原稿の範囲(テーマ・切り口)を明確に伝えた
- [ ] 締切を確認した
- [ ] 行数・字数・種別を指定した
- [ ] 主要な取材先を共有した
- [ ] 背景資料を渡した
- [ ] 写真・図版の必要性を相談した
- [ ] 記者の疑問に答えた

### 記者の確認
- [ ] 締切は現実的か
- [ ] 必要な取材先にアクセスできるか
- [ ] 切り口を理解しているか
- [ ] 困ったときに誰に相談するか分かっているか

編集カレンダー(予定表)

カレンダーのテンプレート

## 編集カレンダー:[◯月◯日の週/◯月]

### ◯月◯日(月)
| 時間帯 | 原稿 | 記者 | 状態 | メモ |
|--------|------|------|------|------|
| 午前 | [原稿] | [氏名] | [状態] | |
| 午後 | [原稿] | [氏名] | [状態] | |

### ◯月◯日(火)
[同じ書式]

### 持ち(いつでも出せる原稿の待機列)
| 原稿 | 記者 | 仕上がり日 | メモ |
|------|------|-----------|------|
| [原稿] | [氏名] | [日付] | [この日以降はいつでも掲載可] |

### 近日(向こう2週間)
| 原稿 | 記者 | 掲載目標日 | 状態 |
|------|------|-----------|------|
| [原稿] | [氏名] | [日付] | [状態] |

メモ:「持ち」=特定の日付に縛られず、紙面に余裕があるとき差し込める原稿(連載のストック、評論、コラム等)。締切が詰まった日の調整弁になる。

編集会議のテンプレート

日次・週次の編集会議(出稿会議)用:

## 編集会議:[年月日]

### 本日の出稿(きょうの紙面・配信)
| 原稿 | 記者 | 状態 | 出稿/掲載時刻 | メモ |
|------|------|------|--------------|------|
| [原稿] | [氏名] | [状態] | [時刻] | |

### 明日の出稿
[同じ書式]

### 進行中(今週締切)
| 原稿 | 記者 | 締切 | 状態 | 滞り(ブロッカー) |
|------|------|------|------|----------------|
| [原稿] | [氏名] | [日付] | [状態] | [問題があれば] |

### パイプライン(2週間以降)
| 原稿 | 記者 | 目標 | 状態 |
|------|------|------|------|
| [原稿] | [氏名] | [日付] | [状態] |

### 協議事項
- [論点1]
- [論点2]

### 決定・宿題(アクション)
- [ ] [対応] - [担当] - [期限]

締切・降版の管理

締切の種類

新聞は「版」ごとに降版時刻が決まっており、最終的な紙面の締切は降版で固定される。Web配信は公開時刻が締切になる。

締切目的目安のリードタイム
取材完了取材・裏取りを終える初稿の2〜5日前
初稿デスクに出稿デスク作業の24〜48時間前
確定稿直し反映後校閲の12〜24時間前
写真・図版ビジュアルの用意初稿と同時期
校閲用語・事実・表記の確認降版の数時間前
整理(見出し・割付)紙面化降版の前
降版/配信紙面を送る/記事を公開各版の確定時刻

メモ:朝刊・夕刊や版(早版〜最終版)ごとに降版時刻は異なる。「降版」は紙面をその版で確定して印刷工程へ送ること。速報・続報は版を追って差し替える運用がある。具体の時刻は自部署の版立て表で確認する。

締切トラッキング(逆算)テンプレート

## 原稿:[見出し]
**最終締切(降版/配信時刻):** [年月日 時刻/版]

### 逆算スケジュール
| 工程 | 締切 | 状態 |
|------|------|------|
| 取材完了 | [日付] | ☐ |
| 初稿出稿 | [日付] | ☐ |
| 写真・図版 | [日付] | ☐ |
| デスク完了 | [日付] | ☐ |
| 直し戻し | [日付] | ☐ |
| 校閲完了 | [日付] | ☐ |
| 最終確認 | [日付] | ☐ |
| 整理・組み/公開 | [日付] | ☐ |

締切遅れの対応手順

締切に間に合わないおそれが出たとき:

  1. すぐ連絡する — 締切を過ぎてからではなく、危ないと分かった時点で
  2. 手短に理由を — 何が進行を妨げているか
  3. 新しい締切を提案 — 現実的な見込み時刻
  4. 代案を出す — 短いバージョンにする? 切り口を変える? 版を落とす(次版回し)?
## 締切アラート

**原稿:** [見出し]
**当初の締切:** [年月日 時刻/版]
**問題:** [何が妨げているか]
**提案する新締切:** [年月日 時刻]
**影響:** [紙面・版・他原稿への影響]
**代案:** [あれば選択肢]

メモ:降版に間に合わない場合、「次版送り(後の版に回す)」「短縮版で当版に入れる」「続報で対応」などを早めにデスク・整理と詰める。版を落とす判断はデスクと整理の合意で行う。

出稿の引き継ぎ手順(記者⇄デスク)

記者 → デスク(出稿時)

初稿を出すとき:

## 出稿:[原稿の見出し]

**原稿の所在:** [リンク/ファイル/編集システムの記事ID]
**行数・字数:** [数]

### 入っている内容
- [押さえた要点]

### まだ足りないもの
- [ ] [未確定の項目]
- [ ] [取材先からの折り返し待ち]

### デスクへの相談
- [構成・切り口などの相談点]

### 取材源についてのメモ
- [匿名・オフレコの扱い、引用の帰属、裏取り状況など]

### 写真・図版の状況
- 写真:[用意済/手配中/要手配]
- 図版・グラフィック:[用意済/手配中/要手配]

デスク → 記者(差し戻し時)

直しのために戻すとき:

## デスクメモ:[原稿の見出し]

**全体所感:** [短評:方向はよい/要修正 など]

### 構成の直し
- [大きな構成変更、抜けている要素 など]

### 個別の直し
- [◯行目]:[問題/修正指示]
- [◯行目]:[問題/修正指示]

### 確認が要る点
- [記者に確認したい事項]

### 直しの締切
[年月日 時刻/間に合わせる版]

### 相談は要るか
[要:直す前に一度話す/不要:指示で明確]

出稿前・掲載後チェックリスト

出稿前(降版前)チェックリスト

## 出稿前:[原稿の見出し]

### 内容
- [ ] 見出しは正確で読ませる力があるか
- [ ] 前文(リード)が要点を要約しているか
- [ ] 書き出し(リード)が機能しているか
- [ ] すべての事実を確認したか
- [ ] すべての取材源・引用の帰属が正しいか
- [ ] 発言の引用が正確か
- [ ] 数字を再確認したか

### 表記・スタイル
- [ ] 社の用語・表記ルールを適用したか(記者ハンドブック等)
- [ ] 文体・人称が通して一貫しているか
- [ ] 誤字脱字・文法の誤りがないか
- [ ] 行数・字数が適切か(段・行に収まるか)

### 法務・倫理
- [ ] 名誉毀損・プライバシー侵害のおそれはないか
- [ ] 反論・コメントを取るべき相手に当てたか
- [ ] 過去記事からの訂正を反映したか
- [ ] 報道解禁(エンバーゴ)を守っているか

### 写真・図版
- [ ] 写真にキャプションとクレジットがあるか
- [ ] (Web)代替テキスト(altテキスト)を入れたか
- [ ] 動画・音声が正しく再生されるか
- [ ] 図表・グラフが正確か

### メタ情報(Web配信時)
- [ ] SEO用の見出しを入れたか
- [ ] メタ説明文(ディスクリプション)を書いたか
- [ ] タグ・カテゴリを設定したか
- [ ] 署名(バイライン)が正しいか
- [ ] 公開日時を設定したか

### 最終サインオフ
- [ ] 記者が最終形を確認した
- [ ] デスクが了承した
- [ ] 校閲がサインオフした

掲載後チェックリスト

## 掲載後:[原稿の見出し]

### 直後(1時間以内・主にWeb)
- [ ] 記事が正しく表示されている
- [ ] リンクが機能する
- [ ] 画像が表示される
- [ ] 明らかな誤りがない
- [ ] SNS投稿を予約/投稿した

### 当日中
- [ ] コメント・反応を確認する
- [ ] 訂正の要否を見張る
- [ ] 初動のアクセス・反響を見る
- [ ] 問い合わせ・指摘に対応する

### フォローアップ
- [ ] 追記・更新の要否を確認
- [ ] 行った訂正・おわびを記録
- [ ] 読者の反応を拾う
- [ ] 必要なら続報を計画する

メモ:紙面の訂正は次版・翌日紙面での「おわびと訂正」、Webは記事の更新履歴・訂正注記が一般的。社の訂正手順に従う。

ワークフローの文書化

業務手順書のテンプレート

自部署のワークフローを文書化するとき:

## ワークフロー:[手順の名称]

### 目的
[この手順で何を達成するか]

### いつ使うか
[この手順を起動する場面]

### 関わる役割
| 役割 | 担当範囲 |
|------|---------|
| [役割] | [やること] |

### 手順
**ステップ1:[名称]**
- 担当:[役割]
- 動作:[何が起きるか]
- 成果物:[何が出来上がるか]
- 次へ:[次工程の起動条件]

**ステップ2:[名称]**
[同じ書式]

### 使うツール・システム
- [編集システム/組版システム/共有ドライブ 等]:[用途]

### テンプレート・様式
- [テンプレートへのリンク]

### 例外
- [通常手順が当てはまらない場合]
- [そのときどうするか]

### エスカレーション
- [いつ上に上げるか]
- [誰に連絡するか]

新任者のオンボーディング

## 出稿ワークフローのオンボーディング

### 初日
- [ ] 編集システム(CMS/組版システム)のアカウント発行
- [ ] 編集部のチャット・連絡チャンネルに追加
- [ ] 用語・表記ルール(記者ハンドブック等)を受領
- [ ] 直属のデスクと顔合わせ

### 1週目
- [ ] ベテラン記者に同行・見習い
- [ ] ワークフロー手順書を確認
- [ ] 最初の原稿を担当(影響の小さいもの)
- [ ] 締切・降版の感覚をつかむ

### 1か月目
- [ ] 標準的な原稿を独力で回せる
- [ ] エスカレーションの道筋を把握
- [ ] 版立て・編集カレンダーを理解
- [ ] すべてのツールに習熟

### 主な連絡先
| 用件 | 連絡先 |
|------|--------|
| 出稿・割り当ての相談 | [氏名] |
| システム・技術トラブル | [氏名] |
| 編集方針の判断 | [氏名] |
| 総務・人事 | [氏名] |

出稿管理のトラッキング(簡易データ構造)

複数の原稿・締切・版を横断管理するための簡易データ構造。日本の新聞の進行(版ごとの降版・差し替え)に合わせている。

from dataclasses import dataclass, field
from datetime import datetime
from enum import Enum
from typing import Optional

class StoryStatus(Enum):
    PITCH = "企画"
    ASSIGNED = "割当"
    REPORTING = "取材中"
    DRAFT = "初稿"
    DESK = "デスク中"
    REVISION = "戻し"
    PROOF = "校閲"
    LAYOUT = "整理"
    FINAL = "完成"
    QUEUED = "組み待ち"
    PUBLISHED = "掲載済"
    HOLD = "保留"
    KILL = "ボツ"

@dataclass
class Story:
    id: str
    slug: str                         # 仮見出し・識別名
    reporter: str                     # 担当記者
    desk: str                         # 出稿デスク
    section: str                      # 掲載面・配信枠
    deadline: datetime                # 最終締切(降版/公開時刻)
    status: StoryStatus = StoryStatus.PITCH

    edition: Optional[str] = None     # 版(例: "最終版", "13版", "夕刊")
    length: Optional[str] = None      # 行数・字数(例: "本記80行")
    photos: bool = False              # 写真・図版の要否
    sources_min: int = 0              # 必要な裏取り・取材源の最低数

    submitted_at: Optional[datetime] = None  # 初稿出稿日時
    published_at: Optional[datetime] = None  # 掲載・配信日時
    notes: str = ""

    @property
    def is_overdue(self) -> bool:
        """締切超過かつ未完成のもの。"""
        return datetime.now() > self.deadline and self.status not in {
            StoryStatus.FINAL, StoryStatus.QUEUED,
            StoryStatus.PUBLISHED, StoryStatus.KILL,
        }

    @property
    def is_at_risk(self) -> bool:
        """締切まで2時間を切っているのに完成していない(要注意)。"""
        remaining = (self.deadline - datetime.now()).total_seconds()
        return 0 < remaining < 7200 and self.status not in {
            StoryStatus.FINAL, StoryStatus.QUEUED, StoryStatus.PUBLISHED,
        }

# 出稿表(出稿管理表)に持たせる列の例
TRACKING_COLUMNS = [
    "原稿ID", "識別名", "担当記者", "出稿デスク", "掲載面", "版",
    "締切", "状態", "行数/字数", "写真", "出稿日時", "掲載日時", "備考",
]

デスク・整理・校閲の連携

紙面では、デスク(出稿・原稿整理)、整理(見出し・割付・組版)、校閲(用語・事実・表記)が並行して動く。引き継ぎが滞ると降版に響く。

## 工程間の連携ポイント

### デスク → 整理
- [ ] 確定稿の行数・字数を確定して渡す(段・行が動かないように)
- [ ] 想定する扱い(トップ/準トップ/ベタ)と面を共有
- [ ] 写真・図版の有無と点数、キャプション原稿を渡す
- [ ] 見出しの方向性(柱になる事実・キーワード)を伝える

### デスク → 校閲
- [ ] 確定稿を所定の時刻までに回す
- [ ] 固有名詞・数字・肩書の典拠(裏取りメモ)を添える
- [ ] 急ぎ・後追い差し替えの予定を共有

### 校閲 → デスク
- [ ] 用語・表記・事実の疑問を疑問出し(要確認点)として戻す
- [ ] 修正は降版時刻から逆算した締切までに

### 整理 → デスク
- [ ] 見出し案・割付を確認に回す
- [ ] 行数オーバー/不足の調整(削り・足し)を依頼
- [ ] 版ごとの差し替え可否・締切時刻を共有

版進行・差し替えの管理

## 版進行メモ(速報・続報があるとき)

| 版 | 降版時刻 | 入れる原稿 | 差し替え予定 | 担当デスク |
|----|---------|-----------|------------|-----------|
| [早版] | [時刻] | [原稿/状態] | [後版で差し替え予定の有無] | [氏名] |
| [中版] | [時刻] | [原稿/状態] | | [氏名] |
| [最終版] | [時刻] | [原稿/状態] | | [氏名] |

メモ:
- 差し替えは「どの版から・どの面・何行差し替えるか」を整理と合意してから動かす
- 続報・速報は時系列(いつ・どの版で更新)を記録し、Web配信との整合をとる

当番引き継ぎ(シフトの申し送り)

夕刊から朝刊、当番デスク交代などの引き継ぎ用。抜け落ちが事故につながるため定型化する。

## 当番引き継ぎ(申し送り):[年月日 時間帯]

**引き継ぐ人:** [氏名] → **引き継ぐ先:** [氏名]

### 進行中で要注意の原稿
| 原稿 | 記者 | 状態 | 締切/版 | 注意点 |
|------|------|------|---------|--------|
| [原稿] | [氏名] | [状態] | [締切] | [折り返し待ち・確認中 等] |

### 確定済み・あとは流すだけ
- [原稿/面/版]

### 未決・判断保留
- [論点と、誰が判断するか]

### 注意・申し送り
- [取材先からの連絡待ち、抗議・問い合わせ、訂正の可能性 等]

### 連絡先
- [当番記者、整理当番、校閲当番、緊急時のデスク]

取材・編集実務上の注意

  • 締切・降版時刻、版立ては社・媒体・地域で異なる。本スキルの数値や工程名はひな形であり、自部署の運用に合わせる。
  • 用語・表記は各社の用語ルール(記者ハンドブック等)に従う。本スキルは手順の枠組みであり、用語集の中身は扱わない。
  • 速報・続報では「どの版・どの面・何を差し替えたか」を必ず記録し、紙面とWeb配信の食い違いを防ぐ。
  • 良いワークフローは目立たない。壊れたときに初めて存在に気づく — だからこそ、平時に手順とテンプレートを整えておく。

出典・ライセンス(帰属表示)

本スキルは claude-skills-journalism(by Joe Amditis, MIT License, © 2025 Joe Amditis, https://github.com/jamditis/claude-skills-journalism )の journalism-core/editorial-workflow を 原典の構成(ステータス体系・担当割り当て・編集カレンダー・締切管理・引き継ぎ手順・出稿前/掲載後チェックリスト・ワークフロー文書化)に沿って日本語化し、 米国編集部の役職・ツール・スタイル運用を日本の新聞編集の実務(出稿・デスク・整理・校閲・降版/版立て)に再構成したものです。 米国固有の役職名・CMS・AP Style等の前提は日本の制度・実務に置き換え、該当しない部分は適応・割愛しています。 原典の著作物本文は転載していません。原作者の公認・推奨を受けたものではありません。 MIT ライセンス全文は同梱の LICENSE-MIT.txt を参照。

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

ai-bun-shuusei

無料概要あり

AIが生成しがちな「いかにもAIっぽい」日本語の定型表現・水増し・空疎な形容を取り除き、読者の信頼を損なわない自然な文章に直す。記事・原稿・プレスリリース・告知・SNS投稿など、AIの支援を受けて書いた文章を公開前に点検するときに使う。「AI臭を消したい」「文章が機械っぽい」「人が書いたように直したい」などの依頼で使う。

sgbms1/ja-news-skills32026年7月14日 更新

data-api-catalog

無料概要あり

取材・調査・データ報道で使える無料データ源(API)のカタログ。政府統計(e-Stat)、地域経済(RESAS)、気象(気象庁)、法令(e-Gov)、企業開示(EDINET)、書誌・国会会議録(国立国会図書館)、地理空間(国土地理院)、汎用の国際API(GDELT・Open-Meteo・Wayback等)を用途別に整理し、登録要否・利用条件・選び方を示す。「無料のデータ源が欲しい」「このテーマのAPIは?」「公的データをプログラムで取りたい」といった依頼で使う。

sgbms1/ja-news-skills32026年7月14日 更新

data-hodo

無料概要あり

データ報道(データジャーナリズム)の手順を支援する。データセットの分析、グラフや地図の作成、雑然としたデータのクリーニング、統計の算出、データに基づく記事の構築に使う。「e-Statのデータを分析したい」「人口あたりで比較したい」「グラフが誤解を招かないか確認したい」「統計から記事を組み立てたい」などの依頼で使う。記者・編集者・調査担当向け。

sgbms1/ja-news-skills32026年7月14日 更新

digital-archive

無料概要あり

取材で集めた資料(開示文書・記事・SNS・反訳など)をデジタルアーカイブ化し、AIで要約・分類・エンティティ抽出・関係づけ(知識グラフ化)して横断検索できる調査基盤を作るための手引き。「取材資料を整理したい」「大量の開示文書をデータベース化したい」「人物・組織・出来事の関係を可視化したい」「調査報道のアーカイブを作りたい」などの依頼で使う。

sgbms1/ja-news-skills32026年7月14日 更新

fact-check

無料概要あり

発言・記事・SNS投稿などの主張を体系的にファクトチェックする。主張の抽出、検証可能な命題への分解、根拠の収集、当事者への確認、判定(レーティング)、記録、訂正対応までを支援する。掲載前の裏取り、ファクトチェック記事の作成、編集部の検証手順づくりに使う。「ファクトチェックして」「この発言は本当か」「裏取りの手順を」などの依頼で使う。

sgbms1/ja-news-skills32026年7月14日 更新

fact-checker-flo

無料概要あり

テキスト・記事・ウェブページの内容を、厳密な検証方法論にもとづいてファクトチェックする。検証可能な主張を抽出し、信頼できる一次情報・公的データ・検証機関と突き合わせ、各主張の真偽と確からしさ(確信度)、情報源の信頼度スコアを評価し、根拠つきの検証レポートにまとめる。「この主張を検証して」「記事をファクトチェックして」「情報源の信頼性を見て」「真偽を判定して」「誤情報か確かめて」などの依頼で使う。付属の references(信頼できる情報源/検証方法論)を参照する検証重視版。

sgbms1/ja-news-skills32026年7月14日 更新

sgbms1 のスキルをすべて見る

このスキルの問題を報告する