LLM とは｜ChatGPT・Claude との違いを未経験者に日常のたとえで

ChatGPT を覚えたと思ったら、次は Copilot、その次は Gemini、Claude——新しい AI ツールが毎週のように出てきて、整理が追いつかないと感じていませんか。実際、ラッコキーワードの実測（2026 年 5 月時点）でも「LLM とは」というキーワード単体で月 3 万人以上が同じ問いに迷っている状態で、私自身も非エンジニア部門からの「結局これ全部、何がどう違うの」という質問に毎週のように答えています。

結論から言うと、LLM は「文章を予測する装置」、ChatGPT・Claude・Gemini はその装置を載せたチャットアプリ、AIエージェント・RAG はその応用——この 3 行の地図さえ掴めば、新しいツールが出てきても置き場所に迷わなくなるのが筋です。本記事では、AI ／生成AI／ LLM の入れ子構造から、5 系統の代表 LLM、Copilot との関係、業務での法律的注意点まで、業務で OpenAI ／ Anthropic ／ Google の API を叩いている現役の生成AIエンジニア視点で整理します。

01 — 結論：LLM は「生成AIの頭脳」、ChatGPT・Claude・Gemini はその顔

📖 この章で使う用語

LLM（Large Language Model：大規模言語モデル）：ChatGPT や Claude などの「中身」を動かす、文章を予測する巨大な装置。読み方は「エルエルエム」。

生成AI（Generative AI）：文章・画像・音声などを「新しく作り出す」AI の総称。AI の大きなカテゴリの 1 つ。

AI（Artificial Intelligence：人工知能）：機械に判断・予測・生成などをさせる技術の総称。LLM・生成AI を含む最も大きい言葉。

まず結論から書きます。LLM は「文章を予測する巨大な装置」で、ChatGPT・Claude・Gemini はその装置を載せたチャットアプリです。両者の関係は、エンジンと車体の関係に近いです。エンジン単体ではドライブできません。エンジンを車体に積み、ハンドルやシートを付けてようやく、私たちが使える「車」になります。LLM も同じで、装置だけでは使えません。チャット画面、料金プラン、ログインのしくみなどを周りに付けた状態のものが、ChatGPT・Claude・Gemini です。

3 つの言葉の関係を、入れ子の図で書くと次のようになります。

[ AI（人工知能） ]
    └─ [ 生成AI（新しく作り出す AI のカテゴリ） ]
            └─ [ LLM（文章を予測する装置） ]
                    └─ [ ChatGPT / Claude / Gemini など、LLM を載せたアプリ ]

「AI」は最も大きい言葉、「生成AI」はその中の 1 カテゴリ、「LLM」はさらにその中で文章を扱う装置の名前、ChatGPT などはその LLM を使えるようにしたアプリ——という階層になっています。

私は本業で、Ruby・Python・Scala から OpenAI / Anthropic / Google の API を直接呼び出して、LLM を業務プロダクトに組み込んでいます。読者の方が日常で触っている ChatGPT・Claude.ai・Gemini アプリと、私が業務で叩いている「API（プログラムから呼び出す注文窓口）越しの LLM」は、同じエンジンを別の入口から触っているだけです。この感覚を最初に持っていただけると、本記事の以降が読みやすくなると思います。

「迷ったらこの 3 つだけ覚えれば OK」一行マップ

頭の整理用に、もう一段シンプルにします。

LLM ＝文章を予測する装置
ChatGPT・Claude・Gemini ＝それを使えるチャットアプリ
AIエージェント・RAG ＝それを土台にして組み立てた応用

この 3 行を覚えていれば、本記事の以降はすべて「この 3 行のどこに位置する話か」を地図のように追えます。

ちなみにサジェスト（Google の検索候補に出てくる単語）に並んでいる「ai」「chatgpt」「copilot」も、すべて「この 3 行のどこに当てはまる？」という疑問の言い換えです。本記事はこの疑問を、章ごとに 1 つずつ分解して整理していきます。

02 — 「LLM とは何か」をわかりやすく——大量の本を読んだ司書のたとえ

📖 この章で使う用語

パラメータ：LLM が「言葉と言葉の関係」を数値で覚えている、その数値の数。「司書の頭の中の整理棚の引き出しの数」のイメージ。

「LLM」を一番わかりやすく例えるなら、インターネット上の膨大な本・記事・文章を読み込んで覚えた、巨大な司書です。誰かが質問すると、その司書は頭の中にある膨大な記憶を参照して、「次に出てくる言葉として一番自然なものはこれだろう」と予測して、1 単語ずつ答えを書いていきます。

「Large（大きい）」「Language（言葉）」「Model（仕組み）」の 3 語を分解すると、こうなります。

Large：とにかく大きい。読み込んだ文章も、覚えている数値の数（パラメータ）も、桁外れに大きいという意味です
Language：扱う対象は「言葉」。画像や音声を扱うものは別途「画像生成 AI」「音声 AI」と呼ばれます
Model：仕組み、ひな型、模型のような意味。「言葉のふるまいを真似する仕組み」という感じです

つまり、LLM とは 「言葉のふるまいを、とにかく大量に学んだ、巨大な仕組み」 ——これだけです。難しく聞こえる名前ですが、骨組みはシンプルです。

LLM の核心：「次の単語を予測している」だけ

ここがとても大事なところなのでゆっくり書きます。LLM がチャット画面で長い文章を返してくれるとき、内部で起きているのは、「次に来る一番自然な単語を、1 つずつ予測して並べているだけ」 です。

たとえば、こちらが「今日の天気は」と打つと、LLM は頭の中で「『今日の天気は』の次に最も自然に来る言葉は何だろう」と考えて、「晴れ」「曇り」「雨」などの候補を比べ、確率の高いものを選びます。次は「晴れ」の続きとして「です」を予測し、その次は……と続けていく。これを単語 1 つずつ繰り返しているだけなのです。

私が営業時代に毎日 60 件ほどの訪問をしていた頃、お客様の話を聞きながら「次にこの方が言いそうな一言は何か」を半歩先で予測する癖を、自然に身につけていました。「いや、今回はちょっと……」が来そうな空気が読めれば、それを言わせる前に提案の角度を変えられる。LLM がやっていることは、これに近いです。膨大な会話のパターンから「次に来そうな一言」を予測する装置——そう捉えると、急に親しみが湧いてきます。

なぜ「大規模」と呼ぶのか

「Large（大きい）」と呼ぶ理由は、主に 2 つの「大きさ」があるからです。

1 つ目は 学習データの量。インターネット上の文章、書籍、論文、コードなど、人間が一生かけても読み切れない分量を、学習の段階で読み込ませています。

