アーティサン株式会社
  • AI関連
  • セキュリティ・保守

生成AIへの依頼を、どう区切ったか――WordPress移行を進めた作業とレビューの実践

第2回:GitHubでつなぐ、調査・実装・検証

この記事の4行要約

  • 最初の調査で、構成資料(有効プラグイン17件)と実際のデータベース(18件)の違いが見つかり、実環境の棚卸しから始めました
  • Claude Codeへの依頼は、対象・維持するもの・復旧点・確認項目・停止条件をそろえ、結果を確認できる単位に区切りました
  • Codexでは「完了」と報告された根拠をレビューし、差分・ログ・動作確認と照合しました
  • 作業結果と未確認事項をGitHubに残し、担当するAIや会話が変わっても引き継げるようにしました
この記事を書いた人
小山才喜

小山 才喜こやま さいき

Microsoft Azure Microsoft 365 AI開発

元マイクロソフトの技術営業、ジョルダン社での事業立ち上げを経て独立、起業13年目の生涯現役社長

元MVP(Microsoft Valuable Professional)
「VSTOとSharePoint Server 2007による開発技術」

など著書多数

Microsoft 認定資格(MCP)を30以上保持したタイトルホルダー


第1回では、事前見積もりで数か月を想定していたWordPress・PHPの移行を、生成AIを活用して約10日間で実質的に完了した取り組みを紹介しました。

体制の中心に置いたのはGitHubです。ChatGPTで方針を整理し、Claude Codeで実作業を進め、Codexでレビューする。そして、人が結果を確認して次の作業を判断する。この役割分担で進めました。

今回は、その体制を実際の作業にどう落とし込んだかを紹介します。

最初の調査で、構成資料との違いが見つかった

構成資料では、有効なプラグインは17件。しかし、実際のデータベースでは18件が有効になっていました。

小さな違いに見えますが、移行では重要です。資料だけを基に計画すると、実際に動いている機能を確認対象から外してしまう可能性があります。

そこで、最初に行ったのは、実環境の棚卸しでした。WordPress本体、PHP、データベース、テーマ、有効プラグイン、外部連携の状態を確認します。資料の内容と照合し、違いがあれば記録しました。

生成AIに調査を依頼する際も、「資料に書かれていること」「実環境で確認できたこと」「まだ分からないこと」を分けて整理することが大切です。

ChatGPTで、目的を具体的な作業へ分ける

「WordPressとPHPを更新する」という目的だけでは、作業の範囲が広すぎます。コアの更新、テーマの互換性対応、プラグインの整理、データ保全、フォーム確認、本番切替。それぞれに確認事項と判断が必要です。

ChatGPTとの壁打ちでは、こうした課題を分け、作業の順序を整理しました。

今回の目的は、既存の機能とデータを引き継ぎながら、新しい環境へ移行することです。デザインの全面刷新や機能の作り直しまで、同時に広げない方針にしました。

この対象範囲が決まっていると、途中で既存の問題が見つかっても、今回対応するか、別の改善として扱うかを判断しやすくなります。

Claude Codeへの依頼は、結果を確認できる単位にする

具体的な作業を依頼するときは、調査と変更を区切りました。たとえば、プラグインを調べる段階なら、現在の状態と互換性上の問題を整理するところまでにします。結果を確認してから、更新や置き換えへ進みます。

次は、今回の進め方を基に再構成した依頼例です。実際の会話ログの転載ではありません。

「検証環境の有効プラグインを調査してください。実際の有効状態とバージョンを確認し、構成資料との差異、PHP 8.3で動作するうえでの問題を整理してください。この段階では、更新・削除・本番環境への変更は行いません。結果は『確認できた事実』『推測』『未確認事項』に分け、次の工程で対応が必要な項目を示してください。」

変更へ進むときは、さらに次の情報をそろえます。

  • 対象:どの環境、どの機能を変更するか
  • 維持するもの:データ、設定、既存の動作
  • 復旧点:問題が起きた場合に戻せる状態
  • 確認項目:変更後に何を調べるか
  • 停止条件:どのような結果なら、続行せず判断を求めるか
対象、維持条件、復旧点、確認項目、停止条件の5項目

作業を区切ることで、原因を追いやすくなり、人も変更内容を確認しやすくなります。

