はじめに
私たち HOLON は、松尾研LLM開発コンペ2025 の決勝チームoNo.1 のメンバーで構成されたチームです。東京大学を通じたNEDOの医療LLM開発プロジェクト へ参加するために、結成されました。
この記事では、HOLONが「どのような立場で参加し、何に取り組んだのか」、その全体像を紹介します。そして、この後に続くメンバーの記事への入口にしたいと思います。
個々の技術や実験結果については、実際に手を動かしたメンバーがそれぞれの視点から紹介する予定です。まずはこの記事で、「どんな課題に、どんな取り組みがつながっていたのか」を知っていただければ嬉しいです。
- 松尾研LLM開発コンペ2025
- 医療LLM開発プロジェクト
1. HOLONは、どんなチームだったのか
HOLONの活動期間は、2025年11月から2026年3月までの5か月間です。
コンペが３位で終わり、「あんなことやこんなことがやれた」という達成感と「やりきれなかったな」という反省、悔しさとチームメイトへの感謝が入り混じった複雑な気持ちでいました。小野リーダー、ほーりーふぉっくすサブリーダー、チームメイトから多くの知見や技術を身につけ始めたところで、このお話が舞い込んできました。私は即「当然、参加しますっ！」と返事をしていたと記憶しています。
参加した時点で、プロジェクト本体ではすでにかなり多くの開発と検証が進んでいました。私たちはその状況を理解しながら、先生方や他チームからの依頼に対応し、自分たちでも課題を見つけ、改善の可能性を探していきました。
私の感覚では、本体や他チームと連携しながら動く 「別動隊」 のような位置付けです。
先生方や他チームから寄せられる課題と、メンバーから生まれるアイデアなどから「やりたいこと」が雪だるま式に膨らんでいく取り組みでした。
- 関連記事（@niryuu さん）
2. データ・学習・評価をつなぐ
初期の段階で、データ合成を基軸に開発を進めることや、学習・データ・評価のフィードバックループを速く回すことが、チームの方針として挙がっていました。
また、コンペの中である程度の手法が実装できてきたこともあり、早期に手を動かすことが可能になりました。
活動をざっくり整理すると、大きく次のようになります。
| 取り組み | 主に向き合った課題 |
|---|---|
| PDFのデータ化 | 既存手法では正確なOCRが困難だった医療関連PDFから、図表を含む情報を抽出、整形 |
| データ加工・合成 | さまざまなデータソースを元に学習データ生成、評価データの生成 |
| 学習手法の検証 | 新たな学習手法の実装と学習 |
| 評価・誤答分析 | 何ができて、何ができていないのかを把握 |
| RAG | 必要な外部知識を活用する方法の検証 |
| 利用場面を見据えた検討 | 個人情報の扱いや、利用を想定した機能・試作 |
これらは、それぞれが繋がり、関係性を持っています。
下記のようなイメージです。
すべての取り組みがこの順番で進んだわけではありませんし、このフローから外れた担当も発生しました。
しかし、中心となったのは「ある人の出力が、別の人の次の仕事の入力になる。」そんな繋がりを持った活動でした。
3. OCR・構造化・学習用データ合成
3.1 OCR ~読めなかった文書を、使えるデータにする~
私たちが参加する前から既存手法で医療関連PDFをOCRしたデータがありました。（参照情報（2025年9~10月ごろ））
多くのものは既存のOCR手法で読み取りができていましたが、一部の複雑な段組や表、図など 既存の方法では十分に読み取れなかったPDF もありました。
たとえば、二段組の本文、結合セルなどを持った複雑な表、フローチャート、図や写真などです。文字が読めても、読む順番や表の対応関係が崩れると、内容が正しく伝わりません。そこで、OCRが難しい医療関連PDFを対象に、読み取り方法の検討を進めました。
3.1.1 OCR
物体検出で本文や図表の位置を取り出し、読み順を推定する方法を試したり、LLMを使った方法の検討も進み、画像を分割して読み取り、その結果を統合するなどの検討が行われました。
最終的に、LLMのみを使った読み取り方法が採用され、OCRしたデータを提供するところまで進みました。
3.1.2 トピック分類
OCRした内容をトピック単位（医療分類）で整理しました。これはモデルやRAGにおいて弱い点を補う場合にトピック単位で素早く取り出せるための工夫です。
文字を取り出すだけではなく、後の学習や検索で使えるように、文書の内容と構造を保つことを目的とし、とあるトピック（医療分類）のモデル性能が低い場合、すぐに学習データとして選択できる状態を作りました。
このようにHOLONだけでなく、医療LLM開発チーム全体が次工程を考えながら取り組む文化があったと思います。
- 関連記事（@takashiyamamoto-o さん）
3.2 データ合成・構造化 ~さまざまなデータソースを、学習に使える形にする~
医療関連PDFから読み取ったテキストをもとに、学習や評価の目的に合わせて加工を行いました。
元のデータは、そのままモデルの学習に使えない場合も多々あります。特に図や画像はそこから何が読み取れるのかということが大切ですし、事後学習に適した形式への変換も必要です。
主な取り組みは、次のとおりです。
- 文書をもとにした事前学習、事後学習データへの加工
- 誤答分析を踏まえた、モデルが苦手とする分野のデータ作成
- 効果的な強化学習を行うための、学習データの難易度分析と分類
例えば、モデルの誤答から不足している知識を検討し、関連する資料から思考過程を含むQAを作成しました。また、生成した問題を難易度別に分類し、学習に使うデータを選ぶ作業も行いました。
また、強化学習系の学習では効率化のために難易度調査をした上でデータセットから絞り込むようなことも行われました。
作成したデータは学習担当へ共有し、学習・評価のループにつなげ、サイクルを回していきました。
4. 論文調査・学習コード実装 & 追加学習 ~大規模モデルの改善方法探索~
学習では、SFTやDPO、GRPO系の手法など、さまざまな方法が検討・実装されました。
モデルの どの部分を学習させる か、どのデータを使う か、どのように報酬を与える か。こうした条件を変えながら、実験が進められました。
例えば、MoEモデルのエキスパートやAttentionなど、選択したパラメータを対象に学習する取り組みがあります。また、大きなモデルの実験を実際に回すために、分散学習や推論サーバーとの連携など、実行環境の整備も行われました。
こうした取り組みから、学習コードと、条件を変えて学習した複数のモデルが作成されました。私が驚いたのは、論文で見つけた手法や、この取り組みの中で浮かんだ学習手法のアイデア、新モデルへの対応などが短期間で実験に進んでいくスピードです。実は学習班が短期間での実装に向けて戦略を持って挑んでいた結果でした。
当然、新しい方法を実装できたことと、モデルの性能が改善することは別です。スコアが上がったり下がったりと、データや報酬、学習条件の組み合わせによっても、結果は変わりました。
学習コードやモデルだけでなく、こうした実験の記録も残すことで、改善が見られた条件と、課題が残った条件の両方が、次の検討につながる材料となりました。
- 関連記事（@katsuki_ono さん）
5. モデル評価 ~評価結果から、次の改善を考える~
最初にお話しした通り、HOLONチームは「データ作成・学習・評価のフィードバックループ」を早く回すことを心がけていました。評価には12時間前後かかるため、モデル完成後、なるべく早く評価をスタートさせます。
- 評価対象に抜けがないか
- 出力や正解を正しく扱えているか
- どの診療科や問題で間違えているか
- その誤答は、知識の不足なのか
- 知識の使い方なのか
- 別の要因なのか
チームでは、評価スクリプトの改善、評価対象の確認、問題の分類、誤答の内容分析などが行われました。
評価から得た情報は、学習データやRAG用の資料を検討する材料にもなりました。スコアを比較するだけでなく、誤答の内容を調査、誤答分野の学習データを増やすなど、次に取り組む課題を具体化していきました。
同じ評価への関わりでも、実行、集計、出力の確認など、さまざまな作業があります。時には専門的な分析について、このプロジェクトに参加されていた医師の皆さんにも協力を頂きました。
さまざまな視点から、それぞれの力を合わせることの大切さを感じました。
6. 実利用に向けた検討の例
6.1 RAGによる回答の改善
外部の知識を検索して回答に使う、RAGの検討も行いました。
誤答分析を踏まえて医療関連PDFの中でもガイドラインを知識ベースにし、検索した情報を使って回答する実験です。RAGによって正答率が改善することを確認できました。
その一方で、必要な情報を検索できても、モデルが適切に読み取って回答できるとは限りません。検索する側と、検索結果を使うモデル側の両方に課題がありました。
6.2 個人情報（PII）の扱いと評価
実際の利用場面を考えると、個人情報の秘匿は非常に重要な要素になります。
個人情報（PII）を扱う時はローカルLLMに、その他の場合はフロンティアLLMにアクセスすることを想定したルーティングの検討や、この機能・性能を確認するベンチマークの整備にも取り組みました。関連するデータ作成や機能の実装とともに、個人情報を適切に扱えているかを評価するための準備を進めました。モデルの回答能力に加え、利用時に扱う情報にも目を向けた取り組みです。
また、利用を想定したモックアップの作成にも取り組みました。実際に使う場面を考えながら、必要な機能を検討していきました。
- 関連リポジトリ（@Holy_fox さん）
7. HOLONの成果
HOLONの活動からは、さまざまなソースコード、モデル、データセットが作られました。加えて、実験で得られた知見や、次に検証すべき課題も残りました。
| 残したもの | 内容 |
|---|---|
| ソースコード・実行環境 | データ生成、文書処理、学習、評価などを進めるための実装 |
| モデル | 学習方法や条件を変えて作成したモデル |
| データセット・知識ベース | さまざまなデータソースを加工した学習・評価用データ、QA、推論説明、検索用コーパスなど |
| 実験と分析の記録 | 条件ごとの結果、誤答分析、改善点や限界 |
ここでは、医療LLM開発プロジェクト本体での最終的な採用・活用状況を、すべて網羅したものではなく、HOLONチームで作成・検証したものを紹介しています。
具体的な成果物や実験条件、結果については、後続の記事で、それぞれの担当者の説明につなげていきたいと思います。
8. この後、HOLONメンバーによる技術記事が続きます
すでに一部の記事やリポジトリを貼り付けていますが、この後もHOLONメンバーの記事が続く予定です。それぞれのメンバーが取り組んだ工夫や試行錯誤について、私自身も楽しみにしています。
記事が公開されたら、このページにもリンクを追加していきます。
9. 私が心がけていたこと
最後に、私自身が「心がけていたこと」と、「医療LLM開発プロジェクトやHOLONチームで感じたこと」を少しだけ書きます。
私が担当していたのは、OCRの初期検討、QAデータセット作り、モデル評価です。
QAデータセット作りでは、松尾研LLM開発コンペ2025 でデータ作成したコードを改造、改良することで対応しました。
一方、モデル評価は１回の評価に12時間くらいかかるので、モデルができたら素早く評価を実行する必要があります。新しいモデルができたタイミングを捉え、なるべく早く評価を始めることを心がけていました。結果を待っているメンバーが、少しでも早く次の学習や実験を考えられるようにしたかったからです。
会社でも昼休みや退勤打刻直後、外出先、帰宅直後、朝起きたときなど、時間ができればパソコンを開き、学習の進捗、SlackやGPUの予約表、評価結果を確認していました。取りかかれるときに、すぐ評価を始められるようにする。それが、私の開発ループを早く回すための工夫でした。
こうした行動の元には、次に何が必要かをチームメンバー各自が考え、自分から動くチームの雰囲気があったと思います。メンバーそれぞれの作業が誰かの次の一手につながる。そんな流れの中にいると、自然に「次につなげることが最優先」と思うようになりました。プライベートのかなり多くの時間を割きましたが、苦しさや辛さは全く感じませんでした。
HOLONだけでなく、医療LLM開発チーム本体、他のチームにも非常に実力を持った方々が集まっており、正直にいうと「製造業の事務部門にいる私ごときでは劣等感しか感じないのではないか」とすら最初は思っていました。
確かに皆さんの凄さには圧倒されましたが、劣等感などは一切感じることなく、むしろ皆さんからの助け、皆さんの努力、凄さ、実力を感じられ、もっとみんなに追いつきたいという気持ちの方が圧倒的に大きいです。
全員がリモートで連携していたために、細かなコミュニケーションは難しいです。しかし、一人ひとりが必要なことを考えて動き、必要なところでは協力する。そんな「医療LLM開発チーム」に私には感じられました。
それぞれが得意なことを持ち寄って一緒に形を作っていく楽しさは、ある意味「新しい開発の型」なのかもしれません。自分もその流れの一部に加われたことは、本当に貴重な経験でした。ぜひこういう機会を得た方は何も考えず飛び込んでみるのも良いかもしれませんよ。
最後に
この記事は、HOLONの取り組みを知る入口として書きました。これから続くHOLONチームの記事を読む際の見取り図になれば嬉しいです。
一緒に取り組んだメンバーの皆さん、そして、課題や助言を寄せ、連携してくださった先生方・各チームの皆さん、ありがとうございました。繰り返しますが、本当に貴重な体験をさせていただき、心の底から感謝しています。
これから続くチームメンバーの記事も、ぜひ楽しみにしてください。
謝辞
この成果は、NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の委託業務（JPNP25006）の結果得られたものです。