「LINE公式アカウントの定期配信を自動化したい」——先に結論をお伝えします。GitHub Actionsのような定時実行の仕組みと、LINEのAPI(Messaging API)を組み合わせれば、月次の配信作業は全自動にできます。私は寺の月次配信をこの形で運用していて、配信作業そのものからは完全に手が離れました。

ただし、作ってみて分かった本当に大事な設計は、送る仕組みではなく**「送らない」判断を仕組みに持たせること**でした。この記事では、仕組みの全体像と運用の実感、そして実際に出した失敗までを、やったことだけ書きます。

この記事の位置づけ——「AIに任せている仕事の全体マップ」の②を深掘りする

全体像はピラー記事へ

私は僧侶と建築設計の実務と複数サイトの運営をひとりで回していて、定型の仕事を順にAIと自動化に渡してきました。その全体像は個人事業で生成AIに任せている仕事の全記録にまとめています。

その記事で「完全に手が離れた」と書いた筆頭が、寺の月次LINE配信です。本記事はその1本目の深掘りで、作り方の考え方と、運用して初めて分かったことに絞って書きます。

自動化する前——月次配信は「作業」より「覚えておくこと」が重かった

自動化する前、配信は手作業でした。作業自体は数分で終わります。原稿を貼り付けて、送信ボタンを押すだけ。時間で測れば、大した負担ではありません。

重かったのは作業ではなく、「今月も忘れずにやる」を毎月抱え続けることでした。月に一度しかない仕事は、習慣になりません。手帳やリマインダーに頼っても、「通知を見たが後回しにして、そのまま」が起こり得ます。

一人事業の定期業務は、抜け漏れがそのまま信用に響く

一人でやっている以上、忘れたときに気づいてくれる同僚はいません。毎月届いていたものが黙って途切れれば、受け取る側からは「やめたのかな」に見えます。定期配信は、続いていること自体が信頼の一部です。

だから自動化の目的は、時短ではありませんでした。「決まった日に、確実に届く」状態を、自分の記憶力から切り離すこと。これが最初からの狙いです。

仕組みの全体像——GitHub Actionsが決まった日にLINEのAPIを呼ぶ

構成要素は3つだけ: 原稿置き場・定時実行・配信API

仕組みといっても、要素は3つしかありません。

要素	役割	私の場合
原稿置き場	配信する文章を決まった場所に置く	月ごとにファイルで管理
定時実行	決まった日時にプログラムを動かす	GitHub Actionsのスケジュール実行
配信API	LINEの友だち全員に一斉送信する	LINEのMessaging API

流れは単純です。毎月の決まった日にGitHub Actionsが起動し、原稿置き場からその月の原稿を読み込み、LINEのAPIを呼んで一斉配信する。それだけです。

LINE公式アカウントには管理画面からの予約配信もあるので、「毎月手で予約すれば十分」という考え方もあります。私がAPI経由の自動化まで進めたのは、予約操作そのものも「毎月忘れずにやること」に含まれてしまうからです。人間の仕事を「原稿を書く」の一点に絞りたかった、というのが理由のすべてです。

「決まった日に、用意された原稿を読んで送る」以上のことをさせない設計にした理由

仕組みを組むとき、意識して機能を足しませんでした。原稿の自動生成もしない。配信日時の柔軟な変更もしない。決まった日に、人間が用意した原稿を、そのまま送る。それ以上のことをさせていません。

理由は2つあります。1つは、配信は取り返しがつかない仕事だからです。一度送った文章は回収できません。中身を決める部分に自動の判断を挟むほど、意図しないものが届く可能性が増えます。もう1つは、単純な仕組みほど壊れにくく、壊れたときに原因を探しやすいからです。月に一度しか動かない仕組みは、不具合に気づく機会も月に一度しかありません。だからこそ、疑う場所が少ない構成にしておく価値があります。

運用して分かったこと

人間に残った仕事は「原稿の用意」だけ——手離れの実感

運用を始めてから、私がこの配信のためにやっているのは、原稿を書いて決まった場所に置くことだけです。配信日を覚えておく必要も、当日に手を動かす必要もありません。

実感として大きいのは、頭の中から「LINE配信」という項目が消えたことです。複数の仕事を並行していると、「忘れてはいけないこと」の在庫が集中力を削っていきます。在庫が1つ減ると、その分だけ他の仕事に頭が回る。自動化の価値は、削減できた作業時間より、この方が大きいと感じています。

