Claude Codeの料金・従量課金を解説｜Fable 5停止とOpus 4.8移行の影響

【2026年7月4日更新】Claude Codeの従量課金やFable 5停止の影響は、料金表だけでなく自動実行、モデル切り替え、チームの利用ルールまで含めて確認が必要です。

Claude Codeを使っていて、突然課金が変わるのか、Fable 5（AnthropicのClaude系モデル名）の停止で何を直すべきなのか不安な方は少なくありません。この記事では、Claude Codeの従量課金（使った量に応じて料金が増える支払い方式）、claude -p（Claude Codeをコマンドで1回実行し結果を受け取る方法）、Agent SDK（Claudeを自社アプリや業務システムに組み込むための開発キット）、Fable 5停止、Opus 4.8（移行先候補として扱う高性能モデル）移行をまとめて整理します。

結論から言うと、2026年6月16日時点ではClaude Codeのclaude -pやAgent SDKに関する従量課金変更は保留されています。ただし、自動実行や高性能モデルの利用が増えるほどコスト管理は重要になるため、料金の仕組み、向いている使い方、避けるべき運用を分けて理解することが大切です。

この記事は、Claude Codeの従量課金が気になっている開発者、AI導入を管理する事業責任者、社内でClaude CodeやAgent SDKを使っているチーム向けです。単にニュースを追うだけでなく、何を確認すればコスト超過や業務停止を避けられるのかまで整理します。

Claude Code従量課金とFable 5停止で何が起きたのか

大きな論点は2つあります。1つ目は、Claude Codeの非対話実行（人が途中で会話せず、一度渡した指示を自動処理する使い方）であるclaude -pやAgent SDKの扱いです。Anthropicは一時的に、こうした自動化的な利用をクレジット（あらかじめ使える利用枠）/従量課金に寄せる流れを示しましたが、2026年6月16日時点ではその変更は保留されています。

2つ目は、Claude系モデル名であるFable 5 / Mythos 5の停止です。こちらは従量課金の話とは別件で、利用中のモデル指定（どのAIモデルを使うかを決める設定）やワークフローに影響する可能性があります。

この図解で押さえるべき点は、予定されていた変更と、実際に起きた保留を分けて理解することです。2026年6月15日に予定されていたのは、Claude Codeの一部自動化利用に対する料金ルール変更でした。一方で、実際にはその変更がいったん保留され、すぐに全ユーザーへ新しい従量課金が適用されたわけではありません。

非エンジニア向けに言えば、これは「使うたびに必ず追加料金が発生するようになった」という単純な話ではなく、「自動で大量に使う機能について、今後は別の料金管理が必要になる可能性がある」という話です。したがって、今すぐ利用を止めるよりも、どの機能が対象になり得るか、誰が管理するかを整理することが重要です。

Claude Code従量課金とFable 5停止の結論

2026年6月16日時点では、Claude Codeのclaude -pやAgent SDKに関する従量課金変更は保留されています。つまり、今すぐ全ユーザーの請求方式が一斉に変わったわけではありません。ただし、Anthropicが自動実行やエージェント利用のコスト管理を見直している流れは明確であり、Claude Codeを業務や開発ワークフローに組み込んでいる場合は、使用量、上限、モデル指定を早めに確認しておく必要があります。

また、Fable 5を前提にしたプロンプトや教材、社内手順がある場合は、Opus 4.8などの代替モデルへ切り替えたときに出力品質やコスト感が変わらないかを検証してください。今回の論点は単なる料金ニュースではなく、Claude Codeを安全かつ継続的に使うための運用設計に関わる話です。

claude -pとは何か：Claude Code自動実行の基本

claude -pは、Claude Codeをコマンドライン（文字でPCに指示を出す操作画面）から非対話的に使うための実行方法です。非対話的とは、チャットのように途中で会話を重ねるのではなく、最初に指示を渡して結果を受け取る形式を指します。公式CLI referenceでも、claude -pはSDK経由で問い合わせて終了するコマンドとして説明されています。スクリプト、CI（コード変更時に自動テストやチェックを走らせる仕組み）、自動レビュー、夜間処理などと相性があります。

便利な一方で、人間が毎回画面を見て確認する前提ではないため、処理回数や投入データ量が増えるとコスト管理が難しくなります。

