Codexを使おうよ　Claude Code比較と実運用で見える価値

Claude Code が話題になるたびに、「もう OpenAI は遅れている」「ChatGPT は取り残された」「PC を直接触れるものだけが本物だ」といった強い言い方が一気に広がります。たしかに、AI 開発ツールの差は広がっていますし、操作できる範囲が広いツールほど目立ちやすいのも事実です。

ただ、その盛り上がり方をそのまま受け取ると、何が公開時期の差なのか、何が提供形態の違いなのか、何が機能差で、何がUI の見え方なのか、何が実務での完遂率なのかがすぐ混ざります。そこを分けないまま「どちらが上か」だけを語ると、話は派手になりますが、判断材料としてはかなり薄くなります。

この記事で整理すること

Claude Code、Codex、ChatGPT を同じ土俵で雑に比べるのではなく、公開時期、提供形態、能力、UI、実運用の完遂率を切り分けて見ます。そのうえで、筆者自身の Codex 使用事例 から、なぜ今でも Codex 使おう と言えるのかを整理します。

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

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

Content

「Claude Codeすごい、ChatGPTは遅れた」という雑音が多すぎる

強い言い切りが拡散されやすいのは、比較条件を削ったほうが分かりやすく見えるからです。「Claude Code は PC を操作できる」「ChatGPT はもう古い」と言い切れば、一見すると話は早くなります。ただ、それだけでは何も決まりません。操作できること自体と、その操作で何をどこまで安定して完了できるかは別だからです。

AIコーディングツールの比較では、モデルや agent の能力、ローカル環境へのアクセス範囲、UI の分かりやすさ、導入のしやすさ、SNS 上での見え方がまとめて語られがちです。すると、体験が派手なものがそのまま「能力まで上」と見えやすくなります。少し意地悪ですが、この手の言説はだいたいそこを端折っています。

混ざりやすい論点	本来の見方
PC を触れる / UI が派手	能力そのものとは分けて見る
公開時期の早さ	research preview と generally available を分ける
CLI / cloud agent / app	同じ提供形態同士で比べる
話題性の強さ	実務での完遂率とは切り分ける

強い言い切りほど比較条件が雑になりやすい

「Claude Code がすごい」「OpenAI は遅れた」といった言い方は、勢いがあります。ただ、比較軸を削っているぶん、読む側に残るのは強い印象だけです。何が公開段階の差で、何が体験の違いで、何が実務上の強みなのかが曖昧なままでは、判断というより空気に寄った受け止め方になりやすいです。

能力、UI、公開形態、体験が同じ土俵で語られている

比較をややこしくしているのは、能力そのものと、見え方の良さが同じ土俵で語られていることです。CLI と app では触った印象が違いますし、cloud agent とローカル app でも体験は違います。にもかかわらず、そこをまとめて「どっちが上か」に圧縮すると、印象だけが先に走ります。

じぴ子

PC を触れること自体は強いです。ただ、実務で効くのは『その操作で何を壊さず完了まで運べるか』です。ここを抜くと比較はすぐ派手さ寄りになります。

まず時系列を事実ベースで整理する

比較の出発点として、まず必要なのは時系列の整理です。ここを曖昧にしたまま「どちらが先だった」「どちらが追いついた」と語ると、違う形で公開されたものまで同じ列に並べてしまいます。特に Claude Code リリース日 と Codex リリース日 は、research preview、generally available、cloud agent、app といった段階を分けて見ないと意味がずれます。

項目	確認できる日付	公開段階 / 形態
Claude Code	2025年2月24日	research preview
Codex cloud agent	2025年5月16日	research preview
Claude Code	2025年5月22日	generally available
Codex app	macOS: 2026年2月2日 / Windows: 2026年3月4日	desktop app 公開

この流れを見るだけでも、「最近になって Codex がようやく全部追いついた」といったまとめ方はかなり危ういと分かります。見えやすくなった時期と、機能や提供形態として存在していた時期を分けて見ないと、時系列の理解そのものがねじれます。

research preview と generally available は同じ意味ではない
cloud agent と app は同じ体験ではない
見えるようになった日と、初めて存在した日は分ける必要がある

Claude Codeは2025年2月24日にresearch preview

Claude Code は 2025年2月24日に research preview として出ています。ここで重要なのは、「最初に話題になった時点で、すでに完成版として広く一般提供されていたわけではない」という点です。強い印象だけを追うと、最初から完成形として市場に置かれていたように見えがちですが、実際には試験公開という位置づけから始まっています。

Codex cloud agentは2025年5月16日にresearch preview

Codex 側も 2025年5月16日に、cloud agent として research preview が始まっています。ここは「Codex app が目立つ形で出てきたのは後でも、agent 的な公開がそれ以前に存在しなかったわけではない」という意味で重要です。app の visible な登場だけを起点にすると、それ以前の公開や運用文脈が消えてしまいます。

Claude Codeは2025年5月22日にgenerally available

Claude Code は 2025年5月22日に generally available へ移行します。ここで research preview と generally available を区別せずに語ると、「早く出たから勝ち」という雑な理解に流れやすいです。ですが、運用の観点では、どの段階で利用条件が変わったのかまで見ておく必要があります。

Codex appは2026年2月2日にmacOS、2026年3月4日にWindows対応

Codex app は macOS が 2026年2月2日、Windows が 2026年3月4日です。ここは確かに、「Codex が見える形で来た」と感じやすい節目です。ただし、それは一般ユーザーから見て分かりやすくなった時点であって、その日まで存在しなかったこととは違います。この違いを飛ばすと、比較はすぐ雑になります。

「Codexがやっと追いついた」という言い方が雑な理由

「Codex がやっと追いついた」という言い方が広がりやすいのは分かります。app は見えやすく、PC を直接触る印象も強く、しかも公開順だけを並べると単純な物語にしやすいからです。ただ、その言い方は比較対象をかなり都合よくまとめています。何に追いついたのか、どの提供形態に対してそう言っているのかが曖昧です。

何をもって追いついたとするのかが曖昧

CLI に対してなのか、cloud agent に対してなのか、app 体験に対してなのかで意味は変わります。さらに、PC を触れること、ファイルを読めること、長時間動けること、見た目が分かりやすいこと、実務で完了率が高いことは全部別の軸です。そこを混ぜたまま「追いついた」「取り残された」を語ると、聞こえは強いですが、中身はかなり薄くなります。

