MCPがAIとインフラストラクチャの間の欠落したリンクである理由

私はインターネット、仮想化、クラウド、そしてAI/MLの進化を目の当たりにしてきました。しかし、今起きていることに対して、これほどまでに活力を感じたことはありません。

綿密な計画、意図的な変更期間の設定、そして広範な手作業は、ストレージアーキテクトおよびIT運用リーダーとしての私のキャリアの大部分を特徴づけてきました。複雑なグローバルIT環境には、長年の運用履歴、蓄積された技術的負債、そして無数の「これは後で片付けよう」という決定が蓄積されています。

エージェント型AIには計り知れない可能性が秘められているが、常に問題があった。それは、AIが理解できないインフラを管理できないということだ。

そこでModel Context Protocol（MCP）の出番です。

ほんの数ヶ月前までは理想的に思えていたものが、今では NetApp IT 社内で積極的に活用されています。MCP は AI 支援オペレーションの基盤となり、AI エージェントが問題を分析し、ONTAP 環境を調査し、根本原因を明らかにし、これまでは不可能だった方法でトラブルシューティングを加速するために必要なインフラストラクチャのコンテキストを提供します。

未来へのビジョンとして始まったものが、あっという間に今日の私たちの業務運営方法の一部となりました。

MCPが解決するAIの問題

AIは推論能力に非常に優れていますが、企業インフラにおいては推論能力だけでは不十分です。

AIモデルは、お客様のONTAPクラスター、SnapMirrorの関係性、ストレージトポロジー、運用標準、あるいは数十年にわたって蓄積された構成上の意思決定を自動的に把握するわけではありません。そのようなコンテキストがなければ、AIは推測するしかありません。ドキュメントの検索、意図の推測、推奨事項の提示は可能ですが、稼働中のインフラストラクチャと確信を持ってやり取りするために必要な運用知識が不足しています。

MCPは方程式を変えます。

簡単に言うと、MCPはAIエージェントにONTAPのようなシステムを理解して対話するための構造化された方法を提供します。これは、憶測に頼るのではなく、有意義な業務を遂行するために必要なコマンド、機能、および運用知識を提供します。

MCPは、AIとインフラストラクチャ間の翻訳機のようなものだと考えてください。AIモデルがリクエストを受信するたびにONTAPを調査することを強制する代わりに、MCPはAIモデルが利用可能なアクション、システムの構成方法、およびそれらと安全にやり取りする方法を理解するための確実な手段を提供します。

「もしも？」から「やろう！」へ

AIを活用したストレージ運用について初めて語り始めた頃は、その多くが理論的なものに聞こえたことでしょう。

ストレージ、ネットワーク、コンピューティング、クラウド、アプリケーション向けのAIエージェントが、システム障害発生時にすべて連携して動作する様子を想像してみてください。各エージェントは、自身の領域を理解しています。それぞれがインフラの担当部分を調査します。そして、それらのエージェントは調査結果を関連付け、根本原因の特定に役立てます。

それがビジョンだった。ついに完成しました。

NetApp IT内部では、エージェントワークフローを使用して、ServiceNowチケットを取得し、説明を読み取り、インフラストラクチャのコンテキストで情報を補完し、MCPを通じてONTAPにクエリを実行し、関連ドメインをクロスチェックして、数分でRCAスタイルの分析を生成します。

ある例では、ユーザーからNASパスをマウントできないという報告がありました。チケットにはNFSとは記載されていませんでした。ONTAPも特定されていませんでした。調査対象のクラスター、SVM、ボリューム、またはリージョンも明記されていませんでした。

エージェントはそれでも真相を突き止めました。MCPを使用して、ServiceNowとCMDBデータを分析し、ONTAPを検査し、UNIX側を検証した結果、問題はNFSのエクスポート ルールであることが判明しました。さらに、ホスト上の他のマウントが正常に機能していることを確認してから、信頼性の高いクロスドメイン分析を作成しました。

エージェント型AIの活用

P1レベルのインシデント対応に携わったことのある方なら、そのパターンをご存知でしょう。チケットが届く。担当者がブリッジに参加する。各チームは自分たちのドメインの確認を開始する。ストレージはストレージを確認する。ネットワークはスイッチを確認する。Compute はホストを確認する。アプリケーションチームはログを確認する。

では、代わりにこう考えてみてください。

• ServiceNowチケットがAIによる調査をトリガーする
• コーディネーターエージェントが問題文を読み取る
• ストレージエージェントは ONTAP MCP を使用して、関連するクラスター、SVM、ボリューム、エクスポート、SnapMirror関係、およびパフォーマンスデータを検査します
• UNIXまたはWindowsエージェントがホスト側をチェックします
• ネットワークエージェントがストレージ ファブリックとレイヤー2をチェックします
• コーディネーターは、複数の領域にわたる調査結果を比較します。
• システムは調査の概要を投稿し、チケットまたはウォールームへの次のステップを推奨します

現在、私たちが行っていることの多くは読み取り専用であり、特に本番環境におけるインシデント対応ワークフローにおいてはその傾向が顕著です。読み取り専用はリスクが低く、影響は大きいものです。AIがエンジニアに対し、どこを調べるべきか、何が変更されたのか、何が設定ミスなのか、そして何がインシデントの原因である可能性が最も高いのかを迅速に伝えることができれば、それだけで対応時間を大幅に改善できます。

AIは「非人間的」な問題に取り組むのに役立つ

