介護事業所のAKS運用メモをClaude Codeで整える: 夜間障害時の連絡順

介護事業所の夜勤中、記録アプリが開かず、職員LINEに「入力できません」が続いたら、最初に必要なのはKubernetesの説明ではありません。夜勤リーダーが見ているのは、利用者記録画面、申し送り表、電話番号表、Azureのアラート、AKSのNode NotReadyです。今日まず直す1箇所は、障害メモに「誰へ何分以内に連絡するか」を書ける状態へ変える作業です。

この記事では、介護事業所がAKSで動く記録アプリや社内ポータルを持っている場合に、Claude Codeで夜間障害の運用メモを整える流れを書きます。狙いは、AIに復旧作業を丸投げする話ではありません。アラート、影響範囲、kubectlの確認結果、個人情報の扱い、連絡順、rollbackを表にして、夜勤者とシステム担当が同じ順番で動けるようにします。

この記事の要点

• 介護事業所のAKS障害では、技術調査より先に、誰が困っているか、記録業務が止まっているか、次の連絡時刻を見る。
• Claude Codeには、アラート文、kubectl結果、Service Health、連絡先表、伏せた障害メモを読ませる。
• 人が見る範囲は、利用者情報、職員連絡、家族連絡、業務継続判断、vendor escalation、rollbackです。
• 夜間メモは「原因探し」ではなく、15分ごとの連絡順と、個人情報を出さない共有文を作るために使います。
• 成果はPVではなく、初動連絡までの分数、影響範囲の確定時間、個人情報を消した共有件数、同じ障害の再発件数で見ます。

夜間障害で現場が詰まる場面

介護事業所の夜勤では、記録アプリ、申し送り表、オンコール表、服薬確認、巡視記録が短い時間に重なります。アプリが落ちたとき、職員は「紙で書くか」「管理者へ電話するか」「システム会社へ投げるか」で迷います。ここでAKSのNode、Pod、namespace、Deploymentの話だけ始めると、現場は置いていかれます。

まず見る具体物は、アラート文、発生時刻、利用者記録画面、影響部署、夜勤者の連絡先、Azure Service Health、kubectl snapshotです。Azure Service Healthは、利用中のAzureサービスやregionに影響する障害、planned maintenance、health advisoryを見る入口です。AKS側では、Microsoft Learnが案内するように、Container insights、Azure Monitor、kubectl、troubleshooting docsを組み合わせて、Node NotReady、Pod restart、高CPU、接続不良を切り分けます。

参考にした一次情報は、What is AKS?、AKS best practices、deployment and cluster reliability best practices、enable monitoring for AKS、Azure Service Health overview、AKS troubleshooting documentation、node NotReady troubleshooting、high CPU in AKSです。Kubernetes自体の基本はデプロイ入門にもまとめています。

Claude Codeに任せる範囲と人が見る範囲

介護事業所の夜間メモでClaude Codeに渡すのは、伏せたアラート文、Node数、Pod状態、namespace、直近deploy時刻、Service Health確認結果、連絡先の役割名、rollback候補です。利用者名、介護記録、医療情報、住所、家族電話番号、職員の私用連絡先は渡しません。

Claude Codeに任せる範囲は、メモの整理、影響範囲の質問、連絡順の表、vendorへ出す個人情報なし文面、kubectl確認コマンドの一覧、次回更新時刻の抜け検出です。人が見る範囲は、利用者の安全、紙運用へ切り替える判断、家族やケアマネへの連絡、個人情報の扱い、vendor escalation、rollback実行、復旧完了宣言です。

AKSの障害対応では、Node NotReadyやPod restartを見つけても、それだけで原因は決まりません。夜間のメモは、原因を断定する紙ではなく、職員へ「いつ次を知らせるか」を決める紙です。Claude Codeには、安心文ではなく、まだ分からない点と、次に確認するコマンドを出させます。

3つのUse case

Use case 1: 夜勤リーダー向けの初動メモを作る

• 入力: アラート文、発生時刻、影響画面、職員からの報告、Service Health確認有無。
• 出力: 影響範囲、次の連絡時刻、紙運用へ切り替える条件、管理者への報告文。
• 人の確認: 利用者安全、服薬や巡視への影響、家族連絡、オンコール判断を見る。

