macOSとCodexを常時見守るMini System Monitor

CPUやメモリの負荷が気になってActivity Monitorを開き、今度はCodexの利用枠を確かめるために別の画面へ移る。確認そのものは数秒で済んでも、作業のたびに視線とウィンドウを切り替えるのは、じわじわと集中を削ります。

そこで作ったのが、Rustとeframe/eguiで実装したmacOS向けの「Mini System Monitor」です。CPU・メモリ・温度といったローカルの状態に加え、Codexの利用状況、Standard／Fastの切り替え、RESETクレジットの管理までを、コンパクトなデスクトップウィンドウへまとめました。

目指したのは、何でも分析できる巨大な監視アプリではありません。必要な数字だけを作業机の情報メモのように視界の端へ置き、詳しく見たいときだけ管理画面を開くことです。本記事では、Mini System Monitorが何を表示できるのか、その値をどのように取得しているのか、自動操作をどこまで慎重に制限しているのかを、実装とREADMEに沿って紹介します。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

“見たい情報だけを常に画面に”から生まれたMini System Monitor

Mini System Monitorの出発点は、とても率直です。

管理人

「常に見たい情報だけ常に画面に出しておきたい！」

この一言が、アプリ全体の判断基準になりました。情報量を増やすことより、作業を止めずに必要な状態へ目を配れることを優先しています。

開発のきっかけは確認のための画面移動を減らすこと

macOSにはActivity Monitorがあり、CPUやメモリを詳しく調べられます。Codexの利用状況にも、それぞれ確認する手段があります。ただし、知りたいのが「今のCPU負荷は高いか」「メモリはどれくらい使っているか」「Codexの5時間枠や週間枠は残っているか」だけなら、詳細画面を開く行為自体が少し大げさです。

Mini System Monitorは、その小さな摩擦を減らすための道具です。プロセス別の負荷、ディスクI/O、ネットワーク通信まで分析する代わりに、日常的に見たい指標へ範囲を絞ります。Activity Monitorを置き換えるというより、Activity Monitorを開く前の状況把握を引き受ける小窓、と考えると役割が伝わりやすいでしょう。

表示を絞ることには、もう一つ利点があります。情報が多すぎないため、数値の変化に気づきやすくなります。ウィンドウを開いて探すのではなく、いつもの作業画面の一部として眺める。この順序の違いが、常時表示ツールの価値です。

システム監視とCodex管理を一つの小窓へまとめる

一般的なシステムモニターと異なるのは、ローカルのCPU・メモリ情報とCodexの利用状況を同じ場所へまとめている点です。開発作業中は、Mac本体の負荷とAIサービスの残量が別々の問題として現れます。しかし利用者から見れば、どちらも「今の作業をこのまま続けられるか」を判断するための状態です。

Mini System Monitorでは、CPU、メモリ、温度、Codexの5時間枠・週間枠などを一つの視界へ収めます。常時眺める情報と、必要なときだけ触る操作を分けながらも、入口は一つです。ブラウザ、設定画面、システム監視ツールを往復する回数を減らせます。

Rustを採用し、GUIにはeframe/eguiを使っています。小さなネイティブアプリとしてローカルで動き、macOSのデスクトップ上に置いて使う構成です。Webサービスとして外へ情報を送るための画面ではなく、自分のMacにある状態を自分の作業環境で確認するツールとして設計しています。

キャラクターは作業中の案内役

この記事のビジュアルでは、銀髪のキャラクターがデスクの前で縦長のサブ画面を指し示します。大きな作業画面の隣に、小さな情報面を置く構図は、Mini System Monitorの使い方そのものです。

ここでキャラクターが示す画面は、実アプリのスクリーンショットや実測値を再現したものではありません。あくまで「作業を続けながら、必要な情報へすぐ目を向けられる」という発想を伝える案内役です。堅い仕様表だけで始めず、どんな場面で役立つツールなのかを直感的に受け取ってもらうための入口にしています。

標準表示とコンパクト表示で、常時表示する情報を絞れる

