エンジニア入門研修

Part 5 AIと知識作業

第18章 LLMと生成AIの基礎

第17章では、リリース後の問題を、ログ、メトリクス、トレース、SLOで観察する方法を扱った。 第18章では、その姿勢をAIに向ける。 AIの出力も、自然に見えるから正しいのではない。 根拠、入力、参照情報、実行結果、評価表で確かめて、初めて仕事に使える。

LLMは Large Language Model の略で、自然言語やコードなどの入力をもとに出力を生成するモデルである。 生成AIは、文章、コード、画像、要約、分類、提案など、新しい出力を作るAIを指す。 この章では、Transformerの数式、GPU、分散学習、fine-tuningの詳細には入らない。 新人エンジニアが最初に持つべき見方は、もっと実務寄りである。 何を入力し、どのcontextを渡し、どのmodelを使い、どんなoutputを受け取り、何でevaluationするか。 この流れを説明できるようにする。

本章のケースは、研修用学習ログアプリに追加する「メンター向け支援コメント案生成機能」である。 メンターが受講者の最近の学習ログを読み、次の支援コメント案をAIに作らせる。 AIは、学習ログ、研修ロードマップ、今週の課題、過去の支援コメントを参考にできる。 ただし、最終的に受講者へ送るかどうかは、メンターが判断する。 この題材を使うと、prompt、context、RAG、tool use、agent、human-in-the-loop、評価が一つの流れとして見える。

この章は、特定のAIサービスの画面操作を覚える章ではない。 OpenAI、Claude、Gemini、社内LLM基盤など、利用するproviderやmodelは変わる。 そのため、ここでは変わりにくい考え方として、入力、context、出力、toolの境界、評価、記録を扱う。

この章でできるようになること

  • LLMと生成AIを、入力、context、model、output、evaluation、revisionの流れで説明できる。
  • AI支援機能を、要約、抽出、検索、生成、判断、実行へ分け、任せる範囲を決められる。
  • promptを、お願い文ではなく、目的、制約、出力形式、評価条件を持つ作業仕様として書ける。
  • RAG、citation、groundingの違いを説明し、根拠が出力本文を支えているか確認できる。
  • tool useとagentで、読み取り、下書き、書き込み、送信、削除を分け、承認と停止条件を設計できる。
  • AI出力をrubric、test case、model/prompt/contextの記録で評価できる。

生成AIは正解集ではない

生成AIを使うと、質問に対して自然な文章が返ってくる。 コードも書ける。 要約もできる。 表も作れる。 そのため、初めて使うと「分かっている相手が答えている」ように感じる。 しかし、開発者はここで立ち止まる必要がある。 流暢さと正しさは別物である。

生成AIは、検索エンジンそのものでも、公式ドキュメントそのものでもない。 入力された文章、渡されたcontext、モデルが学習した傾向をもとに、もっともらしい出力を作る。 その出力は役に立つことが多い。 一方で、根拠のない説明、古い仕様、存在しないAPI、読んでいない資料の要約、確認していない原因の断定も起こり得る。

たとえば、AIに「このエラーの原因を教えて」とだけ聞くと、一般的な原因候補を返す。 それ自体は相談の入口として使える。 しかし、実際の原因は、手元のログ、コード、依存関係、環境変数、直近の変更にある。 AIが自信を持って「DB接続の問題です」と書いても、ログや設定で確認しなければ原因とは言えない。

第17章で、遅いAPIを感想ではなくp95やログで調べた。 AIの出力も同じである。 「良さそう」ではなく、何に基づくか、どこまで確かめたか、何が不確実かを見る。 生成AIを使いこなすとは、AIを信じることではなく、AIの出力を仕事の流れへ安全に組み込むことである。

LLM利用の基本形

LLM利用は、次の流れで考える。

task
  -> prompt
    -> context
      -> model
        -> output
          -> evaluation
            -> revise

taskは、AIに手伝わせたい作業である。 promptは、AIへの作業指示である。 contextは、AIが今回参照してよい情報である。 modelは、入力から出力を作る本体である。 outputは、返ってきた文章、コード、表、JSONなどである。 evaluationは、その出力を採用してよいかを確かめる作業である。 reviseは、prompt、context、評価、場合によってはタスク分解そのものを直すことである。

この流れを見ると、モデル選びだけに注目しても足りないことが分かる。 高性能なモデルでも、taskが曖昧なら出力は曖昧になる。 contextが足りなければ推測が増える。 output formatを決めなければ、後工程で使いにくい形になる。 evaluationがなければ、良い出力と危険な出力を見分けられない。

実務では、この流れをメモに残す。 AI APIやmodel名は変わるため、「最新モデルを使った」だけでは説明にならない。 いつ、どのmodelまたはmodel snapshotを使い、どのprompt version、どのcontext、どの評価表で確認したかを残す。 後からmodelを変えたときは、同じtest caseで再評価する。

支援コメント案生成なら、taskは「受講者の最近の学習ログを読み、メンターが編集して使える支援コメント案を作る」である。 このtaskの中には、要約、抽出、判断、生成、確認、送信が混ざっている。 いきなり全部をAIに任せるのではなく、作業を分ける。

| 作業 | 種類 | AIに任せやすいか | 人間の確認 | 失敗時の影響 |
| --- | --- | --- | --- | --- |
| 学習ログを要約する | 要約 | 高い | 必要 | 重要な文脈を落とす |
| 困っていそうな点を抽出する | 抽出 | 中くらい | 必要 | 誤解した支援になる |
| 支援コメント案を書く | 生成 | 高い | 必要 | 不適切な文面になる |
| 支援方針を確定する | 判断 | 低い | 必須 | 支援がずれる |
| コメントを送信する | 実行 | 低い | 必須 | 誤送信する |