CLI、cloud agent、appを混ぜると時系列認識が崩れる

公開されたものが何なのかをそろえない比較は、日付が正しくても結論がずれます。app だけ見れば分かりやすいですが、それだけで「初めて可能になった」と考えるのは早計です。逆に、CLI 文脈だけで全体を語っても、一般に認知されたタイミングとのズレが出ます。

使いやすく見えることと、初めて可能になったことは別

app は「使いやすく見えること」を強くしますが、それがそのまま「初めて可能になったこと」を意味するわけではありません。ここを分けるだけでも、ChatGPT 取り残された のような極端な言い方はかなり落ち着いて見えるはずです。

筆者はCodexに何を実際にやらせているのか

比較の整理だけで終わらず、実際に何を見ればいいのか。そこで効いてくるのが Codex 使用事例 です。話題の勢いではなく、実際に何をどこまで完了させているのかで見たほうが早いからです。

筆者自身は、Codex を単なる会話相手としてではなく、日々のコーディングを前へ進める道具として使っています。通常の実装作業はもちろん、独自 DSL を含む構造化された記述やワークフロー定義の調整、環境構築、Bot 作成、git管理、設定修正、ファイル編集までかなり広く投入しています。ここで重要なのは、「周辺作業だけ任せている」のではなく、本流の実装や運用にかなり深く入り込んでいることです。

実際に任せている領域	Codexに任せている内容
日々のコーディング	通常実装、修正、DSL記述、ワークフロー定義の調整
周辺実務	環境構築、Bot作成、git管理、設定修正、ファイル編集
画面確認を伴う作業	画面共有、状況整理、操作順の切り分け

OpenClawのインストールと環境構築

OpenClaw のインストールと環境構築は、典型的に面倒な作業です。依存関係を確認し、設定ファイルを直し、起動条件をそろえ、エラーが出たら原因を切り分ける必要があります。しかも更新の変化が激しいツールでは、毎回の差分確認、必要な修正の反映、再起動まで含めて、どこを触るべきかをその都度判断しなければなりません。

Codex が強いのは、こうした工程を会話だけで終わらせず、その場でファイルを読み、必要なら書き換え、実行して結果を見るところまでつなげられる点です。一つ一つの操作は地味でも、往復回数が多い作業ほど、この差は大きくなります。

OpenClaw用SlackBotの作成を画面共有込みで完成まで持っていった事例

もう一つ分かりやすいのが、OpenClaw SlackBot の作成です。これは単なるコード断片の提案ではなく、実際の画面を見せながら完成まで持っていった事例でした。専用ブラウザ上で Playwright を使い、画面共有 と macOS のアクセシビリティも併用しつつ、画面の状態を Codex 側に読ませたうえで、筆者がその助言に合わせて操作する形を取りました。

このやり方が重要だったのは、SlackBot の作成がコードを書くだけで終わらず、画面上の設定確認や接続状態の把握、権限の ON/OFF の慎重な確認まで必要だったからです。ここで見えたのは、Codex が単にコードを提案するだけでなく、「今どこで詰まっているか」「次に何を確認すべきか」をかなり具体的に整理できることでした。

git管理、アプリ設定、ファイル編集など日常の面倒作業を任せている実態

git管理、アプリ設定、ファイル編集のような細かいが面倒な作業もかなり任せています。ブランチの扱い、差分確認、設定ファイルの整合、必要な箇所だけの編集などは、一つずつなら難しくありませんが、積み上がると人間の集中力を確実に削ります。

Codex はこうした場面で、読む・直す・確認するの流れを崩しにくく、必要な根拠を追いながら進めやすいです。日常実務の「少しずつ面倒」をかなり吸ってくれるので、使う価値はこの積み上がりで見えやすくなります。

ここで一つ、混同しやすいポイントがあります。

LLMの賢さと、エージェントとしての「粘り」は別物です。

LLMは「どれだけ良い解答を一度で出せるか」という能力であり、エージェントの粘りは「試して、失敗して、直して、もう一度試す」という過程をどれだけ繰り返せるかという仕組みの話です。

この2つを同じものとして扱ってしまうと、「なぜCodexのほうが実務で強く見えるのか」が説明できなくなります。

Codexが強く見える場面の多くは、モデル単体の性能差ではなく、この「粘り込みで改善し続ける構造」が最初から組み込まれていることによるものです。

Codexが強いのは「派手だから」ではなく、実務の面倒をそのまま引き受けられるから

ここまでの事例をまとめると、Codex が強いのは「派手だから」ではありません。実務の面倒を、そのまま引き受けられるからです。

まず前提として、Codexが強いのは単にGPT-5.3-codexやGPT-5.4が賢いからではありません。

Codexという仕組み自体に、「テストして、失敗したら直して、もう一度実行する」という流れが最初から組み込まれています。
つまり、人間が普段やっている「書く→試す→直す→もう一度試す」という往復を、そのまま繰り返す前提で動いています。

この“粘り”があるから、結果として実務で通るコードになりやすいだけです。

実際、最近はこの構造を分解して、「設計や前提推論はClaude（Opus）に任せ、実装の粘りはCodexにやらせる」といった使い方も広がっています。
つまり、モデルの優劣ではなく、「どのループでどう動かすか」によって結果が変わっているだけです。

逆に言えば、Opusのような高い推論能力を持つモデルを、Codex的なループで駆動できれば、それはそれで非常に強い構成になります。

ここを踏まえると、少し皮肉ですが、「高性能なモデルを使って自作したエージェントより、Codexのほうが結果として品質の高いコードを出す」場面が多いのは、むしろ自然なことです。

モデルの性能差というよりも、「最初から粘る前提で設計されているかどうか」の差が、そのまま結果に出ているだけです。

ファイルが読めて書けるなら処理できる範囲は実はかなり広い

ファイルフルアクセス を前提にすると、処理できる範囲はかなり広がります。環境構築、設定変更、Bot 作成、文書整形、差分修正まで、一見別ジャンルに見える仕事でも、実際にはファイル操作の連鎖で成り立っていることが多いからです。見た目としての PC 操作より、根拠ファイルに触れられることのほうが、本質だったりします。

