こんにちは！
Qualitegプロダクト開発部です！

「ngrok の代替になる国産のトンネルサービスはないか」。

そう検索して、この記事にたどり着いた方も多いはずです。

この記事は、その問いに開発元として正面から答えます。

先にことわっておきますと、ここで紹介する WireCanal は、日本法人である当社（株式会社Qualiteg）が開発・運営し、中継基盤を国内サーバーで運用しているトンネルサービスです。

自社製品を自分で比較する記事なので、都合のよい話だけを並べても信用されません。同じところは同じと書き、ngrok のほうが向いている場合もそのまま書きます。

結論から言うと、

トンネルの基本の仕組みは ngrok と同じです。

違いは3つあります。

料金の考え方（固定枠・従量要素を持つドル建ての料金体系か、追加請求のない円建て定額か）・運用と契約の形（国内中継基盤と日本法人との日本語・円建て契約）・AI につなぐときの許可の置き場所（許可台帳の正本を社内側に置く）

この3つが刺さらない使い方なら、無理に乗り換える必要はありません。どこが同じで、どこが違うのかを順に見ていきます。

仕組みは同じです。だから学び直しはほぼ要りません

ngrok で広く知られるようになったリバーストンネル方式は、こういう仕組みです。手元のPCや社内サーバーに小さなプログラム（WireCanal では Agent と呼びます）を置き、それが内側から外向きに中継サーバーへ接続してトンネルを張ります。外の世界には公開URLができて、そこに届いたアクセスがトンネルを通って手元に流れてくる。

ファイアウォールに受信ポートを開けずに済むのが、この方式の利点です。

WireCanal も同じ考え方を土台にしています（図1）。コマンドを実行して Agent を入れ、canal と呼ぶ公開経路を作り、転送先に手元のポートを指定する。ngrok を使ったことがある方なら、概念の学び直しはほぼ要りません。

なお、現在の ngrok はクラウド側エンドポイントなど製品の範囲が広がっていますが、この記事では「Agent を使ってローカル・社内サービスを公開する」基本構成を比べます。

だからこの記事で書くべきは「どちらが優れているか」ではなく、その先の設計がどう違うか、です。

違い1　料金は円建て・税込の定額制です

ngrok には Free・Hobbyist・Pay-as-you-go などのプランがあります（2026年8月時点・公式サイトで確認）。まず形を表で比べます。

本番利用を想定した Pay-as-you-go は、月20ドルの利用枠を含み、超えた分は転送量・リクエスト数・エンドポイントの稼働などに応じて追加料金が発生する仕組みです。使った分だけ払う合理的な設計ですが、利用が伸びた月の請求額は事前に読みにくく、ドル建てなので為替でも変わります。

WireCanal は、どのプランも月額定額の円建て・税込にしました。プランごとの違いはこうです。

年払いにすると月額換算でライト1,280円・プロ2,980円・プレミアム9,980円になります。

転送量に応じた追加請求はありません。

フリープランは月10GBが目安で、超過時は速度を調整する場合があります。有償プランには通常利用での月間転送量の上限を設けていませんが、公平な利用とネットワーク維持のため、極端な大容量通信は速度制限等の対象になる場合があります。

ことわっておくと、定額が常に得というわけではありません。利用規模や用途によっては、ngrok の Free・Hobbyist・Pay-as-you-go のほうが安く収まる場合もあります。定額制の価値は請求額が事前に読めることにあり、稟議や予算取りが要る組織ほど効いてきます。

違い2　国内リージョンで動き、契約・請求・サポートが日本語と円で完結します

WireCanal の中継基盤は国内リージョンに配置しています。契約とサポートは日本の事業者である当社が日本語で提供し、請求は円建てです。ここも表で整理します。

なお、ngrok にも東京の接続拠点（PoP）があり、地域を指定したルーティングの仕組みもあります。つまり、単純な「国内経路の有無」の比較ではありません。WireCanal の違いは、中継基盤を国内サーバーで運用することをサービス設計として掲げ、日本法人との契約・日本語サポート・円建て請求までセットになっている点です。

「海外SaaSの利用申請が社内でなかなか通らない」「円建ての請求書が出ないと経理処理が面倒」という組織にとって、ここは機能の優劣ではなく、導入できるかどうかの分かれ目になります。

正直に書いておくと、国内リージョンだからといって、海外サービスより常に速いとは言えません。実際の遅延は利用場所・接続先・経路で変わります。逆に、世界各地の利用者に配信したい・海外拠点からも同じように使いたいという場合は、世界規模の接続拠点を持つ ngrok や Cloudflare のほうが適しています。

違い3　AI に見せる機能の「許可台帳」を、社内側に置いています

ここが、当社がいちばん考え抜いた部分です。

生成AIに社内システムを操作させる接続方式として、MCP（Model Context Protocol）が広まりつつあります。すると実務では「AI に社内システムのどの機能まで触らせるか」が問題になります。社内の MCP サーバーには、参照するだけのツールから更新・削除を行うツールまで並んでいるのが普通だからです。

MCP を外部の AI につなぐ際にゲートウェイ側で制御する、という発想自体は当社だけのものではありません。各社の公式ドキュメントで確認できる範囲を表にします。

WireCanal が異なるのは、ツール単位の許可そのものに加えて、その許可台帳の正本を社内側の設定ファイルに置いている点です（図2）。

wirecanal.json（ツール許可の部分・抜粋）

{
  "tools": {
    "default": "deny",
    "allow": ["execute_sql_query", "get_database_stats"]
  }
}

既定は全拒否で、この allow に書いたツールしか AI には見えません。許可していないツールは、ツール一覧（tools/list）にも出ません。クラウドの管理画面からできるのは変更の提案までで、反映には社内側での承認操作が必要です。つまり、通常の管理画面の操作だけでは、社内側の承認なしに公開範囲は広がりません。

もうひとつ、Agent は設定ファイルに登録された転送先へだけ接続し、クラウド側から転送先を動的に変える指示は受け付けません。トンネルの出口が社内の任意の宛先へ向かう汎用の中継点にならないよう、Agent 側でも制限しています。

自作の MCP サーバーを実際に Web 版の ChatGPT・Claude へつないだ手順は、当ブログの連載で画面つきで公開しています。この記事の最後にリンクを置きました。

ngrok のままがよい場合も書いておきます

ここまで読んで分かるとおり、WireCanal が向くのは「国内で・見通せる料金で・AI への公開範囲を統制しながら」使いたい場合です。使い方ごとに整理するとこうなります。

道具は用途で選んでください。無理に乗り換える理由がなければ、それはそれで正しい判断です。

無料でどこまで使えるか

WireCanalのフリープランに期間の制限はなく、クレジットカードの登録も要りません。

canal 1本で、HTTPS 公開・MCP 公開（ChatGPT/Claude などとの OAuth 連携）・IP制限・BASIC認証・Bearerトークン・時間帯公開などのアクセス保護8種まで、ぜんぶ使えます。

公開ホスト名は、使っている限り消えません。Agent の接続が生きている間は有効期限が自動延長され、最後の接続から72時間で失効します（失効しても作り直せます）。名前を自分で選びたい、接続を止めても同じ名前を残したい、となったときにライト以上を検討すれば十分です。

まずは手元の Web アプリか MCP サーバーをひとつ公開してみて、使い勝手を確かめるのがおすすめです。WireCanal は無料で始められます（wirecanal.com）。

まとめ　同じ方式、違う置きどころ

ngrok と WireCanal は、リバーストンネルという同じ方式の上に立っています。違いは、お金の払い方（固定枠・従量要素を持つドル建ての料金体系か、追加請求のない円建て定額か）、運用と契約の形（国内中継基盤と日本法人との日本語・円建て契約か、グローバルサービスの利用か）、そして AI 向けのツール許可台帳の正本を社内側に置いていること。この3点に集約されます。

トンネルサービスは、いちど運用に組み込むと長く付き合う道具です。機能表の○×だけでなく、この3つの置きどころが自分の組織に合うかで選ぶと、あとで後悔しません。

それでは、また次回、お会いしましょう！

参考（一次情報）

• ngrok の料金プラン（公式サイト）　※2026年8月時点の内容で確認しています
• ngrok の MCP ゲートウェイ公式ガイド（ngrok Docs）
• ngrok の接続拠点一覧（ngrok Docs）
• Cloudflare MCP Server Portals（Cloudflare Docs）
• WireCanal の料金プランと機能の対応表（wirecanal.com）
• WireCanal の MCP・AI 連携の解説（wirecanal.com）

関連記事

• MCPサーバーの作り方（前編）｜ PythonとFastMCPで売上DBをAIにつなぐ（当ブログ）

こんにちは！Qualitegプロダクト開発部です！

手元のデータベースをAIから問い合わせられるようにしたい。 そのために必要なのがMCPサーバーです。

やりたいことは単純なのですが、いざ調べてみると「MCPサーバーを作ればいい」というところまでは分かっても、自分のデータベースをどうやってMCP化するのかでつまずきます。

この記事では、

PythonとFastMCPでMCPサーバーを自作し、CLI版のClaude Codeから売上データベースに日本語で聞けるようにする

までの手順を、動くコードつきで最初から最後まで書きます。コードは200行ほどです。「職業別の売上トップ3を教えて」と聞くと、Claude Codeが自分でSQLを組み立てて集計まで返してくれるようになります。

書いたコードは全部GitHubに置きました。cloneして、依存関係のインストールとDB作成を行えば動きます。動かす手順はリポジトリのREADMEにも全部書いてあるので、記事を読まずに手を動かしたい方はそちらからどうぞ。

qualiteg/mcp-server-tutorial ｜ サンプルコード一式とREADME（GitHub）

前後編に分かれていて、前編（この記事）ではCLI版のClaude Codeから使えるところまで。後編では、同じサーバーをWeb版のChatGPT・Claudeから使えるようにします。手元で動くCLI版と、ブラウザで動くWeb版。この2つのあいだに、多くの人が引っかかる壁があります。

MCPとは何か、3分で

MCP（Model Context Protocol）は、AIアプリと外部のデータやツールをつなぐための共通規格です。Anthropicが2024年末に公開し、いまではClaudeだけでなくChatGPT、Gemini、各種コーディングエージェントが対応しています。

MCPが無かったころは、AIにデータベースを触らせたければ、AIアプリごとの独自プラグインや関数呼び出しに個別対応する必要がありました。MCPでは「サーバー（データやツールを出す側。今回作るもの）」と「クライアント（ClaudeやChatGPTなどのAIアプリ側）」の話し方が規格で決まっています。一度MCPサーバーを作れば、AIアプリごとに専用プラグインを作り直さずに、MCP対応の複数のAIアプリから利用できます。ただし、使えるトランスポートや認証方式、プラン、管理者設定はクライアントごとに違います。

MCPサーバーが出せるものはtools・resources・promptsの3種類ありますが、実務でまず使うのはtools、つまりAIが呼び出せる関数です。この記事もtoolsだけ扱います。

もうひとつ、後編で効いてくる予備知識があります。MCP仕様が定める標準トランスポートは2系統あります。

この記事では、前編でCLI版のClaude Codeからローカルのstdioサーバーを使い、後編でWeb版からリモートのStreamable HTTPサーバーを使います。ただし「CLI版ならstdio、Web版ならHTTP」と一対一で決まるわけではありません。たとえばClaude CodeはstdioにもリモートのHTTPにも接続できます。前編では両方の動かし方を試します。

何を作るか

PCパーツのオンラインショップを想定した売上データベース（SQLite）と、それに問い合わせるMCPサーバーです。

テーブルは3つです。顧客マスター（customers）が500人ぶん、商品マスター（products）がPCパーツ8カテゴリで72商品、そして売上明細（sales_transactions）が2024年から2026年までの4,000件。顧客には年齢や職業、年収帯といった属性を持たせてあるので、「職業別に見ると」のような分析ができます。

Claude Codeに渡すツールは、思い切って2つだけにします。テーブル構造と統計を返す get_database_stats と、SELECT文を実行する execute_sql_query です。

「売上集計ツール」「顧客分析ツール」と業務ごとに関数を並べる設計もあります。ただ、SQLを書けるのはClaude Code側なので、汎用のSQL実行ツールを1本渡すほうが応用が利きます。そのぶん安全側の手当てはサーバーの責任になりますが、これは後で書きます。

準備

MCPサーバー自体の実装に必要なのは、Python 3.10以降とFastMCPです。この記事と同じ形でClaude Codeから試すなら、Claude Codeを使える環境も別途必要です。

python -m pip install fastmcp

pip ではなく python -m pip を使ってください。pip だと、あとでMCPサーバーを起動するPythonと別の環境に入ってしまうことがあります。

FastMCPは、Python関数にデコレータを1つ付けるだけでMCPツールを定義できる高水準フレームワークです。クライアント機能やHTTPサーバー機能もまとめて使えます。筆者環境で動作確認したのはstandalone版の3.4.5です。

まず10行で、動くMCPサーバー

いきなり売上DBに行く前に、最小構成で全体像をつかみます。

# hello_mcp.py
from fastmcp import FastMCP

mcp = FastMCP(name="hello-server")

@mcp.tool(description="2つの数値を足し算します")
def add(a: int, b: int) -> int:
    return a + b

if __name__ == "__main__":
    mcp.run()  # 既定はstdioトランスポート

これで完成です。関数の型ヒントとdescriptionから、AIに渡されるツール定義が自動生成されます。

なお python hello_mcp.py を実行しただけでは何も表示されません。stdioサーバーとして入力待ちになるだけです。動きを確かめたいときは、FastMCPのin-memoryクライアントから呼びます。

import asyncio

from fastmcp import Client
from hello_mcp import mcp


async def main():
    async with Client(mcp) as c:
        print([t.name for t in await c.list_tools()])   # ['add']
        result = await c.call_tool("add", {"a": 120, "b": 5})
        print(result.data)                              # 125


if __name__ == "__main__":
    asyncio.run(main())

Claude Codeへの登録は1行です（登録して使うところは後半でやります）。

claude mcp add hello-server -- python hello_mcp.py

うまく繋がらないときは、Pythonとスクリプトを絶対パスで指定してください。仮想環境を使っている場合は、その中のPythonを指す必要があります。

ここで注目してほしいのは、AIが「計算が必要だ」「addというツールがある」「呼ぼう」と判断する材料が、ツール名、description、引数名や型から生成されるinputSchemaしかないことです。なかでもdescriptionは、そのツールをどんな場面で使うのかを自然文で伝えられる中心的な項目で、これがMCPサーバー設計でいちばん効いてきます。

手順1: 売上データベースを用意する

SQLiteでテーブルを3本作ります。

db_setup.py（テーブル定義とダミーデータ生成の全文コード（GitHub））

cur.execute("""
CREATE TABLE sales_transactions (
    transaction_id   INTEGER PRIMARY KEY,
    date             TEXT NOT NULL,     -- 'YYYY-MM-DD'
    customer_id      TEXT NOT NULL REFERENCES customers(customer_id),
    product_id       TEXT NOT NULL REFERENCES products(product_id),
    product_name     TEXT NOT NULL,
    product_category TEXT NOT NULL,
    quantity         INTEGER NOT NULL,
    unit_price       INTEGER NOT NULL,
    total_price      INTEGER NOT NULL
)""")

cur.execute("CREATE INDEX idx_trans_date     ON sales_transactions(date)")
cur.execute("CREATE INDEX idx_trans_customer ON sales_transactions(customer_id)")
cur.execute("CREATE INDEX idx_trans_category ON sales_transactions(product_category)")

インデックスは張っておいてください。AIは遠慮なく全期間の集計クエリを投げてきます。

乱数は固定シードにしてあるので、誰が実行しても同じデータになります。筆者環境で流すとこうなりました。

この記事に出てくる数字は、すべてこのデータの実測値です。手元で同じ数字が出るはずです。

手順2: ツールのdescriptionにスキーマを丸ごと書く

ここがこの記事でいちばん伝えたいところです。

execute_sql_queryのdescriptionには、データベースのスキーマとクエリ例を全部書き込みます。

mcp_server_sales.py（descriptionの全文コード（GitHub））

@mcp.tool(description="""SQLクエリを実行して売上データを取得します。SELECT文のみサポートします。

【データベーススキーマ】

■ customers（顧客マスター）
  - customer_id (TEXT): 顧客ID（例 'C0001'）
  - age (INTEGER): 年齢
  - gender (TEXT): 性別（'男性', '女性'）
  - prefecture (TEXT): 都道府県
  - occupation (TEXT): 職業（'ITエンジニア', '会社員', '学生', '自営業' など）
  - annual_income (INTEGER): 年収（万円）

■ products（商品マスター）
  - product_id (TEXT): 商品ID（例 'CPU_001'）
  - product_category (TEXT): CPU, GPU, Memory, SSD, HDD, Motherboard, PowerSupply, PCCase
  - tier (TEXT): 'high' / 'mid' / 'entry'
  （以下略。全カラムをこの調子で書く）

■ sales_transactions（売上明細）
  - date (TEXT): 売上日（YYYY-MM-DD形式）
  - customer_id (TEXT): 顧客ID → customers.customer_id
  - product_id (TEXT): 商品ID → products.product_id
  - quantity / unit_price / total_price (INTEGER)

【データ期間】2024-01-01 〜 2026-12-31（4,000件）

【クエリ例】
- 職業別の売上:
  SELECT c.occupation, SUM(t.total_price) AS sales
  FROM sales_transactions t JOIN customers c ON t.customer_id = c.customer_id
  GROUP BY c.occupation ORDER BY sales DESC

- ハイエンドGPUの売上:
  SELECT p.product_name, SUM(t.total_price) AS sales
  FROM sales_transactions t JOIN products p ON t.product_id = p.product_id
  WHERE p.product_category = 'GPU' AND p.tier = 'high'
  GROUP BY p.product_name ORDER BY sales DESC
""")
async def execute_sql_query(sql: str, ctx: Context) -> str:
    ...

やたら長いと思われるかもしれません。でもAIが正しいSQLを書けるかどうかは、モデルの賢さよりもスキーマをどれだけ正確に渡せているかで大きく変わります。今回のような小規模で固定されたスキーマなら、必要なカラムとJOIN関係をdescriptionに含めておくのが有効でした。

AIがツールを選ぶ材料は、ツール名、description、引数名や型から生成されるinputSchemaです。なかでもdescriptionは、どんな場面で呼ぶツールなのかを自然文で伝えられます。

クエリ例を2〜3個入れておくのもコツです。JOINの書き方や列の使い方のお手本があると、AIが書くSQLの精度が目に見えて安定します。

手順3: SQL実行ツールに3つの安全弁を設ける

AIにSQL実行を任せる以上、書き込みの防止と、重いクエリでリソースを持っていかれることの両方に備える必要があります。役割の違う3つの安全弁を設けます。

1段目、データベースを読み取り専用で開く。 SQLiteはURI接続でmode=roを指定すると、そもそも書き込みを受け付けなくなります。あとの検査をすり抜けられても、ここで止まります。

mcp_server_sales.py（読み取り専用で接続する関数のコード（GitHub））

conn = sqlite3.connect(f"file:{DB_PATH.as_posix()}?mode=ro", uri=True)

2段目、SELECT以外を弾く。 これは構文解析ではなく文字列の検査なので、明らかな書き換え命令を早い段階で落とすための保守的な補助フィルターです。最終的な書き込み防止は1段目に任せます。

mcp_server_sales.py（SELECT以外を弾く部分のコード（GitHub））

normalized = sql.strip().upper()
if not normalized.startswith("SELECT"):
    return "エラー: SELECT文のみサポートしています"
for keyword in ("DROP", "DELETE", "INSERT", "UPDATE", "ALTER", "CREATE", "TRUNCATE", "ATTACH", "PRAGMA"):
    if keyword in normalized:
        return f"エラー: {keyword} は許可されていません"

3段目、実行時間に上限を付ける。 重い集計で固まらないよう、SQLiteの進捗ハンドラで打ち切ります。

mcp_server_sales.py（実行時間に上限を付ける部分のコード（GitHub））

import time

def install_query_timeout(conn, timeout_sec):
    deadline = time.monotonic() + timeout_sec

    def guard():
        return 1 if time.monotonic() >= deadline else 0

    # SQLite仮想マシンが1,000命令を実行するたびに guard を呼ぶ
    conn.set_progress_handler(guard, 1000)

ここは一度間違えました。進捗ハンドラの呼び出し回数を数えて上限にしていたのですが、set_progress_handler の第2引数は秒ではなくSQLite仮想マシンの命令数です。呼ばれた回数は実行時間そのものではないので、マシンの速度やクエリの内容で待ち時間が変わってしまいます。time.monotonic() で実時間を見るのが正解でした。

なお、この3段目は読み取り専用にするための対策ではありません。暴走したクエリでリソースを持っていかれないための対策です。それぞれ守っているものが違います。

3段が本当に効いているかどうかは、あとで実際に確かめます。

手順4: AIに返す量を、サーバー側で決める

クエリ結果を整形する部分です。返す行数に上限を付けているところを見てください。

mcp_server_sales.py（クエリ結果を整形する部分のコード（GitHub））

    if not rows:
        return "クエリの結果、データが見つかりませんでした。"

    lines = [" | ".join(columns), "-" * 40]
    for row in rows[:MAX_ROWS]:                      # MAX_ROWS = 50
        lines.append(" | ".join("" if v is None else str(v) for v in row))
    if len(rows) > MAX_ROWS:
        lines.append(f"... 他 {len(rows) - MAX_ROWS} 件（全体を見るには集計するか条件を絞ってください）")

    return f"クエリ結果（{len(rows)} 件）:\n\n" + "\n".join(lines)

AIは平気でSELECT * FROM sales_transactionsを投げてきます。4,000行をそのまま返してもコンテキストを溢れさせるだけです。件数だけは正直に伝えて、「集計するか条件を絞って」と促すのが実用的でした。

ただしこの実装が制限しているのはAIへ返す行数だけで、SQLiteから読み込む件数は制限していません。数百万行の実データを相手にするなら、fetchmany(MAX_ROWS + 1) にする、SQL側にLIMITを付ける、クエリコストを見る、といった手当てが別に要ります。

手順5: 「まず全体像を見せる」ツールを足す

2本目のツールは、テーブル構造と統計の要約を返すだけのものです。

mcp_server_sales.py（統計情報を返すツールの全文コード（GitHub））

@mcp.tool(description="""データベースのテーブル構造・件数・データ期間・カテゴリ別売上の統計を返します。
SQLを作る前に、必ずこのツールを呼んで構造を確認してください。""")
async def get_database_stats(ctx: Context) -> str:
    ...

descriptionの最後の一文が仕事をします。

「SQLを作る前に、必ずこのツールを呼んで」

筆者環境では、これを書いたことで、まず統計を確認してからSQLを組み立てる動きになりました。

ただしこれはモデルへのお願いであって、サーバー側で強制される制御ではありません。モデルやクライアント、会話の流れによっては、統計を見ずにいきなりSQLを投げてくることもあります。安全性をこの一文に頼らせない、というのが大事なところです。ツールの説明文は、機能の説明だけでなく、使う条件や手順をモデルへ伝える場所としても働く、くらいの理解が安全です。

使ってみる

Claude Codeに登録します。

claude mcp add sales-db -- python C:\qualiteg_examples\mcp_server_sales.py

登録できたか確認します。

claude mcp list

sales-db: python C:\qualiteg_examples\mcp_server_sales.py - ✔ Connected

✔ Connected が出れば、AIからこのサーバーが見えています。あとは日本語で聞くだけです。

claude -p "職業別の売上トップ3を教えて"

返ってきたのがこれです。

質問したのは日本語の一文だけです。AIはこちらがSQLを一行も書かないまま、テーブル構造を確認し、JOINとGROUP BYを組んだクエリを投げ、集計結果を表にまとめて返してきました。

金額はダミーデータの実測値と一致しています。さらに、質問には含めていなかった取引件数も追加で集計し、「研究者は件数が最多だが単価が低い」「経営者は件数が少ないぶん単価が高い」という読みまで付けてきました。単にSQLを生成するだけでなく、集計結果の解釈まで行っています。

「2025年に発売されたハイエンドGPUで、20代への売上が多い順に」のような多段の条件も同じ調子で通ります。SQLを書いたことがない人でも、売上データベースに話しかけられるようになりました。

ただし、自然言語で聞けることと、集計結果が業務上正しいことは別の話です。重要な判断に使うなら、実行されたSQL・集計の定義・対象期間・除外条件を確認できるようにしておいてください。「売上」「顧客数」「平均単価」あたりは、社内の定義次第で数字が変わります。

安全弁がちゃんと効いているか確かめる

書いたつもりで効いていない防御ほど怖いものはありません。実際、この記事を書いている途中でタイムアウトが機能していないことに気づきました。

3段はそれぞれ守っているものが違うので、確かめ方も分ける必要があります。ツール経由のキーワード検査はFastMCPのin-memoryクライアントで、読み取り専用とタイムアウトはDB接続を直接触って確認します。

verify.py（検証スクリプトの全文コード（GitHub））

# 1段目: 接続そのものが書き換えを拒むか
conn = connect_readonly()
try:
    conn.execute("DELETE FROM customers")
    raise AssertionError("読み取り専用のはずが書き込めてしまいました")
except sqlite3.OperationalError as e:
    assert "readonly" in str(e).lower()

# 3段目: 重いクエリが実時間で中断されるか
conn = connect_readonly()
install_query_timeout(conn, QUERY_TIMEOUT_SEC)
started = time.monotonic()
try:
    conn.execute(HEAVY_SQL).fetchone()
    raise AssertionError("中断されませんでした")
except sqlite3.OperationalError as e:
    assert "interrupted" in str(e).lower()
    print(f"{time.monotonic() - started:.1f} 秒で中断")

筆者環境での結果です。

SELECTで始まってはいるがDROPを潜ませたクエリも止まっています。読み取り専用の接続は「attempt to write a readonly database」で書き込みを拒み、重いクエリは実時間10.0秒で中断されました。行数上限も、SELECT * FROM sales_transactionsを投げると50行のあとに「... 他 3950 件」と付いて返ってきます。

なおこの検証はin-memoryクライアントとDB接続を直接使ったもので、stdioやHTTPのトランスポートを経由した動作までは確認していません。

ここまで確認してから、はじめて社内で使ってもらうようにしてください。

HTTPサーバーとして常駐させる

ここまではstdio、つまりAIアプリが手元でサーバーを起動する形でした。独立して常駐させ、ネットワーク経由で使うならStreamable HTTPに切り替えます。変えるのは起動の1行だけです。

mcp_server_sales.py（起動部分のコード（GitHub））

mcp.run(transport="http", host="127.0.0.1", port=9904)

これでhttp://127.0.0.1:9904/mcpがMCPエンドポイントになります。

待受は127.0.0.1にしてください。 このサーバーは認証を持っていません。0.0.0.0で待ち受けると、そのネットワークから届く相手なら誰でもSQLを実行できてしまいます。サンプルコードでも既定を127.0.0.1にして、外部待受を指定したときは警告を出すようにしました。社内で共有する、外から使うという段階に進むなら、HTTPS、認証と認可、接続元の制限、Origin検証、監査ログを前段に置く前提になります。この記事のサーバーは、その手前の「仕組みを理解するための最小構成」です。

死活監視用のエンドポイントも追加しておくと運用が楽です。

mcp_server_sales.py（ヘルスチェックのコード（GitHub））

@mcp.custom_route("/health", methods=["GET"])
async def health_check(request):
    from starlette.responses import JSONResponse
    return JSONResponse({"status": "ok", "service": "sales-database-server"})

サンプルコードでは--httpオプションで切り替えられるようにしてあります。

python mcp_server_sales.py --http --port 9904

起動したら、ヘルスチェックを叩いて生きていることを確かめます。

curl http://127.0.0.1:9904/health

{"status":"ok","service":"sales-database-server"}

返すのは状態だけにしてあります。監視に要らない情報（DBの絶対パスや例外の中身）を外へ出す理由はありません。

作ってみて分かったこと

今回いちばん効いたのは、ツールを2本に絞ったことでした。業務ごとに関数を並べるより、汎用のSQL実行ツールを1本渡すほうが、AIは自分で考えて答えを出してくれます。ただしこれは小規模なダミーDBでの話です。実データを扱うなら、取得できるテーブルや列、集計の粒度を絞った業務別ツールのほうが安全で、監査もしやすくなります。

そのぶん、descriptionの書き方で結果が大きく変わります。スキーマとクエリ例を丸ごと書いたら、AIのSQLが安定しました。descriptionは機能の説明だけでなく、ツールを使う条件や手順をモデルへ伝える場所としても働きます。ただし手順の指示はお願いであって、実行が保証される仕組みではありません。

安全側の手当ては3段にしました。読み取り専用で開き、SELECT以外を弾き、実行時間に上限を付ける。そして書いて終わりにせず、3段それぞれを実際に試して確かめました。ここを省くと、効いていない防御を効いていると思い込んだまま社内に配ることになります。実際、最初に書いたタイムアウトは実時間を測っておらず、まったく機能していませんでした。

返す行数の上限も忘れないでください。AIは平気で全件取得を投げてきます。50行で切って件数だけ正直に伝えたところ、筆者環境では集計クエリへ切り替える動きが確認できました。

常駐させて使うならStreamable HTTPに切り替えて、ヘルスチェックも足しておくと運用が楽になります。ただし認証は入っていないので、そのまま社内LANや外部へ出さないでください。

もうひとつ。このサンプルは仕組みを理解するための最小構成です。複数人が同時に使う場面では、同期的なDB処理をスレッドへ逃がす、同時実行数を絞る、DB側のタイムアウトを設ける、といった手当てが別に要ります。

次回予告

後編でやることは、はっきりしています。

手元（localhost）で作ったこのMCPサーバーを、Web版のChatGPT・Claudeと連携させます。OAuth認証の壁も乗り越えます。

CLI版のClaude Codeを使うのは開発者です。でもブラウザで使うWeb版なら、コマンドラインを触らない人にも渡せます。営業企画のメンバーが、いつものChatGPTの画面から「先月いちばん売れたGPUは？」と聞ける。同じMCPサーバーのまま、使える人の範囲が一気に広がります。

ところが、ここが本当に難しい。Web版のコネクタにMCPサーバーをつなぐには、次の2つが要ります。

ひとつは、インターネットから到達できるHTTPSのURL。手元のPCで動いているサーバーには、外から誰も届きません。かといって社内DBに届くサーバーをそのまま外に晒すわけにもいきません。

もうひとつが、利用者を識別してアクセスを制御するための認証・認可です。

ChatGPTもClaudeも、構成によっては認証なしのリモートMCPに接続できます。ただ、社内データベースに到達するMCPサーバーを認証なしで公開する選択肢はありません。そこで後編では、MCP Authorization仕様に沿ったOAuth認証を使います。

これを自前で実装するとなると、認可メタデータ、クライアント登録、認可エンドポイント、トークンの発行と検証と、ツール本体とはまったく別の実装が必要になります。ツール本体は200行で書けたのに、本題に入る前に力尽きる。ここで止まる人が多いところです。

後編では、この2つの壁をどう越えるかを、実際にWeb版のChatGPTとClaudeから今回の売上DBにつなぐところまで、画面つきで書きます。しかも無料で試せる方法でです。

先に開示しておくと、後編では当社が提供しているWireCanalを使います。無料で試せる枠があるので、そのまま手を動かせます（利用条件や無料枠は執筆時点のものです）。

それでは、また次回、お会いしましょう！

サンプルコード

この記事のコードはすべてGitHubに置いてあります。

qualiteg/mcp-server-tutorial ｜ サンプルコード一式とREADME（GitHub）

git clone https://github.com/qualiteg/mcp-server-tutorial.git
cd mcp-server-tutorial
python -m pip install -r requirements.txt
python db_setup.py

続けてClaude Codeへ登録します。

claude mcp add sales-db -- python /path/to/mcp-server-tutorial/mcp_server_sales.py
claude mcp list
claude -p "職業別の売上トップ3を教えて"

stdioで使う場合、python mcp_server_sales.py を別ターミナルで手動起動する必要はありません。登録したコマンドはClaude Codeが子プロセスとして起動します。

ここに書いた手順は、リポジトリのREADMEにも全部書いてあります。 クイックスタート、Claude Codeへの登録方法、提供しているツールの説明、HTTPサーバーとしての起動まで揃っているので、手元で動かすときはREADMEだけ見れば足ります。

参考

• Model Context Protocol 公式サイト
• FastMCP
• Anthropic: Introducing the Model Context Protocol

関連記事

株式会社Qualiteg（本社：東京都千代田区、代表取締役：三澤 智則）は、2026年8月4日、「WireCanal（ワイヤキャナル）」の一般提供を開始しました。WireCanalは、ClaudeやChatGPTなどのクラウドAIと、社内ネットワークにあるデータベースやMCPサーバーを安全につなぐサービスです。会社の認証基盤で利用者を認証し、管理者が許可したドメインに属する組織アカウントだけが、AIを通じて社内システムへアクセスできます。AI連携のほか、HTTPSやTCP（RDP、SSH、データベースなど）の汎用セキュアトンネルとしても利用できます。

「canal」は、英語で「運河」を意味する言葉です。運河が、行き先の定まった船だけを通す人工の水路であるように、WireCanalは、クラウドAIと社内システムの間に、許可された通信だけが行き来できる専用の通り道（セキュアトンネル）を構築します。WireCanalでは、この一本一本の通信経路を「canal」と呼びます。canalは、社内に設置した中継プログラム「WireCanal Agent」が社内側から外向きに接続して開通するため、受信ポートの開放や、新たなVPN環境の構築は必要ありません。

WireCanalは、クレジットカード登録不要のフリープラン（0円）から利用できます。あわせて、一般提供の開始を記念したリリースキャンペーンを実施します。2026年8月31日までにライトプラン（canal 1本）を年間契約でお申し込みいただくと、初年度を年額6,000円（税込・月額換算500円）でご利用いただけます。キャンペーン終了後（2026年9月1日以降）の新規年間契約価格は、年額15,360円（税込）です。

AIに社内の生きたデータを使わせたい。しかし、社内システムは公開できない

「社内の売上データをClaudeに聞きたい」「在庫や生産の状況を、SQLやシステムの操作を覚えずに言葉で確かめたい」。クラウドAIの業務活用が進む一方、その答えの根拠となるデータベースや基幹システム、そしてそれらをAIから扱えるようにするMCPサーバーは、手元のPCや社内ネットワークの中にあります。クラウド上のAIからは、そのままでは届きません。

MCP（Model Context Protocol）は、AIが外部のツールを発見して実行するための共通仕様であり、認証・認可の仕組みも定めています。一方で、MCPに対応しただけで、クラウドAIから社内ネットワークまでの安全な到達経路や、会社のIdPと連動したアカウント管理まで自動的に用意されるわけではありません。

クラウドAIから社内ネットワークへ届く通信経路、会社のIDによる利用者の管理、退職時の会社アカウント停止に連動したアクセスの失効といった企業向けの運用基盤は、別途構築する必要があります。

かといって、適切な認証やアクセス制御を設けずにMCPサーバーをインターネットへ公開すれば、社内システムへの入口を広く露出することになります。受信ポートの開放やVPNの構築で対応しようとすれば、今度は情報システム部門の構築・運用負担が重くのしかかります。「使いたい。しかし、安全に出す方法がない」。ここで多くの企業が立ち止まっています。

WireCanalの答え：社内から外向きにつなぎ、会社のIDで入口を守る

Windows、Linuxで動作する接続アプリ「WireCanal Agent」を社内に置くと、Agentが外向きの暗号化トンネルを構築し、ClaudeやChatGPTからのリクエストは、あらかじめ指定した社内のMCPサーバーだけへ届きます。

そして入口を守るのは、会社のIDです。利用者がcanalにアクセスすると、Google Workspaceなど会社の認証基盤のログイン画面が表示され、接続できるのは管理者が許可したドメインの組織アカウントだけになります。WireCanal専用のアカウントを一人ずつ発行する必要はありません。退職などで会社側がアカウントを停止すると、その利用者の接続も1時間以内に自動的に失効します。「誰が使えるか」の管理を会社の既存のID基盤にそのまま委ねられること。これがWireCanalの答えです。

WireCanalの特長：AIに見せるツールを、社内が選ぶ

WireCanalは、HTTPSでのWebシステム公開と、IPアドレス制限・BASIC認証・トークン認証など8種のアクセス保護を全プランで提供する、汎用のセキュアトンネルとしても使えます。RDP・SSH・データベースなどに対応するTCP中継は、プロプラン以上で利用できます。

そのうえでの特長が、MCPツール単位の公開制御です。社内MCPに多数のツールがあっても、AIに見せるものを許可台帳で選べます。既定は全拒否。許可台帳の正本は社内に置く設定ファイルであり、クラウド側の管理画面からできるのは変更の「提案」まで、反映には社内での承認操作が必要です。トンネルが土管だとすれば、WireCanalは中身を理解して通すものを選ぶ門番です。

組織のAI利用を守る、多層防御

ここまで述べた「誰が接続できるか」「AIに何を見せるか」に、「社内のどこへ届くか」を加えた3つが、WireCanalの守る境界です。接続アプリは設定した転送先以外へは接続せず、これにより、トンネルが社内の任意の宛先へ通信を中継する通り道として使われることを防ぎます。WireCanalの中継基盤は国内サーバー上で運用しており、canalごとに到達アクセスを記録して、いつ・どこから接続があったかを後から確認できます。WireCanalのアクセス制御で許可を確認できない通信は拒否する、fail-closed設計を採用しています。

この境界を、次の5層の防御が支えます。

1. 転送先の固定 ― Agentは設定した転送先以外へ接続しません。接続のたびに宛先を検証し直し、リダイレクトにも追従しません
2. 入口の限定 ― 公開入口を正規の呼び出し元のIPアドレスに絞り込めます。Agentの接続は発行済みキーの照合で確認します
3. アクセス保護 ― IP制限、国別制限、BASIC認証、トークン認証、時間帯公開、パス制限、自動ブロック、ステルスモードの8種を、全プランで利用できます
4. 公開範囲の許可リスト ― 外部に見せるMCPツール・URLパスは、社内側の許可台帳で管理します。既定は全拒否です
5. 標準準拠のMCP認証 ― MCP Authorization仕様および関連RFC（RFC 9728・RFC 8414・RFC 8707など）に対応した認証・認可機能を内蔵し、入口で検証した認証情報は転送先へ渡しません

これらに加えて、canalごとの専用サブドメインと固有IDによる分離、canal単位の一時停止・再開、社内側からの即時遮断、プランに応じたアクセスログ（直近1,000〜10,000件・CSVダウンロード対応）を備えます。社内データベースやMCPサーバー本体は社内に置いたままです。まず一人で試し、部署へ広げるときも、IdP設定・canal・許可ツールという同じ仕組みのまま管理を引き継げます。

利用イメージ：Claudeと社内の売上データベースをつなぐ、3つのステップ

事前に社内MCPサーバーとWireCanal Agentを用意した後、MCP canalの作成、会社の認証基盤との連携、Claudeへの接続URLの登録という3つのステップで接続を設定できます。

1. MCP canalを作成する

WireCanalの管理画面で、利用するAIと、転送先となる社内のMCPサーバーを指定してMCP canalを作成すると、Claudeに登録するための接続URLが発行されます。社内に置いたWireCanal Agentが外向きに接続し、通信経路はこの時点で開通します。

2. 会社の認証基盤でMCP canalを守る

作成したMCP canalにGoogle Workspaceなどの組織IdPを割り当て、接続を許可するドメインを設定します。以後、このcanalの入口は会社のログイン画面になります。

3. Claudeに接続URLを登録する

発行された接続URLをClaudeのカスタムコネクタに登録し、会社のアカウントでログインすれば設定は完了です。接続に必要なOAuthの設定はWireCanalが自動で応答するため、AIサービスとの接続用に認可サーバーを別途構築する必要はありません（組織IdP連携の初回設定では、お使いのIdP側でのクライアント登録が必要です）。あとはClaudeに話しかけるだけで、カテゴリー別の売上、年間の売上推移、商品別の販売動向などを、社内の最新データを基に質問・分析できます。SQLを書く必要はありません。

リリースキャンペーン：canal 1本・永続サブドメイン付きのライトプランを、初年度 年額6,000円（税込・月額換算500円）で提供

一般提供の開始を記念し、ライトプラン（canal 1本）を対象としたリリースキャンペーンを実施します。2026年8月31日（月）までに年間契約でお申し込みいただくと、初年度を年額6,000円（税込・月額換算500円）でご利用いただけます。キャンペーン終了後（2026年9月1日以降）の新規年間契約価格は、年額15,360円（税込）です。

※プロモーションを適用できるのは、初回の年間契約時に限ります。2年目以降に契約を更新する場合は、更新時点の通常価格が適用されます。キャンペーンの内容および実施期間は、予告なく変更または終了する場合があります。

WireCanalについて

WireCanalは、クラウドAIや外部サービスと社内システムを安全につなぐ、中継基盤を国内サーバー上で運用するセキュアトンネル＋MCPポリシーゲートウェイです。会社の認証基盤による利用者の確認と、MCPツール単位の権限制御を備え、受信ポートの開放や新たなVPN構築なしに、ClaudeやChatGPTなどから社内システムを利用できるようにします。MCPのほかHTTPSやTCP（RDP、SSH、データベースなど）にも対応し、接続アプリ「WireCanal Agent」はWindows、Linuxで動作します。クレジットカードの登録が不要なフリープランから利用できます。

製品・料金・セキュリティの詳細：https://wirecanal.com/

株式会社Qualitegについて

株式会社Qualitegは、2023年7月に設立されたAIカンパニーです。「世界中の人々のクリエイティビティを深化させる」という経営理念のもと、最先端のAI技術を通じて人々の創造力を増幅し、これまで想像もできなかった新たな表現と価値を生み出す世界の実現に取り組んでいます。AIを一部の専門家の特権にとどめるのではなく、誰もが直感的にAIを活用して自らの創造性を深化させられる、技術格差による分断のない社会を目指し、生成AIプロダクトの研究開発とコンサルティングを行っています。

本件に関するお問い合わせ

株式会社Qualiteg

WireCanal PR担当

お問い合わせ：wirecanal-pr@qualiteg.com

※組織IdP連携はライトプラン以上で利用できます。

※クラウドAIをご利用の場合、MCPツールの呼び出しに必要なリクエストと実行結果は、利用するAIサービスにも送信されます。データの取り扱いは、各AIサービスの規約および設定に従います。

※対応するAIサービス、利用可能な機能、設定手順および必要な管理者権限は、各AIサービスのプランやワークスペース設定により異なります。記載内容は2026年8月4日時点のものです。

※ダッシュボードで参照できるアクセスログの保存件数は、ご利用プランにより異なります。

※記載されている会社名・製品名・サービス名は、各社の商標または登録商標です。第三者のサービス名は接続例として記載しており、各社との提携・後援・推奨関係を示すものではありません。

こんにちは！

前回の記事「TensorRT 10 × Blackwell 移行ガイド【前編】RTX 50 で推論資産が動かない — 基本と最初の壁」では、Blackwell 世代への移行で既存の推論資産が動かなくなる理由と、TensorRT 10 化を最小構成で通す手順を扱いました。前編で出てきた問題には、実はひとつ共通点があります。

すべて、エラーで止まってくれたということです。

本当に怖いのはその先です。TensorRT への移行パイプラインには、

• ビルドが通る
• 実行も通る
• 速度もちゃんと出る
• 出力の形も、値も、一見それらしい
• なのに、中身が間違っている

という失敗の仕方が存在します。

本記事では、TensorRT 本体の挙動だけでなく、export 時のミス・精度設定・エンジンの配布ミスまで含めて、エラーで停止せず誤った出力へ至る事象を便宜上 「沈黙劣化」 と呼びます。

テストが通り、ベンチマークが良い数字を出し、「◯倍速くなりました」と報告した後になって発覚するので、非常に厄介です。

本記事では、実際に踏んだ 5 つの沈黙劣化を、症状 → なぜ起きるか → どう見つけるか → 回避策の順に共有します。

最後に、これらを体系的に検出するための検証設計をまとめます。各事例をどこまで実証できているかを、先に正直に示しておきます。

第1部: 入出力の dtype を取り違える

症状

FP16 tactic を許可してモデルをエンジン化し、PyTorch の half テンソルをそのまま渡して実行しました
（前編の TRTRunner に入っている「dtype 合わせの 2 行」を入れる前の、素朴な実装です）。

エラーは出ません。速度も出ます。ただ、出力が PyTorch とまったく違いました。

どれくらい違ったかというと、出力の値域が 0.5 弱のモデルで、最大絶対誤差が約 13.8 です。fp16 の精度の問題という水準ではありません。完全な別物です。

なぜ起きるか

config.set_flag(trt.BuilderFlag.FP16) は「FP16 の実装候補を許可する」指定で、内部演算で FP16 tactic が選択可能になります（層によっては fp32 が選ばれます）。しかし、ネットワークの入出力テンソルの型は ONNX の定義のままです。ONNX を fp32 で export していれば、エンジンの入出力も fp32 のままなのです。

そこに PyTorch の half テンソルのアドレス（data_ptr()）を渡すとどうなるか。TensorRT はその領域を 「fp32 要素が並ぶ入力バッファ」として扱います。fp16 は 1 要素 2 バイト・fp32 は 4 バイトなので、値の解釈が変わるだけでなく、TensorRT が PyTorch 側の確保範囲を超えて読み出す可能性もあります。挙動は未定義で、出力の破損だけでなく、環境によっては CUDA エラーやクラッシュも起こり得ます。

そして最悪なのは、今回の実測では、この状態でも `execute_async_v3` が `True`（成功）を返し、NaN も出ず、例外も飛ばなかったことです。

回避策

エンジンが要求する dtype を問い合わせて、明示的に合わせてから渡します。 前編の TRTRunner に入れていた 2 行が、これに当たります。

want = _TRT2TORCH[self.engine.get_tensor_dtype(name)]   # エンジンが要求する型を問い合わせる
t = t.to(device=self.device, dtype=want).contiguous()   # 合わせてから渡す
if not self.ctx.set_tensor_address(name, t.data_ptr()):
    raise RuntimeError(f"set_tensor_address failed: {name}")

「fp16 でビルドしたのだから入力も fp16 だろう」は成り立ちません。必ずエンジンに聞いてください。

第2部: mode='linear' が黙って nearest で実行されていた

5 つの中で最も見つけにくく、最も驚いた罠です。

症状

前編で扱った 5D の grid_sample は、TensorRT がビルドを拒否してくれます（＝親切）。では 4D の `grid_sample` はどうかというと、ビルドも実行も問題なく成功します。

ところが出力を PyTorch と比べると、一様にズレている。fp16 でも fp32 でも同じだけズレる。つまり精度の問題ではなく、構造的に何かが違う。それでいて出力画像はパッと見では「ちゃんとそれらしい」のです。

まず、何が起きているかを突き止める

再現用の最小構成はこれだけです（build_engine / TRTRunner は前編のものをそのまま使います）。

class PlanarWarp(nn.Module):
    """4D grid_sample を含む最小モジュール"""
    def forward(self, im, grid):
        return F.grid_sample(im, grid, align_corners=False)

torch.manual_seed(0)
im = torch.randn(1, 8, 128, 128, device="cuda")
grid = torch.rand(1, 128, 128, 2, device="cuda") * 2 - 1
model = PlanarWarp().eval().cuda()

torch.onnx.export(model, (im, grid), "planar_warp.onnx",
                  input_names=["im", "grid"], output_names=["y"],
                  opset_version=20, dynamo=True)
build_engine("planar_warp.onnx", "planar_warp.plan", fp16=False)
runner = TRTRunner("planar_warp.plan")
trt_out = runner.run({"im": im, "grid": grid})["y"]

原因を突き止めるために、TensorRT の出力を、PyTorch の `F.grid_sample` の全解釈と総当たりで突き合わせました。mode（bilinear / nearest）× align_corners（True / False）× padding_mode（zeros / border / reflection）の全 12 通りです。

for mode, align, pad in itertools.product(
        ["bilinear", "nearest"], [False, True], ["zeros", "border", "reflection"]):
    ref = F.grid_sample(im, grid, mode=mode, align_corners=align, padding_mode=pad)
    print(mode, align, pad,
          (trt_out - ref).abs().max().item(),   # 最大絶対誤差
          torch.equal(trt_out, ref))            # ビット単位の一致判定

結果がこちらです。

TensorRT の出力は、`mode='nearest', align_corners=False` の結果と `torch.equal` が True、つまりビット単位で完全一致しました。 一方、本来あるべき bilinear との差は 3.1 以上あります。バイリニア補間が最近傍補間にすり替わると、出力は「なんとなくジャギーになる」程度の変化しか見せません。ワーピング処理の中に埋もれていると、目視ではまず気づけません。

なぜ起きるか — opset 16 と 20 で切り分ける

ONNX ファイルのノード属性を確認すると、こう書かれていました。

ONNX GridSample attributes: {'align_corners': 0, 'mode': 'linear', 'padding_mode': 'zeros'}

mode は opset 20 の仕様どおり正しく linear と書かれています。ここで重要な事実があります。ONNX の GridSample は、opset 16 では補間モード名が `bilinear` で、opset 20 で `linear` へ改名されました。そして TensorRT の公式ドキュメント上、GridSample の linear 補間はサポート対象です。つまり「TensorRT が linear をサポートしない」わけではない。怪しいのは opset 20 の新しい属性名を、取り込み（parser）がどう解釈しているかです。

そこで、同じモデル・同じ入力を opset 16 と 20 の両方で export して比較しました。

同じ TensorRT・同じモデルで、opset 16 なら正しく、opset 20 だと nearest になる。この実測から、当環境の TensorRT 10.16 の ONNX 取り込み経路が、opset 20 で導入された mode='linear' を正しく線形補間へ対応づけられず、nearest へフォールバックしている可能性が高いと強く推定できます（ONNX 仕様でも TensorRT のドキュメント上でも linear はサポート対象・既定側の値なので、「nearest が既定だから」ではありません。parse 後のレイヤ属性や parser 実装までは確認していないため、発生箇所の断定はしていません。将来のバージョンで修正される可能性もあります）。

回避策 — 簡単な順に 3 つ

回避策 1: opset 16 で export する（最も簡単・実測済み）

上の表のとおり、opset 16 で export すれば当環境では正しく bilinear になります。5D が必要（opset 20 が必須）でない限り、これで十分です。

回避策 2: `grid_sample` を基本演算に分解する（TensorRT 実行まで実測済み）

opset 20 を使う事情がある場合や、演算そのものを TensorRT 任せにしたくない場合は、その演算を、TensorRT で数値実績のある基本演算だけで数学的に等価に組み直す手があります。バイリニア補間は要するに「4 近傍を取ってきて重み付き平均する」だけなので、Floor / Clamp / Gather / 四則演算に分解できます。

回避策 3: カスタムプラグイン（後編で扱います）

import torch
import torch.nn.functional as F

def bilinear_grid_sample(im, grid, align_corners=False):
    """F.grid_sample(im, grid, mode='bilinear', padding_mode='zeros') の forward 推論を再現する実装。

    export 時だけこちらへ差し替えて使う。有限値の grid を前提とし、
    NaN/Inf・backward・border/reflection・5D 入力は対象外。
      im:   (N, C, H, W)
      grid: (N, Hg, Wg, 2)  値域 [-1, 1]（x, y の順）
    """
    n, c, h, w = im.shape
    gx, gy = grid[..., 0], grid[..., 1]

    # 正規化座標 [-1, 1] → ピクセル座標
    if align_corners:
        x = (gx + 1) / 2 * (w - 1)
        y = (gy + 1) / 2 * (h - 1)
    else:
        x = ((gx + 1) * w - 1) / 2
        y = ((gy + 1) * h - 1) / 2

    x0, y0 = torch.floor(x), torch.floor(y)
    x1, y1 = x0 + 1, y0 + 1

    # 4 近傍の重み
    wa = (x1 - x) * (y1 - y)
    wb = (x1 - x) * (y - y0)
    wc = (x - x0) * (y1 - y)
    wd = (x - x0) * (y - y0)

    # padding_mode='zeros' の再現:
    # 1px のゼロパディングを張り、インデックスを [-1, size] に clamp してから +1 する。
    # どれだけ範囲外へ外れても、値 0 のパディング画素を参照する形に落ちる。
    im_p = F.pad(im, (1, 1, 1, 1), mode="constant", value=0.0)
    x0i = (x0.clamp(-1.0, float(w)) + 1).long()
    x1i = (x1.clamp(-1.0, float(w)) + 1).long()
    y0i = (y0.clamp(-1.0, float(h)) + 1).long()
    y1i = (y1.clamp(-1.0, float(h)) + 1).long()

    wp = w + 2
    im_flat = im_p.reshape(n, c, -1)          # (N, C, (H+2)*(W+2)) に平坦化

    def gather(yi, xi):
        # ONNX / TensorRT との対応を確実にするため GatherElements(dim=2) の形に寄せる
        idx = (yi * wp + xi).reshape(n, 1, -1).expand(-1, c, -1)
        return torch.gather(im_flat, 2, idx)

    va, vb, vc, vd = gather(y0i, x0i), gather(y1i, x0i), gather(y0i, x1i), gather(y1i, x1i)

    hg, wg = grid.shape[1], grid.shape[2]
    out = (va * wa.reshape(n, 1, -1) + vb * wb.reshape(n, 1, -1)
           + vc * wc.reshape(n, 1, -1) + vd * wd.reshape(n, 1, -1))
    return out.reshape(n, c, hg, wg)

この分解版は、PyTorch 上のセルフテストだけでなく、実際に ONNX export → TensorRT build → 実行まで通して検証しました。三者比較の実測はこうです。

TensorRT に載せても正しく bilinear のまま動く、というところまで確認できています。範囲外のグリッドを含むセルフテストも一緒に書いておくとよいでしょう。

torch.manual_seed(0)
dev = "cuda:0"
src = torch.randn(4, 3, 256, 256, device=dev)

cases = {
    "uniform_pm1":   torch.rand(4, 256, 256, 2, device=dev) * 2 - 1,
    "outside_pm1.5": torch.rand(4, 256, 256, 2, device=dev) * 3 - 1.5,   # 範囲外を含む
}
ys, xs = torch.meshgrid(torch.linspace(-1, 1, 256, device=dev),
                        torch.linspace(-1, 1, 256, device=dev), indexing="ij")
ident = torch.stack([xs, ys], dim=-1).expand(4, -1, -1, -1)
cases["identity_plus_flow"] = ident + torch.randn(4, 256, 256, 2, device=dev) * 0.05

for name, grid in cases.items():
    ref = F.grid_sample(src, grid)          # bilinear / zeros / align_corners=False
    got = bilinear_grid_sample(src, grid)
    ma = float((ref - got).abs().max())
    print(f"[selftest] {name}: max_abs={ma:.3e} -> {'PASS' if ma < 1e-5 else 'FAIL'}")

ポイントは、この差し替えを export 用のラッパの中だけで行うことです。 本番のモデルコードには一切手を入れずに済みます。

第3部: 同じ世代でも、GPU の機種が違うとエンジンは壊れ得る

症状

ある GPU でビルドしたエンジンを、同じ Blackwell 世代（sm_120）の別の機種へ持っていって実行しました。動きはします。速度も出ます。

しかし出力が壊れていました。

TensorRT のログにはこう出ていました（後半の 1 文をそのまま引用します）。

[TRT] [WARNING] Using an engine plan file across different models of devices is not
supported and is likely to affect performance or even cause errors or deadlock.

前段にはもう 1 本、「このデバイスが持つ SM（Streaming Multiprocessor）の数より、このエンジンが要求する SM 数のほうが多い。デッドロックの可能性が高い」という趣旨の警告も出ます。それでも `deserialize` は成功し、`execute_async_v3` も `True` を返し、処理は止まりません。

なぜ起きるか

前編で書いたとおり、TensorRT はビルド時に実機でカーネルを実測し、最速の実装を選びます。既定設定のエンジンは、Compute Capability だけでなく、ビルドした GPU の複数のハードウェア特性（SM 数・共有メモリ・L2 キャッシュなど）を前提として実行計画を組んでいます。別機種ではこれらが異なるため、性能低下だけでなく実行上の問題につながる可能性があり、TensorRT 自身も不一致を検出して警告を出します。

「Compute Capability が同じなら互換」は誤りです。 同じ sm_120 同士でも、機種が違えば別物として扱う必要があります。

ここが本当に厄介なところ

今回、この状況を再現する検証もしてみました。SM 数の多い機種でビルドしたエンジンを、少ない機種でロードして実行したのです。結果はこうでした。

警告は 2 本とも出ました。しかし出力は、ビルドした機種での結果と一致しました（最大絶対誤差は実測値そのものが 0.0。ただし `torch.equal` までは確認していません）。

つまり、小さくて単純なモデルでは、警告を無視しても「動いてしまう」のです。これが最悪です。開発中に一度「動いた」経験をしてしまうと、この警告はただのノイズに見えます。そして本番の複雑なモデルに載せ替えたとき、CUDA エラーを吐きながら壊れた出力を流し続ける、という形で牙を剥きます。私たちが実際に経験したのは後者でした。

なお公式ドキュメントは、同一アーキテクチャの別 GPU でも機能上は動き、小さな性能低下に留まる場合があるとも説明しています。それでも私たちは、本番運用では この警告を fail-fast の対象（＝出たら止める）として扱う方針にしています。壊れる条件が特定できていない以上、「今は動いているから大丈夫」に賭けるべきではない、という判断です。

回避策

1. エンジンは Compute Capability 単位ではなく「GPU 機種」単位で管理・ビルドする — 保管ディレクトリを sm_120/ で切るだけでは足りません。機種名まで含めて分けます
2. ビルド時に「GPU 製品名・Compute Capability・SM 数・TensorRT / CUDA バージョン」をメタデータ（sidecar JSON など）として保存し、起動時に実行環境と照合して、不一致なら deserialize する前に拒否する — ここが実効的な防波堤です。注意すべきは、`execute_async_v3` の戻り値チェックはこの罠の検出には使えないことです。今回の検証でも、機種不一致の状態で True が返りました
3. TensorRT の警告を本番ではエラー扱いにする — ロガーの WARNING を握りつぶさず、上の照合と併せて fail-fast にします
4. 複数機種への配布がどうしても必要なら、hardware compatibility mode（`SAME_COMPUTE_CAPABILITY` など）でビルドする — 同じ Compute Capability の GPU 間で使うための正式な仕組みです。ただし性能や機能に制約が生じるため、速度と数値を別途検証してから使ってください

第4部: fp32 でビルドしても、TF32 が候補に入る

症状

FP16 tactic を許可した設定では精度が足りなかったモジュールを、FP16 tactic を許可しない FP32 設定でビルドし直しました。それでも PyTorch との一致度が期待より伸びません。しかも、ビルドし直すたびに一致度が微妙に変動する。合格ラインを超えたり超えなかったりします。

なぜ起きるか

TensorRT は fp32 のテンソルに対する畳み込みや行列積について、既定で TF32 tactic の使用を「許可」しています。 TF32 は仮数部を 10 bit に削った高速な形式で、Ampere 以降の Tensor Core で使われます。すべての fp32 演算が TF32 になるわけではなく通常の fp32 実装が選ばれる場合もありますが、「fp32 でビルドした＝すべて fp32 で走っている」という思い込みは成り立ちません。

ビルドごとに結果が揺れた原因として考えられるのが、ビルド時の計測ノイズです。TensorRT のビルドは実機計測に基づくため、性能の近い実装候補からビルドごとに異なる tactic が選ばれる場合があります（公式ドキュメントにもこの説明があります）。ただし今回、実際に選択された tactic の比較までは行っていません。

回避策と、意外な副産物

忠実度を厳密に検証するエンジンでは、TF32 を明示的に無効化します。

config = builder.create_builder_config()
config.clear_flag(trt.BuilderFlag.TF32)     # ★ TF32 tactic を候補から外す

実測結果がこちらです。

最大絶対誤差は 2.55e-04 から 6.26e-07 へ、3 桁改善しました。

そして面白いことに、今回の 1 組のビルドでは、TF32 を無効にした側のほうが速い結果になりました（0.874ms → 0.772ms）。別の tactic が選ばれた可能性はありますが、原因の切り分け（選択 tactic の比較）まではしていません。ビルド時の計測ノイズの影響も受け得る差なので、この約 12% を一般的な傾向と読まないでください。それでも「TF32 を切ると必ず遅くなる」という思い込みで試さないのはもったいないので、速度もその構成で実測してください。TF32 を無効にしても、演算順序や tactic の違いによる PyTorch との数値差が完全になくなるわけではない点も添えておきます。

第5部: ONNX export で引数が入れ替わっていた（最も泣けてきた事故）

最後は、TensorRT の問題ではなく 私たち自身のミスです。しかし、これがシリーズ中で最も発見に時間がかかりました。同じ構造の事故は誰にでも起こりうるので共有します。なお本事例は実務モデルで発生したもので、機密上モデルは公開できず、本記事用のダミーモデルでの再現実験は行っていません。

症状

あるモジュールを TensorRT 化したところ、入力によって出力の壊れ方が変わるという奇妙な症状が出ました。ある条件では完璧に一致するのに、別の条件では明確に劣化します。しかも劣化の量は入力の「動きの大きさ」に比例して拡大していました。

fp16 でも fp32 でも、TF32 を切っても、劣化量は変わりません。この時点で、単純な精度差より構造的な問題を強く疑いました。

なぜ起きたか

torch.onnx.export に渡した引数の順序が、モデルの forward の引数順と食い違っていました。

# forward の定義:   forward(self, feature, kp_driving, kp_source)
# export で渡したもの:      (feature, kp_source, kp_driving)   ← 2 番目と 3 番目が逆
torch.onnx.export(model, (feature, kp_source, kp_driving), "m.onnx", ...)

位置引数なので、Python は何も文句を言いません。 export は成功し、ONNX ファイルも生成され、TensorRT のビルドも通り、実行もできます。ただ、モデルの中で 2 つの入力の役割が入れ替わったまま固定された ONNX ができあがります。

内部の計算が「基準 − 入力A + 入力B」のような差分の形になっていたため、誤差はちょうど 2 ×（2 つの入力の差） になります。だから「差が小さい入力では一致し、差が大きい入力ほど盛大に壊れる」という症状になりました。

なぜ発見が遅れたか — 「自己再演」検証の落とし穴

いちばんの問題はここです。当時の検証は、同じデータを両方の入力に与える形で行っていました。この条件では 2 つの入力が等しいので、入れ替わっていても結果は完全に一致します。テストは堂々と合格していました。

これを私たちは 「自己再演パリティ」の罠と呼んでいます。入力と基準が一致してしまう条件だけで等価性を検証すると、引数の取り違えのような構造的なバグが完全に無害化されます。

見つけ方 — 犯人が TensorRT か ONNX かを切り分ける

このとき有効だったのが、onnxruntime を使った切り分けです。

1. まずモデルを段階的に分割し、どこで数値がズレ始めるかを二分探索する（中間テンソルの比較）
2. ズレる部分グラフが特定できたら、同じ ONNX を onnxruntime の CPU 実行で走らせる
3. onnxruntime でも同じ方向にズレるなら、まず ONNX グラフ・export 時の入力束縛・演算の仕様差を疑う。PyTorch と onnxruntime が一致して TensorRT だけズレるなら、TensorRT の parser・エンジン・実行側の設定を優先して疑う

これは犯人を論理的に確定する手続きではなく、どこから先に調べるかを決める切り分けです（onnxruntime 側にも実装差はあり得ますし、TensorRT 側の入力名や dtype の渡し方の問題ということもあります）。それでも調査の初動を大きく変えてくれます。今回のケースでは onnxruntime でも同じだけ食い違ったため export 側を先に調べ、位置引数の取り違えをコード上で特定しました。

なお、層ごとの比較には polygraphy の全層比較（mark all）が便利ですが、大きなモデルではメモリを使い切って落ちます。実務では、疑わしい部分だけを切り出す二分探索のほうが確実でした。

回避策 — kwargs による keyword 束縛

export への引数の受け渡し自体を keyword にします。 torch.onnx.export には位置引数用の args とは別に、keyword 入力として渡す正式な `kwargs` 引数があります。これを使えば、タプルの順番という概念そのものが消えます。

# 課題: args はタプルであり、位置順で束縛される。forward の引数順を
#       取り違えても export は成功してしまい、入力の役割が入れ替わった
#       ままの ONNX が生成される（input_names は名前を付けるだけで、
#       意味上の対応を保証しない）
# 対策: kwargs 引数で「名前 → テンソル」を明示的に対応づける
torch.onnx.export(
    model,
    args=(),
    kwargs={
        "feature": feature,
        "kp_source": kp_source,
        "kp_driving": kp_driving,
    },
    f="m.onnx",
    input_names=["feature", "kp_source", "kp_driving"],
    output_names=["y"], opset_version=20, dynamo=True,
)

修正後、劣化は完全に消えました。

沈黙劣化を検出する検証設計

5 つの罠を並べると、共通する対策が見えてきます。

1. 速度より先に数値を測る

順序を逆にすると、「速くなった」という良い知らせが先に来てしまい、数値の検証が形式的になります。数値が合っていない高速化には価値がありません。

2. 乱数入力の一致を信用しない — 実データで検証する

これは実測でも裏づけが取れました。LayerNorm と GELU を重ねたブロックを FP16 tactic 許可でエンジン化し、入力のレンジだけを変えて誤差を測ったところ、次のようになりました（比較の基準は PyTorch fp32。表の「FP16 許可 / 不許可」はいずれも TF32 は既定＝許可のままです）。

入力スケールを広げると、FP16 設定の最大絶対誤差は大きく増えました（ただし増加は入力倍率への単純比例ではありません。LayerNorm がスケールを正規化するためです）。一方 nRMSE は 8.9e-04 から 2.5e-04 へむしろ低下しており、少なくとも入力スケールとともに悪化してはいません。つまり絶対誤差と正規化誤差では、同じ結果でも評価の見え方がまったく違います。ここから言えるのは、「絶対誤差いくつ以下なら OK」という合格バーを標準正規乱数だけで決めると、実データのレンジでは簡単に破られるということです。

さらに私たちの実モデルでは、これが単なる誤差の増大では済まず、実データを入れた瞬間に全出力が NaN になるという形で現れました（LayerNorm 直前で中間値が fp16 の表現範囲を超えたためです）。対処は、そのモジュールでは FP16 tactic を許可せず、FP32 設定でビルドすることでした。

3. 「自己再演」で等価性を検証しない

第5部のように、入力と基準が一致する条件だけのテストは、構造的なバグを完全に隠します。検証データには、実運用で起こりうる「差が大きいケース」を必ず含めてください。

4. 犯人の切り分けは「PyTorch / onnxruntime / TensorRT」の三点測量で

• PyTorch と onnxruntime が一致し、TensorRT だけズレる → TensorRT のセマンティクス・カーネルを疑う（第2部）
• onnxruntime でもズレる → ONNX、つまり export を疑う（第5部）

この切り分けができると、調査時間が桁で変わります。

5. 疑わしい演算は「1 個だけ」切り出してテストする

モデル全体で「なんとなくズレている」を追うのは非効率です。第2部は grid_sample 1 個を切り出して総当たり照合したことで、一発で確定しました。

6. 精度を切り替えて症状が変わるかを見る

fp16 / fp32 / TF32 を切り替えても劣化量がほとんど変わらないなら、丸め誤差よりも入力束縛や演算セマンティクスなど、構造的な問題を優先して疑います。証明ではありませんが、調査の優先順位を決める判定として非常に有効でした。

7. 失敗を握りつぶさない仕組みを入れる

execute_async_v3 の戻り値チェック、エンジンとデバイスの整合検査、部品が欠けていたら起動を拒否する設計。「一部が壊れたまま正常に見える」状態を作らないことが、沈黙劣化に対する最後の防波堤です。

まだ確かめていないこと

• `mode='linear'` が nearest になる件の根本箇所 — opset 16/20 の比較から parser 段階の解釈が原因と強く推定していますが、parser のソースコードや parse 直後のレイヤ属性までは確認していません。また検証は TensorRT 10.16.1.11 の 1 バージョンのみで、将来のバージョンで修正される可能性があります
• 機種またぎで壊れる条件 — 今回のダミーモデルでは警告が出ても出力は一致しました。「どの程度の規模・構造から壊れ始めるか」は特定できていません
• int8 量子化での同種の問題 — 本記事は fp16 / fp32 / TF32 のみを扱っています

まとめ

一言でまとめると、「TensorRT への移行パイプラインでは、『ビルドが通った』も『実行できた』も『速くなった』も、出力が正しいことを一切保証しない」ということです。

だからこそ、速度を測る前に数値を測り、乱数ではなく実データで測り、ズレたら三点測量で犯人を切り分け、失敗を握りつぶさない仕組みを入れておく。これが TensorRT を本番に載せるための最低条件だと考えています。

次回（後編）は、前編で保留にした最大の宿題、TensorRT がネイティブに対応していない 5D grid_sample を、カスタムプラグインで通す話をお届けします。新しい CUDA / TensorRT 世代でこれをビルドするには、いくつも越えるべきものがあります。手元の nvcc が Blackwell 向けのコードを生成できないときにどうするか、pip で入れた TensorRT には開発用ヘッダが入っていないという問題、そしてプラグインの fp16 カーネルが数値破綻するという、またしても沈黙劣化に近い話です。

それでは、また次回、お会いしましょう！

参考資料（一次情報・主要ソース）

• NVIDIA TensorRT ドキュメント（Developer Guide / Release Notes）
• ONNX Operators: GridSample（mode / align_corners / padding_mode の仕様）
• PyTorch: torch.nn.functional.grid_sample
• NVIDIA/TensorRT issue #3890: 5D GridSample のネイティブ対応要望
• NVIDIA: TensorFloat-32（TF32）の解説
• polygraphy（TensorRT のデバッグ・比較ツール）
• 当社関連記事: 2026年 NVIDIA GPU 一発検索ツール

こんにちは！

2026年7月24日、AnthropicからClaude Opus 5がリリースされました。

Opus 4.8（5月28日リリース）からわずか2ヶ月での世代交代です。このあたりのスピード感、加速していますね。

さて、当ブログではClaude Opus 4.7 完全ガイド、Claude Opus 4.8 完全ガイドとOpusの世代を追いかけてきましたが、今回のOpus 5は過去2回の「4.x内のアップデート」とは立て付けが根本的に違います。

何が違うのか。まず、Opus 5は「最上位モデル」ではありません。

Anthropicのラインナップには2026年6月9日リリースのClaude Fable 5が最上位として存在し、Opus 5はその下位、Sonnet 5の上位という「中上位」ポジションで投入されました。

Opusという名前が「最上位ティア」を意味した時代は、Fable 5の登場で終わっています。

そのうえでAnthropicはOpus 5を「Fable 5のフロンティア級の賢さに、半額で迫るモデル」と位置づけ、一部ベンチマークではFable 5を上回るスコアさえ公表しています。

価格はOpus 4.8と同じ入力$5・出力$25。

つまり「最上位ではないが、実務ではこれが本命」という、いままでのOpusにはなかったキャラクターです。

しかも思い出してほしいのですが、Fable 5は6月12日に米国政府の指令で一時提供停止になり、7月1日に復帰するという波乱を経ています（経緯はFable 5・Mythos 5 提供停止の経緯で詳しく書きました）。

この事件の中心にあった「安全分類器」が、実はOpus 5にも搭載されました。

Opus 4.8にはなかったものが載ったわけで、これは移行時に必ず知っておくべき変化です（第7章で詳しく扱います）。

本稿は長編なので、頭から通読する必要はありません。気になる章だけ拾い読みしてください。出典は記事末にまとめてあります。

想定読者は、Opus 4.8からの移行を検討しているエンジニア、Fable 5とOpus 5のどちらを使うべきか判断したいテックリード、Claude Codeをチームで運用しているリードエンジニア、そしてAPI利用のコスト最適化を考えている方です。

目次

第1部　Claude Opus 5とは何か

• 1. Claude 5ファミリーの中でのOpus 5の位置づけ
• 2. Claude Opus 5の基本仕様
• 3. ベンチマークで見る「Fable 5超え」の中身
• 4. thinkingまわりで変わる2つのAPI破壊的変更
• 5. 移行チェックリスト（公式ガイドより）
• 6. 新機能・関連機能まとめ

第2部　APIで使うときの注意点

• 7. 4.8にはなかった安全分類器が搭載された
• 8. Effortの使い分け
• 9. エージェントに予算感覚を持たせるTask budgets（beta）
• 10. Opus 5を最大限引き出すプロンプティング

第3部　Claude Codeで使うOpus 5

• 11. Claude CodeでOpus 5を使う前提
• 12. Claude Codeのeffort設定は引き継ぎ挙動に注意
• 13. Fast modeの変更点
• 14. フラグされたらどうなるか、自動モデルフォールバックの仕組み
• 15. 1Mコンテキストとopusplan
• 16. 日常運用のリズム

4.8からのアップデート、ざっくり

前回記事で扱ったOpus 4.8から、Opus 5では主に次の点が変わりました。

詳細は各章で扱いますが、まず全体像です。

段階的改善ではなく「step-change（段差のある改善）」

公式ドキュメント自身が4.8比を「incrementalではなくstep-change」と表現しています。深い推論・長時間エージェンティックタスク・test-time compute scalingで最大の伸びです（第3章）。

thinkingがデフォルトON

4.8ではthinkingフィールド無しのリクエストは思考なしで動きましたが、Opus 5では同じリクエストが思考ありで動きます。max_tokensの見直しが必要です（第4章）。

thinking無効化はeffort `high`以下でのみ可能（破壊的変更）

thinking: {type: "disabled"}とeffort xhigh/maxの組み合わせは400エラーになります（第4章）。

effortの推奨スタート地点が変化

APIデフォルトは従来どおりhighのままです。公式ガイドの推奨が4.7/4.8の「コーディングはxhighで開始」から、Opus 5では「highで開始し、要求の厳しい作業のみxhighへ」に変わり、low/mediumの積極活用が明記されました（第8章）。

Web Fetchサーバーツール非対応

Opus 4.8で使えるWeb FetchツールはOpus 5では利用できません（Web検索とは別機能です）。利用中のAPI統合は代替設計が必要です（第5章）。

安全分類器が搭載された

4.8にはなかったモデル固有のサイバー・生物学分類器がOpus 5には載っています。介入頻度はFable 5より約85%少ないとされますが、4.8からの移行では新しい制約になります（第7章）。

ナレッジカットオフが2026年5月

Fable 5・Sonnet 5（いずれも2026年1月）より新しく、現行ラインナップで最も新しい知識を持ちます（第2章）。

新機能・関連機能

会話途中のツール変更（beta）、fallbacksパラメータの"default"モード（beta）、Task budgets（beta）、キャッシュ最小長が512トークンに低下、などがあります（第6章・第7章・第9章）。

価格は据え置き

入力$5・出力$25のまま。Fast modeも$10/$50でOpus 4.8と同額です（第2章）。

Priority Tier非対応

Opus 4.8では使えたPriority TierがOpus 5では未サポートです。コミットメントがある組織は容量計画に注意してください（第5章）。

なお、Opus 4.8向けのコードはモデルIDの差し替えだけで動くとは限りません。

thinkingデフォルトの変化と、thinking無効化の制限という2つの挙動変更があるため、移行チェックリスト（第5章）を一度通すことをおすすめします。

第1部　Claude Opus 5とは何か

1. Claude 5ファミリーの中でのOpus 5の位置づけ

まず、2026年6月からの2ヶ月弱でAnthropicのラインナップがどう変わったかを整理します。

この期間、Anthropicは4つのモデルを立て続けに投入しました。

• 6月9日 Claude Fable 5 / Claude Mythos 5 リリース（新設の最上位「Mythosクラス」。ベンチマーク解説）
• 6月12日 米商務省の輸出管理指令により両モデルの提供を全世界で停止（経緯の詳細）
• 6月26日 Mythos 5が審査済み米国組織限定で一部復帰
• 6月30日 輸出規制が解除。同日、Claude Sonnet 5リリース（導入価格$2/$10、2026年8月31日まで。以降$3/$15）
• 7月1日 Fable 5がclaude.ai・Claude Code等で全面復帰
• 7月24日 Claude Opus 5リリース。同日、Opus 4.7のFast modeが提供終了

この結果、現在のラインナップは上から Fable 5（$10/$50）、Opus 5（$5/$25）、Sonnet 5（$3/$15）、Haiku 4.5（$1/$5）という4層構造です。

Opus 5の公式な位置づけは「complex agentic coding and enterprise work（複雑なエージェンティックコーディングとエンタープライズ業務）向け」です。

AnthropicはこれをClaude Maxの新デフォルトモデル、Proプランで使える最上位モデルに据えました。

「日常の主力はOpus 5、真にフロンティアな仕事だけFable 5」という使い分けをAnthropic自身が推奨する構図です。

（出典はAnthropic公式モデル一覧。価格・カットオフは2026年7月27日時点）

見落とされがちですが重要なのがナレッジカットオフです。

Opus 5のreliable knowledge cutoffは2026年5月で、
Fable 5・Sonnet 5の2026年1月より4ヶ月新しく、現行ラインナップ最新です。

新しめのライブラリやAPIを扱う場面では、「上位」のFable 5より新しい知識を持っている可能性があります。

ただしカットオフの新しさが個別仕様の正確性を保証するわけではありません。後述のとおりOpus 5はWeb Fetchサーバーツール非対応（第5章）なので、最新情報の取り込みはWeb検索ツールや自前の取得で補い、公式ドキュメントとの照合は引き続き必要です。

LLM各社の料金体系の比較はLLM API価格まとめ、Fable 5のコスト問題についてはFable 5のコストと展望も参考にしてください。

Fable 5は「トークン消費が激しい」という利用者の不満が広く報じられており、Fortuneによれば、Opus 5がトークン効率を前面に出すのはこの不満への回答でもあります。

7月9日にリリースされたOpenAIのGPT-5.6も経済的なトークン消費を売りにしており、「賢さ」から「賢さとコストの釣り合い」へ競争軸が移っていることがわかります。

2. Claude Opus 5の基本仕様

4.8から引き継がれた仕様も多い一方、「1Mがデフォルトかつ最大で、そもそも小さいコンテキストのバリアントが存在しない」「thinkingがデフォルトON」の2点は世代の切り替わりを感じさせます。

なおclaude-opus-5はエバーグリーンなポインタではなく固定スナップショットです（Claude 4.6世代から続く日付なしID方式）。

3. ベンチマークで見る「Fable 5超え」の中身

Anthropicのローンチ発表は、複数のベンチマークで「Opus 5がFable 5を上回る」と主張しています。

当ブログの流儀に従い、誰が測った数値かを区別しながら見ていきます。

Frontier-Bench v0.1（Anthropicによる内部実行）

System Cardの評価サマリー表でOpus 5が43.3%と比較対象モデル中トップ。Fable 5の33.7%、Opus 4.8の18.7%を大きく上回り、4.8比では2倍超です。しかもタスクあたりコストは低いとされます。

ローンチ時の公式チャートにはeffortレベル別の複数値も示されているため、43.3%がOpus 5のeffort別ピーク値とは限りません。

ARC-AGI 3（ARC Prizeによる検証済み外部評価）

Opus 5はhigh effortで30.16%（公表時の丸め値30.2%）。次点とされるGPT-5.6 Solの7.8%の約3.9倍です（Anthropicの発表文は「3倍」と控えめに表現しています）。

Opus 4.8は1.5%とほぼゼロでした。なお評価期間が短かったため、Opus 5のmaxはARC-AGI 3では未評価です。

CursorBench 3.2（Cursorによる外部評価）

max時にOpus 5が70.0%、Fable 5が70.5%と0.5ポイント差。タスクあたり平均コストはOpus 5の$8.23に対しFable 5は$17.32と2倍超です。

ただしCursor自身が「小さなスコア差は統計的に有意でない可能性がある」と注記しています。

OSWorld 2.0（コンピュータ操作。Anthropic評価、System Card記載）

70.57%（5回実行の平均初回成功率）でOpus 4.8の55.7%から大幅改善。Fable 5のベスト結果を約3分の1のコストで上回るとされます。

Zapier AutomationBench（外部の評価提供者による結果）

合格率が次点モデルの約1.5倍です（同等のタスクあたりコストで）。

ライフサイエンス（Anthropic自身の評価）

有機化学タスクでOpus 4.8比+10.2ポイント、タンパク質予測で+7.7ポイント。AnthropicはOpus 5を「科学研究向けに最も高性能な一般提供モデル」と押し出しています。

注意点を2つ挙げます。

第一に、数値の帰属は3種類に分かれます。(a) Anthropicが自社で実行した評価（Frontier-Bench・OSWorld・ライフサイエンス）、(b) ベンチマーク提供者が実行・掲載した外部評価（ARC Prize・Cursor・Zapier）、(c) それらを報じた報道です。

(b)は自己申告ではありませんが、第三者コミュニティによる独立追試とも別物です。

第二に、「Fable 5超え」はすべてのベンチマークの話ではありません。

Anthropic自身、最高難度の長時間自律タスクではFable 5を推奨し続けており、サイバーセキュリティのエクスプロイト能力では「Mythos 5に及ばない」と明言しています。

ブラインド投票（Arena系）やLLMランキングでどう出るかは、独立評価が出揃ってからの答え合わせになります。

TechCrunchは、Anthropicが強調した特性として「自分の成果物を検証し、成功するまで丁寧にイテレーションする」点を挙げています。

早々に勝利宣言せず、検証して直す。これは後述するプロンプティングの変化（自己検証と重複する再検証指示を外す。第5章・第10章）と表裏一体の、Opus 5の性格を象徴する変化です。

4. thinkingまわりで変わる2つのAPI破壊的変更

Opus 4.7から4.8のときは「モデルID差し替えだけで動く」移行でした。

今回はAPIパラメータ上の破壊的変更が2つあります。加えて機能面では、前述のWeb FetchとPriority Tierの非対応という実質的な非互換もあります（第5章のチェックリストで扱います）。

変更その1、thinkingがデフォルトONになった

Opus 4.8ではthinkingフィールドを付けないリクエストは思考なしで動きました。

Opus 5では同じリクエストが思考ありで動きます（モデルがターンごとに思考の要否と深さを判断するアダプティブシンキング）。

ワイヤ上の値は変わっておらず、thinking: {type: "adaptive"}を明示しても同じ挙動です。

実務上の注意はmax_tokensです。

max_tokensは思考と本文の合計に対するハードリミットなので、4.8で思考なしで動かしていたワークロードをそのまま移すと、思考トークンが加わったぶん本文が途中で切れる（stop_reason: "max_tokens"）ことがあります。

thinkingなし前提で小さめのmax_tokensを設定していた箇所は見直してください。

変更その2、thinking無効化はeffort `high`以下のみになった

旧挙動を維持したい場合はthinking: {type: "disabled"}を渡せますが、Opus 5ではeffortレベルがhigh以下のときしか受け付けられません。

thinking: {type: "disabled"}とeffort xhigh/maxの組み合わせは400エラーになります。

4.8ではこの組み合わせが通っていたので、移行前に該当リクエストを洗い出しておく必要があります。

チェックはリクエスト単位で毎回行われるため、「会話の前半は通っていたのに、途中でeffortを上げた瞬間に400」ということも起こります。

# 4.8では通るが、Opus 5では400エラーになるリクエスト
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "disabled"},
    output_config={"effort": "xhigh"},   # disabled と xhigh の組み合わせが不可
    messages=[{"role": "user", "content": "..."}],
)

# 対処A thinkingフィールドを外す（デフォルトの思考ありに戻す）
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    output_config={"effort": "xhigh"},   # thinking はデフォルトON
    messages=[{"role": "user", "content": "..."}],
)

# 対処B thinking無効を維持して effort を high 以下へ
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "disabled"},
    output_config={"effort": "high"},    # high / medium / low なら可
    messages=[{"role": "user", "content": "..."}],
)

さらに公式ドキュメントは、thinkingを無効化した場合の副作用を明記しています。

思考なしのOpus 5は、まれにツール呼び出しをtool_useブロックではなく本文テキストとして書いてしまうことがあります。呼び出しは実行されず、エージェントループでは漏れたテキストが会話履歴に残って後続ターンにも影響します。

<thinking>等の内部XMLタグを可視出力に混ぜてしまうこともあります。

公式の推奨は「thinkingは有効のまま、コストは低effortで制御する」です。

ほとんどのタスクで「thinking有効かつlow effort」のほうが「thinking無効」より同等コストで良い結果になるとされています。どうしても無効化が必要な統合向けのプロンプト緩和策は第10章で扱います。

5. 移行チェックリスト（公式ガイドより）

公式移行ガイドのチェックリストを、実務の順序に並べ直したものです。

1. モデル名をclaude-opus-4-8からclaude-opus-5へ更新する
2. Web Fetchサーバーツールを使っているリクエストを洗い出す。Opus 5では利用できないため、Web検索ツール・クライアント側での取得・該当処理だけ別モデルへルーティング、等の代替を設計する
3. thinkingフィールド無しで運用していたワークロードを洗い出す（Opus 5では思考ありで動く）。max_tokensを見直すか、thinking: {type: "disabled"}とeffort high以下で旧挙動を維持する
4. thinking: {type: "disabled"}とeffort xhigh/maxを併用しているリクエストを修正する（400エラーになる）
5. effort設定を白紙から再評価する。旧モデルから持ち越さず、自分のevalsでeffortスイープを取り直す。low/mediumはコスト・レイテンシ制御として積極的に試し、maxは能力優先タスクで試す価値あり。xhigh/maxで走らせるならmax_tokensは64k以上から
6. キャッシュ境界付近のプロンプトを確認する（512トークン以上でキャッシュ可能に。4.8では1,024）
7. stop_reason: "refusal"のハンドリングを確認し、fallbacks: "default"（beta）の採用を検討する（第7章）
8. Priority Tierのコミットメントがある組織は容量計画を分けて立てる。Priority TierはOpus 5非対応で、Opus 4.8では引き続き利用可能
9. エージェンティックワークロードならTask budgets（beta）とmid-conversation tool changes（beta）を検討する（第9章・第6章）
10. 長さ・冗長性のプロンプトを再調整する。Opus 5は可視応答も成果物ドキュメントも長くなりがちで、effortを下げても短くならない（第10章）
11. 旧モデル向けの再検証指示（「最後に検証ステップを入れよ」「ダブルチェックせよ」「サブエージェントで検証せよ」等）を削除する。Opus 5は言われなくても自己検証するため、残すと過剰検証でトークンを浪費する。ただし、指定テストの実行・lint・型検査といったプロジェクト固有の受入条件は削除しない（第10章）
12. 自分のワークロードでコストとレイテンシを再ベースラインする

このうち5・10・11は「壊れないが最適でなくなる」系で、飛ばしてもエラーにはなりません。

ただし11（重複する再検証指示の削除）は公式が「品質を落とさずトークン削減」と明言している数少ない項目なので、優先度高めで対応する価値があります。

6. 新機能・関連機能まとめ

Opus 5で利用できる新機能・関連機能を整理します。

Opus 5と同時に追加された機能だけでなく、既存機能のOpus 5対応も含みます。詳細は該当章で扱います。

Mid-conversation tool changesは地味ながらエージェント開発者に効く変更です。

従来、ツールリストを変えるとキャッシュ済みプレフィックスが無効化されるため、セッションの最初に全ツールを渡しておくのが定石でした。

betaヘッダmid-conversation-tool-changes-2026-07-01を付けると、タスクの進行に応じてツールを段階的に公開したり退役させたりしても、それ以前のターンのキャッシュヒットが保てます。

4.8で入ったmid-conversation system messages（会話途中のシステムメッセージ追記）の続編と考えるとわかりやすい機能です。

第2部　APIで使うときの注意点

7. 4.8にはなかった安全分類器が搭載された

先に重要な事実を押さえてください。

Fable 5と同系のモデル固有安全分類器（サイバーセキュリティ・生物学）が、Opus 5にも搭載されました。

そしてOpus 4.8にはこの分類器は載っていません。

公式ドキュメントが分類器つきと明記しているのはFable 5とOpus 5だけです。フラグされたリクエストの逃がし先がOpus 4.8であること自体が、4.8に同じ分類器がないことの裏付けです。

なお4.8時代にも、プラットフォーム側のUsage Policyセーフガードの誤検知はありました。6月の記事で扱ったものがそれで、モデル固有分類器とは別の層の話です。

つまり4.8から移行するユーザーにとって、これは新たに加わる制約です。

「安全になった」という話ではなく、「分類器が付いてしまった。ただしFable 5ほど頻繁には介入しない」と読むのが正確です。

そのうえで、Fable 5の提供停止で業務が止まる経験をした直後という文脈では、Fable 5との違いにも実務上の意味があります。ポイントは4つあります。

(1) アライメント自体は歴代最良

Anthropicの自動挙動監査（automated behavioral audit）で、Opus 5のミスアライン挙動スコアは2.3（低いほど良い）。

Opus 4.8・Sonnet 5・Fable 5を含む近年のモデルで最良で、「最もアラインされたOpusであり、悪用に誘導されにくい」とAnthropicは主張しています（自己評価である点に留意してください）。

(2) 分類器の介入はFable 5比で約85%減（ゼロではない）

Fable 5はサイバーセキュリティ能力の高さゆえに強力な安全分類器を常時走らせており、これが正当なセキュリティ業務まで妨げるという不満がありました。

Opus 5では素のエクスプロイト能力をMythos 5より意図的に抑えたうえで、分類器の介入頻度を「Fable 5の約85%減」に抑えたとしています。

裏を返せば、4.8では起きなかったモデル分類器の介入が、Opus 5では一定頻度で起きるということです。

線引きとしては、ソースコードを対象とする脆弱性発見は許可する一方、バイナリを対象とした脆弱性スキャンやエクスプロイト生成はブロックする設計です。

防御的セキュリティのための特別枠であるProject Glasswing（Mythos 5の提供枠組み）についてはGlasswing解説記事を参照してください。

Cyber Verification Program（CVP）参加済みの企業・研究者は、制限が緩和された状態でOpus 5に即アクセスできます。

(3) フラグ時の自動フォールバック（API側）

分類器がリクエストをフラグしたとき、エラーで終わらせず別モデルに自動で流す選択肢が入りました。

fallbacksパラメータの新しい"default"モード（fallbacks: "default"）は、拒否カテゴリに応じてAnthropic推奨のフォールバックモデルを自動選択します。たとえばOpus 5のサイバー系拒否はOpus 4.8へ流れます。

従来の明示的なモデルリスト指定も引き続き可能で、"default"モードにはserver-side-fallback-2026-07-01ベータヘッダが必要です。

(4) データ保持の違い（公式ドキュメントで確認）

Anthropic公式の「API and data retention」ドキュメントは、30日データ保持が必須の「Covered Models」としてFable 5とMythos 5を明記しており、この2モデルはZDR（ゼロデータリテンション）では利用できません。Claude CodeのモデルピッカーにもZDR環境では出ません。

Opus 5はCovered Modelsに含まれておらず、ローンチ発表でも一般アクセスのOpus 5にモデル固有のデータ保持要件は課されていません。

したがってClaude APIでZDR契約を持つ組織は、ZDR適格な機能の範囲でOpus 5を利用できます。

ただしZDRは組織単位の契約で、Pro/Max等のコンシューマープラン自体は対象外です。Batch APIやコード実行などZDR対象外の機能もあるため、実際の適用範囲は契約条件と機能別のZDR適格性を確認してください。

まとめると、視点によって評価が分かれる変更です。

4.8ユーザーから見れば、分類器の搭載は純粋に制約の追加です。セキュリティ・生物学が絡むワークロードでは、4.8で通っていた処理が止まる可能性があります（4.8の継続利用も選択肢です。第16章）。

一方、Fable 5ユーザーから見れば、介入頻度は約85%少なく、モデル固有の30日保持要件がなく、サイバー系の拒否には自動フォールバックも用意されているぶん、明らかに扱いやすくなっています。

なお自動フォールバックはAPIではオプトインで、Opus 5の生物学カテゴリにはフォールバック先がない（第14章）等の制約はあります。将来の規制措置まで保証するものでもありません。

8. Effortの使い分け

effortはOpus 4.7以降、Opusを使いこなす最重要レバーであり続けています。

Opus 5では公式ガイドの推奨の書き方が変わりました。

誤解しやすいので先に整理すると、APIのデフォルトは4.7以降ずっとhighのまま変わっていません。変わったのは推奨スタート地点の記述です。

4.7/4.8の公式ガイドは「コーディング・エージェンティック用途はxhighで開始（Start with xhigh for coding and agentic use cases）」と明記していました。

Opus 5のガイドは「high（デフォルト）で開始し、evalsに基づいて調整せよ。要求の厳しいコーディング・エージェンティック作業ではxhighへステップアップ（Start with high, the default … step up to xhigh for demanding coding and agentic work）」という書き方になっています。

表にします。

書き方が変わった背景は、Opus 5の低effortの効率改善です。

公式は「lowとmediumが、上位設定のわずかなトークンとレイテンシで強い品質を出す」とし、「low/mediumをコストと応答時間の主要コントロールとして自由に（liberally）使え」とまで書いています。

4.8時代の「とりあえずxhigh」を無条件に持ち込むと、品質差が小さいのにトークンだけ倍増、ということになりかねません。

旧モデルからeffort設定を持ち越さず、自分のevalsでスイープを取り直すのが公式の明確な推奨です。

一方で上端のmaxは、追加effortを結果に変換する能力（test-time compute scaling）が歴代Opusで最も高いため、4.8時代より試す価値が上がっています。

CursorBenchでFable 5のピークに0.5ポイント差まで迫ったのもmax effort時の話です。

xhigh/maxで走らせるときは、思考とツール呼び出しの余地を確保するためmax_tokensを64k以上から始めて調整してください。

effortに関する固有の注意が2つあります。

effortは可視応答の長さを制御しない

Opus 5でeffortを下げると思考量は減りますが、ユーザー向け応答の長さは確実には短くなりません。応答を短くしたければプロンプトで明示します（第10章）。

effortは会話の途中で変えない

effortはレンダリングされるプロンプトに影響するため、リクエスト間で値を変えるとそれ以前のプレフィックスのプロンプトキャッシュが無効になります。キャッシュに依存する長いセッションでは、最初に決めた値を固定してください。

なお、thinking: {type: "disabled"}と併用できるのはhigh以下のみという制約（第4章）もeffort選択に影響します。

「思考は切りたいがeffortは上げたい」という構成はOpus 5では組めません。

9. エージェントに予算感覚を持たせるTask budgets（beta）

Opus 5でも利用できるbeta機能の中で、エージェント基盤の開発者にいちばん面白いのがTask budgetsです。

betaヘッダはtask-budgets-2026-03-13。対応はOpus 5 / Fable 5 / Mythos 5 / Opus 4.8 / 4.7で、Sonnet 5は非対応です。Opus 5固有の新機能ではなく、既存beta機能のOpus 5対応です。

output_config.task_budgetに{type: "tokens", total: N}を渡すと、思考・ツール呼び出し・ツール結果・出力を含むエージェンティックループ全体のトークン予算をモデルに伝えられます。

モデルはサーバー側で注入されるカウントダウンを見ながら、残り予算に応じて作業の優先順位を付け、予算が尽きる前に「発見の要約」「進捗の報告」といった形で優雅に着地します。

with client.beta.messages.stream(
    model="claude-opus-5",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 64000},
    },
    messages=[{"role": "user", "content": "Review the codebase and propose a refactor plan."}],
    betas=["task-budgets-2026-03-13"],
) as stream:
    response = stream.get_final_message()

概念の整理をしておきます。

effortが「各ステップの推論の深さ」を制御するのに対し、task_budgetは「ループ全体の仕事量」を制御します。

深さのeffort、総量のtask budget、そして毎リクエストのハード上限がmax_tokensという三層構造です。

運用上の注意を4つ挙げます。

予算は助言（advisory）であり強制ではない

中断のほうが破壊的な作業の途中では超過することもあります。ハードキャップは従来どおりmax_tokensで掛けます。

最小値は20,000トークン

それ未満は400エラーになります。

小さすぎる予算は「拒否のような挙動」を引き起こす

数時間級のタスクに2万トークンの予算を渡すと、モデルはタスク自体を辞退したり、過剰にスコープを削ったり、途中で切り上げたりします。

予算設定後に不可解な拒否や早期終了を見たら、他のパラメータを疑う前にまず予算を増やしてください。

カウントダウンはモデルにしか見えない

APIレスポンスに残予算フィールドはありません。

クライアント側でremainingを毎ターン減らして送るとキャッシュを壊すうえ、二重カウントで実際より速く予算が減って見え、早じまいの原因になります。

基本は初回にtotalだけ設定してサーバー任せにします。remainingを使うのは、コンパクション（文脈圧縮）で履歴を書き換えたときに消費済みトークンを引き継ぐ場面だけです。

予算の決め方は「勘で決めない」が公式の推奨です。

まずtask_budgetなしで代表的なタスクを走らせ、ループ全体のusage.output_tokensとツール結果トークンの分布を測り、p99あたりから始めて調整します。

なおTask budgetsはClaude Code / Coworkでは使えません。Messages APIを直接叩くエージェント基盤向けの機能です（Claude Codeのワークフロー機能には類似の予算機構が別途あります）。

10. Opus 5を最大限引き出すプロンプティング

Opus 5は4.8向けプロンプトでも素のままよく動きます。

ただ、公式プロンプティングガイドが「調整が要りやすい」と明言する挙動が5つあります。すべてモデルが勝手にやってくれる方向に変わった結果、旧来の指示が過剰になるパターンです。

(1) 応答・成果物が長くなった

会話応答も、ディスクに書くレポートやMarkdown文書も、4.8より長くなりがちです。

前述のとおりeffortを下げても短くならないので、プロンプトで明示します。

Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.

長いシステムプロンプトでは、末尾近くに短いリマインダ（<tone_preference>Keep outputs reasonably concise.</tone_preference>のようなもの）を重ねるのが効くとされています。

文書の長さには「実質をカバーし、埋め草セクション・冗長な要約・ボイラープレートで水増ししない」という較正指示を入れます。

(2) 進捗ナレーションが増えた

エージェント作業中に「これから何をするか」を積極的に宣言し、メッセージあたりの出力も長めです。

頻度と形を明示的に指定するのが有効で、公式の例はこうです。

Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.

逆にナレーションを増やしたい場合やスタイルを変えたい場合も、禁止形ではなく望む形の肯定例を示すほうが効きます。

(3) 自己検証・自己修正を勝手にやる

これがOpus 5最大の性格変化です。

「最後に検証ステップを入れよ」「ダブルチェックせよ」「サブエージェントで検証せよ」のような、モデルの自己検証と重複する再検証指示は削除が公式推奨です。

モデル自身の検証行動と重なって過剰検証になり、品質向上なしにコストだけ増えるからです。

ただし削除してよいのはこの種の重複指示だけです。

「変更後に指定のテストスイートを実行する」「lintと型検査を通す」といったプロジェクト固有の受入条件は、自己チェックの重複ではなく完了条件なので残します。

また、自分の前言の訂正を口に出しやすくなりました。ユーザー向け製品では「ユーザーのコード・結論・意思決定を変える誤りだけ簡潔に訂正し、影響のない言い間違いは黙って直せ」と絞る指示が紹介されています。

(4) タスクスコープを広げがち

頼んでいないステップを足したり、「本来こうあるべき」と判断してタスクを変形したりすることがあります。

狭いタスクではスコープを明示的に縛ります。

Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it.

(5) サブエージェントへの委任が増えた

マルチエージェント基盤では、4.8より積極的にサブエージェントを起動します。

真に独立した大きな作業では強みですが、小タスクではコストと時間を掛け算で増やします。委任条件の明示か、スポーン数の決定論的な上限を推奨します。

「数回のツール呼び出しで終わる仕事を委任するな」「自分の検証にサブエージェントを使うな」という例文が公式に載っています。

ちなみに4.8のプロンプティングガイドは真逆で、「サブエージェントを増やす」誘導例を載せていました。

世代ごとにデフォルト挙動が振り子のように動くので、ハーネス側の誘導プロンプトは毎世代見直しが必要です。

このほか2つ、特筆したい強化があります。

コードレビュー用途

Opus 5は「1パスあたり高い率で本物のバグを見つけ、追加の指摘もほとんどが誤検知でない」とされます。

しかも低effortでも精度が保たれるため、「レビュー時に速いパス、後でより徹底したパス」という2段構成が組めます。

4.8時代と同じく、「high-severityのみ報告せよ」という指示は文字どおりに守って報告を減らすので、発見段階では全部報告させ、フィルタは別パスで行うのが定石です。

ビジョン（画像理解）

チャート・文書・図の理解と、UIやフロントエンドの視覚的再現が向上しています。

旧モデル向けに入れた画像まわりのワークアラウンドは再検証をおすすめします。

画像を反復的に解析・クロップ・確認できるツールを与えるほうが、thinkingを盛るよりコスト効率が良いとされています。

第3部　Claude Codeで使うOpus 5

11. Claude CodeでOpus 5を使う前提

Claude Codeをまだ使ったことがない方はClaude Code入門（CLI版とWeb版）からどうぞ。

ここでは運用者向けの前提を押さえます。

バージョン

Opus 5にはClaude Code v2.1.219以降が必要です（Sonnet 5はv2.1.197以降、Opus 4.8はv2.1.154以降）。claude updateで更新してください。

エイリアス解決

opusエイリアスの解決先が4.8時代から大きく前進しました。

Anthropic APIだけでなく、Claude Platform on AWS・Amazon Bedrock・Google CloudのAgent PlatformでもopusはOpus 5に解決されます（4.8時代はプロバイダごとにバラバラでした）。

例外はMicrosoft Foundryで、opusはOpus 4.6のまま。Foundryでは完全なモデル名指定かANTHROPIC_DEFAULT_OPUS_MODELで対応します。

`best`エイリアス

組織がFable 5にアクセスできるならFable 5、できなければ最新Opusに解決するbestが使えます。fableエイリアスの直接指定も可能です。

default（モデル未指定時）の解決先は次のとおりです。

ProプランのデフォルトがSonnet 5になった点に注意してください。

Fable 5はどのアカウント種別でもデフォルトにはなりません（/model fable等での明示選択が必要です）。

バージョン固定したい場合は、エイリアスではなくフルモデル名（claude-opus-5）か環境変数（ANTHROPIC_DEFAULT_OPUS_MODEL）を使う、という定石は従来どおりです。

12. Claude Codeのeffort設定は引き継ぎ挙動に注意

Claude Codeでのeffort操作方法（/effort・--effort・CLAUDE_CODE_EFFORT_LEVEL・設定ファイルのeffortLevel・スキルやサブエージェントのフロントマター）は4.8時代と同じです。

Opus 5で特に注意したいのが、effort設定の引き継ぎ挙動です。

Fable 5・Opus 4.8・4.7では、そのモデルを初めて使うとき、以前別モデルで設定したレベルがあってもモデルデフォルトが強制適用される仕様でした（4.8ガイドで注意喚起した挙動です）。

Opus 5にはこのホールドがなく、以前設定したレベルがそのまま引き継がれます。

つまり4.8でxhighを常用していた人がOpus 5に切り替えると、気づかないままxhighで走り続けます。

第8章のとおりOpus 5ではhighから始めて必要に応じて調整するのが公式推奨なので、切り替え直後に/effortで現在値を確認し、意図的に選び直すことをおすすめします。

現在のeffortはセッションヘッダの「with xxx effort」表示でも確認できます。

そのほかは従来どおりです。

maxはセッション限定（設定ファイルには保存不可）、ultracodeは「xhighと動的ワークフローのオーケストレーション」というClaude Code側の設定でモデルのeffortレベルではないこと、一回だけ深く考えさせたいときはプロンプトにultrathinkと書くこと、などは4.8ガイドの第9章・第11章を参照してください。

動的ワークフロー（Dynamic Workflows）自体の仕組みも4.8ガイドで詳説したとおりで、Opus 5で仕組みの変更はありません。

13. Fast modeの変更点

/fastで切り替えるFast mode（同じモデル・同じ品質のまま最大2.5倍速）は、v2.1.219以降でOpus 5がデフォルト対象になりました。

価格はOpus 5・Opus 4.8とも入力$10・出力$50で、4.8時代に値下げされた水準が維持されています（1Mウィンドウ全域でフラット）。

注意点は4.8時代から引き継ぎつつ、ひとつ動きがありました。

• Opus 4.7のFast modeは2026年7月24日（Opus 5ローンチ当日）に削除。しかもClaude Codeは4.7をFast mode対象として扱い続けるため、4.7セッションでFast modeがONのままだとAPIがリクエストを拒否します（標準速度へのフォールバックではなくエラー）。4.7でFast modeを使っていた場合はOpus 5か4.8に切り替えてください
• サブスクリプションプラン（Pro/Max/Team/Enterprise）ではusage credits経由のみ。プランの通常利用枠には含まれず、最初のトークンからFast mode単価
• 会話の途中でONにすると、その時点の会話文脈全体に未キャッシュ入力単価が一度かかるため、使うならセッション開始時から
• Bedrock / Google Cloud / Foundry / Claude Platform on AWSでは利用不可。VS Code拡張も非対応（CLIのみ）

14. フラグされたらどうなるか、自動モデルフォールバックの仕組み

第7章で述べたAPI側のfallbacksとは別に、Claude Code側にもカテゴリベースの自動フォールバックが入りました（v2.1.219以降）。

Fable 5とOpus 5はサイバーセキュリティ・生物学の安全分類器つきで動いており、リクエストがフラグされたときの挙動はこうなります。

この表からも分かるとおり、Opus 4.8に該当分類器がないからこそ、4.8がフォールバック先になっています。

フォールバック後のセッションはそのモデルのまま続くので、戻りたければ/modelで戻します。

運用上知っておくべき挙動を3つ挙げます。

セッションの最初のリクエストでいきなり発火することがある

初回リクエストにはCLAUDE.mdやgit statusなどのワークスペース文脈が載ります。

セキュリティ・生物学系の内容を含むリポジトリでは、何も変なことを頼んでいなくても分類器が反応します。

切り分けにはclaude --safe-mode（CLAUDE.md・スキル・MCP・フックを無効化して起動）が使えます。

自動で切り替えたくない場合は設定で変えられる

/configで「switch models when a message is flagged」をオフにします。

フラグ時にセッションが一時停止し、「フォールバックモデルへ切り替え」か「プロンプトを編集して現行モデルで再試行」を選べます。

ペネトレーションテスト・CTF・生物学隣接コードベースでは頻繁な発火が「仕様どおり」

アカウントにフラグが付いたわけではありません。

Fable級の能力がこの領域で必要な組織向けには、Anthropicのtrusted access programs（CVP等）が案内されています。

なお、Claude Codeの拒否まわりでは過去に紛らわしい不具合もありました。「usage policy violation」表示の対処はこちらの記事にまとめてあります。

15. 1Mコンテキストとopusplan

1Mコンテキストの扱いは4.8時代の枠組みを引き継ぎつつ、Opus 5では「1Mがデフォルトかつ最大」なのでさらに単純になりました。

• Anthropic APIでは、Opus 5（および4.7以降のOpus・Sonnet 5・Fable 5）は常に1Mウィンドウで動作
• Max / Team / Enterpriseプランでは、Opusが追加設定なしで自動的に1Mへアップグレード（サブスクリプションに含まれ、200k超のプレミアム課金なし）
• 完全に無効化するならCLAUDE_CODE_DISABLE_1M_CONTEXT=1

opusplan（プランモードはopus、実行はsonnetエイリアスに自動切り替えするエイリアス）は、Anthropic APIでは計画をOpus 5、実行をSonnet 5が担う構成になりました。

実際の組み合わせは第11章で説明したプロバイダーごとのエイリアス解決に従います。Claude Platform on AWSではOpus 5とSonnet 4.6、BedrockとGoogle Cloud Agent PlatformではOpus 5とSonnet 4.5、FoundryではOpus 4.6とSonnet 4.5になる点に注意してください。

Sonnet 5は「最もエージェンティックなSonnet」としてOpus級に迫る実行能力を謳っており、しかも8月31日までは導入価格$2/$10です。

「設計はOpus 5にじっくり考えさせ、コード生成はSonnet 5に流す」構成はコスト面で魅力があります。

Anthropic APIで実行側がSonnet 5になる場合、Sonnet 5は常時1Mウィンドウで、デフォルトでは約967kトークンで自動コンパクションが入ります（Claude Codeのモデル設定ドキュメント記載。CLAUDE_CODE_AUTO_COMPACT_WINDOWで閾値を変更可能です）。

16. 日常運用のリズム

第10章のプロンプティング変化は、Claude Codeの日常運用にそのまま効いてきます。

運用の型として3点にまとめます。

(1) CLAUDE.mdの検証指示を仕分けする

プロジェクトのCLAUDE.mdやスキルの検証まわりの指示を、2種類に分けてください。

ひとつは必須の受入条件（指定テストスイートの実行・lint・型検査・Definition of Done）。もうひとつはモデルの自己確認に重なるだけの指示（「完了前にダブルチェック」「最後にもう一度検証」）です。

Opus 5で削除してよいのは後者だけです。前者はプロジェクトの完了条件なので残します。

Opus 5は言われなくても自分の変更を確認するため、後者を残すと過剰検証でトークンを浪費します。

逆に、検証してほしくない場面（ドラフト段階の高速イテレーションなど）でこそ明示が必要になる、という逆転も起きています。

(2) 初回プロンプトへの情報集約は引き続き最重要

「完全なタスク仕様を最初に渡して、あとは走らせておくのが最良」という特性は4.8からさらに強化されています。

意図・完了条件・触ってよい範囲・制約を最初に書き切る運用は変わらず有効です。

一方、途中経過の報告は増える方向に変わったので、静かに走らせたければ第10章のナレーション抑制プロンプトをCLAUDE.mdに入れます。

(3) モデルの使い分けを再設計する

Opus 5の登場で、Claude Code内の現実的な使い分けはこうなりました。

「とりあえず全部Fable 5」はコスト的にも（Fable 5のコストと展望）、分類器の介入頻度的にも割に合わない場面が増えました。

Fable 5は最難関のタスクに絞り、日常の上限をOpus 5に置くのが、現時点のバランスだと考えています。

まだわかっていないこと・未確認事項

誠実性のため、現時点で確認できていないことを明示しておきます。

• Frontier-Benchのeffortレベル別チャートの各点（xhigh時は約44%とする読み取りが報道にあります）は画像形式でのみ示されており、テキスト形式では確認できていません。本稿の43.3%はSystem Cardの評価サマリー表に記載された値を採用しています
• 独立評価はまだ出揃っていません。Arena系ブラインド投票やArtificial Analysis等でのOpus 5の位置は、本稿執筆時点（リリース3日後）では確認できませんでした。8月のLLMランキングシリーズで答え合わせをする予定です
• Priority TierとWeb FetchのOpus 5対応時期はアナウンスされていません
• Fast mode・Task budgets・mid-conversation tool changes・fallbacksはいずれもbeta/リサーチプレビューであり、仕様・価格が変わる可能性があります

まとめ

一言でまとめると「Opus 5は最上位モデルではないのに、実務の本命になった」。これが今回のリリースの本質です。

実務で押さえるべき要点は次の5つに集約されます。

1. 移行は「ID差し替えだけ」ではない

thinkingがデフォルトONになり、thinking無効化はeffort high以下限定になりました（400エラー）。Web FetchとPriority Tierの非対応も含め、max_tokensと該当リクエストの監査が必要です。

2. effortは持ち越さず測り直す

デフォルトは変わらずhigh。公式の推奨スタート地点が「コーディングはxhigh」から「highで開始、要求の厳しい作業のみxhigh」に変わり、low/mediumの実用域が広がりました。Claude CodeではOpus 5だけ旧effort設定が引き継がれる点にも注意です。

3. 重複する再検証指示を消す

Opus 5は勝手に自己検証します。「ダブルチェックせよ」系の指示は過剰検証によるトークン浪費の原因になります。ただし必須テスト・lint等の受入条件は残します。

4. 安全分類器の搭載を理解して選ぶ

Opus 5には4.8にないモデル固有分類器（サイバー・生物学）が搭載されました。4.8からの移行では制約の追加であり、セキュリティ系ワークロードは4.8継続も選択肢です。Fable 5と比べれば介入は85%少なく、30日保持要件もなく、フォールバックもあるため、Fable 5からの乗り換え先としては扱いやすいモデルです。

5. 使い分けの再設計

日常はSonnet 5、主力はOpus 5（Maxのデフォルト）、最難関はFable 5。ナレッジカットオフ最新（2026年5月）はOpus 5だけの隠れた強みです。

Fable 5の停止事件からわずか6週間でこの布陣を整えてきたAnthropicの速度には驚かされます。

独立評価が出揃ったら、恒例のランキング記事で改めて検証します。

それでは、また次回、お会いしましょう！

出典

本記事の情報は2026年7月27日時点の公式ドキュメント・公式発表・報道に基づきます。

beta機能・リサーチプレビューの仕様は変更される可能性があるため、最新情報は各出典をご確認ください。

こんにちは！

新しい GPU を手に入れてワクワクしながら既存の推論環境を載せ替えたら、

昨日まで普通に動いていたものが軒並みエラーで止まった

そんな経験はないでしょうか。NVIDIA RTX 50 系、NVIDIA RTX PRO 系（Blackwell 世代）への移行では、これがかなりの高確率で起きます。

そして厄介なことに、エラーで止まってくれるのは、まだ親切なほうで、、TensorRT の世界には

「ビルドは通る、実行も通る、速度もちゃんと出る、けれど出力だけが静かに壊れている」

という、いちばん見つけにくい失敗の仕方が存在します。

本記事はその全体像を扱うシリーズの前編です。

対象環境
OS: Ubuntu 24.04 (WLS)
GPU: NVIDIA RTX PRO 4000 Blackwell・GeForce RTX 5060 Ti
（ともに Compute Capability 12.0 = sm_120）
Stack: PyTorch 2.11.0 + cu128 ／ TensorRT 10.16.1.11。

前編では次の 3 つをお届けします。

1. そもそも TensorRT 化とは何なのか
   なぜ PyTorch のまま動かすより速くなるのか。そして何を代償に払うのか
   
2. Blackwell（RTX 50系、RTX PRO 系）で既存資産が動かなくなる理由
   確認すべき領域は 1 つではなく、大きく 3 つあります
   
3. 最小構成で TensorRT 10 化を通す手順
   環境構築からエンジンビルド、数値照合、速度計測まで、本文のコードを順番に実行すれば再現できる形で

題材には、特定の製品に依存せず同じ検証手順を追えるよう、この記事の中に全コードを載せた小さなダミーモデルを使います。

特定の製品やモデルの話ではなく、TensorRT 化そのものの話として読んでいただけます。

本稿に掲載している数値・エラーログ・挙動は、実際に走らせた結果です。なおコードは TensorRT 10.x の API を対象としています。
TensorRT 11 では precision flag（`BuilderFlag.FP16` 等）を含む一部 API が変更・削除されているため、そのままでは動きません。
既存資産の移行過程を再現するため、意図的に 10.16 を使っています。

なお、お手元の GPU がどの世代（SM いくつ）なのかは、当社が公開している「2026年 NVIDIA GPU 一発検索ツール」で調べられます。本記事の話が自分の環境に当てはまるかどうかは、まずそこからご確認ください。

第1部: TensorRT 化とは何か ～ なぜ PyTorch より速いのか

一言でいうと「事前コンパイル」

PyTorch を普通に（torch.compile や CUDA Graphs を使わない eager 実行で）推論するとき、GPU の中で何が起きているかを思い出してみます。

演算子が呼ばれるたびにディスパッチが走り、演算ごとに GPU カーネルが起動されます。融合されていない演算のあいだでは、中間結果が GPU のメモリ（VRAM)へ書き出され、次の演算がまたそれを読み直します。

TensorRT 化とは、この実行の仕方を根本から変えることです。

モデルの計算グラフ全体を、あらかじめ「その GPU 専用の実行計画」へコンパイルしておき、推論時はホスト側からその実行計画を 1 回の呼び出しで投入するだけにします。

この事前コンパイル済みの成果物を、TensorRT ではエンジン（engine / plan）と呼びます。

なお本記事の比較対象はあくまで PyTorch の eager 実行です。PyTorch 自身にも torch.compile や CUDA Graphs といった高速化経路があり、それらを使った場合の差はまた別の話になります。

ソースコードをインタプリタで 1 行ずつ解釈しながら実行するのと、事前にネイティブバイナリへコンパイルしておいて実行するのと、その違いに近いイメージです。

速くなる 5 つの仕組み

「なぜ速いのか」を分解すると、だいたい次の 5 つに整理できます。

【代償】 TensorRT 化で何を失うか

TensorRT の記事は「速くなりました！」で終わりがちですが、
実務では失うものを把握しておくほうが重要です。

1. ビルドに時間がかかる —
   実機でカーネルを実測して選ぶため、モデルによっては数分から数十分かかります
   
2. エンジンの移植性が低い —
   既定設定でビルドしたエンジンは、作成時の TensorRT バージョンと GPU への依存が強く、「開発機で作ったエンジンを本番機にコピーする」は原則できません。version compatibility や hardware compatibility といった互換モードで対象範囲を広げることもできますが、性能や使える機能に制約が生じます
   
3. 未対応の演算があると、そもそもビルドが落ちる
   本記事の第4部がまさにこれです
   
4. 数値が変わる。ときには静かに壊れる
   精度が落ちるだけでなく、演算の意味そのものがすり替わることすらあります（中編の主題です）
   
5. 固定形状が最も扱いやすい —
   可変形状も optimization profile で正式に扱えますが、対応範囲を広く取りすぎると形状ごとの最適な実装を選びにくくなったり、メモリが増えたりする場合があります
   
6. デバッグしづらい
   PyTorch のようにモデルの途中に print を挟んで中身を覗く、ということができません

「TensorRT 化すべきか」の判断基準

以上を踏まえると、判断はかなりはっきりします。

効きやすいケース

• CPU 実行のままの ONNX モデルがパイプラインに残っている
  （最優先。効果が桁で違います）
  
• 小さな演算が大量にあり、カーネル起動のオーバーヘッドがボトルネックになっているモデル
  
• 入力形状が固定で、同じモデルを大量に回し続ける推論サービス

効きにくい、あるいは慎重に判断すべきケース

• 計算そのものに時間の大半を使っているモジュール …主要演算の計算時間がすでに支配的で、、単純な ONNX → TensorRT 変換による 1 件あたりのレイテンシ改善は限定的でした
  （バッチを増やしても 1 件あたりの時間はほぼ不変。ただしこれはこのモジュールでの結果で、量子化や専用カーネルまで含めれば話は変わりますし、スループットはまた別の指標です）
  
• 形状の変動範囲が大きく、optimization profile の設計や複数エンジンの管理コストが効果に見合わない用途
  
• TensorRT 非対応の演算を含む
  （→ 第4部のハイブリッド構成で部分適用する）
  
• バッチ処理でよい用途
  ここは強調しておきたい点です。カーネル起動のオーバーヘッドがボトルネックなら、TensorRT 化しなくても PyTorch 側でバッチを組むだけで数倍取れることがあります。
  私たちのケースでは、あるモジュールをバッチで回したところ 1 フレームあたり 2 倍以上まで縮み、わざわざ TensorRT 化した構成より速いという結果になりました。「リアルタイムで 1 フレームずつ処理する」用途と「まとめて書き出す」用途では、最適解が変わります

つまり

TensorRT は万能の高速化ボタンではなく、
「どの段が・何に時間を食われているか」を実測してから当てる道具

です。ここを飛ばして全段 TensorRT 化に突っ込むと、ビルドの苦労に見合わない結果になります。

第2部: なぜ「昨日まで動いていた資産」が Blackwell で動かないのか

さて、ここからが Blackwell の話です。

RTX 50 系と、今回検証した RTX PRO Blackwell ワークステーション GPU は sm_120（Compute Capability 12.0） という新しい世代で、既存資産が動かなくなる原因はここに集約されます
（なお Blackwell ファミリー全体ではデータセンター向けに別の Compute Capability を持つ製品もあります。製品ごとの世代は冒頭で紹介した GPU 検索ツールで確認できます）。

私たちの検証環境では、次の 3 つの領域で問題が発生しました。

• TensorRT
  sm_120 に初対応したのは TensorRT 10.8.0 です（リリースノートに "supports NVIDIA Blackwell GPUs, such as the GeForce 50-series" と明記されています）。
  裏を返すと、
  既定設定でビルドされた TensorRT 8 系の `.engine` / `.plan` は互換性チェックを通らず、sm_120 では原則として再利用できません
  （TensorRT 8.6 以降で version compatibility と hardware compatibility を有効にして構築したエンジンは例外になり得ますが、互換設定が確認できない既存資産は再ビルド前提が安全です）
  
• PyTorch
  Blackwell ネイティブ対応の最初の安定版は 2.7.0（CUDA 12.8 wheel = cu128） です。それ以前の wheel を入れると sm_120 is not compatible with the current PyTorch installation. のように弾かれます
  
• onnxruntime: 私たちの検証環境（onnxruntime 1.27）では、CUDAExecutionProvider が初期化できず CPU 実行にフォールバックしました。
  エラーで止まらないので気づきにくく、「なんだか遅い」だけが症状として残ります。
  ただしこれは onnxruntime のバージョン・配布ビルド・CUDA の組み合わせに依存する話で、Blackwell で公式 wheel が一律に動かないという意味ではありません。お使いのバージョンで実際に確認してください
  

つまり Blackwell 移行とは、単に GPU を挿し替える話ではなく、

「PyTorch を cu128 世代へ」
「TensorRT を 10.x 世代へ」に加えて
「onnxruntime などの周辺ランタイムが実際にどのバックエンドで動いているかを見直す」
を同時に走らせる作業

です。

3 番目の onnxruntime については「CUDA で動かないなら CPU のままでいいか」と放置されがちですが、そこがパイプライン全体のボトルネックになっている可能性が高いので要注意です。
まずは providers を実際に出力して、CPU に落ちていないか確認してください。

import onnxruntime as ort
print(ort.__version__)
print(ort.get_available_providers())   # CUDAExecutionProvider が無ければ、この環境では CUDA EP を利用できない

sess = ort.InferenceSession("model.onnx",
                            providers=["CUDAExecutionProvider", "CPUExecutionProvider"])
print(sess.get_providers())            # セッションに登録された provider と優先順位

1 点だけ注意です。
sess.get_providers() で分かるのは「セッションにどの provider が登録されたか」までで、全ノードが GPU で実行された証明にはなりません
（一部のノードだけ CPU に割り当てられることがあります）。ノード単位の配置まで確認したい場合は、onnxruntime のプロファイリングや詳細ログを使ってください。

第3部: 最小構成で TensorRT 10 化を通す ～5 ステップ

ここからは実際に手を動かします。

いきなり本命のモデルを変換しないでください。

まずは数十行の最小モデルで「export → build → 実行 → 数値照合 → 速度計測」の 5 ステップを通し、環境そのものが健全であることを確認します。

この自己診断を挟んでおくと、後で本命モデルが失敗したときに「環境のせいか、モデルのせいか」を即座に切り分けられます。

環境構築 ～ ここに最初の罠があります

検証はすべて WSL2（Ubuntu 24.04）上で行いました。

WSL2 を選ぶのは、CUDA / TensorRT まわりの Linux 前提のツールチェーンがそのまま使えるためです。venv は uv で立て、システムの Python には触りません。

# 作業用 venv を uv で作成（システム Python 非侵襲）
uv venv ~/work/trt_venv --python 3.11
source ~/work/trt_venv/bin/activate

# PyTorch は cu128（CUDA 12.8）世代を明示（2026-07-23 時点では 2.11.0 が入ることを確認）
uv pip install torch --index-url https://download.pytorch.org/whl/cu128

# TensorRT は 10.x の cu12 ビルドにピンする（★理由は下記）
uv pip install "tensorrt-cu12==10.16.1.11"
# onnxscript は PyTorch の新しい exporter（dynamo=True）が必要とする
uv pip install onnx onnxscript numpy

罠その1: pip install tensorrt が CUDA 13 系を連れてくる

素の pip install tensorrt は、検証時点で TensorRT 11.1.0.106（CUDA 13 系ビルド） に解決されました。

一方、本記事の PyTorch 環境は cu128（CUDA 12.8）です。異なる CUDA メジャー系列のライブラリが同じ環境に存在すること自体が直ちに不正というわけではありませんが、依存関係や障害の切り分けが複雑になります。

そして何より、本記事のコードは TensorRT 11 の API では動きません。

そこで検証条件を揃えるため、torch の CUDA 系列に TensorRT の CUDA 系列を合わせて、TensorRT 10.16 の cu12 ビルドを明示的にピンします。

「最新版を入れれば良い」ではありません。

環境が整ったら、GPU が本当に sm_120 として認識されているかを先に確認しておきます。

import torch
print(torch.__version__, torch.version.cuda)   # 例: 2.11.0+cu128 / 12.8
print(torch.cuda.is_available())               # True であること
print(torch.cuda.get_device_capability())      # RTX 50 系・今回の検証 GPU なら (12, 0)

ステップ 1: 題材となるダミーモデルを用意する

小さな畳み込みブロックを用意します。特定の製品とは無関係の、ただの Conv + BatchNorm + ReLU の積み上げです。

# tiny_model.py
import torch
import torch.nn as nn

class TinyBlock(nn.Module):
    """TensorRT 化の動作確認用の最小モデル（Conv+BN+ReLU ×3）。
    レイヤ融合の効果が分かりやすいよう、あえて小さな演算を並べている。"""
    def __init__(self, ch=64):
        super().__init__()
        layers = []
        for _ in range(3):
            layers += [nn.Conv2d(ch, ch, 3, padding=1), nn.BatchNorm2d(ch), nn.ReLU(inplace=True)]
        self.body = nn.Sequential(*layers)

    def forward(self, x):
        return self.body(x)

INPUT_SHAPE = (1, 64, 256, 256)   # 固定形状で扱う

ステップ 2: ONNX へ export する

後のステップで「export したモデルそのもの」と数値を突き合わせるので、`model` と `x` はここで作ったものをこの後もずっと使い回します。

シードも固定しておくと、結果を再現できます。

torch.manual_seed(0)
model = TinyBlock().eval().cuda().float()
x = torch.randn(*INPUT_SHAPE, device="cuda")

torch.onnx.export(
    model, (x,), "tiny.onnx",
    input_names=["x"], output_names=["y"],
    opset_version=20,
    dynamo=True,          # PyTorch 2.x の新しい exporter（onnxscript が必要）
)

入力が複数あるモデルでは、ここに極めて見つけにくい事故の種があります。

torch.onnx.export に渡す args はタプルで、位置引数として順に束縛されます。

モデルの forward の引数順を勘違いしていると、ONNX の中で引数が入れ替わったまま、エラーも警告も出さずに export が成功します。

この事故と恒久的な回避策は中編で詳しく扱います。

ステップ 3: TensorRT エンジンをビルドする

import tensorrt as trt

TRT_LOGGER = trt.Logger(trt.Logger.WARNING)

def build_engine(onnx_path, engine_path, fp16=True, workspace_gb=4, tf32=True):
    builder = trt.Builder(TRT_LOGGER)
    # TensorRT 10 では explicit batch が既定。下記フラグは後方互換で残っているもの
    network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH))
    parser = trt.OnnxParser(network, TRT_LOGGER)

    # parse_from_file を使うと、大きなモデルの外部データ（.onnx.data）も
    # ONNX と同じディレクトリから自動で解決してくれる
    if not parser.parse_from_file(onnx_path):
        errs = [str(parser.get_error(i)) for i in range(parser.num_errors)]
        raise RuntimeError("ONNX parse failed:\n" + "\n".join(errs))

    config = builder.create_builder_config()
    config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, workspace_gb * (1 << 30))

    if fp16:
        # FP16 の実装候補（tactic）を選択肢に加える。全層が FP16 になる保証ではなく、
        # 層によっては FP32 が選ばれる。実際の実行精度はレイヤ情報のダンプで確認できる
        config.set_flag(trt.BuilderFlag.FP16)

    # ★ TensorRT は fp32 ビルドでも既定で TF32（仮数 10bit）を使う。
    #    忠実度を厳密に検証したいときは無効化する（詳細は中編）
    if not tf32:
        config.clear_flag(trt.BuilderFlag.TF32)

    plan = builder.build_serialized_network(network, config)
    if plan is None:
        raise RuntimeError("build_serialized_network returned None（エンジンのビルドに失敗）")
    with open(engine_path, "wb") as f:
        f.write(plan)
    return engine_path

build_engine("tiny.onnx", "tiny_fp16.plan", fp16=True)

コメントに書いたとおり、BuilderFlag.FP16 は「全部を fp16 にする」指定ではなく、「FP16 の実装候補を許可する」指定です。以降、本文で「fp16 でビルド」と書いたときは、この「FP16 tactic を許可してビルド」の意味だと読んでください。

ステップ 4: エンジンを実行する（PyTorch テンソルを直接渡す）

ここが実務上いちばん知りたいところだと思います。

device・dtype・形状・メモリ配置（contiguous）があらかじめエンジンの要求と一致していれば、PyTorch テンソルの GPU メモリアドレス（`data_ptr()`）を TensorRT にそのまま登録でき、境界での追加コピーを避けられます。

これができると、「モデルの一部だけ TensorRT 化して、残りは PyTorch のまま」というハイブリッド構成が現実的になります（第4部で使います）。

以下のサンプルは安全のため dtype と device を自動で合わせてから渡します
（条件が合わない場合はそこで変換コピーが発生します。なぜこの自動変換が要るのかは、すぐ後の罠で説明します）。

_TRT2TORCH = {
    trt.float32: torch.float32, trt.float16: torch.float16,
    trt.int32: torch.int32, trt.int64: torch.int64,
    trt.int8: torch.int8, trt.bool: torch.bool,
}

class TRTRunner:
    """エンジンをロードし、PyTorch テンソルを入出力に使って実行する（固定形状前提）"""

    def __init__(self, engine_path, device="cuda:0"):
        self.device = torch.device(device)
        # Runtime / engine / context はカレント CUDA デバイスに紐づくため、
        # 対象デバイスを明示して作成する（cuda:0 以外を使う場合に必須）
        with torch.cuda.device(self.device):
            self.runtime = trt.Runtime(TRT_LOGGER)
            with open(engine_path, "rb") as f:
                self.engine = self.runtime.deserialize_cuda_engine(f.read())
            if self.engine is None:
                raise RuntimeError(f"deserialize failed: {engine_path}")
            self.ctx = self.engine.create_execution_context()

        self.inputs, self.outputs = [], []
        for i in range(self.engine.num_io_tensors):
            name = self.engine.get_tensor_name(i)
            if self.engine.get_tensor_mode(name) == trt.TensorIOMode.INPUT:
                self.inputs.append(name)
            else:
                self.outputs.append(name)

    def prepare(self, feed: dict):
        """入力の形状とアドレスを設定し、出力バッファを確保する。
        入力バッファを使い回すなら 1 回で足りる（速度計測ではここを計測の外に出す）"""
        self._feed = {}
        for name, t in feed.items():
            # ★ FP16 tactic を許可してビルドしても、エンジンの入出力型は ONNX の定義のまま（多くは fp32）。
            #   half テンソルのアドレスをそのまま渡すと、fp16 のビット列が fp32 として
            #   読まれて出力が壊れる。しかも例外は出ない（詳細は下記）
            want = _TRT2TORCH[self.engine.get_tensor_dtype(name)]
            t = t.to(device=self.device, dtype=want).contiguous()
            # set_* 系も bool を返す。失敗の握りつぶしはこの記事のテーマ的に厳禁
            if not self.ctx.set_input_shape(name, tuple(t.shape)):
                raise RuntimeError(f"set_input_shape failed: {name}, shape={tuple(t.shape)}")
            if not self.ctx.set_tensor_address(name, t.data_ptr()):
                raise RuntimeError(f"set_tensor_address failed: {name}")
            self._feed[name] = t

        self._outs = {}
        for name in self.outputs:
            shape = tuple(self.ctx.get_tensor_shape(name))
            if any(d < 0 for d in shape):
                raise RuntimeError(f"output shape unresolved: {name} {shape}")
            dtype = _TRT2TORCH[self.engine.get_tensor_dtype(name)]
            o = torch.empty(shape, dtype=dtype, device=self.device).contiguous()
            self._outs[name] = o
            if not self.ctx.set_tensor_address(name, o.data_ptr()):
                raise RuntimeError(f"set_tensor_address failed: {name}")
        return self._outs

    def enqueue(self):
        """現在のストリームに実行を積む（非同期）。★ 戻り値を必ず確認すること"""
        ok = self.ctx.execute_async_v3(torch.cuda.current_stream(self.device).cuda_stream)
        if not ok:
            raise RuntimeError("TensorRT enqueue failed: エンジンと実行環境の不一致等の可能性。"
                               "出力は信頼できないため処理を停止する")

    def run(self, feed: dict):
        """検証用の簡便版（毎回 prepare + 同期する）。速度計測には使わない"""
        outs = self.prepare(feed)
        self.enqueue()
        torch.cuda.current_stream(self.device).synchronize()
        return outs

罠その2: FP16 tactic を許可してビルドしても、エンジンの入出力は fp32 のまま

これは今回の検証で実際に踏んだものです。

config.set_flag(trt.BuilderFlag.FP16) を有効にすると TensorRT は FP16 の実装候補を選択肢に加えますが（全層が fp16 になるわけではありません）、

ネットワークの入出力テンソルの型は ONNX の定義に従うため、この例では fp32 のままです。

ここに PyTorch の half テンソルのアドレスをそのまま渡すと、TensorRT はその領域を「fp32 要素が並ぶ入力バッファ」として扱います。fp16 は 1 要素 2 バイト・fp32 は 4 バイトなので、値の解釈が変わるだけでなく、TensorRT が PyTorch 側の確保範囲を超えて読み出す可能性もあります。

挙動は未定義で、出力の破損だけでなく、環境によっては CUDA エラーやクラッシュも起こり得ます
（set_tensor_address はポインタを登録するだけで、バッファのサイズまでは伝えないためです）。

実測すると、こうなりました。

• 正しく dtype を合わせた場合:
  最大絶対誤差 約 0.001
  （今回の FP16 tactic 許可設定では、大きな数値破綻は見られません）
  
• half のアドレスをそのまま渡した場合
  最大絶対誤差 約 13.8
  （出力の値域が 0.5 弱のモデルで、です。なおこの値は今回の環境で観測された一例で、再現可能な誤差量を意味しません）

そして最悪なのは、今回の実測ではこの状態でも `execute_async_v3` が `True`（成功）を返し、NaN も出ず、例外も飛ばなかったことです。上のコードで want = _TRT2TORCH[...] の 2 行を入れているのは、この沈黙劣化を防ぐためです。

罠その3: `execute_async_v3` の戻り値を捨ててはいけない

このメソッドは失敗しても例外を投げず、`False` を返すだけです。

放置すると、更新されなかった出力バッファ（＝ゴミ、あるいは直前のフレームの値）がそのまま下流へ流れていきます。

処理は「成功」に見えたまま、出力だけが壊れるという最悪の形になります。上のコードのように False を即例外にしておくことを強くおすすめします。

ステップ 5: 数値を突き合わせてから、速度を測る

速度を測る前に、まず数値が合っているかを確認します。
順序を逆にしてはいけません。

照合の基準は、ステップ 2 で export に使った fp32 の `model` と `x` そのものです。ここで新しくモデルを作り直してはいけませんし
（ランダム初期化された「別の重み」と比較することになります）、fp16 化した別のモデルを基準にしてもいけません（「export とエンジンが正しいか」の検証になりません）。

# model / x はステップ 2 で export に使った fp32 のものをそのまま使う
with torch.inference_mode():
    torch_ref = model(x)

runner = TRTRunner("tiny_fp16.plan")
trt_out = runner.run({"x": x})["y"]

diff = trt_out.float() - torch_ref.float()
print("max_abs :", diff.abs().max().item())
print("nRMSE   :", (diff.norm() / torch_ref.norm()).item())

出力の値域そのものを併記しないと、最大絶対誤差の大小は判定できません。学習済みでないダミーモデルは値域が実モデルと違うので、正規化した相対誤差（nRMSE）を併せて見るのが安全です。

今回の TinyBlock では max_abs 約 0.001・nRMSE 約 0.0016 で、FP16 tactic を許可したエンジンの、今回の設定における誤差として小さい水準でした。

計測は 専用の CUDA ストリーム + CUDA Event で行います。time.time() では GPU の非同期実行を正しく測れません。

import numpy as np

def bench_callable(fn, n_warmup=30, n_iter=200, device="cuda:0"):
    """fn() を計測して mean/median/min/max（ミリ秒）を返す。
    専用ストリームを使うことで、PyTorch と TensorRT を同じ条件で公平に比較できる"""
    dev = torch.device(device)
    # これ以前に別ストリームへ積まれた処理（モデル変換・prepare 等）を完了させる。
    # ストリーム間は明示的に同期しない限り実行順序が保証されない
    torch.cuda.synchronize(dev)
    stream = torch.cuda.Stream(dev)
    with torch.cuda.stream(stream):
        for _ in range(n_warmup):      # ウォームアップは必須（初回は遅い）
            fn()
        stream.synchronize()

        times = []
        for _ in range(n_iter):
            s = torch.cuda.Event(enable_timing=True)
            e = torch.cuda.Event(enable_timing=True)
            s.record(stream)
            fn()
            e.record(stream)
            stream.synchronize()
            times.append(s.elapsed_time(e))

    t = np.array(times)
    return {"mean": float(t.mean()), "median": float(np.median(t)),
            "min": float(t.min()), "max": float(t.max())}

速度計測では、PyTorch 側の実運用候補として fp16 化したモデルを使います。照合に使った fp32 の model はそのまま残したいので、コピーしてから fp16 化します。ポイントは、TensorRT 側は `prepare()`（バッファ確保・アドレス登録）を計測の外で 1 回だけ行い、計測中は `enqueue()` だけを呼ぶことです。

毎回 run() を呼ぶと、dtype 変換・出力確保・同期まで TensorRT の時間に含まれてしまい、公平な比較になりません。

import copy

# 速度計測用の fp16 モデルは、export に使った fp32 model を保つため deepcopy で別に作る
model_half = copy.deepcopy(model).half()
x_half = x.half()

# PyTorch 側（eager + inference_mode・fp16）
def torch_fn():
    with torch.inference_mode():
        model_half(x_half)

# TensorRT 側: prepare は計測の外で 1 回だけ。計測中は enqueue のみ
runner.prepare({"x": x})
def trt_fn():
    runner.enqueue()

print("torch:", bench_callable(torch_fn))
print("trt  :", bench_callable(trt_fn))

結果はこうなりました。

計測条件: GeForce RTX 5060 Ti ／ batch=1 ／ PyTorch 2.11 eager + inference_mode・fp16 モデル ／ TensorRT 10.16・fp32 入出力・FP16 tactic 有効。TensorRT は入出力バッファを事前確保し enqueue 部分のみを計測。各 200 回・ウォームアップ 30 回の median。

Conv + BatchNorm + ReLU を 3 段重ねただけの小さなモデルで、GPU 実行区間では約 2.5 倍の差が出ました。

ただしこの数字の読み方には注意が要ります。

これは「PyTorch の全面 fp16 eager」と「fp32 入出力 + FP16 tactic を許可した TensorRT エンジン」を、事前の dtype 変換とバッファ準備を除いた GPU 実行区間で比べた結果です。

同一精度条件どうしの比較でも、パイプライン全体のエンドツーエンド高速化率でもありません。

それでも、同じモデル構造をそれぞれの実運用候補となる設定で実行したときにこれだけ差が出る、というのは第1部で挙げたレイヤ融合・カーネル選択・実行時オーバーヘッド削減などの効果と整合的な結果です。

比較は median で見ます。

平均はときどき混ざる外れ値に引きずられます。

また、計測中はその GPU を単独で占有してください。他の推論プロセスやデスクトップ描画が同じ GPU に乗っていると、数値は簡単に数十パーセント変動し、比較の意味がなくなります。

第4部: 最初の壁 ～ grid_sample の次元でビルドが落ちる

本命のモデルを変換し始めると、多くの方が最初にぶつかるのがこれです。モデルの中に 5 次元（volumetric）の `grid_sample` が入っていると、TensorRT のビルドが通りません。

3D ボリュームを変形させる処理は、医用画像のレジストレーション、NeRF 系、3D 特徴のワーピングなど、いろいろな領域で使われています。再現用の最小モジュールは次のとおりです。

import torch.nn.functional as F

class VolumetricWarp(nn.Module):
    """5D（volumetric）grid_sample を含む最小モジュール。
    input: [N, C, D, H, W] / grid: [N, D, H, W, 3]"""
    def forward(self, vol, grid):
        return F.grid_sample(vol, grid, align_corners=False)

VOL_SHAPE  = (1, 32, 16, 64, 64)
GRID_SHAPE = (1, 16, 64, 64, 3)

export とビルドは、ステップ 2〜3 と同じ道具立てでそのまま試せます。

warp_model = VolumetricWarp().eval().cuda()
vol = torch.randn(*VOL_SHAPE, device="cuda")
grid = torch.rand(*GRID_SHAPE, device="cuda") * 2 - 1

torch.onnx.export(
    warp_model, (vol, grid), "volumetric_warp.onnx",
    input_names=["vol", "grid"], output_names=["y"],
    opset_version=20, dynamo=True,
)

# ONNX export は成功する。落ちるのは次の build のほう
build_engine("volumetric_warp.onnx", "volumetric_warp.plan", fp16=False)

実行すると、次のエラーで落ちます（実機のログそのままです）。

[TRT] [E] INetworkDefinition::addGridSample: Error Code 3: API Usage Error
    (Parameter check failed, condition: input.getDimensions().nbDims == 4.
     In addGridSample at /_src/optimizer/api/network.cpp:1803)
[TRT] [E] ModelImporter.cpp:138: While parsing node number 0 [GridSample -> "y"]:
[TRT] [E] ModelImporter.cpp:149: ERROR: ModelImporter.cpp:490 In function parseNode:
[6] Invalid Node - node_GridSample_0

input.getDimensions().nbDims == 4

つまり TensorRT 10.16 のネイティブ `GridSample` は 4 次元入力しか受け付けません。

5D の呼び出しは、パーサがノードを追加する時点で拒否されます。

これは一次情報とも一致します。onnx-tensorrt の operators ドキュメントは GridSample について "Input must be 4D input." と明記しており、5D 対応の要望は NVIDIA/TensorRT の issue #3890 として存在しますが、open / triaged のままネイティブ対応は提供されていません。

「ONNX の opset を上げれば通る」は誤りです

ここは混乱しやすいところなので明確にしておきます。

ONNX の標準仕様では opset 16 で 4D、opset 20 で 5D（volumetric）の grid_sample が定義されています。

ですから PyTorch からの export は opset 20 で問題なく成功し、ONNX ファイルの中に 5D の GridSample ノードがちゃんと生成されます。実際、上のエラーログは「export は成功したあと、ビルドの段階で落ちている」ことを示しています。

落ちているのは export ではなく、TensorRT 側の build です。ONNX に書けることと、TensorRT が食えることは別問題です。

現実解 — 通らないモジュールだけ PyTorch に残す

回避策のひとつは、TensorRT が持っていない演算を自分で CUDA カーネルとして書き、プラグインとして登録することです。5D grid_sample には既存の OSS 実装（grid-sample3d-trt-plugin など）があり、これを新しい CUDA / TensorRT 世代向けにビルドし直すアプローチが取れます。

ただしこれはエキスパート作業なので、本シリーズの後編で扱います。

プラグインを書き上げるまで移行が 1 ミリも進まない、というのは現実的ではありません。そこで有効なのがハイブリッド構成です。考え方はいたってシンプルで、TensorRT で通るモジュールだけ TensorRT にし、通らないモジュールは PyTorch のまま残すというものです。

# 構成イメージ（head_fp16.plan は「後段を TensorRT 化したエンジン」の意味の仮の名前です）
warp = VolumetricWarp().eval().cuda()      # 5D grid_sample → PyTorch のまま
head = TRTRunner("head_fp16.plan")         # 後段 → TensorRT エンジン

def forward(vol, grid):
    with torch.no_grad():
        feat = warp(vol, grid)             # PyTorch が GPU 上に出力を作り
    return head.run({"x": feat})["y"]      # そのアドレスをそのまま TensorRT へ渡す

ステップ 4 で見たとおり、dtype・device・形状が一致していれば、PyTorch テンソルと TensorRT は同じデバイス・同じストリーム上でアドレスを渡し合えるので、両者の橋渡しに追加のコピーを発生させずに済みます。

私たちのケースでは、プラグインを一切書かずにこの構成だけで 2 倍近く改善し、TensorRT にクリーンに載るモジュールを順に置き換えていくと、プラグイン不要の範囲だけでパイプライン全体が 2 倍程度に到達しました。

「まず低リスクな範囲で確実に速くする。カスタムプラグインは別プロジェクトとして切り出す」

これが移行の現実的な進め方だと考えています。

まだ確かめていないこと

誠実に書いておきます。本記事の検証は「TensorRT 10.16・PyTorch 2.11 + cu128」という単一のソフトウェア構成で行ったものです。次の点は本記事では確認していません。

• 他の TensorRT バージョンでの再現性
  特に 4D grid_sample の挙動（中編で扱います）は、将来のバージョンで修正される可能性があります。また TensorRT 11 系は API が変わっており（strong typing 化）、本記事のコードはそのままでは動きません
  
• torch.compile や CUDA Graphs を使った PyTorch との比較
  本記事の比較対象は eager 実行のみです
  
• int8 量子化との組み合わせ
  本記事は fp16 / fp32 のみを扱っています
  
• 可変形状（dynamic shape）でのビルド
  本記事はすべて固定形状です。
  optimization profile を使う場合の速度・精度は別途検証が必要です
  
• 5D grid_sample プラグインを Blackwell 向けにビルドした場合の数値と速度
  後編で扱う予定です

まとめ

一言でまとめると、

「Blackwell 移行は GPU の差し替えではなく、PyTorch と TensorRT の対応状況の更新に加えて、周辺ランタイムが実際にどの実行バックエンドで動いているかを再確認する作業であり、TensorRT 化はそこに乗せる別の投資判断である」

ということです
（まったく一言にならなかったですが（笑）　
ちなみに、私たちの環境では onnxruntime の CPU フォールバックも発生しました）

さて、ここでまとめとして大事なポイントを再掲いたしますね。

1. GPU の Compute Capability を最初に確認する
   （RTX 50 系は sm_120。Blackwell の他製品群は別の値を持つので製品ごとに確認する）
   
2. PyTorch は cu128 世代
   （安定版は 2.7.0 以降）
   
3. TensorRT は 10.8 以降を使う。
   既存の TensorRT 8 エンジンは互換設定と対象 GPU を確認のうえ、原則として再ビルドする
   
4. TensorRT の CUDA 系列を torch に合わせる（cu12 にピン）
   
5. onnxruntime が CPU に落ちていないか、バージョンと providers を実際に出力して確認する。落ちていれば最優先の TensorRT 化候補
   
6. 最小モデルで自己診断してから本命へ進む
   
7. エンジンの入出力 dtype に合わせてテンソルを渡す
   （FP16 tactic を許可したビルドでも入出力は fp32 のことが多い）
   
8. execute_async_v3 や set_input_shape / set_tensor_address の戻り値を必ず確認する
   （失敗しても例外は飛ばない）
   
9. 数値照合は速度計測より先に、export に使ったモデルと同じ重み・同じ入力で行う
   
10. モデル内の grid_sample の次元を確認する
    （5D はネイティブでは通らない。opset を上げても解決しない）
    
11. 通らないモジュールは切り出してハイブリッド化する
    
12. 計測は GPU を単独占有して CUDA Event の median で見る。エンジン単体の比較ではバッファ準備を分離して enqueue 区間を測り、実運用の判断では dtype 変換・モジュール境界・同期を含むエンドツーエンド時間も別途はかる

次回予告（中編）～ ビルドが通っても、正しいとは限らない

次回は後編ではなく中編です。

今回の前編で扱ったのは、エラーで止まってくれる種類の問題でした。

移行作業で本当に怖いのはその先です。

私たちが実際に踏んだ「沈黙劣化」を扱います。

• ビルドも実行も成功していて、出力の形も値も「それらしい」。しかし演算の意味が別物にすり替わっているケース
  （これは今回、公開できるダミーモデルで完全に再現できました）
  
• ビルド成功・速度も良好、なのに実データを入れた瞬間に出力が壊れるモジュール
• 開発機で完璧に動いたエンジンが、同じ世代の別の GPU では静かにゴミを出す現象
• fp32 でビルドしたのに、実は fp32 ではなかったという話
• そして私たちが最も泣いたexport 時の引数取り違え事故

どれも「速くなったので OK」と報告した後に発覚すると非常に厄介なものばかりですので、お楽しみに～

それでは、また次回お会いしましょう！

参考資料（一次情報・主要ソース）

• NVIDIA TensorRT ドキュメント（Release Notes 10.8.0 — Blackwell 対応の記載）
• NVIDIA 公式フォーラム: Software Migration Guide for NVIDIA Blackwell RTX GPUs（CUDA 12.8 / PyTorch / TensorRT）
• PyTorch issue #159207: sm_120 is not compatible with the current PyTorch installation
• onnxruntime issue #27875: Blackwell 環境での CUDAExecutionProvider 初期化に関する報告
• NVIDIA/TensorRT issue #3890: 5D GridSample のネイティブ対応要望
• SeanWangJS/grid-sample3d-trt-plugin（5D grid_sample のカスタムプラグイン実装）
• ONNX Operators: GridSample（opset 16 / 20 の仕様）
• 当社関連記事: 2026年 NVIDIA GPU 一発検索ツール

こんにちは！

2026年7月16日、中国・北京の Moonshot AI が新しいフラッグシップモデル Kimi K3 を発表し、APIやWebサービスでの提供を開始しました。

総パラメータ2.8兆という規模、100万トークンのコンテキスト、そして

「史上最大のオープンウェイトモデルになる」

という宣言がAI界隈をにぎわせています。

当ブログでは今年5月の記事「Mythos（ミュトス）レベルのオープンモデルはいつ出るのか」で、オープンモデルがクローズドのフロンティアにいつ追いつくのかを予測しました。

Kimi K3 は、まさにその問いに対する現時点での最新の「回答」のひとつです。

一方で、この記事を書いている7月20日時点では、モデルのウェイトも技術レポートもまだ公開されていません。

ただし、XなどSNSかいわいでは、

「ガードレールが弱めで、Fable5では拒否されるようなプロンプトでも対応してくれる」

「すぐにOpus4.8にフォールバックする Fable5より使い勝手がいい」

といった声が散見されており、
米国産のガードレール強め方針にたいして、ガードレール弱め中国産モデルが最終的にユーザーの心をつかむ可能性を秘めているかもしれません。

さて、そうはいっても本記事では、SNS等のネタではなく、一次情報（Moonshot 公式ブログ・公式APIドキュメント・GitHub）と英語圏の報道・独立評価機関の分析を突き合わせ、「公式発表」「独立評価」「未確認」を区別しながら、Kimi K3 の全体像を整理していきたいとおもいます。

第1部: Kimi K3 とは何か

リリースの経緯

Kimi K3 は2026年7月16日に発表され、同日から以下のチャネルで利用可能になりました。

• Kimi.com（チャットUI）
• Kimi Work（ワークスペース製品）
• Kimi Code（コーディングエージェント）
• Kimi API（OpenAI SDK 互換）

サードパーティの API アグリゲータである OpenRouter にも同日追加されており、「まず API とWebで使えるようにして、ウェイトは後から」という API 先行型のローンチです。

公式ブログは「フルモデルウェイトは 2026年7月27日までに 公開する」と明言しており、遅延の理由を「推論パートナーとの円滑な展開のため」と説明しています。

基本スペック早見表

第2部: アーキテクチャ — 極端に「疎」な2.8兆パラメータ

896分の16しか使わない MoE

Kimi K3 は Moonshot が「Stable LatentMoE」と呼ぶフレームワークで構築されたスパース MoE（Mixture of Experts）モデルです。特徴的なのはその活性化率の低さで、896のエキスパートのうち、トークンごとに活性化されるのはわずか16基（約1.8%）です。

総パラメータ2.8兆という数字はマーケティング上「世界初のオープン3Tクラス」と丸められて訴求されていますが、推論時に実際に動くのはそのごく一部です。

この
「巨大な知識の倉庫から、必要な棚だけを開ける」
設計により、規模と推論コストの両立を狙っています。

なお、トークンあたりのアクティブパラメータ数は Latent.Space が「A50B」（約500億）と表記していますが、Moonshot 公式は明示しておらず、この数字は未確認です。ウェイト公開後、設定ファイルやモデルカードなどから確認できる可能性があります。

2つの内製新機構: KDA と AttnRes

アーキテクチャ面での見どころは、Moonshot が内製した2つの新機構です。

• Kimi Delta Attention (KDA)
  ハイブリッド線形アテンション機構。100万トークン級のコンテキストで最大6.3倍の高速デコードを実現すると主張されています
  
  
• Attention Residuals (AttnRes)
  従来の残差接続を置き換える機構。追加コスト2%未満で約25%の学習効率向上と主張されています

いずれも興味深い数字ですが、現時点では公式Xアナウンス由来のベンダー主張であり、技術レポート未公開のため第三者による再現はされていません。

ネイティブビジョンと常時オンの思考モード

K3 はテキスト・画像・動画を扱うネイティブマルチモーダルモデルです。

ビジョン機能については、著名なAI技術ブロガーの Simon Willison 氏が実際にテストして「Vision works well」と確認しており、これは数少ない独立した実測のひとつです。同氏の単一テストでは、思考モードが13,241推論トークンを消費する様子も観察されています（モデル一般の典型値ではなく一例です）。

思考モードは常時オンで、公式 Kimi API で指定できる reasoning_effort は現在 'max' のみです。一方 Kimi Code では low/high/max を選択できると公式に案内されており、利用チャネルによって選択肢が異なる点は押さえておきましょう。

第3部: ベンチマーク — 「自己申告」と「独立評価」を分けて読む

Kimi K3 のベンチマーク数値を読むときに最も重要なのは、どれが Moonshot の自己申告で、どれが独立評価かという区別です。

独立した比較評価としては Arena.AI（ブラインド投票）と Artificial Analysis（評価機関）があり、これとは別に Simon Willison 氏によるAPIハンズオンも公開されています。

独立評価①: Frontend Code Arena で1位

最も驚きがあったのはこちらでしょうか。

ユーザーのブラインド投票で決まる Arena.AI の Frontend Code Arena で、公表（7月16日）時点で Kimi K3 が1,679点の1位を獲得しました。

Claude Fable 5 をも上回るスコアで、前世代 Kimi K2.6 の18位から一気に17ランク上昇しています。ブラインド投票のため自己申告バイアスは入りにくいものの、初期の投票数やプロンプトの偏りといった揺らぎは残ります。それでも、フロントエンド生成能力の高さを示す、現時点で最も強い外部シグナルのひとつです。

独立評価②: Artificial Analysis — 「Opus 4.8 / GPT-5.5 級」

評価機関 Artificial Analysis の Intelligence Index では 57 で、同機関の表現を借りれば「Claude Opus 4.8・GPT-5.5 相当。

ただし Claude Fable 5・GPT-5.6 Sol には及ばない」という位置づけです。

同機関の GDPval-AA v2（実務タスクのElo評価）でも、フロンティア2強に次ぐ3位につけています。

ここで注目したいのが、右パネルのエージェントElo です。

GDPval-AA v2 のエージェントElo では K3（1,668）が Claude Opus 4.8（1,600）と GPT-5.5（1,494）を上回るという報道（The Decoder 等）があり、Moonshot 自身の「総合では Fable 5 / GPT-5.6 Sol に劣るが、コーディング・エージェント系なら Opus 4.8 / GPT-5.5 を上回る」という主張とも整合します。

一方、独立評価がすべて肯定的というわけではありません。

Artificial Analysis の AA-Omniscience では、正答率が K2.6 の33%から46%へ改善した一方、ハルシネーション率は39%から51%へ上昇したと報告されています。

知識量や推論力の向上が、そのまま回答の慎重さや事実性の向上を意味するわけではない——企業導入の判断材料として、この点は覚えておきたいところです。

なお、Artificial Analysis が7月17日に公開した分析では、同機関の非公開エージェント評価 AA-Briefcase でも Kimi K3 は Fable 5 に次ぐ2位（Elo 1,547）でした。

VentureBeat 報道の1,527ではなく、評価主体自身が分析記事で公表した1,547を採用しています（Elo は動的に再計算されるため、時点により多少変動します）。

総合ランキングでの位置づけ（参考値）

ベンチマークアグリゲータ BenchLM.ai では、7月19日調査時点で総合80.96点・4位に位置しています。

ただし BenchLM は、全モデルを自前の同一条件で実行する評価機関ではなく、複数の公開値を集約するサービスです。

モデルごとに利用できるベンチマークや評価条件が異なるため、「総合4位」は方向感を見るための参考値として扱うのが適切でしょう。

Moonshot による公式評価の注目値

Moonshot 公式の数値では、エージェント的Web閲覧ベンチマークの BrowseComp が91.2 です。

これは30万トークン到達時にコンテキスト圧縮を行う同社の評価条件での値で、圧縮なしでは90.4と明記されています。

なお外部集計では GPT-5.6 Sol（92.2）に次ぐ水準であり、無条件の「SOTA」とはいえません。

一方で、API 経由ではすでに Arena.AI や Artificial Analysis による独立評価が始まっています。現段階では「外部から観測できる性能には一定の裏付けがあるが、モデル内部の仕様や公式ベンチマークの再現条件はまだ確認できない」と整理するのが正確でしょう。

第4部: API価格 — クローズド最上位より安いが、Kimi世代では大幅値上げ

API価格は公式価格ページで確認できた一次情報です。

• Kimi K3: 入力 $3.00 / 出力 $15.00（100万トークンあたり）、キャッシュヒット時の入力は $0.30
• K2.7 Code（コーディング特化）/ K2.6（汎用）: 各 入力 $0.95 / 出力 $4.00
• 長コンテキストの追加課金なし。OpenAI SDK を利用でき、base_url・APIキー・モデル名の差し替えで呼び出せます

こちら、英語圏の報道では「Claude Sonnet 級の価格」と評されています。

実際、K3 の $3/$15 は Claude Sonnet 5 の2026年9月1日以降の標準価格と同額です（ただし Sonnet 5 は8月31日まで $2/$10 の導入価格で提供されているため、7月20日時点では K3 の方が入出力とも50%高い計算になります）。

また Kimi 系列内で見ると、K2.6 の $0.95/$4 からは大幅な値上げであり、Simon Willison 氏も「中国系AIラボとしては高めの価格帯に踏み込んだ」と指摘しています。

また Moonshot は、Mooncake と呼ばれる分散推論アーキテクチャにより「コーディングワークロードで90%超のキャッシュヒット率」を達成していると主張しており、これが実態に近ければエージェント用途での実効コストはかなり下がることになります（この数値もベンダー主張）。

第5部: 「オープンウェイト」はまだ約束の段階

ここが本記事で最も重要なポイントです。

2026年7月20日時点で、Kimi K3 は「オープンウェイトモデル」ではなく「オープンウェイトになる予定のモデル」です。

実際に Moonshot の公式 GitHub organization を確認すると、Kimi K3 のモデルリポジトリはまだ存在せず、ピン留めされたモデル系リポジトリは Kimi-K2.5 のままです。Hugging Face にもモデルカードはありません。

量子化については、公式技術ブログが MXFP4 ウェイト / MXFP8 アクティベーションという構成を明記しており、これは一次情報となる一方で、Hugging Face での配布ファイル形式がそのまま MXFP4 になるかは、モデルカードが未公開のため未確認です。

技術レポートも「今後公開する」とされています。

もうひとつ、実務上とても重要な注意があります。
「ウェイトが公開されること」と「手元で動かせること」は別問題です。

Moonshot は K3 の展開先として、64基以上のアクセラレータを備えたスーパーノード構成を推奨しています。

量子化済みとはいえ2.8兆パラメータ級であり、フルモデルの自己ホスティングはご自宅はおろか、オフィス環境でもおそらく無理で当面は、専門データセンターや大規模推論事業者向けと考えるべきでしょう。

ライセンスは複数の報道で「Modified MIT」とされていますが、モデルカードが存在しない以上、一次ソースでの確認はできません（未確認）。

予定どおり公開されれば、DeepSeek v4 Pro（1.6兆パラメータ）を抜いて史上最大のオープンウェイトモデルとなります。

第6部: エージェント機能 — K3 の主戦場

Moonshot が K3 で最も訴求しているのはエージェント用途です。

• BrowseComp（エージェント的Web閲覧）91.2（Moonshot の評価条件。外部集計では GPT-5.6 Sol に次ぐ水準）
• AA-Briefcase（Artificial Analysis のエージェント評価）で2位
• GDPval-AA v2 エージェントElo で Opus 4.8・GPT-5.5 超え
• Kimi Code というコーディングエージェント製品ラインで提供
• API はツール呼び出しに対応し、OpenAI SDK からの移行が容易

Kimi Code では、7月20日に Starter / Explorer / Expert / Master の新プラン体系が導入されました。K3 自体は全プランで利用でき、1Mコンテキストは Explorer 以上で利用できます（従来の Moderato / Allegretto 契約者には旧プランの条件が引き続き適用されます）。

実務導入時の注意

公式ドキュメント・公式ブログ自身が認めている制約もあります。

• 思考履歴の完全再送が必要
  過去ターンの思考を含む assistant メッセージをそのまま返さないと品質が不安定になり得ます
  
• 過剰な自律判断
  曖昧な指示に対して、ユーザーに代わって予期しない判断をすることがあると公式が明記しています
  
• サンプリング設定は固定で、Web検索機能は当面本番利用を推奨しないとされています

第7部: K2世代からの進化点

前世代からの変化をまとめると次のとおりです。

1. 規模の飛躍
   GitHub 上の従来フラッグシップ K2/K2.5 から総パラメータ2.8兆へ大幅拡大
   
2. 内製新機構
   KDA と AttnRes を導入、活性化率約1.8%の極端に疎な Stable LatentMoE 設計
   
3. 実力の躍進
   Frontend Code Arena で K2.6 の18位 → K3 で1位へ
   
4. ネイティブビジョン
   画像・動画理解を標準搭載
   
5. 常時オンの思考モード
   
6. 製品ライン再編
   K3（フラッグシップ）/ K2.7 Code（コーディング特化）/ K2.6（汎用低価格帯）の3層構成に

K2.6 との比較は、Arena.AI や Artificial Analysis の評価で一部確認できます（Frontend Code Arena の18位→1位、AA-Omniscience の正答率33%→46%など）。一方、K2 や K2.5 を含めて全世代を同一条件で横断した比較は限定的であり、アーキテクチャや学習方法を含む詳細は技術レポート待ちです。

第8部: まだわかっていないこと

現時点で未公表・未確認の事項も整理しておきます。

• 学習データ規模・学習トークン数・学習手法（事前学習コーパス、RL/ポストトレーニング構成）→一次・二次いずれのソースでも未公表
• アクティブパラメータ数→ 「約50B（A50B）」は分析者の表記で、公式未公表
• 技術レポート/論文→ 未公開（今後公開するとの公式表明のみ）
• Hugging Face モデルカード・配布ファイル形式→ 存在しない（ウェイト未公開のため）
• ライセンスの正確な条項: 「Modified MIT」は報道レベルの言及のみ

7月27日のウェイト公開期限を過ぎたら、(1) 本当に公開されたか、(2) 公式スコアの評価条件が技術レポートで十分に開示され、同等条件で追試できるか、(3) ライセンス条項、の3点をチェックしましょう。当ブログでも続報があれば、また、くわしく取り上げる予定です。

まとめ

Kimi K3 を一言でまとめると、

「フロンティア最上位（Claude Fable 5 / GPT-5.6 Sol）には総合で一歩及ばないものの、コーディング・エージェント領域では Opus 4.8 / GPT-5.5 級以上を狙える位置につけた、"オープンウェイト予定"の超大規模MoE」

です。

ブラインド投票の Frontend Code Arena 1位という独立評価は実力の裏付けとして重く、一方でモデル内部の仕様や公式ベンチマークの再現条件については、7月27日までに予定されるウェイト公開と、今後公開される技術レポートを待つ必要があります。「史上最大のオープンウェイト」という看板が本物になるかどうか、あと1週間ほどで答え合わせが始まります。

5月の記事「Mythos（ミュトス）レベルのオープンモデルはいつ出るのか」では、オープンモデルがフロンティアに追いつく時期をベンチマークの傾きから予測しました。

K3 が予定どおりウェイトを公開すれば、「Artificial Analysis の総合指数で Opus 4.8 と同等圏に入るモデルのウェイト」が2026年夏に手に入ることになり、同記事で描いたトレンドは想定ラインの上限を走っていることになります。

ただし、同記事の主軸だったサイバーセキュリティ能力（CyberGym や AISI 実環境テスト）については K3 の評価データがまだ存在しません。「能力到達と公開判断は別問題」と書いたあの答え合わせは、ウェイト公開後の独立評価を待って、あらためて行いたいと思います。

次回予告

次回は、Qwen が公式に発表した次期フラッグシップ Qwen3.8 を取り上げる予定です。総パラメータ2.4兆・オープンウェイト公開予定と、こちらも Kimi K3 と並ぶ超大規模のオープン系モデルです。Kimi K3 と同じく、一次情報ベースの徹底リサーチで掘り下げますので、どうぞお楽しみに。

それでは、また次回、お会いしましょう！

参考資料（一次情報・主要ソース）

• Moonshot AI 公式ブログ: Kimi K3 Tech Blog
• Kimi API 公式ドキュメント: K3 Quickstart
• Kimi API 公式価格ページ
• Kimi Code What's New（新プラン体系）
• Moonshot AI 公式 GitHub
• Moonshot AI 公式X（KDA / AttnRes の効率数値の発表元）
• Artificial Analysis: Kimi K3 分析（Intelligence Index / GDPval-AA v2 / AA-Briefcase / AA-Omniscience）
• Simon Willison: Kimi K3 ハンズオン
• Tom's Hardware: Moonshot releases 2.8-trillion-parameter Kimi K3
• VentureBeat: China's Moonshot AI releases Kimi K3
• Arena.AI 公式X: Frontend Code Arena 結果
• OpenRouter: moonshotai/kimi-k3
• Latent.Space: Kimi K3 分析
• BenchLM.ai: Kimi K3
• Alibaba Qwen 公式X: Qwen3.8 発表（次回予告の出典）
• Bloomberg: Alibaba's Qwen unveils preview of flagship AI model

※本記事の内容は2026年7月20日時点の調査に基づきます。図表はすべて公表値をもとに Qualiteg が作図したものであり、公式チャートの転載ではありません。

こんにちは！Qualitegプロダクト開発部です！

本日は、PII（ Personally Identifiable Information→個人情報）の非識別化に関する内容を解説いたします。

当社ではこれまで、高精度なPII検出技術やLLM利用時の段階的PIIマスキング、PII検出のテスト設計など、個人情報検出とAIセキュリティに関する技術解説をお届けしてきました。

現在、当社では、PII検出マスキング技術「PII-FIエンジン」と、それを活用したPIIのマスキング・非識別化サービス「PII-FI Scan」「PII-FI API」を開発・提供しています。

本記事では、「PIIを検出したあと、それをどう書き換えるか」の設計原則を、1つの例文を試金石にして、私たちが実際のプロダクトで採用している整理をご紹介します。

先にことわっておきますと、本記事でいう「非識別化(de-identification)」は、文書やログを安全に共有・分析するための技術的な加工(個人を特定できないように加工する処理)のお話です。

個人情報保護法上の「仮名加工情報」「匿名加工情報」に該当することを保証するものではありません（法律用語との関係は後半で触れます）。

非識別化は、何のためにやるのか

まず、そもそも論から始めましょう。

ログや文書を「そのまま」使えるなら、非識別化は必要ありません。

手元に原本があり、自分だけが見るなら、加工する理由がないからです。

非識別化が必要になるのは、

「データを誰かに渡して仕事を進めたいが、生のままでは渡せない」

その瞬間です。

たとえば、

• 分析業務を外部に委託したいが、顧客情報が混ざっている
• 障害解析のため、業務ログをLLMに読み込ませたい
• ログ一式をセキュリティベンダーに分析依頼したい
• PIIを含むファイル他社に送信する前に確認したい
• カルテ情報をAIに整理させたいがAIに入れる前にPIIをマスクしたい

データには「何が起きたか」と「それが誰のことか」が混ざっています。

分析や共有の価値を生むのは前者です。

一方で、本人の不利益（なりすまし、差別、風評など）につながるのは後者です。

つまり非識別化とは、

「出来事」を残して「誰か」を切り離す

技術です。

守られるのは、データに写っている本人だけではありません。

渡す側は漏えい事故の責任から守られ、受け取る側は「持っているだけでリスクになる情報」を預かるリスクと管理負担を減らせます。

試金石：「甲野太郎は高血圧です」

ここからが本題です。次の1文を非識別化することを考えます。

「甲野太郎は高血圧です」

さて、加工の仕方は1つではありません。

代表的な3パターンを比べてみましょう。

パターン1：名前だけを偽名にする

乙山次郎は高血圧です

「甲野太郎↔高血圧」という結びつきは切れました。
読み手には「誰かが高血圧である」という出来事だけが伝わります。そしてこの出来事はまだ真実であり、使えます。症例の内容や対応の妥当性を検討する読み手にとって、この文は材料として機能し続けます。

これが非識別化の基本形です。ただし、ここで成功したのは「この一文の中の結びつきを切ること」だけです。実際の文書では、名前を変えても残りの文脈から本人が推測されることがあります——この限界は落とし穴3で正面から扱います。

パターン2：病名まで偽物にする

乙山次郎は花粉症です

一見、より安全になったように見えます。

しかし、この加工には重大な問題があります。

読み手には「花粉症」が偽物だと見分ける手段がありません。

症例を集計する人も、対応の妥当性を検討する人も、
嘘の事実を材料に仕事をしてしまいます。

「隠す」は安全側の操作です。情報が減るだけで、嘘は増えません。

ところが「別の本物らしい値に差し替える」は、嘘の注入です。データに毒を混ぜる行為だと言ってもよいでしょう。

パターン3：全部伏せ字にする

■■■■は■■■です

はい、安全ではあります。

しかし「誰かが何かである」という情報量ゼロの文になり、データとしては死んでいます。これでは渡す意味そのものがなくなります。

原則：語には2種類ある

この比較は、次の原則に整理できます。

語には2種類ある。

「誰か」を指す語（識別子）——氏名、社員番号、電話番号、メールアドレス。これは自然な偽物に差し替えてよい。読み手はその真実性を消費せず、切るべきは「結びつき」だけだから。

「何が起きたか」を語る語（属性）——病名、金額、人事評価、出来事。これは残すか、正直に伏せるかの二択。偽物にしてはならない。読み手はその真実性で仕事をするから。

もっとも現実の語はこの2つに綺麗に分かれてくれません。

「経理部長」は属性であると同時に、組織の中では本人を指す手がかりです。

年齢や日時も、組み合わせれば「誰か」に近づきます（準識別子と呼ばれます）。だからこそ、判定の物差しは語の型ではなく役割です。

上のフローの問いが「その語は氏名か？」ではなく「読み手はその値が真実であることを使って仕事をするか？」なのは、このためです。

検出した型だけで機械的に方式を決めるのではなく、語が文書の中で果たしている役割と渡し先の用途を組み合わせて加工方式を決めます。

「正直に伏せる」とは、たとえば [病名1] のようなラベルへの置き換えです。

ポイントは連番にすることで、同じ病名にはいつも同じ番号を振ります（これを照応保持と呼んでいます）。

すると「この文書には2種類の病気の話が出てくる」という分析に必要な構造は残り、かつ読み手には「ここは伏せられた」と正直に伝わります。

また、二択の中間として「一般化」という手もあります。「47歳→40代」「詳細な住所→市区町村まで」のように、真実のまま解像度だけを下げる方法です。

嘘は注入せず、特定のリスクだけを下げられるため、識別子にも属性にも使える誠実な中間手です。

ということで、ここまでを、まとめますと、非識別化の方式はこんなふうに整理できます。

さて、ここで一つ注意があります。

表の最後にあるパスワードやAPIキーのような認証情報は、PIIに該当するかどうかとは別に、「シークレット」として扱うべき情報です。

共有用ファイルの上では伏せ字にしますが、外部に漏れた可能性があるなら、伏せ字にして終わりではなく、失効・ローテーションというインシデント対応が別途必要になります。

逆に、

属性へのダミー適用（病名を別の病名に差し替える等）だけは、原則禁止

です。

もし本物らしい偽データが必要な場面があるとすれば、それは受け手が元データの事実性を利用しない用途、たとえばパーサのテスト、デモ、負荷試験、などです。

私たちはそれを非識別化とは呼ばず、「合成データ生成」という別の仕事として扱っています。

標準の世界では合成データの生成も非識別化手法の一つに数えられますが（NIST SP 800-188）、

「意味を保って渡すためのマスキング」と「本物らしい偽物を作る仕事」を同じ処理に混ぜない

これが私たちが採用している設計判断です。

なお、統計データベースの匿名化には、ノイズ付加（数値にランダムな誤差を加える）のように属性値をあえて変える標準技法もあります（ISO/IEC 20889）が、これは、集計したときの統計的性質を保ちながら個々のレコードの真の値を隠すための道具という位置づけです。
これを本記事が対象とする「人やツールがそのまま読む文書・ログ」に持ち込むと、上で述べた嘘の注入と同じ問題を起こします。

実務で踏みがちな、4つの落とし穴

では、実際にPII処理を設計するときの注意点をみていきましょう。

PII処理アプリケーションなどを実装するときに、リアルに出会う4つの課題をご紹介いたします。

1. ファイルをまたぐと、同一人物が別人になる

やみくもに非識別化をしていくと、同一人物のことを複数の人物に変換してしまう場合があります。同一人物は、非識別化したあとも同一人物として追跡できるべきです。これを照応保持といいます。

たとえば、複数のログにある人物名を非識別化することを考えてみましょう。

照応保持を「1ファイルの中」だけで行うと、ログ一式を処理したときにファイルAでは「甲野→乙山」、ファイルBでは「甲野→丙川」になり得ます。

これでは複数ログを横断して関係者の動きを追う分析が壊れてしまいます。

そのため、こういった課題に対処するには、

一式（ジョブ）単位の照応保持

が必要です。

ただし逆の顔もあります。

照応の範囲を広げるほど「同じ偽名の出現パターン＝元の人物の行動パターン」が残るため、特定の手がかりも増えます。そこで、一貫させる範囲は、用途に応じて選べるのがよいようにおもいます。

なお、この論点は人物の偽名に限らず、[病名1] のようなラベルの番号づけにも同じように当てはまります。

2. 偽名が実在の人とかぶる

生成した偽名「乙山次郎」が、たまたま文書に元々登場する本物の乙山さんと同姓同名だったら、分析が混乱するだけでなく、その実在の方に濡れ衣を着せかねません。

この課題には、

文書内に実在する値は、ダミーの候補から除外する

仕組みが要ります。

ただし、自然な人名は「実在しないこと」までは保証できません。誤帰属のリスクを取れない渡し先では、偽名ではなく [人物1] のようなラベルを選ぶ、これも後述する「渡し先」の判断です。

さらに機械的な値については、「実在しえない値」を生成するのが定石です。

ダミーのメールアドレスは予約ドメイン（example.com）、IPアドレスは文書用に予約されたテスト専用領域（192.0.2.0/24 など）、各種番号はチェックデジットが合わない値にしておけば、うっかり連絡や照会をしても誰にも届きません。

3. 非識別化しても「誰か分かる」ことは消せない

氏名や番号をすべて消しても、「経理部の部長が7月3日に処分を受けた」という文脈だけで、社内の人には誰のことか分かります。これはメールに含まれるPIIを非識別化するときによく怒ります。

非識別化は魔法ではなく、特定のリスクを下げる技術です。

そういう意味では、「加工済み＝完全に安全」という思い込みが、いちばんの落とし穴かもしれません。

なお、「仮名加工情報」「匿名加工情報」は個人情報保護法上の定義と要件を持つ法律用語です。

技術的な加工を指す言葉としては、本記事のように「非識別化」「マスキング」と呼ぶのが安全だと私たちは考えています。

4. 加工したファイルは「改変された文書」である

インシデント対応の提出物は、のちに監査や法的手続きの材料になることがあります。

非識別化ファイルは原本ではないので、

「いつ・どんなルールで・何を何件加工したか」と原本のハッシュ値を記録した処理証跡

を成果物に添えることで、原本との関係を第三者に示せるようにしておくべきです。証跡は単なる注意書きではなく、改変の透明性を担保する監査文書です。

正解は「型」ではなく「渡し先」が決める

さて、次の論点に移りましょう。

PII処理において、何を優先させるか、です。

自然さ（分析ツールが壊れない）・安全さ・正直さ（偽物と分かる）の3つは、同時には最大化できません。

どれを優先するかは、そのデータがどこへ行くかで決まります。

• 人が読む提出物 → 正直さ優先。ラベル置換中心＋処理証跡
• ツールで解析するログ → 書式・桁の保持優先。実在しえない値のダミー中心
• LLMに入れるデータ → 自然さ優先。ダミー中心（LLMの応答からの復元と対にする設計もあります）

ちなみに、LLM向けは入力時の置換だけでは完結しません。

置換の対応表はLLMには送らず、手元の信頼境界の内側で管理する。

復元は自由文の文字列一致ではなく管理されたトークンに限定する。

そしてLLMの応答には入力になかったPIIが現れることもあるため、出力側にも再度PII検査をかける。ここまでがワンセットです。

つまり非識別化の設定とは「型ごとの好み」ではなく、
「誰に、何のために渡すか」という宣言
なのです。

私たちのPII-FIでは、この宣言を「渡し先ごとのプロファイル」として設計しています。

まとめ

さて、今回は、非識別化の本質は何か、について私たちの考え方やPII処理の設計課題について具体的に示しながらご紹介してまいりました。

ここで、再度、本記事の要点を整理いたします。

• 非識別化は「渡す」ための技術。「出来事」を残して「誰か」を切り離す
• 語には2種類ある。識別子は偽名にしてよい。属性は「残す・正直に伏せる・一般化」の三択で、偽物にしてはならない
• 属性への偽データ注入は「嘘の注入」。それが許されるのは合成データ生成という別の仕事
• 実務では、ファイル横断の照応保持・偽名の実在衝突・残存する特定リスク・処理証跡の4点に要注意
• 最終的な正解は型ではなく「誰に何のために渡すか」が決める

今回の記事はいかがでしたでしょうか。PII処理の考え方に関して、何かお役にたてましたら幸いです。

当社 株式会社Qualitegでは、本記事の設計思想に基づく高速高精度PII検出・マスキングソリューションとしてログや文書の一式をドラッグ&ドロップで非識別化できるサービス「PII-FI Scan」や、その技術をAPIから使える「PII-FI API」を開発・提供中です。

もし、PII-FIの検出やマスキング、非識別化ご興味ございましたら、お気軽にお問い合わせフォームよりご連絡くださいませ。

それでは、また次回お会いしましょう！

参考（業界標準・ガイドライン）

本記事の整理は、非識別化に関する以下の標準・ガイドラインの考え方と整合しています。あわせてご参照ください。

• NIST IR 8053: De-Identification of Personal Information — 非識別化と再識別に関する研究・実務を幅広く整理した米国NISTの報告書。構造化データに限らず、自由記述や画像も対象とする
• NIST SP 800-188: De-Identifying Government Datasets — 政府データセットを対象とした非識別化の実務ガイド（2023年最終版）。準識別子の変換・合成データ・再識別リスク評価・ガバナンスまで扱う
• ISO/IEC 20889:2018 — 非識別化技法の用語と分類の国際規格。仮名化・一般化・抑制（削除/マスキング）・ノイズ付加などを体系化
• ENISA: Pseudonymisation Techniques and Best Practices — EUサイバーセキュリティ機関による仮名化の実践ガイド。一貫した偽名（照応保持）の有用性と再識別リスクのトレードオフを詳述
• 個人情報保護委員会: 個人情報の保護に関する法律についてのガイドライン（仮名加工情報・匿名加工情報編） — 日本法における「仮名加工情報」「匿名加工情報」の定義・要件・義務

関連リソース

• 高精度なPII検出技術（Part 1）
• LLM利用における段階的PIIマスキング（Part 2）
• PII検出の混同行列では見えないもの——認識器間衝突とテスト設計
• LLM時代の企業情報防衛
• ゼロトラスト時代のLLMセキュリティ完全ガイド
• AI時代のDLP技術（Part 1）
• AI時代のDLP技術（Part 2）

はじめに

本レポートは、Nejumi Leaderboard 4のベンチマークデータ（2026/7/10版）に基づいて、日本語対応LLMの性能を総合的に分析したものです。

前回は 2026/3/6 版の分析レポート を公開しましたが、
約4か月ぶりとなる今回も、上位勢の顔ぶれが大きく入れ替わる激動の回となりました！

（定期的に最新LLMランキングを更新してまいります。当社のX(旧Twitter)をフォローいただくことで更新情報を受け取り可能です）

Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。汎用的言語性能（GLP）とアラインメント（ALT）の2軸で構成され、翻訳・要約・推論・コーディングから毒性・バイアス・真実性まで、幅広い観点をカバーしているのが特徴です。

本分析では、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。まず、今回の3大トピックを先にご紹介します。

• Claude Opus 4.8がリーダーボード史上初の総合スコア0.85を突破
  Claude Opus 4.7とともにAnthropic勢がワンツーフィニッシュ
  
• 総合スコア0.80以上が19モデルに
  （前回11モデル、前々回4モデル）とほぼ倍増ペースが継続
  
• オープンモデルではGemma 4が急浮上
  国産勢もRakutenAI-3.0、llm-jp-4などの新顔が登場
  

オープンソースモデルについて

Weightがオープンなモデルは場合によっては「オープンソースモデル」、「OSSモデル」と呼ばれますが、学習データや学習コードまで完全に公開されているモデルばかりではないため、本稿では「オープンモデル」という表記に統一しています。

ベンチマーク分析について

本レポートは、LLM選択の参考情報として、ベンチマークデータから読み取れる傾向や特徴を提示するものです。実際の導入にあたっては、用途に応じた実環境での検証をおすすめいたします。

また、今回の集計はリーダーボード上位100件のエクスポートデータに基づいています。同一モデルでも思考モード（reasoning/thinking）等の設定が異なる評価ランは別エントリーとして掲載される場合があります。

それでは、2026/7/10 現在の日本語対応LLMの総合ランキングをみてみましょう。

総合スコアランキング TOP50

※水色の行はオープンモデルです。
※本日(7/10)時点では Fable5やGPT 5.6がロールアウトされていますが、ベンチマーク登場までラグがあるので未掲載となっています。ご承知おきください。

総合スコアの傾向と考察

今回の最大のニュースは、なんといっても
Claude Opus 4.8（0.8523）とClaude Opus 4.7（0.8509）のワンツーフィニッシュです。

Nejumi Leaderboard 4で総合スコアが0.85を超えたのは今回が初めてで、それを同一ベンダーの2モデルが同時に達成しました。

• TOP2が0.85以上という未曾有の高水準（前回の首位は0.8430）
• TOP19が0.80以上（前回は11モデル）
• TOP10のうち6枠が、前回ランキングに存在しなかった新顔

Anthropic勢がついに「0.85の壁」を突破

首位のClaude Opus 4.8は、GLP（汎用的言語性能）0.8328とALT（アラインメント）0.8933の両輪で高水準を達成しました。とくに数学的推論0.975、抽象的推論0.87、そしてコーディング実務力を測るSWE-Bench系評価0.6875は全モデル中トップクラスで、「推論の強さ」がスコアを押し上げています。

前回2位だったClaude Opus 4.6（0.8394）も6位に踏みとどまっており、TOP10のうち3枠をAnthropic勢（Opus 4.8、Opus 4.7、Opus 4.6）が占める結果となりました。前回首位のGemini 3.1 Pro（0.8430）はスコア自体は変わらないまま3位に後退しています。

OpenAIはGPT-5.5とGPT-5.4で追撃

前回「出たばかりでまだ評価が載っていない」とお伝えしたGPT-5.4（0.8397）は5位に、その後継のGPT-5.5（0.8411）は4位に入りました。GPT-5.5はGLP 0.8303と言語性能ではOpus 4.8に肉薄しており、SWE-Bench系評価もOpus 4.8と並ぶ0.6875を記録しています。

興味深いのは、GPT-5.4では推論エフォート「high」設定（0.8397）が「xhigh」設定（0.8286）を上回った点です。推論量を増やせば必ずスコアが上がるわけではない、という好例といえます。

※本当の最新モデルの反映はもう少し先

本日(2026/7/10)時点での本当の最新・最上位モデルは Claude Fable5 だったり、ChatGPT 5.6 が存在しますが、ベンチマークに登場するのはもう少し先になる見込みですので現時点ではランキング未掲載であることご承知おきください。

TOP10の6枠が新顔に入れ替わる

上図のとおり、TOP10のうち6枠が前回ランキングにいなかった顔ぶれです。とくに注目すべき新顔を紹介します。

• Qwen3.6 Max（7位、0.8295）
  Alibabaの旗艦APIモデル。ALT 0.9181は全モデル中トップで、制御性・毒性・堅牢性のバランスが際立ちます
  
• Gemini 3.5 Flash（10位、0.8249）
  軽量・低価格のFlashクラスで前回のOpus 4.5（0.8064）を超えるスコア。ただし真実性0.550は上位勢のなかで突出して低く、ハルシネーション対策は利用側で必要です
  
• GLM-5.2（20位、0.8040）
  Z.aiのAPI版最新モデル。6月リリースの新しいモデルで、オープン版GLM-5（0.7884）を上回ります
  
• DeepSeek V4 Pro（23位、0.7956）
  DeepSeekの最新API旗艦。数学的推論0.94、抽象的推論0.79と推論系が強化されています

「性能は高いのに総合で沈む」grok-4.20が示す教訓

上の散布図は、GLP（言語性能）とALT（アラインメント）の2軸で主要モデルを配置したものです。

総合上位モデルはすべて右上、つまり「賢さ」と「安全性・制御性」を両立しています。

対照的なのがxAIのgrok-4.20-0309-reasoning（0.7732）です。

GLP 0.7942はTOP10級の言語性能ですが、ALTが0.7659（とくに毒性0.566、真実性0.485）と低く、総合では40位に沈みました。

総合評価ではアラインメント側の比重も大きいため、「賢いだけ」では上位に入れない構造がよくわかる例です。

ベンチマーク結果の解釈について

本レポートで紹介するスコアは、あくまでもベンチマークテストにおける評価結果です。ベンチマークは、LLMの性能を客観的に比較する有用なツールですが、以下の点にご注意ください。

• ベンチマークは特定のタスクセットに基づいて評価されるため、そのタスク構成に適したモデルほど高いスコアを獲得する傾向があります
• 実際の業務での使用感や、特定の用途における有用性は、ベンチマークスコアだけでは完全には測れません
• モデルによっては、ベンチマークで測定されていない独自の強みや特徴を持っている場合があります

次は、オープンモデルに限定して実力をみていきましょう。

オープンモデル 総合スコアランキング TOP20

※順位はモデル単位（同一モデルの複数評価ランはベストスコアのみ採用）です。

オープンモデル総合スコアの傾向と考察

首位はQwen3.5-397B-A17Bが堅持、ただしAPI勢との差は再拡大

オープンモデルの首位は前回に引き続き、Alibaba社のQwen3.5-397B-A17B（0.8191）です。

Qwen3.5シリーズは2026年2月リリースのスコアのままで、この4か月間オープン側のフロンティア更新はありませんでした。

その間にAPI側の首位は0.8430→0.8523へ伸びたため、オープンとAPIの首位差は前回の約0.024から約0.033へ再び広がっています。

「オープンがAPIに肉薄する」と沸いた前回から一転、今回はフロンティアAPI勢が突き放した格好です。

ただし、オープン勢の層は確実に厚くなっており、0.80超えのオープンモデルは前回の3モデルから4モデルに増えました。

Gemma 4の衝撃 —— 31B denseで0.80超え

その4モデル目こそ、今回のオープン部門最大のニュース、GoogleのGemma 4ファミリーです。2026年3月にリリースされた新世代で、Hugging Face上でApache 2.0ライセンスで公開されています。

• Gemma 4 31B（0.8077）
  31Bのdenseモデルでオープン3位に急浮上。GPT-5.1（0.8085）やClaude Opus 4.5（0.8064）と同水準を、単一GPUで動かせるサイズで実現しました
  
• Gemma 4 26B-A4B（0.7872）
  総26B・アクティブ4BのMoE版。推論コストを大幅に抑えつつ0.79級
  
• Gemma 4 E4B／E2B
  オンデバイス向けの小型版もラインナップ（小規模モデルの章で紹介します）

これまで「30B級ローカルLLMの本命」はQwen3.5-27B（0.8049）でしたが、Gemma 4 31Bがこれを上回ったことで、単一GPUクラスに強力な選択肢が2つ並んだことになります。

中国勢の新顔：GLM-5、Kimi K2.5、MiniMax-M2.1

前回に引き続き、中国発オープンモデルの厚みは圧倒的です。今回は3つの大型新顔が登場しました。

• GLM-5（0.7884）
  Z.aiの最新世代。総744B・アクティブ40BのMoEで、DeepSeek Sparse Attention（DSA）を採用。MITライセンスという太っ腹な公開形態です
  
• Kimi K2.5（0.7785）
  Moonshot AIの総1T・アクティブ32B MoE。視覚エンコーダを統合したネイティブマルチモーダルモデルで、エージェント用途を強く意識した設計です
  
• MiniMax-M2.1（0.7556）
  総229BのMoE。SWE-Bench系のコーディング・エージェント処理に特化した性格のモデルです

Qwen、DeepSeek、GLM（Z.ai）、Kimi（Moonshot）、MiniMaxの中国5社がオープンTOP12に揃う構図は今回も健在で、そこにGoogleのGemma 4が割って入った形です。

国産オープンモデルの新展開

日本発のオープンモデルにも今回、注目すべき動きがありました。

• RakutenAI-3.0（0.6761）
  楽天グループが3月に公開した総671B・アクティブ37BのMoEで、国産オープンモデルとしては最大級です。DeepSeek-V3系アーキテクチャを採用し、日英バイリンガルデータで構築されています（Apache 2.0）
  
• llm-jp-4-32b-a3b-thinking（0.6679）
  国立情報学研究所（NII）による総32B・アクティブ約4BのMoE推論モデル。11.7兆トークンをスクラッチから学習した、完全国産系の意欲作です
  
• Swallowシリーズの強化学習版
  東京科学大学（旧東工大）SwallowチームのRL版が拡充。GPT-OSS-Swallow-120B-RL-v0.1（0.6914）は国産系トップ級、Qwen3-Swallow-32B-RL-v0.2（0.6782）なども続きます

総合スコアではまだ0.70の壁の手前ですが、日本語に最適化された学習データと国内での運用のしやすさは、スコアに表れない価値です。

また韓国LG AI ResearchのK-EXAONE-236B-A23B（0.7186）が日本語を公式サポート言語に含めている点も、日本語ユーザーには朗報といえます。

さて、次は中規模10B～30B程度のモデルをみてみましょう。

中規模モデルのうれしいところは、個人レベルでも比較的入手しやすいGPUでも実行できるところではないでしょうか。

中規模モデル（10B-30B）総合スコアランキング

※上位100件のエクスポートデータに基づくため、前回掲載モデルの一部（gemma-3系など）は今回の集計対象外です。

中規模モデル総合スコアの傾向と考察

中規模カテゴリは前回王者のQwen3.5-27B（0.8049）が首位を守りましたが、2位にGemma 4 26B-A4B（0.7872）が新登場し、2強構図に変わりました。

Gemma 4 26B-A4BはMoE構造でアクティブパラメータがわずか4Bのため、推論時の計算負荷はdenseの27Bモデルより大幅に軽くなります。

「性能はQwen3.5-27B、推論コストはGemma 4 26B-A4B」という使い分けが成立しそうです。

4位のGPT-OSS-Swallow-20B-RL-v0.1（0.6424）は、OpenAIのオープンモデルgpt-oss-20bを日本語向けに強化学習したもので、日本語特化の中規模モデルとして貴重な存在です。

さて、最後に小規模モデルもみてみましょう。こうした小型モデルは比較的安価なコンシューマ向けGPUでも動作しますので、エッジ・オンプレ用途の本命です。

小規模モデル（10B以下）総合スコアランキング

小規模モデル総合スコアの傾向と考察

小規模モデルは前回に引き続きQwen3.5-4B（0.7352）が首位です。わずか4Bで、1年前なら30B級に相当したスコア水準を叩き出しており、小型化の進展を象徴しています。

日本語特化ならNemotron Nano 9B v2 Japanese

前回に引き続き2位のNVIDIA Nemotron Nano 9B v2 Japanese（0.7111）は、NVIDIAがMamba-2／Transformerハイブリッド構造のNemotron Nanoを日本語向けに追加学習したモデルです。推論のオン／オフや思考トークン量の制御（thinking budget）に対応しており、商用利用可能なライセンスで公開されています。日本語特化の小規模モデルとしては現状ベストの選択肢でしょう。

Gemma 4のオンデバイス版 E4B／E2B

Gemma 4 E4B（0.6692）とE2B（0.6564）は、スマートフォンやエッジデバイスでの動作を想定した小型版です。実効パラメータを抑えながらこのスコア帯に乗せてきており、「端末内で完結する日本語LLM」の実用ラインが着実に上がっています。

また7位のQwen3-Swallow-8B-RL-v0.2（0.6552）は、東京科学大学Swallowチームによる日本語強化学習版で、国産系の小規模モデルとして存在感を示しました。

まとめ、本格導入に向けての道しるべ

今回もNejumi Leaderboard 4のベンチマークデータを分析いたしました。今回の分析でみえたポイントをまとめます。

「0.85時代」の幕開けと、0.80の大衆化

今回の最大のポイントは、Claude Opus 4.8が史上初めて総合スコア0.85を突破したことです。

同時に、0.80超えモデルは19に達し、前回11、前々回4からほぼ倍増ペースが続いています。

0.80はもはや「フロンティアの証」ではなく「上位グループへの入場券」になりました。

• 商用API勢：Anthropic（Opus 4.8/4.7）、Google（Gemini 3.1 Pro）、OpenAI（GPT-5.5/5.4）の3強に、Alibaba（Qwen3.6 Max）が食い込む4強構図へ
  
• オープン勢：Qwen3.5が首位を堅持しつつ、Gemma 4・GLM-5・Kimi K2.5など新顔で層が厚く
  
• 国産勢：RakutenAI-3.0、llm-jp-4、Swallow RL版など、日本語特化の選択肢が着実に拡大

モデルサイズ別の特徴

LLMの本格導入にむけて：用途別の最適なモデル選択

今回は総合スコアを軸に各モデルの位置づけを見てきましたが、実際の導入判断はそれほど単純ではありません。

ベンチマークは有力な参考情報である一方、実務では精度だけでなく、導入コスト、推論コスト、応答速度、機密データの扱い、既存システムとの統合性など、多面的な評価が必要です。ライセンスもひとことでオープンソース、オープンモデルといっても、実はよく見ると落とし穴が存在している場合もあります。

とくに今回のように選択肢が急拡大した状況では、「最もスコアの高いモデルを一つ選ぶ」というより、「用途ごとに複数のモデルを適切に使い分けられる状態をどう作るか」が、導入の現場ではより重要になります。

当社では、こうした複数モデル運用の実務に対応する選択肢として、複数のLLMを1つのプラットフォームで利用できる統合AIプラットフォーム Bestllam を提供しています。

商用利用時の論点整理、モデルの選定から、業務フローへの組み込み、AIエージェント活用を前提とした運用設計まで含めてご支援可能です。

また、単なるツール提供にとどまらず、貴社業務のAI化を見据えたBPRコンサルティングもあわせてご提供しており、AIテクノロジーだけでなく、ビジネス上流の業務分析からAIネイティブ化BPR計画策定、成功指標の設計、導入支援まで伴走いたします。

まずはお気軽にご相談くださいませ
https://qualiteg.com/contact?inquiry=consulting

こんにちは！

2026年6月に登場した Claude Fable 5 は、公開直後の輸出規制による一時停止、グローバル再展開、そしてサブスクリプション枠からの離脱と、わずか1か月でめまぐるしい動きを見せています。

当ブログでもその時々の状況を追ってきました。

まず全体像は ついに一般公開、Claude Mythos 5 / Fable 5 を実務視点で読み解く で、公開直後の停止騒動は 公開から3日で停止──Fable 5／Mythos 5 をめぐる米政府指令が示した、AI の新しい可用性リスク で、料金と今後の見通しは Claude Fable 5 はこれからどうなる？ 経緯・コスト・今後の見通し で扱っています。

本記事は、それらを踏まえた「実務で使うための決定版ガイド」です。

とくに

2026年7月12日（日本時間7月13日）を境にサブスクリプション枠から外れ、使用クレジットを有効化しないと使えなくなる
(この期限は当初2026年7月7日とされていましたが、のちに5日間延長されて7月12日になりました。)

という料金面の大きな変更を軸に、モデル仕様・料金の実際・Claude Code での運用注意点までを一本にまとめました。Opus 4.8 との使い分けを含め、

「Fable 5 にいくら払う価値があるのか」

を自分で判断できる材料を提供いたします。

そこで、このガイドは、Anthropic の公式発表・公式ドキュメントを基準に、
Claude Fable 5（claude-fable-5）を

「モデルとして理解する」
「料金とサブスク枠の扱いを把握する」
「安価なモデルとFableを組み合わせてClaude Code で経済的に運用する」

の3点から整理しています。

それでは、さっそく本編に入りたいと思います。

ちなみに、本記事公開時点(2026/7/10)の早朝に、1週間のrate limitが急遽解除され、実質的にFable5の利用枠が急遽また増えました

目次

• 第1部：Claude Fable 5とは何か
  • Fable 5の位置づけ
  • 発表・輸出規制・再展開のタイムライン
  • モデルとしての仕様
  • 企業利用前に確認すべき制約（データ保持）
  • ベンチマークの読み方
  • 主要なAPI差分
  • Mythos 5との関係
• 第2部：料金とサブスク枠からの移行（最重要）
  • 提供方法の変更と7月7日から7月12日への期限延長
  • 使用クレジットの仕組みと管理画面
  • 上限・残高・事前購入の割引（それぞれ別物）
  • コスト試算と、自分で実測する方法
  • 価格比較（2026年7月9日時点）
• 第3部：Claude Code で使う Fable 5
  • 前提条件とモデル選択
  • クレジットの有効化と上限設定
  • effort・1Mコンテキスト・プロンプトキャッシュ
  • 拒否（refusal）とフォールバックの実務
  • Fable 5 を Claude Code で現実的に使う ― 司令塔と実働でモデルを分ける
  • 安全分類器による誤検知への対処
• まとめ ― Fable 5 との付き合い方

第1部：Claude Fable 5とは何か

Fable 5の位置づけ

Claude Fable 5 は、Anthropic が 2026年6月9日 に発表した、現時点で同社が一般提供（GA）する中で最も高性能なモデルです。

公式ドキュメントは Fable 5 を

「最も高度な推論と、長時間にわたる自律的（エージェンティック）な作業のために設計された、Anthropic が広く提供する中で最も高性能なモデル」

と位置づけています。

鍵になるのは 「long-horizon agentic work（長時間の自律作業）」 です。

Fable 5 の特徴は、単発の質問応答よりも、タスクが長く複雑になるほど他モデルとの差が広がる点にあります。

発表時に Anthropic が挙げた事例として、決済基盤の Stripe は「5,000万行を超える Ruby コードベースのマイグレーションを、通常ならチームで2か月以上かかる作業を1日で完了した」と初期利用事例として報告しています（これは一般的な性能保証ではなく、Stripe の報告である点に注意してください）。

Fable 5 は「Mythos-class（ミュトス級）」、すなわち Anthropic の最上位研究モデルと同一系統の能力を持ちながら、一般利用に耐える安全対策（セーフガード）を組み込んで公開されたものです。

なぜ「Opus 4.8のアップグレード版」ではないのか
Fable 5 は Opus の後継ではありません。Opus 4.8（claude-opus-4-8）は依然として「Opus階層の最新・最上位」であり、多くの実務ではこちらが標準です。Fable 5 は Opus階層の上に位置する、価格も能力も別枠のモデルです。したがって「最新モデルにアップグレードしたい」という一般的な要望に対する答えは、今でも Opus 4.8 です。Fable 5 は「最も難しい問題を、コストを承知のうえで解かせたい」ときに明示的に選ぶモデルだと理解してください。

発表・輸出規制・再展開のタイムライン

Fable 5 は、安全保障・輸出規制が絡んだ異例の経緯をたどりました。

時系列で整理します。

再展開にあたり Anthropic は、新しいセーフガード分類器を導入しました。公式説明では「Amazon の報告書で説明された特定の手法は99%以上のケースでブロックされる」ようになった一方で、「安全マージンを大幅に拡大した」結果、良性（benign）なリクエストもより多くブロックされるようになりました。

Anthropic は、

"In the near term, some routine tasks like coding and debugging may be flagged more often."
（当面のあいだ、コーディングやデバッグのような日常的なタスクが、これまでより頻繁にフラグされる可能性がある）

と明言しています。これは Claude Code で Fable 5 を使ううえで実務的に重要なので、第3部で改めて扱います。

なお、この輸出規制による一時停止と再展開の経緯そのもの（そこから見える「AI の新しい可用性リスク」）は、

公開から3日で停止──Fable 5／Mythos 5 をめぐる米政府指令が示した、AI の新しい可用性リスク

で詳しく掘り下げています。

モデルとしての仕様

主要スペックを公式ドキュメントベースで整理します。単価は後述の通り2026年7月9日時点のものです。

• 1Mコンテキストは標準料金で、長文コンテキストに対する追加料金（プレミアム）はありません。
• トークナイザが Opus 4.8 と同一なので、Opus 4.7 / 4.8 から移行する場合、同じテキストのトークン数はほぼ変わりません。
  変わるのは単価です。Opus 4.6 以前・Sonnet・Haiku から移る場合はトークン数が変動するため、count_tokens で再計測してください。

企業利用前に確認すべき制約（データ保持）

Fable5には以下の用な制約があります。
よんでみて、ピンとこなくても大丈夫です。
そのしたに　ざっくり説明　をいれました

Fable 5 / Mythos 5 は「Covered Models」で、30日データ保持が必須です。ゼロデータ保持（ZDR）では利用できません。

これはモデル性能や料金以上に、企業導入の可否を左右する制約です。導入前に最低限、以下を確認してください。機密コードやデータを Fable 5 に送信できる契約・社内規程になっているか。既存の ZDR前提のワークロードは、そのままでは移行できない。30日保持はすべての提供プラットフォームで必要ですが、400 invalid_request_error が公式に明記されているのは Claude API（組織/ワークスペースの保持設定が要件を満たさない場合）です。Claude Code や各クラウド経由での表示・エラー挙動は接続先によって異なります（モデル選択肢から Fable が消える等）。Bedrock / Vertex / Foundry など接続先プラットフォームごとに、保持場所・条件を確認する。

ざっくり説明→基本のルール

つまり上記はどういうことかというと、私たちがFable 5 に送った文章と、Fable 5 が返した文章は、30日間かならず保存されます。消せません。断れません。

他の Claude（Opus 4.8 など）は「保存しない」設定にできます。Fable 5 だけできません。

なぜ保存するのか

Fable 5 は強力なので、悪用を見張るためです。悪用は1回のやりとりでは見抜けず、何百回分を並べて初めて「あ、これ攻撃だ」とわかるからです。保存したデータをAIの学習には使いません。

何が問題か

これまで「うちのデータは一切保存しない」という契約（ZDR）を結んでいた会社があります。その契約は、Fable 5 には効きません。契約より優先されます。

つまり、機密のソースコードや顧客データを Fable 5 に投げると、それが30日間どこかに残ります。しかも危険と判定されたら、人間が中身を見る可能性があります。

ベンチマークの読み方

ベンチマークについて詳しくは以下、当社別記事に譲りたいと思います。

ついに一般公開、Claude Mythos5(ミュトス)/ Fable 5(フェイブル) を実務視点で読み解く

こんにちは！ Qualitegプロダクト開発部です。 2026年6月9日、Anthropicから Claude Fable 5（フェイブル5）と Claude Mythos 5（ミュトス5）が発表されました。 この記事では、 Fable 5 とは何か、Mythos 5 と何が違うのか、 Claude Code やAIエージェントを実務で使う立場から見て何が変わるのか を整理します。当社ブログを読んでくださっている方は、4月の「強すぎて出せないモデル “Mythos”」や「Mythosレベルのオープンモデルはいつ出るのか」でも触れた、あの Mythosクラスの一般公開版がついに来た、という話でもあります。 この記事でわかること * Fable 5 と Mythos 5 は「同じ基盤モデルだが、安全装置の有無が違う」こと * 高リスク領域では応答が Opus 4.8 にフォールバック

Qualiteg BlogQualiteg コンサルティング

主要なAPI差分

まずAPIについてOpusとの差分をみてみましょう。

Fable 5 は基本的に Opus階層（4.7 / 4.8）と API のリクエスト面が概ね共通ですが、移行時に既存実装が 400 になる差分があります。
主なものだけ挙げます（網羅ではありません）。

1. 思考（thinking）は常時ON

Adaptive thinking が唯一の思考モードで、thinking を省略すれば自動的に有効になります。明示的に thinking: {type: "disabled"} を送ると 400（Fable 5 固有。Opus 4.7 / 4.8 では disabled が通ります）。budget_tokens も廃止で、送ると 400 です。深さは output_config.effort（low〜max）で制御します。

2. サンプリングパラメータは非対応

temperature / top_p / top_k は非デフォルト値を送ると 400 になります。出力の傾向はプロンプトで制御します。

3. max_tokens は思考＋最終回答の合計

max_tokens は思考トークンと最終回答の両方を含む上限です。高 effort では思考が多くのトークンを使うため、上限が小さいと回答が途中で切れます。

4. 生の思考連鎖（raw chain of thought）は返らない

返るのは通常の thinking ブロックで、display: "summarized" なら要約が入り、"omitted"（デフォルト）は空文字列です。思考は表示設定に関わらず実行・課金されます。

5. 拒否（refusal）という停止理由

Fable 5 は入力に安全分類器を走らせます。拒否されると、エラーではなく HTTP 200 の成功レスポンスとして stop_reason: "refusal" が返り、stop_details にカテゴリが入ります。

• 出力前の拒否：content は空で、課金なし。
• ストリーム途中の拒否：生成済みの部分は課金対象（部分出力は使わず破棄）。

response.content[0] を無条件に読むコードは壊れます。必ず stop_reason を先に確認してください。実務では次の順序で判定します。①HTTPステータス → ②stop_reason → ③stop_details を記録 → ④content が空でないことを確認 → ⑤拒否時は部分出力を使わない。

6. フォールバック（拒否を別モデルで救う）

サーバーサイドの fallbacks は、ポリシー拒否時に同一リクエストを別モデルで自動再実行するオプトインのβ機能（server-side-fallback-2026-06-01）で、明示的に指定する必要があります（既定でONにはなりません）。

現時点で使えるのは Claude API と Claude Platform on AWS で、

Message Batches API・Amazon Bedrock・Google Cloud・Microsoft Foundry では利用できず、

クライアント側の再実行か SDK ミドルウェアが必要です。移行先モデルはリクエストの fallbacks 配列で明示的に指定します
（公式例は Opus 4.8。Anthropic API が自動的に Opus 4.8 へ固定するわけではありません）。

接続先によって異なるのは「サーバーサイド fallbacks を使えるかどうか」です。新規に claude-fable-5 のコードを書くなら、このフォールバックを明示的に入れておくことを推奨します。

Mythos 5との関係

Claude Mythos 5（claude-mythos-5）は、Fable 5 と同じ基盤モデル・コンテキスト長・最大出力・料金体系を持ちます。

ただし、Fable 5 に追加された安全分類器を搭載していないため、拒否や自動フォールバックを含む実際の API 挙動は同一ではありません
（拒否・フォールバックの説明は Fable 5 にのみ適用されます）。

Mythos 5 は Project Glasswing 参加組織などへの限定提供で、一般ユーザーは claude-fable-5 を使います。

招待制だった旧 claude-mythos-preview の後継にあたります。Mythos 5 と Fable 5 の位置づけの違いやベンチマークの読み解きは、ついに一般公開、Claude Mythos 5 / Fable 5 を実務視点で読み解く もあわせてご覧ください。

第2部：料金とサブスク枠からの移行（最重要）

提供方法の変更と7月7日から7月12日への期限延長

Fable 5 が7月1日に再提供された際、サブスクリプションに含まれる形での提供には期限が設けられていました。

当初その期限は2026年7月7日でしたが、最初の期限の直前に、急遽、Anthropic はこれを5日間延長し、最終的に2026年7月12日（米太平洋時間の23:59:59、日本時間では7月13日）までとしました。

週間枠の最大50%までという割合や、期限を過ぎるとクレジット経由の利用に切り替わる点は、7/1再提供当初から変わっていません。

終了時刻は7月12日の23:59:59（米太平洋時間、日本時間では7月13日の午後）です。実際の切り替えのタイミングはアカウント画面（後述）でも確認してください。

将来サブスクに戻る可能性について
Anthropic は、将来的に容量（capacity）が確保できればサブスクリプション枠へ再び含めたいとの意向を示していますが、時期や実施は確約されていません。今回のように期限が動くこともあるため、最新の公式案内を確認しつつ、当面はクレジット前提で運用計画を立てるのが現実的です。

使用クレジットの仕組みと管理画面

使用クレジットは、Pro / Max などの有料プランに用意された従量課金のレイヤーです。もともとは「プラン上限に達した後も作業を続けられるように」設計されたもので、7月12日終了後（日本時間7月13日〜）はこれが Fable 5 への入り口になります。

ただし、「一般的な追加使用クレジット（プラン上限到達後の継続用）」と「7月12日終了後の Fable 5 の提供」は、公式には別の案内です。

Anthropic は後者について「使用クレジット経由で提供する」と説明しており、Fable 5 が通常枠を消費してからクレジットに移るのか、最初からクレジット消費なのかといった具体的な消費順序は断定しません。実際の枠消費はアカウント画面と最新の公式案内で確認してください。

管理は claude.ai の 設定 → 使用量（Settings → Usage） から行います。実際の画面（サブスク枠を使い切り、クレジットをONにした状態）を見ると、仕組みが具体的に分かります。

設定できる人はプランで異なります。以下の画面例と手順は Pro / Max の個人アカウントを前提としています。Team および seat-based Enterprise では、Owner / Primary Owner が「組織設定（Organization settings → Usage）」から有効化・上限設定を行います。usage-based Enterprise は、含まれる枠を使い切る方式ではなく、原則として最初のトークンから従量課金です。

※2026年7月上旬時点の当社アカウントの表示例。Fable5のサブスク枠を使い切ったあとクレジット枠に移行しているのがわかります。

この画面から読み取れるポイントは次の通りです。

• モデルごとに利用枠が別表示される。「すべてのモデル」と「Fable」が別々のバーで示され、上の例では Fable 枠が100%使用済み（サブスク枠を使い切った状態）。
• 利用クレジットのON/OFFを切り替えられる。「上限に達した場合でも Claude を使い続けるために」クレジットをONにする、という位置づけ。
• 使用量がリアルタイムで表示される（例：$68.69使用 / 上限に対して27%使用、リセット日つき）。

上限・残高・事前購入の割引（それぞれ別物）

クレジットONにすると再現なく使ってしまうのではないか？

そんな心配があるかもしれませんが、
クレジットの上限を設定することが可能です

クレジットON時には、以下の3つの概念があります

• 月間支出上限
  その月に使えるクレジット支出の上限（例：$250.00）。「上限を調整」から変更できます。ただし 「上限なし」も選べるため、クレジットを有効化しただけでは支出上限は保証されません。とくに自動チャージを使う場合は、月間上限が意図した金額になっているかを必ず確認してください。
  
• 保有クレジット残高
  現在持っている残高（例：$181.31）。自動チャージの ON/OFF で、残高が減ったときに自動で買い足すか、手動にするかを制御します（自動チャージ＋上限なしの組み合わせは、実質的に青天井になり得ます）。
  
• 割引バンドル（事前購入）
  上限や残高とは別の「まとめ買い商品」です。あらかじめ課金枠をチャージしておくようなイメージです。
  
  $50相当＝10%引き（支払い$45）
  $250相当＝20%引き（$200）
  $1,000相当＝30%引き（$700）
  
  たとば、250$ぶんを購入すると20%割引が適用され 200$で買うことができます。実際には消費税10%がのって220$を支払うことになります。
  
  

まとめると、Fable 5 のコストは、月間上限（＝設定しないと上限なし）・保有残高・自動チャージ・割引バンドルの事前購入という別々のレバーで管理する設計です。

月間上限を設定することで、青天井を避けることができ、また事前にチャージしておくと少しお得に課金枠を購入することができる、という感じです。

コスト試算と、自分で実測する方法

Fable 5 の単価（入力 $10 / 出力 $50 per 1M）をもとに、単純試算を示します。いずれもキャッシュなし・再試行なし・フォールバックなし・税/為替影響なしの前提です。

ケースA：チャット中心（1日あたり入力20万＋出力5万トークン）

• 入力：0.2M × $10 = $2.0
• 出力：0.05M × $50 = $2.5
• 1日あたり 約 $4.5 → 月あたり 約 $135

これは、Fable 5 の利用分がすべてクレジット課金されたと仮定した単純試算です。

ケースB：Claude Code の自律コーディング

コスト面で効いてくるのは、チャットよりもエージェンティックなコーディングです。Claude Code の長いセッションは、コンテキスト読み込み・ツール呼び出し・自己検証を繰り返すため、トークン消費が大きくなります。

ただし、実際の消費はモデル・コードベース規模・並列実行（サブエージェント数）・キャッシュの有無・再試行/フォールバック・利用形態によって大きく変動します。

公式ドキュメントも、コストはこれらの要因で大きく変わると説明しています。

「1時間あたり何ドル」といった一般化は、測定条件が揃わないと当てになりません。自分の環境で実測するのが確実です。

具体的には、1セッションについて以下を記録し、単価表（入力$10 / 出力$50 / キャッシュ読み出し$1 / キャッシュ書き込み$12.50〜$20、いずれも per 1M）に当てはめます。

• 使用モデル / 入力トークン / 出力トークン
• キャッシュ作成トークン / キャッシュ読み出しトークン
• フォールバック回数 / サブエージェント数 / セッション時間

Fable 5 は Opus 4.8 の2倍単価なので、常用すればクレジット消費は無視できない規模になり得ます。

だからこそ、第3部の「いつ Fable 5 を使うか」の判断が、そのままコスト管理になります。

価格比較（2026年7月9日時点）

• Sonnet 5 は、2026年8月31日までは導入価格として入力$2・出力$10が適用されています（現在適用中の価格）。9月1日以降の標準価格は入力$3・出力$15です。
• Fable 5 の単価は Opus 4.8 のちょうど2倍で、現在一般利用できる主力モデルの中では最も高価格な部類に入ります（「史上最も高価」ではありません。過去には Opus 4.1 のように、より高い単価のモデルも存在しました。また Anthropic 自身、Fable 5 を旧 Mythos Preview の半額未満と説明しています）。

「単価2倍」と「実効コスト2倍」は別物

ここが最も誤解しやすい点です。上の $10 / $50 はトークン単価の比較であって、1タスクあたりの実際のコストが2倍で収まるとは限りません。実効コストが単価倍率（2倍）を上回りやすい理由は主に2つあります。

1. Fable 5 は Adaptive thinking が常時ON。
   思考（thinking）トークンも出力として課金され（Fable 5 では $50 / 1M）、max_tokens は思考＋最終回答の合計です。一方 Opus 4.8 は思考をオフにでき（thinking 省略時は思考なしで動く）、同じタスクでも Fable 5 のほうが高い側＝出力トークンを多く消費しがちです。単価が高い出力側でトークンが増えるので、費用は二重に効きます。
   
2. Fable 5 はもともと深く長く考える設計です。
   難しいタスクでは1リクエストが数分〜十数分走ることも珍しくなく、その分だけ思考・出力トークンが積み上がります。長時間の自律タスクほど、この差は大きくなります。

つまり実効コストは「単価2倍 × 生成トークン量の増加」で決まります。倍率は 2倍〜それ以上（高 effort ではさらに）になり得ます。「Opus 4.8 の2倍払えば同じ仕事ができる」という感覚で見積もると、請求額は想定を超えます。

コストを効かせるレバー

• effort を下げる。Fable 5 は低 effort でも強く、思考トークンを直接減らせます（実効コストに最も効く）。
• max_tokens を適切に絞るか、Task Budgets（API のみ）でループ全体のトークンを制御する。
• 前章の実測で、入力・出力・思考（＝出力に含まれる）・キャッシュを分けて把握する。
• 注意：プロンプトキャッシュが割り引くのは入力側だけです。増えがちな思考・出力トークンはキャッシュで安くならないため、「キャッシュを効かせれば2倍に収まる」とは考えないでください。

したがって Fable 5 を選ぶかどうかの問いは、「単価が2倍」ではなく
「実効で2倍以上になり得るコストを払ってでも、Opus 4.8 では届かない難問を解きたいか?」 です。

第3部：Claude Code で使う Fable 5

ここでは、Claude Code で本格的にFable5を活用するシーンについて考えてみたいとおもいます。

前提条件とモデル選択

Fable 5 は Claude Code の対応モデルです。まずは使ううえでの前提を先に押さえましょう。

• 対応バージョンを確認する。公式ドキュメントによれば、Fable 5 の利用には比較的新しい Claude Code が必要です。まぁ、最新のClaude Code CLIを使いましょう。
  
• 既定モデルはプランによって異なる
  Fable 5 はどのプランでも既定モデルではありませんので、使いたければ /model コマンドで明示的にFable5を選択します。

クレジットの有効化と上限設定

前述のとおり、7月12日終了後（日本時間7月13日〜）、Claude Code から Fable 5 を呼ぶには、claude.ai 側でクレジットを有効化しておく必要があります。

1Mコンテキストとプロンプトキャッシュ

Fable 5 は1Mトークンのコンテキストを標準料金で使えますが、載せた分だけトークン消費（=コスト）は増えます。固定的な大きいコンテキスト（コードベース、仕様書）はプロンプトキャッシュを活用します。ただし価格の理解が必要です。

• キャッシュヒット時の読み出しは $1 / 1M と安い。
• 一方、初回のキャッシュ書き込みには 5分保持で $12.50 / 1M、1時間保持で $20 / 1M がかかる。

つまり、繰り返し参照する固定コンテキストでなければ、キャッシュはむしろ割高です。同じプレフィックスを何度も使うワークフローでこそ効きます。

Task Budgets は Claude Code では使えない
API には、エージェンティックループ全体のトークン予算をモデルに伝える Task Budgets（β）がありますが、これは Messages API 向けの機能で、Claude Code / Cowork では利用できません。また強制的な上限ではなく、モデルに伝える「目安」です。自前の Messages API エージェントを実装する場合にのみ使えます。

拒否（refusal）とフォールバックの実務

再提供版 Fable 5 は安全マージンを広げているため、コーディングやデバッグのような良性タスクでも誤検知（false positive）で拒否されることが以前より起きやすくなっています。

• Claude Code をそのまま使っている場合
  対応する接続先で Fable 5 とフォールバック先の Opus モデルを正しく識別できる場合は、拒否時に自動フォールバックします。
  かなりセンシティブな印象で、正直よく誤検知します。それについては口述します。
  
• API を自前で叩くエージェントを組んでいる場合
  stop_reason == "refusal" を必ずハンドリングし、オプトインのサーバーサイド fallbacks を明示的に指定しておく。利用できるのは Claude API と Claude Platform on AWS で、それ以外（Batches・Bedrock・Vertex・Foundry）はクライアント側の再実行や SDK ミドルウェアが必要。移行先はリクエストの fallbacks 配列で明示指定（公式例は Opus 4.8）。接続先で異なるのは「利用可否」の方。

Fable 5 を Claude Code で現実的に使う

司令塔(Fable)と実働(Opus,Sonnet)でモデルを分けよう

有料化後の Fable 5 は単価が高く（Opus 4.8 の2倍。思考が常時ONのため実効コストはさらに上がりがちです）、ファイル読み・試行錯誤・長時間の自律実行まで含めて何もかもを Fable 5 にやらせるのは、正直なところ経済的ではありません。

そこで当社Qualitegが実際に採っているのが、1つの Claude Code セッションを「司令塔」と「実働」に分け、役割ごとに別モデルを割り当てるやり方です。

基本の発想はシンプルです

• 司令塔＝Fable 5
  方針の決定・タスク分解・指示書の発行・報告の検収（合否判定）・次の一手の判断に専念する。自分ではコードやログを読まず、実装もしない。
  
• 実働＝Opus 4.8 / Sonnet 5 のサブエージェント
  探索・調査・実装・テスト・文書化といった「手を動かす作業」をすべて引き受け、司令塔には短い報告だけを返す。
  
• 実働は2層で使い分ける
  判断や設計理解が要る作業は Opus、手順が完全に決まった機械的な定型作業（一括リネーム・ログ収集など）は Sonnet に落とす。

ねらいは明快で、高価なモデルの価値は「判断」に集中しています。

過程（大量のファイル読み・試行錯誤・ログ）はサブエージェント側のコンテキストで消化させ、司令塔には結論だけを返させれば、Fable 5 のクレジットとコンテキストは"判断の瞬間"だけに使われます。

「Fable 5 が全部やる」から「Fable 5 は考える人、手は安いモデル」

に変えるだけで、クレジット消費は大きく下げられます。

もちろん、日常的な小さな修正はそもそも司令塔を立てず、既定モデル（Opus 4.8 / Sonnet 5）で直接こなすほうが早くて安上がりです。

司令塔メソッドが効くのは、大規模なマイグレーションや、受け入れ条件が明確な大規模実装、並列サブエージェントを使う大規模な調査といった"難所・大物"の局面です。

この Fable司令塔メソッド は、導入手順・委任プロンプトの型・並列サブエージェントの采配・CLAUDE_CODE_SUBAGENT_MODEL によるモデル固定の設定まで含めて、別記事であらためて詳しくご紹介しますのでお楽しみに。

本記事では「高い Fable 5 は司令塔に据え、手は Opus / Sonnet に任せる」という考え方だけ、まずは押さえていただければとおもいます。

安全分類器による誤検知への対処

再提供版の分類器は、サイバーセキュリティ・生物/化学などを対象に安全マージンを広げています。

ここで「意図的なブロック」と「誤検知（false positive）」を混同しないことが重要です。

1. 拒否は「エラー」ではなく「コンテンツ結果」として扱う
   stop_reason を確認し、拒否ならフォールバックや Opus 4.8 切り替えに回す。
   
2. 明確に意図されたブロック対象
   exploit チェーンの構築、マルウェア生成、攻撃ツールの作成など、攻撃的なサイバー能力を直接提供する要求は、当然ながら、Fable 5 の分類器が意図的に制限する対象です。これは誤検知ではなく設計上の制限です。
   
3. 安全マージンによるブロックと誤検知
   脆弱性探索・侵入テスト・PoC 作成などは、内容によっては攻撃にも防御にも使える曖昧な領域です。Fable 5 は安全側に広く判定するため、正当な防御目的の作業もブロックされることがあります。加えて、通常のコーディング・デバッグ・設定変更・依存関係更新など、本来は問題ない作業が巻き込まれる場合もあります。
   Anthropic は、こうした無害な要求の拒否を false positive（誤検知） と位置づけ、「本当の悪用と正当な要求をよりよく区別する」方向で今後改善するとしています。曖昧領域や誤検知と思われる場合は、正当な目的・所有関係・許可範囲を明確にして再依頼し、なお拒否されるならフォールバックや Opus 4.8 への切り替えを検討します。

関連記事：Fable 5 on Claude Code が「来なかった攻撃」を検知・拒否・反省した実体験は AI は、来なかった攻撃を「検知」し、「拒否」し、「反省」した に、正規の運用作業が Usage Policy 違反と判定されてしまう問題への対処は Claude Code で正規の運用作業が「Usage Policy違反」になる理由 にまとめています。

まとめ ― Fable 5 との付き合い方

Claude Fable 5 は、Anthropic が一般提供する中で最も高性能なモデルです。要点を5つに絞ります。

1. Fable 5 は Opus の後継ではなく、上位の別枠
   日常は既定モデル（Opus 4.8 / Sonnet 5）、難所だけ Fable 5、が基本。
   
2. サブスク枠に含まれるのは2026年7月12日（日本時間7月13日）まで
   この期限を過ぎると claude.ai でクレジットを有効化しないと使えない。
   とはいえ、直前でまた日程や方針が変更される可能性もあり、恒久措置とは限らず期限が動くこともあるため、最新の公式案内を確認しつつ、当面はクレジット前提で。
   
3. クレジットは自分で上限を設定して管理する
   （設定しなければ「上限なし」になり得る）。月間支出上限・保有残高・自動チャージ・割引バンドル（最大30%オフ）は別々のレバー。単価は Opus 4.8 の2倍だが、常時ONの思考でトークン消費が増えるため実効コストは2倍を超え得る（effort を下げるのが最も効く）。必ず実測する。
   
4. 長時間・自律・複雑なタスクほど強い
   最初に成果と制約を明示し、適切な effort で、並列サブエージェントを活かす。ただしなるべく「考える、判断」にFable5、手足にOpus,Sonnetをつかうことで、経済効率的にすすめられる。
   
5. 安全分類器に注意
   良性のコーディング/デバッグでも拒否され得る（誤検知）。一方、攻撃コード・認証回避などは誤検知ではなく意図的な制限で、正当な業務でも通らないことがある。stop_reason を扱い、フォールバックを用意し、該当領域は Opus 4.8 など別モデルに回す。

「実効で2倍以上になり得るコストを払ってでも、Opus 4.8 では届かない難問を解きたいか?」
この問いに Yes と答えられるタスクにだけ Fable 5 を投じる。またFable5にすべてをやらせず、司令塔と実働のモデルをわける。これらが、この高性能かつ高価格なモデルとの現実的な付き合い方です。

おわりに ― モデル環境の変化に振り回されないために

Fable 5 の一連の動き（輸出規制による一時停止、グローバル再展開、サブスク枠からの離脱、そして実効コストの読みにくさ）は、特定のモデルに強く依存することのリスクを改めて突きつけました。

最高性能のモデルほど、可用性も料金体系も短期間で変わり得ます。だからこそ、「そのモデルが使えなくなったら／高くなったら、すぐ別の選択肢に切り替えられるか」という視点が重要になります。

株式会社Qualitegのコンサルティングサービス では、今回ご紹介した知見をはじめAIネイティブ開発の実践知を豊富に保有しておりAIエージェントを活用したAIネイティブなソフトウェア開発プロセス革新や Claude Code を徹底活用 のご支援を提供しております。

ご興味ございましたら、ぜひ Qualiteg へご相談ください。

先端AIモデル・AIネイティブな開発プロセス、AIセキュリティの知見を踏まえて、貴社に最適な形をご提案します。

それでは、また次回、お会いしましょう！

参照した一次情報

• Claude Fable 5 and Claude Mythos 5 — Anthropic
• Introducing Claude Fable 5 and Claude Mythos 5 — Claude Platform Docs
• Redeploying Claude Fable 5 — Anthropic
• Claude Fable 5 promotional access — Anthropic 公式サポート
• Models overview / Pricing — Claude Platform Docs

こんにちは！

前回の記事では、AI時代のデータ漏洩防止における技術的な基礎として、HTTPSインターセプトの仕組みと限界について詳しく解説しました。プロキシサーバーによるSSL/TLS通信の復号化、中間CA証明書の運用、そして証明書ピンニングという技術的制約まで、企業がWeb通信を監視する際の技術的な現実を明らかにしました。

しかし、これらのプロキシ技術は、実は既存のDLP製品でも広く採用されている一般的な手法です。メール監視、ファイル転送の制御、Webアクセスの監査など、従来型のデータ漏洩防止においても、HTTPSインターセプトは中核的な役割を果たしてきました。

では、なぜAI時代において新たにDLPを考え直す必要があるのでしょうか。

前回にひきつづき、従来型DLPでは対応できないAI固有の課題と、AI-DLPとして新たに考慮すべき要素に焦点を当て、より本質的な議論を展開していきます。

1. AI時代が要求する新たなDLP要件

従来のDLP製品は、クレジットカード番号や社会保障番号といった定型的なパターンの検出において優れた実績を持っています。これらの技術は今後も重要な基盤として機能し続けるでしょう。しかし、AI時代においては、これに加えて全く新しい要件が生まれています。

自然言語で表現される機密情報

最も大きな変化は、自然言語で表現される機密情報への対応が不可欠となったことです。例えば、
「うちで開発中のProject Phoenixという新製品があるんだけど、この製品名で効果的なマーケティング戦略を提案してもらえる？」
といった問い合わせに対しては、従来のキーワードマッチングを進化させた対策が必要です。「Project Phoenix」が機密のコードネームであることを認識し、その文脈から情報漏洩リスクを判断する、より高度なアプローチが求められるのです。

さらに複雑なのは、同じ情報でも文脈によってリスクレベルが変化するという点です。「弊社の売上高は1,200億円です」という情報は、それが公開済みの前年度実績なら問題ありませんが、未公開の今年度予測なら重大な機密情報となります。

また、社内向けのAIツールに対してなら許可されても、外部のChatGPTには送信すべきでない情報も存在します。このような文脈依存型のリスク判定は、組織の情報公開状況、送信先のAIサービスの種類、ユーザーの権限レベルなど、複数の要素を総合的に判断する高度な仕組みを必要とします。

会話が進むにつれて、断片的な情報が組み合わさり、機密性の高い全体像を形成

そして、LLMとの対話がマルチターンで展開されるという特性が、従来のDLPでは想定されていなかった新たな課題をもたらします。単一のメッセージだけを見れば機密情報は含まれていなくても、会話が進むにつれて、断片的な情報が組み合わさって機密性の高い全体像を形成することがあります。

例えば、エンジニアが「Pythonで大容量データを効率的に圧縮する方法を教えて」という一般的な技術質問から始めたとします。ChatGPTが提案したアルゴリズムについて
「実は私たちが開発しているシステムでは、毎秒10GBのセンサーデータを処理する必要があって」と具体的な要件を追加し、さらに「現在使っている独自の圧縮率は85%なんだけど、これを超える方法はある？」
と会話を続けていくうちに、意図せずして自社の技術的優位性や開発中のシステムの詳細を明かしてしまう可能性があります。

人間どうしの会話でもありますよね。会話が盛り上がっていくうちに、ついうっかり機密情報をしゃべりそうになってしまった・・・

AIの場合は場合によっては対人間よりも安心して相談してしまうことがありそうです

このような累積的な会話による情報漏洩リスクを検出するためには、AIによる深い洞察と、会話全体の文脈を継続的に分析する能力も必要となってきます。

このように一つ一つの発話は無害に見えても、それらが組み合わさることで生まれる情報漏洩のリスクもAI時代のDLP、AI-DLPの腕の見せ所となりますし当社のLLM-Audit シリーズもがんばっています。

また、AIとの対話がリアルタイムで進行するという特性も重要な制約となります。メールやファイル転送であれば、送信前に数秒の検査時間があっても許容されますが、AIとの対話ではわずか1秒の遅延でもユーザー体験を損ないます。

従来はメール送れば、一仕事おわるので、送信が監査により遅くなってもそれほどストレスはたまらないかもしれませんが、AIとの会話は人間との会話と同様リアルタイムで進行しますので、AI-DLPの監査介入によりいちいち何秒も待たされたら「返事おせーな、やってられない！」となってしまうわけです。

この厳しい時間制約の中で、進行中の会話の文脈を維持し、単一の発話、マルチターンでの発話群のリスクの変化を瞬時に評価できる技術開発の必要があります。

2. 双方向監査という新しいパラダイム

従来のDLPは、組織から外部への情報流出、つまりアウトバウンドの防止に焦点を当てていました。機密情報の送信、個人情報の漏洩、知的財産の流出といったリスクは、確かに今でも重要です。しかし、AI時代においては、これだけでは不十分です。

AIからの応答、つまりインバウンドの情報も同様に、あるいはそれ以上に重要になってきています。AIが生成する情報には、誤情報やハルシネーション、不適切なコンテンツ、コンプライアンス違反の助言、さらには悪意のあるコードが含まれる可能性があります。これらは組織に新たなリスクをもたらします。

例えば、法務部門の従業員が契約条項についてAIに相談した際、AIが誤った法的解釈を提供したらどうなるでしょうか。あるいは、エンジニアがコードの最適化をAIに依頼した際、セキュリティホールを含むコードが生成されたらどうなるでしょうか。これらのリスクは、従来のDLPでは全く想定されていなかったものです。

AIの応答品質を管理することは、組織の意思決定の質を保つ上で極めて重要になっています。事実の正確性、特に数値や日付の検証、法的・倫理的な適切性の確認、組織のポリシーとの整合性チェック、そして潜在的なバイアスの検出など、多角的な検証が必要です。技術的にも非常に高難度ですが、これは単なる技術的な課題ではなく、組織のガバナンスそのものに関わる問題にもなってくるため、重要な論点となります。

3. AI-DLP固有の技術的アプローチ

このような新たな要件に対応するため、AI-DLPでは従来とは異なる技術的アプローチが必要となります。その中核となるのが、階層型処理アーキテクチャです。

全ての通信を同じレベルで詳細に検査することは、パフォーマンスの観点から現実的ではありません。そこで、リスクレベルに応じて処理の深さを動的に調整するアプローチが有効です。まず高速スクリーニングで明らかに問題のない通信を素早く通過させ、疑わしいものだけをより深い分析にかけるのです。

初期段階では、基本的なキーワードマッチングや既知のパターン検出を5ミリ秒以内で実行します。これだけで、全体の95%以上の通信は問題なく通過できるでしょう。次の段階では、形態素解析や固有表現抽出(NER)といった自然言語処理技術を用いて、より詳細な構造解析を行います。これもユーザー体験を考慮し100ミリ秒オーダーで完了する必要があります。

さらに高度な判定が必要な場合は、BERTやDeBERTa,RoBERTaといった深層学習モデルを用いた文脈解析を実施します。これらのモデルは、文章の意味を深く理解し、微妙なニュアンスも捉えることができます。また、冒頭に例示したマルチターンの会話によって蓄積された文章のリスク評価にも向いています。
そして、最終的に、最も複雑なケースでは、専用に訓練されたLLMによる総合的な判定を行います。ここでは、組織固有のビジネスルールや過去の判定事例も考慮に入れて、最終的な許可・拒否の判断を下します。

このような階層型アプローチの利点は、大多数の無害な通信に対しては最小限の遅延で済む一方、真にリスクのある通信に対しては十分な分析リソースを割り当てられることです。これにより、セキュリティとユーザビリティの最適なバランスを実現します。

4. 継続的な学習と適応の重要性

AI-DLPシステムは、静的なルールベースのシステムではありません。組織固有の文脈を学習し、時間とともに精度を向上させる必要があります。

さて、最初の例で出した「Project Phoenix」にもう一度登場いただきましょう。

ある組織で「Project Phoenix」というコードネームが使われ始めたとします。初期段階では、システムはこれが機密プロジェクトであることを知りません。しかし、この用語が機密文書や限定的なコミュニケーションで頻繁に使用されることを検出し、徐々にその重要性を学習していきます。同様に、新しい製品名、部署名、技術用語なども自動的に辞書に追加され、適切な機密レベルが設定されていきます。

また、誤検知や見逃しからのフィードバックも重要な学習源となります。セキュリティ担当者が「この警告は誤検知だった」とマークすれば、システムはその判定パターンを学習し、次回から同様の誤検知を減らすことができます。逆に、見逃してしまった機密情報の流出が後から発覚した場合も、そのパターンを学習して検出能力を向上させます。

このように継続的な学習により、AI-DLPシステムは組織の実情に即した、より精度の高い判定を行えるようになっていきます。これは、固定的なルールに依存していた従来のDLPでは実現できなかった、AI時代ならではの進化です。

5. 技術・利便性・ガバナンスの三位一体

ここまで技術的な側面を中心に議論してきましたが、AI-DLPの成功には技術だけでは不十分です。前回の記事でも触れたように、100%の技術的防御は不可能であり、最終的には人の意識とモラルが重要になります。

過度に制限的なセキュリティポリシーは、かえって組織のセキュリティを損なう可能性があります。AIツールの利用を全面的に禁止したり、極めて不便な方法でしか利用できないようにしたりすると、従業員は個人のデバイスや個人アカウントを使用してこれらのツールにアクセスし始めるでしょう。

このように

「うちの会社のネットワークは不便だからこっそり俺様のやりたいようにつかってやろう」

っていう状態を「シャドウIT」（Shadow IT）と呼びます。

シャドウITの発生は、組織のガバナンスを完全にスポイルしてしまいます。

むしろ重要なのは、「使わせない」から「安全に使わせる」への発想転換です。従業員の生産性向上というAIのメリットを活かしながら、リスクを適切に管理する。これが、AI時代のセキュリティの要諦となります。

技術的対策としては、本記事で説明した階層型処理により、大多数の通常利用には影響を与えず、本当にリスクの高い通信のみを詳細に検査します。組織的対策としては、明確な利用ガイドラインを策定し、リスクレベルに応じた段階的な制限を設けます。一般従業員には比較的緩やかな制限を、機密情報を扱う部門にはより厳格な制限を適用するなど、柔軟な運用が重要です。

また、定期的な啓発活動と教育も欠かせません。なぜこのような対策が必要なのか、どのようなリスクがあるのか、そして安全にAIを活用するにはどうすればよいのか。これらを従業員が理解し、納得した上で実践することが、真の意味でのセキュリティ向上につながります。

6. AI-DLPの将来展望

AI-DLPの将来を考える上で、短期、中期、長期の視点で戦略を立てることが重要です。

短期的には、現在利用可能な技術を最大限活用し、基本的な防御体制を構築することが優先されます。前回解説したプロキシ型監視と本記事で説明した階層型処理を組み合わせることで、実用的なレベルのセキュリティを実現することができます。

中期的には、AI-DLPに特化した新しいソリューションがさらに進化していくでしょう。自然言語理解や文脈認識の精度が向上し、より高度な判定が可能になります。また、異なるAIサービスごとの特性を理解し、それぞれに最適化された制御方法も確立されていくはずです。

長期的にはAIがもたらすリスクを管理するためにAI技術自体を全面的に活用する「ガーディアンエージェント」時代が来るでしょう。高度な言語モデルが、送信されようとしているデータの機密性を人間と同等以上の精度で判断し、適切な制御を行う。そんな未来も、そう遠くないはずです。

7. 実践的なソリューションへ向けて

本記事では、AI時代のデータ漏洩防止において、従来型のDLPアプローチでは対応できない新たな課題と、それに対する技術的なアプローチについて詳しく見てきました。自然言語理解の必要性、文脈依存型のリスク判定、リアルタイム処理への対応、そして双方向監査という新しいパラダイムなど、AI-DLPが取り組むべき課題は多岐にわたります。

これらの課題に対して、階層型処理アーキテクチャや継続的な学習メカニズムといった技術的ソリューションが有効であることも明らかになりました。しかし同時に、技術だけでは解決できない部分も多く、組織全体での取り組みが不可欠であることも再確認されました。

LLM-Audit：包括的なAI-DLPソリューション

当社のLLM-Auditは、これらの課題を深く理解した上で開発された、包括的なAI-DLPソリューションとして活用可能です。LLM-Auditは単なる技術製品ではなく、組織のAI活用を安全に推進するための総合的なプラットフォームとして設計されています。

LLM-Auditの最大の特徴は、本記事で詳しく説明した双方向監査を実装していることです。アウトバウンド監査では、従業員がLLMに送信しようとするデータを検査し、個人情報や機密情報が含まれていないかをチェックします。一方、インバウンド監査では、LLMからの応答を検査し、不適切な内容、誤情報、あるいは意図しない機密情報の露出がないかを確認します。

また、階層型ガードレールという柔軟アーキテクチャにより、95%以上の通常のリクエストは高速なマッチング処理（5ミリ秒程度）で処理され、ユーザーはほとんど遅延を感じることがありません。より複雑なケースでは、必要に応じて形態素解析、固有表現抽出、BERT/RoBERTaによる文脈解析、専用LLMによる推論まで、段階的に処理が深化していきます。

また、PIIや機密情報検出や仮名化（非識別化）のみを高速高精度で行う PII-FI もあわせてご提供しており、用途に応じて最適なソリューションをご提案いたします。

まとめ

AI時代のデータ漏洩防止は、もはや従来の延長線上では対応できない、全く新しいチャレンジです。HTTPSインターセプトという基礎技術の上に、自然言語理解、文脈依存型判定、リアルタイム処理、双方向監査といった新しい要素を積み重ねていく必要があります。

しかし、これらの技術的な進化だけでは十分ではありません。「使わせない」から「安全に使わせる」への発想転換、技術・利便性・ガバナンスの三位一体でのアプローチ、そして継続的な改善サイクルの確立が、真の意味でのAI時代のセキュリティを実現する鍵となります。

完璧を求めるのではなく、実用的で持続可能な対策を講じること。技術の限界を認識しながらも、それでも前に進むこと。これが、AI時代のセキュリティに求められる姿勢です。

私たちは、技術の透明性こそがセキュリティの第一の基盤だと考えています。本記事が、皆様の組織におけるAI活用とセキュリティの両立に向けた議論の一助となれば幸いです。

AI技術の進化とともに、セキュリティの課題も日々変化しています。

もし貴社がAI活用におけるセキュリティとガバナンスの課題でお悩みでしたら、ぜひ一度ご相談ください。前回と今回の記事で解説した技術的な背景を踏まえた上で、貴社の具体的な状況に応じた最適なソリューションをご提案させていただきます。

こんにちは！
2026年7月2日(日本時間)、日本からもClaude Fable 5が再び利用できるようになりました。

2026年6月に大きな注目を集めて登場し、わずか3日で米政府の指令により停止、そして7月1日(米国時間)に復活したAnthropicの最上位モデル「Claude Fable 5」。

復活と同時に
「サブスクで使えるのは7月7日まで」
という条件が付いたことで、利用者の間ではコストへの懸念の声も見られます。

本記事では、憶測と事実を切り分けながら、

(1)これまでの経緯、
(2)確定している料金体系、
(3)実際のコスト試算、
(4)今後の見通し、

の4点を整理します。確定情報(ファクト)と筆者の推測は明確に区別して書きます。

※本記事の日付は、特記のない限りAnthropicの発表に基づく米国時間を基準としています。

なお当ブログでは、Fable 5 / Mythos 5についてリリース直後の技術解説、米政府指令による停止が示した可用性リスクの考察、Fable 5の安全分類器がClaude Code上で実際にどう振る舞ったかの体験記を公開してきました。

本稿はその続報として、「復活後の料金とこれから」に焦点を絞って解説していきたいと思います。

1. 経緯の整理(ここはすべてファクト)

時系列で追うと、Fable 5を巡る動きは異例づくしでした。

●2026年6月9日:リリース
Anthropicは公式発表で、Opusティアの上に位置する新しい「Mythosクラス」の一般公開版としてFable 5を発表。
同時に、安全制限を一部緩和した審査制の「Mythos 5」を、既存のMythos Preview利用組織(Project Glasswing参加組織など)向けに提供開始。両者は同一の基盤モデルを共有していますが、Fable 5には一般提供向けの安全分類器が適用され、Mythos 5では承認された用途に向けてその分類器が適用されない構成になっています(詳細はリリース時の解説記事を参照)。
Fable 5はSWE-bench Proで80.0%(Mythos 5は80.3%)を記録し、Opus 4.8の69.2%を10.8ポイント上回りました(数値はAnthropicのシステムカードに基づく)。
有料プラン(Pro / Max / Team / シート制Enterprise)では6月22日まで追加課金なしで利用できる、というローンチ条件でした。

●6月12日:全世界で提供停止
米政府が国家安全保障上の権限に基づき、米国内外を問わず外国籍者によるFable 5 / Mythos 5へのアクセス停止を指令(Anthropic公式声明、CNBC)。Anthropicはリアルタイムで利用者の国籍を判別できないため、全ユーザー向けに両モデルを停止しました。
なお、6月9日〜14日にプランを購入・アップグレードしたサブスクライバーには、6月20日を期限とする日割り返金(プロレート返金)の選択肢が提供されました(Forbes)。
この停止劇が突きつけた「政策リスクによるモデル停止」という新種の可用性リスクについては、停止直後の考察記事で詳しく論じました。

●6月26日〜27日:Mythos 5が部分復活
米商務省のラトニック長官が「適切なセーフガードが確認された」として、重要インフラの防御を担う政府機関・民間企業あわせて約100組織に限ってMythos 5の再提供を許可(TechCrunch、Axios、Fortune)。

●6月30日:規制解除
Anthropicは商務省から輸出規制解除の通知を受けたと発表(Decrypt)。

●7月1日(日本では7月2日の早朝に復活を確認):Fable 5復活
Claude Platform / Claude.ai / Claude Code / Claude Coworkで全世界のユーザーに提供再開(Anthropic公式発表、9to5Mac)。
再公開にあたり、安全分類器の「安全マージン」を拡大するなど対策を強化したと同社は説明しています。
この安全分類器はサイバーセキュリティ・生物学・モデル蒸留などの高リスク領域を検知するものです。
Claude.aiやClaude CodeなどAnthropic提供のアプリでは、分類器が作動しても拒否で終わらせず、Opus 4.8へ切り替えて応答を継続する仕組みが採られています(API利用時の挙動は後述のとおり異なります)。
分類器が実際の開発作業でどう振る舞うか(誤検知も含めて)は、停止前に弊社が経験した実例レポートが参考になるはずです。マージン拡大は誤検知率の上昇と表裏一体なので、復活後の挙動は引き続き観察が必要です。

2. 確定している料金体系(ファクト)

復活後の課金条件は、Anthropicの再提供発表および海外報道(9to5Mac、Digital Trends)で次のように確認されています。

●7月1日〜7月7日
移行期間(米国太平洋時間7月7日23時59分まで。日本時間では7月8日15時59分頃まで)
Pro / Max / Team / Enterprise(プレミアムシート)のユーザーは、
週間利用上限の最大50%までFable 5をサブスクの範囲内で利用可能。

これはFable 5専用の追加枠ではなく、各プランの既存の週間利用上限のうち最大50%までをFable 5に充てられるという意味です。上限を超えると追加クレジットを消費します。なお、Fable 5は他モデルより週間利用枠を速く消費すると案内されている点にも注意が必要です。

●7月8日以降(米国太平洋時間)
従量課金へ
サブスクプランの対象から外れ、利用には使用クレジット(従量課金)が必要になります。

API単価(公表値):

Fable 5の標準API単価はOpus 4.8のちょうど2倍で、現行の主力Claudeモデルの通常モードとしては最高水準です(最新の単価は公式料金ページを参照)。

サブスク枠を超えた後のクレジット消費も、このAPIと同じレートで課金されると報じられています。バッチ処理(Batch API)を使えば入出力とも50%割引が適用されます。なお6月30日(日本時間7月1日)に登場したSonnet 5には、2026年8月末までの導入価格($2/$10)が設定されています。

課金に関わる仕様上のポイント(公式ドキュメントより)

• 拒否(refusal)時の課金ルール
  APIでは、前述の安全分類器がリクエストを止めると、エラーではなくstop_reason: "refusal"付きの正常応答が返ります。出力が始まる前の拒否であれば、そのリクエスト自体は課金されません。ただし、生成の途中で分類器が作動した場合は、入力トークンと、そこまでに生成された出力トークンが課金されます(詳細は公式ドキュメント)。
  
• フォールバック時はOpus 4.8の単価で課金
  拒否されたリクエストをOpus 4.8が代わりに処理した分は、Opus 4.8のレート($5/$25)で課金されます。「Fable 5に投げたのに全額Fable 5価格になる」わけではありません。なお、サーバー側で自動的に再実行するフォールバック機能はClaude APIとClaude Platform on AWSで提供されるオプトインのベータ機能で、Amazon Bedrock / Google Cloud / Microsoft Foundryでは、SDKミドルウェアなどによるクライアント側の再試行を実装する必要があります。
  
• 思考(thinking)は常時オン
  Fable 5では思考を無効化できず、思考トークンも出力トークンとして課金対象です。思考の深さはeffortパラメータ(low〜max)で制御します。
  
• 30日間のデータ保持が必須
  Fable 5はゼロデータリテンション(ZDR)構成では利用できず、保持期間が要件を満たさない組織からのAPIリクエストはエラーになります。厳格なデータ保持ポリシーを敷いている企業は、API利用の前に自社の契約構成の確認が必要です。

なお、Anthropicは停止解除の当初「クラウド経由の提供は可能な限り早期に再開する」と説明していましたが、その後更新された公式ドキュメントでは、Fable 5はClaude APIに加えてClaude Platform on AWS / Amazon Bedrock / Google Cloud / Microsoft Foundryでも一般提供(GA)と明記されています。地域や契約形態による差があり得るため、利用前に各クラウドのモデル一覧をご確認ください。

3. 実際いくらかかるのか(単価はファクト、シナリオは試算)

単価だけで比較すれば、同じトークン数を使った場合のFable 5の料金はOpus 4.8のちょうど2倍です。ただし実際の請求額は、単価以外の要因でも大きく変わります。

請求が膨らみやすい構造的な理由は3つあり、いずれも公式ドキュメントで確認できる仕様です。

●第一に、出力単価が入力の5倍であること。
エージェント的にコードを大量生成させる使い方では出力トークンが支配的になります。しかもFable 5は思考が常時オンで、思考トークンも出力側に加算されます。

●第二に、エージェント処理ではトークンが積み上がりやすいこと。
長時間のエージェントループでは、思考トークン、生成するコード、ツール実行結果の読み込み、会話履歴の再送が積み重なります。実際の消費量はeffort設定、思考量、タスクの長さ、ツール呼び出し回数によって大きく変わります(なお、応答に数分〜十数分かかること自体に課金されるわけではありません。課金対象はあくまでトークン数です)。

●第三に、トークナイザの問題。
Fable 5はOpus 4.7で導入された新トークナイザ(Opus 4.8やSonnet 5と同一)を使っており、Opus 4.6以前やSonnet 4.6以前から乗り換えた場合、同じテキストが内容によって約30%、最大35%程度多くトークン化される場合があるという公式の注記があります(Opus 4.7 / 4.8からの移行ならトークン数はほぼ同等です)。

この前提で、従量課金に移行した後のコスト感を試算すると(1ドル=150円、月20〜22営業日換算の概算。為替・プロンプトキャッシュの利用状況・実際の消費量で大きく変動します)

• 要所だけFable 5を使う軽めの利用(1日あたり入力50万・出力10万トークン)なら、月あたり3万円台。
  
• Fable 5を主力にして長時間エージェントを回す使い方(1日あたり入力500万・出力50万トークン)なら、月25万円前後。
  
• 複数エージェントの並列・常時稼働に近い使い方(たとえば1日あたり入力2,000万・出力270万トークンを月20日)なら1日約$335、月あたり約$6,700
  →月100万円級も現実的な数字です。

リリース直後の期間には、一部の利用者から「利用枠の減りがOpus 4.8より速い」という体感報告も見られました。ただしこれは条件を揃えた比較ではなく、タスク内容やeffort設定の違いを含む体感ベースの声である点には注意が必要です。いずれにせよ、定額の安心感の中で使うのと、メーターが回る中で使うのとでは、心理的にも実務的にもまったく別物です。

自衛策(実務向け):
7月8日以降に意図しない課金バーストを避けるには、(1)使用クレジットの上限設定を見直す、(2)組織利用なら高額モデルへのアクセス制御を入れる、(3)日常タスクはOpus 4.8 / Sonnet系に振り分けてFable 5は高難度タスクに限定する、の3点がまず基本です。

API利用者であれば、さらに次の技術レバーが使えます(いずれも公式ドキュメント記載の機能)。

• effortパラメータを調整する。 Fable 5はlow〜maxの5段階で思考・行動の深さを制御できます。Anthropicは、Fable 5では低いeffort設定でも旧モデルのxhighを上回る場合があると説明しています。ただし公式の推奨開始点は多くのタスクでhighなので、品質とコストを評価しながら段階的に下げるのが安全です。ルーチンタスクをlow/mediumで回すだけでもトークン消費は大きく抑えられます。effortの考え方はOpus 4.8完全ガイドでも解説しています。
• タスクバジェット(ベータ)で残り予算を意識させる。 エージェントループ全体で使えるトークン量をモデル自身に伝える機能で、モデルは残量を見ながら作業を配分し、途中で切られるのではなく予算内で完了するよう自己調整します(公式ドキュメント)。ただしこれは強制的な課金上限ではなく、モデルに提示する「目安」です。実際の暴走防止には、max_tokens(リクエスト単位のハード上限)、呼び出し回数の制限、クライアント側での累積コスト監視、組織側の利用上限設定を併用してください。
• プロンプトキャッシュを効かせる。 繰り返し送信する安定したプロンプト部分は、キャッシュヒット時に通常入力の約1/10の単価になります(公式ドキュメント)。ただしキャッシュ書き込みには通常入力より高い単価がかかるため、実際の削減効果はキャッシュ対象の割合・ヒット率・書き換え頻度によって変わります。同じ会話履歴を再送し続けるエージェントループは、効果が出やすい典型例です。
• バッチ処理に回せるものは回す。 緊急性のない一括処理はBatch APIで50%引きです。

4. 今後どうなるか(ここから先は推測を含む)

最大の関心事は「Fable 5は再びサブスク定額に戻るのか」でしょう。確定情報と推測を分けて書きます。

ファクト
Anthropicは再提供の発表で、十分な提供容量を確保できた段階で、Fable 5をサブスクリプションプランの標準的な一部として復帰させる方針を明示しています。つまり残された論点は「戻すかどうか」ではなく「いつ、どのような枠で戻すか」です(時期・枠の水準は未発表)。

また、復活前にClaude Code(v2.1.190)のバイナリから「You've used your included Fable 5 usage for this week.(今週分のFable 5利用枠を使い切りました)」という新しい文字列が発見され、以前あった「プランとは別に購入する」という趣旨の文言が削除されていたことが報じられています(Decrypt)。

サブスクに週次利用枠付きで組み込む設計が内部的に準備されていた傍証といえます。実際、復活後の7月1日〜7日の「週間上限の50%まで」という提供形態は、まさにこの週次枠モデルそのものです。

推測(筆者の見立て)
以上を踏まえると、シナリオは3つ考えられます。なお、各シナリオの「可能性」表記は算定根拠のある確率ではなく、筆者の主観的な評価です。

1. 週次枠付きでサブスクに復帰する(可能性:中〜高)
   サブスクへ戻す方針そのものは、前述のとおりAnthropicが公式に示しているファクトです。推測にあたるのは「7/1〜7/7と同様の週次枠という形になるか」と「その時期」。7/1〜7/7の提供形態が事実上のテスト運用に見えること、コード内の文言変更がこの方向を示唆していることが根拠です。計算資源の逼迫が緩めば、静かにこの形へ移行する可能性があります。
   
2. 次の最上位モデル登場まで従量課金のまま(可能性:中)
   次の最上位モデルが登場した段階で、Fable 5の提供条件が見直される可能性があります。Anthropicのモデル更新サイクルは速く、数ヶ月スパンでの見直しは十分あり得ます。
   
3. 最上位ティアは恒久的にメーター課金(可能性:低〜中)。 フロンティアモデルのコスト構造を考えれば、「定額はOpusまで、その上は従量」という線引きを固定する経営判断もあり得ます。

ウォッチすべきシグナル
(a)Anthropicが「included window」の延長や週次枠の常設を発表するか、(b)競合(OpenAI / Google)が同格モデルを定額プランに含めるか、(c)次の最上位モデルの発表、(d)公式の料金・プランページの記載変更。この4点が動いたときが潮目です。

まとめ

• Fable 5は6月9日リリース → 6月12日に米政府指令で全停止 → 7月1日に復活、という異例の経緯をたどった(ファクト)。
• 復活後、サブスク枠内で使えるのは米国太平洋時間7月7日まで(既存の週間上限のうち最大50%)。8日以降は$10/$50(1Mトークン)の従量課金(ファクト)。
• 従量課金でのヘビーユース時は月数十万円〜100万円級に達し得る(単価はファクト、シナリオは試算)。
• Anthropicは、容量確保後にFable 5をサブスクへ戻す方針を公式に示している(ファクト)。時期と提供枠の詳細は未定で、週次枠付きでの復帰が有力と筆者は見る。ただし容量確保が進まず、従量課金中心の状態が長期化する可能性も残る(推測)。

料金・提供条件は流動的です。実際の契約判断の前には、必ずAnthropicの公式料金ページとご自身のプラン画面で最新の記載を確認してください。

なお、停止時の考察記事で提言した「特定モデルへの依存を避け、切り替え可能性を設計段階で確保する」という原則は、今回の料金変更にもそのまま当てはまります。

政策リスクで止まるのも、課金体系が変わるのも、利用者から見れば同じ「前提条件の急変」です。

Fable 5を組み込むなら、Opus 4.8への切り替えを前提にした設計をおすすめします
(Claude APIでは、拒否時にOpus 4.8で再実行するオプトインのサーバー側フォールバック機能がベータ提供されています)

関連記事

• ついに一般公開、Claude Mythos 5 / Fable 5を実務視点で読み解く — リリース時の技術仕様・ベンチマーク解説
• 公開から3日で停止──Fable 5/Mythos 5をめぐる米政府指令が示した、AIの新しい可用性リスク — 停止事件の経緯と企業への提言
• AIは、来なかった攻撃を「検知」し、「拒否」し、「反省」した〜Fable 5 on Claude Codeでの経験 — 安全分類器の実挙動レポート
• Claude Opus 4.8完全ガイド — Fable 5からの振り分け先・フォールバック先となるモデルの解説
• Anthropicが「強すぎて出せないモデル "Mythos"」を出した — Mythosクラスと防御者パラダイムの背景

本記事は2026年7月2日(日本時間)時点のAnthropic公式発表・公式ドキュメント(モデル仕様・API料金・移行ガイド)、および海外主要メディアの報道(CNBC、Fortune、Forbes、TechCrunch、Axios、9to5Mac、Decryptほか)に基づいています。推測と明記した箇所は筆者の見立てであり、Anthropicの公式見解ではありません。

こんにちは、Qualiteg研究部です。

今日は「すでに完成している強いモデルを、壊さずに広げる」という、地味だけど実務でとても大事なテーマを取り上げたいと思います。

機械学習に取り組んでいると、

「一度しっかり仕上げたモデルを、新しい用途やデータに合わせてもう少し広げたい」

そんな場面はよく出てきます。
今回ご紹介するNER（固有表現抽出）のシーンに限らず、いろいろなタスクで共通する悩みではないでしょうか。
ところが、ここで素朴に追加学習をかけると、せっかくの強みがあっさり崩れてしまう。

私たちは、PII（個人特定情報や要配慮情報）を検出・マスキングするエンジン(PII-FI)を構築する際、実際にそれを経験しました。

Precision（適合率）が 0.83 から 0.17 まで転げ落ちる、なんてことも本当に起きるんです。

PII検出では、ドメイン（分野）ごとに検出したいPII型の種類や求められる精度が異なる場合があります。そこで1つのエンジンといっても、対応ドメインを広げていくたびに（そのドメインに適応させるための）追加学習が求められることがあります。

本稿は、そうした「追加学習でドメインを広げる」取り組みのなかで私たちがぶつかった壁と、そこから得た原理や判断を、ありのままに共有するものです。

今回は、XLM-RoBERTa をエンコーダに使った高速日本語 NER モデルを土台に、「手法の性質がこうだから、だから我々はこう設計した」という因果の形で、丁寧に書き残していきます。

先に結論だけ言っておくと、勘どころは、精度を上げる小技ではなく、「何を動かさないか」を設計することにありました。

同じような場面に立つ方の参考になればと思います。

0. 記法とモデルの土台

NER をトークン分類として定式化します。入力系列 \(x=(x_1,\dots,x_T)\) に対し、エンコーダ \(f_\theta\) が各トークンの文脈表現 \(h_t = f_\theta(x)_t \in \mathbb{R}^d\) を出し、線形の分類ヘッド \(W \in \mathbb{R}^{C\times d}\)（\(C\) はラベル数、\(b\in\mathbb{R}^C\) はバイアス）が

$$ p(y_t = c \mid x) = \mathrm{softmax}(W h_t + b)_c = \frac{\exp(w_c^\top h_t + b_c)}{\sum_{c'} \exp(w_{c'}^\top h_t + b_{c'})} $$

を返します。学習は交差エントロピー \(\mathcal{L}=-\sum_t \log p(y_t^\star\mid x)\) の最小化です。

エンコーダ \(f_\theta\) には XLM-RoBERTa（多言語 RoBERTa） を用います。

手元には、この \(f_\theta\) の上で十分に鍛えた

強い日本語NER \(M_0=(\theta_0, W_0)\)

がすでにあるとします。目標は、\(M_0\) の強み（特に「実文で過剰に拾わない」校正）を保ったまま、新ドメイン・新ラベルへ対応を広げることです。

ここで、追加学習の自由度は \(\theta\)（エンコーダ）と \(W\)（ヘッド）のどこをどれだけ動かすかに集約されます。

本稿は一貫して「この自由度をどう絞るか」の話です。

1. まず XLM-RoBERTa の性質を押さえる（設計はここから決まる）

設計判断は、すべて XLM-RoBERTa の以下の性質から導かれます。

(a) 多言語・大規模事前学習
XLM-RoBERTa は約100言語・大規模コーパスで Masked LM 事前学習された encoder-only モデルです。一般に、下位層ほど言語横断の汎用的な特徴（語形・文法）、上位層ほどタスク寄りの特徴を持つ、という階層性が経験的に知られています。
→ だから我々は、新能力を足すときも下位層は極力動かさない方針を採りました（後述の凍結・LoRA・低学習率）。これは「層別の表現に関する一般的な知見」と「私たちの層別凍結の実験結果」にもとづく設計仮説で、校正が必ず下位層に宿ると断定しているわけではありません。

(b) SentencePiece サブワード・トークナイザ（日本語に空白境界が無い）
1単語が複数サブワードに割れ、エンティティ境界がサブワードの途中に来ることもあります。
→ そこで我々は、文字オフセット（offset mapping）で文字スパンとサブワードの対応を取り、ラベルはベースのタグ方式に合わせて付与しました。ただし offset mapping は対応を取得できるだけで、1サブワードの内部に境界がまたがる場合まで解決してくれるわけではありません。そうしたトークンは「少しでも重なればラベル付け」「完全に含まれる場合だけラベル付け」「ignore_index にする」などの方針を決めて扱います（ベースが単タグ式＝B/I 接頭辞なしなら、こちらも単タグ。B/I を勝手に導入するとラベル空間が割れて学習が濁ります）。

(c) 多言語共有語彙
ローマ字・全角半角・記号混じり・英数字の造語も、サブワードへ分割して扱えます。
→ ゆえに、英単語の顔をした造語のような「辞書にも正規表現にも載らない固有名」も、文脈表現として扱える余地があります（ただし「分割できる」ことと「表記揺れに頑健」であることは別で、ここは仮説として捉えています）。これは後述の「新しいエンティティ型を学習で取りに行く」勝ち筋の前提になります。

(d) encoder-only ＋ 線形ヘッド
タスクの知識の多くはエンコーダ \(f_\theta\) 側にあると私たちは仮定しており、ヘッド \(W\) は薄い線形写像にすぎません。しかも \(f_\theta\) は全ドメイン・全ラベルで共有されます。
→ ゆえに後述の「単一エンコーダでは多ドメインを完全には両立しにくい」というトレードオフが生まれます。\(f_\theta\) を動かすと、その上に乗る全部の判定が動いてしまうからです。

2. 測れていないものは鍛えられない（評価の自己点検）

最初の作業は新しい学習ではなく、評価指標の点検でした。

指標がわずかにずれると、その後の全最適化が誤った方向へ進みます。
（本稿の Precision／Recall は、重なり（overlap）＋型一致・micro 平均で算出し、placeholder（事前匿名化済みの印）は除外、後処理なしのモデル単体を同一の独立評価セットで比較しています。完全一致（exact match）ではありません。）

今回、私たちの評価コードで実際に見つかった主な問題は2種類でした。

• 「検出すべきでない印」を Recall の分母に入れる
  たとえば対象テキストがあらかじめ伏字・記号化されている箇所まで「正解」に数えると、Recall の定義
  $$ \text{Recall} = \frac{|\text{検出できた正解}|}{|\text{正解集合}|} $$
  の分母が膨らみ、実態とずれます。
  製品が本当に守りたいのは「漏れて困る実体」なので、事前匿名化済みの印は分母から外すべきです。
  
• ラベル対応表の漏れ
  モデルが出すラベル名と評価側の期待名の変換が一部抜けると、特定型だけ取りこぼしが過大計上されます。

私たちはこの2点を直しただけで指標が大きく変わり、「弱点は Recall ではなく Precision（過剰検出）だった」とミッションの理解が反転しました。

教訓：measure-first。「数字が悪い」より先に「数字の定義は正しいか」を疑う。指標のバグはあとから大きく手戻る原因になります

3. 素朴な継続学習では「忘却」と「学習分布の偏り」が同時に起こる

新ドメインのデータ（多くは合成）だけで素朴に追加学習すると、\(\theta_0 \to \theta\) が動いて旧ドメインの性能が落ちることがあります。これは、以前学習した能力を新しい学習で失う破滅的忘却として現れる場合があります。ただし、今回観測した Precision 低下はそれだけでは説明できません（次段）。

NER で特に起きるのが「地の文で黙るを忘れる」ことです。

テンプレートで作った合成文は、ほぼ全文に固有名が入ります。すると、トークンが何らかのエンティティである事前確率（基底率）

$$ \pi = \Pr(y_t \neq O) $$

が、学習データ上で実文よりずっと高くなります。モデルはこの偏った \(\pi\) を内面化し、実文でも何でも拾うようになります。

私たちの観測では Precision が \(P\approx0.83\to0.17\) まで落ちました（Recall は高いまま）。これは破滅的忘却というより、合成データと実文の分布差（クラス事前分布のずれ・負例不足）にモデルが適応してしまった結果です。今回の問題には、旧能力の忘却と学習分布の偏りの両方が関与していました。

XLM-RoBERTa の性質 (a) を踏まえると、層別凍結の実験の範囲では下位層の表現は比較的保たれており、変化したのは主に上位層やヘッドの校正だった可能性が高いと考えています（層別プローブで厳密に同定したわけではありません）。
→ ゆえに我々は、

(1) 合成データの密度（density）を実文に寄せる（長い地の文に固有名を疎らに置き、\(O\) トークンを大半にする）、

(2) 難しい負例（一般名詞・定型句だけの文、紛らわしい一般語）を入れる、という対策で \(\pi\) の偏りを是正しました。

精度は戻りましたが、素朴な続き学習の枠内ではある天井で頭打ちになりました。次節以降がその突破です。

4. 分類ヘッドを作り直さない（デコイクラスという受け皿）

最も効いた一手が、\(M_0\) のラベル体系をそのまま引き継ぐことでした。

これは softmax の確率の振る舞いと、学習信号の両面から説明できます。

自分が欲しい型が \(k\) 個（たとえば人物・組織・地名）だとして、\(W_0\in\mathbb{R}^{C\times d}\)（\(C>k\)）を捨てて \(W_{\text{new}}\in\mathbb{R}^{k\times d}\) を新規初期化したとします。すると、\(M_0\) が別クラスとして持っていた「製品名」「施設」「事象」等の非対象エンティティの出力スロットが消えます。

softmax は確率の総和を1に保つので、消したクラスに乗っていた確率質量は残ったクラスへ再配分されます

$$ \text{クラス } C{+}1 \text{ を除去} \;\Rightarrow\; \sum_{c=1}^{C} p(c\mid x)=1 \text{ に正規化} \;\Rightarrow\; \arg\max_c \text{ が対象型へ移りうる} $$

XLM-RoBERTa のエンコーダは「この語は法律名だ／施設名だ」という特徴を依然として表現しているのに、それを受け止める出力スロットが無い。

既存ロジットの一部だけを除去したと考えれば、非対象クラスという競合先を失うことで対象クラスが選ばれやすくなる、と理解できます。ただし実際にはヘッドを新規初期化するとロジットそのものが変わるため、「以前そのクラスに乗っていた質量が漏れた」と厳密に追跡できるわけではありません。再学習では、これに加えて既存の判別境界の消失・非対象の教師信号の欠落・新データのクラス事前分布への適応も効いて、過剰検出につながります。

→ ゆえに、\(W_0\) をそのまま読み込み（ヘッドの形を一致させてロードし、ignore_mismatched_sizes=False 相当）、対象型のラベルにだけ教師信号を与える設計にしました

$$ \mathcal{L} = -\!\!\sum_{t:\, y_t^\star \in \{\text{対象型}\}\cup\{O\}}\!\!\! \log p(y_t^\star \mid x) $$

非対象の“デコイ”クラスの行を warm start として残すことで、ヘッドを新規初期化する場合より「これは組織ではなく別カテゴリ」という \(M_0\) の判断が失われにくくなります（厳密に「温存」できるかは別問題で、新データで非対象を一律 \(O\) と教えるとデコイ側にも負の勾配が入ります。旧クラスを教師モデルで擬似ラベル化する・未注釈部分を ignore_index にする・replay を併用する、などで受け皿を守るのが理想です）。この変更だけで頭打ちが目に見えて改善しました。

教訓：非対象クラスは“受け皿”として価値がある。型を絞ってヘッドを作り直すと受け皿と既存の判別境界を失い、過剰検出が増えます（softmax の再配分はその一因）。

5. 自己蒸留で drift を抑える（ベースから離れにくくするアンカー）

デコイ温存でも \(M_0\) の精度には届きません。軽い追加学習でも \(\theta\) は少しずつ drift します。

ここで効くのが自己蒸留です。

考え方はこうです。

教師ラベルを人手や辞書ではなく、\(M_0\) 自身に実文を推論させて作り、生徒（学習中のモデル）を教師分布へ近づけます

$$ \mathcal{L}_{\text{distill}} = \sum_t \mathrm{KL}\!\big(p_{M_0}(\cdot\mid x)\,\big\|\,p_{\theta}(\cdot\mid x)\big) $$

（本稿の自己蒸留は \(M_0\) と同じラベル空間（教師＝生徒）で行います。新型の追加は §6 の別段で、soft な KL ではなくハードラベルの交差エントロピー（新型にラベル id が付くだけ）で行うため、次元の異なる教師・生徒で KL をそのまま計算する場面はありません。なお、ハードラベル化した \(M_0\) 出力での交差エントロピーは soft な KL 蒸留とは別物で、非最大クラスの確率情報（dark knowledge）は失われます。）

この目的関数は、理想的にはアンカーデータ上で \(p_\theta = p_{M_0}\) を最小点に持ちます。ただし実際には有限のアンカーデータで学習し、新型ラベルの損失も併用し、最適化誤差もあるため、未見データまで含めて \(M_0\) と完全に一致する保証はありません。それでも実用上は、追加学習による drift を強く抑える正則化として効きます。私たちはこれで、（蒸留に使ったアンカーとは別の）旧ドメインの独立評価セットでも \(M_0\) に近い性能を再現できました。「追加学習＝即劣化」を避けるための有効な一手です。

ただし注意も要ります。教師が \(M_0\) 自身である以上、アンカーデータ上では \(M_0\) のクセ（過剰検出など）も一緒に引き継ぎやすくなります。

とはいえ、これは「生徒が教師を超えられない」という意味ではありません。同一アーキテクチャの自己蒸留でも生徒が教師を上回る報告はあり、外から新しい情報を足せば改善の余地は残ります。

したがって、自己蒸留はあくまで既存の挙動をベースに寄せて保つための手段です。\(M_0\) が持っていない型のような能力を足すには、\(M_0\) の外から情報を入れる必要があります。次節がそれです。

6. 既存ドメインは超えられなかった――勝てたのは「出力空間に無い新型」だけ（ヘッド手術）

理論上は、既存ラベルでも、より質の高いデータ・誤ラベル修正・ドメイン適応・損失設計の改善などで \(M_0\) を上回る余地はあります（自己蒸留で生徒が教師を超える報告もあります）。
ですが我々のデータと手法では、すでに強い既存ドメインの精度を一度も超えられませんでした。§7 で触れる5系統をすべて試し、本番パイプラインで追認しても、どの変種もベース以下。これは正直な負の結果です。
一方で、はっきり勝てた軸が一つだけありました。\(M_0\) の出力ラベル空間に存在しない新しい型です。既存モデルはその型を出力する手段自体を持たないので、ここは学習で取りに行ける明確な勝ち筋になります。

その典型が、辞書にも正規表現にも載らない新しいエンティティ型です。

たとえば英数字の造語のような固有名は、私たちが用意していた辞書・正規表現ルールでは拾えず、\(M_0\) にそのラベルが無ければ Recall は構造的に \(0\) です。しかし §1(c) のとおり、XLM-RoBERTa の多言語サブワード表現はそうしたトークンを文脈として扱える余地があり、出力スロットさえ与えれば学習で取りに行けます。

ここは学習ベースの NER が特に力を発揮できる領域です。

足し方はヘッド手術。\(M_0\) の分類層 \(W_0\in\mathbb{R}^{C\times d}\) を温存したまま、新型のための行を1つ増設します

$$ W' = \begin{bmatrix} W_0 \\ w_{\text{new}}^\top \end{bmatrix} \in \mathbb{R}^{(C+1)\times d}, \qquad w_{\text{new}} \sim \mathcal{N}(0,\sigma^2 I),\ \ \sigma\!=\!0.02 $$

既存 \(C\) 行はそのまま再利用し（既存ロジットを引き継ぐ warm start）、新型のための1行を追加します。新行は \(w_{\text{new}}\sim\mathcal{N}(0,\sigma^2 I)\) で初期化しますが、新ロジット \(z_{\text{new}} = w_{\text{new}}^\top h + b\) の分散は \(\sigma^2\|h\|^2\) なので、\(\sigma\) を小さくしても \(\|h\|\) が大きければロジットは 0 付近とは限りません（\(d=768\) なら標準偏差は概算で \(0.02\sqrt{768}\approx 0.55\)）。つまり小さい \(\sigma\) は期待値を 0 にするだけで、新クラスが暴発しない保証にはなりません。初期暴発を確実に抑えたいなら、新行の bias を十分な負側に置き、許容する新クラス FP 率に合わせてアンカーデータで校正するのが確実です。なお、ここで「1行追加」で済むのは単タグ方式の場合で、BIO 方式なら B-/I- の複数行が必要になります。

old = model.classifier                  # Linear(d, C)
new = nn.Linear(d, C + 1)
with torch.no_grad():
    new.weight.normal_(std=0.02); new.bias.zero_()
    new.weight[:C] = old.weight         # 既存行はコピー（warm start）
    new.bias[:C]   = old.bias
model.classifier = new                  # 増設した1行を中心に学習

※ 上のコードは classifier 全体を差し替えているため、このままだと既存 \(C\) 行も新しい1行もすべて学習対象になります。新行だけを更新したい場合は、旧行の勾配をマスクするか、旧行と新行を別 Parameter として実装する必要があります。PEFT の modules_to_save=["classifier"] も「保存するだけ」ではなく classifier 全体を学習可能にする設定です。

私たちはこの方法で、\(M_0\) が \(0\) だった新型の Recall を
実用水準まで回収しました。

ベースには絶対に出せない数字で、ここで初めて本当に“広げた”と言えました。

7. LoRA：原理から「我々の設計」を導く

ただ、新能力を足すと、§1(d) のとおり共有エンコーダ \(f_\theta\) が動き、既存ドメインの精度がわずかに下がる問題に、私たちの実験では突き当たりました。

これを最小化する定番がおなじみの LoRA（Low-Rank Adaptation） です。

原理から我々の判断を順に導いてみましょう

7-1. 原理

LoRA は、微調整に必要な重み更新 \(\Delta W\) を低ランク行列で十分に近似できるという仮説に基づきます（「更新が本質的に低ランクである」と証明されたわけではなく、低い intrinsic rank を持つという仮説です）。

ならば \(\Delta W\) をフルに学習せず、低ランク分解で表します、

$$ W = W_0 + \Delta W,\qquad \Delta W = \frac{\alpha}{r} BA,\quad B\in\mathbb{R}^{d\times r},\ A\in\mathbb{R}^{r\times k},\ r\ll \min(d,k) $$

学習するのは \(A,B\) だけで、元の \(W_0\) は完全凍結。\(\alpha\) はスケーリング係数で、実効更新の大きさを \(\alpha/r\) で調整します。
（記号について：ここでの \(W_0\) は LoRA を挿入する一般の線形層を指し、§0 の分類ヘッド \(W\) とは別物です。）

で、ここから2つの性質が出てきます、

• ベース重みを上書きしない
  \(W_0\) は凍結され、学習されるのは \(A,B\) だけです。更新行列 \(\Delta W = BA\) の rank が最大 \(r\) に制約されるため、フルファインチューニングより忘却を抑えやすい傾向はありますが、「忘却が必ず小さい」と保証されるわけではなく、タスクや学習量によってトレードオフは変わります。
• ランクは可塑性と忘却のレバーになりやすい
  私たちの実験では \(r\) を上げるほど新型への適応は強まる一方、既存ドメインの drift も増える傾向が見られました（ただし \(\alpha\) のスケーリング・対象層・学習率・データ分布にも依存します）。

7-2. だから我々はこう考えた

私たちのゴールは

「既存ドメインの挙動を \(M_0\) のまま保ちつつ、新エンティティ型だけ足す」

ですのでLoRA の原理に照らして次のように設計しました。

1. base を LoRA で凍結する
   既存ドメインの校正は \(W_0\) と \(f_{\theta_0}\) に宿るので、それを上書きしないこと自体が目的に直結します。
   
   
2. 適応は attention の query / value に当てる
   今回の構成では target_modules=["query","value"] に限定しました。注意機構への適応が効くという経験則に基づく選択で、あらゆる NER で最適という主張ではありません。
3. ランクは小さめ（\(r=16\), \(\alpha=32\)）
   新型1つを足すのに大きな表現力は要らず、忘却を抑える方を優先。
   実際に \(r\) を上げると既存ドメインが drift しました。
   
   
4. ヘッドは別扱い
   新型行は学習が必要なので、分類ヘッドは LoRA 凍結の例外として学習対象に残す（modules_to_save=["classifier"]）。
   さらに踏み込んで、既存ラベル行だけ勾配マスクで凍結し、新型行のみ学習する版も試しました（なお勾配を止めても、weight decay が classifier にかかると既存行が動くことがあるため、classifier の weight decay は 0 にする等の配慮が要ります）。
5. 学習率は LoRA 用に上げる
   標準的な LoRA では \(B\) をゼロ初期化し、追加直後の更新量はゼロ（no-op）から始まります。新設のアダプタと新型ヘッド行を短期間で適応させる必要があり、検証の結果、ヘッド温存・自己蒸留で使う極小 \(\text{lr}=5\times10^{-6}\) では足りず、\(\text{lr}=2\times10^{-4}\)・2エポックが有効でした。
   「凍結中心だから弱く当てる」ではない点が要注意。
6. 学習後はマージする
   推論時は \(W=W_0+\frac{\alpha}{r}BA\) を畳み込み（merge_and_unload）、通常の重みとして保存。
   消費側は差し替えるだけで、LoRA を意識しなくて済みます。
   
   

7-3. それでも残る「共有エンコーダの両立コスト」

ここが本質的な発見です。

たとえ \(W_0\) と既存ヘッド行を凍結しても、LoRA は共有エンコーダの内部表現を動かすため、既存ドメインのロジットは一般には元モデルと一致する保証がありません。

$$ \underbrace{W_0\, f_{\theta_0+\Delta}(x)}_{\text{LoRA後の既存ヘッド出力}} \;\not\equiv\; \underbrace{W_0\, f_{\theta_0}(x)}_{M_0\ \text{の出力}} $$

\(f\) が全ドメイン共有である以上、新型のために \(\Delta\) を入れると、その \(\Delta\) は既存ドメインの \(h_t\) も動かしえます。私たちは「全混合学習」「下位層凍結」「LoRA」「LoRA＋既存ヘッド凍結」「データ配合変更」と5系統を試しましたが、既存ドメインの精度はどれもほぼ同じ天井に張り付きました。

下位層を凍結しすぎると、今度は新型が学習できず Recall が \(0\) に崩壊する（可塑性を失う）副作用も確認しました。

結論：今回試した5系統の構成では、既存ドメインを完全に保ったまま新型を十分に獲得できる設定は得られませんでした。 共有エンコーダの表現更新が既存ドメインへの干渉要因になっている、というのが私たちの解釈です（replay・機能正則化・条件付きルーティングなどで両立できる余地は原理的には残ります）。完全に分離するなら、ドメイン別アダプタやモデル分割という別アーキテクチャの話になります（運用上1エンジンに統合したい、という制約と相談）。

8. リークは「ドメインの文章構造」で潰す

追加学習では、評価データが学習に混ざると数字が嘘っぱちになります。

ID で評価セットを除外するのは当然として、文書どうしが互いを長文で引用し合うドメイン（判例・論文など）では、それだけでは不十分です。
ID が違う学習文書の中に、評価文書の本文が数十字そのまま含まれていることがあるからです。

→ そこで我々は、評価文書全体を長さ \(k\) の窓（shingle）に刻み、学習側に部分一致で照合しました、

$$ \text{leak}(d_{\text{train}}) = \mathbb{1}\!\Big[\,\exists\, s \in \mathrm{Shingles}_k(\mathcal{E}):\ s \subseteq d_{\text{train}}\,\Big],\qquad k=50 $$

（\(\mathcal{E}\) は評価集合の全文。）
数点プローブの素朴照合では取りこぼす部分一致も、shingle 照合なら長い完全一致については高い精度で拾えます（ただし正規化の違い・OCR 誤り・言い換え・49字以下の重複などは取りこぼします）。
迷ったら除外側に倒していますが、定型句が長く一致すると過剰に除外して分布を歪める可能性もあるので、件数は確認しています。

教訓：ドメインの文章構造（引用・定型句）を理解してリーク設計をする。 ID一致チェックだけでは不十分です。

9. 最後は「コストの非対称性」で決める

精度指標が小数点で競るとき、最後の判断は数字の大小ではなく誤りコストの非対称性で行うべきです。

多くの実務タスクでは、見逃し（FN）と過検出（FP）のコストが大きく違います

$$ \text{cost} = \lambda_{\text{FN}}\cdot \mathrm{FN} + \lambda_{\text{FP}}\cdot \mathrm{FP},\qquad \lambda_{\text{FN}} \gg \lambda_{\text{FP}} $$

見逃しが致命的なタスクなら、Recall を保ったまま Precision がわずかに下がる（＝過剰側へ倒れる）モデルは、別ドメインで取りこぼしを大きく回収できるなら採用に値します。

実際、私たちが採用に進めた版は、既存ドメインの Precision がごく僅か下がる代わりに、Recall は維持（評価セット上で見逃しを増やさない）しつつ、新型の取りこぼしを大きく回収するものでした。

ただし、この重み付け（精度の下限ゲートをどこに引くか）はプロダクトの価値判断であり、モデル側が勝手に決めるべきではありません。

現場の数字を添えてプロダクトマネージャなど意思決定者に渡すのが筋です。

10. 実践Tips（試して効いた／効かなかった細かいこと）

ここでは、原理の裏で地味に効いた（あるいは罠だった）実装レベルの知見をご紹介していきます

学習レシピ

• 強いベースほど軽く当てる
  今回のモデル・データ配合では、ヘッド温存＋自己蒸留なら \(\text{lr}=5\times10^{-6}\)・1エポックで十分でした。動かしすぎると即、過剰検出へ転びます。
• LoRA は逆に強めに当てる
  標準 LoRA は \(B\) ゼロ初期化（初期 no-op）から始まり、新設アダプタと新ヘッド行を短期間で適応させる必要があるため、今回の構成では \(\text{lr}=2\times10^{-4}\)・2エポック程度が要りました。
• 凍結しすぎると新型が学べない
  下位層を厚く凍結したら、既存は不変のまま新型 Recall が \(0\) に崩壊。可塑性は残す。
  
  

ラベルとヘッド

• ベースのタグ方式に合わせる（単タグなら単タグ）。
  B/I を勝手に足すとラベル空間が割れる。
  
  
• 新型はオーバーサンプルする
  出現が少数なので学習集合内で数倍に複製。値が毎回変わる生成にしておくと、文字列そのものの暗記リスクは下げられます（ただしテンプレート構造や周辺文脈は暗記されうるので「安全」とは言い切れず、オーバーサンプルはクラス事前分布も変える点に注意）。
• マージして“普通のモデル”で渡す
  消費側は差し替えるだけ。新型は消費側のマッピング1行追加で取り込めるよう、出力ラベル名はベースに合わせる。
  

合成データ設計（“黙る”を教える）

• density
  1文1エンティティをやめ、地の文に固有名を疎らに。
  
  
• 対比ミニマルペア
  同一文型で「固有名修飾あり＝対象型」「裸の総称語／指示語＋総称語＝\(O\)」を対で見せ、「修飾の有無が型を決める」を汎化させる。
  
  
• 総称語・定型句・伏字・断片は \(O\)
  たとえば、【住所】(というPII型)は「行政区接頭辞まで切り詰めて残す」教師も有効。
  
  

実文をクリーンな負例にする

• 公開実文のうち既知の固有名辞書に一致しない文を負例候補とし（判定は辞書 Aho-Corasick で高速化）、教師モデルとの一致・複数検出器・サンプリング監査を通したうえで all-\(O\) の silver negative として使う。辞書に無い＝エンティティが無い、ではない（むしろ本稿で狙う「辞書に載らない新固有名」が偽の負例になりうる）ので、機械任せの一律 all-\(O\) は避ける。
• ほぼ同一文（年号だけ違うテンプレ等）の氾濫は、数値を畳んだ署名での重複排除で抑える。

評価まわりの罠

• 同分布の合成 dev は楽観値になりやすい
  テンプレートや生成規則が学習集合と重なるため、楽観的に出やすい。早期終了の目安程度に。
• Recall だけが上がっても過剰検出とは限らない（Recall に FP は入らない）。ただし Recall 上昇と同時に Precision の急落・予測スパン数の急増・特定ラベルへの集中が起きたら、過剰検出を疑う。Recall と Precision は必ず同時に見る。
• 手元指標は本番パイプラインの代理にならないことがある。 後段にふるい（辞書・否定リスト）があると、モデル単体 Precision と本番 Precision は線形に対応しない。配合比の最終決定は本番評価のフィードバックで詰める。

スキーマ・運用

• 配達元のラベルキーの揺れ（label / entity_type）は取り込み口で両対応に。
  
  
• ラベル名の一括変更（体系のバージョン更新）は機械変換し、「変換後にベース指標が不変」を確認して“純改名”を実証してから適用。
  
  
• 新型の暴発（1文字誤検出など）の最小ガードは、モデルを歪めず消費側の薄い後処理に置く。

広げる技術は「動かさない設計」、これにつきる

さて、ここまでみてきた（ドメインを）広げる技術に関する教訓をおさらいしましょう

1. measure-first
   評価の定義のバグを最初に潰そう！
   （匿名化やラベル変換の扱いで指標は激変します）
   
2. XLM-RoBERTa の階層性を尊重しよう！
   下位層を保護するという設計仮説を、層別凍結の実験で検証する。
3. ヘッドを安易に作り直さない！
   既存の判別境界と非対象クラスの出力先を、安易に捨てない。
4. 自己蒸留でアンカー
   教師＝自分で drift を抑える正則化。新しい能力を足すには外の情報が必要になります。
5. 明確な拡張余地のひとつが新しい型
   既存ラベル空間にない型は、ヘッドを拡張して学習可能な出力先を足す。
6. LoRA は原理から設計しよう！
   低ランク更新は忘却を抑えやすいという傾向を、凍結・低ランク・ヘッド別扱いという具体に落としましょう。（それでも共有エンコーダの両立コストは残ります。）
7. リークは構造で、意思決定は非対称コストで。

まとめ

というわけで、今回は、XLM-RoBERTa ベースの NER モデルを「壊さずに広げる」ための設計思想を、評価の点検から始めて、デコイクラスの温存、自己蒸留によるアンカー、ヘッド手術、LoRA、そしてリーク対策とコストの非対称性まで、ひと通り辿ってきました。

通底していたのは一貫して「動かさない設計」という考え方です。

追加学習は、ベースを少しでも動かせば劣化しかねない綱渡り。

だからこそ、上げ方の小技以上に「どこを凍結し、どこだけ動かすか」を見極めることが本体でした。

一度作り上げたモデルを賢く進化させたい方の、何かのヒントになれば嬉しいです。

次回もまた、機械学習の現場で得たちょっと泥臭い知見をお届けする予定です。

それでは、ここまでお読みいただき、ありがとうございました。

こんにちは！
Qualitegプロダクト開発部です。

Claude Code を使っていると、ツール呼び出しの XML（<invoke> や <parameter>）が画面にそのまま表示されたり、実際にはコマンドや PR 作成が実行されていないのに「完了しました」と報告されたりして、動作がおかしくなることがあります。

そして、その呼び水となる文字列 court や course や count が出現します

本稿では、
この現象（本稿では「XML露出」と呼びます）を実ログから解説し、検知と対策をまとめました。

とか 以下のように course がでたりします

  course
  <invoke name="Bash">
  <parameter name="command"</parameter>
  <parameter name="description">xxx</parameter>
  </invoke>

また、こんな風に count が露出する場合もあります

こんなふうに暴走風の場合も。。

Claude Code を使っていると、まれに <invoke> や <parameter> といったXML風の文字列が、そのまま会話画面に表示されることがあります。

見た目が崩れるだけなら、単なる表示上の不具合に思えるかもしれませんが、 その文字列が示していたはずの

ツール操作が、実際には実行されていない ことがあるこ

とです。

ファイル編集、シェルコマンド、サブエージェント起動、PR作成などが行われていないにもかかわらず、後続の応答が「完了した」前提で進むこともあります。

本稿では、この現象を便宜上「XML露出」と呼びます。 （公式な障害名ではありません）

実際のセッションログをもとに、何が観測できたのか、どこから先が推定なのか、そして運用では何を確認すべきなのかを整理していきたいとおもいます。

なお、よく似た現象は、Anthropic の Claude Code 公式リポジトリにも、利用者による不具合報告として複数投稿されています。

生の <invoke> がテキストとして表示される、stop_reason="tool_use" なのに対応する tool_use が記録に無い、その結果としてコミットやPRが作られていなかった、

といった内容です。

複数の類似報告があり、個別環境だけの偶発的な表示崩れではなさそうです。

本稿公開時点（2026年6月）では、この現象を修正したと明記する公式changelogエントリは確認できず、関連Issueの多く（#63870／#64108／#64690／#68354 ほか）はオープンまたは重複クローズの状態です。
本ブログで紹介する対処方法はすべて、公式修正を待つ間のワークアラウンドとお考えください

1. この現象を本稿で「XML露出」と呼びます

「XML露出」とは、ツール呼び出し用とみられるXML風マークアップ（<invoke> や <parameter> など）が本文に露出し、対応する操作が実行されない、または正常に実行されたか確認できなくなる現象を指す、本稿内の便宜的な呼称です。公式名称ではありません。

露出したからといって常に未実行とは限らず、確実に言えるのは「正常なツール呼び出しとして処理されたかを判断できない」ことです
（後述の復旧手順は、この前提に立っています）。

要点は、二つの問題が重なった状態として捉えることです。

(1)ツール呼び出しパイプラインの不整合 … モデルの出力が、記録上、構造化された tool_use ブロックとして確認できず、対応する実行結果も確認できない。

(2)呼び出しと完了の混同 … 操作が実行された前提で、後続のモデル出力が「完了しました」という文章を生成してしまう。

(1) は、ユーザー側の運用だけで完全に防ぐことは困難です。

だからこそ (2) を断つこと 、 出力（宣言）を信じず、実行結果で確かめる、 が対策の核心になります。 そして「XML露出」は、見た目にすぐ分かるため、ツール呼び出しパイプライン異常の早期警報（カナリア）として使えます。

2. 正常なツール呼び出しはどう動くか

まず、正常時の仕組みを押さえておきましょう。

Claude API の公開仕様では、クライアントツール（Bash やファイル編集など、利用側で実行するツール）の場合、モデルがツールを使いたいとき、応答は stop_reason: "tool_use" と、1個以上の tool_use コンテンツブロックとして返されます。

クライアント側（実行基盤）はそのブロックを読み、実際のツールを実行し、結果を tool_result ブロックとして返します。

モデルはその結果を受け取って続きを生成します。
（Web 検索などのサーバーツールは Anthropic 側で実行されるため、この限りではありません。本稿が扱うのはクライアントツールです。）

「ツールの要求」「ツールの実行」「実行結果の確認」が別々の段階でおこる、ということが重要ですね。

stop_reason: "tool_use" は、あくまでモデルが実行を要求していることを示すメタデータであり、ツールが実行された証拠ではありません
（詳細は How tool use worksがくわしいです）。

一方、<function_calls> や <invoke> といったXML風の表記は、Claude API の公開仕様として保証された形式ではありません。

これは Claude Code 系の内部表現、あるいは失敗時のシリアライズ表現とみられるもので 本稿の対象も「LLMエージェント一般」ではなく、Claude Code および Claude 系エージェントで観測された現象に限定します。

（公開API上の正常な流れ）

モデル: stop_reason="tool_use" + tool_use ブロック   ← 実行の「要求」
  ↓
クライアント: tool_use を読み、実際に実行
  ↓
クライアント: tool_result を返す                      ← 実行の「結果」
  ↓
モデル: 結果を受けて続きを生成

ということで、「XML露出」は、この流れのどこかで、ツール呼び出しが記録上、構造化された tool_use ブロックとして確認できず、対応する実行結果も確認できない状態に相当します。

3. 実ログで起きていたこと

発生環境（実測値） はこんなかんじですます。

※ これらは「同じ環境なら必ず再発する」ということはなく、単に観測時の条件となります。

とりわけ、Opus 4.8 の 1M コンテキストを有効化し、文脈使用率が半分程度（約55%）に達した状態で発生した点は、後述の context rot に関する仮説（§5）と照らして記録しておく価値があります。

舞台は、サブエージェントを4体ずつ「波（wave）」で並列起動し、多数のタスクを順に処理していたセッションです。波1〜波6までは正常でした。問題は波7で起きました。

3-1. XMLが本文に露出したログ

まず、利用者の画面には次のような見え方になります。本来は裏で実行されるはずのツール呼び出しが、ただの文字列としてそのまま表示されます
（この時点で、これらの操作は正常に実行されたかどうか、わからず）

波6完了。波7（タスク0001-0004）を起動します。

court
<invoke name="Task">
<parameter name="description">作業 0001</parameter>
<parameter name="subagent_type">general-purpose</parameter>
<parameter name="prompt">あなたはタスク実行エージェント。対象: task-0001。…（長文プロンプト）…</parameter>
</invoke>
<invoke name="Task"> …0002… </invoke>
<invoke name="Task"> …0003… </invoke>
<invoke name="Task"> …0004… </invoke>

これを記録（トランスクリプト）として見ると、次のようになっていました。

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "波6完了。波7（タスク0001-0004）を起動します。\n\ncourt\n<invoke name=\"Task\">\n<parameter name=\"description\">作業 0001</parameter>\n<parameter name=\"subagent_type\">general-purpose</parameter>\n<parameter name=\"prompt\">あなたはタスク実行エージェント。対象: task-0001。…（長文プロンプト）…</parameter>\n</invoke>\n<invoke name=\"Task\"> …0002… </invoke>\n<invoke name=\"Task\"> …0003… </invoke>\n<invoke name=\"Task\"> …0004… </invoke>"
    }
  ],
  "stop_reason": "tool_use",
  "usage": { "output_tokens": 3809 }
}

このログから読み取れるのは、、
content の型が "text" ＝ <invoke …> の塊は、構造化された tool_use ブロックとしてではなく、ただの本文テキストとして記録されています。 にもかかわらず stop_reason は "tool_use" ＝ 応答上は「ツール実行を要求して停止した」状態です。

崩れの痕跡として、XML風の断片がいきなり <invoke> から始まっており、その直前には court という宙ぶらりんの語も見えます。

<invoke name="Task"> が4連発 ＝ 長文プロンプトのサブエージェントを4体まとめて並列起動しようとしていたことがうかがえます。

※ 先頭に紛れる court（環境によっては call）という素のテキストは、本稿だけの偶発ではなく、公式リポジトリの不具合報告でも、ツール呼び出しが実行されず生の <invoke> が露出する直前のサインとして繰り返し観測されているみたいです（Issue #64108／#68354）。

冒頭のデモは、同じ現象を Bash 呼び出しで示した例ですが、露出するツールは Task に限らず Bash／Edit／Read など複数種類で報告されており、本稿の波7の例（Task の並列起動）も、その一形態とのようです

3-2. ツール呼び出しが記録に残らなかったログ

その直後（出し直した）ターンです。

{
  "role": "assistant",
  "content": [
    { "type": "text", "text": "サブエージェント波7（タスク0001-0004）を起動します。" }
  ],
  "stop_reason": "tool_use",
  "usage": { "output_tokens": 3609 }
}

content は前置きの一文だけで、<invoke> のかけらもありません。

なのに stop_reason は "tool_use"、output_tokens は 3609 です。 stop_reason と content の食い違い（「ツール実行を要求して止まった」とされているのに、記録上は実行可能な tool_use ブロックが1つも無い）が、この現象の核心にみえます。

これは「モデルが地の文にうっかり書いた」だけでは説明できず、XMLが見えた前者は「部分的に露出した」現れ方、見えなかった後者は「記録に残らなかった」現れ方であり、同じ不整合の二つの現れ方とも考えられます。

なお、output_tokens には表示された本文だけでなく、thinking（拡張思考）等のトークンが含まれる場合があるので、3609 という数字だけを根拠に「数千トークン分のツール呼び出しが消えた」と安易に結論づけることもできないでしょう。

で、何が重要かというと、トークン数ではなく、stop_reason="tool_use" と、記録されたコンテンツブロックとの不整合の部分ではないでしょうか。

4. ログから分かること／分からないこと

ここで、ログで断定できることと、できないことを切り分けておきましょう。

うっかり原因を決め打ちしたくないので、整理します。

つまり、このログから確実に言えるのは、

記録された応答内に構造化された tool_use ブロックがなく、対応する tool_result も確認できないことまでです。

モデルが正しい呼び出しを生成しなかったのか、ストリーミングやパースで失われたのか、トランスクリプトへの保存時に欠落したのかは、このログだけでは特定できません。

したがって本稿では、「ハーネス側の捕捉漏れ」と原因を確定はせず、
「ツール呼び出しパイプラインの不整合が確認できる」
という表現にとどめました。

5. なぜ運用上危険なのか

さて、危険の本質は、見た目の乱れではなく進行の食い違いにあります。

実行記録から見ると
stop_reason="tool_use" だが、対応する構造化 tool_use や tool_result が無い
　→ その操作が正常に実行されたことを確認できません。

後続のモデル出力から見ると
操作が完了した前提で文章が続く
　→ 結果が返った前提で次に進みます。

なお今回の事例では、後続の状態および成果物を照合した結果、対象タスクが未実行だったと判断しています
（一般論としての「確認できない」と、今回の実測としての「未実行だった」は分けて扱います）。

このズレが2つの事故を生みます。

(1) 実行結果を伴わない成功報告

副作用のある操作で特に問題になります。

gh pr create の呼び出しが生成される。
しかし実行可能な tool_use として渡らず、実行されない。

それでも後続の応答は「PRを作成しました」と述べ、PRをつくった気になってい、それらしいURLを提示する。

でも、 ユーザーがクリックすると 404。
PRなんぞ存在しないではないか。

「動いた／できた」を実行結果ではなく文章として報告してしまうのが、最大の害です。

(2) サイレント欠落（処理した前提の未処理）

バッチ処理では、
「波7を起動した前提で実際は1体も動かず、そのまま波8へ進む」
という静かな取りこぼしが起き得ます。

「波7 完了」と表示
　→ 実際は タスク0001〜0004 が未処理
　→ 後工程は「全部やった」前提で進む
　→ 最終成果から4件が静かに欠落。

§3のログでは結果的に救われています
（直後に波7を再送し、対象タスクがその後の数ターンに連続して現れた＝リカバリ成功）。

ですが、気づかなければ欠落は静かに残りますし、stop_reason だけ見ると成功に見えるため、自動進行・無人運転ほど危険です。

なぜ長文・並列セッションで起きやすいと考えられるか

長い文脈で指示追従や想起の精度が落ちる「context rot」自体は、
Anthropic の公式資料でも、トークン数の増加に伴って精度や想起能力が低下する現象として説明されています
（Effective context engineering for AI agents）。

長時間・ツール多用セッションで「XML露出」が発生したという報告は複数あり、長文脈下では指示追従や構造保持が不安定になりやすい、という仮説と整合的です。

ただし、セッション開始直後から発生したという報告もあり、並列ツール呼び出しやツール構成との関連を疑う報告もあります。

したがって、 「XML露出」はセッション品質劣化の早期警報として利用できます。

ただし、短いセッションでの報告もあり、context rot だけを原因とみなすことはできません。 という整理が妥当です。「XML露出」は context rot のカナリアというより、ツール呼び出しパイプライン異常のカナリアと捉えるほうが正確です。

6. 検知・復旧・予防

6-1. 検知（diagnostics）

まず検知です。

露出して「見える」ものは気づけます。怖いのは記録に残らない形と、実行結果を伴わない成功報告なので、見た目に頼らず機械的・実測的に検知します。完了は宣言ではなく結果で判定するのが原則です。

6-2. 復旧（出てしまったら）

操作によっては危険なので慎重に進めます。

さて、上記コラムのとおり、
露出した呼び出し自体は通常は未実行ですが、
・同じターンの別ツールが先に実行されていたり、
・並列バッチの一部だけ走っていたりすることがあります
（並列呼び出しでは1件の失敗が兄弟呼び出しのキャンセルを招くという報告もあります）。

PR作成・デプロイ・課金・メール送信などを無条件に再実行すると二重実行の恐れがあるため、まず外部状態を確認してから慎重に動きましょう。

ざっくりいうと、露出したXMLが示すコマンドは本当に実行されてるのか（実行されてない可能性高い）を確認して、引継ぎ文章をつくらせて、はやめにそのセッションを終わらせる　という感じが良さそうです。

ただ、症状がおもいと引継ぎ文章すらつくれないので、そういう場合は、

①XML露出が怒ってしまったセッションログをコピペして、

②「こういう事象で前セッションを途中終了したけど、続きをやってほしい」

と新セッション側で伝えることも効果的です。

6-3. 予防（出る前に）

発生率を上げると疑われるのは、長文・並列・複雑な引数です。要求を小さく分け、品質が落ちる前に区切る・圧縮する・状態を外に出す、が予防の柱です。

6-4. 仕組みで守る（設計・運用）

個々の注意ではなく、運転ループ自体に「宣言と結果を突合する関門」を組み込みます。stop_reason を完了の証拠にしないのが前提です。

まとめ

「XML露出」の実体はツール呼び出し要求と実行結果の不整合、および実行結果を伴わない成功報告という、二つの問題が重なった状態です。

ログから確実に言えるのは、stop_reason="tool_use" なのに実行可能な tool_use ブロックが記録に無いことまでです。

どの段階（モデル生成／ストリーミング／パース／保存）で不整合が起きたかは、このログだけでは特定できません。

最悪の症状は、未実行のまま成功を報告し、存在しないURL（404）を案内すること、そして処理した前提のサイレント欠落を残すことです。stop_reason だけ見ると成功に見えるため、無人運転ほど危険です。

守りの核心は3つです。

踏まない（少数ずつ実行する・複雑なコマンドを分割する・1テーマで区切る・早めに /compact する）

実測で検知（先頭の call／court・stop_reason×実行件数・結果の成功確認・リモート裏取り・母数照合）

出たら慎重に対応（実行済みと数えない・部分実行と外部状態を確認・冪等に再送、崩れが続けば新セッション）。

一行でまとめると：ツールを「呼んだこと」と「実行され、期待した結果が得られたこと」は別です。宣言ではなく結果を確認しましょう。

URLを貼る前に、そのURLの実在を確かめましょう。

お読みいただきありがとうございました。
また、次回お会いしましょう！

参考資料

公式ドキュメント

• How tool use works（Claude API Docs）― stop_reason: "tool_use" は実行の「要求」であり、クライアントが実行して tool_result を返す多段プロトコルであること。
• Effective context engineering for AI agents（Anthropic Engineering）― トークン数の増加に伴って精度や想起能力が低下する「context rot」の説明。
• Environment variables（Claude Code Docs）― 自動圧縮しきい値と CLAUDE_AUTOCOMPACT_PCT_OVERRIDE の仕様（既定は約95%、低い値で早められるが、既定より高い値には効果がない）。

Anthropic 公式リポジトリ上の利用者による不具合報告

これらは Anthropic の公式リポジトリに投稿されたものですが、内容は基本的に利用者による不具合報告であり、Anthropic が原因や再現条件を公式に認定した資料とは限りません（重複としてクローズされたものも含みます）。現象の観測例として参照しています。

• Issue #63870 ― Bash tool calls emitted as raw <invoke> text instead of executing ― 生の <invoke> が通常テキストとして残り、コミット・push・PR作成などが実行されていなかった詳細ログ。
• Issue #64108 ― 先頭に紛れる court トークンに続いて生の <invoke> が露出し、Edit/Read が実行されない報告（先頭の court が一貫した特徴とされる）。
• Issue #64690 ― Tool invocation XML tags intermittently corrupted ― ツール呼び出しタグ名が破損・露出して実行されない報告（重複としてクローズ）。
• Issue #68354 ― 先頭に call／court という素テキストが出たのち、XML風表現が露出し、ツールが実行されない報告。
• Issue #31806 ― CLAUDE_AUTOCOMPACT_PCT_OVERRIDE で既定より高い値を設定しても効かない（Math.min クランプ）ことを示す補助資料（重複としてクローズ）。

※ 本稿中の「同時3〜4体まで」「品質が落ちる前に圧縮」などの数値・運用方針は、Qualiteg としての暫定運用値であり、普遍的なしきい値ではありません。環境ごとに検証してご利用ください。

ここ数年で、サイバーセキュリティをめぐる議論の前提は大きく変わりました。かつての中心は「いかに侵入を防ぐか」でしたが、いまは攻撃側も防御側も、ともにAIを使い始めています。攻撃が機械の速度で自動化・大規模化する一方、防御も人手だけでは追いつかない領域に入りつつあります。本記事では、公開されている市場データをもとに、AI時代のセキュリティ市場を「どこが伸び、どこが重なり、どこに注意すべきか」という観点から整理します。

「AIとセキュリティ」には三つの市場がある

最初に、用語を整理しておきます。「AIセキュリティ」とひとくくりにすると分かりにくいのですが、実際には少なくとも三つの異なるテーマが同時に進んでいます。

この三つの違いは、「誰がAIを使うのか」と「何を守るのか」で考えると分かりやすくなります。

第一は、防御側がAIを使う「AIで守る」領域です。
攻撃者がAIを使っているかどうかにかかわらず、企業やセキュリティ事業者がAIを利用して、サイバー攻撃やインシデントを検知・分析・阻止します。大量のログやアラートの分析、脅威の優先順位付け、異常の検知、初動対応の支援などは、すでに実運用に入り始めています。

第二は、攻撃側がAIを使う「AIを使った攻撃から守る」領域です。
ここで問題になるのは、AIシステムそのものへの攻撃ではなく、攻撃者がAIを道具として利用し、従来のサイバー攻撃を高速化・低コスト化・大規模化することです。フィッシング文面や偽音声の大量生成、脆弱性探索や偵察の高速化、マルウェア作成の補助、流出データの自動分析などが該当します。

第三は、AIそのものを攻撃から守る「AIシステムを守る」領域です。
この領域では、AIは防御の道具でも攻撃の道具でもなく、守るべき対象そのものになります。学習データの汚染、モデルの窃取や改ざん、プロンプトインジェクション、RAGの参照データの汚染、AIエージェントの権限悪用など、AIを業務システムに組み込むことで生まれる新しい攻撃面への対策が中心です。

つまり、第一は防御者がAIを使う話、第二は攻撃者がAIを使う話、第三はAI自体が攻撃される話です。

私たちは、このうち第三の領域を早い時期から追ってきました。たとえば「LLM-Audit：LLM攻防の最前線」では、LLMそのものを狙う攻撃と、それをどう防ぐかという構図を整理しています。当時から繰り返し論じてきたテーマが、いまや独立した市場として明確に立ち上がりつつある、というのが、本記事の出発点です。

NISTも、サイバーセキュリティとAIの関係を「AIシステムのセキュリティ」「AIを利用した攻撃」「AIを利用した防御」というおおむね三つの領域に分けて整理しています[7]。これらは互いに重なり合っていますが、対象となる製品も、予算も、リスクの性質も同一ではありません。市場規模を見るときも、何を「AIセキュリティ」に含めているのかを確認する必要があります。

数字で見る「現在地」

世界のサイバーセキュリティ市場については、調査会社によって算定範囲に大きな差があります。

MarketsandMarketsは2025年を約2,276億ドル、2030年を約3,519億ドルと予測する一方[1]、Grand View Researchは2025年を約2,719億ドル、2033年を約6,632億ドルと推計しています[2]。

Fortune Business Insightsはさらに、2025年を約2,190億ドル、2034年には約6,994億ドルへ達するとしています[3]。

おおまかにまとめれば、世界のサイバーセキュリティ市場は2025年時点で約2,200億〜2,700億ドル規模にあり、2030年には3,500億ドルを超えると予測されています。

さらに調査会社によっては、2033〜2034年に6,600億〜7,000億ドル規模へ達するという見通しも示されています。

各社の差は、どこかが単純に誤っているというより、ハードウェア、ソフトウェア、プロフェッショナルサービス、マネージドサービスなどをどこまで市場に含めるかが違うために生じています。市場規模は単一の確定値ではなく、定義に応じたレンジとして読むのが適切です。

そのなかで、AIを活用したサイバーセキュリティは、全体市場より速い成長が見込まれています。

Fortune Business Insightsは、2025年の市場規模を約341億ドル、2026年から2034年までの年平均成長率を約21.7%と推計しています[4]。セキュリティ投資のなかでAIが占める比率は、今後さらに高まっていくと考えられます。

さらに新しい領域として立ち上がりつつあるのが、AIエージェントの行動、権限、通信、利用ツールを保護・監視する「Agentic AI Security」です。

MarketsandMarketsは、この市場が2026年の約16.5億ドルから2032年には約135.2億ドルへ、年平均約42%で成長すると予測しています[5]。

ここで注意したいのは、これは「自律型AIがセキュリティ業務を行う市場」だけを指すものではない、という点です。

プロンプトの保護、ガードレール、AIレッドチーミング、エージェントのID・権限管理など、AIエージェントを安全に運用するための製品やサービスが幅広く含まれます。これは、ここで参照した市場予測のなかでは突出して高い成長率です。

ただし、新しく定義されたばかりの小規模市場を起点とする予測であり、絶対額や市場の境界そのものには大きな不確実性があります。それでも、エージェントの権限・行動・通信を管理する領域に投資が集まり始めていることを示すシグナルとしては、注目に値します。

なお、これらの市場は互いに重複しています。サイバーセキュリティ市場、AIセキュリティ市場、Agentic AI Security市場を単純に足し合わせると二重計上になる点には、注意が必要です。

なぜ伸びているのか――五つの要因

成長を支えている要因は、ひとつではありません。大きく分けると五つあります。

第一に、攻撃対象の拡大です。クラウド移行、IoT機器の普及、リモートワークの定着によって、守るべき「面」が一気に広がりました。境界を固めれば守れた時代は終わり、エンドポイントやクラウド環境ごとに防御が必要になっています。

第二に、攻撃側によるAI利用です。フィッシング文面や偽音声の大量生成、脆弱性探索や偵察の高速化、マルウェア作成の補助、流出データの自動分析など、AIは既存の攻撃を低コストかつ大規模に実行可能にします。

第三に、AIシステムそのものへの攻撃です。学習データの汚染(データポイズニング)、モデルの窃取・改ざん、プロンプトインジェクション、ツールや権限の悪用、RAGやエージェントメモリの汚染など、AI特有の弱点を突く手口が現実の脅威になってきました。企業がAIに意思決定を委ねるほど、そのAIを守ることが事業継続の前提条件になります。

ここで守るべき対象は、外部からの攻撃だけではありません。業務利用では、利用者がプロンプトへ個人情報や機密情報を入力してしまう、あるいはモデルの出力にそれらが含まれてしまうといった、意図しない情報流出も重要なリスクになります。とくに日本語の個人情報は、氏名、住所、組織名、文脈に依存する識別情報など、単純なパターンマッチだけでは捉えにくいものがあります。私たちはこの課題について、「LLM時代の企業情報防衛」や日本語PII検出技術の記事で継続的に取り上げてきました。

第四に、規制の強まりです。とくにEUでは、重要事業者のリスク管理とインシデント報告を求めるNIS2、金融分野のデジタル・オペレーショナル・レジリエンスを定めるDORA、デジタル製品のセキュリティ要件を課すCyber Resilience Act、そしてAIのリスク管理・透明性・ガバナンスを求めるEU AI Actが相次いで動いています。EU AI Actは2024年8月に発効し、禁止行為とAIリテラシー義務は2025年2月、ガバナンス規則とGPAI(汎用AI)関連義務は2025年8月から適用が始まっています。多くの規定は2026年8月から適用されますが、2026年5月の政治合意では、Annex IIIに該当する一定の高リスク用途に関する規則は2027年12月、規制対象製品に組み込まれるAIシステムについては2028年8月から適用する日程が示されました[8]。「やった方がよい」から「やらなければならない」へと、企業の動機が変わってきました。

第五に、人員とスキルの不足です。ISC2の2025年調査では、単純な人数不足よりも、必要なスキルの不足が重い課題として認識されるようになっています。AI関連スキルは2年連続で最も求められるスキルに挙げられ(回答者の41%)、クラウドセキュリティ(36%)がこれに続きました[6]。同調査はこの年、従来公表していた「人材不足数」の推計値の発表を取りやめ、人数よりも能力・スキルを重視する姿勢に転じています。大量のアラートやログを限られた人員で処理する必要があることが、分析・優先順位付け・初動対応の自動化を後押ししています。

AI対AIの攻防で、本当に差がつくもの

攻撃側がAIを使い、防御側もAIで対抗する構図は、今後ますます一般化していくでしょう。

ただし、勝敗を決めるのは、単にどちらのモデルが高性能か、どちらが速く学習するかではありません。重要なのは、質の高いテレメトリ(監視データ)をどれだけ集められるか、ID・端末・クラウド・ネットワークを横断して全体を捉えられるか、誤検知をどれだけ抑えられるか、異常を安全に制御された対応へ結び付けられるか、そしてその判断と行動を監査・説明できるか、という点です。

ここで注意したいのは、性質の異なる二つの「誤り」を分けて管理する必要があるということです。ひとつは、正常な事象を攻撃と判定してしまう検知モデルの誤検知。

もうひとつは、LLMが根拠のない説明や事実を生成するハルシネーションです。後者については、根拠との整合性を検証するハルシネーション検出が有効ですが(当社でもこの技術を継続的に追っています)、端末隔離や認証情報の無効化といった実アクションには、最小権限、承認フロー、ロールバック可能性といった別の制御が欠かせません。AIの出力をそのまま信じない仕組みづくりは、AI対AIの時代にこそ効いてきます。

防御の自動化そのものは進みます。MarketsandMarketsによれば、人が介在する半自律型(Human-in-the-Loop)が2026年時点で約74%を占めると予測されています[5]。同レポートでは、完全自律型のセキュリティエージェントも独立した市場区分として扱われています。

ただし「完全自律」と一括りにするのは粗すぎます。端末の隔離、認証情報の無効化、通信の遮断、パッチの適用では、誤った判断をしたときの影響範囲がまったく異なります。何を、どこまで自律的に実行させるのか――その線引きが、実務では決定的に重要になります。

人間ではないIDをどう管理するか

今後の中心テーマとして見落とせないのが、AIエージェントの「IDと権限」です。

AIエージェントがコードをデプロイし、メールを送り、データベースを操作するようになると、「そのエージェントは誰の代理なのか」「何をしてよいのか」「権限をいつ失効させるのか」が新たな問題になります。人間の従業員と同じように、エージェントにも身元確認、認証、認可、そして退場の仕組みが要る、という発想です。

私たちはこの論点を「ゼロトラスト時代のLLMセキュリティ完全ガイド」で取り上げ、「何も信頼しない」前提のもとでLLMやエージェントをどう守るか、そしてエージェントの行動を監視・制御する「ガーディアンエージェント」という考え方を論じてきました。本記事でいう「人間ではないIDの管理」は、まさにその延長線上にあるテーマです。NISTも、ソフトウェアおよびAIエージェントの識別・管理・認可を独立したテーマとして扱い始めています[9]。

これから注目すべき変化――時間軸で見る

将来テーマを同じ平面に並べると、投資の優先順位が見えにくくなります。おおまかな時間軸で整理してみます。

2026年現在〜3年。 すでに実装が進んでいる領域です。ログやアラートの分析・トリアージを自動化するAI SOC、ディープフェイクやなりすましといった詐欺・情報操作への対策、そしてAIの利用そのものを統制するAIガバナンスが中心になります。とくにガバナンス領域は、Gartnerが「AI TRiSM(AI Trust, Risk and Security Management)」と呼ぶ独立した市場セグメントとして立ち上がりつつあります[10]。セキュリティの観点では、AI資産の検出・棚卸し、入出力やデータ流通の監視、ランタイムでのポリシー強制、モデルやエージェントの継続的評価、インシデント記録と監査証跡の確保などが具体的な論点です。AI TRiSMという市場概念のもとで、これまで個別に論じられてきたガードレール、データ保護、モデル監視、入出力制御が、ひとつの運用体系として整理され始めています。当社ブログでも、Llama Guardをはじめ、これらを構成する技術を継続的に追ってきました。

3〜5年。 限定された領域での自律対応、複数のエージェントを束ねて監視するマルチエージェント監視、そしてAIのサプライチェーン(学習データやモデルの調達経路)の保護が本格化していくと見られます。

5〜10年。 ポスト量子暗号への本格的な移行が進みます。将来の量子コンピュータは、RSAや楕円曲線暗号など、現在広く使われている公開鍵暗号を危殆化させる可能性があります(共通鍵暗号やハッシュ関数への影響は、これとは性質が異なります)。NISTは2024年8月に最初の標準群を正式化しており[11]、暗号資産の棚卸しや移行計画は、すでに「将来検討するテーマ」ではなくなりつつあります。あわせて、より広範な自律防御もこの時間軸で現実味を帯びてくるでしょう。

成長市場でも、すべてが新規予算ではない

最後に、見落とされがちな視点をひとつ。AIセキュリティの拡大は、まったく新しい製品カテゴリーが純粋に積み上がるだけではありません。既存のIAM(ID管理)、SOC、EDR、SIEM、クラウドセキュリティ、データ保護といった製品が、AI対応へと再編される側面も大きいのです。

McKinseyも、ID、検知、セキュリティ運用といった機能が消えてなくなるのではなく、AIの能力と自律システムの統制を取り込む形で作り替えられていく、と指摘しています[12]。「市場が伸びる=すべて新市場」という単純な図式ではなく、既存予算の組み替えと新規投資が混在している、と捉えるのが実態に近いはずです。

個別の防御技術から、AI運用の統制基盤へ

ここまで見てきた市場の変化を、私たちは単に「新しいセキュリティ製品が増えること」だとは捉えていません。

これまで個別に扱われてきたプロンプトのガードレール、個人情報の検出、モデル出力の監査、ゼロトラスト、エージェントのID・権限管理が、ひとつのAI運用基盤へ統合されていく変化だと考えています。

LLMが文章を生成するだけであれば、入出力を検査するガードレールが防御の中心でした。しかしAIエージェントが外部ツールを呼び出し、データを更新し、業務上のアクションまで実行するようになると、見るべき対象は文章だけでは足りません。誰の権限で、何を参照し、どの操作を行い、その結果をどのように記録したのかまで管理する必要があります。

ガードレールから、データ保護へ。さらにID、権限、行動監視、監査証跡へ。この制御範囲の拡大こそが、今後のAIセキュリティ市場を形作る大きな流れだと、私たちは見ています。当社ブログで個別に取り上げてきたガードレール、PII検出、ハルシネーション検出、ゼロトラスト、ガーディアンエージェントといったテーマも、いま振り返れば、この一本の流れの上に並んでいます。

おわりに

整理すると、セキュリティ市場はすでに大きく、なお速く伸び、そのなかでAI関連の比重が急速に増している――というのが全体像です。とりわけ自律型AIをめぐる攻防は、規模こそまだ小さいものの、伸び率と戦略的重要性の両面で、次の10年の焦点になりそうです。

確かなのは、「AIでどう守るか」「AIを使った攻撃からどう守るか」「AIシステムそのものをどう守るか」という三つの問いが、これからますます切り離せなくなるということです。攻撃と防御がともにAIを手にした時代に、何を前提に投資し、どのリスクに、どの順番で備えるか――その判断の質が、組織の安全を左右していくことになるでしょう。

※本記事の市場規模および成長率は、MarketsandMarkets、Grand View Research、Fortune Business Insightsなどが2025〜2026年に公表した推計を参照しています。各社で市場の定義、対象製品・サービスの算入範囲、基準年が異なるため、数値は直接比較できない場合があります。また、AIセキュリティ、Agentic AI Security、AIガバナンスなどの市場には一部重複があり、各市場規模を単純に合算することはできません。将来値はいずれも予測であり、実績値を保証するものではありません。

当社のLLMセキュリティ関連記事(抜粋)

本記事で触れたテーマは、当社ブログで継続的に扱ってきたものです。あわせてご覧ください。

全体像・攻撃モデル

• LLM-Audit：LLM攻防の最前線

データ・PII保護

• LLM時代の企業情報防衛：PIIセキュリティの新たな課題
• 高精度PII検出技術 ― 日本語の難しさに向き合う

ガードレール・出力検証

• 【LLMセキュリティ】Llama Guard：AI安全性の第一歩
• 【LLMセキュリティ】ゼロリソース・ブラックボックスでのハルシネーション検出
• LLM Security: How to Detect Hallucinations(Lynx)

ゼロトラスト・エージェント統制

• ゼロトラスト時代のLLMセキュリティ完全ガイド：ガーディアンエージェントへの進化を見据えて
• AIエージェント時代の新たな番人「ガーディアンエージェント」とは？

参照元

市場規模は調査会社のレポート、法制度は欧州委員会、標準・技術分類はNIST、人材調査はISC2を一次情報源としています。本文中の番号に対応します(いずれも2026年6月閲覧)。

1. MarketsandMarkets「Cybersecurity Market: Navigating an Era of Rapid Growth and Evolving Threats」(市場ブログ、2025年11月7日付、対象期間 2025–2030)
   https://www.marketsandmarkets.com/blog/ICT/cybersecurity-market
2. Grand View Research「Cyber Security Market Size, Share & Trends Analysis Report」(対象期間 2025–2033)
   https://www.grandviewresearch.com/industry-analysis/cyber-security-market
3. Fortune Business Insights「Cyber Security Market Size, Share & Industry Analysis」(対象期間 2025–2034)
   https://www.fortunebusinessinsights.com/industry-reports/cyber-security-market-101165
4. Fortune Business Insights「Artificial Intelligence in Cybersecurity Market Size, Share & Industry Analysis」(2026年6月1日更新、対象期間 2025–2034、CAGRは2026–2034、Report ID: FBI113125)
   https://www.fortunebusinessinsights.com/artificial-intelligence-in-cybersecurity-market-113125
5. MarketsandMarkets「Agentic AI Security Market — Global Forecast to 2032」(Report、対象期間 2026–2032)
   https://www.marketsandmarkets.com/Market-Reports/agentic-ai-security-market-97017233.html
6. ISC2「2025 ISC2 Cybersecurity Workforce Study」(2025年12月公表)
   https://www.isc2.org/Insights/2025/12/2025-ISC2-Cybersecurity-Workforce-Study
7. NIST/NCCoE「Cyber AI Profile」(AIシステムのセキュリティ／AIを利用した攻撃／AIを利用した防御の三領域整理)
   https://www.nccoe.nist.gov/projects/cyber-ai-profile
8. 欧州委員会「AI Act — Regulatory framework for AI」(2024年8月発効、2026年5月7日の政治合意を含む適用日程)
   https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
9. NIST/NCCoE「Software and AI Agent Identity and Authorization」(検討中のプロジェクト)
   https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
10. Gartner「Market Guide for AI Trust, Risk and Security Management」(2025年2月18日)
    https://www.gartner.com/en/documents/6185655
11. NIST「Post-Quantum Cryptography Standards」(FIPS 203/204/205、2024年8月13日正式化)
    https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
12. McKinsey & Company「Securing the agentic enterprise: Opportunities for cybersecurity providers」(2026年3月24日)
    https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/securing-the-agentic-enterprise-opportunities-for-cybersecurity-providers

その他の参照: 欧州委員会(NIS2、DORA、Cyber Resilience Act)。