はじめに：「AI導入」の前に詰まった話

去年あたりから「AI活用で生産性2倍！」「AIで内製化推進！」という号令が各社で飛び交っている。

うちの現場にも来た。
最初は純粋に期待していた。

やりたかったこと：
- コードを書いたら自動で補完・提案してくれる
- テストコードをAIに生成させる
- 設計書を渡せば実装のたたき台を作ってくれる
- 過去の障害や仕様をAIに聞けばすぐ答えが出る

どれも夢物語ではない。実際にそういう事例はある。

しかし、いざ自分の現場で動かそうとしたとき、AIの前に片付けなければいけないものが山積みだったという話をする。

「公式事例」でよく見る「AIで開発が劇的に改善されました！」みたいな話ではない。
もっとぐちゃぐちゃで、もっとリアルな話だ。

🔴 第一の壁：「Gitが入ってなかった」

AIを導入しようとして、まず確認したのが「現状の開発環境」。

そこで発覚したのがこれ。

変更管理：なし
ブランチ運用：なし
レビュー文化：なし
コード履歴：ローカルの「バックアップ」フォルダ

フォルダ名がバージョン管理になっていた。

src_20240301/
src_20240301_最終/
src_20240301_最終_修正版/
src_20240301_最終_修正版_本当の最終/

お前もか、という顔をした。

AIはGitと極めて相性が良い。PR・Issue・Commit・ADR・READMEなど、全てが「文脈のある構造化テキスト」として機能する。
しかしGitがない現場にAIを入れても、文脈のない断片を食わせ続けることになる。

結論：AI導入の前にGit導入をやることになった。

🔴 第二の壁：「設計書が全部Excelだった」

AIに設計書を渡せば、それを元にコードを生成したり、仕様の質問に答えてくれる。理論的にはそうだ。

しかし、その設計書を開いたとき、絶句した。

セル結合が縦横無尽に走ったExcel
SmartArtで描かれたシステム構成図
Wordに貼り付けられたスクリーンショットのフロー図
「最新版（旧）」というファイル名のPDF

AIは賢いが、ExcelのSmartArtや貼り付け画像の「図」を人間のように読めない。

人間：「この矢印の意味は…えっと、前後の文脈と担当者に聞けばわかる」
AI：「……」

テキストとして読めないものは、AIにとってただのノイズだ。

さらに問題だったのが、これ。

仕様が口頭で存在していた。

「それはAさんに聞けばわかる」「この部分は昔の経緯があって…」という属人的な知識が、どこにも文書化されていない。

AIに食わせるどころか、人間でも情報を探すのが困難な状態だった。

🔴 第三の壁：「情報がどこにあるか誰も知らなかった」

社内の情報がどこにあるか調べたら、こうなっていた。

場所	内容
SharePoint	3年前の設計書（最新かどうか不明）
Teamsのチャット	重要な仕様決定の会話（埋もれている）
NAS	誰も整理していないフォルダ群
Redmine	チケットの中に仕様が書いてある（検索不能）
担当者のローカル	最新かもしれない何か
退職者のPC	引き継がれなかった何か

これはAI以前に、人間でも情報収集が困難という状態だ。

RAGを構築して「社内知識をAIに食わせよう」という構想があったが、食わせる前に情報の棚卸しが必要だった。

古い仕様、誤った仕様、権限的にまずい情報、個人情報……それらを整理せずにRAGへ投入すると、AIが自信満々に古い仕様や誤情報を回答するという最悪のケースになる。

🟡 現場で見た「3つのパターン」

AI導入の取り組みを横断的に見ると、大きく3パターンに分かれていた。

パターン①：ガチガチ分離型

金融・官公庁・インフラ系に多い。

外部AI原則禁止
Azure OpenAIのみ限定許可
設計書持ち込みに厳格な審査

これ自体は理由がある。監査対応・情報漏えいリスク低減など、正当な理由だ。

しかし副作用として：

「人間がコピペ係になる」 現象が発生する。

AIと繋がれていない環境で働く開発者が、手動でプロンプトを組み立て、手動でコピペし、手動で確認する。
生産性向上どころか、新しい形の作業が増えただけという現場もあった。

パターン②：現実路線型（最近増加中）

GitHub Enterprise + Copilot Enterprise + Azure OpenAI + 社内RAG を整備した閉域環境を構築するパターン。

考え方が変わっている点がここ。

「開発環境に設計書を置いてよいか」ではなく
「AI利用基盤としてどう統制するか」 という発想へのシフト

これが進んでいる企業は、明らかにAI活用の成熟度が違う。

パターン③：野良AI型（実は一番多い）

現場の開発者が個人判断で：

個人契約のChatGPT
無料のAIサービス
VSCodeの怪しい拡張機能
ローカルLLM

