ChatGPT GPT-5.2
医療とは、しばしば治癒という成果に報酬が支払われる営みであると受け止められがちだが、実際にはまったく異なる性質をもつ。人間の身体は本質的に不確実であり、個体差は大きく、治療の効果は医師の努力だけで決まるものではない。医療が社会制度として成立してきた背景には、治癒という成果の達成とは切り離された「不確実性そのものへの支払い」という構造が存在する。医師は最善を尽くしても患者が治らないことがある。にもかかわらず報酬を受け取ることが正当化されてきたのは、戦後日本が長く経済成長を続け、若い労働人口が豊富で、社会全体がその不確実性を分散させる余力をもっていたからである。そして生命を無限に尊重するという規範が、医療の“ベストエフォート”原理を支えてきた。
しかし現代日本は、急激な高齢化と社会全体の貧困化により、この構造そのものの維持に限界を迎えつつある。人口の約三割が高齢者となり、医療費の大半がその層に集中する現状では、もはや従来のように「治らない医療」に対して大量の社会的資源を投入する余裕は失われつつある。労働人口が減少すれば、保険料と税によって医療を支える基盤そのものが細る。かつては“当たり前”とみなされていた、治癒しない可能性を含めて医療を全面的に保障する制度的寛容さは、徐々に社会的許容の限界に近づいている。
このような状況下で顕在化しているのが、「成果」の重視である。医療の世界にアウトカム指標が導入され、「どれだけ治ったか」「QOLがどれだけ改善したか」といった結果に基づいて報酬を配分しようとする動きが強まっている。慢性疾患管理の包括払い制度や、介護分野における自立支援に対する加算などはその典型例だ。こうした制度改革は、医療を努力や誠実さだけで評価する従来の観念を後退させ、医療を「成果に応じて価値が決まる」サービス産業へと近づけていく。そこでは、医師が最善を尽くしたという事実だけでは評価されず、再入院率の低減や在院日数の短縮といった数値的成果が重視される。
高齢化が進む社会においては、さらに深刻な倫理的問いが立ち上がってくる。延命治療や終末期医療に対して、これまで当たり前に投じられてきた医療資源が、果たしてどこまで正当化できるのかという問題である。治らない患者に対して医療を提供し続けることは、生命倫理の観点では当然の営みであっても、社会全体の貧困化が進むと「際限ない延命に公的資源を投じることは適切なのか」という財政倫理上の疑問が生まれる。こうした議論はすでに社会の各所で可視化されており、医療の“無限の価値”モデルを覆しつつある。
その結果、医療の有限化が避けられない。すなわち、社会が医療に投入できる資源はもはや無限ではなく、費用対効果を厳密に検討しなければならない段階へ移行したということである。高額な医薬品や治療技術は、質調整生存年（QALY）などの指標を用いて導入の是非が判断され、終末期医療の一部は医療機関から地域ケアへと移されていく。医療の役割が縮小すれば、当然ながら“治らない医療”の一部は自費化し、結果として経済的余裕のある層だけが高度医療を利用できるという格差の固定化も起こりうる。
それでも、医療のベストエフォート原理が完全に消え去るわけではない。治癒が期待できる領域では成果主義が加速する一方、終末期医療や慢性的疾患のケアでは、むしろ「結果よりも過程を支える医療」という価値が再評価される可能性がある。人間にとって大切なのは必ずしも“治ること”だけではなく、“治らない時間をどう生きるか”という側面であり、その支援に誠実さを求める価値観はむしろ増大するかもしれない。
こうした流れを総合すると、未来の医療は「ベストエフォート」でも「成果主義」でもなく、その中間に位置する“最適エフォート（オプティマル・エフォート）”の形に収斂していくと考えられる。すなわち、社会が支えられる範囲で最善を尽くすという、現実的かつ倫理的な折衷点である。この制度では、医療の範囲は再定義され、治療可能領域は成果指標に基づいて効率化され、治らない領域はケアとして別の価値体系のもとに支えられる。医療の一部は縮小しつつも、医療の核心にある「不確実な生命を支える」という本質は失われない。
医療の未来を決めるのは、技術の進歩でも医師の技能でもなく、社会が不確実性とどのように向き合うかという姿勢である。不確実な生命をどれだけ共同体として支える意思があるのか。医療の価値を無限とみなすのか、それとも有限の資源の中で相対化するのか。この問いは単なる制度設計ではなく、社会哲学的な選択であり、まさに文明としての成熟度を問う問題である。今後の日本社会がどの方向へ進むかによって、医療の姿もまた大きく変わっていくことになるだろう。
Rule of Open-Source Programming #8:
Open-Source is not a panacea.
-- Shlomi Fish
-- "Rules of Open Source Programming"
Think of the history of data access strategies to come out of Microsoft. ODBC,
RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological
imperatives? The result of an incompetent design group that needs to reinvent
data access every goddamn year? (That's probably it, actually.) But the end
result is just cover fire. The competition has no choice but to spend all
their time porting and keeping up, time that they can't spend writing new
features. Look closely at the software landscape. The companies that do well
are the ones who rely least on big companies and don't have to spend all their
cycles catching up and reimplementing and fixing bugs that crop up only on
Windows XP. The companies who stumble are the ones who spend too much time
reading tea leaves to figure out the future direction of Microsoft. People get
worried about .NET and decide to rewrite their whole architecture for .NET
because they think they have to. Microsoft is shooting at you, and it's just
cover fire so that they can move forward and you can't, because this is how
the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are
you supporting it because your customers need it, or because someone is firing
at you and you feel like you have to respond? The sales teams of the big
companies understand cover fire. They go into their customers and say, "OK,
you don't have to buy from us. Buy from the best vendor. But make sure that
you get a product that supports (XML / SOAP / CDE / J2EE) because otherwise
you'll be Locked In The Trunk." Then when the little companies try to sell
into that account, all they hear is obedient CTOs parrotting "Do you have
J2EE?" And they have to waste all their time building in J2EE even if it
doesn't really make any sales, and gives them no opportunity to distinguish
themselves. It's a checkbox feature -- you do it because you need the checkbox
saying you have it, but nobody will use it or needs it. And it's cover fire.
-- Joel Spolsky
-- Fire and Motion ( http://www.joelonsoftware.com/articles/fog0000000339.html )