「まだチームの力になれていないな」と感じる瞬間も多くて、 人間関係や信頼関係も、これから一つずつ積み上げていく段階。

だからこそ、ふとしたタイミングで、 「この選択は本当に良かったのかな……？」 そんな不安や焦りが顔を出すこともあります。

でも、今週あらためて思ったのは、 最短の近道は、じっくり確実に進むことだということ。

わからないことが多い中、すべてを完全に把握することは不可能なので、 一つひとつ学んで、吸収して、次に活かす。 小さくても確実に前進する。

焦って背伸びするより、地に足をつけて積み上げるほうが、 結果的に早く、遠くまで行ける。

急がば回れ。

この言葉を、しばらく自分の合言葉にして進んでいきます。

• 「ページの一部だけを自動化したい」
• 「ちょっとした操作を繰り返したい」

という用途でブラウザ操作を自動化していました。
テストのために特定のフォームだけ自動入力したりとかね。

しかし最近、Selenium IDE がサポート終了となり Chrome の拡張機能で使えなくなってしまったため、AIちゃんにおすすめされた Playwright を試してみることにしました。

結論から言うと、Selenium IDE 的な使い方もできて満足！

この記事では、

• Playwright のインストール方法
• Selenium IDE っぽく「ページの一部だけ自動化」する方法
• ハマりポイント（ウィンドウが閉じる問題）

をまとめます。

Playwright のインストール方法

Node.js が入っていれば、まずはこれだけで試せます。

npx playwright codegen https://example.com

初回は Playwright 本体やブラウザのインストールが走ります。もし途中でエラーが出た場合は、以下を実行してください。

npx playwright install

これで録画モード（codegen）が起動し、操作すると自動でコードが生成されます。

Playwright は「開いているウィンドウ」を操作できない

• すでに開いている Chrome / タブを対象にすることはできない
• Playwright が起動したブラウザのみ操作対象

となります。（Selenium IDE も同様）

昔の時代の Selenium IDE は「今見ているページの一部だけ自動化」ができて便利だったのになぁ。。

ということで工夫が必要です。

ページの一部だけを自動化する方法

ここで活躍するのが await page.pause() です。

基本の考え方

• Playwright でブラウザを起動する
• 対象ページを開く
• pause で止める
• 自動化したい処理を実行
• また pause で止める

実際のコード例

import { test } from '@playwright/test';

test('部分的に自動化する', async ({ page }) => {
  // ① まず起動してページを開く
  await page.goto('https://example.com');

  // ② 手動操作したいところで止める
  await page.pause();

  // ③ 自動実行したい処理
  await page.locator('#submit').click();
  await page.locator('#count').fill('3');

  // ④ 再び止める（結果確認用）
  await page.pause();
});

この状態で

npx playwright test --debug

を実行すると、

• pause の位置で完全に停止
• ブラウザを手動で操作できる
• Inspector から再開できる

という流れになります。旧Selenium IDE の「途中から操作 → 再生」にかなり近い体験ができます。

なぜ pause を挟むのが重要なのか

Playwright は

• テストが最後まで走る
• 終了するとブラウザを自動で閉じる

という設計です。

つまり、

• pause を入れない
• 自動処理が最後まで終わる

と、ウィンドウが一瞬で閉じてしまいます。

「確認したい」「途中で操作したい」場合は、必ず await page.pause() を入れるのがポイントです。

まとめ

• Selenium IDE の代替として Playwright は十分使える
• ただし既に開いているウィンドウは操作できない
• await page.pause() を使えば途中で止めたり、ページの一部だけ自動化できる
• pause を入れないと最後にウィンドウが閉じるので注意

旧Selenium IDE に慣れている人ほど、最初は思想の違いに戸惑いますが、pause を使いこなせると一気に世界が変わると感じました。

「ちょっとした自動化」「デバッグ用途」でも Playwright、かなりアリです。

サンドボックスでネットワークを許可する

gh コマンドで GitHub の PR を見たい時、サンドボックスのネットワークが遮断されていると失敗します。（以前は不要だったのにいつからかセキュリティ周り厳しくなってました）

下記を追記すればOK！

vi ~/.codex/config.toml

[sandbox_workspace_write]
network_access = true

