LoginSignup
67
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AI・機械学習 Qiita Tech Festa 2025
Qiita Tech Festa20252025年7月15日まで開催中！
@ShigemoriMasato(重盛 雅人)

[日常] 生成AIは『高級言語』の再来か？ - OHPとFORTRANの時代から探る、エンジニアの進化

Last updated at Posted at 2025-06-18

image.png

午後のミーティング。いつものように画面共有の準備をしていると、50代のベテラン社員たちの会話が耳に飛び込んできた。

「生成AIの登場って、俺たちがアセンブラからCみたいな高級言語1に移った時の感覚にそっくりだよな」

私の手が止まった。

「いや、俺がギリギリ新人研修で触ったくらいの、パンチカード2がなくなった時じゃないか？ 大先輩はノートにFORTRANを書いて、専門のパンチャーさん3にカード化してもらってたって言うし」

「そうそう！ プレゼン資料もパワポなんてないから、OHP4のフィルムにマジックで書いてたもんなあ…」

「でも、2000年頃まで手書きの設計書を保守してるシステム、あったよな。80年代に作られたやつ」

雷に打たれたような衝撃が走った。

彼らが語っているのは、単なる昔話ではない。私たちが今まさに経験している 「思考のデジタル化」 という革命の、壮大な前章だったのだ。

アナログという名の手枷

1969年、ある開発現場の朝

想像してみてほしい。

朝8時。プログラマの山田（仮名）は、昨夜まで悩み続けたアルゴリズムの改良案を、丁寧にコーディングシートに清書している。0.5ミリのシャープペンシルで、一文字一文字、慎重に。なぜなら、この後の工程を考えると、修正は極力避けたいからだ。

C     SUBROUTINE FOR MATRIX MULTIPLICATION
      SUBROUTINE MATMUL(A, B, C, N)
      DIMENSION A(N,N), B(N,N), C(N,N)
      DO 10 I = 1, N
        DO 10 J = 1, N
          C(I,J) = 0.0
          DO 10 K = 1, N
10          C(I,J) = C(I,J) + A(I,K) * B(K,J)
      RETURN
      END

9時半。山田は完成したコーディングシートを持って、計算センターへ向かう。そこには、キーパンチャーの鈴木さん（仮名）が待っている。彼女の仕事は、山田の書いたコードを、一行一枚のパンチカードに「翻訳」することだ。

image.png
(画像: EBCDIC文字セットのパンチカード､ASCII普及前の1963年に、BCD(Binary-coded decimal、二進化十進コード)を拡張する形で作られた)

カタカタカタ...パンチング機の音が響く。一枚のカードに一行。100行のプログラムなら100枚のカード。一文字でも間違えれば、そのカードは作り直し。山田は祈るような気持ちで見守る。

11時。ようやくパンチングが終わった。山田は厚さ3センチほどのカードの束を受け取り、計算機室へ向かう。しかし、計算機の使用時間は予約制。彼の番は明日の午後3時だ。

思考の檻

この時代、エンジニアの「思考」は、常に物理的な媒体という檻に閉じ込められていた。

実装の檻：パンチカード

  • 思考 → 紙への記述 → パンチャーによる穿孔 → カードの束 → 計算機への投入
  • 一つのタイプミスが、数日の遅延を生む
  • デバッグは「推理小説」のような作業

共有の檻：OHPフィルム

  • アイデアの可視化は、透明フィルムと油性ペンの腕前次第
  • 修正は、新しいフィルムを作り直すこと
  • プレゼンの成功は、フィルムの順番を間違えないことから始まる

しかし、最も深刻だったのは、設計思想の檻だった。

山田のチームが開発していたシステムの設計書は、A4サイズのバインダー3冊分。全て手書きだ。フローチャートは定規とテンプレートで描かれ、仕様変更は赤ペンで追記される。コピー機はあるが、モノクロで不鮮明。結果として、「原本」は神聖不可侵の存在となる。

2000年代に入っても、こうした手書き設計書が「正」として扱われるシステムが存在したという事実は、アナログの残響がいかに長く響き続けたかを物語っている。

黎明 - 思考が光速を得た日

革命前夜

