GitHub Copilot (Gen-AI) は役に立つが、万能薬ではない

過去 3 か月間、実際のASP.NET 8 開発で GitHub Copilot Pro を使用した感想を述べます。テクノロジは急速に進化しているため、これらの感想は 2025 年 3 月時点の私の経験に基づいていることをご了承ください。

1. 無料トライアルがきっかけでGitHub Copilot Proに加入することになった

これまで AI コード ジェネレーターについて読んだり、デモ ビデオをいくつか見たりしたことはありましたが、実際に本番環境で使用できるとは確信が持てませんでした。

3 か月前、理由もなく、 Visual Studio 2022の ASP.NET8 プロジェクトで GitHub Copilot Free アカウントが自動的にアクティブ化されたため、いわゆる「ゴースト テキスト」のコード候補が表示されるようになりました。私はショックを受けました。それは、私がこれから書き込もうとしている内容やコーディングしようとしている内容の見事な予測だったからです。

よく知らない人のために説明すると、 「ゴーストテキスト」とは、GitHub Copilot (GHC) の提案で、灰色の半透明のテキストでユーザーに表示されます。これは、AI がユーザーが次に何をすべきかを予測して、理由もなく表示されます。ユーザーは、提案されたコードが気に入った場合は、それを確定するか、無視して自分の作業を行います。

数日後、私はそのツールを試してみるために、 GitHub Copilot PRO の完全版サブスクリプションに加入することにしました。

2. GitHub Copilotの準備 - AIの利用

2.1 トレーニング

私は常にツールを真剣に受け止めているので、ツールを最大限に活用し、限界を認識できるように、事前にマニュアルを読みます。

私は GitHub Copilot で「プロンプト エンジニアリング」、「コンテキストとは何か」などのトピックに関するビデオを約 10 時間視聴しました。プロンプト コマンドとショートカット キーの独自の「チート シート」を作成しました。10 時間のトレーニングの後、 ASP.NET 8/C#/Bootstrap/EF8/JS 環境で実際のプロフェッショナル コーディングにそれを試す準備ができました。

2.2 プロンプトエンジニアリング全般

私の意見では、 「プロンプト エンジニアリング」は AI の敗北です。20 年前に私が聞いた AI システムの定義の 1 つは、人間が自然言語でコンピューター システムと対話できるようになったときに AI が実現されるというものでした。

GHC は AI システムだと彼らは言いますが、実際には「自然言語」で対話することはできません。実際には自然言語のサブ言語である「プロンプト エンジニアリング」を使用し、/、#、@ などの記号を使用する必要があります。私には、これは自然言語とプログラミング言語の混合のように見えます。彼らは、現在持っている AI システムを売りたいのですが、5 年後にはおそらく「今や本物の AI を手に入れたので、プロンプト エンジニアリングはもう必要ありません」と言うでしょう。

したがって、「プロンプト エンジニアリング」という表現は、AI システムと対話する唯一の方法がコマンド プロンプト経由だった時代に由来しています。当時は、コマンドを作成するための「芸術」または「科学」(私は「疑似科学」と呼びます) が、それらの AI システムをより良く機能させるのに役立ちました。私はそのような記事をいくつか読んだことがありますが、それらはすべて「常識」ですが、対象の AI システムは常に「ブラック ボックス」であるため、ある著者の推奨事項が別の人のルール リストよりも優れているかどうかを示す実際の指標はありません。また、システムは時間の経過とともに進化および変化するため、厳密に言えば、それらの著者は新しい世代のシステムに対して推奨事項を再度テストする必要があります。通常、著者はそうしませんが、AI を別の人間の知性として認識することに基づいた「常識」的な根拠を提供します。そして、人間にとっての「常識」は、AI システムにとって同じではない可能性があります。そのため、私は少し懐疑的で、さまざまな世代の AI システムに対する実際の測定基準やテストがないため、「プロンプト エンジニアリング」に関するすべての推奨事項を完全には信じていません。それらは、いくつかのコマンド実行からの「常識」と逸話的な証拠のみを提供します。

2.3. GitHub Copilot でのプロンプトエンジニアリング

したがって、GitHub Copilot (GHC) システムのコンテキストで「プロンプト エンジニアリング」について話す場合、これにはコマンド ライン インターフェイスだけでなく、Visual Studio GUI を介した対話も含まれます。これは基本的に「GitHub Copilot のユーザー インターフェイス」です。

GitHub Copilot を効率的に使用したい場合は、GitHub Copilot UI に慣れる必要があります。そこで、/fix、/optimize、#file1.cs、Alt+/ (GitHub Copilot の起動) などのコマンドをすべて学習しました。

2.4 会話の宇宙

何年も前に高校で哲学を学んでいたとき、あらゆる会話には「会話の宇宙」という概念が暗示されていると教わりました。会話の話題は通常、現在の「会話の宇宙」を指します。特定の話題や用語がその枠組みの中で想定または当然のことと見なされるため、会話の内容を理解するのに役立ちます。

2.5 AIの世界における「コンテキスト」とは何か

