MCP・プラグイン・オートメーション・モデル選び。Codexに道具を渡す基本設計

Codexに慣れてくると、次に気になるのがMCP、プラグイン、オートメーション、モデル選びです。名前だけ見ると専門家向けに見えますが、考え方はそれほど難しくありません。

Codex本体は、作業を進めるスタッフです。MCPやプラグインは、そのスタッフに渡す鍵と道具箱です。オートメーションは、毎週決まった時間に出す業務指示です。モデル選びは、軽い確認を頼むのか、深い設計を頼むのかに合わせて担当者を変える感覚です。

この記事では、公式情報を前提に、業務改善やAI副業準備でどう考えればよいかを整理します。難しい設定値を全部覚えるより、何のために使うのか、どこで人が止めるのかを先に決めるほうが実務では役に立ちます。

MCPは、AI用の接続口

MCPは、Model Context Protocolの略です。MCP公式サイトでは、AIアプリケーションが外部システムとつながるためのオープンな標準として説明されています。分かりやすくいうと、AI用のUSB-Cのようなものです。

普通のチャットだけなら、AIはあなたが貼った文章しか見られません。MCPを使うと、許可した範囲で外部の情報や道具を扱えるようになります。カレンダーを見る、Figmaのデザインを読む、GitHubのPRを確認する、データベースを調べる、といった使い方です。

ただし、つながることは便利であると同時にリスクでもあります。お店のスタッフに倉庫の鍵を渡せば、在庫確認は早くなります。でも金庫の鍵まで渡す必要はありません。MCPも同じで、どの情報源につなぐか、読み取りだけにするか、書き込みまで許すかを分けます。

最初に検討しやすい接続先は、次のようなものです。

• GitHub: PR、Issue、差分確認。最初は読み取りとPR作成まで
• Google Drive: DocsやSheetsの確認。顧客データの扱いには注意
• Google Calendar: 予定確認、空き時間確認。予定作成は人間確認を挟む
• Gmail: 検索、要約、返信下書き。送信は人間が押す
• Vercel: デプロイ状況、ログ確認。envやDNSは慎重に扱う
• Supabase: テーブル確認、ログ確認。削除やスキーマ変更は人間承認
• Figma: デザイン確認、画面理解。実装前の読み取りに向く
• BrowserやChrome: 実画面確認。ログイン状態や個人情報に注意

これを全部入れる必要はありません。最初はGitHub、Browser、公式ドキュメント検索だけでも十分です。道具は増やすほど強くなりますが、確認する責任も増えます。

調べものにAIを使うときの姿勢は、AIで調べものの時間を短くする。うのみにしない使い方でも扱っています。MCPで情報源が増えても、日付、根拠、一次情報の確認は残ります。

権限は、読む、下書き、実行の順で上げる

MCPやプラグインで一番大事なのは、何をつなぐかより、どこまで許すかです。初心者は、権限を階段にして考えると分かりやすいです。

1段目は読むだけです。GitHubのPRを見る、Vercelのログを見る、公式ドキュメントを調べる。外へ影響が出にくいので、最初に試しやすい範囲です。

2段目は下書きです。メール返信案、記事案、PR説明文、修正案を作る。ここも便利ですが、外に出す前に人間が読みます。

3段目は実行です。メール送信、SNS投稿、本番公開、DB変更、環境変数変更などです。ここは人間承認を挟む場所として扱います。AIにできるかどうかではなく、間違えたときの影響で判断します。

プラグインは、まとまった道具箱として考えると分かりやすいです。GitHubプラグインならPRやIssueを見る。Vercelならデプロイやログを見る。Google Calendarなら予定を確認する。道具箱ごとに得意な仕事があります。

導入の判断は、次のように考えます。

• 記事やコードを作る人: GitHub、Browser、公式ドキュメント検索
• 顧客対応の下書きを作る人: Gmail、Google Drive、Calendar
• サイト運営をする人: GitHub、Vercel、Browser
• データを見る人: Google Sheets、Supabase
• デザインから実装したい人: Figma、Browser

たとえばAI副業準備室のようなサイト運営なら、GitHubでPRを作り、Vercelで本番反映を確認し、Browserでスマホ表示を見ます。ただし、PRマージや本番公開は人間が承認する。この分け方が現実的です。

オートメーションは、定期便にする

オートメーションは、Codexに定期的な確認や作業をさせる仕組みです。OpenAIのCodexアプリ公式ドキュメントにもAutomationsの項目があります。毎週の記事PR確認、毎朝のレポート、定期的なエラーチェック、反応数の確認のような仕事に向いています。

オートメーションは、定期便に似ています。毎週決まった曜日に、牛乳や新聞が届くように、決まった確認を忘れずに回す仕組みです。ただし、定期便が勝手に契約変更までしないように、AIにも公開操作まで入れないほうが安全です。

