弊社では業務のさまざまな場面でAIを活用しています。今回は、会社のブログサーバーの引っ越し作業を、AIエージェント（Claude Code）と一緒にやってみた話をご紹介します。しかもネコちゃんが作業してくれます。

きっかけ：ブログのサーバーを新しくしたい

弊社のブログは、AWSのLightsailというサービスの上でWordPressを動かして運用しています。

このブログサーバー、もともと一番小さいプラン（メモリ0.5GB）で動かしていたのですが、WordPressを快適に動かすにはちょっと力不足。さらに、サーバーに入っているソフトウェア（データベースやWebサーバー）のバージョンが古くなってきていました。

そこで、新しいサーバーを立てて、データを引っ越そうということに。ついでにメモリも倍増させます。

月額たった$2アップで、メモリもディスクも倍。ソフトウェアも全部最新。やらない理由がありません。

でも、サーバーの引っ越しってめんどくさい

サーバーの引っ越しって、地味に手順が多いんです。

1. 新しいサーバーを作る
2. セキュリティの設定をする
3. 旧サーバーからデータベースやファイルをコピーする
4. 新サーバーに取り込む
5. ちゃんと動くか確認する
6. ネットワークの向き先を切り替える
7. SSL証明書（httpsの鍵）を設定する
8. 後片付けをする

手作業でやると、どこかで打ち間違えたり、手順を飛ばしたりしがち。そこで……

AIに全部やらせよう

Claude Code（Anthropic社が提供するAIエージェント）は、ターミナル（黒い画面）で動くAIです。人間がキーボードで打つコマンドを、AIが代わりに実行してくれます。

つまり、サーバーにSSH接続してコマンドを打つ作業も、AIにお任せできるわけです。

やったこと

Claude Codeに「ブログサーバーを新しいインスタンスに移行して」と伝えたところ、こんな流れで進みました。

1. 計画を立てる — AIが移行手順を10ステップで提案（数秒）
2. 移行スクリプトを作る — AIが約330行のシェルスクリプトを自動生成（数十秒）
3. 人間がレビューする — 内容を確認してバグを1件発見・修正（数分）
4. 実行する — スクリプトを実行して、AIが全工程を自動で処理

計画もスクリプト作成も一瞬。人間がやるのはレビュー（確認）だけです。

レビューで見つけたバグ

AIが作ったスクリプト、ほぼ完璧だったのですが、1つだけバグがありました。

サーバーの引っ越しでは、途中でネットワークのアドレスを旧サーバーから新サーバーに付け替えます。AIはこの「付け替えた後も、古いアドレスに接続しようとしていた」んです。

住所が変わったのに、前の住所に手紙を送っちゃうようなもの。これは人間がレビューして発見・修正しました。

ちなみに、今のAIはプロンプト（指示）や用途を適切に設計すれば、レビュー作業もAIに任せることができます。今回はあえて人間がレビューしましたが、次回は「レビュー担当AI」を用意するのもアリですね。

作業ネコちゃんと監督ネコちゃん

せっかくなので、実行も少し楽しくしました。

画面を上下に2分割して、「作業ネコちゃん」（作業する側）と「監督ネコちゃん」（チェックする側）の2匹のAIエージェントに役割を分けて実行させました。

監督ネコちゃんは、作業ネコちゃんから報告を受けるたびに内容をチェックして、問題なければ「ヨシッ！」と承認します。特に重要な工程（ネットワーク切り替えなど）では、監督ネコちゃんの承認がないと先に進めない仕組みです。

監督ネコちゃん

── 監督ネコちゃん ──

作業ネコちゃんからの報告を確認中…

 

【フェーズ6: 動作確認（仮IP）】

WordPress管理画面… OK

ブログ表示… OK

データベース… OK

監督ネコちゃん「ヨシッ！動作確認OKニャ！」

 

【フェーズ7: ネットワーク切り替え】— 重要工程

この工程は監督ネコちゃんの承認が必要です

旧サーバーからIPアドレスを切り離し…

新サーバーにIPアドレスを割り当て…

