このたび、介護事故の情報をAIが整理し、事故原因候補や改善策候補を提案してくれる「介護事故検証AIエージェント」をリリースしました。
事故報告書や介護記録、写真、見取り図、ヒヤリハット記録などをもとに、AIが多職種の視点で原因候補と改善案を整理します。
これにより、事故カンファレンスの準備や原因分析、再発防止策の検討にかかる負担を減らしやすくなります。特に、「何を見ればいいのか分からない」「原因が職員の注意不足だけで終わってしまう」「改善策が見守り強化ばかりになる」といった場面で、検討最初に注意点です。
このプロジェクトで出力される内容は、必ず正しいと保証されるものではありません。AIは入力された情報や資料をもとに、事故原因候補と改善案候補を整理しますが、事実誤認、読み取り違い、根拠の弱い推測が含まれる可能性があります。
そのため、出力結果は事故報告書や家族説明文としてそのまま使わず、事故カンファレンスや現場検討のための資料として使ってください。最終判断は、記録、現場確認、関係職種の意見を踏まえて人間が行う必要があります。
介護事故の検証では、事故報告書を書いて終わりになりやすい問題があります。
「注意不足でした」「見守りを強化します」で終わると、次の事故でも同じことが繰り返されます。
このプロジェクトは、OpenAIのCodexで使うことを前提にした、介護事故検証用の運用ファイル一式です。Codexに、事故情報、関連資料、プロンプト、役割定義、チェックリスト、YAMLジョブを読み込ませ、介護事故の原因候補と改善案候補を多職種視点で整理させます。
ただし、事故原因をAIが断定するものではありません。最終判断は人間が行う前提です。
この記事の前半では、実際の使い方だけを説明します。後半では「テクニカル情報」として、内部の仕組みや設計意図を解説します。
このプロジェクトはOpenAI Codex用です
この仕組みは、ChatGPTの通常チャットだけで完結させるものではありません。
OpenAIのCodexにプロジェクトフォルダを読み込ませ、AGENTS.md、jobs、prompts、roles、checklists、templates、cases の各ファイルを参照させながら事故分析を進める想定です。
Codexは、プロジェクト内のファイルを読み、必要に応じてファイルを編集・作成し、指定された作業を進めるためのエージェントです。
このプロジェクトでは、Codexに実装コードを書かせることが目的ではありません。
目的は、すでに用意した md、txt、yaml の運用ファイルを使って、事故情報を整理し、outputs に分析結果を txt で出力させることです。
通常の使い方は、Codexに次のように依頼します。
jobs/accident_analysis_job.yaml に従って、以下のケースを分析してください。
対象ケース：
cases/case_001/
実装コードは作成しないでください。
既存の prompts、roles、checklists、templates を使用してください。
出力はすべて outputs/ に txt ファイルで保存してください。
つまり、このプロジェクトは「Codexに事故分析の流れを守らせるためのファイル群」です。
ダウンロード
以下から、介護事故検証AIエージェント一式をダウンロードできます。
ダウンロード後、ZIPファイルを解凍し、Codexでプロジェクトフォルダとして開いてください。使うときは、cases/sample_case/ をコピーして新しいケースフォルダを作り、incident_input.md に事故情報を入力します。
まずは使い方だけを確認する
このシステムを使うときに、最初から細かい仕組みを理解する必要はありません。
現場で必要なのは、次の流れです。
1. 新しいケースフォルダを作る
2. incident_input.md に事故情報を書く
3. source_files に関連資料を入れる
4. accident_analysis_job.yaml に従ってAIに分析させる
5. outputs に出た結果を確認する
まずはこの流れだけ押さえれば十分です。
手順1：新しいケースフォルダを作る
事故1件ごとに、cases フォルダの中へ新しいフォルダを作ります。
例：
cases/case_001/実際には、あとから見返しやすい名前にしておくと管理しやすくなります。
例：
cases/case_2026_0504_fall_A/個人名は入れません。
ケースフォルダの中身は、以下の形にします。
case_001/
├─ incident_input.md
├─ source_files/
└─ outputs/
手順2：incident_input.md に事故情報を書く
事故情報は、incident_input.md に記入します。
入力する内容は主に以下です。
- 事故種別
- 発生日時
- 発見場所
- 最終確認時刻
- 利用者情報
- ADL
- 認知機能
- 発見時状況
- 発見後対応
- 現場状況
- 環境情報
重要なのは、空欄を作らないことです。
空欄があると、AIは分析を停止します。
分からない項目は、空欄にせず「不明」と書きます。
例：
- 発見場所：居室ベッド左側
- 最終確認時刻：15:05
- 認知機能：見当識障害あり
- 普段との違い：帰宅願望が増えていた
「不明」と書いた項目は、分析では不足情報として扱われます。
手順3：source_files に関連資料を入れる
写真、見取り図、介護記録などがある場合は、source_files に入れます。
例：
source_files/
├─ 発見時写真.jpg
├─ 見取り図.png
├─ 介護記録_事故前3日.txt
├─ 眠りスキャン要約.txt
└─ ヒヤリハット記録.txt
入れる可能性がある資料は次のようなものです。
- 発見時写真
- 見取り図
- 介護記録
- 看護記録
- 眠りスキャン
- ヒヤリハット記録
- 薬剤情報
- 勤務表
- 家族説明記録
- 転倒リスク説明書
- QOL尊重に関する同意書
ここで大事なのは、incident_input.md に「写真あり」「眠りスキャンあり」と書かないことです。
AIが source_files の中身を確認し、自動で資料の種類を判断します。
手順4：着火用プロンプトをCodexに入力する
分析は、jobs/accident_analysis_job.yaml の流れに沿って行います。
ここで使う最初の指示文を、このプロジェクトでは「着火用プロンプト」と呼びます。
着火用プロンプトとは、Codexに対して「どのケースを、どのジョブに従って、どの条件で分析するか」を伝えるための開始指示です。
Codexを開いたら、対象ケースのフォルダ名だけを実際のケース名に変えて、以下を貼り付けます。
jobs/accident_analysis_job.yaml に従って、以下のケースを分析してください。
対象ケース：
cases/case_2026_0504_fall_A/
実行条件：
- 実装コードは作成しないでください。
- AGENTS.md を最優先ルールとして使用してください。
- jobs/accident_analysis_job.yaml の工程順を守ってください。
- 工程の追加・省略・順序変更はしないでください。
- 対象ケース配下の incident_input.md、source_files/、outputs/ を使用してください。
- 出力はすべて対象ケース配下の outputs/ に txt ファイルで保存してください。
- 必須情報が空欄の場合は分析を停止してください。
- 最終判断は人間が行う前提で、断定しすぎない表現にしてください。
上記の cases/case_2026_0504_fall_A/ の部分は、自分が作成したケースフォルダ名に変更してください。
例：
対象ケース：
cases/case_001/ポイントは、Codexに自由に分析させるのではなく、AGENTS.md と accident_analysis_job.yaml の流れに従わせることです。
特に「工程の追加・省略・順序変更はしない」と明記することで、Codexが勝手に手順を変えてしまうリスクを減らします。
Codexには、すでに用意してある AGENTS.md、prompts、roles、checklists、templates を使わせます。新しいプログラムやアプリを作らせるのではなく、事故分析用の運用ファイルに従って処理させるのが前提です。
手順5：outputs の結果を確認する
分析結果は、outputs フォルダに txt で出力されます。
主に確認するファイルは以下です。
01_required_info_check.txt
- 必須情報に空欄がないか
03_fact_summary.txt
- 事実、記録内容、推測、不足情報が分かれているか
08_cause_candidates.txt
- 原因候補が出ているか
09_countermeasures.txt
- 改善案候補が出ているか
13_final_report.txt
- 人間が読む最終レポート
14_quality_review.txt
- 最終品質チェック結果
最初に見るべきなのは、01_required_info_check.txt です。
ここが stop なら、原因分析には進んでいません。
手順6：final_report.txt を読む
13_final_report.txt が最終的に読むファイルです。
ただし、これは事故報告書の完成版ではありません。
人間が検討するための材料です。
確認するポイントは次の通りです。
- 原因候補に根拠があるか
- 改善案が具体的か
- 原因候補と改善案が対応しているか
- 「注意する」「見守り強化」で終わっていないか
- 不足情報が明記されているか
- 断定しすぎていないか
このレポートを読んだうえで、事故委員会や現場カンファレンスで人間が最終判断をします。
よくある使い方の例
転倒事故の場合は、以下のような資料を入れると分析しやすくなります。
incident_input.md
- 発見場所
- 最終確認時刻
- 発見時の姿勢
- 普段のADL
- 認知機能
- 発見後対応
source_files/
- 見取り図
- 発見時写真
- 介護記録
- ヒヤリハット記録
- 眠りスキャン要約
服薬事故の場合は、以下が重要です。
source_files/
- 薬剤情報
- 服薬記録
- 服薬手順
- 勤務表
- ヒヤリハット記録
誤嚥や窒息の場合は、以下が重要です。
source_files/
- 食形態情報
- 食事介助記録
- 看護記録
- 口腔状態の記録
- 食事中の座席配置や姿勢の情報
運用時の注意点
AIの出力をそのまま使わないでください。
特に以下は、人間確認が必要です。
- 医学的判断
- 家族説明
- 行政提出文書
- 事故原因の確定
- 職員への指導内容
- 処分判断
このシステムは、事故検討を補助するものです。
最終判断は必ず人間が行います。
テクニカル情報：このシステムの仕組み
ここからは、内部の仕組みを説明します。
通常の使い方だけ知りたい場合は、ここまで読めば十分です。
全体の処理フロー
Codexは jobs/accident_analysis_job.yaml の流れに沿って処理します。
Codexはプロジェクト内のファイルを読みながら作業できるため、AGENTS.md の全体ルール、prompts の工程指示、roles の役割定義、checklists の確認観点を組み合わせて使います。
1. 必須情報確認
2. 任意資料確認
3. 事実抽出
4. 事故種別分類
5. チェックリスト選択
6. 参加役割選択
7. 多職種議論
8. 原因候補分析
9. 改善案候補生成
10. 根拠紐づけ
11. 候補順位付け
12. 実行可能性確認
13. 最終レポート生成
14. 最終品質チェック
この順番を固定する理由は、情報不足や推測混じりのまま原因分析に進ませないためです。
01 必須情報確認
最初に、incident_input.md の空欄を確認します。
空欄がある場合、分析は停止します。
例：
判定結果：stop
空欄項目：
- 発見時刻
- 外傷・痛み・出血の有無この段階で止めることで、AIが足りない情報を勝手に補って原因を作ることを防ぎます。
02 任意資料確認
source_files の中身をAIが確認します。
AIはファイル名、拡張子、内容から資料種別を仮判定します。
分類は次のようになります。
- 使用する資料
- 補助的に参照する資料
- 使わない資料
- 想定外だが関連しそうな資料
例えば「転倒事故一部容認書」のような想定外の資料があっても、AIが確認します。
ただし、同意書があることをもって「事故は仕方ない」と判断することは禁止します。
03 事実抽出
事実抽出では、情報を以下に分けます。
1. 確認できた事実
2. 記録に書かれている内容
3. 写真・見取り図から読み取れる内容
4. 推測
5. 不足情報例えば、
利用者Aがベッド左側で倒れていたこれは確認できた事実です。
一方、
トイレへ行こうとして転倒した可能性これは推測です。
この区別が崩れると、AIがそれらしいストーリーを作ってしまいます。
04 事故種別分類
人間が書いた事故種別をAIが確認します。
例：
human_selected_incident_type：転倒
ai_detected_primary_type：転倒
confidence：highもし人間入力とAI判定がズレた場合は警告を出します。
例えば、人間は「転倒」と書いたが、記録上は「転落」の可能性もある場合です。
05 チェックリスト選択
事故種別に応じて、使用するチェックリストを選びます。
転倒なら以下が選ばれます。
- common_checklist.md
- fall_or_fall_from_height.md転倒チェックリストでは、以下のような点を確認します。
- 発見位置
- 動作
- 歩行器
- ベッド高
- センサー
- 見守り状況06 参加役割選択
事故内容によって、議論に参加する役割を変えます。
常時参加するのは以下です。
- 介護士
- 介護主任
- 司会
- 発言評価役条件付きで参加するのは以下です。
- 看護師
- PT
- 医師
- ケアマネ
- 薬剤師
- 栄養士
- 管理者例えば、転倒事故ではPTが関係しやすく、誤嚥事故では栄養士や看護師が関係しやすくなります。
全員を毎回参加させないのがポイントです。
07 多職種議論
多職種議論では、全員ターン制にはしません。
必要な役割だけが発言します。
発言条件は以下です。
- 自分の専門領域に関係する
- 事故原因や対策に影響する可能性がある
- 他の役割がまだ拾っていない
- 根拠がある
- 現在のフェーズに合っている司会役は、毎回誰かに話を振る役ではありません。
不足視点、停滞、偏りがあるときだけ介入します。
08 発言ガード
各役割の発言は、ログに残す前に評価されます。
判定は以下です。
- pass
- retry
- rejectreject されるのは以下です。
- 雑談
- 事故分析と無関係
- 役割外の断定
- 根拠なし断定
- 既出内容の繰り返し
- フェーズ違反
- 個人責任への偏り
- 精神論の改善策発言ガードにより、AI同士の議論が雑談化したり、根拠なしに進んだりすることを防ぎます。
09 原因候補分析
原因候補は最大5個です。
ただし、根拠が足りない候補を無理に5個作りません。
各候補には以下を入れます。
- 内容
- 根拠
- 関連資料
- 事故との関連
- 確からしさ
- 推測を含む部分
- 断定できない点個人の注意不足だけで終わらせないことが重要です。
10 改善案候補生成
改善案も最大5個です。
ただし、以下のような改善案は禁止します。
- 注意する
- 徹底する
- 意識する
- 気をつける
- 見守り強化
- 声かけ強化改善案には以下を入れます。
- 実行者
- 実施タイミング
- 具体的行動
- 必要な準備
- 現場負担
- 効果見込み
- 副作用・注意点
- 継続確認方法11 根拠紐づけ
原因候補と改善案には、根拠資料を紐づけます。
例：
原因候補：歩行器位置と本人動線の不一致
根拠資料：見取り図、ヒヤリハット記録、発見時状況
根拠が薄いものは、参考仮説として扱います。
12 候補順位付け
候補は以下の評価軸で順位付けします。
- 根拠の強さ
- 事故との関連度
- 再発防止への効果
- 現場での実行可能性
- 現場負担
- 緊急度
- 副作用の少なさそして以下に分けます。
- 主要候補
- 検討候補
- 参考候補13 実行可能性確認
改善案が現場で実行できるか確認します。
例えば、
見守りを増やすだけでは不合格です。
理由は、誰が、いつ、どう行うかが分からないためです。
14 最終レポート生成
最終レポートには以下を入れます。
1. 事故概要
2. 確認できた事実
3. 使用した資料
4. 不足情報
5. 事故原因候補5個
6. 改善案候補5個
7. 原因候補と改善案の対応関係
8. 優先度
9. 現場で確認すべき点
10. 断定できないこと
11. 人間が最終確認すべきポイント
文体は、断定しすぎない形にします。
原因は〇〇であるではなく、
原因候補として〇〇が考えられると書きます。
15 最終品質チェック
最後に品質チェックを行います。
確認するのは以下です。
- 必須情報が空欄なのに分析していないか
- 事実と推測が混ざっていないか
- 根拠なし断定がないか
- 個人責任に寄りすぎていないか
- 原因候補と改善案が対応しているか
- 改善案が精神論になっていないか
- 同じ内容を言い換えて5個にしていないか
- 人間が読みやすい表現になっているか判定は以下です。
pass
needs_revision
failfail の場合は、完成扱いにしません。
このシステムの強み
このシステムの強みは、「個人の注意不足」で終わらせにくいことです。
介護事故では、複数の要因が重なります。
- 人手不足
- 業務集中
- 情報共有不足
- 環境設計
- 福祉用具配置
- 時間帯特性
- 利用者の状態変化このプロジェクトでは、それを多職種視点で分解します。
まとめ
介護事故検証AIジョブは、事故原因候補と改善案候補を、多職種視点で整理するための運用システムです。
前半で説明した通り、実際に使うときは次の流れだけ押さえれば十分です。
1. ケースフォルダを作る
2. incident_input.md を書く
3. source_files に資料を入れる
4. yaml に従ってAIに分析させる
5. outputs の final_report と quality_review を確認する内部では、必須情報確認、任意資料分類、事実抽出、多職種議論、発言ガード、根拠紐づけ、実行可能性確認、品質チェックまで行います。
最終的な判断は人間が行いますが、事故検討の整理材料としては実務向けに使いやすい構成です。
更新履歴
- 2026年5月7日：新規リリース
