【第5回】GitHubとCodexを連携してAI伴走開発の流れを整える

今回整える開発の流れ

今回の目的は、Ubuntu上で次の流れを安全に行えるようにすることです。

1. GitHubからプロジェクトを取得する

   既存のWordPressプラグインやテーマのリポジトリを、Ubuntuの開発環境へ配置します。

2. Visual Studio Codeでプロジェクトを開く

   ソースコード、設定ファイル、Gitの状態を一つの画面で確認します。

3. Codexへ調査や変更を依頼する

   依頼する範囲と禁止する操作を明確にし、プロジェクト内の作業を担当してもらいます。

4. 変更内容を人間が確認する

   Gitの差分、テスト結果、変更されたファイルを確認してから、変更を採用します。

5. 必要に応じてChatGPTへ共有する

   設計や判断について相談する場合は、対象ファイルやGitの差分をChatGPTへ共有します。

6. 確認済みの変更をGitへ記録する

   問題がないことを確認した後に、コミットとGitHubへの送信を行います。

Codexがコードを変更できるようになっても、人間による確認を省略するわけではありません。

AIへ依頼する作業と、人間が判断する作業を分けることが、今回の重要な目的です。

Gitの基本設定を行う

最初に、Ubuntu上のGitへ、コミットを作成するユーザー情報を設定しました。

git config --global user.name "Kimiya Watabe"
git config --global user.email "watabe@s317.com"
git config --global init.defaultBranch main

user.nameとuser.emailは、Gitのコミットへ記録される作成者情報です。

init.defaultBranchにはmainを指定し、新しいリポジトリを作成した際の初期ブランチ名を統一しました。

設定した内容は、次のコマンドで確認できます。

git config --global --list

Gitの設定には、すべてのリポジトリへ適用するグローバル設定と、特定のリポジトリだけへ適用するローカル設定があります。

案件や所属組織によってメールアドレスを使い分ける場合は、リポジトリ単位で設定を上書きできます。

git config user.name "コミット作成者名"
git config user.email "プロジェクト用メールアドレス"

SSH鍵を使用してGitHubへ接続する

GitHubからリポジトリを取得したり、変更を送信したりするためには、UbuntuとGitHubの間で認証を行う必要があります。

今回は、SSH鍵を使用して接続する方法を採用しました。

SSH鍵は、公開鍵と秘密鍵の組み合わせで本人確認を行う仕組みです。

公開鍵

GitHubへ登録します。他者に知られても、秘密鍵がなければ認証には利用できません。

秘密鍵

Ubuntu内で厳重に管理します。GitHub、ChatGPT、Codex、Gitリポジトリなどへ共有してはいけません。

SSH鍵を新しく作成する場合は、次のようなコマンドを使用します。

ssh-keygen -t ed25519 -C "GitHubに登録しているメールアドレス"

作成された公開鍵の内容を確認します。

cat ~/.ssh/id_ed25519.pub

表示された公開鍵をGitHubのSSH keysへ登録します。

登録後、UbuntuからGitHubへ接続できるか確認しました。

ssh -T git@github.com

認証に成功すると、GitHubのユーザー名を含むメッセージが表示されます。

これにより、パスワードをコマンドへ直接入力することなく、GitHubのリポジトリへSSHで接続できるようになりました。

GitHub CLIを利用できるようにする

GitHub CLIは、GitHubの操作をターミナルから行うための公式コマンドラインツールです。

Git自体はソースコードの履歴を管理するツールですが、GitHub CLIを利用すると、GitHub上のリポジトリ、Issue、Pull Requestなども操作できます。

認証状態は、次のコマンドで確認しました。

gh auth status

GitHub CLIからログインする場合は、次のコマンドを使用します。

gh auth login

表示される選択肢に従い、GitHub.com、SSH接続、ブラウザ認証などを選択します。

GitとGitHub CLIは似ていますが、担当する役割が異なります。

GitHubからプロジェクトを取得する

GitHubとの接続を確認した後、既存のプロジェクトをUbuntuへ取得します。

SSHを使用する場合は、GitHubのリポジトリ画面に表示されるSSH形式のURLを利用します。

git clone git@github.com:GitHubユーザー名/リポジトリ名.git

WordPressプラグインの場合は、ローカル開発サイトのwp-content/pluginsから参照できる場所へ配置します。

今回のWordPress開発サイトでは、プラグインディレクトリは次の場所です。

/var/www/studio317/wordpress-dev/public/wp-content/plugins

リポジトリを取得した後は、ディレクトリへ移動し、Gitの状態を確認します。

cd /取得したリポジトリのパス

git status
git branch --show-current
git remote -v
git log -1 --oneline

