ハーネス・エンジニアリングが、次の10年の堀になる理由

AIの能力を「仕事の成果」に変える仕組みを持つ者が勝つ

AIへのアクセス格差は、もう消えた。

Claude、GPT、Gemini——どのモデルにも誰でもアクセスできる。APIの価格は四半期ごとに下落し、アクセス障壁はほぼゼロになった。APIキーひとつで、世界最高水準の推論能力を呼び出せる。
モデル間の得意不得意は依然として存在するが、どのモデルにもアクセスできること自体は、もはや競争優位にならない。

それなのに、現実の成果には10倍の差が開いている。

Sequoia Capitalが2025年末に報告した数字が、この格差を端的に示している。

AIを業務基盤に組み込んだ新興企業群は、従業員1人あたり100万ドル超の収益という驚異的な効率を叩き出している（David Cahn, "AI in 2026: A Tale of Two AIs", 2025年12月）。

法務、採用、営業——かつて人手に依存していた業務をAIエージェントに委ね、人間は判断とドメイン知識の蓄積に集中する。一方、社内でのAI実装に苦戦するエンタープライズは、同じモデルにアクセスしながら従来の生産性に留まっている。同じエンジンを積んでいるのに、一方は時速200kmで走り、もう一方はガレージから出られない。この差は何か。

ハーネスだ。

ハーネスとは、AIに仕事を任せるための 「手順・評価・安全策・記録」の統合的な仕組み を指す。

もう少し正確に言えば——AIという強力なエンジンを載せるための「車体」である。エンジンがどれほど高性能でも、車体がなければ走れない。サスペンションがなければ路面の凹凸で弾き飛ばされ、ブレーキがなければ壁に激突する。

ハーネスは、AIの生の能力を制御可能な仕事の成果に変換する構造体だ。

この事実を最も鮮烈に示したのが、OpenAIが公開したSWE-bench大規模実験だ（2025年2月発表、同社Engineering Blog）。

エンジニア3人、5ヶ月、100万行のコード。そして人間は1行もコードを書いていない。 彼らが5ヶ月間ひたすら磨いていたのは、コードそのものではなかった。AIに「何を」「どの順序で」「どう評価して」「失敗したらどう戻すか」を伝える仕組み——すなわちハーネスだった。

彼らはプログラマーではなく、ハーネス・エンジニアとして振る舞っていた。

ここで重要な問いが浮かぶ。ハーネスを整備すれば、それだけで勝てるのか。答えはノーだ。ハーネスは「仕組み」に過ぎない。真の競争優位、つまり堀（moat） は、ハーネスを回し続けることで蓄積される3つの層から生まれる。

第1層は、自社固有データだ。 市場に公開されていない業務データ、顧客との対話履歴、社内で暗黙知として眠っている判断基準。

これらはLLMの学習データには存在しない。ハーネスを通じてAIに注入することで初めて、汎用モデルが「自社専用の判断装置」に変わる。

第2層は、因果的理解だ。 単にデータを持っているだけでは足りない。「この施策を打てば、なぜこの結果が出るのか」という因果の連鎖を、ハーネスの評価基準とフィードバックループの中に埋め込む。

相関ではなく因果。これをAIの判断プロセスに組み込むことで、再現可能な意思決定が生まれる。

第3層は、改善サイクルの時間蓄積だ。 ハーネスを1回まわすたびに、成功と失敗の記録が残る。その記録が次の実行の精度を上げ、精度が上がった実行がさらに良質な記録を生む。

この複利的な改善ループは、始めた時期が早いほど追いつけなくなる。 後発がどれほど優秀なエンジンを積んでも、先行者が1年間まわし続けたサイクルの蓄積は買えない。

堀の本質を一言で表せば、「自社コンテキスト × 回転数 × 時間」が生む不可逆的な学習蓄積だ。この3つの変数の掛け算は、時間が経つほど指数的に拡大する。そして一度失った時間は、資金では取り戻せない。

冒頭の車体の比喩に戻ろう。多くの企業がAIの「成果物」、つまり生成されたコードやレポート、分析結果に目を奪われている。

しかし成果物は走行結果に過ぎない。その結果を叩き出した車体——ハーネスの中に蓄積された手順、評価基準、失敗からの学習、ドメイン知識の構造化——がなければ、次のレースは走れない。

走行結果だけを真似ても、車体を持たない者は再現できない。競争優位は走行結果ではなく、車体の中にある。

では、この堀はどのような構造で形成されるのか。本記事ではまず6つの章で理論を論じ、続く4つの章で筆者自身の実装を通じた検証と発見を記録する。

第1章｜ソフトウェアが「労働」を食い始めた

—— 市場構造の転換と、それでも埋まらないギャップ

ソフトウェアの役割が、根本から変わろうとしている。

過去30年間、企業向けソフトウェアが担ってきたのは 「記録の置き場所」 だった。顧客情報をCRMに格納し、会計データをERPに流し込み、プロジェクトの進捗をタスク管理ツールに転記する。

どれほど洗練されたSaaSであっても、その本質は「人間が行った業務の結果を整理・保管するシステム」にすぎなかった。業務そのものを実行するのは、あくまで人間だ。

AIエージェントが変えるのは、まさにこの前提である。AIが狙っているのは「記録の置き場所」ではない。「業務の実行主体」そのものだ。

この転換の規模感を数字で捉えておきたい。グローバルSaaS市場は約3,000億ドル（Gartner, 2025年推計）。

巨大に見えるが、これは「ソフトウェアのライセンス料」という狭い市場にすぎない。一方、AIエージェントが代替し得る人間の労働市場は約13兆ドルに達する（a16z推計、米国ナレッジワーカー労働コストベース）。

Andreessen Horowitz（a16z）のパートナーが端的に表現した通り、いま起きているのは「Software is eating the world」の次の段階、 「Software is eating labor」 だ。

ソフトウェアが世界を飲み込んだ時代の次に、ソフトウェアが労働そのものを飲み込む時代が来ている。市場の天井が一桁どころか二桁近く跳ね上がるという事実を、過小評価すべきではない。

この13兆ドルは抽象的な数字ではない。Sequoia Capitalの分析（Julien Bek, "Services: The New Software", 2026年3月）が、労働予算ベースで侵食可能な市場をセグメント別に可視化している。

経営コンサルティングに3,000〜4,000億ドル、サプライチェーン・調達と採用・スタッフィングにそれぞれ2,000億ドル超、保険仲介に1,400〜2,000億ドル、IT管理に1,000億ドル超。いずれも「ソフトウェアのライセンス料」ではなく「人間の労働コスト」として計上されてきた予算だ。AIエージェントが狙うのは、まさにこの「労働予算」である。

1-1. コパイロットか、オートパイロットか

では、AIはどのような形で労働を代替していくのか。Sequoia Capitalが提唱した 「Sell the Work」 というフレームワークが、この問いに明快な分岐線を引いている。

一方にあるのがコパイロット型だ。人間の隣に座り、提案や下書きを行い、最終判断は人間に委ねる。GitHub Copilotがその典型であり、コードの補完は行うが、何を作るかを決めるのは開発者自身である。もう一方にあるのがオートパイロット型だ。タスクの入力から出力まで、人間の介在なしに完遂する。請求書の処理、定型的な顧客対応、データ入力といった業務が、すでにこの領域に入りつつある。

この分岐をさらに鋭くする補助線がある。Sequoia Capitalが提示した 「インテリジェンス」と「ジャッジメント」 の区別だ（Julien Bek, 前掲）。

インテリジェンスとは、複雑だが規則的な作業を指す。コーディング、データ抽出、文書要約がその例であり、AIはすでにこの閾値を超えた。

ジャッジメントとは、経験・直感・センスに基づく意思決定だ。何を構築するか、どのリスクを許容するか。ここはまだ人間に依存している。

コパイロット型はジャッジメント領域で人間を補助し、オートパイロット型はインテリジェンス領域を丸ごと代替する。そして重要なのは、モデルの進化に伴い、ジャッジメント領域の境界線は後退し続けるという事実だ。今日のジャッジメントは、明日のインテリジェンスになる。

この分岐は、ビジネスモデルの根本的な転換を伴う。コパイロット型は従来のSaaS同様「席数課金」で成立するが、オートパイロット型は 「成果課金」 に向かわざるを得ない。

なぜなら、業務を完遂するAIに対して「何人が使ったか」で課金するのは論理的に破綻するからだ。顧客が求めているのは「AIへのアクセス権」ではなく「業務が完了した事実」である。席数課金の終焉と成果課金への移行は、一時的なトレンドではない。不可逆な構造変化だ。

1-2. どこから食い始めるか

13兆ドルの労働市場は広大だが、AIエージェントが最初に侵食するポイントには明確なパターンがある。すでにアウトソーシングされている業務だ。

これは合理的な参入戦略である。BPO（ビジネス・プロセス・アウトソーシング）に外注されている業務は、三つの条件を満たしている。

第一に、手順が十分に標準化されていること。標準化されていなければ外注できない。

第二に、品質の評価基準が明確であること。成果物の良し悪しを判定できなければ外注先を管理できない。

第三に、すでに「外部に任せる」という組織的な意思決定が済んでいること。心理的な障壁が低い。コールセンター、経理処理、法務レビューの一部、採用スクリーニング。これらの領域でAIエージェントが急速に浸透しているのは偶然ではなく、構造的な必然である。

そしてこの浸透は、もはや理論上の可能性ではなく実績として現れている。a16zのKimberly Tanが2025年2月に報告した事例（"Unbundling the BPO"）が示唆に富む。

