大規模言語モデル (LLM) は強力ですが、制限があります。 既定で実行できる LLM と、それらを調整して生成 AI アプリに最適な結果を得る方法を知る必要があります。 この記事では、LLM の主な課題について説明し、構築する生成 AI 機能の種類に関係なく、それらを解決し、コンテンツの生成方法を改善する簡単な方法を示します。
LLM を使用するときのエンジニアリングの課題
LLM を使用する際に留意すべき最も重要な課題と制限事項を次に示します。
知識のカットオフ: LLM は、特定の日付までにトレーニングされた内容のみを認識します。 外部データ接続がないと、リアルタイムまたは個人情報にアクセスできません。
幻覚: LLM は不正確または誤解を招く情報を生成する可能性があります。 Microsoft Foundry の Groundedness 検出機能は、LLM の応答が提供するソース資料に基づいているかどうかを判断するのに役立ちます。 根拠のない応答には、データでサポートされていない情報が含まれます。 この クイック スタートで接地検出を使用する方法について説明します。
透明性: 生成されたコンテンツのソースまたは精度を常に追跡できるわけではありません。また、組み込みの検証手順はありません。
ドメイン固有の知識がありません。LLM は、統合しない限り、内部データまたは独自のデータを認識しません。
対話から学習できない: LLM には過去の対話に関する記憶や認識がないため、ユーザーのフィードバックに基づいて時間の経過と同時に適応したり改善したりすることはできません。 これらの課題を克服し、最良の結果を得るには、LLM の知識を独自のデータで補完し、検証ツールを使用します。
LLM が情報を取得する場所
LLM は、書籍、記事、Web サイト、およびその他のソースからの大規模なデータセットに対してトレーニングされます。 応答にはこのデータのパターンが反映されますが、トレーニングのカットオフ後に発生した内容は含まれません。 外部接続がないと、LLM はリアルタイム情報にアクセスしたり、インターネットを閲覧したりできないため、古い回答や不完全な回答につながる可能性があります。
推論のしくみに影響を与える要因
LLM を使用すると、モデルが会話全体を記憶しているように見える場合があります。 実際には、送信する新しいプロンプトごとに、以前のすべてのプロンプトとモデルの応答が含まれます。 LLM は、この完全な履歴をコンテキストとして使用して、次の回答を作成します。 この実行中の履歴は コンテキスト ウィンドウです。
各 LLM には、モデルとバージョンによって変更される最大コンテキスト ウィンドウ サイズがあります。 会話がこの制限を超えた場合、モデルは最も古い部分を削除し、その回答で無視します。
コンテキスト ウィンドウが長いほど、モデルはより多くのデータを処理する必要があり、処理速度が低下し、コストが高くなる可能性があります。
コンテキスト ウィンドウのサイズは、単語ではなくトークンを使用します。 トークンは、モデルが処理できるテキストの最小部分です。これらの部分は、言語とトークナイザーに応じて、単語全体、単語の一部、または単一の文字である可能性があります。
開発者にとって、トークンの使用は次の影響を直接受けます。
- モデルが考慮できる会話履歴の最大量 (コンテキスト ウィンドウ)
- 各プロンプトおよび完了のコストは、課金が処理されたトークンの数に基づいているため決まります。
トークン化とは
トークン化 とは、テキストをトークンに分割するプロセスであり、モデルが処理できる最小単位です。 トークン化は、LLM を使用したトレーニングと推論の両方に不可欠です。 言語とトークナイザーによっては、トークンが単語全体、サブワード、または 1 文字である場合があります。 トークン化は、スペースと句読点で分割するのと同じくらい簡単にすることも、言語構造と形態を考慮したアルゴリズムを使用するのと同じくらい複雑な場合もあります。
OpenAI トークナイザー ページでは、トークン化について詳しく説明し、文をトークンに分割する方法を示す電卓が含まれています。
一般的な英語のテキストでは、1 つのトークンは約 4 文字です。 平均して、100 個のトークンは約 75 語です。
開発者にとって、次のライブラリは、プロンプトと入力候補のトークン数を見積もるのに役立ちます。これは、コンテキスト ウィンドウの制限とコストを管理するのに役立ちます。
- tiktoken ライブラリ (Pythonおよび JavaScript)
- Microsoft.ML.Tokenizers ライブラリ (.NET)
- Hugging Face Tokenizers ライブラリ (JavaScript、Python、Java)
トークンの使用が課金に影響する
OpenAI API Azureごとに異なる課金方法があります。 Responses または Chat Completions API を使用してテキストを処理および生成する場合は、プロンプトとして送信したトークンの数と、結果として生成されたトークンの数 (完了) に基づいて課金されます。
各 LLM モデル (GPT-5.2、GPT-5.2-mini など) には通常、トークンの処理と生成に必要な計算量を反映する異なる価格があります。 多くの場合、価格は "1,000 トークンあたりの価格" または "100 万トークンあたりの価格" として表示されます。
この価格モデルは、ユーザー操作の設計方法と、追加する前処理と後処理の量に大きな影響を与えます。
システム プロンプトとユーザー プロンプト
ここまで、この記事では ユーザー プロンプトについて説明しました。 ユーザー プロンプトは、モデルに送信する内容と、モデルが応答する内容です。
OpenAI では、 システム プロンプト (または カスタム命令) も追加されました。 システム プロンプトは、すべてのチャットに追加するルールのセットです。 たとえば、LLM に "常に俳句形式で回答する" よう指示できます。その後、すべての答えは俳句になります。
この俳句の例は、プロンプトを変更して LLM の回答を変更する方法を示しています。
ユーザーのプロンプトを変更する理由 仕事、顧客、またはパートナー向けの生成型 AI アプリを構築する場合は、モデルが回答できる内容を制限するルールを追加できます。
ただし、ユーザー プロンプトを変更することは、テキスト生成を向上させる 1 つの方法にすぎません。
ユーザーのテキスト生成エクスペリエンスを向上させるメソッド
テキスト生成の結果を改善するために、開発者は単にプロンプトを改善することに限定されており、役立つプロンプト エンジニアリング手法が多数あります。 ただし、独自の生成型 AI アプリケーションを構築する場合は、ユーザーのテキスト生成エクスペリエンスを向上させるいくつかの方法があり、それらのすべてを実装して実験する必要があります。
- プログラムによってユーザー プロンプトを変更します。
- 推論パイプラインを実装します。
- Retrieval-Augmented 世代 (他の記事で説明)。
- 微調整 (他の記事で説明)。
プログラムによってユーザー プロンプトを変更する
ユーザーの会話にシステム プロンプトを追加するには、特別な API を使用しません。 必要に応じて、プロンプトに指示を追加するだけです。
ただし、いくつかの手法を使用して、ユーザー プロンプトを改善できます。
- コンテキスト プライミング: ドメイン内の会話のコンテキストを明示的に設定するシステム プロンプトを作成します。 このアプローチでは、各操作の開始時に簡単な説明または一連の手順を提供します。 この手順では、AI が問題のドメイン内に留まるようにガイドします。
- サンプル ベースのガイダンス: 最初のプロンプトに、ドメインに関連する質問と回答の種類の例を含めます。 このアプローチは、AI が期待する応答の種類を理解するのに役立ちます。
任意のプロンプト エンジニアリング手法を使用できます。 プログラムで実行できる場合は、ユーザーの代わりにユーザー プロンプトを改善できます。
この方法に対する注意事項は、プロンプトが長いほど、LLM への各呼び出しのコストが高くなることです。 それでも、この方法は、この記事で説明する最も安価なアプローチである可能性があります。
推論パイプラインを実装する
ユーザーのプロンプトを改善したら、次の手順として推論パイプラインを構築します。
推論パイプラインは、次のプロセスです。
- 生の入力 (テキストや画像など) をクリーンアップする
- それをモデルに送信する (前処理)
- モデルの回答を確認して、表示する前にユーザーのニーズを満たしていることを確認します (後処理)。
前処理には、キーワードのチェック、関連性のスコア付け、ドメインに合わせてクエリを変更することが含まれます。 たとえば、ユーザーの最初のプロンプトを確認します。 プロンプトが理にかなっているか、ルールに従っているか、正しいアイデアに基づいているか、偏りを避けるために書き直す必要があるかどうかを LLM に問い合わせてください。 LLM が問題を検出した場合は、プロンプトを書き直して、より良い回答を得るように依頼できます。
後処理は、回答がドメインに適合し、標準を満たしているかどうかを確認することを意味します。 ルールに一致しない回答を削除したり、フラグを設定したりできます。 たとえば、LLM の回答を調べて、品質と安全性のニーズを満たしているかどうかを確認します。 LLM に回答を確認し、必要に応じて変更するように依頼できます。 適切な結果が得られるまで、このプロセスを繰り返します。
注意してください。推論パイプラインで LLM を呼び出すたびに、応答に時間がかかり、コストが高くなります。 これらのトレードオフと、予算、速度、システムの動作のバランスを取る必要があります。
推論パイプラインを構築するために実行する具体的な手順については、「高度な取得拡張生成システムを構築する」を参照してください。
完了に影響を与えるその他の要因
プロンプトのプログラムによる変更、推論パイプラインの作成、その他の手法に加えて、取得拡張生成と微調整を使用した大規模言語モデルの拡張に関するページで詳しく説明します。 また、Azure OpenAI API を呼び出すときにパラメーターを変更することもできます。
モデルの出力に影響を与えるために調整できる主要なパラメーターの一部を次に示します。
: モデルによって生成される出力のランダム性を制御します。 0 の場合、モデルは決定論的になり、トレーニング データから最も可能性の高い次のトークンを一貫して選択します。 1 の温度では、高確率トークンの選択と出力へのランダム性の導入のバランスがモデルによって調整されます。
: 応答の最大長を制御します。 上限または下限を設定すると、生成されたコンテンツの詳細と範囲に影響する可能性があります。
(核サンプリング): 応答のランダム性を制御するために と共に使用されます。 では、各トークンを生成するときに、AI が確率質量 () の上位パーセントのみを考慮するように制限されます。 値を小さくすると、テキストのフォーカスが高くなり、予測しやすくなります。 値が大きいほど、多様性が高くなります。
: モデルが同じ行または語句を繰り返す可能性を減らします。 この値を大きくすると、生成されたテキストの冗長性を回避できます。
: モデルに、完成時に新しい概念と用語を導入するよう奨励します。 は、より多様でクリエイティブな出力を生成するのに役立ちます。
: 1 つ以上のシーケンスを指定して、より多くのトークンの生成を停止するように API に指示できます。 は、文や段落の末尾で完了を終了するなど、出力の構造を制御するのに役立ちます。
: 指定したトークンが完了に表示される可能性を変更できます。 を使用して、完了を特定の方向に導いたり、特定のコンテンツを抑制したりできます。
Microsoft Azure OpenAI セーフガード
LLM の応答を特定の主題またはドメインに限定したままにすることに加えて、ユーザーが LLM について尋ねている質問の種類についても懸念している可能性があります。 生成される回答の種類を考慮することが重要です。
まず、Microsoft Foundry の Microsoft Azure OpenAI モデルを呼び出す API 呼び出しでは、API が不快と思われるコンテンツが自動的にフィルター処理され、多くのフィルターカテゴリで報告されます。
コンテンツ モデレーション API を直接使用して、潜在的に有害なコンテンツがないかコンテンツを確認できます。
次に、Azure AI Content Safety を使用して、テキスト モデレーション、画像モデレーション、脱獄リスク検出、保護された素材の検出に役立ちます。 このサービスは、ポータルのセットアップ、構成、レポートエクスペリエンスと、アプリケーションに追加して有害なコンテンツを識別できるコードを組み合わせたものです。
AI エージェント
AI エージェントは、独自に動作する生成型 AI アプリを構築する新しい方法です。 LLM を使用してテキストの読み取りと書き込みを行い、外部のシステム、API、データ ソースに接続することもできます。 AI エージェントは、複雑なタスクを管理し、リアルタイム データを使用して選択を行い、ユーザーがそれらを使用する方法から学習できます。 AI エージェントの詳細については、「 クイック スタート: 新しいエージェントを作成する」を参照してください。
ツールの呼び出し
AI エージェントは、外部のツールと API を使用して、情報の取得、アクションの実行、または他のサービスとの接続を行うことができます。 この機能を使用すると、テキストを生成し、より複雑なタスクを処理するだけではありません。
たとえば、AI エージェントは、天気 API からリアルタイムの気象更新を取得したり、ユーザーの要求に基づいてデータベースから詳細を取得したりできます。 ツール呼び出しの詳細については、 Foundry ツール カタログ (プレビュー) のツールの検出と管理に関するページを参照してください。
モデル コンテキスト プロトコル (MCP)
モデル コンテキスト プロトコル (MCP) を使用すると、アプリは大規模な言語モデルに機能とコンテキストを提供できます。 MCP の主な機能は、AI エージェントがタスクを完了するために使用するツールを定義することです。 MCP サーバーはローカルで実行できますが、クラウド規模のツールを共有するためにリモート MCP サーバーが重要です。 詳細については、「モデル コンテキスト プロトコルを使用して Azure でビルド エージェントを構築する」を参照してください。
アプリケーション設計に関する最終的な考慮事項
トークン化、価格、コンテキスト ウィンドウについて理解し、プログラムによる改善を実装してユーザーのテキスト生成エクスペリエンスを強化することは、生成 AI システムの設計方法に影響します。
アプリケーションの設計上の決定に影響を与える可能性がある、この記事で考慮すべき事項とその他のポイントの簡単な一覧を次に示します。
- コストに関する考慮事項に対して、最新の AI モデルを使用する必要性を評価します。 コストの低いモデルは、アプリケーションのニーズに十分な場合があります。 パフォーマンスと予算の制約のバランスを取る。
- ユーザー エクスペリエンスに大きな影響を与えずにコストを管理するために、コンテキスト ウィンドウの長さを最適化することを検討してください。 会話の不要な部分をトリミングすると、品質の対話を維持しながら、処理料金が削減される可能性があります。
- トークン化と入力と出力の粒度がパフォーマンスに与える影響を評価します。 選択した LLM がトークン化をどのように処理するかを理解することで、API 呼び出しの効率を最適化し、コストを削減し、応答時間を向上させることができます。
すぐに生成型AIソリューションの構築を試したい場合は、「Pythonで独自のデータサンプルを使ってチャットを開始する方法」をご覧になることをお勧めします。 このチュートリアルは、.NET、Java、および JavaScript でも使用できます。