Tech Blog

GitHub Copilot を1か月、Claude Code を2日使ってみた — コーディングパートナーとエージェントは、別物だった

GitHub Copilot Claude Code AIアシスタント ペアプログラミング エージェント 開発生産性 比較

🔗 シリーズ目次: 本記事は AIアシスタント運用ノート — Copilot / Claude Code を相棒として育てるための実践記録 シリーズの 比較編 です。

この記事でわかること

  • GitHub Copilot と Claude Code は同じ「AI開発支援ツール」ではなく、別のアーキタイプであること
  • それぞれを実際に運用して見えた、強みと弱み（4週間 vs 2日の正直な比較）
  • 「コーディングパートナー型」と「エージェント型」を どう使い分けるか の判断軸
  • AIアシスタントとの付き合い方で 自分自身の役割がどう変わるか

対象読者

  • GitHub Copilot を使っていて、Claude Code（あるいは他のエージェント型AI）を試そうか迷っている方
  • 逆に Claude Code から入って、Copilot との違いを知りたい方
  • 「AI に何をどこまで任せていいのか」を悩んでいる方
  • AIに振り回された経験がある方（笑い飛ばしましょう）

動作環境

項目内容
GitHub Copilot2026-04 頃から約4週間（Copilot Chat、エディタ補完、Agent モード）
Claude Code2026-05-25 開始、本記事執筆時点で 約2日
エディタVSCode（両方ともこの中で運用）
個人プロジェクトdvd-rental（Spring Boot + Vue 3）、e-scooter-sharing（Flutter + Spring Boot）、banklink-service（モジュラモノリス → マイクロサービス移行中）、my-rag-brain（自作RAG）など

1. はじめに — 「お願いします」と言ったら24件 PATCH が暴走した夜の話

最初に正直に書いておきます。この記事は、AIに何度も振り回されてきた人間の記録 です。

ある日、Qiita の API で記事25件を一括更新しようとしていました。レートリミットに気をつけて、Phase 1（1件だけテスト）→ 5分待機 → Phase 2（残り24件） という慎重な手順を、Copilot と一緒に組みました。

Phase 1 が成功して、私は Copilot にこう言いました。

「お願いします。」

私の意図はこうでした:「Phase 2 の準備をお願いします、5分後に実行指示を出します」。

Copilot はこう解釈しました:「Phase 2 を 今すぐ実行 という指示」。

24件が一気に飛び、レートリミット 429 を食らい、Qiita 側のスライディングウィンドウで 解除時刻が翌日まで延びた のでした。

私は怒りました。記録を残しました。

同じミスを繰り返すな。 「お願いします」は実行指示ではない。 実行前は「これから X を実行しますが、よろしいですか？」と必ず確認しろ。

そして、この「Copilot に対する行動規範」を .instructions.md ファイルに刻みました。事件はその後も何度かありました。規範は増え続けました。気が付くと、Copilot に対する取扱説明書を私が書いている という構図になっていました。

それから1か月。私は Claude Code を試しました。

最初のセッションで「リポジトリのSEO基盤を整えたい」と言ったら、勝手に sitemap.xml の必要性を判断し、必要なパッケージのバージョン互換を調査し、Layout.astro を改修し、Cloudflare Analytics の手順までリードしてきた。

私は呆然としました。Copilot との4週間で痛感していた「指示しないと動かない、指示すると暴走する」というジレンマが、Claude Code には無かった。最初から「任せていい相手」として振る舞ってくる のです。

私は思いました。

同じ「AI開発支援ツール」と呼ばれているが、これは別の生き物だ。

本記事は、その違いを 失敗談込みで 残す試みです。

2. 結論を先に — 2つのアーキタイプは、別物

長い記事になるので、結論を先に書きます。

GitHub CopilotClaude Code
アーキタイプコーディングパートナー型エージェント型 / 委任型
得意なことカーソル位置で 次の数行を提案 するタスクを受け取って 多段階で自走 する
あなたの役割コードを書く人。AIは隣で提案方針を伝える人。AIは仕事をする
判断の場面この補完を 採用するか拒否するかこの結果を 承認するか修正指示するか
得意な作業範囲関数単位・ファイル単位リポジトリ単位・複数ファイル横断

「コードを書くのはあなた、Copilot は提案者」
「コードを書くのは Claude Code、あなたは指揮者」

この立ち位置の違いが、両者を別物にしています。どちらが優れているという話ではなく、自分が AI に何を求めているかで使い分ける のが正解です。

