1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

⚡ChatGPTから始まった3年間で、私の開発スタイルは7回も変わった

Last updated at Posted at 2025-10-19

「普通の質問」から「AIと共創する開発」へ――
2022年12月から2025年10月までの3年間を記録する。

📚 この記事について

  • AI開発ツールの7フェーズ進化の全体像
  • 各フェーズで何が変わり、何ができるようになったのか

目次

  1. 衝撃の3年間:何が起きたのか
  2. 全体像:7つのフェーズ進化マップ
  3. 第0フェーズ(2022年12月〜2023年4月):ChatGPTとの出会い
  4. 第1フェーズ(2023年5月〜2024年12月):開発へのAI活用が始まった
  5. 第2フェーズ(2025年1月〜5月):Cursorで世界が変わった
  6. 第3フェーズ(2025年5月〜7月):Claude Desktopの衝撃
  7. 第4フェーズ(2025年7月〜8月):Claude Codeで自律性が加速
  8. 第5フェーズ(2025年8月〜10月):Codexで開発が「共創」になった
  9. 第6フェーズ(2025年10月〜):SDD統合で未来が見えた
  10. 振り返り:開発者の役割はどう変わったか
  11. 今、どのフェーズにいるだろうか?
  12. 次のフェーズに進むためのアクションプラン

衝撃の3年間:何が起きたのか

2022年12月、私は普通にGoogleで検索していた。

  • 分からないことがあればGoogle検索
  • Stack Overflowで答えを探す
  • ドキュメントを読む
  • 調べた内容を基にコードを書いて試行錯誤

当たり前の日常。これが何十年も続いてきた。

2023年5月、私は開発でAIに頼り始めた。

  • ChatGPTにコードを聞く
  • エラーメッセージを貼り付ける
  • 関数の書き方を教えてもらう

開発のやり方が少しずつ変わり始めた。

2025年10月、私はAIと対話しながら開発している。

  • 自然言語で要件を伝える
  • AIが仕様を理解し、設計を提案する
  • AIが複数ファイルを同時に編集する
  • AIがテストを実行し、バグを修正する

たった3年間で、何が起きたのか?

この記事は、その3年間で私が体験した7つのフェーズ進化の完全な記録である。


全体像:7つのフェーズ進化マップ

まずは、全体像を把握しよう。この3年間で、AI開発ツールは驚異的な速度で進化した。

7フェーズ進化タイムライン

フェーズ進化表

フェーズ 時期 使用ツール 仕様モデル コード提供方法 主な用途 特徴・位置づけ
第0フェーズ 2022年12月〜2023年4月 ChatGPT GPT-3.5 / GPT-4(初期) チャットウィンドウで質問応答 一般的な質問、情報収集、調査など AI会話の体験。開発以外の用途が中心で、「AIと会話できる」という新体験の時期。
第1フェーズ 2023年5月〜2024年12月 ChatGPT GPT-4 Turbo / GPT-4.5系 チャットウィンドウにコードを貼り付ける コードレビュー、コード修正、一部関数の作成など チャット中心のAIコーディングが一般化。自然言語指示による開発支援が定着。
第2フェーズ 2025年1月〜5月 Cursor GPT-4 Turbo / Claude 3系 IDE上で直接コードを提供 コードレビュー、コード修正、一部関数の作成など IDE内AI補完が主流化。開発者の作業サイクルにAIが常駐。
第3フェーズ 2025年5月〜7月 Claude Desktop Claude Sonnet 4(2025年5月22日リリース) MCP経由でワークスペース内ファイルを直接操作 新規アプリ開発、UI PoC、レビュー・修正など MCP対応によりローカル環境連携が実現。マルチファイル開発が現実的に。
第4フェーズ 2025年7月〜8月 Claude Code Claude Sonnet 4 / Opus 4 IDE操作+コマンド実行+MCP直接操作 既存アプリの軽微な修正、新規開発、UI PoCなど MCP+コマンド統合で、AI主導の開発ループが成立。
第5フェーズ 2025年8月〜10月 Codex GPT-5(2025年8月7日リリース) IDE操作+コマンド実行+MCP操作 大規模アプリ修正、新規開発、レビュー・PoCなど 信頼性・自律性が飛躍。セッション/履歴単位管理によるチーム開発が可能に。
第6フェーズ 2025年10月以降 Codex × SDD GPT-5 + 仕様連携モジュール SDDで仕様定義+IDE操作+MCP操作 大規模修正・拡張、新規開発、仕様連動開発 仕様書とAI開発を統合。SDDによる完全なAI共創開発フェーズへ到達。開発体験が飛躍的に上がった。

