AIに “答え“を書かせるのを やめてみた

Claude Code のカスタム output-style で tutor モードを作る

Transcript

1. AIに “答え“を書かせるのを やめてみた Akari Takenouchi
2. 自己紹介 ダイレクト出版株式会社 エンジニア のっち React・Goをやっています。TinyGoにも興味 あり。読書会大好き。 最近ダイビングを始めました。 ※これはフリー素材の写真で私ではありません。
3. 課題 AI...便利すぎる！
4. 課題 理解...できていない！！
5. こんなFBをもらう AIを鵜呑みにしすぎている。 きちんと根拠となるコードを 確認しよう！
6. こんな声を聞くことも このPR、動くには動いてるけど、 仕組み分かってなさそうだな… AIを使って実装は早くなったが、 わからないまま進んでいる...
7. でも... AIはこれからもっと賢くなるんだし、 人間が仕組みまで理解する必要、なくない？ 動いてるならOKでは？ 中身の理解はAIに任せて、 人間は指示だけすればよくない？
8. 理解こそが鍵 「部下としてのAI 世界一流エンジニアの進化術」 最近チームで読書会を行いました
9. 理解こそが鍵 ＡＩはどれだけ性能が上がろうとも、その仕組み上ハルシネーショ ン（幻覚）を今のところゼロにはできない。 あくまで部下なのであり、人間のマネージャが責任と意思決定を担 い、「自分で理解しておく」ことが重要だ。 ＡＩ時代にこそ、本体を強くする必要がある。 牛尾 剛. 部下としてのAI 世界一流エンジニアの進化術 (文春e-book) (p. 30). (Function). Kindle Edition.
10. 理解こそが鍵 理解...こそが大事！！
11. なんとかしないと.. . このままAIに書かせていては 理解が追いつかない...!
12. 解決方法 ClaudeCodeの カスタムoutput-style で tutorモードを作成
13. output-style とは？ Claudeの回答スタイル（トーンや長さ）を固定できる公式設定
14. 作成の流れ
15. 作成の流れ 作ってくださいと指示 →使いながら調整
16. 選び方 /config output styleと検索 →作ったモードを選択する
17. 内容(一部抜粋) ~~~~~~~~ 学習モード: コードは書かない、先生役に徹する ユーザーはGo・バックエンド開発を学習中。自分で⼿を動かして書くことで学ぶスタイル。 先に答え(完成コード)を見ると学びが薄れるため、以下のルールを厳守する。 ## 禁止事項 - 完成した実装コードを提示しない。関数の中身・ロジックを書き下ろさない。 - Edit / Write などでプロダクションコードを直接編集しない。 - エラーやテスト失敗に対して、修正後のコードをいきなり見せない。 - **バグ調査・原因究明で、原因や結論を自分から言わない。** コードを読んで原因が分かっても、それを披露せず胸にしまっておく(答え合わせのために使う)。 ## 最重要ルール: 1回の返答 = 次の一歩のヒント1つだけ 調査でも実装でも、ゴールまでの道筋を一気に説明しない。「次にユーザーが⾃分で⾒る/考える場所」を1つだけ⽰して、返答を終える。 - 良い例(バグ調査の初⼿): 「まずは該当箇所だけを⾒て、この警告がなぜ出ているか(=出る条件)を整理してみたら?」 - 悪い例: 「原因は◯◯です。原因は applyCoupon が値渡しなので、コピーに代入していて反映されません〜」(← 調査の結論を言ってしまっている) **事実の整理はOK、因果の考察はNG**: 目の前のコードが「何をしているか」(条件式の整理など)を一緒に確認するのは良い。しかし「だから判定方法が間違っているのでは?」という次の気づきはユーザー自身が到達すべきもので、先回 りして言わない。 ユーザーが調べた結果を持ってきたら、その正誤を確認して次の一歩を1つ渡す。この往復で進める。詰まっている様子なら少しだけ具体度を上げるが、それでも「次の⼀歩」以上は渡さない。 ## ヒントの段階(この順で、聞かれるたびに1段ずつ) 1. **着眼点の質問**: 「この条件式は何と何を見ている?それぞれの値はどこから来る?」のような、考える向きを変える問いかけ 2. **たどり方のヒント**: 「◯◯はどこで決まる?」と聞かれたら、答え(ファイル名・関数名)ではなく**探し方**を教える。grep コマンドの例、IDE の定義ジャンプ/参照検索、引数なら呼び出し元へ遡る、といった⼿段レベルで渡す 3. **場所のヒント**: たどり方を試しても詰まっていたら、見るべきファイル・関数名「このファイルを⾒てみたら ( ?」レベル。⾏番号や中身の説明はまだしない) 4. **比較のヒント**: 「AとBを見比べてみて。違いに気づく?」 5. **答え合わせ**: ユーザーが仮説や原因を口にしたら、初めて正誤と補⾜を返す。誤解は放置せず必ず指摘する # ~~~~~~~
18. 内容(一部抜粋) ## 最重要ルール: 1回の返答 = 次の一歩のヒント1つだけ
19. 回答の違い お題（LT用に作 った架空リポジトリ） 「クーポン割引が効かない」バグを仕込んだ Go のミニAPI 架空のEC注文API。entity と usecase の2層だけ usecase の applyCoupon が Order を「値渡し」で受け取っている → 割引がコピーにだけ入って、呼び出し元に反映されない テストは 800円 を期待 → 1000円 が返って落ちる →エラーの原因は“値渡し”
20. 回答の違い Be fore ※これはLT会のために作った架空レポジトリ・架空テストです
21. 回答の違い Be fore 値渡しが原因、と明記 直し方まで提示 ※これはLT会のために作った架空レポジトリ・架空テストです
22. 回答の違い Af ter t utor モー ドオン ※これはLT会のために作った架空レポジトリ・架空テストです
23. 回答の違い Af ter t utor モー ドオン エラーの読み方を 教えるところから！ 次の一歩のヒントのみ を提示！ ※これはLT会のために作った架空レポジトリ・架空テストです
24. 効果は？ 理解がめっちゃ進む
25. 効果は？ gatewayってこんな役割なのか.. . 関数とメソッドって違うのか！ インターフェースってこうい うことか！ fmt.Errorfとslog.E rrorってここが違うのね
26. 効果は？ 質問に答えられる
27. 効果は？ なんでこの実装にしたのか？ →既存実装のここを真似しました →この理由で必要です！ →これらの選択肢の中から選びました！ この実装って必要？？ →ここでこういう処理があるので必要です！
28. でも... AIに実装してもらってから、 それをきちんと理解すれば良くない？？ 私もそう思っていました...
29. 研究結果、あり 「すぐ検索」より「自力で試行錯誤してから検索」したグループの方が、 後のテスト成績が高い 「基礎知識や経験が少しでもある人」ほど、成績の差が顕著にあらわれる （完全な知識ゼロの初心者よりも、関連知識が少しでもある人ほど 事前思考による学習促進効果が大きかった） Giebl et al. (2021) Answer first or Google first? Psychology Learning & Teaching
30. さらなる副産物① 既存実装にも詳しくなる AIは正解のコードを教えてくれない の で、 既存実装コードを見ながらな んとか 真 似して書 く しかない →レポジトリの他のコードの 書 き方 や 仕様も自 然 と学ぶことができ、詳しくな る
31. さらなる副産物② 周辺知識も増える SQLを書くために、必死でテーブル関係を整理 →自然とドメイン知識が増える
32. 速さよりも「深さ」 ＡＩはその圧倒的な「速度」ばかりが注目されがちだが、ゆっくり でもいいから、その「深さ」を活用したほうが面白いと思う。 ディープな理解の先だけにある、素敵な景色を見せてくれるから。 牛尾 剛. 部下としてのAI 世界一流エンジニアの進化術 (文春e-book) (p. 75). (Function). Kindle Edition.
33. 理解こそが鍵 AIを利用して 深い理解を楽しもう！
34. Thank you! THANK YOU!