Shu Kobuchi

はじめに前回（Anthropic Claude (Sonnet 4.6 / Opus 4.7) を加えて、5 機種で自転車青切符ベンチマークを総括する）でタイトルに堂々と「完結編」と書きました。完結しませんでした。正確に言うと、判定の質の話は前回で出し切ったつもりだったのですが、前回までの計測にずっと 1 個飲み込みが悪かった点が残っていました。Claude Sonnet 4.6 のハイブリッドが 7 問通しで 226 秒、Gemini 3 Flash に至っては 629 秒かかっていた、あの数字です。Layer 1（条文 AST + TF-IDF + 反則金テーブル）で根拠を全部渡しているのに、Layer 2 の LLM がなぜそんなに考え込むのか、設計上は説明がつきません。ブログを公開して数日経ってから「これ、判定の話に集中しすぎてレイテンシを放置していたのでは」と気づき、潰しに行きました。結論は身も蓋もなくて、Gemini も Claude もデフォルトで thinking を回す設定になっていて、Layer 1 で根拠を全部注入しているハイブリッド構成ではそのコストが丸ごと無駄になっていた、という話でした。明示的に切ってやると Flash は 1 リクエストあたり 5 分 → 数秒、ハイブリッド全体で 7〜8 割の時間が消えます。問題は その代償で正答率は落ちないのか という点で、これを 5 機種すべてで再計測したのが今回の検証です。「完結編」と書いた手前、結論が変わったら書き直す責任があるので、続編を書きます。これまでのシリーズはこちら。Flash 編：単体 5/7、卒論ハイブリッドで 6/7Pro 編：単体は Flash と同じ 5/7、最後の一歩で同じ方向に倒れるGemma3 編：ローカル 4B では条文を注入されても逆向きに倒れるClaude 編（自称・完結編）：Sonnet/Opus を加えて、ハイブリッドだと「Layer 1 が穴を開けたときの後始末」がベンダーで割れることを確認何が起きていたかハイブリッドの Layer 2 呼び出しは、こういう薄いプロンプトを Gemini に投げているだけです。system instruction：「Layer 1 が e-Gov XML からパースした条文と反則金を絶対的根拠として使え、学習データからの補完はするな」user contents：Layer 1 が引いた条文 3 本（テキストごと）＋ 反則金テーブル抜粋 ＋ 検出済み論理フラグ（exception, proviso, delegation など）＋ 委任規定の解決済み情報（施行令第 26 条で「70 歳以上の者」と展開済み）＋ 質問LLM 側がやることは、条文の階層を読み下して「合法 / 違反」を選び、注入された反則金を引き写し、reasoning を書く。これだけです。条文を探す必要も、金額を推測する必要もありません。ところが、デフォルト設定で投げると以下が走ります。Gemini 3 系：thinking_config を明示しないと、内部で「自分で考える」モードが入る。Pro は元から思考前提のモデルなのでまだ穏当ですが、Flash は単発で 5 分 thinking してから 1 行返してくる事象が出ました。Claude Opus 4.7 / Sonnet 4.6：旧来の温度パラメータが消えた代わりに adaptive thinking が前提化されている。SDK アダプタ（anthropic_client.py）でも、最初は良かれと思って Claude 系には常時 thinking: {type: "adaptive"} を付けて投げていました。これが今回の Sonnet 226 秒の犯人です。つまり、「考えなくていい仕事のために思考時間を全部払っていた」状態。Layer 1 を後段に持つハイブリッド構成では設計上ありえないコストでした。実装の修正は数行です。# backend/src/judgement/hybrid_judge.pyresponse = self._client.models.generate_content(    model=self._model,    contents=prompt,    config={        "system_instruction": HYBRID_SYSTEM_PROMPT,        "temperature": 0.0,        # Layer 1 で根拠条文・反則金・委任規定を全て注入済みのため thinking は不要。        # 有効のままだと Gemini 3 Flash で 1 リクエスト 5 分かかる (#10)。        "thinking_config": {"thinking_budget": 0},    },)Anthropic 側は逆方向の修正で、anthropic_client.py から「Opus/Sonnet を見たら自動で adaptive thinking を付ける」分岐を撤廃しました。config["thinking"] が呼び出し側から明示されたときだけ転送する素直な実装に直しています。# backend/src/llm/anthropic_client.py（修正後）thinking_cfg = config.get("thinking")if thinking_cfg:    kwargs["thinking"] = thinking_cfg実コードは PR #10 を参照ください。再発防止用のプロファイラ改善活動の副産物として、Layer 1 / Layer 2 を分けて計測する scripts/profile_hybrid.py を入れました。「総時間の何 % が LLM か」を出すだけのスクリプトですが、これがないと「遅いのは LLM か Layer 1 か」を毎回主観で判断することになるので、再発防止用として置いてあります。$ python -m scripts.profile_hybrid --model flash --runs 3 --queries 3[Summary] (mean over 9 samples)  layer1 (VSM+prompt) mean=  3.3ms    0.1%  min=  2.8ms  max=  4.1ms  llm_call           mean=  2.84s   99.9%  min=  2.31s  max=  3.51s  TOTAL              mean=  2.85s[Diagnosis]  支配項: LLM 呼び出し (100%). Layer 1 はほぼノイズ。Layer 1 はミリ秒オーダーで、結局すべてが Layer 2 のレイテンシで決まる、という当たり前の構造が見えます。LLM 側を整えれば全体が速くなる、という指針もここからきています。結果：5 機種を再計測python -m src.main --hybrid --model <model> を 5 機種で回し、Pre-fix（thinking on）と Post-fix（thinking_budget: 0 / Claude は adaptive thinking 撤廃）を並べました。Pre-fix の数字は前 4 編で使ったデータ、Post-fix は今週撮り直したものです。ハイブリッド 7 ケース合計時間 モデル  Pre-fix  Post-fix  削減率  Gemini 3 Flash  629 秒  146 秒  76.8%  Gemini 3.1 Pro  147 秒  22 秒  85.0%  Claude Sonnet 4.6  226 秒  63 秒  72.1%  Claude Opus 4.7  54 秒  53 秒  1.1%  Gemma3:4b（ローカル）  249 秒  120 秒  51.8% Pro が一番きれいに効きました。約 1/7 です。Layer 1 が条文と金額を全部渡している以上、Layer 2 は「整形係」でしかなく、Pro クラスのモデルの能力は思考時間ではなく 生成速度のほうで効く、という仮説どおりの結果になりました。Opus 4.7 だけは Pre-fix の時点ですでに 54 秒で、ここから 53 秒で誤差レベル。これは Opus の adaptive thinking が「資料が揃っているケースでは考える余地がないと自己判断する」挙動を持っていたためで、前回 Claude 編で「Opus が Sonnet より速い」と書いた件と整合しています。Opus は最初から自前で thinking を切っていたわけで、こちら側から強制オフしても伸び代が残っていませんでした。Gemma3:4b（ローカル）には thinking_budget のような概念がそもそもないので、ここで短縮された半分は別要因です。これはおそらく、Pre-fix の計測時に他のジョブと重なって Ollama サーバが重かった分が抜けただけで、今回の最適化由来ではありません。ここは差分として参考程度に。ハイブリッド 1 ケースあたり最大値平均より「最悪ケース」のほうがユーザ体験には響くので、ケース別の最大レイテンシも並べます。 モデル  Pre-fix max  Post-fix max  削減  Gemini 3 Flash  約 297 秒（commit 計測の単発値）  47.5 秒（TC-005）  84%  Gemini 3.1 Pro  約 22 秒  4.0 秒（TC-002）  82%  Claude Sonnet 4.6  61 秒（TC-001）  17.6 秒（TC-002）  71%  Claude Opus 4.7  約 10 秒  10.6 秒（TC-001）  横ばい  Gemma3:4b  約 33 秒  26.7 秒（TC-001）  19% Flash が Pre-fix で「1 リクエスト 5 分」というのは PR #10 のコミットメッセージにある単発計測（commit f98fcef）で、運用上の最悪値です。Post-fix では 47.5 秒（TC-005「酒気帯び」、論理フラグに delegation が乗っていてプロンプトが長め）が最大で、5 分問題は消えました。ただし、ここは正直に書くと、commit メッセージの「Flash 105× 高速化」は短いクエリ 3 本での best-case 値で、実際の 7 ケース通しでは Post-fix の平均でも 21 秒（最大 47 秒）残っています。「99% 削減」というラベルは最悪値どうしの比較で、平均値で測ると 77% くらいが実態です。誇張は避けたいので、両方の数字を出しておきます。速くなったのは分かった。精度はどうなったかここからが本題です。評価ルブリックは前回までと同じく、「判定（合法 / 違反）、根拠条文、反則金、すべて期待値と一致 = ✓、判定と条文は合うが金額抜け or 不一致 = △、判定そのものが誤り = ✗」。Pre-fix vs Post-fix の正答内訳 モデル  Pre 完全✓  Pre 本質✗  Post 完全✓  Post 本質✗  差分  Gemini 3 Flash  5/7  1 (TC-003 合法と誤判定)  5/7  0  改善：TC-003 が「違反」になった  Gemini 3.1 Pro  5/7  1 (TC-003 合法と誤判定)  5/7  0  改善：TC-003 が「判定不能」に退避  Claude Sonnet 4.6  5/7  0  5/7  1  退化：TC-002 で「合法」と誤判定  Claude Opus 4.7  5/7  0  5/7  0  同点  Gemma3:4b  3/7  4  3/7  4  同点 完全 ✓ の数字は 5 機種すべて変動ゼロ。ハイブリッド構成下では thinking をオフにしても、判定 + 条文 + 金額の正答数は動きません。Layer 1 がグラウンディングを取り切っているなら Layer 2 の思考時間に正答率は依存しない、というのは「そりゃそうだろう」という話ですが、実測で取れた意味は大きいと思っています。ただし、「本質的 ✗（judgement が逆方向）」では機種ごとに小さな動きが出ました。良くなった機種と悪くなった機種が両方あります。順に見ます。改善側：Gemini Flash と Pro が「合法と言ってしまう」事故を起こさなくなった前回 Claude 編で書いた、Layer 1 が穴を開けたときに Gemini 系が陥っていた False Negative。TC-003「自転車でスマホを手に持って運転」Layer 1 が引いた条文：制動装置・検査・自転車道（いずれも携帯使用とは無関係）Pre-fix Flash の判定：合法（「禁止規定がないので違反は問えない」）これが Post-fix では：Post-fix Flash の判定：違反（「条文データには該当なし、反則金特定不可」）Pro も同様で、Pre-fix の「合法」から Post-fix では「判定不能」へ。どちらも「合法だ」と断言する事故は消えました。これは正直予想外でした。thinking を切ったほうが判定が改善するというのは反直感的です。考えられる説明はこうです。Pre-fix で thinking が回ると、Gemini は内部で「条文に違反規定がない → 違反として扱う根拠がない → 違反ではない → 合法」という三段論法を組み立て、その結論を judgement フィールドに焼き込んでしまっていました。Post-fix の thinking なしでは、表層的に「条文範囲外」というシグナルだけ拾い、judgement を「違反」または「判定不能」と慎重側に倒します。思考時間を与えたほうが、与えないより悪い判断をする ケース。これはハイブリッドの設計と Layer 2 の自律的推論が衝突する例で、シリーズ通じて一番面白かった観察です。退化側：Claude Sonnet が TC-002 を取りこぼした逆方向に倒れた機種が一つあります。Claude Sonnet 4.6 の TC-002「成人 30 歳が標識のない歩道」。Pre-fix Sonnet の判定：違反（reasoning も整合：第63条の4第1項の三号列挙からどれにも該当しない）Post-fix Sonnet の判定：合法（reasoning は「条文上の許可根拠を欠く」と書きつつ、judgement だけ「合法」）reasoning と最終判定が矛盾しているので、フィールドレベルの整合性が崩れたとも言えます。adaptive thinking を撤廃した結果、Sonnet が長文 reasoning の途中で「許可根拠を欠く」と論理を積み上げたあと、最終フィールドに焼き込む段階で「反則金データに該当金額がない → 違反として確定できない → 合法」とジャンプしてしまったように見えます。Pro/Flash が Pre-fix で起こしていた「合法ジャンプ」が、Sonnet では Post-fix で出るようになった、という形。thinking がオンだと長文 reasoning とフィールド出力の整合性は保たれるが、オフだと最終フィールドが reasoning から離れる、という挙動差が Claude では出る、ということだと思います。Opus 4.7 ではこの事故は起きておらず（同じ TC-002 で「違反」と正しく返した）、ここは Opus と Sonnet で adaptive thinking 撤廃の影響度が分かれた点です。全体で見ると：完全 ✓ は不動、judgement レベルで小さな揺れ5 機種を並べてみての全体観です。 観点  結果  完全 ✓ 正答数  5 機種すべて変動なし（Layer 1 が天井）  judgement 誤り (本質✗)  Gemini 系で 2 件改善、Sonnet で 1 件退化、Opus/Gemma3 横ばい  reasoning の質  全機種で短くなった（thinking が消えた分）  ユーザ体験  全機種で改善（特に Flash / Pro / Sonnet） 正答数だけ見ると不動、judgement の倒れ方を見ると微妙にトレードオフ、というのが実態です。「精度ゼロ犠牲で 70〜85% 速くなった」と書くのは大筋では正しいですが、Sonnet TC-002 のような小さな退化が出る可能性はあります。学んだことこのシリーズ全体を通して、最初は「Layer 1 を Layer 2 にどう渡すか」が論点でしたが、今回の高速化編で 「Layer 1 と Layer 2 の責任分界をどこに引くか」 という設計の話に降りてきた気がします。Layer 1 で根拠を完全に渡しているなら、Layer 2 の thinking は自動的に冗長になる。 思考のための情報を後段に追加で取りに行く余地がないため、思考時間は整形を遅らせるだけです。デフォルトの thinking_budget（Gemini）/ adaptive thinking（Anthropic）はクライアント側で明示オフにする値。 プロバイダ側のデフォルトは「LLM 単体で論理推論させる」ユースケースを想定しているので、ハイブリッドではオプトアウトする側になる、というのは設計の知見として持っておきたい点です。本番経路で実測しないとレイテンシ支配項は分からない。 今回 Layer 1 が 3.3ms（全体の 0.1%）と分かったのは、scripts/profile_hybrid.py で本番経路を踏ませてからでした。コンポーネントを単独で測ると見落とします。思考時間と判定精度は単調じゃない。 TC-003 で Gemini Flash/Pro が「思考オフのほうが正しい」結論に倒れたのは、思考が長くなるほど LLM が独自の三段論法を組み立てて結論を歪める例でした。ハイブリッド構成では、Layer 2 に「考えるな、整形しろ」と要求するほうが安全側です。同じ撤廃で全機種が同じ方向に動くわけではない。 Sonnet が TC-002 で退化したのは、Layer 1 が穴を開けたケースではなく、むしろ Layer 1 がちゃんと条文を渡せているのに最終フィールドに焼き込む段で揺らいだ事故です。adaptive thinking 撤廃の影響度が Sonnet と Opus で割れたのも、ベンダー内のモデル差として面白い観測でした。留保数字を扱う以上、いくつか正直に書いておきたい留保があります。「Flash 105× 高速化」は best-case の単発値です。 PR コミットメッセージの数字は短い 3 クエリでの計測。実運用相当の 7 ケース通しでは平均 21 秒（最大 47 秒）まで残っています。ベンチマーク上では 77% 削減、最悪ケースで 84%、というのが実態に近いです。Gemma3 の 52% 削減は、thinking 撤廃の効果ではない可能性が高いです。 Ollama サーバ側の負荷変動の混入か、ベンチ実行のばらつきだと思っています。ここは差分として参考程度に。7 ケースでは精度差を見切れないのは前回どおりです。 Sonnet の TC-002 退化が「thinking 撤廃の影響」か「同条件で 2 回回したら 1 回は外す揺らぎ」かは、本来は数十回繰り返さないと分離できません。thinking を切るのが正解なのはハイブリッド構成だから、です。 LLM 単体で法令判定をさせる経路（--benchmark）では Pre-fix の挙動のままにしてあります。Layer 1 がないなら、Layer 2 は自分で考えるしかありません。結論決定論で根拠を取り切れている範囲では、LLM の推論は不要。ハイブリッド構成における Layer 2 の thinking は冗長で、明示的に切るほうがレイテンシが 70〜85% 縮み、正答数は動かず、judgement の倒れ方は機種により小さく改善 / 退化する。「2008 年の卒論コードが 2026 年の LLM の尻拭いをする」というタイトル一発ネタで始まったシリーズも、ここまで来ると「卒論で根拠を取り切っているなら LLM は考えなくていい」という、もうちょっと真面目な設計指針に落ちました。次の課題はやはり 2 つ残っています。1 つは Layer 1 の TF-IDF を意味埋め込みに置き換えて TC-003「ながらスマホ」の取りこぼしを救うこと。もう 1 つはテストケースを 7 → 数十〜100 のオーダーに拡張して、今回の Sonnet TC-002 退化が再現するかを確かめること。後者はそのまま回帰テストにもなりそうです。読んでいただきありがとうございました。シリーズで一番地味で実装寄りの回でしたが、ハイブリッド構成を運用に乗せる前に踏みたい一段ではあったので、書き残しておきます。決定論で塗れる範囲をどこまで広げられるか、その外側にだけ LLM を置く — というのが、5 編書いて最後に残った設計指針でした。そして「完結編」と銘打った直後にこうして続編を書くことになったわけですが、ベンチマークは公開して晒すと自分で見落としていた穴に気づける、というのが今回の副次的な学びでした。次こそ完結編、とはもう書かないことにします。↓ソースコードはこちらgithub.com

