【第9回】最初の実変更でAI伴走開発の流れを確認する

最初の変更は小さな保守作業から始める

Ubuntu上で実案件を扱える状態になったからといって、最初から大きな機能追加を行う必要はありません。

新しい環境では、Git、Composer、PHP、コーディング規約の検査、WordPressの動作確認などが、これまでと同じように利用できるかを確認する必要があります。

そこで今回は、プラグインの機能や画面表示を変更しない、次の保守作業を選びました。

• Composerの設定ファイルを正しい形式へ整える
• プラグインのライセンス情報をComposerへ明示する
• コーディング規約で指摘された余分な空行を削除する
• Composer、PHP、PHPCSの検査が正常に完了することを確認する
• WordPress上の既存機能に影響がないことを確認する

変更量が小さければ、新しい環境で問題が起きた場合も、原因を絞り込みやすくなります。

また、コードの機能を変更しない作業であっても、調査、編集、検査、動作確認、コミットという開発の基本工程は一通り確認できます。

作業を始める前の状態を確認する

最初に、対象となるGitリポジトリへ移動します。

cd /mnt/studio317-data/development/projects/studio317-report-drafts-google-analytics

続いて、現在のブランチ、作業ツリー、最新コミットを確認しました。

git status --short --branch
git log -1 --oneline --decorate
git remote -v

作業開始時点では、mainブランチを開いており、未コミットの変更がないクリーンな状態でした。

最新コミットは、前回確認した次の基準点です。

074b091 0.2.0

新しい作業を始める前にクリーンな状態を確認することで、これから表示されるGit差分が、今回の作業によるものだと判断できます。

Composerの設定を検査する

このプラグインでは、PHPの開発ツールやコーディング規約をComposerで管理しています。

Composerの主な設定は、プロジェクトのルートにあるcomposer.jsonへ記述されています。

最初に、設定ファイルがComposerの仕様に沿っているかを厳密に検査しました。

composer validate --strict

composer validateは、composer.jsonとcomposer.lockの内容を検査するコマンドです。

--strictを付けると、通常のエラーだけでなく、公開パッケージとして改善すべき設定も厳しく確認できます。

検査の結果、composer.jsonにComposerのパッケージ設定として適切ではない項目があり、ライセンス情報も明示されていないことが分かりました。

private設定を削除する

composer.jsonには、次の設定が記載されていました。

"private": true

privateは、JavaScriptのパッケージ管理であるnpmの設定ではよく利用されます。

しかし、Composerのパッケージ定義としては適切な項目ではないため、厳密な検査で指摘されました。

このプラグインをComposerの公開パッケージとして配布する予定があるかどうかに関係なく、composer.jsonはComposerが定める形式に沿って記述する必要があります。

今回は、不要なprivateの行だけを削除しました。

プラグインのPHPコード、WordPressの設定、外部APIとの接続には影響しません。

ライセンス情報を追加する

WordPressプラグインは、WordPress.orgで公開する際にGPL互換のライセンスを使用します。

このプラグインのライセンスは、プラグインのヘッダーやreadme.txtでは明示されていますが、Composerの設定には記載されていませんでした。

そこで、composer.jsonへ次の設定を追加しました。

"license": "GPL-2.0-or-later"

GPL-2.0-or-laterは、GNU General Public Licenseのバージョン2以降を利用できることを示す標準的な識別子です。

ライセンス情報を複数のファイルへ記載する場合は、それぞれの内容が一致していることが重要です。

プラグイン本体、readme.txt、Composerの設定で異なるライセンスを示していると、利用者や開発者が判断に迷う原因になります。

composer.lockを整合させる

composer.jsonを変更した場合は、必要に応じてcomposer.lockも更新します。

composer.lockには、実際に利用する依存パッケージのバージョンや、Composerが管理する設定の情報が記録されています。

composer.jsonだけを手作業で変更すると、二つのファイルの内容が一致しない状態になることがあります。

今回は、Composerのコマンドを利用して整合を取りました。

composer update --lock

--lockは、プロジェクト全体の依存関係を新しいバージョンへ変更することを目的とせず、ロックファイルの管理情報を現在のcomposer.jsonへ合わせるために利用します。

更新後は、依存パッケージへ意図しない変更が含まれていないことをGit差分で確認しました。

Codexへ変更範囲を限定して依頼する

今回の修正はCodexへ依頼しましたが、単に「Composerの問題を直してください」とは伝えませんでした。

変更の目的と範囲、実行してよい検査、行ってはいけない操作を明確にします。

このリポジトリでComposerの設定とPHPCSの結果を確認してください。

