「見事な手さばき」を笑えなかった話

先日、隣の席の若手エンジニアの画面をたまたま見て、手が止まりました。

エラーが出る。
コピーする。
AI に貼る。
返ってきたコードを貼り直す。
動く。次のタスクへ。

ここまで、およそ 3 秒 × 数往復。見事でした。
ですが、エラーメッセージを、本人は一度も読んでいませんでした。

「最近の若手は」という話をしたいのではありません。話はここからです。

その日の午後、自分の画面で見慣れないエラーが出ました。いつものように AI に貼ろうとして、ふと手を止めて、試しに自力で読んでみることにしたんです。

読めませんでした。

正確に言うと、読む前に「AI に貼れば済む」という思考が割り込んできて、スタックトレースを上から追う集中力が、もう続かなかった。数年前の自分なら当たり前にやっていたはずのことが、です。

若手の画面を見て寒気がしたのは、あれが自分の姿だったからでした。

そしてマネージャーとしての立場に戻ると、もっと嫌な問いが待っています。評価面談で「彼の実力」を語ろうとしたとき、見るべきものがない。成果物は AI が書いている。速度は AI が出している。コミットログは AI との共同作品。私が語れるのは、正直「印象」だけでした。

この違和感を放置できなくて、仲間とプロダクトを作りました。この記事はその紹介です。

起きていること — AI は開発を速くして、実力を見えなくした

生成 AI で開発速度は確実に上がりました。一方で、静かに逆流が起きていると感じています。

まず個人の側。

エラーが出たら AI に貼り付け、修正コードをもらう
動いたので次へ。なぜ壊れ、なぜ直ったかは分からないまま
次も同じ場所で詰まる。そして本人も、薄々まずいと感じている

最後の一行が重要だと思っています。プロダクトを作るにあたって若手にヒアリングしてみると、「AI がないとエラーが解けない自分」への不安は、こちらが思っているよりずっと共有されていました。でも納期の前では、学習より解決が優先されるに決まっている。個人の意志で解ける問題ではないんです。

そしてこれは、若手だけの課題感ではありませんでした。ヒアリングでは、マネージャーも人事も、立場は違えど同じ問題を口にした。

組織の側には、これが 3 つの形で跳ね返ってきます。

#	組織側で起きること
1	メンバーの実力が見えない。 AI が下駄を履かせるため、成果物から地力を測れない
2	育成が属人化する。「エラーの読み方」を教えられるのは一部のシニアだけ
3	評価の根拠が主観に寄る。技術力の評価が印象と自己申告に依存する

「AI に頼るな」と言うのは簡単です。でも本人の意志にも、組織の号令にも頼れないなら、仕組みで解くしかない。

だから、発想を変えました。

発想の反転 — AI に答えを出させるのではなく、問いを出させる

作ったのは SocraMetry（ソクラメトリー） という Web サービスです。

一言でいうと、エラーを投げると、答えの代わりに「問い」が返ってくる AI メンターです。

AI は内部でちゃんと原因を特定しています。 特定した上で、言わない。 画面は一見チャットですが、AI に自由に質問する欄はありません。利用者にできるのは、エラーを投げること、選択肢を選ぶこと、そして 自分の言葉で原因を宣言すること だけ。 「AI に聞けば済む」という逃げ道を、構造的に塞いでいます。

名前の由来はそのままで、Socrates（ソクラテス式問答）+ Metrics（評価指標） です。答えを教えず問いで導くソクラテスの対話法と、その対話の履歴 — ヒントへの依存度、思考のプロセス、解決までの時間 — を評価データに変換する、という 2 つの機能を 1 つの名前に詰めました。

実際のやりとりを見てほしい

説明より体験です。よくあるエラーを投げたときの、実際のセッションの流れがこちら。

ポイントは、AIが一度も答えを言っていないことです。エラーを問いかけたエンジニアは、ヒントや設問を解くことで、原因には自分で辿り着いている点です。

これを体験すると分かるのですが、答えを教えてもらったときと、自分で気づいたときでは、記憶への残り方がまったく違います。そして次に同じ形のエラーを見たとき、最初に目が行く場所が変わっている。

「答えを教えないなんて、業務で使えるわけがない」への答え

真っ先にこう思いませんでしたか。私も最初に思いました。詰まったまま業務が止まるなら、誰も使いません。使われないツールは学習にも評価にも使えない。

なので、答えは「隠し続ける」のではなく、本人が到達を試みた後に開示する 3 段階にしています。

