【実録】同じ作業を100回繰り返す前に、自動化する側に回った日 ── Markdown のマーカー1個で Amazon+楽天 CTA が完成する仕組み

非エンジニアAIラボ第17記事アイキャッチ。Markdown 1行でCTA自動化のキャッチ。Editorial風デザイン、キャラクター入り。 AIワークフロー
2026.05.10

Markdown 原稿に {{cta:書名|amzn.to/xxx}} と1行書くだけで、WordPress にそのまま貼れる Amazon オレンジ + 楽天 深緑 の縦並列ボタンに展開される ── そんな小さなツール mdcta を作って GitHub に公開 した日の話。同じ作業を100回繰り返す前に、自動化する側に回るとどうなるか。

「えっ、これだけ?」

Markdown 原稿に1行マーカーを書いて、コマンドを1つ叩いた。出てきたファイルを開くと、Amazon と楽天の2色ボタンが、いつもの形で並んでいた。

書籍リンクを記事に貼るとき、これまで毎回同じ HTML をコピペしていた。Amazon の amzn.to/xxx を貼って、楽天の検索URLをもしもアフィリ管理画面で生成して、ボタンの色とパディングを調整して、PR表記を忘れずに付けて ── どの記事でも同じ手順だった。

その作業が、今、消えた。

これは、2026年5月10日(=今日)に作った mdcta という小さな Python スクリプトの話と、その設計を AI 5視点会議で詰めた経緯と、自分のブログの運営を「自動化する側」に押し上げる感覚の記録。

1. 発端 ── 100回繰り返す前に

第16記事 で、AI 5人と一緒に「次の記事のテーマ」を会議した。出てきた結論のひとつが、こう言葉になった:

同じ作業を100回繰り返す前に、自動化する側に回る

これは AI 5視点のうち「顧客視点」の担当者が、設計レビューの中で投げかけてきたフレーズだった。

「『アフィリリンクの貼り替えを自動化した』ではなく、『同じ作業を100回繰り返す前に、自動化する側に回った』というタイトルに寄せた方がいい。Excel の集計、日報、経費入力 ── ブログを書かない人にも刺さる思考法になる」

このフレーズを、まず自分のブログに対して使ってみることにした。

私は今、書籍CTAブロックを記事の終わりに毎回手で貼っている。最初に書籍CTAを貼ったのは 第10記事「Amazon書籍リンクを過去5記事に貼った日」 で、5記事まとめて手作業でコピペした。それ以降、書籍CTA v2(Amazon オレンジ + 楽天 深緑 の縦並列)に進化させて、第14記事・第15記事・第16記事 でも同じテンプレを毎回手で貼ってきた。これまでに16記事公開して、書籍CTAを貼ったのは12件ほど。これが 100記事になったら、同じHTMLを 100 回コピペすることになる。100回 × 30秒 ≒ 50分。累計1時間近い手作業を将来繰り返すなら、その前に自動化する側に回るのが明らかに合理的だ。

そういう動機で、mdcta を作ろうと決めた。

2. 5視点会議 ── 7つの論点を詰める

実装に入る前に、AI 5視点(アフィリ / 技術 / 顧客 / SEO / X運用)で設計を会議させた。お題は7つの論点:

#論点候補
1マーカー記法[BOOK: ...] / {{cta: ...}} / :::cta\n...\n::: / その他
2対応ASP範囲書籍だけ / +サーバー / +Claude Max / 全部
3配布形式ローカル専用 / GitHub OSS / npm/PyPI
4既存運用との接続既存テンプレを進化 / 別ファイル分離
5楽天URL生成自動生成 / 手動URLマップ
6アフィリID保護.env / 設定ファイル / GitHub除外
7エラー処理警告 / ビルド停止 / 静かにスキップ

5視点が並列に議論して、それぞれ視点ごとに3案ずつ推奨を出してきた。会議録は長いので要点だけ書くと:

  • マーカー記法:{{...}} 系を3視点が推した(=顧客「目立つ」、SEO「検索クエリ親和性」、X運用「Xに貼れる」)。技術視点だけが [BOOK:] 派(=正規表現で抜きやすい)。多数決で {{cta:書名|amzn.to/xxx}} に決定
  • 対応ASP範囲:Amazon+楽天の2本立てで3視点が一致(=顧客「設定の壁が高くなる」、SEO「超低競合領域」、X運用「現運用直結」)。アフィリ視点だけが「サーバー+Claude Max まで拡張」を推奨したが、第17記事のスコープは2本に絞った
  • 配布形式:GitHub OSS 化が4視点で支持(=被リンク獲得、ブランド化、READMEで初心者にも届く)
  • アフィリID保護:5視点全員一致で .env + .gitignore + .env.example 方式
  • エラー処理:マーカー誤記時はビルド停止+警告メッセージ。「無音でスキップ」は記事差し戻しの温床

特に印象に残ったのは、顧客視点の「IDをGitHubに上げて全部持っていかれた話は最高の実録ドラマ素材」という指摘。ヒヤリハットを意識的に書ける場所が、CTA自動化ツールの中にもある ということ。

3. リーダー裁定 ── 7つの設計選択

