AIを使い分ける基準は、モデル性能よりコンテキストではないか

生成AIを使っていると、

「結局、どのAIを使えばよいのだろう？」

と思うことがあります。

GPT、GitHub Copilot、Microsoft 365 Copilotなど、現在は複数のAIを利用できます。

以前の私は、「どのAIが一番賢いのか」という視点で比較することが多くありました。

モデル性能、推論能力、コード生成能力。

もちろん、これらは重要です。

しかし、実務で複数のAIを使うようになってから、もう一つの基準を重視するようになりました。

そのAIは、今の仕事に必要な情報を、どれだけ持った状態で考えられるのか。

つまり、コンテキストです。

本記事ではコンテキストを、

その時点でAIが判断や生成に利用できる前提情報

という広い意味で扱います。

モデル性能だけでは、実務の強さは決まらない

例えば、何も知らない人に突然、

「この設計について、どう思いますか？」

と聞いても、相手には判断材料がありません。

一般論や推測を使って答えるしかないでしょう。

一方、その人が次の情報を知っていたらどうでしょうか。

システムの目的
現在の構成
過去の経緯
変更してはいけない部分
今回の要件

同じ質問でも、具体的な判断ができるようになります。

違うのは、質問を受けた時点で持っている前提情報です。

AIでも、似たことが起きます。

モデル性能が高くても、対象となる業務やシステムについて何も知らなければ、一般的な回答になりやすくなります。

反対に、対象プロジェクトのコード、仕様、制約、過去の判断を利用できれば、実務に即した回答を作りやすくなります。

実務で発揮されるAIの能力は、モデル性能だけではなく、

モデル性能と、利用できるコンテキストの組み合わせ

によって変わると私は考えています。

プロンプトは、コンテキストを与える方法の一つ

AIに、

「この設計をレビューしてください」

とだけ依頼する場合と、

「既存システムへの影響と保守性を重視して、この設計をレビューしてください」

と依頼する場合では、回答が変わります。

後者では、目的や判断基準をプロンプトによって追加しています。

つまり、プロンプトを書くことの一部は、

AIが判断するための前提情報を与えること

と捉えられます。

ただし、実務に必要な情報を毎回一つのプロンプトへ書き切ることはできません。

AIが利用するコンテキストには、プロンプト以外にも次のものがあります。

過去の会話
仕様書や設計書
ソースコード
過去の意思決定
RAGによる検索結果
Web検索結果
ToolやAPIの実行結果
利用者の条件や判断基準

この視点で考えると、AIの使い分けもモデルの比較だけでは決まらなくなります。

私は3つのAIを「情報環境」で使い分けている

現在、私は主にGitHub Copilot、Microsoft 365 Copilot、GPTを使っています。

現在の使い分けを整理すると、次のようになります。

AI	主に利用できるコンテキスト	主な用途
GitHub Copilot	コード、関連ファイル、プロジェクト構造	開発、保守、コード調査、影響範囲の確認
Microsoft 365 Copilot	利用権限のある会議、資料、メールなどの業務情報	会議内容、社内資料、業務情報の確認
GPT	自分で構成した資料、条件、ルール、過去の判断	情報整理、設計、比較、長期的な判断

これは製品ごとの絶対的な分類ではありません。

機能や利用環境は変化しますし、同じ仕事を複数のAIで行うこともあります。

ここで重要なのは、

どのAIが最も優れているかではなく、どのAIが今回必要な情報環境を利用できるか

という点です。

GitHub Copilotは、プロジェクトの中で考えられる

ソフトウェア保守では、一つの関数だけを読んでも、システム全体の動きは分かりません。

周辺コード、呼び出し関係、設定ファイル、共通処理、既存実装を横断して、初めて仕様が見えてくることがあります。

私がGitHub Copilotを使う理由は、コードを生成できるからだけではありません。

プロジェクトというコンテキストの中で調査できるから

です。

私にとってGitHub Copilotは、「コードを書くAI」というより、「プロジェクトを知った状態で支援できるAI」に近い位置付けです。

Microsoft 365 Copilotは、業務情報の中で考えられる

仕事の情報は、Teams、Word、Excel、PowerPoint、Outlookなどに分散しています。

Microsoft 365 Copilotは、権限と利用環境の範囲内で、これらの業務情報を判断材料として利用できます。

会議や社内資料について扱う場合、毎回すべての経緯を説明するより、情報が存在する環境でAIを使う方が自然です。

そのため私は、Microsoft 365上の仕事については、Microsoft 365 Copilotを優先して使っています。

GPTでは、自分でコンテキストを構成する

GPTでは、私は目的に応じてコンテキストを自分で構成しています。