AI を研究するテクノロジー企業は、上記の哲学用語と似た意味を持つ「コンテキスト」という用語を生み出しました。テクノロジー企業は、自社の製品や株式を販売するために、世界がどうあるべきかという定義を押し付けたがるので、私は用語を分けておきたいと思います。また、テクノロジーが発展するにつれて、AI-Context-2025 の定義や AI-Context-2026 の新しい定義などが生まれるでしょう。そして、哲学用語は変わりません。

したがって、2025 年 3 月現在のコンテキスト定義 (AI-Context-2025 と呼ぶこともできます) は、AI システムが実行すべきことを理解するためにユーザーが AI システムに提供する必要のある追加情報になります。

2.6 GitHub Copilotにおける「コンテキスト」とは何か

GitHub Copilot のトレーニング ビデオでは、リクエストに適切な「コンテキスト」を提供することに重点が置かれています。私には、関連するコードを含むファイルを明示的に列挙するように求められているように見えます。「暗黙のコンテキスト」は Visual Studio プロジェクト/ソリューションであると想定しますが、少なくとも現時点ではそうではありません。

実際、GitHub Copilot VS2022 には小さな GUI チェックボックスがあり、これをクリックすると、現在開いているドキュメントをすべてのリクエストの「コンテキスト」に含めるかどうかを確認できます。(ちなみに、これは「プロンプトエンジニアリング」と呼ばれ、GUI チェックボックスをクリックすることになります...「GUI エンジニアリング」という名前の方が適切かもしれません 😉 )。また、# プレフィックスを使用して、#file1.cs のように関連ファイルを列挙するように求められます。

したがって、GitHub Copilot を効率的に使用したい場合は、使用方法に関する特定の手順と、推奨されるコマンド プロンプト/GUI インターフェイスがあります。それで、それでいいでしょう。私はすべての手順を学習/読み、AI が VS2022 プロジェクトに適したコードを生成するのを見たかったのです。

私が理解しているところによると、彼らはリクエストを非常に具体的にし、コードを含む関連ファイルをすべて列挙することを望んでいます。これは、特定の詳細さをもって他のプログラマーに指示を与えることに似ていると思います。開発者が学ぶ数多くのプログラミング言語に比べれば、難しいことではありません。

3. 1週間後の感想

GHC は単なるコード アシスタント ツールです。それほど「インテリジェント」でも「スマート」でもありませんが、繰り返しのタスクには適しており、入力時間を節約できます。コード内のパターンを何度も再適用するには適していますが、独自のソリューションを作成するのは非常に愚かです。

「チャット」するのは時間の無駄です。Google に行って自分で読んで、独自の問題を解決したほうが早いです。

しかし、何かを解決するための適切なパターンを一度作成すると、そのパターンを学習して自動的に再適用するため、入力の手間が省けます。

また、大量の「ゴミコード」が生成される傾向があるため、生成されたものを人間がフィルタリングする必要がありますが、「削除」ボタンを使用して「良いスニペット」だけを残すことは難しくありません。

たとえば、これまで見てきたことから、入力にかかる時間を 5% 節約できると期待しています。

4. 1.5ヶ月後の感想

GitHub-Copilot (Gen-AI) は役に立ちますが、素晴らしいものではありません。時々は役に立ちますが、ローカル スコープの問題にのみ有効で、全体像を把握することはできません。

素晴らしいときもありますが、間違いが多すぎたり、質問されると数ページにわたるテキストで回答したりして、時間の無駄になります。特に、冗長な回答はトピックから外れていることが多いためです。

深刻な問題の場合は役に立ちません。StackOverflow の記事を自分で読んで解決する方がよいでしょう。しかし、時には、繰り返しのタスクに優れ、非常に優れたコードを生成することもあります。

私の「個人的な感覚」は、 「よくわかっていない」 、 「推測しようとしている」ということであり、何百万行ものコードを記憶した巨大なメモリを持つマシンであるため、推測は時には素晴らしいこともあれば、時には的外れなこともあります。

5. 3ヶ月後の感想

GitHub Copilot (GHC) は、範囲が限定されたタスクに非常に役立つ Gen-AI ツールです。

• GHC は時々素晴らしいです。つまり、GHC は時々、あなたがこれからコーディングしようとしている内容を予測し、コードに受け入れるだけでよい「ゴースト テキスト」を提示するという点で素晴らしいのです。

  
  

• GHC は学習が速いです。GHCは、あなたのプログラミング スタイル (例外の処理方法とログ記録方法) を、周りの同僚よりも速く学習し、あなたのスタイルに従って、予測された「ゴースト テキスト」コードを提供します。私はそれがとても気に入っています。周りの人は皆、ログ記録などに独自のスタイルを持っている傾向があるからです。

  
  

• GHC は、独自のスタイルを危険にさらして追加します。GHCが危険なのは、自分がユーザーよりも賢いと考え、ユーザーが気付かないうちに独自の方法で少し変更するからです。データベースの取得で、例外が発生した場合、私は null を返していました。コーディング中に GHC がメソッドを終了するように「ゴースト テキスト」でプロンプトを表示したので、ちょっと見てから受け入れました。これによりバグが発生しました。例外中に null ではなく、空のオブジェクトが返され、他の場所でコードが壊れていました。教訓:提案されているコードを受け入れる前に、注意深く読んでください。

  
  