監督ネコちゃん「ヨシッ！切り替えてOKニャ！」

── 作業ネコちゃん ──

【フェーズ7: ネットワーク切り替え】 実行中…

監督ネコちゃんの承認を確認… 承認済み

IPアドレス切り替え中…

ネットワーク切り替え完了！

監督ネコちゃんが「ヨシッ！」で承認。ネットワーク切り替えという重要な工程も安心です。

移行完了！

── 監督ネコちゃん ──

[進捗: 10/10 フェーズ完了]

 

全フェーズ完了！ヨシッ！！！

作業ネコちゃんお疲れさまニャ！

ブログ記事も書くニャよ！

 

監督業務完了ニャ

── 作業ネコちゃん ──

フェーズ10: 後片付け… 完了

 

移行完了ニャーーー！！！

 

====================================

全10フェーズ正常完了

ブログURL: https://blog.fits-inc.jp

====================================

全工程完了！監督ネコちゃん「ヨシッ！！！」作業ネコちゃん「移行完了ニャーーー！！！」

実際の作業はすべてAIが自動で行っています。人間はターミナルを眺めているだけ。ネコちゃんたちが頑張ってくれました。

移行結果

無事、ブログの引っ越しが完了しました。

サーバーの中身はすべて最新になり、メモリにも余裕ができました。ブログの表示速度も体感で速くなっています。

AIにインフラ作業を任せてみて

今回の移行を通じて感じたのは、AIは「速くて正確な作業員」として非常に優秀だということです。

• 計画立案：移行手順の洗い出しが数秒で完了
• スクリプト生成：330行の移行スクリプトが数十秒で完成
• 実行：10ステップの作業を自動で正確に実行
• チェック体制：監督ネコちゃん＋作業ネコちゃんの2体制で安全に運用

今回は人間がスクリプトをレビューしてバグを1件見つけましたが、実はこのレビュー作業もAIに任せることができます。プロンプト（指示）や用途を適切に設計すれば、AIが計画・実行・チェックまで一貫して担える時代になっています。

もちろん、お客様の大事なシステムをお預かりする以上、最終的な判断と責任は人間が持ちます。大事なのは、「AIにどこまで任せて、どこで人間が判断するか」を正しく設計すること。AIの得意・不得意を把握した上で、適切に使い分けることが重要です。

まとめ

弊社FITSは仙台を拠点に、こうしたAI活用を日常の業務に取り入れながら、Webシステムの開発・運用を行っています。

「AIってどう使うの？」「自社の業務にも使えるの？」といったご相談も大歓迎です。仙台でAIを使っていろいろやっている会社として、お気軽にお声がけください。

この記事の執筆・移行作業は、Claude Code（Anthropic）を活用して実施しました。ネコちゃんたちもお疲れさまでした。

場所はJAビルの地下です。JAビルはオフィスのある南町通りからは遠いので、自転車で行く感じですね。表には写真みたいに看板しか出てないのですが、JAビルの横の階段を下がっていくと・・

ご覧のように地下への入り口が現れ、入り口進んで真ん中ほどにお店があります。「寿司」「天ぷら」「極上麦酒」ののれんがかっこいいですね！（天ぷらののれんは畳まれてますが）なお入り口は手動ドアなので、手をかけてぐっと開きましょう

外の壁にもメニューがあります。どうやらお目当ての天丼は400円プラスすると、極上天丼（エビが4本プラス）になるみたいです。

着丼！

アップも。ボリュームたっぷりです。

えび2本、ピーマン、なす、さつまいも、蓮根、ちくわ、しめじ（舞茸じゃなくてしめじなの珍しいですね）などが載っていて、大満足の味でした！なお、タレは衣に絡ませてあるので、どこを食べてもタレの味がして美味しい！以前に、アーケードの天丼てんやがなくなって、仙台で天丼が食べたくなったらどこ行けばいいんやーって悲しい気持ちになったのですが、これからはさかえさんに行こうと思います。なお、店長さんのお名前がさかえさんなので、お店のなまえもそこから取ったんだろうなーって思ってます。

