自動化って大変だよね

仕事をしていると、業務を自動化したくなる瞬間がよくあります。同じ作業を何度も繰り返していると、これは自動化できるよな～と考え込む。動機としてはとても自然だと思う。

ただ、実際に手をつけてみると、素直なスクリプトでは済まないことばっかりです。例外パターンが次々に出てくるし、環境が違えばほんとに動かない、、、
「自動化って大変だよね」という感想は、たぶん誰もが一度は抱くのかなーと思います。

大変さを、最近は仕事をしながら少しだけ整理できてきた気がするので、書きおこしてみてます。

人間・エージェント・スクリプト の3層

いまの自動化を、自分は一枚岩では考えないようにしています。ざっくり3つの層に分けて捉えています。

• 人間 … 業務を理解し、言語化して、要件に落とす。最終的なUXを仕上げる。責任を持つ。
• エージェント（AI） … あくまでスクリプトの実行者・生成者。指示された範囲を動かし、スクリプトやSkillsに従う。
• スクリプト… 確定した処理。プログラミング的なところに限らず、自然言語で指定したCLI動作やスクリプト処理など

まぁ大事なことはAIに全部を任せるわけではない、というところです。AIはあくまで実行者であって、業務を言語化してコードに落とすのも、出来上がったもののUXを整えてスクリプトをきれいにまとめるのも、責任を持つことも人間の仕事。

そのうえでほんとに難しいのは、この 粒度の落とし込み です。どこまでを人間が決め、どこからをエージェントに渡し、どこをスクリプトとして固めるのか。この線引きこそが実際の作業で、いちばん大変なところだと感じています。

Generative UI 的な捉え方

この感覚、フロントエンドでいう Generative UI（GenUI） の考え方が近いなと思っています。固定のUIを作り込むのではなく、意図や仕様をエージェントが受け取って、その場で組み立てる。宣言的に「何をしたいか」を渡す、という発想です。

GenUI には大きく3つのアプローチがあるようです（参考: AIエージェントがUIを生成する Generative UI を広く浅く理解したい）。

• アプローチ1 : 静的型 … フロントエンドで事前定義したUIコンポーネントをAIエージェントが選択する
• アプローチ2 : 宣言型 … AIエージェントが構造化された仕様（カード・フォーム等）でUIを定義し、フロントエンド側で組み立てる
• アプローチ3 : オープンエンド型 … MCPサーバーが事前定義したHTMLリソースをAIエージェントがツール経由で選択し、iframeとして表示する

自分の自動化でのUIは、基本的には アプローチ1（静的型） を土台にしています。事前に用意した部品をエージェントに選ばせるのが、いちばん安定していて扱いやすいからです。そのうえで、ところどころ宣言型 を混ぜてUIを組み立てる、という感じ。全部を生成に委ねるのではなく、静的を土台にしつつ、必要なところだけ宣言的に

業務自動化も構図は同じで、人間は「何をしたいか」を宣言する側に回ります。実装のかたちは生成に任せ、人間は意図と仕上げに集中する。そんなかんじです。

結局はダッシュボードとの戦い

もうひとつ最近思うのは、自動化は 見やすいUIを備えたダッシュボードとの戦い でもある、ということです。

処理をただ回すだけなら、そこまで難しくありません。難しいのは、その結果を人間が読める形で見せることのほうです。
どれだけ裏側を自動化しても、状態が一目で分かるUIになっていなければ、「自動化できた」の価値は回収できません。
（今のAIは、見やすいUIを考えてくれるところまでは来てないし、センスない、UXは結局人間の手で試行回数稼いで修正しまくる、そんな感じ）

大変さを分解

改めて、大変さを分解して並べてみます。

• 業務を正しく言語化するのが、そもそも難しい。要件定義そのものだから。
  • （というかそもそもまとまってないから、ステークホルダーを巻き込んで一緒に業務を解体すべき）
• 3層の境界を間違えると、AIが大暴走して変なことをするか、固めすぎて融通きかないか、のどちらかに転ぶ
• 生成に任せた部分のUXやまとめ方は、結局のところ人間が引き受けることになる

まとめ

何でもかんでも自動化する、ではなく、3層のどこに置くかを見極めること。それがいちばんの肝だと、いまは思っています。

とはいえ、その粒度の決め方は、正直まだ自分の中でも模索中です。事象ごとに最適な線引きは変わるし、これという正解もまだ見えていません。

しばらくは手を動かしながら、この感覚を育てていこうと思います。