【実務向け】単なる解説で終わらない、開発者・アーキテクトのための生成AI用語集

最近、「プロンプトエンジニアリング」や「ハルシネーション」といった生成AIの基本的な用語集はよく見かけるようになりました。しかし、実際にプロダクトにAIを組み込み、クラウドインフラと連携させ、モバイルアプリとしてリリースする「開発者・アーキテクト」の視点に立つと、少し違ったキーワードが重要になってきます。

本記事では、システム設計・開発プロセスから、クラウド・アプリ実装、そして最前線のAIエージェント技術まで、プロダクトにAIを組み込んでいる中級〜上級エンジニアが知っておくべき技術用語をコードと図を交えてまとめました。

1. システム設計・開発プロセス編

AI Ready（AIレディ）

組織、システム、またはプロダクトがAIをシームレスに導入・活用できるアーキテクチャになっている状態を指します。
単純に外部のLLM APIを叩けるだけでなく、クラウド上のデータベース設計（ベクトル検索への対応など）やデータパイプラインがAIとの連携を前提とした構造になっているかが問われます。セキュアなデータマスキングや柔軟なAPI連携基盤が整っているシステムを「AI Readyなアーキテクチャ」と呼びます。

実務チェックポイント:

ベクトルDBや埋め込みモデルを差し替えられる抽象化レイヤーがあるか
個人情報・機密データのマスキングがLLMへの送信前に行われているか
LLMの呼び出しログ・レイテンシ・コストを計測できる基盤があるか

AI DLC (AI Development Life Cycle)

AIモデルや生成AIを組み込んだシステムの開発から運用までの一連のライフサイクルです。
従来のソフトウェア開発（SDLC）とは異なり、「要件定義」「データ準備」「プロンプト設計」「評価」「デプロイ」「運用監視（LLMOps）」という独自のサイクルを持ちます。AIの出力には不確実性が伴うため、スクラムなどのアジャイル開発と組み合わせ、短いスプリントでプロンプトの微調整と評価（イテレーション）を繰り返すプロセス設計が不可欠です。

2. テスト・評価・運用編

ループ (Loop / Human-in-the-Loop)

AIの処理プロセスの中に、人間の介入や、AI自身による反復的なフィードバックを組み込む設計思想です。
最終的な意思決定や重要データの更新前に人間の承認を挟む「Human-in-the-Loop (HITL)」は、実運用における安全担保として重要です。また、自律型AIエージェントが「思考 → 行動 → 観察」を繰り返す実行ループ（ReActなど）を指すこともあります。

ガードレール（Guardrails）

LLMの入出力に対して、安全性・品質・コンプライアンスの制約を自動的に適用する仕組みです。
ユーザーの入力（インプット）に対してはプロンプトインジェクションや機密情報の混入を検知・ブロックし、LLMの出力（アウトプット）に対しては不適切なコンテンツ・個人情報・ハルシネーションリスクのある応答をフィルタリングします。NVIDIA NeMo Guardrails、Guardrails AI、AWS Bedrock Guardrails などのフレームワークが実装を支援します。

3. アプリケーション・インフラ実装編

Embedding（埋め込み）

テキスト・画像・音声などのデータを、意味的な関係を保持した高次元の数値ベクトルに変換する技術です。
「犬」と「猫」は意味が近いため、ベクトル空間上でも近い位置に配置されます。このベクトル表現が、後述するRAGやセマンティック検索の基礎を支えています。

from openai import OpenAI

client = OpenAI()

def get_embedding(text: str) -> list[float]:
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=text,
    )
    return response.data[0].embedding  # 1536次元のベクトル

# 意味的に近いテキストはベクトル空間でも近くなる
embedding_a = get_embedding("今日の売上を教えて")
embedding_b = get_embedding("本日の売上データを確認したい")
# → コサイン類似度が高くなる（≒意味が近い）

ベクトルDB（Vector Database）

Embeddingで生成した高次元ベクトルを効率的に保存・検索するために特化したデータベースです。
SQLの LIKE 検索とは異なり、「意味的に近い」ドキュメントをミリ秒単位で検索できます（ANN: Approximate Nearest Neighbor）。

サービス	特徴
Pinecone	フルマネージド、大規模スケール向き
pgvector	既存のPostgreSQLに拡張として追加可能
Firestore Vector Search	GCPネイティブ、モバイルアプリと親和性高
Weaviate	OSSで自己ホスト可能、GraphQL対応

RAG (Retrieval-Augmented Generation：検索拡張生成)

LLMに自社の独自データや最新情報に基づいた回答をさせるためのアーキテクチャです。
事前にドキュメントを「チャンク（意味のある塊）」に分割してベクトル化・保存しておき、質問時に関連チャンクを検索してプロンプトに含めることで、ハルシネーションを抑えつつ精度の高い回答を生成します。

Function Calling（関数呼び出し）

