運用に入ってから効く設計判断
AIを組み込んだ仕組みの設計では、稼働直後には問題にならず、数か月後に効いてくる判断がいくつかあります。切り替えの容易さ、費用の制御、障害への気づき方、変更の追跡。
本章ではこれらを扱います。技術的な詳細に入りますが、判断の中身は組織的な問題への備えです。誰が変更できるか、誰が費用を把握するか、誰が障害に気づくか。設計はこれらの答えを固定します。
API設計とシステム間連携
抽象化の層を1つ挟む
最も費用対効果の高い設計判断です。AIサービスを直接呼び出すのではなく、自社のコードで包んだうえで呼ぶ構成にします。
効果は4つあります。
- 切り替えが1箇所で済む ― モデルやサービスの変更が、包んだ層の中だけで完結します(第10章)。
- ログを一元化できる ― すべての呼び出しが同じ経路を通るため、記録の実装が1箇所になります。
- 費用の集計ができる ― 呼び出しごとのトークン数を同じ場所で記録できます。
- 共通の前処理・後処理を入れられる ― 機密情報の除去、出力形式の検証をまとめて行えます。
この層を作らずに各所から直接呼び出す構成にすると、上の4つがすべて散在します。後から追加するのは、呼び出し箇所の数だけ手間がかかります。
同期処理と非同期処理の分け方
AIの処理は、従来のシステム処理より応答時間が長く、その振れ幅も大きいという性質があります。推論モデルではさらに顕著です(第2章)。
| 方式 | 適する場面 | 設計上の要点 |
|---|---|---|
| 同期(その場で待つ) | 対話型の画面、短い処理 | タイムアウトの設定。待ち時間の表示。失敗時の再試行 |
| 非同期(受け付けて後で返す) | 長い処理、大量の一括処理 | 待ち行列、進捗の確認手段、完了通知 |
| バッチ(まとめて夜間に) | 日次・月次の処理 | 再実行の仕組み、部分失敗時の扱い |
実務での失敗は、長い処理を同期方式で作ってしまうことです。画面が固まる、既存のタイムアウト設定に当たる、再試行で二重に課金される。非同期に変更するのは大きな改修になるため、処理時間の見積もりを設計時に行う必要があります。
冪等性の確保
同じ処理を2回実行しても結果が変わらない性質を、冪等性と呼びます。AI処理では特に重要になります。理由は、応答が遅いために再試行が発生しやすく、しかも出力が毎回同じとは限らないためです。
実務的な対処は、処理の単位に識別子を付け、すでに処理済みなら保存済みの結果を返す構成にすることです。これがないと、再試行のたびに費用が発生し、結果も変わります。
インフラの選定
クラウドAPIか、自社環境か
第1章で扱った軸を、インフラ選定の観点から整理します。
| 選択肢 | 初期費用 | 運用負荷 | 適する条件 |
|---|---|---|---|
| クラウドAPI | ほぼなし | 小さい | データを外に出せる。件数が変動する |
| クラウド上の専有環境 | 中 | 中 | 処理量が安定して多い。応答時間を安定させたい |
| 自社サーバー | 大 | 大 | データを外に出せない。長期的に大量処理 |
| 端末上(エッジ) | 中 | 中 | 通信遅延が許容できない。映像を外に出せない |
計算資源の考え方
自社環境でモデルを動かす場合、GPU(元は画像処理向けに作られ、現在はAIの大量並列計算に広く使われる演算装置)の要否と規模が検討事項になります。
判断の順序は次のとおりです。
- 動かすモデルの規模を決める ― 用途に必要な性能から決めます(第1章)。
- 量子化の適用を検討する ― 必要な計算資源が大きく変わります。
- 同時処理数を見積もる ― 何人が同時に使うか、1件の処理にどれだけかかるか。
- 費用を3年間で比較する ― 設備費・電力・運用工数を含めて、クラウドAPIと比較します。
実務では、クラウドAPIで始めて、処理量が安定して大きくなってから自社環境を検討する順序が費用面で有利になることが多いです。逆順(最初に設備投資)は、処理量の見積もり誤りの影響が大きくなります。
スケーラビリティ
件数の増加に対応できる構成にしておく必要があります。ただし過剰な準備は費用の無駄になります。実務的な設計は次のとおりです。
- 処理を待ち行列に入れる構成にする(急な増加を吸収できます)
- 1件あたりの処理時間と費用を記録する(増加時の見通しが立ちます)
- レート制限の上限を把握しておく(第3章)
- ピーク時の処理量を実測しておく
MLOps/LLMOpsの基礎
モデルを使った仕組みを継続的に運用するための考え方です。従来のシステム運用と違う点に絞って扱います。
従来の運用と何が違うか
| 観点 | 従来のシステム | AIを含む仕組み |
|---|---|---|
| 変更の契機 | コードの変更 | コード、プロンプト、参照データ、モデルの更新 |
| 品質の劣化 | 基本的に起きない | モデル更新・データの変化で起きる |
| テストの性質 | 同じ入力に同じ出力を期待 | 許容範囲に収まるかを判定(第14章) |
| 費用の変動 | ほぼ固定 | 使用量に比例 |
| 監視対象 | 稼働・エラー・性能 | +出力品質・費用・トークン数 |
この表の2行目が本質です。コードを変えていないのに品質が変わることがあるという性質が、従来の運用の前提を崩します。だから継続的な品質の測定が必要になります(第24章)。
管理対象を明確にする
AIを含む仕組みでは、次のすべてが変更の対象になります。それぞれ管理の仕組みが必要です。
- コード(従来と同じ管理)
- プロンプト(後述)
- 参照データ(RAGの対象文書。版と更新日)
- モデルの指定(名前とバージョン)
- 設定値(温度などの生成パラメータ、閾値)
- 検証セット(品質を測る基準そのもの)
これらのどれが変わったときにも、品質が変わる可能性があります。「いつ・何が変わったか」を記録しておかないと、品質の変化の原因を特定できません。
プロンプトとエージェントのバージョン管理
プロンプトは実質的にコードの一部です。しかし管理が疎かになりやすい理由があります。編集が簡単で、管理画面上で直接変更できることが多いためです。
管理すべき理由
- プロンプトの変更は出力を変える(コードの変更と同等の影響)
- 誰がいつ何のために変えたかが分からないと、戻せない
- 複数の人が別々に調整すると、変更が衝突する
- 移行時に持ち出せる資産になる(第10章)
実務的な管理方法
- プロンプトをコードと同じ場所で管理する ― 変更履歴が残り、レビューの対象になります。
- 本番で使うプロンプトはバージョンを付ける ― 出力の記録と対応付けられるようにします。
- 変更時に検証セットを流す ― 意図した改善が、他の項目を悪化させていないかを確認します(第14章)。
- 管理画面での直接編集を制限する ― 試行は自由に、本番反映は経路を通す形にします。
エージェントの場合、管理対象がさらに増えます。使える道具の一覧と、その権限です。これは実質的にアクセス権限の設定なので、変更は必ず記録し、承認の対象にします(第16・21章)。
コスト最適化
費用の削減には、効果の大きい順に決まった手順があります。
1. 処理の種類でモデルを振り分ける
最も効果が大きい対策です。定型的な分類・抽出は小さいモデル、複雑な判断は大きいモデルまたは推論モデル。同じ処理をすべて高性能モデルで行っている構成は、費用の大部分を無駄にしている可能性があります(第1・2章)。
2. 入力を減らす
費用は入出力の量で決まります。次の見直しが効きます。
- 文書全体を送るのをやめ、関連部分だけを検索して送る(RAG)
- 毎回送っている長い指示を、ファインチューニングで置き換える(頻度が高い処理のみ)
- 過去の会話履歴を全部送るのをやめ、必要な範囲に絞る
- 不要な項目を除去する(機密情報の除去と同時に行えます)
3. キャッシュを使う
同じ入力に対する結果を保存して再利用します。効果が出るのは次の場合です。
- 同じ質問が繰り返される(FAQ、社内問い合わせ)
- 同じ文書を繰り返し処理する
- 長い共通の前置き(システムプロンプト、参照文書)を毎回送っている
最後の項目については、提供側が共通部分の再利用に対応している場合があり、費用が大きく下がることがあります。利用しているサービスの仕様を確認してください。
4. 上限と可視化
- 月間の費用上限を設定する ― 超えた場合の動作(停止か通知か)も決めます。
- 部署別・用途別に費用を集計する ― 抽象化の層で記録していれば集計できます。
- 1件あたりの費用を継続的に記録する ― 悪化に気づける唯一の方法です。
障害対応と可観測性
AIを含む仕組みでは、「動いているが品質が落ちている」という状態が起こります。従来の稼働監視では検知できません。
記録すべきもの
| 項目 | 用途 |
|---|---|
| 入力(または識別子) | 再現と原因調査。機密情報の扱いに注意する |
| 出力 | 品質の事後確認、傾向の変化の検知 |
| 使用したモデルとバージョン | 更新の影響の切り分け |
| プロンプトのバージョン | 変更の影響の切り分け |
| トークン数と費用 | 費用の管理、悪化の検知 |
| 処理時間 | 性能の劣化の検知 |
| 人による修正の有無と内容 | 品質の実測値になる |
| エラーと再試行の回数 | 安定性の把握 |
| AIが実行した操作(呼び出した道具・送信先・変更対象) | 権限の逸脱の検知と、事故時の追跡。操作を実行する仕組みでは必須(第21章) |
最も価値が高いのは人による修正の記録です。これは品質の実測値であり、他の方法では得られません。確認工程を持つ設計であれば、修正内容を記録する仕組みを併せて作ってください(第4・14章)。
ログに残してはいけないもの
入力をそのまま記録すると、個人情報や機密情報がログに蓄積します。設計時に次を決めます。
- 機密度の高い項目は記録しない、または識別子に置き換える
- ログの保持期間を決める(無期限保存は避けます)
- ログへのアクセス権限を設定する
アラートの設計
通知が多すぎると無視されます。実務的には次の4つに絞るのが有効です。
- 処理が失敗した件数が閾値を超えた
- 費用が予定の水準を超えた
- 処理時間が通常より大きく伸びた
- 人による修正の割合が上がった(品質の劣化の兆候)
4番目が、AIを含む仕組みに特有の監視項目です。これを監視していないと、精度の低下に気づくのが利用者からの申告になります。
二年目の十二月、朝凪精機の情報システム課の森が受注入力の試作を作ると、通信を切って再実行したときに同じ受注が2件できました。一通ごとに番号を振り、処理済みなら前の結果を返す形に直すことにしました。十日、構成図を平文で説明しに来たアストラム・データの技術者は、費用の上限は必ず決めておくよう念を押し、以前に見た仕組みの話をしました。月末に費用の上限を超えて止まった仕組みで、再送されたメールを二重に処理していたうえ、上限に来たら全部が止まる作りでした。上限に達したら新規の受付だけを止める、同じメールは2回処理しない ― この2点を入れるのに要したのは半日でした。停止してから設計したのではなく、停止するまで設計しなかったことが差になっています。
この場面は網羅物語之巻 第9章「動くものと、使えるもの」に出てきます。
設計の優先順位
すべてを最初から作る必要はありません。着手時点で決めておくべき順序を示します。
- 抽象化の層 ― 後から入れるのが最も高くつきます。最初に作ります。
- ログ(入力・出力・モデル・費用) ― 記録がないと後から何も分かりません。
- 費用の上限 ― 想定外の請求を防ぎます。
- 失敗時の動作と再試行 ― 業務を止めないための最低条件です。
- 検証セット ― 品質の基準。移行時にも使えます(第10・14章)。
- 人による修正の記録 ― 品質の実測値になります。
- それ以外の最適化(キャッシュ、非同期化、モデルの振り分け)は、実測してから行います。
7番目が重要です。最適化は実測してから行うべきで、事前の推測で複雑な構成を作ると、必要のない保守対象が増えます。