最後まで行けば必ず答えに辿り着けます。 業務は止まらない。 詰まったまま放置になる人を救うため、ヒントの段階（Gate A）から設問（Gate B）へは、時間が経てば自動でも進みます。「進む」と自分から言えない人ほど、詰まったまま抱え込むものなので。ただし、どのゲートで解決したか・ヒントにどれだけ頼ったかは記録される。開示は敗北ではなく「正しい着地点の一つ」として扱いつつ、 ヒントや誘導に頼らずに解けたほど評価が高い 、という素直なインセンティブだけを置いています。

「そもそも AI 時代に、デバッグ能力なんて要るのか」への答え

もう一つ、必ず来る反論に対して先に答えておきます。

AI がどんどん賢くなるのに、人間がエラーを読める必要ある？
電卓の時代に、暗算を鍛えるようなものでは？

半分は同意します。定型的なエラーの大半は、近い将来 AI が人間より正確に処理するでしょう。それでも理由は 3 つあります。

#	それでも要る理由
1	AI の修正案を検証できる人がいないと、本番で詰む。「動くように見える」と「正しい」の区別をつけるのはデバッグ能力そのもの。全員が手放したチームは、AI の出力をレビューできないままリリースすることになる
2	AI が解けないエラーこそが、人間の仕事として残る。 AI が定型を引き受けるほど、人間に回ってくるのは非定型の難問だけになり、求められる水準はむしろ上がる
3	観察 → 切り分け → 仮説 → 検証のプロセスは、AI への指示にもそのまま要る。デバッグの思考は廃れる能力ではなく、AI を道具として使いこなすための土台

暗算の比喩で言えば、鍛えたいのは桁数の多い掛け算ではなく、「その計算結果、桁からしておかしくない？」に気づく感覚の方です。電卓が普及しても、そちらは要り続けました。

何を測るのか — デバッグ脳スコア

そして冒頭のもう一つの問題、「実力が見えない」の方です。

SocraMetry は問答するだけでは終わりません。熟練者が無意識にやっているデバッグのプロセスを 5 段階に分解して、対話履歴からそれぞれを独立に測ります。

軸	測っているもの	問いの例
観察	エラーを正確に読めるか	「このメッセージは何が undefined だと言っていますか？」
切り分け	問題箇所を絞れるか	「エラーが出る直前に、どのファイルを変更しましたか？」
仮説	原因を推論できるか	「その変数は、どこから来ていますか？」
検証	仮説を確かめられるか	「確認するには、まず何を出力しますか？」
修正	再発しない直し方を選べるか	「二度と起こさないために、どこに何を足しますか？」

「技術力が高い / 低い」ではなく、「観察は強いが検証が弱い」まで言える形にするのがポイントです。育成担当は誰に何を教えるべきかがデータで分かり、本人は伸ばすべき場所が分かる。

一つ、正直に書いておくべき限界があります。 最上位の到達 — ヒントだけで自力解決した場合 — は、5 軸が全部同じ値になります。 設問を 1 問も解いていないので、軸ごとに差がつく材料がそもそも無い。実装の不具合ではなく、「設問に答えさせずに自力解決させる」ことを最良の結末として設計した以上の、構造上の帰結です。測定のために設問を強制すれば、自力解決の価値そのものが失われる。なので v0.1 ではこれを隠さず、自力解決時の 5 軸は 「参考値」と明示して表示し、成長率の算出からは除いて います。

「それ、監視ツールでは？」への答え

測られる側として、いい気分がしない方もいると思います。エンジニアが計測ツールに向ける警戒心は正当なもので、指標は評価に使われた瞬間に歪む（Goodhart の法則）ことも分かった上で、測られる側が損をしないための設計を最初から入れています。

算出根拠は本人がいつでも確認できる。 総合点だけを出力することを許さない。説明できない数値で人を評価させない
主指標は絶対値ではなく成長率。 経験年数の差がそのまま順位になる指標は、若手にとって「頑張っても覆らない」指標であり、使われなくなる
順位付けを既定にしない。 既定の見せ方は「成長の可視化」。スコアを人事システムに自動連携する機能は、意図して作らない

ほかにも、開示（Gate C）の減点は意図的に小さくしてあります。開示を罰にすると、利用者は詰まったとき直接 AI に聞きに行き、学習も計測も成立しなくなる。利用者に損な行動を強いる設計は、必ず回避される — プロダクト全体の設計原則です。

技術の話 — 「答えを言わない AI」はどう作るのか

ここからが本題です（エンジニアなので）。

課題: LLM は、頼んでも秘密を守れない

