タグ: 進捗管理

  • ひとりAI編集部の1週間を記録する方法|AIを使った時間と修正を見える化

    ひとりAI編集部の1週間を記録する方法|AIを使った時間と修正を見える化

    記事タイプ:制度解説・ひとりAI編集部の作業記録

    AIの返答が早くても、仕事がそこで完成するとは限りません。一次資料との照合、修正、WordPressの設定、公開ページの確認が残るからです。

    ひとりAI編集部の1週間では、返答の秒数ではなく次を測ります。

    企画を決めてから、確認済みの成果物が完成するまでの総作業時間を測り、その内訳をAI操作、人の検証、人の編集、公開確認、手戻りに分けます。

    これで、短くなった工程と修正が増えた工程を翌週へ戻せます。

    結論|一週間の記録は時間・修正・完成物の三点で残す

    最低限、次の三つを記録します。

    記録するもの 内容 目的
    時間 AI操作、検証、編集、公開確認、手戻り どの工程が詰まっているかを見る
    修正 AIの誤り、抜け、使わなかった出力、人が決めた点 AIへ任せる範囲を見直す
    完成物 下書き、公開URL、更新済みページ、保留理由 作業量と完了を混同しない

    記事案が十本できても、公開が目的なら十件完了ではありません。公開を見送った仕事も、理由と確認範囲を残せば翌週の重複調査を防げます。

    何を一件の仕事として測るか

    大きな依頼を完了条件で分ける

    「動画を記事にしてSNSでも知らせる」は、完了条件で分けます。

    1. 記事原稿を作る
    2. WordPressで公開する
    3. 公開ページを確認する
    4. SNS投稿文を作る
    5. SNSで送信する

    原稿完成の証拠はファイル、公開完了の証拠は一般公開URLです。SNSの準備と送信も分けます。

    着手前に一文で目的を書く

    計測前に「誰のどんな疑問へ、何を完成させるか」を一文で書きます。

    保釈却下後の手続を知りたい読者に、一般的な刑事手続と未公表事項を分けたブログ記事を公開する。
    

    別テーマの調査が必要になったら、新しい仕事として分けます。

    時間は五つに分け、重ねて数えない

    1.AI操作時間

    素材選び、指示、出力確認、追加指示の時間です。待ち時間に別の仕事をしたら二重計上しません。

    2.人の検証時間

    一次資料、日付、数字、固有名詞、引用範囲を確認する時間です。公開責任のために残します。

    3.人の編集時間

    争点を決め、不要な段落を削り、事実・主張・評価を分け、媒体に合わせる時間です。

    4.公開・確認時間

    本文、カテゴリー、タグ、画像、内部リンクを設定し、公開ページを確認する時間です。下書き保存は公開完了にしません。

    5.手戻り時間

    誤った資料、古い数字、重複、壊れたリンクなどで前工程へ戻った時間です。通常の推敲と分けます。

    1件ごとの記録表

    一分または五分単位で記録し、休憩や別件を除きます。

    日付 タスクID 完成物 AI操作 人の検証 人の編集 公開確認 手戻り 合計 状態
    7/_ _ _ _分 _分 _分 _分 _分 _分 未着手・進行中・確認待ち・完了

    五つを合計し、処理待ちは「経過時間」として実作業へ重ねません。

    もう一枚、修正記録を付けます。

    タスクID AIへ渡した素材 AIに任せたこと 修正した箇所 人が決めたこと 使わなかった出力 根拠
    _ SRT、PDF、URLなど 分類、構成、表作成など 日付、主語、条件など 採否、見出し、公開判断など 理由も記録 原資料のURL・ページ

    「かなり直した」ではなく、「法案と施行済み制度を混同」「実在しないURL」のように原因を残します。

    七日間の記録テンプレート

    曜日ごとに仕事を固定する必要はありません。次の表は、一週間で七工程を漏らさないための型です。

    主な工程 記録すること その日の終了条件
    1日目 設計 読者の問い、媒体、完成物、期限 今週作るものと作らないものが決まる
    2日目 調査 検索語、コメント、候補資料、未確認点 一次資料候補へ戻れる
    3日目 検証 事実、主張、推測、日付、例外 根拠付きの確認表ができる
    4日目 制作 AIの入力・出力、人の修正 公開可能な原稿・画像ができる
    5日目 展開 動画、ブログ、note、Xの役割 コピペではない媒体別原稿ができる
    6日目 公開確認 URL、表示、リンク、カテゴリー、タグ 一般公開ページで確認できる
    7日目 改善 検索語、コメント、クリック、手戻り 翌週の四つの判断が決まる

    速報対応が入った日は順序が変わります。重要なのは、何曜日に何をしたかではなく、検証や公開確認が飛ばされていないかです。

    AI利用前後を比べるときの条件

    同じ仕事でなければ時間差とは言えない

    短い告知文と一次資料付きの長文記事は比べられません。次をそろえます。

    • 入力素材の量と状態
    • 成果物の文字数・形式
    • 必要な事実確認の水準
    • アイキャッチや内部リンクを含むか
    • 下書き完成か、公開確認までか

    条件が違えば「前後比較なし」とし、従来時間を推測しません。

    基準時間は同じ作業を複数回測る

    一回の速さには資料の長さや慣れが影響します。繰り返せる仕事を同じ条件で複数回測り、中央値と手戻りを比べます。

    条件 AIなし/従来手順 AIあり 品質・手戻りの違い
    同じ形式の作業を複数回測定 _分 _分 _分 _

    実測前は空欄にし、倍率は同条件の記録がそろってから計算します。

    修正記録からAIへの任せ方を変える

    修正が多い工程を数える

    一週間の終わりに、修正を原因別に数えます。

    • 固有名詞・数字・日付
    • 条件・例外の欠落
    • 事実と主張の混同
    • 古い資料・版の違い
    • 記事の重複
    • 媒体に合わない構成
    • 公開設定・リンクの不備

    同じ誤りが続けば、日付欄を追加する、一次資料を先に固定する、既存記事台帳を渡すなど、工程を変えます。

    修正ゼロも成功とは限らない

    修正ゼロでも、確認を省いただけかもしれません。「検証済み」と「未確認」を分け、後者は速さの実績に入れません。

    確認できる実例|一日の流れを、時間を作らず記録する

    2026年7月22日の運用ではYouTube Studioに表示できた直近約24時間のコメントを初期診断しました。全件集計ではないため、件数比率には使っていません。

    「裁判はいつか」「次に何が起きるか」という質問を拾い、一般的な手続、確認できること、未公表事項を分けた解説記事を公開しました。台帳では記事作成と公開を別に管理しています。

    確認できるのは、コメント診断、原稿、公開URLです。時間記録はないため「未計測」とし、短縮時間を断定しません。

    工程 確認できる記録 時間
    コメント診断 確認範囲と限界を記した分析ファイル 未計測
    企画判断 「次の刑事手続」という具体質問 未計測
    記事作成 完成原稿の記録 未計測
    公開 一般公開URL 未計測
    公開後の成果 今後、同じ期間で計測 未計測

    次回から五区分を測って初めて比較できます。

    週末は四つの改善判断で終える

    検索語、コメント、クリック、修正履歴、既存記事を並べ、四つに分けます。

    新しく作る

    既存記事では答えられず、根拠を確認できる問いを一記事一論点へ絞ります。

    既存記事を更新する

    同じ検索意図の記事があり、続報やFAQ追加で答えられる場合です。

    タイトルを修正する

    内容は問いに答えているのに選ばれにくい場合です。同条件のデータを見てタイトルやサムネイルを直します。

    今は増やさない

    資料がない、重複する、反応が一時的、計測期間が短い場合です。保留理由と再確認日を残します。

    四つの判断には、それぞれ担当、期限、完了条件を付けます。「更新する」だけでは、翌週も同じ会議を繰り返します。

    週次集計で見る数字

    一週間の最後に、次を集計します。

    • 完了した成果物数
    • 確認待ちと、その理由
    • 総作業時間
    • AI操作、人の検証、人の編集、公開確認、手戻りの内訳
    • 修正原因ごとの件数
    • 公開URLを確認できた件数
    • 新規、更新、タイトル修正、増やさない、の判断数

    AI操作が短くても、手戻りで合計が延びていれば、入力素材や任せる範囲を変えます。

    検索とYouTubeの指標は定義が違います。同じ期間・流入元で比べ、仕事時間とは別に管理します。

    1週間の記録チェックリスト

    • 今週完成させるものを一文で決めた
    • 記事作成、公開、SNS送信を別のタスクにした
    • AI操作、検証、編集、公開確認、手戻りを分けた
    • 休憩や別件を作業時間から除いた
    • AIへ渡した素材と出力を残した
    • 修正箇所を原因が分かる言葉で記録した
    • 人が決めた論点と公開判断を記録した
    • 下書き保存と公開完了を混同していない
    • 公開URLを一般公開ページで確認した
    • 未計測の時間を推測で埋めていない
    • AI利用前後は同じ条件の仕事だけを比べた
    • 新規・更新・タイトル修正・増やさない、の判断を残した
    • 翌週の担当、期限、完了条件を決めた

    よくある質問

    Q1.作業時間は一分単位で測る必要がありますか?

    五分単位でも構いません。同じルールでAI操作、検証、手戻りを分けます。

    Q2.AIが処理している待ち時間はどう数えますか?

    待ちは経過時間として別欄に置き、別の仕事をした時間と重ねません。

    Q3.AI利用前の時間を測っていません。効果をどう書けばよいですか?

    現在の工程別時間だけを記録し、次回から同条件で比べます。記憶は実測値にしません。

    Q4.記事を公開できなかった週は失敗ですか?

    資料不足による見送りは、確認範囲を残します。編集画面で止まっただけなら公開未達です。確認待ちの理由を分けます。

    Q5.修正時間が長いほどAIを使わない方がよいのでしょうか?

    一回では決めません。同じ手戻りが続けば入力形式や任せる工程を変え、工程ごとに採否を決めます。

    まとめ

    ひとりAI編集部の一週間を公開するなら、成果物の数だけでは足りません。

    AI操作、人の検証、人の編集、公開確認、手戻りを分け、何を完成としたかを記録します。修正した箇所と人が決めたことを残せば、AIへ任せる範囲を翌週に調整できます。

    実測していない時間は書かない。下書きを公開と数えない。比較条件が違う仕事を倍率にしない。

    この三つを守るだけで、「AIで速くなった気がする」という感想から、どの工程をどう直すかという業務改善へ進めます。

    公開済み関連記事

    参考にした公式資料

  • AIで仕事の進捗管理をする方法|下書き・確認待ち・公開済みを混ぜないタスク台帳

    AIで仕事の進捗管理をする方法|下書き・確認待ち・公開済みを混ぜないタスク台帳

    記事タイプ:制度解説・AI作業の進捗管理とタスク台帳

    AIを使うと、原稿、投稿文、画像案を短時間で作れるようになります。

    ところが、成果物が増えるほど別の問題が起きます。

    「記事はできたが、WordPressには入れていない」「投稿文は用意したが、Xには送っていない」「公開ボタンは押したが、一般公開ページを確認していない」。この三つが、すべて「だいたい終わった仕事」に見えてしまうのです。

    実際の運用でも、YouTube、ブログ、note、Xを並行して進めると、会話の中で完成した原稿と、読者が見られる公開物が混ざりやすくなりました。

    そこで、仕事を一枚のタスク台帳にまとめ、状態・次の作業・完了条件を分けて記録しています。

    結論から言えば、AI時代の進捗管理で必要なのは、細かな進捗率ではありません。

    「何が残っているか」と「何を確認すれば完了か」が、一行で分かることです。

    結論:成果物ではなく、完了条件ごとに仕事を分ける

    「記事を書く」という一つの仕事に、調査、執筆、入稿、公開、SNS告知まで詰め込むと、途中で止まった場所が分かりません。

    実際の運用では、少なくとも次のように分けます。

    1. 記事原稿を作成する
    2. WordPressで公開する
    3. Xで告知する

    原稿が完成した時点で、1は完了です。しかし、2と3は未着手のままです。

    この区別があれば、「記事は完成した」という報告と「記事は公開された」という事実が混ざりません。逆に三つを一行で管理すると、原稿ができた段階で全体を完了にしたり、公開後もいつまでも進行中にしたりします。

    大切なのは、作業量で分けることではありません。

    完了の証拠が違う仕事を、別の行にすることです。

    タスク台帳に必要なのは六つの項目

    運用上の台帳では、次の六つを記録します。

    項目 記録する内容
    ID 後から同じ依頼を区別できる番号
    依頼 何をどこまで行う仕事か
    状態 未着手・進行中・確認待ち・完了
    次に必要なこと 次に着手する一つの作業
    完了条件 何を確認したら終わりにできるか
    メモ 公開方法、保留理由、関連タスクなど

    AIへ仕事を依頼するときも、この六項目があると引き継ぎやすくなります。

    「この記事を進めて」では、調査から始めるのか、原稿を直すのか、公開するのか分かりません。「本文は完成済み。次はWordPressへ設定。一般公開ページでタイトル、本文、カテゴリ、タグ、画像、リンクを確認したら完了」と渡せば、残作業が明確です。

    状態は四つに絞る

    状態を増やしすぎると、選ぶたびに迷います。実際の運用では、未着手、進行中、確認待ち、完了の四つを使います。

    未着手|依頼はあるが、まだ始めていない

    企画名だけが決まった状態です。

    「いつか書きたい案」と混ぜないため、台帳には実際に着手する予定の仕事だけを入れます。担当や順番が決まっていない構想は、企画メモで管理した方が一覧が濁りません。

    進行中|今、作業している

    調査中、執筆中、入稿中など、手を動かしている状態です。

    「進行中」と書くだけでは、翌日に再開できません。次の作業も一つ書きます。

    • 本文の事実確認を行う
    • サムネイル文言を決める
    • WordPressへ本文を設定する

    次の作業が二つ以上あるなら、先に行う一つを残します。

    確認待ち|成果物はあるが、判断や証拠が残っている

    確認待ちは、失敗でも停止でもありません。

    原稿はできたが公開の承認がない。引用したい資料を取得できない。公開操作は終えたが、一般公開ページをまだ確認できない。こうした状態です。

    確認待ちに移すときは、理由と再開条件を必ず残します。

    状態:確認待ち
    理由:公開の承認が未取得
    再開条件:承認後、WordPressへ設定する
    

    この記録がないと、後から見た人は「忘れている仕事」なのか「待つべき仕事」なのか判断できません。

    完了|依頼された最終状態を確認できた

    完了は、作業したという自己申告ではなく、完了条件を満たした状態です。

    記事作成なら、本文とSEO情報、サムネイル素材がそろったこと。公開まで依頼されたなら、公開URLを開き、本文や設定が読者から見えること。Xへの投稿なら、実際の投稿URLと表示を確認したことです。

    下書き保存や投稿画面の準備は、作業の進展ではあっても公開の完了ではありません。

    実例:原稿作成とWordPress公開を二つに分けた

    実際の運用では、2026年7月22日に公開した記事でも、「記事作成」と「公開」を別々に管理しました。

    原稿作成の完了条件は、確認事項、一般的な制度、未公表事項を分けた原稿が完成することでした。一方、公開作業では、WordPressの公開済み状態と一般公開ページを確認し、タイトル、見出し、表、参考資料、カテゴリ、タグ、アイキャッチ、URL設定まで点検しました。

    同じ記事でも、証拠は別です。

    仕事 完了の証拠
    記事作成 完成原稿のファイルがあり、必要項目がそろっている
    WordPress公開 一般公開URLで本文と設定を確認できる
    関連記事の更新 既存の公開記事から新記事へのリンクを確認できる
    SNS告知 投稿URLを開き、本文・リンク・画像を確認できる

    この分け方にすると、「原稿はあるが未公開」を正しく残せます。また、公開だけが止まっているときに、記事を最初から作り直す必要もありません。

    AIに任せるのは整理と点検、人が決めるのは状態

    AIは、会話や作業記録からタスク候補を拾い、表へ整える作業に向いています。

    • 新しい依頼を一行へ変換する
    • 大きな依頼を完了条件ごとに分ける
    • 「次に必要なこと」が空欄の行を探す
    • 長く進行中の仕事を一覧にする
    • 公開URLがない完了行を点検する
    • 日報や会話から完了候補を抽出する

    ただし、AIが「完了しました」と書いただけでは、完了にしません。

    人が、成果物、公開ページ、送信結果などを確認し、状態を決めます。特に外部への公開や送信は、AIの作業報告ではなく、読者や受信者から見える結果を証拠にします。

    台帳を更新するのは三つの節目だけ

    台帳を常に手入れしようとすると、管理そのものが仕事になります。

    更新する時点を三つに固定すると続けやすくなります。

    依頼を受けたとき

    依頼、初期状態、次の作業、完了条件を一行で登録します。

    大きな依頼なら、この時点で「作成」「公開」「告知」に分けます。

    状態が変わったとき

    未着手から進行中、進行中から確認待ち、確認待ちから完了へ移るときだけ更新します。

    細かな進捗率は不要です。代わりに、次の作業と待っている理由を変えます。

    仕事を終えるとき

    完了条件と証拠を照合します。公開を伴う仕事では、成果物や公開URLも残します。

    これで、過去の仕事を探すときにも台帳が索引になります。

    そのまま使えるタスク台帳のひな型

    | ID | 依頼 | 状態 | 次に必要なこと | 完了条件 | メモ |
    |---|---|---|---|---|---|
    | 001 | ○○の記事原稿を作成 | 進行中 | 本文を事実確認 | 本文・SEO情報・画像素材が完成 | 公開は別タスク |
    | 002 | ○○の記事を公開 | 未着手 | 原稿完成後に入稿 | 公開URLで本文・カテゴリ・タグ・画像・リンクを確認 |  |
    | 003 | ○○をXで告知 | 未着手 | 公開URL確定後に投稿 | 投稿URLと表示を確認 |  |
    

    一行の依頼文には、動詞と対象を入れます。「○○記事」だけではなく、「○○の記事原稿を作成」「○○の記事をWordPressで公開」のように書きます。

    仕事を完了にする前のチェックリスト

    • 依頼された最終状態を読み直した
    • 原稿作成、公開、SNS投稿を必要に応じて分けた
    • 状態が未着手・進行中・確認待ち・完了のどれかに統一されている
    • 次に必要な作業が一つに絞られている
    • 確認待ちの理由と再開条件が書かれている
    • 完了条件が「確認できる事実」になっている
    • 完成原稿または成果物の場所を記録した
    • 公開を伴う場合は一般公開URLを開いた
    • 送信を伴う場合は送信結果または投稿URLを確認した
    • 下書き保存だけで公開済みにしていない
    • 関連する未着手タスクを誤って完了にしていない
    • 完了日と必要なメモを残した

    よくある質問

    Q1.タスク管理アプリを使わなくてもできますか?

    できます。最初はMarkdown、表計算、メモの表で十分です。

    道具よりも、状態、次の作業、完了条件を同じ一行に置くことが大切です。複数人で同時に編集する、期限通知が必要になるといった問題が出てから、専用ツールへ移しても遅くありません。

    Q2.「90%完了」のような進捗率は必要ですか?

    一人または少人数の制作では、なくても回せます。

    90%と書いても、残りが事実確認なのか、入稿なのか、承認なのか分かりません。「次に必要なこと」を書く方が、再開しやすくなります。

    Q3.確認待ちが増えたら、どうすればよいですか?

    理由で分けます。承認待ち、素材待ち、公開確認待ちなどをメモに残し、週に一度だけ見直します。

    自分だけでは動かせない仕事と、確認すれば進められる仕事を同じ扱いにしないことがポイントです。

    Q4.公開済みの記事を更新するときは、新しいタスクにしますか?

    はい。元記事が公開済みでも、更新作業は別の仕事です。

    更新内容、情報を確認した日、公開ページで再確認する項目を完了条件にします。過去の公開実績を進行中へ戻すのではなく、更新タスクを追加します。

    Q5.AIに台帳を自動更新させてもよいですか?

    候補の追記や表の整形は任せられます。ただし、公開、送信、削除、承認が関わる状態変更は、人が証拠を確認して決めます。

    まとめ

    • AIで成果物が増えるほど、下書き・確認待ち・公開済みを分ける必要がある
    • 完了の証拠が違う仕事は、別の行にする
    • 台帳には、依頼、状態、次の作業、完了条件を必ず置く
    • 状態は、未着手・進行中・確認待ち・完了の四つに絞る
    • 確認待ちには、理由と再開条件を残す
    • AIには整理と抜け漏れ確認を任せ、完了判断は人が行う
    • 下書き保存、入稿、投稿文の準備は、公開や送信の完了ではない

    タスク台帳は、仕事を細かく監視するための表ではありません。

    翌日に見ても、別の人が見ても、「今どこで止まり、次に何をすれば終わるか」が分かる引き継ぎです。

    まずは、今抱えている仕事を三つだけ選び、「原稿作成」「公開」「告知」に分けてみてください。混ざっていた未完了の仕事が見えるようになります。

    関連記事