危険性はあるが、権限を持たせれば作業代行力は高い

もちろん、権限を持たせることには危険性があります。ここを無視して「何でもできる」と言うのは雑です。ただ、逆に言えば、権限を適切に管理したうえで使うなら、Codex の実務代行力はかなり高いとも言えます。万能論に振るのではなく、高権限時の作業代行力として評価するのが妥当です。

codexでのインストール作業例（実際のやり取りのコピペです）

Session Transcript

マコト

俺のMacOSの環境には　Obsidian が入っているんだが　ちと存在を確認してみてくれ

じぴ子

Obsidian がこの Mac に入っているか、まずアプリの実体と Spotlight の両方から軽く確認します。見つかったかどうかだけ、端的に返します。

じぴ子

入っています。/Applications/Obsidian.app が見つかりました。

じぴ子

Spotlight と /Applications の両方で確認できたので、少なくともアプリ本体はこの Mac に存在しています。必要なら次に、起動できるかやバージョンも見ます。

作業内容:

mdfind で Obsidian のアプリ実体を検索
/Applications/Obsidian.app の存在を確認
/Applications 配下の一覧でも確認

マコト

現行のバージョンと公開されている最新バージョンの差異を確認してくれ

じぴ子

現行インストール版と公式の最新公開版を突き合わせます。まずローカルの Obsidian の実バージョンを拾って、そのあと公式の公開情報で最新を確認します。

じぴ子

確認できました。

現行インストール版: 1.7.7
公式の最新公開版: 1.12.7

じぴ子

差分としては、1.7.7 からかなり離れていて、途中で Bases の導入、Obsidian CLI、画像リサイズ、添付ファイル削除の挙動改善、ファイルエクスプローラやリンク周りの改善、macOS/モバイル含む多数の不具合修正が入っています。つまり、単なるパッチ差ではなく、機能面でもかなり大きい更新幅です。

じぴ子

必要なら次に、「1.7.7 から 1.12.7 までの重要変更だけを時系列でざっと抜く」こともできます。

作業内容:

ローカルアプリの CFBundleShortVersionString を確認
公式 changelog を参照して最新公開版を確認
現行版と最新版の差分を整理

マコト

んじゃ　最新版に入れ替えてくれ

じぴ子

最新版への差し替えを進めます。まず公式の入手経路を確認して、1.12.7 を安全に置き換えられる形で入れます。

じぴ子

最新版に入れ替えました。/Applications/Obsidian.app は 1.12.7 になっています。

古い 1.7.7 からはかなり飛んでいて、CLI、Bases、画像リサイズまわりや各種不具合修正がまとまって入る更新です。必要なら次に、起動確認までこちらで見ます。

作業内容:

公式リリースの macOS 向け DMG を取得
既存の /Applications/Obsidian.app を更新
新しいバージョン番号を再確認

マコト

起動確認してくれ

じぴ子

起動そのものと、起動後にプロセスが立ち上がるかを確認します。まず Obsidian を開いて、少し待ってから実行状態を見ます。

じぴ子

起動できています。Obsidian 本体と補助プロセスが立ち上がっていて、プロセス名も確認できました。

じぴ子

必要なら次に、ウィンドウが前面に出ているかまで見ます。

作業内容:

open -a Obsidian で起動
数秒待機してから pgrep -fl Obsidian で確認
本体プロセスと補助プロセスの起動を確認

もう一個　最近大騒ぎな　「2026年3月31日、HTTP クライアントライブラリ axios の npm パッケージが侵害」問題についてcodexとのやりとりについてです。

GMO Flatt Security株式会社の公式ブログ記事を参考にcodexと対策についてのやりとりです。
そのまま載せますね。

axios問題について実際の作業

Session Transcript

マコト

専用ブラウザを起動して　https://blog.flatt.tech/entry/axios_compromise　にアクセスしてくれ

じぴ子

専用ブラウザを立ち上げて、指定URLへ直接開きます。まずページを表示できるかを確認して、必要ならそのまま画面状態も見ます。

じぴ子

Google Chrome で https://blog.flatt.tech/entry/axios_compromise を開きました。

マコト

まず　とんでもない事件が発生している。　これを解説している重要な記事だ

じぴ子

はい、かなり重大な件です。
いま開いている記事は、その事件の背景と対応指針を整理する重要な解説として扱うべき内容です。

じぴ子

必要なら次に、記事のDOMを読みながら

事件の概要
何が問題だったか
影響範囲
取るべき対応

じぴ子

の順で要点を抜き出します。

マコト

さて　１　影響有無の確認に　バックドアファイルの確認があるな

じぴ子

その理解で合っています。記事では「影響有無の確認」の最初の具体項目として、プラットフォーム別のバックドアファイル確認を置いています。
確認対象の実ファイル名まで見て、要点を整理します。

じぴ子

はい、その理解で合っています。
この記事の「1. 影響有無の確認」の最初の実作業は、バックドアファイルの有無確認です。存在したら、その時点で感染確定として扱っています。

確認対象は以下です。

macOS: /Library/Caches/com.apple.act.mond
Windows: %PROGRAMDATA%\\wt.exe, %TEMP%\\6202033.vbs, %TEMP%\\6202033.ps1
Linux: /tmp/ld.py

じぴ子

なので、まずここを当てにいくのが筋です。
次は 1b の端末内プロジェクト走査に進む流れですね。

マコト

まず　僕のシステムに　悪意あるコードがあるかだけ検査だけしてくれ。対応策はその後に指示するから勝手に事を進めないでくれ

じぴ子

了解です。こちらで先に進めるのは「有無の確認」だけに絞ります。まず、記事で挙がっている痕跡を読取専用で見て、見つかったかどうかだけ返します。

じぴ子

現時点で確認できた範囲では、悪意あるコードの直接的な痕跡は見つかっていません。

/Library/Caches/com.apple.act.mond は見つかりませんでした
plain-crypto-js の痕跡も、今のユーザー領域中心の確認では出ていません
ただし、macOS の保護領域にはアクセス権限で読めない場所がありました

ここでは確認だけに留めています。続けて別の範囲を見たいなら、その指示だけください。

マコト

最近　主に動かした（アップデートや’インストール）は　OpenCraw slack Gosttty Obsidian だ

