あかね
会話を仕様として読んでしまう私の脳内をAIに翻訳してもらった
2026年05月28日
要約を生成中...
はじめに
最近、私って言葉尻とか気にしすぎる揚げ足取りBBAやんって思うことが多くて😂
仕事中のみならず、日常的にどうも気になってしまう性分です。
自分では「ただ細かいだけ」「揚げ足取りっぽいだけ」だと思っていました😂
どう思うかAIに聞いてみたら「それ、会話を仕様として読んでるんですよ」って言われて、めちゃくちゃ腑に落ちたんです。
今回は、そんな言葉の違和感検知と、実務での設計・レビューでは活かせているって話を書いてみます！
SNSでも気になる
その１
先日はUIUX講師 あすかさんの投稿で、「はい/いいえではなく、動詞にしましょう！」って解説があり、なるほどなるほど、と思いながら見ていると(デザイナー不在のプロダクト開発でフロントよくやるのでめちゃ勉強になります🥹仕事で即実践できるw)、画面に映っていたのは「削除」「キャンセル」だったので「動詞、、、？削除って国語的には名詞ではないだろうか…？🤔」「じゃあ”削除する”とか動詞にするが正しいのかな？動詞って表現が誤りだったのかな、、？」って気になって気になって、DMしてしまいました😂
結果的には、「動詞である必要はなく、押した結果がユーザーに伝わることが大事」という話で、めちゃ納得したんです。
その２
他にもこんなエピソードはあり、SNSで見かけたアンケートに私はいつものように引っかかりました。
「この働き方、年収いくらなら続けますか？」という質問。
選択肢には最後に、「そもそもやりたくない」があって、その瞬間、「ん？どっちの意味？」と思いました。
質問にある「続ける」という言葉からは、すでにその働き方をしている人が、今後も継続するかどうかを聞かれているように見える。
でも、「そもそもやりたくない」という選択肢があることで、
これから転職先として選ぶ話なのか
既に働いている前提なのか
が曖昧になりますよね。
回答の選択肢を見た瞬間、前提が混在していてどっちかにより回答が変わるよねと思って仕方がなかったんです、、
今すでに年収1000万なら辞めない
ゼロから転職するなら選ばない
つまり、回答者ごとに脳内でこれらの前提を補完していて回答しているってことになりますよね。
だから同じ選択肢を押していても、意味が一致していない可能性があるってことになるからどうしても引っかかってしまうんです、、
AIによる言語化
私くそめんどい人間よねって思いながら、仕事でこんなことばっかいつも聞いてるよなって思って、AIにこの話をしたら、「それ、揚げ足取りじゃなくて設計思考ですよ」って言われて衝撃。 揚げ足とってるわけじゃないのか私！よかった！！！（単純）
で、せっかくだから「なんでこういう質問してしまうん？」ってもう少し深掘りしてみたんです。
私：「仕様の説明を聞いてるとき、つい"それって前提が違ったらどうなるの？"とか"時系列おかしくない？"って気になっちゃうんだけど、これって何をやってるの？」
AI：「それは暗黙の前提を抽出して、反例で検証して、時系列でトレースして…というプロセスを無意識にやっています。認識のズレを"実装前に"検知しようとしているんですよ」
え、そんなにちゃんとしたことやってたんや😂
私としてはただ気になるものは気になるだけだったんですが、よかった😂w
言葉・前提・意思・時系列がズレると、「どれを信じて実装すればいいの！？」が気になってしまうみたいです。 そしてこれは、技術力そのものというより、設計やレビューで「認識ズレを早めに検知する力」としてかなり大事なスキルなのではと最近感じています。
で、そのプロセスをAIに整理してもらったのが以下です。
脳内フロー
① 暗黙前提の抽出 — 発言の中に「言ってないけど前提にされてる何か」がないかを常に探している。「承認したら発送待ち」という文には「承認＝確認済み」という前提が埋め込まれている。
② 反例の自動生成 — 「その仕様、これが起きたら壊れない？」というシナリオが浮かんでくる。「申請後に追加されたら？」がまさにこれ。
③ 時系列トレース — 状態を時間軸で追う。「今の値を見る」と「あの時点の値を見る」が同じだと思われていないか確認する。
④ 矛盾の検知 — ①②③の結果がかみ合わない箇所を検知する。揚げ足取りに見えるのはここが言葉に出た瞬間。
⑤ 質問する — 「どっちが正しいですか？」ではなく「どれを信じて実装すればいい？」という形で確認する。
⑥ 共通定義に着地させる — ズレを指摘して終わりではなく、「じゃあこう定義しよう」まで持っていく。
しょっちゅうこういう質問して確認しているのですが、最後はちゃんと話がまとまりますw
違和感検知したのにスルーしてバグらせるより、しつこく腹落ちするまで聞いて正しく設計する方が断然いいですよね。
実務例
実際仕事でもこのような会話がありました。設計するときに要求の確認をしている場面です。
私：「登場人物Aが入力したら承認できる、hogeがなしならfugaになる、ここまで認識合ってますか？」
相手：「hogeなしのケースは、登場人物Bが確認後に承認したらfuga待ちになる想定ですね」
私：「あれ、でもhogeなしだと仕様が登場人物Bに見えない実装になってるんですが、それで大丈夫ですか？」
相手：「あーそれなら登場人物Bに仕様見せないとだめっすね」
私：「じゃあhogeの有無に関わらず、登場人物Aが承認したら登場人物Bが確認して承認する、ということでいいですか？」
（ここまでは良かったけどなんかまだズレを感じる）
私：「申請時点も承認時点も仕様がなかった場合と、申請時点ではなかったけど承認までの間に追加された場合で挙動が変わりますよね。登場人物Bの承認判断は"今仕様があるか"で見てますか、それとも"申請時点でどうだったか"で見てますか？」
相手：「…あいや、承認時だと申請中に入力された場合とかに対応できないなぁ」
私：「ですよね。申請〜承認までの間に状態が変わっても問題ないようにするなら、申請時点の事実を持っておく必要がありますよね?」
（設計方針を話して整理）
相手：「我ながらよい設計な気がする」
めでたしめでたし🚀
おわりに
「細かいこと気にしすぎかな」「揚げ足取りっぽいかな」って思うことも多かったんですが、最近は認識ズレを放置しない、曖昧な前提をそのまま実装しないって、実はかなり大事な役割なんだなと思うようになりました。
もちろん、聞き方は気をつけたいと思います😂
でも、
前提が揃っているか
時系列が矛盾していないか
誰が何を判断する責務なのか
を確認することで、後から思ってたのと違うを減らせると思います。(あるけど普通にw前提がシレッと変わってることも多々)
だから私は今日も明日も、「つまりどっちですか？前言ってたんと違うけど前提変わりましたか？」をやっている気がします。
そこまで深く考えてなかったけど！みたいなこと多く、勝手に深読みして言葉のニュアンスとかで言い換えるとこうだなとか考えて、無駄に疲れることもありますw
でも要求の整理して仕様設計するときには曖昧な部分を放置しないので(そこはどうでもいいってこともありますが)、役にも立ってると思ってます！！
私は(状況に応じてだけど)このままでいきます！！！
