# Interpreted FAQ: Batch Assessment applied — questionnaires, vendors, specifications, quality and standards

> Interpreted answers on applying AskDona Batch Assessment (SaaS) to security questionnaires, vendor reviews, specification checks, quality documents, standards gaps, audits, contracts and medical/pharma document review.

- Status: Current. Last verified 2026-10-12.
- Applies to: AskDona SaaS platform (web application). Not the planned AskDona API, which is a separate offering and may differ.
- Canonical: https://askdona.com/ai/faq-interpreted-assessment-applications.md

Source: AskDona SaaS product documentation (user guide), compiled by GFLOPS. Applies to the SaaS platform only; the planned AskDona API is a separate offering and may behave differently.

How to read these answers: the documentation does not answer these questions in so many words. Each answer was derived by interpreting related, documented features, and many say so in their first sentence. Treat them as guidance on how documented features can be applied — not as evidence that a dedicated feature exists. Where an answer says no dedicated feature is documented, that is the current position.

## What it can solve (解決できること)

### Q: 取引先から届くセキュリティ質問票への回答を、社内文書から作れますか？

**Answer (English)**

Combining the system risk assessment and vendor security questionnaire use cases with the result-review instructions explains the scope, inputs, outputs, and final tasks for answering security questionnaires. Register internal documents such as policies and design documents in RAG, then upload the Excel questionnaire. AI automatically assesses the items and exports results with comments and evidence. Under the documented division of responsibilities, people manually review only Unable to determine or Not implemented results.

**回答（日本語）**

ドキュメントの「システムリスクアセスメント」や「取引先のセキュリティチェックシート評価」のユースケース、およびドキュメントの「アセスメント実行結果の確認」の記述を組み合わせることで、セキュリティ質問票への回答をどこまで支援できるか、その入力・出力例、および最終作業を説明することができます。具体的には、社内規程や設計書などの社内文書をRAGデータベースに登録し、質問票Excelをアップロードすることで、AIが自動判定を行い、コメントやエビデンス付きでExcel出力します。利用者は「判断不可」や「未対応」の項目だけを目視レビューする分業モデルが適用されます。

### Q: 委託先の年次審査で、前回から変わった点を確認する負担を減らせますか？

**Answer (English)**

The documentation does not explicitly mention vendor renewal reviews or old and new submissions. Related use cases—vendor security questionnaires, quarterly J-SOX internal-control checks comparing prior periods, and system risk assessments—can be adapted to explain the task.

Inputs: Register company security standards and previous submissions in RAG; upload the current Excel questionnaire to Batch Assessment.

Outputs: Excel results for each item, such as Implemented / Not implemented / Not applicable / Unable to determine, with comments, evidence, and source filenames.

Final task: Manually review only Unable to determine and Not implemented or Below the standard results, and ask vendors follow-up questions.

**回答（日本語）**

ドキュメントには「委託先の更新審査」や「新旧の提出資料」という言葉で直接言及している箇所はありません。しかし、関連するユースケースとして「取引先（ベンダー）のセキュリティチェックシート評価」や「四半期ごとの内部統制（J-SOX）チェック（前期と比較して変化がないかも見たい）」、「システムリスクアセスメント」が挙げられており、これらを意訳・応用することで回答を構成できます。

具体的には、以下のように整理できます：

- 入力例：自社のセキュリティ基準や前回の提出資料をRAGデータベースに登録し、今回の提出資料（チェックシートExcel）をBatch Assessmentにアップロードする。
- 出力例：各評価項目に対する判定結果（対応済み／未対応／対象外／判断不可など）、コメント、引用（エビデンス）、参照元ファイル名がExcelに出力される。
- 利用者が最終的に行う作業：「判断不可」や「未対応（基準未満）」の項目だけを目視レビューし、ベンダーに追加質問する。

### Q: 顧客の要求一覧と製品仕様書を、一項目ずつ照合する作業を減らせますか？

**Answer (English)**

The documentation does not give input/output examples explicitly labeled matching specifications to requirements. It does mention assessment based on vehicle specifications, and its system risk and vendor security questionnaire examples can be adapted to explain the task.

Inputs: Register specifications, such as design documents, in RAG and upload an Excel requirements list to Batch Assessment.

Outputs: AI automatically assesses each requirement and exports Result—such as Implemented / Not implemented / Not applicable / Unable to determine—Comment, Evidence excerpt, and Source filename to Excel.

Final task: People focus manual review and final decisions only on Unable to determine or Not implemented results.

**回答（日本語）**

ドキュメントには「仕様書と要求の照合」という表現そのものでの直接的な入力・出力例は記載されていませんが、ドキュメントに「車両仕様書に基づく評価判定」というユースケースが挙げられており、ドキュメントに記載されている「システムリスクアセスメント」や「ベンダーのセキュリティチェックシート評価」などのユースケースを「仕様書と要求の照合」に意訳して適用することで、具体的な入力例、出力例、および利用者が最終的に行う作業を説明することができます。

具体的には以下の通りです：

入力例：評価対象となる「仕様書（設計書など）」をRAGデータベースに登録し、照合したい「要求一覧（評価項目）」が記載されたExcelファイルをBatch Assessmentにアップロードします。

出力例：AIエージェントが各要求項目を自動判定し、判定結果（対応済み/未対応/対象外/判断不可など）、コメント（判定理由）、引用（エビデンス）、参照元（ファイル名）をExcelファイルに出力します。

利用者が最終的に行う作業：AIによる一次評価結果をもとに、担当者は「判断不可」や「未対応」と判定された項目のみに集中して目視レビュー（最終判断）を行います。

### Q: 設計レビュー前のチェックリスト確認を、AIで下準備できますか？

**Answer (English)**

Interpreting the documented system risk assessment use case as preparation for design review provides concrete inputs, outputs, and final tasks. Register design documents and operating procedures in RAG and upload an Excel checklist. The output is an Excel report with Result—Implemented / Not implemented / Not applicable / Unable to determine—Comment, Evidence excerpt, and Source. Users manually review only Unable to determine or Not implemented items.

**回答（日本語）**

ドキュメントに記載されている「システムリスクアセスメント」のユースケースを「設計レビューの準備」と意訳することで、具体的な入力例、出力例、および利用者が最終的に行う作業を示すことができます。入力例として「設計書・運用手順書」をRAGデータベースに登録し「評価項目入りのExcel」をアップロードすること、出力例として「判定結果（対応済み/未対応/対象外/判断不可）」「コメント」「引用（エビデンス）」「参照元」が記載されたExcelレポートが出力されること、利用者が最終的に行う作業として「判断不可」や「未対応」の項目だけを目視レビューすることが示されています。

### Q: 試験報告が要求を満たす証拠になっているか、確認を助けるAIはありますか？

**Answer (English)**

The documentation does not explicitly discuss matching test results to requirements or test reports to acceptance criteria. Batch Assessment and similar use cases can be adapted as follows.

Inputs: An Excel file of requirements or assessment items, and test reports or other documents registered in RAG.

Outputs: Excel results for each requirement, including Implemented / Not implemented / Not applicable / Unable to determine, a Comment explaining the assessment, an Evidence excerpt, and the Source filename.

Final task: Focus manual review only on Not implemented or Unable to determine items.

**回答（日本語）**

ドキュメント内には「試験結果と要件の照合」や「試験報告と要求基準」という言葉そのものに対する直接的な言及はありませんが、Batch Assessment機能の仕組みや類似のユースケースを意訳・応用することで回答が可能です。

具体的には、以下のように対応させることができます：

- 入力例：要求基準を記載したExcelファイル（評価項目）と、試験報告書などのドキュメント（RAGデータベースに登録）。
- 出力例：各要求基準に対する「判定結果（対応済み/未対応/対象外/判断不可など）」、「コメント（判定理由の説明）」、「引用（エビデンス）」、「参照元（ファイル名）」がExcelファイルに一括出力されます。
- 利用者が最終的に行う作業：AIが「未対応」や「判断不可」と判定した項目のみに集中して目視レビューを行います。

### Q: 品質手順書と現場の記録が一致しているか、項目別に確認できますか？

**Answer (English)**