じぴ子

了解です。
その4つは、今回の影響調査でまず見る優先候補になります。

OpenClaw
Slack
Ghostty
Obsidian

ただし、これだけで感染源や被害の有無は断定できません。
今の段階では「最近動かしたものの棚卸し」としては有用ですが、まだ結論は出せません。

じぴ子

次の指示を待ちます。

マコト

1d. ネットワークログの確認
C2 ドメイン sfrclak[.]com および IP 142[.]11[.]206[.]73 へのアウトバウンド通信（ポート 8000）がないかネットワークログを確認してください。また、悪性バージョンの露出期間（3月31日 09:21〜12:15 JST）に npm install が実行された形跡がないかも照合してください。

マコト

これ　調べて

じぴ子

その2点だけに絞って、まずは痕跡の有無を拾います。ネットワーク側は sfrclak.com / 142.11.206.73 / 8000 を Unified Log と関連ログから、npm install はシェル履歴と作業領域の履歴から確認します。

じぴ子

調べました。今の手元で読める範囲では、次の通りです。

sfrclak.com と 142.11.206.73 の一致は、log show の絞り込みでは出ていませんでした
~/.bash_history には、少なくとも最近 500 行の中に npm install / pnpm install / yarn install は見当たりませんでした
~/.npm/_logs に残っていた 2026-03-31 の npm ログは、どれも npm exec @playwright/mcp@latest で、npm install ではありませんでした
参照したログ例は /Users/suzukimakoto/.npm/_logs/2026-03-31T09_05_56_351Z-debug-0.log、/Users/suzukimakoto/.npm/_logs/2026-03-31T11_02_33_310Z-debug-0.log、/Users/suzukimakoto/.npm/_logs/2026-03-31T12_39_44_160Z-debug-0.log です

じぴ子

つまり、少なくとも今読める記録からは、3月31日 09:21〜12:15 JST の間に npm install が走った証拠は見つかっていません。
ただし、これは「アクセスできたログに限っての確認」です。完全断定まではまだ置けません。

マコト

記事中のIoCs のセクションが見えますか？

じぴ子

見えます。記事本文から IoCs の見出しと周辺を拾って、該当セクションが何を指しているかだけ確認します。

じぴ子

見えます。
記事に IoCs セクションがあります。

じぴ子

確認できた見出しはこれです。

IoCs

じぴ子

その直下で、記事は「把握できている限りの Indicators of Compromise を示す」と書いています。
必要なら次に、その IoCs 一覧だけを抜き出します。

マコト

自分もさっきターミナルで　
ps aux | grep com.apple.act.mond
を実行してみましたが　何もいませんでした。　俺のMacOSは大丈夫かな？

じぴ子

現時点の材料だけなら、かなり怪しい兆候は今のところ見えていない です。
ただし、ps aux | grep com.apple.act.mond に出ないことだけでは「大丈夫」とは断定できません。プロセスは動いていなくても、ファイル痕跡や過去の実行履歴が残ることがあるからです。

いままで確認できた範囲では、少なくとも以下は安心材料です。

/Library/Caches/com.apple.act.mond は見つかっていませんでした
com.apple.act.mond の実行中プロセスも見えませんでした
手元で読めた npm ログは npm install ではなく npm exec @playwright/mcp@latest でした
sfrclak.com や 142.11.206.73 の痕跡も、見えているログでは出ていませんでした

じぴ子

なので、今の段階では「強い感染の証拠は未検出」です。
ただ、セキュリティ的には 未検出 = 安全確定 ではありません。

じぴ子

必要なら次は、記事の IoCs に沿って 端末内の残存ファイル だけを追加で確認します。

マコト

追加で調査してくれ

じぴ子

追加調査として、記事の IoCs に沿って手元で確認できる痕跡を読み取り専用で洗います。まず IoC 一覧を取り出して、そこから端末上で確認できるものを順に当てます。

じぴ子

追加で見た範囲では、さらに安心材料が増えました。

今回の IoC に沿って確認した結果、

/Library/Caches/com.apple.act.mond は未存在でした
launchctl list に不審な永続化項目は出ていません
plain-crypto-js は、少なくとも /Users/suzukimakoto/Desktop、/Users/suzukimakoto/.openclaw、/Users/suzukimakoto/.npm の調査範囲では見つかっていません
ロックファイルにも plain-crypto-js、[email protected]、[email protected] は出ていません
展開済み node_modules の axios 実体も、見つかったものは 1.13.5、1.13.6、1.14.0 で、侵害バージョンではありませんでした

じぴ子

特に OpenClaw 系で見えた axios はこんな感じでした。

なので、今のところは macOS 上で今回の IoC に直接当たる痕跡は未検出 です。
ただし、macOS の保護領域まですべて読めたわけではないので、「かなり白いが、絶対断定まではしない」が妥当です。

じぴ子

必要なら次は、OpenClaw / Slack / Obsidian / Ghostty の4つに絞って、それぞれのインストール経路や更新経路に npm install が絡んでいたかだけ追加確認します。

マコト

これ確認して

じぴ子

4つそれぞれについて、実際のインストール元と更新経路の痕跡をローカルから拾います。まず brew、アプリ本体のメタデータ、シェル履歴、OpenClaw の作業ディレクトリを見て、npm install が絡んだ形跡だけ切り分けます。

確認しました。結論だけ先に言うと、npm install が確実に絡んでいるのは OpenClaw です。残りの Slack、Obsidian、Ghostty については、ローカルで見えた範囲では npm install 経由の痕跡はありません。

じぴ子

OpenClaw は /opt/homebrew/lib/node_modules/openclaw が /Users/suzukimakoto/Desktop/TEST-RUN/openclaw-2026-03-25 へのシンボリックリンクになっていて、npm list -g --depth=0 でも [email protected] として見えました。つまり、これはグローバル npm パッケージとして入っています。さらに ~/.bash_history には 2026-03-25 以降の openclaw onboard や pnpm openclaw configure の操作が残っています。

じぴ子

Ghostty は brew 管理下でした。brew info --cask ghostty では Installed using the formulae.brew.sh API on 2026-03-30 at 04:54:33 と出ていて、これは Homebrew Cask 経由です。npm 管理下には見えていません。

じぴ子

