1. Claude Opus 4.8は4.7の正常進化。料金は$5/$25のまま据え置き。Fast modeが前世代比3倍安く、バグ見逃しは4.7の約1/4に。新しいeffort制御で「速さとコスト」を自分で握れるようになった。

新しいモデルが出るたびに気になるのは「で、副業の財布にいくら響くの？」だと思う。結論から言うと、Claude Opus 4.8は値上げなしの性能アップ。2026年5月28日にAnthropicが公開し、API料金は$5/$25（入力/出力・100万トークンあたり）で4.7から据え置きのまま、ベンチマークと正確さが上がった。SE歴20年でClaude Code Max枠を毎日回している筆者の視点で、副業・フリーランスに効くポイントだけ抜き出して整理する。

ムラサキ

正直、新モデル＝値上げを身構えてたんですが、今回は据え置き。日々トークンを溶かしている側としては、これだけで十分ありがたいニュースです。

Claude Opus 4.8とは？Opus 4.7から何が変わったか

Opus 4.8は、ゼロから作り直した新世代ではなく、4.7を土台にした品質向上版という位置づけ。Anthropicの発表記事「Introducing Claude Opus 4.8」でも、コーディング・エージェント・推論・実務タスクのベンチマーク全般で4.7を上回ったと説明している。前提として、Opus 4.7時点の副業での立ち位置はOpus 4.7発表時の使い分け基準に整理済みなので、4.7を触っていた人はそこからの差分で読むと早い。

主な改善点：価格据え置きで性能・正確さが向上

押さえるべき変更は3つだけ。料金が$5/$25で据え置き、Fast modeが前世代比3倍安く、そして「コードの欠陥を見逃さず指摘する」正確さが4.7の約4倍に上がった。Anthropicは後者を「honesty（誠実さ）」の改善と表現していて、根拠の薄いまま『できました』と言い切る傾向が減ったとしている。

加えてデフォルトの思考量（effort）がxhighからhighへ下がった。これは性能ダウンではない。公式によると、4.8のhighはコーディングで4.7のデフォルトとほぼ同じトークン量で、スコアはむしろ上というチューニングが効いている。同じ働きをより少ない手数で、というのが今回の地味だが効く進化。

ベンチマークで見るOpus 4.8の実力（GPT-5.5との比較）

GPT-5.5との比較で見ると、Opus 4.8は得意・不得意がはっきり分かれる。発表記事とSystem Cardの数値を主要軸だけ並べると、こうなる。

ブラウザ・PC操作と知識労働ではGPT-5.5を上回る一方、コマンドライン主体のTerminal-Bench 2.1ではGPT-5.5に一歩譲る。ここは隠さず書いておきたい正直な弱点。なお各ベンチは評価ハーネスの違いで数値が動くので、厳密な検証はClaude Opus 4.8 System Cardで確認するのが確実。副業用途なら、ターミナル一発勝負よりもエージェント的に手順を回す場面が多いはずで、その意味では4.8の伸びは噛み合っている。

副業・フリーランスがOpus 4.8で得られる3つのメリット

数字に落とすと、副業規模でも効く変化が見えてくる。

追加コストゼロのアップグレード：/は変わらない

フロンティアモデルの更新で値上げしないのは、AI業界ではむしろ珍しい。Opus 4.8の通常料金は入力$5・出力$25（100万トークンあたり）で、4.7とまったく同じ。すでにOpusのコストで回している人は、財布の前提を変えずに性能だけ受け取れる。乗り換え判断で「値上げ分が見合うか」を計算しなくていい–この時間の節約こそ、地味だが大きい。

Fast modeが3倍安く：APIコスト削減の具体計算

Fast modeは「速度のための上乗せ料金」で、Opus 4.8では入力$10・出力$50。標準の2倍だが、前世代のFast（Opus 4.6時代は$30/$150）と比べると、ちょうど3分の1に下がった。

副業規模で試算してみる。1回あたり入力20万＋出力10万トークンの処理を、月100回回す前提だと、こうなる（公式料金からの筆者試算）。

• 標準（Fast不使用）：1回 約$3.5 → 月 約$350
• 新Fast（4.8）：1回 約$7 → 月 約$700
• 旧Fast（前世代）：1回 約$21 → 月 約$2,100

ここで早とちりしないでほしい。速度が要らないなら標準が最安。Fastの値打ちは、待ち時間が成果に直結する処理を「現実的なコストで速くできる」点にある。前世代だと月2,100ドル相当で手が出なかったFast運用が、700ドル前後まで降りてきた。対話的なセッションや、レビューを何往復もする作業でこそ効く。

バグ見逃しが4倍少ない：コーディング副業での実用価値

副業でコードを書く人に一番効くのが、この正確さの改善。Anthropicの評価では、Opus 4.8は自分が書いたコードの欠陥を見逃さず指摘する確率が4.7の約4倍に上がった。AIが『動きます』と言ったコードが実は壊れていた、というあの手戻りが減る方向の変化だ。レビュー工数を外注している感覚の個人開発者にとって、これは単価以上の価値になりうる。

実際にAIごとのバグ検出力がどれだけ違うかは、実バグ6本でのレビュー精度の差を測った検証で具体的な差が出ている。モデル選びの判断材料として合わせて見ると、4.8の伸びの意味がつかみやすい。

新機能「effort制御」を副業ワークフローに組み込む

今回の隠れた主役は、モデルそのものより「effort制御」かもしれない。

effortレベル別の使い分けガイド（low/medium/high/extra/max）

effortは、Claudeがどれだけ深く考えるかを自分で回せるダイヤル。公式ドキュメント「Effort（Claude API Docs）」によると、レベルはlow・medium・high（既定）・extra・maxの5段階。highより上は思考頻度と深さが増し、下げるとレスポンスが速くなりレート消費も穏やかになる。Claude Codeでは extra が「xhigh」という名前で出てくる点だけ覚えておけばいい。

この制御は、月額のClaude Proから最上位のMaxまで全プランで使え、追加料金もかからない。claude.aiとCoworkではモデルセレクタの隣に並ぶので、画面からそのまま切り替えられる。

API側でも同じ発想で指定する。

# Messages API で effort を指定するイメージ
message = client.messages.create(
    model="claude-opus-4-8",
    effort="high",   # low / medium / high(既定) / extra / max
    max_tokens=64000,
    messages=[...],
)

extra や max を使うときは、思考に必要なトークン余地を確保するため max_tokens を大きめ（公式の目安は64,000から調整）に取るのがコツ。

週末起業家が毎日使うタスク別のeffort設定例

「全部highでいい」と思いがちだけど、副業のタスクは難易度がバラバラ。手元の作業を雑に振り分けると、こんな具合になる（筆者の運用方針）。

ポイントは「難所だけ上げる」。Claude Codeはeffortを上げた分のトークン増を見込んでレート上限が引き上げられているので、難しいタスクで遠慮なくextraを使い、軽い作業はlowに落として温存する–このメリハリが、月末のレート切れを防ぐ一番効く運用になる。

ムラサキ

個人的に一番うれしいのが、軽い作業をlowに落とせること。SNS文の量産でレートを食いつぶす、みたいな事故が減りそうです。

SonnetとOpus 4.8、どちらを使うべきか？

「とりあえずOpus」を卒業すると、コストはぐっと締まる。

コスト比較：Opus vs Sonnetの価格差と費用対効果

料金はSonnet 4.6が$3/$15、Opus 4.8が$5/$25。入力で1.67倍、出力で1.67倍の差だ。ブログ自動化のような月間ワークロード（入力500万＋出力200万トークン）で並べると、Sonnetが月$45、Opusが月$75で、差は月$30前後（筆者試算）。

この差を「Opus一択」で毎回払う必要はない。日常の実装や定型処理はSonnetで回し、設計や難所だけOpusに投げる–この発想を具体化したのがOpus・Sonnet・Haikuでコストを半減する3層の組み方で、モデル単価の差をそのまま月額の差に直結させない設計の実例として読める。

副業タスク別の使い分け判断フロー

迷ったときの分岐はシンプルにできる。