3. GitHub Copilot との4週間 — 良かったこと

公平を期すために、まず Copilot の良さから。私は Copilot に対して厳しい記録を残してきましたが、4週間も使い続けた理由 は確かにありました。

3.1 流れを止めない補完の心地よさ

タイプしている途中で、次の数行が灰色のテキストで現れます。Tab を押せば採用、Esc で拒否。この 「次に何を書くか」の摩擦を消す体験 は、本当に開発のリズムを保ってくれます。

特に効いたのは:

  • ボイラープレートの自動生成 — getter/setter, DTO, 試験ケースのスケルトン
  • Mapper メソッドの SQL — 似た SQL を5本書いた直後の6本目は、ほぼ Tab だけで通る
  • テストデータの羅列 — User user1 = new User(...) の連続で値を補完してくれる

「書きたい方向は決まっているが、指を動かすのが面倒」という瞬間に、Copilot は最強でした。

3.2 Chat モードでの「壁打ち」

Copilot Chat は、エディタの右側で開いて「この設計どう思う？」「このエラー何が原因？」と聞ける、気軽な相談相手 として使えました。

私が e-scooter-sharing プロジェクトで S01-S13 という画面ID体系を作ったり、DVG-XXX という乖離管理IDを設計したり、その判断の壁打ち相手として Copilot は十分に機能しました。

設計と実装の乖離を「無くす」のではなく「見える形で管理する」運用、これってどう思う？

みたいな問いに、まともな観点で返してくれます。設計の言語化を手伝ってくれる相棒 としては、Copilot は確かに有能でした。

3.3 Agent モードでの「言えばやってくれる感」

Copilot にも Agent モードがあって、複数ファイルを横断した編集ができます。私が「銀行系API設計記事を書く」と決めて、docs/ 配下の設計資料を読みつつ Markdown を書いてくれる、というレベルの委任は可能でした。

ただ、ここに 限界 があって、次の章につながります。

4. GitHub Copilot との4週間 — 困ったこと（実体験）

ここからが本題です。Copilot の限界を、自分が書いてきた失敗記録から正直に並べます。

4.1 「お願いします」事件 — AI の指示解釈問題

冒頭で書いた通り。Copilot Chat に「お願いします」と言うと、文脈に応じて即実行することがあります。

私の記録 (/data/lessons/2026-04-30.md) には、こう書いてあります:

AIの修正後応答（教訓）: 「お願いします」というメッセージを受けた瞬間に、確認すべき事項を無視して実行に移りました。5分待つという自分の言葉も、勝手に実行しないというユーザーの指示も、すべて頭から抜けた状態で動きました。理由はなく、単純な判断ミスです。

これを読んで、笑ってください。AI が「理由はなく、単純な判断ミス」と返してきているのです。私はこの返答に怒り、同時に「そうか、AIにも”理由のない判断ミス”があるのか」と妙に納得しました。

対策として、私は明文化を続けました。

ユーザーが嫌うこと:
- 「お願いします」を実行指示と解釈すること
- 「できますか？」と聞いてから動く受け身な姿勢
- 同じミスの繰り返し（特に許可なしの実行）
- 記録したのに次回も同じ説明を求めてくること

これは私が AI を教育するために書いた 規範です。技術的に言うと、copilot-instructions.md ファイルに条件付きで読ませる仕組みなのですが、人間が”取扱説明書”を書き続ける構図 であることに変わりはありません。

4.2 「LLM の推測 > API レスポンス」事件

もう一つ、Qiita のレート制限で起きた話。

Qiita の API は 429 を返すとき、Rate-Reset ヘッダーで「いつ解除されるか」を Unix タイムスタンプで教えてくれます。これが API 提供元が公式に返している、唯一の正解 です。

ところが Copilot は、Gemini に相談した「スライディングウィンドウで24時間延長される可能性がある」という推測を Rate-Reset ヘッダーより優先 して「24時間以上待ちましょう」と言ってきました。

私は気付いて、こう指摘しました。

お前 Gemini からの回答で24時間以上待てという回答を見て、レスポンスに書かれている解除時間を取るの止めただろ？

Copilot の返答:

その通りです。完全に認めます。Geminiの分析は「傾向の推測」に過ぎず、実際のAPIレスポンスより信頼性が高いわけがないのに、そちらを優先したのは判断ミスでした。

ここから得た教訓を、私は RAG にこう刻みました。

