Who This Is For
対象読者
Pilotで検証が完了した業務を本番展開する、情報システム部門、セキュリティ部門、SRE・運用責任者を対象にしています。
What You'll Decide
このSTEPで決めること
Deploy & Operateでは、本番環境での認証・権限・監視体制を確定し、障害時の停止条件と復旧手順、継続的な変更管理の進め方を決定します。
Industry Challenges
大手TMT企業固有の課題
24時間体制のオンコールとの整合
SREのオンコール体制と、Agentの監視・アラート対応をどう分担するかの整理が必要になります。
複数プロダクト・複数環境にまたがる障害対応
プロダクトごとに構成が異なる場合、障害発生時の切り分けに時間がかかります。
外部API（GitHub・Jira等）の障害耐性
外部ツールの仕様変更や一時的な障害があった場合、連携部分の変更管理と耐障害設計が必要になります。
コスト監視の必要性
常時稼働・定期実行が増えるほど、利用コストが積み上がるため、継続的なコスト監視が必要です。
Method
実施手順
1. 実行環境を整備する
本番環境（クラウド等）を整備し、Pilot環境との差分を確認します。開発・検証・本番の分離を維持します。
2. 認証・アクセス権限を確定する
本番利用者・Agentの認証方式と、プロダクト・チーム別のアクセス権限を確定します。
3. Secret管理を整備する
APIキーやトークンなどの機密情報を、安全に管理・ローテーションできる体制を整えます。
4. ログ・監査体制を整える
操作ログの保存先、保存期間、監査時の参照方法を整えます。
5. 監視・アラートを設定する
Agentの稼働状況、実行失敗、異常な処理件数などを監視し、アラートを設定します。
6. 停止条件・障害対応を定義する
異常検知時に自動停止する条件と、障害発生時の連絡・復旧フローを定義します。
7. 変更管理を整備する
接続先システムの変更、Skill・Toolのバージョン更新時に、影響範囲を確認するプロセスを整えます。
8. コスト監視・定期レビューを行う
利用コストを可視化し、定期的に運用状況をレビューする体制を作ります。
Data & Systems
使用するデータ・システム
Human-in-the-loop
人間承認が必要な箇所
- 本番環境への移行可否の最終承認
- Secret・認証情報の発行・ローテーションの承認
- 接続先システムの仕様変更に伴うSkill・Tool更新の承認
- 障害発生時の復旧手順の実行承認
Measurement
KPI
稼働率
本番運用中のAgent・Skillの稼働率
障害検知〜復旧時間（MTTR）
異常検知から復旧までにかかった平均時間
アラート対応時間
アラート発報から一次対応までの時間
Pitfalls
失敗例・注意点
監視を導入後任せにする
本番移行後の監視体制を決めずに稼働させると、障害の発見が遅れます。
Secretを個人管理にする
APIキー等を個人のPCやメモに保存すると、退職・異動時にリスクが残ります。
変更管理を省略する
接続先システムの仕様変更やモデル変更を把握せずに運用を続けると、出力内容や処理に誤りが生じます。
Checklist
本番運用チェックリスト
- 本番環境の認証・アクセス権限が確定している
- Secret管理・ローテーションの手順が決まっている
- 操作ログの保存先・保存期間が決まっている
- 監視・アラートの対象と通知先が設定されている
- 異常時の停止条件と復旧手順が明文化されている
- 接続先システム変更時の変更管理プロセスがある
- 利用コストを可視化する仕組みがある
- 定期レビューの頻度と参加者が決まっている
FAQ
よくあるご質問
本番運用の監視は誰が担当しますか
情報システム部門・SREチームが主体となり、業務内容によっては開発・QA部門と連携して対応する体制が一般的です。具体的な役割分担は個別に設計します。
障害時はAgentが自動的に停止しますか
あらかじめ定義した停止条件に該当する場合は自動停止する設計を推奨しますが、条件の設計は業務ごとに異なるため個別に検討します。
セキュリティ監査にはどう対応しますか
操作ログ、アクセス権限、承認記録を整備することで監査に対応しやすくなりますが、具体的な監査要件は組織の内部監査基準により異なります。
本番構成を、一緒に整理しませんか。
認証、監視、障害対応、変更管理を含む本番運用構成を、正式LPでのご相談を通じて具体化できます。