を使っている状態。いわゆる シャドーAI だ。

そしてAI禁止を強化すればするほど、シャドーAIが増えるという逆説的な現象が起きていた。

禁止されているから報告しない → 会社は実態を把握できない → リスクが可視化されない → さらにルールが強化される → ……

この負のループ、誰かが断ち切る必要がある。

🟢 抜け出すために実際にやったこと

やったこと①：AI用に「中間ファイル」を作る

WordやExcelを直接AIに渡すのではなく、一度Markdownに変換した中間ファイルを作る運用を始めた。

Word設計書 → Markdown（手動 or 変換スクリプト）
Excel仕様書 → CSV / YAML
PowerPoint構成図 → テキスト要約 + Mermaid図

手間はかかる。しかしこれにより：

AIが設計書を正確に読めるようになった
Gitで差分管理できるようになった
レビューがテキストベースになった

という副産物があった。

やったこと②：Mermaidで図をテキスト化する

「図はMermaidで書く」というルールを導入した。

メリットは多い。

Gitで差分比較できる
AIが「図の意味」を理解できる
AIが自動生成・修正できる
レビューがコードレビューと同じ感覚でできる

画像やSmartArtで描かれた図は、変更があるたびに全体を書き直す必要があった。Mermaidなら1行変えれば終わる。

ここには地味に大きなパラダイムシフトがある。

AIにとって画像の図は「見る」だけの対象だ。
しかしMermaidは「理解・生成・修正」できる対象になる。

「図を画像で持つ」から「図をテキストで持つ」への転換。
これは単なる記法の話ではなく、ドキュメントをAIと共同編集できる資産にするかどうかの分岐点だ。

やったこと③：軽量ガイドラインを先に作る

「ルールが整備されるまでAI使用禁止」ではなく、最低限のガイドラインを先に作って動かしながら改善する方針を取った。

最初のガイドラインはこれだけ。

1. 顧客情報・個人情報は入力禁止
2. 認証情報（パスワード・APIキー）は入力禁止
3. AI生成コードは必ず人間がレビュー
4. 最終的な責任は人間が持つ

これだけでも「使ってよい/悪い」の基準が生まれ、シャドーAIの報告が増えた。

🔵 AI導入で最初に気づいた「本当のこと」

AI駆動開発を進める中で、一番大きかった気づきはこれだ。

AI導入は「開発プロセス正常化プロジェクト」だった。

AIに渡せる形へ情報を整理する → ドキュメントが構造化される
Gitで管理する → 変更履歴が可視化される
レビュー文化が生まれる → 属人化が解消される

AIを入れようとしただけなのに、長年放置されていた負債を一気に解消する圧力が生まれた。

「AIが全部コードを書く」を夢見ていたが、実際の第一歩はこうだった。

夢	現実の第一歩
AIが設計書を読んで全実装	設計書をMarkdown化する
AIが自動テスト	テストコードをAIに生成させる
AIがバグを全修正	AIにログ解析を手伝ってもらう
開発者不要	開発者の摩擦が少し減る

「開発者を消す」ではなく、**「開発者の摩擦を減らす」**が現実的な第一歩だった。

まとめ：AI時代に価値が上がるのは「整理できる人」

AI駆動開発を進めていく中で、チームで話題になったことがある。

「AIを使える人」より「AIに渡せる形へ情報を整理できる人」の方が、実は希少かもしれない。

仕様をMarkdownで構造化できる
図をMermaidで表現できる
ドキュメントを機械可読な形で管理できる
情報の「分類」「権限」「鮮度」を整理できる

これらは全部、業務理解・構造化能力・標準化能力だ。プロンプトエンジニアリングより先に求められる能力かもしれない。

AI導入の話をしていたはずが、組織の情報文化を根本から見直すことになった。

でもそれで良かったと思っている。

AIは万能ではなかった。

ただ、長年「そのうちやろう」と先送りされてきた問題を、「AIを入れるために今やらなければならない問題」へ変える圧力としては、非常に強力だった。

Git未導入・ドキュメント混沌・情報分散——これらは昨日今日の問題ではない。でも「AIを入れたい」というトップダウンの号令が、現場の「どうせ言っても変わらない」という諦めをついに動かした。

AI導入に躓いているあなたの現場も、たぶん同じだと思う。

参考：現場でよく使うようになったもの

Mermaid：テキストでシーケンス図・フロー図を書く
GitHub Copilot：コード補完・テスト生成
ADR（Architecture Decision Records）：設計判断をGitで管理する
OpenAPI：API仕様をテキストで管理する

この記事が「うちの現場もそれだ……」と思った人の背中を少し押せれば嬉しいです。

#AI #AI駆動開発 #GitHubCopilot #ドキュメント #エンジニア #現場の話 #Mermaid #Qiita