LLMの本質的価値とプロダクト適用における技術的考察

はじめまして。株式会社PeopleX CTOの橘です。

PeopleXは2024年4月の創業から2年目となる2025年、企業ブランドを「採用から活躍支援まで、人事領域のAI Techカンパニー」に変更し、生成AIを活用したソリューションを提供しています。

生成AIの波がテック業界に訪れていることは、エンジニアの皆様には説明不要でしょう。Claude CodeやCursorなど、次々とコード生成ソリューションが登場し、コーディング業務の相当な割合をAIが担うようになりました。テック業界に留まらず、世界的に生成AIへの期待は高まっています。しかし実際のところ、人間の広範な作業を完全に置き換えるには至らず、技術的に解決が困難な領域があるのも事実です。

本記事では、生成AIの登場により何ができるようになったのか、何が本質的に難しいのかを技術的観点から考察し、プロダクト価値を発揮するための生成AI活用法について記します。

LLMの技術的基盤と革新性

LLMの本質的特徴

今回は生成AIの中でもLLM（Large Language Model）に焦点を当てて検討します。LLMは、大規模なテキストデータセットで学習された深層学習アルゴリズムであり、テキストの認識、要約、翻訳、予測、生成を行うことができます。

LLMの核となる能力は、数千億にも及ぶ膨大なパラメータを持ち、次のトークンを統計的確率に基づいて予測・生成することにあります。このシンプルな仕組みから、言語理解、推論、コード生成、創作など多岐にわたる能力が創発的に現れることが特徴です。

主要アーキテクチャの現状

2025年現在、主流なLLMはTransformerアーキテクチャに基づいています。OpenAIのGPTシリーズ、MetaのLlama、GoogleのGeminiなど、メジャーなLLMの多くがTransformerを採用しています。Transformerの革新は自己注意メカニズムにあり、シーケンス内の全要素を並列処理し、任意の距離にある要素間の関係を効率的に捉えることができます。

Transformerアーキテクチャの採用と大規模事前学習の組み合わせにより、以下のような能力が飛躍的に向上しました。

・長文理解・要約: 数千トークンに及ぶ長文でも文脈を一貫して把握し、高精度な要約や質問応答が可能となった。
・few-shot学習・ゼロショット性能: 限られた例示(few-shot)や事前のタスク学習なし（zero-shot）でも、多種多様な言語タスクに適応できるようになった。
・広範なドメインへの適応: プログラミング、翻訳、創作といった領域横断的タスクを一つのモデルで高水準にこなす汎用性を獲得した。

汎用性と精度の両立

「統計的確率に基づいて次トークンを生成する」というシンプルかつ汎用的な仕組みであるLLMが、従来の専用モデルを上回る性能を実現したことが、AIのパラダイムを変えました。具体例として機械翻訳を見てみましょう。GoogleやMicrosoftは長年にわたり、Neural Machine Translation（NMT）という専用技術に大規模投資を行ってきました。

しかし現在では、汎用的なLLMがコンテキストを踏まえた翻訳において、多くの言語ペアでNMTを上回る品質を実現しています。WMT24（機械翻訳に関する国際会議）では、Claude 3.5-Sonnetが最高性能を記録し、11言語ペア中9ペアで勝利しました。

(注: しかし、LLMは従来のNMTと比較してレイテンシやコストが高く、速度とコストを重視する大量処理では依然として専用システムが使われることが主流です。)

そのような中で、アプリケーション開発者にとっては、複数の専用モデルを個別に開発・運用する必要がなくなり、LLMがアプリケーション開発の主役へと移行しています。

LLMによる機械学習パラダイムの転換

スケール則による性能向上

従来の機械学習ではタスク特化型モデルが主流で、画像認識ではCNN、自然言語処理ではRNNやLSTMといった具合に、問題領域ごとに最適化されたアーキテクチャが用いられていました。

LLMは根本的に異なるアプローチを取ります。データ量とモデルサイズを大幅に拡大することで、単一のアーキテクチャが多様なタスクにおいて専用モデルを上回る性能を発揮するようになったのです。この「スケール則」により、論理推論・コード生成・長文要約といった能力が創発的に現れました。

学習パラダイムの変革

学習プロセスも劇的に変化しました。LLMは一般的に以下の段階を経ます：

1. 事前学習：大規模テキストデータでの自己教師あり学習（次トークン予測）
2. 教師ありファインチューニング（SFT）：指示-応答ペアでの学習
3. 人間フィードバックからの強化学習（RLHF）

