この記事の対象読者と得られること
| 対象読者 | この記事で得られること |
|---|---|
| 1 人運営・個人事業主 | 月 $25〜$80 の AI 秘書の作り方 |
| バックオフィス兼務エンジニア | Codex Automations × 公式プラグインの実装例 |
| GitHub Issue 運用を自動化したい方 | 朝のトリアージの cron 設定例 |
はじめに — 「雑務を AI に任せたい」という素朴な願い
1 人で副業や個人事業を回していると、手は 2 本しかないのに雑務は 10 種類くらい降ってきます。私の周りでも「開発しながら経理もやって、Slack も見て、Sentry のエラーも追う」という人は珍しくありません。
そういうときに欲しいのは、24 時間稼働してくれる情シス担当のような存在です。ただ、人を雇うほどの量ではなく、かといって放置すると積み上がっていく、この中途半端な領域が長らくの悩みどころでした。
2026 年春、この悩みに直接刺さるアップデートが OpenAI から出ました。Codex に追加された Automations（スケジュール実行機能）です。cron 構文で時間を指定すれば、Codex が自律的にタスクを開始し、Gmail や Slack、Linear、Notion など 90 以上の公式プラグインを呼び出して作業を進めてくれます。
本記事では、この Codex Automations と公式プラグインを組み合わせて「AI 秘書」を組む方法を、具体的な 3 つの実装例と設定ファイルのサンプル、月額コストの試算、落とし穴まで含めて紹介します。
本記事の情報は 2026 年 4 月時点のもので、Codex の CLI オプションや料金は今後変更される可能性があります。実際に試す場合は developers.openai.com/codex/app/automations で最新仕様を確認してください。
背景 — スケジュール実行 AI がなぜ必要とされたか
スケジュール実行 AI はなぜ必要とされたか
「定時に動く自動化」というアイデア自体は、別に新しくはありません。UNIX の cron、systemd timer、Windows のタスクスケジューラなど、古くから存在してきた領域です。ただ、これらは「決められたコマンドを決められた時刻に叩く」という点では非常に優秀でも、「状況を読み取って判断する」という用途には向いていませんでした。
cron や systemd timer には、大きく 3 つの限界がありました。1 つ目は対話ができないこと。迷ったときに「人間に確認する」分岐を組み込もうとすると、別の仕組みを足す必要があります。2 つ目は状態を持続しづらいこと。前回の結果を次回に引き継ぐには、自前でファイルや DB を用意する必要がありました。3 つ目は LLM を呼ぶ前提で設計されていないことです。シェルから叩けば呼べますが、プロンプト管理やトークン計算、エラー処理まで含めると、簡単な作業ではなくなります。
GitHub Actions の schedule トリガーも、同じ領域で広く使われてきました。ただ、こちらも「LLM 判断を含むワークフロー」では思ったほど伸びなかった印象があります。理由はいくつかあって、YAML の表現力が LLM 呼び出しには冗長になりがちなこと、シークレット管理とモデル API キーの相性が悪かったこと、そして「cron で動く Actions は本来 CI/CD の延長」という前提があったこと、などが影響していると感じます。
一方で、この空白地帯を埋めようとした試みは 2023 年頃から続いていました。AutoGPT や BabyAGI のような「常駐型の AI エージェント」は、当時大きな期待を集めました。ただ、実運用に持ち込むと、無限ループに入ったりコストが読めなくなったり、結果の品質が安定しなかったり、という課題が目立ちました。「常に動く AI」はロマンがある一方、運用コストと制御の難しさでしぼんでいった、というのが振り返っての印象です。
2026 年春に追加された Codex Automations は、このあたりの反省を踏まえた公式ポジションという見方ができます。具体的には、スケジュールトリガーと Rollout（セッションの永続化・再開）を組み合わせ、「時刻で起動し、必要な状態は持ち越し、終わったら止まる」という断続的なモデルを採用しています。24 時間走らせ続けるのではなく、必要なときだけ立ち上げて仕事をして消える、という設計思想です。
面白いのは、利用者側のメタファーも少し変わってきたことです。以前の「自律エージェント」「AI 執事」といった呼び方には、どこか曖昧で壮大な響きがありました。2026 年現在は、もう少し具体的に「AI 秘書」「スケジュールで動く AI 担当者」「バックオフィス要員としての AI」といった表現が増えている印象です。万能の相棒ではなく、決まった時間に決まった仕事をする担当者、というイメージに着地しつつあるのかもしれません。
2026 年のワークフロー自動化市場
Codex Automations を単体で見ると「便利なスケジュール機能」に見えますが、俯瞰すると既存のワークフロー自動化市場の上に乗っかっている、という見え方もできます。市場を眺めると、競合するプレイヤーがそれなりにいます。
まず、古株の Zapier は 7,000 以上のアプリ連携を強みに、2026 年時点でもノーコード自動化の代表格です。最近は AI Copilot 機能も追加され、自然言語でワークフローを組める方向に進化しています。n8n はオープンソース軸で、セルフホスト派や細かい制御をしたい層に支持されています。make.com（旧 Integromat）はビジュアルエディタの使いやすさで、Zapier よりやや複雑なワークフローを好む層に食い込んでいる、という印象です。
さらに、2026 年 4 月には Anthropic が Routines という機能を発表しています。こちらは Claude を用いた定期実行を前提にしており、コンセプトとしては Codex Automations と非常に近い領域に見えます。OpenAI と Anthropic が同時期にこの領域へ公式機能を投入してきたのは象徴的で、「LLM を組み込んだスケジュール実行」が 2026 年の主要テーマになりつつあることをうかがわせます。
もう 1 つ見落とせないのが、MCP（Model Context Protocol）サーバーのマーケットプレイス化です。Anthropic と OpenAI の双方が MCP に対応する方向を示しており、将来的には「どの LLM でも共通のツール群を使える」世界が広がる可能性があります。今はまだ過渡期ですが、数年単位で見ると「プラグイン＝ベンダー固有」という構図が崩れていくかもしれません。
Codex の公式プラグインは、2026 年 4 月時点で 90 を超えています。カテゴリの内訳をざっくり分けると、メッセージ系（Gmail、Slack、Discord など）、ファイル・ドキュメント系（Google Drive、Notion、Box）、監視・分析系（Sentry、Datadog）、CRM・営業系（HubSpot、Intercom、Salesforce 系）、設計・デザイン系（Figma）あたりに大別できます。数が多すぎて全部は把握できないので、自分の業務ドメインに近い 5〜10 個から触り始めるのが現実的でしょう。
こうして市場全体を見渡すと、Codex Automations は「ノーコード × AI 判断」寄りのワークフロー自動化として、Zapier と GitHub Actions のちょうど中間あたりに陣取っているように感じます。ノーコードほどの手軽さはないものの、AI 判断が自然に組み込める。GitHub Actions ほどインフラ寄りではないものの、開発者が馴染みやすい操作性を持つ、そんなポジションです。どのツールが「正解」かは運用スタイル次第ですが、選択肢が増えてきたこと自体は歓迎すべき流れと捉えています。
Codex Automations とは何か
スケジュール実行という「もう 1 つのモード」
これまで Codex は、対話的に指示を受けて動く「オンデマンド型」が基本でした。人間が開発環境から呼び出して、タスクを渡して、結果を受け取る。この流れは便利ですが、「毎朝 9 時に必ずやってほしい」ような定常業務には向きません。
Codex Automations は、この弱点を補うために追加された機能です。2026 年春のアップデートで登場し、以下 2 種類のモードが提供されています。
| モード | 特徴 | 向いている用途 |
|---|---|---|
| Thread Automation | 既存のスレッドを継続実行する | 週次レポートの追記、長期プロジェクトの定期更新 |
| Standalone Automation | 新規タスクとしてゼロから起動する | 毎朝の Issue トリアージ、定時のエラー集計 |
Thread Automation は、会話の文脈を保ったまま定期的に更新をかけていくイメージです。たとえば「このプロジェクトの週次まとめスレッド」に、毎週金曜 17 時に自動で今週分を追記させる、といった使い方ができます。
一方の Standalone Automation は、毎回まっさらな状態から始めるタイプで、トリアージや集計など「前回の文脈を引きずらない方がいい」ワークフローに向きます。
なぜプラグインと相性がいいのか
Codex 単体ではコード生成と会話までしかできませんが、公式プラグインを経由することで Gmail を読んだり、Slack に投稿したり、Linear にチケットを切ったりできます。Automations と組み合わせると、「時刻」「指示」「外部ツールへの作用」の 3 点が揃うので、これが揃って初めて「AI が業務を代行してくれる」と呼べる状態になる、というのが個人的な感覚です。
基本設定 — CLI からの登録例
公式ドキュメントと Owain Lewis 氏のニュースレター記事で紹介されているコマンド例をベースに、実際に Automation を登録する流れを整理します。以下は擬似的な CLI 呼び出しです。実際のオプション名はバージョンにより多少前後する可能性があります。
# Standalone Automation を新規登録する例
codex automation create \
--name "morning-issue-triage" \
--schedule "0 9 * * 1-5" \
--mode standalone \
--prompt-file ./prompts/issue-triage.md \
--plugins github,slack \
--timezone "Asia/Tokyo"
ポイントは 3 つあります。
-
--scheduleは標準的な cron 構文で、分 時 日 月 曜日の順に指定します -
--timezoneを明示しないと UTC で解釈されるので、日本時間で動かしたい場合は必ずAsia/Tokyoを指定します -
--pluginsで有効化するプラグインを絞れるので、不要な権限を渡さない運用ができます
cron 記法が不慣れな方向けに、よく使うパターンを表にしておきます。
| 指定 | 意味 |
|---|---|
0 9 * * 1-5 |
平日の朝 9 時 |
0 13 * * * |
毎日 13 時 |
0 17 * * 5 |
毎週金曜 17 時 |
*/30 9-18 * * 1-5 |
平日 9〜18 時の 30 分ごと |
cron 式は慣れるまで読みにくいので、crontab.guru のような外部ツールで確認しながら組むのが現実的かと思います。
公式プラグインエコシステム（90+）
2026 年 4 月時点で、Codex の公式プラグインは 90 を超えています。全部覚える必要はなく、自分の業務ドメインに近いものから触っていけば十分です。主要どころを分類して紹介します。
| カテゴリ | 代表プラグイン | 典型的な用途 |
|---|---|---|
| コミュニケーション | Gmail, Slack, Discord | メール要約、チャンネル投稿、DM 監視 |
| ドキュメント | Google Drive, Notion, Box | 議事録保存、ナレッジ更新、資料共有 |
| 開発 | GitHub, Linear, Sentry | Issue/PR 操作、チケット作成、エラー追跡 |
| デザイン | Figma | スクリーンショット取得、コメント抽出 |
| AI/データ | Hugging Face | モデル情報取得、ベンチマーク収集 |
| その他 | Calendar, HubSpot, Intercom | 予定確認、CRM 操作、顧客対応 |
個人的に使用頻度が高いのは、GitHub / Slack / Notion / Gmail の 4 つです。この組み合わせだけでも、開発系副業の大半の雑務はカバーできる印象があります。
プラグインごとに必要な権限スコープが異なります。OAuth 認可時に付与範囲を確認し、必要最小限に絞るのが安全です。Gmail で「読み取りのみ」で済む場面に「送受信フルアクセス」を与えないようにしましょう。
実装例 3 本
ここからは、実際に私が試して便利だったワークフローを 3 つ紹介します。すべて Standalone Automation として組んでいます。
例 1: 朝 9 時の GitHub Issue トリアージ
毎朝 Issue を眺めて優先度を付ける作業、地味に時間を食います。ここを自動化しました。
# prompts/issue-triage.md
あなたは開発プロジェクトのトリアージ担当です。
### 手順
1. GitHub プラグインで `owner/repo` の未処理 Issue を取得する
2. 各 Issue の本文とコメントを読む
3. 以下の基準でラベルを付与する
- `priority/high`: 本番障害、データ損失、セキュリティ
- `priority/medium`: 機能要望のうち主要ユースケース
- `priority/low`: typo、軽微な改善、質問
4. 新規に追加した Issue の一覧を Slack `#dev-daily` に投稿する
5. 判断に迷った Issue は `needs-human-review` を付けて報告する
cron は 0 9 * * 1-5 で平日 9 時。2 週間回してみた体感では、ラベル付けの妥当性は 8 割くらいで、2 割は needs-human-review として人間側に回ってきます。この 2 割をレビューするだけで済むので、単純に作業量が 5 分の 1 に減りました。
例 2: 13 時の Sentry エラー調査 → 修正 PR 提案
昼休み明けに Sentry を見て、「このエラー増えてるな」と気付くパターンが多かったので、そこも自動化しました。
# prompts/sentry-investigation.md
### 手順
1. Sentry プラグインで過去 24 時間のエラーを取得する
2. 発生件数が前日比 +50% 以上のエラーを抽出する
3. 該当するコード位置を GitHub プラグインで特定する
4. 修正案を PR ドラフトとして作成する（自動マージはしない）
5. `#alerts` に「調査しました」コメントを投稿する
PR ドラフトの自動生成は便利ですが、そのままマージせず、必ず人間がレビューしてから進めることを強く勧めます。Automation が誤った原因を特定して、関係ないファイルを書き換える事故を、私自身 2 回経験しています。
例 3: 17 時の Slack 要約 → Notion へ保存
1 日の終わりに、主要な Slack チャンネルの流れを拾って、Notion にログを残します。
# prompts/slack-digest.md
### 手順
1. Slack プラグインで `#general`, `#dev`, `#customer` の今日の投稿を取得
2. スレッドも含めて文脈を拾う
3. 以下の形式で要約を作る
- 今日の主要トピック（最大 5 件）
- 未対応の質問・依頼
- 明日持ち越しの TODO
4. Notion プラグインで `Daily Log` データベースに新規ページを作成
5. タイトルは `Daily Log YYYY-MM-DD` とする
夕方 17 時に動かしておくと、18 時に業務を終える頃には Notion に今日のログが溜まっている、という流れになります。「あの話、どのチャンネルだっけ」と後から探す手間が目に見えて減りました。
設定ファイル例（擬似コード）
複数の Automation をまとめて宣言的に管理したい場合、YAML で定義しておくと運用が楽です。以下はあくまでイメージですが、このような形に揃えておくとメンテナンス性が上がります。
# automations.yaml
version: 1
automations:
- name: morning-issue-triage
schedule: "0 9 * * 1-5"
mode: standalone
prompt: ./prompts/issue-triage.md
plugins: [github, slack]
timezone: Asia/Tokyo
timeout: 15m
- name: sentry-investigation
schedule: "0 13 * * *"
mode: standalone
prompt: ./prompts/sentry-investigation.md
plugins: [sentry, github, slack]
timezone: Asia/Tokyo
timeout: 20m
- name: slack-daily-digest
schedule: "0 17 * * 1-5"
mode: standalone
prompt: ./prompts/slack-digest.md
plugins: [slack, notion]
timezone: Asia/Tokyo
timeout: 10m
全体像を 1 枚で
1 つ 1 つの部品はシンプルですが、スケジューラとプラグインが繋がることで、これまで手動でやっていた作業が勝手に片付いていく仕組みになります。
権限とガバナンス — worktree 実行と local 実行
Automations を運用するうえで、避けて通れないのがセキュリティ面の設計です。とくに気にしたいのが、コードを扱う Automation における実行環境の分離です。
Codex には「worktree で動かす」「local で動かす」という選択肢があり、それぞれ性格が違います。
| 項目 | worktree 実行 | local 実行 |
|---|---|---|
| 独立性 | 専用のワーキングツリーに隔離される | 手元の作業ツリーで直接動く |
| 副作用 | 本体ブランチに影響しにくい | 直接ファイルを書き換える |
| 用途 | 自動化全般、PR 生成 | 手動作業、対話的な修正 |
Automation のように人の目を離れて動くものは、基本的に worktree 側で実行しておくのが無難です。事故った場合も本体ツリーに波及しにくく、ロールバックも簡単です。
また、プラグインごとに「データの外部流出（exfiltration）リスク」も意識する必要があります。たとえば Gmail プラグインに過度な権限を渡すと、意図しないメール送信が発生する可能性はゼロではありません。以下のような運用ルールが現実的かと思います。
- プラグインの OAuth スコープは最小限に絞る
- Automation のプロンプトに「送信系アクションは必ず人間の承認を待つ」と明記する
- 秘匿性の高い情報（顧客データ、契約金額）は、プラグイン側から直接取得せず、別レイヤで加工する
コスト試算 — 月 $25〜$80 の現実感
Codex Automations の月額コストは、動かす頻度と使うモデルによって変わります。ざっくり 3 パターンに分けて試算してみます。
| プラン例 | Automation 数 | 1 日の起動回数 | 想定モデル | 月額目安 |
|---|---|---|---|---|
| 軽量 | 2 本 | 2 回 | 小型モデル中心 | $20〜$30 |
| 標準 | 5 本 | 7 回 | 小型 + 一部高性能 | $40〜$60 |
| 本格 | 10 本 | 15 回 | 高性能モデル多用 | $80〜$150 |
私自身は「標準」のゾーンで運用していて、実測で月 $50 前後に収まっています。時給換算で考えたとき、同じ作業を人間がやれば日 30 分、月 10 時間。これを時給 3,000 円で見積もると月 3 万円相当になるので、コスト対効果としては十分に合うラインです。
モデルの選定は意外と効きます。すべてを最上位モデルで走らせる必要はなく、「要約系は小型モデル、コード生成は高性能モデル」のように使い分けると、月額は半分近くまで抑えられることがあります。
落とし穴 — 実際にハマったポイント
しばらく運用してみて「これは事前に知っておきたかった」と思った落とし穴を 3 つ紹介します。
プラグイン認証切れ
OAuth トークンは永続ではありません。数週間〜数ヶ月で期限が切れて、ある日突然 Automation が失敗し始めます。失敗が積み重なってから気付くと、その間の自動化が丸ごと止まっているので、以下のような対策を入れておくと安心です。
- 失敗時に Slack へアラートを飛ばす Automation を 1 本別建てで用意する
- 週次で「認証状態チェック」だけを行う Automation を走らせる
タイムゾーンずれ
--timezone を指定し忘れると、全部 UTC で動きます。「朝 9 時」と思って組んだものが、実際には 18 時に走るという事故が起きます。最初に環境変数でデフォルトを固定しておくか、すべての Automation で明示指定するのが安全です。
プロンプトの曖昧さで暴走する
「いい感じに整理して」のような曖昧な指示は、Automation だと怖さが増します。対話型なら途中で止められますが、定時実行ではそれができません。プロンプトは「やること」「やらないこと」「判断に迷ったときの挙動」の 3 点セットで書いておくと、事故率が下がります。
他の自動化ツールとの比較 — どれを選ぶべきか
Codex Automations が便利でも、「すべてを Codex に寄せるべきか」というと話はそう単純ではありません。自動化の選択肢は 2026 年時点でも豊富で、用途によってはほかが素直に収まるケースもあります。ここでは主要な 4 つを並べて比較してみます。
自動化ツール 4 種の比較
筆者が実際に触った範囲で、Codex Automations、GitHub Actions の cron、Zapier、自作 cron（VPS 等で動かす古典的な方法）を比較します。数値や価格は 2026 年 4 月時点の情報で、今後変動する可能性があります。
| 軸 | Codex Automations | GitHub Actions cron | Zapier | 自作 cron |
|---|---|---|---|---|
| 対話性 | ○ | × | 限定的（AI Copilot で部分対応） | × |
| 状態持続 | ○（rollout） | × | ○（履歴・ストレージ） | 自前で実装 |
| インテグレーション数 | 公式 90+ | 無限（YAML で自由記述） | 7,000+ | 自前で実装 |
| 月額目安 | Codex Pro $20〜 | 無料〜（従量課金） | $29〜 | インフラ代 |
| 学習コスト | 中 | 低〜中 | 低 | 高 |
| LLM 判断組み込み | ネイティブ | 工夫が必要 | AI Copilot で対応 | 工夫が必要 |
| デバッグのしやすさ | UI + ログ | ワークフロー実行ログ | UI ベースで見やすい | 自前で組む必要 |
| ベンダーロック | 中（OpenAI 依存） | 低 | 中〜高 | なし |
整理してみると、各ツールの「得意分野」が意外とはっきり分かれていることが分かります。Codex Automations は AI 判断と公式プラグインの組み合わせが強みです。GitHub Actions は柔軟性と無料枠、Zapier は圧倒的なインテグレーション数、自作 cron はコントロールの完全性、といった具合です。
どの自動化ツールを選ぶか
どれを選ぶかは、結局のところ「どの軸を重視するか」に尽きます。筆者が相談を受けるときに使っている判断基準を、参考として共有します。
- Codex Automations: AI 判断を含む定期タスクに向いています。文章要約、Issue/チケットのトリアージ、エラーの原因推定、Slack の投稿要約など、「読んで考えて書く」という作業に強みがあります。プロンプトで挙動を調整できるので、運用中にルールが増えても対応しやすい印象です
- GitHub Actions cron: リポジトリと密結合した自動化や、CI/CD の延長として動かしたい処理に向きます。たとえばテストの定期実行、依存ライブラリの更新 PR 生成、リリースノート作成などです。LLM 判断を入れたい場合でも可能ですが、Codex Automations に比べると書くコードは増えます
- Zapier: ノーコードでチームに配りたい場合、エンジニア以外のメンバーが触る可能性がある場合に向きます。7,000 以上のインテグレーションのおかげで、マイナーな SaaS との連携もほぼ揃っています。逆に、複雑な分岐処理やカスタムコードを多用する用途にはやや窮屈です
- 自作 cron: データ主権が重要な場合、外部サービスに載せられない処理、低頻度で安定性だけ欲しい用途に向きます。VPS や Kubernetes CronJob で淡々と動かす選択肢です。柔軟性は最大ですが、運用コストは間違いなく高くなります
もちろん、これらは「排他的な選択肢」ではなく、組み合わせて使うのが現実的です。筆者自身も、軽い通知系は Zapier、リポジトリ系は GitHub Actions、AI 判断が入るものは Codex Automations、データを外に出したくない処理は自作 cron、という具合に使い分けています。「全部 1 つに寄せる」ではなく、「それぞれの得意分野に流す」発想のほうが運用は安定しやすいかもしれません。
AI 判断の柔軟性 vs 予測可能性
比較表で見落としがちなのが、「AI 判断を入れると実行結果が毎回同じにならない」というトレードオフです。これは Codex Automations の弱点でもあり、強みでもあります。
GitHub Actions のような従来型の自動化は、ワークフローが決まれば結果は常に予測可能です。同じ入力には同じ出力が返る、という古典的な再現性があります。一方で、想定外の入力に対しては「失敗する」か「変な結果を出す」のどちらかになりがちです。
Codex Automations のような AI 判断を含む自動化は、この逆の性質を持ちます。想定外の入力にもそれなりに対応できる柔軟性がある反面、同じ Issue のラベル付けがセッションごとに揺れる可能性もあります。厳密な再現性は期待できませんが、雑多な情報を扱うバックオフィス業務では強みになります。
コスト面もよく質問されます。Codex Automations を標準プランで回すと、月 $40〜$60 ほどの追加コストが発生します。GitHub Actions や Zapier でも似た処理は組めますが、LLM 呼び出しの別途料金を考えると、トータルで大差ないケースもあります。月 $5〜$30 の増分は、浮く人件費と比較すれば回収可能な範囲、というのが筆者の肌感覚です。
運用面の落とし穴として、どのツールでも共通で効くのが「プラグイン認証切れ」「タイムゾーンずれ」です。Zapier でも OAuth の期限切れで連携が止まる事故は起きますし、GitHub Actions の cron は UTC 固定で時差計算を間違えやすいです。「ツールの違い」より「運用に組み込めるか」で選ぶほうが実用的かもしれません。
最終的に、筆者の立場では「Codex Automations は万能薬ではないが、AI 判断が欲しい領域では現時点でバランスのよい選択肢の 1 つ」という評価に落ち着いています。プロジェクトの性質やチーム体制で最適解は変わるので、小さく試してから広げるのが安全だと感じます。
まとめ — AI 秘書は「小さな自動化の連鎖」
ここまで読んでいただいた通り、AI 秘書は「1 つの巨大タスクを AI にぶん投げる」話ではありません。むしろ逆で、小さな定型タスクを分解して、それぞれに Automation を割り当てていく積み重ねです。
朝 9 時の Issue トリアージ、13 時の Sentry 調査、17 時の Slack 要約。どれも単体では 10〜20 分の作業ですが、これが毎日毎週積み上がると、1 人運営では無視できない負荷になります。Codex Automations と公式プラグインの組み合わせは、この「積み上がり領域」を静かに消していくための道具、という位置づけで見ると使いこなしやすいかと思います。
とはいえ、すべてを自動化するのが正解とは限りません。人間が判断すべき場面まで AI に回してしまうと、むしろ事故のリカバリコストで赤字になることもあります。最初は 1〜2 本だけ組んで、運用が安定したら少しずつ増やす、くらいのペースがちょうどいいかもしれません。
AI 秘書を組む最大の利点は、コスト削減以上に「自分の時間が主業務に戻ってくる」ことだと感じています。浮いた時間で何をするかは、結局のところ人間側の課題として残り続けます。この記事がそのきっかけになれば嬉しいです。
参考リンク
- Codex Automations 公式ドキュメント（developers.openai.com）
- How I'm Using OpenAI Codex Automations（Owain Lewis ニュースレター）
- Introducing upgrades to Codex（OpenAI 公式ブログ）
- Model Context Protocol 公式サイト
- Anthropic Routines 発表ブログ
- GitHub Actions - Events that trigger workflows（schedule）
- Zapier 公式サイト
- n8n 公式サイト
- Make 公式サイト
- crontab.guru（cron 式の検証ツール）