AIの試行錯誤を、
みんなで持ち寄る場所。

使いやすい空き家探しサイトがなかったのでAIでマシなのが作れるか試してみた

@masayo

何を作ったか 日本語で空き家情報を一括で検索できるWebアプリ（関西エリアのみ） なぜ作ったか 人口減少や高齢化の問題によって、日本には約900万戸もの空き家があると言われています。相続したもののすでに別の場所で暮らしていてその家に住む予定がなかったり、長年手付かずのままで老朽化した家は修復に多額の費用がかかることもあり、税金を払い続けるよりも手放したほうが経済的、というのが大きな理由です。そういった背景があり、無料または非常に安い価格で売り出されている空き家が日本各地で増えています。 ここ数年日本への移住に興味を持つ外国人の間でも空き家が注目されるようになっており、私の相棒もその一人です。現在、空き家の情報は2つの不動産サイト、各自治体のサイト、そして紙媒体などに分散しており、物件を探すのは意外と面倒です。外国人向けにAkiyaMartのような英語で情報を提供しているサイトもありますが、「下水」のような重要な情報が省略されていて、結局リンク先の元の掲載サイトで確認しなければならないことも多々あります。 プロジェクトのゴール 今回もGemini Antigravityを使って作ってみました。MVPは関西の4県のみ。大きな目的は２つ。 - 物件情報はあちこちに分散されているので表示内容やラベル名がバラバラ。これを統一して表示することができるか - 町名の情報と物件の写真をGoolge Mapsのストリートビューの画像と照合して物件の住所を特定できるか 問題点と、その回避方法など スクショからすぐにピンとくるかもしれないですが、レイアウト等のデザインは某民泊プラットフォームのパクリ、ロゴは某アニメのタイトルデザインのパクリです。「具体的な例を出した時にAIはどれくらい忠実に真似できるか」というのを試してみました。結論から言うと、「かなり細かいところまで真似できる」です。 サイトのLook and Feel / Visual Design まず最初のプロンプトで、サイトの意図と見た目の詳細な指示（「AirBnBのホームページみたいな感じで」）というのを出したらかなり想像に近いものが出来てきました。こういう感じにしたい、という具体的なイメージがもしすでにあるのであれば、スクショを貼るのはすごく効果的だと思います。以下がAIが最初に生成したページです： 想像に近かったとはいえ、修正依頼はいくつか出しました。AIで生成されるデザインにはいくつか特徴があり、この「AIのクセ」のようなものを理解したうえで、デフォルトのUIでOKか修正させるかを判断するのをおすすめします。 - とりあえずアイコン好き。隙あればあちこちに入れてくる。 - とりあえず#タグも好き。本当に必要かどうかは構築者が判断しましょう。 - Dividerも好き。必要以上にDividerを入れると画面がごちゃごちゃします。 - 情報をContainer/Boxに入れて整理しようとする。これも逆に情報の関連性がわかりづらくなることがあります。 - サイトタイトルの前にアイコン、下にタグラインを入れる。タイトル名はたまに重複して表示。必要に応じて修正しましょう。 以下が修正後のホームページです： サイトのロゴ サイト名がまだ決まってなかったので、AntigravityとChatGPT両方でいくつかのアイデアを試しました。最終的には「空き家さがそ！」に決まりましたが、ChatGPTの方が若干元ネタのロゴに忠実なように感じました。ただ、AntigravityでもChatGPTでも、細かい修正依頼、例えば「花と葉っぱのイラストだけとって」とかは苦手で、依頼を無視して全く別のバージョンを作ってきます。結局は以下のような作業法が一番効率が良かったです。 1. 「これのココとココを修正すれば使える」という段階までたどり着いたら画像をダウンロード 2. そのファイルをイラレで開く 3. 画像をトレースしてVectorに変換 4. 手動で細かい修正をいれる 現在プロダクトデザインの現場はFigmaのいわゆる無双状態ですが、今後AIでのデザインがさらに普及すれば、もしかしたらまたアドビの時代が来るかもしれないですね。 プロジェクトのゴールの結果 プロジェクト開始前のゴールだった、「#1 物件情報を統一して表示することができるか」と「#2 物件の住所を特定できるか」について、結論は以下になりました： - #1 はできるけどかなり手動の作業が必要になるんで面倒 - #2 はAIでも無理 物件情報を統一して表示することができるか たとえば指示が、 であれば、「建物面積」の情報はもってこれるのに、なぜか「建物構造」はうちのサイトでは「記載なし」になっている場合が多い。元サイトには両方のラベル（まんま同じ）があるのでもってこれないはずはないのに？？ちなみに物件の画像でも同じ問題がありました。スポットチェックでこういう問題を見つけたら指摘し、修正する、の繰り返しにかなりの時間を費やしました。でも400件以上の物件のチェックをいちいちできないので、結果的には「情報は間違っている可能性がある」というあまり理想的ではない結論に至りました。 物件の住所を特定できるか 結論からいうと、AIが自信満々だった割には「できなかった」。リンクされたGoogleマップに一応位置情報ピンが立っているが、その町／村の真ん中あたりに適当にピンを立てただけだと思われる。もう少し調査する必要あり。 作ったことで得られたインサイトなど サイトが不安定 前回の高校のリサーチサイトと違って、今回は400件以上のデータを扱うためかエラーが多く、１つのエラーを修正させたら他の無関係な５つの箇所が壊れる、という状況に数回陥りQAにかなりの時間を要してしまった。 データの信憑性 なぜAkiyaMartのような英語サイトが、元サイトに掲載されている物件についての全ての情報を表示できないのか理解しました。不可能に近いからです。全く同じラベル名でも探知できず見過ごすのに、ラベルが少しでも違えば（例：築年数 vs 建築時期）うちのサイトでは「記載なし」になります。ならばユーザには元サイトへ行ってもらって確認してもらうのが一番安全です。 データ構築、管理 前回作った高校リサーチのサイトでも同じことを思いましたが、プロのエンジニアのヘルプなしでは複雑なサイトを安定して稼働させるのは難しいです。デザイナーの私には裏でどうやって情報が構築、処理されているかがわからないので、エラーになった場合の根本の原因がわからずAIにどう修復すべきかの指示がだせないため、エラー修復にかなりの時間（token）を費やしました。例えばデプロイした後、ページが空白だということが何回かあったので、相棒（エンジニア）に原因を調べてもらったら、「Local DB File」「画像がキャッシュされてない」などいくつか指摘されました。 最後に感想 デザイナーがAIを駆使して、見た目がよく使いやすいプロダクトを構築することは可能です。ただ、安定性やパフォーマンスにも配慮しながらプロダクトを運営していくには、やはりエンジニアの力が不可欠です。AIの導入によって開発・プロダクトチームの作業効率が格段に上がったとはいえ、デザイナーとエンジニアが一緒にプロダクトを作っていくスタイルは、まだまだこれからも健在のようです。

