はじめに
こんにちは。愛猫リンゴちゃん大好きなローです。
最近社内で Claude のコスト最適化が話題となりましたので週報作成で比較検証してみました。 対象となるモデルは下記になります。
- Opus 4.6
- Sonnet 4.6（1M）
- Sonnet 4.6（200k）
- Haiku 4.5
結論
4 つの判断軸（コスト、処理時間、出力の質、コンテキストウィンドウ）でモデルを選別しましょう。
| モデル（コンテキストウィンドウ ※1、※5） | コスト ※2 | 処理時間 ※3 | 出力の質 ※4 |
|---|---|---|---|
| Opus 4.6（1M） | × | △ | ◎ |
| Sonnet 4.6（1M） | ○ | ○ | ○ |
| Sonnet 4.6（200k） | ○ | ○ | ○ |
| Haiku 4.5（200k） | ◎ | ◎ | △⇔× |
※1 Haiku 4.5 のみ、MCP ツールをセッション開始時に全部読み込むため、コンテキストウィンドウが圧迫しやすい
比較基準
※2【コスト】同じタスクを人間がした場合にかかる費用より低いか
※3【処理時間】同じタスクを人間がした場合にかかる時間より少ないか
※4【出力の質】ベースラインを満たせるか
※5【コンテキストウィンドウ】タスク遂行するのに十分か
検証詳細
前提
- Claude.ai のコネクタで Slack、Google Calendar 連携済み
- Claude Code で検証実施
- Claude Enterprise プラン契約
- 利用料は Claude デスクトップアプリ「設定 ⇒ 使用料」で確認
- 多少のプロンプトエンジニアリング手法
手順
1. Claude デスクトップアプリで**作業前**の利用料確認 2. プロンプトで作業開始させる 3. 作成された週報に「Yes」と承認する 4. `/context` のスラッシュコマンドで `Messages` のコンテキスト量を確認 5. Claude デスクトップアプリで**作業後**の利用料確認
プロンプト
ローの先週（2026/04/07~2026/04/11）分の週報を作成してください。 上長に自分の稼働状況を共有する目的となりますため、簡素的に各案件/プリセールス状況を伝えるくらいの内容で十分となります。 claude.aiコネクタを利用してslackとgoogle calendarのみアクティビティを収集してください。 フォーマットは/home/law/weekly_report/format.mdを参考にしてください。 週報は<本プロンプトから週報作成できたまでにかかった時間>_weekly_report.mdとして新規ファイルを作成してください。
比較結果
| モデル | コスト※1 | 処理時間 ※2 | メッセージトークン数 | 備考 |
|---|---|---|---|---|
| Opus 4.6（1M） | 1.85ドル（295.38円） | 5分30秒 | 68.1k | 1回目 |
| Opus 4.6（1M） | 1.77ドル（282.61円） | 3分37秒 | 34.4k | 2回目 |
| Sonnet 4.6（1M） | 0.59ドル（94.20円） | 3分20秒 | 37k | 1回目 |
| Sonnet 4.6（1M） | 0.38ドル（60.67円） | 3分13秒 | 43.4k | 2回目 |
| Sonnet 4.6（200k） | 0.37ドル（59.08円） | 1分21秒 | 44.2k | 1回目 |
| Sonnet 4.6（200k） | 0.8ドル（127.73円） | 4分58秒 | 62.6k | 2回目 |
| Haiku 4.5（200k） | 0.13ドル（20.76円） | 32秒 | 49.5k | 1回目 |
| Haiku 4.5（200k） | 0.12ドル（19.16円） | 30秒以内 | 49.3k | 2回目 |
※1 2026/04/13 時点 159.63円/ドル換算
※2 プロンプト送信から週報作成完了するまでのセッション時間
その他見受けられた点
- プロンプトエンジニアリング手法をかけてみた結果、0.29ドル（46.29円、2026/04/13 時点 159.63円/ドル換算）安くなりました。
- thinking は処理時間を大幅に増加させてしまう
- Sonnet 4.6（1M）は、Slack MCP Server の出力に対して Python をいくつ作成して処理していた
- Haiku 4.5 以外、すべてのモデルはサブエージェント（subagent）機能を利用していた
- ファイル名に処理時間を各モデルに計算させてますが、Sonnet 4.6（1M）だけは計算せずにうそをついてた
考察
検証の結果、モデル選択は単純な「高い＝良い」ではなく、タスクの要求水準に応じた使い分けが重要であることがわかりました。
コスト効率
Haiku 4.5 は Opus 4.6 の約 1/15 のコストで週報を生成できますが、後述する精度面で大きな課題があります。
Sonnet 4.6 は 1M・200k ともに 0.37〜0.80 ドルの範囲で安定しており、コストパフォーマンスに優れています。
処理時間
Haiku 4.5 の 30 秒前後は圧倒的ですが、情報収集の深さを犠牲にしています。
Opus 4.6 は thinking（拡張思考）に時間を費やす傾向があり、同じ情報量でも Sonnet より処理時間が長くなります。
再現性
同一モデル・同一プロンプトでも、実行ごとに情報収集量・出力品質が大きく変動するケースがありました。
特に Opus 4.6 は 1 回目に Slack を 6 ページ分検索したのに対し、2 回目は 1 ページのみで切り上げており、結果の品質にも直結しました。
「同じプロンプトを投げれば同じ品質の出力が返ってくる」とは限らない点は注意が必要です。
プロンプトエンジニアリングの効果
V1 プロンプト（Slack チャンネル指定あり）から V2（指定なし）への調整で 0.29 ドルのコスト削減を確認しました。
情報ソースの指定粒度がコストに直結するため、プロンプトの工夫だけで実用的なコスト削減が可能です。
ユースケース別の推奨
| 重視する軸 | 推奨モデル | 備考 |
|---|---|---|
| 精度・網羅性 | Opus 4.6 / Sonnet 4.6（1M） | 上長への提出をそのまま任せたい場合 |
| コスト・速度 | Haiku 4.5 | 人間レビュー前提。出力内容の検証は必須 |
| バランス | Sonnet 4.6（200k） | コストを抑えつつそこそこの品質を求める場合 |
週報の精度とモデル別特徴
コスト・処理時間の定量比較だけでなく、各モデルが生成した週報の中身の正確性をセッションログから精査しました。
情報収集手段の比較
各モデルがどのようにアクティビティ情報を収集したかを比較します。
| モデル | Slack API | Slack 検索回数 | ページネーション | サブエージェント | Calendar 取得上限 |
|---|---|---|---|---|---|
| Opus 4.6（1 回目） | public_and_private |
6 回 | ○ | ○ | 250 |
| Opus 4.6（2 回目） | public_and_private |
1 回 | × | ○（model=sonnet 指定） | 100 |
| Sonnet 4.6（1M） | public_and_private |
2〜4 回 | △ | ○ | 30〜100 |
| Sonnet 4.6（200k） | public_and_private |
2〜4 回 | × | △（2 回目のみ） | 50〜100 |
| Haiku 4.5 | public のみ |
1 回 | × | × | 50〜100 |
最も大きな差は Haiku 4.5 が
slack_search_publicを使用した点です。 他のモデルは全てslack_search_public_and_privateを使用しており、プライベートチャンネル（プロジェクトチャンネル等）の情報も取得できていました。 Haiku はプライベートチャンネルの情報を一切取得できておらず、プロジェクト固有の活動内容が大幅に欠落しています。
週報の網羅性
情報収集量と週報の粒度には明確な正の相関が見られました。
- Slack の検索回数が多く、ページネーションを活用したモデルほど、最終的な週報に含まれる案件数・トピック数が増加
- Opus 4.6 の 1 回目は最大 6 ページ分（約 100 件）の Slack メッセージを取得し、全モデル中最も多くの案件・トピックをカバー
- Sonnet 4.6（1M）はトピック別検索（特定の案件名やキーワードで追加検索）により、特定分野の深掘りに強みを発揮
- Haiku 4.5 は Slack 検索 1 回（20 件）かつパブリックチャンネルのみのため、プロジェクト固有の活動が週報に反映されず、不足分は汎用的・抽象的な表現で補完
また、同一モデルであっても 1 回目と 2 回目で情報収集量が大きく異なるケースがあり、収集量が少ない回は当然ながら網羅性も低下しています。
情報収集の徹底度がそのまま週報の品質に直結する、という点はどのモデルにも共通する傾向です。
正確性の問題点
セッションログを精査した結果、以下の 3 つの正確性に関する問題が確認されました。
1. Haiku 4.5：情報ソースの制限による内容の空洞化
Haiku 4.5 は slack_search_public のみを使用しており、プライベートチャンネルのメッセージを一切取得していません。
その結果、生成 AI トピック等のセクションで具体的なニュースや技術的な議論ではなく、
- 「〇〇について検討」
- 「〇〇の活用ユースケースについて検討」
のような汎用的な表現で情報を補完する傾向が見られました。 これらは Slack のパブリックチャンネルの断片的な情報から推測された内容であり、実際の活動を正確に反映しているとは言い難い状態です。
2. Sonnet 4.6（1M）：処理時間の捏造
3 回の実行すべてで、ファイル名に含める処理時間を実測ではなく推定で記載していました。
| 実行 | 実際の処理時間 | モデルの自己申告 | 乖離 |
|---|---|---|---|
| 1 回目 | 約 3 分 20 秒 | 2m44s | 0.6 倍（過小申告） |
| 2 回目 | 約 3 分 13 秒 | 約 5 分 | 1.6 倍（過大申告） |
| 3 回目 | 約 2 分 4 秒 | 5min | 2.4 倍（過大申告） |
date コマンドでタイムスタンプを取得しているにもかかわらず、差分を正確に計算せず丸めた数値を申告しています。
モデルが自身の処理時間を正確に認識する能力には限界があることを示しています。
3. 同一モデルの実行間バラつき
Opus 4.6 の 2 回の実行で、情報収集のアプローチが大きく異なりました。
| 1 回目 | 2 回目 | |
|---|---|---|
| Slack 検索回数 | 6 回（ページネーション） | 1 回のみ |
| 取得メッセージ数 | 約 100 件 | 20 件（特定日のみ） |
| 週報の情報量 | 幅広い案件をカバー | カレンダー依存、Slack 情報が欠落 |
同一プロンプトでも再現性が保証されない点は、業務利用における課題の一つです。
モデル別の週報作成特徴
各モデルの「性格」をセッションログから読み取りました。
Opus 4.6 — 最高品質だが再現性に課題
情報収集を徹底する場合は全モデル中最も網羅的な週報を生成します。 Slack のページネーションを最大 6 ページ分実行し、CVE 番号や具体的な人名、技術的な意思決定の経緯まで拾い上げる精度を見せました。
一方で 2 回目の実行では Slack 検索を 1 回で切り上げるなど、実行ごとの「やる気」に大きな差がありました。
サブエージェントに model=sonnet を明示指定してコストを抑える振る舞いも確認され、コスト意識を持ったモデルであることがうかがえます。
Sonnet 4.6（1M）— トピック別検索による深掘り型
全実行でサブエージェントを活用し、Slack の大量データを構造化処理していました。
特徴的なのは、from:me での全文検索に加えて特定のキーワード（案件名や技術用語）で追加の Slack 検索を行うトピック別検索戦略です。
これにより全文検索だけでは埋もれがちな情報を効率的に拾い上げており、網羅性と処理速度のバランスに優れています。
ただし処理時間の自己申告が不正確な点は改善の余地があります。
Sonnet 4.6（200k）— 実行ごとのアプローチ変動が顕著
| 1 回目 | 2 回目 | |
|---|---|---|
| サブエージェント | 不使用 | 使用 |
| Slack 検索回数 | 2 回 | 4 回 |
| 実測処理時間 | 81 秒 | 約 5 分 |
| コスト | 0.37 ドル | 0.80 ドル |
同一プロンプトに対するアプローチの振れ幅が全モデル中最も大きい結果となりました。 コストや処理時間を安定させたい場合は注意が必要です。 コンテキストウィンドウ（200k）の制約が情報収集戦略の選択に影響している可能性があります。
Haiku 4.5 — 最速最安だがツール選択に致命的な問題
30 秒以内で週報を生成する圧倒的な速度が最大の強みですが、slack_search_public のみを使用しておりプライベートチャンネルの情報が全て欠落しています。
ツールの選定、利用方法について説明でガードレールを引いてあげないと結果にバラつきが大きくなります。
処理フローも他モデルとは大きく異なります。
Read（フォーマット確認）→ Slack/Calendar 取得 → Write
サブエージェントも中間処理も使わない最短 3 ステップで完了します。 情報が不足する箇所は汎用的な表現で補完する傾向があり、週報としての信頼性に課題があります。 MCP ツール定義の読み込みだけでコンテキストウィンドウ（200k）が圧迫されやすい点も、情報収集の浅さに影響している可能性があります。
まとめ
週報作成を通して Claude ファミリーの各モデルについて比較検証してみました。
遂行させるタスクの特性によってモデルを「コスト、処理速度、出力の質、コンテキストウィンドウ」の 4 軸で評価してみてはいかがでしょうか。
今回はワンショット・プロンプトタスクを依頼しているため、ほぼすべての判断はモデルに委ねました。 そのため、週報の内容や調査手法から見たらモデル別の差が顕在化しました。 Skill にした場合は情報収集の判断を事前に決められることができ、モデルに判断を任せる場面を減らせます。 そのため、Haiku 4.5 におけるさらなる精度向上を見込めるため次回試してみます。
このブログがどなたかの役に立てればうれしいです。
ロータッヘイ(執筆記事の一覧)
24卒入社の香港人です。
2025 Japan All AWS Certifications Engineers
リンゴちゃん（デボンレックス）にいつも癒されています。
