1記事が投稿されるタイミング

システムは 毎日きまった時間 に、自動で動き始めます。 人がボタンを押す必要はありません。

1日の流れ（タイムライン）

毎日 19:00
システムが起動 — 新しい動画を探す
パソコンの中で自動的にプログラムが立ち上がり、 「さきの海外不動産しか勝たん」チャンネルに、過去2日以内に投稿された新しい動画があるかを確認します。
19:00 〜 19:15頃
動画をlivedoor Echoesにアップロード
新しい動画が見つかると、YouTubeのリンクを livedoor の記事管理画面（Echoes）に登録します。 このとき動画タイトルの先頭に テスト投稿 という目印をつけて、 代行業者さんの作業と区別できるようにしています。
19:15 〜 19:30頃
Echoes側で文字起こしが生成される
livedoor Echoes が動画の音声から自動文字起こしを生成します。 所要時間は動画の長さによりますが、おおむね5〜15分です。
文字起こし完了後（だいたい5〜10分）
AI（Claude）が編集ガイドラインに沿って本文を作成
文字起こしを元に、AIが 編集ガイドライン と 過去の代行業者作成記事10件 を参照しながら、 約800〜1,100字・4ブロック構成（紹介 + 論点1 + 論点2 + 締め）の記事本文と、 固定フレームのタイトルを生成します。文末ごとに改行が入り、読みやすいレイアウトで出力されます。
本文ができ次第（だいたい19:30〜19:50前後）
Larkに完成のお知らせが届く
記事のタイトル、本文、Echoes の記事IDなど、すべての情報が Lark の「下書き予約ボット」 から自動でメッセージとして送られてきます。 通知の冒頭には ⚠️ これはテスト投稿です。下書きになっていますので、不要な場合は削除してください。 という 目印バナーが表示されます。 ここで初めて「運用スタッフが見るタイミング」です。
運用スタッフが任意のタイミングで
★ ここが運用スタッフの出番 ★ Larkで返信して予約投稿の日時を指定
Botから届いた 「📝 記事下書き完成のお知らせ」 のメッセージに対して、 長押し（PCではホバー）から「返信」を選び、年・月・日・時刻をすべて含めた形で返信します。
返信の書き方（必ず年から書く）:
@下書き予約ボット 2026/05/15 18:00
返信から数秒〜30秒以内
「予約投稿として設定しました」の確認通知が届く
システムは Lark のメンション返信をリアルタイムで受信 する仕組みになっています（v1.2 で改善、旧来の1時間ポーリングから WebSocket 即時応答へ移行）。 通常は返信から 1〜30 秒程度 で、記事IDと予約日時を含む確認メッセージが返ってきます。 ※ パソコンがスリープ・電源OFFになっていた間に届いた返信は、朝7:00 と 夜19:30 の保険チェックでまとめて処理されます。
指定した日時
livedoor上で自動的に公開
予約した時間がくると、livedoor 側のしくみで記事が自動公開されます。 公開後は通常の記事と同じ扱いです。
ポイント

動画が公開された日のうちに記事が間に合わなくても大丈夫です。 システムは過去2日分まで見にいくので、夜遅くにアップされた動画は翌日に処理されます。

2新しい動画がない日はどうなるか

動画は毎日アップされるとは限りません。新しい動画が見つからなかった日も、システムは 必ずLarkに「今日はありませんでした」のお知らせを送ります。 無音にはなりません。

📭 「新着なし」通知の例 情報のみ
過去2日以内に 未処理の 新しい動画は見つかりませんでした。
（YouTube側に動画はあっても、自動記事化の対象となる未処理の動画はゼロという意味です）
次回のチェックは明日 19:00 です。
運用スタッフのアクション: なし。確認するだけでOK。返信も不要です。
「未処理」とは？

YouTubeに動画が公開されていても、すでに代行業者さんが記事を作っていたり、 過去にこのシステムが記事化済みだったりする動画は「処理済み」扱いです。 通知の「動画は見つかりませんでした」は、新しく記事化すべき動画がなかったという意味です。

