Aboardix

課題

X への継続的な発信は「ネタ探し → 文案作成 → 投稿時間の管理」という3工程に時間を奪われます。書く価値のある素材は議事録やメモとして手元に溜まっているのに、それを投稿の形に整える手間が挟まるせいで発信が続かない、という状態でした。

一方で、この問題を「完全自動投稿」で解こうとすると X の Automation Rules に抵触しやすくなります。自動化ツールは数多くありますが、規約リスクを利用者側に押し付けている設計が少なくありません。

やったこと

Google Drive 上の既存資料（議事録・メモ・下書き）を素材として、AI が投稿案をバッチ生成します。ユーザーはスワイプ UI で非同期にレビューし、承認したものだけが時間指定で X API 経由で投稿されます。投稿後のエンゲージメントは次回の生成にフィードバックされ、生成の傾向が調整されていきます。

設計上の意思決定

完全自動投稿を捨て、ヒューマン・イン・ザ・ループに限定した

• 判断：投稿前に必ず人間の承認を挟む設計に限定した。
• 選択肢：素材から投稿までを全自動で回す構成も検討した。機能としては明確にこちらの方が強い。
• 理由：X の Automation Rules に抵触するリスクを、利用者ではなくプロダクト側で吸収するため。投稿頻度・重複・スパム判定をプロダクト側で強制する仕様にした。
• 結果：「自動化ツール」ではなく「レビュー効率化ツール」という立ち位置に変わり、訴求も設計も一貫させられた。

差別化を機能ではなく連携先の選択で作った

• 判断：素材の入力元を Google Drive（drive.file スコープ）に絞った。
• 選択肢：独自エディタで素材を管理する構成、複数ストレージ対応。
• 理由：投稿の素材はすでに Google Workspace に溜まっている。新しい置き場所を作るほど、素材を移す手間が発生して使われなくなる。
• 結果：drive.file スコープにより、サービスは自分が作成・選択されたファイルしか触れない。権限要求が小さいことがそのまま導入障壁の低さになった。

詰まったところ・失敗

学び

• 外部プラットフォームの規約は、後から注意書きで補うものではなく、制約条件として最初から設計に織り込むもの。仕様で吸収すると訴求まで一貫する。
• 差別化は機能の数ではなく、連携先の選択で作れる。どこにデータがあるかを見れば、プロダクトの入り口は決まる。