# Interpreted FAQ: Access control, usage monitoring and organization-wide answer policy

> Interpreted answers on confidentiality levels, departmental and role-based access, transfers and departures, usage statistics, audit logs and organization-wide response settings in AskDona (SaaS).

- 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-access-and-governance.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: 部署ごとに見られる資料が違う場合、AIの回答も分けられますか？

**Answer (English)**

No feature is documented for automatically configuring access by directly importing departmental documents and a permissions matrix. The documentation does explicitly describe administrators manually creating database-scoped custom roles, granting access to selected databases, and assigning them to users to control departmental access. The final tasks are creating the custom role in Access Control, selecting the database, and assigning the role. A documented example grants access only to a Contracts database.

**回答（日本語）**

ドキュメントには「部署別の文書と権限表」を直接読み込んで自動的に閲覧権限を設定する機能についての言及はありません。しかし、管理者が手動で「データベース単位の権限」を設定し、カスタムロールを作成して特定のデータベースへのアクセスを許可し、それをユーザーに割り当てることで「部署別の閲覧権限」を管理・制御する方法については明確に言及されています。利用者が最終的に行う作業は、アクセス制御画面でのカスタムロールの作成、データベースの選択、ユーザーへのロール割り当てです。また、手動設定の例として「契約書」データベースのみにアクセスを許可するロールの例が記載されています。

### Q: 異動や退職のたびに、社内AIの権限を漏れなく変えるには？

**Answer (English)**

User Management lists all organization users and supports changing roles, switching accounts between Active and Inactive, and deleting users. This can be interpreted as changing roles after an internal transfer and deactivating or deleting accounts when someone leaves. The management dialog includes inputs such as name, email address, account status, and roles. Concrete input/output examples are not explicitly provided.

**回答（日本語）**

ドキュメントには「ユーザー管理」タブにおいて、組織に所属するすべてのユーザーを一覧で管理し、ロールの割り当て変更やアカウントステータスの切り替え（アクティブ/非アクティブ）、ユーザーの削除ができることが記載されています。これらを意訳することで、異動時には「ロール」の変更、退職時には「アカウントステータス」の非アクティブ化や「ユーザー削除」を行うという具体的な作業や、管理ダイアログでの入力項目（名前、メールアドレス、アカウントステータス、ロールなど）を説明できます。ただし、具体的な「入力例と出力例」そのものは文字通りには記載されていません。

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

### Q: 「文書の機密区分」でAIを使いたいのですが、「一部は限定メンバーだけが見られる」という条件でも使えますか？

**Answer (English)**

The documentation does not use the exact phrase “some information is visible only to selected members,” but describes clearance levels and database-scoped permissions for restricting access to particular documents or databases.

Conditions: Set user clearance and document confidentiality levels appropriately, or create database-scoped custom roles and assign them to the selected members.

Configuration

- Set user clearance in User Management.
- Set each file's clearance/confidentiality level in RAG metadata editing.
- For database restrictions, create custom roles scoped to the required database and assign them to users.
- Enable Apply clearance level when sharing chat sessions.

Limitations: Default system roles such as Owner, Admin, and Member do not provide organization-specific granular database restrictions; custom roles are needed. Organization-wide features such as GPT, administration, Batch Assessment, and organization settings cannot be restricted by database.

**回答（日本語）**

ドキュメントには「一部は限定メンバーだけが見られる」という表現そのものは直接記載されていませんが、AskDonaの「クリアランスレベル」機能や「データベース単位の権限」機能を用いることで、特定のユーザー（限定メンバー）だけが特定のドキュメントやデータベースにアクセスできるように制御できることが説明されています。

具体的には、以下の通り意訳することで回答を構成できます。

対応条件：

- ユーザーの「クリアランスレベル」と、ドキュメントの「クリアランスレベル」（機密レベル）を適切に設定すること。
- または、特定のデータベースだけに限定して権限を付与した「カスタムロール」を作成し、それを限定メンバーに割り当てること。

