はじめに

今回はAIを利用したソフトウェア開発の概念と用語についてまとめてみました。

直近まで育休を取ったり、レガシーな開発手法&技術を扱うプロジェクトにいたという経緯もあり、AIに関しては浦島太郎状態で、内心かなり焦っておりました...。何かにつけて骨組みを理解しないと行動に移せない性分なので、一旦AI周りの概念・用語を時系列も含めて整理してみました。

お恥ずかしながら「ハーネスエンジニアリング？」「Gem？」という状態だったのですが、整理することで理解が深まりちょっとスッキリしました。私のような浦島太郎＆AIよわよわエンジニアの方の参考にしてもらえれば幸いです。

筆者のこと

9年目のWEBエンジニア
育休やらレガシー現場への長期滞在でAIに関して浦島太郎状態

これまでの経緯とキーワード

これまでのAIを利用したソフトウェアエンジニアリングの変遷をざっくり振り返る。

2021 - 22年：AIが補助ツール化する

GitHub Copilotが登場。ただこの時のAIはあくまで「自動補完ツール」。あくまで人間がいかに上手く指示を出すか（プロンプトをうまく作成するか）が重要だった。

#プロンプトエンジニアリング

2023 - 24年：知識の外部拡張

ChatGPTが普及する。ハルシネーションを防ぐためRAGで外部知識を与え、TDDでAIの書いたコードを機械的に検証し始めた。

#RAG #TDD #DDD

2024年前半：直感的開発

自然言語だけでアプリケーションを開発できるようになる。バイブコーディングがバズる。GemなどでAIをカスタマイズし、文脈を持たせるようになる。

#バイブコーディング #Gem

2024年後半：自律型エージェントの台頭

CursorやClineなどのAIエージェント型IDEが普及する。プロンプトそのものよりも「AIにどのファイル(≒文脈)を読ませるか」が重要になる。

#コンテキストエンジニアリング #MCP

2025年 - 現在：AI主導 & 仕様駆動

AIが自律的にコードを書くため、人間は「Markdownで仕様書を書く」「AIがテスト・実行できる環境(ハーネス)を整備する」役割へシフト。

#AI駆動開発 #仕様駆動開発 #ハーネスエンジニアリング

新たに登場した用語たち

AIの性能向上に合わせてエンジニアリング手法も変化し、それに伴ってさまざまな言葉も生まれた。
また従来のTDDやDDDも、形を変えて再評価・重要視されている。

🐣 第一世代：「指示出し」の進化

プロンプトエンジニアリング

AIに対して、

どう質問するか？
どう指示文を書くか？

のテクニック。
現在はモデルの進化により、作り込んだ複雑なプロンプトは不要になりつつある。

コンテキストエンジニアリング

AIに対して、

どの情報(ファイル、ログ、仕様など)を渡すか？

を設計すること。
AIのコンテキストウィンドウ(一度に読める文字数)が巨大化した現在は、上手な指示を出すよりも、必要なドキュメントを過不足なく読ませることが結果を左右する。

バイブコーディング

2024年ごろに登場したバズワード。ちっちゃいことは気にせず、AIと対話しながら直感(バイブス)でコードを書くスタイル。プロトタイプ作成には良いが、本番環境には向かない。

🐥 第二世代：設計・テスト手法のアップデート

テスト駆動開発 -TDD-（AI駆動のすがた）

人間またはAIが先にテストコードを書き、そのテストが通るようにAIに実装させる。

AIによるコーディングは「もっともらしいバグ」を生み出すことが多々ある。それら全てを人間がレビューするには限界がある。そのため「テストが通る=正しい」という自動検閲にできるテスト駆動開発が再評価されている。

ドメイン駆動設計 -DDD-（AI駆動のすがた）

ビジネスの業務知識(=ドメイン)を中心にソフトウェアを設計する。