カスタマーサポートAIのDecagonは問い合わせ解決率80%とCSATスコアの改善を達成し、ヘルスケアRCM（収益サイクル管理）のCamberは初回申請の否認を80%削減、クレーム処理時間を50%短縮した。

この報告から1年以上が経った現在、3,000億ドル超のBPO市場の解体はさらに加速している。

1-3. ケイパビリティ・オーバーハングという名の巨大なギャップ

しかし、ここで一つの厄介な現実に目を向けなければならない。AIの技術的能力と、組織がそれを活用できている度合いとの間には、巨大なギャップが存在する。これを「ケイパビリティ・オーバーハング」と呼ぶ。

GPT-4が登場してから3年以上が経つ。コーディング支援、文書要約、データ分析、画像生成。技術的には驚くべき水準に達している。

にもかかわらず、多くの企業で「AI活用」は依然としてPoC（概念実証）の域を出ていない。チャットボットを試し、社内向けのRAGを構築し、経営会議で「AI推進」のスライドを見せる。

だが、基幹業務のプロセスにAIが深く組み込まれ、人間の仕事のやり方が根本的に変わったと言い切れる企業は、まだ圧倒的に少数だ。

AIが「できること」は急速に拡大している。しかし組織が「使いこなせていること」は、それに遠く及ばない。このオーバーハングこそが、次の10年における最大の事業機会であり、同時に最大の経営課題である。

1-4. 産業革命が教える「Jカーブ」の教訓

このギャップに焦りを感じる経営者は多い。「AIに投資したのにROIが見えない」「PoCは成功したのに全社展開が進まない」——こうした声は、しかし、歴史的に見れば極めて自然な現象だ。

経済史家のErik Brynjolfssonらが示した 「生産性Jカーブ」 の研究が、ここでの道標になる。

電力が工場に導入された19世紀末、生産性はすぐには向上しなかった。蒸気機関時代の工場は動力源を中心に機械を密集させる設計だったが、電力は各機械に個別モーターを取り付け自由に配置できる。

この特性に合わせて工場を再設計するまでに、20年以上を要した。新技術の導入直後は、むしろ生産性が一時的に低下する。旧来のプロセスが壊れ、新しいプロセスが確立されるまでの移行コストが発生するためだ。

そして十分な補完投資（組織構造の変更、人材の再教育、業務プロセスの再設計）が積み重なった後に、生産性は急角度で上昇する。これがJカーブの形状である。

AIにおいても、同じ構造が繰り返されている。補完投資なき導入は、PoC止まりで終わる。 これは技術の失敗ではなく、導入戦略の未成熟だ。

モデルの性能がいかに高くても、データパイプラインが整備されず、業務プロセスが旧来のままで、現場の担当者がAIの出力を信頼する訓練を受けていなければ、効果は発現しない。

産業革命の工場が電力用に再設計されたように、企業はAI前提で業務とオペレーションを再構築しなければならない。

効果がすぐに見えないのは、失敗の兆候ではない。Jカーブの底にいるだけだ。 問題は「AIは使えない」ではなく、「AIを使いこなすための補完投資が足りていない」にある。そしてこの補完投資を正しく行える組織だけが、Jカーブの上昇局面で圧倒的な差をつけることになる。

市場の構造転換は明白だ。SaaSの「記録管理」から、AIエージェントの「業務遂行」へ。席数課金から成果課金へ。13兆ドルの労働市場が、ソフトウェアに食われ始めている。同時に、技術的に可能なことと組織が実現できていることの間には、巨大なオーバーハングが横たわっている。これは脅威であると同時に、途方もない機会でもある。

しかし、ここで根源的な問いが浮かぶ。誰もが同じ基盤モデルにアクセスできる時代において、いったい何が企業間の競争優位を分けるのか。 産業革命の教訓が示すとおり、答えは汎用技術そのものではなく、それを成果に変える補完投資の中にある。

第2章｜何に投資すべきか

—— The Bitter LessonとTest-Time Computeが示す設計原則

前章で示した問いに戻ろう。ケイパビリティ・オーバーハング——AIの能力と組織の活用度の断崖——を埋めるには、何に投資すればよいのか。答えを導くために、まずAI研究史における最も痛い教訓から始めたい。

2-1. 手作りのルールは、いずれ飲み込まれる

2019年、強化学習の父と呼ばれるRich Suttonが短いエッセイを公開した。タイトルは"The Bitter Lesson"、苦い教訓。その主張はこうだ。「AI研究70年の歴史が繰り返し示してきたのは、人間の知識を作り込むアプローチは、最終的に計算量を活かす汎用的手法に敗北するという事実である。」

チェスを思い出せばわかりやすい。1990年代、IBM Deep Blueはグランドマスターの定跡をハードコードしてカスパロフを破った。だが今日の最強チェスエンジンは、ルールを一切教わらず、自己対戦の膨大な計算だけで人間の棋理を超えた。音声認識も同じ軌跡をたどった。言語学者が音素規則を丹念に書き上げた専門家システムは、ディープラーニングと大量データの組み合わせにあっさり置き換えられた。

この教訓をソフトウェア開発に翻訳すると、次の原則が浮かび上がる。探索の手順を固定するif文に投資するな。品質の判定基準に投資せよ。 ただし、後述する安全柵（「やってはいけないこと」を遮断するルール）は、むしろ積極的に固定すべきだ。ルールを否定しているのではない。ルールを置く場所が問題なのだ。「どう解くか」をハードコードするな。「何を通してはいけないか」はハードコードせよ。

多くの企業がAIを導入する際、まず「業務プロセスをフローチャートに落とし、各分岐をプロンプトで制御する」というアプローチを取る。これは一見合理的だ。しかしThe Bitter Lessonの視点から見れば、それは1990年代の専門家システムと同じ構造を持っている。人間が作り込んだ分岐ロジック、つまり探索手順のハードコードは、モデルの能力が一段上がった瞬間に負債へと反転する。GPT-3.5用に100本のif文で組んだワークフローは、GPT-4oの登場で半分が不要になるか、むしろ足枷になる。

では何に投資すべきか。答えは 「良し悪しを判定する仕組み」 だ。手順ではなく、品質基準。プロセスではなく、評価関数。LLMの出力が「合格」か「不合格」かを高い精度で判定できる仕組みさえあれば、中間のプロセスはモデルに任せてよい。モデルが進化すれば、同じ評価関数のもとで——人間が何も変えなくても——出力品質が自動的に上がる。

2-2. 直線から探索ループへ

——Test-Time Computeの衝撃

The Bitter Lessonが「何に投資すべきか」を示すなら、Test-Time Computeは「どう使うべきか」を示す。

従来のLLM活用は、本質的に1本の直線だった。プロンプトを入力し、一発で回答を得る。しかし2024年以降、OpenAIのo1・o3、GoogleのGemini Flash Thinking、AnthropicのClaude。各社のフロンティアモデルが示したのは、推論時に計算量を動的に配分するという設計思想だ。

仕組みを単純化すると、こうなる。モデルがまず回答を生成し、自ら「これは正しいか」と判定し、不十分なら再び考え、再判定する。判定→実行→再判定のループ。このループを何回まわすかは、問題の不確実性に応じて動的に変わる。簡単な質問には1回で済む。複雑な推論には10回、20回と探索を重ねる。

ここで重要なのは、このアーキテクチャが先ほどのThe Bitter Lessonと完全に整合するという点だ。人間がステップバイステップの手順を書く代わりに、「正解かどうかの判定基準」を与え、あとはモデルに探索させる。計算量を注ぎ込めば注ぎ込むほど品質が上がる——スケーリング則が推論フェーズにまで拡張されたのだ。

企業のAI設計にとって、この示唆は決定的に大きい。ワークフローを「入力→処理A→処理B→出力」という固定パイプラインで組む時代は終わる。代わりに、「入力→生成→検証→（不合格なら）再生成→再検証→…→出力」という探索ループを基本単位として設計すべきだ。不確実性の高いタスク（法務レビュー、コード生成、戦略提案）ほどループの回数を増やし、確実なタスク（フォーマット変換、定型文生成）は1パスで通す。計算コストの動的配分。これが次世代のAIシステム設計の基本原則になる。

2-3. アンディ＆ビルの法則、AI版

1990年代のPC産業に「アンディ（Intel CEO）が与えたものを、ビル（Microsoft CEO）が奪う」という格言があった。Intelがプロセッサを高速化しても、Windowsの新機能がその性能をすべて食い尽くす。結果としてユーザーは常にPCを買い替え続けた。この共進化の構造こそが、PC産業30年の爆発的成長を支えたエンジンだった。

AIにおいても、まったく同じ構造を意図的に設計できる。いや、設計しなければならない。

具体的にはこういうことだ。もしあなたのプロダクトが「GPT-4oの能力」を前提に設計され、その天井に最適化されているなら、GPT-5が出ても何も変わらない。プロンプトの分岐が固定され、出力フォーマットが決め打ちされ、後処理のルールが能力の下限に合わせてチューニングされている。モデルが進化しても、プロダクトの価値は1ミリも上がらない。

逆に、プロダクトの設計思想が 「評価関数＋探索ループ」 であれば、話は180度変わる。モデルが賢くなれば、同じ探索回数でより高品質な出力が得られる。あるいは、同じ品質をより少ない探索（つまりより低コスト）で達成できる。LLMの性能向上が、そのままプロダクト価値の上限引き上げに直結する構造。これがAI時代のアンディ＆ビルの法則だ。

この構造を持つ企業と持たない企業の差は、モデルの世代が進むたびに指数関数的に開いていく。前者はモデル進化のたびに自動的に競争力を獲得し、後者はそのたびにプロンプトの書き直しとワークフローの再構築に追われる。

