うさうさ研修工房 / AI設計書レビュー PoC図解で学ぶ 実務レベルの設計書レビュー_20260622

>100 Views

June 22, 26

スライド概要

2026/06/22

profile-image

何卒よろしくお願い申し上げます。 一流のIT研修講師を目指し、日々研鑽を続けております。 本資料は外部公開用としてご提供するものです。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

うさうさ研修工房 / AI設計書レビュー PoC 図解で学ぶ 実務レベルの設計書レビュー 各トピックを「1ページ図解(仕組み)+1ページ実践ステップ(手順・パラメータ・Tips)」で解説 RAG 推論強化 観点別レビュー 評価・品質ゲート 構造化出力 技法の知識基盤は査読済み論文、実装手順は公式Docに準拠。実務でそのまま使える粒度でまとめています。

2.

OVERVIEW 全体像:設計書レビュー PoC のパイプライン ①取込 設計書・標準を チャンク化 → ②索引 (RAG) 根拠をベクタDBで 検索可能に → ③観点レビュー CoT/SCで 4観点を点検 → ④構造化出力 → 所見を型付き JSONで整形 ⑤評価・ゲート Judge/RAGASで 採点→合否 ▲ 評価結果を③へ差戻し(改善ループ:閾値未達はマージしない) 読み方: 以降の各トピックは 【図解】で仕組みを、【実践ステップ】で手順・パラメータ・Tipsを示します。 図解&実践 ― 全体像 02

3.

TOPIC 1 ・ RAG 【図解】根拠付きレビューの仕組み(RAG) ① 事前準備(索引づくり) → 社内標準・規約 → チャンク分割 → 埋め込み ベクタDB 索引を参照 ② 実行時(検索して根拠付きで指摘) → 設計書の記述 → 類似検索 top-k → 根拠+プロンプト → LLM生成 指摘+典拠 肝:内部知識に頼らず「検索した根拠」に紐づけて指摘 「この記述は標準§4.2に不整合」のように指摘と典拠をセットで出力。根拠が引けない指摘は出さない設計にすることで、ハルシネーショ ン(誤生成)を構造的に抑える。 知識基盤:Lewis et al. 2020 / NeurIPS(RAG) 03

4.

TOPIC 1 ・ RAG 【実践ステップ】RAGレビューの作り方 1 知識ベース整備 社内標準・規約・チェックリストをMarkdown化。見出し・章番号をメタデータ付与し「引用できる単位」に。 2 チャンク設計 目安500〜1000字、見出し単位で分割+10〜15%オーバーラップ。表は崩さず保持。 3 埋め込み&索引 4 検索+再ランク top-k=5前後を取得→rerankerで精度向上。引用範囲(章・行)を必ず保持。 5 生成(制約付き) プロンプトに『典拠を必ず付す/根拠なき指摘は出さない』を明記。出典は章番号で返す。 日本語対応の埋め込みモデルを選定し、pgvector等のベクタDBへ格納。 実務Tips: 「根拠が引けない指摘は出力しない」をシステムプロンプトで強制。これだけで誤検知が大きく減る。 公式Doc: python.langchain.com / js.langchain.com 04

5.

TOPIC 2 ・ REASONING 【図解】推論強化:飛躍・矛盾を捉える Chain-of-Thought 推論の途中を明示させる Self-Consistency 複数経路を生成し多数決で安定化 入力(設計書+観点) ステップ1:前提を確認 ステップ2:標準と照合 ステップ3:差異を特定 結論:根拠付き所見 ▼ ▼ ▼ 経路A 推論→結論 経路B 推論→結論 経路C 推論→結論 ▼ ▼ ▼ 多数決 → 安定した結論 ▼ 知識基盤:Wei et al. 2022 / NeurIPS(CoT)・Wang et al. 2023 / ICLR(Self-Consistency) 05

6.

TOPIC 2 ・ REASONING 【実践ステップ】推論強化の組み込み方 1 CoTを観点プロンプトに内蔵 2 重要観点だけ多重サンプル temperatureを上げ n=5 程度で複数生成。全項目に適用せずコストと精度を両立。 3 結論を正規化→多数決 指摘有無・重大度を正規化し Self-Consistency で集約。最頻の結論を採用。 4 不一致は人手フラグ 経路間で結論が割れた項目に『要人手確認』を付与し、レビュアへエスカレーション。 『根拠を段階的に示し、最後に結論』の形式を指定。途中経過で飛躍・前提誤りを発見しやすくする。 実務Tips: 多数決は高コスト。網羅性・一貫性など重大度の高い観点に絞って適用するのが現実的。 公式Doc: arxiv.org/abs/2201.11903 / arxiv.org/abs/2203.11171 06

7.

