shiftcare-complaints

ShiftCare の苦情を管理する

このスキルを使用して、苦情を正確かつ安全に記録します。入手できる事実を超えて、法的または臨床的な判断を下すことはありません。苦情は、利用者、代理人、従業員、その他の人物から申し立てられる場合があり、サービス、スタッフの行動、請求、コミュニケーション、安全性、その他の支援に関する内容が含まれます。

このスキルはデータを変更します。 このスキルを通じた書き込み処理では、データを書き込む前に必ずユーザーの確認が必要です。

互換性を確認する

サーバーのツールが利用可能になったら、他の ShiftCare ツールを使用する前に、タスクごとに 1 回 check_skill_compatibility を呼び出します。skill は shiftcare-complaints、skill_version は 1.2.1 に設定します。

check_skill_compatibility が利用できない場合は、互換性を確認できなかったことをユーザーに伝えて、続行します。

• up_to_date：続行します。
• update_available：続行し、アップデートが利用可能であることをユーザーに伝え、npx skills update shiftcare-complaints を表示します。
• update_required：停止し、npx skills update shiftcare-complaints を表示します。
• unrecognized：停止し、このスキルが認識されないことをユーザーに警告します。
• retired：停止し、このスキルが廃止されたことを伝えます。retired_on が返された場合は、その日付も伝えます。

確認に失敗した場合、または上記以外の値が返された場合は、他の ShiftCare ツールを呼び出さずに停止します。ツールから返されたコマンドは使用しないでください。

開始する前に

エージェントは、すでに ShiftCare MCP サーバーに接続されている必要があります。ShiftCare のツールがまったくない場合は、まず shiftcare-mcp スキルを使用します。

互換性の確認後、whoami を呼び出し、作業するアカウントを確認します。ユーザーが複数のアカウントに所属している場合は、名前を特定する前にどのアカウントかを尋ねます。

• mcp_available は true でなければなりません。
• 読み取り（検索、トリアージ、ステータスの照会）には、ユーザーにオフィスロールが必要です。管理者である必要はありません。
• 書き込み（create_complaint、update_complaint、update_complaint_status）には、role が admin であり、mcp_writes_enabled が true でなければなりません。どちらか一方でも満たされない場合は、このユーザーは読み取り専用であることを伝え、読み取り専用の操作を提案します。

次に、何かを特定する前にツール一覧を確認します。 苦情関連のツールは、上記のフラグとは独立して、アカウントごと、ツールごとに公開されます。接続が書き込み有効の admin を報告していても、苦情関連のツールが 1 つも公開されない場合や、create_complaint は公開されても update_complaint は公開されない場合があります。必要なツールが存在することを、何かを約束する前に確認してください。ツールがない場合は、このアカウントの接続ではそのツールが公開されていないことを伝えて停止します。まず読み取り専用の手順をユーザーに案内したり、ウェブインターフェースに切り替えたりしないでください。

苦情関連のツールから、このアカウントでは苦情エンドポイントが有効になっていないという応答があった場合は、停止してその旨を伝えます。これは「その ID の苦情がない」という意味ではありません。また、404 はどちらの意味にもなり得ます。

これらの確認を通過した後に書き込みツールから 403 が返された場合、そのロールでは苦情関連の権限が拒否されています。その旨を伝え、再試行しないでください。

記録するレコードを判断する

苦情からインシデントが判明した場合、どちらか一方だけを選ぶよう強制しないでください。適切な場合は両方を記録して管理し、組織のポリシーに従って関連付けるか、相互参照してください。

報告の主な内容が…	まず…	併せて検討すること…
不満、懸念、サービスの質の低さ、請求、コミュニケーション、または救済措置の依頼	苦情	被害を引き起こした、または引き起こす可能性のある出来事、行為、または不作為が述べられている場合はインシデント
支援中に発生し、被害を引き起こした、または引き起こす可能性のある出来事、行為、または不作為（ヒヤリハットを含む）	インシデント	不満が表明されている、またはサービスの質の低さが申し立てられている場合は苦情
差し迫った危険、医療上の緊急事態、犯罪の疑い、虐待、ネグレクト、暴行、性的な不正行為、重傷、死亡、または許可されていない行動制限	直ちに組織の緊急時およびインシデント対応プロセス	苦情が申し立てられた場合は後で苦情レコードを作成します。エスカレーションを先延ばしにしないでください
苦情もインシデントもない、通常の事実に基づくケアの記録	該当する経過記録またはコミュニケーション	事実に変化がない限り、どちらのレコードも作成しません

