EN 한국어 日本語 中文
はじめに · INTRO 全体構造 · REFERENCE →
QE FRAMEWORK · 5分ガイド

AIに きちんとした仕事をさせるフレームワーク

v6.5.0 新機能 · Contract Layer — AI がビジネスロジックを密かに破壊するのを機械的にブロックする契約ベースの検証レイヤー。詳細は下の用語集と完全ガイドを参照。

QE Frameworkは、AIにコーディング作業をさせるときに スペック・実行・検証を自動的に組み込んで、 「いい加減だった」または「見当違いなものを作った」をシステムレベルで防ぎます。

0130秒ピッチ

なぜ必要か。 AIに「これ直して」と言うと、大抵3つのうちどれかが壊れます。リクエストが曖昧でAIが推測する、実行はしたが何をしたか追跡できない、または「完成しました」と言うが実は半分しかできていない状態。人間の開発者同士の間でもこの問題を防ぐために スペック → 実装 → レビューを行います。QEはAIに同じ規律を強制します。

何が違うか。 単なるプロンプト集ではありません。すべてのタスクが TASK_REQUEST(何をするのか)と VERIFY_CHECKLIST(どう確認するのか)の2つのファイルとして先に保存されます。実行はその後に行われ、各チェックリスト項目がyes/noで判定された後でのみ「完了」になります。途中で失敗すると、自動的に再試行仕様が生成されます。

何が保証されるか。 (1) ユーザーはAIが何をする計画なのか実行前に見ます。(2) AIは自分の結果を自分で採点しません。別の検証・監督ステップがあります。(3) どのステップでもClaudeまたはCodexに切り替え可能で、外部APIを直接呼び出さないため、依存関係が分離されます。

025秒メタファー

QEを理解する最速の方法 — 作業室(スタジオ)として想像してください。

SKILL
道具
ハンマー・ドリルのような機能
AGENT
従業員
道具を実際に使う人
HOOK
ルール
「のこぎりの前に保護メガネ」のような自動ゲート
SPEC
契約書
何を作るのか書いてある文書

03はじめての方はこの4つだけ

  1. /Qinit — プロジェクトにフレームワークをインストール(CLAUDE.md、.qe/ディレクトリ自動生成)
  2. /Qplan "やりたいこと1行" — AIがロードマップとステップを提案します
  3. /Qgs Phase 1: 短い名前 — 具体的なスペック文書2つが生成されます(承認したらすぐ実行)
  4. 終わり。その後の検証・監督は自動 — 失敗したらAIが自分で再試行して、完了したら知らせます。
# その他のコマンドはこの4つに慣れた後で学んでも大丈夫です。
💡 いつでも/Qplanから始めてもいいです。 Qplanが作業規模を自動判定して、簡単な作業(バグ1つ・小さいリファクター)と判定されたら、ロードマップなしに/Qgs Fix: …に直接進みます。規模判定はユーザーがしなくても大丈夫です。Qplanが Micro / Small / Full に分けて自動的に経路を決めます。

04実際にはこう流れます

ユーザー: "ログインボタンを押しても反応しないバグを直して"
1

計画 (Plan)

/Qplanが作業規模を判定 — 「バグ1つだからマイクロスケール」と判定して、1行のプランを提案します。 ロードマップ・ステップなしに次に進みます。

2

スペック生成 (Spec)

/Qgsが TASK_REQUEST(どのファイルのどの関数をどう直すのか)と VERIFY_CHECKLIST(直した後に何を確認するのか)を作ります。ユーザーはこの2つのファイルをさっと見て 「そう、この通りやって」と承認。

3

実行 (Execute)

/Qatomic-runがチェックリストを並列実行。ファイルが複数なら複数のAI従業員(Haiku)が 同時に分割して修正します。Hookが毎回「ちゃんとやってるか？」を自動確認。

4

検証 (Verify)

/Qcode-run-taskがテストを実行してVERIFY_CHECKLISTを1つずつ確認。 1つでも失敗したら自動で修正 → 再実行 → 再検証(最大3回)。通過したら「完了」報告。

05コア用語 15

全体Referenceを読む前に知っていると便利な単語。

PSE Chain
ユーザーワークフロー4ステップ(計画 → スペック → 実行 → 検証)。すべてのタスクの骨組み。
SIVS Loop
品質ゲート4ステップ(スペック → 実装 → 検証 → 監督)。PSE内で回る内部検証。
Skill
AIが特定の状況で呼び出せる機能単位。/Qplanのようなスラッシュコマンド。
Agent
スキルが委譲する実行主体(E*接頭語)。バックグラウンドで働くAI従業員。
Hook
イベントベースの自動ゲート。AIが何かをする前後に決定論的に動作するルール。
Spec
タスクの契約書。TASK_REQUESTとVERIFY_CHECKLISTの2つのファイルで表現。
TASK_REQUEST
「何をするのか」仕様 — チェックリスト + 依存関係 + 出力ファイルパス。
VERIFY_CHECKLIST
「完了をどう確認するのか」— yes/noで答えられる判定項目リスト。
Wave
並列実行単位。依存関係のないタスクを一度に複数のAIに配分。
Teammate
Wave内で働くHaikuモデルエージェント。高速・低コスト・反復的な作業を担当。
Verify
「やったか？」確認 — 客観的なyes/no判定。
Supervise
「うまくやったか？」評価 — セキュリティ・品質・ドキュメント等、専門家視点の評価。Verifyと異なる。
Context Memory
フォルダ別に分割されたAIコンテキスト。現在の作業ディレクトリに合うものだけロードしてトークン節約。
Phase
ロードマップの1ステップ。複数のWaveを含める可能。Phase 1, Phase 2, …
Handoff
スキル終了時に次のコマンドを知らせる標準ブロック。ユーザーが貼り付けられるよう短く。
⚠️ Qutopia Mode
全てのスキルが確認プロンプトをスキップし、最初のオプションを自動選択するようにする自律実行スイッチ。高速だが、誤ったファイルのコミット、main への push、破壊的操作の連鎖実行のリスクあり。要件が明確で、全ステップがロールバック可能で、独立したフィーチャーブランチ上のときのみ有効化。完全な事前チェックリストは USAGE_GUIDE §10 を参照。セッション終了前には必ず /Qutopia off を実行。
Contract Layer (v6.5+)
ビジネスロジックを構造化された markdown 契約(6セクション: Signature / Purpose / Constraints / Flow / Invariants / Error Modes)として固定し、LLM judge が契約・実装・テストの三者を照合して一致を判定する検証レイヤー。AI リファクタが意図を密かに損なう「バイブコーディング」を機械的にブロック。/Qcontract と /Qverify-contract で使用。
/Qcontract
契約ライフサイクル管理スキル。サブコマンド create / edit / list / approve で .qe/contracts/active/ の契約を作成・更新・承認。承認は対話ゲート(AskUserQuestion)+ .qe/contracts/.lock ハッシュ記録の 2 層防御。
/Qverify-contract
LLM judge(Econtract-judge エージェント)による契約準拠検証スキル。3 ハッシュ(contract / impl / test)キャッシュで同内容の再判定を回避。単一契約(<name>)または一括(--all)モードに対応。/Qcode-run-task Step 4.10 で自動呼び出し。