これまでとの接続——「作らせる」から「組み込む」へ
カテゴリSまでで、Webアプリを安全に作り、公開し、運用する力を身につけました。ここから始まるT章は、講座全体の集大成です。これまでのA章では、AIを開発の道具として使い、AIにコードを作らせることを学びました。T章で扱うのは、その裏返しの視点です。利用者の入力をAIが処理するアプリ、つまりAIを部品として組み込んだアプリを、安全に作る技術を学んでいきます。
このスライドのポイント
- カテゴリSまでで、Webアプリを安全に作り・公開し・運用する力を身につけた
- A章の視点: AIを「開発の道具」として使い、AIにコードを作らせる
- T章の視点: AIを「アプリの部品」として組み込む（本章はこちら）
- 目的地: 利用者の入力をモデルが処理するアプリを、安全に作る
モデルとトークンの定義
用語を整理します。モデルとは、学習を終えたLLMの実体で、性能・速度・費用の異なる複数の中から選ぶ対象です。これはN-10で学んだ技術選定が、そのまま当てはまる場面です。トークンは、A-05で見たとおり、LLMが文字列を処理する単位でした。ここで重要な事実を一つ加えます。トークンは処理の単位であると同時に、課金の単位でもあります。S-10で触れたAIの利用料の正体は、入力と出力のトークン数で費用が決まる、という仕組みだったのです。なお呼び出しはK章で学んだ外部API利用の一種であり、鍵の管理はK-05やQ-08の考え方がそのまま適用されます。
このスライドのポイント
- モデル＝学習を終えたLLMの実体。性能・速度・費用が異なる複数から選ぶ対象（N-10の技術選定）
- トークン＝LLMが文字列を処理する単位（A-05で定義済み。ここで課金の面を深掘り）
- 重要な追加: トークンは処理の単位であると同時に「課金の単位」
- S-10の「AIの利用料」の正体＝入力と出力のトークン数で費用が決まる
- 呼び出しはK章の外部API利用の一種（鍵の管理はK-05／Q-08をそのまま適用）
なぜ必要か——知らないと費用と遅延が爆発する
この関係を知らないと、何が起きるでしょうか。まず、AI機能の費用をS-10のように見積もれなくなります。費用はトークン数で決まるのですから、トークンを意識しなければ概算すら立ちません。さらに危険なのは、長い文章をそのまま全部モデルへ送る設計です。入力トークンが膨らみ、費用と応答の遅延がともに大きくなりますが、仕組みを知らなければこの事故を設計段階で見抜けません。
このスライドのポイント
- 費用がトークン数で決まる以上、トークンを意識しないとS-10の見積もりが立たない
- 危険な設計: 長い文章をそのまま全部モデルへ送る
- 結果: 入力トークンが膨らみ、費用と応答の遅延がともに増大
- 仕組みを知らなければ、この事故を設計段階で見抜けない
構造——LLM呼び出しの基本図と費用の式
モデルの呼び出しを一枚の図で捉えます。アプリのサーバー、これはJ章で学んだ処理の担い手ですが、そこから入力トークンをモデルへ送り、モデルが出力トークンを返し、それをアプリが受け取ります。費用は、この両側のトークン数に単価を掛けた合計で決まります。式で書けば、費用は入力トークン数と出力トークン数の合計に単価を掛けたもの、です。もう一つ大事な点があります。呼び出しは必ずアプリのサーバー側から行います。これはK-05で学んだ、鍵を利用者に見せないための守りだからです。
このスライドのポイント
- 呼び出しの流れ: アプリのサーバー（J章）→［入力トークン］→モデル→［出力トークン］→アプリ
- 費用 ＝（入力トークン数 ＋ 出力トークン数）× 単価
- 呼び出しは必ずサーバー側から行う（鍵を利用者に見せない＝K-05）
具体例——経費アプリに勘定科目提案のAI機能を足す
具体例で感覚をつかみましょう。この章では、これまで作ってきた経費アプリに、領収書の但し書きから勘定科目を提案するAI機能を足す想定で進めます。以降の講義でも、この機能を少しずつ育てていきます。たとえば但し書きの一文をモデルへ送り、提案された科目を受け取る。この一回のやり取りで、入力と出力にそれぞれどれだけのトークンが使われるかを意識してみてください。この感覚が、費用と品質の両方を自分で見積もる第一歩になります。
このスライドのポイント
- 本章の共通例: 経費アプリに「領収書の但し書きから勘定科目を提案する」AI機能を足す
- この機能を以降の講義でも少しずつ育てていく
- 一回のやり取り: 但し書きの一文を送る（入力）→提案された科目を受け取る（出力）
- 意識する感覚: この一回で入力・出力にどれだけのトークンを使うか
技術サンプルカード——呼び出しの基本図と費用の式
サンプルは、いま説明した呼び出しの基本図と費用の式そのものです。読み方の要点は二つあります。一つ、モデルの選定は性能と速度と費用のトレードオフであり、N-10で学んだ技術選定の判断がそのまま生きること。二つ、モデルの世代や名称は移り変わりが速いため、設計は特定のモデルに縛らず、差し替え可能にしておくことです。AIへ設計を相談するときは、この機能の一回あたりの入出力トークン量を見積もり、月間の利用回数から費用の概算を出してほしい、と頼むとよいでしょう。
混同しやすい概念——「作らせる」と「組み込む」
ここで、章全体を貫く視点の違いを固定します。A章で学んだのは、AIを開発の道具として使い、AIにコードを作らせることでした。一方このT章で学ぶのは、AIをアプリの部品として組み込むことです。前者ではAIはあなたの隣にいる開発の相棒でしたが、後者ではAIはあなたが作るアプリの中で動く一つの機能になります。同じAIでも、道具として使うのか、部品として組み込むのか。この区別を、章の最後まで見失わないでください。
バイブコーディングでの確認点——入力に何を渡すかを最初に決める
AI機能を設計するときの確認点です。最初に必ず決めるべきは、入力に何を渡すか、です。すべてを渡してはいけません。渡すトークンの量が、費用と品質の両方を同時に左右するからです。この選択は、次回学ぶコンテキストの設計へとつながる、最初の分かれ道になります。AIに相談するときは、このAI機能は一回の呼び出しで入力に何を渡す設計か、そして渡さないものは何か、を明確にしてもらうとよいでしょう。
このスライドのポイント
- AI機能の設計で最初に決めること: 入力に何を渡すか（すべては渡さない）
- 理由: 渡すトークン量が費用と品質の両方を同時に左右する
- これは次回のコンテキスト設計への最初の分かれ道
- AIへの質問例: 「このAI機能は1回の呼び出しで入力に何を渡す設計ですか。渡さないものは何ですか」
まとめと次回への橋渡し
最後に一問一答です。LLMの費用を決める単位は何でしょうか。……答えは、トークンです。入力と出力の量で費用が決まります。今日の30秒まとめです。モデルは選ぶ対象であり、トークンは処理と同時に課金の単位。呼び出しはサーバー側から行い、費用は入力と出力のトークン数の合計に単価を掛けて決まります。次回は、一度に渡せる情報量の上限、コンテキストウィンドウを学びます。関連資料は、AI利用料の見積もり入門と、AIモデル・AIツール比較マップです。
このスライドのポイント
- 一問一答:「LLMの費用を決める単位は？」→ トークン（入力と出力の量）
- 30秒まとめ: モデルは選ぶ対象／トークンは処理と課金の単位／呼び出しはサーバー側から／費用＝（入力＋出力トークン数）×単価
- 次回: 一度に渡せる情報量の上限「コンテキストウィンドウ」へ
- 関連資料: 「AI利用料の見積もり入門」「AIモデル・AIツール比較マップ」