追加設定：

- ユーザー管理画面で、各ユーザーの「クリアランスレベル」を設定する。
- RAGデータベースのメタデータ編集画面で、各ファイルの「クリアランスレベル」を設定する。
- データベース単位でアクセスを制限したい場合は、「ロール権限」で特定のデータベースだけに限定して権限を付与したカスタムロールを作成し、ユーザーに割り当てる。
- チャットを共有する際は、共有ダイアログで「クリアランスレベルを適用」をONにする。

対応できないケース：

- システムロール（Owner、Admin、Memberなど）をそのまま使用する場合、組織固有の細かい権限設定（データベース単位の制限など）に対応できないため、カスタムロールを作成する必要がある。
- データベース単位の指定ができない機能（GPT、管理、Batch Assessment、組織など）は、組織全体が対象となるため、データベース単位でのアクセス制限は適用できない。

### Q: 「部署別の閲覧権限」でAIを使いたいのですが、「複数部署を兼務する人がいる」という条件でも使えますか？

**Answer (English)**

The documentation does not explicitly discuss users working across multiple departments. Multiple-role combination modes and database-scoped custom roles can be combined to address this. Assign the user a custom role for each department's database and set Role Combination Mode to OR in the user management dialog, allowing access to all relevant departmental databases. Database-scoped role permissions alone cannot control departmental access to specific documents or folders within the same database.

**回答（日本語）**

ドキュメントには「複数部署を兼務する」という直接的な表現はありませんが、複数ロールを割り当てる場合の挙動（ロール結合モード）や、特定のデータベースに限定した権限（カスタムロール）についての記述があり、これらを組み合わせることで回答が可能です。複数部署を兼務するユーザーに対しては、それぞれの部署に対応するカスタムロール（特定のデータベースに限定した権限）を複数割り当てることで対応できます。追加設定として、ユーザー管理ダイアログで「ロール結合モード」を「OR（いずれかのロール）」に設定することで、兼務するすべての部署のデータベースを閲覧できるようになります。対応できないケースとして、データベース単位ではなく、同一データベース内の特定のドキュメントやフォルダ単位での部署別閲覧権限の制御は、ロール権限（データベース単位の権限）だけでは対応できません。

### Q: 「利用状況の把握」でAIを使いたいのですが、「個人の質問内容を過剰に見たくない」という条件でも使えますか？

**Answer (English)**

The documentation does not directly address avoiding excessive inspection of individuals' questions. Insights, permissions, organization restrictions, and privacy guidance can be combined to explain the options.

Usage without conversation content

- The Statistics tab in RAG and GPT Insights aggregates answered questions, sessions, average questions per session, total user-days, and other metrics for a selected period without displaying individual conversations.
- The home-page Activity card charts question counts for the last 28 days without showing question content.

Configuration and policies

- Default RAG Insights Observer and GPT Insights Observer roles can view analytics, dashboards, and chat histories. Create and assign a custom role restricting conversation-history access for usage-monitoring staff.
- Organization restrictions can disable Show dashboard company-wide.
- Define viewing and use rules consistent with privacy and information-management policies because Insights can include individual conversations.

Limitations

- Owner has full access and can view individual conversations and email addresses in Chat History.
- Users allowed to view histories can download Excel, CSV, or JSON containing questions and AI answers, creating risks of disclosure or excessive access.
- Anonymous embedded-chatbot questions are not linked to email addresses or similar personal details, but conversation content still appears in history and cannot be completely hidden while analyzing those questions.

**回答（日本語）**

ドキュメントには「個人の質問内容を過剰に見たくない」という条件そのものに対する直接的な言及はありませんが、インサイト機能（統計情報とチャット履歴）の仕様、ロール権限、組織管理による制限、プライバシーに関する留意事項などの情報が記載されており、これらを組み合わせることで、対応条件、追加設定、対応できないケースを説明できます。

対応条件（個人の質問内容を見ずに利用状況を把握する方法）