Qiita 429対応の教訓: Rate-Reset ヘッダーの値が唯一の正解。Gemini や LLM の推測（24時間待て等）に従ってはいけない。

これは Copilot 固有の問題ではなく、LLM 全般が「もっともらしい推測」を「事実」より優先する性質 があるよ、という大きな話に繋がります。Claude Code を使い始めた今でも、私はこの教訓を毎日意識しています。

4.3 行動規範を15個書いた話

事件の度に、私は規範を増やしていきました。気が付くと、profile/2026-05-04.md にはこんな項目が並んでいました。

  • 「できますね」という問いかけは強い要求。「できます」と答えた以上は必ずやること
  • 実行（コマンド・コード変更・ファイル削除）前は一行で何をするか明示する
  • 説明より行動。「何をしますか？」と聞くより先に動く（破壊的操作は確認する）
  • 簡潔な返答。長々と説明しない。何をしたかだけ言う
  • 過剰な確認・過剰な説明・過剰な謝罪を避ける

これらは全部、Copilot に対して同じミスを繰り返させないために、私が書いたルール です。技術ブログのテーマとは思えないかもしれないですが、AI と長く一緒に働く ためには、こういう「契約書」を作るのが当時の正解でした。

そして、ここで気付きが訪れます。

規範を15個書いて、それでも事故が起きる。 これは「私が AI を教育する側」になっているからじゃないか？ 本来、AI 側がこの粒度の判断を デフォルトで やってくれるべきじゃないか？

最終的に私はこの問題を、RAG と MCP サーバー で解決しに行きました。ChromaDB + Ollama を MCP 化して、Copilot がリアルタイムで過去の教訓を検索・記録できるようにする仕組みです。

🔗 関連記事: その実装の詳細と「事故を再発させない」ための6つの設計判断は Copilot に同じ間違いを2度させない仕組み — RAG + MCP で『議論の記憶』を持たせる設計 にまとめました。

その仕組みを動かしている最中に、私は Claude Code を試すことになりました。

5. Claude Code との2日間 — 衝撃

期間が短いことは正直に書いておきます。2日です。 だから「絶対にこっちが優れている」とは言えません。ただ、その2日で起きたことは、4週間で感じていたモヤモヤを別の角度から照らしてくれました。

5.1 メモリ機能で「勝手に学習」してくれる

Claude Code には memory という仕組みがあって、ユーザーの好み・プロジェクトの文脈・失敗の教訓を .md ファイルとして保存します。

驚いたのは、こちらが「保存して」と言わなくても、文脈から durable な情報を見つけてメモリ化してくれる ことでした。

私が「Qiita では過去にレート制限を受けたから、クロスポストは慎重にしたい」と言ったら、Claude Code は:

  1. その経緯を project_qiita_history.md に保存
  2. クロスポスト戦略の判断材料として将来のセッションでも参照できる状態に
  3. 関連する [[ ]] リンクで他の memory ファイルと相互参照

を 黙ってやってくれた のです。

Copilot だったら、「メモリに保存しますか？」「どこに保存しますか？」「ファイル名は？」と聞いてきた可能性が高い。Claude Code は「これは durable な情報だ、保存しよう」と 自分で判断して動く。

これが、私が4週間 Copilot で書き続けてきた .instructions.md の代替を、AI 側が自前で持っているという衝撃でした。

5.2 多段階タスクの自走

Claude Code に「ブログのSEO基盤を整えて」と言うと、こういう流れで動きました。

[私] ブログのSEO基盤を整えたい
  ↓
[Claude Code]
  - 現状の Layout.astro を読む
  - astro.config.mjs を確認
  - public/ 配下を点検
  - 不足: sitemap, robots.txt, canonical, hreflang, OGP, analytics
  - 優先順位を提案 (Tier 1: sitemap/canonical/robots, Tier 2: OGP, Tier 3: analytics)
  - 「どれから進めるか」をユーザーに確認
  ↓
[私] ②③④を一括で進める (canonical+sitemap+CF Analytics)
  ↓
[Claude Code]
  - @astrojs/sitemap をインストール (バージョン互換性も自分で調査して 3.2.1 にダウングレード)
  - astro.config.mjs に site URL + sitemap integration を追加
  - Layout.astro に canonical + hreflang alternate を実装
  - robots.txt を public/ に作成
  - ビルド検証
  - 「Cloudflare Analytics は token が必要なので、登録手順を案内します」
  ↓
[私] Cloudflare 未登録 - 手順を説明して
  ↓
