最優先事業を決めた初日、AIの「正解」より先に失敗の止め方を作った

2026年8月20日、Nnetで進める最優先の事業計画を決めた。

テーマは「MSP Agent OSS / AI-native MSP」。インシデントの一次調査や判断、エスカレーション、記録といった運用の仕事を、AIにどこまで任せられるのかを実証していく。

名前だけを見ると、AIエージェントを作る技術プロジェクトに見える。でも、初日にいちばん時間を使ったのは、賢い回答を出す方法よりも、AIが間違えたときにどう止めるかだった。

「動いた」と「任せられる」は違う

最初は複数のOSSエージェントへ、同じ架空の障害ケースを渡して比較した。

クラウドモデルへ変えると、ローカルの小さなモデルより回答は改善した。それでも、入力にないログの増加を根本原因として補ったり、処理に長い時間がかかったり、1件で大量のトークンを使ったりした。

デモとしては動いている。文章もそれらしい。でも、実際の運用を任せられる状態ではなかった。

そこで、比較方法から作り直した。非機密のSynthetic障害10件、共通の出力形式、同じ時間とトークンの上限、Evidenceにない推測は禁止。条件を固定して、モデルの能力とOSSの仕組みを分けて測った。

ここで意識したのは、AIが分からないときに「分からない」と言えることだ。出力形式が崩れた、根拠が足りない、禁止された操作が含まれる。そんなときは正解らしい答えを無理に通さず、人間のレビューへ戻す。

独立レビューで、安全設計の穴が見つかった

検証コードを書き、テストが通った後、別のAIエージェントに独立レビューを任せた。

そこで、重要な欠陥が見つかった。顧客のルールが「通知だけ」なのに、根拠と形式さえ整っていれば、再起動という禁止Actionを候補として通せる可能性があった。

技術的に妥当な操作でも、その顧客では実行してはいけない。AI運用では、一般的な正しさより顧客ごとのPolicyが優先される。その当たり前を、最初の実装では完全に強制できていなかった。

もう一つ、管理基盤へ記録する処理にも、重複したケースIDやAPI応答の欠落を厳格に拒否できない箇所が見つかった。どちらも修正し、回帰テストを追加した。最終的に43件のテストが通った。

独立レビューを入れなければ、「安全に作れた」と思ったまま次へ進んでいたかもしれない。初日に失敗が見つかったことは、悪い進捗ではない。むしろ、この事業で公開していくべきEvidenceだと思っている。

AIラボも「試す場所」から「証明する場所」へ

今回、AIラボの位置づけも変えた。

これまでは、新しいAIツールやAI社員を幅広く試す意味合いが強かった。これからは、AI-native MSPの事業仮説、品質、安全性、運用方法を証明する実行主体にする。

新しいツールを使うこと自体を成果にはしない。「何を証明する実験なのか」「結果によって何をGo、Retest、Stopにするのか」を先に決める。実装して終わりではなく、判断まで同じ記録につなげる。

チームへの仕事の渡し方も見直した。いきなりOSSの採否やAIの回答品質を判断してもらうのではなく、Alert、Incident、Evidence、Escalation、Hallucinationといった基礎から段階的に進める。AI-nativeな組織は、人を飛ばして作るものではない。人間側が事実と推測を分け、不明点を質問し、Evidence付きで報告できることもシステムの一部だ。

成功だけを広報しない

この事業で扱いたい問いは、シンプルだ。

人間の仕事は、AIにどこまで任せられるのか。

答えを、派手なデモや成功例だけで示すつもりはない。誤判断、止めたケース、人間へ戻した理由、時間、原価、修正量も測っていく。

今日決まった構成も、まだSynthetic環境での候補にすぎない。顧客データや本番環境へ接続する承認はしていない。次は、通信の隔離、顧客間の境界、Human Approval、障害時の復旧、コストなどを一段ずつ検証する。

最優先事業を決めた初日は、完成を発表する日にはならなかった。

代わりに、失敗をどう見つけ、どう止め、どう記録するかを決めた。AIへ仕事を任せる会社を作るなら、たぶん正しい始まり方だと思う。

モデルとOSSの比較結果、採用したStage 2構成、安全境界の詳細は、Nnetの技術コラム「AI-native MSP Stage 2：Synthetic 10件でモデルとOSSを比較し、安全に止まる構成を選んだ」にまとめた。