Profile
プロフィール
SNS・リンク

Kiro CLIとAWS Systems ManagerでWordPressの「サイトヘルス」の問題をクイックにやっつける

CLIベースでAIエージェントと協働してWordPressのトラブルシューティングする試みはAmazon Q Developer CLI時代にもやっていたのですが、Kiro CLI向けに作り直してみました。

さらに、ただの移植だけでなく、より生産性が上がる形にできないか模索してみたので記してみます。

そもそも、なぜWordPressでサイトを作っているのか

当ブログはWordPressベースで作っています。

これは仕事柄、WordPressベースのサイト構築案件に関わることが多く、愛着があったことに起因しています。
また、一方で、WordPressベースでのサイト運用の辛さも見聞きしていました。
そういった背景もあり、自らのサイトでそれを体感し、AWSの技術理解を深めながらサイト運用の合理化のノウハウを得られるハンズオンの場にもしたいなという思いがあり、あえてのWordPressサイト構築をしています。

そして今回はちょうど都合のいいことにWordPressのトラブルシュートが発生したので、「ブログのネタだ！」とか思いつつKiro CLIを使ってトラブルシュートの合理化を図ったのでそれを記します。

WordPressの「致命的な問題」、再び…

WordPressの管理画面には「サイトヘルス」という画面があり、そのサイトが抱えている不備を指摘してくれる機能があります。
セキュリティ上の不備の顕在化にもつながる機能であり大変ありがたいです。

でも、これって忘れた頃に不備が出てきて、直しておかないとすごく気持ち悪いWordPress管理者の悩みの種ですよね。

今回は「ファイルの所有権の問題」が起きてました。

こういうやつ

WordPressサイトヘルスの問題表示画面

多分、WordPress管理している人であれば、一度は出くわすめんどくさいやつですね。

今回はこれをKiro CLIベースでクイックに解消していきました。

事前準備

概要図

まず、インフラの構成から解説します。

基本のインフラ構成図

すごく抽象化しちゃいますが、EC2インスタンス上でWordPressを稼働しているシンプルな構成です。

そして、そのWordPressにおいてサイトヘルスから不備が出ていたわけです。

従来のアプローチとその課題

従来ですと、サーバー内にアクセスして設定ファイルやファイル・ディレクトリのパーミッションをいじったりする必要がありました。

従来のトラブルシューティングアプローチ

昨今では、AWS Systems Managerの恩恵で、SSHポート解放まではしなくともサーバー内操作をできるようになったりしてましたが、
この「サーバー内にアクセス」というのがなかなかめんどくさかったポイントでした。

アクセスしたあと、設定ファイルをviで開いたり、編集する前には念の為コピーを取っておいたり、、、そして、ローカルPCでセットアップ済みのKiro CLIのようなAIの恩恵を受けられませんでした。

今回のアプローチ

そのため、上記のような状況を改善し次のようにしました。

Kiro CLIを活用した新しいアプローチ

  • 管理者のローカルPCにてKiro CLIを実行可能にする
    • ※管理者のローカルPCからはAWS SSOにて必要な操作だけを許可されたアクセスを担保
  • 管理者はKiro CLIを通じて指示を出す
  • Kiro CLIが AWS Systems Manager Run Commandを通じてサーバー内の情報取得や設定変更を行う
    • ※WordPressが稼働するEC2インスタンスはSystems Managerの管理下に入っている前提

これにより一連の操作をKiro CLIのチャットセッションを介して行うことで、AIのパワーを借りながら迅速に課題解決を進めることができます。

なお、AWS Systems ManagerとAWS Backupについては、このブログ基盤では既に利用していたため、詳細な説明は割愛します。

設定ファイル内訳

今回の構成を実現するためにローカルでは次のように設定ファイルを配備しました。

これらの設定ファイルは、Kiro CLIを実行するプロジェクトルートの.kiro/ディレクトリに配置します。

