Author

technews

世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

Claudeの「超過課金」は自動発生しない——note記事の補足と2026年6月の仕様変更

先日、「Claudeは weekly limit や 5hours limit を突き破ったときのペナルティ料金が半端ない」 という記事が話題になった。Claude CodeやOpusでコードベース解析を回していると、10分足らずで従量課金が発生し得るという警告は実体験として貴重だが、エンジニアが実際に運用判断をする上で誤解しやすいポイントがいくつかある。本記事はその補足として、Anthropic公式ドキュメントに基づき仕組みを整理する。

超過課金は「オプトイン」——デフォルトはOFF

最大の誤解ポイントはここ。Claude Pro/Maxで週次・5時間の利用上限に達しても、​Usage credits（超過課金）を明示的に有効化していない限り、追加料金は一切発生しない。上限に達した場合の既定動作は「リセットまで待つ」だけで、勝手にAPI従量課金へ切り替わることはない。

有効化するには以下の手順が必要:

• Settings > Usage から Usage credits セクションで Enable をクリック
• 支払い方法を登録し、プリペイド方式で残高をチャージ（Add funds）
• 月間上限を Adjust limit で明示指定するか、Set to unlimited で無制限にする
• 残高が一定額を下回ると自動チャージする「auto-reload」も選択可能

つまり note記事にあるような「気づいたら$13課金されていた」は、Usage creditsを能動的にONにし、かつ上限を無制限のまま使い続けた場合にのみ起こる話であり、デフォルト運用では発生しない。なお無制限設定でも1日あたりの償却上限は$2,000に設定されており、際限なく張り出すわけではない。

有効化した場合の課金レート

Usage creditsを有効化した状態で上限を超過すると、以降の利用は標準API料金で課金される。Claude CodeやOpusはコードベース全体を読み込むぶんトークン消費が大きく、大規模リポジトリ解析では確かに単価が跳ねやすい。この点は元記事の警告どおりで、有効化して使う場合は月間上限（Adjust limit）を必ず具体的な金額で設定しておくことを推奨する。

2026年6月15日: 非対話利用が別枠課金に変更

もう一つ、note記事執筆時点では反映されていなかった重要な変更がある。2026年6月15日付で、​非対話的（non-interactive）なClaude Code利用——claude -p、Agent SDK経由の呼び出し、GitHub Actions連携、サブスクリプション経由で動くサードパーティアプリなど——が、これまでのサブスク定額枠から切り離され、標準API料金を消費する別枠の月次クレジットに移行した。

• Pro: $20/月
• Max 5x: $100/月
• Max 20x: $200/月

対話的セッション（ターミナルで自分がタイピングしてやり取りする通常のClaude Code利用）は従来どおりサブスクの定額枠が適用される。CI/CDやSDK経由の自動化を組んでいる場合、コストの見積もりをこの別枠クレジットで行う必要がある点に注意したい。

週次上限と5時間上限の仕組み

Max/Proプランの週次上限は実は2種類ある:

• 全モデル合算の週次上限
• Sonnetモデルのみに適用される週次上限（Opusはこちらにはカウントされない）

いずれもアカウントごとに固定された曜日・時刻でリセットされる。また5時間セッション上限は2026年に倍増改定されており、Pro/Max/Team/シート課金Enterpriseで上限に達しにくくなったほか、Pro/Maxではピーク時間帯の上限引き下げも撤廃されている。「10分で制限に張り付く」という体感は、この改定前の挙動に基づいている可能性がある。

実務上の対策

• 追加課金の可能性をゼロにしたいなら、Usage creditsは触らずデフォルトのままにする。上限到達後はブロックされるだけで課金はされない。
• 長時間のエージェント作業を途切れさせたくない場合のみUsage creditsを有効化し、必ずAdjust limitで具体的な月間上限を設定する（無制限は非推奨）。
• CI/自動化パイプラインでClaude Codeを非対話実行している場合、対話利用とは別枠の月次クレジットで消費される点を踏まえてコスト設計する。
• 日常使いはClaude、コード解析はOpusという元記事の使い分け自体は妥当。ただし「上限到達=即高額課金」ではなく「上限到達=待つか、明示的にONにするか」の二択であることを踏まえて運用したい。