LLMが自然言語の入力を解析し、システム側で事前に定義した関数を適切な引数とともに呼び出すよう指示を返す機能です。
LLMは直接答えるのではなく「どの関数をどの引数で呼ぶか」をJSONで返し、実際の処理はシステム側が担います。これにより、LLMと既存システムを決定論的かつ安全に連携できます。

import OpenAI from "openai";

const client = new OpenAI();

const tools: OpenAI.Chat.Completions.ChatCompletionTool[] = [
    {
        type: "function",
        function: {
            name: "get_sales_data",
            description: "指定した日付の売上データを取得する",
            parameters: {
                type: "object",
                properties: {
                    date: {
                        type: "string",
                        description: "対象日 (YYYY-MM-DD形式)",
                    },
                },
                required: ["date"],
            },
        },
    },
];

const response = await client.chat.completions.create({
    model: "gpt-4o",
    messages: [{ role: "user", content: "今日の売上データを教えて" }],
    tools,
    tool_choice: "auto",
});

// LLMは直接答えず、呼び出すべき関数と引数を返す
// → { name: "get_sales_data", arguments: '{"date":"2026-07-23"}' }

ファインチューニング（Fine-tuning）

事前学習済みのLLMを、特定タスクやドメインのデータで追加学習させ、そのユースケースに特化したモデルを作成する手法です。
RAGがプロンプトに情報を「注入」するのに対し、ファインチューニングはモデル自体の重みを更新します。専門用語への対応や、特定のトーン・出力フォーマットの統一に有効ですが、学習データ準備のコストと、モデルバージョンアップへの追従が課題になります。

比較軸	RAG	ファインチューニング
最新情報への対応	◎（DBを更新するだけ）	△（再学習が必要）
専門知識の深い習得	△	◎
初期コスト	低〜中	中〜高
主なユースケース	社内FAQ・ドキュメント検索	特定フォーマット出力・口調の統一

On-Device AI / Edge AI（オンデバイスAI）

クラウドを経由せず、スマートフォンやエッジデバイスのローカル環境で直接AIモデルを動かす技術です。
iOSでは Core ML、Androidでは ML Kit や MediaPipe などのフレームワークを活用します。APIの通信遅延（レイテンシ）をなくし、オフラインでも動作するほか、ユーザーのプライバシーデータを外部に送信せずに済む強力なメリットがあります。Apple Intelligence に代表されるように、今後さらに重要性が増す領域です。

4. AIエージェント・オーケストレーション編

AIエージェント（AI Agent）

LLMを「推論エンジン」として使い、自律的にツールを選択・実行しながら複数ステップのタスクを達成するシステムです。
単発のQ&Aを超え、「GitHubのIssueを読んでPRを作成し、CIが通ったらSlackに通知する」といった複合タスクを自律実行できます。ReAct（Reasoning + Acting）パターンが広く採用されており、LangGraph、AutoGen、Google ADK などのフレームワークが実装を支援します。

MCP（Model Context Protocol）

Anthropicによって2024年末にオープンソース公開された、AIエージェントとツール群の標準通信プロトコルです。
LLMホスト（Claude、GPTなど）と、データソース・外部ツール（DB、ファイルシステム、外部APIなど）の間のやり取りを標準化した仕様で、「AIのためのUSB-C規格」 とも呼ばれます。MCPサーバーを一度実装すれば、対応するあらゆるAIモデルやクライアントから安全に利用できます。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({
    name: "sales-db-server",
    version: "1.0.0",
});

server.registerTool(
    "get_sales",
    {
        description: "指定日の売上データを取得する",
        inputSchema: { date: z.string().describe("対象日 YYYY-MM-DD") },
    },
    async ({ date }) => {
        const data = await db.getSales(date);
        return { content: [{ type: "text", text: JSON.stringify(data) }] };
    },
);

await server.listen();

マルチエージェント / オーケストレーション

複数の専門化したAIエージェントを連携・協調させ、単一エージェントでは処理しきれない複雑なタスクを分業する設計パターンです。
「リサーチエージェント」が情報収集し、「コーディングエージェント」が実装し、「レビューエージェント」が品質確認するといった役割分担が可能です。オーケストレーターエージェントが各エージェントへのタスク割り当てと結果統合を担う Supervisor/Worker 構成が一般的で、LangGraph や AutoGen がこのパターンの実装をサポートしています。

おわりに

生成AIを「チャットツール」として使うフェーズから、「システムの中核コンポーネント」として組み込むフェーズへと移行しつつあります。
特に MCP や マルチエージェント は2024〜2025年にかけて急速に実用化が進んでいる領域であり、アーキテクチャ設計の選択肢として積極的に検討する価値があります。

これらの用語を共通言語としてチーム内で持つことで、より実践的でスケーラブルなAI搭載プロダクトの開発が進むはずです。少しでも開発現場の参考になれば幸いです！