囲碁・将棋の会所が例会の参加の申込から対局の組合せと手合を Apps Script で決め、成人の会員ごとの組合せの連絡と例会の案内を AI で作って送る

処理の起点を決める

時間主導型のトリガーを毎朝1回動かします。 ClockTriggerBuilder の everyDays(1) と atHour(8) で毎朝8時台を指定します。nearMinute() を呼ばないと分はランダムに決まり、呼んでも前後15分の幅があります。 公式の説明では、毎日9時のトリガーは9時から10時の間のどこかで動き、その時刻が日ごとに保たれます。

毎朝の処理では、例会の日から逆算して次のことをします。

印を待つ処理を「次の朝」にしているのは、トリガーを増やさないためです。 印が付いたらすぐ動かすには編集のトリガーが要りますが、席主が表を直している途中で動くと、直しかけの組で文面ができます。 毎朝の1回で印を見れば足ります。

トリガーは会所のアカウントで作ります。 インストール型のトリガーは作った人のアカウントで動くので、差出人が会所の名前になります。 失敗すると「Summary of failures for Apps Script」のメールが届くので、処理ログに「どの段階で止まったか」を日本語で書きます。

入力データを集める

質を決めるのは、名簿の段級位と「段級位を直した日」の列です。 昇段した会員の段級位が古いままだと、組も手合も古い段級位で出ます。 例会の後に結果を入れるとき、昇段・昇級があれば同じ日に名簿を直すことを手順にします。

「同じ組にしない会員の組み合わせ」は、世話役の頭の中にあった事情を書く場所です。 理由は書かず、会員番号の組だけを入れます。理由を書くと、シートを見た人に事情が伝わってしまいます。

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

すべて同じスプレッドシートの中にあるので、Apps Script のスプレッドシートのサービスで読むだけです。

段級位は点数にしてから並べます。 囲碁なら初段を0、二段を1、1級を−1のように置き、前回の組で全勝なら0.5を足し、全敗なら0.5を引くのように、組分けの決まりのシートにある規則で調整します。点数の付け方は会所の決まりなので、席主が変えられる形にしておきます。

同じ人が2回申し込んだら、後の申込を使います。 「参加」と送った後に「欠席」と送り直すことがあるためです。

点数の付け方の例は次のとおりです。 値はすべて組分けの決まりのシートに置きます。

点数は組の並びを決めるためだけに使い、手合には使いません。 手合は段級位の差だけで手合の表から引きます。点数で手合を決めると、前回の勝敗で置石が変わってしまい、会所の決まりと食い違います。

AIへ渡す前に整形する

1. 参加者を点数の順に並べる … 囲碁と将棋を分け、点数の高い順に並べます
2. 4人ずつに区切る … 上から4人ずつ組にします。4で割り切れないときは、下の組を3人にし、3人の組は席主か世話役との指導対局を1局足します
3. 重なりを避ける … 直近3回の例会で同じ組だった人が2人以上重なる組は、隣の組の点数の近い人と入れ替えます
4. 同じ組にしない組み合わせを外す … 決まりのシートの組み合わせに当たれば、隣の組と入れ替えます
5. 手合を引く … 組の中の対局ごとに、段級位の差から手合の表を引きます
6. 守れなかった箇所に印を付ける … 入れ替えても重なりが残った組、入れ替えで点数の差が大きく開いた組に印を付けます

6番目の印が、席主の確認を短くします。 席主は全部の組を見るのではなく、印の付いた組だけを見て、直すか、そのままにするかを決めます。

文面のための状況は、組合せが確定した後に作ります。

AIに処理させる

させるのは、会員ごとの組合せの連絡の文面を記号入りで組み立てることだけです。

冒頭の一言が、世話役が書きたくて書けなかった部分です。 「前回は上の組へ上がられましたね。今回は少し手ごわい組ですが、楽しんでください」のような一文を、成績の状況の名前から作ります。 勝敗の数そのものは渡しません。

3行目がいちばん起きやすい失敗です。 「相手の◯◯さんは攻めの強い方です」のような一言を足したがります。相手の名前を記号にして渡していても、記号に向けて「強敵」と書くことがあります。 指示で禁じ、検査で「強い」「強敵」「手ごわい相手」の語を見ます。冒頭の一言で組全体を「手ごわい組」と言うのは許し、特定の相手を評する言葉は許しません。

指示内容を固定する

あなたは囲碁・将棋の会所の世話役として、成人の会員に送る例会の組合せの連絡の文面を作ります。
渡された状況だけで書いてください。渡されていないことを足さないでください。

【書く順番】
1. 冒頭の一言（result_state に合わせる。1〜2文）
2. 組合せのご案内（{{組}} と、対局ごとに {{相手n}} {{手合n}} を箇条書きで）
3. 当日のご案内（{{開始時刻}} に始まること、遅れるときは {{連絡先}} へ）
4. 指導対局のご案内（with_lesson が true のときだけ）
5. 次の例会のご予告（{{次回日}}。申込のご案内が届くこと）

