1. はじめに
こんにちは、サーバーワークス橋本です。
炬燵を出したのに猫が占有してことにより、足を伸ばすことが出来ません。
足を伸ばすと容赦ない猫キックがさく裂するのでこの時期は実は窮屈な目にあいます。
ただ、炬燵でごろ寝は出来ないのである意味メリハリはついてよいのかもしれませんね。
さて、AIモデルの選択肢が増えましたね。
何を使えばいいのか迷うことが多いのですが、数多あるAIモデルの中で日本語の「ニュアンス理解」や「論理的推論」においては、Anthropic Claudeは高い評価を得ています。
他にもAmazon Novaついてはコストが安く、Amazon Bedrockを利用する場合はAWS内で完結できる点を評価されることがあります。
簡単に言うと「日本語の理解度」と「コストと一貫性」で良く選びます。
今回は、この2つのモデルの内、個人的によく使うAnthropic Cloude Sonnet 3.5とAmazon Nova Proの要約性能について比較してみました。
2. 比較内容
比較には、以下の手順を踏みました。
比較対象の文章を用意する： 意図的に「会話内容をそのまま記載」「専門用語が混ざっている」「複数のトピックが入り乱れている」といった、少し難易度の高い文章を用意します。
各モデルに同じプロンプトで要約を依頼する： 「文章を要約してください。」というシンプルなプロンプトを使用します。
同条件にするため、Amazon BedrockのChat/Text playgroundでの実行を行います。
3. 検証用のテキスト文
以下の文章を使用しました。
佐藤：「来月のシステム移行ですが、やっぱり深夜作業は避けたほうがいいですかね？」 鈴木：「うーん、でも日中だとユーザーへの影響が……あ、そういえば田中さんが新しいデプロイツールを試したいって言ってましたよ。」 田中：「あ、それなんですが、まだ検証環境でバグが出ていて。でも、使えれば移行時間は半分になるはずです。」 佐藤：「半分！それは魅力。じゃあ田中さんのツールで行きましょうか。あ、でもバグがあるなら……やっぱり今回は見送りかな。あ、やっぱり鈴木さん、いつもの深夜作業で調整お願いします。」 鈴木：「了解です。あ、でもバックアップの容量足りるかな……。まあ、それは後で確認します。」
4. 比較結果
Cloude Sonnet 3.5
箇条書きですっきりしているし、結論が記載されている。 自然な人間っぽい感じに仕上がっている気がする。
この会話は、システム移行に関する打ち合わせの内容を要約したものです： 佐藤が深夜作業を避けたいと提案。 鈴木が日中作業のユーザーへの影響を懸念。 田中が新しいデプロイツールを提案。移行時間を半分に短縮できるが、まだバグがある。 佐藤は新ツールに興味を示すが、バグのリスクを考慮して従来の方法を選択。 結論として、従来通りの深夜作業で行うことを決定。 鈴木がバックアップ容量の確認の必要性を指摘。 全体として、新しい方法の検討はされたものの、安全性を重視して従来の方法が採用されました。
Amazon Nova Pro
一つの文章としてまとめている。
情報の網羅性を優先しているように見えるところが人によってはシステム的にみえるのかもしれない。
来月のシステム移行について、佐藤が深夜作業を避けるべきか尋ねた。 鈴木は日中の作業ではユーザーへの影響が懸念されると述べ、田中が新しいデプロイツールを試したいと提案したことを思い出した。 田中は、そのツールを使用すれば移行時間が半分になるが、まだバグがあると説明した。 佐藤は半分の時間は魅力的だが、バグがあるため今回は見送り、鈴木にいつもの深夜作業で調整を依頼した。鈴木は了解し、バックアップの容量が足りるかどうかは後で確認すると述べた。
4. まとめ
Claude Sonnet 3.5は、複雑な文章や会話の要約に適しており、特に日本語のニュアンスを重視する場合に有効だと思います。 対して、Amazon Nova Proはコスト効率が高く、シンプルな要約や大量のテキスト処理に向いています AIモデルでもそれぞれ違った形で出力されっるため、どちらが良い悪いではなく用途によって使い分けるべきだと思います。 その他にもコストに応じて、適切なモデルを選択することが重要です。 ちなみに実行する前に人力で要約してみたのですが、載せていないということでお察しください。
5. おまけ
Cloude Sonnet 3.5についてはAmazon Bedrockでサポートの有効期限もあるので、Cloude Sonnet 4.5を使って同じ条件で要約してみました。
Cloude Sonnet 4.5
指示は「要約してください」だけなのに、勝手に「問題点分析」や「改善アドバイス」まで踏み込んでいます。 深いところまで考えてくれるのですが、用途によっては過剰になってしまうのかもしれません。 同じモデルのCloude Sonnetでもこのあたりの検討が必要になると思います。
会議の問題点分析 この会話には、プロジェクト管理上の深刻な問題が複数含まれています。 主な問題点 1. 意思決定プロセスの欠如 場当たり的に方針が変わっている（深夜→日中？→新ツール？→やっぱり深夜） 判断基準が明確でない リスクとメリットの比較検討がされていない 2. リスク管理の不在 田中さんのツールのバグについて詳細確認なし バックアップ容量という重要事項を「後で確認」で済ませている 各選択肢のリスク評価がされていない 3. 情報共有の不足 新ツールの存在が事前に共有されていない バグの状況が不明確 移行計画の前提条件が整理されていない 4. 曖昧な結論 「了解です」で終わっているが、具体的なアクションプランがない 期限や責任者が不明確 懸念事項（バックアップ容量）が未解決のまま 改善すべきポイント ✓ 決定事項を明文化（いつ、誰が、何をするか） ✓ リスクの洗い出しと対策を先に行う ✓ 各選択肢の比較表を作成して判断 ✓ 次回ミーティングまでの宿題を明確化 ✓ クリティカルな要素（バックアップ等）は最優先で確認 このままでは移行失敗のリスクが高い状態です。
以上となります。
