「AIが迷わない設計」という考え方
設計の曖昧さが見えるようになった
AIにコードを書かせるようになって、気づいたことがある。
AIが間違えるとき、原因の多くは設計にあった。曖昧な設計が、AIを迷わせている。
これは新しい発見ではない。曖昧な設計は、人間も迷わせる。ただ、人間は「たぶんこうだろう」と補完して、なんとかしてしまう。AIはそれをしない。曖昧なら曖昧なまま、推測して実装する。
だからAIが間違えると、設計の曖昧さがダイレクトに見える。
AIは設計の品質を映す鏡だ。
曖昧さとは何か
設計における曖昧さとは、「解釈の余地がある」状態のこと。
テーブル名を見ても何を表しているかわからない。カラム名を見ても何が入るか推測するしかない。テーブル間の関係が明示されていない。同じ概念に対して、場所によって違う名前が使われている。
こういう状態だと、実装者は推測に頼るしかない。推測が合っていればいいけど、外れればバグになる。
人間なら「これってこういう意味ですよね？」と確認できる。AIはそれをしない。推測して、そのまま実装する。
「迷わない設計」という視点
だから、こういう視点を持つようになった。
「このスキーマをAIに渡したら、迷わず正しい実装ができるか？」
これは具体的なテクニックの話ではない。設計するときの姿勢、アプローチの話だ。
設計に曖昧さを残さない。解釈の余地を減らす。意図を明示する。
この姿勢で設計すると、結果的に人間にとってもわかりやすい設計になる。
曖昧さを排除するアプローチ
意図を明示する
「なんとなくこうしておく」ではなく、「こういう意図でこう設計した」を明示する。
名前、構造、制約。すべてに意図がある状態にする。
意図がない設計は、解釈の余地を生む。「これは何のためにあるんだろう」と考える時間が発生する。その時間は、推測が外れるリスクでもある。
一貫性を保つ
同じ概念には同じ名前を使う。同じパターンには同じ構造を使う。
一貫性があれば、「このパターンならこうだろう」と予測できる。一貫性がなければ、毎回推測になる。
ルールは何でもいい。大事なのは一貫していること。
関係を明示する
テーブル間の関係、データ間の依存関係。暗黙の了解ではなく、スキーマ上で明示する。
人間なら「たぶんこうだろう」で済むことも、AIには明示的な情報が必要。そして、明示的な情報があれば、人間も迷わない。
後から破綻しない構造を考える
今の要件だけでなく、「この構造で将来困らないか」を考える。
ただし、これは「先回りして複雑にしろ」という意味ではない。
シンプルさを保ちつつ、破綻しない構造を選ぶということ。過剰に複雑な設計は、それ自体が曖昧さを生む。
設計時の問いかけ
設計するとき、こんな問いかけをするようになった。
意図の明示について。この名前で、何を表しているかわかるか。この構造の意図は、スキーマを見ただけで伝わるか。
一貫性について。同じ概念に、違う名前を使っていないか。同じパターンに、違う構造を使っていないか。
関係の明示について。テーブル間の関係は、スキーマ上で明示されているか。暗黙の了解に頼っていないか。
将来の破綻について。この構造で、想定される拡張に対応できるか。変更が必要になったとき、影響範囲は限定されているか。
AIが間違えたら設計を疑う
AIが間違えたとき、最初は「AIが悪い」と思っていた。
でも、設計を見直すと、曖昧さがあることが多かった。
名前が不明確だったり、関係が暗黙だったり、一貫性がなかったり。AIは素直にそれを受け取って、推測して、間違えた。
今は、AIが間違えたら設計を疑うようになった。「どこに曖昧さがあったか」を考える。そして設計を直す。
すると、AIだけでなく、人間にとってもわかりやすい設計になる。
結局は良い設計の話
「AIが迷わない設計」は、特別な設計手法ではない。
意図が明確で、一貫性があり、関係が明示されていて、シンプル。
これは昔から言われている良い設計の原則そのものだ。
AIの登場で変わったのは、この原則の価値が可視化されたこと。曖昧な設計はAIが間違えるという形で、すぐにフィードバックが返ってくる。
おわりに
「このスキーマをAIに渡したら、迷わず正しい実装ができるか？」
この問いを持ちながら設計するだけで、設計の質は変わる。
それは同時に、「半年後の自分が見たら、迷わず理解できるか？」という問いでもある。
AIに優しい設計は、人間にも優しい設計だ。
AIの性能を引き出すためのスキル集を提供しています。
良ければ利用してみてください。
Discussion