📦
ワークスペース単位のMCP開発環境が欲しい with Codex & devcontainer

2025/10/02に公開
Model Context Protocol
devcontainer
Codex
tech
 到達点codexとMCP サーバー群（spec-workflow / serena / context7 ）を連携し、ワークスペース単位の仕様書駆動開発環境を実現

 GPT による要約この記事では、Codex と複数の MCP（Model Context Protocol）サーバー（spec-workflow, Serena, Context7）を組み合わせて、プロジェクト単位で切り替え可能な開発環境を、VSCode の devcontainer を使って構築する手法を紹介しています。

仕様書駆動開発の流れ（Steering → Requirements → Design → Tasks → Implementation）を LLM と連携させ、その信頼性を保つ仕組み（承認ゲート、ドキュメント参照）を含めて実例付きで解説しています。

 きっかけGPT の Team プランを契約中→codex をあまり使いこなせていない（もったいない）

GitHub MCP registry の誕生により、MCP サーバー関連の便利・手軽な環境が揃いつつある。
自分の手元でサンドボックス的なお試し環境が欲しい

プロジェクトごとに MCP サーバーを切り替えて開発したい

仕様書駆動開発してみたい

 仕様書駆動開発名前が表す通り「仕様」を定めることで、その後の一貫性を担保しようとする開発手法です。

LLM にコードを書かせる際にも、「なんか違う」とか「よくわからないけれど OK」的な実装をしてしまうことがあったのではないでしょうか？
仕様書を先に定めることで、LLM に実装させる内容を細分化することができるようです。
CyberAgent の方が プレゼンテーション をされていましたが、自動車の運転に例えて
エンジニアによる手動開発→MT
エンジニア＋Chat LLM→AT
エンジニア＋LLM エージェント→自動運転
的な考え方がしっくりきました。
ただ目的地につきたいなら自動運転で良いですが、F1 マシンでポディウムに立つには繊細なスキルを要するというわけです (早口)

 ツール選定Mac Book Pro M3内で構築
devcontainer
開発コンテナ環境

codex
LLM


spec-workflow-mcp
仕様書駆動開発 MCP サーバー


serena
シンボルベースで LLM がコードを参照する MCP サーバー


context7
LLM が公式のドキュメントを参照するようになる MCP サーバー


 出来上がったものhttps://github.com/moore-mua/MCP_Dev

 構成.
├── .devcontainer
│   ├── devcontainer.json
│   └── Dockerfile
├── tools
│   └── .codex
│       ├── archived_sessions/
│       ├── sessions/
│       ├── auth.json
│       ├── config.example.toml
│       └── config.toml
├── .env
├── .gitignore
└── docker-compose.yml
archived_sessions や sessions、auth.json は初期状態では存在しません。

 使ってみる簡単なプログラムを仕様書駆動開発で実装していきましょう。

 想定される開発の流れVSCode で devcontainer を起動
セットアップ
codex でログイン
MCP サーバー設定
（必要なら）AGENTS.md 設定

spec workflow mcp による仕様書駆動開発
ステアリングドキュメント作成（初期設計）
個別仕様起案
設計フェーズ
タスク分解
実装
（仕様変更）


 VSCode で devcontainer を起動作成した開発環境は VSCode の拡張機能「devcontainer」を用いて作成しています。

詳しい設定方法は割愛しますので、以下の記事等を参考にされることをお勧めします。
https://qiita.com/ryoshin0830/items/d03e488a94c08ac7d6dc
今回は Docker コンテナ内に ubuntu の環境を設け、codex および各種 VSCode 拡張機能を設定しています。
devcontainer.json
{

	"name": "codex-mcp-env",
	
	"dockerComposeFile": "../docker-compose.yml",
	
	"service": "app",
	
	"workspaceFolder": "/workspace",
	
	"customizations": {
	
		"vscode": {
		
			"extensions": [
			
			"openai.chatgpt",
			
			"tamasfe.even-better-toml",
			
			"Pimzino.spec-workflow-mcp"
			
			],
			
			"settings": {
			
			}
	
		}
	
	},
	
	"portsAttributes": {
	
		"*": { "onAutoForward": "openBrowser" } // 見つかったら自動でブラウザを開く
	
	}

}
ここでは開発環境 (VSCode) に関わる設定を行なっているだけです。

コンテナ内の詳細な設定（各種アップデートやインストール）は通常の Docker 系ファイルで設定します。
注視していただきたいのは VSCode 拡張機能の箇所です。（"customizations"→"vscode" 内）

codex を VSCode 内で利用するための openai.chatgpt、codex の設定 Toml ファイル編集用 tamasfe.even-better-toml、仕様書駆動開発用 MCP サーバー「spec workflow mcp」の拡張機能 Pimzino.spec-workflow-mcp（※後述しますが、現状ではWeb UI ダッシュボードを利用すべきであると感じます。必須ではありません。）を導入しています。
"portAttributes" については Web UI を持つ MCP サーバーを導入する関係で ON にしています。

（仮想環境内なので、勝手にブラウザが開いてくれるわけではないのですが、一応 ON にしています。）
そのほか、通常の Docker 関連のファイルは以下に記します。
DockerfileFROM ubuntu:24.04

  

# 作業ディレクトリを作成

WORKDIR /workspace

  

# git や curl 等の最低ツールを入れる

RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y \

curl ca-certificates git \

nodejs npm \

&& apt-get install -y --no-install-recommends python3 python3-pip \