1970年代初頭。二つの技術革新が、静かに、しかし確実に、エンジニアリングの風景を変えつつあった。

第一の革命：高級言語の成熟

「なぜ機械の都合に合わせて考えなければならないのか？」

この問いへの答えが、FORTRAN、COBOL、そして後のC言語だった。エンジニアは初めて、「何を計算するか」を「どう計算するか」から分離して考えることができるようになった。

! 1969年：機械に寄り添う思考
      LOAD  A
      ADD   B
      STORE C

! 1975年：人間の思考に近づく表現
      C = A + B

たった一行の違い。しかし、この違いが意味するものは革命的だった。

第二の革命：タイムシェアリングシステム（TSS）5の登場

Screenshot 2025-06-19 04.29.39.png
(出展: bit 1979 3月号 126p TSSエディタの使い勝手2)

「おい、見てみろよ。画面に打ち込んだコードが、その場で実行できるんだ！」

1975年のある日、山田は興奮を隠せなかった。目の前の端末で、彼は初めてコンピュータと「対話」していた。

> 10 PRINT "HELLO, WORLD!"
> 20 GOTO 10
> RUN
HELLO, WORLD!
HELLO, WORLD!
HELLO, WORLD!
^C
>

パンチカードも、パンチャーも、長い待ち時間も必要ない。思考は、キーボードを通じて、即座にデジタルの世界へと流れ込む。

解放された創造性

この二つの革命が合流したとき、エンジニアリングの本質が変わった。

山田のチームの生産性は劇的に向上した。しかし、より重要だったのは、彼らの「思考の質」が変わったことだ。

  • 実験的思考：「とりあえず試してみる」ことが可能になった
  • 反復的改良：小さな修正と確認のサイクルが高速化した
  • 創造的飛躍：実装の制約から解放され、より大胆なアイデアに挑戦できるようになった

OHPフィルムも、やがてPowerPointに道を譲った。手書きの図表は、マウスのクリックで美しいグラフィックに変わる。アイデアの共有は、物理的な制約から解放された。

しかし、この変化は一夜にして起こったわけではない。

地層 - 過去は決して消えない

1999年、ある保守現場にて

「これが、お前が担当するシステムの設計書だ」

中堅エンジニアの滝沢（仮名）は、目の前に積まれた書類の山を見て息を呑んだ。黄ばんだ紙、かすれた青焼き図面、そして無数の赤ペンの修正跡。

「えっと...山田さん、これって、いつ作られたものですか？」

山田は自席でたばこを吸いながら答える。

「1983年だな。でも心配するな。ちゃんと動いてる。20年近くな」

滝沢が担当することになったのは、ある製造業の基幹システムだった。COBOLで書かれ、メインフレーム上で動く、まさに「生きた化石」。しかし、この化石は、会社の心臓部を今も支えていた。

       IDENTIFICATION DIVISION.
       PROGRAM-ID. LEGACY-BEAST.
       DATE-WRITTEN. 1983-04-01.
      * 最終更新: 1999-03-15 Y2K対応（滝沢）
      * 注意: このプログラムは奇跡的なバランスで
      *       動いています。むやみに触らないこと。

滝沢は｢2000年対応済みシール｣をメインフレームに貼付けた。

技術の地層学

滝沢が発見したのは、技術の地層だった。最新のWebシステムの下に、90年代のクライアント/サーバーシステムがあり、その下に80年代のメインフレームが横たわる。そして最深部には、手書きの設計書という「始原の層」が存在していた。

「なぜ移行しないんですか？」

滝沢の素朴な質問に、先輩エンジニアは苦笑した。

「移行？ このシステムには20年分のビジネスロジックが詰まってる。ドキュメント？ 半分は存在しない。もう半分は...見ての通りだ。動いているものを、なぜ壊す必要がある？」

レガシーの叫び

しかし、2010年代に入ると、状況は限界に達していた。

  • COBOLを理解できるエンジニアの引退（69年入社の山田も65歳で定年）
  • 手書き設計書の判読不能化（作成者も既に退職）
  • 新しいビジネス要求への対応不可能