続・完結編 — 「完結」と書いた翌週に Layer 2 の thinking を切ったら 5 機種ハイブリッドが 70〜85% 速くなって、正答率はほぼ動かなかった話

https://genai-users.connpass.com/event/391381/複雑な例外規定や、政令・省令への外部参照（ポインタ）が張り巡らされた法規の解析は、確率論で動くLLM単体では「最も失敗しやすい」領域の一つです。本セッションでは、「古典NLP（決定論）」と「生成AI（確率論）」を垂直統合したハイブリッド判定エンジンの設計思想とソースコードを徹底解説します。【こんな方におすすめ】生成AI（LLM）のハルシネーション対策に苦労しているエンジニアRAG（検索拡張生成）の精度が上がらず、構造的な解決策を探している方法律や規約など「1文字の揺らぎも許されない」ドメインでのAI活用に興味がある方「最新のAIさえあれば古い技術は不要」という風潮に一石を投じたい方【学べること】法的効力の5層スタック： 憲法から条例までをITインフラとして解釈する視点決定論的ガードレール： TF-IDFとコサイン類似度を用いた、揺るがない根拠の引き当て方リーガル・コンパイラ： 法令XMLから論理フラグ（例外・準用）を抽出する前処理技術プロンプト注入の極意： LLMの推論空間を物理的に制限し、論理推論マシンとしてのみ機能させる方法

決定論 vs 確率論：Gemini 3 FlashとTF-IDFを組み合わせた「法規判定エンジン」の構築

完結編・Anthropic Claude (Sonnet 4.6 / Opus 4.7) を加えて、5機種で自転車青切符ベンチマークを総括する

はじめに前々回（Flash編で Gemini 3 Flash 単体は 5/7、卒論ロジック（条文AST + TF-IDF cos類似度）を前段に挟むと 6/7 まで上がる、という結果を書きました。前回（Pro編では Gemini 3.1 Pro でも単体 5/7 で頭打ち、最後の一歩で同じ方向に倒れる、という観測でした。そこで今回は方向を逆に振って、ローカルで動く小型モデルでどうなるかを試しました。クラウドの Gemini に投げる前に、手元の Mac で完結する構成は実務上ありえます。法令 RAG の前処理を全部ローカルでやりたい、API キーを配布したくない、機微情報を社外に出したくない、というニーズです。選んだのは Google Gemma 3 の 4B 量子化版（gemma3:4b、Ollama 経由、3.3GB）です。Apple Silicon の 16GB クラスのメモリでも余裕で回ります。結論から書くと、単体 0/7、ハイブリッドでも条文を注入されても結論を逆向きに解釈する事例が出ました。Flash/Pro とは違う「壁」がここにあります。実験条件モデル: gemma3:4b（量子化 Q4_0、Ollama 経由）実行環境: Apple Silicon（ローカル推論、ネットワーク不要）テストケース: 前々回・前回と同じ 7 問プロンプト: 前々回と完全同一。ハイブリッド側のシステムプロンプトも一切変えていません温度: 0.0平均レイテンシ: 単体 約 13〜33 秒、ハイブリッド 約 23〜48 秒実装は既存のベンチマークスクリプトに --model gemma3 スイッチを足すだけで動くようにしました。get_llm_client(model) がモデル名を見て Vertex AI の Gemini クライアントと Ollama アダプタを切り替えます。python -m src.main --benchmark --model gemma3python -m src.main --hybrid --model gemma3結果サマリ 指標  Flash  Pro  gemma3:4b  単体正答率  5/7 (71%)  5/7 (71%)  0/7 (0%)  ハイブリッド正答率  6/7 (86%)  （未計測）  2/7（条文番号一致のみ）  単体ハルシネーション検知  0/7  0/7  1/7（明示検知）  平均応答時間（単体）  約 7〜9 秒  約 13〜22 秒  約 13〜33 秒 ハイブリッドの「2/7」というのは、機械判定の substring match 基準で見たときの数字です。実質的には条文の意味を取り違えたまま運良く番号と金額が一致した、というケースを含みます。単体（gemma3:4b 丸投げ）で何が起きたか7 問とも「違反」と即答し、しかも条文番号と反則金額をことごとく捏造しました。Flash / Pro が踏み外さなかった「条文ネットワークの形」のレベルから、すでにずれていました。TC-001「75歳の高齢者が普通自転車で歩道を走行」期待される正解は「合法、第63条の4第1項第2号、施行令第26条で 70歳以上は許される」。gemma3:4b の回答:{  "judgement": "違反",  "article": "道路交通法第12条第1項、第19条第1項、第22条第1項",  "fine": "3,000円",  "reasoning": "75歳の高齢者であっても、普通自転車の歩道走行は、道路交通法第12条第1項において、歩行者用道区分にある道路における自転車の通行を禁止しています。…"}第12条・第19条・第22条という条番号が並んでいますが、これらは自転車の歩道通行を直接規律する条文ではありません。「歩行者用道区分」という用語も条文には存在しません。条文ネットワークが完全に作話で構成されています。Flash や Pro は少なくとも第63条の4を引いてきたうえで階層を読み損ねていました。gemma3:4b はその一段手前の「正しい条番号にたどり着く」が落ちていました。TC-005「自転車で酒気帯び運転」期待される正解は「反則金対象外（刑事罰）」。gemma3:4b の回答:{  "judgement": "違反",  "article": "道路交通法第73条の32、第73条の33",  "fine": "10万円以上",  "reasoning": "… 反則金は10万円以上が科せられます。"}第73条の32 や 第73条の33 という条文は道路交通法に存在しません。「10万円以上の反則金」という記述も、青切符制度の上限（12,000円）を大きく超えており、根拠となるものはありません。Flash 編で観測した「数値捏造」が、桁が違う形でフルスケールに出ています。Flash や Pro は青切符の枠（3,000〜12,000円）を踏み外さなかったのに対して、gemma3:4b はその制度の枠そのものから外れた数字を作ります。TC-003「自転車でスマホを手に持って運転」期待: 第71条第5号の5、反則金 12,000円。gemma3:4b: 第71条の3・第71条の4、反則金 3万円（青切符制度の枠外）。ここでも、条文番号も金額も全部作話です。単体結果のまとめ7 問すべてが「違反」判定で、反則金は 3,000円・3万円・10万円以上 が混在しました。条番号は実在しないものや、別の規律対象に属するものばかりが出ました。「LLM はわからないとは言わない」という Flash 編の観測は、gemma3:4b ではより極端な形で再現されました。確信度の表明と回答の正しさが完全に切れている状態です。ハイブリッド（Layer 1 注入あり）で何が起きたかここからが今回いちばん書きたかった話です。Layer 1 は前々回と同じ動作をします。e-Gov XMLをパースして条文ASTを構築し、TF-IDF + cos類似度で関連条文を引き、反則金テーブルから該当する金額を引いて、「政令で定める者」のような委任規定を解決した情報をプロンプトに注入します。ところが gemma3:4b は、この注入された情報を読みながら、結論を反対に倒すケースが複数出ました。TC-004「10歳の児童が普通自転車で歩道を走行」期待される正解は「合法、第63条の4第1項第2号、児童は歩道通行が認められる」。Layer 1 はちゃんと仕事をしています。プロンプトには次のような委任規定の解決済み情報が入っていました。【委任規定の解決済み情報】道路交通法施行令第26条により、第63条の4第1項第2号の「政令で定める者」は以下のとおり:  一　児童（6歳以上13歳未満）及び幼児（6歳未満）  二　七十歳以上の者  三　身体に障害を有する者で政令で定めるもの10歳児童は「政令で定める者」に該当し、歩道通行が許されるという確定情報が、文字列として目の前にあります。gemma3:4b の回答:{  "judgement": "違反",  "article": "第六十三条の四 第二号",  "fine": "3,000円",  "reasoning": "10歳の児童が普通自転車で歩道を走行しているという状況は、第六十三条の四の二号に該当します。  この条文では、普通自転車の運転者が児童、幼児等を理由に歩道を通行できると規定しており、  政令で定める者（この場合は10歳の児童）であるため、歩道を走行していることは違反となります。"}「歩道通行が認められる」と書いてある条文を、「だから違反」と結論しています。論理が完全に反転しています。reasoning の中で「歩道を通行できると規定しており」と正しく要約しているのに、その同じ文の続きで「であるため違反となる」と接続しているのです。人間がコードレビューで「これは反対の結論です」と止めるところを、gemma3:4b は止めません。注入された事実を読み、要約までできているのに、その事実から結論を導く一歩で論理を取り違えます。TC-001「75歳の高齢者が歩道を走行」期待される正解は前述のとおり「合法」。Layer 1 が同じ委任規定（70歳以上は OK）を注入しています。gemma3:4b の回答:{  "judgement": "違反",  "article": "第六十三条の四 第2項",  "reasoning": "75歳の高齢者が普通自転車で歩道を走行している場合、第六十三条の四第2項において、  警察官等が歩行者の安全を確保するため必要があると認めて当該歩道を通行してはならない旨を  指示した場合は、この限りでない。しかし、この質問では、警察官等が…指示しているという記述がない  ため、第七十三条の四第2項に基づいて違反と判断される。"}第63条の4第2項（歩道徐行義務）を持ち出して、「警察官の指示がない＝違反」と推論しています。これは条文の意味の取り違えです。さらに最後に 「第七十三条の四第2項」 という、また別の架空の条文が出てきます。第1項の例外規定（70歳以上は通行可）を完全に無視し、第2項の徐行義務まで内容を取り違えるという、二段重ねのミスです。Layer 1 が"完全に"効いたのは TC-006・TC-007 だけ逆に言うと、ハイブリッドで結論まで合ったのは次の 2 ケースだけです。TC-006（歩道徐行違反、3,000円）: Layer 1 が第63条の4第2項を引き、反則金 3,000円も注入。gemma3:4b はこれをそのまま反復。TC-007（信号無視、6,000円）: Layer 1 が第7条と反則金 6,000円を注入。gemma3:4b は素直に従う。この 2 ケースに共通するのは、問いの構造がシンプルで、例外規定の階層を辿る必要がないことです。「やったら違反、反則金は X 円」という単線的な問いには答えられます。逆に、「原則→例外→例外の例外」という条文の木構造を降りる必要があるケース（TC-001, TC-002, TC-004）では、Layer 1 が階層情報を整形して注入しても、gemma3:4b はその階層を保持できません。何が起きているのか整理すると、gemma3:4b で観測されたのはおそらく以下です。モデル容量のしきい値を切った。Flash/Pro が踏み外さなかった「条文ネットワークの形」のレベルから、4B クラスでは保てない。指示追従が弱い。「以下の条文データのみを根拠にせよ」と書いてあっても、自分の事前学習の確率分布に引きずられる。論理結合子の扱いが脆い。「政令で定める者は通行できる」を読んでも、「である場合 ⇒ 違反」と接続してしまう。文の意味は取れているのに、命題論理レベルで反対に倒れる。特に 3 が今回いちばん不気味でした。前回の Pro 編で、Pro は階層を「読めているのに最後の一歩で揺らぐ」と書きました。gemma3:4b の場合は、読めているのに最後の一歩で逆向きに倒れるところまでが揺らぎの幅です。ハイブリッドの限界とその先Flash/Pro でハイブリッドが効いたのは、注入された条文を「LLM が誠実に使う」という前提が成り立つからでした。gemma3:4b ではこの前提が部分的に崩れます。注入された条文を読みはするが、結論への接続は確率的生成の揺らぎに支配される。Layer 1 で完全に詰めきれるか、Layer 2 にまだ「最後の一歩」を残すかで、許容できるモデル容量が変わるということです。具体的に効きそうな打ち手は次のあたりです。Layer 1 で judgement まで先に決める。LLM には reasoning の文章化だけ任せ、合法/違反の二値判定は決定論側で確定させる。これは前々回の TC-003（NLP が条文を引き損ねたケース）の対策とは方向が逆で、「LLM に判断を委ねる範囲をさらに狭くする」という方針です。モデル容量を上げる。gemma3 ならば 12B か 27B、あるいは Llama 3.3 70B 系の量子化版に置き換えると、指示追従と論理結合の安定性は明確に上がるはずです。Apple Silicon で量子化版なら 12B はギリギリ実用、27B でも MLX 経由で動く範囲です。JSON スキーマ拘束。Ollama でも format=json や JSON Schema 制約をかければ、最低限の構造ミスは減ります。今回はあえてベンチマーク条件を Flash/Pro と揃えるためにかけませんでしたが、実用ではこの一手は効きます。所感今回 gemma3:4b を回してみて、改めて感じたのは次の点です。「ローカルで動く LLM ＋ 卒論ロジック」が万能ではない。決定論的前処理は、最後の推論を担う LLM がある程度賢いことを前提にしています。容量が下がりすぎると、注入された事実を反対に解釈する事例まで出ます。失敗の「形」がモデルクラスでまったく違う。Flash/Pro の失敗は階層の最後の一段で揺らぐ「丁寧な誤り」、gemma3:4b の失敗は条文ネットワーク自体を作話する「乱暴な誤り」。同じベンチマークでも観測される現象が層的に違います。ローカル運用には別設計が要る。クラウド Gemini を前提にした「Layer 1 で根拠を限定して注入、判定は LLM」アーキテクチャを、そのまま 4B クラスのローカル LLM に持っていっても期待した精度は出ません。「Layer 1 でほぼすべて決定し、LLM は説明文だけ書かせる」くらいに役割分担を変える必要があります。2008年の卒論ロジックは、それでもまだ足腰として効いている。TC-006・TC-007 のように単線的な問いでは、Layer 1 が引いた条文と反則金を gemma3:4b は素直に反復します。正解できたケースの正答性は Layer 1 が保証している、という見え方になりました。「ローカル小型モデルなら勝てるのか」という仮説は、少なくとも今回のベンチマークでは棄却されました。ただし、これは gemma3:4b というモデルクラスへの否定ではなく、モデルクラスごとに「卒論ロジックに何を任せるか」の設計を変えなければいけない、という観測です。Flash/Pro で効いた構成をローカルにそのまま持ってこられない、というだけのことで、Layer 1 側にもう一段の役割を持たせれば、4B クラスでも実用領域に乗せられる可能性は残っています。次の課題は、Layer 1 で judgement を決定論的に出すところまで踏み込むこと、それと gemma3:12b / 27b でクラスを上げたときに失敗の「形」がどこまで Flash 寄りに戻るかを見ることです。読んでいただきありがとうございました。「ローカルなら勝てるのか問題」への今回の回答は、「4B クラスでは負けたが、卒論はまだ最後の砦として効いていた」 でした。

