Codex CLI 0.147.0、承認自動化とMCP新仕様の設計転換

ガジェット好きの血が、また騒いだ。8月8日の朝、コーヒーを淹れながらOpenAIのchangelogをいつものように開いたら、見慣れない一行が増えていた。--approve-for-meというフラグだ。

正直、最初は「またフラグが1個増えただけか」と流し読みしそうになったが、読み進めるうちに、これは単なる新機能の追加ではないと気づいた。この4日間で、Cursor、Claude、Codexという3社が、それぞれ別の角度から同じ問いに答えを出していたからだ。AIにどこまで任せ、どこで人間が止めるのか、という問いである。

CS出身の私は、こういう「権限をどう設計するか」という話に弱い。前職で契約更新画面のボタン配置ひとつが継続率を左右する現場を見てきたせいか、今回のアップデート群も「便利機能が増えた」だけでは片づけられなかった。この記事では、Codex CLI 0.147.0を軸に、同じ週に起きたCursor・Claudeの動きを時系列で整理する。そのうえで、自分の小さな業務ツール用リポジトリでapprove-for-meを実際に試した範囲まで書いていく。

承認待ちから「レビュー済み承認」へ、Codex CLI 0.147.0が仕込んだ設計転換

Codex CLI 0.147.0は、2026年8月7日にOpenAIが公開した。変更点は7つある。1つ目はAgent Pluginsだ。ローカル・個人用・ワークスペース用・リモートという4種類のカタログを横断して、プラグインを検索・導入できるようになった。2つ目は会話の整理機能で、長いやり取りを手動で並び替えた区切りに分けて保存し、後から段階的に読み返せる。

3つ目が今回の主役、--approve-for-meだ。OpenAI公式の表現は「automatically reviewed approvals」となっている。「自動承認」ではなく「レビュー済みとして自動的に扱われる承認」という言い回しだ。この違いは小さくない。すべてのコマンドを無条件で素通しにするわけではなく、あらかじめ決めたポリシーの範囲内だけを自動で通す設計だと読める。

4つ目はCursor連携だ。Cursorで作ったスキルをCodexに取り込めるようになり、ClaudeとCursorの会話履歴を重複させずに同期できる。5つ目はMCPの新仕様対応で、これは後の見出しで詳しく扱う。6つ目はAmazon Bedrock向けの強化で、Web検索結果のキャッシュと会話の圧縮に対応した。

7つ目が地味だが見逃せない。ターミナルに表示されるコマンドや、過去の会話を再生したときの表示から、シークレットとベアラートークンを隠す機能が入った。承認の自動化を進める一方で、うっかり認証情報を画面に晒すリスクには先に手を打つ格好だ。自律性を上げる機能と、事故を防ぐ機能を同じバージョンに同居させてきた点に、OpenAI側の慎重さが見える。

Claude Codeを使っている人にはなじみ深いと思うが、Anthropicは逆方向の設計を先に進めていた。Manual modeのデフォルト化で書いたとおり、Claude Codeは「まず人間が確認する」ことを標準に据えた経緯がある。同じ週にOpenAIが承認の自動化へ踏み出したことで、2社の設計思想の違いがくっきりと浮かび上がった格好だ。

3日間で出揃った接続・統制・承認の勢力図

時系列で並べると、この1週間の動きはきれいに3つの軸へ分かれる。

7月29日、Cursorがタブレット端末上で複数のエージェントを並走させながらレビューできる機能を追加した。8月3日には「Google Workspace Plugins」を公開している。Gmail・Google Drive・Calendarへ、エージェントから直接アクセスできるようにする機能だ。公式X投稿ではDocs・Sheetsを含む5製品との言及もあるが、公式changelog本文で明記されているのはこの3製品までになる。Cursorが力を入れているのは、明らかに「接続」だと言える。どこまで多くの外部サービスへ、エージェントの手を伸ばせるか。そこを競っている。

ところが8月5日以降、Cursorのフォーラムでは別の空気が流れ始めた。マーケットプレイスからのプラグイン導入が途中で止まる不具合や、並行して動く複数のプラグインフックの間で環境変数が漏れて衝突する不具合の報告が相次いだ。接続先を増やすスピードに、安定運用が追いついていない実態がうかがえる。機能を公開したその日から現場が快適になるわけではないという、当たり前の事実を思い知らされた。

8月6日、Anthropicは企業向けプランに「skill and plugin security scanning」というベータ機能を加えている。サードパーティのスキルやプラグインをアップロード・編集する際に、不正なコンテンツが含まれていないか自動で検査する仕組みだ。Cursorが「接続」を広げているのに対し、Anthropicが力を入れているのは「統制」だと言える。誰が何を持ち込めるかを、企業側が管理できるようにする方向だ。

そして8月7日、Codexが「承認」の自動化に踏み出した。3社の1週間を並べると、接続・統制・承認という3つの軸が、まるで示し合わせたかのように同時に埋まったことになる。実際には各社が独立に動いているだけだろう。それでも、AIコーディングツールの競争軸は変わりつつある。「どれだけ賢いか」から「どれだけ安全に、どれだけ任せられるか」へ移っている流れが、この4日間だけでもはっきり見えてくる。同じ市場では、価格そのものを武器にしたMuse Code参入の価格破壊も起きた。機能面と価格面の両方で、競争の重心が動いていると言える。