対話モードとclaude -pの違いは、人がその場で会話しながら進めるか、あらかじめ渡した指示を自動で実行するかです。対話モードは、チャットのように質問と回答を繰り返す使い方です。claude -pは、最初に命令文を渡し、Claude Codeに処理させ、結果を受け取る使い方です。

この違いは料金管理にも関係します。対話モードでは人が操作しているため使いすぎに気づきやすい一方、claude -pはスクリプトや自動処理に組み込めます。便利ですが、設定を誤ると人が見ていない場所で何度も実行されるため、実行回数、対象ファイル数、使うモデルを決めておく必要があります。

claude -pの主な利用場面

代表的な使い方は、自動コードチェック、テストコード生成、複数ファイルへの定型修正、ログ解析レポートなどです。つまり、個人が一回だけ試す機能というより、開発ワークフローに組み込むほど価値が出る領域です。

図解の内容を本文で補足すると、claude -pの価値は「人手の作業を自動化・無人化できること」にあります。ここでいう無人化とは、人が一つずつ画面を開いて確認しなくても、決めた条件に沿ってAIが処理を進める状態です。便利な反面、裏側で何度もAIが動くため、従量課金やクレジット消費の管理が重要になります。 自動化とは、毎回人がボタンを押したり確認したりする作業を、決めた条件で機械に実行させることです。

1. 自動コードチェック：修正内容の抜け漏れを早く見つける

自動コードチェックは、開発者がコードを変更したときに、AIがバグやセキュリティ上の問題を確認する使い方です。非エンジニア向けに言えば、文章の誤字脱字チェックに近い役割ですが、対象は文章ではなくプログラムです。人が毎回細かく読む前に、危ない箇所や見落としやすい差分を先に洗い出せます。

2. テスト自動生成：動作確認の手順をAIに作らせる

テスト自動生成は、まだテストが作られていないファイルや機能を見つけ、AIに確認用のコードを作らせる使い方です。テストとは「この機能はこの条件で正しく動くはず」という確認手順です。手作業だと後回しになりやすい確認作業を、開発フローの中に組み込みやすくなります。

3. 定型作業の一括処理：複数ファイルの同じ修正をまとめて進める

定型作業の一括処理は、100ファイルに同じ修正を入れる、古い書き方を新しい書き方へそろえる、名前や設定の表記を統一するといった作業です。単純な置換だけなら通常のツールでもできますが、Claude Codeを使うと、周辺の文脈を見ながら修正できる点に価値があります。

4. 夜間レポート作成：ログを解析して翌朝までに要点をまとめる

夜間レポート作成は、サーバーのエラーログ（システムで起きた失敗や異常の記録）や実行結果を夜のうちに解析し、翌朝に確認しやすい形でまとめる使い方です。ログとは、システムで何が起きたかを残す記録です。人が出社してから一つずつ読むのではなく、AIに重要なエラーや傾向を先に整理させることで、対応の初動を早くできます。

つまり、claude -pは「一回だけAIに相談する機能」ではなく、コードチェック、テスト自動生成、定型作業の一括処理、夜間レポート作成のような繰り返し作業で効果が出ます。だからこそ、使い放題に見える定額枠から、実行回数や処理量に応じた管理へ変わる可能性がある点を押さえる必要があります。

Claude Code従量課金はどう変わる予定だったのか

予定されていた変更では、claude -p、Claude Agent SDK（Claudeを自社アプリや業務システムに組み込むための開発キット）、GitHub Actions（コード変更時に自動チェックを動かす仕組み）連携、Agent SDK経由のサードパーティ利用などが、定額枠とは別のクレジット（あらかじめ付与される利用枠）や従量課金に近い扱いになる可能性がありました。普段のClaude.aiやClaude Codeの対話利用は、主な対象ではないと整理できます。

この図解でいう従量課金の対象は、主に自動実行や外部連携に近い使い方です。具体的には、claude -pでの自動実行、Claude Agent SDKを使ったアプリ連携、GitHub Actionsのような自動チェック、Agent SDKを経由した外部サービスでの利用が含まれ得ます。

ここで重要なのは、普段のClaude.aiのチャット利用と、開発ワークフローに組み込まれた自動利用を分けて考えることです。後者は一度設定すると何度も動くため、使った量に応じて料金が増える従量課金と相性がよく、企業側では予算上限や承認フローが必要になります。 Anthropic公式のCosts docsでも、Claude Codeの費用はAPIトークン消費と関係し、モデル選択や利用パターンで大きく変わると説明されています。APIトークンとは、AIが読み書きする文字量を数える単位のようなものです。