常駐ウィンドウは、情報が足りなければ役に立たず、大きすぎれば作業の邪魔になります。Mini System Monitorは、標準表示とコンパクト表示、さらに独立したCodex管理ウィンドウを使い分けることで、この相反する要求を整理しています。

常に最前面に置く標準表示

メインウィンドウは、macOS上で常に最前面へ置く設定です。別のアプリで作業していても背後へ隠れにくく、「確認したいときに探さなくてよい」という開発動機を実装で支えています。

標準表示では、システム情報とCodex情報をカードとして確認できます。常時最前面というと圧迫感を心配するかもしれませんが、目的は画面の主役になることではありません。ウィンドウの端に置いた付箋やメーターのように、必要なときだけ視線を移せることが重要です。

ただし、常に最前面であることが全員に最適とは限りません。画面の狭いMacや、アプリを全画面で使うことが多い環境では、表示位置やサイズとの相性があります。だからこそ、次のコンパクト表示と文字サイズ設定が効いてきます。

CPU・メモリ・Codexへ絞るコンパクト表示

コンパクト表示では、CPU・メモリ・Codexの3列へ要点を絞ります。詳しい説明や操作を並べず、いま見たい状態を短い視線移動で読み取るためのモードです。

たとえば、重いビルドや複数の開発ツールを動かしているときは、CPUとメモリの動きを見ながら、Codexの残量にも目を配れます。「Macが重いのか」「利用枠を使い切りそうなのか」を、それぞれ別画面へ移動せずに把握できるのが利点です。

表示モードはモニター画面から切り替えられます。一方、起動時は通常表示へ戻る仕様です。前回のコンパクト状態を永続化するのではなく、まず全体を見せる通常表示から始める設計なので、起動直後に情報が省略されていることへ気づかないまま使う状況を避けられます。

詳細操作だけ独立したCodex管理ウィンドウへ分ける

CodexのサービスティアやRESETクレジットまで常時ウィンドウへ詰め込むと、小ささという長所が失われます。そこで詳細なCodex管理は、メインウィンドウとは別のビューポートとして開く構成です。

この管理ウィンドウはサイズ変更ができ、メインウィンドウに隣接する位置を計算して表示します。こちらも最前面に置けるため、設定を確認しながら作業できます。普段は要約だけを眺め、速度の切り替えやRESETの確認が必要になったときだけ管理画面を開く。情報密度を利用場面に合わせて切り替えることで、常駐性と操作性を両立しています。

大切なのは、機能ごとに別アプリへ分散させたのではなく、「見る」と「操作する」を二つの窓へ分けたことです。入口とデータの文脈は共通のまま、作業を邪魔しない形へ整理しています。

言語・テーマ・10〜32pt文字サイズを保存する

常時表示する道具は、一度だけ開く設定画面よりも、環境へのなじみ方が重要です。Mini System Monitorでは、日本語・英語・システム言語、ライト・ダーク・システムテーマ、10〜32ptの文字サイズを選べます。

言語、テーマ、文字サイズ、RESET自動使用の設定は保存されます。明るい作業環境ではライト、暗い環境ではダーク、OSに合わせたい場合はシステム設定を選べます。高解像度ディスプレイで小さく置く場合も、離れた位置から見る場合も、文字サイズを用途に合わせて調整できます。

ここでも目的は装飾の豊富さではなく、必要な情報を無理なく常時読めることです。常駐ツールでは「表示できるか」だけでなく、「毎日の画面に置き続けられるか」が実用性を左右します。

CPU・メモリ・温度を小さな画面で把握する

システムモニター部分は、CPU使用率、メモリ使用量、温度という、作業中に変化を追いやすい指標へ絞っています。ただし、表示される数字を過信させないことも同じくらい大切です。特にmacOSの温度取得には制約があるため、Mini System Monitorは取得元と取得不能の状態を隠しません。

CPU使用率とメモリの使用量・総容量を同時に見る

