【ITニュース解説】A straight line says you'll hit your weekly Claude limit at 4 a.m. on a Friday

今日のITニュースで取り上げるのは、AIチャットボット「Claude」の利用制限にまつわる、とあるプログラマーが開発した便利なツールと、その裏側にある工夫についてだ。システムエンジニアを目指す皆さんにとって、これは単なるツールの紹介にとどまらず、ユーザーが抱える問題を深く理解し、それを技術で解決していくための思考プロセス、そして具体的なアルゴリズム設計のヒントが詰まった興味深い事例となるだろう。

近年、AIチャットボットは、私たちの仕事や学習において欠かせないツールとなりつつある。特にプログラマーがコードの生成やデバッグにAIを活用する「AIペアプログラミング」は、生産性を向上させる可能性を秘めている。しかし、これらのAIサービスには通常、利用できる量に上限が設けられていることが多い。無料プランであれば利用回数や速度に、有料プランや企業向けの契約であれば、時間あたりの利用量や週間の総利用量に制限がかかっている。

筆者が問題視したのは、特に「週間の利用制限」がユーザーにとって非常に分かりにくいという点だった。例えば、あるAIサービス「Claude Code」のサブスクリプションでは、「5時間のセッション（連続利用）制限」と「週間の利用量上限」という二つの制限がある。セッション制限は、使っていると「あと何分で使い切る」といった表示が出るため、感覚的に把握しやすい。しかし、週間の利用制限はそうはいかない。一回のセッションでいくら使ったとしても、それが週全体の利用量にどう影響するかは分かりにくい。週の途中で「現在の利用量は90%に達しました」という通知が来たとしても、それが水曜日で、まだ金曜日まで仕事が残っているとなると、もう手遅れになりがちだ。突然AIが使えなくなってしまえば、作業は滞り、プロジェクトに大きな影響が出てしまう。

この問題を解決するために、筆者は「Claude Code Tray」という小さなWindowsアプリケーションを開発した。これは、Windowsのタスクトレイ（画面右下のアイコンが並ぶ場所）に常駐し、現在のClaude Codeの利用状況をアイコン自体で表示するツールだ。もしこのペースで使い続けると週間の利用制限に達してしまうと判断された場合、アイコンが赤色に変わり、視覚的に警告を発してくれる。さらに、具体的に「いつ、利用制限に達する見込みか」という予測まで表示してくれるため、ユーザーは前もって対策を立てられるようになる。

このツールの肝は、利用制限に達するタイミングを「正しく予測する」ための工夫にある。単に現在の利用ペースを直線的に伸ばすだけでは、正確な予測はできない。筆者は予測の精度を高めるために、四つの重要な点を学んだと述べている。

まず一点目は、「二つの異なる制限には、それぞれ異なる計算方法が必要だ」ということだ。 「5時間のセッション制限」のような短い期間の制限では、直近数分間の利用履歴から、最小二乗法という数学的な手法を使って利用ペースの傾きを計算し、すぐに予測に反映させる。これにより、例えばAIを使い始めて数分で「このペースだと、あと1時間でセッションが切れますよ」といった、即座のフィードバックが可能となる。 しかし、この同じ方法を「週間の利用制限」に適用すると問題が生じた。例えば、ある日の午後だけAIを大量に利用した場合、その一時的な高負荷なペースを週全体に当てはめてしまうと、「このペースだと、明日にも週間の制限に達してしまいます！」といった誤った警告が頻発してしまったのだ。これではユーザーは警告を信用できなくなってしまう。 そこで、週間の利用制限には別のルールが採用された。これは、今の利用量を、週の経過日数から計算される「均等なペース」（例えば、週が3日経過していれば、全体の3/7を使っているのが均等なペース）と比較するというものだ。現在の利用量がこの均等なペースを上回っている場合にのみ、警告を出す。週全体での平均的なペースを計算する式は「100%に達するまでの時間 ＝ 経過時間 × (100 − 利用済み) ÷ 利用済み」というもので、これはこれまでの平均ペースに基づいて残りの利用量を使い切るまでの時間を予測する基本的な計算ロジックだ。この方法は、一時的な高負荷に左右されず、週全体での傾向を捉えることができる。しかも、過去の利用履歴を詳細に保存する必要がなく、最初の利用データから正確な予測が可能となる。