2-4. 品質保証の地殻変動

——決定論から確率論へ

最後にもうひとつ、見落とされがちだが本質的な転換を指摘しておきたい。品質保証のパラダイムが変わる。

従来のソフトウェアは決定論的だった。同じ入力には必ず同じ出力。だからテストは「OK/NG」の二値で判定できた。しかしLLMの出力は確率的だ。同じプロンプトに対して毎回微妙に異なる回答が返る。この世界では、「正解かどうか」を二値で判定しようとすること自体が設計ミスになる。

求められるのは、 「明らかな誤りを高い確率で排除する」 という確率論的な品質保証だ。100%の正解保証ではなく、99.5%の不良排除。医療AIではすでに常識になっている感度と特異度のトレードオフ管理が、あらゆるAIプロダクトの品質設計に浸透していく。

そしてここでも、The Bitter Lessonの原則が生きる。人間が判定ルールをハードコードするのではなく、良い出力と悪い出力の大量の実例をモデルに学習させ、判定自体もスケーラブルにする。この評価のスケーラビリティこそが、ケイパビリティ・オーバーハングを埋める投資の核心にある。

ここまでをまとめよう。The Bitter Lessonは「手順ではなく評価に投資せよ」と告げる。Test-Time Computeは「直線ではなく探索ループで設計せよ」と告げる。アンディ＆ビルの法則AI版は「モデル進化を自動的に取り込む構造を作れ」と告げる。三つの原則が指し示す方向は一致している。固定的なプロセスから、適応的な探索と評価の構造へ。

では、その構造は具体的に何で構成されるのか。

第3章｜ハーネスの4成果物

—— 堀を「深さ×幅」で設計する

前章で導いた原則は明快だった。探索手順ではなく判定基準に投資せよ。直線ではなくループで設計せよ。 だが原則だけでは動かない。エンジニアが明日から手を動かすには、「その構造は具体的に何で構成されるのか」という問いに答えなければならない。

答えは4つの成果物——ワークフロー、評価セット、安全柵（ガードレール）、ログ資産——である。この4つが車体のパーツとして組み上がるとき、企業の周囲には競合が容易に越えられない構造的な堀が形成される。車体の性能は、エンジン（パワートレイン）とシャシー（足まわり）の掛け算で決まる。ハーネス・エンジニアリングの堀も同じだ。個々の業務における品質蓄積が「深さ」、AIを適用できる業務領域の広さが「幅」。堀は「深さ×幅」の乗算で設計する。

3-1. 勝ちパターンのワークフロー

—— 属人知を形式知に変換する

どの組織にも「なぜかあの人がやると速い」という業務がある。与信審査、求人票の作成、障害の一次切り分け——属人的な勘と経験が詰まった暗黙知だ。問題は、暗黙知はスケールしないことにある。人が辞めれば消え、繁忙期に倍にはできない。

ワークフローとは、この属人的な勝ちパターンをYAMLやコードとして形式知に変換したものだ。「まず顧客の業種を分類し、次にリスクスコアを算出し、閾値を超えたら人間にエスカレーションする」。この手順をAIエージェントが再現可能な構造として定義する。Anthropicが提唱するエージェント設計パターンでも、単純なプロンプトチェーンではなくルーティング・並列処理・ループといったプリミティブの組み合わせが推奨されている。重要なのは、ワークフローそのものが「正解」ではないということだ。ワークフローは仮説にすぎない。仮説を検証するために、次の成果物が要る。

3-2. 評価セット

—— 「良さそう」を「測定可能」に変える

AIの出力を見て「良さそうだ」と感じる。だが、その感想は再現できない。昨日「良い」と判断した基準と今日の基準が同じである保証はどこにもない。評価セットは、改善を「感想」から「検証可能な方向収束」に変えるための装置だ。

具体的には、入力・期待出力・評価基準の三つ組をデータとして蓄積する。GoogleのBIG-benchやOpenAIのSimple Evalsがモデル性能を定量化したように、企業は自社業務のベンチマークを自社で持たなければならない。たとえば保険会社なら「過去100件の査定事例に対し、AIの判断が人間の判定と一致する割合」が評価セットになる。これがなければ、モデルを更新するたびに品質が上がったのか下がったのかすら分からない。暗闇でダーツを投げているのと同じだ。

評価セットがあるからこそ、ワークフローの変更がリグレッション（退行）なのかプログレッション（前進）なのかを即座に判別できる。テスト駆動開発におけるテストスイートと同じ役割だが、対象がコードではなく業務品質そのものである点が異なる。

3-3. 安全柵（ガードレール）

—— 実験を基幹業務に昇格させるゲート

多くの企業がAIを「実験」としては導入できている。だが「基幹業務」には踏み込めない。理由は単純で、失敗したときの損害が許容範囲を超えるからだ。 顧客対応のチャットボットが不適切な回答をする。財務レポートの数値が誤っている。医療記録の要約が重要な所見を落とす。こうしたリスクが「実験止まり」の壁を作っている。

安全柵は、この壁を突破するための構造的なゲートである。出力に個人情報が含まれていないか。数値が元データと整合しているか。禁止表現を使っていないか。これらをルールベースまたはLLM-as-a-Judgeで自動検査し、基準を満たさない出力を遮断する。AnthropicのConstitutional AIやNVIDIA NeMo Guardrailsが示したように、ガードレールは「AIの能力を制限する足かせ」ではなく、AIの適用範囲を拡張するイネーブラーだ。

安全柵が堅牢であればあるほど、経営層は「この業務にもAIを使っていい」と判断できる。つまり安全柵は堀の幅——AIを適用できる業務領域の広さ——を直接的に規定する。

3-4. ログ資産

—— 成功も失敗も再利用可能な知識基盤にする

4つ目の成果物は、最も地味でありながら最も過小評価されている。ログ資産とは、ワークフローの実行履歴——成功・失敗・判断の分岐点——を構造化して蓄積した知識基盤だ。

なぜログが「資産」なのか。それは、ログが次のループの燃料になるからだ。「このプロンプトパターンは評価スコアを12%改善した」「この安全柵ルールは誤検知率が高すぎた」「この業務ではモデルAよりモデルBのほうが一致率が高かった」。こうした因果の断片が、時間とともに積み上がる。Teslaが走行データを自動運転モデルの改善に還流させるように、ログ資産はハーネスの自己改善ループを駆動するデータフライホイールとなる。

重要なのは、ログは意図的に設計しなければ資産にならないということだ。非構造的なテキストログを大量に溜めても、それはゴミの山にしかならない。実行ID、入力ハッシュ、評価スコア、判断理由、所要時間。検索・集計・比較が可能な構造で記録して初めて、ログは資産に変わる。

3-5. 4つのパーツが組み上がるとき

—— 堀の乗算構造

4つの成果物は独立して存在するのではない。ワークフローで実行し、評価セットで検証し、ログで記録し、その知見でワークフローを改善する。 この循環が一回転するたびに、堀の「深さ」——すなわち各業務における品質と効率の蓄積——が増す。同時に、安全柵の成熟が新たな業務領域への適用を可能にし、堀の「幅」が広がる。

堀の総量は加算ではない。深さ×幅の乗算だ。 10の業務で浅く使うよりも、3つの業務で深く回し、その安全柵を横展開して6つ、9つと広げるほうが、堀の総量は指数的に大きくなる。

この堀がなぜ模倣困難なのか。理由は3層ある。

第一に、コンテキストの固有性。ワークフローも評価セットも、その企業の業務プロセス・顧客特性・失敗履歴という固有のコンテキストから生成される。汎用テンプレートをコピーしても、この固有性は再現できない。

第二に、因果モデルの内面化。「なぜこのプロンプトが効くのか」「なぜこの安全柵が必要なのか」という因果の理解は、ループを回した組織の中にしか蓄積されない。

第三に、そして最も根本的な理由が、時間の非圧縮性だ。1000回のループから得られた知見を、競合が100回で追いつくことはできない。時間は圧縮できない。

OpenAIやAnthropicが成果課金モデルへ移行しつつある現在、AIの「利用コスト」はコモディティ化する。そのとき競争優位の源泉は、AIそのものではなく、AIの出力品質を測定し、保証し、継続的に改善する仕組み——すなわちハーネスの4成果物——の側に移る。APIを叩くだけなら誰でもできる。だが、その出力が自社の基準を満たしているかを即座に判定し、満たしていなければ自動で修正ループに入れる仕組みは、回した者だけが持てる。

車体のパーツは揃った。だがパーツを棚に並べても、車は走らない。

第4章｜堀を深くし続ける

—— 静的な成果物から動的な改善ループへ

前章では、ハーネス・エンジニアリングが生み出す4つの成果物——ワークフロー、評価セット、安全柵、ログ資産——が「深さ×幅」の堀を形成することを論じた。だが、堀は築いた瞬間から風化が始まる。成果物は存在するだけでは堀にならない。堀を堀たらしめるのは、改善ループの回転速度と持続性だ。

車体を想像してほしい。走るたびにデータを取り、サスペンションを調整し、ブレーキの効きを検証する。メンテナンスを怠れば、どれほど高性能な車体もやがて陳腐化する。成果物という「パーツ」を、改善という「チューニング」で絶えず磨き上げること——それが本章の主題である。

4-1. 評価の3レイヤー

——「動く」と「使える」と「稼げる」は別の問いだ

改善ループを回すには、まず「何を測るか」を定めなければならない。ここで多くのチームが陥る罠がある。機能テストが通ったことを、価値の証明と混同するのだ。

評価には3つのレイヤーが存在する。