graph TD
  A["タスクを確認"] --> B{"難所・設計判断あり?"}
  B -->|"はい"| C["Opus 4.8"]
  B -->|"いいえ"| D{"長文脈の横断理解?"}
  D -->|"はい"| C
  D -->|"いいえ"| E["Sonnet 4.6"]
  C --> F{"待ち時間が重要?"}
  F -->|"はい"| G["Fast mode併用"]
  F -->|"いいえ"| H["標準で実行"]
  classDef opus fill:#dde8f5,stroke:#9bb4d4;
  classDef sonnet fill:#e3f0e3,stroke:#a9cba9;
  class C,G,H opus;
  class E sonnet;

設計判断や長文脈の横断理解が要るならOpus 4.8、そうでなければSonnet 4.6。Opusに振った中でも、待ち時間が成果に効くならFastを足す。この3問だけで、コストと品質のバランスはだいたい収まる。

注意点：Opus 4.8で変わらないこと・制限事項

良い話ばかりではない。先に知っておくと損しない2点。

Dynamic WorkflowsはClaude Code Enterprise/Team/Maxで利用可

同時公開された「Dynamic Workflows」は、Claude Codeが数百の並列サブエージェントを走らせ、出力を検証してから報告する大規模タスク向けの機能（研究プレビュー、Claude Code v2.1.154以降）。利用は全有料プランが対象で、Max・Teamは既定でオン、ProとEnterpriseは有効化が必要（Proは/config、Enterpriseは管理者設定）。実際に副業で走らせた手触りは別記事にまとめる予定。

高effort設定でのトークン消費量に注意

effortは便利だが、上げれば上げるほどトークンを食う。extraやmaxは思考も手数も増えるぶん、同じタスクでも消費が膨らむ。Claude Code側はレート上限が引き上げられているとはいえ、APIで従量課金している場合は青天井になりうる。「難所だけ上げる」を徹底し、走らせっぱなしの自動化ではmaxを安易に常用しないのが安全。Opusのトークナイザは入力に対して生成トークンが増えやすい特性もあるので、移行前に自分のワークロードで概算しておくと事故が減る。

よくある質問

まとめ

Opus 4.8は派手な新世代ではなく、副業の現場にじわっと効くアップデートだった。要点は3つ。

1. 料金は$5/$25で据え置き。値上げ分の計算なしに性能だけ受け取れる。
2. Fast modeが前世代比3倍安く、バグ見逃しは4.7の約1/4。速さと正確さの両方が現実的なコストに降りてきた。
3. effort制御で「難所だけ深く、軽作業は速く」を自分で握れる。Sonnetとの使い分けと合わせれば、月のAIコストはまだ削れる。

まずは普段のタスクをlow/high/extraにざっくり振り分けて、1週間レート消費を眺めてみるところから。自分のワークロードの「どこにコストが乗っているか」が見えると、Opus 4.8の据え置き料金とeffort制御は一気に武器になる。

ムラサキ

据え置きでこの伸び幅なら、乗り換えで悩む理由はほぼなし。あとは自分の作業をどうeffortに割り振るか、ですね。

SE歴20年の筆者が、2026年3月14日〜4月13日の30日間を数字と経緯で記録した。GA4は取得できず、Search Consoleのデータで検証すると、検索クリック数は4倍に増加。平均掲載順位は19.5から8.4へ上昇した。出費は27,593円に対して収益は0円。うまくいかない月の実例を公開する。

ムラサキ

1ヶ月目は仕組みを作る月。2ヶ月目は仕組みが壊れる月。その最中も、サイト自体は確実に育っていた。

副業ブログ2ヶ月目の全体サマリー

1ヶ月目との比較で見る変化

1ヶ月目と2ヶ月目の数字を並べる。GA4が停止していたため、2ヶ月目のPV・ユーザー数は不明。代わりにSearch Consoleのデータで検索パフォーマンスを比較する。

2ヶ月目の主な出来事を時系列で整理

GA4の計測が1ヶ月止まっていた

気づいたきっかけと推定原因

GA4の管理画面を開いたら、3月11日頃から4月11日頃までの約1ヶ月間、データがまったく記録されていなかった。1ヶ月目のレポートのグラフを見返すと、末尾がゼロに向かっていた。あの時点で気づけたはずだが、記事の公開作業に追われて見落としていた。

WordPressのプラグインまたはCocoonテーマの更新で、GA4の計測タグ設定が外れたと推定している。正確な原因は特定できていない。GA4の設定画面でデータストリームを確認し、計測タグが正しく動作していることを再確認して復旧した。

GA4だけに頼らない計測体制の重要性

GA4が停止していた期間中、Google Search Consoleは正常に動いていた。Search ConsoleはGA4とは独立した仕組みで、Googleの検索結果におけるクリック数・表示回数・掲載順位を記録している。Search Console公式ヘルプでも、サイトの検索パフォーマンスを監視する独立ツールとして紹介されている。

計測手段を1つに依存してはいけない。GA4が止まっていてもSearch Consoleのデータがあったおかげで、この記事を「データなし」で終わらせずに済んでいる。

Search Consoleで振り返る2ヶ月目の検索パフォーマンス

1ヶ月目との数値比較

1ヶ月目と2ヶ月目のSearch Consoleデータを比較した。

クリック数が4倍に増えたのに表示回数は減った。一見矛盾しているが、実は改善している。1ヶ月目は関連性の低いクエリにも表示されて999回のインプレッションがあったが、クリックは6回だけ。2ヶ月目はGoogleがサイトの内容を正確に理解し始め、的確なクエリにだけ表示するようになった。表示は減ってもクリック率が急上昇した。

上位ページの傾向

掲載順位が高い上位ページを確認した。

上位に来ているのは筆者のSE経験に基づく実体験記事だ。「SE歴20年の業務自動化術」が平均順位2.0、「不登校だった僕がSE課長になるまで」が2.6。AIツール系の記事より、筆者にしか書けないキャリア・実務系の記事のほうが検索に強い。

ムラサキ

「自分にしか書けないこと」が検索で評価される。AIで量産した記事より、20年の経験を絞り出した記事のほうが強い。数字で確認できると腑に落ちる。

2ヶ月目の出費と収益

出費の全内訳

2ヶ月目（2026年3月14日〜4月13日）の出費を項目別にまとめた。

1ヶ月目の16,266円から11,327円増えた。主因はClaude Code Max 5xへの移行。2026年4月時点でAnthropic公式の料金ページによると、Max 5xは$100/月でProの約5倍の使用量上限がある。

ツール投資の整理｜分散課金から集約へ

2ヶ月目の後半にGenspark PlusとMakeを解約し、Claude Code Maxに投資を集約した。Claude Code 1つでほぼ賄えるようになったからだ。

1ヶ月目の月額ランニングコストはサーバー880円＋Genspark 4,000円＋Make 1,706円＝6,586円。3ヶ月目以降はサーバー880円＋Claude Max 13,782円＝約14,662円になる。金額は増えたが、記事作成・コーディング・サイト構築をすべて1つのツールに統合できた。複数ツール間の移動や コンテキストスイッチの手間がなくなったのは大きい。

Pro（$20/月）からMax（$100/月）に切り替えたきっかけは、5時間あたりの使用量制限に3回ぶつかったこと。制限に達するたびに作業が中断され、週単位の制限も見えていた。Claude Codeで個人サービスを作った記事にPro→Max移行の経緯を詳しく書いている。

2ヶ月間の累計収支

2ヶ月間の累計は出費43,859円、収益0円。純損失43,859円だ。ただしAmazonアフィリエイト審査には通過済みで、Search Consoleの検索パフォーマンスは確実に改善している。回収可能かどうかは判断するには早い。最低でも半年は続けるつもりだ。

AdSense 2回目不合格ともしもAmazon承認

AdSense否認の経緯

2026年3月14日にAdSenseの2回目の審査を申請し、4月13日に不合格の通知を受けた。否認理由は1回目と同じ「有用性の低いコンテンツ」だった。AdSenseプログラムポリシーでは独自性と付加価値のあるコンテンツが求められている。申請から結果通知まで約1ヶ月かかった。

2回連続で同じ理由に落ちると「何を直せばいいのかわからない」という焦りが出る。ただし、AdSenseは否認理由を具体的に開示しない。全体の品質を上げ続けるしかない。

もしもアフィリエイトAmazon承認

