LLM

サービス開発をしている同僚たちと話をしていると、AI導入について漠然とした負担感を感じているケースをよく見かけます。その負担感の根源を掘り下げると、大抵は**「学習（Training）」**という用語が生む誤解に起因しています。 「モデルをサービスに組み込むと、ユーザーデータを取り込んでリアルタイムで学習して賢くなるんですか？」 「じゃあ、その学習プロセスを私たちがコントロールできますか？変なことを学んだらどうしますか？」 もしこのような悩みをお持ちでしたら、少し心配を置いても大丈夫です。今日はその誤解を開発者の言葉で解説します。 「学習」はビルドタイム、「推論」はランタイム 最初に正すべきことは、私たちがサービスにデプロイするAIモデルは、ほとんどの場合「凍結された（Frozen）」状態であるという点です。 開発用語で例えると次のようになります。 概念 AI用語 開発用語の比喩 説明 モデルを作る 学習（Training） ビルドタイム（Build Time） 膨大なリソースと時間が必要 モデルを使う 推論（Inference） ランタイム（Runtime） リクエストを受けて結果を返す 私たちがサービスを運用するとき、実行中のバイナリコードが自らコードを修正して進化することはありません。AIも同様です。 モデルはデプロイされた瞬間、もはや「学ぶ学生」ではなく、**「指示通りに働く労働者」**になります。私たちが心配すべき領域は学習ではなく、この労働者がうまく仕事ができるよう環境を整えることです。 図書館の比喩でAI構造を理解する では、最新情報はどのように反映され、AIはどのような役割を果たすのでしょうか？私はこの構造を**「図書館」**に例えることがよくあります。 構成要素 図書館の比喩 説明 AIモデル（LLM） 司書 言語能力と推論能力を持つ存在 RAG / DB 書庫 サービスデータと最新情報が保存される空間 プロンプト 業務指示書 司書に仕事を任せるときに渡すガイドライン サービス開発者である私たちが毎日やっていることは、**「図書館に新刊を補充すること（DBアップデート）」**です。司書（AI）は私たちが補充した本を必要なときに取り出し（Retrieve）、内容を読んで組み合わせてユーザーに提供する（Inference）だけです。 多くの方が恐れている**「学習（Fine-tuning）」は、「司書を大学院に送って再教育すること」**に相当します。司書が基本的な読解力が不足している場合や、一般的な常識では理解できない特殊なドメインを扱う必要がある場合にのみ必要なエッジケースです。 ほとんどのビジネス問題は、司書を再教育（学習）させることではなく、以下の3つで解決できます： 優秀な司書を採用する - 良いベースモデルを選択 良い業務マニュアル - よく設計されたプロンプト 整理された書庫 - 構造化されたRAG/DB AIは「意味処理アクセラレータ」である このように構造を把握すると、AIはもはや恐ろしい未知の存在ではありません。単に私たちのシステムアーキテクチャに組み込むべき一つの**「部品」**に過ぎません。 コンピュータの歴史は「処理の高速化」でした。 ハードウェア 高速化対象 CPU 計算とロジック（if-else）処理 GPU グラフィックスとピクセル処理 AI（LLM） 意味（Semantics）と文脈（Context）処理 私たちはこれまでif (text.contains("りんご"))のようなコードで人間の言語を機械的に処理するのに苦労してきました。今では、その「意味処理」を専門に担当する高性能アクセラレータ（AI）が登場したのです。 おわりに AI時代だからといって、開発者がAIモデルを直接作ったり数式を理解したりしなければならないという強迫観念を持つ必要はありません。 MySQLの内部エンジンのソースコードを知らなくても優れたバックエンドサーバーを構築できるように、AIという**「優秀な司書」を私たちのサービスのどのデスクに座らせ、どのような権限を与えるかを設計するアーキテクチャリング能力**は今でも有効であり、さらに重要になっています。 AIに過度な意味を付与しないでください。それは自ら考えて反乱を起こす人工知能ではなく、私たちが入力したデータを確率的に最もそれらしく処理して返す**「関数（Function）」であり「ツール（Tool）」**です。 ツールは恐れるべき対象ではなく、手に馴染ませてうまく活用すべき対象です。