続々・自転車の青切符、ローカル LLM (gemma3:4b) でやらせたら何が起きたか — 卒論ロジックも防げない壁の話

はじめに前回の記事自転車の青切符、生成AIに聞いたら間違えた話 — 2008年度の卒論に救われましたでは、Gemini 3 Flash に道路交通法を丸投げすると 5/7（71%）しか当たらず、2008年度の卒論で書いた決定論的 NLP（条文AST + TF-IDF + コサイン類似度）を前段に挟むとハイブリッドで 6/7（86%）まで持ち上がる、という検証結果を書きましたが、Gemini-3-Flashではなく、Pro なら正解数が上がるのかという疑問が湧きました。そこで今回は、同じベンチマークをそのまま Gemini 3.1 Pro（gemini-3.1-pro-preview）に差し替えて回してみました。結論から書くと、正答率は同じ 5/7（71%）で、Flash から改善しませんでした。 ただし「間違い方」には Pro らしい特徴が出ていたので、そこを中心に書きます。実験条件モデル: gemini-3.1-pro-previewテストケース: 前回と同一の7問（自転車×歩道、スマホ、酒気帯び、信号無視 ほか）プロンプト: 完全に同一。法規文は注入せず、LLMの内部知識だけに頼らせる「丸投げ」構成温度: 0.0Layer 1（卒論側）の前処理は なし（Pro単体の素の実力を見たかったため）既存のベンチマークスクリプトに --model スイッチを足しただけの修正で動きます（python -m src.main --benchmark --model pro）。結果サマリ 指標  Flash  Pro  正答率  5/7 (71%)  5/7 (71%)  失敗ケース  TC-002, TC-005  TC-002, TC-005  平均応答時間  約 7〜9 秒  約 13〜22 秒  ハルシネーション検知（機械判定）  0/7  0/7 正答率もハルシネーション検知数も同じ、失敗ケースまで同じです。違うのはレイテンシだけで、Pro のほうが約2倍遅くなりました。「Pro に変えれば正解する」は、少なくとも今回のタスクでは成立しませんでした。ここが違った：Proは「構造」はちゃんと読んでいたただし、「同じ間違え方」ではありません。Pro のほうが明らかに推論の建て付けが丁寧で、前回 Flash が完全に潰していた階層構造を、Pro は reasoning フィールドの中ではきちんと再現していました。TC-002「成人が標識のない歩道を走行」前回、Flashはここで「違反、6,000円」と即答し、第63条の4第1項第3号の「やむを得ない場合」の例外には触れませんでした。階層の潰し方が露骨でした。Pro の回答はこうなりました。{  "judgement": "違反",  "article": "道路交通法第17条第1項、第63条の4第1項",  "fine": "6,000円（道路交通法第125条第3項の委任に基づく道路交通法施行令により規定）",  "reasoning": "… 例外として普通自転車が歩道を通行できるのは、    ① 『自転車通行可』の道路標識等がある場合、    ② 運転者が13歳未満の児童・幼児、70歳以上の高齢者、または身体障害者等である場合、    ③ 車道等の状況に …"}③の「車道の状況に……やむを得ない場合」までちゃんと列挙できています。第125条第3項（反則金額の政令委任）にも自分から言及しているあたり、条文のネットワーク構造は Pro の頭の中にはあります。ところが最終的な judgement は「違反」で、Flash と同じ結論に着地しました。構造は読めている、例外条件も知っている、でも「この30歳というシナリオに③を適用すべきか」という判断のところで、Flash と同じ方向に倒れました。これは面白い現象で、推論の「途中式」は正しいのに、最後の丸め方が統計的なバイアスに引っ張られているように見えます。Pro にすれば語彙や条文ネットワークの知識量は増えるが、「確率的生成の最後の一歩」は同じ揺らぎを持っているということだと思います。TC-005「自転車で酒気帯び運転」こちらは評価スクリプト側の機械判定が意地悪だったパターンです。Pro の回答:{  "judgement": "違反",  "article": "道路交通法第65条第1項、第117条の2の2第11号、第125条第1項、道路交通法施行令第44条の3",  "fine": "反則金対象外（刑事罰の対象）",  "reasoning": "… 2026年4月1日施行の自転車交通反則通告制度（青切符制度）において、    酒気帯び運転は道路交通法第125条第1項の規定により反則行為から明確に除外されているため、    反則金（青切符）の対象外となります。"}内容としては完全に正解です。第65条も第117条の2の2も挙がっていますし、「反則金対象外、刑事罰」という本質も外していません。ところが評価スクリプトは、期待条文 第65条、第117条の2の2 を Pro の article フィールドに 連続した部分文字列として 探しにいきます。Pro の出力には 第65条第1項、第117条の2の2第11号 と、間に「第1項」が挟まっているので部分一致に失敗し、機械判定としては「✗」になりました。ここは Pro が悪いというより、「条文が正しく引けているか」を単純な substring match で測るアプローチの限界です。Pro のほうが情報量の多い回答をする分、こういうマッチャーに引っかかりやすい側面があります。この観測は、次に Layer 1 のマッチャー側を見直すときの良い材料になりました。レイテンシとコストの話実務上、見過ごせないのが応答時間です。Flash: 1ケースあたり約 7〜9 秒Pro: 1ケースあたり約 13〜22 秒（TC-003 は 21.8 秒）2〜3倍の遅延があって、正答率は同じ、という状態でした。法務アシスタント用途でこの差を飲むのは厳しく、特にチャット UI のようにリアルタイム応答が求められる場面では Flash を選ぶ合理性が強まりました。コスト面も、Pro は Flash より単価が高いモデルです。同じ精度なら安くて速いほうを選ぶという、当たり前の結論になりました。結局、ハイブリッドのほうが効く前回の記事で書いたとおり、Flash + 決定論的NLP（Layer 1）で 6/7（86%） まで上がります。今回の Pro 単体は 5/7（71%）。差分は1問ですが、これは「失敗パターンの性質」がまったく違います。Pro 単体の失敗は、確率的生成の最後の一歩で階層が潰れるタイプの誤り。プロンプトやモデルをチューニングしても、同じ方向に倒れやすい。ハイブリッドの唯一の失敗（TC-003）は、TF-IDF が口語クエリと法令文体の語彙ギャップに負けたタイプの誤り。Sentence-BERT などの意味埋め込みで補強すれば直る見込みがある。前者は根治が難しく、後者は根治できる という違いがあります。この1問差は数字以上に大きいと思っています。そして何より、ハイブリッドの強みは「根拠が注入されている限り、LLM は勝手に条文を捏造しない」ところです。Pro に上げてもこの性質は手に入りません。丸投げしている限り、モデルは自分の確率分布の中で一番もっともらしい答えを出力してしまいます。所感今回 Pro を回してみて、改めて感じたのは次の点です。モデルを上げれば精度が上がる、は常に真ではない。 今回のような「条文の階層を正確に降りる」タスクでは、Flash と Pro は同じ壁にぶつかりました。Pro のほうが途中式は丁寧に書く。 reasoning フィールドに出てくる法令ネットワークの網羅性は明らかに Pro が上で、知識量の差は見えます。ただしそれが最終判定に反映されるとは限りません。実用のスイートスポットは Flash + 決定論的前処理のまま。 精度・速度・コストのバランスで、Pro に差し替える合理性は今回のベンチマークでは見つかりませんでした。評価スクリプトも一緒に鍛える必要がある。 Pro のほうが情報量の多い回答をする分、素朴な substring match では正解を取りこぼします。マッチャー側のアップデートは別途の宿題です。「Pro ならそのまま正解する」という仮説は、少なくともこのベンチマークでは棄却されました。逆に言うと、2008年の卒論ロジックが効いているのは Flash だからではなく、LLM 全般の「最後の一歩で揺らぐ」性質に対してである、ということが今回の Pro 実験で裏取りできた形です。Pro に対しても同じ前処理を足せば、さらに精度は上がる見込みが高いです（Pro × ハイブリッドの検証は次の課題として残しました）。読んでいただきありがとうございました。「Pro に上げれば勝てるのか問題」への今回の回答は、「単体では勝てなかった。卒論はまだ現役」 でした。

続・自転車の青切符、Proなら勝てるのか — Gemini 3.1 Pro で同じベンチマークを回してみた

はじめに先日Xで「自転車の法律が変わって、生成AIに聞いたら間違っていた」という投稿を見かけました。2026年4月1日に施行された自転車交通反則通告制度（青切符、令和6年法律第34号）のことです。これを見て考えたのは、生成AIが法規を間違えるのは、確率論的な処理だけに任せているからではないか、ということでした。条文番号や反則金額のように「絶対に揺らいではいけない数値」を扱うのであれば、古典的な自然言語処理（NLP）で前処理を挟む必要があると思います。NLPは決定論的で、同じ入力には必ず同じ出力が返ります。NLPとの関わりは古く、神戸大学海事科学部の卒論ではベクトル空間法（VSM）とコサイン類似度を使ってレポート盗作検出を扱いました。大学院は奈良先端科学技術大学院大学情報科学研究科に進み、P2Pと強化学習の研究に軸足を移しましたが、日本の自然言語処理の聖地である松本研の授業を受けるなど、NLPの知見はありました。そこで今回、検証用のプロトタイプを書いてみました。システム構成仕組みは2層構成です。Layer 1（2008年式）: e-Gov法令XMLをパースして条文ASTを構築し、TF-IDFとコサイン類似度でクエリに関連する条文を決定論的に引き当てます。「ただし」「……を除く」「政令で定める」などの論理フラグを抽出し、例外規定の階層構造を保持します。Layer 2（2026年式）: Gemini 3 FlashにLayer 1が確定させた条文と反則金テーブルを「絶対的根拠」としてプロンプトに注入します。推論の脱走を物理的に封じる作りです。対象法令は道路交通法（昭和35年法律第105号）、施行日は2026年4月1日、対象は16歳以上の自転車運転者、違反113種類、反則金3,000〜12,000円です。テストケースは7問用意し、「Flash単体」と「ハイブリッド」で突き合わせました。Flash単体が間違えたところ正答率は 5/7（71%） でした。典型的な失敗が2種類観測されました。失敗1：条文の階層が平坦化されるTC-002「成人（30歳）が標識のない歩道を走行しました」では、Flashは「違反、反則金6,000円」と即答しました。しかし第63条の4第1項は、歩道通行を許す例外を3つ列挙しています。道路標識等で指定されている場合運転者が児童・幼児・高齢者等である場合道路の状況に照らして安全確保のためやむを得ない場合Flashは回答文の中で (3) を列挙しながらも、判定ではこれを無視して「違反」と断言しました。「原則→例外→例外の例外」という条文の木構造を、Flashは平坦な箇条書きとして読んでしまっています。確率的生成の弱点で、プロンプトをいくら工夫しても揺らぎが残ります。失敗2：存在しない条番号の捏造TC-005「自転車で酒気帯び運転をしました」では、結論は「反則金対象外（刑事罰の対象）」で合っていました。しかし回答文の中に「第117条の2の2第1項第3号」という、現行法と微妙にズレた条番号が紛れ込んでいました。いわゆる 数値捏造（number fabrication） で、法律相談に使うには致命的です。さらに観測上最も重要な点として、Flashは自分のハルシネーションを検知できず、7問すべてで堂々と答えきっていました。「わからない」とは言わないのです。ハイブリッドが間違えたところハイブリッドにすると、正答率は 6/7（86%） に上がりました。ただし1問だけ、Layer 1のNLP側が足を引っ張った事例があります。失敗：TC-003「自転車でスマホを手に持ちながら運転」ハイブリッドの判定は「合法」。完全に外しました。原因は Layer 1 のコサイン類似度検索です。クエリ「スマホを手に持ちながら運転」に対して、TF-IDFが引っ張ってきたのは以下の3条でした。#1 cos=0.1421 → 第六十三条の九 （自転車の制動装置等）#2 cos=0.1135 → 第六十三条の十 （自転車の検査等）#3 cos=0.1126 → 第六十三条の三 （自転車道の通行区分）引くべき条文は 第71条第5号の5（携帯電話使用等） でした。しかし条文の文言は「無線通信のために用いられる装置」のような硬い表現で、「スマホ」という口語とは単語ベースで重なりません。TF-IDFは単語一致の世界ですので、語彙ギャップに弱いです。2008年式の決定論は、揺らがない代わりに融通も利きません。口語クエリと法令文体の意味的な距離を埋めるには、Sentence-BERT などの意味埋め込みを挟む必要がありそうです。Layer 1 のアップデートは別途の課題として残りました。一方で、Layer 1 が正しく引けた残り6ケースでは、Gemini 3 Flash は注入された条文と反則金テーブルを忠実に使い、例外規定の階層まで正しく辿って回答してくれました。TC-005（酒気帯び）でも、Flash単体では出ていた架空の条番号が消え、施行令で解決済みの確定情報だけで回答が構成されました。Gemini 3 Flash を使ってみた所感Layer 2に使ったのは Gemini 3 Flash（gemini-3-flash-preview）です。率直に、精度は良いと感じました。Flash単体でも71%を当てます。ハルシネーションは出すものの、条文の建て付けを概ね把握した上で外しており、「何も知らないから確率で埋めている」のではなく「知っているが階層が潰れている」タイプの誤りでした。これは根治しやすい誤りです。そして決定的だったのは、条文と反則金を根拠としてプロンプトに注入した瞬間、Flashは捏造をやめたことです。注入されたデータの範囲外のことは「該当なし」と正しく言います。TC-003でNLPが間違った条文を渡したときですら、渡された条文の範囲で誠実に「禁止規定はない」と答えました。嘘はつきませんでした。根拠を与えれば、その根拠の中で論理を正しく走らせる。 これをProではなくFlashクラスで実現できているのは、正直驚きでした。速くて軽いモデルなのに、統制下では十分に堅いという印象です。同じプロトタイプをProで回せば精度はもう一段上がるでしょうが、コストとレイテンシを考えると、Flash + 決定論的前処理の組み合わせが実用のスイートスポットだと思います。最後に今回の検証でわかったことをまとめます。LLM単体に法律判定を丸投げすると、例外の階層を平坦化し、存在しない条番号を捏造します。決定論的NLP（条文AST + cos類似度）で前処理して根拠を注入すると、LLMの暴走は物理的に封じられます。ただしTF-IDFは語彙ギャップに弱く、口語クエリでは的外れな条文を引くことがあります。ここは意味埋め込みで補強するのが次の課題です。Gemini 3 Flash は、根拠を与えたときの素直さと推論の堅さが印象的でした。速さと精度のバランスが良く、実用のスイートスポットを突いています。2008年度に卒論で書いたコードが、2026年の生成AIの尻拭いをしてくれる、という体験になりました。技術は積み上がるものだと改めて感じます。お読みいただきありがとうございました。ソースコードはこちらgithub.com