2026年3月30日、もしもアフィリエイト経由のAmazonアソシエイト審査に合格した。1ヶ月目は複数回申請して落ちていたので、承認までの改善内容を整理する。

承認に至るまでにやったことは、品質基準を満たさない記事の非公開化、筆者の実体験に基づく記事への集中、リンク切れの修正だ。特別なテクニックはない。記事の品質を上げたら通った。ただし承認後の2ヶ月目は収益が発生していない。承認はゴールではなくスタートラインだ。

審査対策としてやったこと

2ヶ月目に実施した品質改善をまとめる。

新規記事は筆者の経験や実際に試したことを書けるテーマに限定した。Claude Code系の記事が中心になったのは、この期間に筆者が実際に使い倒していたからだ。「書けるネタ」ではなく「書く資格があるネタ」を選ぶ基準に変えた。

リンク切れのチェックにはWordPressプラグインのBroken Link Checkerを導入した。5件のリンク切れが見つかり、修正した。内訳は記事作成時に手動編集が必要だった外部リンクと、非公開にした記事への内部リンクだ。Googleのリンクに関するガイドラインではクロール可能なリンクの重要性が説明されており、リンク切れはサイト品質に影響する。

Xアカウント凍結とSNS流入の喪失

凍結の経緯と原因の推定

4月13日、Xアカウントが凍結された。誤った投稿を何度も削除・再投稿した操作が自動検知に引っかかったのが原因だと考えられる。Buffer経由で構築していたWordPress→X自動投稿は機能停止した。

凍結アカウントの復旧は難しいため、新規アカウントで再スタートする。

検索流入を主軸にする方針の再確認

1ヶ月目のGA4データではOrganic Social（SNS流入）が全体の12%を占めていた。凍結でこのチャネルはゼロになったが、2ヶ月目のSearch Consoleデータを見ると、検索経由のクリック数は6から24へと4倍に伸びている。SNS流入が途絶えてもサイトの成長は続いた。

SNSは補助的な流入経路に過ぎず、主軸は検索流入だ。新アカウントを作成しても、SNS流入に依存するサイト設計は取らない。

2ヶ月目の作業スタイルの変化

量産から品質重視へのシフト

1ヶ月目は15記事を公開した。2ヶ月目は5記事の追加にとどまり、合計20本になった。新規記事よりも既存記事のリライトと品質向上に時間を使った。新規記事はClaude Code系が中心で、筆者が実際に使い込んだ体験に基づくものだ。

AdSense審査で「有用性の低いコンテンツ」という指摘を受けた。量を出すフェーズを終え、質を固めるフェーズに切り替えた。

Claude Codeへの没頭と作業時間の増加

2ヶ月目の後半はClaude Code漬けだった。4月後半は週35時間近く作業した。1ヶ月目の月60〜80時間（週15〜20時間）から大幅に増えている。

理由は2つ。Claude Codeのリモートセッション機能でスマホから出先でも操作できるようになった。WordPressやMakeはスマホだと操作しづらいが、Claude Codeはターミナル操作なので問題ない。もう1つは単純に楽しいこと。サイト構築やパイプラインの構築をClaude Codeで進めていると、気づいたら数時間経っている。睡眠時間は削っていないが、疲労感は出始めている。「楽しい」が最大の継続エンジンだが、ペース管理は3ヶ月目の課題だ。

ムラサキ

1ヶ月目は「楽しいから続く」と書いた。2ヶ月目は「楽しすぎてブレーキが要る」に変わった。副業のはずが本業の隣で第二の仕事になりかけている。

よくある質問

まとめ｜2ヶ月目の学びと3ヶ月目の方針

副業ブログ2ヶ月目のデータと出来事をすべて公開した。要点は3つだ。

3ヶ月目の方針は3つ。AdSense審査の合格、収益の初発生（100円でもいい）、YouTube・noteなどSNS以外の多角化の検討だ。Xの新アカウントは作成するが、SNS流入に依存する設計にはしない。検索で読まれる記事を軸に据える。

1ヶ月目の全データは副業ブログ1ヶ月目のリアル収支レポートで公開している。Claudeを使った記事作成の具体的な手順はClaudeでブログ記事を作成する実践ワークフローを参照してほしい。3ヶ月目も同じ形式でデータを公開予定だ。

ムラサキ

壊れたり止まったりした2ヶ月目だったけど、サイトは確実に育っている。3ヶ月目で初収益を報告できるようにする。

3ヶ月目の数字はGA4復旧後のPV1.9倍と検索流入65%にまとめた。AdSense3回目申請の1ヶ月無音問題も合わせて記録している。

2026.03.26 更新：AdSense審査不合格の回数・時点表記を事実に基づき修正、アフィリエイトマーケティング協会調査リンクを2025年版に更新、Genspark Plus料金改定の注記追加

副業でブログを始めてみたいけれど、1ヶ月目で実際にどのくらいのアクセスが来るのか、いくらかかるのか、見当がつかない。そんな不安を抱えていませんか。

この記事では、SE歴20年の会社員である筆者が、2026年2月12日に副業ブログを開設してから1ヶ月間（〜3月13日）のPV・ユーザー数・収益・出費・作業時間をすべて数字で公開します。結論を先に言うと、収益は0円、出費は16,266円、PVは200です。AdSenseは2回落ちて3回目の審査中です。「こんなものか」と安心する材料にしてください。

ムラサキ

数字は全部リアルデータです。盛っていません。むしろ盛りようがない結果でした。

副業ブログ1ヶ月目の全体サマリー

筆者のプロフィールとブログ開始の経緯

筆者はSE歴20年の会社員です。過去にもサイト運営の経験がありますが、構成検討や執筆、画像準備といった作業に時間を取られて続きませんでした。

2026年2月、生成AIプラットフォームのGensparkに触れたことが転機になりました。AIで記事作成の負担が減らせると感じ、副業ブログとして「週末起業ラボ」を開設しています。サーバーはXserver、テーマは無料のCocoon、記事作成にはClaude、投稿の自動化にはMakeを使っています。

1ヶ月目の数字をまとめて公開

2026年2月12日〜3月13日の30日間のデータを一覧にします。

収益ゼロに対して出費は16,266円。現時点では完全な赤字です。ここからどう変わるのか（あるいは変わらないのか）を、このまま記録し続ける予定です。

PV・ユーザー数・流入元の内訳

月間200PV・97ユーザーの現実

Google Analyticsのデータをそのまま出します。30日間の合計PVは200、ユーザー数は97でした。ユーザーあたりのページビューは2.06で、平均エンゲージメント時間は49秒です。リピーターは5人。ほとんどの人が1回見て帰っている状態です。

開設直後の1ヶ月としてはこんなものだろう、というのが正直な感想です。Xserverの公式ブログでも、ブログ開設1ヶ月目は月間数十〜数百PVが一般的と紹介されています。200PVは想定の範囲内です。

流入チャネル別の分析

Direct（直接アクセス）が76%を占めています。これは筆者自身のアクセスやブックマークからの訪問が大半と考えられます。GA4ではフィルタ設定でIPアドレスを除外できますが、筆者はリモートワークと出社でIPが変わるため完全な除外はできていません。

Organic Search（検索流入）は9%の9ユーザーです。開設1ヶ月のサイトがGoogleにインデックスされるまでには時間がかかります。Google検索の仕組みに関する公式ドキュメントでも、新しいページがクロール・インデックスされるまでにはタイムラグがあると説明されています。9ユーザーでも検索から来ている事実があるだけ上出来です。

Organic Social（SNS流入）は12%。Xへの投稿経由のアクセスです。記事公開時にMakeとBuffer経由でXに自動投稿する仕組みを組んでいるため、完全にゼロにはなりません。

記事別PVランキング

PVが多い上位5ページは以下のとおりです。

PVの60%がトップページに集中しています。個別記事への流入はまだ弱く、最も読まれている記事でも9PVです。検索からの流入が増えれば個別記事のPVが上がるはずですが、現状はSNSやダイレクトでトップページに来て回遊しているパターンが中心です。

1ヶ月目にかかった出費の全内訳

初期費用と月額費用の内訳

1ヶ月目にかかった出費を項目別にまとめます。

