AI時代の開発は「書くこと」ではなく「縮めること」で強くなる

まず問いを反転させる

AIにコードを書かせるとき、多くの人は「どれだけ速く作れるか」に目を向ける。だが、本当に重要なのはそこではない。どれだけ早く書けるかではなく、どれだけ早く縮められるかだ。

ここでいう「縮める」とは、単にコードを短くすることではない。実装の前には仕様を縮める。実装後には責務を縮める。変更の範囲を縮める。認知負荷を縮める。AI時代の生産性は、巨大な一撃を積み上げる力よりも、大きな不確実性を小さな確実性へ変換する力で決まる。

この視点に立つと、AIコーディングの実践環境づくりと、実装後のクリーンアップや横断的変更の使い分けは、別々の話ではなくなる。どちらも同じ問題を別角度から扱っている。それは、変化のコストをどこで払うかという問題だ。

---

AIは「書く機械」ではなく「編集圧縮機」である

従来の開発では、コードを書くことが仕事の中心に見えやすかった。だがAIが入ると、書く行為そのものは急速にコモディティ化する。すると価値の中心は、生成そのものではなく、生成物をどう整え、どう分割し、どう再利用可能な形に落とし込むかへ移る。

このとき役立つのが、仕様駆動開発の発想だ。仕様書を先に作り、その仕様を実装の土台にする。Kiro、Spec Kit、cc-sddのようなツールが注目されるのは、派手な自動化機能があるからではない。将来の変化に耐える中間成果物を残せるからだ。

ここに重要なポイントがある。ツールの優位性は移ろいやすいが、生成されたドキュメントがMarkdownのテキストとして残るなら、その価値は別の層にある。つまり、ツールの本当の役割は、コードを直接増やすことではなく、判断可能なテキストを蓄積することにある。

これは地味に見えるが、実はかなり大きい。なぜなら、AIとの開発では、最も高価なのはコードを書く時間ではなく、次に何を変えるべきかを理解する時間だからだ。仕様はその理解を外部化する。Markdownはその理解を移植可能にする。

AI時代の開発環境とは、生成を速くする環境ではない。判断を残せる環境である。

たとえば、料理で考えるとわかりやすい。優秀なシェフは、ただ速く炒める人ではない。仕込みを整え、切り方を揃え、レシピを再現可能にする人だ。AIも同じで、出力の速さより、出力の前後にある「準備」と「後始末」が勝負になる。

---

実装は一回で終わらない。だから変更の半径を分ける

AIに実装を任せると、つい「よし、できた」と思いたくなる。だが現実には、完成したように見えるものほど、後から細かな修正が大量に発生する。ここで重要になるのが、変更の種類を分けて考えることだ。

局所的なクリーンアップには /simplify を使う。コードの見通しを良くし、命名や条件分岐や重複を整理する。これは机の上を片付ける作業に近い。対象が小さく、影響範囲が読みやすく、意図も明確だ。

一方で、フレームワーク移行やコードベース横断の変更には /batch を使う。これは家具の配置換えに近い。ファイル単位ではなく、システム全体の整合性が問題になる。少しの編集で済む話ではなく、複数の前提をまとめて更新しなければならない。

この使い分けが示しているのは、AIにおいて最も危険なのは「全部同じノリで変えること」だという点だ。小さな整理を巨大な移行として扱うと過剰になるし、巨大な移行を小さな整理として扱うと破綻する。変更にはサイズがあり、サイズに応じた道具が必要なのだ。

ここで見落とされがちな洞察がある。AI支援の価値は、単に作業を代行することではない。変更の粒度を人間が再認識することにある。AIがいるからこそ、どこまでが局所で、どこからが横断なのかを明確に区別しないといけない。

これは建築にも似ている。壁紙の張り替えと耐震改修を同じ手順で進める建築家はいない。だがソフトウェアでは、見た目の近さだけで同じ扱いにしてしまうことがある。AIはその曖昧さを露出させる。便利だからこそ、境界がぼやけるのだ。

---

本質は「書く」でも「直す」でもなく、知識を圧縮すること

