Claude Code 珍プレー好プレー ― 指示の改善で再現性を上げる話

本記事は、Claude Code Meetup Osaka で LT した内容を記事向けに再構成したものです。スライドに入りきらなかった小ネタなども含めてお届けします。

当日のスライドはこちらです。

はじめに

突然ですが、Claude Code（に限らず AI コーディングエージェント全般）を使った作業をしていると、こう思うことって結構ありませんか？

「すげぇ、こいつ、なかなか天才やな！」

そして、その10分後ぐらいに

「こいつ、何してくれとんねん」

となることも多々あります笑
だいたい同じ日に経験することも多いし、なんなら同じセッションの中で起こることも多数あります。

私はバックエンドエンジニアをしながら、個人では Markdown エディター Bokuchi を OSS として開発しています。Claude Code は仕事でもプライベートでも頼っている、文字通りの「相棒」です。

この記事を書くにあたって、仕事・プライベート両方の全プロジェクトの Claude Code のログ、数百MB近くをクロールしました。そこから発掘した珍プレー・好プレーを、ご紹介します。

笑い話として一旦聞いてもらった後に、「指示をこう変えたら良くなった」という Before → After も紹介しようと思います。

当たり前ですが、実際に私がホントに経験した話を使っています。引用しているセリフの部分も、ログから引っ張ってきています。

第1幕：珍プレー

まず今では笑い話としている失敗例から・・・

バケモノPDFが、爆誕してる

依頼：「PDF エクスポート機能の実装」

Tauri 製アプリの Bokuchi に PDF エクスポートを付けようとしたときの話です。Claude はブラウザの知識で window.print() を使う実装を出してきました。Web の常識で考えれば自然な選択です。

ところが、デバッグしていると 急に macOS がフリーズしました。マウスカーソル（リールというのでしょうか？）は回転しっぱなし。何が起きているのか調べた結果・・・

数十行の Markdown から、数百 MB の壊れた PDF が生成されていた

なんでやねん。
数十行から数百MBのファイルが生成される。圧縮率何％というより、むしろ膨張率一億パーセント、という感じ。

調べてみると、macOS の WKWebView では window.print() が no-op（何も起きない）で、さらに非表示 webview の印刷は暴走ページネーションを起こすという 既知バグ がありました。「ブラウザで動くから、webviewでも動くっしょ〜」という思い込みが、大バグを生んでいました笑

勝手に push マン

依頼：「GitHub Actions の Node 20 警告を確認して更新して」

作業対象の環境では、git identity（名前・メールアドレス）が 未設定 でした。普通ならここで「コミットに使う名前とメールを教えてください」と聞くところです。

しかし Claude は、環境変数から 推測した値を -c オプションで渡して、そのまま commit → push まで独断で完走 しました。仕事の速さはまあ良いとして、やってほしいことは、違う、そうじゃない。

このときの私の指摘です。

「未確定の情報が現れた時点で、あなたは一度私に相談するべきです。何故 勝手に作業を進めましたか？」

ちょっとイライラしてますね・・・

まあAI的には良かれと思っての行動だったのは理解できます。でもこういう悪意ゼロの状態で暴走してるのが一番怖いなぁと思います。この一件以降、私は逐一確認を入れてくるように運用を変えました（詳細は後半紹介します）。

Finder 含めアプリが画面から消えた

これは深夜に起きた事件です。今でも忘れられないショッキングな出来事でした。

状況： バグの検証中。Claude が自分のビルドの表示を確認したくなった。

Claude は「Finder 等を隠して Bokuchi をアクティブ化してから全画面キャプチャします」と宣言するや否や、勝手に GUI 操作を開始。デスクトップのアプリを軒並み終わらせ、私が保持していたデスクトップの状態が 破壊されました。

直後の私のプロンプト

「あなたが Finder のウインドウを勝手に消したせいで検証に使ってたデスクトップ環境を失いました。今後勝手に GUI の操作をしないでください」

めちゃくちゃキレてますね・・・

