外注見積もりが120万円だった。それを断って、自分で作った話をする。
見積もりを受け取ったのは、ある医療機器の点検スケジュール管理ツールが欲しくなったときだ。Excelで管理していた機器台帳が崩壊しかけていた。更新漏れが続き、点検期限を担当者ごとに口頭で確認する状況になっていた。
「これはシステムが要る」と思ってITベンダーに声をかけた。返ってきたのが120万円という数字だった。しかも「標準機能に合わせていただく部分が出ます」という但し書きつきで。
私は断った。そして3週間後、自分でアプリを作って運用を始めた。
—
なぜ既製ツールは現場に合わないのか
医療機器のメンテナンス管理には、独特の複雑さがある。
機器の種類ごとに点検周期が違う。修理業の許可区分によって記録すべき項目が変わる。担当するエンジニアのスキルセットも機種によってバラバラだ。さらに、施設から来る「この機器を優先してほしい」という現場要求が日々割り込んでくる。
汎用ツールはこの複雑さを吸収できない。「医療機器対応」と書いてあっても、実際には製造業向けの工場設備管理ツールに毛が生えた程度のものが多い。フィールドの温度感が開発者に届いていないからだ。
外注で作っても同じ問題が起きる。要件定義の段階で「現場のニュアンス」を言語化しきれない。結果として、出来上がったシステムを現場に合わせて運用を歪める羽目になる。
[ChatGPTをメンテナンス業務に使った実例](/chatgpt-maintenance-practical-use-cases/)を読むと、既製ツールの限界と個別最適化の話が具体的に出てくる。ここで感じた違和感が、自作という選択肢につながっていった。
—
AIで「自作」するとはどういうことか
私がやったことを正確に言う。コードは1行も書いていない。
使ったのはChatGPTとGoogleスプレッドシートとGAS（Google Apps Script）だ。
まずスプレッドシートに機器台帳のシートを作り、点検周期・最終点検日・担当者を入力した。次にChatGPTに「このシートから点検期限が30日以内の機器を抽出して、担当者にメールで通知するGASのコードを書いてほしい」と伝えた。
出てきたコードをそのままGASのエディタに貼り付けて実行した。最初はエラーが出た。そのエラー文をそのままChatGPTに貼り返した。「このエラーが出た。直して」と。
3回のやり取りで動いた。
[医療機器メンテナンスにAIを使う3つの現実的な方法](/medical-device-maintenance-ai-practical-use/)で書いているように、AIはコードを書く道具というより、「私の要件を翻訳してくれるパートナー」として使うのが正しい。自分がやりたいことを日本語で伝えるだけでいい。
—
現場に合ったツールを作るための判断基準
自作するかどうかの判断は、3つの問いで決まる。
その業務フローは、自分たちだけのものか。
汎用ツールで十分カバーできる業務は、わざわざ作らなくていい。「うちの現場は少し違う」という部分が核心にある場合だけ、自作を検討する価値がある。
更新頻度はどのくらいか。
機器台帳のように、運用しながら項目が増えていくものは自作に向いている。ベンダーに都度改修を依頼すると費用がかさむが、スプレッドシートベースなら自分たちで変えられる。
誰がメンテナンスするか。
私がいた現場では、私が作ったものを私以外の誰かが触れるようにしておく必要があった。だからシートの構造をシンプルにして、GASのコードにコメントを多めに入れるようChatGPTに頼んだ。「引き継ぎを考えた構成にして」と言えば、それに応じてくれる。
[紙の作業記録をやめた現場で起きた変化](/maintenance-record-digitalization-change/)にも書いてあるが、デジタル化は「誰でも触れる状態を作ること」が本質だ。難しいシステムを導入しても、使える人が限られれば意味がない。
—
まとめ——今日できる一歩
120万円の見積もりを断って良かったと、今でも思っている。
あのシステムを入れていたら、現場の変化に合わせて都度ベンダーと交渉しなければならなかった。今は自分たちで変えられる。それだけで、管理の質が変わる。
まず今日できることは一つだ。自分の業務の中で「Excelが壊れかけている」か「口頭確認が常態化している」プロセスを一つ特定する。そこを起点に、ChatGPTに「こういうものを作りたい」と話しかけてみる。
[取説PDFから点検チェックリストを自動作成する方法](/maintenance-checklist-pdf-ai-manualcheck/)も参考になる。AIで現場ドキュメントを活用する入口として、試しやすい事例だ。
—
よくある質問
プログラミング知識がまったくなくても作れるか
作れる。ただし「何を作りたいか」を日本語で言語化できる必要がある。「こんな機能がほしい」「こういうときにこう動いてほしい」を具体的に伝えるほど、AIの出力精度が上がる。コードの読み書きは不要だが、業務フローへの理解は要る。
GAS以外の手段はあるか
ある。Notionのデータベース＋自動化、Airtable、Microsoft Listsなどがローコードの選択肢として使われている。何を選ぶかは、すでに組織で使っているツールのエコシステムに合わせるのが最速だ。GoogleWorkspaceを使っているならGAS、Microsoft365ならPowerAutomateが自然な選択になる。
医療機器特有の規制に抵触しないか
点検スケジュール管理や通知ツールは、規制対象となるソフトウェア（SaMD）には該当しない。ただし、記録の保存・改ざん防止・バックアップについては自組織のQMS手順に照らして確認する必要がある。外部システムに記録を移す場合は、監査証跡が残る設計にすることを忘れないようにする。
作ったツールが壊れたときはどうするか
エラーが出たら、エラーメッセージをそのままChatGPTに貼り付けて「直して」と伝える。これで大半のバグは解消できる。それでも解決しない場合は、構造を単純化する方向で作り直すのが早い。複雑なツールより、シンプルで誰でも直せるツールの方が現場では長生きする。
—
ツール紹介
ChatGPT（OpenAI）
現場アプリ自作の起点として使いやすいAIツールだ。コード生成・デバッグ・要件整理のどれにも対応する。有料版（Plus）にするとコード実行環境が使えるため、出力したコードの動作確認もその場でできる。月額20ドルで試せる入口としては、費用対効果が高い。
Claude（Anthropic）
長い文脈を扱う業務に向いている。取説や手順書などの長文PDFを読み込んでそのまま対話できるため、ドキュメントから要件を抽出する作業との相性が良い。「このマニュアルの中で定期点検に関係する部分だけ抜き出して、チェックリスト形式にして」という使い方が、医療機器メンテナンスの現場では実用的だ。
コメント