Xserverの10,560円は年額契約なので、月額換算すると880円です。月額ベースで考えると、サーバー880円＋Genspark 4,000円＋Make 1,706円＝月6,586円がランニングコストになります。AIツールへの課金がなければ月額880円で済む計算です。

Genspark Plusへの課金は記事作成の効率化が目的です。AIチャットや画像生成が無制限で使えるため、複数のAIサービスに個別課金するより安く済んでいます。上記月額4,000円は2026年2月時点の料金（$24.99/月）です。2026年3月以降にプラン改定（$49.99/月・クレジット21,000/月への変更）が報告されているため、最新料金はGenspark有料版の詳細レビューを確認してください。

出費に対するリターンの考え方

収益0円に対して出費16,266円。純粋な損益で見れば完全な赤字です。ただし初月の出費はサーバーの年額契約が大部分を占めており、来月以降は月6,586円のランニングコストだけになります。

この出費を「回収できる見込みがあるか」と聞かれたら、正直わかりません。ただ、AdSense審査に合格して広告収益が発生すれば、月数百円〜数千円の回収は現実的です。1ヶ月目の時点で「無理だ」と判断する根拠もありません。少なくとも6ヶ月は続けて、データが十分に揃ってから判断するつもりです。

作業時間の記録と1記事あたりの所要時間

平日と休日の作業時間配分

1ヶ月間の作業時間の実態です。厳密に計測していたわけではなく、体感ベースの概算になります。

月合計で概算60〜80時間程度です。15記事を公開しているので、1記事あたり4〜5時間の計算になります。ただしこの中にはサイトの初期構築やMakeの自動投稿設定など「記事を書く以外の作業」も含まれています。純粋な記事作成だけなら1記事あたり2〜3時間です。

ムラサキ

最初の1ヶ月は楽しいから時間があればあるだけやっちゃうんですよね。問題は2ヶ月目以降に同じペースを維持できるかどうか。

AI活用による時短効果の実感

記事の下書き生成にはClaudeを使い、スプレッドシートからWordPressへの投稿はMakeで自動化しています。この仕組みがなければ、15記事を1ヶ月で公開するのは難しかったと思います。

ただしAIに丸投げしているわけではありません。キーワード選定、構成の最終判断、事実確認、リライトはすべて手動です。AIが苦手な部分を人間が補う分業体制で運用しています。Claudeを使った記事作成の具体的な手順はClaudeを使った記事作成ワークフローで全工程を公開しています。また、スプレッドシートからWordPressへの自動投稿の設定方法はMakeでの自動投稿の全手順で解説しています。

記事作成だけでなく、Claudeの無料版を使ったバイブコーディングで業務システムも開発しています。プログラミング未経験でも2週間で完成した全工程をバイブコーディング実践記にまとめました。

Claude Codeの機能を体系的に習得したいなら、v2.1.90から使える/powerupでアニメーションデモ付きチュートリアルを受けるのが最短だ。

AdSense・Amazon審査に落ちた経緯と対策

AdSense不合格の経緯

Google AdSenseには開設後まもなく申請し、2026年3月13日に「有用性の低いコンテンツ」を理由に不合格となりました。計測期間終了時点で、改善を行ったうえで2回目の審査を申請中です。

GoogleはAdSenseプログラムポリシーで、独自性があり付加価値のあるコンテンツを求めています。また、AI生成コンテンツに関するガイダンスでは、コンテンツの生成方法ではなく品質を重視すると明言しています。不合格の原因は「AIを使ったから」ではなく「品質基準を満たしていなかった」と筆者は判断しました。

もしもアフィリエイトAmazon審査の状況

もしもアフィリエイト経由のAmazonアソシエイト審査にも申請していますが、計測期間中（2026年3月13日時点）では合格に至っていません。もしもアフィリエイトのAmazon審査は不合格理由が開示されないため、具体的な改善点を特定しにくいのが難しいところです。

もしもアフィリエイトの利用規約には、サイト運営者が遵守すべきコンテンツの品質基準や禁止事項が定められています。AdSenseの改善と並行して、利用規約に沿った対応を進めている状況です。

審査に向けて実施した品質改善

審査不合格を受けて実施した主な改善は、品質基準に満たないと判断した記事の非公開化です。開設当初は量を重視して公開していましたが、審査フィードバックを受けて「読者にとって有用か」「独自の情報が含まれているか」を基準に記事を見直しました。

結果として、現在公開中の記事は15本に厳選しています。いずれも筆者が実際に使ったツールの体験記や、本業のスキルを活かした実践記事です。品質改善のサイクルを回しながら、再申請を繰り返す方針で進めています。

よくある質問

2ヶ月目はGA4計測の消失やXアカウント凍結など想定外の出来事が続いた。それでもSearch Consoleで検索パフォーマンスの改善が確認できている。
副業ブログ2ヶ月目の全記録

まとめ｜1ヶ月目の学びと2ヶ月目の方針

副業ブログ1ヶ月目のデータをすべて公開しました。要点を3つに整理します。

2ヶ月目の目標は、AdSense審査の合格と検索流入の比率を20%以上に引き上げることです。記事数を増やすより、既存記事のリライトとSearch Consoleのデータ分析に時間を使う予定です。2ヶ月目のデータも同じ形式で公開予定です。

ブログの収益化や集客の全体像を学びたい方には、以下の書籍が参考になります。5年以上のブログ運営から得た具体的な戦略と数字が公開されており、1ヶ月目の筆者にとっても目標設定の指針になりました。

ムラサキ

1ヶ月目は「仕組みを作る月」でした。2ヶ月目は「仕組みを回して結果を出す月」にします。

3ヶ月目の検索流入65%への主軸シフトと累計収支もシリーズで公開した。1ヶ月目時点の「想定の範囲内」がどこまで動いたかが追える。

結論から書く。料金は据え置き（入力$5/M・出力$25/M）で、高難度コーディングと長時間タスクの一貫性が明確に強化された。Opus 4.6比でベンチマーク全般が向上し、導入コストは変わらない。ただしClaude CodeでOpusを多用するとレート上限に到達しやすいため、作業フェーズに応じたSonnet/Opusの使い分けが現実的だ。

ムラサキ

この記事を書いている4月17日時点で、チャット版Claudeは既にOpus 4.7に切り替わっています。Claude Code側はトークン管理の観点からSonnet 4.6中心の運用を継続しています。

Claude Opus 4.7で何が変わったのか

Opus 4.7の位置づけを一次情報で確認する。Anthropic公式発表と公式ドキュメントの仕様表を照合しながら、Opus 4.6からの差分を押さえる。

発表内容と主要アップデートの概要

Anthropic公式発表（Introducing Claude Opus 4.7）によると、強化ポイントは4点に集約される。

• 高難度コーディング：従来は緻密な監督が必要だった難しい作業も、安心して任せられるレベルに到達
• 長時間タスクの一貫性：数時間におよぶ実行でも計画どおりに進み、出力の自己検証まで行う
• 視覚認識の高解像度化：画像をより高い解像度で扱い、技術図面や化学構造の読み取り精度が向上
• 料金据え置き：入力$5/Mトークン、出力$25/MトークンでOpus 4.6と同額

APIモデルIDはclaude-opus-4-7。Claude API・Amazon Bedrock・Google Cloud Vertex AI・Microsoft Foundryで同日提供開始となった。

Claude 4.6系からの進化ポイント

Claude 4.6系（Opus 4.6・Sonnet 4.6）とのスペック比較は次のとおり。公式ドキュメント（Models overview）から抜粋した。

注目すべきはOpus 4.7の知識カットオフが2026年1月と、Sonnet 4.6（2025年8月）より約5ヶ月新しい点だ。AIの最新動向や2026年の技術トレンドを扱う場面では、この差が調査の裏取り精度に直結する。

Opus 4.7はExtended thinking（長時間思考）を持たない代わりに、Adaptive thinking（タスクに応じた思考時間の自動調整）を備える。ユーザーが思考時間を明示指定しなくても、モデル側が難易度を判断して思考リソースを配分する設計だ。

Anthropic公式が示す位置づけ

公式ドキュメントは「複雑な推論とエージェント的コーディングに最も適した、一般提供中で最も高性能なモデル」とOpus 4.7を位置づけている。重要なのは「一般提供中（generally available）」という限定詞だ。

