2026.04.04 更新：Claude Opus 4.6の100万トークン正式GA反映、アイキャッチ運用をCanvaに変更、ワークフローのフロー図追加、内部リンク配置の改善

ChatGPT、Gemini、Claude、Copilot――2026年現在、ブログ記事の作成に使える生成AIは数えきれないほど増えました。「AIを使えばブログが楽になるらしい」と聞いて調べてみたものの、どれを使えばいいのか結局わからない。そんな状態で止まっている方は多いのではないでしょうか。

この記事は、AIツールの機能比較やランキングではありません。SE歴20年・副業ブログ運営中の筆者が実際にClaudeというAIを使い、キーワード選定から下書き投稿まで全工程を回してみた実践記録です。便利だった点も困った点も隠さず書いています。AIでブログを始めたいけど最初の一歩が踏み出せない方の判断材料になれば幸いです。

AIでブログを書きたいけど何を使えばいいかわからない人へ

2026年4月時点で、ブログ記事の作成に使える主なAIだけでもChatGPT、Gemini、Claude、Copilot、Perplexityと多岐にわたります。それぞれ無料プランがあり、どれも「記事が書ける」とうたっています。選択肢が多すぎて比較記事を読んでも決められない、という状況は珍しくありません。

筆者も同じ状態でした。最終的に選んだのはClaudeですが、「Claudeが最高だから」ではなく「たまたまClaudeを使い始めて、そのまま全工程を回せた」というのが正直なところです。この記事では、そのリアルな経緯と実際の運用方法をそのままお伝えします。

筆者がClaudeを使い始めた経緯

生成AIの話題をニュースやCMで頻繁に見かけるようになり、興味本位でGenSpark（ジェンスパーク）というAIプラットフォームを触り始めたのがきっかけです。

以前にもサイト運営をしていた時期がありましたが、構成検討や執筆、画像準備といった作業に時間を取られて続きませんでした。生成AIでその負担が減らせると感じ、2026年2月にサイト運営を再開しています。今思えばこの生成AIの流れに乗るために課金する材料を集めていたような節もあります。

GenSparkのAIチャットでは複数のモデルを選択して使えます。公開ベンチマークを見比べた結果、最もスペックが高そうだったClaude Opus 4.6を選び、そのままブログ運営の全工程で使うようになりました。GenSparkの有料プラン（Plus）ではAIチャットがクレジット消費ゼロの無制限利用になるため、記事作成を頻繁に行う筆者にとってコストパフォーマンスは高く、課金判断の詳細はGenspark有料版レビューにまとめています。

Claudeはブログ記事の執筆だけでなく、コーディングでも強力です。Claude無料版を使って業務システムを2週間で開発した全工程をバイブコーディングの実践記にまとめています。

その後Claude Codeに移行してWebサービス開発まで発展した。コスト管理・暴走対策を含む個人開発の実録に続きがある。

2026年4月にはOpus 4.6の後継となるOpus 4.7が料金据え置きでリリースされた。副業開発でのSonnet/Opusの使い分け基準はOpus 4.7の副業開発での使い分けで整理している。

Claudeでブログ記事を作る具体的な手順

筆者がClaudeを使ってブログ記事を1本公開するまでの流れを紹介します。すべてAIに丸投げではなく、自分で判断する部分とAIに任せる部分を分けて運用しています。

リサーチ段階では複数のAIを組み合わせると精度が上がります。筆者は情報収集にGensparkを使っています。

ブログ記事をAI音声に変換してYouTube動画として再利用する方法もあります。ElevenLabsを使えば、書いた記事をそのまま動画ナレーションに転換できます。具体的な手順はブログ記事をAI音声でYouTube動画化する副業ワークフローで解説しています。

キーワード選定──自分の経験とAIの両方で洗い出す

キーワードは自分の経験から「これを知りたかった」という実感をベースに候補を出す場合と、Claudeに関連キーワードを洗い出してもらう場合があります。最終的にどのキーワードで書くかは自分で決めます。自分が実体験として語れるテーマかどうかが判断基準です。

記事構成・本文・HTML生成をAIに任せる

キーワードが決まったら、自分の経験や伝えたいことをClaudeにインプットし、記事構成を作ってもらいます。構成段階で内容の不整合や意図と異なる解釈がないかをチェックし、修正を指示します。

構成確定後は本文執筆からHTML化まで一気に依頼します。WordPressのCocoonテーマに対応したブロック構文で出力させるため、コピー＆ペーストで綺麗に整形された記事ができあがります。

スプレッドシートからMake経由でWordPressに自動投稿

生成されたHTMLはGoogleスプレッドシートに転記し、Make（旧Integromat）でWordPressに下書き投稿しています。タイトル、本文、スラッグ、カテゴリーなどを1行にまとめておけば、ボタンひとつで下書きが作成される仕組みです。

graph TD
    A["キーワード選定"] --> B["記事構成の作成"]
    B --> C["本文・HTML生成"]
    C --> D["スプレッドシートに転記"]
    D --> E["アイキャッチ画像作成"]
    E --> F["Google Driveに<br>アイキャッチをアップ"]
    F --> G["Make検知 →<br>アイキャッチ付きで<br>WordPress下書き投稿"]
    G --> H["プレビュー確認・編集"]
    H --> I["公開"]
    A -.- A1["自分の経験 +<br>Claudeで候補洗い出し"]
    C -.- C1["Cocoonブロック構文で<br>HTML出力"]
    E -.- E1["Canvaテンプレートで<br>統一デザイン"]
    F -.- F1["Driveアップが<br>Makeのトリガー"]
    style A fill:#e3f2fd,stroke:#90caf9
    style B fill:#e3f2fd,stroke:#90caf9
    style C fill:#e3f2fd,stroke:#90caf9
    style D fill:#fff3e0,stroke:#ffcc80
    style E fill:#fff3e0,stroke:#ffcc80
    style F fill:#fff3e0,stroke:#ffcc80
    style G fill:#e8f5e9,stroke:#a5d6a7
    style H fill:#fff3e0,stroke:#ffcc80
    style I fill:#f3e5f5,stroke:#ce93d8
    style A1 fill:#fafafa,stroke:#e0e0e0
    style C1 fill:#fafafa,stroke:#e0e0e0
    style E1 fill:#fafafa,stroke:#e0e0e0
    style F1 fill:#fafafa,stroke:#e0e0e0

青がAI支援工程、緑が自動化工程、オレンジが手動工程です。スプレッドシートに記事データを転記した後にCanvaでアイキャッチ画像を作成し、Google Driveにアップロードすると、Makeがそれを検知してアイキャッチ付きのWordPress下書き投稿を自動生成します。

Makeを使った自動投稿の全体設計に興味がある方もいるかもしれません。ブログ公開からX投稿まで自動化する具体的なシナリオ構成はMake副業自動化入門｜ブログ→X投稿を自動化した全手順で解説しています。

プレビュー確認とアイキャッチ画像の選定

下書きがWordPressに投稿されたら、プレビュー画面で表示を確認します。見出しの階層、装飾ブロックの表示崩れ、文章のつながりなどを目視でチェックし、必要に応じて手動で修正します。AIの出力をそのまま公開することはほぼありません。