息子の高校のリサーチにまたSpreadsheetを作るのが面倒だったのでウェブアプリを作った

@masayo

何を作ったか サンフランシスコ市内の高校をリサーチするための保護者用のツール なぜ作ったか うちには来年高校に進学する息子がいます。過去2回、小学校、中学校と学校が変わる度に学校リサーチのための情報（学校の基本情報、テストスコア、家からの距離、運転に要する時間、学校見学日、申し込み締め切り日、メモ等）をspreadsheetにいちいち細かく入力していました。しかし３回目ともなるといい加減この動作が面倒になってきたので、今回はvibe codingを試してみることにしました。Gemini Antigravityを使い、制作にかかった期間は2日程度でした。 このウェブアプリでできること - SF市内の全ての高校の情報がみれる - 学校のタイプ（public, private, charter, religious）や家からの距離でフィルタできる - 授業料、生徒数、SATスコア等でソートできる - 地図上で学校の位置が確認できる - 自分の「My List」が作れる - 学校をside by sideで比較できる 作ったことで得られたインサイトなど 本職はプロダクトデザイナーなので私の意見はデザイナーよりの意見になります。 とりあえず早い アイコンを右に5ピクセル動かすためだけにいちいちプロンプ​​トを入力するのは少々面倒に感じましたが、AIを使うことで得られるメリットはそんな面倒さをはるかに上回るものでした。まるでどんなに面倒臭い要求にも文句を言わず根気強くかつ意欲的に応えてくれるデベロッパーと一緒に仕事をしているような感覚でした。そして仕事が無茶苦茶早い。知り合いのデベロッパーの方が「一度AIを使って仕事したらもう前みたいにコード書くのには戻れない」と言ってたのを、一瞬で理解しました。 生成されたデフォルトのUIはイマイチ Geminiが最初に生成したページは、そのままでも使えないことはないけどなんか使いづらい、というよく見る「AIが生成しました」という製品そのものでした。なので、「これをいかに使いやすいものにするか」というゴールに作業のほとんどの時間を費やしました。ユーザは自分なのでこの作業はとても楽しかったです。 デザイナーの役目 今後AIを使って構築された製品がどんどん増えていった場合、他のAI製品との差別化が重要な課題になってくると思います。同じ目的のための製品が２つあるとして、もし機能や値段等のもろもろの条件が同じだったらどちらの製品を選びますか？恐らく「使い勝手」がかなり重要なんじゃないでしょうか？使い勝手が悪い製品は、ストレスに感じるだけでなく、余計な時間を費やしてしまい、生産性にも影響します。でもチーム内にデザイナーが一人でもいれば、その製品が「いかにもAIで生成しました」とみえてしまうのを防ぐだけでなく、実際に製品を使うユーザの視点に立ち、使い勝手の良い、直感的な製品をつくるヘルプになります。 以下がUX改良後のページです。 デザイナーも開発チームの一員 今までの「デザイナーはUXチーム、デベロッパーは開発チームに属す」というチーム構成でなく、デザイナーもデベロッパーと同様に同じチームでAIで製品を構築するようになるかもしれません。 【従来】デザイナーがmockupをFigmaで作成 → デベロッパーがFigmaのDev modeをもとにコードを書く 【今後】デベロッパーがAIで製品を構築 → デザイナーがUI/UXをAIに改善させる そして、コードレビューと同じような、UI/UXやアクセスビリティからの観点を重視したデザインレビューはどのプロジェクトにも必須になるかもしれません。 最後に デザインと開発の境界がこれまで以上に近づいている中で、製品が本当にユーザーにとって使いやすいものになっているかを判断するには、デザイナーの視点が欠かせないことを改めて実感しました。

ブログの将棋AIが弱すぎたので、AIエージェント群に1日で作り直させた話 — バグ調査からWASM・NNUE蒸留まで

Yudai Yaguchi