まとめ

元記事が指摘する「Claude Codeはトークン消費が大きく単価が張りやすい」という点自体は正確であり、Opusでの大規模解析には注意が必要というのは実務上有益な警告だ。一方で「勝手に高額課金される」という不安は、Usage creditsがデフォルトOFFのオプトイン機能である以上、過度に恐れる必要はない。設定画面で何もいじらなければ、上限到達時は単に待つだけで済む。

同じ著者の記事

【2026年7月版】Outlookが「起動しない・クラッシュを繰り返す」最新事情 — 6月末の一斉クラッシュはビルド2605が原因、直し方はほぼ一択

「昨日まで普通に使えていたClassic Outlookが、右クリックした瞬間に落ちる」「起動してもすぐ強制終了し、次はセーフモードで開く」——2026年6月末から、この手の悲鳴がまた一気に増えた。半年前・1年前に書かれた「Outlookが起動しない完全解決ガイド」的な記事が今また読まれているのは、まさに今、Classic Outlookのクラッシュが立て続けに起きているからだ。 本稿は、2026年前半に発生した複数のクラッシュ事案を発生時期・影響ビルド・原因・修正状況で整理し直し、「自分のケースはどれで、何をすれば直るか」を最短で切り分けられるようにしたものだ。結論から言うと、直近の主犯は更新プログラムの回帰（リグレッション）で、多くは“Officeを最新へ更新するだけ”で直る。設定を9個いじる前に、まずここを見たほうが早い。 > ⚠️ 先に結論: 2026年6月29日ごろから急にClassic Outlookが落ち始めたなら、疑うべきは自分の設定ではなく **Microsoft 365 Apps バージョン2605（Build 20026.20182

papoo.work

【2026年7月版】Outlookの「送信済みメールが消える」が再燃 — 犯人はWindows更新プログラム KB5074109 の可能性

「送信は成功したのに、送信済みアイテムに残っていない」——Outlookの定番トラブルが、2026年に入ってから再び相談件数を増やしている。半年前(2026年1月)に出回った解説記事の手順は今でも基本として有効だが、2026年に急増した“送信済みが消える”の主犯は、従来の設定ミスではなく Windows のセキュリティ更新プログラムそのものであることが分かってきた。本稿はその現況を、切り分け順に整理し直したものだ。 > ⚠️ 先に結論: 1月中旬以降にClassic Outlook(デスクトップ版)で急に「送信済みに入らない」「Outlookが固まる」が始まったなら、まず疑うべきは自分の設定ではなく 更新プログラム KB5074109 と PSTファイルの置き場所(OneDrive配下かどうか) だ。設定を10個いじる前に、ここを先に見たほうが早い。 --- 2026年1月のWindowsセキュリティ更新 KB5074109 導入後、**Classic Outlookで送信メールが「送信済みアイテム」に記録されない／Outlookが終了しない・フ

papoo.work

【続報】サナエトークン、ついに「当事者2人の法廷闘争」へ――三崎優太氏が溝口勇児氏に内容証明、いまどこまで進んだか

前回まで、私たちはサナエトークン騒動を「補償」「金融庁」「高市首相の否定」という3つの軸で追ってきた。補償は6月10日に申請サイトが開き、金融庁の損失相談は6月時点で5件、首相は国会で改めて全面否定――というのが直近の現在地だった。ところが騒動はここへ来て、まったく別の局面に入っている。行政・補償の話から、当事者どうしの個人間紛争、それも法廷闘争へと重心が移ったのだ。本稿はその続報である。 https://papoo.work/doc/7de9f0cf1b564dc9 実業家の三崎優太氏（元「青汁王子」）が、実業家の溝口勇児氏に内容証明を送付したと明かし、「きっと裁判になる」と法廷闘争を予告した。 三崎氏は溝口氏とみられる人物の会議音声を公開し、「責任を他人になすりつけている（＝トカゲの尻尾切り）」と批判。溝口氏は「編集で切り取っている」「補償対応はやっている」と反論した。 6月26日、三崎氏は両者が共同運営していたYouTube番組「REAL VALUE」からの脱退を表明。ただし本稿執筆時点（7月7日）で、**正式な「提訴」の公