The documentation does not explicitly mention quality procedures or checking quality-document consistency. Similar examples include internal-control checks using procedures and operational records and system risk assessments using design documents and operating procedures. These can be adapted to quality procedures and work records: register them in RAG and upload an Excel checklist; receive Excel outputs containing Result, Comment, Evidence excerpt, and Source; and manually review only Unable to determine or Not implemented items.

**回答（日本語）**

提供されたドキュメントには「品質手順書」や「品質文書の整合確認」という言葉は直接言及されていませんが、類似のユースケースとして「業務手順書・運用記録」を用いた内部統制チェックや「設計書・運用手順書」を用いたシステムリスクアセスメントが記載されています。これらを意訳・応用することで、品質手順書と作業記録を用いた整合確認の入力例、出力例、利用者が最終的に行う作業を具体的に示すことができます。具体的には、入力例として品質手順書や作業記録をRAGデータベースに登録し、チェックリストExcelをアップロードします。出力例として、判定結果、コメント、引用（エビデンス）、参照元がExcelで出力されます。利用者が最終的に行う作業は、「判断不可」や「未対応」の項目だけを目視でレビューすることです。

### Q: 外部基準が変わったとき、どの社内文書を見直すべきか調べられますか？

**Answer (English)**

The documentation does not explicitly describe assessing the impact of revised standards or a workflow using old and new standards with internal documents. Batch Assessment and system risk or vendor security questionnaire examples can be adapted: register internal documents in RAG and upload the new standard's requirements as Excel assessment items. AI assesses compliance and exports results, comments, and evidence. Users manually review only Not implemented or Unable to determine items and revise internal documents accordingly.

**回答（日本語）**

ドキュメントには「基準改訂の影響確認」という言葉や、新旧の基準と社内文書を用いた具体的な手順は直接記載されていません。しかし、Batch Assessment機能の概要や、システムリスクアセスメント、ベンダーのセキュリティチェックシート評価などのユースケースを意訳・応用することで、回答を構成することができます。具体的には、社内文書をRAGデータベースに登録し、新基準の要求事項をExcelの評価項目としてアップロードすることで、AIが社内文書の準拠状況を自動判定します。出力例として判定結果やコメント、エビデンスがExcelで出力され、利用者は「未対応」や「判断不可」の項目のみを目視レビューして社内文書の改訂作業を行うという流れになります。

## Conditions and scope (利用条件・適用範囲)

### Q: 「セキュリティ質問票への回答」でAIを使いたいのですが、「質問表現が取引先ごとに違う」という条件でも使えますか？

**Answer (English)**

The documentation does not directly address security questionnaires whose wording differs between business partners. However, Batch Assessment extracts items by dragging across the uploaded Excel preview and passes the original wording to the LLM. It also assesses items against company security standards and policies registered in RAG. Combining these specifications supports an explanation of handling differently worded questionnaires and necessary preparation, such as registering the company's security information in RAG.

**回答（日本語）**

ドキュメントには「質問表現が取引先ごとに違う」状況における「セキュリティ質問票への回答」への適用範囲（対応条件、追加設定、対応できないケース）について直接的な言及はありません。しかし、Batch Assessment機能において、アップロードしたExcelのプレビューからドラッグして項目を抽出し、元のExcelの表現（取引先ごとの異なる質問表現）をそのままLLMに渡して処理できること、またRAGデータベースに自社のセキュリティ基準や規定を登録して照合判定を行う仕組みが説明されているため、これらを組み合わせることで、取引先ごとに異なる質問票に対しても対応可能であることや、必要な追加設定（自社セキュリティ情報のRAG登録など）を意訳して説明することができます。

### Q: 「委託先の一次評価」でAIを使いたいのですが、「資料の形式が企業ごとに異なる」という条件でも使えますか？

**Answer (English)**

Differences in file formats between companies can be interpreted in two ways: the Excel checklist layout and the formats of supporting evidence.

Different Excel layouts

- Batch Assessment extracts items from selected preview cells and maps four output columns: Result, Comment, Evidence excerpt, and Source. Different company layouts therefore require separate assessment configurations rather than reuse of one setup.
- A single configuration cannot directly process multiple Excel files with different layouts or column positions.
- Distributing a common Excel template to vendors enables reuse: after the initial setup, subsequent runs require only a new Excel upload.

Different evidence formats

- RAG supports PDF, Word, Excel, PowerPoint, CSV, txt, HTML, md, json, and image files. Differently formatted submissions can be registered and processed, then searched and referenced by AI for assessment.
- For scanned PDFs and images, enable Analyze images in documents. SaaS is recommended for materials containing complex tables or equations because it is better suited to extracting them.

**回答（日本語）**

「資料の形式が企業ごとに異なる」という条件について、以下の2つの側面（評価項目を抽出・出力するExcelシートの形式、および参照するエビデンス資料の形式）から意訳することで、適用範囲や対応条件、追加設定、対応できないケースを説明できます。

評価項目を抽出・出力するExcel（チェックシート）の形式が企業ごとに異なる場合：

- 対応条件・追加設定：Batch Assessmentでは、アップロードしたExcelのプレビューから項目をドラッグして抽出し、出力先の4つの列（判定結果、コメント、引用、参照元）をマッピングして設定します。そのため、Excelの形式が企業ごとに異なる場合は、同じアセスメント設定を使い回すことができず、企業（形式）ごとにアセスメントを新規作成して設定を行う必要があります。
- 対応できないケース：1つのアセスメント設定で、異なるレイアウトや列配置を持つ複数のExcelファイルをそのまま処理することはできません。
- 推奨される運用：自社指定の共通テンプレート（同じ形式のExcel）を各ベンダーに配布して記入してもらうことで、「同じテンプレートを別ベンダーで何度も使い回せます。1回設定すれば、次回以降は新しいExcelをアップするだけで済みます」というメリットを享受できます。

参照するエビデンス資料（セキュリティ報告書や規程など）の形式が企業ごとに異なる場合：

- 対応条件・追加設定：AskDonaのRAGデータベースは、PDF、Word、Excel、PowerPoint、CSV、txt、HTML、md、json、画像ファイルなど多様なファイル形式に対応しています。そのため、企業ごとに提出される資料の形式が異なっていても、RAGデータベースに登録してドキュメント処理を実行すれば、AIはそれらを検索・参照して評価を行うことができます。
- 追加設定：スキャンされたPDF（画像PDF）や画像ファイルの場合は、「ドキュメント内の画像を解析する」オプションを有効にして処理する必要があります。また、複雑な表レイアウトや数式が含まれる場合は、それらの抽出が得意なSaaS版の利用が推奨されます。

### Q: 「委託先の更新審査」でAIを使いたいのですが、「同じ項目でも回答が変わる」という条件でも使えますか？

**Answer (English)**

The documentation does not explicitly discuss answers changing for the same item, but its examples of quarterly assessments and template reuse across vendors support this interpretation.

Conditions: Register each vendor's documents in RAG and add metadata. At execution, select the target through the input flow so metadata filters switch the referenced documents. The same item can then receive different results for different targets.

Configuration: Add file metadata, select a key such as vendor name in Step 4, Input Flow, and configure database filtering based on the answer.

Limitations: Without metadata or enabled metadata filtering, the intended scope cannot be isolated and information may be mixed. If the knowledge base lacks necessary information, the result is Unable to determine.

**回答（日本語）**

ドキュメントには「同じ項目でも回答が変わる」という表現そのものは直接使われていませんが、同じアセスメントを四半期ごとに実施して業務の変化を定点観測するユースケースや、同じテンプレートを別ベンダーで何度も使い回すユースケースが示されており、これらを意訳することで回答が可能です。

対応条件：

評価対象（委託先）ごとのドキュメントをRAGデータベースに登録し、メタデータを付与します。アセスメント実行時に「入力フロー」を用いて評価対象を選択し、メタデータで参照するドキュメントを切り替えることで、同じ評価項目であっても対象に応じた異なる判定結果（回答）を得ることができます。

追加設定：

- RAGデータベース登録時のメタデータ付与
- アセスメント新規作成時の「ステップ4：入力フロー」におけるメタデータキー（例：委託先名）の選択設定
- 入力フローの回答に基づくRAGデータベースのフィルタリング設定

