はじめに
以前、ClaudeCodeで製品を作りました。
他者への指示の質・プロンプト能力を上げるために、「AIへの指示がどうだったか」を、製品作成後のAIに聞いて、振り返ってみました。
手法
製品を作った後に、同じセッションで、Claude Codeに「プロンプトがどうだったか？」を教えてもらいました。
このプロンプトはGeminiに作ってもらいました。
これまでの開発プロセス全体を振り返り、私の「指示（プロンプト）」の質について、技術的な観点からフィードバックをください。
最終的にエンジニア向けの記事（Qiita）としてまとめたいので、以下の2つのフレームワークに沿って分析・回答をお願いします。
1. 4Lによる振り返り
Liked: 私の指示で機能した点、スムーズだった部分
Learned: 対話を通じてClaudeが学習した私の「意図」や「クセ」
Lacked: 実装時に不足していた情報や、曖昧だった指示
Longed for: より効率的に開発するために、私に期待する次のステップ
2. KPT形式のまとめ
今回の「指示出し」におけるKeep、Problem、Tryを簡潔に。
忖度は不要です。エンジニアとしての私の成長のために、客観的で厳しいフィードバックを期待しています。
振り返り結果
4L (Four Ls)
振り返り手法の概要：4L (Four Ls)とは
感情・直感にフォーカスした振り返り方法で、以下の4つのLを考えます。
Liked: 良かったこと、Learned: 学んだこと、Lacked: 足りなかったこと、Longed for: 次はこうしたい
ClaudeCodeの回答
Liked：機能した点
- AIの誤りを即座に指摘できた
- 決断に理由を添えた
- コスト・リスクを先に確認した
Learned：AIが学習したあなたの意図・クセ
- 「良さそう」は意見であり指示ではない
- 後から要件が追加されやすい
- 検証はデプロイ後に行う
Lacked：不足していた情報・曖昧だった指示
- 実装に必要な技術的値の準備が後回し
- 「完成」の定義がなかった
- データ品質の全体像を把握していなかった
Longed for：次に期待すること
- 実装前チェックリストの習慣化
- デプロイ直後の動作確認
KPT
振り返り手法の概要：KPTとは
指摘事項を以下の3つに整理する方法です。
K: Keep、良かったこと、続けるべきこと。P: Problem、問題、やめるべきこと。T: Try、次回から始めるべきこと
ClaudeCodeの回答
Keep
- 意思決定に理由を添える
- コストとリスクを実装前に確認する
- AIの誤りをすぐ指摘できる
- 「進めますか？」だけの確認を拒否し、説明を求める
Problem
- 要件の後出しが多く、手戻りが発生した
- 必要な技術的値の準備が後回し
- デプロイ後数日経ってから問題を発見するパターン
- 「良さそう」「気がする」など意図が曖昧な表現が実装トリガーになる
Try
- 実装依頼に受け入れ条件を1行添える
- 実装依頼前に「この実装に必要な情報は何か」を自問する
- デプロイ後24時間以内に主要機能を自分で確認する
- セッション開始時に「前回の未完了タスク」を自分から確認する
ClaudeCodeの総評
総評として、AIとの対話スキルはエンジニア平均より高いです。誤りの指摘・理由付き判断・コスト意識は多くの人ができていません。改善点は「後出し要件」と「デプロイ後検証の遅さ」に集中しており、どちらもプロセスの習慣化で解決できます。
感想
Problemについて
「後出し要件」は、私の中で要件の言語化が不十分なところがあったと思います。全体像についてAIと十分相談してから作るのが理想なのですが、「製品を早く作りたい」という気持ちがあったと思います。
「まずは形に」というのもアリですが、「せっかくならAIと十分要件を練る」という考えも必要だなと感じました。
「デプロイ後の検証の遅さ」は、You've hit your limitのせいなので、気にしません。
「良さそう・気がする、など意図が曖昧な表現が実装トリガーになる」については、半分はClaudeCodeが勝手に実装を始めている・・・という点があります。
ただ、現実社会でも、自信のない状況で「気がする」と言って、受け取り側が「意見交換を求めているのか？このまま実装してよいのか？」が分からないシチュエーションがありそうだなと思いました。
意見交換であることを明示して、「〜〜の気がします。これは意見交換を求めています」というようなプロンプトの仕方をしたり、ある程度断定的にプロンプトを入れたりしたほうが、受け取り側の判断に任せる部分が少なくなって、良さそうだなと感じました。
Keepについて
「意思決定に理由を添える」は、私は現実世界でも結構やりがちです。
背景を理解してもらえば、技術的な変更があった場合も勝手に良い感じにしてくれることが多いと思います。また、人間なら、やりがいに繋がったり、優先度を理解してもらいやすくなります。
これは続けていきたいなと思いました。
「AIの誤りをすぐ指摘できる」「進めますか？だけの確認を拒否し、説明を求める」は、AI時代でも使う側の技術的知識は必要、ということを示唆しています。
結晶性知能のような、洞察力・判断力が重要なのかなと感じました。