1分で完了！
無料お試し
PDFで見やすく
資料請求
ブログ情報共有・ナレッジ管理のお役立ちコラムAIAIが正しく答える社内ドキュメントの書き方｜誤答の5原因と7つのルール

AIが正しく答える社内ドキュメントの書き方｜誤答の5原因と7つのルール

最終更新日:2026年9月7日

「社内にAI検索を入れたのに、聞いても答えが的外れ」「欲しい情報がいつまでも出てこない」——そう感じているなら、原因はAIの性能だけとは限りません。まず疑いたいのは、AIが読みに行っている社内文書の側です。

この記事では、AIが誤答する原因を5つに分類したうえで、今日から書き方を変えられる具体的なルールを7つ、悪い例と良い例のビフォーアフターつきで解説します。あわせて、そのルールを個人の心がけで終わらせずチームの運用に定着させる方法と、やってはいけないことまで扱います。

AIが読みやすい社内文書とは、質問に答えるために必要な結論・前提条件・時点・用語の意味が、検索で取り出された一部分だけを読んでも理解できる文書です。

読み終えると、次の3つがわかります。

  • AIが的外れな回答を返すとき、5つの原因のどれに当てはまるかを切り分けられるようになります
  • 「AIが読む前提」で文書を書くための具体的なルールと、なぜそう書くべきかの理由がわかります
  • ルールをテンプレートとして仕組みに埋め込み、書き手が意識しなくても守られる状態にする方法がわかります

AI検索が的外れなら、まず文書側を確認します

結論から書きます。社内文書を対象にしたAI検索やAIチャットの回答が的外れになるとき、モデルの性能だけでなく、AIが読みに行く社内文書の書かれ方を確認する必要があります。

理由は、AIが回答を作る手順にあります。社内文書を対象にしたAI検索は、一般にRAG（Retrieval-Augmented Generation／検索拡張生成）という仕組みで動きます。質問を受け取ると、まず社内文書の中から関連しそうな箇所を検索して取り出し、取り出した文章を主な根拠として回答を組み立てます。ここで押さえておきたいのは、社内固有の事実についてAIは事前知識を持っていないという点です。検索で適切な文章を取り出せなければ、正確な回答を作るための根拠が不足します。取り出す材料が曖昧であれば、回答も曖昧になります。

言い換えると、実務上は「回答を生成するモデルの性能」と「必要な情報を検索で取り出せるかどうか」の両方が回答品質に影響します。前者はツールを乗り換えれば変わりますが、後者は自社でしか変えられません。文書側は、自社で直接改善できる重要な変数です。

この考え方は社外でも共有されています。AWSはRAG向けドキュメント作成のベストプラクティス（AWS Prescriptive Guidance）の中で、明確な見出しによる構造化、略語の定義、企業固有の文脈の明示、複数のサブトピックを含む大きな文書を自己完結した小さな文書に分割することを推奨しています。LLMはインターネット上のデータで学習しており企業内部の文脈を持たないため、文脈の設定が必要だという理由づけも明記されています。

また2025年8月には、ソフトウェア開発の生産性計測サービスを提供する米DX社の最高技術責任者ローラ・タチョ氏が、企業はすべての社内文書をAIが読みやすい形式で作成すべきだと提言しました。同氏は文書のフォーマットが揃っていないことを「大きな摩擦」と表現し、テキスト形式への統一と、すべての画像への説明文の付与を挙げています。人間にとって読みやすい文書構成はAIにとっても読みやすい、という双方向のメリットも同氏の指摘です（出典：Business Insider Japan「企業はすべての社内文書をAIが読みやすい形式で作成すべき」2025年8月15日）。

社内文書が原因でAIが誤答する5つのパターン｜対策が違うので、まず分類します

結論として、「AIの精度が低い」とひとまとめにせず、5つに分けて考えてください。原因ごとに打つべき手がまったく違うためです。分類せずに対策を始めると、文書を大量に書き足したのに精度が変わらない、といった事態になります。

なお、AIの誤答にはモデル側の要因や、検索設定・アクセス権限・インデックスの不備といった要因もあります。この記事で扱うのは、そのうち文書側で解決できる5つです。