LLM に「原因を特定して、でも答えは言わずに質問して」と 1 回で頼むと、必ず漏れます。「〜が undefined になっているようですね。では…」と、前置きで答えを言ってしまう。プロンプトを頑張っても、確率的にいつか漏れる。

なので、確率で防ぐのをやめて、構造で防ぐことにしました。

解法: 出題者に、答えを教えない

LLM を役割分離した 2 段構成にしています。

1 段目の Diagnoser が原因を特定し、2 段目の Questioner には「どこに着目させるべきか」だけを渡します。出題側は答えを知らないまま問いを作るので、漏らしようがない。

ダメ押しで、生成文をユーザーに返す前に LeakGuard という漏洩検査を通しています。これはあえて LLM を使わず、決定的なルールで実装しています。LLM に「漏れてないか確認して」と聞く方式だと、検査自体が確率的になってしまうからです。

AI を使う場所と使わない場所を分ける — 秘匿情報のマスキングは LLM に送る前なので正規表現、スコア算出は再現性が要るので純関数 — というのは、このプロダクト全体を貫いている方針です。

この構造が、そのままコスト設計になった

面白いのはここからで、この 2 段構成、答えの漏洩対策とコスト最適化が同じ設計で解けています。

本サービスは 1 セッションで LLM を 10〜15 回呼びます。その内訳には、はっきりした偏りがあります。

性質	処理	回数
推論精度が要る。難しい	原因の特定（Diagnoser）	1 回
速度と制約遵守が要る。難しくない	ヒント生成・出題・判定	10〜15 回

難しい処理は 1 回しかなく、簡単な処理が大半。だったら、難しい 1 回に高品質モデルを使い、残りは安価なモデルに出し分ければいい。

ここで効いてくるのが、LLM ゲートウェイに採用した OrcaRouter です。OrcaRouter は OpenAI 互換の API で複数プロバイダのモデルを扱えるゲートウェイで、model パラメータを変えるだけで、プロバイダをまたいだモデルの出し分けができます。クライアントは 1 つのまま。役割別ルーティングの実装コストが、ほぼゼロになりました。

ただし「全部安いモデルにすればもっと安い」とはなりません。Diagnoser の精度が落ちると着眼点が的外れになり、以降の出題が全部無意味になる。

一番効くのは「安くする」ことではなく、「安くしてよい場所を見極める」こと。
回数 × 単価で考えると、投資すべき場所と削るべき場所は自動的に決まります。

しかもこの出し分けは品質設計でもあります。診断は 1 セッション 1 回だけ実行して結果を保存し、再診断しない。毎回診断し直すと原因の見立てがブレて、問いの一貫性が壊れるからです。コストと品質が同じ設計で両立するのは、設計していて気持ちのいい瞬間でした。

実測したら、試算と違った（正直に書きます）

設計時の試算では「出し分けで 74% 削減 」のはずでした。全 LLM 呼び出しを 1 リクエスト単位で記録する仕組みを最初から入れてあった（いまはセッション終了時の結果カードにも「この 1 セッションの実測コスト」を出しています）ので、実 LLM で通して答え合わせをしたところ —

構成	1 セッション（実測ベース）
すべて高品質モデル	約 12.5 円
役割別に出し分け（採用）	約 6.8 円
削減率	45%（試算では 74%）

45% でした。 数字が縮んだ理由が面白くて、安くした対象（設問の生成）が、思っていたよりずっと安かったんです。実測では設問 1 問あたり 0.043 円。セッション全体に占める割合はわずか 3.4% で、コストの 96% は高品質モデルを使う 3 役割（診断・解説・振り返り）が占めていました。安くする対象が小さければ、節約額も小さくなる。当たり前の算数です。

なお、利用者が詰まって設問を重ねるケースでは削減率は 68% まで上がります。削減率は「利用者が何問解いたか」に依存するので、単一の数字では語れない — というのが実測後の正確な言い方です。

もう一つ。この「実測」はアプリ内の推定だけではありません。単価表にトークン数を掛けた推定値を、OrcaRouter の実請求（クレジット消費）と突き合わせて、差 6%（表示の分解能を含めても最大 11%）であることを確認しています。単価表を信じるのではなく、請求と答え合わせをする — 数字を出す以上、そこまでやってようやく「実測」と呼べると考えています。

実測で見つけた、いちばん面白い構造

計測ログを眺めていて気づいたのがこれです。

原価は「どれだけ使ったか」ではなく「何回始めたか」で決まる。

	内容
セッションを開始した時点	約 4.2 円が確定（診断と振り返りは必ず走る）
設問を 100 問解いても	+4.3 円しか増えない