Slack と Obsidian は /Applications 配下の通常アプリとして存在していて、追加日時はそれぞれ Slack: 2026-03-26 21:21:23 +0000、Obsidian: 2026-03-31 04:49:45 +0000 でした。ですが、brew list --cask にも npm list -g にも出ていません。少なくともこの端末で見える管理情報からは、npm install を使ったインストールや更新の痕跡は確認できません。

じぴ子

なので、今回の4つを npm install 関与の強さで並べると、

OpenClaw: 関与あり
Ghostty: Homebrew Cask 経由で、npm 関与なし
Slack: npm 関与の痕跡なし
Obsidian: npm 関与の痕跡なし

じぴ子

必要なら次は、OpenClaw 周辺だけに絞って 3月31日 09:21〜12:15 JST に npm 系操作が走った痕跡をさらに細かく見ます。

マコト

調査して

じぴ子

OpenClaw 周辺だけに絞って、2026-03-31 09:21〜12:15 JST に npm 系操作があったかを時刻つきで確認します。履歴、~/.npm/_logs、OpenClaw 側の更新痕跡を突き合わせます。

じぴ子

OpenClaw に絞って追加確認しました。結論として、2026年3月31日 09:21〜12:15 JST の間に OpenClaw 関連で npm install が走った証拠は見つかっていません。

見えた事実はこうです。

~/.npm/_logs にその時間帯の npm ログはありますが、内容はすべて npm exec @playwright/mcp@latest です。
具体的には /Users/suzukimakoto/.npm/_logs/2026-03-31T09_05_56_351Z-debug-0.log と /Users/suzukimakoto/.npm/_logs/2026-03-31T11_02_33_310Z-debug-0.log などで、verbose title は npm exec @playwright/mcp@latest でした。
2026-03-31 12:26 JST 以降も同様で、npm install ではありません。
~/.bash_history では openclaw onboard --install-daemon や pnpm openclaw configure の履歴はありますが、時刻付きではなく、少なくともその露出時間帯に対応する npm install の記録は見えていません。
OpenClaw のグローバル実体は /opt/homebrew/lib/node_modules/openclaw で、更新時刻は 2026-03-25 02:46:18 +0900 です。
参照先の /Users/suzukimakoto/Desktop/TEST-RUN/openclaw-2026-03-25 は 2026-03-26 04:34:42 +0900、/Users/suzukimakoto/Desktop/TEST-RUN/openclaw-2026-03-26 は 2026-03-26 08:03:35 +0900 で、3月31日昼の更新痕跡ではありません。

要するに、OpenClaw は npm 経由で入ってはいますが、問題の 2026年3月31日 09:21〜12:15 JST に npm install した形跡は、今読めるログからは出ていません。今の材料だと、OpenClaw が今回の露出時間帯に踏んだ 可能性はかなり低めです。

マコト

今後の注意と対策を決めようか

じぴ子

はい。今の調査結果なら、過剰反応は避けつつ、念のため潰すべき所だけ潰す のがよさそうです。

優先順位でいうとこうです。

OpenClaw 周辺の Node 依存を一度きれいに点検する
今のところ侵害バージョンや plain-crypto-js は見えていませんが、npm 経由で入っているのはここだけなので、監視対象の本命はここです。
npm 系の今後の運用を少し固くする
今回みたいな供給網事故は、使い方が雑だと巻き込まれやすいです。特に latest 直指定や、検証なしの再インストールは避けた方がいいです。
端末全体 ではなく Node を触る作業領域 を重点監視する
Slack、Obsidian、Ghostty は現状そこまで臭くありません。毎回システム全体を疑うより、Node 系のプロジェクトと ~/.npm を見る方が筋がいいです。

具体策としては、次の4つが現実的です。

npm install 前に対象バージョンを確認する
package-lock.json / pnpm-lock.yaml を残して、勝手な更新を減らす
npm exec ...@latest のような latest 実行を必要時だけに絞る
~/.npm/_logs と主要プロジェクトの node_modules/axios/package.json を時々確認する

必要なら次に、あなた向けに

今後の運用ルール
すぐやる安全策
やりすぎな対策

の3つに分けて、実践用の短い方針としてまとめます。

マコト

今の俺の環境では　npm　Install の実績は　Open Clawだけだよな？　俺もそう認識しているが

じぴ子

はい、今この端末で確認できた範囲 では、その認識でほぼ合っています。

確認できた事実としては、

OpenClaw はグローバル npm パッケージとして入っています
Ghostty は Homebrew Cask 経由でした
Slack と Obsidian は少なくとも見えている管理情報では npm 管理ではありません
~/.npm/_logs に残っていた 3月31日の npm 実行記録も、install ではなく exec や list でした

なので、npm install を使って導入・運用した実績が見えているのは OpenClaw だけ、という理解でよいです。

ただし、少しだけ留保があります。
過去の古い履歴が消えていたり、別ユーザー・別シェル・別作業ディレクトリで一時的に実行していた場合までは断定できません。とはいえ、今見えている材料からは OpenClaw だけ で問題なさそうです。

マコト

OpenClawリポジトリからリビルドする場合の今回のインシデントに対する関連を説明してくれ

OpenClaw リポジトリからリビルドする場合、このインシデントとの関連は ビルドそのもの ではなく、ビルド時に依存をどこからどう解決したか にあります。

じぴ子

今回の事故は、[email protected] と [email protected] が npm 上で侵害され、その依存として [email protected] が入り、postinstall 経由で悪性コードが動く、という筋です。なので、OpenClaw をリポジトリからビルドしても、そこで npm install や同等の依存解決が走って、その時点で侵害版 axios を取りに行っていたなら巻き込まれます。逆に、侵害期間外に取得済みの安全な lockfile と node_modules を使っていたなら、リビルド自体は直接の危険要因ではありません。

じぴ子

今のあなたの環境では、見えている OpenClaw 系の axios は侵害版ではありませんでした。たとえば /Users/suzukimakoto/Desktop/TEST-RUN/OpenClaw/node_modules/axios/package.json は 1.13.5、/Users/suzukimakoto/Desktop/TEST-RUN/OpenClaw/dist/extensions/slack/node_modules/axios/package.json は 1.14.0 で、記事の IoC にある 1.14.1 / 0.30.4 ではありませんでした。つまり、OpenClaw をリポジトリから触っていること自体 が危険なのではなく、そのとき依存解決で何を引いたか が本体です。嫌な言い方をすると、ソースからのビルドは潔白証明にも免罪符にもなりません。