• sandbox_workspace_write セクションで network_access = true にすると、サンドボックスから外部ネットワークへ出られるようになります。
• これで gh pr view や gh pr checkout がサンドボックス内で動作するようになります。

MCP 設定の詳しい手順

MCP の追加やコマンド運用の詳細は、別途まとめた記事に置きました。

• Codex CLI MCP コマンド活用ガイド

さいごに

Codex も Antigravity と同じく、まずサンドボックス設定を整えてから使うのオススメです。 今後も細かいTipsをこの「俺のCodex」に追記していきます。

ショートカット

エージェントマネージャーへの切り替え

Ctrl + E

メイン ウィンドウ Editor と Agent Manager を切り替えます。

設定画面へ

エージェントマネージャーで

Ctrl + ,

設定を変更したい時に素早くアクセスできます。

設定

Auto-continue = ON

生成が途切れた時に、自動で「続き（Continue）」をしてくれる設定です。 長いコードを生成している時などに、途中で止まってしまうのを防いでくれます。

Enable Terminal Sandbox = ON

ターミナルコマンドをサンドボックス環境で実行する設定です。 ローカル環境（macOS）への影響を抑え、安全にコマンドを実行させるためにONにしておきます。

Sandbox Allow Network = ON

サンドボックス内でネットワークリクエストを許可する設定です。 これがOFFだと、npm install や外部APIへのアクセスなどが失敗してしまうため、基本的にはONにしておきます。

Artifact Review Policy = Agent Decides

成果物（Artifact）のレビューを求めるか。 Agent Decides はタスクの複雑さやユーザーの好みに基づいて、エージェントが自律的に判断します。 基本的には効率よくAIに作業してもらうため、エージェントの自律性を優先しています。

Terminal Command Auto Execution = Always Proceed

ターミナルコマンドの実行前にユーザーに確認を求めるか。 Always Proceedにして、拒否リストにあるものを除き許可しています。 こちらは予期せぬコマンドを実行される懸念もありますが、サンドボックスで実行されるようになったので安心かなと。

Browser Javascript Execution Policy = Always Proceed

ブラウザでのJavaScript実行時に許可を求めない設定です。 JavaScriptは基本ONでないと多くのサイトが操作できないため、Always Proceedにしています。 セキュリティ的な懸念もそこまで高くないと判断しています。

MCP

設定ファイルのパス

~/.gemini/antigravity/mcp_config.json

中身こんな感じ。JSONなので最後にカンマあるとエラーになるので編集時注意。

{
  "mcpServers": {
    "slack": {
    },
    "notionApi": {
    }
  }
}

Slack MCP

手順

1. Slack API でアプリを作成（From scratch）
2. OAuth & Permissions で chat:write, channels:history などの権限を付与
3. Install to Workspace を実行し、Bot User OAuth Token (xoxb-...) を取得
4. ワークスペースのURLなどから Team ID (T...) を取得

設定の記述

"slack": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-slack"],
  "env": {
    "SLACK_BOT_TOKEN": "xoxb-xxxx...",
    "SLACK_TEAM_ID": "Txxxx..."
  }
}

Notion MCP

手順

1. My Integrations で新しいインテグレーションを作成
2. Internal Integration Secret (ntn_...) を取得
3. 接続したいページで、右上の「…」メニュー > Connect (接続) > 作成したインテグレーションを選択

設定の記述

OPENAPI_MCP_HEADERS にJSON形式で認証情報を渡します。

"notionApi": {
  "command": "npx",
  "args": ["-y", "@notionhq/notion-mcp-server"],
  "env": {
    "OPENAPI_MCP_HEADERS": "{\"Authorization\": \"Bearer ntn_xxxx...\", \"Notion-Version\": \"2022-06-28\" }"
  }
}

Figma MCP

手順

FigmaデスクトップアプリをインストールしてデスクトップMCPサーバーとして実行します。そのためトークンは不要。

1. Figmaデスクトップアプリをインストール（最新版）
2. Figma Designファイルを開く
3. Dev Mode に切り替える (Shift + D)
4. インスペクトパネルの MCP Server セクションで「デスクトップMCPサーバーを有効化」をクリック

設定の記述

Figmaアプリとローカル通信を行う設定になります。

"figma-dev-mode-mcp-server": {
  "command": "npx",
  "args": [
    "mcp-remote",
    "http://127.0.0.1:3845/sse"
  ],
  "env": {}
}