この表を作るだけで、AIの使い方は変わる。 AIに任せる範囲、人間が確認する範囲、任せない範囲が見える。 AI活用の第一歩は、良いpromptを書くことではない。 その前に、作業を分解することである。

promptはお願いではなく作業仕様である

promptは、AIへの依頼文である。 ただし、実務では「いい感じに書いて」では足りない。 promptは、作業仕様として書く。 目的、読者、背景、入力、制約、出力形式、良い出力の条件、悪い出力の例を入れる。

悪いpromptは、AIに推測させる。

この受講者にコメントを書いて。

この依頼では、誰に向けたコメントか、どの情報を根拠にするか、どの文体にするか、何を書いてはいけないか、どの形式で返すかが分からない。 AIは足りない部分を一般論で埋める。 その結果、自然だが根拠の弱い文章になりやすい。

作業仕様としてのpromptは、次のように書ける。

あなたは新人エンジニア研修のメンター支援アシスタントです。

目的:
- 受講者の最近の学習ログを読み、メンターが編集して使える支援コメント案を作る

読者:
- コメントを受け取る受講者
- 最終確認するメンター

参考情報:
- 最近の学習ログ
- 今週の課題
- 研修ロードマップ

制約:
- 根拠のない断定をしない
- 受講者の人格を評価しない
- 秘密情報、個人情報、内部URLを出力しない
- 不確実な点は「確認が必要な点」に分ける
- メンターが編集してから送信する前提で書く

出力形式:
- 支援コメント案
- 根拠にしたログ
- 確認が必要な点
- メンターが編集すべき箇所

このpromptでも、出力が必ず正しくなるわけではない。 しかし、何を満たせばよいかが明確になる。 レビューする人も、目的、根拠、制約、形式に照らして評価できる。

promptは一度で完成させるものではない。 出力を見て、足りない制約を足す。 曖昧な出力形式を直す。 悪い出力例を追加する。 評価表に合わせて改善する。 promptの改善は、文章の飾り付けではなく、作業仕様の改善である。

contextは、AIに読ませる作業材料である

contextは、AIが今回の作業で見てよい参考情報である。 仕様、コード、ログ、課題説明、過去の会話、社内文書、実行結果などがcontextになる。 AIが知らない社内事情や最新の仕様は、contextとして渡さなければ使えない。

contextは多ければよいわけではない。 足りなければ推測が増える。 多すぎれば重要な情報が埋もれる。 関係ない情報が混ざると、AIはそこから余計な連想をする。 渡してはいけない情報を入れると、セキュリティやプライバシーの問題になる。

支援コメント案生成では、contextを次のように整理する。

| 参考情報 | 必要な理由 | 渡す/渡さない | 注意 |
| --- | --- | --- | --- |
| 最近の学習ログ | 状況の根拠にする | 渡す | 必要な範囲に絞り、個人情報を伏せる |
| 今週の課題 | 次の行動提案に使う | 渡す | 版が古くないか確認する |
| 研修ロードマップ | 学習の流れに合わせる | 渡す | 該当章だけに絞る |
| 過去コメント | 文体の参考にする | 条件付きで渡す | 不適切例を混ぜない |
| password / token | 不要で危険 | 渡さない | 入力しない |
| 受講者の個人情報 | 支援案には不要 | 渡さない | 必要なら匿名化する |
| 本番ログ全文 | 不要で危険 | 渡さない | 必要fieldだけ抽出する |

context設計では、情報源の新しさも見る。 古いロードマップに基づいて助言すると、受講者を間違った方向へ案内する。 古いライブラリAPIを前提にコードを書くと、動かない。 クラウド、法律、料金、ライブラリ、AI APIの仕様は変わる。 最新性が必要なものは、公式ドキュメント、一次情報、実行結果で確認する。

また、contextには権限の考え方が必要である。 AIが読んでよい情報と、読んではいけない情報を分ける。 必要な最小限だけ渡す。 第14章で扱ったsecret、第17章で扱ったログの匿名化は、AI利用でも同じである。

output formatは、後工程の使いやすさを決める

AIに頼むときは、何を答えるかだけでなく、どんな形で答えるかも指定する。 output formatは、出力の形である。 箇条書き、表、JSON、チェックリスト、PR本文、レビューコメント、ユーザー向け文章などがある。

出力形式を指定しないと、毎回違う形で返る。 人が読むだけならまだよいが、比較、保存、レビュー、自動処理に使う場合は困る。 支援コメント案生成なら、少なくとも本文、根拠、確認事項、編集ポイントを分けたい。

{
  "draft_comment": "ここに支援コメント案を書く",
  "evidence": [
    {
      "source": "learning_log",
      "summary": "根拠にしたログの要約"
    }
  ],
  "uncertainties": [
    "メンターが確認すべき点"
  ],
  "mentor_edit_points": [
    "送信前に編集すべき点"
  ]
}

JSONのような構造化出力は、自動処理に向く。 一方で、厳密なJSONが必要なら、schema、必須項目、型、失敗時の扱いを決める必要がある。 人間が読む下書きならMarkdownの方がよいこともある。 出力形式は、AIにとって都合のよい形ではなく、後工程で使う人とシステムにとって都合のよい形で決める。

