「この作業、本当に全部Solが必要なのか」。重い仕事をまとめて任せ、利用上限に当たることが増えたときに考えたことです。自分でモデルを切り替えるのも手間だったので、仕事を振り分ける仕組みを作るようになりました。
いまはAstraを司令塔にし、範囲の決まった仕事をSolやTerraへ渡しています。そこへClaude Opus 5.5が出てきました。気になるのは新モデルの点数だけでなく、毎週の営業集計、重説の資料確認、部下への指示づくりのどこを任せると楽になるかです。
私の結論は、使い慣れた環境を軸に、定型処理は軽く、複数資料の照合は思考を厚くし、行き詰まった工程だけ別のモデルで試すこと。Opus・Fable・Astra・Solを全部契約し、毎回選び直す必要はありません。
- ClaudeかCodexか。その前に「使う場所」と「モデル」を分ける
- 仕事の重さは、資料の量・条件の絡み・間違えたときの影響で見る
- 重説では、一つの案件を四つの工程に分ける
- モデルを変える前に、前提をそろえる
- Claude Opus 5.5で変わった点
- ベンチマークではOpus 5.5が強い。ただしAstraが上の仕事もある
- コーディングが強いことと、普段の仕事を動かせることは違う
- 普段の仕事なら、最初に試すのは4つ
- Astra・Solの現在の運用に、OpusとFableをどう足すか
- 三つの仕事で試し、料金より「確認を含めた手間」を比べる
- モデル選びが増えたら、判定役を分ける方法もある
- 結論:全部を入れ替えず、詰まっている工程から試す
ClaudeかCodexか。その前に「使う場所」と「モデル」を分ける
Claude、Codex、Opus、Solを一列に並べると迷います。最初に決めるのは、資料を渡して答えをもらう仕事か、ファイルや画面を実際に操作してもらう仕事かです。
| 選ぶもの | 例 | 最初に確認すること |
|---|---|---|
| 作業するサービス・ツール | ChatGPT、Claudeのチャット、Claude Code、Codex | 必要な資料・ファイル・操作先に接続できるか |
| 中で使うモデル | Astra、Sol、Opus、Fable | その工程で、根拠のある回答と完成物を出せるか |
| 思考の設定 | 中・高など、各画面で選べる設定 | 速さを優先するか、条件の検討に時間を使うか |
同じモデルでも、資料を読むだけのチャットと、実行権限のある作業環境では任せられる範囲が変わります。モデル名を変えても、社内ツールへの接続やログイン権限が増えるわけではありません。
OpenAIの公式説明でも、思考設定は考える量を調整するもので、対応する設定はモデルごとに異なります。「高」は正解の認定ではなく、検討に使う時間やトークンを増やす選択です。
仕事の重さは、資料の量・条件の絡み・間違えたときの影響で見る
短い依頼でも判断が重い仕事があります。反対に、数百行あってもルールどおりに足すだけなら、計算式やスクリプトで処理できます。私は作業量だけでなく、条件がいくつ絡むか、答えを何と照合できるかで担当を決める方が運用しやすいと考えています。
| 仕事 | 最初に試す担当・設定 | 設定やモデルを上げる目安 |
|---|---|---|
| 業者への定型メール、決まった書式への整形 | 使い慣れたモデルの中程度。定型化できればTerraなども候補 | 事実を足す、書式を外す、修正が繰り返される |
| 重説資料の場所探し、日付・面積・金額の抽出 | 普段の資料読解環境。Opus・Solは比較候補 | 参照ページがずれる、同名項目を取り違える |
| 重説と契約書など複数資料の照合 | 普段のモデルの高設定を試す。Opus・Solで同じ資料を比較 | 資料間の矛盾や前提変更を拾えない |
| 接道・私道・借地など複数条件の論点整理 | AstraやFableを追加比較する候補にする | 一次回答では条件の関係や未確認点が整理できない |
| 営業集計 | 件数の定義と例外処理をAIで整理し、計算は表計算・スクリプト | 月またぎ、担当変更、重複のルールが未整理 |
| 転記・集計の自動化 | 接続できるClaude CodeやCodexなどで、設計と実装を分ける | 一つ直すと別の工程が壊れる、完成までつながらない |
この表は、同じ仕事で試すための出発点です。Opus・高なら重説は合格、Fableなら法令の見落としがない、という判定には使いません。金額・権利・法令に関わる記載は、モデルに関係なく根拠を確認して採用します。
重説では、一つの案件を四つの工程に分ける
私が実際に行っているのは、登記事項証明書、公図、地積測量図、都市計画図、契約書類などを先に読ませ、入力欄のスクリーンショットを渡す使い方です。「これを埋めて」で候補を出してもらい、確認してコピーします。いま自動化したいのは、このスクリーンショットと転記の繰り返しです。
| 工程 | AIへ頼むこと | 次へ進む条件 |
|---|---|---|
| 1. 探す・抜き出す | 記載候補と、書類名・ページ・原文を出す | 原資料の該当箇所と一致する |
| 2. 照合する | 資料Aと資料Bの値、食い違い、未記載項目を並べる | 空欄を推測で埋めず、不一致を残している |
| 3. 論点を整理する | 条件同士の関係、確認すべき事項、問い合わせ先を整理する | 根拠と未確認点を区別できている |
| 4. 採用して記載する | 確認用の一覧を人へ渡す | 本人が原資料や所管窓口で確認し、記載を決める |
条例については、単に「該当しますか」と聞くより、景観条例、まちづくり条例、中高層建築物に関する条例など、何を調べたいかを具体的に伝えています。ハザードマップも、何に基づく資料かまで調べさせます。AIが用意した候補を見て、心配な項目は市役所へ電話して確認することもあります。
「新人に任せられる物件か」だけではモデルを選びません。一見普通のマンションでも、資料の食い違いがあれば照合に手間がかかります。物件の名前より、いま頼む工程の難しさで切り替えます。
モデルを変える前に、前提をそろえる
普段、業者宛てのメールは六割くらいの雰囲気で書いて、会社名や宛名、文章の形を整えてもらうことがあります。仕事の前提と形式が決まっているので、毎回細かい指示を書かなくても進めやすいのです。雑な指示で回るのは、伝える必要がある前提が先に共有されているからです。
まず資料の不足を埋め、完成形と禁止事項を決めます。それでも条件を落とすなら思考設定を上げる。まだ解けない部分が残るなら、根拠資料と未解決点をまとめて別モデルへ渡す。この順番なら、モデル選びだけで仕事が止まりにくくなります。
切り替えるときには「目的/使用資料/確定事項/未確認事項/出してほしい形」の五つを渡します。前のAIの回答だけを根拠にすると、間違いも一緒に引き継ぐので、元資料への参照を残します。
Claude Opus 5.5で変わった点
| 項目 | Claude Opus 5.5 | 仕事で見る意味 |
|---|---|---|
| 公開日 | 2026年9月22日 | 発売直後のため本人実測と長期評価はこれから |
| コンテキスト | 100万トークン | 複数資料や長い作業履歴をまとめて扱う候補 |
| 最大出力 | 12.8万トークン | 長い成果物も作れるが、必要な長さに絞る指示は残す |
| API標準料金 | 入力100万トークン4ドル、出力20ドル | Opus 5の5ドル・25ドルから20%低下 |
| キャッシュ読取 | 100万トークン0.20ドル | 長い作業を同じ文脈で続ける費用を抑えやすい |
| 思考 | 適応型思考が常時有効、標準effortはmedium | 単純作業にも思考を使うため担当分けが必要 |
Anthropicは、Opus 5.5の典型的な作業費用がOpus 5より40%低く、出力は30%以上速いと説明しています。これはAPI単価だけの比較ではありません。少ない手順やトークンで仕事を終えられるという同社の評価を含みます。自分の仕事でも40%下がるという約束ではないため、実際の作業単位で測る必要があります。
ベンチマークではOpus 5.5が強い。ただしAstraが上の仕事もある
| 公式掲載の評価 | Opus 5.5 | GPT-6 Astra | GPT-5.6 Sol |
|---|---|---|---|
| Terminal-Bench 4.0 | 66.4% | 57.9% | 37.3% |
| FrontierCode v1.1 | 54.4% | 53.3% | 47.5% |
| GDPval-AA v2.1 | 1846 | 1542 | 1588 |
| AutomationBench | 40.0% | 41.4% | 28.8% |
| Terminal-Bench-Science | 58.7% | 64.6% | 22.4% |
この表だけで「Opus 5.5がAstraより上」とは決められません。長いコーディングや知識作業ではOpus 5.5が高い一方、業務自動化と科学系の評価ではAstraが上です。さらに、努力量、実行環境、ツール、保護機構がそろっていません。Anthropic自身も、上位モデル同士ではベンチマークの小差が実務差を表しにくくなったと説明しています。
だから私は、モデル名で全仕事を入れ替えません。現在の仕事でどこに詰まりがあるかを見て、その工程だけを比較します。
コーディングが強いことと、普段の仕事を動かせることは違う
日常の仕事では、コードを書けるだけでは足りません。ブラウザを開く、画面の場所を見つける、設定を変更する、ファイルを保存する、別のツールへ移動する。その途中で表示が変わったら判断し直す必要があります。ここはコーディング能力より、パソコン操作と業務の流れを保つ能力が効きます。
| 能力 | できること | 普段の仕事での例 | 見落としやすい条件 |
|---|---|---|---|
| コーディング | コードを読み、修正し、テストする | 集計ツール、転記補助、定期処理を作る | 社内データへ接続できるとは限らない |
| パソコン操作 | 画面を見てクリック、入力、保存、設定変更を進める | 管理画面からCSVを出す、項目を設定する | 画面への接続、権限、確認手順が必要 |
| 知識作業 | 資料を読み、比較し、矛盾や不足を整理する | 契約書類の照合、指示の整理、報告書作成 | 元資料が正しいか、最新かの確認が必要 |
| 業務遂行 | 複数の操作と判断をつなぎ、完成条件まで進める | 問い合わせから成約までの集計を完成させる | 社内の定義、例外処理、承認者が必要 |
Anthropicの公開表では、Opus 5.5はコーディングだけでなく、パソコン操作を測るOSWorld 2.0で81.8%、複数アプリの業務を測るAutomationBenchで40.0%とされています。ただし、ベンチマーク上で画面を操作できても、私のパソコンや社内ツールへ自動で入れるわけではありません。実際には、操作できる環境、ログイン権限、利用を許可されたデータ、失敗時に戻せる手順が必要です。
設定を進めてもらうときは、「この画面を開いて」だけでは不十分です。どこまで変更してよいか、成功した状態は何か、途中で確認が必要な操作は何か、元へ戻す方法はあるかまで決めます。メール送信、顧客データの変更、公開、削除、支払いは、画面操作ができても本人確認を残します。
普段の仕事なら、最初に試すのは4つ
1. 問い合わせから成約までの営業集計
私が毎週・毎月まとめるのは、問い合わせ数だけではありません。連絡が取れた件数、案内数、成約数、広告費、売上までつなぎます。情報が複数の画面に分かれ、案内の分類にも少し揺れがあります。この仕事で難しいのは足し算ではなく、「何を1件と数えるか」を最後まで同じ定義で使うことです。
Opus 5.5には、匿名にした同じCSVと同じ定義表を渡し、集計、例外行の抽出、率の計算、前月との差の説明までを1つの仕事として試します。合計だけ合っていても、担当変更や月またぎを落としていれば不合格です。完成値は既存集計と照合し、私が確定します。
2. 複数書類の照合と入力候補
不動産の書類確認では、登記事項証明書、公図、地積測量図、都市計画図、契約書類などを先に読ませ、入力欄のスクリーンショットを渡して候補を作らせます。資料が増えるほど、どこに書いてあったかを探す時間は減らせます。Opus 5.5の100万トークンは、このような複数資料の仕事を比較する理由になります。
ただし、条例が該当するか、ハザード情報が水防法に基づくか、重要な記載が正しいかは別です。根拠URLと該当箇所を出させ、法的な資料を確認し、心配な項目は市役所などの窓口へ確認します。長く読めることと、最終判断を任せられることは同じではありません。
3. 上司の指示と部下への指示を整理する
上司から来た長い指示は、目的、期限、担当、確認が必要な点に分けます。部下へ渡す前には、抜けている条件、曖昧な言葉、相手が判断できない箇所を探させます。ここで欲しいのは丁寧な文章ではなく、仕事が止まる原因の発見です。
普段の仕事では、前提が共有されていれば「これを3つに分けて」「今日やる順にして」のような短い指示でも回ります。Opus 5.5を試すなら、長い会話を一度きれいに要約する課題より、過去の決定と今日の変更を区別し、未確認事項を残せるかを見ます。相手に送る文章は私が読み、分からないことは送りません。
4. 小さな業務ツールを最後まで作る
複数画面から数字を拾い、決まった表へ入れる作業は、最終的にはスクリーンショットとコピーを繰り返さない形にしたいと考えています。ここではモデルの文章力より、既存コードを読み、複数ファイルを直し、テストし、何を変えたか報告できるかが重要です。AnthropicがOpus 5.5の強みとして挙げる長時間のエージェント型コーディングと最も重なります。
Astra・Solの現在の運用に、OpusとFableをどう足すか
現在のAstraを軸にした運用は残します。難しい設計と全体の確認をAstra、範囲の決まった実装をSol、抽出・分類などをTerraへ振る。その上で、同じ書類照合や小さな自動化をOpus 5.5でも試し、人の手直しが減る工程があれば担当を変えます。
Fableは、普段の担当では条件をまとめきれない調査や、長く複数工程にまたがる仕事で追加比較する候補です。AnthropicもFableを長時間・複数アプリの仕事や複雑な知識作業向けに説明しています。重説の正答率を保証する根拠としてではなく、難しい工程で試す理由として使います。
Claudeを中心に使っている人なら、まずその環境で資料確認や文章作成を整えればよいと思います。自動化まで進めたいときに、Claude CodeやCodexで実際に必要なファイルと操作先を扱えるかを確かめる。両方契約するかは、その比較で手直しや作業時間が減ることを確かめてからです。
三つの仕事で試し、料金より「確認を含めた手間」を比べる
最初は、普段の仕事、資料が食い違う仕事、条件が途中で増える仕事を一つずつ選びます。同じ匿名資料と指示を渡し、正誤、根拠ページの一致、見落とし、人が直した回数、終わるまでの時間を記録します。三例は最初の比較用であり、三回合ったから以後の確認を外すという意味ではありません。
APIなら実際の利用料、月額契約なら追加契約の必要性と利用上限への影響も見ます。安い回答を何度も直すなら、その手間も費用です。高いモデルへ一度で任せた方が楽な工程と、軽い処理で済む工程を分けます。
モデル選びが増えたら、判定役を分ける方法もある
仕事を分ける基準が固まると、今度はその振り分け自体を自動化する選択肢が出てきます。TypeSafeのJevは、用件や作業を決めた選択肢へ分類するための判定モデルです。AstraやOpusに仕事を任せる前段へ組み込む構成が考えられます。ただし、実行モデルを呼ぶ連携は別に必要です。少数の仕事なら手動や固定ルールを先に整え、同じ分類が繰り返し発生する場合に、Jevを試す価値があります。 Jev公式仕様
結論:全部を入れ替えず、詰まっている工程から試す
Opus 5.5を試すなら、いま何度も修正している書類照合か、途中で止まっている小さな自動化から始めます。定型処理は軽く回し、難しい論点だけ思考設定やモデルを上げる。根拠が足りない問題は、モデルを変える前に資料や確認先を増やします。
仕事を渡す範囲は広げても、相手へ送るのは私です。分からないことは送らない。モデルを切り替える基準は、名前や評判より、自分が内容を確認しやすくなったかです。
よくある質問
Q. 重説ならOpus・高で十分ですか?
資料の抽出・照合を試す候補にできますが、設定だけで合格にはしません。記載候補に書類名・ページ・原文を添えさせ、金額や法令に関わる採用判断は本人が原資料等で確認します。
Q. Claude、Codex、Opus、Astraはどう選びますか?
先に資料を読む仕事か、ファイルや画面を操作する仕事かを決めます。作業できる環境を選び、その中で利用可能なモデルと思考設定を試します。
Q. Fableへ切り替える目安は?
前提と資料をそろえても複数条件を整理できないときや、長い作業が途中で崩れるときに比較します。元資料と未確認点を渡し、前のAIの結論だけを引き継がないようにします。