自転車の青切符、生成AIに聞いたら間違えた話を2008年度の卒論で工夫

https://event.ospn.jp/osc2026-spring/session/2261838AIが私たちの代わりに考えて動く「AIエージェント」が当たり前になる未来、AI同士が自ら協力し、サービスをやり取りする『AI同士の経済圏（エージェント・エコノミー）』が生まれようとしています。AI同士をスムーズにつなぐための「共通のルール（MCPやA2A）」によって、ビジネスがどう進化するのかを展望します。特定のベンダーに縛られず、AIが互いの「名刺（得意なこと）」を確認して自由に助け合う新しい仕組みや、AIが社会を支えるインフラとして溶け込んでいくための課題と可能性について、専門用語を噛み砕いて分かりやすく解説します。

AIエージェント・エコノミーの幕開け 〜 オープンプロトコルが変えるビジネスの未来 〜

日本生成AIユーザ会勉強会とOSC東京での発表資料ですhttps://genai-users.connpass.com/event/385720/https://genai-users.connpass.com/event/385342/

AIエージェント・エコノミーの幕開け 〜オープンプロトコルが変えるビジネスの未来〜

https://genai-users.connpass.com/event/381737/日本生成AIユーザ会第20回勉強会Google Cloudでの動画解析と検索のサービス紹介と比較 〜Video Intelligence, Vision Warehouse, Gemini + Vertex AI Search〜動画コンテンツの爆発的な増加に伴い、「何が映っているか」を抽出するだけでなく、「特定のシーンをいかに高度に検索するか」というニーズが急増しています。本セッションでは、Google Cloud が提供する動画解析・検索ソリューションを網羅的に解説します。具体的には、長年の実績がある Video Intelligence API、大規模なメディア管理と画像・テキストによる横断検索を実現する Vision Warehouse、そしてマルチモーダル LLM Gemini と Vertex AI Search を組み合わせた動画 RAG アーキテクチャを紹介します。生成AIの進化により、従来のモデルでは困難だった「動画の文脈理解」や「自然言語による詳細なシーン特定」がどのように容易になったのか、デモを交えて解き明かします。各サービスのアーキテクチャやコスト、精度、ユースケースを徹底比較し、ビジネス課題に最適なサービス選定の指針を提示します。

Google Cloudでの動画解析と検索のサービス紹介と比較

この記事はQiita 3-shake Advent Calendar 2025 シリーズ1日目の記事です。2025年11月22日(土)に、Google Developer Group - DevFest Tokyo 2025があり、その招待制懇親会でLTをさせていただく機会がありました。「学術的根拠から読み解くNotebookLMの音声活用法」というタイトルで、NotebookLMの音声解説で学習する際のポイントを過去のマルチメディア学習の学術的根拠や実験を基にまとめました。 speakerdeck.com1ページずつ解説をさせていただきたいと思います。1枚目1枚目は表紙です2枚目2枚目は自己紹介です。3枚目Notebookでの音声を作る操作方法です。画面にドキュメントなどをアップロードし、音声解説ボタンを押すだけで簡単に作れます。音声は、男女掛け合いのPodcast形式です。4枚目仕事や学業で、難解なドキュメントを読む場面は多々あると思いますが、NotebookLMの音声解説機能により、学習効率が高められるか期待が高まっています。AIによって作られた音声がどれだけ学習効果があるか過去のマルチメディア学習の学術的根拠実験を基に解説していきます。5枚目学習効果を測定する実験も行いました。とある専門的なドキュメントを音声化して実験に用いました。被験者は熟達者（エキスパート）と初学者のグループに分かれます。熟達者、初学者でそれぞれ、音声の元となったドキュメントのみ読んで学習したグループ、音声のみ聴いて学習したグループ、両方を用いたグループに分かれ、学習後に4択の理解度チェックテストを受けてもらいました。GoogleスライドをPDF化して文字が崩れているので、直せるなら直しておきます。6枚目ドキュメント・音声の両方を用いたグループが優位に思えましたが、結果はご覧の通り。初学者は、実験を1回のみ行い、両方 > 音声のみ > ドキュメントのみ、という期待通りの結果でしたが、熟達者は、実験を3回行い、両方グループが最高点を取るとは限りませんでした。なぜ、熟達者は両方グループが優位とは限らなかったのでしょうか？7枚目初学者の説明です。初学者は音声学習を順書立てて勉強するのが有効です。構造的ガイダンスを提供することを足場かけ理論といいます。また、初学者の両方グループは音声を主、ドキュメントを従（文章を読むより、俯瞰的に見る）ことにより、認知負荷分散につながりました。8枚目一方の熟達者の説明です。熟達者は、初学者に有効な順序立てた構造的ガイダンスが邪魔になることがあります。熟達者の知識ネットワークに対して、手厚い構造的ガイダンスが知識をマッピングするのが非常に認知負荷が高いためです。これを熟達化のリバーサル効果といいます。また、熟達者の両方群は音声とドキュメント両方から情報を得ようと頑張り、認知負荷が高い状態でした。9枚目実験の制約により、不利な面もありました。実験の時間の都合上、音声の一時停止、巻き戻しを禁止していました。音声を一時停止、巻き戻して、自分のペースで聴けるなら、熟達者の両方グループは、音声とドキュメント両方からしっかり情報を取れていた可能性があります。学習者のペースを守らせることが効率を上げるのですが、例えば、音声や動画の学習をする際、数分ごとに区切って、学習者が「次へ」を押すことで次のパートが始まると学習がしやすいです。このことを「セグメンテーション原理」と呼ぶのですが、実験の制約上、阻害されたことになります。また、熟達者の実験の中で、音声のみグループの平均点が低いときがありました。それは、グラフ・図を見ていないと難しい問題が多く、音声でグラフ・図など視覚的な情報伝達が難しいことを意味します。また、各グループの点数のばらつきでは、ドキュメントのみグループが最も大きかったです。これは当然と言えば当然で、ドキュメント学習は各個人の学習能力に大きく左右されるためです。一方、音声は画一的な指導が可能とも言えます。10枚目実験や学術的根拠から読み解く、音声学習のおすすめとしては、学習者の習熟度を考慮し、初学者は音声とドキュメント両方を併用し、音声を主、ドキュメントを従とするのが良いでしょう。一方、熟達者は各個人で使い分けをするのがよく、概要把握や復習、思い出すなどの目的では音声、詳細や図表の把握はドキュメントを使うのがよく、安易に両方同時に使うと認知負荷を増大させるリスクがあります。11枚目参考文献です。一部、有料のものもありますが、Web検索等で概要を知ることもできます。12枚目終わりましたが、他の勉強会での登壇情報です。2025年11月27日(木)に、Jagu'e'r 月末 Tech Lunchの勉強会「月末 Tech Lunch Online#7 - Google Cloud を語る！-」に「MCP・A2A概要 〜Google Cloudで構築するなら〜」というタイトルで登壇した話は、ブログ記事にまとめていますので、よろしければご覧ください。shu-kob.hateblo.jp最後にqiita.com3-shake Advent Calendar 2025 シリーズ2の1日目はmasasuzuさんが書いてくれています。シリーズ1の2日目はyteraokaさんの「VPC Lattice を理解したい」シリーズ2の2日目はnwiizoさんの「生成AIエージェントによるブログレビュー環境の構築（上）」です。今後もお楽しみに！

学術的根拠から読み解くNotebookLMの音声活用法

この記事はQiita Jagu'e'r Advent Calendar 2025の1日目の記事です。2025年11月27日(木)に、Jagu'e'r 月末 Tech Lunchの勉強会「月末 Tech Lunch Online#7 - Google Cloud を語る！-」に「MCP・A2A概要 〜Google Cloudで構築するなら〜」というタイトルで登壇させていただきましたので、その発表内容でのポイントを記事化したいと思います。AIエージェントが流行っているけど、MCPやA2Aという概念は難しいやろうと思い、噛み砕いて説明したいというのが発表のモチベーションでした。 speakerdeck.comなお、今回の資料は、NotebookLMで作成しました。ここまで作れるのはすごいです！1ページずつ解説をさせていただきたいと思います。1枚目1枚目は表紙です。2枚目2枚目は、アジェンダで、全体の話の流れを書いています。3枚目3枚目は、LLMの制約について述べています。LLMは「Brain in a Jar」（瓶の中の脳）とも言われ、賢いけど、手足を持たなくて実行能力のないものの例えです。例えば、学習時点までの知識しか知りません。これをナレッジカットオフといいます。「今日の株価」「明日の天気」「最新のニュース」などは分かりません。また、旅行のプランをLLMに尋ねても、航空券やホテルの予約はしてくれません。APIなどを操作し、データベースのトランザクション操作をする実行能力はないのです。4枚目ここで、LLMの制約を解決する手段として、MCPの話が出てくるのに加え、さらなる機能拡張のためにA2Aの話が出てきます。MCPはLLMに実行能力を与えます。A2Aはエージェント同士が連携し、より複雑なことができるようになる仕組みです。5枚目MCP(Model Context Protocol)は外部ツールやデータへのアクセスを標準化するプロトコルです。LLMという脳に手足を与えて、検索やAPI操作ができるようになり、APIを介してデータベースのトランザクション操作ができるようになるのです。ここでポイントは、推論機能と実行機能を分離して疎結合に実装するということです。6枚目A2A(Agent-to-Agent)は、AIエージェント同士で、連携するためのプロトコルです。能力を記述したAgent CardがAIエージェントの名刺となり、どのエージェントにどのタスクを任せるかの判断ができます。また、通信プロトコルが定められているため、拡張性に優れています。7枚目MCPとA2Aのご紹介をしましたが、Google CloudでMCPやA2Aをどう構築していくかのポイントに移りましょう。まず、認知（推論）機能と実行機能を分離することクラウドを利用する上で、サーバーレスファーストが大事であること（8枚目で詳説）誰も信頼せずとも動くゼロトラストセキュリティであることです。8枚目Google CloudでのMCPサーバー構築は、Cloud Runを使うのが定石です。サーバーレスでありコスト最適化できます。また、高いスケーラビリティに対応していて、コンテナベースで、デプロイが容易です。9枚目MCPサーバーをCloud Runで構築する際の注意点です。ローカル開発で使うようなstdio（Standard I/O）はCloud Runでは使用できないため、Streamable HTTPかSSE over HTTPを使う必要があります。最近では、新しいStreamable HTTPの方が推奨となっています。10枚目一方、A2A対応のエージェントの構築は、Vertex AI Agent Engineが最適です、フルマネージドサービスで、A2Aのプロトコルに準拠しており、Agent Registoryによるガバナンスも効いています。11枚目A2Aエージェントを構築するためのポイントです。スライドには文言が書いていませんが、ADK(Agent Development Kit)を用いた方法です。AgentCardの定義、使用するLLMやツールの定義、タスク処理のロジックを実装し、これらをA2Agentで統合し、A2A準拠のエージェントを作成できます。12枚目MCPとA2Aを連携させた構築例です。「Social Agent」というのは友人の好みを推論するエージェントです。外部連携、つまり実行部分はMCPを用いて、推論と実行の分離を行います。13枚目簡単にAIエージェントが開発できるようになると、企業内でみんな好き勝手にエージェントを作り始めて、野良エージェントが増えそうですが、Gemini Enterpriseによる一元管理でガバナンスを効かせられます。14枚目MCPもA2Aもオープンプロトコルであるため、拡張性に優れています。インターネットでもTCP/IPというオープンプロトコルのおかげで相互運用性があるように、AIエージェントもどんどん拡張していき、どんどん便利な世の中になるのかもしれません。最後にお読みいただきありがとうございました。2日目のQiita Jagu'e'r Advent Calendar 2025は、pHaya72さん「テクサミの宣伝」です。qiita.com空きもまだありますので、Jagu'e'r 会員の方はぜひ書きましょう！私もできれば、複数記事書きます！

MCP・A2A概要 〜Google Cloudで構築するなら〜

「Jagu'e'r 月末 Tech Lunch Online#7 - Google Cloud を語る！-」にて、AIエージェントのMCPとA2Aの概要と、それらをGoogle Cloudで構築する上でのTipsを紹介させていただきました。https://jaguer-tech-lunch.connpass.com/event/362363/

2025年11月25日の日本生成AIユーザ会「#19 MCP・A2A概要 〜Google Cloudで構築するなら〜」にて発表に使用した資料2部あるうちの後半部分です。https://genai-users.connpass.com/event/376260/↓前半部分はこちらですhttps://speakerdeck.com/shukob/aiezientoru-men-zi-lu-xing-noji-chu-karaopunpurotokorumcpa2aniyorulian-xi-made

AIエージェントの自律性と協調性を解放する Google CloudによるMCP・A2A実装のエンタープライズ戦略

2025年11月25日の日本生成AIユーザ会「#19 MCP・A2A概要 〜Google Cloudで構築するなら〜」にて発表に使用した資料2部あるうちの前半部分です。https://genai-users.connpass.com/event/376260/↓後半部分はこちらですhttps://speakerdeck.com/shukob/20251125-ri-ben-sheng-cheng-aiyusahui-xiao-yuan-part2

AIエージェント入門 自律性の基礎からオープンプロトコルMCP・A2Aによる連携まで

2025年11月22日(土)に開催された「Google Developer Group - DevFest Tokyo 2025」の懇親会LTで発表させていただきました。https://gdg-tokyo.connpass.com/event/369416/NotebookLMで音声解説(Podcast)機能がありますが、初学者と上級者でドキュメントでの学習とどのように使い分けたら学習効率がいいかなどを、実験結果と複数の学術的根拠を元に解説しました。

https://genai-users.connpass.com/event/373059/2025年10月18日、オープンソースカンファレンス2025 Online/Fallで発表した資料です。今話題となっている「AIエージェント」について、要素技術となる生成AIを用いてどのように自律的に動作するのか基礎を説明した後、AIが外部のツールやデータにアクセスするためのオープンプロトコルであるMCP（Model Context Protocol）や、複数のエージェントによる分業と連携を可能にするオープンプロトコルA2A（Agent-to-Agent）について解説しました。

AIエージェント入門 〜基礎からMCP・A2Aまで〜

