01 / PROCEDURE
Skill — 業務の正しい手順
何を入力し、どう進め、どこで終わるか。AIが参照する作業契約。業務ルールは共通の原本に置き、モデル別にコピーしない。
例：記事作成の note-writing/SKILL.md。下書きと公開許可は別。INSIDE YZRS / AI WORK ARCHITECTURE
AIと働くための、
業務設計。
AIに仕事を渡す前に、何を任せ、何を確認し、何を残すかを決める。や印工務店が使っているSkill・Router・Wrapper・Hook・Guardの関係を、ローンチ業務の言葉から説明します。
これは既存の運用を外部向けに説明したものです。完成済みの全自動システムや、どのAIでも同じ安全性が働く仕組みを主張するものではありません。
01 / BUSINESS
AI導入というより、
仕事の渡し方を設計する。
企画・制作・公開・改善を経験している人なら、特別な技術を知らなくても理解できる考え方です。
人がやっていた「指示・進捗・品質・決裁・引継ぎ」を、AIが参加できる形にしている。
| ローンチ業務なら | YZRSの仕組み | 役割 |
|---|---|---|
| 業務マニュアル / SOP | Skill | 入力、手順、成果物、終了条件を共有する |
| 担当の振り分け | Router | 指示を対応するSkillにつなぐ |
| ツールごとの操作方法 | Wrapper / Adapter | AI環境と共通手順の間をつなぐ |
| 自動チェックの起点 | Hook | 対応環境のイベントで検査を呼び出す |
| 検査ルール | Guard | 条件に応じて警告・停止を判定する |
| 進行状況・引継ぎ | Agent State | 現在地を次のセッションに渡す |
| 決裁・公開承認 | Human / Owner Gate | 規約で定めた重要判断を人間に戻す |
大事な区別「PRをマージすること」そのものが一律に承認イベントなのではありません。承認が必要な行為は、作業内容に応じた契約で定義します。
02 / COMPONENTS
仕事を支える、6つの機構。
各機構の仕事を混ぜない。ルールを一か所に置き、実行環境ごとの差だけを接続層に残します。
02 / DISPATCH
Router — 依頼の案内係
短い合言葉を、該当Skillへ対応付ける目次。Router自体には記事の書き方や判断ロジックを置かない。
例：/note → note-writing、/pj → private-project-update。03 / CONNECTION
Wrapper / Adapter — 環境の翻訳
ChatGPT、Codexなど実行環境の違いを吸収し、共通Skillの入口につなぐ。中身の業務手順を複製しない薄い接続層。
例：Codex向け .agents/skills/。全Skillの完全コピーではない。04 / EVENT
Hook — 検査の起動点
セッション開始やファイル操作など、対応するイベントに連動して処理を呼び出す仕組み。設定があっても、実行時に発火するとは限らない。
例：対応環境での書き込み前チェック。利用可否は実行環境ごとに異なる。05 / DECISION
Guard — ルールの判定
禁止条件や注意事項を機械的に調べる判定ロジック。ある規則は停止、別の規則は警告とし、Hookやほかの実行経路から利用する。
例：共通判定の原本 _system/guards/vault_guard_core.py。06 / CONTINUITY
Agent State — いまの現在地
目標、制約、次の一手など、継続作業に必要な状態を持つ。作業の経緯を残すセッション記録や人間向け日報とは役割を分ける。
例：現在地の原本と、成果・検証ログは別に管理する。03 / EXECUTION
ひとつの指示は、
どう仕事になるのか。
例として「/noteで記事を作る」を考えます。これは考え方を示す図で、どの環境でも以下の工程が同じ順番で自動実行されるという意味ではありません。
INTENT → CONTRACT → EXECUTION → EVIDENCE
01 / HUMAN目的と境界を渡す
記事の目的、読者、触らない範囲、公開の扱いを決める。
02 / ROUTER指示先を決める
「/note」を共通の執筆Skillへ案内する。
03 / ADAPTER環境に合わせる
ChatGPTのGitHub Remoteなど、実際に使える経路で原本を読む。
04 / SKILL原本に従い制作
必要な資料、編集基準、終了条件に沿って下書きを作る。
05 / CHECK / GATE検証・必要な承認
環境に応じた検査を行い、記事の公開など明示許可が必要な操作で止まる。
06 / RECORD結果と理由を残す
成果、検証、未確認事項を適切な記録に残し、次へ引き継ぐ。
※ Hookは全工程を通す中央ゲートではありません。発火できる環境・イベントでだけ作用します。すべての業務に厳密な6工程を強制するものでもありません。
複数のAIを使っても、手順の正はひとつAIの名前で業務手順を分岐させず、Role（仕事）、Contract（条件）、Provider（AI提供元）、Access Channel（操作経路）、Execution Environment（実行場所）を分けて考えます。
04 / CASE STUDY
実際の小さなローンチ作業で見る。
抽象論だけで終わらせず、公開済みのAI Skill Recipeトップページ整理（PR #95）を、業務設計の観点から分解します。
REAL CHANGE / PR #95 / 2026.10公開PRを読む ↗
全面刷新を止めて、
古い入口だけを外した。
01 / OWNER INTENT目的を狭くする
電子工作通信と旧道具箱の案内を外し、作品集の役割を明確化。リニューアルはしない。
02 / CONTRACT変更対象を1ファイルに限定
5カテゴリと既存デザインは維持。作品番号と時期表示だけ必要に応じて整理。
03 / IMPLEMENTATIONAIが差分を作る
トップ掲載は22件から21件へ。GitHubで変更を確認できるPRを作成。
04 / VERIFICATION分かったことを分ける
HTML・連番など静的検証は実施。スマートフォン実機表示はマージ時点で未確認。
05 / OWNER DECISION残るリスクを見て判断
未確認事項を把握したうえで、オーナーがこの作業のマージを指示。
06 / REUSE判断理由が次の基準に
「既存を壊さず小さく直す」という方針を、後続の実装依頼にも再利用する。
この事例が示すのは、変更範囲と判断過程の管理です。ローンチの売上効果や、全端末での品質を証明するものではありません。
05 / TRUST
「書いてある」だけでは、
安全とは言えない。
業務管理の説明で最も大切なのは、保証できることと、まだ保証できないことを混ぜないこと。
設計上のルール
Skill、Owner Gate、判断基準を文書で定義する。これだけでAIが必ず守ると保証するものではない。
機械的な検証
Guardやテスト、CIで条件を確認する。単体テストが通っても、現場のHookが実際に発火するとは限らない。
実行環境での受入
そのAI、その操作経路、そのイベントで本当に動くかを確認する。未確認・未対応なら、そのまま明示する。
共通のGuardがあっても、すべての実行環境で自動停止するわけではない。
YZRSでは、Codexの特定実行経路において書き込み前Hookが動かない事例を確認し、同等の自動保護は NO-GO と判定した経緯があります。Claude Code向けの旧Hook資産は保持していますが、現在の標準実行環境ではありません。GitHub Remoteの変更もローカルHookには守られないため、ブランチ・PR・差分確認など別の手段で扱います。
一方、すべての可逆な内部変更で人の許可待ちをするわけでもありません。止める条件は各業務のOwner Gate、分からない条件は未解決として扱うことが原則です。検査と承認は別の役割です。
大切なのは、AIを無条件に信用することでも、すべてを疑って止めることでもない。
どこまで任せたかを説明できること。
06 / NEXT
次に残すのは、
答えよりも判断の材料。
実装成果だけでなく、「なぜそうしたか」「何を検証したか」「まだ分からないこと」を残す。これが別の制作や改善につながる。