なぜ「ありません」通知を出すのか

通知が来ない＝システムが止まっている、と誤解されないようにするためです。
毎日決まって何らかのメッセージが届くことで、 「システムは今日もちゃんと動いた」とひと目で確認できます。
注意

もし 夜になっても「新着なし」も「下書き完成」も届かなかった日 は、 システムが止まっている可能性があります。 翌朝までに何も来ていなければ、システム担当者にひと声かけてください。

3代行業者さんとの「分担ルール」

現在、Echoes には 代行業者さんが手作業で作る記事 と、 このシステムが自動で作る記事 の2系統が並んで動いています。 お互いの作業を壊さないために、はっきりした「分担ルール」を設けています。

最優先ルール：代行業者さんの作業を絶対に上書きしない

最重要

代行業者さんが手をつけた動画に、システムが触ることは絶対にありません。 テスト運用期間中は、代行業者さん側の作業が常に優先です。

どうやって区別しているか

システムが Echoes に動画を登録するときは、動画タイトルの先頭に必ず テスト投稿 という目印をつけます。 これがあれば「システムが作ったもの」、なければ「代行業者さんが作ったもの」と分かります。

🤖
タイトルに「テスト投稿」あり
このシステムが自動で作ったもの。
AIが本文を生成 → Lark通知 → 予約投稿、という流れで進みます。
✋
タイトルに「テスト投稿」なし
代行業者さんが作業中、または作業済みのもの。
システムは一切触らず、自動処理を中断します。

同じ動画を両者がさわろうとしたら？

システムは動画をアップロードする直前に、もう一度 Echoes をチェックします。 そのとき「同じ動画がすでに登録されていて、目印がない」場合は、 代行業者さんの作業と判断して すぐに処理を中断 します。

1 システムが「この動画を処理しよう」と決める
↓
2 アップロード直前に Echoes を再チェック
↓
3 既存エントリの有無とタイトルを確認
↓
! 目印がなければ「代行業者さんの作業」と判定 → 中断 → Lark通知

このときLarkに届く通知

🛑 森川様投稿済みのため、自動記事作成中断 中断
動画ID: （該当する動画のID）
YouTubeタイトル: （該当する動画名）

Echoes側に既存記事（テスト投稿マーカーなし）を検知したため、
代行業者の作業と判断して自動処理をスキップしました。
運用スタッフのアクション: なし。代行業者さん側で対応中なので、そのまま見守ってください。

システム側で「テスト投稿」が外された場合

運用上の注意

テスト投稿マーカーは、代行業者さんと自動システムを見分けるためのものです。 このマーカーを人が手動で消してしまうと、システムは「代行業者さんの作業」と判定して、以降そのエントリには触らなくなります。 テスト中は、システムが作った下書きのタイトルに手を入れないようにしてください。

「テスト投稿」マーカーは、いつまで付くのか

運用フェーズの違い

「テスト投稿」のマーカーは、現在の運用テスト期間中の暫定的な仕様です。 代行業者さんによる手作業と AIによる自動作成を並行運用しているあいだだけ、 誤ってお互いの記事を上書きしないように付与しています。

将来、代行業者さんの作業から AIによる自動作成に完全移行した時点で、 この「テスト投稿」マーカーは付与されなくなり、 AIにより作成されたタイトルでEchoesに登録されるようになります。

フェーズタイトル先頭の表示運用
現在
（テスト運用中）		 テスト投稿 ＋ 動画タイトル 代行業者さんと並行運用。マーカーで識別。
本番移行後 動画タイトルのみ AIによる自動作成に完全移行。マーカーは削除。

4Lark通知が来たとき、どう動くか

Lark に届く通知は、おおまかに 4種類 あります。 絵文字とタイトルで一目で見分けられるようになっています。

