GPT-5.6とは、Sol・Terra・Lunaの3階層で構成されるモデル群のことです。

事務所で使う生成AIのモデルを、何を根拠に決めているでしょうか。GPT-5.6は上位から順にSol、Terra、Lunaという3つの階層に分かれており、価格差が大きい一方で、業務によっては下位モデルで足りる場面と、はっきり足りない場面が分かれます。この記事では、公開されているベンチマークと価格情報をもとに、事務所の業務を類型に割ってモデルを当てる手順と、守秘義務まわりで確認しておく設定を整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、モデルの仕様はベンダーの公式発表で確認しています。

GPT-5.6の3階層構成と、士業事務所が見るべき数字

OpenAIは2026年7月9日、GPT-5.6のモデル群を一般提供として公開しました。同社の公表によれば、構成はフラッグシップのSol、日常業務向けのバランス型であるTerra、もっとも低コストなLunaの3つで、番号が世代を、名前が能力の階層を表す設計とされています。

士業事務所にとって重要な数字は、話題になりやすいコーディング性能ではありません。長い文書を読み違えないか、専門的な作業を最後まで走りきれるか、そして一か月あたりいくらかかるか、この三つです。

長文の読み取りについては、同社の公表資料にあるOpenAI MRCR v2という長文脈評価が参考になります。256Kから512Kトークンの範囲で8か所の情報を拾う設定では、Solが91.5%、Terraが89.6%であるのに対し、Lunaは41.3%と大きく落ち込みます。前世代のGPT-5.5は81.5%でした。この差は、契約書一式や過去数年分の議事録、判例集のようなまとまった資料を丸ごと読ませる用途で、そのまま結果の差になって表れる性質のものです。逆にいえば、短い文書を扱うだけならLunaで足りる場面が多いということでもあります。

専門的な業務を長く走らせる力については、同じ公表資料のAgents’ Last Examという評価が、55分野の長時間ワークフローを対象にしています。Solが52.7%、Terraが50.4%、Lunaが50.3%、GPT-5.5が46.9%と並んでおり、上位と下位の差は長文脈ほど大きくありません。つまり、短い作業を数多く回す用途では、階層による差は思ったほど開かないという読み方ができます。

価格は1Mトークンあたりで示されており、公表資料によればSolが入力5ドル・出力30ドル、Terraが入力2.5ドル・出力15ドル、Lunaが入力1ドル・出力6ドルです。同ページには2026年7月30日にLunaを80%、Terraを20%値下げしたという注記も付されているため、実際に請求される単価は公式の料金ページで確認する必要があります。この点は要確認として扱ってください。

キャッシュの扱いも実務では効きます。同社の公表資料によれば、GPT-5.6以降はプロンプトキャッシュの最低保持時間が30分に設定され、キャッシュ読み出しには入力単価の90%割引が適用されます。事務所で同じ規程や同じ雛形を毎回冒頭に置くような使い方をしている場合、この割引が月額に効いてきます。

法務分野での実感としては、同ページに掲載されたLegoraのコメントとして、内部評価の7タスク中5タスクで改善または横ばいであり、法的な結論については慎重さを保っていたという趣旨の評価が紹介されています。慎重さを保つという性質は、士業の実務では長所として読める部分です。

事務所の業務を4類型に割ってモデルを当てる手順

モデル選定を、どれが一番賢いかという問いで始めると答えが出ません。業務を類型に割り、類型ごとに要求水準を決めてから当てはめる順序にします。以下は五つの手順です。

第一に、事務所の業務を4類型に割ります。類型Aは長文読解型で、契約書のレビュー、過去資料の横断検索、判例や通達の突き合わせが入ります。類型Bは定型生成型で、案内文、議事録の整形、チェックリストの作成が入ります。類型Cは調査型で、制度の変更点を追う、複数の資料を突き合わせて論点を洗い出す作業です。類型Dは対話型で、思考の壁打ちや構成の相談が入ります。

