Claude Code をウェブサーバー管理に活用してみてわかった – 得意なこと・苦手なこと

はじめに

弊社では生成 AI ツールとして様々なサービスを利用していますが、その中でも開発者の多くは Claude Code を多くの場面で活用しています。Claude Code は非常に汎用的なツールであり、ソースコードの生成はもちろん、オペレーションの自動化といった日々の業務の工数圧縮に大きく貢献しています。適切な権限を与えれば、ローカルのファイルを生成するだけではなく、リモートサーバーに SSH 接続を行い、そのサーバーの調査やメンテナンス、ソースコードのデプロイなど様々なことに利用ができます。

本記事では、ウェブサーバーの管理業務に対して Claude Code を実際に使ってみた経験をもとに、「どのような場面で力を発揮したのか」「どのような場面では別のアプローチが必要だと考えたか」を整理してお伝えします。

想定よりもうまくいったケース：既存環境の調査とオペレーション

最近のウェブ開発では Vercel や Kubernetes、AWS Fargate などを利用し、ウェブサーバーの OS レイヤーの管理を任せてサービスを運用するケースも増えてきました。しかし、例えば WordPress を使う場合などは依然としてサーバーを構築・管理する必要があります。

こうした既存サーバーに対する内部調査やオペレーションにおいて、Claude Code（今回は Opus 4.7 with medium effort）を使ってみたのですが、その結果、非常に高い精度でタスクを完遂することができました。

SSH 経由でのサーバー接続

Claude Code には SSH 接続用の情報（接続先、ユーザー名、秘密鍵のパスなど）を渡すことで、サーバーに SSH 接続を行い、そのユーザーの権限でサーバー内部の調査や操作を行うことができます。今回のケースでは自分の PC からターミナルで Claude Code を起動し、対象サーバーへ SSH する形で指示を出していました。 

WordPress の操作

WordPress の内部情報を調査したい場面があったので、サーバーとの SSH 接続確認を行った後に情報を出力してくれるように依頼しました。すると Claude Code は自主的に wp-cli をインストールし、必要なコマンドを実行してくれました。具体的には以下のような作業をチャットベースのやり取りだけで完了できました。 

• WordPress の内部ユーザー情報の確認
• WordPress 環境をコピーして開発環境を構築した後の、内部文字列の一括置換（該当する wp-cli コマンドを自動的に探し出して実行）

なお、サーバー上でコマンドを実行する際には都度許可を確認してくれるため、意図しないコマンドが実行されていないかを人間側で確認することができます。

セキュリティ面での補足

今回の運用では、まず開発環境で一連の操作を実行し、その経験をもとに本番環境での作業に臨むという順序を取りました。生成 AI が誤って本番データベースのデータを削除してしまった事例がニュースになったこともあり、AI によるサーバー操作はこなれてきているとはいえ、どこまでの操作を AI に任せるかについては事前にルールを決めておくことを推奨します。

今回は、開発・本番ともに定期バックアップのある環境であり、かつ、インフラリソースの操作権限を Claude Code に与えていない状況だったので、SSH 接続先のサーバー内での操作のみ可能という条件で実行しています。AWS などのクラウドリソースを操作する場合は AI に直接実行させるのではなく、事前検証のためにもスクリプトを書いてもらって、それを実行するような権限分離の方針を取っています。 

また、wp-cli ではローカルからリモートの WordPress に接続する設定も可能です。サーバー上に直接 wp-cli をインストールするのではなく、ローカルの wp-cli からリモートの WordPress を操作するという方法も選択肢のひとつです。環境への影響を最小限にしたい場合は、こちらのアプローチも検討に値するでしょう。 

逆にうまくいかなかったケース：新規のサーバー構築

一方で、サーバーの新規構築（docker-compose によるネットワーク構成を含む）を Claude Code に依頼した場合は、期待通りの結果にはなりませんでした。

Claude Code は基本的に標準的なプラクティスに則った形で環境を構成します。しかし、実際の運用ではセキュリティ上の理由から標準構成を変更しているケースがあります。たとえば、パストラバーサル対策としてドキュメントルートを標準的なディレクトリから変更している場合などです。

こうした独自の構成は都度指示をすることで修正することができます。しかし、構築済みの環境に対する修正は破壊的な作業であり、修正を重ねるうちに別のリソースが変更前のパスを参照していてうまく動作しない、という問題が頻発する傾向がありました。ゴールが明確に見えているにもかかわらず、そこに到達するまでの手間が大きくなるという状況は、直接構築を任せるアプローチの限界を感じる場面でした。

より効果的なアプローチ：構築スクリプトを書かせる

この経験から、サーバー構築については AI に直接環境を構築させるのではなく、構築用のスクリプトを書かせるという方法がより効果的だと考えています。

スクリプトであれば、実行前にレビューが可能であり、環境に対する影響を与えずに検証できます。また、同様の構成を別のサーバーに適用したい場合にも、スクリプトという再現可能な形でナレッジが残ります。AI に直接操作させた場合、その実行プロセスには再現性がないため、同じことを別の環境でもう一度やりたいときに、また一からやり直しになってしまいます。

まとめ

これらの経験を通じて、生成 AI をサーバー管理に活用する際の指針が見えてきました。

既存環境の調査・操作には高い力を発揮する

これは対象が Linux や WordPress といった、インターネット上に豊富な情報が存在する技術スタックであることが大きく寄与しているといえます。逆に言えば、情報が少ない技術スタックやニッチなツールについては同等の精度は期待しにくいということでもあります。ただし、ソースコードを読むことができる状況であれば、情報の少ない技術でも適切な分析を行ってくれます。生成 AI には得意な領域と不得意な領域があり、それを正しく認識したうえで活用することが重要です。

独自の構成を含む新規構築は、直接作らせるのではなく、自動化スクリプトを作らせる

特定の組織ごとの独自要素は、最初から指示をしてもその指示の量が多いとノイズのように扱われやすく、標準構成に引っ張られて構築されてしまう可能性が高くなります。そのため、ユニークな内容を作らせる場合は「直接作らせる」のではなく「それを作るためのスクリプトを作る」という間接的な活用法が、再現性・検証可能性の両面で優れていると考えます。

生成 AI の精度は急激に高くなっており、得意とする分野では非常に頼りになります。一方で万能ではなく、苦手な分野もまだあります。その特性を理解して適切に使い分ければ、サーバー管理だけではなく、多くの業務の効率化に大きく貢献してくれるツールです。