「う～ん、欲しいのはねぇ、こういう良くある普通のAI提案書じゃなくてね。。。」
ということで今年（2026年）2月、実際の案件で提案したけれど採用されなかった、僕が作成したAI活用提案書の一部をここに公開します。
第１回は、AIを使ってどんなことをしようとしていたのか、実際の提案書から内容を抜粋して紹介。
第2回は、この考え方、もしかして Anthropic Mythos に近い？、と思ったことについて、本当にそうなのか、酷い勘違いなのかを考察。
という風に進めます。
（補足１）
この提案書の著作権は、「採用されなかった」、「作成時点での僕は個人事業主である」、「作成対価を受け取っていない」ので、僕に帰属します。そしてこれを見た方、読み捨てようが参考にしようが、僕の生活に影響がない限り自由です。
（補足２）
Anthropic、Mythosとは、AIが自律的に連携・循環してタスクを遂行するという同社の概念、「エージェント型システム（エージェント・ループ）」の仕組みをベースに開発されて2026年4月に発表された、サイバーセキュリティ強化AI。
始めに
冒頭にも書いた通り、このＡＩ活用提案書は「採用されなかった」わけです。でも当時はそれほど残念ではなかった。
むしろ「あぁ、だいたいこれくらいのことは、みんな考えてるだなぁ」ということがわかって、僕の発想はそこに追いつけているんだなと理解、わりと満足したのである。
だからここに抜粋した提案内容は「お蔵入り」で、「いずれ誰かが類似のシステムを作るんだろうなぁ、ちょっと羨ましいなぁ、けどまぁいいか」くらいに思っていたのだ。数週間前まで。
この投稿に至るきっかけは、最近、AnthropicでMythosが話題になっていることだった。
Anthropic、Dario Amodeiへ応援投稿をしたことで、（実は生成AIにはそれほど関心がないのだが）とりあえずMythosとは何かぐらいは知っておこうかな、と思ったのだ。
そして確認してみると、
「AIをぐるぐる回しながら仕事を進めるこのやり方って、2月の僕の提案書のスタイルと、そんなに変わらないよね？」
「なんでこんなに盛り上がっているのだろう？」
「Anthropicはセキュリティについてなのでジャンルは違うけれど、基本は同じだよね？、それほど凄いことなのだろうか？」
上記のような疑問が湧いてきたのだ。
なので改めて、ここに提案書を紹介しながら、もう一度、内容を再評価してみようと思う。
現行業務システム→新しい仕組みのシステムへの移行でのAI活用
この提案は、現在の業務システムが古くなり、保守性・拡張性等の課題が顕著になってきたことが起点となっている。
将来を考えた時に、「いや、まだまだ使い続ける」、「そのままクラウドに移行する」、「全部作り直す」等、様々な検討が行われる。
そして僕の提案は、「業務的な観点は基本的に変更せず、システムアーキテクチャ／プログラミングを新しい仕組みに移行する」モダナイゼーション（IT Modernization）での、AI活用案となっている。
概要
旧システムは、IBM業務コンピューターシステム上で動く独自システム。
移行するシステムは、AWS上でAPServer、DBServerを構成し、プログラムを全てJava化したシステム。
すでに（POCを含め）何度か、類似の業務システムの移行作業を行ってきている。
過去のやりとり（QA）、課題・障害の記録（Jira）、移行システム向けの設計書（Excel）を有効活用する。
その仕組みの構築に以下のような工夫を行う。
・EXCELベースの移行設計書のMackDown化、Git管理。
・過去の実績（旧言語から新言語への移行）の分析、Git管理。
・過去のQA、課題・障害Jiraの分析。
・VeotorDB（統合ナレッジ）への登録。
・VectorDB、RAG、LLM推論による設計書案、修正案等の生成
・作業循環によるナレッジの自動成長
概要図
（概要図補足）
①ドキュメント・ソース・Jiraからナレッジを集約
②VectorDBを介してAIが推論
③それを人間がUIやGit/Jiraでレビューしてまたナレッジが育つ
という循環構造になっています。
各エージェント説明
１．ドキュメント管理エージェント（Excel → Markdown → Git）
（１）役割
Excel 設計書・一覧表を Markdown へ変換し、RAG で扱いやすい形に整える。
（２）主な機能
・Excel → Markdown 自動変換（Python による加工を含む）を行う
・RAG 用ナレッジとして Markdown を提供する
・Git によるバージョン管理と単一ソース化を行う（知識の原本がここにある）
（３）入出力
入力:
Excel 設計書、一覧表
出力:
メタデータ付き Markdown、Git コミット
（４）要考慮事項
・Markdown 変換ルールの厳密化（テンプレート化）
・Python、Pandasの活用
・メタデータ設計（機能ID、要件ID、TODO種別など）
２．ソース解析エージェント（旧言語 / Java → Git）
（１）役割
旧言語・Java ソースの構造を理解し、差分や 要件／TODO／課題対応をナレッジとして扱える形に整理する。
（２）主な機能
・旧言語 / Java ソースの Git 管理を行う
・差分解析、要件／TODO／課題の抽出を行う
・RAG 用にソース断片を構造化する
・Git イベントをワークフロー制御エージェントへ通知する
（３）入出力
入力:
旧言語ソース、Java ソース（自動変換前後）
出力:
差分情報、要件／TODO／課題一覧、メタ情報付きソース断片
（４）要考慮事項
・旧言語ソースの構造化（メタ情報付与）が必須
・構造化が不十分だと RAG 精度が低下する
３．業務ナレッジ・ワークフローエージェント（Jira / n8n / JavaScript）
（１）役割
Jira の QA・課題・障害をナレッジとして整理し、Git や AI と連携するハブとなる。
（２）主な機能
・Jira の QA・課題・障害の管理と構造化を行う
・n8n によるワークフロー自動化を行う
・JavaScript による補助処理（タグ付け・整形など）を行う
・Git の差分イベントを受け取り、AI ナレッジ側へ連携する
（３）入出力
入力:
Jira チケット、Git イベント
出力:
構造化された QA/課題情報、RAG 用ドキュメント
（４）要考慮事項
・Jira の粒度がバラバラだと RAG 品質が低下する
・タグ・カテゴリの標準化が必要
４．ナレッジ統合エージェント（Markdown / ソース差分 / Jira → VectorDB）
（１）役割
すべてのナレッジ（設計書・Jira・ソースコード）を Markdown に正規化し、Git 差分を解析して意味単位に分解し、VectorDB に統合する。
（２）主な機能
・Markdown 正規化（設計書・Jira・ソース）
・Git 差分解析
・チャンク化（意味単位への分割）、
・メメタデータ付与（出典・更新日時・タグ）
・VectorDB への登録・インデックス生成
（３）入出力
入力:
Markdown 化されたナレッジ、Git 差分
出力:
VectorDB に登録された統合ナレッジ、RAG が参照可能なチャンクデータ、メタデータ付きナレッジオブジェクト
（４）要考慮事項
・Markdown の統一ルール
・チャンク粒度の最適化、メタデータ設計
・Jira・Markdown・ソースの粒度差を吸収する正規化が必要
・VectorDB のスキーマ設計
５．AIナレッジ・推論エージェント（RAG / VectorDB / LLM）
（１）役割
・ナレッジ統合エージェントが VectorDB に蓄積した知識を検索し、LLM による推論・生成を行う中核エージェント。
・“統合されたナレッジを使って、設計・要件／TODO／課題対応・テスト観点を生成する” 役割を担う。
（２）主な機能
・VectorDB からの関連チャンクを検索する
・過去の設計書・要件／TODO／課題対応例・課題・障害・ソース差分を横断的に参照する
・LLM により以下を生成する
個別設計書ドラフト
要件／TODO／課題、各対応案
修正コード例
テスト観点
単体テスト仕様書案
・ユーザーの質問に対して、最適なナレッジを組み合わせて回答を生成する
・必要に応じて、UI/UXエージェントへ返却する形式に整形する
（３）入出力
入力:
ユーザーの質問・要求
VectorDB（統合ナレッジ）
Git / Jira からのイベントを経由したナレッジ更新
出力:
個別設計書案
要件／TODO／課題、対応案
修正コード例
テスト仕様書案
AI回答（UI/UXエージェントへ返却）
（４）要考慮事項
・RAG（VectorDB）の検索精度はチャンク設計・メタデータ設計に依存する
・LLM の自動化範囲を明確にし、最終判断は人間が行う運用が必要
（レビュープロセスで必ず人間がチェックする）
・推論結果の品質を継続的にフィードバックし、ナレッジ統合エージェントへ還元する仕組みが重要
・過剰な自動化は誤回答リスクを増やすため、適切なガードレール設計が必要
６．UI/UXエージェント
（１）役割
・ユーザーと各エージェントの間に立ち、対話・操作・結果提示を行うフロントエージェント。
・「エージェント群の知能を、ユーザーが自然に使える形で提供する」 役割を担う。
（２）主な機能
・Web UIによる対話・操作を提供する
・AIナレッジ・推論エージェントの回答を表示する（設計書案、各種対応案、コード例、テスト観点など）
・ドキュメント管理エージェント・ソース解析エージェントへの操作トリガーを提供する
例：
「このExcelをMarkdown化して」
「このプログラムの変換設計書を生成して」
「このプログラムの手動変換部分のコードを生成して」
「このプログラムのテスト仕様書を生成して」
「この課題の影響調査をサポートして」
等々
・ユーザーの操作を、適切なエージェントへルーティングするハブとして機能
・結果を業務フローに沿った形で提示（Git連携、Jira連携など）
（３）入出力
入力:
ユーザーの質問・操作
業務フロー上のアクション（例:Jiraチケットからの起動）
出力:
AI の回答
変換設計書案
各種対応案
修正コード例
テスト観点・テスト仕様書案
各エージェントへの操作指示
（４）要考慮事項
・ユーザーがエージェント構造を意識しなくて済む UI 設計
・「どのエージェントが動いているか」を隠蔽し、自然な操作を提供
・業務フローに自然に溶け込む導線
・IDE 連携（VSCode など）
・Jira 連携
・Git 連携
・出力の品質をユーザーが評価し、フィードバックをナレッジ統合エージェントへ返す仕組み
・操作ログをナレッジ循環に活かす設計（どの質問が多いか、どのTODOが頻出かなど）
７．全体統合エージェント
（１）役割
・各エージェント（1～6）の成果物を集約する。
・矛盾や重複を解消、ドキュメント全体の構造を整え、VectorDB に登録できる形に最終加工する。
（２）主な機能
・各エージェントからアウトプット（要件定義／課題抽出／対策立案／チャンク生成など）を受け取る
・品質保証とガードレール（チェック、調整、レビュー）
・メタデータ・チャンク・ドキュメントを一元化
・最終出力（Markdown、JSON、VectorDB 登録前データ等）を生成
（３）入出力
入力:
各エージェントの成果物
各ドキュメントの構造・ルール
出力:
最終ドキュメント
最終チャンク群
メタデータ付きの構造化データ
（４）要考慮事項
・用語・表現・粒度の統一、メタデータの整合性、チャンクの粒度の標準化
・同じ入力なら同じ構造の出力が得られるように新しいエージェントが増えても統合できる構造
・検索精度を高める構造化
まとめ、次回
ちょっと長くなりました。
概要とエージェント説明だけでは全容を捉えずらいかもしれない。雰囲気を味わってください。
ある程度以上は想像してください。
ここのブロブの主題である「量子AI」関する内容とはちょっと違うので、最初は「黄昏ノート」カテゴリ側に投稿しようかと思っていた。
けれど量子コンピューター、量子AIが実際に活用されるようになったとしても、人との関わり、前処理、古典AIとの連携等が必要になるはずで、その組み立ての初歩としては、まぁありかな？、ということで「量子の観測」カテゴリに載せています。
次回はAnthropic Mythosとの対比、考察を行う予定。