この記事は#17 Gemini CLI AI駆動開発体験ハンズオン【オンライン】 - connpassの資料です。Gemini CLI AI駆動開発体験ハンズオン🎯 本日のゴールこのハンズオンでは、Googleの強力なAIモデルであるGeminiをターミナルから対話的に利用できるGemini CLIを使い、以下の3つの体験を通じて、日々の開発タスクを劇的に効率化する「AI駆動開発」の第一歩を踏み出すことを目指します。面倒なドキュメント作成の自動化未知のアプリケーションの迅速な立ち上げ対話によるスマートな機能追加🧠 Gemini CLIとは？Gemini CLIは、Googleが公開したオープンソースのAIエージェントです。ターミナル（コマンドライン）から自然言語で指示を出すだけで、まるで優秀なアシスタントがいるかのように、以下のようなタスクをこなします。コードの生成・編集・解説ファイル操作情報検索ワークフローの自動化それでは、早速AIとのペアプログラミングの世界を体験してみましょう！1. 準備a. Node.js (npm) のインストールGemini CLIのインストールに必要です。未インストールの方はVer.20以上をインストールしてください。b. Gemini CLIのインストールと設定ターミナルを開き、以下のコマンドを実行します。# Gemini CLIをインストールnpm install -g @google/gemini-cli# インストールされたことを確認gemini --version以下のようにバージョン情報が表示されればOKです。0.3.2c. 認証設定Gemini-CLIのREADMEを参照github.comターミナルでgeminiと入力すると、対話モードとなります。/quitで退出できます。2. ハンズオン1: ローカルコードを解析してREADME.mdを自動生成まずは、既存のコードからプロジェクトの説明書であるREADME.mdを自動生成させてみましょう。手順1. 作業用ディレクトリの作成と移動mkdir gemini-cli-handson && cd gemini-cli-handson2. サンプルコードの作成簡単なWebサーバーのPythonコードを作成します。main.pyというファイル名で以下の内容を保存してください。touch main.pyimport http.serverimport socketserverPORT = 8000Handler = http.server.SimpleHTTPRequestHandlerwith socketserver.TCPServer(("", PORT), Handler) as httpd:    print("serving at port", PORT)    httpd.serve_forever()main.pyを動かしてくださいなどと入力することで起動させることができます。3. ハンズオン1: GeminiにREADMEの作成を依頼！カレントディレクトリの情報をコンテキスト (-c ) として渡し、READMEの作成を依頼し、> を使ってファイルに保存します。💻 実行するコマンド:gemini -p "このプロジェクトのREADME.mdを日本語で生成してください。プロジェクトの概要、使い方、実行方法を簡潔にまとめてください。" -c  > README.mdls コマンドで README.md ファイルが作成されていることを確認してください。たったこれだけで、プロジェクトのドキュメントが完成しました！4. ハンズオン2: 未知のアプリを動かしてみる次に、GitHubから使い方があまり書かれていないプロジェクトをCloneしてきて、Geminiに起動方法を尋ねて動かしてみましょう。手順サンプルリポジトリのクローンまずは一つ上の階層に戻り、サンプルリポジトリをクローンします。git clone https://github.com/shu-kob/rag-app-handsonREADMEがあるとGeminiがその内容をヒントにしてしまうため、READMEがなくてもどれだけ自力でアプリの構造を理解できるか試すためにREADME.mdを削除します。cd rag-app-handsonrm frontend/README.md backend/README.mdGeminiに起動方法を質問してみます。このディレクトリにはREADME.mdがありません。どうやって動かせばいいか、Geminiに聞いてみましょう。💻 実行するコマンド:gemini -p "このプロジェクトの実行方法を教えて。必要な手順をステップバイステップで説明して。" -c Geminiは ファイルを見て、以下のような実行手順を説明してくれます。5. ハンズオン3: プロンプトを工夫して機能追加最後に、対話を通じてアプリケーションに新しい機能を追加してみましょう。ハンズオン1で作成したPythonのWebサーバーコードを拡張します。手順作業ディレクトリへ移動cd gemini-cli-handson現在のコードを確認cat main.pyで現在のコードを再確認します。これはシンプルなWebサーバー機能しかありません。Geminiに機能追加を依頼！このWebサーバーに、「アクセスすると'Hello, Gemini!'と表示する」機能を追加してもらいましょう。コード全体を書き換えてもらうように依頼するのがポイントです。💻 実行するコマンド:gemini -p "現在のmain.pyを修正して、どのパスにアクセスしても 'Hello, Gemini!' というテキストを返すように変更してください。コード全体を提示してください。" -c main.py生成されたコードでファイルを上書きGeminiが修正版のmain.pyコードを生成します。上書きの指示をしてください。（生成されるコードの例）import http.serverimport socketserverPORT = 8000class MyHandler(http.server.BaseHTTPRequestHandler):    def do_GET(self):        self.send_response(200)        self.send_header('Content-type', 'text/plain; charset=utf-8')        self.end_headers()        self.wfile.write('Hello, Gemini!'.encode('utf-8'))with socketserver.TCPServer(("", PORT), MyHandler) as httpd:    print("serving at port", PORT)    httpd.serve_forever()動作確認変更したWebサーバーを起動し、ブラウザやcurlコマンドで動作を確認します。💻 実行するコマンド (ターミナル):python3 main.pyもしくは、Gemini-CLIで「main.pyを起動してください」と指示します。💻 別のターミナルを開いて実行、またはブラウザで http://localhost:8000 にアクセス:curl http://localhost:8000ターミナルに "Hello, Gemini!" と表示されれば、機能追加は成功です！

Gemini CLI AI駆動開発体験ハンズオン

2025年8月7日(木)、日本生成AIユーザ会 で「Google Cloudサービスの生成AI関連サービス」について発表しました。https://genai-users.connpass.com/event/361798/

Google Cloudサービスの生成AI関連サービス

2025年5月30日(金) AI Agent 勉強会 Vol.3 にて、Google CloudのAI AgentサービスとGoogle I/O 2025 で発表された内容の概要を紹介させていただきました。https://almondo.connpass.com/event/355297/

GoogleのAI Agent

genai-users.connpass.com上記ハンズオン勉強会の資料になります。前回資料shu-kob.hateblo.jp前回の課題retriever_service を定義しましたが、検索結果をcontextとして、LLMへの問い合わせを行なってください。llm_serviceでretriever_serviceを使うようにします。@app.post('/api/llm')def llm_service(question: Question):    human_question = question.query    model = VertexAI(model_name="gemini-2.0-flash-001", location="us-west1")    template = """質問: {question}    ステップバイステップで考えてください。"""    prompt_template = PromptTemplate.from_template(template)    chain = prompt_template | model # prompt_templateをmodelに引き渡す処理を"|"を用いて簡単に実現    response = chain.invoke({"question": human_question}) # invokeは全ての処理が終わってから値を返す。他にはstreamなど    print(response)    resp = { 'answer': response }    return resp↓@app.post('/api/llm')def llm_service(question: Question):    human_question = question.query    model = VertexAI(model_name="gemini-2.0-flash-001", location="us-west1")    context_resp = retriever_service(question)    context = context_resp['search_result']    print(context)    template = """質問: {question}    以下の情報を参考にして、質問に答えてください。    {context}    """    prompt_template = PromptTemplate.from_template(template)    chain = prompt_template | model # prompt_templateをmodelに引き渡す処理を"|"を用いて簡単に実現    response = chain.invoke({"question": human_question, "context": context}) # invokeは全ての処理が終わってから値を返す。他にはstreamなど    print(response)    resp = { 'answer': response }    return resp以下も行っておくと便利です。.envを作成DISCOVERY_ENGINE_ID=XXXXXXXXXXXXX以下の行を main.pyに追記from dotenv import load_dotenvload_dotenv()engine_idの行を変更@app.post('/api/retriever')def retriever_service(question: Question):    search_query = question.query    project_id    location: str = "global"    engine_id: str = 'DISCOVERY_ENGINE_ID'↓@app.post('/api/retriever')def retriever_service(question: Question):    search_query = question.query    project_id    location: str = "global"    engine_id: str = os.environ['DISCOVERY_ENGINE_ID']動作確認QUESTION='{"query":"情報セキュリティにおいて気をつけるべきことを教えてください"}'curl -X POST -H "Content-Type: application/json" -d "$QUESTION" -s http://localhost:8000/api/llm | jq .参考）ソースコード差分retriever_serviceで得た検索結果をcontextに by shu-kob · Pull Request #4 · shu-kob/rag-app-handson · GitHubフロントエンドの実装フォルダ整理これまでバックエンドを追加してきたのと同じリポジトリでフロントエンドも管理いたします。そのためにこれまで追加してきたファイルをバックエンド用のフォルダに移動させます。mkdir backend# 下記以外にも必要なファイル、フォルダはbackendに移動してください。# - __pycache__とfastapi-envは削除してください。# - .gitがある場合は移動も削除もしないでください。mv *.md *.py *.txt .env backendアプリ作成アプリの雛形を作成し、起動を確認します。npx --yes create-react-router@latest --install --no-git-init frontendcd frontendnpm run devブラウザでhttp://localhost:5173/を開いてReact Routerの画面が表示されればOKです。画面を変更してみる見た目を定義しているコンポーネントはfrontend/app/welcome/welcome.tsxです。Welcomeコンポーネントを以下のように変更します。export function Welcome() {  return (    <main className="flex items-center justify-center pt-16 pb-4">      <div className="flex-1 flex flex-col items-center gap-16 min-h-0">        <div>          <div>            <label htmlFor="message">メッセージ</label>          </div>          <div>            <textarea              id="message"              rows={4}              cols={50}              style={{                padding: "0.5rem",                border: "1px solid #ccc",                outline: "none",                boxShadow: "none",              }}            />          </div>          <div>            <button              type="button"              style={{                border: "1px solid #ccc",                padding: "0.5rem 1rem",              }}            >              送信            </button>          </div>        </div>      </div>    </main>  );}画面に入力欄とボタンが表示されればOKです。入力をコントロールする上記で入力欄に文字を入力することはできますが、その値はブラウザ側で管理されており、Reactアプリ側では取得できません。そこでstateを用いてアプリ側で入力を制御します。import { useState } from "react";export function Welcome() {  const [input, setInput] = useState("");  const onSend = () => {    console.log(input)  }  return (    <main className="flex items-center justify-center pt-16 pb-4">      <div className="flex-1 flex flex-col items-center gap-16 min-h-0">        <div>          <div>            <label htmlFor="message">メッセージ</label>          </div>          <div>            <textarea              id="message"              rows={4}              cols={50}              style={{                padding: "0.5rem",                border: "1px solid #ccc",                outline: "none",                boxShadow: "none",              }}              value={input}              onChange={(e) => setInput(e.target.value)}            />          </div>          <div>            <button              type="button"              style={{                border: "1px solid #ccc",                padding: "0.5rem 1rem",              }}              onClick={onSend}            >              送信            </button>          </div>        </div>      </div>    </main>  );}テキストを入力して送信ボタンをクリックするとログにテキストの内容が表示されるようになります。ログの確認はブラウザの開発者ツールで行います。バックエンドとの接続フロントエンドはバックエンドと異なるオリジンで動かしているため、CORSエラーにならないようバックエンドを修正します。backend/main.pyに以下を追加してください。# CORSミドルウェアの設定from fastapi.middleware.cors import CORSMiddlewareapp.add_middleware(    CORSMiddleware,    allow_origins=["*"],  # すべてのオリジンを許可    allow_credentials=True,    allow_methods=["*"],  # すべてのメソッドを許可    allow_headers=["*"],  # すべてのヘッダーを許可    expose_headers=["*"]  # すべてのヘッダーを公開)変更後、バックエンドを起動します。python -m venv fastapi-envsource fastapi-env/bin/activateWindowsのコマンドプロンプトの場合fastapi-env/Scripts/activateuvicorn main:app --reload送信ボタンが押された際に入力されたテキストをバックエンドに送信し、生成AIの回答を取得できるようにします。レスポンスの確認はブラウザの開発者ツールで行います。  const onSend = () => {    fetch("http://localhost:8000/api/llm", {      method: "POST",      headers: {        "Content-Type": "application/json",      },      body: JSON.stringify({ query: input }),    })  }演習バックエンドのResponseを画面に表示させましょう例バックエンドからのresponseをフロントエンドに表示 by shu-kob · Pull Request #6 · shu-kob/rag-app-handson · GitHub

RAGアプリ開発ハンズオン（後編：フロントエンド編）

2025年5月17日React Tokyo LT大会にて、生成AIアプリケーションなどでよく使う「ストリーム実装」について話しました。https://react-tokyo.connpass.com/event/350715/

React Tokyo LT大会「ストリームの実装」

https://3-shake.connpass.com/event/351861/3-shake SRE Tech Talk #12 にて、Google CloudのAI Agent関連のサービス紹介を行いました・Vertex AI Agent Builder・Agent Garden・Agent Engine・Vertex AI Search・Agentspaceなど

Google CloudのAI Agent関連のサービス紹介

genai-users.connpass.com上記ハンズオン勉強会の資料になります。ソースコードgithub.comFastAPIの準備python -m venv fastapi-envsource fastapi-env/bin/activateWindowsのコマンドプロンプトの場合fastapi-env/Scripts/activatepip install fastapi uvicorntouch main.pyfrom fastapi import FastAPIapp = FastAPI()@app.get('/')def index():  return 'hello'実行uvicorn main:app --reload別ターミナルにてcurl -s http://localhost:8000/POSTも追加from pydantic import BaseModelclass User(BaseModel):    name: str@app.post('/api/hello')def hello_service(user: User):    resp = { 'message': 'Hello, {}!'.format(user.name) }    return respUSER='{"name":"平賀源内"}'curl -X POST -H "Content-Type: application/json" -d "$USER" -s http://localhost:8000/api/hello | jq .Google Cloudでサービスアカウントの準備Geminiマルチモーダルプログラミングハンズオン - Toilを無くして徒然なるままに日暮し硯に向かひたいの記事を参考に、ロールへVertex AI ユーザーディスカバリー エンジン ユーザーを追加し、環境変数の設定Geminiを呼び出すコードを記載main.pyの上に以下を追加import vertexaifrom vertexai.generative_models import GenerativeModelmain.pyの下に以下を追加class Question(BaseModel):    query: str@app.post('/api/llm')def llm_service(question: Question):    prompt = question.query    vertexai.init(location="us-west1") # vertexaiの初期化で、ロケーションを設定    model = GenerativeModel("gemini-2.0-flash-001") # モデルを設定    response = model.generate_content( # プロンプトをモデルに入れて出力(レスポンスを得る)        prompt    )    print(response.text) # コンソールログにresponseのテキストを表示    resp = { 'answer': response.text } # responseを形作る    return respライブラリのインストールrequirements.txtに以下を記載google-cloud-aiplatform==1.83.0vertexai==1.43.0langchain_core==0.3.33langchain_google_vertexai==2.0.12google===3.0.0google-cloud-discoveryengine==0.13.6pip install -r requirements.txt--break-system-packagesをつけよ、とエラーが出たら以下pip install --user -r requirements.txt --break-system-packages実行方法uvicorn main:app --reload別ターミナルにてQUESTION='{"query":"プロンプトエンジニアリングとは何ですか？"}'curl -X POST -H "Content-Type: application/json" -d "$QUESTION" -s http://localhost:8000/api/llm | jq .LangChainを用いるimport vertexai # 削除from vertexai.generative_models import GenerativeModel # 削除from langchain_google_vertexai import VertexAI # 追記from langchain_core.prompts import PromptTemplate # 追記@app.post('/api/llm')def llm_service(question: Question):    human_question = question.query    model = VertexAI(model_name="gemini-2.0-flash-001", location="us-west1")    template = """質問: {question}    ステップバイステップで考えてください。"""    prompt_template = PromptTemplate.from_template(template)    chain = prompt_template | model # prompt_templateをmodelに引き渡す処理を"|"を用いて簡単に実現    response = chain.invoke({"question": human_question}) # invokeは全ての処理が終わってから値を返す。他にはstreamなど    print(response)    resp = { 'answer': response }    return respRAG構築Google Cloud Vertex AI Agent Builderの使い方 - Toilを無くして徒然なるままに日暮し硯に向かひたいの記事を参考に、Google Cloud Storageにドキュメントを格納し、Agent Builderで検索アプリを作ります。main.pyの上に追記from google.api_core.client_options import ClientOptionsfrom google.cloud import discoveryengine_v1 as discoveryengineimport osimport google.authcredentials, project_id = google.auth.default()main.pyの下に追記'DISCOVERY_ENGINE_ID'を書き換えます@app.post('/api/retriever')def retriever_service(question: Question):    search_query = question.query    project_id    location: str = "global"    engine_id: str = 'DISCOVERY_ENGINE_ID' # AI Applicationsで作成したアプリケーションのIDに変更する    def search(        project_id: str,        location: str,        engine_id: str,        search_query: str,    ) -> discoveryengine.services.search_service.pagers.SearchPager:        client_options = (            ClientOptions(api_endpoint=f"{location}-discoveryengine.googleapis.com")            if location != "global"            else None        )        client = discoveryengine.SearchServiceClient(client_options=client_options)        serving_config = f"projects/{project_id}/locations/{location}/collections/default_collection/engines/{engine_id}/servingConfigs/default_config"        content_search_spec = discoveryengine.SearchRequest.ContentSearchSpec(            snippet_spec=discoveryengine.SearchRequest.ContentSearchSpec.SnippetSpec(                return_snippet=True            ),            summary_spec=discoveryengine.SearchRequest.ContentSearchSpec.SummarySpec(                summary_result_count=3,                include_citations=True,                ignore_adversarial_query=True,                ignore_non_summary_seeking_query=True,                model_prompt_spec=discoveryengine.SearchRequest.ContentSearchSpec.SummarySpec.ModelPromptSpec(                    preamble="文献の検索結果を要約してください"                ),                model_spec=discoveryengine.SearchRequest.ContentSearchSpec.SummarySpec.ModelSpec(                    version="stable",                ),            ),        )        request = discoveryengine.SearchRequest(            serving_config=serving_config,            query=search_query,            page_size=3,            content_search_spec=content_search_spec,            query_expansion_spec=discoveryengine.SearchRequest.QueryExpansionSpec(                condition=discoveryengine.SearchRequest.QueryExpansionSpec.Condition.AUTO,            ),            spell_correction_spec=discoveryengine.SearchRequest.SpellCorrectionSpec(                mode=discoveryengine.SearchRequest.SpellCorrectionSpec.Mode.AUTO            ),        )        page_result = client.search(request)        return page_result    response = search(project_id, location, engine_id, search_query)    resp = { 'search_result': response.summary.summary_text }    print(resp)    return respQUESTION='{"query":"情報セキュリティにおいて気をつけるべきことを教えてください"}'curl -X POST -H "Content-Type: application/json" -d "$QUESTION" -s http://localhost:8000/api/retriever | jq .課題retriever_service を定義しましたが、検索結果をcontextとして、LLMへの問い合わせを行なってください。次回、5月の回（日程未定）で解説します。