もう一つの大きな機会は、技術的負債です。

どの企業にも、概念的に複雑だから難しいわけではない問題が存在する。それらが難しいのは、規模が大きすぎたり、手間がかかりすぎたり、あるいは分散しすぎていて、人間が効率的に解決できないからである。

例えば、AIに数十のONTAPクラスターと数百のノードにわたるローカルアカウントを監査するよう依頼することができます。これは単純なスプレッドシート作業ではありません。最終ログイン情報は、ユーザーアカウントに直接保存されるのではなく、セキュリティログに保存される場合があります。担当者はエクスポートデータを収集し、データを統合し、ログを確認し、タイムスタンプを比較し、手作業で有用なレポートを作成する必要があります。

ONTAP MCPを使えば、自然言語で質問するだけで、数分以内にフリート全体の分析結果を受け取ることができます。手作業によるデータ収集、スプレッドシート作業、ログの確認に何時間も要していた作業が、シンプルなプロンプトを入力するだけで完了できるようになりました。

同じ考え方が、古いスナップショット、孤立した SnapMirrorデスティネーション ボリューム、不整合な構成、欠落している保護関係、ライフサイクル計画、および容量のクリーンアップにも適用されます。

こうした問題は、手作業で対処するにはあまりにも煩雑なため、何年も未解決のまま放置されることがあります。MCP対応AIは、これらの問題を解決し、解決された状態を維持する方法を提供します。

自動化の不備によってSnapMirrorデスティネーションボリュームが取り残されてしまった場合、一度限りのクリーンアップで解決すべきではありません。解決策としては、その状態を定期的にチェックし、報告し、最終的には承認された対策を通じてその状態を改善する、エージェント型ワークフローを構築すべきです。

手作業によるクリーンアップから継続的なハイジーン管理へと移行しています。

自然言語によって自動化できる人が変わる

自動化はもはやコードを書く人だけに限定されるものではありません。

この取り組みの初期段階で、私はチーム向けにデモを作成し、冗談で「Storage Hotness」と名付けました。画期的だったのは、MCPを通じてモデルをONTAPに接続したことです。AIエージェントをONTAPシミュレータに接続し、平易な英語でリクエストを入力し始めました。

• Create volumes
• ボリュームのサイズを変更する
• SnapMirror関係の構築
• 変更内容を表示する

私はほぼ10年間、ONTAP を直接操作していなかったにもかかわらず、自然言語を使ってストレージを管理していました。その瞬間が、チームに何が可能かを認識させるきっかけとなりました。

私たちの役割は変化しつつあります。エンジニアがいなくなるわけではありませんが、仕事内容は変化しています。私たちは、AIを活用した業務のオーケストレーター、レビュー担当者、品質管理者になりつつあります。これらのツールを使いこなせるようになった人は、その影響力を何倍にも高めることができるでしょう。手作業によるワークフローに固執し続ける人々は、変化についていくのに苦労するでしょう。

なぜNetApp ITがこれを証明するのに最適な場所なのか

NetApp IT部門は、お客様が使用するのと同じテクノロジーを使用しているため、他に類を見ない立場にあります。

私たちは、ONTAP、StorageGRID、Eシリーズ、Amazon FSx for ONTAP、Cloud Volumes ONTAP、Data Infrastructure Insights、およびその他のNetAppテクノロジーを実際のグローバルエンタープライズ環境で運用しています。

私たちは、研究室だけの環境でストレージのためのAIを検討しているわけではありません。私たちはそれを、実際のインフラ、実際のインシデント、実際の技術的負債、そして実際の運用上のプレッシャーに適用しています。

私たちはこれらのテクノロジーをエンタープライズ規模で運用しているため、MCPがトラブルシューティングを加速させ、活用されていない容量を発見し、構成のずれを特定し、長年にわたって蓄積された技術的負債を明らかにする様子を直接目の当たりにしています。

エージェントが数分で有用なRCAスタイルの分析を作成するのを見ると、これがITチームの障害対応方法をどのように変えることができるのかが理解できます。

そして、何かがうまくいかない場合も、そこから学ぶことができます。

会話できるストレージ

多くの人が思っているよりも、インフラがインテントによって管理される未来は、はるかに近いところにあります。

経営幹部は「我々にはどれくらいのキャパシティがあるのか？」と問いかけるでしょう。

エンジニアは「どの本番ボリュームに保護が欠けているのか？」と問いかけるだろう。

運用チームは「このインシデントの発生前に何が変わったのか？」と問いかけるでしょう。

ストレージチームは「未使用の容量はどこにあるのか？」と問いかけるでしょう。

AIエージェントは、状況情報を収集し、環境に問い合わせを行い、結果を分析して、行動を推奨します。それは技術的な判断に取って代わるものではなく、むしろそれを増幅させるものです。

将来は、AIがストレージエンジニアに取って代わるというものではありません。未来は、ストレージエンジニアがAIエージェントの群れを指揮し、人間が手作業では決して成し遂げられない規模で、検査、分析、相関分析、そして最終的には修復を行う時代となるでしょう。

私のキャリアの中で初めて、データセンターの運用層が書き換えられようとしています。MCPは、AIによる推論と実際のインフラアクションを結びつける架け橋の一つです。MCPがなければ、AIは単なるアシスタントに過ぎません。MCPがあれば、AIは運用上の能力乗数となります。

そして今回は、理論上の話ではありません。私たちは既にそれを実行しています。