Media > AI活用ユースケース > カスタマーサポート > 寺院が檀家の年忌法要の時期を Make で毎月拾い、家ごとの案内状と法要までの準備の説明を下書きして、住職の確認の後に送る

寺院が檀家の年忌法要の時期を Make で毎月拾い、家ごとの案内状と法要までの準備の説明を下書きして、住職の確認の後に送る

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

故人の台帳から、3か月後に年忌を迎える故人を毎月拾い、施主の家ごとに年忌法要の案内状の本文と、法要までの準備の説明を下書きします。住職が下書きを確かめてから、郵送用の文書とメールの下書きにします。

サマリー
生成AI
ChatGPT/Claude
連携・自動化
Make/n8n/Power Automate/Zapier
対象業界
その他
対象部門
カスタマーサポート
対象業務
台帳・マスタ管理/書類作成
主な課題
人手が足りない/書類作成に時間がかかる/期限・対応漏れが起きる
AIで行う処理
生成
主な効果
品質標準化/工数削減/機会損失防止
導入難易度
★☆☆☆☆
実装レベル
半自動化
費用感
ノーコード連携(中)
人間の確認
条件付き
現在工数
20h/月
AI導入後
4h/月
想定削減
80%
年間削減
192h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 月の初めに、住職が過去帳を繰り、3か月後に年忌を迎える故人を拾う
  2. 住所録で、その故人の家の施主の名前と住所を探す
  3. 前回の法要の記録(日取り、参列の人数、卒塔婆の本数、会食の有無)を帳面で探す
  4. 案内状をワープロで1通ずつ作る。故人の戒名・俗名、何回忌か、命日、日取りの相談の期限を書く
  5. 家の事情に合わせて、準備の説明を書き添える(遠方の施主、同じ年に別の年忌が重なる家など)
  6. 印刷して封入し、郵送する。メールの施主には同じ内容を送る
  7. 送ったことを帳面に記す
導入後(After)
  1. 【人・最初だけ】 過去帳と住所録の内容を、故人の台帳と施主の台帳のスプレッドシートに移す
  2. 自動毎月1日の朝にシナリオが動き、3か月後の月に年忌を迎える故人を台帳から拾う
  3. 自動同じ施主の家で同じ年に年忌が重なる故人をまとめ、施主の情報と前回の法要の記録を引く
  4. 自動施主の情報が最後に確かめられてから3年を超える家に「宛先の確認」の印を付ける
  5. 自動Claude API に、決まった事実と寺の準備の決まりを渡し、案内状の本文と準備の説明を下書きさせる
  6. 自動Google ドキュメントのひな形に差し込み、家ごとの案内状を作る。メールの施主には Gmail の下書きを作る
  7. 人住職が案内状を1通ずつ読み、直す。「宛先の確認」の家は寺務の担当が電話で確かめる
  8. 人案内状を印刷して郵送し、メールの下書きを送る
  9. 自動送った日を台帳に書く。翌月、日取りの連絡が無い家を一覧にする
各工程の詳しい説明を読む
  1. 月の初めに、住職が過去帳を繰り、3か月後に年忌を迎える故人を拾う
  2. 住所録で、その故人の家の施主の名前と住所を探す
  3. 前回の法要の記録(日取り、参列の人数、卒塔婆の本数、会食の有無)を帳面で探す
  4. 案内状をワープロで1通ずつ作る。故人の戒名・俗名、何回忌か、命日、日取りの相談の期限を書く
  5. 家の事情に合わせて、準備の説明を書き添える(遠方の施主、同じ年に別の年忌が重なる家など)
  6. 印刷して封入し、郵送する。メールの施主には同じ内容を送る
  7. 送ったことを帳面に記す

(a)拾い出しで出し忘れる。 過去帳を繰って何年前の命日かを数えるので、数え違いと見落としが起きます。 気づくのは、施主から「今年は七回忌ではないか」と電話が来たときです。

(b)案内状を1通ずつ書く。 文面の骨組みは同じでも、何回忌か、施主との続柄、前回の法要の様子で書き分けます。1通に20分近くかかり、 住職の法務の合間に書くので、月の後半にずれ込みます。