—approve-for-meを実際に試して見えたハマりポイント

ここまでは公式リリースノートで確認できた確定情報の整理だ。ここからは、自分の小さな業務ツール用リポジトリで試した個人の体験談に切り替わる。私が普段使っているのは、スプレッドシートの更新をSlackに通知するだけの簡単なツールになる。本番環境ではなく、動作確認用に切り出したサンドボックスのリポジトリで、approve-for-meを有効化してみた次第だ。

最初は「これで承認待ちのストレスから解放される」と期待していたが、実際に触ってみると挙動はやや違っていた。approve-for-meを有効にしただけでは、コマンドが無条件で通るわけではない。事前にポリシーとして許可範囲を書いておく必要があり、範囲外のコマンドは今までどおり人間の承認を求めてくる。

# approve-for-meを有効化してCodexを起動する例
# --approve-for-me単体だと「安全と判断されたコマンドはレビュー済み扱いにする」動きになる
# ファイル削除やネットワーク越しの書き込みは既定では対象外になる
codex --approve-for-me

ここで私がハマったのは、「安全と判断される範囲」の感覚が自分の予想より狭かったことだ。スプレッドシートAPIの読み取りコマンドは、すんなり自動で通過している。一方でSlack通知先のWebhook URLを書き換えるコマンドは、範囲外として都度の承認を求められた。最初は「なぜ止まるんだ」と戸惑ったが、よく考えれば妥当な線引きだ。外部への書き込みを伴う操作まで無条件で自動通過させてしまうと、意図しない相手に通知が飛ぶような事故が起きかねない。

これは、AIコーディング暴走4事例で書いた「動けばOKの精神が裏目に出る」パターンと地続きの話だと思う。承認を自動化する機能ほど、最初にどこまで任せるかを自分で決めておく作業が欠かせない条件になる。任せる範囲を広げすぎれば事故のリスクが上がり、狭すぎれば結局これまでと変わらない。ちょうどいい線を見つけるまで、何度か設定を書き直すことになった。

設定を書き直す過程で、もう1つ気づいたことがある。許可範囲を細かく指定しようとするほど、設定ファイルの記述自体が長くなり、どこまで書いたか自分でも把握しづらくなる場面があった。

なお、以下の設定キー名は公式ドキュメントで一次確認できた正式な記法ではなく、私が挙動から逆算した擬似コードだ。実際の設定ファイルに書く前には、必ずOpenAI公式のドキュメントで正しいキー名を確認してほしい。

# approve-for-meの許可範囲を絞り込む設定例（著者による擬似コード。実在のキー名は公式ドキュメントで要確認）
# コマンドの種類ごとに許可・要承認を分けて書くイメージ
approve_for_me:
  allow:
    - "spreadsheet:read"      # スプレッドシートの読み取りは自動通過
    - "slack:read"            # Slackの履歴取得も自動通過
  require_review:
    - "slack:webhook:update"  # 通知先の変更は都度人間が確認
    - "file:delete"           # 削除系は常に人間の確認が必要

最初はallow側に何でも入れたくなる誘惑があるのも事実だ。だが、これまでの経験からいって、誘惑に負けた設定は後で必ず痛い目を見る。今回はrequire_review側を厚めに残し、慣れてきたら少しずつallowに移す方針にした。急がば回れだと思う。

正直に書いておくと、私が検証できたのは小さなサンドボックス環境の範囲にとどまる。業務の本流で長時間動かし続けた場合にどこまで安定するかは、まだ確認できていない。ここは実際にもう少し使い込んでから、続報として書きたいと思っている。

MCP 2026-07-28対応でサーバー接続はどう変わったか

Codex CLI 0.147.0は、MCP(Model Context Protocol)の2026年7月28日版仕様にも対応した。オプトインの機能であり、有効にしないと今までどおりの挙動のままになる。

MCP公式の説明によると、2026-07-28版の変更はExtensionsやTasksなど多岐にわたる。そのうち今回Codex文脈で重要な5点は次のとおりだ。

• ステートレスなプロトコルコアを採用し、サーバー起動を待たせない設計にした
• 複数回のやり取りを1つの接続でまとめて完結できる「Multi Round-Trip Requests」を導入した
• リクエストの振り分けをヘッダー情報で高速化する「header-based routing」を加えた
• 一覧取得の結果をキャッシュして使い回せる「cacheable list results」に対応した
• 認可まわりの安全性を高める「authorization hardening」を実施した

Codex CLI側では、この仕様のうち3点をサポートしている。対応するのは「paginated discovery」「multi-round requests」「non-blocking server startup」だ。業務ツール開発の現場で複数のMCPサーバーを同時に立ち上げていると、これまでは1つのサーバーが起動を終えるまで次のサーバーの接続を待たされることがあった。non-blocking server startupが効いてくると、この待ち時間が解消される見込みだ。

