Claudeが設計監督し、Gemma4が実行する 「ハイブリッドLLM」で自動化する構想

250項目のチェックを人間がハルシネーションなくこなせるか=No

IT企業の品管の仕事は複雑で量が多いのが特徴。

「チェックリストはある。基準もある。でも、毎回250項目を同じ精度で見続けるのは、人間には難しい。」

システムの開発現場において、AI駆動型開発が雨後の筍のように増え、人間オンリー案件と比べて生産性が高まるにつれ、PMOが見ないといけない品質管理の対象物も増える。しかし日本は人口減少局面で即戦力の優秀な方は品質管理のような地味な加齢臭のする現場には来ません（注意：私は清潔を第一としています）。

「ローカルAIにやらせたらどうなるんだろう」今日はそれがテーマ。

「全部クラウドAI」ではダメだった理由

品質管理はClaudeにやらせるのが一番精度が出る。だってClaude半端ないって。技術的にはこれが一番簡単だが、以下の問題が2年経っても解決しません。はい守秘義務です。

守秘義務…お客様企業の要件定義をClaudeに入れていいのかという問題ですわ…今回対応しようとしている要件定義にも企業のIT戦略・技術的な秘密が詰まっています。これをそのままクラウドに送るのは、お客様との信頼関係の上で現在はできませんということになっている。
私はこの事なかれ主義的な考え方には反対の姿勢で、Googleで散々検索していたり、Microsoft OnedriveやGoogle workspaceを企業が使っていたり、LINEで結構な機密情報バンバン送受信している時点でPaaS側には御社の情報丸見え丸裸なのには目を瞑り、AIにはデータを入れるのはけしからんいう偏屈アレルギーが笑えるほど矛盾に満ちているからでございます。愚かだよね…

人類はカエサルが2000年前に指摘してから全く進化していません。

なので「時代はローカルAI」なのだが…

私はGemma4 12Bという120億パラメータのAIモデルに私は向き合っています。データはPC外に出ない。コストは電気代（電気代だけ）。守秘義務の問題は完全にクリアできる。ところが問題がある。推論が下手で頑固者。

パイロットテストで結果は全件「OK」。「この計画書は基準を満たしています」と自信満々に答えてくれるが、人間の専門家が見ると3件中2件は「一部不足」や「NG」の項目を含んでいる※3。

原因を調べると、評価プロンプトに判定基準（ルーブリック）が一切なかった。「評価してください」と出力フォーマットだけを渡し、「OKとは何か」の定義を書いていなかった。関連する記述を見つけた瞬間に「ある＝OK」と判定してしまう──楽観バイアスです※3。

「記述が存在すること」と「基準を満たしていること」は別物です。Claudeだと難なく行間を呼んでくるのに、小型モデルは融通が効かない弱点を持つ。経験の浅いエンジニアのチェックでも起こりうる見落とし。

「指揮はClaude、実行はGemma4」

そこでハイブリッド型を目指していくことにしたわけ。この構成は、AI業界では「Plan-then-Ground」パターンと呼ばれてる※4。クラウドの大型AIが汎用的な計画やルールを作り、ローカルの小型AIがそれを手元のデータに適用する、という分業。

クラウドAI（Claude）には、「何をどう判定するか」の設計だけを任せる。 具体的には、評価の基準（ルーブリック）を作成。「OKとは、確認内容の全構成要素が設計書に明示的に記述されていること」「迷ったら厳しい方を選ぶ」──こうした判定ルールを文書化。

実際の設計書を読んで判定するのは、ローカルのGemma4が行う。 企業の機密データはパソコンの外に出ない。Claudeが作った「ルーブリック」というレシピだけがクラウドを経由する。レシピ自体には機密情報は一切含まれません。ここがポイント

Claude (クラウドAI) → レシピのみ → Gemma4 (ローカルPC)

• Claude側：評価基準を設計する／ルーブリックを作る／判定手順を明文化する → 機密データに触れない

• Gemma4側：設計書を読む／基準に沿って4段階判定／結果をJSONで出力 → データは外に出ない