2 つ目は パラメータの数。これは「言葉と言葉の関係を、頭の中で覚えている数値の数」のことです。司書の頭の中の整理棚に、何百億・何千億という引き出しがあるイメージです。引き出しの数が多いほど、「あの単語が出てきたら、次にはこの単語が来やすい」という細かい関係を、たくさん覚えていられます。

ちなみに、何億・何千億という数字の正確な値は、各 LLM のバージョンによって変わりますし、最新の数字を断定的にお伝えするのは避けたいので（古くなりやすいので）、本記事では「とにかく桁外れに大きい」という肌感だけ持ち帰っていただければ十分です。

03 — LLM の具体例——「これが LLM」と指差せる 5 つの代表

📖 この章で使う用語

GPT（Generative Pre-trained Transformer）：OpenAI 社が作る LLM シリーズ名。ChatGPT の中身。

Claude（クロード）：Anthropic 社が作る LLM シリーズ名。Claude.ai の中身。

Gemini（ジェミニ）：Google 社が作る LLM シリーズ名。Gemini アプリの中身。

OSS（Open Source Software：オープンソースソフトウェア）：誰でも中身を見て、改変して、再配布できるソフトウェア。LLM では Llama や Mistral が代表例。

温度感分離の宣言

この章では、現在広く触れる代表的な LLM を 5 系統取り上げます。最初に温度感を明示しておきます。

私が業務で API を叩いているのは GPT 系・Claude 系・Gemini 系の 3 系統です。この 3 系統については自分の言葉で語ります。Llama 系・Mistral 系については、業務で本番運用したことはなく、概念・選定材料として知っているレベルなので、本記事では公開情報からの概論として紹介する扱いとして書きます。「業務で日常的に使っている人の声」と「概論として知っているレベル」を混ぜないために、最初に区別をお伝えしておきます。

これは、本ブログで一貫している運用ルールです。第14本目の「AI 画像生成無料」で UI で触れる 6 ツールに絞ったときも、第16本目の「AI 動画生成おすすめ」で Sora と Veo の 2 系列だけを業務で実際に使っているもの扱いにしたときも、同じ姿勢で書いています。

5 系統の俯瞰

系統名	開発元（会社）	読者が触れる主な入口
GPT 系	OpenAI 社（米）	ChatGPT / OpenAI API
Claude 系	Anthropic 社（米）	Claude.ai / Anthropic API / AWS Bedrock
Gemini 系	Google 社（米）	Gemini アプリ / Google AI Studio / Vertex AI
Llama 系	Meta 社（米）	Hugging Face / 自社サーバー設置
Mistral 系	Mistral 社（仏）	Hugging Face / Mistral API

「Hugging Face（ハギングフェイス）」は、OSS の LLM を配布している大型サイトの名前です。OSS 系の LLM を試したい開発者は、まずここに来るイメージです。

GPT 系（OpenAI）— ChatGPT の中身

GPT 系は、OpenAI 社が開発している LLM シリーズです。読者の方が一番触る機会の多い「ChatGPT」というアプリの中で動いているのが、この GPT 系です。バージョンは GPT-4 や、より新しい世代へと更新されていくのですが、「同じ ChatGPT という名前のアプリでも、中身のモデルバージョンは差し替わっていく」 という点だけ覚えておいてください（この話はセクション 4 で詳しく書きます）。

私は業務で OpenAI の API を、自社プロダクトに組み込んでいます。読者の方が日常で ChatGPT のチャット画面に質問を打ち込むのと同じことを、プログラムから「API という注文窓口」越しに自動でやらせている、という構図です。

ChatGPT を初めて触る方は、まずアプリでチャットを楽しむのが一番です。手順は別記事「ChatGPT 始め方」に詳しくまとめました。アカウント作成から、有料プランの判断軸まで、未経験の方を対象に書いています。

Claude 系（Anthropic）— Claude.ai の中身

Claude 系は、Anthropic 社が開発している LLM シリーズです。Web 画面で触るときは「Claude.ai」というアプリ、プログラムから呼ぶときは「Anthropic API」、企業向けに AWS 経由で使うときは「Amazon Bedrock」という入口を通します。

私は、Anthropic API を業務で日常的に叩いています。加えて、PoC（試作・検証）やコンプライアンス上の要件で、AWS Bedrock 経由で Claude を呼ぶ形も部分的に使っています。Bedrock 経由を選ぶ判断材料や、直 API との違い（IAM 連携／VPC 内通信／コスト体系）は、概念レベルで自分の言葉で語れます。一方、Bedrock 経由の細かい料金最適化テクニックは、私の常用パターンではないため、本記事では深掘りしません。

Claude を初めて触る方向けには、別記事「Claude 使い方」に Claude.ai のアカウント作成から、Projects・Artifacts といった日常使いの機能まで書いています。料金プランで迷う方には「Claude 料金プラン」で Free → Pro → Max の段階推奨もまとめました。

Gemini 系（Google）— Gemini アプリの中身

Gemini 系は、Google 社が開発している LLM シリーズです。読者の方が触る入口は、スマホやブラウザの「Gemini アプリ」、開発者向けの「Google AI Studio」「Vertex AI」などです。

私は Gemini も API 経由で業務利用しています。GPT 系・Claude 系と並べて、用途によって使い分けています。ある場面では GPT 系がいい、別の場面では Claude が手堅い、また別の場面では Gemini が向く——という肌感は実際にあります。ただし「どの場面でどの LLM が一番か」は、扱うデータ、求める出力の精密さ、社内のコンプライアンス要件などで変わるため、本記事では一般化しないでおきます。

Llama・Mistral 系（OSS）— 自分の PC や社内サーバーに置く選択肢

Llama（Meta 社）・Mistral（Mistral 社）は、いずれも OSS として配布されている LLM です。OSS というのは、ざっくり言うと「中身を見て、改変して、再配布できる」ソフトウェアです。

OSS の LLM を選ぶ最大の動機は、自社のサーバーや自分の PC に置いて、外部にデータを送らずに動かせることです。社内の機密情報を外に出さずに LLM を使いたい、というニーズに刺さります。

ただし、運用ハードルは商用 API と比較して高めです。サーバーを用意し、モデルファイルをダウンロードし、推論用のソフトウェアを構築し、メンテナンスを続ける——これらの工数を見積もる必要があります。私自身、業務で Llama・Mistral 系を本番運用したことはなく、本記事では「そういう選択肢がある」「商用 API と分けて考えるとよい」という概念レベルでの紹介にとどめます。

ライセンス条件についても、Llama 系は商用利用の範囲に細かい条件があります（モデルバージョン・利用規模で条件が変動）。使い始める前に、必ず最新の公式ライセンス条項を確認してください。

