Jenkinsはジョブをつないだ。WindmillはAIの職場をつくる。

AIエージェントやWindmillのような新しいワークフロー基盤を見ていると、ふと疑問が湧きました。
「昔からあるJenkinsって、結局何をしていたんだろう？」

私は名前こそ知っていましたが、実際に使ったことはありませんでした。
CI/CDツールというイメージだけがあり、「ビルドを自動化するソフト」という程度の理解でした。
しかし調べていくうちに、Jenkinsは現在のAIエージェント時代を理解するための、とても重要な出発点だったことに気付きました。

自動化とは、プログラムを書くことだった

若い頃、私にとって自動化とはプログラムを書くことでした。

それだけでも十分に高度な自動化でした。
しかし今振り返ると、本当に自動化していたのはプログラムではなく、
「処理の流れ」
だったのだと思います。

Jenkinsは何を書いていたのか

私は長い間、
「Jenkinsの中にプログラムを書く」
ものだと思っていました。
しかし実際は違いました。
Jenkinsが管理していたのは、
どの処理を、どの順番で実行するか。
例えば、

という一連の流れです。

実際の処理はShellやPythonなど既存のプログラムが担当します。
Jenkins自身は、

「これが終わったら次へ」
「失敗したらメール」
という接続だけを管理していました。

つまりJenkinsは、
プログラムを書く場所ではなく、ジョブを接続するハーネスだったのです。

後に登場した「Pipeline as Code（Jenkinsfile）」も、
アルゴリズムを書くものではありません。
書いていたのは、
ワークフローそのものでした。

Windmillは少し違う

最初、私はWindmillを
「Jenkinsの新しい版」くらいに考えていました。
しかし調べてみると、その理解は少し違っていました。
Windmillが登場し、大きく成長した時期は、
ChatGPT以降のLLM時代とほぼ重なっています。
最近の開発を見ると、

など、AIを前提にした機能が中心になっています。
つまりWindmillは、
単なるジョブ管理ツールではありません。

LLM時代に合わせて再設計されたワークフロー基盤
なのです。

接続する対象が変わった

自動化の歴史を振り返ると、
接続する対象が少しずつ変わってきました。

第1世代

プログラムを接続する。
Shell、Perl、cronの時代です。

第2世代

ジョブを接続する。
Jenkinsが代表です。

第3世代

サービスを接続する。
Node-REDやn8nのように、APIやクラウドサービスをGUIで組み合わせる時代です。

そして現在

Windmillが接続しているのは、
PythonやTypeScriptのような言語だけではありません。

AIモデル、
MCP、
Gitリポジトリ、
Secrets、
Sandbox、
Queue、
Human Approval、
そしてAI Agent。

つまり、
AIが仕事をするための環境全体
を一つのワークフローとして扱っています。

Skillsという新しい部品

LLMの登場で、もう一つ変わったことがあります。昔は、

という処理を書くためにプログラムを書いていました。
今では、

といった能力そのものが、一つのSkillとして扱えるようになりました。
接続する対象は、

そして今、知能そのものへと広がっています。

自動化の本質は変わらない

ここまで調べて、一つだけ確信したことがあります。
自動化の本質は、昔から変わっていません。
変わったのは、
何を部品として扱うか。
だけでした。

AIが働く職場

AIエージェントは、
コードを書く能力だけでは仕事になりません。
どのリポジトリを見るのか。どの権限で動くのか。どのSkillを使うのか。
失敗したら誰に承認を求めるのか。どこに成果物を保存するのか。
そうした「職場」が必要になります。

Windmillは、まさにその職場を作ろうとしているように見えます。
Jenkinsがジョブをつないだ時代から約20年。

いま私たちは、
AIが安心して働ける職場を設計する時代
に入り始めているのかもしれません。
 

#AI #生成AI #LLM #AIエージェント #Jenkins #Windmill
#自動化 #ワークフロー #プログラミング #ソフトウェア開発
#NodeRED #n8n #CI_CD #技術解説