存在しない機能のテストを、AI（Claude）が4回書いた

広告（アフィリエイトリンク）を含みます

Claude（Anthropic のAI）が書いたタスクの完了条件に、「既存のセーブをロードして、値が一致することを示す」という一文が4回入っていた。

このゲームには、セーブ機能が存在しない。一度も作っていない。

Claudeに実装を任せるとき、タスクを先に文章で書く。やること、完了条件、やらないこと。書くのもClaudeだ。そのタスクの前提のほうが、実物と違っていたという型。12件あった。

一番こたえたのがセーブの件だった。

タスクの完了条件に、4回書かれていた一文既存のセーブをロードして、値が一致することを示す

別々のタスクに4回。Claudeはタスクを書くときに「ゲームなんだからセーブはあるだろう」と埋めた。そして実装のとき初めて「無い」と気づく。4回とも、気づいたのは実装を始めたあとだった。

同じ形のもの

「そのトグルは残す」── トグルは存在しなかったプロジェクト全体を検索して、その単語が出てきたのはタスクの文章そのものだけだった
「施設を壊された状態でクリアする」── 施設が壊れる仕組みが無い完了条件の3つが、同時には物理的に成立しなかった
「支城が生きている間は本城が弱くなる」── その処理はコードに無い設計メモにはそう書いてあった。メモとコードが乖離していた
「いまの地図は位置について嘘をついている」── 実測すると0件ずれていた土地は1つも無かった。名前が重なるのは位置ではなく名前の幅のせいだった

逆向きに動いた回も、記録にある

タスクを書くClaudeと、実装するClaudeは別のセッションで動いている。実装側が、タスクの前提の誤りを止めた記録が2件ある。

タスクどおりに保存すると、6種類のデータが壊れると分かって着手しなかった夜間に無人で走らせていた回。書きかけを元に戻して、止まった。壊れたセーブは1つも作られていない
タスクに列挙の無かった箇所が、同じ形で壊れるのを実装中に見つけた指示には入っていなかった。合わせて直した

なぜ起きるか

Claudeがタスクを書くとき、材料は3つある。コード、設計メモ、そして「普通こうなっているはず」という常識。

前の2つは確かめられる。3つ目は確かめられない。そして3つ目が一番もっともらしい文章になる。

セーブ機能の件がまさにそれで、「ゲームにセーブがある」は世界の常識としては正しい。このゲームに無いだけだ。

ここで決めたこと

タスクの完了条件に出てくる機能は、
書いた時点で1つずつ実物を確かめる。

もっともらしい文ほど、
確かめられていない。

広告

自分はスクールに通っていない。設計も実装もClaudeと手探りでやっている。だから上に書いたことは全部、遠回りの記録でもある。

体系的にやったほうが早いのは間違いない。生成AIを仕事に繋げる講座はいくつかあって、無料のカウンセリングや説明会だけ受けてみるのは悪くないと思う。自分は独学を選んだが、それは性格の問題で、人には勧めない。

このブログで使っている道具（Claude）そのものの入門書も出ている。読んではいないので、中身の評価はしない。

Unityそのものを本で一から学ぶなら、Unity 6に対応した入門書もある。これも読んでいない。

PREV ／ 前の記事AI（Claude）の検算を信じたら、ゲームバランスの案を5つ全部まちがえて却下していた前の記事を読む →
NEXT ／ 次の記事AI（Claude）に作業ファイルを4回消された話と、3段階の対策続きを読む →

コメント

コメントを投稿

このブログの人気の投稿

AI（Claude）に1ヶ月Unityでゲームを作らせて、失敗を88回記録した

イメージ
広告（アフィリエイトリンク）を含みます 木材が、100日たっても1も増えなかった。伐採の行動も、産出の計算も、専用の職業も、全部コードに入っているのに。 個人で作っているUnityのゲームで、設計も実装もClaude（Anthropic のAI）にやらせている。 Claudeが間違えるたびに、日付・Claudeが言ったこと・実際はどうだったかを記録した。 1ヶ月で88件たまった。 AIで開発した成功例は山ほど出回っている。失敗の記録はあまり見ない。だから失敗のほうを書く。 88件を並べ直して分かったことがある。 バラバラの失敗ではなく、10の型に収束する。 この連載は、多い型から順に1本ずつ書いていく。 01 ── あるのに効いてない（15件） 一番多かった型。そして一番たちが悪い。 機能は入っている。動いてもいる。ただ、どこにも繋がっていない。 木材が100日で1も増えなかった 行動の種類も、産出の計算も、専用の職業も、熟練度の分類も全部あった。 無かったのはボタン1個。 画面から選べないので、誰も木を切りに行かなかった 警戒の値が一日も貯まらなかった 昼に加算して、 翌朝に代入で上書きしていた。 「3日後に敵が来る」と分かっていても、前もって備えられない 前線の拠点から任務に出せなかった 必要な関数は2週間前に入っていた。 条件式の1行が、全部を塞いでいた 2日のあいだに、これと同じ形の発見が 5回 出た。5件とも「無いから作る」ではなく「あるのに効いていない」だった。 ここで決めたこと 画面に入口はあるか 出た結果は、目に入るか 途中で潰されていないか 数字をもう1つ置いておく。同じ1ヶ月で、Claudeが完了まで持っていったタスクは 138件 。88件の失敗は、その138件を実際に動かした記録から出ている。 なぜこの型が溜まるのかも分かった。 設計を先に全部書いてからClaudeに実装させると、「仕様としては存在するが、画面に繋がっていないもの」が溜まる。 Claudeは書かれた設計を実装する。書かれていない「繋ぎ」は実装しない。 Claudeにコードを読ませて点検させても、この型は見つからない。Claudeから見れば全部「実装済み」だからだ。 遊べば1日で出る。 コードを読んでも1ヶ月出ない。 広告 自分はスクールに...
続きを読む

