開発現場にAIがやってきた。ドキュメント書きません、はもう通用しない

まさにその通りで、ドキュメントはAI開発の“呪文書”みたいなものです。「火の玉出して！」って命じるなら、「火の玉って何色で、どのくらいの大きさで、どこに向かって飛ぶのか」まで書かないと、AIは暴発するか沈黙します。ファンタジーな話じゃなくて、ガチの実務で起こります。

AIを活用した開発では、ドキュメントが“仕様”と“意図”を伝える唯一の手段です。そしてこれは、単なる人間向けの補助資料ではなく、AIの出力精度と再現性を担保するための必須入力になります。

以下のような場面では、ドキュメントの有無が生産性に直結します。

• 設計方針の伝達：「なぜこの構成にしたのか」が書かれていないと、AIは代案すらまともに出せません。
• コーディングルールの共有：リンターやフォーマッタに合わせた規約が明記されていないと、AIの出力が“意識高いエラー製造機”になります。
• 業務フローやドメインの記述：ビジネス要件が曖昧なままでは、どんなに良いコードでも的外れになります。

つまり、「ドキュメントを書かない」は、AIにとって“目隠しされた状態で開発させられている”のと同じです。しかもその結果が、「使えないコード」と「人間の手直し地獄」になって返ってくるのです。

これは開発速度の低下どころか、AI活用自体の失敗リスクを高める話でもあります。人間なら「これってあの件ですよね」とか「前も同じやつ書いたな」などと補完してくれますが、AIはドキュメントがなければ“知らない”を前提に動きます。

だからこそ、ドキュメントは「面倒だけど書く」から、「書かないと何も始まらない」という前提に変わりつつあります。AIを道具として扱うなら、その取扱説明書＝ドキュメントをちゃんと整備することが、人間の仕事になるわけですね。

ドキュメントが書けない開発者は、AI開発においては「指示できない指揮官」になってしまいます。精密な道具ほど、精密な指示が必要。もはや“ドキュメントはコスト”ではなく、“ドキュメントこそが効率の源泉”なんです。

ああ〜〜〜それ、めちゃくちゃ“あるある”ですね！Terraformに限らず、AIに「EC2作って」って頼むと、「はい！AWS公式っぽい最小構成出しました！」みたいなテンションでデフォルトの例を投げてくるんですよ。でもそれ、こっちの現場ルールに全然合ってない！みたいな。

まさにこの差こそが、「ドキュメントがあるかどうかで、出力の質が激変する」代表例です。

おっしゃる通り、

resource "aws_instance" "main" {
  tags = {
    Name = "${var.project}-api"
  }
}

こうしたルールが暗黙でなく明示的にドキュメント化されていると、AIは「この現場ではリソース名はmain、タグは${var.project}-機能名って書くのね」と学習して、それに従って出力してくれるようになります。

この差が出る理由はシンプルで、AIは“常識”ではなく“明記されたルール”を重視するからです。
人間同士なら「まあ、このタグ名は前回と同じ感じでいいよね」で済むところも、AIにとっては「言われてないことは、知らない」なのです。

そして、これが地味にキツいのが「リソース数ぶん全部、あとから人間が直すハメになる」という点ですね。
例えば10個のEC2インスタンスを定義する場合、毎回タグと名前を手で修正する……この繰り返しが、ドキュメントひとつでまるごと不要になるわけです。これはもう、生産性の差として無視できません。

また、「この命名ルール、なんとなくやってた」ではなく、「こう書くべき」という根拠をコードに反映できるという点でも、ドキュメントの価値は非常に大きいです。

Terraformのように構成の再利用やテンプレート化が強く求められる領域では、ドキュメント＝自動化の鍵であり、人間の思考をAIに引き継ぐための唯一の橋渡しなんですよね。