- 「統計情報」タブの利用：RAGチャットやGPTチャットのインサイト機能には「統計情報」タブがあり、指定期間における利用実績（回答済み質問数、総セッション数、平均質問数/セッション、合計ユーザー日数など）を集計・可視化したダッシュボードが表示されます。ここでは個人の質問内容（会話内容）は表示されないため、個人の質問内容を見ずに利用状況を把握できます。
- 「アクティビティ」カードの利用：トップページには「アクティビティ」カードがあり、直近28日間の質問数をグラフで確認できます。ここでも個人の質問内容は表示されません。

追加設定（質問内容の閲覧を制限するための設定や運用）

- カスタムロールの作成と割り当て：デフォルトのシステムロール（RAG Insights ObserverやGPT Insights Observerなど）はインサイト（分析・ダッシュボード・チャット履歴など）を閲覧できます。個人の質問内容を過剰に見たくない場合は、チャット履歴（会話内容）の閲覧を制限した「カスタムロール」を新規作成し、利用状況を把握する担当者に割り当てる必要があります。
- 組織管理（キルスイッチ）の設定：組織管理で「インサイト（分析ダッシュボード）の閲覧を全社で止めたい」場合は「ダッシュボードを表示」を制限できます。
- 運用ポリシーの策定：インサイトで閲覧できる情報は、組織内の利用状況・個別ユーザーの会話内容を含むため、プライバシーや情報管理ポリシーに従い、閲覧・利用を行う運用ルールを定める必要があります。

対応できないケース（どうしても見えてしまう部分や、制限されること）

- 管理者（Ownerロールなど）による閲覧：最上位ロールである「Owner」は、すべての機能・設定にフルアクセスできるため、インサイトの「チャット履歴」タブから個別ユーザーの会話内容（質問内容）やメールアドレスを閲覧できてしまいます。
- チャット履歴のダウンロード：チャット履歴の閲覧権限があるユーザーは、チャット履歴データをExcel、CSV、JSON形式でダウンロードできます。ダウンロードしたファイルにはユーザーの質問とAIの応答が一覧で含まれるため、これが流出したり過剰に閲覧されたりするリスクがあります。
- 埋め込み型チャットボットの質問分析：埋め込み型チャットボットで匿名ユーザーが行う質問を分析する場合、メールアドレスなどの個人情報は紐づかないが、質問内容（会話内容）自体はチャット履歴に表示されるため、質問内容そのものを完全に見えなくすることはできません。

### Q: 「設定変更の追跡」でAIを使いたいのですが、「複数の管理者がいる」という条件でも使えますか？

**Answer (English)**

AskDona does not have an AI feature specifically named tracking setting changes, but Audit Logs record who did what and when, including actions by individual administrators in a multi-administrator organization. Access requires a suitable role, such as Owner. Users can filter by date range, event type, or feature and export Excel logs for management. Custom roles without audit-log permissions, such as a RAG-editor-only role, cannot review or export the history.

**回答（日本語）**

AskDonaには「設定変更の追跡」という直接のAI機能はありませんが、管理者が行った操作の履歴は「監査ログ」タブから「誰がいつ何をしたか」を追跡できます。複数の管理者がいる場合でも、監査ログから特定のユーザーの操作を特定することが可能です。対応条件として、監査ログにアクセスできる権限（Ownerロールなど）が必要です。追加設定として、監査ログタブで期間やイベント種別、機能などで絞り込みを行い、Excel形式でエクスポートして管理することができます。対応できないケースとして、監査ログへのアクセス権限がないカスタムロール（例：RAG編集専用など）のユーザーは、履歴の確認やエクスポートができません。

### Q: 「組織の回答方針」でAIを使いたいのですが、「部署ごとに用途が異なる」という条件でも使えますか？

**Answer (English)**

The documentation does not directly discuss different departmental uses. Department-identification prompt rules, organization/personal settings, and metadata filters can be combined.

Supported approaches