あと、帰り道で知ったのですが勾当台公園に地下道を通す工事をやっているみたいですね。どこまで伸びるか分からないですがフェスやイベントの際に、東と西が行き来しやすくなる配置だといいですね。

店名：寿司・天ぷら・極上麦酒さかえ
場所：JAビル宮城の地下１階
訪問日：10/21（月）
頼んだもの：天丼大盛り1200円
定休日：日曜日

最初に契約した時に手違いがあったのか、必要なチュートリアル資料などが送られてきておらず、公式のチュートリアルアプリを色々と確認しながら少しずつ機能の理解を深めていきました。その中で一番理解が難しかったのがフォーム機能に内包されている「外部API連携」です。

この外部API連携については全然情報が出て来ず、こちらで想定するSlack連携などを組み込んでも全く動作してくれませんでした。設定としては

・会員登録APIのエンドポイント（プレビューアプリ用）
・会員登録APIのエンドポイント（本番アプリ用）
・APIのリクエストパラメータへのマッピング

が存在するようです。試しに設定したエンドポイントに送られてくるデータをネットワークのログで確認したところ

parameters[ud_id]=xxx&parameters[created_at]=2024-06-21 07:27:36&parameters[param1]=yyy&parameters[param2]=zzz

というように、設定したパラメータが parameters[パラメータ名] =バリューのペアで入ったテキストを、URLエンコードしたものが入っているようでした。ただ、郵便番号や性別、生年月日などは含まれておりません（おそらくYappliのサーバーにだけ連携されているのかと）

最終的にどのように利用すればいいのかをサポートに確認したところ、Yappli Lite では外部API連携の設定はできるのだけど、プランの機能には含まれていない、とのことでした。Yappli が機能追加ごとの課金であることは知っていましたが、必要最低限のYappli LiteプランではAPI連携系の機能は一切使えない、とのことでした。Yappli Liteを使ってAPIサーバーとの連携を使ったアプリを作りたい、という場合は注意が必要そうです。

% php -v
dyld[84774]: Library not loaded: @loader_path/../../../../opt/icu4c/lib/libicuio.73.dylib
Referenced from: <90055B36-6315-3FD7-9F54-5F9D08D9F325> /opt/homebrew/Cellar/php@8.0/8.0.30/bin/php
Reason: tried: '/opt/homebrew/Cellar/php@8.0/8.0.30/bin/../../../../opt/icu4c/lib/libicuio.73.dylib' (no such file), '/usr/local/lib/libicuio.73.dylib' (no such file), '/usr/lib/libicuio.73.dylib' (no such file, not in dyld cache)
zsh: abort php -v

brew info で調べてみるとicu4cの74が入っていたようなので、Qiitaや他のテックサイトを参考に、gitからicu4cの73をbrew tapしてインストールする方法を試していたのですが、gitリポジトリでgit clone する際にicu4cのログがgit logで見つからず（おそらくパスが間違っていたのだと思うのですが）、最終的に下記の方法でlibicu4cの7.3をインストールしました。

wget https://raw.githubusercontent.com/Homebrew/homebrew-core/6aca0f221ee4ac0c25735dbf31cc01fed984d8f6/Formula/icu4c.rb
brew reinstall --formula icu4c.rb

最終的にはphp8.0をバージョンアップすることで恒久対応を行ったのですが、取り急ぎphp8.0を使わなくてはいけない方でlibicu4cがバージョンアップされてしまって困っている方がいたら上記の方法で解決できる可能性があります。

まず、PHPのバージョンアップを行う必要性についてですが、PHPのバージョンを更新せずにWordPress を運用していると、ダッシュボードに「PHPの更新を推奨」というメッセージが表示されることがあります。PHPにもバージョンごとにサポート期間が設定されていますので、それが切れるとWordPress側で親切にも警告を表示してくれる、ということですね。

この「PHPの更新についてさらに詳しく」を見るとわかるのですが、WordPress自体にはPHPのバージョンアップをサポートする機能はなく、単純にバックアップを取った後に自身でPHPをバージョンアップさせることとなります。

