【ダウンロードページ】介護事故の原因と改善策をAIで検証する方法｜Codex用AIエージェントの使い方

介護事故やヒヤリハットの内容をもとに、AIが事故要因や再発防止の視点を整理するファイルを公開します。まずは実行結果をご確認ください。

以下の様に結果が出力されます。
ダウンロード
使い方（支援ツールを使う場合）
使い方（支援ツールを使わない場合）
ダウンロード
更新履歴

以下の様に結果が出力されます。

介護事故やヒヤリハットの内容を入力すると、AIが事故の背景要因や再発防止の視点を整理します。下記は実際の出力例です。

AI事故分析レポート｜出力例

事故概要：
2026年5月6日14時40分、利用者Aが居室内のベッド右側床上で、尻もちをつくような座位で発見された。最終確認は14時25分で、その時点ではベッド上で臥床していた。14時15分にはトイレ誘導が行われ、排尿があった。発見時、歩行器は本人前方約1m、ナースコールはベッド左側サイドテーブル上、履物は右足のみで左足の履物はベッド下にあった。出血はなく、右臀部痛と右肘軽度発赤が確認された。転倒の瞬間は目撃されていないため、原因や転倒機序は確定しない。

確認できた事実：
- 発見時刻は14時40分、発見場所は居室内ベッド右側床上。
- 最終確認時刻は14時25分で、利用者Aはベッド上で休んでいた。
- 本人は「トイレに行こうと思った」「足がすべった」「転んだか分からない」と発言している。
- 利用者Aには認知症、見当識障害、過去の転倒歴、立ち上がり時のふらつきがある。
- 事故当日は眠気、落ち着きなさ、帰宅願望、排泄回数増加があった。
- 前日にも、昼食後居室で歩行器なしで立ち上がろうとしたヒヤリが記録されている。
- 14時台はおやつ準備、排泄介助、コール対応が重なり、居室内の常時見守りはできていなかった。

使用した資料：
- incident_input.md
- care_record_3days.txt
- hiyarihat_record.txt
- nemuri_scan_summary.txt
- risk_explanation_summary.txt
- room_layout_text.txt
- 発見時の様子.png

不足情報：
- 転倒の瞬間は目撃されていない。
- ベッドから立ち上がった直後に転倒したのか、歩行器へ向かう途中で転倒したのかは断定できない。
- 頭部打撲の有無は本人発言からは不明。
- 翌日の整形外科受診結果、疼痛経過、歩行再開判断は未確認。
- 薬剤情報、薬剤変更、バイタルの具体値、眠りスキャン通知履歴、離床センサー使用基準は資料にない。
- ベッド高、床マットの厚み、履物の滑りやすさ、PTによる動作評価の詳細は未確認。

事故原因候補：
1. 排泄希望、帰宅願望、見当識障害、危険認識低下が重なり、利用者Aが職員を呼ばずに単独で起き上がった可能性がある。
2. 歩行器、ナースコール、履物、床マット、洗濯物カゴの配置が、本人の立ち上がりや歩行器把持の動作と合っていなかった可能性がある。
3. 前日のヒヤリハットが、居室休憩時の具体的な物品配置、訪室時刻、担当者、センサー要否などの行動ルールに落とし込まれていなかった可能性がある。
4. 14時台の業務重複と居室内の死角により、単独離床を早期に把握しにくかった可能性がある。
5. 事故前夜の睡眠不足、事故当日の眠気、立ち上がり時のふらつき、変形性膝関節症、排泄回数増加が、立ち上がり時の安定性や焦りに影響した可能性がある。これは参考候補として扱う。

改善案候補：
1. 昼食後に居室で休む前後の「次行動セット」を作る。ベッド誘導後に、次回訪室時刻と担当者を担当表に記入し、排泄希望、端座位、歩行器位置、履物、ナースコール位置を同じ順で確認する。
2. 居室休憩時のベッド周囲標準配置を決める。歩行器、ナースコール、履物、床マット、洗濯物カゴの定位置を、床テープまたは配置写真で共有する。
3. ヒヤリハット後24時間の暫定対応シートを使う。同じ場面が起こりやすい時間、物品配置、担当者、次回確認時刻、センサーや眠りスキャン通知の要否を記入する。
4. 14時台の業務重複時に、居室内転倒リスク者への短時間担当を割り当てる。食堂準備担当と居室リスク者対応担当を分け、必要時は眠りスキャンや離床センサーの一時適用を判断する。
5. 睡眠不足、眠気、排泄回数増加、ふらつきがある日の一時的な介助レベル変更基準を作る。該当項目が複数ある日は、昼食後からおやつ前まで、歩行器歩行の介助レベル変更を検討する。