絵文字通知のタイトル意味運用スタッフのアクション
📝 記事下書き完成のお知らせ AIが記事を作り終わった 内容を確認 → 返信で予約日時を指定
✅ 予約投稿として設定しました 予約日時の設定が完了した なし（記事IDと予約日時を確認）
📭 未処理の新着動画なし 今日は新しく記事化すべき動画がなかった なし（確認のみ）
🛑 森川様投稿済みのため、自動記事作成中断 代行業者さんが先に着手していた なし（代行業者さん側で進行中）

「下書き完成」通知に含まれる項目

「📝 記事下書き完成のお知らせ」 には、以下の情報が含まれます:

項目内容
テスト投稿バナー⚠️ これはテスト投稿です。下書きになっていますので、不要な場合は削除してください。
YouTube動画URL該当の動画リンク
Echoes記事ID / 動画ID実際にEchoesに保存された記事IDと、YouTube動画ID
■タイトルAIが生成したタイトル（先頭に「【テスト投稿】」プレフィックス付き）
■本文AIが生成した記事本文（約800〜1,100字、4ブロック構成、1 文 1 行で改行）
「不要な場合は削除してください」とは？

AI生成の品質に問題があったり、テーマが媒体に合わないと判断した場合は、 livedoor Echoes の管理画面から該当下書きを削除 してください。 この場合は予約日時の返信も不要です。Lark通知は記録としてそのまま残しておいて構いません。

「下書き完成」通知が来たときの動き方（初回の予約）

1 Botから届いた 「📝 記事下書き完成のお知らせ」 を開いて、タイトルと本文を確認する
↓
2 公開したい日時を決める
↓
3 その📝メッセージを長押し（PCではホバー）→「返信」を選択 し、必ず年から書いて 入力
@下書き予約ボット 2026/05/15 18:00
↓
✓ 数秒〜30秒で「✅ 予約投稿として設定しました」の返信が届く（v1.2 でリアルタイム化、即時応答）

「予約完了」通知の内容

✅ 予約投稿として設定しました 完了
実際のメッセージ例:
✅ 記事ID 17604 を 2028/12/30 11:20 に予約投稿として設定しました。
運用スタッフのアクション: なし。記事IDと予約日時が想定どおりかを確認するだけで完了です。

日時の書き方

必須ルール

年月日と時刻をすべて含めて入力してください。 年を省略するとシステムが正しく日時を解釈できないことがあります。

正しい書き方解釈される日時
2026/05/15 18:002026年5月15日 18:00
2026/5/15 18:002026年5月15日 18:00（0埋めなしもOK）
2026/05/15 18時2026年5月15日 18:00
2026/05/15 午後6時2026年5月15日 18:00
うまくいくと

予約が完了すると、Bot から「✅ 予約投稿として設定しました」の確認メッセージに 記事IDと予約日時が記載されて返ってきます。 livedoor 側でも該当記事のステータスが「予約投稿」になります。

うまくいかなかったら

日時が読み取れなかった場合は「⚠️ 日時を読み取れませんでした」が返ってきます。 その場合は、上の表の「正しい書き方」のいずれかの形でもう一度返信してください。

Bot からのエラー返信を見たら（v1.3 早見表）

Bot から「⚠️」付きの返信が届いた場合、メッセージの種類によって対処方法が違います。 以下に主要なパターンをまとめます。

