AIエンジニアに必要な知識

A. クラウド基盤（Azure）／ネットワーク・ID・ガバナンス

A1. VNet／サブネット／NSG／NAT

• ねらい: アプリとPaaSを閉域でつなぎ、外部露出を最小化。

• できること: East‑Westの無駄な経路を遮断し、固定Egressで外部SaaSの許可リストに対応。

• キーワード: VNet, Subnet(subnet-app/subnet-pe), NSG, NAT Gateway

• 落とし穴: Service Endpoint頼みでPublicを開けっぱなし。

• 練習: 1つのVNetにappとpeサブネットを作り、NSGで最小許可を設定。

A2. Private Endpoint／Private DNS

• ねらい: OpenAI / AI Search / Blob / Key Vault をプライベートIPで利用。

• できること: Publicアクセス無効でデータ流出の攻撃面を縮小。

• キーワード: Private Endpoint, Private DNS Zone

• 落とし穴: Private DNSのレコード未連携で接続失敗（Publicへフォールバックしがち）。

• 練習: 主要PaaS4つ（OpenAI/Search/Blob/KV）にPEを張ってPublicをDisable。

A3. Entra ID／RBAC／Managed Identity（MI）／PIM

• ねらい: 最小権限と秘密レスで運用。

• できること: アプリがKey Vault・Search等へ鍵なしでアクセス、特権はPIMで一時昇格。

• キーワード: Entra ID, RBAC, System‑Assigned MI, PIM, Conditional Access

• 落とし穴: Contributor/Ownerのばら撒き。

• 練習: アプリにMIを付与→Key VaultへSecrets User、SearchへSearch Index Data Readerを付与。

A4. Key Vault（秘密管理）

• ねらい: 秘密の単一路。

• できること: 削除保護／パージ保護／アクセス監査で“誰が何を読んだか”を追跡。

• キーワード: RBACモード, purge protection, soft delete

• 落とし穴: 環境変数にキー直書き。

• 練習: すべての接続情報をKV参照に移行し、アプリ構成から削除。

A5. API Management／WAF（境界）

• ねらい: JWT検証・レート制限・IP制御の“外堀”。

• できること: 認証を統一、DDoS/悪用から推論を防衛。

• キーワード: APIM policies (validate-jwt, rate-limit), Application Gateway WAF/Front Door

• 落とし穴: CORS全開・無制限。

• 練習: APIMでJWT検証→1分X回のレート制限を実装。

A6. 監視／ガバナンス

• ねらい: 追跡可能性と逸脱検知。

• できること: 相関IDでリクエストを端から端まで追跡、Policy/Defenderで逸脱を即検出。

• キーワード: App Insights, Log Analytics, Azure Policy, Defender for Cloud

• 落とし穴: ログ項目の粒度不足（出典やトークン数が無い）。

• 練習: 共通スキーマ（後述J1）をログに実装。

B. データ取り込み／RAG（Retrieval-Augmented Generation）

B1. 文書正規化・チャンク設計

• ねらい: 当てる検索の土台。

• できること: 日本語文書を300–700 tokensに分割、見出し＋本文を1単位に。

• キーワード: PDFテキスト化/OCR, 段落・見出し, スライディングウィンドウ

• 落とし穴: 長大チャンクでノイズ増、短すぎて文脈喪失。

• 練習: 代表10文書でチャンク分布の可視化（平均/分散を確認）。

B2. メタデータ／権限制御（セキュリティトリミング）

• ねらい: 権限外の出力ゼロ。

• できること: acl（部署/ロール）・updated_at・classificationで検索段階の除外。

• キーワード: フィルタクエリ, security trimming

• 落とし穴: 生成側の後マスク依存（一次防衛は検索）。

• 練習: Entraのグループをaclに写像→検索APIに必須フィルタを追加。

B3. ハイブリッド検索と再ランク

• ねらい: Recall×Precisionの両立。

• できること: BM25＋ベクトルをRRFで統合→再ランクでTop‑kを3–5へ。

• キーワード: BM25, Embeddings, RRF, MMR, Cross‑encoder Rerank

• 落とし穴: Top‑k多過ぎでコスト爆発。

• 練習: k=8→再ランク3–5のA/Bで正答・P95・単価を比較。

B4. クエリ拡張・辞書

• ねらい: 日本語特有の語彙揺れ対策。

• できること: 同義語・略語展開、見出し語補強でRecallを上げる。

• キーワード: 同義語辞書, HYDE, クエリ拡張

• 落とし穴: 語彙を足し過ぎてノイズ増。

• 練習: FAQ 50問の未命中ケースを語彙に落とす→辞書更新。

B5. プロンプト（RAG前提）

• ねらい: 根拠強制・推測禁止。

• できること: 「出典を必ず列挙、無ければ“不明”」の規則で安全性を担保。

• キーワード: system指示, citation必須, refusal方針

• 落とし穴: コンテキスト丸投げ。

• 練習: 上位3–5チャンクを要旨化して注入→出典の重複統合。

C. LLM基礎／生成制御