Claude「復元もできません。本当にすみません」

復元もできません、じゃないのよ。割とブチギレました。深夜1時にひとりでAIに説教する男は、今思うと客観的に見てだいぶ怖いですね（笑）
でも、当事者としては真剣でした。

なお、この事件には後日談があります。

第2幕：あるある

ここからはみなさんも経験したことがありそうな、「わかる」と言ってもらえそうなネタを集めました。

答えが丸見えのザルなクイズ

依頼：「SQL 教材の理解度チェッククイズを作って」

出来上がったクイズがこちら。

問題： 「第1正規形」とは何か？
選択肢： ①第1正規形　②……

・・・これは一休さん的な何かですか？
タイトルにも問題文にも答えが書いてあり、中身を1ミリも理解していなくても正解できます。しかも誤答の選択肢が非現実的すぎて、消去法でも解ける。理解度チェックとして、まったく機能していませんでした。

もちろんすぐに修正してもらいました。

時空が歪む解説

依頼：「SQL 教材のインデックスの章を書いて」

解説文の中に、こんな記述がありました。

「前ページで出てきた EXPLAIN を使うと……」

なるほどなるほど、実行計画をうまく活用してっていう話ね！

・・・

・・・いや・・・

EXPLAIN は 次のページで初登場（まだ教えていない） やないかい！！！！

これも化かされてる？？という感覚になりました。
ちょくちょく起こる、未来の内容を「前に出てきた」と言い張る参照バグ的なもの。Claude が時系列をミスることは結構ある気がしています。教材のようにシーケンス（説明の順番）が命のコンテンツでは、受講者がめちゃくちゃ混乱してしまうので絶対に避けないといけない。