対応できないケース：

- ファイルにメタデータが付与されていない、またはメタデータフィルター設定が有効化されていない場合（適切な絞り込みが行えず、情報が混ざってしまいます）
- 判定に必要な情報がナレッジベースに不足している場合（この場合は「判断不可」と判定されます）

### Q: 「車両仕様の一次判定」でAIを使いたいのですが、「型式や地域で条件が違う」という条件でも使えますか？

**Answer (English)**

The internal-control use case and the input-flow and item-filter specifications can be adapted to conditions that differ by model or region. Add model or region metadata to documents, have users select it in the input flow, and configure item filters to mark irrelevant items Not applicable automatically. This interpretation explains the requirements, additional configuration, and unsupported cases.

**回答（日本語）**

ドキュメントの内部統制チェックのユースケースや、ドキュメントのアセスメント新規作成における「入力フロー」および「項目フィルタ」の仕様を、ユーザーの「型式や地域で条件が違う」という条件に意訳・適用することで、対応条件、追加設定、対応できないケースを説明できます。具体的には、型式や地域ごとにドキュメントにメタデータを付与し、入力フローでそれらを選択させ、項目フィルタで該当しない項目を自動的に「対象外」に設定することで対応可能です。

### Q: 「設計レビューの準備」でAIを使いたいのですが、「図と文章の両方に根拠がある」という条件でも使えますか？

**Answer (English)**

The documentation states that selecting Analyze images in documents during RAG processing incorporates information from charts, diagrams, and other images. It also discusses differences between SaaS and Docker/cloud-hosted parsing engines and their accuracy for equations and chemical formulas. Interpreting and organizing this information for design-review evidence spanning both diagrams and text explains the supported conditions, additional settings, and limitations.

**回答（日本語）**

ドキュメントには、RAGデータベースへのファイルアップロード時に「ドキュメント内の画像を解析する」オプションを選択することで、グラフや図表などの画像内容を解析して情報として取り込めることが記載されています。また、SaaS版とDocker版（クラウドホスト版）での解析エンジンの違いや、数式・化学式の抽出精度の差についても言及されています。これらの情報を「図と文章の両方に根拠がある」という条件における「設計レビューの準備」への適用範囲として意訳・整理することで、対応条件、追加設定、対応できないケースを説明することができます。

### Q: 「品質文書の整合確認」でAIを使いたいのですが、「記録に略語が多い」という条件でも使えますか？

**Answer (English)**

The documentation explains why AI may not understand proprietary terminology such as internal abbreviations and recommends creating and registering a glossary in RAG as an underlying solution. It provides CSV glossary-writing guidance and describes possible failures without this preparation, such as irrelevant answers or no reference information. Applying this terminology guidance explains the scope for checking quality-document consistency.

**回答（日本語）**

ドキュメントにおいて、社内の略語などの独自用語をAIが理解できない原因と、その根本対応として「用語集を作成し、RAGデータベースに投入する」という対応条件が説明されています。また、追加設定としてCSVファイルを用いた用語集の具体的な書き方や、対応しない場合（的外れな回答や「参照情報なし」になる）という対応できないケースについても言及されています。「品質文書の整合確認」という特定のユースケースにおける適用範囲については、これらの略語対策を適用して解釈することで説明が可能です。

### Q: 「医療・製薬の文書レビュー」でAIを使いたいのですが、「厳密な版管理が必要」という条件でも使えますか？

**Answer (English)**

The documentation explains RAG file updates and version management. It does not directly discuss medical or pharmaceutical document review, but its guidance can be interpreted for strict version-control requirements. Uploading files with identical names is discouraged. Users should manage versions through filenames, file contents, or metadata, or delete old files. These specifications explain the requirements, additional configuration, and unsupported or discouraged operations.

**回答（日本語）**

ドキュメントにおいて、RAGデータベースにおけるファイルの更新やバージョン管理に関する仕様が説明されています。「医療・製薬の文書レビュー」という特定のユースケースについての直接的な言及はありませんが、「厳密な版管理が必要」という条件に対して、AskDonaで対応するための条件や追加設定、対応できないケース（推奨されない操作）を意訳して説明することが可能です。具体的には、同一名称でのファイルアップロードは推奨されておらず、ファイル名、ファイルの中身、またはメタデータでバージョン管理を行うか、古いファイルを削除するなどの対応が必要となります。

## Setup and operation (準備・操作・運用)

### Q: 「第三者評価の説明」を始めるには、一次評価と証拠資料をどう準備し、どんな操作をすればよいですか？

**Answer (English)**

The documentation does not literally discuss explaining a third-party assessment. Interpreting this as the Batch Assessment workflow of preparing assessment items and evidence, running the assessment, and reviewing results provides the following answer.

- Register design documents, operating procedures, or other evidence in RAG and process them.
- Upload an Excel checklist, extract items by dragging in the preview, and assign Result, Comment, Evidence excerpt, and Source columns.
- Start a new run, answer the input flow, select items, execute, and review all four fields in History.
- Upload, selection, execution, review, and Excel export are standard functions. RAG registration and processing, empty Excel output columns, and filtering metadata are additional preparation.

**回答（日本語）**

提供されたドキュメントには「第三者評価の説明」という言葉は文字通りには存在しません。しかし、これを「Batch Assessment（バッチアセスメント）」機能を用いて、評価項目（一次評価）と証拠資料（RAGデータベースに登録するドキュメント）を準備し、アセスメントを実行して結果を確認する一連の流れとして意訳（解釈）すれば、回答となる情報が存在します。

具体的には、以下の手順や区別についてドキュメントに記載されています。

証拠資料の準備・登録：設計書や運用手順書などのドキュメントをRAGデータベースに登録し、ドキュメント処理を実行すること。

一次評価の準備・登録：評価項目が記載されたExcelファイルをアップロードし、プレビュー上でドラッグして項目を抽出し、出力先となる4つの列（判定結果、コメント、引用、参照元）を割り当てること。

実行と結果確認：利用者が「新規実行」から入力フローに回答し、項目を選択して実行を開始し、完了後に「履歴」から結果（判定結果、コメント、引用、参照元）を確認すること。

標準機能と追加対応の区別：標準機能としてExcelのアップロードやドラッグ選択、実行、結果確認、Excelレポート出力が提供されている一方、追加対応（事前準備）としてRAGデータベースへのドキュメント登録・処理、Excelファイルへの出力用空列の用意、フィルタリング用のメタデータ付与が必要であること。

### Q: 「車両仕様の一次判定」を始めるには、車両仕様書と評価項目をどう準備し、どんな操作をすればよいですか？

**Answer (English)**

The documentation identifies assessment based on vehicle specifications as a use case and details the relevant Batch Assessment and RAG database procedures. Applying them to an initial vehicle-specification review gives the following workflow.

Preparation: Upload and process the vehicle specifications in RAG. Upload an Excel checklist with empty output columns to Batch Assessment and extract items by dragging across the item column. Configure the input flow, filters, result options, output mapping, and prompt, then publish.

Execution: Run the assessment, review results, comments, evidence, and sources in History, and optionally export an Excel report.

Standard features include RAG upload and processing, Excel upload and extraction, all configuration screens, testing and publication, execution, history review, and export. Additional user preparation includes obtaining the vehicle specifications, such as PDFs, creating the Excel checklist and empty output columns, and refining prompts and specific option descriptions to improve accuracy.

**回答（日本語）**

ドキュメントには「車両仕様書に基づく評価判定」というユースケースの存在が示されており、その具体的な設定・実行手順は「Batch Assessment」機能および「RAGデータベース」機能として詳細に説明されています。これらを「車両仕様の一次判定」の文脈に当てはめて整理することで、利用者が行うべき作業と標準機能・追加対応の区別を明らかにできます。

利用者が行う作業（準備・登録から結果確認まで）

- 準備・登録：評価対象となる車両仕様書をRAGデータベースにアップロードしてドキュメント処理を実行します。また、評価項目を記載したExcelファイル（結果出力用の空列をあらかじめ用意したもの）をBatch Assessmentにアップロードし、プレビュー上で評価項目の列をドラッグして抽出します。その後、入力フロー、項目フィルタ、評価選択肢、出力列マッピング、プロンプトを設定して公開します。
- 実行・結果確認：アセスメントを実行し、完了後に履歴から判定結果、コメント、引用（エビデンス）、参照元を確認します。結果はExcelレポートとして一括出力することも可能です。

