incident.ioにおけるオンコール体制と通知方法：スケジュール、ローテーション・シフト、代替割り当て、カバー依頼、エスカレーション（問題の段階的な報告）経路、および通知（エスカレーション）に関する情報を扱います。 次のような場合に使用： - スケジュール、エスカレーション、カバー依頼のいずれかを何らかの方法で操作する場合 - 単純な情報確認（「今夜は誰がオンコール？」「私の次の番は？」など） - 通知の送信（「Avaに通知を送る」「自分の通知を確認」「誰か確認した？」など） 重要：最初のスケジュール・エスカレーション・カバー依頼関連のツール呼び出しの前に読み込んでください。これらのツールは生のシフトデータとレベル情報を返しますが、このスキルがそれらの読み方を説明します。
Who is on call in incident.io and how they get paged: schedules, rotas and shifts, overrides, cover requests, escalation paths, and pages (escalations). Use whenever you're working with any of these in any way, including plain reads ("who's on call tonight?", "when am I next on?") and paging ("page Ava", "ack my page", "has anyone acked?"). Load it before the first schedule, escalation or cover-request tool call: the tools return raw shifts and levels, and this skill says how to read them.
スケジュールは複数のローテーションを含み、各ローテーションにはメンバーとレイヤー（同時に配置される職位で、「主担当者」「副担当者」などが例）があります。「主担当者」はレイヤーの名前であり、ローテーションではありません。シフトはこの設定から計算されるため、ロスターは保存されるのではなく、指定した時間枠でレンダリング（画面表示）されます。**変更（オーバーライド）**は一定期間ローテーションの上に重ねられ、誰がオンコール対応するかを変更します。その変更によって生じるシフトにはoverride_idが付きます。これにより、後でその変更を見つけて取り消すことができます。カバーリクエストはより丁寧な選択肢で、スケジュールのメンバーにボランティアを呼びかけるもので、承認されたリクエストが変更を自動作成します。
表示されるのはincident.ioのネイティブスケジュールのみです。組織がPagerDutyやOpsgenie などの外部サービスでオンコール管理を行っている場合、ツールはそのことを明示します。これは、誰がオンコール対応しているかを把握できないということであり、誰も対応していないわけではありません。incident.ioでオンコール管理を行っていない組織の場合、ここで読み取ったり変更したりすることはありません。その場合は、存在しないスケジュールを探すのではなく、明確にそう説明してください。
このセクションだけが実行環境に依存します。以下の説明ではツール名をそのまま使用し、呼び出し方法がどうであれ適用されます。
ツールはincident.ioの接続上にあり、このスキルが使用する名前で呼び出されます。
schedule_showは、指定した時間枠でスケジュールのローテーションとシフトをレンダリングします。時間枠は過去にも遡れます（「先週の火曜夜は誰がオンコール対応していた？」など）。shifts_truncated: trueは、部分的な情報を要約するのではなく時間枠を狭めることを意味します。uncovered: trueのシフトは、そのレイヤーで誰もオンコール対応していない期間であり、そのレイヤーへのアラートは誰にも届きません。override_idがあれば、変更でそのギャップを埋めた；なければ、ロスター自体にギャップがあります。
「私はオンコール対応していますか？」「次に対応するのは誰ですか？」は、userフィルタを付けた1回のschedule_list呼び出しで答えられます。質問者の場合は"me"、他のユーザーの場合はユーザーIDまたはメールアドレスを使用します。各結果には、そのユーザーの進行中のシフトと次のシフトが含まれます。スケジュール全体を取得して自分で計算しないでください。
cover_request_listはカバーリクエストを探します（「私の未処理リクエスト」「ミリーのリクエスト」など）。応答および管理ツールが必要とするcover_request_idを返します。デフォルトでは保留中のリクエストが対象です。userまたはschedule_idでフィルタして範囲を絞ってください。
「誰がアラートを受け取りますか？」はロスター管理ではなくエスカレーション（段階的対応）に関する質問です。escalation_path_showは各レベルで現在のオンコール対応を解決し、各レベルのschedulesはそこでアラートを送るスケジュールを示します。「このスケジュールを使用するのは何か」を答えるときもこのパスを確認してください。ツールに表示されない参照は、存在しないのではなく未確認です。見えなかったものについて説明してください。チームのパスはチームから来ます。team_showでチームが所有するパスをリストアップしてください。パス名がチーム名に似ているからという理由でパスを選ばないでください。
連絡先として誰かを引き継ぐときは、実際に連絡が取れるか確認してください。user_listでinclude_inactive: trueを付けて検索し、stateとseat_typeを読んでください。このフラグがないと、非アクティブユーザーは表示されません。アラートを受け取れるのはon_callまたはon_call_responderシートのみです。ロスターはresponder、viewer、または非アクティブユーザーを彼らのシフトでレンダリングしますが、誰もアラートを送ることはできません。直接送付すら不可です。そのことを説明し、次に引き継ぐ人物も同じ方法で確認してください。単純な「誰がオンコール対応しているか」という質問は確認不要です。
ページ上のターゲットがnot_paged_reasonを持つ場合、そのターゲットはアラートを受け取っていません（他のレコード情報がどうであれ）。理由がないターゲットは、アラートが到達したことの証明ではありません。そのユーザーがアラートを受け取ったと述べる前に、同じ方法でそのユーザーのシートを確認してください。
ページ上で、escalation_createをパスで呼び出すと、下書き（suggestion）が返され、実際のページではありません。card_posted: falseの場合、ユーザーが操作するまで誰も見ません。ユーザーがページを要求したときは、action: executeとsuggestion_idのみで送信し、誰に届くかを伝えてください。card_posted: trueの場合、カードは会話に表示されており、ユーザーが受け入れることができます。ユーザーにそのカードを指す。下書きをページと呼ばないでください。
サービスまたはコンポーネントの誰がオンコール対応しているかについては、まずカタログを通じて解決してください。その過程は正しいエスカレーションパスで終わります。ロスターはしばしばカバーする対象の名前が付けられているため、カタログに答えがない場合は、「判断できない」と述べる前に、Xという名前のスケジュールを探してください。
指示はロスターを今すぐ変更します。リクエストは事前に人に尋ねます。「私をオンコール対応にする」「サラさんをはずす」「次の2時間私をカバーしてほしい」（決定として述べられた場合）は変更です。「誰か私のシフトをカバーできますか？」「アレックスに金曜日を引き受けるよう依頼してください」はカバーリクエストです。たとえ人が指名された場合でも、依頼することは依頼であることに変わりありません。
変更（オーバーライド）:
変更は、アラート対象を即座に本当に変更します。ユーザーが要求し、誰がカバーするか、どのロスター、いつからいつまでかがわかれば、それを作成して正確に報告してください。まず確認を求めないでください。人や時間枠が曖昧な場合、または異なるシフト間のスワップ（以下参照）の場合だけ、まず確認してください。リマインダー、ユーザー自身の保留中リクエストのキャンセル、読み取りは確認不要です。
NOBODYは配置されたレイヤーを時間枠内でクリアします。ロスターをカバーなしにしたいと明確に要求された場合のみ使用します。その後、そのレイヤーへのアラートが時間枠内でどこにも届かないと明確に述べてください。単に「誰もオンコール対応していない」と述べるのではなく、スケジュールの他のレイヤーでもオンコール対応している人を名前で挙げてください。
スワップは2つの変更で、各シフト1つずつです。2つのシフトが異なるレイヤーにあるか、長さが異なる場合は、まず確認してから実行し、各ユーザーが何を引き受けることになるかを説明してください（たとえば、連続した週など）。それ以外は、両方を作成して両方を報告してください。
複数のローテーションまたはレイヤーを持つスケジュールにはrotation_idとlayer_idが必要です。ないと作成は拒否されます。schedule_showは各ローテーションのレイヤーを名前でリストアップし、すべてのシフトはlayer_nameを含むため、「主担当」はPrimaryという名前のレイヤーです。変更を、置き換えられる人が保有するレイヤーに配置してください。既存の変更を置き換える場合でも同じです。
変更を作成すると、同じローテーションおよびレイヤーで重複する既存の変更は置き換えられます。作成結果はdisplaced_overridesとしてこれらをリストします。置き換えた人をユーザーに伝え、意図していない場合は時間枠を狭めることを提案してください。
1つを元に戻すには、schedule_override_deleteを、作成結果のoverride_idから、またはschedule_showの結果のシフトから取得したoverride_idで呼び出してください。変更を削除しても、その作成で置き換えられたものは戻りません。そのような作成を戻すときは、削除だけでは復元されず、displaced_overridesから再作成してください。
カバーリクエスト:
リクエストを作成する前に、またはだれに頼むかを提案する前に、そのシフトについてcover_request_listで保留中のリクエストを確認してください。存在する場合は、既に誰に依頼したか、誰が対応したかを述べ、別のリクエストを作成するのではなく、そのリクエストを促してください。cover_request_createはどうせ重複は拒否します。
cover_request_createでリクエストを作成します。リクエスター（依頼者）は要求された時間枠中にオンコール対応していなければなりません。自分のシフトのカバーだけを依頼できます。ユーザーが誰がカバーすべきかを指名する場合（「アレックスに私のシフトを引き受けてもらえますか？」）、その人だけをcandidate_user_idsに渡してください。人を指名してもリクエストは変更に変わりません。
リクエストmessageを一人称で、リクエスター視点で書いてください。
候補者はcover_request_respondで応答します。承認する（変更は自動作成されます）、辞退する、またはウィンドウの一部を提供します。リクエスターはcover_request_manageで自分のものを操作します。保留中の状態でキャンセルする、部分的なオファーを承認する（リクエストの候補からcandidate_user_id）、または返答していない人に促す。
どちらもcover_request_idが必要です。ユーザーがリクエストを指す場合（「彼らにリマインダーを送る」「ミリーのシフトを引き受ける」）で、それを直接渡されていない場合は、先にcover_request_listで見つけてください。
返答でスケジュール、変更、カバーリクエストを名前で参照してください。ULIDで参照しないでください。フォローアップアクション（次のアクション）に必要なIDは、この会話のツール結果に既にあります。ユーザーに尋ねるのではなく、そこから読んでください。
明確なタイムゾーンラベル付きで時刻を述べてください。ユーザーのタイムゾーンが既知の場合は、生のUTC形式ではなく、ユーザー向けにレンダリングされた形式で表示します。
変更後は、何が変わったかを説明してください。誰がいつまで新たにオンコール対応するか（それまでは誰だったのか）。単に「完了」と述べないでください。
A schedule holds rotations, each with members and layers: the positions
filled at the same time, like Primary and Secondary. "Primary" names a layer, not a
rotation. Shifts are computed from that configuration, so the rota isn't stored — it's rendered
for a time window. An override sits on top of the rotation for a window and changes
who is on call; the shifts it produces carry an override_id, which is how an override
is found and undone later. A cover request is the polite alternative: it asks the
schedule's members to volunteer, and an accepted request creates the override itself.
Only native incident.io schedules are visible. When an organisation manages on-call in an external provider (PagerDuty, Opsgenie…), the tools say so — that means we cannot see who is on call, never that nobody is. An organisation that doesn't run on-call in incident.io at all has nothing here to read or change: say so plainly instead of hunting for schedules that can't exist.
This section is the only part that depends on where you run. The rest of the skill names tools by their bare names and applies however you call them.
The tools are on the incident.io connection, called by the names this skill uses.
schedule_show renders a schedule's rotations and shifts over a window you choose —
the window may reach into the past ("who was on call last Tuesday night?"), and
shifts_truncated: true means narrow the window rather than summarise a partial
picture. A shift with uncovered: true is a stretch nobody is on call for, so pages
for that layer reach no one. With an override_id, an override cleared it; without
one, the rota itself leaves the gap.schedule_list call with the
user filter — "me" for the asker, a user ID or email for anyone else. Each result
carries that user's in-progress and next shift; don't fetch whole schedules and
compute it yourself.cover_request_list finds cover requests — "my open request", "Milly's request" —
and returns the cover_request_id the respond and manage tools need. It defaults to
pending requests; filter by user or schedule_id to narrow.escalation_path_show resolves current on-call at every level, and each level's
schedules names the schedules it pages. That is also how to answer "what uses this
schedule": check the paths. A reference the tools don't show is unchecked, not absent,
so say what you couldn't see rather than that nothing depends on it. A team's path comes
from the team: team_show lists the paths it owns. Never pick a path because its name
looks like the team's.user_list and include_inactive: true, then read state
and seat_type. Without that flag, a deactivated person just doesn't appear. Only an
on_call or on_call_responder seat can be paged. The rota still renders a
responder, a viewer or a deactivated person on their shifts, but nobody can page
them, not even directly. Say so, and check whoever you name as taking over next the same
way. A plain "who's on" question doesn't need the check.not_paged_reason was never paged, whatever else the record
shows. A target without one isn't proof it arrived: check that person's seat the same
way before saying the page reached them.escalation_create on a path returns a draft (suggestion), not a page. With
card_posted: false, nobody sees it until you act: when the user asked for the page,
send it with action: execute and only its suggestion_id, then say who it reaches.
With card_posted: true, the card is in the conversation for the user to accept, so
point them to it. Never call a draft paged.An instruction changes the rota now; a request asks people first. "Put me on", "take Sarah off", "cover me for the next 2 hours" (said as a decision) are overrides. "Can someone cover my shift?", "ask Alex to take Friday" are cover requests — even when a person is named, asking is still asking.
Overrides:
NOBODY clears the layer it's placed on for the window; use it only when asked to leave
the rota uncovered. Afterwards, say plainly that pages for that layer reach no one in
that window, not just that nobody is on call, and name anyone still on call on the
schedule's other layers.rotation_id and layer_id, or
the create is refused. schedule_show lists each rotation's layers by name, and
every shift carries layer_name, so "primary" is the layer named Primary. Put the
override on the layer held by the person being replaced, even if that displaces an
existing override.displaced_overrides — tell the user who you
displaced, and offer to narrow the window if that wasn't intended.schedule_override_delete takes the override_id from the create's
result or from the shift it produced in schedule_show. Deleting an override doesn't
bring back the ones the create displaced, so when you revert such a create, recreate them
from its displaced_overrides rather than calling it restored on the delete alone.Cover requests:
cover_request_list for a pending
request on that shift. When one exists, say who it has already asked and who has
responded, and nudge it rather than raising another.
cover_request_create refuses a duplicate anyway.cover_request_create raises one. The requester must be on call during the
requested window — you can only ask for cover of your own shift. When the user
names who should cover ("can Alex take my shift?"), pass just that person in
candidate_user_ids — naming a person doesn't turn the ask into an override.message in the first person, as the requester.cover_request_respond: accept (the override is created
automatically), decline, or offer part of the window. The requester drives theirs
with cover_request_manage: cancel while pending, accept a partial offer
(candidate_user_id from the request's candidates), or nudge non-responders.cover_request_id: when the user points at a request rather than
handing you one ("remind them", "I'll take Milly's shift"), find it with
cover_request_list first.原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。