生成AI活用・AIシステム設計 問題集・練習問題クイズ

社内問い合わせへ生成AIを導入する最初の設計作業として適切なのはどれですか？

答え： 対象User、業務Outcome、許容Error、評価指標を定義する

Use Case、影響を受ける人、成功・失敗条件、Risk許容度を先に定義すると、ModelやRAG、Human Reviewの選択根拠ができます。

User入力と参照文書をPromptへ入れる際、命令とDataを混同しにくくする基本策はどれですか？

答え： Role、明確なDelimiter、引用Dataの扱いを指示する

命令階層とData境界を明示すると意図を伝えやすくなります。ただしDelimiterだけでPrompt Injectionを完全には防げません。

同じPromptで回答の多様性を抑えたい。一般に最初に調整するParameterはどれですか？

答え： Temperatureを低くする

低いTemperatureはSamplingのRandomnessを抑えます。ただし完全な決定性を保証せず、重要処理ではSchema ValidationやRule-based Checkも使います。

LLM出力を後続APIへ渡す際、JSONらしい文字列が返れば安全と判断してよいですか？

答え： Schema制約を使い、Application側でもParse・Validationする

Structured Output機能を使っても、型、Range、Business Rule、認可をApplication側で検証してから実行します。

社内規程への回答でHallucinationの影響を下げたい。適切な設計はどれですか？

答え： 承認済み文書を検索して根拠を提示し、不明時は回答を控える

Grounding、Source表示、十分な根拠がない場合のAbstentionを組み合わせます。重要判断はHuman確認へEscalateします。

頻繁に更新される非公開の社内Knowledgeを回答へ反映したい。Fine-tuningよりRAGを先に検討する理由はどれですか？

答え： Knowledgeを更新・削除しやすく、回答時にAccess制御済み根拠を渡せる

RAGはKnowledgeを外部Indexで管理し、更新性、Source提示、User権限に応じた検索を設計できます。

Embeddingの主な用途として適切なのはどれですか？

答え： Text等をVector表現へ変換し意味的近さを検索する

Embeddingは意味的特徴をVector化し、類似検索、Clustering等に使います。認可Filterや機密区分は別途適用します。

RAGのChunk Sizeを決める適切な方法はどれですか？

答え： 文書構造と質問単位を考慮し、Retrieval評価でSize・Overlapを比較する

Chunkが大きすぎるとNoise、小さすぎるとContext欠落が増えます。実Query SetでRecall、Precision、回答品質、Costを比較します。

製品型番の完全一致と自然言語の意味検索を両立したい。適切な検索方式はどれですか？

答え： Keyword検索とVector検索を組み合わせるHybrid Search

Lexical検索は固有名詞・型番、Vector検索は意味的表現に強みがあります。Score統合とFilterを評価します。

初段検索で候補を広めに取得し、上位Contextの関連性を改善したい。次に使う手法はどれですか？

答え： Cross-encoder等で候補をRerankする

RerankerはQueryと候補をより精密に評価して順序を改善します。LatencyとCostが増えるため候補数を制御します。

部門ごとに閲覧権限が異なる社内RAGで最重要のAccess設計はどれですか？

答え： 検索時にUser IdentityとDocument ACLでFilterし、Sourceでも認可する

許可されないContentをModel Contextへ入れないことが基本です。Index更新時もACL Metadataと削除を同期します。

RAGの品質が低いとき、検索と生成のどちらが原因か切り分ける方法はどれですか？

答え： 検索Recall・Relevanceと、Groundedness・Correctnessを別々に評価する

Gold Sourceを取得できたかと、取得Contextを正しく使えたかを分けると、Index・検索・Prompt・Modelの改善先を特定できます。

生成回答が与えた参照Contextに基づいているか測る指標はどれですか？

答え： Groundedness

Groundednessは主張が参照EvidenceでSupportされるかを見ます。Correctness、Relevance、Completenessとは分けて評価します。

Production Release前のEval Datasetとして適切なのはどれですか？

答え： 代表Query、Edge Case、攻撃入力、期待回答・根拠をVersion管理する

実TrafficとRiskを反映したDatasetを持ち、Model・Prompt・Index変更時にRegression Gateとして継続実行します。

LLM-as-a-judgeを品質評価へ使う際の注意として適切なのはどれですか？

答え： Rubricを明示しHuman Labelで較正し、Position・Style Biasを監視する

