前回の続きと、この講義の役割
前回のT-02では、モデルは会話を記憶せず、アプリが履歴を毎回まとめて送り直しているという構造を学びました。では、その毎回送る内容は、どんな階層でできているのでしょうか。今回は、モデルへ渡す入力が3つの層に分かれていること、そして開発者が決める規則と利用者が入れる内容が、同じ文章として読まれることの意味を扱います。ここはAI機能の挙動と安全性の土台になる回です。
このスライドのポイント
- T-02: モデルは記憶せず、アプリが履歴を毎回まとめて送り直している
- 問い: では「毎回送る内容」はどんな階層でできているのか
- 今回の役割: モデルへ渡す入力が3層に分かれること、開発者の規則と利用者の入力が同じ文章として読まれることの意味
3つの指示レイヤーの定義
LLMへの入力には階層、つまり指示レイヤーがあります。1つ目はシステム指示です。これはアプリ開発者が決める役割や規則で、たとえば「あなたは経費の勘定科目を提案する係。科目は次の20種から選ぶ」といった土台の指示です。2つ目はユーザー入力、利用者がその場で入れる内容です。3つ目はモデル出力、生成された結果です。構造上の重要な性質として、モデルはシステム指示もユーザー入力も同じ文章として読みます。そのため、ユーザー入力に指示めいた文が混ざると、挙動が影響を受けることがあります。
このスライドのポイント
- 指示レイヤー: LLMへの入力が持つ階層のこと
- システム指示: アプリ開発者が決める役割・規則（例「あなたは経費の勘定科目を提案する係。科目は次の20種から選ぶ」）
- ユーザー入力: 利用者がその場で入れる内容
- モデル出力: 生成された結果
- 重要な性質: モデルはどちらも「文章」として読むため、入力に指示めいた文が混ざると挙動が影響を受けうる
なぜこの層を知る必要があるか
この層を知らないと、まず「AIの役割や規則はどこで決まっているのか」が分からず、AI機能を設計できません。システム指示という土台があるからこそ、AIは毎回同じ役割で動きます。さらに、利用者の入力を無防備にモデルへ流す危険にも気づけません。これはQ-06で学んだ「入力を信用しない」という原則の、AI版にあたります。開発者が守る土台と、疑ってかかる入力とを分けて考えることが出発点です。
このスライドのポイント
- 知らないと: AIの役割・規則がどこで決まるのか分からず、AI機能を設計できない
- システム指示という土台があるから、AIは毎回同じ役割で動く
- 知らないと: 利用者入力を無防備にモデルへ流す危険に気づけない
- これはQ-06「入力を信用しない」のAI版
3層の積層と、信頼境界の構造
3つの層を積み重ねた図で見てみましょう。一番下がシステム指示で、開発者だけが決められる固定の領域です。その上にユーザー入力があり、ここはQ-06のとおり信用しない領域として扱います。一番上がモデル出力で、これは検証の対象、つまり次回T-04で扱う確認の対象です。この積層は、J-06で学んだ信頼境界の図とそっくり同じ構造をしています。開発者が守る側と、利用者側は疑ってかかる側、という線引きが、そのまま当てはまります。
このスライドのポイント
- 積層図: 下からシステム指示→ユーザー入力→モデル出力
- システム指示: 開発者だけが決められる固定の領域
- ユーザー入力: 信用しない領域（Q-06）
- モデル出力: 検証の対象（次回T-04）
- J-06の信頼境界の図とそっくり同じ構造
勘定科目提案でのシステム指示
勘定科目を提案するAI機能で考えます。システム指示には、係としての役割、選べる科目の一覧、出力の形式、そしてしてはいけないことを書きます。利用者は、領収書の但し書き欄に文字を入れます。ここで、但し書きに変な文が入っても科目提案から逸脱しない、という設計が必要になります。システム指示で、やってよいこととやってはいけないことを明確に決めておくことが、その入口になります。
このスライドのポイント
- 対象: 勘定科目を提案するAI機能
- システム指示に書くこと: 役割・選べる科目の一覧・出力形式・してはいけないこと
- 利用者は「但し書き」欄に文字を入れる
- ねらい: 但し書きに変な文が入っても科目提案から逸脱しない設計
技術サンプルカード: システム指示の記入例
システム指示の記入例を見てみましょう。役割・規則・選択肢・形式・禁止事項という順で、8行に整理しています。読み方の要点は2つです。1つ、システム指示はアプリの仕様書であり、M章で決めた要件がここに翻訳されるという点。2つ、ユーザー入力とは分けて渡すという点です。提供事業者のAPIは、システム指示とユーザー入力を分離して渡す仕組みを備えているので、それを使います。
混同しやすい概念
混同しやすいのは、システム指示とユーザー入力です。システム指示は開発者が決める固定のルールで、ユーザー入力は毎回変わり、信用しない対象です。この2つを混ぜて1本の文章にしてモデルへ渡す実装は、危険の温床になります。利用者の入力が、そのまま命令として効いてしまう余地を残すからです。この悪用の名前と具体的な対策は、T-09でまとめて扱います。
バイブコーディングでの確認点
AI機能を実装するときは、「システム指示とユーザー入力は分離されていますか」と確認してください。もし1本の文字列に連結しているなら、そこが危険箇所です。提供事業者のAPIには両者を分けて渡す仕組みがあるので、それを使わせる形に直します。AIへの質問例としては、次のように聞けます。「このAI機能のシステム指示を見せてください。利用者の入力がどこに、どう挟まれるかも図で示してください」。
このスライドのポイント
- 実装時に確認: 「システム指示とユーザー入力は分離されていますか」
- 1本の文字列に連結しているなら、そこが危険箇所
- 提供事業者のAPIには両者を分けて渡す仕組みがある。それを使わせる
- AIへの質問例（下記ナレーション参照）
一問一答とまとめ
最後に一問一答です。開発者が決めるAIの役割・規則の層を、何と呼ぶでしょうか。……答えは、システム指示です。30秒でまとめます。LLMへの入力はシステム指示・ユーザー入力・モデル出力の3層に分かれ、モデルはどれも文章として読みます。だから開発者の指示と利用者の入力は分離して扱うことが、AI機能の安全の土台になります。次回T-04では、その出力を自由文でなく決まった形で受け取る、構造化出力へ進みます。関連資料は「開発プロンプト100選」「AIエージェント入門」です。
このスライドのポイント
- 一問一答: 開発者が決めるAIの役割・規則の層を何と呼ぶ？ → システム指示
- 30秒まとめ: 入力はシステム指示・ユーザー入力・モデル出力の3層／モデルはどれも文章として読む／だから開発者の指示と利用者の入力は分離する
- 次回T-04: 出力を「決まった形」で受け取る構造化出力へ
- 関連資料: 「開発プロンプト100選」「AIエージェント入門」