第0フェーズ(2022年12月〜2023年4月):ChatGPTとの出会い

「AIと会話できる」という衝撃

2022年12月、ChatGPTが公開された。

当時、私は半信半疑だった。

「AIと会話?どうせ単純な応答しかできないんでしょ。」

しかし、試しに使ってみると――

私: 「日本の首都はどこですか?」

ChatGPT: 「日本の首都は東京です。」

私: 「東京の人口は?」

ChatGPT: 「東京都の人口は約1,400万人です(2022年時点)。
23区だけでは約980万人、東京圏全体では約3,700万人に達し、
世界最大の都市圏の一つとなっています。」

これは...すごい。

このフェーズでできたこと

一般的な質問応答

私: 「量子コンピューターって何?」

ChatGPT: 「量子コンピューターは、量子力学の原理を利用して
計算を行うコンピューターです。従来のコンピューターが
0か1のビットを使うのに対し、量子コンピューターは
量子ビット(キュービット)を使い...」

情報のまとめ

私: 「Reactの特徴を3つ挙げて」

ChatGPT: 
「1. コンポーネントベースの設計
2. 仮想DOMによる高速レンダリング
3. 豊富なエコシステムとコミュニティ」

文章の作成や添削

私: 「この文章をもっとわかりやすくして」

ChatGPT: (改善された文章を提案)

簡単なコード例の生成

私: 「Pythonで現在時刻を表示するコードは?」

ChatGPT: 
「以下のコードで現在時刻を表示できます:

from datetime import datetime
now = datetime.now()
print(now.strftime("%Y-%m-%d %H:%M:%S"))
」

このフェーズでの使い方

開発以外が中心:

  • 言葉の意味を調べる
  • 歴史や科学の質問
  • 旅行計画や料理のレシピ
  • 文章の翻訳やチェック
  • アイデア出し

開発でも少し使い始める:

  • 簡単な文法の確認
  • ライブラリの使い方を聞く
  • エラーメッセージの意味を調べる

しかし、まだ**「本格的な開発に使う」という発想はなかった。**

このフェーズの限界

コードの質はまだ不安定

  • 複雑なロジックは間違いが多い
  • 最新のライブラリには対応していない

コンテキストが短い

  • 長い会話を覚えていられない
  • プロジェクト全体の理解は不可能

開発者の信頼が低い

  • 「AIが書いたコードなんて使えない」
  • 「結局自分で書いた方が早い」

このフェーズの学び

「AIと会話できる時代が来た」

まだ「賢い検索エンジン」程度だが、新しい可能性を感じた。

開発者の役割: 普通に開発し、AIは補助的に情報収集に使う


第1フェーズ(2023年5月〜2024年12月):開発へのAI活用が始まった

「開発でも使える」という気づき

2023年5月、私は開発でChatGPTを使い始めた。

最初は半信半疑だったが、GPT-4が登場し、コードの質が劇的に向上した。

「これは...本気で開発に使えるかもしれない。」

そして、試しに使ってみると――

私: 「Pythonでリストの重複を削除する最も効率的な方法は?」

ChatGPT: 「setを使う方法が最も簡潔です。」

unique_list = list(set(original_list))

「ただし、順序を保持したい場合はdict.fromkeys()を使います。」

unique_list = list(dict.fromkeys(original_list))

これは...使える。

このフェーズでできたこと

コードレビュー

私: 「このコードをレビューして」
(コードを貼り付け)