5視点の意見を統合して、リーダー(私)としてこう確定した:

#採用案理由
1マーカー記法 `{{cta:書名\amzn.to/xxx}}`1行で書ける、Markdown原稿に違和感なく溶け込む
2Amazon + 楽天の2本立て(将来拡張可)スコープを絞って記事の見やすさ優先
3GitHub OSS化(README + .env.example 付き)他のブロガーが Clone ボタン1つで使える
4新記事から適用(過去16記事は手動のまま)「過去と未来の境目」が実録ネタになる
5楽天URL書名検索URL自動生成既存 v2 運用と整合、二重エンコード方式
6.env + .gitignore + .env.example全員一致、ID流出は致命傷
7ビルド停止+警告メッセージ無音スキップは記事差し戻しの温床

設計はこれで決まった。あとは Python で書くだけ。

4. 実装 ── 3つのPythonファイル

実装は Python 標準ライブラリのみで、3つのファイルに分けた。コードを置くと長くなるので、要点だけ書く(=以下のコード抜粋は読み飛ばしてOK、各章の前後のテキストで要点が読めます)。

4-1. rakuten_url.py ── 楽天検索URLの二重エンコード

楽天検索URLをもしもアフィリ どこでもリンクに通すには、漢字部分を二重エンコードする必要がある(=URL に日本語を載せるための変換を、2回かける処理。% を %25 に置き換える形)。これは過去にこのブログの GA4 解説書 CTA で確立したパターン。

def _double_encode_keyword_parts(parts: list[str]) -> str:
    """検索キーワードのパーツ配列を + で繋ぎ、二重エンコード形式の文字列を返す。"""
    encoded_parts = []
    for p in parts:
        if all(ord(c) < 128 for c in p):
            encoded_parts.append(p)  # ASCII はそのまま
        else:
            single = quote(p, safe="")     # %E6%80%9D...
            double = single.replace("%", "%25")  # %25E6%2580%259D...
            encoded_parts.append(double)
    return "%2B".join(encoded_parts)

「AI+思考+技法」を渡すと、AI%2B%25E6%2580%259D%25E8%2580%2583%2B%25E6%258A%2580%25E6%25B3%2595 という二重エンコード文字列が返ってくる。これをもしもの url= パラメータに入れると、リダイレクト時に正しく楽天検索結果ページへ飛ぶ。

4-2. cta_template.py ── 書籍CTA HTMLテンプレ

ブロックでラップした HTML 文字列を返す関数。Amazon オレンジ #ff8c42、楽天 深緑 #1f6e5b、PR表記、rel="sponsored nofollow noopener" などをすべて埋め込む。Markdown 原稿に直接貼れば、WordPress 公開時にそのまま反映される。

4-3. mdcta.py ── マーカー検出 + 置換のエントリポイント

正規表現でマーカーを検出して、書籍CTAブロックに置換する本体:

MARKER_RE = re.compile(
    r"\{\{cta:"
    r"([^|}]+)"          # 書名(=楽天検索キーワード)
    r"\|"
    r"([^|}]+)"          # Amazon短縮URL
    r"(?:\|([^}]+))?"    # 導入文(オプション)
    r"\}\}"
)

re.sub(MARKER_RE, replace_one, md_text) で、原稿内のすべてのマーカーを一括変換する。マーカー誤記時は ValueError を投げてビルドを停止する(=リーダー裁定で決めた挙動)。

5. 動作確認 ── Before / After

examples/input.md というサンプル原稿に、3パターンのマーカーを書いた。

{{cta:WordPress+入門|amzn.to/4t1Azys}}
{{cta:AI+思考+技法|amzn.to/3OPJMMA|今回の発想は、この本に背中を押された。}}
{{cta:GA4|amzn.to/4tKaipG}}

これを python mdcta.py examples/input.md examples/output.md に通すと、3つのマーカーがすべて書籍CTA HTMLブロックに展開される。Amazon オレンジボタン、楽天 深緑ボタン、PR表記つき。

特に確認したかったのは、楽天URL の二重エンコードが正しく出ること。マーカー {{cta:AI+思考+技法|amzn.to/3OPJMMA}} から生成された楽天URLが、第16記事公開時に手作業で組み立てたURLと 完全に一致 していた。同じ思考の流れが、Python に閉じ込められた瞬間。

6. mdcta を GitHub OSS として公開 ── 他のブロガーにも届く

mdcta は自分専用ツールで止めるのはもったいない。同じ「書籍リンク貼り替え地獄」を抱えているブロガーは多いはず。GitHub に Public で公開 して、Clone ボタン1つで誰でも使える状態にした。

公開URLは:

GitHub - fukuokacolor-web/mdcta: Turn one Markdown marker into a side-by-side Amazon + Rakuten CTA block.
Turn one Markdown marker into a side-by-side Amazon + Rakuten CTA block. - fukuokacolor-web/mdcta
github.com

リポジトリ作成は GitHub CLI(gh)で全自動化した。

