GitHub Copilot Pro の月300回 で何ができるか 2025
有料プランを契約していたのに使えてなかった GitHub Colpilot Pro ($10/月) の 300回のリクエストでどこまでできるか体験してみました。現時点で合計 298.25回。途中で倍率が違うモデルを1回選択しましたが素人には違いがよくわからず。 Claude Sonnet 4 しか使ってないです。
現在のリクエスト量概算は VS Code から。

日々のリクエスト数は以下の画面で確認できます。

全貌はこちら。
| date | product | sku | quantity | model |
|---|---|---|---|---|
| 2025/8/2 | copilot | copilot_premium_request | 2 | Claude Sonnet 4 |
| 2025/8/3 | copilot | copilot_premium_request | 32 | Claude Sonnet 4 |
| 2025/8/5 | copilot | copilot_premium_request | 14 | Claude Sonnet 4 |
| 2025/8/8 | copilot | copilot_premium_request | 3 | Claude Sonnet 4 |
| 2025/8/9 | copilot | copilot_premium_request | 77 | Claude Sonnet 4 |
| 2025/8/10 | copilot | copilot_premium_request | 42 | Claude Sonnet 4 |
| 2025/8/11 | copilot | copilot_premium_request | 127 | Claude Sonnet 4 |
| 2025/8/11 | copilot | copilot_premium_request | 1.25 | Claude Sonnet 3.7 Thinking |
作品1: mock-exporter
対話的指示のみで作成。
Grafana の Alert rules を使ってみたくて、テストデータを作成するために作ったものです。Djangoの使用はこちらから指定しました。「Prometheusが読み取る /metrics の API と、メトリクスの値をスライダで変更する UI を Django で作って」程度の指示から始めたと思います。指示するほうは「値をスライダで変更する」が input type="range" で済んでるのに驚いたくらいの Web素人です。
最初はメトリクスが固定でした。メトリクスの数を増減させたり名前を指定できるようにしたりしてると、メトリクス名を編集中にも更新がかかり、さらに古いのを消さないので編集途中の文字列が全部メトリクスになりました。指示が近視眼的なのは良くないのでしょう。
複数のブラウザでアクセスするとおかしなことになるので、「WebSocketを使用して複数のブラウザ間で状態をリアルタイムに同期して」の指示を後から出したのに、動くものを作ったのにも驚く。これは楽しい。
作品2: pdf-preview-go
別プログラミング言語からの変換。
長らくほったらかしにしていたツール。作った自分でさえセットアップがめんどくさい。過去のリポジトリを読み込ませて「シングルバイナリで配布ができるように Go 言語で作り直して」が最初だったと思う。
最初に選択されたGUIが lxn/walk でしたが、チェックボックス付きの TreeView がうまく作れなかったので別のものに 途中から変更 して Wails になりました。こんな指示、人間相手だったら発狂してしまうな。結果的に、Wails で .exe 作成時のマニュフェストの準備が自動で、インストーラー作成の考慮もされているなど、いろいろ知ることができてよかったと思う。
少しずつ修正していくとソースコードの1ファイルがどんどん大きくなるので、適当なところであたりをつけて「これ分割できるんじゃないの?」と指示を出すときれいにしてくれる。が、大きい変更だとときどきファイルが壊れたり。
作っておいてなんですが、 Web素人なのでどうしてこれが動いているのか理解していません。そういえば Go言語も全然知らない。
GitHub の Actions も Copilot に作ってもらいました。
作品3: zipwithpwd
対話的指示のみで作成。
いまどきパスワード付きZIPとか言うだけでリテラシー低そうと思われるんじゃないかと思いつつ、固定パスワードがルールだった時に Go言語(どうやって作ったんだ) で実装し、パスワードが日時付きのルールになったときに Rust で書いてみようとか頑張ったものの、素人すぎて残すほどのソースコードにならなかったので一から作ってもらった。Wails でやっていたのと同じようにインストーラーも作ってもらいました。
作品4: CarryOutApproval
事前に仕様を書いたメモを用意して作成開始。
ここまで、その場の指示を重ねて適当に作ったアプリケーションの説明をまとめて markdown に書いてもらえることがわかったので、先に markdown でゴールを書いて作ってもらおうとしたもの。更新中。
どこかに配置する資料を、誰かに確認してもらってから配置する業務フローを想定しました。
やはり最初から完璧な仕様書を書くのは難しく、特に「申請を」とだけ指示すると、自分が出した申請なのか、自分が承認すべき申請なのかで混乱し、よくわからないものが出来上がってきた。この辺りは現実の仕様策定でもありそう。
また、良いものを選んでくれればと思ってふんわり書いたソフトウェアの構成が仇となり、AI が選んだ FastAPI と node.js / Ract は Web素人には手に負えなくて 途中から Djangoに変更 してもらいました。人間相手だったら発狂してしまう(二回目)。別に最初から作り直してもらってもよかったかもしれないな。
所感(2025-08-12)
Copilot Agent を使い始める記事はよくあるのですが読んだだけではわからず。やはり使ってみないとわからないことがあります。Agent が変更したファイルを覚えているのですが、切りのいいところで新しいセッションを開始してクリアしたほうが良さそうです。うっかり「今までの AI の変更を戻す」を選択する事故がありました。Gitの変更はともかく、表示されるエディタ上の変更と AI が覚えている変更とがどう絡み合っているのかいないのか理解できてないです。AI の理解(昔のことは忘れる)もそうですが、自分が制御できる状態をキープするのも大事。
VS code のターミナルで PowerShell を開くようにしているのに Agent の指示が cmd.exe 用だったり、Python の仮想環境を activate した後のコマンドが別のターミナルで実行されて仮想環境が効いてなかったり、かなり難儀しました。「仮想環境の管理に uv 使っててコマンドは Powershell 用。この指示をファイルに書いて覚えてください」と指示してもよく忘れます。これは VS code のほうで task.json や launch.json を用意しておくとそちらを考慮するようで、少し改善した気がします。タスク作成が面倒なら「このコマンドを task.json に登録して。.....」ができます。
Copilot Agent を使う効果に関して、一般的には「工数20%削減」で通るようですが Copilot Agent の返す結果の質がどんなものか、自分が指示できるプロンプトの質がいいのか悪いのか、ソースコードの規模と結果必要になる呼び出し回数の量とがどういったバランスになって料金がどうなるのか。ただでさえ定量化が難しいのに、使ってもいない状態で使ったことがない人に数値の積み上げで説明するのは無理。
教科書のサンプルコードは理解できるけど実際使えるアプリケーションを実装するにはどっちに進めばいいのかわからず、周りに聞く人もいない、という状況にある場合には金額以上の価値があるし、
前提知識が必要な単純作業を人間に頼むのを考えたら劇的に安い。途中でフレームワークを変えろとか。あとは画面デザインを適当に作ってくれるのが個人的にはすごく助かる。
先週の日曜と三連休の約4日間、朝から昼寝を挟んだりして夜まで使ってこのくらいなので、週末の趣味のプログラミングにはちょうどいい量かなと思ったのですが、300回超えたときにディスカウントがないんなら Free プランでもいいんじゃないのか?(つど課金のストレスに耐えられれば)という気もしてきました。ストレス軽減以外に利点はあるのでしょうか?
その後
300回を超えたらこうなりました。このまましばらく使ってみたらありがたみがわかるのかもしれません。

Discussion
追加課金もコスパ良いしコスパは最強レベルだと思う
API呼び出しで同じことやるとかなり金かかる
今後GPT5がスタンダードモデルになりそうだしclaudeがすごいの出してくるのに期待だね〜
いろいろ使ってみないとわからないだろう、と思い、枠を超えた分は課金して GPT-5 を選択して続けてみています。Agent で Claude Sonnet 4 を選択していた時にあった、いきなり検証コードを書き足してファイルが散らかったり、勝手にフォールバック関数を用意して余計な処理を足したり、絵文字入りの README.md を作って誇大広告的な言い回しを入れたりといった軽率な感じが少ない感じがします。
一方、説明が詳しくて画面をはみ出すくらい長くなりがちな気もします。読むのに時間がかかったりもしますが、その分リクエスト回数が減ってこちらの理解が深まるとおもうと、今の自分にはこっちのほうがいいのかも。作業の段階にもよるのかもしれませんね。