目次


1. 高性能モデルを「常時最大」で使わない時代へ

AIエージェントの導入で、モデル選定は以前より難しくなっています。単純なチャットなら「精度が高いモデルを選ぶ」で済んだかもしれません。けれども、AIがブラウザやターミナルを使い、コードを修正し、社内ツールを操作し、複数ステップの業務を進めるようになると、見るべきものは性能だけではなくなります。

重要になるのは、どのタスクにどのモデルを使い、どの努力レベルで動かし、どこで人間が確認し、どのコストなら継続できるかです。毎回もっとも高性能なモデルを使えば安心に見えますが、日常業務の自動化ではコストが膨らみます。逆に安さだけで選ぶと、途中で止まる、誤った操作をする、レビュー負荷が増えるといった問題が起きます。

Anthropicが2026年6月30日に発表したClaude Sonnet 5は、この論点を考えるうえで分かりやすい材料です。発表では、Sonnet 5がこれまでのSonnet系よりエージェント能力を高め、Opus 4.8に近い性能をより低い価格帯で提供すると説明されています。この記事では、Claude Sonnet 5の公式発表を題材に、企業がAIエージェント用モデルを「モデル名」ではなく「業務タスク単位」で選ぶための考え方を整理します。

2. Claude Sonnet 5で何が発表されたのか

Anthropicの公式発表によると、Claude Sonnet 5は、計画を立て、ブラウザやターミナルなどのツールを使い、自律的に作業を進める能力を強化したSonnet系モデルです。Anthropicは、Sonnet 5について、数か月前ならより大きく高価なモデルが必要だった水準の自律作業をこなせるようになったと説明しています。

位置づけとしては、Sonnet 4.6からの大きな改善であり、Opus 4.8に近い性能をより低い価格で提供するモデルです。発表では、推論、ツール利用、コーディング、知識労働など、エージェント性能に関わる領域で改善が示されています。また、利用者は努力レベルを調整し、タスクに応じてコストと性能のバランスを選べるとされています。

提供範囲も広い点が重要です。Claude Sonnet 5は発表日から各プランで利用可能になり、FreeとProではデフォルトモデル、Max、Team、Enterpriseでも利用可能とされています。Claude CodeとClaude Platformでも使え、APIではclaude-sonnet-5として提供されます。

価格面では、2026年8月31日までの導入価格として、100万入力トークンあたり2ドル、100万出力トークンあたり10ドルが示されています。その後は、100万入力トークンあたり3ドル、100万出力トークンあたり15ドルに移行する予定です。比較対象として、AnthropicはOpus 4.8の価格を100万入力トークンあたり5ドル、100万出力トークンあたり25ドルと説明しています。

ただし、価格だけを単純比較するのは危険です。Anthropicは、Sonnet 5が更新されたトークナイザーを使うため、同じ入力でも内容によっておよそ1.0倍から1.35倍のトークンになる可能性があると説明しています。つまり、企業が実際のコストを読むには、自社のプロンプト、社内文書、コード、ログ、チケット履歴を使って試算する必要があります。

AIエージェント向けモデル選定をタスク単位で分ける図

AIエージェントのモデル選定は、性能だけでなく、タスクの複雑さ、許容コスト、確認負荷、安全性を合わせて見る必要があります。

3. 価格性能をタスク単位で読む

Claude Sonnet 5の発表で企業が注目すべきなのは、「より安いモデルが出た」という点だけではありません。むしろ、モデル選定をタスク単位で最適化しやすくなった点が本質です。

たとえば、日常的な社内問い合わせ、議事録の整理、既存文書の要約、簡単なコード調査、定型的なチケット分類では、毎回もっとも高性能なモデルを使う必要はありません。一定の精度で大量に処理する業務では、価格性能のよいモデルを標準にし、難しいケースだけ上位モデルや人間レビューへ回す設計が合理的です。

