AIに指示を出すのが上手い人の共通点

AIコーディング支援を業務で使い始めて半年以上。チーム内でも使う人が増えてきた。観察していると、AIへの指示が上手い人と下手な人で、生産性の差がかなり出ている。

その差がどこから来るのか。自分の経験とチームでの観察をもとに整理してみた。

上手い人は「制約」から伝える

上手い人はまず制約を書く。「TypeScriptで」「既存のAPIの型定義に合わせて」「テストはJestで」みたいな前提条件を最初に並べる。

下手な人は「ログイン機能を作って」だけ投げる。AIは何でもできるから、聞かれたことに答えてくれる。でも前提がないと、プロジェクトに合わない出力が返ってくる。

たとえばこういう違いが出る。

悪い例:

ユーザー一覧のAPIを作って

これだとAIは好きなフレームワーク、好きなDB、好きなレスポンス形式で書いてくる。Express＋MongoDBで返ってきたけど、自分のプロジェクトはFastify＋PostgreSQLだった、みたいなことが起きる。

良い例:

ユーザー一覧のAPIエンドポイントを作成してください。

• フレームワーク: Fastify v4
• DB: PostgreSQL（Prismaを使用）
• レスポンス: { users: User[], total: number } の形式
• ページネーション: cursorベース
• 既存のエンドポイント src/routes/posts.ts のパターンに合わせる

制約を伝えるのは、要件定義と同じ。AIに対しても、人間の後輩に対しても、やることは変わらない。

上手い人は「ゴール」を具体的に書く

「改善して」「きれいにして」は上手くいかない。AIはきれいの基準を持っていない。

上手い人は「この関数のサイクロマティック複雑度を下げて」「エラーハンドリングを追加して、失敗時はnullを返す仕様にして」と書く。何をもって完了とするかが明確。

ゴールが曖昧だと、AIの出力を見て「なんか違う」と思ってやり直す。この往復が無駄。最初にゴールを具体的に書く方が結果的に速い。

実際に自分がやってしまった失敗例を挙げると、「このコンポーネントをリファクタリングして」と投げたことがある。AIは律儀にファイル分割、命名変更、型の厳密化まで一気にやってくれた。でも自分が直してほしかったのはstateの管理だけ。差分が大きすぎてレビューに時間がかかり、本末転倒だった。

「state管理をuseReducerに置き換えて。他の部分は変更しないで」と書けば、欲しい変更だけ返ってくる。

上手い人は「段階的に」進める

一気に大きなタスクを投げるより、小さく分割して順番に進める方が精度が上がる。

「認証機能を全部作って」より、「まずJWTのトークン検証関数を作って」→「次にミドルウェアとして組み込んで」→「エラーハンドリングを追加して」の方が各ステップの品質が高い。

これもエンジニアリングの基本と同じ。大きなPRより小さなPRの方がレビューしやすいのと一緒。

段階的に進めるもう一つのメリットは、途中で方向修正ができること。最初のステップの出力を見て「この設計だとスケールしないな」と気づけば、次のステップで軌道修正できる。一気に全部作らせると、根本の設計が合わなかった場合に全部やり直しになる。

上手い人は「コンテキスト」を共有する

AIは前の会話を覚えているけど、プロジェクトの全体像は知らない。上手い人は関連ファイルや設計方針を一緒に渡す。

「このファイルの設計に合わせて」「既存のエラー処理パターンはこう」みたいなコンテキストがあると、AIの出力が一気にプロジェクトに馴染む。

Claude Codeなら作業ディレクトリのファイルを自動で参照してくれるけど、明示的に「このファイルを参考にして」と指定する方が精度は高い。

コンテキスト共有で特に効果があるのは、以下の3つだと感じている。

1. 既存コードの設計パターン: 「src/services/userService.ts と同じパターンで注文サービスを作って」と言えば、エラー処理の書き方、ログの出し方、戻り値の型まで既存に揃えてくれる。
2. チームのコーディング規約: 「if文の後にはかならず中括弧をつける」「早期リターンを優先する」みたいなルールを最初に伝えると、後から修正する手間が減る。
3. ビジネスロジックの背景: 「この機能は月末にアクセスが集中する」「ユーザーの8割はモバイルからアクセスする」という情報があると、パフォーマンスやUIの判断が変わる。

