OpenAIとAnthropicのハーネス論争：より強力なモデル、対照的なエンジニアリング上の賭け
OpenAIのエンジニアはAnthropicとの重要な論争を再燃させた。より強力なAIモデルには、より軽量なハーネスで足りるはずだが、要求の厳しいタスクでは依然として手厚い監督が報われる、という論点だ。
このOpenAIとAnthropicのハーネス論争は、単なるプロンプトやインターフェースの好みをめぐる話ではない。ツール、メモリ、権限、計画、評価、人間による承認など、モデルを取り巻くソフトウェア全体に関わる。
OpenAIは、過剰な足場組みが、次世代モデルにはもはや存在しない制約を組み込んでしまう可能性があると主張する。Anthropicの最近の実験は、より条件付きの結論に達した。高性能なモデルによって一部のオーケストレーションは不要になったものの、タスクがモデルの限界に近づくと、プランナーと独立した評価器は依然として有用だった。
この意見の対立はCodexとClaude Codeだけに影響するものではない。企業は汎用モデルを、リポジトリの編集、ブラウザの操作、文書の分析、長期プロジェクトの調整を行うエージェントへと変えつつある。制御を一つ追加するごとに信頼性は高まり得るが、同時にレイテンシ、複雑性、そして将来古くなり得る前提も増える。
したがって中心的な問いは、ハーネスが重要かどうかではない。両社のエンジニアリングの取り組みは、その重要性を示している。問われているのは、進歩によって価値がモデル側へ移るのか、ハーネス側へ移るのか、それとも両レイヤーの間を繰り返し行き来するのか、という点だ。
OpenAIとAnthropicが実際に変えたもの
両社は現在、エージェントハーネスを製品を決定づけるレイヤーとして扱っているが、そのレイヤーにどの程度の知能を持たせるべきかについては見解が異なる。
エージェントハーネスとは、モデルをツール、コンテキスト、メモリ、フィードバックループ、ユーザー制御へ接続するランタイムである。モデルが判断を生成し、ハーネスがモデルに見せる情報、実行可能な操作、そしてミスを検出する方法を決める。
OpenAIの立場は、ソフトウェア開発を超えてエージェントを拡張する取り組みについての8月の報道で明確に示された。同社のエンジニアは、良いハーネスエンジニアリングとは、不要なルールで囲い込むことなく、モデルに必要なツールと情報を正確に与えることだと説明した。
エンジニアのNick GershensonはTechCrunchに対し、条件分岐ロジックとツールを精緻に積み重ねれば短期的な成果を生み出せると語った。しかし新しいモデルが、そうした追加要素を数カ月で時代遅れにする可能性があるとも主張した。彼が好むのは、能力の高いモデル自身が問題のより多くを解決できるようにする、抑制の効いたインターフェースだ。
この原則は、広範な人間の知識を中心に構築されたシステムよりも汎用計算が優位に立つと論じたRich Suttonの影響力ある主張、bitter lessonとも響き合う。エージェントに当てはめれば、この教訓は、想定されるすべての失敗に対して手作業でワークフローを設計するよりも、広範な能力を備えたモデルを支持する。
OpenAIはハーネスエンジニアリングを放棄したわけではない。同社のCodex engineeringに関する説明では、リポジトリ、ドキュメント、テスト、フィードバックループ、機械可読な計画を不可欠なインフラとして挙げている。同社によれば、ある社内プロジェクトではエンジニア1人当たり1日平均3.5件のプルリクエストが作成された。
違いは、OpenAIが複雑性をどこに置きたいと考えているかにある。同社のエンジニアは、モデルがどう考えるべきかを指定する複雑化し続ける分岐よりも、理解しやすい環境と明確なフィードバックを重視している。
Anthropicの3月24日の研究は、別のストレステストを示した。研究者のPrithvi Rajasekaranは、プランナー、生成器、評価器を用いて、長時間の自律セッションにわたり完全なアプリケーションを構築した。
プランナーは短い依頼を構造化された仕様へ変換した。生成器はその計画を実装した。評価器はアプリケーションを操作し、合意済みの基準を確認し、修正すべき欠陥を返した。
Anthropicの初期比較では、単一エージェントの実行では中核となるゲームプレイ機能が動作しないアプリケーションが生まれた。マルチエージェントのハーネスは、欠陥が残ったものの、より広範で機能する結果を実現した。
これは、重いハーネスが常に勝つことを示す証拠ではない。Claude Opus 4.6が長時間の作業をより一貫して処理した際、Anthropicはその後スプリント単位の分解を取り除いた。それでもプランナーと評価器は、欠けている機能や浅い実装を見つけ続けた。
したがってこの出来事は、収束と対立を同時に示している。OpenAIとAnthropicはいずれも、モデルが従来の責務を吸収するとハーネスを簡素化する。異なるのは、開発者がその移行をどれほど早く信頼すべきかという点だ。
OpenAIとAnthropicのハーネス論争が今重要な理由
圧力の源は、エージェントが範囲の限定されたコーディング作業を超え、成功の定義が難しく、失敗を取り消しにくい仕事へ進んでいることにある。
コーディングはエージェントにとって最初の好条件な環境だった。リポジトリには構造化されたファイルがあり、コンパイラはエラーを明示し、テストはしばしば明確な合否シグナルを生む。ハーネスはそれらのシグナルを次のモデル試行へ変換できる。
一般的なナレッジワークには、信頼できる検証手段が少ない。戦略メモは弱い前提に基づいていても首尾一貫して見えることがある。スプレッドシートは計算を正しく行っていても、誤った事業上の問いに答えているかもしれない。エージェントは、その根拠が古くなっていることに気付かないまま、洗練されたプレゼンテーションを完成させる可能性がある。
OpenAIは、より構造化されていないこうした環境へエージェントのアプローチを拡張している。この動きは、より強力なモデルに伴うシンプルさを維持しつつ、一般ユーザーが求める制御を加えるよう同社に迫っている。
Anthropicは逆の圧力に直面している。Claude Codeは、可視化された進捗、頻繁な対話、ユーザーの関与を中心に、その魅力の多くを築いた。このアプローチはより安全に感じられる一方、繰り返される質問と承認はオペレーターの負担を増やす。
この競争は二つの製品思想を反映している。OpenAIはしばしば、目標を任せれば完成した結果を受け取れる体験を追求してきた。Anthropicは概して、計画、代替案、権限リクエストを通じて、中間的な推論プロセスをより多く示してきた。
どちらの考え方も普遍的に優れているわけではない。目標が明確で検証コストが低い場合、自律性は魅力的になる。好みが明示されていない場合や、結果を測ることが難しい場合、協働が価値を持つ。
これは、同一のモデルであってもインターフェースが見かけ上の品質を変え得る理由を説明する。ハーネスは、コンテキストの選択、ツールの説明、再試行の挙動、ファイルアクセス、ユーザー介入のタイミングを制御する。これらの判断が、モデルのすべての行動を形作る。
独立系フレームワーク開発者も同じ依存関係を観察している。LangChainは、モデル固有のハーネスプロファイルが、デフォルト構成と比べてtau2-benchの一部で10～20ポイントの改善を生んだと報告した。同社のharness profilesは、モデルごとの挙動に合わせてプロンプト、ツール、ミドルウェアを調整する。
この結果は、OpenAIの主張を単純化した見方に疑問を投げかける。ハーネスが一時的な補助具にすぎないなら、基盤となるモデルを固定したままハーネスを変えても、大きな性能差は生じないはずだ。
しかし同時に、不要な抽象化に対するOpenAIの批判も支持している。LangChainは、あらゆるモデルを改善する単一の、ますます複雑なアーキテクチャを見つけたわけではない。異なるモデルが異なる構成に反応することを見いだした。
実務上の圧力はプロダクトチームにかかる。1社のプロバイダー向けに密接な最適化を行うか、複数モデルにまたがる移植可能なレイヤーを維持するかを決めなければならない。
密接な最適化は、直近ではより良い結果をもたらす可能性がある。一方で、プロバイダー固有のツール、プロンプト、コンテキストの挙動への依存を生む可能性もある。移植性はその依存を抑えるが、汎用的なハーネスではモデルの能力を活用し切れないかもしれない。
エージェントにより広い権限が与えられるにつれ、これらの選択はさらに重要になる。パッチを提案するコーディングアシスタントの役割は限定的だ。コミュニケーションを読み、共有文書を編集し、業務システムを起動するエージェントは、複数の信頼境界をまたぐ。
したがって、こうした製品を評価するチームはモデルのベンチマークだけを見るべきではない。現実的な権限、データ、失敗条件の下で、モデルとハーネスを組み合わせた全体についての証拠が必要だ。
OpenAIはモデルに主導権を持たせたい
OpenAIの軽量ハーネス論は、開発者が環境を明確に示し、その後は適応的な挙動の大部分をモデルに担わせるべきだとする。
この立場は、テスト、権限管理、コンテキスト管理を取り除くことを意味しない。消滅が見込まれる制約を補う、手作りの推論手順に抵抗することを意味する。
最初のCodex WebアプリケーションにおけるOpenAIの経験は、この確信を説明する助けとなる。同社は当初、ユーザーの関与を最小限に抑えたままモデルがタスクを完了することに賭けた。Anthropicによる、より対話的なClaude Codeのアプローチは、当時モデルが確実に実行できたことにより適合していると判明した。
OpenAIは後に、ユーザーがCodexを導く機会を増やした。あるエンジニアは、以前の製品が、そのモデルとハーネスで支えられる範囲を先取りしていたことを認めた。
この経緯は、両側にある危険を示すため重要だ。ハーネスには硬直的なロジックが多すぎる場合がある。一方で、ユーザーが実際に得られる以上のモデル能力を前提にすることもある。
OpenAIの現在のアプローチは、より明確な環境と強力なフィードバックによって、別の不一致を避けようとしている。同社の社内エンジニアリングに関する説明は、構造化されたドキュメント、リポジトリのルール、計画、自動チェックを強調している。
これらの要素は、すべての推論手順を規定するワークフローより軽量だ。しかし、それでも広範なエンジニアリングを表している。ハーネスは判断を委ねながら、成功を検査しやすくする。
このアプローチはOpenAIの製品上の野心にも合致する。汎用的な職場向けエージェントは、ユーザーが求め得るあらゆる手順をデザイナーが予測することに頼れない。可能なタスクの範囲はあまりに広い。
モデル主導のシステムは、条件の変化に応じてツールを選び、計画を修正できる。この柔軟性は、ユーザーが一つの依頼の中で調査、スプレッドシート、メッセージ、コード、プレゼンテーションを行き来する場合に魅力的だ。
しかし、最小限のハーネスはより多くの責任をモデルへ移す。モデルは曖昧さを認識し、不足情報を求め、ある行動に確認が必要かを見極めなければならない。
こうした挙動は、汎用能力だけで保証されるものではない。モデルは指示の実行能力を高めても、欠陥のある目標を検出する能力まで同程度に高まるとは限らない。
ユーザー体験はそのリスクをさらに増幅する。職場AIを研究するWhartonの教授Ethan Mollickは、直ちに仕事を完了しようとするシステムと、比較を示してフィードバックを求めるシステムを対比してきた。
より自律的な設計は、エージェントが目標を正しく解釈した場合には摩擦を減らす。そうでない場合、ユーザーは首尾一貫していながら方向を誤った長い作業の連鎖が終わってから初めて、間違いを発見する可能性がある。
このため、コンテキストの品質が中心的な問題となる。軽量ハーネスは、簡潔で関連性が高く、最新の情報を提供するときに最も機能する。大規模で未選別のコンテキストは、モデルが長いコンテキストウィンドウをサポートしていても、優先事項を埋もれさせる可能性がある。
ナレッジワーカーにとって、その証拠を整理することは依然として別個のエンジニアリング課題である。検索可能なknowledge baseは、エージェントが行動を始める前に検索ノイズを減らせる。
OpenAIの主張は、機械によるフィードバックが密なタスクで最も強い。コンパイラ、テストスイート、リンター、ブラウザチェックによって、エージェントは絶え間ない人間の判断なしに進捗を評価できる。
完了の成否がセンス、組織の履歴、あるいは記録されていない期待に左右される場合、その能力は弱まる。モデルは、コンテキストに一度も入らない証拠を推論できない。
そのためOpenAIは、計算された賭けに出ている。モデルが進化すれば、計画や復旧をより多く内部で処理できるようになる。ハーネスの設計者は、昨日のモデルの制約を明日の製品に固定するのではなく、汎用性を維持すべきだ。
Anthropicは、より難しい作業には依然として多くの構造が必要だと述べる
Anthropicのより重いハーネスに関する証拠は、強力なモデルがオーケストレーションを不要にするのではなく、その有効な境界をより困難なタスクへ移すことを示している。
Anthropicの長時間稼働ハーネスは、繰り返し現れる二つの弱点から出発した。モデルは長時間の作業中に一貫性を失い、自らの出力を過度に高く評価していた。
第一の問題はコンテキストに関するものだった。長期タスクでは、判断、ツールの結果、エラー、部分的な実装が蓄積する。コンテキストウィンドウにそれらの情報を収められる場合でも、その整理方法はモデルが何に注目するかを左右する。
Anthropicは、構造化された引き継ぎファイルを伴うコンテキストのリセットを用いた。リセットにより、新しいエージェントセッションはクリーンな作業状態を得つつ、不可欠な進捗と次の手順を保持できた。
第二の問題は自己評価だった。アプリケーションを生成したモデル自身が、特に品質がデザイン上の判断に依存する場合、低品質な結果を受け入れがちだった。
Anthropicは、生成とレビューを分離した。その評価器は明示的な基準とブラウザ自動化を用いて機能をテストした。生成器は具体的な指摘を受け取り、修正を試みた。
最初の完全版ハーネスは、一文のゲーム要求を10回のスプリントにまたがる16の機能へと展開した。評価器は各スプリントに詳細な契約を適用し、あるレベルエディタ段階では27の基準を含めた。
Anthropicは、マルチエージェントの結果が、単一エージェントの試行にはなかった動作する中核機能を提供したと報告した。ただし、その実現には大幅に多くの実行時間、オーケストレーション、モデル利用が必要だった。
このトレードオフにより、この実験は単純なベンチマーク上の勝利よりも有用になる。追加の構造で何が得られるかを示す一方で、チームが評価器を無差別に追加できない理由も明らかにしている。
その後Anthropicは、より強力なモデルでこのプロセスを繰り返した。Opus 4.6は、従来のスプリント分解なしで、2時間を超えて主要なビルドを維持した。
これはOpenAIの中心的な観察を裏付けた。かつてハーネスが担っていた能力がモデル内部へ移り、足場の一部が不要になったのだ。
それでも評価器は重大な不足を見つけた。中核となる音声機能が、表層的なインターフェース要素またはプレースホルダーとしてしか存在しないことを特定した。生成器はその後、そうした欠落のいくつかに対処した。
Anthropicの結論は、すべてのタスクに3つのエージェントが必要だというものではない。評価器が最大の価値を発揮したのは、作業が生成器の信頼できる完了能力の境界近くにあった場合だった。
その境界は動的である。モデルのリリースは境界を外側へ押し広げ、より要求の厳しいタスクは再び内側へ引き戻す。
これは「苦い教訓」に別の解釈をもたらす。汎用モデルは昨日の問題に対する手作りの解決策を置き換えるが、以前は非現実的だった目標にも到達可能にする。
チームがそうした目標に取り組み始めると、新たな失敗モードが現れる。ハーネスは消えない。能力の最前線を追いかける。
Anthropicの立場は、評価も製品の一部であることを認識している。より多くの出力を生成するシステムが、自動的により有用になるわけではない。その出力が実際の要件を満たすかどうかは、誰か、あるいは何かが判断しなければならない。
開発者にとっては、テストスイートがその判断の多くを担える。デザイン、リサーチ、マネジメントの作業では、エージェントが行動する前に基準を明示しなければならないことが多い。
プランナー・評価器アーキテクチャは、こうした期待を明文化する。また、不適切な基準を増幅する可能性もある。評価器は、たとえその代理指標がユーザーの価値を見落としていても、与えられた測定可能な代理指標を強制する。
したがって、より重いハーネスは独自のガバナンス問題を生む。コンポーネントが増えるほど、維持すべきプロンプト、権限、ログ、引き継ぎ、失敗経路も増える。
Anthropicの証拠が支持するのは、恒久的な複雑さではなく、選択的な構造である。より強力なモデルが現在処理できるものは取り除き、検証がなお意味のある改善を生む領域へエンジニアリング努力を再配分すべきだ。
モデル対ハーネスの検証は、なお決着していない
どちらの側も、自らが好むアーキテクチャがモデル、タスク、予算、リスク水準を問わず勝つことを示していない。
OpenAIとAnthropicのハーネスをめぐる議論は、内部実験や製品観察に大きく依存している。これらの情報源はエンジニアリング上の選択を明らかにするが、CodexとClaude Codeを管理された条件で比較したものではない。
OpenAIの説明は、自社のモデル、リポジトリ、チーム慣行を反映している。Anthropicの事例は、選定されたアプリケーション構築タスクでClaudeモデルを使っている。各社が環境と成功基準を選んでいる。
Anthropicの詳細な比較でさえ、複数の変数を同時に変更している。完全なシステムは、計画、評価、分解、より長い実行時間、より多くのモデル呼び出しを追加した。その結果からは、どのコンポーネントが各改善を生んだのかを切り分けられない。
同社は後に、その問いを理解するためにコンポーネントの除去を用いた。それでも結論は、広範な独立検証ではなく、少数のデモンストレーションに基づいていた。
第三者ベンチマークは役立つが、追加の複雑さも持ち込む。ハーネスが高い性能を示すのは、そのベンチマークが好むワークフローに似ているためかもしれない。別の構成は、トークン使用量、合格率、レイテンシ、あるいは復旧可能性を最適化する可能性がある。
同じスコアでも、異なる運用リスクを隠しうる。あるエージェントは目に見える形で失敗して停止するかもしれない。別のエージェントは、自動チェックをすり抜けるもっともらしいが誤った結果を生成するかもしれない。
本番コーディングシステムに関する研究では、モデルとハーネスを一体のユニットとして扱う傾向が強まっている。最近のソースコード研究は、Claude Code、Codex CLI、Gemini CLI、Pi、OpenCode、OpenHandsを含む11のコーディングハーネスを調査した。
この多様性は、単一の最適なハーネスという考えを弱める。これらのシステムは、設計者が異なるユーザーを対象にしているため、コンテキスト管理、拡張ポイント、計画、隔離、ツール実行において異なる。
移植性も、未解決の課題として残る。報道では、同じOpenAIモデルを使いながら、オープンソースのPiハーネスがCodexを上回った比較が引用されている。
このような結果は、モデル提供者がすべてのタスクに最適な環境を自動的に構築するとは限らないことを示唆する。ただし、ベンチマークの設定と構成が決定的である以上、Piが広く勝つことを立証するものではない。
オープンなハーネスは、プロプライエタリ製品が隠すトレース、トークン使用量、構成の詳細を公開できる。その透明性は、チームが失敗を診断し、プロバイダーを切り替える助けとなる。
プロバイダーが管理するハーネスは、モデル固有の機能により早くアクセスできる。その開発者は文書化されていない挙動に合わせて調整し、連携した更新を展開できる。
事業上のインセンティブも重要である。OpenAIとAnthropicはいずれも、顧客が自社のインターフェースを通じて自社モデルを利用することで利益を得る。ハーネスを所有することは配布力を強化し、保存されたコンテキスト、統合、学習済みワークフローを通じて乗り換えコストを高めうる。
それは両社のエンジニアリング上の主張が誤りだという意味ではない。顧客は技術的な証拠とプラットフォーム戦略を分けて考えるべきだという意味である。
公開価格を比較しなくても、コストもまた不確実性の一つである。マルチエージェントによる計画と評価は、追加のトークンと時間を消費する。失敗のコストが高い場合、より高い完了率はそのオーバーヘッドを正当化しうる。
日常的で可逆的な作業には、逆のことが当てはまる。小さな編集ごとに評価器を動かすと、時折発生するエラーの修正より多くのリソースを消費する可能性がある。
安全性は、より軽いハーネスという主張をさらに複雑にする。より優れたモデルは、より長い一連のアクションを実行し、ツールをより効果的に使える。そうした改善は、誤解された指示がもたらす影響も増大させる。
権限の境界、監査ログ、サンドボックス化、確認は、ハーネスの機能である。能力が強化されれば、計画用の足場が必要なくなる一方で、それらの重要性が高まる可能性がある。
したがってチームは、一面的なテストを退けるべきだ。有用な評価では、タスクの完了、見えにくい欠陥、人間によるレビュー時間、リソース消費、失敗後の復旧を測定する必要がある。
また、同じモデルで構成を比較すべきだ。そうしなければ、コンテキストやツールの変更で解決できた問題に対して、より高性能なモデルを購入してしまうかもしれない。
現時点の証拠が支持するのは、条件付きのルールである。定義された信頼性のしきい値を満たす最も軽いハーネスを使い、観測された失敗が正当化する箇所に構造を追加する。
このルールは妥協のように聞こえるが、要求の厳しい運用作業を生む。チームは、コンポーネントがいつまで有用かを知るために、再現可能な評価、トレースの検査、バージョン管理された構成を必要とする。
その証拠がなければ、「より軽い」は次のモデルへの信仰になる。「より重い」は、プロンプトとワークフロー分岐に符号化された蓄積的な経験則になる。
どちらのアプローチが勝つかを決める三つのシグナル
次の段階を決めるのは、どちらかの企業が好むアーキテクチャの説明ではなく、比較可能な証拠である。
第一のシグナルは、ハーネスを入れ替えた場合の性能である。研究者とフレームワーク開発者は、モデル、タスク、ツールアクセス、リソース制限を一定に保つ管理されたテストを必要としている。
第三者ハーネスが同じモデルを使用しながらプロバイダーのインターフェースを繰り返し上回るなら、価値はオーケストレーション側へ移っている。その結果は、モデルの進歩が製品差別化の大半を自然に吸収するという考えを弱める。
適切に設計されたハーネス間で性能差が縮小するなら、OpenAIの論点は支持を得る。それは、より強力なモデルには専門的な介入が少なくて済み、よりシンプルで標準化された環境を通じて動作できることを示唆する。
第二のシグナルは、AnthropicとOpenAIがモデルのリリースごとに自社システムをどのように簡素化するかだ。Anthropicはすでに、Opus 4.6のワークフローからスプリント分解を取り除くことで、このテストの一例を示している。
次にどのコンポーネントが消えるかを注視すべきだ。計画、コンテキストのリセット、独立した評価、頻繁な承認は、それぞれモデルの限界に関する異なる仮定を表している。
タスク品質を低下させずにコンポーネントを取り除けるなら、より軽いハーネスの主張が強まる。そのコンポーネントをより困難な種類の作業へ移すなら、Anthropicの移動する最前線という解釈を支持する。
第三のシグナルは、ソフトウェアエンジニアリング以外での採用である。コーディングエージェントは、リポジトリ、テスト、デジタル化されたフィードバックの恩恵を受ける。ナレッジワークには、より弱いシグナルと、より多くの暗黙的な選好が含まれる。
人々が大幅な修正なしに完了した作業を受け入れるなら、モデル主導のエージェントは説得力を持つ。ユーザーが一貫してプレビュー、比較、承認チェックポイントを必要とするなら、協働型ハーネスのほうが強く見える。
最も有用な採用指標は、開始されたタスク数ではない。人間によるレビューと手戻りを考慮したうえで、正しく完了したタスクの割合である。
開発者は失敗の重大度も追跡すべきだ。より少ないタスクしか完了しなくても安全に停止するハーネスは、検出しにくいミスを犯しながらより多くを完了するハーネスより望ましい場合がある。
エンタープライズの購買担当者は、自社の文書、権限、ワークフローを使った評価を求めるべきだ。公開リーダーボードでは、組織固有の正しさの定義を表現できない。
ナレッジワーカーも、このプロセスのより簡単な版を実施できる。使い慣れた可逆的なタスクから始め、エージェントの結果を確立された人間のベースラインと比較する。
モデルがコンテキストを欠いた箇所、誤ったツールを選んだ箇所、主観的なガイダンスを必要とした箇所を記録する。こうした観察は、次の介入を指示、検索、承認ルール、独立したレビューのどこに置くべきかを明らかにする。
OpenAIとAnthropicのハーネスをめぐる議論は、一方の企業が薄いレイヤーを選び、もう一方が厚いレイヤーを構築するという形では終わらない。両社はすでに、モデルやタスクの変化に応じてコンポーネントを追加・削除している。
持続的な優位性を得るのは、そうした変化を迅速に測定できるチームだ。どの制約が依然として障害の防止に役立ち、どの制約が旧世代のモデルに基づく前提をただ維持しているだけなのかを把握できる。
エージェントを導入する組織にとって、直近で取るべき行動は明確だ。モデルとハーネスを一体としてテストし、実際のトレースを確認し、より広い自律性を与える前に成功の定義を定める。より強力なモデルはエンジニアリングの境界を変えるが、その境界を見極める必要性までなくすわけではない。
