はじめに
Claude Codeに代表されるAIコーディングツールは、我々の開発スタイルを劇的に変えました。私も例外ではなく、日常的な開発においてAIの力を借りない日はなくなりました。
しかし、その強力さゆえに新たな危険が生まれたことに、私はある時期まで気づいていませんでした。
私は現在、AIの開発環境としてClaude Codeを活用しています。Claude Codeは高性能ですが、利用コストの課題がありました。そこで私はコスト最適化の取り組みとして、GLMやMiniMaxなどの代替モデルを活用する構成を構築しています。
この環境で日々開発を進めている中で、次第に問題が目に見える形で現れてきたのです。
問題提起——AI駆動開発で起きる4つの事故
AIコーディングを続けていると、必ずと言ってもいいほど同じ类型的失敗を繰り返すようになります。私の場合、主に以下の4種類でした。
1. 勝手に仕様を拡張される
AIが「もっと良くなるだろう」と勝手に機能を追加することがあります。要求したのはCSVエクスポートなのに、なぜかExcel形式での出力まで実装されていた。そんな経験はないでしょうか。
2. 自己レビューで「OK」と言われる
同じチャットセッションの中で、AIが実装した後に自分自身でレビューを行ってしまう。Claude Codeのようなツールでは、生成→確認→修正のサイクルが同一コンテキスト内で完結するため、同席したAIが「OK」と言っても客観性がありません。
3. 推測で進められる
「たぶんこういう仕様だろう」で実装が進む。AIは確信犯的に嘘をつくわけではありませんが、不確かな情報をもとに見込み違いの実装を進めてしまうことがあります。
4. 設計判断が属人化する
AIとの会話履歴という非構造的な場所に設計判断が蓄積されていく。会話履歴を一から見返しても、その判断の根拠が見つからない。担当が変われば、その判断は「闇の中」に消えます。
これらの問題は、どれも「AIが強力であること」が原因です。人間には「本当にこれでいいのか？」と疑いながら進めるという抑制がかかります。しかしAIにはその抑制がありません——少なくとも、今のAIには。
設計思想——なぜ「自分を止めるルール」が必要なのか
この4つの問題を解決するために、私がたどり着いた結論は「自分を止めるルールを制度化する」ことでした。
ここで重要なのは、「AIを信じない」ではなく「AIの力を借りつつも、セーフティネットを構築する」という姿勢です。AIコーディングそのものを止めるつもりはありません。ただ、その強力さから自分を守るための枠組みが必要でした。
具体的には、以下の3つを原則としました。
- 仕様は実装の前に確定させる——曖昧なままAIにコード生成させると、推測で補完される
- レビューは別コンテキストで行う——同じセッション内の自己レビューは無効とみなす
- 決定は記録して残す——チャット履歴ではなく、Git上で管理する
これらの原則をテンプレート化し、再現可能な形にまとめたものが、STIT+IRGです。
STIT+IRGの核心——5原則とフェーズ構成
STIT+IRGは、Spec & Test Driven Iteration + Independent Review Gateの略称です。その名の示すとおり、2つの柱で構成されています。
5つの核心原則
| # | 原則 | 意味 |
|---|---|---|
| 1 | Specification before implementation | 実装より先に仕様を確定させる |
| 2 | Independent Review is mandatory | 独立レビューは絶対に省略しない |
| 3 | IDE self-checks do NOT count as reviews | IDE内のAI自己チェックはレビューと認めない |
| 4 | Git is the Single Source of Truth | Gitが設計判断の唯一の正となる情報源 |
| 5 | Every major decision is logged | 主要な決定はすべて記録する |
特に原則3は、当たり前のようですが守りにくいルールです。CursorやGitHub CopilotなどのAIアシスタントが「コードをレビューしますか？」と聞いてきますが、それはレビューではありません。あくまで「自己チェック」です。
開発フェーズの流れ
STIT+IRGでは、開発を以下のようにフェーズ分割し、順序を強制します。
Phase 0: Project Specialization（プロジェクト固有の前提固定）
↓
Phase 1: Spec & Test Definition（仕様とテストの定義）
↓ ※この段階で実装コードを出力してはならない
Phase 2: Implementation（実装）
↓
Phase 3: Independent Review Gate（独立レビュー Gate）⚠️最重要
↓
Phase 4: Merge & Assetization（統合と設計資産化）
Phase 1で実装コードの出力を禁止としている点は重要です。AIに仕様を解釈させて「この仕様を満たすコードを書いて」とお願いしたくなる衝動を抑えるためです。仕様書はテキストで確定し、そのテキスト自体が成果物の一部となります。
Phase 3がなぜ重要か
STIT+IRGの中で最も重要だと私が考えるのが、Phase 3のIndependent Review Gateです。
このフェーズでは、以下の厳格なルールが適用されます。
- 開発を行ったチャットセッションやIDE内のAIではなく、新規のChatGPT/Claude等のセッションでレビューを実施する
- レビュアーは修正コードの提示禁止。判定（Approve/Reject）と根拠のみを出力する
- レビュアーは、実装者とは別のコンテキストであることが望ましい
つまり、元のセッションの文脈を断ち切ることで、「あの時自分がそう言ったから」という前提知識を排した客観的レビューを実現します。
これは物理的な制約ではなく、心理的な制約として機能します。元のセッションを続けて使用した場合、「あのコードを見れば分かっているだろう」という前提がレビューに入り込んでしまいます。新規セッションで「ここに問題があります」と指摘されて初めて、本当に問題に気づくのです。
また、私はこのレビュー結果をObsidianを活用したSingle Source of Truth（SSOT）で蓄積しています。これにより、決定の経緯を検索可能な形で残せます。
使い方——GitHub Template Repository
STIT+IRGは、GitHubのTemplate Repositoryとして公開しています。
リポジトリ: https://github.com/fukukei23/stit-irg-template
使い方は非常にシンプルです。
- 上記リポジトリのページで「Use this template」をクリック
- 新しいリポジトリとして作成
- プロジェクトに必要な設定をPROJECT_PROFILES配下に追加
- ARCHITECTURE.mdにプロジェクト固有のGovernance Gate定義を記載
ディレクトリ構造は以下のとおりです。
ARCHITECTURE.md # Governance Gate Entrypoint（SSOT）
GOVERNANCE/ # プロトコルとAI向けルール
AI_INSTRUCTIONS.md # 実装AI向け指示書
MASTER_PROTOCOL_TEMPLATE.md # 開発フロー・Gate定義の正本
REVIEW_PACKET_TEMPLATE.md # Phase 3用レビューパケット
ARCHITECTURES/ # 設計図テンプレート
DECISION_LOGS/ # 不変ログ（追記のみ、編集禁止）
PROJECT_PROFILES/ # プロジェクト固有の制約
重要な点として、ARCHITECTURE.mdがSingle Source of Truth（SSOT）となります。ここにGovernance Gateの定義を記載し、プロジェクトメンバー全員がこれを参照します。
AI_INSTRUCTIONS.mdには、実装AI向けの指示書が含まれています。主な制約事項は以下の3点です。
- 実装AIは設計判断・プロトコル変更・レビュー判定の権限なし
- 推測・補完・善意の拡張は禁止
- 不明点は「不明」と明示して停止すること
最後の点は特に重要です。黙って進めることが最悪の違反です。AIが「ここはきっとこうだろう」と推測して進んでしまった場合、後からその仮定を見つけるのは非常に困難です。「不明」と明示されていれば、レビュアーやプロジェクトリーダーが判断できます。
実運用での気づき——実際に使った結果
このテンプレートを実際のプロジェクトで運用して、いくつかの気づきがありました。
習慣になるまでが大変
Phase 1の段階で実装コードが出ないことに慣れるまで時間がかかりました。「じゃあここでコード見せてよ」と口に出してしまうことを、意識的に抑える必要がありました。
Phase 3の心理的ハードルは高い
新しいセッションを開始して、ゼロからコードを説明する作業は面倒に感じることがあります。しかし、この「一手間」があるからこそ、品質保証が確実になります。
ログの価値は時とともに増える
DECISION_LOGSに記録した決定は、時間が経っても参照価値があります。新規参画者がプロジェクトの歴史を理解するための有効な資料となります。
推奨ではなく強制
これらのルールは「できれば守りましょう」ではなく「必ず守りましょう」としています。この差が運用の成否を分けました。「推奨」だと、いつか確実に守られることなく忘れてしまいます。「強制」だからこそ、プロジェクトの記録として残ります。
おわりに
AI駆動開発は、依然として過渡期にあります。強力なツールですが、その強力さゆえに危険でもあります。遠慮なく先へ進むAIを止めるのは人間だけです。そしてその「自分を止める」ためのルールを、制度化・テンプレート化しておくことで、より確かな開発を実現できます。
STIT+IRGは、その最初の試みです。使い込んでいく中で、少しずつ改良されていくことを想定しています。もし興味がありましたら、GitHubリポジトリをご覧ください。フィードバックをお待ちしています。
AI駆動開発の成熟に向けて、一緒に歩み続けましょう。
この記事を読んで興味を持った方へ
- 📖 Claude Code CLIをGLM/MiniMaxで代替した話 — このガバナンス設計を支えているAI開発環境の構築方法を、コスト観点で解説
- 📖 Claude Codeの記憶をObsidianでSSOT化する設計 — ガバナンス設計での「決定記録」をObsidian SSOTで実践する方法
- 📖 playwright-stealthが開発停止なのでPython版を自作してPyPIに公開した話 — STIT+IRGのガバナンス下でAI駆動開発した実践例
- 📖 14のAIエージェントが協調する自律型開発フレームワークの設計と実装 — STIT+IRGを内包するマルチエージェントフレームワーク「NexusCore」のアーキテクチャ解説。フェーズ駆動開発・品質ゲート・ガバナンス自動化の実際を紹介
本記事は個人Zennでも公開しています。