原因症状の見え方打つべき対策
①情報がそもそもない「わかりません」と返る、または一般論だけ返る不足している質問を特定して書く
②情報が古い自信を持って古い手順を答える更新と棚卸し、時点の明記
③重複していて矛盾している聞くたびに違う答えが返る正本を1つに絞る
④文脈・前提が足りない部分的には正しいが例外で外す前提条件を本文に書く
⑤構造が読めない文書はあるのに検索で出てこないタイトルと見出しの設計

原因①：情報がそもそも存在しない

AIが「わかりません」と返す、あるいは社内の実態と関係のない一般論を返す場合、そもそも該当する文書が存在しない可能性があります。口頭やチャットで済ませてきた判断、担当者の頭の中にしかない運用は、文書化されていない限りAIには存在しません。

この原因への対策は「書く」ことですが、闇雲に書き足すのは非効率です。実際に聞かれたのに答えが出せなかった質問を記録し、その質問に答える文書から作ってください。

原因②：情報が古い

最も危険な原因です。更新日時やバージョン情報が検索時に適切に使われていない場合、AIは本文だけからどちらが現行版かを判断できません。古い手順が書かれた文書を取り出せば、それを現在の正しい手順として自信を持って提示します。「わかりません」と返るより、誤った情報を断定的に返すほうが業務上の実害は大きくなります。

対策は、更新と棚卸しに加えて、後述するルール4（時点に依存する語を使わない）の徹底です。

原因③：同じ話が複数の文書にあり、内容が食い違っている

質問するたびに違う答えが返る場合、この原因を疑ってください。同じテーマの文書が複数存在し、それぞれ内容が微妙に異なっていると、AIはそのときの検索結果次第でどちらかを採用します。人間なら「こっちが新しいほうだな」と判断できますが、本文中に有効期限や正本の情報がなければ、どちらを優先すべきかを判断する材料が不足します。

対策は、文書を増やすことではなく、正本を1つに決めて他を畳むことです。

原因④：判断の前提が書かれていない

回答が部分的には正しいのに、例外ケースで明らかに間違う場合、前提条件の記述漏れが原因です。「原則、当日中に対応」とだけ書かれた文書からは、営業時間外の扱いは読み取れません。

ここで問題になるのは、AIが「わかりません」と答えるとは限らない点です。書かれていない社内固有の前提を、一般的な知識から推測して補ってしまうと、社内ルールとは異なる回答を断定的に返します。人間は経験で補完し、しかも「これは自分の推測だ」と自覚できますが、AIの推測は回答の中で事実と同じ顔をして出てきます。

原因⑤：文書はあるが、構造が読めず検索に引っかからない

内容としては正しい文書が存在するのに、AIがそれを取り出せていないケースです。タイトルが「◯◯について」のように主題を示しておらず、本文の結論が末尾にあると、検索段階で候補に上がりません。文書があるのに使われていない状態は、書いた側からは最も気づきにくい失敗です。

AIが正しく読む文書の書き方7つのルール

ここからは具体的な書き方です。前章の原因④と⑤に直接効き、①〜③の再発も抑えます。

各ルールには「AIが読むときに何が起きるか」という理由を添えました。「わかりやすく書きましょう」という一般論ではなく、AIが検索して回答を組み立てる手順から逆算した理由です。理由がわかれば、ここに挙げていないケースでも判断できるようになります。

ルール1：タイトルに主語を入れる

悪い例

申請フローについて

良い例

経費精算の申請フロー（10万円未満・2026年4月改定版）

AIが読むときに何が起きるか

RAGでは文書がチャンクと呼ばれる断片に分割されて検索されます。このとき、タイトルをチャンクのメタデータとして保持したり、検索対象に含めたりする構成が一般的です。タイトルが「申請フローについて」だと、経費精算・稟議・勤怠のどの申請フローなのかをAIが判別できず、無関係な質問にも引っかかり、必要な質問には引っかからない状態になります。何についての文書か（主語）と、どの範囲の話か（条件）をタイトルに入れてください。

ルール2：結論を冒頭に置く

悪い例

背景として、昨年度から経費処理の負荷が課題として挙がっており、各部署へのヒアリングを実施しました。その結果、承認段階の多さが指摘され……（結論は第5段落）

良い例

経費精算は10万円未満であれば部長承認のみで完了します。以下、この運用に至った背景と例外ケースを説明します。