- Add department-identification rules and a contact-routing table to the system prompt so AI infers the relevant department and answers accordingly.
- Set shared rules in the Organization tab and extend them for departmental or individual needs through the Personal System Prompt.
- Classify documents with departmental metadata and enable filters to narrow chat searches.

Configuration

- Add mappings such as payroll, labor matters, benefits, and attendance to Human Resources.
- Enter job-specific personal prompts for users or departmental representatives.
- Enable metadata filtering, select filter keys, and add department-name metadata to RAG files.

Limitations

- Organization settings apply uniformly to all users. Without personal prompts or routing rules, they cannot provide fully independent or contradictory departmental policies or personalities.
- Personal instructions that conflict with organization rules may behave unexpectedly. Use Check conflicts before saving.

**回答（日本語）**

ドキュメントには「部署ごとに用途が異なる」という表現に直接言及した記述はありませんが、システムプロンプト（システム環境設定）における部署判定ルールの記述、組織全体と個人用の設定タブの使い分け、およびメタデータフィルターによる絞り込み機能に関する記述を組み合わせることで、対応条件、追加設定、対応できないケースを説明することができます。

対応条件（どのように対応できるか）

- プロンプトによる自動判定：システム環境設定（システムプロンプト）に「部署判定の補助ルール」や「問い合わせ窓口 対応表」を記述することで、AIが質問内容から自動的に部署を判定し、それぞれの用途や窓口に応じた回答を生成させることができます。
- 個人用システムプロンプトによる個別拡張：組織共通のルールを「組織」タブで定義しつつ、部署やユーザーごとの個別の用途については「個人」タブの「個人用システムプロンプト」を使って個別に指示を追加・拡張（カスタマイズ）することができます。
- メタデータフィルターによる検索範囲の制限：メタデータフィルター設定を有効にし、部署ごとにドキュメントをメタデータ（カテゴリーなど）で分類しておくことで、チャット時に部署ごとの検索対象を絞り込むことができます。

追加設定

- システム環境設定へのルール追加：システム環境設定に、部署ごとの判定ルールや対応表（例：「給与・労務・福利厚生・勤怠 → 人事部」など）を記述します。
- 個人用システムプロンプトの設定：各ユーザー（または部署の担当者）の「個人」タブで、それぞれの業務に特化したシステムプロンプトを入力します。
- メタデータフィルターの有効化とメタデータ付与：管理画面で「メタデータフィルタリングを有効にする」をONにし、フィルターとして使用するキーを設定します。また、RAGデータベースに登録するファイルに部署名などのメタデータを付与します。

対応できないケース

- 組織設定のみでの完全な個別制御：「組織」タブの設定（組織システムプロンプトやAIパーソナリティ設定）は組織内のすべてのユーザーに一律で共通適用されるため、個人設定（個人用システムプロンプト）やプロンプト内の自動判定ルールを使用せずに、組織設定だけで部署ごとに完全に独立した（あるいは互いに矛盾する）回答方針やパーソナリティを切り分けることはできません。
- 組織の指示と完全に矛盾する個別設定：個人用システムプロンプトで組織共通のルールと矛盾する指示を与えた場合、競合が発生して意図通りに動作しない可能性があります（保存前に「競合をチェック」で確認する必要があります）。

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

### Q: 「文書の機密区分」を始めるには、機密区分付き文書をどう準備し、どんな操作をすればよいですか？

**Answer (English)**

The documentation does not use the exact term document classification, but interpreting it as confidentiality level explains the workflow. Set the confidentiality level when uploading files, then process them. Users can filter the file list by confidentiality through customized views or apply RAG chat filters before asking questions. Upload, processing, and filtering are standard functions. Additional preparation may include removing file passwords, creating custom roles, and configuring clearance levels.

**回答（日本語）**