04 — ChatGPT と LLM の関係——プロダクトとエンジンの整理

📖 この章で使う用語

API（Application Programming Interface）：プログラムから LLM を呼び出すための「注文窓口」。お店のレジで使う注文票のイメージ。

モデルアップデート：LLM の中身が新しいバージョンに差し替わること。同じ ChatGPT という名前でも「中で動く GPT-4 → GPT-5」のように変わる。

サジェストの「llm とは chatgpt」を直球で受け止める章です。結論から書きます。

ChatGPT は LLM ではありません。ChatGPT は GPT 系 LLM を載せたチャットアプリです。

セクション 1 でも書いた通り、エンジンと車体の関係です。GPT-4 や GPT-5 と呼ばれているのが「エンジン（LLM 本体）」、ChatGPT というアプリが「車体（エンジンを載せたユーザー向け製品）」です。

表で整理——会社名 / LLM 名 / アプリ名 / API 経由の名前

3 大プロバイダの関係を表で整理します。

会社	LLM シリーズ名（エンジン）	チャットアプリ名（一般ユーザー向け）	プログラムから呼ぶ API 名
OpenAI	GPT シリーズ	ChatGPT	OpenAI API（gpt-4 等のモデル名指定）
Anthropic	Claude シリーズ	Claude.ai	Anthropic API（claude-3, claude-4 等）
Google	Gemini シリーズ	Gemini アプリ	Google AI Studio / Vertex AI

ここで混乱しやすいのが、会社名・モデル名・アプリ名が似た名前で並んでいることです。Google の場合は「Gemini」が会社の中での LLM 名でもあり、アプリ名でもあるので、特にややこしいです。

私が業務で API 越しに呼ぶときは、たとえば「claude-sonnet-4-5 という具体的なモデル名」を指定して呼びます。ところが Claude.ai のチャット画面で同じ会社のサービスを使うときは「Claude」というアプリ名でしか意識しません。「裏ではモデル名で呼んでいる」「表ではアプリ名で見ている」、この二重構造があることだけ覚えておくと、業界の用語が一気に理解しやすくなります。

ChatGPT の「中身」が変わるとは？

ニュースで「ChatGPT が更新されました」「GPT-X がリリースされました」という記事を見たことがあると思います。これは、ChatGPT というアプリの名前は同じまま、中身の LLM がバージョンアップされたという意味です。

たとえば、ある時期は ChatGPT の中で GPT-4 が動いていて、新しい世代が出るとそれに差し替わる——というイメージです。アプリ名は変わりませんが、内部のエンジンが新しくなっています。

この 「アプリ名は同じ・エンジンは差し替わる」 の構造は、業務で API を使うときに重要になります。プログラム側で「gpt-4 を呼ぶ」と書いておくと、新世代が出た日に自動で切り替わるわけではありません。コードを更新して「gpt-5 を呼ぶ」に書き換える必要があります。一方、一般ユーザーが使う ChatGPT アプリの方は、提供側が裏で差し替えれば、ユーザーは意識しないままバージョンアップを受け取れる、という違いがあります。

05 — GitHub Copilot と LLM の関係——コード補完特化型のたとえ

📖 この章で使う用語

コード補完：エディタで文字を打ちかけたところに「続きはこうですか？」と AI が提案してくれる機能。Excel の「オートコンプリート」を、プログラミング全体に広げたイメージ。

エディタ：プログラマーがコードを書くためのソフトウェア。Word のような文書作成ソフトの、プログラム向け版。

サジェスト「llm とは copilot」を直球で受け止める章です。これも結論から書きます。

Copilot は LLM そのものではありません。Copilot は、LLM をコード補完用にチューニングしてエディタに常駐させたプロダクトです。

「LLM はエンジン、Copilot はそのエンジンを使う作業空間の 1 つ」——このイメージで分けて理解していただくと、混乱しません。

GitHub Copilot — エディタの中の補完アシスタント

GitHub Copilot は、エディタ（Visual Studio Code など）で文字を打ちかけたところに、AI が「続きはこうですか？」と提案を出してくれるツールです。中身としては、OpenAI 系の LLM がベースになっており、最近のバージョンでは Anthropic の Claude や Google の Gemini もユーザーが選べるようになっています。

私は GitHub Copilot を業務で使っています。コードを書くスピードは確かに上がりましたし、定型的なロジック（ループの書き方、ライブラリの呼び出し方など）は、ほぼ補完任せで書けます。ただし、「Copilot の提案を丸呑みするのではなく、自分の頭で 1 回読んで判断する」 という姿勢は、いまでも大事にしています。新人エンジニアの頃に書いた「動きはするけど読めないコード」のままを Copilot に量産させるのは、後の自分やチームに迷惑をかけることになるので。

エディタで使う AI アシスタント全般については、別記事「Claude Code 使い方」「Cursor 使い方」もまとめています。Copilot・Claude Code・Cursor の三者は、それぞれ立ち位置が違うので、興味のある方は併読してみてください。

Microsoft 365 Copilot — Excel・PowerPoint の中の AI（公開情報からの概論として紹介する扱い）

ここで一点、非エンジニア読者の方が混乱しやすい話を整理します。

「Copilot」という名前のついた製品は、実は複数あります。

GitHub Copilot：エディタの中で動くコード補完ツール
Microsoft 365 Copilot：Excel・Word・PowerPoint・Outlook・Teams などのオフィス製品の中で動く AI 機能
Copilot in Windows：Windows OS の中に組み込まれたチャット型 AI 機能

これらはすべて Microsoft が出している「Copilot ブランド」の製品群ですが、用途も中身も別物です。GitHub Copilot はコード補完用、Microsoft 365 Copilot は文書・表計算・スライド作成用、Copilot in Windows は OS 全般の操作補助用、という具合です。

Microsoft 365 Copilot や Copilot in Windows は、私が業務で本番運用しているわけではないので、本記事では公開情報からの概論として紹介する扱いとして紹介にとどめます。詳しい使い方は、各製品の公式ガイドをご覧ください。

ここでお伝えしたかったのは、「Copilot ≠ 1 つの製品」 であり、ニュースで「Copilot」と出てきたら 「どの Copilot の話だろう？」 と一度立ち止まる癖をつけると、混乱が減るということです。

06 — AIエージェント・RAG・チャットボットと LLM の関係——応用の地図

📖 この章で使う用語

RAG（Retrieval-Augmented Generation：検索拡張生成）：LLM が答える前に、外部の資料を検索して根拠を持たせる仕組み。営業時代の「お客様の質問 → 商品カタログを引く → 提案する」と同じ手順。