AIが読むときに何が起きるか

文書がチャンクに分割されると、背景と結論が別々のチャンクに入ることがあります。検索で背景側のチャンクだけが取り出されると、回答に必要な結論が検索結果に含まれず、「経緯は説明できるが結論を答えられない」という回答になります。

対策は、文書全体の冒頭に結論を置くだけでは足りません。各セクションを「結論→説明」の順にし、それぞれが単独で読んでも意味の通る状態にしてください。どの断片が取り出されても答えが含まれている、という状態が目標です。

ルール3：略語は初出で正式名称を併記する

悪い例

SFAの更新は営業日中に行ってください。

良い例

SFA（営業支援システム。当社ではSalesforceを指します）の更新は営業日中に行ってください。

AIが読むときに何が起きるか

略語は多義的です。文書内に手がかりがないと、検索の段階で別領域の文書と混ざります。さらに重要なのは、社内固有の指し先を書くことです。「当社ではSalesforceを指します」の一文があるだけで、AIは「SFAの使い方を教えて」という質問に対して、組織固有の意味を引き当てやすくなります。AWSのRAG向け文書作成ガイドも、推奨事項として略語の定義と企業固有用語の明示を挙げています。組織の外にない情報こそ、書く価値があります。

ルール4：「最新」「先日」など時点に依存する語を使わない

悪い例

最新のセキュリティガイドラインに従ってください。先日の会議で決まったとおり、対象は全社員です。

良い例

2026年4月1日改定のセキュリティガイドラインに従ってください。2026年3月12日の全体会議で決定したとおり、対象は全社員です。

AIが読むときに何が起きるか

検索で取り出された本文だけを見ても、「最新」や「先日」が何月何日を指すかは確定できません。文書の更新日時をメタデータとして持っている検索システムであっても、文中の相対表現がいつを基準にしているかまでは判断しにくいため、日付は本文にも明記します。これが原因②（古い情報を自信を持って答える）の主要な発生源です。日付を実体で書けば、内容が古くなったときに人もAIも判別できます。参照先を示す場合も、「別紙参照」ではなく文書名で書いてください。

ルール5：1つのメモに1つのトピックだけを書く

悪い例

「入社時オリエンテーション資料」という1つの文書に、PC設定手順・経費精算のやり方・評価制度の説明・オフィスの使い方が全部入っている

良い例

4つの文書に分け、「入社時オリエンテーション目次」から各文書を参照する

AIが読むときに何が起きるか

1つの文書に複数トピックが混在すると、関連度の計算がぼやけます。文書全体を大きな単位で検索したり、チャンクの境界がトピックをまたいだりすると、「経費精算のやり方は？」という質問に対してPC設定など無関係な情報まで検索結果に含まれる可能性があります。

トピックを分けると1チャンクあたりの情報密度が上がり、混線が減ります。AWSも、複数のサブトピックを含む大きな文書をそのままインデックスせず、明確なタイトルを付けた自己完結した小さな文書に分割することを推奨しています。人間にとっても、必要な部分だけを更新できるようになります。

ルール6：用語のゆらぎをなくす

悪い例

同じ対象を、文書によって「顧客」「クライアント」「取引先」「アカウント」と書き分けている

良い例

「顧客」に統一し、必要であれば冒頭に「本メモでは取引先企業を『顧客』と表記します」と明記する

AIが読むときに何が起きるか

ベクトル検索は表記ゆれにある程度強いのですが、実務ではキーワード検索と組み合わせたハイブリッド検索が使われることが多く、そこでは表記の一致が効きます。組織の文書群全体で呼び方がばらついていると、キーワード検索で検索漏れが起きやすく、検索条件や集計条件によって結果が揺れやすくなります。表記ゆれは前処理で機械的に吸収する方法もありますが、書く段階でそろえておくほうが確実です。

ルール7：判断の前提条件を本文に書く

悪い例

原則、当日中に返信すること。

良い例

サポート窓口に届いた問い合わせのうち、営業時間内（平日9:00〜18:00）に受信したものは当日中に返信します。時間外および休日に受信したものは、翌営業日の午前中までに返信します。

AIが読むときに何が起きるか