記事下書きを作る、PRを作る、検証結果をまとめる、承認待ちとして報告する。ここまでは自動化しやすいです。一方で、PRをマージする、本番公開する、SNS投稿する、メール送信する、広告を動かすといった操作は、人間承認で止めます。

オートメーションを作るときは、次の4つを書きます。

• いつ動くか
• 何を確認するか
• 何を出力するか
• 何をしてはいけないか

特に最後の「してはいけないこと」を書くと安定します。自動化は、寝ている間にも動く可能性があります。だからこそ、外部送信、本番変更、課金、秘密情報更新を止める線が必要です。

オートメーションの指示文は、こう書きます。

毎週月曜の朝、サイトの記事候補を1本確認してください。

確認すること:
- 記事タイトル
- slug
- 本文の不足
- 内部リンク切れ
- 禁止表現の有無
- build結果

出力すること:
- 公開してよいか
- 修正が必要な点
- CEOが確認すべきチェック項目

してはいけないこと:
- PRをマージしない
- 本番公開しない
- SNS投稿しない
- メール送信しない
- envやsecretを変更しない

このように、やることとやらないことを同じくらい具体的に書きます。自動化は、頼む内容よりも止める内容で品質が決まります。

業務を仕組みで続ける考え方は、AI副業を仕組みで続ける。三日坊主にしない作業台の作り方にもつながります。オートメーションは、気合いではなく作業台を整えるための機能です。

モデル選びは、仕事の重さで変える

Codexやエージェント環境では、複数のモデルを選べることがあります。ここで迷いやすいのは、常に一番強いモデルを使うべきかという点です。実務では、仕事の重さで分けるほうが自然です。

軽い確認、誤字修正、短い要約なら、速いモデルで足ります。複数ファイルを読んで設計する、セキュリティや本番公開のリスクを見る、長い記事構成を作るような仕事は、強い推論モデルを使います。人間の仕事でも、メモの転記と事業計画のレビューを同じ重さでは扱いません。

具体例で見ると、こうです。

• 誤字チェック: 速いモデルでよい。判断が浅く、範囲も狭いから
• ブログの構成案: 中くらいのモデル。読者、検索意図、内部リンクを見るため
• Next.jsのエラー修正: 推論が強いモデル。原因の切り分けが必要になるため
• 本番公開前レビュー: 強いモデルと人間確認。見落としのコストが高いため
• セキュリティ確認: 強いモデル。ただし最終判断は人間か専門家
• 長期の自動運用設計: 強いモデル。目的、失敗時の停止条件、承認境界を設計するため

モデル選びは、車選びではなく道具選びに近いです。メモを切るのに大きなノコギリは要りません。逆に、太い木を切るのに小さなハサミでは時間がかかります。作業の重さに合わせます。

ただし、強いモデルを選んでも、材料が少なければ推測が増えます。先に目的、材料、制約、確認方法を渡すことが大事です。AIへの指示のコツ。頼み方を変えるだけで答えが変わるで扱った基本は、モデルが変わっても同じです。

PlanモードとGoalモードは、頼み方を変えるために使う

環境によって名称や使える機能は変わりますが、考え方としては、通常依頼、Planモード、Goalモードを分けると使いやすくなります。

通常依頼は、短い作業に向いています。「この文章を整えて」「このエラーを説明して」「このファイルを要約して」のような依頼です。

Planモードは、すぐに手を動かす前に、目的、前提、変更範囲、検証方法を整理したいときに向いています。たとえば、サイトの導線を変える、記事シリーズを設計する、複数の設定を触るような場面です。作業に入る前に、どこまで触るかを決めます。

Goalモードは、何ターンかかけて進める仕事に向いています。完了条件があり、途中で検証しながら進めるものです。たとえば、記事を3本作ってPRにする、フォームの不具合を再現して修正する、計測設計を実装して確認する、といった仕事です。

弁当作りでいえば、通常依頼は卵焼きを作ること。Planモードは1週間分の献立を決めること。Goalモードは、買い物、下ごしらえ、調理、保存、翌日の確認まで進めることです。全部を同じ頼み方にすると、AIも人間も疲れます。

使い分けの例は、次の通りです。

• 通常依頼: この文章を読みやすくして
• Planモード: このサイトの導線改善案を、実装前に計画してください
• Goalモード: 記事3本と図解3枚を作り、typecheckとbuildまで通してください

Planモードでは、すぐに編集させず、目的、前提、変更範囲、検証方法を出してもらいます。Goalモードでは、完了条件を先に置きます。たとえば「3記事が作成され、画像が表示され、buildが通り、PR作成前で止まる」という状態です。

Codexを仕事で使う基本設計は、道具を増やすことではありません。接続するもの、任せること、止めること、確認することを分けることです。MCPやプラグインで見える世界が広がり、オートメーションで定期業務が回り、モデル選びで作業の重さを合わせる。その中心に、人間の承認境界を置いておくと、AI活用は実務に乗せやすくなります。

参考にした公式情報: MCP公式、Codex Automations、OpenAI Codex Docs