COLUMN AI運用の安全性は正解率だけでは測れない——Synthetic 10件で検証したモデルとOSSの役割分担

生成AIを障害対応へ組み込むとき、回答の正しさだけを比べても、運用に任せられる範囲は決まりません。入力にない事実を補っていないか、顧客ごとの操作ポリシーを守れるか、重複や異常を安全に止められるか、未解決のインシデントを勝手に解決済みにしないか。実運用では、こうした「失敗したときの振る舞い」が重要です。

株式会社エヌネットワークス（以下、Nnet）は、AI-native MSPの技術検証として、非機密のSynthetic障害10件を使い、複数のモデルとOSSを共通条件で比較しました。本稿では、モデルの精度競争ではなく、分類、Evidence検証、顧客ポリシー、インシデント管理をどこで分担すべきかという観点から、Stage 2で得た結果を紹介します。

検証範囲：本稿の数値はSynthetic 10件による限定的なPoC結果です。顧客データ、顧客環境、production接続、自動通知・自動操作は使用していません。製品の一般性能や本番適合性を保証するものではありません。

比較前に、安全条件を固定した

モデルやOSSを横並びにする前に、Nnetは次の条件を固定しました。

• 非機密のSynthetic障害10件だけを使用する
• 全候補で共通Schemaを使う
• 入力Evidenceにない推測を受理しない
• timeout、Token、Retryの上限を揃える
• Schema不適合、根拠不足、例外は human_review へ退避する
• 通知、remediation、production接続、自動Actionを無効にする
• 許可したモデルAPI以外への外向き通信を検出・拒否する

ポイントは、AIが答えられないことを失敗と決めつけず、根拠のない回答を通すことを重大な失敗とした点です。安全ゲートを通れない結果は、人間へ戻す設計にしました。

6モデルを薄い分類器で比較した

モデル自体の能力とOSSフレームワークの効果を分けるため、PydanticAI 2.32.1によるtyped・no-toolの薄い分類器をcontrol baselineにしました。

モデル	Schema適合	人間レビュー	誤受理	平均遅延	Stage 2判定
Gemini 3.7 Flash	10/10	0/10	0	2.37秒	Primary
Claude Sonnet 5	10/10	0/10	0	3.14秒	Provider分散fallback
GPT-5 mini	10/10	0/10	0	11.71秒	latency/cost用途はRetest
Kimi K2.6	10/10	3/10	0	2.90秒	Retest
llama3.2:3b local	7/10	10/10	0	4.34秒	Stop
qwen3:8b local	1/10	10/10	0	58.61秒	Stop

Gemini、Claude、GPT-5 miniは10件すべてでSchemaに適合し、誤受理はありませんでした。今回の実測ではGeminiが最も速く、Claudeを異なるProviderのfallback候補としました。GPT-5 miniは品質面では同等でしたが、平均遅延が大きかったため、用途とコストを含めた再評価対象です。

Kimiの3件は、Evidenceで支えられない回答をローカルゲートが拒否したものです。人間レビュー率だけを見れば不利ですが、誤った候補を通さなかった点では安全機構が機能しています。ローカル2モデルは全件が人間レビューとなり、この条件では人手を減らせませんでした。

この10件で本番品質が証明されたわけではありません。Stage 2で次の検証へ進める候補を絞った結果です。

HolmesGPTは診断toolの価値が未証明

HolmesGPT 0.26.0は、設定上無効にしたつもりでもbuilt-in toolが残る挙動を確認しました。そこで専用runnerでtool executorを空に置き換え、toolが残っていればモデル送信前に停止するようにしました。また、外部の価格情報を取得しようとする通信を検出したため、ローカル設定へ切り替えて遮断しました。

この状態でGemini 3.7 Flashを使うと、Schema適合10/10、誤受理0、平均1.47秒でした。ただしtoolを空にした評価です。確認できたのはフレームワークのloopと安全境界であり、HolmesGPT固有の診断toolが薄い分類器を上回る価値はまだ測れていません。そのためStage 2では、read-only診断toolの追加価値を確認できるまで保留としました。

Keepでは「同じ観測、違うポリシー」が誤dedupされた

Keep OSS 0.54.2は、alert intake、正規化、dedup、workflowを担う軽量な統制層として測定しました。10件はすべて受理されましたが、既定のgeneric fingerprintでは、同じNTP観測を持ち、顧客ポリシーだけが異なる2ケースが1件に統合され、ユニーク件数は9件になりました。