(c)施主の代替わり・転居に気づかない。 住所録は施主から連絡があったときにしか直されません。亡くなった前の施主の名前で案内状が届き、 家の人を悲しませることがあります。

(d)同じ家で年忌が重なる。 祖父の十三回忌と祖母の七回忌が同じ年に来る家では、別々に案内を出すか、1通にまとめて相談するかを住職が考える必要があります。帳面の上では気づきにくい組み合わせです。

(e)前回の記録が帳面に散らばる。 前回の法要の日取りや参列の人数は、その年の行事の帳面に書かれています。七回忌の案内を書くために、4年前の帳面を探すことになり、見つからなければ前回に触れずに書きます。

  1. 【人・最初だけ】 過去帳と住所録の内容を、故人の台帳と施主の台帳のスプレッドシートに移す
  2. 【自動】 毎月1日の朝にシナリオが動き、3か月後の月に年忌を迎える故人を台帳から拾う
  3. 【自動】 同じ施主の家で同じ年に年忌が重なる故人をまとめ、施主の情報と前回の法要の記録を引く
  4. 【自動】 施主の情報が最後に確かめられてから3年を超える家に「宛先の確認」の印を付ける
  5. 【自動】 Claude API に、決まった事実と寺の準備の決まりを渡し、案内状の本文と準備の説明を下書きさせる
  6. 【自動】 Google ドキュメントのひな形に差し込み、家ごとの案内状を作る。メールの施主には Gmail の下書きを作る
  7. 【人】 住職が案内状を1通ずつ読み、直す。「宛先の確認」の家は寺務の担当が電話で確かめる
  8. 【人】 案内状を印刷して郵送し、メールの下書きを送る
  9. 【自動】 送った日を台帳に書く。翌月、日取りの連絡が無い家を一覧にする

7番目を省かないのが、この設計の前提です。 下書きはあくまで下書きで、戒名や続柄の誤りを見つけられるのは、その家を知る住職だけです。 確かめる時間は、自分で書く時間よりはるかに短く済みます。

4番目の「宛先の確認」は、案内状を作る前に付けます。 作ってから気づくと、作り直しになります。

02今回想定するシステム構成

構成図
故人の台帳・施主の台帳・法要の記録(Google スプレッドシート)
   ▼【トリガー】毎月1日 8時(シナリオのスケジュール)
Make(シナリオ)
   ├──▶ Google Sheets:Search Rows(3か月後の月に年忌を迎える故人)
   ├──▶ Google Sheets:Search Rows(同じ施主で同じ年に年忌を迎えるほかの故人)
   ├──▶ Google Sheets:Search Rows(施主の情報・前回の法要の記録)
   ├──▶ 宛先の確認の印を決める(最終確認日から3年超。AIを通さない)
   ├──▶ Claude API(Make an API Call で Messages API、構造化出力)
   │      案内状の本文/準備の説明/住職への確認のメモ
   ├──▶ Google Docs:Create a Document from a Template(家ごとの案内状)
   ├──▶ Gmail:Create a draft email(メールの施主だけ)
   └──▶ Google Sheets:Update a Row(案内の段階・作った日)
   ▼【人】住職が下書きを確かめ、直して送る
役割想定する製品代替候補
ワークフローMake(シナリオ。Google Sheets、Google Docs、Gmail)Zapier、n8n、Power Automate
生成AIClaude API(Messages API、構造化出力)OpenAI API
保管Google スプレッドシート(故人の台帳・施主の台帳・法要の記録・年忌の表・準備の決まり)Airtable
文書Google ドキュメント(案内状のひな形と、家ごとの案内状)Microsoft Word

新しく足すのは、1本のシナリオと、台帳のスプレッドシートと、案内状のひな形だけです。 紙の過去帳はそのまま寺に残し、スプレッドシートには案内に要る項目だけを移します。 この構成が書き込むのは、台帳の案内の列、Google ドキュメントの案内状、Gmail の下書きだけで、メールは送りません。

定時の実行はシナリオのスケジュールで設定します。 公式のページでは、シナリオは決まった間隔のほか、毎日・平日・毎週・毎月・指定した日付などで動かせるとされています。毎月1日の朝にします。