ChatGPT: 「以下の問題があります:
1. エラーハンドリングがない
2. 変数名が不明瞭
3. パフォーマンスの問題...」

関数の生成

私: 「日付をYYYY-MM-DD形式にフォーマットする関数を書いて」

ChatGPT: (完璧な関数を生成)

バグの修正提案

私: 「このエラーの原因は?」

ChatGPT: 「NullPointerExceptionが出ています。
11行目でuserがnullの可能性があります。」

このフェーズの限界

コピペが必要

  • コードをチャットにコピペ
  • 生成されたコードをエディタにコピペ
  • 往復が面倒

コンテキストが失われる

  • プロジェクト全体を理解できない
  • ファイル間の関係が見えない

1関数単位が限界

  • 複数ファイルの編集は無理
  • 大規模なリファクタリングは不可能

このフェーズの学び

「AIは賢いアシスタント」

聞けば答えてくれる。しかし、プロジェクト全体は理解していない。

開発者の役割: コードを書き、AIに部分的に助けてもらう


第2フェーズ(2025年1月〜5月):Cursorで世界が変わった

IDEの中にAIがいる衝撃

2025年1月、Cursorを初めて使った瞬間、世界が変わった。

エディタでCtrl+Kを押すと、AIがその場でコードを提案してくる。

// コメントを書くと...
// ユーザーを取得する関数

// Ctrl+K を押すと、AIが提案
async function getUser(userId: string): Promise<User> {
  const user = await db.users.findById(userId);
  if (!user) {
    throw new Error('User not found');
  }
  return user;
}

コピペが要らない。 これは革命だった。

このフェーズでできたこと

インライン補完

  • タイプすると、AIが次のコードを提案
  • Tabキーで受け入れ

コード選択してAIに指示

コードを選択 → Ctrl+K
「このコードをasync/awaitに変換して」
→ 即座に変換される

チャットでプロジェクト全体を参照

私: 「@codebase この認証の実装、どこにある?」

Cursor: 「auth/login.tsに実装されています。
さらに、auth/middleware.tsでJWT検証を行っています。」

複数ファイルの同時生成

私: 「ユーザー管理APIを作って」

Cursor: 
- routes/users.ts
- controllers/userController.ts
- models/User.ts
を一度に生成

このフェーズの限界

ローカルファイルの操作まで

  • コマンド実行は不可
  • データベースやサーバーの起動は手動

プロジェクト外へのアクセス不可

  • 外部APIの確認は自分で
  • ドキュメントは別途検索

このフェーズの学び

「AIがIDE常駐」

コードを書く横にAIがいて、常にサポートしてくれる。

開発者の役割: 設計を考え、AIに実装を任せる


第3フェーズ(2025年5月〜7月):Claude Desktopの衝撃

MCPがもたらした革命

2025年5月22日、Claude Sonnet 4がリリースされた。

そして、MCP(Model Context Protocol) が登場した。

これは、AIがローカル環境に直接アクセスできるようにする仕組みだ。

MCPで何が変わったのか

従来:

私: 「src/auth/login.tsを見て」
→ ファイルの内容をコピペして貼り付ける

MCP導入後:

私: 「src/auth/login.tsをレビューして」

Claude: (自動的にファイルを読み込む)
「このファイルには以下の問題があります...」

AIがファイルシステムに直接アクセスできる。 これは衝撃だった。

このフェーズでできたこと

マルチファイルの同時編集

私: 「認証システム全体をリファクタリングして」

Claude: 
- auth/login.ts
- auth/middleware.ts
- auth/jwt.ts
を同時に編集

プロジェクト全体の理解

私: 「このプロジェクトの構造を説明して」

Claude: (全ファイルを分析)
「このプロジェクトはクリーンアーキテクチャで構成されています。
controllers、usecases、repositoriesの3層に分かれており...」

新規プロジェクトの雛形生成

私: 「React + TypeScript + Tailwindのプロジェクトを作って」

Claude: 
- ディレクトリ構造を作成
- 設定ファイルを生成
- 基本コンポーネントを配置