Bot 返信の冒頭 原因 対処
⚠️ 予約日時または本文差し替えのいずれかをお送りください。 送ったメッセージに日時もマーカーも含まれていません（例: 「ありがとう」だけ送った）。 「@下書き予約ボット 2026/05/20 18:00」または「@下書き予約ボット 本文差し替え」のいずれかの形で再送してください。
⚠️ 過去の日時は指定できません。 指定した日時が現在時刻より前。タイポや古いテンプレートのコピペで起きがちです。 現在より未来の日時を指定して再送してください。
⚠️ 不正データとして入力内容を確認してください。 1 行目に予約日時を書いたのに、2 行目以降に 30 文字以上の本文が混入しています。
本文差し替えのマーカー（「本文差し替え」）を 1 行目に書き忘れた可能性が高いです。 		本文を差し替えたい場合は 1 行目に「本文差し替え」。
予約日時を設定したい場合は 1 行で日時のみ送信（本文は書かない）。
⚠️ 日時を読み取れませんでした: … 日付らしき形式はあるものの、時刻が無い・月や日の値が範囲外など、書き方が不完全。 「2026/05/20 18:00」のように、年・月・日・時刻を半角で正しく書いて再送してください。
⚠️ 本文が短すぎます（XX字 / 最低 100字） 本文差し替えで送った本文が短すぎる（100 字未満）。誤操作防止のため拒否されました。 100 字以上の本文を、マーカーの次の行から書いて再送してください。
⚠️ 返信元の通知メッセージから記事IDを特定できませんでした。 Bot 通知（📝 や ✅）ではなく、関係ないメッセージへの返信になっています。 必ず Bot から届いた通知（📝 か ✅）に直接「返信」してください。
YYYY/MM/DD HH:MM の返信が最新として処理されたため、スキップされました。 あなたが過去に同じ記事に対して送った返信が、その後のもっと新しい返信 で上書きされたため、古い返信は適用されませんでした（v1.3 で新搭載の保護機能）。 これは異常ではなく、保護のための通知です。最新の予約日時または本文だけが Echoes に反映されている状態です。アクション不要。
⚠️ Echoesへの予約反映に失敗しました
⚠️ Echoesへの本文差し替えに失敗しました		 Echoes 編集画面の操作中にエラーが発生（認証切れ、画面構造の変更、ネットワーク問題など）。 メッセージにエラー詳細とログファイル名が含まれます。 時間をおいて再送するか、Echoes 管理画面で記事 ID を直接編集して手動対応してください。 繰り返し発生する場合はシステム担当者に共有してください。
v1.3 で追加された主な保護機能

1) 同じ記事に複数返信した場合の自動整理: パソコンのスリープ復帰後の取りこぼし処理などで、古い返信が後から処理されようとした場合、 Bot が「最新の返信が既に処理されています」と通知して、古い設定での上書きを防ぎます。 予約日時と本文差し替えは別々にカウントされ、それぞれ最新のみが Echoes に残ります。

2) マーカー優先ルール: 1 行目に「本文差し替え」が書かれていれば、たとえ日時形式が同じ行に混ざっていても、 本文差し替えとして扱います（日時部分は無視）。曖昧な解釈で誤った操作が起きないようにしています。

3) 過去日時・不正データの早期検出: 過去の日時や、明らかに本文を書こうとして失敗した内容を受け取った場合は、 Echoes を一切操作せず、わかりやすい修正案内を返します。

予約日時を変更したい・やり直したいとき

変更したい記事に関する通知のうち、Lark上にある以下の2種類のどちらかに「返信」してください。 システムはどちらの通知からでも記事IDを自動で読み取れるため、結果は同じになります。

📝
候補1: 「下書き完成のお知らせ」
記事が完成した最初のタイミングで届いたメッセージ。
冒頭に「📝」が付いていて、Echoes記事ID・動画ID・タイトル・本文が含まれています。
✅
候補2: 「予約投稿として設定しました」
前回あなたが日時を返信した結果、Botから返ってきた確認メッセージ。
冒頭に「✅」が付いていて、記事IDと予約日時が含まれています。
推奨: 直近の ✅ 通知に返信するのが分かりやすい

どちらに返信しても同じ動作ですが、直近の「✅ 予約投稿として設定しました」 に 返信するほうがチャット履歴で見つけやすく、迷いません。 本文に予約日時が書かれているので、「現状を見て次の日時を決める」操作がしやすいためです。

具体的な操作手順