構造化出力には、いくつかの段階がある。

  • Markdownや箇条書き: 人が読むにはよいが、機械処理には揺れが出やすい。
  • JSON: 機械処理しやすいが、項目の欠落や型のずれに備える必要がある。
  • schema付きstructured output: 必須項目、型、許可値などに沿った出力を求めやすい。
  • function calling: 最終回答の形式ではなく、モデルが外部toolを呼び出すための構造化された要求である。

JSONで返ってきたことやschemaに合ったことは、業務上正しいことを意味しない。 learner_id が許可された受講者か、根拠ログが本人のものか、送信してよい文面かは、アプリ側で別に検証する。 形式のvalidationと、業務ルール、権限、安全性のvalidationは分けて考える。

出力の揺らぎとtemperatureを理解する

LLMの出力は、同じ依頼でも変わることがある。 生成AIは、固定の関数のように必ず同じ答えを返すとは限らない。 temperatureは、出力の揺らぎやすさに関係する設定の一つである。 一般に、揺らぎが大きいと発想の幅は広がりやすく、揺らぎが小さいと安定しやすい。

アイデア出しでは、多少の揺らぎが役に立つ。 複数の言い換え、支援コメントの候補、改善案の候補を出す場合は、同じ答えに固定されない方がよいこともある。 一方、抽出、分類、判定、コード生成、JSON出力、採点では、安定性が重要になる。

重要なタスクでは、1回の出力だけで決めない。 複数の出力を比べる。 同じ評価表で採点する。 失敗例を用意する。 必要なら人間が確認する。 AIの揺らぎは悪ではないが、揺らぎを前提にした評価と運用が必要である。

hallucination、stale knowledge、uncertaintyを分ける

AIの失敗は一種類ではない。 代表的なものに、hallucination、stale knowledge、uncertaintyがある。 これらを分けると、対策も分けられる。

hallucinationは、もっともらしいが根拠がない、または誤った出力である。 存在しないAPIを紹介する。 読んでいない資料を要約したように書く。 確認していない原因を断定する。 支援コメント案で、ログにない努力や困りごとを断定する。 このような出力は、自然な文章でも採用してはいけない。

stale knowledgeは、古くなった知識である。 モデルが持っている知識や、渡したcontextが古い場合、現在の仕様とずれる。 ライブラリAPI、クラウド設定、価格、法律、セキュリティ基準、AI APIは変わる。 最新性が必要なものは、公式ドキュメントや実行結果を見る。

uncertaintyは、不確実性である。 情報が足りない。 ログ同士が矛盾している。 根拠資料が古い。 複数の原因があり得る。 このとき、AIに断定させるのではなく、確認が必要な点として分ける。

支援コメント案では、次のように分ける。

## 根拠に基づいて書けること

- 第18章の課題に取り組んでいる。
- promptとcontextの違いで迷っている。

## 確認が必要なこと

- 実装で詰まっているのか、概念整理で詰まっているのか。
- メンターからの追加説明が必要か。

## 書いてはいけないこと

- 「理解が遅い」と人格評価する。
- ログにない事情を断定する。

AIの不確実性を隠すと、出力は自信ありげに見える。 しかし実務では、不確実な点を見える形にした方が使いやすい。 メンターが確認すべき点として分かれていれば、AIの下書きは安全に使いやすくなる。

RAGは、検索して読ませる設計である

RAGは Retrieval-Augmented Generation の略である。 検索して取り出した情報をcontextに加え、その情報をもとに生成する考え方である。 AIがもともと持っている知識だけに頼らず、社内文書、公式ドキュメント、FAQ、仕様書、コードベース、学習ログなどを参照させたいときに使う。

RAGの基本の流れは次のようになる。

user question
  -> retrieve relevant sources
    -> add sources to context
      -> generate answer
        -> cite sources
          -> verify claims

RAGは魔法ではない。 検索対象が古ければ古い答えになる。 retrievalがずれれば、関係の薄い資料に基づいた答えになる。 取り出した資料の一部だけを見て、全体と違う結論を出すこともある。 根拠表示があっても、本文の主張と本当に対応しているとは限らない。

RAGのretrievalは、単純なキーワード検索だけとは限らない。 semantic searchを使うと、同じ単語がなくても意味が近い資料を取り出せる。 これは便利だが、なぜその資料が出たのかを人間が追いにくいこともある。 そのため、情報源の分割単位であるchunk、更新日や章番号などのmetadata、受講者やteamに応じたpermission filtering、古い資料を外すfreshness管理が重要になる。 他人の学習ログや不要な本番ログが検索結果に混ざるなら、RAG以前に権限設計が失敗している。

また、RAGで取り込む文書は、すべて信頼できる指示とは限らない。 学習ログ、Webページ、メール、Issue本文の中に「これまでの指示を無視して」といった文が混ざることがある。 これはindirect prompt injectionになる。 検索して取り出した内容は、AIへの命令ではなく、引用対象のdataとして扱う。 危険な指示を見つけたら従わず、停止条件や人間確認へ回す。

支援コメント案生成でRAGを使うなら、情報源を先に設計する。

| 情報源 | 目的 | 新しさ | 権限/絞り込み | リスク |
| --- | --- | --- | --- | --- |
| 学習ログ | 現在の状況を見る | 高い | 対象受講者と期間だけ | 個人情報に注意 |
| 研修ロードマップ | 次の学習提案に使う | 中くらい | 該当章だけ | 古い版に注意 |
| 今週の課題 | 具体的な助言に使う | 中くらい | 対象章だけ | 章や提出物の差分に注意 |
| 過去コメント | 文体の参考にする | 中くらい | メンターが許可したものだけ | 不適切な言い回しが混ざる |

