毎日の記事公開も、内部リンクの点検も、経理CSVの仕分けも、繰り返しの作業はClaude Codeに任せれば無人で回せます。本記事の活用事例は、他社事例の寄せ集めではありません。Web制作会社を本業とする編集部が、記事メディア81本の運営で毎日実際に動かしている自動化7つを、仕組み・指示文・つまずいた点まで含めて公開します。Claude CodeはAnthropicが提供するターミナル上のコーディングエージェントで、ファイル操作からコマンド実行まで日本語の指示で完結します。初心者向けの説明はここまでにして、実物の話に入ります。
Claude Codeは何に使える？活用事例7つの全体像
結論から言えば、Claude Codeの用途はコードを書く作業に限りません。「ファイルを読んで、判断して、書き出す」という形にできる業務なら、記事執筆・データ集計・品質検査まで任せられます。編集部が毎日動かしている7つの活用事例を、先に一覧で示します。
| 事例 | Claude Codeにやらせていること | 従来の手作業 | 人がやること |
|---|---|---|---|
| ① SEO記事の自動公開 | 毎日1〜2本をキーワード選定から執筆・公開まで無人実行 | KW選定・執筆・入稿を全て人が行う | 戦略の見直しと抜き打ち検品 |
| ② 内部リンク一括監査 | 81本の孤立記事・リンク切れの洗い出しと結線 | 81本を1本ずつ開いて目視で確認 | リンク方針の決定 |
| ③ タイトル一括改稿 | GSC実データから77本のタイトル案を作成・適用 | GSC画面を1クエリずつ見て手で案を書く | 1本ずつの最終照合 |
| ④ 経理CSVの仕分け | 明細への勘定科目の付与と月次集計 | 明細を1行ずつ目で見て仕分ける | 「要確認」行の判断 |
| ⑤ LP・サイトの機械QA | コントラスト・改行・はみ出しの検査スクリプト作成と実行 | 画面を目視でチェックして指摘を書き出す | デザイン判断 |
| ⑥ ブラウザ自動操作 | Playwrightでの多画面幅スクショと実機確認 | 手でブラウザを操作して1枚ずつ撮る | 最終の目視確認 |
| ⑦ 定期実行の無人運用 | cron/launchdからの毎日の自動起動 | 毎回人が思い出して手動で起動する | ログの確認 |
7つには共通点があります。第一に、毎回ほぼ同じ手順で終わる作業であること。第二に、入力と出力がファイル（CSV・HTML・ログ）で受け渡せること。第三に、失敗してもやり直しがきくことです。逆に、一度きりの重要判断や、失敗が取り返せない操作（本番データベースの削除など）は無人化の対象から外しています。
読者が自分の業務で候補を探すときも、この3条件に当てはめるのが近道です。「先週も同じ手順でやった」と思い出せる作業があれば、それが最初の1事例になります。
活用事例①：SEO記事の毎日自動生成とWordPress自動公開
編集部の記事メディア（公開81本）では、SEO記事の作成をClaude Codeが毎日1〜2本、無人で公開まで実行しています。人が触るのは、キーワード戦略の見直しと、公開後の記事を抜き打ちで検品するときだけです。7事例の中で最も工程が長く、仕組みを図で示すのが早いので先に全体像を出します。
毎日12:00に動く自動公開パイプラインの構成
不合格ならここで終了＝公開せずログだけ残す
STEP1〜2：起動と選定
macOSのlaunchd（Windowsならタスクスケジューラ、Linuxならcron）が毎日決まった時刻にClaude Codeを起動します。何を書くかの判断基準は、すべて事前にスキルファイルへ書いてあります。
STEP3〜4：執筆と機械検査
執筆後、公開前に文字数・内部リンクの実在・日本語の改行位置などをスクリプトで検査します。1項目でも不合格なら、その日は公開しません。
STEP5〜6：公開とログ
合格した記事だけをWordPressのREST API経由で公開し、実行ログを残します。翌朝はログを見るだけで、前日の成否がわかります。
指示はスキルファイルに集約する
無人実行では途中で質問に答えられないため、判断基準をすべてスキルファイルに書き切っておくのが前提です。そこまで用意できていれば、起動コマンドは1行で済みます。
claude -p "記事作成スキル（SKILL.md）を読み、今日の1本をキーワード選定から執筆・公開まで実行して" --permission-mode acceptEdits
つまずいたのは権限確認です。編集部も最初は「このコマンドを実行しますか？」の確認プロンプトで実行が止まり、翌朝まで気づけませんでした。許可するコマンドを設定ファイルに事前登録し、あわせて「迷ったら公開しない側に倒す」という基準をスキルファイルに書き足して解消しています。
活用事例②：記事81本の内部リンク一括監査
公開記事が増えると、内部リンクの管理は手作業で追いつかなくなります。編集部は81本の全記事を対象に、発リンクが無い記事・どこからもリンクされていない孤立記事・リンク切れの3点を、Claude Codeで定期的に一括監査しています。SEO上は孤立記事の解消が目的です。
監査は1つの指示文にまとめる
監査の指示は次の1本で足ります。ポイントは「修正はまだしない」と明記して、洗い出しと修正を分けることです。
claude -p "articles/ 配下のHTML 81本を対象に、(1)発リンクが0本の記事 (2)どこからもリンクされていない孤立記事 (3)リンク切れ の3つを一覧表にして。修正はまだしないで"
一覧が出たら、結線（リンクの追記）だけを別の指示で実行させます。監査と修正を1回の指示に詰め込むと、途中でコンテキストが膨らんで後半の精度が落ちるためです。
最初のつまずきは、81本のHTMLを全文読み込ませたことでした。コンテキストの上限に近づき、後半の記事の判定が明らかに雑になりました。現在はgrepでリンクタグの行だけを抽出させ、その結果をもとに判定へ進む手順に変えています。読み込み量を絞る具体策はClaude Codeのトークン節約術で実測つきでまとめています。
活用事例③：GSCデータからタイトル77本を一括改稿
タイトルの改稿は、Google Search Console（GSC）の実データから始めます。表示回数はあるのにクリックされていない記事を抽出し、実際に検索されているクエリの語彙でタイトルを書き直す流れです。編集部はこの方法で記事77本のタイトルを一括改稿しました。指示文は次の形にしています。
claude -p "gsc_2026-08.csv を読み、表示回数100以上・CTR1%未満のページを抽出して。各ページについて、実際に表示されているクエリの語彙を使ったタイトル案を32〜42字で1本ずつ出して"
推測でタイトルを考えるのではなく、GSCに残っている実クエリの言葉をそのまま使わせるのが要点です。検索者が打った語彙とタイトルの語彙が揃うほど、検索結果で自分ごとに見えます。
改稿は一括置換で終わらせない
つまずいたのは適用の工程です。タイトル案をスクリプトの一括置換で流し込もうとしたところ、置換対象が複数の記事にマッチして、無関係な記事まで書き換わりかけました。現在は置換前にマッチ件数が1件であることを確認させ、適用後は新旧タイトルの一覧をCSVで機械照合しています。
もう1つの反省は、タイトル案を文字数などの形式条件だけで合格にしていたことです。実クエリを1本ずつ検索して競合タイトルの型と見比べると、形式は満たしていても語彙のずれた案が残っていました。機械処理で楽になるのは下ごしらえまでで、最後は1本ずつ目で照合します。
活用事例④：経理CSVの仕分け・集計
毎月のネットバンキング明細CSVの仕分けと集計も、Claude Codeに任せています。要点は、仕分けの基準を会話のたびに伝えるのではなく、rules.mdというルールファイルに書いて渡すことです。基準がファイルにあれば、毎月同じ品質で再現できます。
仕分けルールはファイルで渡す
claude -p "rules.md の仕分けルールに従って bank_2026-08.csv の全行に勘定科目を振り、科目別の月次集計表を summary.md に書き出して。ルールで判断できない行は『要確認』にして"
つまずきは摘要欄の表記ゆれでした。同じ取引先でも全角と半角、正式名と略称が混在し、初回は誤った科目が付いた行が出ています。対策は2つで、判断に迷う行を無理に振り分けず「要確認」として残させること、そして要確認になった表記をrules.mdへ追記してルールを育てることです。翌月からは同じ表記でつまずかなくなります。手順の全文とルールファイルの実例はClaude Codeで経理CSVを自動化した手順で公開しています。
活用事例⑤：LP・サイト制作の機械QA
LP・サイト制作では、納品前の品質検査をClaude Codeで機械化しています。検査するのは、背景色と文字色のコントラスト、日本語の不自然な改行位置、要素のはみ出しの3点です。目視チェックは見落としが出るうえ、修正のたびに全ページを見直すのは現実的ではありません。
検査スクリプトごと作らせる
Claude Codeに毎回「見て確認して」と頼むのではなく、検査スクリプト自体を最初に作らせ、以後はそのスクリプトを実行させる構成にしています。AIの判定ぶれが消え、2回目からの実行はほぼ一瞬で終わるからです。最初の作成指示はこう書きます。
claude -p "このフォルダのHTML全ファイルについて、背景色と文字色の組み合わせを抽出し、コントラスト比がWCAG AA未満の箇所をファイル名と行番号つきで一覧にするPythonスクリプトを書いて、実行結果まで見せて"
つまずいたのは基準の穴です。WCAGのコントラスト基準に合格していても、淡い背景に同系色の濃い文字という読みにくい配色は素通りしました。数値基準と実際の見え方は別物です。現在は色相の近さを判定する検査を別途追加しています。Claude Codeが作るデザインのぶれ全般への対策はClaude CodeのLPが毎回ブレる原因とAI感を消す型にまとめました。
活用事例⑥：Playwrightによるブラウザ自動操作とスクショ
実機確認のスクリーンショット撮影は、ブラウザ自動操作ライブラリのPlaywrightと組み合わせています。修正のたびにスマホ・タブレット・PCの3つの画面幅で開いて撮る作業は、典型的な繰り返し作業だからです。スクリプトを書くのもClaude Code自身です。
claude -p "Playwrightで対象のLPを幅390/768/1280の3パターンで開き、フルページのスクリーンショットを shots/ に保存するスクリプトを書いて、そのまま実行して。撮った画像は開かなくていい"
スクショは撮るだけにして、画像を読ませない
つまずきはトークン消費でした。撮った画像をそのままClaude Codeに読ませて確認させると、画像はテキストよりはるかに大きくコンテキストを占有し、使用量が一気に膨らみます。現在はスクリプトがPNGをディスクに保存するだけにして、Claude Codeの文脈には画像を載せません。指示文の末尾にある「撮った画像は開かなくていい」は、そのための1文です。確認が必要なときだけ、画像を縮小してから読ませています。
活用事例⑦：cron/launchdで定期実行する無人運用
ここまでの事例を「毎日勝手に動く」状態にするのが、cronやlaunchdによる定期実行です。編集部では事例①の記事自動公開が毎日12:00のlaunchdで動いています。cronを使う場合、登録は1行で済みます。
0 12 * * * cd /Users/you/media && /usr/local/bin/claude -p "記事作成スキルで今日の1本を公開まで実行して" >> /Users/you/logs/article.log 2>&1
失敗時の挙動を最初に決める
無人運用の設計で最初に決めるべきは、成功時ではなく失敗時の挙動です。編集部は「失敗したら何もせず、ログだけ残して終了」に統一しています。中途半端に公開された記事を翌日探して直すほうが、1日休むより手間がかかるためです。
実際につまずいたのは環境変数でした。ターミナルでは動くコマンドが、cronからは動きません。cronはPATHをほとんど引き継がないため、コマンドは絶対パスで書く必要があります。上の例でclaudeをフルパスで書いているのはこのためです。macOSでの設定手順とスリープ時の注意点はClaude Codeの定期実行をcronで無人化する方法で手順どおりに追えます。
どのモデルで回すべき？事例別の使い分けと費用感
大半の事例はOpus 5から始めれば足ります。編集部の主力もOpus 5で、軽い定型処理はSonnet 5以下に振っています。数時間かかる自律作業はFable系の受け持ちで、現在の主力はFable 5、9月1日に出たFable 5.1への切り替えは検証中です。料金と役割を表に整理します。
| モデル | 料金（入力/出力・100万トークン） | 編集部での役割 |
|---|---|---|
| Opus 5 | $5 / $25 | 主力。記事生成・タイトル改稿（事例①③） |
| Sonnet 5 | $2 / $10 | CSV仕分け・スクリプト実行（事例④⑤⑥） |
| Haiku 4.5 | $1 / $5 | 単純な変換・整形の下請け |
| Fable 5.1 | $10 / $50 | 長時間の自律作業向け。編集部は切り替えを検証中 |
Fable 5.1はどの事例で使う？
81本の内部リンク監査のように、対象ファイルが多く、途中で人が介入できない長時間タスクに向いています。Fable 5.1は2026年9月1日に公開されたモデルで、Anthropicは「要求水準の高い推論と長時間の自律的なエージェント作業向け」と位置づけ、大半のワークロードはOpus 5から始めるよう案内しています。つまり常用するモデルではなく、Opus 5で精度が届かないときの切り札です。
Claude Codeで使うにはバージョン2.1.251以降が必要で、古いバージョンのままモデル指定するとエラーになります（claude updateで解消）。切り替えは /model コマンドか、claude -p --model claude-fable-5-1 の指定です。事例ごとのモデル選定の考え方はタスク別のClaudeモデルの選び方、Fable 5.1の仕様と移行時の注意はFable 5.1をClaude Codeで使う手順で詳しく解説しています。
3日間の実測費用
2026年9月1〜3日の編集部の使用量をccusageで集計すると、3日間の合計はAPI換算で1,801ドル相当でした。定額のMaxプランの上限内で運用しているため実支払いがこの額になるわけではありませんが、同じ量を従量APIで回すのは現実的でない規模です。内訳で目立つのはキャッシュで、9月2日は入力側の97%超がキャッシュ読み込みでした。Fable 5.1でキャッシュ読み取り単価が100万トークンあたり1.00ドルから0.25ドルへ下がったことは、この構成の費用に直接跳ね返ります。
Claude Codeの活用事例でよくある質問
Claude Codeの活用事例は非エンジニアでも再現できる？
再現できます。7事例のうち経理CSV・タイトル改稿・記事生成は、日本語の指示文だけで始められます。スクリプトが必要な場面でも、事例⑤のようにClaude Code自身に書かせれば足ります。ただし、インストールと権限設定の初期構築だけは最初に一度必要です。
Claude Codeの活用に費用はどのくらいかかる？
使い方次第ですが、毎日回すなら定額プランが前提です。編集部は定額のMaxプランで運用し、3日間でAPI換算1,801ドル相当の処理を上限内で回しています。まず1事例だけ試す段階なら、下位の定額プランで小さく始めて使用量を見るのが安全です。
無人実行で暴走や誤公開は起きない？
起きる前提で設計します。書き込めるフォルダを限定し、公開前に機械検査を挟み、不合格なら何もせずログだけ残す構成にすれば、失敗の影響は「その日の1本が出ない」までに収まります。取り返しのつかない操作を無人フローに入れないことが大前提です。
最初の1事例は何から始めるべき？
毎回同じ手順で終わるファイル処理が最適です。CSVの集計、表記ゆれのチェック、ファイル名の一括整理など、失敗してもやり直せる作業から始めます。いきなり定期実行にせず、まず手動で3回やらせて手順を固めてからが確実です。
ChatGPTやCursorとの違いは？
Claude Codeはターミナルで動き、ファイル操作・コマンド実行・定期実行との組み合わせまで1つで完結する点が違いです。エディタでのコード編集が主目的ならCursorが競合しますが、ChatGPTは会話画面が中心のため、cronで毎日無人実行するような運用には向きません。
まとめ：Claude Codeの活用は「1タスクの無人化」から始める
Claude Codeを本格導入するかどうかは、「ファイルを読んで、判断して、書き出す繰り返し作業が自分の業務に何件あるか」で決まります。1件でもあれば導入する価値があります。進め方は、まず手動で3回Claude Codeにやらせて手順を固め、判断基準をファイルに書き出し、最後に定期実行へ載せる順番が確実です。定期実行の設定手順はClaude Codeの定期実行をcronで無人化する方法、モデル選びの基準はタスク別のClaudeモデルの選び方で解説しています。
- 出典: Anthropic「Claude Fable and Mythos 5.1」発表ページ
- 出典: Claude Platform Docs「Fable 5.1 overview」
- 出典: Claude Platform Docs「Models overview」（各モデル料金）
- 費用・運用の数値: 編集部のccusage集計（2026年9月1〜3日）と実運用ログによる実測