実測でも、ヒントだけで即解決したセッション（約 4.9 円）と、設問を経て解説まで読んだセッション（約 6.8 円）の差は 約 2 円しかありませんでした。

つまり、利用者がどれだけ長く粘って考えても、原価はほとんど動かない。「じっくり考えさせる」ことが価値のプロダクトにとって、思考時間がコストに跳ねない原価構造は、狙って作ったわけではないのに、これ以上ない相性でした。

セキュリティは地味に、確実に

書くと地味ですが、業務のエラーテキストを預かるサービスなので。

API キーはサーバ側の環境変数のみ。 フロントエンドから LLM は叩かない（すべて OrcaRouter 経由に統一）
秘匿情報は LLM に送る前にマスキング （前述の通り、ここは LLM 非使用）。さらに マスク結果は送信前に画面でプレビューします。ここで一つだけこだわったのが、プレビュー用に正規表現をフロントへ書き写さず、サーバと同じマスキング純関数をそのままブラウザと共有　したこと。2 つの実装がずれた瞬間、「画面では消えているのにサーバには生で届く」という無いより悪い表示になるからです。このためだけに、ビルドなし方針だったフロントにバンドラを 1 つ入れました
組織固有の除外語辞書はクライアントに配らない。どの社名を扱っているかが、ブラウザから読めてしまうため
ログに PII を残さない。 エラー本文はログに出さず、トークン数と役割だけを記録

誰が、どう使うのか — ユースケースで考える

作りながら見えてきたのですが、これは個人の学習ツールに見えて、組織側の価値の方が厚いプロダクトです。想定している使われ方を並べます。
（一部は v0.2 以降の構想を含みます）。

個人と育成担当 — 訓練が日常で回り、処方が個別になる

個人にとっては、業務で出たエラーをそのまま投げるだけで、納期を止めずに「エラーを読む訓練」が日常の中で回る。育成担当にとっては、「観察は強いが検証が弱い」まで見えるので全員一律の研修ではなく個別の処方ができ、教えられる希少なシニアの工数をいちばん効く場所にだけ投下できる。

【育成担当やマネージャー、人事が確認できる組織ダッシュボードのイメージ】

組織 — 実力の可視化と、ナレッジの資産化

組織に対しては 4 つの価値を設計しています。

#	価値	内容
1	個人の相対評価	同じ物差しで測った 5 軸と成長率で、メンバー間の比較が印象ではなくデータでできる。※既定の見せ方を順位にしない方針（前述）はここでも変わらない。比較は序列づけではなく、育成投資をどこに配分するかの判断に使う
2	他社とのレベル感	SaaS として利用組織が増えるほど、匿名化された分布との比較で「うちの 3 年目は市場のどのあたりか」が言えるようになる（構想）
3	ナレッジの資産化	実務で起きたエラーの問答セッションを、匿名化・汎用化して社内の問題集に蓄積できる。使えば使うほど、その組織固有のつまずきどころが資産になる。外部の汎用教材では絶対に作れない
4	解決実績の記録	セッション開始時に言語 / フレームワークの文脈を取っているので、「どのフレームワークの、どんな課題を解決したか」が履歴として残る

SES・派遣 — スキルシートに、実績の裏付けが付く

4 つ目の価値がいちばん刺さるのはここだと考えています。エンジニアを提案する営業の現場で、スキルシートの「React: 経験 3 年」という行が何も語らないことは、出す側も受け取る側も知っています。SocraMetry の履歴なら「React の非同期処理起因の不具合を、ヒントに頼らず解決してきた」まで言える。「何年触ったか」ではなく「何を解決したか」で提案できるのは、提案の説得力としても単価交渉の材料としても、まったくの別物です。

トレーニング — 昨日の障害が、今日の演習問題になる

ナレッジの資産化（上の 3）には続きがあります。蓄積されたセッションは、読んで終わりのポストモーテム資料ではなく、解ける設問として溜まっていく。演習モード（v0.2）では、育成担当が問題集からセッションを割り当て、新人は実務とまったく同じ 3 ゲートの問答で解きます。題材がすべて「うちの現場で実際に起きたこと」なので、研修と実務の距離がゼロになる。

【ナレッジから作成されたトレーニング画面のイメージ】

で、これは売り物になるのか

なると考えています。というより、売り物になる形を先に設計しました。