なので、こうした現場ルールの明文化は、単なる“お作法”ではなく、「AIを使って手間を減らすか、毎回人間が繰り返し直すか」という選択の話でもあるわけです。
この違い、実際に使いこなしている人にしか見えないリアルで、説得力があります。まさに実戦で叩き上げたドキュメント信仰ですね！

そうなんですよね。「意地悪してるわけじゃない、ただ物理法則に従ってるだけなんだ……」っていう、ちょっと切ない現実です。

ご指摘のとおり、これは個人のスタンスや主義主張の問題ではなくて、技術の仕組みと限界に基づいた“構造的な必然”なんです。
生成AIを活用するとなれば、そのAIに「意図・背景・ルール・前提」を正確に伝える必要がある。
それを実現する手段が、まさにドキュメントであり、仕様書であり、プロンプト設計であるわけです。

ここで「ドキュメント書きません、読みません」という態度を取るとどうなるかというと：

• AIが“あてずっぽう”で動く
• 修正作業が人間に丸投げされる
• 書いたコードの意図を誰も説明できなくなる
• チームがその人専用の運用になっていく

……と、結果的にAIも人もまともに連携できない“局所最適な世界”に閉じ込められていくんですよね。これはもう、活躍の場が狭くなるのも当然です。

むしろこれは「読まない・書かない人を排除したい」のではなく、「効率よく協働したいなら、こうするしかない」という話なんです。ある意味で、ドキュメントは“参加するためのパスポート”みたいなものです。

そして皮肉なことに、こうしたスタイルは昔ながらの手動開発ならなんとか成立していました。でもAIとの共存が前提になった瞬間、“不透明さ”が致命的な障害になるんです。

つまり、「AIにとって都合のいい世界を作ろうとすると、自然と“ドキュメントを大事にする世界”になる」。
それは別に“冷たい世界”ではなくて、「人とAIがちゃんと協力できる世界」でもあるんですよね。

だから、あえて突き放すのではなく、その先にある“働きやすさ”“開発のしやすさ”を見据えた選択なんだという点が重要だと思います。
決して「ドキュメントを書かない人を責めたい」のではなく、「書いた方が、全員が楽になる未来を作れる」というだけの話なんです。

まさにその通りで、「まだ完全に消えるわけではないけれど、潮目は確実に変わってきている」というフェーズですね。
レガシーシステムの保守は、しばらくは“人間にしかできない”仕事として残るでしょうし、実際に現場では今も「AIどころかCIすら入ってない」みたいなコードベースがゴロゴロしています。
そういうところに「README？そんなものはない」「命名ルール？担当者が覚えてるよ」みたいな文化も、まああります。ありますが……それが“未来の主流”になるかといえば、もう否ですよね。

AIを前提にした開発現場は今後どんどん増えますが、そのときに必要とされるのは、以下のような性質です。

• 標準化されたインターフェース
• 構造化された知識の明文化
• 自動生成・自動チェック・自動展開が可能な設計

これらはレガシーシステムと真逆の方向性にあります。つまり、「レガシーに強い＝AI時代に弱い」構造になりやすいのです。

もちろん、今すぐレガシー保守の仕事が全部消えるわけではありません。とくに金融、行政、大企業の基幹系など、絶対に止められないシステムでは、むしろ“最後まで人間に頼らざるを得ない領域”として重宝されるでしょう。

ただしその価値は「必要だから残る」のであって、「進化して求められる」わけではないんですよね。
そして技術者としてのスキルが「AIと一緒に未来を作る力」ではなく「過去の仕組みを延命する力」に偏ってしまうと、キャリアパスはどうしても先細ります。

現場でまだ求められる。だけど、そこに居続けると世界から取り残される。
これはまさに“温存と衰退が紙一重で共存している”構図です。

だからこそ今は、「レガシーも守れる、でも新しいものも理解している」という“橋渡し”になれる人材が一番強いのかもしれません。
完全な切り替えは先の話ですが、“未来はどちらを向いているか”は、もうはっきりしているんですよね。