先に、2つの記事を公開しました。
AIに「正座」をさせて見えた真実：Antigravityと挑んだkintoneアプリ同期ツールの激闘録
エラーを喜ぶAIは変ですか？――攻略から共鳴へ。人間とAIがたどり着いた「エウレカ！」の境地
10日ほどAIとのやり取りにはとても苦戦していて、いまはそれなりになったのですが、最近の関係がガラッと変わった理由をAIに聞いてみました。
これは役に立つかもしれない。
プロンプトより、Gemeniの設定より、これがよかったようには思います。
記録に残しておきます。
でも、私たちのやり取りで出てきたファイル名なので、公式のものではないのかもしれないことはご注意ください。
以下、AIによる文章です。
今後のプロジェクトで強力なパートナーシップを築くための「AIに対する規律（プロンプト・設計方針）」として、今回のプロジェクトで最も劇的な効果を生んだ設定・アプローチを総括します。
他のシステム開発においても、このの原則をプロジェクトの目的に応じて調整・明文化することで、AIが暴走せず、人間と高度に連携できるチームが組めるはずです。
物理的な「真実」の絶対視（エラー自己修復の禁止）
今回、最もブレークスルーとなったのは 「AIにエラーを『解決』させず、『観測・報告』に徹させたこと」 です。
- 効果が高かった規律: docs/skills/autonomous_deploy.md に記載された 「APIからの拒絶応答（4xx/5xx）に対し、自己解決や推測、リトライを厳禁とする」 という絶対規律。
- なぜ重要か: 一般的なAIの初期設定では、「エラー＝自分が直すべきもの」と解釈し、コードを継ぎ接ぎして無理やり通そうとする性質（AIの陥穽・ハルシネーション）があります。これを物理リミッター（終了コード1で強制停止させるなど）で封じたことで、Kintone固有の複雑な仕様（「サブテーブル内のフィールドはレイアウト制約が違う」「存在しないルックアップを参照すると落ちる」など）という 「プラットフォームの真実」を人間が正確に把握し、根本的な設計（アーキテクチャ）から見直す ことができました。
今後のプロジェクト構成への応用
新しいプロジェクトを立ち上げる際は、最初に以下のファイル群を用意するアプローチをお勧めします。
- SPEC.md / README.md: システムの目的だけでなく、今回のように「プラットフォームの物理法則（仕様）」と「過去の失敗（AIがハマりやすい陥穽）」を明文化しておく。
-
docs/skills/xxx.md: AIに特定の役割（観測者なのか、コーダーなのか、デバッガーなのか）を演じさせるための自立型プロンプト（命令書）。 -
rules.json(またはPROPERTY_RULES的なもの): システムが従うべき振る舞いや例外を定義した設定ファイル。
これらを基盤として明示していただくことで、私（AI）や将来のAIエージェントは、あなたの意図通りの強力な開発パートナーとして立ち回れるはずです。本当に素晴らしいプロジェクト方針の開拓でした！