Pro・Max・Team・Enterpriseのクレジット設計

案内されていた内容では、プランごとに一定額のクレジットが付与され、クレジットを超える利用については設定次第で追加課金または停止という扱いになる想定でした。ここで重要なのは、クレジットを使い切ったあとの挙動です。自動化処理が止まるのか、追加課金で続くのかは、運用上のリスクに直結します。

クレジット設計の図解は、プランごとに最初から使える枠が違うことを示しています。クレジットとは、一定範囲まで使える利用枠のことです。携帯電話のデータ容量に近く、枠内であれば追加料金を気にしにくい一方、枠を超えると止めるのか、追加利用を許すのかを決める必要があります。

オプトイン申請とは、追加利用を自動的に許可するのではなく、利用者や管理者が明示的に申し込むことです。特にTeamやEnterpriseでは、個人が勝手に追加利用するのではなく、管理者がクレジット上限、超過時の扱い、部署ごとの利用ルールを決める設計が重要になります。

影響を受ける人・受けにくい人

今回の論点は、Claude Codeをどの程度自動化しているかで影響度が変わります。毎回ターミナルで会話しながら使うだけなら、急に大きな運用変更が必要になる可能性は高くありません。一方で、CI、夜間バッチ、定期レビュー、社内ツールからの呼び出しに組み込んでいる場合は、利用回数とモデル指定を把握しておく必要があります。

影響を受けやすいケース

• claude -pをシェルスクリプトやGitHub Actionsから定期実行している
• Agent SDKを使って社内ツールや顧客向けワークフローを作っている
• Opus 4.8など高性能モデルを固定指定し、重いコード解析や大規模修正に使っている
• 複数メンバーが同じ請求アカウントでClaude Codeを使い、利用量の可視化が弱い

影響を受けにくいケース

• 個人が対話モード中心で、短時間のコード相談や差分レビューに使っている
• 月次の利用上限や支払い管理者が明確で、重い処理を実行する前に確認できる
• 単純作業は軽量モデル、重要な設計判断は上位モデルという使い分けができている

Claude Code従量課金で注意すべきコスト管理

Claude Codeの従量課金で最も注意したいのは、自動実行の回数が増えるほど月末のコストが読みにくくなる点です。1回あたりの処理が安く見えても、CI、夜間バッチ、定期レポート、複数リポジトリの自動レビューに組み込むと、実行回数とトークン量が積み上がります。特にOpus 4.8のような高性能モデルを常時使う設計にすると、短時間でも費用が膨らみやすくなります。

チームでClaude Codeを使う場合は、誰がどの処理を実行できるのか、ログをどこで確認するのか、上限に達したときに停止するのか追加課金を許可するのかを決めておくことが重要です。従量課金そのものを避けるというより、用途ごとに実行条件とモデル選択を分け、予算を超えない運用にしておくことが現実的な対策になります。

Claude Code従量課金のデメリット・メリット

Claude Code従量課金を判断するときは、料金が上がるかどうかだけでなく、デメリットとメリットを分けて見ると理解しやすくなります。Anthropic公式のCosts docsでも、Claude Codeの費用はモデル選択、処理量、利用パターンで変わると説明されています。つまり、自動化を増やすほど便利になる一方で、管理ルールがないと費用と停止リスクが見えにくくなります。

表のポイントは、Claude Codeの費用を「1回いくら」だけで見ないことです。たとえば1回のコードチェックが小さな金額でも、CIや夜間処理で毎日何十回も動けば月額は膨らみます。逆に、時間のかかるレビューやログ分析を短縮できるなら、一定の従量課金を払っても業務全体では安くなる場合があります。

Claude Codeの従量課金で確認すべき要点は次の3つです。

• 1回の金額ではなく、日次・月次の実行回数で見る
• Opus 4.8のような高性能モデルを使う作業を限定する
• クレジット上限後に止める処理と続ける処理を事前に決める

デメリット：コストが読みにくく、処理停止リスクもある

最大のデメリットは、AIが裏側で何度も動くほど月額コストが読みづらくなることです。自動コードチェック、テスト自動生成、夜間レポートのような処理は、人が操作しなくても実行されるため、使っている本人が気づかないうちに利用量が増えることがあります。