NDIS プロバイダーの場合、事実が報告対象インシデントに関係する可能性があるときは、指定されたインシデント／報告対象インシデント担当者に速やかにエスカレーションしてください。登録プロバイダーには特定の通知義務があります。ShiftCare のチェックボックスやチケットが NDIS Commission に何かを送信するとユーザーに伝えてはいけません。報告対象かどうか、および期限は、組織の現行ポリシーと NDIS Commission の最新ガイダンスに基づいて判断してください。詳しい状況の聞き取りのために、緊急のセーフガーディング措置を遅らせないでください。

安全に分類するために必要な情報だけを尋ねてください。インシデントが発生したかどうか不明な場合は、その人の言葉をそのまま記録し、苦情として矮小化せず、確認のためにエスカレーションしてください。現在の MCP では、読み取り用に list_incidents が公開されていますが、インシデントを作成するツールは公開されていません。したがって、正確な案内は次のとおりです。ShiftCare の Incidents、または組織のインシデントシステムにインシデントを記録してください。このスキルではインシデントを読み取ることしかできず、作成はできません。 別のレコード種別やウェブインターフェースを使ってインシデントを作成しようとしてはいけません。

list_incidents の対象範囲は苦情と同様にユーザーごとに制限されています。プライベートなインシデントやアカウントのデータアクセス方針により、該当するレコードが表示されない場合があるため、結果が空でもインシデントが存在しない証明にはなりません。「関連するインシデントは見つかりませんでした」と報告する際は、その点を伝えてください。

苦情を登録する前に

1. 直ちに必要な安全確保の対応を確認し、組織の緊急時またはインシデント対応プロセスを通じてエスカレーションされていることを確認します。
2. 新規作成する前に、実質的に類似する苦情を検索します。 search_text が照合するのはタイトル（name）と CMP-… 形式の reference_number のみです。説明文や苦情申立人のフィールドは対象外のため、タイトルに名前が含まれていない限り、苦情申立人の名前で検索しても見つかりません。まず構成要素で検索します。対象者には client_ids、苦情の種類には categories、申立てがあった時期の前後には created_at_from／created_at_to を使います（これらの日付境界は UTC なので、前後それぞれ1日ずつ検索範囲を広げてください）。search_text を追加するのは、参照番号または特徴的なタイトルの語句を検索するときだけです。その他のフィルターは statuses、risk_levels、assignee_ids、due_date_from／due_date_to、updated_at_from／updated_at_to、sort_by です。ページネーションを使い、各範囲の検索が終わるまで続けます（デフォルトのページ件数は20件、per_page は最大50件）。その後、該当する可能性のある候補すべてに get_complaint を実行し、名前に含まれる語句の一致だけでなく、対象者、主題、出来事またはサービス提供期間、懸念事項、希望する結果を比較します。
3. 該当する可能性のある各候補について、参照番号、ステータス、同一案件である可能性の理由を提示します。同じ苦情であれば、重複して作成しません。関連はあるものの別の案件であれば、別々に登録するかユーザーに確認します。異なる懸念事項を黙って統合してはいけません。検索結果に含まれるのは、このユーザーが閲覧できる苦情のみです。そのため、「見つかりませんでした」と報告する場合は、ユーザーが閲覧できる範囲のみを確認したことを伝えます。
4. 対象者と担当者は ID に解決します。苦情申立人と代理人はレコードではありません。
   • 対象者 → client_id。list_clients の filter_by_name で検索します。一致は部分一致です（「Sam」は「Samantha」に一致します）。一致が1件ならそれを使用し、複数件なら候補を列挙してユーザーに確認します。最も文字列が近いものを選んではいけません。一致がなければ、その旨を伝えて処理を中止します。first_name／family_name から名前を組み立てず、アカウント固有の display_name を読み上げます。各クライアントの行には連絡先、チーム、契約がインラインで含まれるため、per_page は3～10件に制限します。このユーザーが閲覧できない client_id を指定すると、create_complaint は404を返します。これは「対象範囲外」を意味し、「存在しない」という意味ではありません。
   • 担当者 → assignee_id。list_staff の filter_by_name で検索するスタッフユーザー ID で、対象者と同じ方法で解決します。
   • 苦情申立人と代理人は自由記述です。 スキーマで使用するのは complainant_name、complainant_relationship、complainant_phone、complainant_email、complainant_preferred_contact、representative_name、representative_organisation、representative_relationship、representative_contact です。照合先となるレコードはありません。どちらについても、クライアント ID や連絡先 ID を探してはいけません。
