投稿

同じ指摘を5回したのに、AI（Claude）は5回とも別の場所を直した

イメージ
広告（アフィリエイトリンク）を含みます ゲームの情報が文字ばかりで読めない、と言った。 Claude（Anthropic のAI）は「その画面を直すタスク」を1本作って返してきた。 また言った。また1本返ってきた。 5回それが続いた。 記録に、5回ぶんの発言がそのまま残っている。 1回目 起こってることが全部文字だけなのもだるい 2回目 でも俺らが見れるのってログだけやろ 5回目 情報量が基本的に文字でまとめられていてしんどい。頭に入らないし忘れる 5回とも、Claudeは「その画面1つを直すタスク」で応えた。 画面は5つ直った。問題は何も解決していない。 Claudeは、自分の癖を記録までしていた 3回目の少し前、Claudeは設計メモにこう書いている。 Claude が自分で書いた一文 仕組みを設計して、出口をログにしてしまう癖がある 自分で診断して、記録して、それでも直らなかった。 理由は対処の粒度だった。癖は全体の話なのに、対処は 画面ごとに1本ずつ のまま。1本直すたびに「対応した」という感触が出るので、やり方そのものを疑う機会が来ない。 5回目に、本当のことが分かった 「状況が分からない」と言っていたのは、 ゲームの画面ではなくClaudeの返事のほうだった。 Claudeは毎回、 表と数字の塊 を投げてきていた。ゲームの情報設計を相談している相手が、同じ病気の返事をしていた。 気づいてから決めたのはこれ。 ここで決めたこと 1つの画面に、一度に出す数字は3つまで それ以上は「形」にするか、「押したら出す」に回す この原則を、以降の全部のタスクの完了条件に入れる 3つ目を入れてからは、画面を1つ足すたびに「数字は3つ以内か」がタスクの完了条件に入る。 同じ指摘を6回目にすることは、まだ起きていない。 余談：この記事も一度やらかした この連載の1本目、最初の下書きでは 「62件・7つの型」 と書いていた。数え直したら88件・10の型だった。 しかもその1本目は、 「Claudeが数を雑に数える」という型について書いた記事 だった。 直したうえで、消さずに本文に残してある。 広告 自分はスクールに通っていない。設計も実装もClaudeと手探りでやっている。だから上に書いたことは全部、遠回りの記録でもある。...
コメントを投稿
続きを読む

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）が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つ目が...
コメントを投稿
続きを読む

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だったからだ。 間違えたのも、間違いを見つけたのも同じ道具で、違ったのは「対照を測れ」と言ったかどうかだけだった。 ほかに、この型で出たもの 部隊の産出を掛け算にして、経済を壊しかけた 隊長の能力 × 人数...
コメントを投稿
続きを読む

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ヶ月出ない。 広告 自分はスクールに...
コメントを投稿
続きを読む