Claude 3.5 Sonnet
読み: クロード スリーポイントファイブ ソネット
Claude Sonnetとは低コストLLM
Claude 3.5 SonnetはAnthropicが開発した大規模言語モデルで、同社のClaudeシリーズにおける中位モデルに位置する。コーディング能力と長文コンテキストの処理に強みを持ち、コストパフォーマンスの高さから開発者の実務利用が急速に広がった。
かんたんに言うと
コストパフォーマンスに優れた実務の主力選手。上位モデルに迫る実力を半分以下の料金で出す。特にプログラムを書かせると、チーム内で最も頼りになるタイプである。
コスト対性能で選ばれるClaude 3.5 Sonnetの基本概念
Anthropicはモデルを3つの性能帯に分けている。最上位のOpus、中位のSonnet、軽量のHaiku。Sonnetは「コストと性能のバランスが最もよい」という位置づけで、多くの業務用途ではOpusを使わずともSonnetで十分な精度が出る。
2024年6月にリリースされたClaude 3.5 Sonnetは、前世代のClaude 3 Opusを複数のベンチマークで上回った。上位モデルの世代を中位モデルの次世代が追い越すという構図で、モデルの命名と実力が一致しない状況が生まれた。
ユーザーにとって重要なのは名前ではなく実力である。APIの利用料金はOpusの5分の1程度で、レスポンス速度も速い。同等以上の品質を低コストで得られるなら、わざわざ上位モデルを選ぶ理由がなくなる。
コーディング性能が突出している理由
Claude 3.5 Sonnetがエンジニアの間で特に支持されているのは、コード生成の精度の高さにある。SWE-benchと呼ばれるソフトウェアエンジニアリングのベンチマークで、リリース当初はGPT-4oを含む主要モデルの中で最高スコアを記録した。
実務で評価されるポイントは2つ。まず、既存のコードベースを読み取って文脈を正確に把握する力。大規模なプロジェクトのコードを渡したとき、関数間の依存関係やアーキテクチャの意図を汲み取ったうえで修正案を出してくる。次に、エラーの修正精度。バグレポートとスタックトレースを渡すと、根本原因を特定して修正コードを生成する能力が高い。
ただし、これはベンチマークの話であり、実際のプロジェクトでは前提条件の伝え方で結果が大きく変わる。プロンプトの書き方が雑だと、どんなモデルでも見当違いなコードを出力する。
GPT-4やGeminiとの棲み分け
OpenAIのGPT-4o、GoogleのGemini 1.5 Pro、そしてClaude 3.5 Sonnet。この3つが現時点での実務利用の主力モデルである。
GPT-4oはマルチモーダル対応とエコシステムの広さが強み。ChatGPTのプラグインやGPTsを通じた拡張性に優れ、非エンジニアが日常的に使うユースケースに強い。Gemini 1.5 Proはコンテキストウィンドウの長さが特徴で、100万トークン以上の入力に対応する。書籍や長大なログファイルの分析に向いている。
Claude 3.5 Sonnetはコーディングと長文の構造化に強く、開発者やテクニカルライターから支持されている。200Kトークンのコンテキストウィンドウを持ち、Geminiほどではないが十分な長さを確保している。
実際の現場では、用途によってモデルを使い分けるケースが増えている。コード生成はClaude、画像を含む分析はGPT-4o、長大な文書処理はGeminiという具合に。1つのモデルに固定するメリットは薄れつつある。
API利用時の実務的な注意点
Claude 3.5 SonnetのAPIはAnthropicのコンソールから利用できる。料金体系は入力トークンと出力トークンで単価が異なり、出力のほうが高い。コスト管理をするなら、プロンプトの設計段階で出力の長さを制御する工夫が要る。
レート制限にも注意が必要である。無料プランでは1分あたりのリクエスト数に上限があり、業務利用するなら有料プランへの移行が前提になる。AWSのAmazon BedrockやGCPのVertex AIを経由して利用する方法もあり、この場合はクラウドベンダーの課金体系に統合できる。
もう一つの注意点はデータの取り扱い。APIを通じて送信したデータがモデルの学習に使われるかどうかは契約プランによって異なる。ビジネス用途では、学習に使用されないことが明示されたプランを選ぶのが基本になる。
モデル選定で判断すべきポイント
結局のところ、どのモデルを採用するかは「何に使うか」で決まる。
社内のコーディングアシスタントとして導入するなら、Claude 3.5 Sonnetは有力な選択肢になる。カスタマーサポートの自動化なら、エコシステムが充実しているGPT-4oのほうが立ち上げが速いかもしれない。
ベンチマークのスコアだけで判断するのは危険である。ベンチマークは標準化されたテストであり、自社の業務データとは性質が違う。可能なら、実際の業務データでプロトタイプを組み、精度とコストを自社の環境で検証するのが確実な方法である。
当社の見解
当社は機密情報のマスキング処理を全てローカルAIで行っている。これにより機密情報を外部に送信せずにAI処理できるようになった。だが、AIが嘘をつくハルシネーションの問題は依然としてある。確認していないのに「確認しました」と言う。当社はこの前提で運用を設計している。事実と推測の強制分離、ファクトチェック機能、3つのAIと人間の同士の三重検証を行っている。どこまでいっても、AIは完璧ではない。理論上100%安全設計をしていても、AIも人間も想定しないことは起こるものだ。その万が一に備えておくことが、AIを使う上では前提になっている。だろうではなく、かもしれない運用がAIを使う上での安全基盤となっている。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。