備考

Figmaアプリ入れずにリモートMCPサーバーで動作させてみようとしたがイマイチ記法がわからず諦めました。

参考：Figmaの公式ヘルプ

GitHub MCP

手順

1. GitHubの Developer Settings へ
2. Personal access tokens (Classic) または Fine-grained tokens を作成
3. 必要な権限（Repo, Userなど）を付与して生成

設定の記述

"github-mcp-server": {
  "command": "docker",
  "args": [
    "run",
    "-i",
    "--rm",
    "-e",
    "GITHUB_PERSONAL_ACCESS_TOKEN",
    "ghcr.io/github/github-mcp-server"
  ],
  "env": {
    "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxx..."
  }
}

「開発は PC の前でやるもの」。

そう思っていましたが、最近その前提が崩れ始めています。
理由はシンプルで、AI がコードを書くようになったからです。

この記事では、

• 電車の中
• スマホだけ
• ローカル環境なし

という制約下で、
どこまで実用的な開発ができるのかを整理します。

スマホ開発が難しかった理由

これまでスマホでの開発が現実的でなかった理由は明確です。

• キーボード入力が厳しい
• ローカル環境が必要
• エディタ・ターミナル操作が前提

要するに 「コードを書く」こと自体がスマホに向いていませんでした。

前提が変わった：AI がコードを書く

近年の AI コーディングは、

• 補完する
• 提案する

段階を越えて、タスクを渡すと AI が実装までやるフェーズに入っています。

ここで重要なのは 人間がコードを書かなくてもよくなった 点です。

Codex という存在

Codex は、この流れを決定的にした存在です。

ブラウザ上で Codex を使うと、

• GitHub リポジトリを選ぶ
• 「この Issue を直して」と指示する
• Codex が自動で：
  • リポジトリを clone
  • 実行環境を構築
  • 修正・テスト
  • diff/PR を生成

人間は、

• 指示する
• 結果を確認する
• 判断する

だけでOK。

Codex と Codex CLI の違い

本記事で扱う「Codex」は ブラウザ上で利用する Codex（Web UI） を指しています。
Codex には CLI ツールとして Codex CLI もありますが、思想と利用体験が大きく異なります。

Codex（ブラウザ版）

• ブラウザで完結
• GitHub と直接連携
• 環境構築は不要
• タスク単位で実行
• 同じリポジトリに対して 複数タスクを並列で依頼できる

Codex CLI

• ターミナルで利用
• ローカルにリポジトリが必要
• 実行環境は自分で管理
• 並列タスクは自前で工夫が必要

比較すると以下の通り。

なぜ Codex はスマホと相性がいいのか

1. ブラウザだけで完結する

• ローカル環境不要
• SSH 不要
• エディタ操作不要

スマホの弱点をすべて回避しています。

2. 入力が最小限

スマホでやることはほぼこれだけ。

• 「A を修正して」
• 「テスト追加して」
• 「別案も作って」

長文のコード入力は不要です。

3. 並列タスクができる

Codex の本質的な強みはここにあります。

• 同じリポジトリに対して
• 複数の Codex 実行を
• 同時に走らせられる

例：

バグ修正 → Codex A
リファクタ → Codex B
テスト追加 → Codex C

人間 1 人 + AI 複数人 という構図が成立します。

電車の中でできる「実用的な開発」

実際に電車内でできることは多いです。

• Issue を投げる
• PR をレビューする
• 実装方針をコメントする
• 並列タスクの結果を比較する
• マージ判断をする

もはやこれは 「開発」ではなく「マネジメント」 に近いです。

開発者の役割が変わる

スマホで書けるかどうかより、
AI に任せられる範囲が広がったことが本質です。

開発者は「実装する人」から、
方向を決めて結果を判断する人へ移ってきています。

通勤時間に方針を決めてAIに依頼。 出社後に結果をレビューして判断する。

まとめ

• 変化の中心は AI に実装を任せられるようになったこと
• Codex（ブラウザ版）は
  • 環境構築
  • 実装
  • 実行
  • PR 作成 までを肩代わりする
• 電車の中でできるのは
  • 「書く」ことではなく
  • 「任せる」「判断する」こと

おわりに

開発の現場は、静かに「書く」から「任せる」へ移りました。
これからの開発者は「実装する人」より「判断する人」になります。