滝沢は、今やチームリーダーとなり、ついに決断を下す。「モダナイゼーション」プロジェクトの開始だ。

しかし、それは想像を絶する作業だった。

// 2010年：COBOLロジックをJavaに「翻訳」する日々
public BigDecimal calculateCommission(BigDecimal salesAmount, int employeeGrade) {
    // 元のCOBOLコメント：
    // * 1985-07-23 謎の係数0.97を追加（理由不明だが外すと計算が合わない）
    // * 1992-03-01 消費税対応で更に複雑化
    // * 1997-11-30 特別ボーナス計算追加（仕様書なし）
    
    BigDecimal commission = BigDecimal.ZERO;
    
    // 以下、解読不能な計算式の嵐...
    if (employeeGrade >= 3 && employeeGrade <= 5) {
        commission = salesAmount.multiply(new BigDecimal("0.05"))
                                .multiply(new BigDecimal("0.97")); // なぜ0.97？
    } else if (employeeGrade > 5) {
        // 20行に及ぶ条件分岐（元は1000行のCOBOL）
    }
    
    return commission.multiply(new BigDecimal("1.05")) // 消費税...たぶん
                     .setScale(0, RoundingMode.FLOOR);
}

覚醒 - AIという新たな翻訳者

2025年、自律エージェントが織りなす開発現場

滝沢はVisual Studio Codeの画面を見つめていた。しかし、コードを書いているのは彼ではない。Claude Codeが、自律的に設計からテストまでを進めていた。

# Claude Code セッション - 2025年6月18日 14:32
$ claude-code start --mode=autonomous --project=legacy-modernization

Claude Code: こんにちは、滝沢さん。レガシーシステムのモダナイゼーションプロジェクトを開始します。
             まず、2010年にJavaに移植された既存システムの分析から始めましょう。

[分析フェーズ - 14:32:15]
Claude Code: 現行のJavaコードと、保管されている移行前のCOBOL設計書を照合しています...
             興味深い発見：Java移植時にもそのまま引き継がれた謎の係数0.97があります。
             
             過去の類似パターンから推測すると：
             - 97%達成を基準とした営業インセンティブ設計
             - 3%の事務手数料控除
             - 当時の為替レート調整（1ドル=250円時代の名残）
             
             どの解釈を採用しますか？ それとも私の推論を続けますか？

> 推論を続けて。過去の議事録も参照してみて。

[自律調査フェーズ - 14:33:42]             
Claude Code: /documents/meeting-notes/1985/ を検索中...
             
             発見しました！ 1985年7月の営業会議議事録.mdに記載があります：
             「達成率97%を100%とみなす新評価制度の導入について」
             
             これで謎が解けました。現在のJavaコードをさらにモダナイズする
             アーキテクチャ設計に進みます。

[設計フェーズ - 14:35:20]
Claude Code: 現行のSpring Bootモノリスから、マイクロサービスアーキテクチャへの
             移行を提案します：
             
             1. Commission Service (手数料計算)
             2. Legacy Adapter (既存Javaシステムとの互換性維持)  
             3. Analytics Service (新旧計算結果の比較分析)
             
             設計ドキュメントを生成中... 完了。
             実装を開始してもよろしいですか？

> 続けて。テストカバレッジは95%以上で。

[実装フェーズ - 14:37:45]
Claude Code: 了解しました。TDDアプローチで実装を進めます。

滝沢が驚いたのは、Claude Codeが単にコードを生成するだけでなく、プロジェクト全体を自律的に推進していることだった。調査、設計、実装、テスト、ドキュメント作成まで、すべてが対話的に、しかし主体的に進行していく。

// Claude Code が生成したコード（一部抜粋）
// 生成時刻: 2025-06-18 14:42:33
/**
 * @fileoverview 手数料計算サービス
 * @history
 * - 1983: COBOL実装（メインフレーム）
 * - 1999: Y2K対応
 * - 2010: Java移植（Spring）
 * - 2025: Java 21/Spring Boot 3（Claude Code生成）
 * 
 * Claude Code分析メモ：
 * このビジネスロジックは40年間、本質的に変わっていません。
 * 技術は変われど、ビジネスの要求は一貫しています。
 * これは「良い設計」の証左と言えるでしょう。
 */
