OpenAI File Searchの回答を、チームで使える記録にする

契約書や社内規程をOpenAI File Searchで検索できれば、Agentは資料に基づいて質問に答えられます。しかし、チームがその回答を仕事で使うには、どの資料が根拠なのか、誰が結論を確認したのか、次回どの記録を読むべきかも必要です。

回答をチャットに貼り付けるだけでは、引用と判断が離れがちです。一方、そのまま業務表を書き換えると、検索で見つけた記述が確認済みの事実として扱われる可能性があります。根拠、変更提案、採用した記録をつなぐ設計が役立ちます。

File Searchを検索に、Busabaseを構造化記録と変更履歴に利用できます。両者を接続するアプリケーションやAgent側で、取得、項目への対応付け、書き込みを明示的に実装します。

回答と引用と検索結果を分けて扱う

OpenAIのFile Searchガイドによると、File SearchはResponses APIのホスト型ツールです。vector storeに登録したファイルを意味検索とキーワード検索で調べます。ファイルの索引作成を確認してから、toolsにfile_searchとvector_store_idsを指定します。

応答にはfile_search_callとmessageが含まれ、回答のfile_citation注釈からfile_id、filename、引用位置を取得できます。画面に表示する脚注番号からファイルを推測せず、構造化された注釈を保存します。

検索結果そのものは既定では返りません。レビュー用に取得するなら、include: ["file_search_call.results"]を指定します。引用は参照ファイルとの対応を、検索結果は根拠箇所の確認材料を提供します。どの主張を支持できるかは、内容を確認して判断します。

根拠と結論を別の記録として保存する

小さく始めるなら、Folder内に「根拠」と「結論」の二つのBaseを設けます。既存の業務表が結論を管理している場合は、その表を再利用します。これは用途に合わせて調整する初期設計です。

根拠表には短いタイトル、ファイル識別子とファイル名（text）、参照先（url）、関連箇所（longtext）、取得日時（date）、応答識別子（text）を保存します。file_idは一般公開のダウンロードURLではありません。参照先には、担当者がアクセスできる原資料の入口を記録します。

結論表には質問、現在の結論、根拠へのrelation、業務上の状態、責任者を保存します。一つの結論から複数の根拠を参照できます。「確認中」「確認済み」は業務状態であり、CRのin_review、approved、mergedとは別に扱います。

同じファイル名でも中身が変わることがあります。原本側にバージョン番号や内容のハッシュがあるなら、取得日時とともに残します。後から何を根拠にしたか追えることが重要です。

提案前に現在の記録を読む

Agentは回答を得た後、既存の結論と現在のバージョンを読みます。根拠の追加、古い判断の修正、新しい質問への回答のどれかを区別します。同じ主題の安定した識別子で検索し、毎回似た記録を作らないようにします。

接続済みのAgentには、次のように依頼できます。

このFile Search応答、構造化された引用、取得済み検索結果を読んでください。指定した根拠表と結論表から同じ主題を探し、主張ごとに根拠箇所とファイル識別子を対応付けてください。矛盾は残し、欠けた条項を推測しないでください。現在の値とバージョンを読み、根拠のある項目だけ変更提案にして入口を返してください。

この依頼には実際のツール接続が必要です。Busabase MCPは接続方法を提供しますが、OpenAIのファイル権限とBusabaseの記録権限はそれぞれ設定します。片方へのアクセスで他方まで許可されるわけではありません。

必ず待つ書き込みを権限で定める

Busabase Change Requestsは差分とコミット履歴を保存します。提案専用のchangeRequest権限ではレビュー待ちになります。write権限があると、作成直後にマージされる場合があります。人の確認を必須にするには提案専用権限、または対応する呼び出しで明示的なautoMerge: falseを使います。

担当者は、変更項目を原文が支持しているか、資料が現在も適用されるか、反対の記述がないかを確認します。根拠不足なら追加調査を求めます。作成中に他の担当者が記録を変えていた場合は、提案の基準バージョンも見直します。

承認とマージは実際の状態を別々に確認します。マージ後はcanonical記録を再読し、結論と根拠への関係が一致しているか確かめます。役割の整理にはAgentの記憶・知識ベース・記録システムも参考になります。

次回の処理が読む対象を決める

通常の実行ではマージ済み結論と関連根拠を読みます。保留提案は明示されたレビュー工程で扱います。業務の実行に「確認済み」などの条件が必要なら、それも別途検査します。mergedという状態だけで外部操作の許可まで与えたことにはなりません。

資料更新後は再検索し、採用済み結論と比較して新しい提案を作ります。タイムアウト時は元の提案と現在の記録を探してから再試行します。応答識別子と主題識別子があれば重複作成を避けやすくなります。

一つの実際の質問で引き継ぎを確かめる

参照できる資料、既存記録、判断する担当者がそろう質問を選びます。索引完了、引用との対応、保留時の旧値、マージ後の再読を順に確認します。外部送信や業務操作には既存の許可を適用します。

この手動の一巡を確認してから、自動化と資料範囲を広げます。目指す成果は、別の担当者やAgentが根拠ごと確認して使い続けられる結論です。