「原則」という語の裏には例外があります。人間はそれを経験で補いますが、AIは社内固有の前提を正確には推測できません。前提を省いた文はAIにとって無条件のルールとなり、例外ケースで断定的に誤答します。「誰が」「いつ」「どの範囲で」を文中に明記してください。これは原因④への直接の対策です。

補足ルール：図や画像で説明を代替しない

悪い例

業務フローの説明を、スクリーンショット1枚だけで済ませている

良い例

手順をテキストで書き、図は理解の補助として添える。図を載せる場合は、その図が示している内容もテキストで説明する

AIが読むときに何が起きるか

社内RAGでは、文書から抽出したテキストを検索対象にする構成が一般的です。画像認識やOCRを組み込んでいなければ、スクリーンショットの中にしか書かれていない情報は検索対象から漏れます。画像を説明文に変換して検索対象に含めるマルチモーダルな構成も存在しますが、自社の環境がそこまで対応しているとは限りません。

前述のDX社の最高技術責任者も、スクリーンショットを含むすべての画像に説明文を添えるべきだと指摘しています。文書の中で最も重要な情報ほど、テキストで書いてください。図は情報の本体ではなく、理解を助ける補助として位置づけるのが安全です。

7つのルールのまとめ

ルール対応する原因ひとことで言うと
1. タイトルに主語を入れる⑤構造が読めない何の話かをタイトルで確定させます
2. 結論を冒頭に置く⑤構造が読めない断片だけ読んでも答えがわかる形にします
3. 略語は初出で正式名称を併記④文脈が足りない組織固有の指し先を明示します
4. 時点に依存する語を使わない②情報が古い日付を実体で書きます
5. 1メモ1トピック⑤構造が読めない1チャンクの情報密度を上げます
6. 用語のゆらぎをなくす④文脈が足りない同じものを同じ語で呼びます
7. 前提条件を本文に書く④文脈が足りない例外の条件を省きません
補足. 図で説明を代替しない①情報がないテキストがなければ検索から漏れます

チャンクを調整する前に、まず文書側を確認します

RAGの精度改善には、チャンクサイズの最適化、埋め込みモデルの見直し、ハイブリッド検索、リランキングといった技術的な手法があります。これらはいずれも有効です。ただし、これらの手法は「取り出す対象の文書が読める状態にある」ことを前提にしています。

AWSがRAG向けの文書作成ガイドで、明確な見出し・略語の定義・文脈の明示・大きな文書の分割を推奨しているのも、同じ理由からです。チャンク分割を文書の意味構造に合わせるという話は、裏を返せば、文書に読み取れる意味構造があることが前提だということです。見出しがなく、1つの文書に複数トピックが混ざり、結論が末尾にある文書ほど、適切なチャンク分割の難易度は上がります。

文書側の対処には、もう1つ実務的な利点があります。技術的なチューニングには専門知識と検証環境が要りますが、書き方を変えることは今日から着手できて、費用もかかりません。そして書き方への投資は、後でツールを乗り換えても無駄になりません。

【中間CTA】ルールを守る運用は、書く場所とセットで考えます

書き方ルールは、決めるだけでは定着しません。書く画面の中に型として埋め込むところまでやって、はじめて運用になります。

DocBaseは、テンプレート機能・差し込み機能・AIタグ自動生成・添付ファイルを含む全文検索を標準機能として備えたナレッジ共有ツールです。次の章で紹介する運用方法は、30日間の無料トライアルですべて試せます。クレジットカードの登録は不要で、初期設定費用もかかりません。

DocBaseの30日間無料トライアルを始める

書き方ルールを個人の心がけで終わらせない｜DocBaseでの実践方法

結論として、ルールは「守りましょう」と呼びかけても定着しません。守るためのコストがゼロになる仕組みに落とし込んでください。ここでは、前章の7つのルールをDocBaseの機能で運用に変える方法を紹介します。

テンプレート機能で、ルールを型にする

DocBaseでは、メモに template タグを付けるだけで、そのメモがテンプレートとして使えるようになります。新規作成時にテンプレート一覧から選べば、決まったフォーマットで書き始められます。

ルール1（主語）、ルール2（結論を先に）、ルール4（日付の明記）、ルール7（前提条件）は、テンプレートの見出しとして固定してしまえば、書き手が意識しなくても自然に守られます。たとえば議事録テンプレートを次のように組むと、書く人はブランクを埋めるだけで構造が整います。