ここで二つの話はひとつにつながる。仕様駆動のツールがMarkdownの形で中間成果物を残し、/simplify と /batch が変更の半径を分ける。これは偶然ではない。どちらも、知識を圧縮して扱うという同じ営みを支えている。

仕様は、実装前の知識圧縮だ。曖昧な要求を、後で参照できる単位にまで縮める。クリーンアップは、実装後の知識圧縮だ。散らかった局所知識を、読みやすい構造へ縮める。バッチ変更は、分散した変更を、一貫した方針へ縮める。

このときの「圧縮」は、情報を雑に削ることではない。むしろ逆で、本質を失わずに再構成可能な形へ折りたたむことだ。圧縮率が高いほど良いわけではない。圧縮しすぎると、未来の自分やチームが解凍できなくなる。だから重要なのは、圧縮と可逆性のバランスである。

この考え方は、良い文章を書くときにも似ている。冗長な説明を削るだけではない。読者があとで戻ってきたときに、意味の構造がそのまま見えるように整える。AIコーディングでも同じで、出力の量ではなく、再利用できる構造が価値になる。

速さは一時的だが、圧縮された理解は残る。

だから、AI時代の優れた開発者は、コードを書く人というより、複雑さの圧縮形式を設計する人に近い。仕様書は圧縮形式であり、クリーンアップもまた圧縮形式だ。違うのは、前者が意味の圧縮、後者が構造の圧縮であることだけだ。

---

実践のための新しいメンタルモデル: 三層の作業台

この見方を実務に落とすなら、開発を三つの作業台に分けるとよい。

1. 意味の作業台

ここでは「何を作るのか」「なぜ必要なのか」「成功条件は何か」を固める。仕様駆動開発のツールが力を発揮するのはこの層だ。ここで残すべきものは、実装の細部ではなく、後から見ても判断基準として機能する文章である。

2. 構造の作業台

ここではコードの見通し、命名、責務分割、重複排除を扱う。/simplify が効くのはこの層だ。重要なのは、局所最適の見た目ではなく、将来の変更に対する抵抗を下げることだ。きれいにすること自体が目的ではない。

3. 変換の作業台

ここではフレームワーク移行、API変更、共通ルールの置き換えなど、複数箇所にまたがる更新を扱う。/batch が向いているのはこの層だ。ここで必要なのは細部の優しさではなく、整合性の強さである。

この三層モデルの利点は、AIに何を頼むかを考えるときに、感覚ではなく変更の種類で判断できることだ。結果として、無駄な往復が減る。AIに「もっと良くして」と曖昧に頼む代わりに、「これは意味の作業台」「これは構造の作業台」「これは変換の作業台」と分けて扱える。

たとえば、ログ出力の文言を整えたいだけなのに、フレームワーク移行と同じレベルの大工事をしてしまうことがある。逆に、ルーティングの大改修が必要なのに、単なる整形で済ませようとしてしまうこともある。三層に分けると、この混同が減る。

---

Key Takeaways

• AIに速く書かせるより、変更の粒度を見極めることが重要。局所修正と横断変更を混ぜない。
• 仕様は中間成果物ではなく、未来の変更に耐える知識の圧縮形式として扱う。
• Markdownで残るドキュメントは、ツール依存を超えて価値を持つ。残るのは機能ではなく判断基準。
• /simplify と /batch の使い分けは、作業内容ではなく変化の半径で決める。
• AI時代の開発者は、コードを書く人から、複雑さを圧縮設計する人へ移る。

---

結論: 未来の競争力は、生成量ではなく解像度で決まる

AIがコードを大量に出せるようになるほど、開発の中心は「作ること」から「分けること」へ移っていく。何を仕様として固定し、何を局所的に簡約し、何を横断的に変換するのか。この判断の解像度が高いほど、AIはただの自動生成器ではなく、思考を増幅する装置になる。

本当に強いチームは、たくさん書けるチームではない。どこで知識を縮め、どこで変更を分離し、どこで一貫性を保つかを知っているチームだ。

だから次にAIにコードを任せるとき、こう問い直してみるといい。「何を作るか」ではなく、「何を圧縮するか」。その問いに答えられるようになった瞬間、AI開発は単なる生産性向上ではなく、設計の質を上げる営みへ変わる。