1記事が公開されるまでの流れ
システムは 毎日きまった時間 に自動で動き、記事の作成から その日の夜19:00の予約投稿設定までを一気に行います。 人がボタンを押す必要も、毎回 Lark で日時を返信する必要もありません。
1日の流れ（タイムライン）
当日(JST)に投稿された動画はあえて対象外にしています。 公開後しばらくは、編集者によってタイトルが当日中に書き換えられることがあるためです。 投稿から十分な時間が経過した「前日扱い」になってから記事化することで、タイトル不整合のリスクを避けています。
アップロードの直前にもう一度 Echoes を確認し、同じ動画の記事がすでにある場合は二重投稿を防ぐため処理を中断 します（詳しくは 3. 二重投稿を防ぐしくみ）。
同じ実行で複数本を作成したときは、公開日時の古い順に 19:00 → 19:30 → 20:00 … と30分ずつずらして予約します。
通常は このまま19:00の公開を待つだけで完了 です。 内容や時間を直したいときだけ、この通知に返信して対応します（5. 修正・困ったとき）。
これにより、Echoes にログインできないスタッフでも、前日19:00の予約投稿が実際に公開されたかをURLから確認 できます。 詳しくは 4. Lark通知の種類と対応 の「📰 前日公開分の確認」を参照してください。
予約投稿の設定にはPCが起動している必要があります。
PCが止まっていて 予約時刻（19:00）を過ぎてしまった場合 は、公開せず 「下書き」で保留 し、
Lark に 予約時刻を過ぎたため下書きで保留しました と通知します。
その場合だけ、Lark 返信で公開日時を指定してください（例: @下書き予約ボット 2026/06/02 19:00）。
動画が公開された当日中に記事化することはありません。 当日投稿はタイトル変更が入る可能性があるため、必ず前日扱いになってから記事化されます。 翌日の11:05に、前日と前々日の動画をまとめてチェックする仕組みです。
2新しい動画がない日はどうなるか
動画は毎日アップされるとは限りません。新しい動画が見つからなかった日も、システムは 必ずLarkに「今日はありませんでした」のお知らせを送ります。 無音にはなりません。
（YouTube側に動画はあっても、自動記事化の対象となる未処理の動画はゼロという意味です。当日(JST)に投稿された動画はタイトル確定待ちのため対象外）
次回のチェックは明日 11:05 です。
YouTubeに動画が公開されていても、すでに代行業者さんが記事を作っていたり、 過去にこのシステムが記事化済みだったりする動画は「処理済み」扱いです。 通知の「動画は見つかりませんでした」は、新しく記事化すべき動画がなかったという意味です。
なぜ「ありません」通知を出すのか
毎日決まって何らかのメッセージが届くことで、 「システムは今日もちゃんと動いた」とひと目で確認できます。
📰 前日公開分の確認 の通知は、新着動画の有無に関わらず 毎日 届きます。 前日に公開された記事があればその一覧（公開URL付き）が、なければ「前日に公開された記事はありませんでした」が送られます。
もし 午前中になっても「📰 前日公開分の確認」も、「✅ 予約投稿を行いました」も「📭 新着なし」も、何も届かなかった日 は、 システムが止まっている可能性があります。 その日のうちに何も来ていなければ、システム担当者にひと声かけてください。
3二重投稿を防ぐしくみ
本番運用では、記事は AIによる自動作成に完全移行 しています。 タイトル先頭の「テスト投稿」マーカーは付かなくなり、AIが生成した正式なタイトルでそのまま登録されます。 その上で、同じ動画の記事を二重に作ってしまわないための安全装置 が常に働いています。
最優先ルール：すでにある記事を絶対に上書きしない
すでに Echoes に記事が存在する動画に、システムが新たに記事を作ることはありません。 既存の記事（誰が作ったものであっても）を壊さないことが常に最優先です。
アップロード直前の再チェック
システムは動画をアップロードする直前に、もう一度 Echoes をチェックします。 そのとき 「同じ動画がすでに Echoes に登録されている」 ことを見つけた場合は、 二重投稿になるのを避けるため すぐに処理を中断 し、Lark に通知します。
このときLarkに届く通知
YouTubeタイトル: （該当する動画名）
Echoes側に同じ動画の既存記事を検知したため、
二重投稿を防ぐために自動処理をスキップしました。
テスト運用期間（〜2026年5月31日）は、代行業者さんの手作業とAIの自動作成を並行運用していたため、 タイトル先頭に テスト投稿 マーカーを付けて両者を区別していました。 本番運用ではこのマーカーは廃止 され、AIが正式タイトルで登録します。 二重投稿を防ぐ再チェックのしくみだけが、引き続き安全装置として残っています。
4Lark通知の種類と対応
本番運用で Lark に届く主な通知を、見出しの文言で見分けられるようにまとめました。 多くの通知は「確認するだけ」で完了 し、返信が必要なのは限られた場合だけです。
| 通知の見出し（冒頭） | 意味 | 運用スタッフのアクション |
|---|---|---|
| 記事の予約投稿を行いました （毎日の主役・絵文字なし） |
AIが記事を作り、その日の19:00（複数本は19:30…）に予約投稿を設定した | 内容・タイトル・予約日時を確認。直したいときだけ返信 |
| 📰 前日公開分の確認 | 前日（JST）に公開された記事の一覧。公開URL・公開時刻・記事ID付き | URLを開いて公開を確認（ログイン不要）。アクションは基本なし |
| 📭 未処理の新着動画なし | 前日・前々日（JST）に新しく記事化すべき動画がなかった（当日投稿はタイトル確定待ちのため対象外） | なし（確認のみ） |
| 🛑 既存記事を検知したため中断 | 同じ動画の記事がすでに Echoes にあり、二重投稿を防ぐため中断した | なし（見守り。必要なら既存記事を確認） |
| ⚠️ 予約時刻を過ぎたため下書きで保留しました | PC停止などで19:00を過ぎ、予約できず下書きで止めた | 返信で公開日時を指定（例: 2026/06/02 19:00） |
| ✅ 予約投稿として設定しました | あなたが日時を返信したことを受けて、Botが設定を完了した返信 | なし（記事IDと予約日時を確認） |
| 🔑 再ログイン関連の通知 | ログイン期限の予告、またはセッション切れの警告 | 必要に応じて再ログイン（8. ログイン維持・メンテナンス） |
「予約投稿を行いました」通知に含まれる項目
本番運用の主役となる 「記事の予約投稿を行いました」 通知には、以下の情報が含まれます。 見出しに「テスト投稿です」のバナーは付きません。
| 項目 | 内容 |
|---|---|
| YouTube動画URL | 該当の動画リンク |
| Echoes記事ID / 動画ID | 実際にEchoesに保存された記事IDと、YouTube動画ID |
| 予約投稿日時 | 予約投稿日時：◯月◯日 ◯時◯分 の形式（例: 6月1日 19時0分） |
| ■タイトル | AIが生成した正式なタイトル（「テスト投稿」プレフィックスなし） |
| ■本文 | AIが生成した記事本文（約800〜1,100字、4ブロック構成、1 文 1 行で改行） |
AI生成の品質に問題がある、テーマが媒体に合わない、といった場合は、公開（19:00）までに対応します。 Lark から「本文差し替え」「タイトル差し替え」または日時変更で返信 するか、 livedoor Echoes の管理画面から直接修正・削除 してください（5. 修正・困ったとき）。 公開を取りやめたい場合は、Echoes で該当記事を下書きに戻すか削除してください。
タイトルと本文の内容が食い違っていないか（タイトルの数字・固有名詞・主張が本文で裏付けられているか）は、 記事の生成時に AI が意味ベースで自己チェック しています。言い換えや表現の分割も考慮した確認のため、 従来あった「キーワードが本文に見当たりません」という機械的な完全一致の警告は廃止しました。
※ 自動チェックは万全ではありません。タイトルと本文の最終確認は、これまで通り Lark 通知の ■タイトル と ■本文 を見比べてお願いします。
📰 前日公開分の確認（ログイン不要で公開チェック）
毎日の実行のはじめに、前日（JST）に公開された記事の一覧 が Lark に届きます。 各記事の 公開URL（news.livedoor.com）・公開時刻・Echoes記事IDが載っているので、 Echoes にログインできないスタッフでも、前日19:00の予約投稿が実際に公開されたかをURLから確認 できます。
1. （記事タイトル）
公開時刻: 19:00 Echoes記事ID: 17604
https://news.livedoor.com/article/detail/00000000/
公開日時を変えたいとき・保留になったときの返信
本番運用では公開日時は自動で19:00に設定されるため、通常は返信不要 です。 返信が必要なのは、次のような場合です。
- 自動設定された19:00とは別の日時で公開したいとき（前倒し・後ろ倒し）
- 「⚠️ 予約時刻を過ぎたため下書きで保留しました」 が届いたとき（PC停止などで19:00を過ぎた場合）
どちらの場合も、該当記事の通知（「記事の予約投稿を行いました」など）に「返信」 して、 公開したい日時を 必ず年から 書いて送ります。
@下書き予約ボット 2026/06/02 19:00
「予約完了」通知の内容
日時の書き方
年月日と時刻をすべて含めて入力してください。 年を省略するとシステムが正しく日時を解釈できないことがあります。
| 正しい書き方 | 解釈される日時 |
|---|---|
2026/05/15 18:00 | 2026年5月15日 18:00 |
2026/5/15 18:00 | 2026年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 からのエラー返信を見たら（早見表）
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 を直接編集して手動対応してください。 繰り返し発生する場合はシステム担当者に共有してください。 |
1) 同じ記事に複数返信した場合の自動整理: パソコンのスリープ復帰後の取りこぼし処理などで、古い返信が後から処理されようとした場合、 Bot が「最新の返信が既に処理されています」と通知して、古い設定での上書きを防ぎます。 予約日時と本文差し替えは別々にカウントされ、それぞれ最新のみが Echoes に残ります。
2) マーカー優先ルール: 1 行目に「本文差し替え」が書かれていれば、たとえ日時形式が同じ行に混ざっていても、 本文差し替えとして扱います（日時部分は無視）。曖昧な解釈で誤った操作が起きないようにしています。
3) 過去日時・不正データの早期検出: 過去の日時や、明らかに本文を書こうとして失敗した内容を受け取った場合は、 Echoes を一切操作せず、わかりやすい修正案内を返します。
予約日時を変更したい・やり直したいとき
変更したい記事に関する通知のうち、Lark上にある以下の2種類のどちらかに「返信」してください。 システムはどちらの通知からでも記事IDを自動で読み取れるため、結果は同じになります。
見出しは「記事の予約投稿を行いました」で、Echoes記事ID・動画ID・予約投稿日時・タイトル・本文が含まれています。
冒頭に「
✅」が付いていて、記事IDと予約日時が含まれています。
どちらに返信しても同じ動作ですが、直近の「✅ 予約投稿として設定しました」 に 返信するほうがチャット履歴で見つけやすく、迷いません。 本文に予約日時が書かれているので、「現状を見て次の日時を決める」操作がしやすいためです。
具体的な操作手順
@下書き予約ボット 2026/05/16 09:00
具体例：時系列でどう見えるか
13:00 あなた: ↳ @下書き予約ボット 2026/06/03 09:00 （19:00ではなく翌朝9:00に変更したい）
13:00直後 ボット: ↳ ✅ 記事ID 17604 を 2026/06/03 09:00 に予約投稿として設定しました。
翌日 10:00 あなた: ↳（直近の ✅ メッセージに返信）@下書き予約ボット 2026/06/03 12:00
10:00直後 ボット: ↳ ✅ 記事ID 17604 を 2026/06/03 12:00 に予約投稿として設定しました。（上書き完了）
例外: パソコンがスリープ・電源OFFになっていた場合は、復帰後の 朝7:00 の保険チェック時にまとめて処理されます。
最後に送ったあなたの返信が常に有効です。 間違えても何度でも返信して上書きできます。 ただし、まったく別の記事の通知メッセージに返信してしまうと、その別の記事の日時が変わります。 必ず「変更したい記事の通知」に返信していることを確認してください。
「返信」ではなく新しいメッセージとして投稿してしまうと、 システムはどの記事のことか分からず処理できません。 必ず対象の通知メッセージに対する「返信（リプライ）」の形にしてください。
5修正・困ったとき
「いつもの時間に何も通知が来ない」
・その日の11時台〜12時頃に何か投稿があるかを確認
・「📰 前日公開分の確認」も「記事の予約投稿を行いました」も「📭 新着なし」も、何も来ていない場合は、システムが起動できていない可能性
・その日のうちに無音ならシステム担当者へ連絡
「内容が気に入らない／書き直したい」
編集画面から本文・タイトルを書き直して保存します。修正後にあらためて予約投稿を設定すれば反映されます。
方法B: Lark から「本文差し替え」で丸ごと置き換える
修正後の本文を Lark の返信で送ると、自動的に Echoes に反映されます。
方法C: Lark から「タイトル差し替え」で置き換える
タイトルだけを変更したいときに使います。返信で新しいタイトルを送ると、本文・予約日時には触れずタイトルだけ書き換えてくれます。
方法B: Lark からの本文差し替え
「記事の予約投稿を行いました」通知 または 「予約投稿として設定しました」通知 への返信として、 1 行目に「本文差し替え」と書き、2 行目以降に新しい本文を書く 形で送信します。 システムが Echoes 編集画面を自動操作して、本文だけを置き換えてくれます（タイトル・予約日時・カテゴリは触りません）。
@下書き予約ボット 本文差し替え （ここから新しい本文を貼り付け） 海外不動産投資家の宮脇さき氏が、自身のYouTubeチャンネルで「〜」と題した動画を公開した。 （中略） 最後に宮脇氏は、「〜」と動画を締めくくった。
| 項目 | 仕様 |
|---|---|
| マーカー文言 | 「本文差し替え」（1 行目のみ）。「本文修正」「本文置換」は誤発火防止のため不可 |
| 本文の長さ | 100 字未満は拒否、500 字未満は警告付きで受理、800〜1,100 字推奨 |
| 反映先 | Echoes 編集画面の本文 textarea のみ。タイトル・予約日時・カテゴリは現状維持 |
| 応答時間 | 30〜90 秒（裏で Chrome を起動して Echoes を操作するため、予約日時変更より少し時間がかかる） |
| バックアップ | 上書き前の本文は自動的に保存されるため、誤って差し替えても元に戻せます（システム担当者に依頼） |
ボットから「✅ 記事ID xxxxx の本文を差し替えました（XXX 字）。記事ステータスは維持されます。」が届きます。 Echoes 編集画面を開いて本文が新しい内容になっていることを確認してください。
本文が短すぎる場合は「⚠️ 本文が短すぎます（XX 字 / 最低 100 字）」が返ります。
Echoes 側の操作に失敗した場合はエラー詳細とログファイル名が返るので、システム担当者に共有してください。
方法C: Lark からのタイトル差し替え
「記事の予約投稿を行いました」通知 または 「予約投稿として設定しました」通知 への返信として、 1 行目に「タイトル差し替え」と書き、2 行目に新しいタイトルを書く 形で送信します。 システムが Echoes 編集画面を自動操作して、タイトルだけを書き換えてくれます（本文・予約日時・カテゴリは触りません）。
@下書き予約ボット タイトル差し替え 海外不動産投資家の宮脇さき氏が解説する「新タイトルをここに書く」
| 項目 | 仕様 |
|---|---|
| マーカー文言 | 「タイトル差し替え」（1 行目のみ）。「タイトル修正」「タイトル変更」は誤発火防止のため不可 |
| タイトルの長さ | 15 字未満は拒否、80 字超は拒否。実際の記事タイトルは 31〜79 字（平均 50 字）です |
| 反映先 | Echoes 編集画面のタイトル入力欄のみ。本文・予約日時・カテゴリ・公開ステータスは現状維持 |
| 応答時間 | 30〜90 秒（裏で Chrome を起動して Echoes を操作するため） |
| バックアップ | 上書き前のタイトルは自動的に保存されるため、誤って差し替えても元に戻せます（システム担当者に依頼） |
| プレフィックス | 本番運用では「テスト投稿」プレフィックスは使いません。送信したタイトルがそのまま保存されます |
ボットから「✅ 記事ID xxxxx のタイトルを差し替えました（XX 字）。記事ステータスは維持されます。」が届きます。 Echoes 編集画面を開いてタイトルが新しい内容になっていることを確認してください。
タイトルが短すぎる場合は「⚠️ タイトルが短すぎます（XX 字 / 最低 15 字）」、長すぎる場合は「⚠️ タイトルが長すぎます（XX 字 / 最大 80 字）」が返ります。
送信したタイトルはそのまま Echoes に保存されます（本番運用ではプレフィックスは不要です）。
本文差し替えと同様に、公開済みの記事に対してタイトル差し替えを送ると、ボットが 「本当にタイトル差し替えを行ってよろしいですか？」 と確認を返します。 「はい」「OK」など肯定的に返信すると実行、「いいえ」「キャンセル」で中止になります。30分以内に返信がなければ自動的にキャンセル扱いです。 公開済み記事のタイトル変更は SEO や SNS シェア、RSS 配信に影響するため、慎重にお願いします。
「同じ動画について、記事が二重に出ている」
通常はシステム側がアップロード直前にチェックして中断するため、二重投稿は発生しません（3. 二重投稿を防ぐしくみ）。 万一発生した場合は、内容のよい方を1件だけ残し、もう一方を Echoes の管理画面から削除してください。 判断に迷う場合はシステム担当者に共有してください。
6よく出てくる言葉のミニ辞典
- livedoor Echoes
- 記事を管理する画面。下書き、予約投稿、公開などをここで行います。
- 下書き
- まだ公開していない、保存だけされた状態の記事。
- 文字起こし
- 動画の音声を、テキスト（文章）に変換すること。livedoor 側で自動で行われます。
- 予約投稿
- 「あらかじめ決めた日時になったら自動で公開」する設定。本番運用では作成当日の19:00に自動設定されます。
- 前日公開分の確認
- 前日（JST）に公開された記事を、公開URL付きで毎日 Lark にお知らせする通知。ログインなしで公開を確認できます。
- Lark
- チャットツール。Slack や LINE と似たもの。通知の受け取りや返信に使います。
- 下書き予約ボット
- Lark上にいる自動の「お知らせ係＋秘書」。通知を送ったり、返信を受けて予約投稿日時を変更したりします。
- テスト投稿マーカー
- テスト運用期間中だけ動画タイトルの先頭に付いていた「テスト投稿」の文字。本番運用では使いません（廃止）。
- 代行業者
- テスト運用期間中、livedoor で手作業の記事作成を担っていた外部の業者さん（森川様）。本番運用ではAIによる自動作成に移行しています。
- 動画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. タイトル
タイトルは記事の入り口で、読者がクリックするかどうかを決める一番大事な部分です。 このチャンネルでは、見出しの形が決まっています。
海外（不動産）投資家の宮脇さき氏が[動詞][テーマ]
例:
海外不動産投資家の宮脇さき氏が解説する「過去80年で100%的中」した指標が示す2026年の世界金融危機
※ 本番運用では先頭に「テスト投稿」プレフィックスは付きません。
※ 以下の目安は、これまでに公開された 325件のタイトルを見直して導いたものです。 参考にしていただくと、自然と「いつもの感じ」のタイトルになります。
気をつけたいポイント A: 「解説」「警鐘」ばかりにならないようにする
タイトルの真ん中にある動詞（解説／警鐘／語る…など）は、ついつい 「解説」と「警鐘」ばかりになりがちです。実際、これまでの記事の 6 割近くはこの 2 つで占められていました。 同じ動詞ばかりが続くと、Lark の通知一覧や記事リストを見たときに「またこれか」と単調な印象になります。
目安: 直近 3 記事と同じ動詞は避けて、別のものを使ってみる。 動画の内容に合うのが大前提なので、無理に変える必要はありませんが、選択肢として下のリストを意識すると幅が出ます。
（頭に「徹底」を付けて「徹底解説」「徹底警告」「徹底分析」とすることもあります）
新しい記事タイトルを AI が考えるときは、直近 5 記事のタイトルが AI にも見えるようにしています。 AI は「同じ動詞が続いていたら別の動詞を選ぼう」と意識しますが、 動画の内容と合うのが一番大事なので、必ずしも毎回違う動詞になるとは限りません。 違和感のあるタイトルになっていたら、「タイトル差し替え」機能で書き直していただいて大丈夫です。
気をつけたいポイント B: 「鉤括弧」と「数字」が入っていると目を引く
過去のタイトルを見ると、10件のうち9件以上で 鉤括弧「 」 が使われています。 動画の中の印象的なフレーズを切り出すと、それだけでクリックしたくなる引力が生まれます。
また、具体的な数字（年・倍・％・選など）が入っていると説得力が増します。 動画で出てきた数字を拾えるなら積極的に入れたいところです。
● 海外不動産投資家の宮脇さき氏が指摘する日本の IFA の闇 「利益相反の構造的欠陥」
● 海外不動産投資家の宮脇さき氏が紐解く中東戦争の知られざる背景… かつて同盟国だったイランとイスラエル
気をつけたいポイント C: 長さは 40 〜 60 文字くらいが読みやすい
過去のタイトルの 約 8 割が、この長さ（プレフィックス含む）に収まっています。 短すぎると物足りなく、長すぎると一覧で途切れてしまいます。
- 40 文字未満: ちょっと物足りない（中身を伝えきれていない可能性）
- 40 〜 60 文字: ちょうどよい（おすすめ）
- 60 文字超: 長め。一覧表示で末尾が切れることがあるので、なるべく避ける
気をつけたいポイント D: 「！」は使いすぎないように
「解説！」「警鐘！」のように 「！」（感嘆符）が入ったタイトルは、これまでに 4 割ほどありました。 強調できる便利な記号ですが、3 記事続けて「！」付きにすると同じテンションが続いて単調に見えます。 前後の記事と見比べて、たまには付けない選択肢も持つようにしましょう。
その他のお願い
- タイトルの末尾に「。」を付けない（リード文の文末とは扱いが異なります）
- 本番運用では先頭の
【テスト投稿】プレフィックスは 付けません（AIが正式タイトルでそのまま登録します）
AI が作ったタイトルが「ちょっと違うな」と感じたら、Lark から 「タイトル差し替え」 で書き直せます。 詳しくは 5. 困ったとき・分からないとき の「方法C」をご覧ください。
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 に届く「記事の予約投稿を行いました」通知を見るときに、上記ルールに沿っているかを軽く目視確認してください。 違反がある場合は、公開（19:00）までに「本文差し替え」「タイトル差し替え」マーカー付きで修正版を返信するか、Echoes 管理画面から直接修正することで対応できます。
8ログイン維持・メンテナンス
現在は本番運用です。記事の作成から 作成当日の日本時間19:00の予約投稿設定までを全て自動 で行います （複数本は 19:00 → 19:30 → 20:00 … と30分ずつずらして予約）。 タイトル先頭の「テスト投稿」マーカーは付きません。日々の流れは 1. 記事が公開されるまでの流れ を参照してください。
知っておきたい運用上の注意
本番運用では、人が下書き内容を必ず確認する関門は設けられていません。 AI が生成した本文がそのまま予約投稿として設定され、19:00 に自動公開されます。
そのため、Lark に届く「記事の予約投稿を行いました」通知で内容を確認し、問題があれば 公開（19:00）までに Echoes 管理画面で直接編集するか、 Lark から「本文差し替え」「タイトル差し替え」または日時変更の返信で対応してください。 翌日の「📰 前日公開分の確認」で、公開された記事を事後確認することもできます。
動画が YouTube に投稿された当日（JST）中は記事化の対象になりません。 公開直後はタイトル変更が当日中に入る可能性があるため、検出は 翌日の11:05（前日扱いになってから）に行われます。 結果として、動画公開から記事公開までは最短でおよそ1日〜1.5日（投稿時刻と19:00公開により変動）になります。
公開済み記事への本文・タイトル差し替えは確認を挟む
下書き・予約投稿（公開前）の記事は、本文差し替え・タイトル差し替えがそのまま即時実行されます。 一方、すでに公開済みの記事 に差し替えを送ると、影響が大きいため Bot が先に確認メッセージを返します。
確認メッセージの例:
肯定的な返信（「はい」「OK」「実行」など）をした場合のみ実行されます。 否定的な返信、または30分以内に返信がない場合は、差し替えは行われません（自動キャンセル）。 公開済み記事の編集は SEO や SNS シェア、RSS 配信に影響するため、慎重にお願いします。
| 記事の状態 | 差し替え時の動作 |
|---|---|
| 下書き | 即時実行 |
| 予約投稿（公開前） | 即時実行 |
| 公開済み | Bot から確認メッセージ → 肯定返信を確認してから実行 |
ログインの維持と再ログイン（最重要）
自動投稿は livedoor Echoes へのログインが有効であることが前提です。ログイン情報（sessionid）は 約14日で失効します（毎日の自動実行では延長されません）。失効すると自動投稿が止まります。
そのため、以下の通知が Lark に届きます:
| 通知 | 意味 / アクション |
|---|---|
| まもなく再ログインが必要です（あと約N日） | 失効の3日前から予告。余裕のあるときに再ログインしてください |
| ログインセッションが切れています | 失効済み。その日の自動投稿は実行されていません。早めに再ログインを |
再ログイン手順（PCのPowerShellで実行）:
node scripts/login.js
見えるブラウザが開きます。ブランドアカウント「120 原田さん YouTube」を選択してログインし、 記事一覧が表示されたらターミナルで Enter を押してください。これで新たに約14日間有効になります。