ここでは、作業ツリーに未保存の変更がないこと、利用しているブランチ、接続先のGitHubリポジトリ、最新のコミットを確認します。

既存プロジェクトの作業を始める前に、現在の状態を確認しておけば、どの変更が今回の作業によるものか判断しやすくなります。

WordPressからプラグインを確認する

WordPressプラグインのリポジトリを配置した場合は、WordPressが正しく認識していることを確認します。

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

wp plugin list

対象のプラグインが一覧へ表示されれば、WordPressからプラグインとして認識されています。

プラグインを有効化する場合は、スラッグを指定します。

wp plugin activate プラグインのスラッグ

ただし、既存のプラグインを取得した直後に有効化するとは限りません。

必要なPHPバージョン、依存関係、設定ファイル、データベース処理などを確認し、現在のWordPress環境で安全に実行できることを確かめてから有効化します。

特に、本番サイトのデータをそのままローカル環境へ持ち込む場合は、メール送信、外部API、決済、定期処理などが誤って実行されないよう注意が必要です。

Visual Studio Codeでプロジェクトを開く

取得したリポジトリは、ターミナルからVisual Studio Codeで開けます。

cd /取得したリポジトリのパス
code .

.は、現在のディレクトリを意味します。

Visual Studio Codeでプロジェクトを開くと、ソースコードの編集だけでなく、Gitの変更状況、ターミナル、Codexを同じ画面で利用できます。

Ubuntu上のVisual Studio Codeは、Windowsから共有されたファイルではなく、Ubuntuのファイルを直接編集します。

そのため、Linuxの所有者、グループ、実行権限、改行コード、ファイル名の大文字と小文字などを、実際の実行環境に近い状態で確認できます。

Visual Studio CodeでCodexを利用する

Visual Studio Codeには、Codexを利用するための拡張機能を導入しています。

今回の環境では、Visual Studio Code上のCodex拡張機能と、ターミナルから利用できるCodex CLIの両方を使用できます。

どちらを利用する場合も、最初に対象となるプロジェクトを正しく開いていることを確認します。

Codex CLIを使用する場合は、対象のリポジトリへ移動してから起動します。

cd /取得したリポジトリのパス
codex

別のディレクトリでCodexを起動すると、意図していないファイルを調査したり、必要なファイルを見つけられなかったりする可能性があります。

Codexへの依頼範囲を明確にする

Codexへ作業を依頼する際は、実現したい内容だけでなく、変更してよい範囲と実行してはいけない操作も伝えます。

例えば、WordPressプラグインの不具合を調査する場合は、次のような内容を含めます。

このリポジトリを調査し、管理画面で発生しているエラーの原因を特定してください。

まずは調査のみを行い、ファイルは変更しないでください。
原因と修正案、影響するファイルを報告してください。
データベース、外部API、本番環境、GitHubへのpushは操作しないでください。

調査結果を確認した後、必要であれば修正を依頼します。

提示した修正案のうち、最小限の変更で対応してください。

既存の仕様を変更せず、対象外のリファクタリングは行わないでください。
変更後にPHPの構文確認とGit差分の確認を行ってください。
コミットとpushは行わないでください。

最初から調査、修正、テスト、コミット、GitHubへの送信までをまとめて依頼すると、途中の判断ができなくなります。

作業を段階に分けることで、人間が結果を確認してから次へ進めます。

Codexが変更した内容をGitで確認する

Codexが作業を完了した後は、説明だけを読んで判断せず、実際のGit差分を確認します。

最初に、変更されたファイルの一覧を確認します。

git status --short

続いて、変更された内容を確認します。

git diff

ステージング済みの変更がある場合は、次のコマンドも使用します。

git diff --staged

不要な空白、行末の問題、競合マーカーなどは、次のコマンドで確認できます。

git diff --check

PHPファイルを変更した場合は、構文エラーがないことも確認します。

php -l 変更したファイル.php

複数のPHPファイルを確認する場合は、プロジェクトに用意されているテストやComposerのスクリプトを優先して使用します。

Codexから「テストに成功した」という報告があった場合も、どのテストを実行したのか、対象範囲は十分か、実行していない確認項目はないかを確認します。

新規ファイルはGit差分だけでは確認できない

git diffには、通常、Gitでまだ追跡されていない新規ファイルの内容は表示されません。

新規ファイルの存在は、git status --shortで確認できます。

?? 新しく作成されたファイル.php

先頭に??が表示されているファイルは、まだGitの追跡対象になっていません。

内容を確認する場合は、Visual Studio Codeでファイルを開くか、ターミナルから直接確認します。

sed -n '1,240p' 新しく作成されたファイル.php

新規ファイルを含む変更を確認する際は、Git差分だけでなく、git statusとファイルそのものをあわせて確認する必要があります。