今回の目的は、Composer metadataとコーディング規約の指摘を、
機能へ影響しない最小限の変更で解消することです。

次の範囲で対応してください。

・composer validate --strictの指摘を確認する
・composer.jsonから不要なprivate設定を削除する
・licenseにGPL-2.0-or-laterを設定する
・composer.lockを適切なComposerコマンドで整合させる
・PHPCSで指摘された余分な空行だけを修正する
・変更したPHPファイルの構文を確認する
・PHPCSを再実行する
・Git差分とgit diff --checkを確認する

プラグインの機能、画面表示、バージョン、
readme.txt、翻訳、外部API処理は変更しないでください。

コミットとpushは行わず、変更内容と検査結果を報告してください。

依頼内容を限定することで、今回の目的と関係のないリファクタリングや、広範囲な書式変更が行われる可能性を減らせます。

PHPCSでコーディング規約を確認する

Composerの設定を整えた後、PHP_CodeSnifferを使用して、PHPコードがプロジェクトのコーディング規約に沿っているかを確認しました。

vendor/bin/phpcs

PHP_CodeSnifferは、一般にPHPCSと呼ばれるコード検査ツールです。

WordPressのPHPコーディング規約に沿って、インデント、空白、コメント、命名、記述方法などを検査します。

今回の検査では、次の二つのファイルに余分な空行があることが分かりました。

includes/class-report-builder.php
includes/class-settings.php

どちらも、PHPの処理内容を変更する指摘ではありません。

必要以上に空いていた行を削除し、プロジェクトで定めている書式へ合わせました。

今回のように自動検査が利用できる場合でも、指摘されたすべての箇所を機械的に修正するのではなく、どの規則による指摘なのか、動作へ影響する変更なのかを確認します。

変更されたファイルを確認する

Codexの作業後、最初にGitの状態を確認しました。

git status --short

今回変更されたファイルは、次の四つです。

プラグインのメインPHPファイル、readme.txt、JavaScript、CSS、翻訳ファイルなどには変更がありません。

作業依頼で指定した範囲に収まっていることを確認してから、個々の差分を確認します。

Git差分を人間が確認する

Codexから変更内容の報告を受けた後も、説明だけで採用を判断しません。

実際の差分を確認します。

git diff

今回の確認では、次の点を重点的に見ました。

• private以外のComposer設定が意図せず削除されていないこと
• ライセンスの記述がGPL-2.0-or-laterであること
• 依存パッケージへ意図しない変更がないこと
• PHPファイルでは空行以外のコードが変更されていないこと
• プラグインのバージョンや機能に関係する変更がないこと

空白だけの変更であっても、複数の行がまとめて削除されていないか、PHPの開始タグや終了部分へ影響していないかを確認します。

AIが行った変更であるか、人間が手作業で行った変更であるかに関係なく、Git差分による確認は必要です。

PHPの構文を確認する

今回変更したPHPファイルについて、PHPの構文エラーがないことを確認しました。

php -l includes/class-report-builder.php
php -l includes/class-settings.php

php -lは、PHPファイルを実行せず、構文だけを検査するコマンドです。

余分な空行を削除しただけであっても、作業中に記号や括弧を誤って削除している可能性を考え、構文検査を省略しません。

二つのファイルについて、構文エラーがないことを確認しました。

ComposerとPHPCSを再検査する

修正後、最初に問題が見つかったComposerの検査を再度実行しました。

composer validate --strict

続いて、PHPCSを再実行します。

vendor/bin/phpcs

今回対応したComposerの設定と余分な空行について、指摘が解消されていることを確認しました。

さらに、Git差分に空白や競合マーカーなどの問題がないことも確認します。

git diff --check

検査結果に問題がないことを確認し、コード変更の機械的な検査を完了しました。

WordPress上で既存機能を確認する

今回の変更は、Composerの管理情報とPHPファイルの空行だけです。

プラグインの機能へ影響する変更ではありませんが、機械的な検査だけで完了とはしませんでした。

WordPressの開発サイトで、プラグインが引き続き有効になっていることを確認します。

cd /var/www/studio317/wordpress-dev/public

wp plugin status studio317-report-drafts-google-analytics

ブラウザから、次の画面も確認しました。

• WordPressのトップページ
• WordPressの管理画面
• プラグイン一覧
• Report Builder
• Current Status
• Settings

各画面が以前と同じように表示され、PHPの致命的エラーや不自然な表示が発生していないことを確認しました。

Google OAuth、GA4 Data API、AIプロバイダーなど、外部サービスへの接続は今回の変更と関係がないため実行していません。

