新しいシステムの選定を始めるときに、過去のRFP・ベンダーの提案書・評価表から要件の近い案件を探し、出した要件と評価の分かれ目を根拠付きで情報システムの担当に返す

処理の起点を決める

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

取り込みは、選定結果の稟議の決裁を起点にします。 選定が終わった案件だけを取り込むのは、評価の途中の点や、選定が終わる前の提案書を、他の案件の担当に見せないためです。 稟議の仕組みから決裁済みの案件の番号を毎晩受け取り、その案件のフォルダを Lambda が取り込みます。

導入後の振り返りは、委託先の管理台帳への添付を起点に取り込み直します。 振り返りは稼働の半年後に入るので、取り込み済みの案件のカードに、後から振り返りを結び付ける形になります。結び付けは案件の番号で行います。

過去10年の約400案件は、別に一括で取り込みます。 このときは評価表の書式の読み替えがうまくいかない案件が出るので、読み替えられなかった評価表には「点の開き未計算」の印を付け、要件のカードだけを先に検索できるようにします。

検索は、選定の起案の登録で動きます。 起案が保存されたら Lambda が動き、結果を起案に添付します。担当がRFPを書き進めながら条件を変えて探し直せるように、検索画面からも同じ検索を呼べるようにします。

入力データを集める

提案書の本文は、検索の対象に入れません。 提案書は、ベンダーが自社の製品を説明するために書いたものです。要件の近さで探すなら、自社が書いたRFPと評価表のほうが、言葉がそろっています。 提案書は、検索結果から根拠として開く先として、案件のフォルダへのリンクだけを持たせます。

質を決めるのは、評価表の読み替えと導入後の振り返りです。 評価表が読み替えられないと、点の開きが計算できず、評価の分かれ目が出せません。 振り返りが結び付かないと、前回困った要件が、ふつうの要件と同じ顔で並びます。

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

RFPの要件一覧と評価表は、表計算のファイルから行ごとに取り出します。ここは生成AIを使わず、プログラムで読みます。 列の位置が案件ごとに違うので、見出しの文字で列を探す対応表を持ちます。

検索時には、起案から2種類の問い合わせを作ります。 1つは業務の言葉とシステムの通称（同義語で広げたもの）の言葉の一致、もう1つは要件の箇条書きの埋め込みによる近さです。この2つをハイブリッドクエリのサブクエリにし、filter でカードの種類と公開範囲を絞ります。filter はすべてのサブクエリに効き、条件が複数あるときは bool クエリで包みます。

要件の箇条書きは、1行ずつ別の問い合わせにします。 起案に「代理承認ができること」「承認の経路を部署ごとに変えられること」と並んでいたら、それぞれに近い過去の要件を探します。 箇条書きをまとめて1つの埋め込みにすると、どの要件にも中くらいに近い案件ばかりが上に来ます。

AIへ渡す前に整形する

1. 要件の行への分割 … RFPの要件一覧を1行1枚のカードにします。カードには案件の番号、業務の分類、要件の区分、必須か任意かを持たせます
2. 評価表の読み替え … 項目名・配点・点・コメントの列を、対応表で共通の形に直します。読み替えられない評価表は「点の開き未計算」にします
3. 点の開きの計算 … 項目ごとに、ベンダー間の最高点と最低点の差を配点で割り、開きの割合を出します
4. 分かれ目の項目の決定 … 開きの割合が大きい順に上位5項目を、その案件の分かれ目の項目とします
5. 振り返りの結び付け … 案件の番号で振り返りを引き、問題になった要件の番号のカードに注意の印を付けます
6. 埋め込みの対象を絞る … 要件の文と評価のコメントだけを埋め込みます。点と配点は数値の項目として持ちます
7. 価格の項目の切り分け … 見積の金額と価格の評価のコメントは、別の項目に分けて持ちます

3番目と4番目は、AIにさせません。 点の開きは引き算と割り算で決まります。ここをAIに読ませると、コメントの書きぶりが強い項目を「決め手」と書いてきます。 コメントが丁寧なことと、点が割れたことは別の話です。

