Media > AI活用ユースケース > 総務 > 総務に届く設備・備品・レイアウト変更の依頼に、過去の対応記録と業者の見積から似た依頼を探し、手配先・費用の目安・かかった日数を根拠付きで返す

総務に届く設備・備品・レイアウト変更の依頼に、過去の対応記録と業者の見積から似た依頼を探し、手配先・費用の目安・かかった日数を根拠付きで返す

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

総務に設備や備品、レイアウト変更の依頼が届いたときに、過去の似た依頼を探し、どこに頼んだか、いくらかかったか、何日かかったか、何でつまずいたかを対応記録の番号付きで返します。

サマリー
生成AI
ChatGPT/Claude/Gemini
AIサービス
Azure AI/Google Vertex AI/OpenSearch
対象業界
IT・SaaS/その他/商社/製造
対象部門
総務
対象業務
情報検索/集計・分析
主な課題
属人化している/引き継ぎができていない/情報が見つからない
AIで行う処理
検索(RAG)
主な効果
対応スピード向上/属人化解消/教育コスト削減/検索時間短縮
導入難易度
★★☆☆☆
実装レベル
本格構成
費用感
RAG・個別開発(大)
人間の確認
条件付き
現在工数
30h/月
AI導入後
9h/月
想定削減
70%
年間削減
252h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 依頼フォームに依頼が届き、施設係の担当に割り当てられる
  2. 担当が、依頼フォームの一覧を件名の言葉で検索し、似た依頼を探す
  3. 見つかった依頼の完了時のメモと、共有フォルダの見積書を開き、手配先と金額を確かめる
  4. 見つからなければ、前任者のメモや係の先輩に「前にどこに頼んだか」を聞く
  5. 手配先に見積を頼み、依頼した部署へ費用と日数の目安を返す
導入後(After)
  1. 自動依頼フォームで依頼が完了になると、依頼の文・種類・拠点とフロア・手配先・費用・依頼日と完了日・完了時のメモを1件の文書にして検索基盤に登録する
  2. 自動依頼フォームに依頼が届くと、依頼の文で過去の完了した依頼を言葉で検索する
  3. 自動同じ検索で、上位20件の費用と日数の中央値と幅、手配先の顔ぶれを集計する
  4. 自動Claude が、上位5件について、何をしたか・手配先・つまずいた点を対応記録の引用付きでまとめる
  5. 自動結果を、依頼フォームのその依頼に担当向けのコメントとして付ける
  6. 人担当がコメントを読み、手配先を決めて見積を頼み、依頼した部署へ目安を返す
各工程の詳しい説明を読む
  1. 依頼フォームに依頼が届き、施設係の担当に割り当てられる
  2. 担当が、依頼フォームの一覧を件名の言葉で検索し、似た依頼を探す
  3. 見つかった依頼の完了時のメモと、共有フォルダの見積書を開き、手配先と金額を確かめる
  4. 見つからなければ、前任者のメモや係の先輩に「前にどこに頼んだか」を聞く
  5. 手配先に見積を頼み、依頼した部署へ費用と日数の目安を返す

(a)件名の言葉が合わない。 2番目で「パーテーション」と探しても、前の依頼の件名が「島の間仕切り設置」だと当たりません。依頼の件名は依頼した人が書いたもので、言葉がそろっていません。

(b)1件見つけても、相場は分からない。 3番目で見つかった1件の金額が、その時の特別な事情(夜間の工事、急ぎの手配)で高かったのかどうかは、何件か並べないと分かりません。 担当は1件の金額をそのまま目安として返してしまいます。

(c)つまずいた点が残っていない。 「管理会社の申請に2週間かかった」「搬入の経路に養生が要った」といったことは、完了時のメモに書かれていれば運がよいほうです。 同じところで毎回つまずきます。

(d)前任者の記憶に頼っている。 4番目で答えてくれる人がいるうちは回りますが、施設係は2〜3年で入れ替わります。 新しい担当ほど手配先を知らず、毎回一から見積を取り直します。