標準機能と追加対応の区別

- 標準機能で済む範囲：RAGデータベースへのファイル登録・処理機能、Batch AssessmentにおけるExcelのアップロード、ドラッグによる項目抽出、各種設定（入力フロー、フィルタ、選択肢、出力マッピング、プロンプト）、テスト実行・公開、アセスメントの実行、履歴からの結果確認、Excelレポート出力機能。
- 追加対応（利用者側の準備・運用）：評価対象の車両仕様書（PDF等）の用意、評価項目Excelの作成と出力用空列の事前用意、判定精度向上のためのプロンプトや評価選択肢の具体的な説明（LLMへの指示）の調整。

### Q: 「設計レビューの準備」を始めるには、設計書とレビュー項目をどう準備し、どんな操作をすればよいですか？

**Answer (English)**

Although design-review preparation is not explicitly named, related Batch Assessment use cases and feature descriptions can be combined into a workflow.

- Upload design documents to RAG and process them until complete.
- Upload an Excel checklist, extract items by dragging in the preview, configure output and result options, and publish.
- Run the assessment, review results and evidence in History, and export an Excel report.

Upload, extraction, execution, on-screen review, and Excel export are standard functions. Registering and processing design documents in RAG, preparing empty output columns, and adding metadata where needed are additional preparation.

**回答（日本語）**

「設計レビューの準備」という特定の表現自体はドキュメントに直接記載されていませんが、Batch Assessment機能を用いた「設計書」と「評価項目（Excel）」の準備・登録から結果確認までの手順、および標準機能と追加対応の区別については、関連するユースケースや機能説明を組み合わせることで回答可能です。

具体的には、以下の手順と区別が説明できます：

設計書の準備・登録：設計書をRAGデータベースにアップロードし、ドキュメント処理を実行して「処理完了」にします。

レビュー項目の準備・登録：評価項目が記載されたExcelファイルをアップロードし、プレビュー上でドラッグして項目を抽出します。出力設定や評価選択肢を設定して公開します。

実行と結果確認：アセスメントを実行し、完了後に履歴から判定結果やエビデンスを確認し、Excelレポートとして出力します。

標準機能と追加対応の区別：

- 標準機能：Excelのアップロード、ドラッグによる項目抽出、アセスメントの実行、画面での結果確認、Excelレポート出力。
- 追加対応（事前準備）：設計書のRAGデータベースへの登録・処理、Excelファイルへの出力用空列（判定結果、コメント等）の事前用意、必要に応じたメタデータの付与。

### Q: 「規格とのギャップ整理」を始めるには、利用許諾のある規格と自社文書をどう準備し、どんな操作をすればよいですか？

**Answer (English)**

The documentation does not explicitly discuss gap analysis against standards, but details Batch Assessment against internal or security standards and distinguishes standard functions from preparation. Applied to standards gaps, the workflow is:

Preparation

- Upload company policies, guidelines, and operational documents to RAG and process them until complete.
- Prepare an Excel file of standard requirements with four empty columns: Result, Comment, Evidence excerpt, and Source.
- An administrator creates the assessment, selects the RAG database, uploads Excel, extracts items by dragging, maps output columns, and configures the prompt.

Execution

- Run the assessment.
- Review all four result fields in History.
- Download the results together as an Excel report.

Standard functions include RAG upload and processing, the creation wizard, item extraction and settings, execution, review, and export. Registering company documents and preparing empty Excel output columns are additional preparation.

**回答（日本語）**

「規格とのギャップ整理」という具体的な表現はドキュメントに直接記載されていませんが、Batch Assessment機能を用いて自社基準やセキュリティ基準と突き合わせて評価する手順（準備・登録から結果確認まで）や、標準機能と事前準備（追加対応）の区別については詳細に記載されており、これらを「規格とのギャップ整理」に当てはめて解釈（意訳）することで回答可能です。

【利用者が行うこと】

準備・登録：

- 自社文書（社内規定、ガイドライン、運用ドキュメントなど）をRAGデータベースにアップロードし、ドキュメント処理を実行して「処理完了」にします。
- 規格の要求事項（評価項目）が記載されたExcelファイルを準備します。この際、結果出力用の4つの空列（判定結果、コメント、引用、参照元）をあらかじめ用意しておきます。
- 管理者が新規アセスメントを作成し、RAGデータベースの選択、Excelファイルのアップロード、プレビュー上でのドラッグによる項目抽出、出力列のマッピング、プロンプト設定などを行います。

実行・結果確認：

- 利用者がアセスメントを実行します。
- 実行完了後、履歴から判定結果、コメント、引用（エビデンス）、参照元を確認します。
- 結果をExcelレポートとして一括出力（ダウンロード）します。

【標準機能と追加対応の区別】

- 標準機能で済む範囲：RAGデータベースへのアップロード・処理機能、アセスメント作成ウィザード（項目抽出、出力設定、プロンプト設定など）、アセスメントの実行・結果確認・Excel出力機能。
- 追加対応（事前準備）：自社文書のRAGデータベースへの登録、Excelファイルへの出力用空列の事前追加。

### Q: 「基準改訂の影響確認」を始めるには、新旧の基準と社内文書をどう準備し、どんな操作をすればよいですか？

**Answer (English)**

The documentation does not directly name impact assessment for revised standards. Case 2, comparing company security standards registered in RAG with vendor Excel questionnaires, can be adapted to explain the workflow.

Preparation: Register and process the relevant standards and internal documents in RAG. Prepare and upload an Excel checklist, extract items, and assign Result, Comment, Evidence excerpt, and Source columns.

Execution: Start a new run, answer the input flow, select items, and execute. Review all four fields in History and export an Excel report.

Upload, processing, extraction, execution, review, and export are standard functions. Additional preparation includes source documents, the Excel checklist with four empty output columns, and filtering metadata.

**回答（日本語）**

提供されたドキュメントには「基準改訂の影響確認」という具体的なユースケースについての直接的な言及はありません。しかし、Batch Assessment機能を用いて「自社のセキュリティ基準ドキュメントをRAGデータベースに登録し、ベンダーのチェックシートExcelと突き合わせて評価する」といった類似のユースケース（ケース2）が示されています。これを「基準改訂の影響確認」に置き換えて解釈（意訳）することで、新旧の基準と社内文書の準備・登録から結果の確認までの手順、および標準機能と追加対応の区別について回答することができます。

具体的には、以下の手順と区別が成り立ちます：

準備・登録：評価対象となる基準ドキュメントや社内文書をRAGデータベースに登録・処理します。また、評価項目を記載したExcelファイルを準備し、Batch Assessmentにアップロードして項目を抽出します。出力設定で、判定結果、コメント、引用、参照元の4つの出力列を指定します。

実行・結果確認：利用者はアセスメントを新規実行し、入力フローへの回答や項目の選択を行って実行を開始します。実行完了後、履歴から判定結果、コメント、引用、参照元を確認し、Excelレポートとして一括出力します。

標準機能と追加対応の区別：ファイルのアップロード・処理、Excelからの項目抽出、アセスメントの実行・結果確認・Excel出力は標準機能で提供されます。追加対応（事前準備）として、評価用ドキュメントやExcelファイルの事前準備（Excel側に出力用の空の4列を用意しておくことなど）、絞り込み用のメタデータ付与が必要です。

## Preventing errors and checking quality (失敗への対処・品質)

### Q: 「セキュリティ質問票への回答」で、社内で未実施の対策を実施済みと回答することが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation can be interpreted to explain how AskDona helps identify and prevent incorrectly reporting an unimplemented internal control as implemented.

Controls and display

- Include Unable to determine to prevent forced conclusions when information is insufficient.
- Give strict prompt instructions, such as marking Not implemented whenever any criterion is unmet.
- Results display Implemented / Not implemented / Not applicable / Unable to determine, a Comment explaining the reasoning, an Evidence excerpt, and the Source filename, allowing the implementation evidence to be inspected.

