メインコンテンツへスキップ
メニュー

社内資料をAIに渡す方法:全文か検索かを資料ごとに決める

社内資料は、更新頻度と必要な範囲から、全文か検索した部分かを選んでAIに渡します。

この記事の要点

  • 規程と対応履歴は、AIへの渡し方を分ける
  • 資料の更新頻度と、回答に必要な範囲を表にする
  • 検索に移す条件と、全文に戻す条件を同じ表に書く

全体像図を準備中

目次

規程と対応履歴は渡し方を分ける

A&Aの考え方

社内資料をAIに渡す方法には、回答を作るAIに全文を読ませる方法と、先に検索して必要な部分を読ませる方法があります。短い規程は全文を渡す方法を残し、必要箇所が限られる対応履歴は検索を試す候補にします。どちらも、AIが扱える量と機密情報の取り扱い条件を満たすことが前提です。

A&Aの考え方

毎回まとめて渡していた手順書が増え、回答を待つ時間が長くなったとします。ここで全資料を検索に移すと、例外を定めた条文まで見つけられるかが新たな心配になります。資料の性質に合わせて渡し方を分ければ、作り直す範囲を絞れます。

出典に基づく事実

ブランドの方針を業務に使うソフトを提供するbrand.aiは、Anthropicの事例記事で、Claudeがブランド指針全体を一度に処理できる点を評価しています。

Anthropic ↗

出典に基づく事実

同社は検索の仕組みも二つ使っています。一つは関連するブランドの情報を取り出すため、もう一つは会話の文脈を保つためです。資料全体を扱う能力と、必要な情報を探す仕組みを併用しています。

Anthropic ↗

A&Aの考え方

この記事を書いているAutomate & Augment(A&A)は、この併用の考え方を自社資料の渡し方に当てはめます。参考にするのは資料を読む仕組みです。brand.aiの商品の規模や成果を、小さな会社でも再現できるという話ではありません。

仮想例

機器の保守会社を仮の例にします。出張の承認規程は、本文と例外を一緒に渡します。過去の修理履歴からは、機種と症状で探した記録を渡します。規程と履歴を同じ方法で扱う必要はありません。

A&Aの考え方

機密資料では、まず元の資料と検索用のデータをどこに置けるかを確かめます。検索用に整理したデータを索引と呼びます。索引を社外に置けないなら、その条件の中で作れる方法を選びます。検索で取り出した抜粋をAIへ送れるかも、別に確かめます。

A&Aの考え方

渡してよい情報の線引きは、関連記事「AI外注で顧客データをどこまで渡すか:発注前に決める3つの区分」で扱う論点です。本稿で決めるのは、渡せると確認した資料から、どの範囲を取り出すかです。

更新の頻度と使う範囲を表にする

A&Aの考え方

資料ごとに、更新の頻度と、普段の質問に答えるために必要な範囲を書きます。この二つを判断材料にするのはA&Aの提案です。出典が示した数値基準ではありません。

出典に基づく事実

Anthropicの記事は、AIが使う機能の設計について、住所録から一人を探す例を挙げています。全連絡先を返して順に読ませると、回答に不要な情報まで、AIが一度に読める量に含まれてしまうと指摘しています。

Anthropic ↗

A&Aの考え方

この指摘から、資料がAIの扱える量に収まるかだけでなく、そのうちどれだけが回答に必要かを見る価値があります。担当者は、普段の質問と、その答えに必要な原文を照合します。AIが引用箇所を挙げただけでは、例外まで読めた証拠にはしません。

仮想例

保守会社の記入例では、出張の承認規程は「改訂時に更新、例外を含む全体が必要」と書きます。修理履歴は「対応のたびに追加、同じ機種の似た症状だけ必要」と書きます。これは架空の業務例で、調査結果ではありません。

A&Aの考え方

更新が多い資料では、最新版を渡す手間も見ます。全文を毎回取り直す手間と、検索用の索引へ変更を反映する手間を比べます。検索の仕組みを付けるだけで最新版を使えるとは考えず、誰が更新を確認するかを決めます。

仮想例

毎日変わる短い作業予定でも、回答に全体が必要なら、最新版を丸ごと渡す候補に残ります。逆に、ほとんど変わらない分厚い手順書でも、必要なのが特定機種のページだけなら検索を試す候補です。

A&Aの考え方

更新頻度だけで決めると、この二つを逆に扱う恐れがあります。資料の量も無視できません。全文が利用するAIの上限に収まらない場合は、業務ごとに分割する方法や検索を検討する必要があります。

A&Aの考え方

表には資料名、更新頻度、回答に必要な範囲、今の渡し方を記録します。「全体か一部か分からない」資料は、そのまま未確認と書きます。こうした資料は、外注先に検索の仕組みを作ってもらう前に、担当者が実際の質問と必要なページをそろえる対象です。

