本番AIアプリのアーキテクチャ｜認証・評価・監視・切り戻しを組み込む

本番AIアプリのアーキテクチャでは、モデルを交換できることより先に、利用者の権限を守り、部分失敗を止め、出力を検証し、変更を切り戻せることが必要です。

社内の契約書レビュー支援を題材に、入口、オーケストレーション、RAG、モデル、ツール、状態、評価、監視を分離する手順を示します。試作品から本番へ移す担当者が、構成図、受入条件、障害時の代替経路を作るための記事です。

本番AIアプリのアーキテクチャは八つの責務を分離して設計する

対象アプリは、社員が契約書をアップロードし、社内ひな型と審査基準を検索して、条項ごとの確認候補を返すものとします。AIは法務判断を確定せず、根拠箇所と差分を示し、法務担当が採否を決めます。契約締結や相手方への送信は別システムで行います。

[利用者]
   |
[入口/API Gateway] -- 認証、容量制限、要求ID
   |
[業務API] --------- 認可、案件状態、冪等性
   |
[Orchestrator] ----- 手順、タイムアウト、再試行上限
  /       |       [RAG]  [Model]  [Tools]
         |       /
   [Output Validator] -- スキーマ、引用、業務ルール
           |
   [Review Queue] ---- 人の承認、差し戻し
全コンポーネント -> [Trace / Metrics / Audit]
設定・評価結果   -> [Registry / Release Control]

八つの責務とは、入口、業務API、処理制御、検索、モデル接続、ツール接続、出力検証、人の審査です。どれかが停止したとき、残りが勝手に処理を進めないことが完成条件です。たとえば監査ログを書けない状態で契約データを外部送信せず、検索が0件ならモデルの一般知識で補わないようにします。

本番化の前提をSLO・データ・権限・終了条件でそろえる

PoCのデモが動いても、本番要件は満たしません。契約書レビューの業務所有者、正本となる審査基準、入力可能な機密区分、利用者グループ、保存期間、法務へ渡す条件を決めます。モデル名やクラウド製品を先に固定すると、要件を製品仕様へ寄せることになります。

表の数値は架空の提案値です。品質100案件には、通常条項60、表現揺れ20、欠落・矛盾10、読み取り困難10を含めます。学習や評価に使う権利がない契約書しかない場合は、合成データだけで本番品質を断定せず、権利を確認した匿名化案件を用意してから進めます。この構成が向かないケース

一日数件で、結果を人が最初から読み直す方が速く、機密データを外部処理できず、専用基盤の運用者も置けない場合は、AIアプリを本番化しない判断が妥当です。既存の条項チェックリストと文書比較機能で要件を満たせるかを先に試します。

認証・認可・データ境界をモデル呼び出しより前に実装する

認証は「誰か」、認可は「その人がこの案件へ何をできるか」の判定です。業務APIはID基盤から主体IDとグループを受け取り、案件ACL、文書ACL、ツール権限を毎要求で評価します。会話履歴に「私は法務部です」と書かれても権限は変えません。モデルには社員番号やアクセストークンを渡さず、必要最小限の役割ラベルだけを与えます。

データフローは、ブラウザー、一時保存、OCR、検索索引、モデルAPI、ログ、バックアップ、削除キューまで描きます。各矢印に暗号化、保存地域、再委託、保持期間、削除責任者を付けます。モデルAPIが入力を学習へ使わない設定でも、自社ログやAPMが全文を保存していれば目的は達成できません。

検索結果にも元文書の権限を引き継ぐ

RAG索引へ投入した時点でACLを失うと、別案件の条項が検索されます。チャンクごとに文書ID、版、案件ID、閲覧グループ、有効期間を持たせ、検索時に利用者の権限で絞ります。権限フィルターはモデルが生成するクエリへ委ねず、サーバー側で強制します。文書削除時には索引、キャッシュ、引用プレビュー、バックアップの削除条件を追跡します。

サービス間資格情報は分ける

アプリ、OCR、検索、モデル、監視が同じAPIキーを共有すると、漏えい時の影響と追跡範囲が広がります。ワークロードIDまたは短期トークンを使い、検索サービスには読取り、モデル接続には推論、監視にはイベント書込みだけを与えます。資格情報更新を無停止で行える二重キー期間と、緊急失効の手順を試験します。

オーケストレーターに状態・期限・再試行上限を持たせる

長い契約書は、受付、解析、検索、生成、検査、審査待ちという数分から数日の処理になります。HTTP接続や会話履歴だけで状態を持たず、案件状態をデータベースへ保存します。状態遷移は単方向を基本とし、再実行では新しい試行を作ります。

