記事一覧

AIが書いたコードは「動くけど、あとで読めない」になりがちですよね。全部書き直すのではなく、半年後の自分が困らない程度に整える最低限の手直しを、名前を直す→長い塊を分ける→暗黙の前提を言葉にする→こわい所にテストで足場を作る、の順に手順化しました。一度に全部でなく、まず効く所から。

「AIで使えるか使えないか」を、口論ではなく小さなPoC（お試し）で見せて合意する進め方。確かめたい問いを1つに絞り、合格ラインを先に決め、実データに近い例で試し、結果を見える形にして「進む/やめる/条件つき」を一緒に決める。過度な期待と現実のギャップを、静かに着地させるための現場の手順です。

AIに頼むと単体テストはあっという間に揃って、しかも全部グリーン。でも「通ること」と「正しさを守れていること」は別物です。緑のテストを鵜呑みにせず、何を確かめているのかを自分の目で見るための確認ポイントを、コピーして使えるチェックリスト付きで整理しました。

レビューの行列が詰まって、自分のレビュー待ちで誰かの手が止まる。AIに一次チェックを任せられたら、と思いますよね。任せていい範囲と、人が見るべき範囲の線引きを、そのまま使えるプロンプトとチェックリスト付きで深掘りして整理しました。

PoCでは動いたAIが、本番では時々おかしな返事をしたり、止まったりする——それはあなたの実装ミスではなく、AIが本来「ゆらぐ」ものだからです。失敗を前提に、リトライ・タイムアウト・代替経路・人へのエスカレーションをどう組むか。明日から小さく入れられるフォールバック設計の型を、判断の順番とチェックリストで整理しました。

AIを業務に載せたいけれど、丸ごと任せるのは怖い——その感覚は正しいです。だからこそ「人の確認をどこに、どう挟むか（ヒューマンインザループ）」を設計します。チェックを入れる4つの位置、確認を軽くする見せ方、誰が責任を持つかの線引き、そして形骸化させないコツまで。明日から小さく試せる手順とチェックリストで整理しました。

「これもAIでいいよね」と任される範囲が広がる中で、どこまで任せ、どこから人が判断するのか。取り返しのつくか・正解が検証できるか・責任を負えるかという3つの軸で、AIに任せてよい仕事と人が握るべき判断を一緒に線引きします。明日の現場でそのまま使える具体例とチェックリスト付き。

「ここ、きれいにリファクタしといて」とAIに頼んだら、差分が思ったより広くて読むのがしんどい——そんな経験ありますよね。リファクタは本来「振る舞いを変えずに中身を整える」作業。差分から“こっそり混じった挙動の変化”を見抜く確認手順を、範囲を先に決める→小さく刻む→振る舞いの差を読む→テストで固定する、の順に整理しました。

PoCは動いた。でも本番に出す前に「月いくらかかる？」「アクセスが集中したら止まらない？」と聞かれて言葉に詰まる——その不安は当然です。トークンからコストを出す式、レート制限の3つの軸、PoCの実測から本番を外挿する手順、そして上振れに耐える設計まで。見積もりに自信を持つための型を、計算例と比較表、チェックリストつきで深掘りしました。

AIに書かせたコードが、動くのに既存のコードから浮いてしまう。命名も書き方も置き場所もチームの流儀とずれる——その多くは、既存コードベースの文脈をうまく渡せていないだけです。何を、どの粒度で、どう要約して渡せば生成コードが馴染むのか。明日から使える文脈の渡し方を、コピーして使えるテンプレつきで整理しました。

「テストケースを出して」とAIに頼むと、正常系ばかりが並びがちです。本当に欲しいのは、自分が見落としている異常系や境界値。漏れを減らすために、どんな観点をAIに渡せばいいのかを、コピーして使えるテンプレ付きで整理しました。

「このコード、AIに貼って大丈夫だろうか」と一瞬迷う——その迷いは正しいです。何をそのまま入れてよくて、何は加工が要り、何は入れないのか。学習の扱いやツール設定まで含めて、入力前に数十秒で判断できる線引きの型に整理しました。一度に完璧でなく、まず一番危ない一線から。

設計を相談できる相手が近くにいないとき、AIは壁打ち相手になります。ただ「どう設計すればいい？」と聞くと、もっともらしい一案が返って終わりがち。前提・制約・案の比較・反論を引き出す問いの立て方を、コピーして使えるテンプレ付きで整理しました。

AIがもっともらしく嘘をつく「ハルシネーション」。存在しないAPIや、入れたら危ないパッケージ名、自信たっぷりの誤った仕様——開発現場では特有の形で現れます。なぜ起きるのか、どんなサインで気づくのか、一次情報でどう裏を取るのか。明日から使える見抜き方の型を、具体例とチェックリストつきで深掘りしました。

AIが書いたコードが「テストも緑だし動いてるっぽい」とき、そのままコミットしていいか迷いますよね。読んで確かめるレビューとは別に、実際に動かして確かめる「動作確認の型」を、最小単位で試す→正常系を通す→意地悪入力→副作用→ログの5手順に整理しました。一度に全部でなく、まず効く所から。

AIが書いたコードが「動くけど、ちょっと違う」になるのは、たいてい頼む前の伝え方に原因があります。ゴール・入出力・制約・既存コードの文脈・完成基準の5つを、書かせる前にどうそろえて渡すか。手戻りを減らすプロンプトの型を、コピーして使えるテンプレと例つきで深掘りしました。

上司やクライアントから「AIで何とかしろ」と言われて、何から手をつければいいか戸惑うとき。いきなり作り始める前に、目的・期待値・制約・成功基準・体制・自走の線引きの6つをそろえると、後の手戻りと板挟みがぐっと減ります。曖昧な丸投げを、今日ひとつ形にするための最初の確認手順。

AIが書いたコードを「動いたから」とそのまま使うのが不安なとき、何をどの順番で見ればいいか。仕様の取り違え・境界・セキュリティ・依存・可読性まで、レビューと検証の観点を現場で使えるチェックリストに整理しました。一度に全部でなく、まず効く所から。