二点目は、「直線的な予測では、現実の利用実態と乖離する」という点だ。 週全体の利用量を均等に消費すると仮定する前述の方法は、警告の是非を判断するには適しているが、具体的に「いつ使い切るか」という正確な時間予測には向かない。なぜなら、人間は24時間AIを使い続けるわけではないからだ。例えば、均等ペースで計算すると、「金曜日の午前3時59分に利用制限に達します」という予測が出ることがある。しかし、その時間にAIを使う人はほとんどいないだろう。 そこで、このアプリの「Statistics」ウィンドウでは、さらに高度な予測が導入された。これは、ユーザーのローカルPCに保存されているClaude Codeの利用履歴（トランスクリプト）から、過去のタイムスタンプを分析し、「どの曜日の何時頃にAIを使っているか」というユーザー自身の「活動パターン」を学習するのだ。そして、残りの利用可能量を、この学習した活動パターンに合わせて配分し直す。通常はAIを使わない時間帯（例えば深夜や週末）は消費量をフラットに、普段作業している時間帯に集中して消費されると仮定して計算する。これにより、「実際に作業ができなくなるのは、〇曜日の午後〇時頃だろう」という、より現実的な予測が可能になる。この予測は「〇時頃」というように、少し曖昧な表現で示されるが、これも予測には不確実性が伴うことを考慮し、ユーザーに寄り添った設計と言える。

三点目は、「データが少ないうちは、無理に複雑な予測をせず、控えめに表示するべきだ」という教訓だ。 活動パターンに基づいた予測は非常に有用だが、それには十分な量の過去データが必要となる。例えば、利用履歴がまだ数日しかない状態で、複雑な活動パターンを無理に推測しようとしても、それは単なる「ノイズ」から作られた不正確なものになってしまう。不確かな情報で複雑なグラフなどを表示してしまうと、かえってユーザーを混乱させ、予測の信頼性を損ねてしまう。そのため、筆者は約3週間分の履歴が蓄積されるまでは、単純な平均ペースによる直線的な予測に留めるという判断をした。データが十分に集まってから、より詳細な予測に切り替えることで、信頼性を確保している。これは、機械学習の分野で「過学習」と呼ばれる、データが少ないのに複雑なモデルを適用してしまい、かえって予測精度が落ちる現象を防ぐことにも通じる考え方だ。

そして四点目は、「警告は、具体的な解決策とセットで提示されることで、より有用になる」という考え方だ。 単に「あなたは木曜日に利用制限に達します」と伝えるだけでは、ユーザーは困ってしまう。「で、どうすればいいの？」という疑問が残るのだ。そこで、活動パターンを考慮した予測で利用制限に早期に達すると示された場合、このアプリはさらに一歩踏み込んで、「もし今すぐ作業を中断し、〇月〇日の〇時頃に再開すれば、週の制限内に収まりますよ」という具体的なアドバイスを提示してくれる。もちろん、アドバイスとして提示されるのは、ユーザーが通常作業する時間帯に限られる。もし、どんなに調整しても週の制限内に収めることが不可能だと判断された場合は、無理に架空のアドバイスを出すのではなく、何も提示しないという選択肢を選ぶ。これも、ユーザーにとって本当に役立つ情報を提供するという、ユーザー体験（UX）を重視した設計思想が表れている部分だ。

このアプリがどのようにClaude Codeの利用状況を把握しているかというと、Claude CodeがPC内に保存している認証情報（OAuthトークン）を読み取り、最小限のAPI（Application Programming Interface）コールを行って、レートリミット（利用制限）に関するヘッダー情報を取得している。これにより、PC上のClaude Codeだけでなく、claude.aiのWebサイトや他のデバイスからの利用状況も集計して、週全体の制限にカウントできるという。ただし、これはAnthropic（Claudeの開発元）の利用規約上、グレーゾーンにあたる行為だと筆者自身が認めている。アプリはユーザー自身のPC上で動作し、自身の利用状況を把握する目的で使われるため、禁止されているわけではないが、「Claude Codeの通常の利用方法」とは異なる。筆者はこの点を明確にするため、アプリのREADMEファイルに規約を引用し、ユーザー自身が判断できるようにしている。また、APIへの問い合わせ間隔も設定可能にして、サーバーへの負荷を考慮している。

筆者はこのアプリを、なんと「Claude Code自身」を使って開発したそうだ。つまり、AIチャットボットを使いこなして、そのAIチャットボットの利用を管理するツールを作り上げたわけだ。これは、現代のシステム開発においてAIが強力なツールとなりつつあることを示す好例と言えるだろう。

この事例は、システムエンジニアを目指す皆さんにとって、多くの示唆を与えてくれる。ユーザーが抱える「不便さ」や「困りごと」を深く掘り下げて課題を特定し、それを解決するために、どのようなデータが必要で、どのようなアルゴリズムを設計すれば良いのか、そしてユーザーが直感的に理解し、実際に役立つようなインターフェースはどのようにデザインすべきか。さらに、技術的な制約や利用規約といった現実的な側面も考慮しながら、プロジェクトを進めていく。これらすべてが、システムエンジニアの仕事の本質であり、この「Claude Code Tray」の開発物語には、そのエッセンスが凝縮されていると言えるだろう。