CPUは現在の使用率、メモリは使用量と総容量を表示します。重い処理を始めた直後の負荷や、複数のアプリを開いたときのメモリ消費を、小さな画面で同時に確認できます。

これは詳細分析のための全情報ではありません。どのプロセスがCPUを使っているか、メモリ圧縮やスワップがどう変化したかまで追う場合は、Activity Monitorなどの詳細ツールが必要です。Mini System Monitorが担うのは、「いつもと違う」「負荷が高い状態が続いている」と気づくための入口です。

詳細機能を削ることは弱点にも見えますが、常時表示では明確な選択です。数値を確認するたびに一覧を読み解く必要がなく、異変を見つけたときだけ専用ツールへ移れます。視界の端に置く一次メーターと、原因を探す二次ツールを分担させる考え方です。

Apple SiliconのSoC／PMU系温度と検出元を表示する

温度は、Apple SiliconのSoC／PMU系センサーからベストエフォートで取得します。取得経路は一つに固定されておらず、macOSのprivate IOHID経路、sysinfoのコンポーネント情報、利用できる場合のosx-cpu-temp、istats、powermetricsを順に試します。

取得できた場合は温度だけでなく検出元も表示します。同じ「温度」というラベルでも、Macの機種、OS、権限、補助コマンドの有無によって採用される経路が変わり得るからです。数値だけを見せて出どころを曖昧にするのではなく、どの経路で得た値なのかを利用者が判断できるようにしています。

温度取得はCPUやメモリと同じ頻度で毎描画時に呼ばず、5秒間隔で更新します。比較的重い可能性のある経路を常時繰り返さず、画面で変化を追うのに十分な間隔へ抑える設計です。

温度は個別コア値ではなく、取れないときは「–」にする

表示する温度は、個別CPUコアの厳密な温度ではありません。Apple SiliconのSoC／PMU系温度を可能な範囲で取得した値です。したがって、別の温度計測ツールと数字が一致しない場合や、環境によって取得できない場合があります。

有効な値が取れないときは、温度 --またはTemp --と表示します。別センサーの値をCPU温度として扱ったり、もっともらしい数字を推測して埋めたりはしません。常駐画面では空欄や未取得表示が気になるものですが、不確かな値を確定値のように見せるほうが危険です。

この制約は、導入前に知っておきたい重要な境界です。温度の常時取得を主目的にする場合は、自分のMacで利用できる経路を確かめる必要があります。一方、温度が取得できなくてもCPU・メモリの表示まで止まるわけではありません。取れる情報を使い、取れない情報はそのまま示す方針です。

Codexの利用枠・速度・RESETを一つの管理画面にまとめる

Mini System Monitorのもう一つの柱がCodex連携です。ブラウザの表示内容を読み取るのではなく、サインイン済みのローカルCodexを通じて利用状況と設定を扱います。便利な操作を増やす一方で、設定変更やクレジット使用は、読み取り専用の表示よりも慎重な境界を設けています。

5時間枠と週間枠、返された場合だけSpark枠も表示する

アプリはローカルのcodex app-serverを標準入出力経由で起動し、JSON-RPC接続を初期化します。そこからaccount/rateLimits/readとconfig/readを使い、Codexの利用状況と現在の設定を読み取ります。

基本となるのは、5時間枠と週間枠の残量です。さらにrateLimitsByLimitIdへSparkの制限枠が返された場合は、Sparkの5時間枠・週間枠も表示します。RESETクレジットについては、所持数、並び順、説明、最短有効期限を管理画面で確認できます。

ただし、すべてのアカウントで同じ項目や値が表示されるとは限りません。利用枠、Spark、RESETの実際の値と利用可否は、サインイン中のCodexアカウントから返される情報に依存します。Sparkが返されない環境で、通常のCodex枠からSpark残量を推測することもありません。

StandardとFastは書き込み後の実効値まで確認する

Codexのサービスティアは、StandardとFastを表示し、管理画面から切り替えられます。この操作はUI上の選択表示だけを変えるものではありません。

