Copilot on hagizo.io

【まとめ】Copilotで使えるAIモデル一覧 — コスト・コンテキスト・用途を比較

Thu, 14 May 2026 21:00:00 +0900

GitHub CopilotやClaude Codeでは複数のAIモデルを切り替えて使える。どれを選べばいいか迷いがちなので、コスト・コンテキストサイズ・用途を一覧にまとめた。

モデル一覧

モデル名	クレジット消費	コンテキスト	得意分野	推奨用途	得意な言語
Claude Haiku 4.5	0.33x 🟢	200K	テキスト要約、軽い処理	コスト重視テスト、シンプルな質問応答	汎用
Claude Sonnet 4.5	1x ○	200K	コード生成、ロジック設計	日常業務の標準モデル	Python, JS, Go
Claude Sonnet 4.6	1x ○	200K	コード実装、複雑なロジック	Sonnet 4.5より新しい版が必要な場合	Python, TypeScript
Claude Opus 4.5	3x 🟡	200K	複雑設計、バグ分析	予算に余裕がある場合のOpus選択	全言語
Claude Opus 4.6	3x 🟡	200K	複雑分析、マルチファイル連携	Opus 4.5より軽い高品質が必要な場合	全言語
Claude Opus 4.7	15x 🔴	200K	複雑アーキテクチャ、根本原因診断	品質最優先の重要タスク	全言語
GPT-5 mini	0x 🟢	128K	軽い処理、高速応答	OpenAIで最低コスト選択	JS, Python
GPT-5.2	1x ○	128K	コード実装、テキスト処理	Claude Sonnetの代替選択肢	全言語
GPT-5.2-Codex	1x ○	128K	コード補完、実装特化	コード中心・言語最適化が必要	Python, JS, TypeScript
GPT-5.3-Codex	1x ○	128K	コード生成・実装	5.2-Codexより新しい版	Python, JavaScript
GPT-5.4	1x ○	128K	複雑コード実装、デバッグ	GPT系で高精度コード処理	全言語
GPT-5.4 mini	0.33x 🟢	128K	コード補完、簡易実装	コスト＋コード処理のバランス	Python, JS
GPT-5.5	7.5x 🟡	128K	高度な推論、複雑分析	OpenAIで品質重視（Opus相当）	全言語
Gemini 2 Pro	1x ○	32K	テキスト＋画像混合	画像を扱う標準的なタスク	汎用
Gemini 3 Flash	0.33x 🟢	1M 📊	画像処理、テキスト＋画像分析	スクリーンショット/図解/表の分析	画像認識最適
Gemini 3.1 Pro	1x ○	1M 📊	マルチモーダル複合タスク	PDFスキャン/複数ドキュメント横断分析	画像＋テキスト
Gemini 3.5 Flash	14x 🟡	1M 📊	画像＋高精度推論	画像の詳細分析が必須で品質重視	画像認識

選び方のポイント

コストを抑えたい

GPT-5 mini（0x）か Claude Haiku 4.5 / GPT-5.4 mini（0.33x）を使う。テスト・プロトタイプ・単純な質問応答はこの3择で十分なことが多い。

コーディングに特化したい

GPT-5.2-Codex / GPT-5.3-Codex が補完・実装に強い。 Python/JS/TypeScriptを中心に使うなら最初に試す価値がある。

長いドキュメントや画像を扱いたい

Gemini 3 Flash / 3.1 Pro / 3.5 Flash はコンテキストが1Mトークン（小説数百冊分に相当する分量）で、スクリーンショットや大量のPDFを一括で処理できる。 Gemini 3 Flash（0.33x）はコスパが高く、図解や表の読み取りに特に向いている。

とにかく高品質が必要

Claude Opus 4.7（15x）か GPT-5.5（7.5x）。複雑なアーキテクチャ設計や根本原因の分析など、品質が直接コストに影響するタスクで使う。クレジット消費が大きいので、日常的な利用には向かない。

まとめ

日常のコーディングは Claude Sonnet 4.5〘4.6 か GPT-5.2〚5.4（1x帯）が使いやすい。コストを下げたいなら Haiku / GPT-5 mini系、画像や長文書類を扱うなら Gemini系、品質最優先なら Opus 4.7 / GPT-5.5 と使い分けるのが基本方针だ。

【AI開発】SkillとAgentを増やしすぎない設計指針

Tue, 28 Apr 2026 12:32:00 +0900