一方で、複数のリポジトリをまたぐ原因調査、障害対応、顧客影響のある仕様判断、法務・セキュリティに関わる文書作成、本番環境へ影響する操作では、安さよりも失敗時の影響を重く見るべきです。この領域では、上位モデル、長めの検証ステップ、人間承認、監査ログを組み合わせる必要があります。

Claude Sonnet 5が示す「努力レベルを調整する」という考え方は、ここで効いてきます。すべての依頼を同じ深さで考えさせるのではなく、タスクのリスクと難しさに応じて、軽い処理、通常処理、深い調査を切り替える。これは、社内AIエージェントの運用をコスト面で成立させるための基本設計になります。

タスク例推奨する考え方注意点
社内FAQ、要約、分類低〜中コストの標準モデルで大量処理根拠文書と回答履歴を残す
コード調査、軽微な修正Sonnet級を標準にし、テスト実行まで任せるレビュー通過率と再修正率を見る
複雑な障害調査、設計判断高い努力レベルや上位モデルへ段階的に切り替える途中経過と判断根拠を確認する
セキュリティ、本番操作人間承認と監査ログを必須にするモデル性能より権限境界を優先する

企業導入では、モデル価格の表だけで判断しないことが大切です。月間の入力トークン、出力トークン、再試行回数、レビュー時間、失敗時の手戻りまで含めた総コストを見る必要があります。安いモデルで三回やり直すより、最初から適切なモデルを使ったほうが安い場面もあります。

4. 実務AIエージェントで見るべき四つの設計軸

AIエージェント向けモデルを選ぶときは、少なくとも四つの軸を分けて考えるべきです。性能、コスト、継続力、安全性です。

第一に、性能です。ここでいう性能は、単発の回答精度だけではありません。タスクを分解できるか、ツールを正しく使えるか、途中で方針を修正できるか、最後に検証できるかまで含みます。Claude Sonnet 5の発表では、ブラウザやターミナルを使うエージェント的な作業、コーディング、知識労働での改善が強調されています。企業の実務では、まさにこの「最後までやり切る力」が成果に直結します。

第二に、コストです。AIエージェントは一つの依頼で多くのコンテキストを読み、複数回ツールを使い、検証ログを出すことがあります。チャット一往復の単価だけを見ると安く見えても、エージェント化すると入力も出力も増えます。特にコードベース、問い合わせ履歴、社内規程、ログを読む業務では、トークン量の見積もりが重要です。

第三に、継続力です。実務のAIエージェントは、途中で止まらず、作業計画を保ち、失敗したら別案を試す必要があります。Anthropicの発表では、早期利用者の例として、複数ステップの業務、難しいPull Request、バグ調査、ライブデータ分析、保険業務のコンピューター操作などが紹介されています。これらは、単なる文章生成ではなく、業務の流れに沿って動く力が問われる領域です。

第四に、安全性です。自律性が高いモデルほど、便利さとリスクが同時に大きくなります。AIが社内ツールを触る場合、誤操作、権限外アクセス、未確認情報の使用、プロンプトインジェクション、過剰な自信を持った提案が問題になります。モデルの安全評価だけでなく、業務側の権限設計とレビュー設計が必要です。

AIエージェントのモデルルーティング設計

実務では、依頼内容を分類し、標準モデル、深い調査、上位モデル、人間承認へ段階的にルーティングする設計が有効です。

5. 安全性と業務適用範囲をどう分けるか

Claude Sonnet 5の公式発表では、安全性についても具体的に触れられています。Anthropicは、Sonnet 5がSonnet 4.6より望ましくない振る舞いの割合を全体として下げ、エージェント文脈でもより安全に使えると説明しています。また、幻覚や迎合の低下、悪意ある依頼への拒否、プロンプトインジェクションへの耐性も評価対象として示されています。

同時に、過信してはいけない点もあります。Anthropicは、Sonnet 5がOpus 4.8やMythos 5より危険なサイバータスクの能力は低いと説明しつつ、サイバーセーフガードをデフォルトで有効にして提供しています。これは、企業にとって重要なメッセージです。モデルが比較的安全に設計されていても、業務側の制御を省いてよいわけではありません。

