プロジェクトが本番稼働した後の問い
PoC (proof of concept) では、想定したやり方でシステムが動くことを示せます。しかし本番展開では、別の問いが前面に出てきます。
本番稼働後、そのシステムには誰が責任を持つのか。
その答えによって、リリース後にそのシステムを運用できるかどうかが決まります。
FDEが責任の抜けを早い段階で見つけられる理由
その理由は、この役割が顧客の業務フローと本番実装のあいだに位置しているからです。
OpenAIのForward Deployed Engineerの職務記述では、この役割は顧客向けの本番デプロイを中心に説明されています。具体的には、ディスカバリー、技術スコープの整理、システム設計、構築、本番展開、本番環境での定着、業務フローへの影響、現場からのフィードバックをプロダクトやモデルのロードマップへ戻すことが含まれます。
そこで、本番後の責任境界が見えてきます。長期的な責任主体は、顧客IT部門、業務部門、サポート、プロダクトオペレーション、またはプラットフォームチームかもしれません。本番展開前の時点では、どの責任がまだ割り当てられていないかを、FDEが最も明確に見ていることがよくあります。
そのためFDEは、本番展開前に責任境界を見える形にする手助けができます。それによって、顧客、ベンダー、プロジェクト関係者は、本番後の各責任をどのチームが持つのかを決められます。
責任境界1：監視
この境界では、リリース後に誰がシグナルを見て、何かが変化したときに最初の判断を下すのかを決めます。
何を監視するかを決める
実務的な監視計画は、3つの層を対象にします。
| 層 | シグナル |
|---|---|
| 基本動作 | 可用性、レイテンシ、エラー、トラフィック、コストなど |
| AIの挙動 | 回答品質、検索品質、ツール呼び出しの挙動、ガードレールによるブロック、ユーザーの拒否、ユーザーによる修正 |
| 業務リスク | 不正アクセス、機微な情報の露出、ポリシー違反、低い利用率、苦情、手作業への回帰 |
基本動作は、サービスの健全性を示します。GoogleのSREにおける監視の章では、この層について最低限見るべき範囲として、症状と原因を分けること、レイテンシ、トラフィック、エラー、飽和状態を見ること、対応につながらないアラートを避けることが示されています。AI導入では、サービス健全性のシグナルで分かるのは、システムの稼働状態です。回答品質、情報源の新しさ、ツール呼び出しの正しさ、ユーザーの信頼は、別に確認する必要があります。
AIの挙動は、回答と業務フローの品質を示します。基本動作が正常でも、AIの挙動は誤ることがあります。たとえば、サーバーは生きているのに回答が間違っている、APIは正常に返っているのに取得された文書が古い、ツール呼び出しは成功しているのにパラメータが間違っている、サービスは利用可能なままなのにユーザーが出力を信頼しなくなる、といった場合です。
業務リスクは、その利用が組織にとって安全で有用な状態を保っているかを示します。たとえば、社内サポートアシスタントは、従業員が古い社内ポリシーに基づく回答に依存する、回答が機微な情報を露出させる、ユーザーがアシスタントを迂回する、またはチームが出力を信頼できず手作業の確認を続ける場合、業務リスクになります。
シグナルは、アプリケーションログ、モデル呼び出しの記録、検索結果、ツール呼び出しのトレース、ユーザーフィードバック、サポートチケット、業務レポートなどから得られます。
誰が見て、誰が対応するかを決める
誰が見て、誰が対応するかは、そのシグナルが何に影響するのか、そして組織がどのように分かれているのかに基づいて決めるべきです。
たとえば、次のように整理できます。
- レイテンシの上昇 → プラットフォーム、インフラ、モデルエンドポイント、または連携チーム。
- 検索品質の低下 → 文書、権限、インデックス、またはデプロイチーム。
- ツール呼び出しの失敗 → API、顧客IT、連携、またはデプロイチーム。
- ユーザーの手作業への回帰 → 業務部門、サポートチーム、または業務フロー責任者。
責任境界2：障害対応
この境界では、システムに障害が起きたとき、誰が最初の対応を取るのかを決めます。
障害を分類する
障害対応は、誰に対応権限があるのかを決めるところから始まります。GoogleのSREオンコールガイダンスでは、引き継ぎ、エスカレーション経路、プレイブック、深刻度のトリアージ、緩和対応が扱われています。
障害は、業務への影響に基づいて分類します。
| 深刻度 | 例 | 最初の対応 |
|---|---|---|
| 低 | 1件の誤回答、同期失敗、または後続アクションを伴わない軽微な業務フローエラー | 事例を収集し、障害を分類する。 |
| 中 | 業務中に発生する検索エラーの繰り返し、ツール呼び出しの失敗、連携失敗、または権限の問題 | 影響を受けるユースケースを制限し、ログを調査し、回避策を伝える。 |
| 高 | 誤った業務アクション、機微なデータの露出、本番業務フローの停止、または顧客に影響する障害 | 機能を無効化またはロールバックし、直ちにエスカレーションする。 |
深刻度の高い障害では、明確な役割分担が必要です。Googleのインシデント管理の章では、インシデント指揮、実作業、コミュニケーション、計画を分けています。また、明確な引き継ぎを、対応責任を見える状態に保つための一部として扱っています。
最初の対応経路を割り当てる
深刻度分類が役に立つのは、それぞれの対応経路にチームまたは役割が割り当てられている場合だけです。
Googleのインシデント管理ガイドでは、インシデント対応を調整、コミュニケーション、運用の役割に分けています。同じ考え方は、FDEプロジェクトが曖昧な初動対応を避けるうえでも役立ちます。つまり、誰が報告を受けるのか、誰が証拠を確認するのか、誰が可用性を制限できるのか、またはロールバックを承認できるのか、誰が影響を伝えるのかを、プロジェクトとして定義しておくべきです。
各障害レベルについて、本番展開前に次の4点を決めます。
- 誰が報告を受けるのか。
- 誰が最初の証拠を確認するのか。
- 誰が一時的に機能の利用可能性を制限できるのか、またはロールバックやフォールバックを承認できるのか。
- 誰が回避策またはエスカレーションを伝えるのか。
これにより、最初の対応者がインシデント中に権限を推測する事態を防げます。深刻度の低い問題は、デプロイチームまたはサポートチームで対応できるかもしれません。深刻度が中程度の問題では、影響を受ける業務フローを絞り込むために、顧客IT部門、業務部門、またはFDE／デプロイチームが必要になる場合があります。深刻度の高い問題では、機能を止めること、問題をエスカレーションすること、影響を伝えることについて、事前に定義された権限経路が必要です。
フォールバックを定義する：システムができることを減らす
フォールバックとは、アシスタントをより安全な運用モードへ移すことです。システム自体は利用可能なままでも、障害が理解されるまで、できることを減らします。
ツールを使えるAIエージェントやアシスタントの場合、フォールバックは通常、システムが自律的に実行できる範囲を狭めることを意味します。影響の大きいアクションに人間の承認を必須にする、リスクの高いツール実行を無効化する、業務フローを狭める、または読み取り専用／検索専用モードに切り替える、といった対応です。これは、OWASPのAI Agent Security Cheat Sheetと同じセキュリティの考え方を適用しています。つまり、最小権限、高リスクな操作に対する明示的な認可、human-in-the-loopの制御です。
よくあるフォールバックのパターンは次のとおりです。
| リスクレベル | フォールバックのパターン | 何が変わるか |
|---|---|---|
| 回答品質に不確実性がある | 検索専用モードに切り替える | アシスタントは最終回答を生成する代わりに、情報源を表示する。 |
| ツール利用にリスクがある | ツール実行を無効化する | アシスタントは説明や下書きはできるが、アクションは実行できない。 |
| 業務への影響があり得る | 人間の承認を必須にする | アシスタントはアクションを準備するが、判断は人間が行う。 |
| 直近の変更が問題を起こした | プロンプト、業務フロー、モデル、または連携バージョンをロールバックする | システムを、最後に安全性が確認されていたバージョンへ戻す。 |
| ユースケースが広すぎる | 機能をより狭い業務フローに限定する | アシスタントは、リスクが理解されている範囲でのみ利用可能なままにする。 |
責任境界3：改善
この境界では、リリース後にどのチームがシステムのどの部分を変更するのかを決めます。
すべての問題がプロダクトのバグとは限りません。問題によっては、原因や対応先が顧客データ、業務フロー設計、ユーザートレーニング、連携、または再利用可能なプロダクトにあります。改善は、影響を受けている部分を変更できるチームへ問題を振り分けるところから始まります。
問題を変更できるチームへ振り分ける
本番後の報告は、担当先が決まった次のアクションに落とし込むべきです。
よくある振り分けパターンは次のとおりです。
| 本番後の問題 | 振り分け先のチームまたは役割 |
|---|---|
| 回答が古い情報を使っている。 | 文書またはデータの責任者 |
| ユーザーが未対応の業務フローを求めている。 | 業務部門またはトレーニング責任者 |
| 検索、プロンプト、または業務フロー設計が繰り返しミスを起こしている。 | FDEまたはデプロイチーム |
| ツール呼び出し、権限、またはAPIの挙動が本番環境で失敗している。 | 連携チーム、顧客IT部門、またはプラットフォームチーム |
| 同じ制約が複数のデプロイで現れている。 | プロダクトまたはプラットフォームの責任者 |
フォローアップを追跡する
責任を持つチームまたは役割が明確になったら、その問題は追跡可能なフォローアップ項目にするべきです。たとえば、データ修正、業務フロー変更、評価ケース、ランブック更新、プロダクトバックログ項目、またはユーザートレーニングの変更です。
GoogleのSREポストモーテムガイダンスでは、追跡の実務が詳しく説明されています。アクションアイテムには、責任者、追跡番号、優先度、検証可能な完了状態を持たせるべきだとされています。
引き継ぎ：責任を実行できる状態にする
引き継ぎとは、元のFDEまたはデプロイチームが離れた後でもシステムを運用できるように、次のチームまたは役割へ十分な運用知識を渡すことです。
運用知識を渡す
実務的な引き継ぎでは、次の4つの問いに答えられるようにするべきです。
- そのアシスタントはどの業務フローをサポートしているのか。
- どの業務フローはサポートしていないのか。
- どの文書、ツール、API、権限、プロンプト、またはモデルに依存しているのか。
- ログ、フォールバック手順、ロールバック手順、エスカレーション経路はどこにあるのか。
ランブックは、一般的な引き継ぎ成果物の1つです。GoogleのSREオンコールに関するガイダンスでは、エスカレーション経路とインシデント管理手順が、重要なオンコール用リソースとして挙げられています。FDEプロジェクトでも、引き継ぎ後には同じ考え方が当てはまります。次のチームは、最初に何を確認し、どこへエスカレーションすべきかを知っている必要があります。
障害を診断できるだけの証拠を残す
次のチームが意図された設計だけを知っている状態では、引き継ぎは完了していません。障害発生時に何が起きたのかを再構成できるだけの証拠も必要です。
次のような報告だけでは不十分です。
昨日、AIが間違った回答をしました。
この報告だけでは、問題が元文書、検索、プロンプト、モデル出力、ツール実行、権限、またはユーザーの業務フローのどこから来たのかが分かりません。
有用な障害記録では、次の経路を残すべきです。
ユーザーリクエスト
→ 取得された情報源または外部データ
→ モデル出力
→ ツール呼び出しまたはAPI結果
→ 業務フローのバージョン
→ ユーザーフィードバックまたは繰り返し現れるパターン
経路が見えるようになると、チームは問題を適切な先へ振り分けられます。たとえば、文書責任者、業務部門、デプロイチーム、連携チーム、顧客IT部門、またはプロダクトチームです。
何をログに残せるかを決める
証拠が多いほど診断には役立ちますが、ログはリスクも生みます。
AI導入のログには、顧客データ、個人情報、機密文書、社内業務ルール、認証情報、プロンプト、取得されたコンテキスト、またはツール出力が含まれる可能性があります。OWASPのLogging Cheat Sheetでは、実務的なログ記録のルールが示されています。運用およびセキュリティ上の用途に十分なログを残しつつ、機微なデータは除外または保護し、アクセスを制限し、必要な保持期間を超えてログを保存しない、という考え方です。
FDEプロジェクトでは、実務上のルールはより狭くなります。障害を説明できるだけの証拠を残しつつ、どの機微なデータをログに残す可能性があるのか、誰がアクセスできるのか、どれくらいの期間保持するのかを管理することです。
References
Google. “Being On-Call.” Site Reliability Engineering. https://sre.google/sre-book/being-on-call/
Google. “Incident Management Guide.” Google SRE: Practices and Processes. https://sre.google/resources/practices-and-processes/incident-management-guide/
Google. “Managing Incidents.” Site Reliability Engineering. https://sre.google/sre-book/managing-incidents/
Google. “Monitoring Distributed Systems.” Site Reliability Engineering. https://sre.google/sre-book/monitoring-distributed-systems/
Google. “On-Call.” The Site Reliability Workbook. https://sre.google/workbook/on-call/
Google. “Postmortem Culture: Learning from Failure.” The Site Reliability Workbook. https://sre.google/workbook/postmortem-culture/
NIST. “AI Risk Management Framework.” National Institute of Standards and Technology. https://www.nist.gov/itl/ai-risk-management-framework
OpenAI. “Forward Deployed Engineer, Tokyo, Japan.” OpenAI Careers. https://openai.com/careers/forward-deployed-engineer-tokyo-tokyo-japan/
OpenTelemetry. “Generative AI Semantic Conventions.” OpenTelemetry Semantic Conventions. https://opentelemetry.io/docs/specs/semconv/gen-ai/
OWASP. “AI Agent Security Cheat Sheet.” OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
OWASP. “Logging Cheat Sheet.” OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html