自社のTechblog（Hugo製）で公開している技術記事を、noteやQiitaにも展開したい——でも「同じ本文を全文コピペ」はSEO/AIサーチ的にもポーティング的にも避けたい。そんな課題を、生成AI（Claude Code）で"サマリー記事"を自動生成し、Qiitaへは公式APIで半自動投稿する仕組みで解いてみました。この記事では、その設計判断を中心に紹介します。
なお、この記事自体も、ここで紹介する仕組みを使ってQiitaに投稿しています。
何を作ったか
- 生成: Techblogの元記事（Markdown）を読み込み、プラットフォーム別のサマリー記事を生成
- note向け: 手動コピペ前提でMarkdownを出力
-
Qiita向け: Qiita API v2 (
POST /api/v2/items) で限定共有の下書きとして投稿
全文転載ではなく「要点だけ載せて元記事へ誘導する」方針にすることで、重複コンテンツのペナルティを避けつつ、各プラットフォームの読者層に合わせた記事を用意できます。
設計の勘所
1. 「生成」と「投稿」を分離する
生成AIが得意なのは要約・文体調整で、API投稿は確実性が命。ここを1つのプログラムに混ぜると、どちらの品質も中途半端になります。そこで:
- 生成はClaude Codeのカスタムコマンド（スキル）に任せ、YAML front matter付きのMarkdownをファイル出力
- 投稿は独立したPythonスクリプトが、そのファイルを読んでAPIを叩く
生成物がファイルとして残るので、投稿前に人間が中身を確認・修正できます。
出力ファイルはそのままAPIに渡せるよう、先頭にfront matterを持たせています。
---
title: "記事タイトル"
tags:
- IoT
- LoRaWAN
private: true
---
（本文Markdown）
投稿スクリプトはこのfront matterをパースし、title / tags / 本文を取り出してAPIペイロードへ組み立てます。Qiitaのタグは1〜5個必須で、APIでは [{"name": "IoT"}, ...] という形なので、そこだけ変換します。
2. 「限定共有の下書き」で人間チェックを挟む
Qiita API には純粋な下書きエンドポイントはありませんが、private: true（限定共有）で投稿すれば実質的な下書きになります。フローはこうです。
- 生成 → ファイル出力
-
--dry-runでAPIペイロードを目視確認（トークン不要） -
private: trueで投稿（自分だけが見えるURLが返る） - Qiita上で最終確認 → 手動で公開ボタン
private の値はfront matterではなくCLIフラグ（--publish 指定時のみ公開）で決めるようにして、「うっかり全世界公開」を防いでいます。
3. 秘密情報とエラーの扱い
- トークンは
.env（gitignore済み）から読み、ログにもdry-run出力にも出さない - front matterが不正／タグ0個／HTTPエラーは、握りつぶさずメッセージ付きで異常終了
地味ですが、CLIツールは「失敗したときに理由が分かる」ことが実運用では効きます。
実際の使い勝手
コマンド1つでサマリーが生成され、--dry-run で中身を確認してから投稿できます。
python qiita_post.py output/xxxx-qiita.md --dry-run # 投稿せず確認
python qiita_post.py output/xxxx-qiita.md # 限定共有で投稿
note用とQiita用でガイド（生成ルール）を分けているのもポイントです。noteは親しみやすさ重視、Qiitaはエンジニア向けに技術的な要点を一段深く——同じ元記事でも読者に合わせて書き分けます。
まとめ
- 生成AIによる「要約」と、API による「投稿」を分離すると、それぞれの品質を保ちやすい
-
private: trueを下書き代わりにして人間チェックを挟むと、自動化と安全性を両立できる - 秘密情報は
.env、エラーは明示——CLIツールの基本を押さえると実運用に耐える
まずはこの記事を第一号として、効果を見ながら運用していく予定です。同じように「オウンドメディアの記事を複数プラットフォームへ展開したい」方の参考になれば幸いです。