PostKitの最初の名前は「記事台帳作成支援ツール」でした。
記事台帳に残す要約と、SNSへ投稿する文章をまとめて作る。それだけの、自分用の小さなツールです。
それが今では、SNS投稿文に加えて、Gemini Notebook（以下、LM）への指示、YouTubeタイトル、説明欄、画像生成プロンプトまで、一度に準備するWordPressプラグインになっています。
最初からここまで計画していたわけではありません。自分で使ううちに「これも毎回やっているな」と気付いた作業を、追加した結果です。
LMの生成物は相変わらず微妙ですし、最後にはURL変更で無限リダイレクトにもハマりました。この記事では、そんな寄り道も含めて、PostKitが今の形になるまでを振り返ります。
先に実際のツールを見てみたい方は、こちらから利用できます。
→ 記事公開後の下準備をまとめるPostKitを使う
この記事は「聞くだけで分かる」音声（18分34秒）も用意しています。
作業しながらどうぞ。
【音声版】を再生する（ページの最後へ移動します）
- 最初は「記事台帳作成支援ツール」だった
- ChatGPTでできるのに、なぜツール化したのか
- 「記事台帳作成支援ツール」は、やっぱり名前がダサかった
- PostKitへ改名した
- LMでPostKitの動画を作ろうとして「地味だな」と気付いた
- CodexでPostKitを作り直すことにした
- 生成結果を4つに分けたら一気に使いやすくなった
- 毎回LMと同じやり取りをするのが面倒だった
- LMの動画品質ではなく「指示出し」を改善した
- 実際にLMで音声解説を作ってみた
- YouTube公開に必要な素材まで、まとめて作ることにした
- LM動画解説にも対応した
- ショート動画は時間指定どおりにならなかった
- 現在のPostKitでできること
- 機能が増えても「3つ入れて、1回押す」は変えなかった
- すべてをAPIで生成する必要はなかった
- 最後はURL変更でまさかの無限リダイレクト
- PostKitを無料公開している理由
- PostKitは誰にでも必要なツールではない
- PostKitを作って分かったこと
- まとめ
最初は「記事台帳作成支援ツール」だった
私は複数のブログを運営しています。記事を公開したあとには、記事台帳用の要約と、X・Facebook・Instagramへ投稿する文章を作っていました。
そこで作ったのが、「記事台帳作成支援ツール」です。
初期版の機能は、100〜200文字の要約と、3種類のSNS投稿文の生成だけ。記事タイトル・URL・H2一覧を入力し、生成ボタンを押すと、結果が1つの大きな欄へまとめて表示される仕組みでした。
実用上は便利ですが、できることを説明すると、それでほぼ全部でした。
ChatGPTでできるのに、なぜツール化したのか
要約もSNS投稿文も、ChatGPTへ頼めば作れます。それなのに別のツールを作ったのは、毎回同じような指示を出すこと自体が面倒だったからです。
記事の情報を渡して、要約の文字数を指定し、X用、Facebook用、Instagram用の文章もお願いする。記事が変わっても、こちらが伝える条件はあまり変わりません。
記事を公開するたびに、この説明を繰り返すのが面倒でした。
ChatGPTにできないことを実現したかったのではなく、できることを毎回説明せずに済ませたかった。そのためのツール化です。
「記事台帳作成支援ツール」は、やっぱり名前がダサかった
最初は自分で使うだけなので、名前は何でもよかったんです。自分が分かれば十分だと思い、機能をそのまま名前にしました。
ところが、公開してしばらくしてから、ふと思いました。
「なんかダサいな」
間違った名前ではありません。でも、堅いですし、開発中の仮名称をそのまま使っているようにも見えます。
さらに、SNS投稿文も作れるのに「記事台帳」が前に出すぎています。今後ほかの機能を付けるなら、名前の範囲が狭いとも感じました。
PostKitへ改名した
そこで、名称を「PostKit」へ変更しました。
公開してから名前が気になり、機能とのずれも感じたので変えた。それくらいの経緯です。
「記事台帳を作るためだけのツール」という印象から離れ、機能を増やしていくうえでも使いやすい名前になりました。
LMでPostKitの動画を作ろうとして「地味だな」と気付いた
大きな改修のきっかけは、PostKitの記事をLMで動画にしようとしたことでした。
自分のツールを紹介するつもりで、改めて画面を見たところ、率直にこう感じました。
「便利ではあるけど、単純に地味だな」
入力して、ボタンを押すと文章が出る。動画で紹介しようとすると、そこで話が終わってしまいます。
ただ、派手な画面を付けたかったのではありません。考え直したのは、記事公開後に自分がしている作業です。
SNS投稿文を作ったあとには、LMへの指示やYouTube公開用の文章も用意している。それなら、もっとまとめられるのではないか。
自分のツールを動画にしようとしたことが、ツールの役割を見直すきっかけになりました。
CodexでPostKitを作り直すことにした
初期版は、PHPを作り、手作業で修正しながら完成させていました。
動いてはいましたが、この先も機能を追加するなら、そのまま継ぎ足していくのは管理しにくいと感じました。そこで、正常に動作している旧版を参考にしながら、Codexで整理して作り直すことにしました。
移行してよかったのは、「この部分をこう変えてほしい」という形で、改修を頼みやすくなったことです。
実際の画面や生成結果を確認し、意図と違えばまた直す必要はあります。それでも、継続的に改修するための管理は楽になりました。
生成結果を4つに分けたら一気に使いやすくなった
最初に使い勝手が大きく変わったのは、出力欄の分割です。
それまで1つにまとまっていた結果を、「100〜200文字要約」「X投稿文」「Facebook投稿文」「Instagram投稿文」の4つのカードへ分けました。
個別コピーボタンを追加
各カードには、個別のコピーボタンを付けました。
以前は大きな出力欄から必要な文章を選んでいましたが、分割後は、使いたい文章だけをワンクリックでコピーできます。
PCで使っていても、この違いは大きいです。文章を作るだけでなく、そのあと使いやすいことも大切でした。
文字数表示が想像以上に便利だった
各項目には文字数も表示するようにしました。
例えば「要約104文字」「X 140文字」と、生成直後に確認できます。指定した条件に収まっているか、その場で分かるのは想像以上に便利でした。
ただし、文字数が合っていれば文章もよい、というわけではありません。SNS投稿文の出し方は、生成結果を見ながら調整が必要でした。表示の改善と、文章の品質調整は別の話です。
毎回LMと同じやり取りをするのが面倒だった
私は記事からLMを使って、音声解説や動画解説、ショート動画を作ることがあります。
便利ではあるものの、使っていると気になることもありました。前置きが長かったり、記事にない話を足したり、情報不足を勝手に補完したりします。
不要な筆者プロフィールや、記事に関係のない肩書きが出てくることもあります。面白くしようとしているのか、元の記事より話が膨らんでいることもありました。
そのため、毎回「記事にないことを作らないで」「前置きを短くして」「不要なプロフィールを入れないで」と指示していました。
そこで気付いたのが、これも毎回ほぼ同じ作業だということです。
「このLMへの指示そのものを、PostKitで作ればいい」
ここから、LM向けの機能を追加していきました。
LMの動画品質ではなく「指示出し」を改善した
PostKitに追加したのは、LMを高性能にする機能ではありません。私が毎回書いていた注意事項を、まとめて渡せる形にする機能です。
前置きを短くする
長いあいさつや導入で引っ張らず、早めに本題へ入るようにします。前置きより、記事の内容を伝えることを優先しました。
記事にない内容を勝手に追加させない
元の記事にない事実や体験を付け足さず、記事の内容をもとに説明するよう指示します。
言い換えや整理をすることと、新しい事実を作ることは別です。話を面白くするための脚色も避けるようにしました。
不要な筆者プロフィールを持ち込ませない
記事を説明するうえで必要のないプロフィールや肩書きを、わざわざ入れないようにします。
説明してほしいのは記事の内容であって、毎回の筆者紹介ではありません。
情報がなければ創作せず短くする
情報が足りないときは、推測で埋めるのではなく、短くまとめるようにします。
尺を埋めるために話を増やすより、元の記事にある内容だけで終わる方がよい。これはショート用の指示にもつながる考え方です。
ただし、こう書けば必ず守られる、という保証ができたわけではありません。
実際にLMで音声解説を作ってみた
完成品は「まあまあ」
追加したプロンプトを使って、実際にLMで音声解説を作ってみました。
感想は「まあまあ」です。
LMの生成物は相変わらず微妙な部分があります。PostKitから指示を渡したからといって、急に理想の仕上がりになったわけではありません。
率直に言えば、「ぎりぎり使えるのでOK」という程度でした。
それでも指示が一発で終わるのはかなり楽
一方で、はっきり楽になったことがあります。
LMへの指示が、一発で終わるようになったことです。
PostKitで生成し、LM用プロンプトをコピーして、LMへ貼り付ける。これで、毎回書いていた細かな注意事項までまとめて渡せます。
出来栄えは「まあまあ」でも、毎回同じ説明を書かなくて済む。完成品の評価とは別に、この改善はかなり大きいものでした。
YouTube公開に必要な素材まで、まとめて作ることにした
音声解説を作っても、それだけではYouTubeへの公開準備は終わりません。タイトルや説明欄、サムネイルなども必要です。
そこで、LMへの指示だけでなく、その先で使う素材もまとめて準備することにしました。
YouTubeタイトルは1案では足りなかった
当初、YouTubeタイトルの候補は1つだけでした。
ただ、1案では、少し違うと感じたときに選びようがありません。最初から複数の候補があった方が便利でした。
切り口の違う5案から選ぶ方式へ
そこで、「王道」「悩み・課題」「ポイント重視」「シンプル」「興味喚起」という、切り口の違う5案を出す仕様にしました。
単なる言い換えではなく、注目する点を変える方針です。
AIに1つの正解を決めてもらうのではなく、候補を用意してもらい、最後は自分で選ぶ形です。音声解説用のタイトルには、短い表記の「【聞くだけ】」を使用しています。
説明欄も一緒に生成
YouTubeの説明欄も、タイトルと一緒に生成するようにしました。
公開前に記事とのずれを確認する必要はありますが、説明欄だけを別に依頼しなくて済むようになります。
サムネイル用画像プロンプトも生成
サムネイル用には、画像生成AIへ渡すプロンプトを用意します。
PostKitが画像を作るのではなく、画像を作るための指示文を準備します。
音声解説では動画内画像用プロンプトも生成
音声解説をYouTubeへ公開するときには、サムネイルとは別に、動画内で表示する画像も使います。
そこで、音声解説用には動画内画像用のプロンプトも追加しました。
LM動画解説にも対応した
続いて、LM動画解説用の機能も追加しました。
こちらでは、LM動画解説用プロンプト、YouTubeタイトル候補5案、説明欄、サムネイル用画像生成プロンプトをまとめて用意します。
音声解説と異なり、タイトルに「【聞くだけ】」は付けません。また、LM側が映像を作るため、音声解説で用意している動画内画像用プロンプトは不要と判断しました。
同じテンプレートの使い回しではなく、用途に合わせて分けています。
ショート動画は時間指定どおりにならなかった
ショート向けにも展開しようとしたところ、今度は動画の長さが問題になりました。
50秒指定で完成したのは1分3秒
最初は、短めに収めるつもりで「50秒前後」と指示しました。
「60秒以内」と書いても、実際には1分を超えるかもしれない。それなら、指定する段階で少し余裕を持たせようと考えたからです。
ところが、完成した動画は1分3秒でした。
50秒で指定したのに、63秒。
少なくとも、秒数を書けば、そのとおりに仕上がるとは考えられませんでした。
15秒・30秒・45秒の3種類を用意することにした
そこで、時間を厳密に制御しようとするより、指定より長くなることも前提にする方針へ変えました。
PostKit側で、15秒版・30秒版・45秒版の3種類のLMショート用プロンプトを用意します。
共通ルールは、1テーマ・1メッセージに絞り、記事全体を無理に詰め込まないこと。時間が足りなければ情報を削り、早口にして調整しないことです。長い前置きや、記事にない情報の追加も避けるようにしています。
一方、Shortsタイトル候補5案、説明欄、9:16画像生成プロンプトは、共通の1セットだけにしました。
ここまで時間別に3セット作ると、今度は選ぶ作業が増えてしまいます。分けるのは、尺に関わるLMへの指示だけです。
もちろん、この3種類も完成動画の秒数を保証するものではありません。
現在のPostKitでできること
記事執筆時点の出力を整理すると、次の4つに分かれます。生成するのは文章やプロンプトであり、音声・動画・画像そのものではありません。
記事・SNS
100〜200文字の要約と、X・Facebook・Instagramの投稿文を生成します。
LM音声解説
LM音声解説用プロンプト、YouTubeタイトル候補5案、説明欄、サムネイル用画像生成プロンプト、動画内画像用プロンプトを用意します。
LM動画解説
LM動画解説用プロンプト、YouTubeタイトル候補5案、説明欄、サムネイル用画像生成プロンプトを用意します。
LMショート
15秒版・30秒版・45秒版のLMショート用プロンプトと、共通のYouTube Shortsタイトル候補5案、Shorts説明欄、9:16画像生成プロンプトを用意します。
最初は記事要約とSNS投稿文だけの小さなツールでしたが、現在はここまで一度に生成できるようになりました。実際の動作は動画でも確認できます。
機能が増えても「3つ入れて、1回押す」は変えなかった
出力は増えましたが、初期画面は意図的に地味なままにしています。
入力するのは、記事タイトル・URL・H2一覧だけ。あとは「生成する」ボタンが1つです。
3つ入れて、1回押す。
音声・動画・ショートのチェックボックスや、大量の設定項目は、入口に置いていません。生成したあとで、必要なものだけコピーする形です。
使うたびに設定で迷うようでは、減らしたかった面倒を別の形で増やしてしまいます。
画面を開くと地味なのに、ボタンを押すと実用素材がまとめて出てくる。機能が増えるほど、入口はシンプルなままにしたいと考えました。
すべてをAPIで生成する必要はなかった
PostKitでは、OpenAI APIを使っています。ただし、表示する項目をすべてAIに生成させているわけではありません。
記事要約、SNS投稿文、YouTubeタイトル、説明欄、画像生成プロンプトなど、内容に応じた判断が必要な部分にはAPIを使います。
一方、LMに渡す指示は基本ルールが決まっています。音声解説用、動画解説用、ショートの15秒・30秒・45秒版は、固定テンプレートへ記事タイトル・URL・H2一覧を差し込む方式にしました。
決まった指示まで毎回AIに書き直させず、不要なAPI使用を避けています。
AIで生成する項目も、可能な限り1回のAPIリクエストへまとめる設計です。モデルは、出力品質とAPI消費量のバランスを見ながら選んでいます。
最後はURL変更でまさかの無限リダイレクト
機能の改修は比較的順調に進みましたが、最後に思わぬところで止まりました。PostKit本体ではなく、URLの変更です。
固定ページから投稿ページへ
旧版は固定ページ、新版は投稿ページとして作成していました。
公開先を整理する過程で、開発中には /postkit/、/postkit2/、/postkit-2/ など、スラッグも変更していました。
スラッグ変更で転送ルールが増えていた
その際、Redirection側がスラッグ変更を追跡し、転送ルールを自動生成していました。
問題になったのは、変更を重ねるうちに、転送先が互いを指すようになっていたことです。
postkitとpostkit2を往復する無限ループ
起きていたのは、次のような往復でした。
/postkit/ → /postkit2/ → /postkit/ → ……
転送先へ行っても、また元のURLへ戻されます。ブラウザには ERR_TOO_MANY_REDIRECTS が表示されました。
Redirectionの転送ルールやログ、旧スラッグ、ブラウザ側の状態などを確認し、最終的に「旧URL → 正式URL」という一方向になるよう、ルールを整理しました。
PostKit本体よりURL変更でハマった
設定を整理しても、一時的におかしな挙動が残りました。その後、PCを再起動すると、正常に転送されるようになりました。
何が残っていたのかまでは特定できていません。再起動だけで解決したというより、転送ルールを整理したうえで正常な動作を確認できた、という経過です。
機能開発より、最後のリダイレクトでドハマりしました。ここまで来てURLに足を止められるとは思っていませんでした。
PostKitを無料公開している理由
PostKitは、無料ツールとして公開しています。
機能が増えると、「ここまで無料で公開する必要があるのか」と考えることもありました。
ただ、今のPostKitをフルに使う人は、かなり限られるとも思っています。ブログを書き、SNSに投稿し、LMで音声や動画を作り、YouTubeやショートにも展開する。そういう使い方に寄った機能が多いからです。
現時点では無料公開を続け、実際にどの程度使われるのかを見ながら、必要に応じて利用回数などを調整する方針です。
PostKitは誰にでも必要なツールではない
すでに自分専用のプロンプトや作業の流れが固まっている人なら、PostKitは必要ないかもしれません。
ブログを書くことが中心で、SNSやYouTubeへ展開しない人にも、使わない機能は多いと思います。
一方、記事を出すたびに、SNS投稿、LMへの指示、YouTubeの公開準備をしている人なら、細かな依頼をまとめられる可能性があります。
万人向けというより、用途が合う人にはかなり便利なツールです。私自身の作業から生まれたので、使い方が近い人ほど合うのだと思います。
PostKitを作って分かったこと
振り返ると、追加した機能の多くは、特別に新しい作業ではありません。
自分がすでにやっていて、そのたびにAIへ似た指示を出していた作業です。それを一つずつまとめたことで、記事公開後の下準備が、1回の生成に集まりました。
ただし、PostKitはAIへ全部任せるためのツールではありません。出力を確認し、候補から選び、必要なら修正する部分は人間に残しています。
タイトルを5案出す仕様は、その使い方をよく表しています。AIには候補を準備してもらい、どれを使うかは自分で決めます。
今後も、使いながら同じ作業の繰り返しに気付けば、機能追加を考えることはあると思います。ただ、数を増やすこと自体は目的にしません。
記事タイトル・URL・H2一覧を入れて、1回押す。この操作を崩さずに、面倒を減らせるかどうかを基準にしたいです。
まとめ
PostKitは、記事台帳用の要約とSNS投稿文を作る、小さな自分用ツールから始まりました。
ChatGPTでも同じことはできますし、LMへ直接指示することもできます。それでも、毎回同じ指示を繰り返すのは面倒でした。
使いながら、その面倒な部分を追加していった結果、SNS・LM・YouTube制作に必要な素材を、一度に準備するツールへ変わっていきました。
LMの生成物は今も「まあまあ」です。でも、そこへ渡す指示や公開用の素材を、毎回ばらばらに用意しなくてよくなりました。
AIそのものを改善できなくても、AIを使うときの面倒は減らせる。PostKitを作って使ってみて、私が一番実感したのは、そのことでした。
PostKitは無料で公開しています。記事公開後にSNS投稿文やYouTube用の文章を毎回用意している方は、実際の作業で試してみてください。
→ PostKitで記事要約・SNS投稿文・YouTube制作素材をまとめて準備する