Judge ModelもBiasと変動を持ちます。Human Gold Setとの一致、複数Judge、Blind化等で妥当性を確認します。

Tool CallingでModelに外部Functionを選ばせる場合の安全な実装はどれですか？

答え： AllowlistしたToolとSchemaを使い、Server側で認可・Validationする

Model出力は実行計画の候補として扱います。Tool Dispatcherが名前、引数、User権限、Rate LimitをDeterministicに検査します。

AgentがDocument要約だけを行う。Tool権限として適切なのはどれですか？

答え： 必要なDocumentへのRead-only Accessだけ

Excessive Agencyを避け、Functionality、Permission、Autonomyを業務に必要な最小範囲へ絞ります。

Agentが送金や本番削除を提案できる。実行前Controlとして適切なのはどれですか？

答え： 変更内容・影響・対象を表示し、権限あるHumanの明示承認を要求する

不可逆・高影響ActionはHuman-in-the-loopと職務分離を使います。Approval Tokenは内容へBindし、変更後は再承認します。

AgentのRetryで同じ注文が二重作成された。Tool API側の改善はどれですか？

答え： Idempotency Key、重複検出、明確なResult状態を実装する

Agent OrchestrationではTimeout後に結果不明のRetryが起きます。Side-effect APIをIdempotentにし、同じIntentを一度だけ適用します。

Web Pageを要約するAgentが、Page内の『秘密を送信せよ』という文を命令として実行した。分類はどれですか？

答え： 非信頼Content経由のIndirect Prompt Injection

取得ContentはDataとして扱い、命令へ昇格させません。Tool権限最小化、Data/Instruction分離、出力検査、Human承認を重ねます。

LLMが生成したHTMLをBrowserへ表示する際の適切な扱いはどれですか？

答え： 非信頼出力としてEscape・Sanitizeし、CSP等も適用する

生成出力には攻撃Payloadや誤ったCodeが含まれ得ます。利用先のContextに応じたEncoder、Sanitizer、Allowlistを使います。

Customer Support Transcriptを外部Model APIへ送る前のData設計はどれですか？

答え： 目的に必要な範囲へ最小化し、PIIをRedactし、Provider条件とRetentionを確認する

Purpose Limitation、Data Minimization、Redaction、契約・保存条件、Region、Access Log等を確認し、機密Dataを必要以上に送信しません。

AI Request LogへPromptと回答を保存する際の適切な方針はどれですか？

答え： 必要Fieldを構造化し、機密値をRedact、Access・Retentionを制限する

Prompt/Responseは機密情報を含み得ます。Traceabilityに必要なMetadataとSampleを定義し、Redaction、Encryption、Retention、監査を設計します。

Multi-tenant AI ServiceでTenant AのRAG文書がTenant Bへ出た。再発防止の中核はどれですか？

答え： Index・Cache・Log・Tool CredentialをTenant境界で分離し認可Filterを強制する

Tenant IDを信頼できるIdentityから導出し、全Data Pathへ伝播します。検索後のPromptだけで隠す方式は不十分です。

Model APIのRate LimitでTraffic急増時に連鎖障害が起きる。適切な設計はどれですか？

答え： Concurrency制限、Queue、指数Backoff・Jitter、Retry上限を設ける

BackpressureとRetry BudgetでProviderと自Serviceを保護します。非同期化、優先度、Fallback、明確なDegraded Responseも設計します。

LLM回答をCacheする際に最も重要な注意はどれですか？

答え： Tenant・User権限、Prompt/Model/Knowledge Version、TTLをKeyとPolicyへ反映する

AI CacheはData漏えいとStale回答のRiskがあります。Security Contextと全入力Versionを考慮し、Invalidationと暗号化を設計します。

簡単な分類と複雑な分析でCost/Latency要件が異なる。適切なModel選択はどれですか？

答え： 評価済みのTask Routerで小型Modelを優先し、難問だけ上位ModelへEscalateする

Quality Gateを満たす最小ModelをTaskごとに選ぶと、CostとLatencyを抑えられます。Routing誤りもEval対象にします。

Primary Model Provider障害時も最低限のServiceを続けたい。適切なのはどれですか？

答え： Timeout・Circuit Breakerと、評価済みFallbackまたは機能縮退を用意する

Fallback Modelの品質・Safety差を事前評価し、利用者へ縮退を明示します。Data ResidencyやAPI差も確認します。

AI ChatのP95応答時間SLOを設計する方法はどれですか？