従来の「事前学習→タスク別微調整」から、「汎用事前学習→プロンプトによるタスク適応」という新しいパラダイムが確立されました。これにより、新しいタスクに対して大量のラベル付きデータを必ずしも用意する必要がなくなりました。

LLMによるアプリケーション価値の変革

LLMをプロダクトに組み込む際には、従来のシステムとの根本的な違いがあります。従来は決定論的な処理により予測可能な結果を返しますが、LLMは自然言語による入力を変えることで異なる出力を容易に得られるようになります。

近年、米国を中心に「SaaS is Dead」というキャッチーなフレーズが広まり、これはマイクロソフトCEOのサティア・ナデラの発言に端を発します。必ずしもこれに同調するわけではありませんが、興味深い問題提起として、従来のSaaSは本質的にはデータベースのCRUDを実装したものという指摘があります。

SaaSの王道パターンの一つは、対象領域のドメインエキスパートが業務を分析し、最大公約数を満たすプロダクトを提供することで、システム知識を持たない顧客でもベストプラクティスを享受できるというものでした。個社ごとのカスタマイズは各種設定でカバーするものの、システム全体が決定論的に作られているため、独自の業務プロセスが複雑に組まれたエンタープライズ企業への導入が進みづらいという課題も浮き彫りになりました。

一方でLLMを活用することで、自然言語による指示で期待する出力を得られるようになりました。決定論的な世界ではルールベースの枠内で設定項目によりカスタマイズしていたものが、自然言語で指示をすると統計的確率に基づいて妥当な出力を各社ごとに得られるようになったため、これまで適用できなかった複雑な業務プロセスへの適用可能性が広がっています。

当然、LLMがあれば何でも思った通りの出力が得られるほど簡単なものではなく、決定論的なシステムをガードレールとして組み合わせる必要があります。しかし、決定論から統計的確率を前提としたシステムへとパラダイムが変わっていることは間違いありません。

正解がない領域への適用

LLMが真価を発揮できる領域の一つは、「完全な正解は存在しないが、統計的に妥当な判断が価値をもたらす領域」です。

従来の機械学習モデルは、正解ラベルをもとに勾配降下法を用いてより損失の少ない出力を得たり、勝敗のような結果をもとに強化学習で報酬を最大化するなど、正解や勝敗のある領域において事前学習されてきました。LLMも学習プロセスにおいては同様ですが、利用する際には正解が存在しない問いに対しても、統計的に妥当な答えを出してくれるという特徴があります。

この特徴を活かして以下のような適用方法が考えられます（※思考実験として例示しているのみで、これらのアプリケーションが成立することを保証しているわけではありません）：

知識の非対称性を解消する領域

例えば「法務相談チャットボットや旅行プラン提案システム」など、専門知識を一般ユーザーがアクセスしやすい形で提供する用途です。完璧な法的助言や緻密な旅行プランは期待できませんが、初期段階での情報提供や方向性の示唆として十分な価値があります。

重要なのは「正確性の限界」を明確にUI/UXで示すことです。「参考情報として提供」「必要に応じて専門家・旅行会社に相談を推奨」といった免責と合わせて、ユーザーの期待値を適切にコントロールする必要があります。

大量処理による効率化が主目的の領域

カスタマーサポートの一次対応や、大量ドキュメントの要約・分類などが該当します。個々の処理の完全性よりも、全体の処理効率向上と人的リソースの最適配分が価値となります。

この場合、人間によるエスカレーション・フローの設計も同時に重要です。統計的判断では困難なケースを適切に人間に引き継ぐことにより、業務に浸透させることができます。

創作支援における発想の拡張

コンテンツ生成支援やアイデア出しは根本的に正解が存在しない領域のため、LLMの確率的生成が役立ちます。

LLMアプリケーション開発時の制約

このようにLLMはソフトウェアの提供可能な価値を広げましたが、魔法のように何でも解決してくれるわけではありません。代表的な制約について紹介します。

正解がない領域での精度の限界

正解が明確に定義できないタスクでは、モデルを学習・評価する際の基盤となる評価指標自体が不確実になります。たとえば経営判断の提案では「これが唯一の正解」といえるものがなく、また失敗と思われても反証が困難です。そのため、学習時には次トークン予測の自己教師あり学習やRLHF（人間フィードバック強化学習）を組み合わせても、推論内容が主観的でノイズを含みやすく、モデルの性能を安定的に向上させることが難しくなります。

さらに、客観的なベンチマークが整備されていない領域では、モデルの比較評価が困難です。BLEUやROUGEのような評価指標は、翻訳や要約のように人手アノテーションとの整合性が保証されたタスクに有効ですが、経営判断など定量化しづらい出力には適用できません。その結果、性能向上のための反復的な改善サイクルが回りにくく、高次の意思決定を置き換えるほどの精度を出すのは困難になります。