例えば、

長期的な目的
判断基準
制約
ナレッジ
過去の意思決定
現在の条件

を整理して与えます。

必要に応じて、新しい情報を追加し、古い情報を外し、判断基準を更新します。

そのため、私にとってGPTは、

自分で情報環境を設計しながら使うAI

です。

一つの仕事で、複数のAIを使うこともある

AIを一つに決める必要はありません。

例えば、既存システムの改修では、次のような使い分けが考えられます。

Microsoft 365 Copilotで、社内資料や会議から業務要件を確認する
GitHub Copilotで、既存コードと影響範囲を調査する
GPTで、要件、制約、調査結果から設計方針を整理する
確定した設計を、実装を担当するAIへ受け渡す

それぞれのAIに同じ仕事を競わせているわけではありません。

その工程で必要なコンテキストを扱いやすいAIへ、仕事を渡している

という考え方です。

もちろん、実際に情報を受け渡す際には、機密性、アクセス権限、利用規約などを確認する必要があります。

コンテキストは、多ければよいわけではない

必要な情報が不足すると、AIは不足部分を推測することがあります。

その推測が誤っていれば、誤った前提から、もっともらしい回答が生成される可能性があります。

ただし、情報をできるだけ多く与えればよいわけでもありません。

古い仕様、別案件の情報、重複した資料、今回の判断に不要な情報まで含めると、AIが重要な条件を見失う可能性があります。

入れたい情報	外したい情報
今回の目的	別案件の情報
現在の要件	既に無効な要件
重要な制約	古い仕様
関連する過去判断	今回使わない詳細
判断に必要な根拠	重複した情報

コンテキスト設計とは、情報を増やすことではありません。

何を与え、何を与えないかを、仕事の目的に合わせて決めること

です。

情報を取得できることと、根拠にできることは違う

必要な資料へアクセスできても、それだけで今回の判断に使えるとは限りません。

例えば製品の操作を説明するとき、意味の近い文書でも、別機種や旧版の手順なら回答根拠としては不適切です。

担当者が閲覧できる社内資料を、そのまま顧客向けの回答へ使ってよいとも限りません。

したがって、コンテキストを選ぶ際は、関連性だけでなく、対象・版・公開可否・利用目的を確かめます。条件が分からなければ追加確認し、資料同士が矛盾していれば、AIに都合よくつなぎ合わせさせず保留します。

この違いは、顧客サポートDXのRAG / Knowledge設計で具体化しています。本記事の使い分け経験とは別の設計ケースですが、「情報がある」から「今回使える根拠がある」へ進める考え方は共通しています。

AI選びを、モデルランキングだけで決めない

現在、私はAIを選ぶとき、次の順番で考えています。

今回行いたい仕事を決める
判断に必要な情報を特定する
その情報がどこに存在するか確認する
今回の用途で使ってよい根拠かを確認する
必要な情報を適切に扱えるAIを選ぶ
不足している情報だけを追加する

モデル性能を無視するわけではありません。

同じコンテキストを利用できるのであれば、モデル性能が高い方が有利になる場面もあります。

ただ、実務ではモデル性能だけでなく、

そのAIが何を知った状態で仕事を始められるか

まで含めて選ぶ必要があります。

AIを使いこなすことは、良いプロンプトを書くことだけではありません。

必要な情報を特定し、その情報を適切なAIへ与え、不要な情報を外し、必要なら複数のAIを役割分担させる。

AIを使い分けるということは、コンテキストを使い分けることでもある。

私は現在、そのように考えています。

誰に聞くかではなく、誰が必要なコンテキストを持つか

AI活用判断では、人間かAIかを先に決めません。まず問いに必要な情報を特定し、その情報へ直接アクセスでき、回答を検証できる主体を選びます。人、AI、文書、コード、ログ、テストを組み合わせ、不足する情報に応じて調査経路を切り替えます。

人間もコンテキストを持つ知的主体として見る

比較のために、人間とAIを「限られたコンテキストと推論をもとに回答する主体」として捉えます。これは両者を同一視するモデルではありません。人間は経験や価値判断、組織的な権限を持ち、責任ある判断・承認を担います。AIは許可された範囲で情報を参照・処理する道具であり、責任主体にはなりません。

人間もAIも、必要な情報を持っていなければ、もっともらしい推論と確認済みの事実を取り違える可能性があります。ただし、持っていない情報について一切推論できないという意味ではありません。推論だけで個別の事実を確定しないことが重要です。