.kiro/
├── agents/
│   └── wp.json
└── rules/
    └── wp-maintenance.md

agents/wp.json

WordPress専用エージェントの設定ファイルです。

{
  "name": "wp",
  "description": "WordPress メンテナンス専門エージェント（AWS SSM RunCommand対応）",
  "prompt": "file://../rules/wp-maintenance.md",
  "tools": [
    "use_aws",
    "fs_write",
    "fs_read",
    "execute_bash"
  ],
  "allowedTools": [
    "fs_write",
    "fs_read"
  ],
  "toolsSettings": {
    "use_aws": {
      "allowedServices": ["ssm", "backup"],
      "autoAllowReadonly": true
    },
    "fs_write": {
      "allowedPaths": ["**/*.md", "**/logs/**"]
    }
  },
  "resources": [
    "file://../rules/wp-maintenance.md"
  ]
}

rules/wp-maintenance.md

WordPress メンテナンス作業のルールとガイドラインを定義したファイルです。


# WordPress メンテナンス専門エージェント（AWS SSM RunCommand対応）

あなたはAWS EC2上のWordPressサイトの保守・運用を専門とするエキスパートです。AWS Systems Manager RunCommandを使用してリモートメンテナンス作業を支援します。

セッションを開始した時点で、ユーザーに対してどのような操作を行いたいかをヒアリングをし、それに基づいて操作をしてください。

## 設定情報

- **AWSプロファイル**: `my-site`
- **対象EC2インスタンス**: `<対象となるEC2インスタンスのID>`
- **リージョン**: `ap-northeast-1`

## 基本原則

- **SSM RunCommand必須**: 全てのサーバー内操作は上記に指定のあるAWSプロファイルを使いながら、SSM RunCommandで実行
- **段階的実行**: 一度に複数の変更を行わず、1つずつ確認しながら進める
- **安全第一**: 設定ファイルの書き換えを行う際には、必ず現状ファイルをコピーしてバックアップを作っておいた上で作業をすること。
- **コマンド記録**: 実行したRunCommandの履歴を詳細に記録し、 yyyymmdd/のフォルダ配下にMarkdown形式の作業履歴を残す。その際にはユーザーからのチャット指示内容も原文のまま記載する。
- **振り返りをしやすく**: 対応を完了したと思ったらユーザーに完了できたかどうかを確認する。そして、ユーザーから完了の旨宣言が出たら「当初の課題」「実際に行った対応」「最終的な結果」を作業履歴書に記載する。そしてフォルダ名も yyyymmdd/ から yyyymmdd/<対応内容>/ のフォルダ名で後に振り返りをしやすいようにする。

## 基本コマンド形式

ユーザーからのリクエストを受けたら、それに応じて SSM RuncommandでEC2インスタンス内で操作を実行する。

```bash
aws ssm send-command \
  --instance-ids "<対象となるインスタンスID>" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=["コマンド内容"]' \
  --profile my-site \
  --region ap-northeast-1
```

## 実行結果の取得

コマンドが実行された後はその詳細履歴を都度取得する。

```bash
aws ssm get-command-invocation \
  --command-id "コマンドID" \
  --instance-id "<対象となるインスタンスID>" \
  --profile my-site \
  --region ap-northeast-1
```

## 対応スタイル

- 全ての操作をSSM RunCommandで実行可能な形で提示
- Chatセッションの開始時点で、AWS Backupの中を確認して、復元可能な最終バックアップ取得地点を確認する。

実施結果

では、上記のような内容でどんな結果になったのかチャットのログを抜粋してみます。

チャット開始

Kiro CLIエージェントのヒアリング画面

作業の希望を聞いてきました。

バックアップ状況を確認

AWS Backupの履歴確認画面

AWS Backupの中を確認して、復元可能ポイントを確認してくれます。（明示的な指示をしないといけなかったので、もうちょっとここは改善したい）

発生している問題をスクリーンショットを使って共有

スクリーンショット読み込み成功画面