アイキャッチ画像は当初GenSparkの画像生成機能で作成していましたが、文字の崩れや構図の問題があり、現在はCanvaでテンプレートベースで作成する運用に切り替えています。テンプレートにタイトルとステップ文言を流し込むだけで統一感のあるアイキャッチが完成します。AI画像生成ツールの比較と筆者が辿り着いたワークフローはAI画像生成でアイキャッチ作成｜無料5ツール比較で詳しく紹介しています。

公開後に記事間の不整合が見つかった場合は、Claudeに調査を依頼しますが、修正の反映は手動で行っています。

AIブログの書き方で感じたデメリットと対処法

便利な点が多い一方で、困ったことも正直にあります。GenSpark経由で使っているため、問題の原因がClaude側かGenSpark側か切り分けできていない部分もあります。

AIに任せると効率は上がるが、その裏で数字が捏造される事故も起きる。AIが数字を捏造した実例と防止策に、本番公開でやらかした一件をまとめた。

同じ文言の繰り返し・コンテキスト忘れ

同じフレーズが重複して出力されることがあります。原因は特定できておらず、有効な対処法も見つかっていません。都度手動で削除しています。

また、同じチャットで長く会話を続けていると、序盤に共有した情報が抜け落ちることがあります。「さっきと同じ形式で続けて」と指示しても体裁の異なる結果が返ってきます。重要な情報はプロンプトに都度再掲して対処していますが、手間は増えます。

アイキャッチ画像が1回で期待通りにならない

当初はAIに画像生成プロンプトを作らせてGenSparkで生成していましたが、文字の崩れや非現実的な構図が頻発し、1回で想定通りになることはまれでした。この問題はAI画像生成ではなくCanvaのテンプレートでアイキャッチを作成する方式に切り替えることで解決しています。AI画像生成の限界と代替ワークフローの詳細はアイキャッチ作成ツール比較記事にまとめました。

画像生成AI以外のアプローチとして、Claude DesignでHTMLベースのアイキャッチ素材を作りブラウザでスクショする手順もある。検証結果はClaude Designの実測レポートにまとめた。

対処できたこと・できていないこと

コードの出力が1行に詰め込まれて読みにくい問題は、出力ルールの再定義で改善しました。コードブロックに言語クラスを付与し、Cocoonのシンタックスハイライト機能を有効にすることで視認性が大幅に向上しています。

文言の重複やコンテキスト忘れは現時点で根本的な対処ができていません。AIですべてが自動化されるわけではなく「AIが苦手な部分を人間が補う」前提で運用するのが現実的です。この「面倒を1つずつ潰す」発想はWindows環境の業務自動化にも通じており、SE歴20年の業務自動化術でSendToカスタマイズからSeleniumまで現場のテクニックをまとめています。

よくある質問（FAQ）

Claude Codeを使った開発効率化をさらに深めたい場合は、ターミナル内チュートリアル機能の解説記事Claude Code /powerup入門も役立つ。

実際にこのワークフローでブログを2ヶ月運営した結果、ツール構成はClaude Code Maxへの集約に落ち着いた。出費と成果の推移を含む詳細データは運営報告で公開している。
副業ブログ2ヶ月目のデータ全公開

まとめ｜AIツール選びより「まず1本書く」が最短ルート

この記事では、筆者がClaudeを使ってブログ記事を作成している実際のワークフローと、使ってみて感じたメリット・デメリットを紹介しました。このワークフローで実際に1ヶ月運営した結果（PV200・収益0円・出費16,266円）は副業ブログ1ヶ月目の収支レポートで全数字を公開しています。

ポイントを振り返ると、GenSparkの無料AIチャットからClaude Opus 4.6を選び、キーワード選定から下書き投稿まで一連の工程を構築できたこと。構成チェックや画像選定など人間が介入する工程は残ること。重複出力やコンテキスト忘れなど未解決の課題もあること。この3点です。

AIツール選びで比較記事を読み続けるよりも、まず1本書いてみる方が圧倒的に早く前に進めます。合わなければ別のツールに乗り換えればいいだけです。10年前に挫折した筆者でも再開できたのは、AIが「本質ではない作業」を引き受けてくれたからでした。

2026.03.24 更新：Xの文字カウント仕様（Weighted Character Counting）の説明を修正、Makeの課金単位「クレジット」への名称変更を反映、FAQをCocoonブロック形式に変更

MakeでWordPressに記事を下書き投稿している人は多いと思います。しかし、X（旧Twitter）への投稿テキストとハッシュタグは別管理になっていませんか？

この記事では、SE歴20年・3サイトをMakeで運用している筆者が、WordPressのカスタムフィールドにX投稿用のテキスト（x_post_text）とハッシュタグ（x_hashtags）を持たせ、MakeのHTTPモジュールで記事投稿と同時に一括書き込みする仕組みを構築します。スプレッドシートにデータを入力すれば、記事本文もX投稿データもWordPressに一発で登録できるようになります。

コードはすべてコピペで実装可能です。WordPress側の準備は10分、Make側の修正は5分で完了します。まだMakeの初期設定が済んでいない方は、先にMake副業自動化入門の全手順でAPI Key取得まで完了させてください。

ムラサキ

3サイトすべてにこの仕組みを導入して1ヶ月運用しています。一度設定すれば記事投稿のたびにX投稿テキストも自動でWordPressに入るので、公開前の確認がとても楽になりました。

なぜカスタムフィールドでX投稿データを管理するのか

まず、なぜわざわざカスタムフィールドを使うのか。スプレッドシートで管理するだけではダメなのかを整理します。

スプレッドシート管理の限界

スプレッドシートにX投稿テキスト列とハッシュタグ列を設けておく方法は、記事の生成段階では合理的です。しかし、実際にXに投稿するタイミングでは問題が起きます。

MakeのWordPress Watch Postsトリガーは、WordPressの記事公開を検知して発火します。このとき取得できるのはWordPressの投稿データ（タイトル、本文、カテゴリ、カスタムフィールドなど）です。スプレッドシート上のX投稿データはWordPress側に存在しないため、Watch Postsトリガーからは直接参照できません。

スプレッドシートから読み取るには、別途Google Sheetsモジュールで「該当する記事のX投稿テキスト列・ハッシュタグ列を検索して取得する」シナリオを追加する必要があります。これはクレジット数が増え、シナリオも複雑になります。

カスタムフィールドなら記事と投稿データが1か所で完結する

WordPressのカスタムフィールド（post meta）にX投稿データを保存すれば、Watch Postsトリガーで記事データと一緒にX投稿テキストも取得できます。スプレッドシートを参照する追加モジュールは不要です。

さらに、WordPress管理画面の記事編集画面からもX投稿テキストを直接確認・修正できるため、公開前の最終チェックも容易になります。

全体像｜スプレッドシートからX投稿までのデータの流れ

実装に入る前に、データがどう流れるかの全体像を把握しておきましょう。

データフロー図

全体の流れは以下の5ステップです。

各ステップで何が起きるか

ステップ1：スプレッドシートにデータを入力。記事管理用のスプレッドシートに、記事データ（タイトル、本文、メタ情報など）に加えて、X投稿テキスト列（x_post_text用）とハッシュタグ列（x_hashtags用）にもデータを入力します。列の位置はスプレッドシートの構成に合わせて自由に設定してください。

