TL;DR
- AIにプロセスやコンテキストの管理を丸投げすると、推測が発散して暴走と破綻を招く。
- これを防ぐには、アーキテクチャによってAIの行動に物理的な「ガードレール（境界線）」を設ける必要がある。
- **「チケット（Issue）による境界線設定」と「Gitによる絶対的な状態管理」**を組み合わせた『チケット駆動開発（TiDD）』は、現在の私たちが手応えを感じている、極めて現実的で強力なアプローチの一つである。
はじめに：なぜ我々はAIに振り回されるのか？
AIにコードの修正や機能追加を依頼したとき、以下のような経験はないでしょうか？
- 「指示した要件から逸脱して勝手に無関係なコードを書き始める」
- 「資料の作成を頼むと、レイアウトやフォーマットを勝手に崩す」
こうしたAIの暴走は、我々がAIに対して**オープンループ（フィードバックと境界線のない状態）**で自由な推論を許してしまっているシステム設計の欠陥から生じます。
「プロンプトを工夫してAIを賢く動かす」というアプローチには限界があります。
必要なのは、**「アーキテクチャ（構造）によってAIの暴走を物理的に封じ込める」**という制御工学的な視点です。
提唱するアーキテクチャ：【AI(脳) × Git(記憶)】
AIを安全に業務パイプラインに組み込むためには、「思考の制御」「表現の制御」「状態の同期」という3つの柱が必要です。
柱1：思考の制御（チケット駆動開発：TiDD）
TiDD自体はすでに多くの開発現場に浸透した手法ですが、AI駆動開発においてはその意味合いが全く異なります。
人間のエンジニアであれば「チケットのスコープ外のコードは触らない」「空気を読んで意図を汲む」という暗黙の常識が働きます。しかし、確率的な推論エンジンであるAIにはそれがありません。AIは局所的な最適化を求めて関係ないファイルまで書き換えたり、全体設計を破壊するDiffを平気で出力する固有の傾向（弱点）を持っています。
だからこそ、AIに対しては「よしなに開発して」と丸投げするのではなく、プロセスを以下のようなフィードバック制御系として再定義し、AIの思考に「物理的なガードレール」を設ける必要があります。
- 目標値（制約）：チケット（Issue）
-
操作量（出力）：AIが生成するコード差分（
git diff） - 制御対象（状態）：Gitリポジトリ
（※厳密な制御理論としてのゲインや無駄時間を論じるものではなく、あくまで「非決定的なAIを安全に運用するための強力なメンタルモデル（比喩）」として捉えてください）
AIには常に「現在アクティブな単一のチケット（Issue）」だけを与えます。AIの仕事は「そのチケットの要求を満たす最小の git diff を出力すること」のみに制限されます。
ここで重要なのは「AIが自発的に境界線を守ってくれるわけではない」という点です。 人間と違い、AIは隙あらばチケット外のコードまで勝手に書き換えようとします。
人間のPRレビューが「性善説に基づく最終確認」であるのに対し、ここでのレビューは「AIの暴走を前提とした必須の検閲ゲート」として機能します。
このアーキテクチャでは必ず**「人間のレビューとGitへのコミット」**がクリティカルパスに介在し、出力されたDiffがチケットの境界線を逸脱していれば人間がリジェクトし、問題なければコミットして状態を確定させます。
プロセスを人間が握り、Gitという物理的な関所を設けることで、AI特有の「コンテキストの暴走」を物理的に遮断できるようになったのです。
柱2：表現の制御（MVCパターン × CI）
人間の作業であれば「レイアウトが少し崩れたら微調整する」で済みますが、AIは確率的な揺らぎを持つため、表現の自由度を与えると毎回非決定的なレイアウト破壊を繰り返すという固有の問題があります。
これを防ぐため、表現（View）とデータ（Model）を徹底的に分離します。
AIにはシステムプロンプト等で「純粋なテキストやソースコード（Model：主にMarkdown）のみを出力せよ」と厳命し、装飾やPDF化といった表現（View）の権限を完全に奪います。
Viewの生成（コンパイル）は、AIではなくCI（GitHub Actions等）上のスクリプトに任せます。
このように「決定論的なスクリプト」に表現を委譲することで、AIの気まぐれによるレイアウト崩れが構造的に発生しなくなります。
柱3：状態の同期（Docs as Code による自動追従）
「ソースコードとドキュメントが永遠に乖離して腐っていく」という現場の永遠の課題。
人間同士であれば「暗黙の記憶と阿吽の呼吸」でなんとかなる場面もありますが、AIに正確な文脈を持たせて機能させるには「絶対的に信頼できる現在状態（SSOT）」が必要不可欠です。
上記の柱1と柱2によって、ソースコードも資料も「Gitで管理された純粋なテキスト」として安全に扱える状態（いわゆる Docs as Code の体制）が完成すると、この課題も自動的に解決します。
AIに「Gitの最新のコード差分（確定した事実）」を読み込ませ、それに追従するように「マークダウンドキュメント」を修正させるフローを組むことで、AIがハルシネーション（推測による嘘）を起こすことを減らして仕様書を常に最新の状態に保つことができます。
おわりに：新時代のエンジニアの役割
「人間がプロセスを統制し、AIには実行のみに専念させる」。
このTiDD（チケット駆動）のアプローチにおいて、エンジニアの主務は「ゼロからコードをタイピングすること」ではなくなります。
「AIの出力スピードに対して人間のレビューが追いつかなくなるのでは？」という懸念はその通りです。しかし、ゼロからタイピングしていた時間をすべて「要件の分割（チケット化）」と「レビュー」に全振りできるようになるため、結果としてスループットは圧倒的に向上します。
AIに対して**「適切な記憶（チケットとGit履歴）を与え、出力された差分（Diff）を監査し、次の状態として確定させる」コンテキストの管理者**になること。
これこそが、AIのメリットを最大限に引き出しつつ、暴走リスクを抑え込む「現代のエンジニアリングの最適解の一つ」ではないかと感じています。