はじめ方と、
足場の棚卸し

最初に確かめるのは、作り方ではなく作るべきかどうかです。ここを飛ばして進めた案件は、後段の投資がまるごと無駄になります。

そして、進むと決めたなら評価タスクを先に20〜50件作ります。机上で理想を並べるのではなく、実際に起きた失敗から。採点できないものは改善もできないので、これは「準備」ではなく設計の一部です。詳しくはPart 6で扱いました。

導入検討でよく起きるのが、公表スコアをそのまま自社の期待値にしてしまうことです。

実務上の含意は3つです。

• <b>他社の数値は、そのままは使えない</b> — 自社のハーネスで測り直す。
• <b>モデルの差し替えは、静かな性能変化を伴う</b> — ハーネスはモデルの一部として働くため、入れ替えただけで挙動が変わる。
• <b>「モデルの評価」と「ハーネスの評価」は分ける</b> — 両方をまとめて回すと、どちらが原因か切り分けられない。

関連して、ツールの定義の「形」も中立ではありません。広く使われている形と大きく違うスキーマを採ると、モデルが存在しない引数を補ってしまう現象が報告されています。奇をてらった設計より、一般的な形に寄せるほうが安全です。

入門資料が「答え」だけを並べると、現場で例外に当たったときに動けなくなります。2026年8月時点で、実務家の間でも結論が割れている論点を挙げておきます。

• <b>エラーを残すか、消すか</b> — 「回復のための学習材料だから残せ」という実務側の主張と、「自分の誤りが文脈にあると以降の誤り率が上がる」という実験結果が併存する。両者を分離した検証はまだ無い。
• <b>圧縮するか、入り直すか</b> — 圧縮する実装、区切りで意図的に要約する実装、セッションごとリセットして引き継ぐ実装、そもそもスレッドを伸ばさない実装。主要な作り手の方針が割れたままである。
• <b>並列は効くのか</b> — 広く浅い調査系では大幅改善という報告と、相互依存する作業では有害という報告がある。前者はトークン消費が大きく増える条件付きで、コストを揃えた比較試験が無い。
• <b>足場はどこまで薄くできるか</b> — モデルの進化速度に依存するため、来年の最適解は今年と違う。だからこそ棚卸しの対象になる。
• <b>検索は、探索型か埋め込み型か</b> — 同じ条件で比較した統制実験が見当たらない。

これらは「まだ分かっていないから触れない」のではなく、自社で測る対象として設計に組み込むべき箇所です。片方を正解として実装を固めると、反例に当たったときに戻れなくなります。