ローカルのPC側でCLIを使えることの利点として、スクリーンショットを配備して、そのファイルのPathを与えてやることでその画像を読み取って理解してくれるということがあります。

画像を理解してくれるので、人間に共有する時と同じようにペン入れなどをするとうまく意図が伝わるのではないでしょうか。

ちなみに貼った画像は冒頭の「サイトヘルス」の画像です。

原因調査→修正が行われる

WordPressディレクトリ権限確認画面

以降はKiro CLIが

Systems ManagerのRun Commandを実行→その結果を確認

をひたすら繰り返していきます。

wp-config.phpバックアップと設定追加画面

よく見ると、ファイルを変更する前には事前にbackupのサフィックスと日付をファイル名につけたバックアップも作っているので、万が一のミスがあった時への備えも取れていることがわかります。

実行結果の確認も入念に行われる

今回は設定ファイルの修正と、サーバー内のファイル・ディレクトリのパーミッション変更を行なっています。

一括で、パーミッションの変更を行う操作は完了までに時間がかかる場合があります。
そのことも考慮して、実行結果が取得できなかった際にはしっかりと、実行結果の取得もリトライしてくれています。

ディレクトリ権限修正作業画面

こまめな実行ログの記録

上記に記載したAIへの指示内容をみていただけるとわかると思いますが、今回実行したオペレーションを都度時系列に沿って記録させるようにしています。

上記のような時間のかかるパーミッション変更操作の完了待ちの際には
「ちょっとこの操作時間かかりそうなので、今のうちに作業ログ更新しておきますね」的なことも上手いことやってくれています。

作業ログ記録画面

作業完了

Webサーバー再起動画面

最後は、再起動なども抜かりなく行なって完了

最終的な作業ログ

以上がCLI上でのチャットログでしたが、同時にKiro CLIに作らせていた作業ログは以下のような内容です。

人の目で内容の確認も行いましたが、時系列的にもちゃんと沿って行なった内容が記録されています。

作業履歴詳細レポート画面

個人で運用しているブログなので、実行された変更などが本当にベストな対応なのか、というのは今回厳密に精査していないのですが、少なくとも冒頭に抱えていた課題は上記の対応を経て、無事解消されました。

問題解消後のサイトヘルス良好画面

まとめ

以上、Kiro CLIとAWS Systems Managerの合わせ技で、EC2内のトラブルシュートを行う方法を紹介しました。

Kiro CLIをローカルのPC上で動かして、コーディング上の支援に使うという方法はKiroに限らずさまざまなAIエージェントで使われていると思いますが、今回のようにトラブルシュートの効率アップに使ってみるというのも検討の余地が大いにあるのではないでしょうか。

ちなみに、作業履歴のレポートを見るとわかるのですが、事前の準備の環境が整っていれば、今回のトラブルシュートは１０分もかからずに完了することができています。
そして、チャットセッションの中では「このエラーを解消したいです」の一言だけ伝えて、あとはひたすらにKiro CLIがトライアンドエラーを繰り返していくのを眺めているだけでした。

今回のようなWordPressのトラブルシュートって往々にして時間を溶かしてしまいがちなので、これは本当に嬉しい改善でした。

業務上の環境においては、さすがにAIによる個別のコマンド実行を全許可していくのではなく、コマンド実行の”Yes or No”を人間が判断する。などの追加の手立ては必要かと思います。
また、さらにKiro CLIのagents設定ではssmとbackupのコマンドを一括で許可してしまっています。
より安全に使うためにはこの辺りも最小権限の原則に則った絞り込みなどは必要でしょう。

それでも旧来型の「サーバーに入ってファイル操作する」よりは快適に、そして速やかに実行できるのではないでしょうか。

今回の記事で、Kiro CLIの力を借りながらWordPressサイトの運用の合理化を図りたい人の参考になれば幸いです。

これが私のmacOSセットアップ（2026年版）〜Ansibleのplaybookも添えて〜 前の記事

関連記事