医療システムの開発に、AIエージェントをどこまで使えるか

医療システムの開発におけるAI活用には、はっきりした利点と、はっきりした危険があります。間違いが患者さんに届くからです。

MENTRAは開発にAIエージェントを本格的に使っていますが、「AIに書かせている」という話ではありません。どこを任せ、どこを機械で止めるかの線引きが本体です。

何が危険か

AIにコードを書かせるとき、いちばん危ないのはもっともらしく間違えることです。

3つ目が特に厄介です。AIが「できない」と答えることと、仕組みが止めることは別物です。前者は説得で変わります。安全に関わる確認は、AIの返答を検証結果にしてはいけません。

MENTRAでは開発の工程をあらかじめ固定しています。要件整理 → 影響調査 → 実装計画 → 実装 → レビューパケット生成 → セキュリティレビューとコードレビュー → ドキュメント更新 → 適用確認、という流れです。

工程を固定する目的は、同じ確認を毎回必ず通すことにあります。人が「今回は急ぎだから」と飛ばす余地を作らない。AIに任せる範囲が広いほど、飛ばせない道を用意しておく必要があります。

とくに「影響調査」と「適用確認」を独立した工程にしているのは、実装した人が自分で確かめると見落とすからです。適用確認では、仕様書に書かれたリリース対象と、実際の本番環境の状態を突き合わせます。

安全に関わる確認は、道具を奪ったうえで実測します。「使えないはずだ」ではなく、実際に使えないことを試して確かめる。そして「拒否された」で終わらせず、何が拒否したのかまで見ます。検証したい仕組みが働いたのか、別の理由でたまたま止まったのかは、別のことだからです。

許可リストについても、「書いていないから使えない」は成り立たないと実測で分かっています。使わせたくないものは、明示的に閉じる側で止めます。

守りを入れたあと、それが効いているかを確かめる機会はめったに来ません。異常が起きなければ試されないからです。

そこでMENTRAでは、重要な守りを意図的に壊して、赤くなることを確認しています。本番で動いているものではなく複製を使い、守りが実際に働くかを見ます。

このとき分かったことがひとつあります。ガード1つにつきテストを1本にしておかないと、複数のガードが同じケースを塞いでいる場合に、片方を壊しても緑のままになります。守りが1枚素通りしていることに気づけません。

機械判定は「これが出たら誤り」だけに使います。「この語があれば正しい」という判定は、正解を落とします。

ここまでの3つは、冒頭に挙げた「もっともらしい間違い」への手当てです。並べると対応が見えます。

もっともらしい間違い	どう現れるか	機械の側でどう止めるか
条件の抜け	動くコードが返るが、医療機関ごとのデータ分離の条件が抜けている	影響調査と適用確認を独立した工程にして、実装した本人以外が通す
何も検証していないテスト	テストは緑だが、守りが働いているかは分からない	守りを意図的に壊して赤くなることを見る。ガード1つにテスト1本
説得で変わる「できません」	指示の書き方次第で答えが変わる	道具を奪って実測する。使わせたくないものは閉じる側で止める

開発だけでなく、日々の運用にもAIを組み込んでいます。届いた連絡の一次整理、状況の要約、定型の報告。ここでも同じ線引きです。

そして、「聞く」こと自体が工数だと考えています。確認ダイアログも、選択肢も、通知も、利用者の時間と判断を奪います。だから聞いてよいのは、戻せない操作か、機械が決めてはいけない判断のときだけ。それ以外は聞かずにやります。

開発の判断は、仕様書として残します。なぜそう作ったか、何を検討して何を採らなかったか、どこまで本番に出したか。後から読む人が、実装を読み直さずに背景に辿り着ける状態を作ります。

同じ考え方を、対外的な発信にも使っています。記事がどの実装から生まれたかの対応表は、記事の付記から自動生成しています。手で書くと必ず片方だけ古くなるからです。

AIを使うと開発は速くなりますが、その速さは確認を減らして得たものであってはいけません。 医療システムでは、間違いの代償が他の領域と違います。

MENTRAが工程を固定し、守りを機械で止め、テストを壊して確かめているのは、速さと安全を同時に成り立たせる方法がそれしかないと考えているからです。

こうした開発・運用の自動化は、医療AIの開発で培ったものです。ご提案にとどまらず、実装・運用まで含めた実行支援も行っていますので、社内の業務を仕組みで軽くしたいというご相談も歓迎です。まずは現状をお聞かせください。お問い合わせからお気軽にどうぞ。