Claude のモデルが「Sonnet 4.6 と Opus、API も Bedrock も GitHub も並んでいて、結局どう選べばいいか分からない」と立ち止まっていませんか。実際、ラッコキーワード実測(2026 年 5 月時点)でも「Claude Sonnet 4.6」は月 2,400 件・SEO 難易度 34 の MOFU 領域。私自身は Max プラン課金中で、Anthropic 直 API と Bedrock 経由を業務で叩いています。
結論から言うと、Sonnet 4.6 は業務日常使いの主力モデル、深掘り推論や 1M context が必要なときだけ Opus 4.6 / 4.7 に切り替えるのが筋——というのが、3 モデル×3 経路を毎日触っている感覚です。本記事では技術仕様・料金・直 API / Bedrock・Opus / Haiku / Codex 系比較・GitHub 統合まで通貫整理します。
とりあえず最短で「自分は Sonnet 4.6 をどこから触り始めればいいか」を知りたい方は、セクション 1「結論」と セクション 5「Anthropic 直 API での使い方」から読み始めると、5 分で判断材料が揃います。
01 — 結論:Sonnet 4.6 は「業務日常使いの主力」、Opus 切替は深掘り推論と 1M context のときだけ(一行マップ)
📖 この章で使う用語
- Claude Sonnet 4.6(クロード ソネット 4.6):Anthropic 社の Claude シリーズ中堅・主力モデルの 2026 年 5 月時点バージョン。車に例えるとセダン。
- Anthropic(アンソロピック):Claude を開発・運営している米国の AI 企業。OpenAI 出身者が設立。
- Opus / Sonnet / Haiku:Claude の 3 モデルランク。最上位 / 主力 / 軽量の階層。
- 3 経路:Anthropic 直 API / AWS Bedrock 経由 / Pro・Max プラン経由の 3 つの利用ルート。
まず結論から書きます。Claude のモデルで迷ったら、普段の業務は Sonnet 4.6、PDF 50 ページ要約や複雑な要件整理など「深掘り推論」が必要なときだけ Opus 4.6(または 4.7)に切り替える——これが、3 モデル × 3 経路を毎日叩いている私のいちばん実用的な答えです。
3 行で覚えていただきたいのは、次の住み分けです。
- Sonnet 4.6 = 中堅・主力。短い質問、コード生成、レビュー、文章整形、議事録整理に十分(業務日常の主力)
- Opus 4.6 / 4.7 = 最上位。PDF 50 ページ要約、複雑な要件整理、コーディングの設計壁打ち(深掘り推論が必要なとき)
- Haiku = 軽量・速度優先。分類、抽出、要約の量産(コストと速度を抑えたいとき)
車のたとえだと、Sonnet 4.6 がセダン、Opus がスポーツカー、Haiku が軽自動車です。通勤と買い物の 9 割はセダンで足りますし、レース用にはスポーツカーが必要で、街乗り大量タスクは軽自動車が向いている。場面で乗り換えるのが、いちばん体力にもお財布にも優しい運用です。
ここで本記事の立ち位置と、既存記事との役割分担を明示しておきます。本記事は 「Sonnet 4.6 単独軸」——このモデルそのものをどう選ぶか、どの経路(直 API / Bedrock / Pro・Max / GitHub 統合)でどう叩くか、Opus 4.6 / Haiku / GPT Codex 系との違いはどうか——に焦点を絞ります。Opus 単体の深掘りは Claude Opus、3 モデルの俯瞰比較は Claude Opus と Sonnet の違い、Claude プロダクト全体は Claude 使い方、料金プラン全体は Claude 料金プラン、GitHub Actions 統合専門は Claude Code Action、エンタープライズ AI 基盤の全体は AWS Bedrock、AI コーディング親ハブは AI コーディング で、それぞれ別記事として整理済みです。本記事は「Sonnet 4.6 単体の選び方」に絞ることで、各記事を読み合わせると Claude 全体像が立体的に立ち上がる構成にしています。
私自身の立ち位置もお伝えしておきます。私は Max プランに課金中で、Anthropic 直 API は業務本番運用、AWS Bedrock 経由 Claude は概念・選定整理レベルで部分使用、Claude Code(CLI)と GitHub Copilot は業務で使っています。Free 期から Pro 期 1〜2 ヶ月を経て Max に上がった、という段階的な経路です。これまでの業務での経験から書きますが、運用の温度感はルートごとに分けて書きます。具体的には、(1) Anthropic 直 API = 業務本番運用、(2) Bedrock 経由 Claude = 概念・選定整理レベルでの部分使用、(3) Claude Code Action = 業務で部分的に運用、(4) GPT Codex 系(GPT 5.3 codex / Codex 5.3 等)= 業務本番運用なしで公開情報からの整理、という分け方です。
なお、料金は変動しますし、モデルのリリース動向も日進月歩です。最新の体系と性能は anthropic.com で必ず事前確認してから判断してください。本記事の数字も 2026 年 5 月時点のもので、半年経つと変わっている可能性が高いです。「絶対 Sonnet 4.6 が一番」「必ず速い」「絶対 Opus が必要」とは申し上げません——個人差・業務差・依頼内容で振れる領域です。
02 — Claude Sonnet 4.6 とは——Anthropic 3 モデル系列での位置づけと 4.5 → 4.6 の進化
📖 この章で使う用語
- Sonnet(ソネット):14 行の定型詩。Claude の中堅・主力モデル名。
- モデル世代:Anthropic が時期ごとにリリースする Claude のバージョン群。3 系 / 3.5 系 / 4 系のような系列。
- バージョン番号(4.5 / 4.6):同じ Sonnet でも世代を表す番号。本の版数のイメージ。
ここからは、Sonnet 4.6 の「Anthropic 3 モデル系列の中での位置づけ」「4.5 → 4.6 で何が変わったか」を整理します。
02-1. Anthropic 3 モデル系列の中での Sonnet の位置づけ
Anthropic の Claude シリーズは、1 つの世代の中に Opus / Sonnet / Haiku の 3 モデルが用意される構造になっています(2026 年 5 月時点)。Sonnet は常に「主力・中堅」、Opus が「最上位」、Haiku が「軽量」というスケール関係です。
3 つとも「言葉の作品」のメタファーで命名されています。
- Opus:ラテン語で「作品・労作・大作」。最上位。
- Sonnet:14 行の定型詩。中堅サイズ。主力。
- Haiku:俳句、17 音の日本の定型詩。軽量。
Sonnet の役割を 1 文で書くなら、「Claude シリーズの中で、賢さとコストのバランスが最も取れた主力モデル」 です。普段の業務で 9 割の依頼を任せられる「日常運用の本命」という立ち位置です。出版社のたとえで言うと、Opus が「上製・函入りの大作」、Sonnet が「単行本」、Haiku が「文庫本」のイメージです。
02-2. 4.5 → 4.6 で何が変わったか(公式リリース要約 + 業務体感)
2026 年 5 月時点、Sonnet には 4.5 と 4.6 が存在し、4.6 が現行主流です。4.5 → 4.6 の変更点として公式(anthropic.com/news)が挙げているのは、長文文脈での推論精度の向上、コーディングタスクの安定性、Tool Use(外部関数呼び出し)の信頼性、出力速度——あたりが代表的です(最新のリリースノートは anthropic.com で必ず事前確認してください)。
業務で 4.5 から 4.6 に乗り換えたときの私の体感としては、「コード生成の安定感」と「長い社内ドキュメントを読み込ませたときの応答品質」が一段上がった感覚がありました。営業時代の身近なたとえで書くと、4.5 から 4.6 への切替は、車のマイナーチェンジで燃費とエアコンの効きが少しずつ良くなった、というレベルの体感です。明日から世界が変わる、という派手な差ではなく、毎日触っていると気づく、底上げ型の改善でした。
02-3. 「絶対 4.6 が一番」とは申し上げません
ここで重要なメタ宣言を 1 つ。「絶対 4.6 が一番」「絶対 4.5 で十分」とは申し上げません。Anthropic のリリースサイクルは早く、4.7 系列が一般化すれば、Sonnet 4.7 / 4.8 と続く可能性があります。本記事の数字と性能評価は 2026 年 5 月時点のもので、半年後には景色が変わっている前提でご参照ください。
3 モデルの俯瞰比較(Opus / Sonnet / Haiku の使い分け 5 軸)は Claude Opus と Sonnet の違い で別建てしているので、興味がある方はそちらをご覧ください。本記事は「Sonnet 4.6 単独深掘り」に絞ります。
03 — 技術仕様——コンテキストウィンドウ 1M / max tokens / model ID / リージョン
📖 この章で使う用語
- コンテキストウィンドウ:AI が「一度に受け取れる文章の長さ」の上限。会議室の机に同時に広げられる資料の量のイメージ。
- 1M context(100 万トークン):100 万トークン分の文脈。日本語で約 75 万字、A4 用紙にして約 5,000 ページ分。
- max tokens(出力上限):AI が「1 回の応答で出力できる文字数」の上限。
- model ID:API で呼び出すときに指定するモデルの識別子。商品コードのイメージ。
- トークン:AI が文章を区切る最小単位。日本語 1 文字 ≒ 1〜1.5 トークン、英語 1 単語 ≒ 1〜2 トークン。
ここからは、Sonnet 4.6 の技術仕様を 4 軸で整理します。サジェスト 6 位「context window」、9 位「max tokens」が並んでいることからも、技術仕様レベルで Sonnet 4.6 を評価したい層が一定数いるサインです。最新の正式仕様は anthropic.com の公式ドキュメントで必ず事前確認してください——本記事の数字は 2026 年 5 月時点の公開情報からの整理です。
03-1. コンテキストウィンドウとは——「机に広げられる資料の量」
コンテキストウィンドウは、AI が 「一度に受け取れる文章の長さ」 の上限です。営業時代の身近なたとえで書くと、商談の打合せ机の上にどれだけの資料を同時に広げられるか、という「机の広さ」のイメージです。机が広ければ広いほど、相手の発言と過去資料を同時に参照しながら話せます。狭ければ、机に乗らない資料は別の部屋に置いておくか、要約して持ち込むか、という運用になります。
Sonnet 4.6 は 1M context(100 万トークン)に対応しています(2026 年 5 月時点、公式仕様)。日本語で換算すると約 75 万字、A4 用紙にして約 5,000 ページ分の文脈を 1 回のリクエストで受け取れる、という規模感です。コンテキストウィンドウは、Claude 3 系列の 200K → 4 系列の 1M と、世代ごとに大きく拡張されてきました。
03-2. Sonnet 4.6 の 1M context が効くケース 3 つ
1M context が業務でどう効くか、私の業務感覚で 3 シーンを挙げます。
① 大規模コードベースの一括読み込み:数十ファイル × 数千行のコードベースを 1 回のリクエストで Sonnet 4.6 に読ませて、「全体的な構造の問題点」「リファクタの優先順位」を相談する用途です。Claude Code(CLI)で /model コマンドで Sonnet 4.6 に切り替えれば、リポジトリ全体を文脈として読ませながら作業できます。
② 年間議事録の横断分析:12 ヶ月分の議事録(合計数十万字)を 1 回のリクエストで読ませて、「年間で繰り返し出ている課題」「テーマ別の傾向」を抽出する用途です。手で読み返すと丸 1 日かかる作業が、Sonnet 4.6 + 1M context だと数分で骨子が出てきます。
③ 長大仕様書 + 既存実装 + 質問の同時参照:仕様書 100 ページ + 既存実装 数千行 + 「この変更を入れたい」という質問——この 3 つを 1 回のリクエストでまとめて読ませて、設計の整合性を相談する用途です。会議室の机にすべての資料を広げて、相手と一緒に確認しながら話せる感覚です。
ただし、1M context を毎回フル活用しようとすると応答が遅くなりますし、料金も嵩みます。「机を広く使えるが、毎回フル展開しなくていい」 という運用感覚が、私の業務での落ち着きどころです。
03-3. max tokens(出力上限)と出力分割の業務作法
max tokens は 「1 回の応答で出力できる文字数」 の上限です。コンテキストウィンドウが「入力の上限」だとすると、max tokens は「出力の上限」です。Sonnet 4.6 の max output tokens は 64K(6.4 万トークン)が現行水準(2026 年 5 月時点、最新の正式値は anthropic.com で必ず事前確認してください)。
64K トークンは日本語で約 4.8 万字 ≒ 単行本約 80 ページ分。1 回の応答でかなり長い文書を生成できます。ただし、長文を 1 回で出力させると、(1) 応答時間が長くなる、(2) 途中で品質が落ちやすい、(3) 料金が嵩む——という 3 つの理由から、私の業務では 「長文は章ごとに分割して複数回叩く」 運用を基本にしています。本記事のような 1.5〜2 万字の記事も、章ごとに分けて Claude Code で書いていく方が、結果的に品質が安定する感覚です。
03-4. model ID 一覧(API 識別子と提供リージョン)
API で Sonnet 4.6 を呼び出すときは、model ID(モデル識別子)を指定します。Anthropic 直 API では claude-sonnet-4-6 系の識別子(具体的な文字列は anthropic.com/docs の最新版で必ず事前確認してください)、AWS Bedrock 経由では anthropic.claude-sonnet-4-6-v1:0 のような Bedrock 命名規則の文字列を使います。
提供リージョン(どの地理拠点から叩けるか)は、Anthropic 直 API はグローバル提供、AWS Bedrock 経由は US East / US West / Tokyo 等のリージョン別提供で、リージョンごとに利用可能なモデルが異なります。データ所在地・レイテンシ・社内コンプラ要件で選ぶ必要があり、最新の提供状況は aws.amazon.com/bedrock/ で必ず事前確認してください。
04 — 料金——per-token 単価と Opus / Haiku との 3 モデル比較
📖 この章で使う用語
- per-token 単価:「百万トークンあたり何ドル」で表す API 料金。入力と出力で別建て。
- prompt caching:同じプロンプトの一部を「キャッシュ」して再利用すると、入力料金が割引になる仕組み。
- batch 割引:複数のリクエストをまとめて非同期で投げると、料金が割引になる仕組み。
- Pro / Max プラン:Claude.ai のサブスクリプション。Pro は月額約 $20、Max は月額約 $100〜$200。
ここからは、Sonnet 4.6 の料金を整理します。サジェスト 10 位「price」が示すとおり、料金は最大の検索意図のひとつです。料金は変動するため、本記事の数字は参考値として、anthropic.com/pricing で必ず最新値を事前確認してください。
04-1. API 単価(公式値、2026 年 5 月時点)
Sonnet 4.6 の Anthropic 直 API 単価は、入力 $3 前後/百万トークン、出力 $15 前後/百万トークン(2026 年 5 月時点、anthropic.com/pricing からの参照値)。これを Opus 4.6 / 4.7 や Haiku と並べると、おおむね次のレンジ感です。
| モデル | 入力単価(/百万 tok) | 出力単価(/百万 tok) | Sonnet 比 |
|---|---|---|---|
| Opus 4.6 / 4.7 | $15 前後 | $75 前後 | 約 5 倍 |
| Sonnet 4.6 | $3 前後 | $15 前後 | 基準 |
| Haiku | $0.25 〜 $1 前後 | $1.25 〜 $5 前後 | 約 1/3 |
※すべて参考値、最新値は anthropic.com/pricing で必ず事前確認してください。
業務感覚で書くと、Opus は Sonnet の約 5 倍、Haiku は Sonnet の約 1/3 という料金スケールです。日常業務の 9 割を Sonnet 4.6 で叩いて、深掘り推論が必要な 1 割だけ Opus に切り替える運用が、コスト効率としていちばん落ち着きます。逆に、簡単な分類タスクを毎回 Sonnet で叩くと割高になるので、量産タスクは Haiku に流す、という使い分けが筋です。
04-2. prompt caching と batch 割引——業務コスト最適化の 2 つの仕組み
公式 API には、料金を抑えるための 2 つの仕組みがあります。
prompt caching:同じプロンプト(システム指示や長い参照ドキュメント)を繰り返し送るとき、最初の 1 回をキャッシュして 2 回目以降は割引価格で再利用できる仕組みです。社内ドキュメント参照型の RAG 系プロダクトで、毎回同じ参照テキストを送るケースに効きます(最大 90% 程度の割引、最新値は公式で必ず事前確認してください)。
batch 割引:複数のリクエストを「まとめて非同期で投げる」と、通常の半額程度で処理してもらえる仕組みです。リアルタイム性が不要な分析タスク(夜間バッチで議事録を一括要約する等)に効きます(通常価格の 50% 程度、最新値は公式で必ず事前確認してください)。
業務での感覚としては、RAG 系で大きいシステムプロンプトを使っているなら prompt caching、夜間バッチや非同期分析タスクなら batch 割引——という棲み分けで、両方の仕組みをセットで活用するのが、本気でコストを抑えるときの王道です。
04-3. Pro / Max プランで使える Sonnet 4.6
API ではなく、Claude.ai のサブスクリプション(Pro / Max)でも Sonnet 4.6 は使えます。Free / Pro / Max のすべてのプランで Sonnet 4.6 が利用可能(2026 年 5 月時点)です——Opus が Pro 以上限定なのに対し、Sonnet 4.6 は Free でも触れる位置づけです。
私の経路を書くと、Free 期に Sonnet で触り始めて、Pro(月額約 $20)で 1〜2 ヶ月使い込み、業務利用が増えたタイミングで Max(月額約 $100〜$200)に上げました。Pro / Max の選び方の詳細は Claude 料金プラン で全体整理しているので、サブスクで Sonnet 4.6 を使いたい方はそちらもご参照ください。
なお、料金については「絶対これがお得」とは申し上げません。利用頻度・組織の契約事情・API かサブスクかの使い分けで振れるため、ご自身の使い方で見比べていただくのが筋です。
05 — Anthropic 直 API での使い方——curl と Python SDK の最小サンプル
📖 この章で使う用語
- API キー:Anthropic の API を叩くための「会員証」のような文字列。console.anthropic.com で発行。
- curl(カール):コマンドラインから HTTP リクエストを送るツール。
- Python SDK:Anthropic 公式の Python ライブラリ。API を Python から簡単に叩ける。
- messages.create:Anthropic API の中心メソッド。チャット風の対話を 1 ターン作る。
- ストリーミング応答:応答をひと塊で待つのではなく、生成中の文字を順次受け取る方式。
- rate limit:「1 分あたり何回まで」のような API 呼び出し回数制限。
ここからは、Sonnet 4.6 を Anthropic 直 API で叩く最小サンプルを整理します。私は業務本番運用を Anthropic 直 API で回しており、Ruby / Python / Scala の自社プロダクトから日常的に呼び出しています(プロフィール記述に合わせます)。
05-1. API キー取得 5 ステップ
(1) console.anthropic.com にアクセスして Anthropic アカウントを作成
(2) Billing からクレジットカードを登録(無料枠は限定的、業務利用は従量課金前提)
(3) API Keys メニューで「Create Key」を実行
(4) 表示された API キー(sk-ant-... で始まる文字列)をコピー
(5) ローカル開発環境では ANTHROPIC_API_KEY 環境変数に格納(コミット禁止)
API キーは Anthropic 側の「会員証」相当の文字列で、漏洩すると料金が他人に使われるリスクがあるため、コードにハードコードせず、環境変数 / Secret Manager で必ず管理してください。GitHub に誤コミットすると、自動スキャンで検知されて無効化されますが、それまでに使われる可能性があります。
05-2. curl 最小サンプル
curl で Sonnet 4.6 を叩く最小サンプルです。シェルから 1 コマンドで動作確認できます。
# Sonnet 4.6 を curl で叩く最小サンプル
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-4-6",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "営業7年からエンジニアに転職した経緯を3行でまとめてください。"}
]
}'
model 欄に claude-sonnet-4-6 系の識別子を指定するだけで、Sonnet 4.6 が選ばれます。具体的なモデル ID 文字列は anthropic.com/docs で最新版を必ず事前確認してください。
05-3. Python SDK 最小サンプル
Python から叩くなら、公式の anthropic SDK を使うのがいちばん楽です。pip install anthropic でインストールしたら、次のコードで動きます。
# Python SDK で Sonnet 4.6 を叩く最小サンプル
import os
from anthropic import Anthropic
# API キーは環境変数から(コードにハードコードしない)
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
# messages.create でチャット風の対話を 1 ターン
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system="あなたは営業出身のエンジニアです。読者は未経験者です。",
messages=[
{"role": "user", "content": "Python の基礎を学ぶ最短順序を3ステップで教えてください。"}
],
)
print(response.content[0].text)
system 欄でシステムプロンプト(AI の人格・前提)を指定し、messages で会話履歴を渡します。複数ターンの対話なら、messages に過去のやり取りを順に積んでいけば文脈が継続します。
05-4. ストリーミング / Tool Use / Vision の概要
公式 API には、最小サンプル以外にも 3 つの主要機能があります(業務で使う頻度が高い順)。
ストリーミング応答:応答をひと塊で待たず、生成中の文字を順次受け取れます。チャット UI で「タイピング中」のように見せたいときに必須です。client.messages.stream(...) で開始し、for text in stream.text_stream で 1 文字単位で取得できます。
Tool Use:AI が外部関数(電卓・検索・データベース問い合わせなど)を呼び出せる仕組みです。AI エージェントを組むときの中心機能で、AI が「この計算は電卓に投げよう」と判断して関数を呼びます。詳細は AIエージェント とは と AIエージェント 作り方 で扱っています。
Vision:画像をプロンプトに入力できる機能です。スクリーンショット、図表、写真を読み込ませて、AI に説明・解析させる用途。Sonnet 4.6 は Vision も対応しています(2026 年 5 月時点、公式仕様)。
05-5. rate limit とエラーハンドリングの業務作法
業務本番運用で API を叩いていると、rate limit(「1 分あたり何回まで」「1 分あたり何トークンまで」の上限)に当たります。Anthropic 公式の rate limit は契約ティア(Tier 1 / 2 / 3 / 4)で異なり、利用実績に応じて自動で引き上がっていく仕組みです。
エラーハンドリングで業務上必須なのは、(1) 429 Too Many Requests(rate limit 超過)への指数バックオフ再試行、(2) 500 系(一時的なサーバーエラー)への再試行、(3) API キー漏洩検知時の即時ローテーション、(4) コスト上限アラート、の 4 点です。本番運用に組み込むときは、これらをまとめて扱うラッパー層を 1 枚噛ませると、後々の運用が楽になります。
06 — AWS Bedrock 経由 Sonnet 4.6——modelId / IAM / リージョン
📖 この章で使う用語
- AWS Bedrock(ベッドロック):AWS の生成 AI 統合プラットフォーム。複数 LLM を一括で叩ける。
- modelId(Bedrock):Bedrock 上で各モデルを識別する文字列。
anthropic.claude-sonnet-4-6-v1:0のような形式。- IAM(Identity and Access Management):AWS の権限管理サービス。「誰が何を使えるか」を細かく設定。
- VPC(Virtual Private Cloud):AWS 内の「自社専用のネットワーク区画」。社外との通信を制限可能。
- 監査ログ:「誰がいつ何にアクセスしたか」の記録。コンプライアンス要件で必須なケースが多い。
- On-demand / Provisioned Throughput:Bedrock の 2 つの料金体系。使った分だけ / 一定枠を予約。
ここからは、AWS Bedrock 経由で Sonnet 4.6 を使うルートを整理します。まず立ち位置の宣言から書きます。私は Anthropic 直 API を業務本番運用、AWS Bedrock 経由 Claude は概念・選定整理レベルでの部分使用(プロフィール §2-2 記述に合わせます)。本セクションで語れる範囲は、「Bedrock 経由を選ぶ判断材料」「直 API との違い」「modelId と IAM 連携の入り口」までです。業務本番運用の細部(PrivateLink の具体的な構成例、Provisioned Throughput の最適予約タイミング等)は公式 docs と大手 SI のブログを参照しながら、本記事では深掘りしません。エンタープライズ AI 基盤の全体地図は AWS Bedrock で別建てしているので、Bedrock そのものを深掘りしたい方はそちらをご参照ください。
06-1. Bedrock 経由を選ぶ 5 つの判断材料
業務で「直 API か Bedrock 経由か」を整理するとき、私が確認している判断材料は次の 5 つです。
① IAM 連携:既存 AWS の権限管理(IAM ロール、IAM ポリシー)をそのまま継承できます。社内の AWS 運用ルールに乗せやすい。
② VPC 内通信(PrivateLink):インターネット経由を避けて、AWS の自社専用ネットワーク内で API を叩けます。金融・医療系のコンプラ要件で効きます。
③ 監査ログ集約:CloudTrail / CloudWatch で「誰がいつ何にアクセスしたか」を既存基盤に集約できます。監査対応がある組織で有利です。
④ コンプラ認証:AWS 既存の BAA / SOC 2 / ISO 27001 / FedRAMP / FISC 等の認証がそのまま継承できます。業界規制が厳しい領域で効きます。
⑤ 契約・請求の一本化:AWS との既存契約に乗せられるため、新規ベンダー稟議が不要になるケースがあります。
これら 5 つの組織要件が「現実に出てきた段階」で Bedrock を検討する、というのが、業務での選定整理の経験からの私の感覚です。逆に、個人検証や小規模 PoC では Anthropic 直 API の方が、API キー 1 本で 5 分で始められる手軽さがあります。
06-2. modelId / リージョン / boto3 サンプル
Bedrock で Sonnet 4.6 を叩くときは、Bedrock 命名規則の modelId を使います。anthropic.claude-sonnet-4-6-v1:0 のような形式が現行水準(2026 年 5 月時点、最新の正式 ID は aws.amazon.com/bedrock/ で必ず事前確認してください)。リージョンは US East / US West / Tokyo 等を選び、リージョン別に利用可能なモデルが異なります。
Python(boto3)から叩く最小サンプルは次の通りです。
# Bedrock 経由で Sonnet 4.6 を叩く最小サンプル(boto3)
import json
import boto3
# AWS の IAM 認証情報は ~/.aws/credentials や IAM Role から自動取得
client = boto3.client("bedrock-runtime", region_name="us-east-1")
# Bedrock の Messages API(Anthropic 互換)形式でリクエスト
body = {
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "営業出身のエンジニアにおすすめの学習順序を3行で。"}
],
}
response = client.invoke_model(
modelId="anthropic.claude-sonnet-4-6-v1:0",
body=json.dumps(body),
)
result = json.loads(response["body"].read())
print(result["content"][0]["text"])
直 API との違いとして、(1) 認証が IAM ベースになる、(2) modelId のフォーマットが Bedrock 命名規則になる、(3) リージョン指定が必須——という 3 点が主な変更です。
06-3. 業務本番運用の細部は法務・情シスへ事前確認
Bedrock の業務本番運用は、(1) PrivateLink の具体的な構成、(2) Provisioned Throughput の予約タイミングと最適化、(3) BAA 締結の段取り、(4) 業界ガイドライン(金融庁・個人情報保護法・医療情報ガイドライン等)への適合確認——など、組織側で整える論点が多い領域です。
これらは私の業務本番運用の射程外(概念・選定整理レベルでの部分使用に留まる)のため、本記事では深掘りしません。最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談いただくのが筋です。
07 — Sonnet 4.6 vs Opus 4.6 / Haiku——3 モデル使い分けの 5 軸
📖 この章で使う用語
- 3 モデル使い分け:1 つのブランド(Claude)の中で、用途・コスト・速度で 3 モデルを切替える運用。
- 賢さ(推論深度):複雑な要件を最後まで噛み砕いて応答する力。
- 速度(レイテンシ):リクエストから応答完了までにかかる時間。
ここからは、Sonnet 4.6 を Opus 4.6 / Haiku と比べたときの使い分けを 5 軸で整理します。サジェスト 1 位の「vs opus 4.6」が示すとおり、Sonnet と Opus の使い分けは最大の検索意図のひとつです。
07-1. 5 軸性能比較表
私が業務で 3 モデルを使い分けるときに見ている 5 軸を、表で並べます(2026 年 5 月時点の業務感覚、性能評価は依頼内容で振れます)。
| 軸 | Opus 4.6 / 4.7 | Sonnet 4.6 | Haiku |
|---|---|---|---|
| 賢さ(推論深度) | ◎ 最上位 | ○ 主力に十分 | △ 軽量向き |
| 速度(レイテンシ) | △ じっくり型 | ○ バランス型 | ◎ 高速 |
| コスト(per-token) | △ 約 5 倍 | ○ 基準 | ◎ 約 1/3 |
| コンテキスト窓 | 1M(4.7) / 200K(4.6) | 1M | 200K |
| 得意領域 | 複雑要件・長文整理 | 普段使い全般 | 大量タスク・分類抽出 |
業務感覚で書くと、「賢さは Opus 一強だが、コスト・速度・普段使いの 9 割は Sonnet 4.6 で十分」 という構図です。3 モデル俯瞰の詳細は Claude Opus と Sonnet の違い で別建てしています。
07-2. いつ Sonnet 4.6、いつ Opus 4.6、いつ Haiku の判断軸
3 モデルの選び分けで、私が業務で見ている判断軸は次の通りです。
Sonnet 4.6 を選ぶ場面(業務日常の 9 割):
- 短い質問(数百字〜数千字の応答)
- コード生成(中規模)、コードレビュー
- 文章整形、議事録の構造化
- エラーメッセージの解読
- RAG 系の応答生成
Opus 4.6 / 4.7 に切り替える場面(深掘り推論が必要な 1 割):
- PDF 50 ページ以上の要約・横断分析
- 複雑な要件整理(仕様 + 実装 + 質問の同時参照)
- コーディングの設計壁打ち(大規模リファクタの方針相談)
- 長文記事のドラフト(本記事のような 1.5 万字超)
- 1M context をフル活用したい長大文脈案件(4.7 系)
Haiku を選ぶ場面(量産タスク):
- 分類タスク(カテゴリ判定、ラベル付け)
- 抽出タスク(メール本文から情報を抜く)
- 要約の量産(夜間バッチで数千件の議事録を要約)
「絶対 Sonnet で十分」「絶対 Opus が必要」とは申し上げません——依頼内容と求める応答品質で振れる領域です。判断に迷ったら、まず Sonnet 4.6 で叩いて、応答品質が物足りないと感じたら Opus に切り替える、というのがコスト効率の良い試し方です。
07-3. 業務シーン 5 例での使い分け
具体的な業務シーンで 5 例並べると、次のような棲み分けになります。
| 業務シーン | 推奨モデル | 理由 |
|---|---|---|
| コード生成(中規模) | Sonnet 4.6 | 速度とコストのバランスが取れる |
| コードレビュー(PR 単位) | Sonnet 4.6 | PR の差分を読んでコメントするには十分 |
| 議事録整理(1 時間分) | Sonnet 4.6 | 構造化と要約に必要十分 |
| RAG 系応答生成 | Sonnet 4.6 | レイテンシが効くので Sonnet 主軸 |
| 長文資料の横断分析(数十万字) | Opus 4.7(1M) | 1M context が必要なケース |
Opus 単体の深掘りは Claude Opus で別建てしているので、Opus を主軸に選ぶ判断材料を探している方はそちらもご参照ください。
08 — Sonnet 4.6 vs GPT Codex 系(GPT 5.3 codex / Codex 5.3)——コーディング用途の比較
📖 この章で使う用語
- GPT Codex 系:OpenAI のコーディング特化モデル群。GPT 5.3 codex / Codex 5.3 などの名称。
- コーディング特化モデル:プログラミング用途に特化して訓練されたモデル。汎用モデルよりコード生成に強い設計。
- 推論深度:複雑な要件を最後まで噛み砕いて応答する力。
ここでも立ち位置の宣言から書きます。Claude Sonnet 4.6 は業務常用、GPT Codex 系(GPT 5.3 codex / Codex 5.3 等)は業務本番運用なしで公開情報からの整理レベルです。ChatGPT 自体は業務利用がありますが、Codex 系単体での業務本番運用はしていません。本セクションは「公開情報からの整理 + Sonnet 4.6 業務常用者の比較観察」のハイブリッドで書きます。
08-1. GPT Codex 系とは(公開情報からの整理)
GPT Codex 系は、OpenAI が提供する コーディング特化モデル群 の総称です。GPT 5.3 codex / Codex 5.3 などの名称で展開されており、汎用 GPT モデルよりもコード生成・リファクタ・バグ調査に特化した設計とされています(最新の正式情報は openai.com で必ず事前確認してください)。
Codex の流れは、初代 Codex(GitHub Copilot の中身として 2021 年に登場)から、現在の GPT 5.3 codex / Codex 5.3 系まで複数世代があります。本記事の数字は 2026 年 5 月時点の公開情報からの整理です。
08-2. コーディング用途での比較軸 3 つ
Sonnet 4.6 と GPT Codex 系を「コーディング用途」で比較するとき、公開情報からの整理 + Sonnet 4.6 業務常用者の観察として挙げられるのは、次の 3 軸です。
① 推論深度:複雑な要件を最後まで噛み砕いて応答する力。Sonnet 4.6 は Opus 比で 1 段下がる位置づけ、Codex 系は専用設計で「コードに関しては深い推論」と言われる領域です。汎用タスクは Sonnet 4.6 が有利、コードに閉じた推論は Codex 系が公開情報では強みが語られています。
② コンテキスト保持:会話の文脈や、複数ファイルの関係を保持する力。Sonnet 4.6 は 1M context で大規模コードベースを一括で読めるのが強み。Codex 系のコンテキスト窓は世代によって異なるため、最新仕様は openai.com で必ず事前確認してください。
③ コードスタイル:生成されるコードの読みやすさ・規約遵守。両者で出力スタイルに差があり、好みが分かれる領域です。私の業務感覚では、Sonnet 4.6 は「説明と理由付きのコード」が多めで、コードレビューを兼ねた壁打ちに向く印象があります。
08-3. 業務感覚での選び方——「絶対 Claude が一番」とは申し上げません
私の業務感覚としては、Claude Code(CLI)と Cursor で Sonnet 4.6 / Opus を業務常用しており、コーディング全般の主軸は Claude 側です。GitHub Copilot は補完用途で日常的に使っていますが、Copilot の内部モデルが GPT Codex 系か Claude かは設定で切り替え可能で、私は Claude モデルを選択することが多い、というのが セクション 10 で扱う実体験です。
ここで重要なメタ宣言を 1 つ。「絶対 Claude が一番」「絶対 Codex 系が劣る」とは申し上げません。OpenAI のリリースサイクルも速く、Codex 系の最新世代が「業務常用に値するか」は個人の業務シーンで振れます。本セクションは「Sonnet 4.6 を主軸に置いている私の選び方の整理」であり、Codex 系を主軸にする読者の選び方を否定するものではありません。ChatGPT / Claude / Gemini の業務利用全体の比較は 生成AI 入門 で扱っているので、3 プロバイダの俯瞰整理を求める方はそちらもご参照ください。
09 — GitHub Actions × Claude Code Action での Sonnet 4.6
📖 この章で使う用語
- Claude Code Action:GitHub Actions 上で Claude Code を動かす公式 Action。GitHub Marketplace から導入可能。
- workflow.yml:GitHub Actions の設定ファイル。「いつ何を動かすか」を YAML で記述。
- PR レビュー自動化:Pull Request を作ると AI が自動でレビューコメントを書き込む仕組み。
- CI/CD:継続的インテグレーション・継続的デリバリー。テストやデプロイの自動化基盤。
ここでも立ち位置の宣言を最初に。Claude Code Action は業務で部分的に運用しており、フル運用ではありません。個人 OSS リポでの動作確認 + 一部の業務リポでの PR レビュー補助に組み込むレベルです。本セクションで語れる範囲は、「workflow.yml でのモデル指定」「PR レビュー自動化での Sonnet 4.6 設定」「CI コスト最適化のモデル選び」までです。Claude Code Action そのものの専門深掘りは Claude Code Action で別建てしているので、認証 3 系統(直 API / Bedrock / Vertex)や運用リスクの深掘りはそちらをご参照ください。
09-1. workflow.yml でのモデル指定
Claude Code Action では、workflow.yml の with: ブロックで model を指定できます。Sonnet 4.6 を指定する最小サンプルは次の通りです。
# .github/workflows/claude-review.yml
name: Claude PR Review (Sonnet 4.6)
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
- uses: anthropics/claude-code-action@v1
with:
# Sonnet 4.6 を CI コスト最適化のため明示指定
model: claude-sonnet-4-6
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
model を省略すると、Action 側のデフォルトモデルが選ばれます。CI でモデルを明示する意義は、(1) 期待するコスト枠に収める、(2) 応答品質を予測可能にする、(3) 後から他モデルへの切替を試しやすくする——の 3 点です。
09-2. PR レビュー用 Sonnet 4.6 設定例
PR レビュー自動化での Sonnet 4.6 は、コスト × 品質のバランスが取れた選択肢です。Opus 4.7 を CI に走らせると料金が嵩むため、普段の PR レビューは Sonnet 4.6、特に重要な PR だけ Opus に切り替える運用が私の業務感覚での落ち着きどころです。
PR レビューの精度を上げたいときは、workflow.yml でシステムプロンプトをカスタマイズすると効きます。「コーディング規約の遵守を確認」「セキュリティ観点でのコメント追加」「テストカバレッジの不足を指摘」など、レビュー観点を明文化して system に注入する設計です。詳細は AI コードレビュー で 5 つのレビュープロンプト型を整理しているので、そちらもご参照ください。
ここで重要なメタ宣言を 1 つ。「絶対に Claude のレビューだけでマージしてよい」とは申し上げません。マージ判断 / 本番デプロイ / 機密処理 / 契約変更の 4 つは、人間が責任を持って判断する領域として明確に線を引いておく必要があります。Claude のレビューは「人間レビューの叩き台」と位置づけるのが、業務で部分的に使ってきた私の実感としていちばん健全な使い方です。
09-3. CI コスト最適化のモデル選び
CI でのモデル選びは、コスト × 品質のトレードオフです。私の業務感覚での使い分けを表にすると、次の通りです(2026 年 5 月時点)。
| CI 用途 | 推奨モデル | 理由 |
|---|---|---|
| 通常 PR レビュー | Sonnet 4.6 | コスト×品質のバランス(主軸) |
| 大規模リファクタ提案 | Opus 4.7 | 1M context と推論深度が効く |
| 簡易な型チェック・命名チェック | Haiku | コスト最小化が効く |
| CI コード生成(コミットメッセージ補助) | Sonnet 4.6 | 速度と品質のバランス |
workflow.yml で条件分岐させて、PR のラベルやファイル変更量に応じてモデルを切り替える設計も可能です(例:size/large ラベルなら Opus、それ以外は Sonnet)。最終的な CI コストは、PR 件数 × 平均 PR サイズ × per-token 単価で大きく動くため、組織の予算枠に合わせて月次でモデル選択を見直すのが現実的です。
10 — GitHub Copilot のモデル選択肢としての Sonnet 4.6
📖 この章で使う用語
- GitHub Copilot:GitHub 社の AI コード補完サービス。IDE 拡張で動く。
- model picker:Copilot の設定画面で「どのモデルで補完するか」を選ぶ UI。
- 内蔵 GPT 系:Copilot の標準モデル。OpenAI 系列のモデル群。
ここからは、GitHub Copilot で Sonnet 4.6 を選ぶ場合の整理です。GitHub Copilot は業務常用、Copilot 内での Claude モデル切替は使う頻度限定的(プロフィール記述に合わせます)という立ち位置で書きます。
10-1. Copilot model picker での Sonnet 4.6 選択手順
GitHub Copilot は、2024 年以降に モデル選択機能(model picker)を提供しており、内蔵 GPT 系以外に Claude モデルや Gemini モデルを選べるようになっています(2026 年 5 月時点、最新の対応状況は github.com/copilot で必ず事前確認してください)。
Sonnet 4.6 を選ぶ手順は、ざっくり次の通りです(VSCode の場合、最新の正式手順は GitHub 公式ドキュメントで必ず事前確認してください)。
(1) VSCode で GitHub Copilot Chat を開く
(2) チャットウィンドウのモデル選択メニュー(右上の歯車 or ドロップダウン)を開く
(3) Claude 系のモデル選択肢から Claude Sonnet 4.6 を選択
(4) 設定保存後、補完・チャットが Sonnet 4.6 経由で動作
組織契約の Copilot Business / Copilot Enterprise でも、管理者設定で Claude モデルの利用可否を切り替えられる場合があります。組織の設定状況は管理者に確認してください。
10-2. Copilot 内蔵 GPT 系との使い分け
Copilot の内蔵 GPT 系と Sonnet 4.6 の使い分けで、私の業務感覚で挙げられるのは次の通りです。
Sonnet 4.6 を選ぶ場面:
- Claude.ai や Claude Code で慣れた応答スタイルを Copilot でも使いたい
- 説明と理由付きのコードを補完してほしい
- 1M context の長文文脈を Copilot で活用したい(対応状況は公式で必ず事前確認)
内蔵 GPT 系を選ぶ場面:
- Copilot のデフォルト設定そのままで使いたい
- GPT 系の応答スタイルに慣れている
- OpenAI のコーディング特化動向(Codex 系)を試したい
「絶対 Claude が一番」「絶対 GPT が一番」とは申し上げません——個人の慣れと用途で振れる領域です。Copilot 自体は「補完用途で日常的に使っている」のが私の業務感覚であり、Claude モデル切替は「特に深く考えながら書きたいとき」だけ、という運用です。
11 — Claude Code(CLI)でのモデル切り替え——/model コマンドで Sonnet 4.6 を選ぶ
📖 この章で使う用語
- Claude Code:Anthropic 公式のターミナル型 AI エージェント。コードベース全体を読みながら作業可能。
/modelコマンド:Claude Code 内でモデルを切り替えるスラッシュコマンド。- スラッシュコマンド:CLI 内で
/から始まる特別なコマンド。設定変更などに使う。
ここからは、Claude Code(CLI)での Sonnet 4.6 切替を整理します。Claude Code は業務常用、本記事も Claude Code で執筆中(Opus 4.7 / 1M context)です。Claude Code そのものの始め方・使い方は Claude Code 使い方 と Claude Code 始め方 で別建てしているので、本セクションは「Sonnet 4.6 への切り替え方とシーン 3 つ」に絞ります。
11-1. /model コマンドの使い方
Claude Code(CLI)の中で /model と入力すると、現在のモデルが表示され、対話的に切り替えメニューが出てきます。例えば次のような流れです。
# Claude Code セッション内で /model を実行
> /model
Current model: claude-opus-4-7
Select a new model:
1. claude-opus-4-7
2. claude-sonnet-4-6
3. claude-haiku-4-5
> 2
Switched to: claude-sonnet-4-6
(実際の表示は Claude Code のバージョンによって異なります。最新の正式仕様は anthropic.com/docs/claude-code で必ず事前確認してください。)
/model 以外にも、起動時のオプションでデフォルトモデルを指定する方法や、環境変数で固定する方法があります。プロジェクトごとに .claude/config.json などで設定する運用も可能です。
11-2. モデル切替の業務シーン 3 つ
業務で Claude Code の /model を使ってモデルを切り替えるシーンを 3 つ挙げます。
① 軽い修正・小規模リファクタは Sonnet 4.6:1〜5 ファイル程度の小規模な修正は、Sonnet 4.6 の速度とコストのバランスが効きます。Opus 4.7 で叩くと応答が遅く、料金も嵩むため、軽作業は Sonnet 4.6 に切り替える運用です。
② 設計壁打ち・大規模リファクタは Opus 4.7:「このリポジトリ全体の構造を見直したい」「複雑な要件を整理したい」「1M context をフル活用して大規模コードベースを横断的に読みたい」というシーンは、Opus 4.7 に切り替えます。本記事執筆中の Claude Code セッションも Opus 4.7 で動作中です。
③ 量産タスク(コミットメッセージ生成、簡易型チェック等)は Haiku:大量に走らせる軽量タスクは、Haiku に切り替えてコストを抑えます。バッチ処理的な使い方で、Sonnet 4.6 を毎回叩くと割高なケースに有効です。
CLI 上で /model をスラッシュ 1 つで切り替えられるのは、Claude Code の業務常用感覚としては相当に楽な仕様です。AI コーディング全般の整理は AI コーディング で親ハブにしているので、Claude Code 以外のツール(Cursor / GitHub Copilot 等)との比較を求める方はそちらをご参照ください。
12 — Sonnet 4.6 を、エンジニアでない人がどう関わるか(非エンジニア UC 5 本)
📖 この章で使う用語
- Claude.ai:Anthropic 公式のチャット UI。ブラウザ / アプリで使える。
- モデル切替(Claude.ai):チャット画面のモデル選択メニューで Sonnet 4.6 を選ぶ操作。
ここまでは API / Bedrock / Claude Code / Copilot といった開発者向けの叩き方を整理してきました。ここからは、エンジニアでない読者の方でも Sonnet 4.6 をどう使えるかを、5 職種で整理します。共通の入口は 「Claude.ai のチャット画面でモデルメニューから Sonnet 4.6 を選ぶ」 だけです。Free プランでも Sonnet 4.6 は触れるので、最初の一歩はとても低い位置にあります。
12-1. 営業職:日報・週報の自然な整形、提案資料の論点出し
Before:商談メモを見ながら 15 分かけて日報を手書き、週報は週末にまとめて 1 時間。 After:商談メモを Claude.ai に貼って「今週の商談 5 件を、顧客別の課題と次の打ち手で 3 行ずつ整理してください」と頼むと、骨子が 30 秒で出てきます。提案資料の論点出しも、客先の業界キーワードと過去のヒアリングメモを渡せば、論点候補が 5〜10 個並びます。 所要時間:初回 5 分(Claude.ai 登録 + Sonnet 4.6 選択)、以降は日報 5 分以内 / 提案論点出し 10 分。 最初の壁:Claude.ai のモデル選択メニューが Pro 以上のプランだとデフォルト Opus になっていることがあり、Sonnet 4.6 への切替を最初に確認する必要があります。営業時代の私だったら、商談直後の車内で日報の骨子を作ってしまう用途でいちばん回したと思います。
12-2. 事務:議事録の整理、長文 PDF の要約(1M context が効く)
Before:1 時間の会議録音を手で起こして 2 時間かけて議事録化、長文 PDF(50 ページ以上)は読むだけで 1 日。 After:会議スクリプト(テキスト化済み)を Claude.ai に貼って「アクション / 決定事項 / 課題で分けて整理してください」と頼むと、構造化議事録が 1 分で出ます。長文 PDF は Claude.ai に直接アップロードして、章ごとの要約と「重要 5 点」を抽出させると、読む順序が決まります。 所要時間:議事録整形 10 分 / 50 ページ PDF 要約 5 分。 最初の壁:機密情報(社内データ、顧客情報、契約書)を Claude.ai に貼り付けると社外送信になるため、社内の情シス・法務に事前に利用許諾を取ってから運用してください。許諾なしで貼り付けるのは絶対に避けるべきです。
12-3. 個人事業主:請求書テンプレ / 顧客提案書ドラフト
Before:請求書テンプレを Word で毎回コピペ編集、顧客提案書は白紙から手書きで 2〜3 時間。 After:請求書の項目構造(業種・サービス・支払い条件)を Claude.ai に伝えて「請求書のテンプレを Markdown で作ってください」と頼むと、3 種類のひな型が一度に出ます。顧客提案書のドラフトも、顧客業界 × 提案テーマ × 競合状況の 3 軸を渡すと、構成と論点が一気に並びます。 所要時間:請求書テンプレ作成 5 分 / 提案書ドラフト 20 分。 最初の壁:個人事業主の方は、Free プランで始めて、利用頻度が増えてから Pro(月額約 $20)に上げる経路が無理がありません。Pro / Max の比較は Claude 料金プラン で別整理しているので、サブスク選びはそちらもご参照ください。
12-4. 副業ライター:記事の章立て設計、出典確認の下準備
Before:記事のテーマだけ決まって章立てに 1 時間悩む、出典探しに半日。 After:テーマと読者像と字数目標を Claude.ai に伝えて「章立てを 5 案、それぞれの差分を 1 行で」と頼むと、章立て候補が 5 種類並びます。出典確認の下準備も、調査キーワードを渡すと「公式ソース候補 5 つ」「Wikipedia 該当ページ」「学術論文の検索キーワード」が出るので、その後の手作業の地図ができます。 所要時間:章立て設計 10 分 / 出典下準備 15 分。 最初の壁:AI が出した出典をそのまま信じないこと。必ず一次ソースを開いて、内容と日付を確認してから引用してください。AI のハルシネーション(自信満々で間違える挙動)は今でも残っているリスクです。
12-5. エンジニア志望:コード写経の質問、エラーメッセージの解読
Before:チュートリアル本のコードでエラーが出るが、何が悪いか分からず 1 時間悩む。
After:エラーメッセージとコードを Claude.ai に貼って「このエラーの原因と直し方を、初学者向けに 3 ステップで」と頼むと、原因 → 修正案 → 再現確認の順で説明が出ます。コードの意味が分からない箇所も、「この for ループ の意味を、初心者に営業のたとえで説明してください」のような頼み方で噛み砕いてもらえます。
所要時間:エラー解読 5 分 / コード意味の質問 5 分。
最初の壁:AI に頼りきりで写経すると、自分で考える力が育たない側面があります。まず 5 分は自分で考えてから AI に聞く、というルールを自分で決めると、学習効果が落ちません。私自身、未経験 SES に入った最初の 3 ヶ月は AI が今ほど普及しておらず、ひたすら自分で調べていた経験があり、その時の「調べる癖」が今でも効いている感覚があります。
13 — 失敗パターン 5 つと、業務で踏みやすい落とし穴
📖 この章で使う用語
- コスト爆発:API 課金が想定を超えて膨らむ事象。料金監視がないと気づきにくい。
- rate limit:「1 分あたり何回まで」のような API 呼び出し回数制限。
- コンプライアンス要件:法令・規則を守るための社内基準。金融・医療・公共で特に厳しい。
- YMYL(Your Money or Your Life):金銭・健康・キャリアなど人生に影響する領域。Google が品質基準を特に厳しく定める。
ここからは、Sonnet 4.6 を業務で使うときに踏みやすい落とし穴を 5 つ整理します。私の業務感覚と公開情報からの整理を組み合わせたものです。
13-1. ① Sonnet 4.6 で十分なのに Opus を選んで料金が膨らむ
症状:「最上位モデルが一番いいだろう」と Opus を選び続けて、月末に API 請求が想定の数倍に膨らむ。 対処:依頼の 9 割は Sonnet 4.6 で十分です。Opus 4.7 を選ぶのは「PDF 50 ページ以上の横断分析」「複雑な要件整理」「コーディング設計壁打ち」「1M context をフル活用したい長大文脈案件」に限定する運用が、私の業務感覚での落ち着きどころです。
13-2. ② 1M context を毎回フル活用しようとして応答が遅くなる
症状:「1M トークン使えるんだから全部入れよう」と毎回満タンに入力して、応答時間が 1〜2 分に伸びる。 対処:1M context は「机を広く使えるが、毎回フル展開しなくていい」運用感覚で扱います。普段は数千〜数万トークンで足りる依頼が大半で、長大文脈が必要な特定シーン(年間議事録の横断分析、大規模コードベース読み込み)にだけ広く使う、という分け方が現実的です。
13-3. ③ 機密情報を Claude.ai に貼り付けてしまう
症状:社内データ・顧客情報・契約書・社外秘文書を Claude.ai のチャット画面に貼り付け、社外送信になる。 対処:機密情報は、(1) Claude.ai に貼らない、(2) 必要なら社内法務・情シスに利用許諾を取ってから運用、(3) 抽象化してから貼る、(4) Team / Enterprise / Bedrock 経由など別契約の経路を検討、の 4 段階で扱います。最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談いただくのが筋です。
13-4. ④ rate limit を超えて API エラーが連発
症状:業務本番運用で API を叩いていると、「1 分あたり何回まで」「1 分あたり何トークンまで」の rate limit に当たって 429 エラーが連発する。 対処:(1) 指数バックオフ再試行を実装、(2) Anthropic 公式の contact 経由で Tier 引き上げを申請、(3) batch API でリクエストを非同期化、(4) 利用量を平準化するキューを噛ませる——の 4 つが標準的な対処です。本番運用に組み込むときは、これらをラッパー層にまとめて 1 枚噛ませると後々楽になります。
13-5. ⑤ Bedrock 経由を選ぶ判断が組織のコンプラ要件を満たさない
症状:「コンプラ要件で Bedrock 経由が必要」と判断したが、実際は直 API でも要件を満たせた / 逆に Bedrock 経由でも不足要件があった。 対処:Bedrock 経由を選ぶ判断は、セクション 6 の 5 つの判断材料(IAM / VPC / 監査ログ / 認証 / 契約一本化)を、社内の情シス・法務と一緒に照らし合わせて決めるのが筋です。「絶対 Bedrock 経由が安全」「絶対 直 API がベスト」とは申し上げません——組織の業界・規模・既存 AWS 利用状況で振れる領域です。最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。
14 — よくある質問
Q1: Claude Sonnet 4.6 と Opus 4.6、結局どちらを使えばいいですか?
A. 「絶対これ」とは申し上げません(個人差・業務差・依頼内容で振れます)。私の業務感覚としては、短い質問・速度優先・コスト重視・コード生成・議事録整理なら Sonnet 4.6、PDF 50 ページ要約・複雑な要件整理・コーディングの設計壁打ち・1M context をフル活用したいときは Opus 4.6(または 4.7)、という使い分けが現実的です。3 モデル俯瞰は Claude Opus と Sonnet の違い で扱っています。
Q2: Claude Sonnet 4.6 のコンテキストウィンドウは何トークンですか?
A. 1M(100 万トークン)対応です(2026 年 5 月時点、公式仕様)。日本語で約 75 万字、A4 用紙にして約 5,000 ページ分の文脈を 1 回で受け取れます。ただし毎回フル活用する必要はなく、用途に応じて広く / 狭く使い分けるのが業務感覚です。最新仕様は anthropic.com で必ず事前確認してください。
Q3: Sonnet 4.6 を API で使う料金はいくらですか?
A. 2026 年 5 月時点、Anthropic 直 API で入力 $3 前後/百万トークン、出力 $15 前後/百万トークンが目安です(Opus の約 1/5、Haiku の約 3 倍のレンジ)。料金は変動するため、anthropic.com/pricing で必ず最新値を事前確認してください。prompt caching / batch 割引も活用すると業務コストを抑えられます。
Q4: AWS Bedrock 経由で Sonnet 4.6 を使うのと、Anthropic 直 API で使うのは何が違いますか?
A. 「絶対 Bedrock が安全」「絶対直 API がベスト」とは申し上げません。私の業務感覚では、直 API は本番運用の軽快さで選び、Bedrock 経由は IAM 連携 / VPC 内通信 / 監査ログ / コンプラ要件があるときに選ぶ、という使い分けが現実的です。最終判断は社内法務・コンプライアンス部門、必要に応じて弁護士の方へご相談ください。詳細は AWS Bedrock をご参照ください。
Q5: GitHub Copilot や Claude Code で Sonnet 4.6 を選べますか?
A. 選べます(2026 年 5 月時点)。GitHub Copilot は model picker で Claude モデルを選択可能、Claude Code(CLI)は /model コマンドで Sonnet 4.6 / Opus 4.7 / Haiku を切り替え可能です。最新の対応状況は公式ドキュメントで必ず事前確認してください。Claude Code Action での CI 用モデル指定は Claude Code Action で深掘りしています。
訂正・お問い合わせ
本記事の内容に誤りや古くなった情報を見つけた方は、お問い合わせフォーム(send@bon-bon-tools.com)までご連絡ください。記事末尾に訂正履歴として追記します。料金・モデル仕様は変動する領域のため、本記事の数字は 2026 年 5 月時点の公開情報からの整理であり、最新値は anthropic.com / aws.amazon.com / github.com の公式情報で必ず事前確認してください。
出典
- Anthropic 公式:Claude モデル一覧(取得:2026-05-20)
- Anthropic 公式:API ドキュメント Messages(取得:2026-05-20)
- Anthropic 公式:料金ページ(取得:2026-05-20)
- Anthropic 公式:Claude 4.6 リリースノート(取得:2026-05-20)
- Anthropic 公式:Claude Code ドキュメント(取得:2026-05-20)
- AWS Bedrock:Anthropic Claude モデルページ(取得:2026-05-20)
- AWS Bedrock:料金(取得:2026-05-20)
- GitHub Marketplace:anthropics/claude-code-action(取得:2026-05-20)
- GitHub Copilot 公式ドキュメント(取得:2026-05-20)
- ラッコキーワード「Claude Sonnet 4.6」検索ボリューム(取得:2026-05-19、月 2,400 件 / SEO 難易度 34)
関連記事
- Anthropic Console 使い方——APIキー発行・Workbench・使用量/コスト・課金管理を毎日触る視点で整理
- Claude Skills とは何か——SKILL.md / 自作 3 系統 / Slash commands・MCP・Tools との違いを整理
- Claude Opus とは何か
- Claude Opus と Sonnet の違い
- Claude 使い方
- Claude 料金プラン
- Claude Code Action とは
- AWS Bedrock とは何か
- Azure OpenAI Service とは何か——GPT/Codex モデル一覧・料金・直 API/AWS Bedrock 3 経路使い分け・「Azure に Claude はない」誤解まで整理
- Claude Code 使い方
- LLM ローカル——個人検証視点で Ollama + Llama 3 / Gemma を整理
- Claude Code 始め方
- AI コーディング
- AI コードレビュー
- LLM とは
- 生成AI 入門
- AIエージェント × MCP——標準仕様の手と目を増やす設計(自作 MCP サーバー本番運用者が整理)
- Claude Skills を自作する——SKILL.md の書き方から業務 3 系統・チーム配布まで「作る側」を実演
- Vibe coding とは——感覚で AI に書かせ、人間はレビューと方向づけに回る新スタイルを業務実践視点で整理
- Codex CLI とは——OpenAI 系の Claude Code 相当を、両方触った現役の生成AIエンジニアが比較しながら整理しました
- Vertex AI とは——Google Cloud の AI 基盤。Gemini と Claude on Vertex の二本柱・料金・3 基盤比較を業務試用視点で整理
- MCP サーバー 作り方——Python/TypeScript SDK で自作し本番運用まで「作る側」の完全マニュアル
- Gemini CLI 使い方——Google のターミナル型 AI コーディングを 3 ツール比較で整理
- Gemini API 使い方——コードから Gemini を呼ぶ最小サンプルを Python・GAS で