Claude Code を1か月本気で使い込むと、自動化の輪郭がだいぶ見えてくる。筆者は Max20 プランを継続契約していて、PCのアイドル時間を中心に重い処理を Claude Code 経由で回している。ここでは私の実運用ログを公開しつつ、予定タスクを”起動装置”として使う発想、Haiku から Python や Opus 4.7 を呼び出す連鎖、ローカルLLMとの併用、業務応用までを順番にまとめる。
- Claude Code のCLI版とデスクトップ版どちらを選ぶべきか
- 予定タスクを”その場の命令”より強い武器として使う発想
- Haiku を入り口にして Python や Opus 4.7 を内部呼び出しする流れ
- Sonnet / Opus / Haiku を実用基準で使い分けるコツ
- Ollama などローカルLLMと併走させる構成
- 業務に直結する自動化テンプレ（メール処理の例）
- トークンコストの比較とプラン選びの指針
CLI版とデスクトップ版、どちらを選ぶか
Claude Code には端末で動かす CLI 版と、ウィンドウで完結するデスクトップ版（Web/アプリ）がある。両者は同じモデルを使うものの、得意分野が違う。
| 用途 | CLI版 | デスクトップ版 |
|---|---|---|
| 長時間バッチ・スクリプト連携 | ◎ 強い | △ 不向き |
| 会話ベースの設計相談 | ○ | ◎ 履歴とUIが優秀 |
| 予定タスク（Routines） | △ 自前で組む | ◎ ネイティブ機能あり |
| スマホからの起動（Dispatch） | × 非対応 | ◎ アプリ版専用機能 |
| 外部MCP / 拡張 | ◎ なんでも繋がる | ○ 制限あり |
| プロジェクト切替 | cwd 単位で軽い | セッション単位で重い |
結論を先に書くと、筆者はデスクトップアプリ版だけで運用している。理由は2つあって、ひとつは予定タスク（Routines）機能がネイティブで使えること、もうひとつは履歴と統計の可視化UIが長期運用の判断材料として優秀だからだ。CLI版もパワフルなのは確かだが、予定タスクを起動装置として使う今の運用スタイルだと、デスクトップ版だけで必要な機能はほぼすべて揃っている。
とはいえ、これは万人向けの正解ではない。読者の用途次第でCLIに振ったほうがいい場面もあるので、それぞれの強みを以下に整理しておく。
CLI版が向いている場面
- パイプで標準入出力を他コマンドと繋ぎたい
- git の状態を端末で見ながら作業したい
- SSH先のサーバ上で動かしたい
- シェルスクリプトの一部として組み込みたい
デスクトップ版が向いている場面（筆者の選択）
- 毎日同じ時刻に走らせる仕組みを組みたい（Routines機能）
- 外出中にスマホから手元のPCで動く処理を呼び出したい（Dispatch機能）
- 会話の履歴を残して相談を重ねたい
- UI上から軽くタスクを起動したい
- 過去の使用量・トークン消費を可視化したい
- 複数の予定タスクを管理画面で俯瞰したい
筆者のMax20運用ログ — 31日アクティブ/71.4Mトークン
百聞は一見にしかず、ということで実運用の数字をそのまま出す。デスクトップ版の統計画面のスクリーンショットがこちら。左にRoutines一覧、右に概要パネルが並んでいる。
ハイライトを書き出すとこうなる。
| 項目 | 1か月の数値 |
|---|---|
| セッション数 | 5,507 |
| メッセージ数 | 160,891 |
| 合計トークン数 | 71.4M |
| アクティブ日数 | 31日（毎日稼働） |
| 最長連続日数 | 27日 |
| ピーク時間帯 | 5時台 |
| よく使うモデル | Opus 4.7 |
直近30日に絞った数字も並べておく。
30日間で見ても全期間とほぼ重なり、運用が定常化していることが分かる。
- セッション数: 直近30日 5,469 / 全期間 5,507
- メッセージ数: 直近30日 148,854 / 全期間 160,891
- 合計トークン: 直近30日 69.7M / 全期間 71.4M
- アクティブ日数: 直近30日 29日 / 全期間 31日
30日と全期間がほぼ同じ数値なのは、Claude Code 側で使用統計が可視化されるようになったのがおよそ27日前で、まだ全期間として記録されている範囲が短いからだ（最長連続日数27日が両方で一致しているのもそのため）。それでも1日あたり約180セッション・約5,000メッセージのペースで何かしらが動き続けている計算になる。手動でこの量を打ち込むのは現実的でなく、ほとんどは予定タスク経由で勝手に立ち上がっているぶんだ。
ピーク時間が5時というのが筆者の使い方を象徴している。寝ている間に予定タスクが順次起動して重い処理を片付け、朝起きた時には結果が揃っている、という運用に振り切っているからだ。
運用値の補足: ここに並べた数値は Haiku/Sonnet/Opus を使い分けて最適化した後の値で、 「Claude Code を効率よく回すとここまで届く」という上振れ事例として読んでほしい。 Anthropic 公式の集計では、 Claude Code 利用者の平均的な使用量は 1日あたり約 6ドル相当 (月額換算で約 180ドル)、 90% のユーザーは 1日 12ドル以下に収まるとされる。 本記事の運用は 1日あたり約 230万トークン消費しているので、 平均利用の 10 倍以上のヘビーレンジに位置する。 Max20 サブスクなら定額枠の中で動かせるため、 同等規模を API 従量で回すと月額 1,000ドル超になる作業をサブスク内に収められる。
逆に言うと、「Opus を使いたいけれど枠が足りない」「気付いたら週半ばで使えなくなる」と悩んでいる人がいたら、本記事で扱う 役割分担と起動装置型の組み方 がそのまま解決になる可能性がある。Opus一本という前提を捨ててHaikuに起動とゲートキーパーを任せれば、同じサブスク枠で何倍もの量を回せるようになる。以降のセクションは、その具体的な組み方を順番に説明していく。
1か月で71.4Mトークンというのは Max20 プランの上限近辺で、デスクトップアプリの画面にはメルヴィルの『白鯨』(Moby-Dick) 約266冊ぶんに相当する旨が表示される（Claude Code 側のお馴染みの比喩表記だ）。ここまで使うと Opus 4.7 中心で組んだルーチンは早晩トークン不足になる。だから「Opus一辺倒」ではなく、Haiku/Sonnet/Opus を意識的に切り分ける必要が出てくる。
予定タスクは”起動装置”として使う — 起動装置型自動化という発想
Claude Code の予定タスク機能は、「決まった時刻に決まったプロンプトを走らせる」だけのものに見える。けれど発想を変えると、これは複雑なタスクの起動装置として使える。本記事ではこの設計思想をひとつの名前で呼んでおきたい。
予定タスク（Routines）を単なる定期実行ではなく、別プロセスを立ち上げる「起動装置」として捉える設計思想。会話履歴から切り離した独立セッションで、必要なモデル（Haiku/Sonnet/Opus）と Python スクリプトを順次呼び出して処理する。トークン消費を予測しやすくし、Opus を本当に判断が必要な瞬間だけに絞れる。
たとえば Opus 4.7 に「データを集めて、要約して、コミットして、報告書を作って」と1回のプロンプトで頼むと、応答が長くなりすぎて途中で破綻したり、トークンを大量に食ったりする。ところが起動装置型で組むと、予定タスクが内部で別プロセスを立ち上げ、必要に応じて Python スクリプトや別モデルを呼び出して処理を分割してくれる。
起動装置型の隠れた強みがこれだ。起動した Haiku がまず状況を確認し、Opus を呼ぶ価値のある処理がなければそのままスキップする、という組み方ができる。
たとえば「新しいデータが来ていない」「閾値を超える変化がない」「前回と同じ結果しか出なさそう」といった場合、Haiku の判定だけで完結して Opus の立ち上げを見送れる。
ルーチンの大半は何もせずに終わるが、本当に必要な日だけ Opus が動く、という運用にできる。これだけで月間のOpus消費がかなり削れる。
起動装置型で得られる4つの利点:
- 独立セッションで立ち上がるので、会話履歴のトークンを引きずらない
- 処理時間が長くても自分の作業を止めない
- 失敗したら次回の起動でリトライしやすい
- 複数のタスクを時間差で組み合わせて1つの大きなパイプラインにできる
つまり、予定タスクは「定期実行ボタン」というより「重たい仕事を自分の手から離して回し続ける装置」として捉えるとしっくりくる。寝ている間や、別の仕事に集中している間にも黙々と動いてくれる。本記事ではこの考え方を起動装置型自動化と呼ぶことにする。以降のセクションも、すべてこの設計思想を前提に組み立てている。
なぜわざわざ名前を付けるのか
「予定タスクで自動化する」だけだと、Routines機能の使い方解説と区別がつかない。起動装置として使うという設計思想を明示的に区別しておくと、自分の中でも設計の判断軸がブレないし、ほかの人に伝えるときにも要点が伝わりやすい。
たとえば「このタスクは起動装置型じゃなくて単発のプロンプトでいい」「これは起動装置型に組み替えたほうがOpusを節約できる」という判断が、ひとつの言葉で素早くできるようになる。設計の言葉を持つことは、運用を続ける上で意外と効いてくる。
スマホから起動する: Dispatch との連携
予定タスクは「決まった時刻に動く起動装置」だが、Anthropicが2026年に追加した Dispatch（リサーチプレビュー）を組み合わせると、スマホからメッセージを送るだけでデスクトップ上の処理を呼び出せるようになる。
仕組みは単純で、スマホ側の Claude モバイルアプリとデスクトップ版をあらかじめペアリングしておけば、移動中に「○○を集計しておいて」「××のレポート作って」とメッセージを送るだけで、デスクトップ側で対応する Claude Code セッションが立ち上がる。プロジェクトに仕込んだ CLAUDE.md やスクリプト、MCPコネクタにそのままアクセスして処理を進めてくれる。
- 時刻ベース（毎朝7時など）: 予定タスク (Routines) で起動 → 定例の集計・監視・レポートに向く
- スマホからのメッセージ: Dispatch で起動 → 移動中に「これやっておいて」と任せる場面
- 外部イベント（GitHubやチャット）: Channels / Slack 連携で起動 → CI失敗・レビュー依頼への即応
筆者はDispatchを本格運用しているわけではないが、予定タスクと組み合わせる発想は理にかなっている。毎朝定時に走る仕組みは予定タスクで組みつつ、急ぎで結果が欲しい時にはスマホからDispatchで同じ仕組みを呼び出して即時実行させる、といった使い方が考えられる。「組んでおいた仕組みの起動口を増やす」ことで、PCの前にいなくてもタスクを動かせるようになる。
これはデスクトップアプリ版の強みでもある。 Dispatch は Claude Code デスクトップアプリ専用機能で、 CLI版だけだと使えない。 記事冒頭で「筆者はデスクトップアプリ版だけで運用している」と書いたが、 その判断を後押しするのが Dispatch の存在だ。 予定タスク（Routines）と Dispatch がそろうと、「時刻ベースの自動起動」と「スマホからの手動起動」がアプリ内で完結する。 CLI版を併用するとこの体験が分断される。
Haikuを入り口にしてPython・Opus 4.7を呼び出す
具体的な構成として筆者がよく使うのが、Haiku を起動装置として置き、内部で Python スクリプトや Opus 4.7 を呼び出す形だ。
イメージはこう。
| レイヤー | 役割 | 使うもの |
|---|---|---|
| 外側（起動） | 定時に立ち上がり、内部処理を呼ぶだけ | Haiku 4.5 |
| 中間（実処理） | データ取得・整形・保存・通信 | Python スクリプト |
| 内側（判断） | 判定・分析・生成 | Opus 4.7 や Sonnet |
この三層構造の何が嬉しいかというと、外側が安いHaikuなので、起動と最終報告だけならごくわずかなトークンで済む。実処理は Python 側で確定的に動くので、AIの揺らぎを気にしなくていい。判断が必要な箇所だけ Opus を内部で呼び出すから、Opus の消費を本当に必要な部分に集中させられる。
Haiku は安くて速いが、複雑な要件分解や曖昧な判断は苦手。「このメールは緊急か」を判定させると、文面の婉曲表現を取り違えて誤判定することがある。判断が要るところは Opus か Sonnet に必ず渡す設計にする。
もう一つの構成: Opusを呼ばずローカルLLMで完結させる
三層構造の応用形として、Opus を一切呼ばず、Haiku ＋ Python ＋ ローカルLLM だけで完結させるパターンもある。クラウドへ渡すのは Haiku の起動と簡単な調停判定だけで、重い生成や分析は手元の Ollama に任せる組み方だ。
- 外側（起動）: Haiku 4.5 が定時に立ち上がり、何をやるかを判定して指示を出す
- 中間（実処理）: Python スクリプトでデータ取得・整形・保存・通知
- 内側（生成・分析）: ローカルLLM (Ollama) で分類・要約・下書き
業務的に「人間が必ず最終チェックする前提で、AIには下処理だけ任せたい」というケースなら、この構成で十分すぎる。クラウドに渡すのは Haiku の起動分のごく小さな量だけなので、Opus トークンを一切減らさずに毎日回せる。たとえば社内文書の分類、会議録の下書き整形、ログのパターン抽出といった用途は、これで成立する。
わざわざ Claude Code を経由する理由 — Windowsスケジューラとの違い
正直なところ、ここまで述べた自動化はClaude Code を使わなくても組める。Windows のタスクスケジューラ（または Mac/Linux の cron）でバッチを定時起動して、その中で Anthropic SDK や Ollama を直接叩けば、機能的には同じことができる。
それでも筆者が Claude Code 予定タスクに一本化している理由はひとつ、タスクが増えてきたときの管理のしやすさだ。3〜5個までならどちらでも変わらないが、10個を超えてくると「どこに何を仕掛けたか」「最後に動いたのはいつか」「失敗していないか」を確認する場所がバラけるのが効いてくる。
| 軸 | Claude Code 予定タスク | Windows タスクスケジューラ等 |
|---|---|---|
| AI連携 | 最初から組み込まれている | スクリプト側で API 呼び出しを書く |
| 実行履歴の確認 | アプリ内で一覧表示 | イベントビューアで個別確認 |
| モデル切替 | タスクごとに指定可 | スクリプトに直書き |
| 失敗通知 | アプリ通知に統合 | 別途実装（メール・Slack等） |
| セットアップ | UIから即時登録 | スケジューラ設定＋スクリプト＋認証情報の3点管理 |
| 追加コスト | サブスク内で完結 | OS標準で無料 |
| 移植性 | Anthropic アカウント単位 | そのマシンに紐づく |
Windowsタスクスケジューラ補足: Windows 標準で無料。 PowerShell スクリプトやバッチファイル、 Python スクリプト (.py) を定時起動できる。 実行ログは「イベントビューア」から確認する。 スクリプトの中で Anthropic 公式の SDK (Python の anthropic パッケージなど) や Ollama を呼べば、 Claude Code を経由しない自動化も成立する。 タスクスケジューラ + 自前スクリプトという組み合わせは Claude Code 予定タスクと棲み分け可能。
「タスクが片手で数えられる範囲」なら Windowsスケジューラで全く問題ない。10個を超えて並走させ始めるあたりから Claude Code に集約しているほうが圧倒的に楽になる、というのが筆者の体感だ。今の運用では予定タスクが30個近く動いているので、もし全部 Windowsスケジューラ＋スクリプトで組んでいたら管理が破綻していた可能性が高い。
Haikuのメリット・デメリットを冷静に
Haiku のメリット:
- コスト: 圧倒的に安い
- 速度: 応答が速い
- 用途: 起動・テンプレ整形・分類に向く
Haiku のデメリット:
- 精度: 複雑な判断・長文理解で取りこぼしやすい
- 用途: 分析・生成・監修には向かない
Haiku を起動装置として割り切ると「Haiku で全部やろうとして精度が足りない」問題は起きない。むしろ、Opus一本で組むとトークン上限にすぐ到達するほうが現実的なリスクで、Haiku を要所に挟んでおくほうが Max20 プランを長持ちさせられる。
Sonnet / Opus / Haiku の使い分け
実際の筆者の使用量内訳がこちらになる。Opus 4.7 が中核を担いつつ、要所で Sonnet や Haiku が補助している配分がわかる。
3つのモデルを実用基準で振り分ける目安を表にまとめた。あくまで筆者の感覚値だが、ベースラインとしては機能する。
| モデル | 得意なこと | 避けるべきこと | 1日の使用イメージ |
|---|---|---|---|
| Haiku 4.5 | 起動・分類・テンプレ整形・大量の単純判定 | 分析・設計・難しい文章生成 | 定時タスクの外側、ログのフィルタリング |
| Sonnet 4.6 | コード実装・差分監査・要約・リライト | 長時間の構想練り・横断分析 | 日中のメイン作業、コミット単位のレビュー |
| Opus 4.7（1M） | 設計・レビュー・横断分析・複雑な判断 | 単純作業・大量繰り返し（コスト的に） | 朝晩の構想セッション、週次のメタレビュー |
使い分けの一般原則は単純で、判断の重さに応じてモデルの重さを選ぶ。誰でも判定できる作業を Opus に任せるのはコストの無駄、難しい設計判断を Haiku に振るのは精度の博打、というだけのこと。
予定タスクの中で複数モデルを切り替える
予定タスク自体に「このタスクはHaikuで起動」と指定しつつ、内部タスクとして Opus を呼び出すといった構成も取れる。たとえば筆者の場合は、毎朝の重たい解析タスクを「Haiku で起動 → Python が CSV を整形 → 内部タスクで Opus を呼び出して判断 → Haiku で Discord に通知整形」のような連鎖で組んでいる。
これによって「Opusがフルで動くのは判断が必要な数十秒間だけ」という運用ができ、Opus の消費を抑えながら判断精度は確保できる。
ローカルLLM（Ollama）との併用
クラウドのClaudeだけで完結させない、というのも長期運用では大事になってくる。業務シーンで例えると、筆者は下処理や一次仕分けはローカルLLM、顧客に出す仕上げや経営判断だけ Claude、という二段構成で組んでいる。
- 経理: 領収書・請求書PDFの一次仕分け → Ollama (Qwen系・小型モデル) で完結。 科目別・取引先別に振り分けるだけならクラウド代をかける必要がない
- カスタマーサポート: 過去FAQの類似質問抽出 → Ollama で類似度ベース抽出。 機密性の高い顧客情報を外に出さずに済む
- 議事録: 録音文字起こしと要点抽出 → ローカル Whisper で文字起こし、 Ollama で要点抽出。 機密会議の処理に向く
- コード補完: 短い関数生成・タイプヒント追加 → Ollama (CodeLlama / Qwen Coder 系)。 IDE 統合で待ち時間を短縮
- 翻訳: 大量ドキュメントの一次翻訳 → Ollama で粗訳、 Sonnet/Opus で最終仕上げ。 量で稼ぐ用途
- 分類: メール・タスク・ファイルの振り分け → Ollama (軽量モデル) で十分。 大量処理ほどコスト差が効く
Ollama 側は GPU さえあれば実質コスト0で動く。クラウドAPIに渡す前段で「これはClaudeに渡す価値があるか」を Ollama が振り分ける仕組みを入れておくと、Claudeの稼働時間がぐっと減る。Haikuのゲートキーパーと役割が似ているが、Ollama の場合はトークン消費そのものがゼロなので、毎時・毎分動かすような頻度の高い前処理でも気にならない。
業務応用のイメージ: 経理担当が朝に出社したら、 Ollama が昨日のうちに領収書 PDF を科目別フォルダに振り分け済み。 人事担当者の前には、 応募者100名から要件マッチで30名に絞られた一覧と要約が並んでいる。 担当者は「人間が判断すべき30件」だけに集中できる。 社外提出物の最終文面だけ Claude に整えてもらう──こういう業務フローが、 ローカルLLM＋Claude で現実的に組めるようになる。
業務応用の例：メール処理を半自動化する
具体例として、筆者の周辺で実際に組まれているメール処理テンプレを匿名化して紹介する。
想定する流れ
- 定時に Gmail（または Outlook）の MCP コネクタ経由で未読メールを取得
- Haiku が件名と冒頭を読み、「業務」「案内」「広告」「個人」に分類
- 業務カテゴリだけ Sonnet に渡し、要点と返信案ドラフトを生成
- 返信案を Slack（または Discord）に投稿
- 人間が承認したものだけ実際に返信する
ポイントは最後の送信操作を人間が必ずやること。AI に勝手に返信させるのはリスクが大きすぎるので、文面の起案までは自動化して、最終的な確認と送信ボタンを押すのは自分の手で残しておく。
コスト感
| 処理 | 使うモデル | 1メール当たりの目安 |
|---|---|---|
| 分類 | Haiku 4.5 | 0.0001ドル未満 |
| 要約・返信案 | Sonnet 4.6 | 0.001〜0.005ドル |
| 承認 | 人間 | 10秒 |
仮に1日100通来るとして、月間でAPI課金が 数ドル〜十数ドル の範囲に収まる。Max20プランの定額枠の中でこれを完結させたければ、サブスクの予定タスク経由で組めばよい。
予定タスク vs 都度命令、トークンコストの違い
同じ作業を「予定タスクで起動する」のと「会話の中で都度命令する」のとで、トークン消費は明確に違う。
| 予定タスク経由 | 会話中の都度命令 | |
|---|---|---|
| 会話履歴の引きずり | なし（独立セッション） | あり（毎回フル展開） |
| システムプロンプト | 定義したぶんだけ | 会話の文脈ごと積み上がる |
| モデル切替 | タスク単位で固定指定可 | 同一セッションは1モデル |
| 並列実行 | タスク同士で容易 | 1セッション内では難しい |
| トークン消費の安定性 | 予測しやすい | 会話が長くなるほど増える |
同じ「データ整形→要約→通知」を1日3回回す場合、会話の中で続けてやると履歴が肥大して各回の入力トークンが膨らむ。一方、予定タスクとして3つに分ければ、毎回ほぼ同じトークン量で安定する。同じ作業を継続的にやるなら、予定タスクのほうがトークン的にも結果的にも有利になりやすい。
プラン選びの指針 — Pro / Max5 / Max20
「どのプランから始めるべきか」という質問はよくもらう。筆者の体感を整理するとこうなる。
| プラン | 主な使えるモデル | こんな人向け |
|---|---|---|
| Pro | 基本的にSonnet中心（Opusは事実上ほぼ使わない運用になる） | 個人の試行・学習目的、Sonnetでも十分な作業 |
| Max5 | Sonnet＋Opusも現実的に運用可能 | 本格的に自動化を組みたい入口、複雑タスクが時々発生 |
| Max20 | Opusを多用する想定で組める | 業務利用、複数プロジェクト並行、長時間タスク常態化 |
Opus を本気で使いたい、複雑なタスクを定期で回したい、という段階に入ったら Max5 以上、長時間タスクを毎日複数走らせるなら Max20 がストレスなく使える、というのが目安。
この記事を読んで作れるようになること
- 定時に勝手に走り、必要なときだけ通知してくる監視自動化
- Haiku 起動 → Python 実行 → Opus 判断、という段階処理パイプライン
- Ollama を前段に置いて Claude の消費を絞るハイブリッド構成
- 業務メールを分類・要約・返信案まで作って人間が承認するだけにするテンプレ
- Max20プランでも長持ちするモデル別の振り分け設計
1か月の実運用で確信したのは、Claude Code を本気で使うとPCがほぼ常時何かしらの仕事をしている状態になるということ。アイドル時間が減る代わりに、自分の意識が空いている時間が増える。これは生産性の話というより、生活の組み立て方そのものに関わる変化だと思う。
よくある質問
Q. CLI版とデスクトップ版、どちらで始めるのがおすすめですか？
用途次第ですが、予定タスク（Routines）を中心に自動化を組みたいならデスクトップ版から始めるのが楽です。筆者もデスクトップ版だけで運用しています。シェルスクリプトと深く連携させたい、SSH先のサーバで動かしたいといった用途ならCLI版が向きます。同じAnthropicアカウントで併用も可能ですが、最初はどちらか一方に寄せて運用を固めるのがおすすめです。
Q. Haiku で起動して Opus を内部で呼ぶと、結局 Opus のトークンを使うのでは？
その通りで、Opus を呼んだ瞬間は Opus 分のトークンを使います。狙いは「Opusを呼ぶ時間を最短にする」こと。前処理と後処理を Haiku/Python に任せれば、Opus が動くのは判断が必要な数十秒だけになり、結果としてOpus消費を圧縮できます。
Q. Pro プランから始めても自動化はできますか？
できます。ただしPro はSonnet 中心の運用になるため、複雑な判断や長時間バッチを Opus でゴリゴリ回したくなったら Max5 以上を検討するのが現実的です。
Q. ローカルLLMはどのGPUから始められますか？
軽量なモデル（7B〜13B）なら VRAM 12GB 程度から実用的に動きます。重い処理を任せたい場合は VRAM 24GB 以上のGPUが選択肢に入ってきます。Ollama は導入が簡単なので、まずはここから試すのがおすすめです。
Q. 予定タスクが失敗したら気付けますか？
予定タスク側のログを定期的に確認するか、別の予定タスクで「失敗を検知して通知する」仕組みを組むのが王道です。Slack や Discord への通知を組み込んでおくと運用が楽になります。
まとめ
Claude Code をMax20で1か月回した結論をまとめておく。
- CLI版とデスクトップ版は用途で住み分ける。筆者は予定タスク中心の運用なのでデスクトップ版に統一した
- 予定タスクは”定期実行ボタン”ではなく 起動装置型自動化（Routines-as-launcher パターン） として使うと真価が出る
- Haiku を起動装置に、Python を実処理に、Opus 4.7 を判断に、と役割で分担する
- Opus 一本では Max20 でもトークン枠に到達する。使い分けが前提になる
- ローカルLLM（Ollama）を前段に置くとClaudeの稼働時間が大幅に減る
- 業務応用はメール処理が手軽な入口。送信は人間、起案は AI のルールを徹底する
- 同じ作業を続けるなら予定タスクのほうがトークン的に有利になりやすい
- プランは Pro→Max5→Max20 の順に試して、Opus 多用が前提なら Max5 以上を選ぶ
1か月の実運用ログを公開した目的は、自動化を組む前に「自分のPCに何をどれだけ任せたいか」を一度棚卸ししてほしかったから。Max20の枠は大きいが無限ではないし、Opus はずっと万能でもない。役割分担と起動装置という2つの考え方を持ち込むだけで、Claude Code は驚くほど長く伴走してくれる相棒になる。
関連記事
AI自動化の枠組みでも読みたい
- 量産型 / 投資型の設計思想を全体で見る → 2026年版｜AI自動化は本当に稼げるのか？
- 量産型を 4 層構造で組む実例 → 量産型AI自動化の4層構造 ─ ストックフォト動画系で動かしている中身
本記事は AIツール図鑑編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
コメント