2026 年の AI サービスを見ようとすると、最初に混乱するのは名前の多さである。ChatGPT、Claude、Gemini、Microsoft 365 Copilot、GitHub Copilot、Codex、Claude Code、Devin、Cursor、Perplexity、Mistral、DeepSeek、Llama、Grok。どれも AI と呼ばれる。しかし、これらは同じ階層の製品ではない。あるものは基盤モデルであり、あるものはチャットサービスであり、あるものは API であり、あるものは開発作業を進めるエージェントであり、あるものは企業内データや業務アプリに接続する基盤である。ここでいうエージェントとは、人間の指示を受けて、調査、編集、実行、確認のような複数の手順を進める AI のことである。したがって、名前だけを横に並べて「どれが一番よいか」と比べると、最初から比較対象を取り違える。
たとえば、GPT-5.5 や Claude Sonnet 5 は、文章、コード、画像、長文文脈、外部ツール呼び出しなどを扱う基盤モデルである。一方、ChatGPT や Claude は、利用者がファイルを読み込ませたり、会話を継続したり、プロジェクト単位で文脈を保ったりするサービスである。Codex、Claude Code、GitHub Copilot クラウド上のエージェント、Devin、Cursor は、モデルを使ってリポジトリを読み、ファイルを編集し、テストを実行し、Pull Request に近い単位まで作業を進める実行環境である。Microsoft 365 Copilot は、モデル単体よりも Microsoft Graph、Teams、Outlook、SharePoint、Word、Excel などの業務データと権限体系に埋め込まれている点が本質になる。Perplexity は、汎用チャットというより、検索、引用、URL 取得、複数ソース統合に重点を置く調査基盤である。
本稿は、2026 年 7 月時点の最新 AI モデルと関連サービスを、単なる性能ランキングとしてではなく、仕様、役割、実行環境、統制方法の変化として整理する。中心に置くのは ChatGPT / OpenAI と Claude / Anthropic である。この 2 系統は、汎用 AI の主軸であり、ほかのサービスを比較するときの基準にもなる。OpenAI は、ChatGPT、API、Codex、Apps SDK、外部ツール、コネクタを束ね、広い業務を AI 上で進める方向へ向かっている。Anthropic は、Claude Sonnet 5、Claude Opus 4.8、Claude Fable 5、Claude Mythos 5、Claude Code、MCP コネクタを通じて、長時間作業、高信頼なコード処理、能力境界の管理を前面に出している。MCP は、AI と外部ツールやデータソースを共通の方式で接続するための規格である。
ただし、本稿は ChatGPT と Claude だけを扱うものではない。Gemini、Microsoft 365 Copilot、GitHub Copilot、Devin、Cursor、Perplexity、Mistral、DeepSeek、Llama、xAI も、2026 年時点の記録として残す価値がある。これらを主論と同じ深さで論じると焦点が散るが、仕様台帳として整理しておかなければ、後から見直したときに当時の全体像が失われる。そこで本稿では、主論を ChatGPT / OpenAI と Claude / Anthropic に置きながら、ほかのサービスも比較対象として記録する。役割は明確に分ける。主軸は汎用 AI の構造変化を説明するために使い、周辺サービスは、その構造変化が開発、企業業務、調査、低コスト API、自前運用へどのように分岐しているかを確認するために使う。API は、アプリケーションや業務システムから AI を呼び出すための接続口である。
本稿の中心命題は、次の一点である。最新 AI モデルの比較で重要なのは、もはや「どのモデルが一番賢いか」だけではない。もちろん、推論能力、コード能力、長文処理能力、マルチモーダル処理能力は重要である。マルチモーダル処理とは、文章だけでなく、画像、音声、動画、PDF など複数種類の入力を扱う能力である。また、トークンとは AI が文章を処理するときの細かな単位であり、日本語の一文字や単語と完全に一致するものではない。2026 年時点で問われているのは、最大入力トークン数はいくつか、最大出力トークン数はいくつか、推論の深さを制御できるか、外部ツールを呼び出せるか、ファイルを読めるか、コードを編集できるか、テストを実行できるか、社内データの権限を守れるか、危険な能力をどの境界で止められるか、利用量と費用を管理できるかである。AI は、文章を返す道具から、作業を進める基盤へ移りつつある。
この見方は、既稿で整理した「生成 AI の競争軸は、モデルから業務実装へ移る」という見立ての技術仕様版である[1]。また、AI を使う前に人間が問題設定、判断軸、優先順位、任せない領域を決める必要があるという既稿の議論とも接続する[2]。さらに、Claude Mythos をめぐる既稿では、AI が新しい不整合を作るというより、既存の不整合を高解像度で観測する装置になるという構造を扱った[3]。Fable 5 / Mythos 5 の再配備問題を扱った既稿では、誰に使わせるかだけでなく、その境界を API、アカウント、社員、顧客、クラウド、監査の各層で実装できるかが問題になると整理した[4]。本稿は、これらの既稿を受けて、2026 年時点の AI サービス全体を、モデル性能、実行環境、業務接続、能力境界の四つの層から見直す位置にある。
そのため、本稿では抽象的な印象ではなく、できるだけ確認可能な仕様を残す。特に一覧表では、単に「強い」「弱い」といった評価を避け、最大入力トークン数、最大出力トークン数、ツール対応、エージェント実行、データ接続、統制機能、価格単位、提供範囲といった定量または準定量の確認項目を置く。AI サービスの仕様は変化が速い。だからこそ、結論だけでなく、どの項目を見てそう判断したのかを記録しておく必要がある。
1. 最新 AI モデルは、もうモデル名だけではわからない
最初に確認すべきなのは、2026 年の AI 比較では、比較対象の階層が混ざりやすいという点である。GPT-5.5 や Claude Sonnet 5 はモデル名である。一方、ChatGPT や Claude は利用者が接するサービス名である。Codex、Claude Code、GitHub Copilot クラウド上のエージェント、Devin、Cursor は、モデルを使って開発作業を進める実行環境である。Microsoft 365 Copilot や Gemini Enterprise は、企業データや業務アプリに埋め込まれた AI 基盤である。Perplexity は、汎用チャットというより検索、引用、調査統合に重点を置く。これらを同じ表で比較することはできるが、その場合は、同じ物差しで横一列に採点するのではなく、まず何を比較しているのかを分解しなければならない。
この区別をしないまま「どの AI がよいか」と考えると、議論はすぐに曖昧になる。長文推論に強いモデルであっても、社内ファイルに安全に接続できなければ企業業務では使いにくい。リポジトリ修正に強い開発エージェントであっても、引用付き調査や法務文書の整理に向くとは限らない。検索に強い AI であっても、巨大コードベースを読み、分岐を作り、テストを実行し、Pull Request の形にまとめられるとは限らない。つまり、能力の種類と利用環境が一致していなければ、単体性能は実務上の価値へ直結しない。
この混乱の直接原因は、モデル能力が上がったことで、AI の用途が文章生成から作業実行へ広がったことにある。以前の利用では、質問に答える、文章を直す、要約する、短いコード片を書くといった単発作業が中心だった。この段階では、モデルの応答品質を見れば、かなりの範囲で比較できた。しかし現在は、ファイルを読む、外部サービスを検索する、コードを編集する、テストを実行する、Pull Request を作る、社内データを参照する、ユーザー権限を守る、危険な要求を拒否するところまで含まれる。比較対象が、モデルの言語能力から、実行環境全体へ広がったのである。
| 分類 | 具体例 | 主な役割 | 定量的に確認すべき項目 | 誤比較しやすい点 |
|---|---|---|---|---|
| 基盤モデル | GPT-5.5、Claude Sonnet 5、Claude Opus 4.8、Gemini 3.1 Pro など。 | 文章生成、推論、コード生成、長文処理、画像や音声を含む入力処理など、AI の基本能力を担う。 | 最大入力トークン数、最大出力トークン数、知識の基準日、推論制御、対応モダリティ、API 単価、ベンチマーク結果を確認する。 | チャット画面や開発エージェントの使いやすさまで、モデル単体の性能として評価してしまいやすい。 |
| チャットサービス | ChatGPT、Claude、Gemini アプリなど。 | 利用者が会話、ファイル、プロジェクト、記憶、外部コネクタを通じて AI を使う作業面を提供する。 | 利用可能モデル、ファイル上限、会話履歴の扱い、プロジェクト機能、メモリ機能、外部コネクタ数、プラン別制限を確認する。 | 背後のモデルが同じでも、サービス側のファイル処理、記憶、接続機能によって実用性が変わる点を見落としやすい。 |
| API | OpenAI API、Anthropic API、Gemini API、DeepSeek API、xAI API など。 | 開発者が自社アプリ、業務システム、エージェント基盤にモデルを組み込むための実行インターフェースを提供する。 | 一度に扱える文脈量、最大出力、入力単価、出力単価、キャッシュ済み入力単価、一括処理対応、呼び出し上限、ツール利用、データ保持条件を確認する。 | チャットサービスで使える機能が、そのまま API でも使えると考えてしまいやすい。 |
| 開発エージェント | Codex、Claude Code、GitHub Copilot クラウド上のエージェント、Devin、Cursor など。 | リポジトリを読み、作業計画を立て、ファイルを変更し、テストやレビューに近い工程まで開発作業を進める。 | リポジトリアクセス、同時実行数、実行環境、テスト実行可否、ブランチ作成、Pull Request 作成、継続的インテグレーション連携、ログ、権限管理を確認する。 | コード生成能力だけを見て、実行環境、検証、変更履歴、レビュー可能性を見落としやすい。 |
| 業務プラットフォーム | Microsoft 365 Copilot、Copilot Studio、Gemini Enterprise など。 | メール、予定表、文書、チャット、社内ファイル、業務アプリを、組織の権限体系に従って AI から扱えるようにする。 | 接続可能な業務データ、ID 連携、権限継承、監査ログ、管理者制御、データ保持、テナント分離、外部コネクタを確認する。 | 基盤モデルの賢さだけで、企業内業務で使えるかを判断してしまいやすい。 |
| 調査特化基盤 | Perplexity Sonar、Sonar Deep Research、Agent API など。 | 検索、引用、URL 取得、複数ソース統合、調査レポート生成を通じて、最新情報に基づく回答を作る。 | 検索回数、引用提示、URL 取得、文脈量、調査レポート生成、検索単価、対応モデル、出典追跡性を確認する。 | 検索と引用に強いことを、コード修正や業務アプリ操作まで強いことと混同しやすい。 |
| 重み公開型・自前運用系 | Mistral、DeepSeek、Llama 系など。 | 閉鎖型クラウド型サービスではなく、自前運用、低コスト運用、改変可能性、データ主権を重視する利用に向く。 | ライセンス、重み公開の有無、必要 GPU、一度に扱える文脈量、推論単価、追加調整可否、商用利用条件を確認する。 | 統合クラウド型サービスと同じ使い勝手を期待すると、運用、監視、セキュリティ、評価を自前で担う負担を見落としやすい。 |
この表が示すように、AI サービスの比較では、まず分類を決める必要がある。基盤モデルには、最大入力トークン数や最大出力トークン数といったモデル仕様がある。API には、単価、レート制限、データ保持、ツール呼び出しといった開発者向け仕様がある。開発エージェントには、リポジトリを読めるか、テストを実行できるか、Pull Request に近い形で変更をまとめられるかという作業仕様がある。業務プラットフォームには、社内権限を継承できるか、監査ログを残せるか、管理者が利用範囲を制御できるかという統制仕様がある。これらは互いに関連するが、同じものではない。
ここで重要なのは、比較対象を分解することが、議論を細かくしすぎるためではないという点である。むしろ、分解しなければ、実務上の判断が粗くなる。たとえば「Claude は長文に強い」という評価だけでは、Claude のどのモデルを使うのか、チャットサービスとして使うのか、Claude Code として使うのか、API で使うのか、MCP コネクタを接続するのかがわからない。「ChatGPT は便利である」という評価だけでは、GPT-5.5 のモデル仕様、ChatGPT Projects、Codex、Apps SDK、外部コネクタ、組織管理のどれが便利さを生んでいるのかが見えない。分類は、評価を複雑にするためではなく、評価の根拠を失わないために必要である。
| 観点 | 単純な見方 | 仕様として見るべき問い | 実務上の判断に効く理由 |
|---|---|---|---|
| モデル性能 | どのモデルが一番賢いかを見る。 | どのタスクで、どの推論深度で、どの入力長と出力長の条件で性能が出るのかを見る。 | 短い質問に強いモデルが、長文文書、巨大コードベース、複数ツール利用でも同じように強いとは限らない。 |
| コンテキスト | 最大入力トークン数が大きいほどよいと見る。 | 長文入力時の精度、検索併用、圧縮、キャッシュ、履歴管理、最大出力との組み合わせを見る。 | 1M トークンを入れられても、必要な箇所を正しく参照できなければ、実務上の価値は下がる。 |
| ツール利用 | 外部ツールに対応していれば十分と見る。 | Web 検索、ファイル検索、関数呼び出し、画面操作、コード実行、MCP のどれに対応し、どこまで自動実行できるかを見る。 | 調査、文書処理、コード修正、画面操作では、必要なツールの種類と実行権限が異なる。 |
| エージェント性 | AI が自律的に作業できるかを見る。 | 計画、実行、検証、失敗時の復旧、ログ、レビュー可能性、人間の承認点をどこに置くかを見る。 | 長時間作業では、単に動くことよりも、失敗したときに止まり、説明し、戻せることが重要になる。 |
| 業務接続 | 社内データを読めればよいと見る。 | ID、権限、部署、テナント、ファイル権限、監査ログ、管理者制御が維持されるかを見る。 | AI が便利でも、本来見てはいけない情報を読めるなら、企業内では使いにくい。 |
| 能力境界 | 危険な要求を拒否できればよいと見る。 | 利用者、組織、用途、地域、モデル ID、API キー、別モデルへの切り替え、監査、緊急停止をどう組み合わせるかを見る。 | 高能力モデルでは、能力を公開するか止めるかだけでなく、誰にどの条件で配分するかが問題になる。 |
| 経済性 | API 単価が安いほどよいと見る。 | 入力、出力、キャッシュ済み入力、一括処理、優先処理、検索課金、エージェント実行時間、同時実行、利用量上限を合わせて見る。 | 長文、検索、エージェント実行では、単価表だけでなく、実際のトークン消費と実行回数が費用を決める。 |
このように見ると、2026 年の AI 比較は、従来の「モデル性能の比較」から、より複合的な「作業成立条件の比較」へ変わっている。基盤モデルは頭脳に相当する。しかし、実務で必要なのは頭脳だけではない。長い文脈を置く記憶、外部情報を読む目、ファイルやコードを操作する手、権限を守る境界、後から確認できるログ、失敗時に戻れる手順が必要である。これらが揃ってはじめて、AI は単なる回答器ではなく、作業基盤として機能する。
したがって、最新 AI を見るときの背後構造は、モデルの単体性能ではなく、モデルを取り巻く実行環境の変化である。AI は、単独で答える存在ではなく、道具、データ、ファイル、アプリ、権限、監査、実行環境と結びついて価値を出す存在になっている。より広く言えば、2026 年の AI 比較は「頭脳の比較」から「作業基盤の比較」へ移っている。以降では、この見方を前提に、まず ChatGPT / OpenAI と Claude / Anthropic を詳しく見ていく。そのうえで、Gemini、Microsoft 365 Copilot、GitHub Copilot、Devin、Cursor、Perplexity、Mistral、DeepSeek、Llama、xAI を、同じ地図の中で位置づける。
2. 2026 年の AI は何を比べるべきか
では、2026 年時点の AI サービスは、具体的に何を比べればよいのか。従来の比較では、推論ベンチマーク、コードベンチマーク、数学、知識量、回答品質が中心だった。これらは今でも重要である。基盤モデルの能力が低ければ、長文を渡しても、ツールを与えても、業務データに接続しても、最終的な判断や生成物の品質は上がらない。しかし、モデル能力だけでは、実務上の違いを十分に説明できない。2026 年の AI は、回答するだけでなく、検索し、ファイルを読み、コードを変更し、外部サービスに接続し、社内権限を守り、場合によっては危険な能力を制限しながら動くからである。
ここで比較すべき対象は、単一の点数ではなく、作業が成立する条件である。たとえば、2 つのモデルが同じ 1M トークン文脈を持っていたとしても、同じ価値を持つとは限らない。長文から必要箇所を安定して取り出せるか、不要な履歴に引きずられないか、外部ファイルを必要なときに読み直せるか、検索結果を検証できるか、古い会話を圧縮できるか、出力を長く保てるかは別問題である。最大入力トークン数は重要な仕様だが、それだけでは長文作業の品質は決まらない。
本稿では、評価軸を 9 つに分ける。第一にモデル能力、第二にコンテキスト、第三に推論制御、第四にツール実行、第五にエージェント実行、第六に業務接続、第七に統制、第八に能力境界、第九に経済性である。この順序には意味がある。まず基盤モデルの能力があり、その上に長文処理があり、その上に推論深度の調整があり、さらに外部ツールやエージェント実行が乗る。業務に入ると、データ接続と統制が必要になり、高リスク領域では能力境界が問題になる。最後に、それらを継続利用できるかを経済性が決める。
ここでいう文脈とは、モデルが応答を生成するときに参照できる作業記憶である。これは訓練データ全体ではない。会話履歴、入力文書、ツール結果、画像、ファイル、モデル自身の途中出力などが、一定のトークン上限の中に入る。文脈が長いほど大量の資料を渡せるが、長ければ長いほど必ずよいわけではない。重要なのは、長文を入れられることではなく、必要な情報を取り出し、不要な情報に引きずられず、作業の途中で適切に再利用できることである。したがって、文脈は「容量」だけでなく、「検索」「圧縮」「再利用」「出力長」と一体で見る必要がある。
ツール利用も同じである。関数呼び出し、Web 検索、ファイル検索、画面操作、コード実行、MCP などの言葉が並ぶが、本質は、モデルが外部の情報源や操作手段を使えるようになることにある。これにより、AI は内部知識だけで答えるのではなく、必要に応じて検索し、ファイルを読み、プログラムを実行し、外部アプリへ指示を送れるようになる。ただし、ツールが増えるほど、誤操作、過剰実行、権限逸脱、ログ管理、コスト管理の問題も増える。つまり、ツール対応は単純な加点項目ではなく、作業能力と統制リスクの両方を増やす要素である。
| 評価軸 | 見るべき内容 | 定量的に記録すべき項目 | 比較時の問い | 実務上の意味 |
|---|---|---|---|---|
| モデル能力 | 推論、コード、数学、専門知識、マルチモーダル処理を確認する。 | 主要ベンチマーク、対応モダリティ、知識の基準日、入力形式、出力形式を記録する。 | 単発回答、専門的推論、コード生成、画像や PDF を含む入力で、どの程度安定して答えられるかを見る。 | AI の基本性能の上限を決める。ここが弱いと、ツールやエージェントを加えても最終成果物の品質は安定しにくい。 |
| コンテキスト | 入力トークン、最大出力、長文精度、検索した外部文書を回答に使う仕組み、記憶、圧縮、キャッシュを確認する。 | 最大入力トークン数、最大出力トークン数、ファイル上限、検索対象、キャッシュ有無、長文時の価格変化を記録する。 | 長い資料、会議履歴、仕様書、コードベースを渡したとき、必要な情報を正しく取り出せるかを見る。 | 長文作業、調査、契約書確認、設計書レビュー、コードベース理解の実用性を左右する。 |
| 推論制御 | 推論量設定、推論モード、速度、精度、コストの調整を確認する。 | 推論レベルの種類、既定値、指定可否、追加課金、応答速度への影響を記録する。 | 軽い要約と重い設計判断で、同じモデルを異なる深度で使い分けられるかを見る。 | 単純作業では速く安く、高難度作業では深く考えさせるという運用が可能になる。 |
| ツール実行 | 関数呼び出し、Web 検索、ファイル検索、画面操作、コード実行、MCP を確認する。 | 対応ツール種別、外部検索可否、ファイル検索可否、コード実行可否、画面操作可否、MCP 対応、ツール単価を記録する。 | AI が内部知識だけで答えるのか、外部情報を読み、操作し、検証できるのかを見る。 | 調査、文書処理、データ分析、コード修正、業務アプリ操作を AI に任せられる範囲を決める。 |
| エージェント実行 | Codex、Claude Code、GitHub Copilot クラウド上のエージェント、Devin、Cursor などの実行面を確認する。 | 実行環境、同時実行数、最大作業時間、リポジトリアクセス、ファイル編集、テスト実行、ブランチ作成、Pull Request 作成、ログ保存を記録する。 | AI が計画、実行、検証、失敗時の復旧、作業結果の提示まで進められるかを見る。 | 単発のコード生成ではなく、実際の開発作業や長時間タスクを委譲できるかを決める。 |
| 業務接続 | Google Drive、SharePoint、Slack、GitHub、M365、MCP などへの接続を確認する。 | 接続可能サービス数、検索対象、読み取り権限、書き込み権限、リアルタイム取得、インデックス方式、外部コネクタ対応を記録する。 | AI が社内情報や業務データを、利用者の権限に従って扱えるかを見る。 | 企業内で使う場合、社内文書、メール、チャット、リポジトリ、CRM、チケット管理への接続が価値を決める。 |
| 統制 | シングルサインオン、ユーザー管理連携、監査、データ保持、権限継承、管理者制御を確認する。 | シングルサインオン対応、ユーザー管理連携対応、監査ログ、データ保持期間、学習利用設定、管理者ポリシー、ユーザー権限、テナント分離を記録する。 | 組織で正式導入したとき、誰が何を使い、何にアクセスし、何を出力したかを後から説明できるかを見る。 | 企業導入、法務、セキュリティ、監査、内部統制の前提になる。 |
| 能力境界 | 誰が、何を、どの目的で、どの領域まで使えるかを確認する。 | 提供対象、利用資格、地域制限、用途制限、危険領域の分類、別モデルへの切り替え、追加審査、データ保持、緊急停止手段を記録する。 | サイバー、バイオ、化学、重要インフラなどの高リスク用途で、能力をどこまで出し、どこで止めるかを見る。 | 高能力モデルでは、公開するか禁止するかだけでなく、能力を条件付きで配分できるかが重要になる。 |
| 経済性 | トークン価格、キャッシュ済み入力、一括処理、優先処理、検索課金、エージェント実行費用、利用量管理を確認する。 | 入力単価、出力単価、キャッシュ済み入力単価、一括処理割引、優先処理課金、検索単価、月額料金、利用量上限を記録する。 | 試用ではなく、組織や開発基盤として継続利用できる費用構造かを見る。 | 長文、検索、エージェント実行ではトークン消費が大きくなるため、単価と実行回数が採用可能性を左右する。 |
この表の役割は、評価項目を増やすことそのものではない。重要なのは、比較の単位を明確にすることである。モデル能力は、AI の認知能力に近い。コンテキストは、作業記憶に近い。ツール実行は、外部世界に触れる手段である。エージェント実行は、作業を段階的に進める足場である。業務接続と統制は、企業組織の中で使うための条件である。能力境界は、高能力化した AI を社会的に扱うための制動装置である。経済性は、それらを継続利用できるかを決める制約である。
この評価軸で見ると、主要サービスの違いはかなり明確になる。ChatGPT / OpenAI は、モデル、ツール、アプリ、Codex、コネクタを広く束ね、汎用の作業実行基盤に近づいている。Claude / Anthropic は、長文、コード、長時間作業、MCP コネクタ、Fable 5 / Mythos 5 に見られる能力境界管理で特徴が出る。Gemini は、Google Search、Workspace、Cloud、マルチモーダル処理との統合に強みがある。Microsoft 365 Copilot は、モデルそのものより、Microsoft Graph、M365 データ、ID、権限、監査との接続が本質になる。GitHub Copilot、Devin、Cursor は、開発作業をどこまで実行環境として扱えるかで評価するべきである。Perplexity は、検索、引用、調査統合の専門基盤として見るのが適切である。Mistral、DeepSeek、Llama、xAI は、重み公開型、低コスト API、自前運用、データ主権、リアルタイム性といった別の軸で意味を持つ。
| 対象 | 主に強く見る評価軸 | 比較上の位置づけ | 採用判断で見るべき根拠 |
|---|---|---|---|
| ChatGPT / OpenAI | モデル能力、ツール実行、エージェント実行、業務接続、経済性。 | 汎用 AI を広い作業基盤として使う場合の主軸になる。 | GPT-5.5 系のモデル仕様、Responses API、ツール、Apps SDK、Codex、Projects、外部コネクタ、API 単価を合わせて確認する。 |
| Claude / Anthropic | モデル能力、コンテキスト、推論制御、エージェント実行、統制、能力境界。 | 長文、コード、慎重な知的作業、高信頼なエージェント実行で主軸になる。 | Sonnet 5、Opus 4.8、Fable 5、Mythos 5、Claude Code、MCP コネクタ、Enterprise 統制、別モデルへ処理を切り替える設計を確認する。 |
| Gemini / Google | モデル能力、コンテキスト、マルチモーダル、業務接続、検索連携。 | Google Search、Workspace、Cloud と接続した第三極として見る。 | Gemini 3.1 Pro、Gemini 3.5 系、検索結果に基づく回答補強、URL 文脈、コード実行、Workspace 連携を確認する。 |
| Microsoft 365 Copilot | 業務接続、統制、権限継承、監査、企業内検索。 | 企業内業務では、モデル性能よりも Microsoft 365 のデータ接続と権限体系を評価する対象になる。 | Microsoft Graph、M365 Copilot コネクタ、Copilot Studio、Teams、Outlook、SharePoint、管理者制御を確認する。 |
| GitHub Copilot / Devin / Cursor | エージェント実行、開発統合、ツール実行、ログ、レビュー可能性。 | コード生成 AI ではなく、開発作業をどこまで委譲できるかを見る対象になる。 | リポジトリアクセス、ブランチ作成、ファイル編集、テスト実行、Pull Request 作成、継続的インテグレーション連携、同時実行、作業ログを確認する。 |
| Perplexity | 検索、引用、URL 取得、調査レポート生成、検索課金。 | 汎用チャットの代替ではなく、最新情報の調査と出典付き統合の専門基盤として見る。 | Sonar、Sonar Deep Research、Agent API、検索回数、引用提示、URL 取得、対応モデル、検索単価を確認する。 |
| Mistral / DeepSeek / Llama / xAI | 経済性、重み公開型、自前運用、低コスト API、リアルタイム性。 | 閉鎖型統合クラウド型サービスとは別に、コスト、独立性、データ主権、改変可能性を担う比較軸になる。 | ライセンス、重み公開、API 単価、一度に扱える文脈量、必要計算資源、商用利用条件、運用負担を確認する。 |
この整理から分かるのは、AI 比較が単なるモデル比較でなくなったことである。モデルが強くなるほど、実務に入り込む範囲が広がる。実務に入り込むほど、権限、監査、費用、データ接続、安全制御が重要になる。つまり、AI の能力向上は、比較軸を狭めるのではなく、むしろ広げている。高度なモデルが登場したから比較が簡単になるのではない。高度なモデルが、外部ツール、企業データ、開発環境、高リスク領域へ接続されることで、比較しなければならない層が増えるのである。
したがって、本稿の比較は、単純な総合順位を出すためのものではない。用途ごとに、どの評価軸が支配的になるかを見極めるための比較である。広い業務を AI 上で処理したいなら、ChatGPT / OpenAI のツールと作業基盤が重要になる。長文文書、コードベース、慎重な推論、能力境界を重視するなら、Claude / Anthropic の設計が重要になる。Google Workspace や Microsoft 365 に深く依存する組織では、Gemini や Microsoft 365 Copilot の業務接続が強い意味を持つ。開発作業では、モデルの賢さよりも、実行環境、検証、ログ、レビュー可能性が効く。調査では、検索と引用が効く。自前運用では、重み公開型、ライセンス、コスト、運用負担が効く。
より広く言えば、2026 年の AI を評価するとは、「最も賢いモデル」を一つ選ぶことではない。作業の種類、扱うデータ、必要な権限、許容できるコスト、求める説明可能性、危険領域の有無に応じて、支配的な評価軸を切り替えることである。以降の章では、この評価軸に従って、まず ChatGPT / OpenAI と Claude / Anthropic を詳しく見る。そのうえで、ほかの AI サービスを、同じ比較地図の中で位置づける。
3. ChatGPT / OpenAI は、業務 OS 化する汎用 AI である
OpenAI 側を見るときに最初に分けるべきなのは、GPT-5.5 というモデルそのものと、それを利用する ChatGPT、API、ツール、Apps SDK、Codex、コネクタである。GPT-5.5 は OpenAI の最先端モデルであり、複雑な目標を理解し、長い文脈を扱い、ツールを使いながら作業を進めるための中核モデルとして位置づけられている[5]。API 仕様では、一度に扱える文脈量、最大出力、推論制御、対応ツール、価格が明示されており、単なるチャット品質ではなく、実務アプリケーションに組み込むための仕様として整理されている[6]。
この章で確認する評価軸は、五つある。第一に、GPT-5.5 がどの程度の入力、出力、推論制御を持つかである。第二に、Responses API とツールが、モデルを外部情報や操作手段へどう接続するかである。第三に、Apps SDK が、ChatGPT を外部アプリの実行面としてどう拡張するかである。第四に、Codex が、開発作業をどこまで実行可能な作業単位に変えるかである。第五に、これらを合わせたとき、OpenAI が単なるモデル提供ではなく、広い業務を AI 上で進める作業基盤へ向かっているかである。
| 評価対象 | 階層 | 確認すべき仕様 | 比較上の意味 | 本章での評価結果 |
|---|---|---|---|---|
| GPT-5.5 | 基盤モデル | 一度に扱える文脈量、最大出力、推論制御、対応モダリティ、対応ツール、API 単価を確認する。 | OpenAI 系の作業能力の上限を決める。 | 単発回答よりも、長文、コード、調査、複数ツール利用を含む専門的な実務作業向けの中核モデルとして読むべきである。 |
| Responses API | API 実行面 | モデル出力、推論、ツール呼び出し、状態管理、開発者向け統合方法を確認する。 | モデルを自社アプリや業務システムへ組み込めるかを決める。 | OpenAI をチャットサービスではなく、アプリケーション基盤として使うための中心になる。 |
| ツール | 外部接続 | 関数呼び出し、Web 検索、ファイル検索、画面操作、遠隔 MCP などの対応範囲を確認する。 | AI が内部知識だけでなく、外部情報や操作手段を使えるかを決める。 | 回答生成器から作業実行器へ移るための直接的な機能群である。 |
| Apps SDK | ChatGPT 拡張 | ChatGPT 内で外部アプリのツールと画面部品を接続できるかを確認する。 | ChatGPT が単なる会話欄ではなく、作業画面として使えるかを決める。 | ChatGPT を外部アプリのホストに近づける機能であり、業務 OS 化を示す重要な要素である。 |
| Codex | 開発エージェント | コード読解、編集、実行、並列作業、クラウド環境、作業ログ、レビュー可能性を確認する。 | AI がコード補完を超えて、開発作業を委譲できるかを決める。 | OpenAI のエージェント化を最も具体的に示す実行環境である。 |
GPT-5.5 の仕様でまず見るべきなのは、入力と出力の規模である。API 仕様では、GPT-5.5 は 1M トークン級の一度に扱える文脈量と 128K トークン級の最大出力を持つモデルとして扱われている[6]。この数字は、短い質問に答えるだけのモデルではなく、長い仕様書、複数の文書、調査資料、コード断片、ツール結果をまとめて扱う前提の仕様である。ただし、ここで重要なのは、1M トークンという容量だけではない。長い文脈を扱うには、どの情報を入れるか、どの情報を検索で後から読むか、どの出力を検証するか、どの推論深度で処理するかが同時に問題になる。
| 仕様項目 | GPT-5.5 で確認すべき内容 | 定量的な記録項目 | 実務上の意味 | 比較時の注意点 |
|---|---|---|---|---|
| 入力規模 | 長い文書、会話履歴、ツール結果、ファイル内容をどこまで文脈に入れられるかを見る。 | 最大入力トークン数、ファイル入力の扱い、検索併用の可否を記録する。 | 仕様書、議事録、契約書、調査資料、コードベースを扱う作業に効く。 | 最大入力が大きくても、長文内の必要箇所を安定して参照できるとは限らない。 |
| 出力規模 | 長いレポート、設計書、コード、表形式の整理をどこまで一度に出力できるかを見る。 | 最大出力トークン数、長大出力時の品質、途中停止時の扱いを記録する。 | 単発回答ではなく、まとまった成果物を生成する作業に効く。 | 出力上限が大きくても、構成が崩れたり、後半で反復が増えたりする場合がある。 |
| 推論制御 | 軽い作業と重い作業で、推論量を切り替えられるかを見る。 | 推論量設定の段階、指定可否、既定値、コストと速度への影響を記録する。 | 要約、分類、設計判断、コード修正、調査のように重さの違う作業を同じ基盤で扱いやすくなる。 | 推論を深くすれば常に良いわけではなく、費用、応答速度、過剰検討との均衡が必要になる。 |
| ツール対応 | 外部検索、ファイル検索、関数呼び出し、画面操作、MCP 連携をどこまで使えるかを見る。 | 関数呼び出し、Web 検索、ファイル検索、画面操作、遠隔 MCP の対応状況を記録する。 | AI が内部知識だけでなく、外部情報を読み、操作し、検証する作業に効く。 | ツールが多いほど便利だが、誤操作、権限、監査、費用の管理も必要になる。 |
| 価格 | 大規模入力、大規模出力、ツール利用を継続的に使える費用構造かを見る。 | 入力単価、出力単価、キャッシュ済み入力単価、一括処理や優先処理の有無を記録する。 | 試用ではなく、組織やサービスに組み込む場合の採算性を左右する。 | 単価だけでなく、実際のトークン消費量、検索回数、エージェント実行回数を合わせて見る必要がある。 |
推論制御は、OpenAI の方向性を読むうえで重要である。OpenAI は推論を重視したモデルの仕組みを通じて、用途に応じた推論量の制御を用意している[7]。これは、すべての依頼に最大限深く考えさせるという設計ではない。軽い分類、短い要約、定型的な変換では速さと費用が重要になる。一方、設計判断、障害原因の切り分け、複雑なコード修正、長文調査では、時間と費用をかけてでも深い推論が必要になる。つまり、推論制御は単なる性能調整ではなく、作業の重さに応じて AI の使い方を切り替えるための運用仕様である。
ツールの仕様は、OpenAI を回答生成器から作業実行器へ変える部分である。OpenAI のツールでは、関数呼び出し、Web 検索、ファイル検索、画面操作、遠隔 MCP などを組み合わせ、モデルが外部の情報源や操作手段を使えるようになっている[8]。関数呼び出しは、モデルが外部システムに渡す検索条件や操作内容を、決まった形式で出力するための仕組みである。Web 検索は最新情報の取得に使われる。ファイル検索は手元の文書やナレッジベースを参照するために使われる。画面操作は、画面やアプリケーションを操作する方向の機能である。MCP は、外部ツールやデータソースを共通の形で接続するための規格として機能する。
| ツール種別 | 役割 | 向く作業 | 確認すべき定量項目 | 統制上の注意点 |
|---|---|---|---|---|
| 関数呼び出し | 外部システムに渡す操作や検索条件を、構造化された形で生成する。 | 業務システム連携、データ取得、チケット作成、社内 API 呼び出しに向く。 | 対応モデル、JSON 形式の定義対応、並列呼び出し、失敗時の再試行方法を確認する。 | モデルが作った引数をそのまま実行すると、誤操作や過剰実行が起きる可能性がある。 |
| Web 検索 | モデルの内部知識だけに頼らず、外部 Web から最新情報を取得する。 | ニュース、価格、仕様変更、公式発表、規制、ソフトウェア更新の確認に向く。 | 検索回数、検索単価、引用提示、検索対象、検索結果の保持方法を確認する。 | 検索結果の品質、情報源の信頼性、古い情報の混入を確認する必要がある。 |
| ファイル検索 | アップロードされた文書やナレッジベースから、必要な情報を検索して利用する。 | 社内文書、仕様書、議事録、契約書、FAQ、研究資料の参照に向く。 | ファイル数、容量、検索対象、更新反映、引用単位、権限管理を確認する。 | 検索に出なかった情報を存在しないものとして扱う誤りに注意が必要である。 |
| 画面操作 | モデルが画面やアプリケーションを操作するための実行手段を提供する。 | ブラウザ操作、業務画面操作、画面上の定型作業、複数アプリをまたぐ作業に向く。 | 操作範囲、確認プロンプト、失敗時の停止条件、スクリーンショット利用、実行ログを確認する。 | 便利さと同時に、誤クリック、権限逸脱、意図しない送信や削除のリスクが増える。 |
| 遠隔 MCP | 外部ツールやデータソースを、共通のプロトコルでモデルへ接続する。 | 複数システム連携、社内ツール統合、独自業務アプリ接続、開発環境接続に向く。 | 接続可能サーバー、認証方式、対応ツール数、ログ、管理者制御、権限継承を確認する。 | 接続先が増えるほど、どのツールが何を実行できるかを管理しなければならない。 |
Apps SDK も同じ方向にある。Apps SDK は、ChatGPT の中に外部アプリのツールと画面部品を接続する仕組みであり、MCP を基盤としている[9]。ここで重要なのは、外部アプリを単に呼び出すだけではない点である。ChatGPT の会話の中で必要なツールを呼び、必要に応じて画面部品を表示し、利用者がその場で確認や操作を行えるようにする。これは、ChatGPT を単なる会話欄ではなく、作業の入口、操作の仲介面、アプリケーションのホストへ近づける。
この方向性を「業務 OS 化」と呼ぶことができる。OS という表現は比喩であり、ChatGPT が文字どおりオペレーティングシステムになるという意味ではない。ここでいう業務 OS 化とは、文書、表、検索、ファイル、コード、外部アプリ、画面部品、業務システムを、ChatGPT を入口として横断的に扱えるようになることを指す。従来のアプリケーションは、それぞれ独立した画面と操作体系を持っていた。ChatGPT が外部アプリのツールと画面部品を抱え込むと、利用者は「どのアプリを開くか」ではなく、「何をしたいか」を起点に作業を進めるようになる。
| 観点 | 従来のアプリ中心の作業 | ChatGPT / Apps SDK 型の作業 | 変化の意味 |
|---|---|---|---|
| 作業の入口 | 利用者が個別アプリを開き、画面ごとの操作を覚えて作業する。 | 利用者は目的を伝え、ChatGPT が必要なツールや画面部品を呼び出す。 | 操作の中心が、アプリ名から作業目的へ移る。 |
| データの扱い | 文書、表、検索結果、コード、外部サービスが別々の場所にある。 | 会話文脈の中で、複数データ源を参照しながら作業を進める。 | データを移動するのではなく、AI が必要な情報を取りに行く形に近づく。 |
| 操作の抽象度 | 利用者がボタン、メニュー、入力欄を直接操作する。 | 利用者が目的や条件を伝え、AI が操作候補を組み立てる。 | 作業指示が、画面操作から意図指定へ移る。 |
| 検証 | 利用者が個別アプリの結果を見て判断する。 | AI が中間結果をまとめ、利用者が承認や修正を行う。 | 人間の役割が、逐次操作から判断、承認、採否決定へ寄る。 |
Codex は、この流れをもっとも分かりやすく示す。OpenAI の Codex モデル群では、多くの作業で GPT-5.5 が推奨され、複雑なコード作業、画面操作、知的作業、調査作業に強いと説明されている[10]。Codex の Web 版では、Codex がコードを読み、編集し、実行できるコード作業を進めるエージェントであり、クラウド環境で並列に作業できると説明されている[11]。さらに、Codex 利用の大規模分析では、エージェント型 AI の利用が急速に増え、OpenAI 社内では Codex が ChatGPT の業務利用を大きく置き換えているという観測も示されている[12]。
ここで注意すべきなのは、Codex が単なるコード補完ではないことである。コード補完は、開発者が今書いている行や関数の続きを支援する。一方、Codex 型のエージェントは、作業目標を受け取り、リポジトリを読み、変更箇所を探し、ファイルを編集し、実行し、失敗したら修正し、結果を説明する方向へ進む。これは、開発者の手元を少し速くする機能ではなく、開発作業の一部を委譲可能な単位へ分解する機能である。
| 比較観点 | 従来のコード補完 | Codex 型エージェント | 実務上の評価項目 |
|---|---|---|---|
| 入力 | 編集中のコード、短いコメント、関数名などを手がかりにする。 | 課題、仕様、エラー、リポジトリ全体、関連ファイル、実行結果を手がかりにする。 | どれだけ広い文脈を安全に読めるかを確認する。 |
| 作業単位 | 数行から 1 関数程度の生成や補完が中心である。 | 複数ファイルの変更、テスト修正、調査、実行、説明までを作業単位にできる。 | 複数ファイル変更、依存関係理解、既存設計との整合性を確認する。 |
| 検証 | 生成後の確認は開発者が主に行う。 | AI 自身がコマンド実行やテストを通じて一部検証できる。 | テスト実行、失敗時の再試行、ログ、再現性を確認する。 |
| 並列性 | 開発者の作業中に補助的に動く。 | 複数タスクをクラウド環境で並列に進められる可能性がある。 | 同時実行数、作業キュー、結果の統合方法を確認する。 |
| 人間の役割 | 開発者が実装の主体であり、AI は補助である。 | AI が下書きや変更案を作り、人間がレビュー、採否判断、責任ある統合を行う。 | レビュー可能な差分、説明、元に戻す手順、承認点を確認する。 |
ここまでを総合すると、OpenAI の方向性はかなり明確である。GPT-5.5 は高性能モデルであり、Responses API はそのモデルをアプリケーションへ組み込む実行面であり、ツールは外部情報や操作手段への接続であり、Apps SDK は ChatGPT を外部アプリのホストへ近づける仕組みであり、Codex は開発作業をエージェント化する実行環境である。これらはばらばらの機能ではない。共通しているのは、AI を「答えるもの」から「作業を進めるもの」へ移す方向である。
| 評価軸 | OpenAI で強く見える点 | 実務上の利点 | 注意すべき点 |
|---|---|---|---|
| モデル能力 | GPT-5.5 が長文、コード、複雑推論、ツール利用の中核モデルとして位置づけられている。 | 汎用作業、調査、文書化、コード作業を一つのモデル系統で扱いやすい。 | 高性能モデルは費用が高くなりやすく、軽い作業では過剰になる場合がある。 |
| ツール実行 | 関数呼び出し、Web 検索、ファイル検索、画面操作、遠隔 MCP が用意されている。 | 内部知識だけでなく、外部情報や操作手段を使った作業に広がる。 | ツール実行には誤操作、権限、監査、費用管理が伴う。 |
| 業務接続 | Apps SDK やコネクタにより、ChatGPT が外部アプリやファイルへ接続する方向へ進んでいる。 | 会話、文書、表、検索、業務アプリを横断した作業面を作りやすい。 | 組織導入では、どのデータに誰がアクセスできるかを厳密に管理する必要がある。 |
| エージェント実行 | Codex がコード読解、編集、実行、並列作業を担う実行環境として位置づけられている。 | 開発作業を補完するだけでなく、調査、修正、検証をまとまった単位で委譲しやすい。 | 最終的な設計判断、レビュー、採否判断、責任ある統合は人間側に残る。 |
| 経済性 | モデルごとの価格、キャッシュ済み入力、一括処理、優先処理などで運用調整の余地がある。 | 重い作業には高性能モデル、軽い作業には低コストモデルという使い分けが可能になる。 | 長文、検索、エージェント実行ではトークン消費と実行回数が増え、単価表だけでは費用を読みにくい。 |
ここから分かるのは、OpenAI が ChatGPT を「業務 OS」に近づけているということである。OS という表現は比喩である。ここで言いたいのは、ChatGPT が文章を返す単独アプリではなく、文書、表、コード、検索、ファイル、外部サービス、画面、開発環境を横断する作業面を取りに行っているということである。したがって、ChatGPT を評価するときは、GPT-5.5 のベンチマークだけでなく、そのモデルがどのツール、どのアプリ、どのコネクタ、どの実行環境で使われるのかを見なければならない。
より広く言えば、OpenAI の強みは、特定の単一機能ではなく、機能群を同じ方向へ束ねている点にある。GPT-5.5 は頭脳であり、Responses API は組み込み面であり、ツールは外部世界への接続であり、Apps SDK は作業画面であり、Codex は開発実行面である。この束があるため、OpenAI は「最も賢いモデル」を売っているだけではなく、「AI を使って仕事を進める場所」を作ろうとしている。これが、ChatGPT / OpenAI を 2026 年の汎用 AI 比較の主軸に置くべき理由である。
4. Claude / Anthropic は、高信頼・長時間・能力境界管理の AI である
Anthropic 側を見るときも、まず階層を分ける必要がある。Claude は単一のチャット AI ではない。Claude Sonnet 5、Claude Opus 4.8、Claude Fable 5、Claude Mythos 5 というモデル階層があり、その上に Claude、Claude Code、MCP コネクタ、ツール利用、企業向け管理機能が乗っている。Claude Sonnet 5 は、複数段階のソフトウェア開発、ツール利用、不具合調査と修正、整理されていない技術的文脈に強い実行層として紹介されている[13]。Anthropic のモデル概要では、各モデルの一度に扱える文脈量、最大出力、用途、価格が整理され、Sonnet、Opus、Fable、Mythos の階層が示されている[14]。
この章で確認する評価軸は、六つある。第一に、Sonnet 5 が日常業務とエージェント型の作業の主力主力実務モデルとしてどこまで使えるかである。第二に、Opus 4.8 が複雑推論、長時間コード作業、高自律作業をどこまで担うかである。第三に、Fable 5 と Mythos 5 が示す高能力モデルの提供条件である。第四に、一度に扱える文脈量を単なる容量ではなく、文脈設計としてどう扱うかである。第五に、Claude Code と MCP コネクタが、Claude を開発作業者や外部ツール利用者としてどう拡張するかである。第六に、企業利用や高リスク領域で、統制と能力境界をどう設計しているかである。
| 評価対象 | 階層 | 確認すべき仕様 | 比較上の意味 | 本章での評価結果 |
|---|---|---|---|---|
| Claude Sonnet 5 | 主力モデル | 一度に扱える文脈量、最大出力、価格、コード作業、ツール利用、不具合調査と修正、エージェント型の作業の性能を確認する。 | 日常業務と長時間作業の標準モデルとして使えるかを決める。 | 速度、性能、価格のバランスを取った主力実務モデルであり、Claude 系の実務利用の中心になる。 |
| Claude Opus 4.8 | 上位モデル | 複雑推論、長時間エージェント型のコード作業、高自律作業、慎重な分析への適性を確認する。 | Sonnet 5 では重い作業を、より高い推論能力で処理できるかを決める。 | 高難度な設計判断、複雑なコード作業、長時間の知的作業で使う上位モデルとして読むべきである。 |
| Claude Fable 5 | 一般提供される Mythos 級モデル | 高能力モデルを一般利用向けにどのような安全制御付きで提供しているかを確認する。 | 最上位能力を一般提供する際、安全制御をどう実装するかを示す。 | 能力の高さそのものだけでなく、一般提供時の制限、別モデルへの切り替え、誤検知を評価対象に含める必要がある。 |
| Claude Mythos 5 | 審査済み利用者向けの限定提供向けモデル | Fable 5 と同じ基盤となる同一モデルから一部安全制御を外し、誰にどの目的で提供するかを確認する。 | 高リスク能力を限定配分する設計が実装できるかを決める。 | 単なる上位モデルではなく、能力境界、利用資格、監査、データ保持を含む統治対象として扱うべきである。 |
| Claude Code | 開発エージェント | コードベース読解、ファイル編集、コマンド実行、IDE 統合、作業ログ、MCP 接続を確認する。 | Claude をコード補完ではなく、開発作業者として使えるかを決める。 | Claude の長時間作業能力を、実際の開発作業へ接続する実行ハーネスである。 |
| MCP コネクタ | 外部接続 | 外部ツール、データソース、API、認証、権限継承、管理者制御を確認する。 | Claude が社内データや業務システムを安全に扱えるかを決める。 | Claude を閉じた会話環境から、外部データと操作手段へ拡張する基盤である。 |
Sonnet 5 の位置づけは、Claude 系を理解するうえで重要である。Anthropic は Sonnet 5 を、コード作業、エージェント、専門的な実務作業を大規模に処理するモデルとして示している[13]。これは、最上位モデルを常に使うという発想ではない。多くの実務では、速度、費用、推論能力の均衡が重要になる。Sonnet 5 は、その均衡点に置かれるモデルである。軽い要約や雑談向けというより、コード、技術調査、デバッグ、複数段階の作業を日常的に処理する標準モデルとして読むのがよい。
一方、Opus 4.8 は、Sonnet 5 よりも重い作業を担う上位モデルである。Anthropic のモデル概要では、Opus 4.8 は複雑な推論、長時間のエージェント型コード作業、高い自律性が求められる作業に対応する Opus 級の高能力モデルとして説明されている[14]。この位置づけは、OpenAI 側の高推論モデルと比較するとわかりやすい。軽い作業では費用と速度が重要だが、複雑な設計、長時間のコード修正、複数文書をまたぐ分析、失敗時の復旧を含む作業では、より慎重な推論と持続性が必要になる。Opus 4.8 は、そのような高難度作業に置くモデルである。
| モデル | 主な位置づけ | 見るべき定量項目 | 向く作業 | 比較時の注意点 |
|---|---|---|---|---|
| Claude Sonnet 5 | 速度、性能、価格のバランスを取った主力主力実務モデルである。 | 最大入力トークン数、最大出力トークン数、入力単価、出力単価、ツール利用、コード作業ベンチマークを確認する。 | 日常的な知的作業、技術調査、コード修正、デバッグ、複数ステップの業務に向く。 | 最上位能力ではなく、継続利用しやすい標準モデルとして評価する必要がある。 |
| Claude Opus 4.8 | 複雑推論、長時間コード作業、高自律作業向けの上位モデルである。 | 最大入力トークン数、最大出力トークン数、入力単価、出力単価、推論性能、エージェント型のコード作業評価を確認する。 | 高難度の設計判断、複雑なコードベース、長時間の調査、失敗時の復旧を含む作業に向く。 | 費用と速度の負担が増えるため、すべての作業に使うのではなく、重い作業へ割り当てるべきである。 |
| Claude Fable 5 | 一般提供される Mythos 級モデルである。 | 最大入力トークン数、最大出力トークン数、入力単価、出力単価、ベンチマーク、安全制御発動率、別モデルへ処理を切り替える条件を確認する。 | 長期的で複雑なソフトウェアエンジニアリング、知的作業、画像理解、科学研究などに向く。 | 能力だけでなく、安全制御によって一部要求が Opus 4.8 に別モデルへ処理を切り替える点を含めて評価する必要がある。 |
| Claude Mythos 5 | 審査済み利用者向けの限定提供向けに一部安全制御を外した高能力モデルである。 | 提供対象、利用資格、データ保持、対象領域、サイバーセキュリティ / 生命科学の安全制御の有無、監査条件を確認する。 | 防御的サイバーセキュリティ、重要インフラ保護、生命科学研究など、限定された高リスク領域に向く。 | 一般ユーザー向け比較ではなく、能力配分と統治設計の対象として扱うべきである。 |
Claude の特徴を理解するには、一度に扱える文脈量の説明も欠かせない。Anthropic は一度に扱える文脈量を、モデルが応答生成時に参照できる作業記憶として説明している[15]。これは訓練データ全体ではない。会話履歴、入力文書、ツール結果、画像、ファイル、モデル自身の出力などが、一定のトークン上限の中に入る。大きな一度に扱える文脈量は、長い仕様書、複数文書、巨大な会話履歴、コードベースの一部を扱ううえで有利である。しかし、Anthropic は同時に、トークン数が増えるほど正確性や取り出し精度が劣化する文脈劣化が起きうると説明している[15]。
この説明が重要なのは、1M トークンという数字だけでは実務能力を判断できないからである。大量の情報を入れられることと、必要な情報を適切に取り出せることは違う。長文の中には、古い前提、矛盾した記述、不要な履歴、途中で破棄すべき仮説が混ざる。これらを全部文脈に残すと、モデルは情報を多く持つ一方で、何を重視すべきかを見失う可能性がある。したがって、Claude を長文作業で評価するときは、一度に扱える文脈量の大きさだけでなく、どの情報を入れ、どの情報を検索し、どの情報を要約し、どの段階で捨てるかという文脈設計を見る必要がある。
| 文脈の観点 | 単純な見方 | Claude で見るべき点 | 実務上の意味 |
|---|---|---|---|
| 容量 | 最大入力トークンが大きいほどよいと見る。 | 最大入力トークンと最大出力トークンを確認し、実際にどの程度の資料を扱うかを見る。 | 長い文書、会話履歴、コード、調査資料を一度に扱いやすくなる。 |
| 検索性 | 入れた情報はすべて同じように参照できると考える。 | 長文内の必要箇所を安定して取り出せるか、引用や根拠を追えるかを見る。 | 契約書、仕様書、設計書、ログ調査では、必要箇所を外さないことが重要になる。 |
| 劣化 | 文脈が長ければ長いほど精度が上がると考える。 | 文脈劣化、不要情報の混入、古い履歴の影響、取り出し精度低下を考慮する。 | 長い会話や大きな資料を使うとき、情報を入れすぎることで逆に判断が鈍る場合がある。 |
| 設計 | 資料を全部入れてモデルに任せる。 | 要約、検索、分割、メモリ、補助エージェント、ツール実行結果の再利用を組み合わせる。 | 長時間作業では、文脈を管理する設計そのものが成果物の品質を左右する。 |
Claude Code は、Claude の長時間作業能力を開発現場へ接続する実行ハーネスである。Anthropic は Claude Code を、コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと統合するエージェント型の開発支援ツールと説明している[16]。これは単なるコード補完ではない。コード補完は、現在書いている行や関数の続きを支援する機能である。一方、Claude Code は、既存コードを読み、関連ファイルを探し、バグの原因を調べ、修正し、コマンドを実行し、結果を確認しながら作業を進める環境である。
ここで Claude Code の価値は、モデルがコードを書けることだけではない。実務のコード作業では、変更対象を見つけること、既存設計を壊さないこと、テストを実行すること、失敗時に原因を追うこと、変更理由を説明することが必要になる。Claude Code は、この一連の流れを Claude のエージェント型の作業と接続する。したがって、Claude Code を評価するときは、生成コードの見た目ではなく、コードベース読解、コマンド実行、失敗時の復旧、ログ、レビュー可能な差分を見なければならない。
| Claude Code の観点 | 確認すべき内容 | 実務上の価値 | 注意すべき点 |
|---|---|---|---|
| コードベース読解 | 関連ファイル、依存関係、既存設計、テスト構造をどこまで理解できるかを見る。 | 単発のコード生成ではなく、既存システムに沿った変更がしやすくなる。 | 巨大リポジトリでは、読み取る範囲と文脈管理が品質に直結する。 |
| ファイル編集 | 複数ファイルを編集し、整合した変更としてまとめられるかを見る。 | 設定、実装、テスト、ドキュメントをまたぐ修正に向く。 | 変更が広がるほど、レビュー可能な差分と元に戻す手順が重要になる。 |
| コマンド実行 | ビルド、テスト、静的解析、検索、スクリプト実行を扱えるかを見る。 | 生成した変更を AI 自身が一部検証できるようになる。 | 危険なコマンド、破壊的操作、外部送信、秘密情報の扱いには制御が必要である。 |
| 開発ツール統合 | ターミナル、IDE、デスクトップ、ブラウザ、MCP 経由の外部ツール接続を確認する。 | 開発者の通常環境に Claude を組み込みやすくなる。 | 便利さが増すほど、接続先ごとの権限管理が複雑になる。 |
| 作業説明 | 何を読んだか、なぜ変更したか、どの検証をしたかを説明できるかを見る。 | 人間がレビューし、採否判断し、責任を持って統合しやすくなる。 | 説明がもっともらしくても、実際の差分やテスト結果と照合する必要がある。 |
MCP コネクタとツール利用は、Claude を外部ツールやデータソースへ接続するための基盤である。Anthropic のツール利用では、Claude がユーザーの要求とツールの説明に基づいて、必要なツールを呼び出す仕組みが説明されている[17]。MCP は、AI アプリケーションがデータソースやツールに接続する方法を標準化するプロトコルとして位置づけられている[18]。これにより、Claude は会話の中だけで閉じるのではなく、ファイル、データベース、検索、業務ツール、開発ツールと接続できる。
ここでも重要なのは、接続できること自体ではない。接続先が増えるほど、どのツールが何を読めるか、何を書けるか、どの認証で動くか、どのログが残るかを管理しなければならない。Claude が高信頼な作業者として使えるかどうかは、モデルの誠実さだけで決まるのではない。接続先の権限、ツール説明文の正確さ、実行前確認、監査ログ、管理者制御が揃っているかで決まる。
| 接続要素 | 役割 | 評価項目 | 実務上の注意点 |
|---|---|---|---|
| ツール利用 | Claude が外部関数や Anthropic 提供ツールを必要に応じて呼び出す。 | ツール定義、引数形式定義、呼び出し判断、失敗時の扱い、結果の再利用を確認する。 | ツールの説明が曖昧だと、誤ったツール選択や過剰実行が起きやすい。 |
| MCP | AI アプリケーションと外部データソース、外部ツールを標準化された形で接続する。 | 接続可能サーバー、認証方式、権限継承、管理者制御、ログ、データ範囲を確認する。 | 接続の標準化は便利だが、接続先が増えるほど境界管理も重要になる。 |
| コネクタ | Claude を業務データや外部サービスへ接続する。 | 対応サービス、読み取り権限、書き込み権限、ユーザー権限継承、組織単位の制御を確認する。 | 社内文書や業務データを扱う場合、見てよい情報だけを見る設計が必要である。 |
| 企業向け管理機能 | 組織利用時の認証、監査、データ保持、管理者制御を担う。 | シングルサインオン、ユーザー管理連携、監査ログ、データ保持、利用状況分析、役割に基づくアクセス制御を確認する。 | 企業導入では、AI の出力品質だけでなく、後から説明できる運用が必要になる。 |
Fable 5 / Mythos 5 は、Claude 系を他社比較と分けて考えるべき最大の理由である。Fable 5 は、Anthropic が一般利用向けに安全化した Mythos 級モデルとして発表したモデルであり、ソフトウェアエンジニアリング、知的作業、画像理解、科学研究などで高い能力を示すと説明されている[19]。一方、Mythos 5 は Fable 5 と同じ基盤となる同一モデルだが、一部領域の安全制御を外し、Project Glasswing などの審査済み利用者向けの限定提供向けに提供される[19]。
この構造は、単なるモデル階層ではない。Fable 5 と Mythos 5 は、能力が違うというより、能力の出し方が違う。Fable 5 は一般提供のために安全制御を持ち、一部のサイバーセキュリティ関連要求などでは Claude Opus 4.8 へ別モデルへ処理を切り替える設計が示されている[19]。Mythos 5 は、防御的サイバーセキュリティや将来的な生命科学領域の審査済み利用者向けの限定提供制度のように、利用者、目的、領域を限定して能力を配分する対象である。つまり、ここで比較すべきなのは、Fable 5 と Mythos 5 のどちらが賢いかではなく、同じ高能力を、どの条件で、誰に、どの範囲まで出すかである。
| 観点 | Fable 5 | Mythos 5 | 評価上の意味 |
|---|---|---|---|
| 基盤能力 | Mythos 級モデルを一般利用向けに安全化したものとして扱われる。 | Fable 5 と同じ基盤となる同一モデルと説明される。 | 両者は単純な上下関係ではなく、同じ高能力を異なる安全条件で提供する関係である。 |
| 提供対象 | 一般利用者向けに提供される。 | Project Glasswing など、審査済み利用者向けの限定提供向けに制限される。 | 能力の高さだけでなく、利用資格が仕様の一部になる。 |
| 安全制御 | 高リスク領域では安全制御が働き、一部要求は Opus 4.8 へ別モデルへ処理を切り替える。 | 一部領域の安全制御が外された形で提供される。 | モデル名だけでなく、どの安全制御が有効かを確認しなければならない。 |
| 主な用途 | ソフトウェア開発、知的作業、画像理解、科学研究などの一般高難度作業に向く。 | 防御的サイバーセキュリティ、重要インフラ保護、生命科学研究など、限定された高リスク用途に向く。 | 用途制限と提供条件を含めて比較する必要がある。 |
| 統制条件 | 一般提供のため、誤検知を含む保守的な制御が入りうる。 | 審査済み利用者向けの限定提供、データ保持、監査、政府やパートナーとの協調が前提になる。 | 高能力モデルでは、性能表だけでなく、データ保持と監査条件も仕様になる。 |
Fable 5 / Mythos 5 の再配備問題は、この能力境界の難しさをさらに明確にした。Anthropic は、2026 年 6 月 12 日に米政府の輸出管理規制により、Fable 5 と Mythos 5 への外国籍者アクセスを制限する必要が生じたが、国籍をリアルタイムに信頼可能な形で確認する方法がなかったため、両モデルへのアクセスを全ユーザーで停止したと説明している。その後、2026 年 6 月 30 日に輸出管理規制が解除され、Fable 5 は 7 月 1 日から Claude Platform、Claude.ai、Claude Code、Claude Cowork で再提供されると発表された[19]。
この事例から分かるのは、能力境界は方針だけでは足りないということである。「外国籍者には使わせない」「防御目的には使わせる」「高リスク領域は制限する」といったルールを掲げることはできる。しかし、それを実際の API、アカウント、組織、クラウド、ID、契約、監査、データ保持、別モデルへの切り替えの層で実装できなければ、境界は保存されない。能力の制御は、政策文言ではなく、運用可能な技術仕様でなければならない。
| 能力境界の層 | 制御したいこと | 必要になる実装 | Fable 5 / Mythos 5 から見える問題 |
|---|---|---|---|
| 利用者 | 誰が高能力モデルを使えるかを制御する。 | 本人確認、組織確認、利用資格、地域、国籍、契約条件を管理する。 | 国籍のような属性をリアルタイムに信頼可能な形で確認することは難しい。 |
| 用途 | 防御目的、研究目的、一般業務、危険用途を区別する。 | 申請、審査、用途制限、監査、利用ログ、違反時停止を組み合わせる。 | 同じ技術的操作が、防御にも攻撃にも使えるため、用途判定は単純ではない。 |
| モデル | どの能力をどのモデル ID で提供するかを分ける。 | Fable 5、Mythos 5、Opus 4.8 などの振り分け、別モデルへの切り替え、利用権限を管理する。 | 同じ基盤となる同一モデルでも、安全制御の有無で提供条件が変わる。 |
| リクエスト | 危険な要求や曖昧な要求を検出する。 | 安全判定器、拒否、別モデルへの切り替え、追加確認、ログ分析を使う。 | 保守的に制御すれば誤検知が増え、緩くすれば悪用の危険が増える。 |
| 運用 | 問題発生時に説明し、停止し、修正できるようにする。 | 監査ログ、データ保持、人間によるアクセス記録、緊急停止、政府やパートナーとの連携を整える。 | 高能力モデルでは、事後検証と再配備の仕組みも仕様の一部になる。 |
ここまでを総合すると、Claude / Anthropic の特徴は、長文に強いことや安全性を重視することだけではない。Sonnet 5 は実務用主力実務モデルであり、Opus 4.8 は高難度作業用の上位モデルであり、Claude Code は開発作業を進める実行ハーネスであり、MCP コネクタは外部ツールとデータソースへの接続基盤である。そして Fable 5 / Mythos 5 は、最上位能力を一般提供と審査済み利用者向けの限定提供に分け、安全制御、別モデルへの切り替え、データ保持、監査を含めて提供する能力境界管理の事例である。これらは別々の話ではなく、Claude を高信頼な長時間作業者として成立させるための部品である。
| 評価軸 | Claude / Anthropic で強く見える点 | 実務上の利点 | 注意すべき点 |
|---|---|---|---|
| モデル能力 | Sonnet 5、Opus 4.8、Fable 5、Mythos 5 が用途と能力階層ごとに整理されている。 | 日常業務、高難度作業、最上位能力、限定提供能力を使い分けやすい。 | モデル名だけでなく、提供範囲、安全制御、別モデルへ処理を切り替える条件を合わせて見る必要がある。 |
| コンテキスト | 一度に扱える文脈量と文脈劣化の考え方が明示されている。 | 長文文書、コードベース、複数資料、長時間作業を扱う設計を考えやすい。 | 1M トークンという容量だけでなく、文脈設計が必要になる。 |
| エージェント実行 | Claude Code がコードベース読解、ファイル編集、コマンド実行、開発ツール統合を担う。 | コード補完ではなく、開発作業の調査、修正、検証を委譲しやすい。 | 破壊的操作、秘密情報、誤修正、テスト不足を防ぐ運用が必要になる。 |
| 業務接続 | MCP コネクタとツール利用により、外部データや外部ツールへ接続できる。 | Claude を閉じた会話環境から、業務データや開発環境へ拡張できる。 | 接続先ごとの認証、権限、ログ、管理者制御を確認する必要がある。 |
| 能力境界 | Fable 5 / Mythos 5 により、同一基盤となる同一モデルを一般提供と審査済み利用者向けの限定提供に分けている。 | 高能力モデルを、用途と利用者に応じて条件付きで配分する設計が見える。 | 国籍、用途、領域、別モデルへの切り替え、データ保持、監査を実装できなければ境界は保存されない。 |
ここから分かるのは、Claude が単に ChatGPT と似たチャット AI ではないということである。Claude は、長文、コードベース、慎重な分析、企業データ、権限、危険領域の制御に重心がある。OpenAI が広い作業面を取りに行く「業務 OS」型だとすれば、Anthropic は、高信頼な長時間作業者を、能力階層、文脈設計、Claude Code、MCP コネクタ、安全制御、審査済み利用者向けの限定提供、監査を組み合わせて提供する方向に進んでいる。
より広く言えば、Claude / Anthropic の比較軸は、「ChatGPT より賢いか」ではない。むしろ、長い文脈をどう扱うか、複雑な作業をどこまで継続できるか、外部ツールやコードベースにどう接続するか、危険な能力をどの条件で配分するか、問題が起きたときに説明し、止め、再配備できるかである。Fable 5 / Mythos 5 が示したのは、最先端 AI では、能力そのものだけでなく、能力をどの境界で出すかまでが仕様になるということである。
5. Fable 5 / Mythos 5 は、能力配分そのものが仕様になることを示す
Fable 5 / Mythos 5 は、本稿の中で特に重要である。これは単なる新モデル紹介ではない。Anthropic の “Claude Fable 5 and Claude Mythos 5” は、Fable 5 と Mythos 5 を単純に競わせる発表ではない。Mythos 級の能力を、一般提供向けの Fable 5 と、審査済み利用者向けの限定提供向けの Mythos 5 に分けたうえで、Claude Opus 4.8、GPT-5.5、Gemini 3.1 Pro、Claude Mythos プレビューなどと比較している発表である[18]。つまり、この発表で比較されているのは、モデルの性能だけではない。同じ高能力を、どの利用者に、どの条件で、どの安全制御付きで渡すかという提供設計も比較対象になっている。
ここで最初に確認すべきなのは、Fable 5 と Mythos 5 がまったく別系統のモデルとして示されているわけではないという点である。Anthropic は、Fable 5 を一般利用向けに安全化された Mythos 級モデルとして説明している。一方、Mythos 5 は、同じ基盤となる同一モデルを基礎にしながら、一部領域の安全制御を外し、審査済み利用者向けの限定提供向けに提供されるモデルとして説明されている[18]。したがって、Fable 5 と Mythos 5 の差は、単純な能力差ではない。差の中心は、能力の出し方、利用資格、安全制御、別モデルへの切り替え、監査条件にある。
この点を取り違えると、Fable 5 / Mythos 5 の意味を誤る。通常のモデル比較であれば、入力トークン数、出力トークン数、価格、ベンチマーク点数を並べれば、ある程度は比較できる。しかし Fable 5 / Mythos 5 では、それだけでは足りない。なぜなら、同じ基盤となる同一モデルに近い能力であっても、一般利用向けには安全制御が入り、高リスク領域では別モデルへ別モデルへの切り替えし、審査済み利用者向けの限定提供向けには一部安全制御を外した形で提供されるからである。つまり、モデル仕様の中に、能力、利用者、用途、安全制御、提供条件が一体化している。
| 観点 | Fable 5 | Mythos 5 | 定量・準定量で確認すべき項目 | 読み取れること |
|---|---|---|---|---|
| 基盤能力 | Mythos 級モデルを一般利用向けに安全化したものとして扱われる。 | Fable 5 と同じ基盤となる同一モデルを基礎にした高能力モデルとして扱われる。 | ベンチマーク、最大入力トークン、最大出力トークン、価格、対応モダリティを確認する。 | 両者は単純な上下関係ではなく、同じ高能力を異なる安全条件で提供する関係である。 |
| 提供範囲 | 一般利用向けに提供される。 | 審査済み利用者向けの限定提供向けに限定提供される。 | 利用可能なプラン、API 提供範囲、利用資格、地域制限、組織審査を確認する。 | モデルの意味は、性能だけでなく、誰が使えるかによって変わる。 |
| 安全制御 | 高リスク領域では安全制御や別モデルへ処理を切り替えることで挙動が制御される。 | 一部領域の安全制御を外した形で、限定された主体と目的に提供される。 | 安全判定器、別モデルへ処理を切り替える条件、誤検知、拒否率、監査ログ、データ保持条件を確認する。 | 高能力モデルでは、安全制御の有無と発動条件が仕様の一部になる。 |
| 用途 | ソフトウェア開発、知的作業、画像理解、科学研究などの一般高難度作業に向く。 | 防御的サイバーセキュリティ、重要インフラ保護、将来的な生命科学研究など、限定された高リスク領域に向く。 | 対象領域、禁止領域、許可される研究目的、利用者区分、審査手続を確認する。 | 同じ技術能力でも、用途によって一般提供と限定提供に分かれる。 |
| 比較上の意味 | GPT-5.5 や Gemini 3.1 Pro と並ぶ最先端モデルとして比較される。 | 一般市場の横並び比較というより、制限付き能力の提供形態として位置づけられる。 | 他社最先端モデルとのベンチマーク差、旧 Mythos プレビューとの差、Opus 4.8 との差を確認する。 | ベンチマーク表は、性能比較であると同時に、能力配分の説明でもある。 |
この表で重要なのは、Fable 5 と Mythos 5 を「どちらが上か」と読むべきではないという点である。Fable 5 は広く使える形に整えられた高能力モデルである。Mythos 5 は、より限定された主体と目的のもとで、より直接的な能力を使わせるためのモデルである。したがって、Fable 5 / Mythos 5 の比較で見るべきものは、能力差だけではなく、能力をどの条件で配分するかである。これは、従来のモデル比較にはなかった評価軸である。
Anthropic の発表では、Fable 5 / Mythos 5 は、ソフトウェア開発、知的作業、画像理解、科学研究、サイバーセキュリティなど複数の領域で評価されている[18]。ここで注意すべきなのは、ベンチマークの点数が高いほど、公開判断が単純になるわけではないということである。むしろ逆である。サイバーセキュリティや生命科学のような領域では、高い能力は防御にも研究にも役立つ一方で、攻撃や危険な応用にもつながりうる。能力が高くなるほど、単に「公開する」か「公開しない」かではなく、誰に、何の目的で、どの範囲まで使わせるかを決めなければならない。
| 能力領域 | 有益な利用 | 高リスクな利用 | 境界設計で見るべき項目 | Fable 5 / Mythos 5 から見えること |
|---|---|---|---|---|
| ソフトウェア開発 | 大規模コード修正、移行、デバッグ、テスト生成、技術的負債の整理に使える。 | 脆弱なコードの作成、自動化された悪用補助、レビューを通らない危険な変更に使われうる。 | リポジトリアクセス、テスト実行、レビュー、差分管理、秘密情報保護を確認する。 | 高いコード作業能力は、開発効率とリスクを同時に増やす。 |
| サイバーセキュリティ | 防御的調査、脆弱性検証、重要インフラ保護、ログ分析、攻撃経路の理解に使える。 | 攻撃手順の高度化、悪用コード作成、侵入支援、検出回避の助言に使われうる。 | 防御目的の確認、利用者審査、安全判定器、別モデルへの切り替え、監査ログ、データ保持を確認する。 | 同じ知識が防御にも攻撃にも使えるため、用途と利用者を分ける必要がある。 |
| 生命科学・化学 | 生命科学研究、文献整理、実験設計の補助、安全性評価に使える。 | 危険な合成、生物学的リスクの高い手順、デュアルユース研究の悪用に使われうる。 | 対象領域、研究目的、利用資格、危険手順の拒否、別モデルへの切り替え、追加審査を確認する。 | 専門能力が高いほど、単なる回答制御ではなく、領域別の能力配分が必要になる。 |
| 知的作業 | 長文調査、法務、政策文書、技術仕様、業務資料の統合に使える。 | もっともらしい誤情報、根拠不明な要約、都合のよい引用、判断の外部化を招きうる。 | 引用、根拠追跡、出典確認、長文取り出し精度、レビュー手順を確認する。 | 高性能な知的作業支援では、人間側の判断軸と検証手順がより重要になる。 |
| 画像理解・マルチモーダル | 図表、画面、PDF、写真、設計資料、研究資料の理解に使える。 | 誤認識、画像の過信、文脈抜きの判断、監視や識別への不適切利用につながりうる。 | 入力形式、解像度、根拠提示、誤認識時の扱い、個人情報や機微情報の制御を確認する。 | マルチモーダル能力は便利さだけでなく、扱う情報の範囲を広げる。 |
この構造は、2026 年 6 月の Fable 5 / Mythos 5 停止と再配備でさらに明確になった。Anthropic は、Fable 5 と Mythos 5 に対する輸出管理規制の影響で、外国籍者アクセスを制限する必要が生じたが、国籍をリアルタイムに信頼可能な形で確認する方法がなかったため、両モデルへのアクセスを全ユーザーで停止したと説明している。その後、輸出管理規制が解除され、Fable 5 は Claude Platform、Claude.ai、Claude Code、Claude Cowork で再提供されると発表された[19]。
この事案が示すのは、AI の統治が「危険なモデルを止めるかどうか」だけでは済まないということである。方針として「特定の属性の利用者には使わせない」「防御目的なら使わせる」「高リスク領域では制限する」と書くことはできる。しかし、それを実際の API、アカウント、組織、クラウド、ID、契約、監査、データ保持、別モデルへの切り替えの層で実装できなければ、境界は保存されない。能力の制御は、理念や規約だけではなく、運用可能な技術仕様でなければならない。
| 境界の層 | 制御したいこと | 必要になる実装 | 失敗した場合に起きること | Fable 5 / Mythos 5 から見える問題 |
|---|---|---|---|---|
| 利用者 | 誰が高能力モデルを使えるかを制御する。 | 本人確認、組織確認、利用資格、地域、国籍、契約条件、承認済みアカウントを管理する。 | 本来使えない利用者がアクセスできるか、逆に正当な利用者まで一律に止めることになる。 | 国籍のような属性を、リアルタイムに信頼可能な形で確認することは難しい。 |
| 用途 | 防御目的、研究目的、一般業務、危険用途を区別する。 | 申請、審査、用途制限、利用ログ、事後監査、違反時停止を組み合わせる。 | 同じ能力が防御にも攻撃にも使われるため、用途判定が形式的になる。 | デュアルユース領域では、行為の内容だけでなく、主体と目的を合わせて見る必要がある。 |
| モデル | どの能力をどのモデル ID で提供するかを分ける。 | Fable 5、Mythos 5、Opus 4.8 などの振り分け、別モデルへの切り替え、利用権限、モデル ID 管理を行う。 | 利用者が意図せず高能力モデルに到達するか、必要な作業で不自然に低能力モデルへ落ちる。 | 同じ基盤となる同一モデルでも、安全制御の有無で実際の提供条件が変わる。 |
| リクエスト | 危険な要求や曖昧な要求を検出する。 | 安全判定器、拒否、別モデルへの切り替え、追加確認、出力制限、ログ分析を使う。 | 保守的すぎれば誤検知が増え、緩すぎれば悪用の危険が増える。 | Fable 5 では、一部高リスク領域で別モデルへ処理を切り替えることで能力を制御する設計が示されている。 |
| 環境 | どのクラウド、どの組織、どの API キー、どのアプリから使えるかを制御する。 | テナント分離、API キー管理、リージョン制御、監査可能な実行環境、管理者ポリシーを整える。 | 利用者単位では制御できても、別経路から同じ能力に到達できる可能性が残る。 | 能力境界は、モデルだけでなく、提供経路全体で保存する必要がある。 |
| 運用 | 問題発生時に説明し、停止し、修正し、再配備できるようにする。 | 監査ログ、データ保持、人間によるアクセス記録、緊急停止、再配備手順、政府やパートナーとの連携を整える。 | 問題発生時に、誰が、いつ、何を、どのモデルで行ったかを説明できなくなる。 | 高能力モデルでは、事後検証と再配備の仕組みも仕様の一部になる。 |
この事案を、単なる規制対応の失敗としてだけ読むのは浅い。むしろ重要なのは、能力境界を実装する難しさが露出したことである。高能力モデルを提供する場合、モデル提供者は、利用者の属性、利用目的、対象領域、提供経路、実行環境、監査可能性を同時に管理しなければならない。どれか一つでも曖昧であれば、境界は崩れる。逆に、厳格に止めすぎれば、正当な利用まで妨げられる。Fable 5 / Mythos 5 は、この緊張を具体的に示している。
この章の一般化は明確である。最先端 AI の能力が高くなるほど、比較すべきものは性能だけではなくなる。誰が使えるか、どの用途なら許されるか、どの領域では止めるか、どのモデルに別モデルへ処理を切り替えるか、どのログを残すか、どの条件で再配備するかが、モデル仕様の一部になる。Fable 5 / Mythos 5 は、AI モデルの公開が、能力配分、制度、実装、監査を同時に問う段階へ入ったことを示している。
したがって、Fable 5 / Mythos 5 は、Claude 系の単なる上位モデル紹介ではない。これは、最新 AI モデルの比較軸そのものを変える事例である。従来の比較では、性能、価格、文脈、出力長を見ればよかった。しかし、Fable 5 / Mythos 5 以後は、一般提供、審査済み利用者向けの限定提供、安全制御、別モデルへの切り替え、利用資格、用途制限、監査、データ保持、緊急停止、再配備まで見なければならない。能力配分そのものが仕様になるとは、そういうことである。
6. Gemini / Google は、モデル単体ではなく Google 統合で見る
Gemini は、ChatGPT / Claude に対する第三極として扱うべきである。ただし、Gemini を評価するときも、モデル単体だけを見ては不十分である。Google AI for Developers のモデル一覧では、Gemini 系モデルが Pro、Flash、Flash-Lite、画像生成、音声生成などの用途ごとに整理されている[20]。また、Gemini 3.1 Pro プレビューの仕様では、入力として文章、画像、動画、音声、PDF を扱い、1,048,576 トークンの入力上限と 65,536 トークンの出力上限を持つモデルとして示されている[21]。この仕様だけを見ても、Gemini は短い会話のためのモデルではなく、大量の資料、複数形式の入力、検索やコード実行を含む作業を想定したモデルである。
しかし、Gemini の本当の評価軸は、モデル仕様だけでは決まらない。Google は、検索、メール、文書、予定表、クラウド、ブラウザ、モバイル OS、動画、広告、開発者向けクラウド基盤を持っている。Gemini は、この巨大な情報環境に埋め込まれることで価値を出す。つまり、Gemini は「Claude や ChatGPT より賢いか」という単純な問いだけでなく、「Google Search、Workspace、Cloud、Android、Chrome、YouTube、Gmail、Drive、Docs、Calendar と結びついたとき、どの作業が自然に AI 化されるか」という問いで評価する必要がある。
この章で確認する評価軸は、五つである。第一に、モデルとしてのマルチモーダル能力である。第二に、Google Search や URL 文脈と結びついた検索・調査能力である。第三に、Gmail、Drive、Docs、Calendar など Workspace への埋め込みである。第四に、Vertex AI や Gemini Enterprise を通じた企業システムへの接続である。第五に、Google という既存プラットフォームを前提にした利用者接点の広さである。Gemini は、単体モデルとしての能力と、Google の情報面に埋め込まれる力を分けて見なければならない。
| 評価軸 | Gemini で見るべき内容 | 定量的に記録すべき項目 | ChatGPT / Claude との比較上の意味 | 本章での評価結果 |
|---|---|---|---|---|
| モデル能力 | Pro、Flash、Flash-Lite などのモデル階層と、推論、コード作業、マルチモーダル処理を確認する。 | モデル ID、最大入力トークン、最大出力トークン、対応入力形式、対応出力形式、価格、提供状態を記録する。 | ChatGPT / Claude と同じ最先端モデル比較の対象になる。 | Gemini 3.1 Pro プレビューは、1M トークン級の入力と 65K トークン級の出力を持つ第三極の高性能モデルとして扱うべきである。 |
| マルチモーダル | 文章、画像、動画、音声、PDF、コードなどを横断して扱えるかを見る。 | 対応モダリティ、動画入力長、音声入力、PDF 入力、画像理解、コードリポジトリ処理の有無を記録する。 | Google は YouTube、画像検索、Drive、Docs、Android、Chrome を持つため、マルチモーダル処理の接続先が広い。 | Gemini の強みは、モデル単体のマルチモーダル能力だけでなく、Google の既存データ面と結びつく点にある。 |
| 検索統合 | Google Search、検索結果に基づく回答補強、URL 文脈、Deep Research をどう使えるかを見る。 | 検索結果に基づく回答補強の有無、URL 文脈対応、検索回数、引用提示、リアルタイム性、Deep Research の利用条件を記録する。 | 調査用途では、ChatGPT Deep Research や Perplexity Sonar と比較する必要がある。 | Gemini は Google Search と同じ企業内で開発されるため、検索と生成の統合という点で重要な比較対象になる。 |
| Workspace 統合 | Gmail、Drive、Docs、Sheets、Slides、Calendar、Meet などに AI がどう埋め込まれるかを見る。 | 接続可能アプリ、ファイル検索、メール検索、予定表参照、文書生成、表計算補助、管理者制御を記録する。 | Microsoft 365 Copilot と同じく、既存業務基盤への埋め込みが価値になる。 | Google Workspace を日常業務の中心にしている組織では、モデル単体よりも Workspace 上での自然な利用が重要になる。 |
| Cloud・Enterprise | Vertex AI、Gemini Enterprise、エージェント、企業データ接続、管理機能を確認する。 | Vertex AI 提供、API 利用、企業データ接続、M365 接続、Google Workspace 接続、エージェント実行、ガバナンス機能を記録する。 | OpenAI / Anthropic API との比較では、モデル API だけでなく、Google Cloud 上の企業基盤として見る必要がある。 | Gemini は、Google Cloud と既存業務データに埋め込まれた AI として評価するべきである。 |
この表から分かるのは、Gemini の比較軸が二重であるという点である。一つは、Gemini 3.1 Pro プレビューのような最先端モデルとしての比較である。この軸では、最大入力トークン、最大出力トークン、推論、コード作業、マルチモーダル処理、価格、提供状態を見る。もう一つは、Google の既存サービスへどのように入り込むかという比較である。この軸では、Google Search、Workspace、Cloud、Android、Chrome、YouTube、Drive、Gmail、Docs、Calendar との接続を見る。Gemini を正しく評価するには、この二つを分けてから、最後に統合して判断する必要がある。
Gemini 3.1 Pro プレビューの仕様は、モデル単体でも十分に強い。Google AI for Developers では、入力として文章、画像、動画、音声、PDF を扱い、出力はテキストであり、入力トークン上限は 1,048,576、出力トークン上限は 65,536 と示されている[21]。この仕様は、会話だけでなく、長い PDF、動画、音声、画像を含む資料、複数形式の調査材料を一つのモデルへ渡す用途を想定している。特に、動画や音声を自然に扱う方向は、Google が YouTube、Android、Chrome、Meet などを持つことと相性がよい。
| 仕様項目 | Gemini 3.1 Pro プレビューで見る内容 | 実務上の意味 | 比較時の注意点 |
|---|---|---|---|
| 入力トークン | 1,048,576 トークンの入力上限が示されている。 | 長い文書、複数資料、議事録、調査材料をまとめて扱いやすい。 | 入力上限が大きくても、長文内の必要箇所を安定して取り出せるかは別に見る必要がある。 |
| 出力トークン | 65,536 トークンの出力上限が示されている。 | 長めのレポート、要約、設計案、調査結果の生成に向く。 | Claude や OpenAI の 128K 出力級モデルと比べる場合、出力上限の差を考慮する必要がある。 |
| 入力形式 | 文章、画像、動画、音声、PDF を入力として扱える。 | 資料、画像、動画、音声、PDF を横断した調査や分析に向く。 | 対応していることと、実務で正確に理解できることは別であり、用途別に検証が必要である。 |
| 出力形式 | 出力はテキストとして示されている。 | 入力の種類が多くても、最終的な整理、説明、要約、提案は文章として扱う用途に向く。 | 画像生成や音声生成は別モデルや別機能として確認する必要がある。 |
| 開発者機能 | 関数呼び出し、コード実行、検索結果に基づく回答補強、URL 文脈、構造化出力などを確認する。 | 外部情報を検索し、コードを実行し、構造化した出力を得る開発用途に広がる。 | API で使える機能と、Gemini アプリや Workspace で使える機能は一致しない場合がある。 |
Gemini の強さは、Google Search と結びついたときに特に見えやすい。調査では、モデル内部の知識だけでは不十分である。最新の仕様、価格、規制、ニュース、論文、企業発表は変化する。したがって、検索、引用、URL 取得、検索結果の検証が必要になる。Google は検索そのものを持っているため、Gemini は生成 AI と検索の統合という観点で重要である。ただし、検索と生成が統合されるほど、出典の選び方、引用の偏り、検索結果の再現性、Google 所有コンテンツへの偏りといった問題も生じる。したがって、Gemini の検索統合は強みであると同時に、検証すべき対象でもある。
| 検索・調査の観点 | Gemini / Google で見る内容 | 比較対象 | 実務上の評価項目 |
|---|---|---|---|
| 検索結果に基づく回答補強 | Google Search に基づいて回答を補強できるかを見る。 | ChatGPT の Web 検索、Perplexity Sonar、Claude の Web 検索と比較する。 | 引用提示、検索結果の信頼性、更新頻度、検索対象、出典追跡性を確認する。 |
| URL 内容の読み取り | 指定した URL の内容を読み、回答へ反映できるかを見る。 | ChatGPT の閲覧機能やコネクタ、Perplexity の URL 取得と比較する。 | URL 読み取り精度、PDF 対応、長文ページ対応、引用単位、取得失敗時の扱いを確認する。 |
| Deep Research | 複数ソースを調査し、長めの調査レポートを生成できるかを見る。 | ChatGPT Deep Research、Perplexity Sonar Deep Research と比較する。 | 検索範囲、調査深度、引用、レポート構成、調査時間、利用回数制限を確認する。 |
| 検索統合の偏り | 検索結果、AI Overview、Gemini で提示される情報源がどう違うかを見る。 | 従来の Google Search、AI Overview、他社検索 AI と比較する。 | 情報源の多様性、再現性、Google 所有コンテンツの比率、同じ質問への安定性を確認する。 |
Workspace 統合も重要である。Gemini が Gmail、Drive、Docs、Sheets、Slides、Calendar、Meet に埋め込まれると、利用者は AI を別アプリとして呼び出すのではなく、日常の業務画面の中で使うようになる。これは Microsoft 365 Copilot と同じ構造である。企業内業務では、最強のモデルを別画面で使えることよりも、メール、予定、文書、表、会議、ファイルに自然に接続できることの方が効く場合がある。Google Workspace を中心に仕事をしている組織では、Gemini の価値はモデル性能だけではなく、Workspace の中でどこまで権限を守りながら業務データを扱えるかで決まる。
| Workspace 領域 | Gemini が担う可能性のある作業 | 定量・準定量で見る項目 | 比較対象 | 注意点 |
|---|---|---|---|---|
| Gmail | メール要約、返信案、関連メール検索、文脈整理を行う。 | 検索対象、添付ファイル扱い、返信生成、権限、管理者制御を確認する。 | Microsoft Outlook / Copilot、ChatGPT コネクタと比較する。 | メールには機密情報が多いため、権限とデータ保持の確認が必要である。 |
| Drive | ファイル検索、資料横断要約、関連文書の抽出を行う。 | 検索対象ファイル数、対応形式、共有権限、更新反映、引用単位を確認する。 | SharePoint / Microsoft 365 Copilot、ChatGPT コネクタ、Claude コネクタと比較する。 | 見てよいファイルだけを検索できるかが企業利用の前提になる。 |
| Docs / Sheets / Slides | 文書作成、表の整理、プレゼン下書き、編集補助を行う。 | 生成可能な文書形式、表計算補助、スライド生成、共同編集、履歴管理を確認する。 | Microsoft Word / Excel / PowerPoint Copilot、ChatGPT の文書生成と比較する。 | 生成物の正確性だけでなく、既存ファイルの編集履歴や共同編集との整合が重要である。 |
| Calendar / Meet | 予定調整、会議要約、アクションアイテム整理を行う。 | 予定表参照、参加者情報、会議録、要約、タスク化、権限を確認する。 | Microsoft Teams / Outlook / Copilot と比較する。 | 会議内容は文脈依存が強く、要約やタスク化の誤りが業務判断に影響する。 |
クラウドと企業向け機能の観点では、Gemini は Vertex AI や Gemini Enterprise Agent Platform と組み合わせて評価する必要がある。Google Cloud の Gemini 3.1 Pro の説明は、このモデルを Gemini Enterprise Agent Platform 上で利用する前提の仕様として示している[21]。これは、Google が単に Gemini というモデルを売っているのではなく、企業データに基づいて回答し、複数の業務アプリをまたぐ作業手順を自動化するエージェントを、管理可能な企業向け基盤として提供しようとしていることを示している。
この点で、Gemini は OpenAI / Anthropic だけでなく、Microsoft 365 Copilot とも比較される。OpenAI や Anthropic は、汎用モデルと API、エージェント、コネクタを通じて業務基盤に入ろうとしている。一方、Google と Microsoft は、すでに企業のメール、文書、予定、ファイル、ID、クラウドを持っている。そのため、企業導入では、モデル単体の性能だけではなく、既存データ、権限、監査、管理者制御にどれだけ自然に接続できるかが競争軸になる。
| 企業導入の観点 | Gemini / Google | ChatGPT / OpenAI | Claude / Anthropic | Microsoft 365 Copilot |
|---|---|---|---|---|
| 既存業務データ | Google Workspace、Google Cloud、Gemini Enterprise との接続が強い。 | コネクタや Apps SDK により外部データへ接続する。 | MCP コネクタや企業内検索により外部データへ接続する。 | Microsoft Graph、SharePoint、Teams、Outlook との接続が強い。 |
| 検索 | Google Search、検索結果に基づく回答補強、URL 文脈と接続する。 | Web 検索や Deep Research と接続する。 | Web 検索やコネクタと接続する。 | Microsoft 365 Copilot Search や Graph コネクタと接続する。 |
| 管理 | Google Workspace / Cloud の管理基盤に乗る。 | ChatGPT Business / Enterprise の管理機能に乗る。 | Claude Team / Enterprise の管理機能に乗る。 | Microsoft 365 管理センターと Entra ID の管理基盤に乗る。 |
| 強い組織 | Google Workspace と Google Cloud を主軸にしている組織で強い。 | 複数サービスを横断し、ChatGPT を汎用作業面にしたい組織で強い。 | 長文、コード、慎重な分析、権限管理を重視する組織で強い。 | Microsoft 365 を業務基盤にしている組織で強い。 |
ここまでを総合すると、Gemini の背後構造は、既存プラットフォームへの埋め込みである。Google は検索、メール、文書、予定、クラウド、モバイル、ブラウザ、動画を持っている。そのため、Gemini はモデル性能だけでなく、Google の情報流通面にどこまで自然に入り込めるかが競争軸になる。ChatGPT / OpenAI が広い作業面を作り、Claude / Anthropic が長時間・高信頼・能力境界管理に寄るとすれば、Gemini / Google は、検索、Workspace、Cloud、マルチモーダル入力を束ねることで差別化する。
一般化すれば、Gemini を評価するとは、「Gemini 3.1 Pro が GPT-5.5 や Claude Sonnet 5 より賢いか」を見るだけではない。Google の情報環境を前提に、どの入力形式を扱えるか、どの検索機能に接続できるか、どの Workspace データを権限に従って扱えるか、どの Cloud 環境で企業アプリに組み込めるかを見ることである。Gemini は、モデル単体ではなく、Google 統合の中で評価してはじめて意味がある。
7. Microsoft 365 Copilot は、企業業務では権限とデータ接続が効くことを示す
Microsoft 365 Copilot は、モデル比較だけでは説明できない典型例である。ChatGPT / OpenAI や Claude / Anthropic を見るときは、基盤モデル、文脈、ツール利用、エージェント実行が重要になる。一方、Microsoft 365 Copilot を見るときは、それに加えて、Microsoft 365 の業務データ、Microsoft Graph、Entra ID、Teams、Outlook、SharePoint、Word、Excel、PowerPoint、OneDrive、Copilot Studio、Copilot コネクタをまとめて見る必要がある。つまり、Microsoft 365 Copilot の本質は、最強モデルを単体で提供することではなく、企業の情報権限構造の中に AI を埋め込むことにある。
Microsoft 365 Copilot のエージェントは、特定の業務シナリオに合わせて指示、参照知識、操作を追加し、Copilot の振る舞いを業務目的に合わせて拡張するものとして説明されている[22]。また、Copilot コネクタは、外部データソースを Microsoft 365 Copilot や Microsoft Search へ接続し、本文、メタデータ、アクセス権限リストなどを Microsoft Graph 側に取り込む仕組みとして説明されている[23]。ここでいうアクセス権限リストとは、誰がどの情報へアクセスできるかを表す権限情報である。企業内 AI では、このアクセス権限リストが極めて重要になる。
この章で確認する評価軸は、五つである。第一に、企業内のどのデータへ接続できるかである。第二に、接続したデータの権限を継承できるかである。第三に、AI の操作と回答を監査できるかである。第四に、エージェントによって業務プロセスへどこまで組み込めるかである。第五に、Microsoft 365 という既存業務基盤の中で、利用者がどれだけ自然に AI を使えるかである。この順序で見ると、Microsoft 365 Copilot はモデル性能の比較対象というより、企業情報基盤に埋め込まれた AI として評価すべきであることが分かる。
| 評価軸 | Microsoft 365 Copilot で見るべき内容 | 定量・準定量で記録すべき項目 | ChatGPT / Claude との比較上の意味 | 本章での評価結果 |
|---|---|---|---|---|
| 社内データ接続 | Outlook、Teams、SharePoint、OneDrive、Word、Excel、PowerPoint、外部業務システムへ接続できるかを見る。 | 接続可能サービス数、対象データ種別、外部コネクタ、同期方式、インデックス対象、更新頻度を記録する。 | ChatGPT / Claude が外部コネクタで業務データへ接続するのに対し、Microsoft は最初から Microsoft 365 の業務データ面を持っている。 | Microsoft 365 を業務基盤にしている組織では、モデル単体性能よりも既存データへの自然な接続が強く効く。 |
| 権限継承 | 利用者が見られる情報だけを Copilot も扱えるかを見る。 | アクセス権限リスト、Entra ID、グループ権限、SharePoint 権限、外部項目の権限、管理者ポリシーを記録する。 | 汎用 AI ではデータをアップロードして使う場面が多いが、企業内 AI では既存権限を壊さずに検索できることが重要になる。 | Microsoft 365 Copilot の価値は、社内データを扱う便利さと、権限構造を守る統制が同時に存在する点にある。 |
| 監査 | 誰が、いつ、どの情報を使い、どのような操作や出力を得たかを追跡できるかを見る。 | 監査ログ、利用ログ、管理者レポート、データ保持、電子証拠開示、コンプライアンス設定を記録する。 | ChatGPT / Claude でも Enterprise 統制は重要だが、Microsoft は既存の Microsoft 365 管理・監査基盤と接続しやすい。 | 正式な企業導入では、回答品質よりも、後から説明できる運用が採用可否を左右する場合がある。 |
| エージェント | 業務シナリオごとに指示、参照知識、操作を追加し、Copilot を拡張できるかを見る。 | エージェント数、参照知識の出所、操作、独自指示、利用可能チャネル、管理者承認、公開範囲を記録する。 | OpenAI の Apps SDK や Anthropic の MCP コネクタと同じく、AI を業務プロセスへ組み込むための実行面である。 | Microsoft 365 Copilot は、汎用チャットではなく、業務別エージェントを Microsoft 365 内に配置する方向へ進んでいる。 |
| 業務アプリ統合 | Teams、Outlook、Word、Excel、PowerPoint、SharePoint など、日常業務画面の中で AI を使えるかを見る。 | 対応アプリ、利用可能機能、ファイル編集、メール作成、会議要約、表計算補助、プレゼン生成を記録する。 | ChatGPT / Claude が AI 側へ作業を集めるのに対し、Microsoft は既存業務アプリ側へ AI を埋め込む。 | Microsoft 365 を日常的に使う組織では、AI を別画面で開くより、既存アプリ内で使えることが価値になる。 |
ここで重要なのは、企業の情報が単なる文書の集まりではないという点である。企業内の情報には、部署、役職、プロジェクト、契約、顧客、機密区分、法務要件、監査要件が結びついている。ある文書は経理部門には見えてよいが、全社員には見せられない。ある契約書は案件関係者には必要だが、別プロジェクトの担当者には不要である。ある会議録は経営判断に関わるため、検索できる範囲を厳密に管理する必要がある。企業内 AI がこの構造を無視して回答すれば、便利であっても危険である。
このため、Microsoft 365 Copilot の比較では、モデルがどれだけ賢いかだけでなく、Microsoft Graph と権限体系にどう接続されるかを見る必要がある。Microsoft Graph は、Microsoft 365 内のユーザー、グループ、ファイル、メール、予定、チャット、サイト、外部項目などを扱う基盤である。Copilot コネクタは、外部データを Microsoft 365 Copilot や Microsoft Search に持ち込むために、本文、メタデータ、アクセス権限リストを Graph 側へ登録する[23]。この設計により、AI は単に文書本文を読むのではなく、誰が読める文書なのかという権限情報も合わせて扱う。
| 企業業務の観点 | 必要になる仕様 | 定量・準定量で見る項目 | 理由 | 不十分な場合のリスク |
|---|---|---|---|---|
| 社内検索 | 文書、メール、会議、チャット、外部システムを横断して検索できる必要がある。 | 検索対象サービス、インデックス件数、対応ファイル形式、外部コネクタ、更新頻度、検索遅延を確認する。 | 業務上の答えは、Web ではなく社内の分散した記録にあることが多い。 | AI が社内情報を見つけられなければ、もっともらしい一般論を返すだけになる。 |
| 権限継承 | ユーザーが見られる情報だけを AI も見られるようにする必要がある。 | アクセス権限リスト、Entra ID、SharePoint 権限、グループ権限、外部項目の権限、権限同期の反映時間を確認する。 | AI が権限を迂回すると、情報漏洩や内部統制違反につながる。 | 本来見えない情報が回答に混ざると、AI が情報漏洩経路になる。 |
| 監査 | 誰が、いつ、どの情報を使って、どのような出力を得たかを追跡できる必要がある。 | 監査ログ、利用履歴、管理者レポート、保持期間、電子証拠開示対応、情報漏洩防止機能連携を確認する。 | 企業利用では、後から説明できない AI 利用は正式運用に乗せにくい。 | 問題発生時に、情報取得経路や判断根拠を追跡できなくなる。 |
| 業務アプリ連携 | Outlook、Teams、SharePoint、Word、Excel、PowerPoint、業務システムと接続する必要がある。 | 対応アプリ、読み取り権限、書き込み権限、操作、承認フロー、外部システム連携を確認する。 | AI が業務の外側にいると、最終的には人間が転記と確認を行うことになる。 | AI の回答は便利でも、実際の業務処理へつながらず、二重入力が残る。 |
| 管理者制御 | どのユーザーがどのエージェント、コネクタ、操作を使えるかを管理できる必要がある。 | 管理者承認、公開範囲、エージェント管理、コネクタ管理、利用制限、ポリシー設定を確認する。 | 企業では、個人利用ではなく組織単位で AI の利用範囲を制御する必要がある。 | 便利なエージェントが乱立すると、権限、品質、責任範囲が不明確になる。 |
この観点から見ると、Microsoft 365 Copilot は、AI を企業の情報流通に埋め込むサービスである。たとえば、会議の要約を作る場合、必要なのは自然な文章生成だけではない。参加者、予定表、Teams 会議、会議チャット、共有資料、過去の関連メール、プロジェクト文書を、利用者の権限に従って参照する必要がある。提案文書を作る場合も、Word の文章生成だけでは足りない。過去提案、見積、契約条件、社内レビュー、顧客情報、承認フローが関わる。こうした作業では、モデルの一般知識よりも、社内情報を正しく取り出し、権限を守り、既存アプリの中で結果を扱えることが価値になる。
| 業務シナリオ | AI が参照すべき情報 | 必要な接続 | 必要な統制 | 評価すべき成果 |
|---|---|---|---|---|
| 会議要約 | 会議音声、会議チャット、参加者、共有資料、過去の関連議論を参照する。 | Teams、Calendar、OneDrive、SharePoint、Outlook への接続が必要になる。 | 参加者権限、会議録の保持、機密会議の扱い、外部参加者の有無を管理する必要がある。 | 単なる要約ではなく、決定事項、未決事項、担当者、期限が正しく抽出されるかを見る。 |
| 提案書作成 | 過去提案、顧客情報、契約条件、製品資料、見積情報、社内レビューを参照する。 | Word、PowerPoint、SharePoint、CRM、外部コネクタへの接続が必要になる。 | 顧客別アクセス権、契約上の秘密情報、版管理、承認フローを管理する必要がある。 | 文章の自然さだけでなく、事実関係、価格、条件、過去資料との整合を確認する。 |
| 社内問い合わせ | 規程、手順書、FAQ、チケット履歴、担当部署、最新通達を参照する。 | SharePoint、Teams、外部ナレッジベース、ServiceNow などへの接続が必要になる。 | 部署別閲覧権限、古い手順の除外、回答根拠の提示、エスカレーションを管理する必要がある。 | 回答が正しいだけでなく、根拠文書と更新日が追跡できるかを見る。 |
| Excel 分析 | 表データ、前提条件、過去レポート、部門別数値、関連メールを参照する。 | Excel、SharePoint、OneDrive、Outlook、Power BI への接続が必要になる。 | 数値の出所、編集権限、閲覧範囲、計算式変更、監査ログを管理する必要がある。 | グラフや文章だけでなく、計算根拠、式の妥当性、再現性を確認する。 |
| 業務エージェント | 業務ルール、社内データ、外部システム、承認条件、例外処理を参照する。 | Copilot Studio、操作、コネクタ、Microsoft Graph、外部 API への接続が必要になる。 | 実行権限、承認点、失敗時停止、ログ、管理者承認、利用者範囲を管理する必要がある。 | 回答ではなく、業務プロセスを安全に短縮できるかを見る。 |
ここでエージェントの意味も明確になる。Microsoft 365 Copilot のエージェントは、単なるチャットボットではない。業務シナリオに合わせて指示、参照知識、操作を追加し、特定業務に必要な知識と操作を持たせる仕組みである[22]。指示はエージェントの振る舞いや目的を定義する。参照知識は参照すべき業務知識を与える。操作は外部システムへの操作や処理を担う。つまりエージェントは、汎用 Copilot を、経理、法務、人事、営業、情報システムサポート、開発支援などの業務単位へ落とし込むための仕組みである。
| エージェント構成要素 | 役割 | 定量・準定量で見る項目 | 誤解しやすい点 | 実務上の意味 |
|---|---|---|---|---|
| 指示 | エージェントの目的、制約、回答方針、業務上の振る舞いを定義する。 | 指示文の管理方法、更新履歴、公開範囲、承認フロー、禁止事項を確認する。 | 単なるプロンプトではなく、業務エージェントの振る舞いを決める仕様である。 | 曖昧な指示は、業務判断のぶれや誤回答につながる。 |
| 参照知識 | エージェントが参照する文書、データ、ナレッジソースを定義する。 | 参照元、ファイル数、更新頻度、権限継承、検索対象、古い情報の扱いを確認する。 | 知識を追加すれば必ず正確になるわけではなく、古い情報や矛盾した情報も混ざりうる。 | 業務特化エージェントでは、どの知識を参照するかが回答品質の中心になる。 |
| 操作 | エージェントが外部システムへ問い合わせたり、処理を実行したりする手段を定義する。 | 実行可能操作、承認点、失敗時処理、ロールバック、監査ログ、書き込み権限を確認する。 | 回答と違い、操作は実際の業務状態を変更する可能性がある。 | 操作を持つエージェントは、便利さと同時に誤操作リスクを持つ。 |
| 公開範囲 | 誰がそのエージェントを使えるかを定義する。 | ユーザー、グループ、部署、テナント、共有範囲、管理者承認を確認する。 | 有用なエージェントでも、全社公開してよいとは限らない。 | 業務別エージェントでは、対象利用者と対象データの整合が必要である。 |
| 運用管理 | エージェントの品質、更新、利用状況、リスクを継続的に管理する。 | 利用回数、失敗率、ユーザー評価、更新履歴、監査、停止手順を確認する。 | エージェントは作って終わりではなく、業務変更に合わせて保守する必要がある。 | 業務エージェントが増えるほど、エージェント管理そのものが情報システム運用になる。 |
Microsoft 365 Copilot の背後構造は、企業内業務では AI の価値が情報権限構造に依存するということである。Web 上の一般知識を答える AI であれば、モデル性能と検索能力が中心になる。しかし、企業内業務では、正しい答えは社内のどこかにあることが多い。その情報は、部署、プロジェクト、契約、顧客、職位、機密区分によってアクセス権が分かれている。したがって、企業 AI の価値は、社内情報へ深く接続しながら、見てよい情報だけを見るという矛盾した要求を満たせるかで決まる。
| 比較観点 | 汎用チャット AI | Microsoft 365 Copilot | 企業業務での意味 |
|---|---|---|---|
| 主な入力 | ユーザーが入力した文章、アップロードしたファイル、接続済みコネクタの情報を使う。 | Microsoft 365 のメール、文書、予定、会議、チャット、SharePoint、外部コネクタを使う。 | 業務で自然に発生する情報を、そのまま AI の作業対象にしやすい。 |
| 権限 | 接続やアップロードの設計次第で権限管理が変わる。 | Microsoft 365 のユーザー、グループ、アクセス権限リスト、Graph、管理者ポリシーに乗る。 | 既存の情報権限構造を維持しやすい。 |
| 作業場所 | AI サービスの会話画面が中心になる。 | Teams、Outlook、Word、Excel、PowerPoint、SharePoint など既存業務画面の中で使う。 | 利用者が業務アプリを離れずに AI を使える。 |
| 導入判断 | モデル性能、使いやすさ、外部コネクタ、価格を中心に見る。 | Microsoft 365 基盤、権限設計、管理者制御、監査、既存業務との整合を中心に見る。 | 企業では、AI 単体の性能より、既存基盤との適合が採用可否を左右する。 |
ここから分かるのは、企業導入では「最も賢いモデル」がそのまま最適解になるとは限らないということである。企業で価値を持つ AI は、情報権限構造を壊さず、既存の業務データに接続し、操作と結果を監査できる AI である。Microsoft 365 Copilot は、その競争軸を明確に示している。モデル性能は重要である。しかし、企業業務では、誰が何を見てよいか、どの情報を根拠にしたか、どの操作が実行されたか、後から説明できるかが、それ以上に重要になる場合がある。
一般化すれば、Microsoft 365 Copilot は、AI の企業導入がデータ接続と統制の問題であることを示している。ChatGPT / OpenAI が広い作業面を作り、Claude / Anthropic が長時間・高信頼・能力境界管理に寄り、Gemini / Google が Google 統合で差別化するなら、Microsoft 365 Copilot は Microsoft 365 の業務データ、Graph、権限、監査、業務アプリ統合で差別化する。企業内 AI では、モデルの賢さだけでなく、情報権限構造を守ったまま仕事に入れるかが、最終的な価値を決める。
8. 開発エージェントは、コードを書く AI ではなく開発変更を前に進める AI である
開発領域では、AI の変化が特に分かりやすい。かつての開発支援 AI は、コード補完や関数生成が中心だった。開発者がエディタでコードを書いているときに、次の行を提案する。関数の雛形を作る。エラーの意味を説明する。これは有用だが、あくまで開発者の手元を補助する機能である。現在の競争軸は、それより先へ移っている。AI がリポジトリを読み、課題を理解し、変更方針を立て、ファイルを編集し、コマンドを実行し、テスト結果を見て修正し、人間がレビューできる差分へまとめることが問われている。
この章の中心命題は、開発 AI の本質が「コードを書くこと」ではなく、「開発変更を前に進めること」へ移っているという点である。実務のソフトウェア開発では、コードを書く行為は全体の一部でしかない。まず、何を直すべきかを理解しなければならない。次に、既存設計や依存関係を壊さない変更方針を立てなければならない。そのうえで、複数ファイルを編集し、テストし、失敗すれば原因を調べ、修正し、最終的にレビュー可能な差分として提示しなければならない。したがって、開発エージェントの比較では、生成されるコード片の見た目よりも、変更を開発プロセスに乗せられるかが重要になる。
GitHub Copilot クラウド上のエージェントは、この変化をよく示している。GitHub Copilot クラウド上のエージェントは、リポジトリ上で作業し、MCP サーバー、独自エージェント、フックなどを使って外部データや検証手順と接続できるものとして説明されている[24]。また、GitHub Copilot の MCP 説明では、MCP が Copilot をほかのシステムへ拡張する規格として説明されている[25]。ここで重要なのは、AI が単にコードを提案するのではなく、開発環境、リポジトリ、外部ツール、検証手順に接続されることである。
Devin も同じ方向を示している。Devin は、自律型 AI ソフトウェアエンジニアとして、コードを書き、実行し、テストする存在として説明されている[26]。Cursor は、IDE 体験をエージェント中心へ寄せ、開発者がローカルまたはクラウドのエージェントを使って作業する方向を示している[27]。これらは、いずれも「モデルがコードを書けるか」だけでは比較できない。どの隔離実行環境で実行するか、どのリポジトリにアクセスできるか、どのコマンドを実行できるか、どの変更を許すか、どのログを残すか、どこで人間の承認を挟むかが重要になる。
| 開発 AI の段階 | 主な役割 | 具体的にできること | 定量・準定量で見る項目 | 限界 |
|---|---|---|---|---|
| 補完 | 開発者が書いているコードの続きを提案する。 | 次の行、関数、コメント、型定義、定型処理を生成する。 | 補完精度、応答速度、対応言語、IDE 対応、ローカル文脈の利用範囲を見る。 | 作業の目的、既存設計、テスト結果、複数ファイルの整合までは十分に扱えない。 |
| 会話支援 | コードについて質問に答え、修正案や説明を返す。 | エラー説明、リファクタ案、テスト案、設計相談、レビュー観点を提示する。 | コード理解範囲、入力可能ファイル数、説明品質、差分提案、根拠提示を見る。 | 回答が正しく見えても、実際にビルドやテストを通るとは限らない。 |
| 作業実行 | AI がファイルを編集し、コマンドを実行し、結果を見て再修正する。 | 複数ファイル変更、テスト実行、静的解析、ログ確認、失敗時の修正を行う。 | 実行環境、コマンド実行可否、テスト実行可否、失敗時の再試行、作業ログ、権限を見る。 | 破壊的操作、秘密情報、外部送信、誤修正を防ぐ制御が必要になる。 |
| 開発委譲 | 課題や依頼から、変更案をレビュー可能な単位へまとめる。 | リポジトリ調査、変更方針作成、分岐作成、実装、検証、Pull Request 作成に近い流れを進める。 | リポジトリアクセス、分岐作成、Pull Request 作成、継続的インテグレーション連携、レビュー可能性、差分説明、承認点を見る。 | 最終的な設計判断、マージ判断、責任あるリリース判断は人間側に残る。 |
この表から分かるのは、開発 AI の段階が上がるほど、比較すべき仕様がモデル性能から実行環境へ移ることである。補完では、速度や補完精度が重要である。会話支援では、コード理解と説明品質が重要である。作業実行では、ファイル編集、コマンド実行、テスト、失敗時の復旧が重要になる。開発委譲では、リポジトリへのアクセス、分岐、Pull Request、継続的インテグレーション、レビュー可能性、責任分界が問題になる。つまり、上位の開発エージェントほど、コード生成能力だけでは評価できない。
| 評価軸 | 確認すべき内容 | なぜ重要か | 比較時に見る具体項目 |
|---|---|---|---|
| リポジトリ理解 | AI が対象リポジトリの構造、依存関係、テスト構成、既存設計を読めるかを見る。 | 実務の修正では、正しいコード片よりも、既存構造に合う変更が重要になる。 | 読み取り可能ファイル数、検索範囲、関連ファイル抽出、依存関係把握、既存テスト参照を確認する。 |
| 実行環境 | AI がどの隔離実行環境やクラウド環境で作業するかを見る。 | コードは生成しただけでは不十分であり、実行して初めて問題が見える。 | OS、依存関係インストール、ネットワーク制限、秘密情報の扱い、永続化、環境再現性を確認する。 |
| 検証 | AI がテスト、ビルド、静的解析、型検査を実行できるかを見る。 | 生成された変更が動くかどうかは、自然文の説明ではなく検証結果で確認する必要がある。 | テスト実行可否、失敗時の再試行、ログ提示、検証範囲、継続的インテグレーション連携を確認する。 |
| 変更管理 | AI が変更を差分として整理し、レビュー可能な単位にまとめられるかを見る。 | 実務開発では、変更内容を人間が読め、戻せ、責任を持って統合できる必要がある。 | 差分、コミット、分岐、Pull Request、変更理由、影響範囲、元に戻す手順を確認する。 |
| 権限 | AI がどのファイル、コマンド、外部サービス、秘密情報にアクセスできるかを見る。 | 開発エージェントは実際に操作するため、権限設計を誤ると被害が大きい。 | 読み取り権限、書き込み権限、承認プロンプト、秘密情報保護、外部送信制御を確認する。 |
| ログと説明 | AI が何を読んだか、何を実行したか、なぜ変更したかを説明できるかを見る。 | 人間がレビューし、採否判断し、問題時に原因を追うには作業履歴が必要になる。 | 作業ログ、コマンド履歴、参照ファイル、失敗履歴、最終説明、レビュー用要約を確認する。 |
この評価軸で見ると、GitHub Copilot、Devin、Cursor は、それぞれ違う位置にある。GitHub Copilot クラウド上のエージェントは、GitHub のリポジトリ、課題、Pull Request、MCP、フックと結びつく点が強い。Devin は、AI ソフトウェアエンジニアとして、クラウド上で作業を進める方向が強い。Cursor は、IDE 体験そのものをエージェント中心に作り替え、開発者がローカルまたはクラウドのエージェントと並行して作業する方向が強い。つまり、これらはすべて開発エージェントだが、GitHub 中心、クラウド委譲中心、IDE 体験中心という違いがある。
| 対象 | 中心になる場所 | 強い評価軸 | 向く作業 | 比較時の注意点 |
|---|---|---|---|---|
| GitHub Copilot クラウド上のエージェント | GitHub のリポジトリ、課題、Pull Request、クラウド上のエージェントの作業環境。 | リポジトリアクセス、Pull Request 作成、MCP、フック、GitHub 連携、レビュー可能性。 | GitHub 上の課題から修正案を作り、レビュー可能な差分へ進める作業に向く。 | GitHub を開発基盤にしていない環境では、強みが十分に出ない場合がある。 |
| Devin | クラウド上の自律型 AI ソフトウェアエンジニアの作業環境。 | 長時間作業、コード実行、テスト、タスク委譲、作業ログ、クラウド実行。 | 明確な開発タスクを渡し、AI に調査、実装、検証を進めさせる作業に向く。 | 汎用チャット AI ではなく、開発タスクに強く寄った製品として評価する必要がある。 |
| Cursor | IDE 内または IDE と連動したエージェント中心の開発体験。 | エディタ統合、ローカル文脈、複数エージェント、開発者との共同作業、利用体験。 | 開発者が自分でレビューしながら、エージェントと並行して実装や修正を進める作業に向く。 | モデル自体の能力だけでなく、IDE 体験と開発者の操作設計を含めて評価する必要がある。 |
ここで重要なのは、開発エージェントが人間の開発者をそのまま置き換えるという話ではない。むしろ重要なのは、開発作業が分解され、人間が行う部分と AI に任せる部分が変わることである。AI は、調査、候補実装、テスト実行、単純修正、影響範囲の整理を進められる。一方で、人間は、問題設定、設計判断、レビュー、採否判断、セキュリティ確認、リリース判断を担う必要がある。AI が作業を前に進めるほど、人間の役割はコードを書くことから、変更を評価し、責任を持って統合することへ寄る。
| 役割 | AI に任せやすい部分 | 人間側に残る部分 | 理由 |
|---|---|---|---|
| 調査 | 関連ファイルの検索、既存実装の把握、エラー箇所の候補抽出を任せやすい。 | 何を問題とみなすか、どの方針を採るかの判断は人間側に残る。 | AI は候補を広く探せるが、業務上の優先順位や設計意図は人間が決める必要がある。 |
| 実装 | 局所修正、テスト追加、定型的なリファクタ、ドキュメント更新を任せやすい。 | アーキテクチャ変更、責任境界、互換性判断、長期保守性の判断は人間側に残る。 | 実装は生成できても、システム全体の将来責任は AI には引き受けられない。 |
| 検証 | テスト実行、コード規約検査、静的解析、失敗ログの読み取りを任せやすい。 | 検証範囲が十分か、未検証リスクを許容できるかの判断は人間側に残る。 | テストが通ることと、本番で安全に動くことは同じではない。 |
| レビュー | 変更要約、影響範囲の説明、差分の注意点整理を任せやすい。 | 採用可否、マージ、リリース、障害時責任の判断は人間側に残る。 | AI の説明は補助資料であり、最終判断の責任は開発組織に残る。 |
この章の結論は、開発 AI の比較では、モデル名より実行ハーネスが重要になるということである。優れたモデルでも、コードを実行できなければ検証できない。検証できても、権限やログが不十分なら正式な開発プロセスに乗せにくい。Pull Request を作れても、人間がレビューできる差分、説明、テスト結果、元に戻す手順の見通しがなければ安心して統合できない。したがって、開発エージェントの本質は、コード生成ではなく、開発変更を人間がレビューできる単位まで進めることにある。
一般化すれば、開発エージェントは「開発者の代替」ではなく、「開発プロセスの分担を変える仕組み」である。AI がコードを書くほど、人間が不要になるのではない。AI が調査、実装案、検証、差分整理を進めることで、人間は問題設定、設計判断、レビュー、採否判断、責任ある統合に集中するようになる。これは、開発 AI の価値を低く見る話ではない。むしろ、開発 AI の価値を正しく測るには、生成コードの量ではなく、開発変更をどこまで安全に前進させられるかを見る必要がある、ということである。
9. Perplexity は、汎用 AI ではなく引用付き調査基盤として見る
Perplexity は、ChatGPT や Claude と完全に横並びで比較するよりも、検索、引用、調査統合に特化した AI として見るほうが分かりやすい。ChatGPT や Claude は、文章作成、構成整理、コード作業、長文読解、ファイル処理、対話的な検討など、広い作業に使われる。一方、Perplexity の中心的な価値は、問いに対して Web を調べ、出典を示し、複数の情報をまとめて回答することにある。つまり、Perplexity は「何でもする汎用 AI」というより、「調査の入口と根拠確認を支援する AI」である。
この違いは、AI サービスの比較では重要である。たとえば、ある製品の最新仕様を確認したい場合、モデルの内部知識だけでは足りない。仕様は変更される。価格も変わる。提供地域、利用制限、モデル名、API 単価、利用可能な機能も変わる。こうした情報を扱うには、AI が過去に学習した知識だけではなく、現在の公式ページやドキュメントを確認し、どの情報源に基づいているかを示す必要がある。Perplexity は、この「調べながら答える」流れを主な価値としている。
Perplexity の API Platform では、Agent API が Web 検索、URL 取得、推論の強さを調整する機能を備えたエージェント型の作業手順のための基盤として説明されている[28]。ここでいう Web 検索は、Web 上の情報を検索することである。URL 取得は、指定されたページの内容を取得することである。推論の強さを調整する機能は、回答を作るときの推論の強さや振る舞いを調整する仕組みである。Agent API のクイックスタートも、検索と最先端モデルを組み合わせてエージェント型の作業手順を構成する入口として位置づけられている[29]。つまり Perplexity は、検索、URL 取得、モデル推論を組み合わせ、調査作業を API として扱えるようにしている。
| 比較観点 | 一般的なチャット AI | Perplexity 型の調査 AI | 定量・準定量で見る項目 | 実務上の意味 |
|---|---|---|---|---|
| 情報源 | モデルの内部知識、会話文脈、アップロードされたファイル、接続済みコネクタの情報を使う。 | Web 検索、URL 取得、複数ソースの確認を前提に回答する。 | 検索回数、取得 URL 数、参照ソース数、引用表示、検索対象範囲を確認する。 | 最新情報や変化しやすい仕様を扱うとき、内部知識だけに頼らずに済む。 |
| 出典 | 明示的に要求しなければ、根拠や出典が曖昧になることがある。 | 引用付き回答や出典付き調査を主な価値としている。 | 引用の有無、引用単位、一次情報の比率、出典の多様性、リンク切れの扱いを確認する。 | あとから情報を確認し直しやすく、調査メモや比較記事に使いやすい。 |
| 得意な作業 | 文章作成、構成整理、コード作業、ファイル処理、対話的な検討に強い。 | 最新情報の確認、複数ソース比較、仕様調査、根拠付き要約、調査レポート作成に強い。 | 調査対象件数、要約の長さ、レポート生成、検索の深さ、再検索の可否を確認する。 | 調べものでは強いが、開発作業や業務アプリ操作まで同じように強いとは限らない。 |
| 弱点 | 検索機能を使わない場合、最新情報や出典確認に弱くなることがある。 | 検索結果に依存するため、出典の品質、検索漏れ、古いページの混入に注意が必要になる。 | 検索結果の更新日、公式情報の有無、重複ソース、引用の偏り、検索失敗時の挙動を確認する。 | 引用があるから正しいとは限らず、出典そのものの信頼性を確認する必要がある。 |
| 比較対象 | ChatGPT、Claude、Gemini のチャット機能やファイル処理機能と比較される。 | ChatGPT Deep Research、Gemini Deep Research、Google Search、従来の調査作業と比較される。 | 検索深度、引用品質、調査時間、検索単価、出典の追跡性を確認する。 | 汎用 AI の競合というより、調査ワークフローの競合として見るほうが正確である。 |
ここで注意すべきなのは、引用が付いていることと、内容が正しいことは同じではないという点である。引用は、回答の根拠を確認するための入口である。引用があるからといって、その出典が一次情報であるとは限らない。古い情報、二次情報、広告的なページ、誤った解釈を含む記事が混ざる可能性もある。したがって、Perplexity 型の調査 AI を使う場合でも、重要な判断では、公式ドキュメント、企業の一次発表、API 仕様、論文、規制当局の文書などを確認する必要がある。
AI モデルや AI サービスの調査では、この点が特に重要になる。モデル名、一度に扱える文脈量、価格、提供プラン、API 提供状況、ツール利用、データ保持、エンタープライズ機能は頻繁に変わる。たとえば、あるモデルが発表時点ではプレビューであっても、数週間後には一般提供されている可能性がある。逆に、一般提供されていた機能が、地域やプランによって制限される場合もある。そのため、AI サービスの比較では、「何を知っているか」よりも、「どのページを確認し、どの時点の情報として記録したか」が重要になる。
| 調査対象 | 確認すべき情報 | 優先すべき出典 | Perplexity 型 AI が役立つ点 | 人間が確認すべき点 |
|---|---|---|---|---|
| モデル仕様 | 最大入力トークン、最大出力トークン、対応モダリティ、知識の基準日、推論制御を確認する。 | 公式モデル一覧、API ドキュメント、リリースノートを優先する。 | 複数モデルの仕様ページを探し、比較の入口を作れる。 | 最終的な数値は公式ページで確認し、参照日を記録する必要がある。 |
| 価格 | 入力単価、出力単価、キャッシュ済み入力、一括処理、優先処理、検索課金、エージェント実行費用を確認する。 | 公式価格、API 価格、請求関連ドキュメントを優先する。 | 価格ページや変更履歴を見つけ、比較表の材料を集められる。 | 価格は変更されやすいため、記事執筆時点の数字であることを明示する必要がある。 |
| 提供範囲 | 一般提供、プレビュー、限定提供、地域制限、プラン制限、審査済み利用者向けの限定提供を確認する。 | 公式発表、提供状況ドキュメント、ヘルプセンターを優先する。 | 複数ページに分かれた提供条件を探しやすい。 | 発表記事と実際の API 提供状況がずれていないか確認する必要がある。 |
| 安全制御 | 利用制限、安全制御、別モデルへの切り替え、データ保持、監査、管理者制御を確認する。 | システムカード、安全性文書、企業向け文書、ポリシー文書を優先する。 | 関連する安全性文書を横断的に探せる。 | 安全性の説明は抽象的になりやすいため、実装上の制御項目まで確認する必要がある。 |
| 企業導入 | シングルサインオン、ユーザー管理連携、監査ログ、権限継承、コネクタ、管理者制御を確認する。 | 企業向け文書、管理者向け文書、コネクタ文書を優先する。 | 企業向け機能の一覧化や比較表作成に役立つ。 | 組織の既存基盤に合うかどうかは、実際の認証、権限、監査要件で確認する必要がある。 |
この表が示すように、Perplexity 型の調査 AI は、調査の最初の段階で強い。候補となる情報源を探し、複数ページを比較し、要点をまとめ、引用を付ける。そのため、仕様が頻繁に変わる領域では非常に有用である。一方で、最終的な判断まで AI に任せるべきではない。特に、料金、API 仕様、法務、セキュリティ、医療、金融、規制のように誤りの影響が大きい情報では、引用元そのものを読む必要がある。
ここで重要なのは、Perplexity が ChatGPT や Claude より上か下かという話ではない。役割が違うという話である。ChatGPT や Claude は、文章を練り、構成を作り、ファイルを読み、コードや長文を扱い、対話しながら考える用途に強い。Perplexity は、検索し、出典を示し、複数情報を束ね、調査の足場を作る用途に強い。したがって、Perplexity は汎用 AI の代替というより、調査工程の一部を高速化する基盤として見るべきである。
| 作業工程 | Perplexity が担いやすいこと | ChatGPT / Claude が担いやすいこと | 人間が担うべきこと |
|---|---|---|---|
| 情報収集 | 関連ページを探し、複数ソースを集め、引用付きで要点を整理する。 | 与えられた資料や検索結果をもとに、論点を整理する。 | どの情報源を信頼するか、どこまで調べるかを決める。 |
| 比較 | 複数サービスの仕様や発表を横断的に集める。 | 比較軸を設計し、表に整理し、文章として論理展開する。 | 比較軸が目的に合っているかを判断する。 |
| 検証 | 出典リンクを提示し、追加検索の入口を作る。 | 資料間の矛盾や論理の抜けを整理する。 | 公式ページを読み、最終的な事実確認を行う。 |
| 執筆 | 調査メモや出典候補を作る。 | 記事構成、説明、比較、一般化、結論を組み立てる。 | 採用する論点、捨てる資料、最終的な主張を決める。 |
この章の一般化は、調査用途では「どのモデルが賢いか」だけでなく、「どのように調べ、どの出典に基づき、どの範囲を確認したか」を見る必要があるということである。Perplexity は、AI が検索エンジンと調査レポート作成を統合する方向を示している。ただし、検索と引用は、判断の代替ではなく、判断の材料である。出典付きで調べる力は重要だが、その出典をどう評価し、どの事実を採用し、どの結論へ進むかは、なお人間側の責任として残る。
10. 重み公開型 / 低コスト勢は、自前運用と独立性の軸を担う
OpenAI、Anthropic、Google、Microsoft のような大手の AI サービスは、完成度が高い。モデル、チャット画面、API、外部ツール接続、企業管理機能、開発エージェントがまとまって提供されるため、利用者は比較的すぐに使い始められる。しかし、AI の全体像はそれだけではない。Mistral、DeepSeek、Llama、xAI などは、別の意味で重要である。これらは、最高性能の統合サービスというより、コスト、自前運用、データ管理、改変可能性、ベンダーロックイン回避という軸を担っている。
ここでいう重み公開型とは、モデルの重み、つまり AI モデルの内部パラメータが公開されている、または利用者が入手できる形で提供されていることを指す。重みが公開されていれば、利用者は自分たちの環境でモデルを動かしたり、用途に合わせて調整したり、クラウド事業者を変えたりしやすくなる。ただし、重み公開型は「何もしなくても安全で便利に使える」という意味ではない。モデルを動かす計算資源、監視、セキュリティ、利用制限、品質評価、障害対応は、利用者側が考えなければならない。
また、低コスト API という軸も重要である。API とは、アプリケーションやシステムから AI モデルを呼び出すための接口である。チャット画面で使うのではなく、業務システム、検索システム、開発ツール、社内アプリなどに AI を組み込む場合、API の入力単価、出力単価、長文利用時の費用、呼び出し回数が大きな問題になる。高性能モデルがいくら優れていても、毎日大量に呼び出す用途では費用が合わない場合がある。そのため、Mistral、DeepSeek、xAI などの低コストまたは自前運用しやすい選択肢には、実務上の意味がある。
この章で確認する評価軸は、五つである。第一に、モデルの重みが公開されているかである。第二に、自社や自分の環境で運用できるかである。第三に、API 単価や推論コストがどれくらいかである。第四に、商用利用や改変がどこまで許されるかである。第五に、統合サービスとして何が不足し、その不足分を利用者側がどこまで担う必要があるかである。この軸で見ると、OpenAI / Claude と重み公開型 / 低コスト勢は、単純な上下関係ではなく、用途の違う選択肢であることが分かる。
| 評価軸 | 見るべき内容 | 定量・準定量で記録すべき項目 | 実務上の意味 | 注意点 |
|---|---|---|---|---|
| 重み公開 | モデルの重みを利用者が入手し、自分の環境で動かせるかを見る。 | 重み公開型か、利用ライセンス、商用利用条件、再配布条件、改変可否を確認する。 | ベンダーのサービス停止や価格変更に依存しにくくなる。 | 重みが公開されていても、安全対策、運用、評価は利用者側の責任になる。 |
| 自前運用 | 自社サーバー、専用クラウド、閉域環境でモデルを動かせるかを見る。 | 必要 GPU、メモリ、推論速度、同時実行数、運用監視、障害対応、ログ管理を確認する。 | 機密データを外部サービスへ送れない組織でも AI を使いやすくなる。 | インフラ費用、技術者、セキュリティ設計、保守が必要になる。 |
| 低コスト API | 外部 API として大量利用したときの費用を見る。 | 入力単価、出力単価、キャッシュ済み入力、一度に扱える文脈量、最大出力、呼び出し上限、月額費用を確認する。 | 大量の分類、要約、検索補助、軽量エージェントなどで採算を取りやすくなる。 | 安い API でも、品質、可用性、サポート、データ保持条件を確認する必要がある。 |
| 改変可能性 | 用途に合わせて追加調整、蒸留、追加学習、システム統合ができるかを見る。 | 追加調整可否、学習データ条件、派生モデル作成、ライセンス制限、評価手法を確認する。 | 特定業務、特定言語、社内用語、独自フォーマットへ適応しやすくなる。 | 改変したモデルの品質、安全性、説明責任は利用者側で検証しなければならない。 |
| 統合機能 | チャット画面、エージェント、コネクタ、管理機能、監査機能がどこまで揃っているかを見る。 | シングルサインオン、監査ログ、権限管理、外部コネクタ、ツール利用、管理者制御、サポート体制を確認する。 | 完成済みサービスとして使えるか、自分たちで周辺機能を作る必要があるかを判断できる。 | 重み公開型モデルは、モデル本体は使えても、企業向け統制や業務アプリ統合が不足する場合がある。 |
Mistral は、この軸で見ると分かりやすい。Mistral Medium 3.5 は、作業を進めるエージェントやコード作業用途に最適化された高性能マルチモーダルモデルとして説明され、修正版 MIT ライセンスのもとで公開された重みが提供されるとされている[30]。マルチモーダルモデルとは、文章だけでなく、画像など複数種類の入力を扱えるモデルのことである。Mistral の重要性は、単に ChatGPT や Claude と同じようなサービスを出していることではない。高性能モデルを、比較的開かれた形で使える選択肢として提供している点にある。
DeepSeek も、別の意味で重要である。DeepSeek V4 プレビューは、V4-Pro と V4-Flash を提供し、OpenAI 形式や Anthropic 形式の API と互換的に利用できる方向を示している[31]。互換的に利用できるとは、既存の OpenAI API や Anthropic API を前提にしたアプリケーションから、比較的少ない変更で DeepSeek 側のモデルを呼び出せる可能性があるという意味である。これは、コストを下げたい場合や、特定用途で複数ベンダーを切り替えたい場合に重要になる。
Meta の Llama 4 は、最初から複数種類の入力を扱う前提で設計されたなモデル群として発表されている[32]。最初から複数種類の入力を扱う前提で設計されたとは、後から画像処理機能を付け足したというより、文章や画像など複数種類の情報を最初から扱う前提で設計された、という意味である。Llama 系の重要性は、巨大な重み公開型周辺環境を持つことである。研究者、企業、個人開発者、クラウド事業者が、Llama 系をもとに派生モデルやアプリケーションを作れる。この点は、閉鎖型サービスとは異なる。
xAI は、推論、コード、音声、画像、動画を扱う高性能 AI モデル群を API として提供する方向を示している[33]。xAI のような API 事業者を見るときは、モデル能力だけでなく、単価、リアルタイム情報への接続、音声や画像や動画の扱い、企業向け管理機能の成熟度を見る必要がある。安価で高速な API は魅力的だが、企業統制、監査、業務データ接続、サポート体制まで揃っているかは別の問題である。
| 系統 | 主な意味 | 定量・準定量で見る項目 | 強み | 注意点 |
|---|---|---|---|---|
| Mistral | 高性能モデルを比較的開かれた形で使う選択肢である。 | 公開された重み、ライセンス、一度に扱える文脈量、入力単価、出力単価、対応モダリティ、コード作業評価を確認する。 | 公開された重み、欧州系、エージェント/ コード作業用途、低コスト寄りの選択肢を持つ。 | ChatGPT や Claude のような完成済み統合サービスとして使う場合は、周辺機能を別途確認する必要がある。 |
| DeepSeek | 低コスト API と互換性を重視した選択肢である。 | API 互換性、一度に扱える文脈量、入力単価、出力単価、Pro / Flash の違い、提供地域、データ保持条件を確認する。 | 低コスト、長文、OpenAI / Anthropic 互換 API、自前組み込みのしやすさがある。 | 企業統制、法務、サポート、データ所在地、運用責任は利用側で確認する必要がある。 |
| Llama | 重み公開型周辺環境の中心的な選択肢である。 | モデルサイズ、必要計算資源、ライセンス、追加調整可否、派生モデル数、商用条件を確認する。 | 自前運用、研究開発、カスタマイズ、派生モデル開発に向く。 | 商用条件、推論コスト、品質評価、セーフガード設計を自分たちで考える必要がある。 |
| xAI | 低単価 API とリアルタイム情報連携の選択肢である。 | API 単価、一度に扱える文脈量、対応モダリティ、推論、コード、音声、画像、動画、企業向け機能を確認する。 | 低単価 API、リアルタイム情報、複数モダリティ対応を打ち出す。 | 企業統制や業務データ接続の細部は、Microsoft、OpenAI、Anthropic と別に検証する必要がある。 |
ここで大事なのは、重み公開型 / 低コスト勢を「安い代替品」とだけ見ないことである。たしかに費用は大きな論点である。しかし、それ以上に重要なのは、AI をどこで動かし、どのデータを外に出さず、どのベンダーに依存し、どこまで改変できるかである。たとえば、機密性の高い社内文書を外部 API に送れない場合、自前運用できるモデルは有力な選択肢になる。大量のログ分類や定型要約を毎日実行する場合、高価な最先端モデルだけでは費用が合わない。特定業務に合わせてモデルを調整したい場合、重みや学習手段にアクセスできることが意味を持つ。
| 利用場面 | 統合型サービスが向く場合 | 重み公開型 / 低コスト勢が向く場合 | 判断基準 |
|---|---|---|---|
| 一般業務 | すぐに高品質なチャット、ファイル処理、外部ツール接続を使いたい場合に向く。 | 特定業務だけを低コストで大量処理したい場合に向く。 | 必要なのが完成済み体験か、大量処理の費用対効果かで判断する。 |
| 機密データ | 企業向け契約、データ保持、監査、権限管理が十分に整っている場合に向く。 | 外部 API に送れないデータを、自社環境内で処理したい場合に向く。 | データをどこへ送れるか、誰が管理するか、ログをどう残すかで判断する。 |
| 研究開発 | 最新の高性能モデルをすぐ試したい場合に向く。 | モデル構造、推論、追加調整、派生モデル作成を研究したい場合に向く。 | 使いたいのが完成品か、改変可能な材料かで判断する。 |
| 社内アプリ組み込み | 高品質な API とサポートを使い、短期間で組み込みたい場合に向く。 | 費用、ベンダー依存、データ所在地を細かく制御したい場合に向く。 | 開発速度、運用負担、単価、ベンダー依存の許容度で判断する。 |
| 大規模バッチ処理 | 精度が最優先で、費用より品質を重視する場合に向く。 | 大量の分類、抽出、要約、前処理を安価に繰り返す場合に向く。 | 1 件あたりの単価、処理件数、必要精度、失敗時の再処理コストで判断する。 |
一方で、重み公開型 / 低コスト勢には明確な負担もある。閉鎖型の統合サービスでは、モデル提供者がチャット画面、API、監査、管理機能、安全対策、外部ツール接続、サポートをまとめて提供することが多い。重み公開型モデルや低コスト API を使う場合、その一部を利用者側が設計しなければならない。たとえば、誰が使えるか、どのデータを読めるか、危険な要求をどう止めるか、誤回答をどう検出するか、モデル更新時に品質が変わらないかを、自分たちで確認する必要がある。
| 不足しやすい要素 | 何が必要か | 放置した場合の問題 | 確認すべきこと |
|---|---|---|---|
| 安全制御 | 危険な要求、機密情報、誤操作、外部送信を制御する仕組みが必要である。 | モデルが不適切な出力を返したり、機密情報を扱ったりするリスクが増える。 | 利用ポリシー、拒否条件、ログ、フィルタリング、人間による確認を確認する。 |
| 運用監視 | 応答品質、遅延、エラー、費用、利用量を継続的に監視する必要がある。 | 品質低下、費用増加、障害、異常利用に気づきにくくなる。 | 監視指標、アラート、利用ログ、障害対応、モデル更新履歴を確認する。 |
| 権限管理 | 誰がどのモデルを使え、どのデータにアクセスできるかを制御する必要がある。 | 利用者やアプリごとの権限が曖昧になり、情報漏洩や誤操作につながる。 | シングルサインオン、API キー管理、ロール管理、データアクセス制御、監査ログを確認する。 |
| 品質評価 | 用途ごとの正解率、誤回答、再現性、失敗例を評価する必要がある。 | 安いが不正確な AI を大量に使い、結果として人間の確認負担が増える可能性がある。 | 評価データ、回帰テスト、モデル比較、サンプル監査、失敗時の運用を確認する。 |
| サポート | 障害、仕様変更、セキュリティ問題、性能劣化に対応する体制が必要である。 | 問題発生時に、誰が原因を切り分け、どこへ問い合わせるかが不明確になる。 | 商用サポート、コミュニティ、サービス水準合意、更新頻度、セキュリティ情報を確認する。 |
この章の結論は、重み公開型 / 低コスト勢が、OpenAI や Claude の単なる下位互換ではないということである。完成済みの統合サービスは、使いやすさ、サポート、企業統制、外部ツール接続に強い。一方、重み公開型や低コスト API は、コスト、独立性、改変可能性、自前運用、データ管理で意味を持つ。どちらが上かではなく、どの制約を重視するかで選択が変わる。
一般化すれば、AI の未来は最強モデル 1 社に収束するのではない。高性能な閉鎖型統合サービス、企業業務基盤、開発エージェント、調査基盤、重み公開型、自前運用、低コスト API が分化していく。OpenAI や Anthropic は、完成度の高い作業基盤を提供する。一方で、Mistral、DeepSeek、Llama、xAI などは、独立性、費用、改変可能性、データ主権という別の軸を担う。AI を選ぶとは、単に最も賢いモデルを選ぶことではなく、どの制約を自分たちで引き受け、どの価値を外部サービスに任せるかを決めることでもある。
11. 2026 年時点の主要 AI サービス仕様台帳
本稿の主軸は ChatGPT / OpenAI と Claude / Anthropic である。しかし、2026 年時点の全体像を後から見返すには、主軸ではないサービスも記録しておく必要がある。AI サービスの仕様は変化が速い。モデル名、一度に扱える文脈量、最大出力、価格、提供範囲、API 仕様、企業向け機能、エージェント機能は数か月単位で変わる。したがって、本章は論評ではなく、2026 年 7 月時点の仕様スナップショットとして置く。
ただし、AI サービスは同じ種類のものではない。ChatGPT / OpenAI や Claude / Anthropic は、基盤モデル、チャット、API、エージェント、外部ツール接続を束ねる汎用作業基盤である。Gemini / Google は、Google Search、Workspace、Cloud、マルチモーダル入力と結びつく第三極である。Microsoft 365 Copilot は、Microsoft 365 の業務データと権限に埋め込まれた企業内 AI である。GitHub Copilot、Codex、Claude Code、Devin、Cursor は、開発作業を進めるエージェントである。Perplexity は、検索と引用に重点を置く調査基盤である。Mistral、DeepSeek、Llama、xAI は、低コスト API、自前運用、重み公開型、独立性の軸を担う。
そのため、本章では単純な総合順位を付けない。代わりに、五つの評価軸で整理する。第一に、モデル仕様である。これは一度に扱える文脈量、最大出力、対応モダリティ、価格などを見る。第二に、作業実行力である。これはツール利用、エージェント実行、コード編集、テスト実行、外部操作を見ればよい。第三に、業務接続である。これは Google Workspace、Microsoft 365、GitHub、社内データ、外部コネクタへどう接続できるかを見る。第四に、統制である。これはシングルサインオン、ユーザー管理連携、監査ログ、権限継承、データ保持、管理者制御を見る。第五に、独立性である。これは重み公開型、自前運用、API 互換性、低コスト、ベンダーロックイン回避を評価する。
| 評価軸 | 意味 | 定量・準定量で見る項目 | 高く評価する条件 |
|---|---|---|---|
| モデル仕様 | 基盤モデルとしてどれだけ大きく、複雑な入力と出力を扱えるかを見る。 | 最大入力トークン、最大出力トークン、入力単価、出力単価、対応モダリティ、推論制御、知識の基準日を見る。 | 長い入力と長い出力を扱え、文章、コード、画像、音声、動画、PDF などに広く対応し、価格情報が明確である場合に高く評価する。 |
| 作業実行力 | AI が回答するだけでなく、実際に作業を前に進められるかを見る。 | ツール利用、関数呼び出し、Web 検索、ファイル検索、画面操作、コード実行、リポジトリ編集、テスト実行、Pull Request 作成を確認する。 | 複数ステップの作業、ファイル編集、コード実行、外部検索、失敗時の再試行、レビュー可能な差分作成まで扱える場合に高く評価する。 |
| 業務接続 | AI が実際の業務データや業務アプリに接続できるかを見る。 | Google Drive、Gmail、Docs、SharePoint、Teams、Outlook、GitHub、Slack、MCP、外部コネクタ、社内検索への対応を見る。 | 利用者が日常的に使っている文書、メール、予定、会議、コード、チケット、社内文書へ自然に接続できる場合に高く評価する。 |
| 統制 | 企業や組織で安全に正式運用できるかを見る。 | シングルサインオン、ユーザー管理連携、監査ログ、権限継承、データ保持、管理者制御、テナント分離、利用ログ、情報漏洩防止機能連携を見る。 | 誰が、いつ、何にアクセスし、何を出力し、どの操作をしたかを後から説明できる場合に高く評価する。 |
| 独立性 | 特定ベンダーにどこまで依存せずに使えるかを見る。 | 重み公開型、自前運用、API 互換性、商用利用条件、必要 GPU、低コスト API、追加調整可否を見る。 | モデルや API を自社環境に組み込みやすく、価格変更やサービス停止への依存を下げられる場合に高く評価する。 |
次の台帳では、各サービスをこの五つの軸で整理する。スコアは本稿における比較用の目安であり、絶対的な順位ではない。5 は非常に強い、4 は強い、3 は標準的、2 は限定的、1 は弱い、または本稿の対象用途では中心ではないことを示す。たとえば Microsoft 365 Copilot はモデル仕様の比較では ChatGPT / Claude と同じ土俵に置きにくいが、業務接続と統制では極めて強い。Perplexity は作業実行や企業統制の主役ではないが、検索と引用付き調査では強い。Llama は統合サービスとしては弱いが、独立性では強い。このように、点数は総合順位ではなく、どの用途で強いかを見分けるための目印である。
| 対象 | 分類 | 主な位置づけ | モデル仕様 | 作業実行力 | 業務接続 | 統制 | 独立性 | 本稿での読み方 |
|---|---|---|---|---|---|---|---|---|
| ChatGPT / OpenAI | 汎用作業基盤 | GPT-5.5、Responses API、ツール、Apps SDK、Codex、コネクタを束ねる。 | 5 | 5 | 4 | 4 | 2 | 広い業務を AI 上で処理する主軸である。モデル、ツール、アプリ、開発エージェントを一つの作業面へ束ねる点が強い。 |
| Claude / Anthropic | 高信頼作業基盤 | Sonnet 5、Opus 4.8、Fable 5、Mythos 5、Claude Code、MCP コネクタを持つ。 | 5 | 5 | 4 | 5 | 2 | 長文、コード、慎重な推論、能力境界管理に強い。高信頼な長時間作業者として見る。 |
| Gemini / Google | Google 統合型 AI | Gemini 3.1 Pro、Flash 系、Google Search、Workspace、Cloud、マルチモーダル入力に接続する。 | 5 | 4 | 5 | 4 | 2 | Google Search、Gmail、Drive、Docs、Calendar、Cloud を前提に見る第三極である。 |
| Microsoft 365 Copilot | 企業内 AI 基盤 | Microsoft Graph、M365 業務データ、Copilot エージェント、Copilot コネクタに接続する。 | 3 | 4 | 5 | 5 | 1 | モデル性能より、Microsoft 365 のデータ、権限、監査、業務アプリ統合で評価する。 |
| GitHub Copilot | 開発エージェント基盤 | GitHub、IDE、クラウド上のエージェント、MCP、フック、独自エージェントと結びつく。 | 4 | 5 | 3 | 4 | 2 | GitHub を開発基盤にしている場合、課題、分岐、Pull Request、コードレビューまで接続しやすい。 |
| Codex | OpenAI の開発エージェント | コード読解、編集、実行、並列作業、調査作業手順を担う。 | 5 | 5 | 3 | 3 | 1 | ChatGPT 本体とは別に、開発作業を前に進める実行環境として見る。 |
| Claude Code | Anthropic の開発エージェント | Claude をコードベース、ファイル編集、コマンド実行、開発ツールへ接続する。 | 5 | 5 | 3 | 4 | 1 | 既存コードベースを読み、修正し、検証する長時間開発作業に強い。 |
| Devin | 自律型 AI ソフトウェアエンジニア | 開発タスクを受け取り、調査、実装、テスト、Pull Request に近い流れを進める。 | 4 | 5 | 2 | 3 | 1 | 汎用チャットではなく、ソフトウェア開発タスクの委譲に特化したサービスとして見る。 |
| Cursor | エージェント中心 IDE | IDE 体験をエージェント中心へ寄せ、ローカルまたはクラウドのエージェントと共同作業する。 | 4 | 5 | 2 | 3 | 2 | モデル単体ではなく、開発者の作業空間そのものを AI 化する環境として見る。 |
| Perplexity | 引用付き調査基盤 | Web 検索、URL 取得、推論の強さを調整する機能、Agent API による調査を担う。 | 4 | 3 | 2 | 2 | 1 | 汎用 AI の代替ではなく、最新情報を調べ、出典付きで整理する調査基盤として見る。 |
| Mistral | 重み公開型 / 低コスト系 | Mistral Medium 3.5 など、エージェント型の作業用途やコード作業と公開された重みを打ち出す。 | 4 | 3 | 2 | 2 | 5 | 完成済み統合クラウド型サービスではなく、自前運用、改変可能性、低コストの選択肢として見る。 |
| DeepSeek | 低コスト API / 互換 API 系 | V4-Pro、V4-Flash、OpenAI / Anthropic 互換 API、低コスト利用を打ち出す。 | 4 | 3 | 1 | 2 | 4 | 大量処理や既存 API 置き換えの候補になるが、企業利用では法務、データ所在地、サポートを確認する必要がある。 |
| Llama | 重み公開型周辺環境 | Meta の重み公開型系モデル群として、自前運用、研究開発、派生モデル開発に使われる。 | 4 | 2 | 1 | 1 | 5 | 統合サービスではなく、研究、改変、自前運用、データ主権のための基盤として見る。 |
| xAI | 最先端 API / リアルタイム情報系 | 推論、コード、音声、画像、動画、リアルタイム情報連携を打ち出す。 | 4 | 3 | 2 | 2 | 2 | 低単価 API やリアルタイム情報には意味があるが、企業統制や業務データ接続は個別検証が必要である。 |
このスコア表だけを見ると、ChatGPT / OpenAI と Claude / Anthropic が全体的に強く見える。実際、本稿の主軸としてはその理解でよい。両者は、モデル能力、作業実行力、外部ツール接続、開発エージェント、企業利用の機能を高い水準で束ねている。一方で、目的を限定すると評価は変わる。Microsoft 365 Copilot は、Microsoft 365 を業務基盤にする組織では、ChatGPT / Claude より自然に社内情報へ接続できる。Gemini は、Google Search、Workspace、Cloud を前提にすると強い。Perplexity は、最新情報の調査と出典確認では独自の位置を持つ。Mistral、DeepSeek、Llama は、完成度ではなく独立性とコストで意味を持つ。
次に、主要なモデル仕様を数値で整理する。ここでは、本文で扱った範囲で後から見直す価値が高い項目に絞る。重要なのは、最大入力トークンと最大出力トークンである。最大入力トークンは、AI に一度に渡せる文脈の上限である。最大出力トークンは、AI が一度に返せる回答の上限である。前者は長い資料を読ませる能力に関係し、後者は長いレポート、設計書、コード、仕様整理を出力する能力に関係する。ただし、最大値が大きいほど常に実務品質が高いわけではない。長文内の必要箇所を正しく取り出せるか、不要な情報に引きずられないか、費用が現実的かを合わせて見る必要がある。
| 対象モデル | 提供元 | 最大入力トークン | 最大出力トークン | 本文での主用途 | 見るべき注意点 |
|---|---|---|---|---|---|
| GPT-5.5 | OpenAI | 1M 級 | 128K 級 | 複雑推論、コード、長文、ツール利用、知的作業、Codex を含む汎用作業の中心。 | ChatGPT、API、Codex で同じ条件とは限らないため、利用面ごとに仕様を確認する必要がある。 |
| Claude Sonnet 5 | Anthropic | 1M 級 | 128K 級 | 日常業務、複数段階のソフトウェア開発、不具合調査と修正、ツール利用、長時間作業の標準モデル。 | 単に長文を入れるのではなく、文脈設計と文脈劣化を考慮する必要がある。 |
| Claude Opus 4.8 | Anthropic | 1M 級 | 128K 級 | 複雑推論、長時間エージェント型のコード作業、高自律作業、高難度分析。 | 高難度作業向けであり、費用と速度の負担を見て使い分ける必要がある。 |
| Claude Fable 5 | Anthropic | 1M 級 | 128K 級 | 一般提供される Mythos 級モデルとして、ソフトウェア開発、知的作業、画像理解、科学研究に使われる。 | 安全制御や別モデルへの切り替えにより、高リスク領域で実際の挙動が変わる点を含めて評価する必要がある。 |
| Claude Mythos 5 | Anthropic | 1M 級 | 128K 級 | 審査済み利用者向けの限定提供向けに、防御的サイバーセキュリティや将来的な生命科学研究などで使われる。 | 一般市場比較ではなく、利用資格、監査、データ保持、能力境界の仕様として見る必要がある。 |
| Gemini 3.1 Pro プレビュー | 1,048,576 | 65,536 | 文章、画像、動画、音声、PDF を扱うマルチモーダル作業、Google Search / Workspace / Cloud 連携。 | 出力上限は 128K 級の OpenAI / Claude 系と差があるため、長大出力では比較が必要である。 |
この数値表から分かるのは、2026 年時点の主力最先端モデルでは、1M トークン級の入力がひとつの重要な競争線になっていることである。これは、長い文書や複数資料を扱えるという意味では大きな変化である。しかし、実務上の差は、入力上限だけでは決まらない。Claude 系は文脈設計と長時間作業の説明が強く、OpenAI はツール、Apps SDK、Codex との統合が強い。Gemini は入力形式の広さと Google 統合が強い。つまり、同じ 1M トークン級でも、何に接続され、どの作業に使われるかで意味が変わる。
次に、サービス別の強みを用途ごとに整理する。これは採用判断のための表である。たとえば、「長文資料を読みたい」のか、「開発作業を進めたい」のか、「社内データを扱いたい」のか、「最新情報を調べたい」のか、「低コストで大量処理したい」のかによって、選ぶべき AI は変わる。
| 用途 | 第一候補 | 第二候補 | 定量・準定量で確認すべき項目 | 判断理由 |
|---|---|---|---|---|
| 広い知的作業 | ChatGPT / OpenAI | Claude / Anthropic | 最大入力トークン、最大出力トークン、ツール利用、ファイル検索、Web 検索、プロジェクト機能、価格を確認する。 | OpenAI はモデル、ツール、Apps SDK、Codex を束ねる汎用作業面として強い。 |
| 長文読解・慎重な分析 | Claude / Anthropic | ChatGPT / OpenAI | 最大入力トークン、最大出力トークン、文脈劣化、引用、長文取り出し精度、推論制御を確認する。 | Claude は長文、慎重な推論、文脈設計、長時間作業で評価しやすい。 |
| 開発作業 | Claude Code / Codex / GitHub Copilot | Devin / Cursor | リポジトリアクセス、ファイル編集、テスト実行、分岐、Pull Request、継続的インテグレーション、作業ログ、レビュー可能性を確認する。 | 開発 AI では、モデル名より、変更を検証しレビュー可能な単位へ進められるかが重要である。 |
| Microsoft 365 中心の企業業務 | Microsoft 365 Copilot | ChatGPT Enterprise / Claude Enterprise | Graph 接続、Teams、Outlook、SharePoint、Word、Excel、アクセス権限リスト、監査ログ、管理者制御を確認する。 | Microsoft 365 のデータと権限をそのまま使えることが、企業内業務では大きい。 |
| Google Workspace 中心の業務 | Gemini / Google | ChatGPT / Claude | Gmail、Drive、Docs、Sheets、Calendar、Meet、検索結果に基づく回答補強、Vertex AI、管理者制御を確認する。 | Google の検索、文書、メール、予定、Cloud に埋め込まれることで価値が出る。 |
| 最新情報調査 | Perplexity | ChatGPT Deep Research / Gemini Deep Research | 検索回数、引用数、URL 取得、一次情報の比率、検索単価、レポート生成を確認する。 | Perplexity は、汎用作業ではなく、検索、引用、複数ソース統合に強い。 |
| 低コスト大量処理 | DeepSeek / Mistral / xAI | OpenAI の軽量モデル / Gemini Flash 系 | 入力単価、出力単価、一度に扱える文脈量、呼び出し上限、API 互換性、品質評価を確認する。 | 大量分類、定型要約、軽量抽出では、最高性能より 1 件あたり費用が効く。 |
| 自前運用・研究開発 | Llama / Mistral | DeepSeek 系モデル | 重み公開型、ライセンス、必要 GPU、追加調整、商用利用条件、推論速度を確認する。 | 外部 API に依存せず、モデルを改変し、自社環境で動かしたい場合に意味がある。 |
この用途別表から分かるのは、「最強 AI」を一つ選ぶ発想が実務には合わないということである。広い知的作業では ChatGPT / OpenAI と Claude / Anthropic が主軸になる。開発作業では Claude Code、Codex、GitHub Copilot、Devin、Cursor のような実行ハーネスが重要になる。企業業務では、Microsoft 365 や Google Workspace にどれだけ自然に接続できるかが効く。調査では Perplexity のような引用付き検索基盤が意味を持つ。低コスト大量処理や自前運用では、Mistral、DeepSeek、Llama、xAI のような選択肢が重要になる。
最後に、この台帳を後から読み返すときの注意点をまとめる。AI サービスの仕様は固定されたものではない。モデル名が変わる。プレビューが正式提供になる。価格が変わる。一度に扱える文脈量が拡大する。ある機能が特定プランだけで使えるようになる。API では使えるがチャット画面では使えない機能もある。逆に、チャット画面では使えるが API では使えない機能もある。したがって、この台帳は絶対的な事実の永久保存ではなく、2026 年 7 月時点で、何を比較軸として見るべきだったかを残すための記録である。
| 見直し時の確認項目 | なぜ確認が必要か | 確認すべき具体項目 |
|---|---|---|
| モデル名 | AI モデルは更新が速く、同じ名称でもプレビュー版、安定版、小型版、上位版、高速版などの違いが出る。 | 正式モデル ID、提供状態、廃止予定、後継モデル、利用可能プランを確認する。 |
| 一度に扱える文脈量 | 最大入力トークンは長文作業の前提になるが、提供面によって上限が違う場合がある。 | API、チャット、エージェント、企業プランごとの最大入力トークンと最大出力トークンを確認する。 |
| 価格 | 価格は採用可否に直結し、短期間で変更されることがある。 | 入力単価、出力単価、キャッシュ済み入力、一括処理、優先処理、検索課金、月額料金を確認する。 |
| 提供範囲 | 機能は地域、プラン、組織契約、審査済み利用者向けの限定提供によって制限される場合がある。 | 一般提供、プレビュー、限定提供、地域制限、利用資格、API 提供状況を確認する。 |
| 統制機能 | 企業導入では、モデル性能よりも権限、監査、データ保持が問題になる。 | シングルサインオン、ユーザー管理連携、監査ログ、データ保持、権限継承、管理者制御、情報漏洩防止機能連携を確認する。 |
| 実行環境 | 開発エージェントや業務エージェントは、モデルではなく実行環境の仕様で価値が変わる。 | 隔離実行環境、ファイル編集、コマンド実行、Pull Request 作成、継続的インテグレーション連携、ログ、承認点を確認する。 |
この章の結論は、2026 年の AI サービスは、単一のランキング表では整理できないということである。ChatGPT / OpenAI と Claude / Anthropic は、汎用作業基盤として中心に置くべきである。しかし、Gemini / Google は Google 統合、Microsoft 365 Copilot は企業内データと権限、GitHub Copilot や Codex や Claude Code は開発実行、Perplexity は引用付き調査、Mistral や DeepSeek や Llama や xAI は低コスト、自前運用、独立性で意味を持つ。したがって、後から見直すべきなのは「どの AI が一番だったか」ではなく、「どの用途では、どの評価軸が支配的だったか」である。
12. ここまでの比較から見える構造
ここまで見てきた各社の AI サービスは、表面的には同じ方向へ進んでいるように見える。どの会社も高性能モデルを出し、長い文脈を扱い、外部ツールを使い、業務や開発に入り込もうとしている。しかし、細かく見ると、取りに行っている場所は異なる。OpenAI は、ChatGPT、API、ツール、Apps SDK、Codex を束ね、広い作業を ChatGPT 周辺で進める基盤を作っている。Anthropic は、Claude Sonnet 5、Opus 4.8、Fable 5、Mythos 5、Claude Code、MCP を通じて、長時間作業、高信頼、能力境界管理を前面に出している。Google は、Gemini を検索、Workspace、Cloud、画像、動画、音声、PDF へ埋め込む。Microsoft は、Graph、Microsoft 365、権限、監査を通じて企業内業務を押さえる。GitHub、Devin、Cursor は、開発作業を AI によって前へ進める。Perplexity は、検索と引用付き調査を専門領域にする。Mistral、DeepSeek、Llama、xAI は、低コスト、自前運用、重み公開型、独立性という別軸を担う。
この章で明らかにしたいことは、単純である。2026 年時点の AI 競争は、「最も賢いモデルを作る競争」だけではなくなっている。もちろん、モデル性能は今でも重要である。しかし、複数社が 1M トークン級の入力、長大出力、推論制御、ツール利用、マルチモーダル入力を備え始めると、モデル単体だけでは差が見えにくくなる。そこで差を作るのは、そのモデルをどこに接続するかである。文書へ接続するのか、コードベースへ接続するのか、社内データへ接続するのか、検索へ接続するのか、企業の権限管理へ接続するのか、自前運用へ開くのか、高リスク能力を限定配分するのかが競争軸になる。
ここでいう「接続」とは、単に外部サービスのリンクを貼ることではない。AI が、どのデータを読み、どの道具を使い、どの画面で動き、どの権限で操作し、どのログを残し、どこで人間の承認を求めるかということである。たとえば、同じ高性能モデルでも、検索だけに使うなら調査支援である。リポジトリに接続し、ファイルを編集し、テストを実行するなら開発エージェントである。Microsoft Graph や SharePoint の権限に従って社内文書を読むなら企業内 AI 基盤である。つまり、AI の意味は、モデル名だけでなく、置かれる作業環境によって変わる。
| 競争軸 | 何を比べる軸か | 代表例 | 定量・準定量で見る項目 | この軸で見た結論 |
|---|---|---|---|---|
| モデル性能 | AI の基礎的な推論力、長文処理、コード能力、マルチモーダル処理を見る軸である。 | GPT-5.5、Claude Sonnet 5、Claude Opus 4.8、Gemini 3.1 Pro プレビューなど。 | 最大入力トークン、最大出力トークン、対応入力形式、推論制御、ベンチマーク、入力単価、出力単価を見る。 | 主力モデルでは 1M トークン級入力が重要な競争線になっているが、入力上限だけでは実務品質は決まらない。 |
| 作業実行 | AI が回答するだけでなく、実際に作業を前へ進められるかを見る軸である。 | OpenAI Codex、Claude Code、GitHub Copilot クラウド上のエージェント、Devin、Cursor など。 | ファイル編集、コード実行、テスト実行、分岐作成、Pull Request 作成、ログ、失敗時の再試行を見る。 | 開発領域では、コード生成よりも、変更を検証し、レビュー可能な単位へまとめる力が重要になる。 |
| 業務接続 | AI が社内文書、メール、予定、会議、チャット、業務アプリに接続できるかを見る軸である。 | Microsoft 365 Copilot、Gemini / Google Workspace、ChatGPT コネクタ、Claude MCP コネクタなど。 | 接続可能サービス、ファイル検索、メール検索、予定表参照、外部コネクタ、権限継承を見る。 | 企業業務では、最強モデルよりも、日常的に使う業務データへ安全に接続できることが効く場合がある。 |
| 統制 | 誰が何にアクセスし、何を実行し、後から説明できるかを見る軸である。 | Microsoft Graph、企業向け管理機能、シングルサインオン、ユーザー管理連携、監査ログ、データ保持など。 | シングルサインオン、ユーザー管理連携、監査ログ、管理者制御、データ保持、情報漏洩防止機能、権限継承、テナント分離を見る。 | 組織導入では、便利さだけでなく、情報漏洩、誤操作、監査不能を防げるかが採用条件になる。 |
| 能力境界 | 高性能 AI の危険な能力を、誰に、どの目的で、どこまで使わせるかを見る軸である。 | Claude Fable 5、Claude Mythos 5、安全制御、別モデルへの切り替え、審査済み利用者向けの限定提供など。 | 利用資格、地域制限、用途制限、安全判定器、別モデルへの切り替え、監査、データ保持、緊急停止を見る。 | 最先端 AI では、性能だけでなく、能力を配分する条件そのものが仕様になる。 |
| 独立性 | 特定ベンダーに依存せず、自前運用、低コスト運用、改変ができるかを見る軸である。 | Mistral、DeepSeek、Llama、xAI など。 | 重み公開型、API 互換性、必要 GPU、ライセンス、商用利用条件、追加調整可否、単価を見る。 | 完成度では統合クラウド型サービスが強い一方、自前運用、費用、データ主権では重み公開型 / 低コスト勢が意味を持つ。 |
この表から分かるのは、AI サービスが一列に並ぶ商品ではなくなっているということである。ChatGPT / OpenAI と Claude / Anthropic は、汎用 AI の主軸である。しかし、Microsoft 365 Copilot は Microsoft 365 を使う企業で強く、Gemini は Google の検索や Workspace を使う環境で強く、GitHub Copilot や Claude Code や Codex は開発作業で強く、Perplexity は調査で強く、Mistral や DeepSeek や Llama は自前運用や低コスト処理で強い。したがって、比較の結論は「どれが一番か」ではなく、「どの作業では、どの競争軸が支配的か」でなければならない。
この分化の直接原因は、基盤モデルの能力が一定水準を超えたことである。以前は、モデルそのものの賢さに大きな差があり、回答品質やコード生成能力を比べることが比較の中心だった。しかし、複数社が高性能な推論、長文文脈、ツール利用、画像や音声や動画の入力、コード実行を備え始めると、単純なモデル比較だけでは実務上の違いを説明しにくくなる。そこで各社は、モデルをどの作業環境へ接続するかで差を作るようになった。
| 企業・系統 | 中心にある競争軸 | 定量・準定量で見る項目 | 構造的な意味 | 実務での読み方 |
|---|---|---|---|---|
| OpenAI | 業務 OS 化、ツール、Apps SDK、Codex、外部アプリ接続。 | 最大入力トークン、最大出力トークン、ツール種別、Apps SDK 対応、Codex 実行環境、API 単価を見る。 | AI を、文書、コード、ファイル、検索、画面、外部アプリを横断する作業面にする。 | 広い知的作業や複数ツールをまたぐ作業を AI 上で進めたい場合の主軸になる。 |
| Anthropic | 長時間作業、高信頼、Claude Code、Fable / Mythos、能力境界管理。 | 最大入力トークン、最大出力トークン、文脈劣化、Claude Code 機能、MCP、安全制御、別モデルへの切り替え、審査済み利用者向けの限定提供を見る。 | 高能力 AI を、長文作業、コード作業、用途制限、主体制限、監査条件によって階層化する。 | 慎重な分析、長文、コード、能力境界を重視する場合の主軸になる。 |
| Search、Workspace、Cloud、マルチモーダル統合。 | 入力トークン、出力トークン、対応入力形式、検索結果に基づく回答補強、URL 文脈、Workspace 連携、Vertex AI を見る。 | AI を Google の検索、文書、メール、予定、動画、クラウドへ埋め込む。 | Google Workspace や Google Cloud を業務基盤にしている場合に強い。 | |
| Microsoft | Microsoft 365、Graph、権限、監査、業務アプリ統合。 | Graph 接続、アクセス権限リスト、Teams、Outlook、SharePoint、Word、Excel、監査ログ、管理者制御を見る。 | AI を企業内情報権限構造の上で動かす。 | Microsoft 365 を業務基盤にしている企業では、モデル単体性能以上に強い意味を持つ。 |
| GitHub / Devin / Cursor | 開発作業手順、リポジトリ、テスト、Pull Request、エージェント実行環境。 | リポジトリアクセス、ファイル編集、コマンド実行、テスト、分岐、Pull Request、継続的インテグレーション、作業ログを見る。 | AI をコード補完から開発変更を前へ進める存在へ移す。 | 開発では、コード生成能力よりも、変更を検証しレビュー可能な単位へまとめられるかを見る。 |
| Perplexity | 検索、引用、URL 取得、調査統合。 | 検索回数、引用数、URL 取得、一次情報比率、検索単価、レポート生成を確認する。 | AI を最新情報の調査と根拠提示に特化させる。 | 仕様確認、ニュース、価格、規制、企業発表など、変化しやすい情報の調査に向く。 |
| Mistral / DeepSeek / Llama / xAI | 重み公開型、低コスト API、自前運用、独立性。 | 重み公開型、API 単価、API 互換性、必要 GPU、ライセンス、商用利用条件、追加調整可否を見る。 | 閉鎖型統合基盤に対する、費用、自由度、運用主権の軸を担う。 | 大量処理、自前運用、機密データ処理、ベンダーロックイン回避を重視する場合に意味を持つ。 |
ここで「AI がアプリからインフラへ移行している」という表現を使う場合、その意味を明確にしておく必要がある。アプリとしての AI とは、利用者が画面を開き、質問を入力し、回答を受け取るものを指す。この段階では、AI は便利な相談相手や文章生成ツールである。一方、インフラとしての AI とは、文書、メール、予定、コード、検索、社内データ、外部 API、権限管理、監査ログの中に組み込まれ、業務や開発の流れそのものを支えるものを指す。この段階では、AI は単独のアプリではなく、作業を動かす基盤になる。
| 観点 | アプリとしての AI | インフラとしての AI | 何が変わるか |
|---|---|---|---|
| 利用方法 | 利用者が AI の画面を開き、質問や依頼を入力する。 | AI が文書、メール、会議、コード、業務アプリの中に組み込まれる。 | AI を使う行為が、特別な操作ではなく日常業務の一部になる。 |
| 扱う情報 | 利用者が入力した文やアップロードしたファイルが中心である。 | 社内文書、メール、予定、会議、リポジトリ、検索結果、外部システムを横断する。 | AI が扱う情報の範囲が広がり、権限と監査が重要になる。 |
| できること | 回答、要約、文章作成、相談、短いコード生成が中心である。 | ファイル編集、コード変更、テスト実行、業務エージェント、検索、外部操作まで広がる。 | 回答品質だけでなく、実行、検証、失敗時の復旧が重要になる。 |
| 必要な管理 | 利用規約、個人設定、履歴管理が中心である。 | シングルサインオン、ユーザー管理連携、監査ログ、権限継承、情報漏洩防止機能、データ保持、管理者制御が必要になる。 | 個人利用の便利さから、組織運用の統制へ問題が移る。 |
| 人間の役割 | 人間が質問し、AI の回答を参考にする。 | 人間が問題設定、承認、レビュー、採否判断、責任ある統合を担う。 | 人間は単なる利用者ではなく、AI が進めた作業を評価する責任者になる。 |
この変化によって、評価の仕方も変わる。以前は、「この AI はよい文章を書くか」「この AI は難しい問題に答えられるか」「この AI はコードを書けるか」を見れば、多くの用途を判断できた。しかし、AI がインフラ化すると、それだけでは足りない。どのデータに接続できるか。どの権限で動くか。どの作業を実行できるか。どのログを残すか。どこで人間が止められるか。費用は継続可能か。危険な能力をどこで制御できるか。これらがすべて評価対象になる。
| 用途 | 支配的な評価軸 | 第一候補になりやすい系統 | 判断理由 |
|---|---|---|---|
| 広い知的作業 | モデル性能、長文、ツール利用、作業面の広さ。 | ChatGPT / OpenAI、Claude / Anthropic。 | 複数用途を横断して使うため、モデル能力と作業基盤の総合力が効く。 |
| 長文・慎重な分析 | 文脈設計、長文取り出し精度、推論制御、出力品質。 | Claude / Anthropic、ChatGPT / OpenAI。 | 長い資料を扱い、矛盾や前提を丁寧に処理する能力が重要になる。 |
| 開発作業 | リポジトリ理解、ファイル編集、テスト、Pull Request、ログ。 | Claude Code、Codex、GitHub Copilot、Devin、Cursor。 | コードを書く能力より、変更を検証しレビュー可能な単位へ進める能力が効く。 |
| Microsoft 365 中心の企業業務 | Graph、権限、Teams、Outlook、SharePoint、監査。 | Microsoft 365 Copilot。 | 既存の業務データと権限構造をそのまま使えることが強い。 |
| Google Workspace 中心の企業業務 | Gmail、Drive、Docs、Calendar、Search、Cloud。 | Gemini / Google。 | Google の業務環境と検索基盤へ自然に埋め込まれることが強い。 |
| 最新情報の調査 | 検索、引用、URL 取得、一次情報確認。 | Perplexity、ChatGPT Deep Research、Gemini Deep Research。 | モデル内部知識ではなく、現在の情報源を確認できることが重要になる。 |
| 低コスト大量処理 | API 単価、処理件数、呼び出し上限、品質評価。 | DeepSeek、Mistral、xAI、軽量モデル。 | 大量の分類、抽出、要約では、最高性能より 1 件あたりの費用が効く。 |
| 自前運用・機密データ処理 | 重み公開型、必要 GPU、ライセンス、データ所在地、運用監視。 | Llama、Mistral、DeepSeek 系。 | 外部 API に送れないデータや、ベンダー依存を避けたい用途では独立性が効く。 |
この用途別整理から分かるのは、各社が同じ山の頂上を取り合っているのではなく、AI を置く場所を取り合っているということである。OpenAI は、ChatGPT を作業の入口にしようとしている。Anthropic は、Claude を高信頼な長時間作業者にしようとしている。Google は、検索と Workspace と Cloud に Gemini を埋め込もうとしている。Microsoft は、企業内データと権限の上で Copilot を動かそうとしている。開発エージェント企業は、開発作業手順の中に AI を入れようとしている。Perplexity は、調査の入口を取ろうとしている。重み公開型 / 低コスト勢は、統合クラウド型サービスの外側に、自前運用と独立性の逃げ道を作っている。
ここでの結論は明確である。2026 年の AI 競争は、単なるモデル競争から、配置場所の競争へ移った。どのモデルが最も賢いかは、依然として重要である。しかし、それ以上に、どのデータへ接続されるか、どの作業を進めるか、どの権限で動くか、どの環境に埋め込まれるか、どの能力を制限されるかが重要になっている。最新 AI モデルの実体は、モデルの重みだけではない。そのモデルが置かれる作業環境、接続先、権限、監査、実行機能、制限条件を含んだ全体構造である。
一般化すれば、AI は「答えるアプリ」から「仕事を動かす基盤」へ移行している。この移行によって、AI を選ぶときの問いも変わる。「どの AI が一番賢いか」では足りない。「どの作業に使うのか」「どのデータに接続するのか」「誰が使うのか」「何を実行させるのか」「どこで止めるのか」「どの費用なら継続できるのか」を問う必要がある。2026 年時点の AI 比較で残すべき構造は、この問いの変化である。
13. 結論 ―― 最新 AI モデルの実体は、モデルではなく作業基盤である
本稿で見てきた結論は、ひとことで言えばこうである。2026 年の最新 AI は、もはや「文章を返すだけの賢いチャット」ではない。もちろん、GPT-5.5、Claude Sonnet 5、Claude Opus 4.8、Claude Fable 5、Claude Mythos 5、Gemini 3.1 Pro のようなモデル名は重要である。どのモデルが長い文章を読めるか、複雑な問題を考えられるか、コードを書けるか、画像や音声や PDF を扱えるかは、今でも大きな差になる。しかし、モデル名だけを並べても、実際に何ができる AI なのかは分からない。
なぜなら、2026 年の AI の価値は、モデル本体だけでは決まらないからである。AI がどれだけ長い資料を読めるか。どれだけ長い文章を出力できるか。Web を検索できるか。ファイルを読めるか。コードを編集できるか。テストを実行できるか。業務アプリに接続できるか。社内文書を、権限を守って読めるか。危険な使い方を止められるか。費用を払える範囲に収められるか。こうした条件がそろって、はじめて AI は仕事に使える。
本稿で「作業基盤」と呼んでいるのは、この全体のことである。作業基盤とは、AI モデルそのものに加えて、検索、ファイル、コード、外部アプリ、社内データ、権限管理、監査ログ、実行環境、費用管理まで含めた、仕事を進めるための土台である。AI が単に答えるだけなら、モデル性能を見ればよい。しかし AI が実際に作業を進めるなら、どの情報を読み、どの道具を使い、どの権限で動き、どこで人間が確認するかまで見なければならない。
| 見るべきもの | 分かりやすい言い方 | なぜ重要か |
|---|---|---|
| モデル性能 | AI そのものの頭のよさである。 | 推論、文章作成、コード、画像理解、長文読解の上限を決める。 |
| 文脈長 | AI が一度に読める資料の量である。 | 長い仕様書、議事録、契約書、コード、調査資料を扱えるかを決める。 |
| 外部ツール利用 | AI が検索、ファイル読み取り、コード実行、外部アプリ操作をできるかである。 | AI が知っていることだけで答えるのではなく、調べたり、実行したり、確認したりできる。 |
| 作業実行環境 | AI が実際にファイルを編集し、テストし、変更案をまとめられる場所である。 | 特に開発作業では、コードを書くことより、動かして確認し、レビューできる形にすることが重要になる。 |
| 業務データ接続 | メール、文書、予定、会議、チャット、社内ファイルに接続できるかである。 | 企業の仕事では、答えが Web ではなく社内の記録にあることが多い。 |
| 権限と監査 | 誰が何を見てよいかを守り、後から確認できる仕組みである。 | 便利でも、本来見てはいけない情報を AI が読めるなら、企業では使いにくい。 |
| 能力の線引き | 危険な能力を、誰に、どの目的で、どこまで使わせるかである。 | 高性能 AI では、サイバーや生命科学のような領域で、能力の出し方そのものが問題になる。 |
| 費用 | 継続して使える価格かどうかである。 | 長文、検索、エージェント実行、大量処理では、単価と利用回数が採用可否を左右する。 |
この見方で整理すると、ChatGPT / OpenAI の位置づけは明確になる。OpenAI は、ChatGPT、API、ツール、Apps SDK、コネクタ、Codex を組み合わせ、文章、検索、ファイル、コード、外部アプリを横断して扱う方向へ進んでいる。つまり、ChatGPT は単なる会話画面ではなく、いろいろな作業を始める入口になりつつある。ここでいう「業務 OS 化」とは、ChatGPT が文字どおりオペレーティングシステムになるという意味ではない。文書を書く、表を整理する、検索する、コードを直す、外部アプリを呼ぶといった作業を、ChatGPT を中心に進める場所へ変わっている、という意味である。
Claude / Anthropic の位置づけも明確である。Claude は、ChatGPT と似たチャット AI というだけではない。Claude Sonnet 5 は日常的な実務作業の中心モデルであり、Claude Opus 4.8 はより重い推論や長時間作業に向く。Claude Code は、コードベースを読み、ファイルを編集し、コマンドを実行する開発作業の環境である。Fable 5 / Mythos 5 は、最上位の能力を一般利用と限定利用に分け、安全制御や監査条件を含めて提供する事例である。Claude は、長い資料、複雑なコード、慎重な分析、危険な能力の線引きに重心を置いている。
ほかのサービスも、それぞれ別の役割を持っている。Gemini は、Google Search、Gmail、Drive、Docs、Calendar、Cloud、画像、音声、動画と結びつくことで意味を持つ。Microsoft 365 Copilot は、Microsoft Graph、Teams、Outlook、SharePoint、Word、Excel、企業内権限、監査と結びつくことで意味を持つ。GitHub Copilot、Codex、Claude Code、Devin、Cursor は、コードを書く AI というより、開発変更を前へ進める AI である。Perplexity は、検索し、出典を示し、複数情報をまとめる調査基盤である。Mistral、DeepSeek、Llama、xAI は、低コスト、自前運用、モデル改変、ベンダー依存の低減という軸で意味を持つ。
| 用途 | 中心になる選択肢 | 結論 |
|---|---|---|
| 広い知的作業 | ChatGPT / OpenAI、Claude / Anthropic | 文章、調査、整理、コード、長文を横断するなら、この 2 系統が主軸になる。 |
| 長文・慎重な分析 | Claude / Anthropic、ChatGPT / OpenAI | 長い資料を読み、前提や矛盾を丁寧に扱う作業では、文脈設計と推論の安定性が重要になる。 |
| 開発作業 | Claude Code、Codex、GitHub Copilot、Devin、Cursor | コード生成より、リポジトリを読み、変更し、テストし、レビュー可能にする力を見るべきである。 |
| 企業内業務 | Microsoft 365 Copilot、Gemini / Google、ChatGPT Enterprise、Claude Enterprise | 最強モデルよりも、社内データ、権限、監査、既存業務アプリとの接続が効く。 |
| 最新情報の調査 | Perplexity、ChatGPT Deep Research、Gemini Deep Research | モデルの内部知識ではなく、どの出典を確認したかが重要になる。 |
| 低コスト大量処理 | DeepSeek、Mistral、xAI、軽量モデル | 大量の分類、抽出、要約では、最高性能より 1 件あたりの費用が重要になる。 |
| 自前運用・独立性 | Llama、Mistral、DeepSeek 系 | 外部 API に依存したくない場合や、機密データを外に出せない場合には、重み公開型や自前運用が意味を持つ。 |
したがって、2026 年の AI を理解するときに最も避けるべきなのは、「どの AI が一番賢いか」だけで考えることである。これは、車を選ぶときに最高速度だけを見るようなものである。実際には、何に使うのか、どれだけ荷物を積むのか、どの道を走るのか、燃費はどうか、安全装備はあるか、修理できるかを見なければならない。AI も同じである。どの作業に使うのか。どのデータを読ませるのか。どの道具を使わせるのか。誰が使うのか。どこで止めるのか。費用は続くのか。これらを見なければ、実務上の価値は判断できない。
本稿の最終結論は、最新 AI モデルの実体は、モデル単体ではなく、作業基盤であるということである。モデルは中心にある。しかし、モデルだけでは仕事は進まない。検索できること、ファイルを読めること、コードを実行できること、社内データにつながること、権限を守れること、危険な能力を止められること、費用を管理できることがそろって、はじめて AI は仕事の中に入る。2026 年の AI 比較で見るべきものは、モデル名ではなく、そのモデルがどの作業環境に置かれ、何に接続され、どの権限で動き、どこまで作業を進められるかである。
言い換えれば、AI は「答える道具」から「仕事を進める土台」へ変わっている。この変化によって、人間の役割も変わる。人間は、AI に丸投げするのではなく、何を任せるか、何を任せないか、どの結果を採用するか、どこで止めるかを決める必要がある。AI が強くなるほど、人間の判断が不要になるのではない。むしろ、AI が進めた作業を評価し、責任を持って採用する人間の判断が、より重要になる。
これが、本稿で 2026 年の AI サービスを長く整理した理由である。最新 AI を理解するとは、モデルの名前を覚えることではない。どの AI が、どの作業に強く、どのデータに接続され、どの権限で動き、どの費用で使え、どの危険を止められるのかを整理することである。後から見直すべきなのは、「当時どのモデルが一番だったか」ではなく、「当時、AI はどのように仕事の中へ入り始めていたか」である。
参考文献
- id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/
- id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
- id774, Claude Mythos は世界をどう変えたのか（2026-05-08）. https://blog.id774.net/entry/2026/05/08/4737/
- id774, 最先端 AI は、誰に使わせるかだけでは足りない（2026-07-01）. https://blog.id774.net/entry/2026/07/01/4933/
- OpenAI, Introducing GPT-5.5（2026-04-23）. https://openai.com/index/introducing-gpt-5-5/
- OpenAI Developers, Models | OpenAI API（参照日 2026-07-01）. https://developers.openai.com/api/docs/models
- OpenAI Developers, Reasoning models | OpenAI API（参照日 2026-07-01）. https://developers.openai.com/api/docs/guides/reasoning
- OpenAI Developers, Using tools | OpenAI API（参照日 2026-07-01）. https://developers.openai.com/api/docs/guides/tools
- OpenAI Developers, Apps SDK（参照日 2026-07-01）. https://developers.openai.com/apps-sdk
- OpenAI Developers, Codex Models（参照日 2026-07-01）. https://developers.openai.com/codex/models
- OpenAI Developers, Codex の Web 版（参照日 2026-07-01）. https://developers.openai.com/codex/cloud
- Johnston, D., Holtz, D., Richmond, A. M., Ong, C., Tambe, P., and Chatterji, A., The Shift to Agentic AI: Evidence from Codex（2026）. https://arxiv.org/abs/2606.26959
- Anthropic, Introducing Claude Sonnet 5（2026-06-30）. https://www.anthropic.com/news/claude-sonnet-5
- Anthropic, Models overview | Claude Platform Docs（参照日 2026-07-01）. https://docs.anthropic.com/en/docs/about-claude/models/overview
- Anthropic, Context windows | Claude Platform Docs（参照日 2026-07-01）. https://platform.claude.com/docs/en/build-with-claude/context-windows
- Anthropic, Claude Code overview（参照日 2026-07-01）. https://docs.anthropic.com/en/docs/claude-code/overview
- Anthropic, Tool use with Claude（参照日 2026-07-01）. https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
- Anthropic, Claude Fable 5 and Claude Mythos 5（2026-06-09）. https://www.anthropic.com/news/claude-fable-5-mythos-5
- Anthropic, Redeploying Claude Fable 5（2026-06-30）. https://www.anthropic.com/news/redeploying-fable-5
- Google AI for Developers, Models | Gemini API（参照日 2026-07-01）. https://ai.google.dev/gemini-api/docs/models
- Google Cloud, Gemini 3.1 Pro | Gemini Enterprise Agent Platform（参照日 2026-07-01）. https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/gemini/3-1-pro
- Microsoft Learn, Agents for Microsoft 365 Copilot（2026-05-18）. https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/agents-overview
- Microsoft Learn, Copilot connectors overview（2026-05-14）. https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/overview
- GitHub Docs, About GitHub Copilot cloud agent（参照日 2026-07-01）. https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
- GitHub Docs, About Model Context Protocol (MCP)（参照日 2026-07-01）. https://docs.github.com/en/copilot/concepts/context/mcp
- Cognition, Introducing Devin（参照日 2026-07-01）. https://docs.devin.ai/get-started/devin-intro
- Cursor, Meet the new Cursor（2026-04-02）. https://cursor.com/blog/cursor-3
- Perplexity, API Platform（参照日 2026-07-01）. https://www.perplexity.ai/api-platform
- Perplexity, Agent API Quickstart（参照日 2026-07-01）. https://docs.perplexity.ai/docs/agent-api/クイックスタート
- Mistral AI Docs, Mistral Medium 3.5（2026-04-28）. https://docs.mistral.ai/models/model-cards/mistral-medium-3-5-26-04
- DeepSeek API Docs, DeepSeek V4 Preview Release（2026-04-24）. https://api-docs.deepseek.com/news/news260424
- Meta AI, The Llama 4 herd: The beginning of a new era of natively multimodal AI innovation（2025-04-05）. https://ai.meta.com/blog/llama-4-multimodal-intelligence/
- xAI, Frontier AI models（参照日 2026-07-01）. https://x.ai/