先日アップしたこちらの記事の対比です。
同様のオーダーでGitHub CopilotのPlanモードを利用した場合に、どのような結果になるのか比較するためお試ししてみました。
注意
envやsecret、脆弱性関連に関する要求は行っていません。
今回の目的がGitHub CopilotのPlanモードでの製造工程や成果物の比較のみのためです。
間違えても商用向けでこのような脆弱な重要な情報が洩れるような構造にしないようご注意ください。
あくまでわたし個人のこのPlanで今回投入した段階での印象の比較です
利用シーンやオーダーの仕方・表現、モデルなどによっても結果は異なると思います。
あくまで興味本位での比較となります。
Planモードで要求を伝えてみる
Antigravityの記事と同様のPlanを投入します。
RHEL10+Apache2.4+PHP8.3、PostgreSQL16の2階層構造とし、1:1双方向のテキストメッセージ送受信Webアプリを作成したい。
WebSocketまでのレスポンスは不要で、定期的な状態確認をAjaxで行えればよい
新たな書き込みが相手から会った場合には未読件数を表示するUI＋端末への通知機能を具備する。
履歴情報はDBに蓄え次回表示時に復元可能とする。
直近の送信については編集または取り消しが可能で、送信先にも編集または取り消しされた旨の通知が入り識別可能Iとする。
コーディング規約はPSR-12をベースとする。
対象となる言語はjaのみ。技術者も日本人技術者のためコードはPHPDoc、コミットコメントなどは日本語で記載する。技術車間の引継ぎがしやすいように利用方法のMarkdownやコード内のコメントは丁寧に記する。
なお、ローカル環境で実行可能なDocker環境を.docker/内に構築しそこでテスト事項可能とする。
Google Antigravityではこれでもいい感じのImplementation Plan、Taskを補完し立ててもらえましたが、GitHub Copilotではどうでしょうかね!?
## Plan: RHEL10/PHP/PostgreSQLチャット基盤
RHEL10上のApache 2.4＋PHP 8.3とPostgreSQL 16をDocker(.docker配下)で再現し、Ajaxポーリング型の1対1メッセージ機能と未読・編集/取消通知を備えたPSR-12準拠の日本語実装を整備する。READMEや利用手順を含むドキュメントも日本語で用意し、履歴永続化と復元、端末通知を考慮した設計を行う。
### Steps
1. アーキテクチャ指針と要件を README.md と docs/architecture.md に整理し、双方向要件・Ajaxポーリング条件・通知仕様を明文化。
2. .docker/ 以下に RHEL10ベースApache/PHPコンテナと PostgreSQL16 コンテナを定義する docker-compose、Dockerfile、init SQL を作成し、ローカル起動方法を README に追記。
3. src/ 以下に PSR-12 & PHPDoc 準拠のアプリ骨格 (エンティティ、リポジトリ、サービス、コントローラ) を配置し、1:1会話・履歴永続化・未読件数ロジックを実装。
4. public/ のフロントエンドで Ajaxポーリング、未読バッジ、直近メッセージの編集/取消UI、通知許可フローを構築し、通知API連携を追加。
5. tests/ にユニット・統合テスト、lint/formatter設定、CIスクリプト案を準備し、直近メッセージ編集/取消や未読計算の検証を自動化。
### Further Considerations
1. 通知方式: ブラウザ Push API / OS ネイティブ通知 / メール通知のどれを採用するか要確認。
2. Ajaxポーリング間隔や同報制御の負荷要件を定義し、将来WebSocketへ切替可能な設計にするか検討。
曖昧な個所についての指示が求められております。
Further Considerations
1: クライアントサイドからのAjax通信
2: 5sec間隔とし、ホスティング環境想定でApache設定変更不可のためWebSocket切り替えはスコープ外
## Plan: RHEL10チャット基盤更新
クライアント側のAjaxポーリングを5秒間隔で実装し、Apache設定を変更せずWebSocketを使わない構成を明記したチャットアプリ計画を整える。Docker上のRHEL10＋Apache 2.4＋PHP 8.3とPostgreSQL 16を前提に、PSR-12と日本語ドキュメントで実装指針を固める。
### Steps
1. README/docsでアーキ要件と Ajax 5秒ポーリング制約、WebSocket不使用理由、通知方針を日本語で整理。
2. .docker/ に RHEL10 Apache/PHP と PostgreSQL 16 の Dockerfile・docker-compose・初期化SQLを配置し、クライアントAjaxポーリング前提の設定説明を追加。
3. src/ に PSR-12準拠のメッセージ送受信サービス・未読計算・編集/取消通知ロジックを実装し、Ajax APIエンドポイント仕様を PHPDoc で詳述。
4. public/ のUIで 5秒間隔のAjaxポーラー、未読バッジ、直近メッセージ編集/取消UI、通知表示・許可処理を組み込む。
5. tests/ と CI 設定で Ajax API応答、未読計算、編集/取消通知のユニット/統合テストを用意し、5秒ポーリング想定の負荷テスト指針を記述。
### Further Considerations
1. 端末通知方式：ブラウザPush APIとOS通知のどちらを採用するか要決定。
2. 5秒ポーリングの負荷対策：スロットリングや差分応答にするか検討が必要。
また、未確定個所に対する指示をしていきます。
Further Considerations
1: OS通知
2: 差分の未取得
## Plan: RHEL10チャット基盤更新 (差分未取得＋OS通知)
RHEL10上のApache 2.4＋PHP 8.3とPostgreSQL 16をDockerで再現し、5秒周期のAjaxポーリングで差分未取得メッセージのみを取得、OS通知を行う1対1チャットを設計する。PSR-12準拠、日本語ドキュメント・コメントで実装指針を固める。
### Steps
1. README/docsに要件（5秒Ajax、差分未取得取得、OS通知、WebSocket非対応）と利用手順を明文化。
2. .docker/ に RHEL10 Apache/PHP と PostgreSQL16 の Dockerfile・docker-compose・initSQL を配置し、差分APIエンドポイントや通知依存の設定を説明。
3. src/ に PSR-12準拠のメッセージ/未読/通知サービス、差分取得API、編集・取消処理をPHPDoc付きで実装設計。
4. public/ UIで5秒ポーリング差分取得、未読バッジ、直近メッセージ編集/取消UI、OS通知許可・発火ロジックを実装方針化。
5. tests/ と CI 用設定で差分API、未読計算、編集/取消通知のユニット・統合テスト、5秒ポーリング想定の負荷シナリオを準備。
### Further Considerations
1. OS通知はブラウザ Notification API＋Service Worker で統一する想定で問題ないか確認。
2. 差分取得の判定キー（最新タイムスタンプ vs メッセージID）とデータ整合の要件を確定する必要あり。
途中、略
Start Inprimantationの直前のPlanは以下の通り
## Plan: RHEL10チャット基盤 (Cookie差分＋OS通知)
RHEL10＋Apache 2.4＋PHP 8.3とPostgreSQL 16をDocker(.docker配下)で再現し、5秒ごとAjaxポーリングでCookie保持の差分トークンを用いて未取得メッセージのみ取得し、OS通知で受信を知らせる1対1チャットをPSR-12準拠・日本語ドキュメントで構築する。
### Steps
1. README/docsに要件（5秒Ajax、Cookie差分、OS通知、WebSocket非対応）と利用手順、通知許可手順を日本語でまとめる。
2. .docker/ に RHEL10 Apache/PHP と PostgreSQL16 の Dockerfile・docker-compose・初期SQLを作成し、環境構築と差分APIの前提条件を記す。
3. src/ に PSR-12準拠のメッセージ、未読、Cookie差分トークン管理、編集/取消通知サービスとAPIエンドポイントをPHPDoc付きで設計。
4. public/ UIで5秒ポーリング、Cookie更新処理、未読バッジ、直近メッセージ編集/取消UI、OS通知許可・通知発火ロジックを組み立てる。
5. tests/ とCI想定で差分API、Cookie更新、未読計算、編集/取消通知、OS通知トリガーのユニット・統合テスト方針を用意する。
### Further Considerations
1. サンプル用途のためCookie署名などの追加セキュリティは今回は考慮不要。
さて、ここで「Start Inprimantation」
セットアップしてテストしてください
コーディングで一段落したようなので「セットアップしてテストして」とし
試してもらったらかなりDockerやプログラムの修正を繰り返していました。
画面イメージはなかなかイケている画面ですかね。（まぁ好みの問題ではありますが）
が…動かない💦
コンソールログの一部をGitHub CopilotのAgentに渡し修正してもらいます。
通知も動作しているようです。
ただ、直前のメッセージの編集や取り消しが動作せず、また、立場が切り替えられないのでチャット相手の様子がわかりません...。
佐藤花子さん側の画面を確認するには？
**佐藤花子側を確認する手順**
- ブラウザをもう一つ開きます（Chromeならシークレットウィンドウを推奨）。同じ `http://localhost:18080/` を開いて通知許可を与えます。
- 2つ目のウィンドウで送信者/受信者のIDを入れ替える必要があります。暫定実装では app.js の `state.userId` と `state.recipientId` が固定（自分=1, 相手=2）なので、佐藤花子視点では下記のいずれかを行います。
1. デベロッパーツールのコンソールで `state.userId = 2; state.recipientId = 1;` を実行し、`handlePoll()` を呼び直す。
2. もしくは暫定的に app.js を編集して `userId: 2`, `recipientId: 1` に変更し、ページを再読み込み。
- こうして ID を入れ替えたブラウザは佐藤花子視点、元のブラウザは山田視点として操作でき、互いにメッセージ送信・未読・通知を確認できます。
ちょっとひどい仕打ち💦
テストですので利用者切替機能を追加してもらいます。
ブラウザのルートでログインユーザを切り替えられるようにして
これでヘッダー部にてログインユーザの切り替えができるようになりました。
ただ、また別の問題が…
デスクトップ通知が重複して通知される上に止まらない…。
今回の勝負的には完全にGoogle Antigravityさんの勝利でしたね！
開発工程での使い勝手もGitHub CopilotのPlanモードでは、会話をしながら不確定要素を決定して行きますが
今回で言えば
- DBのテーブル定義、カラム定義がおまかせ
- 利用者のユーザ数がおまかせ
- 全体的なデザインに関するオーダー
といったものが欠落していました。
予めPlanを投入する段階で決定していれば要望として伝えればよいですが…
Google Antigravityのように
Implementation PlanやTaskとして提示されそれをレビューし指摘する方が、
網羅性が上がりそうだなというのが印象です。
また、Docker起動からブラウザテストまでスムーズに実施してくれたため
開発者側は、他のタスクを行う事で効率的に開発業務が行えそうな感触でした。
SDDまでかっちりしなくてよいけどある程度手戻りを防いで開発をしたい場合は
Google Antigravityも良い選択なのかなと感じています。
※得意不得意やエージェントに対するオーダー方法等、様々な要因で結果にブレはあるとは思いますが、個人的なファーストインプレッションは上記のようなイメージでした。