第１回最後に、「次回はAnthropic Mythosとの対比、考察を行う予定」と書いたのだが、そんな最強AI・最新機能と比較する前に、このままだと、
「なにこれ？、どういうこと？」となって、おそらく伝わらない。
自分で読み返しても、第１回だけだと説明が足りないと思う。
不十分だと自覚があるなら、ちゃんとすべきだ。
ということで「Mythos」との対比などという無謀なことをする前に、この「没になったAI活用提案書」の特徴を少し説明させていただきたい。
１．知識を循環させる
通常どんなシステム開発プロジェクトでも、大量の資料・情報が積みあがる。
設計書、コード、質問、課題、進捗、それらがWord、Excel、Git、Jiraになり、どこにあるのか、なにが書かれているのかは、「人が憶えているから使える」物だった。
つまり「経験した人」にしか活用が出来なかった。
もちろん「未経験の人」であっても時間と忍耐さえあれば、いずれ活用できるようになるが、どんなプロジェクトもそこに苦労している。出来る人は簡単には出来上がらないのだ。
この提案がまず目指したのは、
・Excel → Markdown化
・Jira → 構造化データ化
・ソースコード → 意味単位を定義、差分把握
・すべて Git で一元管理
・VectorDB に統合し、AI が参照できるようにする
・追加／修正のたびに、上記を繰り返す
という、知識と経験を、人の頭の中から「知識と経験を蓄積・成長させるシステム」側に移すということだ。
２．7つのエージェントが連携する
やりたいことは突き詰めれば、「AIを活用して良い感じのシステムを作りたい」ということなのだが、1つの巨大なAIに全てを丸投げする、という発想は、最初からなかった。
おそらく、そうやって丸投げしてから「ここは、こういう風に判断して」、「こっちは、こういう風に生成して」と会話しながら進めることはできる。そして欲しい物が得られるかもしれない。
けれど違う局面になったらまた「こっちのケースでは、こうして。。。」というのを繰り返すと思う。
知識を「丸投げ」してしまった時点で、どう解釈され、利用されるかは、AIにお任せなのだ。
生成結果が安定しないんだろうなぁ、おそらく永遠にAIと相談し続ける（プロンプトの微調整が続く）はずだ、と想像できた。
これではだめだ。たぶん使い物にならない。
なのでこの提案では、知識（設計、コード、QA、課題）を、AIに的確に解釈させるための前処理、その知識を継続し成長させるための仕組みを同時に考えている。
具体的には以下の7つに役割を分割し、１つ１つを程良い作業単位にして連携させることで、システム構築しようとしている。
１．ドキュメント管理エージェント（Excel → Markdown → Git）
Excel 設計書・一覧表を Markdown へ変換し、RAG で扱いやすい形に整える。
２．ソース解析エージェント（旧言語 / Java → Git）
旧システム言語・Java ソースの構造を理解し、差分や 要件／TODO／課題対応をナレッジとして扱える形に整理する。
３．業務ナレッジ・ワークフローエージェント（Jira / n8n / JavaScript）
Jira の QA・課題・障害をナレッジとして整理し、Git や AI と連携するハブとなる。
４．ナレッジ統合エージェント（Markdown / ソース差分 / Jira → VectorDB）
すべてのナレッジ（設計書・Jira・ソースコード）を Markdown に正規化し、Git 差分を解析して意味単位に分解し、VectorDB に統合する。
５．AIナレッジ・推論エージェント（RAG / VectorDB / LLM）
ナレッジ統合エージェントが VectorDB に蓄積した知識を検索し、LLM による推論・生成を行う。“統合されたナレッジ”を使って、設計・要件／TODO／課題対応・テスト観点を生成する
６．UI/UXエージェント
ユーザーと各エージェントの間に立ち、対話・操作・結果提示を行う。
７．全体統合エージェント
各エージェント（1～6）の成果物を集約する。矛盾や重複を解消、ドキュメント全体の構造を整え、VectorDB に登録できる形に最終加工する。
３．“チャンク設計”と“メタデータ設計”を重視する
「Gitで一元管理」し、「VectorDBに統合」するのは、検索を賢くするためではなく、AIで活用・推論を行うためだ。
そのために、以下の設計に注力する。
チャンク設計：
AIが一度に理解・処理しやすい大きさに、情報の塊（文の意味単位、機能ブロック等）を最適化する。
メタデータ設計：
ベクトル検索（意味の類似度）だけでは誤認が発生しやすい。メタデータ（要件ID、TODO種別、Jira課題ID、機能ID、プログラムID、作成日付、作成者等）を、検索の「フィルター」として機能させる。
スキーマ設計：
検索エンジンと推論LLM、そしてフロントエンドを繋ぐデータの構造を定め、システム全体の安定性と拡張性を確保する。
上記を行うことで、「丸投げ」して「永遠にAIと相談（微調整）」するシステムではなく、「意図した意味」に基づいた「安定した生成結果を得られる」システムを構築しようとしている。
４．人間が判断する
仕組みは作った、としよう。
推論までたどり着き、設計書、追加・修正コード、テスト仕様を生成してみた、とする。
おそらく最初は思い通りにならない。
チャンク設計、メタデータ設計をし直し、学習し直しになるだろう。
そして生成した結果が良い感じなってきたとしても、必要なら修正することになるだろう。
必ず人が良し悪しを判断する。
そして、加筆訂正した設計書やコードはもう一度、学習サイクルにまわり、ナレッジになる。
この循環を前提にしている。
人の判断が介在することを前提に成長するシステムを目指している。
５．段階的に構築する
「一気に構築」と失敗すると思う。少しずつ進めたほうがよい。なのでこの提案では、
- 基盤構築（Excel→Markdown→Git）
- 設計支援（設計書ドラフト生成）
- 品質保証（テスト観点・再発防止）
- 標準化（組織横断の仕組み化）
上記のように段階を分けてシステムを構築し、確実に成果を積み上げる。
６．少しずつシステムを大きくする
「設計（Excel）、ソースコード（Git）、過去の会話（Jira）、全てをクラウドAIに託すのはちょっと。。。」
という考えは当然あると思う。
知的財産を外部に全て出せるかどうか、必ず議論になるだろう。
なのでこの提案は、最初は以下のような構成で、ローカル環境で動作するシステムを想定している。
・ローカルn8n（ワークフロー）
・LangChain（アプリ層）
・LlamaIndex（RAG層）
・Chroma（VectorDB）
・ローカルLLM（Gemma3など）
上記構成だと、
・ライセンスコストがほぼゼロ
・初期基盤として程良い大きさ
・内部で完結、拡張性も確保
ということで、スタートしやすい。
将来的には
・ローカル構成をそのまま強化する
・部分的にクラウドサービスを採用する
・全量クラウド化or 組織基盤上に統合
等を考えればよい。
まとめ
ここまで書いてやっと、「Anthropic Mythosとの対比、考察」までたどり着いたが、そもそも対比できるようなものなのだろうか？。
そもそも「Mythos」自体、よく知らないのだが。。。
「あ、なんか似ているのかも」と思っただけなので。
残念な誤解だった気がしてきている。ちょっと筆が重たくなってきた。
けれどまぁ、しかたがない。このシリーズを完結させるために、そもそも「Mythosとはなにか」から次回は始めるかな。。。
今回はここまで。