■ 1. 発表の背景と問題意識
- 発表者（nrs / 成瀬 允宣）はLLMプロダクト3つを並行開発し、実装・調査ともにAIエージェントを活用している
- TAKTというAIコーディングエージェント向けオーケストレーションツールを自作し、複数プロダクトで利用している
- 開発に加え週4回の登壇が重なるなど業務密度が高く、フルAI活用でも「レビューと判断」は自分に残り続ける
- 前段（実装・調査・資料化）が速くなるほど、Human in the loopの確認だけが詰まりやすい構造になっている
- このボトルネックを「レビュー委譲」で解消することが本発表の主題
■ 2. サーヴァントエンジニアリングの概要
- 定義: 自分の判断基準を分解し、一面的な専門エージェント群で再構成すること
- キーコンセプト「Review as Code」: 判断基準を外に出し、再現できる工程へ移す
- 委譲するのは作業の丸投げではなく「判断基準のファイル化」である
- 誰として見るか（役割）
- 守る基準（禁止事項・品質基準）
- 判断の前提（構成・規約・設計意図）
- 人間は多面的でも一度に一面しか発揮できない（判断は逐次、注意は一点へ寄る）
- 一面ずつ外に出すと同時に発揮できる（一面ごとの狭いコンテキストなら同時に走らせても混ざりにくい）
- 出力には共通の返却形式（問題なし／修正が必要／理由／対象）を揃え、次の工程が判断できる形にする
- 分けて読む発想は新しくない（六色帽子、PBR）が、新しいのは「分けた一面をAIレビューへ常設すること」
■ 3. サーヴァントエンジニアリングの必要性
- 繰り返し指摘の課題:
- デフォルト引数、フォールバック、抽象化、デッドコード、ボーイスカウト原則を何度も伝えている
- 短絡的な力技の課題:
- AIがやりがちな短絡実装（無理やりstyle、隠れたfallback、未使用コード）が実行される
- 本来はbodyにclassを付けるところを、styleで見た目だけ合わせる実装が出てくる
- 知見の属人化:
- レビュー時に頭の中の基準を思い出して指摘する → PRコメントとして消え、次も同じ説明をし、チームの基準にならない
- 単一AIレビューの限界:
- 「このPRをレビューして」と依頼すると指摘は返るが、見た観点・見ていない観点が不明
- 指示しても読まないことがある（→「正直に言うと、前回はスキルを使う宣言をして、指定されたファイルを読み切ってから着手したわけではありません」）
- 多観点をひとつに詰めるほど、ひとつひとつの確認が薄くなる
■ 4. 自分のレビューを言語化して再現する手順
- まず見ているものを棚卸しする:
- 自分が見る: 込み入った実装、セキュリティ
- 見ない: 軽微な修正、動作で確認できる変更
- 部分的に見る: 実装の意図、影響範囲
- 一面ずつ切り分ける:
- アーキを見る役割として立てる
- 品質を見る役割として立てる
- 安全性を見る役割として立てる
- 一面ずつなら同時に外へ出せる
- いつもの指摘を原則にする:
- デフォルト引数 → 理由なく使わない
- フォールバック → Fail Fastを優先
- デッドコード → 置き土産にしない
- 判断の前提を知識に昇格する:
- 会話で説明していた構成・規約・設計意図 → リポジトリに置き、担当ごとに読み、同じ前提で判断する
- 明文化すれば毎回説明しなくていい（原則・知識・返し方を揃えるとレビューは再現しやすくなる）
- 明文化できない勘所は自分に残す（違和感、事業判断、最後の責任はファイル化しない）
■ 5. サーヴァントエンジニアリングの具体（3つの実装例）
- TAKTの例:
- レビュー基準ファイル（いつもの指摘・判断の前提・見る役割）をTAKT workflowに載せ、AIレビュアーに自分のレビュー基準を工程の入力として持たせる
- 一面ずつ専門に割って並列でレビューさせる（アーキ・品質・セキュリティ・テスト・振る舞い）
- workflowはstepとrulesで工程を定義: review → fix → re-review
- レビュアーには編集権限を渡さない（edit: false）、見るだけで指摘と理由を返す
- ステップの返答で次の工程が決まる（all("approved") → COMPLETE、any("needs_fix") → fix）
- review と fix のラリーが続く場合はloop monitorが停止判断する
- 力技のような実装を後段レビュー前に捉える（AIアンチパターンレビューを差し込む）
- CodeRabbitの例:
- policies/.md、knowledge/.md、rules/*.md → .coderabbit.yamlでPRレビュー時に読むファイルとして指定
- TAKTの原則ファイルと前提ファイルをCodeRabbitにも読ませる
- 指摘は並列に二系統で出る（TAKT基準に沿う指摘、CodeRabbit側の指摘）
- 同じ基準を渡しても、出力は完全な再現ではない（CodeRabbitの能力による補完も混ざる）
- 基準外の指摘は人間が採否を決め、何度も必要な指摘はTAKT側の基準ファイルへ明文化する
- AIコーディングエージェントの例（Claude Code、Codex）:
- レビューの観点・禁止事項・品質基準・プロジェクトの前提 → SKILL.md、AGENTS.md、サブエージェント設定として渡す
takt export-ccでClaude Code用、takt export-codexでCodex用にエクスポート- Skill宣言だけでは足りない（SkillやAGENTSで渡しても、読んだかどうかは成果物と確認手順で検証する）
■ 6. サーヴァントエンジニアリングを支える技術
- 一本目の柱「Faceted Prompting」:
- 分けるとは判断を一面ずつ外に出すこと（観点を分ける、材料を分ける）
- 巨大なpromptをSoCの原理で分割して管理し、合成して実行する
- 5つの関心に分ける:
- Persona（誰として見るか、一面の専門家）
- Policy（守る基準・禁止事項）
- Knowledge（判断の前提）
- Instruction（今回の指示・手順）
- Output Contract（出力の形式契約）
- Personaだけをsystem messageへ置き、基準・前提・手順は実行ごとに渡す（役割は強く固定し、基準・前提・手順は差し替える）
- Policy・KnowledgeはPolicyは共有し、Persona・Instructionは一面ごとに持つ
- 一箇所直せば使う全てに反映される（基準がファイルになるから、直しが全体へ行き渡り集合知になる）
- 二本目の柱「決定論的オーケストレーション」:
- workflowをYAMLで定義し、エンジンが定義どおりに回す
- workflowは有限状態機械として工程を保つ（AIの返答が揺れても、進む・戻す・止める条件は固定する）
- 並列の多面レビューは集約して判定する（一面ごとの出力を束ね、同じrulesで次の遷移を決める）
- 判定を実行から引き剥がす:
- Worker（実行）は実作業を担い、Output Contractに結果を固定し、Judge（判定）が結果だけを読んで次を決める
■ 7. レビュー分担の私的現在地
- 見る・任せる・聞き返すを線引きする（委ねるほど自分が見る範囲は狭くなる）:
- 任せる: 軽微・単純な変更はテストと実行結果に寄せる
- 聞き返す: 意図が曖昧なところだけ、判断を自分へ戻す
- 自分が見る: リスクや影響が大きい、込み入った変更は意図まで追う
- TAKT開発では他人作と込み入った実装を見る（軽微な修正は任せ、実装意図が曖昧な箇所だけ聞き返す）
- プロダクト開発では成熟度で確認の重さが増す（初期は動かして確認が中心、成熟はほぼ全部に目を通す）
- MVPでは見る範囲を絞り動かして確かめる（自分で見るのは一部、残りは動かす・専門に委ねる）
- AIが量産するほど確認待ちが自分へ積み上がる（実装は速くなっても判断とレビューは自分に戻る）
- コンテキストスイッチが脳を焼き切る（複数の現場を行き来するたびに集中が削られる）
- だから自分の一面をサーヴァントにする（判断を一面ずつ手放せば脳の負荷が下がり多面も同時に出せる）
■ 8. まとめ
- サーヴァントエンジニアリングを支える3つの型:
- 分ける: 1エージェント=1観点（アーキ・品質・安全性を混ぜず一面ずつ純度を保つ）
- ファイルにする: Policy / Knowledge（繰り返す指摘と判断の前提をファイルにして共有・再利用する）
- 工程にする: workflow / rules（進む・戻る・止める条件を決め決定論的に回す）
- 「自分を定義したら仕事がなくなる」——エンジニアリングってそういうもの
- 本懐を遂げるために自分の仕事を自動化しよう
- 課題を解決すれば次の課題が見えてくる