はじめに
私たちチームHOLONは、2025年11月から2026年2月にかけて、NEDO「AIの安全性確保に関する研究開発・検証等の推進事業」の東大松尾研チーム(以下、医療LLMプロジェクト)の一員として参加しました。「LLMの研究開発プロジェクトはどのように進むのか」は未だ知見が共有されていない領域です。このため、この記事では試行錯誤や意思決定の過程なども含めて共有します。
チームHOLONは2025年6月から10月まで「松尾研LLMコンペ2025」に参加した、「チームきつね」と「チームoNo.1」の有志が集まったものです。コンペではHumanity's Last Exam(HLE)という当時最も困難な学術ベンチマークの性能を事後学習によっていかに向上させるかを競いましたが、その経験を実際に日本の医療現場で役立つLLMの開発に活かそうということで、医療LLMプロジェクトに取り組むことにしました。
LLMの性能競争は今も続いており、各企業や組織がその時々で「最高のモデル」として出したものに追加で性能を上げるのは簡単なことではありません。しかし、「この目的のために、このリソースを使って、これをしたい」という目的をはっきりさせれば、その中で上げることは可能だと考えています。そして、その一端をお見せします。
また、本記事の目標として、「LLM開発に入っていくにはどうしたら良いか」を私たちの経験から述べていきたいというものがあります。一応知見的なものを書けましたので参考になれば幸いです。
本記事の範囲と限界
本記事は、主にNotionの週次議事録から活動を復元したものになります。このため、各項目の詳細に関してはチームメンバーの別記事などを参照してくだされば幸いです。
我々は何をしてきたか
Phase 0: このプロジェクトで私たちは何を目指すのか？
医療LLMプロジェクトは、コンペと同じ2025年6月に始まり既存の医療LLMプロジェクトの知見なども合わせて、既にさまざまな試行錯誤や成果をすでに出していました。最初のミーティングで全体の概要を確認しましたが、11月の段階でそれらを技術面、組織面でキャッチアップし、一体となって活動するのは期間を考えると合理的ではないと判断しました。
計算資源を有効活用するなら、一つの方向性に全てをつぎ込むのではなく、さまざまな可能性を模索する隙間を用意することも重要です。もちろん各人が計算資源を使いたいため、頑張って確保していく、もしくは計算資源を使わないでできることを模索していくことになりました。
このため、第2回定例で、事後学習特化の別働隊チームとして動き始めることになりました。例えば
- 継続事前学習モデル
- 学習用データ
- その他さまざまな医療関連データ
- 学習や評価用のコード
などはプロジェクト全体で共有し、事後学習やRAGなどで性能を上げていく形になりました。本体チームでも事後学習が重要だという認識があったため、良い協働になりそうだということで組織的な動きが始まりました。
初期の方向性の模索
チームの位置付けが決まったところで、我々の目標とそれぞれができることをリストアップしました。
目標: 専門医試験ベンチマーク(IgakuQA形式、非公開)の性能向上
- (継続)事前学習モデルのSFT、GRPO
- OCRなどのデータ整備
- 合成データ生成
- PII対策
- モデル評価
- 誤答分析
これらを分け、サブチームとして以下の目標を掲げました。
- 学習班: 既存の形にとらわれない学習方法の模索やマルチノードを用いた学習
- 評価班: 既存の評価を踏襲しながら足りないものを追加
- データ班: 新しい合成データ生成フローの模索、およびそのためのツール群の作成
Phase 1(2025年11-12月): 試行錯誤と足場固め
LLMコンペから受け継いだ基盤と、コードを用いた本チームとの連携
先ほど述べた通り、私たちはLLMコンペから合流したチームです。コンペと医療LLMプロジェクトでは計算資源などをほぼ同じ形で使うことができたため、コンペで開発し、使われた技術基盤をそのまま使うことができました。具体的には以下のようなものがありました。
- マルチノード学習の基本コード
- Vision-Language Modelを用いた資料のOCR
- 合成データ生成用のドメイン特化言語とその実行基盤
これらは必要に応じて進歩し、チーム全体の能力の下支えをし続けました。
また、評価コードに関しては全チームで共通化する必要があります。元々あった評価コードをベースモデルで動かすところから始め、そもそも評価用データの全てを用いていないというバグを発見するところまで行きました。モデル評価にはLLM-as-a-Judgeなどを用いるため時間がかかります。このため、誰でも動かせる知識を早期に共有することが重要でした。
また、評価は「何を目指し、どのように進めていくか」の基準にもなります。例えばニュースリリースなどで成果を発表する際には、ベンチマーク結果が数値指標になります。このため、「どのように評価をするか」「評価データは何か」などは早期に調べておく必要がありました。
試行錯誤: 何をすべきかを探索する
さて、私たちのチームはこれまで全く別分野のベンチマークで戦ってきており、医療分野に詳しいわけではありません。また、既存モデルの事後学習による性能向上が難しいことを思い知っていました。このため、2025年内は主に各自が試行錯誤をすることで、モデル性能向上の方法案を見つけ出していきました。
まず、事後学習のリソースには限界があります。それを突破するためには、より的を絞った学習で効果を出すことが必要です。特に、コンペでは少量データかつ少量の学習で、モデルの挙動が大きく変わることを観察していました。それがどれだけ実用的か、またMoEなどのアーキテクチャの特性に沿った効果的なチューニング手法などをどんどん実験していきました。これは、基本的なコードがすでにできていたから高速に試行錯誤できたといえます。
次に、OCRによる画像判読です。医療系のガイドラインなどのPDFデータがありましたが、RAGなどでうまく活用できていない状況でした。その大きな理由が、OCRの精度そのもののみならず、そもそも医学資料では文字だけではなく図によって伝えることが多いためです。これでは単に文字データだけを抽出しただけでは十分ではありません。このため、「事実知識をうまく注入する」以前に「そもそも事実知識をうまく抽出する」ことを模索していきました。
さらに、評価結果の分析も重要です。ベンチマーク問題の何を間違えているのか、間違いの特徴は何か、なぜ間違えているのか、知識が問題か、推論が問題か、などを評価結果から豊富に得ることができます。それを学習やRAGなどにフィードバックさせれば全体の方針をより良くできるでしょう。
これら全てに関わるのが合成データです。生成と言ってもいいかもしれません。難しい問題があるなら、一般に「より難しく」「より品質の高い」データが必要になります。しかし、ある問題を解けないモデルにそれを解けるようにする問題解答を生成することは困難です。また、それが学習に効くかどうかもわかりません。専門知識を用いた問題を作るなら、データパイプラインも試行錯誤が必要になります。
最後に、試行錯誤を続ける体制を維持することです。本番の学習やOCRなどが始まったら計算リソースがフル稼働します。その中で少ない計算リソースを用いて試行錯誤できる環境そのものを整えることが重要でした。
Phase 2(2026年1月): スケール
12月までで、以下の成果が出ていました。
- 学習基盤の成熟(速度、安定性面、観測可能性)
- OCR精度の成熟と実際の構造化
- 評価体制の成熟と有用な誤答分析の構築
つまり、「医療に特化したLLMの学習データを作り、実際に学習させ、有効かどうか、どう有効か計測する」ところまで整ったことになります。ここからは、各自が成果物をもとに協調して作業し、それをもとにモデルを開発するフェーズに入りました。
そのためにまず行ったことが、チームワーク体制の構築です。各自が何をしているかをリストアップし、「こんな感じで共同作業したらどうか」という叩き台を作りました。
一方で、問題も出てきました。まず計算リソースです。プロジェクト全体で、ちゃんと調整しないと全く足りなくなると言う問題が起きました。我々のモデル学習や評価についてちゃんと説明し、本線、HOLONや他チームで協調して動く体制が始まりました。
一方で、では我々はどのように強みを活かしていったらいいかという問題が残りました。そこでモデル学習だけでなく、RAGなどの高度化も目指し、「試行錯誤をどんどん本番に持っていく」ような路線が生まれました。
合成データ、学習、誤答分析などのループを通じて、学習方法やRAGの利点、欠点がだんだんとわかってきました。「性能向上」への道筋が見えてきました。
Phase 3(2026年2月): ファイナライズ
さて、残り1ヶ月となると、「どのモデルを最終成果物として公開するか」ということが課題となります。そこでは合意が必要です。数ある作ったモデルの中から良いものを選び、もしくは作り、正式なベンチマークを出す必要があります。また、公開に向けてドキュメントを整える必要もあります。このあたりは調整作業の側面が高いですが、プロジェクトとしての正式なモデルのリリースにこぎつけました。
我々はどのように進められたか
おそらく、個別の技術に関してはさまざまな記事が公開されていると思います。その中で私が取り扱いたいのは、「何が医療LLM開発を可能にしたか」という条件を考察して提示することです。
どのようなスキルが必要か
まず、スキルの話です。このプロジェクトではさまざまなバックグラウンドのメンバーが協調してモデルを作り上げました。このため、たとえば機械学習/深層学習など何か特別なスキルセットを中核に進んだわけではありません。これは特定のスキルが必要だ、必要ではないという切り口ではなく、結果的に相当程度のモデル改善ができたということです。実際に、医療LLMプロジェクトの前のコンペでは始めに「LLM講座」の一部をピックアップして毎日詰め込んだこともありました。
また、「多様なメンバーが集まったからこそ、良いモデルができた」とも単純に言えません。
実際のところ、LLMを評価するには言語的な理解が大いに関わっていることは感覚ではわかりますが、「ではどう言葉のレイヤーで分析して改善するか」という観点にはまだ答えがありません。
また、私が本業としてきたソフトウェア開発とLLM開発にはあらゆる点で違いがあることを実感しました。この2つの境界、プログラムによる決定論的レイヤーとモデルによる非決定論的レイヤーをどう協調させていくかという問題は、今はHarness Engineeringという分野で課題となっています。
その中で、チームメンバーが常に意識していたのが、「言語化」です。各自が何をしてきたか、どうあるべきかをちゃんと言葉にして説明して、残していく。それがあったからこそ、知見をコンペから継承し、試行錯誤をし、その試行錯誤を最終的なリリースにつなげられたと考えています。
あえて言えば、「黙れば止まる」くらいの印象でした。その観点では、どのような立場やフェーズに関わろうと、進捗が出ていなくても、何か言葉を絞り出すスキルみたいなものは必要だったように思います。特に今回のように「成果が見えにくい」状況では、見えるようにするということが非常に重要でした。
どのようなプロジェクト進行が必要か
次に、どのようにプロジェクトを進めていくか、協調していくかという面です。言語化したとしても、それを共有してプロジェクトの進行に進めていかないと意味がありません。コンペの際は「日次定例」などの今思えば無茶なことをした覚えがあります。1ヶ月の予選ではとにかく進めていかないとという感じでした。
今回の場合、毎週本線への報告ミーティングと、その前日の準備用の内部ミーティングがありました。この内部ミーティングでNotionの議事録に進捗を書き込み、発表していたことがプロジェクトを進める原動力の一つとなっていました。
とはいっても、正直今ログを見ても深い部分を完全に理解できるかというとそうではありません。ただ、今プロジェクトの歩みを再構成してみて感じたのが、「今週はこれをしようとして、こう進め、こうなった」ということが割と明確だったということです。
よくある進捗ミーティングでは、各自が「何をした」だけを報告して終わり、というある種儀式的なフェーズになりがちです。しかし、「何を目指してやっているか」ということを各自が言語化したことで、各自への関心を維持できたのではないかと思います。また、「これから何をすべきか」というフェーズの変化にも柔軟に対応できます。
情報やデータのマネジメント
ミーティングが原動力の一つだったとすると、もう一つが情報やデータのマネジメントです。とはいっても、「どのようなデータや成果物があるべき」ということが日々変わっていく以上、基本的にあるものを使うしかありません。それに適したマネジメント手法を選ぶことが適切でした。
議事録を見る限り、チームの各人のフォルダやHugging Face, GitHubのリポジトリを参照し、あるものを使っていく運用でした。これが結果的には効果的でした。なぜならば、それが最も迅速だからです。
合成データ、モデル開発、評価などあらゆるものが「今あるデータや成果物」ベースで進んでいきました。たとえばスプレッドシートによる体系的な管理などは、かなり後のフェーズになって導入されました。
まとめ: 言葉がいる場面といらない場面の分離
我々のチームでは「言語化」を重視しました。しかし、それはとにかく言葉を使おうというものではありませんでした。むしろ、言葉にすべき部分を徹底的に言葉にしてミーティングで集中的に共有し、それ以外では言葉を使わないで成果物で協調していく、という2つの場面をうまく分離できたのではと考えています。
結論: LLM開発入門
さて、ここまでの記事で私が目指したいことは「LLM開発に携われるようにするにはどうしたらいいか」を説明することです。1つのプロジェクトの例ですし、つたないですが試みてみます。なお、今回に関してはエージェントなどは対象とせず、事後学習にスコープします。
飛び込んでみる
たとえば松尾研LLM講座の基礎編などで、LLM開発の大枠はわかります。しかし、その各部分を見れば試行錯誤できるリソースはたくさんあります。学習、合成データのパイプライン、評価、さまざまな手法やコードは公開されています。その中で「難しいなあ」と感じる部分は確かにあります。しかし、今回のような巨大プロジェクトでなければ少数の予算でできることはたくさんあります。何かやってみるのが入り口だと思います。
言語化する
次に、自分がやったことを言語化することを心がけます。そうすれば知識や経験が定着しますし、人との共有や協働もできます。また、次に何をすればいいかもわかります。また、LLM開発の他の側面との関係も明確になります。
自分自身を試行錯誤の対象にする
上記の2つをまとめると、LLM開発において試行錯誤するだけではなく、自分自身がLLMをどう見てどう扱っていけばいいかという観点自体を試行錯誤していくことになります。要は「自分にとってLLMとは何か」を常に更新しメンテナンスしていくことです。それをベースに、日々変わっていくトレンドを追うこともできますし、新たな潮流を開拓することができるでしょう。
Acknowledgements
この成果は、NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の委託業務（JPNP25006）の結果得られたものです。