| AI適用判断 |
課題にAIが必要か、必要であればどのような形態が最もシンプルか、今開発する条件が整っているかを判断すること。 |
| 解決策のはしご |
最下段のルール・照会から、検索、分類・予測モデル、生成モデルの呼び出し、ワークフロー、最上段のエージェントに至るまで、軽量な解決策から重量な解決策の順に並べた枠組み。下の段で目的を達成できる場合は、上の段は選びません。 |
| ルール・照会 |
入力とルールが決まっており結果が1つに定まる処理を、条件分岐やデータベース照会で処理する方式。 |
| 検索拡張生成 |
検索によって根拠となる文書を探し、その根拠に紐づけて回答を生成する構成。モデルが把握していない社内文書や最新情報を根拠に回答を記述する必要がある場合に使用し、原文の確認だけであれば検索で十分です。 |
| ワークフロー |
LLMとツールをあらかじめ定めたコードパスで連携させたシステム(Anthropicの定義)。 |
| エージェント |
LLMが自ら手順とツールの使用を決定するシステム。ステップ数を予測できないオープンな問題に使用します。 |
| ルーティング |
入力を分類し、専門化された後続処理へ振り分けるワークフローの形態。 |
| 評価者-最適化者 |
一方の呼び出しが結果を生成し、もう一方の呼び出しが評価とフィードバックを提供する反復構造。評価基準が明確な場合に使用します。 |
| 自動化と補助 |
人間の仕事を代替すること(自動化)と、人間の仕事を支援すること(補助)。リスクが大きい場合は、人間が統制権を握る補助が一般的です。 |
| 高影響人工知能 |
AI基本法第2条第4号が定める領域(採用・融資審査などの判断・評価、公共サービスの受給資格の決定、学生評価など)で活用され、生命・安全・基本権に重大な影響を及ぼし得る人工知能システム。 |
| 生成型人工知能 |
入力データの構造や特性を模倣して文章、音声、画像、映像などを生成する人工知能システム(AI基本法第2条第5号)。 |
| 人工知能事業者 |
人工知能を開発して提供する者(開発事業者)と、それを利用して製品・サービスを提供する者(利用事業者)。国家機関等も含まれます。 |
| 事前告知 |
高影響・生成型人工知能を利用した製品・サービスが、その人工知能に基づいて運用されているという事実を利用者に事前に知らせる義務(AI基本法第31条第1項)。 |
| 生成物の表示 |
生成型人工知能の生成物が生成型人工知能によって生成されたという事実を表示する義務(第31条第2項)。 |
| 高影響の確認 |
事業者が高影響への該当有無を事前に検討し、必要に応じて科学技術情報通信部長官に確認を要請できるようにした手続き(第33条)。 |
| 自動化された決定 |
完全に自動化されたシステム(AIを含む)によって個人情報を処理して行われる決定(個人情報保護法(韓国)第37条の2)。行政基本法(韓国)第20条に基づく行政庁の自動的処分は除外されます。権利・義務に重大な影響を及ぼす場合、拒否権が生じます。 |
| 成功基準 |
機能が成功したかを判定する基準。指標、データ、基準値、基準線(ベースライン)、測定方法を備えている必要があります。 |
| リリース阻止基準 |
達成できなければ他の指標が良好であってもリリースしない基準。法律・契約の違反やユーザーへの被害につながる項目に設けます。 |
| 改善目標 |
リリース後に追跡しながら引き上げる水準。利用に支障のない品質項目に設けます。 |
| 基準線(ベースライン) |
比較の出発点となる現在の水準。人間や既存システムの性能。 |
| 適合率(プレシジョン) |
陽性と判定したもののうち、実際の陽性が占める割合。誤って検出した場合の被害が大きい機能で重視します。 |
| 再現率(リコール) |
実際の陽性のうち、陽性として検出できた割合。見逃した場合の被害が大きい機能で重視します。 |
| 偽陽性・偽陰性 |
該当しないものを該当すると判定したエラーと、該当するものの検出を見逃したエラー。双方のコストを考慮して維持すべき指標を定めます。 |
| F1スコア |
適合率と再現率を1つにまとめた調和平均の指標。 |
| 入力契約(入力コントラクト) |
機能が受け付ける入力の範囲(言語、形式、長さ、必須情報)と、範囲外の入力に対する処理ルール。 |
| 出力契約(出力コントラクト) |
機能が返す結果の形式、空の値の処理、検証失敗時の処理ルール。 |
| 構造化出力 |
応答が指定したJSONスキーマに従うよう制約する機能。拒否やmax_tokensへの到達時にはスキーマから外れる場合があります。 |
| スキーマ |
結果のフィールド名、形式、必須か否かを定めた仕様。 |
| TTFT |
リクエストを送信してから最初のトークンが出力されるまでの時間。ユーザーが画面の前で待機する機能の体感遅延を左右します。 |
| ストリーミング |
全体の出力が完了する前に応答の送信を開始する方式。全体の所要時間は同じであっても体感的な応答性を高めます。 |
| バッチ処理(一括処理) |
即時応答を必要としない大量のリクエストを集めて非同期で処理し、コストとスループットを改善する方式。例えばAnthropicのMessage Batches APIはコストを50%削減し、大半は1時間以内に完了し、24時間以内に完了しない場合は失効します(2026-10-22確認)。 |
| max_tokens |
出力トークン数の上限。上限に達すると文章や構造化データの途中で生成が停止するため、長さの調整用ではなくコスト・遅延の上限として設定し、中断理由を確認します。 |
| 評価 |
モデルや機能の性能を測定する構造化されたテスト。評価セット、採点方式、成功基準で構成されます。 |
| 評価セット |
評価に使用する入力と期待される結果の組み合わせ。実際の利用分布を代表している必要があります。 |
| エッジケース(境界事例) |
無関係な入力、極端に長い入力、有害な入力、人間でも判定が分かれる曖昧な事例など、失敗しやすいケース。 |
| ホールドアウトセット(保留セット) |
修正時には確認せず、最終判定にのみ使用する評価セットの一部。過学習を防ぎます。 |
| 過学習(過適合) |
同一の評価セットに合わせて修正した結果、スコアが実際の性能よりも高くなってしまう現象。 |
| コードによる採点 |
完全一致、文字列の包含、フォーマット検証のようにコードで判定する採点。最も高速で信頼性が高い方法です。 |
| LLM採点 |
ルーブリックを与えられたLLMが結果を判定する採点。複雑な判断に適していますが、人間による評価と照合して信頼性をあらかじめ確認しておく必要があります。 |
| 人間による採点 |
人間が判定する採点。品質の基準となりますが、時間がかかりコストも高いため、基準データや補正に使用します。 |
| ルーブリック |
評価項目別の判定基準と評価尺度を具体的に記述し、採点の一貫性を高める採点基準表。 |
| 位置バイアス |
LLM採点器が回答の提示順序によって判定を変えてしまう傾向。順序を入れ替えながらの一対比較によって軽減します。 |
| ブラインド比較 |
評価者がどちらのバージョンであるかを知らない状態で、2つの結果を並べて比較する評価。 |
| 能力評価 |
まだうまくこなせない課題で構成し、低い合格率からスタートする評価。 |
| 回帰評価(リグレッション評価) |
すでにうまくこなせていた処理を引き続き正しく実行できているか確認する評価。合格率がほぼ100%である必要があります。 |
| 評価の飽和 |
評価課題をすべてパスし、これ以上の改善の余地を示せなくなっている状態。 |
| pass@k |
k回の試行のうち、少なくとも1回は成功する確率。 |
| pass^k |
k回の試行がすべて成功する確率。毎回同じ品質が求められる機能に適しています。 |
| オフライン評価 |
用意した評価セットを使用し、ユーザーには公開(配信)せずに結果を測定する評価。 |
| オンライン指標 |
実際の運用環境で測定する指標(再生成、相談への転換、離脱、通報、購買転換)。 |
| A/Bテスト(A/B実験) |
ユーザーを無作為に分けて2つの案の指標を比較する実験。リスクが低く、十分なトラフィックがある場合に使用します。 |
| 捏造された回答 |
根拠のない内容を事実のように作り出す失敗(ハルシネーション)。減らすことはできますが、完全になくすことはできません。 |
| 過剰拒否 |
回答できる質問まで拒否してしまう失敗。誤答率には反映されないため、回答可能な質問に対する拒否率を個別に測定します。 |
| 形式エラー |
取り決めた出力形式を守らないことで、画面表示や連携が損なわれる失敗。 |
| 指数バックオフ |
再試行するたびに待機の間隔を延ばしていくリトライ方式。 |
| 段階的縮退(グレースフルデグラデーション) |
AI機能が停止しても、中核業務がよりシンプルな経路で継続できるようにする設計。 |
| 事前承認 |
すべての結果を人間が確認したうえで外部に出す介入方式。 |
| 条件付き移管 |
確信度が低い案件やリスク条件に該当した案件のみを人間に引き継ぐ介入方式。 |
| 事後標本点検 |
自動反映された後、その一部を定期的に抽出して点検する介入方式。 |
| 異議申し立て処理 |
結果の通知を受けた人が要求した場合、人間が再度処理を行う介入方式。 |
| 形式的承認 |
レビュー担当者が根拠や権限のないまま、ほぼすべての結果をそのまま承認してしまい、監督が機能していない状態。 |
| 自動化バイアス |
人間がAIの推薦をよく検討せずに受け入れてしまう傾向。形式的承認の原因となります。 |
| 厳格なツール入力 |
ツール名と入力値が定義されたスキーマに従うようにする設定(strict tool use)。 |
| 信頼の調整 |
ユーザーがAIを特定の状況では信頼し、必要なときには再確認できるよう、信頼水準を適切に合わせること。 |
| 暗黙的・明示的フィードバック |
ログに残るユーザーの行動(暗黙的)と、ユーザーが意図的に残す意見(明示的)。 |
| バックグラウンドエラー |
システムが誤動作しているにもかかわらず、ユーザーもシステムもエラーとして認識できない失敗(Google PAIRのbackground errors)。サイレント失敗とも呼ばれます。 |
| シャドウテスト |
実際のリクエストの複製を新バージョンに送信しつつ、ユーザーには既存バージョンの結果のみを返すテスト。 |
| カナリア |
変更を少数の実トラフィックに対して時間制限を設けて先行配信し、対照群と比較評価したうえで、問題がなければ公開範囲を段階的に拡大していく方法。 |
| 対照群 |
同一期間に既存バージョンを使用する比較グループ。 |
| 中断基準 |
リリース前に定めた、閾値を超えた場合に配信拡大を停止してロールバックするための指標と基準値。判定に必要な最小サンプル数も併せて定めます。 |
| 機能フラグ |
コードのデプロイなしに機能をオン/オフしたり、公開範囲を変更したりする仕組み。 |
| ガードレール指標 |
実験やリリースにおいて、目標指標が向上したとしても、許容限度を超えて悪化してはならない指標(通報率、返金率など)。 |
| モデルのライフサイクル |
モデルのサポート・サポート終了(提供終了)のステータスとその推移。例えばAnthropicはActive、Legacy、Deprecated、Retiredに分類しており、提供終了(Retired)となったモデルに送信されたリクエストは失敗します。ステータスやスケジュールはベンダーや提供プラットフォームごとに確認します。 |
| 振り返り |
事故の経緯、影響、措置、原因、再発防止策をまとめた記録とその議論。 |
| 非難なき振り返り |
個人やチームを責めず、寄与要因(直接・間接の原因)の究明に集中する振り返り。 |