n8nのGUIは誰が得するんだ？ Codexに操作させて分かった「JSONでよかった」という話
私は自動化が好きです。
面倒な作業はできるだけ自動化したいし、ローカルLLMを動かしたり、自分用のツールを作ったりするのも好きです。
そんな私ですが、以前からどうしても好きになれないものがあります。
n8nのワークフローGUIです。
「ちょっと苦手」くらいではありません。
かなり嫌いです。
そして今回、久しぶりにn8nを使ってみて、
「やっぱり私には合わないな」
どころか、
「Codexにコーディングを任せられる今、このGUIって誰が得するんだ？」
というところまで来ました。
しかも、その結論にたどり着いた代償は、
朝のCodexの5時間枠でした。
以前、n8nには散々苦戦させられた
今回初めてn8nを使ったわけではありません。
以前にも自動化のためにかなり触りました。
最初は便利そうに見えます。
ノードを置く。
線でつなぐ。
条件を設定する。
実行する。
ところが、少し複雑なものを作り始めると、私の場合は一気につらくなりました。
実行。
エラー。
原因がよく分からない。
ノードを開く。
設定を変える。
また実行。
またエラー。
別のノードを見る。
JSONを見る。
認証を見る。
接続を見る。
ようやく、
Success！
が出る。
「やった、動いた！」
と思って確認すると、
全体の中の部品が一つ動いただけ。
次へ進むと、また別のエラー。
この繰り返しでした。
もちろん、プログラムだってエラーは出ます。
でも私にとってn8nは、
エラーを直すためにどこを見ればいいのかが、とにかく分かりにくい。
しかも「Success」が、必ずしも「やりたかったことが成功した」を意味しない。
あまりにも時間と成果が釣り合わないと感じて、それ以来なるべく使わないようにしていました。
それでも今回、またn8nを使った
現在、私はローカルLLMのBONSAIの日本語品質を改善しようとしています。
BONSAIは内容そのものはかなり悪くないのですが、ときどき日本語がおかしい。
たとえば、
physical therapist → 物理療法師
と訳してしまう。
いや、
理学療法士
です。
そこで、専門用語辞書を用意して、
BONSAIの出力
→ 専門用語辞書を参照
→ 自己校正
→ より自然な日本語
という仕組みを作ろうとしています。
その辞書候補を作るために外部APIを使うことにしました。
そしてAPI Credentialは、すでにn8n側に登録してあります。
そこで、
「今回はn8nを使うか」
となりました。
ただし、昔とは大きな違いがあります。
今はCodexがいます。
私がGUIを触りたくないなら、Codexに触らせればいい
以前n8nで消耗した最大の理由は、私自身がGUIと格闘し続けたことでした。
でも今ならCodexがあります。
しかもPlaywright MCPを使えば、Codex自身がブラウザを操作できます。
だったら、
私が嫌いなn8nのGUI操作を、Codexに全部やらせればいい。
そう考えました。
workflowを作る。
Data Tableを設定する。
ノードを開く。
設定を変更する。
実行結果を確認する。
そういう面倒なところはCodexに任せる。
私は最終的に、
Execute workflow
を押すだけ。
これならいける。
そう思いました。
CodexにGUI操作を任せても、結局n8nだった
CodexはPlaywright MCPを使って、実際にn8nを操作していきました。
今回必要なのは、
未処理候補の取得
batch処理
API呼び出し
JSONの検証
結果の保存
API使用量と費用の記録
二重処理の防止
retry
途中停止からの再開
といった仕組みです。
ある程度できたところで、Codexから、
「Execute workflowを1回押してください」
と言われました。
それくらいならできます。
押しました。
エラー。
Data Table自体は存在するのに、workflow側から正しく参照できていませんでした。
表示されたのは、
data_table_user_undefined
というエラー。
なんだそれ。
Codexに直してもらいます。
再び、
「Execute workflowを1回押してください」
と言われます。
押しました。
今度は緑色。
Success！
よし。
やっと動いた。
……と思いました。
「Success」なのに、何も処理されていなかった
Codexが実行結果を確認しました。
すると、
テスト用に入れた2件が、どちらもpendingのまま。
API呼び出しもなし。
状態遷移もなし。
実行時間はわずか数十ms。
つまり、
n8n上ではSuccess。
でも、
目的の処理には入ってすらいない。
これを見た瞬間、
「そうだった。私がn8nを嫌いになったの、これだった」
と思い出しました。
昔も何度も、
エラーを直す
→ やっとSuccess
→ でも実際には全体のごく一部しか動いていない
を繰り返しました。
今回はその操作をCodexに任せただけで、構造そのものは何も変わっていませんでした。
今回は、私ではなくCodexの枠が削られていく
昔は、n8nに私の時間を吸われていました。
今回は、
Codexの利用枠まで吸われています。
ブラウザを開く。
ノードを探す。
クリックする。
設定を見る。
保存する。
実行する。
結果を見る。
また別のノードを開く。
Playwright MCPでこれを繰り返しているうちに、Codexの5時間枠がどんどん削られていきます。
これはかなりもったいない。
Codexには、もっとやってほしいことがあります。
BONSAIそのものの改善。
自作ツール。
検索システム。
ローカルAI環境。
画像生成や動画生成。
それなのに今やっているのは、
「なぜこのData Tableをこのノードから参照できないのか」
の調査です。
そこで、ふと思いました。
そもそも、なんでCodexにGUIを操作させているんだ？
Codexを使っていて、初めて「躓いた」と感じた
ここは今回、かなり印象に残りました。
私はこれまでCodexにいろいろなことを任せてきました。
自作ツールを作る。
既存のコードを修正する。
Linux環境を触る。
ローカルAI環境を整える。
もちろん途中でエラーが出たり、修正が必要になったりすることはあります。
でも、基本的には前へ進みます。
Codexを使っていて、ここまで「進まない」と感じたのは今回が初めてでした。
しかも躓いたのは、難しいアルゴリズムを書いているところでも、ローカルLLMを動かしているところでもありません。
GUIを操作しているところでした。
これはかなり象徴的でした。
私は、
「このGUIは私には使いにくい。でもCodexなら代わりに操作できるだろう」
と思って任せました。
ところが、そのCodexまでGUI操作とそのデバッグに時間を取られている。
人間である私が使いにくいからAIに任せたのに、
そのAIまで躓くこのGUIって何なんだ。
そう思いました。
GUIじゃなくてJSONでよかった
ここで方針を考え直しました。
n8nのworkflowは、結局データとして表現できます。
だったら、
CodexにworkflowのJSONを直接扱わせればいい。
JSONを生成する。
JSONを修正する。
diffを見る。
検証する。
必要ならn8nへImportする。
これならCodexの得意分野です。
もっと言えば、n8n自体が必要ない処理なら、
普通にPythonを書かせればいい。
ここでようやく気づきました。
今回私は、
コードやJSONを扱うのが得意なAIに、人間向けGUIをPlaywright MCPで操作させていた
わけです。
ものすごく遠回りです。
人間にもAIにも使いにくい、この形は何なんだ
GUIというのは、本来なら複雑なものを人間に分かりやすくするためのものだと思います。
でも今回のn8nでは、私には逆に感じました。
JSONなら、
どのIDが設定されているか
を文字として確認できます。
コードなら、
どの条件でどの分岐へ入るのか
を追えます。
Gitなら変更前後のdiffも見られます。
Codexも直接読めます。
ところがGUIでは、
ノードが線でつながっている。
見た目は正常。
実行結果も緑色のSuccess。
でも、
実際にはpendingのデータを一件も処理していない。
だったら、視覚化したことで本当に分かりやすくなっているのか。
少なくとも私にはそう思えませんでした。
そして人間の私が使いにくいからAIに任せたら、AIにとってもJSONやコードの方が扱いやすかった。
だからこそ疑問に思います。
人間である私にも使いにくく、ましてAIにとってすら使いにくい、この形は一体何なんだ？
Codexがいる今、このGUIは誰が得するんだ？
以前なら、
コードを書けない
→ GUIでworkflowを作る
という発想には意味があったのだと思います。
でも今は、
コードを書けない
→ Codexに書かせる
ができます。
私はPythonを全部自分で書けなくてもいい。
JSONを全部手作業で書けなくてもいい。
自然言語で、
「こういう処理にして」
と頼めばいい。
AIが書く。
AIがテストする。
AIがログを読む。
AIが修正する。
コードならdiffも残ります。
そういう環境がすでにあるのに、
なぜ一度それを箱と線のGUIに変換して、さらにAIにそのGUIをクリックさせるのか。
かなり本気で思います。
Codexにコーディングを任せられる現状、このワークフローGUIは一体誰が得するんだ？
少なくとも私は得していません。
そして今回、CodexにとってもGUIよりJSONやコードの方が自然でした。
私が欲しいGUIは「作るためのGUI」ではなく「使うためのGUI」
ただし、GUIそのものが嫌いなわけではありません。
むしろ、自分用のGUIは欲しい。
たとえば今回なら、
BONSAI 日本語改善
未処理：108件
処理済み：0件
API使用額：$0.00 / $1.00
［辞書候補を生成］
これくらいで十分です。
私はボタンを押す。
裏で処理する。
結果を見る。
エラーが出たら、AIがコードとログを読んで直す。
私が欲しいのは、
使うためのGUI
です。
欲しくないのは、
実装そのものを箱と線で組み立て、それを保守するためのGUI
です。
画像生成でも似た方向へ進んでいます。
ComfyUIはバックエンドとして使う。
普段は自分用の簡単なUIから操作する。
裏側の複雑なworkflowは見えなくていい。
この形の方が私には圧倒的に楽です。
そして、ようやくJSONへ切り替えたところで5時間枠が尽きた
ここまで来て、ようやく方針を変えることにしました。
もうPlaywright MCPでn8nのGUIを追いかけるのはやめる。
CodexにはJSONを直接扱わせる。
必要ならコードを書く。
AIが得意な方法で仕事をさせる。
CodexもJSONベースへの方針転換を開始しました。
ようやく、
「最初からこっちでよかったじゃん」
という方向へ進み始めました。
そのときです。
Codexの5時間枠が尽きました。
……。
朝の時間を使って、
BONSAIの日本語改善基盤を作ろうとして、
CodexにPlaywright MCPでn8nを操作させて、
エラーを調べて、
直して、
また実行して、
ようやくSuccessになって、
でも実際には何も処理されていないことが分かって、
最後に、
「GUIじゃなくてJSONでよかった」
と気づく。
JSONへの方針転換を始める。
そして、
そこで5時間枠終了。
さすがに、
何をやっているんだろう。
と思いました。
昔はn8nに私の時間を持っていかれました。
今回は、
Codexの枠まで持っていかれました。
ノーコードの次は「AIにコードを書かせる」なのかもしれない
ノーコードは、
人間がコードを書かなくてもシステムを作れる
という考え方でした。
でも今は、
人間がコードを書かなくても、コードでシステムを作れる
ようになってきています。
AIが書いてくれるからです。
これは似ているようで、かなり違います。
コードを消す必要はない。
人間がコードを書かなければいい。
AIがコードを書く。
AIが読む。
AIがテストする。
AIが直す。
人間は自然言語で指示する。
そして人間が日常的に触るところだけ、シンプルなGUIを載せる。
私はこの形の方がずっと好きです。
おわりに
以前、私はn8nに散々苦戦しました。
意味の分からないエラー。
ようやくSuccess。
でも動いたのは部品一つ。
あまりにもコストパフォーマンスが悪く感じて、なるべく使わないようになりました。
今回、APIを使う必要が出てきたので久しぶりに戻ってきました。
でも今回はCodexがいる。
Playwright MCPでGUI操作まで任せれば大丈夫だろう。
そう思いました。
そして、Codexをかなり使ってきた中で、初めてと言っていいほど躓きました。
それも、
コードではなくGUIで。
結果として分かったのは、
AIにGUIを操作させれば問題が解決するわけではない
ということでした。
むしろ逆でした。
GUIをAIに操作させるのではなく、GUIを飛ばしてAIにJSONやコードを直接扱わせればよかった。
人間である私にとって使いにくいからAIに任せた。
ところが、そのAIにとってすらGUIよりJSONやコードの方が扱いやすい。
だったら、
人間にも使いにくく、ましてAIにとってすら使いにくい、このワークフローGUIという形は一体何なんだ？
Codexに普通にコーディングを任せられる今、
このGUIは一体誰が得するんだ？
私はかなり本気でそう思っています。
そして今回、それに気づいた代償は、
朝のCodexの5時間枠でした。
次の枠では、もうPlaywright MCPでn8nの箱を追いかけるところから始めたくありません。
JSONの続きから始めます。
……と書いたのだが、その後実際にJSON中心へ切り替えた。
めちゃくちゃ順調に進んだ。
E2Eが通った。APIが呼ばれた。二重処理も防げた。そのままBONSAIの日本語改善レイヤーまで実装され、A/B/C比較テストまで進んだ。
朝あれだけ苦戦していたのは、Codexの能力不足ではなかったらしい。
CodexにGUIを触らせていたのが悪かった。
JSONに戻したら、いつものCodexに戻った。