RAGアプリ開発ハンズオン（前編：バックエンド編）

https://genai-users.connpass.com/event/349197/この論文は大規模言語モデル（LLM）を基盤とする自律型エージェントに関する包括的な調査論文です。この論文は、LLMベースの自律型エージェントの現状、構成要素、課題、そして将来の展望について詳細に解説しています。本論文を読むことで、AIエージェントの概要を体系的に知ることができます。

論文紹介 ”A Survey on Large Language Model based Autonomous Agents”

https://genai-users.connpass.com/event/344332/2024年は生成AIが世の中に浸透した1年でしたが、2025年はAIエージェント元年と言われています。生成AIはチャットベースで受け身なものでしたが、AIエージェントは自律的にタスクを分解しこなすことができます。そのインパクトは計り知れません。生成AIの概略を説明した後、AIエージェントの紹介をします。

AIエージェント元年@日本生成AIユーザ会

https://event.ospn.jp/osc2025-spring/session/2017030AI時代におけるMLOpsのTips 〜 MLOpsを加速させるOSS 〜オープンソースカンファレンス2025 Tokyo/SpringライトニングトークにてKubeflowの紹介などMLOpsの話をさせていただきました。

AI時代におけるMLOpsのTips

https://genai-users.connpass.com/event/344292/2024年は生成AIが世の中に浸透した1年でしたが、2025年はAIエージェント元年と言われています。生成AIはチャットベースで受け身なものでしたが、AIエージェントは自律的にタスクを分解しこなすことができます。そのインパクトは計り知れません。生成AIの概略を説明した後、AIエージェントの紹介をします。

AIエージェント元年

https://gdg-tokyo.connpass.com/event/340671/大規模言語モデル（LLM）は、外部の知識源を利用することで、より強力な応答を生成できるようになります（これをRetrieval-Augmented Generation: RAGと呼びます）。LLMが処理できる入力テキストの長さが長くなるにつれて、より多くの関連情報をRAGで与えられるようになり、生成される回答の質が向上することが期待されます。一般的には、取得する情報が多いほど関連情報（高い再現率）も増え、結果として性能が向上すると考えられます。しかし、長文処理LLMにおけるRAGの性能が、取得する情報が増えすぎると逆に低下する現象を明らかにし、その原因が「ハードネガティブ」な情報にあることを示しました。そして、その問題を解決するために、効果的な学習不要および学習を伴うアプローチを提案しています。

論文紹介 ”Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG” @GDG Tokyo

genai-users.connpass.comこの記事は上記勉強会の資料です。shu-kob.hateblo.jp↑上記記事を参考にサービスアカウントの設定をしてください。※ Google Cloudの無料期間が終了していると、課金されますが、ハンズオンの内容だけだと数百円もいかないと考えています。料金は確実には言えないので、Google Cloudはご自身の責任でご使用ください。github.com↑今回のサンプルコードgit clone https://github.com/shu-kob/prompt_engineeringcd prompt_engineeringpip install vertexaiLangChainを使わずVertex AIのライブラリを使用シンプルなVertex AIでGeminiを実行project_id = "PROJECT_ID" # 書き換える実行python3 generate_content.pyresponse = model.generate_content(  "プロンプトエンジニアリングとは")プロンプトを変更して実行してみましょう。Zero Shot プロンプティングproject_id = "PROJECT_ID" # 書き換える実行python3 zero_shot_prompting.pyprompt = """以下はニュース記事のタイトルです。「政治」「経済」「芸能」「スポーツ」「科学」「その他」のうち1つに分類してください。回答だけ一言で出力してください===========================紅白出場歌手の選考基準 NHK公開"""プロンプトを変更して実行してみましょう。Few Shot プロンプティングproject_id = "PROJECT_ID" # 書き換える実行python3 few_shot_prompting.pyprompt = """以下はニュース記事のタイトルです。「政治」「経済」「芸能」「スポーツ」「科学」「その他」のうち1つに分類してください。回答だけ一言で出力してください===========================「紅白出場歌手の選考基準 NHK公開」===========================以下は例です「G20 バイデン氏不在で集合写真」:政治「岡田将生&高畑充希結婚 SNS反応」:芸能"""プロンプトを変更して実行してみましょう。LangChainを使用langchain_google_vertexai を使用pip install langchain_google_vertexaipython3 invoke.pymessages = [  ("human", "ネコの鳴き真似をしてください。"),]プロンプトを変更して実行してみましょう。PromptTemplateを使用pip install langchain_corepip install pydantic==2.9.0実行python3 prompt_template.pyプロンプトテンプレートやQuestionを変更して実行してみましょう。ChatPromptTemplateを使用実行python3 chat_prompt_template.pyprompt_template = ChatPromptTemplate.from_messages([    ("system", "ステップバイステップで考えてください。"),    ("human", "{question}"),])question = """10 + 2 * 3 - 4 * 2"""システムプロンプトやQuestionを変更して実行してみましょう。参考資料python.langchain.compython.langchain.com参考文献LangChainとLangGraphによるRAG・AIエージェント［実践］入門Google Gemini 1.5／LlamaIndex／LangChain 人工知能プログラミング実践入門

プロンプトエンジニアリング プログラミング ハンズオン

この記事は、MLOps（LLMOps、生成AIOps） Advent Calendar 2024 4日目の記事です。生成AIの普及により、アプリケーションに組み込んで実運用を始めた方も増えてきたと思います。LLMOpsをする中で気をつけたいことを考えてみました。モデルの更新まず、思い浮かぶのがモデルの更新よる影響です。モデルの更新によって性能が上がるなどのメリットを享受できる反面、挙動変更によって、困ることもあります。私の場合、システムの実運用では無いですが、LLM技術書のサンプルコードが動かなくなる事態がありました。06_agent/agent_5.py で2回目の実行結果が正しく表示されません · Issue #3 · harukaxq/langchain-book · GitHubgpt-3.5-turboをAgentとして使用したときの挙動が変わったという内容です。アプリに組み込んでいたら、機能が使えなくなる可能性があり、使えなくなった場合の代替案も用意しておく必要があると考えました。また、LLMのリリース情報もウォッチしておく必要があるでしょう。Geminiはリリースの最新情報を日本語で提供しています。gemini.google.comChatGPTはリリースノートを英語のみですが提供しています。ChatGPT — Release Notes | OpenAI Help CenterAnthropic製品（Claude）のリリースノートは日本語で提供されています。docs.anthropic.comモデルの廃止モデルの廃止もウォッチする必要があるでしょう。GPT-3.5 Turbo終了はニュースになりました。xtech.nikkei.com↑日経クロステックの有料会員記事ですが、会員でなくても1ページ目で内容は把握できます。learn.microsoft.comAzure OpenAIでは、GPTの各種マイナーバージョンが提供されていますが、適宜廃止になるので注意が必要です。廃止になる場合、モデルのVersion UPが必要なので、早めに開発環境でVersion UPしたモデルの挙動確認をする必要があるでしょう。Version UPしたモデルだと、LLMの利用料が高くなることも念頭に置いて、コスト試算しましょう。まとめモデル更新や廃止を早く知るために、LLM公式サイトのリリースノートなどのウォッチをして、早めに対策をしましょう。

LLMのモデル更新や廃止による影響を考える

この記事は生成AI Advent Calendar 2024の3日目の記事です。AIの歴史は60年ほどで、「冬の時代」と呼ばれる停滞期もありましたが、昨今の生成AIの発展は「Transformer」と呼ばれる論文から始まりました。この「Transformer」論文をわかりやすいように生成AIに要約させてみました。arxiv.org「Transformer」論文は上記サイトで見ることができます。論文の正式名称は「Attention Is All You Need」で、現在 v7。右側のAccess Paper:から閲覧することができます。なお、PDFの直リンクはこちらGoogle CloudのVertex AIでGeminiに要約させた結果は以下です。プロンプト「この論文を日本語で高校3年生レベルにもわかるように要約してください。」この論文は、「Transformer」という、機械翻訳などのシーケンス変換タスクに革新をもたらした新しいニューラルネットワークアーキテクチャを提案しています。高校3年生にもわかるように要約すると、以下のようになります。従来の機械翻訳の問題点:従来の機械翻訳は、RNN（再帰型ニューラルネットワーク）という技術を主に使っていました。RNNは文章を単語ごとに順番に処理していくため、長い文章だと処理に時間がかかります。また、並列処理が難しいため、計算速度を上げるのが困難でした。Transformerの革新的な点:Transformerは、「Attention（注意機構）」という仕組みに完全に基づいており、RNNのような順番に処理する仕組みを完全に排除しました。Attention機構は、翻訳したい単語を生成する際に、入力文全体の中でどの単語に注目すべきかを判断する仕組みです。人間の翻訳作業で例えると、翻訳する際に原文の関連する部分に注目するのと同じような働きをします。この仕組みにより、以下の利点が生まれました。並列処理が可能: 単語を順番に処理する必要がないため、並列処理が可能になり、計算速度が大幅に向上しました。長い文章への対応力向上: RNNでは、文章が長くなるほど精度が落ちやすいという問題がありましたが、Attention機構は入力文全体を一度に見ることができるため、長い文章でも高い精度を維持できます。Transformerの成果:Transformerは、従来のモデルよりも高い精度を達成し、さらに学習時間も大幅に短縮しました。具体的には、英語からドイツ語への翻訳と英語からフランス語への翻訳タスクで、当時の最高精度を更新しました。Transformerの仕組みを簡単に説明すると:Transformerは、エンコーダとデコーダという2つの部分から構成されています。エンコーダ: 入力文を解析し、各単語の意味をベクトル表現に変換します。デコーダ: エンコーダの出力とAttention機構を利用して、翻訳文を生成します。エンコーダとデコーダは、それぞれ複数の層が積み重なった構造になっています。各層は、Attention機構と全結合層という2つのサブ層から構成されています。Transformerの今後の展望:Transformerは、テキスト以外のデータ（画像、音声、動画など）にも応用できる可能性があり、様々な分野での活用が期待されています。また、文章生成をより効率的に行うための研究も進められています。簡単に言うと、Transformerは、人間の「注意」の仕組みに似た仕組みを使って、従来よりも高速で高精度な機械翻訳を実現した画期的な技術です。

Transformer論文を生成AIで要約してみた

はじめにこの記事は3-shake Advent Calendar 2024 シリーズ1の2日目の記事です。1日目はシリーズ1がYutaro ShirayamaさんのポストCloud9？クラウドIDE CoderでPlatform Engineeringを実践する2日目はシリーズ2がYoshinori Teraokaさんのvector で kubernetes の container log を CloudWatch Logs に転送するでした。なお、シリーズ2の2日目はshingo919さんの 九州旅行記（ドライブでの九州一週旅行は大変だった！）です。2025年の崖今回は「2025年の崖」について軽くご紹介したいと思います。いよいよ2025年になりますが、ITでは「2025年の崖」という言葉が存在します。2025年の崖がある中で、スリーシェイクのSreake事業部が果たす役割を考えていきたいと思います。「2025年の崖」をググったら色々出てきますが、経済産業省のレポートが1次情報源的かつわかりやすいでしょう。www.meti.go.jpなお、DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～（サマリー）はスライド5枚にまとまっており、さっと読みやすいです。「2025年の崖」は要するに何なのかというと、IT人材が不足しており、レガシーシステムを保守するのに限界が来ている。DXも推進しないといけない。何とかしないともう後が無い。という状況。2015年時点で、IT人材の不足が約17万人とされていたところ、2025年には約43万人にまで上ります。既存のレガシーシステムの保守がブラックボックス、属人的になっており、DX化の足枷に → デジタル競争の敗者に技術的負債が溜まる一方保守運用の担い手不足で、サイバーセキュリティ事故が起きやすくこんな厳しい状況を打破するには、ユーザとベンダーそれぞれで対策していく必要があります。ユーザは人材・資金を保守からDXにシフトベンダーも同様に人材・資金を保守からDXにシフトベンダーはAI、アジャイル、マイクロサービス等最新技術を用いたビジネスにシフトやることはわかっていても、そう簡単にはいきません。ただし、スリーシェイクのSreake事業では、内製化支援も行っており、これまで数々の企業様の支援を行ってまいりました。Sreakeという商材は難しく、入社して1年が経った私もストンと腹落ちできる説明ができないままでしたが、「2025年の崖」をどう克服するかが我々のパーパスだと感じました。私は生成AIアプリケーション開発支援というDXを担当しておりますが、案件の推進を通して、「DX推進」を語れるようになっていきたいと思います。今回は、序章のような形で今後も2025年の崖について書いていければと思います。次の3-shake Advent Calendar 2024はシリーズ1がkechigonさんの「Google Cloud monitoringのアラートをGitHub issueに通知する」シリーズ2がtryu___さんの「kubebuilder使ってpodの監視してみた」です。

2025年の崖から考える我々のパーパス（序章）