第1レイヤーは機能評価だ。AIエージェントが指示通りに動くか。ワークフローが最後まで走るか、出力フォーマットは正しいか。これはソフトウェアテストの延長線上にあり、自動化も容易だ。

第2レイヤーはユーザー反応だ。その出力は実際に使われるか。生成されたレポートを人間が読み、意思決定に採用するか。ここからは定量化が一気に難しくなる。

第3レイヤーはKPI連動だ。最終的に事業指標を動かすか。分析レポートが投資判断の精度を上げたか、業務プロセスの再設計が工数を削減したか。

GoogleのMLOps実践が示すように、モデルの精度改善と事業KPIの改善は必ずしも相関しない。第1レイヤーで95点を取っても、第3レイヤーでは何も動かないことがある。逆に、第1レイヤーが80点でも、ユーザーの意思決定速度を2倍にすれば事業価値は絶大だ。改善ループが回すべき対象は、この3レイヤーすべてである。 そして、レイヤーが上がるほど評価の遅延は大きくなり、フィードバックの解像度は落ちる。

4-2. LLM-as-a-Judge

——AIがAIを評価するという再帰

第1レイヤーの評価を高速に回す手段として、近年注目されているのがLLM-as-a-Judge——大規模言語モデル自身を評価者として用いるアプローチだ。Anthropicの Constitutional AI やOpenAIのRLHF評価パイプラインに見られるように、AIの出力品質をAIがスコアリングし、そのスコアを改善の入力とする。

この手法の魅力は明白だ。人間の評価者を待たずに、数千件の出力を数分で評価できる。改善ループの回転速度が桁違いに上がる。だが、評価者自身がバイアスを持つという構造的な限界もある。LLMは自身が生成しそうな文体を高く評価する傾向があり、Judgeモデルの盲点がそのまま改善ループの盲点になる。

したがって、LLM-as-a-Judgeは改善ループの「加速装置」であっても「操舵装置」にはなれない。何を良しとし、何を退けるかという基準設計は、依然として人間のドメイン知識に依拠する。

4-3. スキルの自己改善ループ

——Observe, Inspect, Amend, Evaluate

ハーネス・エンジニアリングにおける改善ループを、より具体的に定式化しよう。Observe → Inspect → Amend → Evaluateの4ステップだ。

Observe（観察）は、ログ資産からパターンを抽出するフェーズだ。どのステップで失敗が集中しているか、どの入力パターンで品質が劣化するか。ここでは前章で述べたログ資産の構造化が効いてくる。Inspect（検査）は、観察された異常の根本原因を特定するフェーズだ。ワークフローの設計に問題があるのか、プロンプトの記述が曖昧なのか、あるいはLLM自体の能力限界なのか。Amend（修正）は、特定された原因に対してワークフローやスキル定義を書き換えるフェーズだ。Evaluate（評価）は、修正後の出力を評価セットで検証するフェーズ——ここで再びObserveに戻る。

このループが1週間に1回転するチームと、1日に10回転するチームでは、半年後の堀の深さは比較にならない。堀の深さとは、このループの累積回転数そのものだ。

4-4. 多段エージェント特有の3つの壁

ただし、このループを回し続けることは、単一のAIモデルを改善するより遥かに難しい。多段エージェント——複数のLLM呼び出しが連鎖するシステム——には、固有の3つの壁が立ちはだかる。

第1の壁は、原因特定の難しさだ。最終出力が期待を下回ったとき、5段のワークフローのどのステップが原因なのかを特定するのは極めて困難だ。ステップ間の依存関係が複雑になるほど、原因と結果の因果関係は不透明になる。

第2の壁は、評価指標の曖昧さだ。中間ステップの「良い出力」とは何か。最終成果物には明確なKPIがあっても、途中の要約ステップや分類ステップの品質基準は往々にして定義されていない。MicrosoftのAutoGenチームが報告しているように、中間ステップの評価基準が曖昧なまま最終出力だけを最適化すると、ワークフロー全体が局所最適に陥る。

第3の壁は、外部環境の非決定性だ。同じプロンプトを同じモデルに投げても、返ってくる結果は毎回異なる。温度パラメータをゼロに設定しても、APIの内部状態やバッチ処理の影響で完全な再現性は保証されない。つまり、改善の効果を測定すること自体に統計的なノイズが乗る。

4-5. 愚直さという最強の戦略

これら3つの壁を前にして、「自動最適化で解決できないか」と考えるのは自然な発想だ。だが、現時点での率直な結論を述べる。最も有効な手段は、人間がドメイン知識をもとに愚直に改善を重ねることだ。

華やかではない。論文にもなりにくい。しかし、実務で堀を深くしている組織が実際にやっていることは、驚くほど地道だ。ログを1件ずつ読む。失敗パターンを分類する。プロンプトの一語を変えて再実行する。評価セットに新しいエッジケースを追加する。この反復を、週次ではなく日次で、日次ではなく時間単位で回す。

ここで重要なのは、完璧を待たないことだ。評価セットのカバレッジが60%でも、安全柵が主要リスクの半分しかカバーしていなくても、運用しながら改善する。リスク許容度を見極め、致命的な失敗だけを安全柵で防ぎつつ、残りは「観察して修正する」というループに委ねる。完璧な評価体系の設計を待っている間に、競合は不完全なループを100回転させている。

4-6. AIはループの中にいて、ループの外にもいる

最後に、AIの二重の役割について触れておきたい。前節で述べた「愚直さ」とは、改善の方向を決める行為を指している。何を観察し、何を修正し、何を良しとするか。AIが担うのは、その方向が定まった後の実行と候補生成の加速だ。操舵は人間、推進力はAI。この分担を逆転させると、ループは高速に空回りする。

その前提のもとで、ハーネス・エンジニアリングにおいてAIはループ内の問題解決者であると同時に、ループ自体を改善するメタ道具でもある。

ループの中では、AIはワークフローの各ステップを実行する。分析し、生成し、判断する。ループの外では、AIはログを解析して失敗パターンを発見し、改善候補を提案する。評価セットの欠落を指摘し、安全柵の抜け穴を検出する。

この二重性こそが、ハーネス・エンジニアリングの改善ループに独特の加速度を与える。従来のソフトウェア開発では、コードを書く人間とコードを改善する人間は同一だった。ハーネス・エンジニアリングでは、実行するAIと改善を支援するAIが——時に同じモデルでありながら——異なる文脈で協働する。人間は、この二重ループの設計者であり、最終的な判断の錨である。

車体は組み上げて終わりではない。走らせ、データを取り、チューニングし続ける。その営みの速度と持続性が、競争優位の実体だ。

だが、ここまでの議論には決定的に欠けているピースがある。この車体を設計し、チューニングし続ける人間は、どんな条件を満たす必要があるのか。

第5章｜FDE

—— ハーネスを回す人材の条件

第1章から第4章まで、私たちはハーネス・エンジニアリングの構造と、その堀の深め方を論じてきた。ワークフロー設計、評価セット、安全柵、ログ資産——この4つの成果物が複利的に積み上がることで、模倣困難な競争優位が生まれる。改善ループを愚直に回し続けることが最強の戦略であることも示した。

だが、ここで根本的な問いが浮上する。この仕組みは、いったい誰が回すのか。

ワークフローを書けるエンジニアは山ほどいる。LLMのAPIを叩けるプログラマーも珍しくない。しかしハーネスの真価——業務の暗黙知を構造に変換し、評価関数を定義し、リスクの勘所からガードレールを引き、ログの裏にある因果を読み解く——これらすべてを担える人材は、驚くほど少ない。

その答えの手がかりが、 FDE（Forward Deployed Engineer） という概念にある。

5-1. FDEとは何か

——ビジネス理解×実装力の二刀流

FDEは米Palantir Technologies社が生み出した職種だ。通常のソフトウェアエンジニアがオフィスでプロダクトを開発するのに対し、FDEは顧客の現場に入り込み、課題を共に解決する。"Forward Deployed"とは、戦場の最前線に展開する兵士のように、ビジネスの現場へ送り込まれるという意味だ。Palantirがテロ対策からサプライチェーン最適化まで成果を出せたのは、天才的なプロダクトだけでなく、顧客のドメインに深く潜り込むFDEの存在があったからだ。

FDEの本質は 「ビジネス理解 × 実装力」の二刀流 にある。コンサルタントは戦略を描くが、自分の手でコードを書かない。エンジニアはコードを書くが、業務の勝ちパターンが見えない。FDEはその両方を一人で担う。現場の痛みを理解し、それをシステムとして実装し、運用の中で磨き上げる。この越境こそがFDEの不可替性だ。

なぜこのFDEがハーネス・エンジニアリングの鍵になるのか。答えは、ハーネスの4成果物すべてがドメイン知識なしには設計できないという構造的制約にある。

• ワークフロー設計：純粋なエンジニアは「PDFをパースして項目を抽出する」と考える。だがFDEは、営業担当が月末に手入力で値引き調整をしている事実を知っている。例外処理を含めた業務の全体像を把握しているからこそ、実際に機能するワークフローが描ける。

• 評価関数の設計：LLMが出力した契約書レビューの「良さ」とは何か。法務部が重視するのは網羅性か、リスク指摘の優先順位か、修正文案の質か。これを定義できるのは、現場で何が問題になるかを肌で知っている者だけだ。F1スコアやBLEUスコアだけでは、業務における「良さ」は測れない。

• 安全柵の設計：社内向けの議事録要約が多少不正確でも実害は小さい。だが顧客向けの見積もり金額を誤れば損害賠償に直結する。この「勘所」は、現場にいるからこそわかる。