AnthropicはMythos Previewの一般公開に向けた段階的な安全性検証の第一弾としてOpus 4.7をリリースしたと説明している。サイバーセキュリティ関連の高リスク要求を自動検知・ブロックする安全機構が組み込まれた点も4.7の特徴だ。

コンテキスト性能の強化と実務インパクト

ここでの「コンテキスト性能」は、コンテキストウィンドウのサイズではなく長文コンテキストを扱う際の一貫性・安定性を指す。ウィンドウサイズ自体は1Mトークンで4.6から変わっていない。

長文処理・ドキュメント解析の精度向上

公式発表に掲載された早期アクセステスターのコメントで注目すべきは、研究エージェント用途での評価だ。「6モジュール横断で総合スコアが同率1位、長文コンテキストでの一貫性はテストしたどのモデルより安定」という評価がApplied AI社から出ている。

筆者自身も、Opus 4.6時代に大量の既存記事を読み込ませて内部リンク候補を洗い出す処理で、指示の取りこぼしを経験したことがある。発生位置が文章のどこかまでは計測していないが、長いインプットを扱う処理では取りこぼしが起きうるという認識だ。Opus 4.7でこの取りこぼしがどう変わるかは、今後の運用で比較していく。

コード全体を横断した理解力の違い

CursorのCEOマイケル・トルーエル氏は、社内ベンチマーク「CursorBench」でOpus 4.7が70%を突破（Opus 4.6は58%）と公開している。12%の差は、単一ファイル編集では見えにくく、複数ファイルにまたがる依存関係の把握で現れる差だ。

副業開発でこの恩恵が出るのは、モノレポ構成の複数サイト横断修正・WordPressテーマ改修と管理スクリプトの連動修正といった場面。単機能のスクリプトや1ファイル内のバグ修正なら、Sonnet 4.6で十分捌ける範疇だ。

副業開発で効く具体的なシーン

筆者がOpus系の「長文一貫性」を必要とする場面を具体的に挙げる。

推論性能アップがもたらす開発体験の変化

推論性能の向上は、ベンチマークの数字より使用者が感じる体験の変化として現れる。公式発表の早期アクセステスターコメントから傾向を拾う。