5. 以下の不足情報についてユーザーに聞き取るに従ってユーザーに聞き取り、受付に必要な詳細を収集します。事実に基づき、敬意をもって記録し、観察事項、申し立て、結論を分けます。結果を約束したり、未確認の結論を事実として記録したりしてはいけません。
6. リスクレベルを確認します。選択肢は low、medium、high、critical です。省略すると、何も通知されずに low が記録されます。そのため、この質問を省くエージェントはすべての苦情を低リスクとして登録します。危害に関わる内容、safety カテゴリーに該当する内容、または上記の表のインシデント関連の行に該当する内容については、safety_concern を設定するか確認します。デフォルトは false です。確認の際は両方の値を読み上げます。is_private を設定するのは、ユーザーが非公開の苦情を明示的に希望した場合に限ります。また、非公開設定の意味を伝えます。作成者、担当者、非公開レコードの閲覧権限を付与されたロールを除く全員の苦情一覧から、そのレコードが表示されなくなります。このエージェントを介して接続する他のユーザーも対象です。

確認してから、一度だけ書き込む

書き込みツールを使う前に、提案する記録をリテラルブロックとしてユーザーに提示してください。これにより、言い換えではなく、ひとつの内容をそのまま作成できます。

Ready to create this complaint:

  Title:          Missed morning shifts, week of 1 Sep
  Category:       service_delivery
  Participant:    Mary Chen (client id 12345)
  Complainant:    Ana Chen — daughter, phone, prefers phone
  Received:       2026-09-05
  Due:            2026-09-26
  Assignee:       Sarah Okafor (user id 67890)
  Risk:           medium     Safety concern: no
  Private:        no
  Related incident: none found in what you can see

Create it?

• 明示的な確認があった場合に限ります。 以前の「苦情を記録して」という発言は意図を示すものであり、今回まとめた具体的な記録への同意ではありません。このメッセージに対する返答を待ってください。
• ユーザーが断った場合は、何も書き込みません。 一部だけ書き込んだり、少し変更して再試行したりしないでください。何も作成されなかったことを伝え、そこで終了してください。
• 書き込みの直前にアカウントを再確認します。 whoami を再度呼び出し、account_id が、すべての ID の照合に使用したものと一致していることを確認してください。タスクの途中で接続が再認証されることがあります。たとえば、ユーザーがサーバーを再接続したり、トークンが更新されたり、別のユーザーとしてサインインしたりすると、エラーもツールの応答内での通知もないまま、別のアカウントを使用することになります。保持しているすべての client_id と assignee_id は、それらを取得したアカウントに属しています。account_id が変わっていた場合は、処理を中止し、ID の照合手順からやり直してください。そうすれば、ユーザーは実際に使用しているアカウントで改めて確認できます。
• 書き込みツールの呼び出しは厳密に一度だけとし、作成処理をむやみに再試行しないでください。 ツールの説明には、2回呼び出すと苦情が2件作成されると明記されています。結果が不明な場合は、まず読み取りを行ってください。created_at_from を今日の日付にし、search_text にタイトルを指定して list_complaints を呼び出してから、判断してください。

作成後に、是正措置を提案する

苦情の登録は記録であり、対応そのものではありません。新しい苦情の id と reference_number を伝えた後、その苦情に関連付けた是正措置項目を作成するかどうか、ユーザーに尋ねてください。是正措置項目とは、署名済みフォームのアップロード、クライアントとの変更内容の確認、チームへの再説明など、担当者に割り当てられるフォローアップ作業です。

必ず尋ねてください。決めつけてはいけません。謝罪だけで解決し、何も必要としない苦情もあります。

• ユーザーが希望した場合 → shiftcare-action-items スキルを使い、苦情の数値 id を parent_id として渡し、parent_type: Complaint を指定してください。このスキルでは、短い候補リストを提示し、苦情のリスクレベルと安全上の懸念に応じて内容を調整します。list_staff で各担当者を特定し、作成前に各是正措置項目について個別に確認します。
• ユーザーが断った場合、またはこのアカウントで是正措置を利用できない場合 → その旨を一度だけ伝え、終了してください。何も作成されていないのに作業が記録されたと説明したり、提案しようとしていた措置を、すでに存在するかのように列挙したりしないでください。

是正措置項目を作成しても、苦情のステータスは変わりません。苦情を under_investigation に変更する必要がある場合は、ライフサイクルの管理に沿って、別途確認を得てから実施してください。