夜勤リーダーが欲しいのは、AKSの内部名ではなく、今どの記録業務が止まっているかです。Claude Codeには、アラートを「職員向けの言葉」へ直させます。人は、記録が後追いで足りるのか、紙へ切り替えるのか、15分後に再通知するのかを決めます。

Use case 2: システム担当向けのkubectl確認表を作る

• 入力: kubectl get nodes、kubectl get pods、kubectl describe、前回ログ、直近deploy時刻。
• 出力: Node NotReady、CrashLoopBackOff、CPU高騰、接続不良、直近変更の確認表。
• 人の確認: 本番操作、restart、rollback、vendor escalation、Azure権限を見る。

システム担当が夜間に呼ばれたとき、最初の5分で情報が散ると復旧が遅れます。Claude Codeには、kubectl結果を表にし、Node、Pod、namespace、Deployment、event、previous logを分けさせます。人は、restartやrollbackを実行してよいかを判断します。

Use case 3: vendorへ渡す個人情報なしの連絡文を作る

• 入力: 伏せた障害メモ、影響画面、件数、時刻、確認済みコマンド、連絡先役割。
• 出力: vendor向け文面、個人情報を消した再現条件、次回更新時刻、依頼事項。
• 人の確認: 利用者名が消えているか、契約範囲、緊急度、電話連絡可否を見る。

介護事業所の障害連絡では、焦るほど利用者名や記録内容を書きがちです。Claude Codeには、個人情報を消したvendor連絡文を作らせます。人は、情報を出してよい範囲と、電話で伝える範囲を決めます。

コピペで使えるプロンプト

あなたは介護事業所の夜間障害メモを整える運用レビュー担当です。
対象はAKSで動く記録アプリまたは社内ポータルです。
目的は、原因断定ではなく、夜勤者、管理者、システム担当、vendorが同じ順番で動ける連絡表を作ることです。

入力:
- 発生時刻
- 影響画面。利用者名や記録内容は消す
- Azure alert文
- Azure Service Healthを確認したか
- kubectl get nodes / pods の要約
- 直近deployの有無
- 連絡先の役割名。個人電話番号は伏せる
- rollback候補

確認してほしいこと:
1. 影響を受ける職員、部署、画面、時間帯
2. Node NotReady、Pod restart、CPU高騰、接続不良のどれが見えるか
3. Service Healthを先に確認したか
4. 次の職員向け更新時刻があるか
5. vendorへ送る文面から個人情報が消えているか
6. rollbackまたは紙運用への切替条件があるか
7. 人が判断しないと進めてはいけない操作

制約:
- 利用者名、住所、介護記録、医療情報、家族電話番号は扱わない
- kubectl delete、restart、rollbackは実行しない
- 「問題ありません」と断定しない
- 最後に、今日直す5行だけを優先順で出す

動く確認コード

夜間障害メモを1枚の表にしたら、次の確認コードで抜けを拾えます。実際のAKS APIを叩くものではありません。Service Health確認、影響範囲、Node/Podの状態、連絡先、個人情報、rollback、次回更新時刻を表にしてから実行します。

// verify-aks-night-incident-runbook.mjs
// No dependencies. Run with: node verify-aks-night-incident-runbook.mjs
const incidentMemo = {
  industry: "care",
  service: "night-shift-care-record",
  detectedAt: "22:18",
  alert: "AKS node NotReady and pod restart spike",
  serviceHealthChecked: false,
  affectedUsers: "unknown",
  kubectlSnapshot: {
    nodesNotReady: 2,
    podsCrashLooping: 3,
    highCpuPods: 1,
    recentDeployWithinHours: 2
  },
  contactOrder: [
    { role: "night shift lead", name: "Sato", phone: "" },
    { role: "system owner", name: "", phone: "080-0000-0000" },
    { role: "vendor", name: "Cloud partner", phone: "03-0000-0000" }
  ],
  personalDataShared: true,
  rollbackNote: "",
  nextUpdateMinutes: 0
};

const problems = [];