案内状は Google Docs の Create a Document from a Template で作ります。 公式のページでは、このモジュールはひな形の文書を複製し、文書の中のタグを値に置き換えるもので、新しい文書の名前と保存先のフォルダを指定できるとされています。

文面は Claude API で書きます。 Make の Anthropic Claude のアプリには Create a Prompt と Make an API Call などがありますが、アプリの説明に構造化出力の記載がありません。この構成では Make an API Call で Messages API を呼び、output_config.format に JSON スキーマを書きます。

03どうやって実装するのか

Step1

処理の起点を決める

毎月1日の朝に動かします。 案内は法要の時期の3か月前に出すので、1日に動かせば、その月のうちに住職の確認と郵送が終わります。 毎日動かす必要はありません。命日の月で拾うので、1か月に1回で漏れはありません。

拾う対象は、「3か月後の月」に年忌の命日がある故人です。 1月1日に動けば4月の命日の故人を拾います。命日が月の初めの故人は、案内から法要の時期までが短くなるので、日取りの相談の期限を早めに書くよう、準備の決まりの側で定めます。

手で動かす経路も残します。 台帳に故人を書き足した月や、施主から「今年が年忌か」と問い合わせがあったときに、住職がシナリオを1回だけ動かせるようにします。スケジュールの画面にある「Run once」で動かせます。

1度作った案内は二度作りません。 台帳の案内の段階の列に「下書き済み」と書き、同じ故人・同じ回忌の行に値があれば拾いません。 手で動かしたときに同じ案内が二重にできるのを防ぎます。

Step2

入力データを集める

データ中身取得元
故人の台帳故人の番号、戒名、俗名、命日、施主の番号、案内の段階スプレッドシート
施主の台帳施主の番号、氏名、故人との続柄、住所、メールの希望の有無、最後に確かめた日スプレッドシート
法要の記録故人の番号、回忌、日取り、参列の人数、卒塔婆の本数、会食の有無、住職のメモスプレッドシート
年忌の表回忌の名前と、命日から何年後に当たるかスプレッドシート
準備の決まり日取りの相談の期限、卒塔婆の申込の締切、本堂と客殿の使い方、会食の手配の案内、遠方の施主への案内スプレッドシート

質を決めるのは、準備の決まりの表です。 住職が毎回書き添えていた説明を、項目ごとに1行で書いておきます。 AIは、この表に書かれた決まりの中から、その家に当てはまるものを選んで文にします。表に無い準備をAIが付け足さないように、指示でも縛ります。

法要の記録は、前回の様子を文面に生かすために渡します。 「前回の三回忌には十数名でお参りいただきました」と添えられれば、施主は今回の人数を考えやすくなります。 ただし、住職のメモの列は内部の覚え書きなので、AIには渡しません。

お布施の額は、どの表にも持たせません。 寺の方針として案内状に書かないことにしているためで、AIが一般論で額に触れないよう、指示で禁じます。

Step3

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

取るものどこからどうやって
年忌を迎える故人故人の台帳Search Rows(スプレッドシートの式で出した「次の年忌の年月」が3か月後の月で、案内の段階が空)
施主の情報施主の台帳Search Rows(施主の番号で絞る)
前回の法要法要の記録Search Rows(故人の番号で絞り、日取りの新しい順で1件)
準備の決まり準備の決まりの表Search Rows(すべて。十数行)

何回忌に当たるかは、スプレッドシートの式で出しておきます。 故人の台帳に「次の年忌の年月」と「次の回忌」の列を置き、命日と年忌の表から式で計算します。 シナリオはその列で絞るだけで、数える仕事は表と式に置きます。

年忌の重なりは、もう一度 Search Rows で探します。 拾った故人ごとに、同じ施主の番号で、次の年忌の年が同じ故人を AND の条件で探します。命日の月が違っても同じ年なら見つかるので、同じ年に年忌が重なる家が分かります。重なる故人も材料に入れてAIを呼び、1通の案内状でまとめて相談するか、別々に出すかの確認のメモを住職向けに書かせます。

Update a Row での書き戻しは、行の番号で行います。 公式のページでは、Update a Row は行の番号で対象を指定するとされています。Search Rows で拾った行の番号を残しておき、 書き戻しに使います。

Step4

