Memologを作る上で、自分とGitHub Copilotはどう役割分担したか
この記事を書こうと思ったきっかけ
このMemologは、Astroで作ったブログをAzure Static Web Appsで配信し、Azure FunctionsやTable Storage、Azure AI Translator、Application Insightsなどを組み合わせて育ててきました。
コードのかなりの部分はGitHub Copilotと一緒に作っています。ただ、振り返ってみると「自分が要件を書き、Copilotがコードを書いた」という単純な分担ではありませんでした。
- 最初はVS CodeのAgent Modeで、要件、設計、実装計画を会話しながら形にした
- 途中からGitHub Issueを作り、Copilot coding agent（この記事ではCloud Agentと呼びます）へ非同期で実装を任せた
- Cloud Agentが作ったPull Requestを、ローカルのCopilotとレビューして統合した
- 並列実行による重複や調整コストを経験し、現在はIssue-firstを維持しながらローカル実装を中心にした
そこで、過去の会話ログ、GitHub Issue、Pull Request、コミット、現在のリポジトリルールを照合し、どの仕事を自分が持ち、どこをCopilotへ任せたのかを整理してみます。
目次
- 先に結論
- Memologで作ったもの
- 第1段階: Agent Modeで構想から実装までつなぐ
- 第2段階: IssueからCloud Agentへ実装を渡す
- ローカルCopilotを品質ゲートにした
- 並列化で同じ修正が2本できた
- 第3段階: Issue-firstのままローカル実装へ寄せる
- 自分とCopilotの役割分担
- 実行ログから見えたこと
- 今後もCloud Agentを使いたい場面
- まとめ
先に結論
自分とCopilotの役割分担を一言で表すと、次のようになります。
自分は「何のために作るか」「何を採用するか」「どこまで責任を持つか」を決め、Copilotは調査、構造化、実装、検証を加速する。
Copilotへ実装を任せても、要件の優先順位、Azureのコストやセキュリティ制約、期待するユーザー体験、変更を本番へ入れるかどうかは自分が決めます。一方で、関連コードの探索、選択肢の比較、反復的な修正、テスト、本番状態の確認はCopilotが得意でした。
開発フローも固定ではありませんでした。
Memologで作ったもの
Memologは静的なブログから始まりましたが、現在は次のような構成になっています。
| 領域 | 主な構成 |
|---|---|
| Web | Astro、MDX、React Islands、Azure Static Web Apps |
| API | Azure Functions Flex Consumption |
| データ | Azure Table Storage、Private Endpoint |
| 多言語 | Azure AI Translator、GitHub ActionsのOIDC認証 |
| 監視 | Application Insights |
| Infrastructure as Code | Bicep |
| 開発管理 | GitHub Issue、Pull Request、Actions、Copilot |
特にAzure環境では、共有キー認証の禁止やパブリックネットワークアクセスの無効化など、テナント固有のポリシーがありました。そのため、一般的なサンプルをそのまま使うのではなく、Managed Identity、Private Endpoint、OIDCを前提に設計し直す必要がありました。
このような制約を発見し、採用する構成を決める部分は、人とCopilotの共同作業になりました。
第1段階: Agent Modeで構想から実装までつなぐ
最初の開発では、VS CodeのAgent Modeに対して、次の順番で進めたいと伝えました。
- 設計をdocsに残す
- サイトのデザインをする
- Phase 1のBicepを書く
- アプリケーションをスキャフォールドする
この指示をもとに、Copilotはリポジトリを作るだけでなく、docs/architecture.mdとdocs/design.mdへ考え方を残し、Astroの画面、コンポーネント、スタイル、Bicepを同じ流れで実装しました。
この段階で自分が担ったのは、主に次の部分です。
- 個人サイトを復活させたいという目的
- Azureを使うこと、Static Web Appsを中心にすること
- デザインや機能の優先順位
- どの順番で設計と実装を進めるか
Copilotが担ったのは、曖昧な要望をドキュメントとコードへ落とし、ビルド可能な最初の状態まで一気につなぐことでした。
この進め方の良さは、設計と実装の文脈が切れにくいことです。会話の中で決めた理由を、そのままドキュメント、コード、テストへ反映できます。
一方で、長い会話の中だけに判断が残ると、あとから「なぜこの実装になったのか」を追いにくくなります。そこで次に、GitHub Issueを仕事の単位として使うようになりました。
第2段階: IssueからCloud Agentへ実装を渡す
多言語対応では、まず海外SEOの方針をAgent Modeと相談しました。ブラウザ翻訳では英語ページの実体ができず、英語検索からの流入を狙いにくいため、翻訳済みHTMLを/en/配下へ生成する方針を選びました。
その後、Epicと個別Issueへ分解しました。
| Issue | 内容 |
|---|---|
| #4 | 多言語対応と海外SEO全体のEpic |
| #1 | Astroの多言語ルーティング基盤 |
| #2 | Azure AI Translatorを使う翻訳パイプライン |
| #3 | hreflang、canonical、sitemapなどのSEO仕上げ |
最初の#1をCloud Agentへ割り当てると、Cloud Agentは非同期で作業し、Draft Pull Requestを作りました。自分はPCの前で実装完了を待ち続けなくてもよく、別の作業と並行できました。
この時期の役割分担は明快でした。
- 自分: 目的、優先順位、制約、採用判断をIssueにする
- Cloud Agent: Issueの範囲を実装し、PRとテスト結果を返す
- ローカルCopilot: PRの差分を読み、手元の環境でビルド・検証する
- 自分: レビュー結果を見て、マージ、修正依頼、見送りを決める
ローカルCopilotを品質ゲートにした
Cloud AgentがPRを作ったからといって、そのままマージしたわけではありません。
多言語の翻訳パイプラインを扱ったPR #11では、当初の実装がGitHub ActionsからAzureへOIDC認証する方針になっていました。しかし、その時点では自分のテナントでApp Registrationを作れないという制約があり、提案された構成のままでは動かないと判断しました。
ローカルCopilotと差分を確認し、次のように進めました。
- コード上の衝突だけでなく、運用方針との衝突を確認する
- PRへRequest Changesを出す
- Azure認証をCIから外し、当時動作確認できていたローカルAAD認証へ修正してもらう
- 修正後にローカルビルドと生成された英語ページを確認する
その後、同じテナントの別システムでUser Assigned Managed Identityとfederated credentialを使ったOIDCが動いていることを確認し、前提を更新しました。現在はMemolog専用Managed Identityを使い、GitHub Actions上で翻訳を実行しています。
ここで大事だったのは、最初の判断に固執しなかったことです。Copilotの回答も、自分の理解も、実際の環境で反証されたら直します。
並列化で同じ修正が2本できた
Cloud Agentを使っていて、うまくいかなかった例もあります。
英語記事のカードが日本語ホームへ混ざり、存在しない/blog/en/...へのリンクができた問題では、Issue #13に原因と修正方針をまとめ、Cloud Agentへ割り当てました。
ところが、同じ問題を扱うIssue #15も作られてしまい、2つのIssueからPR #14とPR #16が作成されました。確認すると、どちらもsrc/pages/index.astroの同じ2行へ同じフィルターを追加する、バイト単位で同一の修正でした。
最終的には次のように整理しました。
- PR #14をレビューし、ビルド後にマージ
- PR #16は重複としてクローズ
- Issue #15もIssue #13の重複としてクローズ
- 本番ホームから誤った英語リンクが消え、英語記事が正常に表示できることを確認
この経験から、並列化すると実装時間は短くできても、仕事の境界が曖昧だと統合コストが増えると分かりました。
Cloud Agentの問題というより、Issueを切る側の調整不足です。小さく密結合なリポジトリでは、複数のAgentが同じファイルや同じ不具合を触らないよう、Issue間の依存と重複を先に確認する必要があります。
第3段階: Issue-firstのままローカル実装へ寄せる
サイトの機能が増えるにつれ、1つの修正でWeb、API、Infrastructure as Code、GitHub Actions、本番Azure環境まで確認する場面が増えました。
こうした仕事は、すでにローカルで持っている会話の文脈や、直前の検証結果を引き継いだ方が速いことがあります。そこで現在は、Issueを先に作る原則を残しつつ、実装自体はローカルCopilotと進めることが多くなりました。
リポジトリの.github/copilot-instructions.mdには、現在次のルールを置いています。
- 変更前に既存Issueへ関連付ける。なければIssueを作る
- 同じ目的のIssueを重複して作らない
- 実装上の判断、検証結果、デプロイ結果、関連PRをIssueへ残す
- 実行者の指定がなければ、現在のローカルセッションで作業する
この形なら、会話からそのまま実装・検証できる速さを保ちながら、あとからIssueを見れば目的と結果を追えます。
自分とCopilotの役割分担
現在の分担を表にすると、次のようになります。
| 仕事 | 自分 | GitHub Copilot |
|---|---|---|
| 目的 | 何を実現したいか、誰のためかを決める | 目的を要件やタスクへ構造化する |
| 優先順位 | 今やること、後でやること、やらないことを決める | 依存関係や実装順を提案する |
| アーキテクチャ | コスト、セキュリティ、運用上の制約から採否を決める | 選択肢、公式情報、既存実装を調査して比較する |
| 実装 | 期待する振る舞いと許容範囲を示す | コード、テスト、IaC、ドキュメントを変更する |
| レビュー | リスクを受け入れるか、体験として良いかを判断する | 差分、回帰、セキュリティ、テスト不足を検出する |
| 検証 | 本番へ入れるか、問題を解決できたかを判断する | ビルド、テスト、CI、HTTP応答、ログを確認する |
| 記録 | 残すべき意思決定を選ぶ | Issueやドキュメントへ再現可能な形で整理する |
| 最終責任 | マージ、公開、Azure変更を承認する | 結果と不確実性を報告する |
特に、自分が手放さないようにしているのは次の4つです。
- 目的: 技術的に作れることと、作る価値があることは別です
- 制約の受け入れ: コスト、セキュリティ、プライバシー、運用負荷をどこまで許容するかは人が決めます
- 採否: Copilotの提案は選択肢であり、決定ではありません
- 本番責任: 最後に公開・デプロイする責任は自分にあります
逆に、Copilotへ積極的に任せているのは、広いコードベースから関係箇所を探すこと、仮説をテストで絞ること、同じ確認を正確に繰り返すことです。
実行ログから見えたこと
今回の振り返りでは、会話の記憶だけでなく、セッションログとGitHub上の記録を突き合わせました。代表的な出来事は次の通りです。
| 日付 | 記録に残っていた依頼・判断 | 確認できた結果 |
|---|---|---|
| 2026-07-13 | 設計、デザイン、Phase 1 Bicep、スキャフォールドの順で進める | 設計文書、Astroサイト、Bicep、初期ビルドを作成 |
| 2026-07-13 | 多言語対応をIssueへ分解し、#1をCloud Agentへ割り当てる | PR #5をローカルでレビューし、英語ルートを含むビルドを確認 |
| 2026-07-13 | PR #11の認証方針がテナント制約と合わない | Request Changesを出し、方針修正後に再検証 |
| 2026-07-14 | PR #14と#16をまとめてレビューする | 同一修正と確認し、片方をマージ、片方を重複クローズ |
| 2026-07-20 | OIDCの前提を実環境の証拠から見直す | Managed Identityを使うCI翻訳を構築し、本番で英語記事を確認 |
| 2026-07-31 | この記事を作る | Issue #117を作成し、実行ログ・Issue・PRを照合してローカル下書きを作成 |
ログを見返して分かったのは、Copilotとの開発は「正しい答えを一度でもらう作業」ではなく、仮説を実装し、環境で確かめ、違えば記録ごと更新する作業だということです。
今後もCloud Agentを使いたい場面
現在はローカル実装が中心ですが、Cloud Agentを使わなくなったわけではありません。次のような仕事では、今後も有効だと考えています。
- 対象ファイルと完了条件が明確で、他の作業と衝突しにくい
- 長めのテストや調査を非同期で進めたい
- PCを閉じている間もGitHub上で作業を続けたい
- Draft PRというレビュー可能な成果物で受け取りたい
逆に、直前のローカル検証結果へ強く依存する作業、複数レイヤーをまたぐ障害対応、同じファイルへ変更が集中する作業は、ローカルCopilotと連続して進める方が扱いやすいです。
重要なのは、Agent ModeとCloud Agentのどちらが優れているかではなく、作業の独立性、待ち時間、統合コストに合わせて選ぶことだと思います。
まとめ
Memologを作る中で、自分とGitHub Copilotの分担は少しずつ変わりました。
- 最初はAgent Modeで、構想、設計、実装を一続きにした
- 次にIssueをCloud Agentへ渡し、非同期実装とローカルレビューを組み合わせた
- 重複PRや環境制約との不一致から、Issueの切り方と品質ゲートの重要性を学んだ
- 現在はIssue-firstで記録を残しながら、文脈を持つローカルCopilotで実装・検証することが多い
Copilotは、コードを書く速度だけを上げたわけではありません。調査、設計、実装、テスト、本番確認、記録を往復する速度を上げてくれました。
ただし、何を作るか、何を信じるか、どのリスクを受け入れるか、いつ本番へ出すかは、今も自分の仕事です。この境界を意識することが、Copilotを単なるコード生成ではなく、開発のパートナーとして使う上で一番大事だと感じています。