記事一覧

見積もりを出したら「AI使えば半分でできるでしょ」と返された——。工程ごとにAIが効く／効かないを分け、確認と手直しの時間まで含めて、後で自分が守れる工数を出すための考え方と伝え方を整理しました。

昨日と同じことを聞いたのに、AIの答えが違う。デモではうまくいったのに、本番の場ではぼんやりした回答になる——。AIの「毎回同じにならない」性質を、揺れを減らす手・揺れる前提で組む手・上に説明する言葉の3つに分けて整理しました。

頭の中では処理の流れが見えているのに、作図ツールで線を引き直すのが面倒で図がいつも後回し。そんなときは、AIにPlantUMLのテキストを書かせて図の下書きにするのが速いです。任せていい部分と、実装や仕様と食い違っていないか人が必ず見る部分の線引きを、コピーして使えるプロンプトとチェックリストで整理しました。

静的解析やLintをかけたら警告が数百件——全部は直せないし、どれが本当に危ないのかも見えない。そんなとき、警告の一覧をAIに渡して「今すぐ直す／後で／今回は見送る」に仕分けさせると、手をつける順番が見えてきます。ただし優先度の最終判断は、コードの事情を知るあなたの側。丸投げにしないための渡し方・確認の型と、そのまま使える仕分けプロンプトをまとめました。

グレーの候補が出るたびタブを押して、気づけば自分でほとんど書いていない——それでも動くから、そのまま進んでしまう。インライン補完は速いぶん、確認の隙間がいちばん薄い場所です。押す前の3秒と、押したあとに拾う仕組みを整理しました。

機能は作れたのに「本番の負荷は？」「落ちたら？」と後から聞かれてヒヤッとする——非機能要件は忘れた頃に牙をむきます。AIに観点を洗わせておくと、性能・可用性・運用・セキュリティの抜けを設計の早い段階で拾えます。ただし数値目標は自分で決める部分。コピーして使える観点リストとプロンプト、鵜呑みにしない確認の型まで整理しました。

社内資料を読ませたAIが、見当違いの答えを返す。上からは「精度を上げて」と言われるけれど、どこを触ればいいのか分からない——。そんなときに最初に見る場所を、検索と生成の切り分けから、チャンク分割・ハイブリッド検索の詰め方まで、順番に整理しました。

AIが出したシェルコマンドを、意味を追いきれないままコピペして実行する——その一回が、消したくないファイルを消してしまうことがあります。責める話ではなく、貼る前の数秒でヤバいコマンドを見分ける型を、コピーして使えるチェックリストとプロンプト付きで整理しました。

「このエンドポイント、URLの切り方これでいいのかな」と手が止まるとき、AIはたたき台を素早く出してくれる相棒になります。ただ前提を渡さずに聞くと、それらしいのに使いにくい設計が返ってくる。この記事は、AIにREST APIのエンドポイント設計を相談するときの前提の渡し方と、命名・粒度を詰める手順を、チェックリスト付きでまとめました。

似たようなCRUD、DTO、設定ファイル、テストの雛形——手で書くと退屈で、でも間違えると地味に痛い定型コード。AIに量産させれば一瞬ですが、そのまま流し込むと似て非なるコードが静かに紛れ込みます。この記事は、AIにボイラープレートを安全に量産させる頼み方と、目で追うべき最小の確認ポイントを一緒に整理します。

本番で動いているAI機能のプロンプトを、誰かがちょっと直したら別の場所の出力が崩れた——そんな事故は、プロンプトが管理されていないと必ず起きます。コードから切り出し、履歴を残し、本番に出す前に見比べる。壊さないための最小の運用を、今日から始められる形で一緒に整理します。

単体テストは書けても、E2Eや結合テストになると「どこまで書けばいいのか」で手が止まる。AIにシナリオを洗い出させたいけれど、丸投げすると正常系ばかり返ってくる。この記事では、抜けを減らす観点の渡し方と、そのままコピーして使える聞き方を一緒に整理します。

「このライブラリとあれ、どっちがいい？」——技術選定でAIに相談すると、それらしい比較表がすぐ返ってきます。でも、そのまま採用してよいか迷いますよね。AIの比較には見えにくいクセがあります。鵜呑みにせず、現場の制約に合った一つを選ぶための確認の型を整理しました。

チームの誰かが、会社が把握していないAIツールに業務のコードや資料を貼っている——気づいたときに、いきなり「禁止」と言いたくなりますよね。でも潰すだけだと、たいてい水面下に潜って余計に見えなくなります。シャドーAIが生まれる理由と、責めずに安全な道へ寄せていく現場の一手を整理しました。

直したはずのテストが、また別の日に落ちている。原因もはっきりせず、再実行すると通る。この「たまに落ちる（Flaky）テスト」を、AIに丸投げせず一緒に切り分けるための、原因の型と手順、そのまま使える聞き方を整理しました。

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

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

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

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

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