Verification and human decisions

- Review all four fields in the results screen or Excel report. Test a small sample before publication to check for incorrect assessments and adjust settings.
- AI performs the initial assessment; people use comments and evidence to make final decisions on Unable to determine and Not implemented items, and, where appropriate, items marked Implemented as well.

**回答（日本語）**

AskDonaにおいて「社内で未実施の対策を実施済みと回答する」という誤判定を検出・抑制・表示する方法、および人が判断する範囲については、ドキュメントの記載を意訳することで以下のように回答できます。

検出・抑制・表示する方法

- 抑制・検出: アセスメント作成時の「評価選択肢」の設定で「判断不可」を含めることにより、情報不足の場合にLLMが無理な結論（未実施のものを対応済みとするなど）を出すことを防ぎます。また、「プロンプト」設定において「少しでも基準を満たさない場合は未対応と判定すること」のように明確に指示することで、厳格な評価を行わせ、誤判定を抑制できます。
- 表示: アセスメントの実行結果として、判定結果（対応済み/未対応/対象外/判断不可）だけでなく、その判定に至った理由を説明する「コメント」、判定の根拠となった情報源からの「引用（エビデンス）」、および「参照元」のファイル名を表示します。これにより、本当に実施されているかどうかの根拠を視覚的に確認・検出できます。

できない場合の確認手順と人が判断する範囲

- 確認手順: 実行結果画面や出力されたExcelレポートにおいて、各項目の判定結果、コメント、引用（エビデンス）、参照元を確認します。また、公開前に少ない項目数で「テスト実行」を行い、判定結果が期待通り（誤判定がないか）を確認・調整します。
- 人が判断する範囲: 「一次評価をAIに、最終判断を人間に」という分業モデルに基づき、担当者は「判断不可」や「未対応」とされた項目（あるいは対応済みとされた項目も含め）、出力されたコメントや引用（エビデンス）をもとに目視レビューを行い、最終的な判断を下します。

### Q: 「セキュリティ対策の証拠」で、文書上の対策を実装済みと扱うことが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not directly discuss treating documented security measures as implemented controls. Batch Assessment settings, result-review guidance, and the division of AI and human responsibilities can be interpreted to address this concern. Outputs show Result, Comment, Evidence excerpt, and Source. Unable to determine limits forced conclusions when information is missing, while a prompt requiring Not implemented whenever any criterion is unmet discourages unsupported implementation claims. When AI cannot decide, and for final verification, people review comments, evidence, and original source files and make the final decision.

**回答（日本語）**

ドキュメントには「セキュリティ対策の証拠」で「文書上の対策を実装済みと扱う」ことに対する直接的な言及はありませんが、アセスメント機能（Batch Assessment）の設定や実行結果の確認方法、および人とAIの分業モデルに関する記述を意訳することで回答が得られます。具体的には、AskDonaはアセスメント実行結果として「判定結果」「コメント（判定理由）」「引用（エビデンス）」「参照元」を表示し、根拠を明確にします。また、アセスメント設定時に「判断不可」の選択肢を設けることで情報不足時の無理な結論を抑制し、プロンプトで「少しでも基準を満たさない場合は未対応と判定すること」と厳格な評価を指示することで曖昧な実装済み扱いを防ぐことができます。AIが判断できない場合や最終確認は、人が「コメント」や「引用（エビデンス）」、および「参照元」ファイルを確認して最終判断を行う分業モデルが推奨されています。

### Q: 「委託先の更新審査」で、重要な変更を見落とすことが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not directly describe preventing important changes from being missed in vendor renewal reviews. Batch Assessment specifications can be combined to explain the following controls for vendor and recurring assessments.

Prevention

- Run the same assessment periodically to track operational changes.
- Include Unable to determine to avoid forced conclusions when information is insufficient.
- Require Not implemented whenever any criterion is unmet to encourage strict assessment.
- Test a small sample and refine prompts and option descriptions to improve accuracy.

Display: Each item shows Result, Comment, Evidence excerpt, and Source filename.

Human follow-up: AI performs the initial assessment. Reviewers focus manual review, final decisions, and vendor follow-up questions only on Unable to determine or Not implemented results, including Below the standard or Further confirmation required.

**回答（日本語）**

ドキュメントには「委託先の更新審査」という表現で直接「重要な変更を見落とす」ことへの対策が書かれているわけではありませんが、取引先（ベンダー）の評価や定期的なアセスメントにおける見落とし防止策、表示方法、および人が判断する範囲について、Batch Assessment機能の仕様を組み合わせることで回答が可能です。

検出・抑制の方法：

- 同じアセスメントを定期的に実施することで、業務の変化を定点観測できます。
- 評価選択肢に「判断不可」を含めることで、情報不足の場合にLLMが無理な結論を出すことを防ぎます。
- プロンプトで「少しでも基準を満たさない場合は未対応と判定すること」のように明確に指示することで、厳格に評価させ見落としを抑制できます。
- 少ない項目数でテスト実行を行い、プロンプトや評価選択肢の記述を調整することで判定精度を向上させます。

表示方法：

- アセスメント実行結果画面において、各評価項目に対して「判定結果」「コメント（判定理由）」「引用（エビデンス）」「参照元（ファイル名）」が表示されます。

できない場合の確認手順と人が判断する範囲：

- 「一次評価をAIに、最終判断を人間に」という分業モデルを基本とします。
- AIが判定した結果のうち、「判断不可」や「未対応（基準未満、追加確認が必要）」となった項目のみを、担当者が目視でレビュー（最終判断）したり、ベンダーへ追加質問したりする手順をとります。

### Q: 「第三者評価の説明」で、判定だけが一人歩きすることが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not explicitly discuss decisions being circulated without their context. Related descriptions can be organized to explain safeguards and human responsibilities.

Display and prevention: Batch Assessment outputs Result, Comment explaining the decision, Evidence excerpt, and Source together, helping keep the decision attached to its basis. Include Unable to determine to prevent forced conclusions from missing information, and use strict prompt rules such as marking Not implemented whenever any criterion is unmet.

Verification: Review the comments, evidence, and source filenames alongside the result in the results screen or Excel report.

Human decisions: AI performs the initial assessment. People make final decisions on Unable to determine, Not implemented, Below the standard, or Further confirmation required results.

**回答（日本語）**

ドキュメントには「判定だけが一人歩きする」という表現自体への直接的な言及はありませんが、判定結果の誤利用や一人歩きを防ぐための機能、表示方法、および人間が判断すべき範囲について、関連する記載を意訳・整理することで回答できます。

検出・抑制・表示について：

- 表示: AskDonaのBatch Assessmentでは、判定結果（対応済み／未対応など）だけでなく、判定に至った理由を説明する「コメント」、判定の根拠となった情報源からの「引用（エビデンス）」、判定に使用された「参照元」の4つの情報をセットで表示・出力します。これにより、判定結果だけが一人歩きすることを防ぎます。
- 抑制: 評価選択肢の設定で「判断不可」を設けることで、情報不足の場合にLLMが無理な結論（判定）を出すことを防ぎます。また、プロンプトで「少しでも基準を満たさない場合は未対応と判定すること」のように厳格な評価方針を指示することで、曖昧な判定を抑制できます。

確認手順と人が判断する範囲について：

- 確認手順: アセスメント結果画面や出力されたExcelレポートにおいて、判定結果に加えて「コメント」や「引用（エビデンス）」、「参照元」のファイル名を確認します。
- 人が判断する範囲: 「一次評価をAIに、最終判断を人間に」という分業モデルを基本とし、AIが「判断不可」や「未対応」と判定した項目、あるいは「基準未満」「追加確認が必要」とした項目について、人間の担当者が目視でレビューし最終判断を行います。

### Q: 「設計レビューの準備」で、図面上の条件を読み落とすことが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not directly discuss design-review preparation or overlooking conditions in drawings. Batch Assessment and RAG chat mechanisms can be applied to explain safeguards and human responsibilities. Include Unable to determine to prevent forced conclusions when information is insufficient, and display results such as Unable to determine or Not implemented. Comments, evidence, and sources let users inspect the basis. Under the initial-AI-assessment, final-human-decision model, staff manually review only Unable to determine or Not implemented items.