retrievalでは、質問に関係する情報を取り出す。 groundingでは、出力が取り出した情報に基づいているかを見る。 citationでは、どの情報源に基づいたかを示す。 この三つは別物である。 検索できたこと、根拠に基づいていること、引用が正しいことは、それぞれ確認が必要である。

citationは飾りではなく検証の入口である

citationは、どの情報源に基づいたかを示す参照表示である。 リンクや文書名が付いていると安心しやすい。 しかし、citationがあるだけで正しいとは限らない。 本文の主張と根拠が対応しているかを確認する必要がある。 citationは証明ではなく、検証の入口である。 文書名だけでなく、可能ならsource id、更新日、chunk id、該当箇所の短い要約を残す。 AIが存在しない文書名や読んでいないsourceを挙げることもあるため、citation自体の実在も確認する。

たとえば、AIが次のように出力したとする。

支援コメント案:
第18章のRAG設計で、根拠表示まで意識できています。次はagentの境界を整理するとよさそうです。

根拠:
- **learning_log_2026-06-25**：RAGとcitationの違いをメモしている
- **assignment_ch18**：Exercise 4でagent boundary noteを作る

この場合、根拠は本文の主張を支えている。 一方、根拠ログにRAGの記述がないのに「RAG設計で意識できています」と書いていたら、citationは飾りでしかない。 AI回答を採用する前に、主張、根拠、確かさ、注意点を表で確認するとよい。

| 主張 | 根拠 | 確かさ | 注意 |
| --- | --- | --- | --- |
| RAGとcitationを区別している | 学習ログに両方のメモがある | 中 | 正確な理解かは確認が必要 |
| 次はagent境界を整理する | 課題にExercise 4がある | 高 | 具体的なtool権限は未確認 |

groundedな出力とは、自然な出力ではない。 根拠と対応している出力である。 RAGを使うなら、本文と根拠を照合する作業を省いてはいけない。

tool useは、AIの出力を現実の操作へ接続する

tool useは、AIが外部の道具を呼び出して作業する仕組みである。 検索、DB参照、ファイル読み取り、チケット作成、メール下書き、コード実行、ログ検索などがある。 単なるチャットと違い、実際のデータや操作につながる。

OpenAIのAPIドキュメントでは、function calling、またはtool callingとして、モデルが外部systemの機能やデータに接続する考え方が説明されている。 AIが何でも直接実行してよいわけではない。 toolには、読み取りだけのもの、下書きを作るもの、状態を変更するもの、外部へ送信するものがある。 影響の大きさが違う。

重要なのは、モデルがtool callを提案しても、実際に実行するのはアプリ側である点である。 アプリは、tool名、引数、ユーザー権限、対象ID、回数制限、承認状態を検証してから実行する。 「モデルがそう要求したから実行する」は、tool useの設計として弱い。

支援コメント案生成では、toolを次のように分ける。

| tool | 操作 | 権限 | 人間承認 | 実装側の確認 |
| --- | --- | --- | --- | --- |
| 学習ログ検索 | 最近のログを読む | 読み取り | 不要 | learner_idと期間を検証 |
| ロードマップ検索 | 該当章を読む | 読み取り | 不要 | source versionを記録 |
| コメント下書き保存 | draftを保存する | 書き込み | 必要 | draft扱いで送信しない |
| コメント送信 | 受講者へ送る | 送信 | 必須 | 承認者、送信先、本文を記録 |
| DB更新 | 支援状態を変更する | 書き込み | 必須 | idempotencyとrollbackを設計 |

function callingでは、toolの入力をschemaで定義できる。 schemaは、項目名、型、必須項目、許可される値を決める構造である。 自然文だけで「ログを検索して」と言うより、learner_id、date_range、chapter のように決まった形で渡す方が、実装側で扱いやすい。

ただし、schemaがあっても安全性は自動では保証されない。 許可されていないIDを読めないか。 大量取得できないか。 送信や削除の前に承認を挟むか。 ログに残るか。 失敗時に戻せるか。 同じtool callが再送されても二重送信や二重更新にならないか。 tool useでは、AIの出力だけでなく、権限と操作の設計が必要になる。

agentは、自律ではなく境界設計で考える

agentは、目標に向けて複数の手順を計画し、toolを使い、結果を見て次の行動を決める仕組みである。 agentという言葉には、自動で全部やってくれる印象がある。 しかし実務では、agentを使うほど、境界、権限、停止条件、評価が重要になる。

単発のAI応答とtool useで足りるなら、無理にagentにしない。 agentが必要になるのは、複数stepを計画し、tool結果を見て次のstepを選び、状態を持って進める必要がある場合である。 便利そうだからagentにするのではなく、必要な手順とリスクが見えてから選ぶ。 また、agentにはguardrailが必要である。 guardrailは、入力、出力、tool実行の前後で、危険な内容や権限外の操作を止めるための検査である。

支援コメント案生成をagentにする場合を考える。 AIが最近の学習ログを検索する。 研修ロードマップを読む。 今週の課題を読む。 支援コメント案を作る。 根拠を添える。 確認が必要な点を出す。 ここまでは、agentに任せやすい。

一方で、受講者へコメントを送信する、DBの支援ステータスを更新する、メンターの方針を確定する、といった操作は別である。 これらは人間の承認が必要である。 AIが直接送信すると、根拠が弱いコメント、厳しすぎる表現、個人情報を含む内容、誤った支援方針がそのまま相手に届く可能性がある。