ChatGPTへファイルを共有する

Codexが作成または編集したファイルについて、設計上の判断、文章、コードの妥当性などをChatGPTへ相談することがあります。

Windowsではエクスプローラーからファイルをコピーしていましたが、Ubuntuでも基本的な操作は同じです。

Ubuntuの「ファイル」アプリで対象ファイルを開き、ChatGPTの入力欄へドラッグ＆ドロップします。

対象のプロジェクトが深い階層にあり、毎回ファイルを探すのが大変な場合は、ホームディレクトリへ共有用フォルダーを作っておくと便利です。

mkdir -p ~/ChatGPT-share

共有するファイルをコピーします。

cp /共有するファイルのパス ~/ChatGPT-share/

その後、「ファイル」アプリからChatGPT-shareを開き、必要なファイルを添付します。

共有用フォルダーは一時的な受け渡し場所として使用し、確認が終わったファイルは必要に応じて削除します。

複数の変更はGit差分として共有する

複数のファイルが変更されている場合は、すべてのファイルを個別に添付するより、Gitの状態と差分をテキストファイルへ保存する方法が適しています。

cd /対象リポジトリのパス

git status --short > ~/ChatGPT-share/git-status.txt
git diff > ~/ChatGPT-share/git-diff.txt
git diff --check > ~/ChatGPT-share/git-diff-check.txt 2>&1

作成したファイルをChatGPTへ添付すれば、どのファイルが変更され、どのような差分があるのかをまとめて共有できます。

新規ファイルの内容はgit-diff.txtに含まれないため、そのファイル自体も添付します。

ファイル名だけでは判断できない場合は、Codexへ共有用ファイルを準備してもらうこともできます。

今回変更したファイルを確認し、ChatGPTへの共有用として、
git statusの結果を ~/ChatGPT-share/git-status.txt に、
git diffの結果を ~/ChatGPT-share/git-diff.txt に保存してください。

ソースファイルの変更、Gitへの追加、コミット、pushは行わないでください。

共有してはいけないファイルを確認する

ChatGPTへファイルを共有する前に、秘密情報が含まれていないことを確認します。

特に、次のようなファイルや情報は、そのまま共有しません。

• SSHの秘密鍵
• APIキー
• アクセストークンと更新トークン
• OAuthクライアントシークレット
• データベースのパスワード
• 本番環境の接続情報
• 利用者の個人情報
• .envやwp-config.phpなどの設定ファイル

設定ファイルについて相談する必要がある場合は、秘密情報を伏せたコピーを作成します。

cp wp-config.php ~/ChatGPT-share/wp-config-redacted.php

コピーしたファイルを開き、パスワード、鍵、トークンなどを削除または置き換えてから共有します。

Git差分にも秘密情報が含まれる可能性があるため、作成したgit-diff.txtの内容も添付前に確認します。

変更をコミットする

コード、Git差分、テスト結果、WordPress上の動作を確認し、問題がなければ変更をGitへ記録します。

最初に、コミットへ含めるファイルを選択します。

git add 変更したファイル

ステージングした内容を確認します。

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

問題がなければ、変更内容を表すコミットメッセージを付けます。

git commit -m "fix: 修正内容の要約"

コミット後は、作業ツリーに意図しない変更が残っていないことを確認します。

git status
git log -1 --oneline

GitHubへ送信する場合は、対象のブランチを確認してからpushします。

git push origin ブランチ名

Codexにコミットやpushまで任せる場合もありますが、最初の段階では、人間が差分とテスト結果を確認した後に実行する方針としました。

ChatGPT、Codex、人間の役割を整理する

今回の環境では、ChatGPTとCodexのどちらもAIですが、同じ役割で利用するわけではありません。

ChatGPTで方針を整理し、Codexへ具体的な作業を依頼し、人間が結果を確認するという流れが基本になります。

Codexからの報告をそのまま正しいと判断するのではなく、Git差分や実際の画面で確認することが重要です。

今回の到達点

今回は、Ubuntu上のGitへコミット作成者情報を設定し、SSH鍵とGitHub CLIを利用してGitHubへ接続できる状態を整えました。

GitHubから取得したプロジェクトをVisual Studio Codeで開き、Codex拡張機能とCodex CLIから調査や編集を行うための基本的な流れも確認しました。

Codexが変更した内容は、git status、git diff、構文確認、テストなどを使用し、人間が確認してからコミットします。

また、Ubuntuの「ファイル」アプリや共有用フォルダーを利用し、Codexが作成・編集したファイルやGit差分をChatGPTへ共有する方法も整理しました。

これにより、ChatGPTで方針を検討し、Codexがプロジェクト内で作業し、人間が確認してGitへ記録するという、AI伴走開発の基本的な環境が整いました。