C1. トークン／サンプリング

• ねらい: 再現性とコストの制御。

• できること: temperature/top_p/max_tokensで長さと多様性を調整。

• キーワード: トークン化, context window, stop sequence

• 落とし穴: 温度上げ過ぎ→ハルシネ。

• 練習: 同一入力を温度0.2/0.7で比較し、差分とコストを記録。

C2. 関数呼び出し（Tool Use）

• ねらい: LLMは決定列を返し、実行はコード側。

• できること: スキーマ化された操作DSLや整形関数の呼び出し。

• キーワード: JSON Schema, strict mode, ツール白リスト

• 落とし穴: 返り値のスキーマ不一致→実行例外。

• 練習: “操作ステップ配列”のスキーマを作り、バリデーション未通過は破棄。

C3. 出力の構造化／検証

• ねらい: 安全でパース可能な出力。

• できること: JSON/Markdown表形式＋ルール検査（長さ・単位・PII）。

• キーワード: スキーマ検証, ルールベース検査

• 落とし穴: “ほぼJSON”。

• 練習: スキーマに合わなければ即再生成のパイプ。

D. プロダクト別の実務知識

D1. 社内RAGチャット

• ねらい: 根拠付きの正確な社内回答。

• できること: セキュリティトリミング、FAQ昇格、失敗上位の定例改善。

• キーワード: Teams/ポータル統合, feedback UI

• 落とし穴: 範囲外質問に答えようとする。

• 練習: “範囲外は礼節ある拒否”のテンプレをシステム指示に入れる。

D2. テストシナリオ／コード自動生成

• ねらい: 決定的・再現可能なE2Eを自動生成。

• できること: data-testid前提の操作DSL→テンプレ展開→CIで3連続実行。

• キーワード: Playwright/Cypress, 条件待機, flake率, 自己修復の監査

• 落とし穴: XPath依存／固定スリープ。

• 練習: Record‑firstで10ケース→テンプレでコード化→3連成功を基準に通過/差戻し。

D3. スライド自動生成（社内）

• ねらい: ブランド準拠かつ事実誤り0のデッキ。

• できること: スライド**型（文法）**とPOTXマッピング、情報不足スライド。

• キーワード: 箇条3–5点, 出典100%, 品質ゲート（禁止語/字数/PII）

• 落とし穴: 自動図表への過信（初期は図枠まで）。

• 練習: 週次報告12枚を60分で生成→レビュー30分で完了。

E. LLMOps（評価・監視・A/B・コスト）

E1. ログlineage・共通スキーマ（最重要）

• ねらい: 再現性の担保。

• できること: run_id/model/prompt/index/params/latency/tokens/cost/sources(user匿名)を全応答に紐づけ。

• キーワード: 相関ID, App Insights, Log Analytics

• 落とし穴: どの出典で答えたか残っていない。

• 練習: 1件の回答から全ログを辿れる可視化をダッシュボードに1クリックで用意。

E2. オフライン評価（ゴールデンセット）

• ねらい: 本番前に数値判定。

• できること: RAG=正答/根拠/ハルシネ、テスト=成功/flake、スライド=事実/準拠。

• キーワード: 50–100問/件, 自動採点

• 落とし穴: 感想ベースの改修。

• 練習: 代表50問にallowed sourcesを付けて自動採点。

E3. オンライン評価／A/B／Canary

• ねらい: 実運用で本当に勝っているかを見る。

• できること: 1–5%のCanary→勝ち定義（品質↑、P95悪化なし、単価±5%以内）。

• キーワード: A/B, Canary, ロールバック条件

• 落とし穴: 同時に複数変更。

• 練習: 変更は単一種類（モデルorプロンプトor検索orデータ）で実験。

E4. コスト最適化

• ねらい: 単価の管理。

• できること: 段階推論、小モデル前処理、要旨化、Top‑k最適化、セマンティックキャッシュ。

• キーワード: input/output tokens, キャッシュ, two‑stage

• 落とし穴: コンテキスト増やし過ぎ。

• 練習: “同一質問の再利用率”を計測→キャッシュ導入で単価の下げ幅を可視化。

F. セキュリティ／プライバシー（ゼロトラスト／STRIDE）

F1. ゼロトラストの写像

• ねらい: 侵害前提で被害最小化。

• できること: PE/MI/KV/APIM、MFA・条件付きアクセス、最小権限・環境分離。

• キーワード: Private Endpoint, Managed Identity, Key Vault, JWT

• 落とし穴: 公開エンドポイントの見落とし。

• 練習: 主要PaaSのPublic無効を監査クエリで定期チェック。

F2. STRIDEでの点検

• ねらい: 脅威の見える化。

• できること: Spoofing/Tampering/Repudiation/Information Disclosure/DoS/EoPの対策表を維持。

• キーワード: セキュリティトリミング, 監査再現, レート制限, RBAC分離

• 落とし穴: 生成後の後マスク依存。

• 練習: “検索で出ない”ことを一次防衛に設定。

F3. LLM特有のガード

