🧭 概要
本記事では、Gemini CLI × Markdown Driven Development（MDD） による開発AIの活用に関連し、
AIが記憶する情報を「クレンジング＝選別」するためのタグ設計とリポジトリ構成を考えていきます。
今後、GitHub Actionsを組み合わせた実装を考えるにあたり、最近感じた事を整理してみました。なので今回は具体的な実装はありません。
🧩 最近の違和感：「AIのコードが最近なんだか微妙」問題
Twitterや現場で、こんな声をみたり、私自身も感じたりしています。
- 「AIでコードをリファクタしまくったら、どんどん微妙になってきた」
- 「AIが提案するコードが、以前より冗長で、なんか品質が下がった気がする」
これはAIが玉石混交のコードを“キャッシュ”してしまっていることが原因かもしれないと思っています。
例えばジュニアのコードばかりレビューしていたなど。。。
💡 ここでいう「キャッシュ」とは：
ChatGPT、Claude、Gemini などがユーザーごとに短期記憶しているメモリ情報や、
RAG（Retrieval-Augmented Generation）で参照されるナレッジソースを指します。
💣 リポジトリ汚染：社内コードは技術的なベストプラクティスか？
たとえば、Gemini Code Assist Enterprise では、社内リポジトリのコードをRAG経由で参照（Code Customization）できるそうです。
この種の機能は一見は非常に強力でいいことずくめに見えますが、その特性上、参照させる情報ソースの品質がAIの出力に直結するため、慎重な運用が求められると考えています。
なぜなら、通常の会社の社内コードは以下の性質があるのではと思っています。
- ✅ ビジネスロジックの参照には有効（ドメイン知識、社内ルール）
- ❌ 技術的なベストプラクティスとしては要確認（納期優先や妥協などのより技術的な負債が多い、パブリックリポジトリに比べてレビュワーの質・量ともに十分ではない）
つまり、社内コードは「社内文脈としての参考」にはなっても、
「正解コード」として覚えさせてはいけない までは言い過ぎかもしれませんが、Output作成時の技術的な参考としては優先度が低いのではないか。技術的な実装はあくまでパブリックなリポジトリのほうが参考になると考えます。
社内のリポジトリや、AI開発でのアウトプット（特に作業ログなど）をそのままRAGに組み込むと、AIが劣化コードを模倣する危険性が高まります。
🧼 解決の鍵：「Human in the Loopによるナレッジ・クレンジング」
AIが参照する情報については、慎重かつコストをかける必要があり、人間（有識者）が責任を持って以下を判断すべきです：
- すべての情報をそのままAIに記憶させるのではなく、取捨する（基本的にはリポジトリの入り口のプルリク時？）。
- AIにinput、参考にしてもらうコードはauthorによって優先順位をつける。
- ベストプラクティスのナレッジかアンチパターンかなど？たとえばアンチパターンであれば、AIにはレビューのみで使用/人間が見る専用にし、Output作成時の参考にしないなど制御する。
🏷️ 残すべき情報には人間が“タグ”をつける
リポジトリに蓄積していくMarkdownなどには、AIに用途の区別としてタグで明示的に制御することを考えたい。
🔖 Markdownの先頭にメタデータとして記載（例）
<!-- metadata:
tier: 1
trust: high
author: e.hoba
usage: rag
-->
✅ タグ一覧案
| タグ | 内容 | 用途例 |
|---|---|---|
tier |
master / temp / other | マスタ / 一時保存 / その他 |
trust |
high / low / unknown | 著者・レビュー・コードの信頼度 |
usage |
production_code / business_logic / anti_pattern | AIへの用途分類 |
author |
名前（例：e.hoba） | 書いた人を明示 |
📁 次回：ナレッジ・レポジトリのフォルダ設計へ
最近、“政策議論も GitHub で透明にできたら※” という声があるなど、GitHubはドキュメント？ナレッジ管理のツールとしていろいろ可能性がありそうです。本記事では、MDD×GitHub Actions によるAIナレッジ共有を開発ならびにビジネスワークフローにも応用できる可能性について、次回以降も考えていきます。
※なお特定の政党活動の支持を表明するものではありません。