機能を変更していない場合も確認が必要な理由

今回のように、空行や設定情報だけを変更した場合、動作確認は不要に見えるかもしれません。

しかし、実際の開発では、変更内容の認識とGit差分が必ず一致しているとは限りません。

例えば、次のような問題が含まれる可能性があります。

• Codexが対象外のファイルも変更している
• Composerの操作によって依存関係が変化している
• 空行と一緒にPHPの記号が削除されている
• 文字コードや改行コードが変化している
• シンボリックリンクの参照先とは別のファイルを編集している

構文検査、コーディング規約、Git差分、WordPressの画面を組み合わせることで、それぞれの検査だけでは見つけられない問題を補います。

コミットするファイルを選択する

すべての確認が完了した後、今回変更した四つのファイルをGitのステージング領域へ追加しました。

git add \
composer.json \
composer.lock \
includes/class-report-builder.php \
includes/class-settings.php

git add .のようにすべての変更をまとめて追加する方法もあります。

しかし、対象ファイルを明示すると、意図していないファイルをコミットへ含める可能性を減らせます。

ステージング後、コミットへ含まれる内容をもう一度確認しました。

git status
git diff --staged
git diff --staged --check

git diffではなくgit diff --stagedを使用し、実際にコミットされる差分を確認します。

最初の変更をコミットする

検査と動作確認に問題がなかったため、Ubuntu上での最初の実変更をコミットしました。

git commit -m "chore: align Composer metadata and coding standards"

choreは、機能追加や不具合修正ではなく、開発環境、設定、保守作業などの変更を示すために使用しています。

コミット後、最新のコミットを確認しました。

git log -1 --oneline --decorate

今回作成されたコミットは、次のとおりです。

f58fd39 chore: align Composer metadata and coding standards

最後に、未コミットの変更が残っていないことを確認しました。

git status --short

出力がないため、今回の変更はすべてコミットされ、作業ツリーがクリーンな状態になっています。

コミットとpushを分けて考える

Gitのコミットは、Ubuntu上のローカルリポジトリへ変更履歴を記録する操作です。

一方、pushは、ローカルで作成したコミットをGitHubへ送信する操作です。

コミットを作成したからといって、自動的にGitHubへ公開されるわけではありません。

変更内容や作業単位によっては、複数のコミットをまとめて確認した後にpushする場合もあります。

Codexへ作業を依頼する場合も、調査、変更、コミット、pushを別々の権限として考えます。

今回のような最初の実作業では、人間がすべての差分と検査結果を確認した後にコミットする流れとしました。

Ubuntu環境で一連の作業を完了できた

今回の作業では、WindowsやWSLへ戻ることなく、次の工程をすべてUbuntu上で実施できました。

1. ChatGPTで作業方針を整理する

   変更目的、影響範囲、Codexへ許可する操作を明確にしました。

2. Codexがリポジトリを調査する

   ComposerとPHPCSの指摘内容、変更が必要なファイルを確認しました。

3. Codexが最小限の変更を行う

   Composerの設定と、PHPCSが指摘した余分な空行だけを変更しました。

4. 人間がGit差分を確認する

   対象外の変更や、意図しない依存関係の変更がないことを確認しました。

5. 各種検査を実行する

   Composer、PHP、PHPCS、Git差分の検査を行いました。

6. WordPress上で動作を確認する

   プラグインと管理画面が引き続き正常に動作することを確認しました。

7. 確認済みの変更をコミットする

   変更内容をGitの履歴として記録しました。

環境を構築しただけでなく、実際のプロジェクトで変更を完了できたことで、Ubuntuを日常の開発環境として利用できる見通しが立ちました。

今回の到達点

今回は、Ubuntuへ移行してから最初となる実際の変更を、「Studio317 Report Drafts for Google Analytics」のリポジトリで行いました。

composer.jsonから不要なprivate設定を削除し、ライセンスとしてGPL-2.0-or-laterを追加しました。

あわせて、PHPCSが指摘した二つのPHPファイルの余分な空行を削除し、composer.lockを現在の設定へ整合させました。

Composerの厳密な検査、PHPの構文確認、PHPCS、Git差分の検査、WordPress上の画面確認を行い、既存機能へ影響がないことを確認しました。

最終的な変更は、f58fd39 chore: align Composer metadata and coding standardsとしてコミットしました。

これにより、ChatGPT、Codex、Visual Studio Code、Git、Composer、WordPressを組み合わせた一連のAI伴走開発を、Ubuntu上の実案件で完了できました。