このグロッサリーは、プロンプトエンジニアリングの全体像を理解するための100以上の必須用語をカバーしています。 基礎概念からエージェント・オーケストレーション、評価フレームワークまで。各用語には開発者とAI実践者向けの実践的な定義と、さらに詳しく学ぶための一次資料へのリンクを付けました。
構成は6つのカテゴリー：基本的なプロンプティング、エージェント＆オーケストレーション、安全性＆アライメント、評価＆テスト、高度なテクニック、メトリクス＆本番運用。表をクイックリファレンスとして活用し、個別の用語をクリックして各カテゴリーの詳細へジャンプできます。
日本での活用例
大手IT企業での実践： NTTデータ、富士通、アクセンチュアなどの大手SI企業は、カスタマーサポート自動化やドキュメント生成にプロンプトエンジニアリングを活用。Chain-of-ThoughtとRAGを組み合わせることで、複雑な業務フローの効率化と品質向上を実現しています。
製造業での活用： Sonyは製品開発プロセスの自動ドキュメント化と技術仕様の多言語化にプロンプト技術を導入。Toyotaは車両開発のエンジニアリングドキュメント作成と品質チェックにLLMを活用し、開発サイクルを短縮。RakutenのEC事業では、商品説明の自動生成とマーケティングコピーの多言語化にプロンプトエンジニアリングを適用。
金融・保険業での応用： メガバンクや大手保険会社は、コンプライアンス遵守の厳密性の中でプロンプトエンジニアリングを導入。信頼性と予測可能性が最重要であるため、安全性とアライメント、HALLUCINATIONの用語理解と対策が必須。
教育・研究機関： 大学や公的研究機関では、日本語LLM（Swallow、Llama 3.3 JP等）を活用した学術論文自動分析とデータ解析に本格的に取り組み始めています。
実践Tips：日本の開発チーム向け
## 日本語でのプロンプト設計
- システムプロンプトに背景文脈を明示： 「日本の金融規制に準拠して」「社内ドキュメント形式に従って」など、制約条件を詳細に記述。日本語は文脈依存性が高いため、曖昧な指示は避ける
- 敬語・丁寧語の使い分け： 出力の形式（顧客向けor社内報告書）を明確に指定することで、トーンの一貫性を保証。企業ブランドに合わせたスタイルを固定
- 日本語特有の表現をサンプルに含める： Few-Shotプロンプティングで、期待される日本語の自然さを示す例を5～7個提示。機械的な翻訳を避ける
## RAGと日本の社内データ
- ドキュメント準備： 社内マニュアル、技術仕様書、過去のナレッジベースを事前に整理。日本語の形態素解析（MeCab、Janomeなど）を使用して精度向上
- プライバシー対応： 個人情報や営業秘密が誤ってRAG検索結果に含まれないよう厳格なフィルタリング。GDPR・APPI対応も明示
- マルチモデル検証： Claude、Gemini、日本語特化モデル（Swallow、Qwen、Llama JP等）を複数試し、用途ごとに最適なモデルを選定
## モデル選択のベストプラクティス
- クラウドvs.ローカルの選別基準： データ保護が最優先（金融・医療）→ローカル運用（Ollama + Llama 4 Scout等）。リアルタイム性・高性能重視 → クラウドAPI（GPT-5.6、Claude）
- コスト効率化： 単純なタスク（テンプレート生成、要約）→軽量モデル（GPT-5.6 Luna、Claude Haiku）。複雑な推論 → 大規模モデル。本番前に必ずコスト試算
- 評価とロールアウト： 小規模なパイロット（10～100ユーザー）で品質・コスト検証後、段階的に本番展開。日本語品質の低下がないか継続監視
## 運用・監視のベストプラクティス
- ログ記録と監査： すべてのプロンプト入力と出力をログに記録。コンプライアンス要求や問題検証時に追跡可能な状態を維持
- 継続的な品質向上： ユーザーフィードバック、生成テキストの抽出精度、レイテンシメトリクスを定期的に計測。四半期ごとにプロンプト改善サイクル実施
- セキュリティとGuardrails： プロンプトインジェクション対策（入力検証）、不適切な出力フィルタ、レート制限を実装。重要なユースケースは人間レビューを組み込む
重要な注意点
ハルシネーション：日本語での事実誤認が特に危険。金融・医療・法務分野では、モデルが自信満々に誤った情報を生成する可能性。RAGで信頼できるデータソースのみを使用し、出力を常に検証する仕組みが必須。
プロンプトインジェクション：ユーザー入力を直接プロンプトに含める場合、悪意のある指示が意図を上書きする危険性。特に日本語では複雑な漢字・ひらがなの組み合わせでバイパスが可能なため、入力検証とサニタイズを強化。
コンテキストウィンドウ：日本語は1トークンあたりの文字情報が英語より少ないため、同じトークン数でも表現できる内容が制限される。長文ドキュメント処理の際は、より大きなコンテキストウィンドウを持つモデル（Claude 200K等）を選定。
ファインチューニングのコスト：日本語モデルのファインチューニングは計算リソースが多く必要。LoRA や QLoRA での軽量ファインチューニングを検討するほか、プロンプトエンジニアリング優先で効率化を図ることを推奨。
プロンプティングのコアコンセプト
エージェント＆オーケストレーション
セキュリティ＆アライメント
評価＆テスト
高度なテクニック
メトリクス＆プロダクション
よくある質問
プロンプトエンジニアリングを簡単に説明すると何ですか？
プロンプトエンジニアリングは、言語モデルが有用で予測可能、安全な出力を生成するようにプロンプトを設計・改善する分野です。指示の構造化、コンテキストの追加、および Few-Shot や Chain-of-Thought などのテクニックの選択が含まれ、信頼性と品質を向上させます。
ゼロショットとフューショットプロンプティングの違いは何ですか？
ゼロショットプロンプティングは、例を使わずに指示だけを使用してタスクを実行するようモデルに求めます。これはモデルの事前学習がパターンをすでにカバーしている一般的なタスクに最適です。フューショットプロンプティングは少数のインプット-アウトプット例をプロンプトに含めます。フューショットは通常、複雑または珍しいタスクで高い品質を生成します。
AI に RAG とは何ですか？
RAG は Retrieval-Augmented Generation の略です。ナレッジベースから関連ドキュメントを取得してプロンプトに挿入するアーキテクチャです。これにより、モデルはトレーニングだけに頼らず、最新でグラウンディングされたデータに基づいて回答します。これにより、ハルシネーションが削減され、回答が実際の現在の情報に基づいていることが保証されます。
プロンプトエンジニアリングとファインチューニングの違いは何ですか？
プロンプトエンジニアリングは、モデル自体を変更せずに、プロンプトを設計・改善してモデル出力を指導する分野です。ファインチューニングは、タスク固有のデータをトレーニングしてモデルの重みを修正します。プロンプトエンジニアリングは迅速、低コスト、反復が簡単です。ファインチューニングは専門的なタスクでより良い結果を達成できますが、より多くのデータと計算リソースが必要です。
AI のコンテキストウィンドウとは何ですか？
コンテキストウィンドウは、モデルが一度に考慮できるトークンの最大数です。システムプロンプト、会話履歴、取得したドキュメントを含みます。コンテキスト制限を超えると、古いまたは中央のコンテキストが切り詰められるか無視されます。コンテキストウィンドウのサイズを理解することは、コスト管理と遅延に重要です。より長いコンテキストはより高い処理コストがかかり、より遅くなります。
日本企業でプロンプトエンジニアリングを導入する際、最初に何をすべきですか？
日本企業での導入は、以下の3ステップで進めることをお勧めします：(1) 要件定義―業務フローを分析し、プロンプトエンジニアリングで自動化できる部分を特定（例：ドキュメント要約、顧客問い合わせの分類）、(2) パイロット実施―少規模なプロジェクトで複数のモデルを試し、日本語精度と応答品質を評価、(3) ガバナンス構築―出力の品質チェック、監査ログ、責任者の明確化など。金融・医療分野では特に、規制順守体制を同時に整備することが重要です。
Swallowなど日本語LLMと、GPT-5.6・Claudeのような大規模モデルの使い分けは？
Swallow（7B・70B）や他の日本語特化モデルは、小規模で軽量、プライベート環境での自社運用に適しています。一方、GPT-5.6やClaudeは大規模で高精度、複雑な推論やマルチタスク対応が優れています。実務的には、(1) 社内秘密・個人情報が含まれる処理は日本語LLMをオンプレ実行、(2) 複雑な分析・生成は規制要件を満たす前提でGPT-5.6/Claudeを使用、という使い分けが一般的です。PromptQuorumのような複数モデル同時実行ツールを活用すれば、同じプロンプトで複数モデルを比較でき、最適なものを本番採用できます。
日本の開発チームがプロンプトエンジニアリングで避けるべき落とし穴は？
最も危険な落とし穴は3つです：(1) ハルシネーション過信―日本語でも、モデルが誤った情報を自信満々に出力するため、金融・医療・法務分野では必ず出力検証を組込む、(2) 日本語固有の曖昧性―敬語・方言・文字種（漢字・ひらがな・カタカナ）の混在で、意図しない解釈が生じやすいため、Few-Shotサンプルで明確化、(3) コンプライアンス見落とし―個人情報・営業秘密がプロンプトやコンテキストに混入しないよう、厳格なデータガバナンスが必須です。これら対策を組み込むことで、堅牢で信頼できるシステムが実現できます。
プロンプトエンジニアリングとプロンプト最適化、プロンプトチューニングの違いは？
これらは段階的に異なります：(1) プロンプトエンジニアリング―最も基礎。手作業でプロンプト構造（役割、タスク、例、制約）を設計・改善。(2) プロンプト最適化（Prompt Optimization）―プロンプト変種を複数試し、評価指標をもとに最適版を自動選択。ツール支援あり。(3) プロンプトチューニング（Prompt Tuning）―連続的な「ソフト」プロンプト埋め込みを勾配降下で最適化。モデル内部で微調整。日本企業では段階的に導入：最初は手作業設計、スケール時に自動最適化を導入、高度な使用例では軽量なプロンプトチューニングを検討します。
日本語テキスト処理でのトークン数計算は、英語と大きく違いますか？
はい、大きく異なります。英語は「単語」が基本的なトークン単位で、1単語=1～2トークンですが、日本語は文字種や形態素単位で分割され、同じ意味の文でも英語より20～40%多くトークンが必要になります。例：「プロンプトエンジニアリングの基礎」は日本語で約10トークン、英語の"Fundamentals of Prompt Engineering"も約10トークンですが、翻訳すると効率が下がります。実務的には、日本語コンテンツを大量処理する場合、英語処理より高いトークン数を見積もり、コスト計画を立てることが重要です。PromptQuorumではモデルごとのトークン計算機が統合されており、日本語入力に対して正確なコスト見積もりが可能です。
オンプレミス（ローカル）運用と、クラウドAPI利用（GPT-5.6、Claude）の選択基準は？
データ保護レベルで判断します：(1) クラウド推奨―データ流出リスクが低い、リアルタイム高性能重視（顧客向けチャットボット、マーケティング）。コスト安定、最新モデルへのアクセス。(2) オンプレミス推奨―顧客個人情報、財務データ、営業秘密を含む、データローカライゼーション要件あり。クラウド送信できない。Ollama + Llama 4 Scout等で実運用可能。(3) ハイブリッド―非機密タスクはClaudeで高速処理、機密部分はローカルで自社制御。多くの日本企業がこのアプローチ。初期構築コスト vs. 長期運用コスト、スタッフスキル、規制要件を総合判断してください。
エンタープライズ環境で複数チームがプロンプトを共有・管理するベストプラクティスは？
4つの層を構築することをお勧めします：(1) Prompt Repository―Git或いは専用ツール（PromptHub、KeepMyPromptsなど）で全プロンプトをバージョン管理。誰が書いた、いつ改改訂、どの版が本番か記録。(2) テンプレート化―部門別テンプレート（営業向け、カスタマーサポート向けなど）を用意。新人でも高品質なプロンプトで開始。(3) 評価・テスト―新プロンプトはゴールデンセット（期待値データセット）で評価。回帰テストで既存品質を維持。(4) Governance―誰がプロンプトの本番導入を承認するか、責任者を明確化。特に金融・医療分野は法令対応も含めた統制が必須です。