AIエージェント：LLM に「目的」と「使ってよい道具」を渡して、自律的に手順を考えて動かす仕組み。

チャットボット：LLM をチャット UI に載せた、最もシンプルな応用。

LLM を土台として、その上に乗っかる応用パターンが、いま大きく 3 つあります。チャットボット・RAG・AIエージェントです。それぞれ「何を足し算しているか」で区別すると、頭に入りやすいです。

応用パターン	構成	一言で
チャットボット	LLM ＋チャット UI	最もシンプル。ChatGPT などのチャット画面そのもの
RAG	LLM ＋外部の資料検索	社内ドキュメントや商品カタログを参照させて答えさせる
AIエージェント	LLM ＋道具を使う能力	目的を渡すと、自分で手順を考えて道具を使い分けて動く

チャットボット — 最もシンプルな LLM 応用

チャットボットは、LLM を「人とチャットで会話する」という形だけで使うパターンです。ChatGPT・Claude.ai・Gemini アプリも、本質的にはこのチャットボットの代表例です。

業務で「自社プロダクトの中にチャット相談窓口を作りたい」という場合は、LLM の API を呼び出して、画面のチャット欄に答えを出す——というシンプルな構造で実現できます。私自身、業務プロダクトにチャットボットを組み込んだ経験があります。

RAG（検索拡張生成） — LLM ＋外部知識

RAG は、LLM が答える前に「外部の資料を検索して、見つけた情報を根拠にして答える」 という仕組みです。

なぜこれが必要かというと、LLM 単体は 学習を打ち切った日付までの知識しか持っていない からです（セクション 7 で詳しく書きます）。自社の社内ドキュメント、商品カタログ、最新のニュースなどは、学習データに入っていません。これを「都度検索して、検索結果を LLM に渡してから回答させる」のが RAG です。

営業時代を思い出すと、お客様から商品の細かい仕様を質問されたとき、私は手元の商品カタログをめくって、該当ページを開いて、その情報を見ながら答えていました。RAG はちょうどこれと同じことを LLM にやらせている、と理解していただければ正確です。「LLM の頭の中だけで答えない」「外部の資料を引いて、その内容を根拠にして答える」という運用です。

私は業務で RAG を構築した経験があります。実装の中では LangChain・LangGraph といったライブラリを部分的に使ったり、用途によっては Anthropic / OpenAI の公式 SDK と自前パイプラインの組み合わせで組んだりしています。ベクトル DB（意味的に近いテキストを素早く取り出せる検索データベース）も、業務では FAISS・Chroma・Weaviate を使ってきました。詳しい RAG の構造や、なぜ必要なのかは別記事「RAG とは」に書きました。本記事では「LLM の応用としてこういう形がある」というところで止めておきます。

AIエージェント — LLM ＋ツール実行能力

AIエージェントは、LLM に「目的」と「使ってよい道具」を渡すと、LLM が自分で手順を考えて道具を使い分けて、ゴールに向かって動く 仕組みです。

たとえば「来週の出張の航空券を、東京→大阪、火曜午前出発で予約しておいて」というゴールを渡すと、エージェントは「予約サイト検索」「在庫確認」「カート追加」「決済」などの道具を順番に使って、ゴールに向かいます。RAG が「外部の資料を検索して答える」までを担当するのに対し、エージェントは 「答えるだけでなく、行動する」 ところまで踏み込むイメージです。

私は業務で AIエージェントを組み込んだプロダクトを開発した経験があります。詳しい構造、なぜ必要か、どんな道具を持たせるか、は別記事「AIエージェントとは」に書きました。本記事の地図としては「LLM ＋道具＝ AIエージェント」とだけ整理しておきます。

実装に踏み出す側（自分で作る側）に回るときは、別記事の AIエージェント作り方で 4 ルート（Python + LangChain / ノーコード / Microsoft Copilot Studio / Claude Projects・GPTs）を業務で実際に使っている範囲で整理しました。LLM の最大の応用例なので、流れで読まれると射程が伸びます。

07 — LLM が「できること・できないこと」——ハルシネーション含む

📖 この章で使う用語

ハルシネーション：LLM が「事実でないこと」を、自信満々で本当のように書いてしまう現象。新人時代に「分からないと言えなくて、適当に答えてしまった日」のイメージ。

モデルカットオフ：LLM が学習を打ち切った日付。それ以降のニュース・新発売の製品などは知らない。

LLM は万能ではありません。「得意なこと」と「苦手なこと」をはっきり分けて頭に入れておくと、業務で使うときの判断がぶれません。

できること 7 つ（実務での頻度順）

私が業務で日常的に LLM にお願いしている作業を、頻度の高い順に書きます。

要約：長い議事録・記事・ドキュメントを短くまとめる
翻訳：英語の OSS ドキュメントやニュースを日本語に置き換える
文章生成：メールの下書き、提案書の骨子、ブログ記事の素案を作る
コード補完：エディタで打ちかけたコードの続きを提案させる（Copilot などの応用）
質問応答（一般知識）：「○○ってどういう意味？」程度の質問に答える
アイデア出し：「この企画のタイトル案を 10 個出して」のような壁打ち
構造化：箇条書きの羅列を、表や見出し付きのフォーマットに整える

これらは、いずれも 「文章の中で完結する作業」 です。LLM の本質が「次の単語を予測する装置」である以上、文章で表せる作業との相性が抜群によく出ます。

できないこと・苦手なこと 5 つ

一方、苦手領域もはっきりしています。これを知っておかないと、業務で痛い目に遭います。

最新の情報：学習データの締切以降のニュース・新製品・新法律などは知りません
事実の保証：それっぽい文章は作りますが、書かれている内容が事実かどうかは別問題（ハルシネーション、後述）
数値計算の精度：単純な四則演算でも、間違える可能性があります（電卓に任せた方が確実）
社内ドキュメントの参照：自社の機密資料は学習に含まれないため、何も知りません（→ RAG が必要）
物理世界の操作：ロボット制御や、現実世界のセンサー読み取りはできません（応用の組み合わせで可能になることはありますが、LLM 単体ではできません）

これらは LLM の構造上の限界です。「次の単語を予測する装置」で何でもできると考えると、必ずどこかで裏切られます。

ハルシネーション——LLM 最大の落とし穴

ハルシネーション（hallucination：幻覚）は、LLM が「事実でないこと」を、自信満々で本当のように書いてしまう現象のことです。

たとえば、実在しない論文を「○○年に発表された△△という論文によると……」と引用したり、実在しない人物を「□□氏が著書で述べているように……」と書いたりする。一見もっともらしいので、知らない人が読むと信じてしまいます。