# %{Year}年%{month}月%{day}日 ◯◯定例会議 議事録

## 決定事項（結論）

## 適用範囲・前提条件

## 背景

## 保留事項と次回確認すること

%{Year} %{month} %{day} %{name} といったテンプレート変数が使えるため、日付や作成者は自動で埋まります。%{year:-1y} %{day:+2d} のような相対日付の指定にも対応しているので、「2日後までに提出」といった期限を型に含めることもできます。ルール4で「時点に依存する語を使わない」と書きましたが、テンプレート変数を使えば、書き手が日付を書き忘れる余地そのものがなくなります。

具体的な設定手順はDocBaseのテンプレート機能でメモを作成する方法で確認できます。

差し込み機能で、同じ情報の複製をやめる

原因③（重複していて矛盾している）は、コピー＆ペーストで生まれます。同じ内容を複数の文書に貼り付けると、片方だけが更新されて食い違いが発生し、AIは聞かれるたびに違う答えを返すようになります。

DocBaseの差し込み機能を使うと、#{メモID} と書くだけで別のメモの中身をその場に展開できます。内容の実体は1か所にしかないため、正本を更新すれば参照しているすべての場所に反映されます。共通の前提条件、用語定義、承認フローなど、複数の文書に登場する情報はこの形にしてください。ルール6（用語のゆらぎをなくす）も、用語定義メモを1つ作って各文書から差し込む形にすると、統一を維持しやすくなります。

書き方はDocBaseの差し込みメモで別のメモを埋め込む手順にまとまっています。

AIタグ自動生成で、タグの表記を揃える

DocBaseには、AIがメモの内容を分析して適切なタグを提案するAIタグ自動生成があります。チーム内で既に使われているタグを優先的に活用する設計のため、タグの表記が人によってばらつくのを防げます。AI機能をONにしていれば、追加費用なしで利用できます。

ここで効いてくるのがルール1とルール2です。タイトルに主語がなく、本文の結論が末尾にあるメモは、何についてのメモかを判断しにくくなります。タイトルや本文から主題を把握しやすい状態にしておくことは、AIが内容を判断するうえでも有利です。タグがそろうと、AI検索の前段階である絞り込み検索も機能するようになります。書き方の改善が、そのままタグ運用の改善につながる構造です。

機能の詳細はDocBaseのAIタグ機能の使い方をご覧ください。

添付ファイルの中身も検索対象になることを前提に置く

DocBaseの検索は、タイトル・本文・コメントに加えて、添付ファイルの中身も対象に含みます（コメント内のファイルと、1メモ内の添付ファイル合計が75MB以上になる場合は対象外です）。PDFやExcelで配布された資料も、貼り付けておけば検索から辿れます。

ただし、これは「添付しておけば伝わる」という意味ではありません。ファイル形式やレイアウトによっては、検索システムが文書構造を完全には再現できない場合があります。結論と前提条件はメモ本文にテキストで書き、詳細なデータや元資料を添付する、という順序を守ってください。補足ルール（図で説明を代替しない）と同じ考え方です。

検索の対象範囲と絞り込み方法はDocBaseでメモ・コメント・添付ファイルを検索する方法で確認できます。

外部のAIから読ませるときも、効くのは書き方です

DocBaseはMCPサーバーを提供しており、Claude、Claude Code、ChatGPT、Visual Studio Code、Cursor、Gemini CLIなどの外部AIアプリからDocBaseのメモにアクセスできます。OAuth 2.1に準拠しており、DocBase側で設定した閲覧権限がそのまま継承されるため、権限のないメモが外部AIに読まれることはありません。こちらもAI機能をONにしていれば追加費用なしで利用できます。

ここで重要なのは、外部の高性能なAIに切り替えても、文書側の問題がそのまま残っていれば、期待した改善が得られないことがあるという点です。逆に、書き方を整えた文書は、DocBase内のAI機能でも外部AIでも同じように効きます。書き方への投資が特定のツールに依存しないのは、この理由からです。

DocBaseのAI機能の全体像はナレッジ共有ツールDocBaseのAI機能一覧にまとめています。

