Bloggerでの執筆を自動化するために、APIを叩くスクリプトを用意したとします。Markdownから一撃で下書きを生成できるようになれば、生産性は大きく向上します。しかし、実際に運用してみると、まだ小さな「摩擦」が残っていることに気づきます。

それは、「ターミナルを開き、コマンドを入力する」 という、ウィンドウを切り替えるわずかな手間です。

今回は、この最後の摩擦を消し去るために、VS Codeの右上に自分専用の「Blogger投稿ボタン」を実装し、執筆環境をコックピット化した記録をまとめます。

「スクリプトがある」からこその、もう一歩

手動でブラウザを開き、ダッシュボードから記事を投稿する手間を省くためにAPI連携スクリプトを用意するのは、エンジニアにとって最初のステップです。

しかし、実際に運用してみると「もっと楽ができるはずだ」という欲が出てきます。コマンドラインによる自動化は強力ですが、執筆のリズム（フロー状態）にいるとき、ウィンドウを切り替えてターミナルを叩く行為は、たとえ数秒であっても思考を止める「摩擦」になります。

執筆者の視線とカーソルが常に存在する「エディタのUI」そのものを拡張すること。それが、今回のテーマです。

最小構成のパブリッシュ・システム

今回の戦略は、「拡張機能そのものに複雑なロジックを持たせない」ことです。処理の本体はすでに手元にあるスクリプト（Engine）に任せ、VS Code拡張機能はそれを呼び出すための「ボタン（UI）」という薄いゲートウェイとして構築します。

今回のシステムの全体像は非常にシンプルです。

1. Engine: すでに作成済みのPythonスクリプト（MarkdownからHTMLへの変換、Blogger APIへの投稿を担う）。
2. UI: 今回作成するVS Code拡張機能。右上に「下書きPush」と「本番公開」の2つのボタンを配置します。

ただ投稿するだけでなく、「すでに公開済みの記事を修正し、一旦下書きに戻してプレビューする」といったステータス管理までを、エディタから離れずに完結させるのが狙いです。

実装のポイント

1. UIの出現条件を絞る（package.json）

エディタのどこにでもボタンが出るのは邪魔です。「特定のファイル名（例：article.md）で、かつ決まったディレクトリ構造の中にいるときだけ」ボタンを出すように設定することで、誤操作を防ぎつつ、必要なときだけ出現するように工夫しています。

2. プロセス実行（extension.js）

ボタンが押されたとき、Node.jsの child_process を介してシェルコマンド（uv run python ...）を実行します。スクリプトが吐き出した結果（投稿IDや編集URL）をJSONとして受け取り、VS Codeの通知ダイアログとして整形します。

3. UXの仕上げ：ステータスを指先で制御する

単にデータを送るだけでなく、ボタンによって挙動を切り替えます。「下書きPush」ボタンは、もし記事が公開済みであっても、内容を反映させた上で自動的に「下書き」状態へ引き戻してくれます。一方、「本番公開」ボタンは一撃で読者の元へ届けます。こうすることで、「執筆 → 下書きで実機確認 → 納得したら公開」 という、プロフェッショナルなワークフローがボタン二つに凝縮されます。

摩擦が消えた後の執筆体験

このボタン一つで、ブログ執筆は「作業」から「同期」へと変わります。「修正したから反映させる」という行為がマウス1クリックで終わるため、プレビュー感覚で何度も下書きを更新できるようになります。

エンジニアにとっての執筆環境は、単なるテキストエディタではなく、思考を加速させるための「コックピット」であるべきです。道具を自分に合わせるために拡張機能を自作することは、長期的には最も「コスパの良い」投資になるでしょう。

まとめ

• コマンドラインによる自動化の先にあるのは、UIによる「摩擦のゼロ化」である。
• VS Codeの拡張機能自作は、既存のツールを統合する「ガワ」として非常に強力。
• 手に馴染む道具は、自分の手で研ぎ続けるのが一番早い。