機器保守会社の資料配分表の仮の記入例。A&Aの設計案であり、導入結果ではありません。
資料更新と必要な範囲渡し方と見直す条件
出張の承認規程改訂時に更新。本文と例外を一緒に使う扱える量なら全文を残す。担当者が必要な条文を確認
修理履歴対応のたびに追加。同じ機種の似た症状を使う検索を試す。必要記録が出なければ、量と版を確かめ全文へ戻す
短い作業予定毎日更新。全体が必要最新版の全文を残す候補。頻度だけで検索に移さない

検索に移す条件と戻す条件を決める

A&Aの考え方

資料ごとの渡し方をまとめた表には、検索へ移す条件と全文へ戻す条件を同じ行に書きます。移す候補は、答えに必要な箇所が限られ、全文を渡す負担が増えた資料です。最新版から必要な箇所を取り出せるかは、移す前に確かめます。

出典に基づく事実

Anthropicは、AIが使う機能の設計について、効果の大きい業務を狙った少数の機能から始めるよう勧めています。評価では正確さに加え、実行時間や、AIが処理する文字量に関わるトークン数、エラーなども見ると説明しています。

Anthropic ↗

A&Aの考え方

A&Aの提案では、同じ業務の質問を、全文を渡す方法と検索で取り出した部分を渡す方法の両方で試します。担当者が先に必要な本文と例外を決め、回答に使われた資料の版も照合します。そのうえで待ち時間、実際の利用料金、人による確認と更新の手間を比べます。効果は試すまで未測定です。

仮想例

保守会社の修理履歴なら、「対象機種の記録を取り出せ、直近の追記も読める」を検索に移す条件にできます。「必要な過去記録が検索に出ない」を全文に戻す条件に書きます。検索に出なかったことを、過去記録が存在しない証拠にはしません。

A&Aの考え方

適用条件や例外を落とせない短い規程は、AIが扱える量の範囲で全文を渡し続ける候補です。ただし全文を渡しても、AIが読み落とす恐れは残ります。必要な条文を確認できない回答は、担当者が原文と照らして判断します。

A&Aの考え方

全文に戻す場合も、最新版を扱えることが条件です。全文が上限に収まらない、または最新版を確認できないときは、担当者が原文を確認する方法へ戻します。どちらの方法でも確認できないまま、自動回答だけを続ける形にはしません。

仮想例

外注先に頼む範囲は「修理履歴を探す仕組みと、追記が反映されたかの確認まで」と書けます。規程の改訂を判断する仕事は自社に残します。表の確認者欄に担当者を書けば、仕組みを作る人と、資料の正しさを決める人の役割を分けて合意できます。

A&Aの考え方

資料の分け方そのものから整理したい場合は、関連記事「AIに毎回同じ説明をしない:会社の情報は3つに分けて渡す」が先に読む記事に当たります。本稿の表は、その後で資料ごとの渡し方を決め、変更する範囲を狭く保つためのものです。

全文と検索の使い分けは資料ごとに見直す

A&Aの考え方

規程と対応履歴は、必要な情報の範囲に合わせて渡し方を分けます。

A&Aの考え方

更新頻度と回答に必要な範囲を記録すると、全文を差し替える手間と検索用データを更新する手間を比べられます。

A&Aの考え方

検索に移す条件と全文に戻す条件、確認者を同じ表に残すことで、作り直しを資料単位で決められます。

規程と対応履歴は、回答に必要な範囲に合わせて渡し方を分けます。全文の差し替えと検索用データの更新にかかる手間を比べ、移す条件と戻す条件、確認者を同じ表に残すと、資料単位で変更を決められます。

よくある質問

検索に変えると利用料金は必ず下がりますか?

必ず下がるとは言えません。AIへ渡す量のほか、検索の実行や索引の更新にも費用と手間がかかります。同じ質問で実際の利用料金と人の作業を比べるのがA&Aの提案です。

規程を全文で渡せば例外の見落としは防げますか?

防げるとは限りません。検索で例外を取り出し損ねる工程は省けても、AIによる読み落としは残ります。重要な回答は、担当者が適用条件と例外を原文で確認します。

更新頻度が分からない資料はどうしますか?

頻度を推測せず、未確認として残します。直近の改訂と、誰が最新版を管理するかを確かめる対象にします。検索へ移す場合も、最新版が反映されているかの確認は必要です。

出典・編集情報

記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。

  1. Brand.ai uses AI to make brands more human with Claude

    Anthropic · Publication date not stated

    確認日 2026-10-30
  2. Writing effective tools for agents — with agents

    Anthropic · 2025-09-11

    確認日 2026-10-30

編集方針

← 記事一覧へ