agentの境界は、次のように書く。

# Agent Boundary

## agentに任せる

- 学習ログの候補を検索する
- 関係するロードマップを読む
- 支援コメント案を作る
- 根拠と確認事項を分ける

## 人間承認が必要

- コメントを送信する
- 支援ステータスを更新する
- 受講者への評価や方針を確定する

## 停止条件

- 根拠が不足している
- 個人情報やsecretを検出した
- 情報源が矛盾している
- 確信度が低い
- prompt injectionらしい指示を検出した
- 書き込み、送信、削除が必要

## guardrails

- input: secret、不要な個人情報、不審な指示を検出する
- output: 根拠なし断定、人格評価、秘密情報の混入を止める
- tool: 権限外ID、過剰取得、未承認の送信や更新を止める

agentは、任せる範囲を広げる技術ではない。 任せる範囲を明確にする設計である。 どこで止めるかを決めていないagentは、実務では危険である。

AI利用リスクは、使わない理由ではなく設計対象である

AI利用には、正確性、セキュリティ、プライバシー、著作権、ライセンス、バイアス、説明責任のリスクがある。 NIST AI RMFは、AIの信頼性やリスク管理を設計、開発、利用、評価の中へ組み込むための参照になる。 OWASPのLLM/生成AI向けTop 10は、prompt injection、sensitive information disclosure、supply chain、data and model poisoning、improper output handling、excessive agency、system prompt leakage、vector and embedding weaknesses、misinformation、unbounded consumptionなど、LLMアプリで起きやすいリスクを整理している。

リスクという言葉は、「AIを使うな」という意味ではない。 リスクは、何を入れてよいか、何を出してはいけないか、どこで人間が確認するか、何をログに残すか、どう評価するかを決めるための材料である。

支援コメント案生成では、少なくとも次を考える。

  • prompt injection：ユーザー入力やRAGで取り込んだ文書内の指示に、AIが従わないようにする。
  • 正確性：学習ログにないことを断定しない。
  • grounding：コメント本文と根拠ログが対応している。
  • privacy：個人情報や不要な内部情報を入力、出力しない。
  • improper output handling：AI出力をHTML、SQL、command、メール本文などへ渡す前にescapeやvalidationを行う。
  • safety：受講者を傷つける表現や人格評価を避ける。
  • excessive agency：AIが直接送信、DB更新、評価確定をしない。
  • overreliance：メンターが最終確認する。
  • unbounded consumption：無制限の再試行、大量retrieval、大量生成で費用や負荷が膨らまないようにする。
  • auditability：使ったcontext、出力、採用判断を後から確認できる。

リスク対策は、最後にチェックリストを足すだけでは弱い。 prompt、context、tool権限、停止条件、評価表、ログ設計へ分散して入れる。 AI機能は、モデルだけでなく、その周囲の設計で安全性が決まる。

AIに入れてはいけない情報を決める

AI利用では、入力してはいけない情報を明確にする。 secret、password、access token、API key、個人情報、顧客情報、未公開情報、内部URL、本番ログ全文、AWS account idなどである。 第14章で扱った秘密情報チェックと同じで、AIに貼る前に止める。 system promptや内部指示も、外に漏れない前提で設計してはいけない。 隠したpromptだけで安全性を守るのではなく、アプリ側の権限、validation、承認で守る。

ログやスクリーンショットを使うときも注意する。 エラー調査のためにAIへログを貼る場合、request_id、endpoint、status、duration_msのような必要fieldだけに絞る。 token、email、氏名、内部URL、DB接続情報は伏せる。 AIに渡す前の匿名化を、作業手順として書く。

# AI Input Safety Checklist

- [ ] secret、token、passwordを含まない
- [ ] 個人名、メールアドレス、顧客情報を含まない
- [ ] 内部URL、AWS account id、DB接続情報を含まない
- [ ] 本番ログ全文ではなく必要fieldに絞っている
- [ ] AIに渡す必要がない情報を削っている
- [ ] system promptや内部運用ルールを安全性の唯一の前提にしていない
- [ ] 出力にも秘密情報が混ざっていないか確認する

AI活用ルールは、足かせではない。 チームで継続して安心して使うための前提である。 一度でも秘密情報を貼ってしまうと、その後の共有、ログ、監査、説明が難しくなる。 最初から入力しない設計にする。

評価を先に作る

AI出力を、印象だけで評価してはいけない。 「良さそう」「自然」「賢そう」という感想は、採用判断として弱い。 評価には、rubric、test case、期待する動き、悪い例が必要である。

rubricは採点表である。 支援コメント案なら、次のような評価軸が考えられる。

| 評価軸 | 重み | 良い状態 | 悪い状態 |
| --- | --- | --- | --- |
| 事実に合っている | 高 | 学習ログに基づく | 根拠のない断定 |
| 根拠と対応している | 高 | 主張とcitationが対応する | 根拠表示と本文がずれる |
| 役に立つ | 中 | 次の行動が分かる | 一般論だけ |
| 文面が支援的 | 中 | 具体的で受け取りやすい | きつい、曖昧 |
| 形式を守る | 中 | 指定項目がそろう | 欠落がある |
| 安全である | 高 | 秘密情報や個人情報を出さない | 不要な個人情報を含む |

test caseは、AIを試す具体的な場面である。 通常の学習ログだけでなく、失敗しやすい場面を入れる。