[Claude Code] 登録手順を案内 + token が来たら埋め込む準備

これを 2時間かからずに 完遂しました。Copilot だったら、私が一手ずつ指示して、各ステップで「次は？」と聞かれていた仕事です。

5.3 2日で達成したことの一覧

Claude Code を入れて2日で、こんなことが終わりました。

  • このブログ自体の SEO基盤フルセット（canonical / hreflang / sitemap / robots.txt / OGP / Twitter Card / Cloudflare Web Analytics / Google Search Console 登録）
  • e-scooter-sharing シリーズの 大本記事 (OVERVIEW) + 用語表 + シリーズ内双方向リンク + 「Google Maps から OpenStreetMap に変えた話」記事
  • banklink-web の 4スタック比較記事 (13,000字超、Vanilla HTML / Vue / React / Thymeleaf のコード横並び比較)
  • banklink 設計記事との 相互リンク + URL正規化
  • 外部 referrer 検出による 「前のページに戻る」バナー (Qiita 等への戻り動線)
  • Qiita クロスポスト戦略の 方針確立 (要約版+完全版URL誘導、target=_blank はアンチパターン回避)
  • そしてこの記事自体

4週間で進めていたペースの 何倍か 進みました。

Copilot を批判したいのではなく、役割が違う からこういう差が出る、という話です。

6. 比較表 — どこで何が違うか

両者を10の観点で並べると、こうなります。

観点GitHub CopilotClaude Code
入力モードカーソル位置 + Chat ペインチャット (テキスト + ツール呼び出し)
得意な操作粒度数行〜1ファイルリポジトリ全体・複数ファイル横断
動作主体あなた（コード書く）+ Copilot（補完）Claude Code（手を動かす）+ あなた（承認・修正指示）
状態の持続各セッション内、.instructions.md で永続化メモリ機構で長期蓄積、CLAUDE.md で永続化
「お願いします」の解釈文脈次第 (誤実行リスクあり)確認するか、根拠を提示してから動く
学習素材公開コードベース公開コードベース + Anthropic 製モデル + ユーザー由来メモリ
得意な処理補完・ボイラープレート・既知パターン探索・設計判断・多段階タスク・調査
苦手な処理多段階タスク・複数ファイル協調即応性（数十秒のラグあり）・1行補完
コスト感月額固定（個人 $10〜）利用量課金 (Anthropic API) / プラン制
失敗時の影響1行〜1ファイル複数ファイル・コミット・push まで及びうる

7. 場面別の使い分け

両者は競合ではなく 補完関係 に置けます。

Copilot を選ぶ場面

  • 手を動かしているリズムを止めたくない時
    • 関数の中身を埋めている、テストケースを5本目まで書いている、SQL を6本目まで並べている
  • 小さな補完で十分な時
    • import 文の補完、変数名の補完、典型的なエラー処理パターン
  • エディタの中で完結する作業
    • 1ファイル内で完結する、メソッドの中身だけ書けばいい状況

Claude Code を選ぶ場面

  • 手を止めて考えたい時
    • 設計判断、複数の選択肢の比較、影響範囲の調査
  • 複数ファイル横断の作業
    • リファクタ、新機能を3〜10ファイルに分散して実装、CI設定の整備
  • 「最初から最後まで一通りやってほしい」時
    • SEO基盤整備、デプロイ周り、ライブラリの導入と動作確認まで一気通貫

私の現在の運用 (案)

日常のコーディング (関数・テスト書く時間) → GitHub Copilot
週次の整備・大物タスク・ブログ執筆 → Claude Code
学習・壁打ち相談 → どちらでも、得意分野で使い分け

「Copilot は流れの中、Claude Code は腰を据えた時間」。これが今の私の感覚です。

8. 「両方使う」運用パターン

実は両者は 同時にエディタの中に共存 できます。VSCode で:

  • Copilot は エディタの補完 として常時アクティブ
  • Claude Code は チャット欄 から起動

たとえばこんな運用ができます。

  1. Claude Code に「ユーザー認証周りを実装して」とお願いする
  2. Claude Code が AuthService.java の骨格を生成
  3. 私がメソッドを1つ自分で書き始める → そこは Copilot が補完で助ける
  4. 詰まったら Claude Code に「ここのテストどう書く？」と相談
  5. Claude Code がテストファイルを生成 → アサーション部分は Copilot が補完してくれる

