← 2026-02-08 の一覧へ戻るホーム
「選択であり、予測ではありません」

2026/02/04 8:31

「選択であり、予測ではありません」

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Summary

本研究は、複数のコーディングエージェントを並行して実行し、最高品質の出力（“best‑of‑N”）を選択する方策が、単一エージェントに依存するよりも遥かに効果的であることを示しています。このアプローチは、言語・タスク種別・時間によって変動する予測不可能なエージェント性能を最適化問題へと転換します。

Methodology:
仕様書の作成から始まり、それを複数の隔離されたワークツリー上にあるエージェントへディスパッチし、リポジトリ評価を実行、最後に人間レビュアがマージ用に最適な差分を選択するというワークフローを構築しました。プロセスは、どのエージェントのパッチが実際にマージされたかを記録するリーダーボードで追跡されます。

Data & Findings (211 本の実世界 TypeScript タスク、18 エージェント):

  • 単一トップエージェントはわずか 24 % の確率で勝利します。
  • トップ3コホートでは成功率が約 51 % に上昇し、トップ7コホートでは 91 % 近くに達します。
  • 7番目以降のエージェント追加は減少限界を迎え（8–18 エージェントはほぼ僅かな向上しか提供しません）。
  • Bradley‑Terry/Elo モデリングでは、エージェント間に明確なパフォーマンス階層が示され、トップティアと下位ティアの間に顕著なギャップがあります。トップティア内では信頼区間が大きく重複しています。

Practical Implications:
トークン使用量は低コストである一方、人間レビュー時間は費用がかかるため、3–7 エージェントの小規模なコホートをデプロイすることで、マージ可能なパッチを生成する確率を最大化しつつオーバーヘッドを管理できます。この戦略は日常的な製品作業においてコード品質を向上させバグを減らす効果がありますが、他のワークフローやドメインでは結果が異なる可能性があります。

本文

コーディングエージェントはかなり優秀になってきており、誰もが尋ねる質問は「どれを使えばいいのか？」です。

しかし、エージェントの性能は言語・タスク種別・時間帯によって大きく異なります。単一のエージェントに固執すると、自分が投げるあらゆるタスクで最適だと予測してしまいます。この予測は評価結果、経験、口コミなどから導かれることもありますが、ばらつきが大きいため、しばしば誤ってしまうでしょう。

選択（Selection）はその予測問題を回避します。多くの候補実装を生成し、その中から最良のものを選びます。つまり、予測問題を最適化問題に変換するわけです。そのため、我々が尋ねるべき質問は「何人のエージェントを使うか、そしてどれを選ぶか？」であり、これは一般的に「best‑of‑N」と呼ばれます。N個の並列試行（ここでは異なるモデル）を実施し、その中から最高の出力を選び取ります。

エージェントは競い合い、人間が仲裁する

数か月前からこのワークフローを運用しています。以下にその流れを示します。

  1. タスク仕様を書き、複数のエージェントへ並列で配信
  2. 各エージェントは独立した作業ツリー（worktree）で動き、リポジトリ内の評価（evals）を実行
  3. 人間レビュアーが差分(diff)を確認し、最適な実装を選択 そのパッチをマージ
  4. マージされた diff を生成したエージェントが「勝者」となる

これは人間審査付きの best‑of‑N です。日常業務を有用な評価信号に変換します：実際のコードベースでリアルタスクを与えたとき、どのエージェントがマージされたコードを生成したか？ このデータは実際の日々の作業から得られ、18種類のエージェントで211タスクにわたり収集されています。リーダーボードで継続的に結果を追跡しており、以下のプロットはそのスナップショットです。

ほとんどのタスクはフルスタックTypeScript製品作業で、原子単位の機能追加・バグ修正・リファクタリングなど、数分から約1時間程度のものが多いです。

ランキングはノイズが大きい

各実行に勝者が決まれば、それをマルチウェイ（複数相手）マッチとして扱い、結果からレーティングを推定できます。Bradley–Terry モデルで勝敗ペアをフィッティングし、強さをElo風のレーティングにマッピングします。

  • 各点はエージェントのレーティング（高いほど良い）
  • ウィスカーは90％ブートストラップ信頼区間、色はモデルファミリーを示す

データ全体で見ると、エージェントは自然に階層化されます。トップティアとそれ以外との明確なギャップがありますが、その中でも上位二者の信頼区間は大きく重なります。スナップショットでは gpt‑5‑2‑high と gpt‑5‑2‑codex‑high が約40ポイント重複しており、1位と2位を確実に分けることはできません。

ランキング自体は存在しますが、ノイズが大きく、トップレーティングモデルでもタスクごとのばらつきが期待できます。リーダーボードから一つだけエージェントを選ぶなら、そのばらつきを考慮に入れる必要があります。

選択のメリットは大きい

単一エージェントではなく、複数（コホート）を走らせることでどれだけ得点が上がるかを測定します。評価は「少なくとも1人以上が参加した実行で勝率」を用います。例えばトップ3のエージェントを走らせた場合、その中の誰かがマージされた diff を生成する頻度です。

  • x軸：コホートサイズ（レーティング順）
  • y軸：そのコホートに少なくとも1人が参加した実行での勝率

データ全体から：

コホート勝率
トップ124 %
トップ351 %
トップ791 %

最初の数人が最大の影響を与え、7人以降は曲線が平坦になり、8〜18番目のエージェントで得られる確率向上はわずかです。すべてのエージェントを走らせる必要はありませんが、1つだけに固執すると多くの場合より良いコードを残してしまうことになります。

結論

