AIでオンラインイベントの出席者一覧を作るときは、入退室ログの行数を人数として数えません。同じ人の再接続、申込取消後の接続、当日参加、本人を特定できない表示名を分け、何を分母にするかを先に固定します。
この記事では、架空の申込者4人と接続ログ6行を照合します。成果物は、申込者ごとの接続確認と、対応が未確定のログを残した一覧です。実際の参加記録の取得、AIによる名寄せ、出席認定、案内送信は行っていません。
目次
申込、接続、出席条件を別にする
申込みがあること、イベントへ接続した記録があること、出席条件を満たすことは異なります。今回の例は、取消を除く申込者について「1回以上の接続」と「合計15分以上の接続」を別々に数えます。15分は説明用の独自条件で、学習や視聴内容の理解を認定する基準ではありません。
Google Meetの公式説明には、出席レポートの氏名、メール、参加・退出時刻、滞在時間が記載されています。また、同じ人が何度も入退室した場合は複数の時刻をすべて表示せず、全体の通話時間を含むと説明しています。レポートが接続単位か、参加者単位で集約済みかを確認してから数えます。Google Meet：出席状況の確認（新しいタブで開く）
以下のログは、方法を説明する独自の接続単位の架空表です。Google Meetの出力を再現した表ではありません。対象機能が手元の契約や設定で利用できるかも未確認です。
申込一覧を、集計時点の状態で固定する
対象イベントは架空の2026年11月4日9～10時、日本時間とします。次の申込状態はイベント開始時点の確定版です。
表は横にスクロールできます
| 人ID | 申込状態 | 今回の申込者集計 |
|---|---|---|
| P01 | 有効 | 含める |
| P02 | 有効 | 含める |
| P03 | 有効 | 含める |
| P04 | 取消済み | 除く。接続があれば別確認 |
有効申込者は3人です。P04を含めた4人を分母にする集計を作るなら、取消を含む値と明示します。後から接続が見つかっただけで、P04の申込状態を有効へ書き換えません。
申込者とログの対応には、承認済みの識別子や確認記録を使います。表示名が似ているから、同じ会社だから、という理由でAIに本人を決めさせません。家族や会議室などの共有接続では、一つの接続を一人と数えてよいかも確認が必要です。
再接続の行と、未対応の行を残す
次の6行について、J01～J05は人IDとの対応が確認済みという架空設定です。P05は申込一覧にない当日参加者として別の確認記録があります。J06の表示名「Guest」は本人を確認できていません。
表は横にスクロールできます
| ログID | 対応する人ID | 接続時間 | 扱い |
|---|---|---|---|
| J01 | P01 | 20分 | 1回目の接続 |
| J02 | P01 | 35分 | 再接続。J01とは時間が重ならない |
| J03 | P02 | 10分 | 接続確認 |
| J04 | P04 | 30分 | 取消済み申込者の接続 |
| J05 | P05 | 40分 | 申込一覧にない当日参加 |
| J06 | 未対応 | 20分 | 表示名Guest。本人確認待ち |
P01は2行ありますが、一人です。この例では2区間が重ならないと確認した条件なので、20＋35＝55分とします。実ログに同時接続や重複区間があるなら、単純加算せず、重なりをどう数えるかを決めて確認します。
6行のうち人IDが分かる5行には、P01・P02・P04・P05の4人が対応します。J06がこの4人の誰かか、別の人かは未確認なので、「全参加者は5人」と確定しません。未対応の1行を消して人数を整えないでください。
有効申込者の接続状況を照合する
表は横にスクロールできます
| 有効申込者 | 対応する接続 | 合計時間 | 1回以上の接続 | 例の15分条件 |
|---|---|---|---|---|
| P01 | J01、J02 | 55分 | 確認 | 満たす |
| P02 | J03 | 10分 | 確認 | 満たさない |
| P03 | なし | 対応する記録なし | 確認できず | 確認できず |
今回提供したログの範囲では、有効申込者3人中2人に接続が対応し、2÷3で約66.7%です。15分条件を満たすのは3人中1人、約33.3%です。どちらも同じ「出席率」とだけ書かず、接続確認か、今回の時間条件かを列名へ示します。
P03は対応するログがありませんが、J06の本人が未確定です。このため、P03が確実に欠席したとは断定できません。表示するのは「現時点で接続を確認できた人数」であり、未解決ログを照合した最終値ではありません。ログ自体の欠落や対象回の取り違えも、実際には確認する必要があります。
P04の30分とP05の40分は別の確認一覧へ残します。有効申込者3人の中の出席人数へ足すと、分母と対象が変わります。当日参加を含む別指標が必要なら、その対象者一覧を改めて決めてください。
固定例の人数と時間を検算する
次のPythonは、対応済みの人IDを使った計数です。本人確認、接続時間の重複除去、実サービスのレポート取得を行うコードではありません。
from fractions import Fraction
registration = {"P01": "ACTIVE", "P02": "ACTIVE",
"P03": "ACTIVE", "P04": "CANCELLED"}
logs = [("J01", "P01", 20), ("J02", "P01", 35),
("J03", "P02", 10), ("J04", "P04", 30),
("J05", "P05", 40), ("J06", None, 20)]
active = {p for p, state in registration.items() if state == "ACTIVE"}
minutes = {}
for log_id, person, duration in logs:
if person is not None:
minutes[person] = minutes.get(person, 0) + duration
connected = active & set(minutes)
qualified = {p for p in connected if minutes[p] >= 15}
unresolved = [log_id for log_id, p, _ in logs if p is None]
assert len(logs) == 6 and len(minutes) == 4
assert minutes == {"P01": 55, "P02": 10, "P04": 30, "P05": 40}
assert connected == {"P01", "P02"}
assert qualified == {"P01"}
assert unresolved == ["J06"]
assert active - connected == {"P03"}
assert Fraction(len(connected), len(active)) == Fraction(2, 3)
assert Fraction(len(qualified), len(active)) == Fraction(1, 3)
print(minutes, connected, qualified, unresolved)
掲載例を実行し、別の検算でも人ごとに元ログを列挙して、P01の2行と55分、有効申込者内の2人・1人を照合しました。対応できなかったログを人数へ足さないこと、取消済みと当日参加を分母へ混ぜないことも確認しています。
実務では、識別子の欠損、申込みの重複、複数端末、ホストや運営スタッフ、対象時間外の接続をどう扱うかを先に決めます。時間条件の15分ちょうどを含むかも明記し、後から合格人数に合わせて条件を変えません。
AIには、本人の推測より確認事項を返させる
架空の申込者一覧と接続ログを照合してください。
J01～J05の人IDは確認済み、J06は未対応です。表示名で本人を推測しないでください。
有効申込者P01・P02・P03を分母とし、取消P04、当日参加P05、未対応J06を別欄に残してください。
1回以上の接続と、合計15分以上の条件を分けて返してください。
P01の2接続は時間が重ならない設定です。2人と数えないでください。
未対応ログがあるため、P03の欠席とイベント全体の実人数を確定しないでください。
出力：元ログ付きの照合表、分母付き集計、未解決事項。
申込状態の更新、出席認定、参加者への送信は行いません。
依頼と表は手製で、AIの正答率を測ったものではありません。未対応ログを確認し、必要なら対象者一覧や対応表の版を更新して再集計します。接続を確認したことを、本人の視聴、理解、受講修了、連絡への同意へ読み替えないでください。
参考資料
公式資料の確認日：2026年10月20日。申込み、接続ログ、対応関係、時間条件、依頼文は独自の架空例です。掲載コードと別方式の計数をローカルで検査しました。実ログ取得、本人確認、AI名寄せ、出席認定、連絡、製品の利用条件、画面表示は未検証です。