■ 1. LLMとクラウドの技術的共通性
- LLMは「言語を使った作業を操作可能にする技術」であり、入力プロンプトをもとに語の確率分布から人間らしい文章を生成する統計モデル
- システム開発はドキュメント作成やコーディングなど言語を使った作業が多く、LLMによる補完・自動化の可能性がある
- クラウドは「インフラ作業を操作可能にする技術」であり、仮想化技術をベースにインフラ構築・運用作業がAPI化された
- 両者は「人手でしかできなかった作業を操作可能にする技術」として比較できる
- システム開発という文脈では「特定の工程が自動化されたことで何が起きるか」という視点での比較が有効
■ 2. クラウドがもたらした変化
- NoOps（2011年）:
- インフラ構築・運用作業の自動化により、従来の運用という概念が変化
- Netflixでは運用部門の目的が「開発者が運用するのに必要なツール・プラットフォームを整備すること」に変化
- 開発者がセルフサービスで運用作業を実施し、DevOpsエンジニアがそのツールを作る体制が確立
- IaC（Infrastructure as Code）:
- インフラのあるべき構成をコードとして管理し、定義と現在状態の差分から変更計画を生成するツール
- インフラ構成がコードとして確認・比較・レビュー・再現できる対象となる
- 現在状態との差分やドリフトを検知し、あるべき状態へ収束させることが可能
- マイクロサービス（2014年）:
- インフラの高度な自動化を前提に、大規模システムを複数のサービスに分割して構成するアーキテクチャ
- 他チームとの調整なく各チームが独立したリズムでサービスを変更・リリースできる
- 巨大なサービス全体における漸進的な改善が可能になる
■ 3. クラウドの歴史から学べること
- 自動化された工程の担当者は、自動化ツールを整備する側に移行し、前工程の作業者がセルフサービスで作業するようになる
- 自動化ツールは抽象化された構成管理ツールとして高度化する
- チーム構成や仕事の進め方も変化していく
■ 4. AI駆動開発の現在
- AIエージェントへのタスク委任が主流になりつつあり、象徴的な例としてClaude Codeによるエージェント型コーディングがある
- エージェント型コーディングでは利用者が「何を作りたいか」というタスクを与え、AIエージェントが実行する
- AIエージェントが動く環境として以下の構成要素（AIハーネス）が必要:
- Context: プロジェクトの前提・ルールとして共有する情報
- Skills: 繰り返し使う作業手順を与えるためのスキル定義
- Subagents: 作業ごとの役割・文脈・権限を分けるための専門エージェント
- Hooks: 特定タイミングで自動実行する処理を定義するための仕組み
- MCP servers: 外部ツールや外部データに接続するための仕組み
- AIエージェントはAIモデルとAIハーネスの組み合わせとして定義される
■ 5. AI駆動開発の未来
- AIハーネス開発者の登場:
- DevOpsが運用オペレーターの役割を変えたように、AI駆動開発ではシステムエンジニアやプログラマの役割が変化する
- 「エンジニアが不要になる」のではなく、DevOpsエンジニア・SREのように「AIハーネス開発者」という役割が重要になる
- AIハーネス開発者は、エージェントツール環境管理・ハーネス設定・ナレッジ整備・エージェント動作管理・品質管理などに細分化される
- 要件構成管理ツールの必要性:
- POがコーディングエージェントを使うには精度の高い要件が必要だが、従来の要件定義手法では人間の認知限界を超えられない
- LLMは文章で記載された要件同士の関係を読み取り、矛盾や抜け漏れを機械的に確認できる
- IaCツールがインフラ構成を管理したように、要件構成を管理するためのツールが重要になる
- BIMとの類比:
- 建設業界のBIM（Building Information Modeling）は、部品単位でデータを持った3Dモデルとして建物を扱い、設計精度を高める仕組み
- システム開発の要件管理でも、LLMによって要件や構造の意味的な整合性を機械的に確認することが可能になる
- 要件構成管理ツールの想定される姿:
- 小さな要件を候補要件モジュールとして登録する
- 候補要件モジュールの選択から依存性・影響を踏まえた「リリース要件構成情報」を組み上げる
- 「リリース要件構成情報」を「全体実現構造モデル」に組み込む
- 「全体実現構造モデル」の更新差分から「実現構造モデル差分」を生成する
- 「実現構造モデル差分」からコーディングエージェントが各サービスを開発する
- 「リリース要件構成情報」に対して受入テストを実施する
- 新たな役割の登場:
- 要件構成設計エンジニア: POの横で要件モジュールを整理し、要件同士の依存性を管理する
- 実現構造設計エンジニア: 要件構成から実現構造を導く
- 建築業界における「意匠設計」（目的・空間設計）と「構造設計」（物理的・構造的実現）の分離に相当する
- チーム・マネジメントの変化:
- 複数の開発チームが複数のサービスを個別管理する形から、AI駆動開発プラットフォーム上で横断的に管理する形に変化
- 1つの要件に対して複数のサービスにまたがる変更を整合性を保ったまま一括して計画・実装・リリースできるようになる
■ 6. まとめ
- 従来のSEやプログラマの役割は、コーディングエージェントを正しく動かすための環境・制約・ナレッジを整備するAIハーネス開発者へ移行する
- ビジネス側がコーディングエージェントを使いこなすには精度の高い要件が必要であり、要件構成管理ツールが必要になる
- 「何のためにやるか」という要件構成を設計するエンジニアと「どう実現するか」という実現構造を設計するエンジニアという新たな役割が登場する
- AI駆動開発はコード生成の自動化にとどまらず、要件・実現構造・実装・テストのつながりをAIによって再設計することにある