• GHC は「コードを生成」できますが、「コードを書き込む」ことはできません。説明するのは難しいですが、簡単に言えば、GHC は C# の構文をうまく理解できません。GHC は C# の素晴らしいスニペットを作成しますが、小さな構文エラーがあります。GHCから取得したコードに対して、別の構文チェックを行う必要があります。これは、私たちが機械/自動コード アシスタントから得ることに慣れているものではありません。

  
  

• GHC は C# 構文をうまく理解しません。まず、string と string? 型のような null 可能性で失敗します。コンパイラで確認し、自分で磨きをかける必要があります。難しくはありませんが、まさにその種の作業をマシン/自動コード アシスタントに委任することが期待されます。おそらく、C#-.NET-Framework スニペットと C#-.NET-Core コード スニペットが混在しているのではないかと推測するしかありません。

  
  

• GHC は C# 構文をうまく理解しません。VS2022コード プロジェクトにコード スニペットを挿入しますが、コード ブロックの開き/閉じ中括弧を混乱させます。自分で数えて必要なものを追加/削除する必要があります。時間の無駄になり、場合によってはかなり混乱を招きます。生成されたコードがすぐにコンパイルできる状態にならないのは残念です。

  
  

• GHC は C# のメソッド/プロパティをよく理解しません。見栄えの良いコードを提供し、私はそれを受け入れます。しかし、C# クラス オブジェクトにはそのメソッドがまったくありません。それは近いもので、その親オブジェクトにはそのメソッドがあるので、私は自分でそれを理解しました。OK、それは近いもので、私を正しい方向に導いてくれました。しかし、それは機械の役割です。私がコーディングで使用する .NET8 API であるおそらく 10,000 の C# クラスのメソッドをすべて覚えている人間はいません。機械がその手助けをしてくれることを期待します。しかし、いいえ、 GHC でさえどのメソッドがどのクラスにあるかはわかりません。自分で手動で確認するようにという小さな宿題が出されます。提供されるコードはコンパイルされませんが、「近い」ものです。GHCは C# クラスに何らかのメソッドがあると錯覚しているようですが、実際にはそうではありません。

  
  

• GHC は C# のメソッド/プロパティをよく理解しません。私は VS2022 プロジェクトで EF8 を使用しており、Customer クラスがあります。Customer DB テーブルへのアクセス メソッドをいくつか記述し始めたところ、GHC が「ゴースト テキスト」で GetCustomer メソッドの予測を提供してくれました。概念はしっかりしており、その DB テーブルには主キーがありますが、CustomerId という名前ではありません。GHCは、その名前のクラス プロパティが存在するはずだと単純に錯覚しているように見えますが、実際には存在しません。予測されたコードはコンパイルされず、クラス Customer で主キーの正確な名前を確認する必要があります。マシン/自動コード アシスタントのGHC が適切なプロパティ/メソッド名を独自に確認できないのは残念です。これは、VS2022 プロジェクトの単なる別のクラスです。したがって、コード スニペットは概念的には近いのですが、構文エラーを手動で修正する必要があります。そして、私はそのような状況を 100 回以上経験しました。

  
  

• GHC は C# のメソッド/プロパティをよく理解していません。GHCは浅く、数ページ以上のコードを認識しておらず、VS2022 プロジェクトの残りの部分がどのようになっているかを「推測」しようとしているという印象です。

  
  

• GHC チャットは時間を無駄にする傾向があります。推測で時間を無駄にします。生成されたコードの提案を 2 つ以上読む時間はありません。何か作業する必要があります。1、2 回間違った推測をした後、私は GHC を無視して自分でコードを書きます。私は「GHC とチャット」しようとしましたが、5、7 回チャットでやり取りした後でも、会話の最初と同じくらい愚かなままです。チケットを販売しているサイトで AI ではないチャットボットと話しているような感じです。テキストを常に繰り返し、 GHC はあなたが本当に必要としているものに焦点を合わせていません。インタラクティブ チャットでリクエストを「絞り込む」ために、そのアプローチを数回試しましたが、馬鹿と話しているような気がします。私はもうそんなことはしません。時間とエネルギーを尊重して節約しています。GHC を無視して、まっすぐにコーディングし、昔ながらの方法で結果を得ています。結論としては、 GHC に言いたいことを言うチャンスを 1 ～ 2 回与え、その後は時間を無駄にしないように無視して、手動でコーディングする、ということになります。

  
  

• GHC チャットは時間を無駄にする傾向があります。GHCは常に良い情報源であるとは限りません。素晴らしい情報源で、期待以上の情報やコード サンプルを提供してくれることもあります。しかし、不確実性があります。失敗することもあります。ごく一般的なトピックについて、自分のニーズに少しだけ特化したアドバイスを得ようとすると、終わりのないチャット セッションで時間を無駄にすることになります。Google で Stack Overflow の記事を自分で見つけたほうがよいでしょう。GHC はテキスト ジェネレーターで、質問に対する回答として膨大な量のテキストとコード サンプルを生成できます。提供されるコード サンプルの量に圧倒されました。質問に対して、読んで理解するのに 15 分ほどかかるテキストとコード サンプルを提供します。まるでタスクを割り当てているかのようです。これを読んでからまた話しましょう。そして、次から次へと答えが返ってきます。GHC は、HTTP の仕組みを指導するために、たとえば 1 つのヘッダーについて質問するなど、それを永遠に続けることができます。問題は、フォーカスがないため、私が尋ねたことではないことです。これらはすべて、話題から外れたゴミです。Google にアクセスして、いくつかのリンクをフィルタリング/開いて、問題の答えを見つける方が早いです。結論としては、 GHC に質問して 1 つか 2 つの回答を読んでから、Google にアクセスして時間を無駄にしないようにします。

  
  

