はじめに

こんにちは、MSPセクションの毛利です。

前回の記事では、PagerDuty on Tour Tokyo 2026で得た気づきをもとに、MSPセクションとして目指す方向性をお伝えしました。

「人がシステムを管理する」状態から、「システムがシステムを管理し、本当に必要な時だけ人が介入する」状態へ

あれから約2か月。ビジョンを語るフェーズから、実際に手を動かすフェーズに入りました。

今回は、私たちのチームが今期のミッションとして本格的に始動した取り組みについて、なぜやるのか、何を目指しているのか、どう進めるのかをお伝えします。具体的な技術の話は今後のブログで書いていきますので、まずは「宣言」として読んでいただければ嬉しいです。

🏔️ MSPが直面する「スケールの壁」

KDDIアイレットのMSPは、AWSやGoogle Cloud、OCIなど、お客様のクラウド環境を24時間365日監視し、アラート対応を行っています。

しかし、MSPの業務はアラート対応だけではありません。クラウド事業者からのセキュリティ通報への初動対応、お客様からの緊急の問い合わせ対応など、迅速な判断と正確な情報伝達が求められる業務が日常的に発生します。こうした業務では、お客様の環境構成の確認、関連情報の収集、お客様への連絡、クラウド事業者への報告、社内関係者への連携など、複数のステップを正確に、迅速にこなす必要があります。

事業がスケールしていく中で、お預かりするお客様環境の数は増え続けています。アラート対応は、お客様の環境に合わせた対応が求められる、MSPの重要な仕事です。

一方で、アラート対応以外の業務 ── セキュリティ通報への対応、緊急の問い合わせ対応、それらに伴う情報収集や文面作成、関係者への連絡 ── こうした作業も同じくMSPの重要な仕事であり、対応件数の増加とともに確実に積み重なっていきます。

今の運用のまま件数だけが増えれば、早々に限界を迎える。今期は、その限界を超えるための基盤を整備する年だと位置づけています。

🎯 チームのミッション：アラート対応「以外」の業務を効率化する

私たちのチームのミッションは明確です。

アラート対応以外の業務を効率化し、チームが本来集中すべき判断業務にリソースを割けるようにする

セキュリティ通報への対応や緊急の問い合わせ対応は、判断そのものは人が行うべき業務です。しかし、判断の「周辺」にある作業 ── 情報の収集、定型文面の作成、関係者への連絡文の準備 ── は、仕組みで支えられるはずです。

前回の記事で触れた「8割の定型作業を自動化し、2割の例外処理に人を割り当てる」という考え方を、自分たちの現場で実践していくことになります。

🔄 AIを「個人」から「組織」へ、「補助」から「代替」へ

私自身、AIコーディングツールを使った業務効率化には以前から取り組んできました。シフト表の自動生成、Slack投稿の分析、問い合わせの一覧化など、個人の業務改善としては一定の成果が出ています。

しかし、個人の取り組みには限界があります。

  • 作った人しか直せない ── 異動や退職で使えなくなる
  • ノウハウが属人化する ── 他のチームに展開できない
  • 品質の担保が難しい ── レビューやテストのプロセスがない

まさに、前回の記事で書いた「属人化した運用には持続性がない」そのものです。AIを使っていても、使い方自体が属人化していたら意味がありません。

今期の取り組みで目指すのは、AIの活用を「個人」から「組織」へ、「補助」から「代替」へシフトさせることです。

「補助」 とは、AIに手伝ってもらいながら人が作業するような使い方。「代替」 とは、これまで人が行っていた業務をAIの仕組みで置き換え、自動化することです。

「代替」に到達するには、プロンプトの工夫だけでは不十分です。業務のプロセスを理解し、仕組みとして設計する必要があります。

では、その「仕組み」をどうやって作るのか。私たちが目指したいのは、ちゃんと設計し、設計をもとに開発し、引き継げるようにする ── チームで継続運用できる仕組みです。

📐 バイブコーディングではなく「スペック駆動開発」