@Service
@RequiredArgsConstructor
public class CommissionCalculationService {
  // Claude Codeが過去の実装から抽出した不変条件
  private static final BigDecimal LEGACY_COEFFICIENT = new BigDecimal("0.97"); // 1985年導入、2025年も現役
  
  private final LegacyAdapter legacyAdapter;
  private final AuditLogger auditLogger;
  
  // Claude Code: 依存性注入により、レガシーシステムとの
  // 並行稼働を可能にしています
  
  public CompletableFuture<CommissionResult> calculateCommission(CommissionParams params) {
    // Claude Code: 新旧両方の計算を実行し、結果を比較
    var modernFuture = CompletableFuture.supplyAsync(() -> modernCalculation(params));
    var legacyFuture = CompletableFuture.supplyAsync(() -> legacyAdapter.calculateViaCobol(params));
    
    return modernFuture.thenCombine(legacyFuture, (modernResult, legacyResult) -> {
      // 差異があれば自動的に調査レポートを生成
      if (!areResultsEqual(modernResult, legacyResult)) {
        auditLogger.logDiscrepancy(new DiscrepancyRecord(
          modernResult,
          legacyResult,
          analyzeDiscrepancy(modernResult, legacyResult)
        ));
      }
      
      return modernResult;
    });
  }
}
// Claude Code: テストも同時に生成しています
@SpringBootTest
class CommissionCalculationServiceTest {
  // 1985年の実データを使用したゴールデンテスト
  @Test
  void shouldMatch1985COBOLImplementationResults() throws Exception {
    var testData = loadHistoricalTestData("1985-cobol-results.json");
    // ... 95%カバレッジを達成する包括的なテスト
  }
}

record CommissionResult(BigDecimal amount, Instant calculatedAt) {}
record DiscrepancyRecord(CommissionResult modern, CommissionResult legacy, String analysis) {}

「> 」Claude Codeのプロンプトが語りかけてきた。「実装が完了しました。旧システムとの互換性は100%、パフォーマンスは320%向上、テストカバレッジは96.7%です。デプロイの準備はできています」

思考の翻訳者たち

ここで、私たちは壮大な相似形に気づく。

パンチャーからAIへ - 思考を形にする「翻訳者」の系譜：

  1. 1960-70年代: キーパンチャー（人間）が、手書きコードをパンチカードに翻訳
  2. 1980-90年代: コンパイラ（ソフトウェア）が、高級言語を機械語に翻訳
  3. 2020年代: AI（知能）が、人間の意図をコードに翻訳

しかし、決定的な違いがある。AIは単なる翻訳者ではない。それは、思考の増幅器なのだ。

レガシーとの対話

滝沢のチームは、生成AIと自律エージェントを使って、あの悪名高いレガシーシステムの移行を加速させた。Claude Codeは単独で数千行の古いJavaのコードを解析し、現代的なアーキテクチャへの移行計画を自律的に立案した。しかし、最も価値があったのは、AIが「なぜ」を問い続け、人間と対話しながら本質を掘り下げたことだった。

// AI との対話から生まれた洞察
public interface LegacyBusinessRule {
    // AIの分析：0.97係数は「達成率97%を基準とした
    // インセンティブ設計」の名残りである可能性が高い
    BigDecimal MYSTERY_COEFFICIENT = new BigDecimal("0.97");
    
    // AIの提案：当時の設計思想を保持しつつ、
    // 現代的な実装に置き換える
    default Money calculateCommission(CommissionParams params) {
        // 20年分の暗黙知を、明示的なビジネスルールとして再構築
        return Money.of(params.salesAmount())
            .multiply(getBaseRate(params.employeeGrade()))
            .multiply(MYSTERY_COEFFICIENT)
            .multiply(BigDecimal.ONE.add(getCurrentTaxRate()));
    }
}

統合 - 一人のエンジニアに宿る半世紀

2025年、ベテランエンジニアの今

あの日の会議で昔話をしていたベテランエンジニアの一人、滝沢さんだ。57歳。1990年入社。彼のキャリアは、まさに日本のIT産業の歴史そのものだった。