AIは一般的で平凡なアーキテクチャを採用したがる傾向にある。PJ固有のビジネスルールをAIに理解させるための手法として、ドメイン駆動設計の「ユビキタス言語(共通言語)」をインプットすることが重要視されている。

🦅 第三世代：AI主導へのパラダイムシフト

AI駆動開発 -AIDD-

AIを単なる補完ツールとしてでなく、設計~実装~テスト~リファクタリングを担う自律型エージェントとして扱う開発。人間はコードを書く時間を減らし、「AIのマネジメント」「レビュー」に専念する。

仕様駆動開発 -SDD-

人間が厳密な仕様書を書き、それをもとにAIに実装させる。バイブコーディングとは対極の手法。

考え方としては従来のウォーターフォール開発における要件定義・設計の相似形。AIは超優秀ではあるがあくまで指示待ちのため、明確な指示を与えることで正確に動かす。

ハーネスエンジニアリング

AIがコーディング・テスト・実行するための安全な環境(=ハーネス)を構築すること。ハーネスとは日本語で言うと、命綱や安全帯の意。

例えばAIが勝手に本番DBを飛ばしてしまったりしないよう、サンドボックス環境を用意し、LinterやCI/CDを整備して、AIが自律的に試行錯誤できるようにするエンジニアリング。

新たに登場したMarkdownドキュメントたち

AI駆動開発では、AIが最も読みやすい軽量フォーマットのMarkdownが開発資料の主役。これらはAIにPJの文脈(=コンテキスト)を理解させるためのもの。

🎯 要件定義書 requirements.md

プロジェクトの目的
対象ユーザー
満たすべき機能要件・非機能要件

などを記載する。AIが何を作るべきかを見失わないようにする。

# TODOアプリ 要件定義

## プロジェクトの目的
ユーザーが日々のタスクを簡単に記録・管理し、実行を促すためのTODOアプリケーションを構築する。

## 対象ユーザー
- PCおよびスマートフォンでタスクを素早くメモしたい個人

## 機能要件
- タスクの追加ができること
- タスクの一覧が表示できること
- タスクの完了ステータスをトグルできること
- タスクを削除できること

## 非機能要件
- UI/UX: レスポンシブ対応（PC, モバイル両対応）であること
- 保存方式: バックエンドは用意せず、ブラウザのLocal Storageに保存すること

📐 基本/詳細設計書 design.md

DBスキーマ
APIのIF
画面構成
アーキテクチャ方針

などを記載する。AIに「こういう構造で作ってくださいね」と強制させる。

# TODOアプリ 設計書

## 技術スタック
- React
- TypeScript
- Tailwind CSS

## 画面構成
1. ヘッダー (アプリタイトルを表示)
2. タスク入力フォーム (テキスト入力フィールド + 追加ボタン)
3. タスクリスト (タスク名、完了チェックボックス、削除ボタンのリスト)

## データ構造 (型定義)
```typescript
type Task = {
  id: string; // UUID
  title: string;
  completed: boolean;
  createdAt: number; // Unix Timestamp
}
```

📅 WBS/進捗管理表 tasks.md

実装手順をステップバイステップで記載する。
AIエージェントはこのファイルに記載されたタスクにチェック✅を入れながら自律的に作業を進める。

# 実装タスク一覧

## Phase 1: 初期セットアップ
- [ ] Viteを使用してReact+TypeScriptのプロジェクトを作成する
- [ ] Tailwind CSSをインストールし、初期設定を行う

## Phase 2: UI実装
- [ ] `TaskInput` コンポーネント（入力欄とボタン）を作成する
- [ ] `TaskList` コンポーネント（一覧表示）を作成する
- [ ] `TaskItem` コンポーネント（1行分の表示）を作成する

## Phase 3: ロジック実装
- [ ] Local Storageと同期するカスタムフック `useTasks` を実装する
- [ ] App.tsxに各コンポーネントを配置し、状態をつなぎ合わせる

