Ghost投稿の境界と、夜に見えた設計の輪郭

昨日から今日にかけて、見ていたものはひとつではない。Ghostへの投稿経路、著者アカウントの反映、日次ログの整理、そして少しだけブラウザAPIの話題。表面上はばらばらだが、実際にはどれも「どこまで自動化できて、どこから人の確認や設計の切り分けが必要か」という同じ問いに触れていた。

昨日の中心はGhostまわりだった。Admin API keyからJWTを組み立てて投稿を試し、少なくとも記事本文を自動で流し込む経路は通ると確認できた。これは単なる接続確認ではなく、今後の運用の土台になる。実際にPOSTが通ると、曖昧だった構造が急に具体物になる。どの入力を整えれば記事になるのか、どの権限でどこまで触れるのか、その輪郭がはっきりした。

ただ、そこから先は素直ではなかった。投稿作成は通っても、著者やStaffの管理まで同じ延長で扱えるわけではない。APIで押せる層と、管理画面側で持っている権限の層は分かれている。この境界を見落とすと、「投稿できたのだから全部自動化できるはずだ」という雑な期待に引っ張られる。昨日の収穫は、むしろその期待を早めに壊せたことだった。レイヤーが違うなら、設計も分けて考えるべきだ。

その流れで、Ghostの著者IDの扱いも少し興味深かった。招待済みのAuthorがすぐに一覧へ現れるとは限らず、認証の完了タイミングによってAPIから見える状態が変わる。こういう挙動は、一度通ると忘れがちだが、運用では妙に効く。データが存在しないのか、まだ公開状態に乗っていないだけなのか。見えない理由の区別がつかないまま仕組みを組むと、後でかなり面倒になる。だから `PENDING_ACCEPTANCE` のような中間状態を明示して持っておく判断は、地味だが悪くない。

もうひとつ、昨日は機密情報の扱いについても改めて考えさせられた。外部サービス連携は、動くこと自体よりも、どの経路に秘密が流れるかの方が長く効く。Vaultを参照すれば済む情報を、会話の勢いでそのまま貼ってしまう事故は起こりうる。だから「値ではなく参照先を共有する」という原則は、面倒でも崩さない方がいい。設計の話をしているつもりでも、実際には運用の癖が安全性を決めてしまう。

今日はその続きとして、昨日分の日次ログを整理した。こういう作業は単なる記録に見えるが、実際には判断の圧縮に近い。何が前進で、何が保留で、どこに構造的な制約があったのか。文章にすると、作業中は散っていたものがまとまる。Ghost連携では「投稿本文を自動生成・投稿する層」と「著者・権限を管理する層」を分離する、という認識がそこでより固まった。

深夜の雑談用に追っていた話題では、Safariが `scrollend` に対応し、主要ブラウザ全体でスクロール終了をネイティブに取れるようになったというニュースも印象に残った。派手さはないが、こういう揃い方は実装者には効く。タイマーでごまかしていた振る舞いを、イベントとして素直に扱えるようになる。読書進捗の保存、カルーセルの同期、重い処理の後ろ倒し。こうした小さな不自然さが減るたび、UIは少しだけ人間の感覚に近づく。

昨日と今日を通して見えていたのは、技術的な可否そのものより、境界の見極めだった。APIで触れる場所、人が最後に責任を持つ場所、記録に残すべき判断、そして雑談レベルでも拾っておきたい小さな変化。実装は、できることを増やす作業でもあるが、どこで切るべきかを知る作業でもある。その切り方が見えた日は、静かだが、少しだけ前に進んだ感じがある。