• ログ資産の活用：「成功率が72%に低下した」という数値が、季節要因なのか、入力データの質の変化なのか、業務プロセス自体の変更に起因するのかを判断するには、数字の背後にある因果関係を読む力が要る。

つまりFDEとは、ハーネス・エンジニアリングの文脈で言えば　「車体を設計し、チューニングし続けられる人材」　にほかならない。

5-2. 日本企業にFDEが不可欠な構造的理由

米国企業ではSalesforceやSAPに業務を合わせる文化が根づいており、FDE一人が顧客に入ればある程度の全体像が掴める。しかし日本の現実は根本的に異なる。拠点ごとにオペレーションが違い、同じ「発注処理」でも東京本社と大阪支社で手順が異なる。データは基幹システム、Excel、紙帳票、そして担当者の頭の中に散在している。

この環境では、Palantir型の「スーパーエンジニア1人を送り込む」モデルでは対応しきれない。日本版FDEに求められるのは、「業務アセスメント → AI前提での業務再設計 → 実装 → 運用」を一気通貫で担う力だ。FLUXのCEO長井氏が「経営者の本音はAI導入ではなく、業務プロセスの見直しだ」と指摘する通り、多くの日本企業にとって真の課題は現行の業務プロセスを可視化し、AI前提で再設計し、その上でハーネスを敷設することだ。

5-3. FDE × ハーネス = 堀

——属人知を組織資産に変換する

ただし、一つ重大なリスクがある。　FDEの知見が「個人の能力として閉じる」　ことだ。優秀なFDEが異動した途端、誰もワークフローの背景思想を説明できなくなる。評価関数の閾値がなぜその値なのかを知る者がいなくなる。これでは、個人の腕利きコンサルに依存しているのと変わらない。

ここにハーネス・エンジニアリングの構造的な意義がある。FDEの暗黙知を、ハーネスの4成果物として外在化し、制度化する。ワークフローに業務ロジックが記述される。評価セットにドメイン基準が明文化される。安全柵にリスク判断が埋め込まれる。ログ資産に改善の軌跡が蓄積される。FDEの頭の中にあった知識が、組織の構造資産に変換されるのだ。

FDE × ハーネス = 堀。 この等式の片方が欠ければ、堀にはならない。FDE単体では属人化に陥る。ハーネス単体ではドメイン知識の不足から空回りする。仕組みと人材は車の両輪だ。片方だけでは前に進めない。

第1章で市場の構造転換を描き、第2章で設計原則を導き、第3章でハーネスの4成果物を定義し、第4章で改善ループの方法論を確立した。そしてこの第5章で、その仕組みを回す人材の条件を明らかにした。ハーネスという仕組みと、FDEという人材。この2つが揃ったとき、企業の競争力はどう変わるのか——そして、揃えられなかった企業はどうなるのか。 次章では、いま始まりつつある「大分岐」の構造を読み解く。

第6章｜大分岐の入口に立つ

—— 企業と個人がいま取るべき行動

6-1. なぜ「大分岐」なのか

経済史家ケネス・ポメランツが名づけた　グレート・ダイバージェンス（大分岐）　は、18世紀末から19世紀にかけて西欧と中国の経済水準が劇的に乖離した現象を指す。ここで見落とされがちな事実がある。蒸気機関の原理そのものは、中国にも伝わった。にもかかわらず産業革命が起きたのは英国だった。差を生んだのは発明ではない。工場制度、鉄道網、会計システム、特許法。蒸気機関を「使い倒す」ための補完投資の厚みだった。

いま、同じ構造がAIの世界で再現されようとしている。GPT-4もClaude 4もGeminiも、APIキーさえあれば誰でも呼べる。第1章で述べた通り、汎用技術へのアクセスはすでに民主化された。だからこそ、ここから先の勝敗はモデルの外側で決まる。ハーネス、評価ループ、安全柵、そしてそれらを回し続ける組織の意志だ。

そしてこの分岐は、国家間だけの話ではない。企業と企業のあいだ、個人と個人のあいだでも、同時並行で進行する。 同じ業界、同じ職種、同じツールを使っていても、補完投資の有無によって3年後の生産性は桁が違う。第1章で述べたJカーブの底にいる今こそ、分岐の入口だ。

ここで見落としてはならないのは、この窓には有効期限があるということだ。a16zのTanが明確に警告している通り、「ファンデーションモデルが安定し知識が民主化されるにつれ、既存プレイヤーはAIを取り込み、既存の顧客関係を活用するようになる」。実際、既存BPO大手はすでに動き始めた。WiproはAI採用率を140%増加させ、Accentureは生成AIで12億ドルの新規受注を獲得している。

だが皮肉なことに、既存プレイヤーの反撃は構造的に制限されている。既存BPOのビジネスモデルは「タイム＆マテリアル課金」、つまり労働コストに20〜30%のマークアップを乗せる仕組みで成り立っている。AIネイティブの「成果課金」モデルに転換すれば、マージンは劇的に圧縮され、既存の収益源そのものが毀損される。これはクリステンセンが描いたイノベーションのジレンマの、ほぼ教科書的な再現だ。既存企業はAIの脅威を認識していながら、利益構造がハーネスへの全面移行を許さない。先行者のハーネスが成熟し堀になるまでの猶予期間は無限ではない。だが、既存企業が構造的に身動きが取りにくい今この瞬間こそ、最大の機会でもある。

6-2. 企業が取るべき行動

——「三つの変革力」で堀を築く

多くの経営者が「どのモデルを採用すべきか」を議論している。だが本稿をここまで読んだ読者には明らかだろう。勝負を分けるのはモデル選定ではなく、「組織変革力 × プロセス再設計力 × ガバナンス設計力」の掛け算だ。

組織変革力とは、AIを「IT部門の実験」から「全社の業務基盤」に引き上げる力を指す。McKinseyが公表した調査（"The state of AI", 2024年11月）では、AIパイロットを本番展開に移行できた企業はわずか26%だった。残り74%が失敗した理由のトップは技術的課題ではない。部門間の合意形成と業務プロセスの再定義——つまり組織の問題だ。

プロセス再設計力とは、第3章で述べたハーネスの4成果物——ワークフロー定義、評価基準、安全柵、実行ログ——を自社の業務文脈に落とし込む力だ。ここで重要なのは起動戦略である。最初から基幹業務に手を出してはならない。高頻度・低リスクの業務から始め、安全柵の精度を検証しながら、段階的に高価値業務へ展開する。 社内FAQ対応、定型レポート生成、コードレビュー補助——こうした「失敗しても致命傷にならない」領域でループを回し、評価基準と安全柵を鍛える。そのうえで、与信判断、契約書レビュー、医療画像トリアージといった高価値領域に進出する。順番を間違えた企業はインシデントを起こし、AI導入そのものが政治的に凍結される。

ガバナンス設計力とは、第4章で述べた評価3レイヤー——自動テスト、LLM-as-a-Judge、人間によるドメイン評価——を制度として組織に埋め込む力だ。属人的なプロンプト職人に依存する企業は、その人材が抜けた瞬間に堀が崩壊する。評価基準をコードとして定義し、実行ログを蓄積し、改善ループを組織の制度にまで昇華させること。これが第3章で論じた「模倣困難性の第3層」——時間と試行の蓄積——に直結する。

6-3. 個人が取るべき行動

——「使い方」ではなく「埋め込み方」

個人レベルでも分岐は容赦なく進む。だが、ここにも誤解がある。「AIの使い方が上手い人が勝つ」という言説だ。プロンプトの書き方を極めること自体に価値がないとは言わない。しかし本質的な差は、AIを「現場業務にどう埋め込むか」を設計できるかどうかにある。

ChatGPTに質問して便利な回答を得る。これは「使い方」だ。一方、自分の業務プロセスを分解し、どの工程をAIに委譲し、どの工程で人間が判断を下すかを設計し、その判断基準を明文化し、ループとして回す。これが「埋め込み方」だ。前者は誰でもできる。後者にはドメイン知識と構造化思考が要る。

そしてもう一つ、個人が見誤ってはならないことがある。AIを使う目的は　「楽をすること」ではなく「学習速度を上げること」　だ。AIにレポートを書かせて空いた時間でSNSを眺める人と、AIにレポートの初稿を書かせて空いた時間で顧客ヒアリングに出向く人。半年後、両者のドメイン知識の厚みには決定的な差がついている。AIは認知労働のレバレッジだ。レバレッジは、元本がゼロなら何倍かけてもゼロである。

6-4. 発想が安くなる時代に、何の価値が上がるのか

AIの進化は、アイデアの生成コストを限りなくゼロに近づけている。かつて「ひらめき」に数週間かかった仮説が、数秒で10個生成される時代だ。発想の希少性は急速に失われつつある。

では何の価値が上がるのか。構造資産だ。具体的には三つある。

第一にドメイン知識。特定業界の暗黙知、規制の解釈、顧客の行動パターンへの深い理解。これはLLMの学習データには十分に含まれていない。

第二にブランド。「この会社・この人が言うなら信頼できる」という認知の蓄積。AIが生成した文章の真偽を最終的に保証するのは、発信者の信用だ。

第三に顧客との信頼関係。長年の取引で築かれた相互理解と期待の網の目。

これらはいずれも、一夜にして構築できず、コピーもできない。第3章で論じた「堀の深さ」とは、つまるところこの構造資産の厚みにほかならない。

AIが「考える」部分を代替すればするほど、「何を考えるべきか」を定義する能力——つまり問いを立てる力と、その問いに文脈を与えるドメイン知識——の相対価値は上がり続ける。

6-5. 分岐は、すでに始まっている