比較対象	利用できる情報	調査を任せやすい条件	注意すること
AI	参照可能な現行コード、仕様、履歴、与えられた前提	関連箇所を取得でき、処理経路や条件を根拠付きで追える	誤読、推測、取得漏れがある。情報が保存されていても取得できるとは限らない
人間	経験、記憶、設計意図、運用知識、暗黙知、資料	背景や例外を知り、業務上の意味を説明できる	回答待ちや再質問が必要な場合がある。記憶が古く、類推や伝聞が混ざることもある

人間が現行コードを直接確認する場合も、AIが設計履歴を検索できる場合もあります。「コードはAI、背景は人」と固定せず、実際に参照できる情報を比較します。

主体・情報・応答特性・検証可能性を比較する

回答品質を単一の性能値へ置き換えず、少なくとも次の軸で調査経路を評価します。これは判断のための設計モデルであり、実測した公式や品質保証ではありません。

比較軸	確認すること
情報の範囲と新しさ	必要な条件・例外を含み、対象の版や時点に合っているか
一次情報への近さ	コード、正式文書、記録、実行結果へ戻れるか。記憶・伝聞と区別できるか
検索・参照能力	情報があるだけでなく、関連箇所を実際に取得できるか
推論への依存	根拠から確認した部分と、推測で補った部分が分かるか
応答時間	待ち時間や追加質問の反復を含め、今回の判断期限に間に合うか
検証可能性と再現性	同じ根拠・条件で説明や結果を確かめ直せるか

AIの応答が速くても正しいとは限らず、人の回答が遅くても正確とは限りません。経験の豊富さだけでは現行実装の把握を保証できず、コードを読めるだけでは設計意図を確定できません。

同じ問題でも、問いが変われば調査経路を変える

長期運用されるWindowsアプリケーションの保守で、アンインストール時にユーザー単位の設定が残る可能性を調査しました。この経験から、同じ設定の問題でも、以下のように問いを分けて考えます。個々の経路は選択の例であり、すべてを実施したという記録ではありません。

問い	必要な情報	有力な調査主体・経路	検証
現行実装の保存・削除条件は何か	現行コード、条件分岐、呼出関係	コードへアクセスできるAIまたは開発者	関連コードとテストへ照合
なぜこの設計になったか	設計記録、判断履歴、当事者の知識	担当者、設計資料、資料を参照できるAI	記録と当事者の説明を照合
過去の経緯は何か	課題記録、議事録、履歴、経験	担当者または文書検索	記憶と記録を区別
実際の環境で削除されるか	実機、ログ、実行条件	人や道具による実行・観測、結果を調べるAI	対象環境の実行結果を確認
互換性方針や契約上の理由はあるか	正式資料、方針、責任部門の知識	関連文書と責任を持つ担当者	正式文書と判断権限を確認

現行コードを直接参照できるAIを最初の調査主体に選ぶ合理性はあります。ただし、その回答を正解とせず、関連箇所、条件分岐、保存・削除処理へ戻って確かめます。人の回答も、コードを確認した説明なのか、資料・記憶・類推に基づく説明なのかを分けます。

不足する情報に応じて、途中で主体を切り替える

問いを分類し、何を確定したいか決める。
必要なコンテキストと一次情報を特定する。
その情報へ直接アクセスできる主体を選び、調査する。
回答候補を根拠へ照合し、事実・推論・未確認事項を分ける。
不足する情報や矛盾があれば、それを確認できる別の主体・資料へ切り替える。
実行時の事実が必要なら、実機・ログ・テストで確認する。
根拠と未解決事項を整理し、責任を持つ人が必要な判断・承認を行う。

主体の切替は失敗時の救済ではなく、通常の調査に含まれます。AIから人へ、人の説明からコードへ、文書検索から実機へ進むことがあります。誰が最初かではなく、何がまだ不足しているかで次の経路を選びます。

一次情報も問いによって異なります。現行挙動ならコードや実行結果、正式な仕様なら仕様書、契約なら契約文書、過去の判断なら設計記録や議事録を確認します。人やAIの回答はそれらの説明であり、可能なら元の根拠へ戻ります。

人の情報提供・判断・承認を分ける

人間の関与を「最後に毎回確認する」だけにしません。背景を提供する人、根拠の矛盾や例外を判断する人、権限を持って承認する人では役割が異なります。同じ人が複数を担う場合も、どの立場で何を確定したかを分けます。責任ある承認が必要な処理は、調査主体の選択とは別に管理します。

この責任設計はAI出力の責任境界とHITL、保守の検証条件はなぜAIは新規コードよりコード保守に強いのかで整理しています。

AI活用の出発点は、問いに必要なコンテキストです。人への問い合わせをゼロにするのではなく、確定できた事実と不足する情報を分け、問い合わせるべき問いを絞ります。調査を速めることと、開発品質を保証することも分けて評価します。