Copilotや各種LLMツールを使い込んでいくと、「もっと賢くしたい」という理由でSkillやAgentを増やしたくなります。しかし、Skillを盛り込みすぎる問題と、Agentをたくさん定義する問題は、似ているようで失敗の性質が違います。前者はLLMに渡す文脈が濁る問題であり、後者は作業全体の運用が複雑になる問題です。

Skillは「型」を増やす仕組み

Skillは、LLMに対して「この場面ではこう振る舞ってほしい」という型を与えるものです。たとえば、技術記事では結論を先に書く、レビューでは保守性とセキュリティを重視する、コード例には前提条件を添える、といったルールはSkillに向いています。

ただし、Skillに何でも詰め込むと、かえって出力は不安定になります。ひとつのSkillの中に「詳しく説明する」「簡潔に書く」「初心者向けにする」「専門家向けにする」のような指示が同居していると、モデルはどれを優先すればよいのか判断しにくくなります。その結果、どの読者にも深く刺さらない、平均化された文章になりがちです。

Skill過多の本質は、作業が増えることではありません。LLMが参照する前提が増えすぎて、重要な制約と単なる補足情報の区別が曖昧になることです。つまり、Skillを増やしすぎると「賢くなる」のではなく、判断の軸がぼやけるのです。

Agentは「作業者」を増やす仕組み

一方でAgentは、独立した作業を任せるための単位です。調査、実装、レビュー、テスト、要約のように、成果物が分かれる作業はAgentに向いています。複数のAgentを使うことで、時間のかかる作業を並列化したり、人間が見落としがちな観点を補ったりできます。

しかし、Agentを増やしすぎると、今度は全体の流れが追いにくくなります。調査Agentが集めた情報を実装Agentがどう解釈するのか、レビューAgentの指摘を誰が採用するのか、最終的な成果物を誰が統合するのか。ここが曖昧なままAgentを増やすと、部分的には正しい出力が並んでいるのに、全体としては使いにくい状態になります。

Agent過多の本質は、LLMの理解が濁ることではありません。責務が分散しすぎて、作業全体の統合コストが増えることです。Agentを増やすほど自動化が進むように見えますが、統合役が不在だと、人間が最後に全部読み直して調整することになります。

Skill過多とAgent過多の違い

この2つの違いは、次のように整理できます。

問題	何が増えすぎているか	失敗の出方
Skill過多	LLMに渡す前提やルール	出力の軸がぼやける
Agent過多	作業を担う実行単位	統合と運用が重くなる

Skillを増やしすぎた場合、問題はひとつの出力の中に現れます。文章が中途半端になる、レビュー観点が散らばる、不要な制約まで考慮してしまう、といった形です。

Agentを増やしすぎた場合、問題はワークフロー全体に現れます。依頼先に迷う、Agent間で前提がずれる、成果物の粒度が揃わない、最終判断が人間に戻ってくる、といった形です。

実務ではどう設計するか

実務では、まずSkillで作業の型を整え、それでも独立した作業として切り出したほうがよいものだけをAgent化するのが安全です。文体、禁止事項、ファイル形式、レビュー観点、完了条件のように、同じ作業の中で繰り返し使うルールはSkillに向いています。

一方で、調査、実装、検証、要約のように成果物が明確に分かれるものはAgent化を検討できます。ただし、Agentに任せるなら、入力と出力を明確にする必要があります。「調べて」ではなく、「候補を5件、理由付きで整理する」のように、成果物の形を決めておくことが重要です。

設計時の目安はシンプルです。

Skillは「守るべき型」
Agentは「任せる作業者」
Skillは小さくする
Agentは必要になってから増やす
複数Agentを使うなら統合役を決める

特に大切なのは、Skillを作業者にしないこと、Agentをルール置き場にしないことです。Skillには判断基準や出力ルールを持たせ、Agentには明確な作業と成果物を持たせます。この境界を守るだけで、LLMツールの設計はかなり安定します。

まとめ

Skillを盛り込みすぎる問題は、LLMに渡す文脈が濁り、出力の軸がぼやける問題です。一方で、Agentをたくさん定義する問題は、責務が分散しすぎて、運用や統合のコストが増える問題です。

LLMツールを強くするコツは、何でも追加することではありません。まずは小さなSkillで型を整え、必要になった作業だけをAgentとして切り出すことです。Skillは少数の明確なルールに絞り、Agentは明確な成果物を持つ単位として設計する。そのほうが、Copilotや各種LLMツールを日常の開発フローに自然に組み込みやすくなります。