場所は自由、役割は明確。
次に変わるのは、開発者という役割そのものかもしれません。

N+1問題は「親データを取った後、子データを件数分だけ追加で取得してしまう」ことで、SQLが爆増してパフォーマンスが落ちる現象。
特にResourceなどのループ処理でリレーションにアクセスすると、気づかないうちに発生しがちです。

何が起きるか

• 1件なら問題ない
• 100件になると +100 クエリ
• 気づかずリリースして本番で重い！😱

N+1は、リリース後に発覚すると辛いので「起きない仕組み」を作ることが大事。

今まではチェックしてたけど、下記で防げるよ！

これまでは開発中にデバッグしてN+1問題が発生していないかSQLチェックしてました。これが地味に面倒で大変。。

relationLoaded を使う

Resourceクラス（APIのレスポンス整形層）はループ処理を行うことが多いです。
ここで不用意にリレーションにアクセスすると、データ数分だけSQLが発行されてしまいます。

relationLoaded() を使うことで、

• UseCase側で with() してロード済みなら使う
• そうでなければ無視する

という安全な実装になります。
Resource側は「読み込まれていたら使う」だけにしておけば、N+1の温床になりません。これは便利！

例

if ($user->relationLoaded('books')) {
    $books = $user->books;
}

UseCase側で必要なデータだけを効率よく with() しているので、Resource側は安全にそれを参照するだけの構成にできます。

設定しよう！　Model::preventLazyLoading

でも毎回 relationLoaded を書くのも手間ですよね。
Laravelデフォルトでそうしておいてほしいですね。そんな機能はないの？

あります！
Laravel 8以降は Model::preventLazyLoading() で「うっかりN+1」を防げます！

これを有効にすると、with() していないリレーションにアクセスした瞬間に例外を投げてくれます。
開発中にN+1を完全に防げるので、超強力。

// AppServiceProvider など
use Illuminate\Database\Eloquent\Model;

public function boot()
{
    Model::preventLazyLoading();
}

開発中と書きましたが、もちろん本番も同じ設定しててOKです。
ローカルや開発環境でしっかりテストしていれば、そこで検知できるので、本番で発生したらバグですね！

まとめ

• すでに運用中のシステムなら
  • relationLoaded で安全に対策していく
• 新規構築システムなら
  • preventLazyLoading を導入して事故を防ぐ

この2つを使いこなせば、N+1問題とおさらばですね！
寒い冬はしっかり手洗いうがいをして、インフルエンザとN+1問題を防ぎましょう！

1. そもそも「自分で実装しない」

• 「書かない」という決意
  • 極力、自分では1行もコードを書かない。書こうとした瞬間に「あ、これはエージェントに任せられるな」と立ち止まる。
  • 自分で実装し始めたら、それはAIエージェントをただの「補完ツール」に格下げしてしまっているのと同じ。
• 自分の役割は「意思決定」と「確認」
  • 実装という実務はエージェントに譲り、自分は「何を作るか」「それは正しいか」の判断に集中する。

2. ざっくり依頼する

• 細かく指示しすぎない
  • 実装方法まで細かく指示すると、結局自分でコードを書いているのと変わらない。
  • 「自分の頭の中にあるもの」をなぞらせるだけだと、作業感が出てストレスが溜まる。
• 思わぬ発見を楽しむ
  • あえて抽象的に依頼することで、自分では思いつかなかったスマートな実装やUIを提案してくれる可能性がある。
  • AIエージェントのポテンシャルを信じて、設計から任せてみる。（DB定義なんかも任せてます）

3. AIに「依頼する」前に「相談する」

• 納得して進むための「問い」
  • 自分が納得したいがゆえに、あえて問いかける。「どう思う？どうしたらいいかなぁ？」
  • 誰かに（AIに）認めてもらうことで、心理的に進みやすくなる効果は大きい。
  • 命名に迷った時も、候補を投げれば爆速で決まる。
• まずは計画を出させて壁打ち
  • いきなりコードを書かせず、まず「実装計画」を教えてもらう。
  • 計画の段階で議論することで、手戻りを最小限に抑えられる。
• 未知の領域は事前にリサーチしてもらう
  • 情報の少なそうな箇所や新しいライブラリは、先にAIに調べさせて、詳しくなってから本題に入る。

