はじめに
すでに業務の中でAIを使っているエンジニアは、今や珍しくありません。
調べものをするとき、コードを書くとき、設計に迷ったとき。
AIは、仕事を進める上での選択肢の一つになっています。
ただ、同じようにAIを使っているはずなのに、仕事の進み方や、判断のしやすさに差が出ている。そんな場面を、現場で感じることが増えてきました。
ある人は、AIを使うことで考える余裕が生まれ、要件や設計の判断を前に進められています。
一方で、別の人は、AIを使っているにもかかわらず、仕様変更や認識ズレに振り回され、判断が後手に回ってしまう。
この差は、AIを使っているかどうかではありません。
どの段階で、何の目的でAIを使っているかによって生まれます。
本記事では、AIに仕事を奪われるかどうか、という話はしません。
また、ツールのインストール方法や設定手順を解説することもありません。
ここで扱いたいのは、業務には詳しいけれど、AIをまだ「設計の一部」として扱えていない人が、どうすればもう一段、仕事のレイヤーを上げられるかという視点です。
第1章：AI活用における基本戦略 役割を与えるという考え方
AIを使ってうまくいかない、という声を聞くと、その多くは「期待の置き方」に原因があります。
- いい感じに考えてくれるはず
- それっぽい答えを出してくれるはず
- 何なら設計も丸ごと任せられるのではないか
こうした期待をそのままAIに向けると、
返ってくるのは「それっぽいが使えない回答」であることがほとんどです。
一方で、AIをうまく使っている人たちは、AIを万能な頭脳としてではなく、役割を与えられた存在として扱っています。
たとえば、
- 設計案を一度言語化して、穴がないかを確認させる
- 自分の判断を前提に、「別の観点がないか」を洗い出させる
- 実装方針は決めた上で、コードの叩き台だけを作らせる
ここで重要なのは、
考える主体は常に自分側にあるという点です。
AIは「考える代行」ではなく、「考えたものをぶつける壁」や「仮想のレビュー相手」に近い存在です。
この距離感を取れるかどうかが、最初の分岐点になります。
第2章：プロンプト力の本質 問いを立て、業務を前に進める
AI活用というと、よく「プロンプト力」という言葉が出てきます。
ですが、ここで言うプロンプト力は、テクニックや言い回しの巧さではありません。
実際に効いてくるのは、次のような要素です。
- 何を前提条件として与えるか
- どこまでが確定事項で、どこからが検討対象なのか
- 最終的に、どんなアウトプットを期待しているのか
これらはすべて、
業務や設計をどう理解しているかに直結します。
つまり、プロンプト力とは「AI向けの特別なスキル」ではなく、
人に仕事を依頼するときの整理力に近いものです。
業務に詳しい人ほど、この整理を頭の中だけで済ませてしまいがちですが、それを一度言語化することで、AIは初めて力を発揮します。
AIにうまく答えさせるために考える過程そのものが、結果として、自分の設計をクリアにしてくれます。
この循環に入れるかどうかが、大きな差になります。
ここで一つ、プロンプトがうまく機能しない典型的なケースに触れておきます。
AIに投げた問いに対して、
「それっぽいけれど、使えない答え」が返ってきた経験は、
多くの人が持っているはずです。
このとき、「AIの精度が低い」「期待外れだった」と感じがちですが、実際には、問いの側が曖昧なまま投げられていることがほとんどです。
前提条件が揃っていない。
制約が言語化されていない。
何を判断してほしいのかが決まっていない。
こうした状態で問いを投げると、AIは「一般論としては正しいが、現場では使えない答え」を返します。
これは、AIが間違っているというより、与えられた情報から妥当な推測をしているだけです。
逆に言えば、問いを立て直し、前提や制約を整理したうえで投げ直すと、返ってくる内容の質は、はっきりと変わります。
この差は、テクニックの問題ではありません。プロンプトの成否を分けているのは、業務知識と、それを構造化して言語化する能力が結びついているかどうかです。
業務を理解していても、言語化できなければAIは使えません。言葉が巧みでも、業務理解が浅ければ意味のある答えは返ってきません。プロンプト力とは、この二つを融合させる力です。
第3章：設計戦略としての切り分け AIに任せない判断とは何か
AI時代の設計力は、
「全部を細かく決める力」ではありません。
むしろ重要なのは、
- ここは人が判断する
- ここはAIに任せる
- ここは結果だけ見ればいい
といった責任範囲の切り分けです。
たとえば、システム全体の構成や制約条件、業務的に外せない要件は人が決める。
一方で、
- 実装の選択肢出し
- 設定ファイルの叩き台
- 想定漏れの洗い出し
こうした部分は、AIに任せたほうが早く、しかも安定します。
設計力とは、「何を考えるか」だけでなく、後の手戻りや判断遅延を招く論点をあらかじめ排除し、「何を考えなくていい状態にするか」を決める力でもあります。
第4章：設計と要件定義を前に進めるためのAI活用戦略
設計や要件定義の段階で判断を誤ると、その影響は必ず実装フェーズ以降で表面化します。
後から発生する仕様変更や手戻り、再設計の多くは、この手前の工程で前提を固めきれなかったことに起因します。
AI活用の成否は、実装や自動化では決まりません。最も差が出るのは、設計や要件定義といった、不確実性の高いフェーズで判断をどう前に進めるかです。
多くの現場では、要件が完全に固まらないまま実装に入り、設計も「たぶんこれでいけそう」という感覚で進みます。
そしてレビューの段階で初めて、違和感や抜け漏れが言語化されます。
この流れ自体は珍しいものではありません。
ただ、その違和感が後工程で見つかるほど、手戻りのコストは大きくなっていきます。
そこでよく使っているのが、設計や要件定義の途中段階で、内容を一度AIにぶつけてみるというやり方です。
仕様書が存在しない、あるいは会話ベースで要件が更新され続けているなど、前提条件が流動的な状況では、設計や要件定義の途中段階で内容を一度AIにぶつけて整理するアプローチが有効です。
自分が考えた設計方針や構成案を、そのままAIに渡し、前提条件の抜け、リスクになりそうな点、運用フェーズで詰まりそうな箇所を洗い出させます。
要件メモや会話ログといった未整理の情報をAIに渡し、
「現時点で確定している前提は何か」
「未整理の論点はどこか」
「次に確認・調査すべき事項は何か」
を切り分けることで、判断を前に進めるための論点整理を行います。
正解を出してもらうというよりも、後工程で致命的な手戻りや仕様変更を引き起こし得る前提の固定化を避けるために、自分の思い込みとは別の視点から、立ち止まるべきポイントや、想定外の抜け漏れを見つけるための使い方です。
ここで重要なのは、AIに設計や判断を委ねるのではなく、AIを「検証の壁」として位置づけ、人が意思決定の主体であり続けることです。
あくまで、自分が考えた設計を、第三者の視点で眺めさせている、という感覚に近い使い方です。
この一手を挟むだけで、レビューで指摘されがちな点を事前に潰せたり、自分の思考の癖や偏りに気づけたりします。
その結果、他者に確認すべき点や、自分の立ち位置を整理した上で話ができるようになり、
「なぜ今この判断をするのか」を、クライアントやPMに対しても論理的に説明できる状態になり、不要な差し戻しや追加確認に費やす時間を減らせます。
このプロセスを挟まずに進めた場合、前提条件の固定化に気づかないまま実装が進み、開発後期における大幅な手戻りや再設計が発生するリスクが高まります。
同じ発想で、要件の整理にもAIを使うことがあります。
業務要件というのは、最初から整理された文章で降ってくることはほとんどありません。
断片的な要望や、曖昧な制約が混ざった状態で渡されるのが普通です。
この状態を一人で抱え込むと、「どこが決まっていて、どこが決まっていないのか」が自分でも分からなくなっていきます。
そこで、まだ粗い要件をそのままAIに渡し、
「この要件で何を達成しようとしているのか」
「必須要件と、後回しにできる要件はどれか」
「前提として曖昧な点はどこか」
といった問いを投げます。
ここでも、答えを出させることが目的ではありません。
AIの返答をきっかけに、自分の中で「これは決めきれていない」「ここは業務的に外せない」といった判断が、自然に浮かび上がってきます。
結果として、要件の粒度が揃い、実装範囲が明確になることで、実装工数の見積もり精度が上がり、後から前提を覆すような認識ズレや再設計のコストを抑えられます。
設計レビューと要件整理。
扱っているテーマは違いますが、AIとの関わり方としては共通しています。
それは、考える主体を最後まで手放していないという点です。
AIは判断を代わりに下す存在でも、責任を引き受ける存在でもありません。
考えを整理するための相手であり、視点を増やすための補助線です。
この距離感でAIを使えるようになると、設計や要件定義といった、
本来一人で抱えるには重たい工程が、ぐっと扱いやすくなります。
そしてその分、「どこをどう判断するか」という、エンジニアとして最も価値が出る部分に、時間と集中力を使えるようになります。
おわりに：AI時代にレイヤーを上げる人の共通点
AIを使っているかどうか自体は、もはや大きな差ではありません。
差が生まれるのは、AIをどこに組み込み、どこから先の判断と責任を自分が引き受けるのかを、意識的に設計できているかどうかです。
AIを活用するとは、判断や責任を手放すことではありません。
むしろ、不確実性の高い状況においても、自らの判断に説明責任を持ち続けるために、AIを戦略的に統合することだと言えます。
この「考える主体を手放さない」という姿勢は、Accountability（自己責任原則）に基づくAI統合戦略そのものです。
どこまでをAIに委ね、どこからを自分が担うのかを明確にできる人ほど、プロジェクトにおける信頼や意思決定の中心に立つようになります。
ツールや技術はこれからも変わり続けます。しかし、判断と責任を引き受ける立場を選び続ける限り、エンジニアとしての市場価値やキャリアのレイヤーは、AI時代においても着実に引き上げていけるはずです。