社員と情シスの担当から出る「このPC・スマホ・ソフトは標準か、何を申請すればよいか」の質問に、社内標準構成と調達ルールを根拠にチャットで答え、標準外の相談を情シスへ回す

処理の起点を決める

社員がチャット画面で質問を送ったことを起点にします。 定時の一括処理はありません。端末の申請は思い立ったときに出すもので、答えが翌日になると、社員は待たずに担当へメールを送ります。メールとチャットの二重の問い合わせになり、かえって件数が増えます。

入口は社内ポータルのチャット画面の1つに絞ります。メールで届いた質問は、担当がチャット画面に転記して答えを確かめ、その答えを返信に使います。 入口を分けたままにすると、メールで届く質問だけが記録に残らず、どの質問が多いかが数えられません。

もう1つの起点は、文書の改訂です。 標準構成表や許可一覧を改訂して Cloud Storage に置き直したときに、メタデータを付け直して取り込みをやり直します。改訂の当日に取り込みが終わっていないと、旧版で答える期間ができます。

入力データを集める

質を決めるのは、各文書に付けるメタデータです。 本文だけを入れると、検索は旧版と新版を区別できず、事務職向けの記載と設計職向けの記載を同じ重さで拾います。付けるのは、文書の種類・版・適用開始日・適用終了日・対象の職種・対象の拠点・状態（有効／廃止）の7つです。

許可一覧は、表のまま入れます。 製品名と区分の行が崩れると、「禁止」の行の製品を「標準」と答える誤りが出ます。公式のページでは、レイアウトの解析は PDF・HTML・DOCX・PPTX・XLSX・XLSM を扱い、表を要素として検出するとされています。

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

文書の取り込みは、Cloud Storage のバケットに原本とメタデータを置き、データストアに読み込ませます。データストアは、社員向けと担当向けを分けずに1つにし、文書ごとの閲覧者で見せ分けます。

見せ分けには、データソースのアクセス制御を使います。 公式のページでは、Cloud Storage の非構造化データでも、メタデータの acl_info に閲覧者（ユーザーまたはグループ）を書けば、検索した人が見られる文書だけが結果に出るとされています。ただし、アクセス制御はデータストアを作るときに選ぶもので、後から変えられません。 1文書あたりの閲覧者は最大3,000で、ユーザーとグループがそれぞれ1と数えられます。

社内の認証が Microsoft Entra ID などで、Google のアカウントに同期していない場合は、Workforce Identity Federation の設定が要るとされています。 ここは情報システム部の認証の構成によって手間が大きく変わるので、最初に確かめます。

絞り込みの式は、中継プログラムが質問者の情報から組み立てます。 公式のページでは、メタデータの項目をスキーマでインデックス可能にしたうえで、ANY で値の一覧と一致させ、AND ／ OR でつなぎ、日付は ISO 8601 の文字列と比較演算子で絞れるとされています。

status: ANY("有効")
AND job_type: ANY("設計", "全職種")
AND site: ANY("第二工場", "全拠点")
AND effective_from <= "2026-10-08"

「全職種」「全拠点」を値として持たせるのは、共通の規定を落とさないためです。 調達ルールの本文は全員に当てはまるので、職種で絞ったときに外れないようにします。

AIへ渡す前に整形する

1. 質問者の特定 … 認証の情報から社員番号を取り、人事の一覧で職種・拠点を引きます。引けない（派遣・業務委託の人など）ときは、職種の絞り込みをかけずに答え、答えの先頭にその旨を書きます
2. 個人情報の除去 … 質問に端末の資産番号や私用の電話番号が書かれていたら、記録に残す前に伏せます
3. 品目の言い換え … 「Excelが重い」「CADが落ちる」のような症状の質問は、標準構成の質問ではない可能性があります。障害の相談かどうかは answer メソッドに任せず、症状の語の一覧で先に分け、ヘルプデスクの窓口を案内します
4. 文書の取り込み前の整形 … 標準構成表のPDFは、職種ごとの表に見出しを付けて書き出します。見出しが無いと、表の途中で切られた断片から職種が分からなくなります
5. チャンクの設定 … 公式のページでは、チャンクの大きさは100〜500トークン（既定500）で、祖先の見出しをチャンクに含める設定（既定は無効）があります。有効にします。 表の途中のチャンクにも「設計職」「第二工場」の見出しが付きます
6. 版の整理 … 旧版の文書は削除せず、状態を「廃止」にして残します。過去の答えの根拠をたどるためです

