開発効率化 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

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

2ターン設計で精度を上げる：VSCode×Codexのやりとり術

Thu, 22 Jan 2026 10:00:00 +0900

はじめに

「VSCodeからCodexにお願いしたけど、意図とズレた」――そんな経験はありませんか。私自身、短く書くと精度が落ち、長く書くと伝える内容が散らばることがありました。

そこで効果があったのが2ターン設計です。1回目で前提を確認し、2回目で実行に移す。たったそれだけで、精度と納得感が上がりました。この記事では、VSCode×Codexで使える「2ターンの型」を整理します。

1. なぜ1回でうまくいかないのか

LLMは文脈が不足していると、良い推測はしても本当に欲しい答えに辿り着けないことがあります。公式のプロンプト指針でも「目的・制約・期待する出力」を明確に伝えることが推奨されています¹²。

つまり、1回目の指示で「必要な前提が足りているか」を確かめるだけで、2回目の成功率が大きく上がります。

2. 2ターン設計の全体像

2ターン設計は、**確認（Turn 1）→実行（Turn 2）**の流れです。会話の段階を明確にするだけで、やりとりが安定します。

flowchart LR
 A[Turn 1: 調査・前提確認] --> B[Turn 2: 実装・反映]

Turn 1: 調査・前提確認

このターンでは、**「何を、どこまで、どういう形で」**を固めます。足りない情報があれば質問してもらい、必要な前提を揃えるのが目的です。質問してから進めるスタイルは公式例でも推奨されています³。

Turn 2: 実装・反映

Turn 1で前提が揃ったら、実装・修正・整理などを依頼します。ここでは作業のゴールと受け入れ条件が明確になっていることが大事です。

3. Turn 1のテンプレ（そのまま使える）

短くてもよいので、次の項目を伝えると迷いが減ります。

目的
変更範囲
期待する出力
制約（触らない場所、守るルール）
参照してほしいファイル

実際のテンプレはこんな感じです。

1
2
3
4
5
6
7


目的: 画面の表示崩れを直したい
変更範囲: @src/pages/order-detail/ だけ
期待出力: レイアウトが崩れずに表示されること
制約: UIの文言は変更しない
参照: @src/pages/order-detail/index.tsx

まず原因を調査して、必要なら質問してください。

ポイントは「まず調査して」と先にフェーズを指定することです。これだけで、いきなり修正を始めるリスクが減ります。

4. Turn 2のテンプレ（承認してから実行）

Turn 2では「OK、やってください」を明示します。明確な実行依頼が推奨されることは公式のベストプラクティスでも触れられています¹²。

1
2
3
4
5


ありがとうございます。修正案で進めてください。

- 変更は最小限で
- テストは不要
- 差分を最後にまとめてください

この形式だと、実装範囲が安定し、仕上がりの確認も楽になります。

【実践】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やネット調査も含めて調査してください。

---

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

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

頭脳 vs 手足：Claude Code（Opus 4.5）とCodex CLI（GPT-5.2）徹底比較

Tue, 06 Jan 2026 12:00:00 +0900

はじめに

2025年末から2026年にかけて、AIコーディングツールは新たなステージに突入しました。AnthropicのClaude Code（Opus 4.5）とOpenAIのCodex CLI（GPT-5.2）は、どちらも「AIエージェントが自律的にコードを書く」時代を切り開いています。

しかし、この2つのツールは設計思想が根本的に異なります。本記事では、**「頭脳 vs 手足」**という独自の視点からこの2大ツールを比較し、それぞれの強みと使い分けのポイントを解説します。

1. 両ツールの概要

まずは、それぞれのツールの基本的な特徴を押さえておきましょう。

1.1 Claude Code + Opus 4.5

Claude Codeは、Anthropicが提供するAIコーディングエージェントです。2025年11月にリリースされたOpus 4.5モデルと組み合わせることで、「世界最高のAIコーディングツール」を謳っています¹。

主な特徴は以下の通りです。

ローカルファースト設計: ターミナルやIDEに直接統合され、開発者のワークフローに溶け込む
インタラクティブな操作: 開発者が「コントロールを握り続ける」設計思想
チェックポイント機能: 作業の進捗を保存し、いつでも以前の状態にロールバック可能
ハイブリッド推論: 即座の応答と拡張思考を状況に応じて切り替え

1.2 Codex CLI + GPT-5.2

Codex CLIは、OpenAIが提供するオープンソースのAIコーディングエージェントです。GPT-5.2-Codexは、複雑なソフトウェアエンジニアリングタスクに最適化された専用モデルで、2025年12月にリリースされました²。

主な特徴は以下の通りです。

クラウドベース設計: タスクは隔離されたサンドボックス環境で非同期に処理
委任型ワークフロー: タスクを渡して「任せる」スタイル
長時間自律作業: テスト中に7時間以上連続して複雑なタスクに取り組んだ実績
サイバーセキュリティ強化: CTFチャレンジでの高精度を実証

2. 「頭脳 vs 手足」の比較軸

ここで本記事の核心となる比較軸を紹介します。

観点	GPT-5.2 Codex（頭脳型）	Claude Code + Opus 4.5（手足型）
設計思想	「深く考える」ことに最適化	「精密に実行する」ことに最適化
強み	巨大なコンテキスト、長時間思考	ローカル統合、ツール操作の精度
操作感	「従業員に任せる」感覚	「道具を使いこなす」感覚

2.1 GPT-5.2 Codex：「賢い頭脳」

GPT-5.2 Codexは、まさに**「頭脳派」**のAIエージェントです。