> 個人サイト（meetyudai.com）に置いていた自作将棋AIが、将棋二段の自分から見て「弱すぎる」状態だった。Claude Code のサブエージェントを最大5体、並行で走らせて、丸1日でどこまで強くできるかを試した記録。うまくいった施策だけでなく、A/Bテストで容赦なく棄却された失敗施策も全部残す。原因調査の生ログ、失敗のカタログ、実測値、そして「近似指標をいくら磨いても対局では勝てない」という、何度も足をすくわれた教訓まで。費用はほぼゼロ（電気代とLLMの利用料のみ）。これはその全体像で、生ログとコードは完全版（ブログ）にある。 この記事の要点（先に3行） - 「意味不明な手」の最大の原因は、探索エンジンでも評価関数でもなく、その手前で定跡フォールバックが探索をバイパスして即答していた配線ミスだった。思考時間ログが決定的証拠になった。 - 手書きエンジンの小改良は、本番相当の持ち時間で測ると8〜9割が「効果なし」。効いたのは構造改革——TypeScript→WebAssembly移植（探索15倍）と、その上に載せたNNUE蒸留。 - 系譜は 勝率19.6% → 32.1% → 77.1%（対・手書き評価）。最後は本番で作者が負けてsigmoid飽和という病を発見し、データの作り直しで根治。最終的に作者が実戦で「確実に強くなった」と確認。 何を作ったか 作ったのは、サーバーもGPUも使わず、ブラウザの中（WebAssembly）だけで完結する将棋AIだ。バックエンドは一切ない。ページを開くと、評価関数の重み（約1.1MBの静的ファイル）を非同期で取りに行き、あとはあなたのブラウザのCPUだけで数手先を読んで指す。スマホのブラウザでも動く。 中身は二本柱でできている。 1つめは探索エンジン——「数手先を読む」部分だ。将棋は1手ごとに合法手が平均80〜100手以上あり、それを何手も掛け合わせると組合せは天文学的になる。全部は読めないので、明らかにダメな枝を早めに切り落としながら読む。使っている技法は、ネガマックス＋αβ枝刈り（相手が最善で応じる前提で、見込みのない枝を打ち切る）、PVS（主要変化探索）、置換表（一度読んだ局面の結果を再利用するキャッシュ）、LMR（後回しの手ほど浅く読む）、ヌルムーブ／futility 枝刈り、静止探索（駒の取り合いが落ち着くまで読み延ばす）、そして詰みを専門に探す詰みソルバー。要は「賢く手を抜いて深く読む」ための道具箱だ。 2つめは評価関数——読みの末端で「この局面はどっちがどれだけ有利か」を1つの数値にする"目"だ。探索がいくら深くても、末端の局面を正しく採点できなければ意味がない。最初は人間がルールで書いた評価だったが、最終的にこれをNNUE（ニューラルネット評価）に置き換えた。ここが記事の山場になる。 「ブラウザだけで動く」という制約は地味に効いている。学習にはGPUを使うが、動かす側（推論）はCPUだけ。しかも他人のスマホで数百msの持ち時間、という厳しい条件で強さを出す必要がある。この制約が、後半のあらゆる判断（モデルを小さく保つ、量子化する、SIMDで速くする）を縛ってくる。 何故作ったか 将棋二段の自分から見て、サイトに置いていたAIが率直に「弱すぎた」。症状は2つあった。 ひとつは、アマの基本戦法「原始棒銀」に、毎回同じようにはまって負けること。棒銀は▲2六歩→2五歩→3八銀→2七銀→2六銀→1五銀…と銀をまっすぐ繰り出して端を破る、入門書の最初に載る攻めだ。これに毎回沈むのは、対策以前に読みが破綻している証拠だった。 もうひとつは、ときどき完全に意味不明な手を指すこと。自陣に無意味な歩を打つ、玉を自分から危険に晒す。人間なら絶対に指さない手だ。 放置しているのが気持ち悪かった、というのが直接の動機。だがもう一つ、試したいことがあった——AIエージェントを並行で走らせて、ソフトウェアを1日でどこまで作り直せるか、という実験だ。将棋AIはその題材として理想的だった。理由は明快で、正解が存在する（やねうら王という、アマトップを遥かに超える強豪エンジンがある）し、強さを数値で直接測れる。だから「なんとなく良くなった気がする」という自己欺瞞に逃げられない。測れば白黒つく。 どう回したか：AIエージェントの運用 技術詳細に入る前に、進め方そのものを書いておく。ここが半分の見どころだからだ。 最大5体のサブエージェントを並行で走らせた。 担当は「探索の高速化」「評価関数の学習」「定跡の整備」「コードの堅牢化（レビュー対応）」「記事執筆」のように分けた。私自身は統合役に徹し、各エージェントが上げてくる結果を読んで、次に何を試すかを決める。人間がボトルネックにならないよう、独立に進められるタスクは独立に投げる。 問題は、5体が同じリポジトリを同時に編集すると壊れることだ。これは各エージェントを別々の git worktree で作業させることで解いた。worktree は同じリポジトリの作業コピーを複数持てる仕組みで、エージェントAが探索コードを書き換えている隣で、エージェントBが学習スクリプトを触っても、互いのファイルを踏まない。安いコストで分離でき、マージ地獄も起きない。 そして、これが一番大事なのだが、すべての「振る舞いが変わる変更」にA/Bテストを義務づけた。「強くなった気がする」は一切信じない。各変更は、本番相当の持ち時間で旧版とN局対戦し、勝率で本当に上回った時だけ採用する。この規律のおかげで、試した改良の8〜9割は棄却された。これは失敗ではなく、むしろこのプロジェクトの本質だ。もっともらしいアイデアの大半は、実測すると効かない。それを機械的にふるい落とせる仕組みを最初に作ったことが、一番効いた。 もう一つの必須ゲートがビット完全一致だ。後半でエンジンを WebAssembly に移植するのだが、その際「速くなったが、指す手が微妙に変わった」を絶対に許さなかった。移植版が、手書きTypeScript版と同じ手・同じ評価値・同じ探索ノード数・同じ葉ノード数を返すことを、数千局面での照合と、合法手の全数え上げ（perft）で確認する。perftは初期局面から深さ3で25,440手、持ち駒を打てる局面でも既知の数字と一致することを見る。100%一致した版だけを本番に載せた。速度は別物、指し手は同一——これで「高速化がバグを紛れ込ませる」事故を封じた。 フェーズ1：まず「弱い」を再現して、真犯人を特定する 弱いAIを前にすると、つい「評価関数が悪いんだろう」と当たりをつけて直したくなる。だがそれは推測だ。まず物証を取ることにした。 負ける将棋——棒銀に沈む手順——を、固定した棋譜として再現できるスクリプトにした。そのスクリプトが、本番とまったく同じAI呼び出し経路に1手ずつ局面を渡し、返ってきた手・評価値・駒割・思考にかかった時間をログする。 ここで決定的な証拠が出た。AIが1手を1〜23ミリ秒で返していた。 数手先をまともに読めば、数百ミリ秒から数秒はかかる。1〜23msという即答は、「実は読んでいない」ことを意味する。 追いかけると、真相はこうだった。定跡ブックのフォールバック機構が、探索エンジンを丸ごとバイパスしていたのだ。本来この機構は「定跡に載っている局面なら、記録された手を即返す」ためのもの。ところがバグで、定跡を外れた局面でも「それっぽい手」を探索抜きで返してしまっていた。つまり終盤の勝負どころでも、AIは一切読まずに、雰囲気で手を選んでいた。これが「意味不明な手」の正体だった。 ここが最大の発見だ。弱さの原因は、評価関数でも探索アルゴリズムでもなく、その2つの手前にある配線ミスだった。どんなに評価や探索を磨いても、そもそも探索が呼ばれていなければ全部素通りする。この機構を撤去しただけで、即答ナンセンスの一群が根絶された。 教訓は明確だ。症状（悪い手）から原因（評価が悪い）を推測すると、たいてい外す。ログという物証で殴れ。 思考時間という、一見どうでもいい数字が、決め手になった。 フェーズ2：探索を作り直す（小細工はほぼ効かず、構造改革だけが効いた） 即答バグを潰したら、次はまともに読ませた上で強くしたい。まず探索そのものに手を入れた。 試したのは教科書的な小技だ。枝刈りをもう一段追加する、手の並べ替え（良さそうな手から先に読むと枝刈りが効く）を改良する、詰み探索を延長する、各種マージン定数を調整する……。どれも理屈の上では「読みが深くなる」「無駄が減る」はずのものだった。 ところが、本番相当の持ち時間で厳密にA/Bを取ると、その大半が「効果なし」だった。深くなるはずの改良が、勝率をまったく動かさない。これは後で効いてくる伏線でもある——深く読んでも、着いた先の局面を評価関数が正しく裁けなければ、深さは勝ちに変換されないのだ。 効いたのは、小技ではなく土台の載せ替えだった。手書きの TypeScript エンジンを、WebAssembly（WASM）に移植したのだ。WASMは、ブラウザ上でネイティブに近い速度で動く低水準の実行形式で、JavaScriptよりずっと速く数値計算を回せる。同じアルゴリズムを WASM に移しただけで： - 探索が 約15倍高速化 - 同じ持ち時間で読める深さが +3〜4手深くなった - 旧エンジンとの直接対決で 10戦全勝 将棋で「+3〜4手深く読める」は、実力にして段位が変わるレベルの差だ。アルゴリズムは1文字も賢くしていない。実行環境を変えただけ。「賢さ」より先に「速さ」がボトルネックだったという、身も蓋もないが重要な教訓だった。 フェーズ3：評価関数を「蒸留」する（NNUE） 探索が速く深くなったので、次はいよいよ末端の"目"、評価関数を強くする番だ。 それまでの評価関数は手書きだった。駒の価値（歩は100点、飛車は約1000点…）に、玉の堅さ、駒の働き、といった項目を人間がルールで足し算する方式。読みやすく、そこそこ働くが、人間が思いつく項目の範囲という天井がある。微妙な形の良し悪しは、ルールでは書ききれない。 そこで機械学習に置き換える。使った手法が蒸留（distillation）だ。考え方はこうだ。 1. 強豪エンジンやねうら王に、何百万もの局面を「この局面は何点」と固定深さで採点させる。これが教師データになる。やねうら王は強いが重い——ブラウザでは動かせない。だが「答え合わせをしてくれる先生」としては最高だ。 2. その採点を、小さなニューラルネットに真似させる。ネットは意図的に極小に設計した。ざっくり 2,268個の盤面特徴 → 256 → 32 → 1 という構造で、途中の活性化はクリップ付きReLU（大きくなりすぎる値を頭打ちにする単純な非線形）、パラメータ総数は約59万個。小さいのは、ブラウザのCPUで一瞬に評価を出す必要があるからだ。この方式がNNUEで、面白いことにもともと将棋のために発明された（後にチェスのStockfishが輸入した）。NNUEの強みは、盤面が1手で少ししか変わらないとき、評価を差分だけ更新して高速に計算できる点にある（この保持役を「アキュムレータ」と呼ぶ）。 3. 学習後の重みを16bit整数に量子化（細かい小数を整数に丸める）して約1.1MBに圧縮し、ブラウザに静的配信する。 学習の目標値は にした。エンジンの評価値（センチポーン＝歩1/100単位のcp）を、sigmoidという関数で0〜1の「勝率っぽい値」に潰したものだ。この分母の 600 を覚えておいてほしい。終盤でこの設計が牙をむく。 データ：3サイクルの実測値 NNUEは一発では決まらなかった。3周してようやく形になった。それぞれが独立した小さな物語なので、順に。 第1サイクル——大敗（19.6%）。 最初に学習したNNUEを、手書き評価と等時間で自己対戦させると、わずか19.6%しか勝てなかった。ボロ負けだ。ところが調べると、推論の実装は完全に正しい——学習フレームワーク、TypeScript、WASM の3者で、数百局面の評価がビット単位まで一致し、等時間でのノード数も同等（差分更新も完璧に機能）。実装は正しく、負けたのはモデルそのものだった。 敗因の分析が、この記事で一番大事な学びにつながる。当時、モデルの良し悪しを「教師（やねうら王）の採点にどれだけ近いか」で測っていた。手書き評価の2〜2.5倍も教師に近い——だから強いはずだ、と。ところがこの指標は、対局の強さの予測子として不適切だった。理由はこうだ。αβ探索で効くのは、評価の絶対値ではなく、兄弟手同士の相対的な順位だ。「この手とあの手、どっちが上か」さえ合っていれば探索は正しく働く。NNUEの平均誤差は、典型的な候補手同士の評価差（100cp未満）より大きく、その順位を壊していた。一方、手書き評価は絶対スケールがズレていても自己一貫しているので、一様なズレは探索に無害だった。「教師に近いが順位はガタガタ」より「教師から遠いが順位は保つ」方が、探索では強い。これは最後まで効いてくる教訓になった。 第2サイクル——逆転（77.1%）。 敗因が「順位を保つには誤差が大きすぎる＝データ不足」だと踏んで、教師データを大幅に増やして学習し直した。すると勝率が 19.6% → 32.1% → 77.1% と伸び、手書き評価を明確に上回った。データを増やすだけで、大敗が快勝に反転した。あわせてポンダリング（相手が考えている時間にも、こちらは読み続ける「常時思考」）を本番投入し、平均到達深さを 9.00 → 9.35 に底上げした。ここで初めて本番投入にこぎつけた。 第3サイクル——速度、そして敗北からの根治。 勝てるようになったので、今度は速くする。WASMのSIMD命令（1命令で複数の数値をまとめて計算する）で評価を6.2倍高速化し、さらにマルチスレッド化（Lazy SMP 型の並列探索）も入れた（推定+58 Elo。ただしn=24で統計的有意には届かず、正直に「点推定」と記録した）。ここまでは順調だった。ところが——本番の最高難度で、作者（二段）がそのNNUEに負けた。せっかく強くしたはずが、実戦で足元をすくわれた。そして診断の結果、真犯人が判明する。 一番の敵：sigmoid飽和 思い出してほしい。学習の目標値は だった。この設計に、終盤で牙をむく落とし穴があった。 sigmoidは、入力が大きくなると出力が1に、小さくなると0に、両端で平らに張り付く関数だ。勝勢や敗勢の局面ではセンチポーンが巨大になる（例：+3000cp）。すると はほぼ1.0に振り切れる。問題は、そこから少し評価が動いても——+3000でも+3500でも——出力がほとんど変わらないことだ。つまり、本当は価値が違うはずの手が、全部ほぼ同じ数値に潰れて見える。 実際、診断で見つけた問題局面では、合法71手すべてが15cp幅の中に潰れていた。AIから見れば「どの手も同じ」。だから、勝ちが見えている（あるいは負けが込んでいる）局面で、AIはほぼ乱択でナンセンスな手を選んでいた。作者が負けた将棋の「意味不明な手」は、これが原因だった。皮肉なことに、深く読めるようにしたことが、むしろ飽和域の局面に到達しやすくして、症状を悪化させていた。 修正は、探索ではなくデータの作り方にあった。それまでの学習データは、決着がついた局面（大差の局面）を「退屈だから」と薄く間引いていた。まさにその薄い領域で飽和が起きていた。そこで、決着局面を意図的に多めに——全体の約半分まで——混ぜて、524万局面（採点は深さ12）で学習し直した。飽和域をたっぷり学ばせて、大差の中の微差を見分けられるようにする狙いだ。結果： - 問題局面での手の価値の散らばりが 20cp → 532cp（26倍） に回復。「どれも同じ」が「ちゃんと差がある」に戻った - その局面の悪手が 8個 → 4個 に半減 - 旧NNUEに 92.2%、手書き評価に 84.4% で勝ち越し（1000ms・2000msの両方で） - そして最終的に、作者本人が実戦で「確実に強くなった」と確認した 近似指標ではなく、作者が実際に指して認めた——これが唯一信じられる合格判定だった。 分かったこと（失敗も全部残す） 正直なところ、この1日の一番の収穫は、成功よりも失敗の記録だった。 近似指標が良くても、対局で勝つとは限らない。 「教師への近さ」を2倍に上げても、実戦は強くならなかった。最後の審判はいつも同じで、「実際に対局して勝つか」だ。それも、できれば自分が実際に指す戦型を使う人間相手に。ベンチの数字は、あくまで途中の目安でしかない。 検証そのものが罠だらけ。 セルフプレイの統計的縮退（自己対戦は、同じ癖同士だと勝敗が偏って見える）、時間設定のバイアス（測る持ち時間で結論が変わる）、旧版と新版でデフォルト設定がズレていた事故——どれも「強くなった」と誤解しかけた。何度も間違った結論を掴みかけた。防御は一つだけ、本番相当の条件で測ること。 効かなかった施策のカタログ。 理屈で良さそうでも実測で死んだものを、供養として並べておく。KP特徴量（玉と駒の関係を細かく入れる強力な手法だが、100万局面ではデータ希釈で悪化した）、王手延長（A/Bで負け）、ドロップ手のLMP枝刈り（同）、詰みソルバーの深化（変化なし）。そして極めつけが本格ビットボードだ。盤面を整数のビット列として持ち、ビット演算で一括処理するこの技法は、やねうら王のようなネイティブ強豪の高速化の要だ。真似ようとしたが——32bit止まりのJavaScriptでは、81マスが1つの整数に収まらない。飛び駒の利きを求める処理がワードをまたいで面倒になり、飛び駒リスト方式の試作は、JITが既に十分最適化している配列のレイ走査より約2倍遅かった。理屈で速くても、この土俵では逆に遅くなる。ネイティブC++とは、本当に土俵が違うのだと思い知った。 これからどう強くするか 正直に書くと、ブラウザという土俵には天井がある。探索側は、この環境では実用上やり切った。SIMDもマルチスレッドもビット一致の高速化も入れ切って、これ以上「深さが跳ねる」大ジャンプは構造的に難しい。 ここからさらに強くするなら、レバーは評価（データ）側だ。有力なのは自己対戦データループ——今の強いエンジンに自分自身と対戦させて、「実際に強い将棋で出る局面」を集め、それをやねうら王で採点し直して再学習する、という正のループ。ただし採点者はやねうら王のままなので、天井はやねうら王の判断力で頭打ちになる（真の自己強化＝勝敗そのものから学ぶAlphaZero式ではない）。もう一つは、作者が指して見つけた具体的な弱点を、狙い撃ちで潰すこと。飽和の発見がまさにそれで、実戦の1局が、どんな近似指標より鋭く急所を教えてくれた。 コストとまとめ かかった費用は電気代とLLMの利用料だけ、時間は実質1日。「弱すぎる」から「作者が確実に強くなったと認める」まで、AIエージェントの並行運用と、A/B・ビット一致という地味な検証規律で到達した。 振り返ると、これは「1つの賢い発見」の物語ではない。むしろ逆で、測って、失敗を捨てて、生き残ったものだけ残す——その退屈な反復こそが効いた、という話だ。派手なアイデアの8〜9割は死に、残った少数（WASM移植、データを増やす、飽和を潰す）が全部を持っていった。強くするより、弱くする変更を確実に弾く方が、ずっと大事だった。 完全版（生ログ・コード・全数値） 上は全部ダイジェストだ。バグ調査の生ログ、失敗施策の一つひとつの詳細、各サイクルの実測グラフ、コードの中身まで、すべてブログに書いてある。機械学習が初めての人向けに、NNUE・蒸留・誤差逆伝播・量子化をゼロから説明した入門記事も別に用意した。 👉 完全版： https://www.meetyudai.com/blog/applied-algorithms/9fpLthtYgHvnImuFR0Jf 👉 入門編（ML初心者向け）： https://www.meetyudai.com/blog/applied-algorithms/H9beqVVY7h5qc3hNfskR