この記事はGCP(Google Cloud Platform) Advent Calendar 2024 1日目の記事です。2024年はIT業界にとって、最も話題に上がったトピックは生成AIだったのではないでしょうか？2023年までは生成AIと家は、ChatGPTでしたが、2024年はGoogleがBardをリブランディングして、Gemini（ジェミニ）とし、しのぎを削っています。私はGoogle Cloudのパートナー企業である株式会社スリーシェイク Sreake事業部にて、Geminiを用いた生成AIアプリケーション開発に携わっており、Geminiのビジネス利用でのメリットを語りたいと思います。Gemini-1.5-Proは最大200万トークンの読み込みが可能Geminiの強みの中で、最も他の生成AIモデルと差別化できているのが、トークン数の長さです。これにより、動画解析などへの利用もしやすくなりました。Geminiはマルチモーダルなので、音声、画像、動画なども処理可能です。量の目安としては以下になります。書籍15〜20冊程度の分量動画約2時間音声約22時間BigQueryで容易にデータ分析基盤を構築可能他のクラウドには同様のサービスがなく、同じ機能を実現するためには複数のサービスを組み合わせる必要があります。AzureやAWS、オンプレのデータはそのままで読み込みだけ行う機能もあります。今お使いのシステム構成はほぼ変えず、追加構築可能となります。Geminiは他のモデルと比較してトークンあたりの利用料が安いGoogle Cloud上で稼働させるのに最適化しているためです。他社のクラウドで使える生成AIモデルは別会社のものなので、クラウドも生成AIもGoogleのGeminiによって、この点も強みです！もしもGeminiの出力結果が著作権侵害で係争が発生してもGoogle Cloudがサポート他クラウドにはないサービスです。こちらも、クラウドも生成AIも会社が揃っている強みと言えるでしょう。真実性1位！Gemini 1.5 ProがNIKKEI Digital Governanceが調査した真実性のスコアで1位となりました！以下の記事は最初日経で見れていたと思うのですが、今はNIKKEI Digital Governanceに登録しないと見れないようです。博識のGoogle､主観強いMeta　生成AIの｢真実性｣を検証上記画像は下記記事から引用させていただきました。note.com2024年もあと少し。2025年もGeminiとともに生成AIを盛り上げていきたいと思います！GCP(Google Cloud Platform) Advent Calendar 2024 次の記事はknak72さんによる企業のセキュリティ強化に！ Chrome Enterprise Premium のURLフィルタリングとマルウェアスキャン機能です。

Geminiのビジネス利用でのメリットを語る

genai-users.connpass.com↑上記勉強会の資料です。shu-kob.hateblo.jp↑こちらの記事の「プロンプトエンジニアリング」もご覧ください。（上記記事はChatGPT）先ずは復習してみましょうGeminiにアクセスgemini.google.comお好みで、ChatGPTやClaudeを使用しても構いません。プロンプトエンジニアリングJSON形式で出力カレーのレシピを教えてください。出力は以下のJSON形式にしてください。==============={  "材料": ["材料1", "材料2"],  "手順": ["手順1", "手順2"]}==============={  "材料": [    "玉ねぎ 1個",    "にんじん 1本",    "じゃがいも 2個",    "牛肉 300g",    "カレールー 2箱",    "サラダ油 大さじ2",    "水 800ml",    "塩 少々",    "こしょう 少々"  ],  "手順": [    "玉ねぎ、にんじん、じゃがいもは食べやすい大きさに切る。",    "鍋にサラダ油を熱し、牛肉を炒め、色が変わったら玉ねぎを加えて炒める。",    "にんじん、じゃがいもを加えてさらに炒める。",    "水を加え、アクを取りながら煮込む。",    "野菜が柔らかくなったらカレールーを加えて溶かす。",    "塩こしょうで味を調え、5分ほど煮込む。"  ]}出力結果をJSON Formatterで確認JSON Formatter & ValidatorZero-shotプロンプティングZero-Shotプロンプティングとは、大規模言語モデル（LLM）に対して、事前に具体的な例を示すことなく、一度の指示でタスクを実行させるプロンプトエンジニアリング手法です。以下はニュース記事のタイトルです。「政治」「経済」「芸能」「スポーツ」「科学」「その他」のうち1つに分類してください。回答だけ一言で出力してください===========================紅白出場歌手の選考基準 NHK公開芸能Few-shotプロンプティングFew-Shotプロンプティングは、大規模言語モデル（LLM）に対して、タスクを実行するための具体的な例をいくつか示すことで、モデルの性能を向上させるプロンプトエンジニアリングの手法です。Zero-Shotプロンプティングとの違いZero-Shotプロンプティングが、一切の例を示さずにタスクを実行させるのに対し、Few-Shotプロンプティングでは、少数の例を提示することで、モデルがより効率的にタスクを学習できるようにします。以下はニュース記事のタイトルです。「政治」「経済」「芸能」「スポーツ」「科学」「その他」のうち1つに分類してください。回答だけ一言で出力してください===========================「紅白出場歌手の選考基準 NHK公開」===========================以下は例です「G20 バイデン氏不在で集合写真」：政治「岡田将生&高畑充希結婚 SNS反応」：芸能芸能Zero-shot Chain-of-ThoughtプロンプティングZero-shot Chain-of-Thought（CoT）プロンプティングは、大規模言語モデル（LLM）に対して、具体的な例を示すことなく、段階的な推論プロセスを踏ませるように指示するプロンプトエンジニアリングの手法です。回答だけ一言で出力してください。10 + 2 * 3 - 4 * 28ステップバイステップで考えてください。10 + 2 * 3 - 4 * 2## ステップバイステップで解いてみましょう！**与えられた式:** 10 + 2 * 3 - 4 * 2**解き方:**数学では、**掛け算と割り算**は、**足し算と引き算**よりも先に計算します。これを**優先順位**と言います。1.  **掛け算を計算する:**    * 2 * 3 = 6    * 4 * 2 = 8    式は、10 + 6 - 8 に変わります。2.  **残りの計算を行う:**    * 10 + 6 = 16    * 16 - 8 = 8**答え:** 8**まとめ:**与えられた式をステップバイステップで解くと、答えは**8**になります。**ポイント:*** **優先順位:** 掛け算と割り算は、足し算と引き算よりも先に計算します。* **計算順序:** 左から右へ計算していきます。**補足:**もし、計算の順番を変えたい場合は、**かっこ**を使います。例えば、(10 + 2) * 3 - 4 * 2 のようにかっこでくくると、最初に10と2を足してから3をかけることになります。**この説明で理解できましたか？** もし、まだ疑問な点があれば、遠慮なく質問してくださいね。Few-shot Chain-of-ThoughtプロンプティングFew-shot CoTプロンプティングは、大規模言語モデル（LLM）に、いくつかの例を示しながら、段階的な推論プロセスを踏ませることで、より複雑な問題を解かせる手法です。このグループの奇数を合計すると偶数になります。: 4、8、9、15、12、2、1。A: 奇数を全て加えると(9, 15, 1)25になります。答えはFalseです。このグループの奇数を合計すると偶数になります。: 17、10、19、4、8、12、24。A: 奇数を全て加えると(17, 19)36になります。答えはTrueです。このグループの奇数を合計すると偶数になります。: 16、11、14、4、8、13、24。A: 奇数を全て加えると(11, 13)24になります。答えはTrueです。このグループの奇数を合計すると偶数になります。: 17、9、10、12、13、4、2。A: 奇数を全て加えると(17, 9, 13)39になります。答えはFalseです。このグループの奇数を合計すると偶数になります。: 15、32、5、13、82、7、1。A:参考文献LangChainとLangGraphによるRAG・AIエージェント［実践］入門10倍速で成果が出る！ChatGPTスゴ技大全

プロンプトエンジニアリングハンズオン

#7 WebサイトやGitHubソースコードを処理 (ハンズオン)【オンライン】 - connpassgenai-users.connpass.com勉強会の資料です。Google Cloudでクレデンシャルを取得IAMと管理 > サービスアカウント↓こちらの記事を参考shu-kob.hateblo.jp環境変数にセット以下はMacで、.zprofileの場合export GOOGLE_APPLICATION_CREDENTIALS="/path/PROJECT_ID-XXXXXXXXXX.json"source ~/.zprofileソースコードを取得github.comgit clone https://github.com/shu-kob/genai-web-github-loadercd genai-web-github-loadernpm iWebページを読んで要約loadWebPages.tsで、プロジェクトIDの書き換えconst project = 'PROJECT_ID' // 書き換える実行npx tsx loadWebPages.ts https://www.raumen.co.jp/rapedia/study_history/ソースコードの読み込んで仕様書を作成loadGitHubでプロジェクトIDの書き換えconst project = 'PROJECT_ID' // 書き換える実行npx tsx loadGitHub.ts https://github.com/shu-kob/genai-web-github-loader

WebサイトやGitHubソースコードを処理 (ハンズオン)

OCRとは、Optical Character Recognitionの略で、日本語では光学文字認識といいます。OCRとは何か？OCRは、スキャンした書類や画像に含まれる文字を、コンピュータが読み取り、テキストデータに変換する技術です。つまり、紙に書かれた文字をデジタルの文字に変えて、パソコンで編集したり、検索したりできるようにするものです。OCRの仕組み画像の取り込み: スキャナーやデジタルカメラで、文字が書かれた紙の画像を撮影します。画像の前処理: 画像のノイズ除去や歪みの修正など、文字認識を円滑に行うための処理を行います。文字の切り出し: 画像から文字を一つずつ切り出します。文字の認識: 切り出した文字を、事前に登録された文字のパターンと照合し、どの文字か判定します。テキストデータへの変換: 認識された文字を、テキストデータに変換します。OCRの活用例書類のデジタル化: 紙の書類をスキャンしてテキストデータに変換することで、電子化し、保管や検索を効率化できます。データ入力の自動化: 請求書や領収書などの文字情報を自動的に読み込むことで、データ入力の手間を大幅に削減できます。検索の効率化: テキストデータに変換された文書は、キーワード検索が可能になり、必要な情報に素早くアクセスできます。翻訳: OCRでテキストデータに変換した後に、翻訳ソフトウェアを使って他の言語に翻訳することができます。OCRのメリット作業の効率化: 手作業でのデータ入力に比べて、大幅に作業時間を短縮できます。正確性の向上: 人による入力ミスを減らすことができ、データの正確性を高めます。コスト削減: 人件費の削減につながります。ペーパーレス化: 紙の書類を電子化することで、保管スペースを削減し、環境にも優しいです。OCRの種類OCRには、大きく分けて以下の2種類があります。OCRエンジン: ソフトウェア開発者が、OCR機能を自社のアプリケーションに組み込むために利用するソフトウェアです。OCRサービス: クラウド上で提供されるOCR機能で、APIなどを利用して簡単にOCR機能を導入できます。OCRの選び方OCRを選ぶ際には、以下の点に注意しましょう。認識精度: どの程度の精度で文字を認識できるか。対応言語: どの言語に対応しているか。対応フォント: どのフォントに対応しているか。対応ファイル形式: どのファイル形式に対応しているか。価格: 有料か無料か、料金体系はどうか。AIを用いたOCRcloud.google.comGoogle CloudなどパブリッククラウドでOCR機能が提供されています。Geminiで使用することもできます。OCRの活用の幅が広がり、工数削減に役立ちそうですね。まとめOCRは、紙の文書をデジタル化し、業務効率化に貢献する便利な技術です。様々な分野で活用されており、今後もその重要性はますます高まっていくでしょう。

AIを用いたOCR

k-tai.watch.impress.co.jpiPhone16で、Apple Intelligenceという名の生成AIが搭載されるようですね。Xなどではいまいち、盛り上がりに欠けているものの、生成AIを生業にするものとしては、触ってみたいです。Google PixelがGeminiを搭載したAIスマホとして売り出されていますが、iPhone・Apple Watch・Macユーザとしては、引き続きiPhoneですかね。Geminiは好きなので、Google Pixel欲しい気もしますがww

Apple Intelligence触ってみたい

生成AIにおけるベクトルインデックス：詳細解説ベクトルインデックスとは？ベクトルインデックスは、生成AIにおいて、テキスト、画像、音声などの非構造化データを、数値のベクトルに変換し、そのベクトル間の類似度に基づいて検索や推薦を行うための技術です。なぜベクトルに変換するのか？意味の理解: 単語の並びだけでなく、単語間の関係性や文脈を数値として表現することで、コンピュータがより深くテキストの意味を理解できるようになります。高速な検索: 高次元空間上のベクトル間の距離を計算することで、従来のキーワード検索よりも高速かつ正確に類似したデータを検索できます。多様なデータの統合: テキストだけでなく、画像や音声などもベクトルに変換することで、異なる種類のデータを統一的に扱うことができます。ベクトルインデックスの仕組みベクトル化: テキストや画像などを、ニューラルネットワークなどのモデルを用いて数値のベクトルに変換します。インデックス作成: 変換されたベクトルを、効率的に検索できるようにインデックスを作成します。ベクトル検索: ユーザーのクエリをベクトル化し、作成されたインデックスから最も類似したベクトルを検索します。ベクトルインデックスの活用事例検索エンジン: キーワードだけでなく、文章の意味に基づいたより精度の高い検索を実現します。推薦システム: ユーザーの興味関心に基づいた商品やコンテンツを推薦します。チャットボット: ユーザーの質問に対して、より自然な回答を生成します。画像検索: 画像の内容に基づいた検索や、類似画像の検索を行います。ベクトルインデックスのメリット高精度な検索: キーワードマッチングだけでなく、意味に基づいた検索が可能になります。柔軟なデータ処理: テキストだけでなく、画像や音声など、様々な種類のデータを扱えます。スケーラビリティ: 大量のデータを効率的に処理できます。ベクトルインデックスの課題次元数の呪い: 高次元空間での計算コストが大きくなることがあります。モデルの選択: どのモデルを用いてベクトルに変換するかが、性能に大きく影響します。解釈の難しさ: ベクトル表現が抽象的であり、人間が直感的に理解することが難しい場合があります。今後の展望ベクトルインデックスは、生成AIのさらなる発展に不可欠な技術です。より大規模なデータセットへの対応、より高精度なベクトル化モデルの開発、そして、ベクトル表現の解釈に関する研究が進められていくことが期待されます。具体的な活用事例eコマース: ユーザーの過去の購入履歴や検索履歴に基づいた商品推薦カスタマーサポート: チャットボットによるFAQ検索や、ユーザーの問い合わせに対する自動応答医療: 医療論文の検索や、診断支援金融: リスク評価や不正検知まとめベクトルインデックスは、生成AIの性能を飛躍的に向上させるための重要な技術です。様々な分野での応用が期待されており、今後もその重要性はますます高まっていくでしょう。さらに詳しく知りたい場合は、以下のキーワードで検索してみてください。ベクトルデータベースベクトル検索自然言語処理機械学習ニューラルネットワーク何か他に聞きたいことがあれば、お気軽にご質問ください。より具体的な質問の例:特定のベクトルデータベースについて詳しく知りたいベクトルインデックスを構築する際の注意点ベクトルインデックスを生成AIの開発にどのように活用できるかこれらの質問に対して、より詳細な情報を提供できます。

生成AIにおけるベクトルインデックス

cloud.google.com生成AIのプロンプトエンジニアリングは様々な手法がありますが、Gemini for Google Cloudなんて出ているのですね。Google Cloud のプロダクトとサービスに関しては、Geminiは学習済のようで、詳しいようです。読んで勉強したいと思います。

Google Cloud Gemini向けの生成AIのプロンプトエンジニアリング