ステップ2：Makeの記事投稿シナリオが実行される。HTTPモジュールでWordPress REST API（POST /wp-json/wp/v2/posts）にリクエストを送信します。このとき、リクエストボディのmetaフィールドにX投稿テキスト列・ハッシュタグ列の値を含めます。

ステップ3：WordPressに下書き記事が作成される。記事本文とともに、カスタムフィールド（x_post_text、x_hashtags）にX投稿データが保存されます。

ステップ4：手動で内容を確認し、記事を公開する。WordPress管理画面で記事内容とX投稿テキストを最終確認し、公開ボタンを押します。

ステップ5：X投稿シナリオが発火する。別のMakeシナリオ（WordPress Watch Posts → Buffer）がWordPressの公開を検知し、カスタムフィールドからX投稿テキストとハッシュタグを読み取り、Bufferを経由してXに投稿します。

この記事で扱うのはステップ1〜4までです。ステップ5のBuffer連携については前回の記事で解説しています。

▶ Make→X自動投稿の代替手段と Buffer連携の全体像はこちら
Make→X自動投稿の代替手段3選｜モジュール廃止後の実践ガイド

STEP1｜WordPress側の準備（functions.phpにカスタムフィールドを登録）

WordPressのREST APIでカスタムフィールドを読み書きするには、事前にそのフィールドを「REST APIに公開する」設定が必要です。register_post_meta関数を使います。

register_post_metaでREST APIに公開する

WordPressのREST APIは、デフォルトではカスタムフィールドを返しません。register_post_meta関数で明示的に「このフィールドはREST APIで読み書きできる」と宣言する必要があります。

ポイントは show_in_rest パラメータを true にすることです。これにより、REST APIのレスポンスにmetaフィールドが含まれるようになり、POSTリクエストでの書き込みも受け付けるようになります。

コピペ用コード全文

WordPressテーマのfunctions.php（子テーマを使用している場合は子テーマのfunctions.php）に以下のコードを追加してください。

add_action( 'rest_api_init', function() {	 
 register_post_meta( 'post', 'x_post_text', array(	 
 'type' => 'string',	 
 'single' => true,	 
 'show_in_rest' => true,	 
 'description' => 'X投稿用テキスト',	 
 ) );	 
 register_post_meta( 'post', 'x_hashtags', array(	 
 'type' => 'string',	 
 'single' => true,	 
 'show_in_rest' => true,	 
 'description' => 'X投稿用ハッシュタグ',	 
 ) );	 
} );

コードの内容を説明します。’post’ は通常の投稿タイプ（post）に対してフィールドを登録する指定です。固定ページにも登録したい場合は ‘page’ に対しても同様のコードを追加してください。’single’ => true は1つの投稿に対して1つの値を持つことを意味します。’type’ => ‘string’ はテキストデータであることを示します。

登録できたか確認する方法

コードを追加したら、ブラウザで以下のURLにアクセスして確認します。

https://あなたのドメイン/wp-json/wp/v2/posts/記事ID

レスポンスのJSONに “meta” オブジェクトが含まれ、その中に “x_post_text” と “x_hashtags” が表示されていれば成功です。まだ値を書き込んでいない段階では空文字（””）が表示されます。

STEP2｜スプレッドシートにX投稿データ列を追加する

次に、記事管理用スプレッドシートにX投稿データ用の列を追加します。列の位置はスプレッドシートの既存構成に合わせて決めてください。この記事では便宜上、X投稿テキスト列を「x_post_text列」、ハッシュタグ列を「x_hashtags列」と呼びます。

x_post_text列の設計ルール

x_post_text列にはX投稿のテキスト本文を入力します。設計ルールは以下の通りです。

x_post_text列テキスト ＋ x_hashtags列ハッシュタグ ＋ URL（23文字換算）＋ 改行・スペース（4文字）の合計が280文字以内に収まること。x_post_text列単体の目安は180文字前後です。

投稿テキストは3パート構造で書きます。1行目はフック（疑問形・あるある・意外性でスクロールを止める）。2〜3行目はベネフィット（記事を読むと何が得られるかを具体的に書く）。最終行はCTA（「↓」でURLへ誘導する一言）。絵文字は1〜2個まで。記事タイトルをそのまま使わないこと。MakeでURLを末尾に自動付与する前提のため、x_post_text列にURLは書きません。

x_hashtags列の設計ルール

x_hashtags列にはハッシュタグを入力します。3〜5個を半角スペース区切りで記述します。構成はメインキーワード系1〜2個、カテゴリ系1個、サイトブランドタグ1個です。

280文字チェックの考え方

Xの投稿上限は重み280です。XはWeighted Character Countingという仕組みを使っており、半角英数字・半角記号は重み1、日本語（CJK）・絵文字は重み2でカウントされます。URLはt.co短縮で常に重み23固定です。

つまり日本語だけで書いた場合、実質140文字が上限になります。投稿テキスト（x_post_text列）＋ハッシュタグ（x_hashtags列）＋URL（重み23）＋改行・スペース（重み4）の合計重みが280以内に収まる必要があります。

スプレッドシートで重みを正確に計算するには、LEN関数では不十分です。日本語の文字数にはLENB関数を使い、以下のような重み計算式を入れておくと便利です。

=LENB(A1) - LEN(A1) + LEN(A1) + 23 + 4

この式は「マルチバイト文字の数 × 2 ＋ シングルバイト文字の数」を概算します。厳密にはUTF-8のバイト数と重みは異なりますが、日本語中心のテキストであれば実用上十分な精度です。2026年3月時点の仕様に基づいています。

STEP3｜MakeのHTTPモジュールにmeta書き込みを追加する

ここが本記事の核心です。既存のMakeシナリオで、WordPress REST APIにPOSTリクエストを送信しているHTTPモジュールのBODYの、metaフィールドに項目を追加します。

MakeのHTTPモジュールの設定画面で、Body content typeが「JSON (application/json)」でBody input methodが「JSON string」になっている前提で説明します。

Body contentのJSONテンプレート内で、”meta” 内の値にスプレッドシートのx_post_text列・x_hashtags列の変数をマッピングします。Makeのマッピングパネルで、Google Sheetsモジュールから取得した値を選択し、”x_post_text” と “x_hashtags” にそれぞれ割り当てます。

テスト実行と確認

MakeのHTTPモジュールを修正したら、「Run once」でテスト実行します。テスト用のスプレッドシート行にダミーデータ（x_post_text列：「テスト投稿テキスト」、x_hashtags列：「#テスト #確認用」）を入力しておきましょう。

実行後、MakeのHTTPモジュールの出力でHTTPステータスコード201（Created）が返っていれば成功です。レスポンスボディのmetaオブジェクト内に x_post_text と x_hashtags の値が含まれていることを確認してください。

ムラサキ

筆者が最初にテスト実行したとき、JSONボディ内のmeta部分でカンマの位置を間違えて400エラーが出ました。MakeのHTTPモジュールの出力ログでリクエストボディ全文を確認すると原因が特定しやすいです。

STEP4｜投稿後にカスタムフィールドを確認する方法

テスト実行でWordPressに下書きが作成されたら、カスタムフィールドが正しく書き込まれているか確認しましょう。

