「小さく失敗できる環境」が、開発スピードを上げる上で非常に重要でした。
-LLM開発スピードとコスト課題を劇的に改善したSCCの挑戦-
-

株式会社SCC様は、金融系や鉄道系をはじめとする多くの大手企業から直接案件を受注し、要件定義から運用開始までを一気通貫で手がける実力派のシステムインテグレーター（SIer）です。

同社では、受託案件のプロジェクト状況をモニタリングする「マネジメントセンター」と、AIやクラウドなどの最新技術で開発部門を支える「AI・TECラボ」が強力に連携しています。さらに、グループ内に専門学校などの教育機関を有しており、独自の教育ノウハウをプロジェクトマネジメントの組織的支援に活かしている点も大きな強みです。

近年、システム開発プロジェクトの複雑化に伴い、プロジェクトマネージャー（PM）の負担増大が課題となっています。そうした中、SCC様は現在、「現場のPMを支援する独自の社内LLM（大規模言語モデル）」の研究開発に取り組まれています。

本記事では、自身も長年PMとして現場を牽引してきた開発担当者に、独自データを活用した「頼れるベテランPMシステム」の開発背景と、アジャイルな試行錯誤が求められるAI開発において、ハイエンドGPUクラウド「GPUSOROBAN」がどのように課題を解決し、開発を加速させたのか、その全貌を伺いました。

志賀さん　背景には大きく分けて「プロジェクトマネージャー（PM）の支援」と「セキュリティを担保したデータ活用」という2つの軸があります。

もともと私はPMを担当しており、当時はプロジェクトの計画書や報告書がすべてExcelで管理されていました。何十年分ものデータが蓄積されているにもかかわらず、それらが十分に活用されていないことに強い課題を感じていました。

近年、システム開発プロジェクトはますます複雑化しており、PMに求められる判断や責任も増大しています。
実際に負荷が高まり、心身に影響が出てしまうケースも見られる中で、「ここにリスクが潜んでいるかもしれない」「この点は再確認したほうがよい」といった示唆を、AIが一歩先に提示できれば、PMの心理的負担も軽減できるのではないかと考えたのがきっかけです。

そこでまずは、将来的にAIでの活用を見据えたデータ戦略の一環として、2021年頃にプロジェクト情報をウェブシステム化し、データを蓄積する基盤を作りました。

その後、ChatGPTをはじめとする生成AIが登場しますが、プロジェクト情報には機密性の高い内容が含まれるため、外部サービスにデータを送信することは現実的ではありませんでした。そこで「ローカル環境でLLM（大規模言語モデル）を構築する」という方針を決定しました。

志賀さん　私たちは過去何十年にもわたるプロジェクトの計画書や報告書を保有しています。

これらの文書に蓄積された、PMの判断観点や対応ノウハウをAIに学習させることで、
進行中のプロジェクトに対して「過去に類似のケースで問題が発生していないか」「どの観点で見直すべきか」といった、独自の実績に基づいた示唆を提示できる仕組みを構築しています。

単に一般的な知識を検索して回答するのではなく、自社の蓄積データを反映した判断支援ができる点が特徴です。

一般的なAIの回答は教科書的になりがちですが、「ベテランPMならどこに着目するか」「どのような言葉でリスクを指摘するか」といった振る舞いをモデルに反映させることで、現場のPMにとって納得感のあるアドバイスができるAIを目指しています。

河野さん　もともと社内でAWSを利用していたため、LLM構築用の学習サーバについても、AWS環境を利用するのが自然な選択でした。

河野さん　検証を進める中で、大きく分けて「リソース確保」と「コスト」の2点に課題を感じました。

まずリソース面では、必要なタイミングでGPUインスタンスを確保できないケースが頻発しました。
当時は世界的にGPUが不足しており、起動しようとしても利用できない状況が続いていました。
事前予約という選択肢もありましたが、利用していない時間帯にも課金が発生するため、検証フェーズではコスト効率が見合いません。

また、一度インスタンスを停止すると再度起動できない可能性があるため、停止をためらい、結果として不要な稼働時間が発生するというジレンマもありました。
「デモや試運転をしたいのにGPUを確保できず、スケジュールが遅れる」といった事態も実際に起きていました。

さらに、ストレージ面でも、安価なディスクでは読み書きの速度が出ず、高速なディスクを用意しようとすると追加コストがかかるといった課題もありました。

河野さん　最終的に「GPUSOROBAN」採用に至った最大の決め手は、「開発の自由度」と、それを支える「コストパフォーマンス」の両立でした。

AI開発は従来のシステム開発とは異なり、あらかじめロジックが確定しているものではなく、「試してみなければ分からない」要素が多く含まれます。そのため、試行回数を重ねられる環境であることが極めて重要です。
時間課金型の環境では、試行回数が増えるほどコストが積み上がるため、どうしても「失敗できない」という心理的な制約が生まれます。一方、GPUSOROBANのような定額制であれば、「まずは回してみる」「夜間も含めて継続的に学習させる」といった試行錯誤を前提とした開発が可能になります。

この「小さく失敗できる環境」が、開発スピードを上げる上で非常に重要でした。

加えて、試算の結果、AWSでGPUを24時間365日確保し続けた場合と比較しても、大幅にコストを抑えられることが分かりました。
継続的に学習・検証を回す前提で考えたとき、「これを採用しない手はない」と感じたのが正直なところです。
実際、ケースによってはAWSの数分の一のコストで運用できる試算となり、費用面での現実性も大きな判断材料となりました。

さらに、国内基盤で安定的にリソースを確保できる点や、高速なストレージ環境も、継続的なLLM開発を進めるうえで重要な判断材料となりました。