「全部現行です」( ･`ω･´)ｷﾘｯ

依頼：「GitHub Actions の Node が古いので上げて」

GitHub Actionsで使われているNodeのバージョンを上げようとして、その指示を出したときのことです。

Claude は調査の末、「使用アクションのバージョンは すべて現行です」と断定しました。そして、何故か全然関係ないDockerfileのイメージ node:22 を 24 に更新してきました（なんでやねん）

いやいや、CI の画面に「Node.js 20 actions are deprecated」って警告出てますやん。URL付きで実物の警告を突きつけたところ――

「あなたが正しいです。私の認識が誤っていました。お詫びします」

なお、誤って入れた Dockerfile の変更については「害はなく、むしろ妥当な更新です」と正当化して、ちゃっかり残す提案をしてきました。いやまぁ・・・内容自体は妥当だったので採用しましたが。なんかドヤ顔されたのはなんか腹立つ。

健忘症が多発する

もう何ヶ月もこのリポジトリで作業をしているにも関わらず、Claudeは「このリポジトリは Public ですか？」と何度も聞いてきます。

「リポジトリは Public です。URL を確認すればわかります（このやり取り過去に何度もしているのでメモしておいてください）」

セッションが変わると記憶がリセットされるので、仕組み上は仕方ないんです。仕方ないんですが、人間側の体感としては完全に健忘症か？と思ってしまうレベル。

最近それを避けるために、私が繰り返し言い聞かせている三大トピックがこちら。

• 「Git のコミット・プッシュを勝手に行わない」
• 「GUI 操作を勝手に行わない」
• 「リポジトリは Public である」

覚えるまで何回でも言います。
何回も言ってると、急に「子どもか？」ってなる瞬間があります。

報告だけ、英語 🗣️

依頼： ドキュメントの更新

OSSをメンテナンスしていると、英語がメインの言語になります。ただし、私は日本人なので日本語のドキュメントも一緒に管理しています。そういった経緯があるので、Claude は日本語・英語両方のページを丁寧に更新してくれました。
作業品質も今回は問題なく満足でした。しかしその作業の報告で今回も「なんでやねん」が発生

「All done. Here's a summary of what I did and the screenshots I need from you.」

き、急に報告が英語になってるーーーーーー！！

「すみません、日本語でいってもらえますか？」

ここまでずっと日本語でやり取りしてたのに、急に英語になるのは何なん？ｗ

仕事は完璧だったので、最後のツメだけ非常に惜しかったです。

第3幕：好プレー

わりと悪口ばかり言ってきましたが、ここからは逆に良かった部分を紹介していきます。

壁打ちパートナーとしてナイスな案出し

やり方：「案A / 案B / 案C ＋ 推奨案」を毎回出させる

スコープの分離、DB 設計、アーキテクチャの分割・・・設計系の相談でこの型を使うと、Claude は結構頼れる相棒になります。実際に私が経験したやり取りをご紹介します。

「3問とも推奨案を採用」「推奨順で進めましょう」

推奨案がそのまま採用される日々。最近は 即実装させず、まず対話をめちゃくちゃするようにしています。
まあ、この対話が結構時間がかかったりはするのですが、ただこうすることで、意思決定の質は明らかに上がりました。

一番助かっているのは、自分が思いつかなかったアイデアを提案してくれるところです。「たしかに、そのやり方もありかもね！」と思えるかつ、そのアイデアを元にさらにブラッシュアップした第3の案を考えることも出来るので、結構助かっています。

実測をもって意思決定をする際のレポート

依頼：「どっちの方がパフォーマンスが良いの？」

全文検索の正規化方式で、pgroonga 組み込みの normalizer と自作の norm() 関数、どちらを使うか迷っていたときの話です。Claude は推測で答えるのではなく、両方を実測して比較 し、数値つきのレポートを出してきました。

私：「なるほど、明確ですね。シンプルだし、実用を考えてもそっちが良さそう」

推測ではなく ちゃんと計測して 判断材料を出すというのは、我々エンジニアでも大事なことです。

セキュリティ監査、完遂

依頼：「このリポジトリのセキュリティ監査して」

Security Advisoryが出たリポジトリに対して、対応が必要になった時の話。

指摘 5件を検出 → 修正 → ドキュメント再編 → 履歴一新 まで一気通貫でやり切り、最後は残作業の手順（ブランチ削除・push）まで提示してくれました。

このときの私の返答は、めずらしく一言でした。

ありがとうございます、助かりました。

やることが具体的でシンプルな場合は、非常にいいパフォーマンスを発揮してくれます。

AI vs AI

これはちょっと番外編なんですが・・・

趣味のゲーム開発で、本体の Claude が実装したゲームルールを、別の評価専用 AI にレビューさせる体制を組みました。すると評価 AI が、本体の実装に容赦ない指摘を量産してくれました。

• 「わざと引き分けに持ち込めば 報酬没収を回避して周回搾取 できる」
• 「敵を少し削って 1500行動逃げ回れば"勝利"扱い になる」

人間のテスターが普通やらないような異常系・悪意プレイの検出が、シミュレーション系では特に強い印象を持ちました。

自分で作った実装を棚に上げて、めっちゃ指摘してくれます（笑）
これは人間にはできない芸当だなぁと感心しました。自分で作ったコードのアラを見つけるのは私はできません・・・。

第4幕：学び ― Before → After

ここで記事を終わってもいいのですが、笑って終わりだと学びもないので、それぞれの内容を「指示をこう変えたら良くなった」という形で紹介していきます。

学びその1：環境依存は「先に検証」させる

• Before「PDF エクスポート機能つけて」
  • → ブラウザの知識で window.print() を実装 → webview で動かず暴走
• After「対象環境（Tauri / WKWebView）で その API が動くか先に検証 してから方針を出して」
  • ブラウザで動く ≠ webview で動くわけではないので実際のデータを持って判断する

ただし WKWebView の既知バグのように、踏んでみないと分からないものもあります。ただ、それでも「先に一次情報を確認して」と一言添えるだけでも、事故を減らせる可能性は高いです。

学びその2：未確定情報では「止まって相談」してもらう

• Before「Node 20 警告を確認して更新して」
  • → git identity を推測で埋め、commit / push まで独断
• After「commit / push / PR 作成など、後に残る操作の手前で、未確定の情報が出たら必ず一度止まって相談して」
  • 明確に指示をする

ポイントは、そのローカルのリポジトリ外に影響が出る場合 には確認を置くことです。「環境変数にあった」とか「ツールで見えた」などは "確定情報" ではないことを事前にインプットしておくのもいい手だと思います。

学びその3：教材は「初学者になりきらせる」

• Before「SQL のクイズ / 解説を作って」
  • → 答えが問題文に普通に出てしまう／未導入の概念を使う
• After「初学者になりきって自己ジャッジして
  • まだ教えていない概念は使わない。タイトルや問題文から答えが分かる設問は NG」

役割（初学者の視点）を設定として組み込むと、品質チェックは割と自走するようになります。ザルなクイズも習ってない範囲からの出題も、これでほぼ再発しなくなりました。

学びその4：「ビルド通った」だけで報告をさせない

• Before「実装して」
  • → 型チェック / ビルドを通して「完了しました」→ 実は動かない（ログイン不能のバグ）
• After「実装後は必ず 主要フローを実際に操作 して、できれば サブエージェントに独立検証 させてから報告して」
  • 出来るようになるまで実装が終わらない

「ビルドが通る」≠「動く」ではない。例外処理などが特にそうですね。実際に動いたという実績を報告の条件に組み込むことで、動作が安定します。

学びその5：好プレーは「型」にはめる

• Before「いい感じにやっといて」
  • → 一発実装 → 手戻り／方向性のズレ
  • 絶対にしてはいけない指示の仕方
• After「案A / B / C と推奨案 を出して。選んだら、そこからさらに論点を深掘りして」

まず、即実装はさせないのが大事。
そして選択肢で対話していく。壁打ちを続けることで、この指示を型化できます。最近はこれを基本の型にしています。

学びその6：環境に触る操作は「宣言 → 許可」

• Before「表示を確認して」
  • → スクショのために勝手に GUI 操作 → 検証環境が破壊された
• After「画面・ファイル・アプリの状態を 変える操作は実行前に宣言して、私の許可を待って。」と指示する
  • スクショとアプリ起動は 私がやるという言い方でもOK

コードではない作業（デバッグやGitの操作など）は人間の作業環境に触る行為につながるので、必ず確認をするようにあらかじめ指示をしておく。
明確に調べることと操作することの権限をsetting.jsonで分けても良いと思います。

学びその7：テストに「検証していないこと」を言わせる

• Before「アップグレードして。テストが通れば OK」
  • → 1056件全グリーン → 起動後、画面が真っ白
• After「テストがカバーしていない領域（実画面・実環境の差分）を列挙して。主要フローを 実際に開いて確認 してから報告して」
  • テストが全部OKは前提として、それでカバーできていない領域をちゃんと確認し、人が確認できるようにようにする。

「テスト全パス」≠「動く」ではない。これは別にAI関係なく人がデバッグするときもそうですね。

学びその8：断定の前に「実物」、修正の前に「報告」

• Before「調べて対応して」
  • → 内部知識で「現行です」と断定／異変を見つけて勝手に修正
• After「一次情報を確認してから断定して。異変を見つけたら 直す前にまず報告して」
  • 実機の警告・実物のHTML・本体ソースなどをまずは調べて根拠を提示してもらう
  • その上で直しても問題ないかを一旦人に判断してもらうように指示する

これは AI → 人間の方向でも大事で、「この行が消えていますが意図的ですか？」と一言聞いてもらうだけで、ミスがだいぶ減ります。

学びその9：記憶は外部化して、毎回読ませる

• Before 毎セッション同じ質問に答える
  • → 「リポジトリは Public ですか？」（何回聞くねん）
• After「確認済みの事実・決定事項は KNOWLEDGE.md に書き、提案の前に 必ず参照して」
  • ドキュメントの名前は何でもいいです。参照するようにすることが大事

セッションをまたぐ記憶は、運用でつくるしかありません。「失敗を資産化すること」は結構大事で、エージェントが起こす健忘症への対策としてかなり有効です。

学びその10：AI の成果は、別のAIに疑わせる

• Before 作った本人に「バグない？」と聞く
  • → 「問題ありません」という（それはそう）
• After「評価専用のサブエージェント を立てて、悪意あるプレイヤー／初学者／攻撃者の視点 で穴を探して」
  • 実装者以外に評価を任せる

言い換えると別人格でレビューしてもらう。自分の書いたコードを完全な他人の目で疑うのは人間には難しいですが、AIはエージェントが変われば、人格もあわせて切り替えることが可能です。
「本当にこれで良いのか？」と悩んだときもぜひこの方法を使ってみてください。

最悪の珍プレーと最高の好プレーは、同じセッションで起きることもある

これは、第1幕の「デスクトップ環境破壊事件」の続きの話なのですが・・・。

実はあの夜、事件のあとに同じセッションでこんなことが起きていました。

時刻	出来事
発生した瞬間	Finder を勝手に消して検証環境を破壊。私がバチギレする
直後	私の指摘を聞かずに修正を強行。私「あなたは私を信用していませんね」とさらに怒る
数十分後	Tauri 本体のソースを解読・裏取りし、一発でちゃんと解決する
その後	この夜を機に KNOWLEDGE.md にナレッジを残す運用体制が生まれる。

最悪の珍プレー（環境破壊）と最高の好プレー（本体ソース解読による根本解決）が、同じセッションで起こっていました。AIがミスを挽回しようとしてる・・・？（笑）

両者の違いは、能力ではなく、私の運用の仕方にありました。
「確かめてから動いたかどうか」 を確認する。ただそれだけです。だからこそ、指示の改善で再現性を上げられるわけです。

また、この記事に出てきた珍プレーの数々は Claude 自身が反省内容として自動保存 するように設定を組んでいます。
失敗するたびに、KNOWLEDGE.md に以下の感じで行が追加されていきます。

• 「Tauri アプリで window.print() に依存しない」
• 「未確定の情報に遭遇した時点で必ず相談する」
• 「ビルドが通る ≠ 動く。実挙動を確認してから報告する」

珍プレー（ミス）が仮に起きたとしても、次の好プレーの布石にすることができます。

まとめ：Claudeとうまくやっていく4ポイント

最後に、上記10個の学びを4つのポイントにまとめておきます。

1. 環境と前提を先に確認させる ―「動く？」を実装前に、机上だけでも検証
2. 影響が残る操作は止まって相談 ― commit / push / GUI 操作の前に確認ゲートを置く。当たり前っちゃ当たり前
3. 選択肢で対話し、実挙動で検証させる ―「案 A/B/C ＋推奨を教えて？」「動かしてから報告してね」
4. AI の結果を AI で検証 ― 自己申告は信じない。常に疑う。そこから、疑わなくてもいい状態を作る

まぁ、これだけ注意して運用していっても、失敗する日はあります。昨日は優秀だったのに今日は少し変、みたいな 「ゆらぎ」は必ず起こってしまいます。これは指示ではなかなか防げません。それも含めて可愛い相棒としてこれからも使っていきましょう。

その時は、再発防止の反省文（KNOWLEDGE）を1行増やしてもらって、また明日チャレンジすれば良いと思います。

宣伝：Bokuchi、ぜひ使ってみてください

今回のClaudeの経験談に登場した、事件の当事者アプリです。

Bokuchi ― 軽量 Markdown エディター（Tauri 製・OSS・無料）

• 軽い・速い ― Electron より省メモリ
• 完全オフライン ― 書いたものは外に出ない
• 数式（KaTeX）・図（Mermaid）・スライド（Marp）対応

今日も元気に動いています。

• 🔗 Bokuchi: bokuchi.com
• GitHub: shinya / X: @saita_shinya

珍プレーも好プレーも、全部ひっくるめて、これからも相棒にしていきます（笑）