私もMCPは増やすほど賢くなるは誤解で書いたとおり、MCPサーバーを闇雲に増やすと応答速度と判定精度がむしろ落ちるという経験をしている。今回の仕様更新は、サーバーの数そのものを減らす話ではない。同じ数のサーバーを、より軽く安全につなぐための土台整備だと理解している。cacheable list resultsのおかげで、同じ一覧取得を毎回リクエストし直さずに済む場面が増えていく。体感速度だけでなく、APIコストの節約にもつながるはずだ。

opt-inの機能であり、有効化は設定ファイルにフラグを1行足すだけで済む。以下も同様に、キー名の綴りまで一次ソースで確認できたものではなく、私が試した範囲から組んだ擬似コードとして読んでほしい。

# ~/.codex/config.toml に追記するイメージ（著者による擬似コード。実在のキー名は公式ドキュメントで要確認）
[mcp]
protocol_version = "2026-07-28"  # opt-inで新仕様を有効化

私の環境では、スプレッドシート連携用・Slack連携用・カレンダー連携用の3つのMCPサーバーを常時立ち上げている。これまでは起動のたびに3つ順番の接続待ちが発生する構造だ。non-blocking server startupを有効にしてからは、起動時の待ち時間が体感でかなり短くなった。厳密な計測はまだできていないが、コーヒーを1口飲む間に終わっていた待ち時間が、画面から目を離す前に終わる程度には縮んだ印象だ。

Cursor管理スキルの取り込みは業務ツール開発にどう効くか

もう1つ、地味だが業務ツール開発者には効きそうな変更がある。Cursorで作ったスキルをCodexに取り込めるようになり、ClaudeとCursorの会話を重複させずに同期できるようになった点だ。

私は普段、用途によってツールを使い分けている。細かいUI調整はCursor、長時間の一括処理はClaude Code、というように使い分けているが、この使い分けには代償があった。ツールを切り替えるたびに、同じプロンプトのテンプレートやコーディング規約の説明を、もう一度別のツール用に書き直す必要があったのだ。地味に時間を食う作業だった。

Cursor管理スキルの取り込みが実際に効くなら、この書き直し作業がかなり減らせる。ただし、これは一方向の「取り込み」であって、CursorとCodexが常に完全に同じ状態を保ち続ける仕組みではないという点は押さえておきたい。会話の重複なし同期も、対象になるのはClaudeとCursorの会話であり、Codex側の会話全部が自動で巻き込まれるわけではなさそうだ。過度に期待せず、まずは1つの小さなスキルで試してから本格導入するのが安全だと思う。

業務ツール開発者が今週やるべき3つのこと

ここまで読んで「便利そうだから今すぐ全部オンにしよう」と思った人がいたら、少し待ってほしい。CS出身の私が学んだ教訓は、新しい権限機能はまず小さく試すに限るという一点に尽きる。

1つ目は、手元のCodex CLIのバージョンを確認するところから始めたい。0.147.0より古いままだと、approve-for-meもMCP新仕様対応も使えない仕様だ。アップデート自体は数分で終わる作業であり、まずここから始めるといい。

2つ目は、approve-for-meを有効にする前に、自分が任せたい操作の範囲を紙に書き出すことだ。読み取り系だけを任せるのか、書き込みを含めて任せるのか。事前に線を引いておかないと、私のように何度も設定を書き直す羽目になる。

3つ目は、今使っているMCPサーバーの数と種類を棚卸しすることだ。opt-inの新仕様であり、いきなり本番環境で切り替えるのではなく、リスクの低いプロジェクトで先に動かしてみるのがいい。サーバーが多いほど、non-blocking server startupの恩恵は大きくなるはずだ。

どれも地味な作業に見えるかもしれない。だが、この地味な棚卸しをやっているかどうかで、半年後に「AIに何を任せているか説明できる人」と「なんとなく便利に使っているだけの人」の差が開くと思う。派手な新機能ほど、導入前の一手間が効いてくる。

まとめ

Codex CLI 0.147.0を起点に、8月最初の1週間で起きたことを整理すると、こうなる。

• Cursorは接続先を広げ、Claudeはプラグインの検査を強化し、Codexは承認の自動化に踏み出した
• approve-for-meは「完全自動承認」ではなく「事前に決めた範囲内でのレビュー済み承認」であり、範囲設計を先にやる必要がある
• MCP 2026-07-28対応により、複数サーバーの起動待ちや一覧取得の重複リクエストが軽くなる見込み
• Cursor管理スキルの取り込みは便利だが、双方向の完全同期ではないため過度な期待は禁物

かつて、大規模プロジェクトで出会ったエンジニアたちの技術に「敵わない」と感じた日があった。あの頃はまるで想像がつかなかった話だ。今は承認の設計やMCP接続の設計といった「AIにどこまで任せるか」を決める作業そのものが、業務ツール開発者の腕の見せどころになりつつある。全部を自動化することが正解ではない。どこを自動化し、どこを人間が握るかを自分で決められることが、これからの強みになると思う。

まずはリスクの低いサンドボックスで、approve-for-meの範囲設計から試してみてほしい。私も引き続き手を動かして、続報を書くつもりでいる。