**回答（日本語）**

ドキュメントには「設計レビューの準備」や「図面上の条件を読み落とす」という具体的なユースケースについての直接的な言及はありません。しかし、AskDonaのBatch Assessment機能やRAGチャットの仕組みを応用することで、条件の読み落としを検出・抑制・表示する方法や、人が判断する範囲について説明することができます。具体的には、Batch Assessmentにおいて評価選択肢に「判断不可」を設定することで、情報不足の場合にLLMが無理な結論を出すことを防ぎ（抑制）、判定結果として「判断不可」や「未対応」を表示します。また、AIが判定した結果に対して、コメントや引用（エビデンス）、参照元を表示することで、ユーザーがその根拠を確認できるようにします。AIにすべてを任せるのではなく、「一次評価をAIに、最終判断を人間に」という分業モデルをとり、担当者は「判断不可」や「未対応」の項目だけを目視レビュー（人が判断する範囲）します。

### Q: 「品質文書の整合確認」で、記録の欠落を作業未実施と断定することが心配です。どう防いで確認できますか？

**Answer (English)**

General Batch Assessment settings and its human/AI operating model can be applied to avoiding the assumption that missing records prove work was not performed in quality-document checks.

Prevention and display

- In Step 6, add Unable to determine with the criterion “The knowledge base lacks the information required for assessment.” This prevents missing records from forcing a Not implemented conclusion.
- In Step 8, specify assessment policies and how missing records should be treated.
- Results show Implemented / Not implemented / Not applicable / Unable to determine, Comment, Evidence excerpt, and Source, making the reason and evidence for either an undetermined or negative result visible.

Verification and human decisions

After execution, review comments and evidence for Unable to determine or Not implemented items. Under the initial-AI-assessment, final-human-decision model, people manually review these items and make final decisions.

**回答（日本語）**

「品質文書の整合確認」において「記録の欠落を作業未実施と断定する」ことへの対処について、AskDonaのBatch Assessment機能を用いた具体的な検出・抑制・表示方法、および確認手順と人が判断する範囲は、ドキュメントに記載されている一般的なアセスメント設定や分業モデルの記述を意訳・適用することで回答できます。

検出・抑制・表示の方法：

- 抑制（無理な結論の防止）：アセスメントの新規作成における「ステップ6：評価選択肢」の設定で、「判断不可」という選択肢を追加し、その説明（LLMへの指示）に「判定に必要な情報がナレッジベースに不足している場合」と記入します。これにより、記録の欠落（情報不足）がある場合に、AIが無理に「未対応（作業未実施）」などの結論を出すことを防ぐ（抑制する）ことができます。
- 検出・制御（プロンプトによる指示）：「ステップ8：プロンプト」において、評価の方針や注意事項を記述します。例えば、記録がない場合にどう判定するかを明確に指示することで、判定品質を調整・制御できます。
- 表示：アセスメントの実行結果画面や出力レポートにおいて、各評価項目に対して「判定結果（対応済み / 未対応 / 対象外 / 判断不可）」、「コメント（判定に至った理由の説明）」、「引用（エビデンス）」、「参照元」が表示されます。これにより、記録の欠落によって「判断不可」となったのか、あるいは「未対応」となったのか、その理由と根拠を明確に確認できます。

できない場合の確認手順と人が判断する範囲：

- 確認手順：アセスメント実行後、担当者は「判断不可」や「未対応」と判定された項目について、出力された「コメント」や「引用（エビデンス）」を確認します。
- 人が判断する範囲：「一次評価をAIに、最終判断を人間に」という分業モデルに基づき、AIが「判断不可」や「未対応」とした項目について、人間が目視レビューを行い、最終的な判断を下します。

### Q: 「社内基準への準拠」で、正当な例外を不適合にすることが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not explicitly discuss legitimate exceptions being classified as nonconformities. Item filters, result options, and human review can be combined to address the issue.

Prevention: Item filters automatically mark specified items Not applicable based on input-flow answers. Add Not applicable and Unable to determine options with specific criteria to prevent forced nonconformity decisions when information is insufficient.

Display: Results include comments explaining decisions and evidence excerpts, allowing reviewers to assess whether an exception is legitimate.

Human decisions: AskDona recommends initial AI assessment followed by human final decisions. Reviewers focus on Unable to determine, Not implemented/nonconforming, and Review required items.

**回答（日本語）**

ドキュメント内には「正当な例外を不適合にする」という表現自体に直接言及した記述はありませんが、アセスメント機能（Batch Assessment）における「項目フィルタ」や「評価選択肢」の設定、および「人間による目視レビュー（分業モデル）」の仕組みを組み合わせることで、この課題に対処する方法が説明されています。

検出・抑制・表示の方法：

- 抑制：アセスメント作成時の「項目フィルタ」機能により、入力フローの回答に基づいて特定の評価項目を自動的に「対象外」として除外できます。また、「評価選択肢」の設定で「対象外」や「判断不可」を設け、その基準（LLMへの指示）を具体的に記述することで、情報不足時にAIが無理な不適合判定を出すことを防ぎます。
- 表示・検出：アセスメントの実行結果画面において、判定結果だけでなく、判定理由を説明する「コメント」や、判定の根拠となった情報源からの「引用（エビデンス）」が表示されるため、正当な例外であるかどうかの根拠を確認できます。

できない場合の確認手順と人が判断する範囲：

- AskDonaは「一次評価をAIに、最終判断を人間に」という分業モデルを推奨しています。
- 人（担当者）が判断する範囲は、AIが「判断不可」「未対応（不適合）」「要確認」などと判定した項目であり、これらに集中して目視レビュー（最終判断）を行う手順が示されています。

### Q: 「基準改訂の影響確認」で、表現変更と実質変更を混同することが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not directly describe a feature for detecting, preventing, or displaying confusion between wording changes and substantive changes in revised standards. General Batch Assessment functions can be applied: AI outputs Result, Comment, Evidence excerpt, and Source; people review the comments and evidence and make final decisions. Refining prompts and result-option descriptions can improve accuracy and reduce this confusion.

**回答（日本語）**

ドキュメントには「基準改訂の影響確認」において「表現変更と実質変更を混同する」ことに対する直接的な検出・抑制・表示機能についての言及はありません。しかし、Batch Assessmentの一般的な機能や運用モデルを意訳・応用することで、この課題に対処する方法を説明できます。具体的には、AIが「判定結果」「コメント」「引用（エビデンス）」「参照元」を出力し、担当者が「コメント」や「引用（エビデンス）」を目視でレビューして最終判断を行うという「一次評価をAIに、最終判断を人間に」という分業モデルを適用します。また、プロンプトや評価選択肢の記述を調整することで判定精度を向上させ、混同を抑制することが可能です。

### Q: 「監査前の自己点検」で、文書確認だけで監査完了と扱うことが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not directly discuss treating document review alone as audit completion during a pre-audit self-check. Batch Assessment specifications and use cases can be interpreted to address the question.

Prevention: Include Unable to determine so missing information does not force a conclusion, and use strict prompts requiring Not implemented whenever any criterion is unmet.

Display: Results screens and reports show comments, evidence, and source filenames alongside results, making the basis explicit.

Verification and decisions: AI performs the initial assessment; people manually review Unable to determine or Not implemented items and make final decisions.

**回答（日本語）**

「監査前の自己点検」において「文書確認だけで監査完了と扱う」という特定の状況に対する直接的な言及はありませんが、Batch Assessment機能の仕様やユースケースを意訳することで回答が可能です。

検出・抑制・表示について：

- 抑制：評価選択肢の設定で「判断不可」を含めることで、情報不足の場合にAIが無理な結論を出すことを防ぎます。また、プロンプトで「少しでも基準を満たさない場合は未対応と判定すること」と厳格な評価を指示することで、安易な判定を抑制できます。
- 表示：実行結果画面や出力レポートにおいて、判定結果だけでなく「コメント（判定理由）」、「引用（エビデンス）」、「参照元（ファイル名）」を表示し、確認の根拠を明示します。

できない場合の確認手順と人が判断する範囲について：

