目的
最近「生成AI開発」というワードをよく聞きます。社内でもよく聞きます。
ただ時折、人によってこの言葉の指す意味が異なるのを感じています。
そこで私なりのまとめを作ります。
そして自社開発の必要性が少しでも伝われば私にGPUを買ってください。
生成AI開発とは
大きく以下の3つの意味で使われている気がしています。
① 生成AIの 「活用」
これは組織において、普段業務を生成AIを活用して効率化することを意味しています。
例えば要件の案だし・資料作り、コーディング補助などが。
② 生成AIの 「統合」
これはビジネスにおいて、アプリや業務システムに生成AIを統合させることを意味しています。
例えばOpenai APIやAmazon Bedrockを使いシステムから生成AIを呼び出し業務フローの効率化など。
③ 生成AIの 「開発」
これは生成AIのモデル自体の開発を意味しています。
例えば（継続）事前学習、ファインチューニング、強化学習などを行い、特定のタスクに沿ったAIモデルの開発。
それぞれ補足
① 生成AIの 「活用」 について
これは弊社でもいち早く取り組んできました。
社内で生成AIの利用促進チームを立ち上げ、全社的に生成AIが使える環境というのを整えてきました。
詳細が気になる方はこちらのセミナーをご覧ください。
https://www.youtube.com/watch?v=-hRfrOdDPDw
② 生成AIの 「統合」 について
自社他社問わず最もこの動きが多いのではないでしょうか。
お客様の業務システムやフローに生成AIを統合して新たな価値提供をします。
ここでは主に基盤モデルとして高性能なクローズドモデル（重みが公開されていない調整不可なモデル）が使われることが多いかと思います。
③ 生成AIの 「開発」 について
この「開発」というものはさらに2つに分類できるかと思っています。
-
③-① 生成AIモデルの0->1開発（事前学習）
大量コーパスで言語能力＋一般知識＋基礎推論を形成。脳みそを作る。
AIモデルに「言語能力＋一般知識＋基礎スキル」を形成させるために大規模なコーパスを事前学習させます。
いわば脳みそを作る部分。 -
③-② 生成AIモデルの追加学習
- 継続事前学習：ドメイン文書で知識・語彙・基礎スキルを拡張
- ファインチューニング：指示への追従・口調・安全方針など振る舞いを学習
③-① については知識も資本もある大企業が圧倒的優位に立っており、新規参入のメリットも少なく感じます。（膨大な時間と金がかかるので）
しかし、③-② についてはこれから自社開発で必須のスキルになるのでは考えています。
なぜ生成AIを自社開発できた方がいいのか
ここでは生成AI≒言語モデル（LM）とします。また、開発とは「③-② 生成AIモデルの追加学習」を指します。
例えば以下のような要件があったとします。
この時、ChatGPTやClaudeなどのクローズドな大規模モデルを使った場合と自社開発した場合を比較します。
【要件】
- 社内への問い合わせにが膨大に来るので、生成AIを使って効率的に処理できるようにしたい
-> 決まったフォーマットの要約や特定情報の抽出などを高効率・高再現性で行いたい
【大規模モデルをそのまま使う場合】
- 業務前提・用語・出力形式を毎回プロンプトに盛り込む必要（文脈内学習／フューショット）
→ プロンプトが長文化し、入出力トークンとレイテンシが増大
API経由での利用の場合、トークン数に応じてコストが増大 - API経由で使う上での制限がある
→ API経由での利用の場合、トークン数に応じた課金形態やサービスクォータなどの制限 - モデル規模が数千億を超えるパラメータ級
→ 推論に必要なGPUリソースが大、回答生成が遅い - タスクに最適化されていない
→ 出力形式が一定ではなく、回答に揺らぎがある - プロンプトがネット外へ送信される
→ プロンプトに機密情報を含められない
【開発モデルを用いる場合】
- 業務知識・用語・出力形式を学習によるモデルの内在化が可能
→ 前提や形式を都度プロンプトに含める必要なく、トークンも削減でコスト／レイテンシを改善
自前環境で利用できるため、トークン数に応じてコストが増えることはない - API経由で使う上での制限がない
→ 自社環境で利用できるため、トークン数に応じた課金形態やサービスクォータなどがない - タスク特化なら数億~数十億パラメータ程度で小型化可能
→ 必要GPUリソース減、応答時間短縮、スループット向上 - タスクに最適化
→ 出力形式も学習済みで、回答に揺らぎがなくなる - 自前のモデルになるので、閉じたネット環境で動作可能
→ 機密情報渡し放題
まとめるとこんな感じ
| 項目 | 大規模言語モデル（そのまま利用） | 開発モデル（自社最適化） |
|---|---|---|
| 前提・用語・出力形式の扱い | 毎回プロンプトに付与（文脈内/フューショット）→ 長文化でトークン/レイテンシ増 | 学習で内在化 → 都度指定不要、トークン削減でコスト/レイテンシ改善 |
| API制限・課金 | トークン課金・サービスクォータなどベンダー制限あり | APIの従量課金なし／自社制御（※自社インフラの計算コストは発生） |
| モデル規模・推論資源 | 数千億超パラメータ級で重い → GPU大・応答遅い | 数億〜数十億へ小型化可 → GPU少・応答速い |
| タスク最適化/出力一貫性 | 汎用で非最適化 → 形式不定・揺らぎが出やすい | タスク特化 → 形式学習済み・一貫性高い |
| データ送信/セキュリティ | 外部送信が前提 → 機密を含めにくい | 閉域/オンプレ運用可 → 機密を安全に扱える |
| スループット/運用 | 長プロンプト＋大規模で遅延増 | 小型化でスループット向上・応答時間短縮 |
ここまで、あえて開発モデルのメリットが際立つように載せましたが、もちろんデメリットもあります。
それは大前提LLMの開発をしなければならないということです。
継続事前学習、ファインチューニング、強化学習等々...初期コストがかかってきます。
とはいえ、業界によっては特定のドメイン知識や堅牢なセキュリティ、高いスループットが必要だったりするケースがあります。
その際にモデルの開発・チューニングできるのは自社の強みにつながるのではないでしょうか。
（補足）RAGやMCPでいいのでは？
RAGやMCPはいわば知識の外付け、機能の拡張パーツです。
どちらも強力な機能ではありますが、今回の本質とはまた別の話かと考えます。
最適なモデル選定を踏まえたうえで、これらのパーツを使うのが効果を最大限活かせるものになるかと思います。
結論
大規模モデル＋プロンプト／RAGで“性能・コスト・制約”のどれかが許容値を超えるときに、開発LLM（継続事前学習やファインチューニング、蒸留・小型化）が合理的になります。
とくに 高スループット・低遅延・厳密な構造化出力・閉域運用 の要件が同時に立つケースは“やる価値大”です。
早いうちにLLMの開発ノウハウをためておいて損はないと思います。
今後企業ごとにLLMをカスタムすることが当たり前になるかもしれません。
そんな開発にぴったりなGPUがあります。
お値段4000ドルぐらい。
一個買ってくれませんか？