この安定性を、完了条件を満たすまでの自走として引き出すのが/goalだ。条件を満たすまでAIを走らせる仕組みで、実際の動作フローと前提条件を解説している。 ──────────────────────────── 備考 ──────────────────────────── – 本文修正（A〜F）: 該当する重大な陳腐化・矛盾は確認されませんでした。/goalは既存記事と異なる新規キーワード（完了駆動の自走）のため、カニバリゼーションリスクは低と判断。 – 種別G（アフィリエイトリンク）: 今回は書籍候補なし（ヒアリングQ5）のため提案なし。 – 内部リンクは1既存記事につき最大1本・計4本。すべてstructure_index.mdでH2見出しの完全一致を確認済み。“`

複雑なタスク分解と計画立案の精度

公式発表冒頭の「計画フェーズで自分の論理的欠陥を捕捉する」という記述は、エージェント運用で実務的な意味を持つ。プラン→実行→検証のループで、プランの段階でミスを見つけるか実行後に発覚するかは、消費トークンに直結するからだ。

Hex社のCTOは「low-effortのOpus 4.7がmedium-effortのOpus 4.6とほぼ同等」と評価している。同じ精度を出すための思考リソースが減ったということは、Adaptive thinkingのタスク難易度判定が効率化されたと読める。

エージェント的ワークフローでの安定性

Notion AI LeadのSarah Sachs氏は、「Opus 4.6比で14%の成果向上かつ消費トークンは減少、ツールエラーが3分の1」と公開している。ツールコール失敗後のリカバリ能力も強化されており、従来はそこで詰まっていたワークフローが完走するようになった。

副業開発の文脈でこれが刺さるのは、RSS収集→AI評価→Slack通知→記事生成→WordPress投稿のような多段パイプライン構築時だ。途中1ステップで止まると復旧コストが跳ね上がる構造なので、エラー耐性の差はそのまま運用負荷に直結する。

既存モデル（Sonnet/Haiku）との使い分け

Claude 4.7世代はOpusのみの提供で、Sonnet・Haikuは4.6/4.5が現行最新だ。つまり使い分けの土台は「Opus 4.7 × Sonnet 4.6 × Haiku 4.5」の3モデル構成になる。

• Haiku 4.5：$1/$5。定型的な整形・分類・短文生成。200kコンテキスト
• Sonnet 4.6：$3/$15。日常的なコーディング・記事執筆・Extended thinking対応
• Opus 4.7：$5/$25。高難度コーディング・長文横断推論・エージェント運用の要所

価格差は小さく見えるが、出力はOpusがSonnetの約1.67倍。副業開発で数万トークン単位の処理を繰り返すと、月末請求で効いてくる差だ。

副業・個人開発で活かすユースケース

Opus 4.7を副業開発で活かすには、コストに見合う場面を絞る。筆者が実践しているフローから3つ紹介する。

SEOコンテンツ制作の品質向上

2026年4月17日にはOpus 4.7を基盤とするClaude Designがリリースされ、プロトタイプ・LP・スライドの初稿生成に活用できるようになった。実測の挙動と使いどころはClaude DesignでLPを生成した実測レポートにまとめている。

記事制作のフェーズによってSonnetとOpusを使い分けている。パイプライン経由で新規ネタを見つけて検討内容の概要をまとめるまではSonnet（API）。骨子作成から本文執筆は非API（チャット版Claude）でOpusを使う。筆者発信のネタで記事を作成する場合は、最初からOpusで進めるフローだ。

このフローで効くのが、Opus 4.7の長文一貫性強化だ。骨子作成から本文執筆までを1つのチャットで進めると、文脈が数万トークンに達する。後半で骨子の指示が効かなくなると、本文の構造がブレる。Opus 4.7でこの部分がどう安定するかは今後の運用で見ていく。

詳しいワークフローはClaude記事制作ワークフローの全記録にまとめている。

Claude Codeを使った自動化パイプライン

Claude CodeはMax 5xプランでもセッション単位のレート制限がかかる。筆者はPro時代に5時間上限を3回踏んだ経験があり、Max移行後もClaude Code上ではSonnet中心で運用している。Opus 4.7リリース後もこの方針は変わらない。

ただし、モノレポ複数サイト横断の大規模リファクタや新規機能のアーキテクチャ設計フェーズでは、レート制限を承知の上でOpus 4.7を一時的に使う判断はあり得る。Claude Code上で起きた困りどころはClaude Code個人開発の正直な話で詳述している。

リサーチ・企画・分析の時短術

Web検索＋長文ドキュメント要約＋競合分析を1チャットで完結させるリサーチ業務は、Opus 4.7との相性が良い。4.7の知識カットオフが2026年1月まで伸びたため、2025年末〜2026年初頭の技術動向を追う際、Web検索に頼る頻度が下がる。これは副業開発の企画フェーズで、裏取り工数そのものを削る効果を持つ。

コストとモデル選択の最適解

個人が無理なくOpus 4.7を使うには、消費ペースの感覚値を持っておく必要がある。

モデル選択と並行して効くのが、トークン消費の少ない外部記憶を持たせる設計だ。トークン消費ゼロで知識を蓄積するナレッジベース構築例では、MCP不使用・hookベースでの実装パターンを紹介している。

この料金感はOpus 4.7時点のもので、後継のOpus 4.8は同じ$5/$25のまま正確さとFast modeのコストが改善している。最新版での価格据え置きでの変更点と副業での使い方を踏まえると、乗り換え判断がはっきりする。

Opus 4.7の料金感と消費スピード

入力$5/M・出力$25/M。日本円換算で、入力1Mトークンが約760円・出力1Mトークンが約3,800円（2026年4月17日時点の為替約152円/ドル換算。レートは変動する）。

Claude Max 5xプラン（月200ドル・約30,400円）は、従量課金での予想請求額がこの金額を超える使い方をする場合に、固定料金でレート上限と引き換えに安定利用できる選択肢だ（Anthropic公式料金ページ）。

用途別にSonnet・Opusを使い分ける

筆者の実運用では、作業フェーズでSonnetとOpusを明確に切り分けている。

ポイントは「API経由で自動処理する工程はSonnet、人間が介在しながらじっくり作る工程はOpus」という分け方だ。自動化処理はコストが積み上がりやすいのでSonnetで抑え、人間が一緒に考えるフェーズは品質を優先してOpusを選ぶ。

個人が無理なく使うための運用ルール

Claude Code Maxプランなら月額固定でレート制限と引き換えに使える。API直接利用なら従量課金で制御できる。筆者はコスト確認をClaudeの設定画面から使用料を見る形で行っている。複雑なコマンド運用を入れずに、ダッシュボードで月次の消費を把握する方法だ。

個人の副業開発で重要なのは、自分が続けられる最もシンプルな方法を選ぶこと。高度な追跡ツールを導入しても運用できなければ意味がない。

ただしモデル性能が上がってもプロンプト側の肥大化が原因の破綻は解決しない。888行プロンプトで起きた破綻事例と設計原則も併せて押さえておきたい。

モデルを正しく振り分けるだけでなく、Prompt Cacheやコンテキスト管理まで踏み込めば削減幅はさらに広がります。実測値ベースの手順は3層スタック実践でコストを半減させる方法にまとめました。

個人運用のノウハウが固まったあと、社内展開を考えるならChatGPT・Claude・Geminiの開発業務向けプラン選定ガイドで3社のエンタープライズ構造を比較しておくと、提案の解像度が上がる。

まとめ：いつOpus 4.7に切り替えるべきか

なお本記事はOpus 4.7世代での使い分け基準をまとめたもので、2026年5月28日に後継のOpus 4.8が公開された。料金据え置きでの性能向上やeffort制御の追加といった最新の変更点は、価格据え置きで何が変わったかの整理で確認できる。

Opus 4.7への切り替え判断は、現在のモデル利用状況によって大きく分かれる。

乗り換え推奨ケースと様子見ケース

推奨ケース

様子見ケース

今日から試せる導入ステップ

Opus 4.7を試す最小コストのルートはチャット版（Claude.ai）だ。Pro以上のプランならモデル選択でOpus 4.7が選べる。API経由で試したい場合は、既存コードのモデルIDをclaude-opus-4-7に差し替えるだけで済む。

まず1つ、自分が「4.6で詰まった」タスクを手元で覚えているはずだ。そのタスクを4.7で再実行して、解けるか・消費トークンが減ったかを比較する。これが一番確実な評価方法になる。

よくある質問

まとめ

Claude Opus 4.7は「料金据え置きで性能向上」という副業開発者にとって歓迎すべきリリースだ。切り替え判断は自分の作業フェーズとコスト感から決めればよい。筆者のようにパイプライン経由はSonnet・手動作業はOpusという分け方は、一つの実運用例として参考にしてほしい。

4.6と4.7の体感差を正確に知るには、自分が4.6で詰まったタスクで比較検証するのが一番早い。

2026.03.20 更新：X APIの料金体系（Freeプラン廃止・Pay-per-use移行）を最新情報に更新し、代替手段の比較表を追加しました。

「MakeでWordPressからXに自動投稿していたのに、急に動かなくなった」——2025年5月末、多くの副業ブロガーがこの問題に直面しました。原因はMakeによるX（旧Twitter）モジュールの公式廃止です。

この記事では、Makeの Xモジュールが廃止された背景と、その後も自動投稿を続けるための代替手段3つを比較します。筆者自身が実際に運用している WordPress → Make → Buffer → X のワークフローも公開します。

MakeのXモジュールが使えなくなった経緯

まず、なぜMakeからXモジュールが消えたのかを整理します。知っている方は次のセクションまで読み飛ばしてください。

廃止の理由はX APIの料金改定

2025年4月3日、MakeはX（旧Twitter）アプリ連携の廃止を正式に発表しました。理由は「X APIのポリシー要件と料金体系により、顧客に妥当な連携を提供し続けることが困難になったため」です。

背景にはXのAPI料金の大幅な値上げがあります。Makeのような連携プラットフォームがXのAPIを利用するには、Enterprise tier（月額$42,000〜、約630万円〜）の契約が必要とされました。MakeのコミュニティユーザーがAPIを利用する総量を考えると、この費用を吸収することは現実的ではありません。

同様の理由で、ZapierもX連携を縮小しています。これはMakeだけの問題ではなく、自動化プラットフォーム全体に影響した出来事です。

影響範囲と時系列まとめ

廃止までの流れを時系列で整理します。

2025年4月3日：Makeが廃止を発表。この日以降、新規シナリオでXモジュールの追加が不可に。
2025年5月30日：既存シナリオのXモジュールも完全に動作停止。
2025年5月以降：Xモジュールを含むシナリオは実行時にエラーで失敗するように。

X APIの料金体系【2026年3月最新】

代替手段を選ぶ前に、X APIの現在の料金体系を把握しておきましょう。2026年2月に料金体系が大きく変わり、旧プラン（Free / Basic / Pro）は廃止されています。特にHTTPモジュールで直接連携する場合やn8nを使う場合は、自分のX APIアカウントの料金が直接関係します。

廃止された旧プラン（Free / Basic / Pro）

2025年までのX APIは固定料金のティア制でした。Free（$0・月500投稿まで書き込み専用）、Basic（$200/月）、Pro（$5,000/月）、Enterprise（$42,000〜/月）の4段階です。しかし2026年2月にFree・Basic・Proの3プランは廃止（deprecated）され、新規登録ができなくなりました。旧Basic/Proの既存ユーザーは当面利用可能ですが、XはPay-per-useへの移行を推奨しています。

旧Freeプランを利用していた開発者には、一回限りの$10バウチャーが付与された上でPay-per-useに自動移行されています。「Freeプランで月500投稿」という情報は2026年3月時点では古い情報ですので注意してください。

現在の料金体系：Pay-per-useモデル

2026年2月、XはPay-per-use（従量課金）モデルを正式にリリースし、これが唯一の新規登録可能なプランとなりました。事前にクレジットを購入し、APIリクエストごとにクレジットが消費される仕組みです。月額固定費はありません。2026年3月時点の主要操作の単価は以下のとおりです。

同一リソースを同じUTC日内に複数回取得した場合、原則として重複課金は発生しません（ただし例外あり）。月間の投稿読み取りは200万件が上限で、それ以上はEnterprise契約（$42,000〜/月）が必要です。支出上限の設定もDeveloper Consoleから可能で、使いすぎを防止できます。料金の詳細はX API公式料金ページで確認できます。

副業ブロガーの月額コスト試算

旧Freeプランは廃止されたため、2026年3月時点ではPay-per-useが唯一の選択肢です。では副業ブロガーが月30記事の自動投稿をした場合、いくらかかるでしょうか。

投稿の作成（Post create）は$0.01/件のため、月30投稿 × $0.01 = $0.30（約45円）です。Buffer経由で投稿する場合はX APIを直接叩かないため、この費用は発生しません。HTTPモジュールで直接連携する場合やn8n経由の場合のみAPI利用料がかかりますが、月額100円にも満たない水準です。

ムラサキ

旧Freeプランがなくなって不安に思った方も多いと思いますが、副業ブログの投稿量なら月50円以下です。実質ほぼ無料と言って差し支えありません。

ただし投稿後のエンゲージメントデータ（いいね数、RT数など）をAPI経由で取得しようとすると、読み取り操作（$0.005/件）のコストが加算されます。分析を自動化したい場合はDeveloper Consoleで支出上限を設定し、想定外の課金を防ぎましょう。

代替手段①｜Buffer経由でX投稿（最も手軽）

MakeのXモジュール廃止後、最も手軽に自動投稿を再開できるのがBuffer経由の方法です。MakeにはBufferモジュールが標準で用意されており、追加費用なしで利用できます。

Bufferとは？無料プランでできること

BufferはSNS投稿の管理・スケジューリングツールです。無料プランでは3つのSNSチャンネルを接続でき、各チャンネルに月10件までの予約投稿が可能です。X、Instagram、Facebook、LinkedIn、Mastodon、Bluesky、Threadsなどに対応しています。

有料プランはEssentials（年払い$5/月/チャンネル、月払い$6/月/チャンネル）からで、予約投稿数の上限がなくなり、分析機能も使えるようになります。2026年3月時点の料金はBuffer公式料金ページで確認できます。副業ブログのX投稿だけなら無料プランで十分です。

MakeのBufferモジュール設定手順

MakeでBufferモジュールを設定する手順は以下の通りです。

ステップ1：Bufferアカウントを作成し、Xアカウントを接続しておく。
ステップ2：Makeのシナリオエディタで「＋」をクリックし、「Buffer」で検索。
ステップ3：「Create a Status Update」アクションを選択。
ステップ4：コネクション作成でOAuthポップアップが表示されるので、Bufferアカウントで認証。
ステップ5：投稿先のProfile（Xアカウント）を選択し、Textフィールドに投稿テキストをマッピング。

Bufferモジュールの接続にはMake側のClient IDが使われるため、Buffer側でアプリ登録をする必要はありません。OAuthで認証するだけで接続が完了します。

メリットとデメリット

メリット：設定が最も簡単（5分で完了）。X APIの開発者アカウントやAPIキーが不要。Buffer無料プランで運用可能。テキスト＋画像＋動画に対応。

デメリット：Bufferという中間サービスを挟むため、Bufferの仕様変更や障害の影響を受ける。無料プランでは月10件の予約投稿上限がある（ただしMakeから即時投稿する場合はこの制限に該当しない場合もある）。投稿のカスタマイズ性はX API直接連携より低い。

▶ Makeの基本的な使い方やシナリオの作り方はこちらの記事で解説しています。
Make副業自動化入門｜ブログ→X投稿を自動化した全手順

代替手段②｜MakeのHTTPモジュールでX APIを直接叩く

Bufferを挟まずにMakeから直接XのAPIを叩く方法もあります。技術的なハードルは上がりますが、最も自由度の高い方法です。

OAuth 2.0 PKCE認証の流れ

X APIの投稿エンドポイント（POST /2/tweets）を利用するには、OAuth 2.0 Authorization Code Flow with PKCE（Proof Key for Code Exchange）による認証が必要です。

大まかな流れは以下の通りです。

1. X Developer Portalでアプリを作成：Client IDとClient Secretを取得。
2. 認証URLを構築：Client ID、リダイレクトURI、code_challengeなどのパラメータを含むURLを生成。
3. ユーザー認可：そのURLにアクセスしてXアカウントで承認し、認可コードを取得。
4. トークン交換：認可コードをアクセストークン＋リフレッシュトークンに交換。
5. APIリクエスト：取得したアクセストークンを使って POST /2/tweets にリクエスト。
6. トークン更新：アクセストークンが期限切れになったらリフレッシュトークンで更新。

Makeの標準HTTPモジュールはOAuth 2.0に対応していますが、X APIが要求するPKCE拡張をネイティブではサポートしていません。そのため、code_verifierとcode_challengeのSHA-256ハッシュ生成を手動で行うか、専用のヘルパーツール（GitHubで公開されているMake用OAuth PKCE Wizardなど）を利用する必要があります。

実装の難易度と注意点

正直に言うと、この方法の実装難易度は高いです。OAuth 2.0 PKCEの仕組みを理解した上で、Make上でData Store（トークン保管）、Webhooks（コールバック受信）、複数のHTTPモジュール（トークン取得・更新・API呼び出し）を組み合わせる必要があります。

メリットとデメリット

メリット：中間サービスが不要で、X APIの全機能にアクセスできます。画像付き投稿、スレッド投稿、引用RTなど、Buffer経由では難しい高度な投稿形式にも対応可能です。API利用料はPay-per-useの従量課金ですが、月30投稿程度なら$0.30（約45円）で済みます。

デメリット：実装難易度が高い。OAuth 2.0 PKCEの理解が必要。トークン管理の仕組みが必要。Makeの無料プランではData Storeの容量やシナリオ数の制限に注意が必要。

代替手段③｜n8nに乗り換える

Makeにこだわらないのであれば、n8nという選択肢もあります。n8nにはXのネイティブモジュールが現在も健在で、OAuth 2.0 PKCEにもネイティブ対応しています。

n8nとは？Makeとの違い

n8nはMakeと同じノーコード/ローコードの自動化プラットフォームです。オープンソースで、セルフホスト（自分のサーバーで運用）も可能な点がMakeとの大きな違いです。クラウド版は月$20〜の有料プランですが、セルフホストなら無料で利用できます。

n8nのネイティブXモジュール

n8nのTwitter/Xモジュールでは、Client IDとClient Secretを入力するだけで接続が完了します。PKCEの処理はn8n側で自動的に行われるため、開発者がハッシュ生成やトークン管理を意識する必要がありません。

また、Makeの既存シナリオからn8nのワークフローをHTTPリクエストで呼び出すことも可能です。つまり、Make側のWordPressトリガーはそのままに、X投稿の部分だけn8nに委任するハイブリッド構成も作れます。

メリットとデメリット

メリット：ネイティブXモジュールが健在で設定が簡単。セルフホストなら無料。PKCEを自動処理してくれる。投稿・リツイート・削除など幅広いアクションに対応。

デメリット：Makeとは別のツールを覚える必要がある。セルフホストにはVPSなどのサーバーが必要。クラウド版は月$20〜の費用が発生。既存のMakeシナリオを移行する手間がかかる。

3つの代替手段比較まとめ

ここまで紹介した3つの代替手段を一覧で比較します。2026年3月時点の情報です。

副業ブロガーの大半はBuffer経由（①）で十分です。筆者も①を採用しています。

当ブログの実践例｜WordPress→Make→Buffer→Xの全体像

最後に、当ブログ（週末起業ラボ）で実際に運用しているワークフローを紹介します。

現在の構成と運用フロー

当ブログでは、代替手段①のBuffer経由を採用しています。全体の流れは以下の通りです。

WordPress（記事公開）→ Make（Watch Posts トリガー）→ Buffer（Create a Status Update）→ X に投稿

MakeもBufferも無料プランで運用しています。ただし実際には、Makeの常時ON運用ではWatch Postsトリガーのポーリングでクレジットが消費されるため、現在は必要なときだけシナリオをONにする半手動運用に落ち着いています。

カスタムフィールドで X 投稿テキストを管理する仕組み

WordPress の投稿にカスタムフィールド x_post_text（本文）と x_hashtags（ハッシュタグ）を追加し、スプレッドシートの列 M・N から Make 経由で書き込みます。X の 1 投稿上限は 280 文字（URL 23 文字換算を含む）なので、本文＋ハッシュタグ＋URL の合計が 280 文字以内に収まるようスプレッドシート側であらかじめ文字数を管理するのがポイントです。

実装の全手順（Make シナリオへのモジュール追加・WordPress テンプレート側の出力方法）は以下の記事で詳しく解説しています。

WordPress×Makeカスタムフィールド一括登録｜X投稿を自動化する実装手順

MakeのカスタムフィールドをWordPressに一括登録してX投稿を自動化する手順を、SE歴20年が実装ベースで解説。2026年3月時点の課金単位クレジットにも対応。

shumatsu-lab.com

2026.05.03

無料プランでの運用コツ（クレジット節約術）

Makeの無料プランは月1,000クレジット、アクティブシナリオ2つまでです。Watch Postsトリガーは15分間隔のポーリングで、記事がなくても1回のチェックで1クレジットを消費します。24時間×4回/時×30日＝2,880クレジット。これだけで無料枠を大幅に超えます。

対策としては、記事を公開するタイミングでのみシナリオをONにし、投稿確認後にOFFにする運用が現実的です。月に数記事の投稿頻度なら、ONにする時間を最小限にすることで無料枠内に収まります。

▶ Makeの基本操作や無料プランの活用法はこちらで解説しています。
Make副業自動化入門｜ブログ→X投稿を自動化した全手順

よくある質問

まとめ

2025年4月のMake Xモジュール廃止は、多くの副業ブロガーの自動投稿ワークフローを止めてしまいました。しかし代替手段は複数あり、特にBuffer経由の方法なら5分で設定が完了し、無料で運用を再開できます。

この記事のポイントを振り返ります。

カスタムフィールド（x_post_text / x_hashtags）の設定方法とMakeシナリオからの読み取り方はWordPressカスタムフィールドでX投稿テキストを管理する手順で詳しく解説しています。

ムラサキ

Freeプラン廃止のニュースに焦った方もいると思いますが、副業ブログの投稿量なら影響はほとんどありません。Buffer経由ならAPI料金すらゼロです。まずは動く仕組みを作って、記事を書くことに集中しましょう。

Makeの基本から知りたい方はMake副業自動化入門｜ブログ→X投稿を自動化した全手順をご覧ください。

2026.03.20 更新：文部科学省2024年度統計データの追加、FAQのブロック形式変更、タイムライン追加、外部エビデンスリンクの追加を実施しました。

中学に入って1ヶ月で学校に行けなくなった。

約1年間、家にいた。そこから少しずつ動いて、今はSE歴20年、金融系システム開発の課長をやっている。部下が10人いて、家庭もある。

文部科学省の2024年度調査によると、小・中学校の不登校児童生徒数は約35万4千人で過去最多を更新した。12年連続の増加で、中学校ではおよそ15人に1人が不登校という計算になる。自分もその「元・不登校児」の一人だ。

劇的な逆転劇ではない。ただ、いくつかの分岐点で少しだけ動いた。その話を書いてみる。

ムラサキ

20年前の自分に「課長やってるよ」と言ったら、たぶん信じないと思います。でも事実です。

小3で世界が変わった

小学3年のとき、両親が離婚した。母に連れられて田舎の実家に引っ越した。

知らない土地だった。周りに知っている人はいない。子供ながらに「ここは自分の場所ではない」と感じていた気がする。

小学校は断続的に休むことはあったが、合計すると2ヶ月くらいで、ほぼ通っていた。ただ「楽しかった」という記憶がほとんどない。なんとなくやり過ごしていた。毎日をこなしていただけだった。

振り返ると、この時期にすでに「環境が変わることへの疲弊」の種はあったのだと思う。

中学、1ヶ月で止まった

中学に入学した。また環境が変わった。

引越しもあって、周りに知り合いはほぼいない。同級生たちにはすでに小学校からの関係性がある。その中にぽんと放り込まれた。

疎外感があった。「またゼロからやるのか」という気持ちが重かった。小学校をなんとかやり過ごしてきた分、中学で完全に糸が切れた。

1ヶ月で行かなくなった。正確には、行けなくなった。

明確ないじめがあったわけではない。誰かに何かをされたわけでもない。ただ、あの教室にいることが自分にはできなかった。

不登校の1年間は意外と暇じゃなかった

学校に行かない日々が始まった。約1年間続いた。

何もしていなかったかと聞かれると、そうでもない。ゲームをやり、勉強もしていた。PCを触り、Magic The Gatheringにハマった。

「不登校＝引きこもって何もしない」というイメージを持つ人がいるかもしれないが、自分の場合はむしろ忙しかった。学校という枠がなくなった分、自分の興味に全振りできた。

親は無理に登校を促すことが一切なかった。これは今思うと大きい。

代わりに相談機関に定期的に通っていた。相談員の人と遊んだり、少し話したりする程度。カウンセリングという堅い感じではなく、ただ一定のサイクルで外に出て誰かと過ごす時間があった。

当時はなんとも思っていなかったが、今振り返るとこの距離感がちょうどよかったのだと思う。詰められず、放置もされない。その間で少しずつ息をしていた。

文部科学省は「不登校児童生徒への支援の在り方について」の通知の中で、不登校の時期が休養や自分を見つめ直す等の積極的な意味を持つことがあると明記している。当時の自分がまさにそれだったのだと、この文書を読んで腑に落ちた。

嫌いな祖母がくれた転機

転機は意外なところからやってきた。

祖母が、不登校の子供が通う施設を見つけてきた。母にそこへ行かせるよう提案した。

正直に言うと、祖母のことは好きではなかった。だからその提案も素直には受け入れられなかった。半強制的に通い始めた記憶がある。

でも結果として、この施設に通えるようになったことが自分の人生で一番大きな転機だった。中学の間に約1年かけて、そこに通えるようになった。

高校は消化試合、大学でプログラミングに出会った

高校は自宅から近い普通科に進学した。田舎なので選択肢がほぼなかった。

正直、面白くなかった。ただ通っていただけだった。唯一、数学だけは成績がよかった。

大学進学する生徒がほとんどいない高校だったが、担任の先生に「大学に行け」と勧められた。おそらく学校の進学実績を作りたかったのだと思う。理由はどうあれ、この一言がなければ大学には行っていなかった。

工学部の夜間に進学した。ここで初めて「学ぶ場所が自分に合っている」と感じた。

理由は2つある。自分でカリキュラムを組めること。そして団体行動を強制されないこと。小中高とずっと苦手だった「集団の中にいること」から解放された。

そしてプログラミングに出会った。コードを書いて、動く。自分の書いたものが画面上で結果を返してくる。これが純粋に面白かった。

学校が面白くなかったのではなく、学ぶ内容と環境が自分に合っていなかっただけだった。大学でそれに気づけたことは大きい。

就活を知らないまま社会人になった

就職活動の仕組みを正直よくわかっていないまま就職した。情報系の学部だったので、そのままSEになった。

大企業を目指すという発想がそもそもなかった。「この規模の会社なら自由にやれるだろう」「自分が活躍できるだろう」という見立てがあった。

結果的にその読みは当たっていた。20年間、同じ会社で転職せずに課長になった。部下が10人いる。金融系のクライアントを担当し、システムを作っている。

ただ今振り返れば、もっと大きな環境に挑戦してみても面白かったかもしれない。当時の自分には想像もつかなかった選択肢が、実はあったのだろうと思う。これは後悔ではなく、今だから言える感想だ。

不登校と関係あるもの、ないもの

社会人を20年やってきて、自分の特性についてはだいぶ理解が進んだ。

よく「不登校の影響で人付き合いが苦手なんでしょう」と思われるかもしれないが、自分の場合はそうではないと思っている。

不登校だったことをすべての原因にしてしまうと、自分自身を見誤る。「不登校だったから」と「もともとの自分の性格」は分けて考えた方がいい。

教育機会確保法のパンフレットでは、不登校はどの児童生徒にも起こり得るものであり、問題行動ではないと明確に位置づけている。この考え方は、不登校経験者が自分を過度に特別視しないための支えにもなるはずだ。

課長としてチームをまとめる中で、対応の仕方は経験値で学んでいった。マニュアルがあったわけではない。場数を踏んで「こういう時はこう返す」というパターンを蓄積していった。不登校経験があろうがなかろうが、社会人はみんな同じことをやっていると思う。最近は生成AIの登場でSEに求められるスキルも変わりつつあり、その変化と若手教育のアプローチについては生成AI時代に必要なスキルと若手教育の進め方で詳しく書いている。

よくある質問（FAQ）

まとめ｜不登校は「終わり」じゃなかった

ずっと不登校のままだったら、今の状態はなかったと思う。

動いたタイミングがあった。それは自発的なものだけではなく、嫌いな祖母からの半強制もあった。大学進学も先生の一言がなければなかった。自分の意思だけで切り拓いたわけではない。

でも、どちらでもいいと思う。きっかけが自発的か他発的かは問題ではない。動いた事実だけが残る。

ムラサキ

不登校の経験は「終わり」ではなかったし、「始まり」でもなかった。ただ、人生の一部だった。それをそのまま書けたことに意味があると思っています。

SE歴20年の業務自動化術｜SendTo・Selenium・AIエージェントまで

SendToフォルダの自作ツール、PowerShell、Seleniumからコードレビューエージェントまで。SE歴20年が20年かけて磨いた「自分の仕事を自分で楽にする」自動化テクニックと比較表。

shumatsu-lab.com

2026.05.02

SE歴20年の時短術｜Excel業務効率化15選

SE歴20年の筆者が実務で使うExcel時短テクニック15選。ショートカット・テーブル・PowerQuery・VBA設計思想まで網羅。

shumatsu-lab.com

2026.02.17

文部科学省2024年度統計データの追加、FAQのブロック形式変更、タイムライン追加、外部エビデンスリンクの追加を実施しました。