新人エンジニアになった頃の私は、上司やお客様から専門的な質問をされたとき、「分かりません」と言えずに、知ったかぶりで適当に答えてしまうことが何度かありました。後で間違いがバレて、信頼を失う——あれと似た現象が、LLM にも構造的に起きます。「予測する装置」である以上、もっともらしい予測が事実と一致するとは限らないのです。

業務で LLM を使うときの基本姿勢は、「LLM の出力を、人間が一度読んで判断する」 ことです。要約・翻訳・骨子作りなど、最終的に人間が責任を持つ前提の作業なら、効率を大幅に上げられます。一方、「正確性が絶対に問われる場面（医療情報・法律相談・財務数値など）」では、LLM の出力をそのまま使うのは避けた方がよいと、私は考えています。

08 — LLM の仕組みをざっくり——技術用語ゼロで（オプション、軽め）

📖 この章で使う用語

Transformer（トランスフォーマー）：2017 年に登場した、現代の LLM のほとんどが使っている内部構造の名前。アテンションという仕組みで「文の中のどの単語に注目するか」を決める。

トークン：LLM が言葉を数える単位。日本語ではおおむね 1 文字 = 1〜2 トークン。API 料金はこの単位で計算される。「タクシーのメーター」のイメージ。

アテンション（注意機構）：文の中で「どの単語が他のどの単語と関係が深いか」を計算する仕組み。

この章は 「仕組みまで知りたい方向け」 の補足です。読み飛ばしてセクション 9 に進んでも、本記事の流れは追えます。

技術用語を最低限に絞って、LLM が動く流れを 3 段階に分けます。「料理人が膨大なレシピを覚え、お客様の注文に合わせて即興で皿を組む」というアナロジーで進めます。

学習——大量の文章を読ませる工程

まず、LLM を作るときには 「大量の文章を読み込ませる」 工程があります。これを「学習」と呼びます。インターネット上の文章・書籍・コードなどを、何百ギガ・何テラといった単位で読み込ませて、「ある単語の後には、どんな単語が来やすいか」を、ひたすら数値で記録していきます。

料理人で例えるなら、修行時代に「世界中の料理本を読み、何万食もの料理を実際に作って、何が美味しい組み合わせかを体に染み込ませる」という工程です。この工程は、巨大な計算機を何ヶ月も走らせるような、桁外れに大きな仕事になります。

推論——質問されたときに動く工程

学習が終わった LLM は、ユーザーから質問を受け取ると 「推論（inference）」 という工程で答えを返します。これは、修行を終えた料理人が、お客様の注文を聞いて、頭の中のレシピを参照しながら即興で皿を組み立てるイメージです。

ユーザーが「今日のおすすめは？」と聞くと、LLM は「『今日のおすすめは』に続いて最も自然な単語」を予測し、「○○です」と返す。次に「○○について詳しく教えて」と聞かれると、また「次に来る自然な単語」を予測して、文章を組み立てていきます。

私たちがチャット画面で文章のやり取りをしているとき、裏では、このような 「学習で覚えた関係を使って、リアルタイムに単語を予測する」作業 が行われています。

トークン——LLM が言葉を数える単位（API 料金にも直結）

LLM は、言葉を 「トークン」 という単位で扱います。これは、LLM が「ひとかたまりとして処理する文字の単位」です。

英語ではおおむね「1 単語 = 1〜2 トークン」、日本語ではおおむね「1 文字 = 1〜2 トークン」が目安です（モデルや日本語特化の有無で多少変動します）。

このトークンが、API を使うときの 料金単位 にもなっています。たとえば「入力：1,000 トークンあたり◯円」「出力：1,000 トークンあたり◯円」という料金体系で、各社が API 料金を設定しています。タクシーのメーターと同じイメージで、長く話せば話すほど、料金が積み上がる 構造です。

業務で API を使うときは、トークン数を意識した設計が大事になります。プロンプトを必要以上に長くしない、出力上限を設けるなど、料金とのバランスを考えながら組みます。詳細な料金プランの整理は別記事「Claude 料金プラン」にもまとめました。

Transformer・アテンションは、興味のある方だけ

ここから先は、技術書ぽい話になるので、興味のある方だけ読んでください。

現代の LLM のほとんどは、2017 年に登場した Transformer という内部構造を使っています。Transformer の中核には アテンション（注意機構） という仕組みがあり、これは「文の中で、どの単語が他のどの単語と関係が深いか」を計算する仕組みです。

たとえば「私は昨日カフェに行った。そこで本を読んだ」という文の「そこ」が、「カフェ」を指していると判断できるのは、このアテンションの働きです。文中の単語同士の関係性を、数値で計算して取り扱っているのです。

私自身、LLM を業務で 「使う側」 のエンジニアであり、Transformer の内部実装を研究している立場ではありません。本記事で扱う範囲としては、「Transformer という構造で動いている」「アテンションが核心」とだけ知っておいていただければ十分です。深く学びたい方は、各 LLM プロバイダの公式ドキュメントや、論文「Attention Is All You Need」（2017）を出発点に進んでみてください。

09 — 業務で LLM を使うときの法律・著作権の注意——メタ否定と法務委ね

📖 この章で使う用語

利用規約：サービス提供者が定める「使い方のルール」。商用利用可否・データの扱いなどはここに書かれている。変更頻度が高いので必ず最新版を確認する。

エンタープライズ経路：AWS Bedrock や Azure OpenAI Service など、企業向けに監査・契約・データ保護を強化した LLM 利用ルート。社内の機密情報を扱う業務で選ばれる。

サジェスト「llm とは法律」を受ける章です。最初に、最も大事な前置きをします。

私は弁護士でも法律家でもありません。本章は「現役の生成AIエンジニアとして、業務で気をつけている観点」のみを共有します。最終的な法律判断は、必ず社内の法務・コンプライアンス部門、必要に応じて弁護士の方にご相談ください。

LLM を業務で使い始めるときの法律論点は、変動が激しく、また個別事案で判断が分かれます。本記事で「絶対安全」「必ず合法」「これで商用利用可」と断定することは、いっさいできません。本章でお伝えするのは、私が業務で実際に運用している「事前に必ず確認している観点」のみです。

5 つの観点（学習データ／商用利用／機密情報／OSS ライセンス／規制動向）

業務で LLM を使い始めるときに、私が「最低限ここは事前に確認している」観点を 5 つ挙げます。それぞれ深入りはせず、観点だけ提示します。

観点 1：学習データの著作権