取り込み(依頼が完了するたび)

  1. 【自動】 依頼フォームで依頼が完了になると、依頼の文・種類・拠点とフロア・手配先・費用・依頼日と完了日・完了時のメモを1件の文書にして検索基盤に登録する

新しい依頼が届いたとき

  1. 【自動】 依頼フォームに依頼が届くと、依頼の文で過去の完了した依頼を言葉で検索する
  2. 【自動】 同じ検索で、上位20件の費用と日数の中央値と幅、手配先の顔ぶれを集計する
  3. 【自動】 Claude が、上位5件について、何をしたか・手配先・つまずいた点を対応記録の引用付きでまとめる
  4. 【自動】 結果を、依頼フォームのその依頼に担当向けのコメントとして付ける
  5. 【人】 担当がコメントを読み、手配先を決めて見積を頼み、依頼した部署へ目安を返す

3番目を検索基盤の集計にしているのが、この設計の分かれ目です。 費用の目安は、依頼した部署が予算を取るときにそのまま使います。AIの文章の中の数字は、どこから来たのかを後から確かめられません。 集計の数字なら、どの20件から出したかが記録に残ります。

5番目で、依頼した部署には直接返さないのも意図してのことです。 前例の金額は、当時の物価と当時の事情を含んでいます。担当が見て、今回の条件に合うかを確かめてから返します。

02今回想定するシステム構成

構成図
【取り込み】依頼フォームで依頼が完了になる
   ▼【トリガー】完了のたび
AWS Lambda ── 依頼の文・種類・拠点・手配先・費用・日数・メモを1件の文書に
   ▼
Amazon OpenSearch Service(依頼の索引。Sudachi+同義語の辞書)

【新しい依頼】依頼フォームに依頼が届く
   ▼【トリガー】依頼フォームからの通知
AWS Lambda
   ▼
Amazon OpenSearch Service
   ├─ 言葉の検索:依頼の文・完了時のメモ(Sudachi+同義語)
   ├─ filter:完了済み、過去3年
   └─ 集計:sampler(上位20件)→ percentiles(費用・日数)、terms(手配先)
   ▼
Claude(Amazon Bedrock)── 上位5件を検索結果のブロックで渡し、引用付きでまとめる
   ▼
依頼フォームの担当向けコメント(似た依頼・手配先・費用と日数の目安・つまずいた点)
役割想定する製品代替候補
検索基盤Amazon OpenSearch Service(Sudachi、同義語の辞書、sampler と percentiles の集計)Azure AI Search、Vertex AI Search(Agent Search)
生成AIClaude(Amazon Bedrock。似た依頼を引用付きでまとめる)Gemini API、OpenAI API
連携AWS Lambda(取り込み、依頼の通知の受け取り、コメントの書き込み)AWS Step Functions
保管Amazon S3(同義語の辞書の元ファイル、検索の記録)―
台帳既存の依頼フォームと共有フォルダの見積書―

依頼フォームには、担当向けのコメントを付けるだけです。 依頼の状態や承認には触れません。依頼フォームの仕組みが、外からのコメントの書き込みと、依頼の受付・完了の通知に対応していることが前提で、どの方式が使えるかは依頼フォームの製品によるので、この部分は利用環境に応じた個別の実装になります。

日本語の言葉の検索には、Sudachi を使います。 Amazon OpenSearch Service の対応プラグインの一覧で、日本語向けに推奨とされているものです。オプションのプラグインなので、ドメインに関連付けてから使います。

同義語は、辞書のファイルとしてドメインに取り込みます。 公式のドキュメントでは、同義語や除外する語のファイルを S3 に置いてパッケージとして取り込み、ドメインに関連付けると、synonyms_path に analyzers/<パッケージのID> を指定して使えます。検索の側の分析器で updateable を true にしておけば、辞書を更新したときに索引が自動で更新されるとされています。

03どうやって実装するのか