JTPA Community Hub: AI勉強会の運営を支えるコミュニティサイト

Yudai Yaguchi

なぜ作ったか ベイエリアAI勉強会/JTPAの活動では、イベント告知、RSVP、登壇者情報、発表資料、参加者チェックイン、プロジェクト共有、記事、Q&Aなどがそれぞれ別の場所に分散しがちでした。運営側はイベントごとに参加者管理や発表資料の整理が必要で、参加者側も「次のイベントはどこか」「登壇資料はどこにあるか」「他の人がどんなAIプロジェクトを作っているか」を追いにくい状態になりやすい。 そこで、AI勉強会の活動を一つの場所に集約するコミュニティサイトを作りました。いま見ているこの「みんなのプロジェクト」機能も、このプロジェクトの一部です。 何を作ったか JTPA / ベイエリアAI勉強会向けのコミュニティ運営プラットフォームです。 主な機能は以下です。 - イベント一覧、イベント詳細、RSVP、ウェイトリスト - 登壇者登録、発表タイトル/概要の登録、スライドや動画リンクの共有 - QRコードによる当日チェックイン - AIプロジェクトのShowcase投稿、管理者レビュー、コメント、いいね - メンバーブログ、Q&A、メモ/ノウハウ、コミュニティ投票 - Googleログイン、公開プロフィール、マイページ - 管理画面でのイベント作成、投稿承認、参加者CSV出力、権限管理 - 日本語/英語の多言語対応 単なる告知サイトではなく、勉強会の運営と参加者同士の継続的な交流を支えるための実用アプリとして作っています。 仕組み フロントエンドは Next.js 16 App Router + React 19、ホスティングは Firebase App Hosting です。データは Firestore、認証は Firebase Auth の Google OAuth、画像や発表資料は Firebase Storage を使っています。 設計上のポイントは、Firestoreの読み書きを基本的にサーバー側へ寄せたことです。Server Components が表示用データを読み、Server Actions が投稿、RSVP、承認、コメント、いいねなどの更新処理を担当します。ブラウザから直接Firestoreを書き換える構成にせず、認可は / / のようなサーバー側ヘルパーに集約しました。 一方で、画像やスライドなどの大きなファイルはブラウザからFirebase Storageへ直接アップロードします。アップロード後にServer ActionでメタデータだけをFirestoreへ保存する構成にして、Cloud Run側で重いファイル転送を受けないようにしています。 AIをどう使って作ったか 実装の大部分は Codex や Claude Code と対話しながら進めました。AIに「全部作って」と丸投げするのではなく、機能ごとに小さく分解し、既存コード、制約、期待する挙動、テスト方法を毎回渡す形にしました。 たとえば、次のような流れです。 1. 人間が「イベントRSVPにウェイトリストを入れたい」「QRチェックインを作りたい」「Showcase投稿に承認フローを入れたい」といった運用上の要件を決める 2. AIに既存のデータモデル、Server Action、Firestore rules、UIコンポーネントを読ませる 3. AIに実装方針を出させ、認可、データ整合性、エラー時の挙動を確認する 4. 小さな単位で実装させる 5. 、 、 、Firestore/Storage rulesテストで壊れていないか確認する 6. レビューコメントやCIの失敗をAIに渡して修正する 特に効果が大きかったのは、Firestoreのデータモデル、Server Actions、管理画面、Markdown投稿フォーム、i18n文言、テスト、READMEや運用ドキュメントの整備です。AIは既存パターンに合わせた実装を高速に出せるので、同じ設計でイベント、プロジェクト、記事、Q&A、投票などの機能を横展開しやすくなりました。 逆に、人間側で強く管理する必要があったのは、セキュリティ、権限設計、運営フロー、ユーザー体験、Next.js 16の新しい仕様への追従です。AIが出したコードをそのまま信じるのではなく、「誰がこの操作をできるべきか」「失敗した時にデータが壊れないか」「承認前の投稿が公開されないか」を重点的に見ました。 難しかったポイント 一番難しかったのは、コミュニティサイトとして自然に見えるUIと、運営ツールとして必要な厳密さを両立することです。参加者向けにはシンプルに見せつつ、裏側ではRSVP数、ウェイトリスト、登壇者数、出席数、承認状態、投稿者権限、ファイル所有者などを正しく扱う必要があります。 QRチェックインも、単にQRを表示するだけではなく、イベント開始前後の有効期限、ログイン後のリダイレクト、同じ人の二重チェックイン、管理者による手動修正、累計参加回数の更新まで考える必要がありました。 また、Next.js 16は従来のNext.jsと違う点が多かったので、AIに任せる前にプロジェクト内のドキュメントや実際のAPIを読ませることが重要でした。 作ってみて得られた学び AIコーディングで大事なのは、プロンプトを長くすることよりも、良い制約を渡すことだと感じました。「このファイルを読んで」「この既存パターンに合わせて」「このテストを通して」「この権限境界を壊さないで」と指定すると、AIはかなり実務的な開発パートナーになります。 一方で、プロダクトの目的や運営上の判断はAIだけでは決まりません。どの投稿を承認制にするか、Q&Aは即時公開にするか、イベント参加者に何を入力してもらうか、といった判断はコミュニティの文脈を知っている人間が決める必要があります。 今後やりたいこと 今後は、投稿やQ&AのAI要約、イベント後の自動レポート、参加者向けのおすすめ記事/プロジェクト表示、運営向けのダッシュボード分析などを追加したいです。コミュニティ内に蓄積されるプロジェクト、記事、質問、イベント資料をAIで再利用しやすくして、勉強会の知識がイベント当日だけで終わらない形にしていきたいです。 詳しいプロジェクト紹介 このプロジェクトは、自分のポートフォリオでも英語のケーススタディとしてまとめています。プロダクトの目的、担当範囲、主な機能、技術構成、AIを使った開発プロセス、難しかった点などを、より職務経歴・プロジェクト紹介寄りの形で整理しています。 English case study: JTPA Community Hub Project Description

