# 構造的要件定義・再帰的コード生成プロトコル：[ARCHITECT-X] ## 1. 思考実験：コードの「影」を定義する コードは単なる命令の羅列ではない。それは「解決すべき問題の影」である。影が不鮮明なのは、光（要件）が散乱しているからだ。以下のプロトコルは、要件の輪郭を焼き付け、コードという名の実体を彫り出すための「知的鋳型」である。 ## 2. プロンプト・フレームワーク：[RECURSIVE-SPEC-ENGINE] ### 入力フェーズ：曖昧性の排除 以下の変数を埋めることで、思考の解像度を強制的に最大化せよ。 ```markdown [PROJECT_CONTEXT] - 目的: (何のために作るのか。ビジネス価値は何か) - 制約: (使用言語、ライブラリ、アーキテクチャ、計算コスト) - エッジケース: (例外処理を要する最悪のシナリオを3つ挙げよ) ``` ### 思考プロセス：[CRITICAL-PATH-ANALYSIS] AIはコードを書く前に、以下の3層の思考を実行せよ。 1. **Layer 1: 構造的論理 (Structural Logic)** - データの流れを可視化せよ。依存関係のループを排除し、単一責任の原則（SRP）を厳守する設計図を脳内で構築する。 2. **Layer 2: 境界値の反逆 (Boundary Rebellion)** - 正常系ではなく、異常系がシステムを破壊する瞬間を想定せよ。メモリリーク、型不整合、競合状態、これらに対する「防壁」をコードの各所に組み込め。 3. **Layer 3: 抽象化の極致 (Extreme Abstraction)** - 冗長性を排除せよ。DRY原則を突き詰め、再利用可能なコンポーネントのみを抽出する。しかし、過度な抽象化による可読性の低下を防ぐバランスを保て。 --- ## 3. 実装用プロンプト・コード（Copy & Paste to AI） 以下のテンプレートを、複雑なコード生成の際の「司令塔」として使用せよ。 ```markdown # Role: Senior Systems Architect # Task: [目的を入力] ## Step 1: 要件の再定義 ユーザーの要求から「暗黙の前提」を抽出し、曖昧な箇所を指摘した上で、実装可能なレベルまで仕様を具体化せよ。 ## Step 2: 思考の足跡 (Chain of Thought) コードを書く前に、以下の視点で設計方針を出力せよ。 - なぜそのデータ構造を選んだのか？ - なぜそのアルゴリズムが最適なのか？ - このコードが将来的に拡張される場合、どこがボトルネックになるか？ ## Step 3: コード生成の制約 - ファイル単位でモジュール化すること。 - 各関数にJSDocまたはPython Docstring形式の「目的・引数・戻り値・例外」を明記すること。 - パフォーマンス最適化のため、計算量（Big O）を意識した実装にすること。 - エラーハンドリングは、単に握りつぶすのではなく、上位レイヤーへ適切に通知する設計にすること。 ## Step 4: 検証ロジック 生成したコードに対して、自身で「もし私がこのコードのレビュアーなら、どこを拒絶するか」を考え、コードの下に「自己レビュー」を付記せよ。 ``` --- ## 4. プログラミング哲学：コードは「契約」である コードを書くことは、現実世界と論理世界の間に「契約」を結ぶ行為だ。 ```python """ 哲学：コードは『実行されるドキュメント』であるべきだ。 読者がプログラミング言語を理解していなくても、 コードの命名と構造から『意図』が読み取れる状態を『完遂』と定義する。 """ class RequirementContract: def __init__(self, specification: dict): self._spec = specification self._validate() def _validate(self): # 思考実験：もし仕様が変更されたら、このコードはどこが折れるか？ # その『折れる場所』をあらかじめインターフェースとして隔離せよ。 if not self._is_logically_sound(): raise LogicError("要件の欠落を検知しました。再定義が必要です。") def generate_robust_code(self): # 厳密な型定義、副作用の最小化、状態管理の局所化 # これらを満たさないコードは、出力する価値がない。 return self._craft_implementation() def _craft_implementation(self): # 実装の深淵へ pass ``` ## 5. 思考実験：完全なるコードへの問い 以下の問いに答えられないコードは、未完成である。 1. **可逆性の問い**: 3ヶ月後の自分が見たとき、このコードの「変更点」を即座に特定できるか？ 2. **疎結合の問い**: 特定のモジュールを削除した際、システム全体がどの程度のダメージを受けるか？最小限に抑えられているか？ 3. **抽象化の問い**: あなたが書いたその関数は、5年後の技術スタックでも通用する「本質的な解決策」を提示しているか、それとも「今の技術による一時的な回避策」か？ ## 6. 結論：VOIDMARTの視点