AIへ渡す前に整形する

  1. 宛先の確認の印 … 施主の最後に確かめた日から3年を超えていれば「宛先の確認」の印を付けます。計算はシナリオの式で行い、AIに渡しません
  2. 重なりの印 … 同じ施主で同じ年に年忌を迎える故人が見つかれば、「年忌の重なり」の印を付けます
  3. 個人の情報を絞る … AIに渡すのは、戒名・俗名・回忌・命日の月日・施主の氏名と続柄・前回の法要の日取りと人数だけです。住所、電話、メール、住職のメモは渡しません
  4. 戒名の扱い … 戒名は台帳の文字列をそのまま渡し、AIの出力からは使わず、ひな形への差し込みは台帳の値から直接行います
  5. 空の項目の確認 … 戒名・命日・施主の氏名のどれかが空の故人は、AIを呼ばずに「台帳の確認」として住職の一覧へ回します

4番目がいちばん大事です。 戒名には常用でない字が多く、AIが文中で書き写すときに、似た字に置き換わることがあります。 案内状の戒名の欄は、台帳の値をひな形に差し込みます。本文の中では戒名を繰り返させず、「故人」「〇〇様」と書かせます。

Step5

AIに処理させる

させるのは、決まった事実と準備の決まりから、その家に合わせた案内状の本文と準備の説明を書き、住職が確かめるべき点をメモにすることです。

書くもの材料書き方
案内状の本文回忌、命日の月日、施主の氏名と続柄、前回の法要の日取りと人数時候のあいさつ、年忌の案内、日取りの相談のお願い。4〜6文
準備の説明準備の決まりの表のうち、当てはまる行箇条書きで、日取りの相談の期限、卒塔婆の申込の締切、会食の案内
住職への確認のメモ年忌の重なり、宛先の確認の印、前回の記録の有無1〜3行。住職が判断すべきことだけ

準備の説明は、表の行を選んで書かせます。 遠方の施主には「遠方からお越しの方へ」の行を、年忌の重なりがある家には「同じ年に年忌が重なる場合」の行を選ばせます。どの行を選んだかを used_rules に返させ、住職が確かめられるようにします。

させないこと理由
何回忌に当たるかの計算年忌の表と式で決める
戒名を文中に書くこと字が置き換わる恐れ。台帳の値を差し込む
お布施の額や目安に触れること寺の方針で案内状に書かない
準備の決まりに無い準備を付け足すこと宗派・寺の作法と違うことを書く恐れ
年忌が重なる家の扱いを決めること住職が施主と相談して決める

4行目がいちばん起きやすい失敗です。 何も言わないと、AIは一般的な法要の準備として「お供え物はお花と果物が一般的です」「平服で構いません」のような説明を足します。寺や宗派によって違うことを、寺の名前で書いてしまいます。

施主への呼び方も、AIに選ばせません。 続柄から「ご尊父様」「ご母堂様」のような言い方を作らせると、続柄の欄の書き方しだいで誤ります。続柄ごとの呼び方を準備の決まりと同じ表に持たせ、 本文では「故 {俗名} 様」とだけ書かせます。呼び方を添えたい寺は、ひな形の側に表の値を差し込みます。

Step6

指示内容を固定する

あなたは寺院の寺務の担当として、檀家の施主に年忌法要の案内状を下書きします。
下の「事実」と「準備の決まり」に書かれていることだけを使ってください。
推測で補わないでください。

【書くもの】
1. letter_body:案内状の本文。時候のあいさつ、年忌の案内、日取りの相談のお願いを
   4〜6文で。丁寧な手紙の言葉づかいで、施主の氏名は「{施主の氏名}様」と書く
2. preparation:準備の説明を、下の「準備の決まり」の行から当てはまるものを選んで
   1行ずつの箇条書きにする。選んだ行の番号を used_rules に入れる
3. memo_for_priest:住職が確かめるべき点を1〜3行で

【厳守事項】
- 回忌、命日、日取りの相談の期限は「事実」に書かれた値をそのまま使ってください。
  計算し直したり言い換えたりしないでください。