RECEIVED
  -> CLASSIFIED
  -> TEXT_EXTRACTED
  -> SOURCES_RETRIEVED
  -> DRAFT_GENERATED
  -> VALIDATED
  -> WAITING_REVIEW
  -> APPROVED | REJECTED | CANCELLED
例外状態:
RETRYABLE_ERROR | NEEDS_INPUT | SECURITY_HOLD | UNKNOWN_SIDE_EFFECT

各段階へタイムアウト、最大試行回数、補償処理、担当キューを設定します。OCRが失敗した文書をモデルへ空文字で渡しません。検索が0件なら一般知識で契約解釈を作らず、NEEDS_INPUTとして審査基準の不足を通知します。外部ツールの応答が途切れた場合はUNKNOWN_SIDE_EFFECTへ移し、冪等キーで状態照会します。

再試行は、入力が重複しても副作用を二重に発生させない設計と組み合わせます。モデル生成は再試行可能でも、相手方への送信、契約台帳更新、課金処理は状態照会を挟みます。再試行回数を増やす前に、入力不備、一時障害、上限超過、恒久的な認可拒否をエラーコードで分けます。

モデル接続をアダプター化し、機能差を契約として表す

モデルを抽象化する目的は、どの製品にも瞬時に切り替えることではありません。入力上限、構造化出力、ツール呼び出し、データ保持、リージョン、レート制限、終了理由の違いを業務APIから隔離し、評価を通過した構成だけを有効にすることです。

アダプターの戻り値は、本文、引用候補、使用量、終了理由、提供側要求ID、モデル固定名、拒否情報、エラー分類を共通化します。未対応機能を黙って無視しません。たとえばJSON Schemaの厳格保証がないモデルを選んだ場合は、capability.structured_output=falseとして後段検査を強めるか、その経路では利用不可にします。

OpenAIの公式実装資料「Production best practices」は、APIキーをコードや公開リポジトリへ置かず、環境変数や秘密管理サービスで扱うこと、利用量とレート制限を考慮して本番運用することを説明しています^[1]。

これはOpenAI APIの運用条件を示す一次資料であり、他社サービスの仕様を保証するものではありません。一方、資格情報をクライアントへ露出しないことと、利用上限を設計へ組み込むことは、接続先ごとに確認すべき設計項目です。

出力検証と人の審査画面を別工程として設計する

出力検証は、JSONとして読めるか、必須条項があるか、引用先に同じ主張があるか、数値と日付が原文に一致するか、権限外の文書IDを含まないかを順に確認します。検証器自体の版も保存し、モデル変更と検証ルール変更を同時に本番投入しないようにします。原因を切り分けられなくなるためです。

審査画面には、AIの完成文だけでなく、原文との差分、引用箇所、使用した審査基準、検証不合格、モデルが参照しなかった節を表示します。承認者が原本を別画面で探し回る設計は、確認を形骸化させます。承認、修正、差し戻し、対象外を選び、修正理由を評価データへ戻します。

高リスク案件を自動承認しません。法務担当が少ない場合は、全件確認を諦めてAIへ確定させるのではなく、対象条項を限定する、受付量を制限する、低リスク契約だけにする、といった範囲調整を行います。

監視・監査・セキュリティを共通の要求IDで結ぶ

監視には、インフラの可用性、モデル使用量、検索0件、検証不合格、審査差し戻し、権限拒否、部分成功を含めます。ログ全文を一つのAPMへ送るのではなく、通常運用のメタデータと、短期保存する機密原文を分けます。要求IDから必要な案件だけを承認付きで調査します。

Google Cloudの公式アーキテクチャ指針「Well-Architected Framework」のAI/ML reliabilityは、AI・MLシステムをモジュール化・疎結合にし、障害時の縮退と横断的な可観測性を備えるよう推奨しています^[5]。

本稿では特定製品の採用根拠ではなく、検索、モデル、検証、監視を別々に停止・切り戻せる構成を検討するための公式資料として用います。

NIST AI 600-1は、米国国立標準技術研究所が公表した生成AI向けの公的リスク管理資料です。生成AIに固有、または生成AIによって増幅されるリスクを整理し、事前評価、継続監視、インシデント開示などをAI RMFへ対応付けています^[2]。

NIST AI 600-1は、契約レビュー支援に対する法的要件や合格値を定めた資料ではありません^[2]。本稿では、モデル出力をアプリ内部の一部として扱い、利用文脈に応じた測定と管理を自社側へ置くという運用設計の根拠に限定して参照します。

評価済みの構成一式を段階配備し、案件状態も切り戻す

モデル、プロンプト、検索索引、検証器、ツールスキーマを別々に「最新版」へ向けると、再現できません。互いに動作確認した版をリリースマニフェストへまとめます。設定変更にもコードと同じレビュー、承認、ロールバックIDを付けます。