• GHC はユーザーの指示に厳密に従いません。GHCはユーザーの指示に厳密に従わず、ユーザーよりも賢いと考え、指示に緩く従い、ユーザーにとってより良いと思われるものを提供します。そのため、アプリケーション全体で特定の方法/スタイルで HTML ASP.NET Razor フォームを作成したいのですが、GHC ではそうではなく、そのように指示しても、教科書のような HTML フォームが表示されます。これは他の状況でも発生しました。

  
  

• GHC フィードバック フォームは時間の無駄です。そこで、ソフトウェア会社は素晴らしいアイデアを思いつきました。製品の料金は請求しますが、同時に、ユーザーには製品テストに無料で参加するよう親切にお願いするのです。そのため、他の多くの製品と同様に、フィードバックを求めるダイアログがいくつかポップアップ表示されます。問題は、フォームに記入したとしても、誰かが書いた内容を読むかどうかです。多くの製品が、新機能について知らせるダイアログをポップアップ表示し、生成されたすべての結果に 5 つ星の評価を求めたり、コメントを書いたりしています。このようなダイアログは私の作業スペースを乱雑にするだけで、通常、私が受け取ったすべてのサービスを評価するいくつかの質問に答えるよりも、もっと真剣にやるべきことがあります。基本的に、彼らは大量のユーザーに各回答を評価してもらい、AI システムのトレーニングに協力してもらいたいのです。

  
  

• GHC は、小規模で限定された範囲のタスクに優れています。EFクラス内のすべての文字列を Trim() するメソッドが必要で、汎用的なソリューションを求めていました。Reflection が最適な方法であることはわかっていましたが、1 行のコマンド要求で、GHC は完璧な 30 行のメソッドを生成しました。これらは、人間が GHC に勝てる状況ではありません。適切な Reflection メソッドを見つけたり、いくつかの API を読んだりするには時間がかかります。この方法なら、20 秒で解決できました。しかし、 GHC は、そのようなシナリオでも、素晴らしい場合もあれば、役に立たない場合もあります。

  
  

• GHC は、少し複雑な JavaScript タスクでは失敗します。つまり、私は単純な問題を抱えていて、スコープが限定されていました。jQuery のロード時に「defer」属性を使用していたため、jQuery がロードされるまで待機する 10 行のメソッドが必要でした。GHC に最適なタスクのように見えました。しかし、私はショックを受けました。5回試行した後でも、GHC は何か他のことを行う JS コードを生成していました。GHC は私が求めていることを理解できませんでした。問題に関連しているように見えるが、実際には役に立たないスニペットを生成し続けているだけでした。JS に詳しいと「主張する」ジュニア プログラマーにタスクを与えると、インターネットで見つけたランダムなコード サンプルが提示され続けますが、誰もあなたが要求した単純なことを行っていません。その後、私は StackOverflow で自分でスニペットを見つけました。Google で 3 回クリックするだけで見つかりました。GHCは時々とても劣っています。

  
  

• GHC は、浅い C# コメントを生成します。私は、メソッドにコメントを追加するために GHC を使用していましたが、生成されたコメントは少し浅く、そのメソッドが達成しようとしていることの全体像が見えません。これは、行ごとのコメントよりも重要です。今では、これやあれを割り当てています。メソッドの英語名からメソッドの目的を推測することはできますが、それでもほとんどの場合、それほど印象的ではありません。

  
  

• GHC は C# のコメントをうまく理解しません。メソッドのコメントを作成するように求められた場合、GHC は実際のコード行を数行消すことができます。注意して、回答として提示された内容を注意深く読んでください。これは大変な作業で、メソッド全体を手動で読み直す必要があり、GHC を信頼できません。GHCは構文をうまく理解していないようで、コメントとそうでないものの両方をテキストとして認識します。これは私にも起こったことなので、その理由を注意深く調べました。いくつかのプロパティを設定していたのですが、上記のコメントでは、テストしてコメント アウトした古い設定でした。GHCによって、コードとコメントされた古いコードの両方が消去されました。コードの多くの場所でこのようなことが起きている可能性があります。そのため、コメントを追加するだけの単純な要求に対して、望ましくないコード操作が行われるリスクが高くなります。生成されたコメント付きコードはすべて手動で確認する必要があります。

  
  

• GHC の「コンテキスト」の話は宣伝どおりには機能しません。テクノロジー企業が AI-Gen 製品の失敗について開発者を非難する「責任転嫁」が行われているようです。単純に言えば、現在の Gen-AI ツールは、実際の状況では宣伝されているほど役に立ちません。しかし、現在の世代の AI ツールがいかに不完全であっても、それを販売し、今すぐに収益を上げるための「販売努力」が盛んです。そのため、失敗や制限については、責任転嫁はユーザーに向けられます。「ツールは素晴らしい、ただ使い方を知らないだけだ」。テクノロジー企業はこう言います。「AI ツールが失敗したのはユーザーのせいであり、現在の AI ツールに問題があるというのは真実ではない」。そのような責任転嫁の 1 つが、GHC の「コンテキスト」設定です。

  
  