5番目は取り込みのときにしか決められません。 公式のページでは、チャンク分けはデータストアを作った後に入り切りできないとされています。作り直しになるので、最初から有効にしておきます。

AIに処理させる

させるのは、絞り込まれた文書から質問に当てはまる記載を探し、出典付きで答えることだけです。

3行目の「一覧に無い」は、「禁止」とも「使ってよい」とも違います。 許可一覧に無いソフトは、調達ルールで「申請のうえ情報システム部が審査する」と決めている会社が多いはずです。AIが製品の評判から「一般に安全なソフトです」と書き足すと、審査を飛ばす理由になります。

指示内容を固定する

answer メソッドには、答え方の指示を前置き（promptSpec.preamble）として渡します。公式のページでは、口調・文体・詳しさを自然文で指示できるとされています。

あなたは情報システム部の窓口として、社内標準構成と調達ルールについての質問に答えます。
検索で見つかった社内文書だけを根拠にしてください。文書に無いことを推測で書かないでください。

【答え方】
- 最初の1文で結論を書く（標準の範囲／申請すれば可／標準外／禁止／文書に記載なし）。
- 次に、該当する品目、対象の職種と拠点、適用期間を書く。
- 申請が要る場合は、使う様式の名前と承認の経路を書く。
- 根拠にした文書の名前と版を、答えの最後に必ず書く。

【厳守事項】
- 文書に記載が無い場合は「文書に記載がありません」と書き、担当への相談を案内する。
  一般的な知識や製品の評判で補わない。
- ソフトウェアが許可一覧に無い場合は「許可一覧に記載がありません」と書く。
  安全かどうか、使ってよいかどうかを書かない。
- 標準外の申請が認められるかどうかを答えない。
  「標準外の申請には、調達ルールの○○の手続きが要る」と経路だけを書く。
- 職種や拠点によって答えが変わる場合は、質問者の職種と拠点に当てはまる記載だけを使う。
  質問者の職種が分からない場合は、職種ごとに分けて書く。
- 文書の間で記載が食い違う場合は、どちらかを選ばず、両方を示して担当への確認を案内する。
- 社員番号、資産番号、電話番号を答えに書かない。
- 価格、単価、代理店の名前は、検索で見つかっても社員向けの答えに書かない。

「一般的な知識や製品の評判で補わない」を書かないと、許可一覧に無いソフトについて、製品の一般的な説明を答えにします。 社員にとっては「使ってよい」と読めます。禁じるのは、文書の外の知識で空白を埋めることそのものです。

「価格、単価を社員向けの答えに書かない」を指示に入れているのは、二重の守りです。 本来は閲覧者の設定で担当向けの文書が社員の検索に出ないはずですが、メタデータの付け間違いが1件あれば単価が社員の画面に出ます。 中継プログラムの側でも、出典に担当向けの文書が混じっていたら答えを返さずに担当へ回します。

検索の側の設定もあわせて決めます。 公式のページでは、質問の分類（queryClassificationSpec）で、敵対的な質問（ADVERSARIAL_QUERY）と答えを求めていない質問（NON_ANSWER_SEEKING_QUERY）を見分け、ignoreAdversarialQuery ／ ignoreNonAnswerSeekingQuery で答えを作らないようにできるとされています。関連の薄い内容しか見つからないときに決まった文を返す設定（ignore_low_relevant_content）もあります。3つとも有効にし、 答えの言語は answer_language_code で日本語に固定します。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に詰め替えて画面と記録に渡します。