特に注意したいデメリットは次の通りです。

• 自動実行の回数が増えると、月末まで総額を把握しにくい
• クレジット上限に達した場合、重要な処理が途中で止まる可能性がある
• すべてを高性能モデルに固定すると、費用対効果が悪くなりやすい

クレジットとは、あらかじめ使える利用枠のことです。上限後に止めるのか、追加課金を許すのかを決めていないと、開発やレポート作成が途中で止まるリスクがあります。非エンジニアの管理者は、細かいコードよりも「どの処理が自動で走るのか」「誰が停止を判断するのか」を確認する方が実務的です。

メリット：AI利用を見える化し、無駄な自動化を減らせる

一方で、従量課金にはメリットもあります。どの処理にどれだけAIを使っているかを見える化しやすくなり、効果の薄い自動化や、必要以上に高性能モデルを使っている処理を見直すきっかけになります。

メリットを活かせるのは、次のような運用です。

• コードレビューやテスト作成など、削減できる作業時間が明確な処理から始める
• モデル指定を用途別に分け、重い処理だけOpus 4.8を使う
• 利用ログを見て、効果の薄い自動化を止める

特にチーム利用では、利用ログ、モデル指定、上限設定を管理できるようになると、AI活用を個人の勘ではなく運用ルールとして扱えます。Claude Codeを業務基盤として使う会社にとって、これは単なる節約ではなく、AI利用を安全に広げるための土台になります。

Claude Codeを賢く使う方法：向いている人・向いていない人

Claude Codeを賢く使う方法は、すべてをAIに任せることではありません。繰り返し作業、レビュー、テスト、ログ確認のように、人が毎回同じ判断をしている領域から小さく導入し、効果とコストを見ながら広げることです。

向いている人・チーム

向いているのは、コードレビュー、テスト作成、複数ファイルの修正、エラーログ分析を継続的に行っているチームです。これらは作業手順がある程度決まっており、AIに任せる範囲を定義しやすいからです。

また、利用上限や承認フローを決められる組織にも向いています。誰がどのモデルを使うか、Opus 4.8をどの作業に限定するか、月ごとの予算をどこで見るかを決めておくと、コスト管理と品質管理を両立できます。

向いていない人・チーム

向いていないのは、利用ログを見ないまま自動処理を増やすチームです。特に、すべての処理を高性能モデルに固定したり、失敗時の停止条件を決めずに夜間処理を走らせたりすると、費用と安全性の両方でリスクが大きくなります。

非エンジニアの管理者が見るべきポイントは、細かいコードの中身ではありません。どの業務にAIを使っているか、月いくらまで許容するか、問題が起きたときに誰が止めるかです。この3点を決めてから使う方が、Claude Codeを安全に活用できます。

判断基準はシンプルです。Claude Codeは、繰り返し発生する開発作業を減らしたいチームには向いています。一方で、利用量を誰も見ないまま自動化だけを増やす運用には向いていません。

実務チェックリスト：今日確認すること

Claude Codeを業務に組み込んでいるなら、ニュースを読むだけで終わらせず、利用実態を棚卸しすることが重要です。特に、従量課金が再導入された場合に止めたい処理と、追加コストを払ってでも続けたい処理を分けておくと、急な変更にも対応しやすくなります。

• Claude Codeの /usage や管理画面で、誰がどの程度使っているかを確認する
• claude -p、Agent SDK、GitHub Actions、定期実行ジョブを一覧化する
• 各ジョブのモデル指定を確認し、Opus 4.8固定が必要な処理だけに絞る
• クレジット上限到達時に、停止するのか追加課金を許可するのかを決める
• Fable 5やMythos 5など、停止済みモデル名がプロンプトや教材に残っていないか検索する
• 重いログや大きなファイルをそのまま渡さず、前処理で必要部分だけに絞る

Touch AI編集部の見解：Claude Codeは個人任せにしない

今回の従量課金保留とFable 5停止から見える本質は、AIツールの性能比較ではなく、業務で使うAIを個人の裁量だけに任せてよいのかという運用設計の問題です。Claude Codeは便利な開発支援ツールですが、無人実行、外部連携、モデル指定、利用ログが絡むと、もはや単なる個人ツールではなく社内の開発基盤に近い存在になります。