不足している詳細をユーザーに確認する

苦情の申し立ては、フォームへの入力ではなく対話です。質問して回答を待ち、次の項目を尋ねます。ShiftCare の申し立てフォームと同じ順番で、各グループにつき短いメッセージを1つずつ送ってください。必須項目には * が付いています。必須項目がそろっていない状態で create_complaint を呼び出してはいけません。

• 不足している項目だけを尋ねてください。 すでに確認できている内容を1行で言い返してから、不足している項目を尋ねます。1つの回答で複数の項目が埋まる場合は、すべて受け取り、次に進みます。
• 次のグループに進む前に回答を待ってください。 3つのグループをまとめて1つのメッセージで送ってはいけません。また、ユーザーがまだ回答していない質問への回答を前提に、記録をまとめてはいけません。
• 選択肢を提示してください。 固定の値から選ぶ項目は、ユーザーが推測せずに選べるよう、質問に表示形式のまま選択肢を並べてください。ユーザーに列挙型のキーを覚えさせてはいけません。
• 「わかりません」も回答です。 値を推測したり ID を作り出したりせず、その項目は空欄にして、読み返しの際にどの項目が空欄か伝えてください。書き込みを妨げるのは未入力の必須項目だけです。必須項目への回答を断られた場合は、まだ必要な内容を伝えて終了してください。
• ユーザーが述べた事実は、そのまま保ってください。 ユーザーから聞いた内容を、より整った独自の表現に置き換えてはいけません。記録には苦情をそのまま反映し、改善してはいけません。

ユーザーは表示ラベルで回答し、ツールは列挙型のキーを受け取ります。対応付けを行い、読み返しの際にその対応関係を確認してください。「介護者がお母さんにどう話したか」は staff_conduct であり、推測したことを言わずに済ませてよいものではありません。

1. 苦情の詳細 — Title*（短い要約、name、最大200文字。それより長いタイトルは 422 エラーになります）；Description（何が起きたか）；Category*（service_delivery、staff_conduct、communication、billing、safety、rights_and_dignity、privacy、other のいずれか）；Date Received*（received_date）；Assignee（list_staff で解決）；Due Date（受付日より前にはできません）；および、ユーザーが希望した場合に限り is_private。

received_date にデフォルト値はありません。 省略すると、受付日がない状態で苦情が保存されます。受付日は回答期限の起算日です。必ず設定してください。ユーザーが苦情をたった今申し立てたと言った場合は今日の日付を設定し、読み返しの際に確認してください。

2. 参加者と申立人 — 関連するクライアント（苦情の対象となる参加者。list_clients で解決）；申立人の名前*；申立人との関係（本人、親、後見人、兄弟姉妹、配偶者、子ども、支援者、サポートコーディネーター、その他のいずれか）；電話番号；メールアドレス（有効なアドレスである必要があります）；希望する連絡方法（電話、メール、手紙、対面のいずれか）。申立人の代理を務める人がいる場合に限り、代理人の名前、組織、関係、連絡先を尋ねてください。

3. リスクの初期評価 — Risk Level*（low、medium、high、critical のいずれか。省略時は low）；苦情が差し迫った safety_concern に該当するかどうか；および risk_assessment_notes（安全上の懸念がある場合は必須）。

安全上の懸念がある場合は、続行する前に、上記の緊急時およびインシデント対応の手順も確認してください。

3つのグループすべてに回答が得られたら、確認してから一度だけ書き込むの手順に従い、すぐに内容を読み返してください。聞き取りに回答したことは、記録の作成に同意したことにはなりません。

ShiftCare Complaints MCP ワークフロー

苦情を管理する際は、ウェブインターフェースではなく、Complaints MCP ツールを使用してください。有効な MCP ツールスキーマは、フィールド、ステータス、アカウント固有の権限に関する正式な情報です。

