自動化の進化：ShellスクリプトからAI組織へ

技術は変わっても、基本の取引は変わらない。一度投資しておけば、同じ作業を永遠に繰り返さずに済む。

私は長いことソフトウェアを作ってきたが、その間ずっと自動化について驚くほど変わらないことが一つある。技術は変わるが、理屈は変わらない、ということだ。同じことを繰り返している自分に気づいたら、たいていどこかで、先に時間をかけて自動化するほうが得になる地点が来る。

1900年代の終わりごろなら、それはシェルスクリプトを書くことだったかもしれない。大量のファイル名を変える、決まった手順でデータを処理する、システム間でコピーする、同じコマンドを何度も打つ。手作業を続けることもできたし、時間をかけて一度スクリプトにすることもできた。スクリプトを書くほうが、その作業を一回やるより時間がかかることもある。だがそこは問題ではない。見返りは、それ以降のすべての繰り返しからやってくる。

この基本の等式は変わっていない。変わったのは、私たちが自動化できる対象の規模のほうだ。

まず、タスクを自動化した

私が最初に扱った自動化は、小さくて局所的なものだった。シェルスクリプトが一連のコマンドを置き換えた。cron ジョブが決まった時刻に何かを起こした。Perl や Python のスクリプトが、繰り返しの多い作業を再現可能なものに変えた。

典型的な例はこういうものだ。

• 大量のファイルをまとめてリネーム・移動する
• 毎回同じやり方でデータを処理する
• システム間でファイルをコピーする
• 繰り返しのデプロイコマンドを実行する
• 定期メンテナンスのジョブをスケジュールする

抽象化の中身は単純だ。コンピュータに何をさせたいかは正確にわかっているし、それを十分な精度で記述できる。そして自分が永遠にやり続けるより、一度きり教え込むほうに時間を使いたい。手作業なら五分で終わるタスクの自動化に二時間かけることもある。一度しかやらないつもりなら馬鹿げて見えるが、何百回、何千回とやるつもりなら答えは明らかだ。

ソフトウェアシステムが複雑になるにつれ、この同じパターンが繰り返された。

次に、インフラを自動化した

クラウドは、スクリプト化できる範囲を押し広げた。マシン上のタスクを自動化するのではなく、マシンそのものの作成と設定を自動化するようになったのだ。

Terraform はインフラをコードとして記述させてくれた。Kubernetes は分散アプリケーションがどう動き、スケールし、再起動し、通信すべきかを記述させてくれた。CI/CD はソフトウェアがソース管理から本番へ移る過程を自動化した。

従来なら相当な手作業の運用を要したものが、突如として宣言し、再現できるものになった。

• サーバー
• ネットワーク
• データベース
• ロードバランサー
• 権限
• アプリケーションのデプロイ
• スケーリングのルール
• 環境そのもの

かつては人がコンソールをクリックして回り、手作業でシステムを設定し、デプロイを調整していた。それが次第に、バージョン管理し、レビューし、テストし、再現できるものになった。

自動化される対象が大きくなったぶん、初期コストも大きくなった。よいインフラ自動化は十行のシェルスクリプトよりずっと難しい。より多くの検討、より多くの例外処理、より多くのデバッグ、より多くの保守を要する。だが見返りも複雑さと同じだけ大きくなる。環境がきちんと定義されていれば、手作業なら数時間から数日かかっていたシステム一式を、ごくわずかな人手で再現できる。

自動化の原則はまったく変わっていない。私たちは一段上に移っただけだ。

そしていま、ワークフローを自動化している

AI エージェントは、その抽象度をもう一段押し上げようとしている。最初にわかりやすかった使い道は、エージェントを非常に有能なスクリプトとして扱うことだった。タスクを与え、実行させ、結果を受け取る。

それは役に立つが、いま起きていることの捉え方としてはかなり狭い。より大きな変化は、個々のタスクだけでなく、複数の知的な働き手にまたがるタスクの調整までも自動化できるようになったことだ。

現代のエージェント的ワークフローは、たとえばこんな形になる。

• あるエージェントがコードを書く。
• 別のエージェントが実装をレビューする。
• 別のエージェントがテストを走らせる。
• 別のエージェントがセキュリティ上の問題を確認する。
• 別のエージェントが、そもそもの要件が本当に満たされたかを検証する。
• 何かが失敗したときにどうするかは、ワークフローが決める。
• 承認ゲートが、人間を要する部分と自動で進めてよい部分を切り分ける。

その段階に来ると、あなたはもう作業をスクリプト化しているのではない。作業を編成する仕組みのほうをスクリプト化している。これは、手作業のタスク一つを AI のタスク一つに置き換えるのとは比べものにならない飛躍だ。自動化の境界が、実行から調整へと移りつつある。

Orgabot は同じ発想の最新版だ

私は Orgabot をそう捉えている。AI エージェントのオーケストレーションを、それ以前の自動化ツールとはまったく別物だと考えるのは簡単だ。だが抽象的に見れば、私が何十年も使ってきたのと同じパターンにすぎない。

道筋はかなり素直だ。

