はじめに

今回は、CopilotでWebシステムを作る方向にて、株情報システムをVS Code、GitHub Copilotのエージェント機能、GitHubを使って開発を進めました。

最初からコードを書き始めるのではなく、作りたい機能や安全上の条件を整理し、設計とタスクを文書にしてから実装しました。この記事では、要件定義からFastAPI／SQLiteによる実装、テスト、GitHubへの反映まで、実際に進めた手順を紹介します。

キャプション：開発した株価情報Webシステムの画面

1. まず要件を整理する

最初に取り組んだのは、実装ではなく「何を作るか」の整理です。

株価・板情報や口座情報を表示すること、日次の終値・出来高を収集して保存することなど、希望する機能を並べるだけでは、どこまで作れば完成なのかが曖昧になります。そこで、各機能の目的や利用者、期待する動作、失敗時の扱いを文書にまとめました。

資料ごとに役割を分けたのもポイントです。

• requirements.md：要求、理由、受け入れ条件
• design.md：システム構成や処理方式
• task.md：作業項目と進捗
• テスト資料：確認項目と結果
• 障害表・変更依頼表：不具合や追加要望の記録

会話だけに頼らず、決定事項を資料に残しておくことで、後から実装やテストの範囲を確認しやすくなりました。

キャプション：機能の希望を、確認可能な受け入れ条件として要件定義書として記録

【役割】

あなたは、システム開発プロジェクトに精通したシニアプロジェクトマネージャーです。

docs\01_ユーザ要望.mdを元に03_要件定義書.mdを作成して下さい。what,why,受け入れ条件を記載して下さい。howは書かないでください。

キャプション：要件資料を作成したときのCopilotへの依頼文

2. Copilotエージェントに作業を依頼する（設計～実装まで）

要件をまとめた後、Copilotエージェントを使って、設計からコードの調査や実装、テストの追加を進めました。

依頼するときは、単に「この機能を作って」と伝えるのではなく、対象範囲や確認条件を具体的にします。たとえば、どの画面やAPIを変更するか、エラー時にどう振る舞うか、実口座に接続しないこと、関連資料も更新することなどです。

エージェントの提案は、そのまま採用せず、既存コードの設計に合っているか、エラーを成功扱いしていないか、テストで動作を確認できるかを見ながら進めました。

又、実装までの依頼文は、今回は、以下のシンプルな文章にてお願いしてみました。

requirements.mdを元にdesign.mdを作成しなおして下さい。

キャプション：design.mdの作成依頼をした際の依頼文

design.mdを元にtask.mdを作成して下さい

キャプション：design.mdを元にtask.mdの作成依頼をした際の依頼文

task.mdを元に実装して下さい。

キャプション：task.mdを元に実装をした際の依頼文

3. FastAPIとSQLiteで構成する

今回確認できたプロジェクトでは、APIにFastAPIを使用し、データ保存にはSQLiteを使っています。ブラウザーの画面からAPIを呼び出し、株価や口座情報の表示、日次データ収集などを行う構成です。株価データ取得にはKabu Station APIを利用します。

認証、ユーザー権限、操作記録、通知、バックアップなども段階的に実装しました。発注や取消については、誤操作で実口座に影響しないよう無効状態を維持し、今回の検証で実際の注文・取消は行っていません。

キャプション：アプリの起動

キャプション：ログイン画面（認証コード付き）

4. テスト用DBとモックで安全に検証する

自動テストでは、利用者の実データではなく、テスト専用のSQLiteデータベースを使います。外部APIはモックに置き換え、実口座への接続や注文送信を避けて、アプリ内部の処理を検証しました。

テストでは、正常に動くケースだけでなく、認証に失敗したとき、API通信が切れたとき、データが取得できないときなども確認します。エラーを成功扱いせず、状態や理由を記録できるかも重要な確認点です。

最終確認では252件のテストが成功しました。既存ライブラリに由来する非推奨警告が1件ありました。この結果は、テスト環境でアプリ内部の処理を確認したものであり、実APIや実口座で動作確認したという意味ではありません。

5. 日次収集の処理を改善する

調査結果をもとに、日次収集でAPIへ登録する銘柄を小分けにし、同じアプリの別プロセスによる板情報取得と競合しにくくする排他制御を加えました。収集終了時に登録銘柄を解除する処理や、途中で止まったときに処理位置を保存して再開する仕組みも整えています。

さらに、対象日を指定して再収集できるようにし、一時的な通信エラーと、HTTP 400のような恒久的なエラーを区別して扱います。恒久的なエラーを自動で繰り返さず、処理位置や失敗理由を記録する設計です。

キャプション：収集対象日、進捗、エラーを確認する画面

キャプション：操作履歴画面

6. GitHubにコミット・プッシュする

実装とテストを確認した後、コード、テスト、設計・進捗資料をGitHubへコミットし、プッシュしました。

コミット前には変更対象を確認し、データベースや秘密情報が含まれていないかをチェックします。今回、利用者データを含む可能性のあるローカルの app.db は、コミット対象から除外しました。

キャプション：GitHubのコミットまたは変更一覧内容

7. UATの終了と、未確認事項

利用者の判断により、現時点のUATは完了とし、発注関連の残作業は次期開発へ分けました。実口座への注文や取消は行わず、発注機能は無効状態のまま維持しています。

UAT全体を終了する判断と、個々の機能がすべて実環境で確認済みであることは別です。実APIでの全件収集など、確認できていない項目は個別に合格扱いせず、未確認として記録しました。

おわりに

VS CodeとCopilotエージェントを使うことで、コードの調査、実装、テストを一連の流れとして進めやすくなりました。一方で、AIにコードを作ってもらうだけでは、要件の整理、安全性の確認、実環境での受け入れまで完了したことにはなりません。

今回の開発で特に大切だと感じたのは、次の点です。

• 実装前に要件と受け入れ条件を文書にする
• 状態表示とバックグラウンド処理の実行状況を区別する
• テストを実データや実口座から隔離する
• 外部APIのエラーを記録し、恒久的なエラーを自動再送しない
• テスト成功と実環境での確認を混同しない
• GitHubへの反映前にDBや秘密情報が含まれていないか確認する

Copilotエージェントは強力な開発支援になりますが、最後に結果を判断するのは人です。要件、コード、テスト、進捗記録をつなげて進めることが、安心して開発を続けるための土台になりました。

---