GitHub Copilot WorkspaceのTechnical PreviewがGitHub有償ユーザ向けに公開されました。GitHub Copilotを有償で利用している方は、すぐに使える状況になっていると思います。

僕も少しだけ使ってみたのですが、今後の開発プロセスを大きく変えていくだろうなという感触を持ったので、ではその「変わった先」というのがどういうものになると思っているのかを書いてみます。

GitHub Copilot Workspaceとは

GitHub Copilot Workspaceを一言で言うと、AIを活用したコーディング支援ツールと言えるでしょう。それってGitHub Copilotと何が違うの？と言う疑問が湧きますが、GitHub Copilotが個々の細かなタスクベースでコード生成を支援するのに対し、GitHub Copilot Workspaceはプロジェクト全体を俯瞰し、計画化の段階からコード生成を支援するという違いがあるといえます。

GitHub Copilot Workspaceは、コードベースやIssueの返信などに対する深い理解に基づき、Issueを解決するためのステップバイステップの計画を提供します。計画を検証し、コードをテストするために必要なすべてを、1つの合理化されたリストで自然言語で提供します。

例えば僕は、「VS Codeの最新３バージョンに合わせてテストを実行し正常性を確認するGitHub Actionsを作成して」と言うタスクをGitHub Copilot Workspaceに伝えました。 GitHub Copilot Workspaceは、このタスクに対して、以下のような計画を提案してくれました。

この計画は、エンジニアがレビューすることができ、修正・追加が可能です。そして計画化が完了すると、GitHub Copilot Workspaceがその計画に沿ってコードを修正し、Pull Requestまで作ってくれます。

GitHub Copilotは、渡せるコンテキストをある程度人が指定する、あるいは、認識しコントロールする必要がありました。

Copilot に役立つコンテキストを次のように指定します。

IDE で Copilot を使用している場合は、関連するファイルを開き、無関係なファイルを閉じます。

Copilot Chat では、特定の要求が有用なコンテキストでなくなった場合は、その要求を会話から削除します。または、特定の会話のどのコンテキストも役に立たない場合は、新しい会話を開始します。

Copilot Chat in GitHub を使用している場合は、特定のリポジトリ、ファイル、シンボルなどをコンテキストとして指定します。「GitHub で GitHub Copilot に質問をする」を参照してください。

IDE で Copilot Chat を使用している場合は、キーワードを使用して、Copilot を特定のタスクまたはコンテキストにフォーカスします。「IDE で GitHub Copilot に質問する」を参照してください。

GitHub Copilot の使用についてのベストプラクティス - GitHub Docs

これに対して、GitHub Copilot Workspaceは、プロジェクト全体を俯瞰し、自ら必要なコンテキストを抽出してくれる感触です（もちろん、人間が指定してあげると精度はよくなるようです）。

GitHub Copilot Workspaceの苦手なところ

まず当然ですが、ある程度の粒度の指示を伝えなければ、GitHub Copilot Workspaceの計画精度は著しく落ちます。これはプロンプトエンジニアリングの世界そのものといえます。

さらに、コンテキストすら与えられないプロジェクト初期フェーズにおいては、なかなか対応が難しいようです。

僕たちのプロセスをどう変えるのか

プロジェクトが一定の規模に達した後の個々の機能実装は、GitHub Copilot Workspaceやその他のAgenticな生成AIプロダクトによって、かなり効率化されるようになると考えています。この分野では各社がさまざまな取り組みを進めていますが、GitHubのような資本力と高度な人材を投入しない限り、期待する成果を得るのは難しい印象です。

僕としては、このような背景を踏まえ、GitHub Copilot Workspaceのような生成AIを軸に据え、それらを活用できる環境を整備する方向に舵を切ることがより価値のある取り組みになると感じています。

課題はプロンプト生成

実装作業をGitHub Copilot Workspaceに任せるとしても、その前段階で重要になるのが「プロンプト生成」です。このプロンプトには設計内容が含まれることになり、設計をどのように生成するかが大きな課題となります。

設計のインプットとしては、次のような要素が挙げられます：

要件や要求：プロダクトが達成すべきゴールや仕様。
アーキテクチャ設計・標準ドキュメント：大規模なシステムで特に重要となる、コード規約や設計基準。

これらを基に設計を生成するアプローチが求められます。特に、要件やアーキテクチャ設計はビジネスドメインごとに大きく異なるため、これが可能か否かが競合優位性を決定づけるポイントにな理想です。

設計仕様とテスト工程の連携

設計仕様が正しいかどうかを確認するのがテスト工程の役割です。そのため、生成された設計文書はテスト仕様のインプットとしても活用できねばなりません。ここでもGitHub Copilot Workspaceのような生成AIが活躍し、設計内容はテスト工程で利用するAgenticな生成AIに対応した形式で作成する必要が出てきます。

では開発フローは？

これらを踏まえると、プロジェクトのフレームワーク構築後の開発フローは次のような形になるでしょう：

設計文書の生成
- 人間と生成AIが協働し、機能ごとに詳細な設計文書を作成。
コードの生成
- 設計文書を基に、GitHub Copilot Workspaceのような生成AIを活用してコードを自動生成。
テスト仕様の生成
- 設計文書と生成されたコードを基に、人間と生成AIが協働してテスト仕様を作成。
テストコードの生成
- テスト仕様とコードをもとに、生成AIが自動でテストコードを作成。

設計との向き合い方

要するに、「要件定義・要求定義」と「設計」がますます重要になりそうです。特に、GitHub Copilot WorkspaceのようなAgenticな実装ツールが主流になると、プロジェクトのタイムラインにおいて、最初に求められるのは設計への適切なアプローチとなります。

これはなぜかというと、「質の悪いプロンプトからは質の悪い生成物しか生まれない」のと同様に、「質の悪い設計からは質の悪い実装しか生まれない」からです。この点は生成AIが登場する以前から変わらない原則ですが、生成AIにより設計から実装へのプロセスがどんどんシステム化されることで、この課題がより顕著になってくると考えられます。

言い換えれば、生成AIが高度化するほど、「設計の質」がプロジェクト全体の成功を左右する決定的な要因となってきそう。設計大事。