AIが迷わず仕事を進められる「型」の作り方 〜10の工夫と638セッションの実測〜

はじめまして。今年の4月にLayerXへ入社した伊林です。「ちゃんさん」と呼ばれています。
バクラクで、申請・経費精算・債務管理を開発するグループのエンジニアリングマネージャーをやっています。前職までは10年ほどCTOをやっていて、転職の経緯については「CTO歴10年のエンジニアがプレイヤーに戻った理由」というインタビュー記事を是非ご覧ください。
インタビューでは「AIを前提に価値を出していきたい」と話していまして、この記事では、その現在地について共有させていただきます。

AIを前提に価値を出すとは

LayerXには羅針盤という文化があります。羅針盤は、LayerXが⼤切にする⾏動指針から派⽣する、具体的な⾏動をイメージできるようにしたものです。
その中で今僕が最も意識していることはこの2つです。

• AI-Nativeに仕事を再構築する

• AIオンボーディング・エージェントハーネスで、AIに仕事をさせる

AI-Nativeに仕事を再構築する

僕自身、これまでのやり方をAIに自動化してもらうのがAIネイティブであるとは思っていませんでした。
前提を疑って、本来どうあるべきかをAIを前提として考える。逆に人間が介在する価値を徹底的に考える事によって、人間が介在することなく自律的に動くシステムを構築することが出来る。介在が必要な場面では、速やかに最適な選択を人間がすることが出来る。
それこそがAI-Nativeな仕事だと思っています。

AIオンボーディング・エージェントハーネスで、AIに仕事をさせる

このときに大事になってくるのが「AIが働きやすい環境整備」であり、これが付加価値を決める決定要因になると考えます。

前置きが長くなりましたが、この記事では、AIに仕事を任せるために作った「型」の仕組みを、10の工夫に分けて書きます。仕組みを構築してから、僕が途中で軌道修正を入れるセッションの割合は、Codex側で3分の1以下、Claude Code側で半分以下になりました（計測の条件は記事の後半にまとめています）。

なぜ「型」が必要だったか

7月のはじめ、Claude CodeとCodexの全セッションログを分析しました。
セッション数は、4月の月18回から6月には月316回と、17倍に増えていました。めっちゃ使ってるじゃん、と思ったのも束の間、入社からの累計458セッションを読み返すと、僕が途中で「そうじゃなくて」と軌道修正を入れたセッションが139、およそ3回に1回ありました。しかも、訂正の内容をルールとして残せていたのは8回分だけ。131回分の学びを、その場で使い捨てていたことになります。
使う回数は17倍になったのに、使い方は入社時のままだったわけです。
問題は3つに分けられます。

• 「そうじゃなくて」で伝えた判断基準が、そのセッション限りで捨てられる

• 完了条件が「いい感じになったら終わり」しかなく、AIを自走させられない

• コンテキストが一杯になると会話が自動要約（compaction）され、決めた方針が薄れる

どれもAIの能力の問題ではなく、僕が仕事を渡す形の問題です。そこで、仕事の渡し方そのものを作り直しました。

結論: 判断基準、完了条件、人間の関門、記録を分離する

結論から言うと、AIに任せる仕事は、次の4つを分離して書くとAIが迷う場面が目に見えて減ります。

• 判定原則：迷ったときの判断基準。作業を始める前に渡す

• 停止条件：機械的に確認できる完了条件。ここまでAIが自走する

• Gate：人間が判断する関門。ここだけ人間が出る

• ログ：状態と判断の記録。コンテキストの外に置く

~/.claude/portal/
├── modes/               # 仕事の型（Markdown、12ファイル）
├── state/               # セッションごとの状態（JSON）
├── gates.tsv            # 人間の判断の記録
├── harvest-pending.tsv  # 訂正の自動抽出キュー
├── history.md           # 進化の記録（何を取り込み、何を見送ったか）
└── status.html          # state/ から生成する一覧ビュー

これにClaude Codeのhookを2つ（型の自動装着と、要約直後の状態再注入）足します。

10の工夫

1. 仕事を12種類の「型」に分ける