- 戒名を本文に書かないでください。故人は「故 {俗名} 様」と書いてください。
- お布施、志、金額、その目安に一切触れないでください。
- 「準備の決まり」に無い準備(服装、お供えの品、作法の説明)を書かないでください。
- 前回の法要の記録が無いときは、前回に触れないでください。
- 年忌の重なりがあるときは、本文で合わせて執り行うとは書かず、
  「ご一緒のご相談も承ります」までにとどめ、memo_for_priest に重なりを書いてください。
- 宛先の確認の印があるときは、memo_for_priest の最初に書いてください。
- 亡くなった方や施主の家族について、記録に無い事情を想像して書かないでください。

【事実】
施主:{施主の氏名}(故人との続柄:{続柄})
故人:{今回の故人と、同じ年に年忌が重なる故人ごとに、俗名・回忌・命日の月日}
前回の法要:{日取り}・{参列の人数}(無ければ「記録なし」)
日取りの相談の期限:{相談の期限}
年忌の重なり:{あり/なし}/宛先の確認:{あり/なし}/遠方:{あり/なし}

【準備の決まり】{preparation_rules}

「計算し直さない」を書くのは、AIが命日から回忌を数え直そうとするからです。 数え直して表と違う回忌を書くと、表で決めた正しい回忌が文面の中で上書きされます。 値は渡したものをそのまま使わせます。

年忌が重なる家の書き方を細かく決めているのは、それが住職の判断だからです。 「お二人の年忌を合わせて執り行います」と書けば、施主が相談する前に寺が決めたように読めます。 本文では相談を受けることだけを書かせ、判断の材料はメモで住職に渡します。

Step7

出力形式を固定する

次の形のJSONで受け取ります。 Make an API Call で Messages API を呼び、output_config.format に JSON スキーマを渡します。

{
  "letter_body": "",
  "preparation": [ { "rule_no": "", "text": "" } ],
  "used_rules": [ "" ],
  "memo_for_priest": ""
}

構造化出力には、公式の決まりがあります。 スキーマのオブジェクトには additionalProperties: false が必要で、数値の最小・最大や文字列の長さの制約は使えず、使うと400のエラーになるとされています。本文の文の数は、スキーマではなく指示で縛ります。

JSON にする理由の1つ目は、ひな形の差し込みに使えることです。 letter_body と preparation をひな形の別々のタグに入れ、戒名・回忌・命日は台帳の値を別のタグに入れます。 AIの書いた文と台帳の事実が、同じ文書の中で混ざらずに並びます。

2つ目は、used_rules で住職が確かめやすくなることです。 どの決まりを選んだかが分かれば、遠方の案内が抜けていないか、重なりの案内が付いているかを一目で見られます。

返ってくる値の例は次のとおりです。

【letter_body】
秋冷の候、皆様にはお健やかにお過ごしのことと存じます。
さて、来る令和九年一月、故 山田太郎 様の七回忌を迎えられます。
前回の三回忌には、ご家族十二名でお参りいただきました。
つきましては、ご法要の日取りを十一月末日までにご相談いただけましたら幸いです。
【preparation】
・日取りのご相談は、電話または寺務所の窓口で承ります(規則3)
・卒塔婆をお申し込みの方は、法要の二週間前までにお知らせください(規則5)
【memo_for_priest】
同じ年に故 山田花子 様の十三回忌(令和九年六月)が重なります。

この例でも、戒名と回忌の欄はひな形の側で台帳から差し込みます。 本文の回忌と命日の月は、渡した事実をそのまま写したものです。

stop_reason も確かめます。 公式のページでは、max_tokens で止まると出力が不完全でスキーマに合わないことがあるとされています。end_turn 以外で止まったものは差し込まず、 住職の一覧に「下書きの作り直し」として回します。

Step8

システムへ連携する

つなぎ先方式内容
故人・施主・法要の記録・決まりの表Google Sheets:Search Rows拾い出しと材料の取得
Claude APIAnthropic Claude:Make an API Call案内状の本文と準備の説明の下書き
案内状Google Docs:Create a Document from a Template家ごとの案内状を作り、その月のフォルダに置く
メールの施主Gmail:Create a draft email同じ内容のメールの下書き
故人の台帳Google Sheets:Update a Row案内の段階と作った日を書く

Gmail は下書きまでにし、送信のモジュールは置きません。 送るのは住職が案内状を確かめた後で、郵送と同じ日に寺務の担当が下書きから送ります。