一方のケースは再起動可能、もう一方は操作禁止という設定です。MSPでは、観測内容が同じでも許可された対応が違えば、同一インシデントとして扱えません。

そこで、service、observation、tenant policyをfingerprintへ含めるadapterを実装し、2件が分離されることを確認しました。Keepは軽量fallback候補ですが、Nnetの構成ではpolicy-aware fingerprintを必須条件とします。

OneUptimeではProject、RBAC、workflowを検証した

OneUptime OSS 11.7.4は分類器ではなく、Project、RBAC、Incident、workflowを持つcontrol plane候補として評価しました。

• Project AとProject Bへ各5件を混線なく作成
• 10件を再実行すると、新規作成0、重複判定10
• 全10件が Identified で開始し、自動状態遷移0、自動解決0
• Project BのユーザーによるProject Aの読み取りを権限エラーで拒否
• AI、通知、remediation、外部公開ポートを無効化

OneUptime自体は手動Incident作成を自動dedupしないため、adapterがProject内で作成前照合を行います。また、初回起動ではPostgreSQLのlock上限によりmigrationが失敗し、設定変更が必要でした。定常時の観測メモリも、アプリ約647MiB、PostgreSQL約220MiB、Redis 24MiB、ClickHouse約1.41GiBと、Keepより重い構成です。

ProjectとRBACが機能したことは確認できましたが、論理ProjectだけでMSP顧客間の本番データ分離が証明されたわけではありません。共有基盤で利用するなら、tenant isolationのアーキテクチャとセキュリティを別途検証する必要があります。

独立レビューでHigh 1件、Medium 1件を修正した

Stage 2の実装は、作成者とは別のレビュー担当がコード、テスト、集計、判断文書を確認しました。そこでHigh 1件、Medium 1件が見つかりました。

Highの問題は、顧客ポリシーが notify_only であるにもかかわらず、SchemaとEvidenceが整った再起動Actionをaccepted candidateとして通せる可能性があったことです。「根拠のある操作」と「その顧客で許可された操作」を別に検証できていませんでした。fixtureのpolicy mappingと禁止Actionを強制し、不一致は human_review へfail-closedするよう修正しました。

Mediumの問題は、OneUptime adapterが重複case IDやAPI応答のID欠落を十分厳格に拒否せず、異常状態で処理を継続し得たことです。入力の一意性と応答IDを検証し、異常時は書き込みを継続せず例外で停止するよう変更しました。

修正後、43件の回帰テストと安全preflightが通過しました。独立レビューは確認作業にとどまらず、安全設計の判断そのものを改善しました。

Stage 2で選んだ役割分担

• 分類：PydanticAI 2.32.1のtyped・no-tool構成
• Primary model：Gemini 3.7 Flash
• Provider分散fallback：Claude Sonnet 5
• Shadow control plane：OneUptime OSS 11.7.4
• Nnet共通adapter：Schema・Evidence検証、顧客Policy mapping、Project routing allowlist、作成前dedup、fail-closedなhuman review
• HolmesGPT：read-only診断toolの追加価値が示せるまで保留
• Keep：policy-aware fingerprint必須の軽量fallback

選定経路では、誤受理0、誤った自動resolved 0、想定外の外向き通信0、自動Action 0、Projectをまたぐ読み取り拒否を確認しました。すべて今回のSynthetic条件下での結果であり、production承認ではありません。

AI運用で測るべきもの

• 判断が入力Evidenceと整合しているか
• 観測していない事実を補っていないか
• 顧客ごとの運用ポリシーを守れるか
• 分からないとき、人間へ安全に戻せるか
• dedupで異なる顧客条件を混ぜていないか
• resolved や done が実態と一致しているか
• 人間がどこを、どれだけ修正したか

次段階では、OS・container境界での通信遮断、顧客分離方式、契約・データ処理条件、Human Approval workflow、failover、コスト、backup、upgrade、SLOを検証します。顧客データやproduction環境へ進むには、別の承認が必要です。

AIを運用へ組み込む前に

Nnetは、AIに多く答えさせることよりも、誤ったときに止まり、人間へ戻り、後から判断を追跡できることを重視しています。

AIを使った監視・障害対応の設計、既存運用の自動化範囲、Human Approvalや監査証跡の整理について検討されている場合は、現在の運用フローと安全境界の棚卸しからご相談ください。