「今、何を開発されているんですか？」

私の問いに、滝沢さんは少し照れくさそうに答えた。

「GitHub Codespaces 上の Visual Studio Code で、Claude 4 と対話しながら、自律エージェントに設計とテストを任せて Next.js でフロントエンドを開発してるよ。最近バックエンドの実装とテストが終わったんだけど、8割はClaude Codeが自動で進めてくれるから、俺は主にビジネス要件の検討と、アーキテクチャの最終判断に集中してる。重盛も使ってるんでしょ？Claude Maxの200ドル？」

私は息を呑んだ。

  • GitHub Codespaces: クラウド上の開発環境
  • Claude 4: 最新の対話型AI
  • Claude Code: 自律的な開発エージェント
  • Next.js 15: モダンReactフレームワーク

すべてが「最先端」だった。

技術の年輪

滝沢さんの経歴を聞いて、私はさらに驚いた。

滝沢さんの技術遍歴

  • 1990年 - 新人研修でパンチカード体験 / FORTRAN 77でプログラミングの基礎を学ぶ
  • 1993年 - C言語で業務アプリケーション開発 / 在庫管理システムなど
  • 1997年 - Visual Basic 6.0でWindowsデスクトップアプリ開発 / 社内向けGUIツール
  • 1999年 - Y2K問題対応でCOBOLの改修
  • 2005年 - Javaで Webアプリケーション開発 / Struts + JSP でECサイト構築
  • 2010年 - COBOLからJavaへのモダナイゼーション
  • 2015年 - Single Page Application開発 / Angular + Node.js でリアルタイムアプリ
  • 2020年 - React + TypeScript でモダンフロントエンド / GraphQL API連携
  • 2024年 - AI駆動開発 / GitHub Copilot + Claude でコーディング効率が劇的に向上
  • 2025年 - Next.js + Claude Code / 自律エージェントが実装、人間はUX設計に専念

「でもさ」滝沢さんは続けた。「結局、本質は変わってないんだよ」

「本質、ですか？」

「そう。俺たちがやってることは、ずっと同じ。人間の『こうしたい』を、機械が理解できる形に翻訳すること。道具が変わっただけさ」

層を成す知恵

滝沢さんのVSCodeの画面を覗かせてもらった。そこには、驚くべき光景が広がっていた。

/**
 * @file 在庫管理システム - メイン計算ロジック
 * @author 滝沢
 * @description 
 * 第4世代目です。オリジナルはCOBOLでした（1985年製）。
 * 
 * Claude による分析：
 * - 安全在庫の計算式は統計的に妥当
 * - ただし、現代ではより高度な予測モデルが利用可能
 */

class InventoryCalculator {
    /**
     * 安全在庫数を計算
     * 
     * この計算式は40年前から使われ続けているが、
     * 今でも十分実用的。ただし、Claudeの提案により、
     * 機械学習による需要予測も並行して実装中。
     */
    calculateSafetyStock(
        averageDemand: number,
        leadTime: number,
        serviceLevelZ: number = 1.65 // 95%サービスレベル
    ): number {
        // 1985年の知恵
        const classicFormula = Math.sqrt(leadTime) * 
                              averageDemand * 
                              serviceLevelZ;
        
        // 2025年の知恵（Claude 4による自律的改良）
        const mlAdjustment = this.getMachineLearningAdjustment();
        
        return Math.ceil(classicFormula * mlAdjustment);
    }
}

コードには、40年分の知恵が層を成して存在していた。COBOLの計算式、オブジェクト指向の設計、そして最新のAIによる改良提案。

真の継承

「君たち若い世代に伝えたいことがあるんだ」

滝沢さんは、真剣な表情で語り始めた。

「AIが登場して、『プログラマーは不要になる』って言う人がいるだろ？ でも、それは違う。パンチカードがなくなった時も、同じことを言われた。『キーパンチャーが失業する』って。でも実際は？」

私は頷いた。確かに、キーパンチャーという職業はなくなった。しかし、プログラマーという、より創造的な職業が生まれた。

