あかね
AI使ってエンジニアするならやっぱ基礎知識が大事だなと思った話
2026年06月01日
見出しはありません
要約を生成中...
さっきまで仕事していて、「やっぱりAI時代こそ基礎知識って大事だな」と思う出来事が繰り返しありました。
最近は「AIがあるから勉強しなくていいのでは?」とか「誰でもアプリ作れる!」いう話もよく見かけます。
でも実際に仕事でAIを使っている私の感覚は全く逆です。
AIはたくさん案を出してくれますし、大体動きます。
ただ問題はそこではなくて、その案が本当に今のシステムにとって適切なのか判断できるかだと思うんです。
AIでコード生成している間にこのブログを書いております
フォームの実装で、必須の項目を空にして送信した時に私が期待していたエラーメッセージが表示されませんでした。
調べていくと、
<input required />が原因でブラウザ標準バリデーションが先に動いていました。
標準のエラーメッセージ出てるんだけど!直して!と雑にお願いしたところ、AIは
noValidateを付けましょう
と提案してくれました。
確かにそれで症状は解消します。
でも私が最初に思ったのは「ん?RHFとzod使ってるのに、そもそもなんでrequired付いてるんだ?」でした😂
今回の画面ではReact Hook Formとzodを使っています。
つまりバリデーションの責務はzodという設計です。
だったら見るべきなのは、「noValidateを付けるか」ではなく、「zod側に空入力を拾うケースが足りているか」です。
「zodに空の場合のバリデーションケース追加して。最低文字数しかないんやない?」で図星で思った通りになりました。
AIの提案は間違っていませんが、原因までは見ていませんでした。
症状に対処することと、設計として正しい方向へ直すことは別なんだなと改めて感じました。
別の実装では、モーダルを開いた時に現在価格をフォームへ表示したいケースがありました。
AIに相談すると、こんな案が返ってきました。
useEffect(() => {
if (isOpen) {
reset({
currentPrice,
});
}
}, [isOpen, currentPrice]);確かに動きますが!!!見た瞬間なんかキモいなと思いました。
私がやりたいのは、「モーダルを開いたら値を入れる」ってことではなく、「現在価格を表示する」なんですよね。
なのに提案された実装は、モーダルの開閉イベントとフォームの状態が結び付いていました。
??isOpenの分岐いる??propsで受け取ったのをdefaultValuesに渡すだけでいいと思うんやけど???
そのまま提案してみました。すると今度は
その通りです!条件付きレンダリングで再マウントしましょう!
という案が返ってきました。これも動きます。でも思いました。
「なんでそんなに頑張って初期化しようとしてるんだろう?」
今回の画面はSWRでデータ取得しています。
だったら最新データはpropsとして渡ってくるはずです。
なので、
SWRで最新値来るよね?
親コンポーネント再レンダリングされるよね?
じゃあそもそもuseEffectいる?
という疑問が出てきました。
最終的にはReact Hook Formが元々持っている機能で解決できました。
結果として、
reset不要
useEffect不要
条件付きレンダリング不要
になりました。
動くコードを書くことと、必要以上に複雑な実装をしないことは別だなと改めて感じました。
今度API側で状態遷移の設計で新パターンがあることを発見して、それを追加せねばとAIと話していた時も似たことがありました。
AIは新しいstatusを追加する案を出してきました。
でも見た瞬間、「その状態、本当に保存する必要ある?」と思いました。
既に持っている情報から計算できるなら、新しい状態を増やす必要はありません。
結果的にAIが真っ先に提案してきた以下の内容は不要。
migration不要
enum追加不要
backfill不要
になりました。モデルにそのパターンか返すメソッドを生やして終わりです。シンプル。
ここで誤解してほしくないのは、AIの提案はどれも間違っていないことです。
実際、
noValidate
useEffect + reset
条件付きレンダリング
status追加
全部動きますしそれなりに正しいです。
でも私がずっと気にしていたのは動くかどうかではありません。
RHF使ってるのにrequired付ける?
zod使ってるのにHTMLバリデーション使う?
SWRで値更新されるのにuseEffectいる?
既存情報で表現できるのにstatus増やす?
ということです。
つまり、「本当にその実装必要?」をずっと見ていました。
そして今回改めて思ったのが、こういう違和感って基礎知識がないと出てこないんですよね。
Reactを知らなかったら、「なるほど、useEffectでやるんですね」で終わります。
状態遷移設計を知らなかったら、「なるほど、status増やすんですね」で終わります。
AIが出した案を評価することもできません。
最近よく、「AIがコードを書いてくれるからアプリ開発簡単」という話を見ます。
でも実際に使っていると、AIは案を出してくれるだけです。
その案が良いのか悪いのか?
今のシステムに合っているのか?
もっとシンプルな方法がないのか?
そこを判断するためには、やっぱり基礎知識が必要です。
AI時代だから勉強しなくていいのではなく、AI時代だからこそ基礎知識が大事。
今回のやり取りで、それを改めて実感しました。
このコード出してきたのclaude codeのOpus4.8です、、、
見事に例になる典型的なコードや設計提案が相次いだので共有をと思ってまとめました。
AIでそれっぽいアプリを作ること自体は簡単になりました。
ポートフォリオできたし転職しよう!と思った時に、比較対象のライバルがゴリゴリAIを使って見栄えの良いポートフォリオを普通に作ってくると思います。
そうなると成果物だけでは差が付きにくくなって、なぜそう設計したのか説明できる人の方が強くなるんじゃないかなと思っています。
腐らず頑張りましょう!!
コメント
まだコメントはありません。