AIエージェント on Feature Branch Tech Blog

仕様駆動開発 — Specsを中心とした開発フロー

Mon, 02 Feb 2026 10:00:00 +0900

はじめに

2025年、**仕様駆動開発（Spec-Driven Development）**が話題になり、関連ツールを試してみました。しかし、従来のSDDには「ドキュメント過剰」の課題を感じ、直近の開発で試行錯誤する中での、私なりのアプローチを整理します。

1. 仕様駆動開発の理想と現実

2025年、AIコーディングエージェントの登場により**仕様駆動開発（Spec-Driven Development）**が再注目されています¹。

SDDの理想

SDDの理想では、Specレビュー → 実装 → テスト/検証 → フィードバックのサイクルが日単位で回転し、AIにより爆速化されるはずでした²。

flowchart LR
 A[📝 Spec作成] --> B[🔍 Specレビュー]
 B --> C[💻 AI実装]
 C --> D[✅ テスト/検証]
 D --> E{フィードバック}
 E -->|修正| A
 E -->|OK| F[🎉 リリース]

現実の課題

しかし、実際にSDDを試してみると、いくつかの課題が見えてきました。

課題	説明
Specの巨大化	小さな機能追加でも数千行のSpecが生成され、レビューが重くなる²
正確性検証の難しさ	LLMが確率的な出力をする以上、Specのみで実装漏れやミスを防ぐのは難しい
組織的な調整	エンジニア単独では完結せず、PM・QAなど複数ステークホルダーの関与が必要
小規模開発への不適合	単純なバグ修正に詳細仕様を書くのはオーバーヘッド

開発手法の歴史 — 振り子の揺れ

開発の歴史は、「重すぎる文書化」と「軽すぎる文書化」の間で振り子のように揺れ動いてきました。³

flowchart LR
 subgraph 歴史の振り子
 A[📚 ウォーターフォール
重すぎる文書化] -->|反動| B[🏃 アジャイル
軽すぎる文書化]
 B -->|反動| C[📝 SDD
再び仕様重視?]
 C -->|課題| D[🎯 バランスを探る]
 end

アジャイル開発は「重すぎる文書化」の反動として生まれましたが、別の課題も生まれました。

【実践】AIエージェントでのコーディング指南書 - 4ヶ月の開発から学ぶプロンプト術

Wed, 07 Jan 2026 10:00:00 +0900

はじめに

「AIエージェントを使ってみたけど、うまく動かない」「何を指示すればいいかわからない」——そんな声をよく聞きます。

この記事は、約4ヶ月間AIエージェント（Claude Code、Codex CLIなど）を使って開発してきた経験から見つけた、効果的なパターンをまとめた指南書です。これまで各自が試行錯誤しながら使ってきましたが、知見が整理されないまま属人化していました。開発チームに新メンバーが加わったこのタイミングで、改めてノウハウを整理・共有することにしました。

1. 効果的なプロンプトの書き方

1.1 「@ファイルパス」でコンテキストを明示する

AIエージェントは賢いですが、読心術は使えません。どのファイルの話をしているのか、明示的に教えてあげましょう。

1
2
3
4
5
6
7


❌ 悪い例：
「このエラーを直して」

✅ 良い例：
「@src/components/user-profile/sections/department-info.tsx
について、部署名がIDのまま表示されてしまっています。
原因を調査して修正してください。」

Anthropic のベストプラクティスでも、「giving clear directions upfront reduces the need for course corrections later」（最初に明確な指示を与えることで、後から軌道修正する必要が減る）と述べられています¹。

@記法のポイント：

ポイント	良い例	悪い例
フルパスで指定	`@src/components/.../file.tsx`	`file.tsx を見て`（どこにあるか不明）
複数ファイル比較時	両方のパスを明示	「もう一つのファイルと比較して」

1.2 問題の背景・文脈を詳細に説明する

実際の開発で効果的だったプロンプトパターンを見てみましょう。

1
2
3
4
5
6
7


元請けベンダーから以下の質問が来ています。
コードベースやSalesforceの現在のライセンス構成での
ガバナ制限など、Context7やネット調査も含めて調査してください。

---

[質問内容をそのまま貼り付け]

このプロンプトには以下の要素が含まれています。

【2025年版】エンジニア向けAI用語整理ガイド

Mon, 01 Dec 2025 00:00:00 +0900

はじめに

最近のIT開発では「AI」「LLM」「エージェント」といった言葉が飛び交っています。この記事では、これらの用語をざっくり整理してみます。

そもそもAIとは？

AI（Artificial Intelligence / 人工知能） とは、人間の知的な振る舞いをコンピュータで再現しようとする技術の総称です。

具体的には以下のような能力があります。

画像認識（写真に何が写っているか判定）
音声認識（話し言葉をテキストに変換）
自然言語処理（テキストの意味を理解・生成）
推論・判断（データから予測や意思決定）

ポイント: AIは非常に広い概念で、チェスを打つプログラムも、ChatGPTも、自動運転も、すべて「AI」です。

LLMとは？

LLM（Large Language Model / 大規模言語モデル） とは、膨大なテキストデータを学習し、人間のような文章を理解・生成できるAIのことです。

代表的なものは以下です（2025年12月時点）。

GPT-5 / o3（OpenAI）
Claude Opus 4.5 / Sonnet 4.5（Anthropic）
Gemini 3（Google）
Llama 4（Meta）

モデルとは？

「モデル」とは、学習済みのAIの「頭脳」部分のことです。

学習データ（インターネット上の大量のテキスト）を使って
パターンを学習し
出力（回答や文章）を生成できる状態になったもの

同じLLM製品でも、複数のモデルが提供されています。

Claude: Haiku 4.5（軽量・高速）、Sonnet 4.5（バランス型）、Opus 4.5（高性能）
GPT: GPT-5 Mini（軽量）、GPT-5（標準）、o3（推論特化）
Gemini: Flash（高速）、Pro（標準）、Deepthink（推論特化）

モデルの性能は重要

「とりあえず動けばいいや」ではなく、適切なモデル選択が重要です。

理由は次の通りです。

回答の正確性 - 高性能モデルほど複雑な質問に正確に答えられる
コード生成の品質 - バグの少ない、保守しやすいコードを生成
指示の理解力 - 曖昧な指示でも意図を汲み取れる
コストとのバランス - 単純なタスクには軽量モデル、複雑なタスクには高性能モデルを使い分ける