ただ、過去の経験からLightsailにおけるPHPのアップデート作業は依存関係などで作業が複雑化することが多く、単純にLightsailに別なWordPressインスタンスを構築し、そこに対してバックアップデータを復帰するのが最も確実な対応方法となります。まずはLightsailのダッシュボードから新しいインスタンスを立ち上げていきます。その際に、WordPress用インスタンスイメージを選びましょう。また、立ち上げたら静的IPアドレスをアタッチしておくと良いです。

立ち上げインスタンスを確認すると、PHPのバージョンが新しくなっていることが分かります。※PHPのバージョンはbitnamiのWordPressイメージ次第のため、新しくはあるものの、最新のPHPバージョンではないことに注意してください。

bitnami@ip-xxx-xxx-xxx-xxx:~$ php -v
PHP 8.2.19 (cli) (built: May 7 2024 15:22:14) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.19, Copyright (c) Zend Technologies
with Zend OPcache v8.2.19, Copyright (c), by Zend Technologies
bitnami@ip-xxx-xxx-xxx-xxx:~$

さらに、WordPressの認証情報を確認し、管理画面にもログイン可能であることを確認します。

今回の環境ではWordPressのファイル群は /opt/bitnami/apps/wordpressにまとまっていました。wp-content の中に以降に必要となる uploads、themes、pluginsなども存在しています

root@ip-xx-xx-xx-xx:/opt/bitnami/apps/wordpress/htdocs# ls
activate.html wp-activate.php wp-content wp-mail.php
index.php wp-admin wp-cron.php wp-settings.php
license.txt wp-blog-header.php wp-includes wp-signup.php
pairing.html wp-comments-post.php wp-links-opml.php wp-trackback.php
readme.html wp-config.php wp-load.php xmlrpc.php
robots.txt wp-config-sample.php wp-login.php

root@ip-xx-xx-xx-xx:/opt/bitnami/apps/wordpress/htdocs# ls wp-content/
cache      languages  themes   upgrade-temp-backup  w3tc-config
index.php  plugins    upgrade  uploads

さらに、データベースのダンプデータ（バックアップデータ）も取得しておきます。

#mysqldump -u bn_wordpress -p bitnami_wordpress > bitnami_wordpress.sql

この後はバックアップデータを移行先の Lightsail インスタンスに格納する必要があります。SSHでCLIから接続しても良いのですが、今回Advanced File ManagerプラグインのFTP機能を使ってアップロードすることにします。

後は必要なファイルと、データベースの取り込みをすれば作業完了ですが「このサイトに重大なエラーがありました」が発生しました。

wp-config.php のデバッグ設定をONにしてデバッグします

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_DISPLAY', true);

define( 'WP_DEBUG_LOG', true );

結果、今回は下記のエラーが発生していました
Fatal error: Uncaught Error: Call to undefined function create_function()
Fatal error: Array and string offset access syntax with curly braces is no longer supported
これらは、PHPのバージョンが上がって廃止になったものなので、create_functionを無名関数に置き換え、配列への波括弧によるアクセスを、角括弧に置き換えれば問題なく動きます（今回はテーマのファイルで発生していたため、少し発見が遅れました）

後はLet ‘s Encrypt を使ってSSL対応を行います。今回はbitnamiのイメージを使っているので、certbotではなくてbncertを使うことで恒久的なSSL対応が可能となります。
参考：AWS公式ドキュメント「Lightsail WordPress のインスタンスで HTTPS を有効にする」
https://docs.aws.amazon.com/ja_jp/lightsail/latest/userguide/amazon-lightsail-enabling-https-on-wordpress.html

FITSではGoogle Workspaceを利用しています。
あるとき、Googleグループのすべてのメールが閲覧できるという報告を受けました。
幸い、情報漏洩などの事故は起きていませんでしたが、今後に備えて原因の解明と対策を行いました。

原因の特定

原因はGoogle Workspaceの管理者ロール設定にありました。