簡単なバグ修正の開始

私: 「この画面で表示がおかしくなるバグがある」

Claude: 
1. 関連ファイルを分析
2. 原因を特定(CSS競合)
3. 複数ファイルを同時に修正
4. 「修正しました。確認してください」

私: 「直った!」

このフェーズから、新規開発だけでなく既存コードのバグ修正もAIに任せられるようになった。

ただし、まだ簡単なバグ(UI表示崩れ、単純なロジックエラー)が中心で、複雑なバグは人間が対応する必要があった。

このフェーズの限界

コマンド実行は手動

Claude: 「npm installを実行してください」
私: (ターミナルで実行)

エラーの確認が手動

私: 「エラーが出たよ」(エラーメッセージをコピペ)
Claude: 「このエラーは...」

「Vibeコーディング」的な開発

  • 「なんとなく動くもの」は作れる
  • しかし、プロダクション品質ではない
  • CI/CD、テスト、品質管理は手動
  • PoC(概念実証)やプロトタイプ開発が中心
  • 本格的な運用には別途作業が必要

コンテキストウィンドウの限界

私: 「このプロジェクト全体をリファクタリングして」

Claude: (ファイルを読み込み始める)

しかし...
- プロジェクトが大きすぎる(100ファイル以上)
- コンテキストウィンドウが溢れる
- 途中で重要なファイルが抜け落ちる
- 「一部のファイルしか参照できませんでした」

「大規模プロジェクトは無理か...」

コンテキストウィンドウの制限:

  • Claude 3: 約200,000トークン(約15万語)
  • 大規模プロジェクトでは全ファイルを読み込めない
  • 重要なファイルを手動で指定する必要がある
  • ファイルが多いと、古い情報が「忘れられる」
  • コンテキストの優先順位付けが困難

チャット継続の苦痛:

私: (長時間開発を続けている...)

Claude: 「コンテキストが一杯になりました」

私: 「新しいチャットを開始」

新しいチャットで...
私: 「このプロジェクトは〇〇で、今〇〇を実装していて...」
(長い説明)

私: 「では、続きをお願い」

Claude: (また少し開発...)
「コンテキストが一杯になりました」

私: 「また新しいチャット...」
「また一から説明...」
「また一から説明...」

この繰り返し。とてもつらい。

セッション管理の課題:

  • 長時間の開発でコンテキストが溢れる
  • 新しいチャットを開始すると、前提知識がリセット
  • プロジェクトの背景、アーキテクチャ、制約を毎回説明
  • 「前のチャットで〇〇と決めた」が通じない
  • 開発の流れが途切れる
  • 説明の繰り返しで疲弊する

このフェーズの学び

「AIがローカル環境を理解」

プロジェクト全体を俯瞰し、複数ファイルを同時に扱える。
ただし、まだ「本格的な開発」には一歩手前の状態。

開発者の役割: 要件を伝え、AIがマルチファイル編集する(品質管理は人間)


第4フェーズ(2025年7月〜8月):Claude Codeで自律性が加速

「Vibeコーディング」から「本格開発」へ

2025年7月、Claude Codeが登場した。

これは、AIがコマンドを実行できるようにしたツールだ。

そして、このフェーズで開発のパラダイムが大きく変わった。

第3フェーズまで:

  • 「なんとなく動くもの」を作る
  • PoC、プロトタイプ開発が中心
  • CI/CD、テストは手動で後から追加
  • いわゆる「Vibeコーディング」

第4フェーズから:

  • プロダクション品質のコードを生成
  • CI/CD、E2Eテストも自動構築
  • 品質管理もAIが担当
  • 本格的な開発フェーズへ突入

AIが自分でコマンドを実行し始めた

何が変わったのか

従来(Claude Desktop):

Claude: 「npm installを実行してください」
私: (手動で実行)
私: 「実行したよ」

Claude: 「では、npm run devを実行してください」
私: (手動で実行)

Claude Code:

私: 「このプロジェクトをセットアップして実行して」

