記事一覧

「AIに聞いたら、できるって言ってたよ」——営業や企画の同僚がAIの答えを持って席に来たとき、どう返せばいいか迷いませんか。AIの得意は「形を作る」こと、苦手は「正しさを保証する」こと。この一言を軸に、非エンジニアの同僚との誤解を角を立てずにほどく説明の型を、言い回しとチェックリストつきで整理しました。

「先週、AIが変な回答をしたらしい。何を聞かれて、何を返したの？」——そう聞かれて、手元に何も残っていない。AI機能を業務システムに組み込んだときに、後からたどれる利用ログ・監査ログを「誰が・何を渡し・何が返り・人がどうしたか」の4点で残す設計と、残しすぎないための線引きを、チェックリストつきで一緒に整理します。

自社システムの脆弱性テストを頼んだだけなのに、AIに「お手伝いできません」と返される。言い換えを繰り返すうちに、30分が過ぎている——。AIの拒否を「止まるべきもの」と「伝え直せば通るもの」に仕分けて、抜け道を探さずに前へ進む頼み直しの型と、AI機能に組み込んだときの備えを整理しました。

自分のテストは全部通っているのに、つないだ瞬間に画面が真っ白になる。原因は、相手のAPIが返す形と、こちらが思っていた形のわずかなズレ。契約テストの観点をAIに洗い出させ、相手と突き合わせて、小さな1本から始める進め方を、頼み方のテンプレとチェックリストつきで整理しました。

「この関数、ちょっと直しておいて」——開いてみたら、見たことのない書き方が並んでいる。AIに説明させると、それらしい答えはすぐ返ってきます。でも、触るときに本当に要るのは「何をしているか」より「何を前提にしているか」。AIの説明を仮説として受け取り、小さく動かして確かめる読み方を、頼み方のテンプレとチェックリストつきで整理しました。

「古いPythonのバッチ、AIでTypeScriptに書き直しておいて」——動くコードはすぐ出てくるのに、なぜか数字が1円ずれる。移植で怖いのは文法ではなく、言語ごとの「当たり前」の違いです。移植前に今の挙動を固定し、同じ入力で新旧を突き合わせる確認手順を、チェックリストつきで整理しました。

AI機能を出したのに「間違ってるのに直せない」「直したら再生成で消えた」と言われていませんか。AIの精度が足りないのではなく、人が直す場所が用意されていないだけかもしれません。AIの出力を「下書き」として出し、人が修正して確定する——その前提で画面を組むための4つの型を、明日からの一歩とチェックリストで整理しました。

「これ、AIでパッとやってもらえない？」が一日に何度も来て、自分の作業が夜に押し出されていませんか。頼られるのは悪いことではありません。全部を引き受けるか断るかの二択ではなく、「代わりにやる・隣でやる・型を渡す」の3段階で返し、窓口と依頼の型を決めて仕組みに変える方法を、言い回しとチェックリストつきで整理しました。

朝、いつものAIツールがつながらなくて、手が止まってしまった——そんな日はありませんか。AIへの依存そのものは悪いことではありません。困るのは「止まったときの次の一手」が決まっていないことです。障害・値上げ・提供終了の3つに分けて、業務が止まらないための備えを、明日できる小さな手順で整理しました。

「AI使ってるんだよね？なんでまだ終わらないの？」と聞かれて、うまく答えられずに謝ってしまった——そんな夕方はありませんか。AIで短くなるのは「書く時間」で、「確かめる時間」と「捨てる時間」は残ります。試行錯誤の時間を4つに分けて見せ、3文で説明するための型を、そのまま使える言い回しつきで整理しました。

AI機能が失敗したとき、画面に「エラーが発生しました」とだけ出して、問い合わせが増えていませんか。裏側のリトライは作ったのに、表側の見せ方は後回し——現場ではよくあることです。失敗の種類ごとに「何が起きたか・入力は無事か・次に何をすればいいか」を伝える、エラー表示の設計の型を整理しました。

朝いちばんにAIの請求画面を開いて、昨夜のグラフだけ跳ね上がっていた——そんな冷や汗を二度とかかないために。「呼び出しごと」「利用者ごと」「機能全体」の3段で上限を置き、止まったときの振る舞いと止める手順まで、明日ひとつ入れられる形で整理しました。

「AIでテストも全部書けるよね」と言われても、時間は有限です。全部を同じ厚さで書こうとすると、本当に守りたい所が薄くなりがち。AIに「壊れたら困る度合い」と「変わりやすさ」を渡して判断材料を並べさせ、どこを厚く・どこを薄くするかを人が決める手順を、プロンプトとチェックリストつきで整理しました。

AIに「フォルダ構成を考えて」と頼むと、それらしい controllers / services / utils がすぐ出てきます。でも半年後、services に何十ファイルも積み上がり、utils が何でも置き場に。崩れる原因は案の良し悪しより「変更の起き方」を渡していないことでした。AIに判断材料を並べさせ、変更シナリオで試してから決める手順を、プロンプトとチェックリストつきで整理しました。

「先週までは動いていたのに」。その間に入ったコミットは数十件、AIに聞くと怪しい候補をもっともらしく挙げてくる——。原因コミットは推測で当てず、git bisect の二分探索で事実として絞り込むのが近道です。AIには再現スクリプト作りと、見つかった差分の読み解きを任せる。その分担と手順を、チェックリストつきでまとめました。

CIが赤くなって開いたテストの名前が「test1」や「正しく動くこと」。何を確かめていたのか分からず、テストの中身を読み解くところから始まる——AIに書かせたテストでは、よくあることです。落ちた瞬間に「何が壊れたか」が読めるテスト名の型と、「なぜこの値か」だけを残す意図コメント、AIに中身を変えずに整えさせる頼み方を、チェックリストつきで整理しました。

AIが書いたコードは動く。でも data、result、handle、flg……名前を見ても何をしているのか分からない。命名のずれは、AIのせいでも自分の不注意でもなく、「業務の言葉」を渡していないことから起きやすいものです。ずれた名前の見つけ方、チームの言葉を渡して候補を出させる聞き方、動作を変えずに安全に直す手順を、チェックリストつきで整理しました。

プッシュしてからCIが終わるまで、コーヒーを淹れても戻ってこない。「テストが遅い」のは分かっていても、どこが遅いのかは意外と測っていないものです。時間を段取りごとに測り、その数字をAIに渡して原因の型に当てはめ、効きそうな所から1つずつ直す——待ち時間を無理なく減らす手順を、聞き方とチェックリストつきで整理しました。

AIが出してくれたサンプルコード、そのまま貼ったのに動かない。自分の書き方が悪いのか、コードが間違っているのか、それとも手元のバージョンと合っていないのか。原因を3つに分けて、短い時間で見当をつける切り分けの手順を、聞き直し方とチェックリストつきでまとめました。

「リリース前に負荷試験もやっておいて」と言われて、AIにシナリオを頼んだら、それらしい数字が並んで返ってきた——でも、その数字はどこから来たのでしょう。本番の山はアクセスログから自分で見積もり、AIには操作の流れと観点の洗い出しを任せる。性能テストのシナリオを無理なく組み立てる手順を、チェックリスト付きで整理します。