セッションを始めるときには必ず「型」を装着することが大事で、これによってAIの迷いがなくなります。
自分の仕事をリリース、障害調査、コードレビュー、OKR、1on1、執筆といった12種類に分け、1種類につき1枚のMarkdownを書きました。実装の型はこんな形です。

---
name: implement
triggers: 実装|作って|直して|修正して|追加して|対応して
---

## 判定原則
- 差分最小、シンプル実装、既存の書き方に揃える

## 停止条件
- build / test / lint が exit 0（コマンド実行結果で判定。自己申告は不可）
- fresh-context の検証エージェントが仕様突合で PASS
- 実機動作の証跡（ログ、スクショ）が PR に揃っている

## Gate
- マージ判断、PR の ready 化
- 仕様変更を伴う逸脱の承認

型は最初から完全に書けなくてかまいません。随時訂正していきます。

2. 判定原則を先に渡す

ログを読み返すと、訂正の多くは僕が判断基準を後出しにしたときに起きていました。「言っていなかったけれど、そこはこうしてほしい」というやつです。これ、AIからすると防ぎようがないんですよね。型の「判定原則」節は、この後出しを予防する入れ物です。

• 例：差分は最小に。依頼目的に直結しない整理や名前変更をしない

• 例：現行仕様より厳しい制限を勝手に導入しない

後出しの訂正は「AIの失敗」ではなく「渡し忘れの検出」なので、検出した基準はこの節へ移し替えていきます。

3. 停止条件は「そのまま指示に渡せる1行」で書く

停止条件は機械的に確認できる完了条件で、AIで自律的に動ききって欲しいものです。
コツは、自律実行の指示にそのまま渡せる文で書くことです。

テスト全緑、lint 0件、検証エージェントPASS。最大5試行で停止

「いい感じになったら終わり」は停止条件ではありません。機械的に判定できない完了条件を書くと、AIは楽観的に「できました」と報告してくることがあります。

4. 人間の判断は「Gate」として分離する

停止条件とGateの境界線は「その条件を決定論的に書けるか」です。境界線をきっちり引けるなら停止条件に置いてAIに任せ、書けないならGateとして人間に残します。

• Gateの例：マージ判断、リリース判断、記事の公開判断、仕様変更を伴う逸脱の承認

逆に言うと、Gate以外の場面で人間の出番が残っているなら、停止条件の書き込みが足りていないサインです。Gateでの判断は1行ずつ記録に残し、5回連続でpassした関門は停止条件への卒業候補に上げます。人間の関門を、感覚ではなく実績で減らしていくためです。

5. 型の装着は自動化する

frontmatterに正規表現を書いておき、UserPromptSubmit hookが依頼文と突き合わせて、マッチした型の本文をコンテキストへ注入します。

triggers: 実装|作って|直して|修正して|追加して|対応して

「実装して」と打てば実装の型が、「推敲して」と打てば執筆の型が装着されます。
1で必ず「型」を装着するとは言いましたが、僕自身よく忘れてしまいます…。装着を人の記憶やAIの従順さに頼ると、どうしても素通りされてしまうんですよね。こういうケアもAIと共に仕事をする上では重要なんだと思います。
ちなみに、この注入はサブエージェントには届かないため、委譲する際は型の本文が指示文へ転写される形となります。

6. 状態はコンテキストの外のJSONに置く

ゴール、TODO、決定事項、Gate待ちを、節目のたびにAI自身に1枚のJSONへ書き出させます。
これがとても重要で、特にロングコンテキストになってきたときにAIの精度を保つことを可能にします。タスクを進めていくとどうしてもロングタスクになったり、MCPとの接続も必要になったりしてコンテキストが増えるのは避けられません。そのような状態でも指示や今やるべきことが明確になっていることがとても重要です。

{
  "mode": "write",
  "goal": "寄稿ドラフトを点検 PASS まで推敲",
  "todos": [
    {"text": "実測の再集計", "status": "done"},
    {"text": "点検エージェント PASS", "status": "doing"}
  ],
  "decisions": ["時刻の表現は書かない", "顧客名はマスクする"],
  "gate": "本人の公開判断"
}