「正解がない領域でも統計的に尤もらしい出力ができる」ことの裏返しでもありますが、精度を上げることが本質的に難しいため、この制約の上でプロダクト価値を提供できる領域を慎重に決定する必要があります。

ソフトウェアが収集できる情報の限界

例えば「優秀なカスタマーサポート担当者の対応パターン分析」を行うアプリケーションを考えてみましょう。システムが収集できるデータは、チャットログやメールのやり取り、FAQへのアクセス履歴などに限られます。しかし実際の対応品質には、お客様との声のトーンやニュアンスの把握、状況に応じた臨機応変な対応、担当者の共感力やストレス耐性といった定量化が難しい要素が大きく影響します。

このように、人間の活動を完全に記録することは現実的ではありません。仮に映像や音声、バイタルデータなどを全方位的に取得しても、情報セキュリティ上の制約やストレージ・計算リソースの観点から、実運用には膨大な負荷がかかります。

さらに、人間が判断に用いる五感や経験、暗黙知はデジタル化が困難であり、高次の意思決定においてはこれらの要素が重要な役割を果たします。したがって、現実のアプリケーションが収集可能なデータは必ずしも判断の全要素を網羅せず、その結果としてLLMが扱うデータは統計的出力の範囲を超えられない場合があります。

既存事例から見る実装パターン

GitHub Copilotの設計思想

GitHub Copilotが、コード生成におけるブレークスルーをもたらしたことは皆様ご存知の通りです。

編集中のファイルや開いているタブの内容から統計的確率をもとに、尤もらしいソースコードを提示します（※現在はより広範なコンテキスト保持のソリューションがありますが）。これはプログラマが無条件に受け入れるというよりも、受け入れてから最適な形に修正することも前提としたものとなっています。

「完璧なコードの自動生成」ではなく「開発効率の向上支援」に焦点を絞り、ソースコードの最終的なレビューや確定は人間が行うという業務フローは変わっていません。またIDEに組み込まれることで、従来の開発プロセスを踏襲したまま導入することができます。

LLMの不完全性を前提としながらも、日々の業務に深く入り込むためのインターフェースを備えていたことが、短期間で世界で受け入れられるようになった要因でしょう。

PeopleXの面接システムにおける設計判断

手前味噌ですが、弊社のAI面接プロダクトの事例も紹介します。

AI面接は3Dアバターと人間のように対話をしながら、実際の面接を進行していくプロダクトです。

面接官の発言や質問、また候補者の回答への深掘りはLLMを駆使したものですが、面接という候補者の就業機会を左右する重要なイベントにおいて、進行不能となるような不完全性は受け入れられません。

従来システムのような決定論的なガードレールを随所に入れることで、不完全性によるデメリットを極力防ぎながら、LLMの統計的アプローチに基づくリアルな面接体験を実現しています。

まとめ：LLM時代の開発指針

LLMアプリケーションでは、決定論的でなく統計的確率による不完全性を受け入れながらも、ソフトウェアに次のような新しい可能性をもたらしています。

• 自然言語による個社最適化：ルールベースの中で大量の設定項目を設けることで個社カスタマイズしていたものが、個社ごとの要求を自然言語による記述でより柔軟な出力を得られるようになった。
• 正解がない問題への取り組み：経営判断支援、創作活動支援など、明確な正解が存在しない領域でも統計的に有用な回答をすることで、意思決定を支援できるようになった。

重要なのは、この「不完全性」を設計思想として受け入れ、それを価値に転換するプロダクト設計です。また、開発チームとして持つべき視点も次のように転換する必要があります。

• 技術優先から価値優先へ：「LLMで何ができるか」ではなく「ユーザーの課題解決にLLMがどう貢献できるか」を起点とする。
• 完全性から実用性へ：常に100%の精度を目指すのではなく、80%の精度でも10倍の効率化を実現することが求められる領域へのソリューションを実現する。
• 単一システムから複合システムへ：LLM単体でなく、従来システム、人間の判断、外部データソースとの連携による全体最適を実現する。

もちろん、不完全性に伴うプロダクトの改善余地は常に存在するため、組織としてユーザーフィードバックを基にした改善サイクルの確立や、品質問題やコンプライアンス課題への備えも必要です。

LLMは革新的な技術ですが、それ自体が目的ではありません。顧客課題の解決という本質を見失わず、技術の特性を深く理解した上で、適切な領域で価値を提供することこそが、LLM時代の開発組織に求められています。