以下のロールが割り当てられたメンバーは、グループ側の設定で閲覧制限をかけていても適用されずに閲覧が可能です。
・特権管理者
・グループ管理者
閲覧できる旨の報告をしてくれた方は、グループ作成業務の際にグループ管理者ロールを割り当てられていたため、意図せず全てのメールが閲覧できる状態でした。

対策

グループの閲覧権限は必要のない権限であったため、ロール権限からグループの閲覧権限を外すことを試みましたが、特権管理者ロールやグループ管理者ロールはプリセットなロールであり、権限の変更はできませんでした。

そのため、グループの閲覧以外の権限を同等にした管理者ロールを手動で作成し、そちらに現在のメンバーを移行することで対応しました。

注意点

この対応を行う際には以下の点に注意が必要です。

特権管理者ロールは特殊なロール（スーパーアドミン）であり、権限設定画面に明記されていない権限と紐づいています。
つまり、権限を手動で同等に作成したつもりでも、今まで出来ていた操作ができなくなることがあります。
例えば、Google WorkspaceとAWSのIAMを統合してSSOを利用する場合、特権管理者ロールを持っていないとそれらの設定や操作ができません。

– 参考リンク: Configure SAML and SCIM with Google Workspace and IAM Identity Center –

その他の対応方法

私が行った方法以外にも、以下のような対応方法が考えられます。

・管理者の権限の見直し
不必要に管理者権限を持っているメンバーがいないか確認し、権限を持つ人数を最小限に抑えること。管理者権限を持つ必要があるか確認を行い、必要のないメンバーからはその権限を削除する。

・情報の機密性の評価
共有される情報の機密性を評価し、Googleグループ内で共有すべきでない機密性の高い情報は、もっとセキュアな方法（例えば、エンドツーエンド暗号化を提供するプラットフォーム）で共有することを検討する。

まとめ

組織でGoogle Workspaceを運用する場合、管理者権限は情シスなど一部のメンバーに限定しプロジェクトメンバーには権限のサブセットをロール化するのが基本となります。
もし管理者権限を運用されているのであれば、不要な権限を与えてしまっていないかと、
別途ロールを発行することが可能か検討するのが良いかもしれません。

結論から言うと「laravel-admin自体は動くけどartisan adminの一部のコマンドが動かない」という状況になります。laravel11ではこちらのリンクにあるようにDoctrine DBALの依存関係がなくなっています。

https://laravel.com/docs/11.x/upgrade#doctrine-dbal-removal

なのでlaravel-adminを使いたい場合は、laravel10の導入が選択肢となりそうです。

laravel11とlaravel-adminの導入

laravel11導入とlaravel-adminのインストールを順を追って説明すると、まずは公式の

https://readouble.com/laravel/11.x/ja/installation.html

にあるインストールコマンド（下記はMacOSの場合）

curl -s "https://laravel.build/laravel11" | bash

でlaravel11をインストールします（URLの末尾はアプリのディレクトリとなる）。インストールが終わったらコンテナを起動しましょう

cd laravel11
./vendor/bin/sail up

コンテナが起動したら

./vendor/bin/sail artisan migrate

これだけでlaravel11はインストール完了です。とっても簡単ですね。

次に、laravel-adminを導入していきます。

./vendor/bin/sail composer require encore/laravel-admin
./vendor/bin/sail artisan vendor:publish --provider="Encore\Admin\AdminServiceProvider"
./vendor/bin/sail artisan admin:install

こちらもとっても簡単ですね。

次に、モデル用のコントローラーを生成するためにいつものコマンドを叩いたところエラーが発生。