7番目は、第13章の見せる範囲の話です。 価格は、他のベンダーに知られてはいけない情報で、案件の担当以外が見る必要もほとんどありません。項目を分けておけば、検索基盤の項目単位の制限で隠せます。

同義語の辞書は、Sudachi の辞書として登録します。 ドキュメントでは、Sudachi の辞書ファイルを関連付け直してもすぐにはドメインに反映されず、次のブルー／グリーンデプロイで更新されるとされています。すぐ反映したいときは、新しいパッケージで新しいインデックスを作って再インデックスし、インデックスのエイリアスを切り替えます。 辞書の更新は月に1回にまとめます。

AIに処理させる

AIの仕事は2か所です。取り込み時の論点の取り出しと、検索結果のまとめです。

2行目がいちばん起きやすい失敗です。 評価表をそのまま渡すと、AIは長いコメントの付いた項目を分かれ目として挙げます。長いコメントは、たいてい全社が同じ点だった項目に付いています。 説明が要ったのは、差が付かなかった理由を書いたからです。

指示内容を固定する

取り込み時（論点の取り出し）：

あなたは情報システム部で、選定が終わった案件の記録を整理する担当です。
渡された評価のコメントと導入後の振り返りだけを根拠にしてください。
推測で埋めないでください。

【評価のコメントから取り出すもの】
- 項目ごとに、評価者がベンダー間の差として書いたこと
- 差の理由として書かれた具体的な事実（機能の有無、体制、実績、デモの結果など）

【振り返りから取り出すもの】
- 問題になった要件の番号と、何が起きたか
- 振り返りに「こう書いておけばよかった」と書かれていれば、その文

【厳守事項】
- 評価の項目の重要さを、あなたが判断しないでください。
  渡された項目を、渡された順に扱ってください。
- 書かれていない欄は null にしてください。他の欄から補わないでください。
- 価格・見積の金額は取り出さないでください。
- ベンダーの社名は、渡されたベンダーの記号（A社、B社）のまま書いてください。
- 振り返りに要件の番号が無ければ、requirement_no を null にしてください。

検索時（結果のまとめ）：

あなたは、システムの選定を起案した担当を助ける担当です。
渡された検索結果だけを根拠に、起案と過去の選定案件を比べてください。

【起案】{proposal}

【書くこと】
1. 起案の要件ごとに、近い過去の要件の文（どの案件の何番か）
2. 各案件の評価の分かれ目の項目と、そこで差になった理由
3. 導入後の振り返りで問題になった要件と、何が起きたか
4. 各案件と起案の範囲の違い（業務の範囲、利用者の数、基盤）

【厳守事項】
- どのベンダーや製品がよいかの結論を書かないでください。
- 分かれ目の項目は、検索結果で「分かれ目」と印のあるものだけを挙げてください。
- 新しい要件の文を書き起こさないでください。
- 価格や金額に触れないでください。
- 「点の開き未計算」の印のある案件は、その旨を必ず書いてください。
- 近い案件が1件も無ければ、「近い過去の選定案件は見つかりませんでした」と書いてください。

検索結果は、Claude の検索結果ブロックで渡します。 1つの案件を1つの search_result にし、source に案件の番号、title に案件名と決裁日、content に要件のカード、分かれ目の項目のコメント、振り返りを、1つずつ別のテキストブロックとして並べます。引用を有効にすると、まとめの文ごとに、どの検索結果のどのブロックを根拠にしたかが付きます。

ブロックを細かく分けるのは、引用の単位がブロックだからです。 ドキュメントでは、引用の位置はブロックの範囲で返り、内容を1つのブロックにまとめると、どの引用でも全文が返るとされています。案件を1つのブロックにすると、どの文を引用しても案件のすべてが返ってきます。

「分かれ目は印のあるものだけ」を明記しないと、AIは自分で分かれ目を探し直します。 前処理で点の開きから決めた項目より、コメントの印象が強い項目を挙げてきます。 機械で決めたことを、文章でひっくり返させないための1行です。

出力形式を固定する

取り込み時の論点は、次の形のJSONで受け取ります。 Lambda が形を確かめ、欠けた項目があれば取り込みを止めて一覧に出します。