1 変更したい記事に関する通知をLarkで開く（📝 か ✅ のどちらか）
↓
2 そのメッセージを長押し（PCではホバー）→「返信」を選ぶ
↓
3 新しい日時を年から書いて返信
@下書き予約ボット 2026/05/16 09:00
↓
✓ 新しい「✅ 予約投稿として設定しました」が届く → 日時上書き完了

具体例：時系列でどう見えるか

19:45　ボット:　📝 記事下書き完成のお知らせ（Echoes記事ID: 17604 ほか）
20:05　あなた:　↳ @下書き予約ボット 2026/05/16 09:00
20:05直後　ボット:　↳ ✅ 記事ID 17604 を 2026/05/16 09:00 に予約投稿として設定しました。

翌朝 10:00　あなた:　↳（直近の ✅ メッセージに返信）@下書き予約ボット 2026/05/17 12:00
10:00直後　ボット:　↳ ✅ 記事ID 17604 を 2026/05/17 12:00 に予約投稿として設定しました。（上書き完了）
※ ボットの応答時間について（v1.2 改善）: v1.2 から WebSocket リアルタイム連携 に切り替わり、ボットからの確認返信は あなたが送ってから 1〜30 秒程度 で届きます。
例外: パソコンがスリープ・電源OFFになっていた場合は、復帰後の 朝7:00 または 夜19:30 の保険チェック時にまとめて処理されます。
大事なポイント

最後に送ったあなたの返信が常に有効です。 間違えても何度でも返信して上書きできます。 ただし、まったく別の記事の通知メッセージに返信してしまうと、その別の記事の日時が変わります。 必ず「変更したい記事の通知」に返信していることを確認してください。

よくある間違い

「返信」ではなく新しいメッセージとして投稿してしまうと、 システムはどの記事のことか分からず処理できません。 必ず対象の通知メッセージに対する「返信（リプライ）」の形にしてください。

5困ったとき・分からないとき

「いつもの時間に何も通知が来ない」

確認の手順
・Larkの「下書き予約ボット」のチャットを開く
・その日の19時台〜20時頃に何か投稿があるかを確認
・「新着なし」通知も「下書き完成」通知も両方ない場合は、システムが起動できていない可能性
・翌朝になっても無音ならシステム担当者へ連絡

「内容が気に入らない／書き直したい」

対処（方法は 2 通り）
方法A: livedoor Echoes の編集画面で直接修正
編集画面から本文を書き直して保存します。修正後にあらためて予約投稿を設定すれば反映されます。

方法B: Lark から「本文差し替え」で丸ごと置き換える（v1.2 新機能）
修正後の本文を Lark の返信で送ると、自動的に Echoes に反映されます。

方法B: Lark からの本文差し替え（v1.2 新機能）

「下書き完成」通知 または 「予約投稿として設定しました」通知 への返信として、 1 行目に「本文差し替え」と書き、2 行目以降に新しい本文を書く 形で送信します。 システムが Echoes 編集画面を自動操作して、本文だけを置き換えてくれます（タイトル・予約日時・カテゴリは触りません）。

返信の書き方: 
@下書き予約ボット 本文差し替え
（ここから新しい本文を貼り付け）
海外不動産投資家の宮脇さき氏が、自身のYouTubeチャンネルで「〜」と題した動画を公開した。
（中略）
最後に宮脇氏は、「〜」と動画を締めくくった。
項目仕様
マーカー文言「本文差し替え」（1 行目のみ）。「本文修正」「本文置換」は誤発火防止のため不可
本文の長さ100 字未満は拒否、500 字未満は警告付きで受理、800〜1,100 字推奨
反映先Echoes 編集画面の本文 textarea のみ。タイトル・予約日時・カテゴリは現状維持
応答時間30〜90 秒（裏で Chrome を起動して Echoes を操作するため、予約日時変更より少し時間がかかる）
バックアップ上書き前の本文は自動的に保存されるため、誤って差し替えても元に戻せます（システム担当者に依頼）
うまくいくと

