毎朝7分、
数値を残す習慣をつくる。
X投稿のエンゲージメント数値を、毎朝Notionに手動転記するための運用マニュアル。シナリオ①(Notion→Buffer→X)で投稿された前日分の数値を、Buffer Sent画面とX本体から拾って記録します。
数値の取得元はBuffer Sent画面とX本体。Notionが記録の中心。
このマニュアルの位置づけ
シナリオ②(投稿の数値取得 → Notion記録)を手動転記運用で行うための手順書です。
初回セットアップ(再現用)
以下は構築時に完了済み。再現や確認が必要な場合のみ参照。
Notion DB の追加カラム
「X投稿管理データベース」に以下2つのカラムを追加済み。
%付きで表示します。Buffer表示が 1.23% なら、Notionには 1.23 と入力するだけでOK。0.0123 のように小数変換しないこと。
Notion ビュー「数値転記待ち」
「X投稿管理データベース」内に専用ビューを作成済み。未記録の投稿だけが表示される。
iOS リマインダー & Buffer アプリ
毎朝の作業をフックするリマインダーと、スマホで数値を確認するためのBufferアプリ。
転記の7ステップ
7:00の通知から完了確認まで、所要時間は1〜2分。
運用ルール一覧
迷ったときの判断基準。
うまくいかないときに見るところ
よくある詰まりポイントと対処法。
Q「数値転記待ち」ビューに行が表示されない
投稿ステータスが「投稿済み」になっていない可能性。メインビューで該当投稿のステータスを確認する。シナリオ①のMakeが「投稿済み」に更新するはずなので、これが効いていない場合はシナリオ①側の問題。
または、既に転記済み(=フィルタ条件を満たさない)の場合は表示されないのが正常な挙動。
Q数値を入力しても消えない
いいね数を 0 と入力する代わりに空欄のままになっている可能性。0 と明示入力すること。または、入力が確定していない可能性もある。セルの外側をタップしてフォーカスを外すか、行を開いた詳細画面で入力する。
Q入力した数値が確定せずに消える
これは多くの場合、入力した瞬間にビューのフィルタから外れて行が消える正常動作。メインの「テーブルビュー」タブに切り替えて、データが保存されているか確認する。本当に保存されていない場合は、行を開いた詳細画面で入力するのが確実。
QBuffer Sent画面で過去投稿が見つからない
Bufferの保持期間を超えている可能性。スマホ版で見つからない場合は、PCのブラウザ版 (https://publish.buffer.com/sent) でも確認。それでも無い場合はその投稿の数値はスキップ。
QNotion ビューの並びがおかしい
ソートが解除されている可能性。ビュー設定 → 並べ替え → 投稿予定日時 降順 を再設定する。
Q投稿URL欄に貼り付けても「無効」と出る
カラムの型が「数値型」になっている可能性。カラムヘッダーを右クリック → プロパティを編集 → 種類を URL に変更する。
なぜこの運用にしたか
将来見直すときの判断材料。
Qなぜ24時間後に取得するか
X投稿のエンゲージメントは投稿後24時間でほぼ確定する。それ以降の伸びは緩やか。24時間ルールはシンプルで運用負荷が低く、毎日同じ時刻に作業すれば自然に「前日分」を拾える。
Qなぜフォロワー数を毎日記録するか
投稿ごとの数値ではなく「その日のスナップショット」として記録する。日次推移を追えるので、伸びている期間と落ちている期間を可視化できる。同じ投稿に紐付く値ではない点に注意し、時系列分析で使う。
Qなぜ Buffer の Eng. Rate を自前計算しないか
Bufferの計算定義は非公開で、分母にプロフィールクリック等を含む可能性がある。Notion で (いいね+リプライ+リポスト)÷インプレッション×100 の数式を組むと、Buffer表示値とズレて混乱する。Buffer表示値をそのまま転記するのが堅実。
Qなぜ手動運用を選んだか
シナリオ②の自動化(Make + X API)を試行したが複数の障害で断念。Make公式のX/Twitterモジュールは2025年5月廃止、HTTPモジュールはOAuth 1.0a非対応、OAuth 2.0に切り替えてもMake側で oauth/wait: Not found エラーで Connection 作成が完了しなかった。手動転記は1日2〜3分の負荷で済み、データ取得の確実性が高い(API障害の影響を受けない)。詳細は phase2_x_direct_attempt_log.md 参照。
- 7:00 のリマインダー通知をタップした
- Notion「数値転記待ち」ビューを開いた
- 該当行をタップして詳細画面を開いた
- Buffer Sent画面で5項目の数値を確認した
- いいね数・リプライ数・リポスト数を転記した(0なら
0を明示入力) - インプレッション数を転記した
- エンゲージメント率を転記した(Buffer表示そのまま)
- X本体でフォロワー数を確認して転記した
- 気づきがあれば「気づき」欄にメモした
- 詳細画面を閉じ、ビューから行が消えたことを確認した
関連ドキュメント
本マニュアルと関連する他のプロジェクトファイル。
配信予約したら、
勝手にアーカイブ。
専用Gmailアドレスで受信→毎日22時+Mac起動時に自動でObsidianに保存。一度仕掛ければ、もう二度とコピペ作業はいりません。実装で実際にぶつかった問題の解決策も全部この中に。
なぜこの設計なのか
最初は「メインのGmailにフィルタを作って絞り込む」案でした。でも、メルマガ配信元から登録通知・コメント返信・Zoom申し込み等が同じFromアドレスで届いているので、「配信メルマガ本体だけを完璧に絞り込む」ことがほぼ不可能。だから方針転換。
仕組みの全体像
この仕掛けが裏で何をしているか。流れがわかると、どこかで止まったときに自分で原因を切り分けられます。
10ステップで、仕掛け完了。
上から順に進めれば60〜90分で完成します。途中でつまずきやすいポイントは★印で警告しています。
つまずいたら、ここを。
実装時に実際に発生したエラーと、その解決策。
UnicodeEncodeError: ‘ascii’ codec…
標準imaplibは日本語ラベル名を扱えない。
imapclientを使う(本マニュアル通りに作っていれば発生しない)。
SELECT command error: BAD
ラベル名が見つからない、または書式不一致。
下記コマンドで全ラベル名を確認し、config.jsonに完全一致(大文字小文字含む)で書く:
externally-managed-environment
HomebrewのPythonにシステム直下でpip installしようとした。
必ずvenvを作って、その中でpip install。Step5の手順通りに。
app_password length が16以外
16桁にスペースが含まれている、または余計な文字が入っている。
nano config.jsonで開き、app_password行のスペースをすべて削除。16文字きっかりに。
JSONDecodeError
config.jsonの構文ミス(カンマ抜け、ダブルクオート抜け、{}重複等)。
cat config.jsonで中身を見て、Step7のテンプレと比較。心配ならファイルを削除して作り直し。
launchdが22時に動かない
22時にMacがスリープ・電源オフだった。
RunAtLoad: trueを入れていれば、次のMac起動時に自動実行されて取りこぼし回収。手動なら cd ~/myasp-archive && source venv/bin/activate && python3 archive.py。
登録通知などが混じる
Gmailフィルタの絞り込みが甘い。
件名の条件を 『 に絞ると配信メルマガのみに。それでも混じる場合はObsidianで手動削除。
『5.6』が件名に二重に付く
登録通知などは件名にすでに『◯.◯』が含まれている。
本マニュアルのarchive.pyは件名に『◯.◯』があれば追加付与しない仕様。古いコードを使っているなら最新版に書き換え。
もしアプリパスワードが漏れたら
チャットや投稿に誤って貼ってしまった場合の緊急対応。
アプリパスワード管理ページ で該当エントリを削除。これで漏れた16桁は即時無効。その後、新規発行してconfig.jsonを更新。
停止・再開・手動実行
必要なときに見るコマンド集。
Notionで管理、
Bufferで安全にX投稿。
Makeを初めて使う人向けの、Notion投稿管理データベースとX投稿運用の構築マニュアル。手順通りに進めれば、初期設定から運用開始まで到達できます。
投稿管理の中心はNotion。Makeは中継役、XへはBuffer経由で安全に。
なぜMakeから直接Xに投稿しないのか。
XのAPI制限や仕様変更の影響を避けるため、Bufferを中継します。Buffer経由にすることでX API直連携の不安定さを回避し、投稿後の状態(Queue/Sent/Error)も一覧で追えます。
・投稿予約がしやすい
・投稿後の状態をBufferのSent/Errorで確認できる
・X以外のSNSにも展開しやすい
・Make側の設定が複雑になりにくい
・誤投稿リスクを下げやすい
初期は Now: No(下書き保存)で動作確認し、安定したら Now: Yes / Post immediately(即投稿)に切り替えるのがおすすめ。本マニュアルの推奨は Lv.2(半自動)で安定させてから Lv.3(自動投稿)に移行 です。
Makeアカウントを作って、初期設定を済ませる
登録時の質問6つに答えればセットアップ完了。各画面で何を選ぶか、なぜそれを選ぶかを順番に説明します。
Notionに投稿管理データベースを作る
投稿の中心はNotion。Makeに渡す前提のデータベース設計を、項目とステータスで固めます。
MakeでScenarioを作る(Notion → Buffer)
最初のScenarioは1本だけ。Notionで「投稿待ち」になった投稿をBufferに送り、Notionのステータスを更新する流れを作ります。
「Run once」で1件だけテストする
本番運用の前に、必ず1件だけ流して全モジュールが正常に動くか確認します。エラーが出たら次のモジュールに進ませません。
本番運用に切り替える(Scheduleを起動)
Run onceでの動作確認が完了したら、Scheduleを起動して自動運用に切り替えます。
本番運用前のチェックリスト
本番運用を始める前に、3カテゴリ(Notion/Make/Buffer)すべてに目を通してください。
- 投稿管理データベースがある
- 投稿本文の項目がある
- 投稿予定日時の項目がある(Date型)
- ステータス項目がある(下書き/投稿待ち/投稿済みの3段階)
- 投稿先項目がある
- テスト用の投稿データが1件ある(投稿予定日時は過去〜現在に設定してテスト)
- テスト投稿のステータスが「投稿待ち」になっている
- 過去日時の「投稿待ち」が他に残っていないか確認した
- Makeアカウントにログインできる
- Notionと接続できている
- Bufferと接続できている
- Scenario「Notion to Buffer」を作成している
- 最初のNotionモジュールが Search Objects(Data Source Items) である
- Filter条件①「投稿ステータス Select: Equals 投稿待ち」が設定されている
- Filter条件②「投稿予定日時 Date: On or before {{now}}」が設定されている
- Limit が 10 になっている
- Buffer モジュールに NotionのX投稿文がマップされている
- Notion Update モジュールの Page ID が Search Objects から取れている
- Notion Update で投稿ステータス=投稿済みに更新する設定になっている
- Schedule 設定の Days で土日も含む全曜日にチェックが入っている
- Schedule 設定の Time from / Time to が投稿時刻をカバーしている
- Run onceで1件テストした(または0件取得=正常を確認した)
- エラーが出ていない
- Schedule の ON/OFF トグルが ON になっている
- Bufferにログインできる
- XアカウントがBufferに接続されている
- Makeから送られた投稿がBufferに入っている
- 投稿文が文字化けしていない
- 投稿日時が意図通りになっている
- Lv.2運用なら投稿前に人が確認できる状態になっている / Lv.3運用なら投稿後にSent/Errorを確認する運用になっている
- Queue / Sent / Error タブを定期的に確認する運用になっている
自動化レベルのロードマップ
いきなりレベル4を目指さない。レベル2で動作確認 → 安定したらレベル3に移行するのが現実的なステップ。本マニュアルの構築完了時点はLv.3(自動投稿)を想定。
外注さんへの作業指示文
そのままコピーして外注さんに共有できます。
目的は、Notionで管理しているX投稿案を、Make経由でBufferに送ることです。
XへはMakeから直接投稿しません。
XのAPI制限や仕様変更の影響を避けるため、Bufferを中継して運用します。
最初から完全自動投稿にはせず、まずは以下の状態を目指してください。
Notionでステータスが「投稿待ち」の投稿だけを取得
↓
MakeでBufferへ送信
↓
Notionのステータスを「投稿済み」に変更
初期はBuffer上で人が最終確認してから手動投稿する運用(Lv.2)で動作確認し、安定したら自動投稿(Lv.3)に切り替えます。
作業時は、必ずRun onceで1件だけテストしてください。
いきなり本番自動稼働はしないでください。
Notion側の項目名は勝手に変更しないでください。
変更が必要な場合は、事前に確認してください。
Claudeに引き継ぐ場合のプロンプト
作業を別のチャットや別の人に引き継ぐ時、このプロンプトをClaudeに渡せば前提を一発で共有できます。
以下の前提で、初心者でも作業できる手順書を作成してください。
【前提】
Makeは初めて使う
投稿管理はNotionで行う
X投稿はMakeから直接投稿しない
X投稿はBufferを経由する
理由は、MakeとXの直連携が不安定、または使えなくなっているため
初期(Lv.2)は完全自動投稿ではなく、Bufferに下書きとして送って人が確認(Now: No)
安定後(Lv.3)は Now: Yes(または Publication: Post immediately) に切り替えて自動投稿
最終確認方法はLv.2ではBuffer下書き、Lv.3ではBufferのSent/Errorタブとなる
Notionのステータスが「投稿待ち」の投稿だけをMakeで取得する
Bufferに送信後、Notionのステータスを「投稿済み」に変更する
Notionのステータスは「下書き/投稿待ち/投稿済み」の3段階のみで運用する
【作成してほしい内容】
全体構成
Notionデータベースの項目設計
Make Scenarioの作成手順
Notion接続手順
Buffer接続手順
テスト実行手順
よくある失敗と対処法
初心者向けの注意点
本番運用前チェックリスト
専門用語はなるべくかみ砕いて説明してください。
ただし、Make上のボタン名やモジュール名は英語表記を残してください。
参照させていただいた動画
本マニュアルの作成にあたり、以下の動画を参考にさせていただきました。素晴らしい解説に感謝します。
チャンネル:管理の山田 | Notion公式アンバサダー
まとめ。
Notionで投稿を管理 → Makeで投稿待ちデータだけ取得 → Bufferへ送信 → 自動的にXに投稿 → Notionのステータスを更新。
初期は半自動(Lv.2)で動作確認し、安定したら自動投稿(Lv.3)に移行するのが現実的です。本マニュアルの構築完了形はLv.3(自動投稿)を想定しています。
英語の音声を、
きれいに文字起こし。
Macのターミナル初心者向け、OpenAI APIを使った文字起こしマニュアル。コピペでそのまま動きます。
12ステップで、最後まで。
上から順に進めれば、英語音声から自然な日本語訳まで作成できます。各ステップは独立しているので、途中で止めて再開してもOK。
進み具合を、可視化。
各項目をクリックすると完了マークがつきます。ページを閉じるとリセットされます。
事前準備 3
- OpenAIのAPIキーを用意した
- 英語音声ファイルを用意した
- ファイル名を output.wav にした
ターミナル準備 3
- ターミナルを開いた
- ~/openai-transcribe フォルダを作った
- cd ~/openai-transcribe で移動した
APIキー設定 2
- export OPENAI_API_KEY=… を実行
- echo ${#OPENAI_API_KEY} で数字が出た
Python環境 4
- python3 -m venv .venv を実行
- source .venv/bin/activate を実行
- 行頭に (.venv) が出た
- pip install openai を実行
音声配置 3
- open . でフォルダを開いた
- output.wav をフォルダに入れた
- ls で output.wav が見えた
分割 5
- nano split_wav.py を開いた
- 分割コードを貼った
- 保存した
- python3 split_wav.py を実行
- part_1.wav などができた
文字起こし 5
- nano transcribe_parts.py を開いた
- 文字起こしコードを貼った
- 保存した
- python3 transcribe_parts.py を実行
- 「完了」メッセージが出た
翻訳 4
- transcript.txt をコピーした
- ChatGPTに貼った
- 翻訳プロンプトを送った
- 日本語版を保存した
つまずいたら、ここを。
よく出るエラー4つと、その対処法をまとめました。落ち着いて1つずつ確認すればだいたい解決します。