Step1

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、依頼フォームで依頼が完了になったときです。 完了の通知を受けて、その依頼を1件の文書にして登録します。完了前の依頼は取り込みません。 見積の途中の金額や、まだ決まっていない手配先が前例として返るのを防ぎます。

検索は、依頼フォームに新しい依頼が届いたときに自動で動きます。 担当が開く前にコメントが付いている状態にしておくと、担当は依頼を開いた瞬間に前例を読めます。 依頼の文が短すぎるとき(20字未満など)は検索せず、「依頼の内容を詳しく聞いてから検索してください」とだけコメントします。

コメントには「再検索」のリンクを付け、 担当が依頼の文を書き足したあとにもう一度探せるようにします。

Step2

入力データを集める

データ中身取得元
過去の依頼(完了済み)依頼番号、依頼の件名と本文、種類、拠点とフロア、手配先、手配先の区分(工事業者・家具の販売店・家電の量販店・ビルの管理会社)、費用(税抜)、依頼日、完了日、完了時のメモ依頼フォーム
見積書依頼番号、見積の明細共有フォルダ(この構成では原本へのリンクとして使う)
新しい依頼依頼の件名と本文、種類、拠点とフロア、希望の時期依頼フォーム

質を決めるのは、完了時のメモです。 「管理会社への工事申請が必要で、承認まで10営業日」「夜間の作業で割増」「搬入にエレベーターの養生が要った」。この一行があるかどうかで、次の担当の手間がまるで違います。 取り込みの側では、メモが空の依頼に印を付けて、毎月の件数を係長に見せます。

見積書のPDFは索引に入れず、 原本へのリンクとして添えるだけにします。金額は依頼フォームの費用の欄から取ります。

Step3

データの取得方法を決める

依頼フォームの仕組みから、完了した依頼のデータを受け取ります。最初の取り込みは、過去3年分を一覧として書き出してもらい、まとめて登録します。 そのあとは完了のたびに1件ずつ足します。

索引は1件の依頼を1件の文書にします。

項目型使いどころ
request_idkeyword依頼番号。原本と見積書へのリンク
title/bodytext(Sudachi+同義語)言葉の検索。件名は重みを2倍にする
notestext(Sudachi+同義語)完了時のメモ。言葉の検索とつまずいた点の材料
categorykeyword種類。画面の表示と、種類ごとの集計
site/floorkeyword拠点とフロア。同じ拠点の前例を上に寄せる
vendor/vendor_typekeyword手配先と区分。手配先の集計
costinteger費用(税抜)。中央値と幅の集計
lead_daysinteger依頼日から完了日までの営業日数。中央値と幅の集計
completed_ondate過去3年の絞り込みと、何年前の前例かの表示

日数は、取り込みのときに営業日で数えて持たせます。 暦の日数にすると、年末年始や連休をまたいだ依頼だけが長く見えます。

分析器は、索引を作るときに次のように決めます。 索引に入れるときは Sudachi だけで分け、検索するときだけ同義語を足します。

PUT /facility-requests
{
  "settings": {
    "index": {
      "number_of_shards": 1,
      "analysis": {
        "tokenizer": { "ja_tokenizer": { "type": "sudachi_tokenizer" } },
        "filter": {
          "facility_synonyms": {
            "type": "synonym",
            "synonyms_path": "analyzers/F000000001",
            "updateable": true
          }
        },
        "analyzer": {
          "ja_index": { "type": "custom", "tokenizer": "ja_tokenizer" },
          "ja_search": { "type": "custom", "tokenizer": "ja_tokenizer",
                         "filter": ["facility_synonyms"] }
        }
      }
    }
  },
  "mappings": { "properties": {
    "body": { "type": "text", "analyzer": "ja_index", "search_analyzer": "ja_search" }
  } }
}

