記事一覧

「このテーブル設計でいいのかな」と一人で抱え込むとき、AIは頼れる壁打ち相手になります。ただ、前提を渡さずに聞くと、それらしいけれど自分の要件に合わない案が返ってくる。この記事は、AIにDB・テーブル設計を相談するときに渡すべき前提の伝え方と、返ってきた案を鵜呑みにせず確かめる手順を、チェックリスト付きでまとめました。

ドキュメントがない・書いた人がいない・でも触らなきゃいけない。そんなレガシーコードの仕様を、AIを使って少しずつ読み解く進め方をまとめました。丸ごと貼って「仕様書にして」と頼む前に、範囲を絞って、AIの復元を叩き台として使い、必ず現物で裏を取る。仕様を「復元する」のではなく「仮説を立てて確かめる」ための、具体的な手順とチェックリストです。

最初は的確だったのに、やり取りを重ねるうちにAIの答えがだんだんズレていく——長い会話ほど起きやすい「文脈のにごり」です。粘って直そうとするより、いったんリセットして立て直したほうが速いことがあります。会話が長引いて生成がブレたときに、文脈を作り直して仕切り直す手順を、具体例とチェックリストにまとめました。

「テストデータ、それっぽいの100件用意しといて」——AIに頼めば一瞬です。でも、そのダミーに本物の個人情報が混じっていたら、正常系ばかりで異常系が抜けていたら。便利だからこそ、そのまま使う前に確認したい点があります。AIにテストデータ・ダミーデータを安全に作らせる型を、具体例とチェックリストにまとめました。

「ここを直して」と頼んだら、AIが5つも6つもファイルをまたいで書き換えてきて、差分の量に手が止まる——正しいのか、余計なことをしていないのか、追いきれない。そんなときは、任せる範囲を先に区切り、差分をファイル単位で小さく確認し、意図と関係ない変更を戻す。複数ファイル変更を安全に受け取る追い方を、手順とチェックリストで整理しました。

テストではきれいなJSONが返ってきたのに、本番でたまに前置きの一文が付いたり、途中で切れたりして落ちる——AIを業務システムに組み込むと、この「たまに崩れる」がいちばん怖いですよね。出力の型を先に決める、受け取ったら必ず検証する、崩れたら静かに立て直す。この3つを手順で整理しました。

赤いエラーがずらっと出て、コピペで検索しても同じ画面に戻ってくる——その時間、けっこう削れます。AIにビルド・実行エラーの原因を解説させて直すやり方を、「何をどこまで貼るか」「AIの答えを鵜呑みにしない確かめ方」まで、地味だけど効く手順にまとめました。今日からエラー画面に固まる時間を短くしていきましょう。

AIに書いてもらったコードが、命名もインデントもimportの順番もチームの規約と微妙に違う——毎回手で直すの、地味に疲れますよね。実は「毎回プロンプトで丁寧にお願いする」より、規約をAIが読む場所に置いて、最後はLinter・Formatterで機械的に直す方がずっと確実です。指示の仕込み方と、指示に頼りきらないチェックの仕込み方を、コピペできる形で整理しました。

「メールアドレスを弾く正規表現書いて」——AIはそれっぽいパターンをすぐ返してくれます。でも、そのまま使って大丈夫か不安になりますよね。正規表現は一見動いても、際どい入力でこっそりすり抜けたり、逆に正しい値まで弾いたりしがち。AIに書かせた正規表現を、通すべき入力・弾くべき入力・際どい入力で確かめる、地味だけど効く検証手順の型をまとめました。

実装は終わったのに、コミットメッセージとPR説明を書く手が止まる——その気持ち、よく分かります。ここはAIが得意な所ですが、丸投げすると「何をしたか」だけの当たり障りない文になりがち。差分を渡して下書きさせ、「なぜ」と「レビューで見てほしい所」だけ人が足す。レビュアーが楽になる頼み方と確認の型を、コピペできるプロンプトつきで整理しました。

業務システムにAI機能を載せると、必ず出てくるのが「外から来た文章に、勝手な指示が仕込まれていたら？」という不安です。プロンプトインジェクションは、難しく身構えるより「外部入力は指示ではなくデータとして扱う」という一本の軸で、明日から手を打てます。仕組みと、現場でまずやる守りの型を整理しました。

AIに頼むと、SQLもクエリを呼ぶコードも、驚くほどそれっぽく返ってきます。テスト環境では一瞬で動く。でも本番の何万行というデータで、急に遅くなる——その多くはN+1やインデックス漏れが原因です。動いたかどうかとは別に、AIのSQLで見落としやすい所を、実行計画の読み方まで手順で整理しました。

AIが書いたコードが、見慣れないライブラリを import してくる。便利そうだからと npm install や pip install してしまう前に、そのパッケージは本当に実在して、生きていて、この用途に妥当なのか——依存を1つ足すのは長く付き合う決断です。追加前に3分でできる確認の型を、実在しないパッケージ名の見抜き方から手順つきでまとめました。

Claude CodeやCursorのようなエージェントが、自分でファイルを直し、テストを走らせ、コミットまで進む——便利な反面、「気づいたら想定外の所まで書き換わっていた」と冷やっとしますよね。これはあなたの管理が甘いのではなく、自走の範囲と止め方を先に決めていないだけのことが多いんです。任せる度合いを段階で決め、止める合図を置き、いつでも戻せる状態を作る。その設計を、手順とチェックリストにまとめました。

エラーを貼る、修正案が返る、試す、また別のエラー——AIとの往復が30分、1時間と続いて、気づけば堂々巡り。これはあなたの詰めが甘いからではなく、ループの構造にハマっているだけのことが多いんです。いつ手を止めるか、どこで文脈をリセットするか、どう自分の手に取り戻すか。抜け出す手順を、具体例とチェックリストにまとめました。

AIが書いたコードは動く。でも「安全か」は別の話ですよね。秘密のべた書き、文字列連結のクエリ、未エスケープの出力——動作確認では気づきにくい穴が、そのまま残りがちです。全部を一度に見張るのは大変なので、まず穴が空きやすい3カ所だけを、コピーして使えるプロンプトとチェックリストで確認できるよう整理しました。

引き継いだ既存システムの設計が、なぜこうなっているのか分からない。そんなとき、AIに「問題点を直させる」のではなく「説明させる」使い方があります。設計の意図と弱点を言葉にしてもらい、自分の理解を深めるための問いの立て方を、鵜呑みにしないコツと一緒に整理しました。

AIに修正やリファクタを頼んだら、直したいところは直ったのに別の場所が壊れていた——このリグレッション（デグレ）が怖くて任せきれない。既存テストの文脈をどう渡せば「勝手に壊れる」を防げるか、そのまま使える手順とチェックリストで整理しました。

「このAIツール、勝手に使い始めて大丈夫かな」と一瞬ためらう——その感覚は正しいです。規約は提供元・自社・相手先の3方向にあり、どこか一つでも見落とすとあとで困ります。使い始める前に数分で確認できるよう、チェックすべき項目を3方向の型に整理しました。全部を完璧に、ではなく、まず一番効く一線から。

「この業務フローのどこかにAIを入れて」と言われても、いきなり全部を置き換える必要はありません。既存の流れを止めずにAIを試すには、差し込む一箇所を選び、人の確認を残したまま、戻せる形で小さく始めるのがいちばん安全です。この記事では、試験導入の設計を「差し込む場所・入口と出口・戻し方・見る数字」の順に、明日から一歩ずつ組める形で一緒に整理します。