第18章 LLMと生成AIの基礎

Slide 01. LLMと生成AIの基礎

第18章では、LLMと生成AIの基礎を扱います。LLMは Large Language Model の略で、自然言語やコードなどの入力をもとに出力を作るモデルです。この章の目的は、AIを中身の分からない箱のまま使わないことです。何を入力し、どの参考情報、つまりcontextを渡し、出てきた答えをどう確かめるかを説明できるようにします。

Slide 02. この章で持ち帰ること

この章で持ち帰ってほしいことは三つです。一つ目は、AIの出力は下書きであり、確かめて初めて成果物になることです。二つ目は、依頼文であるpromptと、参考情報であるcontextを、作業の仕様として書くことです。三つ目は、AI出力を印象ではなく、根拠、評価軸、試す場面で比べることです。モデル名が変わっても残る見方を身につけます。

Slide 03. 第17章との接続

前章では、ログや数値を見て、リリース後の問題を勘ではなくデータで調べる姿勢を学びました。AIの出力も同じです。もっともらしく見えても、根拠、実行結果、テストで確かめます。この章では、LLM、prompt、context、RAG、tool use、agent、評価を順番に整理し、AIにどう任せ、どこで人間が確認するかを決められるようにします。

Slide 04. 生成AIは正解集ではない

生成AIは、検索エンジンや公式ドキュメントそのものではありません。入力された文章や参考情報をもとに、自然に見える答えを作ります。だから、もっともらしいけれど間違った説明を出すことがあります。AIの出力だけを見て正しいと判断せず、根拠、再現手順、テスト、公式情報、実行結果で確認します。

Slide 05. LLMの基本

LLMは、入力された言葉やコードの流れをもとに、次の出力を作ります。ここでは数式やTransformerの内部実装には入りません。実務でまず見るのは、入力、参考情報、モデル、出力、評価の流れです。モデルが高性能でも、参考情報が足りなければ推測が増えます。答えの形が曖昧なら、後で扱いにくい結果になります。

Slide 06. prompt

promptは、AIへの依頼文です。ただのお願いではなく、作業の仕様として書きます。目的、背景、入力、制約、出力形式、評価基準を入れます。依頼が曖昧だと、AIは足りない部分を推測で補います。例を入れると、答えの形や判断基準が安定しやすくなります。ただし長ければ必ず良いわけではありません。実行して、結果を見ながら直します。

Slide 07. context

contextは、AIが今回の作業で見てよい参考情報です。仕様、関連ファイル、過去の会話、参考資料、制約などが入ります。必要な情報が足りないと、AIは推測で補います。関係ない情報を渡しすぎると、重要な情報が埋もれます。良いAI活用は、モデル選びだけでなく、何を渡し、何を渡さないかでも決まります。

Slide 08. output format

output formatは、答えの形です。箇条書き、表、JSON、チェックリスト、PR本文、ユーザー向け文章など、後で使いやすい形を指定します。形を指定しないと、毎回違う形式になり、比較や自動処理が難しくなります。AIに頼むときは、何を答えるかだけでなく、どんな形で答えるかも書きます。

Slide 09. 出力の揺らぎ

LLMの出力は、同じ依頼でも変わることがあります。temperatureは、答えの揺れやすさを調整する設定の一つです。アイデア出しでは、少し揺らぎがある方が役に立つことがあります。一方、抽出、分類、判定、コード生成では、安定した答えが大事になることが多いです。重要なタスクでは、1回の出力だけで決めず、評価と再確認を用意します。

Slide 10. hallucination

hallucination、つまりハルシネーションは、もっともらしいけれど根拠がない、または誤った出力です。AIが自信ありげに言っていても、根拠がなければ採用しません。特に、存在しない仕様、存在しないAPI、読んでいない資料の要約、確認していない原因の断定には注意します。AIを使わないのではなく、間違いに気づきやすい形で使います。

Slide 11. stale knowledge