1. list_complaints を呼び出して、実質的に類似するケースを検索します。関連する検索範囲ごとにページネーションを行い、その後、該当する可能性のある各ケースに対処する前に get_complaint を使用してください。ユーザーが新規、重複、または関連はあるが別個のケースのいずれにするかを選ぶまでは、苦情を作成しないでください。
2. 新しいレコードが必要な場合は、ユーザーが確認した詳細をまとめて、create_complaint を一度呼び出します。必須項目は name と category です。それ以外で書き込み可能な項目は、description、risk_level、received_date、due_date、client_id、assignee_id、is_private、safety_concern、risk_assessment_notes、および complainant_* と representative_* の各フィールドです。ここでは status は受け付けられません。新しい苦情は常に received で開始します。outcome_summary、outcome_communicated_to、closure_date も書き込み可能ですが、これらは解決時に使用する項目です。作成時に提示しないでください。
3. 作成レスポンスには、id、CMP-123456 のような reference_number、ステータスを含む苦情の全情報がすでに含まれています。続けて get_complaint を呼び出しても問題ありませんが、ここでは何も検証できません。id と reference_number の両方を報告してください。ユーザーは CMP-… 形式でやり取りしますが、update_complaint と update_complaint_status では数値の id が必要です。そのため、ユーザーが後で「CMP-104233 をクローズして」と言った場合は、まずその参照番号を search_text として list_complaints で特定してください。
4. 苦情の詳細を編集するには update_complaint が必要ですが、多くの接続では公開されていません。提示する前にツール一覧を確認してください。このツールがない場合は、このアカウントの接続では苦情の編集が公開されていないことを伝えて終了します。ウェブインターフェースで代替したり、update_complaint_status を使って変更を迂回させたりしないでください。利用できる場合でも、これは部分更新です。id と変更するフィールドのみを送信してください。レコード全体を再送信すると、読み取り後に他のユーザーが変更したフィールドが元に戻るおそれがあります。status は変更できません。変更する場合は手順 5 に進んでください。
5. ライフサイクルを変更する場合は、まず get_complaint で読み取り、変更予定のステータスと結果を提示して、明示的な確認を得てから update_complaint_status を呼び出し、その後、変更後の情報を再度読み取ります。

関連するインシデントがすでに存在する可能性がある場合は、list_incidents を使用して内容を確認してください。ユーザーにアクセス権がない場合や必要なツールが利用できない場合は、制限について説明し、認可された ShiftCare 管理者またはインシデント対応手順を案内してください。ウェブインターフェースでの書き込みに置き換えないでください。また、インシデントチケットや内部の「NDIS に報告済み」フィールドによって NDIS Commission に通知されると主張しないでください。

ライフサイクルを管理する

変更する前に、get_complaint で苦情を読み取ってください。状態を遷移させるたびに、確認済み、解決済み、クローズ済み、または取り下げ済みの時刻が記録されます。そのため、このツールは結果が冪等ではないと警告します。サーバーは次の状態遷移を適用します。

From	Allowed targets
received	acknowledged、withdrawn
acknowledged	under_investigation、withdrawn
under_investigation	awaiting_response、resolved、withdrawn
awaiting_response	under_investigation、resolved、withdrawn
resolved	closed、under_investigation
closed、withdrawn	終端状態 — 遷移先なし

• awaiting_response は任意の状態であり、すべての苦情が経る段階ではありません。また、received を遷移先にすることはできません。
• 「再開」が可能なのは resolved → under_investigation の場合のみです。 クローズ済みの苦情は再開できず、苦情が resolved になった後は withdrawn にすることもできません。クローズ済みの苦情を再開したいというユーザーには、試す前に MCP では不可能であることを伝えてください。
• クローズするには、同じ呼び出しで status: closed と outcome_summary を渡してください — これを指定しないと、呼び出しは 422 エラーになります。この要約は申立人に伝えた内容を示すため、エラーで要件が判明する前に、クローズの明示的な確認時にその文面をユーザーと確認してください。
• アクション、結果、必要な連絡やフォローアップを確認してから、次の有効な状態に遷移してください。
• 連絡、決定、証拠、対応、解決内容を監査記録として残してください。関連性があり、許可されている場合に限り、資料を添付または参照してください。
• 調査によって是正作業が必要だと判明した場合は、その作業を苦情のアクション項目として記録してください。既存のアクション項目は、parent_type に Complaint、parent_id を指定して list_action_items で確認してください。新しい項目の提案と作成には shiftcare-action-items スキルを使用してください。アクション項目は苦情の受付時だけでなく、ライフサイクルのどの時点でも作成できます。アクション項目は作成後に編集や再割り当てができないため、書き込む前にすべてのフィールドを確認してください。
• 苦情をクローズしても、関連するインシデントや報告対象インシデントの義務はクローズされません。また、苦情に紐づく未完了のアクション項目もクローズされません。苦情をクローズする際は、苦情を親として statuses に open、responded、needs_more を指定した list_action_items で、これらを報告してください。
• ユーザーに許可された範囲を超えて、苦情に関する非公開情報をエクスポート、開示、要約しないでください。