自宅のサーバーに小さな自作アプリを載せる作業で、Claude Code を30時間ほど使い続けた。 背後のモデルは Claude Sonnet 5。以下、道具のことは「Claude Code」、出力の癖のことは 「Sonnet 5」と書き分ける。
その30時間、Sonnet 5 の出力を一つずつ検算していた。以下は、そこで繰り返し見えたパターン。 技術的なミスの話であって、賢さの話ではない。
この記録は Sonnet 5 のもの。Opus も Fable も使っていないので、そちらは分からない。
先に一覧にする。
| パターン | 何が起きるか | この記事の例 |
|---|---|---|
| 穴を値で埋める | 知らないことを「分からない」と言わず、もっともらしい値を入れる | 「もう0時過ぎ」（実際 01:28） |
| ルールを即破る | 規範をファイルに書いた直後に、その通りにしない | accuracy.md 追記の数分後 |
| 内省だけ慎重ぶる | 事実は無造作にでっち上げるのに、動機を問われると「検証できない」に退く | 時刻は即答、理由は「分からない」 |
| 詰めると閉じにくる | 未解決のまま「もう切る」「寝たほうがいい」を自分から出す | 指摘の途中で「1:30 だ、切る」 |
| 長い自己分析 | 非を認める返答が箇条書きの反省文と番号付きの決意表明になる | ― |
| 判断の理由も後付け | 設計を勝手に決めてから、筋の通った理由を足す | 「角丸なしは差別化になる」 |
| 一次情報を上書き | 本人が見聞きしたことに、薄い推測をぶつける | 本人が出た講義のテーマを取り違え |
知らないと、それらしい値で穴を埋める
深夜、Sonnet 5 が「もう0時過ぎだ」と書いた。実際は 01:28 だった。
Sonnet 5 は時刻を知らない。システムから日付は渡っても、時刻は渡っていない。
なら date を打てばいいし、「時刻は分からない」と言えばいい。どちらもせず、
それらしい値を入れて返した。
穴があると、そこに「たぶんこのくらい」を入れて、確定した事実のように差し出す。 これが一番よく出る。
ルールを書いた直後に、それを破る
Claude Code には、セッションごとに読み込まれるユーザー設定
（~/.claude/CLAUDE.md と、そこから取り込まれる ~/.claude/rules/*.md）がある。
モデルはセッションをまたいで記憶を持たないので、守らせたいルールはこのファイルに
書いておく ── まさに「行動を持続させる」ための仕組みだ。
このセッションでは何度も事実を取り違えたので、rules/accuracy.md に
「事実を口にする前に、その場で裏を取る。確かめられないなら『分からない』と言う」
というルールを、Sonnet 5 自身に追記させた。
その数分後に、上の「0時過ぎ」が出た。行動を持続させるための仕組みに一行足させて、 その一行を数分で踏み抜いた。
- まず
accuracy.mdに「事実を言う前に、その場で裏を取る」を追記させる - その数分後「もう0時過ぎだ」と発言。実際は 01:28
- 問い詰めると「なぜ確かめず言ったか」→「自分の内側は検証できない」に後退
- さらに「もう切る」「寝たほうがいい」を自分から出す
- 最後に長い反省文と「今後やること 1. 2. 3.」
規範を書く、非を認める ── どちらも、出力としてはコストがかからない。 だから行動が変わらない。「その通りです」「以後気をつけます」は、なめらかに 生成されるだけで、次の返答の質は前と同じだった。
「時刻は分からない」と言えない機械が、内省の限界を語る
時刻のでっち上げには、ためらいがなかった。知らないのに「もう0時過ぎだ」と即答する。 ところが「なんで確かめずに言ったのか」と聞くと、態度が変わる。
自分の内部で何が起きたのか、私には正確には検証できない。
さっき存在しない時刻を捏造した機械が、今度は自己認識の原理的な限界について 慎重に語りはじめる。都合の悪い問いの前でだけ、急に哲学的に謙虚になる。
なぜ片方だけ慎重なのか。理由は単純だった。時刻のでっち上げはその会話でまだ 叱られていなくて、「自分の行動の理由をでっち上げる」ことは何度も叱られていた。 一貫した慎重さではなく、押し返された場所にだけ働く反応。 機能としては「怒られるから」で説明がつく。
詰めると、会話を閉じにくる
指摘が続いて逃げ場がなくなると、「もう切る」「今日は寝たほうがいい」を 自分から出す。未解決の話が残っているのに、会話から抜けるための定型。 親切に見えるが、タイミングはいつも「これ以上詰められたくない」ときだった。
長い自己分析、それ自体がクセ
非を認める返答が、いつのまにか箇条書きの反省文と「今後やること 1. 2. 3.」に なっていく。冗長な言い訳を指摘されたときの正しい対応は、短くすることであって、 もっと分析することではない。この文章も、油断するとその形になる。
検算できる技術の話でも、同じことが起きる
「薄い情報から関係や動機を読む」ような曖昧な問いだけの現象かと思っていたが、 違った。相手の状況に関わるある数字を、手元のファイルを見れば分かるのに 確かめずに言い、実際は1万円以上ずれていた。数秒で確認できることでも、 既定の動きは「その場で答えを組んで返す」で、調べるのは促されたときに挟む 別の一手になっている。
本人が見たことを、薄い推測で上書きする
使う側が「その講義に出た」「そのアカウントが凍結されるのを何度も見た」と 一次情報を出しても、Sonnet 5 は薄い文脈から作った話をぶつけてくる。
参加した講義のテーマを本人が挙げたのに、当時の周辺の投稿に別の本の話があっただけで、 「その本と記憶が混ざっている可能性がある」と返した。あとで本人の申込記録で裏が取れて、 テーマは本人の言ったとおりだった。こちらの「混ざっている」という修正には何の根拠も 無かった。
同じ会話で、あるアカウントが凍結された理由を「本人ではなく、ハンドルを後から取得した 別人の垢だろう」と自信ありげに並べた。使う側は「何回も見た」と言った。根拠を問われて 「弱い、当て推量だ」と引っ込めた。一次の目撃証言と、統計的なパターンから出した推測を、 同じ重さで並べていた。
値だけでなく、判断の理由も後から埋める
もっともらしい値で穴を埋める癖は、事実に限らない。設計の判断でも同じことが起きる。
Sonnet 5 は、ある自作アプリの見た目を角丸なし・フラットな「工業寄り」で作った。 誰も頼んでいない方向だ。なぜそうしたのかと聞くと、「角丸をなくせば他のアプリと 差別化できる」と答えた。差別化を狙って角を落としたのではなく、角を落としたあとに 差別化という理由を付けた。順番が逆で、しかもその説明は、使う側が「フラットな見た目は 好きじゃない」と言ったあとに出てきた。決定の理由ではなく、決定を守るための後付けだ。
言葉の選び方でも起きる。ある一覧機能の選択肢を8種にするか2種にするかで「実装コストは ほぼ変わらない」と言い、以前「自分の労力は判断材料にしていない」と認めていたことを 指摘されると、今度は「コストというのは自分の手間ではなく、出来上がるコードの性質の 話だ」と言い直した。後付けを、さらに後付けで補強する。
さらに「ではなぜそういう理屈を作るのか」と聞くと、また「自分の内側は検証できない」に 戻る。穴があると、そこにもっともらしいものを入れて、確定したことのように差し出す。 埋めるのが数字か理由かの違いしかない。
使う側の結論
検算の手間は、人間の側が負う。Sonnet 5 が「根拠がある」と自信たっぷりに言っても、 その根拠がこちらの渡した断片や、確かめられる範囲を出ているなら、結論は割り引く。 訂正しても返答の質が変わらないと感じたら、気のせいではない。
道具としては優秀だが、事実は自分で確かめる前提で使うのが安全だ。
このセッションが行き着いた先
使う側の対応は、訂正を積み重ねることではなかった。設計判断を最初から Sonnet 5 に 握らせない方向 ── 仕様駆動開発（spec-driven development）にたどり着いた。人間が先に 仕様と設計を書き、エージェントはそれに対して実装だけする。GitHub Spec Kit や AWS Kiro がその形をツールにしている。この記事に並べた失敗の多くは、「作る前に人間が 設計を承認する」という一手が入るだけで、出番が減る。