「文書の機密区分」という表現そのものはドキュメントに存在しませんが、これを「機密レベル」と意訳することで、準備・登録から結果の確認（利用）までの手順、および標準機能と追加対応の区別について回答することができます。具体的には、利用者はファイルアップロード時に「機密レベル」を設定して登録し、ドキュメント処理を実行します。結果の確認や利用においては、ファイル一覧のカスタマイズビューから機密レベル別に絞り込んで確認したり、RAGチャットのフィルター機能で絞り込んで質問したりできます。標準機能としてこれらのアップロード、処理、絞り込み機能が提供されていますが、追加対応（事前準備）として、パスワード保護されたファイルのパスワード解除や、必要に応じたカスタムロールの作成とクリアランスレベルの設定が必要となります。

### Q: 「異動・退職時の変更」を始めるには、利用者一覧と所属変更をどう準備し、どんな操作をすればよいですか？

**Answer (English)**

The documentation does not directly describe transfer/departure changes or preparing a user list with changed affiliations. User Management procedures cover adding and deleting users, changing roles or Active/Inactive status, and checking Effective Permissions. These can be applied to transfers and departures and verified in the user list or Effective Permissions dialog. Standard functions cover individual account changes and permission checks. Bulk CSV registration and changing Team/affiliation through operations not shown in the user dialog would require additional measures not described in the documentation.

**回答（日本語）**

ドキュメントには、「異動・退職時の変更」という表現や「利用者一覧と所属変更」の具体的な準備・操作手順そのものは直接記載されていません。しかし、アクセス制御の「ユーザー管理」機能において、ユーザーの追加・削除、ロールの割り当て変更、アカウントステータス（アクティブ/非アクティブ）の切り替え、有効な権限の確認などの操作手順が記載されています。これらを意訳・応用することで、異動時（ロール変更やステータス変更）や退職時（削除や非アクティブ化）の変更手順、および結果の確認方法（ユーザー一覧や有効な権限ダイアログでの確認）を説明することが可能です。また、標準機能で対応できる範囲（個別の追加・削除・設定変更・権限確認）と、ドキュメントに記載のない追加対応が必要な範囲（CSV等による一括登録や、ユーザー管理ダイアログに記載のない「チーム（所属）」の変更操作）を区別して回答することができます。

### Q: 「組織の回答方針」を始めるには、社内の回答方針をどう準備し、どんな操作をすればよいですか？

**Answer (English)**

The documentation does not name a feature Organizational Response Policy, but RAG System Settings, custom AI Personality Settings, and GPT's Organization System Prompt serve this purpose.

Workflow

- Prepare up to 2,000 characters describing tone, format, templates, response rules, and constraints.
- An administrator or Owner opens Settings > Organization, enters the text in the appropriate setting, and clicks Save settings at the top right.
- Test the behavior in the RAG Preview or GPT Preview chat on the right.

Entering and saving these settings and testing in real-time previews are standard functions. Additional work includes designing policy prompts and templates, assigning and managing administrator/Owner permissions, and repeatedly testing and refining instructions. Because these are LLM instructions, adherence is not guaranteed to be 100%.

**回答（日本語）**

ドキュメント内には「組織の回答方針」という直接の機能名は存在しませんが、組織全体に適用する回答方針の設定として、RAGチャットの「システム環境設定」や「AIパーソナリティ設定（カスタム設定）」、およびGPTチャットの「組織システムプロンプト」が該当します。これらを「組織の回答方針」と意訳することで、準備・登録から結果の確認までの手順、および標準機能と追加対応の区別について回答を導き出すことができます。

準備・登録から結果確認までの手順：

- 準備：社内の回答方針（トーン、形式、テンプレート、回答ルール、制約事項など）をテキスト（最大2000文字）として準備します。
- 登録・操作：管理者またはOwner権限を持つユーザーが、左サイドバーの「設定」から「組織」タブを開き、「システム環境設定」や「AIパーソナリティ設定（カスタム設定）」、または「組織システムプロンプト」に準備したテキストを入力し、画面右上の「設定を保存」をクリックします。
- 結果の確認：設定画面の右側にある「RAGプレビュー」または「GPTプレビュー」の簡易チャット画面で、設定した回答方針が意図通りに動作するかテストして結果を確認します。