arxiv.orgGPT-4oの進化系で、リアルタイム音声会話のできる生成AIがOSSで出たようです。github.comその名もMini-Omni。小型モデルでどうリアルタイム音声会話を実現したのか興味深いですね。生成AIでリアルタイム音声会話は難しく、Speech-to-Text-to-Speechという変換手順を踏む必要があり、時間がかかっていたところ、リアルタイム、つまりSpeech-to-Speechで早く処理できるようになった、ということですね。ぜひ論文を読んでみたいと思います。以下、AbstractをGeminiで訳してみました。（OpenAIちゃうんかいw）言語モデルの進歩とMini-Omni言語モデルの最近の進歩は、大きな成果を上げています。GPT-4oは新たなマイルストーンとして、人間とのリアルタイム会話が可能となり、人間に近い自然な流暢さを示しています。このような人間とコンピュータのインタラクションを実現するには、音声モダリティで直接推論を行い、ストリーミングで出力生成できるモデルが必要となります。しかし、これは現在の学術的なモデルではまだ実現できていません。これらのモデルは通常、音声合成のために追加のTTSシステムに依存しており、望ましくない遅延が生じます。本論文では、リアルタイム音声インタラクションが可能なオーディオベースのエンドツーエンド会話モデルであるMini-Omniを紹介します。この機能を実現するために、テキスト指示による音声生成方法と、推論時のバッチ並列戦略を提案しています。この手法は、元のモデルの言語能力を最小限の劣化で保持するのに役立ち、他の研究がリアルタイムインタラクション機能を確立できるようにします。このトレーニング方法を「Any Model Can Talk」と呼んでいます。また、音声出力を最適化したモデルをファインチューニングするためのVoiceAssistant-400Kデータセットも紹介します。私たちの知る限り、Mini-Omniはリアルタイム音声インタラクションのための最初の完全なエンドツーエンド、オープンソースモデルであり、今後の研究に貴重な可能性を提供します。

Mini-Omni OSSでSpeech-to-Speechができるようになる？

github.comGoogle Cloudの生成AIサンプルアプリ「Enterprise Knowledge Solution」 (EKS)がGitHubで公開されています。EKSはAmazon Elastic Kubernetes Serviceと紛らわしい（苦笑）「Enterprise Knowledge Solution」 はIAPとCloud RunベースでUI付きの生成AIアプリケーションをさっとデプロイできるようです。私はまだ試せていないですが、是非とも触ってみたいですね。terraformでデプロイできる模様。これは面白そう。コードも参考になりそうですね。

Google Cloudの生成AIサンプルアプリEnterprise Knowledge Solution (EKS)

langchain.connpass.comLangChain Meetup Tokyo #2に登壇してきました。私は「LangChainでWebサイトの内容取得やGitHubソースコード取得」というタイトルで発表しました！次は @shu_kob によるLangChainでWebサイトの内容取得やGitHubソースコード取得👏 #LangChainJP pic.twitter.com/ryvFxqv6M1— こぎそ | Algomatic (@kgsi) 2024年9月2日   写真撮っていただけてました。ありがとうございます。ChatGPT/LangChainによるチャットシステム構築［実践］入門作者:吉田 真吾,大嶋 勇樹技術評論社Amazon「ChatGPT/LangChainによるチャットシステム構築［実践］入門」の著者、吉田 真吾さん、大嶋 勇樹さんにもお会いできました。お二人の会社、株式会社ジェネラティブエージェンツのCEO西見公宏さんにもお会いでき、コロッケそばさん、技術者としてステキ‼️ #langchainjp pic.twitter.com/N1GE4ArjJ0— 𝙎𝙝𝙞𝙣𝙜𝙤 吉田真吾 (@yoshidashingo) 2024年9月2日   65歳で登壇されたコロッケそばさんかっこよかったです！ speakerdeck.com↑私の資料はこちらにアップロードしています。様々な学びがあり、もっと生成AIを頑張ろう、と思えた刺激的なMeetupでした！

LangChain Meetup Tokyo #2に登壇し、LangChainでWebサイトの内容取得やGitHubソースコード取得、というタイトルで発表しました

shu-kob.hateblo.jp昨日の記事に関連して、今回はLangChainでgithubリポジトリのソースコードを読む方法です。github.com↑サンプルソースコードを載せています。js.langchain.com↑使い方はこちら実行例npx ts-node githubLoader.ts https://github.com/shu-kob/langchain-sample-codeDocument {  pageContent: "import { CheerioWebBaseLoader } from '@langchain/community/document_loaders/web/cheerio'\n" +    "import { RecursiveCharacterTextSplitter } from '@langchain/textsplitters'\n" +    "import { HtmlToTextTransformer } from '@langchain/community/document_transformers/html_to_text'\n" +    '\n' +    'const url = process.argv[2]\n' +    '\n' +    'async function webLoad (url: string) {\n' +    '  const loader = new CheerioWebBaseLoader(url)\n' +    '  const docs = await loader.load()\n' +    "  const splitter = RecursiveCharacterTextSplitter.fromLanguage('html')\n" +    '  const transformer = new HtmlToTextTransformer()\n' +    '  const sequence = splitter.pipe(transformer)\n' +    '  const newDocuments = await sequence.invoke(docs)\n' +    "  console.log('newDocuments:')\n" +    '  console.log(newDocuments)\n' +    '}\n' +    '\n' +    'webLoad(url)\n',  metadata: {    source: 'cheerioWebBaseLoader.ts',    repository: 'https://github.com/shu-kob/langchain-sample-code',    branch: 'main'  },  id: undefined}Document {  pageContent: "import { GithubRepoLoader } from '@langchain/community/document_loaders/web/github'\n" +    '\n' +    'const url = process.argv[2]\n' +    '\n' +    'async function readSorceCodesFromGithub(url: string) {\n' +    '\n' +    '  const loader = new GithubRepoLoader(\n' +    '    url,\n' +    '    {\n' +    '      branch: "main", // Defaultブランチが "master" でないか注意。他のブランチも選択可能\n' +    '      recursive: true,\n' +    '      processSubmodules: true,\n' +    '      unknown: "warn",\n' +    '      maxConcurrency: 5, // Defaults to 2\n' +    '      ignorePaths: ["*.json", "*.yaml", "*.yml", "*config*", "*.md", "Dockerfile", "*ignore", ".eslintrc.js", "*.svg"] // 除外するファイルパス\n' +    '    }\n' +    '  );\n' +    '\n' +    '  for await (const doc of loader.loadAsStream()) {\n' +    '    console.log(doc)\n' +    '  }\n' +    '};\n' +    '\n' +    'readSorceCodesFromGithub(url)\n',  metadata: {    source: 'githubLoader.ts',    repository: 'https://github.com/shu-kob/langchain-sample-code',    branch: 'main'  },  id: undefined}Document {  pageContent: "import * as cheerio from 'cheerio'\n" +    '\n' +    'const url = process.argv[2]\n' +    '\n' +    'async function webLoad (url: string) {\n' +    '  // HTMLの取得\n' +    '  const response = await fetch(url)\n' +    '  const htmlText = await response.text()\n' +    '  const cheerioText = cheerio.load(htmlText)\n' +    '\n' +    '  // styleとscriptを除去\n' +    "  cheerioText('style').remove()\n" +    "  cheerioText('script').remove()\n" +    '\n' +    "  const bodyContent: string = cheerioText('body').text().replace(/\\s+/g, '')\n" +    '\n' +    "  console.log('bodyContent:')\n" +    '  console.log(bodyContent)\n' +    '  return bodyContent\n' +    '}\n' +    '\n' +    'webLoad(url)\n',  metadata: {    source: 'webLoad.ts',    repository: 'https://github.com/shu-kob/langchain-sample-code',    branch: 'main'  },  id: undefined}これらのソースコードをプロンプトに含めて、生成AIに投げます。例えば、GitHubリポジトリの仕様を聞くなどです。多くの場合、ソースコードの文量は多くなり、それなりのトークン数になるので、200万トークン対応のGemini-1.5などを使うのが良いでしょう。

LangChainでgithubリポジトリのソースコードを読む方法

LangChainでURLからWebページの中身を読み込む方法

shu-kob.hateblo.jp2024年8月23日に弊社スリーシェイクのコミュニティ勉強会「SRETT #10 ~ 夏のSRE祭り！」が開催されました。www.youtube.comアーカイブ動画も公開されています！当日ご参加できなかった方もぜひご覧ください！自分は当日誘導係をやっていて、最初の菱田さんのセッション「SRE NEXT 2024 で形にしたバトンを渡せる仕組み」は最後のちょびっとだけしか聴けていないから、観ようかな。

SRETT#10 ~ 夏のSRE祭り！アーカイブ動画公開！

AWSではじめる生成AI ―RAGアプリケーション開発から、基盤モデルの微調整、マルチモーダルAI活用までを試して学ぶ作者:Chris Fregly,Antje Barth,Shelbee EigenbrodeオライリージャパンAmazonそういや、オライリージャパンからAWSの生成AI本出てますね。欲しいと思いながらも買うてない。現状、自身の仕事のほとんどはGoogle cloudなので、AWS書籍どうしようかと思ってますが、面白そうなら買うてみるしか！翻訳はAWS Japanの久富木 隆一さん。AWSの中の人が翻訳しているので確かでしょうね！

オライリーのAWS生成AI本

SREをはじめよう ―個人と組織による信頼性獲得への第一歩作者:David N. Blank-EdelmanオライリージャパンAmazon「Becoming SRE」の邦訳である「SREをはじめよう」が2024/10/8オライリージャパンから発売されます！翻訳は、オライリーのSRE系の邦訳を数多く手掛けられてきた山口 能迪さん（Google所属）個人がSREになる、組織がSREになるという二面で書かれているようで、今からとても楽しみです！

「SREをはじめよう」(Becoming SRE邦訳)が出版

pages.sreake.comイベントで登壇していました。ご参加くださった方はありがとうございました！良い評価をいただけたようで光栄です！今回、「生成AI利活用を進めるためのプロセス」というテーマだったので、普段私があまり話さないことも話せて新鮮でした。genai-users.connpass.com普段は、日本生成AIユーザ会でハンズオンをやっているように、具体的技術を話すことが多いので。今回とても良い経験になりました。今後も良い発表ができるよう精進していきます！

Shu Kobuchi

続・完結編 — 「完結」と書いた翌週に Layer 2 の thinking を切ったら 5 機種ハイブリッドが 70〜85% 速くなって、正答率はほぼ動かなかった話

決定論 vs 確率論：Gemini 3 FlashとTF-IDFを組み合わせた「法規判定エンジン」の構築

完結編・Anthropic Claude (Sonnet 4.6 / Opus 4.7) を加えて、5機種で自転車青切符ベンチマークを総括する

続々・自転車の青切符、ローカル LLM (gemma3:4b) でやらせたら何が起きたか — 卒論ロジックも防げない壁の話

続・自転車の青切符、Proなら勝てるのか — Gemini 3.1 Pro で同じベンチマークを回してみた

自転車の青切符、生成AIに聞いたら間違えた話を2008年度の卒論で工夫

AIエージェント・エコノミーの幕開け〜オープンプロトコルが変えるビジネスの未来〜

AIエージェント・エコノミーの幕開け〜オープンプロトコルが変えるビジネスの未来〜

Google Cloudでの動画解析と検索のサービス紹介と比較

学術的根拠から読み解くNotebookLMの音声活用法

MCP・A2A概要〜Google Cloudで構築するなら〜

MCP・A2A概要〜Google Cloudで構築するなら〜

AIエージェントの自律性と協調性を解放する Google CloudによるMCP・A2A実装のエンタープライズ戦略

AIエージェント入門自律性の基礎からオープンプロトコルMCP・A2Aによる連携まで

学術的根拠から読み解くNotebookLMの音声活用法

AIエージェント入門〜基礎からMCP・A2Aまで〜

Gemini CLI AI駆動開発体験ハンズオン

Google Cloudサービスの生成AI関連サービス

GoogleのAI Agent

RAGアプリ開発ハンズオン（後編：フロントエンド編）

React Tokyo LT大会「ストリームの実装」

Google CloudのAI Agent関連のサービス紹介

RAGアプリ開発ハンズオン（前編：バックエンド編）

論文紹介 ”A Survey on Large Language Model based Autonomous Agents”

AIエージェント元年@日本生成AIユーザ会

AI時代におけるMLOpsのTips

AIエージェント元年

論文紹介 ”Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG” @GDG Tokyo

プロンプトエンジニアリングプログラミングハンズオン

LLMのモデル更新や廃止による影響を考える

Transformer論文を生成AIで要約してみた

2025年の崖から考える我々のパーパス（序章）

続・完結編 — 「完結」と書いた翌週に Layer 2 の thinking を切ったら 5 機種ハイブリッドが 70〜85% 速くなって、正答率はほぼ動かなかった話

決定論 vs 確率論：Gemini 3 FlashとTF-IDFを組み合わせた「法規判定エンジン」の構築

完結編・Anthropic Claude (Sonnet 4.6 / Opus 4.7) を加えて、5機種で自転車青切符ベンチマークを総括する

続々・自転車の青切符、ローカル LLM (gemma3:4b) でやらせたら何が起きたか — 卒論ロジックも防げない壁の話

続・自転車の青切符、Proなら勝てるのか — Gemini 3.1 Pro で同じベンチマークを回してみた

自転車の青切符、生成AIに聞いたら間違えた話を2008年度の卒論で工夫

AIエージェント・エコノミーの幕開け 〜 オープンプロトコルが変えるビジネスの未来 〜

AIエージェント・エコノミーの幕開け 〜オープンプロトコルが変えるビジネスの未来〜

Google Cloudでの動画解析と検索のサービス紹介と比較

学術的根拠から読み解くNotebookLMの音声活用法

MCP・A2A概要 〜Google Cloudで構築するなら〜

MCP・A2A概要 〜Google Cloudで構築するなら〜

AIエージェントの自律性と協調性を解放する Google CloudによるMCP・A2A実装のエンタープライズ戦略

AIエージェント入門 自律性の基礎からオープンプロトコルMCP・A2Aによる連携まで

学術的根拠から読み解くNotebookLMの音声活用法

AIエージェント入門 〜基礎からMCP・A2Aまで〜

Gemini CLI AI駆動開発体験ハンズオン

Google Cloudサービスの生成AI関連サービス

GoogleのAI Agent

RAGアプリ開発ハンズオン（後編：フロントエンド編）

React Tokyo LT大会「ストリームの実装」

Google CloudのAI Agent関連のサービス紹介

RAGアプリ開発ハンズオン（前編：バックエンド編）

論文紹介 ”A Survey on Large Language Model based Autonomous Agents”

AIエージェント元年@日本生成AIユーザ会

AI時代におけるMLOpsのTips

AIエージェント元年

論文紹介 ”Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG” @GDG Tokyo

プロンプトエンジニアリング プログラミング ハンズオン

LLMのモデル更新や廃止による影響を考える

Transformer論文を生成AIで要約してみた

2025年の崖から考える我々のパーパス（序章）

AIエージェント・エコノミーの幕開け〜オープンプロトコルが変えるビジネスの未来〜

AIエージェント・エコノミーの幕開け〜オープンプロトコルが変えるビジネスの未来〜

MCP・A2A概要〜Google Cloudで構築するなら〜

MCP・A2A概要〜Google Cloudで構築するなら〜

AIエージェント入門自律性の基礎からオープンプロトコルMCP・A2Aによる連携まで

AIエージェント入門〜基礎からMCP・A2Aまで〜

プロンプトエンジニアリングプログラミングハンズオン