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 ネイティブのスケジュール（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 としてシフトに表示されることもありますが、誰もそれらの人にアラートを送ることはできません。直接送信もできません。そのことを伝え、次に引き継ぐ人物についても同じように確認してください。「誰がオンコール中か」という簡単な質問では確認は不要です。
「何のアラートを受け取りましたか？」「何が私を起こしましたか」「アラートを見落としましたか」は質問者自身のアラートを読みます。escalation_list で user: ["me"]を指定します（または incident.io デスクトップアプリで escalations_list を使用）。新しい順に表示されます。各アラートは通常、発火の理由である alert_title と、関連するインシデント（事象）の incident_reference と incident_name を持っています。多くのアラートはインシデントに関連しないため、その場合アラートと警告が答えとなり、インシデントを探す必要はありません。you は各アラートが対象者を狙ったかどうか、そして確認応答（ack）したかどうかを示すため、リストから答え、すべてのアラートを開く必要はありません。
アラートの対象者に not_paged_reason がある場合、そのレコードが他に何を示していても、実際にはアラートを受け取りませんでした。対象者にそれがない場合も、アラートが到達したことの証拠にはなりません。アラートがその人に届いたと言う前に、その人の座席を同じ方法で確認してください。
サービスやコンポーネントのオンコール担当者を知るには、まずカタログを通じて確認してください。その過程は正しいエスカレーションパスで終わります。ローテーションはカバーする対象にちなんで名付けられることが多いため、カタログに答えがない場合、「X」という名前のスケジュールを探してから「判明しない」と言ってください。
アラート送信には incident.io でのオンコール管理が必要です。escalation_create ツールがない場合、代わりのやり方を作り出すのではなく、そのアラート送信が利用不可であることを伝えてください。間違った人にアラートを送ると、午前3時に無関係な何かで起動させてしまい、送ったアラートは取り戻せません。そのため：
明示的な指示がない限りドラフト保存してください。 直接送信するのはユーザーが明確にアラート送信を指示し、明白な対象者が正確に1人いる場合のみです。対象者が特定されていない、曖昧、またはぼんやりした一致の場合は、まず質問してください。チームをデフォルトにしないでください。
質問はリクエストではありません。 「バックエンド チームにアラートを送信できますか？」または「これの第1段階は誰ですか？」は可能性を尋ねています。答えて、誰にアラートを送信できるかを名前で示しますが、誰にも送信しないでください。
すべてのID を先に確認してください。 ユーザー、優先度、またはエスカレーションパスはカタログまたはユーザーリストから来ます。ルックアップが複数の候補を返す場合は、どれかを尋ねてください。
escalation_create をパスに対して実行するとドラフト（suggestion）が返され、アラートではありません。card_posted: false の場合、アクションを起こすまで誰も見ません。ユーザーがアラート送信を指示した場合、action: execute と suggestion_id のみで送信し、誰に到達するかを伝えてください。card_posted: true の場合、カードは会話内に表示されており、ユーザーが承認できるので、カードを指すだけです。ドラフトを送信済みアラートと呼ばないでください。
escalation_respond は送信されたアラートに応答します。確認応答（「了解しました」）はパスの上昇を停止し、否認は次のレベルに進みます。
ユーザーがどのアラートを見るかを尋ねてきたら、最近のアラート1つにつき1行（タイトル、関連するインシデントの参照と名前、送信からの経過時間）で提示し、新しい順に表示して、1つを勧めてください。ユーザーがそれを選ぶまで、どのアラートのインシデントについても説明しないでください。
指示はローテーションを今すぐ変更します。リクエストは先に人に尋ねます。「私をオンにしてください」「サラをはずしてください」「次の2時間カバーしてください」（決定として述べられている）はオーバーライドです。「誰か私のシフトをカバーできますか？」「アレックスに金曜日を引き受けるよう頼んでください」はカバーリクエストです。たとえ人が指定されていても、尋ねることは尋ねることです。
オーバーライド：
オーバーライドは、アラート送信対象を即座かつ実際に変更します。ユーザーが指示し、誰がカバーするか、どのローテーション、いつからいつまでかを判断できれば、作成して正確にそれを報告してください。事前に確認をとらないでください。人または時間帯が曖昧な場合、または異なるシフト間のスワップの場合（以下参照）のみ事前に確認してください。リマインダー、ユーザー自身の保留中リクエストのキャンセル、読み取りは確認を必要としません。
NOBODY は配置されたレイヤーを時間帯でクリアします。ローテーションをカバーなしにするよう指示されたときのみ使用してください。その後、そのレイヤーへのアラートがその時間帯では誰にも届かないことをはっきり伝え、スケジュールの他のレイヤーでまだオンコール中の人を名前で示してください。
スワップは2つのオーバーライドで、各シフトに1つずつです。2つのシフトが異なるレイヤーにあるか長さが異なる場合、事前に確認して、各人が最終的に何を得るか（例えば、連続する週）を伝えてください。そうでなければ、両方を書き、両方を報告してください。
複数のローテーションまたはレイヤーを持つスケジュールには rotation_id と layer_id が必要です。ないと作成が拒否されます。schedule_show は各ローテーションのレイヤーを名前で一覧表示し、すべてのシフトは layer_name を持つため、「プライマリー」は「Primary」という名前のレイヤーです。置き換えられている人が保持するレイヤーにオーバーライドを配置してください。既存のオーバーライドを置き換えてしまう場合でも。
オーバーライドを作成すると、同じローテーションとレイヤーで重複する既存のオーバーライドが置き換わります。作成結果はこれらを displaced_overrides として一覧表示します。置き換えた人をユーザーに伝え、意図していない場合は時間帯を絞るよう提案してください。
1つを取り消すには、schedule_override_delete で作成結果またはそれが schedule_show で生成したシフトから override_id を取得します。オーバーライドを削除しても、作成時に置き換えられたものは戻りません。そのような作成を戻す場合、削除だけでは復元されたとは言わず、displaced_overrides から再作成してください。
カバーリクエスト：
1つを作成するか、誰に尋ねるかを提案する前に、そのシフトについて cover_request_list で保留中のリクエストを確認してください。1つ存在する場合、既に誰に尋ねたか、誰が応答したかを伝え、別のリクエストを作成するのではなく、そのリクエストを促してください。cover_request_create は重複を拒否します。
`cover_
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.escalation_list with user: ["me"] (or escalations_list, where the incident.io
desktop app adds it), newest first. Each page carries
alert_title, usually the reason it fired, and its incident's incident_reference and
incident_name when it has one. Many pages have no incident; then the page and its alert
are the answer, so don't go looking for one. you says whether each page targeted them and
whether they acked it, so answer from the list rather than opening every page.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.Paging needs the organisation to run on-call in incident.io: with no escalation_create
tool, say paging isn't available to them rather than improvising a substitute. Paging the
wrong person can wake them at 3am for something that wasn't theirs, and a page can't be taken
back, so:
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.escalation_respond answers a page the user was sent: ack ("I've got this") stops it
climbing the path, nack sends it on to the next level.When the user asks which page to look at, offer one line per recent page (title, its incident's reference and name, how long ago), newest first, and recommend one. Don't catch them up on any page's incident until they've picked it.
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 による自動翻訳です。