選択した値をconfig/batchWriteで書き込んだあと、設定をもう一度読み込みます。そして、実際に有効になったservice_tierが選択したStandardまたはFastと一致しているかを確認します。書き込み要求を送れたことと、設定が反映されたことを分けて扱うためです。

速度設定は、その後のCodex利用へ影響する状態変更です。だからこそ、「ボタンを押したから変わったはず」で終えず、実効値まで確かめます。小さな常駐ツールの中でも、表示と操作では必要な確実性が異なることを意識した実装です。

RESETクレジットを期限順で把握する

RESETクレジットは、数だけでなく説明や有効期限を含めて確認できます。複数のクレジットがある場合、どれを先に使うべきか判断するには、単純な所持数より期限の情報が重要です。

管理画面ではクレジットの並び順と最短有効期限を把握でき、自動使用の対象を選ぶ際も期限が最も近い1枚を優先します。利用者が意図しないクレジットを無差別に使うのではなく、明確な順序に従わせています。

もちろん、RESETを使うかどうかは残量表示とは性質が違います。確認は何度行っても状態を変えませんが、クレジット使用は取り消せない可能性のある操作です。そのため、自動化は初期状態で有効になっていません。

自動RESETは既定OFFで、全条件を満たす1枚だけを使う

RESETの自動使用は既定でオフです。有効にした場合も、単に「残量が少ない」だけでは実行しません。

対象が10,080分の週間枠であること、残量が0％であること、クレジット一覧を完全に取得できていること、まだ処理していないリセット境界であること。これらの条件をすべて満たした場合に限り、期限が最も近い1枚を選びます。

ここで重要なのは、便利さのために条件を緩めていないことです。残量の取得に失敗した、クレジット一覧が一部しか読めない、同じ境界をすでに処理した可能性がある、といった曖昧な状態では自動使用へ進みません。

一度の自動実行で扱うのは1枚です。さらに処理済みのリセット境界をジャーナルへ記録し、同じ条件を繰り返し検出しても二重に使わない冪等性を持たせています。自動化は「操作を省く機能」である前に、「同じ状態へ何度反応しても結果を増幅させない仕組み」であるべきだと考えた設計です。

止まらず、推測せず、重複実行しないための設計

常時表示するツールでは、一時的な取得失敗は避けられません。重要なのは、失敗をゼロに見せることではなく、失敗したときに誤った判断や過剰な再試行へつなげないことです。Mini System Monitorは、直近正常値の保持、バックオフ、未検出表示、機能分離、冪等性という複数の方法でその境界を守ります。

Codex取得失敗時は最後の正常値を残して更新を遅らせる

Codex情報の取得に失敗した場合、画面上の値を即座に空へ戻すのではなく、最後に正常取得できたlast_goodを保持します。一時的にcodex app-serverが応答しないだけで、利用枠のカード全体が消えて読めなくなることを避けるためです。

ただし、直近正常値は最新値ではありません。表示されるStale状態や最終更新情報と合わせて、「最後に確認できた値」として読む必要があります。古い値を現在値のように無条件で見せる設計ではなく、利用可能な履歴を残しつつ鮮度の違いを伝えます。

通常の更新間隔は60秒です。失敗が続く場合は、回数に応じて間隔を延ばし、最大300秒まで待ちます。応答しない相手へ短い周期で要求を送り続けても、回復が早まるとは限りません。むしろローカル環境へ余計な負荷を加える可能性があります。バックオフによって、情報を待つ姿勢そのものを穏やかにしています。

Spark未検出と温度未取得を別の値で埋めない

欠損をきれいに埋めれば、画面の見栄えは整います。しかし、取得できないものを別の値から推測すると、利用者は実データと推定値を区別できません。

Mini System Monitorは、rateLimitsByLimitIdにSparkが含まれない場合、既存のCodex利用枠から値を作らず「未検出」として扱います。温度も同様に、有効な値がない場合は--です。二つの機能は取得経路が違いますが、「得られた事実と、得られなかった状態を混ぜない」という判断は共通しています。