if (!incidentMemo.serviceHealthChecked) {
  problems.push({ item: "Azure Service Health", fix: "check Service Health before blaming the application" });
}
if (incidentMemo.affectedUsers === "unknown") {
  problems.push({ item: "affected users", fix: "write whether staff, managers, families, or residents are affected" });
}
if (incidentMemo.kubectlSnapshot.nodesNotReady > 0) {
  problems.push({ item: "node NotReady", fix: "capture node count, last change time, and network or CPU clues" });
}
if (incidentMemo.kubectlSnapshot.podsCrashLooping > 0) {
  problems.push({ item: "pod restart", fix: "capture namespace, deployment, previous logs, and recent release" });
}
for (const contact of incidentMemo.contactOrder) {
  if (!contact.name || !contact.phone) {
    problems.push({ item: "contact: " + contact.role, fix: "write name and phone before the night shift" });
  }
}
if (incidentMemo.personalDataShared) {
  problems.push({ item: "personal data", fix: "remove resident names and care details from vendor escalation notes" });
}
if (!incidentMemo.rollbackNote) {
  problems.push({ item: "rollback", fix: "write rollback or safe read-only mode before escalation" });
}
if (incidentMemo.nextUpdateMinutes <= 0) {
  problems.push({ item: "next update", fix: "write the next staff update time, such as 15 or 30 minutes" });
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("AKS night incident memo passed.");
}

このコードで見ているのは、Azure Service Health、影響範囲、Node NotReady、Pod restart、連絡先、個人情報、rollback、次回更新時刻です。実運用では、Azure Portal、Container insights、Azure Monitor alert、kubectl、Log Analytics、紙運用の記録表を合わせて確認します。

Pitfall: よくある落とし穴

一つ目の落とし穴は、夜勤者へ技術用語だけ返す点です。原因は、NodeやPodの状態を見た瞬間に、現場の記録業務を忘れるためです。直し方は、AKSの状態と、職員が見る画面、紙運用の条件、次の連絡時刻を同じ表に入れる形です。

二つ目は、Azure側の障害確認を飛ばす点です。原因は、自分たちのアプリだけを疑ってしまう流れです。直し方は、Azure Service Health、AKS alert、直近deploy、network変更を最初の確認欄に置きます。

三つ目は、vendor連絡に個人情報を混ぜる点です。原因は、急いで再現例を説明しようとして、利用者名や記録内容を貼ってしまうためです。直し方は、画面名、時刻、件数、エラー文、確認コマンドだけで説明します。

四つ目は、連絡先表が古い点です。原因は、オンコール担当、管理者、vendor窓口が変わっても運用メモが更新されないためです。直し方は、毎月1回、名前、役割、電話、代替連絡先、対応可能時間を確認します。

よくある質問

Q. 介護事業所がAKSを使うのは重すぎませんか。

A. 記録アプリや社内ポータルだけなら、必ずAKSが必要とは限りません。複数サービス、既存Kubernetes運用、夜間対応のSLA、監視基盤がある場合に検討します。

Q. Claude Codeに障害ログを読ませても大丈夫ですか。

A. 利用者名、介護記録、医療情報、住所、電話番号を消したログだけにします。kubectl結果、件数、時刻、役割名、エラー文は扱えます。

Q. 夜間に最初に見る項目は何ですか。

A. 影響画面、Service Health、Node NotReady、Pod restart、次回更新時刻の5つです。この5つで、現場連絡と技術調査の順番がそろいます。

Q. 成果は何で見ますか。

A. 初動連絡までの分数、影響範囲の確定時間、個人情報を消したvendor連絡件数、同じ障害の再発件数、夜間対応後の記録漏れ件数で見ます。

研修・相談につなげるなら何を見るか

介護事業所のAKS記事から相談へ進めるなら、PVではなく夜間対応の詰まりを見ます。記録アプリが止まった時に、連絡順が曖昧、個人情報を含むログを送ってしまう、rollback基準がない、vendorへの説明が毎回違うなら、運用メモと権限を整える価値があります。

AKS監視、Container insights、Service Health alert、kubectl確認表、個人情報を出さない障害連絡、夜間対応runbookを社内運用に落としたい場合は、ClaudeCodeLabの研修・相談で相談できます。まずは夜間障害メモの先頭に、影響画面、Service Health、連絡順、rollback、次回更新時刻の5行を置いてください。

実際に試した結果

この記事では、Microsoft LearnのAKS overview、best practices、cluster reliability、monitoring、Service Health、troubleshooting、Node NotReady、高CPUの説明を確認しました。さらに、slug、frontmatter、内部リンク、外部リンク、CTA、コードブロック、10言語ファイル、記事キューの削除対象を確認しています。今日まずやる1手は、夜間障害メモを開き、影響画面、Service Health、連絡順、rollback、次回更新時刻の5行をチェックする作業です。