ポイントは、クラウドに送るのが「レシピ（判定基準）」だけという点。設計書の中身は一文字も外に出ないのはいい。

【本実験の結果サマリ】

完全一致（人間と全く同じ判定）：32%。方向一致（OK系か不足系かの大分類）：56%。100点満点なら56点。80点で合格ラインにしておいたので、まだまだの結果も初手なのでいい感じと評価している。

そして処理時間は57分。人間がこの設計書を1項目ずつ読んで判定すると、1項目あたり約10分はかかる。25項目なら250分で4時間以上、つまり半日。57分で25項目をエラーゼロで完走したスピードだけを見れば、圧倒的に速い。

ただし、速くても的外れでは意味がないのも事実で不一致の中身を見ると、はっきりした癖があった。Gemmaは愚直に単語を拾って評価する。人間が読めば「これは書いてあるから丸（OK）だよね」「まあ三角（一部不足）くらいかな」と判断できる項目でも、チェックリストの語彙と設計書の語彙が少しでもズレていると、バツ（記載なし）にしてしまう※7。

不一致17件のうち、Gemmaが厳しすぎた方向（人間ならOKだがGemmaは不足と判定）が10件。逆に見逃した（人間は不足だがGemmaはOK）のは1件だけ※3。つまり、「拾いすぎる」けれど「見逃さない」。品質管理としては、見逃しが少ないこと自体は悪くない。問題は、拾いすぎて人間が精査する量が減らないことです。

フローは作り品質を詰めていく

設計書を読み込んで、基準と突合して、4段階で評価して、JSON形式でレポートを出す。この一連の流れは、エラーゼロで25項目を57分で完走しました※3。人間なら半日かかる作業です。機密データは一文字も外に出ていない。しかしながら間違える方向が「厳しすぎる」側に偏っている。 不一致17件のうち、Gemmaが厳しすぎたのが10件。見逃しは1件だけ※3。品質管理では、「見逃す」より「拾いすぎる」方が安全なのでセーフと言えばセーフだが、非常に口うるさいAI品質管理がでしゃばるのも考えものなのでレッツ改善。

是正対策：「仕事の渡し方」を変える

やったこと：チェック項目を「単純労働」に分解する

変更1：「設計十分性」を問わない。「記載の有無」だけ聞く。
もともと「この内容は設計として十分か？」と聞いていた。120億パラメータのモデルに十分性を聞くのは、新人に「この設計は本当にこれでいい？」と聞くようなもの。変更後は「記載があるかどうか」だけ。十分性の判断は人間がやる。

変更2：「1事実＝1要素」に分解する。
「認証方式・権限管理・アクセス制限が定義されているか」を1項目にしていた。3概念のAND結合なので1つ見つからないと全否定。これを3項目に分解。1つずつなら迷わない。

要するに：小さなAIには「小さな仕事」を渡す

大きなAIは「考える仕事」、小さなAIは「探す仕事」。 モデルを賢くするのではなく、仕事を単純にする。これが精度56%からの是正で見えた、ハイブリッドLLMの是正点。

大きなAIに「考え方」を設計させ、小さなAIに「実行」させる──この役割分担は、品質管理に限らず多くの業務に応用できると考えています。

出典・参考
※1 自社実験データ：反証担当による独立評価（実施日 2026-07-18）。ダミー分類器64%・κ≈0.217・スクリーニング削減効果最大28%は検証スクリプトによる追試で確定
※2 Stop Choosing Between Local and Cloud LLMs: A Field Guide to Hybrid Patterns | Towards Data Science（閲覧日 2026-07-19）
※3 自社実験データ（実施日 2026-07-17〜18）。パイロット3件→本実験25項目の全工程記録
※4 同上。5つのハイブリッドパターン分類のうち「Plan-then-Ground」
※7 自社実験データ（実施日 2026-07-19）。過検出17件の原因分類（読解ミス7/語彙乖離5/AND合成2/検知正当8）、v4変更点（記載有無判定への限定＋1事実1要素分解）、合格基準（方向一致80%以上・見逃し0〜1件）