Excelの限界を感じたので、AIにアプリを作ってもらった──ヒヤリハット報告書をClaude Codeでアプリ化した記録
目次
この記事は、プログラミング未経験の理学療法士が、エージェント型AIに頼んで現場の業務効率化アプリを作った記録です。書いた人は、コードは1行も書いていません。書いたのは「こういうアプリが欲しい」という日本語の依頼と、AIに作ってもらった要件定義書だけです。
題材は、通所リハで使っていたマクロ付きExcelの「ヒヤリハット報告書」。これをエージェント型AI「Claude Code」に頼んで、現場のWindowsパソコンで動くデスクトップアプリに置き換えました。半月ほどの作業で、現場運用に入っています。
「アプリを作る＝エンジニアの仕事」というのは、もう一段崩れていて、医療介護の現場職でも、この記事くらいの規模のアプリならパッと作れる時代になっています。本記事は、その実例を「実際のプロンプト」「要件定義書」「つまずいたところ」までそのまま見せる形でまとめます。
この記事で扱う構成要素は次のとおりです。
- AIツール：Claude Code（エージェント型AI・有料）
- 入力：自分の言葉で書いた要件定義書（Markdown）と、画面を見ながらの会話
- 出力：Windowsインストーラー（.exe）／SQLite共有DB／PDF帳票
- 配布：GitHub Actionsで自動ビルド → Googleドライブで現場PCへ配布
- 既存資産：マクロ付きExcel（.xlsm・57列）からのデータ移行機能つき
以下、Excel運用が辛くなった理由から、配布まで一気に通った半月の手順を、実際に使ったプロンプトと一緒に紹介します。
1. Excel報告書の何が辛かったか
通所リハの現場では、ヒヤリハット（インシデント）報告書をマクロ付きExcelで運用していました。1件＝1行の入力シートに57列ぶんを埋めて、別シートで報告書帳票が自動生成される。よくある形だと思います。
辛かったのは次の3点です。
- 入力に時間がかかる。プルダウンを開いてスクロールして選ぶ操作が、ノートPCのトラックパッドだと毎回ストレス
- 集計が手作業。年度末に「分類別件数」「リスクレベル別件数」をピボットで作り直す
- 共有が壊れやすい。複数人が同時に開くと「読み取り専用」になり、誰かが閉じるまで待つ
報告そのものは現場の安全文化の土台なので、減らせません。減らせるとしたら、入力と集計の手間だけです。「Excelをやめたい」というより「同じデータを、もっと入れやすく、自動で集計できる形にしたい」という気持ちでした。
2. 「アプリにしよう」と決めた理由
Excelの代わりに使えそうなクラウドサービス（kintone、サイボウズ、Microsoft Forms＋Power Apps など）も検討しました。ただ、勤務先の通所リハには次の制約があります。
- 患者・利用者情報を含むデータは、原則として施設の共有フォルダ（NAS）から出さない
- 月額のSaaSは稟議が重い。最低でも1年は試したい
- 触るのは現場スタッフ。「インストールしてアイコンをダブルクリック」で動く形がいい
この3つの制約は、医療介護の現場ではどこでも似たような顔ぶれだと思います。クラウドに乗せにくくて、すぐ試したくて、現場が触れる形がいい。であれば、自分たち専用のデスクトップアプリを1個作ってしまうのがいちばん早い、と判断しました。
これくらいの規模（入力フォームが1つ・印刷帳票が1つ・集計画面が1つ）であれば、エージェント型AIに頼めば数日〜半月で形になります。基本方針としては「重たい開発の経験がないとできない」のではなく「このサイズの業務アプリならパッと作れる」というのが、今回の出発点です。
3. 使ったもの：Claude Code（エージェント型AIの説明）
ここで使ったのは「Claude Code」というツールです。ChatGPTやGeminiのような対話型AIと違って、自分のPCのフォルダを見て、ファイルを直接読み書きして、コマンドを実行できる「エージェント型AI」です。
イメージとしては、こうです。
- ChatGPT/Gemini：相談できる相手（コードを書いてくれるが、貼り付けて実行するのは自分）
- Claude Code：手を動かしてくれる相手（フォルダを開いて、ファイルを作って、エラーを見て、自分で直す）
「ヒヤリハット報告書のアプリを作りたい」と日本語で頼むと、設計してファイルを作り、テストして、エラーがあれば直してくれます。動かしてみて違和感があれば、「ここをこうして」と日本語で伝えるだけで修正されます。
なお、Claude Codeは有料です（Anthropicの有料プラン）。詳細は公式サイト（https://www.anthropic.com/claude-code）を参照してください。本記事では、別のエージェント型AIである「Codex（OpenAI）」もセカンドオピニオン的に併用していますが、軸はClaude Codeです。
4. 全体の流れ（まずはAIに相談するところから始める）
具体的な手順に入る前に、全体像を整理しておきます。今回の半月でやったことは、ざっくりこの5ステップでした。
- Step 0：AIに相談する — 何から始めればいいか、どんなやり方が向いているか、AIに聞く
- Step 1：要件定義書を一緒に作る — 目的・利用環境・機能・制約をAIと話しながら1枚にまとめる
- Step 2：画面とDBを作ってもらう — 要件定義書を渡して、土台を一気に作ってもらう
- Step 3：動かして直すの繰り返し — 現場で触って、違和感を日本語で伝えて直してもらう
- Step 4：Windowsで配布する — 自動ビルドの仕組みを組んで、現場PCに届ける
- Step 5：セキュリティチェックをAIにかける — 別のAIにセカンドオピニオンとして脆弱性を見てもらう
ここでいちばん大事なのは、Step 0です。
初めてアプリを作る場合、いきなり要件定義書を書こうとしたり、いきなりコードを書こうとしたりすると、ほぼ確実に詰まります。私もそうでした。最初にやることは、「何から始めればいいですか」とAIに相談することです。
たとえばこんな相談で構いません。
通所リハの現場でExcelの報告書をアプリにしたいです。
私はプログラミング未経験です。
何から始めればいいですか。どんなやり方が向いていますか。これだけで、AIは「まずは要件定義書から作りましょう」「アプリの形はElectronのデスクトップアプリが向きます」「データはSQLiteで十分です」と、進め方の選択肢を提示してくれます。選択肢が分かれば、判断できます。
自分だけで考えない、というのが一番の肝です。AIに相談する → 出てきた選択肢を見て決める → またAIに相談する。この往復を、要件定義から配布まで全部のフェーズで続けただけ、というのが今回の正直な感覚です。
ここから先は、5つのステップを順番に見ていきます。
5. Step 1 — 要件定義書をAIと一緒に作る
最初にやったのは、設計でもUIスケッチでもなく、「要件定義書を作る」ことでした。
要件定義書って何ですか
理学療法士をやっていると、「要件定義書」という言葉自体になじみがありません。簡単に言うと、アプリやプロジェクトを始める前に「何のために作るのか」「誰が使うのか」「どこまでやるのか／やらないのか」を1つの文書にまとめたものです。
カルテで言えば、評価・目標設定・治療計画にあたります。ゴールと、その範囲と、ルールを最初に決めておくための紙、というイメージです。
- 目的（何を解決するアプリか）
- 利用者と利用環境（誰が・どこで・どんなPCで使うか）
- 機能の一覧（できることの範囲）
- やらないこと（範囲外として明示する）
- 制約条件（共有フォルダで動かす、ネットに出さない、など）
これを最初に決めておくと、AIに頼むときも、現場のスタッフに説明するときも、判断の軸が1本通ります。途中で「やっぱりこれもほしい」が出ても、要件定義書に書いてあるか／追加するか、を見れば迷いません。
それ自体もAIに作ってもらった（ここが一番の肝）
ただ、要件定義書を初めから1人で書こうとすると、たぶん挫折します。私もそうでした。
今回いちばんの肝は、要件定義書そのものをAIと相談しながら作ったところです。手順としてはこうでした。
- 現行のExcel（マクロ付き・57列）をそのままAIに渡す
- 「このExcelをアプリ化したい。要件定義書を一緒に作ってください」と頼む
- AIが章立て（目的／利用環境／機能／DB／帳票／未確定事項）を提案してくる
- 1章ずつ、「ここはこうしたい」「これは分からない」と答えていく
- AIが「では、ここは仮置きでこう書きます」「ここは現場に確認してください」と整理してくれる
要件定義書は完璧でなくていい、というのが今回いちばんの学びです。分からないところは「未確定事項」として残しておけば、AIが「これは後で運営者に確認」とラベルを付けて残してくれます。
実際に使った初回プロンプトは、こんな雑なものでした。
通所リハで使っている報告書をアプリでやりたいです。
入力したいのと、印刷したいのと、分析とかができる感じがいいです。
今のExcelを添付しました。これと同じ項目で作ってください。
まずは要件定義書を一緒に作りましょう。
分からないところは私に質問してください。これだけです。あとはAIが質問してくれる質問に答えていくだけで、A4で十数枚の要件定義書がそろいました。完成版は、アプリのリポジトリ内に置いてあります（個人情報・施設名は含まれません）。
ここで分かったのは、「AIと相談しながら進める」というのが、コードを書く場面だけでなく、その前の設計・整理の段階からずっと使えるということです。一人で考え込まずに、AIに壁打ち相手になってもらう。今回の作業を通じて、いちばん変わったのはこの感覚でした。
6. Step 2 — 画面とDBを作ってもらう
Claude Codeに上の依頼を渡すと、要件定義書を整理し直したうえで、次を順番に作ってくれました。
- プロジェクトの初期設定（Electron + React + TypeScript + Tailwind CSS）
- SQLiteの初期化スクリプト（テーブル定義・マスタ初期データ）
- 6つの画面：報告一覧 / 入力 / 帳票印刷 / 集計・分析 / 職員マスタ / 選択肢マスタ
- メインプロセス（DB操作）と画面側（フォーム）をつなぐIPC層
ここで自分がやったのは、「動かして触ってみる」だけです。
npm run dev というコマンドを実行すると、開発用にアプリが立ち上がります。立ち上がったら、フォームに適当に入力してみて、保存ボタンを押す。一覧が出るか、印刷プレビューが出るか、を見ます。
最初の起動で気づいた違和感は5つでした。
- 職員登録フォームの日付欄が「年/月/日」表示しか出ず、何の日付か分からない
- 全角の職員番号「４９２」と半角の「492」が別レコードとして二重登録される
- 入力中にタブを切り替えると、入力が消える（確認ダイアログがない）
- 「下書き」を保存しても、一覧に出ない
- 報告一覧から職員番号で絞り込みたいのに、絞り込み欄がない
これを順番に、日本語で伝えました。たとえば②はこう頼みました。
職員番号を全角で入れた人と半角で入れた人が
別の人として登録されてしまうみたいです。
入力時に半角の数字に揃えるようにしてください。Claude Codeは「normalizeStaffNo という関数を作って、入力時に半角化する」処理を、入力画面と職員マスタ画面の両方に適用してくれました。自分はそのコードを読んでいません。動かしてみて、全角で入れても半角に直って保存されることだけ確認しました。
7. Step 3 — 動かして直すの繰り返し（不具合修正の実例）
ここからは、現場のスタッフに触ってもらいながら、出てきた声を順番にAIに渡していく時期です。
たとえば、こんな声が出ました。
- 「新規報告の画面で、タブを行き来したあと、入力欄が反応しなくなる」
- 「職員マスタで、新規登録のときに職員番号が入力できない」
- 「既存Excelから過去ぶんを取り込みたい」
- 「集計画面で期間を指定したあと、別の画面に行って戻ると、期間がリセットされる」
このうち「タブ往復後に入力欄が効かなくなる」は、私には何が起きているのか分かりませんでした。なので、こう伝えました。
新規報告を書こうとして、いったん一覧画面に戻って、
もう一度新規報告を開くと、入力欄に文字が入らなくなります。
何度か再現します。原因を調べて直してください。Claude Codeは、画面間の状態管理（未保存フラグの解除タイミング）が原因だと特定し、修正してくれました。私がやったのは、修正後に「直ってますね」と確認することだけです。
「既存Excelから取り込みたい」は、設定画面に「Excelを選ぶ → プレビュー → 取り込み」のUIを追加してもらいました。現行Excelには職員番号の列がないので、取り込み時の staff_no は空欄になります。これは仕様として運営側に確認しました。
学び: AIに直してもらうときは、「何をして」「どうなった」「期待はこう」の3点を日本語で書くだけでいい。コードの場所や原因は、AI側が探してくれます。
8. Step 4 — Windowsで配布する（GitHub Actions → Google Drive）
社内のPCはWindowsです。MacBookで作ったアプリを、Windows用のインストーラー（.exe）に変換する必要があります。
これも、Claude Codeに丸投げしました。
このアプリをWindowsで動くようにしたいです。
うちの現場ではたくさんのPCを一つのところで使えるようにしてるから、
そこ（共有フォルダ）にDBを置く形で動くようにしてください。Claude Codeと相談しながら、こういう流れに落ち着きました。
- ソースコードはGitHubのプライベートリポジトリに置く
- バージョンタグ（
v0.1.0など）をpushすると、GitHub ActionsがWindowsマシン上で自動的に.exeをビルドする - ビルドされた
.exeを、Googleドライブの所定フォルダに置く - 各PCで、ドライブからダウンロードしてインストールする
「GitHub Actions」も「electron-builder」も、自分は名前しか知りません。それでも動いているのは、AIが設定ファイルを書いて、エラーが出たら自分で修正したからです。
途中で2つだけ詰まりました。
- electron-builderがタグpush時に勝手にGitHub Releaseへ公開しようとして、トークンエラーで止まる
- GitHub Actionsのデフォルト権限ではReleaseを作れず、403エラーになる
どちらもエラーメッセージをそのままClaude Codeに渡して、--publish never を付ける／ワークフローに permissions: contents:write を足す、という形で解決しました。
最終的な配布物は、Googleドライブの施設用フォルダに ヒヤリハット報告アプリ_v0.1.2_Setup.exe の名前で置いています。新しいバージョンが出たら、同じフォルダにバージョン番号を上げて積み上げるだけです。
9. Step 5 — セキュリティチェックを別のAIにかける（セカンドオピニオン）
現場のスタッフが触るアプリで、しかも患者の情報（性別・年齢・病名）を扱う以上、配る前にセキュリティの確認は必要です。とはいえ、私は情報セキュリティの専門家ではありません。
ここで使ったのが、もう一つのエージェント型AI「Codex（OpenAI）」です。Claude Codeで作ったコードを、別のAIにレビューしてもらうイメージです。同じことを2つのAIに見せると、片方が気づかなかった問題をもう片方が拾ってくれることがあります。医療で言うところのセカンドオピニオンと同じ発想です。
頼んだのはシンプルにこれだけです。
このアプリを現場で配布する前に、セキュリティ面のチェックをしてください。
依存ライブラリの脆弱性、データ保存の安全性、配布物の安全性、
気になる点をすべて挙げてください。Codexは次のような形でレポートを返してきました。
- 依存ライブラリに脆弱性が10件（high 5件・moderate 5件）。配布前に更新したほうがいい
- 共有フォルダ上のデータベース・バックアップ・PDFは暗号化されておらず平文で保存されている
- アプリ内のログイン認証がないので、PCを開ける人は全員アプリも開ける
- Windowsインストーラーに署名がないため、SmartScreenで警告が出る
- 一方で良い点として、
.envファイルや実データはリポジトリに含まれておらず、SQLは安全な書き方で実装されている
このレポートを見て、「これは試験運用の段階なので許容」「これは本格運用の前に直す」と判断を分けました。判断するのは現場の責任者（私）です。AIは候補を網羅的に出してくれる、人間が優先順位を決める、という分担です。
ここで言いたいのは、セキュリティのような専門領域も、「自分には分からないから誰かに頼まないと」と止まる必要はない、ということです。AIに「気になる点を全部挙げて」と頼めば、論点が一覧で出てきます。その一覧を見れば、判断はできます。
10. 自分がやったこと、AIがやったこと
ここまでの作業を、役割分担で整理しておきます。
私（プログラミング未経験のPT管理職）がやったこと：
- 現場の困りごとを言葉にする
- 要件定義書を日本語で書く（A4数枚、未確定事項も含めてOK）
- アプリを動かして、違和感を1行で伝える
- バージョンを上げる判断、配布の判断
- 個人情報・運用ルール・バックアップ体制の責任を持つ
AIがやったこと：
- 進め方の選択肢を提案する（Step 0の相談相手）
- 要件定義書の章立てを作り、こちらの回答を整理する（Claude Code）
- 画面・DB・帳票・印刷・集計を実装する（Claude Code）
- バグの原因を調査して直す（Claude Code）
- Windows向けの自動ビルドを構築する（Claude Code）
- 既存Excelからのインポート機能を作る（Claude Code）
- セキュリティ面の懸念を網羅的に洗い出す（Codex・セカンドオピニオン）
つまり、判断と検証は人間が、選択肢の提示と実装と調査はAIが、という分担です。コードを1行も書かなくても、現場で使えるアプリは作れる、という実感が残りました。
11. 現在地とこれから
現在（2026年6月時点）、このアプリはv0.1.2で試験運用中です。完成品ではありません。
- 帳票レイアウトは原本Excelとの照合・微調整がこれから
- 共有フォルダ運用での複数PC同時利用は、これから現場で検証
- セキュリティ（依存関係の更新・Electronの設定強化・配布物への署名）は本格運用前に対応予定
未完成のまま現場に出しているのは、「完成してから出す」と永遠に出ないと知っているからです。試験運用で出てきた違和感を、また1行で伝えて、また直してもらう。この繰り返しを半月続けるだけで、Excelに戻りたいと思う人はいなくなりました。
「Excelの限界を感じたら、AIにアプリを作ってもらう」という選択肢が、現場の管理職にも普通にある時代になったと思っています。プログラミングを学ぶ必要はありません。自分の現場で起きていることを、自分の言葉で書く力さえあれば、形になります。
まとめ
- マクロ付きExcelの報告書を、Claude Codeに頼んで半月でWindowsデスクトップアプリに置き換えた
- いちばん大事なのはStep 0「まずAIに相談する」。自分だけで考えない
- 要件定義書もAIと一緒に作る。書き方が分からなくても、質問に答えていけば形になる
- AIは設計・実装・バグ修正・配布ビルド・セキュリティ点検まで担当。判断と検証は人間側に残る
- セカンドオピニオンとして別のAI（Codex）にレビューさせると、見落としを拾える
- 「完成してから出す」ではなく「未完成のまま試験運用」が現実解
- 同じやり方は、報告書以外の業務（記録・申し送り・委員会資料）にもそのまま使える
次に試したいAI活用や、議事録AIの土台になっている考え方は、別記事にまとめています。
関連記事
NotebookLMで議事録3日→10分。委員会議事録こそAIに任せるべき4つの理由
NotebookLMで委員会議事録の作成を3日から10分に短縮した実例。なぜ議事録こそAI活用の入口として最適なのか、その4つの理由（定型業務・個人情報が薄い・効果が見える・毎月発生）と、最短手順・プロンプトの型・用語集・手直しまで学べる全5回シリーズの全体像を紹介します。
関連記事
医療介護の音声入力ツール比較【2026年版】｜4タイプの選び方と始め方
医療・介護で使える音声入力・AIボイスレコーダーを、医療専用/介護専用/汎用議事録/デバイス型の4タイプで比較。選び方の判断軸と、現場管理職がどこから始めたかを実例で解説します。
導入の相談や「自施設に合うやり方を一緒に考えてほしい」というご依頼は、お問い合わせからどうぞ。現場目線で一緒に整理します。