この記事で紹介されている OncoAgent は、ひとことで言うと「がん診療に特化した、かなり本気のAI意思決定支援システム」です。
普通のAIチャットは、「それっぽい答え」を返してしまうことがあります。医療、とくに腫瘍学（oncology）はその“それっぽさ”が一番危ない領域です。治療方針を間違えれば、冗談では済みません。
そこで OncoAgent は、
という、かなり堅実な思想で作られています。
個人的には、ここがいちばん面白いところだと思います。
最近のAI界隈は「どれだけ賢いか」に目が行きがちですが、医療では “どれだけ安全に使えるか” が主役 です。OncoAgent はそこを真正面から取りにいっている感じがあります。
OncoAgent は、LangGraph を使った stateful directed graph として実装されています。
難しく聞こえますが、要するに「処理の流れを、分岐や戻り道つきのワークフローとして管理している」ということです。
流れはだいたいこんなイメージです。
必要なら Fallback に逃がす構造もあります。
ここでのポイントは、AIが1発で答えるのではなく、途中で何度もチェックが入る こと。
医療AIとしては、むしろそれくらい慎重なほうが自然だと思います。
OncoAgent には Tier 1 と Tier 2 があります。
どちらを使うかは、Complexity Router が判定します。
これは、がんの種類、病期（stage）、遺伝子変異の数、既治療の有無などを点数化して、一定以上なら Tier 2 に回す仕組みです。
たとえば、記事では
のようなケースで高いスコアになり、Tier 2 に振り分けられたと紹介されています。
これはかなり実用的です。
全部を巨大モデルで処理すると重いし高コストですが、全部を小さいモデルで済ませると複雑症例に弱い。
なので、難しいものだけ重いモデルに回す のは、かなり筋がいい設計だと思います。
OncoAgent の中核は RAG（Retrieval-Augmented Generation） です。
これは、AIが勝手に記憶から喋るのではなく、外部の文書を検索して、その内容を踏まえて答える 方式です。
医療ではこれが重要です。
なぜなら、AIが「たぶんこうです」と言うのが一番怖いからです。
OncoAgent では、NCCN や ESMO などの 70以上の専門ガイドライン をベースにしていて、さらに4段階の retrieval pipeline を通します。
Recall
まず広く候補を拾う
Distance Gate
文書の関連性が低ければ弾く
つまり「それっぽいけど関係ない文書」を落とす
Re-Ranking
候補の中から本当に関連度が高いものを再評価する
Context Trimming
LLM の入力制限に合わせて長さを調整する
このあたりは、地味ですがとても大事です。
RAGは「検索して終わり」ではなく、検索の質がほぼ勝負 なので、段階を細かく分けて精度を上げるのは理にかなっています。
OncoAgent には Corrective RAG（CRAG） という仕組みもあります。
これは、検索した文書をそのまま使うのではなく、まず文書の関連性を採点する 方式です。
もし関連性が足りなければ、クエリを言い換えてもう一度検索します。
要するに、「検索ミスったら聞き直す」わけです。
記事ではこの grading の成功率が、ある段階で 0% から 100% に改善した と述べられています。
ここはインパクトが大きいですね。RAGの失敗原因って、実は「AIがバカ」より「検索がズレている」ことが多いので、そこを正面から潰しにいくのはかなり本質的だと思います。
もう一つ面白いのが Reflexion Safety Loop、つまり Critic Node です。
このノードは、AIの回答が外に出る前に3段階でチェックします。
ここでダメなら、フィードバックを元に再生成します。
しかもこの Critic は、LLM任せではなく deterministic code として動くと書かれています。
これ、かなり重要です。
AI自身に「自分の安全性を自分で審査させる」だけだと、どうしても抜け道がある。
だからルールベースの固定チェックを挟む。
私はこの設計、かなり好きです。医療ならなおさらです。
OncoAgent には HITL Gate があります。
HITL は Human-in-the-Loop の略で、人間が最後に関与する という意味です。
特に、
では、必ず臨床医の確認が入る設計になっています。
これも現実的です。
どれだけAIが進歩しても、診断や治療方針の最終責任は人間側にある からです。
AIに「全部おまかせ」は、医療ではまだ早い。というか、やってはいけないと思います。
この記事で特に好感が持てるのは、Fallback の存在です。
何か問題が起きたとき、無理に答えを捏造するのではなく、
"Información no concluyente en las guías provistas"
つまり「提供されたガイドラインでは結論できない」という安全な拒否を返します。
これは地味に見えて、超重要です。
AIは沈黙できないと危ない。でも医療では、わからないならわからないと言う のが一番の安全策です。
個人的には、これをちゃんと設計に組み込んでいるのはかなり評価したいところです。
OncoAgent は per-patient memory isolation を採用しています。
つまり、患者ごとの会話や状態を混ぜないようにしているわけです。
これは当たり前に見えて、実はかなり大事です。
別の患者の情報が混ざったら大事故ですからね。
ここでも thread_id を使って、患者単位で完全に分離しています。
医療AIは「賢さ」より「取り違えないこと」が何倍も重要です。
OncoAgent は、QLoRA を使って fine-tuning されています。
QLoRA は、巨大モデルを比較的軽いコストで追加学習するための手法です。
ざっくり言うと、「フルサイズで全部学習するより、賢く省エネで調整する」やり方です。
学習データは OncoCoT というコーパスで、266,854 samples が使われたとされています。
実ケースと合成ケースの両方を含んでいるのが特徴です。
さらに驚くのが、AMD Instinct MI300X と Unsloth を使った最適化です。
記事によれば、sequence packing によって全データの fine-tuning が 約50分 で終わり、APIベース生成と比べて 56倍のスループット改善 があったとのこと。
この数字が事実ならかなり強いです。
とはいえ、こういうベンチマークは条件次第で見え方も変わるので、私は「性能が出たこと自体はすごいが、再現条件は確認したい」とも思います。
それでも、クラウド依存なしで、オンプレでここまで回せる のは医療機関にとってかなり魅力的でしょう。
記事のメッセージを一言でいうと、**“ハードウェア主権” が医療では大事** ということです。
GPU を含めた推論・学習環境を自前で持てれば、
という利点があります。
特に医療現場では、AIの性能だけでなく「どこで動くか」がかなり重要です。
クラウドが便利なのは間違いないですが、病院では使いにくい場面も多い。
だからこそ、on-premises で動く open-source 医療AI には価値があると思います。
OncoAgent が面白いのは、単なる「医療向けLLM」のデモではなく、実運用の制約をかなり真面目に考えている 点です。
たとえば、
こうした要件は、研究デモだと後回しにされがちです。
でも実際の病院では、むしろそこが本番です。
個人的には、医療AIの成熟度って「モデルが何点取るか」より、安全・監査・導入可能性まで含めて設計できているか で決まると思っています。
OncoAgent はその方向にかなり踏み込んでいる印象です。
もちろん、いいことばかりではありません。
記事自体も Limitations を挙げていて、実運用にはまだ課題があることを示唆しています。
たとえば、
などは、どんな高度なAIでも避けて通れません。
なので、OncoAgent は「完成品」というより、医療AIのあるべき構成をかなり丁寧に示したプロトタイプ兼研究成果 と見るのが自然ではないでしょうか。
OncoAgent は、がん診療支援のために
を組み合わせた、かなり野心的なシステムです。
派手さだけで押すAIではなく、医療で本当に必要な慎重さを積み上げている のが好印象でした。
こういう方向性の研究は、実際に病院で使えるAIに近づくための大事な一歩だと思います。