なお、AI機能のON/OFFはチーム管理者が一括で管理できる標準機能です。特定のメモをAIの対象外にしたい場合は no-ai タグで除外できます（これも標準機能です）。グループ単位でAIの利用範囲を制限したい場合は、セキュリティパック（有料オプション）の契約が必要です。

やってはいけないこと｜AI下書きの量産は「AI汚染」の入口です

結論として、文書が足りないからといってAIに下書きを量産させ、数で埋めようとするのは逆効果です。

理由は、再帰的に精度が落ちる構造にあります。需要を確かめないまま生成した文書が増えると、読まれない・検証されていない文書がナレッジベースに溜まります。次にAIが検索するとき、AIはそれらも含めて読みます。検証されていない重複文書が増えるほど、検索時に不要な候補が混ざり、正本を安定して取り出しにくくなります。こうした低品質なAI生成コンテンツは「AI Slop」と呼ばれることがあります。原因①（情報がない）を解消したつもりが、原因③（重複して矛盾）と原因⑤（構造が読めない）を新たに作ってしまいます。

対策は3つです。

  1. 下書き生成は需要シグナルを起点にします。 AIに質問されたが答えが出せなかった、検索されたがヒットしなかった。こうした記録を起点に、答えるべき文書を1つずつ作ってください。「文書を増やす」のではなく「答えられなかった質問を潰す」と考えると判断を誤りません。
  2. 公開前に人が承認します。 AIによる下書き生成は着手のハードルを下げる有効な使い方ですが、承認を外した全自動更新は避けてください。「この内容は正しい」と人間が保証する工程を残すことが、ナレッジベースへの信頼を保ちます。
  3. 組織固有の判断・背景・意図は人が書きます。 AIが得意なのは文章を書くことであって、何を書くべきかを決めることではありません。一般論はAIが元から知っています。社内文書に書く価値があるのは、AIが持ち得ない、その組織だけの前提と判断です。

よくある失敗パターンと対策｜整備したのに精度が上がらない3つのケース

失敗①：「まず全社の文書を棚卸しします」で止まる

症状：プロジェクトを立ち上げたものの、対象が広すぎて数か月経っても着手できていない状態です。整備の必要性は全員が認めているのに、誰も最初の1文書に手をつけられません。

対策：全体最適を先に目指さず、まず頻出質問の上位20件など、範囲を決めて始めてください。AI検索の質問ログ、問い合わせ窓口への質問、新入社員から繰り返される質問のいずれかが起点になります。決めた範囲に答えられる状態を作ってから広げるほうが、体感できる改善が早く出ます。

失敗②：ルールを決めたが、決めた人しか守っていない

症状：文書作成ガイドラインは存在するのに、新しく作られるメモは従来どおりの書き方のままです。ガイドライン自体が読まれていません。

対策：ルールを読ませるのではなく、テンプレートに埋め込んでください。前章で紹介したとおり、見出し構造としてルールを型にしてしまえば、書き手はブランクを埋めるだけでルールを満たせます。守るコストがゼロになれば、周知の努力はほとんど不要になります。

失敗③：古い文書を残したまま、新しい文書を足す

症状：整備を進めているのに、AIに聞くと相変わらず答えが安定しません。同じ質問を2回すると違う答えが返ることもあります。原因③が解消されていない典型です。

対策：新規作成と、旧文書の処理をセットで運用に組み込んでください。旧文書はアーカイブするか、差し込み機能で正本を参照する形に置き換えます。ナレッジ運用は「作る」だけでは回りません。「畳む」を同じ重さで扱ってください。

DocBaseがおすすめ｜選ばれる理由

ここまで紹介した書き方ルールは、どのツールを使っていても有効です。そのうえで、ルールを運用として定着させたい場合には、書く場所の側に型を埋め込める仕組みがあると進めやすくなります。

DocBaseは、テンプレート機能でルールを型にでき、差し込み機能で情報の重複を防ぎ、AIタグ自動生成と添付ファイルを含む全文検索で探しやすさを保てるナレッジ共有ツールです。MCPサーバーにも対応しているため、社内文書を外部のAIアプリから権限を効かせたまま参照させることもできます。

  • 料金：チーム単位の定額制です。パーソナル（1人）は月額550円、スターター（3人）は月額1,320円、ベーシック（10人）は月額4,950円、レギュラー（30人）は月額11,000円（いずれも税込）。ユーザー単価制ではありません
  • 信頼性：導入実績は12,000社以上です。ISO 27001（ISMS）認証を取得しており、利用継続率は99%以上です（自社集計）
  • 導入のしやすさ：初期設定費用は不要です