LLM の学習データに、第三者の著作物がどの程度含まれているかは、各プロバイダの説明や、世の中の議論を見ても、まだ整理が続いている状況です。生成された文章が、特定の他者の著作物に似てしまった場合のリスクをどう扱うか——これは個別事案で判断が分かれ、本記事で一律の答えを出せる領域ではありません。

業務で使う前に、社内法務に確認することをおすすめします。

観点 2：生成物の商用利用

各 LLM サービス（ChatGPT・Claude・Gemini など）の 利用規約 には、生成された文章・画像などを商用利用してよいか、その条件は何かが記載されています。

ここで大事なのは、利用規約は頻繁に更新される ということです。半年前に確認した内容が、今日も同じとは限りません。業務で商用利用するのであれば、毎回、最新版を確認 する運用にしておくのが安全です。

観点 3：機密情報・個人情報の入力

これは私が最も慎重に扱っている観点です。

社外の LLM サービスに入力したデータは、原則として「社外に出した」と同等の扱いになる と考えるのが、安全側の判断です。各サービスは「入力データを学習に使わない」オプションを提供している場合もありますが、その設定が正しく効いているか、契約上どこまで保証されるかは、社内の情報セキュリティ部門・法務部門と一緒に必ず事前確認が必要です。

社内の機密情報を扱う業務では、エンタープライズ経路（AWS Bedrock、Azure OpenAI Service、Vertex AI Enterprise など）を選択肢として検討することが多いです。これらは、企業向けに契約条件・データ取り扱い・監査要件を強化したルートです。私自身、業務の一部で AWS Bedrock 経由で Claude を呼ぶ運用をしています（セクション 3 で触れた通り）。ただし、エンタープライズ経路を使えば自動的に安全になるわけではなく、契約内容・運用設計を社内法務と一緒に確認する必要があります。

業務効率化全般のツール選びと、セキュリティの観点については、別記事「AI 業務効率化ツール」にも整理しました。

観点 4：OSS LLM のライセンス

Llama・Mistral などの OSS 系 LLM を業務で使う場合、それぞれ ライセンス条項 があります。Llama 系であれば、商用利用の規模に応じた条件がある場合があり、こちらもバージョン・配布形態によって変動します。

OSS だから自由に使える、という単純化はせず、必ず使うバージョンの最新ライセンス条項を確認 することをおすすめします。

観点 5：AI 規制の動向

世界の AI 規制は、いま動きが激しい領域です。EU の AI Act、日本国内のガイドライン、各国の対応など、論点が次々と更新されています。

本記事で「現在の規制内容」を断定的にお伝えするのは、明日には古くなる可能性が高いため、避けます。業務で本格的に LLM を使い始める前に、最新の一次情報（経産省・総務省・内閣府の AI 関連ページ、EU の公式 AI Act ページなど）を確認してください。

「業務で使い始める前に必ずやる 3 つ」

5 観点を踏まえて、私が業務で LLM を新しく使い始めるときに、社内で必ずやっている 3 つのステップを共有します。

規約確認：使う予定の LLM サービスの利用規約・データ取り扱いポリシーを、最新版で読む
社内承認：法務・情報セキュリティ・コンプライアンス部門のいずれか（あるいは全部）に、計画を共有して承認をもらう
運用ルール文書化：社内で「何を入力してよいか／何を入力してはいけないか／生成物のチェック手順」を文書化して、関係者全員で共有する

これらは、私の所属組織で実際に運用しているプロセスです。組織の規模・業界・取り扱うデータの機密度によって、必要なステップは変わります。最終的な運用設計は、必ず社内の専門部門と一緒に組み立ててください。

繰り返しになりますが、本章はあくまで「業務で LLM を使う一エンジニアとして気をつけている観点」の共有です。法的判断は法律の専門家に、お願いします。

10 — 非エンジニアが LLM を使うユースケース 5 本——営業・事務・個人事業主・副業ライター・エンジニア

📖 この章で使う用語 （前章までで主要用語は出尽くしています。新規用語はありません）

ここまでで、LLM の概念・種類・関係・できること・法律の注意点を一通り見てきました。最後に、職種別に「具体的にどう使えるか」を 5 本のユースケースで整理します。

最初に温度感を明示します。私自身は営業 7 年 → SES → 自社開発エンジニアという経歴で、現在は生成AIエンジニアとして AI 活用の全社推進を担当しています。営業時代の業務感覚と、現職での全社推進の感覚は自分の言葉で語れます。一方、銀行員や医師など、profile に書かれていない職種のユースケースを具体的に書くことは控えます。本章では「営業」「事務」「個人事業主」「副業ライター」「エンジニア」の 5 職種を扱います。

各ユースケースは Before / After / 所要時間 / 最初の壁の 4 要素で整理します。

1. 営業職：商談メモから提案書骨子の生成

Before：お客様訪問の後、ホワイトボードや手書きメモを見返して、翌朝に提案書の骨子を 30〜40 分かけて整理する。 After：商談メモを LLM のチャット画面に貼り付けて、「これを提案書の骨子に整理して。お客様の関心ポイント、提案する 3 つの軸、想定される反論への対応」と頼むと、5 分で骨子が出てきます。 所要時間：1 商談あたり 5 分前後（メモを貼って、出てきた骨子を読んで判断する時間）。 最初の壁：何を貼り付ければよいかの取捨選択。社外秘の情報、特定可能な個人名は、原則貼り付けません（セクション 9 参照）。

これは LLM の 「構造化能力」 を使ったユースケースです。営業時代の私だったら、毎日の日報・週報の下書きにも使っていたと思います。

2. 事務職：定型メールの下書き生成（10 パターンを 1 つのテンプレで）

Before：「請求書送付の案内」「会議出席依頼」「資料送付の御礼」など、定型メールを送るたびに、過去メールから似たものを探してコピペし、固有名詞を書き換える。1 通あたり 5〜10 分。 After：「件名と相手の役職と要件」を LLM に伝えると、丁寧な定型メールが 30 秒で出てきます。1 つのプロンプト型を覚えれば、10 パターンの定型メールを使い分けられます。 所要時間：1 メールあたり 30 秒〜2 分（出力を読んで、固有名詞だけ書き換える時間）。 最初の壁：固有名詞・社外秘部分のマスキング。お客様名・社内固有の案件番号などは、LLM に渡す前に「○○社さま」「△△プロジェクト」のように置換する運用が安全です。

これは LLM の 「文章生成能力」 を、定型業務に当てた例です。

3. 個人事業主：請求書テンプレ・業務マニュアルの初稿生成

