AI ideas
get better when people share them.

第4回 Bay Area AI勉強会 - 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 コミュニティサイト](https://bayarea-ai.com/) 本勉強会は、ベイエリアの日本語話者エンジニア・技術者コミュニティを支援するNPO、JTPAにもサポートいただいています。 - [JTPA公式サイト](https://jtpa.org/) - [JTPA Facebookグループ](https://www.facebook.com/groups/25208215005) ## 写真撮影について 当日は、開催レポートや今後のイベント告知のため、写真撮影を行う場合があります。 写真は個人が特定されない形で利用する予定です。掲載を希望されない方は、当日スタッフまでお知らせください。 皆さまのご参加をお待ちしています！

I rebuilt my blog's shogi AI in a day with a fleet of AI agents — from bug hunts to WASM and NNUE distillation

Yudai Yaguchi

> The homemade shogi AI on my personal site (meetyudai.com) was, in the words of its owner (an amateur 2-dan player), "way too weak." This is the record of running up to five Claude Code subagents in parallel to see how far I could push it in a single day. It keeps not just what worked but the failed ideas that got mercilessly rejected by A/B testing — the raw diagnostic logs, the catalog of failures, the real numbers, and the lesson (learned the hard way, more than once) that polishing a proxy metric doesn't win you games. Cost: essentially nothing (electricity and LLM usage). This is the overview; the raw logs and code are in the full write-up on my blog. The gist (three lines up front) - The real cause of the "nonsense moves" was neither the search nor the eval: an opening-book fallback was bypassing the search engine and answering instantly, a wiring bug. A thinking-time log was the smoking gun. - Small tweaks to the handwritten engine were "no effect" 8–9 times out of 10 under production time controls. What worked was structural: a TypeScript→WebAssembly port (15× faster search) and, on top of it, NNUE distillation. - The arc was 19.6% → 32.1% → 77.1% win rate vs the handwritten eval. At the end I lost to it in production, discovered a disease called sigmoid saturation, and cured it by rebuilding the data. Finally the author confirmed, in real games, that it "definitely got stronger." What I built I built a shogi AI that runs entirely inside the browser (WebAssembly), with no backend at all. Open the page and it fetches the eval weights (a 1.1 MB static file) asynchronously; from there it reads a few moves ahead and plays using only your browser's CPU. It runs on a phone browser. It has two pillars. The first is the search engine — the "read ahead" part. Shogi averages 80–100+ legal moves per position, and multiplying that across several plies gives astronomical trees. You can't read everything, so you prune obviously-bad branches early. The toolkit: negamax with alpha-beta pruning (cut branches that can't beat what you've already found, assuming the opponent replies optimally), principal-variation search, a transposition table (a cache of already-searched positions), late-move reductions (search later-ordered moves shallower), null-move and futility pruning, a quiescence search (read on until captures settle), and a dedicated mate solver. In short, a box of tools for "cutting corners intelligently so you can read deeper." The second is the evaluation function — the "eyes" that turn the leaf position of a read into a single number: who's ahead, by how much. No matter how deep the search, it's worthless if it can't score the leaves correctly. It started as a handwritten, rule-based eval; in the end I replaced it with an NNUE (neural-net eval). That's the centerpiece of the story. The "browser-only" constraint matters more than it sounds. Training uses a GPU, but running it (inference) is CPU-only — and it has to be strong under a harsh budget: a few hundred milliseconds on someone else's phone. That constraint drives every later decision: keep the model tiny, quantize it, speed it up with SIMD. Why I built it As a 2-dan player, I found the AI on my site honestly "too weak." Two symptoms. First, it lost the same way every time to the basic amateur "climbing silver" (bōgin) attack — the ▲2六歩→2五歩→3八銀→2七銀→2六銀→1五銀… march that's on page one of every beginner's book. Losing to that every time isn't a matter of counter-strategy; it means the reading itself is broken. Second, it occasionally played completely nonsensical moves — dropping a pawn uselessly in its own camp, walking its king into danger. Moves no human would ever make. The direct motivation was that leaving it broken bugged me. But there was a second one: an experiment — how far can a fleet of AI agents rebuild a piece of software in one day? Shogi AI is an ideal subject, for two clean reasons: a ground truth exists (YaneuraOu, an engine far beyond amateur-top strength), and strength is directly measurable. So you can't escape into "it feels better." Measure, and you get a verdict. How I ran the agents Before the technical details, the process itself — because it's half the point. I ran up to five subagents in parallel. Responsibilities split into "speed up search," "train the eval," "curate the opening book," "harden the code (address review findings)," and "write the article." I stayed the integrator: read each agent's result and decide what to try next, so a human bottleneck doesn't stall the independent work. The problem is that five agents editing the same repo at once will clobber each other. I solved it by giving each agent its own git worktree — multiple working copies of the same repo. Agent A can rewrite the search code while Agent B touches the training script without stepping on each other's files. Cheap isolation, no merge chaos. And — most important — every "behavior-changing" change had to pass an A/B test. I trusted no "feels stronger." Each change played N games against the previous version at production time controls, and got adopted only if it genuinely won more. Thanks to this, 8–9 out of 10 ideas I tried were rejected. That's not a failure; it's the whole point. Most plausible ideas don't survive measurement, and building the machine to reject them mechanically, up front, was the single biggest win. The other mandatory gate was bit-exact parity. Later I ported the engine to WebAssembly, and I refused to allow "faster, but the moves changed slightly." The ported version had to return the same move, same score, same node count, same leaf count as the handwritten TypeScript version — verified on thousands of positions and by exhaustive legal-move counts (perft: 25,440 nodes at depth 3 from the initial position, matching known numbers even with drops in hand). Only the version that matched 100% went to production. Different speed, identical moves — that closed the door on "optimization sneaks in a bug." Phase 1: reproduce "weak," and find the real culprit Faced with a weak AI, the temptation is to guess "the eval's bad" and start fixing. But that's a guess. I decided to get hard evidence first. I turned a losing game — the collapse to bōgin — into a reproducible script as a fixed game record. That script feeds positions, one by one, through the exact production AI path, and logs the returned move, score, material, and how long it thought. That surfaced the decisive clue: the AI was returning each move in 1–23 milliseconds. Real search of several plies takes hundreds of ms to seconds. An instant 1–23 ms reply means it isn't reading at all. Chasing it down, the truth was: an opening-book fallback was bypassing the search engine entirely. That mechanism is supposed to instantly return a recorded move for positions that are in the book. But a bug made it return a "plausible-looking" move even for positions outside the book — with no search. So even at critical endgame moments, the AI was choosing moves on vibes, reading nothing. That was the source of the nonsense. This is the biggest finding. The cause of the weakness was neither the eval nor the search algorithm — it was a wiring bug sitting in front of both. However much you polish eval or search, if the search never gets called, it all gets bypassed. Deleting that fallback eradicated the instant-nonsense class of bug. The lesson is clear. Inferring the cause (bad eval) from the symptom (bad move) usually misses. Hit it with hard evidence. Thinking time — a seemingly irrelevant number — was what cracked it. Phase 2: rebuild the search (small tricks barely helped; the structural change did) With the instant-answer bug gone, I wanted to get stronger while actually reading. I started with the search itself. I tried textbook tricks: another layer of pruning, better move ordering (searching good-looking moves first makes pruning bite), deeper mate search, tuned margin constants. In theory each should "read deeper" or "cut waste." But under rigorous A/B at production time controls, most of it was "no effect." Improvements that should deepen the read didn't move the win rate at all. This foreshadows what bit me later: a deeper read doesn't convert to wins if the eval can't correctly judge the positions you reach. What worked wasn't a trick — it was swapping the substrate. I ported the handwritten TypeScript engine to WebAssembly (WASM), a low-level format that runs at near-native speed in the browser and crunches numbers far faster than JavaScript. Moving the same algorithm to WASM alone gave: - 15× faster search - +3–4 ply of depth at the same time budget - a 10–0 record against the old engine In shogi, "+3–4 ply deeper" is a rank's worth of strength. I didn't make the algorithm one bit smarter — just changed the runtime. Speed, not smarts, was the bottleneck — a blunt but crucial lesson. Phase 3: distill the eval (NNUE) With search fast and deep, it was time to strengthen the leaves — the "eyes," the evaluation function. Until then it was handwritten: piece values (a pawn ≈ 100, a rook ≈ 1000…) plus terms for king safety, piece activity, and so on, summed by human-written rules. Readable and decent, but capped at the range of terms a human thinks of. The subtle goodness of a shape can't be fully captured in rules. So I replaced it with machine learning, via distillation. The idea: 1. Have the strong engine YaneuraOu score millions of positions at fixed depth. That's the teacher data. YaneuraOu is strong but heavy — it can't run in a browser. But as a "teacher who grades your answers," it's ideal. 2. Have a small neural net imitate those scores. The net is deliberately tiny: roughly 2,268 board features → 256 → 32 → 1, with clipped-ReLU activation (a simple non-linearity that caps values that grow too large) and about 590k parameters. Tiny, because it has to produce an eval instantly on a browser CPU. This format is NNUE, and — fun fact — it was originally invented for shogi (chess's Stockfish imported it later). NNUE's strength: when the board changes by only one move, it can update the eval incrementally rather than recompute (the running state that enables this is the "accumulator"). 3. Quantize the trained weights to 16-bit integers (round fine decimals to integers), compress to 1.1 MB, and serve them statically to the browser. The training target was — the engine's centipawn score (cp = hundredths of a pawn) squashed by a sigmoid into a win-probability-like 0–1. Remember that 600 in the denominator. It bares its teeth in the endgame. Data: three cycles of measurements NNUE didn't land in one shot. It took three rounds, each its own little story. Cycle 1 — a rout (19.6%). The first trained NNUE, in equal-time self-play against the handwritten eval, won just 19.6%. A blowout. Yet the inference was perfectly correct — bit-identical across the training framework, TypeScript, and WASM on hundreds of positions, with matching node counts at equal time (the incremental accumulator worked flawlessly). The implementation was right; the model itself lost. The post-mortem is the most important lesson here. I'd been judging model quality by "how close it is to the teacher's scores." 2–2.5× closer than the handwritten eval — so it should be stronger, right? But that metric is a bad predictor of match strength. Here's why: what alpha-beta needs is not the absolute eval value but the relative ordering of sibling moves. As long as "this move beats that one" is right, search works. The net's average error was larger than the gap between typical candidate moves (<100cp), so it scrambled the ordering. The handwritten eval, even with an off absolute scale, was self-consistent, so a uniform bias was harmless to search. "Close to the teacher but with jumbled ordering" is weaker in search than "far from the teacher but order-preserving." That lesson held to the end. Cycle 2 — the reversal (77.1%). Guessing the cause was "error too big to preserve ordering = too little data," I greatly increased the teacher data and retrained. The win rate climbed 19.6% → 32.1% → 77.1%, clearly beating the handwritten eval. More data alone flipped a rout into a comfortable win. I also shipped pondering (thinking on the opponent's clock — a "permanent brain"), lifting mean reached depth 9.00 → 9.35. This finally reached production. Cycle 3 — speed, then a defeat and its cure. Now that it could win, I made it fast. WASM SIMD (one instruction computing several numbers at once) made the eval 6.2× faster, and I added multithreading (a Lazy-SMP-style parallel search; an estimated +58 Elo, though at n=24 it didn't reach significance, so I recorded it honestly as a point estimate). So far so good. And then — at the top difficulty in production, the author (2-dan) beat the NNUE. The thing I'd just strengthened tripped over its own feet in a real game. The diagnosis revealed the culprit. The main enemy: sigmoid saturation Recall the training target was . That design hid a trap for the endgame. A sigmoid flattens and pins near 1 for large inputs, near 0 for small ones. In won or lost positions the centipawn score is huge (say +3000cp), so is essentially 1.0 — maxed out. The problem: from there, moving the eval a bit — +3000 or +3500 — barely changes the output. So moves that should differ in value all collapse to nearly the same number. In the problem position from the diagnosis, all 71 legal moves collapsed into a 15cp band. To the AI, "every move is the same." So in a position where the win (or loss) was clear, it picked essentially at random and produced nonsense. The "nonsense move" in the game the author lost came from exactly this. Ironically, making it read deeper made things worse, by reaching more of those saturated positions. The fix was in the data, not the search. The earlier training data had thinned out decisive (lopsided) positions as "boring" — and that thin region was exactly where saturation lived. So I retrained with decisive positions deliberately over-sampled — up to about half the set — on 5.24M positions (labels at depth 12), to teach it the saturated region and let it tell tiny differences apart inside a big lead. Results: - Move-value spread in the problem position recovered from 20cp → 532cp (26×): "all the same" became "clearly different." - Blunders in that position halved, 8 → 4. - 92.2% win rate vs the old NNUE; 84.4% vs the handwritten eval (at both 1000 ms and 2000 ms). - And finally, the author confirmed in real games that it "definitely got stronger." Not a proxy metric — the author playing it and admitting it. That was the only pass/fail I trusted. What I learned (failures and all) Honestly, the biggest payoff of the day was the record of failures, more than the wins. A good proxy metric doesn't mean you win. Doubling "closeness to the teacher" didn't make it stronger. The final judge is always the same: do you win the actual game — ideally against a human playing the openings you actually face? Bench numbers are only a mid-way signal. Verification itself is full of traps. Self-play statistical degeneration (self-play skews the win/loss when both sides share quirks), time-control bias (the budget you measure at changes the conclusion), and a config mismatch between old and new defaults — each nearly led me to "conclude it got stronger" by mistake. The only defense is to measure under production-equivalent conditions. Catalog of what didn't work — a memorial to the plausible ideas that died on measurement. King-piece (KP) features (a powerful method adding fine king-to-piece relations, but at 1M positions it made things worse via data dilution), check extensions (lost the A/B), drop-move late-move pruning (same), deepening the mate solver (no change). The capstone: full bitboards. Holding the board as bits of an integer and processing with bit operations is the core of a native engine's speed. I tried to copy it — but in 32-bit JavaScript the 81 squares don't fit in a single integer. Resolving sliding-piece attacks straddles words awkwardly, and a slider-list prototype came out 2× slower than the array ray-walk the JIT already optimizes well. Theoretically faster, slower here. A genuinely different arena from native C++. How I'd make it stronger from here Honestly: the browser arena has a ceiling. The search side is done for practical purposes in this environment. With SIMD, multithreading, and bit-exact speedups all in, there's no structural "depth jump" left to grab. To go further, the lever is the eval (data) side. The strongest candidate is a self-play data loop — have the current strong engine play itself to gather "positions that arise in genuinely strong play," re-label them with YaneuraOu, and retrain, closing a positive loop. Caveat: the grader is still YaneuraOu, so the ceiling is YaneuraOu's judgment (this is not true self-improvement à la AlphaZero, which learns from game outcomes themselves). The other lever is hunting concrete weaknesses the author finds in real games. The saturation discovery was exactly that: a single real game pointed at the weak spot more sharply than any proxy metric could. Cost and wrap-up Total cost: electricity and LLM usage only. Time: effectively one day. From "way too weak" to "the author admits it's definitely stronger," reached by running AI agents in parallel plus the unglamorous discipline of A/B testing and bit-exact verification. Looking back, this isn't a story of "one clever discovery." Quite the opposite: measure, discard the failures, keep only what survives — that boring repetition is what worked. 8–9 out of 10 flashy ideas died; the surviving few (the WASM port, more data, killing saturation) carried the whole thing. Reliably rejecting the changes that make it weaker mattered far more than being clever. The full version (raw logs, code, all the numbers) Everything above is a digest. The raw debugging logs, the details of every failed approach, the per-cycle measurement graphs, and the code are all in the full write-up. There's also a beginner primer explaining NNUE, distillation, backprop, and quantization from scratch. 👉 Full write-up: https://www.meetyudai.com/blog/applied-algorithms/9fpLthtYgHvnImuFR0Jf 👉 Primer (for ML beginners): https://www.meetyudai.com/blog/applied-algorithms/H9beqVVY7h5qc3hNfskR

JTPA Community Hub: A community platform for running AI meetups

Yudai Yaguchi

Why I Built It Bay Area AI / JTPA activities can easily become scattered across many tools: event announcements, RSVPs, presenter info, slide sharing, check-in, project showcases, blog posts, Q&A, and polls. Organizers need a reliable way to manage events, while members need one place to find upcoming events, past materials, and what others are building. I built this as a unified community hub for AI meetup operations. The Showcase feature you are reading now is part of the same platform. What It Does JTPA Community Hub is a web application for running the Bay Area AI / JTPA community. It includes: - Event listings, event detail pages, RSVPs, and waitlists - Presenter registration, talk titles/abstracts, and slide or recording links - QR-code check-in for event day attendance - AI project Showcase submissions, admin review, comments, and likes - Member blog posts, Q&A, guides/notes, and community polls - Google sign-in, public profiles, and member dashboards - Admin tools for events, reviews, attendee CSV export, and roles - Japanese and English localization The goal is not just a public website. It is an operational backbone for a recurring AI meetup and a place where knowledge can accumulate over time. How It Works The app is built with Next.js 16 App Router and React 19, hosted on Firebase App Hosting. Firestore stores data, Firebase Auth handles Google OAuth, and Firebase Storage stores project images, event assets, and presentation files. A key design choice is that almost all Firestore reads and writes go through the server. Server Components load page data, and Server Actions handle RSVPs, submissions, approvals, comments, likes, and check-in. The browser does not directly write application data to Firestore. Authorization is centralized in helpers such as , , and . Large files use a different path: images and slides upload directly from the browser to Firebase Storage. After upload, a Server Action records only the metadata in Firestore, so Cloud Run does not proxy heavy file transfers. How I Used AI to Build It Most of the implementation was developed with Codex and Claude Code. I did not treat AI as a black-box "build the whole app" button. I broke the product down feature by feature and gave the AI the relevant code, constraints, expected behavior, and verification commands. The typical loop was: 1. I defined the need, such as waitlisted RSVPs, QR check-in, or reviewed project submissions 2. I asked AI to read the data model, Server Actions, Firestore rules, and UI patterns 3. AI proposed a plan, and I checked authorization, data consistency, and failure cases 4. AI implemented a small change 5. I ran , , , and rules tests, then fed CI or review feedback back into AI AI was especially useful for expanding consistent patterns: Firestore schemas, Server Actions, admin screens, Markdown editors, i18n copy, tests, and docs. Once a pattern existed, AI helped apply it to events, projects, posts, Q&A, polls, comments, and likes. The parts that still needed strong human control were security, permissions, moderation workflow, product decisions, and UX. I treated AI-generated code as a draft, especially around who can perform an action, what happens if a write fails, and whether a pending or rejected submission can become public. What Was Hard The hardest part was balancing a simple community-facing experience with the strictness required by an operations tool. Members should see a clean site, while the system still handles RSVP counts, waitlists, presenter counts, attendance counts, approval status, ownership, roles, and file permissions correctly. QR check-in was a good example. It needed event-specific validity windows, login redirects back to the QR URL, duplicate check-in protection, admin corrections, and cumulative attendance counts. Next.js 16 also has meaningful changes compared with older versions, so it was important to make the AI read local docs and APIs instead of relying on stale assumptions. What I Learned The most important lesson was that AI coding works best when constraints are clear. Prompts like "read this file," "follow this pattern," "keep this authorization boundary," and "run these tests" were much more effective than vague requests. AI can speed up implementation dramatically, but it does not replace product judgment. Decisions such as which content requires review, whether Q&A should publish immediately, and what event attendees should provide need to come from people who understand the community. What's Next Next, I want to add AI-powered summaries for posts and Q&A, automatic event recap drafts, recommendations for relevant projects or guides, and better analytics for organizers. The long-term goal is to make community knowledge easier to find and reuse after each meetup ends. Detailed Project Case Study I also wrote a more detailed English case study about this project on my portfolio site. It summarizes the product goals, my role, key features, technical architecture, AI-assisted development workflow, challenges, and outcome from a professional project perspective. 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

最新のニュース/Youtube/Tweetを毎日取得してエージェントに解析させる [株取引自動化 Part1]

@jin

Market 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。

ベイエリア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で作る・つなぐ・自動化する」の開催レポートです。

ベイエリア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になりましたのでご注意下さい。 --- 皆様のご参加をお待ちしております！