release: contract-review-2026.07.30.1
app: git:8a12...
prompt: clause-review@24
model: provider/model-snapshot
index: legal-rules@2026-07-15
validator: ruleset@11
tool_schema: case-registry@5
eval_set: legal-100@7
approved_by: product-owner, legal-quality, security

最初に社内開発者5名、次に法務10名、最後に対象部署の20%へ広げます。段階ごとに最低100案件または二週間のどちらか長い方を観測する、というのは本稿の提案例です。重要条項見落とし0、権限逸脱0、審査差し戻し率が基準内であることを確認してから次へ進みます。

切り戻しでは入口を旧版へ向けるだけでなく、処理中案件を分類します。生成前は旧版で再開可能、生成済み・審査前は使用版を明示して審査、外部更新済みは二重実行を避けて状態確認、というルールにします。新旧の結果を同じ案件へ上書きしません。

NIST SP 800-218Aは、米国国立標準技術研究所が公表した、生成AIやデュアルユース基盤モデル向けの安全なソフトウェア開発実務を既存SSDFへ追加する公的資料です^[3]。

自社が基盤モデルを開発しない場合でも、モデル、データ、依存関係、設定の出所と変更を追える供給網管理は、本番アプリの更新判断に使えます。ただし、本文で示したリリース名や承認者の組み合わせは同資料の指定ではなく、契約レビュー支援に合わせた本稿の設計例です。

本番前に機能・権限・障害・復旧を同じ環境で検証する

受入試験は正常な回答精度だけで終えません。性能試験用にダミー契約を使い、権限試験では異なる部署と案件を用意し、障害注入では検索、モデル、監視、外部ツールを個別に止めます。本番相当のネットワーク、ID、秘密管理、監視を使わなければ、構成上の欠落を検出できません。

1. 機能: 100案件の重要条項を法務正解と比較し、案件単位と条項単位の両方で集計する。
2. 権限: 別案件ID、削除済み文書、期限切れセッション、異動前グループを拒否する。
3. 負荷: 同時10、30、50要求でp50・p95・p99、キュー長、GPU/API上限を測る。
4. 障害: OCR失敗、検索0件、429、5xx、タイムアウト、監査ログ停止、部分成功を注入する。
5. 復旧: データベースと索引をバックアップから戻し、RTO4時間・RPO15分を実測する。
6. 切り戻し: 新版で処理中の案件を残したまま旧版へ戻し、二重処理がないことを確認する。

負荷試験の容量例として、平均到着率が毎秒2件、平均処理時間が12秒なら、Littleの法則による処理中要求の平均は2×12=24件です。これは待ち行列の平均を見積もる試算であり、ピーク、長文、再試行を含みません。安全率2を掛けた48件を起点にし、実測のp95とメモリから同時数を調整します。

復旧試験でデータベースだけ戻っても、索引版、プロンプト版、審査待ち状態が一致しなければ業務復旧ではありません。代表10案件を再開し、引用文書、モデル版、承認履歴が復元されることまで確認します。

OpenAIの公式安全ガイド「Safety best practices」は、敵対的入力のテスト、人による確認、入力・出力制約などを本番安全策として挙げています^[4]。これはOpenAI製品を利用する開発者向けの一次資料です。本稿では製品固有機能の保証としてではなく、受入試験へ落とす観点として利用します。

テナント分離・キュー・キャッシュを業務APIの配下で制御する

複数部署が使う場合、モデルAPIの前にテナント境界を置きます。案件DB、オブジェクト保存、検索索引、キャッシュ、監視ビューで同じテナントIDを強制し、利用者が要求本文から変更できないようにします。共有索引を使う場合でも、チャンクACLと検索フィルターをサーバー側で必須にします。

キューはレート制限への対策だけでなく、優先度と期限を管理します。契約締結当日の案件、通常レビュー、再評価を別キューにし、古い要求をいつまでも処理しません。期限を超えた要求はモデルへ送らず、利用者へ再受付の要否を確認します。キュー内の入力は暗号化し、担当者が平文を一覧できないようにします。

生成結果のキャッシュは、入力が同じでも利用者権限、文書版、プロンプト版、モデル版が違えば再利用しません。秘密情報を含む応答を共有CDNへ置かず、キャッシュヒット時にも現在の認可を確認します。削除依頼や文書改定が来たら、対応するキーを追跡して失効できる設計にします。

一部署の大量投入で他部署を止めないよう、同時実行数と日次予算をテナント別に設定します。超過時は低優先度を保留し、重要案件まで無差別に拒否しません。運用者が上限を変更した場合は、理由、期限、影響テナントを監査ログへ残します。

依存先ごとの障害モードと代替経路を事前に固定する

