# AI の使用を最適化して効率を最大化し、コストを削減する 適切なモデルを選択し、プロンプトを構成し、ガードレールを追加して、 Copilot がタスクをより効率的に完了し、使用する AI creditsを減らす方法について説明します。 ## イントロダクション この記事で概説されている戦略では、 Copilot 効率を向上させる方法を示します。その結果、使用する AI creditsが少なくなります。 ## 1. 適切なタスクに適したモデルを選択する タスクに適した機能レベルを選択し、推論を適切に構成し、特定のワークロードに対して auto model selection かつ安価なモデルを活用することで、トークンの消費量を大幅に削減しながら品質を維持できます。 ### 適切なモデルを選択する モデルの選択は、コスト効率を向上させる最も速い方法の 1 つですが、見過ごされることがよくあります。 一般的なパターンは、すべてのタスクで最も能力の高いモデルに既定で設定されますが、結果を改善することなくトークンの使用が増えることがよくあります。 一部の実行負荷の高いシナリオでは、推論モデルを過剰に使用すると、モデルがタスクを過剰に考えたり、不要な変更が発生したりする可能性があるため、品質が低下する可能性があります。 関連する作業に基づいてモデルを選択します。 * **推論モデル**: アーキテクチャの決定、複雑なデバッグ、システム設計、より詳細な分析が必要なタスクに最適です。 * **中間層モデル**: プランが既に明確であり、エージェントを効率的に実行する必要がある場合に最適です。 * **軽量モデル**: リファクタリング、書式設定、ドキュメントの更新、およびその他のルーチンの適切な範囲の変更に最適です。 タスクが要求するだけの機能を使い、必要最小限にとどめてください。 タスクに一致する機能により、結果が向上し、大規模なコストが直接制御されます。 モデルとタスクの種類別の内訳については、「 [AUTOTITLE」](/ja/enterprise-cloud@latest/copilot/tutorials/compare-ai-models)を参照してください。 ### モデルの推論レベルを構成する 一部のモデルでは、構成可能な推論レベルもサポートされています。このレベルでは、モデルが応答する前の理由の量を制御します。 より高いレベルでは複雑な問題に対する回答を向上させることができますが、より多くのトークンを消費するため、クレジットが多くなるため、通常のレベルを既定で使用し、より困難なタスクにのみ発生させる必要があります。 構成可能な推論は、サポートされているモデルの Visual Studio Code と Copilot CLI で使用できます。 「[GitHub Copilotでサポートされている AI モデル](/ja/enterprise-cloud@latest/copilot/reference/ai-models/supported-models#models-with-extended-capabilities)」を参照してください。 ### Copilot auto model selectionを既定として使用する Auto model selection は、タスクの意図に基づいて、対応するモデルを選択します。 小さなルーターはプロンプトを見て、 **それを最も効率的に処理**できるモデルに送信し、複雑な問題に対して高価な推論モデルを予約します。 また、トークンの予算を素早く消費するモデルを回避します。 Auto model selection また **、キャッシュを保護します**。 新しいセッションが開始されたとき、または `/compact`実行した後、タスクの途中ではなく、自然なキャッシュ境界でのみモデルが変更されます。 これが重要な理由の詳細については、4 を参照してください [。キャッシュを保持します](#4-preserve-the-cache)。 Auto model selection は、性能が低下したモデルや高負荷のモデルを避けてルーティングするため、レート制限に達したりエラーが発生したりすることが少なくなります。 有料Copilotプランをご利用の場合は、auto model selection、Copilot Chat、Copilot CLI、またはGitHub Copilot appでCopilot cloud agentを使用しながら、モデル コストの 10% 割引を受けることができます。 機能とその可用性については、 [について Copilotauto model selection](/ja/enterprise-cloud@latest/copilot/concepts/models/auto-model-selection#copilot-chat-in-ides) を参照してください。 ### より安価なモデルを使用する subagents 安価なモデルで subagents を実行します。 Subagents は独自のセッションで実行され、メイン エージェントの会話履歴は継承されません。 コンテキストのスコープは 1 つのフォーカスされたタスクであるため、軽量なモデルで十分です。また、割り当てると、中間セッション モデルの切り替えのようにメイン エージェントのキャッシュには影響しません。 ## 2. プロンプトで明確なガイダンスを提供する プロンプトは、エージェントが行うすべての方向を設定します。 プロンプトがあいまいな場合、エージェントは意図を推測し、より多くのコンテキストを調査し、判断の呼び出しを行う必要があります。 多くの場合、再試行、スコープのずれ、不要なトークンの使用につながります。 適切に構造化されたプロンプトには、次の 3 つの特性があります。 * **明確なタスク定義。** "この問題を修正する" の代わりに、問題の内容、発生場所、および予想される結果がどのようになるかを説明します。 * **関連するコンテキストが事前に提供されます。** 重要なファイル、サービス、ログ、エラー、または入力が既にわかっている場合は、それらを含めます。 これは、エージェントが不要な探索を回避するのに役立ちます。 * **明確な停止条件。** "完了" の外観をエージェントに伝えます。 停止ポイントがない場合、エージェントは、追加のコミットの追加、関連のないコードのリファクタリング、またはスコープの拡張によって、目標を超えて続行できます。 この追加されたガイダンスでは、トークンの使用量が有意に増加することはありませんが、適切な結果を得るために必要なエージェント実行の数を大幅に減らすことができます。 プロンプト エンジニアリングのベスト プラクティスについては、 [GitHub Copilot Chat のプロンプト エンジニアリング](/ja/enterprise-cloud@latest/copilot/concepts/prompting/prompt-engineering) を参照してください。 ## 3. コンテキストは簡潔に保つ Copilot は、入力トークンとしてアクセスできるコンテキストを送信し、そのコンテキストが追加されます。開いているエディター タブ、添付ファイル、長い会話の完全な前後はすべてコンテキストとしてカウントされます。 コンテキストを制御し続けるために、次の操作を行うことを検討してください。 ### 問題を切り替えたときに新しい会話を開始する 長いスレッドでは、新しいリクエストのたびにそれまでの履歴すべてが引き継がれます。 関連のないタスクに進むときは、新しい会話を開始します。 例えば次が挙げられます。 * Copilot CLI `/new` (または`/clear`) を使用する * Copilot Chatで、新しいチャット セッションを開始します。 ### 続行したい長時間の Copilot CLI セッションを圧縮する スレッドを継続する必要があるが、サイズが大きくなった場合は、`/compact`でCopilot CLI実行して履歴を要約し、コンテキスト ウィンドウを縮小し、必要に応じて概要 (`/compact focus on the auth module` など) にフォーカスします。 さらに、 `/context` を使用して、現在の使用状況をいつでも確認できます。 「[でコンテキストを管理する GitHub Copilot CLI](/ja/enterprise-cloud@latest/copilot/concepts/agents/copilot-cli/context-management)」を参照してください。 ### Copilot にプロジェクトのマップを与える `AGENTS.md`ファイルや`.github/copilot-instructions.md`ファイルなど、保守性の高いカスタム命令ファイルを使用すると、エージェントはリポジトリの構造上の概要を把握できるため、自身の向きを変えるためだけに多数のファイルを読み取る必要はありません。 「[さまざまな種類のカスタム命令のサポート](/ja/enterprise-cloud@latest/copilot/reference/custom-instructions-support)」を参照してください。 ### 必要なツールのみを取り込む 大規模なツール セット (たとえば、完全な MCP サーバーの相当するツール) は、すべての要求のコンテキストに追加されます。 ワークフローに適合する場合は、タスクに関連するツールセットのみを有効にします。 「[GitHub MCP サーバーのツールセットの構成](/ja/enterprise-cloud@latest/copilot/how-tos/provide-context/use-mcp-in-your-ide/configure-toolsets)」を参照してください。 ## 4. キャッシュを保持する キャッシュを使用すると、AI モデルは会話のコンテキストの一部を格納できるため、すべての要求で再処理する必要はありません。 同じ大きなコンテキスト (システム プロンプト、ファイル コンテンツ、ツール定義) が何度も繰り返し送信されるエージェント コーディングでは、キャッシュに影響があります。キャッシュは、前の応答のキャッシュ部分は再処理ではなく再利用され、キャッシュされたトークンは通常の入力価格の 10% で課金されます。 「[GitHub Copilot のモデルと価格設定](/ja/enterprise-cloud@latest/copilot/reference/copilot-billing/models-and-pricing)」を参照してください。 ただし、次のアクションによりキャッシュが無効になり、完全なコンテキストが再送信され、新しい入力トークンとして課金されます。 * **セッションの途中でモデルを切り替える**。 別のモデルでは別のモデルのキャッシュを再利用できないため、次の要求では最初から再構築されます。 モデルを選択 (または Copilot auto model selection使用) し、セッションに使用します。 * **古いセッションに戻ります**。 キャッシュは、非アクティブな期間 (OpenAI モデルの場合は 24 時間、他のほとんどの場合は 1 時間) の後に期限切れになります。 しばらく離れている場合は、新しいセッションを開始するか、(`/compact`で) Copilot CLI実行します。再構築されるのは、完全な履歴ではなく短い要約です。 * **セッションの途中で推論を変更**する。 セッション中に推論作業レベル、コンテキスト サイズ、または有効なツールと MCP サーバーのセットを変更すると、キャッシュが無効になります。 開始する前にこれらの設定を構成し、セッションに対して変更しないようにします。 ## 5. セッション制限 AI credit 設定する AI credit セッションの制限は、1 つのセッションで実行Copilot作業の量を制限します。 Copilot CLIとCopilot SDKでは、タスクを開始する前にセッション制限を設定し、制限に達すると、エージェントは正常に停止し、通知を受け取り、制限を続行するか引き上げるかを選択できます。 AI credit セッション制限は、次の場合に最も役立ちます。 * 予期しないコストを回避するために、1 つのセッションで AI credits 使用量を制限する必要があります。 * エージェントの効率をチューニングしていて、それでも良好な結果を生み出す最小限の AI credits を見つけたいと考えています。 セッション制限は、1 つのタスクが消費する AI credits の数を制御するのに役立つソフト制限ですが、ユーザー レベルの予算や使用制限に代わるものではなく、毎月の全体的な消費量を管理します。 これらのコントロールについては、「 [使用量ベースの課金の予算](/ja/enterprise-cloud@latest/copilot/concepts/billing/budgets-for-usage-based-billing)」を参照してください。 Copilot CLIでセッション制限を設定する方法については、[で AI credit セッション制限を設定する GitHub Copilot CLI](/ja/enterprise-cloud@latest/copilot/how-tos/copilot-cli/use-copilot-cli/set-session-limit) を参照してください。 ## 6. 研究、計画、実施 エージェントを効果的に活用するうえでの大きな変化の一つは、すべてを1回のセッションで済ませるやり方から脱却することです。 研究、計画、実装がすべて一緒に行われると、コンテキストが急速に拡大し、無関係な情報が蓄積されます。 作業を明確なフェーズに分割します。 * **研究：** エージェントを使用してコードベースを調べ、関連するファイルを特定し、依存関係を理解します。 * **計画：** 変更を加える前に、詳細で構造化された計画または仕様を作成します。 ここで、推論モデルは最も価値があり、常に強力な推論モデルを使用して計画し、より安価なモデルで作業を実装します。 * Copilot CLIでは、`/plan`を使用します。 * Copilot ChatのVisual Studio Codeで、エージェントのドロップダウンから \[プラン] を選択するか、コンテキスト ウィンドウに「`plan`」と入力します。 * **実装：** フォーカスされたコンテキストと実行に適したモデルを使用して、プランに対して実行します。 フェーズ間で新しいセッションを開始すると、不要なコンテキストを転送できなくなります。これにより、トークンの使用が増加し、エージェントのわかりやすさが低下する可能性があります。 各フェーズは、必要なものでのみ動作する必要があります。 効果的なスコーピング セッションのガイダンスについては、 [GitHub Copilotを使用してタスクに取り組むためのベスト プラクティス](/ja/enterprise-cloud@latest/copilot/tutorials/cloud-agent/get-the-best-results) を参照してください。 ## 7. 学習を活用し、ターンごとに効率を高める ### `/chronicle`を使用して分析情報を生成する Copilot CLIでは、`/chronicle`はセッション履歴から有用な分析情報を生成できます。 * `/chronicle tips`を使用して、最近のセッション履歴を分析し、Copilotをより効率的に使用する機会を確認します。 * `/chronicle cost-tips`を使用してトークンの使用パターンを理解し、コストを削減する方法に関する分析情報を取得します。 「[セッション データ GitHub Copilot CLI について](/ja/enterprise-cloud@latest/copilot/concepts/agents/copilot-cli/chronicle#the-chronicle-slash-command)」を参照してください。 ### `copilot-instructions.md` ファイルに分析情報をフィードする リポジトリ レベルの `copilot-instructions.md` ファイルは、リポジトリに固有のガイダンスをエンコードする最も直接的な方法です。 個人レベルと組織レベルの手順を重ねて、より広範な一貫性を確保できます。 `/chronicle`が繰り返し発生するパターン (ツールが過剰に使用され、読み間違いを続けるプロンプト) を表示すると、その観察を`copilot-instructions.md` ファイルに直接エンコードします。 これにより、1 回限りの分析情報が、今後のすべてのセッションに適用される永続的なガイダンスに変わります。繰り返す必要はありません。 詳細については、「[GitHub Copilot用のリポジトリカスタム命令の追加](/ja/enterprise-cloud@latest/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions)」を参照してください。 ### `copilot-instructions.md` ファイルを特定し、固定したままにする 永続的な命令により、エージェント間の対話の一貫性が向上しますが、その値は、その記述方法によって完全に異なります。 最適な手順は、短く、具体的であり、実際に観察されたエージェントの動作に根付きます。これは、適切に聞こえるがシステムには適用されない一般的なベスト プラクティスではありません。 **含める内容:** * 必要なフレームワーク、ライブラリ、または設計パターン * エージェントが繰り返す傾向がある既知の落とし穴 * "簡潔にする" や "リターン コードのみ" などの出力の期待値 * エージェントが従う必要があるチーム固有の規則 * ビルド、テスト、Lint のコマンド **回避する方法:** * 長い一般的なドキュメント * 実際のシステムを反映しない AI によって生成されたガイダンス * 1 回限りの基本設定または使用頻度の低い詳細 * コンテキストを煩雑にする過剰な指示 コードベース、アーキテクチャ、標準、ワークフローの進化に合わせて、手順を最新の状態に保ちます。 これらの命令は実行のたびにエージェントのコンテキストに含まれているため、小さな改善であっても、繰り返しエラーを減らし、時間の経過と同時に無駄なトークンの使用を減らすことができます。 ## 8. 確定的ガードレールを追加する エージェントは非決定論的であり、特にマルチステップ ワークフローでは、毎回正しいとは限りません。 ガードレールがないと、小さなエラーが迅速に複合化する可能性があります。エージェントは正しくない出力を基に構築され、目標からさらに離れ、デバッグのコストが高く、時間がかかります。 決定論的制御では、明確な合格/失敗信号が導入されます。 * **単体テストでは** 、エージェントの変更によって予期される動作が生成されたことを確認します。 * **リンターは** 構造と一貫性を強制し、書式設定の問題、スタイルのずれ、および回避可能なクリーンアップ作業を防ぎます。 * **セキュリティ スキャンは** 、アンワインドが難しくなる前に、危険なパターンを早期にキャッチします。 これらのコントロールを組み合わせることで、緊密なフィードバック ループが作成されます。エージェントは変更を行い、テスト、ルール、スキャンによって評価され、エージェントは次に進む前に調整されます。 これにより、トークンの無駄の最大の要因の 1 つである、間違った変更の長いチェーンを防ぐことができます。 これらのガードレールに投資するチームでは、再試行の回数が減り、タスクの完了速度が速くなり、エージェントの動作が予測可能になります。 多くの場合、個々の手順で事前に少し多くのトークンを使用している場合でも、トークンの合計消費量が削減されます。 ## 次のステップ 支出を監視および管理して、 AI creditsを最大限に活用します。 * **ダッシュボードと予算コントロールを使用します**。 \[AI の使用状況] ページでは、すべての機能とモデルの使用量が分割されるため、クレジットが実際にどこに向かっているかを確認し、それに応じて調整できます。 「[GitHub AI Creditsの使用状況の監視](/ja/enterprise-cloud@latest/copilot/how-tos/manage-and-track-spending/monitor-ai-usage)」を参照してください。 * **より大きな許容量にアップグレードします**。 毎月の上限に定期的に近づくと、追加の使用量を支払うよりも高いプランの方が経済的である可能性があります。これは、より高いプランの方が AI credit 許容量が多い場合です。 「[GitHub Copilotの計画](/ja/enterprise-cloud@latest/copilot/concepts/billing/individual-plans#github-ai-credits-allowance-by-plan)」と「[GitHub Copilot プランの表示と変更](/ja/enterprise-cloud@latest/copilot/how-tos/manage-your-account/view-and-change-your-copilot-plan)」を参照してください。