Before：請求書のフォーマット、業務マニュアル、お客様向けの説明資料などを、ネット検索で雛形を探してきて、自分の業務に合わせて書き換える。1 つあたり 1〜2 時間。 After：「自分の業務内容（屋号・取り扱い商品・取引条件など）」を LLM に伝えると、自分の業務に合わせた初稿が 10 分前後で出てきます。それを読んで、必要な部分だけ手で直す。 所要時間：10 分前後（出力を読んで、業務に合わせて加筆する時間）。 最初の壁：屋号・取引先名・税率などの 入れ忘れチェック。LLM は「もっともらしい雛形」を作るのが得意ですが、自分の業務に固有の細かい部分は、出力後に必ず人間が確認する必要があります。

これは LLM の 「文章生成」＋「構造化」 を組み合わせたユースケースです。

4. 副業ライター：構成案出し・見出し設計の壁打ち相手

Before：記事の構成案を考えるのに、1 人で 3 時間くらい唸る。見出しが思いつかず、書き始められない日もある。 After：「テーマ・想定読者・記事の目的・字数」を LLM に伝えて、「構成案を 3 案出して」と頼む。30 分で 3 案出てきて、その中から自分の方向性に合うものを選んで、肉付けしていく。 所要時間：30 分前後（構成案を出させて、選んで、自分の方向性で肉付けする時間）。 最初の壁：LLM が出した構成案を 「丸呑みしない」判断軸。LLM の出力は「世間で見かけそうな構成」を出してくる傾向があり、独自の切り口は人間が足す必要があります。

これは LLM の 「アイデア出し」＋「構造化」 のユースケースです。ライターの方は、見出し設計を AI に丸投げするのではなく、壁打ち相手として使う のがしっくり来やすいと思います。

5. エンジニア：コードレビュー観点の抜け漏れチェック

Before：自分が書いたコードを、レビュー依頼に出す前に、抜け漏れがないか自分で見直す。経験が浅いと、見落としが多い。 After：書いたコードを LLM に渡して、「コードレビュー観点で、考えられる抜け漏れを 10 個指摘して」と頼む。AI の指摘から、本当に必要なものを取捨選択して、自分で修正してから人間レビューに回す。 所要時間：2〜5 分（コードを貼って、指摘を読んで判断する時間）。 最初の壁：機密コードの取り扱い規約確認。社内コードを外部 LLM に貼ってよいかは、セクション 9 で書いた通り、社内ルールで事前確認が必要です。エンタープライズ経路を整えている会社なら、その経路を使う運用になります。

これは私が業務でいちばん推進実感のある領域でもあります。コードレビューの 1 次チェックを AI に通してから、人間レビューに回す——という流れは、レビュアーの負担を下げ、レビュー前の自分のセルフチェック品質も上げる、両方の効果がありました。

5 本に共通する姿勢

5 本のユースケースに共通して言えることは、「LLM の出力を、人間が一度読んで判断する」 という姿勢です。LLM は得意な作業（要約・生成・構造化・アイデア出し）を高速にやってくれますが、最終的な責任は人間が持つ——この前提を崩さないでいる限り、業務効率化の効果は素直に大きく出ます。

職種別の業務効率化の話は、業務事例の側面から「AI 業務効率化事例」、ツール選定の側面から「AI 業務効率化ツール」にもまとめました。本記事と併せて読むと、「概念（LLM）→ 事例 → ツール選定」の流れで頭に入りやすいと思います。

11 — 学習の最初の一歩——営業出身の私が、未経験読者に薦める順番

📖 この章で使う用語

無料版／有料版：ChatGPT・Claude・Gemini いずれも無料で試せる範囲と、月額有料で使える機能の幅がある。料金プランの整理は別記事へ送り。

ここまで LLM の概念から業務利用までを一気通貫で見てきました。最後に、「これから LLM を学び始める方に、私だったらこういう順番をお薦めします」 という個人的な提案を 3 ステップで書きます。

最初にお断りしておくと、これは 「私の場合は」 の話です。「絶対この順番がいい」と一般化するつもりはありません。読者の方の生活・職場環境・興味の方向によって、最適な順番は変わります。あくまで「営業出身で、未経験から SE になり、現在生成AIエンジニアをやっている人間の、いち提案」として読んでいただければと思います。

ステップ 1：触る（最初の 1 週間）

最初の 1 週間でやることは、たった 1 つです。

ChatGPT または Claude.ai の無料版に登録して、毎日「業務の文章を貼り付ける」だけを続ける。

要約させてもいい、英訳させてもいい、メールの下書きを作らせてもいい。とにかく、自分の業務で発生する文章を、毎日チャット画面に貼り付けて、何が返ってくるかを見る。これだけです。

最初の 1 週間で、「あ、ここは AI に任せられる」「あ、ここは AI ではダメで人間がやった方がいい」という肌感が、自然にできてきます。この 肌感を体で覚える ことが、本やドキュメントを読むより圧倒的に大事です。

具体的な始め方は、別記事「ChatGPT 始め方」「Claude 使い方」にまとめました。アカウント登録の手順から、最初の触り方まで、未経験の方向けに書いています。

ステップ 2：使い分ける（次の 1 ヶ月）

1 週間触ってみて、AI とのやりとりに慣れてきたら、次のステップです。

ChatGPT・Claude・Gemini の 3 つを順番に試して、自分の業務にいちばんハマるものを 1 つ選ぶ。

私の業務での肌感では、3 つは確かに少しずつ得意領域が違います。ある場面では Claude が手堅く、別の場面では ChatGPT がスピード重視で出してくれ、また別の場面では Gemini がしっくり来る。「全部使え」では学習が大変 なので、まず 1 つに絞ってメインで使い込むのがおすすめです。

このタイミングで「無料版で十分か、有料版に課金するか」を判断する場面が来ます。料金プランの考え方は、Claude を例に取った別記事「Claude 料金プラン」で、Free → Pro → Max の段階推奨と判断軸を書きました。ChatGPT・Gemini も基本的な考え方は似ています。

ステップ 3：広げる（その後、必要に応じて）

メイン 1 つで業務効率化が回り始めたら、次は応用に広げていく段階です。

チームに広げる：自分の業務で効いた使い方を、同じ部署のメンバーに展開する
応用パターンを知る：AIエージェント・RAG・チャットボットなど、LLM の応用形を学ぶ（「AIエージェントとは」「RAG とは」）
業務効率化の他の事例を見る：「AI 業務効率化事例」「AI 業務効率化ツール」で、他の職種・他のツールの組み合わせを知る

この「広げる」フェーズは、業務やキャリアの方向によって、進める範囲・スピードが大きく変わります。「最低限ステップ 2 まで身につけておけば、当面の業務には十分」というのが、私の実感です。

最初の壁を、正直に書いておく

