この記事について
本記事は、別記事「AIエージェント2台に同じLPを「5プロンプト」だけで作らせた検証（Vol.01）」の補足用語集です。本編は理論パート（自己評価・過信現象・LLM-as-a-Judge など）を含むので、読みながら詰まりやすい用語を、ここで一括して引けるようにしました。
本編 → バイブコーディング検証 Vol.01
本編を読んでいなくても、生成AI／フロントエンドの用語集として単体で使えます。
使い方は2通りです。まず早見表（カテゴリ別の一覧）でざっと当たりをつけ、本編の核心に関わる語は後半の詳説で深掘りしてください。定義はすべて筆者の言葉で書いています（一次情報のリンクは末尾の参考に集約）。
1. 早見表
A. バイブコーディング & エージェント
| 用語 | 一言でいうと |
|---|---|
| バイブコーディング（vibe coding） | 人間がコードを書かず、自然言語の指示でAIに生成・修正・デバッグさせる開発スタイル |
| エージェント型コーディング環境 | 指示を受けてファイル編集・実行・検証まで自分で進めるAI開発ツールの総称 |
| IDE型 / CLI型 | 前者はエディタ内で自走（例：Antigravity）、後者はターミナルで動く（例：Claude Code） |
| 自走（イテレーション） | 1つの指示の中で、AIが内部的に何度も試行錯誤を繰り返すこと。人間のカウント外 |
| Antigravity | Google系のIDE型エージェント。本検証では Gemini 3.5 Flash を載せて使用 |
| Claude Code | Anthropic のターミナル型エージェント。本検証では Claude Opus 4.7 を使用 |
B. 自己評価とLLMの評価
| 用語 | 一言でいうと |
|---|---|
| 自己評価（self-evaluation） | LLMに自分の出力を採点させること。例「完成度100%」という自己申告 |
| 過信現象（overconfidence） | 予測した確信度が、実際の正確さを上回ってしまう傾向。詳説あり |
| キャリブレーション（較正） | 「自信の度合い」と「実際の当たりやすさ」が一致している状態 |
| ECE（Expected Calibration Error） | 較正のズレを測る指標。大きいほど過信・過小評価がひどい |
| LLM-as-a-Judge | LLMに別の出力を評価させる手法。人手評価をスケールできる。詳説あり |
| 相互レビュー | 2つのモデルに互いの成果物を評価させること。本検証の決定打。詳説あり |
| ルーブリック（rubric） | 評価軸ごとに配点を定義した採点基準表。比較可能性を担保する |
C. モデルと指標
| 用語 | 一言でいうと |
|---|---|
| モデル階級 | 中位（軽量・安価・高速）／最上位（高価・低速・高精度）といったモデルの格 |
| レイテンシ（latency） | 入力してから出力が返るまでの待ち時間 |
| トークン / コスト | LLMが扱う処理単位。課金はトークン量に比例する |
| LOC（行数 / Lines of Code） | コードの行数。少なさ＝偉さではないが、重複・冗長の代理指標になる |
| 保守性（maintainability） | あとから読んで直しやすいか。動くこととは別の品質軸 |
| デッドコード | どこからも使われていないコード（例：未使用CSSクラス）。保守の負債になる |
D. フロントエンドの制約と実装
| 用語 | 一言でいうと |
|---|---|
| 単一HTML / 外部依存ゼロ | CSS・JSを1ファイルに内包し、外部CDN・フォント・画像・ライブラリを使わない構成 |
| インラインSVG | 画像ファイルを使わず、HTML内にSVGを直接書いて図形・アイコンを描く |
| Vanilla JS | フレームワークなしの素のJavaScript |
| アコーディオン | クリックで開閉する折りたたみUI（FAQなどで使う） |
| レスポンシブ | 画面幅（PC/タブレット/スマホ）に応じてレイアウトが崩れず追従すること |
| アクセシビリティ（a11y） | 誰でも（キーボード操作・支援技術含め）使えるようにする配慮。詳説あり |
| WCAG | Webアクセシビリティの国際ガイドライン |
aria 属性 |
支援技術に意味や状態を伝えるためのHTML属性（例：aria-expanded） |
outline: none |
フォーカス枠を消すCSS。安易に使うとキーボード操作者が現在地を見失う |
E. 検証方法・科学の作法
| 用語 | 一言でいうと |
|---|---|
| Single Source of Truth | 唯一の正解。本検証では「要件定義.md」がそれ |
grep 検証 |
文字列を機械的に検索して、想定外の記述（例：非対応の色）が残っていないか確認する |
| n=1 | サンプル数が1。一般化できない単発の観察であることを示す |
| 交絡（こうらく / confounding） | 比べたい要因以外の変数が混ざり、原因を切り分けられない状態 |
| 対照実験 / ケーススタディ | 前者は変数を1つに絞った厳密比較、後者は単一事例の観察。混同すると主張が過剰になる |
| 探索的検証 | 仮説を厳密に証明するのではなく、当たりをつけるために行う観察的な検証 |
F. 関連用語（LLM生成の基礎・シリーズで頻出）
| 用語 | 一言でいうと |
|---|---|
| ハルシネーション | LLMが事実でない「もっともらしい嘘」を自信満々に生成する現象 |
| temperature | 出力のランダム性。高いと発散（多様）、低いと収束（一貫） |
| 構造化出力（JSON Schema） | 出力をキー・型・構造が決まったJSONに強制整形する機能 |
| strict モード | 構造化出力の厳格版。JSON Schema の一部（値制約など）は非対応な点に注意 |
| grounding | 事実や文脈をモデルに与え、生成を事実に係留すること（RAGなど） |
| HITL（Human-in-the-loop） | 意思決定点に人の確認を残す設計。誤情報・炎上の防止に効く |
2. 詳説（本編のキモになる語）
早見表だけでは足りない、検証の結論に直結する語を掘り下げます。
2.1 過信現象（overconfidence）
ひとことで： AIの「自信」は、実際の正しさより高く出やすい。
LLMに「どれくらい正しい自信があるか」を出させると、その数値（予測確信度）が、実際の正答率を体系的に上回ることが報告されています。つまり「90%の自信」と言われても、本当に当たっている割合はそれより低いことが多い。さらに、自己改善（出力を自分で直す）を繰り返すほど過信が強まる（較正のズレ＝ECEが上昇する）という観測もあります。
本編との関係：あるモデルが最終的に「完成度100%」と自己申告したのに、相手のレビューで実バグが複数見つかりました。一方「88%」と控えめに申告した側のコードの方が堅牢でした。自己申告の高さは品質を保証しない――この観測は、過信現象という一般傾向と整合的です（ただし上記研究はベンチマーク採点の知見で、自作コードへの自己評価とは設定が異なるため、直接証拠ではなく傍証として扱うのが正確です）。
2.2 LLM-as-a-Judge と相互レビュー
ひとことで： AIに採点させると速いが、採点者自身もブレる。だから「相手に見せる」。
LLM-as-a-Judge は、人手評価をスケールするためにLLMへ評価を委ねる手法です。便利な反面、評価者であるLLM自身にバイアスと揺らぎがあることが知られています。「judge を足せば安心」とは言えません。
そこで本検証では、自己評価の限界を補うために 相互レビュー を使いました。2つのモデルに互いのコードを評価させるのです。自分の作を甘く見る過信があっても、第三者（相手モデル）の目には粗が映る、という仮定です。実際、片方は相手のコードからバグを優先順位つきで列挙し、もう片方は「秀逸」「商用公開できる」と高評価を並べるだけでした。評価する側の性格差そのものが、結果として現れます。
2.3 自己評価 vs 相互レビュー（なぜ分けるか）
| 観点 | 自己評価 | 相互レビュー |
|---|---|---|
| 速さ・手軽さ | ◎ その場で出せる | ○ もう1回投げる手間 |
| 過信の影響 | 受けやすい（自分に甘い） | 受けにくい（他人に厳しい目） |
| 本編での役割 | 「100%」という当てにならない指標 | バグを掘り当てた決定打 |
教訓は単純です。「できました（100%）」という自己申告ではなく、他人の目に映った1つのバグを信じる。 これは人間のコードレビューと同じ発想です。
2.4 outline: none がなぜ「高」重大度なのか
ひとことで： フォーカス枠を消すと、キーボードだけで操作する人が「今どこにいるか」を失う。
リンクやボタンは、Tabキーで移動すると周囲に枠（フォーカスリング）が出ます。これはマウスを使わない人にとって現在地を示す唯一の手がかりです。outline: none はこの枠を消すCSSで、見た目をすっきりさせたいときに安易に使われがちですが、消しっぱなしにするとキーボード操作者が操作不能になり、WCAG（アクセシビリティ指針）違反になりえます。本検証で相手モデルがこれを「重大度：高」として検出したのは、見た目では気づけない実害のある欠陥だからです。
対処：outline: none だけで終わらせず、:focus-visible で代替の見やすいフォーカス表示を用意するのが定石です。
2.5 対照実験 / ケーススタディ / n=1
ひとことで： 「実験」と名乗ると、その厳密さで反論される。身の丈に合った名前を使う。
- 対照実験：比べたい要因（独立変数）を1つだけ変え、それ以外を揃える厳密な比較。
- 交絡：要因以外の変数が混ざってしまい、原因を切り分けられない状態。
- ケーススタディ / n=1：単一事例の観察。一般化はできないが、仮説や気づきを得るには有効。
本検証は、モデル階級（中位 vs 最上位）・実行環境（IDE型 vs CLI型）・プロンプトの出し分けが同時に動いているため、厳密な対照実験ではなく n=1 の探索的ケース観察です。結論を「Aは常にBより上」と一般化せず、「この1ケースで何が観測されたか」に限定するのが誠実です。
3. ミニFAQ
Q. バイブコーディングって結局「丸投げ」では？
原義はそれに近い（コードの存在を忘れる）ですが、実務では「コードは書かないが、出力を読んで判断はする」という使い方が現実的です。判断のために、本用語集レベルの内部知識はむしろ必要になります。
Q. 自己評価が当てにならないなら、何を信じる？
他者（人間／別モデル）のレビューと、機械的に検証できる事実（grep・テスト・行数・リンターの出力）です。主観の数値より、客観の検出を上に置きます。
Q. 行数（LOC）が少ない方が良いコード？
必ずしも違います。ただし同じ要件で行数が大きく違うとき、多い側に重複・未使用・冗長が潜む確率は上がります。LOCは「品質そのもの」ではなく「疑う入口」です。
参考（一次情報）
- バイブコーディングの提唱と原義（Andrej Karpathy, 2025年2月）／用語解説：Simon Willison "Not all AI-assisted programming is vibe coding"（2025）https://simonwillison.net/2025/Mar/19/vibe-coding/
- "Vibe Coding" が Collins 辞書の2025年 Word of the Year に選定。 https://www.newsonair.gov.in/vibe-coding-named-collins-dictionarys-word-of-the-year-2025/
- 過信現象：Z. Tian et al., "Overconfidence in LLM-as-a-Judge"（arXiv:2508.06225, 2025）https://arxiv.org/abs/2508.06225
- 自己改善と較正：" Beyond Accuracy: The Role of Calibration in Self-Improving LLMs"（arXiv:2504.02902, 2025）https://arxiv.org/abs/2504.02902
- LLM-as-a-Judge の信頼性サーベイ：J. Gu et al.（arXiv:2411.15594, 2024）https://arxiv.org/abs/2411.15594
本記事は用語の理解を助ける補足であり、各定義は筆者による要約です。正確な仕様・最新情報は一次情報をご確認ください。
技術・キャリアの発信は Zenn と LinkedIn でもやっています。「この語の説明が分かりにくい」「この用語も足してほしい」があれば、コメントで教えてください。Vol.02（バックエンド編）の用語も随時このシリーズに追記していきます。