ボットから「✅ 記事ID xxxxx の本文を差し替えました（XXX 字）。記事ステータスは維持されます。」が届きます。 Echoes 編集画面を開いて本文が新しい内容になっていることを確認してください。

うまくいかなかったら

本文が短すぎる場合は「⚠️ 本文が短すぎます（XX 字 / 最低 100 字）」が返ります。
Echoes 側の操作に失敗した場合はエラー詳細とログファイル名が返るので、システム担当者に共有してください。

「同じ動画について、代行業者さんと自動システムの両方から記事が出ている」

本来起きないはず

通常はシステム側がチェックして中断するため、二重投稿は発生しません。 万一発生した場合は、代行業者さんの記事を残し、システム側の記事（タイトル先頭に「テスト投稿」がついているもの）を削除してください。

6よく出てくる言葉のミニ辞典

livedoor Echoes
記事を管理する画面。下書き、予約投稿、公開などをここで行います。
下書き
まだ公開していない、保存だけされた状態の記事。
文字起こし
動画の音声を、テキスト（文章）に変換すること。livedoor 側で自動で行われます。
予約投稿
「あらかじめ決めた日時になったら自動で公開」する設定。
Lark
チャットツール。Slack や LINE と似たもの。通知の受け取りや返信に使います。
下書き予約ボット
Lark上にいる自動の「お知らせ係＋秘書」。通知を送ったり、返信を受けて予約投稿を設定したりします。
テスト投稿マーカー
動画タイトルの先頭につく「テスト投稿」の文字。システムが作ったものを見分けるための目印。
代行業者
現在 livedoor で手作業で記事を作っていただいている、外部の業者さんのこと（森川様）。
動画ID
YouTubeの動画ごとに割り振られた11桁の英数字。通知メッセージなどに含まれます。
記事ID
livedoor Echoes 側で記事ごとに割り振られる番号。通知メッセージに記載されます。

7記事作成のルール

AI が記事本文を生成する際に従っているルールの一覧です。Lark に届く下書きの内容を確認するときの チェックポイントとして使えます。詳細は prompts/article-generation.md および editorial-guidelines.md に定義されています。

1. 文字数・構成

項目仕様
本文字数800〜1,100 字（許容範囲 700〜1,200、改行文字は字数に含めない）
構成4 ブロック固定（小見出しなし、段落区切りのみ）
段落間改行\n\n（空行）
段落内改行句点「。」の直後ごとに \n（1 文 1 行）

2. 4 ブロックの中身

Block目的字数目安必須事項
Block 1 紹介文 + トレンド導入 180〜260 字 「海外不動産投資家の宮脇さき氏が、自身のYouTubeチャンネルで『[動画タイトル]』と題した動画を公開した」で開始。動画と自然に紐づくトレンド・時事を任意で 1 文。
Block 2 論点 1 + 専門用語補足 200〜320 字 「宮脇氏はまず、〜」「まず、〜」で開始。数値情報を 1 つ以上含める。初出の専門用語に 1〜2 文の補足。
Block 3 論点 2 + マス/富裕層バランス 200〜320 字 「続いて、〜」「さらに、〜」など別の接続詞で。テーマと逆側の読者層への配慮 1 文を入れる。
Block 4 締め 100〜200 字 必須パターン「最後に宮脇氏は、〜と動画を締めくくった。」

3. タイトル

必須フレーム:
【テスト投稿】海外（不動産）投資家の宮脇さき氏が[動詞][テーマ]
  • 動詞バリエーション: 指摘する / 解説 / 解説する / 解説！ / 考察！ / 明かす / 語る / 警告 / 分析する
  • テーマ部分: 数字や「」付きキャッチーフレーズ、フック語（真実／実態／闇／裏側／秘密／警鐘）を入れる
  • 文字数: 30〜50 字（プレフィックス含む）
  • 末尾「。」を付けない
  • テスト運用期間中は 【テスト投稿】 プレフィックス必須