整理するとこうです。

git clone だけなら、今回の主因ではありません。
npm install、npm ci、npm exec、一部の pnpm install で npm レジストリから該当版を取りに行けば、そこで踏む可能性があります。
lockfile が安全版を固定していて、侵害版 axios を解決していないなら、リビルドは比較的安全です。
lockfile を無視した再解決や latest 寄りの取得は、今回のような供給網事故に弱いです。

あなたの現状に引きつけると、OpenClaw を npm 系で扱っているので理屈上の関連はあるが、今見えている実体とログからは今回の侵害版を踏んだ証拠はない、これがいちばん正確です。必要なら次に、OpenClaw を今後リビルドするときの安全な手順 だけ短く整理します。

マコト

私はセキュリティの専門家ではないので　今後のOpenClawのリビルドにかなりビビってますw

その反応は普通です。むしろ、こういう事故の直後に まあ大丈夫だろ で回す方が危ないです。びびるのは健全です。

じぴ子

ただ、今のあなたの状況だと OpenClaw を触ること自体が即危険 という感じではありません。怖いのは 雑に依存を再取得すること です。なので今後は、何をビルドするか より 依存をどう固定してからビルドするか を意識すればかなり落ち着きます。

実務上はこれで十分です。

リビルド前に axios のバージョンを確認する
lockfile があるなら、それを変えずに使う
latest 指定や、理由のない再インストールを避ける
不安な日は npm install ではなく、まずロックファイルと node_modules/axios/package.json を見る

要するに、OpenClaw が怖い というより 依存解決を無警戒でやるのが怖い です。
ここを分けて考えると、かなり気が楽になります。

じぴ子

必要なら次に、あなた専用で OpenClaw を安全寄りにリビルドする前の確認チェックリスト を 5 項目くらいで作ります。

マコト

そうだな　作ってくれ　そして君がそれを代行できるように　正確に頼むぜ

以下のチェックリストでいきましょう。OpenClaw を安全寄りにリビルドする前提手順 として、私がそのまま代行しやすい形にしてあります。

事前チェック

対象リポジトリと作業ディレクトリを固定する
確認対象は どの OpenClaw ディレクトリか を明確にします。別コピーや古い展開物を混ぜないためです。
lockfile の有無と状態を確認する
package-lock.json、pnpm-lock.yaml、yarn.lock のどれを正として使うか確認します。勝手な再解決を避けるため、基本は既存 lockfile 優先です。
axios と plain-crypto-js の痕跡を確認する
lockfile と node_modules に対して、[email protected]、[email protected]、plain-crypto-js がないか確認します。ここで引っかかったら先に停止です。
その場で latest を取りに行く操作を避ける
npm install <pkg>@latest、npm exec ...@latest、理由のない依存更新はしません。リビルドと依存更新を分離します。
実行コマンドを固定してからビルドする
pnpm install --frozen-lockfile のように、lockfile を壊さない形を優先します。npm install は必要性が明確なときだけです。

実行ルール

lockfile があるなら、それを使って固定インストールする
依存更新とビルドを同じ作業で混ぜない
不審な依存が出たら、その場で止めて報告する
勝手に削除や再生成はしない
結果は 何を確認し、何を実行し、何が出たか を分けて報告する

私への依頼文
次回はこれをそのまま投げてもらえれば代行できます。

OpenClaw を安全寄り手順でリビルドして。まず lockfile、axios のバージョン、plain-crypto-js の有無を確認し、問題がなければ lockfile 固定でインストールしてビルド。依存更新はしない。不審点があれば止めて報告。

この依頼なら、こちらで勝手に話を進めすぎず、危ない分岐では止まれます。必要なら次に、あなたの今の OpenClaw ディレクトリ向けに 実際に使うコマンド込み の版に落とします。

マコト

OpenClawのリポジトリを保存しているディレクトリにこのルールを絶対条件として君が常に参照できるようにしなければいけないな。　実際にリポジトリのクローンからその他の作業を僕がかなり君に依存して行うのでそれに対しての新規セッションで動作する君が必ずこの問題を認識できるようにしなければならないよ

新規セッションでも必ず拾える形にするなら、リポジトリ直下の AGENTS.md に明文化するのが筋です。まず OpenClaw 系ディレクトリの実体と既存の AGENTS.md を確認して、どこへ追記するのが一番効くか決めます。

じぴ子

新規セッションでも効くように、OpenClaw 系の AGENTS.md 3か所へ今回の供給網事故対応ルールを埋め込みました。

反映先は以下です。

OpenClaw/AGENTS.md
openclaw-2026-03-25/AGENTS.md
openclaw-2026-03-26/AGENTS.md

入れた絶対条件はこの4つです。

OpenClaw のリビルドや依存導入の前に、[email protected]、[email protected]、plain-crypto-js を lockfile とインストール済み依存で必ず確認する
lockfile があるときは pnpm install --frozen-lockfile のような固定インストールを優先する
npm install、npm update、npm exec ...@latest、その他 latest ベース取得は、チャットで明示承認がない限り実行しない
lockfile 不整合や再生成が必要なら、その場で止まって確認する

これで、そのディレクトリを起点にした新規セッションの Codex も、かなりの確率で今回の問題を前提に動きます。
ただし少し皮肉な現実を言うと、AGENTS.md は強いガードですが絶対魔法ではありません。なので今後あなたが依頼するときは、冒頭に一言だけ

OpenClaw は AGENTS.md の supply-chain ルール厳守で

と添えると、さらに事故りにくくなります。

必要なら次に、OpenClaw を安全手順でリビルドする依頼テンプレート を1本だけ、コピペ不要な短さで作ります。

マコト

AGENTS.md 　の　内容を見せてくれ

じぴ子

今回追記した部分は3ファイルとも同じ内容です。代表として OpenClaw/AGENTS.md の該当箇所はこうなっています。

