TL; DR (要約)
AI開発は、モデルを「自家発電」する時代から、巨大な「中央発電所」の知能を借りる時代へ。
基盤モデルという超高性能AIを、APIという「コンセント」経由で誰でも利用する方法のまとめです。
① 基盤モデルとAPI
(中央発電所とコンセント)
巨大IT企業が作った超汎用AI（基盤モデル）の能力を、APIという「コンセント」に繋ぐだけで、誰でも自分のプログラムから利用できます。
② マルチモーダルAI
(目と耳を持つAI)
画像とテキストを同時に理解。X線写真とカルテ情報を一緒に見て、より人間に近い総合的な判断を支援します。
③ 医療特化AI
(頼れる専門医)
汎用モデルを医療データで追加学習させ、「万能の天才」を「専門医（Med-PaLMなど）」に。精度と安全性を高めます。
④ 実践方法
(Pythonで呼び出す)
PythonとOpenAI等のライブラリを使えば、数行のコードで最先端AIを呼び出し、自分のアプリに組み込めます。
この章の学習目標と前提知識
はじめに：「訓練」から「対話」へ、AI活用の新時代
皆さん、こんにちは！いよいよ「拡張編」もクライマックス、AI開発の「今」を象徴する、最も実践的なテーマに迫ります。
前回の講義で、私たちはプロンプトという「魔法の呪文」を唱えることで、AIに追加学習をさせることなく、様々なタスクを解かせるZero-shot/Few-shot学習を学びました。まるで、AIと直接「対話」しているような、不思議な感覚でしたよね。
しかし、ここで当然、次のような疑問が湧いてきます。「なるほど、対話が重要なのは分かった。でも、その対話相手である、GPT-4やMedPaLMのような超賢いAIは、一体どこにいて、どうすれば私たちの研究室のPCから呼び出せるんだ？」と。
まさか、巨大なモデルを自力で構築・維持する必要があるのでしょうか？もしそうなら、結局は膨大な計算資源を持つ一部の組織だけの技術になってしまいます。
ご安心ください。その答えこそが、現代のAIエコシステムの根幹をなす、基盤モデル（Foundation Models）とAPI (Application Programming Interface) という考え方です。
これは、社会の電力インフラに例えると非常に分かりやすいです。かつて、各家庭や工場がそれぞれ「自家発電機（個別のAIモデル）」を持っていた時代から、巨大な「中央発電所（基盤モデル）」が作った強力な電気（AIの知能）を、各家庭が「コンセント（API）」にプラグを差し込むだけで、誰でも安全かつ安価に利用できる時代へと変わったのです。
今回は、まさにこの「コンセントにプラグを差し込む」ように、最先端のAIモデルを私たちのPythonコードから直接活用する方法を学びます。この技術を身につけることで、私たちはAIモデルの「開発者」であるだけでなく、世界最高峰のAIの能力を自在に活用する、賢い「利用者」にもなることができるのです。
この記事では、この新しいAI活用の世界について、基盤モデルの概要から、API利用の具体的なコード、そしてマルチモーダルAIや医療特化AIといった最前線まで、その全体像をダイジェスト形式で一緒に見ていきましょう。より詳細な実装方法や各APIの仕様については、今後の個別記事（30.1〜30.4）でじっくりと掘り下げていく予定です。
30.1 基盤モデル（Foundation Models）の概要とエコシステム 〜AI開発のパラダイムシフト〜
さて、私たちがAPIを通じて利用する、GPT-4やMedPaLMといった超高性能AI。これらは、専門用語で基盤モデル（Foundation Models）と呼ばれています。この「基盤」という言葉が、その性質を非常によく表しているんですよ。
基盤モデルとは、第25回で学んだ自己教師あり学習のような技術を使い、インターネット全体に匹敵するような、超大規模で多様なデータセットで事前学習された、巨大なAIモデルのことを指します(1)。
これは、特定の専門分野だけでなく、歴史、科学、芸術、日常会話といった、ありとあらゆる分野の膨大な本を読破して、非常に幅広い「一般教養」と「常識」を身につけた、万能の天才のような存在です。
基盤モデルの「２つの顔」：汎用性と適応性
この「万能の天才」は、一つのタスクに特化して作られているわけではありません。その代わり、言語を理解し、画像を認識し、論理的に推論するといった、非常に汎用的な能力を幅広く持っています。
そして、ここからが重要なのですが、この汎用的な能力を「基盤」として、ファインチューニング（PEFT/LoRAなど）や、より手軽なプロンプトエンジニアリングによって、私たちの目の前にある、様々な専門的な下流タスク（要約、分類、質問応答など）に、驚くほど迅速に適応させることができるのです。
エコシステムの変化：「自家発電」から「中央発電所」へ
基盤モデルの登場は、AI開発の「エコシステム」、つまり、開発者たちの関わり方そのものを大きく変えました。これは、電力の歴史になぞらえると、非常に分かりやすいと思います。
| 時代 | アナロジー | AI開発のアプローチ |
|---|---|---|
| 〜2020年頃 | 「自家発電」の時代 | タスクごとに個別のモデルをゼロから構築 |
| 現在 | 「中央発電所」の時代 | 巨大な基盤モデルをAPI経由で利用・適応 |
かつては、研究者や開発者が、それぞれの課題（画像分類、文章生成など）ごとに、最適なモデルをゼロから設計し、データを集めて学習させる「自家発電」が主流でした。しかし今は、巨大IT企業が莫大なコストをかけて構築した「中央発電所」（基盤モデル）が生み出す強力な知能を、私たちはAPIという「送電網」を通じて、手軽に利用できる時代になったのです。私たちの仕事は、「発電機を作ること」から「送られてきた電気（AIの能力）を、どう賢く使うか」へとシフトしているんですね。
代表的な基盤モデル
現在、世界中で様々な基盤モデルが開発され、まさに群雄割拠の時代と言えるでしょう。代表的なものには、以下のようなものがあります。
- OpenAI:
GPT-3,GPT-4,GPT-4V（視覚）,Sora（動画生成）など - Google:
PaLM 2,Geminifamily, そして医療に特化したMedPaLM 2など - その他:
Claudeseries (Anthropic),Llamaseries (Meta) など
30.2 APIを通じたモデル利用と簡単なアプリケーションへの組み込み 〜AIという「中央発電所」から電気を引いてくる〜
さて、「中央発電所」（基盤モデル）の存在は分かりましたが、どうやって私たちの研究室まで「電気（AIの能力）」を引いてくれば良いのでしょうか。そのための「コンセント」の役割を果たすのが、API (Application Programming Interface) です。
APIは、よくレストランの「メニュー」に例えられます。私たちは、厨房でシェフがどんな調理をしているか（AIモデルの内部構造）を一切知る必要はありません。ただ、メニュー（APIドキュメント）を見て、食べたい料理（使いたい機能、例：文章生成）を選び、必要な情報（プロンプト）をウェイター（APIリクエスト）に伝えれば、出来上がった料理（AIの生成結果）が運ばれてくる。この一連の「注文のルール」こそがAPIなのです。
Pythonコード例：OpenAIのAPIを使って医療的な質問応答を行う
言葉だけではイメージが湧きにくいかもしれませんね。ここでは、数あるAPIの中でも最も有名なものの一つである、OpenAI社のAPIを使い、GPTモデルに簡単な医療関連の質問をするコードの基本形を見ていきましょう。これを通じて、API利用の具体的な流れを掴んでください。
【実行前の準備】
- OpenAIのウェブサイトでアカウント登録し、APIキーを取得します。（有料の場合があります）
- お使いのコンピュータのターミナルやコマンドプロンプトで、
pip install openaiを実行し、ライブラリをインストールします。
graph TD
A["開始"] --> B["1. APIクライアントを初期化
(APIキーを安全に読み込み、通信を準備)"];
B --> C["2. 送信メッセージを作成
(AIの役割とユーザーの質問を定義)"];
C --> D["3. APIを呼び出し応答を取得
(作成したメッセージをモデルに送信)"];
D --> E["4. 回答を抽出して表示
(応答データからテキスト部分を取り出す)"];
E --> F["終了"];
# --- ステップ1. 必要なライブラリをインポート ---
from openai import OpenAI # OpenAIのライブラリをインポート
import os # コンピュータの環境変数を読み込むためのライブラリ
# --- ステップ2. APIキーの設定とクライアントの初期化 ---
# APIキーは、私たちがOpenAIのサービスを利用する正規な契約者であることを証明するための、あなた専用の「秘密の鍵」です。
# 【最重要】このキーは、パスワードと同じくらい大切に扱ってください。
# もしこのキーが外部に漏洩すると、第三者に不正利用され、高額な料金が請求される可能性があります。
# そのため、下の行のようにコードに直接書き込むのは非常に危険です。
# client = OpenAI(api_key="sk-...") # この書き方は絶対に避けるべき！
# 最も安全で推奨される方法は、「環境変数」としてコンピュータにキーを記憶させておくことです。
# os.getenv("OPENAI_API_KEY") は、「コンピュータ君、"OPENAI_API_KEY"という名前で覚えておいた秘密の鍵を教えて」
# と尋ねる命令です。これにより、コード上には秘密の情報が一切現れなくなります。
# （環境変数の設定方法は、お使いのOS（Windows/Mac/Linux）によって異なりますので、別途調べてみてください）
client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))
# この`client`オブジェクトが、OpenAIのサーバーと通信するための「専用線」の役割を果たします。
# --- ステップ3. モデルに送信するメッセージを作成 ---
# GPT-4のようなチャットモデルには、「役割(role)」と「内容(content)」のペアを持つ辞書のリスト形式で指示を与えます。
messages_for_api = [
{
"role": "system", # 「システム」の役割は、AIのペルソナや、会話全体の大前提となる指示を与える部分です。
"content": "あなたは、医療知識を持つ優秀なAIアシスタントです。専門用語を避け、一般の人にも分かりやすく説明してください。"
},
{
"role": "user", # 「ユーザー」の役割は、私たちがAIに尋ねたい具体的な質問や指示です。
"content": "高血圧の患者さんが日常生活で気をつけるべき最も重要な点を3つ、簡潔に教えてください。"
}
]
# --- ステップ4. APIを呼び出して、モデルからの応答を取得 ---
try:
# `client.chat.completions.create` を使ってAPIを呼び出します（最新のライブラリ形式）。
response = client.chat.completions.create(
model="gpt-4", # 使用するモデルを指定します。
messages=messages_for_api, # 作成したメッセージリストを渡します。
temperature=0.7, # 出力の「創造性」。0に近いほど決まった答えに、高いほど多様な答えになります。
max_tokens=300 # 生成する文章の最大長（トークン数）。
)
# --- ステップ5. 応答から回答テキストを抽出して表示 ---
# 応答は複雑なオブジェクトで返ってくるため、回答部分だけを抽出します。
ai_response_text = response.choices[0].message.content.strip()
print("--- AIからの回答 ---")
print(ai_response_text)
except Exception as e:
# APIキーが設定されていない場合や、通信エラーが起きた場合に、エラーメッセージを表示します。
print(f"API呼び出し中にエラーが発生しました: {e}")
# === ここから下が上記のprint文による実際の出力の例 ===
# --- AIからの回答 ---
# 高血圧の患者さんが日常生活で気をつけるべき重要な点は以下の3つです。
#
# 1. **減塩**: 食事に含まれる塩分（ナトリウム）を減らすことが最も重要です。塩分は血圧を上げる大きな原因となりますので、加工食品や外食を控え、薄味を心がけましょう。
# 2. **適度な運動**: ウォーキングなどの有酸素運動を定期的に行うことで、血圧を下げる効果が期待できます。週に150分程度を目安に、無理のない範囲で続けましょう。
# 3. **適切な体重の維持**: 肥満は高血圧のリスクを高めます。バランスの取れた食事と運動で、ご自身の適正体重を維持することが、血圧のコントロールに繋がります。
30.3 マルチモーダルAI — 画像とテキストを「統合」して理解する新次元
APIを通じて、私たちはAIと「言葉」で対話できるようになりました。しかし、実際の臨床現場での私たちの思考は、言葉だけで完結することは稀ですよね。
私たちは、患者さんの言葉を聞きながら、同時に顔色を伺い、聴診器を当て、そしてX線写真や心電図といった「画像」や「波形」のデータを統合して、初めて総合的な判断を下します。この、テキスト、画像、音声など、複数の異なる種類の情報（モダリティ）を同時に理解し、統合して処理できるAIこそが、マルチモーダルAIです。
これは、AIが「耳」と「目」を同時に手に入れ、より人間に近い、統合的な理解能力を獲得した、と言っても過言ではないでしょう。
GPT-4V (Vision) とは？
その代表格であり、AIの可能性を大きく広げたのが、OpenAIのGPT-4V (Vision)です。このモデルは、画像とテキストを一緒に入力として与え、それらに関連する複雑な問いに答えることができます。
これは、私たちが経験豊富なコンサルタントに、「この患者さんのレントゲン写真（画像）と、これまでの経過サマリー（テキスト）を一緒に見て、あなたの専門的な意見を聞かせてほしい」とお願いするのと、全く同じです。AIは、画像とテキストの両方を「見て」「読んで」、その上で総合的な回答を生成してくれるのです。
マルチモーダルAIへの入力例
医療分野における無限の可能性
この能力が、医療分野にどれほど大きなインパクトを与えるか、想像してみてください。
- 診断支援の高度化
X線写真と共に「この患者は45歳男性、2週間の咳と微熱あり」というテキスト情報を与えることで、AIは単に画像パターンを認識するだけでなく、臨床文脈を考慮した、より精度の高い鑑別診断リストを提示できるかもしれません。 - 研究の加速
病理画像と、それに対応する遺伝子発現データを同時に解析させ、「この特異な細胞形態は、どの遺伝子の変異と関連が深いか？」といった、複数のモダリティにまたがる、新しい科学的発見を促す可能性があります。 - 患者向け説明の自動生成
患者さんのMRI画像を見せながら、「この画像のこの部分が何を意味するのか、専門用語を使わずに小学生にも分かるように説明して」といった、インフォームド・コンセントを支援するツールも考えられます。
マルチモーダルAIは、これまでサイロ化されていた様々な医療データを統合し、より全体的で、より人間に近いレベルでの理解を可能にする、まさにゲームチェンジャーです。この技術の発展が、未来の医療をどう変えていくのか、非常に楽しみですね。
30.4 医療特化モデル（MedPaLMなど）の動向と可能性 〜「万能の天才」から「頼れる専門医」へ〜
GPT-4のような汎用的な基盤モデルは、まさに「万能の天才」です。どんな質問にも驚くほど的確に答えてくれます。しかし、私たちが日常的に向き合う医療の世界は、非常に特殊で、高度な専門性が要求される領域ですよね。
例えば、私たちが日常的に使う略語（例: CABG, DM, Fx.）や、一見同じに見えるが文脈によって全く意味が変わる用語、そして何よりも、膨大な知識に基づいた複雑な論理的思考。汎用モデルは、こうした医療特有のニュアンスを完全には捉えきれず、時に致命的な誤りを犯す可能性があります。
そこで、この「万能の天才」を、私たちの現場で本当に頼れる「専門医」へと育てるために、医療分野のデータで追加学習・ファインチューニングさせた、医療特化モデルの開発が世界中で活発に進められています。これは、「一般教養を修めた天才」に、医学部のカリキュラムと臨床研修を受けさせ、特定の診療科の専門医として育成するプロセスに他なりません。
代表例：Med-PaLM / Med-PaLM 2
その代表格が、Googleによって開発されたMed-PaLM、そしてその後継であるMed-PaLM 2です(2,3)。これらのモデルは、Googleの強力な基盤モデルをベースに、医療分野の膨大な質問応答データセットや医学論文などで追加学習されています。
その実力は驚くべきもので、特にMed-PaLM 2は、米国の医師国家試験（USMLE）形式の質問に対して、85%を超える正答率を達成し、専門医に匹敵するレベルに到達したと報告されています。これは、AIが単なる情報検索ツールではなく、高度な医学的推論能力を獲得しつつあることを示す、重要なマイルストーンと言えるでしょう。
今後の展望：大きな可能性と乗り越えるべき課題
これらの医療特化モデルは、私たちの未来を大きく変える可能性を秘めています。しかし、その大きな可能性と同時に、私たちはAIを医療に応用する上での、重大な課題とリスクにも目を向けなければなりません。これは、AI開発者であると同時に、人々の健康と生命を預かる私たち医療従事者にとって、最も重要な視点です。
| 期待される応用（可能性） | 慎重であるべき理由（課題とリスク） |
|---|---|
| 臨床意思決定支援: 複雑な症例に対する鑑別診断リストや治療法の提案。 研究・教育の加速: 膨大な論文の要約、研究計画の草案作成、医学生向けの対話型シミュレーション。 業務効率の改善: 診察サマリーの自動作成など、医師や医療スタッフを事務作業から解放。 | 情報の正確性: 時にもっともらしい「嘘」を生成するハルシネーションの問題。 知識の鮮度: 日々更新される医療知識にどう追従させるか。 公平性とバイアス: 学習データに潜むバイアスが、不公平な判断に繋がる危険性。 安全性と規制: 医療機器としての安全性・有効性の証明と、各国の規制当局（PMDA, FDAなど）の承認。 |
まとめと次のステップへ
今回は、AI開発の最前線である、基盤モデルとそのAPIを通じた活用法を学びました。
- 基盤モデル: 巨大データで事前学習された、汎用的な大規模AI。
- API: 巨大モデルの能力を、自分のプログラムから「借りてくる」ための窓口。
- マルチモーダルAI: 画像とテキストなど、複数の情報を統合して理解するAI。
- 医療特化モデル: 医療分野のデータで追加学習され、高い専門性を持つAI。
AI開発のパラダイムは、モデルを「作る」ことから、高性能な基盤モデルを「いかに賢く使うか」へとシフトしつつあります。
しかし、GPT-4VやMedPaLMのような強力なモデルは、医療に計り知れない恩恵をもたらす可能性を秘めていると同時に、大きな責任を伴います。もしAIが間違った診断を下したら？もしAIの回答にバイアスがあったら？
次回の第31回では、このコースの（当面の）締めくくりとして、AIを社会実装する上で不可欠な、AI倫理、バイアス、そして説明可能性（XAI）という、非常に重要なテーマについて考えていきます。
参考文献
- Bommasani R, Hudson DW, Adeli E, et al. On the opportunities and risks of foundation models. arXiv preprint arXiv:2108.07258. 2021.
- Singhal K, Azizi S, Tu T, Mahdavi SS, Wei J, Chung HW, et al. Large language models encode clinical knowledge. Nature. 2023;620(7972):172-180.
- Singhal K, Tu T, Gottweis J, et al. Towards expert-level medical question answering with large language models. arXiv preprint arXiv:2305.09617. 2023.
ご利用規約（免責事項）
当サイト（以下「本サイト」といいます）をご利用になる前に、本ご利用規約（以下「本規約」といいます）をよくお読みください。本サイトを利用された時点で、利用者は本規約の全ての条項に同意したものとみなします。
第1条（目的と情報の性質）
- 本サイトは、医療分野におけるAI技術に関する一般的な情報提供および技術的な学習機会の提供を唯一の目的とします。
- 本サイトで提供されるすべてのコンテンツ（文章、図表、コード、データセットの紹介等を含みますが、これらに限定されません）は、一般的な学習参考用であり、いかなる場合も医学的な助言、診断、治療、またはこれらに準ずる行為（以下「医行為等」といいます）を提供するものではありません。
- 本サイトのコンテンツは、特定の製品、技術、または治療法の有効性、安全性を保証、推奨、または広告・販売促進するものではありません。紹介する技術には研究開発段階のものが含まれており、その臨床応用には、さらなる研究と国内外の規制当局による正式な承認が別途必要です。
- 本サイトは、情報提供を目的としたものであり、特定の治療法を推奨するものではありません。健康に関するご懸念やご相談は、必ず専門の医療機関にご相談ください。
第2条（法令等の遵守）
利用者は、本サイトの利用にあたり、医師法、医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律（薬機法）、個人情報の保護に関する法律、医療法、医療広告ガイドライン、その他関連する国内外の全ての法令、条例、規則、および各省庁・学会等が定める最新のガイドライン等を、自らの責任において遵守するものとします。これらの適用判断についても、利用者が自ら関係各所に確認するものとし、本サイトは一切の責任を負いません。
第3条（医療行為における責任）
- 本サイトで紹介するAI技術・手法は、あくまで研究段階の技術的解説であり、実際の臨床現場での診断・治療を代替、補助、または推奨するものでは一切ありません。
- 医行為等に関する最終的な判断、決定、およびそれに伴う一切の責任は、必ず法律上その資格を認められた医療専門家（医師、歯科医師等）が負うものとします。AIによる出力を、資格を有する専門家による独立した検証および判断を経ずに利用することを固く禁じます。
- 本サイトの情報に基づくいかなる行為によって利用者または第三者に損害が生じた場合も、本サイト運営者は一切の責任を負いません。実際の臨床判断に際しては、必ず担当の医療専門家にご相談ください。本サイトの利用によって、利用者と本サイト運営者の間に、医師と患者の関係、またはその他いかなる専門的な関係も成立するものではありません。
第4条（情報の正確性・完全性・有用性）
- 本サイトは、掲載する情報（数値、事例、ソースコード、ライブラリのバージョン等）の正確性、完全性、網羅性、有用性、特定目的への適合性、その他一切の事項について、何ら保証するものではありません。
- 掲載情報は執筆時点のものであり、予告なく変更または削除されることがあります。また、技術の進展、ライブラリの更新等により、情報は古くなる可能性があります。利用者は、必ず自身で公式ドキュメント等の最新情報を確認し、自らの責任で情報を利用するものとします。
第5条（AI生成コンテンツに関する注意事項）
本サイトのコンテンツには、AIによる提案を基に作成された部分が含まれる場合がありますが、公開にあたっては人間による監修・編集を経ています。利用者が生成AI等を用いる際は、ハルシネーション（事実に基づかない情報の生成）やバイアスのリスクが内在することを十分に理解し、その出力を鵜呑みにすることなく、必ず専門家による検証を行うものとします。
第6条（知的財産権）
- 本サイトを構成するすべてのコンテンツに関する著作権、商標権、その他一切の知的財産権は、本サイト運営者または正当な権利を有する第三者に帰属します。
- 本サイトのコンテンツを引用、転載、複製、改変、その他の二次利用を行う場合は、著作権法その他関連法規を遵守し、必ず出典を明記するとともに、権利者の許諾を得るなど、適切な手続きを自らの責任で行うものとします。
第7条（プライバシー・倫理）
本サイトで紹介または言及されるデータセット等を利用する場合、利用者は当該データセットに付随するライセンス条件および研究倫理指針を厳格に遵守し、個人情報の匿名化や同意取得の確認など、適用される法規制に基づき必要とされるすべての措置を、自らの責任において講じるものとします。
第8条（利用環境）
本サイトで紹介するソースコードやライブラリは、執筆時点で特定のバージョンおよび実行環境（OS、ハードウェア、依存パッケージ等）を前提としています。利用者の環境における動作を保証するものではなく、互換性の問題等に起因するいかなる不利益・損害についても、本サイト運営者は責任を負いません。
第9条（免責事項）
- 本サイト運営者は、利用者が本サイトを利用したこと、または利用できなかったことによって生じる一切の損害（直接損害、間接損害、付随的損害、特別損害、懲罰的損害、逸失利益、データの消失、プログラムの毀損等を含みますが、これらに限定されません）について、その原因の如何を問わず、一切の法的責任を負わないものとします。
- 本サイトの利用は、学習および研究目的に限定されるものとし、それ以外の目的での利用はご遠慮ください。
- 本サイトの利用に関連して、利用者と第三者との間で紛争が生じた場合、利用者は自らの費用と責任においてこれを解決するものとし、本サイト運営者に一切の迷惑または損害を与えないものとします。
- 本サイト運営者は、いつでも予告なく本サイトの運営を中断、中止、または内容を変更できるものとし、これによって利用者に生じたいかなる損害についても責任を負いません。
第10条（規約の変更）
本サイト運営者は、必要と判断した場合、利用者の承諾を得ることなく、いつでも本規約を変更することができます。変更後の規約は、本サイト上に掲載された時点で効力を生じるものとし、利用者は変更後の規約に拘束されるものとします。
第11条（準拠法および合意管轄）
本規約の解釈にあたっては、日本法を準拠法とします。本サイトの利用および本規約に関連して生じる一切の紛争については、東京地方裁判所を第一審の専属的合意管轄裁判所とします。
For J³, may joy follow you.
