AIコーディングの話になると、議論はすぐモデル比較へ向かう。どのモデルが賢いか。どれが速いか。どれだけ長いコードを書けるか。
もちろんモデルの能力は重要だ。しかし、実際の開発で不安定さを生む原因は、モデルの外側にも大量にある。
仕様が会話にしかない。正しい画面がどれか分からない。テストを実行できない。ログが読めない。権限が広すぎる。完了条件が曖昧なまま「いい感じに直して」と頼む。
この状態でモデルだけを強くしても、速く迷子になる可能性がある。
AIがコードを書く比率が増えた時、人間の開発者は何を書く仕事へ移るのか。
コードを書く実験が、環境を作る実験になった
モデル単体ではなく、文脈・道具・権限・テスト・観測性を束ねて性能を作る。
OpenAIは2026年2月、社内向けソフトウェアを「手書きコード0行」という制約で構築した実験を公開した。アプリケーション、テスト、CI、文書、可観測性、内部ツールまでCodexが生成し、最終的に約100万行へ達したという。開発期間は手作業なら必要だったと推定する時間の約10分の1だったとしている。
数字だけを見ると、「AIが大量のコードを書いた話」に見える。だが、記事の核心は別の場所にある。
チームが作り込んだのは、CodexがUIを起動して操作できる環境、ログやメトリクスを読める観測系、作業ごとに分離されたworktree、構造化された文書、機械的に検査できるアーキテクチャルールだった。
コード生成を増やすために、コードの外側を徹底的に整えた。
なお、これはOpenAI自身による単一チームの内部実験であり、期間短縮も自己推定だ。どの会社でも100万行を書けば成功する、という意味ではない。それでも、何に投資したかは重要な示唆になる。
AI開発の主戦場は「自己検証できるか」へ移る
結果を読み取る手段が環境にあれば、AIは実行・観測・修正・再検証を自律的に回せる。
人間なら、画面を見て「余白がおかしい」と気づける。ログを眺め、遅い処理を追い、要件と実装の微妙なズレを察知できる。
エージェントに長く仕事を任せるなら、その感覚を祈りで代用できない。結果を読み取る手段を、環境へ明示的に埋め込む必要がある。
UI──実際の画面を起動し、操作し、スクリーンショットで比較できる
振る舞い──testとacceptance criteriaで、何が成功か判定できる
内部状態──log、metric、traceから、なぜ失敗したか追える
構造──依存方向や命名規則を機械的に検査できる
正本──仕様と現在地へ短い導線で辿り着ける
これらが揃うと、AIは「書いて終わり」ではなく、実行し、観測し、修正し、もう一度確かめるloopを回せる。
強いモデルでも、何が正解か見えない環境では安定しない。反対に、検証可能な環境はモデルを交換しても残る。
巨大な指示書より、正本へ辿れる地図
OpenAIのチームは、巨大な一枚のAGENTS.mdへすべてを書く方法がうまくいかなかったと説明する。contextは有限であり、全部を重要にすると何が重要か分からなくなるからだ。
代わりに、短いAGENTS.mdを目次として使い、設計、product spec、実行計画、品質、securityを構造化したdocs/へ分けた。AIに覚えさせるのではなく、必要な時に正しい場所へ辿らせる。
これは人間の引継ぎにも効く。昨日の会話を知らないagent、新しく入った開発者、別のPMが、同じ正本から現在地を復元できる。文書は説明資料ではなく、実行環境の一部になる。
安全は、承認ボタンの回数では決まらない
agentが強くなるほど、できることを増やしたくなる。その一方で、毎回人間へ確認を出せば安全になるとも限らない。
Anthropicは、permission promptが増えると注意が薄れるapproval fatigueを報告し、OS-level sandboxを導入した。workspace内のwriteは許し、networkはdefaultで拒否するなど、危険な行動を環境側で狭めた結果、permission promptを84%減らしたとしている。
OpenAIも、sandbox、credentialのOS keyring保存、workspace固定認証、command rule、監査logを組み合わせている。両社に共通するのは、人間が毎回正しく警戒することより、agentが到達できる範囲を先に設計するという発想だ。
承認は重要だ。ただし、承認しか守りがない構成は、人間の集中力を無限資源として扱っている。
実装が自動化されても、専門性は消えていない
では、環境まで整えば人間の専門性は不要になるのだろうか。
Anthropicが約40万件のClaude Code sessionを分析した研究では、典型的な分業は、人間が「何を作るか」を多く決め、Claudeが「どう作るか」を多く決める形だった。domain expertiseが高い人ほど成功率が高く、失敗からの復旧にも強い傾向が観測されている。
コードを書く速度が価値のすべてではなくなる時、問題を正しく切り、制約を見抜き、結果の違和感に気づく力が前へ出る。
AIは専門性を消すのではなく、専門性が実装へ到達するまでの摩擦を薄くする。
ハーネスエンジニアリングを六つに分ける
Intent、Context、Action、Observation、Verification、Auditを会社の基盤として持つ。
Intent──目的、非目的、制約、完了条件を定義する
Context──必要な正本へ短く辿れる地図を作る
Action──filesystem、network、credentialの範囲を狭く与える
Observation──UI、log、metric、実機状態を読めるようにする
Verification──lint、test、security scan、acceptanceで閉じる
Audit──依頼、実行、承認、失敗、修正の履歴を残す
この六つは特定のAI製品に依存しない。モデルが替わっても、会社の正本と検証環境と権限境界は残る。
少人数の会社ほど、コードより先にハーネスを持つ
大企業には、仕様を補う人、QA、security、運用、文書管理の担当がいる。少人数の会社では、それらが一人の頭の中へ集まりやすい。
だからこそ、AIに任せる前に、現在地、根拠、完了条件、戻し方を外へ出す価値が大きい。最初は遅く見えても、二本目、三本目、別agentへの引継ぎで効いてくる。
EDIFORCEでも、記事を本文だけで持たず、research pack、fact gate、visual source、Owner GOを分けている。開発では、repo-owned docs、acceptance、worker report、監査可能なAPIを残す。これは管理を増やすためではない。人間の記憶をボトルネックにせず、AIの速度を安全に受け止めるためだ。
結論──開発者は、AIが働ける世界を書く
AI時代の開発者は、コードを書かなくなるわけではない。しかし、価値の中心はコードそのものから、そのコードが正しく生まれ、検証され、直され続ける環境へ広がる。
モデルを替える前に、agentは正本へ辿れるか。結果を自分で見られるか。失敗を検出できるか。危険な場所へ届かないか。
その答えをコード、文書、test、policyとして書く。そこに、ハーネスエンジニアリングという新しい仕事がある。