本稿を通じて論じてきたことを一文で要約するなら、こうなる。AIの価値はモデルの中ではなく、モデルの外側に構築するハーネスと、それを回し続ける人間の意志の中にある。

ケイパビリティ・オーバーハングは縮小しない。モデルの性能は半年ごとに跳ね上がる。だが、それを業務成果に変換するハーネスの整備には、地道な試行錯誤と時間がかかる。Sequoia CapitalのCahnはこの瞬間を　「リミナル期（liminal period）」　——境界の時代——と呼んだ。アニマルスピリッツは落ち着いているが、AI企業は好業績を継続している。AGIという「機械仕掛けの神」を待つのではなく、持続的な進歩には「ハードワーク、創造的な卓越性、忍耐力」が必要だ、と。この指摘は、本稿の主張と完全に重なる。この非対称性こそが、第1章で述べたJカーブの本質であり、第2章で述べたBitter Lessonの実践的含意であり、第3章と第4章で述べた堀と改善ループの存在意義であり、第5章で述べたFDEという人材が不可欠な理由だ。

産業革命の時代、最初に工場制度を整えた企業がその果実を総取りした。AI時代も同じだ。最初にハーネスを整え、評価ループを回し、構造資産を積み上げた企業と個人が、複利の恩恵を受ける。

完璧な計画は要らない。完璧なモデルも要らない。必要なのは、小さく始めて、速く回して、学びを蓄積する仕組みだ。a16zのda CostaとRampellが「グリーンフィールド戦略」と名づけたStripeの成長モデルが、ここでの参照点になる（"The Greenfield Strategy", 2025年10月）。Stripeの顧客の多くは、Stripe設立時にはまだ存在していなかった。小さなスタートアップとして始まり、Stripeとともに成長し、やがてエンタープライズになった。ハーネスも同じだ。 最初は小さな業務、小さな評価セット、最低限の安全柵で始める。だがその顧客やその業務が成長するにつれ、ハーネスの深さが実績として証明され、隣接領域への展開が自然に進む。最初から完成されたハーネスを設計しようとする必要はない。顧客と共に、業務と共に、ハーネス自身が成長すればよい。

導入で述べた比喩を思い出してほしい。成果物はレースの走行結果に過ぎない。結果だけを真似ても、その結果を叩き出した車体がなければ、次のレースは走れない。 だが、この6章を通じて明らかになったことがある。車体は買ってきた瞬間が完成形ではない。走らせるたびにデータが溜まり、チューニングの精度が上がり、次のレースの結果が変わる。それ自体が、あなたの手で鍛え上げるものだ。ワークフローを敷き、評価で検証し、ログに記録し、改善で更新する。その一回転ごとに車体は研ぎ澄まされ、次のレースはより速く、より精緻に走れるようになる。

だからこそ、問いは「どのモデルを選ぶか」ではなく「いつ最初の一回転を回すか」だ。今日の試行錯誤が、明日の複利になる。

ここまでが理論編だ。第7章以降では、筆者自身がハーネスを実装した経験から、理論がどう着地し、何が見えたかを記す。

第7章｜ハーネスの実装例

—— 設計思想から動く仕組みへ

理論は理論として完結している。だが、理論が本物かどうかは、自分で手を動かさなければ分からない。

第1章から第6章まで、筆者は「ハーネスこそが次の10年の堀になる」と主張してきた。ワークフロー、評価セット、安全柵、ログ資産。この4つの成果物を回し続けることで、模倣困難な構造資産が蓄積される、と。では、その主張は実装に耐えるのか。

筆者は自らハーネスを構築した。GitHub Issueに自然言語で書くだけで、AIエージェントが最適な処理を自動選択し、実行結果をIssueに返す仕組みだ。システム開発を始めいくつかの業務ドメインにまたがるプラグイン群が、それぞれ独自の評価基準と改善ループを内蔵している。

本章では、この実装の設計思想を5つの観点から紹介する。

7-1. プラグインルーティングアーキテクチャ

——意図と能力を疎結合に保つ

設計の出発点は、ひとつの問いだった。ユーザーの「やりたいこと」と、システムの「できること」を、どう結びつけるか。

素朴なアプローチは、固定的なコマンド体系を作ることだ。「/analyze-stock AAPL」「/generate-slide テーマ」のように、ユーザーが正確なコマンドを知っていることを前提とする。だがこの設計には致命的な問題がある。能力が増えるたびにコマンド体系が肥大化し、ユーザーは「何ができるか」を把握しきれなくなる。

筆者が採用したのは、プラグインルーティングアーキテクチャ——意図と能力を疎結合に保つ5レイヤー構造だ。

この構造の要点は、各レイヤーが隣接レイヤーの内部構造を知らないことにある。起点は実行の詳細を知らない。実行はルーティングの方式を知らない。能力の追加はPlugin Registryへの登録だけで完結し、他のレイヤーに変更を波及させない。

カーナビを想像してほしい。カーナビは「どこに行きたいか」を聞き、適切なルートを算出する。道中で何をするか——どのギアで走るか、いつブレーキを踏むか——には関与しない。Routerもまさにこの役割を果たす。「この依頼はどのスキルが処理すべきか」だけを判断し、スキルの内部でAIがどう探索するかには一切関与しない。信頼度が0.7未満の場合は、スキルを経由せずモデルに直接回答させるフォールバックも備えている。

この疎結合が、第3章で論じた堀の「幅」に直結する。新しいプラグインを追加しても、既存のプラグインは何も変わらない。堀を幅方向に広げるコストが、構造的に低く抑えられている。

7-2. 1プラグイン=1業務ドメイン

——堀の単位を切る

堀は漠然と掘るものではない。単位がある。

筆者の実装における堀の単位は、1プラグイン=1業務ドメインだ。業務ドメインが異なれば、必要な判断基準、評価軸、安全柵がすべて異なる。これらを無理に統合すれば、どちらの品質も中途半端になる。

各プラグインが独自のスキル定義（実行手順）とエージェント定義（判断主体）を内蔵し、ドメインごとに独立して進化する。

ここで、第5章で論じたFDEの議論を回収したい。FDEの暗黙知を組織資産に変換すると述べたが、その具体的な実装形態が `domain/` システムだ。

たとえば企業価値ドメインでは、金融の暗黙知が4つのファイルに構造化されている。

ワークフローに `domain: equity-analysis` と1行書くだけで、これらのドメイン知識がすべてのLLMプロンプトに自動注入される。FDEの頭の中にあった「EPS成長率の閾値はどこに設定すべきか」「投資推奨の根拠は最低何件必要か」といった判断基準が、ファイルシステム上に外在化された瞬間、それは個人の能力ではなく組織の構造資産になる。

第5章で「FDE × ハーネス = 堀」と等式を立てた。`domain/` システムは、この等式の実装そのものだ。FDE単体ではドメイン知識は個人の中に閉じるが、`vocabulary.yaml` と `criteria.yaml` に書き出された瞬間、その知識はプラグインに自動的に反映される。

7-3. Task×Stage構造

——「何を作るか」と「どう進めるか」の直積

各プラグインの内部は、task（何を作るか）とstage（どう進めるか）の直積でスキルを構成する。

ここで重要なのは、taskは段階ではないという区別だ。taskは業務成果物の種類であり、stageはその成果物を処理するライフサイクルの段階である。スキルの命名規則は `{task}-{stage}` パターンに従う。たとえば `coding-plan`（計画）、`coding-generate`（生成）、`coding-evaluate`（評価）。

この構造がすべてのプラグインに共通している。

ドメインが変わっても、task×stageの直積でスキルを構成し、オーケストレーターが全体を統合するという骨格は同一だ。stageの具体的な中身はドメインごとに異なるが、「plan → generate → evaluate →（不合格なら再generate）」というライフサイクルの構造は共通している。

オーケストレーターは3つの原則に従う。
第一に、オーケストレーター自身はドメインロジックを持たない。各stageのスキルを呼び出す順序と条件分岐だけを制御する。
第二に、各stageは独立して実行可能であり、オーケストレーター経由でなくても単独で呼び出せる。
第三に、終了条件はevaluate stageが決める。オーケストレーターは「evaluateが合格を返すまでgenerate→evaluateを繰り返す」というメタ制御だけを担う。

この設計は、第2章で論じたThe Bitter Lessonの直接的な実装だ。オーケストレーターは「どう解くか」を知らない。「何をもって合格とするか」だけを知っている。

7-4. 生成と評価の構造的分離

——自己採点を許さない設計

人間でも、自分のレポートを自分で採点すれば甘くなる。LLMも同じだ。

すべてのプラグインの改善ループは、4つの要素で構成されている。

このループが成立する条件は、生成と評価が構造的に分離されていることだ。同じLLMが生成と評価を兼ねると、自分の出力を自分で「良い」と判定する自己欺瞞のバイアスが入る。

筆者の実装では、生成エージェントと評価エージェントは異なるエージェントインスタンスとして実行される。評価エージェントは生成時の会話履歴を持たない。さらに、評価エージェントには成果物を修正するための `Edit` 権限が与えられていない。評価者は「判定する」ことだけができ、「直す」ことはできない。

生成は評価の意図を知らず、評価は生成の過去を知らない。この無知の強制が、ループを収束させる。

7-5. engineering-pipelineの全体フロー

——Plan→Generate→Evaluate→Verify→Escalation

設計思想を具体的なフローで見てみよう。engineering-pipeline（システム開発）は、GitHub Issueを入力として受け取り、PRの作成まで自動で完遂する。5つのStageがライフサイクルを構成する。