原価である LLM コストは、上の出し分け設計で 1 人あたり月 39〜55 円（実測ベース。週 2 回利用、セッション 4.9〜6.8 円で換算。幅で書くのは、どのゲートで解決したかで原価が 40% 変わるからです）。BtoB の SaaS として 1 人あたり月額 1,000〜2,000 円の価格帯を検証中ですが、この原価構造なら十分に成立します。エンジニアの育成・評価に組織が払っているコスト（シニアの工数、外部研修、評価制度の運用）を考えると、置き換える先は十分にある。

「日常的に使ってもらうことが売りなら、使われるほど原価が増えて、成功するほど粗利が減る構造では？」— チームの QA からもらった指摘です。構造としてはその通りで、ただしどこで問題になるかは実測で言えます。月額 1,000 円と置いた場合の損益分岐は 1 人あたり月 146 セッション — 想定利用（週 2 回）の 18 倍。「日常化」で増やしたいのは 1 セッションを深く使うことで、そちらは 100 問解いても +4.3 円しか増えない。増えて困るのは開始回数の方だけなので、日次・週次の上限を v0.2 で入れます。

原価がセッション開始回数で決まる構造（前述）なので、価格を守る蛇口も「トークン量の上限」ではなく「セッション開始のレート上限」の 一本だけです。実際、トークン量の上限は実測では 2 割も使われておらず、防波堤として機能していませんでした。** どの蛇口を締めれば原価が守られるかを、実測で特定してある** — 価格設計とはこういう作業の積み上げだと思っています。

そして前節のユースケースの通り、使えば使うほどその組織固有のナレッジと実績データが溜まっていく構造にしてあります。データが資産になるサービスは、使い続けるほど手放しにくくなる。原価構造と合わせて、これが SaaS として成立すると考えている理由です。

おわりの前にインフラの話

インフラは enebular のクラウド実行環境です。TypeScript で書いたバックエンドを ZIP で上げると、サーバーレスとして動く。ここに全部載せています。

API も画面も、1 つの関数から配信。 フロントエンドの静的ファイルも関数が返す（同一オリジン）ので、デプロイ先が 1 つになり、CORS も Cookie の設定も丸ごと消えました
データは enebular データストアに。 DB を別途立てていません。そして「AI が内部で特定した原因（= 答え）」は API レスポンスに決して載せず、データストアの隔離テーブルにだけ保存しています。答えを言わない AI の、答えの置き場所がここです
デプロイは GitHub Actions から enebular CLI で自動化。 push すると ZIP がビルドされ、@uhuru/enebular-cli がそのまま実行環境を差し替える。マージから数分で、staging に実 LLM の環境が立ち上がります

現状のシステム構成はこのような構成です。
（短い期間で、実現性の確認を行うため簡易的な構成となってます）

面白かったのは、プラットフォームの制約が設計を良くしたことです。クラウド実行環境はバッファ応答（ストリーミング不可）なので、当初予定していた SSE を捨て、時間のかかる診断（実測で約 21 秒）を別リクエストに分離しました。結果として生まれた「診断は 1 回だけ実行して保存し、再診断しない」という構造は、前述の通りコストと品質の要になっています。enebularのデータストアも JOIN や集計のない Key-Value ストアなので、アクセスパターン起点でキーを設計し、1 セッションを少数アイテムに集約する。制約は考えることを増やすのではなく、選択肢を絞って設計を速くしてくれました。

全体のシーケンスはこのような流れとなってます。

おわりに — 「AI に何をさせないか」を設計する時代

AI プロダクトの多くは「AI に何をさせるか」を競っています。でも今回作ってみて確信したのは、これからの AI プロダクトの差別化点は 「AI に何をさせないか」の設計にもある、ということです。

答えを知っている AI に、答えを言わせない（構造で）
検査やスコアリングには、AI を使わない（確実性のために)
高いモデルを、精度が要る場面でしか呼ばない（回数 × 単価で）

SocraMetry は、AI から答えを取り上げることで、AI 時代に見えなくなったエンジニアの実力を、もう一度見えるようにするプロダクトです。

最後に、冒頭の問いを 2 つ、あなたにも置いていきます。

次にエラーが出たとき、AI に貼る前に、自力で読み切れる自信はありますか？

そしてもしあなたがチームを見る立場なら —
メンバーがエラーを自力で読めるかどうかを、いま、データで語れますか？

本プロダクトは、AI HACK 2026というハッカソンで、2人のチームで作ったプロダクトです。
最初に課題出しをした際に意見が合い、組織やエンジニアマネージャー、若手エンジニアの課題を解決するためのサービスとして、SocraMetryを構築しました。
ハッカソンは9日間という短い期間ですが、同じような課題感は多いと思うので、ある程度賛同が得られれば継続開発していきたいと思っています。