はじめに
今回、松尾研LLM開発コンペ2025にTeam Promptiaのリーダーとして参加しました。コンペでは、1チームあたり3ノード（1ノードあたり H100×8基）の大規模 GPU 環境を用い、数十億パラメータ規模のモデルの事後学習に取り組みました。1ヶ月という短い期間の中で成果を出すことはかなり難しく、リーダーとしての力不足を感じましたが、本コンペを通して様々な知見を得ることができました。
本記事ではTeam PromptiaのLLM開発の取り組みや成功・失敗談を紹介します。
開発テーマ
Team Promptia の開発テーマは 「革新的かつ効率的な推論能力の強化」 です。人海戦術のような方法ではなく、再現性のあるスマートな開発を目指してこのテーマを設定しました。ただし、約1か月という限られた期間を考えると「革新性」を前面に打ち出すのは最適ではなかったと感じています。
LLM 開発に限らず、開発全般は思い通りに進まないことの方が多いため、初期段階から斬新なアプローチに挑戦するよりも、まずはエラーの少ない基盤的な部分に着実に取り組み、その上で革新的な方向性へと発展させるのが望ましいと実感しました。
直面した課題・反省点
1. チーム間での情報共有
本コンペでは、1チーム約30人、しかも全員が初対面という構成でした。参加者ごとに活動時間やリソースの投入度合いも異なり、共通認識を揃えることが非常に難しかったです。
顔を合わせる機会は、週1回のオンライン全体MTGに加えて、モデル訓練・評価・データ管理・マネジメントといった部門ごとのMTGのみ。情報共有の主な手段は Slack と Notion でした。当初は「Slack で議論・質問 → 決定事項を Notion に整理」という方針でしたが、開発が進むにつれて Slack 上で方針が二転三転し、Notion への反映が遅れることが増えました。その結果、情報が散在し、一日でも見逃すと改めて情報を追い直さなければならない状況が生じました。
この問題によって「開発にコミットしたくても情報が整理されていないため動けない」「情報を追うのを諦めてしまう」というメンバーが出てしまったことは大きな反省点です。
2. 完全オンラインでの共同開発の難しさ
完全オンラインでの開発では、対面であれば1分で済むようなやり取りに Slack 上では10分以上かかってしまうことが多くありました。文字だけのコミュニケーションでは、相手の意図やニュアンスを正確に把握するのが難しく、自分の考えを100%伝えきれない場面も少なくありませんでした。
その結果、ちょっとした確認や意見交換に時間がかかり、意思決定が遅れることがしばしば発生しました。また、文面の解釈に差が生まれることで認識の食い違いが生じ、追加のやり取りが必要になり、さらに開発スピードが落ちるという悪循環を招いてしまいました。
特に大規模チームでの開発においては、このような小さなタイムロスが積み重なると、進捗全体に大きな影響を与えることを強く実感しました。
3. 人的リソースを生かしきれない
今回のコンペには、多様なバックグラウンドを持つメンバーが集まり、最後まで多くの人が積極的に開発に関わってくれました。しかしリーダーとして振り返ると、各メンバーの特徴を十分に把握し、それを最大限に生かしきれなかったと感じています。
メンバーの特徴は大きく分けて次の2タイプがありました。
- 経験や知見はあるが、参加に割ける時間が限られているメンバー
- 経験は浅いが、熱意があり多くの時間を投入できるメンバー
比率としては前者が約2割、後者が約8割でした。本来、チーム全体の推進力を左右するのは後者、つまり「豊富な時間を投入できる8割」のメンバーであり、彼らの成長や活躍の場をいかに設計するかが重要でした。ところが実際には、経験者に依存したタスク配分となってしまい、時間を割けるメンバーのポテンシャルを十分に引き出すことができませんでした。特に経験の浅いメンバーは「どの知識を身につけるべきか」「具体的に何をすればよいのか」が不明瞭で、結果として動けない場面が多いです。こうしたメンバーには、学習すべき内容や取り組むべきタスクを明確に示し、ステップごとに進められる仕組みを提供する必要があったと感じています。
短期的な成果を追求するのであれば「できる人が試行錯誤する」ことが効率的ですが、今回のような大規模チームではそうはいきません。むしろ「できる人ができない人をサポートする」体制を早期に構築し、全体の底上げを図ることが最終的な成果につながると強く実感しました。
またそれこそが、全員にとって成長の機会を提供することにもつながります。経験の浅いメンバーは学びながら確実に成果を積み重ねることができ、経験豊富なメンバーは自らの知識を言語化・体系化することで理解をさらに深められる。つまり「成果」と「成長」を両立できる開発体制の構築こそが、今後のチーム運営において最も重要なポイントだと感じています。
4. 技術選定の難しさ
近年、LLM の性能向上に関する研究論文は非常に多く発表されています。新しい最適化手法や学習アルゴリズム、データ構築の工夫など、そのアプローチは多岐にわたります。しかし、実際に開発現場で利用できる技術は驚くほど少なく、論文で報告されている成果をそのまま再現することすら簡単ではありません。今回の取り組みを通じて、「最新の研究成果」と「実際にプロジェクトで使える技術」の間には大きな隔たりがあることを強く実感しました。
今回のコンペで試みた技術は主に以下の2つです。
RLTについては一定の成功を収めることができましたが、VLDに関しては失敗に終わってしまいました。特に、アーキテクチャに関する技術は成果を出すために膨大な学習時間と実験サイクルを要するため、わずか1か月程度という短期間の開発スケジュールには適しませんでした。
さらに、論文に記載されている条件を忠実に再現すれば一見成果が出ることもありますが、前提条件を少し変えるだけで途端にうまくいかなくなるケースも多々ありました。こうした経験から、限られた期間で成果を求める場合には論文の新規性だけでなく、短期間での検証可能性・再現性・実運用における安定性といった観点から技術を選ぶ必要があると痛感しました。
この経験は、今後の研究や開発において「最新の論文を追う」こと以上に「現実的に成果を出すための技術選定」を重視すべきだという重要な学びにつながったと感じています。
得られた知見
-
対面での開発の有効性
研究開発はやはり対面で進めたほうが効率的であると感じました。特に複雑な議論や意思決定のスピードは、オンラインよりも対面のほうが圧倒的に早いです。 -
オンライン開発における情報共有の重要性
オンラインで開発を行う場合は、何よりも情報共有を徹底することが重要です。ただまとめるだけでなく、「受け取る側ができるだけ簡単に理解できる形」で整理する工夫が必要だと学びました。 -
メンバー全員の力を最大限に生かす
開発では関わる全てのメンバーを活用することが成果につながります。短期的な成果を優先しすぎると一部の人に負荷が集中してしまいますが、長期的に見れば全員が成長しながら関与する体制のほうが、成功の確率を高められると感じました。 -
リーダーの役割
チームリーダーは常に「次のステップ」を明確に示すことが大切です。完全な自由よりも、一定の制約や方向性があったほうが、メンバーは安心して創造性を発揮できます。 -
開発メンバーとして意識すべきこと
リーダーとしての経験を通じて、開発メンバーは以下を大切にすると良いと感じました。- 指示を待つのではなく、自分から指示を仰ぎ、その間にできることを考えて行動する
- 分からないことはすぐに質問しつつ、自分でも調べる
- 自分の考えは正誤に関わらず共有する
- レスポンスはできるだけ早く返す
-
スケジュール設計の教訓
スケジュールは「自分の想定の3倍」余裕を持たせるべきです。開発は予想以上にうまくいかないことが多いため、余裕を見込むことが成功の鍵になります。
本プロジェクトは、国立研究開発法人新エネルギー・産業技術総合開発機構（以下「NEDO」）の「日本語版医療特化型LLMの社会実装に向けた安全性検証・実証」における基盤モデルの開発プロジェクトの一環として行われます。