manabiQ: 社内のマニュアルやSOPを、AIでスマホ対応の短時間トレーニングに変換する新人教育・オンボーディング支援サービスを、バイブコーディングで作りました。

@kazuookumura

何故作ったか AIシステム開発のビズデブ（事業開発）活動をしている中で、私を含め多くの人が、もともとの基礎知識が無いために案件化しない、ということが頻発していました。そこで当初は、AIに関する基礎知識講座を作るつもりでした。 しかし、お客様のお話を聞いているうちに、特に流通・小売の領域では、AI以前の問題として従業員の入れ替わりが激しく、同じ研修を高頻度でやり直していることを知りました。しかもベテランを現場から外して新人に教えるので、教える側のコストも大きい。「すでに手元にあるマニュアルを、初出勤前にスマホで終わる研修に変えられないか」——その繰り返し作業を肩代わりしたくて作りました。 何を作ったか ・PDF・Word・テキスト、Google Drive・OneDrive の資料をアップロードすると、AI がクイズ付きの5〜15分のコースを自動生成する SaaS です。 ・受講者はマジックリンクを開くだけ（アプリ不要）でスマホ受講でき、日本語・英語・スペイン語をワンクリックで切り替え。管理者はクイズの結果で「誰が現場に出る準備ができたか」を把握できます。 工夫したところ ・Gemini呼び出しが混雑で失敗しても少し間隔を空けて自動で再試行する仕組みを入れ、生成が途中で止まらないようにしています。 ・言語を TypeScript に統一: フロントもバックエンドも同じ TypeScript（Node）で書けるので、言語を行き来せずに済み、少人数でも開発が速い。 ・AI生成しっぱなしでは大きな誤りが出てしまうので、「元資料との整合性チェック＋人の承認(HITL)」をセットにしてみました。 ・コスト最適化: 通常は軽くて速い Gemini Flash を使い、簡単な処理では Gemini の「思考モード」をOFFにしてトークン（＝コスト）を節約するようにしました。 ・セキュリティ：全API を「認証→レート制限→入力検証→処理→ログ無害化」という同じ順序にしたことで、漏れが減り、あとの管理がラクになった気がします。 仕組み モデル: Google Vertex AI / Gemini 2.5 Flash 生成パイプライン（Agentic）: 資料抽出 → コース構成 → 各モジュール本文 → クイズを段階生成 整合性チェック（Fidelity Check）: 生成結果を元資料と突き合わせ、捏造（ハルシネーション）や抜け漏れを検出 Human-in-the-Loop: 公開前に人が確認・編集・承認 多言語対応：英、日、スペイン語 Text-to-Speech 読み上げ サポートチャットにも AI（RAG） を活用 技術スタック Next.js 16 / React 19 / TypeScript、Firebase Auth・Firestore 決済 Stripe インフラ Google Cloud Run / Cloud Build / Artifact Registry（Docker, node:20-alpine） です。 今後やりたいこと ・SMS対応（今はいちいちメールソフトを開けてリンクをクリックしないといけないのでめんどくさい。） ・Gusto、BambooHR、日本だとsmartHR、freeeなどの中小企業向けの人事・労務プラットフォームと連携し、新入社員を登録した瞬間にオンボーディング研修が自動で始まる流れを作っていきたい。

