会議ファシリテーター輪番
アリス、ボブ、キャロル、ダナの順なら、最初の会議（0回目）はアリス、次はボブ、前回はダナです。ダナの次は最初に戻ります。同じ一覧を使えば誰でも同じ答えになります。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- メンバー一覧
- Alice, Bob, Carol, Dana
- 会議の番号
- 0
- 名簿の人数
- 4
- 担当者
- Alice
- 担当者の番号
- 0
- サイクル内の位置
- 1
定期的なスタンドアップ、オールハンズ、運用レビューは、毎週同じ管理者に負担が集中するのではなく、ファシリテーションが公平に輪番するほうがうまく回ります。この会議ファシリテーター輪番計算機は、順序付きの名簿とゼロ始まりの開催回数インデックスを受け取り、古典的なモジュラー式ラウンドロビン演算を適用して、次のセッションの担当者、その次、そしてサイクル上の前任者が常に分かるようにします。チームはボット、カレンダー、ランブックに同じ決定論的契約を組み込み、誰かが入退社したときにずれる場当たり的な表計算式を発明する必要がありません。
ラウンドロビンによる会議オーナーシップの仕組み
公平なファシリテーター輪番は、固定の順序付き名簿と、その会議がすでに何回開催されたかを示すカウンタにすぎません。カウンタが N に達すると余りはゼロに戻り、最初の人が再びファシリテートし、N に一を足すと二番目の人が司会を取り、うるう週や暦月の特別扱いなしにパターンが続きます。
式が整数除算の余りだけを使うため、同じ名簿順と開催カウンタを共有する二つのクライアントは、タイムゾーンが違ってもオフラインでも常に同じ担当者に一致します。本機能は祝日・休暇・スキップリストを自動では扱いません。欠席者がいれば名簿を編集するか、オーケストレーション層でインデックスを進めます。
コアを純粋に保つことで、チャットボット、GitHub Actions、表計算プラグインが三言語でモジュロを書き直す代わりに、ひとつのオラクルを再利用できます。
輪番の進行役が役立つ場面
エンジニアリングマネージャは週次デモを組み、特定の一人だけが更新する非公開表なしにホストを回したいと考えます。スクラムマスターはスタンドアップの司会を自動化し、同じシニアエンジニアが永遠に時計係にならないようにします。インシデントコマンダーはシフト表と一致する名簿でオンコール儀式の週次オーナーを回します。
人事とピープルオペスは部門横断で月次オールハンズのホストを公平に割り当てます。
活用例
週次スタンドアップ司会の輪番
チーム名簿とスタンドアップの週カウンタを渡し、共有表なしで今日の司会と次の担当を表示します。
公平なオールハンズとデモのホスト
ハンドブックが既に公開している同じ順序の名簿で、月次オールハンズやデモのホストを部門横断で回します。
よくある質問
休暇中の人がいる場合は？
本計算機は欠席をモデル化しません。一時的に名簿から外すか、呼び出し前にオーケストレーション層でそのインデックスを飛ばしてください。
一覧の最後の人の次は誰が進行しますか？
最初の名前に戻ります。アリス、ボブ、キャロル、ダナの場合、五回目の会議は再びアリスとなり、月や特別な週による例外なく同じ順番が続きます。
最初の会議が0回目なのはなぜですか？
すでに開催された会議の数を数えているからです。最初の会議は0回目でアリスが担当します。結果には1から数えた周回内の位置も「4人中1番目」のように表示されます。
次と前の担当者も分かりますか？
はい。今回の進行役に加えて、次と前の担当者も表示されます。最初の会議ではボブとダナで、前回のメモを頼みたいときに便利です。
メンバーが増えたり抜けたりしたらどうしますか？
回す順番どおりに一覧を更新し、会議の回数はそのまま数え続けてください。同じ一覧と同じ回数を使えば誰が計算しても同じ担当者になり、予定表と通知が食い違いません。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/biz/rotating-meeting-owner \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"roster":["Alice","Bob","Carol","Dana"],"meeting_index":0}'const res = await fetch("https://api.kit.forhosting.com/biz/rotating-meeting-owner", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"roster": [
"Alice",
"Bob",
"Carol",
"Dana"
],
"meeting_index": 0
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/biz/rotating-meeting-owner",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"roster": [
"Alice",
"Bob",
"Carol",
"Dana"
],
"meeting_index": 0
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/biz/rotating-meeting-owner", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"roster":["Alice","Bob","Carol","Dana"],"meeting_index":0}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"roster":["Alice","Bob","Carol","Dana"],"meeting_index":0}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/biz/rotating-meeting-owner", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"roster": [
"Alice",
"Bob",
"Carol",
"Dana"
],
"meeting_index": 0
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "biz.rotating_meeting_owner",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
空の名前や負のインデックスは invalid_input で失敗し、課金されません。
ラウンドロビンによる会議オーナーシップの仕組み
最初の開催を meeting_index のゼロ、二回目を一、というように番号付けします。名簿が N 人なら、その開催の担当者は owner_index が meeting_index を N で割った余りに等しい位置にいます。サイクル位置は owner_index に一を足して報告されるので、「このサイクルの四人中三番目」と人手でゼロ始まりを変換せずに言えます。次の担当者は owner_index に一を足して N で割った余り位置の名前、前任者は逆方向にラップし、先週のファシリテーターにメモを依頼するときに便利です。
入力契約、応答フィールド、検証エラー
必須フィールド二つの JSON ボディを POST してください。roster は回転順のファシリテーター名文字列一〜百件の空でない配列で、各要素はトリムされ、トリム後に空なら不正インデックスを明示して invalid_input になります。meeting_index はゼロから十億までの非負整数で、解決するシリーズの何回目かを示し、ゼロが初回です。roster には members、people、facilitators の別名、meeting_index には index、occurrence、week_number の別名が使えるため、既存自動化はペイロード名を変えずに馴染みのキーを写せます。成功時は正規化済み roster と meeting_index、roster_size、owner と owner_index、cycle_position（サイクル内の一始まり）、next_owner と next_owner_index、previous_owner と previous_owner_index、および owner_index が meeting_index を roster_size で割った余りである旨の短い式文字列を返します。例：Alice、Bob、Carol、Dana の名簿で meeting_index が五なら、五を四で割った余りは一なので Bob が担当、Carol が次、Alice が前です。名簿欠落・空・非配列、非整数や負の meeting_index、過大な名簿は invalid_input で失敗し残高を消費しません。任意の出力フィールドに null を埋めることはなく、この単純契約では成功時の各フィールドが常に存在します。
輪番ファシリテーター API が価値を生む場面
プロダクトオペスのボットはカウンタキーに保存したシリーズインデックスで API を呼び、「今週のファシリテーターは…」を Slack や Teams に投稿します。実装はパースのティア A のため、成功した呼び出しは公開の基本価格 $0.002 で、モデルトークンも外向きネットワークもなく、検証失敗は無料です。各記録システムで名簿順を揃え、開催ごとに meeting_index を一度増やせば（回転を進めたいならスキップ週も含めて）、自前のスケジュールサービスを立てずにカレンダー、ランブック、エッジワーカー向けの再現可能な担当決定が得られます。
連携の活用例
チャットボットとカレンダー自動化
各開催でボットがシリーズインデックス付きで API を呼び、Slack、Teams、またはカレンダー説明に「ファシリテーター: …」を投稿します。
技術的な質問
誰の番でファシリテートするかをどう調べますか？
roster（順序付き名前）と meeting_index（初回は 0）を送ってください。担当は roster[meeting_index を名簿長で割った余り] です。
meeting_index はゼロ始まりですか、一始まりですか？
ゼロ始まりです。初回は 0、二回目は 1、と続きます。応答の cycle_position は表示用に一始まりです。
roster の代わりに members を送れますか？
はい。別名 members、people、facilitators は roster に、index、occurrence、week_number は meeting_index に対応します。
会議ファシリテーター輪番計算機の料金は？
ブラウザツールは無料です。API は成功した呼び出しごとに KIT 前払い残高から $0.002 です。無効入力は課金されません。