第二に、類型ごとに許容できない失敗を言語化します。類型Aで許容できないのは、資料の一部を読み飛ばしたまま結論を出すことです。類型Bで許容できないのは、事務所の文体や用語から外れることです。類型Cで許容できないのは、存在しない条番号や制度名を出力することです。類型Dは、そもそも出力をそのまま使わないため、許容範囲が広くなります。

第三に、許容できない失敗から逆算してモデルを割り当てます。類型Aは長文脈の性能差が直結するため上位階層を、類型Bと類型Dは下位階層でも実用に耐えることが多いため低コスト側を、類型Cは出力の検証を前提に中位を当てる、という組み方が起点になります。ここは事務所の扱う文書量によって動くので、次の手順で自前の検証にかけます。

第四に、自事務所の実データで比較検証を行います。ベンダーの公表するベンチマークは一般的な水準を示すもので、事務所ごとの文書の癖までは反映しません。過去に処理済みで正解が確定している案件を十件ほど選び、同じ入力を各階層に投げて、出力を突き合わせます。ここで比べるのは文章の巧拙ではなく、事実の取りこぼしと誤りの有無です。

第五に、検証結果を根拠として記録に残し、モデル割り当てを事務所規程の別表として管理します。モデルは短い周期で更新されるため、割り当ての根拠が残っていないと、次の世代が出たときに同じ検証をやり直すことになります。

検証の入口として使えるプロンプトが次のものです。正解が確定している案件の入力と、確定した論点リストを用意して使います。

あなたは文書読解の精度を検証するための回答者です。
以下の資料群を読み、質問に回答してください。

回答の形式:
- 各質問に対し、結論を1文で述べる
- 結論の根拠となった箇所を、資料名とページまたは条番号で示す
- 資料から判断できない場合は「資料からは判断できません」と回答する

制約:
- 資料に書かれていない事実を補完しないでください
- 一般論や推測で埋めず、資料の記述のみを根拠にしてください
- 条番号や制度名は、資料に書かれている表記のまま転記してください

【資料群】
（ここに貼り付け）

【質問】
（ここに貼り付け）

出力を人が突き合わせるのは手間がかかるため、比較そのものを補助させる使い方もできます。次のプロンプトは、階層違いの出力を並べて差分を洗い出すものです。

あなたは出力比較のレビュー担当です。
同じ入力に対する2つの回答を比較し、次の観点で差分だけを列挙してください。

観点:
1. 事実として述べている内容が食い違っている箇所
2. 一方にしか出てこない固有名詞・条番号・数値
3. 一方が「判断できない」と答え、他方が断定している箇所
4. 根拠として挙げている資料箇所が異なる箇所

制約:
- どちらが優れているかの総合評価は書かないでください
- 差分の指摘のみを行い、正解の判定はしないでください

【回答A】
（ここに貼り付け）

【回答B】
（ここに貼り付け）

この手順で組むと、モデルが更新されたときの入れ替え判断が軽くなります。検証セットが手元にあるので、新しい階層が出たら同じ十件を流し直すだけで済みます。モデル世代ごとの使い分けの考え方は、GPTモデルの士業業務での使い分けとClaude最新モデルの士業での使い分けでも整理しています。

なお、どの階層を使う場合でも、出力を成果物として外に出す前の確認は有資格者が行う工程として固定します。長文脈の性能が上がったことは、読み飛ばしが減ったことを意味しますが、ゼロになったことを意味するわけではありません。

Zero Data Retentionと守秘義務、事務所規程に落とす論点

モデルの精度と同じかそれ以上に、士業事務所が確認すべきなのはデータの取り扱いです。守秘義務の根拠は職種ごとに条文が分かれており、いずれもe-Gov法令検索で原文を確認できます。