4. 設定ファイル（CLAUDE.md等）はあえて作り込まない

• AIの進化を邪魔しない
  • CLAUDE.md や .AGENTS.md といった指示ファイルをガチガチに固めない。
  • AI自体が日々進化しているため、古いルールや余計な情報で思考を惑わさないようにしている。
• 「素の知能」を使いこなす
  • 凝った指示書を作るよりも、その時々のAIの「素の状態」と対話する方が、柔軟で最新の提案を受けやすい。

5. 行き詰まったら「中の人」を変える

• 泥沼にはまらない
  • AIが同じミスを繰り返したり、ハマり出したりしたら潔く再起動するようにしてます。同じAIでもかなりアウトプット変わってきます。
• 別の人（モデル）にも依頼してみる
  • 一つのエージェントで解決しない時は、別のエージェントに同じ依頼を投げてみる。
  • 同一AIでも並行して依頼してみたりも有効です（Codexなど）

6. 開発のリズムを作るTips

• 適度にコミットする
  • キリのいいところでコミットを挟んでおくのは大事です。少し前の挙動が良かったなぁというときにAIが戻せないことは多々あるので。
• コミット前に差分確認する
  • コーディング中は正しく動作することに重きを置き、コードを見るのは最後にしています。よほどおかしな実装をしていたり、保守性が悪い場合のみ指摘し修正してもらうことで余計な時間を使わない。人がコードを見ることは今後ますます少なってくると思うので。
• gitやCLIツールをフル活用
  • gh コマンドを使ってPRをサクッと参照させたり、作成してもらいます。
  • git履歴を元に現在の実装状況を把握してもらうと、AIエージェント再起動後もやりたいことを理解してくれて便利です。

まとめ：目的を伝えて、あとはやってもらう

AIエージェントは単なるツールではなく、頼れる爆速開発者です。 大切なのは、詳細な実装方法を伝えることではなく、明確な「目的（Why）」を伝えて信頼すること。 彼らに任せたほうが、自分が考えた設計よりもずっと良いものが早く出来上がる。そんな体験が、これからの開発の当たり前になっていくはずです。

症状

何度起動しても画面週力を許可してくれポップアップが出る。。

結論（原因）

• macOS側の「画面収録（ScreenCapture）」権限が壊れている
• Monosnapを入れ直してもTCCの権限DBが更新されていない
• 設定UI上はONでも、内部のDBが壊れている状態だとアプリが拒否され続ける

✅ 解決手順（確実版）

① Monosnapを完全終了

killall Monosnap

バックグラウンド常駐を含めて強制終了します。

② 画面収録の権限を一度外す

システム設定 > プライバシーとセキュリティ > 画面収録 で Monosnap のチェックを外します。ここではまだ起動できません。

③ 権限キャッシュ（TCC）をリセット【重要】

tccutil reset ScreenCapture

パスワードを求められたら入力し、エラーが出なければ成功です。これでmacOSが抱えていた壊れた許可情報が削除されます。

④ Macを再起動（必須）

ここは絶対に飛ばさないでください。再起動せずにMonosnapを起動すると、古いキャッシュが復活してやり直しになる確率が高いです。

⑤ Monosnapを起動し、許可を“新規登録”

1. Finderの「アプリケーション」からMonosnapを起動
2. 警告ダイアログが出たら「Open System Preferences」を押す
3. 画面収録 > Monosnap のチェックを付け直す
4. 「再起動が必要」と言われたらMonosnapのみ再起動

⑥ それでもダメな場合（最終手段）

Monosnap.app自体を物理的に削除して再登録します。

sudo rm -rf /Applications/Monosnap.app

公式DMGから入れ直し、手順⑤をもう一度実施してください。

🔍 なぜこれで直るのか

• macOSの設定UIと実際の許可DB（TCC）は別物
• UI上はONでもDBが壊れているとアプリは拒否される
• tccutil reset ScreenCapture が壊れたレコードを消す唯一の正攻法

ということで今回は Notion Automation を使って、ステータスを進行中にしたタイミングで一度だけ「着手開始日」を埋め、それ以降は上書きされない仕組みを作ったのでメモしておきます。

やりたいこと

• ステータスが「進行中」になったタイミングで日付を自動入力したい
• その後、「レビュー」や「テスト」のように別ステータスへ変更しても入力済みの日付は上書きされないようにしたい

