AI を業務システムに組み込み運用に乗せた後、問われるのは「動かし続けられるか」です。 本稿では、本番運用にあたって設計しておくべき三つの観点——障害モード、監視、コスト——について論じます。 いずれも、試作の段階では表面化しにくい論点です。

想定すべき障害モード

AI を外部 API として利用する場合、障害は単純なネットワーク断だけでは終わりません。 本番運用において当社が想定している主な障害モードは次のとおりです。

• タイムアウト：応答時間が想定を超え、業務側の処理が滞る。
• レート制限：単位時間あたりの呼び出し回数の上限に達し、後続の処理が一時的に拒否される。
• 入力長の超過：扱える文字数の上限を入力が超え、処理が完了しない。
• サービスの変更・終了：上流側のモデルや API 仕様が更新され、これまで動いていた呼び出しが意図しない動作になる。
• 出力品質の経時変化：モデルや上流サービスの更新により、同じ入力に対する出力傾向が変わる。

これらは個別の不具合というよりも、AI を外部依存として利用する以上、構造的に発生しうる事象です。 運用設計は、これらが「いつか起きる」前提で行います。

監視の設計

監視の目的は「壊れているか」を判定することではなく、「想定外の状態を早く検知すること」です。 AI を業務に組み込んだ場合、当社が監視対象とする項目は次のとおりです。

• 応答時間と失敗率の推移
• 呼び出し回数および入力長の分布
• 出力に含まれる特定の語・形式の出現頻度
• 業務側で発生したリトライ・エラー件数
• 単位時間あたりの利用コスト

いずれも、平時の値を把握しておかなければ「想定外」を判定できません。 本番投入の前後で平時の値を測定し、しきい値を経験的に定めます。

監視自体の運用にも仕組みが必要です。 当社の監視サービス Red Alert は、こうした AI 利用の監視にも適用できる構成として設計しています。

コストの設計

AI の利用コストは、本番投入の初期には小さく見えることが多い項目です。 試作の段階では呼び出し回数も入力長も限定的であり、利用料金が問題になることは稀です。

しかし、本番運用に乗せた後、業務の中で利用範囲が広がるにつれてコストは増加します。 当初の見積もりは「典型的な利用」を前提に行われがちですが、実際には、長い入力、繰り返しの呼び出し、誤りに対するリトライといった要素が、想定を超える費用を発生させることがあります。

当社では、本番投入の段階で 利用コストの上限と、それを超えた際の挙動 を設計に含めることを基本としています。 単位時間あたりの利用回数の制限や、入力長の上限、コスト上昇を検知した際の通知などです。 これらは、機能要件としては見落とされやすい一方、運用に乗せた後に最も影響の大きい項目です。

出力品質の経時変化

外部のモデルを利用する場合、上流側の更新により出力の傾向が変わる可能性があります。 昨日まで問題なく動いていた業務処理が、モデルの差し替えにより異なる結果を返すことがあります。

この種の変化は、ログを観察していなければ気づきにくいものです。 評価と品質 で論じた継続評価の仕組みは、こうした経時変化の検知にも有効です。

まとめ

AI を本番運用に乗せた後の信頼性は、障害モードの想定・監視の設計・コストの管理という三つの観点で支えられます。 いずれも試作の段階では表面化しにくく、本番投入後に問題として顕在化しがちです。 運用設計を、機能設計と同等の重みで扱うことが要点です。