{
  "question_id": "",
  "asker": { "job_type": "設計", "site": "第二工場", "is_it_staff": false },
  "conclusion": "standard | apply_ok | non_standard | prohibited | not_in_documents",
  "answer_text": "",
  "items": [
    { "name": "", "category": "PC | phone | peripheral | software",
      "effective_from": "", "effective_to": "" }
  ],
  "application": { "form": "", "approval_route": "" },
  "citations": [
    { "document": "", "version": "", "status": "有効", "audience": "all | it_staff" }
  ],
  "support_score": 0.0,
  "route_to_staff": false,
  "route_reason": "low_support | non_standard | conflict | staff_doc_cited | symptom"
}

1つ目の理由は、conclusion で待ち行列を機械的に振り分けられることです。 non_standard と not_in_documents は答えを返したうえで担当にも知らせ、担当が後から文書に書き足すかを決める材料にします。

2つ目は、citations の status と audience で、答えを出す前に止められることです。 出典に 廃止 の文書が混じっていれば旧版の検知、社員への答えに it_staff の文書が混じっていれば閲覧の設定の誤りです。どちらも答えを画面に出さず、担当へ回します。

基準の値は、最初の1か月の記録から決めます。 根拠のスコアと担当の判定を並べて、誤った答えが出始める値を見ます。最初から値を決め打ちしません。

3つ目は、items の適用期間を画面に出せることです。 「この機種は2027年3月まで標準」と期間付きで出すと、社員が次の入れ替えの時期まで含めて申請を考えられます。

システムへ連携する

申請ワークフローへは書き込みません。 答えから申請を自動で起こすと、標準外の品目が「AIが案内したから」という理由で申請されます。申請は社員が自分で出し、承認はこれまでどおり上長と情報システム部が行います。

人事の一覧も読み取りだけです。職種が古いまま残っている社員がいても、この構成からは直しません。 答えの先頭に「職種：設計、拠点：第二工場として答えています」と出し、違っていれば社員が気づけるようにします。

人が確認する

人が見るのは、待ち行列に入った質問だけです。 文書に書いてあることへの答えは、社員が画面で読んで終わります。

1. non_standard の相談 … 標準外の申請の見込みを聞かれているもの。担当が調達ルールの例外の手続きを案内し、必要なら上長と相談します
2. 根拠の弱い答え … 根拠のスコアが基準に届かなかったもの。多くは文書に書かれていない質問で、担当が答え、文書に足すかを決めます
3. 文書の食い違い … 標準構成表と拠点の取り決めで記載が違うもの。どちらが正しいかを決め、文書を直します
4. 閲覧の設定の誤り・旧版の検知 … 取り込みとメタデータを直します

担当は月に1回、答えの記録から20件を抜き出して読みます。 待ち行列に入らなかった答えのなかに、根拠のスコアは高いのに質問とずれている答えがないかを見るためです。

目標は、300件をならして1件4分です。 待ち行列に入るのは2割から3割という想定で、それより多い月は、文書に書かれていない質問が増えているか、メタデータの付け方に抜けがあります。

例外に対処する

1行目の質問者は派遣・業務委託の人が多く、答える範囲が社員と違います。 調達ルールの「社員以外の端末」の項を必ず含めて答えます。

記録を残す

• 質問の文（個人情報を伏せた後）、質問者の職種・拠点、担当かどうか
• 送った絞り込みの式と、answer メソッドの応答の全文（答え・出典・根拠のスコア）
• 詰め替えた結果（conclusion、route_to_staff、route_reason）
• 担当が回された質問に返した答えと、文書の改訂の起票の有無
• そのとき有効だった文書の版の一覧
• 月ごとの not_in_documents の質問の一覧

5つ目を残すのは、標準構成表が改訂されるためです。 社員から「前に聞いたときは標準だと言われた」と言われたとき、当時の版で正しく答えていたのかを確かめられます。