• GHC の「コンテキスト」の話は宣伝どおりには機能しません。 「コンテキストを十分に指定していない」という話を読んだり聞いたりするのはうんざりです。これは言い訳にすぎません。なぜなら、私はすべてのアドバイスに従ったのに、GHC は依然として愚かで、コンパイルもされない役に立たないコード スニペットを生成して時間を無駄にしているからです。言うまでもなく、それらは話題から外れています。私は「プロンプト エンジニアリング」と「コンテキスト」について読んでいましたが、最善を尽くした後、 GHC は十分にスマートではなく、仕事をこなせないと思います。6か月待って、新しいツールを試してみましょう。現時点で GHC からより多くのものを絞り出そうとするのは時間の無駄です。したがって、真実は、現時点で (2025 年 3 月)、GHC は非常に愚かで、「コンテキスト情報が与えられても」中級レベルのタスクを解決するのに役立たないということです。

  
  

• GHC は単純な例外を解決できません。例外をスローするコードがあり、GHC を使用して解決したいと考えました。Visual Studio で例外の位置を特定し、/FIX で GHC を呼び出しました。「コードの欠陥をよりよく理解するために、さらにログに記録する」という推奨事項を含むテキストが生成されましたが、具体的な回答はありませんでした。これは簡単でした。例外のテキストを Google にコピーするだけで、3 番目のリンクが説明でした。言うまでもなく、EF9 が失敗する理由などについて、Google にさらに多くのテキストがありました。GHCは、通常のタスクではそれほど劣っている可能性があります。

  
  

• GHC は、プレーンな C# クラスからプロパティを列挙できません。LINQ を実行していて、互いに継承するクラスからいくつかのオブジェクトをコピーしました。一致するすべてのプロパティをコピーしたかったのです。プロパティは 25 個ほどありました。2、3 個のプロパティを割り当てて、GHC がパターンを選択して残りのコードを挿入してくれることを期待しました。いいえ、そうはなりませんでした。いくつかのプロパティが順序どおりに追加されず (これは問題で、どれが追加され、どれが追加されていないかを追跡できません)、次に、存在しないプロパティの名前がいくつか作成され (幻覚でしょうか)、スタックされました。コマンド プロンプトからコマンドを発行しようとしましたが、誤解され、C# クラス全体がその場所に挿入されるなどしました。大きな DTO が多数あるため、このようなコピーがタスクになることが多いため、さまざまな場所で何度か試していました。代わりに実行させることはできませんでした。飽きて、自分で手動でプロパティをコピーしました。一見愚かなツールに指示を与えるのにうんざりしていました。このような単純なタスクを GHC に委任できないのは不思議です。場合によっては、IntelliSense の方が GHC よりもはるかに賢く、便利です。

  
  

• GHC では、4 つの C# ファイルの小さなプロジェクトは実行できません。そのため、VS2022/C# プロジェクトで生成 AI を使用したいと思い、適切な機会を探していました。あることに気付きました。DB テーブルに対応する HTML テーブルをいくつか表示する HTML/Razor/ASP.NET8/Bootstrap ビューを作成しているのです。これは少し複雑で、ビュー内にパンくず UI や AJAX などがありました。そこで、Customers テーブル用に 1 つの MVC アクション/ビューを手動で作成し、Contracts にもまったく同じことをしたいと考えました。結局、別の DB テーブル (EF8 クラスに対応) と、新しいプロパティを持つ別の EF クラス名だけになりました。生成したい HTML テーブルは、Bootstrap スタイルで同じ外観になるはずでした。つまり、典型的な「 4 つのファイルでパターンに従う問題」です。 「コンテキスト」の重要性を強調するビデオをいくつか見てきました。そこで、別のテキスト エディターで、GitHub Copilot の正確な手順を書き始めました。私はタスクを説明し、テンプレートとして必要なファイルを指定し、ファイル名に # を付けました。MVC モデルがどこから来るのか、どのファイルなのかなどを説明しました。GHC 用に短い段落のタスクのスペルチェックも行いました。タスクの説明をわかりやすく準備するのに時間を費やしました。その後、それを GHC に提供しました。生成された最初のフォームは、私が明示的に指定したテンプレートに従っていませんでした。GHC は、私のアプリケーション用に Bootstrap でカスタマイズされたものではなく、教科書のような HTML フォームのようなものを生成しました。私は、新しいコード ファイルの生成を要求しました。2 番目は、既に作成したフォームに似ていましたが、15 個の DB テーブル プロパティのうち、4 個しか作成されませんでした。後で、 GHC は依存ファイルを読み取ることができず、ほとんどの場合、プロパティ名を推測しているのだとわかりました。異なる EF クラスで同じ命名規則に厳密に従っていたため、GHC の推測はうまくいき、正しく推測されました。不足している 10 個以上のプロパティを手動で追加して、ファイルを手動で完成させました。このような反復タスクは GHC に委任できると思われるかもしれませんが、GHC は単純な反復ジョブを実行することはできません。

  
  

