1. モデルより先に、仕事の境界を決める
何を入力し、どんな結果を返し、誰が採否を判断するかを一組にします。合計・重複判定・定型転記のように規則が決まる処理は、固定処理で再現できるかを先に確認します。
- 入力と権限
- 機密区分、送信できる契約・地域、参照できる文書、サービスアカウントの権限。
- 出力と責任
- 下書きか、登録データか、対外送信か。原文との照合、形式・数値の検査、承認する担当者。
- 運用と停止条件
- 許容時間、処理量、月額上限、再実行、モデル変更時の確認、AIを使えない時の代替手順。
2. 必要な仕事に合わせて、接続方式を選ぶ
以下は構成を検討する入口です。複数の方式を組み合わせる場合も、権限と処理の責任を分けます。
| 方式 | 向く用途 | 構成・確認事項 |
|---|---|---|
| 人がアプリで確認 | 文書の下書き・要約など、少量で人が判断する仕事 | 承認済みの利用環境と入力範囲を決める。API連携が必要になる量・手間を測る。 |
| 業務APIから呼び出す | 画面内の下書き・分類など、応答を待てる仕事 | 業務側で認証・入力検査し、モデルを呼び出す。タイムアウト時は未完了として扱い、結果の形式を検査する。 |
| キューとワーカー | 大量文書・夜間処理など、即時応答が不要な仕事 | 受付IDと処理状況を保存。実行量、再試行の上限、失敗の隔離、同じ業務データの二重更新を防ぐキーを決める。 |
| 検索して根拠を渡す（RAG） | 社内文書を根拠にした回答・照会 | 検索時に利用者の参照権限を適用。文書の版・更新・削除を反映し、回答の根拠と検索の不足を評価する。 |
| 提案と更新を分ける | 登録・承認・メール送信など、結果が業務を変更する仕事 | AIの提案をそのまま実行権限にしない。許可した操作、データ検査、必要な承認を業務側で通してから実行する。 |
3. 文書差分の確認を、既存業務につなぐ例
教材を実業務へ適用するための設計例です。実際の顧客システムや、動作検証済みの構成ではありません。
- 対象を確定する比較する文書ID・版・参照権限を業務側で確認。元の文書は更新しない。
- 差分の候補を作る許可した情報を送信し、差分・原文箇所・未確認事項を取得。結果は未承認の下書きとして保存。
- 検査し、人が確認する存在しない文書箇所、数値・重要条項の抜け、出力形式を検査。担当者が原文と照合して採否を決める。
- 業務へ反映する承認済みの結果だけを反映。再実行でも重複登録しない識別子と、履歴・取消の手順を用意。
取得失敗や出典不足を「差分なし」と同じ状態にしないことが、この例の要点です。失敗は確認待ちへ戻し、従来の確認手順に切り替えます。
4. 採用する条件と、見送る条件を記録する
同じ素材・版・設定で候補を試し、公開スコアとは別に業務での合否を残します。平均だけでなく、失敗したケースと確認に要する手間も見ます。
- 品質：重要な数値・条項の欠落、根拠のない回答、形式違反をどこまで許容するか。
- 権限：閲覧できない文書、別部署のデータ、入力に混ざった不正な指示をどう扱うか。
- 費用と時間：再試行・人の確認を含めた1件あたりの費用と、混雑時の処理時間。
- 変更と復旧：モデルの版や設定を変えた時の再評価、障害時の代替処理、担当者。
入力条件を満たせない、重大な誤りを検出できない、失敗時に業務を戻せない場合は、その範囲の導入を見送るか、人の確認が可能な小さな範囲へ絞ります。特定ベンダー全体の採用・不採用とは分けて判断します。
参考資料と、この資料の範囲
接続方式の検討では次の一次資料も参照しました。上記の業務例と採否の手順は、当社が編集した設計観点です。各製品の機能・プレビュー状態・利用条件は、実装時に確認してください。