同義語を検索の側だけに置くのは、updateable が検索の側の分析器にしか効かないためです。 公式のドキュメントでは、この設定のときに限って、辞書のパッケージを更新すると索引が自動で更新されます。索引の側に同義語を入れると、辞書を足すたびに索引を作り直すことになります。F000000001 は辞書のパッケージの ID に置き換えます。Sudachi のシステム辞書や利用者辞書を指定するときは、公式の例のとおり additional_settings にパッケージの ID を書きます。

Step4

AIへ渡す前に整形する

  1. 費用の欄を確かめる … 税込と税抜が混ざっていないかを確かめます。依頼フォームの欄が税抜と決まっていなければ、取り込みで印を付けます
  2. 費用が0円の依頼を分ける … 社内の在庫で済んだ、管理会社の負担で済んだ、といった依頼は費用0円になります。集計から外し、前例としては残します
  3. 呼び方の揺れを辞書にする … 「パーテーション/間仕切り/パネル」「コンセント増設/電源工事/電源の追加」「什器/オフィス家具」「入退室/セキュリティカード/IDカード」を同義語の辞書にします
  4. 手配先の名前をそろえる … 「○○電設」「(株)○○電設」「○○電設工業」のような表記の揺れを、取引先の一覧のコードに寄せます
  5. 個人名を外す … 依頼の本文に出てくる社員の名前を、「依頼者」「部長」のような役割に置き換えます

3番目の辞書は、最初から完全に作ろうとしないでください。 最初は施設係が思いつく20組ほどで始め、「前例が見つかりませんでした」になった依頼の言葉を毎月見て足していきます。 辞書を更新しても、検索の側の分析器で updateable を有効にしてあれば、索引を作り直さずに反映されます。

2番目を飛ばすと、0円の依頼で中央値が実際の相場より下がります。

Step5

AIに処理させる

AIの仕事は、上位5件の依頼について、何をしたか・手配先・つまずいた点を、対応記録の引用付きでまとめることだけです。 似た依頼を探すのも、費用と日数を数えるのも検索基盤で行います。

させること中身
似た依頼ごとのまとめ依頼の中身と、実際に何をしたかを、依頼の本文と完了時のメモから引用して書く
手配先の書き出しどこに頼んだかを、記録のまま書く
つまずいた点の書き出し完了時のメモにある、申請・日程・搬入・追加の費用の話を引用する
今回との違いの書き出し拠点、フロア、規模、時期のどこが違うかを書く
させないこと理由
費用や日数の目安を書く数字は集計の値をそのまま出す
手配先を勧める選ぶのは総務。取引の条件や相見積の決まりがある
工事に申請や届出が要るかの判断記録にあれば引用するだけ。要否はビルの管理会社と確かめる
記録に無いつまずきを想像で足す一般的なオフィスの知識で補わない

1行目が、いちばん外せない線です。 前例の文に「約15万円」と書かれていれば、AIはそれを目安として書きたくなります。1件の金額を目安にしてしまうのは、第3章の(b)で人がしていた失敗そのものです。 数字は集計の欄だけに出します。

3行目の申請の要否も、記録の引用にとどめます。 ビルが違えば決まりが違い、本社のビルの前例から「申請が必要です」と書けば、支店で要らない手間を作ります。

Step6

指示内容を固定する

あなたは総務部の施設係で、新しい依頼の対応のために過去の似た依頼を整理する係です。
渡された検索結果(過去の依頼の本文と完了時のメモ)だけを根拠にしてください。
一般的なオフィスや工事の知識で補わないでください。

【新しい依頼】
拠点:{site} フロア:{floor} 種類:{category} 希望の時期:{wanted_by}
依頼の本文:{body}

【検索結果】
依頼番号ごとに、依頼の本文、何年前の依頼か、拠点とフロア、手配先、完了時のメモが渡されます。

【依頼ごとに書くこと】
1. 依頼番号、何年前か、拠点とフロア
2. 依頼の中身と、実際に何をしたか(本文とメモから引用)
3. 手配先(記録のまま)
4. つまずいた点(メモから引用。無ければ「メモに記載なし」)
5. 今回の依頼との違い(拠点、フロア、規模、時期)

