「正の参照」と 「負の導出」で組む ハーネスエンジニアリング

Transcript

1. 「正の参照」と 「負の導出」で組む ハーネ スエンジニアリング ― AI Agent に「正解」を参照させて、自律実行した記録 Dress Code株式会社 Product & Technology 渡邊 雅弘 / ハーネスエンジニアリング × AI Meetup
2. 自己紹介 渡邊 雅弘 Dress Code株式会社 Product & Technology @cottpan 業務 プロダクトエンジニア。情シス領域のプ ロダクトを中心に開発。 趣味 旅行 / カメラ / ゲーム etc... 経歴 2019/04 通信キャリア ネットワークエンジニア 2020/08 建築系ベンチャー CTO / 情シス / なんでも屋 2023/01 フリーランス モバイルエンジニア 2024/10 現職 Dress Code株式会社 01 / 16
3. 会社概要 Company Name 会社名 Dress Code 株式会社 CEO 代表取締役 江尻 祐樹 Established 設立年月 2024年9月 （正式創業： 2025年4月） Location 所在地 東京都中央区築地2-1-4 銀座PREX East 8F Member メンバー数 47名 PRE SEED & SEED ROUND 14.1 億円 資金調達を実施 NUMBER OF COMPANIES 215 +社 が利用中 NUMBER OF COUNTRIES 5 カ国 で事業を展開 02 / 16
4. CONFIDENTIAL Copyright © DressCode Inc. All rights reserved. 4
5. DRESS CODE 全体像 IT FORCE 情報システム • ソフトウェア管理 • デバイス管理 • ID & アクセス • ライセンス管理 • セキュリティ & MDM • ストレージ & ファイル • ネットワーク管理 • IT オペレーションコア HR FORCE 人事労務 • メンバー台帳 • 組織管理 • 労務コア • 業務契約者コア • 給与計算 • 勤怠管理 • 福利厚生 • メンバーサーベイ RCT FORCE 採用 • ATS • 入社前事務調査 • 面接管理 • リファラル採用管理 • 役割と職務内容管理 • オファーレター & サイン • 選考ステップ最適化 • タレントプール GA FORCE 総務 • 拠点管理 • 備品 & 消耗品管理 • 車輌管理 • ファシリティ管理 • 安否確認 • 郵便管理 • 社内イベント • 株主総会 PJ FORCE プロジェクト • プロジェクト • 予実管理 • リソース管理 • スケジュール管理 • マンパワー & ワークロード CG FORCE ガバナンス • プライバシー • リスク & インシデント • コンプライアンス • 監査 • ベンダー管理 Platform Capabilities オペレーションエンジン マーケットプレイス UI・UX デザインシステム 分析 & レポート ワークフロー & 自動化 ルール & ポリシー 権限 & 役割 契約 & 支払 通知 & 回答 ユーザーアカウント & 認証 コラボレーション People Graph + CoreDB 04 / 16
6. 本日のアジェンダ 1つのテストケース —— 約1万行の構造リファクタリングを自律実行した記録 —— を通して、 ガードレールを効か せながら AI Agent を自律的に実行する やり方を示します。 01 ケーススタディ 何を作り直し、どう自律実行したか 02 正の参照と、負の算出 ガードレールは手書きせず、正から算出する 03 検証まで含むループ 正と負が揃って、安全に回る 04 まとめ 明日からやる３つ 05 / 16
7. ケーススタディの全体像 IT FORCE「ソフトウェア管理」の一機能 —— SaaS と API で情報を定期的に同期するバッチ処理。挙動は変えず、内部構造だけを作り直した。 Choreography → Orchestration Saga 新規 BEFORE · CHOREOGRAPHY 各取得処理が「次に何をするか」を自分で判断し、イベントを投げ合 う。 取得の種類が増えるほど経路が絡み、全体の流れが追いにくい。 AFTER · ORCHESTRATION SAGA 指揮者（オーケストレーター）が中央で、次のステップを宣言的に決 める。 返事は「完了・継続・失敗」の3つ。取得と差分反映を分離し、負荷も分 散。 進捗は「プラン / ステップの状態」で一覧でき、同じプランを安全に（冪等に）再実行できる。 出典: Zenn「データ同期バッチを Choreography から Orchestration Saga へ作り直した話」 https://zenn.dev/dress_code/articles/deaca45dcb9873 06 / 16
8. AI Agent で、自律実行 先ほどの構造リファクタリングを、全自動モードで走らせた。 ≈10,000 行 対象規模 挙動は変えず、構造だけ 3 日 マージまで 実装そのものは1日 11 回 停止裁定 自走を止め、人間が裁定 完全放置ではない。止まるべき所で 11回止まり、裁定だけ人間がやった —— その「止まるべき所」を、誰が書いたのか? 出典: Zenn「データ同期バッチを Choreography から Orchestration Saga へ作り直した話」 https://zenn.dev/dress_code/articles/deaca45dcb9873 07 / 16
9. ガードレールは、誰が書いたのか AI Agent の「自律実行」で語られるもの・必要なもの。 制動 ガードレール 計測 評価 計測 観測 操縦 プロンプト設計 操縦 ツール定義 ガードレールは「こうするな」の 負 のルール。 「何を目指すか」を決める 正のルールが、 抜けていないか ? 08 / 16
10. 今日の主張 BEFORE 負のガードレールは必要 (こうしてはいけない)。 チェックリストの世界。安全に走れる。 -- でも、どこへ向かう? → AFTER 中心に「正の参照」 (こうあるべき)。負は正から算出、 検証は正で裁定。 自律実行には 正の参照 が重要。 ガードレールは手書きしない —— 正から算出して、参照させる。 09 / 16
11. 仕様を、リポジトリに置いて参照させる 曖昧な・口頭の指示 コードや会話履歴から仕様を幻覚 。長い会話でコンテキストが劣化し、指 示は流れて薄まる。 ↓ 参照可能な「正」 仕様書(提案・設計・仕様)をリポジトリに置き、参照させる 。 版管理・節の名指し・裁定根拠として再利用できる。 論拠 — プロンプト埋め込みは構造的に脆い ・ 中央に置いた情報は無視されやすい ・ 入力が長いほど従い方が劣化する ・ 出力形式1行の変更で予測の10%以上が変わる → 独立した外部コンポーネントに出し、参照・版管理・ 監査可能にするのが定石に。 出典: LINEヤフー Tech Blog「安全は基本、コスト削減はおまけ」 https://techblog.lycorp.co.jp/ja/20260122c 仕様 = エージェントが参照する、唯一の正解。 10 / 16
12. 負は、正から算出できる 仕様 → ガードレール 影響範囲 → 触ってよい場所 対象外 → 触ってはいけない場所 決定事項 → 再議論しないこと 特に効く節 → 必ず参照する箇所 同時に算出する運用ガード push可・merge禁止 停止条件 二段階エスカレーション deny: - infra 定義(別リポジトリ) §影響範囲 → 別PRで扱う - 決済まわりのモジュール §対象外 → 今回は変更しない - 旧テーブルの削除 §決定事項 → 後続フェーズで実施 各 deny の末尾が仕様の節を指す = 負が正から算出されている 仕様が決まれば、負(境界)の大部分は機械的に算出できる 。 allow / deny の手書きはスケールしない。 11 / 16
13. 「手書きして参照させる」のと、何が違う ? 外部ファイルにして参照させる点は同じ。違いは 真実の源(source of truth)がいくつあるか 。 ✕ ガードレールを手書き参照 ・仕様と二重管理になる ・仕様が変わっても、ガードレールは古いまま ・「なぜこの制約か」の根拠が残らない ✓ 正から算出 ・源は仕様ひとつ (ガードレールは導出物) ・仕様が変われば、再生成するだけ ・すべての deny に、仕様の節という根拠が付く 負は「もうひとつの正」ではなく、正の 導出物。真実の源はひとつでいい。 12 / 16
14. 正と負が揃って、初めて回る 正を置き、負を算出しても、一発では動かない。検証環境で隠れた不具合が3件。象徴的なのは 「仕様にもガードレールにも書いた制約 が、実装では効いていなかった」 。 エージェントループ = 停止条件を満たすまで、作業サイクルを繰り返す コンテキスト収集 → 行動 → 自分の作業を検証 ↺ 必要なら反復 チェックが定量的であるほど、自己検証は容易になる。 “ 人が起点でない自動実行（Proactive loop）を安全に回すには —— 明確な終了条件 ／大規模に流す前に小さくパイロット ／ ルーチンは小さく速いモ デル、判断は最も有能なモデルに 。 Anthropic「Getting started with loops」より（論の補強） ループの「検証」には照らし先が要る = 正。 「停 止条件」も、正から算出したもの。 出典: Anthropic「Getting started with loops」 https://claude.com/blog/getting-started-with-loops 13 / 16
15. 正があると、修正は安い 「あるべき挙動」が既に書いてあるので、修正は仕様との差分を埋めるだけ ——直す方向に迷いがない。 正の参照は、 3回起きる 1 実装するとき 2 ガードレールを作るとき 3 バグを直すとき 10,000 行 ↔ 300 行 自走 10,000行 に対し、修正は 300行。 3件中2件を その日のうち に解消。 14 / 16
16. 正を設計し、参照させ、ループを回す 1 仕様をプロンプトに書かない リポジトリに置いて、参照させる。(OpenSpec でなくてもよい) 2 ガードレールを手書きしない 触ってよい範囲・確定事項は仕様の中にある —— 算出する。 3 実装させて終わりにしない 検証と停止条件を備えたループを回す。検証の照らし先も、正。 15 / 16
17. 結び 私が思う、harness engineer とは—— 正を設計し、参照させ、 ズレを閉じる 人。 コードを書く時代 → 正を設計する時代へ ガードレールとメーターをいくら磨いても、的が無ければ周回するだけ。 まず、的を置きましょう。 16 / 16