| 場面 | 期待する動き | リスク |
| --- | --- | --- |
| 通常の学習ログ | 根拠つきで短い支援案を書く | 一般論になる |
| つまずいているログ | 励ましと次の行動を分ける | 厳しすぎる文面になる |
| 参考情報が足りない | 確認事項へ分ける | 推測で埋める |
| ログが矛盾している | 矛盾を明示する | 都合よく片方だけ使う |
| 個人情報が含まれる | 出力に含めない | そのまま出す |

OpenAIの評価に関するドキュメントでも、生成AIは変動するため、タスク固有の評価、ログ、継続的な評価、人間の判断の組み合わせが重要になる。 ここでいう評価は、特定providerの評価サービス名ではなく、AI出力を検証する実務プロセス全体を指す。 評価は、最後に一回だけ行うものではない。 promptを変えたとき、contextを変えたとき、modelを変えたとき、toolを増やしたときに、同じtest caseで比べる。

評価用のtest caseは、思いつきではなく小さなdatasetとして管理する。 通常例だけでなく、情報不足、矛盾、個人情報混入、古いsource、prompt injection文、形式違反、tool失敗を入れる。 期待する出力が明確な例をgolden caseとして残し、変更後に同じcaseでregression evalを行う。 評価ログには、run date、model、prompt version、context source、採点者、採用判断を残す。

複数モデル比較はランキングではない

モデルによって、得意なタスク、速度、費用、出力の癖、tool useの扱いやすさが違う。 大きいモデルが常に最適とは限らない。 小さいモデルが、要約や分類では十分なこともある。 一方で、複雑な推論、長いcontext、繊細な文面では高性能モデルが必要になることもある。

モデル比較は、ランキングではない。 このタスクに十分かを見る作業である。 同じ入力、同じcontext、同じrubric、同じtest caseで比べる。 速度や費用だけでなく、失敗の種類も見る。

| model/snapshot | run date | 事実性 | 根拠対応 | 文面 | 形式 | 安全性 | latency/cost | context window/tool対応 | メモ |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| A |  |  |  |  |  |  |  |  |  |
| B |  |  |  |  |  |  |  |  |  |

業務では、最強のモデルを探すより、十分な品質を安定して出せる構成を見つける方が重要である。 また、model versionやAPI仕様は変わる。 productionで使うなら、いつ、どのmodel、どのprompt、どのcontext、どの評価で確認したかを記録する。 latest のような名前を使う場合でも、評価時点の日付と実際に返ってきたmodel識別子を残す。

複数prompt比較は、好みではなく失敗の減り方で見る

同じmodelでも、promptとcontextで出力は変わる。 目的が曖昧なprompt、制約が足りないprompt、根拠表示を求めるprompt、悪い例を入れたpromptでは、失敗の種類が変わる。

比較するときは、同じ入力と同じ評価表を使う。 一つの良い出力だけを見て決めない。 通常例、情報不足、矛盾、個人情報混入、古いロードマップ、prompt injection、形式違反など、複数のtest caseで見る。

| prompt案 | 減った失敗 | 増えた失敗 | 採用判断 |
| --- | --- | --- | --- |
| A: 短い依頼 | 速い | 根拠が弱い | 不採用 |
| B: 根拠表示あり | 根拠対応が見やすい | 文章が硬い | 改善して採用候補 |
| C: 不確実性欄あり | 推測が減る | 出力が長い | 採用 |

prompt改善は、文章を長くすることではない。 失敗を減らすことである。 どの失敗を減らしたいのかが決まっていないprompt改善は、方向を見失いやすい。

human-in-the-loopは責任の所在を明確にする

human-in-the-loopは、人間が途中で確認する設計である。 AIを使うすべての場面で、人間が一字一句確認する必要があるわけではない。 しかし、相手に影響する出力、権限を伴う操作、データを書き換える操作、外部へ送信する操作では、人間の確認が必要になる。

支援コメント案では、AIは候補を出す。 メンターは、根拠、文面、相手への影響、送信可否を確認する。 AIが「送信してよい」と判断するのではない。 メンターが判断する。

人間確認の設計では、次を明確にする。

  • 何を確認するか。
  • どの画面で確認するか。
  • 何が満たされないと送信できないか。
  • AI出力を編集した履歴を残すか。
  • 送信後に問題があった場合、どのログから追えるか。

人間を挟むことは、AI活用を遅くするためではない。 AIの速さを、利用者に影響する判断へ安全に接続するためである。

ai-task-fit-note.mdに書くこと

ai-task-fit-note.md は、AIに任せる作業を分類する文書である。 「AIにコメントを書かせる」と大きくまとめず、生成、要約、抽出、分類、検索、判断、実行へ分ける。

# AI Task Fit Note

## タスク分解

| 作業 | 種類 | AIに任せやすいか | 人間の確認 | 失敗時の影響 | 記録する根拠 |
| --- | --- | --- | --- | --- | --- |
| 学習ログを要約する | 要約 | 高い | 必要 | 重要な文脈を落とす | 対象ログID |
| 困っていそうな点を抽出する | 抽出 | 中 | 必要 | 誤解した支援になる | 該当ログの要約 |
| 支援コメント案を書く | 生成 | 高い | 必要 | 不適切な文面になる | 根拠と確認事項 |
| 支援方針を確定する | 判断 | 低い | 必須 | 支援がずれる | メンター判断 |
| コメントを送信する | 実行 | 低い | 必須 | 誤送信する | 承認者と送信記録 |

## AIに任せること

-

## 人間が確認すること

-