標準機能で済む範囲と追加対応の区別：

- 標準機能で済む範囲：「組織」タブでのシステム環境設定、AIパーソナリティ設定、組織システムプロンプトの入力・保存機能、およびリアルタイムで動作テストができる「RAGプレビュー」「GPTプレビュー」機能。
- 追加対応（利用者側の準備・運用負担）：自社のルールに合わせた具体的な回答方針（プロンプトやテンプレート）の文面作成・設計、設定変更を行うための管理者またはOwner権限の付与・管理、およびプレビューでのテストを繰り返しプロンプトの記述を調整する運用（LLMへの指示文であるため、100%の精度で反映されるとは限らず、調整が必要となるため）。

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

### Q: 「顧客情報を含む資料」で、必要のない個人情報まで使うことが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation explains how administrators can limit personal-information output through constraints in System Settings or AI Personality Settings. Example rules prohibit direct output of personal or confidential information, direct users to the source instead, and focus on general content rather than highlighting sensitive details. For verification, RAG chat provides original-document previews and reasoning through Show AskDona Thoughts. Batch Assessment provides Result, Comment, Evidence excerpt, and Source in the results screen and Excel report. Under the initial-AI-assessment, final-human-decision model, people manually review Unable to determine, Not implemented, or Review required items and make final decisions.

**回答（日本語）**

AskDonaにおいて、個人情報の出力を抑制・表示（制御）する方法として、管理者が「システム環境設定」や「AIパーソナリティ設定」のプロンプト（制約事項）を設計・設定する手順が示されています。具体的には、「個人情報が含まれる場合は直接出さない」、「機密性の高い情報や個人情報は、そのまま開示せず、参照元の確認を促す」、「個人情報・機密情報が含まれる場合は、直接の開示を禁止する」、「ドキュメントに個人情報や機密情報が含まれている場合、それを強調せず、一般的な内容に焦点を当てる」といったルールを設定することで、不要な個人情報の出力を抑制・表示制御します。また、AIだけで判断できない場合の確認手順として、RAGチャットでは「参照元プレビュー」で元のドキュメントを直接閲覧して確認したり、「Show AskDona Thoughts」でLLMの思考過程を確認したりする手順があります。Batch Assessmentでは、結果画面やExcelレポートの「判定結果」「コメント」「引用（エビデンス）」「参照元」を確認します。人が判断する範囲としては、「一次評価をAIに、最終判断を人間に」という分業モデルに基づき、AIが「判断不可」や「未対応」、「要確認」と判定した項目について、人間が目視でレビューし最終判断を行います。

### Q: 「部署別の閲覧権限」で、兼務設定で権限を広げすぎることが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not explicitly name settings for multi-department assignments. Database-scoped custom roles can be interpreted as a way to limit and manage access across departments and prevent unnecessary database access. There is no automatic warning for overly broad permissions. Before rollout, assign the new role to a test user, log in, and have a person verify that intended actions are possible and prohibited actions are not.

**回答（日本語）**

ドキュメントには「兼務設定」という言葉は直接使われていませんが、複数の部署やデータベースに対する閲覧権限を制限・管理する方法（データベース単位の権限付与）や、権限が広がりすぎていないかを人間が確認する手順について、意訳することで回答が可能です。

具体的には、特定のデータベースだけに限定して権限を付与したカスタムロールを作成・割り当てることで、不要なデータベースへのアクセスを抑制できます。

また、自動的に権限の広がりすぎを検出・警告する機能はないため、人が判断する範囲（確認手順）として、本格展開の前に新しいロールをテスト用のユーザーに割り当て、実際にログインして「できるべきことができ、できないはずのことができない」を人間が確認する必要があります。

