ワークフロー自動化パイプライン
自前で構築した、ジョブ連携・スケジュール実行・承認フロー・状態管理の実装集。GitHub Actions・PythonAI・データ分析の分野で最も使われるプログラミング言語（読み: パイソン）。AI関連の道具が最も豊富で、文法が読みやすいのが特徴・OAuthオーオースと読む。他のサービスの機能を、IDやパスワードを教えずに安全に使わせるための認可の標準規格。「○○でログイン」ボタンの裏側で動いている仕組み1.0a・Selenium/Playwright を組み合わせ、ノーコードの連携ツールに依存しない再現可能なパイプラインとして設計・運用している。
概要
「A が起きたら B を動かす」型のワークフローを、コードベースで構築・運用している代表例。ジョブ連携・スケジュール実行・承認フロー・状態管理といった統合機能群を、自前の APIApplication Programming Interface（エーピーアイ）の略。あるプログラムの機能を、別のプログラムから呼び出せるようにした「窓口」。予約システムがLINE社の機能とやり取りするのもAPI経由 + コードで設計・実装している。
- 公開リポジトリ（参照可）: Zenn 記事パイプライン・LINE 予約システム・本ガイド
- 非公開リポジトリ（設計思想は本ガイド参照）: X 自動投稿・BUYMA 販売管理
- 受託・納品済: SHOWROOM 楽曲報告 RPARobotic Process Automation（アールピーエー）の略。人がパソコンで行う定型作業（コピペ・転記等）をソフトウェアに代行させること
代表事例 1: Zenn 記事 自動投稿パイプライン（公開・稼働中）
zenn リポジトリで完全公開。GitHub Actions 連鎖による「毎日6時のトピック発掘 → Issue 承認 → Zenn 公開 → SNS 連携」の流れを、コードベースの workflow で回している。
パイプライン構成（2 系統）
[毎朝 6:00 JST] discover.yml
└ 過去コミット解析 → 記事候補生成 → Issue 起票（要承認）
[Issue コメント "/approve"] publish.yml
└ 本文整形 → Zenn API 投稿 → 120秒待機 → SNS 連携 → Issue クローズ
設計の要点
| 観点 | 設計 | 効果 |
|---|---|---|
| 人間承認ゲート | GitHub Issue の /approve コメントで公開可否判定 |
自動実行と品質管理の両立 |
| リポジトリでの workflow 公開 | .github/workflows/discover.yml publish.yml を公開 |
第三者による検証・再現が可能 |
| JST タイムゾーン固定 | 環境変数 TZ: Asia/Tokyo で CIContinuous Integration（シーアイ・継続的インテグレーション）の略。コードを変更するたびに自動でテストとチェックを回し、壊れていないかを常に確認する仕組み 内 UTC と分離 |
実行時刻の意図ズレ防止 |
| 段階的リトライ | 失敗時の Issue コメント通知 + 手動再承認 | 無音失敗を排除 |
代表事例 2: デスクトップ RPA — SHOWROOM 楽曲報告自動入力
ココナラ受注 → 2025 年 12 月納品完了の実績。Selenium / Playwright ベースの RPA。Excel から楽曲コードを読み取り、JASRAC / NexTone 入力欄を自動判別して入力、ポップアップ広告や通信エラー時は画面リセット & 再入力で自己修復する。
| 観点 | 実装 |
|---|---|
| 自律復帰ロジック | ポップアップ広告・通信エラーを自動検知し、画面リセット → 再入力で自己修復 |
| 自動判別 | 楽曲コード頭文字から JASRAC / NexTone 欄を振り分け |
| フェイルセーフ | 空行自動削除・50 件上限到達で自動停止 |
| 提供形態 | Python 環境がないクライアント向けに exe ファイル化（ダブルクリック即実行） |
| 開発期間 | 実質 4 日間・バグ報告から 2.5 時間で修正納品 |
代表事例 3: X 自動投稿（非公開リポジトリ・設計思想のみ公開）
OAuth1.0a 署名を自前実装した、ジョブ連携 + 状態管理 + ガードロジックの統合システム。
構成要素
| 構成 | 役割 |
|---|---|
post_tweet.py |
投稿 CLI（72h 重複 / レートガード / dry-run / UA 独自 / --confirm 付き） |
lib/oauth1_signer.py |
OAuth1.0a 署名（外部ライブラリ非依存） |
lib/safety.py |
重複チェック・レートガード・bigram Jaccard 類似 0.7 ガード |
lib/content.py |
記事選択（LRU + 3日 cooldown）+ テンプレ適用 + 語彙注入 |
scheduled_tweet.py |
定期実行入口（dry-run / --post） |
scripts/jitter_schedule.py |
重み付きジッター時刻生成 |
data/posted_log.jsonl |
投稿履歴（gitignore） |
| Windows Task Scheduler | ジッター時刻での定期実行 |
設計の要点
- 重複投稿ガード: 72 時間以内の同一本文ブロック + bigram 類似度 0.7 超えで投稿拒否
- OAuth1.0a 自前署名: ライブラリ任せにせず署名仕様を理解して実装
- ジッター時刻: 固定時刻での投稿を避け、時間帯に自然なばらつきを与える
- Discord 承認フロー: 投稿前に Discord へ承認依頼を送り、人の確認を経て投稿する半自動経路も併設
なぜ自前構築を選んだか（ノーコード代替との比較）
ワークフロー自動化には、ノーコードでGUIベースで組む選択肢（Zapier / Make / n8n / UiPath / WinActor / Dify 等）も存在する。これらを比較した上で自前コードベースでの構築を選んだのは、技術的に高度だから——というよりもむしろ、要件をコードレベルできめ細かく制御できるから、が主たる理由。
ノーコードツールに対する優位性
| 観点 | ノーコードツール（代表例） | 自前コードベース（本ガイド事例） |
|---|---|---|
| 類似度判定 | 基本的な重複チェックは可能 | bigram Jaccard 0.7・LRU・72時間窓をコードで正確に定義 |
| OAuth 署名 | ベンダー提供の認証ブロックを使用 | OAuth1.0a 署名を自前実装（外部ライブラリ非依存・署名仕様を理解した実装） |
| ジョブの分岐・合成 | GUI で if/then を線で繋ぐ | Python で任意のロジック（例外処理・リトライ・バックオフを正確に記述） |
| テスト・回帰検証 | 手動確認中心 | pytest + CIで挙動を自動検証 |
| バージョン管理 | GUI 上のスナップショット | Git で全変更履歴・コミット単位でレビュー可能 |
| 実行基盤の透明性 | ベンダー依存（仕様変更・値上げ・終了リスク） | GitHub Actions / Task Scheduler 等 OSS 中心・仕様が自分の手元 |
| エラーハンドリング | ベンダー提供のエラー UI 任せ | リトライ戦略・通知・フォールバックをコードで明示定義（SHOWROOM RPA の自律復帰ロジック等） |
| 状態の永続化 | ベンダー DB 依存 | JSON / JSONL を自前管理（gitignore と git 管理を使い分け） |
| ジョブ間データ受け渡し | ブロック接続で視覚的に | コードで任意のスキーマ変換・型チェック |
選択はあくまで要件次第
ノーコードツールが不適切なケース:
- 類似度計算・OAuth 署名・数値閾値の細かいガードが必要なケース
- コードでテストしたい・CI で回帰検証したいケース
- Git で変更履歴を管理したいケース
- 長期運用で外部仕様変更リスクを抑えたいケース
ノーコードツールが適切なケース（本ガイドで扱わない領域）:
- 非エンジニアがGUIで設定変更したい場合
- 短期間・小規模な単発連携
- 監視・アラート基盤までSaaSに丸投げしたい場合
つまり「コードで書けるからコードを選んだ」のではなく、「要件がきめ細かい制御を求めていたので、コードが最適だった」ということ。技術的に高度かどうかよりも、要件との適合性が選択の基準。
採用している技術スタック
| カテゴリ | 技術 |
|---|---|
| ジョブスケジューラ | GitHub Actions（毎日 6:00 / Issue トリガー）/ Windows Task Scheduler |
| 言語 | Python 3.12 |
| API 認証 | OAuth1.0a（自前署名）/ Personal Access Token |
| ブラウザ自動化 | Selenium / Playwright |
| RPA パッケージング | PyInstaller（exe 化） |
| 状態管理 | JSON / JSONL（git 管理 or gitignore 区別） |
| 承認 UI | GitHub Issue コメント / Discord メッセージ |
用語の平易な解説（専門用語を読み解く）
本章で使った専門用語を、日常的な言葉に翻訳して解説する。
🧮 類似度計算（bigram Jaccard 0.7）
一言で: 「2つの文章がどれくらい似ているか、を 0〜1 の数値で測る方法」。
- bigram（バイグラム）: 文章を「2文字ずつのセット」に切り分けること。「AI開発」→「AI」「I開」「開発」のような単位
- Jaccard（ジャッカード）係数: 2つの文章の「共通部分 ÷ 全体」で似てる度合いを出す計算式。1.0 なら完全一致・0.0 なら全くの別物
- 0.7 は何か: 「70% 以上似ていたら、同じ投稿とみなして弾く」という私が決めた基準値（閾値・しきいち）
- なぜこれが必要か: X で「毎日同じようなツイートが流れる」を防ぐため。「全く同じ文」だけでなく「言い換えただけの似た文」も自動検出する
⏱️ クールダウン（cooldown）・LRU
一言で: 「同じネタを連投しないための、時間的なクールダウン仕組み」。
- クールダウン: 一度使ったネタを「しばらくの間、再利用禁止」にすること。スポーツの選手が試合後に体を冷やすのと同じ発想で、ネタを休ませる
- 3日クールダウン: 「この記事を使ったら、次に使えるのは3日後から」というルール
- LRU（Least Recently Used）: 「一番昔に使ったものから順に捨てる」管理方式。キャパが一杯になったら、最も長く使われていないものを消す。スマホのブラウザタブを「開きすぎたら古い順に閉じる」のと同じ
🎚️ 数値閾値（しきいち）ベースの制御
一言で: 「人間の感覚ではなく、数値でルールを決めて機械に判定させる」こと。
- 閾値（しきいち）: 「ここを越えたら OK / 越えなければ NG」と分ける境界線の値
- 例: 「類似度 0.7 以上は重複」「72 時間以内は重複」「1日3投稿まで」等
- なぜ数値で決めるか: 「なんとなく被っている気がする」ではなく「0.72 だから弾く」と判定がブレない。コードで書くと閾値を1行で明示できる
🔑 OAuth1.0a（オーオース・ワン・ポイント・オー・エー）
一言で: 「パスワードを渡さずに、他のサービス（X 等）へ安全に投稿権限を委譲する仕組み」。
- OAuth: ユーザーがアプリに「パスワードそのもの」を渡さずに「代わりに操作していいよ」と許可を出す仕組み。LINE 連携や Google ログインでも同じ技術が使われている
- 1.0a: OAuth のバージョン名（現在は 2.0 が主流だが、X の投稿 API は 1.0a を要求する）
- 署名（しょめい）: 「このリクエストは本当に本人からか？」を証明する暗号のような文字列。自前署名＝この署名作成ロジックを、既製ライブラリに頼らず自分で実装した、ということ
- なぜ自前実装か: ライブラリ任せだと「中で何が起きているか」が分からない。署名の仕組みを理解して実装することで、トラブル時に原因を自分で追える
🔄 自律復帰（じりつふっき）ロジック
一言で: 「エラーが起きても、自分で元の状態に戻って再開する仕組み」。
- SHOWROOM RPA の例: 投稿中にポップアップ広告が飛び出したり通信エラーが起きたりしても、画面をリセット → 入力をやり直しで自動復旧する
- 人間なら「あ、エラー出た。やり直そう」とできるが、機械は明示的に教えないと止まったまま。この「やり直す手順」をコードで組む
📅 ジッター（jitter）時刻
一言で: 「毎日同じ時刻ではなく、あえて少しずらした時刻に動かす仕組み」。
- ジッター: 揺らぎ・ばらつきのこと
- 例: 毎日 19:00 ピッタリではなく、18:52・19:07・18:45 のように重み付きで少しずらす
- なぜか: 「このアカウントは毎日19:00に自動投稿している」と機械的パターンがバレると、プラットフォーム側にスパム判定されるリスクがある。人間っぽい自然なばらつきを持たせる
🗳️ 人間承認ゲート
一言で: 「機械が最終判断せず、人間が『これでいいよ』と押すまで動かない仕組み」。
- Zenn パイプラインの例: AI が記事候補を生成 → GitHub の Issue に「これを公開しますか？」と起票 → 人間が
/approveとコメントした瞬間に公開へ進む - なぜか: 完全自動だと「変な記事を公開してしまう」リスクがある。重要なアクションには人の目を通すことで、自動化の便利さと安全性を両立
🧪 回帰テスト（CI）
一言で: 「コードを直した時に、今まで動いていた機能が壊れていないか自動で確認する仕組み」。
- 回帰テスト: 改修の影響で前の機能が後退（回帰）していないか調べるテスト
- CI（Continuous Integration・継続的インテグレーション）: コードを更新するたびに自動でテストを走らせる仕組み
- なぜコードベースか: GUI のノーコードツールでは「前と同じように動くか」の自動検証が難しいが、コードなら pytest + CI で機械的にチェックできる
この設計方針を選んだ理由（中立版）
「コードベースで組む」選択には 技術選定の合理性がある。
- 精密な制御ロジック: 類似度計算やクールダウン等の数値閾値ベースの判定は、視覚的な GUI ブロックよりもコードの方が正確に表現できる
- 再現性・テスト可能性: Git 管理されるため変更履歴・CI による回帰テストが回る
- 長期運用コスト: 毎日動くジョブは公開リポジトリの GitHub Actions で実質無料で運用可能