Codex on KnightLiブログ

Scientific Agent Skills：研究ワークフローを AI Agent に渡すためのスキルライブラリ

Sun, 17 May 2026 17:52:04 +0800

K-Dense-AI/scientific-agent-skills は、科学研究や調査作業向けの Agent Skills 集です。

目的は、また別のチャットボットを作ることではありません。研究でよく発生する、ドキュメント調査、データベース接続、分析スクリプト作成、ファイル処理、図表生成、レポート作成といった流れを、AI Agent が発見して呼び出せるスキルに分解することです。

プロジェクト：https://github.com/K-Dense-AI/scientific-agent-skills

2026-05-17 時点で、GitHub API では約 23.4k stars、2.5k forks、MIT ライセンス、最終 push は 2026-05-11 と表示されます。README では 135 個の ready-to-use scientific and research skills とされていますが、scientific-skills ディレクトリは GitHub API で 137 項目確認できます。この差は集計方法、最近追加されたディレクトリ、README の更新遅れによる可能性があります。

まず結論

Scientific Agent Skills は、Codex、Claude Code、Cursor、Gemini CLI、または Agent Skills 標準をサポートするツールをすでに使っている人に向いています。

価値は主に三つです。

科学ツールチェーンの使い方を SKILL.md に書き、agent が毎回ライブラリの使い方を推測しなくてよくする。
科学データベース、Python パッケージ、ドキュメント処理、科学執筆、可視化のワークフローを一つのスキル集に整理する。
AI Agent を、概念を答えるだけでなく、研究ワークフローを実行できる助手に近づける。

ただし、インストールすれば自動的に研究が完了する魔法のボタンではありません。スキルは agent が正しい道具を選び、より信頼できるコードや手順を生成する助けになりますが、データ品質、実験設計、統計仮定、臨床・研究上の結論は人間が判断する必要があります。

何が含まれるか

README は、このプロジェクトを研究、科学計算、工学、分析、金融、執筆タスクをカバーするスキル集として説明しています。主な領域は次の通りです。

バイオインフォマティクスとゲノミクス
ケモインフォマティクスと創薬
プロテオミクスと質量分析
臨床研究と精密医療
医療 AI と臨床機械学習
医用画像とデジタル病理
機械学習と AI
材料科学と化学
物理と天文学
工学シミュレーションと最適化
データ分析と可視化
地理空間科学とリモートセンシング
実験室自動化
科学執筆、文献レビュー、査読、引用管理

これらのスキルは、agent が使えるライブラリを制限するためのものではありません。README でも、agent は Python を書いたり、利用可能な API やパッケージを呼び出したりできると説明されています。スキルの役割は、整理済みの説明、例、ベストプラクティス、統合手順をあらかじめ提供することです。

言い換えると、「科学ツールの説明書 + ワークフローテンプレート + agent 呼び出し規約」の集合に近いものです。

データベースと Python パッケージ

研究者にとって最も魅力的なのは、科学データベースと Python エコシステムのカバー範囲です。

README では次が示されています。

database-lookup による 78 個の公開データベースへの統一アクセス。
PubChem、ChEMBL、UniProt、COSMIC、ClinicalTrials.gov、FRED、USPTO など。
DepMap、Imaging Data Commons、PrimeKG、U.S. Treasury Fiscal Data、Hugging Science などの専用データアクセススキル。
70 個以上の最適化済み Python Package Skills。

ディレクトリには、なじみのある名前が多くあります。

rdkit
scanpy
biopython
bioservices
pydeseq2
scvelo
scvi-tools
pymatgen
qiskit
pennylane
openmm
mdanalysis
scikit-learn
statsmodels
matplotlib
seaborn
networkx
sympy
pytorch-lightning
transformers
timesfm-forecasting

これらのライブラリ自体は珍しくありません。重要なのは、agent が作業中に、そのライブラリ固有の制約、コード例、よくある流れ、注意点を読めることです。モデルの古い記憶だけに頼るより安定します。

典型的な場面

Scientific Agent Skills は、単発の質問応答より、多段階の研究タスクに向いています。

創薬なら、agent に ChEMBL から EGFR 阻害剤を探させ、RDKit で構造活性相関を分析し、DiffDock で仮想スクリーニングを行い、文献検索とレポート作成までつなげられます。

シングルセル解析なら、10X データを Scanpy に読み込み、QC、統合、細胞型同定、差次的発現、経路エンリッチメントを実行できます。

マルチオミクスなら、RNA-seq、質量分析、代謝物、タンパク質相互作用、臨床試験、統計モデリングをつなげられます。

これらを普通の prompt だけで行うと、agent は方向性を知っていても各ステップで人間の補助が必要になりがちです。スキルライブラリの意味は、こうした頻出経路を保存し、agent が回り道を減らせるようにすることです。

インストール方法

README が推奨する標準方式は Agent Skills ツールです。

`1`	`npx skills add K-Dense-AI/scientific-agent-skills`

GitHub CLI v2.90.0+ を使う場合は gh skill でもインストールできます。

`1`	`gh skill install K-Dense-AI/scientific-agent-skills`

特定のスキルを入れる場合：

`1`	`gh skill install K-Dense-AI/scientific-agent-skills scanpy`

対象 agent を指定する場合：

gh skill install K-Dense-AI/scientific-agent-skills --agent codex
gh skill install K-Dense-AI/scientific-agent-skills --agent cursor
gh skill install K-Dense-AI/scientific-agent-skills --agent claude-code
gh skill install K-Dense-AI/scientific-agent-skills --agent gemini

再現性を保つには release tag または commit SHA に pin できます。

1
2

gh skill install K-Dense-AI/scientific-agent-skills --pin v1.0.0
gh skill install K-Dense-AI/scientific-agent-skills --pin abc123def

これは研究環境では重要です。「先週は動いたが、今週は結果が変わり、理由がわからない」という状況は避けたいものです。分析にスキルが関与するなら、スキル、依存関係、データのバージョンを一緒に記録すべきです。

実行環境

README の基本要件は次の通りです。

Python 3.11+、3.12+ 推奨。
Python 依存関係のインストールに uv。
Agent Skills 標準をサポートするクライアント。
macOS、Linux、または Windows with WSL2。

Windows ユーザーは WSL2 の記述に注意すべきです。科学計算ライブラリはネイティブ Windows でも動くことがありますが、依存関係、コンパイラ、バイナリパッケージ、パスの問題が起きやすくなります。README が Windows with WSL2 としていることは、Unix 系の研究計算環境を想定していることを示しています。

普通の prompt 集との違い

普通の prompt 集は、モデルに「どう答えるか」を伝えるものです。Scientific Agent Skills はさらに、ツール、ライブラリ、データベース、ワークフローを agent が発見できるスキルとして記述します。

実際の違いは次の通りです。

スキルには構造化された説明とコード例を含められる。
特定のライブラリやデータベースを中心に長期保守できる。
agent はタスクに応じて関連スキルを選べる。
チームは必要なスキルだけを入れ、コンテキストノイズを減らせる。
スキルはリポジトリとともに versioning、review、update できる。

複雑な研究作業では、巨大な万能 prompt をコピーするより、この方が保守しやすくなります。モデル、データベース、Python パッケージは変わります。その変化をスキルにまとめる方が制御しやすいです。

セキュリティと信頼境界

README のセキュリティ警告ははっきりしています。Skills はコードを実行でき、coding agent の挙動に影響します。

研究スキルは、Python 依存関係をインストールし、ネットワークデータベースへアクセスし、ローカルファイルを読み書きし、分析スクリプトを実行し、機密性の高い実験データや臨床データを処理し、後で引用される可能性のあるレポートを生成するかもしれません。

したがって、すべてを無条件にインストールするべきではありません。より安全な方法は次の通りです。

現在のタスクに必要なスキルだけを入れる。
インストール前に対応する SKILL.md を読む。
呼び出すパッケージ、API、ファイル、外部サービスを確認する。
コミュニティ提供のスキルには特に慎重になる。
データ処理やコード実行は隔離環境で行う。
研究結論、臨床提案、統計結果は人間がレビューする。

README では Cisco AI Defense Skill Scanner も触れられており、第三者スキルのローカルスキャンも推奨されています。スキャンは人間のレビューを置き換えませんが、スキルのサプライチェーンリスクを意識していることはわかります。

向いている人

このプロジェクトは次の人に向いています。

日常的に AI coding agent を使っている。
科学データ、論文、図表、レポートをよく扱う。
Python の科学計算エコシステムを頻繁に行き来する。
agent に多段階分析を実行させたい。
チームの研究ワークフローを再利用可能なスキルにしたい。
Agent Skills 標準が専門分野へどう適用されるかを調べたい。

逆に、たまに論文を説明してもらうだけ、ローカル Python 環境がない、依存関係を扱いたくない、データプライバシーやネットワークアクセスやコード実行の境界が未整備、厳格な臨床・本番意思決定システムなのに人間のレビューがない、といった場合には向きません。

一度きりの分析なら agent にスクリプトを書かせるだけで軽いかもしれません。似た研究フローを繰り返すなら、スキルライブラリの価値は大きくなります。

使い方のすすめ

最初からリポジトリ全体を入れて、すべてのタスクを agent に渡すべきではありません。

現実的な流れは次の通りです。

文献整理、図表生成、公開データ探索など低リスクなタスクを選ぶ。
literature-review、scientific-writing、scanpy、rdkit など関連スキルだけを入れる。
agent にまず計画を説明させてからコードを実行させる。
入力データ、スクリプト、環境、スキルバージョンを残す。
出力結果を人間が確認する。
フローが安定したら、チームの SOP や独自スキルに書き込む。

研究 agent の核心は、すべてを自動化することではありません。繰り返しが多く、面倒で、ドキュメント確認が必要な部分をツールに任せ、判断、仮定、結論を人間に残すことです。

まとめ

Scientific Agent Skills の意味は、Agent Skills を一般的なプログラミングから研究の現場へ広げることにあります。

研究作業は本質的に、多ツール、多データベース、多ファイル、多段階の流れです。チャット型 prompt だけでは、こうした細部を安定して扱うのは難しいです。このプロジェクトは、よく使われる科学ライブラリ、データソース、研究フローをスキルとして整理し、AI Agent が実際の研究ワークフローに入りやすくします。

ただし、強力であるほど境界も必要です。スキルは agent の挙動に影響し、コードを実行し、ネットワークへアクセスし、ファイルを処理することがあります。インストール前に内容を読み、実行環境を隔離し、研究結論では人間の検証を省かないことが重要です。

Codex、Claude Code、Cursor、Gemini CLI を研究やデータ分析に使っているなら、Scientific Agent Skills は一度見る価値があります。全面的に導入しなくても、スキルの分割方法はチームの研究 AI ワークフローを整理する参考になります。

参考リンク：

Codex が ChatGPT モバイルからのリモートアクセスに対応、Enterprise ワークスペースで Access Tokens が利用可能に

Sun, 17 May 2026 09:12:07 +0800

OpenAI は 2026 年 5 月 14 日、ChatGPT Enterprise & Edu Release Notes を更新し、Codex に関する 2 つの変更を発表しました。Codex が ChatGPT モバイルアプリからのリモートアクセスに対応し、Enterprise ワークスペースで Codex access tokens を使った制御された自動化が可能になりました。

これはモデル能力の発表ではありません。Codex という製品の形が変わりつつあるという話です。Codex は、ローカル環境や Web セッション内の coding assistant から、長時間実行でき、遠隔から管理でき、企業の自動化ワークフローに接続できる coding agent へ近づいています。

今回の更新内容

OpenAI Help Center によると、Codex は ChatGPT mobile app からのリモートアクセスに対応しました。ユーザーはスマートフォンから実行中の Codex 環境に接続し、長時間タスクを追跡し、必要なタイミングで介入できます。

同時に、ChatGPT Enterprise ワークスペースでは Codex access tokens が利用可能になりました。これは信頼された非対話型のローカルワークフロー向けで、毎回ブラウザでログインしなくても、ChatGPT workspace identity と企業側の制御を使って自動化を実行できます。

今回の更新は、次の 2 つの入口として理解できます。

モバイルリモートアクセス：Codex が長時間タスクを実行しているとき、ユーザーが PC の前にいない問題を解決する。
Access Tokens：企業の自動化スクリプトが制御された ID で Codex ワークフローを使えるようにする。

モバイルリモートアクセスが解決する問題

Codex のタスクは、いつも数秒で終わるわけではありません。実際の開発では、リポジトリを読み、複数ファイルを変更し、テストを実行し、コマンド出力を待ち、エラーに応じて修正を続け、途中でユーザーの承認を求めることがあります。

これまでは、こうしたタスクではユーザーがローカル Mac、デスクトップアプリ、CLI、IDE の近くにいる必要がありました。今後は ChatGPT モバイルアプリがリモートコンソールになり、PC から離れていても Codex を追跡できます。

OpenAI は、モバイル側で基盤環境のリアルタイム状態を確認できると説明しています。対象には次が含まれます。

プロジェクトコンテキスト。
approvals。
screenshots。
terminal output。
diffs。
test results。

ユーザーはスマートフォンから Codex の質問に答え、実行をリダイレクトし、操作を承認し、出力を確認し、複数の connected hosts を切り替えられます。基盤タスクは Mac host や接続されたリモート環境で動き続け、スマートフォンは確認と制御のために使われます。

開発者にとっての価値

この機能は、長時間実行され、途中確認が必要な開発タスクに特に向いています。

たとえば：

Codex が時間のかかるテストを実行していて、外出中に結果を確認したい。
Codex が複数ファイルを変更し、スマートフォンで diff を見てから次のステップを承認したい。
Codex が危険な操作の前で確認待ちになっており、遠隔で処理したい。
ローカル Mac に複数の connected hosts があり、スマートフォンで状態を切り替えて見たい。

価値はスマートフォンでコードを書くことではありません。ずっと PC の前にいる必要がなくなることです。Codex は元の環境で作業を続け、ユーザーは重要な節目だけ介入します。

これは Codex が「バックグラウンド Agent」に近づいていることも示しています。タスクは継続実行でき、ユーザーが常時オンラインでなくてもよい一方、承認と制御は人間側に残ります。

Access Tokens が解決する問題

Codex access tokens は ChatGPT Enterprise ワークスペース向けです。重点は個人ユーザーの通常ログインではなく、企業内の信頼された自動化です。

企業には、非対話的に実行したいローカルまたは内部ワークフローがよくあります。

定期的なコードチェック。
管理されたマシン上での Codex ワークフロー起動。
Codex と社内開発ツールチェーンの接続。
ブラウザを開かずにワークスペース ID を使うこと。

Access tokens により、これらのワークフローは ChatGPT workspace identity を持って実行され、同時に企業ポリシーの制御を受けます。一時的な手動ログインより自動化に向いており、個人資格情報の共有よりガバナンスに載せやすい仕組みです。

普通の API key ではない

この点は重要です。Codex access tokens は、単なる万能 API key と理解すべきではありません。

OpenAI の説明では、access tokens は ChatGPT Enterprise ワークスペースで利用でき、管理者はワークスペースレベルの可用性を管理でき、許可されたロールを持つメンバーは自分の tokens を作成できます。利用可能な場合、ガバナンス画面にも access token の活動が反映されます。

つまり、access tokens は企業の権限、ロール、監査フレームワーク内に置かれています。

管理者がワークスペースで有効にするかを決められる。
すべてのメンバーが当然作成できるわけではない。
token の活動はガバナンスビューに入る可能性がある。
ChatGPT workspace identity と企業側の制御を継承する。

個人が長期秘密鍵を気軽に作成するのとは違います。

安全な初期設定：Remote Control はデフォルトでオフ

Codex mobile remote access は、コード環境、ターミナル出力、diff、テスト結果、操作承認に関わります。デフォルトで有効なら、企業にとって明確なセキュリティリスクになります。

そのため OpenAI の初期設定は保守的です。remote control はデフォルトでオフで、管理者または owner が Workspace settings で有効にする必要があります。

モバイルリモートアクセスの有効化には、次の要素が関係する場合があります。

workspace-enabled Remote Control access。
SSO。
多要素認証。
passkey。

これは、アプリを更新したら全員が自動的に使える機能ではなく、企業の IT とセキュリティチームが設定すべき機能です。

利用前に必要な更新

OpenAI は、モバイルリモートアクセスを使うには両側の更新が必要だと説明しています。

ChatGPT mobile app。
macOS 上の Codex app。

ワークスペース側の要件によっては、セットアップ時に SSO、多要素認証、passkey フローが発生することもあります。

実際に導入する場合、企業管理者はまず Workspace settings の remote control 設定と、どのメンバーまたはロールに利用を許可するかを確認する必要があります。

企業での Codex 利用への影響

今回の更新は、Codex を 2 つの方向へ進めます。

第一に、Codex は長時間タスクに向きます。以前は長時間タスクではユーザーがずっと見ている必要がありましたが、今後はスマートフォンで状態を確認し、操作を承認できるため、Codex をバックグラウンドで動かしやすくなります。

第二に、Codex は企業自動化に向きます。Access tokens により、非対話型ワークフローに正式な ID 経路ができ、内部 CI、コードレビュー、スクリプト、開発プラットフォームとの接続がしやすくなります。

この 2 つを合わせると、Codex は単なる開発者の手元の AI 助手ではなく、企業の開発フローに組み込まれる管理可能な agent へ近づいています。

注意すべき境界

今回の更新は便利ですが、Codex を完全に無人で任せてよいという意味ではありません。

企業利用では、引き続き次の点に注意が必要です。

どのプロジェクトでリモート制御を許可するか。
どのコマンドに承認が必要か。
token をどう作成、ローテーション、失効するか。
mobile remote access が社内のデバイス管理ポリシーに合うか。
ターミナル出力、スクリーンショット、diff に機密情報が含まれないか。
監査ログとガバナンス画面が社内コンプライアンス要件を満たすか。

特に access tokens は、自動化フローに入った時点で他の企業資格情報と同じように扱うべきです。最小権限、定期的なローテーション、ハードコード回避、不要 token の速やかな失効が必要です。

まとめ

今回の OpenAI Codex 更新は焦点が明確です。ChatGPT モバイルから Codex の長時間タスクにリモートアクセスでき、Enterprise ワークスペースでは Codex access tokens による制御された自動化が可能になりました。

前者は、開発者がずっと PC の前にいる必要を減らします。後者は、企業が Codex をより正式に社内ワークフローへ接続できるようにします。両者を合わせると、Codex は対話型 coding assistant から、遠隔管理、監査、自動化接続に向いた企業向け coding agent へ進んでいることが分かります。

参考リンク：

OpenAI Help Center：ChatGPT Enterprise & Edu - Release Notes

Codex の利用上限はなぜ突然リセットされるのか？Usage Limits の履歴と情報源

Sun, 17 May 2026 08:36:15 +0800

Codex を使っていると、自分の通常の reset 時刻が来ていないのに、usage limits が突然回復していることがあります。このような「予告なしのリセット」は今回が初めてではなく、上限ルールが恒久的に緩くなったことを意味するとは限りません。障害補償、製品プロモーション、成長マイルストーン、あるいは特定のウィンドウやアカウント状態だけを対象にしたバックエンド側のリセットである可能性があります。

このスクリーンショットは、OpenAI Codex チームを率いる Tibo Sottiaux（@thsottiaux）が X に投稿した告知です。利用上限を気にしているユーザーにとって重要なのはモデルの細部ではなく、彼がその夜に usage limits を reset すると述べている点です。文脈を見ると、これは通常の周期的な更新ではなく、補償としてのリセットだと考えられます。

まず結論

Codex の利用上限が突然リセットされる理由は、おおまかに次のように分けられます。

障害補償：モデルや Codex サービスの問題でユーザーの上限が無駄に消費され、OpenAI が補償としてリセットする。
リリースやプロモーション：新モデル、新クライアント、新機能の公開時に、一時的な増量やリセットが行われる。
成長マイルストーン：Codex のユーザー規模が一定の節目に達したとき、利用継続を促すために上限をリセットまたは拡大する。
バックエンド方針の調整：一部の上限ウィンドウやアカウント状態だけがリセットされ、UI では範囲が明確に説明されない。

よくある誤解は、「リセット」と聞くとすべての上限ウィンドウが回復したと考えてしまうことです。実際には、Codex には短時間ウィンドウ、weekly limit、モデルごとの消費重み、プランごとの制限が同時に存在する場合があります。特別なリセットは、その一部だけに効くことがあります。

このスクリーンショットが示していること

スクリーンショットでは、Tibo が 2026 年 5 月 15 日に更新を投稿し、チームが監視を続け、その夜に usage limits をリセットすると述べています。前の投稿では一部ユーザーからの報告を調査中だと説明していたため、このリセットはサービスの揺らぎに対する補償と見るのが自然です。

ユーザー向けには、次の 3 点が重要です。

これは各ユーザーの通常周期による回復ではなく、チーム側の能動的なリセットです。
このリセットには明確な出来事の背景があり、恒久的な上限引き上げではありません。
「usage limits」という表現だけでは、5 時間ウィンドウや weekly limit がすべて含まれるかは分かりません。

そのため、上限が回復していても、まずは特別な reset event として捉えるべきです。

なぜ Codex のリセットは予告なしに見えるのか

Codex の上限は、単純に「毎日何時に更新される」ものではありません。UI には残り上限やパーセンテージだけが表示されることが多い一方、バックエンドでは次のような要素を同時に追跡している可能性があります。

数時間単位の短時間ウィンドウ。
週単位またはそれ以上の上限。
モデルごとの消費重み。
ローカル Codex、Cloud Task、IDE/CLI などの入口の違い。
Plus、Pro、Business、Team などのプラン差。
特別リセットの対象となるアカウント状態かどうか。

OpenAI が特別リセットを行っても、ユーザーはそれが通常周期による回復なのか、補償なのかを UI だけでは判断できない場合があります。短時間ウィンドウだけが回復した場合でも、weekly も回復するはずだと誤解されやすく、weekly が変わらないと「リセットが失敗した」と見えることがあります。

OpenAI の Codex GitHub issue でも、この透明性の問題が指摘されています。公開メッセージでは Codex rate limits が reset されたと説明されても、製品 UI はどのウィンドウがリセットされたのか、weekly limit が含まれるのか、すべての有料プランに同じように適用されたのかを明確に示していませんでした。

これまでの主なリセットの型

1. 2026 年 2 月：リリース期と一時的な増量

Codex デスクトップアプリと GPT-5.3-Codex のプロモーション時期には、usage limit reset と一時的な 2x rate limits がコミュニティで話題になりました。Reddit では、Codex app の公開時に期間限定の 2x rate limits と usage limit reset があったという投稿が見られます。

この種のリセットは、新しいクライアント、モデル、ワークフローを試してもらうためのリリース期の施策と考えられます。

2. 2026 年 3 月：ランダムなリセットと異常消費の議論

3 月前後には、コミュニティで「random usage reset」や「weekly limit reset daily」といった話題が何度も出ました。weekly limit が予定より早く回復したという報告や、新しい Codex モデル、安全ブロック、異常な上限消費、バグ修正と関係しているのではないかという見方がありました。

これらは公式発表ではありませんが、ユーザー側では通常スケジュール以外の回復が複数回観測されていたことを示しています。

3. 2026 年 4 月：成長マイルストーンと有料プランのリセット

4 月下旬には、Codex が週間アクティブユーザー 300 万人に達し、OpenAI が rate limits をリセットしたという報道がありました。今後の成長マイルストーンでも、ユーザーにより多くの利用余地を与える計画だとされています。

GitHub issue でも、Tibo が 4 月 28 日に X で「good week」を祝って有料プランの Codex rate limits をリセットし、GPT-5.5 でより多く構築できるようにしたという投稿が引用されています。ただし同じ issue では、どの上限ウィンドウが実際にリセットされたのか、weekly limit が含まれたのかを UI が明確に示していないとも指摘されています。

つまり、成長やイベントに伴うリセットでも、説明の曖昧さがユーザーの混乱につながりやすいということです。

4. 2026 年 5 月：障害補償型のリセット

今回のスクリーンショットは、より分かりやすい障害補償型のリセットです。Tibo はチームが問題を見つけ、その夜に usage limits をリセットすると述べています。OpenAI Status でも、2026 年 5 月 13 日に Codex 関連のエラー率上昇と遅延悪化が記録されています。

普通のユーザーにとって重要なのは、どのモデルの細部が原因だったかではありません。サービス側の問題で上限が異常に消費された場合、OpenAI が特別リセットで補償することがある、という点です。

リセットの理由をどう判断するか

Codex の上限が突然回復した場合は、次の順番で確認するとよいです。

自分の通常 reset 時刻に達していないか確認する。
OpenAI Status で Codex、モデルエラー、遅延、性能低下の記録を見る。
Tibo、OpenAI 公式アカウント、Codex GitHub issue に説明があるか確認する。
コミュニティで「突然 reset」「異常な消費」「weekly が戻らない」といった報告が集中していないか見る。
短時間ウィンドウと weekly limit を分けて考え、必ず同時に回復するとは決めつけない。

公式の事故補償であれば、状態ページ、責任者の告知、または多数のユーザー報告がセットで見つかることが多いです。一方、バックエンド側の部分的な更新だけなら、明確な告知がない場合もあります。

情報源の信頼性を分けて見る

この種の情報は、層を分けて見るのが安全です。

公式ステータスページ：障害、エラー率、遅延、復旧時刻の確認に最も向いています。
Tibo / OpenAI 公式アカウント：特別リセット、補償、プロモーションの説明を確認するのに向いています。
OpenAI Codex GitHub issue：UI、上限ウィンドウ、実際の挙動に関するユーザー報告を見るのに向いています。
Reddit / X の議論：同じ現象が広く起きているかを見るのに有用ですが、公式確認ではありません。
第三者ニュースやブログ：時系列の補足には便利ですが、公式情報や原典で確認する必要があります。

記事を書くときや判断するときは、これらを分けて扱うべきです。「OpenAI Status に障害が記録された」は公式の状態情報です。「Reddit でランダムリセットが報告された」はコミュニティ観測です。「GitHub issue で UI の不透明さが指摘された」はユーザー提出の製品課題です。

まとめ

Codex の利用上限が突然リセットされるのは、単に「無料の追加枠が来た」という話ではありません。障害補償、リリース期のプロモーション、成長施策、バックエンド方針の変更など、複数の理由があり得ます。分かりにくいのは、Codex に複数の上限ウィンドウがあり、特別リセットがすべてを対象にするとは限らない点です。UI が reset scope を明確に示さないこともあります。

このような状況に遭遇したら、まずクライアント上の実際の上限を確認し、OpenAI Status、Tibo の投稿、Codex GitHub issue、コミュニティ報告を照らし合わせるのが最も安全です。1 回の reset だけで長期的なルール変更だと判断せず、weekly limit、短時間ウィンドウ、すべてのプランが同時に回復すると決めつけない方がよいです。

参考リンク：

Codexのモバイルリモートアクセス：ChatGPT AppでMac上の開発タスクを追跡する

Sat, 16 May 2026 17:42:40 +0800

OpenAIは2026年5月中旬、Codex remote accessをChatGPTモバイルアプリに追加しました。これはスマートフォンでコードを書く機能ではなく、Mac上で動くCodexをスマートフォンから追跡・操作するための機能です。

Codexは引き続きMac上でプロジェクトを読み、コマンドを実行し、ファイルを編集し、テスト結果を確認します。スマートフォン側は進捗確認、質問への回答、追加指示、操作承認を担当します。

できること

OpenAIのCodex remote connectionsドキュメントによると、モバイルアクセスでは次のことができます。

ホスト上のプロジェクトで新しいthreadを開始、または既存threadを継続
追加指示の送信、質問への回答、作業方向の調整
コマンドやその他の操作の承認
出力、diff、テスト結果、端末出力、スクリーンショットの確認
Codexの完了や注意が必要なタイミングで通知を受信
接続済みホストとthreadの切り替え

単なる小さなチャット画面ではなく、Codexの作業コンテキストに接続するモバイル操作面です。

必要条件

同じChatGPTアカウントとworkspaceでCodexを使える必要があります。スマートフォンには最新版のChatGPT Appが必要で、iOSとAndroidに対応します。

ホストは現時点ではMacです。Macは起動中、オンライン、Codex App実行中で、同じアカウントとworkspaceにログインしている必要があります。モバイル設定とデバイス制御には現在Codex App for macOSが必要で、Codex CLIやIDE Extensionからは設定できません。

MFA、SSO、passkeyが必要なアカウントでは、セットアップ中にその認証を完了する必要があります。ChatGPT workspaceでは、管理者がRemote Control accessを有効にする必要がある場合もあります。

制限

第一に、現在はmacOS hostが必要です。スマートフォンが接続するのはMac上のCodex Appであり、Codex CLI、IDE Extension、Linux / Windows開発機に直接接続するわけではありません。

第二に、ホストはオンラインでなければなりません。Macがスリープしたり、ネットワークを失ったり、Codex Appを閉じたりすると、リモートセッションは切断される可能性があります。

第三に、接続はQRコードのセットアップに依存します。Mac側でSet up Codex mobileを開き、スマートフォンでQRコードを読み取り、ChatGPTで連携を完了します。

第四に、遠隔操作にも承認フローがあります。端末コマンド、ファイル変更、テスト実行、外部アクセスに関わる操作は、内容を確認してから承認すべきです。

接続方法

MacでCodexを開きます。
サイドバーでSet up Codex mobileを選びます。
Codexがこのホストのリモートアクセスを有効化し、QRコードを表示します。
スマートフォンでQRコードを読み取り、ChatGPTのセットアップ画面に進みます。
同じChatGPTアカウントとworkspaceであることを確認します。
必要なMFA、SSO、passkeyを完了します。
成功すると、スマートフォンのCodexにMacが表示されます。

接続後はMac側のSettings > Connectionsで接続済みデバイスを管理できます。コンピューターをスリープさせない設定、Computer Use、Chrome extensionもここで確認できます。

スマートフォンでやるべきこと

スマートフォンに向いているのは、承認、方向修正、結果確認です。Codexがコマンド実行を求めたときに承認し、誤解やテスト失敗があれば短い指示で修正し、diffやテスト出力を確認できます。

価値があるのは「スマートフォンで開発する」ことではなく、ホスト上で動く開発タスクの携帯用コントローラーになることです。

よくある問題

ホストが表示されない場合は、MacでCodex Appが動いていること、Allow other devices to connectが有効であること、同じChatGPTアカウントとworkspaceを使っていることを確認します。

承認リクエストが表示されない場合は、ChatGPTモバイルアプリでCodexを開き、再度QRコードを読み取るか、ホスト側からセットアップをやり直します。workspaceでは管理者設定も確認します。

リモートセッションが切れる場合は、Macがスリープしていないか、ネットワークが切れていないか、Codex Appを閉じていないかを確認します。

向いている場面

長いCodexタスクをよく走らせる、席を離れても承認したい、複数のプロジェクトやthreadを扱う、Macを主開発機として使っている人に向いています。

WindowsやLinux中心、Codex CLIやIDE Extensionだけを使う、スマートフォンだけで完全な開発環境を期待する場合には向きません。

まとめ

Codexのモバイルリモートアクセスは、開発をスマートフォンに移す機能ではありません。Codexが止まりがちな承認、質問、テスト失敗、方向確認を、ChatGPT Appから処理できるようにする機能です。

Mac上でCodexをよく使う人には有用です。たまにコードの質問をするだけなら、効果はそれほど大きくありません。

参考資料

Superpowers：Coding Agent を工学プロセスへ戻す skills フレームワーク

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers は coding agent 向けの skills フレームワークであり、ソフトウェア開発方法論でもある。目的は万能 prompt を増やすことではなく、agent に流れを守らせることだ。目標を確認し、設計を作り、計画に分解し、TDD で実装し、レビューして終える。

プロジェクト：https://github.com/obra/superpowers

執筆時点で GitHub API では 19 万 star を超え、MIT ライセンスで、最近も更新されている。README は An agentic skills framework & software development methodology that works. と説明している。

解決したい問題

多くの AI コーディングツールの問題は、コードを書けないことではなく、すぐコードを書き始めることだ。