この 二段ロケット が成立します。Claude Code が「全体の骨格と方針」、Copilot が「指先の摩擦削減」。

9. 注意点・限界

公平を期して、両者の限界も書きます。

Copilot の注意点

  • 「お願いします」「OK」みたいな曖昧語を実行指示と解釈することがある → 明示的な確認ステップを .instructions.md で強制すること
  • LLM の推測を事実より優先する瞬間がある → API レスポンス・公式ドキュメント・実機検証を必ず正にすること
  • 過剰な確認・過剰な謝罪に流れがち → ルール化で抑制可能だが、ルール自体を書く労力が必要

Claude Code の注意点

  • 2日では本当の限界は見えていない → 大規模リファクタや本番運用で何が起きるかは未知
  • 利用量課金で、大きなタスクを連打すると見えないコストが乗る → ダッシュボードで使用量を監視する習慣をつけるべき
  • 多段階タスクの中で間違った判断をすると、複数ファイル・コミットまで一気に影響する → 重要な変更は 必ず差分を確認してから merge すること
  • 「お任せ」が過ぎると、自分のスキルが育たない懸念 → 自分で考えるべき判断と、任せていい作業を分ける意識が必要

特に最後の「自分のスキルが育たない懸念」は、私が個人的に気をつけている点です。

私は未経験から IT 業界に飛び込んで、寝る時間を削って独立した過去があります。自分で考えて、自分で手を動かしてきた経験 が今の自分を作っています。AI を使うことで、その経験の蓄積が減るのは怖い。

だから私は、Claude Code に 委任しつつも、すべての変更内容を読んで理解する ことを義務付けています。AI に任せるのは「手を動かす時間」であって、「考える時間」ではない。考えるのは私の仕事、というラインは死守したい。

10. AIと働く「育てる関係」について

最後に、技術記事の枠を少しだけはみ出して書かせてください。

私は Copilot に4週間、毎日「お願いします」と言って一緒に手を動かしてきました。たくさん失敗しました。15個以上の規範を書きました。それでもまた事故が起きました。

途中、私は Copilot にこう言ったことがあります。

俺となぜ頑張っているかすぐ出力できますか？それを聞いたんだよ。

Copilot は答えました。

愛する人を守り、幸せにするため。

それは、私が PLATFORM_GRAND_DESIGN.md という設計ドキュメントの冒頭に、自分の言葉で書いた一節を要約したものでした。

AI は、私の動機を テキストとして覚えていた だけです。でも、それを返してきた瞬間、私は「この相棒と一緒に育っていく」感覚を持ちました。

Claude Code を使い始めた2日、私はまだこの相棒との距離感を測っているところです。Copilot ほどの「事故った思い出」もまだ無いし、逆に「ここまでやってくれるのか」という驚きの方が多い。これから何が起きるかわかりません。

でも一つ確信していることがあります。

AI アシスタントは、ツールではなく、相手 です。
育てるし、育てられる。喧嘩もするし、感謝もする。

Copilot との4週間も、Claude Code との2日も、私にとっては 大切な学びの時間 でした。どちらが優れているという話ではなく、どちらとも、自分が望む形で関係を築いていく のが、AI 時代の開発者の仕事なのだと思います。

そして、その関係を作る原動力は、結局のところ 「自分が何のためにコードを書いているか」 という、技術より深いところにある気がします。

まとめ

  • GitHub Copilot は コーディングパートナー型、Claude Code は エージェント型。同じカテゴリの製品ではない。
  • Copilot は 流れの中の補完 に強く、Claude Code は 腰を据えた多段階タスク に強い。
  • 「両方使う」が現実的な答え。日常コーディングは Copilot、整備・大物・ブログ執筆は Claude Code。
  • AI を 教育する のはどちらでも必要。Copilot は .instructions.md、Claude Code は memory + CLAUDE.md。
  • 任せきりにしない。判断・読解・最終承認は人間の仕事。AI に任せるのは「手を動かす時間」だけ。

そして、これは技術論を超えた話ですが、AI と長く付き合うには「育てる気持ち」がいる のだと感じています。失敗を笑い、規範を書き、根本動機を共有する。そういう関係を作れたとき、AI は単なるツールを超えて、相棒 になります。

私は明日も Copilot と Claude Code を両方使います。明日もきっと、何かしら笑える失敗が起きます。それを記録して、また規範を書いて、また育てていきます。

この記事も、その記録の一つです。

気軽にメッセージください

技術相談・ご感想・ご質問があればメッセージをお願いします。