「大事なのは、何を作るかを考える力なんだ。どんなにAIが賢くなっても、『なぜそれが必要か』『誰のために作るか』を考えるのは人間の仕事さ」

「滝沢さん、今週末ゴルフに行きませんか？」

滝沢は下を向きながら言った。

「だめだ重盛、今週末は山田さんの墓参りだ」

エピローグ：未来への手紙

2035年のエンジニアへ

この記事を書き終えようとしている今、私は想像する。10年後、2035年のエンジニアは、どんな世界で生きているのだろうか。

きっと彼らは、私たちを笑うだろう。

「え？ 2023年の人たちって、まだ人間がVisual StudioやEclipseを立ち上げて、自分でJavaやPythonをタイピングしてたの？それって、人間のやる仕事じゃないよね…」

「しかも、変数名とか、インデントとか、セミコロンの位置とか、そんな瑣末なことに時間を使ってたって？」

そう、彼らにとって、人間が高級言語でプログラミングすることは、私たちがアセンブラやパンチカードを見るのと同じ - 原始的な手作業として映るだろう。

しかし、私は確信している。

歴史は繰り返す。彼らもまた、さらに新しい「手枷」に気づき、それを打ち破ろうとしているはずだ。そして、2025年の私たちと同じように、過去の技術の上に立ちながら、「人間の想いを形にする」という永遠の使命を追求しているはずだ。

今、私たちが立っている場所

2025年、私たちは技術史の転換点に立っている。生成AIという新しい「翻訳者」を得て、さらに自律エージェントという「開発パートナー」を手に入れた。思考と実装の距離は、もはやゼロに近づきつつある。

しかし、滝沢さんの姿が教えてくれるのは、この変化が「断絶」ではなく「継承」だということだ。

  • パンチカードの不便さを知るからこそ、即時実行の価値がわかる
  • COBOLの冗長さを経験したからこそ、簡潔な表現を追求できる
  • 手書き設計書の曖昧さと格闘したからこそ、明確な仕様の重要性を理解できる

すべての経験が、次の時代を生きる知恵となる。

最後に - ベテランたちへの敬意を込めて

あの日の会議で聞いた「昔話」は、単なるノスタルジーではなかった。

それは、半世紀にわたって技術の荒波を乗り越え、常に学び続け、自らを更新し続けてきたエンジニアたちの、壮大な叙事詩だった。

彼らは今日も、最新のAIと対話しながら、新しい価値を生み出している。その姿は、私たち全員に勇気を与えてくれる。

技術は変わる。ツールは進化する。しかし、エンジニアの本質 - 人間の想いを形にするという使命は、永遠に変わらない。

そして、その使命を果たすために必要なのは、最新のツールを使いこなす技術だけではない。過去から学び、現在に適応し、未来を創造する、しなやかな精神なのだ。

1969年の『bit』創刊号から2025年のVibe Codingまで、56年の時を超えて。全てのエンジニアに、敬意と感謝を込めて。

参考文献

『bit 1969年3月号 Vol.1, No.1』共立出版、1969年

  1. 高級言語 (High-Level Language) - 人間の言葉に近い文法で記述できるプログラミング言語。機械語やアセンブリ言語のような低級言語と対比される。FORTRAN（1957年）、COBOL（1959年）が代表例。 ↩

  2. パンチカード - 紙のカードに穴を開けてデータを記録する媒体。1801年のジャカード織機に起源を持ち、1970年代までコンピューターの主要な入力媒体だった。80桁×12行が標準。 ↩

  3. パンチャー / キーパンチャー - プログラマーが作成したコーディングシートを見ながら、専用の穿孔機でパンチカードに穴を開ける専門職。1960-70年代には花形職業の一つだった。 ↩

  4. OHP (オーバーヘッドプロジェクター) - 透明なフィルムに書かれた内容を、光源と鏡を使ってスクリーンに投影する装置。PowerPoint登場以前の主要なプレゼンテーションツール。 ↩

  5. TSS (タイムシェアリングシステム) - 1台のコンピューターの処理時間を細かく分割し、複数のユーザーが対話的に利用できるシステム。1960年代後半から普及し、現代のマルチユーザーOSの原型となった。 ↩

67
35
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
67
35

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?