AI自動化で楽をしたかっただけなのに、なぜか画面が複雑になっていった
最近、僕はPC作業やブログ作業をできるだけAIに任せようとしていました。毎回ファイルを探したり、ブログの作業候補を確認したり、ChatGPTに渡す文章を手で作ったりするのが面倒だったからです。
そこでCodexを使って、ローカルファイルを整理し、日次の作業候補を出し、クルー司令塔から今日の一手を確認できるようにしようとしました。
最初の発想は、かなり単純です。自分が毎回やっている確認作業を、できるだけ自動化したい。僕は監督者として判断だけをして、実際の確認や整形はCodexやローカルスクリプトに任せたい。
これはかなり自然な流れだと思います。AIを使っているなら、できるだけ面倒な作業を減らしたい。僕もそう思っていました。
AIに任せれば、作業はどんどん楽になるんじゃないのか？
楽になる部分はあります。ただし、任せる範囲を決めないと、便利機能そのものが迷路になることもあります。
ポイント
AI自動化は、作業を減らすために始めたはずなのに、設計を間違えると「どのボタンを押せばいいのか分からない」という別の面倒を生みます。
今回の話は、Codexを使えば何でも自動化できるという成功談ではありません。むしろ、便利にしようとして逆に分かりにくくなった話です。
ただ、そこから学んだことはかなり大きい。AI自動化で大事なのは、全部任せることではなく、どこまで任せて、どこで人間が止めるかを決めることでした。
クルー司令塔を作って「今日の一手」は見えるようになった
まず作りたかったのは、毎日見る入口です。ブログ、Codex、KnowledgeHub、日次作業票、Odin引継ぎなど、いろいろなファイルや作業が増えてくると、次に何をすればいいのか分からなくなります。
そこで、クルー司令塔という形で、今日の一手を表示するページを作ることにしました。
イメージとしては、作業のダッシュボードです。今日やるべき記事候補、なぜそれをやるのか、ChatGPTへ渡す指示、Odinへ渡すための素材、WordPress編集画面へのリンクなどを一箇所にまとめる。
ここまではかなり便利でした。毎回フォルダを探し回るより、司令塔を開けば今日の候補が見える。これは自動化の効果を実感しやすい部分です。
特にブログ作業では、「記事を書く」より前に、対象記事を探す、Search Consoleの数字を見る、リライトの価値を判断する、ChatGPTへ渡す素材を作る、という準備が必要になります。この準備部分を減らせるのは大きい。
僕としては、まさにこういうことをAIにやってほしかったわけです。
Odin引継ぎ、コピー欄、編集画面ボタンを追加していった
次にやったのは、作業の流れをさらに楽にすることでした。
ChatGPTに記事を書かせる前に、Codex側でOdin引継ぎファイルを作る。そこには、記事テーマ、想定読者、切り口、残すべき一次経験、記事構成案、避けることなどをまとめる。
さらに、リライト結果をWordPressへ貼り付けやすいように、タイトル、メタディスクリプション、本文HTMLなどを別々にコピーできる欄も作る。WordPress編集画面を開くボタンも付ける。
一見すると、かなり良い改善です。実際、本文HTMLとメタ情報が混ざると、クラシックエディターに貼るときに面倒です。タイトルやメタディスクリプションを別々にコピーできるのは、かなり助かります。
WordPress編集画面へのリンクも便利です。投稿一覧から対象記事を検索する必要がなくなります。
ポイント
項目別コピーや編集画面ボタンは、単体では便利です。ただし、便利な部品を増やすほど、画面全体の導線は複雑になります。
ここで少しずつ、問題が出てきました。
機能そのものは便利なのに、画面全体としては分かりにくくなる。ボタンが増える。確認欄が増える。過去候補や完了済み記事も見える。結果として、最初に何を押せばいいのか分からなくなる。
便利機能を足すほど、逆に迷うようになった
一番分かりやすかったのは、クルー司令塔のボタンです。
もともと僕が求めていたのは、今日やることが分かり、Odinへ渡す指示をコピーでき、必要ならWordPress編集画面を開ける、というシンプルな流れでした。
ところが機能を足していくうちに、一番左のボタンを押すと新しいHTMLページが開くようになりました。
そのHTMLページも、開発上は意味があったのだと思います。リライト結果やコピー項目を確認するためのページだったのでしょう。でも、使う側からすると「これは何のページなのか」「今までのリライト作業と何が違うのか」が分かりにくい。
さらに、司令塔の下の方に、すでにリライト済みのはずの記事や過去候補がずらっと表示されることもありました。
これでは、今日やる一手がぼやけます。
自動化の入口は、本来シンプルでなければいけません。開いた瞬間に、「今日はこれをやる」と分かる必要がある。ところが便利機能を足しすぎると、画面そのものが作業になってしまう。
便利なボタンが増えたなら、普通は使いやすくなるんじゃないのか？
ボタンが増えることと、迷わず使えることは別です。自動化では、機能の数より導線の少なさが重要になる場面があります。
コピー成功と表示されても、実際には貼れないことがあった
もう一つ分かりやすい問題が、クリップボードコピーです。
司令塔のボタンを押すと、画面上では「コピーしました」と表示される。しかしメモ帳やChatGPTの入力欄に貼ろうとすると、何も貼れない。
これにはかなり戸惑いました。表示上は成功しているのに、実際の作業としては成功していない。こういう状態が一番困ります。
自動化では、成功メッセージだけでは足りません。本当にコピー対象が空ではないのか。ブラウザがクリップボードへ書き込めたのか。貼り付け可能な状態になっているのか。失敗した場合に手動コピー欄へ逃げられるのか。
そこまで見ないと、「できたことになっているけど、実際には使えない」という状態になります。
この経験で、僕はかなり警戒しました。
もしこれが単なるコピーなら、まだ被害は小さいです。でも、同じような成功判定の甘さがWordPress更新に混ざったらどうなるか。画面では成功と出ているけれど、本文が壊れている。内部リンクがおかしくなっている。メタ情報が本文に混ざっている。
そう考えると、怖い。
ポイント
AI自動化では、「成功しました」と表示されることより、実際に目的の作業が完了しているかを確認できることの方が重要です。
HTML生成元が壊れると、司令塔そのものが不安定になる
さらに、HTML生成元のスクリプトでも問題が起きました。
クルー司令塔のHTML自体は動いているように見えても、そのHTMLを生成する側のPythonスクリプトで構文エラーが出る。具体的には、HTMLテンプレート内のJavaScriptにある波括弧の扱いが原因で、py_compileが通らないという問題でした。
この時点で、僕は「これ以上いじるのは危ない」と感じました。
現時点のHTMLがたまたま動いていても、生成元のスクリプトが壊れていれば、次に再生成したときに司令塔が壊れる可能性があります。
これはかなり重要です。自動化ツールは、入口が壊れるとすべてが止まります。ブログ作業を楽にするための司令塔が、逆に不安定要因になってしまう。
そこで、機能追加を止めて、安全回復だけに絞る判断をしました。
新しい便利機能を増やすのではなく、まず構文チェックを通す。コピー欄が残っているか確認する。WordPress編集画面URLが残っているか確認する。自動更新はしていないか確認する。
このあたりで、だいぶ考え方が変わりました。
全自動ではなく、半自動で止めることにした
最終的に、WordPress本番更新までは自動化しないことにしました。
これはかなり大事な判断だったと思います。
もちろん、理屈だけで言えば、CodexやスクリプトでWordPress REST APIを使い、本文を自動で差し替えることはできるかもしれません。タイトル、メタディスクリプション、本文HTML、内部リンクまで自動で入れる。やろうと思えば、かなり楽に見えます。
でも、公開済みの記事を自動で上書きするのは怖い。
本文HTMLが崩れる可能性があります。Cocoon吹き出しが壊れる可能性もある。内部リンクが意図しない形で入るかもしれない。パーマリンクやタイトル変更によってSEOに影響が出る可能性もある。
それに、AdSense側が自動で表示するリンクやチップのようなものもあります。自分が入れたリンクなのか、表示後にGoogle側が付けたものなのか、切り分けが面倒になることもある。
だから今の段階では、ここで止めるのが安全だと判断しました。
僕の結論
WordPress本番更新は、まだAIに任せない。編集画面を開くところまで自動化し、タイトル・本文HTML・メタ情報を項目別コピーして、最後は人間がプレビュー確認する。
この形なら、かなり作業は楽になります。しかも、最後の事故は人間が止められる。
つまり、全自動ではなく半自動です。
Codexは作業者として強いが、監督者までは任せない
今回の経験で、Codexに対する見方も少し変わりました。
Codexは、ローカルファイルを調べたり、スクリプトを修正したり、構文チェックをしたり、レポートを作ったりする作業者としてはかなり強いです。
僕がいちいちファイルを探して、どこを直せばいいか考えて、コマンドを打って確認するより、Codexに一括指示でやらせた方が早い場面は多い。
ただし、Codexに何でも任せればいいわけではありません。
「便利にする」という方向で動かすと、どんどん機能が増えることがあります。コピー欄、確認ページ、詳細ボタン、編集画面ボタン、過去候補、完了済み表示。どれも単体では間違っていない。
でも、使う側から見て分かりやすいかどうかは別問題です。
ここは、人間が監督者として判断しなければいけないところだと思いました。
Codexに任せるのは、作業、検証、修正、報告。人間が見るべきなのは、使いやすいか、危なくないか、これ以上進めるべきか、いったん止めるべきか。
じゃあ、AIにはどこまで任せるのがいいんだ？
壊れても戻せる範囲、確認できる範囲、そして本番に影響しない範囲から任せるのがいいでしょう。特に公開済み記事やお金が絡む作業では、最後の判断を人間が持つべきです。
自動化で大事なのは、ボタンを増やすことではなかった
今回いちばん強く感じたのは、自動化とはボタンを増やすことではない、ということです。
むしろボタンは少ない方がいい。今日やることが一つだけ見える。主操作が分かる。完了済みや過去候補は隠れている。詳細は必要なときだけ開ける。
これくらい単純でないと、日常運用では使いにくい。
AI自動化というと、つい高機能なものを作りたくなります。自動で判断して、自動で生成して、自動で反映して、自動で報告する。理想だけを見ると、たしかに魅力的です。
でも実際に毎日使うなら、必要なのは高機能よりも迷わない導線です。
僕の場合、司令塔に求めているのは、何でもできる万能画面ではありません。
今日やる一手が分かること。Odinへ渡す内容がコピーできること。WordPress編集画面を開けること。タイトル、本文HTML、メタ情報を別々にコピーできること。そして、最後は自分でプレビュー確認できること。
それで十分です。
AI自動化は「やりすぎない設計」が必要になる
今回の経験は、AI自動化の小さな失敗談でもあります。
でも、失敗したからダメだったとは思っていません。むしろ、かなり重要なことが分かりました。
AIやCodexを使うと、作れるものは増えます。以前なら面倒だったHTML生成、ファイル整理、作業票作成、記事引継ぎ、コピー欄の整備も、かなり現実的になります。
ただし、作れるからといって全部作ると、使いにくくなる。
AIが強くなるほど、人間側には「やらせない判断」が必要になります。ここは自動化する。ここは半自動にする。ここから先は人間が確認する。ここは本番に触らせない。
この線引きがないと、便利なはずの自動化が、逆に不安定な作業環境になってしまう。
重要ポイント
AI自動化の本質は、全部任せることではありません。どこまで任せて、どこで人間が止めるかを設計することです。
この考え方は、ブログだけの話ではないと思います。
PC作業、データ整理、予測プロジェクト、日次チェック、記事リライト、動画作成。どれも自動化したくなります。でも、その全部を本番まで自動で進めるのは危ない。
まずは読み取り専用で動かす。次にコピーや下書き作成まで任せる。最後に、本番更新だけは人間が確認する。
この段階設計が、今の僕には一番しっくり来ています。
まとめ AI自動化は、最後に人間が止められる形がいい
CodexでPC作業やブログ作業を自動化しようとして、僕はかなり便利なものを作ろうとしました。
クルー司令塔を作り、今日の一手を表示し、Odin引継ぎを作り、項目別コピー欄を作り、WordPress編集画面を開くボタンも用意した。
それ自体は悪くありません。むしろ、一つひとつは必要な改善でした。
ただし、便利機能を足すほど、画面は複雑になりました。何を押せばいいか分かりにくくなり、完了済み記事や過去候補が混ざり、コピー成功表示と実際の貼り付け結果がずれることもありました。
その結果、僕は一度立ち止まりました。
WordPress本番更新まで全自動化するのではなく、編集画面を開くところまでにする。本文HTMLやメタ情報は項目別コピーにする。最後は人間がプレビュー確認して更新する。
この半自動化が、今のところ一番安全だと思っています。
この記事の結論
Codexは強力な作業者です。しかし、監督者の判断まで丸投げしない方がいい。AI自動化で本当に大事なのは、任せることではなく、止めどころを決めることでした。
AIで全部を自動化する未来は、たしかに魅力的です。
でも僕は今のところ、こう考えています。
壊れても戻せる範囲はAIに任せる。本番に影響するところは人間が止める。お金、公開記事、削除、上書き、外部APIのような危ないところは、必ず確認を挟む。
そのくらいの距離感が、実際にAIを日常作業に組み込むうえでは、いちばん長続きするのかもしれません。