弁護士については弁護士法第23条が、弁護士または弁護士であった者は、その職務上知り得た秘密を保持する権利を有し、義務を負うと定めています。税理士については税理士法第38条が、正当な理由がなくて税理士業務に関して知り得た秘密を他に洩らし、または窃用してはならないと定めています。公認会計士については公認会計士法第27条、社会保険労務士については社会保険労務士法第21条、行政書士については行政書士法第12条に、それぞれ同趣旨の規定が置かれています。表現は少しずつ異なりますが、事務所として押さえるべき構造は共通しています。

そのうえで確認したいのが、データ保持の設定です。OpenAIの公表資料によれば、Responses APIのProgrammatic Tool Callingは、モデルがメモリ上でプログラムを実行してツールを協調させる仕組みで、Zero Data Retentionに対応するとされています。API経由で組む場合、この設定が使えるかどうかは、事務所がベンダー側にどれだけデータを残すかという設計そのものに関わります。ただし、この仕組みが使えるのはAPI利用の場合であり、通常のチャット画面から使う場合は契約プランごとの扱いが別に定められています。どちらの経路で使うのかを決めないまま設定の話をしても噛み合いません。

事務所規程に落とすときの論点は四つです。一つ目は、経路の指定です。チャット画面から使うのか、API経由の自前環境から使うのかを業務類型ごとに決めます。二つ目は、階層ごとの入力可否です。低コスト階層を検証用途で使う場合、顧客の実データを入れるのか、加工したデータを入れるのかを分けます。三つ目は、確認日の記録です。ベンダーの方針は改定されるため、いつ時点の仕様に基づく運用なのかを残します。四つ目は、顧客への説明です。個人情報保護委員会も生成AIサービスの利用に関する注意喚起を公表しており、入力した情報がどう扱われるかを利用者側が把握しておくという発想は、事務所の説明責任と同じ方向を向いています。

法人向けプランと個人向けプランで学習利用の扱いが異なる点については、生成AIの法人プランと学習利用の比較で整理しています。外部に一切出したくない業務がある場合の選択肢は、士業事務所でのローカルLLM運用を参照してください。

モデル選定でつまずく失敗パターン

一つ目は、最上位階層だけを全業務に当てる失敗です。安全側に倒したつもりでも、月額が膨らんで利用が抑制され、結局誰も使わなくなります。長文脈を要求しない業務まで上位に寄せる必要はありません。

二つ目は、逆に最下位階層だけで通そうとする失敗です。長文脈の評価で階層差が大きく開くことは前述のとおりで、契約書一式を読ませる用途で下位に寄せると、読み飛ばしが起きやすくなります。安いからという理由だけで割り当てを決めると、確認工数のほうが増えます。

三つ目は、ベンチマークの数字をそのまま自事務所の期待値にしてしまう失敗です。公表される評価は一般的な課題で測ったものであり、日本語の専門文書、事務所固有の書式、顧客業界の用語といった条件は含まれていません。自前の検証セットを持たないまま数字を信じると、期待と実際がずれます。

四つ目は、モデルが更新されたときに何も見直さない失敗です。階層の名前が同じでも、世代が変われば性能も価格も動きます。更新の告知を追う担当を決め、検証セットを流し直す運用にしておくと、入れ替えの判断が属人化しません。

月額コストの試算と検証体制

試算の考え方は単純です。業務類型ごとの月間処理量をトークンに換算し、階層ごとの単価を掛けて足し合わせます。長文読解型は入力トークンが大きく出力が小さい、定型生成型は入力が小さく出力が中程度、という具合に、類型ごとの偏りを踏まえると精度が上がります。キャッシュ読み出しの割引が効く使い方をしているかどうかも、試算に織り込みます。

チャット画面から使う場合は、利用者一人あたりの月額として見ることになります。事務所の規模が数人であれば、階層の選択より、そもそも誰にライセンスを配るかのほうが総額への影響が大きくなります。API経由で自前の仕組みを組む場合は、従量課金になるため、階層の割り当てが直接コストに跳ね返ります。