【厳守事項】
- 費用、金額、日数、期間を一切書かないでください。引用する文に含まれていても、
  その部分は「(金額は集計欄を参照)」に置き換えてください。
- 手配先を勧めないでください。「〜に頼むとよい」と書かないでください。
- 申請や届出が必要かどうかを判断しないでください。
  メモに書かれていれば「当時のメモには〜と記載」と引用の形で書いてください。
- 拠点が違う依頼には、必ず「拠点が違う」と今回との違いに書いてください。
- メモに無いつまずきを想像で書かないでください。

金額を「置き換える」まで指示しているのは、 禁止しても引用ごと写してくるためです。数字は集計の欄の1か所に絞ります。

検索結果は、Claude の検索結果ブロックで渡します。 依頼1件を1つの search_result にし、source に依頼番号、title に何年前か・拠点・種類、content に依頼の本文と完了時のメモを入れます。公式の説明では、検索結果ブロックは Claude API、Amazon Bedrock、Google Cloud で使え、引用は content の中のテキストブロック単位です。本文とメモを別のブロックに分けて渡すと、つまずいた点の引用がメモから来たことが分かります。

Step7

出力形式を固定する

検索と集計は、1回の要求で行います。

POST /facility-requests/_search
{
  "size": 5,
  "query": { "bool": {
    "must": [
      { "multi_match": { "query": "会議室 モニター 壁掛け 設置",
          "fields": ["title^2", "body", "notes"] } }
    ],
    "should": [ { "term": { "site": "本社" } } ],
    "filter": [ { "range": { "completed_on": { "gte": "now-3y/d" } } } ]
  } },
  "aggs": {
    "top_similar": {
      "sampler": { "shard_size": 20 },
      "aggs": {
        "cost_with_amount": {
          "filter": { "range": { "cost": { "gt": 0 } } },
          "aggs": { "cost_pct": { "percentiles": { "field": "cost", "percents": [25, 50, 75] } } }
        },
        "days_pct": { "percentiles": { "field": "lead_days", "percents": [50, 90] } },
        "vendors": { "terms": { "field": "vendor", "size": 5 } }
      }
    }
  }
}

sampler で、集計を点数の高い文書に絞ります。 公式のドキュメントでは、sampler は各シャードで点数の高い文書だけに下位の集計をかけるもので、shard_size は1シャードあたりの件数(既定は100)です。この索引は数千件なので1シャードで作り、shard_size の20がそのまま「似た依頼の上位20件」になるようにします。

中央値と幅は percentiles で出します。 公式のドキュメントでは、percentiles は近似の値とされています。20件ほどの集計なので大きくはずれませんが、画面では「約」を付けて出します。

依頼フォームに付けるコメントの元になる形は、次のJSONです。

{
  "request_id": "REQ-2026-1184",
  "estimate": {
    "basis_count": 20, "cost_count": 16,
    "cost_p25": 82000, "cost_p50": 118000, "cost_p75": 164000,
    "days_p50": 9, "days_p90": 21
  },
  "vendors": [ { "vendor": "V-0231", "count": 7 }, { "vendor": "V-0088", "count": 4 } ],
  "similar": [
    { "request_id": "REQ-2024-0912", "years_ago": 2, "site": "本社", "floor": "8F",
      "vendor": "V-0231", "summary": "", "stumbles": "", "differences": "",
      "quote_link": "", "citations": ["REQ-2024-0912"] }
  ],
  "not_found": false
}

1つ目の理由は、estimate をAIの答えと別の場所に持てることです。 集計の値は Lambda が検索の結果から写し、Claude の答えは similar の文の項目にだけ入ります。basis_count と cost_count で、何件から出した数字かも一緒に見せます。 16件中の中央値と、3件中の中央値は、同じ重さではありません。

2つ目は、vendors で手配先の顔ぶれを件数付きで出し、相見積の先を決めやすくできることです。