Plan Stageでは、GitHub Issueを分析し、TDD実装計画を策定する。どのテストを先に書き、どの順序で実装するか。ブランチの作成もここで行う。オーケストレーターがprogrammerエージェントを起動し、以降の全工程を委譲する。

Generate Stageでは、TDDのRED→GREEN→REFACTORサイクルを忠実に実行する。まず失敗するテストを書き（RED）、テストを通す最小限のコードを書き（GREEN）、品質を改善する（REFACTOR）。各処理はSub-agentに委譲される。ここで決定論的な安全策が挟まる。GREEN・REFACTOR後にはテストファイルのハッシュ値を比較し、テストが変更されていないことを機械的に検証する。テストを書き換えて通すのは、TDDにおける最大のアンチパターンだからだ。

Evaluate Stageでは、5軸100点満点でスコアリングする。TDDプロセス遵守、テスト品質、実装品質、セキュリティとパフォーマンス、AIアンチパターン不在。各指摘には `[修正可能]`、`[修正不可能]`、`[設計起因]` の分類が付与される。80点以上で承認となり、結果報告へ進む。

Verify Stageでは、80点未満の場合にフィードバックを適用し、Generate Stageに戻す。最大3回まで反復する。ここに停滞検知の仕組みがある。同一のCritical指摘が2回連続で改善されなかった場合、実装レベルの修正では解決不能と判断し、Escalationに遷移する。

Escalationでは、実装レベルの修正を中止し、Plan Stageに戻って計画からやり直す。無限ループ防止のため、計画やり直しは最大1回に制限されている。2回目のEscalationに達した場合は、現時点での最善の状態をもって最終報告とする。

この一連のフローの要点は、各Stageが独立したスキルとして実装されていることだ。`coding-plan`、`coding-generate`、`coding-evaluate` はそれぞれ単独で呼び出せる。オーケストレーターは「evaluateが80点以上を返すまでgenerate→evaluateを繰り返す」というメタ制御だけを担い、ドメインロジック自体は各Stageのスキルに閉じている。

車体の設計図は見えた。では、この車体は理論通りに走ったのか。

第8章｜原則は実装でどう効いたか

—— 第1〜6章の原則を検証する

第7章の実装は、第2章で導いた原則とどう対応するか。

3つの原則はいずれも、「何を固定し、何をモデルに委ねるか」の設計判断として実装に現れた。固定すべきは評価基準と安全柵。委ねるべきは探索手順と生成方法。この区分けが一貫しているからこそ、モデルが進化するたびに——人間が何も変えなくても——出力品質が自動的に上がる構造が成立する。

ここで、安全柵の「固定」について補足しておきたい。プロンプトで「テストファイルを編集しないでください」とお願いするのと、ツールレベルで編集権限を剥奪するのでは、実効性がまるで違う。筆者の実装では、`.env`ファイルの読み取り、評価ファイル（`evals/`）の編集、`git push --force`の実行などが、設定ファイルで構造的に禁止されている。LLMは確率的な存在であり、プロンプトの指示を100%遵守する保証はない。だがツール権限を剥奪すれば、物理的に実行できない。ルールをプロンプトに置くか、ツール権限に置くか——この一見小さな設計判断が、安全柵の実効性を根本的に変える。

8-1. 確率論的品質保証

——3層ゲートと報酬ハッキング対策

第2章で品質保証のパラダイム転換を論じた。　「100%の正解保証ではなく、99.5%の不良排除を目指せ」　と。決定論的なOK/NGの二値判定から、確率論的な多段フィルターへ。

実装ではこの原則が、valuation-pipeline（企業価値評価）の3層ゲートとして具体化された。

第1層は決定論的バリデーションスクリプトだ。引用形式の正規表現チェック、確率合計の算術チェック、必須セクションの存在確認。LLMの判断を挟まない。正しいか正しくないか、二値で判定できるものだけを扱う。

第2層はLLM評価エージェントだ。情報の鮮度、論理整合性、分析の深さ。これらは二値では判定できない。人間の判断に近い「程度」の問題であり、LLMの推論能力を使う意味がある。

第3層はクロスレポートバリデーションだ。3つのレポート（リサーチ、バリュエーション、サマリー）間で数値の一貫性を検証する。同じ企業のEPSが、リサーチレポートでは500円、バリュエーションレポートでは480円と書かれていれば、どちらかが誤りだ。±1%の許容誤差でクロスチェックする。

「明らかな誤り」は決定論的に排除し、「微妙な品質」はLLMで判定し、「全体の整合性」は数値比較で確認する。100%の正解を保証するのではなく、多段階のフィルターで不良排除の確率を最大化する設計だ。

ただし、3層ゲートにも落とし穴がある。報酬ハッキングだ。LLMが評価メトリクスを狙い撃ちにし、形式だけ整えて中身が薄い出力を生成する可能性がある。たとえば、「セクション名だけ揃え、中身が2行しかない」出力は、セクション存在チェックを通過してしまう。

対策として、決定論的バリデーションはセクションの「存在」だけでなく 「情報密度」 までチェックしている。引用の数、数値トークンの数、感度分析テーブルのセル数。LLMが形式だけ整えて中身が薄い出力を「合格」とする自己欺瞞を、定量指標で防ぐ。評価をすり抜けようとする相手に対しては、評価の解像度を上げるしかない。これもまた、改善ループの一部だ。

理論の原則は、実装においても有効だった。だが、実装はもうひとつのことを教えてくれた。理論が予見できなかった設計原則の存在だ。

第9章｜実装して初めて見えたこと

第8章では、理論と実装の合致を確認した。本章では逆に、理論には書かなかった——書けなかった——設計原則を記録する。これらは、実装を通じて初めて輪郭が見えたものだ。

発見は2つの領域に分かれる。前半はループの精度に関するもの、後半はシステムのスケーリングに関するものだ。

ループの精度を上げる発見

9-1. 停滞検知とエスカレーション

——愚直さには方向制御が要る

第4章で「愚直さという最強の戦略」を説いた。ログを1件ずつ読み、プロンプトの一語を変え、評価セットにエッジケースを追加する。この反復を時間単位で回せと。

その主張は撤回しない。だが実装して分かったのは、愚直さと盲目は紙一重だということだ。

engineering-pipelineのevaluatorが80点未満のスコアを返すと、Verify Stageがフィードバックを適用し、Generate Stageに戻す。これを最大3回繰り返す。だが3回繰り返しても同じCritical指摘が消えないケースが現れた。変数名の修正程度の指摘であれば次のイテレーションで解決するが、「アーキテクチャが根本的に適切でない」という指摘は、コードレベルの修正をいくら重ねても解消しない。

そこで実装したのが、停滞検知とエスカレーションの仕組みだ。同一のCritical指摘が2回連続で改善されなかった場合、実装レベルの修正を中止し、計画レベルに戻ってやり直す。ループの中にメタループを埋め込むことで、局所最適の袋小路を脱出する。

これと対をなすのが、evaluatorによる指摘の3分類だ。

• `[修正可能]`：次のイテレーションで実装エージェントが直接修正できるもの

• `[修正不可能]`：現在の制約下では修正不能なもの（外部ライブラリの仕様制限など）

• `[設計起因]`：計画やアーキテクチャから見直す必要があるもの

この分類により、次のイテレーションで修正不可能な指摘に時間を浪費することを防ぎ、設計起因の指摘はエスカレーション経路に流される。

第4章では「改善の方向を決める行為」を人間に委ねた。実装ではこの判断の一部を構造化して自動化している。愚直さにはガードレールとしての方向性判定が不可欠だという、実装で初めて見えた知見だ。

9-2. コンテキスト分離

——同じモデルでもバイアスは断てる

第4章で、LLM-as-a-Judgeについてこう述べた。「評価者自身がバイアスを持つという構造的な限界がある」と。LLMは自身が生成しそうな文体を高く評価する傾向があり、Judgeモデルの盲点がそのまま改善ループの盲点になる。

この指摘は正しかった。だが実装を通じて、モデルを変えなくても、コンテキストを分離するだけでバイアスは大幅に軽減されることが分かった。

筆者の実装では、生成エージェントと評価エージェントは異なるエージェントインスタンスで実行される。評価エージェントは、生成時の会話履歴を一切持たない。どんなプロンプトで指示されたか、どんな試行錯誤を経たか、どんな代替案を検討したか——これらの情報が評価エージェントに渡らない。評価エージェントが見るのは、成果物だけだ。

さらに、評価エージェントにはコードを修正するための `Edit` 権限が与えられていない。これにより2つの分離が実現される。

会話履歴の分離——評価エージェントは生成の過程を知らないため、「苦労して書いたのだから甘く評価しよう」という自己正当化が構造的に不可能になる。

書き込み権限の分離——評価エージェントは判定だけができ、修正はできないため、「この程度なら自分で直せるから合格にしよう」という裁量が入る余地がない。

同じモデルを使っていても、コンテキストと権限を分離するだけで、LLM-as-a-Judgeのバイアス問題は構造的に緩和される。異なるモデルを使わなくても、異なる「視点」は作れる。これは理論では予見できなかった実装上の発見だ。

9-3. ファイルベースのフィードバック

——記憶の適切な忘却

改善ループにおいて、フィードバックをどう受け渡すかは地味だが重要な設計判断だ。

素朴なアプローチは、会話コンテキストの中にフィードバックを含めることだろう。前回の評価結果を会話履歴に残し、次のイテレーションでLLMがそれを参照して改善する。しかし、この設計にはコンテキストの肥大化という問題がある。イテレーションを重ねるたびに会話履歴が膨張し、LLMの注意が分散する。3回目のイテレーションでは、1回目のフィードバック（もはや古く、場合によっては矛盾している）が依然としてコンテキストに残り、ノイズとなる。