{
  "project_id": "SEL-2021-034",
  "split_items": [
    { "item_no": "E-17", "gap_ratio": 0.6, "point": "", "facts": [] }
  ],
  "post_issues": [
    { "requirement_no": "F-042", "what_happened": "", "lesson_text": null }
  ]
}

gap_ratio は前処理で計算した値を Lambda が入れます。AIが埋めるのは point と facts と post_issues の文だけです。

検索結果は、Lambda が組み立てた次の形で起案に添付します。

{
  "proposal_id": "PRP-2026-10-021",
  "matches": [
    {
      "project_id": "SEL-2021-034",
      "decided_on": "2021-11-18",
      "requirement_hits": [
        { "query_line": 1, "requirement_no": "F-018", "score": 0.82 }
      ],
      "split_items": ["E-17", "E-22"],
      "summary": "",
      "citations": [ { "project_id": "SEL-2021-034", "block": "評価 E-17" } ],
      "gap_uncomputed": false
    }
  ],
  "caution_requirements": [
    { "project_id": "SEL-2021-034", "requirement_no": "F-042" }
  ],
  "not_found": false
}

1つ目の理由は、AIの文と機械の値を分けられることです。 summary はAIが書き、split_items と requirement_hits と caution_requirements はカードと計算から機械で入れます。何で決まったか、何が問題になったかを、AIの言い回しに頼らずに読めます。

2つ目は、引用を文書の場所まで戻せることです。 Claude が返す引用の位置（search_result_location）には、検索結果の番号とブロックの範囲が入ります。Lambda がそれを案件の番号と要件・評価の番号に置き換え、citations に入れます。 担当は「SEL-2021-034 の評価 E-17」の行をそのまま開けます。

3つ目は、注意の要件を caution_requirements に分けられることです。 前回困った要件がふつうの要件と同じ並びにあると、上から順に写して、困った書き方をそのまま持ち込みます。 別の欄にすれば、担当はRFPを書く前に先に読めます。

引用付きのまとめと構造化出力は、1回の呼び出しで両方は求めません。 引用はまとめの文に付けて受け取り、JSONの組み立ては Lambda が行います。

システムへ連携する

文書管理にも、稟議にも、委託先の管理台帳にも書き込みません。 この構成が書き込むのは、検索基盤のインデックスと、起案への添付だけです。文書の正本は文書管理の仕組みに残し、検索結果からはそこへのリンクで戻ります。

人が確認する

AIのまとめをそのままRFPに写す運用にはしません。 担当が次の順で確かめます。

1. caution_requirements を先に読む … 前回問題になった要件は、振り返りの原文で何が起きたかを確かめます
2. 分かれ目の項目の根拠を開く … citations から評価表の行を開き、まとめと点・コメントに食い違いがないかを見ます
3. 範囲の違いを自分で確かめる … 利用者の数、つなぐ先のシステム、規制の変更など、前回と今回で違う条件を書き出します
4. 使った要件を起案に記録する … どの案件の何番の要件を参考にし、どれを採らなかったかを残します

取り込み時の論点も、確かめる人を決めます。 新しく決裁された案件の論点は、その案件の担当に取り込みの翌週に送り、取り違えがないかを見てもらいます。 過去分は、検索で参考に選ばれたときに、その場で確かめます。

例外に対処する

1行目を守ることが、信頼を保ちます。 新しい種類のシステムで前例が無いときに、遠い案件を3件並べると、担当は次から結果を読まなくなります。 「無い」と返すことも、社内に前例が無いという情報です。

記録を残す

• 取り込んだ案件の文書の版と、取り出したカードと論点（どのモデルで取り出したかを含む）
• 評価表の読み替えに使った対応表の版と、点の開きの計算結果
• 検索のたびの問い合わせ、同義語で広げた後の言葉、ハイブリッドクエリの上位の結果とスコア
• Claude に渡した検索結果と、返ってきたまとめと引用の位置
• 担当が参考に選んだ要件と、選ばなかった要件
• 誰が、どの案件の結果を見たか

最後の行は、第13章の提案書の扱いのためです。 提案書を預かったときの取り決めで、利用の範囲が問われたときに、どの案件の結果を誰が見たかを示せるようにしておきます。