4. 視点・文体

観点ルール
書き手の立場富裕層に詳しい専門家（第三者視点）
想定読者動画未視聴の初〜中級層、海外情報を知識として仕入れたい人
一人称「私」不使用（livedoor 媒体固有ルール）
NG 表現「思います」／「〜することができる」／「？」（リード文・本文ともに）
口語→文語〜なんですよ／〜じゃないですか／ですよね／ちょっと／すごく／やっぱり 等を文語に変換
接続詞しかし／さらに／また／そのため／なお／一方で 等を意識的に活用

5. 内容のルール

項目ルール
数値情報金額・期間・割合・統計値を 1 つ以上必ず含める
専門用語補足初出時に 1〜2 文の簡潔な補足（例:「IFA（独立系金融アドバイザー）」）。全用語ではなく 1〜2 個に絞る
トレンド要素動画公開時期と自然に紐づくもののみ Block 1 に 1 文（無理に作らない）
マス/富裕層テーマと逆側の読者層への配慮 1 文を Block 3 に。どちらかに偏らない
エンタメ性読者の好奇心を刺激する切り口を 1 つ。投資家チャンネルとしての品位は維持

6. 表記ルール（誤 → 正、19 項目）

誤正誤正
早速さっそくw笑
出来るできるとかや
◯◯する内に◯◯するうちに又また
中々なかなか事こと
身につける身に付ける為ため
いっぱいたくさん有りますあります
達たち位ほど
要はつまり等など
いいよい〜することができる〜できる
大事重要思います（第三者視点に変換 or 削除）

7. 誤字・脱字最終チェック（5 観点、出力前に必須）

観点チェック内容
A. 文字単位同じ文字の連続（「のの」「をを」）、助詞の重複、句読点連続、全角・半角混在、鉤括弧の対応
B. 漢字・送り仮名同音異義語（以外/意外、対象/対称、以降/移行）、送り仮名のゆれ
C. 固有名詞「宮脇さき」表記、国名・通貨名・金融商品名、数値・単位、引用句
D. 文構造主語の脱落、逆接の連続、1 文 80 字超は分割
E. 文字起こし整合数値・固有名詞・引用句は文字起こしと突き合わせ、Whisper 誤認識（英字略語の音訳化など）に注意

8. やってはいけないこと（NG リスト）

NG理由
AI ライター注意書きを本文やタイトルに含める
（「この記事は以下の動画を基に…AIライターが執筆しております」）		 本文・タイトルともに記述不要。当該文言は livedoor Echoes が記事公開のタイミングで自動的に動画に添付する仕様のため、AI 側で本文・タイトルに書く必要がない
小見出しの追加livedoor 媒体の既存記事フォーマットに反する
動画末尾「まとめ／コミュニティ宣伝」の流用情報重複で原稿が長くなる原因
同じ表現・情報の繰り返し文字数オーバーの原因
「自分が稼いでいる」色を出す富裕層に詳しい専門家視点を保つ
本論と関係ない箇所の詳しい説明文字数管理のため
YouTube 文字起こしの丸写し拾う情報を事前に決めてから執筆
運用スタッフの確認ポイント

Lark に届く「📝 記事下書き完成のお知らせ」を見るときに、上記ルールに沿っているかを軽く目視確認してください。 違反がある場合は「本文差し替え」マーカー付きで修正版を返信するか、Echoes 管理画面から直接修正することで対応できます。

8本番運用への移行（予定）

現在はテスト運用期間中で、「下書き保存までを自動化 + 運用スタッフが Lark から予約日時を返信」 という半自動フローで運用しています。テスト運用が終了し本番運用に移行した後は、 下書きから予約投稿までを全て自動で行う 予定です。

本番運用後のフロー（予定）