案内状の文書の名前には、施主の番号と回忌を入れます。 「0123_十三回忌_2027-04」のようにしておけば、その月のフォルダを開くだけで、住職が確かめる順番と抜けが分かります。

ひな形のタグは、事実と文を分けて置きます。

タグ入る値出どころ
施主の氏名・住所施主の台帳の値スプレッドシート
戒名・俗名・回忌・命日故人の台帳の値スプレッドシート
本文letter_bodyClaude API
準備の説明preparation の各行を改行でつないだものClaude API

住所と戒名はAIを一度も通りません。 宛名の誤りと戒名の誤りが、AIの出力から入る経路を最初から作らないためです。

Step9

人が確認する

住職が案内状を1通ずつ読みます。 寺務の担当は、「宛先の確認」の家への電話と、台帳の空欄の確認を受け持ちます。

  1. 住職への確認のメモを先に読む … 年忌の重なりと宛先の確認の印があるものから見ます
  2. 戒名と回忌を台帳と見比べる … 差し込まれた戒名、回忌、命日が台帳と同じかを見ます
  3. 本文と準備の説明を読む … 言葉づかいと、その家に当てはまらない説明が無いかを見て、直します
  4. 年忌の重なりを決める … まとめて相談するか、別々に案内するかを決めます
  5. 直した内容を残す … 直した箇所の多い決まりの行は、表の書き方を見直します

2番目を省かないでください。 戒名は台帳から差し込んでいるので字の置き換わりは起きませんが、台帳に移すときの打ち間違いは、ここでしか見つかりません。 最初の数か月は特に丁寧に見ます。

目標は、40件をならして1件6分です。 読む、直す、印刷して封入する時間を合わせたものです。それより多い月は、準備の決まりの表の書き方が家の事情に合っていません。

Step10

例外に対処する

起きること対応
戒名・命日・施主の氏名が空AIを呼ばず、「台帳の確認」として住職の一覧へ
施主の情報が3年以上確かめられていない「宛先の確認」の印。寺務の担当が電話で確かめてから送る
施主が亡くなっていると分かった新しい施主を台帳に入れ、案内状を作り直す
stop_reason が end_turn 以外差し込まず「下書きの作り直し」へ
構造化出力のスキーマで400未対応の制約を使っていないかを確かめる
同じ故人の案内を二度作りそうになる案内の段階に値があれば拾わない
施主から年忌を行わないと連絡があった台帳の案内の段階に「辞退」と書き、次の年忌まで拾わない

上の3行が大半を占めます。 どれもAIではなく台帳の情報の古さの問題です。案内状を出すたびに施主の情報を確かめ、最後に確かめた日を直していくと、 年ごとに印の付く家が減ります。

Step11

記録を残す

  • 家ごとの案内状の文書(その月のフォルダにそのまま残る)
  • Claude API が返したJSONの全文と、そのときの準備の決まりの表の版
  • 住職が直した後の案内状と、直した箇所
  • 送った日、送った手段(郵送・メール)、施主からの日取りの連絡
  • 宛先の確認の結果と、施主の情報を直した日

直した箇所の記録は、準備の決まりの表を直す材料です。 同じ行の説明が毎回直されるなら、表の書き方がその寺の言い方に合っていません。

04実装レベルの3段階

最小構成:手元のAIの画面に事実を貼り、案内状の本文を書かせる / 文面の下書き
半自動化:上記+台帳から毎月拾い、ひな形に差し込んだ案内状とメールの下書きまで作る / 拾い出し・下書き・差し込み
本格構成:上記+施主からの日取りの連絡を受け付けて法要の予定表に入れ、連絡の無い家に再案内を下書きする / 案内から日取りの確定まで

