寺院が毎月の寺報の原稿を、行事の予定と住職のメモから Apps Script と Claude で下書きし、Google ドキュメントにまとめる

処理の起点を決める

毎月18日の朝に1回動かします。 時間主導型のトリガーで onMonthDay(18) と atHour(6) を指定します。公式の説明では、atHour() の例が「5時〜6時の間に動く」と書かれ、nearMinute() を指定しないと分はランダムに決まります。 朝の勤行の前後に終わっていればよい、という作りにします。

18日にしているのは、25日の印刷まで1週間を残すためです。 住職が法話の欄を直す時間を、法事の合間に2〜3日取れるようにします。18日より後に行事が足されたときは、手で動かせる関数で行事の表だけを作り直します。

トリガーは、作った人のアカウントで動きます。 公式は、インストール型のトリガーは作成した人のアカウントで実行されるとしています。寺の共用のアカウント（カレンダーと寺報の文書を持つアカウント）で作ります。 住職個人のアカウントで作ると、代替わりのときに止まります。

失敗すると、所有者に「Summary of failures for Apps Script」という件名のメールが届きます。 共用のアカウントの受信箱は寺務の担当が見ることにし、処理ログのシートにも「どの欄で止まったか」を日本語で書きます。

入力データを集める

質を決めるのは、住職のメモと寄進の記録の「載せてよいか」の列です。 メモが薄ければ、法話の欄は薄くなります。AIに膨らませることはさせません。 載せてよいかの列が空なら、その方の名前は載せません。

仏事の解説の手本は、住職がこれまでの寺報に書いた文を仏事ごとに1つずつ集めたものです。 彼岸、盆、報恩講、除夜の鐘、修正会、花まつり。AIはこの手本を言い換えて、今年の行事の日程と結びます。 一般の仏教の説明をAIが一から書くことはしません。

データの取得方法を決める

行事の範囲を翌々月の7日まで取るのは、月初の行事の案内が前の号に要るからです。 1日に修正会がある1月号は、12月末に配る号で案内しなければ間に合いません。

住職のメモは、見出しで節を分けてもらいます。 「法話の種」「近況」「表紙の言葉」の見出しの下に箇条で書き、使いたい節の見出しの末尾に「★」を付けます。 Apps Script は★の付いた節だけを読みます。印の無いメモは、住職の個人的な覚え書きとして読みません。

カレンダーの行事のうち、法事と葬儀の予定は読みません。 寺のカレンダーには檀家の法事も入っていることが多く、家の名前や故人の名前が予定の題に入っています。 行事を入れるカレンダーと法事を入れるカレンダーを分けるか、行事に「寺報」の色を付けて、その色だけを読みます。

AIへ渡す前に整形する

1. 行事を選ぶ … 「寺報」の色の予定だけを残し、法事・葬儀の予定は捨てます
2. 行事の表を作る … 日付・曜日・時刻・行事の名前・場所を Apps Script が並べます。この表はAIに渡しません
3. 行事の説明を記号にする … 案内の欄のために、行事ごとに {{行事日_1}} {{開始_1}} のような記号と、説明の文（持ち物、お斎）を束ねます
4. メモの節を切り出す … ★の付いた節を、見出しごとに分けます
5. 名前を外す … メモやお知らせ、檀家の声の中の人の名前を、名簿と照らして {{人名_1}} に置き換えます
6. 寄進の御礼は名前の一覧だけを作る … 載せてよい方の名前を Apps Script が並べ、AIには件数と寄進の種類だけを渡します
7. 仏事の解説の手本を選ぶ … 翌月に当たる仏事の手本を1つ選びます。当たる仏事が無ければ、この欄は作りません

5番目を軽く見ないでください。 住職のメモには「先日、{{人名}}さんの一周忌で……」のような書き方がよく出てきます。名前を残したまま渡すと、AIはそれを法話の中にきれいに織り込み、名前の出た寺報が450軒に届きます。 名簿と照らして記号にし、ドキュメントでは記号のまま残して、住職に名前を出すかを決めてもらいます。

2番目の行事の表をAIに渡さないのは、表を作り直させないためです。 渡すと、AIは表を文章にまとめ直し、時刻の書き方を「午後二時」に変えたり、二つの行事を一つにまとめたりします。 表は機械で作り、AIには案内の文だけを書かせます。

AIに処理させる

させるのは、欄ごとの材料を、寺報の文体の原稿に整えることだけです。

させないこと：

1行目がいちばん起きやすい失敗です。 法話の要点が「感謝の心」なら、AIは親切にそれらしい言葉を引いて補います。住職が知らない引用、宗派の解き方と違う引用が、住職の名前で檀家に届きます。 引用はメモにあるものだけ、と指示し、さらに検査で引用符の中身をメモと照らします。

指示内容を固定する

あなたは寺院の寺報の原稿を、住職と坊守の手伝いとして下書きします。
渡す「材料」だけを使い、欄ごとに原稿を書いてください。

【文体】
- です・ます調。檀家の高齢の方が読みやすいよう、一文を短く、難しい漢語を避けてください。
- 住職の近況と法話は、住職の一人称（「私」）で書いてください。

【法話の欄の決まり】
- メモの「要点」を、順番を変えずに文章にしてください。要点に無い話を足さないでください。
- 「」で囲まれた引用は、メモにある文字のとおりに写してください。
  言い換え、補足、出典の書き足しをしないでください。
- メモに無い経典・祖師・高僧の言葉、ことわざ、偉人の言葉を引かないでください。
- 教えの解説をメモ以上に広げないでください。