ユーザーが曖昧な要望を言うと、agent はファイルを編集し、見た目は完成する。しかし境界、テスト、アーキテクチャは不明確なまま残る。小さな作業ならよいが、複雑なプロジェクトでは手戻りと技術的負債になる。

Superpowers は、コードに触る前に agent を workflow に入れる。

何かを作りたいと分かったら、まず目標を質問する。
会話を仕様にし、区切って確認する。
設計が通ったら、実装計画を作る。
ユーザーが “go” と言ってから実装する。
実装では TDD、YAGNI、DRY、レビューを重視する。

これは新しい工学ではない。速い agent ほど、こうしたガードレールが重要になる。

対応ツール

Superpowers は単一の agent に縛られない。README には Claude Code、Codex CLI、Codex App、Factory Droid、Gemini CLI、OpenCode、Cursor、GitHub Copilot CLI が挙げられている。

つまり特定モデルのテクニックではなく、複数の harness で使える workflow 層に近い。

基本 workflow

最初は brainstorming。実装前に粗いアイデアを実行可能な設計へ変え、ユーザーに確認する。

次に using-git-worktrees。設計後、隔離された worktree とブランチを作り、インストールとテストの基線を確認する。

次は writing-plans。設計を小さなタスクに分け、ファイルパス、変更範囲、検証手順を明確にする。

実装段階では subagent-driven-development で subagent に渡すことも、executing-plans で順に実行することもできる。重要なのは各タスクが確認可能で review 可能なことだ。

その後 test-driven-development によって、本当の RED-GREEN-REFACTOR を行う。失敗するテストを書き、失敗を確認し、最小実装で通し、リファクタリングする。

さらに requesting-code-review でタスク間の review を行う。Critical な問題は進行を止める。

最後に finishing-a-development-branch でテストを確認し、merge、PR、worktree の保持や破棄を選ぶ。

Skills Library

テスト系は test-driven-development が中心だ。

デバッグ系には systematic-debugging と verification-before-completion がある。再現、最小化、仮説、検証、修正を求め、検証なしに完了と言わない。

協調系には次がある。

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

メタ skills には writing-skills と using-superpowers がある。組み合わせると、agent に「いつ質問し、いつ計画し、いつテストし、いつ止まって review するか」という習慣を与える。

普通の prompt との違い

普通の prompt は、ルールを system prompt に積み上げがちだ。勝手に変更するな、先に考えろ、テストしろ、簡潔に説明しろ。ルールが増えるほど、複雑なタスクでは忘れられやすい。

Superpowers はルールを段階ごとの workflow モジュールに分ける。各 skill は短く、目的が集中している。agent は今の段階で何をすべきかを理解しやすく、複雑な流れも検査しやすい。

学べる点は、賢いモデルだけを追うのではなく、モデルに繰り返し可能な働き方を与えることだ。

向いている場面

Superpowers は、実プロジェクトで coding agent を使う開発者に向いている。複数ファイルの変更、設計してから実装したい場合、TDD や検証が必要な場合、複数ブランチや worktree を扱う場合、subagent に実装や review を任せたい場合に特に有効だ。

一行の設定変更には重いかもしれない。しかし多段階の開発では、その制約が価値になる。

注意点

これは自動操縦ではない。プロセスは与えるが、要求、トレードオフ、最終受け入れは人間が持つ。

TDD と review は初期コストを増やす。小タスクでは遅く感じるが、複雑なタスクでは手戻りを減らす。

subagent の並列化は常に良いわけではない。境界と書き込み範囲が明確なときに効く。要件が曖昧なら、並列化は混乱を増やす。

まとめ

Superpowers の価値は、coding agent を「依頼を受けたらコードを書く」状態から、ソフトウェア工学プロセスへ戻すことにある。

AI コーディングに足りないのは生成速度ではなく、確認、計画、検証、review、終了処理であることが多い。モデルが強くなるほど、これらを省いてはいけない。

Codex、Claude Code、Cursor、Gemini CLI を実プロジェクトで使っているなら、Superpowers は調べる価値がある。直接使わなくても、skills の分け方は自分の agent workflow を設計する参考になる。

Vibe Coding を拒む：Matt Pocock の skills リポジトリが AI コーディングに工学的制約を足す

Fri, 15 May 2026 08:46:23 +0800

AI がコードを書く速度が上がるほど、プロジェクトが崩れる速度も上がり得る。問題はモデルが関数を生成できるかではなく、要件を理解し、チームの言葉に従い、既存アーキテクチャの中で小さく進められるかだ。

Matt Pocock が公開した mattpocock/skills は、vibe coding とは逆の方向を示している。AI に開発プロセス全体を任せるのではなく、成熟したソフトウェア工学の制約の中に置く。

プロジェクト：https://github.com/mattpocock/skills

これは魔法の prompt ではない。要件確認、ドメインモデリング、TDD、診断、アーキテクチャレビューを、AI agent が使いやすい workflow にした skills の集合だ。

まずアラインメント失敗を防ぐ

AI コーディングで最も多い失敗は、モデルが理解したと思ったら、実は曖昧な説明から推測していただけ、というものだ。

grill-me はこれを反転させる。コードを書く前に、AI を厳しいレビュアーにし、分岐、境界、未決事項を質問させる。

たとえば「ログインページを作って」と頼んだら、先に聞くべきことは次のようなものだ。

パスワード忘れはどう扱うか
外部ログインをサポートするか
ログイン失敗時のエラー表示はどうするか
アカウントロック、CAPTCHA、リスク制御は範囲内か
成功後はどこへ遷移するか

この段階は遅く見えるが、後の手戻りを減らす。コード生成が安くなるほど、曖昧な要件のコストは大きくなる。

ドメイン言語をコンテキストに入れる

次の問題は汎用語彙だ。モデルはチーム内の業務用語を知らないため、変数名、関数名、ドキュメントの言葉がずれていく。

grill-with-docs は質問しながら、CONTEXT.md、ADR、ドメイン文書を確認する。確認済みの用語、境界、判断は、再利用できるコンテキストとして残せる。

これはドメイン駆動設計のユビキタス言語に近い。チームが user ではなく customer、order ではなく transaction と呼ぶなら、AI もその言葉を使うべきだ。

コンテキスト文書の価値は、情報量ではなく推測を減らすことにある。

TDD で生成速度を制御する

AI の危険は速さにある。昔は悪いコードを大量に書くにも時間がかかったが、今は数秒で数百行が出る。問題は速さそのものではなく、フィードバックループがないことだ。

tdd skill は RED-GREEN-REFACTOR を戻す。

ひとつの振る舞いに対して失敗するテストを書く。
そのテストを通す最小実装を書く。
リファクタリングする。
次の縦スライスへ進む。

重要なのは、ひとつずつ進めることだ。AI は実行し、人間は方向と境界を確認する。

診断ループで複雑な問題を扱う

バグに出会うと、多くの agent は答えを推測し、何度も修正して問題をさらに複雑にする。

diagnose は先にフィードバックループを作らせる。

再現する
最小化する
仮説を立てる
観測やログを足す
修正する
回帰テストを足す

古い方法だが、AI コーディングでは特に重要だ。AI は試行が得意だが、根因に近づいているかを判断するにはレールが必要になる。

アーキテクチャを定期的に見る

単発のタスクが通っても、コードベースが良くなったとは限らない。AI の小さな変更が積み重なると、モジュール境界がぼやけ、インターフェイスが複雑になり、テストしづらくなる。

improve-codebase-architecture のような skill は、現在のタスクから離れて全体を見る。

責務が混ざっているモジュールはどこか
複雑すぎるインターフェイスはどれか
テストしづらい経路はどこか
ドメイン言語と合わない命名はどれか
収束すべき重複ロジックはどれか

これは自動で大規模リファクタリングするためではない。構造化された観察と改善方向を出し、人間が判断するためのものだ。

制限すべきは自由度

この方法論の核心は単純だ。AI コーディングはモデルを自由に走らせることではなく、明確な目標、コンテキスト、テスト、停止条件を与えることだ。

人間は問題定義、アーキテクチャ境界、業務上の取捨選択、受け入れ基準を担当する。AI はコード生成、テスト補完、反復修正、局所的なリファクタリングを担当する。

AI が強くなっても、ソフトウェア工学の基礎は古くならない。要件整理、ドメイン言語、TDD、診断、アーキテクチャレビューは、むしろ重要になる。

コードを書ける人は増える。差がつくのは、AI を保守可能で検証可能な工学体系に組み込めるかどうかだ。

Codex /goal vs Claude Code /goal：長いタスクを完了条件まで自動で進める

Thu, 14 May 2026 22:25:31 +0800

/goal は、AI コーディングツールにおける重要なコマンドになりつつあります。

これは「モデルにもう少しコードを書かせる」ためのものではありません。より実用的な問題、つまりタスクに明確な完了条件があるとき、毎ターン止まってユーザーの「続けて」を待つのではなく、Agent が条件を満たすまで進み続けられるか、という問題を扱います。

Codex CLI はすでに公式ドキュメントで実験的な /goal を追加しています。Claude Code も独自の /goal ドキュメントを公開し、複数ターンにまたがって作業を続けられる自動化機能として説明しています。名前は同じですが、プロダクトとしての方向性は完全には同じではありません。

`/goal` は何を解決するのか

通常の AI コーディング対話は、だいたい「一問一答」です。

ユーザーがタスクを出す。
Agent が分析し、コードを変更し、テストを実行する。
Agent が結果を報告する。
ユーザーが次の行動を決める。

この流れは短いタスクには向いています。しかし移行、リファクタリング、テスト修正、issue backlog の整理になると、かなり細切れになります。Agent は少しだけ進めて、また「続けて」と入力されるのを待つことがあります。

/goal の考え方は、タスクを「次に何をするか」ではなく「最終的にどんな状態なら完了か」に変えることです。たとえば：

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

この種の目標は長いタスクに向いています。テストが通る、ビルドが成功する、ファイル分割が終わる、キューが空になる、受け入れ条件を満たす、といった明確な終点があるからです。

Codex の `/goal`：実験機能で、現在のスレッドに紐づく

OpenAI の Codex CLI ドキュメントでは、/goal は実験機能として扱われています。デフォルトの安定機能ではなく、先に features.goals を有効にする必要があります。

有効化する方法は 2 つあります。

`1`	`/experimental`

または config.toml に追加します。

1
2

[features]
goals = true

有効化後は、次のように使えます。

`1`	`/goal Finish the migration and keep tests green`

よく使うコマンドは次の通りです。

/goal
/goal pause
/goal resume
/goal clear

OpenAI のドキュメントによると、Codex は goal を現在の active thread に付与し、より大きなタスクの進行中にその目標を追跡します。

ここで重要なのは、Codex /goal に対する公式ドキュメントの表現がかなり抑制的であることです。「長いタスクに実験的な目標を設定する」「現在のスレッドに目標を付与する」と説明していますが、Claude Code のドキュメントのように、各ターンの終了後に独立した evaluator が自動判定して次のターンへ進む、という説明まではしていません。そのため現時点では、Codex /goal は完全に安定した無人実行モードではなく、実験中の長期タスク向け目標メカニズムとして見るのがよさそうです。

Claude Code の `/goal`：完了条件で駆動する複数ターン実行

Claude Code の /goal ドキュメントはより明確です。ユーザーが completion condition を設定すると、Claude はその条件が満たされるまで複数ターンにわたって作業を続けます。

例：

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code の仕組みは、おおまかに次のようなものです。

現在の turn が終わっても、すぐに制御をユーザーへ戻さない。
小さく高速なモデルが、目標条件がすでに満たされたかを確認する。
満たされていなければ、Claude が自動で次のターンを開始する。
満たされていれば、goal は自動で解除され、transcript に完了状態が記録される。

つまり Claude Code の /goal は、「完了条件を満たすまで自動で続ける」機能に近いものです。単に会話へ目標を貼り付けるだけではなく、「次のターンへ進むかどうか」を独立した評価ステップに任せています。

Claude Code では、状態を直接確認することもできます。

/goal

状態には、目標条件、実行時間、評価済み turn 数、token 消費量、evaluator が最後に出した理由が表示されます。

途中で止めたい場合は、次を使います。

`1`	`/goal clear`

stop、off、reset、none、cancel も解除用の別名として使えます。目標を有効にした後でセッションが中断された場合でも、--resume や --continue で再開すると、active な goal を復元できます。ただし、経過時間、turn 数、token の基準値は再計算されます。

最大の違い

Codex と Claude Code はどちらも、AI コーディングを「単発の回答」から「長いタスクの実行」へ押し出しています。ただし /goal の位置づけには違いがあります。

比較項目	Codex CLI `/goal`	Claude Code `/goal`
状態	experimental	公式ドキュメントで単独ページとして説明
有効化	`features.goals` を有効化する必要がある	信頼済み workspace で直接利用可能
目標のスコープ	現在の active thread	現在の session
主な操作	set / view / pause / resume / clear	set / view / clear
自動判定	ドキュメントは目標の付与と追跡を強調	各ターン後に evaluator が判定すると明記
自動継続	公式表現は控えめ	条件未達なら自動で次のターンへ進む
向いている場面	Codex の長いタスクで目標コンテキストを維持したい場合	完了条件に向けて Claude Code に継続実行させたい場合

簡単に言えば、Codex の /goal は「現在のスレッドに実験的な長期目標を付ける」ものに近いです。Claude Code の /goal は「現在のセッションに検証可能な停止条件を設定し、満たされるまで自動で進める」ものに近いです。

よい `/goal` の書き方

どちらのツールでも、/goal は曖昧な願望を書く場所ではありません。

あまりよくない例：

`1`	`/goal 把项目优化一下`

よりよい例：

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

よい目標には通常、次の 3 つが含まれます。

明確な完了状態。
実行可能な検証方法。
守るべき境界。

目標が大きい場合は、停止条件も加えるべきです。

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

これは重要です。/goal が強力になるほど、境界が必要になります。そうしないと Agent は「完了」を追い求めて、過剰にファイルを変更したり、長く走りすぎたり、token を使いすぎたり、本来なら質問すべき問題をそのまま進めてしまう可能性があります。

`/goal` が向いている場面

向いているもの：

テスト修正：指定したテストが通るまで。
コード移行：すべての呼び出し箇所を変更し、コンパイルが成功するまで。
一括整理：特定の lint や型エラーがゼロになるまで。
ドキュメント補完：指定したすべてのモジュールに説明が付くまで。
issue キュー処理：特定タグの issue が処理済み、または明確に分類されるまで。

向いていないもの：

要件自体がまだ曖昧。
頻繁なプロダクト判断が必要。
高リスクな削除、データ移行、権限変更を含む。
受け入れ条件が主観でしか判断できない。
大量の無関係なモジュールをまたぐ。

実用的な基準は、「どのコマンドを実行し、どんな結果を確認し、どのファイルに触れてはいけないか」を書けるなら /goal に向いている、ということです。「もっとよくして」としか書けないなら、通常の対話、計画モード、人間のレビューを使うほうが安全です。

AI コーディングツールへの影響

/goal は明確な方向性を示しています。AI コーディングツールは「対話型アシスタント」から「継続実行できる作業単位」へ移りつつあります。

以前は、Agent にタスクを任せるとき、ユーザーが近くで見守る必要がありました。詰まったら促し、テストが終わったら続行させ、エラーが出たらまた命令する。/goal はこのやり取りを完了条件に圧縮し、次のターンで何をするかを Agent 自身に決めさせます。

ただし、これはユーザー側への要求も高めます。これからの prompt はタスクを説明するだけでなく、受け入れ条件、検証コマンド、変更範囲、停止ルールも書く必要があります。言い換えると、ユーザーの仕事は「続けてと促す」ことから「何をもって完了とするかを定義する」ことへ移ります。

Codex と Claude Code が /goal に到達したということは、長いタスクを扱う Agent が、もはやバックグラウンドタスクやクラウドキューだけのものではないということです。ターミナル上のローカルなコーディングツールにも、より強い自律的な進行能力が求められ始めています。

まとめ

Codex CLI と Claude Code はどちらも /goal を持っていますが、現時点では同じ機能として単純に扱わないほうがよいです。

Codex の /goal はまだ実験機能で、features.goals を有効にする必要があり、現在の Codex スレッドで長期目標を維持する仕組みとして見るのが自然です。Claude Code の /goal は、「完了条件」と「自動継続」をより明確に結びつけ、独立した evaluator によって続行可否を判断します。

日常開発では、この種のコマンドは明確な受け入れ基準を持つエンジニアリングタスクに向いています。要件判断やコードレビューを置き換えるものではありませんが、長いタスクにありがちな「続けて」「もう一度実行して」「テストが通るまで直して」という繰り返しを減らせます。

本当に身につけるべきなのは、コマンドそのものではありません。タスクを、明確で、検証可能で、停止できる目標として書く力です。

参考資料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal ドキュメント：https://code.claude.com/docs/en/goal

Codex は中国系 LLM とどう接続する？CCX で OpenAI 互換 API を一元管理する

Wed, 13 May 2026 23:20:40 +0800

CCX は AI API プロキシ兼プロトコル変換ゲートウェイです。Claude Messages、OpenAI Chat Completions、OpenAI Images、Codex Responses、Gemini API を 1 つのサービス入口にまとめ、チャネル、キー、モデルマッピング、優先度、フェイルオーバー、トラフィック監視を設定する Web 管理画面も提供します。

Claude、OpenAI、Gemini、Codex を同時に使っている場合や、OpenAI API 互換の上流サービスを複数維持している場合、CCX の価値は入口と管理の一元化にあります。クライアントは 1 つのサービスアドレスへ接続し、後続の上流チャネルは CCX が選択します。

プロジェクト：https://github.com/BenedictKing/ccx

CCX が解決すること

複数の AI API を混在させると、次の問題が起きやすくなります。

プロバイダーごとにパス、認証方式、リクエスト形式が異なる。
同じ種類のモデルでも複数の上流があり、base URL や API key を手動で切り替える必要がある。
ある key やチャネルが失敗したとき、クライアント側では自動でバックアップへ切り替わらないことが多い。
チーム利用では、モデル許可リスト、プロキシ、カスタムヘッダー、呼び出しログの集中管理が難しい。
Claude、Gemini、OpenAI Chat、画像 API、Codex Responses を同時に扱うと設定が散らばる。

CCX はこれらの差異をプロキシ層へ集約します。フロントエンドツール、スクリプト、業務サービスは CCX だけにアクセスし、CCX が API 種別、モデル、チャネル状態、優先度、ヘルス状態に基づいて適切な上流へ転送します。

対応エンドポイント

CCX は統一されたバックエンド入口を提供します。デフォルトポートは 3000 です。主なパスは次の通りです：