./vendor/bin/sail artisan admin:make UserController --model=App\\Models\\User

   BadMethodCallException 

  Method Illuminate\Database\MySqlConnection::isDoctrineAvailable does not exist.

  at vendor/laravel/framework/src/Illuminate/Macroable/Traits/Macroable.php:112
      108▕      */
      109▕     public function __call($method, $parameters)
      110▕     {
      111▕         if (! static::hasMacro($method)) {
  ➜ 112▕             throw new BadMethodCallException(sprintf(
      113▕                 'Method %s::%s does not exist.', static::class, $method
      114▕             ));
      115▕         }
      116▕ 

  i   Bad Method Call: Did you mean Illuminate\Database\MySqlConnection::availableAt() ? 

んん？なんでしょうこれは。と思って調べるとバッチリ「Laravel11ではDoctrine DBAL関連のメソッドが削除された」と出てきますね。

代替としてSchema::xxxを使えとあるのですが、現時点ではlaravel-adminがこれに対応するかどうか不明ですので、一旦laravel11とlaravel-adminの組み合わせは選択肢から外すのが良さそうです。

php artisan make:model Book --migration

マイグレーションファイルを適当に編集して書籍が持っていそうなプロパティを追加しましょう。

return new class extends Migration
{
    /**
    * Run the migrations.
    */
    public function up(): void
    {
        Schema::create('books', function (Blueprint $table) {
            $table->id();
            $table->string('title');
            $table->string('author');
            $table->string('isbn');
            $table->integer('price');
            $table->timestamps();
        });
    }
    /**
     * Reverse the migrations.
     */
    public function down(): void
    {
        Schema::dropIfExists('books');
    }
    /**
     * Reverse the migrations.
     */
    public function down(): void
    {
        Schema::dropIfExists('books');
    }
};

マイグレーションを適用します

php artisan migrate

さらに laravel-admin 用にルーティングとコントローラーを設定します。

php artisan admin:make BookController --model=App\\Models\\Book

実行結果で親切にも $router->resource(‘books’, BookController::class); をapp/Admin/routes.php に追加しろ、と教えてくれているのでその通り対応します。これで http://localhost/admin/books で管理画面が表示できるようになりました。

せっかくなのでメニューにも追加しましょう。メニューテーブルの seeder を書いても良いのですが、せっかくデフォルトのままlaravel-adminを使っているので、最初から搭載されてるメニューのマスメン機能を使ってページを追加しましょう。

Bookデータの管理画面に遷移するためのメニューが追加されました

まずヘッダー部分のテンプレートは vendor/encore/laravel-admin/resources/views/partials/header.blade.php に存在しますけど、ヘッダーからリフレッシュボタンなどのナビゲーションボタンを読み込む箇所は

    <!-- Navbar Right Menu -->
    <div class="navbar-custom-menu">
        <ul class="nav navbar-nav">
            {!! Admin::getNavbar()->render() !!}

という記載になっていました。Admin::getNavbar() を確認する必要がありますね。vendor/encore/laravel-admin/src/Admin.php の実装を確認すると、

/**
 * Get navbar object.
 *
 * @return \Encore\Admin\Widgets\Navbar
 */
public function getNavbar()
{
    if (is_null($this->navbar)) {
        $this->navbar = new Navbar();
    }

    return $this->navbar;
}

とあるので Encore\Admin\Widgets\Navbar の実装を確認します。vendor/encore/laravel-admin/src/Widgets/Navbar.php を確認すると、 left()、right()、add() というメソッドでナビゲーションバーに独自の element を追加できることがわかりました。

/**
 * @param $element
 *
 * @return $this
 */
public function right($element)
{
    $this->elements['right']->push($element);

    return $this;
}

例えば vendor/encore/laravel-admin/resources/views/partials/header.blade.php 直接編集し、下記のように書き換えることでメールアイコンを表示することができました。

    <!-- Navbar Right Menu -->
    <div class="navbar-custom-menu">
        <ul class="nav navbar-nav">

            <?php
            Admin::getNavbar()->right('<li><a><i class="fa fa-envelope"></i></a></li>');
            ?>

もし、リフレッシュボタンのようにコンポーネント化した上でボタンを追加するのであれば vendor/encore/laravel-admin/resources/views/components/refresh-btn.blade.php を参考にテンプレートや、SCRIPTタグで動作を設定することになります。またこれらの修正は vendor 以下のファイルを直接編集するのではなく、テンプレートをプロジェクトディレクトリにコピーした上で行う必要があります。