近年、プロジェクトに「AI」というアクターが加わりました。AIが適切に機能するには、何を読ませ、何を遮断するかを設計する必要があります。「なぜAIへの指示書はNotionのようなツールではなくGitリポジトリに置くのか」を原則から説明できるチームは多くありません。これはツールの選択の問題ではなく、情報の責務をどう設計するかという問題です。本記事では、AI駆動開発を前提とした情報設計の考え方を整理します。
1. なぜ今「情報設計」が重要なのか
1.1 従来のドキュメント管理の限界
SIerプロジェクトでは、Excelでドキュメントを作成するのが一般的でした。この方法だと修正漏れが積み重なり、時間が経つにつれコードと設計書は乖離します。さらに、ドキュメントが古くなると「なぜその資料が必要なのか」という意図が失われます。メンバーの入れ替わりで作成経緯を知る人もいなくなります。誰も意図を把握していないまま、ドキュメントだけが残り続けます。結果として以下の状況が生まれます。
- ドキュメントに「参照先：○○」とあるが、参照先にドキュメントが存在しない
- どこに何があるか把握するだけで手間がかかる
場当たり的な対応が繰り返されると、開発チームの効率は低下し続けます。
1.2 AI駆動開発で前提が変わった
Claude Codeなどの開発AIは、リポジトリ内の設計書やコードを参照しながら実装します。このようなAIの登場でドキュメントの管理方法を変える必要があります。例えば、AIを活用するには、情報がAIが読める形式（Markdown、OpenAPI等）でGitリポジトリに集約される必要があります。
開発AIが参照できず、人間だけが読めるでは不十分です。さらに、AIは「現在の仕様」だけでなく「なぜその設計になったか」という文脈も必要とします。コンテキストが整備されていないと、AIが古い設計へ回帰する原因になります。情報構造そのものが開発基盤になるようになりました。
2. 情報は「成果物」ではなく「責務」で分類する
従来のSIerプロジェクトでは、成果物リストに沿ってドキュメントを管理してきました。この方法は「何をどこに置くか」の判断基準が曖昧になりやすく、散らかります。そこで、情報を責務（その情報が果たすべき役割）で分類することを提案します。
2.1 3つの設計軸
情報の責務を分類するうえで、3つの設計軸が判断基準になります。
軸1（受け手の設計）「誰のための情報か」：受け手が違えば、保管場所・アクセス権・更新ルールが変わります。「誰のため」が明確な情報は配置先も自然に決まります。逆に受け手が曖昧なまま置き場所を決めると、情報は散らかり続けます。
軸2（アクセス設計）「AIに読ませるか、遮断するか」：AIはコンテキストに渡された情報を全て参照します。読ませてよい情報と遮断すべき情報を設計しないと、機密情報の混入リスクが生じます。特に契約書・金額情報・APIキーはAIから遮断することが必要です。
軸3（ライフサイクル設計）「メンテナンスするか、ストックに留めるか」：更新すべき情報と不要な情報を混同すると、古い内容がAIのコンテキストに残り続けます。メンテコストも際限なく膨らみます。設計書・オンボーディング資料は変更のたびに更新します。議事録・ADRは追記のみでメンテせず、ストックに留めます。
この3軸を組み合わせると、各レイヤーの性質が明確になります。
| レイヤー | 受け手（軸1） | AIアクセス（軸2） | メンテ（軸3） |
|---|---|---|---|
| Product | AI・開発者 | 読ませる | 設計書：する / ADR：ストック |
| Team | プロジェクト関係者（人間） | 原則渡さない | ナレッジ：する / 議事録：ストック |
| Governance | 外部ステークホルダー／限定管理担当者 | 遮断 | ほぼストック |
2.2 3大分類・7小分類の全体像
3つの分離軸をもとに、情報を3つの大分類・7つの小分類に整理します。
| 大分類 | 小分類 | 説明 | 保管場所 | メンテ | AI駆動での役割 |
|---|---|---|---|---|---|
| Product | 実装同期ドキュメント | システムの最新仕様。実装と同期するソースオブトゥルース | GitHub | 要 | 重要コンテキスト |
| 開発履歴・変更記録 | 設計判断・QA・レビューの証跡 | GitHub | ストック | 実装経緯の補足 | |
| AIへの指示書 | Cursor Rules・CLAUDE.md等 | GitHub | 要 | AIへの直接指示 | |
| Team | 共通ルール/ナレッジ | 開発規約・チーム運営ルール。Gitに置く場合は補助コンテキストになりうる | GitHub / Notion | 要 | 補助コンテキスト（越境） |
| 動的データ/運営ログ | 議事録・タスク（チケット）・KPT等 | Notion | ストック | 原則AI対象外 | |
| Governance | 契約/ビジネス | 契約書・見積・体制等の公式文書 | SharePoint | ストック | AIアクセス遮断 |
| 機微情報/セキュリティ資産 | パスワード・APIキー・本番データ等 | 専用ツール | 要 | 混入検知・遮断対象 |
表中の「越境」については3.3節で詳しく説明します。
3. プロダクト成果物の情報設計（Product Layer）
Product Layerは、プロダクトに関する情報を管理するレイヤーです。主な受け手はAIと開発者です。このレイヤーには3種類の情報が含まれます。「現在の正しい仕様」を記述する実装ドキュメント、「なぜその設計になったか」を蓄積する開発履歴・変更記録、そして「AIへの振る舞い指示」を定義するAIへの指示書です。いずれもGitリポジトリで管理します。開発AIはGitリポジトリを参照するため、AIに仕様と設計の根拠を伝える情報源になります。
GitHubが利用できない環境では、GitLab・Bitbucketで代替できます。いずれもGitベースであるため、同じ設計原則が適用できます。SIerプロジェクトでは、リポジトリをクライアントのOrganization配下で管理することを推奨します。納品対象であり、プロジェクト終了後もクライアントが継続保守できるためです。
3.1 実装ドキュメント
設計書は、実装と同期される「ソースオブトゥルース（信頼できる唯一の情報源）」として扱います。ソースコードと同じGitリポジトリでMarkdown管理します。代表的なドキュメントと形式は以下です。
- 基本設計書・詳細設計書：Markdown
- API仕様：OpenAPI（YAML/JSON）
- 構成図・シーケンス図：Mermaid / PlantUML
- インフラ定義：IaC（Terraform等）
これらのドキュメントはAIが直接参照できる形式にします。AIに「現在の仕様」を伝えるコンテキストになります。さらに、クライアントへの共有はGitHubリポジトリ上で行います。他にもGitHub ActionsでMarkdownをHTMLに変換し、静的サイトとして納品する方法も有効です。
3.2 開発履歴・変更記録
Issue・Pull Request・ADRなどは、開発プロセスで生まれる記録を蓄積します。これらはメンテナンス不要のストック情報であり、「なぜそうなったか」という経緯を積み上げていく情報です。
特にADRはAI時代に価値が高まっています。AIはコンテキストが不足すると、過去に却下した設計へ回帰することがあります。ADRに却下の理由を残しておくことで、AIへその判断を伝えられます。
3.3 AIへの指示書（越境するドキュメント）
AIへの指示書とは、AIツールの振る舞いをチームのルールに合わせるための設定ファイルです。具体的にはCLAUDE.mdなどが該当します。コーディング規約・命名規則・レビュー観点などを記述し、AIが生成するコードをプロジェクトの方針に沿わせる役割を持ちます。記述内容はプロジェクトの進行とともに変化します。規約や方針に変更が生じた場合は、指示書も合わせて更新します。
2章の分類では、Team Layerに属する情報です。しかし、実務では、これらのファイルはGitリポジトリに置く必要があります。主要な開発AIが、リポジトリ内の指示書を自動で参照する仕組みを持っているためです。例えば、Claude Codeはリポジトリ内のCLAUDE.mdを起動時に自動で読み込みます。Cursorは.cursor/rules/配下のファイルを、GitHub CopilotはCopilot Instructionsファイルをそれぞれ自動参照します。NotionやSharePointに指示書を置いても、AIは自動では読み込めません。
Team LayerのファイルがProduct Layer（Git）に置かれるこの分類と実務の不一致を、本記事では「越境」と呼びます。ただし、越境の性質は異なります。AIへの指示書は、AIの振る舞いを制御するための専用ファイルです。AIだけが読む前提で記述します。一方、開発規約などの共通ルールは、AIと人間の両者が参照する文書です。実装時にAIが読み、レビュー時に人間が読みます。どちらも意図的な越境ですが、受け手の設計が異なります。
4. チーム運営・ナレッジの情報設計（Team Layer）
Team Layerは、チームの活動と知識を管理するレイヤーです。主な受け手はプロジェクト関係者（開発者・PM・PLなど）です。このレイヤーには2種類の情報が含まれます。開発規約・オンボーディング資料などの「共通ルール/ナレッジ」と、議事録・タスク（チケット）・KPTなどの「動的データ/運営ログ」です。前者はプロジェクトを通じて更新し続けるナレッジとして機能します。後者は都度記録するストック情報です。
主な保管場所はNotionなどGitとは別で管理できるツールがよいです。代替ツールとしてConfluence等があります。SIerチームが主に管理し、必要なページのみクライアントと共有します。原則として開発AIのコンテキストとは分離します。ただし、共通ルールをGitリポジトリで管理する場合は、AIの補助コンテキストとして機能します。保管場所の選択基準は、AIに読ませる意図があるかどうかです。AIに開発規約を補助コンテキストとして読ませたい場合はGitHubを選びます。プロジェクト関係者の参照・更新が主目的であればNotionを選びます。
4.1 プロジェクトの「インデックス」と「オンボーディング」
インデックスとは、プロジェクトで使うすべての情報の置き場所を一覧化したページです。Notion・GitHub・SharePointなど、ツールが複数にまたがる場合でも、インデックスを見れば目的の情報にたどり着けます。特定の人に依存した状態は、その人の退場で情報が失われるリスクにつながります。新規メンバーが自己解決できる割合が増えると、こうしたリスクを下げられます。
インデックスの中に、オンボーディングのページを設けます。環境構築手順・権限申請方法・初日の動き方など、参加初日に必要な情報をひとまとめにします。先輩メンバーへの問い合わせを減らせます。
4.2 ナレッジDBとチーム運営ルール
FAQ・KPT・チーム運営ルール（勤怠・会議体等）をNotionに蓄積します。プロジェクトを通じて更新し続けるナレッジDBとして機能させます。「人間のための空間」です。チームが自由に意見を出し、検討を重ねるための領域として機能させます。
「人間のための空間」が必要な理由は、AIの参照特性にあります。AIはコンテキストに含まれる情報を区別なく参照します。未確定の検討内容や過去の試行錯誤をAIに読ませると、ノイズになります。そのため、Notionの情報は原則としてAIに渡しません。AIには「確定した仕様と判断」だけを読ませる、という設計方針を守ります。未確定の情報とAIの判断材料を分離することで、AIの出力の精度を保てます。
4.3 プロジェクト管理と議事録の扱い
タスク管理はGitHub Projects、議事録はNotionと使い分けます。議事録はNotionに記録しますが、全文をAIに渡すことは避けます。検討段階の情報や覆った案がそのまま混入すると、AIが古い方針で実装する原因になります。
議事録から取り出すべき情報は「決定事項」だけです。決定事項はGitリポジトリにADRまたはIssueとして記録します。こうすることで、決定の根拠をAIのコンテキストに正確に反映できます。
5. ガバナンス・セキュリティの情報設計（Governance Layer）
Governance Layerは、契約・コンプライアンス・セキュリティに関する情報を管理するレイヤーです。主な受け手は外部ステークホルダーと、限定された担当者です。
このレイヤーには2種類の情報が含まれます。契約書・見積・体制等の「契約/ビジネス情報」と、APIキー・パスワード・本番データ等の「機微情報/セキュリティ資産」です。前者は監査・コンプライアンス・承認フローの対象となる文書です。後者は漏洩した場合にシステムやビジネスへ被害をもたらす秘匿情報です。
保管場所はSharePoint等のセキュアなストレージと、専用の秘匿管理ツールに分かれます。AI駆動開発においては、このレイヤーの情報を開発AIから隔離します。保管場所をProduct LayerやTeam Layerから分けることで、隔離を実現します。
5.1 契約・ビジネス情報
契約書・見積書・発注書・予算資料などの確定文書は、SharePoint等のセキュアなストレージで管理します。書き換えられることを前提としないため、PDF・Excel形式で固定保管します。代替ツールとしてはBox・Google Drive・OneDriveがあります。
契約金額・商流・人事情報などがAIのコンテキストに混入することを防ぐため、公開範囲はPM・PL・営業・管理職など契約上の責任者に限定します。
5.2 機微情報・セキュリティ資産
APIキー・パスワード・接続情報・証明書・本番データなどの秘匿情報は、専用の秘匿管理ツールで管理します。これらは継続的なメンテナンスが必要です。APIキーは定期的なローテーションが必要です。証明書は有効期限前の更新が必要です。本番データはアクセス権限の定期的な見直しが必要です。管理ツールの例としては、AWS Secrets ManagerやGitHub Actions Secretsなどがあります。
.envファイルはGitリポジトリにコミットしません。.gitignoreへの追加は必須です。さらに、CIパイプラインにSecret Scanを組み込むことで、誤ってコミットされた秘匿情報を自動検出できます。
6. 3レイヤーとツールの対応
3章から5章で説明した各レイヤーは、それぞれ異なるツールに対応します。
| 項目 | GitHub | Notion | SharePoint |
|---|---|---|---|
| 対応レイヤー | Product | Team | Governance |
| 情報の性質 | 生きた情報 | 議論・運営され続ける情報 | 確定・固定された情報 |
| 主な対象データ | ソースコード・Markdown・Issue・ADR | 議事録・FAQ・ナレッジ・タスク | PDF・Excel・契約書 |
| 公開範囲 | プロジェクト関係者全員 | 原則SIerチーム（一部共有） | 極めて限定的 |
| システム管理者 | 原則クライアント | SIer | SIerまたはクライアント |
| 更新頻度 | 高い | 高い | 低い |
| AIとの関係 | 直接読ませる | 原則AI対象外（例外：越境時） | 完全隔離 |
| 代替ツール例 | GitLab・Bitbucket | Confluence・Growi | Box・Google Drive |
7. ドキュメント配置チェックリスト
3レイヤーの設計を実際に適用するときの配置先の目安です。
| ドキュメント | 配置先 | 理由 |
|---|---|---|
| OpenAPI定義 | Git | 実装と同期するため |
| 基本・詳細設計書 | Git | AIコアコンテキストのため |
| ADR（設計判断の記録） | Git | AIに経緯を伝えるため |
| AIへの指示書 | Git | AIが自動参照するため |
| 議事録 | Notion | 都度記録・更新不要のため |
| タスク・進捗 | Notion / GitHub Projects | 流動情報のため |
| 契約書・見積書 | SharePoint | AI遮断・統制のため |
| 秘匿値（APIキー等） | Secret Manager | 最小権限管理のため |
8. ツールが選べないプロジェクトでの次善策
SIerプロジェクトでは、ツールを自由に選べないことがあります。AI駆動開発での設計書管理の方法は大きく2択です。設計書をGitリポジトリに置くか、外部ツールにドキュメントを書きMCP（AIがツールやデータソースを参照するための標準プロトコル）でAIと連携させることです。どちらも選べない場合も、以下の2つの次善策で原則を適用できます。
次善策①として、フォルダ設計で責務を分離します。ツールが変わらなくても、フォルダ構成で3レイヤーを再現します。
（例：SharePoint上のフォルダ構成）
/AI-context # AIに読ませるもの（設計書Markdown等）
/team-knowledge # チーム向けナレッジ（AIには渡さない）
/governance # 契約・機微情報（AI完全遮断）
次善策②として、更新ルールで情報を維持します。「生きたドキュメント」リストを明示し、そのファイルだけをAIへの投入対象とします。議事録など都度記録するストック情報は更新しません。更新が必要な内容が生じたら、「生きたドキュメント」側を修正します。
おわりに
情報設計はツール選定より先に行うものです。「何をどこに置くか」を設計してからツールを選ぶことで、AI駆動開発に対応した情報管理の土台を作れます。本記事の3レイヤー設計はツールに依存しません。現場のツールが変わらない場合でも、フォルダ設計と更新ルールで同じ原則を適用できます。本稿はAIと壁打ちして記載しております。
最後まで読んでいただいた方、ありがとうございました。
参考文献
Zenn Atsushi Nakamura様（2026年3月19日）「生成AI時代のドキュメント基盤」https://zenn.dev/nuits_jp/articles/2026-03-19-genai-documentation-foundation 2026年5月24日アクセス.