papoo.work

ブラウン大学で起きた「AIカンニング」騒動、大学の信頼はどう守るのか

ブラウン大学の経済学者ロベルト・セラーノ教授が、担当科目の試験で少なくとも50人がAIを使って不正をしたと訴えている。 問題になったのは、持ち帰って解く形式の試験。自宅でじっくり考えられる反面、ChatGPTのようなAIを使いやすい。 期末試験では平均点が一気に落ち、欠席者の多くが前回満点だったことから、教授は「証拠は圧倒的」と見ている。 ブラウン大学の反応は鈍く、教授は「大学全体で学問の誠実さを守る議論が必要だ」と主張している。 背景には、米国の名門大学で広がるAI利用の誘惑と、教育のあり方そのものを揺さぶる問題がある。 ブラウン大学で起きたこの話、かなり重いです。しかも、ただの「試験でズルした人がいました」という話では終わりません。大学が長年かけて築いてきた信頼、つまり「ここで学んだ学生の成績には意味がある」という前提そのものが、AIの登場でぐらついている。この記事は、その現場で何が起きているのかをかなり生々しく伝えています。 中心にいるのは、ブラウン大学の著名な経済学者ロベルト・セラーノ教授です。彼は、数学的経済学の上級学部生向け講義 ECON 1170 を担当していて、

papoo.work

AIにMRIを読ませたら、医師と真逆の答えが出た話

肩が痛い。だからMRIを撮った。そこまではよくある話です。ところがこのブログ記事は、そこで終わりません。著者はそのMRI画像を、OpenAI系のモデルではなく、Claude Code上で動かしたOpus 4.8に読ませて、「もう一つの診断」を引き出そうとします。で、出てきた答えがかなり衝撃的でした。医師は「腱板の部分断裂（Grade III）」と見たのに、AIは「腱は保たれている」と判断したんです。 この差、かなり大きいです。しかも著者は、ただAIに雑に投げたわけではありません。DICOM形式のMRIデータを用意し、Claude Codeに必要なパッケージを入れさせ、かなり本気で解析させています。単なるお遊びではなく、「AIが医療画像をどこまで読めるのか」を自分の体で試した記録、と言ったほうが近いです。 肩の痛みでMRIを撮った著者が、AIに画像の再読影をさせた 人間の医師は「Grade IIIの部分断裂」と判断した Opus 4.8は最初、「腱は正常」と報告した その後、別の条件で再比較させた結果、AIは「明らかな断裂は見当たらない」と結論づけた ただし著者自身は、AIも医師も完全に

papoo.work

AIコーディングは「レビュー」より「テスト」で殴るほうが強い、という話

著者は、AI coding を使っていると「人間なら即クビ」レベルの妙な挙動に何度も遭遇したが、それでも利用をやめるどころか、さらに使い込むようになった。 この記事の中心テーマは、AI にコードを書かせるときは code review 以上に test process が大事 だ、という主張。 その根拠として、著者は昔働いていた CPU 設計会社 Centaur のテスト文化を紹介する。そこでは、手書きテストより fuzzing や random testing を重視し、unit test はほぼ使わず、専任の test engineer がいた。 著者は、AI 時代の開発でも「人間が全部レビューする」より、「大量の自動テストで叩く」ほうが現実的で、しかも強いと考えている。 ただし、これは単なる理想論ではなく、実際にバグを見つけて直してきた現場の感覚から来ている。 本文を読んでまず面白いのは、著者の出発点がかなり変わっていることです。AI coding を「便利な補助輪」ではなく、かなり攻めた実験装置として見ています。しかも、その最初の印象がすごい。バ

papoo.work

Apple Neural Engineの中身を、かなり踏み込んで覗いた研究