常時モニターでは、数字が並んでいるだけで信頼できそうに見えます。だからこそ、不明な状態を不明なまま表示することに意味があります。数値を埋めるより、利用者が次の判断を誤らないことを優先しています。

Codex連携が止まってもシステムモニターは動かす

Codexデータを取得できない場合でも、CPU・メモリを中心とするシステムモニター部分は動作します。ローカルCodexの未導入、認証状態、対応メソッドの変更などがあっても、Mac本体の監視まで共倒れにしません。

これは機能の縮退であると同時に、責務の分離です。システム指標はローカルの監視経路から取得し、Codex情報はcodex app-serverから取得します。片方が利用できない状態を、アプリ全体の停止理由へ広げないことで、残った機能をそのまま使えます。

一方で、Codex連携が必要な読者にとっては、システムモニターだけ動けば十分というわけではありません。Staleや未検出が続く場合は、ローカルCodexの状態や互換性を確認する必要があります。フォールバックは問題を隠すものではなく、問題の範囲を限定して表示し続けるためのものです。

冪等性ジャーナルでRESETの二重使用を防ぐ

自動RESETでは、同じリセット境界を何度検出しても、同じ操作を重ねないことが欠かせません。ポーリング型のアプリは一定間隔で状態を読み直すため、条件がしばらく変わらなければ同じ判断へ何度も到達するからです。

Mini System Monitorは、処理済み境界を冪等性ジャーナルへ残します。更新、再取得、一時的な通信失敗が重なっても、すでに扱った境界で再びクレジットを使わないための記録です。

残量0％という条件、完全なクレジット一覧、期限順の1枚選択、未処理境界の確認は、別々の飾りではありません。自動操作の入口から実行後までを一つの安全条件としてつなげています。「自動だから便利」ではなく、「条件を説明でき、重複を抑えられる範囲だけ自動にする」という姿勢です。

動作条件・ビルド方法・導入前に知っておきたいこと

Mini System Monitorは、一般向けストアから配布される完成品ではなく、GitHubでソースを公開している独立した非公式ユーティリティです。試す前に、対応環境、ローカルCodexへの依存、署名の範囲、現在確認できているテスト結果を把握しておくと、導入後の期待を合わせやすくなります。

GitHubでソースを公開している

ソース、README、現在の実装は、次のGitHubリポジトリで確認できます。

mlabo-org/mini-system-monitor-rs（GitHub）

公開リポジトリを案内するのは、単なるダウンロード導線のためだけではありません。温度の取得経路、CodexとのJSON-RPC接続、Standard／Fastの書き込み後確認、自動RESETの条件など、常駐ツールとして気になる部分を導入前に自分で読めます。

現時点で一次ソースから案内できるのは、GitHubのソースを取得して実行またはローカルビルドする方法です。一般向けの公開バイナリ配布URLは確認できていないため、存在するようには案内しません。

macOS 14以降とローカルCodex環境が基本条件

対象はmacOS 14以降です。Rustの固定ツールチェーンとXcode Command Line Toolsを使ってビルドします。CPU・メモリを表示するシステムモニター部分だけでなくCodex情報も利用する場合は、ローカルにCodexがあり、サインイン済みであることが基本条件です。

さらに、利用中のCodexがaccount/rateLimits/readやconfig/readなど、アプリが使うcodex app-serverのメソッドに対応している必要があります。アカウントから返される情報によって、Spark枠やRESETクレジットの表示内容も変わります。

Codexデータが取れなくてもシステムモニターは動くため、最初はCPU・メモリ部分だけ確認することもできます。ただし、Codex管理を主目的にするなら、認証済みセッションと現在のインターフェース互換性を導入条件として考えてください。

cargo runとビルドスクリプトで試す

リポジトリを取得したあと、開発実行は次のコマンドです。

cargo run --locked

--lockedを付けることで、Cargo.lockに固定された依存関係を使います。macOSアプリバンドルを生成する場合は、リポジトリに含まれるビルドスクリプトを使います。

