医院の困りごとを、使える小さな道具へ。金川歯科医院のAXプロジェクトでは、Codexを使い、書類作成や既存アプリとの連携を形にする取り組みを進めてきました。第5回は、各ツールを詳しく紹介する前に、何を作った記録があり、どこに確認課題が残るのかを整理します。
この記事は、運営者の説明と、2026年10月8日に整理した非機密の開発報告に基づきます。今回、現行コードや院内端末の動作を再検証したものではありません。患者情報や実際の診療画像は使用していません。
目次
出発点は、コンサル後の見積書づくり
運営者の説明では、コンサル後に見積書を作成する作業が、仕事の流れを詰まらせる一因でした。そこで医院の料金体系に合わせた見積書作成支援を実装し、ベータテストとフィードバックを通じて改善しました。開発報告にも、WEBアポを起点に治療内容などを選び、Excelの見積書を出力する拡張機能と、配布版を作成した記録があります。
ここで大切なのは、「何でも自動化する」より、困っている一つの作業を具体的な入出力へ置き換えたことです。医院の料金体系や、最終的に誰が内容を確かめるかは、医院側が決める要件です。作成時間が何分短くなったか、何人が試したかという測定値は今回の資料にはなく、効果を数字では示していません。
同じ「連動」でも、確認できた範囲は違う
見積書から広がったプロジェクトを、記録のある範囲で並べると次のようになります。以下は現在の完成度を保証する一覧ではなく、各論で確かめるための見取り図です。
- 診療情報提供書:見積書の拡張にWord文書・定型返書の作成機能を加え、配布したという開発報告があります。出力内容や紹介先の照合、必須項目不足時の扱いは、別途確認が必要です。
- 歯科衛生士実地指導用紙と歯周検査:連動を扱う開発相談と、印刷・PDF保存の課題の記録があります。今回確認できた要約だけから、完成や試験完了とは書けません。
- 3Shape Unite:連携ツールの作成と別PCでの連携報告があります。一方、初回の患者対応付けや、再起動後の設定保持に確認課題が記録されています。
- DICOMデータのZIP化・保存:対象検査を探して圧縮ファイルとして保存する拡張・PC側ツールの配布と、限定条件での試験報告があります。すべての端末・検査で検証済みという意味ではありません。
名称だけを見ると、どれも「つながった」と一言でまとめたくなります。しかし、書類を出せること、別PCで一度動くこと、再起動後も継続して使えることは、それぞれ違う確認です。開発記録に残る成果を伝えるときも、その範囲を添える必要があります。
実装・試験・実運用・構想を分ける
この連載では、実装は機能を作った段階、試験は決めた条件で動きを確かめた段階、実運用は実際の業務で継続して使う段階、構想はこれから作る内容として区別します。一つのツールの中でも、出力部分は実装済み、例外への対応は検討中ということがあります。
予約リマインダーや仕入AGENTも後続回のテーマですが、今回参照した資料だけでは現在の実装・運用範囲を確定できません。保険請求点検AGENTは、この連載では構想として扱います。発注や算定の判断まで自動で正しく完了できる、という実績に置き換えないことが大切です。
コードの先に、医院で確かめる仕事がある
OpenAIの公式説明でも、Codexのコードレビューは追加の確認役であり、テストや必要な承認を置き換えるものではないと位置付けられています。医院の道具でも、実装の報告を読むだけで、出力の正しさや業務への適合まで確認できたことにはなりません。
たとえば架空データで書類が作れても、患者と書類の対応、金額、保存先、途中で止まったときの扱いは別の確認項目です。送信される情報と処理先も、設定や実装に即して確かめます。カルテ番号への置き換えやZIP化だけを、匿名化とは扱いません。診療判断や書類の最終内容は、担当者が確認する範囲として残します。
形になった機能と、次に確かめることの両方を残す。それが、医院で使う道具を育てるための開発記録です。次回は、困りごとを要件に分け、架空データで小さく試す手順を紹介します。
資料・確認日
- 金川歯科医院の運営者による説明、および非機密の開発報告の整理(整理日:2026年10月8日/本文との照合:10月16日)。現行コード・実機の再検証、実運用効果の測定は今回行っていません。
- OpenAI Developers:Custom Code Review rules for Codex(公開:2026年7月20日/確認:10月16日)。コードレビューとテスト・承認の役割に関する公式説明です。
本記事はAIの作成支援を利用しています。公開後に運営者が確認し、必要に応じて追記・修正します。
歯医者のどんちゃん 