Claude Code にコードを全部書いてもらって、「ババ抜き AI」を作った話

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

卓上には、ロボットアームと 3 台のカードホルダーが並んでいます。使うのは 7 種類 × 2 枚にジョーカーを足した計 15 枚。来場者 2 人とロボットに 5 枚ずつ配り、ペアを捨てて、順に相手の手札から 1 枚引きます。最後にジョーカーが残った人の負けです。

ロボットの目は、天板の真上に取り付けたカメラです。カードとホルダーに貼った ArUco マーカー (OpenCV で読み取れる白黒の二次元マーカー) を読んで、誰が何枚持っているかを把握します。人間同士の手番のあいだも、カメラは場を追い続けます。

この展示の中心は、カードを引くときの駆け引きです。自分の番が来たロボットは、狙いを決めても、いきなり引き抜きません。カードに触れたまま一度止まり、そのあいだに正面のカメラで相手の顔の特徴点を読み取ります。

あわせて手元の GSR センサー (皮膚の電気抵抗の変化を測るセンサー) で、緊張の揺れも捉えます。ジョーカーに手がかかった瞬間、人はどこかに反応が出るはずだ、という読みです。その読みを、引くカードの選択に使っています。逆に自分がジョーカーを持ったときは、それまでの対戦でよく引かれた位置に差しておきます。

看板で「AI を騙し通せる ?」と銘打ったのは、この仕掛けがあるからです。

卓の後ろのディスプレイには、ロボットが見ている場の状況と、ジョーカーの位置の推定を映しました。

調べてもらったことには、たとえばカードの識別があります。市販のトランプはアームの指ではつかみにくく、裏面を見ても 1 枚 1 枚の区別がつきません。カードを自作することは早くから決めていましたが、何を目印に見分けるかが決まっていませんでした。

Claude Code に調査を頼むと、8 案が返ってきました。裏面にマーカーを貼る、絵柄を機械学習で見分ける、NFC タグを埋め込む。それぞれの案に、読み取りやすさと、準備にかかる日数や費用の比較が付いています。採用しない理由も書くように頼んだのがポイントです。

カードの上端に載せる小さなマーカーは、今回のカメラでは読み取れない。機械学習での絵柄認識は、残りの日数では準備が間に合わない。

消去法まで見えていれば、私たちは選ぶだけで済みます。選んだのは、裏面に ArUco マーカーを置く案でした。

方式が決まれば、あとはマーカーの検出と、カードをホルダーの位置に対応づける処理を実装してもらうだけです。

この「先に調べさせて、決めるのは人間」という頼み方は、次に紹介するアームの動かし方の検討でも、そのまま使うことになります。

アームへの最初の指示は、素直なものでした。「この座標からこの座標へ動かして」。6 つの関節の角度を始点から終点まで線形に補間するコードが、1 分ほどで出てきます。正直、これは楽勝かもしれないと思いました。

ところが、実機で動かすとアームはカードに突っ込みました。コードのバグではありません。手先の位置は 6 つの関節の角度の組み合わせで決まるので、各関節を一定の速さで動かしても、手先はまっすぐには進まないのです。

軌跡は途中で膨らむ曲線になり、その途中でカードの上端に当たる。経由点を増やしても、曲線であることは変わりませんでした。間違っていたのはコードではなく、指示の出し方のほうだったわけです。

そこで、方式ごと変えました。アームを手で持って動かし、その軌道を記録して、本番では再生する。「相手の席に近づく」「カードをつかむ」「自分のホルダーへ運ぶ」という一連の動きを、実際にアームを握って覚えさせました。

カードを差す位置ごとに軌道を録るのは大変なので、席ごとに基準の軌道を 1 本だけ録り、カードの位置に合わせて終点を補正します。出発と帰着は必ず、人間が教えた形をなぞる設計です。

Claude Code には、この記録と再生の仕組みを伝えて、制御コードを書き直してもらいました。最初に紹介した「触れたまま止まって様子をうかがう」動きも、実はこの方式の上に乗っています。接近の軌道を途中まで再生して止まり、相手の反応を見て、つかむか、狙いを変えるか、戻るかを選ぶ。

駆け引きに見えた動きの正体は、録画の再生と、止まった先での三択でした。

役割の線は、来場者のデータを境に引きました。カメラの映像、顔の特徴点、GSR センサーの値は、すべて MacBook の中で処理して外に出しません。クラウドに渡すのは、場の状況を数値やテキストにしたものだけです。

Amazon Bedrock の Claude Haiku 4.5 が返すのは、次の一手そのものではなく、「いまのロボットが何を重視するか」という採点の重みです。MacBook 側はその重みで候補の行動を採点し、次の動きを選びます。天秤に載っているのは、得られる情報と、動作にかかる時間と、そのまま引いてジョーカーをつかんでしまうリスクです。

会場で測った応答時間は中央値で約 3 秒でした。アームの 1 手には数十秒かかるので、進行には十分間に合います。観客向けの実況も同じ応答で受け取り、Amazon Polly で読み上げます。

Amazon DynamoDB に置いたのは、どのスロットからカードが引かれたかのカウンターだけです。ロボットがジョーカーを差す位置は、この記録から決めています。

こうしたインフラは AWS CDK で構築しました。もちろん、この CDK のコードも Claude Code 製です。

開発中の自動テストは、ハードウェアの動作を模したモックで回していました。テストは全部通り、ロジックもひととおり動いて、あとは実機をつなぐだけのはずでした。実際につないでみると、カードとの摩擦や照明の加減など、モックに書かなかった条件で次々に不具合が出ます。しかも、アームを 1 回動かして確かめるのに数十秒かかり、そのあいだは人が横で見ていないといけません。気がつけば、コードを直す時間より、動かして確かめる時間のほうが長くなっていました。

そこで、確かめ方を組み立て直しました。まず部品を一つずつ。アームの姿勢を順に変えてカードに届くか、カメラでマーカーを読み取れるか、Bedrock と DynamoDB に実際につながるかを個別に確認してから、組み合わせます。確認項目は 1 本のシェルスクリプトにまとめ、当日の朝にも一通り回す時間を取りました。センサーが止まっている、本来のモデルの代わりに代替モデルで動いている、といった異常を見つけたら、そこで起動を止める設定も用意しています。

前日の夜、ほぼ徹夜の調整の末に、通しでロボットが動きました。しかし、当日の会場は照明もカメラの設置場所も前日と違い、朝からキャリブレーション (カメラの位置や明るさの基準の取り直し) が必要になりました。それでも開場までに調整を終えて、2 日間、来場者の方と対戦し続けました。

アームがカードに触れたまま止まると、それまで笑っていた来場者の方も勝負の顔になります。表情を読むロボットとの対戦は、会場でちゃんと成立していました。