Step8

システムへ連携する

つなぎ先方式内容
依頼フォーム(完了)完了の通知の受け取り(個別の実装)完了した依頼を取り込む
依頼フォーム(受付)受付の通知の受け取り(個別の実装)新しい依頼で検索を動かす
Amazon OpenSearch Service索引への登録と、検索・集計似た依頼と、費用・日数・手配先の集計を返す
Claude(Amazon Bedrock)Lambda からの呼び出し上位5件を引用付きでまとめる
依頼フォーム(コメント)コメントの書き込み(個別の実装)担当向けのコメントを付ける
共有フォルダリンクのみ見積書の原本へのリンクを添える

依頼した部署には、コメントを見せない設定にします。 担当向けのコメントには、手配先の名前と過去の金額が入ります。依頼フォームの製品がコメントの公開範囲を分けられない場合は、コメントではなく施設係の共有の画面に出します。

Step9

人が確認する

この構成の確認は、必須です。 前例を読んで手配先を決め、目安を返すのは担当です。

  1. 何件から出した目安かを見る … cost_count が5件に満たないときは、目安として返さず、見積を取ってから返します
  2. 前例の年を見る … 3年前の前例は、物価と手配先の事情が変わっています
  3. 拠点の違いを見る … 別の拠点の前例は、手配先が対応できる地域かを確かめます
  4. 依頼した部署へ返す … 「過去の似た依頼では約○円〜○円、完了まで約○営業日」と、幅で伝えます。1つの金額で伝えません

1件あたり6分を目安にします。

Step10

例外に対処する

起きること対応
似た依頼が1件も当たらない「前例は見つかりませんでした」とコメントし、依頼の言葉を辞書の見直しの一覧に入れる
当たるが、費用の入った依頼が少ない目安の欄に「件数が少ないため目安を出しません」と出す
依頼の文が短すぎる検索せず、詳しく聞いてから再検索するよう案内する
依頼が2つ以上の内容を含む「レイアウト変更と電源の追加」のような依頼は、担当が分けて再検索する
手配先がすでに取引をやめている取引先の一覧に取引停止の印があれば、手配先の集計に「取引停止」と添える
Bedrock の呼び出しに失敗した集計の値と、上位5件の依頼番号・件名・手配先だけをコメントする
OpenSearch の検索に失敗した「前例の検索に失敗しました」とコメントし、担当は従来どおり探す

5行目は、手配先の集計だけを見て頼むと起きます。 取引先の一覧の状態を、集計に添えます。

Step11

記録を残す

  • 取り込んだ依頼の番号と完了日、取り込んだ日時
  • 検索の入力(依頼の文)、返した依頼番号、集計の値とその元になった件数
  • Claude に渡した検索結果と、返ってきたまとめと引用
  • 「前例は見つかりませんでした」になった依頼の言葉
  • 同義語の辞書の更新の履歴(いつ、どの組を足したか)
  • 担当が実際に頼んだ手配先と、かかった費用と日数

最後の行は、そのまま次の前例として取り込まれます。 完了時のメモを書く習慣が、次の担当の検索の質になります。

04実装レベルの3段階

最小構成:100件の依頼をAIサービスに貼り、似た依頼を挙げさせる / 前例が引けるかの確認
半自動化:上記+依頼を索引に取り込み、施設係が画面で言葉の検索と費用・日数の集計を見る / 前例と目安の調べ出し
本格構成:上記+依頼の受付で自動に検索し、引用付きのまとめを依頼フォームにコメントする。同義語の辞書を毎月更新する / 前例の調べ出しから担当への提示までの全体