Claude Code: 
1. npm install を実行(自動)
2. .env ファイルを作成(自動)
3. npm run dev を実行(自動)

「開発サーバーが http://localhost:3000 で起動しました」

AIが自律的に動く。 これは新しい世界だった。

このフェーズでできたこと

完全な開発ループ

私: 「ログイン機能を実装してテストして」

Claude Code:
1. コードを生成
2. npm test を実行
3. エラーを確認
4. コードを修正
5. 再度テスト実行
6. 「すべてのテストが通りました」

デバッグの自動化

私: 「このバグを修正して」

Claude Code:
1. エラーログを確認
2. 原因を特定
3. コードを修正
4. テスト実行
5. 「修正完了しました」

環境構築の自動化

私: 「このプロジェクトを本番環境にデプロイして」

Claude Code:
1. ビルド実行
2. テスト実行
3. Docker イメージ作成
4. デプロイコマンド実行

CI/CDパイプラインの自動構築

私: 「GitHub Actionsでテストと自動デプロイを設定して」

Claude Code:
1. .github/workflows/ci.yml を作成
2. テストジョブを設定(ユニットテスト、リント、型チェック)
3. デプロイジョブを設定(ステージング、本番環境)
4. 環境変数とシークレットの設定手順を提示
5. プルリクエスト時の自動テストを有効化

「CI/CDパイプラインが完成しました。
プルリクエストを作成すると自動でテストが実行され、
mainブランチへのマージ時に自動デプロイされます。」

E2Eテストの自動生成と実行

私: 「Playwrightでログインからダッシュボード表示までのE2Eテストを作って」

Claude Code:
1. Playwrightのセットアップ
2. tests/e2e/login.spec.ts を作成
3. ログインフローのテスト実装
4. ダッシュボード表示のテスト実装
5. スクリーンショット比較の設定
6. npx playwright test を実行

「すべてのE2Eテストが通りました。
CI/CDパイプラインにも統合しますか?」

テストカバレッジの自動改善

私: 「このプロジェクトのテストカバレッジを80%以上にして」

Claude Code:
1. 現在のカバレッジを確認(45%)
2. カバレッジが低いファイルを特定
3. 不足しているテストを順次追加
4. エッジケースのテスト追加
5. カバレッジレポート生成

「テストカバレッジが85%になりました。
CIでカバレッジチェックも有効にしますか?」

開発体験の本格化

このフェーズから、開発体験が劇的に変わった。

Vibeコーディングの時代は終わった。

第0〜3フェーズの「Vibeコーディング」:

開発者: 「ログイン機能作って」

AI: (コードを生成)

開発者: 「動いた!」

しかし...
- テストは書いていない
- CI/CDは未設定
- エラーハンドリングは不十分
- プロダクションでは使えない

→ 後から手動で品質を上げる作業が必要

第4フェーズからの「本格開発」:

開発者: 「ログイン機能作って」

AI: 
1. 実装コード生成
2. ユニットテスト生成
3. E2Eテスト生成
4. CI/CDパイプライン構築
5. エラーハンドリング実装
6. セキュリティチェック
7. カバレッジ確認

「ログイン機能が完成しました。
すべてのテストが通り、CI/CDも設定済みです。
プロダクション環境にデプロイできます。」

→ 最初からプロダクション品質

従来は手動で行っていた作業:

  • ❌ CI/CD設定ファイルをYAMLで書く
  • ❌ E2Eテストを1つずつ手書きする
  • ❌ テストカバレッジを上げるために時間をかける
  • ❌ デプロイ手順をドキュメント化して手動実行

Claude Codeで自動化:

  • ✅ 「CI/CD設定して」→ 完全なパイプライン構築
  • ✅ 「E2Eテスト作って」→ 網羅的なテスト自動生成
  • ✅ 「カバレッジ80%にして」→ 自動でテスト追加
  • ✅ 「デプロイして」→ 自動でビルド・デプロイ

開発の質と速度が、両方同時に向上した。

「動くものを作る」から「プロダクションで運用できるものを作る」へ。

