■ 1. 登壇者・背景
- 発表者: 株式会社ビズリーチ CTO 外山英幸（Hideyuki Toyama）
- 所属: Visionalグループ 執行役員 CTO / DX本部 本部長 / AI Product Studio室 室長
- ビズリーチはCodexで月間2,300億トークンを消費（総使用量・1アクティブユーザー当たり使用量ともに日本トップクラス）
■ 2. AI駆動開発の現在地と次の課題
- AI駆動開発はすでに一般化し、多くの組織が「もっと使う」フェーズにある
- フェーズの変遷:
- 浸透（2023〜2024）: 個人活用、PoC、教育
- 拡大（2025〜2026）: 全社展開、標準化、利用率最大化
- 次の課題: 「拡大」の先に何が来るかが問われている
■ 3. Harness Engineeringの台頭
- 2026年2月を境に、業界の議論の中心が「Harness engineering」に移行した
- Mitchell Hashimoto氏（HashiCorp共同創業者）がブログ「My AI Adoption Journey」で「Engineer the Harness」を提唱
- OpenAIのRyan Lopopolo氏が「Harness engineering: leveraging Codex in an agent-first world」を発表（3名チーム、5ヶ月、100万行、ゼロ手書き）
- harnessの定義: AIエージェントが正しく・速く・安全に動くための以下を統合して設計する営み
- 実行環境（execution environment）
- 文脈（context）
- ガードレール（guardrails）
- 検証ループ（verification loop）
- 観測性（observability）
- モデルだけでなく、harnessの設計も競争領域となっている
■ 4. HITLとHOTLの構造的違い
- HITL（Human in the Loop）の特徴:
- 人間がフローの「中」にいて、すべての判断点を通過する
- 設計・実装レビュー・テスト承認・リリース判断をすべて人間が行う
- 人間が律速点になる
- HOTL（Human on the Loop）の特徴:
- 人間がループの「外」から監督し、フローには介在しない
- 設計・実装・検証・統合・監視をすべてAgentが実行する
- 人間は「監督」と「方向付け」に集中する
- 人間は律速点から外れる
- HITLとHOTLの差異:
- 違うのは速度ではなく、制御位置と最適化対象
- HITLは「個人を速くする」最適化、HOTLは「ループ構造を設計する」最適化
- harnessを真剣に作ると開発は速くなるが、それはHITLのまま速くなっただけに過ぎない
- harnessで改善すること: レビューサイクルの短縮、1人あたりアウトプットの増加、待ち時間の消滅、デバッグの高速化
- それでも変わらないこと: 人間がフロー内部にいる構造、レビューが律速になる構造、設計・判断・承認が人間に集中する構造
■ 5. 本題: AI実行の統治（Governance of AI Execution）
- 問いは「AIをどう使うか」ではなく「AI実行を、どう統治するか」
- ADR・Wiki・設計書・Confluenceにドメインルールが書かれていても、現実には機能しない:
- Agentは参照しない
- 違反しても誰も止めない
- 変更影響を追跡できない
- 削除していいか誰も分からない
- 「書かれている」と「効いている」はまったく違う
- ADRを増やしても、設計書を充実させても、Wikiを整備しても、HOTLには到達しない
- ドキュメントを「書く」のではなく、ルール・チェック・実行を「制御構造に組み込む」必要がある
■ 6. AI統治の結論: 三権分立モデル
- AIを統治するには3つの機能を分離する必要がある:
- ① ルールを定める（立法）
- ② ルールに従っているかを判定する（司法）
- ③ ルールに基づいて実行する（行政）
- 従来はこの3つをすべて人間（特に熟練者）が持っていた
- AI Native（HOTL）では、構造として分離する必要がある
- ビズリーチの統治モデル「三権分立」:
- 立法AI（ルール）: 何が正しいかを定義する（ルールのSSOT）
- 司法AI（検証）: 適合しているかを裁く（contracts / guards）
- 行政AI（実行）: 実際に実行する（workflow / agent）
- 憲法（Constitution）が三権すべてを縛る。改正は人間のみが可能
- 三権の実装内容:
- 立法: ルール（憲法に準拠する具体規範）、制定/改正（AIが提案、人間が承認）
- 司法: セマンティックチェック（LLMで意味判定）、決定性チェック（Grep/AST等で機械判定）
- 行政: ワークフロー（タスク完了の事前定義）、スキル+ツール（エージェントを拡張）
■ 7. 汎用harnessと統治の分担
- 立法と司法はプロダクト・フェーズ依存であるため汎用化しづらい
- 汎用化できるのはharness（行政）だけ
- Anthropic・OpenAI・Cursorなどharness engineeringを提供する側は、構造的に行政までしか触れない
- harnessは借りられるが、統治は自社で作るしかない
■ 8. Authority Provenance Graph
- 目的: 「書かれている」を「効いている」に変えること
- 立法（ルール）と司法（チェック）を機械可読に・双方向に接続する層
- 接続例:
- ADRのルール ↔ それを検証するテスト
- ドメインルール ↔ 違反検知のassertion
- 設計原則 ↔ Linterルール
- graphによって機械可読に検知できる3つの問題:
- 立法なき司法: チェックは存在するが、何のルールに依拠するか不明
- 司法なき立法: ルールは存在するが、それを効かせるチェックがない
- 越境司法: チェックが、本来管轄外の領域まで裁いている
■ 9. Specification Provenance Graph
- 目的: 機能の成立を機械可読に追跡する
- 追跡構造: feature（機能）↔ requirement（仕様）↔ proof（テスト）をgraphで接続
- 追跡可能にする問い:
- この機能は何の仕様に基づくか
- どのテストで証明されているか
- 変更したら、何に影響するか
- Authority Provenance Graph × Specification Provenance Graphの2つが揃って、機能・非機能の統治が完成する
- Agentが自走するために必要な「追跡可能性」を機械可読にする
■ 10. graph設計の最重要原則: SSOTと派生データの分離
- 原則: 自動生成される情報を、判断の根拠として参照させてはならない
- SSOT（Single Source of Truth）の定義:
- 人が定義したもの
- 正式な承認プロセスを経たもの
- 例: 機能要件、ドメインルール、テスト・assertion
- 判断の根拠として参照可能。変更には承認が必要
- 派生データの定義:
- 機械が自動生成するもの
- いつでも再生成できるもの
- 例: 変更影響分析、自動生成された依存図、集計サマリー
- 判断の根拠としては参照不可。ナビゲーション・索引としてのみ使う
- 「便利だから」でSSOTと派生データを混ぜると、統治は必ず崩壊する
■ 11. 実証: HOTL型組織の突出した成果
- ビズリーチ社内で、HOTL型組織だけがPR数×Codexトークン消費量で桁違いに突出している
- チーム全体でも、一人あたりで見ても外れ値であり、「規模の差」ではない
- 同じ会社、同じツール、同じ時代でも桁違いの差が出る
- 違いを生んだのはAI利用量ではなく、AIを「どれだけ自律的に走らせられる構造を持っているか」
- AI実行密度: AI Agentが人間の介入なしに自律的に走り続けられる「密度」
- AIを使ったのではなく、AIを前提に組織構造を変えた
■ 12. harnessと統治の関係
- harnessは必要条件、統治は十分条件
- harnessだけではHOTLに到達しない。統治が、harnessを動かす
- harnessだけではHOTLに到達しない。統治で初めて完成する
■ 13. HOTL化に向けて自社で問えること
- 問うべきは「書かれているか」ではなく「効いているか」
- ① 判断の根拠は機械的にチェック可能な形で表現されているか
- ドキュメントに「ある」だけでなく、違反したらCIが落ちる・Agentが止まる状態か
- ADR・設計書・WikiはLevel 1に過ぎない
- ② 派生情報と原典は機械的に区別されているか
- 自動生成された情報が判断根拠として参照可能になっていないか
- 「便利だから」で原典と派生が混在していないか
- ③ ルール・検証・実行の繋がりは、Agentが追跡し、Agentが止められるか
- 人間が記憶や経験で繋いでいる状態になっていないか
- 接続が切れたら、Agentが違反を検知できるか
- 「書かれている」でYesにしてはいけない。「効いている」かを問え
■ 14. AI-Native時代に向き合う問い
- 今日話した統治はHOTLの入口に過ぎない
- HOTLは「AI前提の世界」であり、人間Firstの延長線上にはない
- 今後の探求領域:
- 機能以外の領域への統治拡大（セキュリティ、堅牢性、保守品質、インフラ、運用、DevOps）
- graph設計の深化（直交linkageの活用、状況に応じたナレッジgraph化、weight設計）
- プロダクトのAI-Native前提での再設計（「人間First」ではないドキュメント設計、HOTLを前提とした機能設計）
- 組織・プロセスのHOTL前提での再設計
- 必要な人材要件のアップデート
- AI Building AIの時代、競争力を決めるのはAIを使う量ではなく、AI実行を統治できるかどうか
- これは開発の話に見えて、事業と組織のあり方の話に接続する