AIにnoteの記事をアップしてもらう。
言葉にすると、とてもラクそうです。
ところが、実際にやってみると一つ困ることがありました。
AIがブラウザを操作している間、ぼくが同じMacを使いにくくなるのです。
マウスが動き、画面が切り替わり、クリップボードも使われる。
記事を任せているはずなのに、その間は自分の仕事が止まってしまいます。
そこで今回は、Codexがnoteへ記事のデータを直接送り、画面を開かずに投稿できるのかを試しました。
note投稿のたびMacを取られていた

これまでの方法では、AIがぼくのChromeを人間の代わりに操作していました。
本文を入れる。
見出しを大きくする。
画像を一枚ずつ入れる。
アイキャッチやハッシュタグを設定する。
こうした作業を画面上で進めてくれるので、仕組みとしては分かりやすいです。
ただし、AIが作業している間は、その画面をぼくが使えません。
ゲームでいえば、自動戦闘を選んだのに、戦闘が終わるまでコントローラーを返してもらえない状態です。
任せられることは増えたのに、待ち時間まで増えてしまう。
ぼくが解決したかったのは、投稿作業そのものより、この待ち時間でした。
画面を使わない方法は2つあった

調べてみると、画面を占領せずにnoteへ投稿する方法は、大きく二つありました。
一つ目は、noteの内部通信を使って、記事の情報を直接送る方法です。
とても速い一方で、noteには現在、だれでも使える公式の公開APIがありません(note公式)。
そのため、note側の仕組みが変わると急に動かなくなる可能性があります。
二つ目は、ぼくのChromeとは別に、AI専用のブラウザを裏で動かす方法です。
こちらは、人間が画面でしていた投稿作業を、見えない別の作業台で再現します。
今回は、ぼくの画面をまったく使わない一つ目を選びました。
今回は画面を使わない直接通信を選んだ

今回使ったのは、保存済みのログイン情報を使い、Codexからnoteへ記事データを直接送る方法です。
大事なのは、いつものChromeを遠隔操作しないことです。
本文や画像は、画面上のボタンを押す代わりに、noteの編集画面が使っている通信と同じ形で送ります。
ぼくは普段のChromeで別の仕事を続けられます。
実装の参考にした公開ツールにも、下書き作成、アイキャッチ、公開の処理がありました(GitHub)。
ただし、公開されている道具をそのまま入れたわけではありません。
見出しや太字が崩れていないか、画像が本当に入ったか、公開が完了したかを検査する処理を加えて試しました。
自分のAIエージェントへ頼むときのプロンプト
同じ仕組みを自分のAIエージェントへ頼みたい人は、次の文章をそのまま渡せます。
このパソコンで、noteへ記事を投稿するときに、私が普段使っているブラウザやマウスを占領しない仕組みを作ってください。
投稿先のnote IDは「[ここにnote ID]」、表示名は「[ここに表示名]」です。
投稿する記事フォルダは「[ここに記事フォルダの絶対パス]」です。
最初に、noteが公式の投稿方法を提供しているか確認し、公式の方法があれば最優先で使ってください。公式の方法がない場合だけ、現在のnote編集画面が使っている通信を調べ、安全に実現できるか判断してください。
実現できる場合は、このnoteアカウントだけに使う専用の認証情報を用意し、ほかのアカウントと混ざらない安定した場所へ保存してください。パスワードや認証情報の中身は、チャット、ログ、記事、スクリーンショットへ表示しないでください。ログインや確認コードの入力が必要なら、私が入力するところで止まってください。
記事フォルダのindex.mdとassetsフォルダを読み、本文、本文画像、アイキャッチ、タグをnoteへ送ってください。
書き込み前と公開後に、note IDと表示名が指定した投稿先と完全に一致していることを確認してください。
公開後は、公開URLを開き、パソコン表示とスマホ幅390pxの両方で確認してください。タイトル、投稿者、大見出し、各大見出し直下の画像、アイキャッチ、タグ、段落を検査し、画像が実際に読み込まれたことまで確認してください。
途中で失敗した場合は、同じ記事を新しく作り直さないでください。下書きIDとエラーを残して止まり、Computer Useや普段のChrome操作へ勝手に切り替えないでください。
動作が確認できたら、今回の手順を担当フォルダのAGENTS.mdまたはCLAUDE.mdへ追記し、次回から同じ方法を使えるようにしてください。関係のない既存ルールは消さないでください。
まずはテスト記事一つで、仕組みの設置、投稿、公開ページの検査まで行い、できたことと残る注意点を報告してください。このプロンプトは、CodexやClaude Codeのように、パソコン内のファイルと通信処理を扱えるAIエージェント向けです。会話だけをするAIでは、仕組みを設置できない場合があります。
この記事そのもので試した

テスト用の短い文章だけを送って成功にするのでは、実際のブログ運用には使えません。
そこで今回の記事そのものを使いました。
タイトル、短い実段落、大見出し、太字、二つのリンク、本文画像、アイキャッチ、ハッシュタグ。
普段の記事で必要になる部品をまとめて入れています。
下書き保存の時点で、見出しの数と画像の数を確認します。
公開後は、公開ページをもう一度読み込み、投稿先がAI黒板になっていることも確かめます。
単に「投稿ボタンを押した」だけでは、成功にはしません。
読者が見るページまで正しく届いて、初めて成功です。
自動化しても最後の確認は残す

画面を使わず投稿できても、確認まで消してはいけません。
画像のアップロードが遅れることがあります。
noteの画面が変われば、ボタンを見つけられなくなることもあります。
だから、入力は直接通信へ任せても、公開ページの検品は残します。
パソコン表示で、タイトル、投稿者、見出し、画像を見る。
スマホ幅でも、文章が詰まっていないかを見る。
この確認まで自動で記録できれば、社長が画面を見張り続ける必要はありません。
AIに仕事を任せる目的は、人間の画面を奪うことではありません。
人間が別の仕事をしている間に、画面の外で仕事を終えてもらうことです。
実際にこの記事も、Codexがこの方法を使って、ぼくの画面を占領せずにnoteへのアップロードと公開まで行っています。