このフェーズの限界

大規模プロジェクトでの不安定さ

  • 複雑な依存関係で迷うことがある
  • 長時間の実行で途中で止まる

コンテキストの管理

  • セッションが長くなると混乱
  • プロジェクトの履歴管理が弱い

コード品質の不安定さ

私: 「この機能を実装して」

Claude Code: (実装完了)

私: 「テスト実行」
→ エラー多発

私: 「バグを修正して」

Claude Code: (修正試行)

私: 「まだエラーが出る」

Claude Code: (再度修正)

私: 「別のエラーが出た...」

何度繰り返しても直らない。
最終的に人間が手動で修正する羽目に。

意図しないコードの生成

私: 「シンプルなログイン機能を実装して」

Claude Code: 
- なぜか複雑な認証フレームワークを導入
- 不要な依存関係を大量に追加
- オーバーエンジニアリング

「こんな複雑なものは求めていない...」

バグ修正の悪循環

  • バグAを修正 → バグBが発生
  • バグBを修正 → バグAが再発
  • 同じ問題を何度も修正させられる
  • 最終的にコードが混乱状態に

エラーの抑制(握りつぶし)が頻発

私: 「このエラーを修正して」

Claude Code: (修正完了)
→ 実は try-catch で握りつぶしただけ

コード例:
try {
  // 問題のあるコード
  problematicFunction();
} catch (error) {
  // エラーを無視
  console.log(error); // ログに出すだけ
}

「エラーは出なくなったけど、根本的に解決していない...」

さらに悪質なパターン:

// ハードコードされたフォールバック値で誤魔化す
try {
  const userData = await fetchUser(userId);
  return userData;
} catch (error) {
  console.error(error);
  // エラー時にハードコードされた値を返す
  return {
    id: "unknown",
    name: "Guest User",
    email: "guest@example.com"
  };
}

// APIエラーを隠蔽してデフォルト値を返す
const getConfig = () => {
  try {
    return fetchRemoteConfig();
  } catch {
    // 本当はエラーなのに、固定値を返して正常を装う
    return { timeout: 3000, retries: 3 };
  }
};
  • エラーログを出力するだけで問題を放置
  • 空の catch ブロックでエラーを無視
  • ハードコードされた値やフォールバックで誤魔化す
  • try-catch で全てを囲んで、エラー時は適当な値を返す
  • エラーを隠蔽して「修正しました」と報告
  • 後で本番環境で致命的なバグに発展
  • デバッグが困難に(エラーが見えない)

このフェーズは「本格開発」への入り口だったが、まだ信頼性に課題があった。

このフェーズの学び

「AI主導の開発ループと本格的な自動化」

AIが実装・テスト・デバッグのサイクルを自律的に回せるだけでなく、
CI/CD、E2Eテスト、カバレッジ改善など、プロダクション開発に
必要な全ての自動化を実現。開発体験が本格化した。

開発者の役割: 要件を伝え、結果を確認する。品質管理はAIに任せられる。


第5フェーズ(2025年8月〜10月):Codexで開発が「共創」になった

GPT-5の登場が全てを変えた

2025年8月7日、GPT-5がリリースされた。

そして、Codex がGPT-5を搭載して登場した。

このフェーズで、開発は「指示する」から「共創する」に変わった。

GPT-5 × Codexの衝撃

信頼性の飛躍:

従来のAIは、時々間違ったコードを生成した。しかし、GPT-5搭載のCodexは、ほぼ完璧だった。

私: 「決済システムを実装して」

Codex:
- Stripeとの連携
- トランザクション管理
- エラーハンドリング
- ロールバック処理
すべて完璧に実装される

自律性の向上:

Codexは、長時間にわたって安定して動作する。

私: 「このアプリ全体をリファクタリングして」

Codex:
(2時間かけて)
- 50ファイルを分析
- アーキテクチャを改善
- テストを実行
- ドキュメントを更新

「リファクタリングが完了しました。
すべてのテストが通っています。」

このフェーズでできたこと

