SERVICE # AIOps 事例 ![](/media/newsite-aiops-hero.png) ## AIOps：対応のたびに正本（ルール・テスト・仕様書）を育て、精度を上げる。 当社のAIOpsは、開発・第三者評価・検証・運用監視・BPOで発生した事象をAIが分析し、ルールやテスト、仕様書、スクリプトとしてコードに残し、精度を上げていく取り組みです。FDE が組み込んだ正本を、運用の中で育てます。個人情報や秘密情報は AI に見せず、それを扱うコードを AI に作らせ、人がレビューしてデータのある環境の中で実行します。業務ごとに「これまで」と「AI を組み込むと」を、実際のコードの形で並べました。 AIOps × 開発 AIOPS FOR DEVELOPMENT FDE：AI 駆動開発基盤の構築 ## ルールを増やすのではなく、構造で AI にできないことを決める **この段で 伝えていること** AI エージェントに開発を任せるとき、大切なのはコーディングのルールを増やすことではありません。ルールは読み落とされることがあり、増えるほど互いに食い違います。AI にさせてはいけないことは、構造でできないようにします。サービスと API で責務を分け、サービスどうしは API の仕様（OpenAPI など）だけでつなぎます。ほかのサービスのデータベースには、接続先も認証情報も持たせません。本番のデータベースやログ、認証情報には、エージェントの権限では届きません。本番への反映は、人の明示的な指示でのみ行います。レビューで見つかった失敗も、ルールの追記だけで済ませず、責務の分け方・API の仕様・権限といった構造の見直しに戻します。 具体例をコードで見る具体例を閉じる 1. 01 責務を分ける サービスと API で責務を分けてエージェントが触れる範囲を決める ↓→ 2. 02 権限で閉じる 本番のデータやログ、認証情報にはエージェントの権限ではアクセスできない ↓→ 3. 03 仕様でつなぐ サービスどうしは、API の仕様だけでつなぐ。仕様にないことは、そもそもできない ↓→ 4. 04 失敗を構造に戻す 失敗はルールの追記だけで済ませず、責務の分け方や API の仕様、権限の見直しにつなげ、人が判断して取り込む ↺ 次の課題も、同じ構造の中でエージェントが実装する。守らせたいことは、読ませるのではなく、構造で止める 1. 01 ### API の仕様で、サービスの境界を守らせる **これまで**別の機能のデータベースを直接読む実装が入り、機能どうしが絡み合う。レビューのたびに指摘する。 **AI を組み込むと**サービスごとにデータベースを分け、ほかのサービスとは公開 API の仕様（OpenAPI）だけでつなぐ。各サービスは、ほかのサービスのデータベースへの接続先も認証情報も持たないので、境界を越える実装は書いても動かない。 境界を越える実装は、動かない # API の仕様（勤怠サービスの公開分）GET /attendance/monthly-summaryresponse: MonthlySummary # 仕様にない項目は返らない# 呼び出す側（請求サービス）+ const s = await attendance.getMonthlySummary(staffId, month)// 勤怠のデータベースへの接続先は持たない 2. 02 ### 本番のデータとログに、エージェントが届かない **これまで**不具合を調べるために、本番のデータやログを AI に見せたくなる。 **AI を組み込むと**エージェントの権限は、担当のコードとテスト用のデータまで。本番のデータベース・ログ・認証情報は別の権限にあり、エージェントからは読めない。調査は、AI が書いた集計スクリプトを人が本番の環境で実行し、結果だけを渡す。 守らせたいことを、読ませずに構造で止める # エージェントの権限（例）読み書きできる: 担当サービスのコード、テスト用のデータ読めない: 本番のデータベース、本番のログ、認証情報実行できない: マージ・デプロイ・本番の変更（人の明示的な指示のみ） 3. 03 ### 認証情報は、エージェントの環境に置かない **これまで**「API キーをコードに書かない」とルールに書いても、急ぎの修正で書かれてしまうことがある。 **AI を組み込むと**認証情報は秘密情報の保管庫（Secret Manager など）に置き、本番の環境が実行するときにだけ読み込む。エージェントの環境には本番の認証情報が入っていないので、コードにもプロンプトにも書きようがない。 ルールを守らせるのではなく、守るしかない構造にする # 本番の環境の設定（例）DATABASE_URL: 保管庫から実行時に読み込むAPI_KEY: 保管庫から実行時に読み込む# エージェントの環境本番の認証情報: なし（開発用の値だけ） SAFE BY DESIGN ### 怖いところは AI にやらせず、コードを作らせる 個人情報や秘密情報を AI に直接見せたり、本番を AI に直接操作させたりはしません。AI に渡すのはデータの形（項目名とダミーの例）だけで、AI にはそれを扱うコードとスクリプトを作らせます。人がレビューし、データがある環境の中で実行します。AI がなければ書ききれない量のスクリプトで、データを外に出さない運用をつくります。 AI に直接やらせないこと - ×本番のデータベースのデータを、エージェントに見せる - ×API キーなどの秘密情報を、コードやプロンプトに書く - ×エージェントに本番の操作を任せる 代わりに AI に作らせるもの - ✓スキーマから、匿名化したテストデータを作るスクリプト - ✓ログの個人情報を自動でマスクする処理 - ✓秘密情報が混ざっていないかを検査する CI の仕組み 1. AI がコードを作る データの形とダミーの例だけを見る ↓→ 2. 人がレビューする 処理の中身と出力を確かめる ↓→ 3. お客様の環境で実行 データはこの環境から出ない ↓→ 4. AI が受け取るもの テストと CI の結果、スキーマなどの構造情報だけ コードやテスト、仕様書の変更は、必ず人がレビューしたうえで取り込みます。本番環境での操作は、人が明示的に指示したときのみ実行します（HITL）。コードは説明のための例です。 AIOps × 第三者評価・検証 AIOPS FOR THIRD-PARTY TESTING ## 仕様書を正本に、変更に追いついていく自動テスト **この段で 伝えていること** 第三者検証では、開発側のコードは見ず、変更もしません。そのため、画面が変わったことは、自動テストが止まって初めて分かります。テストの正本を、画面の作りではなく、仕様書に書いた「操作と期待する結果」に置き、AI が Computer Use で画面の表示を読み取りながら実行します。止まったときは、不具合なのかテストの壊れなのかの候補を AI が出し、壊れたテストの修正案も書きます。合否と判断は、第三者として人が持ちます。仕様書が実際の動きから離れて古くなったときは、AI が更新案をつくり、人が確かめて確定します。 ### AI に見えるもの AI が Computer Use で画面を操作するとき、画面に表示された内容は AI に渡ります。検証環境のデータは架空のものにし、本番のデータは使いません。画面や仕様書を AI に見せること、どこで AI が処理するかは、お客様と一緒に決めます。 AI のタスク AI に見えるもの 扱い 画面を操作してテストを実行する（Computer Use） 検証環境の画面と、そこに表示されるテストデータ テストデータは架空のものにし、本番のデータは使わない。画面を AI に見せることを、お客様と確認する テストケースを下書きする 仕様書・要件・受入基準 社外秘の仕様書を AI に渡してよいかを、お客様と確認する 不具合の報告を下書きする 再現手順、画面の記録、ログ 画面とログに実在のデータが映っていないことを確かめてから渡す テストデータを作るスクリプトを書く データの形（項目名とダミーの例） そのまま渡せる 仕様書の更新案をつくる 仕様書と、動きとの食い違い・不具合の記録 仕様書と同じ扱い 具体例をコードで見る具体例を閉じる 1. 01 実行する 仕様書に書いた操作を、AI が Computer Use で画面を読み取りながら実行する ↓→ 2. 02 切り分ける 失敗したとき、画面の記録と仕様書を照らし、不具合かテストの壊れかの候補を AI が出す。人が判断する ↓→ 3. 03 直す 不具合は報告して回帰テストに加える。テストの壊れは、AI が修正案を書き、人がレビューする ↓→ 4. 04 回帰テストに戻す 直したテストを、受け入れのたびに実行する検証側の回帰テストに戻す ↺ 次の受け入れでは、直したテストで同じ範囲を確かめる。画面が変わっても、止まったままにしない 1. 01 ### 仕様書の操作を、AI が人と同じように実行する **これまで**受け入れのたびに、担当者が同じ画面操作を目視と手作業で繰り返し確認している。 **AI を組み込むと**Selenium や Playwright を土台に、AI が Computer Use で、仕様書に書いた操作を検証環境の画面を読み取りながら実行する。操作ごとの処理時間も記録する。開発側のコードには触れない。 手で確かめていた操作が、毎回同じ手順で走り、処理時間も残る # 実行の記録（請求書の CSV 出力）01 ログインする 1.2s OK02 請求書一覧を開く 0.8s OK+ 03 CSV 出力を押す 3.4s OK（基準 2.0s を超過）04 ダウンロードを確かめる 0.5s OK 2. 02 ### 画面が変わって止まったテストを、直す **これまで**ボタンの名前が「出力」から「CSV ダウンロード」に変わり、自動テストが止まる。担当者が原因を調べ、スクリプトを書き直す。 **AI を組み込むと**失敗したときの画面の記録と仕様書を AI が照らし、「仕様どおりの変更で、テストの壊れ」と候補を出す。スクリプトの修正案も書き、人がレビューして戻す。 止まったテストが、次の受け入れまでに戻る # 検証側の回帰テスト（請求書の CSV 出力）- await page.click("text=出力")+ await page.click("text=CSV ダウンロード")+ // 切り分け: 仕様書の文言の変更に合わせた修正（不具合ではない） 3. 03 ### 見つけた不具合を、回帰テストにする **これまで**修正された不具合が、その後の版で再発していないかを手作業で確認し直している。 **AI を組み込むと**報告した不具合の再現手順から、AI が画面から操作する回帰テストを作り、検証側の回帰テストに加える。 一度見つけた不具合は、次の受け入れで必ず確かめる # 検証側の回帰テスト（ログイン後の戻り先）+ // 不具合: ログイン後に元のページへ戻らない+ test("ログイン後に元のページへ戻る", async ({ page }) => {+ ...+ }) テストケース・自動テストの変更は、必ず人がレビューして取り込みます。開発側のコードは見ず、変更しません。コードは検証側のテストの例です。 AIOps × 運用監視 AIOPS FOR MONITORING ## 誤検知と仕様書にない対応を検知ルールと仕様書に反映する運用監視 **この段で 伝えていること** 監視の精度を下げるのは、誤検知と、仕様書にない対応です。誤検知が多いと、見るべきアラートが埋もれます。閉じたアラートと対応の記録を AI が振り返り、検知ルール・仕様書・確認のスクリプトの変更案を下書きします。人が確かめて、監視ツールと仕様書に反映します。どのモデルを使い、何を AI に渡すかは、お客様と一緒に検討して決めます。 ### マスクしてから、AI に渡す 仕様書づくりに要る情報は、お客様の環境の中でマスクしてから AI に渡します。AI が受け取るのは「低」の情報だけです。 1. 01 取り出す 監視ツールやチケット管理の API から、必要な項目だけを読み取りで取り出す（例 Zabbix の problem.get・trend.get） ↓→ 2. 02 マスクする お客様の環境の中で、決まったルールのスクリプトが、ホスト名・お客様名・担当者名・IP を記号に置き換える。対応表は環境から出さない ↓→ 3. 03 抜き取りで確かめる 最初のうちは、マスクした後の内容を人が確かめる。自由に書いた文章の漏れを見る ↓→ 4. 04 AI が下書きする 受け取るのは低の情報だけ。仕様書の下書きや、しきい値の試算をする ↓→ 5. 05 確かめて戻す 二次対応チームが確かめて確定し、記号を元の名前に戻す AI のタスク 必要な情報（元のレベル） マスクの仕方 AI が受け取るもの 繰り返しているアラートを洗い出す アラートの履歴、チケットの閉じた理由（中） API で項目ごとに取り出し、ホスト名を記号に置き換える 低 仕様書を下書きする 二次対応のチケットの経過、今の仕様書、監視の設定（中） チケットの本文は、ホスト名・担当者名の辞書と、IP・メールアドレス・電話番号のパターンで置き換える。監視の設定はテンプレートを書き出す 低 お客様への連絡の文例を下書きする 過去の初報・続報の文面、連絡の決まり（中） お客様名・担当者名・連絡先を置き換える 低 確認スクリプト（読み取りのみ）を書く 確認のしかた、OS・ミドルウェアの種類と版、ログの形式（低） そのまま渡す 低 しきい値を変えたときの影響を試算する メトリクスの推移、誤検知だったかの記録（中） API で数値だけを取り出し、対象を記号に置き換える 低 移譲が進んだかを数える チケットの件数（低） 件数だけを渡す 低 低＝仕様書・監視の設定・公開マニュアル・件数など、そのまま渡せる情報。中＝チケット・障害報告書・構成情報など、マスクが要る情報。高＝本番の生のログ・個人情報・認証情報。高の情報は、どのタスクにも使いません。お客様に確認いただくのは、API の権限（読み取りだけ・対象のホストグループ）と、マスクのルール（何を、どの記号に置き換えるか）の 2 つです。 具体例をコードで見る具体例を閉じる 1. 01 検知 アラートが鳴る ↓→ 2. 02 対応 一次・二次対応チームが、仕様書に沿って対処する ↓→ 3. 03 振り返り 閉じたアラートと対応の記録を AI が仕分け、変更案を下書きする ↓→ 4. 04 反映 人が確かめて、検知ルールと仕様書に反映する ↺ 次のアラートは、直したルールと仕様書で扱う。回すほど、同じアラートを繰り返さなくなる 1. 01 ### 一瞬の負荷増加を障害として扱わない **これまで**CPU 使用率が一瞬 80% を超えただけで夜間にアラートが鳴り、一次対応チームが確かめて何もせずに閉じる。 **AI を組み込むと**誤検知として閉じた記録を AI が集め、「80% を超えた状態が 〇〇 分続いたら通知する」条件への変更案を下書きする。人が確かめて監視ツールに反映する。 同じ理由の誤検知が、次から鳴らなくなる # 監視ツールのトリガー条件（API サーバーの CPU）- CPU 使用率 > 80%（一度でも超えたら通知）+ CPU 使用率 > 80% が 〇〇 分続いたら通知+ # 振り返り: 一瞬の負荷増加による誤検知が続いたため 2. 02 ### 二次対応した内容を、一次対応の仕様書にする **これまで**証明書の自動更新が失敗したときの対応が仕様書になく、そのたびに二次対応チームへ上がっている。 **AI を組み込むと**二次対応の記録から、AI が仕様書への追記と確認用スクリプトを下書きする。二次対応チームが確かめて、一次対応の仕様書に加える。 次からは、一次対応チームで対処できる ## 仕様書: 証明書の自動更新が失敗したとき+ 1. 確認用スクリプトで、期限と DNS の検証状態を確かめる+ 2. 検証用レコードが無ければ再作成して 10 分待つ+ 3. 更新されない場合は、二次対応チームへエスカレーション 3. 03 ### アラートと、見るべき仕様書を対応づける **これまで**アラートの名前だけでは何が起きたかがわからず、一次対応チームがどの仕様書を見ればよいか迷う。 **AI を組み込むと**過去のアラートと仕様書から、AI がアラートごとの重大度と参照する仕様書の対応表を下書きする。人が確かめて、監視ツールの通知文に反映する。 アラートを見れば、重大度と見るべき仕様書がすぐにわかる # アラートと仕様書の対応表+ DB の応答遅延　　　　重大度: 高　仕様書: DB の応答遅延+ アクセス数の上限超過　重大度: 低　通知しない（集計のみ）+ 証明書の期限切れ間近　重大度: 中　仕様書: 証明書の更新 検知ルールと仕様書の変更は、必ず人が確かめてから反映します。本番での操作は、人の明示的な指示でのみ実行します（HITL）。内容は説明のための例です。 AIOps × BPO AIOPS FOR BPO ## 届出と問い合わせの正確性を、チェックと手順化で高める **この段で 伝えていること** 人事労務の業務で正確性を左右するのは、届出の不備の見落としと、担当者ごとにばらつく問い合わせへの回答です。マスクした対応記録をもとに AI がチェックルールや仕様書を下書きし、担当者が確認したうえで取り込みます。不備を受付の段階で見つけ、誰が対応しても同じ回答ができる体制を整えます。 ### マスクしてから、AI に渡す 届出や問い合わせの記録は、お客様の環境内でマスクしてから AI に渡します。AI が受け取るのは、区分「低」の情報だけです。 1. 01 取り出す 人事労務システムや問い合わせの記録から、必要な項目だけを読み取り専用で抽出する ↓→ 2. 02 マスクする お客様の環境内で、決まったルールのスクリプトが氏名・社員番号・連絡先を記号に置き換える。マイナンバー・給与・口座の項目は抽出しない ↓→ 3. 03 抜き取りで確かめる 導入初期は、マスク後の内容を担当者が確認し、自由記述の欄に漏れがないかを見る ↓→ 4. 04 AI が下書きする 受け取るのは区分「低」の情報だけ。チェックルール・仕様書・回答案・検証スクリプトを下書きする ↓→ 5. 05 確かめて戻す 下書きを担当者が確認して確定し、記号を元の情報に戻す AI のタスク 必要な情報（元のレベル） マスクの仕方 AI が受け取るもの 差し戻し理由からチェックルールを作成する 差し戻しの記録（中） 氏名・社員番号を記号に置き換え、届出の原本は渡さない 低 問い合わせの仕様書と回答案を作成する 問い合わせの対応記録（中） 氏名・部署・連絡先を記号に置き換える 低 取込データの検証スクリプトを作成する 列の定義（項目名・型・コード値）（低） そのまま渡す 低 繰り返し発生している確認作業を洗い出す 受付と差し戻しの件数（低） 件数だけを渡す 低 情報の区分は、低＝列の定義や件数など、そのまま渡せる情報。中＝差し戻しや問い合わせの記録など、マスクが必要な情報。高＝マイナンバー・給与・口座・届出の原本で、どのタスクにも使いません。お客様にご確認いただくのは、抽出する項目と、マスクのルール（どの情報をどの記号に置き換えるか）の 2 点です。 具体例をコードで見る具体例を閉じる 1. 01 受付 届出・申請・問い合わせを受け付ける ↓→ 2. 02 確認・対応 担当者が内容を確認して登録し、その対応手順をシステム化する ↓→ 3. 03 振り返り 繰り返し発生する確認作業やイレギュラーな対応を AI が分析し、仕組み化できる業務を仕分ける ↓→ 4. 04 チェックと手順に 自動チェックや仕様書、スクリプトを AI が作成し、担当者がレビューして自動処理の仕組みに反映する ↺ 次回からの届出は、自動チェックを通したあとに担当者が確認する。このサイクルを回すほど、差し戻しやイレギュラーな対応が減っていく 1. 01 ### 届出の不備確認を自動チェック化する **これまで**入社の届出を受けるたびに、必須項目の記入漏れや日付の不整合を担当者が目視で確認している。 **AI を組み込むと**差し戻し理由（氏名などはマスク）を AI が分析し、受付時に自動で実行するチェックルールを下書きする。担当者が確認したうえでシステムに組み込む。 差し戻しが必要な不備を、受付の段階で見つける # 届出のチェックのルール（入社）+ - 必須: 雇用区分・入社日・給与の支払方法+ - 整合: 入社日は雇用契約の開始日と同じ+ - 差し戻しの文面: 入社の届出の不足（定型文） 2. 02 ### 仕様書にない問い合わせを手順化する **これまで**手順化されていない問い合わせに対し、担当者がその都度調べて回答しているため、ノウハウが蓄積されない。 **AI を組み込むと**マスクした対応記録から AI が仕様書と回答案を下書きし、担当者が確認したうえで共通の仕様書に追加する。 同じ問い合わせには、誰が対応しても手順どおりに回答できる # 仕様書（有給休暇の問い合わせ）## 有給休暇の残日数が合わないと言われたとき+ 1. 付与日と前年度からの繰り越しを確認する+ 2. 半休の申請が二重に登録されていないか確認する 3. 03 ### 取込データの検証をスクリプト化する **これまで**システムに取り込む CSV のエラーにより、修正と再取り込みの手戻りが繰り返し発生している。 **AI を組み込むと**エラーの原因を AI が整理し、取り込む前に自動で検証するスクリプトを作成する。 取り込みエラーを、取り込む前に見つける # 取込データの検証スクリプト+ # 文字コードは Shift_JIS（CP932）+ # コード値は名称ではなく ID で入れる+ # 条件を満たすと必須になる列も検証する チェックルール・仕様書・スクリプトの変更は、必ず担当者がレビューしたうえで反映します。給与支払いの確定などの判断は、あらかじめ定めた権限者が行います。コードは説明のための例です。 ![](/media/newsite-contact-hero.png) ## CONTACT ご相談の内容が固まっていなくても構いません。下記のフォームからお気軽にお問い合わせください。 [▶お問い合わせ](/contact)