半自動化で、1件30分が6分になり、この段階が本記事の想定です。 拾い出しと書き分けが自動になり、住職は読んで直すだけになります。 最初の台帳の電子化は、半自動化の前に一度だけ要る作業です。 過去帳のすべてを移す必要はなく、三十三回忌までに当たる故人、つまり直近の三十数年分から始めれば足ります。 本格構成は、日取りの連絡の受け方を決めてからにしてください。 電話で受けることが多い寺では、受けた人が台帳に書く手順が先に要ります。連絡の無い家への再案内は、住職が一覧を見て送るかを決める形のままにします。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
2 名
月間件数
40 件
1件あたり現在時間
30 分
1件あたり導入後時間
6 分
現在  40件 × 30分 ÷ 60 = 20 時間/月
導入後 40件 × 6分 ÷ 60 = 4 時間/月
月間削減時間
16h
削減率
80%
年間削減時間
192h
年間金額換算(時間単価2,000円)
38万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 檀家が数百軒あり、毎月数十件の年忌を迎える故人について、住職や寺務の担当が過去帳を繰って該当を探し、案内状を手書きやワープロで1通ずつ作っている寺院。案内の出し忘れや、施主の代替わり・転居に気づかず古い宛先に送ってしまうことがあり、案内状に添える準備の説明(日取りの相談、卒塔婆やお供え、会食の手配)も家ごとに書き分けている場合。故人と施主の情報を Google スプレッドシートに移す準備ができ、Gmail を使っている場合。
向いていない
  1. 檀家が数十軒で、住職がすべての家の年忌を覚えていられる寺院。年忌の案内を出さず、施主からの申し込みを待つ方針の寺院。過去帳の内容を電子化して外部のサービスに置くこと自体を、寺の方針として避けたい場合。なお、法要の執り行い方、お布施の扱い、宗派の作法に関わる判断は、この構成では代替できません。

07最小構成で試す方法

  1. 来月に年忌を迎える故人から10人を選ぶ(うち数人は、年忌が重なる家、遠方の施主、前回の記録の無い家を入れる)
  2. その10人の事実(回忌、命日、施主、前回の法要)と準備の決まりを、手元のAIの画面に貼る
  3. 第7章の指示で案内状の本文と準備の説明を書かせる
  4. 住職が、自分で書いた場合と比べて読む

10人は必ず試してください。 シナリオを組む前に、「住職がそのまま使えるか、直す量はどれくらいか」を確かめます。 台帳をスプレッドシートに移す手間をかける前に、文面の質を見ます。

出てきた内容判断
少し直せば使える文面が出た台帳の電子化とシナリオに進む
決まりに無い準備やお布施に触れた指示の書き方で直る。構成は有効
寺の言い方と大きく違う準備の決まりの表と、過去の案内状の例を整えるのが先

3行目が出たときは、過去に住職が書いた案内状を数通、例として指示に添えて試し直してください。 寺ごとの言い回しは、決まりの表より例のほうが伝わります。

08実装時につまずきやすいポイント

問題対策
AIが回忌を数え直して書く値をそのまま使わせ、計算をさせない
戒名の字が似た字に置き換わる本文に戒名を書かせず、台帳の値を差し込む
一般的な法要の作法を書き足す決まりの表に無い準備を禁じ、used_rules で確かめる
お布施の目安に触れる指示で禁じる。表にも持たせない
亡くなった前の施主に送る最後に確かめた日で印を付け、電話で確かめる
年忌の重なりを寺が決めたように書く本文は相談を受けるまでにし、判断はメモで住職へ
スキーマに文字数の制約を書いて400長さは指示で縛る
同じ案内が二重にできる案内の段階の列で拾わない
重なる故人を別々の月に二度案内する重なりのメモを見た住職が、まとめるかを決めて台帳に書く
施主の呼び方を誤る続柄ごとの呼び方を表に持たせ、AIに作らせない

上の2行が、この構成の失敗のほとんどです。 どちらも、AIに事実を書き直させることから起きます。事実は台帳から差し込み、AIには文をつなぐ部分だけを書かせます。