ちなみに、このJSON群からHTMLの一覧ビューを生成するツールも作成していて、全セッションの「今」とGate待ちが1画面に並びます。赤帯がGate待ちの行で、人間の仕事はこの赤帯の処理に寄っていることが視覚的に分かります。

7. 要約の直後に状態を読み直させる

コンパクションによって会話が自動要約されると、それ以降のAIは要約越しにしか過去を見られず、決めた方針が薄れていきます。これを防ぐためにも、「6. 状態はコンテキストの外のJSONに置く」がとても重要になってきます。
SessionStart hookの source=compact は要約直後に発火するので、ここで「このJSONを正として再装着せよ」と注入します。

# SessionStart(source=compact) hook から呼ばれる
sid=$(jq -r '.session_id // ""')
state="$HOME/.claude/portal/state/${sid}.json"
printf 'compaction 直後。以下のセッション状態（正）を再装着して続行する。要約と食い違う場合はこの状態を正とする。\n%s\n' \
  "$(jq -c . "$state")"

8. 検証は書いた本人にさせない

実装したAIに「テストは通りましたか」と聞くと、通っていなくても「通りました」と答えることがあります。検証は、何も知らない別のエージェントに仕様と成果物だけを渡して行わせます。
渡す指示にはこの2行を固定で入れます。

- 完全なテストスイートを実行した後にのみ PASS を出すこと
- 失敗すべきケースが失敗することも確認する（負のテスト）

9. 訂正は自動で拾い、ルールへ昇格させる

「そうじゃなくて」「やり直し」「覚えておいて」のような定型句を含む発言を、hookが1日1回、バックグラウンドでセッションログから抽出してキューに溜めます。週に一度見直し、残す価値のあるものだけを恒久ルールへ昇格させます。
昇格したルールの実物はこんな形です（抜粋）。

- WHAT を説明するコメントは禁止（命名で表現する）
- 結論を先に書く。理由や補足は必要な分だけ後ろに添える

導入前は3ヶ月で8件だった昇格が、導入後は2週間で8件になりました。あわせて、作業が終わるたびに「今回の作業をスキル化して」という決まったプロンプトで手順を資産化しています。
リリース作業や障害の一次調査は、この積み重ねで再実行可能な手順書になりました。

10. 外部の定石は、構造への影響まで評価してから取り込む

この仕組みの部品は、実はどれも公開されている定石です。
検証の分離は「Prompting Claude Fable 5」（Anthropic公式ドキュメント）、訂正を「書き忘れた暗黙知の検出」として扱う発想は「A Field Guide to Fable: Finding Your Unknowns」（Thariq氏）、最上位モデルには直接仕事をさせるより型を作らせるという発想は「鋳型としてのFable」（LayerX CTO 松本さんのnote）を下敷きにしています。
状態の外部化、要約の運用、検証の分離という構成は、Anthropicの「Effective context engineering for AI agents」が長時間タスクの手法として挙げる3つ（structured note-taking、compaction、sub-agent）と対応します。
取り込むときの原則は「文言の追記ではなく、構造への影響まで評価する」です。良さそうな一節をルールファイルに足すだけだと、ファイルが太って読まれなくなるんですよね。既に構造として持っているものは表現が違っても見送り、見送った判断も理由つきで記録しています。

• 見送り例：要約の発動をコンテキスト残量の割合で決める案。発動基準としてはタスクの境界のほうが支配的で、要約はプロンプトキャッシュを全損させるため頻度も上げたくない

• 見送り例：先回りのモード追加。新しい型は、作業実績と訂正が溜まってから作る

通しで見る実例: この記事のドラフト執筆セッション

工夫が実際にどう連なるのか、この記事自体のドラフト執筆セッションで見せます。
まず、執筆の型を装着すると、判定原則、停止条件、Gateが注入されます。

• 判定原則：顧客名や社内事情は書かない。文章規範に従う

• 停止条件：規範との突合点検を通過し、漏出チェックのgrepが0件で、fresh-contextの点検エージェントがPASS

• Gate：公開判断は本人

この型を装着したうえで、社内のSlackやNotion、ローカルPCなどから僕自身の動きを抽出して形にしていきます。執筆が進むと、決定事項がstateのJSONに積まれていきます。
なお、このセッションは長丁場で、会話の自動要約をすでに2回またぎましたが、要約のたびにhookがこのJSONを再注入するため、僕がゴールや方針を説明し直した回数はゼロです。