### Q: 「異動・退職時の変更」で、変更前の権限で閲覧できることが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation does not directly describe automatic detection or prevention of continued access under old permissions after a transfer or departure. User Management guidance does explain manual administrator verification and action: open Effective Permissions to inspect a user's accessible features, then change account status or roles, or delete the user. These operations define the human-controlled review and response.

**回答（日本語）**

ドキュメントには「異動・退職時の変更」や「変更前の権限で閲覧できる」ことに対する自動的な検出・抑制・表示機能についての直接的な言及はありません。しかし、管理者が手動でユーザーの権限を確認・変更する手順や、人が判断して対応する範囲については、ユーザー管理機能の説明から意訳して回答することができます。具体的には、管理者が「ユーザー管理」タブから「有効な権限」ダイアログを開いてユーザーがアクセスできる機能を個別に確認する手順や、アカウントステータスの切り替え、ロールの変更、ユーザーの削除を手動で実行して権限を制御する手順が記載されています。

### Q: 「利用状況の把握」で、利用件数だけで効果を判断することが心配です。どう防いで確認できますか？

**Answer (English)**

No feature is explicitly documented for detecting or preventing judgments of effectiveness based only on usage counts. Usage and Insights provide additional perspectives beyond runs or questions. These can be interpreted to explain how credits consumed, user counts, failure logs, answer quality, and chat histories support broader evaluation. Human responsibilities include revising assessments, identifying dependence on particular individuals, interviewing users, detecting operational problems early, and evaluating answer quality.

**回答（日本語）**

AskDonaには「利用件数だけで効果を判断する」ことを直接的に検出・抑制する機能についての文字通りの言及はありませんが、件数（実行回数や質問数）以外の多角的な指標を表示する機能（「使用状況」や「インサイト」）が提供されています。これらを意訳することで、件数以外の指標（クレジット消費、ユーザー数、失敗ログ、回答品質、チャット履歴など）を表示して多角的な判断を支援する方法や、人間が確認・判断する範囲（アセスメントの見直し、属人化リスクの把握、ユーザーへのヒアリング、運用上の問題の早期発見、回答品質の評価など）を説明できます。

### Q: 「設定変更の追跡」で、変更の原因を追えないことが心配です。どう防いで確認できますか？

**Answer (English)**

The documentation explains that Audit Logs track who changed what and when, including adding or removing organization restrictions. It does not directly describe automatic detection, prevention, or display of the reason for a change, or a dedicated verification workflow. An answer can be inferred: identify the actor and action in the log, then have a person follow up with the individual who made the change.

**回答（日本語）**

ドキュメントにおいて、AskDonaの「監査ログ」機能により、組織の制限の追加・解除などの変更操作について「いつ」「誰が」「何をしたか」を追跡できることが説明されています。しかし、「変更の原因（理由）」そのものを自動で検出・抑制・表示する機能や、それができない場合の確認手順、人が判断する範囲についての直接的な言及はありません。監査ログから変更を行ったユーザーやアクションを特定し、人間がその変更者に直接確認するなどの判断を行う必要がある、と意訳することで回答が得られます。

### Q: 「組織の回答方針」で、設定だけで完全に制御できると思うことが心配です。どう防いで確認できますか？

**Answer (English)**

No feature is explicitly documented for detecting or preventing the assumption that settings completely control organizational response policy. Related guidance explains available controls and human verification.

Controls: System and AI personality settings influence tone, templates, specialist terminology, and responses when data is absent. Default intellectual-honesty behavior explicitly acknowledges missing or conflicting source information. Making clarification a top-priority prompt rule helps prevent guessing at ambiguous questions.

Verification: Inspect Show AskDona Thoughts, compare answers with originals in source previews, and submit good/bad feedback so administrators can review and improve quality through Insights. Determine whether failures originate in the question, the data, or the settings.

Human decisions: The operating model assigns initial assessment to AI and final review and judgment to people.

**回答（日本語）**