stale knowledgeは、古くなった知識です。AIがもともと持っている知識は、最新情報を常に反映しているとは限りません。日付、価格、仕様、法律、ライブラリAPI、クラウドサービスの設定は変わります。最新性が必要なものは、公式ドキュメント、一次情報、実行結果で確認します。AIの記憶に頼りすぎず、今の情報を見る姿勢が大切です。

Slide 12. uncertainty

uncertaintyは、不確実性です。AIに、分からないことを無理に断定させない設計が必要です。根拠が足りない場合は、確認が必要な点として分けます。仮説と事実も分けます。確信度が低い場合は、人間の確認へ回します。支援コメント案のように人へ影響する出力では、不確実な点をメンターが確認できる形にします。

Slide 13. RAG

RAGは Retrieval-Augmented Generation の略です。AIがもともと持っている知識だけに頼らず、検索した文書やデータを参考情報に入れて回答する設計です。社内文書、公式ドキュメント、FAQ、仕様書、コードベースを参照させるときに使います。ただし、RAGでも誤りは残ります。何を取ってきたか、根拠に沿って答えているかを見ます。

Slide 14. retrieval

retrievalは、必要な情報源を検索して取り出すことです。ここで関係の薄い資料を取ってくると、生成される答えもずれます。支援コメント案なら、最近の学習ログ、研修ロードマップ、今週の課題、過去コメントなどが候補になります。ただし、個人情報や不要な情報を渡しすぎないようにします。検索結果が質問に関係しているか、人間が確認できる形にします。

Slide 15. grounding

groundingは、出力が渡した資料や事実に基づいている状態です。支援コメント案なら、どの学習ログや課題説明に基づいているかを示せることが重要です。根拠がない推測は、支援コメント本文に混ぜず、確認が必要な点へ分けます。AIの文章が自然でも、根拠資料に基づいていなければ採用しません。

Slide 16. citation

citationは、どの情報源に基づいたかを示す手段です。ただし、リンクや引用が付いているだけで安心してはいけません。その情報源が本当に本文の主張を支えているかを見ます。リンクはあるのに、本文と関係が弱いこともあります。研修では、AI回答に対して、根拠がある文と根拠が弱い文を分ける練習をします。

Slide 17. tool use

tool useは、AIが外部ツールを呼び出して作業する仕組みです。検索、DB参照、ファイル読み取り、チケット作成、コード実行などがあります。単なるチャットと違い、実際の操作につながります。便利な一方で、間違った操作の影響も大きくなります。AIが何を呼び出し、何を読み、何を変更するかを管理します。

Slide 18. function calling

function callingは、AIが決められた形式、つまりschemaに沿って関数呼び出しを組み立てる仕組みです。たとえば、検索条件、保存する下書き、取得するIDなどを決まった形で出させます。自然文だけより扱いやすくなりますが、その形式が正しいこと、権限が適切なこと、呼び出し前に承認が必要な操作かどうかを確認します。

Slide 19. agent

agentは、目標に向けて複数の手順を計画し、toolを使い、結果を見て次の行動を決める仕組みです。何でも勝手に終わらせる存在ではありません。品質は、目標設定、tool、context、権限、評価、停止条件に左右されます。agentを使うときは、何を任せるかだけでなく、どこで止めるか、何を人間が確認するかを決めます。

Slide 20. agentの境界

支援コメント案なら、学習ログを読む、ロードマップを見る、コメント案を作るところまではAIに任せやすいです。一方、受講者へ送信する、DBを更新する、支援方針を確定する操作は人間承認が必要です。境界には、権限、承認、停止条件、ログ、戻せる準備を置きます。根拠が足りないとき、個人情報が見つかったとき、確信度が低いとき、送信前には止めます。

Slide 21. AI利用リスク

AI利用には、正確性、セキュリティ、プライバシー、著作権、ライセンス、バイアス、説明責任のリスクがあります。リスクという言葉は、使うなという意味ではありません。安全に使い続けるために、何を入れてよいか、何を確かめるか、誰が最後に判断するかを決めるという意味です。影響が大きい判断では、人間が必ず確認します。

Slide 22. 入れてはいけない情報