AIにコードを書かせるアプローチとして「バイブコーディング」という言葉が話題になっています。自然言語で雰囲気を伝えて、AIにコードを生成してもらうスタイルです。個人の試作やプロトタイピングには強力ですが、チームで継続運用する仕組みを作ろうとすると課題が見えてきます。

  • 仕様が会話の中にしか残らない
  • 作った人以外がメンテナンスできない
  • 変更の影響範囲がわからない
  • レビューの基準がない

こうした課題に対して、私たちが試すことにしたのがスペック駆動開発（Spec-Driven Development）です。

要件定義や設計をドキュメントとして先に書き、AIはそのドキュメントに基づいてコードを生成するアプローチです。一見すると従来のウォーターフォールに見えるかもしれませんが、本質は「AIへの指示を構造化し、再現可能にする」ことにあります。

  • 仕様がドキュメントとして残る → 引き継ぎができる
  • モジュール単位で分担できる → チーム開発ができる
  • テストの基準が明確になる → 品質を担保できる

つまり私たちはスペック駆動開発を、AIの力を活かしながら、保守・拡張・引き継ぎが可能な仕組みを作るために取り入れていきます。

こうしたスペック駆動開発の特徴が、前回掲げた「属人化の解消」と「システムが支える運用への改善」を実現する手段にもなり得ると考えています。

🛡️ 最初のテーマ：セキュリティ通報（Abuse Report）対応の自動化

最初に取り組むテーマとして選んだのは、クラウド事業者からのセキュリティ通報への初動対応の自動化です。

クラウド環境でアカウントの不正利用が疑われる場合、クラウド事業者からAbuse Reportと呼ばれるセキュリティ通報がアカウント管理者に届きます。たとえばアクセスキーの漏洩が検知された場合、お客様への連絡メール、クラウド事業者への一次回答、社内関係者への連携など、複数の対応を迅速に行う必要があります。

対応手順は標準化されていますが、情報収集から文面作成までには一定の時間がかかります。まさに先ほど触れた「判断の周辺にある作業」の典型例です。

この対応のうち、「判断」は人が行い、「情報収集」や「文面のドラフト作成」はAIが担うという分担で自動化を進めます。最終的な送信や実行はすべて人が行う、human-in-the-loop のアプローチです。

前回の記事で触れた「AIは『魔法の杖』ではなく『増幅器』」という考え方を、そのまま設計思想に落とし込んでいます。

🌱 チームのチャレンジも同時に

MSPのメンバーは、日々のアラート対応やお客様対応のプロフェッショナルです。しかし、要件を整理し、設計し、実装し、テストするというソフトウェア開発の一連のプロセスを経験する機会は、そう多くありません。

今回のプロジェクトでは、実際の業務課題を題材に、この一連の開発プロセスにチームで取り組みます。「何を作るか」を自分たちで定義し、「どう作るか」を設計し、手を動かして形にする。これ自体が、今回の取り組みのもう一つの本質だと考えています。

今回あえてこのやり方を選んだのは、開発自体も属人化させず、組織として取り組んでいく流れを作りたいと考えたからです。

AIコーディングツールを使い、さらに「課題を分解し、設計し、形にする」という開発を体験すること ── これは、MSPの業務を超えて、さまざまな場面で活きる普遍的なスキルと考えています。

前回の記事で掲げた「オペレーターから『新しい価値を創出するエンジニア』への転換」。その第一歩を、このプロジェクトから踏み出します。

📢 今後予定しているブログ

この取り組みは始まったばかりです。今後、以下のようなテーマでブログを書いていく予定です。

  • スペック駆動開発の実践 ── 要件定義・モジュール分担の実際
  • AIを活用した運用自動化のアーキテクチャ ── human-in-the-loop の設計思想
  • チーム開発の進め方と振り返り ── 学習と実務を両立させる工夫

うまくいくことばかりではないと思いますが、試行錯誤の過程も含めて発信していきます。同じように運用現場でAI活用に取り組んでいる方にとって、何かの参考になれば嬉しいです。

学習する組織。学習に終わりはない。

前回の記事を、この言葉で締めくくりました。今回はその「学習」を、チームとして実践に移すタイミングです。

次回の記事でまたお会いしましょう。