上手い人は「出力形式」を指定する

意外と見落とされがちだけど、出力形式の指定は効果が大きい。

コードレビューを依頼するとき、「このPRをレビューして」だけだと、長文の散文が返ってくることがある。読みにくいし、指摘の優先度もわからない。

こう書くと出力が安定する。

以下のコード差分をレビューしてください。 出力形式:

• 重大な問題 / 改善提案 / 細かい指摘の3段階で分類
• 各指摘は該当行番号とともに記載
• 修正案があればコードブロックで提示

ドキュメント生成でも同じ。「API仕様書を作って」より「OpenAPI 3.0形式のYAMLで書いて」の方が、そのまま使える出力が返ってくる。

業務での実践: 3つのユースケース

ここまでの原則を踏まえて、自分が日常的にやっている使い方を紹介する。

コードレビューの補助

人間がレビューする前に、AIに一次レビューさせている。特にGo言語のコードだと、エラーハンドリングの漏れやゴルーチンのリーク可能性など、パターン化できるチェックはAIの方が見落としにくい。

ポイントは「何を重点的に見てほしいか」を伝えること。「セキュリティ観点でレビューして」「パフォーマンスのボトルネックを探して」のように観点を絞ると、指摘の質が上がる。

設計の壁打ち

設計に迷ったとき、AIに選択肢を出させるのは有用。「Pub/Subの設計で、Cloud Pub/SubとKafkaのどちらを使うべきか。要件はこう。制約はこう」と投げると、比較表を出してくれる。

ただしここでも、制約を伝えることが重要になる。「すでにCloud Pub/Subの運用実績がある」「チームにKafkaの経験者がいない」という情報があるかどうかで、結論は変わる。AIは情報を与えなければ一般論しか返せない。

ドキュメント生成

障害報告書やポストモーテムのたたき台作成にも使っている。時系列のログとSlackの会話を渡して、「ポストモーテムのフォーマットに沿ってまとめて」と頼む。

ここで出力形式の指定が活きる。チームで使っているテンプレートを渡して「このフォーマットに合わせて」と指定すれば、そのまま使えるドキュメントが出てくる。もちろん事実確認は人間がやるけど、構成を考える時間は省ける。

上手い人は「出力を検証する」

AIの出力を鵜呑みにしない。これが一番の差。

上手い人はAIが出したコードを必ず読む。テストを書いて動かす。「AIが言ったから正しい」とは思わない。検証のコストは払う。

下手な人はコピペして動いたら終わり。最初は動いても、エッジケースで壊れる。AIは「だいたい正しい」コードを出すのが得意だけど、「完璧に正しい」とは限らない。

検証で自分がやっているのは、AIに「このコードのエッジケースを5つ挙げて」と追加で聞くこと。AIは自分が書いたコードの弱点も指摘できる。これで事前にテストケースを洗い出せる。

プロンプトは「仕様書」だと思えばいい

結局、AIへの指示が上手い人は「仕様書を書くのが上手い人」と同じ。制約、ゴール、コンテキスト、出力形式、検証基準。これらを明確にする能力は、AIの時代になっても変わらず求められる。

むしろAIの普及で、この能力の価値は上がっていると思う。AIは実装を高速化してくれるけど、何を作るかを決めるのは人間。その「何を」を言語化する力が、AIを使いこなすための本質。

プロンプトエンジニアリングと言うと特別な技術に聞こえるけど、やっていることは要件定義の基本。エンジニアならすでに持っているスキルを、AIに対しても使えばいいだけの話。

逆に言えば、要件定義が苦手な人はAIへの指示も苦手になる。AIツールの導入をきっかけに「自分の指示の出し方」を見直してみると、人間相手のコミュニケーションも改善するかもしれない。

関連記事

• AI活用で仕事はどう変わったか。Claude CodeとCodexを毎日使った実感
• AIにコードレビューさせたら精度がすごかった
• AIに記事を書かせないために気をつけていること