GET  /                         -> Web 管理画面
GET  /health                   -> ヘルスチェック
/api/*                         -> 管理 API
POST /v1/messages              -> Claude Messages プロキシ
POST /v1/chat/completions      -> OpenAI Chat プロキシ
POST /v1/responses             -> Codex Responses プロキシ
POST /v1/images/generations    -> OpenAI Images 生成
POST /v1/images/edits          -> OpenAI Images 編集
POST /v1/images/variations     -> OpenAI Images バリエーション
GET  /v1/models                -> モデル一覧
POST /v1beta/models/*          -> Gemini プロキシ

つまり、1 種類のプロトコルだけをプロキシするのではなく、Messages、Chat、Responses、Gemini、Images というよく使われる AI API 種別を個別のチャネルとして管理します。プロトコルごとにヘルス状態やログ空間が分かれるため、トラブルシュートしやすくなります。

アーキテクチャの考え方

CCX は Go バックエンドと Vue 3 フロントエンドで構成されています。フロントエンドのビルド成果物はバックエンドバイナリに埋め込まれるため、単一ポートでデプロイできます。同じサービスが Web UI、管理 API、プロキシ API を提供します。

リクエストの流れは概ね次の通りです：

`1`	`Client -> Auth Middleware -> Route Handler -> Channel Scheduler -> Provider / Converter -> Upstream API -> Metrics / Channel Logs -> Client Response`

主要モジュールの役割：

handlers: 各プロトコルのリクエストと管理操作を受け付ける。
providers: 上流 API のリクエストとレスポンス処理をラップする。
converters: Responses などの場面でプロトコル変換を行う。
scheduler: 優先度、プロモーション期間、ヘルス状態、サーキットブレーカー状態、セッション親和性に基づいてチャネルを選ぶ。
metrics: リクエスト数、成功率、遅延、ログ、サーキットブレーカー状態を記録する。
config: ランタイム設定を管理し、ホットリロードとバックアップをサポートする。

この設計の要点は、すべての API を無理に 1 つの形式へ変換することではありません。プロトコル種別ごとに代理し、管理、スケジューリング、ログ、認証を統一することです。

CCX と CodexBridge の違い

CCX と CodexBridge はどちらも Codex と OpenAI 互換 API に関係しますが、解決する問題が違います。

CodexBridge は専用の Codex ブリッジに近いツールです。目的は Codex CLI/SDK を OpenAI 互換の /v1/chat/completions サービスとして公開し、OpenWebUI、Cherry Studio、スクリプト、その他の OpenAI 互換クライアントからローカル Codex を呼び出せるようにすることです。つまり、CodexBridge の焦点は「Codex を外へ出す」ことです。

CCX は統一 AI API ゲートウェイに近いツールです。Codex Responses だけでなく、Claude Messages、OpenAI Chat、OpenAI Images、Gemini API も扱い、Web 管理画面、チャネル優先度、フェイルオーバー、ログ監視、複数 key 管理を提供します。つまり、CCX の焦点は「複数のモデルとプロバイダーをまとめて管理する」ことです。

簡単な比較：

項目	CodexBridge	CCX
中心的な位置づけ	Codex ローカルブリッジ	マルチプロトコル AI API ゲートウェイ
主な目的	Codex を OpenAI 互換エンドポイントにする	Claude、OpenAI、Gemini、Codex などのチャネルを一元管理する
管理画面	API サービス自体が中心	Web 管理画面を提供
複数チャネル調度	主目的ではない	チャネル優先度、フェイルオーバー、ログ監視に対応
向いている場面	ローカルまたは単一サービスで Codex を呼ぶ	チーム、多数の key、複数プロバイダー、複数プロトコル

Codex を OpenWebUI や Cherry Studio に接続したいだけなら CodexBridge のほうが直接的です。Codex、Claude、Gemini、DeepSeek、Qwen、Kimi など複数の上流をまとめて管理したいなら CCX が向いています。

クイックデプロイ

最も簡単なのはバイナリをダウンロードする方法です。ダウンロード後、同じディレクトリに .env を作成します：

PROXY_ACCESS_KEY=your-proxy-access-key
PORT=3000
ENABLE_WEB_UI=true
APP_UI_LANGUAGE=zh-CN

起動後、次へアクセスします：

`1`	`http://localhost:3000`

Windows で WSL、Docker、PowerShell などから localhost に接続できない場合は、Windows ホストの LAN IPv4 アドレスを使います。例：

`1`	`http://192.168.1.23:3000`

CCX はデフォルトで :PORT により全ネットワークインターフェースを待ち受けるため、LAN に公開する場合はアクセス制御に注意してください。

Docker デプロイ

Docker は常駐サービスに向いています：

docker run -d \
  --name ccx \
  -p 3000:3000 \
  -e PROXY_ACCESS_KEY=your-proxy-access-key \
  -e APP_UI_LANGUAGE=zh-CN \
  -v $(pwd)/.config:/app/.config \
  crpi-i19l8zl0ugidq97v.cn-hangzhou.personal.cr.aliyuncs.com/bene/ccx:latest

リポジトリに docker-compose.yml がある場合は次でも起動できます：

`1`	`docker compose up -d`

自動更新が必要なら Watchtower 設定を重ねます：

`1`	`docker compose -f docker-compose.yml -f docker-compose.watchtower.yml up -d`

デプロイ後、.config ディレクトリにはランタイム設定と永続データが保存されます。コンテナ再作成時に設定を失わないよう、ホストへマウントするのがおすすめです。

ソースから実行

開発またはカスタムビルドではソースから実行できます：

git clone https://github.com/BenedictKing/ccx
cd ccx
cp backend-go/.env.example backend-go/.env
make run

よく使うコマンド：

make dev
make run
make build
make frontend-dev

フロントエンドのみの開発：

1
2
3

cd frontend
bun install
bun run dev

バックエンドのみの開発：

1
2

cd backend-go
make dev

主な環境変数

最小構成は通常次のようになります：

PORT=3000
ENV=production
ENABLE_WEB_UI=true
PROXY_ACCESS_KEY=your-proxy-access-key
ADMIN_ACCESS_KEY=your-admin-secret-key
APP_UI_LANGUAGE=zh-CN
LOG_LEVEL=info
REQUEST_TIMEOUT=300000

ポイント：

PROXY_ACCESS_KEY はプロキシ API 用で、必ず変更します。
ADMIN_ACCESS_KEY は Web 管理画面と /api/* 用で、プロキシ用キーとは分けるべきです。
ENABLE_WEB_UI は管理画面の有効化を制御します。
REQUEST_TIMEOUT はリクエストタイムアウトです。長文コンテキストや画像タスクでは増やせます。
LOG_LEVEL はログレベルです。本番環境では通常 info または warn を使います。

リクエスト本文サイズを制限したい場合：

`1`	`MAX_REQUEST_BODY_SIZE_MB=50`

画像編集、base64 画像、マルチモーダルリクエストでは本文サイズが大きくなりがちです。

チャネル編成とフェイルオーバー

CCX の管理画面では複数チャネルを設定でき、各チャネルに次のような項目を指定できます：

上流サービス種別。
API key または複数 key のローテーション。
プロキシアドレス。
カスタムリクエストヘッダー。
モデル許可リスト。
ルートプレフィックス。
優先度。
ヘルスチェックとサーキットブレーカー復旧。

スケジューリングでは、チャネル状態、優先度、プロモーション期間、Trace 親和性、サーキットブレーカー状態、利用可能な key を総合的に考慮します。簡単に言うと：

通常は優先度の高いチャネルが先に使われる。
あるチャネルが失敗するとバックアップへフェイルオーバーできる。
サーキットブレーカーにより、明らかに使えない上流へ打ち続けることを避ける。
Trace 親和性により、同種のセッションをなるべく適切なチャネルに維持する。

これは複数 key、複数プロバイダー、複数地域の上流がある場合に便利です。個人の軽量利用なら、1 つのチャネルだけを設定して Web UI 付きプロキシ層として使うこともできます。

ログと監視

CCX はチャネル指標とリクエストログを提供します。確認できるもの：

リクエスト数。
成功率。
失敗率。
平均遅延。
モデル別の履歴データ。
チャネル状態とサーキットブレーカー状態。

本番環境では控えめなログ設定がよいです：

ENV=production
LOG_LEVEL=info
ENABLE_REQUEST_LOGS=true
ENABLE_RESPONSE_LOGS=false

これにより基本的なリクエスト情報を残しつつ、完全なレスポンス内容をログに書かないようにできます。調査時には一時的に詳細ログを有効化できますが、終わったら戻すべきです。特に本番でリクエスト本文とレスポンス本文を長期出力し続けるのは避けます。

セキュリティ上の注意

CCX はプロキシゲートウェイであり、上流 API key を保存します。したがって「動けばよい」だけで終わらせるべきではありません。少なくとも：

デフォルトまたは短すぎる PROXY_ACCESS_KEY を使わない。
ADMIN_ACCESS_KEY を別に設定する。
Web 管理画面を直接インターネットへ公開しない。
公開が必要な場合は、リバースプロキシ、VPN、アクセス制御、SSO の後ろに置く。
.env、.config、ログファイルを Git にコミットしない。
本番環境で完全なリクエスト本文とレスポンス本文のログを長期的に有効化しない。

ランダムキーは次のように生成できます：

1
2

PROXY_ACCESS_KEY=$(openssl rand -base64 32)
ADMIN_ACCESS_KEY=$(openssl rand -base64 32)

向いている人

CCX は次のような場面に向いています：

Claude、OpenAI、Gemini、Codex、画像 API を同時に維持している。
複数の API key があり、ローテーション、分流、フェイルオーバーが必要。
設定ファイルを手で編集するのではなく Web UI で上流チャネルを管理したい。
各チャネルの成功率、遅延、リクエストログを観察したい。
チームへ統一された AI API 入口を提供したい。

自分のマシンで単一モデルをたまに呼ぶだけなら、公式 SDK や単一の OpenAI 互換プロキシのほうが簡単です。CCX の強みは、複数チャネル、複数プロトコル、統一運用にあります。

まとめ

CCX は AI API ゲートウェイであり、特定モデルのクライアントではありません。Claude Messages、OpenAI Chat、OpenAI Images、Codex Responses、Gemini を 1 つのプロキシ層にまとめ、チャネル編成、フェイルオーバー、ログ監視、Web 管理画面を提供します。

個人利用では API アドレスやキーの切り替えを減らせます。チームや長期運用サービスでは、軽量な AI ゲートウェイに近い存在です。本番導入前には、モデル設定だけでなく、キー、管理入口、ログレベル、チャネル優先度、フェイルオーバー戦略も整える必要があります。

参考

GitHub プロジェクト：https://github.com/BenedictKing/ccx
アーキテクチャ説明：https://github.com/BenedictKing/ccx/blob/main/ARCHITECTURE.md
環境変数説明：https://github.com/BenedictKing/ccx/blob/main/ENVIRONMENT.md

Codex は中国系 LLM とどう接続する？OpenAI 互換 API と CodexBridge の使いどころ

Wed, 13 May 2026 23:08:28 +0800

CodexBridge は、Codex CLI/SDK を OpenAI 互換の HTTP サービスとして公開するローカルブリッジです。これにより、これまでターミナル中心だった Codex を、OpenWebUI、Cherry Studio、スクリプト、自動化システム、または OpenAI Chat Completions 互換クライアントから呼び出せます。

中心となるエンドポイントは /v1/chat/completions と /v1/models です。前者は会話を処理し、通常の同期レスポンスと SSE ストリーミングをサポートします。後者は OpenAI 風のモデル一覧として利用できます。すでに OpenAI API に対応しているツールなら、基本的には base URL、API key、モデル名を変更するだけで済みます。

プロジェクト：https://github.com/begonia599/CodexBridge

向いている用途

CodexBridge は、Codex を既存の AI クライアントやワークフローに組み込みたい場合に向いています。たとえば：

OpenWebUI や Cherry Studio で Codex を直接選びたい。
curl、Python、Node.js などのスクリプトからローカル Codex を呼びたい。
1 つのフロントエンドから OpenAI、Ollama、他の互換 API、Codex を同時に扱いたい。
Codex のローカルスレッド、サンドボックス、作業ディレクトリ、承認ポリシーを維持したい。
社内ツールに統一された /v1/chat/completions 入口を提供したい。

これは新しい LLM ではなく、Codex CLI を完全に置き換えるフロントエンドでもありません。より正確にはアダプター層です。上流はあくまで Codex で、ブリッジが OpenAI 風のリクエストを Codex が扱える会話入力に変換します。

基本環境

必要なもの：

Node.js 18 以上。
インストール済みでログイン済みの Codex CLI。
npm。好みに応じて pnpm / yarn でも構いません。

ソースからの基本的なデプロイ手順：

git clone https://github.com/begonia599/CodexBridge
cd codexbridge
npm install
cp .env.example .env
cp .env .env.local

その後、.env または .env.local を編集し、API key、デフォルトモデル、作業ディレクトリ、サンドボックスモード、ネットワーク権限などを設定します。

HTTP サービスを起動します：

`1`	`npm run codex:server`

デフォルトポートは 8080 で、PORT で変更できます。起動後は次のエンドポイントを利用できます：

1
2
3

GET /health
POST /v1/chat/completions
GET /v1/models

CLI 会話モード

HTTP サービスのほかに、軽量な CLI も用意されています。

`1`	`npm run codex:chat`

CLI では自然言語を直接入力して Codex と対話できます。よく使うコマンドは次の 2 つです：

/reset: 新しい Codex スレッドを作成する。
/exit: CLI を終了する。

現在のスレッド ID は .codex_thread.json に保存されます。次回 CLI を起動したときにこのファイルが残っていれば、以前の会話を続けられます。

HTTP 呼び出し例

最小構成のリクエストは次のようになります：

curl http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:medium","session_id":"demo","messages":[{"role":"user","content":"ls"}]}'

注意点：

authorization の token は CODEX_BRIDGE_API_KEY と一致している必要があります。
model には gpt-5-codex:medium や gpt-5-codex:high のように推論レベルを付けられます。
session_id は会話を紐付け、同じ Codex スレッドを再利用するために使います。

ストリーミング出力が必要な場合は stream: true を追加します：

curl -N http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:high","session_id":"stream","stream":true,"messages":[{"role":"user","content":"Node.js プロジェクトの作り方を段階的に説明してください"}]}'

OpenAI のストリーミング応答に対応したクライアントなら、通常のチャットに近い体験になります。

セッション永続化

CodexBridge の重要な機能の 1 つがセッションマッピングです。リクエストでは次のフィールドからセッション ID を渡せます：

session_id
conversation_id
thread_id
user

ヘッダーから渡すこともできます：

x-session-id
session-id
x-conversation-id
x-thread-id
x-user-id

本番環境では次を有効にするのがおすすめです：

`1`	`CODEX_REQUIRE_SESSION_ID=true`

これによりすべてのリクエストにセッション ID が必須となり、別ユーザーや別チャットウィンドウの文脈が混ざるのを避けられます。ブリッジ側のマッピングは .codex_threads.json に保存されます。このファイルを削除するとブリッジ側の対応関係をリセットできますが、Codex 自体のスレッドは ~/.codex/sessions に残ります。

CODEX_REQUIRE_SESSION_ID=false でリクエストにセッション ID がない場合、ブリッジは現在の messages を一回限りの入力として Codex に渡します。これは一時的な呼び出しには便利ですが、長い会話には向きません。

マルチモーダル入力

CodexBridge は OpenAI 風の content block をサポートし、画像を Codex が扱える local_image 入力に変換します。

リモート画像：

{
  "type": "image_url",
  "image_url": {
    "url": "https://example.com/demo.png"
  }
}

ローカル画像：

{
  "type": "local_image",
  "path": "./images/demo.png"
}

リモートリソースは一時ディレクトリへダウンロードされ、ターン終了後に削除されます。実運用ではリクエスト本文のサイズに注意してください。特に画像を base64 で送る場合は、CODEX_JSON_LIMIT を増やす必要があるかもしれません。

構造化出力

クライアントが response_format に対応している場合、CodexBridge はそれを Codex の outputSchema にマッピングできます。チェック結果、要約、分類結果、自動化レポートなど、固定 JSON 構造を返したいときに便利です。

最小例：

{
  "model": "gpt-5-codex",
  "session_id": "lint",
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "lint_report",
      "schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["ok", "action_required"]
          }
        },
        "required": ["summary", "status"],
        "additionalProperties": false
      }
    }
  },
  "messages": [
    {
      "role": "user",
      "content": "src/ の lint 問題を確認し、結果を JSON で返してください"
    }
  ]
}

type: "json_schema" では schema が必須です。ない場合、サービスは 400 を返します。

主な環境変数

よく使う設定は次のように分けられます。

サービスと認証：

1
2
3

PORT=8080
CODEX_BRIDGE_API_KEY=123321
CODEX_JSON_LIMIT=10mb

デフォルトモデル：

1
2

CODEX_MODEL=gpt-5-codex
CODEX_REASONING=medium

Codex 実行環境：

CODEX_WORKDIR=
CODEX_SANDBOX_MODE=read-only
CODEX_APPROVAL_POLICY=never
CODEX_SKIP_GIT_CHECK=true

ネットワーク機能：

1
2

CODEX_NETWORK_ACCESS=false
CODEX_WEB_SEARCH=false

フロントエンドチャット用途だけなら、デフォルトでネットワークを閉じておくほうが安全です。Codex に curl、git clone、Web 検索を明確に実行させたい場合だけ、対応するスイッチを有効にします。

Docker とインストールスクリプト

長時間常駐させたい場合は Docker 方式も使えます：

1
2

docker compose up -d
docker compose logs -f codexbridge

Linux 用のインストールスクリプトもあります：

`1`	`curl -fsSL https://raw.githubusercontent.com/begonia599/CodexBridge/master/scripts/install.sh \| bash`

このスクリプトは依存関係をインストールし、リポジトリを clone または更新し、.env.example をコピーして Docker Compose でサービスを起動します。sudo 権限が必要なので、クリーンなサーバーでの素早いデプロイに向いています。すでに複雑な Node.js、Docker、Codex 環境がある場合は、実行前にスクリプト内容を確認してください。

よくある問題

リクエストが 413 を返す

通常はリクエスト本文が大きすぎます。base64 画像でよく起きます。次を増やします：

`1`	`CODEX_JSON_LIMIT=20mb`

API key が無効と表示される

リクエストヘッダーに次があるか確認します：

`1`	`Authorization: Bearer <your CODEX_BRIDGE_API_KEY>`

または x-api-key を使います。

Codex が Git リポジトリ制限を報告する

実行ディレクトリが信頼済みリポジトリではない場合、Codex のチェックに引っかかることがあります。安全を確認した環境でのみ使ってください：

`1`	`CODEX_SKIP_GIT_CHECK=true`

会話をリセットしたい

ブリッジ側のマッピングは .codex_threads.json、Codex 自身のスレッドは ~/.codex/sessions にあります。サービスを停止して該当ファイルまたはディレクトリを削除すればリセットできます。

使い方のすすめ

ローカルで試すときは、まずデフォルト API key と read-only サンドボックスで流れを確認します。OpenWebUI、Cherry Studio、スクリプトから正常に呼び出せることを確認してから、CODEX_WORKDIR、CODEX_SANDBOX_MODE、CODEX_NETWORK_ACCESS、CODEX_APPROVAL_POLICY を段階的に調整します。

複数人で使う場合は、少なくとも次の 3 点を行うべきです：

session_id を必須にする。
デフォルト API key を変更する。
作業ディレクトリとサンドボックス権限を明確に制限する。

CodexBridge の価値は機能の多さではなく、Codex を既存の OpenAI 互換エコシステムに入れられる点にあります。クライアントが base URL を変更できるなら、Codex を通常のチャットモデルのように扱いつつ、ローカルスレッド、サンドボックス、ツール利用といった Codex 本来の機能を維持できます。

ProgramBench 0% 解説：AI コーディングで本当に怖いのは失敗ではなく、ロードマップが明確になったこと

Sun, 10 May 2026 12:32:39 +0800

AI コーディング界隈に、新しいベンチマーク ProgramBench が登場しました。表面的には、プログラマーにとって安心できる結果に見えます。主要 9 モデルは fully resolved 指標ですべて 0% で、1 つのタスクを完全に通過できたモデルはありません。

しかし本当に警戒すべきなのは、今日の大規模モデルがまだできないことではありません。完全なソフトウェア工学が、初めて明確に評価・順位付け・反復最適化できる課題として定義されたことです。

タスクが明確に定義されると、AI 業界が最も得意なことが始まります。ベンチマークを解き、反復し、ランキングを追い、かつて不可能だったものを少しずつ実用域へ近づけていくのです。

ProgramBench は何を測っているのか

多くのコーディングベンチマークは、関数補完、bug 修正、単体テスト通過、あるいは既存プロジェクトへの小さな機能追加を測ります。ProgramBench はそれよりずっと厳しいものです。ソースコードも、プロジェクト構造も、既存のテストケースも与えません。

モデルに与えられる材料は主に 2 つだけです。

コンパイル済みの実行ファイル。
そのプログラムの利用ドキュメント。

モデルは実行ファイルを自分で動かし、入出力の振る舞いを観察し、コマンドライン引数、境界条件、エラーメッセージ、データ保存方法を理解したうえで、同じ振る舞いをするプログラムを再実装する必要があります。

これはもはや「少しコードを書く」作業ではありません。簡略化されているとはいえ、完全なソフトウェア工学タスクです。要件を理解し、振る舞いを探索し、言語を選び、構造を設計し、ソースコードを書き、ビルド方法を用意し、隠しテストをできるだけ通過しなければなりません。

ProgramBench の公式説明によると、現在は 200 個のタスクを含み、小規模なコマンドラインツールから PHP、FFmpeg、SQLite などの大型実プロジェクトまでを対象にしています。テストセットは agent-driven fuzzing によって生成され、合計で 248,000 件を超える行動テストがあります。

テストの流れを分解すると、ProgramBench はおおよそ次の 4 つを測っています。

ドキュメントを読む力：プログラムが提供すべきコマンド、引数、出力を理解する。
振る舞いを探索する力：バイナリを繰り返し実行し、正常入力、異常入力、境界条件を観察する。
実装を再構築する力：言語とプロジェクト構造を自分で選び、振る舞いが近い代替プログラムを書く。
隠しテストを通す力：通常の振る舞いだけでなく、エラー処理、出力形式、境界条件もできるだけ一致させる。

つまり検索上の価値は「また新しいスコア表」だけではありません。より具体的に、ソースコードなしで、ドキュメントとブラックボックスの振る舞いだけを頼りに、大規模モデルが本物のソフトウェアをゼロから再現できるのかを問うています。

なぜ結果は 0% なのか

ProgramBench の主指標は fully resolved です。つまり、あるタスク内のテストがすべて通過して初めて完了とみなされます。現在の leaderboard では、9 モデルすべてがこの指標で 0% です。

評価対象には Claude、GPT、Gemini などの系列が含まれ、すべて mini-SWE-agent をベースライン agent として使っています。almost resolved 指標では Claude Opus 4.7 が最もよく、約 3.0% のタスクで少なくとも 95% のテストを通過しました。Claude Opus 4.6 は 2.5%、Claude Sonnet 4.6 は 1.0% です。GPT 5.4、GPT 5.4 mini、Gemini 3.1 Pro、Gemini 3 Flash などは almost resolved でも 0.0% です。

これは、今日の大規模モデルに軽量 agent を組み合わせても、ゼロから完全なソフトウェアを再構築することはまだできない、ということを示しています。最も簡単なタスクでさえ、すべての細部を完全に合わせるのは難しいのです。

ただし注意も必要です。今回使われたのは mini-SWE-agent であり、Claude Code でも Codex でもありません。より強力な coding agent、より多くのツールチェーン支援、より長い探索プロセスを使えば、結果は改善する可能性があります。より正確には、現在のモデルに軽量 agent を組み合わせただけでは、完全なソフトウェア再構築を安定して完了するには足りない、ということです。

fully resolved と almost resolved の意味

ProgramBench の結果を読むとき、最も誤解しやすいのがこの 2 つの指標です。

fully resolved は最も厳しい指標です。あるタスク内のすべての隠しテストを通過して初めて、完全に解決したとみなされます。境界条件、エラー形式、コマンド引数の振る舞いのどれか 1 つでも漏れれば fully resolved にはなりません。

almost resolved は「ほぼ完成」に近い指標です。あるタスクで少なくとも 95% のテストを通過すれば almost resolved に入ります。モデルが大部分の振る舞いを再現できたかは分かりますが、そのプログラムが元のソフトウェアを置き換えられることを意味するわけではありません。

だからこそ 0% は分けて見る必要があります。fully resolved の 0% は、モデルがまだ完全な納品をできないことを示します。一方で almost resolved の差を見ると、どのモデルが一部のタスクで復刻成功に近づいているかが分かります。たとえば Claude Opus 4.7 の almost resolved は約 3.0% で、少数の比較的簡単なタスクでは確かに完成に近づいていますが、完全なソフトウェア再構築を安定して行うにはまだ遠い状態です。

mini-SWE-agent が結果に影響する理由

今回の評価では、統一された mini-SWE-agent が使われています。利点は公平性です。異なるモデルを同じ軽量 agent フレームワーク上で走らせるため、横比較がしやすくなります。

しかし、それは上限も制限します。完全なソフトウェア再構築はモデル本体だけで決まるものではありません。agent が探索戦略を立てられるか、長期タスクを管理できるか、テストを自動生成できるか、失敗原因を反復的に特定できるか、プロジェクト構造を整理できるかにも左右されます。

mini-SWE-agent は最強のエンジニアリング環境というより、統一されたベースラインです。

Claude Code や Codex のようなより完全な coding agent は、通常、より強力なツール呼び出し、コンテキスト整理、タスク分解、多段階修正能力を備えています。これらのツールに置き換えれば、結果はよくなる可能性があります。

したがって ProgramBench の今回の結果は、現在のモデルが軽量 agent 環境では完全なソフトウェア再構築をまだできない、と理解するのが適切です。「モデルは永遠にできない」と証明しているわけでも、すべての商用 coding agent の上限を完全に測ったわけでもありません。

SWE-bench との違い

SWE-bench は AI コーディング領域ですでに重要なベンチマークです。実際の GitHub リポジトリで issue を読み、コードを修正し、パッチを提出させることで、モデルが現実の bug を解決できるかを測ります。

しかし SWE-bench は本質的には既存プロジェクトの修理です。車はすでにあり、技術スタック、ディレクトリ構造、コード組織、アーキテクチャ設計は人間が作っています。モデルは問題を見つけ、壊れた部品を直せばよいのです。

ProgramBench は車を作り直すことに近いものです。この車は赤信号で止まり、歩行者に近づくと警笛を鳴らす、といった振る舞いだけが分かっています。構造、言語、モジュール、ビルド方法はすべて自分で決めなければなりません。

だからこそ、はるかに難しくなります。局所的なパッチ能力だけでなく、ソフトウェアアーキテクチャ、システム推論、振る舞い探索、自動テスト、多段階修正、長期的なエンジニアリング設計を測るからです。

違いは次の表で整理できます。

観点	SWE-bench	ProgramBench
出発点	既存の GitHub リポジトリと issue	コンパイル済み実行ファイルと利用ドキュメント
ソースコードの有無	ソースコードあり	ソースコードなし
主なタスク	既存プロジェクト内の bug 修正	振る舞いから完全なプログラムを再実装
技術スタック	元プロジェクトで決定済み	モデルが自分で選択
プロジェクト構造	元プロジェクトに存在	モデルが自分で設計
テスト方法	パッチ提出後にテストを実行	隠し行動テストで復刻度を検証
主な評価点	コード読解、問題特定、パッチ修正	振る舞い探索、システム抽象化、アーキテクチャ設計、完全実装

このため ProgramBench は、次段階の AI Coding の目標として見るのに適しています。「既存コードを修正する」段階から「完全なソフトウェアを再構築する」段階へ問題を押し進めているからです。

0% は安全を意味しない

0% を見て、多くの人は「プログラマーの仕事は当面守られた」と感じるかもしれません。

短期的には、それは間違いではありません。今日の大規模モデルは、特にソースコード、テストケース、プロジェクト構造がない状況では、完全なソフトウェア工学を安定してこなせません。要件定義、アーキテクチャ設計、長期保守、セキュリティ管理、チーム協業、業務理解は、いまも人間のソフトウェアエンジニアの重要な強みです。

しかし 0% を「AI コーディングはここで頭打ち」と解釈するのは楽観的すぎます。

ProgramBench が本当に変えたのは、問題定義です。以前から、AI がコードを補完できることも、bug を修正できることも知られていました。しかし「実行ファイルとドキュメントから完全なソフトウェアを再構築する」という課題は、明確な共通レースとして置かれていませんでした。今は 200 問、統一評価、統一ランキングになっています。

これは、モデル企業、agent 企業、開発ツール企業が次にどこへ力を入れるべきかを知った、ということです。AI をコード片を書く存在から、完全なソフトウェアシステムを保守・再構築・納品する存在へ進化させる方向です。

オフライン化と不正防止が必要な理由

ProgramBench の設計には重要な細部があります。不正防止です。

初期のテストでは、モデルが GitHub から直接ソースコードを探したり、パッケージマネージャー経由でソースを含むパッケージをダウンロードしたり、ローカルのシステムキャッシュからダウンロード済みパッケージを探したりしました。これではテストの目的が壊れます。問うているのが「振る舞いからソフトウェアを再構築できるか」ではなく、「元のソースコードを見つけられるか」になってしまうからです。

そのため ProgramBench はサンドボックスとオフライン環境を使います。インターネットアクセス、逆コンパイル、逆アセンブル、実行ファイル内容の読み取りは禁止です。モデルはプログラムを実行し、振る舞いを観察し、自分で実装することしかできません。

この制限によって評価はよりクリーンになり、本当に答えたい問いに近づきます。大規模言語モデルは、プログラムの振る舞いとドキュメントから、自力で実行可能なソフトウェアプロジェクトを構築できるのか、という問いです。

より警戒すべきなのはコード形態の変化

ProgramBench には 0% よりもソフトウェアエンジニアが考えるべき発見があります。モデルが生成するコードは、人間のエンジニアが書くプロジェクトとは違う形になりがちです。

公開資料では、モデルはより少ないファイル、浅いディレクトリ、少ない関数、そして長い単一関数を生成する傾向があるとされています。つまり、構造が明確で人間が保守しやすいソフトウェア工学プロジェクトではなく、巨大だが動くスクリプトを書きがちです。

従来のソフトウェア工学の観点では、これは通常よくないコードです。ファイルが少なすぎる、関数が長すぎる、抽象化が足りない、モジュール境界が曖昧、といった問題は人間の保守を難しくします。

しかし問題は、AI が人間の保守方法に合わせてコードを書く必要があるとは限らないことです。

人間が抽象化、命名、ディレクトリ構造、モジュール境界を重視するのは、人間の記憶に限界があり、チーム協業が必要で、コードを長期的に再利用するからです。AI が長いコンテキスト、検索システム、自動テストを使ってコードを繰り返し書き直せるなら、人間に馴染みのある工学規範をそれほど必要としないかもしれません。

これは現実的なリスクを生みます。将来の AI が書くソフトウェアは動き、場合によっては高速でも、人間が保守に介入することはますます難しくなるかもしれません。

プログラマーが本当にアップグレードすべきもの

ProgramBench の結果は、プログラマーにとって単純な朗報でも悲報でもありません。

短期的には、完全なソフトウェア工学はまだ難しく、この benchmark だけでプログラマーがすぐ失業するわけではありません。特にアーキテクチャ判断、要件定義、セキュリティ管理、品質検収、業務理解は、今も人間が責任を持つ必要があります。

長期的には、プログラマーの仕事はさらに上流へ移ります。本当に危ないのは「コードを書けない人」ではなく、コードしか書けず、問題を定義できず、結果を検証できず、ツールチェーンを組織できず、リスクを制御できない人です。

未来のソフトウェアエンジニアは、より次のような役割に近づくかもしれません。

要件定義者：曖昧なビジネス課題を実行可能な目標に変える。
システム検収者：AI が生成した結果が本当に要件を満たしているか判断する。
ツールチェーン組織者：モデル、agent、テスト、デプロイ、監視を組み合わせる。
品質責任者：安全性、保守性、境界条件、長期リスクを管理する。
ビジネスと技術の翻訳者：現実の問題をエンジニアリングシステムが扱える制約へ変換する。

もし AI が本当にコードアシスタントから完全なソフトウェアエンジニアへ進化するなら、人間のプログラマーの価値は、すべての行を手で書くことではなくなります。何を書く価値があるのか、何をもって正しいとするのか、どこで失敗してはいけないのかを定義することになります。

まとめ

ProgramBench の 0% は終点ではなく、新しい段階の始まりです。

それは、今日の大規模モデルがまだゼロから完全なソフトウェアシステムを安定して再構築できないことを示しています。同時に、次世代 AI Coding agent の目標も非常に明確にしました。局所的なパッチから完全なプロジェクトへ、コード片からシステム納品へ進むという目標です。

プログラマーにとって、短期的には少し安心してよいでしょう。しかし長期的には「AI はまだできない」だけを見ていてはいけません。より重要なのは、自分をコード実行者から、問題定義者、結果検収者、リスク管理者へ早く引き上げることです。

本当に警戒すべきなのは、AI が今日 0% を取ったことではありません。問題集がすでに置かれたことです。

GPT-5.5、GPT-5.4、GPT-5.3-Codex はどう使い分けるべきか

Sun, 10 May 2026 08:43:17 +0800

結論だけ先に言うと、基本は GPT-5.5、コストや使用量をより重視するなら GPT-5.4、そして Codex 環境で長時間のソフトウェアエンジニアリング作業を回したり、Cloud Tasks や Code Review が必要だったりする場合に GPT-5.3-Codex を重点的に見る、という選び方になります。

これは単なる主観ではありません。2026-05-10 時点でも、OpenAI の Codex 公式ドキュメントでは、多くのタスクは gpt-5.5 から始めることを推奨しています。まだ gpt-5.5 が使えない場合は gpt-5.4 を使い、軽いタスクやサブエージェントには gpt-5.4-mini が向いている、という整理です。

3 つのモデルの位置づけ

まずは公式の位置づけから見ます。

GPT-5.5 は Codex における最新のフロンティアモデルで、複雑なコーディング、コンピュータ操作、ナレッジワーク、リサーチワークフロー向けです。難しい分析、多段階タスク、複数ファイルにまたがる修正、方針設計、重めのドキュメント作業に向く、いわば標準の主力モデルです。

GPT-5.4 はより安定した万能型の選択肢です。公式には、GPT-5.3-Codex の高いコーディング能力に、より強い推論、ツール使用、agentic workflow を組み合わせたモデルと説明されています。つまり、単なる「5.5 の弱い版」ではなく、長期的な主力として使いやすいバランス型です。

GPT-5.3-Codex も依然として非常に強いコーディングモデルですが、強みは実際のソフトウェアエンジニアリングや Codex ネイティブのワークフローにより集中しています。公式ドキュメントでも agentic coding tasks 向けに最適化されたモデルだとされており、GPT-5.4 のコーディング能力自体もその長所を引き継いでいます。

そのため、今の時点では GPT-5.3-Codex をそのまま「最強のコーディングモデル」と考えるのはあまり適切ではありません。日常的な開発では、まず GPT-5.5 と GPT-5.4 を優先して検討するほうが自然です。

用途別にどう選ぶか

日常の Q&A、難しい説明、資料整理、ファイル分析、長文の情報統合のような仕事なら、GPT-5.5 が最も向いています。コードを書くだけでなく、コード以外の負荷の高い知的作業にも強いからです。

複雑なプログラミング、リファクタリング、デバッグ、アーキテクチャ設計、複数ファイルの修正なら、やはり GPT-5.5 が第一候補です。Codex 公式の推奨も同じで、gpt-5.5 が使えるならまずそこから始める、という扱いです。

一方で、品質をある程度維持しながら消費量やコストを抑えたいなら、GPT-5.4 がより現実的な標準モデルになります。通常の開発、一般的なリライト、標準的な翻訳、スクリプト生成、バグ修正の多くでは、GPT-5.4 で十分に強く、しかもクレジット消費を抑えやすいからです。

Codex CLI、IDE 拡張、アプリで、よりエージェント的なソフトウェアエンジニアリング作業を回す場合、たとえば長時間リポジトリを読ませる、継続的にコードを書き換える、タスクをキューに積む、Cloud Tasks や Code Review を使うといった場面では、GPT-5.3-Codex にまだ意味があります。これは GPT-5.5 より新しいからではなく、Codex の Cloud Tasks と Code Review が今も GPT-5.3-Codex で動いているからです。

クレジット消費はどれくらい違うか

Codex の credits 表を見ると、この 3 つの違いはかなりはっきりしています。

Business / New Enterprise のトークン単位の料金では、次の通りです。

GPT-5.5：入力 125 credits / 1M tokens、キャッシュ入力 12.5 credits、出力 750 credits
GPT-5.4：入力 62.5 credits / 1M tokens、キャッシュ入力 6.25 credits、出力 375 credits
GPT-5.3-Codex：入力 43.75 credits / 1M tokens、キャッシュ入力 4.375 credits、出力 350 credits

表面的な単価だけで見ると、GPT-5.4 は GPT-5.5 のほぼ半額です。同じくらいの入出力長で処理するなら、一般には 50% 近く節約できると考えてよいでしょう。GPT-5.3-Codex は入力がより安いものの、出力コストはすでに GPT-5.4 にかなり近いため、「圧倒的に安い選択肢」というわけではありません。

ただし見落としやすい点もあります。Codex 公式には、GPT-5.5 uses significantly fewer tokens to achieve results comparable to GPT-5.4 とあります。つまり単価は高くても、複雑なタスクではトークン使用量の少なさややり直しの減少によって、差が縮まる可能性があります。

それでも、固定テンプレートの記事リライト、翻訳、SEO 説明文のように入出力の長さが比較的安定している仕事では、この「遠回りの少なさ」の恩恵は、複雑なソフトウェアエンジニアリングほど大きくありません。実運用では、GPT-5.4 のほうがやはり安く、だいたい 45% から 50% ほど節約できると考えてよいケースが多いです。

Codex での利用制限の違い

単価だけでなく、Codex 内での使え方も同じではありません。

2026-05-10 時点では、GPT-5.5 は Codex の推奨モデルですが、ChatGPT サインインで使う Codex でのみ利用でき、API key 認証には対応していません。GPT-5.4 と GPT-5.3-Codex は API から利用できます。

また、GPT-5.5 と GPT-5.4 は現時点で Codex Cloud Tasks と Code Review をサポートしていません。この 2 つは今も GPT-5.3-Codex の領域です。つまり、Codex 内で長時間のエンジニアリング作業を回したい場合は、単純にモデルの強さだけでなく、必要な機能が GPT-5.3-Codex に依存していないかも確認する必要があります。

ローカルメッセージだけを使う場合、Plus プランの 5 時間ウィンドウの目安は次の通りです。

GPT-5.5：15-80
GPT-5.4：20-100
GPT-5.3-Codex：30-150

ここからも現実的な違いが見えます。GPT-5.5 は最も強力ですが、固定枠の中では使える回数が少なくなりやすい。GPT-5.4 はよりバランスが良く、GPT-5.3-Codex はローカルメッセージだけを見ると、むしろ粘り強く見えることがあります。

よくある場面ではどう選ぶか

日常業務には、かなり種類の違う高頻度タスクがあります。抽象的に「どれが一番強いか」を考えるより、場面ごとに分けて見るほうが実用的です。

1. 日常の Q&A、資料整理、長文要約

GPT-5.5：最も向いています。曖昧な依頼を処理し、文脈を補い、散らばった情報を構造化するのが得意です。

GPT-5.4：通常の要約や大量整理に向いています。難度が高くなく、量が多いならより経済的です。

GPT-5.3-Codex：主力にはあまり向きません。こなせますが、もっとも得意な領域ではありません。

2. 技術概念の説明、コード解説、古いプロジェクトの読解

GPT-5.5：複雑なプロジェクト向きです。ファイル間の関係が多い、呼び出し経路が長い、歴史的経緯が重い、といった場合により安定します。

GPT-5.4：通常の読解には十分です。関数やモジュールの理解、設定の説明、既存プロジェクトの立ち上がり支援に向いています。

GPT-5.3-Codex：より実行寄りで、解説中心の用途では第一候補ではありません。

3. スクリプト、小ツール、SQL、Shell、正規表現

GPT-5.5：スクリプトの背後にシステム設計があったり、複数サービスが連動したり、制約が複雑だったりする場合に向いています。

GPT-5.4：標準の主力として最も使いやすいです。多くのスクリプト、小ツール、SQL、コマンドライン作業には十分で、しかもクレジット効率が良いです。

GPT-5.3-Codex：スクリプトが大きなエージェントワークフローの一部なら候補になりますが、単体の小さなスクリプト作成で優先する必要はありません。

4. バグ修正、小機能追加、テスト補完、通常開発

GPT-5.5：原因分析、複数ファイル修正、テスト補完まで含む少し重い修正に向いています。

GPT-5.4：日常開発の主力として最適です。一般的なバグ、小機能、テストのひな形、リネーム、整形などでは最もバランスが良いです。

GPT-5.3-Codex：対応できますが、Cloud Tasks やエンジニアリングエージェントが不要なら、普通は第一候補ではありません。

5. 複雑なリファクタリング、設計検討、難しいデバッグ

GPT-5.5：最も向いています。複雑な作業で本当に高くつくのは単発の出力ではなく、やり直しだからです。GPT-5.5 は主問題解決モデルとして使いやすいです。

GPT-5.4：中程度の難しさには向いています。設計案やリファクタリングにも使えますが、非常に長い文脈、多段階推論、不確実性の高い問題では GPT-5.5 ほど安定しないことが多いです。

GPT-5.3-Codex：より実行寄りで、この種の高難度な判断中心タスクでは優先順位は低めです。

6. 大量の軽作業、反復作業、サブタスク分割

GPT-5.5：できますが、通常は割高です。

GPT-5.4：最も向いています。コメントの一括修正、整形の一括処理、定型コード生成、内容のまとめて修正といった場面で最もバランスが良いです。

GPT-5.3-Codex：すでに Codex のエンジニアリングフローの中に組み込まれているなら候補ですが、単純な費用対効果では GPT-5.4 に劣りやすいです。

7. 自動化パイプライン、エージェント実行、継続的なリポジトリ操作

GPT-5.5：初期の設計、ルール作成、複雑なタスク分解に向いています。

GPT-5.4：自動化スクリプトや中程度のワークフローロジックの実装に向いており、特に API から使いたい場合に便利です。

GPT-5.3-Codex：ここでは特に重要です。Codex の Cloud Tasks と Code Review が今もこのモデルで動いているため、「仕組みを自走させる」場面に向いています。

8. 重要ページの文章、ブランド紹介、最終仕上げ

GPT-5.5：最も向いています。自然さ、文体制御、長文の一貫性が最も高いです。

GPT-5.4：通常ページや日常更新には十分です。重要ページは GPT-5.4 で下書きを作り、最後に GPT-5.5 で磨くのが実用的です。

GPT-5.3-Codex：主文案モデルには向きません。

9. 固定テンプレートの記事リライト、翻訳、SEO 説明文

GPT-5.5：テンプレート設計、最終調整、重要ページの仕上げ、より自然な中国語から英語への翻訳に向いています。

GPT-5.4：大量処理の主力に最も向いています。標準的な記事リライト、固定構成の翻訳、商品文案の書き換え、Meta description の一括生成では、品質とコストのバランスが良いです。

GPT-5.3-Codex：主文案モデルには向きません。バッチ処理スクリプト、HTML の整形、タグ構造の保持、自動公開フローの改善などに向いています。

10. EC 商品文案、カテゴリページ、大量コンテンツ運用

GPT-5.5：ルール設計、抜き取り確認、高価値ページの最終仕上げに向いています。

GPT-5.4：大量処理の主力として最適です。商品タイトル、カテゴリ説明、キャンペーン文案、ロングテール SEO コンテンツなどでは、品質とコストのバランスが良いです。

GPT-5.3-Codex：クロール、クリーニング、バッチ処理、自動公開スクリプトには向いていますが、主文案にはあまり向きません。

これらを一言でまとめるなら、次のようになります。

複雑な知的作業、複雑な分析、重要な文章作成：GPT-5.5
日常開発、大量処理、反復作業：GPT-5.4
Codex エンジニアリングエージェント、Cloud Tasks、Code Review：GPT-5.3-Codex

最後にどう使い分けるか

普段の仕事が通常のコーディング、バグ修正、技術相談、付随するドキュメント作成であれば、GPT-5.4 は非常に安定した主力になります。

より複雑なプロジェクト分析、複数ファイルの修正、設計検討、難しいデバッグ、あるいはエンジニアリングと重い知的作業の両方を 1 つのモデルでこなしたいなら、素直に GPT-5.5 を優先するのがよいです。

一方で、Codex 環境そのもののワークフロー、たとえば Cloud Tasks、Code Review、長時間のエージェント実行が重要なら、GPT-5.3-Codex はまだ残す価値があります。ただし、もはや最初の既定選択にするモデルではありません。

固定テンプレートのコンテンツサイトであれば、実用的な組み合わせは次のようになります。

GPT-5.4 で大量生成
GPT-5.5 でテンプレート設計、抜き取り確認、最終仕上げ
GPT-5.3-Codex で自動化ツールを書く

まとめ

現在のより現実的な優先順は、GPT-5.5、GPT-5.4、GPT-5.3-Codex の順です。GPT-5.3-Codex は、よりエンジニアリングエージェント寄り、あるいは Codex 固有機能寄りの場面に置くのが自然です。

もし「同じテンプレート記事をリライトする場合、GPT-5.4 は GPT-5.5 よりどれくらい節約できるのか」を知りたいなら、公式の credits 表とこの種のタスクに典型的なトークン構造を見る限り、「ほぼ半分近く節約できる」と考えてよいでしょう。大量コンテンツサイトではその差は十分に大きいため、GPT-5.5 を最初に使ってルールと文体を固め、その後の大量処理を GPT-5.4 に任せる、という運用がもっとも現実的です。

AI Coding プランの選び方：ライトユーザーは使いやすさ、ヘビーユーザーは柔軟性

Sun, 10 May 2026 08:20:58 +0800

AI Coding のプランは、この半年でかなり速いペースで変わっています。多くのツールが「回数ベース」から「使用量ベース」に移行し、無料または低価格プランの枠は締まり、海外サービスの一部では本人確認、地域制限、より厳しい利用ルールも増えました。

開発者にとって問題は、もはや「どのモデルが一番強いか」だけではありません。毎月いくら払うのか、枠は十分か、ツールは使いやすいか、そしてプランが突然値上げされたりルール変更されたりしたときに、スムーズに乗り換えられるかも重要です。

実用的な結論としては、ライトユーザーは使いやすさを買い、中程度のユーザーはコストパフォーマンスを買い、ヘビーユーザーは柔軟性を買うべきです。使い方が重くなるほど、モデルとツールを一つのプランに固定しないほうがよくなります。

プラン選びで見るべき 4 つのポイント

以前の AI Coding プラン選びでは、通常は 3 つのことを見れば十分でした。

モデルの性能が十分に強いか。
応答速度が安定しているか。
プランの枠が足りるか。

今はこれに 4 つ目を加える必要があります。モデルとツールを分けて使えるかどうかです。

モデルは推論能力を担い、ツールはコンテキスト管理、ファイル編集、Agent の編成、ワークフロー体験を担います。どちらも重要ですが、完全に結びつけないほうが安全です。たとえば Claude 系モデルが好きなら公式プランを使ってもいいですし、API を別のツールに接続しても構いません。あるエディタや Agent ツールが気に入っているなら、それが自社モデルしか使えないのではなく、複数モデルをつなげられるかを見たほうがよいです。

ここで大事なのは、複雑にすること自体ではなく、リスクを減らすことです。AI Coding は業界の中でも変化が最も速い分野の一つです。今は枠が緩いプランでも、数か月後には課金方式が変わるかもしれませんし、今は使いやすいツールでも、モデル連携の変更で体験が落ちるかもしれません。モデルとツールを分けておくことは、移行の余地を残すことでもあります。

海外プランは全体として締まりつつある

GitHub Copilot、Cursor、Windsurf、Claude Code のようなツールは今でも多くの人の主力ですが、流れはかなり明確です。安くて枠が大きいプランは維持しにくくなり、使用量ベース課金が一般化しています。

GitHub Copilot のようなサービスが使用量課金を強めるほど、プランそのものの「割安感」は薄くなります。ライトユーザーにはまだ便利ですが、Agent、長いコンテキスト、複雑なコードタスクを高頻度で使う人にとっては、実際の消費は本物の API コストにかなり近づいていきます。

Cursor と Windsurf は、要するにモデル能力を IDE 体験にまとめているツールです。強みは導入のしやすさと成熟したエディタ体験ですが、弱みはツールへのロックインが強めなことです。専用 Agent、インデックス、自動化フローに依存するほど、後から移るコストは高くなります。

Claude Code は体験面でも注目度でも魅力がありますが、海外サブスクリプション、本人確認、地域制限、中継サービスの安全性は、中国国内のユーザーにとって無視できないリスクです。特に第三者の中継サービスは、モデルの混在、安定性不足、データ安全性、サービス終了といった問題を抱えやすく、重要な仕事の長期基盤には向きません。

国内プランの強みと弱み

国内の AI Coding プランの利点は、多くが API 形式で提供されているため、特定のツールに強く縛られにくいことです。OpenCode、Cline、Continue、自作スクリプト、社内 Agent などに接続できます。

一方で弱点もはっきりしています。モデルが強く、速く、枠も大きい、という条件を同時に満たすプランはあまり多くありません。

GLM 系は国内モデルの中では強い部類ですが、ピーク時間帯にはスループットが不安定になり、重いタスクでは速度が足かせになることがあります。Kimi も能力は高いですが、価格と枠のルールは継続的に確認が必要で、特にバックエンドの枠がどれだけ透明かが重要です。MiniMax のようなモデルは速度と枠の面では使いやすく、日常の軽いタスクやバッチ処理、比較的単純なコード支援に向いていますが、難しいエンジニアリング推論では一段落ちることがあります。DeepSeek の新モデルは、キャンペーン価格のうちは非常にコスト効率が高く見えることがありますが、終了後は通常価格で改めて評価し直す必要があります。

そのため国内プランは、一つの万能パッケージとして使うより、「モデルプール」として運用したほうが向いています。タスクごとにモデルを使い分けるほうが現実的です。

ライトユーザー：使いやすさを優先し、API 構築にこだわりすぎない

週に数回、AI にスクリプト修正、ドキュメント補完、エラー説明、小さなツール作成を頼む程度なら、複雑な構成は不要です。

このタイプのユーザーは、まず使いやすい製品を選ぶのが正解です。Cursor、Windsurf、Trae、CodeBuddy、通義霊碼、GitHub Copilot などはどれも試す価値があります。大切なのは最安値ではなく、摩擦が少ないことです。普段使うエディタで安定して動き、補完品質が悪くなく、失敗したときに戻しやすい。それで十分です。

少し安くするためだけに、多段の API、中継、複雑なプロキシ構成を組むのは、ライトユーザーにはあまりおすすめできません。時間コスト、アカウントリスク、トラブル対応の手間のほうが、節約額より大きくなりがちです。

中程度のユーザー：コスパだけでなく、移行しやすさも見る

毎日 AI を使ってコードを書き、プロジェクトを直し、テストを作り、ドキュメントを整理するようになると、枠と実際の消費量をより真剣に見る必要が出てきます。

このタイプのユーザーには、主力ツールと予備モデルを分けておく構成が向いています。たとえば、使いやすい IDE プランで日常の編集を行い、別に複数ツールへ接続できる API や集約プランを用意して、長いコンテキストや複雑な Agent タスクに使う、といった形です。

選ぶときに見るべきポイントは主に 3 つです。

外部ツールへ接続できるか。
token や枠の消費が見えるか。
超過時の挙動が、速度制限、機能劣化、停止、純粋な従量課金のどれか。

見た目は安くても、そのツールの中でしか使えないプランなら、移行コストまで含めて考える必要があります。逆に少し高くても複数ツールで使えるなら、長期的にはそちらのほうが主力に向く場合があります。

ヘビーユーザー：モデルとツールを固定しない

ヘビーユーザーにとっての核心は柔軟性です。

個人やチームが毎日大量に AI Agent を使うようになると、消費量はすぐ大きくなります。コードベース検索、長いコンテキストでの修正、多段のデバッグ、自動テスト修復などは、token 消費を一気に増やします。その状態で単一プランに依存すると、次の 3 つの問題が起きやすくなります。

枠が急に足りなくなる。
課金ルールが突然変わる。
あるツールやモデルが一時的に使えなくなる。

より安定したやり方は、層を分けた構成にすることです。主力 Agent ツールを一つ、差し替え可能なモデル接続先を一つ以上、軽い仕事をさばく低コストモデルを一つ、難しい仕事を担う高性能モデルを一つ、という形です。日常の軽い仕事を全部いちばん高いモデルに投げる必要はありませんし、重要な仕事を最安モデルだけに頼るのも危険です。

ヘビーユーザーにとっては、「どのツールにもモデルをつなげられる」「どのモデルも別ツールで使える」という柔軟性のほうが、月数十ドルの差額より重要です。本当に高いのはサブスク料金そのものではなく、一つのエコシステムに閉じ込められたあとで、ワークフローを作り直すコストだからです。

より安定した組み合わせ方

比較的安定した構成は、次のように考えられます。

軽いタスクは低コストモデルに任せる。コード説明、小さなスクリプト、整形、簡単な文書生成など。
中程度のタスクはコスパ重視モデルに任せる。通常の機能開発、テスト補完、リファクタリング提案など。
難しいタスクは強いモデルに任せる。複雑な設計変更、複数ファイルの修正、難しいバグ、長いコンテキスト推論など。
ツール層は開いておく。API 接続、設定の持ち出し、モデル切り替えができるツールを選ぶ。
予備ルートを残す。主力プランのルールが変わったときに、別のモデルやツールへすぐ切り替えられるようにする。

これが最安とは限りませんが、変化にはかなり強くなります。AI Coding の価格や枠は今後も変わり続けるはずです。長期的に価値があるのは、短期的にお得に見えるプランそのものではなく、持ち運びできるワークフローです。

まとめ

AI Coding のプランは、月額だけで判断すべきではありません。ライトユーザーはシンプルさと使いやすさを優先し、中程度のユーザーは枠、消費量、移行しやすさを見て、ヘビーユーザーはモデルとツールを切り離して単一エコシステムへの依存を避けるべきです。

覚えておきたいのは、プランもモデルもツールも変わる、ということです。選択権を自分の手元に残しておくことが、長く AI Coding を使ううえで最も重要なコスト管理になります。

PPTからプロトタイプ設計まで：Guizang PPT SkillとHuashu Designの使いどころ

Sat, 09 May 2026 08:34:23 +0800

最近、中国語圏の開発者が作った2つのデザイン系 Agent Skill は、並べて見る価値があります。ひとつは歸藏による guizang-ppt-skill、もうひとつは花叔による huashu-design です。

どちらも従来の意味での「デザインツール」ではありません。設計プロセス、審美上の好み、チェックリスト、エンジニアリングテンプレートを、Agent が実行できる Skill として記述したものです。UI を開いて要素を少しずつドラッグするのではなく、Claude Code、Codex、Cursor のような Agent に要件を渡し、決められた流れに沿って HTML、PPT、アニメーション、プロトタイプを生成させます。

この種のプロジェクトの価値は、AI にランダムに発想させることではありません。「どう作れば見苦しくならないか」をプロセス化している点にあります。

guizang-ppt-skill：雑誌風Web PPTに特化

歸藏の guizang-ppt-skill は位置づけが明確です。単一ファイルの HTML 横スクロールPPTを生成し、視覚の基調は「デジタル雑誌 x 電子インク」です。汎用デザインフレームワークというより、登壇用に用意されたレイアウトシステムに近い存在です。

リポジトリの README では、主な機能として次のものが挙げられています。

単一ファイル HTML 出力。ビルドもサーバーも不要で、ブラウザから直接開ける。
横方向のページ移動。キーボード、ホイール、タッチスワイプ、下部ドット、ESC インデックスに対応。
Ink Classic、Indigo Porcelain、Forest Ink、Kraft Paper、Dune を含む5種類のテーマカラープリセット。
オープニングカバー、章区切り、データ大見出し、左テキスト右画像、画像グリッド、Pipeline、サスペンス質問、大きな引用、Before/After 比較、テキスト画像混在など10種類のページレイアウト。
テンプレート、コンポーネント説明、レイアウト骨格、テーマ設定、品質チェックリストを内蔵。

オフライン共有、業界内の社内発表、少人数イベント、AIプロダクト発表、demo day、そして強い個人スタイルを持つプレゼン資料に向いています。一方で、大量の表データ、研修教材、複数人での共同編集にはあまり向きません。

このプロジェクトの良いところは、割り切りです。すべてのデザイン場面を覆おうとせず、「雑誌風PPT」という場面を狭く定義しています。テーマ色はプリセットから選び、レイアウトにも明確な骨格があります。その制約が、むしろ Agent の脱線を減らします。

意見、業界観察、プロダクト発表の内容をプレゼン deck にまとめる機会が多いなら、かなり実用的です。

インストールコマンドも単純です。

`1`	`npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill`

huashu-design：より包括的なHTMLネイティブ設計ワークフロー

花叔の huashu-design はカバー範囲がより広いです。目標は PPT だけを作ることではなく、HTML をネイティブなデザインキャンバスとして扱い、Agent に納品可能なデザイン資産を生成させることです。

リポジトリの README では、次のような機能が挙げられています。

クリック可能な App または Web プロトタイプ。
HTML スライド、および編集可能な PPTX エクスポート。
プロダクト発表アニメーション、MP4、GIF、音楽付きバージョン。
複数方向のデザイン案の横並び比較。
インフォグラフィック、データ可視化、PDF、PNG、SVG エクスポート。
哲学的一貫性、視覚階層、実行品質、機能性、革新性を含む5次元の専門家レビュー。

中心にある考え方は、Agent にまずブランドと素材を理解させ、その後で高忠実度のデザインを出させることです。プロジェクトでは Core Asset Protocol が強調されています。具体的なブランドを扱うときは、記憶に頼って推測するのではなく、logo、製品画像、UI スクリーンショット、配色、フォント、ブランドガイドラインを先に確認します。

これは重要です。AI が生成したデザインの多くは「デザインっぽく」は見えますが、特定の実在する製品やブランドには見えません。huashu-design はこの問題を前段で解決しようとします。まず本物の素材を見つけ、それからデザインする、という流れです。

インストールコマンドは次のとおりです。

`1`	`npx skills add alchaincyf/huashu-design`

より包括的なデザイン納品をターミナル内で進めたい人に向いています。製品プロトタイプ、発表アニメーション、プレゼン資料、インフォグラフィック、デザインレビューを、ひとつの Agent ワークフローに載せて処理できます。

両者の最大の違い

簡単に言えば、guizang-ppt-skill はより狭く、より安定したプレゼン deck 生成器です。huashu-design はより広く、より包括的な HTML ネイティブ設計システムです。

PPT だけを見るなら：

guizang-ppt-skill は雑誌感、リズム、版面、単一ファイルのブラウザ発表をより重視します。
huashu-design は汎用的なデザイン能力、編集可能な PPTX、ブランド素材、エクスポート経路、レビュー工程をより重視します。

全体的なデザイン能力を見るなら：

guizang-ppt-skill は境界が明確で、スタイルのある横型プレゼンを素早く作るのに向いています。
huashu-design はより総合的で、製品やブランドのデザインタスクをプロトタイプ、アニメーション、スライド、インフォグラフィックに分解するのに向いています。

この2つのプロジェクトは、Skill の書き方としても異なる型を示しています。前者は高度に収束したテンプレートと審美上の制約の集合に近く、後者は小さなデザインチームのワークフロー説明書に近いものです。

なぜこの種のSkillが重要なのか

Agent でよくある問題は、「できるが、安定しない」ことです。同じ要件でも、あるときは良い出力になり、別のときは紫のグラデーション、角丸カード、偽物のアイコン、もっともらしい空文句へ流れてしまうことがあります。

Skill の意義は、そこに安定性を補うことです。次のようなものを固定化できます。

再利用可能なテンプレート。
実行可能なチェックリスト。
明確な審美上の好み。
よくあるミスを避けるルール。
出力形式と検証フロー。
いつ質問し、いつそのまま作業を始めるべきか。

これは、単に「もっと高級感を出して」と書くよりはるかに信頼できます。

特にデザインタスクでは、審美は一文の prompt だけで安定して再現できるものではありません。本当に役に立つのはプロセスです。まず素材を確認し、方向性を決め、構造を組み、視覚表現を作り、最後に出力を確認する。この流れを Skill として書くことで、Agent は一回きりの画像生成器ではなく、協働できる実行者に近づきます。

使い分けの提案

ひとつのテーマをオフライン登壇や共有用の deck にしたいだけなら、まず guizang-ppt-skill を試すとよいでしょう。出力の境界が狭く、単一ファイル HTML なので配布やプレビューもしやすいです。

Agent により包括的なデザインタスクを任せたい場合、たとえば App プロトタイプ、発表アニメーション、ブランド化されたスライド、エクスポート可能な PPTX、インフォグラフィックなどであれば、まず huashu-design を見るとよいでしょう。ワークフローは長めですが、複数回の反復と納品物の出力が必要なタスクに向いています。

すでに自分の Codex や Claude Code Skill を書いているなら、この2つのプロジェクトはいずれも参考になります。

「狭い場面をどう安定させるか」を学びたいなら、guizang-ppt-skill。
「複雑なワークフローをどう実行可能なプロトコルに分解するか」を学びたいなら、huashu-design。

まとめ

歸藏と花叔の2つのプロジェクトに共通しているのは、「デザイン能力」を一回の prompt から、繰り返し実行できるプロセスへ変えていることです。

guizang-ppt-skill の重点は雑誌風 HTML PPT で、強くスタイル化されたプレゼンに向いています。huashu-design の重点は HTML ネイティブ設計システムで、プロトタイプ、アニメーション、スライド、インフォグラフィック、レビューまでをカバーします。解決しているのは「AI はデザインを生成できるか」ではなく、「AI は安定した方法に沿って納品可能なデザインを生成できるか」です。

これは Agent ツールのエコシステムにおいて、重要なオープンソースプロジェクトの一類型になるかもしれません。コードテンプレートだけでなく、人間の経験、審美、仕事の進め方を Skill としてパッケージ化するものです。

参考リンク：

Codex vs Claude Code：2 つの Subagent 設計をどう選ぶか

Fri, 08 May 2026 14:14:01 +0800

AI コーディングツールでは Subagent が重要になっています。これは流行りの機能ではなく、単一 Agent が実際の開発タスクを抱え込むと限界に当たりやすいからです。

1 つの Agent がコードを読み、ログを確認し、実装を変更し、テストを実行し、エラーを分析し、結果をまとめると、main context はすぐ汚れます。検索結果、コマンド出力、テストログ、中間推論が混ざり、後の判断が不安定になります。探索、実装、検証、レビューを 1 本の main thread に押し込むため、並行処理もしづらくなります。

Subagent の本質は Agent の負荷を下げることです。main session はすべてを最後まで行うのではなく、目標を決め、タスクを割り当て、結果を受け取り、最終回答へ統合する coordinator になります。Subagent は探索、実装、検証、レビューなど局所的な仕事を処理し、圧縮した結論を返します。

つまり Subagent は「もう 1 人の自分」ではなく、絡み合った開発作業を明確な役割に分ける仕組みです。

共通する土台

成熟した Subagent system には通常、次の要素が必要です。

Context isolation。
Role specialization。
Project/user level configuration。
Tool and permission boundaries。

Context isolation は前提です。実際のリポジトリでは、検索結果、テストログ、コマンド出力など中間情報が大量に出ます。これをすべて main session に入れると main thread が乱れます。Subagent は局所的な過程を先に消化し、判断に必要な signal だけを返します。

Role specialization も重要です。複数 Agent とは同じモデルを複数起動することではありません。探索役は検索、読解、要約に強くあるべきです。実装役はコード変更に集中します。検証役はチェックを実行し、リスクを見つけ、結果を明確に報告します。

Tool と permission の境界は安全性を決めます。Subagent が main session の全能力を自動継承すべきではありません。読み取り専用の explorer に書き込み権限は不要です。verifier が実装を変更する必要もありません。

Codex と Claude Code はこの問題意識を共有しつつ、異なる道を取っています。

Codex：明示的な委任

Codex の Subagent 設計は抑制的です。

現在の main session を中心に、制御された軽量な分業機構を提供します。いつ委任するか、誰に渡すか、いつ結果を受け取るかは明示的な判断です。制御フローは現在のタスクに残ります。

特徴は次の通りです。

main session が明示的に subtask を委任する。
role set は小さく保たれる。
main session は誰が何をしているか把握できる。
結果は main line に戻ってから判断される。
協作境界が透明。

これは手動 orchestration、予測可能性、実行の確定性を重視するチームに向いています。explorer に call chain を調べさせ、worker に限定的な変更を任せ、main session が結果を統合して次のテストを判断できます。

一方で、分割、委任、回収、統合の負荷は main session に残ります。軽量な協作には心地よいですが、長期的で複雑な workflow では重くなることがあります。

Claude Code：Agent を workstations として扱う

Claude Code はより platform 的です。

Agent を、説明可能、選択可能、設定可能、記憶可能、隔離可能、background 実行可能な正式な object として扱います。Subagent は会話中の一時的な helper ではなく、開発システムの workstation に近い存在です。

Agent list、use case、description、tool boundary をモデルに渡し、モデル自身がその turn に適した role を選ぶことができます。これにより委任はより自動化されます。

この方向性を支える要素はいくつかあります。

第一に role system。explorer、planner、general-purpose、verifier などの role が用途説明、tool restriction、default model、runtime condition を持てます。read-only explorer は編集できず、planner は設計に集中し、verifier は検証に集中します。

第二に inheritance と override。Subagent は完全に自由ではありません。main session の大きな境界を継承しつつ、許可された範囲で局所的に振る舞いを調整します。

第三に memory。memory は単に少し覚えることではなく、scope を持ちます。user memory は長期的な好み、project memory はリポジトリ背景、local memory は現在環境の状態です。

第四に background work と worktree isolation。検証 task は background で走り続けることができ、main thread は待ち続けなくて済みます。強い隔離が必要なときは別 worktree で作業できます。

第五に plugin ecosystem。Agent を first-class object と見るなら、配布、インストール、優先順位、override、安全境界を考える必要があります。plugin agent は入れられますが、permission mode、hooks、MCP servers など高リスク領域は制限されるべきです。

これにより Claude Code は単発 session の協作ツールではなく、Agent runtime に近く見えます。

違い

Codex は制御された分業ツールに近いです。

明示的な委任。
軽量な role set。
明確な制御フロー。
現在 session 中心の subtask。
人が orchestration する確定的な作業に向く。

Claude Code は engineering workstation system に近いです。

Agent が正式に model 化される。
role が体系化される。
memory、background、isolation、plugin が runtime に含まれる。
モデルが role 選択に関与できる。
長期 project や platform 的 workflow に向く。

問題は機能数ではありません。Subagent を「自分が明示的に呼ぶ helper」と見るか、「system に長期存在する workstation」と見るかです。

選び方

明示的な制御、軽量な分業、現在 session 内の安全な並行処理を重視するなら Codex 的な設計が合います。コードレビュー、小さな変更、明確な実装 task、人がリズムを握りたい workflow に向きます。

体系化された role、長期 memory、background execution、worktree isolation、plugin extension、より完全な Agent runtime を求めるなら Claude Code 的な設計が合います。

判断する質問は 2 つです。

モデル自身が誰に仕事を任せるか選ぶことを受け入れられるか。
より完全な Agent runtime が必要か。

1 つ目が不安なら明示的委任が向いています。2 つ目が yes なら、platform 的な workstation system が向いています。

使い方の注意

Subagent を「モデルを増やせば強くなる」と考えない方がよいです。

各 role の task boundary を明確にする。
role ごとの tool を制限する。
raw log ではなく結論を返させる。
最終判断は main session に残す。
background task と worktree isolation を可視化する。
plugin agent に安全境界を置く。

Subagent の価値は数ではなく分業品質です。role が明確で context がきれいなほど、main thread の判断は安定します。

まとめ

Codex と Claude Code は同じ問題に向き合っています。単一 Agent は実際の開発作業をすべて背負いにくい。両者とも context isolation、role specialization、permission boundary、local summarization を重視します。

違いは設計の方向です。Codex は抑制的で、明示的委任と main session の制御を重視します。Claude Code は体系的で、Agent を設定、記憶、隔離、background 実行、plugin ecosystem に対応した正式な workstation として扱います。

選択はブランド勝負ではありません。必要なのが制御された協作ツールなのか、完全な Agent runtime なのかで決まります。

9Router：Claude Code、Codex、Cursor を 1 つの AI ルーターにつなぐ

Fri, 08 May 2026 13:41:15 +0800

9Router は AI コーディングツール向けのローカルルーターです。Claude Code、Codex、Cursor、Cline、Copilot、OpenCode、OpenClaw などを 1 つの OpenAI-compatible endpoint に接続し、そこから複数のモデルや provider に転送します。

目的はチャットクライアントを増やすことではありません。AI コーディングツールとモデル provider の間に入り、API 形式の違い、provider の手動切り替え、ツール出力による token 消費、quota 切れ、複数アカウント管理をまとめて扱います。

README によると、9Router は 40 以上の provider と 100 以上のモデルに対応し、RTK Token Saver、自動 fallback、quota 追跡、複数アカウントのローテーション、形式変換、リクエストログを備えています。JavaScript 製で、Node.js、Next.js、React、Tailwind CSS、LowDB を使い、MIT ライセンスです。

何に向いているか

複数の AI コーディングツールと複数のモデル供給元を同時に使う場合に便利です。

Claude Code はサブスクリプションで使う。
Codex や Cursor にカスタム OpenAI endpoint を設定したい。
Cline、Continue、RooCode に OpenAI-compatible API を渡したい。
無料 provider を試用に使う。
GLM、MiniMax、Kimi などを安価なバックアップにする。
高品質モデルを難しいタスクだけに使う。

通常は各ツールに endpoint、API key、モデル名、fallback を個別設定する必要があります。9Router はそれをローカルのルーティング層に集約します。

API:

`1`	`http://localhost:20128/v1`

Dashboard:

`1`	`http://localhost:20128/dashboard`

インストール

ローカル利用なら npm が簡単です。

1
2

npm install -g 9router
9router

ソースから実行する場合：

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

本番起動：

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

npm パッケージは Node.js >=18.0.0 を要求します。VPS や Docker では JWT_SECRET、INITIAL_PASSWORD、DATA_DIR、API_KEY_SECRET を設定してください。

ツールの接続

一般的な設定：

1
2
3

Base URL: http://localhost:20128/v1
API Key: 9Router Dashboard からコピー
Model: 9Router で設定したモデル名または combo 名

Codex CLI:

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

Cline、Continue、RooCode では OpenAI Compatible を選びます。

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

モデル名は接続済み provider によって変わり、cc/、cx/、gh/、glm/、minimax/、kr/、vertex/ などがあります。

RTK Token Saver

AI コーディングでは以下のようなツール出力が token を大きく消費します。

git diff
git status
grep
find
ls
tree
ログ
長いファイル一覧

9Router の RTK Token Saver は、これらをモデルに送る前に圧縮します。プロジェクト説明では、多くのリクエストで 20%-40% の input tokens を節約できるとされています。

ただし、重要なログや完全なファイル内容が必要な場面では、圧縮が回答品質に影響しないか確認してから使うのが安全です。

自動 fallback

モデルを優先順に並べられます。

1
2
3

1. サブスクリプションモデル
2. 安価な API
3. 無料 provider

例：

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

fallback は作業停止を減らしますが、モデルが変わると出力の一貫性も変わります。大規模リファクタリングや移行では固定モデルを使う方が安全です。

無料 provider の注意点

Kiro、OpenCode Free、Vertex などの無料経路は便利ですが、利用条件、地域制限、サードパーティツールでの利用可否、ban や rate limit、期限を必ず確認してください。9Router はルーティングを管理するだけで、上流 provider の規約は変えません。

デプロイ

個人利用なら localhost のみで十分です。VPS や LAN で公開するなら、デフォルトパスワードを変更し、強い JWT_SECRET と API_KEY_SECRET を設定し、Dashboard を公衆インターネットに直接出さず、/v1/* に Bearer API key を要求します。

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

まとめ

9Router は AI コーディングツールのローカル gateway です。Claude Code、Codex、Cursor、Cline などを http://localhost:20128/v1 に集約し、モデル選択、形式変換、token 圧縮、quota 追跡、fallback を処理します。

複数 provider を使う重めの AI コーディングユーザーに向いています。まず 1 つのツールと 1 つの provider から試し、徐々に combo とアカウントを増やすのが無難です。

参考資料

opencode、Claude Code、Codex の違いとは？オープンソース AI コーディングツールガイド

Fri, 08 May 2026 08:33:37 +0800

opencode は anomalyco が公開しているオープンソースの AI Coding Agent だ。位置づけは明確で、開発者がターミナル内で、プログラム可能で拡張しやすく、複数のモデル提供元に接続できるコードアシスタントを使えるようにする。

Claude Code や Codex と並べて見ると、3つはいずれも同じ種類の問題を解こうとしている。AI を実際のコードベースに入れ、コンテキストを理解し、ファイルを変更し、コマンドやテストを実行できるようにすることだ。ただし、製品としての向きは異なる。

opencode はオープンソース、複数モデル対応、ターミナル TUI を重視する。Claude Code は Anthropic のモデルエコシステムとローカルでの開発協業を重視する。Codex は OpenAI の AI coding agent であり、ターミナル、IDE、Codex app、クラウドタスクから利用できる。

opencode が向いている人

opencode は次のような開発者に向いている。

ターミナル内でコード変更、プロジェクト分析、エンジニアリングタスクを進めたい人。
AI Coding Agent を単一のモデル提供元に縛られたくない人。
オープンソースツールを好み、自分で監査、拡張、二次開発したい人。
Neovim、TUI、コマンドラインワークフローに慣れている人。
将来的にデスクトップ、モバイル、その他のクライアントから同じコーディングエージェントをリモート操作したい人。

重要なのは、単なるチャットウィンドウを作ることではない。開発者が普段使っているターミナルとプロジェクトディレクトリの中に、AI コーディング能力を入れることだ。

インストール方法

公式 README には複数のインストール方法が用意されている。

# 直接インストール
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS と Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# その他
mise use -g opencode
nix run nixpkgs#opencode

公式 README では、古いバージョンの残存による問題を避けるため、インストール前に 0.1.x より前のバージョンを削除することも推奨している。

インストールスクリプトは次の優先順位でインストール先を選ぶ。

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

パスを指定したい場合は、次のように書ける。

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

デスクトップアプリはまだ Beta

コマンドラインツールに加えて、opencode はデスクトップアプリも提供している。ただし現在は Beta 扱いだ。GitHub Releases または opencode.ai/download からダウンロードできる。

デスクトップ版は次のプラットフォームに対応している。

プラットフォーム	ファイル
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` または `.AppImage`

macOS と Windows では、パッケージマネージャーからデスクトップ版をインストールすることもできる。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

2つの内蔵 Agent モード

opencode には2つの内蔵 Agent があり、Tab キーで切り替えられる。

build はデフォルトモードで、完全な開発権限を持つ。コードを直接変更し、コマンドを実行し、エンジニアリングタスクを進める用途に向いている。

plan は読み取り専用モードだ。未知のコードベースを分析し、プロジェクト構造を理解し、変更方針を立てる用途に向いている。デフォルトではファイル編集を拒否し、bash コマンドを実行する前に確認する。

さらに、opencode には複雑な検索や多段階タスクのための general サブ Agent もある。ユーザーはメッセージ内で @general と入力して呼び出せる。

この設計は実用的だ。実際に手を動かす前に plan でプロジェクトを把握し、コードを変更する必要が出たら build に切り替える。大規模リポジトリでは、読み取り権限と書き込み権限を分けることで誤操作を減らせる。

Codex とは

Codex は OpenAI の AI coding agent で、開発者がコードを書き、コードレビューを行い、bug を修正し、エンジニアリングタスクを出荷するのを支援する。

単なるコード補完ツールとは異なり、Codex はコードベースを操作できる Agent に近い。ローカルツール内で開発者とペアになって作業することも、クラウドにタスクを委任することもできる。OpenAI の公式資料では、Codex は CLI、IDE、Codex app、ChatGPT/Codex クラウドなど複数の入口から利用できると説明されている。

開発者にとって、Codex のポイントは次の通りだ。

コードベースを読み、ファイルを編集し、コマンドとテストを実行できる。
ターミナル、IDE、アプリ、クラウドなど複数のインターフェースに対応する。
bug 修正、機能開発、リファクタリング、移行、コードレビュー、テスト補完に向いている。
OpenAI アカウント、モデル、Codex 製品体系との結びつきが強い。
クラウドタスクは、比較的明確な複数のエンジニアリングタスクを並行処理するのに向いている。

opencode が開かれたターミナルエージェントフレームワークに近いとすれば、Codex は OpenAI が提供する一式の AI コーディングワークベンチに近い。ローカルでペア作業でき、クラウドに委任でき、チームはそれをより長いエンジニアリングフローへ組み込める。

3つの主な違い

opencode、Claude Code、Codex はいずれも AI コーディングツールだが、選ぶときはまず次の観点を見るとよい。

ツール	中心的な位置づけ	主な強み	向いている用途
`opencode`	オープンソース AI Coding Agent	オープンソース、複数モデル、TUI、クライアント/サーバー構成	開かれたツールチェーン、交換可能なモデル、ターミナル中心のワークフローを求める開発者
`Claude Code`	Anthropic のコマンドライン型コーディングツール	Claude モデル体験、コード理解、長いコンテキスト、エンジニアリングタスク協業	Claude/Anthropic エコシステムを使っていて、ローカルでコードタスクを進めたい開発者
`Codex`	OpenAI の AI coding agent	CLI、IDE、Codex app、クラウドタスク、複数 Agent ワークフロー	ChatGPT/OpenAI を使っていて、ローカルでのペア作業とクラウド委任を併用したいチーム

簡単に言えば、opencode のキーワードは「オープン」と「交換可能」、Claude Code のキーワードは「Claude エコシステム」と「ローカル開発エージェント」、Codex のキーワードは「OpenAI エコシステム」と「複数入口の協業」だ。

Claude Code との違い

opencode の公式 FAQ は Claude Code と直接比較している。両者の能力はかなり近いが、主な違いは次の通りだ。

第一に、opencode は 100% オープンソースプロジェクトで、コードは GitHub にホストされ、MIT license で提供されている。

第二に、opencode は単一のモデル提供元に縛られない。OpenCode Zen が提供するモデルを推奨しているが、Claude、OpenAI、Google、またはローカルモデルとも組み合わせられる。開発者にとっては、モデルのコスト、能力、可用性が変わっても、特定のプラットフォームにロックインされにくいという意味がある。

第三に、opencode は任意の LSP サポートを内蔵している。コード補完、ジャンプ、診断、プロジェクト理解にとって、LSP は非常に重要な基盤だ。

第四に、opencode は TUI を重視している。Neovim ユーザーと terminal.shop の作成者によって作られており、製品の重心は明らかにターミナル体験にある。

第五に、opencode はクライアント/サーバー構成を採用している。つまり、opencode を自分のコンピューター上で動かし、将来的に TUI、デスクトップ、モバイル、その他のクライアントから制御できる。TUI はそのうちの一つのフロントエンドにすぎない。

opencode、Claude Code、Codex をいつ選ぶか

すでに Claude Code や Codex を使っている場合、opencode がすぐにそれらを置き換える必要はない。より自然な見方は、opencode がオープンで、モデルを交換でき、ターミナル寄りの選択肢を提供しているというものだ。

opencode を優先して検討したい場面は次の通り。

AI コーディングツールをできるだけオープンソースにしたい。
ワークフローを特定のモデル提供元に縛られたくない。
同じツールで Claude、OpenAI、Google、またはローカルモデルを試したい。
TUI が好きで、主要な作業フローをデスクトップアプリやWebアプリに中断されたくない。
クライアント/サーバー構成によるリモート制御能力に関心がある。

Claude Code を優先して検討したい場面は次の通り。

主に Claude モデルを使っている。
長いコンテキスト、コード理解、複雑なエンジニアリングタスク協業を重視している。
ローカルリポジトリ内で変更、テスト、リファクタリングを継続的に進めたい。
Anthropic による Claude Code のデフォルト製品体験を信頼している。

Codex を優先して検討したい場面は次の通り。

すでに ChatGPT または OpenAI アカウント体系を使っている。
同じ coding agent をターミナル、IDE、デスクトップアプリ、クラウドタスクで使いたい。
明確な bug 修正、機能開発、移行、テスト補完をクラウドに委任して並行処理したい。
コードレビュー、バックグラウンドタスク、チーム協業、複数 Agent ワークフローが必要だ。

公式の一体化された体験、デフォルトのモデル設定、企業管理、既製の統合を重視するなら、Claude Code や Codex のほうが楽な場合がある。制御性、オープン性、provider-agnostic を重視するなら、opencode は注目に値する。

注意点

opencode、Claude Code、Codex はいずれも変化が速い。GitHub release、インストールコマンド、デスクトップ版のファイル名、モデルの可用性、プラン権限は変わる可能性がある。インストールや選定の前には、それぞれの公式 README、ドキュメント、リリースページを直接確認するのがよい。

また、opencode のデスクトップアプリはまだ Beta と表示されており、安定した本番用ツールとして最初から扱うべきではない。日常的なエンジニアリングタスクでは、ターミナル版が引き続き主な入口になる。

ツールの流れとして見ると、opencode は AI Coding Agent のオープンツールチェーン方向を代表している。モデルを交換でき、クライアントも交換でき、コアの代理能力をできるだけ開く方向だ。一方、Codex と Claude Code は、モデル企業が coding agent を完成度の高い製品入口として作る方向に近い。開発者にとって、この2つの流れは長く併存するだろう。

参考リンク

opencode GitHub：https://github.com/anomalyco/opencode
opencode 公式サイト：https://opencode.ai
opencode ドキュメント：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Awesome Codex Skills：Codex CLI を拡張するコミュニティ製スキルカタログ

Thu, 07 May 2026 20:19:15 +0800

ComposioHQ の awesome-codex-skills は、Codex CLI 向けのコミュニティ製スキルカタログです。単なるプロンプト集ではなく、繰り返し使う作業手順をインストール可能で、再利用しやすく、保守しやすい Skill として整理している点に価値があります。

Codex を日常の開発パートナーとして使っているなら、この種のリポジトリの意味はかなり分かりやすいはずです。毎回説明していたルール、コマンド、参照資料、操作手順を一度 Skill にまとめておけば、次回から Codex は同じ文脈で作業を始められます。

このリポジトリが解決すること

Codex Skills は、Codex CLI に「専用の作業モード」を追加する仕組みだと考えると分かりやすいです。通常のプロンプトは一度きりの指示に向いていますが、Skill は長く再利用する作業に向いています。

たとえば、次のような作業です。

決まった形式でコミットメッセージを生成する。
特定の API ドキュメントを参照する。
プロジェクト固有のテストやデプロイコマンドを実行する。
チーム規約に沿って記事を書き直す、翻訳する、資料を整理する。
外部ツールを呼び出して反復的な開発補助作業を行う。

こうした内容を毎回入力するのは負担になります。Skill はそれらのルールを独立したディレクトリに置き、中心となる SKILL.md に手順を書きます。必要に応じてスクリプト、テンプレート、参考資料、アセットも添えられます。Codex は呼び出されたときにその説明を読み、定義された流れに従って作業します。

通常のプロンプトとの違い

通常のプロンプトは「今回はこうしてほしい」という一回限りの指示に近いものです。Skill は「この種類のタスクでは今後この手順で進める」という小さな運用マニュアルに近いものです。

主な利点は次の三つです。

再利用できる：よく使う作業手順を何度も貼り付ける必要がありません。
レビューしやすい：スキルファイルは通常ローカルの Markdown で、直接開いて編集し、バージョン管理できます。
拡張できる：複雑な Skill は自然言語の説明だけでなく、スクリプト、テンプレート、参考資料を含められます。

awesome-codex-skills のようなカタログの価値もここにあります。既存の Skill を探し、自分の作業スタイルに合わせて選び、インストールし、改造できます。

インストールと使い方

リポジトリにはインストールスクリプトが用意されており、手動インストールにも対応しています。典型的な流れは次の通りです。

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

少数の Skill だけを試す場合は、各スキルディレクトリの SKILL.md を先に読み、どの資料を読むのか、どのスクリプトを実行するのか、どのファイルを変更する可能性があるのかを確認してから、ローカルの Codex skills ディレクトリへ入れるのがよいでしょう。

インストール後、Codex はタスクに応じて Skill を自動的に使うこともできますし、明示的に名前を指定して呼び出すこともできます。長く使うなら、まずコミュニティ製 Skill を入れ、その説明を自分のプロジェクト規約に合わせて書き換えるのが実用的です。

注目したい Skill

この種のリポジトリで最初に見るべきなのは、名前が派手な Skill ではなく、反復作業を安定して減らしてくれる Skill です。

優先して見たいのは次のようなものです。

開発フロー系：コードレビュー、テスト、コミット、リリース、依存関係チェック。
ドキュメント処理系：書き直し、翻訳、要約、構造化整理。
ツール連携系：Codex を外部サービス、API、CLI ツールにつなぐもの。
プロジェクト規約系：チームの約束、ディレクトリ構成、命名規則、デプロイ手順を固定フローにするもの。

一文のプロンプトを包んだだけの Skill なら価値は限られます。調査、判断、実行、検証、出力までを安定した流れにできる Skill なら、長く残す価値があります。

注意点

コミュニティ製 Skill は便利ですが、ブラックボックスとしてそのまま実行するべきではありません。特にスクリプトを含む Skill は、インストール前に次の点を確認したいところです。

SKILL.md が Codex に何をさせようとしているか。
ネットワークアクセス、ファイルの読み書き、外部サービス呼び出しを行うスクリプトが含まれているか。
デフォルトのパス、コマンド、権限が自分の環境に合っているか。

Skill は Codex の行動範囲を広げます。よく書かれた Skill は、Codex をプロジェクトに詳しい同僚のようにしてくれます。雑に書かれた Skill は、合わないルールを作業フローへ持ち込むこともあります。理想は大量に入れることではなく、少数を入れ、自分に合うよう調整し、長く保守することです。

所感

awesome-codex-skills はブックマークする価値があります。特に Codex CLI を実際の開発、ドキュメント作成、自動化に使い始めている人には役立ちます。これは公式機能そのものではなく、コミュニティが整理した Skill の入口です。そこから着想を得ることも、普段の作業を自分用のローカル Skill に変えることもできます。

ヘビーユーザーにとって、Codex Skills の重要点は AI に多くを記憶させることではありません。同じ種類のタスクで回り道を減らすことです。ルールを Skill として書くことは、一度きりの説明を再利用可能な作業基盤に変えることでもあります。

CC Switch：Claude Code、Codex、Gemini CLI、OpenClawを一元管理するデスクトップツール

Wed, 06 May 2026 09:03:08 +0800

CC Switch は、AIコーディングを日常的に深く使うユーザー向けのデスクトップ管理ツールだ。解決しようとしている問題ははっきりしている。いま多くの人が Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw を同時に使っているが、それぞれ設定形式、Providerの書き方、MCP設定、Skills管理の方法が違う。

1つのツールだけを使うなら、手作業で設定を変えるのもまだ我慢できる。しかし複数のツールを混在させ、そこに公式アカウント、サードパーティAPI、リレーサービス、ローカルモデル、チーム共有設定まで加わると、JSON、TOML、.env を手で編集する作業はすぐに面倒になる。

CC Switch の位置づけは、こうした分散した設定を1つのクロスプラットフォームなデスクトップアプリに集約することだ。

何を解決するのか

現代のAIコーディングツールは、「コマンドラインの中にいる開発仲間」のようになりつつある。ただし、各ツールのエコシステムはまだ完全には統一されていない。

よくある課題は次の通りだ。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawで設定形式が異なる。
API Providerを切り替えるたびに、設定ファイルを何度も変更する必要がある。
MCP serverを複数ツールで重複して設定しがちになる。
CLAUDE.md、AGENTS.md、GEMINI.md のようなプロンプトファイルを統一して保守しにくい。
Skillsのインストール、同期、バックアップ、削除に集中管理の入口がない。
複数アカウント、複数relay、複数モデルサービスの切り替えが混乱しやすい。
設定ファイルを手作業で壊した場合、原因調査のコストが高い。

CC Switch の考え方は、ユーザーに各ツールの設定細部を覚えさせるのではなく、Provider、MCP、Prompts、Skills、Sessions、プロキシを1つの統一画面で管理するというものだ。

対応ツール

READMEに挙げられている主な対応対象は5種類ある。

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

これらのツールは、AIコーディング、Agentワークフロー、コマンドライン上の協働という点で近い位置づけにある。ただし設定体系は異なっており、CC Switch の価値はその違いを包み込むところにある。

複数のAIコーディングツールをよく比較する人にとっては、毎回設定ファイルを手で開くよりかなり楽になる。

Provider管理

CC Switch の第一の機能はProvider管理だ。

50以上のProviderプリセットを内蔵しており、READMEではAWS Bedrock、NVIDIA NIM、各種コミュニティrelayなどが挙げられている。ユーザーはAPI keyをコピーしてワンクリックでインポートし、画面上で切り替えられる。

実用的なポイントは次の通りだ。

Providerをワンクリックで追加できる。
Providerをドラッグで並べ替えられる。
システムトレイから素早く切り替えられる。
Providerのインポートとエクスポートに対応する。
一部の共通Providerは複数アプリへ同期できる。

多くの人にとって、この機能だけでも十分に魅力がある。AIコーディングツールの日常利用で問題になるのは、「モデルを使えない」ことではなく、「今日このkeyをどのツール、どのendpoint、どのアカウントで使うのか」が混乱することだからだ。

ローカルプロキシとフェイルオーバー

設定ファイルを書き換えるだけでなく、CC Switch はローカルプロキシモードも提供する。

この機能の要点は次の通りだ。

Providerのホットスイッチ。
フォーマット変換。
自動フェイルオーバー。
サーキットブレーカー。
Providerのヘルスチェック。
リクエスト補正。

簡単に言えば、対象ツールに設定を書き込むだけでなく、間にローカルプロキシ層を挟み、異なるツールがそのプロキシ経由でモデルサービスにアクセスできるようにする。

これは複数Providerを使うユーザーにとって便利だ。あるサービスが落ちたら別のものへ切り替える。あるモデルが高ければ安いものに変える。リクエスト形式が合わない場合も、プロキシ層で適配できる。

MCP、Prompts、Skills

CC Switch の重要な第二層の機能は、MCP、Prompts、Skillsの一元管理だ。

MCP

複数アプリ間でMCP serverを管理できる統一MCPパネルを提供し、双方向同期とDeep Linkインポートにも対応する。

これはMCPを使っているユーザーにはかなり実用的だ。MCP serverが増えるほど、設定は複数のクライアントに散らばりやすい。統一パネルがあれば、重複設定を減らし、移行もしやすくなる。

Prompts

Prompts部分はMarkdown編集に対応し、異なるツール間で対応するファイルを同期できる。例えば次のようなファイルだ。

CLAUDE.md
AGENTS.md
GEMINI.md

これらは本質的にはAgent向けのプロジェクト説明書だ。一元管理できれば、チームルール、プロジェクトの約束事、グローバルプロンプトをより保守しやすくなる。

Skills

SkillsはGitHubリポジトリやZIPファイルからワンクリックでインストールできる。カスタムリポジトリ管理、シンボリックリンク、ファイルコピーにも対応する。

Claude Code、Codex、OpenClawのようなツールを同時に使う場合、Skillsは複数ディレクトリに散らばったファイル群になりやすい。CC Switch はそれらを集約し、保守コストを下げる。

セッションとワークスペース

READMEではSession ManagerとWorkspace関連の機能にも触れられている。

複数アプリ内のセッション履歴を閲覧、検索、復元できる。AIコーディングツールを長期的に使う人にとって、セッション管理はかなり重要だ。価値のある文脈、デバッグ過程、案の比較が、古い会話の中に埋もれていることが多いからだ。

さらにOpenClaw向けにWorkspace editorも提供し、AGENTS.md、SOUL.md などのagentファイルを編集でき、Markdownプレビューも備える。

これは CC Switch が単なる「key切り替えツール」ではなく、AI Agentワークステーションの方向へ拡張していることを示している。

クラウド同期とデータ保存

CC Switch はDropbox、OneDrive、iCloud、NAS、WebDAV経由でProviderデータを同期できる。

ローカルのデータ保存場所も明確だ。

データベース：~/.cc-switch/cc-switch.db
ローカル設定：~/.cc-switch/settings.json
自動バックアップ：~/.cc-switch/backups/
Skills：~/.cc-switch/skills/
Skillバックアップ：~/.cc-switch/skill-backups/

主要データソースとしてSQLiteを使い、原子的な書き込みと自動バックアップを重視している。目的は、切り替えや書き込みの際に設定ファイルが壊れることを避けることだ。

この設計はヘビーユーザーにとって重要だ。設定管理ツール自体が設定を書き壊した場合、影響を受けるのはすべてのAIコーディングツールだからだ。

インストール方法

CC Switch はTauri 2ベースのクロスプラットフォームデスクトップアプリだ。

おおよそのシステム要件は次の通り。

Windows：Windows 10以降
macOS：macOS 12 Monterey以降
Linux：Ubuntu 22.04+、Debian 11+、Fedora 34+などの主要ディストリビューション

Windowsユーザーは .msi インストーラーまたはポータブル版の圧縮パッケージをダウンロードできる。

macOSユーザーはHomebrewでインストールできる。

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

更新は次の通り。

`1`	`brew upgrade --cask cc-switch`

Linuxユーザーは .deb、.rpm、AppImageを選べる。Arch Linuxユーザーは paru -S cc-switch-bin でもインストールできる。

2026年5月6日時点で、リポジトリページに表示されている最新releaseは CC Switch v3.14.1 で、公開日は2026年4月23日だ。

技術スタック

リポジトリ構成を見ると、CC Switch は典型的なTauriデスクトップアプリだ。

フロントエンド：React 18、TypeScript、Vite、TailwindCSS、TanStack Query、shadcn/ui
バックエンド：Tauri 2、Rust、SQLite、Tokio
テスト：Vitest、MSW、Testing Library

主な設計パターンは次の通り。

SQLiteをSingle Source of Truthとして使う。
デバイス単位のローカル設定はJSONで保存する。
切り替え時に対象ツールのlive configへ書き込む。
現在のProviderを編集する際はlive configから回填する。
一時ファイルとrenameを使って原子的に書き込む。
データベース接続をロックし、並行書き込み問題を避ける。

この構成から、プロジェクトは単なるスクリプトではなく、長期利用を前提にしたデスクトップツールとして設計されていることがわかる。

誰に向いているか

CC Switch が向いているのは次のようなユーザーだ。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawを同時に使う。
公式アカウント、サードパーティrelay、ローカルモデル、チームProviderを頻繁に切り替える。
すでにMCPを多用し始めている。
CLAUDE.md、AGENTS.md、GEMINI.md を統一して保守したい。
Skillsを頻繁にインストール、テスト、移行する。
複数ツールのセッション履歴や利用状況を見たい。

もしAIコーディングツールを1つだけ使い、常に公式ログインで、Provider、MCP、Skillsをあまり触らないなら、価値はそれほど明確ではないかもしれない。

しかしすでに「複数ツール、複数アカウント、複数Provider、複数プロジェクト」の状態に入っているなら、細かな設定作業をかなり減らせる。

注意点

この種のツールは便利だが、境界も意識する必要がある。

第一に、複数のAI CLI設定を管理するため、このツールとその書き込みロジックを信頼できるか確認する必要がある。

第二に、API key、relay endpoint、MCP serverはいずれも機微な設定だ。クラウド同期を有効にする前に、同期先ディレクトリやWebDAVサービス自体が安全で信頼できるか確認したい。

第三に、Providerを切り替えた後、多くのツールでは変更を反映するためにターミナルやCLIの再起動が必要になる。READMEでは、Claude CodeはProviderデータのホットスイッチに対応するとされているが、他のツールでは通常再起動が必要だ。

第四に、公式ログインへ戻す場合は、プロジェクト説明に沿ってofficial providerを追加し、対応するツールのログインフローを改めて実行するのがよい。

まとめ

CC Switch の価値は、また別のAIコーディングツールを作ったことではない。AIコーディングのエコシステムが、すでに複数ツール共存の段階に入ったという現実を認めている点にある。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawにはそれぞれ独自の設定システムがあり、MCP、Skills、Prompts、Providerも急速に広がっている。設定を手作業で変え続けるやり方は、いずれ負担になる。

CC Switch はこれらを1つのデスクトップアプリに集約し、Providerの切り替え、MCPの同期、Skillsの管理、プロンプトファイルの保守、セッション確認をより簡単にする。AIコーディングを重く使う人にとって、この種のツールは「任意の小道具」から「日常の基盤」へ変わっていく可能性が高い。

参考資料

farion1231/cc-switch

Codex App 入門ガイド：インストール、サンドボックス、並列タスク、Skills、MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App は、AI コーディング向けのタスクワークスペースと考えると分かりやすい。従来の IDE でも、単なるチャット画面でもなく、マルチタスク、プロジェクト管理、サンドボックス権限、Git、クラウド実行、プラグイン、Skills、MCP、自動化を 1 つのインターフェイスにまとめている。

すでに Codex CLI、Claude Code、Cursor、その他の coding agent を使っているなら、Codex App の最も注目すべき点は、「複数の agent を並列に動かす」ことをより明確なデスクトップワークフローにしている点だ。

Codex App が向いていること

Codex App の価値は、AI に質問へ答えさせることではなく、プロジェクトディレクトリ内で継続的にタスクを実行させることにある。

コードを編集し、コマンドを実行し、開発サーバーを起動する。
複数のプロジェクトと複数のタスクを管理する。
ローカルまたはクラウドで長いタスクを実行する。
プラグイン、Skills、MCP を呼び出して能力を拡張する。
Git、worktree、PR で変更を管理する。

OpenAI も Codex App を複数の coding agent を管理するためのインターフェイスとして位置付けている。複数のコードタスクを同時に進める人に向いており、特にフロントエンドページ、スクリプト、小規模アプリ、ドキュメント整理、自動化ワークフローと相性がよい。

インストール前の準備

Codex App を使う前に、次の 3 つの基本ツールを用意しておくとよい。

Git
Node.js
VS Code または普段使っている IDE

Codex App は macOS と Windows をサポートしている。インストール後は ChatGPT アカウントでログインする。初回起動時には、プログラミングや日常作業など主な利用シナリオを選択できる。Codex は選択内容に応じて一部のプラグインと Skills を事前に入れ、後から設定やプラグインマーケットで調整できる。

Windows と macOS の主な機能はおおむね同じだが、一部のコンピューター自動化機能はプラットフォームやプラグイン対応に依存する。実際には現在のバージョンに表示される内容を基準にする。

インターフェイス構造：プロジェクト、タスク、チャット

Codex App は典型的な 3 カラム構成になっている。

左側：プロジェクト、タスク、過去のチャット、プラグイン、自動化への入口。
中央：現在のチャット画面。
右側：ファイル、ブラウザー、ターミナル、実行結果などの多機能領域。

1 つのプロジェクトは通常、ローカルフォルダーに対応する。同じプロジェクト内で複数のチャットを開くことも、複数のプロジェクトを同時に開き、異なる agent に並列で作業させることもできる。

タスクリストには状態が表示される。

実行中：agent がまだ作業している。
承認待ち：権限、ネットワーク、依存関係インストール、高リスク操作の確認が必要。
完了：タスクが終了し、結果確認や追加質問ができる。

複数のターミナルを行き来するより直感的で、複数の AI タスクを同時に管理しやすい。

サンドボックスと権限管理

Codex App の権限体系はサンドボックスを中心にしている。デフォルトでは、現在のプロジェクトフォルダーが agent の主な作業範囲になる。

一般的な権限境界は次の通り。

プロジェクトディレクトリ内のファイルを読み書きできる。
デフォルトではプロジェクト外のファイルを自由に変更できない。
ネットワークや高リスクコマンドはデフォルトで制限される。
権限昇格が必要な場合はユーザーに承認を求める。

実用的なのは「自動レビュー」モードだ。低リスク操作は自動で許可し、高リスク操作はユーザー確認に回す。これにより頻繁なポップアップを減らしつつ、危険な操作が知らないうちに実行されることを防げる。

「完全アクセス」は慎重に使うべきだ。agent が何をする必要があるか明確で、プロジェクトが Git でバックアップされ、重要ファイルにも別のバックアップがある場合に向いている。日常的に常時有効にするのはおすすめしない。

コンテキスト、モデル、利用枠

Codex App は現在のチャットのコンテキスト使用状況を表示する。会話が長く、履歴が多いほど、モデルが処理するコンテキストも大きくなる。

実用的な習慣は次の通り。

1 つのタスクが終わったら新しいチャットを開く。
長い会話は手動圧縮できるが、圧縮を万能の記憶と考えない。
複雑なタスクでは、目的、境界、受け入れ条件を先に明確にする。
関係ない大量のログ、エラー、ファイルを一度に詰め込まない。

モデル選択では、タスクの複雑さに応じて推論強度を調整する。簡単な修正、文章整理、反復タスクは必ずしも最高性能モデルを必要としない。アーキテクチャ移行、難しいバグ、複数ファイルにまたがるリファクタリングには、より強いモデルが向いている。

高速モードがある場合は、通常より利用枠を多く消費する点に注意する。急ぎの時には有効だが、日常のデフォルトにする必要はない。

画像生成とマルチモーダル入力

Codex App は画像やファイルをコンテキストとして受け取ることができ、適切な場面では画像生成能力も呼び出せる。

これはフロントエンドやコンテンツ系プロジェクトで役立つ。たとえば Codex に次のことを依頼できる。

スクリーンショットをもとにページスタイルを修正する。
Web ページ内の不適切な画像を置き換える。
商品画像、カルーセル画像、ページ素材を生成する。
UI スクリーンショットから修正すべき位置を指摘する。

より効率的なのは、「もっときれいにして」とだけ言うのではなく、スクリーンショットを使って具体的な問題を示すことだ。たとえば「このカードの余白が大きすぎる」「この画像はサービスシーンに合っていない」「地図エリアをもっと分かりやすくする」といった指示がよい。

Steer：実行中に方向を修正する

Steer は、実行中に方向を引き受ける機能と考えるとよい。agent がすでに作業を始めた後で、方向を誤解していると気づいた場合、すべて終わるまで待ってから直す必要はない。

この機能を使うと、新しい指示を現在の実行フローに挿入し、Codex に進路を修正させられる。

Steer が向いている場面は次の通り。

agent が要件を誤解した。
生成されたページのスタイルが明らかに違う。
実行中の案が重すぎる、またはコストが高すぎる。
途中で重要な制約を追加する必要がある。

通常はデフォルトのキュー動作を維持し、本当に介入が必要な時だけ手動で Steer を使うのがよい。通常のタスクを乱さず、重要な場面で方向を戻せる。

計画モードと内蔵ブラウザー

複雑なタスクでは、まず計画モードを使うのがよい。計画モードでは Codex はすぐにコードを変更せず、先に計画を出し、必要ならカード形式で重要な選択肢を確認する。

計画モードに向いているタスクは次の通り。

React プロジェクトを Next.js に移すようなフレームワーク移行。
大規模リファクタリング。
データベース、認証、デプロイを含む機能。
技術方針がまだ固まっていない要件。

Codex App の右側領域では内蔵ブラウザーを開き、ローカル開発サーバーをプレビューできる。ページ上で注釈を付け、具体的な UI 位置に応じて Codex に修正させられる。この「ページを見る、位置を指す、AI に直させる」流れは、純粋な文章説明よりフロントエンドデバッグに向いている。

Git、IDE、コードのロールバック

Codex App は完全な IDE ではない。コード閲覧や注釈はできるが、手作業での編集は VS Code、Cursor、Windsurf などの IDE の方が向いている。

Codex プロジェクトでは早めに Git を初期化しておくとよい。

Codex に .gitignore を作成または確認させる。
使える状態になったら一度コミットする。
大きな変更の前にはクリーンなコミット地点を作る。
不満があれば Git でコードを戻す。

チャット履歴だけを戻しても、コードは自動では戻らない。安定した方法は、チャットを適切な地点へ戻し、コードは Git commit hash で対応する状態へ戻すことだ。

Worktree：複数方向の並列開発

git worktree は Codex App で並列 agent を使う際に非常に相性がよい。

本質的には、同じリポジトリから複数の独立した作業ディレクトリを作り、それぞれを別ブランチに対応させる仕組みだ。これにより、異なる agent を別フォルダーで同時に作業させても互いに上書きしない。

典型的な使い方は次の通り。

1 つの worktree で顧客レビューコンポーネントを改善する。
1 つの worktree で店舗情報と地図レイアウトを調整する。
2 つのタスクが終わったらそれぞれ main へマージする。
マージ後に一時 worktree を削除する。

同じディレクトリで複数 agent に同時編集させるよりずっと安定する。競合が出た場合も、通常の Git フローで review と merge を行えばよい。

クラウド実行環境

Codex はローカルだけでなく、クラウド環境にもタスクを委任できる。

クラウド実行が向いている場面は次の通り。

外出中で手元にスマートフォンしかない。
agent に長いタスクをバックグラウンドで実行させたい。
コードがすでに GitHub に同期されており、Codex にリモートリポジトリを変更させたい。
PR 形式で変更を確認してマージしたい。

典型的な流れは、ローカルコードを GitHub に push し、Codex がクラウド環境でリポジトリを取得してタスクを実行し、変更を生成し、PR または diff としてレビューに出すというものだ。

ローカルで開発を続ける場合は、リモートの最新変更を取り込むことを忘れない。

記憶システム：AGENTS.md を整える

新しいチャットはデフォルトでは完全な履歴記憶を持たない。プロジェクトが複雑になると、毎回背景を説明し直すのは非効率だ。

最も汎用的な方法は、プロジェクトルートに AGENTS.md を置くことだ。このファイルには次の内容を記録できる。

プロジェクトの目的と主要技術スタック。
よく使うコマンド。
ディレクトリ構成。
コードスタイルと命名規則。
禁止事項、たとえばファイルの一括削除を避けること。
テスト、ビルド、デプロイルール。

Codex にプロジェクトを読ませて AGENTS.md の初版を生成させ、人間が確認する方法もよい。複雑なプロジェクトでは、このファイルを維持する価値が高い。

グローバルルールは慎重に使う。全プロジェクトに共通する安全制約、たとえば「ディレクトリを再帰的に削除しない」「破壊的操作の前に確認する」などに向いている。特定プロジェクトの細部をグローバルルールに入れると、他のプロジェクトを汚染する。

プラグインと自動化

プラグインは、GitHub、Gmail、Google Drive、データベース、デプロイ基盤など外部サービスを Codex に接続する。

価値はコピー&ペーストを減らすことだ。たとえば Codex に次のことをさせられる。

GitHub リポジトリの star 推移を確認する。
メール内容を整理して自分に送る。
定期的なチェックを実行する。
結果を要約として書く。

自動化は繰り返しタスクに向いている。たとえば毎週金曜午後にリポジトリデータを確認し、メールレポートを送るような用途だ。簡単な自動化タスクには最高性能モデルは不要で、軽量モデルで十分なことが多い。

Skills：ワークフローを再利用可能な能力にする

Skills は Codex の「専門的な手順書」だ。一回限りのプロンプトではなく、ある種類のタスクの流れ、規則、スクリプト、注意点をまとめ、Codex が後で安定して再利用できるようにする。

主な入手元は次の 3 種類。

公式 Skills。
サードパーティ Skills。
自分で書いた Skills。

Skill 化に向いている作業は次の通り。

字幕を図解付きノートにする。
会社の形式で週報を書く。
画像や文書を一括処理する。
固定形式のコードレビュー。
特定フレームワークのプロジェクト初期化。

同じプロンプトを何度もコピーしているなら、Skill にする価値がある。

MCP：外部ツールとデータベースを接続する

MCP は、大規模モデル向けの標準化されたツールプロトコルと考えられる。MCP を通じて、Codex は外部サービスを呼び出し、より具体的なタスクを完了できる。

たとえば Supabase を接続すると、Codex に次のことをさせられる。

データベーステーブルを作成する。
データベーススキーマを読む。
バックエンドエンドポイントを変更する。
フロントエンドフォームをデータベースへ送信する。
データベース状態に基づいて問題をデバッグする。

これは強力だが、権限境界に注意が必要だ。データベース、本番環境、デプロイ基盤、メールアカウントは高リスク資源である。初回接続時はテストプロジェクトと低権限アカウントを使うのがよい。

デプロイプラグイン

デプロイ基盤のプラグインを使うと、Codex がビルドと公開を直接完了できる。たとえばフロントエンドプロジェクトを Netlify のような平台へデプロイできる。

この種のプラグインは、小規模サイト、プロトタイプ、社内ツール、デモプロジェクトに向いている。実際に使う時は次の点に注意する。

デプロイ前にローカルビルドを実行する。
環境変数をコードへ直接書かない。
公開後にページが正常に開くか確認する。
本番プロジェクトでは人間の review を残す。

AI は公開フローをつなぐ助けになるが、デプロイ権限は慎重に管理すべきだ。

コンピューター自動化

対応プラットフォームとプラグイン環境では、Codex がブラウザーやデスクトップアプリを操作し、RPA に近いタスクを実行できる。

例：

チャットアプリを開いてメッセージを準備する。
プロジェクトボードを閲覧し、タスク状態を要約する。
英語のブリーフを生成する。
確認後、指定相手へ送信する。
この流れをスケジュール自動化にする。

この機能は想像力を広げるが、最も強い安全境界も必要だ。メッセージ送信、メール送信、フォーム送信、支払い、データ削除に関わる操作では、人間の確認を残すべきだ。

使い方の提案

Codex App の正しい使い方は、すべてを一度に完全自動化させることではない。タスクを明確に分解し、制御された環境で効率よく実行させることだ。

おすすめの習慣：

すべてのプロジェクトで最初に Git を初期化する。
複雑なタスクでは計画モードを使う。
並列タスクでは worktree を優先する。
プロジェクトルールを AGENTS.md に書く。
高リスク操作では人間の確認を残す。
繰り返しワークフローを Skill や自動化にする。
プラグインと MCP はまずテスト環境で検証する。

参考資料

まとめ

Codex App の本質は「もう 1 つの AI チャット画面」ではない。AI コーディングを管理可能なワークスペースにすることだ。ローカルプロジェクト、クラウドタスク、Git、worktree、プラグイン、Skills、MCP、自動化をつなげられる。

うまく使う鍵は、「任せること」と「制御すること」のバランスを取ることだ。小さなタスクは大胆に Codex に渡し、複雑なタスクはまず計画させ、高リスク操作は必ず確認する。そうすれば Codex は、コードを書く助手から、長期的に協力できるエンジニアリングツールへ近づく。

ChatGPT と Codex がログイン時に電話番号認証を求める理由

Wed, 06 May 2026 00:09:41 +0800

最近、ChatGPT アカウントは登録済みなのに、ChatGPT や Codex にログインしようとすると再度電話番号の認証を求められるケースが報告されている。特に Codex ではこの表示に戸惑うユーザーが多い。アカウント登録はできたのに、なぜツールにログインする際に電話番号が必要になるのか。

この問題は通常、アカウントのリスク制御、無料枠の悪用、ネットワーク環境、アカウントセキュリティポリシーに関係している。以下に主な原因と対処の考え方を整理する。

電話番号認証が要求される理由

最も直接的な原因はリスク制御の強化である。

Codex が一般ユーザーに開放されると、無料枠は多くの正規ユーザーを惹きつける一方で、大量登録や無料枠の搾取も呼び込む。登録ボットでアカウントを大量生成し、無料枠を消費する行為が増えれば、プラットフォームは認証ポリシーを引き締めざるを得なくなる。

ユーザー側から見える結果は、以前はメールまたはサードパーティログインだけで済んでいたアカウントが、ChatGPT や Codex へのアクセス時に突然電話番号の追加入力を求められる、というものだ。

これは必ずしも個別のアカウントに問題があるとは限らず、よりリスクの高いログイン環境と判定された可能性もある。例えば：

多数のユーザーが共有するネットワーク出口を使用している。
現在のIP帯域が登録や異常ログインに頻繁に使われている。
登録直後のアカウントで、リソース消費の大きいツールにすぐアクセスした。
デバイス、地域、ネットワークが頻繁に変わる。
無料アカウントの利用パターンが大量アカウントのそれと似ている。

最近アカウントの異常、ログイン制限、誤BANを経験した場合、ネットワーク環境が巻き添えでフラグ付けされた可能性もある。特に多人数共有のノードはリスクが顕著に高い。

Codex でより発生しやすい理由

Codex は通常のチャットと異なり、開発ツールに近く、より多くのリソースを消費する可能性がある。また、無料枠を狙う大量アカウントにとっても格好の標的になりやすい。

したがって、同じアカウントが通常の ChatGPT ページでは問題なく見えても、Codex のログインフローで電話番号認証がトリガーされるのは不思議ではない。製品の入り口ごとに異なるリスク判断が適用されると考えればよい。

通常のユーザーに対しては、この種の認証は個人を困らせるためではなく、大量登録と無料枠の悪用を抑制するためのものだ。ただし、ネットワーク環境がクリーンでない場合は巻き添えを食らうこともある。

対処法1：Plus へのアップグレード

ChatGPT や Codex を長期利用するなら、最もシンプルな対処法は ChatGPT Plus へのアップグレードである。

実際の使用感から言えば、有料アカウントは無料アカウントよりも無料枠悪用関連のリスク制御に引っかかりにくい。Plus アカウントは Codex、ChatGPT の上位モデル、その他高頻度機能の安定利用にも適している。

ただし、Plus にアップグレードすれば認証が永久に発生しなくなるわけではない。アップグレード後も電話番号を求められる場合、原因はやはりネットワーク環境であることが多い。

その場合は以下を優先的に確認するとよい：

多数のユーザーが共有するネットワークを使っていないか。
出口IPが頻繁に切り替わっていないか。
低品質なプロキシや公共ノードを長期間使っていないか。
同一ネットワーク下で多数の OpenAI アカウントがログインしていないか。

可能であれば、より安定したクリーンなネットワーク環境に切り替えてからログインする方が、何度もリトライするより効果的だ。

対処法2：ネットワーク環境の確認

ログイン認証の問題の多くは、一見アカウントの問題に見えて、本質的にはネットワークの問題である。

特定の出口IPが多数のユーザーに共有されていたり、大量登録、異常ログイン、自動化リクエストに使われた履歴がある場合、フラグ付けされやすい。その場合、正規のユーザーであっても ChatGPT や Codex へのログイン時に追加認証を要求されることがある。

以下の観点から確認できる：

より安定したネットワーク環境に切り替える。
公開された安価な多人数共有ノードの使用を避ける。
短期間での頻繁な地域切り替えを最小限に抑える。
同じブラウザで複数アカウントを頻繁に切り替えない。
プロキシを使う場合は、品質が安定し悪用の少ない回線を優先する。

サードパーティのネットワーク品質検出ツールで現在のIPのリスク状況を確認することもできるが、検出結果はあくまで参考であり、OpenAI 内部の判断を完全に代表するものではない。

対処法3：指示に従って電話番号認証を完了する

システムが明示的に電話番号認証を要求する場合、最も確実な方法は指示に従って認証を完了することである。

長期的に認証コードを受信できる自分自身の番号を使うことを推奨する。そうすれば、後日アカウントのセキュリティ確認、復旧、異常通知が必要になった際にも対応できる。

重要なアカウントを出所不明、多人共有、または長期間使えない番号に紐付けることは推奨しない。短期的には認証を通過できても、長期的にはアカウント復旧、セキュリティ監査、二次認証のリスクを招く。

仕事用アカウント、チームアカウント、または長期利用の開発用アカウントを使っている場合は、管理不能な一時的な番号の使用を特に避けるべきだ。アカウントの安全は一時的な手間より重要である。

Plus アップグレード時の注意点

Plus へのアップグレードを予定している場合、事前にいくつか確認しておくとよい：

アカウント自体が正常にログインできること。
現在のネットワーク環境が安定しており、頻繁に地域が切り替わらないこと。
支払い方法が信頼できるものであること。出所不明の代理決済は使わない。
アップグレード後は決済記録とアカウントのメールを保管すること。
アカウントを複数人で共有しないこと。

アカウントの問題の多くは Plus 自体にあるのではなく、アップグレード前後のネットワーク、支払い、共有の習慣にある。アカウントを長期間複数人で共有し、頻繁に別の場所からログインし、頻繁に環境を切り替えると、有料であってもセキュリティ認証がトリガーされる可能性がある。

たまに試すだけであれば、無料アカウントでも問題ない。しかし Codex を日常の開発ツールとして使っているなら、Plus の方が長期利用に適している。

無料枠の搾取は推奨しない

Codex のようなツールの無料枠は、もともと正規ユーザーが体験・試用するためのものだ。大量のアカウントが無料枠を継続的に消費すれば、プラットフォームは最終的にリスク制御の強度を上げ続けるしかなくなる。

その結果、正規ユーザーも影響を受ける。ログインは面倒になり、認証は増え、誤BANは増え、アカウントの利用コストは上昇する。

実際に Codex をコーディング、プロジェクト改修、エンジニアリングタスクに使っている人にとっては、リスク制御を回避することに時間を費やすよりも、アカウントとネットワーク環境をクリーンに整える方が価値がある。長期的に見れば、新しいアカウントを繰り返し登録し、ノードを切り替え、認証問題に対処するよりもずっと楽だ。

まとめ

ChatGPT や Codex がログイン時に電話番号認証を要求するのは、通常アカウントのリスク制御、無料枠の悪用、ネットワーク環境のリスクに関係している。必ずしもアカウント自体が違反しているとは限らないが、現在のログイン環境またはアカウント状態がより高いレベルの認証をトリガーしたことを示している。

対処の順序はシンプルだ：

まずネットワーク環境を確認し、多人共有や高リスクの出口を避ける。
長期利用の場合は Plus へのアップグレードを検討する。
システムが電話番号認証を要求する場合は、自分が長期間管理できる番号で完了させる。
大量登録、アカウント共有、頻繁なログイン環境の切り替えを避ける。

AI ツールを安定して使うための本質は、認証を回避し続けることではなく、アカウント、ネットワーク、利用方法をできる限り正常に保つことだ。そうすることでログインの手間を減らし、後日の巻き添えリスクも下げられる。

OpenAI が Advanced Account Security を発表：ChatGPT と Codex アカウントに強力な保護層を追加

Fri, 01 May 2026 06:15:29 +0800

OpenAI は 2026 年 4 月 30 日、ChatGPT アカウント向けの任意の高度なセキュリティ設定として Advanced Account Security を発表した。

主な対象は二つのユーザー層だ。一つは、ジャーナリスト、選挙で選ばれた公職者、政治的反体制派、研究者など、標的型攻撃を受けやすい人たち。もう一つは、ChatGPT と Codex のアカウントにより強い保護を加えたい、セキュリティ意識の高いユーザーである。

この機能を有効にすると、ChatGPT だけでなく、同じログインアカウントでアクセスする Codex も保護される。

なぜ ChatGPT アカウントにより高い安全性が必要なのか

現在、多くの人が ChatGPT をますます私的で、リスクの高い仕事に使うようになっている。

一つの ChatGPT アカウントには、次のようなものが含まれる可能性がある。

個人的な相談や長期的な会話
業務文書とプロジェクトの文脈
接続済みのツールとワークフロー
Codex 内のコードや開発タスク
企業、研究、セキュリティ関連の資料

アカウントが乗っ取られた場合、被害はチャット履歴の漏洩だけでは済まない。攻撃者は接続済みツールへアクセスしたり、機密性の高い文脈を見たり、進行中の作業に干渉したりする可能性がある。

そのため、今回 OpenAI が導入したのは単なるログインオプションではなく、より厳格なアカウント保護のセットである。

Advanced Account Security に含まれる保護

OpenAI はこの機能を、ChatGPT ウェブ版アカウントの Security 設定に配置している。ユーザーは任意で有効にできる。

有効にすると、いくつかの面でアカウントの安全性が高まる。

第一に、ログイン方法が強化される。

Advanced Account Security は passkeys または物理セキュリティキーを要求し、パスワードベースのログインを無効にする。目的は、フィッシングに強いログイン方法を、それを必要とする人たちの標準にすることだ。

第二に、アカウント復旧がより厳格になる。

従来のアカウント復旧は、多くの場合メールやSMSに依存している。攻撃者がユーザーのメールアカウントや電話番号を支配した場合、それを使ってアカウントをリセットできる可能性がある。このリスクを下げるため、Advanced Account Security はメールと SMS による復旧を無効化し、バックアップ passkeys、セキュリティキー、復旧キーなど、より強力な復旧方法を使う。

ここには重要な代償がある。有効にした後は、アカウント復旧がユーザー自身による復旧手段の管理に大きく依存する。OpenAI は、この機能を有効にしたユーザーが復旧手段を失った場合、OpenAI Support はアカウント復旧を支援できないと明示している。

第三に、セッションが短くなり、管理がより明確になる。

OpenAI はログインセッションを短くし、端末やアクティブなセッションが侵害された場合の露出時間を減らす。ユーザーはログイン通知も受け取り、複数デバイスでのアクティブセッションを確認・管理できる。

第四に、学習除外が自動になる。

機密情報を扱う人にとって、会話をモデル学習に使わせないことは重要なプライバシー設定である。Advanced Account Security を有効にすると、この設定が自動的に適用される。つまり、これらのアカウントの会話は OpenAI モデルの学習に使われない。

Yubico と連携して物理セキュリティキーを広げる

OpenAI は、Yubico と提携してカスタムのセキュリティキーセットを提供することも発表した。

含まれるのは次の二つだ。

YubiKey C Nano：ノートPCに挿したまま使うことを想定し、日常のログイン負担を減らす
YubiKey C NFC：バックアップとして、またノートPCとモバイルデバイスの両方で使いやすい

OpenAI は、ユーザーが他の FIDO 準拠の物理セキュリティキーや、ソフトウェア passkeys を使うこともできるとしている。

これは、Advanced Account Security が特定のハードウェアに縛られているわけではなく、フィッシングに強い認証方式を中心に設計されていることを示している。

Trusted Access for Cyber ユーザーには有効化が求められる

OpenAI はさらに、Trusted Access for Cyber の個人メンバーが、より高性能で許容範囲の広いサイバーセキュリティ向けモデルにアクセスする場合、2026 年 6 月 1 日から Advanced Account Security の有効化が必要になると述べている。

組織ユーザーは別の方法でも要件を満たせる。自社のシングルサインオンのワークフローが、すでにフィッシング耐性のある認証を採用していると証明する方法だ。

この方針は妥当だ。モデル能力が強くなるほど、アカウント保護も強くする必要がある。特にサイバーセキュリティ研究、脆弱性分析、レッドチームといった場面では、アカウント自体が高価値の標的になる。

誰が有効にすべきか

この機能は、必ずしもすべての人に向いているわけではない。

普通の会話に使うだけで、より厳格なアカウント復旧の複雑さを負いたくない場合は、しばらく様子を見るのもよい。

ただし、次のようなユーザーは真剣に検討する価値がある。

ChatGPT で機密性の高い業務資料をよく扱う人
Codex でプライベートコードリポジトリを扱う人
ジャーナリスト、公共政策関係者、研究者、企業幹部などの高リスクユーザー
サイバーセキュリティ従事者
すでに passkeys や物理セキュリティキーに慣れている人
フィッシング、SMS乗っ取り、メールアカウント乗っ取りを特に警戒している人

有効にする前に、バックアップ passkey、セキュリティキー、復旧キーを用意し、それらが適切に保管されていることを確認したほうがよい。そうしないと、安全性は高まる一方で、アカウント復旧の難度も明らかに上がる。

AI プロダクトにとって何を意味するのか

Advanced Account Security はモデル能力の更新ではない。しかし、AI プロダクトがより高リスクな利用段階に入っていることを反映している。

ChatGPT と Codex がワークフロー、コード、文書、企業向けコネクター、長期的な文脈を担い始めると、アカウントはもはや「チャットツールにログインする入口」ではなく、AI 作業環境の鍵になる。

こうしたプロダクトが個人の作業台に近づくほど、アカウントセキュリティ、復旧メカニズム、セッション管理、学習データ制御は重要になる。

OpenAI が passkeys、物理セキュリティキー、復旧制限、セッション管理、学習除外を一つの設定にまとめた方向性は妥当だ。高リスクユーザーが明確な入口から、機密性の高い作業に適したレベルまでアカウント保護を引き上げられる。

まとめ

Advanced Account Security は、ChatGPT と Codex の高セキュリティモードと理解できる。

より強いログイン、より厳格な復旧、短いセッション、ログイン通知、自動的な学習除外によって、アカウント乗っ取り後のリスクを下げる。その代わり、ユーザーは自分の復旧手段をより慎重に管理する必要がある。有効化後は従来のメールや SMS による復旧が使えず、OpenAI Support も代わりに救済できないからだ。

すでに ChatGPT や Codex を重要な仕事に使っているなら、特にプライベートコード、機密文書、高リスクな立場に関わる場合、この機能は注目に値する。

参考リンク：

Introducing Advanced Account Security - OpenAI

mattpocock/skills：AI コーディング Agent 向けの実用スキル集

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills は、Matt Pocock が公開している AI コーディング agent skills のコレクションです。

これは完全なアプリケーションでも、新しいチャットクライアントでもありません。AI コーディングアシスタントに使わせるための作業スキル集です。考え方は実用的です。AI コーディングでよく起こる問題を小さなスキルに分解し、Agent が適切なタスクで呼び出せるようにします。毎回巨大なプロンプトで無理に支えるのではありません。

Claude Code、Codex、Cursor、または類似の AI コーディングツールをよく使うなら、この種の skills は注目する価値があります。AI コーディング体験に本当に影響するのは、「モデルがコードを書けるか」だけではなく、自分の作業方法に沿ってタスクを進められるかだからです。

解決する問題

AI コーディングアシスタントは強力ですが、問題も起こしやすいです。

よくある状況は次のとおりです。

要件を理解する前にコード変更を始める
一度に多すぎるファイルを変更する
説明は多いが、実際に有用な行動が少ない
エラー後に場当たり的に試す
テストやチェックをすぐに実行しない
プロジェクト内の既存パターンを無視する
タスク完了のために不要な抽象を導入する
コードを書いた後に本当にリスクを review しない

これらは必ずしもモデル能力不足ではありません。ワークフローが十分に制約されていないことが原因の場合も多いです。

mattpocock/skills の価値は、こうした失敗パターンを再利用可能な操作方法に分解し、Agent が場面に応じてより経験あるエンジニア協作者のように振る舞えるようにすることです。

Skills とは何か

AI Agent の文脈では、skill は再利用可能なタスク説明、作業方法、専門的なフローとして理解できます。

必ずしもコードプラグインである必要はなく、外部サービスを呼び出す必要もありません。多くの場合、skill は明確なルールセットです。

いつ使うか
まず何をするか
何をしないか
何を出力するか
タスク完了をどう判断するか

これは通常のプロンプトテンプレートに似ていますが、粒度は「タスク能力」に近いものです。

通常のプロンプトテンプレートは、ユーザーが毎回一時的にコピーして貼り付けるものです。Skills は agent ツールボックスの一部として、Agent がタスクに応じて適切なフローを選ぶ形に向いています。

小さく組み合わせ可能である理由

README では、これらの skills が小さく組み合わせ可能であることを強調しています。

これは重要な方向性です。

1 つの skill がすべてを担当しようとすると、すぐに新しい巨大プロンプトになります。長く、曖昧で、保守しにくいものです。小さなスキルの利点は境界が明確なことです。

たとえば 1 つの skill は次のようなことだけに集中できます。

先に計画する
TypeScript エラーを修正する
テストを実行し、結果に基づいて修正する
コード review を行う
プロジェクト規約を要約する
プロンプトを改善する
不要な抽象を取り除く

これらのスキルはタスクに応じて組み合わせられます。単純なタスクなら 1 つ、複雑なタスクなら複数をつなげます。

これは実際のエンジニアリング作業に近いです。すべての問題を同じフローで処理するのではなく、問題に応じてツールを選びます。

エンジニアの制御を残す

このリポジトリの重要な方向性の一つは、エンジニアが制御権を持ち続けることです。

AI コーディングは、2 つの極端に寄りやすいです。

1 つ目は完全に手動です。AI は数行のコードを書く手伝いをするだけで、コンテキスト、計画、検証はすべて自分が監視します。

2 つ目は完全に放任です。タスクを Agent に投げ、大きく変更させ、最後にレビューしづらい diff と向き合います。

skills はその中間に、より安定した位置を作ります。

AI により多くの反復フローを任せつつ、ルールで制限します。

タスクを理解してから手を動かす
関連ファイルを読んでから変更する
変更範囲を制御可能にする
不確実な場合は報告する
変更後に検証する
見せつけるために無関係なコードをリファクタリングしない

これは AI を弱めるのではありません。AI の行動を人間がレビューし、引き継ぎやすくするものです。

アラインメント問題

AI コーディング失敗の最初の種類は、アラインメント失敗であることが多いです。

ユーザーが求めているのは具体的な変更ですが、Agent はそれを大きなリファクタリングとして理解することがあります。ユーザーは Bug 修正だけを望んでいるのに、スタイルまで変更することがあります。既存アーキテクチャに従ってほしいのに、新しいパターンを導入することもあります。

Skills はタスク開始時に Agent に次のことをさせられます。

目的を言い直す
影響範囲を見つける
既存の実装パターンを識別する
計画を出す
何をしないかを明確にする

これはエンジニアが作業開始前に行うセルフチェックに似ています。

Agent がタスク境界を明確にしないままコードを書き始めると、後でどんどんズレやすくなります。

フィードバックループ問題

AI のコード生成は一回だけに頼るべきではありません。

実際の開発では、フィードバックループが重要です。

小さく変更する
テストまたは型チェックを実行する
エラーを見る
修正する
再検証する

多くの Agent は途中のフィードバックを飛ばすために失敗します。一度に多くを変更し、感覚で「動くはず」とまとめます。

Skills はフィードバックループを明示的にフローへ書き込めます。たとえば Agent に次のことを要求できます。

変更後に関連チェックを実行する
チェックが失敗したら、まずエラーメッセージを読む
無関係なファイルを盲目的に変更しない
各修正後に再検証する
最後に検証結果を報告する

これにより AI コーディングは、一回限りの作文ではなく本物のデバッグに近づきます。

アーキテクチャ制御問題

AI は抽象を生成するのが得意で、過剰に抽象を生成するのも得意です。

小さな要件を満たすために、サービス層、ヘルパー関数、設定オブジェクト、型ラッパー、アダプターを新しく作り、最終的に要件そのものより複雑なコードにしてしまうことがあります。

この問題は大規模プロジェクトで特に危険です。AI が生成した抽象は「専門的」に見えますが、既存のプロジェクトスタイルに合わず、保守コストを増やす可能性があります。

良い skills は Agent に次のことを思い出させます。

既存パターンを優先する
不必要な新しい抽象を導入しない
無関係な領域をついでにリファクタリングしない
変更をタスク規模に合わせる
コードを理解してから構造を設計する

これにより、「見た目はエンジニアリングっぽいが実際は保守しにくい」出力を減らせます。

Review skill が重要な理由

コードを書くこととコードを review することは別の状態です。

Agent がコードを書くとき、自分の実装が成立することを説明しがちです。なぜこの変更で動くかは説明しますが、必ずしもリスクを探すわけではありません。

Review skill の意味は、Agent の役割を切り替えることです。

潜在 Bug を探す
振る舞いの回帰を探す
足りないテストを探す
境界条件を探す
複雑度の上昇を探す
既存規約と不一致な箇所を探す

これは AI コーディングで重要です。AI はコードを高速に生成するため、review がないとユーザーは大量の diff に埋もれやすくなります。

良い review 出力は、まず問題を列挙すべきです。先に実装を褒める必要はありません。エンジニアがその変更をマージできるか判断する助けになるべきです。

通常の rules ファイルとの違い

多くの AI コーディングツールは rules、instructions、memory をサポートしています。

これらのファイルは通常、長期ルールを記録します。

プロジェクト技術スタック
命名規約
テストコマンド
変更してはいけないディレクトリ
回答スタイルの好み

Skills はよりタスクフローに寄っています。

rules は Agent に「長期的にどう振る舞うべきか」を伝えます。skills は Agent に「この種類のタスクをどう実行すべきか」を伝えます。

両方を一緒に使うのがよいです。

たとえば rules にプロジェクトが pnpm test を使うと書き、review skill で変更後にテストカバレッジを確認するよう求めます。すると Agent はコマンドだけでなく、いつ使うべきかも理解します。

向いている場面

mattpocock/skills のようなリポジトリは次の場面に向いています。

AI コーディングツールを頻繁に使う
Agent に実コードベースを扱わせる
AI の範囲外変更を減らしたい
Agent により積極的に結果を検証させたい
自分のエンジニアリング習慣を skills にしたい
他人の agent workflows 設計を学びたい
一時的なプロンプト群を保守可能な skill 集合に整理したい

たまに AI に小さな関数を書かせるだけなら、skills を専用に維持する必要はないかもしれません。

しかし AI を長期的な開発パートナーとして扱うなら、skills は徐々に重要になります。Agent に再利用可能な作業方法を持たせるものだからです。

このリポジトリから学べること

各 skill を直接使わなくても、このリポジトリからいくつか学べます。

第一に、失敗パターンを書き出すことです。

AI が間違えたときにその場で不満を言うだけではなく、よく間違えるパターンをルールに整理します。次回は skill に先回りして防がせます。

第二に、スキルは短くすることです。

1 つの skill は、1 つの明確な問題を解くのが理想です。短いほど正しく呼び出されやすく、保守しやすくなります。

第三に、出力形式を明確にすることです。

Agent に先に計画を列挙し、次に実行し、最後に検証結果をまとめてほしいなら、その構造を明確に書きます。曖昧な要求は曖昧な結果を生みます。

第四に、人間が引き継ぐポイントを残すことです。

良い skill は AI を一人で遠くまで走らせるべきではありません。不確実性、影響範囲の拡大、テスト失敗、プロダクト判断が必要な場合は、止まって状況を説明させるべきです。

利用時の注意

第一に、すべてを skill 化しないことです。

skills が多すぎるとシステムは複雑になり、Agent もどれを選ぶべきか分からなくなります。まずは頻度が高く、痛みの大きい場面から始めるのがよいです。

第二に、skills は反復改善が必要です。

最初に書いた skill が良いとは限りません。AI の実行結果を見て、少しずつ削り、追加し、書き直します。

第三に、skill にエンジニアリング判断を置き換えさせないことです。

Skill はフローを改善できますが、実装の正しさを保証するものではありません。テスト、review、ビルドチェック、人間の判断は依然として重要です。

第四に、Agent ごとの差に注意することです。

Claude Code、Codex、Cursor、Copilot は instructions、skills、rules のサポート方法が異なります。同じ考え方は再利用できますが、具体的な形式はツールに合わせて調整する必要があります。

参考

mattpocock/skills

最後に

mattpocock/skills が注目に値するのは、その中の一つの魔法のプロンプトではありません。エンジニアリング経験を小さなスキルに分解し、Agent に場面ごとに組み合わせて使わせるという実用的な AI コーディングの考え方です。

AI コーディングがたまの補助から日常ワークフローになると、skills は Agent を制約し、エンジニアの制御を保ち、フィードバック品質を高める重要な道具になります。

Compound Engineering Plugin：AI コーディングを計画、実行、レビューの工程ループにする

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin は、Every Inc が公開している AI コーディングワークフロープラグインです。

注目しているのは「AI により速くコードを書かせること」ではありません。AI コーディングを、よりエンジニアリングチームに近いループへ入れることです。まず計画し、次に実装し、その後レビューし、最後に経験を蓄積します。Claude Code、Codex、Cursor、Copilot のようなツールをよく使う人にとって、この種のプラグインはプロンプト問題ではなくワークフロー問題を解決します。

AI コーディングツールは強力になっていますが、実プロジェクトで難しいのはコード生成そのものではありません。AI に継続してプロジェクトルールを守らせ、タスク境界を理解させ、同じ間違いを繰り返させず、複数回の反復でコンテキストを蓄積させることです。

解決する問題

多くの人は AI コーディングアシスタントを次のような流れで使います。

要件を直接説明する
AI にコードを変更させる
結果が動くか確認する
エラーが出たら追加説明する
次のタスクでまた背景を最初から説明する

小さなタスクならこれで十分なこともあります。しかし複雑なプロジェクトでは問題が起こりやすくなります。

要件を整理しないまま AI が編集を始める
コード変更後に体系的な review がない
プロジェクト規約がユーザーの繰り返しの注意に依存する
同じ種類のミスが次回も起こる
複数の Agent ツール間で統一した作業方法がない
経験が再利用可能なルールとして蓄積されない

Compound Engineering Plugin が解決したいのは、この種の問題です。AI コーディングを複数の段階に分け、Agent を単なるコマンド実行者ではなく、より完全なエンジニアリングプロセスの参加者にします。

Compound Engineering とは何か

プロジェクト README の説明から見ると、Compound Engineering は AI 支援ソフトウェア開発の方法と理解できます。

重視するのは次のループです。

計画：目的を理解し、タスクを分解し、方針を確認する
実行：計画に沿ってコードを変更し、コマンドを実行し、問題を処理する
レビュー：実装品質、リスク、テストカバレッジを確認する
学習：経験を後続で再利用できるルールとして蓄積する

このループは実際のエンジニアリングチームの働き方に近いです。

信頼できるエンジニアは、要件を受け取ってすぐに無秩序に変更することはありません。変更後に何も確認せず渡すこともありません。まず影響範囲を判断し、実装し、リスクとテスト結果を確認し、最後に踏んだ落とし穴を記録します。AI Agent にも同じような制約が必要です。

なぜプラグインが必要なのか

プロンプトで AI に「先に計画してから実行してください」と伝えることはできます。しかしプロンプト自体は必ずしも安定しません。

会話が長くなり、コンテキストが複雑になると、モデルは計画を飛ばしたり、ルールを無視したり、タスク完了を急いで過度に自信を持ったりします。プラグインの価値は、ワークフローを固定し、異なる Agent 環境でも似た方法を守れるようにすることです。

この種のプラグインは通常、ワークフローをコマンド、ルール、テンプレート、サブフローに分解します。ユーザーは毎回完全なプロンプトを書く必要がなく、固定された入口から特定の段階を起動します。

たとえば：

まず Agent に計画を生成させる
計画に沿って段階的に実装する
変更後に review を起動する
問題が見つかったら修正に戻る
残す価値のある経験を記憶やルールに書く

これにより AI コーディングは、一回限りのチャットではなく「制御された協作」に近づきます。

対応する Agent 環境

README では、複数の AI コーディング環境をサポートすると説明されています。

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

これは注目すべき点です。

多くのワークフローツールは 1 つのクライアントにだけ結びついており、ツールを替えるとルールを再利用できません。Compound Engineering Plugin は、クロス Agent のエンジニアリング方法に近く、計画、実行、レビューのような流れを異なるツールへ持ち込みます。

複数の AI コーディングアシスタントを同時に使うなら、このような統一ワークフローには価値があります。ツールごとに能力は違っても、プロジェクト規約、レビュー習慣、タスク分解方法はできるだけ一貫している方がよいです。

計画段階の役割

計画段階の価値は、AI が早すぎる段階で手を動かすのを防ぐことです。

複雑なタスクで本当に重要なのは、たいてい次のような問いです。

どのファイルを変更するのか
どのモジュールが影響を受ける可能性があるか
既存のパターンは何か
テストはあるか
リスクはどこにあるか
先に読むべきドキュメントはあるか
より小さなステップに分解できるか

Agent がこれらを考える前にコードを書き始めると、完成しているように見えてもプロジェクト構造から外れた実装になりやすくなります。

計画は長い必要はありません。良い計画は短く、具体的で、実行可能です。目的はドキュメントを増やすことではなく、後続の実装に境界を与えることです。

実行段階で避けるべきこと

AI がコードタスクを実行するとき、よく起こる問題があります。

関係ないコードをついでにリファクタリングする
ユーザーの既存変更を上書きする
happy path だけを処理する
エラーハンドリングを無視する
既存のプロジェクトスタイルに従わない
必要な検証を実行しない
エラー後に場当たり的に試す

ワークフロープラグインはこれらの問題を完全には消せませんが、ルールと段階制約によって発生確率を下げられます。

たとえば、実行段階では Agent に計画どおり段階的に進めさせます。計画範囲外の発見があった場合は、まずリスクを説明します。共有モジュールを変更する場合は、テストを追加するか、少なくとも関連検証を実行します。

この制約は大規模コードベースで特に重要です。AI が速くコードを書くほど、その勢いを制限するプロセスが必要になります。

レビュー段階が重要な理由

多くの AI コーディング失敗は、コードがまったく動かないからではありません。細部に問題があるからです。

境界条件が処理されていない
状態更新が一貫していない
API 契約がこっそり変わっている
テストが重要経路をカバーしていない
エラーメッセージが分かりにくい
性能やセキュリティリスクが触れられていない

レビュー段階は Agent を「作者モード」から「レビューモード」へ切り替えます。

作者モードでは自分の実装を正当化しがちです。レビューモードでは、穴、回帰リスク、テスト漏れを積極的に探すべきです。この 2 つの段階を分ける方が、同じ回答内で実装と自己レビューを同時に行わせるより信頼しやすくなります。

ユーザーにとっても、レビュー出力は価値があります。その変更をマージしてよいか、まだ修正が必要かを素早く判断できます。

学習と記憶の意味

プロジェクト名の “Compound” は、重要な考え方を示しています。エンジニアリング経験は複利的に増えるべきだ、ということです。

AI が毎回のミスをその場で直すだけで、次回また同じミスをするなら、生産性向上は限られます。より良い方法は、価値ある経験を蓄積することです。

このプロジェクトのディレクトリ規約
ある種類のエラーの調査方法
テストコマンドと注意事項
触ってはいけない生成ファイル
コードスタイルの好み
よく使う実装パターン

これらの経験は、ルール、記憶、ドキュメント、テンプレートになります。後続タスクでは、Agent がまずそれらの蓄積を読み、その後作業を始めます。

これが AI コーディングを「一回限りの問答」から「長期協作」へ進める鍵です。

向いている場面

Compound Engineering Plugin は次のような場面に向いています。

AI Agent を長期的に使ってコードを書く
1 つのプロジェクトを何度も、複数回にわたって変更する
AI に先に計画してから実装してほしい
変更後に review 思考へ自動で入ってほしい
チームで AI コーディングフローを統一したい
Claude Code、Codex、Cursor など複数ツールを同時に使う
プロジェクト経験を再利用可能なルールにしたい

たまに小さなスクリプトを AI に書かせるだけなら、完全なフローは重く感じるかもしれません。

しかし AI コーディングアシスタントを日常開発の相棒として使うなら、計画、実行、レビュー、学習のループは明らかに役立ちます。

通常のプロンプトテンプレートとの違い

通常のプロンプトテンプレートは、「タスクをどう明確に伝えるか」を解決します。

たとえば：

一歩ずつ考えてください
先にファイルを読んでください
コードスタイルを揃えてください
テストを実行してください
変更内容を要約してください

これらのプロンプトはもちろん有用です。しかし、毎回ユーザーが正しく使うことに依存しています。

Compound Engineering Plugin は、よりワークフロー層にあります。これらの要求を再現可能なプロセスとして整理し、異なる Agent ツールに適用します。毎回ゼロからプロンプトを書くのではなく、一つのフローの中でタスクを進めます。

簡単に言えば、プロンプトテンプレートはリマインダーであり、ワークフロープラグインは制度に近いものです。

利用時の注意

第一に、フローを負担にしないことです。

小さなタスクに完全な計画と長いレビューが常に必要なわけではありません。良いワークフローはタスクの複雑さに応じて調整できます。単純な問題は素早く処理し、複雑な問題では完全なループを使います。

第二に、レビューはテストの代わりにはなりません。

Agent review は多くの問題を見つけられますが、実行時エラーを見逃すことがあります。最終判断には、テスト、型チェック、ビルド結果、人間のレビューが必要です。

第三に、ルールは継続的に整理することです。

経験の蓄積は重要ですが、ルールが増えすぎるとノイズになります。古いルール、重複ルール、一回のタスクにしか合わなかった一時的な経験は、定期的に整理すべきです。

第四に、ツール間で一貫していることは完全に同じであることではありません。

Claude Code、Codex、Cursor、Copilot などは能力や対話方式が異なります。統一すべきなのは作業方法であり、すべてのコマンドや設定詳細が同じである必要はありません。

向いているチーム

チームがすでに AI Agent に実コードの変更を許可しているなら、「どのモデルが強いか」だけを議論しても不十分です。

より重要なのは次の点です。

AI は変更前にタスクを理解しているか
AI は変更中にプロジェクト境界を守っているか
AI は変更後にリスクを自発的にレビューしているか
AI は過去のミスから学べるか
チームに統一された Agent 利用規約があるか

Compound Engineering Plugin のようなプロジェクトの意味はここにあります。AI コーディングを個人の小技から、チームで再利用できるプロセスへ一歩進めます。

参考

EveryInc/compound-engineering-plugin

最後に

Compound Engineering Plugin が注目に値する理由は、AI コーディングコマンドを一つ増やすことではありません。AI コーディングを、継続的に改善できるエンジニアリングフローとして整理することです。

AI Agent が実プロジェクトに参加し始めると、計画、実行、レビュー、経験の蓄積は、一回限りのコード生成より重要になります。

Codex がコンピューターを操作し始めると、これから何が変わるのか？

Wed, 29 Apr 2026 11:28:25 +0800

今回の Codex で最も注目すべき変化は、普通のボタンが一つ増えたことではありません。Codex が「コンピューターを操作する」方向へ進み始めたことです。

これまで AI を使うとき、多くの場合はチャット欄で質問し、コピーして貼り付け、その後は人間が手動でソフトウェアを操作していました。
今、その境界が外側へ広がり始めています。AI は答えるだけでなく、あなたの目的に合わせてデスクトップアプリを操作できるようになりつつあります。

短期的には新機能の一つです。長期的には、多くの人のコンピューターの使い方を変えるかもしれません。

この機能とは何か

簡単に言えば、Codex のコンピューター操作機能は、デスクトップ環境に触れ、それを操作できるようにするものです。

できることは次のようなものです。

特定のアプリを選択して操作する
自然言語でタスクを受け取る
ブラウザ、AI ツール、ローカルファイル、その他のソフトウェアを開く
テキストを入力し、ボタンをクリックし、結果を待つ
複数の手順を一つのタスクとしてつなげる
ユーザーが一歩ずつ追わなくても、バックグラウンドで実行を続ける

役割は、単に文章を一段落書くことではありません。操作の流れそのものを代行することです。

ここが Agent と普通のチャットボットの大きな違いです。
チャットボットは主に答えを返します。Agent は「目的を受け取り、それを実行する」ものに近づきます。

なぜ重要なのか

これまで多くの自動化には、スクリプトを書く力が必要でした。

たとえば、複数のソフトウェアをまたぐ作業をしたいとします。

Web ページを開く
情報を探す
内容をコピーする
別の AI ツールに渡す
ファイルを保存する
ローカルディレクトリを開いて結果を確認する

従来の方法でこれを自動化するなら、ブラウザスクリプト、API、ローカルプログラム、場合によってはウィンドウ操作まで扱う必要があります。

しかし、多くの一般ユーザーはそうしたものを書けません。
書ける人でも、一時的な作業のために専用スクリプトを書く価値があるとは限りません。

コンピューター操作機能の意味はここにあります。
「スクリプト的な能力」を自然言語の方向へ一歩押し出します。

どこをクリックするかを細かく教える必要はありません。
欲しい結果を伝え、あとは Agent に試してもらう形に近づきます。

どんなワークフローが変わるのか

最初に変わるのは、極めて厳密で高リスクな仕事ではなく、面倒で、細かく、繰り返しが多く、それでも専用プログラムを書くほどではない作業だと思います。

1. ソフトウェア間の情報移動

典型的なのは、複数のソフトウェア間で情報を移動する作業です。

これまでは、ブラウザ、文書、チャット画面、ローカルフォルダを何度も行き来していたかもしれません。
今後は、こうした作業を Agent に任せられるようになります。

ある種類の情報を探す
文書にまとめる
指定フォルダに保存する
結果を開いて確認できる状態にする

この作業は難しくありませんが、注意力を消耗します。
Agent の価値は、こうした細かい操作を吸収することです。

2. 複数の AI ツールの連携

今では、一つの AI ツールだけで完結しない作業も増えています。

たとえば：

あるツールでコードを書く
あるツールで資料を調べる
あるツールで画像を生成する
あるツールで文書を整理する

これまでは、それらの間を人間がコピー&ペーストでつないでいました。
これからは、Agent が中間層になれます。ツールを開き、文脈を渡し、出力を待ち、結果を整理します。

これにより、「複数の AI ツールの協調」は手作業から半自動の流れに変わります。

3. オフィスソフトの自動化

表計算、プレゼン、文書、メールには共通点があります。機能は強力ですが、操作は細かいものが多いということです。

Agent がこれらを安定して操作できるようになれば、オフィス自動化のハードルはかなり下がります。

メニューの場所を覚えたり、複雑なショートカットを覚えたりする必要は薄れます。
必要なのは、目的をはっきり伝えることです。

この表を月報にまとめる
この文書から 1 ページの要約を作る
これらの資料を構造の分かりやすい説明にまとめる

面倒なボタン操作は、少しずつ自然言語の後ろに隠れていくでしょう。

一般ユーザーにとっての意味

一般ユーザーにとって、この種の機能は「モデルが少し賢くなった」ことよりも直接的な影響を持つかもしれません。

下がるのは知識のハードルだけではなく、操作のハードルだからです。

多くの人は、やりたいことを説明できないわけではありません。
どこをクリックすればよいか、ソフトウェアの機能をどう組み合わせればよいかが分からないのです。

Agent がそこを引き受けられるなら、コンピューターの使い方は次のようになります。

1
2
3

私が目的を説明する
Agent がソフトウェアを操作する
私が結果を確認する

これは単なるチャットより、実際の生産性に近い形です。

ソフトウェアの形にも影響する

この種の Agent 能力が成熟していけば、ソフトウェアそのものも影響を受けます。

これまでソフトウェア設計は、主に人間のクリックに向けられていました。
これからは、Agent による操作も意識する必要が出てきます。

つまり：

UI 要素はより明確である必要がある
操作結果のフィードバックは安定している必要がある
ローカル権限はより細かく管理される必要がある
ソフトウェアは Agent が呼び出しやすいインターフェースを用意するかもしれない
ユーザーは「AI がうまく操作できるか」を気にするようになる

長期的には、アプリ間の境界は薄くなるかもしれません。
ユーザーが気にするのは「どのアプリを開くか」ではなく、「どのタスクを完了したいか」になります。

まだ過度に楽観する段階ではない

もちろん、今すぐ完全に任せる段階ではありません。

この能力には、まだ明確な制限があります。

安定性はまだ見ていく必要がある
複雑なタスクは途中で失敗する可能性がある
権限の境界は慎重に扱う必要がある
アカウント、支払い、ファイル削除のような操作は簡単に任せるべきではない
利用枠の消費も無視できない

そのため現時点で最も向いている使い方は、コンピューター全体を完全に任せることではありません。
低リスクで、確認可能で、手順が多い作業を任せることです。

たとえば：

資料を整理する
下書きを生成する
ツール間で内容を移動する
ファイルを開いて確認する
人間が最後に確認できる半自動フローを実行する

最後に

今回の Codex 更新で本当に重要なのは、AI が「質問に答える」段階から「環境を操作する」段階へ進んだことです。

短期的には、これはコンピューター操作機能です。
長期的には、個人用コンピューターとの関わり方の転換点になるかもしれません。

これから私たちは、ボタンを覚えたり、メニューを探したり、ウィンドウを切り替えたりする時間を減らしていくかもしれません。
その代わりに、目的を伝え、Agent に実行させ、最後に人間が判断する場面が増えていくでしょう。

Codex Skill はディレクトリにあるのに、なぜ表示されないのか？

Wed, 29 Apr 2026 11:18:00 +0800

今回の問題はかなり見落としやすいものでした。~/.codex/skills には複数の skill が置かれているのに、新しい Codex スレッドを開いても、サイドバーには一部しか表示されませんでした。

最初はキャッシュやインデックスの問題に見えました。実際の原因はもっと具体的で、いくつかの SKILL.md ファイルの先頭に UTF-8 BOM が付いていました。Codex 0.111.0 の skill loader はこのバイト列を読み飛ばさず、結果として有効な YAML front matter がないと誤判定していました。

現象

ローカルディレクトリには次の skill がありました。

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

しかし新しいスレッドで実際に公開された skill は次の二つだけでした。

1
2

bilibili-speech-transcriber
product-cutout-normalize

つまり、ファイルが存在することと、現在のセッションで読み込めることは別です。Codex は各 SKILL.md の front matter を先に解析し、解析に失敗した skill はそのまま除外します。

調査

codex exec で新しいセッションを起動すると、より直接的なエラーが見えます。VS Code などの IDE では、こうした log が見えない場合があります。

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

これらのファイルは、見た目には正常な先頭を持っていました。

---
name: post-rewrite
description: ...
---

本当の問題はバイト列にありました。

失敗するファイルの先頭は：

`1`	`EF-BB-BF-2D-2D-2D`

正常に読み込まれるファイルの先頭は：

`1`	`2D-2D-2D`

2D-2D-2D は --- です。その前にある EF-BB-BF が UTF-8 BOM です。

原因

Codex 0.111.0 の skill loader は、SKILL.md の最初のバイトが --- の最初の - であることを期待しています。

ファイルの先頭に UTF-8 BOM があると、実際の先頭は次のようになります。

`1`	`BOM + ---`

そのため loader は、ファイルが front matter の区切りで始まっていないと判断し、最終的に次のエラーを出します。

`1`	`missing YAML frontmatter delimited by ---`

skill の内容が間違っていたわけでも、ディレクトリが間違っていたわけでもありません。エンコーディングの細部が原因で、パーサーがファイルを認識できなかっただけです。

修正

問題のある SKILL.md を BOM なしの UTF-8 に変換します。

PowerShell では次のように処理できます。

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

処理後にファイルヘッダーを確認すると、次の状態から：

`1`	`EF-BB-BF-2D-2D-2D`

次の状態に変わっているはずです。

`1`	`2D-2D-2D`

検証

Codex セッションを再起動すると、表示される skill は次のように戻りました。

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

それでもサイドバーに古い一覧しか表示されない場合は、現在の Codex sidebar またはウィンドウを閉じて、プロジェクトを開き直します。skill 一覧は通常セッション開始時に読み込まれるため、途中でファイルを変更してもすぐには反映されないことがあります。

最後に

この種の問題は、「Codex が再インデックスしていない」または「skill のインストールに失敗した」と誤解しやすいです。

実際に調べるときは、まず次の三点を確認するとよいです。

SKILL.md が正しいディレクトリにあるか
ファイル先頭に有効な --- front matter があるか
ファイルが BOM なしの UTF-8 か

今回のポイントは三つ目です。ファイルは見た目には問題ありませんでしたが、最初のバイトが - ではなかったため、Codex はそれを有効な skill として扱いませんでした。

Codex の ~/.codex/skills とプロジェクト/.codex/skills の違い

Wed, 29 Apr 2026 11:08:00 +0800

Codex skills を整理するとき、多くの人がつまずきやすい問題は主に二つあります。

~/.codex/skills と プロジェクト/.codex/skills は何が違うのか
skill はディレクトリにあるのに、なぜ現在のセッションに表示されないことがあるのか

この文章では結論から整理します。

両者の違い

まず短く覚えるなら、こうです。

~/.codex/skills は自分用のグローバルなスキルライブラリ
プロジェクト/.codex/skills はそのリポジトリ用のローカルなスキルライブラリ

`~/.codex/skills`

ここに置くのに向いているもの：

自分が複数プロジェクトで繰り返し使う skill
特定のリポジトリに依存しない汎用的な手順
明らかに個人の作業習慣に属するワークフロー

たとえば：

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

このタイプの skill の特徴は、現在のプロジェクトを離れても使えることです。

`プロジェクト/.codex/skills`

ここに置くのに向いているもの：

このリポジトリでだけ成立する手順
現在のプロジェクトのディレクトリ構成、スクリプト、テンプレートに強く結びついたルール
チームで共有したい skill

たとえば：

このリポジトリ固有の公開フロー
このプロジェクト内でしか使えない生成テンプレート
プロジェクト固有のスクリプトに強く依存する自動化手順

このタイプの skill の特徴は、このリポジトリを離れると意味が薄くなることです。

グローバルに置くか、プロジェクトに置くか

判断基準はシンプルです。

個人の作業習慣に関係するなら ~/.codex/skills
リポジトリのルールに関係するなら プロジェクト/.codex/skills
複数プロジェクトで再利用できるなら、まずはグローバル
複数人で共有し、リポジトリと一緒に育てたいなら、プロジェクト側

今回のリポジトリの状態

現在見えている状態では：

ローカル環境には ~/.codex/skills がある
現在のリポジトリには .codex/skills がない

つまり、今は主にグローバル skills に依存しています。

言い換えると、post-rewrite、post-translate、git-commit-push のような手順は、このリポジトリに明示的に含まれているものではなく、あなた個人のワークフローに近いものです。

ディスク上にあるのに、現在のセッションに表示されない理由

ここでは二つの状態を分けて考える必要があります。

ディスク上に存在する：skill ファイルがローカルのディレクトリにある
セッションに公開されている：現在のセッションがそれを利用可能な skill として登録している

この二つは同じではありません。

そのため、次のようなことが起きます。

~/.codex/skills にはすでに skill がある
しかし / の後に出る一覧には表示されない

これは通常、skill が壊れているという意味ではありません。より多い原因は、現在のセッションがそれを再インデックスしていないことです。

現在のセッションに skill を表示させるには

実用上の手順は次の通りです。

1. 正しいディレクトリに置く

グローバル：

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

プロジェクト単位：

`1`	`プロジェクト/.codex/skills/<skill-name>/SKILL.md`

2. `SKILL.md` の先頭を認識できる形にする

最低限、次のような front matter が必要です。

---
name: your-skill-name
description: この skill が何をするものか
---

3. 新規作成または編集後は、新しいセッションを開く

skill が表示されない原因は、ファイルの問題ではなく、現在のセッション開始時に利用可能な skill 一覧がすでに確定していたことかもしれません。

そのため、セッション中に skill を作成しても、ディスク上には存在する一方で、そのセッションでは認識されない場合があります。

いちばん確実な流れは次の通りです。

skill を正しい場所に置く
現在のセッションを終了する
プロジェクトに入り直す
新しいセッションを開く
/ に表示されるか確認する

4. プロジェクト skill は事前に置いておく

プロジェクト/.codex/skills をより安定して認識させたいなら、リポジトリに入り、セッションを開始する前に、それらの skill をプロジェクト内に置いておくのが無難です。

最後に

短くまとめると：

~/.codex/skills は個人用のスキルライブラリ
プロジェクト/.codex/skills はリポジトリ用のローカルルールライブラリ
skill がディレクトリにあることと、現在のセッションに表示されることは別
表示させたいなら、正しいディレクトリに置き、正しい SKILL.md を書き、新しいセッションを開くのが基本

OpenAI が GPT-5.5 を発表：より強力なエージェント型コーディング、知識作業、研究支援

Fri, 24 Apr 2026 08:39:56 +0800

OpenAI は 2026 年 4 月 23 日に Introducing GPT-5.5 を公開しました。公式ページを見る限り、今回の更新は単に「モデルが賢くなった」という話ではなく、複雑なタスクをどこまで継続して進められるかに重点があります。

OpenAI は GPT-5.5 を、実際の仕事により適したモデルとして位置づけています。質問に答えるだけでなく、コードを書き、デバッグし、情報を調べ、データを分析し、文書やスプレッドシートを作成し、ソフトウェアを操作し、複数のツールを行き来しながらタスクを完了することが期待されています。

1. GPT-5.5 はどこが強いのか

今回の発表ページで繰り返し強調されている方向性は、大きく次の 4 つです。

エージェント型コーディング
コンピューター操作とツール利用
知識作業
初期段階の科学研究支援

つまり、GPT-5.5 の重点は短い質疑応答ではなく、より長い流れを持つタスクです。たとえばエンジニアリング上の問題は、「このコードをどう直すか」だけではありません。プロジェクト構造を理解し、失敗原因を特定し、関連ファイルを修正し、テストを追加し、結果を検証し、ユーザーが何度も指示しなくても前に進める必要があります。

OpenAI は、GPT-5.5 が Codex のタスクでより少ない token を使うことも強調しています。これは実務上かなり重要です。コーディングエージェントは、ファイルを読み、コマンドを実行し、bug を直し始めると、token 消費がすぐに増えます。同じタスクを少ない手順で完了できれば、実際のコストと待ち時間の両方が下がります。

2. コーディング能力が今回の中心的な見せ場

OpenAI は GPT-5.5 を、現時点で最も強力な agentic coding モデルだと説明しています。

公開されている指標の中で、とくに注目したいものは次の通りです。

Terminal-Bench 2.0：GPT-5.5 は 82.7%
SWE-Bench Pro：GPT-5.5 は 58.6%
OpenAI 内部の Expert-SWE：GPT-5.5 は GPT-5.4 を上回る

これらの評価に共通しているのは、単一のアルゴリズム問題よりも、実際の開発フローに近いことです。特に Terminal-Bench のようなタスクでは、コマンドライン操作、計画、試行錯誤、ツール連携、複数ステップの検証が必要になります。

日常的に開発する人にとって、ここでの意味は明確です。モデルがより大きなタスクを受け止められるかどうかは、長時間コンテキストを保てるか、自分の仮説を検証できるか、いつテストを走らせるべきかを判断できるか、変更がどこに影響するかを理解できるかにかかっています。

Codex における GPT-5.5 の価値も、主にこうした振る舞いに表れます。コード断片を補完するだけのツールというより、エンジニアリング作業の一部を任せられる協力者に近づいています。

3. 知識作業が重要な利用シーンになっている

コードを書くことに加えて、OpenAI は今回 GPT-5.5 をより広いオフィス作業の文脈にも置いています。

公式発表では、GPT-5.5 は Codex で文書、スプレッドシート、スライド資料をよりうまく生成でき、業務調査、表計算モデル、ビジネス資料の整理にも向いているとされています。コンピューター操作能力と組み合わせると、その目標は単に助言することではなく、「情報を探す、内容を理解する、ツールを使う、出力を確認する、結果として整理する」という一連の流れに直接参加することです。

発表ページでは、OpenAI 社内ですでにソフトウェアエンジニアリング、財務、コミュニケーション、マーケティング、データサイエンス、プロダクト管理など、多くの部門で Codex が使われていることにも触れています。ここで注目すべきなのは個別の事例ではなく、OpenAI が Codex を開発者向けツールから汎用的な仕事用ツールへ広げようとしている点です。

ChatGPT では、GPT-5.5 Thinking が Plus、Pro、Business、Enterprise ユーザー向けに提供されます。GPT-5.5 Pro は、より難しい問題や高い正確性が必要な作業向けで、Pro、Business、Enterprise ユーザーが利用できます。

4. 研究能力は「答えがうまい」だけではない

GPT-5.5 は研究支援の面でも大きく紹介されています。

OpenAI は、遺伝学、定量生物学、バイオインフォマティクス、数学証明などの領域で改善があると述べています。ここで重要なのは、モデルが知識を暗記しているかどうかではなく、より現実の研究に近い問題を扱えるかどうかです。データを読み、異常を見つけ、分析方法を提案し、結果を解釈し、中間結果に基づいてさらに進める必要があります。

発表ページに登場する GeneBench と BixBench は、どちらも多段階の科学分析タスク寄りの評価です。OpenAI はさらに、カスタムハーネスを使った GPT-5.5 の内部版が Ramsey numbers に関する新しい証明の発見を助け、その証明が Lean で検証されたとも述べています。

こうした事例を「AI がすでに独立して研究できる」と単純に捉えるべきではありません。ただし、モデルが質問応答ツールから研究協力者へ近づいていることは示しています。特に、コード、データ、論文、実験アイデアが混ざる場面では、GPT-5.5 の長い推論とツール利用能力がより重要になります。

5. 推論効率：強くなっても大きく遅くならない

見落としやすい点として、OpenAI は GPT-5.5 の実運用における per-token latency が GPT-5.4 と同等だと説明しています。

通常、より大きく強力なモデルは高い遅延を伴います。今回 OpenAI は、推論システムの最適化によって、GPT-5.5 の能力を高めながら速度を維持したと強調しています。発表ページでは、Codex が本番トラフィックのパターンを分析し、負荷分散に関するヒューリスティックアルゴリズムを書いたことで、token 生成速度が 20% 以上向上したとも述べられています。

この点は興味深いところです。モデルはインフラに提供されるだけでなく、自分自身を提供するインフラの改善にも役立っているからです。

6. 安全対策はより厳しくなる、とくにサイバーセキュリティ領域

GPT-5.5 はサイバーセキュリティ能力も強くなっているため、OpenAI は安全制限も同時に強化しています。

公式説明では、GPT-5.5 はサイバーセキュリティ能力で GPT-5.4 より向上しているため、より厳格な分類器を導入するとされています。特に、高リスク活動、機微なサイバーセキュリティ関連リクエスト、繰り返しの悪用に対して厳しくなります。

そのため、一部のユーザーはサイバーセキュリティ関連の作業で、より多くの拒否や制限に遭遇する可能性があります。OpenAI は Trusted Access for Cyber も用意しており、検証済みの防御目的のユーザーが不要な制限を受けにくくする仕組みを提供しています。

一般的な開発者にとっては、合法的なセキュリティ強化、脆弱性修正、コード監査は引き続き支援される一方、高リスクな攻撃フローはより厳しく制御される、と理解すればよさそうです。

7. 利用可能範囲と API 価格

OpenAI の発表ページによると、GPT-5.5 の利用可能範囲は次の通りです。

ChatGPT：GPT-5.5 Thinking は Plus、Pro、Business、Enterprise ユーザー向け
ChatGPT：GPT-5.5 Pro は Pro、Business、Enterprise ユーザー向け
Codex：GPT-5.5 は Plus、Pro、Business、Enterprise、Edu、Go プラン向け
Codex：コンテキストウィンドウは 400K
Codex Fast mode：生成速度は約 1.5x、コストは 2.5x

API については、OpenAI は gpt-5.5 と gpt-5.5-pro を近く提供するとしています。

公式に示された API 価格は次の通りです。

gpt-5.5：入力 5 米ドル / 1M tokens、出力 30 米ドル / 1M tokens
gpt-5.5-pro：入力 30 米ドル / 1M tokens、出力 180 米ドル / 1M tokens
gpt-5.5 API のコンテキストウィンドウは 1M
Batch と Flex は標準 API 価格の半額
Priority processing は標準価格の 2.5x

この価格は多くの日常用途向けモデルより明らかに高いため、普通の雑談よりも、複雑な工程変更、長文書分析、オフィス自動化、研究支援、重要な業務フローのような高価値タスクに向いています。

8. 今回の発表をどう見るか

一言で言えば、GPT-5.5 の重点は、OpenAI がモデルを「質問に答えるもの」から「仕事を完了するもの」へさらに進めていることです。

注目すべきなのは benchmark の点数だけではありません。いくつかの能力が合流し始めています。

より強い長時間タスク維持能力
より安定したツール利用
より良いエンジニアリング文脈理解
文書、スプレッドシート、研究、業務フローへの適性
より長いコンテキストと高い token 効率
高リスク能力に対するより厳格な制御

開発者にとって最も試す価値があるのは、Codex での複雑なエンジニアリングタスクです。企業ユーザーにとっては、ツール、文書、業務プロセスをまたぐ一部の作業を、実際に納品できる成果物へ変えられるかが重要になります。

GPT-5.5 は、チャット体験だけを対象にした小さな更新ではありません。OpenAI が「仕事の実行層としての AI」をさらに進める一歩に見えます。

codex-quota 実践ガイド：コマンドをそのまま使う Local・Web・Docker 運用

Thu, 16 Apr 2026 18:13:04 +0800

このプロジェクトは何をするか

codex-quota は ChatGPT Codex のクォータ使用状況を確認できる軽量ツールで、データ取得元は https://chatgpt.com/backend-api/wham/usage です。

主な機能：

単一アカウント・複数アカウント（account/*.auth.json）の両方に対応。
five_hour%、weekly%、weekly_reset を出力し、取得元（network / cache）も表示。
一時的な失敗（408、429、5xx）に対して指数バックオフで再試行。
ローカルキャッシュを内蔵し、クォータ枯渇時の重複リクエストを削減。
Web Dashboard、JSON API、auth ファイル管理画面を提供。

メリット：

軽量：単体スクリプトで実行でき、依存が少ない。
実用的：CLI と Web の両方の入口を使える。
配備しやすい：Docker / Docker Compose をサポート。
運用しやすい：再試行、キャッシュ、定期更新に対応。

先にアカウント認証情報を準備する

account/<name>.auth.json に認証情報ファイルを作成します。例：

{
  "tokens": {
    "access_token": "eyJ...",
    "account_id": "user-xxxxxxxx"
  }
}

説明：

access_token と account_id は API クエリに必要な項目です。
ファイル名の <name> は出力時のアカウント名として使われます。

Local CLI の使い方（元コマンドを維持）

依存をインストール：

`1`	`pip install -r requirements.txt`

説明：プロジェクトの実行依存をインストールします。

全アカウントを照会：

`1`	`python codex_quota.py`

説明：account/*.auth.json を読み込み、全アカウントのクォータを集計表示します。

単一アカウントを照会：

`1`	`python codex_quota.py your_account_name`

説明：account/your_account_name.auth.json のみを照会します。

強制更新（キャッシュ無視）：

`1`	`python codex_quota.py --refresh`

説明：ローカルキャッシュを無視して最新データを直接取得します。

CLI オプション説明（README 準拠）

account_name：任意のアカウント名（.auth.json なし）。
--account-dir：認証ファイルディレクトリ。デフォルトは account。
--chatgpt-url：クォータ API エンドポイント。
--raw-json：JSON レスポンス本文をそのまま表示。
--raw-headers：レスポンスヘッダーを表示。
--refresh：キャッシュを無視。
--retries：再試行回数。デフォルト 3。
--retry-delay：再試行の基本待機秒数。デフォルト 2.0。

Web Dashboard の使い方（元コマンドを維持）

サービス起動：

`1`	`python codex_quota_service.py --host 0.0.0.0 --port 8081`

説明：8081 ポートで HTTP サービスを起動します。

アクセス URL：http://localhost:8081

Service オプション：

--host：バインドアドレス。デフォルト 0.0.0.0。
--port：ポート。デフォルト 8081。
--interval-seconds：定期更新間隔。デフォルト 3600。
--account-dir：認証ファイルディレクトリ。デフォルト account。
--state-file：状態ファイルパス。デフォルト <account-dir>/codex_quota_web_results.json。
--account-name：任意。単一アカウントモード。
--chatgpt-url：クォータ API エンドポイント。
--retries：再試行回数。
--retry-delay：再試行の基本待機。
--refresh：定期実行時に CLI キャッシュを無視。

HTTP エンドポイント（自動化向け）

GET /：Dashboard 画面。
GET /api/results：最新結果の JSON。
GET /refresh：即時更新して / にリダイレクト。
GET /auth：auth ファイル一覧。
GET /auth/new：auth ファイル新規作成フォーム。
GET /auth/edit?name=<account>：auth ファイル編集フォーム。
POST /auth/save：auth ファイル作成/更新。
POST /auth/delete：auth ファイル削除。

Docker の使い方（元コマンドを維持）

イメージをビルド：

`1`	`docker build -t codex-quota .`

説明：現在のプロジェクトを codex-quota イメージとしてビルドします。

コンテナ起動（8081 をマッピング）：

`1`	`docker run --rm -p 8081:8081 -v ./account:/app/account codex-quota`

説明：

--rm：終了後にコンテナを自動削除。
-p 8081:8081：ホストポートをコンテナポートへマッピング。
-v ./account:/app/account：ローカル認証ディレクトリをコンテナにマウント。

アクセス URL：http://localhost:8081

Docker Compose の使い方（元コマンドを維持）

起動：

`1`	`docker compose up --build`

説明：docker-compose.yml に従ってビルド・起動します。

アクセス URL：http://localhost:8081

運用のヒント

複数アカウント運用では、まず Dashboard で一元管理するのがおすすめです。
通知や自動連携には GET /api/results を優先すると扱いやすいです。
公開リポジトリに実際の access_token をコミットしないでください。
一時エラーが多い場合は --retries と --retry-delay を増やしてください。

Codex の利用枠の考え方：5時間制限、週次制限、Credit 消費

Wed, 15 Apr 2026 22:50:00 +0800

Codex の利用枠を見ると、最初は 5時間制限 が短期の残高で、それを使い切ってから 週次制限 が減り始めるように見えます。

しかし実際は違います。Codex は複数の制限ウィンドウを同時に確認している、と考える方が自然です。短いウィンドウは短時間の大量利用を防ぎ、週次ウィンドウは一週間の総量を制御します。1 回の Codex 利用は通常、その両方に反映されます。

そのため、次のような状態は一般的には正常です。

1
2

5時間枠はまだ多く残っている
しかし weekly 枠はすでに減っている

01 まず結論

Codex の利用枠は、まず次の 3 点で理解できます。

5時間制限 と 週次制限 は同時に有効であり、順番に消費されるものではありません。
週次制限を使い切ると、5時間枠が残っていても同じサブスクリプション枠では通常続けて使えません。
Codex は単純なメッセージ数ではなく、モデル、tokens、タスクの複雑さ、コンテキスト、実行場所に影響されます。

疑似コードで書くとこうです。

can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && 他の製品ポリシー制限に触れていない

5時間ウィンドウがリセットされても、戻るのは 5時間枠だけです。weekly 枠は戻りません。weekly は自分の reset を待つか、対応プランで追加 credits を購入する必要があります。

02 なぜ両方のウィンドウが減るのか

Codex の利用枠は 2 つのゲートとして考えるとわかりやすいです。

ウィンドウ	役割
5時間ウィンドウ	短時間の高頻度利用を防ぐ
週次ウィンドウ	一週間の総使用量を制御する

Codex タスクごとに実際の消費が発生し、その消費が関連する rate limit ウィンドウに反映されます。

つまり、こうではありません。

1
2
3

先に 5時間枠を使う
5時間枠を使い切ったら
週次枠を使う

より近いのはこうです。

1
2
3

1 回の Codex リクエスト
=> 5時間ウィンドウに計上
=> 同時に週次ウィンドウにも計上

これが「5時間枠が残っているのに weekly も減る」理由です。

03 今は token-based credits を見る

OpenAI は、ユーザーが完全に再計算できる Codex の課金式を公開していません。公開されているのは rate card、影響要因、モデル別の credit 単価です。

2026-04-15 時点では、Codex rate card の主な考え方は token-based credits です。入力 tokens、キャッシュ入力 tokens、出力 tokens から credits に換算されます。

公式の価格例は次の通りです。

モデル	入力 / 1M tokens	キャッシュ入力 / 1M tokens	出力 / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

ざっくりした見積もりは次のようになります。

今回の消費
≈ 入力 tokens / 1,000,000 × モデルの入力単価
+ キャッシュ入力 tokens / 1,000,000 × モデルのキャッシュ入力単価
+ 出力 tokens / 1,000,000 × モデルの出力単価

これは正確な請求式ではありませんが、傾向の説明には十分です。出力は高く、長いコンテキストも高く、高性能モデルほど高くなります。公式 rate card では、Fast mode は 2 倍の credits を消費し、Code review は GPT-5.3-Codex の価格を使うとも説明されています。

04 メッセージ数だけで見ない

同じ 10 回の Codex メッセージでも、消費量は大きく変わります。

軽いタスクは通常少なめです。

小さな関数を修正する
短いコードを説明する
短い文章を書く
明確なファイル内で局所的に変更する

重いタスクは高くなります。

大きなコードベースをスキャンする
長時間 agent を動かす
読み取り、編集、テスト、修正を何度も繰り返す
大量のコードや長いレポートを生成する
cloud task を使う
fast mode を有効にする

そのため、メッセージ数 はかなり粗い目安にすぎません。実際の消費量を判断するには不十分です。

05 local task と cloud task の違い

消費量の差が出やすいのは実行場所です。

local task は、ローカルのワークスペースでファイルを読み、コードを編集し、コマンドを実行するものです。cloud task は、タスクをクラウド環境に任せて実行するもので、長く自動化された処理に向いています。

cloud task は多くの場合、より高くなります。理由は単純です。

クラウド実行環境が必要
タスクが長くなりやすい
ツール呼び出しが多い
コンテキストが大きい
自動化の流れがより完全

通常のコード編集、記事整理、小さな修正なら local task の方が節約しやすいです。cloud task は本当にクラウド実行が必要なときに使うのがよいです。

06 weekly が早く減る理由

5時間枠はあまり減っていないのに weekly が大きく減る場合、よくある理由は次の通りです。

cloud task を使った。
高いモデルを使った。
fast mode を有効にした。
コンテキストが大きく、多くのファイルや長い会話を扱った。
出力が長かった。大量のコード、長いレポート、ログ分析など。
タスクチェーンが長かった。検索、編集、テスト、修正、再テストなど。
自作の利用枠スクリプトがウィンドウ名を誤って解釈した。

/backend-api/wham/usage のようなフィールドをスクリプトで読んでいる場合、加工後の five_hour% や weekly% だけを信用しない方が安全です。raw JSON で次の値を確認します。

limit_window_seconds
percent_left
reset_at
bucket / feature 名

典型的なウィンドウは次のように判断できます。

limit_window_seconds = 18000
=> 約 5 時間

limit_window_seconds = 604800
=> 約 7 日

スクリプトが 2 つのウィンドウを逆にラベル付けしていると、利用枠表示は誤解を招きます。

07 利用枠を節約する使い方

weekly を長持ちさせるには、次のように使います。

大きなタスクを小さく分ける。
可能なら local task を優先する。
関連パスを明確に伝え、不要なスキャンを減らす。
巨大なログ、長いファイル、無関係なコンテキストを一度に入れない。
軽い作業には安い mini モデルを使う。
長い作業の前に、まず計画を出してもらう。
長いレポートが不要なら、簡潔に答えるよう指定する。

覚えやすいモデルはこれです。

続けて使えるか
= 短いウィンドウに残量がある
&& 週次ウィンドウに残量がある

消費の速さ
= モデル価格
× tokens
× 出力の長さ
× タスクの複雑さ
× 実行場所

これは正確な請求計算ではありませんが、ほとんどの Codex 利用枠の挙動を説明できます。

Codex クォータ使用統計

Sun, 12 Apr 2026 00:01:33 +0800

現在の Codex アカウントの残高を確認したい場合は、ChatGPT の /backend-api/wham/usage インターフェイスを要求する小さなスクリプトを直接作成できます。

このタイプのスクリプトの考え方は非常にシンプルです。

auth.json から tokens.access_token および tokens.account_id を読み取ります
リクエスト https://chatgpt.com/backend-api/wham/usage
リクエストヘッダーに Authorization: Bearer ... と ChatGPT-Account-Id を含めます
返された結果の 5 時間のウィンドウと週ごとのウィンドウクォータを解析します。

やるべきことに適した

この方法は、ローカルですばやく確認するのに適しています。

5 時間の割り当てはどれくらい残っていますか?
週の割り当てはどれくらい残っていますか?
クォータはいつリセットされますか?

複数のアカウントをお持ちの場合は、スクリプトで account/*.auth.json を一括で読み込み、一律に集計表を出力することもできます。 auth.json ファイルは、現在ログインしている chatgpt アカウントに対応する ~/.codex/ ディレクトリにあります。

最も重要なインプット

通常、スクリプトは次の 2 つの資格情報のみに依存します。

access_token
account_id

これらは通常、ローカルの auth.json から入手できます。これら 2 つの値が有効である限り、リクエストヘッダーは次のように構成できます。

headers = {
    "Authorization": f"Bearer {auth_token}",
    "Accept": "application/json",
    "ChatGPT-Account-Id": auth_account_id,
    "Origin": "https://chatgpt.com",
    "Referer": "https://chatgpt.com/",
    "User-Agent": "Mozilla/5.0",
}

返された結果の見方

インターフェイスが戻った後は、次の 2 種類のウィンドウに焦点が当てられます。

five_hour
weekly

スクリプトはそれらを次の項目に整理できます。

残高の割合
リセット時間
対応する時間ウィンドウの長さ

インターフェイスフィールド名が異なる場合、バリアント primary_window、secondary_window、five_hour_limit、および weekly_limit とも互換性がある可能性があります。

よくある質問

スクリプトが 401 を返した場合、通常、access_token の有効期限が切れているか、無効であることを意味します。

403 が返された場合は、通常、現在のアカウントにこのインターフェイスにアクセスする権限がないか、アカウントのステータスが異常であることを意味します。

同じ応答内でフィールドの名前が一貫していない場合でも驚かないでください。実際の処理では、異なる命名方法を統一的にマッピングしてから出力するのがベストです。

参考リンク

codex-auth-manager：https://github.com/RioArisk/codex-auth-manager

コード

import argparse
import base64
import json
import os
import sys
from datetime import datetime, timedelta, timezone
from pathlib import Path
from typing import Any

import requests


UTC = timezone.utc
CST = timezone(timedelta(hours=8), name="CST")
JSONDict = dict[str, Any]


def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description="Query ChatGPT Codex usage from /backend-api/wham/usage."
    )
    parser.add_argument(
        "account_name",
        nargs="?",
        help="Account name used to load account/<account_name>.auth.json. If omitted, load all *.auth.json files in account/.",
    )
    parser.add_argument(
        "--account-dir",
        default="account",
        help="Directory containing <account_name>.auth.json files.",
    )
    parser.add_argument(
        "--chatgpt-url",
        default="https://chatgpt.com/backend-api/wham/usage",
        help="ChatGPT usage endpoint.",
    )
    parser.add_argument(
        "--raw-json",
        action="store_true",
        help="Print the full JSON response body.",
    )
    parser.add_argument(
        "--raw-headers",
        action="store_true",
        help="Print response headers.",
    )
    return parser.parse_args()


def print_json(data: Any) -> None:
    print(json.dumps(data, indent=2, ensure_ascii=False))


def load_auth_json(path_str: str | Path | None) -> JSONDict | None:
    if not path_str:
        return None
    path = Path(path_str).expanduser()
    if not path.is_file():
        return None
    try:
        return json.loads(path.read_text(encoding="utf-8"))
    except (OSError, json.JSONDecodeError):
        return None


def get_nested_string(data: JSONDict | None, *keys: str) -> str | None:
    current: Any = data
    for key in keys:
        if not isinstance(current, dict):
            return None
        current = current.get(key)
    return current if isinstance(current, str) and current else None


def format_dt(dt: datetime | None) -> str:
    if dt is None:
        return "-"
    return dt.astimezone(CST).strftime("%Y-%m-%d %H:%M:%S %Z")


def format_cst(dt: datetime | None) -> str:
    return format_dt(dt)


def epoch_ms_to_dt(value: Any) -> datetime | None:
    if value is None:
        return None
    try:
        raw = int(value)
    except (TypeError, ValueError):
        return None
    # Newer responses sometimes use epoch seconds, older ones use epoch milliseconds.
    timestamp = raw / 1000 if raw > 10**11 else raw
    return datetime.fromtimestamp(timestamp, tz=UTC)


def first_dict(data: Any, *keys: str) -> JSONDict | None:
    for key in keys:
        value = data.get(key) if isinstance(data, dict) else None
        if isinstance(value, dict):
            return value
    return None


def decode_jwt_exp(token: str) -> datetime | None:
    parts = token.split(".")
    if len(parts) != 3:
        return None
    try:
        payload = parts[1]
        payload += "=" * (-len(payload) % 4)
        data = json.loads(base64.urlsafe_b64decode(payload.encode("ascii")))
        exp = data.get("exp")
        if exp is None:
            return None
        return datetime.fromtimestamp(int(exp), tz=UTC)
    except (ValueError, TypeError, json.JSONDecodeError):
        return None


def get_percent_left(value: JSONDict) -> float | int | None:
    percent_left = value.get("percent_left")
    if percent_left is None:
        percent_left = value.get("remaining_percent")
    if percent_left is not None:
        return percent_left

    used_percent = value.get("used_percent")
    try:
        if used_percent is not None:
            return max(0, 100 - float(used_percent))
    except (TypeError, ValueError):
        return None
    return None


def resolve_limit_window(value: JSONDict) -> JSONDict:
    if (
        "reset_at" not in value
        and "reset_time_ms" not in value
        and isinstance(value.get("primary_window"), dict)
    ):
        return value["primary_window"]
    return value


def parse_limit_entry(name: str, value: Any) -> JSONDict | None:
    if not isinstance(value, dict):
        return None

    value = resolve_limit_window(value)

    percent_left = get_percent_left(value)
    reset_time_ms = value.get("reset_time_ms")
    if reset_time_ms is None:
        reset_time_ms = value.get("reset_at")

    window_seconds = value.get("limit_window_seconds")

    return {
        "name": name,
        "percent_left": percent_left,
        "reset_time_ms": reset_time_ms,
        "reset_at": epoch_ms_to_dt(reset_time_ms),
        "limit_window_seconds": window_seconds,
    }


def infer_limit_name(window_seconds: Any) -> str | None:
    if not isinstance(window_seconds, (int, float)):
        return None
    if window_seconds <= 6 * 3600:
        return "five_hour"
    if window_seconds >= 6 * 24 * 3600:
        return "weekly"
    return None


def relabel_rate_limits(primary: JSONDict | None, secondary: JSONDict | None) -> tuple[JSONDict | None, JSONDict | None]:
    for entry in (primary, secondary):
        if not entry:
            continue
        inferred_name = infer_limit_name(entry.get("limit_window_seconds"))
        if inferred_name:
            entry["name"] = inferred_name

    if primary and secondary and primary.get("name") == secondary.get("name"):
        if primary.get("name") == "weekly":
            primary["name"] = "five_hour"
        else:
            secondary["name"] = "weekly"

    if primary and primary.get("name") == "weekly" and secondary is None:
        return None, primary

    if secondary and secondary.get("name") == "five_hour" and primary is None:
        return secondary, None

    return primary, secondary


def parse_rate_limits(data: JSONDict) -> tuple[JSONDict | None, JSONDict | None]:
    primary = None
    secondary = None

    for primary_key in ("five_hour", "five_hour_limit", "five_hour_rate_limit", "primary"):
        if primary_key in data:
            primary = parse_limit_entry("five_hour", data.get(primary_key))
            if primary:
                break

    for secondary_key in ("weekly", "weekly_limit", "weekly_rate_limit", "secondary"):
        if secondary_key in data:
            secondary = parse_limit_entry("weekly", data.get(secondary_key))
            if secondary:
                break

    if primary is None:
        primary = parse_limit_entry("five_hour", data.get("primary_window"))
    if secondary is None:
        secondary = parse_limit_entry("weekly", data.get("secondary_window"))

    return relabel_rate_limits(primary, secondary)


def format_percent(value: Any) -> str:
    return f"{value:g}" if isinstance(value, (int, float)) else str(value if value is not None else "-")


def percent_sort_value(value: Any, descending: bool) -> tuple[int, float]:
    if isinstance(value, (int, float)):
        numeric_value = float(value)
        return (0, -numeric_value if descending else numeric_value)
    return (1, 0.0)


def get_auth_paths(account_dir: str, account_name: str | None) -> list[Path]:
    base_dir = Path(account_dir)
    if account_name:
        return [base_dir / f"{account_name}.auth.json"]
    return sorted(base_dir.glob("*.auth.json"))


def get_account_name_from_path(path: Path) -> str:
    suffix = ".auth.json"
    return path.name[: -len(suffix)] if path.name.endswith(suffix) else path.stem


def build_summary_row(account_name: str, five_hour: JSONDict | None, weekly: JSONDict | None) -> JSONDict:
    return {
        "account": account_name,
        "five_hour_percent": five_hour["percent_left"] if five_hour else None,
        "weekly_percent": weekly["percent_left"] if weekly else None,
        "weekly_reset_at": weekly["reset_at"] if weekly else None,
    }


def print_summary_rows(rows: list[JSONDict]) -> None:
    if not rows:
        return

    sorted_rows = sorted(
        rows,
        key=lambda row: (
            percent_sort_value(row.get("five_hour_percent"), descending=True),
            percent_sort_value(row.get("weekly_percent"), descending=True),
            format_cst(row.get("weekly_reset_at")),
            row["account"],
        ),
    )

    display_rows = []
    for row in sorted_rows:
        display_rows.append(
            {
                "account": str(row["account"]),
                "five_hour": format_percent(row.get("five_hour_percent")),
                "weekly": format_percent(row.get("weekly_percent")),
                "weekly_reset": format_cst(row.get("weekly_reset_at")),
            }
        )

    headers = {
        "account": "account",
        "five_hour": "five_hour%",
        "weekly": "weekly%",
        "weekly_reset": "weekly_reset",
    }
    widths = {
        key: max(len(headers[key]), max(len(item[key]) for item in display_rows))
        for key in headers
    }

    print(
        f"{headers['account']:<{widths['account']}}  "
        f"{headers['five_hour']:>{widths['five_hour']}}  "
        f"{headers['weekly']:>{widths['weekly']}}  "
        f"{headers['weekly_reset']:<{widths['weekly_reset']}}"
    )
    for item in display_rows:
        print(
            f"{item['account']:<{widths['account']}}  "
            f"{item['five_hour']:>{widths['five_hour']}}  "
            f"{item['weekly']:>{widths['weekly']}}  "
            f"{item['weekly_reset']:<{widths['weekly_reset']}}"
        )


def validate_token_inputs(
    token: str,
    account_id: str,
    auth_token: str | None,
    auth_account_id: str | None,
) -> int | None:
    if token.startswith("sess-"):
        print("status: invalid_token_type", file=sys.stderr)
        print(
            "message: --chatgpt-token looks like a session token (sess-...). Use the JWT access_token instead.",
            file=sys.stderr,
        )
        if auth_token:
            print(
                "hint: Found tokens.access_token in auth.json; omit --chatgpt-token or pass that value instead.",
                file=sys.stderr,
            )
        return 1

    token_exp = decode_jwt_exp(token)
    if token_exp is not None and token_exp <= datetime.now(UTC):
        print("status: expired", file=sys.stderr)
        print(f"message: access_token expired at {format_dt(token_exp)}", file=sys.stderr)
        if auth_token and auth_token != token:
            auth_token_exp = decode_jwt_exp(auth_token)
            hint = format_dt(auth_token_exp) if auth_token_exp else "unknown time"
            print(f"hint: auth.json contains a different access_token expiring at {hint}", file=sys.stderr)
        return 1

    if auth_account_id and account_id != auth_account_id:
        print("warning: supplied --account-id does not match auth.json tokens.account_id", file=sys.stderr)

    return None


def handle_error_response(response: requests.Response, data: Any, raw_json: bool) -> int | None:
    if response.status_code == 401:
        print("status: expired", file=sys.stderr)
        print("message: Token 已过期或无效", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code == 403:
        print("status: forbidden", file=sys.stderr)
        print("message: 账号已被封禁或无权访问", file=sys.stderr)
        if raw_json:
            print_json(data)
        return 3

    if response.status_code >= 400:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print_json(data)
        return 3

    return None


def fetch_chatgpt_usage(auth_path: Path, args: argparse.Namespace) -> tuple[int, JSONDict | None]:
    auth_data = load_auth_json(auth_path)
    account_name = get_account_name_from_path(auth_path)
    auth_token = get_nested_string(auth_data, "tokens", "access_token")
    auth_account_id = get_nested_string(auth_data, "tokens", "account_id")

    if not auth_data:
        print(f"{account_name}: auth file not found or invalid", file=sys.stderr)
        return 1, None

    if not auth_token:
        print(f"{account_name}: missing access_token", file=sys.stderr)
        return 1, None

    if not auth_account_id:
        print(f"{account_name}: missing account_id", file=sys.stderr)
        return 1, None

    validation_error = validate_token_inputs(
        auth_token,
        auth_account_id,
        auth_token,
        auth_account_id,
    )
    if validation_error is not None:
        return validation_error, None

    headers = {
        "Authorization": f"Bearer {auth_token}",
        "Accept": "application/json",
        "ChatGPT-Account-Id": auth_account_id,
        "Origin": "https://chatgpt.com",
        "Referer": "https://chatgpt.com/",
        "User-Agent": "Mozilla/5.0",
    }

    try:
        response = requests.get(args.chatgpt_url, headers=headers, timeout=60)
    except requests.RequestException as exc:
        print(f"Request failed: {exc}", file=sys.stderr)
        return 2, None

    if args.raw_headers:
        print("=== Headers ===")
        print_json(dict(response.headers))
        print()

    try:
        data = response.json()
    except ValueError:
        print(f"HTTP {response.status_code}", file=sys.stderr)
        print(response.text, file=sys.stderr)
        return 3, None

    error_response = handle_error_response(response, data, args.raw_json)
    if error_response is not None:
        return error_response, None

    if args.raw_json:
        print("=== Raw JSON ===")
        print_json(data)
        print()

    rate_limits = first_dict(data, "rate_limit", "rate_limits")

    if rate_limits is None:
        return 0, build_summary_row(account_name, None, None)

    five_hour, weekly = parse_rate_limits(rate_limits)
    return 0, build_summary_row(account_name, five_hour, weekly)


def main() -> None:
    args = parse_args()
    auth_paths = get_auth_paths(args.account_dir, args.account_name)
    if not auth_paths:
        print("No auth files found.", file=sys.stderr)
        sys.exit(1)

    exit_code = 0
    summary_rows: list[JSONDict] = []
    for auth_path in auth_paths:
        current_exit_code, summary_row = fetch_chatgpt_usage(auth_path, args)
        exit_code = max(exit_code, current_exit_code)
        if summary_row is not None and not args.raw_json:
            summary_rows.append(summary_row)

    if summary_rows:
        print_summary_rows(summary_rows)
    sys.exit(exit_code)


if __name__ == "__main__":
    main()

AI を使用して Hugo の多言語ブログを維持するエージェントスキル

Mon, 06 Apr 2026 10:00:00 +0800

Hugo の多言語ブログを維持している場合、頻繁に次のような問題点に遭遇するでしょう。

中国語を作成した後、英語バージョンと繁体字中国語バージョンを同時に生成する必要があります。
3 つの言語ファイルは一貫した構造を持っている必要があります
前付は翻訳され、Hugo 形式に準拠する必要があります

sync-post-translations は、このシナリオ用に設計されたエージェントスキルです。

このスキルはどのような問題を解決しますか?

sync-post-translations のポジショニングは非常に明確です。

index.zh-cn.mdをソースファイルとして取得します
同じディレクトリ内で index.en.md、index.zh-tw.md を生成または更新します
マークダウン構造の一貫性を保つ
前付に明確なルールを適用する (特に date、slug)

適用可能なトリガーワードの例:

「英語と繁体字の同時通訳」
「この記事を英語と繁体字中国語に同期します」

スキルのディレクトリ構造

.\sync-post-translations\
├─ SKILL.md
└─ agents\
   └─ openai.yaml

コアコード 1: SKILL.md

以下は、このスキルのコアルールファイルです。

---
name: sync-post-translations
description: 将 Hugo 文章从简体中文源文件（`index.zh-cn.md`）同步翻译为英文（`index.en.md`）和繁体中文（`index.zh-tw.md`）。当用户提出“en 繁体”“同步翻译英文繁体”或要求同时生成/更新两种语言版本且需保持 front matter 与 Markdown 结构一致时使用。
---

# 同步文章翻译

使用此技能为同一篇文章生成或更新多语言版本。

## 工作流程

1. 在目标文章目录中定位源文件 `index.zh-cn.md`。
2. 读取完整 front matter 与正文内容。
3. 在同目录创建或更新 `index.en.md` 与 `index.zh-tw.md`。
4. 确保三语结构对齐后执行 Hugo 构建检查。

## 翻译规则

1. 严格保留 `slug` 原值。
2. `date` 统一规范为 Hugo 常用带时间格式（RFC3339），示例：`2026-04-05T10:00:00+08:00`。
3. 自然翻译以下 front matter 字段：`title`、`description`、`tags`、`categories`。
4. 保持 Markdown 结构不变：标题层级、列表形态、代码块、链接与命令行示例。
5. 技术标识符保持原样：文件名、CLI 参数、模型名、设备名、URL、包名等。
6. 若 YAML 的 `title` 含有 `:`，必须加引号，避免解析报错。
7. 在不改变语义前提下，使用目标语言自然标点与表达习惯（`en`、`zh-tw`）。

## 输出约定

1. 仅在源文章同目录写入目标文件。
2. 汇报变更的文件路径。
3. 条件允许时执行 `hugo --source . --destination public`，并反馈通过/失败；失败时给出关键报错行。

## 质量标准

1. 全文术语前后一致。
2. 避免机器直译感，优先可发布文风。
3. 章节内容完整，不省略示例、注意点与总结。

コアコード 2: エージェント/openai.yaml

このファイルは、エージェント側のスキルの表示とデフォルトのプロンプト単語を定義します。

interface:
  display_name: "同步文章翻译"
  short_description: "生成或更新 EN + ZH-TW 翻译稿"
  default_prompt: "使用该技能在同一 Hugo 文章目录中，从 `index.zh-cn.md` 生成或同步 `index.en.md` 与 `index.zh-tw.md`，保留 `date` 与 `slug`，保持 Markdown 结构一致，并执行 Hugo 构建校验。"

実際の通話例

1) 人間指向の自然言語トリガー

1
2

请把 content/post/2026/04/06/index.zh-cn.md 同步翻译成英文和繁体，
要求 date 用 RFC3339，slug 不变，最后跑 hugo 校验。

2) 期待される出力

已更新：
- content/post/2026/04/06/index.en.md
- content/post/2026/04/06/index.zh-tw.md

构建校验：
- hugo --source . --destination public
- 结果：PASS

これらのルールが重要な理由

slug は変更されず、URL と過去の外部リンクを安定させることができます。
date RFC3339 (タイムゾーン付き) を統合して、時間解像度における Hugo/トピックの曖昧さを回避します。
Markdown 構造は変更されないため、翻訳されたディレクトリ、コードブロック、ショートコードのレンダリングの位置がずれることを回避できます。
技術識別子は翻訳されないため、「コマンドが使用できない/ファイル名が一致しない」問題が大幅に減少します。

よくある落とし穴と回避策

title に : があっても引用符がない場合、YAML は解析に失敗します。
--flag、URL、パッケージ名を変換すると、サンプルコマンドはそのまま無効になります。
3 つの言語のタイトルレベルは一貫性がなく (たとえば、中国語の ## は英語の ### になります)、ディレクトリアンカーの位置がずれます。
前付を加工せずに本文だけを翻訳すると、ページ一覧やSEO情報が異常になります。

VS CodeでCodexを使う方法（インストールから効率的な実践まで）

Fri, 20 Mar 2026 00:00:00 +0000

Codex は、コードの作成、バグの修正、プロジェクトの説明、VS Code サイドバーでのコマンドの直接実行に役立ちます。

1. 準備

始める前に、次のことを確認してください。

VS Code は新しい安定バージョンに更新されました。
OpenAi Web サイトには通常どおりアクセスできます
プロジェクトコードはローカルで開かれています (Git リポジトリが推奨されます)。

2. 拡張機能をインストールする

VS Code 拡張機能マーケット (Extensions) をオープンします。
Codex - Codex - OpenAI's coding agent を検索してインストールします。
インストールが完了したら、プロンプトに従ってログイン認証を完了します。

3.コーデックスのサイドバーを開きます

任意の方法で開くことができます。

エディターの右上隅にある Open Codex Sidebar をクリックします。
コマンドパネル (Ctrl + Shift + P) を使用して、Codex を検索して開きます。

Codex を開いた後、現在のワークスペースコンテキストを読み取り、会話状態に入ります。

4. 一般的な使用方法

4.1 コードを解釈させる

プロンプトの単語の例:

`1`	`请解释这个文件的核心逻辑，并指出最可能出错的 3 个地方。`

古いプロジェクトを引き継ぐ場合に、グローバルな理解を迅速に確立するのに適しています。

4.2 機能させる

プロンプトの単語の例:

1
2

在现有 API 里新增一个 /healthz 健康检查接口，
要求返回版本号和数据库连接状态，并补上基础测试。

生成される結果がより安定するように、「入力制約」と「受け入れ基準」を一緒に明確に記述することをお勧めします。

4.3 問題を解決してもらう

プロンプトの単語の例:

1
2

这个接口在并发下偶发 500，请先定位根因，再给出最小改动修复方案，
最后列出回归测试点。

最初に「位置を特定」してから「修復」することで、誤った修正や過度の再構築を減らすことができます。

5. 高品質のプロンプト Word テンプレート

次の構造を直接再利用できます。

背景：这是一个 <技术栈> 项目，当前目标是 <目标>
约束：不改动 <模块/接口>，兼容 <版本/平台>
输出：
1) 修改文件列表
2) 关键代码说明
3) 验证步骤
4) 风险与回滚方案

このテンプレートは、「複数人でのコラボレーション + 大規模プロジェクト」に非常に役立ちます。

6. よくある質問

6.1 無料割り当てについて

ダイアログボックスに「\」と入力し、ステータスを選択します。クォータ、リセット時間などの関連情報が表示されます。

6.2 変更が期待どおりにならない

変更が完了したら、「レビュー」ボタンをチェックして変更の詳細を表示します。満足できない場合は、「元に戻す」ボタンを選択して変更を元に戻します。次のステップでは、要件を複数のステップに分割して個別に実行できます。 git などのコード管理ツールを使用して、小さなステップでコミットを維持し、ロールバックを容易にします。

Codex on KnightLiブログ

Scientific Agent Skills：研究ワークフローを AI Agent に渡すためのスキルライブラリ

まず結論

何が含まれるか

データベースと Python パッケージ

典型的な場面

インストール方法

実行環境

普通の prompt 集との違い

セキュリティと信頼境界

向いている人

使い方のすすめ

まとめ

Codex が ChatGPT モバイルからのリモートアクセスに対応、Enterprise ワークスペースで Access Tokens が利用可能に

今回の更新内容

モバイルリモートアクセスが解決する問題

開発者にとっての価値

Access Tokens が解決する問題

普通の API key ではない

安全な初期設定：Remote Control はデフォルトでオフ

利用前に必要な更新

企業での Codex 利用への影響

注意すべき境界

まとめ

Codex の利用上限はなぜ突然リセットされるのか？Usage Limits の履歴と情報源

まず結論

このスクリーンショットが示していること

なぜ Codex のリセットは予告なしに見えるのか

これまでの主なリセットの型

1. 2026 年 2 月：リリース期と一時的な増量

2. 2026 年 3 月：ランダムなリセットと異常消費の議論

3. 2026 年 4 月：成長マイルストーンと有料プランのリセット

4. 2026 年 5 月：障害補償型のリセット

リセットの理由をどう判断するか

情報源の信頼性を分けて見る

まとめ

Codexのモバイルリモートアクセス：ChatGPT AppでMac上の開発タスクを追跡する

できること

必要条件

制限

接続方法

スマートフォンでやるべきこと

よくある問題

向いている場面

まとめ

参考資料

Superpowers：Coding Agent を工学プロセスへ戻す skills フレームワーク

解決したい問題

対応ツール

基本 workflow

Skills Library

普通の prompt との違い

向いている場面

注意点

まとめ

Vibe Coding を拒む：Matt Pocock の skills リポジトリが AI コーディングに工学的制約を足す

まずアラインメント失敗を防ぐ

ドメイン言語をコンテキストに入れる

TDD で生成速度を制御する

診断ループで複雑な問題を扱う

アーキテクチャを定期的に見る

制限すべきは自由度

Codex /goal vs Claude Code /goal：長いタスクを完了条件まで自動で進める

/goal は何を解決するのか

Codex の /goal：実験機能で、現在のスレッドに紐づく

Claude Code の /goal：完了条件で駆動する複数ターン実行

最大の違い

よい /goal の書き方

/goal が向いている場面

AI コーディングツールへの影響

まとめ

参考資料

Codex は中国系 LLM とどう接続する？CCX で OpenAI 互換 API を一元管理する

CCX が解決すること

対応エンドポイント

アーキテクチャの考え方

CCX と CodexBridge の違い

クイックデプロイ

Docker デプロイ

ソースから実行

`/goal` は何を解決するのか

Codex の `/goal`：実験機能で、現在のスレッドに紐づく

Claude Code の `/goal`：完了条件で駆動する複数ターン実行

よい `/goal` の書き方

`/goal` が向いている場面