WordPress管理画面での確認

WordPress管理画面で該当の下書き記事を開き、記事エディタ（ブロックエディタ）の右上にある縦三点メニュー → 設定 → パネル → 「カスタムフィールド」をオンにします。初回はページのリロードが必要です。

リロード後、記事エディタの下部にカスタムフィールドのセクションが表示されます。ここに x_post_text と x_hashtags が表示され、スプレッドシートから入力した値が入っていれば成功です。

この画面からX投稿テキストを直接編集することもできます。記事公開前の最終チェックで「このテキストでXに投稿して大丈夫か」を確認し、必要に応じてここで修正してから公開してください。

REST APIレスポンスでの確認

ブラウザで https://あなたのドメイン/wp-json/wp/v2/posts/記事ID にアクセスすると、JSONレスポンスの “meta” 内に値が入っていることも確認できます。MakeのWatch Postsトリガーが取得するデータも、これと同じ構造です。

よくある質問

まとめ

WordPressのカスタムフィールドにX投稿データを持たせることで、記事と投稿テキストを一元管理できるようになりました。

この仕組みにより、スプレッドシートにデータを入力 → Makeで下書き投稿 → 手動確認・公開 → 自動でXに投稿、という一連のワークフローが完成します。

ムラサキ

カスタムフィールドの設定は地味な作業ですが、一度やれば全記事で恩恵を受けられます。まずはテスト用のダミーデータで試してみてください。

Makeの基本操作やシナリオの組み方から知りたい方はMake副業自動化入門の全手順を、MakeのXモジュール廃止後にBuffer経由でX投稿を再開する方法は代替手段3選の実践ガイドを参照してください。

2026.03.20 更新：Makeの課金単位「オペレーション」→「クレジット」への名称変更を反映、料金比較表を2026年3月時点の情報に更新

副業でブログを書いている会社員が直面する問題があります。「記事を書く」以外の作業が多すぎることです。WordPress への投稿、X への告知、管理表の更新、アイキャッチ画像のリサイズ。1 記事あたり 15〜20 分かかるこの「地味な手作業」を、筆者は Make というノーコード自動化ツールでほぼゼロにしました。

本記事では、SE 歴 20 年・副業ブログ 運営の筆者が、Make の無料プランで実際に動かしている 2 つのシナリオを図解付きで公開します。最も需要が高い「スプレッドシート → WordPress 自動投稿」は、Step ごとにスクショ挿入箇所を設けたので、読みながらそのまま再現できます。

記事を書いた後の「作業」、毎回やっていませんか？

ブログ記事を 1 本公開するまでの流れを思い出してください。下書きを書く。WordPress にログインして本文を貼り付ける。アイキャッチ画像を設定する。カテゴリとタグを選ぶ。メタディスクリプションを入力する。公開ボタンを押す。そして X を開いてタイトルと URL を貼り付けて投稿する。さらに管理用のスプレッドシートや Notion に公開日とタイトルを記録する。

記事を書くこと以外の手作業が週末の可処分時間を圧迫していました。「記事を書くこと」に集中するために、それ以外の工程を自動化する必要がありました。そこで導入したのが Make です。

Makeとは？副業ブロガーが知るべき3つのポイント

ノーコードでアプリ同士をつなぐ「配線ツール」

Make（旧 Integromat）は、異なるWebサービスをノーコードで連携させる自動化プラットフォームです。WordPress、X、Googleスプレッドシート、Notionなど 3,000 以上のアプリに対応しています。画面上でモジュールと呼ばれるパーツを線でつなぐだけでワークフローが完成します。

同種のツールに Zapier がありますが、Make は分岐やループを視覚的に組める点が強みです。副業で使う程度の複雑さなら、どちらでも問題ありません。ただし無料プランの太っ腹さでは Make に軍配が上がります。

無料プランでできること・できないこと

2026年3月時点の情報です。2025年8月にMakeは課金単位の名称を「オペレーション」から「クレジット」に変更しました。非AIアプリでは1 operation = 1 creditの1:1換算で料金は変わりませんが、AIアプリ（Make AI Agents等）を使う場合はトークン消費に応じてクレジットが動的に変動します。最新の料金はMake公式料金ページで確認してください。

Make の料金プランは公式サイトで確認できます。

※ 2026年3月時点の価格です。最新情報はMake公式料金ページで確認してください。

副業ブロガーに向いている理由

副業ブロガーが日常的に使うツールは WordPress・X・Googleスプレッドシート・Notion の 4 つに集約されます。Make はこの 4 つすべてに公式モジュールを用意しています。つまり、副業ブロガーのツールスタックにそのままはまる自動化基盤です。

【実例公開】筆者が実際に動かしている2つのシナリオ

ここからは筆者が 実際に使っている Make シナリオを公開します。すべて無料プラン内で運用できています。

シナリオ1｜スプレッドシート → WordPress自動投稿

ポイントは、スプレッドシートに「x_post_text」と「x_hashtags」の列を設けておくことです。この 2 つは後述のシナリオ 2 で X 投稿に使うデータです。記事を書く段階で SNS 投稿文まで一緒に用意しておくことで、公開からSNS告知までの一連の流れが全自動になります。

シナリオ2｜WordPress公開 → Buffer経由でX自動投稿

以前は Make の X モジュールで直接投稿可能でしたが、2025 年 5 月に X モジュールが廃止されました。現在は Make → Buffer → X という構成に切り替えて運用しています。Buffer は SNS 投稿管理ツールで、無料プランでも X への投稿が可能です。Make には Buffer モジュールが標準で用意されているため、追加費用なしで連携できます。

カスタムフィールド（x_post_text / x_hashtags）を導入し、「フック → ベネフィット → CTA」の3パート構成でX投稿テキストを管理する仕組みに移行済みです。スプレッドシートにX投稿テキストを入力すれば、記事投稿と同時にWordPressのカスタムフィールドに書き込まれ、公開時にWatch Postsトリガーで自動取得されます。実装手順はWordPressカスタムフィールドでX投稿テキストを管理する手順で解説しています。

Make の X モジュール廃止の経緯、Buffer 連携の詳細手順、HTTP モジュールで X API を直接叩く方法など、X 自動投稿の代替手段については代替手段3選の実践ガイドで詳しく解説しています。

PC側の自動化に興味がある方はSE歴20年が実務で使っている業務自動化テクニックも参考になります。

【図解】シナリオの作り方を完全ステップ解説

ここからは「WordPress 公開 → Buffer 経由で X 自動投稿」の構築手順を解説します。シナリオ 1（スプレッドシート → WordPress）の構築は WordPress モジュールの設定までは同じ手順のため、まずはこの Step を完了させてください。

Step 1｜Makeアカウント作成とWordPress接続