ドキュメントには「組織の回答方針を設定だけで完全に制御できると思うこと」に対する直接的な検出・抑制機能の明記はありませんが、システム環境設定やAIパーソナリティ設定による制御の仕組み、プロンプト設計による誤回答の抑制方法、および設定だけで制御しきれない場合の確認手順や人が判断する範囲について、関連する記述から意訳して回答を導き出すことができます。

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

- AskDonaでは、システム環境設定やAIパーソナリティ設定によって回答の形式やスタイル（口調、テンプレート、専門用語の頻度、データがないときの回答方法など）を制御できます。
- AIの「知的な誠実さ」として、ドキュメントに情報がない場合やソースに矛盾する情報が含まれている場合は、それを明確に認める振る舞いがデフォルトで適用されています。
- システムプロンプトの設計において、曖昧な質問に対して推測で答えず確認してから回答させる「聞き返し」のルールを最優先ルールに設定することで、誤った回答を抑制することができます。

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

- 確認手順：
- 回答の正確性を確認したい場合、回答の下部にある「Show AskDona Thoughts」をクリックしてLLMの思考過程を確認します。
- 回答の根拠となったドキュメント（参照元）のプレビューをブラウザ上で直接参照し、元のドキュメントと突き合わせて確認します。
- 回答の品質に問題がある場合は、グッド/バッドアイコンでフィードバックを送信し、管理者がインサイト機能で把握・改善します。
- うまくいかない原因が「質問側」「データ側」「設定側」のどこにあるかを切り分けて対応します。
- 人が判断する範囲：
- AIにすべてを任せるのではなく、「一次評価をAIに、最終判断を人間に」という分業モデルを基本とし、最終的な判断やレビューは人間（担当者）が行います。

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

### Q: 「役割別の機能制限」には、全員共通の権限と文書を使うAIをどう使い分けるとよいですか？

**Answer (English)**

Interpreting custom roles and database-scoped permissions as role-based restrictions, and system roles or organization-wide restrictions as shared permissions, provides the following comparison.

Changes

- Restrict a user to a particular database, such as Contracts, while hiding other databases as though they do not exist.
- Allow only specified actions, such as file upload or metadata editing, while restricting chat or organization settings.
- Limit users to a feature such as RAG chat without Insights or administration.

Suitable uses: External collaborators performing a limited task, such as database maintenance; granular information and action access by role; and organization-specific permissions.

Alternative: For actions nobody should perform, such as deleting files or using web search, organization restrictions are preferable because they disable the action for all users, including the Owner.

**回答（日本語）**

ドキュメント内には「役割別の機能制限」という言葉自体は直接使われていませんが、AskDonaの「アクセス制御」における「ロール権限（カスタムロール）」や「データベース単位の権限」を「役割別の機能制限」と意訳し、「組織管理（組織全体の制限）」や「システムロール」を「全員共通の権限」と意訳することで、質問に対する回答が得られます。

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

- データベース単位のアクセス制限：特定のユーザーに対して、特定のデータベース（例：「契約書」）のみアクセスを許可し、他のデータベースは存在しないものとして非表示にできます。
- アクション単位の操作制限：ユーザーごとに「ファイルアップロード」や「メタデータ編集」などの特定操作のみを許可し、チャットや組織設定などの不要な操作を制限できます。
- 特定機能に絞った利用：RAGチャットのみを利用させ、インサイトや管理機能は使わせないといった制御が可能になります。

向く条件：

- 外部協力者（業務委託など）に特定の作業（データベースの整備など）だけを依頼したい場合。
- ユーザーの役割（ロール）に応じて、アクセスできる情報（データベース）や実行できる操作を細かく分けたい場合。
- 組織固有の権限設定が必要な場合。

別の方法（組織全体の制限など）がよい条件：

- 「絶対に誰にもさせたくないこと」（例：全社でのファイル削除禁止、Web検索のオフなど）がある場合。この場合は、個別ロールではなく「組織の制限（組織管理）」を用いて、オーナーを含む全ユーザーに対して一括で無効化する方が適しています。