winget install GitHub.cli
gh auth login --hostname github.com --git-protocol https --web
gh repo create mdcta --public --source=. --remote=origin --description "Turn one Markdown marker into a side-by-side Amazon + Rakuten CTA block."
git add .
git commit -m "Initial commit: mdcta v0.1.0"
git push -u origin main

README.md には、Quick Start、マーカー記法、楽天URL組み立ての仕組み、ASP規約配慮の注意書きを書いた。「amzn.to 短縮URLは Amazon管理画面で生成したものをそのまま使う(=他人のタグを流用すると規約違反)」「MOSHIMO_A_ID は自分のもしもアカウントのIDを使う」「自己クリックは ASPによっては成果無効化や垢BANの対象」 といった運用ルールも明記した。

7. つまずきの記録 ── 認証エラーとハイフンの罠

実装はスムーズに進んだが、GitHub CLI の認証で2回つまずいた。

つまずき1:ハイフンを type してしまった

gh auth login --web を実行すると、ワンタイムコードが表示される(例:DE3C-61DA)。これをブラウザの https://github.com/login/device に貼り付けるフロー。

最初、私は DE3C-61DA のまま9文字を input box に流し込んだ。結果は 「あらら、何も見つからなかった」。コードのフォームは8文字を期待していて、ハイフンは UI 上のセパレータでしかないのに、type で送ったせいで分配が崩れていた。

正解は、ハイフンを抜いて DE3C61DA の8文字をそのまま type する。これだとフォームが文字を1つずつ自動分配して、ハイフンは UI 上で表示されるだけ。「目に見える区切り文字 = 入力すべき文字」とは限らない という小さな学び。

つまずき2:Authorize ボタンが効かない

コード入力に成功して「申請を承認する」画面に進んだあと、緑色の「GitHubを認証してください」ボタンを click しても、画面が遷移しなかった。Chrome MCP の座標ベースクリックが、ボタンの位置をズレて押していた可能性が高い。

JavaScript で直接 click イベントを発火する形に切り替えると、無事に通った:

const btn = Array.from(document.querySelectorAll('button'))
  .find(b => b.textContent.trim() === 'GitHubを認証してください');
btn.click();

ボタンの outerHTML を見ると data-octo-click="oauth_application_authorization" という属性が付いていた。GitHub 内部でクリックをトラッキングする属性で、ここを引っかけて発火させる方が確実だった。

8. 関連書籍 ── このマーカーが、いま生成したものです

ここから下の Amazon + 楽天 並列CTAは、原稿に書いた 1行のマーカー を mdcta が展開した結果です(=この記事を公開する時点で、mdcta の最初の本番ユースケースになりました):

{{cta:AI+思考+技法|amzn.to/3OPJMMA|今回の5視点会議の発想も、このスクリプトを設計した思考の流れも、この本に背中を押された。AIを「相棒」として使うための56の技法が一冊に。1人で考えるのが苦手な方や、思考の型を増やしたい方に。}}

これが下のように展開されます(=このページを WordPress に公開した時点で、mdcta を経由して Amazon オレンジ + 楽天 深緑 の縦並列CTAブロックに置き換わります):

📚 関連書籍で深掘りしたい方へ
『AI 思考 技法』
今回の5視点会議の発想も、このスクリプトを設計した思考の流れも、この本に背中を押された。AIを「相棒」として使うための56の技法が一冊に。1人で考えるのが苦手な方や、思考の型を増やしたい方に。
Amazonで中身とレビューを見る ▶
楽天市場でポイント還元を見る ▶
※Amazonアソシエイト・楽天アフィリエイト・PR

9. 次の記事 ── 4日待った AdSense の答え

第15記事末尾で「次は数字の話を一旦離れて、AdSense 審査の合否を待つ4日間」と書いた。実際は4日では足りず、現時点で申請から11日が経っている(=2026年5月10日時点、4月29日申請)。

第18記事は、いよいよ AdSense の合否を書く つもり。承認なら広告ユニット作成と配置の実録、不承認なら理由と修正作業の記録。どちらの結果も、これから始める人の参考になる素材になる。

終わりに

書いていて気づいたが、今回作ったのは単なるスクリプトじゃなかった。

「書籍CTA を貼る作業を毎回手でやる自分」と、「書籍CTA を貼る作業をスクリプトに任せる自分」の境目を、5月10日に通過した。スクリプトを書いた瞬間ではなく、設計を5視点で会議させて、リーダー裁定で7つの選択を確定させた瞬間に、頭の中が「自動化する側」に切り替わったと思う。

100回繰り返す前に、自動化する側に回る。これは Markdown のCTAだけの話じゃなくて、Excel の集計でも、メールの定型返信でも、毎月の経費入力でも、同じパターンが効く。作業の手順を AI に説明できれば、その作業はもう「貼り付ける必要のあるもの」ではなくて「マーカー1個で済むもの」に変わる。

mdcta のコードは GitHub で公開しています。書籍リンクの貼り替え地獄を抱えているブロガーの方は、Clone ボタン1つで自分の .env を作るだけで動きます。何かハマったり、改善案があれば、Issue や Pull Request も歓迎です。

同じ立場で何かを始めようとしている方の、ちょっとしたヒントになれば。

続編記事

タイトルとURLをコピーしました