--- title: うさうさ研修工房 ／ AI設計書レビュー PoC図解で学ぶ 実務レベルの設計書レビュー_20260622 tags: author: [smile_yukiko_it](https://www.docswell.com/user/smile_yukiko_it) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/K74WD2Q3E1.jpg?width=480 description: 2026/06/22 published: June 22, 26 canonical: https://www.docswell.com/s/smile_yukiko_it/53JJ68-2026-06-22-150355 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/K74WD2Q3E1.jpg) うさうさ研修工房 ／ AI設計書レビュー PoC 図解で学ぶ 実務レベルの設計書レビュー 各トピックを「1ページ図解（仕組み）＋1ページ実践ステップ（手順・パラメータ・Tips）」で解説 RAG 推論強化 観点別レビュー 評価・品質ゲート 構造化出力 技法の知識基盤は査読済み論文、実装手順は公式Docに準拠。実務でそのまま使える粒度でまとめています。 # Page. 2 ![Page Image](https://bcdn.docswell.com/page/LJ1YZMPZEG.jpg) OVERVIEW 全体像：設計書レビュー PoC のパイプライン ①取込 設計書・標準を チャンク化 → ②索引 (RAG) 根拠をベクタDBで 検索可能に → ③観点レビュー CoT/SCで 4観点を点検 → ④構造化出力 → 所見を型付き JSONで整形 ⑤評価・ゲート Judge/RAGASで 採点→合否 ▲ 評価結果を③へ差戻し（改善ループ：閾値未達はマージしない） 読み方： 以降の各トピックは 【図解】で仕組みを、【実践ステップ】で手順・パラメータ・Tipsを示します。 図解＆実践 ― 全体像 02 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/GJWG932672.jpg) TOPIC 1 ・ RAG 【図解】根拠付きレビューの仕組み（RAG） ① 事前準備（索引づくり） → 社内標準・規約 → チャンク分割 → 埋め込み ベクタDB 索引を参照 ② 実行時（検索して根拠付きで指摘） → 設計書の記述 → 類似検索 top-k → 根拠＋プロンプト → LLM生成 指摘＋典拠 肝：内部知識に頼らず「検索した根拠」に紐づけて指摘 「この記述は標準§4.2に不整合」のように指摘と典拠をセットで出力。根拠が引けない指摘は出さない設計にすることで、ハルシネーショ ン（誤生成）を構造的に抑える。 知識基盤：Lewis et al. 2020 / NeurIPS（RAG） 03 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/4EZL9VDR73.jpg) 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 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/Y76WK5117V.jpg) 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 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/G75MPY4L74.jpg) 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 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/9J296GV3ER.jpg) TOPIC 3 ・ REVIEW ASPECTS 【図解】4観点で設計書を点検する 網羅性 曖昧性 要件の抜け・記述漏れ 曖昧・多義な表現 設計書 ＋標準 一貫性 トレーサビリティ 用語・値の矛盾 上位→下位の追跡 各観点を独立プロンプトで点検 → 所見を一元集約 07 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/DEY49V38JM.jpg) TOPIC 3 ・ REVIEW ASPECTS 【実践ステップ】観点別レビューの実装 1 観点ごとにルーブリック定義 各観点の合否基準・重大度の付け方を明文化。判定の属人化を防ぐ。 2 1観点1プロンプト 観点を混ぜず独立実行。指示が単純化され、精度と再現性が上がる。 3 RAG＋マトリクスで照合 網羅性・一貫性はRAGで標準と突合。トレーサビリティは要件 設計の対応表で確認。 4 所見を構造化して集約 観点・該当箇所・重大度・根拠を1レコードに。重複・関連を後段で名寄せ。 実務Tips： 出力は「事実」と「所感」を分けさせる。レビュー記録の信頼性が上がり、Notion運用とも噛み合う。 公式Doc： Lubos 2024 / IEEE RE ・ Preda 2024 / MSR（査読済み） 08 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/VJNYLMV978.jpg) 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 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/YE9P4N63J3.jpg) 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 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/GE8DQKZLED.jpg) TOPIC 5 ・ STRUCTURED OUTPUT 【図解】型で品質を強制する構造化出力 スキーマ定義 Pydantic / Zod → LLM生成 → structured / JSON 検証 parse → 型付きオブジェクト へ（後段で集計） 型・enum検査 ▲ 検証失敗なら自動リトライ レビュー所見スキーマ（例） 観点（enum：網羅性/曖昧性/一貫性/トレーサビリティ） ・ 該当箇所（章・行） ・ 重大度（enum：高/中/低） ・ 根拠（引用） ・ 提 案 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/LELMXZDQ7R.jpg) 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 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/4JMYLVWKJW.jpg) TAKEAWAYS 実務導入の勘所 根拠ファースト RAGで典拠を引けない指摘は出さない。説明責任と誤検知抑制を同時に。 重要観点に推論を厚く 評価を“門番”に CoTは全体に、多数決(Self-Consistency)は重大観点だけに適用しコスト最適化。 RAGAS×Judgeを閾値ゲート化しCIへ。プロンプト変更の劣化を自動で止める。 型で機械処理を安定化 所見はenum付きスキーマで構造化。集計・レポートが破綻しない。 進め方： 小さく作る→評価で回す→ゲートで守る。各トピックの図解で仕組みを掴み、ステップで手を動かす。