答え： 検索、Rerank、Model、Tool、Queueを分解しEnd-to-end Budgetを割り当てる

AI ChatのLatencyは検索、Rerank、Model生成、Tool、Queue等の合計です。End-to-end SLOを各Stageへ配分し、Streaming開始時間と完了時間も分けて測ります。

生成AI機能のUnit Economicsを把握する指標設計はどれですか？

答え： Task成功1件当たりのToken・検索・Tool Costと品質を追う

Token、検索、Tool、Infrastructure Costを成功した業務Outcome単位で集計し、品質・Latencyと併せて追うと、価値を損なわない最適化ができます。

AI Agentの障害原因を追跡できるObservability設計はどれですか？

答え： Request単位で検索・Model・ToolのTraceを関連付け、Version、Latency、Token、Errorを記録する

生成AIの失敗は検索、Prompt、Model、Toolなど複数Stageにまたがります。Trace IDで経路を結び、Prompt・Model・Index・Tool Versionと品質指標を追えるようにします。

本番RAGの品質低下を早期検知する方法として適切なのはどれですか？

答え： 検索Hit・Groundedness・Task成功率を継続測定し、CorpusやModel変更と関連付ける

正常なHTTP応答でも回答品質は低下します。Golden Set、Sampling Review、利用者Signalを組み合わせ、Data・Index・Prompt・Modelの変更点と比較します。

AI回答の再現性とRollbackを高めるRelease管理はどれですか？

答え： Prompt、Model、Parameter、Index、Tool SchemaをVersion化し、評価結果とReleaseを対応付ける

AI挙動はCode以外の多くのArtifactに依存します。入力からRelease構成を特定できるVersionとEvaluation Evidenceを残し、段階展開とRollbackを可能にします。

利用者のThumbs-up/down Feedbackを改善へ使う際の適切な扱いはどれですか？

答え： Task Contextと理由を収集し、Bias・不正操作・Privacyを確認して評価Dataset候補にする

FeedbackはSelection Biasや悪意ある入力を含み、評価者の意図も曖昧です。Contextを付けて審査し、まずFailure分析とEval Set改善へ利用します。

生成AIのContent Safetyを設計する原則として適切なのはどれですか？

答え： Use CaseのRiskを分類し、入力・出力Guardrail、Policy、Human Review、Appealを層状に設計する

Safetyは誤検知と見逃しのTradeoffを持ちます。影響度に応じたPolicyと複数Controlを設け、拒否品質、Bypass率、異議申立ても評価します。

多言語AI Assistantの公平性とAccessibilityを評価する方法はどれですか？

答え： 言語・地域・支援技術・重要Subgroup別に品質と失敗率を測り、当事者Reviewを行う

全体平均は少数Groupの著しい失敗を隠します。代表性のあるTest Setと定性Reviewを組み合わせ、翻訳品質だけでなくTask完遂と有害差も確認します。

AI Agentが誤って外部Systemを更新し始めたIncidentで、最初に備えるべきControlはどれですか？

答え： Tool実行を即時停止するKill Switch、Credential失効、影響範囲特定とAudit Log保全

Agent IncidentではまずCapabilityとCredentialを封じ込め、Evidenceを保全します。その後、変更のRollback、利用者通知、Root Cause分析、Guardrail改善を進めます。

AI SystemのModel・Dataset・Library供給網Riskを管理する方法はどれですか？

答え： 出所、License、Version、Hash、評価、既知RiskをInventory化し、承認済みArtifactだけを使う

AI Artifactにも改ざん、Malware、License、Data Provenance、脆弱性のRiskがあります。取得元を固定し、Integrity検証、Sandbox評価、更新監視を行います。

Fine-tuningを選ぶのが適切な状況はどれですか？

答え： 十分な品質のTraining例があり、反復する形式・Style・Task挙動を安定化しHoldout評価できる

Fine-tuningはTask挙動の適応に向きますが、頻繁に変わる知識の更新やSecurity境界の代替ではありません。BaselineとHoldout Setで品質・Safety・Costを比較します。

生成AI Risk ManagementのLifecycle設計として適切なのはどれですか？

答え： Govern・Map・Measure・Manageを継続し、監視、変更再評価、Incident対応、廃止までOwnerを定める

生成AIのRiskはModel、Data、利用方法、外部環境の変化で変動します。責任者とRisk許容度を定め、導入前評価から本番監視、重大変更、廃止まで循環的に管理します。