連載「AIがブン回る環境づくり！」第2部です。第1部で置いた全体像のうち、ここではAIが最初に迷う「正典の置き場」を扱います。
私たちは、AIエージェントに渡す知識は「集める」より先に「どこを正とするか」を決めるべきだと考えています。
チーム固有の設計方針、作業手順、禁止事項、レビュー観点が別々の場所に散らばっていると、AIエージェントは近くの例や古い文書に引っ張られます。人間なら聞き返せる場面でも、AIは与えられた文脈からもっとも近いものを推測します。
SSoTは、情報を一箇所に集めることではありません。判断の正を一つに決め、そこへ迷わずたどれるようにすることです。
第1部の全体像では、SSoTをAI駆動開発の最初の土台に置きました。第2部では、その土台を「文書整理」ではなく、AIが判断に使える作業場の地図として設計します。次の第3部では、この正典を前提に、作業領域と品質ゲートをどう分けるかへ進みます。
SSoTは、巨大な一冊ではなく棚の設計です
AI向けのSSoTで大切なのは、すべてを一つの巨大文書に詰め込まないことです。
巨大な文書は最初だけ安心感があります。しかし、設計方針、開発手順、文章表現、セキュリティ、リリース判断が同じ場所に混ざると、更新対象が広がります。古い記述も残りやすくなります。AIにとっても、どの段落がいまの作業に効くのか見分けにくくなります。
SSoTは本棚に近いです。設計の正はここ、テスト方針の正はここ、AIエージェント向け入口はここ、問い合わせフォームの正はここ、というように棚を決めます。入口には棚の地図を置き、本文のコピーを増やしません。
この分け方にすると、人間もAIも「探す」時間が減ります。正しい場所へたどれるので、毎回の会話で同じ前提を説明する必要も減ります。
AI向け入口は薄く作る
AIエージェント向けの入口は、薄いほど長持ちします。
入口の役割は、詳細ルールを全部読むことではありません。最初に守るべき不変条件と、関心事ごとのSSoTへの導線を示すことです。たとえば、作業はタスク単位で分ける、完了前に品質ゲートを通す、危険な操作や秘密情報の扱いを避ける、詳細ルールはどこを見る、という程度に絞ります。
入口が厚くなったら、分割の合図です。アーキテクチャ、フロントエンド、バックエンド、セキュリティ、Issue運用、マーケティング公開前チェックなどは、それぞれの正典へ逃がします。入口は地図であり、百科事典ではありません。
CodexのAGENTS.md、Claude Codeのプロジェクトメモリ、Cursor Rulesのような仕組みは、どれも「プロジェクトの作法を作業場に置く」発想です。毎回のプロンプトで説明するのではなく、チームの前提をAIがたどれる形にしておくことが効きます。
守る強さは3段階に分ける
SSoTとガバナンスでは、ルールの強制力を分けて考えます。ここを混ぜると、「書いたのに守られない」という状態になります。
1つ目は、機械で止める層です。lint、型チェック、テスト、ビルド、secret scanning、依存境界チェックのように、コマンドやCIで失敗させられるものです。この層は人間の注意に頼りません。
2つ目は、常時ロードで効かせる層です。設計ルール、作業前の計画、レビュー観点、報告スタイルなど、機械的には止めにくいが毎回の判断に効かせたいものです。AIの判断前提として置きます。
3つ目は、文書化された運用の層です。権限棚卸し、リリース判断、ブランチ保護、許諾確認など、コードやテストだけでは完結しないものです。弱い層として扱い、運用設定やレビューで補います。
すべてを最初から機械化する必要はありません。どのリスクが、どの強さで守られているかを見える化することが先です。
権限設計は、安全に任せるための線引きです
AIエージェントのガバナンスは、文書だけでは完成しません。何を読んでよいか、何を編集してよいか、どのコマンドを実行してよいか、どこで人間に止めるかを決めます。
これは信頼の有無ではなく、役割に必要な範囲だけを渡す設計です。lintやtestの実行は許可する。秘密情報の読み取りや破壊的なgit操作は止める。PR作成は許可しても、force pushは止める。ログを見る場合も、認証情報が出る場所は扱わない。
できないことが明確になるほど、できることを安心して任せられます。権限設計はAIを縛るためだけのものではなく、人間がAIに仕事を渡しやすくするための土台です。
SSoTを作る実践ステップ
SSoTを整えるときは、いきなり文書を書き足さない方が進めやすくなります。
まず、判断の種類を洗い出します。設計判断、実装手順、テスト方針、レビュー基準、セキュリティ禁止事項、Issue状態、依存関係更新などを並べます。
次に、それぞれの正典を一つに決めます。すでに複数の文書があるなら、どれを正とするか決めます。片方を消すのか、片方を索引にするのかも決めます。
その後、AI向け入口から正典へたどれるようにします。入口に本文をコピーすると、将来の不整合が増えます。「この判断はここを見る」と置く方が、更新対象を小さくできます。
最後に、機械で守れるものをゲートへ移します。文章で「型を通す」と書くだけではなく、typecheckを完了条件にします。文章で「秘密情報を入れない」と書くだけではなく、secret scanningを入れます。
SSoTは文書整理ではありません。AIが迷わず、チームの判断に沿って動くための開発基盤です。
連載ナビ
- 第1部：AI駆動開発の全体像
- 第2部：SSoTとガバナンス（この記事）
- 第3部：開発ワークフロー
- 第4部：エージェントハーネス
- 第5部：ループエンジニアリング
関連サービス
- テクニカルディレクション: AGENTS.md、CLAUDE.md、ルール、品質ゲート、レビュー観点を整理し、コーディングエージェントが迷わない開発体制づくりを支援します。
- AI Agent開発: 業務知識、用語、判断基準をAIが扱える形へ整理し、実務で再現できるAI Agentの設計を支援します。