【result_state ごとの冒頭の一言】
- promoted：上の組へ上がったことへのねぎらい
- stayed：変わらず楽しんでいただけるようにという一言
- demoted：組が変わったことには触れず、例会への参加のお礼だけ
- first_time：初めての例会への歓迎

【厳守事項】
- 相手の名前、段級位、置石、コミ、駒落ち、時刻、日付は、必ず渡された記号のまま書いてください。
- 特定の相手の強さ、棋風、性格について書かないでください。
- 昇段・昇級の見込み、勝ち負けの予想を書かないでください。
- game が go のときは「打つ」「対局」、shogi のときは「指す」「対局」と書いてください。
- 会員の名前は書かないでください。宛名はこちらで入れます。
- 本文は300字以内にしてください。

【状況】
game: {game}
result_state: {result_state}
group_size: {group_size}
with_lesson: {with_lesson}

game で「打つ」と「指す」を切り替えるのは、小さいようで大事な点です。 将棋の会員に「打つ」と書いた連絡は、会所の連絡として違和感があります。囲碁と将棋を同じ処理で回すので、指示に明記します。

demoted の一言を「触れない」にしているのは、組が下がった理由を本人が一番知っているからです。 AIに任せると「次こそは」と励ましを書きますが、受け取る側の気持ちは人によって違います。

出力形式を固定する

次の形のJSONで受け取ります。 Responses API の text.format に type: "json_schema"、strict: true でスキーマを渡します。

{
  "member_ref": "M-0231",
  "game": "go",
  "subject": "{{例会日}}の例会の組合せのご案内",
  "opening_line": "",
  "body": "",
  "used_placeholders": ["{{組}}", "{{相手1}}", "{{手合1}}", "{{開始時刻}}", "{{連絡先}}", "{{次回日}}"]
}

1つ目の理由は、冒頭の一言を分けて持てることです。 席主が自分で一言を書きたい会員には、opening_line だけを差し替えます。

2つ目は、used_placeholders で組合せの書き漏れが分かることです。 4人の組なら {{相手1}} から {{相手3}} と {{手合1}} から {{手合3}} の6つがそろっているはずで、1つでも欠ければ対局の案内が抜けています。 赤の印を付けて送りません。

Structured Outputs には決まりがあります。 公式の説明では、すべてのフィールドを required にし、additionalProperties: false を指定する必要があります。game のような決まった値は enum で絞ります。モデルが安全上の理由で応じなかったときは、応答に refusal のフィールドが入るとされているので、refusal があればその会員を飛ばし、確認のシートに出します。

リクエストでは store を false にします。 公式の説明では、Responses API は store が true のとき、アプリの状態を既定で30日保持します。会話を続ける使い方ではないので保存しません。また、API に送ったデータは、明示的に共有を選ばない限りモデルの学習や改善に使われないとされています。

システムへ連携する

送るときは name で差出人を会所の名前にし、replyTo を世話役のアドレスにします。 会員が「当日少し遅れます」と返信したとき、世話役に届くようにするためです。

1日の送信先の数を数えます。 公式の上限は、メールの受信者の数が個人の Google アカウントで1日100、Google Workspace で1日1,500です。例会の10日前に全会員120名へ申込のリンクを送る日は、個人のアカウントだと上限を超えます。 囲碁と将棋で送る日を1日ずらすか、会所のアカウントを Google Workspace にします。

掲示用の組合せの表も書き出します。 メールの無い会員のために、確定した組合せを組ごとに並べたシートを作り、席主がそれを印刷して掲示板に貼ります。 掲示用の表には会員の名前を出しますが、AIの文面は使いません。

人が確認する

確認は2回あります。

1. 席主が組合せの表を見る … 印の付いた組（重なりが残った・点数の差が開いた）を見て、直すかそのままにするかを決めます。直した箇所は、次から決まりのシートに足すかを考えます
2. 世話役が文面を流し読みする … 赤は直し、黄は読んで判断します。印の無い文面は件名と冒頭の一言だけ見ます

1回目は例会ごと、2回目は会員ごとです。 1回目は組の数（60名なら15組）を見るだけで、数十分かかっていた組分けが、印の付いた数組の判断に変わります。

席主が組を直すときは、確認のシートの組の欄を書き換えるだけにします。 入れ替えた会員の手合は、印を付け直した次の朝に Apps Script が手合の表から引き直します。席主が手合まで手で書き直す必要はありません。

目標は、240件をならして1件0.5分です。 時間を使うのは席主の組合せの確認と、電話の申込の入力です。

例外に対処する

上から3行目までは、AIの問題ではありません。 組分けの決まりと名簿の付け方の問題で、確認のシートに出たものを直すたびに、翌月の例外は減ります。

記録を残す

• 実行の日時、対象の例会、参加者の数、作った組の数
• 組分けの計算の結果と、席主が直した箇所と、直した理由の種類（重なり・事情・点数）
• OpenAI API に渡した状況（氏名なし）と、返ってきた JSON
• 検査の結果と、世話役が文面を直したかどうか
• 送った会員の数、掲示用の表を書き出した日時

2つ目は、組分けの決まりを育てる材料です。 席主が毎回同じ直し方をしているなら、それは決まりに足せます。決まりが育つほど、席主が直す箇所は減ります。