5行目は、AIではなく台帳の問題です。 施主の情報は、施主から連絡があったときにしか直りません。案内状に「お届け先に変更がありましたらお知らせください」の一文をひな形の側で必ず入れ、 返ってきた連絡で台帳を直す流れを作ります。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 故人の戒名・俗名・命日、施主の氏名・続柄・住所・メール、法要の記録です。ある家がその寺の檀家であることは、その家の信仰に関わる情報です。

  1. AIに渡す項目を絞る … 住所、電話、メール、住職のメモは渡しません。文面に要る事実だけを渡します
  2. 台帳を見られる人を絞る … スプレッドシートと案内状のフォルダは、住職と寺務の担当だけが見られるようにします。共有のリンクを作りません
  3. 個人情報の扱いを寺として決める … 個人情報保護法の第57条は、宗教団体が宗教活動(これに付随する活動を含む)の用に供する目的で個人情報を扱うときは、同法の第4章の規定を適用しないとしています。一方で、安全管理の措置や苦情の処理などの措置を自ら講じ、その内容を公表するよう努めなければならないともしています。台帳を外部のサービスに置くことを含め、扱い方を寺として決め、檀家に説明できるようにします
  4. 送信を自動にしない … メールは下書きまでで、郵送も住職の確認の後にします
  5. 作法や宗派の説明をAIに書かせない … 準備の説明は寺の決まりの表からだけ書かせます
  6. APIの鍵を寺の中で管理する … Make の接続に入れる Claude の API キーは、作ったときにしか表示されないとされています。住職と寺務の担当のどちらが管理するかを決め、 担当が替わったら作り直します

誤りが起きた場合のリスクは、戒名や施主を誤った案内状を送ることと、案内を出し忘れることの2つです。 前者は事実をAIに書き直させると起き、後者は台帳の移し漏れや宛先の古さから起きます。前者は差し込みと住職の確認で、後者は毎月の拾い出しと宛先の確認で防ぎます。

10まず何から始めるか

1週目:10人で試す

来月に年忌を迎える故人から10人を選び、手元のAIの画面で案内状を書かせます。住職が読み、直す量と、決まりに無い説明を足していないかを見ます。

2週目:準備の決まりの表と年忌の表を作る

住職がこれまで書き添えてきた説明を、項目ごとに1行で書きます。あわせて、回忌と命日からの年数の表を作ります。

3週目:台帳を作る

三十三回忌までに当たる故人から、戒名・俗名・命日・施主を台帳に移します。施主の台帳には、最後に確かめた日の列を置きます。移した戒名は、住職が過去帳と見比べます。

4週目:シナリオを動かす

Make のシナリオで、拾い出しから案内状の差し込みまでを作り、来月分を試しに作って、住職が全件を読みます。

2か月目: 毎月1日のスケジュールで動かし、メールの下書きを足します。直した箇所を記録します。3か月目以降: 直しの記録から準備の決まりの表を直し、1件30分が何分になったかを実測します。施主から「案内が来なかった」という連絡がなくなった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-15/最終更新:2026-10-23
確認した内容情報源確認日
シナリオを決まった間隔・毎日・平日・毎週・毎月・指定した日付などで動かせること。手で動かす(Run once)ことができることMake: Schedule a scenario2026-10-15
Google Sheets のアプリに Search Rows・Update a Row などがあり、Search Rows で AND と OR の条件と並べ替え、返す件数の上限を指定できること。Update a Row が行の番号で対象を指定することMake: Google Sheets modules2026-10-15
Google Docs のアプリに Create a Document from a Template があり、ひな形の文書を複製してタグを値に置き換え、新しい文書の名前と保存先のフォルダを指定できることMake: Google Docs modules2026-10-15
Gmail のアプリに Create a draft email と Send an email があることMake: Gmail modules2026-10-15
Anthropic Claude のアプリに Create a Prompt と Make an API Call などがあり、アプリの説明に構造化出力の記載が無いことMake: Anthropic Claude2026-10-15
構造化出力がスキーマを output_config.format(type: json_schema)に渡して使い、オブジェクトに additionalProperties: false が必要で、数値の最小・最大や文字列の長さの制約に対応せず、使うと400になること。stop_reason が max_tokens のときは出力がスキーマに合わないことがあることClaude: Structured outputs2026-10-15
宗教団体が宗教活動(これに付随する活動を含む)の用に供する目的で個人情報等を扱うときは第4章の規定を適用しないこと。その場合も安全管理の措置等を自ら講じ、内容を公表するよう努めなければならないこと(個人情報保護法第57条第1項第3号・第3項)e-Gov 法令API: 個人情報の保護に関する法律2026-10-15

法要の執り行い方、年忌の数え方、お布施の扱い、宗派の作法は、住職と寺の決まりに従ってください。 本記事は上記の公式ページで確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1725)についてのご相談はこちらから。

AI活用について相談する
目次