はじめに
みなさんの2025年は如何でしたでしょうか？
少し気が早いですが、今年１年を振り返ってみましょう。
📅 2025年 時系列サマリー（12月14日時点）
| 時期 | 地域 | 出来事 | カテゴリ | 参照元 |
|---|---|---|---|---|
| 12月31日(2024) | 🌐 グローバル | アジャイルアライアンスがPMIに統合 | 開発手法 | PMI |
| 1月3日 | 🌐 グローバル | PMI Agile Alliance発足を正式発表 | 開発手法 | PMI |
| 1月7-10日 | 🇺🇸 米国 | CES 2025開催 | イベント | CES |
| 1月 | 🇯🇵 日本 | IPA「情報セキュリティ10大脅威 2025」発表 | セキュリティ | IPA |
| 1月 | 🇯🇵 日本 | AIコーディングツール「Cline」がオープンソースツールとして注目 | AI開発ツール | GitHub |
| 1月13日 | 🇬🇧 英国 | AI Opportunities Action Plan発表 | AI政策 | UK Gov |
| 1月20日 | 🇨🇳 中国 | DeepSeek R1モデル発表、世界に衝撃 | AI技術 | DeepSeek |
| 1月25日 | 🇰🇷 韓国 | AI基本法署名（2026年施行） | AI規制 | Korea Herald |
| 2月 | 🇬🇧 英国 | AI Safety Institute → AI Security Instituteに改称 | AI政策 | UK AISI |
| 2月2日 | 🇪🇺 EU | EU AI Act 禁止AI慣行・AIリテラシー義務の適用開始 | AI規制 | EUR-Lex |
| 2月24日 | 🇺🇸 米国 | Anthropic「Claude Code」発表 | AI開発ツール | Anthropic |
| 2月25日 | 🌐 グローバル | 「Vibe Coding」概念をAndrej Karpathyが提唱 | 開発手法 | X/Twitter |
| 3月 | 🇯🇵 日本 | AI Guidelines for Businesses Version 1.1発行 | AI政策 | METI |
| 3月25日 | 🇯🇵 日本 | IPA「JC-STAR」運用開始 | セキュリティ | IPA |
| 5月 | 🇺🇸 米国 | Claude 4 Opus リリース（SWE-bench 72.5%） | AI技術 | Anthropic |
| 5月7日 | 🇯🇵 日本 | IPA「DX推進指標 分析レポート（2024年版）」公開 | DX | IPA |
| 5月21日 | 🇯🇵 日本 | JC-STAR ★1適合ラベル交付開始 | セキュリティ | IPA |
| 5月28日 | 🇯🇵 日本 | AI推進法（人工知能関連技術促進法）成立 | AI規制 | 首相官邸 |
| 6月 | 🇺🇸 米国 | OpenAI「o3-pro」公開 | AI技術 | OpenAI |
| 6月26日 | 🇯🇵 日本 | IPA「DX動向2025」発表 | DX | IPA |
| 6月5日 | 🇬🇧 英国 | ICO AI・バイオメトリクス戦略発表 | AI政策 | ICO |
| 7月3日 | 🇯🇵 日本 | 開発生産性カンファレンス2025開催 | イベント | Findy |
| 8月2日 | 🇪🇺 EU | EU AI Act GPAI規則適用開始 | AI規制 | EUR-Lex |
| 8月7日 | 🇺🇸 米国 | OpenAI「GPT-5」正式リリース | AI技術 | OpenAI |
| 8月12日 | 🇯🇵 日本 | IPA 高度試験等CBT方式移行発表 | 資格・試験 | IPA |
| 8月7日 | 🇺🇸 米国 | Microsoft、GPT-5統合発表（M365 Copilot等） | AI技術 | Microsoft |
| 8月 | 🌐 グローバル | TypeScriptがGitHubで最も使用される言語に | 開発トレンド | GitHub Octoverse |
| 9月 | 🇯🇵 日本 | NRI「IT活用実態調査（2025年）」発表 | 市場調査 | NRI |
| 9月10日 | 🇯🇵 日本 | IPA「情報セキュリティ白書2025」PDF版公開 | セキュリティ | IPA |
| 9月2日 | 🌐 グローバル | GitHub「Spec Kit」オープンソース公開 | 開発手法 | GitHub Blog |
| 10月14日 | 🌐 グローバル | Windows 10サポート終了 | セキュリティ | Microsoft |
| 10月14-17日 | 🇯🇵 日本 | CEATEC 2025開催 | イベント | CEATEC |
| 10月1日 | 🇯🇵 日本 | 情報処理安全確保支援士 登録者総数24,937名に | 資格・試験 | IPA |
| 10月28日 | 🌐 グローバル | GitHub Octoverse 2025発表 | 市場調査 | GitHub |
| 11月1日 | 🇺🇸 米国 | AI脆弱性管理統合期限 | セキュリティ | CISA |
| 11月12日 | 🇺🇸 米国 | OpenAI「GPT-5.1」リリース | AI技術 | OpenAI |
| 11月13日 | 🌐 グローバル | PMBOK第8版リリース | 開発手法 | PMI |
| 12月5日 | 🇺🇸 米国 | AWS CodeCommit廃止撤回・一般提供再開 | クラウド | AWS |
| 12月8日 | 🇯🇵 日本 | 耐量子計算機暗号（PQC）移行方針発表 | セキュリティ | デジタル庁 |
| 12月11日 | 🇺🇸 米国 | OpenAI「GPT-5.2」リリース | AI技術 | OpenAI |
| 12月 | 🇺🇸 米国 | AWS「AWS Interconnect - multicloud」プレビュー開始 | クラウド | AWS |
| Q1 | 🌐 グローバル | クラウド市場：AWS 29%、Azure 22%、GCP 12% | 市場動向 | Synergy Research |
※リンク切れやハルシネーションと思わしきものを削除しました（2025/12/14 12:30）
夜中にAIを使うものじゃないな、、、
生成AI、特にコーディングエージェントの進化スピードがとんでもない1年だったなと、、、
本題
なにを書こうかなと、かなり迷って、２本くらい下書きを書いてボツにしたりしました。
あまり風呂敷を広げすぎると広大になりすぎるなと思いましたので、
趣味で開発している中で気付いたTipsについて書いていきます。
誰かの役に立つと良いなと思います。
AI駆動開発Tips
事前準備
AI開発ツールの準備
- おすすめは、 メイン：Claude code サブ：Codex CLI
- MCP導入（Serena、context7、DevTools MCPの３つがあれば基本OK）
- spec-kit導入 GitHub spec-kit
ディレクトリ構成（ベース）
ルート
├── README.md # リポジトリ入口
├── CLAUDE.md # Claude codeが起動時に見るファイル
├── AGENTS.md # Codex CLIが起動時に見るファイル
├── 00_docs/ # ドキュメント（基本不変のもの）
├── 01_vision/ # TO-BE：ユースケース
├── 02_backlog/ # バックログ・進捗管理
└── specs/ # 実行：詳細仕様・テスト（開発作業領域）:spek-kitで自動生成
- この３ディレクトリを用意してから始めると良いです
CLAUDE.md（AGENTS.md）（初回）
# CLAUDE.md
## Work Policy
**重要: 時間短縮は考えず、ひとつづつ丁寧に作業を行うこと**
- すべてのタスクは品質を最優先し、丁寧に実施する
- 時間効率よりも正確性と完成度を重視する
- 各ステップを確実に完了してから次に進む
- 急がず、焦らず、確実に作業を進める
## Communication Guidelines
**重要: すべての返答は日本語で行うこと**
- ユーザーとのコミュニケーションは常に日本語で行う
- コードコメント、コミットメッセージ、ドキュメントも日本語で記述する
- エラーメッセージやログも可能な限り日本語で説明する
## Code Documentation Guidelines
**重要: すべての新規追加・修正時にはドキュメンテーションコメントを記載すること**
### ドキュメント記載のタイミング
- **新規コード追加時**: 実装と同時にドキュメントを記載
- **既存コード修正時**: 変更内容に応じてドキュメントを更新
- **コードレビュー時**: ドキュメントの有無と正確性を確認
- これくらいは最初に書いておくと楽
要求分析
00_docs/ # プロジェクト基盤ドキュメント
├── 01_SystemOverview.md # 作りたいシステムの概要
└── 99_standard # 開発標準
├── 01_ArchitectureDesign.md # 技術側（アーキテクチャ、開発標準）
├── 02_CodingStandards-Backend.md # 技術側（コーディング規約：バックエンド）
├── 03_CodingStandards-FrontEnd.md # 技術側（コーディング規約：フロントエンド）
├── 04_SecurityDesign.md # セキュリティ設計
└── 05_Non-FunctionalRequirements.md # 非機能
- これらは事前に用意しておくと良い
- 1ファイルづつAIに「○○を作りたいので、<ファイル名>を作成して欲しい」で生成
これはChatGPT等とやりとりしながら進めるのが良い - 01_ArchitectureDesign.mdで技術スタックを指定するので、学びたい技術とフォルダ構成を指定しておく
CLAUDE.mdの更新
ファイルが揃ったら
一度CLAUDE.mdを最新化します。claude codeに入り、
/init
することで、最新化できます。
特に「00_docs/」内の各ファイルへのリンクがあることを確認しておきましょう。
要求仕様
01_vision # TO-BE：ユースケース
└── INI-XXX # 一応切っておく
├── screen-design.md # 画面設計：画面一覧、画面遷移図
└── usecases/ # ユースケース
├── README.md # サマリー
├── UC-XXX-xxx.md # ユースケース
└── UC-XXX-xxx.md # ユースケース
初回は特に、画面一覧と画面遷移図は用意しておくと良いです。
ChatGPTなどと相談しながら詰めておきましょう。
画面設計はdocsに置いて更新し続けるのもありですが、
AS-IS、TO-BEが混在すると混乱を生むので、実装完了したタイミングでdocsに移し、
対応中のものは「01_vision」か「02_backlog」に置く方がなにかと便利です。
画面設計が用意できたら、docsの資料と画面設計を元に、ユースケース毎にファイルを生成させます。
- プロンプト例：
00_docs/配下の資料と、01_vision/INI-XXX/screen-design.mdを元に、「01_vision/INI-XXX/usecases/」にユースケース単位でファイルを生成し、サマリーを作成して
- 特に初回は規模が大きくなりがちなので、これを挟むと良いです
要件定義
02_backlog/ # バックログ・進捗管理
└── 00_epics/
├── EPIC-000-init/ # エピック：基盤構築
│ ├── README.md # エピック概要
│ └── ST-XXX-xxx.md # ユーザーストーリー
│ └── ST-XXX-xxx.md # ユーザーストーリー
├── EPIC-XXX-xxx/ # エピック
│ ├── README.md # エピック概要
│ └── ST-XXX-xxx.md # ユーザーストーリー
│ └── ST-XXX-xxx.md # ユーザーストーリー
└── EPIC-XXX-xxx/ # エピック
├── README.md # エピック概要
└── ST-XXX-xxx.md # ユーザーストーリー
└── ST-XXX-xxx.md # ユーザーストーリー
基盤構築要件
- プロンプト例：
00_docs/を元に、開発基盤を構築したい。02_backlog/00_epics/EPIC-000-init/に概要ファイルと、ユーザーストーリー単位のファイルを生成して。各機能は別で実装する為、基盤構築のみを対象とすること。また、静的解析ツールの導入を合わせて追記してください。
機能要件
- プロンプト例：
01_vision/INI-XXX/usecases/UC-XXX-xxx.mdを元に、02_backlog/00_epics/EPIC-XXX-xxx/に概要ファイルと、ユーザーストーリー単位のファイルを生成して
- これは初回など規模が大きくなりがちな場合なので、基盤ができてしまえば、
ユースケースからではなく、
○○を追加したいので、02_backlog/00_epics/EPIC-XXX-xxx/に概要ファイルと、ユーザーストーリー単位のファイルを生成して
でも良い
- アジャイルでは一般的に「Use Case」は使われないそうだが、追加したい機能が、複数画面や機能を跨ぎそうであれば「Use Case」単位で一度分割するとそれなりにちょうど良いサイズ感のEpicになる
※恐らく、手でドキュメントを書く場合では、「Use Case」まで書くのは冗長気味であることと、
ドキュメントの保守コストが高くなるので、使われないのだろうと推測する。
AI駆動の場合には、コンテキストを分割する方が実装漏れが起きにくい。
UIデザイン
- Claudeのチャット側で叩きを生成させるのが個人的に楽（ChatGPTよりclaudeの方が強そう）
- ワイヤーフレームと明示して必要な項目を指定し、レイアウトを整えてもらう
- レイアウトに問題がなければデザインを綺麗にしてもらう
（この段階を踏まずともお任せでそれっぽいものは出してくれるので、拘りがなければお任せでも良い） - チャット側だけで連続して指示しているとそのうち壊れるので（コンテキストが溢れる）、
壊れそうになったらダウンロードしてローカルでClaude Code側に任せると良い
生成したjsxなりhtmlなりは、
epic内に格納し、ユーザーストーリ内から参照するようにしておくと良いでしょう。
詳細設計 -> テスト計画 -> 実装準備 -> 実装
spec-kitの利用
ここまできてやっとspec-kitを利用します。
spec-kitの使い方は、公式などを参照のこと。
公式や、記事を読むと
/speckit.specify <実現したいこと>
と説明されているが
// 開発標準を定義
/speckit.constitution 00_docs/99_standard/
のようにフォルダやパスを渡すことも可能。
// ユーザーストーリー単位でspek-kitに依頼
/speckit.specify 02_backlog/00_epics/EPIC-000-init/ST-XXX-xxx.md
// 仕様の曖昧な点を確認:基本推奨で良い
/speckit.clarify
// 実装プラン作成：（例だと引数を渡していることが多いが、引数なしで問題ない）
/speckit.plan
// 実装タスク作成：（例だと引数を渡していることが多いが、引数なしで問題ない）
/speckit.tasks
ここまでくると
specs/
└── 001-init/ # 自動で採番
├── checklists/
├── contracts/
├── data-model.md
├── plan.md
├── research.md
├── spec.md
└── tasks.md
このような感じのものが出力される。
公式や、記事だとここから「/speckit.implement」で実装に入っていくのだが、
デフォルトだとテストケースが足りない。
なので、Claude codeに対して
specs/001-init/の内容を確認し、specs/001-init/tests/配下にテストケースを追加して欲しい。正常系、異常系、エッジケースを含めて追加して欲しい。必要に応じてファイルを分割して下さい。
このようにして
specs/
└── 001-init/ # 自動で採番
├── tests/ # 単体テストケース（後から追加）
├── checklists/
├── contracts/
├── data-model.md
├── plan.md
├── research.md
├── spec.md
└── tasks.md
単体テストケースを拡充しておくと、考慮漏れや実装ミスが減る。
ここまできたら
// 実装依頼
/speckit.implement
で実装を進めさせます。
最後まで実装し切ることはほぼないのですが、「/speckit.implement」は初回の１回のみで問題なく
それ以降はClaude codeなりCodex cliなりに指示を出していけばOKです。
あとは、実装->静的解析->単体テスト->実装...を繰り返してもらい、
実装が完了したらコミットしておき、
// 次のユーザーストーリーを元にspek-kitに依頼
/speckit.specify 02_backlog/00_epics/EPIC-000-init/ST-XXX-xxx.md
先ほどのコマンドで次のユーザーストーリーを渡して、
テストケースを追加生成して、
また、実装->静的解析->単体テスト->実装...を繰り返させる流れになります。
閑話休題
※こんな大げさな手順を踏まずとも
Spec Kitを使って簡単な家計簿アプリ実装してみた
GitHub製のSpec Kitで仕様駆動開発に入門してみた
のように、気軽に使えたりはするのですが、
はまったポイント
- 粒度が大きい指示だとバグを上手く修正できない
- レビュー量も多すぎて、認知負荷高すぎ+追いつかない
- テスト駆動で作らせても、テスト通らないままで放置してくる
- テストの分量もかなり多いので、すべて通る状態にするのがかなり難しいので結果形骸化しがち
- 細かなミスで起きるバグを上手く直してくれないこともあるので、その時は自身でデバッグして治す必要がたまにあった
というハマりポイントを回避しようと思うと、
これくらい準備しておくと軽減されます。（完全にはなくならない）
人が開発する時同様にオンボーディング資料を用意し
ドメイン単位やシナリオ単位などに分割してから依頼する方がコンテキストが広くなりすぎず
漏れが少なくなるのだろうなと感じています。
この手法の良いところ
「Use Case」が基本ドメイン単位で切られるので、
「Use Case」毎に別のコンソールを立てて、並行作業を進めてもコンフリクトが限定的になるので
複数作業を同時並行で行いやすい点かなと思います。
※Git worktreeの利用は必要
世界一わかりやすくGit worktreeを解説！AI駆動開発でも活用できる並列開発の方法
まとめ
要件定義から実装、テストまで(ほぼ)全工程にAIを活用する場合のTipsでした。
障害調査や障害対応、IaC、CI/CDまでは今回踏み込めていないので、
そこの知見が溜まってきたらまた別記事を書いてみようかと思います。
AI駆動開発は楽しい！