大規模アプリの修正

私: 「このレガシーシステムをモダン化して」

Codex:
- 100ファイル以上を分析
- 段階的に移行計画を作成
- 1つずつモダン化
- すべてのテストを維持

セッション管理

Codex:
「昨日の続きから始めますか?」

私: 「はい」

Codex:
「昨日は認証システムのリファクタリングまで完了しました。
今日は決済システムに取り組みますか?」

チーム開発のサポート

Codex:
「Aliceさんが昨日修正したauth.tsと、
あなたが今編集しているpayment.tsに
競合が発生する可能性があります。」

このフェーズの限界

仕様の明確化は人間

  • 「何を作るか」は人間が決める必要がある
  • AIは「どう作るか」は完璧だが、「何を作るか」は提案まで

ビジネスロジックの妥当性

  • AIはコードは完璧に書けるが、
    「これはビジネス的に正しいか」は人間が判断

このフェーズの学び

「開発が共創になった」

AIは単なるツールではなく、一緒にプロジェクトを作るパートナー。

開発者の役割: ビジョンを示し、AIと協力して実現する


第6フェーズ(2025年10月〜):SDD統合で未来が見えた

仕様駆動開発との統合

2025年10月、Codex × SDDが登場した。

SDD(Spec-Driven Development) とは、仕様書を中心に開発を進める手法だ。

そして、Codexが仕様書と統合された。

何が変わったのか

従来:

私: 「ユーザー登録機能を作って」

Codex: 「どんな仕様ですか?」

私: 「メールアドレスとパスワードで登録して、
     メール確認が必要で、
     パスワードは8文字以上で...」
(長い説明)

SDD統合後:

私: 「@spec/user-registration.md を読んで実装して」

Codex: (仕様書を読み込む)
「仕様書を理解しました。
- メール + パスワード登録
- メール確認リンク送信
- パスワード強度チェック(8文字以上、英数字)
- レート制限(5回/15分)

実装を開始します。」

このフェーズでできたこと(実装中機能含む)

仕様からの自動実装

# spec/payment-system.md

## Overview
決済システム

## Requirements
- Stripe連携
- 定期課金対応
- 領収書自動発行
...
私: 「@spec/payment-system.md を実装して」

Codex:
- 仕様書を完全に理解
- 設計を提案
- 実装を完了
- テストも生成

仕様とコードの整合性チェック

Codex:
「警告: auth.ts のパスワード検証ロジックが
仕様書(spec/auth.md)と異なります。

仕様書: 8文字以上
実装: 6文字以上

修正しますか?」

仕様変更の自動反映

私: 「spec/auth.md のパスワード要件を10文字に変更」

Codex:
「仕様変更を検知しました。
影響を受けるファイル:
- auth/validation.ts
- auth/password.ts
- tests/auth.test.ts

すべて更新しますか?」

プロジェクト全体の一貫性

Codex:
「プロジェクトの仕様書とコードベースを分析しました。

一貫性: 98%
課題:
1. user-profile.ts が仕様書と乖離
2. payment.ts にテストが不足

修正しますか?」

このフェーズの革命的な点

1. 仕様が「唯一の真実の源泉」に

従来は、コードが真実だった。ドキュメントは古くなりがちだった。

SDD統合後は、仕様書が真実になった。

仕様書 → AI → コード
   ↑           ↓
   └──── フィードバック

2. チーム開発が劇的に改善

Product Owner: spec/new-feature.md を作成
Tech Lead: 仕様をレビュー・承認
Codex: 仕様から実装を生成
Developer: レビュー・調整

全員が仕様書を見れば、何を作っているか分かる。

3. AI駆動開発の完成形

人間の役割:
- ビジョンを描く
- 仕様を定義する
- ビジネス判断をする

AIの役割:
- 仕様を理解する
- 設計を提案する
- 実装する
- テストする
- 一貫性を保つ

このフェーズの学び

「開発体験が飛躍的に上がった」

仕様を書けば、AIが完璧に実装してくれる。
もはや「コードを書く」のではなく、「システムを設計する」時代。

