OpenSpec

AIに「作らせる」だけでは足りない時代 AIコーディングツール（Claude Code、Codex、Cursor など）を使う際、多くの開発者が次のプロンプトで止まってしまっている。 1 2 3 「作って」 「修正して」 「いい感じにして」 これで機能は動く。しかし、後から「なぜそうなったのか」が一切わからない。 Claude Code Studio（@ClaudeCode_love）が紹介した、Anthropic 社員が使っているとされるプロンプトは、その問題に真正面から切り込んでいる（公式声明ではなく、あくまで伝聞である点に注意）。 Anthropic 社員が使うプロンプト 元ツイート（2026-05-19）では「自分がいちばん使っているプロンプト」として次の指示が紹介されている。 1 2 3 仕様書通りに実装して。 その途中で、仕様書に書かれてなかった判断・変更・妥協点・意思決定を、 全部 implementation-notes に残して 英語で書くなら次のようになる。 1 2 3 Implement according to the specification. Along the way, record every judgment, change, trade-off, and decision not covered by the spec into implementation-notes. 一見地味に見えるが、これは AI コーディングの本質を突いたプロンプトだ。本記事では、このプロンプトを 「計画レビュー」と対比する形で深掘り し、なぜ AI コーディング時代に implementation-notes パターンが支配的になるのかを考察する。 ...

はじめに 「AIにコードを書かせるのは得意になったが、完成品が要件とずれていて全部作り直しになった」——そんな経験はないだろうか。 Vibe coding（感覚的なプロンプトだけでAIにコーディングさせるスタイル）は手軽な反面、AIとの認識齟齬が後から発覚してリワークが発生するリスクをはらんでいる。 OpenSpec は、その問題を「仕様駆動開発（SDD: Spec-Driven Development）」で解消するフレームワークだ。2025年8月に登場してから急速に普及し、2026年5月時点で⭐50,000超を獲得している。 GitHub: Fission-AI/OpenSpec npm: @fission-ai/openspec ライセンス: MIT Vibe Codingの落とし穴 AIコーディングアシスタントは非常に強力だが、要件がチャット履歴の中にしか存在しない場合、出力は予測不能になりやすい。よくある失敗パターンは次のとおり。 「ざっくり作って」と頼んだら意図と全く異なる設計になった 途中で要件変更を伝えたら、AIが古い前提を引きずった 長いセッションでコンテキストが失われ、最初の仕様が無視された OpenSpecはこれを「コードを書く前にAIと仕様に合意する」プロセスを導入することで防ぐ。 OpenSpecとは OpenSpecは、AIコーディングアシスタント向けの軽量な仕様レイヤーを提供するフレームワーク。プロジェクトに openspec/ ディレクトリを作り、変更ごとに proposal・specs・design・tasks の4つのアーティファクトを生成・管理する。 設計哲学: 1 2 3 4 5 → fluid not rigid （柔軟、固定フェーズなし） → iterative not waterfall （反復的、ウォーターフォールではない） → easy not complex （シンプル） → built for brownfield （既存プロジェクトにも対応） → scalable from personal projects to enterprises 主要コマンド（/opsx:* スラッシュコマンド） OpenSpecは /opsx:propose から始まる一連のスラッシュコマンドで動作する。 ...