半自動化で、①と②の時間は大きく減ります。 ただし担当が検索の画面を開いて依頼の言葉を入れ直す手間と、つまずいた点を読み比べる手間が残ります。本格構成で1件6分になり、この段階が本記事の想定です。 難易度★2の構成なので、半自動化までは小さく作れます。 生成AIを使わず、検索と集計の画面だけでも、第3章の(b)の「1件の金額を目安にしてしまう」問題は解けます。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
4 名
月間件数
90 件
1件あたり現在時間
20 分
1件あたり導入後時間
6 分
現在  90件 × 20分 ÷ 60 = 30 時間/月
導入後 90件 × 6分 ÷ 60 = 9 時間/月
月間削減時間
21h
削減率
70%
年間削減時間
252h
年間金額換算(時間単価3,000円)
76万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 複数の拠点やフロアを持つ従業員数百名規模の会社で、総務に「会議室にモニターを付けたい」「席を島ごと移したい」「コンセントを増やしたい」といった依頼が月に数十件から百件ほど届き、対応の記録と業者の見積が数年分たまっているのに、手配先と費用の目安を前任者のメモや記憶で探している場合。依頼を社内の依頼フォームやワークフローの仕組みで受け付けており、完了時に手配先・費用・完了日を記録している場合。AWS を使っている場合。
向いていない
  1. 依頼が月に数件で、担当が全件を覚えていられる場合。対応の記録に手配先や費用が残っておらず、件名だけの一覧になっている場合(先に完了時の記録の欄をそろえる必要がある)。建物の設備をビルの管理会社がすべて受けており、総務が手配をしない場合。なお、発注先の選定と金額の決定は総務と決裁権限を持つ者が行い、この構成はそれを代わりに行いません。

07最小構成で試す方法

  1. 過去1年の完了した依頼から、費用と手配先の入ったものを100件書き出す
  2. 施設係に、最近の依頼を10件選んでもらう(その10件は100件から外しておく)
  3. 手元のAIサービスに100件を貼り、10件の依頼の本文を1件ずつ入れて「似た依頼を5件、手配先と完了時のメモを添えて挙げてください。金額は書かないでください」と指示する
  4. 挙がった5件が、施設係から見て「確かに似ている」かを数える
  5. 挙がった5件の費用の幅を手で計算し、実際にかかった費用と比べる
出てきた内容判断
10件のうち多くで、似た依頼が挙がり、費用の幅に実際の金額が入る索引と集計の構築に進む
似た依頼は挙がるが、言葉の揺れで落ちる依頼がある同義語の辞書で直る。構成は有効
完了時のメモが空で、つまずいた点が出ない完了時のメモの書き方が先。 検索の問題ではない

5番目の比べ方が、この試しの中心です。 実際の金額が幅の外に出た依頼は、何が違ったのかを施設係で話します。夜間の作業、急ぎの手配、ビルの指定業者といった理由が出てきたら、それがそのまま完了時のメモに書くべきことです。

08実装時につまずきやすいポイント

問題対策
件名の言葉が合わず前例が当たらない本文と完了時のメモも検索の対象にし、同義語の辞書で揺れを吸収する
1件の金額を目安にしてしまう上位20件の中央値と幅を集計で出し、件数も見せる
集計が似ていない依頼まで含むsampler で点数の高い文書に絞る
シャードを増やしたら集計の件数が変わったshard_size は1シャードあたり。索引は1シャードで作る
0円の依頼で中央値が下がる費用0円を集計から外す
AIが金額を書く金額の置き換えを指示し、目安は集計の欄だけに出す
AIが申請の要否を判断する記録の引用にとどめ、ビルの管理会社と確かめる
辞書を更新しても反映されない検索の側の分析器で updateable を有効にしておく
依頼した部署に過去の金額と手配先が見えるコメントの公開範囲を担当に限る