Touch AI編集部としては、Claude Codeを業務に入れるなら「使ってよい/使ってはいけない」という二択ではなく、どの処理を、どのモデルで、誰の承認で、どこまで自動化するかを決めることが重要だと考えます。特にclaude -pやAgent SDKは、便利さと同時にコスト・セキュリティ・継続性の責任も増やします。

3レイヤーで管理する

• 実行前：AIに渡してよいデータ、使ってよいモデル、実行できる人を決める
• 実行中：/usage、管理画面、ログで使用量と失敗を見える化する
• 実行後：出力結果、修正履歴、請求影響を振り返り、次回の実行条件を調整する

この3レイヤーを整えるだけで、従量課金が再導入された場合でも、いきなり高額請求になるリスクや、重要な自動処理が月末に止まるリスクをかなり下げられます。AI活用を広げるほど、自由度ではなく運用ルールが価値を守ります。

モデル別の料金とOpus 4.8のコスト感

モデル料金は、入力データ量と出力データ量で変わります。スライド内では、Opus 4.8を使った場合の概算として、軽いコード確認で1回あたり約5円、テストコード生成で約13円、大きなファイルの書き換えで約38円というイメージを置いています。

これは固定料金ではありません。実際の費用は、入力、出力、モデル、処理内容によって変わります。重要なのは、1回あたりの単価が小さく見えても、自動化やチーム利用では積み上がることです。

モデル別料金の図解は、AIモデルごとに得意分野と料金感が違うことを示しています。ここでいうモデルとは、Claudeの頭脳の種類です。一般に、高性能なモデルほど複雑な作業に強い一方、同じ量を処理しても費用が高くなりやすいと考えると理解しやすいです。

Opus 4.8のコスト感を見るときは、コードを少し確認する軽い作業、テストを作る中程度の作業、大きなファイルを書き換える重い作業を分けます。軽い確認は小さな金額でも、夜間処理や大量ファイルの一括修正のように回数が増えると、1回あたりの単価より総実行回数の方が効いてきます。

そのため、すべてをOpus 4.8に任せるのではなく、重要な設計判断や複雑な修正には高性能モデルを使い、単純な確認や下書きには軽いモデルを使う、という使い分けが現実的です。これは品質とコストの両方を守るための考え方です。

Claude Code従量課金が再導入されたときの対応

Claude Codeの従量課金が再導入された場合は、まずAnthropicからの案内メールと管理画面を確認し、自社アカウントでどの設定が有効になっているかを把握してください。特に、クレジット上限に達したときに処理を止めるのか、追加課金を許可するのかは、開発チームや管理者が事前に決めておくべきポイントです。

次に、Claude Codeの /usage などで利用量を確認し、重い処理や不要なファイル読み込みがないかを見直します。AIに渡すデータを事前に絞るだけでも、入力トークンと処理時間を抑えられる場合があります。大規模な自動化はClaude Codeの対話的な使い方と分け、APIキー利用や専用ワークフローとして設計する方が管理しやすくなります。

モデル選択も重要です。単純な分類や軽い確認は軽量モデルに任せ、難しい設計判断や大きなコード変更だけOpus 4.8のような上位モデルを使うと、品質とコストのバランスを取りやすくなります。最終的には、月額上限、実行権限、ログ確認をセットで整え、高額請求や突然の処理停止を避ける運用にしておくことが大切です。

Fable 5停止後にOpus 4.8移行で確認すべきこと

Fable 5 / Mythos 5の停止は、claude -pの従量課金問題とは別件です。もしFable 5を前提にしたプロンプト、社内手順、教材、検証環境がある場合は、Opus 4.8などの代替モデルで同じ品質や速度が出るかを確認してください。

Fable 5停止後にまず確認すべきなのは、モデル名を固定している設定がないかという点です。社内ドキュメント、教材、検証用プロンプト、CI設定、外部ツール連携の中にFable 5やMythos 5の名前が残っていると、利用者が古い前提のまま作業してしまう可能性があります。重要な業務フローでは、Opus 4.8などへ切り替えた後の出力差分を小さく検証し、品質、速度、費用の変化を確認してから本番運用に戻すのが安全です。

Fable 5とMythos 5の停止に関する図解は、単なるモデル名の変更ではなく、利用可能なモデルが短期間で変わるリスクを示しています。Fable 5やMythos 5はClaudeのモデル名で、記事執筆時点では提供停止が報じられています。つまり、昨日まで使えていた選択肢が、運用上は突然使えなくなる可能性があります。