30日間の無料トライアルで、テンプレート運用も差し込み機能もAIタグ自動生成もすべて試せます。クレジットカードの登録は不要です。

DocBaseの30日間無料トライアルに申し込む

DocBaseの料金プランと機能の違いを確認する

よくある質問（FAQ）

Q. AIが読みやすい文書と、人が読みやすい文書は違いますか？

ほとんど同じです。タイトルで主題が示され、結論が先にあり、略語に説明があり、1つの文書に1つのトピックだけが書かれている文書は、人にとってもAIにとっても読みやすい文書です。違いが出るのは3点で、「最新」「先日」が具体的にいつを指すのかを本文だけからは判断できないこと、書かれていない社内固有の前提を経験で補えず一般論から推測してしまうこと、画像解析に対応していない検索環境では図の中だけにある情報を検索対象にできないことです。この3点だけ意識すれば、人向けの読みやすさを追求することがそのままAI対策になります。

Q. RAGの精度を上げるには、チャンクサイズの調整と文書の書き直しのどちらを先にやるべきですか？

文書側を先に確認することをおすすめします。チャンク分割は文書の意味構造に沿って行うものなので、見出しがなく複数トピックが混在した文書では、サイズ調整だけでは意味のまとまりを作りにくくなります。まず質問ログで実際に失敗している質問を拾い、その回答に必要な文書がどの原因（①〜⑤）に当てはまるかを分類してください。文書側の問題であれば書き方の改善が最短ですし、文書が正しく書かれているのに取り出せていないのであれば、そこではじめて技術的なチューニングの出番になります。

Q. 既存の社内文書が数千件あります。どこから手を付ければいいですか？

全件の見直しは現実的ではありません。実際に検索されている質問の上位20件に絞り、その回答に必要な文書だけを先に整えてください。まず、日常的によく参照されている文書から対象を絞れます。よく聞かれる質問から潰していくと、効果が体感できるため社内の協力も得やすくなります。残りの文書は、参照されたタイミングで直す運用に切り替えるのが現実的です。

Q. 「1メモ1トピック」にすると、メモの数が増えて探しにくくなりませんか？

タグと目次メモを併用すれば、探しやすさを維持できます。トピックを分けたうえで、目次にあたるメモから各メモを参照する構成にすると、人は目次から辿れて、AIはトピック単位で正確に取り出せます。DocBaseの場合は差し込み機能で目次メモから各メモの中身を展開できるため、分割していても1つの文書のように読むことができます。

Q. Markdownで書けないメンバーがいます。書き方ルールを守らせるのは難しいのでは？

書き方ルールとMarkdownの記法は別の話なので、記法の習熟は前提になりません。DocBaseの場合、Markdownに不慣れなメンバーはリッチテキストモード（WYSIWYG編集）で直感的に編集できます。内部フォーマットはMarkdownに統一されるため、メンバーによって編集方法が異なってもフォーマットが混在することはありません。加えて、テンプレートで見出し構造を用意しておけば、書き手が構造を組み立てる必要自体がなくなります。

Q. AIに読ませたくない機密文書がある場合はどうすればいいですか？

DocBaseでは、チーム全体のAI機能のON/OFFをチーム管理者が一括で切り替えられます。特定のメモだけをAIの対象外にしたい場合は、そのメモに no-ai タグを付けることで除外できます。ここまでは標準機能です。特定のグループのメモをまとめてAIの利用範囲から外したい場合は、セキュリティパック（有料オプション）の契約が必要になります。

関連記事・関連情報

編集ポリシー

本記事はDocBase開発元である株式会社KRAYが作成しています。可能な限り客観的な情報提供を心がけていますが、自社製品に関する記事であることをあらかじめご了承ください。

出典

監修

DocBase編集部
DocBase編集部

情報共有に役立つ情報をお届けします。

  • DocBaseの無料トライアルを始める
  • DocBaseの資料をダウンロード

関連する記事