AIの試行錯誤を、
みんなで持ち寄る場所。
ベイエリアAI勉強会は、Bay Areaの日本語・日本人テックプロフェッショナルがAIの学びや実践を持ち寄るコミュニティです。 完成した記事じゃなくても大丈夫。試したこと、詰まったこと、小さな発見、作ったものを気軽に書き込んでください。
プロフィール
公開プロフィールと設定
ログインすると、自分の公開プロフィールページとアカウント設定を使えます。公開する情報はプロフィール設定から選べます。
次に参加できるイベント
勉強会、LT、交流会など。聞くだけでも、持ち寄って話すだけでも歓迎です。
みんなのプロジェクト
完成品だけでなく、試作や途中経過も歓迎。見せられるところから共有してください。
ブログの将棋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] のサムネイル](/_next/image?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Fjtpa-main.firebasestorage.app%2Fo%2Fprojects%252Fs20K36xPeMfgZrVuuIYKnMvxDO12%252F1781293156428-%25E3%2582%25B9%25E3%2582%25AF%25E3%2583%25AA%25E3%2583%25BC%25E3%2583%25B3%25E3%2582%25B7%25E3%2583%25A7%25E3%2583%2583%25E3%2583%2588_2026-06-12_12.38.36.png%3Falt%3Dmedia&w=3840&q=75)
株取引で予想が当たるYoutuberを見つける [株取引自動化 Part2]
@jinMarket 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
情報取得／解析エージェントアルゴリズム最適化![最新のニュース/Youtube/Tweetを毎日取得してエージェントに解析させる [株取引自動化 Part1] のサムネイル](/_next/image?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Fjtpa-main.firebasestorage.app%2Fo%2Fprojects%252Fs20K36xPeMfgZrVuuIYKnMvxDO12%252F1781246657091-sentiment.png%3Falt%3Dmedia&w=3840&q=75)
最新のニュース/Youtube/Tweetを毎日取得してエージェントに解析させる [株取引自動化 Part1]
@jinMarket Sentiment Explorer 何故作ったか 毎日通勤中に株式市況情報のYoutubeチャンネルを複数見てチェックしていたが、これを自動化したかった 何を作ったか 毎日指定した Youtube Channel, Website, X accoutを巡回し最新のtranscript/記事/Tweetを取得し、Claude Codeに内容を分析させ、市場のセンチメントを数値として把握できるようにし自分の代わりに毎日の分析を行わせます。 具体的にはそのセクターが上がると予想される期待の強さ（センチメント）と、現時点で不確定であるネガティブ要因（リスク）を分析します。 (一ヶ月の各セクターごとの分析された市場センチメント変化) 仕組み Youtube ChannelやXのアカウントを巡回しtranscriptや内容を取得します。一日に120件程度のyoutube チャンネル、250件程度のツィートを取得します。 現状でトータル1万件のvideo/news/tweetを取得しました。 (取得したyoutubeチャンネルのtranscriptの例) その後、それぞれに下記のようなプロンプトを使って各セクターの今後の予想やリスクを数値として取得します。 (得られたセンチメントデータの例。多数のセンチメントをあるアルゴリズムを使ってまとめあげてその日のセンチメントを算出する) 最終的に直近2週間のセンチメント変化＋各youtube Channel/ツィートのサマリを全てエージェントに読ませてサマリーレポートを作成します。 ... (サマリーは長いので省略) さらに11種類の各種経済指標も毎日取得させ、それぞれの日次、週次、月次の変化も分析させてレポートを作成させます。 作成された経済指標サマリの例: こうして得られた各種情報に自分の現在のポートフォリオをAIが読める形(CSV)にしておき、Claude Codeに与えて運転中に音声で相談ができるシステムになりました。 フローチャートは下記のようになっています。（後半の"予想が当たる"YoutuberやXアカウントの算出” は別の記事で解説しています） どうやって作ったか、難しかったポイントなど 全てClaude CodeあるいはCodexに頼んでコードを書いてもらっています。 GUIはPythonでそのままコードが書けるようにStreamlitを使いました。 （これは後で分析されたセンチメントと実際の値動きの相関を分析するためにpythonのライブラリを使いたかったため） コツとしては、センチメント分析などでLLMを走らせたい場合にAPIを使うと非常に高くついてしまったため、CodexやClaude Codeをヘッドレスモードで呼び出して処理させている点です。これによって5h/1weekの復活枠を使って非常に安価に($20/mo)大量のトランスクリプト分析と日本語への翻訳を実現しています。 作ったことで得られたインサイトなど 今まで一日に3-4チャンネルのYoutubeを見るのが限界だったが、一気に120チャンネル以上網羅的にチェックできるようになった。英語のチャンネルも日本語にで読めます。 システムの設計にはソフトウェアエンジニア的なコツが必要 Youtuberは一般的にXユーザーよりも楽観的 バイアスのかからないシステムを組むことは非常に難しい 今後やりたいことなどがあれば 元々のフィーリングとして、全ての情報を数値として集約し予想を行わせる機械学習モデルでは限界があると感じていました。今回はセンチメントデータを数値としてまとめつつ、元の記事のサマリーや経済指標変化などは大量のテキストとして保存し混ぜて使うことに一定の手応えを得ることができました。 このまま企業の決算情報DBやチャート情報解析スキルと組み合わせることでより高度な資産運用エージェントの構築を目指そうと思っていますw。
情報取得／解析エージェント大量テキスト解析
最近の開催報告・過去イベント
参加前後に雰囲気が分かるよう、直近の開催報告や終了したイベントをまとめています。
開催報告2026年6月24日(水) 17:30
ベイエリアAI勉強会 第2回 開催レポート
2026年6月24日、Santa ClaraのNiterra North America, Inc.にて開催した「ベイエリアAI勉強会 第2回：AIで作る・つなぐ・自動化する」の開催レポートです。
過去イベント2026年5月15日(金) 17:30
ベイエリアAI勉強会 第１回キックオフ
> > 当日ご参加頂いた皆様ありがとうございました！ > 会場を提供頂いたニテラの方が当日の写真を撮っていて下さいました。ご興味のある方はぜひ下記のリンクからご覧下さい。 > またもし公開を望まない写真が含まれておりましたらお手数ですがスタッフまでご一報頂けたら幸いです。 > > https://adobe.ly/4eze6EU > #【ゆるく学ぶ ベイエリアAI勉強会（仮）】 第一回キックオフ 2026/5/15 5:30 PM – 7:30 PM Vibeコーディングを活用したい コーディングをしたことはないが何かアプリなどを作ってみたい AIやエージェントを日々の業務や日常生活に役立てたい 自分のAIの使い方を皆と共有したい そんな人々が気軽に参加できる勉強会です。 この会は基本的には講義中心ではなく、参加者同士でAIの使い方や工夫を見せ合いながら一緒に学んでいくスタイルにしたいと思っています。最初の方は運営側で教材や講習などは用意していく予定ですが、参加者同士で気軽に質問したりアップデートしていける会を作っていけると嬉しいです。 勉強会は当座は月に1回オフラインで定期的に集まりつつオンラインで活動していければと思います。 ▼当日の内容（予定） 途中でレベル別にいくつかのグループに分かれての進行も検討中です 参加／退出自由 ・簡単な教材やテーマは用意しますが、基本はハンズオン＆共有スタイル コーディング系に加えて、AI/エージェント活用（非エンジニア向け）グループも検討中 当日皆さんに見せたいものがある人は大歓迎です。LT/発表者枠でお申し込み下さい。 ▼開催概要 日程：5/15 (Fri) 17:30 には会場を開けます。遅れて参加もOK。18:00時開始〜19:30か20:00まで？ 場所：Niterra North America, Inc. 住所 3979 Freedom Cir # 400, Santa Clara, CA 95054 です。 Mission Towers 2の4階になります。 参加費は無料： BYOB（アルコールはNGですがスナック・飲み物の持参は歓迎です） ▼運営・リード 当面は 下記３名でリードしていきます。 Yudai Yaguchi ( https://www.linkedin.com/in/yudai-yaguchi ) Mie Haga ( https://www.linkedin.com/in/miehaga ) Jin Yamanaka ( https://www.linkedin.com/in/jin-y ) また、本勉強会はベイエリアの日本人エンジニアを支援するNPOである JTPA もバックアップしていきます。 ▼追記 場所については Niterra North America, Inc. 様に会場をご提供頂けることになりました。 西側にある立体駐車場が使えますので、駐車はそちらをご利用ください。 ビルのセキュリティの都合上、受付でご利用階までのエレベータを手配するルールとなっています。申込時にお名前と所属をご記入頂けますとお名前を告げていただけるだけで入館できるようにNiterraさんで手配頂けるそうです。 以前に概要にBYOBと書かれていましたが、アルコールはNGになりましたのでご注意下さい。 --- 皆様のご参加をお待ちしております！