• GHC は 4 つの C# ファイルの小さなプロジェクトを実行できません。明確なパターン プロトタイプ ファイルに基づいて VS2022/C# プロジェクトでいくつかのファイルを生成する同様の状況を再度試しました。結果はあまり良くありませんでしたが、それは宣伝どおりの状況であり、GHC が成功するように準備されていました。複雑なロジックではなく、明確な名前の置き換えが必要で、別の DB テーブルに対応する少し複雑な HTML テーブルだけです。しかし、GHC は 3 番目のファイルから EF8 プロパティを読み取って列挙し、同様の HTML テーブルを作成することはできないようです。また、C# プロパティについて幻覚を起こすことで、生成されたファイルに多くのエラーが導入されます。場合によっては、理由もなくファイル コードが変更されることさえあるため、生成されたファイルを 1 行ずつ手動でチェックする必要があります。また、GHC にコマンド ライン チャットして変更を要求すると時間がかかり、結果が保証されずエラーが含まれるため、最終的には効率的なソフトウェア開発方法ではありません。

  
  

• GHC は 4 つの C# ファイルの小さなプロジェクトを実行できません。振り返ってみると、私は「コンテキスト」仕様に関してこれ以上正確にすることはできませんでした。与えられた記述されたタスクと指定されたコンテキストは誰でも理解できるでしょう。私は、たとえ非常にテンプレート/パターン指向のタスクが与えられたとしても、 GHC は 4 つのファイルの小さな生成を処理できるほど賢くないと結論付けました。私はすべてを正しく行うために努力しているので、「適切なコンテキスト」の話はもう聞きたくありません。また、GHC に何度もファイルを生成させ、VS2022/C# プロジェクトで新しく生成されたコードをすべて再読み込みさせるのは時間と労力の無駄です。私はそれを試しましたが、GHC は要求するたびに別のファイルを生成でき、失敗した試みを調べるのにうんざりしていました。

  
  

• GHC では、4 つの C# ファイルの小さなプロジェクトは実行できません。今では、パターン ベースのタスクであるテンプレートに基づいて新しい HTML ビューを生成するという同様の状況になったときも、GHC に頼むことはありません。VS2022/C# プロジェクトでは、検索/置換機能を備えたテキスト エディターを使用するだけで、時間は変わらず、確実性も高まります。検索/置換を使用すると、何が得られるか正確に把握できます。GHC は文字列を変更しますが、独自にコードを変更することがあるため、元のテンプレート コードの 1 行か 2 行が変更されたか削除されたかはわかりませんでした。退屈な作業ですが、「スマートな」GHC がコードを「改善」しても、予期せぬ驚きはありません。

  
  

• GHC は、Bootstrap の愚かな間違いを犯します。Bootstrap のクラス名を思い出せなかったのですが、ボタンを左右に拡大したいと思いました。GHC に尋ねると、Bootstrap のクラス名が返されました。それを適用したところ、ボタンの上下が拡大されました。どうしてこのような間違いが起こるのか不思議です。Bootstrap の CSS クラスすべてについて正確に助けが必要でしたが、すべてを記憶することはできません。これはとても簡単な質問ですが、GHC ではできません。

6. GitHub CopilotのようなAIシステムを説明する方法

何か新しいものの典型的な適切な定義は、 2 つの部分で構成されます。1 ) それが類似するオブジェクト/概念、2) それが類似するオブジェクト/概念とどのように異なるかです。

したがって、インテリジェント システムについて話すとき、人々は通常、人間を基準値として扱います。彼らは、「AI-Gen システムはジュニア プログラマーのレベルですが、これやあれでは人間より優れている/劣っています」と言う傾向があります。

しかし、 GitHub Copilot (GHC) のような AI システムの場合、人間は良い基準ではないと感じています。人間は知的能力が徐々に向上し、最初は単純なタスクを解決する能力があり、その後、より複雑なタスクを解決する能力が身に付きます。

私は、トム・クルーズ主演の「レインマン」（1988年）のようなハリウッド映画以外、自閉症についてあまり知りません。しかし、GHCを人間に例えると、GHCは映画に出てくる自閉症のキャラクターのように見えます。GHCは聡明で複雑なパズルを素早く解くことができますが、非常に単純なタスクでも失敗することがあります。

GHC のような AI システムは独自のカテゴリに分類できます。そのスピードと巨大なメモリ、そして大量のテキスト/コードを高速に生成する能力は、人間とは比べものにならないほどです。これは、どんな人間よりも 100 万倍優れたメモリと数学的能力を持ちながら、単純な問題の前ではやはり愚か者である愚か者のようなものです。「論理的にコードを書く」のではなく、おそらくメモリ内の何百万行ものコードを検索し、あなたよりも速く問題の解決策を見つけるからといって、それを愚か者と呼ぶことができますか?

7. 体験後、GitHub Copilotをどのように使用していますか

7.1 GitHub Copilot は C# の間違いを多く犯す

コード支援生成に関して言えば、GHC はC# 構文を常に正しく理解できず、 C# プロパティ/メソッドの存在を独自に確認できないという点で非常に残念です。これは間違いなく、マシンに期待されるものではありません。論理的に推論することはまったくできないと私は感じています。そうでなければ、常に単純な構文ルールに従うことができ、余分な括弧で混乱を招いたり、存在しない C# クラス メソッドやプロパティについて幻覚を起こしたりすることはなかったでしょう。