【日付と名前】
- 日付・時刻・曜日は書かず、材料にある記号（{{行事日_1}} {{開始_1}} など）を置いてください。
- 人の名前は書かず、材料にある記号（{{人名_1}} など）をそのまま置いてください。
- 金額は書かないでください。

【欄の長さの目安】 表紙の言葉 120字、近況 300字、法話 900字、行事の案内 1行事 80字、
行事の報告 200字、仏事の解説 500字、お知らせ 1件 100字、編集後記 100字。
材料が少ないときは短くてかまいません。足りない分を作らないでください。

【notes】
材料の中で意味がとれないところ、書くのに足りないものがあれば、欄ごとに notes に書いてください。

【材料】{materials_json}

「足りない分を作らないでください」が、法話の欄で効きます。 長さの目安を書くと、AIはそこまで書こうとして話を足します。目安は上限で、材料が少なければ短くてよいと明記します。

「出典の書き足しをしないでください」も同じ理由です。 引用の言葉の後に「（○○経）」と出典を足すことがあり、その出典が正しいかは住職にしか確かめられません。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 スキーマは output_config.format に type: "json_schema" で渡します。

{
  "sections": [
    {
      "id": "dharma_talk",
      "title": "今月の法話　ありがとうの重さ",
      "text": "先日、{{人名_1}}さんのお宅で……「…（メモの引用そのまま）…」……",
      "quotes": ["…（メモの引用そのまま）…"],
      "placeholders_used": ["{{人名_1}}"],
      "notes": []
    }
  ]
}

id は欄ごとに決めた10個の名前（cover・news・dharma_talk・events_next・events_report・buddhist_rite・donation_thanks・office_notice・members_voice・afterword）から選ばせます。

構造化出力を使う理由は3つです。 1つは、欄ごとに分かれて返るので、ドキュメントの決まった場所に差し込めることです。2つ目は、quotes に引用を抜き出させ、メモと一字ずつ照らせることです。3つ目は、placeholders_used で記号の抜けと余りを見られることです。

スキーマに文字数の上限は書きません。 公式の説明では、文字列の長さの制約や数値の範囲の制約は非対応で、使うと400のエラーになります。 長さは Apps Script で数えて、目安の1.5倍を超えたら印を付けます。

Apps Script の検査は次のとおりです。

1行目と2行目が、法話の欄の網です。 AIが引用を書き足したなら、メモに無い文字列が「」の中に現れます。機械で見つけて、住職が読む前に冒頭に並べておきます。

システムへ連携する

下書きのドキュメントは DocumentApp.create(名前) で作り、appendParagraph() で欄の見出しと原稿を、appendTable() で行事の表を足します。 公式の説明では、appendTable() は文書が表で終われないため、表の後に空の段落を1つ足します。 表の後の行の数を数えて体裁を組むときに注意します。

記号の置き換えは replaceText() で行います。 公式の説明では、replaceText() は Google の RE2 の正規表現を使い、検索の文字列は JavaScript の正規表現ではなく文字列で渡すため、{ } などの記号はバックスラッシュでエスケープします。 エスケープを忘れると、{{人名_1}} が置き換わらずに残ります。

ドキュメントの作成には1日あたりの上限があり、個人のアカウントで250、Workspace で1,500とされています。 月1回の寺報で当たることはありませんが、作り直しを何度も試す最初の週は、テスト用の文書を消しながら進めます。

人の名前の記号は、ドキュメントでは置き換えずに残します。 名前を出すかどうかは住職が決め、出すなら住職が手で書きます。置き換えるのは日付と時刻の記号と、御礼の名前の一覧だけです。

人が確認する

1. 冒頭の検査の欄を見る … 引用の不一致、申告の無い引用、日付の混入、長すぎる欄
2. 住職が法話と近況を読む … 自分の言葉として出してよいかを見ます。引用は必ずメモの元の文と見比べます
3. 坊守が行事の表を見る … カレンダーと同じ日時か、中止や変更が入っていないか
4. 坊守が御礼の名前を見る … 寄進の記録の「載せてよいか」と一人ずつ照らします
5. 人名の記号を決める … 名前を出すか、「ある檀家の方」に直すかを住職が決めます
6. 寺務の担当が枠に貼り、文字の量を整える

4番目を省かないでください。 一覧は台帳から機械で作っていますが、台帳の「載せてよいか」の列そのものの記入漏れは機械では分かりません。 寄進を受けたときに聞いた内容と合っているかを、受けた坊守が確かめます。

目標は、10の欄をならして1欄18分です。 お知らせや行事の案内は数分で済み、時間を使うのは法話を住職の言葉に直すところです。

例外に対処する

最後の行が、名前の網の穴です。 名簿と照らして置き換える方式は、名簿に無い人（親戚、他の寺の僧侶、近所の方）の名前を拾えません。メモの段階で、名前を書くときは「○○さん」と伏せてもらうのが一番確実です。

記録を残す

• 実行の日時、読んだ行事の数、★の付いたメモの節、作ったドキュメントの URL
• 欄ごとの材料（記号に置き換えた後）と、Claude が返した JSON
• 検査の結果（引用の照合、記号、日付、長さ）
• 住職と坊守が直した後の最終版（印刷した版のドキュメントを月ごとに残す）
• 御礼の名前の一覧と、そのとき参照した寄進の記録の「載せてよいか」の値

4つ目を残しておくと、下書きと最終版の違いが見えます。 法話の欄で住職が毎月同じ種類の直しをしているなら、プロンプトの文体の決まりを直す材料になります。

5つ目は、後から「載せないでと言ったのに」と言われたときの確認のためです。 当時の記録の値が残っていれば、記録の誤りか、一覧を作る仕組みの誤りかを分けられます。