## Phase 4: 仕上げ
- [ ] Tailwind CSSを用いて全体のデザインを整える
- [ ] アプリケーションをビルドし、エラーが出ないか確認する

※AIエージェントがこのマークダウンのチェックボックス [ ] を自分で [x] に書き換えながら、自律的にタスクを消化するイメージ。

📜 コーディング規約/開発標準 CLAUDE.md, .cursorrules

変数名はキャメルケース
エラーハンドリングは◯◯とする

などを記載する。AIに対するPJ固有の振る舞いやルールを記述する。

# コーディング規約およびAIへの指示

## 言語とフレームワーク
- 常に TypeScript を使用し、厳密な型定義（`any`の禁止）を行うこと。
- Reactコンポーネントは常に関数コンポーネント（FC）として記述すること。

## スタイリング
- CSSモジュールやインラインスタイルは使用せず、必ず Tailwind CSS のユーティリティクラスを使用すること。

## エラーハンドリングとログ
- エラーが発生しうる処理には `try-catch` を用いること。
- ユーザー向けの警告は `console.warn` で出力すること。

## コミュニケーション
- コードの修正を提案する際は、なぜその修正が必要なのか理由を日本語で簡潔に添えること。

🛠️ 運用マニュアル/ツール定義 skills.md

AIに対して、

コマンドラインで使えるツール
DB接続スクリプトの使い方

など、AIが実行可能な操作の方法を教える。

# ツールとコマンドライン操作マニュアル

## パッケージ管理
当プロジェクトではパッケージマネージャーとして `npm` を使用します（`yarn`や`pnpm`は使用しないでください）。
- パッケージ追加: `npm install <package-name>`

## 開発サーバーの起動
ローカルで動作確認を行う場合は、以下のコマンドを実行してください。
- `npm run dev`

## テストの実行
AIがコードを変更した後は、必ず以下のコマンドでテストが通るか確認してください。
- `npm run test`

よく使うツールたち

🔍 RAG：検索拡張生成

AIに社内ドキュメントや全コードベースを検索させ、その結果をもとに回答させる技術。

例えば「このPJの認証フローについて教えて」と聞くと、裏側でRAGが走り、関連ファイルを読み込んで正確な回答を出してくれる、など。

💎 Gem -Google Gemini Gems-

特定の役割やコンテキストを持たせたカスタムAIアシスタントを作る機能。OpenAIのCustom GPTsも同様。

例えば、

社内のコーディング規約を全て読み込ませたコードレビュワーGem
要件定義書の壁打ち相手になるGem

などを作って活用できる。

🔌 MCP -Model Context Protocol-

AIと外部ツール(PCのローカルファイルや社内DB, Slack, GitHubなど)を標準規格で繋ぐオープンプロトコル。

AIをブラウザの中で使うのだけではなく、AIエージェントに、

直接ローカルのPostgreSQLの中身を見せる
Jiraのチケットを読ませる

といったことがシームレスかつ安全にできるようになった。

まとめ

AIがぐんぐん進化していますので、私も「とにかくツール触らなきゃ」「自分の仕事にも導入しないと」と焦っていました。そこで少し立ち止まってみて、一旦これまでの経緯と誕生した概念を振り返って理解してからツールを触ることで、自分のこれまでの業務とAIツールの橋渡しがしやすくなった実感があります。

もう仕事でコードを書けない（※禁止はされていないが）のはかなり寂しさがありますし、仕事を失う不安もありますが、古来の開発に比べると時代を経るにつれて開発言語は自然言語に近付いてきていたわけなので、いま自然言語でソフトウェア開発が可能になったことは当然の帰結ですし、ある種のハッピーエンドかなと思います。

今日すぐにソフトウェアエンジニアが不要になったわけではないですし、やること・やれることはたくさんある！進化したソフトウェアエンジニアリングをまた楽しんでいきましょう。