大きなショックだったのは、GHC にコメントを追加するよう要求すると、類似のコード行がコメントアウトされていたため、アクティブなコード行が削除されたことです。GHCは「アクティブなコード行」が何であるかを完全には理解していません。そうでなければ、削除しないはずです。単に何らかのテキストを見て、「似たような」テキストを生成するだけのようです。宣伝されている「ペア プログラマー」や「ピア プログラマー」というよりは、大量のメモリとスピードを持つ子供がコードをいじっているような感じです。

7.2 GitHub Copilot を使用する場合

コーディング作業はやらなければならないし、 GHC をいじるのは楽しかったのですが、今は真剣に取り組むべき時です。時間は限られているので、エネルギーを生産的に集中させる必要があります。

• 私は GHC の「ゴースト テスト」をよく使用し、レビューして、気に入った提案があれば受け入れます。エネルギーを無駄にすることなく、VS2022/C# プロジェクトにテキストがポップアップ表示されるので、便利な場合もあれば、AI が今何をすべきか考えているかを知るのが面白い場合もあります。AI の提案を読むのも少し楽しいです。

  
  

• VS2022/C# プロジェクトの 1 つのファイルでコードの一部を選択し、変更やコメントを依頼します。GHC はこのようなタスクをうまく理解できます。限られた行数 (おそらく 50 行) に焦点を当てて、提案を依頼します。GHC の提案は役立つこともありますが、多くの場合、私が何を求めているのかを理解できなかったり、間違った回答が生成されたりします。必要な Bootstrap CSS クラスが何かといった簡単な質問について、チャット プロンプトを 3 ～ 4 回繰り返した後でも、提案が失われることがあります。しかし、私はすべてを制御できており、時間の無駄にはなりません。答えがよくわからない場合は、Google で解決策を探します。

  
  

• 私は GHC のテキスト プロンプト ページを使用して、明確な機能を持つスニペットまたは小さな関数の生成を依頼します。GHC はこのようなタスクに最適です。ここでは、GHC が本当に素晴らしい働きをすることもあれば、間違った答えのコード スニペットを提供することもあります。GHCがここで成功する保証はありませんが、成功した場合は素晴らしい働きをする可能性があります。

  
  

• 3～4 個のファイルを同時に含む大きな変更は、GHC とチャットして行うのは面倒で労力がかかるため、もう試していません。さらに悪いことに、GHC が他に何を変更するかわからないため、各 GHC 介入後に生成されたコードを再度読み込む必要があります。このようなタスクに GHC を使用するのは時間の無駄です。回答はせいぜい不完全で、C# のプロパティやメソッドが存在しない (幻覚でしょうか?) など、多くのエラーがあります。指定されたパターンに厳密に従わないため、VS2022/C# プロジェクトで生成されたコードを注意深く読む必要があります。コード行を削除したり、独自のコードを追加したりする可能性があるためです。この特定のケースでは、これは間違っています。また、 GHC が提供する各回答をレビューするには時間とエネルギーがかかります。GHC は、サンプル コードの新しい反復を永遠に生成できるマシンです。私もただの人間なので、GHC が 2 秒で生成する C#/Razor/CSS/JS を組み合わせた 300 行を確認するには、おそらく 10 分ほど集中する必要があるでしょう。そして、回答を再生成するように依頼すると、つまり新しい解決策を提案してもらうと、最初からすべてをもう一度確認する必要があります。

  
  

• HTTP コンテキストなどに関連する、よく知られた頻繁に使用される API に存在しない C# プロパティとメソッドについて、なぜ幻覚を起こすのかと考えていました。おそらく、.NET4.8 フレームワークからスニペットをコピーしたもので、そのメソッドは .NET Core にはもう存在しないのでしょう... ただし、EF8 クラスなど、VS2022 プロジェクトの一部である C# クラスについては、読み取らずに推測するだけであり、CustomerId という名前の主キーが存在するはずですが、実際には別の名前で呼び出されるため、EF8 クラスを手動で開いて、プロパティの適切な名前をコピーして貼り付ける必要があります。

  
  

• 私は「適切なコンテキスト」の話は信じていませんが、 GHC ツールは本格的な作業を行うには賢くなく、GHC と延々とチャットするよりも、直接コードを書く方が速いと単純に信じています。

  
  

• その「適切なコンテキスト」の話は、AI ツールを製造している企業が、開発者が AI 製品を適切に使用できないことを責めようとする責任転嫁です。そこで、私は「プロンプト エンジニアリング」について十分に学び、VS2022/C# プロジェクトで GHC を利用してコードを生成するよう真剣に取り組んでいましたが、失敗しました。GHC に適したタスクに使用して、作成したパターン (HTML テーブルなど) に従って類似のコードを生成することも計画していましたが、GHC では不十分でした。全体として、 4 つのファイルを含む割り当てられたパターン ベースのタスクでは、有用なコードよりも混乱が生じます。

  
  

