AI開発の設計指針
3本セット（汎用版）

AIエージェントに開発や運用を任せるときに、周りに用意しておくものを3つの設計指針にまとめました。実際のプロジェクトの運用で得た原則と教訓を、特定のプロジェクトに依存しない形にしています。どれも Markdown 1ファイルで、そのままプロジェクトの docs/ に置いて使えます。

新しく作るプロジェクトなら「境界」と「材料」の2本を。すでに動いているシステムをAIに任せるなら「現状と順序」から始めて、残りの2本をその上に載せます。

ダウンロード

3本とも登録不要・無料。複製・改変自由（改変版を配布する場合は出典を明記してください）。

こんな方に

• 意思決定者・発注側の方：各資料の冒頭にある「要約」だけ読めば足ります。開発会社に「どんなハーネスがありますか」「AIへの指示書は誰が更新していますか」「戻せることを試しましたか」と聞くときの質問リストも入っています。
• 実装・運用する方：全体を通して。各資料の記入テンプレート（§11、移行は§8）と記入済み見本を手元に置いて作業できます。
• AIエージェント：ファイルを渡して「§0の手順に従って」と言えば、リポジトリを調べてテンプレートを自分で埋め始めます。人間は判断事項だけ決めれば済み、判断できなければ推奨案で仮決定して先へ進みます。

3本の関係

	ハーネス設計	コンテキスト設計	既存システムの移行
扱うこと	止める仕組み	判断の材料	現状の記録と、任せる順序
主な中身	6つの層、責任分界、承認ゲートの実動作確認、秘密情報、教訓集	5つの置き場、指示書の骨子、正本と台帳、鮮度、圧縮と隔離、外部入力	台帳、動作確認、復旧、暗黙知、作業環境、4段階の委任計画、関係者
いちばん伝えたいこと	承認ボタンは、本当に止めているか	決めたことは会話ではなくファイルに	戻せることを先に確かめる
使う順番（新規）	1	2	—
使う順番（既存）	2	3	1

いちばんお伝えしたいこと——承認ボタンは、本当に止めていますか

ある本番環境で、承認ボタンが実はデプロイを止めていなかった、ということがありました。設計書にもコードにも図にも「承認後に反映」と書いてあったのに、です。

この種の食い違いは、一度実際に止まるかを試すことでしか見つかりません。ハーネス設計では、導入時と、パイプラインや権限を変えたときに「止まるべき操作が止まるか」を確かめる方法を、テンプレートの一項目として組み込んでいます。

使い方

1. 必要な資料をダウンロードして、プロジェクトの docs/ に置きます。別のファイルは作りません。
2. AIエージェント（Claude Code などのコーディングエージェント）に「このファイルの§0に従って」と渡します。AIがリポジトリや設定を調べ、テンプレートのうち分かる項目を埋め、人間が決めるべき項目を「要決定」として挙げてきます。
3. 権限の境界や触ってはいけない場所など、人間が決める項目を埋めます。判断できない項目は「おすすめで」と返せば、AIが推奨案で仮決定して「仮」と印を付けます。
4. 「実動作確認」（ハーネス設計§11-E）や「復旧を試す」（移行§8-C）のように、実際に手を動かす項目を一度行い、日付を入れます。ここまでが導入の完了です。

ツール名（CodePipeline、Amplify、GitHub Actions、WordPress など）はすべて例です。同じ役割を果たすものに読み替えて使えます。

ご利用条件

3本とも自由に複製・改変して利用できます。社内での利用、取引先への共有、自社の手順書への組み込みも構いません。改変版を配布する場合は、出典（JumpStack株式会社「AI開発の設計指針（汎用版）」と資料名）を明記してください。

本資料は設計の考え方と手順を示すものです。個々のシステムへの適用結果について当社は責任を負いかねます。本番環境への適用は、各プロジェクトの責任者の判断で行ってください。