Opus 4.8へ移行する場合は、単にモデル名を書き換えるだけでは不十分です。出力の傾向、料金、処理速度、既存プロンプトとの相性、社内の承認ルールを確認する必要があります。特に自動化に組み込んでいる場合は、失敗時に止まるのか、別モデルへ切り替えるのかまで決めておくと安全です。

Fable 5停止の背景と現在の確認ポイント

Fable 5 / Mythos 5の停止については、複数の海外報道で、米国政府の輸出管理指令や国家安全保障上の懸念が背景にあると説明されています。公式の復旧時期が明確に示されていない以上、利用者側では停止理由の細部を追い続けるよりも、停止が長引いても業務が回る状態を作ることが現実的です。

特に注意したいのは、モデル名を固定している箇所です。プロンプト本文、CLI設定、社内マニュアル、教材、検証用スクリプト、外部ツール連携に古いモデル名が残っていると、利用者が古い前提のまま作業してしまいます。単にOpus 4.8へ切り替えるだけでなく、出力品質、速度、費用、拒否されるタスクの傾向を小さく比較することが重要です。

移行時に見落としやすい項目

• Fable 5 / Mythos 5を指定しているプロンプト、教材、社内手順を検索する
• 代替モデルをOpus 4.8にした場合の出力差分と費用差分を小さく検証する
• 6月9日から12日前後にプラン購入やアップグレードをした場合は、Anthropicからの案内メールを確認する
• 停止中モデルに依存したデモ、研修資料、営業資料が残っていないか確認する

Claude CodeやClaude系モデルを社内展開する場合、今回のようなモデル停止は例外ではなく、今後も起こり得る運用リスクとして扱うべきです。重要なワークフローでは、モデル名を固定しすぎず、代替モデルで再実行できる手順を残しておくことが、AI活用の継続性を守ります。

Fable 5側の最新文脈は、Fable 5再展開後の使い方・料金記事と提供停止時の背景整理で補足しています。

よくある質問

Claude Codeは今すぐ従量課金になったのですか？

2026年6月16日時点では、claude -pやAgent SDKに関する従量課金変更は保留されています。今すぐ全ユーザーの請求方式が変わったという整理ではありません。ただし、自動実行やエージェント利用のコスト管理が今後も論点になる可能性は高いため、使用量と上限設定の確認は必要です。

claude -pだけを避ければ安全ですか？

いいえ。claude -pは代表例ですが、Agent SDK、GitHub Actions、定期実行、外部ツール連携など、人間が毎回確認しない自動化処理全体がコスト管理の対象になります。使い方ごとに実行回数、入力データ量、モデル指定を確認してください。

Opus 4.8は常に使うべきですか？

高度な設計判断や複雑なコード変更ではOpus 4.8が向く場面がありますが、単純な分類、軽い確認、定型的な調査まで常時Opus 4.8に任せるとコストが膨らみやすくなります。用途ごとにSonnetやHaiku系を含めて使い分ける方が現実的です。

Fable 5停止後は何を直せばよいですか？

まず、社内ドキュメント、教材、検証プロンプト、CI設定、外部ツール連携にFable 5やMythos 5のモデル名が残っていないかを確認します。そのうえで、Opus 4.8などの代替モデルで出力品質、速度、費用を小さく検証してから本番運用へ戻すのが安全です。

公式情報はどこで確認すべきですか？

Claude Codeの基本仕様は公式ドキュメント、料金や利用可能プランはClaude Codeの製品ページ、CLIの挙動はCLI reference、Agent SDKの扱いはAgent SDK documentationを確認してください。この記事末尾にも確認先をまとめています。

参考視聴・公式情報

• Claude Code Docs: Manage costs effectively - /usage、モデル選択、コンテキスト削減の確認先
• Claude Code Docs: CLI reference - claude -p / --print の仕様確認
• Claude Code Docs: Agent SDK overview - Agent SDKの認証・用途・実装確認
• Claude Code product page - 利用可能プラン、モデル、FAQの確認
• Claude API pricing - APIトークン料金の確認
• The Verge: Anthropic cuts off Fable 5 and Mythos 5 access - Fable 5 / Mythos 5停止に関する海外報道
• Tom's Hardware: U.S. gov't orders Anthropic to disable Fable 5 and Mythos 5 - 輸出管理指令に関する報道