Appleの「Neural Engine」、通称ANEは、iPhoneやMacの中で静かに働く専用チップです。顔認識、写真の補正、音声処理、生成AIの一部まで、裏側でかなり多くの仕事を抱えています。ふだんはCore MLというApple公式の仕組み越しにしか使えないので、一般の開発者から見ると「中はブラックボックス」の代表格でした。 今回のarXiv論文は、そのブラックボックスをかなり本気で分解したものです。しかも単なる憶測ではなく、Apple silicon上での直接計測と、private runtime、compiler、kernel driver、firmwareの静的解析を組み合わせている。こういう研究は地味に見えて、実はとても面白いです。Appleが“使わせるつもりのない層”にまで手を伸ばして、仕組みを記述しているわけですから。 この論文は、Apple Neural Engineのアーキテクチャ、プログラミング方法、性能の限界をまとめた「リバースエンジニアリングのガイド」です。対象はA11世代のiPhone/iPadチップからA18、そしてM1からM5まで。かなり広い。 特に

papoo.work

AMDでもここまで速い。GLM-5.2を“安く速く”動かしたWaferの話

Waferは、GLM-5.2をAMDのMI355X GPU上で動かし、かなり高い性能を出した。 しかもポイントは「速い」だけでなく、「Blackwell系より2倍以上安いのに性能効率が高い」こと。 ただし、AMDで最先端LLMをそのまま使うのは簡単ではなく、quantizationやinference frameworkの調整がかなり効いている。 speculative decode という高速化手法のために、ROCm向けの小さな修正も必要だった。 個人的には、ここで見えるのは「GPUの勝負」だけではなく、「ソフトウェアの面倒をどこまで減らせるか」が勝負になってきた、という現実だと思う。 Waferの記事は、タイトルの通りかなりストレートです。要するに「1ドルあたりの性能、まだ伸ばせるし、しかも安くできる」という話です。対象はGLM-5.2というオープン系の大規模言語モデルで、これをAMD MI355X上でかなりうまく動かした、という内容でした。 まず数字が強いです。Waferは、20k input / 1k output、cache hit rate 60% という条件で、1ノードあ

papoo.work

Codexに「見ちゃダメなファイル」を教える仕組みがほしい、という話

GitHubのopenai/codexリポジトリに、ちょっと地味だけどかなり重要な要望が出ています。内容はシンプルで、AIエージェントに読ませたくないファイルを明示的に除外したい、というものです。 これ、派手さはないんですが実際にはかなり大事です。AIにコードを書かせる時代になっても、「これは見せていい」「これは絶対にダメ」の線引きは、人間がしっかり持っていないと危ない。そこをちゃんと仕組みにしよう、という提案です。 このIssueで求められているのは、エージェントが読み込んだり、モデルに送ったりしてはいけないファイルやパスを明示できる機能です。 しかも単なる一時的な指定ではなく、次の2段階を想定しています。 リポジトリごとの設定 ユーザー全体のグローバル設定 たとえば、プロジェクト内に `.codexignore` のようなファイルを置いて「このリポジトリではこのファイル群は触るな」と定義する。一方で、ユーザー側にも「どのプロジェクトでも `.env` や秘密鍵っぽいものは見せない」という共通ルールを持てるようにしたい、という考えです。 ここで面白いのは、**“プロジ

papoo.work

文字を画像にしてトークンを節約する、かなり変わったProxy「pxpipe」

Claude CodeのようなLLM向けツールで、長いテキストをそのまま送らず、画像に変換してからモデルに渡す仕組み 文字がぎゅっと詰まった内容ほど得をしやすく、場合によってはトークン使用量を大きく削減できる ただし万能ではなく、IDやハッシュのような“1文字でも間違えたら困る情報”は危ない だからこそ、安くなる場面と危ない場面を見極める設計になっている 発想はかなり攻めているが、実務の痛点をちゃんと突いていて面白い pxpipeは、ひとことで言うと「LLMに渡す長文を、必要に応じて画像に圧縮してしまうローカルProxy」です。Proxyというのは、アプリとAPIのあいだに入って通信を中継する仕組みのこと。ブラウザの世界でいう“中継サーバー”みたいなものだと思えば大きく外れていません。 普通、LLMにたくさんの文章を読ませると、そのぶんトークンが増えます。トークンは、AIが文章を扱うときの細かい単位で、課金やコンテキスト長の計算に使われます。つまり、長文を入れるほどお金も容量も食う。これは避けようがない、と思われがちです。 でも pxpipe はそこに逆張りをします。大量のテキストをP

papoo.work