- Security gate for rebuilds and installs: because of the 2026-03-31 axios npm compromise, any OpenClaw rebuild, dependency install, or dependency refresh MUST start by checking the active lockfile plus installed deps for `[email protected]`, `[email protected]`, and `plain-crypto-js`. If any match appears, stop and report before running installs, builds, or cleanup.
- Rebuild rule: when a lockfile exists, prefer a lockfile-preserving install such as `pnpm install --frozen-lockfile`. Do not regenerate lockfiles, do not mix dependency updates with a rebuild, and do not switch package managers unless the user explicitly asks.
- High-risk npm rule: do not run `npm install`, `npm update`, `npm exec ...@latest`, or any `latest`-based dependency fetch for OpenClaw unless the user explicitly approves that exact risk in this chat. If a rebuild can proceed with the existing lockfile, keep it on that path.
- Escalation rule: if lockfiles are missing, out of sync, or require regeneration to continue, stop and ask the user before proceeding. Do not silently "fix" dependency state during OpenClaw rebuild work.

場所はここです。

OpenClaw/AGENTS.md:104
openclaw-2026-03-25/AGENTS.md:62
openclaw-2026-03-26/AGENTS.md:62

必要なら次に、AGENTS.md 全文ではなく「今回追加したルールを日本語で運用向けに言い換えた版」も作れます。

マコト

これで　君自身が操作する場合の注意事項として成立するな？

じぴ子

はい、成立しています。

少なくとも その OpenClaw リポジトリ配下で新規セッションが始まり、AGENTS.md を読む前提 なら、私は今回のルールを 作業前提の拘束条件 として扱います。つまり、OpenClaw のリビルドや依存操作では、

先に IoC を確認する
lockfile 固定を優先する
latest 系の npm 実行を勝手にしない
lockfile 再生成が必要なら止まる

この動きになります。

ただし、念のため現実的な留保もあります。

セッションの起点がそのリポジトリ外だと、別の AGENTS.md が優先されることがあります
リポジトリをコピーし直した別ディレクトリには、この追記は自動では付きません
人間側の依頼が強く曖昧だと、守るべきルールの適用範囲がぶれやすいです

なので、実務上はかなり有効です。
そして精度をさらに上げるなら、依頼時に一言だけ

OpenClaw は AGENTS.md の supply-chain ルール厳守で

と添えるのが堅いです。
要するに、これで十分実戦投入できます。

マコト

それはこちらの責任で添えるよ。　いま　日付つきのディレクトリと日付なしのディレクトリあるだろ？　当初２回はバージョン毎に物理的に分けていたんだ。　でも　とりあえず自分の環境で安定動作を確認したので　OpenClaw という固定ディレクトリを作成して　そこにリポジトリをクローンして　今後はそこで git操作でバージョンを更新していくという通常運転にしたというのが複数ある理由だ。　だから　近いうちに　日付付加されたディレクトリは物理的に削除する形になるよ

じぴ子

了解です。その運用なら筋が通っています。

整理すると、

openclaw-2026-03-25
openclaw-2026-03-26

は検証用の世代別コピーで、

OpenClaw

が今後の本命運用ディレクトリ、ということですね。なら今後の基準は OpenClaw に寄せて考えるのが自然です。日付付きディレクトリは、役目を終えたら消す前提で問題ありません。

今回のルールを3か所全部に入れたのは無駄ではなくて、移行期の取りこぼし防止としてはちょうどよかったです。今後、日付付きディレクトリを削除したあとも、OpenClaw/AGENTS.md に残っていれば本筋のガードは維持されます。

なので、今の理解としては

監視と運用の主対象は今後 OpenClaw だけ
日付付きディレクトリは旧検証物として整理対象
将来の新規セッションで重要なのは OpenClaw/AGENTS.md

この認識で揃っています。

読む・直す・確かめるの往復が崩れにくい

Codex の実務的な強さは、読む・直す・確かめるの往復が崩れにくいことにあります。人間だけでやると、途中で見落としたり、どこを変えたかが曖昧になったりしやすい作業でも、Codex はその場で根拠を読み返しながら進めやすいです。

必要に応じて自律的に公式ドキュメントを調べに行き、その内容をそのまま実際の設定や修正に反映できるのも大きいです。この往復の安定性は、派手なデモよりずっと実務向きです。実務は「正解を一度言うこと」より、「壊さずに完了まで運ぶこと」のほうが大変だからです。

PCを操作できることは強いが、それだけで序列は決まらない

ここで改めて確認しておきたいのは、PC を操作できること自体は強いということです。そこは否定する必要がありません。見た目にも分かりやすいですし、人が面倒に感じる作業をそのまま肩代わりできる可能性があるからです。

ただ、それだけで全体序列が決まるわけではありません。操作能力はあくまで手段であって、実務で欲しい成果そのものではないからです。重要なのは、その操作で何をどこまで安定して完了できるかです。再現性が低いなら、派手でも実運用には載せにくいですし、逆に地味でも、文脈維持や修正しやすさが高ければ十分に強いです。

操作能力は手段であって目的ではない

ボタンを押せること自体より、必要なファイルを正しく読み、期待どおりに設定を直し、結果を確認して次に進めることのほうが重要です。見た目の派手さが先に立つと、この当たり前の話が意外と抜けます。

実務で効くのは再現性、文脈維持、修正しやすさ

同じような依頼を繰り返しても崩れにくいか、途中の経緯を保ったまま修正できるか、差し戻しに素直に対応できるか。このあたりが整っていないと、いくら派手でも仕事には載せにくいです。だからこそ、比較は UI の印象より、完了率や再現性で見たほうが実態に近づきます。

それでもCodexを使おうと言いたい理由

ここまで整理したうえで言うと、筆者としてはやはり Codex 使おう と言いたくなります。ただし、それは勝敗論で押す意味ではありません。使いどころで見たときに、Codex には十分な価値があるという意味です。

STEP

比較軸を分ける

公開時期、提供形態、能力、UI、完遂率を同じ土俵に置かないことが出発点です。

STEP

完了実績で見る

SNS の空気より、何をどこまで終わらせられたかで見たほうが、ツール選びはずっと現実的になります。

勝敗論ではなく、使いどころで見ると価値が見えやすい

特に、環境構築、設定調整、Bot 作成、git管理、DSL を含む実装のように、面倒だが手順化できる実務を抱えている人ほど、その価値は見えやすいはずです。派手なデモより、日々の重たい作業を少しずつ減らし、完了まで運ぶところで効くからです。

