AI活用時代に必要なのは「先回り力」だと気づいた話

AIに丸投げして失敗した日々

Claude CodeやGitHub Copilotを使い始めた頃、僕は期待に胸を膨らませていた。

「AIがコードを書いてくれる時代が来た！もう設計とか細かいこと考えなくていいんじゃない？」

そう思って、雑な設計のまま「あとはAIに任せよう」とやってみた。結果は散々だった。

AIが書いたコードが既存の設計思想と合わない。修正を頼んだら、別の場所が壊れた。何度やり直しても、思った通りにならない。

「AIって使えないな」と思いかけたとき、あることに気づいた。うまくいくプロジェクトと、うまくいかないプロジェクトがある。その違いは何なのか。

答えは「準備」にあった。

先回り力という発見

試行錯誤の末にたどり着いたのが「先回り力」という考え方だ。

AIにうまく働いてもらうために、人間側が先に準備しておく力のこと。コードの構造を整理しておく、命名を明確にしておく、責務を分離しておく。これらの「先回り」ができているプロジェクトでは、AIは驚くほど良い仕事をしてくれる。

逆に、先回りができていないプロジェクトでは、AIは迷子になる。暗黙的な前提がわからない、複雑な依存関係が読めない、プロジェクト固有のルールが見えない。だから的外れな実装をしてしまう。

AIが悪いのではなく、人間側の準備が足りなかったのだ。

6つの領域

この「先回り力」を整理していくと、6つの領域に分けられることがわかった。

1つ目は「データ設計」。テーブル名やカラム名が明確で、リレーションが整理されていれば、AIは正しいクエリを書ける。逆に「tbl_01」「col_a」みたいな命名だと、AIは何が何だかわからない。

2つ目は「インフラ・ネットワーク」。環境変数の一覧、依存サービスの関係、デプロイ手順。これらが明文化されていれば、AIは正確に設定ファイルを書ける。暗黙知のまま放置していると、AIは推測で書くしかなくなる。

3つ目は「ベースプログラム」。1ファイル1責務、明確な関数名、適切なコメント。読みやすいコードはAIにも読みやすい。スパゲッティコードを渡しても、AIは困るだけだ。

4つ目は「アプリ設計」。レイヤー構造が明確で、どこに何を書くべきかがわかる設計。これがあれば、AIは適切な場所に機能を追加できる。なければ、変な場所に実装してしまう。

5つ目は「機能結合」。モジュールの境界が明確で、公開インターフェースと内部実装が分離されている。これがあれば、AIによる変更が他に影響しにくくなる。なければ、一箇所の変更が全体に波及する。

6つ目は「セキュリティ」。禁止パターンや必須の処理が明文化されている。これがあれば、AIも従ってくれる。なければ、脆弱なコードを書いてしまうかもしれない。

結局は「良い設計」の話

ここまで書いて気づいたことがある。

先回り力の内容は、実は昔から言われている「良い設計」の原則そのものだ。明確な命名、責務の分離、疎結合、ドキュメント化。AIが登場する前から、優れたエンジニアが実践してきたことだ。

AIの登場で変わったのは、これらの原則の「価値が可視化された」ことかもしれない。

良い設計のプロジェクトでは、AIがサクサク動く。悪い設計のプロジェクトでは、AIが迷子になる。この差が、はっきり見えるようになった。

AIは、僕たちの設計力を映す鏡なのかもしれない。

おわりに

「AIに任せればいい」という時代は、むしろ逆だった。

AIに任せるからこそ、人間側の準備が重要になる。先回り力がある設計なら、AIは10倍速で働いてくれる。なければ、AIも人間も苦労するだけだ。

このシリーズでは、6つの領域それぞれについて詳しく書いていく。データ設計、インフラ、ベースプログラム、アプリ設計、機能結合、セキュリティ。

AI時代だからこそ大事になる、設計力の話をしていきたい。