本番AIアプリは、ID基盤、OCR、オブジェクト保存、検索、モデル、通知、監視へ依存します。単純な「AIサービス障害」では切り分けられません。依存先ごとに、タイムアウト、誤応答、遅延、部分成功、古いデータ、認証失敗を列挙し、代替経路がデータ条件を満たすかを審査します。

代替モデルは「接続できる」だけでは候補になりません。保存地域、学習利用、入力上限、構造化出力、ツール仕様、品質評価が同じ本番要件を満たす必要があります。条件を満たさない場合は非同期受付や手動処理へ縮退します。

四半期ごとに一依存先を止め、アプリが表どおりに振る舞うかを確認します。監視画面の赤表示だけでなく、利用者への文言、保留案件の状態、復旧後の再開順、二重処理の有無まで試します。障害注入が本番で危険なら、同じID・ネットワーク・設定を持つ演習環境で行います。

容量・費用・品質を一つのリリース予算へまとめる

同時実行数を上げれば待ち時間は減りますが、レート制限、モデル費、検索負荷が増えます。入力ページ数、抽出文字数、検索チャンク数、生成上限、再試行を業務単位の予算として定めます。上限超過時に末尾を黙って切らず、分割または人への差し戻しを選びます。

想定月間案件: 3,000件
平均モデル呼出し: 2.4回/案件
平均費用: 18円/呼出し
モデル費試算: 3,000 × 2.4 × 18 = 129,600円
再試行率が8%の場合:
追加呼出し: 3,000 × 2.4 × 0.08 = 576回
追加費用: 576 × 18 = 10,368円
人の審査:
3,000件 × 平均6分 ÷ 60 = 300時間

これは架空の試算で、モデル単価や実績ではありません。API費139,968円より、人の審査300時間の方が運用計画へ大きく影響する可能性があります。AIの高速化だけで受付を増やすと審査キューが詰まるため、モデル処理量と承認者の処理能力を同じ容量計画へ入れます。

品質予算には、重要条項見落とし0、引用不一致率1%未満、全面書き直し率10%未満などを置きます。費用上限を守るため出力を短くした結果、重要条項を落としたらリリースしません。品質、p95時間、月額費、審査待ちの四条件を同時に満たした構成だけを段階配備します。

月次予算の80%へ達した時点で低優先度案件の受付を調整し、100%を超えてから緊急停止しないようにします。予算増額は自動化せず、案件数の増加、再試行、入力長、モデル変更のどれが原因かを要求トレースから説明して承認を得ます。

本番AIアプリの運用引き継ぎを終え、次の行動を決める

開発完了の条件に、運用担当が自力でアラートを切り分け、モデル経路とツールを個別停止し、保留案件を確認できることを含めます。手順書を渡すだけでなく、検索0件の急増、資格情報漏えい、状態不明の外部更新という三つの演習を行います。

演習の合格は、担当者が画面を見たことではなく、権限を借りずに対象経路を止め、状態不明案件を再送せず隔離し、復旧の承認先へ証拠を渡せたことです。各操作の開始・終了時刻を記録し、手順書にない口頭補助が必要だった箇所は未完了として改訂します。

連絡先には氏名だけでなく、当番窓口、代行者、判断できる範囲を記載します。モデル事業者の障害、検索索引の破損、顧客データ誤表示では必要な責任者が異なります。四半期演習で連絡不能だった窓口は、公開環境の構成変更と同じ優先度で直します。

公開日を決める前に、現在のPoCを前掲の八責務へ割り当て、次の三点を実施します。

1. 入口から人の審査までの構成図に、各責務の所有者と停止操作を記入する。
2. 認可、状態管理、出力検証、監査、切り戻しの空欄を設計課題として登録する。
3. 契約レビュー100案件と障害演習3件を実行し、公開判定の証拠を残す。

所有者を置けない責務、単独で止められない経路、復旧を実測していない状態が一つでも残る場合は、公開日を確定せず、読み取り専用の試行へ戻します。

参考文献・出典

1. OpenAI「Production best practices」（オンライン版、2026年7月30日確認）
2. NIST「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」（NIST AI 600-1、2024年7月26日）
3. NIST「Secure Software Development Practices for Generative AI and Dual-Use Foundation Models」（NIST SP 800-218A、2024年7月）
4. OpenAI「Safety best practices」（オンライン版、2026年7月30日確認）
5. Google Cloud「AI and ML perspective: Reliability」（Google Cloud Well-Architected Framework、最終レビュー2025年8月7日、2026年7月31日参照）。本番AIアプリのアーキテクチャにおけるモジュール分離、縮退、評価・監視の設計に使用。

参考文献[1]〜[4]の参照日は2026年7月30日、[5]は2026年7月31日です。オンライン仕様は公開直前にも変更履歴を確認してください。