コーディングエージェントは性能階層に分かれ、トップティア内では差が薄くノイズが大きいです。リーダーボードは有用であり、主に「デフォルトの単一エージェント」ではなく「複数（コホート）」を選択する際のガイドとして機能します。特定タスクで最適なエージェントを事前に予測することは難しいですが、トップティアから数人を走らせれば、ほとんどの場合その中の1つが正解を導きます。

データでは、1人から3人へ移行すると勝率が約2倍になり、3人から7人に増やすことで残余の利益を大部分捉えられます。これは我々の日常製品作業で得た結果ですので、ワークフローやドメインが異なる場合は結果も変わる可能性があります。

トークンは安価で、人間のエンジニアリング時間は高価です。より良い基盤を得て、後続作業のクリーンアップやバグを減らすために、少し多めにエージェントを走らせる価値があるかもしれません。

同じ日のほかのニュース

一覧に戻る →

2026/02/08 6:45

小型 C コンパイラ

## Japanese Translation: Tiny C Compiler（TCC）は、非常に小さな（約100 KBのx86実行ファイル）Cコンパイラであり、1回のステップでコンパイル・アセンブル・リンクを行い、バイトコード層なしでネイティブx86マシンコードを生成します。2.4 GHz Pentium IV上では、Links BrowserテストをGCC（20.0 秒）より約10倍速く実行できます（2.27 秒）。これは別のコンパイルステージが不要であるためです。 TCCはISO C99を完全にサポートし、自身をコンパイルでき、任意のC動的ライブラリを直接リンクすることも可能です。完全なプリプロセッサ、GNUスタイルのアセンブラー構文、オプションのメモリと境界チェック機能、さらにはシェバンベースの「Cスクリプト」まで含まれ、コマンドラインから実行できます。libtccライブラリにより、他のプログラムがTCCをランタイムコード生成のバックエンドとして使用できるようになります。 性能テストはPentium IV上で行われました。新しい測定値（参照1–4）では、モダンハードウェアでも速度向上が継続しています。ドキュメント、メールリストサポート、およびSavannah/GitHubリポジトリは最新情報を提供します。 TCCはGNU Lesser General Public License（LGPL）の下で配布されており、商用利用も許可されています。

2026/02/08 8:23

**良質なコードの静かな終焉**

## Japanese Translation: 著者は中学時代から「Good Code™」―読みやすく、保守しやすく、特定の目的を持って存在するコード――を書き続けることに情熱を注いできました。機能提供に重点を置くソフトウェアエンジニアとして、彼は今日の高速開発環境で良いコードがますます希少になっていると感じています。 同僚の経験はこの状況をよく示しています。外部Linuxカーネル統合システムをCからRustへ書き換えた後、最初のバージョンは機能していたものの読みづらく保守が困難でした。原始的なCロジックを学習した上で再度書き直すと、コードはクリーンになり、自明であり、元のCよりも優れていると言えるようになりました。この経験が著者に品質コードへの熱意を再燃させました。 現在、彼はほとんどの場合初期バージョンを書かず、代わりに「Good Code™」ではなく許容できるものを生成するコーディングエージェントに頼っています。このようなツールへの継続的な依存が個々の行レベルでの品質への注意を薄め、業界実務におけるGood Codeの静かな消滅を招くと彼は恐れています。コード品質が低下すると保守コストや技術的負債が増大し、開発者の生産性、製品の信頼性、そして最終的には企業から提供されるソフトウェアへのユーザーの信頼まで損なわれます。

2026/02/08 2:39

**セクターC：512バイトで実装されたCコンパイラ**

## Japanese Translation: SectorCは、x86‑16アセンブリで完全に書かれたCコンパイラで、単一の512バイトのブートセクタに収まります。Ultra‑compactなトークン化スキーム「Barely C」を使用しており、各スペース区切り語を「メガトークン」とみなし、`atoi()`で識別子をハッシュし64Kテーブルに格納します。変数はこのハッシュを通じてセグメント0x3000に保存されます。最初のBarely C実装は468バイトで、シンボルテーブルなしの再帰下降パーサーでした。バイトスレッド化されたForth風の変種も試みられましたが、サイズをさらに削減することはできませんでした。 最終的なコンパイラはわずか **303 バイト** です。サイズは、フォールスルーロジック、テイルコール、コールフュージョン、`lodsw/stosw`の広範な使用、およびすべてのジャンプオフセットを1バイト内に収めるなどの手法で削減されました。残り約200バイトでBarely Cは完全なCサポートへと拡張されました：ネストされたif/whileブロック、包括的な演算子集合（+, −, *, &, |, ^, <<, >>, ==, !=, <, >, <=, >=）、ハッシュテーブルを介した関数定義と再帰、インライン`asm`ステートメント、および単一行(`//`)と複数行(`/* */`)コメントの両方が実装されました。 コンパイラのランタイムは `rt/` ディレクトリ内の2つのCファイルに分かれています：ライブラリルーチン（多くの場合インラインasmを含む）を持つ `lib.c` とエントリポイントとして機能する `_start.c` です。これらはプログラムソースと結合してからコンパイルされます。記事には、全ブートセクタのBase64文字列、VGAモード0x13hで動くサイン波を描画するデモ、および追加例（`hello.c` はビデオメモリ0xB8000に書き込み、`twinkle.c` はPCスピーカーで「Twinkle Twinkle Little Star」を再生）が含まれています。この作業は、512バイトという一見不可能な目標—完全機能のCコンパイラを実現すること—が、創造的なトークン化、ハッシュ化、および積極的なコードサイズ最適化によって達成できることを示しています。