上の3行が、この構成の失敗のほとんどです。 前例が当たらなければ何も始まらず、当たっても1件の金額で返せば、いまの手作業と同じ失敗が速くなるだけです。 言葉の揺れと、幅で返すことの2つを先に固めます。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 社内の依頼の内容、拠点とフロア、手配先と取引の金額、完了時のメモです。メモには、入退室のカードや鍵、防犯カメラの設置場所の話が含まれることがあります。

  1. 取引の金額と手配先は、施設係だけが見る … 依頼した部署や他部署の社員が、業者ごとの過去の金額を見られる状態にしません
  2. 防犯に関わる依頼は索引から外す … 鍵の交換、入退室の設定、防犯カメラの設置の依頼は、本文とメモに建物の弱いところが書かれていることがあります。 種類で取り込みの対象から外すか、施設係の責任者だけが見られる別の索引にします
  3. AIのまとめを、業者への発注の根拠にしない … 発注は、相見積の決まりと決裁の手順に従います
  4. 個人名を外す … 依頼の本文の社員の名前を、取り込みで役割に置き換えます
  5. 同義語の辞書を秘密の置き場にしない … 辞書のファイルは S3 に置いて取り込みます。辞書そのものに機密は無くても、置き場の権限は施設係と情報システムに限ります

誤りが起きた場合のリスクは、少ない前例や古い前例の金額を、依頼した部署に目安として返してしまうことです。 予算がその金額で取られると、後から足りなくなります。件数と年を必ず添え、幅で返すことで防ぎます。

10まず何から始めるか

1週目:完了時の記録を確かめる

過去1年の完了した依頼を50件開き、手配先・費用・完了時のメモがどれだけ入っているかを数えます。メモが空の依頼が多ければ、完了時にメモを書く決まりを今週から始めます。

2週目:100件で試す

費用と手配先の入った依頼を100件書き出し、手元のAIサービスで似た依頼を挙げさせます。似た依頼が当たるか、言葉の揺れで落ちる依頼がどれかを最優先で見ます。

3週目:同義語の辞書の最初の20組を作る

2週目で落ちた依頼の言葉から、施設係で20組ほどの同義語を書き出します。完璧にしようとせず、毎月足していく前提で始めます。

4週目:索引を作り、検索と集計の画面を使う

過去3年分の依頼を取り込み、施設係が画面で言葉の検索と費用・日数の集計を見られるようにします。依頼が届くたびに、担当がこの画面を開いてから見積を頼みます。

2か月目: 依頼の受付での自動の検索と、Claude の引用付きのまとめを足し、依頼フォームにコメントを付けます。3か月目以降: 「前例は見つかりませんでした」の言葉を毎月見て辞書を更新します。依頼した部署に費用と日数の目安を幅で返すまでの時間が、前任者に聞かずに済む長さに収まった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-08/最終更新:2026-10-08
確認した内容情報源確認日
Amazon OpenSearch Service が OpenSearch 3.5、3.3、3.1 などのバージョンに対応していることAmazon OpenSearch Service: What is Amazon OpenSearch Service?2026-10-08
対応プラグインの一覧で、Sudachi Analysis が日本語向けに推奨されていること。オプションのプラグインをドメインに関連付けて使うことAmazon OpenSearch Service: Plugins by engine version2026-10-08
同義語などの辞書ファイルを S3 からパッケージとして取り込み、ドメインに関連付けて synonyms_path に analyzers/<ID> で指定できること。検索の側の分析器で updateable を true にすると、辞書の更新が自動で反映されること。Sudachi の辞書を additional_settings で指定する例Amazon OpenSearch Service: Importing and managing packages2026-10-08
sampler が各シャードで点数の高い文書だけに下位の集計をかけ、shard_size が1シャードあたりの件数(既定100)であることOpenSearch Documentation: Sampler aggregation2026-10-08
percentiles が数値の項目の分位点を返し、値が近似であること。percents で返す分位点を指定できることOpenSearch Documentation: Percentile aggregation2026-10-08
検索結果ブロック(source・title・content)で引用付きの答えが返り、Claude API、Amazon Bedrock、Google Cloud で使えること。引用がテキストブロック単位であることClaude Docs: Search results2026-10-08

発注先の選定と金額の決定は、自社の購買と決裁の手順に従ってください。 本記事は公開仕様で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1039)についてのご相談はこちらから。

AI活用について相談する
目次