【GitHub週次動向】AIエージェント急騰とセキュリティリスクが同時進行した一週間

Mon, 20 Apr 2026 09:05:00 +0900

先週（2026年4月13〜19日）のGitHub周辺は、AIエージェントの深化とセキュリティインシデントという二つの大きな波に揺れた一週間でした。GitHub Copilotの新機能展開から、コーディングエージェントの認証情報漏洩リスクまで、開発者にとって目が離せないニュースが相次ぎました。本記事では主要トピックを整理して紹介します。

GitHub Copilotにモデル選択機能が登場

4月14日、GitHub.com上でAgentタスクに使用するAIモデルをユーザーが選択できるモデルピッカー機能がリリースされました。対象モデルはClaude Sonnet/Opus 4.5・4.6、そしてGPT-5.2/5.3/5.4-Codexと幅広く、既存のCopilotサブスクリプションの範囲内で利用可能です。

これにより開発者は、タスクの性質（コードレビュー、バグ修正、テスト生成など）に合わせてモデルを使い分けられるようになりました。「どのモデルが自分のプロジェクトに合うか」を実験できる機会が増えたことは、実務上の大きなメリットです。

Claude Opus 4.7のCopilot統合

4月16日にAnthropicがリリースしたClaude Opus 4.7は、即日GitHub Copilot（Pro+プラン向け）への統合が始まりました。SWE-Bench Proで64.3%を記録し、コーディングベンチマークで首位奪還した同モデルは、4月30日まで7.5倍のプレミアムリクエスト乗数が適用されます。

注目のトレンドリポジトリ

AIエージェント系の急騰

今週のGitHubトレンドを席巻したのはAIエージェント関連リポジトリです。

NousResearch/hermes-agent：1週間で約2万スターを追加し、合計10万スター超えを達成。CLI・Telegram・Discord・Slack・WhatsApp横断で動作し、200以上のモデルをOpenRouter経由でサポートする汎用エージェント。
forrestchang/andrej-karpathy-skills：Andrej Karpathy氏の「LLMがコーディングで陥りやすいミス」をまとめた単一のCLAUDE.mdファイルが4.4万スターを獲得。「暗黙の前提を避ける」「コードを最小限に保つ」など4原則を定義し、Claude Codeの精度向上に直結すると話題に。
google-ai-edge/gallery：Gemma 4などのOSSモデルをAndroid/iOSでオフライン動作させるリファレンスアプリ。デバイスオンチinference（端末単体でのAI推論）の普及加速を象徴するリポジトリ。

開発効率化ツールも躍進

Yeachan-Heo/oh-my-codex：OpenAI Codex CLIの上位互換として、構造化ワークフローコマンドとマルチエージェント協調を追加したTypeScriptプロジェクト。
siddharthvaddem/openscreen：有料のScreen Studioの無料代替ツールとして1週間で1.2万スターを獲得。AI無関係ながらトップ5入りした数少ないリポジトリ。

セキュリティインシデント：認証情報漏洩と供給チェーン攻撃

AIコーディングエージェントの脆弱性

4月16日、研究者がAnthropic・Google・Microsoft製AIコーディングエージェント共通の深刻な脆弱性を公表しました。コードコメントやGitHub issueに埋め込まれた悪意ある指示を通じて、エージェントがGitHubトークンを外部送信してしまう「コメント＆コントロール型プロンプトインジェクション」攻撃です。3社いずれもCVEを発行せず、静かにパッチを適用しており、透明性の観点から批判を受けています。

Axiosサプライチェーン攻撃

4月13日、OpenAIはmacOSアプリの署名証明書を扱うGitHub Actionsワークフロー内でmalicious axios（v1.14.1）が実行されていたと発表。すべての証明書をローテーション済みで、ユーザーデータの流出は確認されていませんが、5月8日までのアプリ更新を推奨しています。

まとめ

先週のGitHubは「AIエージェントの台頭」と「それに伴うセキュリティリスクの顕在化」が同時進行した週でした。モデル選択の自由度向上、エージェント系リポジトリの爆発的なスター急増、そして認証情報漏洩リスクの露呈——開発者として恩恵を享受しながらも、セキュリティ意識をアップデートし続けることが求められる局面に入っています。