AIの記事を順に読んでいても、モデル名、RAG、エージェントと話題が変わるたびに、何を学べばよいか分からなくなることがあります。最初に必要なのは、すべての製品を覚えることより、自分の仕事で何を確かめる必要があるかを分けることです。
このページは、AI・LLMの基礎と実務上の判断をつなぐ学習案内です。仕組み、データ、費用、実行権限、評価を押さえ、その後で必要な詳しい記事を選べる構成にしています。特定製品の機能は2026年10月4日に確認した公式資料に基づく例で、2026年10月7日に同じ10資料の本文を再読しました。入出力、保持、RAG、追加学習の区分に記事変更を要する差分はありません。利用時には対象のモデルと契約の現状を確認してください。
30秒で要点
- モデルはアプリを構成する一部です。検索、記憶、画像や音声、ツールの権限は個別に確かめます。
- 仕事の目的と受入基準を先に決め、使えるデータ、費用、誤りの影響から手段を選びます。
- 下書きの速さだけでなく、根拠確認と再作業を含めて評価します。小さな試行を全業務の成功証明にはしません。
AI、LLM、アプリは、どの層の話か
AIは、予測、認識、生成などを含む広い領域の呼び方です。生成AIは文章や画像などを作る仕組みを指します。LLMは大規模言語モデルのことで、文脈中の言語のパターンを学び、文章などの出力に使われます。すべてのAIがLLMではなく、すべての生成AIが文章を作るモデルでもありません。
Googleの言語モデル教材では、言語モデルをtokenの列の確率を扱う仕組みとして説明しています。tokenは文字や単語の一部などを表す単位で、日本語の一文字が常に一tokenになるわけではありません。多くのLLMで使われるTransformerは、入力中の要素の関係を重み付けするattentionを利用します。ただし、これは情報の正しさを外部の事実と照合する機構そのものではありません。Transformerの公式教材でも、全体構成と生成に使う構成を分けています。より詳しい仕組みはLLMとTransformerの基礎で学べます。
一方、利用者が触るアプリには、画面、検索、会話履歴、ファイル保管、外部システムへの接続が含まれます。アプリが資料を検索して答えたなら、それを「モデルが最初から知っていた」とは言えません。アプリ全体の便利さと、モデル単体の能力を分けると、選定時の問いが具体的になります。
学習、参照、記憶を混同しない
学習は、データからモデルのパラメータを調整する過程です。Googleの調整手法の教材では、追加学習によるパラメータの調整と、パラメータを変えず入力の指示や例を工夫する方法を分けています。質問するたびに、その質問内容が直ちにモデル本体へ学習されるという意味ではありません。利用サービスが入力をどの目的で扱うかは、別途その規約や設定の確認が必要です。
参照は、その回答に必要な資料を今回の入力として渡すことです。MicrosoftのRAGの説明では、基本的な構成として必要な資料を検索し、その結果をLLMに渡して回答を生成する流れを示しています。この記事ではその流れをRAGの入口とします。新しい規程を探せても、検索漏れや誤読が起きる可能性があります。根拠へのリンクがあることと、その根拠が回答を支えることを別に確かめます。
記憶は、アプリが会話や利用者情報を保存し、後の処理へ渡す仕組みです。例えばLangGraphの状態保存は、処理の状態を保存して再開する機構を説明しています。何を覚えるか、誰が読めるか、いつ削除するかは、運用側の設計に含まれます。記憶する量を増やすことが、そのまま正しい回答の増加を意味するわけではありません。
表が収まらない場合は、横にスクロールできます
| 困りごと | 最初に調べる候補 | 注意する条件 |
|---|---|---|
| 指示が曖昧で回答形式が揃わない | 指示文と入出力例の整理 | 書式が合っても内容は誤り得る |
| 社内の更新資料を使いたい | 検索・参照するRAG | 検索権限、版、欠落、出典の照合 |
| 特定の振る舞いを改善したい | 指示の改善と追加学習の比較 | 学習用と評価用のデータを分ける |
| 次の手順を状況に応じて変えたい | ツールを使うエージェント | 外部作用、承認、上限、再実行 |
これは製品の優劣表ではなく、問題を切り分けるための案です。検索ならRAGの設計、指示ならプロンプトの基礎、動作の連携ならAIエージェント開発が次の入口になります。
現在の入出力は、形式ごとに確認する
「マルチモーダル」は、文章以外の画像や音声なども扱うことです。ただし、同じ形式を読めることと、作れることは同じではありません。OpenAIの画像仕様は画像理解と生成・編集を分け、音声仕様は文字起こし、音声生成、音声対話を別の処理として案内しています。
表が収まらない場合は、横にスクロールできます
| 欲しい処理 | 仕様で確認すること | 小さく試す例 |
|---|---|---|
| 画像から読む | 入力形式、解像度、文字や図表の制約 | 小さい文字を含む公開資料を原本と照合 |
| 画像を作る | 画像出力・編集の対応、用途や入力の条件 | 架空の説明図のラフを作り意味を確認 |
| 音声を書き起こす | 音声入力、言語、長さ、話者や時刻の扱い | 同意を得た短い試験音声と原稿を照合 |
| 音声で応答する | 音声出力、遅延、割込み、操作の権限 | 誤認識時に訂正や停止できるか確認 |
画像では文字やグラフの線、数え上げなどで誤り得ることも公式資料に示されています。「画像が送れた」段階を、その仕事に必要な精度が得られた段階にしないでください。動画を含む追加の形式も、モデル名の印象から推定せず、使う入口の仕様を確認します。
データと権限を、モデル選定より前に決める
まず、入力する資料を誰が提供できるか、外部送信してよいか、どこに保存されるかを書き出します。入力の学習利用、ログの保持、アプリの状態保存、外部ツールへ渡るデータは、別々の条件です。
例えばOpenAI APIのデータ管理資料では、APIデータの学習利用と、不正利用監視ログや機能上の状態保存を分けています。「学習に使わない」という条件だけから、「何も保存されない」とは判断できません。ここで述べるのはAPIの例で、個人向けアプリや他社サービスにも同じ条件が適用されるという意味ではありません。
自社環境で動かすモデルでも、データの権限、モデルの利用条件、機器の保守、ログの管理は残ります。重みを入手できることと、全用途で制限なく使えることも分けます。クラウドかローカルかという二択の前に、許可できるデータと運用できる責任の範囲を決めます。
さらに、回答を表示することと、メール送信や顧客情報の更新を実行することを分けます。外部操作を加えるなら、対象を固定した承認、実行時の権限、重複防止、停止条件が必要です。モデルへの指示だけでアクセス制御を代用しないようにします。
費用は、出力一回より仕事全体で見る
token単価だけで比較すると、検索、保存、再試行、人の確認が抜けます。アプリの固定料金、APIの利用料、自社機器の費用も、必要な仕事の単位へそろえて比べます。以下の単価は計算の説明用に置いた架空の料金で、実在するモデルの価格ではありません。
仮に入力100万tokenあたり6円、出力100万tokenあたり24円とします。一回あたり入力2,000token、出力500tokenなら、モデル利用料は次の計算です。
表が収まらない場合は、横にスクロールできます
| 仮想の内訳 | 計算 | 金額 |
|---|---|---|
| 入力一回分 | 2,000÷1,000,000×6円 | 0.012円 |
| 出力一回分 | 500÷1,000,000×24円 | 0.012円 |
| 1,000回の合計 | 1,000×0.024円 | 24円 |
| 同じ長さの再試行100回を追加 | 1,100×0.024円 | 26.4円 |
一方、1,000件すべての確認に一件0.5分、人の時間を仮に一分40円で換算すると20,000円です。モデル利用料だけの26.4円と、確認の20,000円を合わせると20,026.4円になります。この例には検索、保存、導入、再試行による追加の確認などを含めていません。実際の見積りでは必要な費目を足します。
人の確認費が常に支配的だという主張ではありません。短い入力と架空の単価を置いたこの例では、どの費目を省くと判断が変わるかを示しています。実際は長い資料、画像、音声、モデル内の推論や課金方式で変わるため、試験時の利用明細と作業記録を使います。
「役に立った」を、評価できる問いに変える
文章が自然でも、問いに答えているとは限りません。業務で試す前に、事実、漏れ、出典、形式、処理時間、費用のうち何を判定するか決めます。正答できる通常例だけでなく、資料に答えがない例、条件が矛盾する例、使ってはいけない操作を求める例も入れます。
NISTの生成AIプロファイルは、利用条件に近い評価や、出力中の引用・根拠の確認を扱っています。Microsoftの人とAIの設計指針も、誤りの範囲を知らせ、修正できることを重視しています。いずれも、導入するだけで成果が上がるという資料ではありません。AIの技術、使う人の判断、数値による検証は、必要に応じてつなぎます。例えばチャットの変更を比べるなら、応答が好まれたかだけでなく、目的を達成できたか、誤案内が増えなかったかを見ます。満足度が60%から80%になったという二つの割合だけでは、母数、回答者の選ばれ方、比較条件が分からず、p値や因果効果は決まりません。A/Bテストの統計で比較の条件を、AIと人の協働で確認負担を整理できます。
今の疑問から、次の記事を選ぶ
同じ記事を何度も列挙するより、読後に何を決めたいかで学習経路を選びます。
表が収まらない場合は、横にスクロールできます
| 今の疑問 | 次に読む内容 | 読後に残すもの |
|---|---|---|
| 基礎用語を知りたい | AI・LLM入門、ChatGPTの基礎 | モデルとアプリの区別 |
| どのモデルを試すか | モデル比較、モデル選定 | 必要能力と比較する課題 |
| 社内資料に答えてほしい | RAG、ベクトルデータベース | 参照範囲と検索の確認方法 |
| システムにつなぎたい | API実装、LangChain入門 | 入出力とエラー時の扱い |
| 顧客対応へ使いたい | チャットボット設計 | 対応範囲と人への引継ぎ |
| Web業務へ組み込みたい | Web開発への統合、AI時代のWeb制作 | 既存工程のどこへ入れるか |
| 業務の前提を整理したい | 導入前に整理すること、First byteメソッド | 目的、制約、判断材料、次の検証 |
各記事の具体的な仕様やコードも、対象とした版と前提を確認して読んでください。リンクがあることを、その先のすべての手順が自分の環境で検証済みという意味にはしません。
最小の実践は、外部へ作用しない一つの仕事を選び、公開情報や仮想データで試すことです。欲しい出力と失敗の基準を先に書き、原資料へ戻って確認し、手直しの負担を残します。その結果から、指示を変えるのか、資料を整えるのか、別の仕組みを選ぶのかを判断できます。学ぶ順序は製品の新しさではなく、その判断に足りない材料で決められます。