Codex Usage Monitor — Codex使用量管理ウィジェット
プロジェクト概要
Codex Usage Monitorは、Codexの使用状況をMac上で分かりやすく確認するために開発した、macOSアプリとウィジェットです。
Codexを継続的に使用していると、「現在どのくらい使用しているのか」「あとどの程度利用できるのか」「使用量がリセットされるまで、どのようなペースで使うべきか」を頻繁に確認する必要があります。
しかし、その都度Codexを開いて使用量画面まで移動する方法では、確認に手間がかかります。
そこで、必要な情報をMacのデスクトップや通知センターから素早く確認できる、シンプルな使用量管理ツールを作成しました。
Inspiration — 何がインスピレーションを与えたのか
このプロジェクトのきっかけは、私自身がCodexを集中的に利用する中で感じた、使用量管理の難しさでした。
Codexは、コードの作成、修正、テスト、調査、ドキュメント作成など、幅広い開発作業を実行できます。一方で、大規模なタスクや複数のエージェントを利用する作業では、使用量を想定以上に消費する場合があります。
特に週間単位で使用量を管理する場合、単に現在の残量を確認するだけでは不十分です。
重要なのは、次のような判断です。
- 現在、使用量全体の何％を消費しているか
- リセットまでに何日残っているか
- 今のペースで使用を続けても問題ないか
- 重い開発タスクを今実行するべきか
- 使用量を節約し、別の作業を優先するべきか
私はCodexを単発のコーディングツールではなく、複数のプロジェクトを継続的に進めるための開発パートナーとして利用しています。
そのため、使用量は単なる数値ではなく、開発リソースを配分するための重要な情報だと考えました。
この課題を解決するために、Codexの使用状況を常に確認できるmacOSウィジェットを作ろうと考えたことが、プロジェクトの出発点です。
What it does — プロジェクトでできること
Codex Usage Monitorは、Codexの使用状況を入力・保存し、その情報をmacOSウィジェットに表示します。
アプリ本体では、使用状況に関する情報を管理します。保存されたデータは、アプリとウィジェットの間で共有されます。
ウィジェットを設置することで、ユーザーはCodexを開かなくても、Mac上から使用状況を確認できます。
このプロジェクトでは、情報をできるだけ短時間で理解できるようにすることを重視しました。
表示の中心となるのは、次の情報です。
- 使用済みの割合
- 残りの使用可能量
- 使用量の更新状況
- 次回リセットまでの目安
- 現在の利用ペースを判断するための情報
使用済み量を (U)、利用可能な上限を (L) とした場合、使用率 (P) は次の式で表せます。
[ P = \frac{U}{L} \times 100 ]
残りの使用率 (R) は、次のように計算できます。
[ R = \max\left(0,\ 1-\frac{U}{L}\right)\times 100 ]
例えば、利用可能な使用量のうち70％を消費している場合、残りの使用率は次のようになります。
[ R = (1-0.7)\times100 = 30% ]
この数値をウィジェット上で視覚的に表示することで、ユーザーは詳細な数字を読み込まなくても、現在の状態を直感的に理解できます。
How I built it — どのようにプロジェクトを構築したのか
このプロジェクトは、macOS向けのネイティブアプリとしてXcodeで構築しました。
主に使用した技術は次のとおりです。
- Swift
- SwiftUI
- WidgetKit
- App Groups
- Xcode
プロジェクトは、大きく2つのターゲットで構成されています。
CodexUsageMonitorCodexUsageMonitorWidgetExtension
CodexUsageMonitorは、使用状況の入力やデータ管理を担当するメインアプリです。
CodexUsageMonitorWidgetExtensionは、保存された情報を取得し、macOSのウィジェットとして表示します。
SwiftUIによる画面構築
アプリのユーザーインターフェースにはSwiftUIを使用しました。
SwiftUIを採用した理由は、状態と画面表示を連動させやすく、入力値の変化を即座にUIへ反映できるためです。
使用量が変更された場合、表示される割合や残量も再計算されます。
このように、データと画面を宣言的に結び付けられる点は、使用量モニターのような小規模なユーティリティアプリに適していました。
WidgetKitによるウィジェット実装
ウィジェットの実装にはWidgetKitを使用しました。
WidgetKitでは、タイムラインを通じてウィジェットの表示内容を更新します。
ウィジェットは通常のアプリのように常時動作するわけではないため、データが更新された際に、適切なタイミングでウィジェットを再読み込みする設計が必要でした。
アプリ側でデータを更新した後、WidgetKitにタイムラインの再読み込みを要求することで、新しい情報をウィジェットへ反映させます。
App Groupsによるデータ共有
メインアプリとウィジェットは、異なる実行領域で動作します。
そのため、通常のアプリ内ストレージだけでは、メインアプリに保存した情報をウィジェットから直接読み取ることができません。
この問題を解決するために、App Groupsを使用しました。
アプリとウィジェットの両方に、次のApp Groupを設定しました。
group.com.kai.codexusage
この共有領域へデータを保存することで、メインアプリとウィジェットの両方から同じ情報へアクセスできます。
データ共有の基本的な流れは次のとおりです。
ユーザーが使用状況を入力
↓
メインアプリが共有領域へ保存
↓
WidgetKitへ更新を要求
↓
ウィジェットが共有領域から最新情報を取得
↓
新しい使用状況を表示
Codexを利用した開発
プロジェクトの設計、コード作成、エラー調査、構成確認にはCodexを活用しました。
私は実現したい機能や画面の目的をCodexへ伝え、CodexがSwiftUIやWidgetKitのコードを作成しました。
その後、Xcode上でビルドと動作確認を行い、発生したエラーを再びCodexへ渡して修正を進めました。
開発は、次のサイクルを繰り返して進めました。
要件を整理する
↓
Codexへ実装を依頼する
↓
生成されたコードをXcodeで確認する
↓
ビルド・型チェックを実行する
↓
エラーや不足点をCodexへ共有する
↓
修正と再検証を行う
Codexにすべてを一度に任せるのではなく、機能単位で実装と検証を繰り返すことで、問題の発生箇所を特定しやすくしました。
Challenges — どのような課題に直面したのか
1. アプリとウィジェットのデータ共有
最初の大きな課題は、メインアプリで保存した情報がウィジェットに反映されないことでした。
原因は、アプリとウィジェットがそれぞれ異なる保存領域を使用していたことです。
単純なUserDefaultsを使用した場合、それぞれのターゲットが別々のデータを参照する可能性があります。
この問題は、App Groupsを設定し、アプリとウィジェットが同じ共有コンテナを参照するように変更することで解決しました。
この経験から、ウィジェット開発ではUIの実装だけでなく、アプリ本体と拡張機能のデータ境界を理解することが重要だと学びました。
2. コードが正しくてもアプリを実行できない問題
Swiftコードの型チェックやプロジェクトファイルの構文に問題がなくても、アプリを実機環境で実行できない問題が発生しました。
確認したところ、開発環境には有効な署名IDとプロビジョニングプロファイルが存在していませんでした。
具体的には、次の状態でした。
0 valid identities found
0 provisioning profiles
これはコードの不具合ではなく、Apple Developerの署名設定に関する問題でした。
解決するために、XcodeへApple IDを追加し、メインアプリとウィジェットの両方で次の設定を行いました。
- 同じDevelopment Teamを選択する
Automatically manage signingを有効にする- 両方のターゲットでApp Groupsを有効にする
group.com.kai.codexusageを選択する
この課題から、macOSアプリ開発では、コードの正しさとアプリを実行・配布できる状態は別の問題であることを学びました。
3. ウィジェットの更新タイミング
通常のアプリでは、データが変更された直後に画面を更新できます。
しかし、WidgetKitのウィジェットはOSによって更新タイミングが管理されるため、常にリアルタイムで更新できるわけではありません。
そのため、データ保存後にタイムラインの更新を要求しながらも、ウィジェットが常時動作するアプリではないことを前提に設計する必要がありました。
この制約を理解したことで、「頻繁に更新すること」よりも「ユーザーが必要な情報を一目で確認できること」を優先するようになりました。
4. 使用量データをどのように取得するか
もう一つの課題は、Codexの使用量情報を安全かつ安定して取得する方法です。
MVPでは、非公開の内部APIや不安定な画面解析に依存するのではなく、ユーザーが確認した使用状況をアプリへ反映し、ウィジェットで管理する方式を採用しました。
完全自動化だけを優先すると、サービス側の画面変更や認証方式の変更によって、アプリが突然動作しなくなる可能性があります。
そのため、最初のバージョンでは、確実に動作するデータ保存・計算・表示の仕組みを完成させることを優先しました。
これは機能上の妥協ではなく、MVPとして信頼性を確保するための判断でした。
What I learned — そこから何を学んだのか
AIが生成したコードにも検証が必要
Codexは、SwiftUIやWidgetKitのコードを短時間で作成できます。
しかし、生成されたコードが構文上正しくても、署名設定、Entitlements、App Groups、ターゲット設定など、Xcodeプロジェクト全体の構成が正しくなければアプリは動きません。
AIによる開発では、コードを生成する能力だけでなく、次の能力が重要だと学びました。
- 要件を明確に伝えること
- 生成されたコードを検証すること
- エラーをコードと環境設定に分けて考えること
- 小さな単位で実装とテストを繰り返すこと
- AIが変更した内容を人間が理解すること
シンプルなツールほど情報設計が重要
使用量管理ウィジェットは、大規模なアプリではありません。
しかし、表示する情報が多すぎると、ユーザーは現在の状態を瞬時に判断できません。
逆に情報を減らしすぎると、使用ペースを判断する材料が不足します。
そのため、単に数値を並べるのではなく、「今どのような状態なのか」が一目で分かる情報設計が重要でした。
Codexは実装者だけでなく、問題解決のパートナーになる
このプロジェクトを通じて、Codexはコードを書くためだけのツールではなく、問題を分解し、原因を調査し、解決策を検討するためのパートナーとして活用できると学びました。
人間が目的、制約、期待する結果を定義し、Codexが実装と技術的な調査を支援することで、個人でもネイティブアプリの開発を進められました。
Future plans — 今後の展望
今後は、Codex Usage Monitorを単なる残量表示ツールから、使用計画を支援するツールへ発展させたいと考えています。
例えば、経過日数を (d)、現在までの使用量を (U) とした場合、1日当たりの平均使用量 (A) は次の式で求められます。
[ A = \frac{U}{d} ]
リセットまでの残り日数を (n)、残り使用可能量を (L-U) とすると、1日に使用できる推奨量 (B) は次のように表せます。
[ B = \frac{L-U}{n} ]
この2つを比較することで、現在の利用ペースを評価できます。
[ S = \frac{A}{B} ]
- (S < 1)：現在のペースを継続できる
- (S \approx 1)：推奨ペースとほぼ同じ
- (S > 1)：リセット前に使用量を使い切る可能性がある
将来的には、次のような機能を検討しています。
- 使用履歴の記録
- 日別・週別の利用傾向の表示
- 現在の利用ペースの分析
- 使用量が一定値を超えた場合の警告
- リセット日までの推奨使用量の計算
- 複数のAI開発ツールの使用状況管理
Conclusion — まとめ
Codex Usage Monitorは、私自身がCodexを日常的に利用する中で感じた、現実的な課題から生まれたプロジェクトです。
このプロジェクトを通じて、SwiftUIやWidgetKitによるmacOS開発だけでなく、App Groupsによるデータ共有、コード署名、プロビジョニング、ウィジェットのライフサイクルについて学びました。
また、Codexを利用した開発では、AIへ実装を依頼するだけではなく、人間が目的を定義し、結果を検証し、問題を切り分けることが不可欠であると実感しました。
最終的にこのプロジェクトは、Codexの使用量を表示するウィジェットであると同時に、Codexを使って、Codexをより効果的に使うためのツールを構築するという自己完結型のプロジェクトになりました。
Log in or sign up for Devpost to join the conversation.