Make の公式サイト（[make.com](http://make.com/)）で Google アカウントまたはメールアドレスでサインアップします。ダッシュボードが表示されたら「Create a new scenario」をクリックし、最初のモジュールとして「WordPress」を検索して追加します。

WordPress との接続には Make Connector プラグインの API Key を使います。まず WordPress 管理画面の「プラグイン」→「新規追加」で「Make Connector」を検索してインストール・有効化します。有効化すると左メニューに「Make」が追加されるので、クリックして表示される API Key をコピーしてください。

Make に戻り、WordPress モジュールの「Create a connection」画面で以下を入力します。

URL の末尾は「/wp-json」です。「/wp-json/」のようにスラッシュを付けても動作しますが、統一しておくとトラブルが減ります。入力したら「Save」をクリックしてください。

Step 2｜Buffer接続とXへの投稿設定

2025 年 5 月に Make の X モジュールが廃止されたため、X への投稿には Buffer を経由します。Buffer は SNS 投稿管理ツールで、無料プランでも利用可能です。X Developer Portal での API キー取得は不要です。

まだ Buffer アカウントを持っていない場合は buffer.com で無料登録し、設定画面から X アカウントを接続しておいてください。

Make のシナリオ画面に戻り、WordPress モジュールの右の「＋」をクリックします。検索窓に「Buffer」と入力し、「Create a Status Update」アクションを選択します。「Create a connection」をクリックすると OAuth 認証のポップアップが表示されるので、Buffer アカウントでログインして許可してください。

接続が完了したら、Profile（投稿先）で X アカウントを選択します。Text フィールドには WordPress モジュールから取得できる変数を直接組み合わせて投稿文を組み立てます。たとえば「記事タイトル＋改行＋記事 URL」のように設定します。今後カスタムフィールド（x_post_text / x_hashtags）を導入すれば、より訴求力のある投稿文に切り替えることも可能です。

Step 3｜テスト実行と本番稼働

画面左下の「Run once」をクリックしてテスト実行します。WordPress で記事を 1 本公開し、X に投稿が作成されることを確認してください。

成功したらシナリオのスケジュールを ON にします。無料プランでは 15 分間隔が最短です。副業ブログの公開頻度なら十分です。エラー発生時にメール通知が届くよう、シナリオ設定の「Notifications」も有効にしておきましょう。

無料プランで運用するコツと注意点

Make の無料プランは副業ブログ運営に十分な容量がありますが、いくつか気をつける点があります。

筆者の運用では、シナリオ 1（スプレッドシート → WP）とシナリオ 2（WP → Buffer → X）の 2 つを使い分けています。Make の無料プランではアクティブシナリオが 2 つまでのため、ちょうど枠内に収まります。シナリオ 2 は記事公開時だけ ON にし、投稿確認後に OFF にする半手動運用で、クレジットの消費を抑えています。

クレジット消費の目安は、シナリオ 1 本の実行で 2〜3 クレジットです。月 30 記事 × 2 シナリオでも約 180 クレジット。無料枠の 1,000 に対して余裕で収まります。

スプレッドシートの操作自体を効率化したい場合はExcel業務効率化15選にまとめたテクニックが役立ちます。

よくある質問（FAQ）

Claude Codeのヘッドレスモードやフック機能を活用すれば、Makeとの連携もさらに柔軟になる。詳しくはClaude Code /powerup入門を参照。

まとめ｜「記事を書く以外」は全部自動化していい

本記事で紹介した 2 つのシナリオを導入した結果、1 記事あたりの「記事を書く以外の作業時間」は約 15 分から 1 分以下になりました。月 30 記事換算で約 7 時間の節約です。浮いた時間は記事の質を高めるリサーチに充てており、この仕組みで実際に1ヶ月運営した結果は副業ブログ1ヶ月目の実績レポートで全数字を公開しています。

副業ブログの本質は「読者に価値ある記事を届けること」です。WordPress への投稿作業、X への告知、管理表の更新は、記事の価値を生み出す工程ではありません。だから自動化していいのです。

Make の無料プランなら費用もゼロです。まずはシナリオ 1（スプレッドシート → WordPress 自動投稿）だけでも試してみてください。手元のスプレッドシートに 1 行書くだけで WordPress に下書きが生まれる体験は、自動化の第一歩として最適です。X自動投稿のモジュール廃止後の代替手段はMake→X自動投稿の代替手段3選で詳しく解説しています。また、Make以外にもPC操作レベルで「面倒」を潰すテクニックをSE歴20年の業務自動化術にまとめています。GASを使えばGmailの情報をNotebookLMに自動集約することもでき、手順はGAS×NotebookLMメール集約の実装手順で解説しています。

2026.03.20 更新：コードレビューエージェントの進捗を更新（パイロット運用開始・簡素化の経緯を追記）、自動化テクニック比較表を追加

SEとして20年、同じ会社で働いている。この20年で「自分の仕事を自分で楽にする」ことだけは一貫して続けてきた。

大規模な業務改革ではない。SendToフォルダに自作ツールを入れる、PowerShellでパスを取得する、Seleniumで入力チェックを回す。どれも小さい。しかし小さいものが積み重なると、1日のうち30分から1時間は確実に浮く。年間にすれば200時間になる。

本記事では、筆者が実務で実際に使っている自動化テクニックを紹介する。華やかなツール紹介ではなく、「Windows標準の範囲内で動くこと」「管理者権限がなくても使えること」「Windows 10と11の両方で動くこと」という現場の制約下で生まれたものばかりだ。

本記事で紹介する自動化テクニック一覧

難易度「低」のSendToカスタマイズから順に紹介する。自分の業務で「面倒だ」と感じている作業に近いものから読み進めてほしい。

SendToフォルダのカスタマイズ｜右クリックを自分専用にする

Windowsの「送る」メニューは、ファイルやフォルダを右クリックしたときに表示される。このメニューの実体は「shell:sendto」で開けるフォルダに入っているショートカットだ。ここに自作ツールのショートカットを置けば、右クリックから一発で任意の処理を実行できる。

筆者が登録しているのはパス取得ツールだ。ファイルやフォルダを「送る」だけで、そのフルパスをクリップボードにコピーする。手順書やチャットでパスを共有する場面は毎日ある。エクスプローラーのアドレスバーをクリックしてコピーしてもいいが、ファイル単位のパスが欲しい場面ではこちらの方が早い。

登録方法はシンプルで、Win+Rで「shell:sendto」を実行し、開いたフォルダにショートカットを置くだけだ。特別な権限は不要で、自分のユーザーフォルダ配下なので管理者権限も要らない。

PowerShellでSharePointのパスを一発取得する

SharePointのファイルをローカル同期している環境では、同期フォルダのパスにユーザー名が含まれる。たとえば「C:Usersyamada会社名チーム名ドキュメント」のような構成だ。これをそのままチームに共有しても、他のメンバーの環境ではパスが通らない。

PowerShellでユーザー固有の部分を環境変数に置換するスクリプトを作った。実行すると、ユーザー名の部分が「%USERPROFILE%」に置き換わった汎用パスがクリップボードに入る。これをチャットに貼れば、誰の環境でもそのまま使える。

やっていることは文字列の置換だけだが、毎日5回以上パスを共有する業務では効果が大きい。こうした「1回10秒の手間」を潰すことが、自動化の第一歩だと思っている。

Excel/Accessのモジュールを自動エクスポートする

VBAで業務ツールを開発していると、モジュールのバージョン管理が課題になる。Gitで管理したくても、VBAのコードはExcelファイルの中に格納されているため、そのままではdiffが取れない。

この問題を解決するために、カスタムスクリプトでExcelやAccessからVBAモジュールとシート情報を自動エクスポートする仕組みを作った。エクスポートしたテキストファイルをGit管理すれば、変更履歴が追える。

さらに、SpreadsheetCompareと連携させて2つのExcelファイルの差分を一発で表示する機能も追加した。レビュー時に「どこが変わったのか」を目視で確認する手間がなくなった。EUC（エンドユーザーコンピューティング）の開発では、こうした周辺ツールの整備が品質と保守性に直結する。

ExcelVBAの設計思想や効率化テクニックはこちら

Seleniumでメンバーの入力内容を自動チェックする

チームメンバーがWebシステムに入力したデータの整合性チェックを、Python＋Seleniumで自動化している。以前は目視で確認していたが、件数が増えると見落としが出る。ブラウザを自動操作して入力内容を取得し、ルールに照らしてNGを検出する仕組みだ。

Seleniumを選んだ理由は単純で、チェック対象がブラウザ上のWebアプリケーションだからだ。APIがあればAPIを叩く方が早いが、レガシーなシステムではブラウザ操作しか手段がない場合がある。環境制約のなかで「動くもの」を作ることが現場では重要になる。

導入効果は明確で、月あたり約4時間の確認作業がほぼゼロになった。最初のスクリプト作成に半日かかったが、2ヶ月目で回収できている。

Python×業務自動化の基本から実践例までを体系的に学びたい方には、以下の書籍がおすすめです。筆者もSelenium導入時に参考にしました。

NotebookLMでVBAモジュールをデバッグする

GoogleのNotebookLMにVBAモジュールのソースコードを読み込ませて、不具合の原因調査に活用している。具体的には、エクスポートしたモジュールファイルをそのままアップロードし、「このモジュールで○○の処理が期待通りに動かない。原因を分析してほしい」と質問する。

NotebookLMの強みは、アップロードしたドキュメントの内容に基づいて回答する点だ。一般的な生成AIに長いコードを貼り付けるよりも、文脈を正確に把握してくれる。複数モジュール間の依存関係がある場合でも、関連ファイルをまとめて読み込ませれば横断的に分析してくれる。

ただし万能ではない。VBAの古い記法や、Excel特有のオブジェクトモデルに関しては誤った回答が返ることもある。最終的な判断は自分でやる必要がある。それでも「あたりをつける」速度は格段に上がった。

本業プロジェクトのメールをGASで自動集約し、NotebookLMで思考整理する手順は「GAS×NotebookLM実践記」で解説しています。

▶ 生成AI時代に求められるスキルの変化についてはこちら
【生成AI時代】必要・不要なスキルと若手教育の進め方

コーディング支援エージェントの構想｜環境制約との戦い

現在取り組んでいるのが、コーディング支援エージェントの構築だ。目指しているのは、「VBAやPowerShellのコードを書く際に、環境制約を理解した上でアドバイスしてくれるAI」の実現だ。

環境制約は3つある。Windows標準の範囲内で完結すること、Windows 10と11の両方で動作すること、管理者権限がないこと。これらを満たさないコードは、いくら優れていても現場では使えない。一般的な生成AIにコードを書かせると、この制約を無視した回答が返ってくることが多い。

現時点ではまだ完成していない。プロンプトに制約条件を組み込んだカスタム指示を作成し、テスト中だ。うまくいけば、チームメンバーが自分でツールを作る際のハードルが大幅に下がると考えている。完成したら別記事で詳しく書く予定だ。

AIコーディング支援の活用が広がる中で、使い方次第でスキル形成に3.6倍の差がつくことがAnthropicの研究で示されている。AI時代のキャリア設計と行動指針も参考にしてほしい。

コードレビューエージェント（パイロット運用中）

もう一つ取り組んでいるのが、コードレビューエージェントだ。メンバーが書いたVBAコードを読み込ませて、命名規則の違反、エラーハンドリングの漏れ、モジュール分割の不備などを自動で指摘する仕組みを目指している。

当初はNotebookLMにレビュー観点をまとめたドキュメントとコードを同時に読み込ませる形で運用していたが、レビュー観点の網羅や指摘の完全な抽出がどう調整しても期待通りに動作しなかった。プロジェクト固有のコーディング規約を守らせるのが特に難しく、AIのコンテキスト処理能力の限界を感じた。

そこで方針を切り替え、レビュー観点を絞った簡素版をパイロット運用している。DRY原則や命名規則などに絞り、他の観点は人間のレビュアーが補う分業体制にした。完全自動化は諦めたが、レビュアーが最初に目を通す前の「粗チェック」としては機能し始めている。

やりたいことを完全に実現するには、AIのスペックがもう一段上がる必要があると感じている。2026年3月時点では「要点を絞って使う」のが現実的な落としどころだ。レビューの質を均一化し、レビュアーの負担を減らすという方向性は変わらない。引き続き改善を進める。

よくある質問

Claude Codeにはターミナル内で機能を学べるチュートリアルコマンドも搭載されている。Hooksやヘッドレスモードの使い方を体系的に把握したい方はClaude Code /powerup入門を参照してほしい。

まとめ｜自動化は「面倒くさい」から始まる

紹介した内容を振り返ると、どれも出発点は「面倒くさい」だった。パスをコピーするのが面倒、入力チェックが面倒、コードの差分確認が面倒。その「面倒」を1つずつ潰してきただけだ。

重要なのは、最初から大きな仕組みを作ろうとしないことだ。SendToにショートカットを1つ追加する。PowerShellで10行のスクリプトを書く。そこから始めて、必要に応じて拡張していく。この積み上げが20年の蓄積になった。

環境制約がある中でも、Windows標準機能とPythonだけでかなりのことができる。管理者権限がなくても、外部ライブラリをインストールできなくても、工夫次第で業務は楽になる。「制約があるからできない」ではなく「制約の中で何ができるか」を考える方が、SEとしては生産的だと思っている。

Google Workspace側に特化したレシピはClaude Code×GASでWorkspace自動化7選に集約しているので、Gmail・カレンダー・ドライブの定型作業を撲滅したい場合はそちらを参照。

2026.03.25 更新：NotebookLMプラン体系をPlus/Pro/Ultra体系に修正、Gemini 2.5 Flash・3系モデルのシャットダウン情報を追記

「このプロジェクト、過去のメールを全部読み返さないと判断できない」──SE歴20年、こういう場面に何度も遭遇してきました。NotebookLMにメールを投入すれば文脈を横断して質問できると知り、試しに40通ほど突っ込んだところ、思考整理が驚くほど捗りました。

しかし問題はその「突っ込む」作業です。Gmailからメールを1通ずつコピーしてGoogleドキュメントに貼り付け、NotebookLMのソースに手動追加する。隔週で繰り返すと、準備だけで30分以上かかります。

そこでGoogle Apps Script（GAS）を使い、プロジェクトに関連するメールを自動で集約するスクリプトを書きました。本記事では、最初に書いた「動くけど荒い」v1と、実運用で起きた問題を踏まえて改善したv2の両方を、コピペ用コード付きで公開します。

本業メールの山をNotebookLMで「思考の素材」に変えたかった

きっかけ──40通のメールを手作業でNotebookLMに投入した日

担当プロジェクトの方向性を整理する必要があり、過去2週間分のメールをNotebookLMに投入してみました。メールの本文をGoogleドキュメントにまとめ、NotebookLMのソースとして追加すると、「この案件で未回答の論点は何か」「A社とB社の要望の違いを整理して」といった質問に対し、メール横断で回答が返ってきます。

自分の記憶だけでは見落としていた論点が浮かび上がり、NotebookLMの有用性を実感しました。ただし、40通のメールをGmailから手動でコピーしてドキュメントに貼り付ける作業は、想像以上に面倒でした。これを隔週で繰り返すのは現実的ではなく、GASで自動化しようと考えました。

NotebookLMはGoogleが提供するAIノートブックツールです。Googleドキュメント・PDF・Webページなどをソースとしてアップロードすると、それらの内容に基づいてAIが質問に回答します。2026年3月時点では無料版のほか、Google AIのPlus（月額1,200円）・Pro（月額2,900円）・Ultra（月額36,400円）の有料プランがあり、上位プランほどソース数やチャット回数の上限が拡張されます。本記事のスクリプトは無料版で十分に運用できます。NotebookLMの7つの活用術と実務レビューはこちら

GASを開くだけで迷った話

GASを使おうとして、最初にハマったのが「どこから開くか」でした。Google検索で「GAS」と調べてscript.google.comにアクセスしたところ、Google Workspaceアカウントと個人アカウントの切り替え問題でログインできません。

結局たどり着いたのは、Googleドライブの「新規作成 → その他 → Google Apps Script」という経路です。Workspaceアカウントの場合、この方法が最も確実です。GASを初めて使う方は、script.google.comではなくGoogleドライブから開くことをおすすめします。

最初に書いたスクリプト──「動くけど荒い」v1の全容

v1の仕様とコード

最初に書いたスクリプトの仕様はシンプルです。Gmailの検索演算子を使い、プロジェクト名のキーワードと基準日以降という条件でメールを検索します。スレッド形式のメールは最新の1通だけを取得し、本文をそのままGoogleドキュメントに結合して出力します。キーワードと基準日はスクリプト内にハードコードしていました。

function collectProjectEmails_v1() {
  var keyword = "プロジェクトABC";
  var sinceDate = "2026/01/15";
  var query = keyword + " after:" + sinceDate;
  var threads = GmailApp.search(query);

  var doc = DocumentApp.create(
    keyword + "_メール集約_" + new Date().toLocaleDateString("ja-JP")
  );
  var body = doc.getBody();

  for (var i = 0; i < threads.length; i++) {
    var messages = threads[i].getMessages();
    var lastMsg = messages[messages.length - 1];
    body.appendParagraph("【件名】" + lastMsg.getSubject());
    body.appendParagraph("【日時】" + lastMsg.getDate().toLocaleString("ja-JP"));
    body.appendParagraph("【差出人】" + lastMsg.getFrom());
    body.appendParagraph(lastMsg.getPlainBody());
    body.appendParagraph("─".repeat(40));
  }

  doc.saveAndClose();
  Logger.log("作成完了: " + doc.getUrl());
  Logger.log("取得スレッド数: " + threads.length);
}

このスクリプトで基本的な自動集約は実現できました。手動で40通コピーしていた作業が、ボタン一つで完了します。

v1で起きた問題──情報のミスリード

2回目の実行で問題が発生しました。キーワード検索でヒットしたメールの中に、対象プロジェクト以外の情報が含まれていたのです。具体的には、複数案件の売上報告メール、自分宛のメールメモ、案件横断の請求・支払業務メールです。

これらはメール本文にプロジェクト名が含まれているためキーワード検索にヒットしますが、中身は別案件の金額や状況も記載されています。このままNotebookLMに投入すると、別案件の数字やコンテキストが混入し、AIの回答が事実と異なる内容を含む危険があります。

以降、集約後にGoogleドキュメントを目視確認し、不要なメールを手動で削除する運用にしましたが、これでは自動化の意味が半減します。

改善版v2──スプレッドシート制御＋除外フィルタ

v1の問題を踏まえ、3つの改善を加えたv2を作成しました。最大の変更点は、キーワード・基準日・除外条件をスプレッドシートから読み込む方式にしたことです。スクリプトを毎回書き換える必要がなくなりました。

改善点① キーワードと基準日をスプレッドシートから読み込み

スプレッドシートに「設定」シートを作り、A1にプロジェクトキーワード、B1に基準日を入力します。スクリプトはこの値を読み取って検索に使います。隔週で実行する際は、スプレッドシートの日付を更新するだけで済みます。複数プロジェクトに対応したい場合は、行を増やして拡張できます。

改善点② 除外キーワードをブラックリスト管理

同じスプレッドシートの「除外」シートに、除外したい件名キーワードを縦に並べます。たとえば「売上報告」「請求」「支払」の3行です。スクリプトはメールの件名にこれらの文字列が含まれている場合、そのメールをスキップします。

運用しながら除外キーワードを追加できるため、スクリプト本体を触る必要がありません。当初3個だった除外キーワードが増えても、シートに1行追加するだけです。

改善点③ 実行ログをスプレッドシートに出力

何通取得して何通除外したかを「ログ」シートに記録します。集約結果の信頼性を確認でき、除外キーワードの調整にも役立ちます。ドキュメントURLも記録するので、NotebookLMへの投入時にログシートからワンクリックでアクセスできます。

v2コピペ用コード全文と使い方

コード全文

function collectProjectEmails_v2() {
  // スプレッドシートから設定読み込み
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var settingsSheet = ss.getSheetByName("設定");
  var keyword = settingsSheet.getRange("A1").getValue();
  var sinceDate = Utilities.formatDate(
    new Date(settingsSheet.getRange("B1").getValue()),
    Session.getScriptTimeZone(),
    "yyyy/MM/dd"
  );

  // 除外キーワード読み込み
  var excludeSheet = ss.getSheetByName("除外");
  var excludeValues = excludeSheet
    .getRange("A1:A" + excludeSheet.getLastRow())
    .getValues();
  var excludeKeywords = excludeValues
    .map(function(row) { return row[0]; })
    .filter(String);

  // Gmail検索
  var query = keyword + " after:" + sinceDate;
  var threads = GmailApp.search(query);

  // ドキュメント作成
  var docTitle = keyword + "_メール集約_"
    + Utilities.formatDate(
      new Date(),
      Session.getScriptTimeZone(),
      "yyyy-MM-dd"
    );
  var doc = DocumentApp.create(docTitle);
  var body = doc.getBody();

  var countTotal = 0;
  var countExcluded = 0;
  var countIncluded = 0;

  for (var i = 0; i < threads.length; i++) {
    var messages = threads[i].getMessages();
    var lastMsg = messages[messages.length - 1];
    var subject = lastMsg.getSubject();
    countTotal++;

    // 除外判定
    var isExcluded = excludeKeywords.some(function(ex) {
      return subject.indexOf(ex) !== -1;
    });
    if (isExcluded) {
      countExcluded++;
      continue;
    }

    // ドキュメントに追記
    body.appendParagraph("【件名】" + subject);
    body.appendParagraph(
      "【日時】" + lastMsg.getDate().toLocaleString("ja-JP")
    );
    body.appendParagraph("【差出人】" + lastMsg.getFrom());
    body.appendParagraph(lastMsg.getPlainBody());
    body.appendParagraph("─".repeat(40));
    countIncluded++;
  }

  doc.saveAndClose();

  // 実行ログ記録
  var logSheet = ss.getSheetByName("ログ");
  if (!logSheet) {
    logSheet = ss.insertSheet("ログ");
    logSheet.appendRow([
      "実行日時", "キーワード", "基準日",
      "総スレッド数", "除外数", "取得数", "ドキュメントURL"
    ]);
  }
  logSheet.appendRow([
    new Date(), keyword, sinceDate,
    countTotal, countExcluded, countIncluded,
    doc.getUrl()
  ]);

  Logger.log(
    "完了: " + countIncluded + "通取得 / "
    + countExcluded + "通除外"
  );
  Logger.log("ドキュメント: " + doc.getUrl());
}

初回セットアップ手順

コードをコピーしたら、以下の手順で環境を整えてください。

「ログ」シートは初回実行時に自動作成されます。実行後にログシートを確認し、取得数と除外数が想定どおりか確かめてください。

▶ GAS以外にもSendToカスタマイズやSeleniumなど、Windows環境で使える自動化テクニックをまとめています。
SE歴20年の業務自動化術｜SendTo・Selenium・AIエージェントまで

GASの基礎から応用までを体系的に理解したい方には、以下の書籍が役立ちます。本記事のスクリプトで使っているSpreadsheetApp・GmailApp・DocumentAppの詳細な解説も含まれています。

集約ドキュメントをNotebookLMに投入するコツ

手動投入の効率化Tips

GASが生成したGoogleドキュメントのURLは、ログシートに自動記録されています。NotebookLMのソース追加画面で「Googleドライブ」を選択し、ドキュメント名で検索して追加します。ログシートのURL列をクリックすればドキュメントに直接アクセスでき、内容を目視確認してからNotebookLMに投入する運用が可能です。

投入前にドキュメントを開いて不要な部分がないか確認するひと手間を加えると、NotebookLMの回答精度がさらに安定します。v2の除外フィルタで大半は処理されていますが、件名に除外キーワードが含まれない想定外のメールが混入する可能性はゼロではありません。

自動投入はEnterprise限定──2026年3月時点の制約

NotebookLMにはEnterprise版のみAPI（notebooks.sources.batchCreate）が提供されています。GASからAPIを叩いてソースを自動追加する構成は技術的に可能ですが、Enterprise契約が必要です。NotebookLMの無料版・有料版の違いやEnterprise版の詳細は「NotebookLM活用術7選｜SE歴20年が実務で使い倒した全記録」で比較しています。

2026年2月19日にNotebookLMのバックエンドモデルがGemini 3.1 Proに更新されました。回答精度が向上している一方、一部のユーザーからは大量ソース投入時の検索品質低下が報告されています。GASで集約したドキュメントをNotebookLMに投入する際は、投入後の回答精度を確認し、必要に応じてソースを分割することをおすすめします。

個人向けプラン（Free / Plus / Pro / Ultra）ではソースの自動追加APIは利用できません。2026年3月時点では手動投入が唯一の方法です。

次のステップ──Gemini APIで返信下書きを自動生成する構想

構想：集約メールの文脈をGeminiに渡して下書き生成

現在のスクリプトはメールを「集める」ところまでですが、次のステップとして「返信の下書きを自動生成する」機能を計画しています。集約したメール本文をGemini APIに渡し、プロジェクトの文脈を踏まえた返信下書きをGmailの下書きフォルダに保存する仕組みです。

GASのUrlFetchAppを使えばGemini APIを直接呼び出せます。集約済みドキュメントのテキストをプロンプトに含め、「このプロジェクトの経緯を踏まえて、以下のメールに対する返信案を3パターン生成してください」のような指示を送ることで、文脈に沿った下書きが期待できます。

Gemini API無料枠で副業・本業どちらにも十分

Gemini 2.5 Flashの無料枠は1日あたり250リクエスト（RPD 250）、Flash-Liteなら1,000リクエスト（RPD 1,000）です（2026年3月時点）。隔週で40通程度のメールに対して返信下書きを生成する用途であれば、無料枠の範囲内で十分に収まります。APIキーはGoogle AI Studioから取得できます。

この構想は別記事で実装済みです。GASからGemini APIを呼び出し、プロジェクトの文脈を踏まえた返信下書きをGmailに自動保存するコード全文と実行結果を公開しています。本記事のv2スクリプトと同じ仕組みがベースなので、ここまでの内容を理解していればスムーズに読み進められます。

▶ 実装コードと手順の詳細はこちら
GAS×Gemini APIでメール返信下書きを自動生成する方法

GAS運用で知っておきたい注意点

GASにはいくつかの実行制限があります。1回の実行時間は最大6分で、これを超えるとスクリプトが強制終了します。40通程度のメール集約であれば問題ありませんが、数百通を対象にする場合は分割実行の仕組みが必要です。

トリガー（定期実行）は1プロジェクトあたり最大20個まで設定可能です。Google Workspaceアカウントと個人Googleアカウントでは実行上限が異なり、Workspaceアカウントのほうがメール送信数やURL Fetch回数の上限が高く設定されています。詳細はGoogle公式のApps Script割り当て量ページで確認できます。

GAS×Gemini API無料枠でメール返信を自動化｜5分類＋下書き生成の実装記録

1日30分のメール返信を自動化。GASとGemini APIの無料枠でメールを5分類して下書き生成する実装手順。2026年6月のGemini 2.5 Flashシャットダウンへの移行ガイダンスも収録。

shumatsu-lab.com

2026.02.22

よくある質問

まとめ

本業のプロジェクトメールをGASで自動集約し、NotebookLMの思考整理に活用する方法を解説しました。最初の「動くけど荒い」v1から、スプレッドシート制御と除外フィルタを加えたv2への改善過程を通じて、GASの実践的な使い方を紹介しています。

NotebookLMへの自動投入は現時点でEnterprise限定ですが、手動投入でもGASによるメール集約だけで大幅な時短になります。次のステップとしてGemini APIによる返信下書き自動生成も別記事で実装・公開済みです。本記事のv2スクリプトをベースにGemini APIと連携して返信下書きを自動保存する手順を解説しています。

▶ 本記事のメール集約をベースに、Gemini APIで返信下書きを自動生成する方法はこちらで解説しています。

GAS×Gemini API無料枠でメール返信を自動化｜5分類＋下書き生成の実装記録

1日30分のメール返信を自動化。GASとGemini APIの無料枠でメールを5分類して下書き生成する実装手順。2026年6月のGemini 2.5 Flashシャットダウンへの移行ガイダンスも収録。

shumatsu-lab.com

2026.02.22

▶ 集約したメールからスライド資料を作りたい場合、AIスライド生成ツールの選び方が参考になります。

AIスライド作成3ツール比較｜社内プレゼン向け実践ガイド

Gamma・NotebookLM・Canva AIを同一条件で実際に試した。生成速度・編集性・社内プレゼンでの機密情報の扱いまで徹底比較。最適ツールの選び方を解説。

shumatsu-lab.com

2026.05.17

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投稿を自動化した全手順をご覧ください。