【第18回】なぜエンジニアより放射線技師の方がいいツールを作れるのか—専門知識がそのままAIへの指示書になる時代
「AIでツールを作りたいけど、プログラミングができないので無理です」
こういうメッセージをいただくことがよくあります。
気持ちはわかります。でも、この前提は間違っています。
プログラミングができなくても、ツールは作れます。
それだけではありません。
放射線技師のような医療専門職は、ある意味でエンジニアよりも有利な立場にいます。
この記事ではその理由を整理しますが、まずその前に「Vibe Coding」という考え方について説明します。これを知らずに「プログラミングが必要か否か」を議論しても、話がかみ合わないからです。
ここ数年でAIの能力は急速に上がり、「自然言語でAIに指示を出すだけでコードが生成される」という状況が当たり前になりました。Vibe Codingとはまさにそのやり方のことです。コードを自分で書かず、「こういうものが欲しい」と日本語で伝えるだけで、AIが実装を担ってくれる。
この文脈において、「プログラミングが書けるか書けないか」という問いはもはやあまり意味を持ちません。問われるのは別の力です。「何が必要かを言葉にする力」と「その言葉をAIに正確に伝える力」。この2つが、Vibe Codingの質を決めます。
そして放射線技師は、この2つをすでに持っています。なぜそう言えるのか。理由を3つ挙げます。
Vibe Codingとは何か
Vibe Codingとは、コードを自分で書かずに、AIに自然言語で指示してプログラムを作るやり方です。「こういうツールが欲しい」と伝えるだけで、AIがコードを生成してくれる。実装の詳細はAIが担う。
最近では本職のプログラマーですらもVibe Codingを多用するようになっていると言います。
「でも、出てきたコードを理解しないといけないのでは？」という疑問が出ます。
実際には、理解できなくても動くものは動きます。エラーが出たらエラーメッセージをそのままAIに渡す。修正が必要な箇所はAIが直す。このループで完成させる方法は、もはや定番になっています。
では、この方法で何が一番重要かというと——「最初に何を作ればいいかを決める力」と「AIへの指示を正確に伝える力」です。どちらもコードとは無関係です。
根拠①：専門職はすでに「要件の言語化」を日常でやっている
ツールを作る最初のステップは、「何が必要か」を言葉にすることです。ソフトウェア開発の現場では、これを「要件定義」と呼びます。プロのエンジニアでも、要件定義を正確にやることが一番難しいと言われています。
放射線技師は、この作業を日常的にやっています。
たとえば、検査プロトコルを組むとき。「この患者にはこのシーケンスで、この条件で撮る」を決める判断は、「何が必要か」の言語化そのものです。装置メーカーへの要望や、院内での仕様確認も同じです。「今のシステムではこれができない、だからこうしてほしい」と伝える作業は、要件定義と構造が変わりません。
エンジニアは技術は持っているが、医療現場の要件はわからない。技師は現場の要件をわかっているが、コードは書けない。Vibe Codingが埋めるのは後者のギャップだけです。前者のギャップは、埋まりません。
根拠②：現場の「解像度」がそのまま指示の精度になる
AIへの指示の質は、現場の解像度に比例します。
「CTの品質管理ツールを作って」という指示と、「CTの不変性試験でMTFをROI自動設定で計測し、基準値と比較してレポート出力するツールを作って」という指示では、出てくるものが全然違います。
後者の指示は、放射線技師でないと書けません。MTFとは何か、ROIとは何か、不変性試験にどんな項目があるか——この知識がなければ、指示自体が組み立てられません。
エンジニアが医療ツールを作るとき、最初に技師からヒアリングする時間が何時間もかかるのはこのためです。技師が自分でAIに指示を出す場合、そのヒアリング工程が不要になります。現場の知識が、そのまま指示の精度になる。
第13・14回でやった棚卸しと言語化は、この「指示の精度を上げる」作業そのものでした。
根拠③：「動いたかどうか」の判断ができる
AIが生成したツールを使えるかどうか、最終的に判断するのは人間です。この判断に必要なのは、コードを読む力ではなく、「これは業務で使えるか」を評価する力です。
計算結果が正しいかどうか、UIが現場の使い方に合っているかどうか、エラーが出たときに何が起きているかを説明できるかどうか——これらはすべて、現場の経験から来ます。
エンジニアが医療ツールを単独で作って現場に持っていくと、「使いにくい」「この値は合わない」「この状況が想定されていない」という問題が出ることが多い。それは現場の評価軸を持っていないからです。
自分で作ったものを自分で評価できる。このループが回せる人間が、一番速く良いものを作れます。
「でも、エラーが出たら詰みませんか？」
よく聞かれます。答えはシンプルです。
エラーが出たら、エラーメッセージをコピーしてAIに渡す。「こういうエラーが出た、直して」と一言添えるだけです。それだけで、ほとんどのエラーは解消します。
解消しない場合は、「解消できなかった、別のアプローチを提案して」と続ける。コードの中身を自分で読む必要はありません。
第14回のワークシートで言語化まで終わっている人は、すでにこの入口に立っています。次のステップは、そのままAIに渡してみることです。
まとめ
Vibe Codingで必要なのは言語化力であり、コードを書く力ではない
専門職は要件の言語化を日常業務でやっており、その力がそのままAI指示の精度になる
現場の解像度が高いほど、AIへの指示が具体的になり、出てくるものの質が上がる
「動いたかどうか」を評価できるのも、現場の人間だけ
プログラミングを学ばなくていい理由は、学ぶ必要がないからではなく、すでに必要な力を持っているからです。
次回（第16回）は、実際にAIへ最初の指示を出すときの具体的な手順を書きます。ワークシートで言語化した内容を、どの順番でAIに伝えれば詰まらないか——最初の一回を確実に動かすためのステップです。
本記事の内容は筆者個人の見解であり、所属する医療機関の公式見解を代表するものではありません。記事中の情報は執筆時点のものです。臨床判断・業務運用にあたっては、必ず最新の公式情報（添付文書・診療ガイドライン等）をご確認ください。本記事を参考にしたことによって生じた損害・不利益について、筆者は一切の責任を負いかねます。
