動画自動告知ボット 開発日記
五条ハーレム投稿用。2026年8月（葉月）から9月15日まで、このチャットで進めた作業を時系列でまとめた。失敗、不具合、未完了の監査項目も省かない。APIキー、トークン、Webhook URL、個人を特定する設定値は載せていない。
目次
- 2026-08-02 新PCでの再開とRumble取得問題
- 2026-08-04 GitHub・ローカルの実装調査
- 2026-08-04 63言語の再実装とGitHub保全
- 2026-08-04〜05 Gemini Visionの再実装とmain統合
- 2026-08-20 EXE販売版と通知先の実運用問題
- 2026-08-22 多言語UI、複数アカウント、問い合わせ機能
- 2026-08-22 ニコニコ動画の取得方式変更
- 2026-09-05 Slack、Odysee、Twitch、ツイキャス、172言語
- 2026-09-09〜14 Facebookサムネイルと二重投稿
- 2026-09-15 認証情報の整理と販売前監査
- 次に行う購入者監査
2026-08-02 新PCでの再開とRumble取得問題
新しいPCへ移ったあと、動画自動告知ボットの復旧から始めた。最初から全SNSへ通知すると誤送信の危険があるから、外部へ一切投稿しない取得専用モードで檢査した。
Pythonファイルの構文檢査には通り、YouTubeとOdyseeからは新着を取得できた。一方でRumbleだけは取得0件だった。設定がないのではなく、チャンネルページやHTML構造の変更、対象URLの状態などを確認する必要がある状態だった。
この段階で分かったのは、PCを新しくしても「ファイルがある」だけでは復旧にならないことだ。設定UIをすぐ開けるショートカット、タスクスケジューラーによる定期実行、通知先の認証、動画サイトごとの取得を全部戻して初めて使える。ショートカットはOneDrive側ではなく、実際に使うローカルのデスクトップへ置く方針にした。
また、設定や認証の作業では、秘密情報をチャットや報告書へ貼らないルールを徹底した。ログイン、二段階認証、APIキー入力が必要なところだけ律が操作し、ボット側は値を表示・記録しない形を守る。
2026-08-04 GitHub・ローカルの実装調査
以前作ったはずの機能がGitHubにどこまで残っているかを、推測なしで調べた。対象は既定ブランチ、全ブランチ、タグ、コミット履歴、到達不能オブジェクト、ローカルのOneDriveコピー、旧作業フォルダ、配布ZIP・EXE、CodexやGeminiの作業履歴だった。
結果は少し厳しかった。GitHubにはAI司令室、GeminiのテキストAPI、OCR、EXE化の基盤、日本語・英語のロケール機構などは残っていた。でも、63言語の翻訳資源と案内文書、Gemini Visionによる画像解析本体、Discord・Slack専用通知、右クリック画像貼り付け、販売用リリース成果物が揃った完全版は残っていなかった。
63言語版は、ローカルPC、OneDrive、移行コピー、配布物、作業ログ、ごみ箱まで探したが、完全な実体は見つからなかった。言語別の翻訳文書もGUI用辞書も発見できなかった。ここは「復元できた」とは言えないので、以後は再実装として扱うことにした。
一方で、mainより40コミット進んだ古いEXE基盤featureは見つかった。ただし、これをそのままmainへ混ぜると、分離濟みの古いAI司令室などまで戻る危険がある。残っているものを全部mergeするのではなく、現在のボットに必要な部分だけ安全に選んで統合する方針を取った。
2026-08-04 63言語の再実装とGitHub保全
63言語対応は、言語を選べる一覧を置くだけでは完成しない。言語コード、表示名、OS言語の初期判定、設定保存、英語への安全なフォールバック、右から左へ書く言語の情報、画面文言の辞書、言語別の案内文書、配布ZIPへの収録まで必要になる。
そこでロケール基盤を作り直し、設定UI上部から表示言語を選べるようにした。選択した言語は再起動後も反映され、GUI辞書とクイックスタート文書も言語別に入る。最初は日本語・英語・中国語系を重点確認し、その他の言語は安全な英語フォールバックを持つ構成にした。
今回の作業では、機能追加より先に保全を優先した。過去に未pushの作業を失ったことがあったからだ。Rumble、Webhook、LINE broadcast、SNSテスト送信、一般RSS/Atom監視、設定UIアイコン、63言語辞書、63言語分の案内を、秘密情報を除外した状態で保全ブランチへ保存した。
GitHubへpushしたあとも、ローカルHEAD、追跡ブランチ、リモート上のコミット、ツリーハッシュ、主要ファイルのハッシュを照合した。mainへの強制push、reset、rebase、既存featureブランチの削除はしていない。ここで大事なのは、作ったものを「あるはず」ではなく、戻せる状態で残したことだ。
2026-08-04〜05 Gemini Visionの再実装とmain統合
Gemini Visionについても、過去の実装本体は発見できなかった。残っていた作業文書、チャットログ、AI司令室の画像添付設計、Git履歴を根拠にして、現行ボットの構造へ合う形で新規に実装した。
人工智能助手では、文字だけで質問できるのが基本だ。画面を見せた方が早い場合だけ、画像添付ボタン、クリップボード貼り付け、右クリックからの貼り付けで画像を加えられる。画像は一時ファイルに残さずメモリ上で処理し、UIが固まらないよう非同期でGeminiへ送る。APIキー未設定、認証失敗、通信失敗、画像形式の問題も、利用者に原因が分かる形で分類するようにした。
APIキーは画面に再表示せず、ログにも残さない。APIキー欄が別タブにあって分かりにくかったので、人工智能助手の画面内に入力・貼り付け・保存・設定濟み表示を用意した。画像を貼らないと相談できない作りにはせず、文章だけの相談と、必要時の画像相談の両方を使えるようにした。
Ctrl+V、右クリック、画像添付、プレビュー、画像なしの相談、APIキー未設定、無効キー、通信失敗、メモリ上の画像変換、非同期処理を檢査した。実Slack/Discord画面をGeminiで読む試験だけは、実APIキーが未設定だったため後回しにした。
8月5日には、保全ブランチとGemini Visionの復元ブランチを段階的にmainへ統合した。Rumble、Webhook、LINE broadcast、RSS、SNSテスト送信、63言語、アイコン、Gemini Visionが統合後にも残っていることを確認し、構文檢査、単体試験、配布ZIP檢査、EXE再ビルドを通した。
2026-08-20 EXE販売版と通知先の実運用問題
販売を考えた時に大きな問題になったのが、EXEの設計だった。以前の形式では、設定UIの実行ボタンが一時展開先のPython本体を外部Pythonで探す作りになっていた。開発PCでは動いても、Pythonを入れていない購入者のPCでは確実に動かない。
そこで、常駐して監視するBot本体と、設定を編集するSettingsを二本のEXEへ分離した。設定、認証情報、通知濟み履歴、ログはEXEの一時展開先ではなく、利用者ごとの永続的な保存先へ置く。販売ZIPにも二本のEXEを入れ、外部Pythonや外部ソースを前提にしない形へ直した。
同日に、X、Facebook、LinkedInの実運用上の違いも整理した。XへURLだけを送った時のカードはX側の仕様で小さくなる。YouTubeのような大きな再生プレイヤーを必ず出すことはできない。大きく見せたい場合は、サムネイル画像を添えるか、動画自体をXへネイティブ投稿する別実装が必要になる。
FacebookとLinkedInの失敗は、Make側に存在しない古いWebhook URLへ送っていたことが原因だった。単純に「5日で必ずWebhookが失効する」のではなく、シナリオに接続されていないWebhook、作り直した旧URL、接続解除濟みURLが410になる。現行Webhookへ差し替え、Makeの履歴で両方が成功することまで確認した。
2026-08-22 多言語UI、複数アカウント、問い合わせ機能
この日は、機能を増やすというより、利用者が一人で設定し、困った時に戻れる製品へ近づける作業を集中して行った。
多言語UIの混在修正
別言語を選んでも、言語選択欄だけ変わり、画面本体には日本語が残る不具合があった。原因は、設定だけ保存して、既に作られた画面部品を作り直していなかったことと、固定日本語の文字列が残っていたことだった。
言語変更時に未保存の編集を確認し、選択言語を保存してUIを自動で開き直す形に変更した。監視チャンネル、通知先、Webhook、状態、人工智能助手、Gemini APIキー、画像操作を翻訳対象へ広げた。63言語の辞書は英語の複製をやめ、静的な翻訳カタログとして収録した。製品実行時に利用者のAPIキーで翻訳サービスへ通信することはない。
ただし、機械翻訳は母語話者が校閲濟みという意味ではない。外部サービスが返すエラーはサービス側の言語のまま出る場合もある。多言語対応の範囲と、翻訳品質を保証できない範囲は分けて説明することにした。
SNS複数アカウント配信
Tumblr、Bluesky、LINE、Mastodon、Xが一つのアカウントにしか送れない問題を直した。既存の一アカウント設定は消さずMainとして引き継ぎ、サービスごとに複数の有効アカウントへ順番に送れるようにした。
設定UIから追加・無効化・全アカウントへのテスト送信ができる。保存濟みの秘密値は平文で再表示しない。設定ファイル、バックアップ、一時ファイルはGit管理と販売ZIPから外し、追加アカウントの秘密値もログ伏字の対象にした。
人工智能助手と五条ハーレムへの問い合わせ
製品内の人工智能助手で解決できなかった場合、利用者が希望した時だけ律（開発者）へ知らせる流れを作った。「解決した」「まだ困ってる（律へ知らせる）」を用意し、問い合わせ番号、回答確認、修正版番号の受け取りまで扱える。
画像、設定、ログを勝手に送らないのが前提だ。添付画像も、利用者が明示的に「添付画像も律（開発者）へ送る」を選んだ時だけ送る。画像はEXIFを落とし、サイズと容量を抑え、公開URLを作らず、開発者だけが確認できる経路に保存する。APIキー、設定ファイル、ログは問い合わせに含めない。
五条ハーレム側には問い合わせの受け口を作り、製品からの送信、保存、状態確認を檢査した。自動で修正候補や回答準備を進められるようにしても、販売版を正式更新する判断は律が行う。そこは無人化しない。
UIの文言も見直した。「律からの回答」では利用者に誰のことか分からないので、「律（開発者）」と明記した。説明は堅すぎず、人工智能は万能ではないこと、機械翻訳の質は保証できないこと、困った時は説明書を見ることを正直に伝える形へ変えた。
2026-08-22 ニコニコ動画の取得方式変更
ニコニコ動画は、設定したIDが正しいのに通知できない問題があった。原因は、以前使っていたRSS URLがRSSではなくHTMLを返す仕様になっていたことだ。HTTP 200なので一見正常に見えるが、RSS解析では0件になってしまう。
RSSが空の場合に公開ユーザーページを取得し、ページ内の公開データから動画一覧を読む方式を追加した。動画ID、タイトル、投稿日時、投稿者名、公開サムネイルを取り、ページ取得失敗や構造不一致は秘密を出さずに診断ログへ分類する。
実際のニコニコ動画を使った通知では、Tumblr、Bluesky、LINE broadcast、Mastodon、X、Facebook、LinkedIn、五条ハーレム、Discord、Slackへの到達を確認した。途中でBlueskyにimport漏れが見つかったが、修正後に個別補送まで確認した。
これはニコニコ側の公開ページ構造に依存する。将来また仕様が変われば、取得できなくなる可能性がある。その点をREADMEや人工智能助手向けの案内にも明記した。
2026-09-05 Slack、Odysee、Twitch、ツイキャス、172言語
9月5日は、通知先の見え方、動画サイトの取得、新しい対応サービス、多言語基盤をまとめて進めた。
Slackカード表示
Slackでは、ニコニコ動画の本文とURLは届いても画像カードが出ないことがあった。URLの自動展開任せでは、Slack側や動画サイト側の条件でカードが省略される。
そこで、本文とサムネイルをSlack Block Kitのカードとして明示送信するように変えた。サムネイルがない時は本文だけで送る。Rumbleのサムネイルについては、画像取得とSlack上での画像カード表示を確認した。
ただし、Slackが外部画像URLを取得できない場合は、WebhookがHTTP 200でも画像だけ表示されない可能性がある。HTTP 200は通知payloadを受理したという意味で、最終的なカード表示を完全保証するものではない。この違いは、Facebook、LinkedIn、Xなどのリンクカードにも共通する。
Odysee RSS
Odyseeでは、チャンネルIDの記号をRSS URLで正しくエンコードしていなかった。HTTP 200でも中身が空になる、かなり分かりにくい不具合だった。URL生成を修正し、実際のRSSから動画を取得できることを確認した。
OdyseeはRSS反映に時間差が出ることがある。投稿時刻がほかの動画サイトと近くても、通知が同時に届くとは限らない。即時通知を約束できない理由は、UIと説明書で伝える必要がある。
Twitchとツイキャス
Twitchでは、チャンネルURLまたは名前を登録し、公式APIからライブ開始と公開動画を監視できるようにした。ライブと動画は別の一意IDで扱い、同じ項目の重複通知を防ぐ。サムネイルも通知先へ渡す。
TwitCastingも、ライブ開始と公開録画を監視対象へ追加した。配信者URLまたはscreen IDを登録でき、非公開録画は通知しない。どちらもClient IDとSecretは設定UIから安全に入力し、保存濟み値の再表示やログ出力はしない。
Twitchもツイキャスも、公式API、認証方法、公開条件、レート制限が変更・終了すれば利用できなくなる可能性がある。対応濟みと書いて終わりにはせず、仕様変更リスクを説明書に残す。
172言語
多言語基盤は63言語から172言語へ拡張した。言語コードの重複、翻訳キー、プレースホルダー、日本語の残りを自動檢査し、言語別のGUI辞書と案内を配布物に収録した。
ただし、追加言語の多くは人工智能による自動翻訳だ。母語話者の校閲濟みではなく、自然な表現を保証できない。誤訳や不自然な文章の報告を受けて直していく前提である。また、右から左へ書く言語の画面配置は、実機で追加確認が必要な課題として残っている。
2026-09-09〜14 Facebookサムネイルと二重投稿
Facebookでは、リンクを送るだけだとサムネイルが十分に出ないことがあった。SNSのリンクカードは投稿先の仕様やキャッシュに左右される。そこで、公開サムネイルを取得してFacebookの写真投稿として送る構成を追加した。ツイキャスの実配信では、サムネイル取得からFacebook写真投稿まで成功を確認した。
同じ頃、複数の動画サイトへ近い時刻に投稿して試験したところ、Odyseeの通知だけ遅く見える場面があった。これはRSSの更新時刻と取得周期の影響で、故障と即断できない。動画サイトごとに取得方式と反映速度が違うことを、利用者が理解できる説明にする必要がある。
その後、YouTubeの同一動画がLINEとMastodonへ二重投稿され、TumblrとBlueskyでも同じ傾向が確認された。複数SNSにまたがるので、投稿先固有の障害ではなく、旧PC、古い認証、複数起動経路、別々の通知濟み台帳を疑った。
対策は二段階にした。Windows利用者で共通の通知濟み台帳を持ち、複数の記録を統合して保存する。さらに同時起動ロックを置き、手動実行・タスクスケジューラー・複数起動が同じ動画を同時に送らないようにする。
過去の通知履歴を消して帳尻を合わせることはしていない。既存の記録を読み込み、壊れにくい形で統合する設計にした。
さらに、旧PCからまだ投稿できる認証情報を遮断するため、Mastodon、Tumblr、Bluesky、LINEの認証を現行PC側へ切り替えた。新しい認証を発行しただけで終わらせず、古い認証が実際に使えなくなったことまで確認した。サービスによっては旧トークン失効の反映に時間差があるので、後から再確認も行った。
二重投稿は、利用者から見れば自動化の信頼を失う問題だ。通知数を増やすよりも、同じ動画を一度だけ正しい相手へ送ることを優先して直している。
2026-09-15 認証情報の整理と販売前監査
この日は、ソースコードではなく「購入者へ渡すEXEとZIP」を監査した。確認したのは、二本のEXEが入っていること、ZIPに設定ファイル・認証情報・通知履歴・ログ・問い合わせ履歴が混ざっていないこと、多言語資源が収録されていること、Pythonを前提にしない起動経路になっていることだ。
秘密情報については、実際の設定値とZIP内のファイルを照合し、配布物に混ざっていないことを檢査した。環境設定、利用者設定、SNS認証、実Webhook、状態ファイル、ログを同梱しないことを確認している。
一方で重要な発見もあった。9月5日に作られた配布EXE・ZIPには、その後に加えた共有台帳、同時起動ロック、TwitCasting修正がまだ反映されていない。コードを直しても、古い配布ZIPを出せば購入者には直っていない製品が届く。
だから、販売版を急いで差し替えるのではなく、修正の保存、再ビルド、秘密情報檢査、購入者目線の監査を通るまで正式更新とは扱わないことにした。
監査候補では、取得だけで通知台帳を作らないこと、Pythonなしの環境に近い起動、画面の操作が小画面で隠れないこと、初回画面や問い合わせ画面に日本語が残らないこと、ログに秘密を出さないことを確認している。ただし、実認証、実SNS送信、Gemini画像相談、設定保存後の再起動、デスクトップショートカット、タスクスケジューラーを、まっさらな購入者監査アカウントで通す試験はまだ完了していない。
次に行う購入者監査
次の目的は、開発者のPCで使えるかではなく、購入者と同じ監査アカウントで使い始められるかを確認することだ。エラーが出ることを前提に、見つけたものを再現し、原因を分け、直し、もう一度試す。
確認対象は、初回起動、設定保存、再起動、ローカルデスクトップのショートカット、定期実行、動画サイトの監視、SNS認証、テスト送信、通常通知、失敗表示、多言語、人工智能助手、問い合わせ送信、配布物の安全性である。
動画自動告知は、動画を上げた後の告知作業を減らす道具だ。だから利用者に設定の専門家であることを求めてはいけない。外部サービスの仕様変更、認証期限、リンクカードの見え方、APIの停止は完全には避けられない。その代わり、壊れた時に何が起きたか分かり、直す道筋があり、秘密を漏らさず相談できる製品にしていく。
葉月からの作業で、消えた機能を探し直し、作り直し、GitHubへ保全し、統合し、EXE化し、通知先を増やし、実際のSNSで失敗を拾った。まだ完成宣言はしない。でも「たまたま動く」段階から、「販売前に疑って確かめる」段階へ進めた。
— 律
2026-09-15 セットアップ配布に変更（v1.1.13）
共有フォルダの「作業用Codexへ_セットアップ配布の依頼.md」を受けて修正したよ。監査側のv1.1.12の日本語起動・unicodedata対策を取り込み、ZIP直下の入口をセットアップ.batにした。本体はappフォルダへ同梱。実行ユーザーのLOCALAPPDATA\Programs\VideoNotifierBotに置いて、その人のデスクトップへ設定画面のショートカットを作る。設定画面内に説明書6本と利用規約の閲覧機能を追加した。
最終ZIPで日本語・空白のある場所からの導入、再導入時の設定保持、解凍元削除後のショートカット起動、初回日本語・保存濟み英語/日本語、文書6本の読込みを確認。最終Bot EXEのダミー通知と、実BAT/VBSの終了コードも確認した。非表示で行った回帰テストは72件成功、檢証用EXEの1件はDevice Guardによる拒否、画面確認は合計3件保留。Windowsの保護設定は変えていない。
律から「操作権限を奪わず、作業を邪魔しないように後ろで」と指示されたため、その後は画面の前面化・マウス・キーボード操作をしていない。画面を出す檢証は保留し、非表示の自己檢証とファイル・プロセスの確認だけで継続した。
成果物: C:\共有\動画自動告知\v1.1.13\動画自動告知Botv1.1.13セットアップ.zip
ZIP SHA256: 276145f39908d365452f4c161a49cb4e2217eac6ada3c5367eb59a50358e4c2d
報告: C:\共有\動画自動告知\v1.1.13\修正報告.md
旧版・元の監査報告は保存。作業アカウントに作成したデスクトップショートカットの常設先も最終版へ更新濟み。実SNS投稿、実認証、AI送信、監査アカウントのタスク登録はしていない。Gitのcommit/pushもしていないよ。