3 ステップを通じて、ぶつかる壁は主に 3 つです。

登録の心理的抵抗：「クレジットカードを登録するのが怖い」「個人情報を入れるのが不安」。これは無料版だけならクレジットカード不要のサービスもあります（各サービスの最新情報を公式で確認してください）
英語 UI への抵抗：一部の機能は英語のままです。少しずつ慣れていくしかないですが、ブラウザの翻訳機能を組み合わせると、ハードルが下がります
料金プランの不安：有料版を試すか迷う場面で、料金体系が複雑に感じる場合があります（特に従量課金の API）。月額固定のサブスクリプション（Pro / Max など）から入る方が、最初は予算管理しやすいです

これらは、未経験から触り始めた方の多くがぶつかる壁です。「壁にぶつかるのは普通」 くらいの心持ちで進むのが、結果的に長く続きます。

もし「いずれエンジニアにキャリアを広げてみたい」と感じる方は、私の経歴を素材に書いた別記事「未経験エンジニア転職」もあります。営業 → SE のキャリア転換の話なので、AI を業務で触る話とは別軸ですが、興味があれば覗いてみてください。

12 — よくある質問

Q1: LLM と AI、生成AI、ChatGPT の違いを 1 行で教えてください

A. AI は最も大きい言葉、生成AI はその中の「新しく作り出す AI」のカテゴリ、LLM は生成AI の中で「文章を予測する装置」、ChatGPT は LLM を使えるようにしたチャットアプリです。「AI ＞生成AI ＞ LLM」の入れ子で、ChatGPT・Claude・Gemini は LLM を載せたアプリの代表例です。

Q2: 業務で LLM を使うのは、法律的に大丈夫ですか？

A. 「絶対大丈夫」とは申し上げません（私は弁護士ではありません）。一般論として注意すべき観点は (1) 利用規約の最新版確認、(2) 機密情報・個人情報を入力しない運用ルール、(3) 生成物の商用利用条件の確認、(4) OSS LLM 使用時のライセンス条項の 4 つです。最終的な法律判断は必ず社内法務部門・コンプライアンス部門、必要に応じて弁護士の方にご相談ください。

Q3: LLM の種類は何種類くらいありますか？

A. 商用サービスとして広く触れる代表は 5 系統（GPT・Claude・Gemini・Llama・Mistral）です。私が業務で API 経由で叩いているのは GPT・Claude・Gemini の 3 系統で、Llama・Mistral 系は OSS 中心のため本記事では公開情報からの概論として紹介する扱いとして触れています。詳細はセクション 3 をご参照ください。

Q4: GitHub Copilot は LLM ですか？それとも違いますか？

A. Copilot は LLM そのものではなく、LLM（OpenAI 系がベース、最近は Claude や Gemini も選べる）をコード補完用にチューニングしてエディタに組み込んだプロダクトです。「LLM はエンジン、Copilot はエンジンを使う作業空間の 1 つ」というイメージで分けて理解すると混乱しません。Microsoft 365 Copilot や Copilot in Windows など、同名の別製品もあるので、ニュースで「Copilot」と出てきたら「どの Copilot か」を一度確認するのがおすすめです。

Q5: LLM を勉強し始めるなら、最初の一歩は何をすればいいですか？

A. 私の場合は「触る → 使い分ける → 広げる」の 3 ステップをお薦めします。まず ChatGPT または Claude.ai の無料版に登録し、1 週間「業務の文章を貼り付ける」だけを続ける。次に ChatGPT・Claude・Gemini を試して自分の業務に合うものを 1 つ決める。最後に AIエージェント・RAG などの応用や、チームへの展開へ広げる——という順序です。詳細はセクション 11 をご参照ください。

13 — まとめ——LLM を「文章を予測する司書」として味方にする

長くお付き合いいただき、ありがとうございました。最後に、本記事の要点を 3 行に圧縮します。

LLM は道具です。「文章を予測する装置」というシンプルな核を理解すれば、ChatGPT・Claude・Gemini・Copilot・AIエージェント・RAG までの関係が、入れ子の地図として整理できます
業務利用は、規約・法律・機密情報の確認とセットです。便利さに目を取られて、社内ルールと法的観点を後回しにすると、後でつらいことになります。社内の専門部門と一緒に運用設計するのが安全です
学習の最初は「触る」からです。理論書を読み込むより、毎日 1 週間チャット画面に文章を貼り付ける方が、肌感が早く身につきます。理論はその後で十分追いつけます

LLM は「魔法の杖」ではなく、「膨大な本を読んだ司書」のような存在です。司書は何でも知っているわけではないし、嘘をつくこともある。でも、こちらが質問の仕方を工夫すれば、思った以上の助けになってくれる。「人間が一度読んで判断する」という姿勢を崩さない限り、業務での効果は素直に大きく出ます。

本ブログでは、AI を業務で使う・キャリアに活かす方を対象に、関連記事を 20 本近くまとめています。本記事を起点に、興味のある分野へ広げていただけると嬉しいです。

近いうちに、本ブログの内容を体系化した「未経験から生成AIエンジニアになる講座」もご案内する予定です。準備が整いましたら、メルマガでお知らせさせていただきます。

私自身、現役の生成AIエンジニアとして OpenAI（GPT）／Anthropic（Claude）／Google（Gemini）API を業務で日常的に叩いている立場から、5 系統の代表的 LLM の温度感（GPT・Claude・Gemini は実体験、Llama・Mistral は OSS 中心のため公開情報からの概論として紹介する扱い）を分けて整理しました。LLM の機能・料金体系・利用規約・法的論点は変動が早いため、実際の利用判断は最新の公式情報と利用規約、社内ルール、必要に応じて法務・コンプライアンス部門の判断を優先してください。本記事に対する質問・誤りのご指摘は send@bon-bon-tools.com までお願いします。

出典

What is a large language model (LLM)? | Cloudflare（取得：2026-05-18）
What is a large language model (LLM)? | IBM（取得：2026-05-18）
What is an LLM (large language model)? | AWS（取得：2026-05-18）
OpenAI API Documentation | OpenAI（取得：2026-05-18）
Anthropic API Documentation | Anthropic（取得：2026-05-18）
Gemini API Documentation | Google AI（取得：2026-05-18）
GitHub Copilot Documentation | GitHub（取得：2026-05-18）
Llama Models | Meta AI（取得：2026-05-18）
Mistral AI Documentation | Mistral（取得：2026-05-18）
Amazon Bedrock | AWS（取得：2026-05-18）
AI 事業者ガイドライン | 経済産業省・総務省（取得：2026-05-18）
EU AI Act 公式ページ | European Commission（取得：2026-05-18）