開発者の役割: システムアーキテクトとして、全体を設計する


振り返り:開発者の役割はどう変わったか

この3年間で、開発者の役割は劇的に変わった。

役割の進化

フェーズ 開発者の役割 AIの役割
第0フェーズ 普通に開発、AIで情報収集 質問に答える(開発以外が中心)
第1フェーズ コードを書き、AIに質問する 質問に答える(開発支援開始)
第2フェーズ 設計を考え、AIに実装を任せる コードを生成する
第3フェーズ 要件を伝え、AIがマルチファイル編集 複数ファイルを理解・編集
第4フェーズ 要件を伝え、結果を確認 実装・テスト・デバッグを自律実行
第5フェーズ ビジョンを示し、AIと協力 パートナーとして共創
第6フェーズ システムを設計し、仕様を定義 仕様から完璧に実装

スキルの変化

減った作業:

  • ❌ ボイラープレートコードを書く
  • ❌ Stack Overflowを検索する
  • ❌ バグを1行ずつデバッグする
  • ❌ テストを手書きする

増えた作業:

  • ✅ システム全体を設計する
  • ✅ ビジネス要件を理解する
  • ✅ 仕様を明確に言語化する
  • ✅ AIの出力をレビューする

求められる能力:

従来の開発者:

  • コーディング能力
  • アルゴリズム知識
  • デバッグ力

AI時代の開発者:

  • 仕様設計力 ← 最重要
  • システム思考
  • 言語化能力
  • AI活用力

開発スピードの変化

実際の数字:

タスク: 新機能の実装(ユーザー認証システム)

第0フェーズ(ChatGPTで情報収集のみ):
開発時間: 3日
内訳: 設計1日、実装1.5日、テスト0.5日
AI活用: Google検索の代わりにChatGPTで調査

第1フェーズ(ChatGPTでコード生成):
開発時間: 2.5日
内訳: 設計0.5日、実装(コピペ)1.5日、テスト0.5日
AI活用: コード例を生成してもらい、コピペして調整

第2フェーズ(Cursor):
開発時間: 1日
内訳: 設計0.5日、実装0.3日、テスト0.2日
AI活用: IDE内でコード生成、補完を活用

第3フェーズ(Claude Desktop):
開発時間: 半日
内訳: 設計0.3日、実装0.1日、テスト0.1日
AI活用: マルチファイル同時編集

第6フェーズ(Codex × SDD):
開発時間: 3時間
内訳: 仕様作成1時間、実装(AI)1.5時間、レビュー0.5時間
AI活用: 仕様から完全自動実装

約6倍の生産性向上(第0フェーズ比)。
約24倍の生産性向上(ChatGPT以前比)。


まとめ:この3年間で学んだこと

1. AIは「ツール」から「パートナー」になった

最初は「便利なツール」だと思っていた。
今では「一緒にプロジェクトを作るパートナー」だと感じている。

2. 開発者の価値は「コードを書く速さ」から「システムを設計する力」に変わった

価値の変化:

従来: いかに速くコードを書けるか
今: いかに良い仕様を書けるか

3. 進化のスピードは加速している

第0フェーズ: 5ヶ月(2022年12月〜2023年4月)
第1フェーズ: 19ヶ月(2023年5月〜2024年12月)
第2フェーズ: 4ヶ月(2025年1月〜5月)
第3フェーズ: 2ヶ月(2025年5月〜7月)
第4フェーズ: 1ヶ月(2025年7月〜8月)
第5フェーズ: 2ヶ月(2025年8月〜10月)
第6フェーズ: 進行中

進化のサイクルがどんどん短くなっている。


おわりに:この3年間を振り返って

私の3年間を書いてきた。

皆様にも、異なる3年間があったことだろう。

AI時代の開発は、まだ始まったばかりだ。

この3年間は、序章に過ぎない。

次の3年間で、何が起こるのか――


参考資料

公式サイト

関連記事


この記事が、AI開発の旅の参考になれば幸いです。

1
2
0

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
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?