セキュリティ領域では、AIに任せる範囲を細かく分ける必要があります。ログの要約、脆弱性情報の整理、影響範囲の下調べ、修正案の下書きは、AIの支援価値が出やすい領域です。一方で、エクスプロイトの作成、本番環境への変更、外部公開情報の判断、顧客影響のある対応は、人間の確認と承認が欠かせません。

一般業務でも同じです。営業メールの下書き、議事録整理、問い合わせ分類は比較的始めやすい一方、契約条件の変更、顧客データの更新、請求処理、採用判断、人事評価のような領域では、AIの出力をそのまま実行に移すべきではありません。

モデルの安全性は、企業の安全性の一部にすぎません。入力データ、接続ツール、実行権限、監査ログ、人間承認、利用者教育がそろって初めて、実務に載せられるAIエージェントになります。

6. 導入時の判断基準

Claude Sonnet 5のような価格性能のよいエージェント向けモデルを導入するとき、最初に決めるべきなのは「全社で使うモデル」ではありません。どの業務を標準モデルで処理し、どの業務を上位モデルへ回し、どの業務は人間承認を必須にするかです。

まず、タスクをリスク別に分類します。情報検索、要約、分類、下書き、コード修正、外部送信、本番操作のように、実行結果の影響が違う単位へ分けます。次に、それぞれに許容されるコストと失敗時の扱いを決めます。大量処理する問い合わせ分類なら、1件あたりの単価が重要です。月数回しかない重要な障害調査なら、単価より正確性と説明可能性が重要です。

そのうえで、実測を行います。代表的な社内文書、問い合わせ、コード、ログを使い、入力トークン、出力トークン、処理時間、再試行回数、レビュー差し戻し率を測ります。Anthropicの発表にある価格や性能は有用な出発点ですが、自社の業務に入れたときのコストは、データ量と運用設計で大きく変わります。

最後に、モデルルーティングを設計します。軽いタスクは標準モデル、複雑なタスクは努力レベルを上げる、失敗時は上位モデルへ切り替える、リスクが高い操作は人間承認へ回す。こうした段階設計があると、コストを抑えながら品質と安全性を保ちやすくなります。

導入前のチェックポイントは次のとおりです。

観点確認すること実務上の問い
タスク分類低リスク業務と高リスク業務を分けたかAIが失敗したとき、誰にどんな影響が出るか
コスト実データでトークン量を測ったか1件あたりではなく月次で継続可能か
品質レビュー差し戻し率を見ているかAIの出力で人間の負担が増えていないか
安全性権限、承認、ログを設計したかAIがどの情報を読み、どの操作をしたか説明できるか
切り替え上位モデルや人間へ回す条件があるか難しい依頼を安いモデルで抱え込ませていないか

7. まとめ

Claude Sonnet 5の発表は、AIエージェント時代のモデル選定が「最強モデルを選ぶ」だけでは足りないことを示しています。性能、価格、努力レベル、安全性、ツール利用、レビュー負荷を合わせて考えなければ、実務ではコストか品質のどちらかが崩れます。

企業にとっての現実的な選び方は、タスク単位でモデルを使い分けることです。標準的な業務は価格性能のよいモデルで処理し、難しい判断や高リスク操作は努力レベルを上げる、上位モデルへ回す、人間承認を挟む。こうしたルーティングを設計しておくと、AIエージェントを「試して終わり」ではなく、継続可能な業務基盤として運用しやすくなります。

OpenBridgeでは、AIエージェント開発、Claude CodeやCodexを含む開発ワークフロー設計、RAG、MCP Gateway、社内ツール連携、権限管理、監査ログ設計を支援しています。新しいモデルを導入するときほど、モデル名ではなく、任せる業務、止める場所、測る指標から設計することが重要です。