毎日 19:00
動画の検出からアップロード、文字起こし、本文生成、予約投稿の設定までを一気通貫で自動化
現在運用スタッフが行っている「Lark の通知に予約日時を返信する」操作が不要になります。 システム側で公開日時を自動的に設定して予約投稿状態にします。
処理完了後
Lark に「✅ 予約投稿として設定しました」通知が届く（詳細情報付き）
下書き完成通知ではなく、予約日時まで含めた最終的な完了通知が届く形になります。 ただし運用スタッフが 内容を確認できるよう、通知の中には以下の情報を必ず記載 します。

本番運用後の Lark 通知に含まれる情報

項目内容
Echoes 記事 IDlivedoor Echoes 側で割り振られた記事番号
YouTube リンク元になった動画の URL
件名AI が生成した最終的な記事タイトル
本文AI が生成した記事本文（全文）

これにより、運用スタッフは Lark の通知を見るだけで「いつ・どんな内容が・どこに公開予定か」が把握できます。 内容に問題がある場合は Lark から「本文差し替え」または日時変更の返信 で対応できます。

公開済み記事への本文差し替えは警告を挟む

公開済み記事の本文差し替え時の確認フロー

Lark の通知への返信で本文差し替えを指示すると、現状の仕組みでは 公開済みの記事に対しても差し替えが実行可能 です。 ただし一度公開した記事の編集は影響が大きいため、本番運用では 公開済み記事に「本文差し替え」が送られた場合、すぐには実行せず、Bot から確認メッセージを先に返す 仕様にします。

確認メッセージの例:

こちらの記事は現在すでに公開しております。本当に本文差し替えを行ってよろしいですか？

運用スタッフがこの確認メッセージに対して肯定的な返信（「はい」「OK」「実行」など）を返した場合のみ、本文差し替えが実行されます。 確認メッセージを無視（返信なし）または否定的な返信をした場合は、差し替えは行われません。

対象記事の状態と動作の違い:

記事の状態本文差し替え時の動作
下書き即時実行（従来通り）
予約投稿（公開前）即時実行（従来通り）
公開済みBot から確認メッセージ → 肯定返信を確認してから実行

本番運用に移行する前に確認が必要な事項

注意 1: 下書き段階でのチェックは行われません

本番運用への移行後は、運用スタッフが下書き内容を目視確認するタイミングは設けられません。 AI が生成した本文がそのまま予約投稿として設定され、指定日時に自動公開されます。

生成された記事に問題があった場合は、 公開前に Echoes 管理画面から直接編集するか、 Lark から「本文差し替え」または日時変更の返信で対応する運用となります。

テスト運用期間中に AI 生成の品質が安定していることを確認してから本番運用に切り替えるか、 運用開始後しばらくはサンプリングで内容確認を行うかは事前に決めておく必要があります。

注意 2: 即時公開か予約投稿（翌日公開など）かを事前に決める必要があります

本番運用に切り替えるタイミングで、公開タイミングのデフォルト値を決定しておく必要があります。

選択肢内容長所短所
即時公開 下書き作成後、すぐに公開される 動画公開直後のタイミングを逃さない 誤った内容が公開された場合の取り返しが効きにくい
翌日公開（予約投稿） 翌日の指定時刻（例: 朝 8:00）に自動公開される 万が一の問題があれば公開前に修正する余裕がある 動画公開からニュース化までに半日〜1 日のタイムラグ
当日数時間後（予約投稿） 下書き作成から例えば 2〜3 時間後に自動公開 即時性と修正余裕のバランス 運用スタッフの確認時間帯と合わせる必要がある

本番運用への切り替え時に、上記のいずれを採用するかを必ず決めて、関連スクリプト（記事生成パイプライン）の設定に反映してください。

移行のタイミング

本番運用への移行時期は、テスト運用期間中の運用結果を踏まえて改めて検討します。 切り替え時には本マニュアルの該当箇所（タスクスケジューラの設定、Lark 通知文、運用スタッフのアクション）を改訂し、 運用スタッフ全員に周知します。