• UI パターン ファイルを処理する古い方法に戻りました。たとえば、非常によく似た「ListOfCustomers」UI フォームに基づいて「ListOfContracts」HTML (かなり高度な AJAX フォーム) を作成します。ファイルをコピーして名前を変更します。次に、テキスト エディターの検索と置換を使用して、VS2022/C# プロジェクトでフォームを変更します。速度は遅いですが、進行中であることは確実であり、コード行が欠落したり、予期しないコード行が追加されたりするような厄介な驚きはありません。このようなパターンを探すタスクには GHC を使用することを考えていましたが、手動で直接コーディングする方が時間効率とエネルギー効率が優れています。

  
  

• 私は GHC に問題の解決を依頼しますが、チャットの返信は最大 2 つしか読みません。GHCの回答は冗長になる傾向があり、GHC がそれを知っている場合は 2 回の試行で回答が得られるため、これは素晴らしいこともあります。2 回の試行で適切な回答が得られない場合は、同じ問題について Google で調べます。GHC は大量のテキストとコード サンプルを生成し、優れた点について指導してくれますが、解決すべき特定の問題があり、延々とチャットしている時間はありません。GHCには深刻な焦点の問題があり、回答は頻繁にトピックから外れます。

8. AI製品のマーケティングは非常に強力

テクノロジー企業による AI 製品のマーケティングは非常に強力なので、現時点でのAI 製品の能力について常に最新の情報を把握するよう努力する必要があります。

• マーケティングは強力です。テクノロジー企業はマーケティングに資金を投入しており、今すぐに売上と収益を上げたいからです。実際の AI 製品が「生産準備完了」でなくても、 「ビジョン ストーリー」で販売したいのです。お金を集めるためだけに、マーケティングは必要なストーリーを何でも作ります。売れる良いストーリーは、技術的な現実を正確に反映している必要はありません。

  
  

• 彼らは「ペアプログラミング」について話していますが、これは、一人で作業するのではなく、「ペア」で、あなたと GHC のような AI 担当者の 2 人で作業することを意味します。将来的にはそうなるかもしれませんが、2025 年 3 月の時点では、GHC は単なる別のコード支援ツールであると私は考えています。

  
  

• 彼らは「ピアプログラミング」について話している。つまり、AI 担当者があなたのタスクであなたと同等になるということだ。2025 年 3 月現在、GHC は C# 構文で依然として大きな問題を抱えており、一部の .NET Core API C# クラスが正確にどのように見えるかについては、少し幻覚を起こしている。そこにある VS2022 プロジェクトのファイルを読み取ることはできないが、その代わりに、 GHC は構文をチェックして作業を完了するタスクを人間に与えている。しかし、本来は逆であるべきであり、人間はそのような退屈なタスクを AI ツールに委任すべきである。

  
  

• 開発者に自信を持たせるために、 「操縦と航空機」や「副操縦士の存在」に関する想像力豊かなマーケティングストーリーが作られています。結局のところ、あなたはキーボードとモニターの前にいる一人の人間であり、世界を旅する豪華な飛行機に乗っているわけではありません。そして、あなたが持っている GHC の「AI 相棒」(2025 年 3 月現在) は、私には少し自閉症のように見え、よくしゃべり、時には素晴らしく、時には愚かで、知っているように聞こえるかもしれませんが、間違っている可能性があるため、彼の行動や発言はすべて確認したほうがよいでしょう。

  
  

• 多くのAI コード ジェネレーターは、少しアレンジされた非現実的なシナリオで公開デモされています。デモは、「階乗」や「フィボナッチ数」などの 50 行の小さな関数の生成に限定されています。これらはプログラミングの教科書でよく知られているタスクです。AI システムは数学に優れており、コード スニペットの膨大なメモリからコード サンプルを引き出すことさえあります。このようなデモでは、実際の 300 を超えるコード ファイルを持つソフトウェア開発プロジェクトに直面したときに、そのようなシステムがどのように機能するかは示されません。

9. 結論

GitHub Copilot (GHC) (2025 年 3 月現在) は便利なツールなので、プログラミングで引き続き使用していきます。コード スニペットや提案を提供してくれるので、かなりの時間を節約できます。

現在の技術レベルでは、 GitHub Copilot (GHC) は、複数のファイルを同時に扱う複雑なタスクを信頼できません。このようなシナリオでは、直接の手動プログラミングに比べて結果が不完全で、時間効率も良くありません。

深刻な問題として、GitHub Copilot (GHC) は存在しない C# メソッドやプロパティについて誤解する傾向があります。GHCによって生成されたコードはすぐにはコンパイルされないため、完成させるには多くの手作業が必要になります。

状況は急速に進化しているため、上記のメモはすでにほとんど古くなっています。どうやら、GPT-4o と呼ばれる新しいツールが数日前にリリースされたようです。AI テクノロジー企業は、ユーザーに明確な通知をすることなく、バックグラウンドでこれらのツールを静かにアップグレードし、ツールをどんどん改善しているようです。

一部のメディアの報道によると、大規模言語モデル (LLM) は限界に達しており、純粋なスケーリングでは改善されていないとのことです。AI ツールの真の進歩が見られるようになるには、AI 科学の理論的な進歩を待つ必要があるかもしれません。

2025 年 3 月の GitHub Copilot のバージョンは便利ですが、宣伝されているほど優れているわけではありません。時間の経過とともに改善されることが期待できます。ただし、実際に確認/検証する必要があります。

最後に、もちろん、上記の記事で述べられたことすべてについて、セカンドオピニオンを求めてください。