筆者の実装では、フィードバックを会話コンテキストの外に、ファイルとして書き出す設計を採っている。評価結果を書き出し、次のイテレーションの生成エージェントがそれを読む。

会話履歴を引き継がないため、各イテレーションは最新のフィードバックだけに集中できる。過去の試行錯誤の記憶は意図的に捨てられる。これは情報の喪失ではない。記憶の適切な忘却だ。

人間の改善プロセスでも同じことが起きている。昨日のフィードバックを全文暗記して今日の作業に臨む人はいない。要点だけをメモに残し、メモだけを見て作業する。ファイルベースのフィードバック受け渡しは、この「メモだけ見て作業する」行為の構造化だ。

スケーリングの発見

9-4. レジストリの自動同期

——成果物が増えたときのメタ管理問題

第3章でハーネスの4成果物を論じたとき、暗黙の前提があった。成果物の数は管理可能な範囲に収まるだろう、という前提だ。

現実はそうならなかった。プラグインとスキルの数が無数に増えていき、「どのスキルがどの入力を受け付け、どの条件で呼ばれるべきか」の管理が新たなボトルネックになった。
スキルを追加するたびにRoutingの設定を手動で更新し、矛盾がないか確認する作業が発生する。成果物が増えれば増えるほど、成果物のメタ管理コストが膨張する。

解決策は、単一真実源（Single Source of Truth）の原則だった。各スキルの定義ファイル（SKILL.md）を唯一の真実源とし、Routing設定は自動生成する。
同期スクリプトがトリガーキーワードを自動抽出し、入力スキーマを推論し、オーケストレーターフラグを判定する。

これにより、プラグイン追加時のRouting設定コストは、ほぼゼロになった。スキルを定義するだけで、自動的にRoutingに組み込まれる。成果物が増えたときのメタ管理は、成果物の定義自体を真実源にすることで解決できる。 第3章では触れなかった、スケーリング固有の設計課題だ。

9-5. Routerは薄く、スキルに制御を寄せる

——制御フローをLLMに委ねる

初期の実装では、ワークフローの制御フローをYAMLで宣言的に記述していた。ステップの順序、ループの条件、並列実行の分岐。手順書をそのまま機械可読にしたような設計だ。

しかし運用を続けるうちに、この設計自体がThe Bitter Lessonに反していることに気づいた。YAMLで分岐やループを固定すると、モデルの能力が向上しても、固定された手順がその能力を活かすことを妨げる。GPT-4の能力に合わせて書いた分岐ロジックは、GPT-5では不要な制約になっていた。

そこで生まれたのが「Routerは薄く、スキルに制御を寄せる」という設計原則だ。Routerは1クエリ→1スキル選択だけを行い、制御フローを一切持たない。ループ、並列実行、チェーン実行はスキル定義の中でエージェントが自律的に判断する。

これにより、モデルが進化すればスキル内の自律的な判断も自動的に改善される。手順をハードコードしたYAMLを人間が更新する必要がない。ハーネスのアーキテクチャ自体が、The Bitter Lessonに従って進化したのだ。

ここで、第3章との矛盾を感じる読者がいるかもしれない。第3章では「属人的な勝ちパターンをYAMLやコードとして形式知に変換する」と述べた。YAMLを否定しているのか？　否。ここで区別すべきは制御フローと業務ロジックだ。「ステップAの後にステップBを実行し、条件Xならループする」という制御フローをYAMLで固定するのは、The Bitter Lessonに反する。モデルの能力が上がれば不要になる分岐が必ず出るからだ。一方、「この業務ではEPS成長率の閾値を15%に設定する」「投資推奨の根拠は最低3件必要」といった業務ロジック——すなわちドメイン知識と評価基準——は、むしろ積極的にYAMLで形式知化すべきだ。固定すべきは「何を良しとするか」であり、「どう辿り着くか」ではない。 この区別は、第2章の「ルールを置く場所が問題だ」という原則の、より解像度の高い再発見である。

9-6. visibilityによるルーティング制御

——安全柵は出力だけでなく入力にも置ける

第3章で安全柵を論じたとき、その機能を「AIの出力を検査し、基準を満たさない出力を遮断する仕組み」と定義した。出力に個人情報が含まれていないか。数値が元データと整合しているか。検査の対象は常に「出力」だった。

実装を通じて、安全柵の適用箇所がもうひとつあることが見えた。入力のルーティング段階だ。

Plugin Registryには `visibility` フィールドがある。`public`（外部から呼び出し可能）と `internal`（オーケストレーター内部からのみ呼び出し可能）の2値だ。

たとえば engineering-pipelineの `coding-verify-feedback` は、「すでにレビュー結果が存在する」ことを前提として動作するスキルだ。もしGitHub Issueから直接呼ばれた場合、前提条件（レビューコメントの存在）が満たされないまま実行される。空のフィードバックに対して無意味な「修正」を試み、無関係なファイルの変更や、最悪の場合は既存コードの破壊が発生しうる。

`visibility: internal` は、この事故をルーティング段階で構造的に遮断する。出力を検査して事後的に防ぐのではなく、そもそも不適切な入力がスキルに到達しないようにする。

「やってはいけないこと」の遮断は、出力検査だけでなく入力のルーティングでも実現できる。安全柵の設計は、「どこで遮断するか」という選択肢が、理論が想定していたよりも広い。 第3章の安全柵の議論は、出力側の検査に偏っていた。入力側のルーティング制御という視点は、実装が教えてくれた新しい設計選択肢だ。

理論が予見した原則と、実装が教えてくれた原則。両方が揃って初めて、車体の真価が見える。

第10章｜まとめ

—— 車体の現在地と、最初の一回転の意味

10-1. 不完全なループを止めないこと

第4章で「完璧を待たないこと」と述べた。評価セットのカバレッジが60%でも、安全柵が主要リスクの半分しかカバーしていなくても、運用しながら改善せよと。

この言葉を書いたとき、それはある程度の知的確信だった。実装を経た今、それは体験的な実感に変わっている。

筆者のハーネスは完成品ではない。KPI連動評価は未着手であり、ログの横断分析は存在せず、安全柵の横展開フレームワークは構想段階だ。

それでもループは止めていない。不完全なまま回し続けている。そして、本記事の第9章自体が、そのループの成果物のひとつだ。停滞検知、コンテキスト分離、ファイルベースのフィードバック、レジストリの自動同期、Routerの薄型化、visibilityによるルーティング制御。これら6つの設計原則は、理論を書いた時点では見えていなかった。不完全な実装を回し続ける中で、初めて輪郭が現れたものだ。

完璧な設計を待つのではなく、不完全な設計を回しながら、そのループから新たな設計原則を抽出する。これが、実装が教えてくれた最も重要な教訓だ。

10-2. 実装を経て見えた「複利」の実感

第6章の結語で、こう書いた。「今日の試行錯誤が、明日の複利になる。」

あのとき、それは理論的な確信だった。ハーネスのループは複利構造を持っているはずだ、と。実装を経た今、「はずだ」は「実際にそうだった」に変わった。

複利が具体的に効いた場面を3つ挙げる。

第一に、domain/システムの横展開。 企業価値評価ドメインで `vocabulary.yaml` と `criteria.yaml` を整備したとき、そのフォーマットと設計思想が、次のドメインの設計を加速した。ゼロから「ドメイン知識をどう構造化するか」を考える必要がなくなった。1つ目のドメインに1週間かかったとすれば、2つ目は3日、3つ目は1日で済む。これは知識ではなく構造の再利用だ。

第二に、停滞検知の転用。 システム開発ドメインで実装した「同一指摘2回連続→エスカレーション」の仕組みは、他のプラグインにも応用可能なパターンであることが見えてきた。ループの中にメタループを埋め込むという設計原則自体が、ドメインを超えて転用できる。

第三に、モデル進化の自動吸収。 評価基準をモデル非依存で定義したことで、モデルを切り替えるたびに——何も変えていないのに——出力品質が上がった。第2章で論じたアンディ＆ビルの法則AI版が、理論通りに機能した。これは最も静かで、最も強力な複利だ。

導入で述べた比喩に戻ろう。車体は買ってきた瞬間が完成形ではない。 ハーネスを回すたびにチューニングが深まり、走行の質と速度が変わる。この10章を通じて記録してきたのは、車体を鍛え上げるプロセスそのものだ。

理論編（第1〜6章）では、なぜ車体が競争優位になるかを論じた。実装編（第7〜10章）では、車体がどう鍛え上げられるかを記録した。そして本章で示したのは、車体の鍛造はまだ途上にあるという事実だ。深いが狭い。蓄積は始まったが、複利の全貌が見えるにはまだ早い。

だが、それでよい。堀の深さは、ループの累積回転数で決まる。最初の一回転を回した者だけが、二回転目を回せる。 そして二回転目を回した者だけが、三回転目の景色を見ることができる。

問いは変わらない。「どのモデルを選ぶか」ではなく、「いつ最初の一回転を回すか」だ。

ここまで約35,000字、お読みいただきありがとうございます。

本記事が「自分の現場でも最初の一回転を回してみよう」と思うきっかけになれば、書いた甲斐があります。もし少しでも参考になったと感じていただけたら、「いいね」 を押していただけると励みになります。また、同じ課題感を持つ同僚やチームメンバーがいれば、ぜひ シェア していただけると嬉しいです。

ハーネスの設計や実装について議論したい方は、XのDMでお気軽にどうぞ。皆さんの現場での工夫や発見も、ぜひ聞かせてください。