草稿ができると、停止条件が走ります。漏出チェックのgrepをかけ、何も知らない点検エージェントに文章規範と草稿を渡します。
このエージェントは実際に過去の稿へFAILを出していて、指摘には「冒頭の『3分の1』はCodex側の数字としか整合しない。どの数字が根拠か言い分けること」「実在しないhook名に言及している。削除すること」といった行が並びました。修正して再点検を通すまで、提出はできません。

最後がGateです。
点検がPASSしても、公開するかどうかは僕が判断し、その判断は1行の記録として残ります（工夫4）。この2週間の判断は10件で、8件をpass、2件をrejectしました。
結果、このセッションでは、最初の依頼・途中の方向修正・最後の公開判断だけでした。（その後下書きを基に本稿を作成しています）

効果の実測

効果は、入社からのセッションログで測りました。
対象はCodex側が554セッション、Claude Code側が保持期間内の直近6週間分84セッションです。ログから人間の発言だけを抽出し（自動注入されるコンテキストやサブエージェントとのやりとりは除外）、「そうじゃなくて」のような定型句を含むかで訂正を機械的に判定し、仕組みを導入した7月5日の前後で比べました。

冒頭の「458中139」はログを読んで軌道修正とみなした広めの判定で7月頭時点の数、前後比較は機械的に再現できる狭い判定です。
基準が狭いぶん数字は小さく出ますが、前と後は同じ条件です。Claude Code側はログの保持期間の制約で導入前のデータが直近分に限られるため、率の比較はツールごとに閉じています。

                            導入前          導入後
訂正ありセッション率
  Codex                     14.6%           4.2%
  Claude Code               29.2%          13.3%
1セッションの人間の発言数
  中央値                     6件             3件
  上位10%                   164件           28件
訂正のルール昇格            8件 / 3ヶ月     8件 / 2週間

導入をまたぐ直近3週では、週あたりのセッション数が54、60、86と増える一方、1セッションあたりの出力トークンは約14万、11万、6万と半分以下になりました。セッションが停止条件まで走って短く終わるようになった、と読んでいます。
効いていない数字も、正直に書いておきます。
プロンプト100回あたりの訂正回数は導入前後でほぼ横ばいで、僕が「そうじゃなくて」と言う癖そのものは直っていません。変わったのは人間ではなく環境の側で、人間を直すより人間の癖を吸収する仕組みを作るほうが早い、というのが実測から言えることです。

おわりに

同じ問題をデザインの側から扱った同僚の記事に「AIが迷わず読めるデザインドキュメントの作り方」があります。
判断の入口、条件、出口、ログを明確にするという整理は、この記事の判定原則、停止条件、Gate、ログとそのまま重なります。
AIに仕事を渡す形の設計は、職種を問わず同じ骨格に収束しつつあるようです。

AIに仕事を任せるようになっても、人間には多くの判断が残ります。
その一つひとつの判断の精度と速度を上げるためにも、AIを前提に仕事を再構築して、人間が判断に集中できる環境を自分の手で作っていく。
この記事の「型」は、そのための僕の現在地です。

LayerXでは、一緒に働く仲間を募集しています。
自分の働き方をAIネイティブに再構築したい方、カジュアルにお話ししましょう。

お知らせ：AIカンファレンス「Bet AI Day 2026」を開催します！

AIは「使う」段階から「共に働く」段階へ。
2回目となる「Bet AI Day 2026」は"AIエージェントと働く未来に、Betしよう"のメッセージを軸に、LayerXにおけるAIエージェント活用の実践知などを余すことなく共有します。

昨年同様にオンラインでも開催しますので、全国どこからでも、PCやスマートフォンからお気軽にご視聴いただけます。AIエージェントと働く未来について興味のある方、ぜひ「Bet AI Day 2026」にご参加ください！

「Bet AI Day 2026」開催概要
開催日：2026年9月3日（木）12:00 開演
開催方法：オンライン配信
参加費：無料（事前申込制）
お申し込み（connpass）：https://layerx.connpass.com/event/399169/