株取引で予想が当たるYoutuberを見つける [株取引自動化 Part2]

@jin

Market Sentiment Explorer (2) 何故作ったか 株式市場について様々なYoutubeチャンネルが存在しているが、予想が当たるYoutuberを見つけたかった 何を作ったか 毎日指定した Youtube Channelを巡回し最新のtranscriptを取得し、Claude Codeに内容を分析させ、市場の今後のセンチメントを数値として把握できるようにする。次に実際の各セクターのその後の値動きを数値化し、両者の相関を計算することで予想の当たりやすさを数値化する。 仕組み Youtube Channelを巡回しtranscriptを取得します。こちらは別記事で詳細を解説しています。 フローチャートは下記のようになっています。この右側部分が本プロジェクトでの解説記事になります。 Claude CodeとChat GPTに手動で対話せさながらS&P500の各ティッカーをどれかのセクターに振り分ける まず、S&P500の各ティッカーシンボルとその該当セクター分けのリストを作ります。リストはClaude CodeとChat GPTでそれぞれに作らせ、2つのリストをそれぞれのエージェントに渡して検討させながら最終的に一つのリストを作成します。 基準日からの値動き率 (セクタームーブメント)を計算する Yahoo Financeで毎日のティッカーシンボルの終値を取得し、各セクターごとに各ティッカーの時価総額を用いて加重平均し、各セクターのインデクス価格を計算します。さらにはある日から2週間の各日の終値を加重平均し、基準日からその後どれだけ株価が動いていたかをセクタームーブメント指数として計算しておきます。 (ドットマーカー付きのグラフがセンチメント、実線だけのグラフがその後２週間のムーブメント) Youtuberの予想センチメントと、その後の値動きの相関を計算する その後、現在ある45日分のデータセットを使って各セクターごとにあるyoutuberが予想や所感を述べた場合に -100 100までのセンチメントが計算され、それに対して後日の値動き（ムーブメント指数）との相関を計算します。 どうやって作ったか、難しかったポイントなど 基本的に全てClaude CodeあるいはCodexに頼んでコードを書いてもらっています。 GUIはPythonでそのままコードが書けるようにStreamlitを使いました。 （これは後に後に分析されたセンチメントと実際の値動きの相関を分析するためにpythonのライブラリを使いたかったため） コツとしては、アルゴリズムを全てパラメーター化することでパラメータ探索を行い、データが溜まってきたところで随時アルゴリズムの最適化を行えるようになっています。 システム維持費用が高い Claude Code ($20/mo) システム開発、Daily Report 作成 Codex ($20/mo) システム開発、各video transcript/tweetからのセンチメント／リスク算出 Twitter API ($60/mo) Tweet 取得 (1日250件程度) 計 $100/mo 作ったことで得られたインサイトなど それなりに自分が感じていた所感と同じような結論が数値で得られた (このyoutuberは当たらないと感じていたら負の相関が示された) ただし、一部直感に異なる数値が得られているところもある 計算されたセンチメントを使って今後の株価変動を予想する場合、各セクター平均での結果の相関係数が 0.4だった。思ったよりも良い結果 予想の当たるYoutuberに高い荷重をかけてそれで予想システムの精度が上がるか検証したが、平均的な精度としては上がらなかった。 （予想が当たらないYoutuberでもオーバーフィッティングを妨げる効果がある？） 45日分程度のデータではまだまだ信頼度が低い 今後やりたいことなどがあれば とりあえずのシステムは完成したのでまずはよりデータを集めることに専念して、データが集まったところでセンチメントの予想アルゴリズムをエージェントに自動で修正させてるようにしたいです。 数千の人格がその状況でどう動くかをマルチエージェントを使ってシミュレーションする技術があるのでそれと繋げてみたいですね。 https://github.com/666ghj/MiroFish