TOPIC 3 ・ REVIEW ASPECTS 【図解】4観点で設計書を点検する 網羅性 曖昧性 要件の抜け・記述漏れ 曖昧・多義な表現 設計書 +標準 一貫性 トレーサビリティ 用語・値の矛盾 上位→下位の追跡 各観点を独立プロンプトで点検 → 所見を一元集約 07

8.

TOPIC 3 ・ REVIEW ASPECTS 【実践ステップ】観点別レビューの実装 1 観点ごとにルーブリック定義 各観点の合否基準・重大度の付け方を明文化。判定の属人化を防ぐ。 2 1観点1プロンプト 観点を混ぜず独立実行。指示が単純化され、精度と再現性が上がる。 3 RAG+マトリクスで照合 網羅性・一貫性はRAGで標準と突合。トレーサビリティは要件 設計の対応表で確認。 4 所見を構造化して集約 観点・該当箇所・重大度・根拠を1レコードに。重複・関連を後段で名寄せ。 実務Tips: 出力は「事実」と「所感」を分けさせる。レビュー記録の信頼性が上がり、Notion運用とも噛み合う。 公式Doc: Lubos 2024 / IEEE RE ・ Preda 2024 / MSR(査読済み) 08

9.

TOPIC 4 ・ EVALUATION 【図解】評価と品質ゲート(CIに組み込む) 合格 → マージ LLM-as-a-Judge レビュー出力 → 所見の妥当性を採点 指摘+典拠 → スコア集計 閾値で判定 ▲ → 差戻し → 再レビュー RAGAS Faithfulness等を算出 差戻しは入力へ戻して再実行(CIで自動) 肝:主観評価を数値化し、閾値を“門番”にする 例:Faithfulness < 0.8 はマージ不可。プロンプト変更時の品質劣化をCIで自動検知し、回帰を防ぐ。 知識基盤:Zheng 2023 / NeurIPS(LLM-as-a-Judge)・Es 2024 / EACL(RAGAS) 09

10.

TOPIC 4 ・ EVALUATION 【実践ステップ】評価とゲートの作り方 1 評価データセット作成 代表的な設計書+期待される所見(正解例)をひとセット用意。小さく始める。 2 RAGAS指標を算出 Faithfulness/Answer・Context Relevanceを計測。根拠忠実性を定量化。 3 LLM-as-a-Judgeで採点 4 閾値をCIに組み込む スコア閾値を品質ゲート化。基準未達はマージ不可にして回帰を防止。 5 人手で抜き取り検証 自動評価を過信せず、定期的にサンプルを人手レビューして妥当性を担保。 審査プロンプトと対象を分離し、位置・冗長・自己優遇バイアスに対策。 実務Tips: 最初から完璧な指標を狙わない。少数の正解例+1指標で回し始め、運用しながら拡張する。 公式Doc: docs.ragas.io / promptfoo.dev 10

11.

TOPIC 5 ・ STRUCTURED OUTPUT 【図解】型で品質を強制する構造化出力 スキーマ定義 Pydantic / Zod → LLM生成 → structured / JSON 検証 parse → 型付きオブジェクト へ(後段で集計) 型・enum検査 ▲ 検証失敗なら自動リトライ レビュー所見スキーマ(例) 観点(enum:網羅性/曖昧性/一貫性/トレーサビリティ) ・ 該当箇所(章・行) ・ 重大度(enum:高/中/低) ・ 根拠(引用) ・ 提 案 11

12.

TOPIC 5 ・ STRUCTURED OUTPUT 【実践ステップ】構造化出力の実装 1 所見スキーマを定義 観点・該当箇所・重大度・根拠・提案を Pydantic(Py) / Zod(TS) で型定義。 2 structured outputで生成 function calling / JSON mode を使い、LLMにスキーマ準拠で出力させる。 3 parse+検証→自動リトライ 検証失敗時はエラーを添えて再生成。型に合うまで自動で整える。 4 型付きで後段へ 集計・重大度フィルタ・レポート生成へ。表記ゆれが無いので機械処理が安定。 実務Tips: 観点・重大度はenumで固定。自由記述を許すと表記ゆれで集計・フィルタが破綻する。 公式Doc: zod.dev / docs.pydantic.dev / ai-sdk.dev 12

13.

TAKEAWAYS 実務導入の勘所 根拠ファースト RAGで典拠を引けない指摘は出さない。説明責任と誤検知抑制を同時に。 重要観点に推論を厚く 評価を“門番”に CoTは全体に、多数決(Self-Consistency)は重大観点だけに適用しコスト最適化。 RAGAS×Judgeを閾値ゲート化しCIへ。プロンプト変更の劣化を自動で止める。 型で機械処理を安定化 所見はenum付きスキーマで構造化。集計・レポートが破綻しない。 進め方: 小さく作る→評価で回す→ゲートで守る。各トピックの図解で仕組みを掴み、ステップで手を動かす。