ONESTRUCTIONの金澤です。
前回の記事では、GENIAC第3期の開発成果である建設（IDS）特化基盤モデル「Ishigaki-IDS」の開発成果と開発の裏側について記事にしました。今回も引き続きGENIAC第3期で得られた開発成果について共有しようと思います。
今回のGENIAC採択は、私たちにとって初めての基盤モデル開発への挑戦でした。当初は基盤モデル開発に関する実践的な知見が限られた状態からのスタートでしたが、試行錯誤を重ねながら知見を蓄積し、少しずつ形にしていきました。そうした経験を通じて、より良いモデルを作るために必要なことは、学習戦略やデータ収集、分散学習といった技術的な内容だけでなく、実験・データ・スケジュールをどう管理し、PDCAを回していくかという”外側の設計”であることに気づきました。
従来の機械学習に関する実験管理手法の知見は多く蓄積されている一方で、GENIACのように限られた計算資源と期間の中で基盤モデルを開発する場合、1回の実験にかかる時間や成果物の規模は大きくなります。私たちも実際に開発に取り組むなかで、実験条件やスコアを記録するだけでは十分ではなく、スケジュール管理、ステークホルダーとの共有、データセットやckptのようなアセット管理まで含めて慎重に設計することの重要性を強く感じました。しかしながら、特に基盤モデル開発に関しては、このような“外側”に言及している資料は多くありません。
DeepSeekやQwenといったオープンウェイトモデルの成功を踏まえると、GENIAC第4期以降を含め、今後は国内でも多くの組織が基盤モデル開発に取り組んでいくと考えられます（The Future of the Global Open-Source AI Ecosystem: From DeepSeek to AI+）。 そのような組織がこれから開発を進めていく際に、できる限り開発の中核の部分に注力できるよう、運用・管理に関する知見も共有されていくべきだと感じています。
そこで本記事では、特に我々のように基盤モデル開発の知見が十分でない少人数チームに向けて、モデルそのものの設計ではなく、その開発を前に進めるための運用・管理に焦点を当て、私たちの経験で実際に得られた知見や取り組みを共有します。当たり前の話も多いかと思いますが、実際に進めていくと、そのような当たり前をキッチリこなすことも難しくなるといった観点で見てもらえると幸いです。
外側の設計とは？
LLMであっても、他モダリティのモデルであっても、より良い基盤モデルを開発するうえで重要な要素の一つは、高速な開発サイクルです（The Smol Training Playbook:
The Secrets to Building World-Class LLMs）フルスクラッチからモデルを開発する組織はもちろんそうですが、少人数のチームであっても何らかの追加学習を行うのであれば、使用するデータ、データ混合比率、学習手法、ハイパーパラメータなど、無数の変数の中から適切な設計を意思決定していく必要があります。そのためには、多くのアブレーションやチューニングを重ねながら、仮説検証を素早く回していくことが欠かせません。
こうした高速かつ精度の高い実験サイクルを支えるのが、本記事でいう“外側の設計”です。これは、実験をどのように設計・記録するか、データやckpt（チェックポイント）、評価結果をどのように管理するか、そしてどのようなスケジュールでPDCAを回していくかといった、開発サイクルを取り巻く設計全体を指しています。このような内容は、技術的なトピックに比べると軽視されがちです。しかし、この部分が曖昧なままだと、実験サイクルの速度も質も安定せず、結果として開発されるモデルの質そのものにも悪影響を及ぼしかねません。
実際に直面した課題
まずは、私たちが実際に直面した課題をケーススタディとして取り上げながら、”外側の設計”の重要性について紹介します。こうした課題は、私たちだけに特有のものではなく、基盤モデル開発に取り組む多くのチームが直面しうるものだと思います。
ケース1：データセット・ckptがカオスになる
特に、少人数かつリソースが限られたチームほど、「GPUのアイドル期間をできるだけ作りたくない」という焦りから、とにかく学習を止めないことを優先しがちです。その結果、開発に必要なタスクは次々とこなしていく一方で、実験内容や結果の整理、ckptの管理は後回しになりやすくなります。私たちの場合、実験サイクルの速さを最優先にした結果、出自を追えないデータセットやckptが増えていき、次第に全体がカオスな状態になっていきました。
データセットに関して言えば、各実験で使用したデータセットと実験記録、前処理スクリプトとの対応関係を十分に整理できていませんでした。そのため、過去に開発したモデルについて、「どのデータを使っていたのか」「どの前処理スクリプトから作られたのか」を把握することが難しくなっていました。
ckptについても同様です。多くの場合、ckptはrun番号やタイムスタンプ、step数などをもとに自動で命名・保存されますが、実験を重ねるにつれて、それが何のckptなのか分かりにくくなっていきます。私たちの場合も、過去の実験で作成したckptを後から探そうとした際、管理が十分でなかったために発見が難しい場面がありました。さらに、仮に見つかったとしても、それが本当に意図したモデルなのか確信を持てない状況に陥ることもありました。ckpt管理が曖昧なまま過去のモデルの意味づけが失われてしまうと、そのモデル開発に費やしたリソースが無駄になりかねません。
ケース2：不確実性を前提にしたスケジュール調整
基盤モデル開発では、多くのチームが限られたGPUの利用期間の中で開発を進めることになると思います。そのため、期間内で短期的なスケジュールと中長期のマイルストーンを設定しながら、開発を進めていく必要があります。その際に難しいのが、スケジュールの設計です。先述したように、基盤モデル開発は実験的な要素が多いため、「いつまでに何をやるべきか」を確定的に見積もることは困難です。
我々の場合、当初は基盤モデル開発に関する実践的な知見が限られていたこともあり、ロードマップを明確に描くことは容易ではありませんでした。各工程にどの程度の時間がかかるのか、1サイクルにどれくらいの期間を見込むべきかについて、公開情報や既存事例を参照しながら、まずは仮説ベースで計画を立てる必要がありました。
しかし、仮説ベースの計画だけでは、実際の開発をスケジュールどおりに進めることは容易ではありませんでした。そのため、その都度暫定的な見積もりを置き、実際の進捗や実験結果をもとにスケジュールを更新しながら進めていきました。この進め方は柔軟にスケジュールを調整できる一方で、目標や優先順位が変動しやすく、次に何を判断すべきかが見えにくくなる場面が多くなってしまいました。
今回実施したこと
こうした課題を踏まえ、プロジェクト後半にかけて、私たちは“外側の設計”を徐々に洗練させていきました。スケジュールをより高い確度で立てられるようにするとともに、各実験と関連するアセットを適切に紐付けて管理できるよう、運用の整備を進めました。ここでは、そうした試行錯誤の中で形にしていった、私たちなりの計画の立て方と実験サイクルの回し方を紹介します。
準備-1. 1回の実験サイクルにかかる時間を見積もる
多くの組織では、実験サイクルを回していく前に短期・中長期的な計画を引き、ステークホルダーに共有する必要があると思います。先述したように、スケジュール設計は何らかのとっかかりが無ければ勘で設定することになり、何の意味も持たない計画になります。私たちが採用して有効だと感じたのは、1サイクルの時間を根拠にスケジュールを設定するということでした。
CPT・SFT・RLといった各学習過程では、使用するデータ量やstep数が決まれば、学習にかかる時間がある程度見積もれます（もちろん、分散学習の構成やハイパーパラメータによって変動するため注意は必要です）たとえば、1Bトークン・1M stepの学習に24時間かかるのであれば、2Bトークン・2M stepでは48時間程度かかると概算できます。さらに、そこに実験準備期間としてN日を加えれば、1サイクル全体に必要な時間を見積もることができます。
このように概算して、たとえば1サイクルにおよそ2週間かかると見積もれれば、1か月で2サイクル、3か月では実験内容の変動も考慮しつつ4〜8サイクル程度を回す、といった形で計画を立てやすくなります。さらに、3か月後までに到達しておきたい状態が定まっていれば、各サイクルで何が達成されているべきかも見えやすくなります。もちろん、実験の進み方によっては計画を大きく修正する必要が出てくることもありますが、そのような場合でも、1サイクルの時間を基準として再度見積もりを作ることで、数か月先までの見通しを立てやすくなります。
このように計画を立てることで、より確度の高いスケジュールを設計しやすくなります。これにより、ステークホルダーとの擦り合わせがしやすくなるだけでなく、開発メンバーにとっても「N日後に次のサイクルが始まるので、それまでにここまで進めよう」という明確な目標を持ちやすくなります。特に、実験サイクルを小さく、速く回していくような開発においては、このような形で計画を設計することが有効だと感じています。
準備-2. 評価結果を自動で・インタラクティブに可視化できるようにしておく
各実験サイクルでは、学習後にckptの評価を行うことになると思います。このとき、評価スクリプトに加えて、評価結果を自動で蓄積し、分かりやすく可視化できる基盤も、あわせて用意しておくことが重要です。評価のたびに手作業で結果を集計していると、確認や比較に時間がかかるだけでなく、実験サイクル全体の速度も落ちてしまいます。今回私たちは、GENIACで採択されているWeights & Biases（W&B）のReport機能を用いて、この可視化基盤を整備しました。
私たちが構築した評価パイプラインでは、評価を実行するとベンチマークごとに自動で評価が走り、その結果がW&Bに転送され、レポートへ反映されるようにしていました。これにより、評価が終わるたびに結果を手動で整理し直す必要がなくなり、常に最新の状況をすぐに確認できる状態を保てました。さらに、このレポートは表示内容をインタラクティブに調整できるため、過去の任意のモデルとの比較や商用モデルとの追加の比較を気軽に行えます。そのため、開発中のモデルがどの程度の性能にあるのかを素早く把握するうえで非常に重宝しました。
また、このような可視化は開発者以外にとっても有益です。開発や実験の詳細を知らないステークホルダーに対しても、レポートを共有することでモデルの評価結果や立ち位置を容易に把握してもらえるため、チーム内のコミュニケーションを円滑にする効果がありました。
さらに、各ベンチマーク評価における実際の推論内容については、W&B Weaveを使って可視化していました。モデル開発では、スコアのような定量評価だけでなく、実際にどのような出力を返しているのかという定性評価もあわせて確認することが重要です。数値だけを見ていると、なぜその結果になったのかが分からず、誤った解釈をしてしまうことがあるためです。
私たちの経験談だと、ある時点で複数のモデルが全く同じスコアを取っていることに気づきました。これは何らかの異常だと思えたため、Weave上で実際の推論内容をチェックしたところ、Reasoning（<think>ブロック）が評価対象に混入してしまっており、それが原因だと分かりました。違和感に気づいた時、その背景を簡単に確認できるようにしておくことで、早期の対策に繋がります。
可視化基盤が不十分だと、評価結果に対して誤った考察をしてしまい、それが誤った実験設定につながりかねません。場合によっては、多大なリソースを無駄にする可能性もあると思います。そうした意味でも、簡単に確認でき、かつインタラクティブに調整できる可視化基盤は、早い段階で整えておくことを強く勧めます。
1. 実験のレポートを作成する
このような下準備を行ったうえで、次に、各実験サイクルをどのように進めていたのかを紹介します。先述した通り、私たちが課題として感じていたのは、実験が増えるにつれてデータセットやckptも増え、それらの管理や各実験との紐付けが次第に難しくなっていくことでした。そこで、すべての実験について実験レポートを中心に情報を集約するというPrincipleを置いて運用していました。
この実験レポートには、大きく2つの目的があります。1つは、各実験の背景や狙い、何を検証したかったのかを分かりやすく説明することです。もう1つは、その実験によって生じたデータセットやckptなどのアセットを、一箇所に集約して管理できるようにすることです。実験数が増えてくると、「このckptは何を目的に学習したものか」「このデータセットはどの検証で使ったものか」が分かりにくくなりがちです。実験レポートを中心に情報を整理しておくことで、そうした対応関係を後からでも追いやすくなります。
レポートの構成としては、実験全体の流れを網羅的に記録するため、背景→課題・目的→検証内容→結果→ネクストアクション、という見出しで情報を記録していました。また、冒頭には実験の要点を一目で把握できる概要を置き、その後に詳細で厳密な内容を整理する形にしていました。これにより、まず全体像を素早く把握し、そのうえで必要に応じて詳細を確認できるようにしていました。
実際の運用としては、最初にテンプレートから実験レポートを作成し、計画段階で埋められる部分を記入します。その後、実験を進めながら分かったことや結果を随時追記していき、最後に要約情報を上部に整理して完成させる、という流れで運用していました。
実験レポートの例（内容はイメージです）
今回、こうした実験レポートの作成にもW&BのReport機能を活用しました。W&B Reportでは、Notion likeに情報を記録できる他、先ほどの評価基盤と同様に、lossやrewardといった学習過程のグラフを選択して埋め込み、インタラクティブに可視化できます。そのようなグラフはホバーすることで細かな数値まで確認できるため、単に結果を記録するだけでなく、学習の傾向を読み取りながら結果を解釈し、考察につなげやすい点も有用でした。
2. パッと見で分かるProject・RUNを設定する
レポートで実験の計画を作成したら、次は実際に実験を実行していくことになります。この段階で意外と重要になるのが、実験名やプロジェクト名の管理方法です。かなり枝葉の話にも見えますが、私たちの経験では、この部分は実験を正しく整理・理解するうえでクリティカルであり、パッと見で内容が分かる名前を付けておくことが、後の管理や振り返りのしやすさに大きく影響しました。
たとえば、上記は実際にスループット改善を目的として行ったアブレーション実験のプロジェクト名・RUN名ですが、何を意図した実験なのかが名前から把握しやすくなっていると思います。このような名称にしておくと、後から自分で見返したときにも、各実験の意図や結果、そこから得られたインサイトを追いやすくなります。
一方で、デフォルトのままでは、タイムスタンプやRUN番号といった意味を読み取りにくい名前になりがちです。実験直後は記憶で補えるため大きな問題には見えないかもしれませんが、数週間も経つと、各RUNが何を意図したものだったのかさえ正確に思い出すのは難しくなります。その結果、実験内容の取り違えや解釈ミスが生じる可能性があります。
また、何も考えずに実験を回していると、実行に失敗したRUNが大量に残ってしまいがちです。そうしたRUNは、残しておく明確な理由がない限り積極的に削除し、できるだけプロジェクトをクリーンに保つべきです。不要なRUNが多い状態では一覧のノイズが増え、必要な実験を見つけにくくなるだけでなく、全体の解釈もしづらくなってしまいます。
W&Bの場合、プロジェクトの切り方としては、複数の実験をまとめて管理したり、すべてを共通のプロジェクトに集約したりするのではなく、実験ごとにプロジェクトを分けることを推奨します。1つのプロジェクトに情報を集約しすぎると全体が煩雑になり、把握しづらくなるためです。別プロジェクトのRUNとの比較はコピー機能などを使って容易に行えるため、このように分けたほうが圧倒的に管理・理解しやすいと感じました（W&B Skillsもリリースされています）
3. レポートにRUN, データセット, ckpt, 評価結果を紐づける
実験を実行したら、その実験に関わる情報をレポートへ記録し、どのRUNで、どのデータセットを使い、どのckptが生成され、どのような評価結果になったのかを一つの場所で追えるようにしておくことが重要です。私たちは、W&BのプロジェクトURL、使用したデータセット、生成されたckpt、評価結果といった実験に関わるアセットを、レポート上で明示的に記録し、相互に紐づけるようにしていました。私たちの場合は、下記のような形でレポートに整理していました。
内容は実際に使っていたものから差し替えたイメージになります
内容は実際に使っていたものから差し替えたイメージになります
私たちの運用では、データセットとckptをS3にアップロードしていたため、レポートにはそれぞれのURIを記録していました。これにより、レポートを見れば、その実験で実際に使ったデータセットや、そこから得られたckptへすぐに辿れる状態になっていました。評価結果についても、単にスコアだけを記録するのではなく、可視化基盤上でベースラインとの比較を作成し、その比較結果を掲載するようにしていました。
この紐づけを丁寧に行うことは、実験数が少ないうちはそこまで重要に見えないかもしれません。しかし、実験を重ねるほど、RUN、データセット、ckpt、評価結果といった関連情報は急速に増えていきます。その状態で情報の対応関係を明示せずに運用していると、「このckptはどの設定で作ったものだったか」「この評価結果はどのRUNに対応していたか」「このデータセットはどの実験で使ったものか」といった基本的なことですら、後から追うのが難しくなります。
最悪の場合、せっかく開発したckptを見失ったり、別の実験で得られたckptを誤って同一視したり、逆に本来は同じ系列の成果物を別物だと誤認したりする可能性があります。これは単なる整理不足ではなく、実験結果の解釈や次の意思決定を根本から誤らせる原因になり得ます。
一見すると当たり前のことばかりに思えるかもしれませんが、リソースやGPU期間が限られている中での開発だと、全てを完璧にやり切ることは容易ではありません。こうした当たり前を意識的に行うことで、根本的なリスクを大きく減らしつつ、より質の高い意思決定を加速することができます。
4. 次の実験に繋げる
ここまで整理できれば、その実験レポートはひとまず完成です。あとは、得られた結果をもとに考察を行い、次に何を検証するべきかを整理して、次の実験サイクルの計画へとつなげていきます。私たちの運用では、後に見返したときにパッと見で内容を理解できるように、実験が終わった時点でレポート全体を見返し、最後にレポート上部に実験の要約を記載するようにしていました。
内容は実際に使っていたものから差し替えたイメージになります
特に、リソースが限られたチームでは、実際にPDCAを回しながらこのような整理まで行うのは大変に感じられるかもしれません。しかし、整理不足のまま開発を進めると、後から実験の意図や成果物の対応関係が追えなくなり、より大きな損失につながる可能性があります。そう考えると、こうした整理には十分に取り組む価値があると思います。実際、慣れてしまえば運用の負担もそこまで大きくありません。
また、このようなレポートの価値は、作成直後よりも、むしろ数週間後、数か月後に実験を見返すタイミングでより強く実感されます。時間が経って記憶が薄れたあとでも、背景、目的、設定、結果、次のアクションまでが一つの場所にまとまっていれば、当時の判断をスムーズにたどることができます。初めは作成が少し手間に感じるかもしれませんが、その苦労に見合う価値は十分にあると感じています。
現在、私たちは開発成果の論文化に取り組んでいますが、この形式で情報を整理していたことが大いに役立っています。そうした意味でも、このような“外側の設計”は、基盤モデル開発において非常に重要だったと感じています。
これからの改善点
これまでの内容には当たり前の話も多く含まれているとは思いますが、実際に開発を進めていくと、GPU予約の制約や最終目標への焦りから、細部の管理が疎かになりがちです。きっちりと上記のような管理を進めることによって、実験サイクルの効率化が進み、サイクルの速さと質の両面を改善できます。また、ステークホルダーへの共有や、後から振り返る際の読み取りやすさという点でも有用でした。
一方で、これらの取り組みによって多くの課題は解決できたものの、細部まで十分に整備しきれなかった点も残っています。これから新たに基盤モデル開発に取り組むチームの参考になればと思い、それらの改善点についても共有します。もし良い解決策をご存じの方がいれば、ぜひ教えていただけると嬉しいです。
より厳密で多層的なデータセットの管理
データセットの管理は非常に難しいです。単に、実験で使用したデータセットを保存し、その情報を記録しておけばよいようにも思えますが、それだけでは不十分でした。実際には、データセットに関する情報を複数のレイヤーで整理・記録する必要があり、それらを後から理解しやすい形で管理することは簡単ではありませんでした。
私たちが特に重要だと感じたのは、まずデータセットの構成要素と履歴を追えるようにすることです。最終的に学習に使用するデータセットは、単一のソースからそのまま作られるとは限らず、複数のデータソースを前処理し、それらを一定の比率で混合して構築することが多くあります。そのため、最終成果物としてのデータセットだけを見ても十分ではありません。どのソースデータを使ったのか、どの前処理を施したのか、どの比率で混合したのか、さらにNeMo形式やMessage形式、Reasoningの有無といったデータ形式上の違いまで含めて、追跡できるようにしておく必要があると感じます。私たちは開発中のリソースが逼迫していたこともあり、これらの軸を全て網羅して綺麗に整理しきることは困難でした。
もう一つ重要だと感じたのは、定量的な情報と定性的な情報の両方を管理することです。定量的な情報としては、データ件数、トークン数やその分布、Reasoningの有無、データ種別ごとの比率などが挙げられます。こうした情報は、実験条件を正確に把握し、比較可能な形で管理するうえで不可欠です。その上で、定性的な情報として、データサンプルをいくつかピックアップし、その特徴や気づきを記録しておくことも重要でした。データセットは、統計量だけを見ていても、本当に意図した内容になっているかまでは分からないことが多いです。実際、私たちの運用でも、データセットを目視で確認していなければ、意図と異なる設定のまま実験を進めてしまったり、結果を正しく解釈するための重要な手がかりを見落としてしまったりする場面がありました。そのため、データセット管理においては、定量と定性の両方を簡単に確認できる仕組みが必要だと感じました。
不確実性を前提にしたスケジュール設計
先述したように、1サイクルにかかる時間を見積もることは、スケジュール設計において非常に有効です。一方で、中長期のスケジュールを設計するうえでは、このようなボトムアップのアプローチだけでは不十分だと感じました。実際に取り組んでみると、1サイクル単位で見積もるだけでは、数か月後にどの状態まで到達したいのか、また、そのために今どの実験を優先すべきかが見えにくくなる場面が多くありました。
そのため、各サイクルの所要時間を積み上げるだけでなく、中長期の到達目標を置き、そこから逆算して各サイクルの役割を考えるという、トップダウンの視点もあわせて必要だと感じました。つまり、短期的な実行可能性を支えるボトムアップの見積もりと、中長期の方向性を定めるトップダウンの目標設定の両方を統合しつつ設計することが重要だと考えています。
ただし、この両者をどのように統合してスケジュール設計をするかについては、今回の取り組みを通じてもなお大きな課題として残りました。現時点では明確な解決策を持てているわけではなく、OpenAIやAnthropic、Googleのようなフロンティアモデルを開発する組織が、このような不確実性の高い開発において、どのように中長期の計画を設計しているのかは非常に気になるところです。
おわりに
今回のブログでは、GENIAC第3期で私たちが直面した、基盤モデル開発における“外側の設計”について共有しました。こうした現場寄りの知見は、重要である一方で、なかなか表に出にくいものでもあります。そのため、同じような課題に直面しているチームも少なくないのではないかと思っています。そのようなチームに対して、我々の知見が少しでも貢献できれば幸いです。
私たちはこれからも、AIをはじめとするテクノロジーを活用しながら、建設DXの推進に取り組んでいきます。今後の発信にもぜひご期待ください。
前回の記事はこちら：
建設AIに一緒に取り組む仲間を募集しています！
ONESTRUCTIONでは建設AI・建設基盤モデル開発に興味がある仲間を募集しています。正社員・インターン生を募集しているので興味がある方は下記からご連絡ください。
謝辞
最後に、GENIACでの取り組みにおいてW&Bを活用させていただき、誠にありがとうございました。丁寧にサポートいただいたW&B 鎌田さんにも、心より御礼申し上げます。
Discussion