AIに入力してはいけない情報を明確にします。秘密情報、password、access token、個人情報、顧客情報、未公開情報、内部URLなどです。第14章の秘密情報チェックと同じです。ログやスクリーンショットを貼る場合も、見せてはいけない部分を隠してから使います。AI活用ルールは足かせではなく、チームで安心して使い続けるための前提です。

Slide 23. 評価を先に作る

AIの良し悪しは、印象だけでは評価できません。まず、何を良い出力とみなすかを書きます。採点表であるrubric、試す場面であるtest case、期待する動き、悪い例を用意します。promptを磨く前に、評価のものさしを作ります。1回だけ良い出力が出ることより、継続して一定の品質を出せることを見ます。

Slide 24. 評価軸

支援コメント案なら、評価軸は複数あります。事実に合っているか。根拠と対応しているか。次の行動につながるか。文面が支援的で具体的か。指定した形を守っているか。秘密情報や個人情報を出していないか。英語名を覚えることより、どの軸で比べるかを先に決めることが大事です。

Slide 25. 複数モデル比較

モデルによって、得意なタスク、速度、コスト、出力の癖が違います。ただし、モデル比較はランキングではありません。同じ入力、同じ評価軸、同じ条件で、このタスクに合うかを見る作業です。一番強いモデルを探すのではなく、このタスクに十分で、検証でき、運用しやすい選択を考えます。

Slide 26. 複数prompt比較

同じモデルでも、promptやcontextで品質は変わります。目的が曖昧な依頼、制約が足りない依頼、根拠の出し方を指定した依頼では、出力が変わります。比較するときは、同じ入力と同じ評価表を使います。好みだけで選ばず、どのpromptが、どの失敗を減らしたかを見ます。

Slide 27. ケース: 支援コメント案

この章のケースは、メンター向けの支援コメント案生成機能です。AIは、受講者の最近の学習ログ、過去の支援コメント、研修ロードマップ、今週の課題を参考情報として使います。出力は、支援コメント案、根拠になったログ、確認すべき不確実な点、メンターが編集すべき箇所です。最終送信はメンターが確認します。

Slide 28. AI機能の失敗

AI機能を入れる前に、失敗したときの影響を考えます。たとえば、学習ログを読み違える。根拠のない励ましをする。厳しすぎる文面になる。個人情報を出す。古いロードマップに基づく助言をする。送ってはいけないコメントを自動送信する。失敗を想像すると、必要な参考情報、評価、承認、ログが見えてきます。

Slide 29. 人間の確認

human-in-the-loopは、人間が途中で確認する設計です。支援コメント案では、AIが下書きを作り、メンターが編集してから送信します。AIは候補を出します。人間は、根拠、文面、相手への影響、送信してよいかを確認します。この分担を明確にします。AIに任せる範囲と、人間が責任を持つ判断を混ぜないようにします。

Slide 30. Exercise 1-2

Exercise 1では、生成、要約、抽出、検索、判断、実行に分け、AIに任せること、人間が確認すること、任せないことを書きます。Exercise 2では、promptとcontextを設計し、目的、入力、制約、出力形式、必要な参考情報、渡さない情報を決めます。成果物は ai-task-fit-note.md と prompt-context-design.md です。

Slide 31. Exercise 3-4

Exercise 3では、RAGとgroundingの設計を書きます。情報源、検索方法、根拠の示し方、RAGでも残る失敗を整理します。Exercise 4では、agentにするべきか判断し、使うtool、権限、承認、停止条件、人間の確認地点を書きます。成果物は rag-grounding-note.md と agent-boundary-note.md です。

Slide 32. Exercise 5と第19章への接続

Exercise 5では、AI出力の評価表を作ります。採点表、試す場面、複数出力の比較、採用判断を書きます。成果物は ai-evaluation-note.md です。この表は、AIをどう使い、どう確かめたかを説明する材料にもなります。次の第19章では、この考え方をAIコーディングへつなげます。AIに任せる前に、context、境界、評価を設計する視点を持って進みましょう。