[{"data":1,"prerenderedAt":281},["ShallowReactive",2],{"content-\u002Fcontents\u002Fagent-hooks-deterministic-control":3,"surroundPost-\u002Fcontents\u002Fagent-hooks-deterministic-control":272},{"id":4,"title":5,"body":6,"createdAt":255,"description":256,"draft":257,"extension":258,"meta":259,"navigation":260,"path":261,"seo":262,"stem":263,"tags":264,"thumbnail":270,"updatedAt":255,"__hash__":271},"contents\u002Fcontents\u002Fagent-hooks-deterministic-control.md","Agent Hooks Reading Guide",{"type":7,"value":8,"toc":226},"minimark",[9,13,17,20,23,26,29,32,35,38,41,44,47,51,54,57,60,63,66,69,72,76,79,83,86,90,93,96,99,102,118,121,135,138,152,156,160,163,167,170,174,177,181,184,188,191,195,198,202,205,209,212,216,219,223],[10,11,12],"h2",{"id":12},"どんな記事か",[14,15,16],"p",{},"この記事の中心は、エージェントを強くするには、よいプロンプトだけでなく、作業フローの決まった地点で必ず動く処理が必要だということ。モデルは計画や実装を柔軟に進められる一方で、毎回守るべきルールを忘れたり、後回しにしたりする。その部分を hook に寄せる。",[14,18,19],{},"hook は、SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Stop、SessionEnd のようなライフサイクルイベントに紐づく。イベントごとに matcher や filter で対象を絞り、コマンド、HTTP、MCP、LLM、subagent などの handler を実行する。",[14,21,22],{},"重要なのは、hook がモデルの思考を deterministic にするわけではないこと。モデルの実装方針や回復手順は揺れる。しかし、選んだライフサイクル地点で自分のコードが必ず走るため、保護パスのブロック、テスト実行、監査ログ、完了条件チェックのような部分を安定させられる。",[14,24,25],{},"記事には小さな checkout calculator のデモがあり、tests、generated code、protected fixture を使って、実務に近い hook の使い方を見せている。狙いは大規模フレームワークではなく、既存の scripts、tests、policy、runbook をエージェント作業へ接続することにある。",[14,27,28],{},"エージェント運用の実践記事である。主題は、agent workflow の特定地点に hook を差し込み、プロンプトだけでは守りきれない反復ルールを決定的に実行すること。",[14,30,31],{},"記事は Devin、Claude Code、Codex、Cursor のような複数環境を意識しており、demo では command handler を使う。shell script や Python script として policy を書けば、環境をまたいで再利用しやすい。",[10,33,34],{"id":34},"この記事の要点",[14,36,37],{},"第一に、hook を「モデルへの追加指示」ではなく「実行フローに入る制御点」として説明している。これにより、always、never、block、record、run、verify といった要件をプロンプトから分離できる。",[14,39,40],{},"第二に、SessionStart から SessionEnd までの代表的な lifecycle points を、開発者が最初に使いやすい形で整理している。開始時の文脈注入、プロンプト検査、ツール実行前ブロック、実行後検証、終了前チェック、終了時ログが一連の流れになる。",[14,42,43],{},"第三に、demo repo を通じて、保護パス、危険コマンド、テスト実行、品質ゲート、監査ログという実務で最初に欲しくなる hook を具体化している。",[14,45,46],{},"第四に、hook の価値を「目に見える出力」ではなく、避けられたミス、短くなった復旧ループ、残るログとして位置づけている。これは harness engineering の考え方に近い。",[10,48,50],{"id":49},"hook-の使い方","Hook の使い方",[14,52,53],{},"基本モデルは event、optional matcher or filter、handler、outcome の4つ。event は PreToolUse や Stop のような lifecycle moment。matcher は shell command だけ、file edit だけ、といった対象の絞り込み。handler は実際に動く処理。outcome は context、decision、log、state update など。",[14,55,56],{},"SessionStart では、プロジェクト規約、active constraints、環境情報、関連 runbook を読み込ませる。毎回最初に必要な context を、ユーザーやモデルの思い出しに依存せず渡す。",[14,58,59],{},"UserPromptSubmit では、ユーザーの依頼をモデルが見る前に検査し、追加 context を付けたり、危険な依頼をブロックしたり、適切なルートへ寄せたりする。",[14,61,62],{},"PreToolUse では、実行前の tool call を検査する。生成物、機密 fixture、.env、.git、repo 外パスの編集などをブロックする用途に向く。",[14,64,65],{},"PostToolUse では、成功した tool call のあとに検証を走らせる。Python や JSON の編集後に unittest を実行し、失敗したら品質ゲート state を残す、といった使い方ができる。",[14,67,68],{},"Stop では、エージェントが完了を宣言する前に、最後の quality gate が失敗していないかを見る。SessionEnd では、セッション終了理由、時刻、transcript path などを監査ログへ書く。",[10,70,71],{"id":71},"実務で効くこと",[73,74,71],"h3",{"id":75},"実務で効くこと-1",[14,77,78],{},"記事が示す実務上の効果は、エージェントの自由度を残しながら、守るべき制約を実行環境側へ移せること。モデルには実装や判断を任せ、保護パス、危険コマンド、テスト、完了条件は hook に任せる。",[73,80,82],{"id":81},"良い最初の-hook-は明確に言える-policy-に対応する","良い最初の hook は、明確に言える policy に対応する",[14,84,85],{},"protected paths、blocked commands、required tests、audit logging、repo context、completion gates は特に始めやすい。",[73,87,89],{"id":88},"prompt-instruction-は-guidance-に向く","prompt instruction は guidance に向く",[14,91,92],{},"一方で、毎回必ず実行する必要があるものは hook に向く。記事中の短い rule of thumb は、always、never、block、record、run、verify と言える要件なら hook 候補、というもの。",[73,94,71],{"id":95},"実務で効くこと-2",[14,97,98],{},"demo の構成は、小さな checkout calculator、tests、generated client code、protected fixture、hooks、runtime configs でできている。小さいが、実務の hook flow を一通り試せる。",[10,100,101],{"id":101},"注意点と読みどころ",[103,104,105,109,112,115],"ul",{},[106,107,108],"li",{},"hook はモデルの推論そのものを安定させるものではない。hook が安定させるのは、特定の lifecycle point で handler が走ることだけである。",[106,110,111],{},"導入には、event を選び、payload を見て、script を書き、失敗時の扱いを決める必要がある。プロンプトに一文足すよりは初期コストがある。",[106,113,114],{},"hook を増やしすぎると、作業が過度にブロックされたり、失敗原因が hook とモデルのどちらにあるのか分かりにくくなる。最初は明確な policy に絞るのがよい。",[106,116,117],{},"記事本文は実践ガイドであり、特定環境の hook API やイベント名の詳細は各公式ドキュメントで確認する必要がある。",[10,119,120],{"id":120},"読みながら見る場所",[103,122,123,126,129,132],{},[106,124,125],{},"まず見るべき流れは、event → optional matcher\u002Ffilter → handler → outcome。hook を大げさに捉えず、イベントに紐づいた小さな処理として読むと理解しやすい。",[106,127,128],{},"次に見るべきなのは、六つの lifecycle points。SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Stop、SessionEnd を、自分の作業フローのどこに対応するかで読む。",[106,130,131],{},"demo repo では hooks\u002F 配下の共通 policy logic と、.devin、.claude、.codex、.cursor の runtime config の分離を見る。環境ごとの差分を config に寄せ、policy 本体を共有する発想が使える。",[106,133,134],{},"コード例では、protected path block、command policy、quality gate、stop gate、session audit log を見る。最初に真似るなら、保護パスと品質ゲートが一番実用に近い。",[10,136,137],{"id":137},"次にやるなら",[103,139,140,143,146,149],{},[106,141,142],{},"自分の repo で最初に作るなら、PreToolUse の保護パス hook と、PostToolUse のテスト実行 hook がよい。どちらも policy が明確で、失敗時の挙動も決めやすい。",[106,144,145],{},"おい丸運用に引くなら、brain や wiki の非公開情報を公開 HTML に入れない、記事生成後にモバイル表示を確認する、テスト失敗時に完了しない、のような既存ルールを hook 候補として棚卸しできる。",[106,147,148],{},"次に読むなら、Codex hooks、Claude Code hooks、Cursor hooks、Devin lifecycle hooks の各公式ドキュメントを見て、同じ policy をどの event に写せるか比較するとよい。",[106,150,151],{},"さらに進めるなら、hooks を単発 script として増やすだけでなく、audit log、state、quality gate、skill 改善ループと接続する。ここまで行くと、プロンプト改善ではなく harness engineering になる。",[10,153,155],{"id":154},"読後qa","読後Q&A",[73,157,159],{"id":158},"この記事の一番大事な主張は","この記事の一番大事な主張は？",[14,161,162],{},"毎回守るべきルールは、モデルに覚えさせるだけでなく、agent workflow の lifecycle point に hook として差し込むと安定する、ということ。",[73,164,166],{"id":165},"hook-はプロンプトと何が違う","hook はプロンプトと何が違う？",[14,168,169],{},"プロンプトはモデルへの guidance。hook は特定イベントで実際に動く処理。保護、検証、記録、完了判定のような deterministic にしたい部分に向く。",[73,171,173],{"id":172},"代表的な-lifecycle-point-は","代表的な lifecycle point は？",[14,175,176],{},"SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Stop、SessionEnd。開始、依頼受付、ツール実行前、実行後、完了前、終了時に対応する。",[73,178,180],{"id":179},"pretooluse-は何に使う","PreToolUse は何に使う？",[14,182,183],{},"ツール実行前に payload を検査し、危険コマンド、保護ファイル、repo 外パス、機密ファイルの読み書きなどをブロックする。",[73,185,187],{"id":186},"posttooluse-は何に使う","PostToolUse は何に使う？",[14,189,190],{},"ツール実行後にテスト、formatter、scanner、logging、state capture を走らせる。編集後の品質ゲートに向く。",[73,192,194],{"id":193},"stop-hook-はなぜ必要","Stop hook はなぜ必要？",[14,196,197],{},"エージェントが完了を宣言する前に、直近の quality gate が失敗していないか、必要な確認が済んでいるかを止められるから。",[73,199,201],{"id":200},"hook-はモデルを-deterministic-にする","hook はモデルを deterministic にする？",[14,203,204],{},"しない。モデルの計画や実装は揺れる。deterministic になるのは、選んだ lifecycle point で handler が走る部分。",[73,206,208],{"id":207},"最初に作る-hook-は何がよい","最初に作る hook は何がよい？",[14,210,211],{},"protected paths、blocked commands、required tests、audit logging、repo context、completion gates のように、ルールが短く明確に書けるもの。",[73,213,215],{"id":214},"おい丸運用にどう効く","おい丸運用にどう効く？",[14,217,218],{},"AGENTS.md や memory に書いたルールのうち、毎回守るべきものを hook 化できる。公開ページ生成、テスト実行、秘密情報の混入防止、完了前チェックに特に効く。",[73,220,222],{"id":221},"一言でいうと","一言でいうと？",[14,224,225],{},"hook は、エージェントにお願いするルールを、作業環境が実行するルールへ変えるための仕組み。",{"title":227,"searchDepth":228,"depth":228,"links":229},"",2,[230,231,232,233,240,241,242,243],{"id":12,"depth":228,"text":12},{"id":34,"depth":228,"text":34},{"id":49,"depth":228,"text":50},{"id":71,"depth":228,"text":71,"children":234},[235,237,238,239],{"id":75,"depth":236,"text":71},3,{"id":81,"depth":236,"text":82},{"id":88,"depth":236,"text":89},{"id":95,"depth":236,"text":71},{"id":101,"depth":228,"text":101},{"id":120,"depth":228,"text":120},{"id":137,"depth":228,"text":137},{"id":154,"depth":228,"text":155,"children":244},[245,246,247,248,249,250,251,252,253,254],{"id":158,"depth":236,"text":159},{"id":165,"depth":236,"text":166},{"id":172,"depth":236,"text":173},{"id":179,"depth":236,"text":180},{"id":186,"depth":236,"text":187},{"id":193,"depth":236,"text":194},{"id":200,"depth":236,"text":201},{"id":207,"depth":236,"text":208},{"id":214,"depth":236,"text":215},{"id":221,"depth":236,"text":222},"2026-05-17","Agent Hooks は、エージェントに毎回守ってほしいルールを、プロンプトの記憶力ではなくライフサイクル上の deterministic な処理として実行するための考え方。保護パス、テスト、監査ログ、完了判定のような反復ルールを、hook として作業フローに差し込む。",false,"md",{},true,"\u002Fcontents\u002Fagent-hooks-deterministic-control",{"title":5,"description":256},"contents\u002Fagent-hooks-deterministic-control",[265,266,267,268,269],"論文まとめ","Agent Hooks","Harness Engineering","Deterministic Control","Codex・Claude Code・Devin・Cursor","\u002Farticle-pages\u002Fdocs\u002Fassets\u002Fgraphic-recordings\u002Fpaper-summary-default.svg","PnyZggC59-hRPO7MxNw0b4Rwkzcts3AXbSsElry8TU4",[273,277],{"title":274,"path":275,"stem":276,"children":-1},"PythonとTwitter APIを利用したツイート収集方法","\u002Fcontents\u002Fabout-twitter-api","contents\u002Fabout-twitter-api",{"title":278,"path":279,"stem":280,"children":-1},"Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents","\u002Fcontents\u002Fagent-libos","contents\u002Fagent-libos",1782055099371]