AI（Claude）に作業ファイルを4回消された話と、3段階の対策

イメージ
広告（アフィリエイトリンク）を含みます Claude（Anthropic のAI）と長く作業すると、2人で1つのファイルを触ることになる。設計を書くほう、実装するほう。 そのファイルが4回消えた。 起きていたことは単純だった。 Claudeはセッションの最初にファイルを読む。作業する。終わりに書き戻す。 その間に別のセッションが書いた分が、まるごと消える。 一度は、1日前の状態に戻っていた。 37件ぶんの完了記録が消えていた。 気づいたのは翌日だった。 対策が3段階に進化した 第1段階：手続き 「書き込む直前に、必ず読み直す」をファイルの冒頭に書いた。 守られないことがある 第2段階：検知 完了件数を数えて、 減っていたら事故 と判定する。 grep -c 1行で済む 第3段階：構造 1つのファイルを分割して、 そもそも衝突する面積を減らした 効いたのは3段階目だった。手続きは忘れられる。検知は事後。 衝突する場所を無くすのが、唯一の根本対策だった。 落ちがある 第2段階の「検知」が、しばらく機能していなかった。 件数を 2箇所に書いていた。 片方だけ更新が止まっていて、そちらの数字がずっと古いままだった。 巻き戻りを検知するための数字が、 巻き戻りを検知できなくなっていた。 真実の置き場所を1箇所に決め直して解決した。 検知の仕組みにも、同じ「1箇所」の原則が要る。 1箇所に直したあと、検知は1回効いている。書き戻しで 完了数が128から125に減っていた のを数字で捕まえて、消えた2版ぶんの記録を git の履歴から載せ直した。37件消えたときは翌日まで気づかなかった。この回は、数字が減った時点で分かった。 ほかに、この型で出たもの コミットの内容と、メッセージが食い違っていた 書き込みと記録の間のごく短い隙間で、ファイルが古い内容に差し替わっていた。 コミットは成功している のでエラーも出ない 出力フォルダの名前を使い回して、古いソースを書き戻した しかも コンパイルが通ってしまう。 気づいたのは偶然 診断ツール自身が、調べようとしていたクリックを吸っていた 「ボタンが押せない」を調べるために入れたツールが、 そのボタンの上に透明な膜を張っていた 最後の1件は、この連載で一番笑った。 今回の調査で見つか...
続きを読む

AI（Claude）の検算を信じたら、ゲームバランスの案を5つ全部まちがえて却下していた

イメージ
広告（アフィリエイトリンク）を含みます Claude（Anthropic のAI）が引いた線で、新しい能力の案を 5つ全部 却下した。 念のため、すでにゲームに入っている能力どうしを同じ線で測った。 既存の能力も、全部「却下」の側に入った。 この型は15件。一番多い型と同率だった。しかも気づきにくい。 数字が出てきた時点で、検算した気になってしまう。 5つの案を、間違った線で全部却下した ゲームに「能力」が6種類ある。新しい能力を足すとき、既にあるものと中身が被っていないかを確かめたかった。Claudeに測らせた。 Claudeは相関係数を使った。2つの能力の相関が高ければ「同じもの」、低ければ「別物」。線を引いて、 5つの案を全部「被ってるので却下」にした。 Claude が引いた線 相関が 0.45 より下なら別の能力と見なせる 念のため、 既にゲームに入っている能力同士 で同じ測り方をさせた。これが対照になる。 既存の組み合わせの相関は 0.52 だった。却下した案とほぼ同じ数字。 線のほうが間違っていた。 原因もはっきりした。この6能力は全部、同じ素の数値から計算で出している。だから 「全体が高い人は、何もかも高い」ぶんの相関が必ず乗る。 相関では分離できない構造だった。 ここで決めたこと 能力どうしが別物かを測るときは、相関ではなく 「80人から選んだときの顔ぶれの重なり」を使う。 そして、結論を実行する前に書いていた 同じ日の記録にこれがある。 記録に残っている1行 シミュレーションの結論コメントを、実行する前に書いた（3回） 表と食い違う文章を、そのまま出していた。 3回。 Claudeはコードを書く。そして「おそらくこうなるだろう」という解説を、実行結果を見る前に書ける。読む側からは、 どちらが先に書かれたか分からない。 ここで決めたこと 検算の結論は、必ず出力を見てから書く。 それでも検算をClaudeから取り上げはしなかった。0.45の線を崩した0.52という対照の数字を出したのも、Claudeだったからだ。 間違えたのも、間違いを見つけたのも同じ道具で、違ったのは「対照を測れ」と言ったかどうかだけだった。 ほかに、この型で出たもの 部隊の産出を掛け算にして、経済を壊しかけた 隊長の能力 × 人数...
続きを読む