検証体制としては、正解が確定した案件を十件程度そろえた検証セットを作り、四半期に一度流し直す運用が現実的です。作成には数日かかりますが、一度作れば以後は流用できます。検証結果は、誰がいつどの階層で何を確認したかまで含めて記録し、モデル割り当ての根拠として保管します。この記録が、顧客から品質管理の体制を問われたときの説明材料になります。

モデルが速く入れ替わる時代の選び方

GPT-5.6の設計で目を引くのは、番号が世代を、名前が能力の階層を表すという整理です。同社の公表資料は、Sol、Terra、Lunaを世代をまたいで継続する階層と位置づけています。事務所の側から見ると、これは業務とモデルの対応を階層名で固定できるということを意味します。世代が上がるたびに割り当てを組み直すのではなく、階層名で組んでおいて、世代交代のたびに検証セットで確かめる運用が成り立ちます。

残る論点は二つあります。一つは、上位階層の性能が上がるほど、下位階層でも十分な業務が増えていくという逆説です。実際、日常業務向けの階層が前世代のフラッグシップに近い水準に来ている以上、上位に寄せる根拠は年々弱くなります。もう一つは、検証セットの維持です。モデルの入れ替わりが速いほど、自前の物差しを持っている事務所と持っていない事務所の差が開きます。どのモデルを選ぶかより、選び方を持っているかが問われる局面に入っています。

よくある質問

GPT-5.6のどの階層を事務所に入れればよいですか

業務の類型によって分けるのが現実的です。契約書一式のような長文を読ませる業務は上位階層、案内文の作成や議事録の整形は下位階層で足りる場面が多くなります。判断の根拠は、自事務所の実データで作った検証セットに置く形がもっとも説明しやすくなります。

下位階層のLunaは士業業務に使えますか

短い文書を扱う業務であれば実用に耐えます。ただし長文脈の評価では上位階層と大きな差が出ており（OpenAI 公表資料）、まとまった資料を丸ごと読ませる用途には向きません。用途を限定して使うという前提が要ります。

顧客の資料を入力してよいかはどう判断しますか

契約プランと利用経路によってデータの扱いが変わるため、まずどの経路で使うかを決めます。そのうえでベンダーの公式ドキュメントで扱いを確認し、確認日を記録に残します。顧客への説明と同意の取り方を契約書に書き込むところまでを一組にすると、運用が安定します。

Zero Data Retentionに対応していれば守秘義務の問題は解消しますか

データ保持の設定は論点の一部にすぎません。守秘義務の根拠条文は職種ごとに置かれており（e-Gov法令検索）、事務所内で誰が何を入力したかを追える体制、顧客への説明、記録の保存といった運用面とあわせて設計することが要になります。

ベンチマークの数字はどこまで信用してよいですか

一般的な水準を知る材料としては有用ですが、日本語の専門文書や事務所固有の書式は評価条件に含まれていません。公表値は出発点として使い、自事務所の実データによる検証で補うという二段構えが現実的です。

モデルが更新されるたびに検証をやり直す必要がありますか

検証セットを作っておけば、流し直すだけで済みます。作成には数日かかりますが、更新のたびにゼロから比較する手間と比べれば軽くなります。四半期に一度の頻度で回している事務所が多い印象です。

複数のベンダーのモデルを併用する意味はありますか

用途によって得意分野が異なるため、併用には合理性があります。ただし併用するほど、どの業務でどれを使うかの管理と、それぞれのデータの扱いの確認が増えます。管理コストと精度の見合いで決める論点です。

参考文献

• OpenAI GPT-5.6: Frontier intelligence that scales with your ambition
• e-Gov法令検索 弁護士法第23条
• e-Gov法令検索 税理士法第38条
• e-Gov法令検索 公認会計士法第27条
• e-Gov法令検索 社会保険労務士法第21条
• 個人情報保護委員会 生成AIサービスの利用に関する注意喚起

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/