モデルを呼べるようになると、次に必ずぶつかるのが「なぜか途中で切れる」「思ったより高い」「出力が毎回バラバラ」といった悩みです。これらは全部、トークン・コンテキストウィンドウ・課金・パラメータという基本概念を知らないことが原因。逆にここを押さえると、コストも品質も自分でコントロールできるようになります。
「トークン」って結局なに？ 課金の単位もよく分からないし、温度とかmax_tokensとか、いじると何が変わるの？
この記事は Azure OpenAI シリーズの第3回として、AI とうまく付き合うための基本概念を次の流れで整理します。
- プロンプト / トークンを理解している
- コンテキストウィンドウを理解している
- 課金単位（入力 / 出力トークン）を理解している
- デプロイ種別（Standard / Provisioned / グローバル）の違いを理解している
- 基本パラメータ（温度 / top_p / max_tokens）を理解している
プロンプトとトークン｜AI が読む「文字のかたまり」
まず土台となる2語です。プロンプトはモデルへの入力（指示や質問）、トークンはモデルがテキストを処理する単位です。
トークンとは、モデルがテキストを扱うときの最小単位です。単語よりやや細かく、英語ならおおよそ「4文字＝1トークン」、日本語は1文字が1トークン以上になることもあります。
なぜトークンを気にするのかというと、「処理量の上限」も「料金」も、すべてトークンで数えられるからです。文字数ではなくトークン数で世界が回っている、と考えると腑に落ちます。長いプロンプトを投げれば、それだけ多くのトークンを消費し、料金も上限への圧迫も増える——この感覚を持っておくのが第一歩です。
【ここが説明できればOK①】
「プロンプトはモデルへの入力、トークンはテキストの処理単位。処理量の上限も料金もトークンで数える」——これを言えればOKです。
コンテキストウィンドウ｜AI の「一度に見渡せる範囲」
「長い会話をしていたら、最初の方の指示を忘れられた」——これに関わるのがコンテキストウィンドウです。
コンテキストウィンドウとは、モデルが1回のやり取りで扱える入力 + 出力の合計トークン数の上限です。この上限はモデルごとに異なります。
イメージは「AI の作業机の広さ」です。机が広い（コンテキストが大きい）モデルなら、長い文書や長い会話履歴をまとめて載せて考えられます。逆に机が狭いと、載せきれない古い情報は落ちてしまう。ここで大事な注意点が1つあります。
- コンテキストウィンドウは「入力」と「出力」の合計で数える。
- つまり、入力（プロンプト）を長くしすぎると、出力に使える余白が減る。長文を全部詰め込むと「答えが途中で切れる」のはこれが原因。
【ここが説明できればOK②】
「コンテキストウィンドウは入力+出力の合計トークンの上限でモデルごとに異なる。入力を長くしすぎると出力の余白が減る」——これを言えればOKです。
課金単位｜入力トークンと出力トークンは別料金
コストを読むうえで絶対に押さえたいのが、「入力トークンと出力トークンで単価が違う」という点です。多くのモデルで、出力トークンの方が高い傾向があります。
| 種類 | 何に対して課金されるか | 単価の傾向 |
|---|---|---|
| 入力トークン | 送ったプロンプト（システム＋会話履歴＋質問） | 相対的に安い |
| 出力トークン | モデルが生成した応答 | 入力より高いことが多い |
課金はおおむね1,000トークン単位の従量制です（正確な単価はモデル・時期で変わるため、最新は必ず公式の料金ページで確認してください）。この「入力と出力で別料金」を知っていると、コスト削減の勘所が見えてきます。たとえば、毎回同じ長い前置き（システムメッセージ）を送っている入力コストや、だらだら長い応答を生む出力コスト——どちらを削るべきかが判断できるようになります（具体策は第5回で扱います）。
【ここが説明できればOK③】
「入力トークンと出力トークンは単価が異なり（出力が高いことが多い）、おおむね1,000トークン単位で従量課金される」——これを言えればOKです。
デプロイ種別｜Standard / Provisioned / グローバル
第2回でモデルをデプロイしましたが、そのデプロイには種別（タイプ）があります。ここはコストと性能に直結するので、選び分けを押さえましょう。
| デプロイ種別 | 特徴 | 向いている場面 |
|---|---|---|
| Standard（従量） | 使ったトークン分だけ課金 | まず始める・トラフィックが読めない |
| Provisioned（PTU） | スループットを予約購入。安定したレイテンシと容量 | 安定した高負荷・応答速度を保証したい |
| グローバル（Global） | 複数リージョンに分散配置し可用性・単価を最適化 | コストと可用性のバランスを取りたい |
基本方針は「まず Standard（従量）で始める」で問題ありません。検証段階で固定費を持つのは無駄が多いからです。トラフィックが安定して大きくなり、「レイテンシを保証したい」「大量処理で単価を抑えたい」となったら Provisioned（PTU）やグローバルを検討する、という順番が実務的です（PTU は第5回でもう少し詳しく扱います）。
【ここが説明できればOK④】
「Standard は従量で手軽、Provisioned（PTU）はスループット予約で安定、グローバルは分散配置で最適化。まず Standard で始める」——これを言えればOKです。
基本パラメータ｜温度 / top_p / max_tokens
最後に、応答の質を左右する3つの基本パラメータです。これを知っていると「出力が毎回バラバラ」「途中で切れる」を自分で調整できます。
- temperature（温度）：出力のランダム性。低い（0 に近い）ほど毎回ほぼ同じ・堅実な答え、高いほど多様で創造的。事実回答は低め、アイデア出しは高め。
- top_p：候補となる単語を確率の上位何％に絞るか。temperature と似た効果を持つので、どちらか一方をいじるのが定石。
- max_tokens：出力の最大トークン数。答えが途中で切れる時はここを増やす。逆にコストを抑えたい時は上限として使う。
「答えがブレて困る→temperatureを下げる」「途中で切れる→max_tokensを上げる」。この2つだけ覚えておけば、まず困らないよ！
【ここが説明できればOK⑤】
「temperature と top_p は出力のランダム性を制御（どちらか一方）、max_tokens は生成の上限。事実回答は温度低め、切れる時は max_tokens を増やす」——これを言えればOKです。
まとめ
- トークン＝テキストの処理単位。上限も料金もトークンで数える
- コンテキストウィンドウ＝入力+出力の合計上限。入力を詰め込むと出力が切れる
- 課金は入力/出力で別単価（出力が高め）・1,000トークン単位
- デプロイ種別は Standard / Provisioned(PTU) / グローバル。まず Standard
- パラメータは temperature（ブレ）と max_tokens（長さ）を押さえる
基本概念を押さえたら、次は「本番で安全に使うための守り」と「自社データに答えさせる拡張」です。第4回で、キーレス認証・Private Endpoint・コンテンツフィルターといったセキュリティと、RAG・Function calling といった拡張をまとめて整理します。
