AIを使いこなしている人を見ていると、大きく2つのタイプに分かれると感じます。どちらにも共通する前提は、言語化が上手いことです。違いが出るのは「どこから始めるか」です。
この記事では、2つのタイプの違いと、知識が少ない人でもAIで成果を出せる進め方を紹介します。
タイプ1：知識先行型（設計 → 開発）
業務知識や設計の基礎がしっかりある人です。AIの出力を叩き台として受け取り、自分の知識で修正を入れていきます。
AIは優秀な副操縦士という位置づけです。手戻りが少なく、コストも小さく済みます。
たとえば、ログイン機能のAPIをAIに作らせたとします。知識先行型の人は、出てきたコードを見てすぐにこう返します。
トークンの有効期限が長すぎるので15分にして、リフレッシュトークンを別に用意してください。あと、ログイン失敗時に「ユーザーが存在しません」と返すと、登録済みのメールアドレスが推測できてしまうので、メッセージを統一してください。
何がまずいかを自分で判断できるので、AIへの指示も具体的です。1〜2往復で、実用的なコードにたどり着きます。
タイプ2：AI先行型（開発 → 設計 → 開発）
こちらは土台をまるごとAIに作らせるところから始めます。さらに、その土台のレビューもAIに任せます。
コツは、プロンプトに「シニアエンジニアの観点で」「ベストプラクティスに沿って」といった言葉を入れてチューニングすることです。完成したら、またシニアエンジニア視点でダメ出しをさせ、修正させる。これを繰り返します。
同じログイン機能なら、流れはこうなります。まずは作らせます。
ログイン機能のAPIを作ってください。
次に、観点を指定してレビューさせます。
シニアエンジニアの観点で、このコードをレビューしてください。セキュリティ、保守性、テストのしやすさの3点で、重要な順に指摘してください。
最後に、指摘を反映させます。
指摘をすべて反映して修正してください。修正後にもう一度、同じ観点でレビューしてください。
知識先行型が自分で気づいたトークンの有効期限やエラーメッセージの問題も、このレビューの中でAIが指摘してくれることが多いです。自分に知識がなくても、「知識がある人の目」をAIに借りるわけです。
「AならB、BならA」はinput不足のサイン
この往復を続けると、あるところで指摘がループし始めます。Aに直せばBと言われ、Bに直せばAと言われる状態です。
たとえば、入力チェックの置き場所でこんなループが起きます。
- AI「入力チェックは画面に近い層（Controller）でまとめるべきです」→ 修正する
- AI「入力チェックは業務ルールなので、モデル層に置くべきです」→ 修正する
- AI「Controllerが入力を検証していないため、不正なデータが奥まで届きます」→ 最初に戻る
これはAIの性能の限界ではなく、判断に必要な前提（input）が足りていないサインです。どちらも一般論としては正しく、決め手になる情報がないので揺れているのです。
ここでAIに、足りない情報を洗い出してもらいます。
直前の指摘が以前の指摘と矛盾しています。どちらを採用すべきか決めるために、不足している前提条件を挙げてください。
すると、AIは「このプロジェクトのレイヤー構成の方針」「同じ入力チェックを他の画面やバッチでも使い回すか」といった、判断に必要な問いを返してきます。
そこで初めて、要件や設計の知識を本格的に吸収するフェーズに入ります。レイヤー構成とは何か、チームの方針はどうなっているか。調べるべきことが、具体的な問いの形で手に入るのです。AI先行型の人は、作りながら「何を知るべきか」を逆算して学んでいます。
AI先行型の進め方
知識が少ない状態から始めるなら、次の順番がおすすめです。
- まず作らせる。 完璧な指示を目指さず、作りたいものを一文で伝えます。
- 観点を指定してレビューさせる。 「シニアエンジニアの観点で」に加えて、「セキュリティ」「保守性」など見てほしい観点を具体的に書きます。
- 指摘を反映させ、もう一度レビューさせる。 指摘が細かい好みの話だけになったら、ひとまず完成です。
- ループに気づいたら止まる。 同じ箇所を2回以上行き来したら、修正をやめて不足している前提を聞きます。
- 出てきた問いを自分で調べる。 チームの方針や要件は、AIではなく人やドキュメントに確認します。
- 答えをAIに渡して修正させる。 前提が埋まれば、ループは止まります。
どちらが良いのか
コストだけを見れば、知識先行型が断然有利です。軽微な修正で済み、遠回りもありません。
ただ、オンボーディングの負荷や個人の成長を考えると、AI先行型が合うケースもあります。知識ゼロの状態から、シニアエンジニアの観点を持ったレビュアーを一人手に入れられるからです。新しく入った人が、先輩の手を止めずに「まず一人で形にする」ところまで進められます。
もちろん、AIの観点はあくまで一般論です。現場固有の事情や最終判断の責任までは肩代わりしてくれません。そこを補うのが、ループから見つけた「足りないinput」を自分で埋めていく作業です。
よくある失敗
「シニアエンジニアの観点で」と付けるだけで満足する
観点の言葉は魔法ではありません。何を重視してほしいかを書かないと、当たり障りのない指摘しか返ってきません。
ループに気づかず、延々と修正を続ける
A⇄Bの往復は、何回繰り返しても終わりません。2回行き来したら止まる、と決めておきましょう。
AIのレビューを、チームのルールより優先する
AIの言う「ベストプラクティス」が、チームの規約と食い違うことはよくあります。迷ったらチームのルールが優先です。
1つの会話を長くしすぎる
やりとりが長くなると、AIが序盤の指示を忘れたように振る舞うことがあります。区切りの良いところで、新しい会話に切り替えましょう。
どちらのタイプにも必要なのは「根気」
AIは、想定外の動きをよくします。指示と違うコードを書いたり、頼んでいない部分まで変えたりします。
そこで「AIは使えない」と諦めるか、「どう伝えれば伝わるか」を考え直すか。この差が、使いこなせる人とそうでない人を分けます。うまくいかなかった指示は、自分の言語化のどこが曖昧だったかを教えてくれる材料です。
ただし、根気は同じ会話を延々と続けることではありません。やりとりが長くなって話がこじれたら、ここまでの経緯と決まったことを整理し、新しい会話でやり直す方が早いこともあります。諦めないのは「伝えること」で、「その会話」ではありません。
捨てるべきは知識ではなく「順番」
「AI活用は難しい」とよく言われます。しかしプロンプトの感覚は、触ってみないと身につきません。プロンプトレシピやカスタム指示を選ぶだけでも始められますが、それだけでは応用が効きにくいです。
今求められているのは、言語化と取捨選択のスピードです。手放すべきなのは知識そのものではなく、「全部理解してから手を動かす」という凝り固まった順番なのかもしれません。
この記事は Zenn にも投稿しています。