• ねらい: プロンプトインジェクション等の生成時リスクを封じる。

• できること: 禁止事項の明文化、スキーマ検証、出典強制、PII検知、縮退モード。

• キーワード: 出力検証, refusal, DLP

• 落とし穴: “ほぼOK”のまま通過。

• 練習: すり抜け攻撃の評価セットを作り、更新時に回帰する。

G. CI/CD・IaC・供給網セキュリティ

G1. IaC（Bicep/Terraform）＆差分デプロイ

• ねらい: 再現性と監査性。

• できること: what-if→deploy、環境差分ゼロ、本番の手作業禁止。

• キーワード: Bicep/Terraform, GitHub Actions/Azure DevOps

• 落とし穴: ポータル経由の“ちょっとだけ”。

• 練習: すべてのリソースをコードで作り直し、手動変更を検出。

G2. 供給網（SAST/Secrets/SBOM/署名）

• ねらい: 依存脆弱性・秘密漏洩の早期検知。

• できること: Secrets scanning、SAST、SBOM生成、署名付きアーティファクト。

• キーワード: Trivy/GH Advanced Security等

• 落とし穴: “CIだけ通ればOK”。

• 練習: 依存のCVEレポートを定期生成。

H. 性能・信頼性（SLO／バックプレッシャ／縮退）

H1. レイテンシ分解とSLO

• ねらい: ボトルネックの局所化。

• できること: 取得／生成／後処理の段階別P95を可視化。

• キーワード: P50/P95/P99, timeout, retries

• 落とし穴: 一括で“遅い”。

• 練習: 段階別タイマーを組み込み、ダッシュボードに分解表示。

H2. スロットリング・バックプレッシャ・縮退モード

• ねらい: 障害時の計画的な劣化。

• できること: レート超過時のキューイング、要約のみや小モデル切替。

• キーワード: rate limit, circuit breaker, graceful degradation

• 落とし穴: 失敗→連続再試行で炎上。

• 練習: 単価急騰・ハルシネ率上昇時に自動縮退するルールを入れる。

I. PM／契約（エンジニアが知っておくべき最小限）

I1. RFP/SOW/受入KPI（数値）

• ねらい: “何を作れば合格か”を数値で固定。

• できること: 正答/根拠/ハルシネ、成功/flake、時間/誤り/準拠など。

• キーワード: DoR/DoD, マイルストーン, 変更管理（CR→A/B）

• 落とし穴: KPIが曖昧。

• 練習: 自プロダクトの受入表を1枚で書けるようにする。

用語ミニ辞典（30語）

• Security Trimming: 検索段階で権限外文書を候補から除外する方式。

• RRF: BM25とベクトル検索のランキング融合法。

• MMR: 類似候補の重複を抑え多様性を上げる再ランキング。

• Groundedness（根拠率）: 回答に出典が含まれる割合。

• Hallucination（ハルシネ）: 根拠にない断定。

• Lineage: 応答に紐づくモデル/プロンプト/インデックス/パラメータの系譜情報。

• Canary Release: 小規模ユーザでの試験投入。

• PIM: 特権の一時昇格管理。

• Sem. Cache: 意味類似での出力/要旨の再利用。

• Backpressure: 負荷時に上流へ制限を伝播する設計。

（※この他も必要なら追補できます）

現場演習セット（すぐに出来る3本）

1. RAGの当て力を数字で示す

   • 代表50問＋allowed sourcesを作成 → BM25のみ vs ハイブリッド＋再ランクをA/B → 正答・根拠・P95・単価の4軸で勝ち設定を採択。

2. テスト自動生成の“決定列化”

   • data-testidを網羅 → Record‑firstで10ケース → 操作DSL→テンプレ展開→CIで3連成功をゲート化。

3. スライドの“型＋品質ゲート”

   • スライド文法＋POTXマップを定義 → 12枚/60分で初稿 → 出典100%・誤り0・ブランド逸脱0を自動検査で通す。

チェックリスト（技術到達度セルフスコア）

• 基盤: PE/MI/KV/APIMを自分でIaCで立てられる（Yes/No）

• RAG: チャンク/辞書/再ランクでTop‑k≤5でも正答↑を再現できる（Yes/No）

• 生成制御: 関数呼び出し＋スキーマ検証で“ほぼJSON”を潰せる（Yes/No）

• LLMOps: 変更は単一種類でA/B → 勝ち定義を数字で示せる（Yes/No）

• コスト: 段階推論＋キャッシュで**単価▲X%**の実績がある（Yes/No）

• セキュリティ: セキュリティトリミングを“検索段”で効かせている（Yes/No）

まとめ

この知識マップを上から順に“潰す”と、安全（ゼロトラスト）×再現（LLMOps）×低コスト（設計レバー）の3拍子が揃います。まずは A（基盤）→B（取り込み／検索）→E（lineage＆評価） の3点を最優先で実装し、D（各プロダクトの型）へ展開してください。“ちゃんと当てる・記録する・数値で改善する”――これが現場のAIエンジニアにとっての必須スキルセットです。