松尾研LLMコンペ2025に参加しました。LLMのチーム開発の過程で生じた、情報共有に関する出来事と、それに対する所感をまとめました。このLLM開発コンペにおいて特徴的なことは、「約一ヶ月間の短い時間の中で汎用LLMを作る」という時間的制約の厳しさにある、と思われます。
私が参加したチームでは、オペレーション(環境構築、再現実験、学習テスト)、ベースモデル選定(候補、ベンチマーク)、PoC研究(改善案、実証試験、研究)、実働サポート(データ作成、調査、作業)で分かれて、並列実行する予定になっていました。ふたを開けてみれば、特定の人が先行して環境構築のノウハウを伝え、それに続いて「モデル班」「データセット班」に分かれての活動が行われるようになりました。
サーバー利用開始後の約一ヶ月間、モデル班とデータ班の連携は弱く、知見は散逸しやすい状況でした。本チームでは「誰が何をするのか」決めるにあたって、挙手制がベースに採用されていました。挙手制は多くの局面で担い手を生みにくく、明確なアサインがなければ責任者が定まりにくい空気もありました。非同期・テキスト運用は発信の萎縮を生み、内輪のDMや非公式同期に比重が寄る場面もありました。LLM開発コンペ第一ラウンドの開発期間の後半では、24時間開催体制のZoom「作業部屋」が情報のハブとなり、学生の戦力化に寄与した一方で、意思決定の可視性に課題が残りました。全体を通じて、仕組み・語り口・緩衝役の重なりが場の安定に効いていた——そのような印象です。
前提：本コンペの要旨
松尾研LLMコンペ 2025は、汎用データを活用した高品質な LLM の開発を目的の一つにしています。ベンチマークに用いられたのはHumanity’s Last Exam（HLE）。また、現場展開を見据え、AI Safetyを含めた評価（Do-Not-Answer を含む自己抑制の適切な発動）も求められています。参加単位は個人で、LLM開発にあたって情報の透明性・公開性が原則とされています。
本チームで起きた情報共有の問題
サーバーにログイン可能となってから約一ヶ月もの間、情報共有は落ち着かず、特にモデル班とデータ班の接続に問題が多発しました。Slackは流れが速く、Notionは書式や運用にばらつきがあり、Git／Hugging Face／Weights & Biases（W&B）を用いての成果物管理のルールが固まったのは第一ラウンド終了の7〜10日前でした。
その背景には複数の要因が重なっていたと感じます。挙手制は情報管理に限らず多くの作業・局面で担い手が現れにくく、明確なアサインのない限り、責任者不在になりやすい空気がありました。モデル班とデータ班の架け橋となる情報管理役は不在で、チーム全体ではNotion管理を一部の学生たちとチームリーダーが担い、公式ミーティング関連とGitHubの情報管理はPMP保有者が担っていました。複数ツールの同時運用は「どこに書き、どこを見るか」を常に意識する必要があり、記憶と注意の消耗も、書き込み作業そのものの負荷も、いずれも大きかった印象です。さらに、テキストによる非同期では発信側が誤読を恐れて筆が止まり、透明性・公開性を基調にすべき場でも内輪のDMや非公式同期が優先される場面もありました。
24時間 Zoom「作業部屋」の成立と内包する課題
学生の呼びかけによる「もくもく会」を起点に、24時間稼働の Zoom「作業部屋」が情報のハブとなりました。フルスタックに動くリーダーの存在も相まって、学生の戦力化が進み、情報共有の難しさは一部やわらぎました。
一方で、非公式の場には性質上の課題もありました。重要な意思決定に相当する合意までが「作業部屋」で進み、社会人メンバーには「いつどこで決まったのか」を把握しづらい局面がありました。結果として、足並みが乱れた時期もあった——私にはそのように映りました。
意思決定の揺れ：「回す派」と「秩序派」
時間が限られる中でまず現場を回すことを優先する「回す派」と、会議設計や秩序の整備を重視する「秩序派（PMP 保有）」の間で、意思決定のスタイルに揺れがありました。秩序派は学生・若手の「何をすべきか分からない」という声を受け止めようとしていましたが、着手が遅れた面もありました。皮肉にも、「秩序派」が批判していた「回す派」のほうが、疲弊しがちな学生への対処に長けていた場面もあった、と感じました。
属人的なスキル——勢いで突破する人と慎重に設計する人を見極め、適切にタスクを渡す力——が、混乱をいくぶん和らげていたという印象です。その意味で、秩序をつくる側自体を複数人体制にしておくほうがよかったのかもしれません。
具体的な場面（所感を含む）
24時間体制で走る学生が、主力社会人のジョブをキャンセルし、温度差の残る場面がありました。さらに、「GPU資源の厳密運用」への切り替えは非公開の場で決まり、リーダーがSlackに告知したものの、反応は 5 名にとどまり（当時のチャンネル参加者数は約45人）、情報の到達範囲に偏りがありそうでした。錯綜や誤解が重なり、学生は混乱し、社会人のあいだに心理的摩擦が生じました——私にはそのように映りました。
「作業部屋」以外の場面——緩衝役の存在
別チームとの接点があり心理学にも明るいベテランが、緩衝役として働いていました。「回す」と「秩序」のあいだに立ち、学生が萎縮しがちな場でも受け止め役を担っていた印象です。Zoom MTGではアバターを活用するなど、心理的安全性を保つ小さな工夫が場の呼吸を整えていた——そんな場面がいくつもありました。
「トラブルが起きると人の能力は200%になる」
「チームが何も出せずに終わるのは最悪」
混沌の只中で、この緩衝役が最低限の秩序と希望をつなぎ止めていた——私はそう感じました。情報共有は、結局、人とその態度の積み重ねで形作られるのではないでしょうか。ツールは場を整える手助けで、最後に動くのは人の側の温度なのかもしれません。
結語
情報共有は「仕組み×語り口×緩衝役」の重なりで落ち着くことが多いのかもしれません。仕組みをある程度固定し、語り口を整え、緩衝役を複数人で回す——そうした積み重ねは、崩れをいくぶん和らげてくれるのかもしれません。時間が限られるときほど、基礎を雑にしないほうが結果的に楽——そんな場面がありました。
付記
Notionが公式ハブでした。Zoomの決定事項を同日に反映する役割はPMP 保有者やチームリーダーに委ねられていました。Notionでの同期ルールは明文化されておらず、議事録は複数ページに分散し、私自身も追い切れませんでした。GitHub管理は PMP 保有者、チームごとのアカウント配布はリーダーという分担のはずでしたが、両者の連携が十分でなかった可能性、あるいは運営による配布の遅延もあり得た——そのような印象です。W&B（Weights & Biases）や Hugging Faceについては、ある学生が一元化を試み、回るようになりました。
「回す派」と「秩序派」の対立が表面化した日に、緩衝役が「作業部屋」での合意をその場で要点化し、日次でSlackに転記する案を提示していました。試す余地があったのでは？、と今は感じます。
「秩序派」の彼 コンペ第一ラウンド終了直後のぼやき
「チームリーダーが独断でDeepSeek-R1を動かす、と決めたチームが結局強かった」「運営が思い描いていた理想のチームは、秩序だって情報共有を行い、無難なモデルを選ぶチームのはず。思いがけない方向に行ってしまった」
本プロジェクトは、国立研究開発法人新エネルギー・産業技術総合開発機構(以下「NEDO」)の「日本語版医療特化型LLMの社会実装に向けた安全性検証・実証」における基盤モデルの開発プロジェクトの一環として行われます