判断を4つに分けても、記録の宛先までは決まらない

LayerXバクラク事業でエンジニアリングマネージャーを務める伊林義弘氏は、入社から4ヶ月間のAIエージェント利用ログを実測して公開している。セッション数は入社時点の月18回から、4ヶ月後には月316回まで増えた。氏が注目したのは17倍という増加率そのものではなく、訂正の中身だった。累計458セッションのうち139回が軌道修正の対象になっていて、そこから汎用的なルールへ昇格できた訂正はわずか8件しかない。131回分の学習が、ルール化されないまま使い捨てられていた計算になる(出典)。

氏の診断は、AIの能力不足ではなく、仕事を渡す形が壊れていることにあった。使う回数が17倍になっても、指示の出し方は入社時のままだったからだ。そこで氏が組み立て直したのが、判定原則、停止条件、Gate、ログという4つを分離して書く設計だった。判定原則は迷ったときの判断基準(「差分最小、既存の書き方に揃える」)を作業前に渡しておくもの、停止条件はテスト全緑やlint 0件のように機械的に確認できる完了条件、Gateはマージ判断のように決定論的に書けない判断を人間に留保する仕切り、ログはコンテキストの外側にJSON形式で残す状態の記録だ。「AIに任せる仕事は、判定原則・停止条件・人間の関門・記録を分離して書くとAIが迷う場面が目に見えて減ります」と氏は言う。実装後、Codexの訂正率は14.6%から4.2%へ、Claude Codeの訂正率は29.2%から13.3%へ下がり、ルールが昇格する速度も3ヶ月に8件から2週間に8件へと12倍速くなった。

四軸と同じ発想だ、と思いかけた

PRレビューツールParryを開発している立場からこの記事を読むと、判定原則、停止条件、Gate、ログという4分離は、Parryが導入時からPRに要求している四軸(Why/Risk/Confidence/Context)とほぼ一対一で対応するように見える。判定原則は事前に理由を明示するWhyに、停止条件は機械的に確認できる範囲を切り出すConfidenceに、Gateは人間の判断が要る箇所を示すRiskに、ログは判断の経緯を残すContextに、それぞれ重なる。伊林氏はPRレビューという言葉を一度も使わずに、独立して同じ切り分けへたどり着いていた。そうだとすれば、Parryの設計が社外の実測で裏付けられたことになる。

そう考えて、氏のログの実物を読み返した。対応が揃わない箇所が一つだけ残る。

{
  "mode": "write",
  "goal": "寄稿ドラフトを点検 PASS まで推敲",
  "decisions": ["時刻の表現は書かない"]
}

このログが解決しているのは、要約後の状態再注入というコンパクション対策だ。会話が長くなり要約が挟まると、「決めた方針が薄れる」。それを防ぐために決定事項をコンテキストの外へ出しておき、要約が起きるたびに読み直させる。つまりこのログの読み手は、そのセッションを継続しているAI自身であって、あとからPRを読む人間ではない。

宛先が違えば、同じ記録でも役割が変わる

Parryの四軸は逆向きの宛先を持つ。PRのWhyやContextに書かれる理由は、そのセッションを実行したAIが読み返すためではなく、あとでレビューする別の人間、あるいは別のセッションのAIが読むために書かれる。書く時点の読み手がセッションの中で完結するか、セッションをまたいで他者に渡るか。外見が同じ4つの要素は、この一点で違う層の問題を解いている。氏の4分離は、セッションの中で判断が薄れる問題を防ぐ。Parryの四軸は、セッションが終わったあと、なぜそうしたかが誰にも分からなくなる問題を防ぐ。どちらも意図が失われる場面を塞いでいるが、失われる時点が違う。

その宛先違いを、Parry自身も一度壊した

この違いを軽視すると何が起きるかは、Parryの運用記録に残っている。2026年8月、複数記事をまとめて執筆する依頼を受けた際、記事ごとに並列のサブエージェントを立て、執筆からPR送信までを丸ごと任せたことがあった。各エージェントは同じ作業ディレクトリを共有していて、一つのエージェントによるcheckoutとcommitの操作が、別のエージェントの作業に混入した。結果、公開済みだった記事2件のstatusをpublishedからdraftへ巻き戻す差分が、無関係な記事のPRに紛れ込んだ。レビュー前に発覚し実害はなかったが、原因は判断そのものの誤りではない。各エージェントの判断は、エージェントの中では一貫していた。ただしその記録の宛先が、他のエージェントにもメインの作業スレッドにも設定されていなかった。

対策として決めたのは、複数記事の本文執筆はエージェントで並列化してよいが、git操作とPR送信は必ずメインの作業スレッドが1記事ずつ順番に行う、という役割分担だった。エージェント内のログをそのまま外へ晒すのではなく、宛先を持つ場所へ判断を集約させてから初めて、記録は事故を防ぐ記録として機能する。これは伊林氏の4分離が扱っているレイヤーと、Parryの四軸が扱っているレイヤーの境界を、人間の運用でなぞり直した格好になる。

decisions配列は、セッションの外まで届くのか

残る疑問は、氏のログに書かれるdecisions配列が、そのセッションの外まで届くのかどうかだ。ルール昇格候補は週次で精査されるとあるので、精査を経た8件の知見は残るはずだ。だが、精査対象にならなかった残り131件の判断が、セッションの終了とともに消えるのか、それとも別の形でコミットメッセージやPRに書き残されるのかは、記事からは分からない。もし後者なら、氏の4分離とParryの四軸は、想像していたよりも近い場所でつながっていることになる。