Scripts/build-app.sh --output target/app

このスクリプトは、固定依存を使ったオフラインのreleaseビルドを行い、アプリバンドルを組み立てたあと、アドホック署名とcodesignによる検証まで進めます。手元で単にバイナリを作るだけでなく、macOS上で扱うアプリの形へまとめる経路がソース側に用意されています。

アドホック署名はローカル利用向け

ビルドスクリプトが行うのはアドホック署名です。これは自分のMacでローカル利用するための署名であり、Developer IDを使った公証済みの一般配布を意味しません。

そのため、GitHubからソースを取得して自分でビルドする使い方と、第三者へ完成アプリとして広く配布する使い方は分けて考える必要があります。この記事で保証できるのは、一次ソースに記載されたローカルビルドの範囲です。

温度取得で補助コマンドを使う可能性がある点も含め、読者のMacで選ばれる経路や取得可否は、機種、OS、権限、ローカル環境によって異なります。ビルドできたことと、すべてのセンサーやCodex項目が同じように表示されることも同義ではありません。

非公式連携なのでCodex側変更の影響を受ける

Mini System MonitorはOpenAIとの提携や、OpenAIによる承認を受けた製品ではありません。独立して開発した非公式ユーティリティです。

Codex連携はローカルのcodex app-serverインターフェースへ依存しています。そのため、Codex側でメソッド、応答形式、設定項目が変われば、アプリ側にも更新が必要になる場合があります。ローカル接続だから将来も変化しない、という関係ではありません。

この制約は弱点を隠さず導入判断へ含めるべき部分です。一方で、ソースがGitHubで公開されているため、現在どのメソッドを使い、失敗時にどう振る舞うのかを確認できます。非公式ツールだからこそ、動作の根拠へたどれることが重要です。

一時targetで固定依存テスト28件が通過した

2026年8月6日時点のローカル確認では、既存のtargetを使ってcargo test --lockedを実行した際、epaint、skrifa、wgpu系crateのrlibが見つからず、コンパイルに失敗しました。

この結果だけを見るとソースの不具合に見えますが、既存のCargo fingerprintやtarget内の不整合が影響する場合があります。そこで既存成果物の影響を切り分けるため、一時的なCARGO_TARGET_DIRを使い、固定依存のままcargo test --offline --lockedを実行しました。その結果は28件通過、失敗0件、無視0件です。

これは、あらゆるMacでのGUI表示、温度センサー、すべてのCodexアカウント条件を保証する結果ではありません。固定依存の単体テストが、既存targetの影響を除いた環境で通過したという公開時点の事実です。もし手元の既存targetで依存成果物に関する不可解なビルドエラーが出た場合は、ソース欠陥と即断せず、Cargoの成果物境界も確認する手掛かりになります。

視界の端へ何を置きたいかが導入の判断軸

Mini System Monitorが向いているのは、Activity Monitorの全機能を小さく詰め込みたい人ではありません。CPU・メモリ・温度とCodex残量という、作業中によく見る情報を選び、視界の端へ置きたい人です。必要なときにはCodex管理画面を開き、普段はコンパクトな要約だけを眺める使い方に合います。

反対に、プロセス別負荷、ディスク、ネットワークまで常時分析したい場合は、専用のシステムモニターが適しています。Codexをローカルで使っていない場合も、このツール独自の統合メリットは小さくなります。温度値に個別コア単位の厳密さを求める用途にも向きません。

それでも、「確認のためだけに画面を行き来したくない」という感覚があるなら、試す理由は明確です。Mini System Monitorは、情報を増やすためではなく、常に見たい情報だけをいつもの画面へ残すために作りました。

まずはGitHubの公開リポジトリでREADMEとソースを確認し、自分のMacとCodex環境に合うか見てみてください。便利さだけでなく、未検出、ベストエフォート、非公式連携という境界まで納得できれば、作業机の小さな情報窓として役立つはずです。