• シェルスクリプトは、何度も打ちたくないコマンドを自動化した。
• Infrastructure as Code は、何度も設定したくないシステムを自動化した。
• CI/CD は、手で調整したくないデプロイの流れを自動化した。
• エージェントのオーケストレーションは、一歩ずつ管理したくない作業を自動化する。
• Orgabot はそれを、働き手を取り巻く構造そのものの自動化へと押し進める。

違いは規模だ。Orgabot のようなものでは、自動化される対象はもはやコマンドでも、デプロイパイプラインですらない。複数の専門エージェント、権限、レビューゲート、検証ステップ、デプロイのロジックを含む、ソフトウェア開発のワークフロー全体になりうる。

「この機能を作れ」というタスクをスクリプト化する段階から、機能をどう作るべきか、誰が作るべきか、作業をどうレビューすべきか、いつ出荷してよいかを繰り返し判断できる仕組みを定義する段階へ。これはもう開発者を自動化しているというより、組織の一部を自動化しているように見えてくる。

自動化は抽象の階段を上り続ける

振り返ってみると、この道筋は驚くほど一貫している。

• コマンドを自動化した。
• 次に、繰り返しのタスクを自動化した。
• 次に、デプロイを自動化した。
• 次に、インフラを自動化した。
• 次に、パイプラインとワークフローを自動化した。
• いまは、そのワークフローの中で働く担い手を自動化している。
• そしてますます、担い手どうしの調整を自動化しつつある。

一段ごとに、自動化の境界は上へ移る。興味深いのは、どの段階でもそこが頂上のように感じられることだ。インフラがプログラム可能になったときも、抽象化の巨大な飛躍に思えた。AI エージェントがソフトウェアを書き始めたときも、これで自然な終着点に達したと考えるのは容易だった。欲しいものを AI に伝えれば、あとは作ってくれる、と。

だがそれさえ、すでに途中の一段に見え始めている。一つのエージェントに何をすべきか指示するのではなく、どのエージェントが働くべきか、どう協働すべきか、その成果をどう評価すべきか、次に何が起きるべきかを決める仕組みを作っている。ならば当然の問いが出てくる。自動化されたオーケストレーションの上には、何があるのか。

十年後、何がスクリプト化できるようになるのか

このパターンが続くなら、次の抽象は、いま私たちがワークフローと呼ぶどんなものよりはるかに大きいかもしれない。自動化する単位が、組織まるごとになる可能性もある。

事業上のゴールを述べるだけで、次のような機能の等価物をシステムが組み上げてくれるかもしれない。

• プロダクト開発
• エンジニアリング
• インフラ
• マーケティング
• カスタマーサポート
• 財務
• 法務プロセス
• アナリティクス
• オペレーション

入力はやがて、手順的なものではなく意図的なものになるかもしれない。タスクやワークフローやエージェントを指定する代わりに、「こういうことをする製品があるべきだと思う」といったゴールを口にするだけで、それを現実にするために必要な一切をシステムが割り出す。

ここにはもっと大きな歴史的パターンもある。人とコンピュータのやり取りは、より高い意図の水準へと移り続けてきた。

• 機械語はプログラミング言語になった。
• プログラミング言語はライブラリとフレームワークを得た。
• サーバーはインフラの宣言になった。
• コマンドはプロンプトになった。
• そしてプロンプトはゴールになりつつある。

論理的な行き着く先はこうだ。私たちは「どう起こすか」を記述する時間を減らし、「何が存在してほしいか」を記述する時間を増やしていく。十年後には、エージェントを明示的にオーケストレーションするという発想さえ、原始的に見えるかもしれない。意図を述べるだけで、その下に必要なエージェント、ツール、ワークフロー、インフラ、組織、プロセスの組み合わせを、システムが勝手に組み立てているかもしれない。

極端に言えば、そのインターフェースはプログラミングというより「顕現」に近いものになりうる。何かを思いつき、それを描写し、自動化されたシステムがその意図を現実に変えるのを眺める。大げさに聞こえるだろうが、これまでのどの抽象層も、生まれる前は同じように大げさに聞こえたはずだ。

自動化の経済学は結局変わっていない

いちばん面白いのは、これだけ進歩してもなお、その取引が何十年も前にシェルスクリプトを書いていたころとほとんど同じだということだ。自動化には今も先行投資が要る。プロセスを定義し、仕組みを作り、例外を処理し、失敗をデバッグし、現実が想定と食い違ったときにどうするかを決めなければならない。

手作業は最初こそ楽に見える。その初期投資を避けられるからだ。やがて自動化が回り始め、繰り返しが積み上がり、見返りがはっきりしてくる。

自動化が十行のシェルスクリプトだったころも、それは真実だった。何千行ものインフラ設定になったときも真実だった。AI エージェントのチームを編成し始めたいまも真実だ。規模は増え続けるが、原則はほとんど変わっていない。一度力を注いでおけば、永遠に注ぎ続けずに済む。

そしてこのパターンが続くなら、いちばん面白い問いは、今日何を自動化できるかではない。明日もなお、自動化するには大きすぎると思われるものは何か、である。