原因候補と改善案の対応関係：
- 原因候補1には、改善案1と改善案5が対応する。
- 原因候補2には、改善案2が対応する。
- 原因候補3には、改善案2と改善案3が対応する。
- 原因候補4には、改善案1と改善案4が対応する。
- 原因候補5には、改善案5が対応する。

優先度：
1. 原因候補2、改善案2：根拠が写真、見取り図、入力記録にあり、低負担で即日着手しやすい。
2. 原因候補1、改善案1：本人発言、直前状況、前日のヒヤリとの関連が強く、時間帯を絞った対応が有効と考えられる。
3. 原因候補3、改善案3：前日のヒヤリが具体策に変わっていない点は再発防止上重要である。
4. 原因候補4、改善案4：業務重複と死角への対策は重要だが、業務分担の調整負担がある。
5. 原因候補5、改善案5：状態変化への対応として有用だが、直接原因としては追加情報が必要である。

現場で確認すべき点：
- 実際のベッド高、床マットの端、履物の滑りやすさ、歩行器の最適位置。
- ナースコールを本人が起き上がる側で使えるか。
- 14時台に担当者を割り当てるとき、現行業務のどこを分けられるか。
- ヒヤリハット後24時間シートを既存記録に無理なく組み込めるか。
- 眠りスキャンや離床センサーの一時使用が、身体拘束や過度な行動制限にならない運用か。
- 翌日受診結果、疼痛経過、歩行再開判断。

断定できないこと：
- 転倒の直接原因。
- 足が滑った場所やタイミング。
- 歩行器、履物、床マット、洗濯物カゴのどれが直接転倒に関係したか。
- 睡眠不足や眠気がどの程度影響したか。
- 離床センサーを使用していれば事故を防げたか。
- 頭部打撲や骨折の有無。

人間が最終確認すべきポイント：
- 今回の事故原因候補のうち、現場記録、写真、職員聞き取り、受診結果と最も整合するものはどれか。
- QOL尊重方針を維持しながら、居室内の物品配置、訪室時刻、担当者、機器使用基準をどこまで具体化するか。
- 事故前日のヒヤリハットを、翌日の具体策に変える仕組みをどの記録様式に組み込むか。
- 14時台の業務重複に対して、現場負担が過大にならない担当分けが可能か。
- 追加情報が得られた場合、原因候補5を主要候補に上げる必要があるか。

最終判断は人間が行う旨：
このレポートは、事故原因の確定や責任判断を行うものではなく、人間が検討するための材料である。最終判断は、施設の記録、職員聞き取り、受診結果、家族・本人方針、現場での実行可能性を踏まえて、人間が行う。

ダウンロード

介護事故やヒヤリハットの振り返りに使える、AI事故分析用ファイルです。必要な方は下記よりダウンロードしてください。

ファイルをダウンロードする

使い方（支援ツールを使う場合）

支援ツールを使うと、事故情報をフォームに入力するだけで、Codexで読み込むためのケースフォルダを作成できます。手作業で incident_input.md を編集するのが不安な場合は、こちらの方法がおすすめです。

手順1：支援ツールを起動する

ダウンロードしたファイルを解凍し、介護事故検証エージェントファイル作成支援.exe を実行してください。

手順2：フォームに事故情報を入力する

フォームに沿って、事故種別、発生日時、発見場所、利用者の状態、発見時の状況、事故後の対応などを入力します。

事故現場の写真、見取り図、介護記録、バイタル記録、眠りセンサーのデータなどがある場合は、「関連ファイル」の欄にドラッグ＆ドロップしてください。

※個人名、顔写真、施設名などの個人情報は、施設のルールに従って必要に応じてマスキングしてください。

手順3：ケースを作成する

入力が終わったら、画面下部の「ケースを作成する」をクリックします。

保存すると、cases フォルダ内に新しいケースフォルダが作成されます。関連ファイルに追加した資料も、自動でケースフォルダ内に保存されます。

手順4：Codexで分析を開始する

ケース作成後、Codexでこのプロジェクトフォルダを開きます。

支援ツール画面の右下にある「プロンプトをコピー」をクリックし、そのままCodexのチャット欄に貼り付けてください。

貼り付け後に送信すると、作成したケースフォルダをもとに事故検証が開始されます。

使い方（支援ツールを使わない場合）

最初から細かい仕組みを理解する必要はありません。まずは、次の流れだけ押さえれば使えます。

新しいケースフォルダを作る
incident_input.md に事故情報を書く
source_files に関連資料を入れる
着火用プロンプトをCodexに入力する
outputs に出た結果を確認する
13_final_report.txt を読む

手順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に入力する

Codexを開いたら、下の文章を貼り付けます。cases/case_2026_0504_fall_A/ の部分だけ、自分が作ったケースフォルダ名に変更してください。

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_001/ を分析したい場合は、対象ケースの部分を次のように変えます。