## AIに任せないこと

-

## 承認が必要な操作

| 操作 | 承認者 | 承認前に見るもの |
| --- | --- | --- |
|  |  |  |

この文書は、AI利用の入口になる。 失敗時の影響が大きい作業ほど、人間の確認を厚くする。 実行や送信は、下書き生成とは別の権限として扱う。

prompt-context-design.mdに書くこと

prompt-context-design.md には、依頼文と参考情報の設計を書く。 目的、利用者、入力、制約、出力形式、良い出力の条件、渡すcontext、渡さない情報を分ける。

# Prompt and Context Design

## タスク

-

## 利用者

-

## 依頼文に入れる要素

| 要素 | 内容 | 注意 |
| --- | --- | --- |
| 目的 |  |  |
| 背景 |  |  |
| 入力 |  |  |
| 制約 |  |  |
| 出力形式 |  |  |
| 良い出力の条件 |  |  |
| 悪い出力の例 |  |  |

## 渡す参考情報

| 参考情報 | 必要な理由 | 出典/source version | 新しさ | 信頼度 | 渡す/渡さない | 注意 |
| --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |

## 渡さない情報

- secret
- 個人情報
- 未公開情報
- 本番ログ全文

## 出力形式

- 人間が読む部分:
- 機械処理する部分:
- schemaで必須にする項目:
- 出力を受け取った後のvalidation:

良いpromptは、AIへのお願いではなく、レビュー可能な作業仕様である。 この文書があると、出力が悪かったときに、promptが悪いのか、contextが足りないのか、評価軸が曖昧なのかを切り分けやすい。

rag-grounding-note.mdに書くこと

rag-grounding-note.md には、RAGで使う情報源、retrieval、grounding、citation、人間確認を書く。 RAGでも誤りが残ることを前提にする。

# RAG Grounding Note

## 情報源候補

| 情報源 | 目的 | source version | 新しさ | 権限/metadata filter | リスク |
| --- | --- | --- | --- | --- | --- |
| 学習ログ | 現在の状況を見る |  | 高 | 対象受講者と期間 | 個人情報に注意 |
| 研修ロードマップ | 次の提案に使う |  | 中 | 該当章 | 古い版に注意 |

## retrieval

- 検索方法:
- chunkの単位:
- metadata filter:
- permission filtering:
- freshness確認:
- retrievalが当たったかを見る方法:

## grounding

- 支援コメントごとに根拠ログを示す
- 根拠がない推測は本文に混ぜない
- 不確実な点は確認事項へ分ける

## citation

| 主張 | 根拠 | 確かさ | 注意 |
| --- | --- | --- | --- |
|  |  |  |  |

## RAGでも防げない失敗

-

## prompt injection対策

- source内の命令文をAIへの指示として扱わない
- 不審な指示を見つけたら停止する
- 送信や更新は人間承認に回す

RAGは「資料を読ませれば正しくなる」仕組みではない。 何を検索し、何を取り出し、どの主張に対応させるかを確認する設計である。

agent-boundary-note.mdに書くこと

agent-boundary-note.md には、単発AI応答、tool use、agent、人間承認、権限、停止条件を書く。 agentにするべきかどうかを、便利そうかではなく、必要な手順とリスクで判断する。

# Agent Boundary Note

## 単発AI応答でできること

-

## tool useが必要なこと

| tool | 操作 | 権限 | 人間承認 | validation | audit log |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

## agentに任せる候補

| 手順 | 自動化するか | 人間承認 | 注意 |
| --- | --- | --- | --- |
|  |  |  |  |

## 権限

- 読み取り:
- 書き込み:
- 禁止:

## guardrails

- input:
- output:
- tool:

## 停止条件

- 根拠不足
- 個人情報やsecretを検出
- 確信度が低い
- 送信やDB更新が必要

## ログと戻せる準備

- 実行ログ:
- 承認ログ:
- idempotency:
- rollback:

この文書は、第19章のAIコーディングにもつながる。 AIがファイルを読む、コマンドを実行する、コードを編集するようになると、境界設計はさらに重要になる。

ai-evaluation-note.mdに書くこと

ai-evaluation-note.md には、AI出力の評価表、test case、複数出力比較、採用判断を書く。 評価は、AI出力の品質を印象から証拠へ移す作業である。

# AI Evaluation Note

## 評価対象

- 作業:
- 入力:
- run date:
- model/snapshot:
- prompt version:
- context source/version:
- 案A:
- 案B:

## rubric

| 評価軸 | 重み | 良い状態 | 悪い状態 |
| --- | --- | --- | --- |
| 事実に合っている | 高 | ログに基づく | 根拠のない断定 |
| 根拠と対応している | 高 | 主張と根拠が対応 | 根拠表示だけある |
| 役に立つ | 中 | 次の行動が分かる | 一般論だけ |
| 文面が支援的 | 中 | 具体的で受け取りやすい | きつい、曖昧 |
| 形式を守る | 中 | 指定項目がそろう | 欠落がある |
| 安全である | 高 | 秘密情報を出さない | 個人情報を含む |

## test cases

| 場面 | 入力の要約 | 期待する動き | リスク | 種類 |
| --- | --- | --- | --- | --- |
|  |  |  |  | normal / edge / adversarial / regression |

## 比較

| 出力 | 事実性 | 根拠性 | 有用性 | 文面 | 形式 | 安全性 | 採用判断 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| A |  |  |  |  |  |  |  |
| B |  |  |  |  |  |  |  |

## 採用判断