&& rm -rf /var/lib/apt/lists/*

  

RUN curl -LsSf https://astral.sh/uv/install.sh | sh

  
  

# Codex CLI をグローバルにインストール

RUN npm install -g @openai/codex

  
  
  

# コンテナ起動時に bash（または sh）を起動（対話モード）

CMD ["bash"]
docker-compose.ymldocker-compose.yml
services:

app:

build:

context: .

dockerfile: ./.devcontainer/Dockerfile

volumes:

- ./:/workspace:cached

- codex_cache:/home/vscode/.cache # キャッシュはボリュームに退避

- ./tools/.codex:/root/.codex

environment:

CODEX_HOME: /workspace/tools/.codex

# OPENAI_API_KEY: ${OPENAI_API_KEY} # 必要なら .env から注入

working_dir: /workspace

command: sleep infinity # Dev Container が attach するだけ

init: true # プロセス管理を安定化

volumes:

codex_cache:
Command + Shift + P で出現するメニューからコンテナをビルドして起動してみましょう。



ウィンドウ左下がこのような表示になっていれば成功です。

!codex のライバルである Claude Code の開発においても 言及 がありますが、CLI 系の開発支援 LLM エージェントはユーザーの意図しない（把握していない）設定変更や破壊を行なってしまう可能性があります。
そのような点でも、開発環境を仮想化することのメリットが見込めます。

 セットアップ
 codex でログインまずは codex をアクティベートしましょう。

何かしらのファイルを選択した状態であれば、右上にロゴが出現します。



クリックすると以下のようなメニューが出現します。



今回は ChatGPT のアカウントでサインインします。
サインインに成功すると、ウィンドウが変化し最終的に以下のような表示になるかと思います。



（クラウド版での作業内容が表示されていますが、気にしないでください。）
ここで確認して欲しいのですが、おそらく tools/.codex 内に auth.json というファイルが作成されているかと思います。
!Open AI のアカウントトークン等の情報が含まれています。

必ず.gitignore 等で設定し、外部公開しないように設定してください。

 MCP サーバー設定Codex の MCP サーバー設定は config.toml ファイルで行うことができます。

通常の場合であれば、codex 拡張機能のタブから歯車→MCP 設定などの手順で設定できますが、今回の環境では tools/.codex 内の config.toml を参照するようになっています。
config.example.toml
network_access = true

  

model = "gpt-5-codex"

  

[tools]

web_search = true

  

[mcp_servers.spec-workflow]

"command"="/usr/bin/npx"

"args"=["-y", "@pimzino/spec-workflow-mcp@latest","/workspace","--AutoStartDashboard"]

startup_timeout_ms = 30000

  

[mcp_servers.context7]

command = "/usr/bin/npx"

args = ["-y", "--node-options=--experimental-fetch","@upstash/context7-mcp@latest","--api-key","YOUR_APIKEY"]

  

[mcp_servers.serena]

"command"="uvx"

"args"=["--from", "git+https://github.com/oraios/serena","serena","start-mcp-server"]
config.example.toml を参考に、ご自身で example.toml を作成することで対応してください。
config.toml には MCP サーバー設定以外にも、いくつかの設定が可能です。

私は以下のサイトを参考に設定させていただくことが多いです。（完了時に通知を飛ばしてくれるのとか、地味に便利※コンテナないだと微妙かも）
https://zenn.dev/dely_jp/articles/codex-cli-matome
今回の環境では以下の MCP サーバーを導入しています。

もちろん、開発環境ごとに追加で MCP サーバーを導入することも可能です。

是非ともこだわりの環境を作成してみてください。
Spec-workflow-mcp
本開発環境のコア的 MCP サーバー
AWS に実装された Kiro というサービスに見られる、LLM の仕様書駆動開発への活用を、MCP サーバー化することで実現した
スタート時にデフォルトのタイムアウトで起動を無視される事象が多発したため、例外的に 30 秒に延長している

context7
公式ドキュメントや最新の情報に基づいた開発を支援してくれる MCP サーバー
モデル内の学習データやインターネット上の古い情報に惑わされずに、的確なデータを参照した開発を実現できる
公式サイト での API キー取得が必要な模様

serena
LLM がシンボルベースでコードを参照してくれるようになる MPC サーバー
従来のテキストベースでの参照よりも、IDE 的な参照が可能になることで、LLM による開発体験が大きく向上する

上記の通り、Context7 のみAPI キーの設定が必要になりますので、お気をつけください。

!spec-workflow-mcp は mcp の設定にワークスペースの指定を行う必要があります。

ローカル環境で spec-workflow-mcp を使用する場合、ワークスペースを変更するたびに（プロジェクトを変更するたびに）MCP のコンフィグをいじる必要があります。
spec-workflow-mcp を用いた仕様書駆動開発では、本コンテナ開発環境のようなプロジェクト単位での環境構築が重要な意味を持ちます。

 (必要なら)AGENTS.md 設定codex をはじめとする様々な LLM は AGENTS.md に対応しています。
https://agents.md/
MCP サーバーは起動時に自身がどのような機能（ツール）を有しているか、その使い方を含めて通達しますので、特段書かなくても動作します。
しかし、今回のように Context7 や serena を利用することでトークンや開発ペースの効率化が見込める場合には、システムプロンプト的な内容を記述することをお勧めします。
GPT に考えてもらったプロンプト## **0. 役割と原則（必読）**

  

このリポジトリは **仕様書駆動開発** を採用します。仕様は **spec-workflow-mcp** が管理し、

**Context7** は最新の公式ドキュメント・コード例を取得、**Serena** は精密なコード編集と検索を担当します。

- **順序厳守**：Steering → Requirements → Design → Tasks → Implementation。承認前の先行実装は禁止。 
    
- **承認ゲート**：requirements.md 承認後に design.md、design.md 承認後に tasks.md・実装へ。承認履歴はダッシュボードとメタデータで追跡。 
    
- **ドキュメント配置**：.spec-workflow/steering/* と specs/<feature>/{requirements,design,tasks}.md を正とする。 
    

  

## **1. MCP サーバー方針（Codex / VSCode）**

- **必ず** VSCode の MCP で spec-workflow-mcp, Serena, Context7 を有効化した前提で動くこと。
    
- AGENT はチャット中で次の語を見たら相応の MCP ツールを**自動使用**する：
    
    - **「use context7」/ 「最新のAPI仕様を確認」** → Context7 で該当ライブラリの**バージョン一致**ドキュメントを取得し、引用元を記録。 
        
    - **「コード編集/関数追加/シンボリック編集/セマンティック検索」** → Serena の編集・検索ツールで実行。 
        
    
- VSCode/Codex は AGENTS.md を優先コンテキストとして解釈し、階層が近い AGENTS.md が優先される。必要に応じてサブディレクトリにも置く。 
    

  

## **2. ワークフロー（Spec Workflow MCP 準拠）**

  

### **2.1 Steering（最上位方針）**

- 生成/編集先：.spec-workflow/steering/{product.md, tech.md, structure.md}。
    
- 目的：製品ビジョン・技術選定・モジュール境界を明文化。ここを**真実の源泉**とし、以後すべて参照。 
    
- **Context7**：技術選定の裏付け資料（フレームワーク/SDKのバージョン別差分）を収集して要約。 
    
- **承認**：Steering は初回確定後の改訂に**再承認**が必要。ダッシュボードでレビュー→承認/差戻し。 
    

  

### **2.2 Requirements（機能要件）**

- 生成先：specs/<feature>/requirements.md（受入基準・非機能要件を含む）。 
    
- **Context7**：対象API/UIの仕様根拠を最新版で取得し、**引用元URLとバージョン**を明記。 
    
- **承認ゲート**：requirements.md 承認なしに次へ進まない。 
    

  

### **2.3 Design（設計）**

- 生成先：specs/<feature>/design.md（アーキテクチャ、API I/O、データ構造、代替案/トレードオフ）。
    
- **Serena**：リポジトリ全体から**セマンティック検索**で関連コードを洗い出し、影響範囲を提示。必要に応じて**シンボリック編集**で雛形を追加。 
    
- **Context7**：使用ライブラリの**正しいコード例**を差し込む（対象バージョンで）。 
    
- **承認ゲート**：design.md 承認後に tasks.md と実装を解禁。 
    

  

### **2.4 Tasks（実装タスク分解）**

- 生成先：specs/<feature>/tasks.md（担当/粒度/完了条件/関連PR/チェックリスト）。
    
- **Serena**：コードベースを解析し、**安全な変更単位**に分割。依存順序を付与。 
    
- **実行**：各タスク完了時にダッシュボードへ進捗反映。 
    

  

### **2.5 Implementation（実装）**

- **Serena** を既定の編集器とし、**関数/クラス単位**の局所編集を優先。誤差分を防ぐため大域置換は避ける。 
    
- **Context7** は実装中に API 仕様の**変更点**や**バージョン相違**が疑われたときに都度参照。 
    

  

## **3. 具体的な指示（AGENT が守るべきチェックリスト）**

  

### **3.1 共通**

1. **最初に** .spec-workflow/ の有無を確認。無ければ spec-workflow-mcp の初期化を提案/実行（プロジェクトルート指定）。 
    
2. ダッシュボードの承認待ちがある場合は**最優先でレビュー反映**→再承認要求。 
    
3. 仕様文書の改訂は**再承認**を自動リクエスト。 
    

  

### **3.2 Context7 の使い方（自動トリガ）**

- キーワード：「use context7」「最新の公式ドキュメント」「このAPIの正確な用法」。
    
- 取得時は **ライブラリ名・バージョン・URL** を requirements.md / design.md に脚注で残す。 
    

  

### **3.3 Serena の使い方（自動トリガ）**

- キーワード：「関数を追加」「型安全にリファクタ」「この記号参照を検索」「このクラスだけ編集」。
    
- **セマンティック検索→シンボリック編集**の順で、影響最小のパッチを生成。レビューに備え差分要約を出力。 
    


## **4. ガードレール**

- 未承認の仕様に基づくコード変更を**禁止**。承認待ちはダッシュボードで解消してから。 
    
- 外部情報の引用は **Context7 由来を優先**し、出典・バージョンを明記（Hallucination回避）。 
    
- 大規模改変は design.md に設計差分を追記→承認→Serenaで段階的に適用。 
基本的には MCP ツールの一覧を取得した際にプロンプトを受け取っているので、ユーザーが spec-workflow の使い方を理解していなくてもある程度開発できます。
しかし、想定されるドキュメントの作成やタスクの承認管理を飛ばしてしまうこともあるため、AGENTS.md の設定をお勧めします。

 spec workflow mcp による仕様書駆動開発spec workflow mcp による仕様書駆動開発では、想定されている開発方針のようなものが存在します。
まずはプロジェクト全体の方向性を定め、ガイドラインを示すためにステアリングドキュメントを作成します。(product.md, tech.md, structure.md)
これを元に、実現するために必要な機能について、それぞれ要件を決定します。

ユースケースや制約、非機能要検討もここに含まれます。(requirements.md)
機能要件を元に、どのように実現するのかを詳細に設計します。API やデータフロー、内部構造もここで決定します。(design.md)
設計が定まったところで、実装可能なタスクごとに分解します。

タスク自体もドキュメント (tasks.md) に記載され、ToDo のような形で管理されます。
!これによって codex や Claude、Copilot など spec-workflow-mcp を導入した LLM であれば、共同で作業したり、途中から作業するなど様々なことが実現できます。
もちろん人が作業しても OK です。

 ステアリングドキュメント作成（初期設計）今回はデモンストレーションですので、小さめのプロジェクトにしようと思います。

以下のプロンプトを渡してみます。
プロンプトspec workflowを用いて、プロジェクトのステアリングドキュメントを作成してください。
プロジェクトの内容を以下に示します。
プロジェクト内容:
- pythonで実装すること
- ターミナル上に標準出力で一秒に一回カウントをアップして表示すること
- 現在のカウントを表示する際、現在時刻と合わせて表示すること
- 動作が確認できれば良いため、最小限の構成で実装すること
プロンプトを流すと MCP サーバー群が起動します。

うち spec workflow と serena は web ダッシュボードが表示される設定になっています。
VSCode のポートを確認すると、以下のようなものが確認できます。



アドレスにアクセスしてみましょう。
localhost:49774

localhost:24282/dashboard
※URL に注意


どちらも正常に起動できていますね。

一方 codex では…
レスポンスCreated .spec-workflow/steering/product.md with the heartbeat counter vision, audience, key features, success metrics, and future ideas. Approval request approval_1759390010356_guohgnoqe is pending—please approve it via the Spec Workflow dashboard ([http://localhost:49774](http://localhost:49774/)) or VS Code extension so I can proceed to the tech and structure steering docs.
なぜか英語で返ってきましたが、product.md という初期設計書を作成したから確認後、承認してくださいとのこと。
実際にワークスペースには以下のような書類が誕生していました。
product.md
 Product Overview
 Product PurposeDeliver a minimalist terminal utility that emits a live counter once per second, pairing each tick with the current timestamp so developers can quickly verify Python runtime behavior and timing.

 Target UsersDevelopers or operators who need a quick heartbeat script to confirm that a Python environment is running and stdout updates in real time.
Educators demonstrating event loops, delays, or formatted time output without introducing external dependencies.

 Key FeaturesOne-second cadence counter: Increment the visible counter every second to provide a predictable heartbeat.
Timestamped output: Display the current time alongside the counter so users can confirm system clock alignment.
Minimal footprint: Ship as a single-file Python script with only standard-library usage for easy portability.

 Business ObjectivesProvide a simple reference implementation for teams adopting the spec workflow pipeline.
Enable rapid validation of Python CLI execution inside constrained environments (containers, CI sandboxes, remote shells).
Establish a baseline artifact for future timing or monitoring demonstrations.

 Success MetricsTick interval accuracy: Counter advances roughly every 1.0±0.1 seconds under typical load.
Startup latency: Script begins emitting output within 1 second of launch.
Runtime simplicity: Zero non-standard dependencies required for execution.

 Product PrinciplesSimplicity first: Favor the most direct implementation that satisfies timing and formatting needs.
Observability at a glance: Each line should communicate both progress (count) and context (timestamp).
Portability: Keep the solution compatible with default Python installations across Linux, macOS, and Windows terminals.

 Monitoring & Visibility (if applicable)Dashboard Type: CLI stream rendered directly in the terminal.
Real-time Updates: Loop-driven updates once per second using standard output flushing.
Key Metrics Displayed: Elapsed count, formatted timestamp, and optionally contextual labels.
Sharing Capabilities: Output can be redirected to files or piped into logging/monitoring tools if needed.

 Future VisionThe counter can evolve into a richer heartbeat or monitoring probe when projects require it.

 Potential EnhancementsRemote Access: Package as a lightweight HTTP endpoint to expose current count over a local network for demos.
Analytics: Persist counts with timestamps to review drift or downtime over longer sessions.
Collaboration: Add configuration flags so multiple operators can standardize output format or integrate with team tooling.
こちらも英語ですか…
流石に書類は日本語で書いて欲しいので、日本語に修正してもらいます。（AGENTS.md に記載したほうが良いかもしれない）
ということで、普段であればプロンプトを流すと思います。

ですがこれは仕様書駆動開発です。
ダッシュボードから修正依頼を出しましょう。

 修正依頼web ダッシュボードから 承認 タブへ移動し、product.md の レビューと注釈 を押下します。



全般コメントを追加 に「ドキュメントの内容を日本語に修正してください。」と追加しましょう。
コメントを追加後、修正を依頼 ボタンを押下します。

保留中の承認が 0 になったので、「修正依頼を提出しました。確認してください。」と codex にお願いしましょう。
数秒待つと、新たな承認リクエストが届きます。

同様にレビューしてみましょう。
product.md
 プロダクト概要
 プロダクトの目的Python 実行環境が正常に動作しているかを即座に確認するため、1 秒ごとにカウンターを増やしつつ現在時刻を標準出力に表示する極限までシンプルなターミナルユーティリティを提供する。

 ターゲットユーザーPython 環境がリアルタイムに標準出力へ書き込めるかを素早く確かめたい開発者・オペレーター。
外部ライブラリに依存せず、イベントループや遅延処理、時刻表示を教育目的で示したい講師や学習者。

 主要機能1 秒間隔のカウンター: 毎秒カウンターをインクリメントし、一定リズムのハートビートを示す。
タイムスタンプ付き出力: 各行に現在時刻を付与し、システムクロックとの整合性を確認できるようにする。
最小構成: 標準ライブラリのみを利用した単一ファイルの Python スクリプトとして提供し、あらゆる環境で導入しやすくする。

 ビジネス上の目的Spec Workflow パイプラインを採用するチーム向けのリファレンス実装を用意する。
コンテナや CI サンドボックスなど制約の強い環境で Python CLI が動作するかを迅速に検証できるようにする。
将来的なタイミング検証や監視系デモに発展させるためのベースアーティファクトを整備する。

 成功指標カウンター間隔の精度: 通常負荷下で 1.0±0.1 秒ごとにカウンターが増分すること。
起動レイテンシ: スクリプト起動から 1 秒以内に出力が開始されること。
運用の簡潔さ: 実行に追加依存パッケージを必要としないこと。

 プロダクト原則シンプル最優先: タイミングと表記要件を満たす最短経路の実装を選ぶ。
ひと目で状況把握: 各行で進捗（カウント）と文脈（時刻）が同時に伝わるようにする。
ポータビリティ: Linux, macOS, Windows のデフォルト Python でも動作する実装とする。

 モニタリングと可視化表示形態: ターミナルに直接表示される CLI ストリーム。
リアルタイム更新: 1 秒ごとにループで標準出力へ書き込み、必要に応じて強制フラッシュ。
主要な表示情報: 経過カウント、整形済みタイムスタンプ、および必要に応じた補足ラベル。
共有手段: 出力をファイルへリダイレクトしたり、ログ・モニタリングツールへパイプして再利用できる。

 将来ビジョンニーズに応じて、より高度なハートビートや監視プローブへ発展させる余地がある。

 拡張の可能性リモートアクセス: 軽量な HTTP エンドポイントを追加し、ローカルネットワーク経由で現在のカウントを提供するデモに転用する。
アナリティクス: カウントと時刻を永続化し、ドリフトや停止時間を長期的に把握できるようにする。
コラボレーション: 出力フォーマットを調整する設定フラグを追加し、複数人で統一した運用ができるようにする。
良さげですね。
少し意地悪ですが、仕様書の場所を指定して修正依頼を出してみます。
ダッシュボードのレビューから該当箇所を選択して、コメントを残してみます。

※コメントを残したい箇所をドラックすると、選択箇所にコメントを入力できるようになります。



このように複数箇所を一度に修正依頼を行うことも可能です。
再度修正依頼を出しましょう。
修正案を見て、良いと感じたら承認してしまいましょう。

codex には「承認しました。次のドキュメントを作成してください。」とお願いしてみます。

 ドキュメントが揃ったらproduct.md の後は tech.md が作成され、structure.md まで作成が完了したらステアリングドキュメントは完成です。
codex には、機能別のドキュメントを作成してもらうフェーズに移ってもらいましょう。
tech.md

 テクノロジースタック

 プロジェクトタイプ
シンプルな CLI ツール。ターミナル上でカウンターと時刻を表示する常駐型の小規模ユーティリティ。


 コアテクノロジー

 プライマリ言語
Language: Python 3.11 以上
Runtime: CPython 標準実装（Linux 端末を想定）
言語固有ツール: 標準ライブラリのみを使用。time と datetime モジュールで遅延と時刻整形を行う。


 主要依存ライブラリ
外部依存なし。標準ライブラリのみで構成する。


 アプリケーションアーキテクチャ
スタンドアロンのシーケンシャルループ。無限ループ内でカウンター更新・時刻取得・出力・sleep を順番に実行する線形フロー。


 データストレージ
永続ストレージは利用しない。
すべての状態はメモリ上のカウンター変数として保持し、100 でリセットして再利用。


 外部連携
外部 API やプロトコルとの連携は想定しない。


 モニタリング／ダッシュボード技術
出力先はターミナル標準出力のみ。追加の可視化フレームワークは使用しない。


 開発環境

 ビルド・開発ツール
ビルドシステム: 不要（単一ファイルを直接実行）。
パッケージ管理: 不要。必要に応じて pip のみ使用可能だが依存なし。
開発ワークフロー: ローカルで python main.py を実行し挙動確認。


 コード品質ツール
静的解析: 必要に応じて ruff や flake8 などを追加できるが必須ではない。
フォーマッタ: black の採用を推奨（任意）。
テストフレームワーク: 規模が小さいため手動確認を前提。ただし将来的に pytest で動作検証を自動化する余地あり。
ドキュメンテーション: README レベルで十分。Sphinx などは未導入。


 バージョン管理とコラボレーション
VCS: Git（既存リポジトリを使用）。
ブランチ戦略: 小規模のため main ブランチでのトランクベース開発を想定。
コードレビュー: Spec Workflow によるドキュメント承認ののち、通常の PR レビューを実施。


 ダッシュボード開発
該当なし。


 デプロイと配布
ターゲットプラットフォーム: Python が動作する Linux／macOS／Windows 環境。
配布方法: リポジトリからソースを取得し python main.py を直接実行。
インストール要件: Python 3.11 以上。追加モジュール不要。
アップデート手段: Git pull などで最新版ソースを取得。


 技術要件と制約

 パフォーマンス要件
1 秒ごとに確実に出力を更新し、カウンターが 100 まで増加したら 0 に戻す処理を遅延なく実行する。
CPU 使用率は低負荷（単一スレッド・待機中心）であること。


 互換性要件
プラットフォーム対応: Linux 端末を第一対象としつつ、クロスプラットフォームな標準ライブラリのみを使用。
依存バージョン: Python 3.11 以上。将来的な互換性のため 3.12 でも動作確認を推奨。
準拠規格: 特になし。


 セキュリティとコンプライアンス
外部入出力が標準出力のみであり、機密情報を扱わないため特別な対策は不要。
実行環境のファイルアクセス権限などは通常の OS セキュリティに依存。


 スケーラビリティと信頼性
同時ユーザーは 1 セッション想定。複数インスタンスを立ち上げる場合は OS のプロセス管理に依存。
可用性要件は低いが、無限ループ継続を前提とするため例外発生時には終了する点に留意。


 技術的意思決定と根拠

 決定ログ
Python 標準ライブラリのみを採用: 配布容易性と環境依存の最小化を優先。代替案として rich 等の装飾ライブラリがあったが導入コストが不要と判断。
循環カウンター方式: 出力行が増えすぎることによるスクロール負荷を避けるため、100 でリセットする使用要件を採用。
単一ファイル構成: セットアップ手順を簡素化し、学習用サンプルとして読みやすさを確保。


 既知の制限
ログ保存がない: 標準出力のみのため、履歴を後から参照する場合はリダイレクトが必要。
例外処理の簡素さ: 最小構成を優先しているため、エラー発生時の自動再開やリトライ機構は未実装。

structure.md
 プロジェクト構成
 ディレクトリ構成
project-root/

├── .spec-workflow/ # Spec Workflow 用のドキュメントとテンプレート

├── .serena/ # Serena CLI 設定

├── tools/ # 補助スクリプト・設定（Codex CLI 用）

└── src/ # カウンター実装を配置する予定のディレクトリ（最小構成）

実装ファイルは src/main.py として配置し、標準出力の挙動を管理する。
テストが必要になった場合は tests/ を新設し、簡易的な検証スクリプトを配置する。

 命名規則
 ファイル実装ファイル: snake_case（例: main.py）。
ユーティリティ: snake_case（例: time_utils.py）。
テスト: test_*.py 形式（例: test_main.py）。

 コードクラス: PascalCase。
関数・メソッド: snake_case。
定数: UPPER_SNAKE_CASE。
変数: snake_case。

 インポートパターン
 インポート順序標準ライブラリ (time, datetime など)
プロジェクト内モジュール（必要になった場合）

 モジュール構成プロジェクト内では絶対インポート（from src.timer import ...）を基本とする。
最小構成では単一ファイルのため、追加モジュール発生時に適切にパッケージ化する。

 コード構造パターン
 モジュール構成インポート宣言
定数・設定値（例: カウンター上限 MAX_COUNT = 100）
補助関数（例: フォーマット関数）
メインループ関数
ガード節 if __name__ == "__main__": によるエントリポイント

 関数構成入力バリデーションや初期化を冒頭で行う。
ループ内のカウンター更新 → 時刻取得 → 出力 → 待機を一貫した順序で実行。
エラー処理が必要な場合は try/except ブロックでラップし、終了時にメッセージを表示。

 ファイル構成原則単一責務を重視し、カウンター制御と出力処理を同一ファイルで扱う。
実装が増える場合は timer.py など機能別に分割し、main.py はエントリポイントとして残す。

 コード組織原則Single Responsibility: 各ファイルは明確な役割（エントリポイント、ユーティリティなど）に限定する。
Modularity: 後から拡張しやすいよう関数単位でロジックを切り出す。
Testability: カウンター更新ロジックを関数化し、将来的に単体テストが書ける構造に保つ。
Consistency: PEP 8 に沿ったスタイルを維持し、共通のパターンを踏襲する。

 モジュール境界main.py: エントリポイントおよび無限ループ制御。
将来的に timer.py 等を追加する場合、出力フォーマットや時間計測をモジュール化し、main.py から呼び出す。
依存方向はエントリポイント → ユーティリティの一方向とする。

 コードサイズガイドラインファイル: 200 行以内を目安とし、極力コンパクトに保つ。
関数: 40 行以内を目安にし、責務が増える場合は分割を検討。
ネスト深度: 3 レベル以内。

 ドキュメント基準主要な公開関数には docstring を追加し、引数と動作を明示する。
README に実行手順と依存関係を記載（最小構成でも基本説明を含める）。
複雑な制御が発生した場合は、ファイル冒頭に簡潔なコメントを追記する。

 機能別ドキュメント今回のプロジェクトでは、秒間でカウンタアップするシンプルな機能しか有しませんが、WEB 開発などでは様々な機能を有すると思います。

それらの機能ごとに、ドキュメントが ./spec-workflow/spec 下にフォルダ分けされ、拡充していきます。
requirements.md
 Requirements Document
 Introductionシングルファイルの Python CLI で 1 秒ごとにカウンターと現在時刻を標準出力へ表示する最小構成機能を定義する。カウンターは 0 から 100 まで巡回し、環境動作確認用のハートビートとして利用できるようにする。

 Alignment with Product Vision本機能は product.md に記載された「シンプル最優先」「ひと目で状況把握」「ポータビリティ」の原則を満たす。CLI 上で循環カウンターとタイムスタンプを提示することで、Python 実行環境の稼働と時刻整合性を即時に確認できる体験を提供する。

 Requirements
 Requirement 1User Story: Python 環境の動作確認をしたい開発者として、1 秒ごとにカウンターと現在時刻を出力する CLI を利用したい。そうすることでランタイムが停止せず更新され続けるかを一目で把握できる。

 Acceptance CriteriaWHEN スクリプトを python main.py で起動した THEN システム SHALL 直ちに初回行を標準出力へ表示する。
WHEN 1 秒が経過した THEN システム SHALL カウンターを +1 して現在時刻と共に新しい行を表示する。
IF 実行中に標準出力がパイプやファイルへリダイレクトされている THEN システム SHALL 同じ形式の出力を継続し、バッファリングを避けるために毎行後にフラッシュする。

 Requirement 2User Story: 端末ログの読みやすさを確保したいオペレーターとして、カウンターが 100 に達したら 0 に戻る循環挙動を求める。そうすることで出力が際限なく増えず、周期性で状態を把握できる。

 Acceptance CriteriaWHEN カウンターが 100 を表示した次の周期 THEN システム SHALL カウンターを 0 にリセットして出力する。
IF カウンターをリセットした直後でも 1 秒周期が維持されている THEN システム SHALL 次行を 1 秒後に 1 へ更新して表示する。

 Requirement 3User Story: 学習用途でスクリプトを紹介する講師として、Ctrl+C で容易に停止して終了を示したい。そうすることで受講者が安全にセッションを終えられる。

 Acceptance CriteriaWHEN ユーザーが Ctrl+C (SIGINT) を送信した THEN システム SHALL 例外を捕捉し、終了メッセージを 1 行出力して正常終了コードでプロセスを終了する。
IF ループ処理内で予期せぬ例外が発生した THEN システム SHALL 例外内容を標準エラーに通知し、プロセスを終了する。

 Non-Functional Requirements
 Code Architecture and Modularity単一ファイルであっても関数に処理を分割し、将来的なテスト容易性を確保する。
カウンター制御と出力フォーマットを関数化し、再利用性を意識する。
グローバルな可変状態を最小限に抑え、引数・返り値で状態を渡す。

 Performance1 秒周期を維持するため、各ループでの処理時間を 100ms 未満に抑える。
長時間実行時も CPU 使用率がアイドルに近い状態を保つ。

 Security外部入力を扱わないため追加要件はなし。標準出力以外への書き込みを行わない。

 Reliability無限ループが継続する間、周期が乱れた場合は標準エラーに通知できるよう例外処理を備える。
SIGINT 受信時にはリソース（標準出力）のフラッシュを保証してから終了する。

 Usability出力フォーマットは [{timestamp}] count={value} のように読みやすい固定フォーマットとし、時刻は ISO 8601 形式を用いる。
README に実行方法と停止方法を記載する。
design.md
 Design Document
 Overview1 秒ごとに循環カウンターと現在時刻を出力する CLI ユーティリティを src/main.py の単一モジュールとして実装する。time.sleep を用いたループ制御と datetime.datetime.now による時刻取得を組み合わせ、標準出力へ整形済みテキストを流す。SIGINT を捕捉して優雅に終了できるようにする。

 Steering Document Alignment
 Technical Standards (tech.md)Python 3.11 以上、標準ライブラリのみを利用する方針に従う。
循環カウンター方式と単一ファイル構成を採用し、CPU 負荷を抑えたシーケンシャルループを実装する。
例外処理とフラッシュ制御でリアルタイム性を担保し、tech.md で定義した運用要件を満たす。

 Project Structure (structure.md)実装は src/main.py に配置し、モジュール構成・命名規則 (snake_case) を遵守する。
MAX_COUNT 定数やフォーマット関数を切り出し、構造ガイドラインのインポート順序・関数構成に合わせる。
将来の拡張を見据え、ユーティリティ分割が容易な形で関数を配置する。

 Code Reuse Analysis既存コードはまだ存在しないため新規実装となる。ただし Python 標準ライブラリの time, datetime, sys を活用して要件を満たす。

 Existing Components to Leveragedatetime モジュール: 現在時刻取得と ISO 8601 形式への整形。
time モジュール: 1 秒間隔の待機 (time.sleep).
sys.stdout/sys.stderr: 出力フラッシュおよびエラーメッセージ表示。

 Integration Points外部システムやデータストアとの連携はない。

 Architecture単一モジュールで完結するシーケンシャルなループ構造。
関数分割: 初期化 (run())、次のカウント値計算 (next_count)、出力フォーマット (format_line)、メインループ (heartbeat_loop)。
SIGINT をハンドリングするため KeyboardInterrupt を捕捉する try/except ブロックを用いる。

 Modular Design PrinciplesSingle File Responsibility: main.py はカウンター制御と表示に限定。
Component Isolation: カウンター更新ロジックと出力フォーマットを関数化しテストしやすくする。
Service Layer Separation: 規模が小さいため層分けは最小限だが、将来 timer.py 等へスケールできるよう関数 API を明確にする。
Utility Modularity: 補助関数をトップレベルに定義し、他ファイルから再利用可能な形にする。

 Components and Interfaces
 Component 1: run() エントリポイントPurpose: 初期状態を設定し、ハートビートループを開始する。
Interfaces: run(max_count: int = 100) -> None
Dependencies: heartbeat_loop
Reuses: MAX_COUNT 定数。

 Component 2: heartbeat_loop()
Purpose: 無限ループでカウンターと時刻を取得し出力する。
Interfaces: heartbeat_loop(max_count: int) -> None
Dependencies: next_count, format_line, time.sleep, sys.stdout.flush
Reuses: KeyboardInterrupt ハンドリングロジック。

 Component 3: next_count()
Purpose: 現在値と上限値から次のカウントを算出する。
Interfaces: next_count(current: int, max_count: int) -> int
Dependencies: なし
Reuses: 後続でテスト可能な純粋関数として利用。

 Component 4: format_line()
Purpose: 時刻とカウンターを表示用文字列に変換する。
Interfaces: format_line(timestamp: datetime, count: int) -> str
Dependencies: datetime
Reuses: フォーマットロジックを一箇所に集約し、将来の出力変更に備える。

 Data Modelsデータベースや複雑なモデルは不要。以下の単純な構造のみ扱う。

 カウンター状態
CounterState:

- count: int # 現在のカウンター値 (0〜100)


 出力レコード（概念モデル）
OutputLine:

- timestamp: datetime

- count: int

- text: str # format_line で生成される出力


 Error Handling
 Error Scenario 1: SIGINT による中断Handling: KeyboardInterrupt を捕捉し、終了メッセージを print("Interrupted") 等で出力後、return。
User Impact: ユーザーは Ctrl+C 後に「Interrupted」メッセージを確認し、安全に終了できる。

 Error Scenario 2: 出力時の例外 (I/O エラー)Handling: IOError や OSError を捕捉し、内容を標準エラーへ書き出した上で非ゼロ終了コードで終了。
User Impact: ユーザーはエラー内容を把握し、リダイレクト先の問題などを調査できる。

 Error Scenario 3: 時刻取得の例外Handling: datetime.now() は通常例外を投げないが、念のため予期せぬ例外を最上位で捕捉しログを出力して終了。
User Impact: 想定外の障害が発生した際も原因を把握しやすい。

 Testing Strategy
 Unit Testingnext_count の挙動をテストし、0→1、99→100、100→0 などのケースを検証する。
format_line のフォーマットが ISO 8601 形式であることを確認するスモールテストを用意できる。

 Integration Testingpytest から capsys を用いて heartbeat_loop を短時間実行し、出力のタイミングとフラッシュが行われるかを確認する。
SIGINT を疑似的に発生させ、終了メッセージが表示されるかを検証する。

 End-to-End Testing手動テスト: ターミナルで python src/main.py を 5〜10 秒実行し、秒間出力と 100 でのリセット動作を確認。
ログへのリダイレクト (python src/main.py > output.log) を試み、フラッシュの効果でリアルタイムに追記されることを確認。
tasks.md

 Tasks Document
 1. scaffold-main-script
File: src/main.py
Create Python entrypoint with run() function, guard if __name__ == "__main__" を追加。
目的: CLI 実行の基盤を整備する。
Leverage: README (作成予定) の実行手順を参照予定
Requirements: Requirement 1
_Prompt: Implement the task for spec heartbeat-counter, first run spec-workflow-guide to get the workflow guide then implement the task: Role: Python CLI Developer | Task: Create the initial src/main.py with run() entrypoint, guard 節、定数 MAX_COUNT = 100 の定義を行い、今後のロジック追加に備える | Restrictions: 外部依存を追加しない、PEP 8 に従う | _Leverage: Python 標準ライブラリのみ | _Requirements: Requirement 1 | Success: python src/main.py で実行可能なエントリポイントが生成され、まだループは実装していないがスクリプトが終了時に "Heartbeat counter placeholder" を出力する。
 2. implement-heartbeat-loop
File: src/main.py
heartbeat_loop 関数を実装し、1 秒周期でカウンターと ISO 8601 タイムスタンプを出力。
目的: 基本的なカウンター更新ロジックを提供する。
Leverage: Python time, datetime モジュール
Requirements: Requirement 1, Requirement 2
_Prompt: Implement the task for spec heartbeat-counter, first run spec-workflow-guide to get the workflow guide then implement the task: Role: Python Timing Specialist | Task: 実行中ループを実装し、カウンターと ISO 8601 時刻を [{timestamp}] count={value} 形式で出力。カウンターは 0〜100 を循環させる。 | Restrictions: 1 秒周期を維持し、time.sleep と標準出力のフラッシュを必ず行う | _Leverage: time, datetime | _Requirements: Requirement 1, Requirement 2 | Success: 実行中に各行が 1 秒間隔で表示され、100 の後に 0 に戻る。
 3. handle-signals-and-errors
File: src/main.py
KeyboardInterrupt 捕捉と終了メッセージ、想定外例外のエラーハンドリングを追加。
目的: ユーザー操作や I/O 異常時でも情報を残して終了させる。
Leverage: Python sys モジュール
Requirements: Requirement 3
_Prompt: Implement the task for spec heartbeat-counter, first run spec-workflow-guide to get the workflow guide then implement the task: Role: Python Reliability Engineer | Task: KeyboardInterrupt を捕捉し終了メッセージを標準出力へ表示、その他例外を標準エラーへ書き込み終了コード 1 で終了させる | Restrictions: 余計なログを追加しない、終了前に出力をフラッシュ | _Leverage: sys.stdout, sys.stderr | _Requirements: Requirement 3 | Success: Ctrl+C で「Interrupted by user」が表示され正常終了し、その他例外は標準エラーに内容が表示される。
 4. document-usage
File: README.md
スクリプトの実行・停止方法と循環カウンター仕様を記載。
目的: ユーザーが手順と挙動を理解できるようにする。
Leverage: Steering docs product.md, tech.md
Requirements: Requirement 1, Requirement 2, Requirement 3
_Prompt: Implement the task for spec heartbeat-counter, first run spec-workflow-guide to get the workflow guide then implement the task: Role: Technical Writer | Task: README.md を作成し、実行方法 (python src/main.py)、出力フォーマット、Ctrl+C での終了方法、依存ライブラリの有無を説明する | Restrictions: 日本語で記述、過度な説明を避ける | _Leverage: product.md, tech.md | _Requirements: Requirement 1, Requirement 2, Requirement 3 | Success: README を参照するだけで利用手順が理解でき、実際の動作と整合する。

機能一つあたり、三つのドキュメントが作成され、タスク タブでこれからの実装内容を確認することができます。
問題なければ、実装に移りましょう。

 実装タスクはこのような見た目で管理されます。

全てのタスクが終了したら、テスト等も行なってくれるようです。

 （仕様変更）もしも仕様変更などがあれば、その旨も伝えることで新たにドキュメント変更→承認→実装という流れで進行します。

 成果物の確認最終的に README.md まで作成してくれました。
README.md
 ハートビートカウンター CLIPython で作成した最小構成のカウンタースクリプトです。1 秒ごとに現在時刻とカウンター値を標準出力へ表示し、カウンターは 0〜100 を循環します。

 実行環境Python 3.11 以上
追加の依存パッケージは不要（標準ライブラリのみ利用）

 実行方法
python3 src/main.py

実行すると次のような出力が 1 秒ごとに表示されます。

[2025-10-02T12:00:00] count=0

[2025-10-02T12:00:01] count=1

...

[2025-10-02T12:01:40] count=100

[2025-10-02T12:01:41] count=0


 停止方法実行中に Ctrl+C を押すと、「Interrupted by user」と表示して正常終了します。

 リダイレクトやログ出力標準出力へ毎行フラッシュしているため、python3 src/main.py > output.log のようにリダイレクトしてもリアルタイムに追記されます。

 エラーハンドリング予期せぬ例外が発生した場合は標準エラーへ内容を表示し、終了コード 1 で停止します。
実行方法も書いてあるので、その通りに起動してみましょう。
outputroot@dc6622cdf3e7:/workspace# python3 src/main.py             
[2025-10-02T08:18:07] count=0
[2025-10-02T08:18:08] count=1
[2025-10-02T08:18:09] count=2
[2025-10-02T08:18:10] count=3
[2025-10-02T08:18:11] count=4
[2025-10-02T08:18:12] count=5
[2025-10-02T08:18:13] count=6
[2025-10-02T08:18:14] count=7
[2025-10-02T08:18:15] count=8
[2025-10-02T08:18:16] count=9
[2025-10-02T08:18:17] count=10
[2025-10-02T08:18:18] count=11
[2025-10-02T08:18:19] count=12
[2025-10-02T08:18:20] count=13
[2025-10-02T08:18:21] count=14
[2025-10-02T08:18:22] count=15
[2025-10-02T08:18:23] count=16
[2025-10-02T08:18:24] count=17
[2025-10-02T08:18:25] count=18
[2025-10-02T08:18:26] count=19
[2025-10-02T08:18:27] count=20
[2025-10-02T08:18:28] count=21
[2025-10-02T08:18:29] count=22
[2025-10-02T08:18:30] count=23
[2025-10-02T08:18:31] count=24
[2025-10-02T08:18:32] count=25
[2025-10-02T08:18:33] count=26
[2025-10-02T08:18:34] count=27
[2025-10-02T08:18:35] count=28
[2025-10-02T08:18:36] count=29
[2025-10-02T08:18:37] count=30
[2025-10-02T08:18:38] count=31
[2025-10-02T08:18:39] count=32
[2025-10-02T08:18:40] count=33
[2025-10-02T08:18:41] count=34
[2025-10-02T08:18:42] count=35
[2025-10-02T08:18:43] count=36
[2025-10-02T08:18:44] count=37
[2025-10-02T08:18:45] count=38
[2025-10-02T08:18:46] count=39
[2025-10-02T08:18:47] count=40
[2025-10-02T08:18:48] count=41
[2025-10-02T08:18:49] count=42
[2025-10-02T08:18:50] count=43
[2025-10-02T08:18:52] count=44
[2025-10-02T08:18:53] count=45
[2025-10-02T08:18:54] count=46
[2025-10-02T08:18:55] count=47
[2025-10-02T08:18:56] count=48
[2025-10-02T08:18:57] count=49
[2025-10-02T08:18:58] count=50
[2025-10-02T08:18:59] count=51
[2025-10-02T08:19:00] count=52
[2025-10-02T08:19:01] count=53
[2025-10-02T08:19:02] count=54
[2025-10-02T08:19:03] count=55
[2025-10-02T08:19:04] count=56
[2025-10-02T08:19:05] count=57
[2025-10-02T08:19:06] count=58
[2025-10-02T08:19:07] count=59
[2025-10-02T08:19:08] count=60
[2025-10-02T08:19:09] count=61
[2025-10-02T08:19:10] count=62
[2025-10-02T08:19:11] count=63
[2025-10-02T08:19:12] count=64
[2025-10-02T08:19:13] count=65
[2025-10-02T08:19:14] count=66
[2025-10-02T08:19:15] count=67
[2025-10-02T08:19:16] count=68
[2025-10-02T08:19:17] count=69
[2025-10-02T08:19:18] count=70
[2025-10-02T08:19:19] count=71
[2025-10-02T08:19:20] count=72
[2025-10-02T08:19:21] count=73
[2025-10-02T08:19:22] count=74
[2025-10-02T08:19:23] count=75
[2025-10-02T08:19:24] count=76
[2025-10-02T08:19:25] count=77
[2025-10-02T08:19:26] count=78
[2025-10-02T08:19:27] count=79
[2025-10-02T08:19:28] count=80
[2025-10-02T08:19:29] count=81
[2025-10-02T08:19:30] count=82
[2025-10-02T08:19:31] count=83
[2025-10-02T08:19:32] count=84
[2025-10-02T08:19:33] count=85
[2025-10-02T08:19:34] count=86
[2025-10-02T08:19:35] count=87
[2025-10-02T08:19:36] count=88
[2025-10-02T08:19:37] count=89
[2025-10-02T08:19:38] count=90
[2025-10-02T08:19:39] count=91
[2025-10-02T08:19:40] count=92
[2025-10-02T08:19:41] count=93
[2025-10-02T08:19:42] count=94
[2025-10-02T08:19:43] count=95
[2025-10-02T08:19:44] count=96
[2025-10-02T08:19:45] count=97
[2025-10-02T08:19:46] count=98
[2025-10-02T08:19:47] count=99
[2025-10-02T08:19:48] count=100
[2025-10-02T08:19:49] count=0
[2025-10-02T08:19:50] count=1
[2025-10-02T08:19:51] count=2
[2025-10-02T08:19:52] count=3
[2025-10-02T08:19:53] count=4
[2025-10-02T08:19:54] count=5
[2025-10-02T08:19:55] count=6
[2025-10-02T08:19:56] count=7
[2025-10-02T08:19:57] count=8
[2025-10-02T08:19:58] count=9
[2025-10-02T08:19:59] count=10
[2025-10-02T08:20:00] count=11
[2025-10-02T08:20:01] count=12
[2025-10-02T08:20:02] count=13
[2025-10-02T08:20:03] count=14
[2025-10-02T08:20:04] count=15
[2025-10-02T08:20:05] count=16
[2025-10-02T08:20:06] count=17
[2025-10-02T08:20:07] count=18
[2025-10-02T08:20:08] count=19
[2025-10-02T08:20:09] count=20
[2025-10-02T08:20:10] count=21
[2025-10-02T08:20:11] count=22
[2025-10-02T08:20:12] count=23
[2025-10-02T08:20:13] count=24
[2025-10-02T08:20:14] count=25
[2025-10-02T08:20:15] count=26
[2025-10-02T08:20:16] count=27
[2025-10-02T08:20:17] count=28
[2025-10-02T08:20:18] count=29
[2025-10-02T08:20:19] count=30
[2025-10-02T08:20:20] count=31
[2025-10-02T08:20:21] count=32
[2025-10-02T08:20:22] count=33
[2025-10-02T08:20:23] count=34
[2025-10-02T08:20:24] count=35
[2025-10-02T08:20:25] count=36
[2025-10-02T08:20:26] count=37
[2025-10-02T08:20:27] count=38
[2025-10-02T08:20:28] count=39
^CInterrupted by user
素晴らしいですね…

簡易的なプログラムとはいえど、ここまで何もコードは書いていません。

仕様の要求通り、丁寧な実装もされています。
何よりもドキュメントが詳細に残っています。

 まとめ今まで LLM を用いた開発を信用していなかった人は多いでしょう。

現状でも、正しい情報・実装であるかの判断はとても難しいですが、今回の開発手法は「使える」状態まで進化していると考えられます。
↓今回仕様書駆動開発で作成したプロジェクトブランチ
https://github.com/moore-mua/MCP_Dev/tree/python_demo
仕様書駆動開発・AI 駆動開発ともに、今後の進化に期待です。