しくみ

Notionのオートメーションは「このプロパティが空なら実行」といった条件をまだ指定できません。

そこで条件を指定したフィルタビューを作り、そのビューに対してのみオートメーションを設定する工夫をしています。

手順

1. 「着手開始日」フィールドを作成

データベース（タスクDBなど）に 着手開始日 という Date プロパティを追加します。通常の Date でOKです。

2. 未入力フィルタビューを作る

着手開始日 が空のページだけを抽出するフィルタビュー（またはビュー専用のフィルタグループ）を作ります。
例：着手開始前

このフィルタビューのみにオートメーションを適用することで、着手開始日 が空欄の行だけに動作し、上書きされることを防ぎます。

3. Notion Automationを設定

1. 右上の「•••」から Automations を開く
2. New automation を作成
3. Entry filter に、手順2で作った「着手開始前」ビューを指定
4. Trigger: When property changes を選び、ステータス が 進行中 になったときに発火するよう設定
5. Action: Edit property で 着手開始日 に Trigger timestamp をセット

これで完成です！動作確認してみてください！

補足

• 進行中以外のステータスでも着手日を残したいなら、ビューのフィルタ条件を増やすだけで応用できます。
• 「着手開始日を手動で調整したい」ケースでも、既に値が入っていればオートメーションは動かないので安心です。

こんな感じで、Notion Automation × フィルタービュー の組み合わせを使えば色々な使い方ができて便利ですね！着手遅れの分析やリードタイム計測にもぜひどうぞ。

それでは良きNotionライフを！

1. まずは全体像を掴む (codex mcp --help)

オプション構成が分からないまま手を動かすと迷子になりがちです。--help でサブコマンドの説明をざっと眺め、使い方の全体像を掴んでから進みましょう。

codex mcp --help

ここで確認できるポイント

• add, list, remove など MCP 管理に関係する主要コマンド
• 1 コマンドで command と args を一括登録できるフォーマット
• グローバル設定ファイル ~/.codex/config.toml が更新対象であること

2. Chrome DevTools MCP を追加する (codex mcp add …)

インストールや設定ファイルの手編集は不要です。以下の 1 行で command と args が config.toml に追記され、頭から Codex CLI で利用できるようになります。Chrome DevTools MCP の場合は --headless=false を付けてデバッガ画面を出しながら使うのが分かりやすいです。

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --headless=false

コマンドの読み方

• chrome-devtools が MCP サーバー名。mcp_servers."chrome-devtools" として保存される
• -- 以降は OS 上で実行するプロセス (npx + 引数)
• --headless=false を args に入れるとブラウザ UI を開いた状態で DevTools オートメーションを扱える

実行後は ~/.codex/config.toml に以下のように追記されます（例）:

[mcp_servers."chrome-devtools"]
command = "npx"
args = ["chrome-devtools-mcp@latest", "--headless=false"]

3. 登録済み MCP を確認する (codex mcp list)

設定を追加したら正しく反映されているか、その場で確認しておくと安心です。list は config.toml を読み込み、登録済みの MCP 名と実行コマンドを一覧表示してくれます。

codex mcp list

出力例では各 MCP に割り当てられた command / args の要約を確認できるので、設定の typo や引数漏れを早期に検出できます。加えて list --json（ヘルプ参照）を使えばスクリプトからの検査にも応用可能です。

4. 不要になった MCP を片付ける (codex mcp remove …)

検証が終わった MCP を放置すると ~/.codex/config.toml が肥大化し、目的の MCP を探しづらくなります。不要になったタイミングで remove を実行し、設定をクリーンに保ちましょう。

codex mcp remove chrome-devtools

remove は指定した MCP 名に紐づく command と args を丸ごと削除します。後から同じ MCP を再利用したくなったら「2. add」からやり直せば OK です。

まとめとワークフロー例

1. codex mcp --help でコマンド体系を把握
2. codex mcp add … で必要な MCP を追加
3. codex mcp list で設定確認（必要なら --json で自動テスト）
4. 使い終わったら codex mcp remove … でクリーンアップ

Codex CLI は設定ファイルがグローバル共有な点に気を付けながら、この 4 コマンドをルーティンにすると MCP との付き合いがぐっと楽になります。ぜひターミナルのお供にどうぞ。