「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段で上限を置き、止まったときの振る舞いと止める手順まで、明日ひとつ入れられる形で整理しました。