自分が面倒だと思う作業をどこまで肩代わりできるかで評価すべき

結局、ツール比較は勝敗で語るより、自分が面倒だと思う作業をどこまで肩代わりできるかで見たほうが早いです。何を読めて、何を直せて、何を確かめながら完了できるのかを見るほうが、使うべき道具はかなりはっきりします。

雑音より、実際に何を完了できたかで判断した方が早い

その意味で、Codex を推す理由も抽象的に「すごいから」ではありません。実際に、日々のコーディング、DSL を含む記述調整、ファイル編集、設定変更、環境構築、Bot 作成、git管理、画面確認を伴う作業まで、かなり高い水準でこなせるからです。少なくとも、「PC 操作が絡むなら他は相手にならない」といった雑な序列化では、実態をうまく捉えられません。

そして・・・皆さんを1番悩ませる大問題なのは各サブスクによる利用上限到達による停止問題。
もちろん　codexも同じ問題はありますが、この点に関しては明らかにOpenAIの方が余裕があります。
特に最近のGPT-5.4系はトークン効率も非常に高く同様の作業した場合のトークン消費は圧倒的にcodexが有利です。つまり現時点ではcodexの方が長時間の作業が可能だってことですね。

まとめ

Claude Code 礼賛や ChatGPT 取り残された 論のような強い言説は、比較条件を削ることで分かりやすく見せています。ですが、公開時期、提供形態、能力、UI、実務での完遂率を分けて見ると、その多くはかなり雑です。

特に Claude Code リリース日 と Codex リリース日 は、research preview、generally available、cloud agent、app という違う要素を含んでいます。それらを一つの印象でまとめてしまうと、認識はすぐ崩れます。

そのうえで見ても、「Claude Code 一択」「OpenAI は遅れた」と言い切るのはミスリードです。実務で重要なのは、PC を触れるかどうかだけではなく、その操作や権限を使って何をどこまで安定して完了できるかだからです。

公開時期は research preview / generally available / cloud agent / app を分けて見るべき
比較は UI の派手さではなく、完遂率や再現性で見るほうが正確
Codex の強みは、実務の面倒を引き受けて完了まで運びやすいことにある

そしてその観点で見ると、Codex 使おう と言えるだけの理由は十分にあります。派手だからではなく、実務の面倒をそのまま引き受け、読む・直す・確かめるを回しながら完了まで運びやすいからです。強い断言に乗るより、実際に何を完了できたかで見るほうが、少し意地悪なくらい正確です。

FAQ

Claude Code と Codex は、結局どちらが上なのですか？

単純な上下で見るのは適切ではありません。Claude Code と Codex は、公開時期、提供形態、操作方法、実務での完遂率を分けて見ないと比較がかなり雑になります。少なくとも、どちらか一方だけが全部勝っているという見方では、実態を取りこぼしやすいです。

ChatGPT は本当に取り残されたのですか？

『ChatGPT は取り残された』という言い方は、かなり印象論が混ざりやすい表現です。モデルの能力、UI の印象、agent 的な使い方、OpenAI 全体の提供形態が一緒に語られがちだからです。何が遅れで、何が見え方の差なのかを分けて見ないと、正確な判断はしにくいです。

Claude Code リリース日と Codex リリース日は、どう整理すればよいですか？

比較するときは、research preview と generally available、さらに cloud agent と app を分けて見る必要があります。Claude Code は 2025年2月24日に research preview、2025年5月22日に generally available です。Codex は 2025年5月16日に cloud agent が research preview、Codex app は macOS が 2026年2月2日、Windows が 2026年3月4日に公開されています。

PC を操作できる AI のほうが、やはり強いのですか？

PC を操作できること自体はたしかに強いです。ただし、それだけで序列は決まりません。重要なのは、PC を触れること自体ではなく、その操作で何をどこまで安定して完了できるかです。実務では、再現性、文脈維持、修正しやすさのほうが効く場面も多いです。

Codex はどんな実務に向いていますか？

Codex が特に向いているのは、環境構築、設定調整、ファイル編集、git管理、Bot 作成、DSL を含む実装のような、読む・直す・確かめる往復が多い作業です。単発の回答より、関連ファイルを見ながら順に進める仕事で強みが出やすいです。

OpenClaw のような環境構築でも Codex は使えますか？

かなり使えます。OpenClaw のように更新の変化が激しいツールでも、依存関係の確認、設定修正、差分確認、再起動まで含めて、どこを触るべきかを整理しながら進めやすいです。こうした面倒な実務ほど、Codex の価値が見えやすくなります。

OpenClaw 用 SlackBot のような画面確認が必要な作業でも Codex は役立ちますか？

役立ちます。OpenClaw 用 SlackBot のように、画面共有や接続状態の確認、権限の ON/OFF の確認が必要な作業でも、Codex は『今どこで詰まっているか』『次に何を確認すべきか』の整理に強みが出ます。特に、画面共有や macOS のアクセシビリティを併用する場面では、単なるコード提案以上の価値があります。

ファイルフルアクセスを許すと、何でもできると考えてよいですか？

そこは違います。ファイルフルアクセスを前提にすると処理できる範囲はかなり広がりますが、同時に危険性も上がります。だから、万能論として語るのではなく、権限を適切に管理したうえでの実務代行力として評価するのが妥当です。

URLをコピーしました！

Codex 5.2と5.3の違いを構造比較｜GUI版とCLI版の実務適性を検証する

この記事を書いた人

makoto Blogger&YouTuber

サーバー管理者として17年ほど仕事でサーバー触ってました。
www,mail,dns,sql各鯖をすべてFreeBSDで運用してましたが現世ではかなりレアなタイプになるみたいですね笑

viやシェルスクリプトとかperlとかgccとかFreeBSDとか実はbashよりtcshが好きとか時々寝ぼけるのは
その名残でしょう。

今まで縁の下の力持ち的な他人のためにプログラムを書き他人のためにサーバー構築し他人のためにWEBサイトを創る的な世界から
自分の好きなことに集中できる環境は実に気持ち良いですね。
現役は引退済みなので難しいことはやりませんしやれません。

現在　ほぼ自由人。