- 確認手順と人が判断する範囲：「一次評価をAIに、最終判断を人間に」という分業モデルに基づき、AIが判定した結果のうち「判断不可」や「未対応」となった項目について、担当者が目視でレビュー（最終判断）を行います。

### Q: 「契約条件の一次確認」で、AIの一次判定を法的結論とすることが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not directly describe automatic detection or prevention of treating an initial AI contract assessment as a legal conclusion. It does describe safeguards against incorrect or forced assessments and a human final-decision workflow.

Prevention and display: Include Unable to determine to avoid forced conclusions from insufficient information. Results show Result, Comment, Evidence excerpt, and Source.

Verification: Review the AI result, reasoning, supporting excerpt, and source file in the results screen or Excel report.

Human decisions: AI performs the initial assessment. In the contract-review use case, legal staff focus manual review on Clause absent and Review required items and make the final legal judgment.

**回答（日本語）**

ドキュメントには「契約条件の一次確認」や「AIの一次判定を法的結論とする」ことに対する直接的な自動検出・抑制機能についての言及はありませんが、契約書レビューやアセスメント業務において、AIの誤判定や無理な結論を防ぎ、人間が最終判断を行うための機能や運用方法が記載されています。

検出・抑制・表示方法：

- 抑制：アセスメントの新規作成時に、評価選択肢として「判断不可」を含めることで、情報不足の場合にLLMが無理な結論を出すことを防ぐ（抑制する）ことができます。
- 表示：アセスメントの実行結果画面において、各評価項目に対して「判定結果」「コメント（判定理由の説明）」「引用（エビデンス）」「参照元」が表示されます。

確認手順と人が判断する範囲：

- 確認手順：利用者はアセスメント実行後に結果画面やExcelレポートから、AIの判定結果、コメント、および判定の根拠となった引用（エビデンス）や参照元ファイルを確認します。
- 人が判断する範囲：AskDonaは「一次評価をAIに、最終判断を人間に」という分業モデルを基本としています。契約書レビューのユースケースでは、法務担当者がAIの判定した「条項なし」や「要確認」の項目に集中して目視レビューを行い、最終的な判断（法的結論）を下します。

### Q: 「医療・製薬の文書レビュー」で、製品の適合性をAIだけで確定することが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not explicitly mention medical/pharmaceutical document review or product conformity. Its controls on automatic assessment, output fields, and division of AI and human responsibilities can be applied. Unable to determine helps prevent forced conclusions; Result, Comment, Evidence excerpt, and Source are displayed. The recommended model assigns the initial assessment to AI and final decisions to people, who manually review only Unable to determine, Not implemented, or Review required items.

**回答（日本語）**

ドキュメントには「医療・製薬の文書レビュー」や「製品の適合性」という具体的な言葉は直接言及されていませんが、Batch Assessment機能におけるAIによる自動判定の抑制・表示方法、および人間との分業モデル（人が判断する範囲）について意訳することで回答が可能です。

具体的には、AIが無理な結論を出すことを防ぐ（抑制する）ために評価選択肢に「判断不可」を含めることができ、判定結果、コメント、引用（エビデンス）、参照元を表示します。また、AIにすべてを任せるのではなく「一次評価をAIに、最終判断を人間に」という分業モデルを推奨しており、人間は「判断不可」や「未対応」「要確認」となった項目だけを目視レビュー（確認）します。

## Compared with other approaches (他の方法との比較)

### Q: 「セキュリティ質問票への回答」には、過去回答のコピーと文書を使うAIをどう使い分けるとよいですか？

**Answer (English)**

The documentation does not directly compare copying past answers with AskDona. Its comparison of manual security assessments with Batch Assessment can be interpreted to answer the question. Instead of manual work, including copying prior answers, an AI agent assesses items and outputs comments and evidence alongside results. This improves consistency across reviewers, while recurring runs track operational changes. Suitable uses include regular checks involving hundreds or thousands of items and repeated use of a template. Another approach is preferable for a short checklist or tasks resolved through individual RAG chat questions.

**回答（日本語）**

提供されたドキュメントには、「過去回答のコピー」という表現を用いた直接的な比較は記載されていません。しかし、手作業によるアセスメント（セキュリティ評価など）とAskDonaの「Batch Assessment」を比較した際の違いや、向く条件・不要な条件（別の方法がよい条件）については記載されており、これらを意訳することで回答を構成できます。

手作業（過去回答のコピーを含む）と比べた場合、AskDona（Batch Assessment）を使うことで、AIエージェントが自動で判定を行い、判定結果だけでなくコメントや引用（エビデンス）が出力されるようになります。これにより、担当者ごとの判定のばらつきを減らして一貫性を確保でき、定期的な実施によって業務の変化を定点観測できるようになります。

また、向く条件として「数百〜数千の評価項目を定期的にチェックする業務」や「同じテンプレートを何度も使い回す場合」が挙げられており、別の方法がよい条件として「数項目程度の簡単なチェックリストだけで十分な場合」や「RAGチャットで個別に質問すれば解決する場合」が示されています。

### Q: 「車両仕様の一次判定」には、技術担当者の目視判定と文書を使うAIをどう使い分けるとよいですか？

**Answer (English)**

The documentation does not directly compare technical staff's manual review with AskDona for initial vehicle-specification assessment. General Batch Assessment guidance describes initial AI assessment followed by human final decisions, reduced effort, improved consistency, and suitability for recurring checks of hundreds of items. It also says the feature is unnecessary for a few simple checks or individually answerable questions. Applied to vehicle specifications, this suggests AI handling the initial assessment while people make final decisions and review undetermined items; suitability for many items requiring consistency; and simpler alternatives for small checklists or individual questions.

**回答（日本語）**

提供されたドキュメントには、「車両仕様の一次判定」における技術担当者の目視判定とAskDona（Batch Assessment）の具体的な使い分けや、向く条件・別の方法がよい条件について、文字通りに直接言及している記述はありません。しかし、Batch Assessmentの一般的な特徴として、「一次評価をAIに、最終判断を人間に」という分業モデルにより省力化・効率化できること、担当者ごとの判定のばらつきを減らし評価の一貫性を確保できること、数百件規模の評価項目を定期的にチェックする業務に向いていること、数項目程度の簡単なチェックリストや個別の質問で解決する場合は不要であることが示されています。これらを「車両仕様の一次判定」に意訳して適用することで、目視判定との使い分け（一次判定をAIが行い、人間が最終判断や判断不可の項目をレビューする分業モデル）、向く条件（項目数が多く、評価の一貫性を確保したい場合）、別の方法がよい条件（数項目程度の簡単なチェックや個別質問で済む場合）を示すことができます。

### Q: 「設計レビューの準備」には、設計者による自己点検と文書を使うAIをどう使い分けるとよいですか？

**Answer (English)**

The documentation does not directly compare approaches to design-review preparation, but its general comparison of manual self-checks and Batch Assessment can be applied. Initial AI assessment followed by human final decisions reduces effort and improves consistency. Suitable uses include recurring checks of hundreds or thousands of items and a need for consistent assessment. The feature is unnecessary for a simple checklist with a few items or questions that RAG chat can resolve individually.

**回答（日本語）**

ドキュメントには「設計レビューの準備」という特定の文脈における比較は直接言及されていませんが、一般的な「自己点検」と「Batch Assessment」の比較、および向く条件・不要な条件についての記述があります。これらを「設計レビューの準備」に意訳・適用することで回答が可能です。手作業の自己点検と比べて「一次評価をAIに、最終判断を人間に」という分業モデルにより省力化・効率化でき、判定のばらつきを減らし一貫性を確保できること、向く条件（数百〜数千の評価項目を定期的にチェックする、一貫性を確保したいなど）と不要な条件（数項目程度の簡単なチェックリストで十分、RAGチャットで個別に質問すれば解決するなど）が示されています。

### Q: 「複数仕様案の比較」には、比較表の手作成と文書を使うAIをどう使い分けるとよいですか？

**Answer (English)**