API直送の配信は管理画面の見え方が変わる(運用上の注意メモ)

1つ、運用上の注意を書いておきます。APIから直接配信すると、管理画面から手動配信した場合とは、配信の記録の見え方が変わることがあります。管理画面上の履歴だけを見て「送れていない」と早合点しないよう、配信が成功したかどうかはAPIの応答や実際の受信で確かめる前提でいた方が安全です。

私も運用当初、管理画面の表示と実際の配信状況を突き合わせて確認する期間を設けました。仕組みを信用するのは、届いていることを自分の目で確かめてからで遅くありません。

失敗の実録——過去配信の誤再送

うまくいった話だけでは実録になりません。実際に出した失敗を書きます。

何が起きたか: 当月原稿がない月に、過去の配信を再送してしまった

ある月、当月の原稿を所定の場所に用意できていない状態で、配信日を迎えました。その結果、仕組みが過去の配信済み原稿を読み込み、そのまま再送してしまいました。受け取った側から見れば、前に読んだものがもう一度届いたことになります。

原因: 「原稿がある前提」で組み、前提が崩れた時の挙動を決めていなかった

原因は仕組みの故障ではありません。設計の抜けです。仕組みは「その月の原稿が用意されている」前提で組んであり、前提が崩れたときにどう振る舞うかを、私が決めていませんでした。決めていないので、仕組みは止まらず、読める原稿を読んで送るという「正常な動き」をした。つまり、組んだ通りに動いた結果の事故です。

対策: 「原稿がなければ配信を中止する」安全側の仕様へ

対策として、当月の原稿が確認できなければ配信を中止する仕様に直しました。「間違ったものを送る」と「送らない」なら、送らない方の失敗を選ぶ。安全側に倒すとはそういうことだと、身をもって学びました。

配信が止まれば自分が気づいて原稿を用意すればいい。しかし誤配信は取り消せません。定期配信の自動化では、この非対称を仕様に反映しておくべきでした。

これから作る人へ——月次配信自動化の設計チェック

例外時の挙動を先に決める/「送らない」判断を仕組みに持たせる

これから同じような仕組みを作る方へ、私の失敗から導けるチェック項目を置いておきます。

• 原稿がなかったらどうするかを、作る前に決める(私はここで失敗しました)
• 迷ったら「送らない」に倒す。誤配信は取り消せず、未配信は後から取り返せる
• 配信の成否を確かめる手段を、管理画面の表示以外にも持っておく
• 仕組みには「決まったものを決まった日に送る」以上の判断をさせない
• 月に一度しか動かない仕組みは不具合に気づきにくい、という前提で単純に組む

技術的には難しいことをしていません。定時実行とAPI呼び出しは、調べれば作れます。差がつくのは、例外のときの挙動を先に決めてあるかどうか。それだけです。

まとめ——次の実録は画像生成APIか情報収集

寺の月次LINE配信は、原稿置き場・定時実行・配信APIという3要素の単純な仕組みで全自動になり、私の仕事は原稿の用意だけになりました。一方で、原稿がない月の誤再送という失敗も出しました。原因は仕組みではなく、例外時の挙動を決めていなかった設計にあります。

自動化の設計とは、正常に動く道筋を作ることよりも、「どういうときに動かさないか」を決めることなのだと思います。

AIと自動化に任せている仕事の全体像はピラー記事にまとめています。今後は、画像生成APIの使い方や情報収集の仕組みについても、同じように実際にやったことだけを1本ずつ書いていく予定です。

補足: 原稿を書く側でAIを使うなら、先に「話し方の設定」を

この記事で書いた配信の仕組みは、原稿さえあれば動く単純なものです。一方、その原稿を用意する側でAIを使う場合、応答の癖を先に揃えておかないと手直しばかりが増えます。返事が長い・敬語がぶれる・勝手に英語が混じる、といった癖を設定ファイル1枚で揃える手順は、私自身がnoteに書きました。

【コピペ12行】AIの返事が長い・敬語がぶれる・勝手に英語が混じる——設定ファイル1枚で直す(note)

私が書いている連載の入口の記事です。この1本は無料で最後まで読めます。連載の続きには有料の記事も含みます。