コンピュータの歴史をひと言で表すなら、それは「自動化の歴史」だと言えるかもしれません。人間が紙と鉛筆で行っていた計算を機械に任せることから始まって、大量の事務処理をパンチカードで処理する時代、決まった手順をシェルスクリプトに書く時代、ビルド・テスト・デプロイをパイプラインに流す時代へと、「自動化」は着実に進化を重ねてきました。そして今、AIがコードを書き、修正案を出し、場合によってはタスクの進め方まで提案する時代になっています。もちろん、自動化とは「人間が不要になること」ではありません。むしろ歴史を振り返ると、自動化はいつも人間の仕事を消すだけでなく、人間が考えるべき対象を変えてきたといってよいと思います。今回は、コンピュータ黎明期からAIエージェント時代までの自動化の大まかな時代の流れを見ていきます。
- もくじ
1. コンピュータの原点は「手作業の自動化」だった
1-1. 計算という作業を機械に任せるという発想
コンピュータの原点には、「面倒で間違いやすい計算を、人間の代わりに機械へ任せたい」という発想があります。現代の私たちは、表計算ソフトやプログラムで一瞬にして合計や平均を出すことができます。しかし、かつて計算は人間の手作業でした。帳簿をつける、天体の位置を計算する、人口統計をまとめるといった作業はどれも膨大な時間がかかり、入力ミスや計算ミスがつきものだったのです。
ここで重要なのは、コンピュータが最初から「知的な機械」として登場したわけではないことです。最初に期待されたのは、もっと素朴な役割でした。つまり「決められた手順を、速く、正確に、何度でも実行する機械」でした。19世紀、チャールズ・バベッジが構想した「差分機関（Difference Engine）」は、航海や数学で使用される数表の誤りを減らすため、計算を機械化しようとしたものでした。また「解析機関（Analytical Engine）」は、より汎用的な計算機の構想として知られています。
Difference Engine | Calculating Machine, Charles Babbage | Britannica
計算という知的なプロセスを物理的な歯車の動きに変えて「自動化」しようとする試みは、現代のデジタル計算機の論理的な基礎を築きました。コンピュータの歴史は、この「繰り返しを機械に任せる」という小さな発想から始まり、やがて社会全体の業務や開発プロセスを変える巨大な流れへと発展していくことになります。
1-2. パンチカードとバッチ処理
自動化の歴史を語るうえで外せないのが、パンチカードでしょう。パンチカードとは、紙のカードに穴を開け、その穴の位置によって情報や命令を表す仕組みです。IBMの歴史資料によれば、パンチカードは政府の統計処理や記録管理などで広く使われ、1935年の米国社会保障局の契約では、大量のパンチカードと集計機が社会保障制度の事務処理を支えました。
パンチカードの面白さは、情報を「物理的な形」にして機械へ渡していた点です。今ならプログラムはテキストファイルで書き、クラウド上のリポジトリに保存します。しかし当時は、穴の開いたカードの束が、データであり、命令であり、処理手順でもありました。カードを順番に読み込ませることで、機械は人間が一つひとつ指示しなくても処理を進められます。
その見た目には大きなインパクトがあり、古い特撮映画などにコンピュータが登場すると、高い確率でパンチカードも映し出される傾向があったようです。
このころ発想された重要な考え方が、バッチ処理です。バッチ処理とは、作業をその場で一件ずつ対話的に処理するのではなく、あらかじめ処理対象をまとめておき、機械に一括で実行させる方法です。
たとえば、昼間に入力された売上データを夜間にまとめて集計する、給与計算を月末に一括処理する、といったイメージです。バッチ処理は、現代のエンジニアにとってもなじみのある概念です。夜間ジョブ、定期実行、ログ集計、データパイプラインなどは、考え方としてはこの延長線上にあります。パンチカードの時代からすでに、人間は「その場で毎回操作する」のではなく、「機械がまとめて処理できる形に作業を設計する」方向へ進んでいたことになります。
1-3. メインフレーム時代とジョブ管理
パンチカードや初期の計算機の時代を経て、1950年代から70年代にかけて、企業や政府機関ではメインフレームと呼ばれる大型コンピュータが使われるようになりました。金融、保険、行政、製造業など、大量のデータを正確に処理する必要がある分野で活躍したこのメインフレーム時代に重要になったのが、ジョブ管理です。
ジョブとは、コンピュータに実行させる仕事の単位のことです。たとえば「データを読み込む」「集計する」「帳票を出力する」「バックアップを取る」といった処理が、それぞれジョブになります。メインフレーム時代には、こうしたジョブをどの順番で実行するのか、前の処理が成功したら次へ進むのか、失敗したら止めるのか、といった流れを管理する必要がありました。これは単に「計算を自動化する」段階から一歩進んでいます。処理単体ではなく、処理の流れ全体を機械に任せるようになっています。
今で言えば、ワークフローエンジンやジョブスケジューラ、CI/CDパイプラインに近い発想です。Aが終わったらBを実行し、Bが成功したらCへ進む。失敗したら通知する。こうした制御は、現代のシステム運用でも基本中の基本です。
ここでエンジニアの役割も少し変わります。単に処理を書くのではなく、「どの順番で処理すれば安全か」「異常時にどう止めるか」「再実行できるか」を考える必要が出てきたからです。自動化は便利ですが、流れを誤ると大量の誤処理も高速に実行してしまいます。自動化の歴史は、同時に「失敗したときにどう止めるか」を考える歴史だといってよいと思います。
2. エンジニアは「作業」を自動化してきた
2-1. UNIXとシェルスクリプト
自動化がエンジニア文化として根づくうえで、UNIXの存在は大きな意味を持っています。1970年代に多く使われ始めたUNIXでは、「一つのことをうまくやり、それを組み合わせる」という設計思想のもと、小さなコマンドを組み合わせて大きな処理を作るという考え方が発達しました。
ファイルを探す、文字列を抽出する、並べ替える、集計する。こうした小さな道具をパイプでつなぎ、必要に応じてシェルスクリプトとして保存することで、作業を再利用できるようになったのです。IBM Developerの記事では、Ken Thompsonが1971年にUNIX向けの初期シェルを開発したこと、またその後のシェルがスクリプトによる作業自動化の基盤になっていったことが紹介されています。
シェルスクリプトの価値は、難しいアルゴリズムを書くことだけではありません。むしろ日々の細かな作業を「二度と手でやらない」ための道具である点にあります。たとえば、ログファイルからエラー行だけを抜き出す。複数のファイル名を一括で変更する。バックアップを決まった場所にコピーする。こうした作業は一回だけなら手でやってもよいかもしれません。しかし、二回、三回と繰り返すなら、スクリプト化したほうが安全で速くなります。
UNIXで生まれたのが、「同じ作業を繰り返さない」というエンジニアらしい文化でした。手作業を減らそうとすることは、単なる怠けではありません。むしろ品質を守るための態度です。人間の手作業には、疲労、思い込み、見落としが入り込みます。スクリプト化すれば、少なくとも同じ条件では同じ処理が再現できます。自動化は効率化であると同時に、再現性を高める技術といってよいでしょう。
2-2. ビルド作業の自動化
プログラム開発では、多くのケースでソースコードを書いただけではアプリケーションとしては動きません。コンパイルし、ライブラリをリンクし、必要なファイルを生成する。こうした一連のビルドを経て、実行可能なプログラムやアプリケーションになります。小さなプログラムなら手でコマンドを打ってもよいでしょう。しかし、ファイルが数十、数百と増えると、どの順番で何を再コンパイルすべきかを人間が覚えるのは難しくなります。
そこで登場したのがMakeのようなビルドツールでした。GNU Makeのマニュアルでは、makeは大きなプログラムのどの部分を再コンパイルすべきかを自動的に判断し、必要なコマンドを発行するツールだと説明されています。
Makeの考え方はとても実用的です。「このファイルを作るには、どのファイルが必要か」「その依存元が変わったら、どの処理をやり直すべきか」をルールとして書いておきます。すると、開発者は毎回すべてを手でビルドする必要がなくなります。変更された部分に応じて、必要な処理だけが実行されます。この発想は現代のビルドツール、パッケージマネージャ、タスクランナーにも受け継がれています。エンジニアが作業を自動化するうえで、「依存関係を正しく書く」ことは今も変わらず重要なことなのです。
2-3. テスト・ビルド・デプロイのパイプライン化
開発現場の自動化は、個別作業の自動化から、開発プロセス全体の自動化へ広がっていきます。その代表がCI/CD（継続的インテグレーション／継続的デリバリー）です。CIとは、開発者がコードを頻繁に統合し、自動ビルドや自動テストで問題を早く見つける考え方です。
かつての開発現場では、書いたコードを本番環境へ反映させるまでには、手順書を見ながら人間が慎重にコマンドを打つという、非常に神経を使う作業が伴っていました。もちろん今でも重要なリリースは慎重に行うべきですが、手作業が多いほどミスの入り込む余地も増えます。パイプライン化された開発では、コードをプッシュすると、ビルドが走り、テストが走り、静的解析が走り、条件を満たせばステージング環境や本番環境へと自動で進みます。これは工場のベルトコンベアに似ていますが、流れているのは部品ではなくコードの変更です。
ここで大切なのは、パイプラインは速くリリースするためだけのものではないということです。むしろ本質は、品質確認を毎回同じ形で実行することにあります。誰が作業しても、同じテストが走る。条件を満たさなければ止まる。履歴が残る。これにより、チームは属人的な手順や経験則への依存から少しずつ解放されていきます。自動化は、単なる効率化の手段から、システムの品質と信頼性を担保するための不可欠なインフラへと進化したことになります。
2-4. Infrastructure as Code
自動化の波は、アプリケーション開発だけでなく、それが動作する「土台」であるサーバーやネットワークの構築にまで及びました。これが「Infrastructure as Code（IaC）」です。かつてサーバー構築といえば、管理画面を開き、設定値を入力し、ミドルウェアをインストールし、設定ファイルを編集する作業でした。手順書があっても、人によって微妙に設定が違う、開発環境と本番環境で差分が出る、といった問題が起こりがちでした。
AWSのドキュメントでは、DevOpsの基本原則として、インフラをアプリケーションコードと同じように扱い、バージョン管理や変更履歴の対象にすることが説明されています。
IaCによって、インフラ構築もレビュー可能で再現可能な成果物として扱えるようになりました。これは、開発作業だけでなく、システムを動かす環境そのものを自動化する流れだといえます。
3. これから大切なのは「判断を含む作業の自動化」かもしれない
3-1. 生成AIによるコード生成と開発支援
近年の自動化で大きな転換点になっているのが、生成AIによるコード生成です。これまでの自動化は、基本的には人間が決めた手順を機械に実行させるものでした。しかし生成AIは、コメントや自然言語の指示からコードを提案したり、既存コードを読んで修正案を出したりします。これは「作業の自動化」から「判断を含む支援」への移行だと見ることができます。
GitHubの調査では、特定のプログラミング課題において、GitHub Copilotを使った開発者が、使わなかった開発者よりも55％速く完了したと報告されています。もちろん、この数字だけであらゆる現場の生産性を語ることはできません。課題の種類、開発者の経験、レビュー体制によって効果は変わります。それでも、AIが開発作業の一部を現実に加速し始めていることを示す代表的な事例だといえると思います。
AIによる開発支援の便利さは、単にコード量を増やすことではありません。初期実装のたたき台を作る、知らないAPIの使い方を調べる、テストケースの候補を出す、エラーメッセージの意味を説明する。こうした場面で、AIはペアプログラミングの相手のように働きます。エンジニアが「どう書くか（How）」という細かな構文の悩みを減らし、「何を作るか（What）」という本質的な設計に時間を使いやすくなってきたともいえます。
ただし、AIが出したコードは正しいとは限りません。だからこそ、AI時代のエンジニアには、コードを書く力だけでなく、コードを読む力、疑う力、検証する力がより重要になってきているといってよいと思います。
3-2. AIエージェントと自律的な開発ワークフロー
さらに進むと、AIは単発のコード補完だけでなく、複数ステップの作業を自律的に進めるエージェントとして使われ始めています。OpenAIのCodex紹介ページでは、Codexが機能実装、コードベースに関する質問への回答、バグ修正、レビュー用のプルリクエスト提案などを行えるクラウドベースのソフトウェアエンジニアリングエージェントとして説明されています。
AIエージェントの特徴は、「この関数を書いて」といった一問一答だけでなく、「この不具合を調べて修正案を出して」「このリポジトリのテストを追加して」「古いAPI呼び出しを新しい方式へ移行して」といった、少し大きな仕事を任せられる点にあります。エージェントはコードを読み、変更し、テストし、差分を提示します。人間はその結果をレビューし、採用するか判断します。
たとえば、朝に小さな改善タスクをいくつかAIエージェントへ依頼し、昼にはプルリクエスト候補が並んでいる。人間はそれをレビューし、設計意図やプロダクト方針に合うかを確認する。そんな働き方が現実味を帯びてきました。一部の現場では、エンジニアが自ら手を動かしてコードを書くことに加え、複数のAIエージェントに適切な目標を与え、その進捗を監督し、最終的なアウトプットを統合する「オーケストレーター（指揮者）」のような立ち位置を求められる場面も増えていくのではないでしょうか。
一方で、エージェント化が進むほど、失敗したときの影響も大きくなることには注意が必要です。コード補完候補が一行間違うのと、エージェントが複数ファイルをまとめて変更するのとでは、リスクの大きさが違います。だからこそ、自動テスト、コードレビュー、権限管理、監査ログといった基礎的な仕組みがますます重要になります。新しい自動化ほど、古い基本を必要とする......と言ったら言い過ぎでしょうか。
3-3. 自動化の境界線をどこに置く？
ここまでの歴史を振り返ると、自動化はいつも「人間が何をするべきか」を問い直してきたことがわかります。計算を機械に任せたことで、人間は計算結果の意味を考えるようになりました。ビルドを自動化したことで、人間は依存関係や設計を考えるようになりました。CI/CDを導入したことで、人間はリリース作業そのものより、品質をどう保証するかを考えるようになりました。
AIの登場によって、この問いはさらに深くなっています。なぜなら、AIは単なる作業だけでなく、すでに「判断らしきもの」まで引き受け始めているからです。どの実装がよさそうか。どのテストが必要そうか。どの修正が妥当そうか。これらは従来、人間の経験に強く依存していた領域です。
では、どこまで機械に任せるべきなのでしょうか。この答えは単純ではありません。ただ、一つの目安は「失敗したときに、人間が理解し、止められ、直せるか」ではないかと思います。処理内容を誰も理解していない自動化は、便利であると同時に危険です。逆に、仕組みが見えていて、ログが残り、レビューでき、やり直せる自動化は、チームの力を大きく高めることは間違いありません。
AIが賢くなればなるほど、人間は楽になるだけでなく、より上流の判断を求められるようになるでしょう。その意味では、自動化の最終目的は、人間の責任を消すことではないことがわかります。自動化とは、人間がより重要な責任に集中できるようにすることなのかもしれません。これからのエンジニアに必要なのは、「自動化できるか」だけでなく、「自動化してよいか」を考える姿勢だと思います。機械に「手順」を任せ、人間が「意思」を込める。この役割分担こそが、未来のエンジニアリングを支える重要な鍵となりそうです。
4. まとめ
コンピュータの歴史は、計算・命令・作業・開発プロセス・インフラ構築を少しずつ自動化してきた歴史です。そして今、AIによって「判断を含む作業の一部」まで自動化の対象になりつつあります。大切なのは、機械に任せる範囲を設計し、人間が理解・検証し、必要なときに止められる状態を保つことです。自動化の歴史を知ることは、AI時代にエンジニアがどこで価値を発揮するかを考えるヒントになります。