The documentation does not directly compare manual and AI-based preparation for comparing multiple specification proposals. Its Batch Assessment overview and use cases can be applied to answer the question. Manual reading and status entry can take several days. Initial AI assessment followed by human final decisions substantially reduces effort and improves consistency across reviewers. The feature suits recurring checks of hundreds or thousands of items, including annual or quarterly work, and a need for consistent assessment. It is unnecessary when a short checklist or individual RAG chat questions are sufficient.

**回答（日本語）**

ドキュメントには「複数仕様案の比較」という特定のユースケースにおける手作成とAIの使い分けについて直接的な言及はありませんが、ドキュメントに記載されている「Batch Assessment（バッチアセスメント）」の概要やユースケースを意訳して適用することで回答が可能です。

同じ資料・同じ課題で何が変わるか：

手作業（手作成）では担当者がドキュメントを読み込んで対応状況を埋めるのに多大な工数（数日など）がかかりますが、AskDona（Batch Assessment）を使うことで「一次評価をAIに、最終判断を人間に」という分業モデルになり、工数を大幅に削減し省力化・効率化できます。また、担当者ごとの判定のばらつきを減らし、評価の一貫性を確保できます。

向く条件：

数百〜数千の評価項目を定期的にチェックする業務や、毎年・毎四半期ごとに手作業でチェックしている場合、判定のばらつきを減らし一貫性を確保したい場合に向いています。

別の方法（手作成やRAGチャット）がよい条件：

数項目程度の簡単なチェックリストだけで十分な場合や、RAGチャットで個別に質問すれば解決する場合には、Batch Assessmentは不要（別の方法がよい）とされています。

### Q: 「品質文書の整合確認」には、品質担当の目視監査と文書を使うAIをどう使い分けるとよいですか？

**Answer (English)**

The documentation does not explicitly name quality-document consistency checking. Its comparison of Batch Assessment with manual audits can be applied to this task.

Instead of manually reading documents and entering status, AI performs an initial assessment and exports Excel results with comments and evidence. People focus review only on Unable to determine or Not implemented items requiring confirmation, reducing effort and improving consistency.

Suitable uses include recurring annual or quarterly checks of hundreds or thousands of items, a need for consistent decisions, and checking many items against one document. Alternatives are preferable for short checklists, individually answerable RAG chat questions, or cases where the database lacks necessary information and AI must return Unable to determine.

**回答（日本語）**

ドキュメントには「品質文書の整合確認」という具体的な業務名での直接的な言及はありませんが、AskDonaの「Batch Assessment」機能と「目視監査（手作業）」を比較した際の変化、向く条件、別の方法がよい条件について明確な記述があり、これらを品質文書の整合確認に当てはめることで回答が可能です。

同じ資料・同じ課題で何が変わるか：

手作業でドキュメントを読み込んで対応状況を埋める目視監査と比べ、AskDonaを使うことで「一次評価をAIに、最終判断を人間に」という分業モデルに変わります。AIエージェントが自動判定を行い、コメントやエビデンス（引用）付きでExcel出力するため、担当者は「判断不可」や「未対応（要確認）」の項目だけに集中して目視レビューできるようになり、省力化・効率化が図れます。また、担当者ごとの判定のばらつきを減らし、評価の一貫性を確保できます。

向く条件：

・数百〜数千の評価項目を定期的にチェックする業務（毎年または毎四半期など）である場合。

・担当者ごとの判定のばらつきを減らし、評価の一貫性を確保したい場合。

・「1ドキュメント × 多項目チェック」のように、1つのドキュメントに対して多くの項目をチェックする場合。

別の方法がよい条件：

・数項目程度の簡単なチェックリストだけで十分な場合。

・RAGチャットで個別に質問すれば解決する場合。

・判定に必要な情報がデータベースに不足しており、AIが「判断不可」と判定せざるを得ない場合。

### Q: 「規格とのギャップ整理」には、専門家による全件読解と文書を使うAIをどう使い分けるとよいですか？

**Answer (English)**

The documentation does not explicitly name gap analysis against standards. Comparisons of manual expert review with Batch Assessment for similar risk and compliance work can be applied. Manual document reading and status entry can take several days per system. AI instead assesses items and exports Excel results with comments and evidence, while people manually review only Unable to determine or Not implemented results and make final decisions. This reduces effort and improves consistency. It suits recurring annual or quarterly checks of hundreds or thousands of items and a need for consistent decisions. Manual work or RAG chat is preferable for short checklists or questions answerable individually.

**回答（日本語）**

ドキュメントには「規格とのギャップ整理」という言葉そのものへの言及はありませんが、類似するアセスメント業務（システムリスクアセスメントやコンプライアンスチェックなど）において、専門家（担当者）による手作業（全件読解）とAskDonaのBatch Assessment機能を比較した際の違い、向く条件、別の方法がよい条件について言及されています。これらを意訳して適用することで回答が可能です。

同じ資料・同じ課題で何が変わるか：

- 専門家（担当者）が手作業でドキュメントを読み込んで対応状況を埋める場合、1システムあたり数日かかりますが、Batch Assessmentを使用すると、AIエージェントが自動判定し、コメント・エビデンス付きでExcel出力します。
- これにより、「一次評価をAIに、最終判断を人間に」という分業モデルが実現し、担当者は「判断不可」や「未対応」の項目だけを目視レビュー（最終判断）すればよくなるため、省力化・効率化されます。
- また、担当者ごとの判定のばらつきを減らし、評価の一貫性を確保できます。

向く条件：

- 数百〜数千の評価項目を定期的にチェックする業務（毎年または毎四半期ごとに手作業でチェックしている場合）。
- 担当者ごとの判定のばらつきを減らし、評価の一貫性を確保したい場合。

別の方法（手作業やRAGチャットなど）がよい条件：

- 数項目程度の簡単なチェックリストだけで十分な場合。
- RAGチャットで個別に質問すれば解決する場合。

### Q: 「基準改訂の影響確認」には、改訂対照表の手作成と文書を使うAIをどう使い分けるとよいですか？

**Answer (English)**

The documentation does not explicitly mention checking the impact of revised standards or revision comparison tables. Its general comparison of manual checks and Batch Assessment can be applied. Initial AI assessment followed by human final decisions reduces effort and improves consistency. Suitable uses include recurring checks of hundreds or thousands of items. Alternatives are preferable when a simple checklist with a few items is sufficient or individual RAG chat questions can resolve the task.

**回答（日本語）**

ドキュメント内には「基準改訂の影響確認」や「改訂対照表」という言葉自体は直接言及されていません。しかし、手作業でのチェックとAskDona（Batch Assessment）の比較、向く条件、別の方法がよい条件については、一般的なアセスメント業務の観点からドキュメントに記載されており、これらを意訳・適用することで回答が可能です。

具体的には、手作業と比べた変化として「一次評価をAIに、最終判断を人間に」という分業モデルによる省力化・効率化や、判定のばらつきを減らし一貫性を確保できる点が挙げられます。また、向く条件として「数百〜数千の評価項目を定期的にチェックする業務」などが示されており、別の方法がよい条件として「数項目程度の簡単なチェックリストだけで十分な場合」や「RAGチャットで個別に質問すれば解決する場合」が示されています。

### Q: 「監査前の自己点検」には、監査担当による全件確認と文書を使うAIをどう使い分けるとよいですか？

**Answer (English)**

The documentation compares manual checking of all items with Batch Assessment for self-checks and assessments. Applied to pre-audit self-checks, it explains substantial effort reduction through initial AI assessment followed by human final decisions. It suits recurring checks of hundreds of items and a need for consistent assessment, but is unnecessary when a simple checklist with a few items is sufficient.

**回答（日本語）**

ドキュメントにおいて、「自己点検」や「アセスメント」業務を対象に、担当者の手作業（全件確認に相当）とAI（Batch Assessment）を比較した際の変化、向く条件、不要な条件（別の方法がよい条件）について言及されています。これらを「監査前の自己点検」に適用して意訳することで、質問に対する回答が得られます。具体的には、手作業からAIによる一次評価に置き換えることで工数を大幅に削減し、「一次評価をAIに、最終判断を人間に」という分業モデルに移行できること、また数百件規模の定期的なチェックや評価の一貫性確保に向く一方で、数項目程度の簡単なチェックリストで十分な場合は不要（別の方法がよい）であると示されています。