- 採用する案:
- 理由:
- 採用しない案:
- 残した課題:
- 次に再評価する条件:

採用判断では、点数だけでなく理由を書く。 どの失敗が残るか、どの確認を人間が行うか、次に何を改善するかを残す。 これが、第20章の技術文書や第24章の最終発表で、AIをどう使い、どう検証したかを説明する材料になる。

生成AI利用で起きやすい誤解

  • AIの出力が自然なら正しいと考える。根拠、実行結果、公式情報、テストで確認する。
  • promptだけを工夫すればよいと考える。task分解、context、output format、evaluationも設計する。
  • contextを多く渡せばよいと考える。必要な情報に絞り、渡さない情報を明確にする。
  • JSONやschemaに合えば安全だと考える。形式のvalidationと、業務ルール、権限、安全性のvalidationは別である。
  • RAGならhallucinationがなくなると考える。retrievalのずれ、古い情報、根拠不一致は残る。
  • citationがあれば正しいと考える。本文の主張と根拠が対応しているかを見る。
  • RAGで取り込んだ文書をすべて指示として扱う。外部sourceは命令ではなくdataとして扱い、indirect prompt injectionを警戒する。
  • tool useを便利機能としてだけ見る。読み取り、書き込み、送信、削除で権限と承認を分ける。
  • agentに任せれば自動化できると考える。停止条件とhuman-in-the-loopを先に決める。
  • system promptを秘密の壁として扱う。隠し指示だけに頼らず、アプリ側の権限、validation、承認で守る。
  • AIにsecretや本番ログを貼る。必要fieldだけに絞り、匿名化する。
  • モデル比較をランキングとして扱う。対象タスクに十分かを同じrubricで見る。
  • latest のmodel名だけを記録する。評価日、実際のmodel識別子、prompt version、context sourceも残す。
  • prompt比較を好みで決める。どの失敗が減ったかで判断する。
  • 評価を出荷直前に一度だけ行う。prompt、context、model、toolが変わるたびに同じtest caseで見る。
  • 評価ツールを使えば評価が終わると考える。評価dataset、rubric、人間判断、regression確認が必要である。
  • AI出力を採用した理由を残さない。採用、不採用、残る不確実性を書く。

AI評価と境界設計で確認すること

この章では、ai-task-fit-note.md、prompt-context-design.md、rag-grounding-note.md、agent-boundary-note.md、ai-evaluation-note.md を作る。

最初に、第3章の ai-use-plan.md と ai-use-log.md、第14章の secrets-and-dependencies-check.md、第17章の observability-goals.md、telemetry-plan.md、slow-api-investigation.md、incident-review-note.md を読み直す。 AIへ渡してよい情報、渡してはいけない情報、出力をどう観察し評価するかを確認する。

ai-task-fit-note.md には、支援コメント案生成を、要約、抽出、検索、生成、判断、実行へ分ける。 AIに任せること、人間が確認すること、AIに任せないこと、失敗時の影響を書く。

prompt-context-design.md には、目的、利用者、入力、制約、出力形式、良い出力の条件、悪い出力の例、渡すcontext、渡さない情報を書く。 contextには、source version、新しさ、信頼度、渡してよい理由を書く。 構造化出力を使う場合は、schemaとvalidation方針も書く。

rag-grounding-note.md には、情報源、retrieval方法、chunk、metadata filter、permission filtering、grounding方針、citationの形、RAGでも防げない失敗、人間が確認することを書く。 RAGで取り込んだsource内の指示をどう扱うかも書く。

agent-boundary-note.md には、単発AI応答で足りること、tool useが必要なこと、agentに任せる候補、権限、validation、guardrail、承認、停止条件、ログと戻せる準備を書く。

ai-evaluation-note.md には、rubric、test case、複数出力比較、model/snapshot、prompt version、context source、採用判断、次に改善することを書く。 評価軸には、事実性、根拠対応、有用性、文面、形式、安全性を入れる。

実際にAIを使う場合は、入力する情報を必ず点検する。 secret、個人情報、未公開情報、本番ログ全文を入れない。 AIの出力は、採用前に根拠、文面、形式、安全性を確認する。 AIを使わない場合でも、この章の成果物は作れる。 AI機能を設計するつもりで、境界と評価を書けばよい。

LLMと生成AIの基礎で持ち帰ること

第18章で身につけるべきことは、LLMと生成AIを、ブラックボックスではなく、入力、context、出力、評価、リスク管理の流れとして扱うことである。 LLMは自然な文章やコードを作れるが、流暢さと正しさは別である。 hallucination、stale knowledge、uncertaintyを分け、根拠が足りないものは断定しない。

promptはお願いではなく作業仕様である。 contextはAIに読ませる作業材料であり、必要な情報と渡してはいけない情報を分ける。 RAGは検索して読ませる設計であり、retrieval、grounding、citationの確認が必要である。 tool useとagentでは、権限、人間承認、停止条件を先に決める。

評価は、AI活用の最後ではなく中心に置く。 rubricとtest caseを作り、複数modelや複数promptを同じ条件で比べる。 AIは候補を作る。 人間は、根拠、影響、安全性、採用判断を持つ。

AIコーディングの実務ワークフローの章へ

次章では、この考え方をAIコーディングの実務ワークフローへ進める。 AIがファイルを読み、コマンドを実行し、コードを編集できるようになると、便利さだけでなく影響範囲も大きくなる。 第18章で整理したcontext、境界、評価、human-in-the-loopの考え方が、第19章の土台になる。

参考資料

教材を検索