検証環境にも、本番への影響を防ぐ準備が必要

作業は、本番のコピーを使った検証環境で進めました。

ただし、本番をコピーすると、メールの送信先や外部サービスの設定も引き継がれる場合があります。そのままフォームを試験すると、実際の宛先へメールを送ってしまう可能性があります。

今回も、検証環境ではメール送信を抑止しました。画面や処理の確認と、テスト先への実送信確認を分けて進めるためです。

各工程の前には、データベースやファイルの復旧点も確保しました。問題が起きた場合に、直前の状態へ戻せるようにします。生成AIに作業を任せる際も、こうした前提を依頼に含めることが重要でした。

Codexでは、「完了」の根拠をレビューする

実作業の後は、Codexを使って計画、変更差分、検証結果を確認しました。レビューでは、コードの修正内容に加え、報告された結果が何を意味するかを見ます。

たとえば、ログイン画面が表示されたことと、ログイン後に記事を編集できたことは別の確認です。フォームが完了画面へ進んだことと、正しい宛先へメールが届いたことも同じではありません。

レビュー依頼も、次のように具体化できます。

「変更差分と検証結果を確認してください。依頼範囲を超えた変更、既存データへの影響、完了条件に対する確認不足がないかを見てください。指摘には根拠を添え、確認済みの問題と追加調査が必要な事項を分けてください。」

これは今回の進め方を基にした例です。複数の生成AIを使うことで、別の観点から見落としを探せます。ただし、AI同士の意見が一致していても、それだけで正しいとは判断しません。実際の差分、ログ、データ比較、動作確認と照合します。

GitHubに、次の作業で必要な情報を残す

作業結果は、個別の会話だけに残さず、GitHubへ集約しました。Issueには課題、承認、経過、結果を記録します。Pull Requestにはコードや設定の変更をまとめ、確定した手順や結果は文書として残します。

記録で重視したのは、次の内容です。

  • 何を変更したか
  • 何を確認し、どのような結果だったか
  • 何が未確認か
  • 復旧や切り戻しを行ったか
  • 次の工程へ進めるか
  • 残った課題は何か
実作業とレビューを経て人が判断しGitHubへ記録する流れ

この記録があれば、担当するAIや会話が変わっても、前提を引き継ぎやすくなります。

リポジトリには、AIが継続して参照する共通ルールも置きました。変更を意味のある単位にまとめること、本番への操作を無断で広げないことなどを、毎回説明するだけに頼らない形にしています。

速く進めるために、判断する場所を決める

生成AIは、調査や修正案の作成を速く進められます。その速さを移行全体へつなげるには、人が判断しやすい状態を作る必要があります。

今回は、作業を区切り、結果を記録し、レビューして次へ進みました。「どこまで任せるか」と「何を見て判断するか」を決めることが、生成AIを活用した移行の土台になりました。

次回は、実際に直面したPHP互換性、カスタムフィールド、404、フォームの問題を紹介します。

連載「生成AIで進めたWordPress・PHP移行」のこれまでの記事

Artisan(アーティサン)とは

Artisan(アーティサン)とは、腕の良い職人を意味する言葉です。

アーティサン株式会社では、技術をつくること自体を目的とせず、使われ続ける価値として社会に届けることを使命としています。

モビリティ事業は公共交通事業者や自治体向けに、バスロケーションシステム「バス予報」、予約配車システム「オンデマンドバス予報」、GTFS作成支援「まかせてGTFS」、お知らせ配信「かんたんAlert」などを提供しています。

MSクラウド事業はMicrosoft 365、SharePoint、Power Apps、Power Automate、Copilot Studioなどを中心に、コンサルティング、設計、構築、開発、研修、内製化、運用支援を提供しています。

2つの事業を通じて、企業と社会が自らの力で最適解を導き出すための支援を行っています。

気になることがあれば、お気軽にご相談ください。

また、技術を追い求めながら会社と一緒に成長していける仲間も、積極的に募集しています。

バス予報・オンデマンド交通など、モビリティ事業のサービス一覧はこちら

モビリティ事業ページへ

SharePoint・Power Platformなど、Microsoftクラウド事業のサービス一覧はこちら

Microsoftクラウド事業ページへ

アーティサンの採用情報はこちら

採用情報ページへ