ベイエリアAI勉強会　第4回： AIに「質問する」から「仕事を任せる」へ。AIエージェント入門

ChatGPTやClaudeに一つずつ質問するだけでなく、目的を伝えることで、必要な手順を考え、外部ツールと連携しながら作業を進める「AIエージェント」が広がっています。 第4回では、AIエージェントを実際の仕事につなげるための仕組みや、試して分かった小さな工夫を紹介します。 発表・デモ予定 当日は、次のような内容を扱う予定です。 - AIエージェントの基本的な仕組み - GmailやGoogle Driveなど、外部サービスとの連携例 - AIエージェントにツールを接続する方法 - 作業ログや途中経過を記録し、エージェントが参照できるようにする工夫 - 複数ステップの作業やブラウザ操作を任せる際のポイント - 業務フローをAIエージェントに組み込む考え方 - 実際に試して分かったこと、うまくいかなかったこと、まだ難しいこと 準備状況に応じて、Webサイトや簡単な業務ツールの制作、n8nなどを使ったワークフロー自動化についても紹介します。 完成された事例だけでなく、現在試している構成やセットアップ時につまずいたポイントも共有しながら、AIエージェントを実務で使うための現実的な方法を一緒に考えます。 ※発表内容や使用ツールは、準備状況や各サービスの提供状況により変更する場合があります。 こんな方におすすめです - AIエージェントを仕事で使ってみたい - GmailやGoogle DriveなどをAIと連携させたい - AIに複数ステップの作業を任せる方法を知りたい - エージェントを試したが、セットアップや運用でつまずいた - 自分の事例や実験結果を共有したい - AIに関する質問や相談をほかの参加者としてみたい エンジニアに限らず、プロダクト、デザイン、オペレーションなど、AIを仕事や日常の作業に取り入れたい方の参加を歓迎します。 当日の流れ（予定） 17:30〜 開場 18:00〜 オープニング 18:10〜 メイン発表・デモ 19:15〜 事例共有・質問・交流タイム 20:00 終了 後半は、今回のテーマに限らず、参加者がAIに関する事例、実験結果、困っていることなどを自由に共有・質問できる時間にする予定です。 - 途中参加・途中退出自由 - 短い発表やデモを希望する方は、申込時のアンケートよりお知らせください - 見学や質問のみの参加も歓迎します 開催概要 - 日程： 2026年8月28日（金） - 時間： 17:30〜20:00 - 参加費： 無料 - 場所： Niterra North America, Inc. 3979 Freedom Cir #400 Santa Clara, CA 95054 Mission Towers 2・4階 駐車場 会場ビル西側の立体駐車場をご利用いただけます。 駐車場は午後7時に自動的に閉まり、それ以降は入庫できません。午後7時以降にお越しの方は、ビル前の1時間パーキングまたは周辺の路上駐車をご利用ください。 出庫時は、南側の出入り口が内側から自動で開きます。当日も改めてご案内します。 飲食・持ち物 スナックや飲み物の持参を歓迎します。 ※アルコールはご遠慮ください。 特定のソフトやブラウザ拡張機能を事前にインストールする必要はありません。デモでは、運営側で用意した環境やサンプルデータを使用します。 コミュニティサイト 勉強会専用プラットフォームを試験運用しています。プロジェクト紹介、質問、Tipsなどの投稿をお待ちしています。 Bay Area AI コミュニティサイト 本勉強会は、ベイエリアの日本語話者エンジニア・技術者コミュニティを支援するNPO、JTPAにもサポートいただいています。 - JTPA公式サイト - JTPA Facebookグループ 写真撮影について 当日は、開催レポートや今後のイベント告知のため、写真撮影を行う場合があります。 写真は個人が特定されない形で利用する予定です。掲載を希望されない方は、当日スタッフまでお知らせください。 皆さまのご参加をお待ちしています！

ベイエリアAI勉強会 第3回 開催レポート

2026年7月17日（金）、「ベイエリアAI勉強会 第3回：AIツールを使ってみる実践ライブデモ」を開催しました。今回はAIにコーディングをさせて何かを作る内容ではなく、さまざまなAIツールやAIエージェントの活用方法を紹介する勉強会となりました。 今回も多くの質問が寄せられ、終了時間いっぱいまでAIの活用方法について活発な議論が続きました。 ご参加いただいた皆さま、発表してくださった皆さま、そして会場をご提供いただいたNiterra North America, Inc.の皆さま、ありがとうございました。

ベイエリアAI勉強会 第2回 開催レポート

2026年6月24日、Santa ClaraのNiterra North America, Inc.にて開催した「ベイエリアAI勉強会 第2回：AIで作る・つなぐ・自動化する」の開催レポートです。