EXPLACE 5つのエンジニアリング ── 共通認識とセットアップ計画（社内・代表向け）
作成 2026-11-06・更新 2026-11-08（v3） ／ 状態：ドラフト（公開前・代表確認用）。「案」「未決」は黄、「実在」は紫、「決定済み」は緑。出典の取得日はすべて 2026-11-06。
00
DECIDE

この資料で決めること

層：入口　読み終えたら、返すのは2つだけ
この資料の目的 ── 目的を合わせる
エージェントが組織で動き、入力・処理・出力の質を PDCA で上げる体制をつくる前に、5つの言葉を共通にそろえる。
実在今ある部品案・未決これから作る・推測で埋めていない決定済み代表が決めた緑決定済み・ゴール・OK赤NG・失敗・リスク

00-1返してほしいのは、共通認識の可否と12章の12項目だけ

読んだあと、この2つを1回で返してもらえれば、次の版は作らず返答で直します。

①共通認識OK直す点②12章の項目答える12項目決定済み2項目（確認のみ）1回で返す代表の返答
根拠・出典・手順（折りたたみ）
  • この資料の目的：エージェントが組織で動き、入力・処理・出力の質を PDCA で上げる体制をつくる前に、5つの言葉を共通にそろえ、実装の順番を決める。
  • 返してほしい2つ：①5つのエンジニアリング（プロンプト／コンテキスト／ハーネス／ループ／グラフ）の共通認識は可か否か ②セットアップ計画と実装の順番の判断（優先順・未決）。
  • 根拠：代表の依頼文（作業票 §0）、v3 は代表の追加依頼（2026-11-08：各エンジニアリングの具体的な実装方法・AIへの実装のさせ方・国内外の実装例・段階的な実装）。ペルソナ段（読む段）は未決本人の現状は未確認。

00-2急ぐなら、5つの章だけ読めば返せる

急ぐ場合は5章で足ります。残りは必要なときの詳細です。

01 全体像関係図07 使い分け困りごとで引く13 実装の順番段階1〜410 セットアップ5本柱の順12 決めること返答
v3 で足したこと（レビュー用）
  • v3（2026-11-08）で足したもの：02〜06章に x-8 人が実装する手順（段階の階段）／x-9 AIエージェントに実装させる方法／x-10 国内・海外の実装例。新章 13 ORDER（実装の順番と落とし穴。表示は 07 の次）。12章は答える12項目＋決定済み2項目。11章に出典を追加。
根拠・出典・手順（折りたたみ）
  • 全14タブ：00 DECIDE／01 MAP／02 PROMPT／03 CONTEXT／04 HARNESS／05 LOOP／06 GRAPH／07 COMBINE／13 ORDER（表示は 07 の次）／08 DESIGN／09 PDCA／10 SETUP／11 LEARN／12 ASK。番号は 13 だが、既存の 08〜12 の参照を壊さないため番号は変えていない。
  • 扱わないこと：柱⑤（設計タブ）の追加改修、ai-office ソースの変更、デプロイ。柱⑤は 2026-11-06 に本番公開済み。この資料は計画の擦り合わせまで。
この章の結論
返してほしいのは、共通認識の可否と12章の12項目だけ
01
MAP

5つは別物ではなく、層と軸の関係

層：芯　関係図（外から内へ）と2本の軸（時間・構造）

01-15つは進化の階段ではなく、重なる設計のレンズ

古いものが消えるのではなく、外側の環境の中に構造があり、その中で繰り返しと1回の指示が動きます。

ハーネス環境・権限・安全枠グラフ複数体の連携ノードノード依存依存ノードループ実行検証改善プロンプト1回の指示コンテキスト見せる情報Agent ＝ Model ＋ Harness
定義は割れているこの関係図は動画7本の共通見解（NotebookLM 要約）で、公式な定義ではありません。「ループは古い、今はグラフ」という主張に、他の多くのソースは「グラフはループを束ねる構造」と反論しています（動画の食い違い）。
未決未決（埋めずに残しています）
EXPLACE 定義5つ（案）の承認未決・代表承認
根拠・出典・手順（折りたたみ）
  • 動画の整理：5つは「設計のレンズ」。対象は プロンプト＝1回の呼び出し／ループ＝1体の挙動／グラフ＝複数体の連携（出典：動画7本。要約の §1）。
  • 旧版（v1）の「プロンプト ⊂ コンテキスト ⊂ ハーネス」は、動画の共通見解に合わせて廃止した。
  • 確立度：プロンプト・コンテキスト＝確立、ハーネス＝一部で使用、ループ・グラフ＝造語に近い（01_research §1。動画で解説されていても変えない）。
  • 実装調査（2026-11-08）で補強：LangChain 公式ブログは「ループは有向の循環グラフにすぎない」という他者（David Khourshid）の言葉を引用し、"Graph engineering isn't a new idea." と書く（LangChain 2026-07-22）。電通総研 AITC（2026-09-07）は「グラフはループの上位互換ではありません」と書く（企業記事）。

01-2ループは「時間」、グラフは「構造」。プロンプト・コンテキスト・ハーネスは「材料と環境」

材料と環境を整え、時間で繰り返し、構造でつなぎます。

整える・回す・つなぐ対象材料と環境プロンプトコンテキストハーネス1回の呼び出し時間軸ループ1回繰り返し完了条件1体の挙動構造軸グラフ1工程分岐複数担当複数体の連携
根拠・出典・手順（折りたたみ）
  • 出典：動画7本（NotebookLM 要約 §1「時間軸 vs 構造軸」「対象範囲」）。軸としての整理は EXPLACE の見立てとしても採用未決・代表承認。

01-3確立しているのはプロンプトとコンテキスト。残りは造語に近い

言葉の強さに差がある。だから EXPLACE の定義を先に決めます。

プロンプト1回の指示確立コンテキスト見せる情報確立ハーネス失敗を防ぐ環境一部で使用ループ繰り返しの時間造語に近いグラフ工程と分岐造語に近い
根拠・出典・手順（折りたたみ）

定義表（出典つき。取得日 2026-11-06）

語一般の定義動画7本の見解（NotebookLM 要約）出典
プロンプトLLM への指示文を書き整える方法指示文（内容・役割・制約・出力形式）を厳密化し、単一の呼び出しの精度を上げるhttps://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview
コンテキスト最適なトークン集合を選び維持する戦略何を・いつ・どれだけ読ませるかを選別・設計するhttps://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents （Anthropic 2025-09-29）。Tobi Lütke 2025-06 提唱・Karpathy 支持は二次情報 https://simonwillison.net/2025/jun/27/context-engineering/
ハーネス失敗したら同じ失敗を二度としない仕組みを環境側に作る。Agent＝Model＋Harnessツール・権限・制約・指示書・安全装置など周辺環境を丸ごと設計するhttps://mitchellh.com/writing/my-ai-adoption-journey （Mitchell Hashimoto 2026-02-05、本人も用語の確立は留保）／https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents （2025-11-26）／OpenAI 原典 https://openai.com/index/harness-engineering/ は取得不可要確認
ループ確立した定義なし。関連実践＝Ralph loop実行・検証・改善を自律で回し、完了条件まで反復するhttps://ghuntley.com/ralph/ （Geoffrey Huntley 2025-07-14）。命名者要確認
グラフノード・状態・ルーティングを持つグラフとして設計タスク・エージェント・人の関係と依存・状態遷移を設計する。言葉は2026年に広まったが概念は昔からあるhttps://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph （LangChain 2026-07-22）
  • 動画の食い違い（要約 §7）：①ループは古いか ②グラフの実装（コード中心／スキルで自動構築／標準コマンド）③モデル配置（最上位だけ／上流と最終だけ最上位）。

EXPLACE 定義（案・代表承認まで確定語として使わない）

語EXPLACE での定義（案）
プロンプト1回の依頼文を整える。agent の本文（.claude/agents の指示）を含む
コンテキスト1回の呼び出しでモデルが見る情報を選ぶ。必要時だけ読む・要約を返す・外部メモに置く。ポリシーと承認条件の枠を先に確保する（動画：Policy First）
ハーネスモデル以外の環境全部。CLAUDE.md・rules/・hooks・検査担当・権限・人の関所
ループ完了条件を満たすまで同じ手順を繰り返す時間軸の設計（分・時間・日の3段）。完了条件・上限・別の評価者を必ず置く
グラフ工程・担当・分岐・状態の構造の設計。正本＝ workflows.json（AI Office のノード図は投影）
この章の結論
5つは設計のレンズ。外にハーネス、その中にグラフとループ
確立しているのはプロンプトとコンテキスト。残りは EXPLACE の定義を先に決める
02
PROMPT

プロンプト＝1回の指示を整える

層：中身　設計・実装・具体例・よくある失敗

02-1プロンプト＝1回の指示を整える

モデルに渡す1回の依頼文の書き方です。

プロンプト1回の依頼文確立
根拠・出典・手順（折りたたみ）

02-2良い指示は、5つの部品を組み合わせたもの

5つの部品の抜けを探せば、指示が直せます。

1回の依頼文役割指示例形式考えさせ方
根拠・出典・手順（折りたたみ）
  • 部品の根拠：Anthropic 公式（明確な指示・例示・XML構造・役割・思考・チェーン。01_research §1）。部品の数と呼び方は EXPLACE が5つに束ねた未決・代表承認。動画7本は「目的・役割・条件・出力形式」を挙げる（NotebookLM 要約）。

02-3指示は、5つの動詞で設計する

ここまでできれば OK＝同じ入力で、同じ形式が返ります。

定める例を足す構造にする試す直す目的と出力形式を1文良い例を1つ見出しや枠で区切る同じ入力で数回ずれた所だけ直すここまでできれば OK ＝ 同じ入力で同じ形式が返る
根拠・出典・手順（折りたたみ）

手順（5ステップ）

  1. 定める：この指示で出してほしい物（形式・長さ・禁止）を1文で書く。
  2. 例を足す：良い出力を1つ、悪い出力を1つ並べる（例は実在の出力から取る）。
  3. 構造にする：「役割」「やること」「出力形式」「やってはいけないこと」の見出しで分ける。
  4. 試す：同じ入力で複数回流し、形式が揃うか見る。
  5. 直す：ずれた箇所だけ指示を足す（全面書き直しはしない）。
  • 動画7本の4手順との対応（NotebookLM 要約 §2）：①目的と役割＝手順1 ②条件・ルール・制約（やること・禁止）＝手順3の「やってはいけないこと」 ③出力形式の指定＝手順1・3 ④雑な音声入力などを整えた指示文にする中間プロンプト（動画の手順。EXPLACE の導入は未決）。
  • 出典：Anthropic 公式（02-1）、動画7本（題名は冒頭）。

02-4指示の置き場は、agents と skills

担当ごとの指示は agent の本文、よく使う手順は skill に置きます。

設計部品役割と権限と指示.claude/agents（49体）繰り返す手順skills（SKILL.md）呼び出し/名前（slash コマンド）動画の部品プロンプトテンプレート・スキルファイル・音声入力＋整形スキル
根拠・出典・手順（折りたたみ）
  • 出典：https://code.claude.com/docs/en/sub-agents ／ https://code.claude.com/docs/en/skills （取得日 2026-11-06）。動画の部品は NotebookLM 要約 §3。
  • 実在：.claude/agents/（49体）の職務定義（00_要点 §2）。CLAUDE.md で /kickoff・/knowledge・/kosu・/scrape・/team-pdca・/order を使う記載がある。
  • 実装手順（3ステップ）：①agent 本文に「目的・入力・手順・出力・完了条件・引き継ぎ」を書く（解像度基準16項目の担当の定義）②繰り返す手順は skill に切り出す（作る（案））③指示を直したら 02-3 の「試す」を行う。

02-5資料作成チームでは、担当ごとに指示が1行で決まっている

指示が担当ごとに分かれているから、出力の形が揃います。

担当（実在）指示の1行doc-writer結論の見出し・2〜10字の図の語・1行・折りたたみ・CTAdoc-designer図を型から選ぶ・色を意味で当てる・HTML に組むcontent-checker事実確認・合否7問・図解ルール・合否と修正指示
根拠・出典・手順（折りたたみ）
  • 出典：Teams/collateral/02_workflow.md の D4・D5・D6 の「作業手順」欄。
  • 例1：doc-writer への指示。出力形式＝見出し＋図の語＋1行＋折りたたみ。
  • 例2：doc-planner の指示＝相手目線シートを埋める → 構成 → 層の印（D3 の欄）。
  • 例3：content-checker の指示＝事実確認 → 合否7問 → 問いかけ基準 → 表現 → 図解 → 顧客情報の混入（D6 の欄）。
  • 動画の例（EXPLACE の実績ではない）：議事録を「決定事項・宿題の順で表」と形式・順序で指定／セミナー表紙画像を色・禁止事項（グラデーション・ドロップシャドウ）で規定（NotebookLM 要約 §4）。

02-6プロンプトは確立した用語

公式ドキュメントがあり、根拠を取れる。

プロンプト確立
根拠・出典・手順（折りたたみ）

02-7「いい感じに」と書くと、精度が落ちる

1回の指示では、手順が増えるほど限界が来ます。そこからループとグラフに進みます。

原因結果曖昧な指示精度の低下ステップが増える精度が掛け算で低下対処：出力形式と禁止を書く
根拠・出典・手順（折りたたみ）
  • 動画の主張（NotebookLM 要約 §5）：精度95%の処理が10ステップ重なると最終精度は約60%（動画内の数字。一次情報で未確認要確認）。出典：動画7本（題名は冒頭）。

02-8指示を直す前に、合格ラインと評価セットを持つ

ここまでできれば OK＝新しい指示が、古い正解を落とさずに現行を上回ります。

成功基準1評価セット2初版を評価3AIに改善案4本番ログを戻す5次へ進む条件数値の1文自動採点できる失敗が数個の型現行を上回る（案）業務側が足す評価セットの置き場【未決】
根拠・出典・手順（折りたたみ）

段階（前提 → 次に進む条件）

段前提次に進む条件根拠
1 成功基準業務の正解を言える数値の合格ラインが1文で書けた。公式の例は "F1 score of at least 0.85"、悪い例は "Safe outputs"Anthropic 公式 develop-tests
2 評価セット段1実データで自動採点でき、件数が決まっている公式 develop-tests／ELYZA（数件・10件で素早く試す → 100〜300件でスクリプト評価）
3 初版を評価段2失敗が「名前のついた数個の型」に分類できたNurture Boss（Husain 2025-03-24）
4 AIに改善案段3＋人のレビュー権同じ評価セットで現行を上回り、既存の正解が落ちていない（回帰なし）調査担当の設計案（公式に同じ文言なし）
5 本番ログを戻す本番運用中業務側が実出力を見て評価に追加しているELYZA、Nurture Boss
  • Claude Code の部品名で：毎回の事実＝CLAUDE.md／手順＝skills/<名>/SKILL.md／担当の本文＝.claude/agents/。公式は例を <example> で囲み3〜5個を勧める（Anthropic 公式 prompting best practices）。評価セットの置き場は公式に指定なし未決・EXPLACE の設計事項。
  • 版管理（国内の例）：ELYZA はプロンプトを SemVer 風に版管理（MAJOR＝入出力の変更、MINOR＝互換の機能変更、PATCH＝文言の微修正）し、版ごとに変更理由と結果を記録（2025-07-07・古い）。
  • 調査担当の整理：計測つきの事例（ZOZO・LayerX・Nurture Boss）は、いずれも評価セットを先に持っていた（20_validation で個別の再検証はしていない）。
  • 注意：公式の例の勧め（3〜5個）と、Anthropic 社内記事の「例は探索を狭める」は食い違う。形式の指定には例、判断の指示には例を使わない、は調査担当の推測要確認。
  • 出典（取得 2026-11-08）：https://platform.claude.com/docs/en/test-and-evaluate/develop-tests ／ https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices ／ https://zenn.dev/elyza/articles/3b25b8e44fc280 （ELYZA 2025-07-07）／ https://hamel.dev/blog/posts/field-guide/ （Husain 2025-03-24）

02-9改善案はAIに出させ、採点基準と承認は人が持つ

AI が書いた改善案は、元より悪くなることがあるので、人が評価してから入れます。

指示文AI が作る人が確かめるAI に任せてよい初版の下書き失敗の分類案改善案評価の再実行人が持つ採点基準・評価データ改善案の承認禁止ルール案の確認手段・原文の部品prompt improverMetaprompt/doctor prompt-audit/tune（ZOZO の実例）
根拠・出典・手順（折りたたみ）

手段（出典つき。数字は注記つき）

手段中身注意
prompt improver既存プロンプトを Claude が改善（Anthropic 2024-10-14）Claude 3 Haiku・Wikipedia 500件で正答率 +30%（公式の脚注）。旧モデルで、現行モデルでの再現は未確認
Metaprompt（cookbook）タスクと変数を入れると Claude がプロンプトの雛形を書く公式の注意："not guaranteed to be optimal by any means, so don't be afraid to change it!"。単発の質問・応答向けで、複数ターンは対象外
/doctor prompt-auditCLAUDE.md・rules・skills・subagents を監査し、古い指示・存在しないファイル参照・矛盾を報告（公式 memory）変更はユーザーが承認するまで行わない
OpenAI prompt optimizer評価は 2026-10-31 に読み取り専用、"the platform is scheduled to shut down on November 30, 2026"（OpenAI 公式）2026-11-08 時点で約3週間後。新規採用は非推奨
  • 指示文の原文（公式の引用）：サブエージェントを使う条件を絞る一文＝"Use subagents when tasks can run in parallel, require isolated context, or involve independent workstreams that don't need to share state."（Anthropic 公式 prompting best practices）。
  • EXPLACE 用の指示文の例（案・実在の業務に当てはめた見立て。未試行）：「content-checker の指示文を直したい。過去に不合格だった出力を評価セットとして読み、失敗を数個の型に分類し、改善案を1か所ずつ出して。現行を上回り、すでに合格していた出力が落ちない場合だけ差分を示して。採用するかは私が決める。」（件数は未決）
  • 人が確認する点：①採点基準・評価データはドメインの専門家が決める（Husain：改善する人は AI を知らない人のことが多い、と書く）②最適化後のプロンプトが特定の入力で元より悪くなりうる（OpenAI 公式："it's possible for the optimized prompt to perform worse than your original on specific inputs"）。本番前に手で評価する ③LLM が出した禁止ルール案は人がレビューしてから入れる（LayerX の手順）。
  • 出典（取得 2026-11-08）：https://claude.com/resources/articles/prompt-improver （2024-10-14）／ https://github.com/anthropics/claude-cookbooks/blob/main/misc/metaprompt.ipynb ／ https://code.claude.com/docs/en/memory ／ https://developers.openai.com/api/docs/guides/prompt-optimizer ／ https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
  • 要確認Console の prompt generator の現行仕様は未確認。

02-10国内2件・海外2件が、評価の数字を出している（どれも件数は少ない）

数字は著者の計測で、第三者の検証はありません。方法を借りて、数字は借りません。

国内ZOZO データサイエンス部 2026-08-25VLM プロンプトの精度向上（/tune skill）T1 F1 0.7842→0.8641（初期値との比較）N=1・速報（著者の計測）LayerX／バクラク 2026-05-19問い合わせ対応の不要な確認質問NG率 80%（37/46）→約61%著者の計測・件数が少なく、有意性は保証されていないELYZA 2025-07-07（古い）PromptOps（版管理と評価の運用）方法のみ（精度改善の数字は使わない）海外Nurture Boss 2025-03-24（古い）賃貸 AI の日付まわりの失敗成功率 33%→95%著者報告・第三者検証なしAnthropic（Shihipar）2026-07-24Claude Code のシステムプロンプトを削る80%超を削減主張・評価の条件は非公開Anthropic 障害報告 2026-04-23品質低下の原因（長さ制限の行）1つの評価で 3% drop公式の障害報告
根拠・出典・手順（折りたたみ）

国内

誰・日付何をどう作ったか結果（計測と主張を分ける）
ZOZO データサイエンス部（大川）2026-08-25服の特徴を抽出する VLM プロンプトの精度向上Claude Code の /tune skill が SKILL.md を司令役に、analyzer・planner・improver・retrospector へ委譲。停止条件＝全 F1≥0.7・最大10イテレーション・3回連続の収束計測（著者）：T1 F1 0.7842→0.8641（初期値との比較。人手チューニング後との比較は 0.8473→0.8641）、T2 0.8481→0.9184、T3 0.8721→0.8794。チューニング1回 約6時間→約2.5時間、評価サイクル 約3.5週→約1週。N=1の速報。「人手より良い」は別時期の比較。指示文の原文は未掲載要確認
LayerX／バクラク（teyamagu）2026-05-19問い合わせ対応で LLM が「不要な確認質問」を出す問題実出力11件・質問46項目に OK/NG を付与 → LLM に禁止ルール案を出させ → 人がレビューして追加計測（著者）：NG率 80%（37/46）→ 約61%。「問題の性質に合わない情報」11%→0%。著者が「統計的な有意性は保証できません」と明記。件数が少ない
ELYZA 2025-07-07（古い）PromptOps（版管理と評価の運用）約100版の候補、3段評価（10件 → 100〜300件 → 顧客レビュー）方法のみ。精度改善の数字は本文に無く、結果としては使わない

海外

誰・日付何をどう作ったか結果
Nurture Boss（Hamel Husain）2025-03-24（古い）賃貸 AI アシスタントの日付まわりの失敗実ログを読む → 自由記述 → LLM で分類体系 → 頻度を数える → 失敗を捉えるテスト著者報告：成功率 33%→95%。失敗の上位3つで全体の60%超。第三者検証なし
Anthropic（Thariq Shihipar）2026-07-24Claude Code のシステムプロンプトを削る「ルールから判断へ」。古いモデル向けの強い規則を削減"We removed over 80% … with no measurable loss on our coding evaluations."。評価の件数・条件は非公開。「全部削るのが目的ではない」も併記
Anthropic の障害報告 2026-04-23品質低下の原因system prompt に足した「長さの制限」の行が他の変更と組み合わさり品質を下げ、4/20 に撤回1つの評価で 3% drop。再発防止＝変更のたびにモデル別の評価・行単位の検証
この章の結論
プロンプト＝1回の指示を整える
確立した用語。手順が増えるほど限界が来る
03
CONTEXT

コンテキスト＝モデルに見せる情報を選ぶ

層：中身　設計・実装・具体例・よくある失敗

03-1コンテキスト＝モデルに見せる情報を選ぶ

プロンプトの次の問いは「何を見せるか」です。

コンテキスト最適な情報の集合を選ぶ確立
定義は割れているTobi Lütke 2025-06 の提唱（Karpathy 支持）は二次情報。Anthropic は「最適なトークン集合を選び、維持する戦略」。EXPLACE 定義（案）は 01-3 の表未決・代表承認。
根拠・出典・手順（折りたたみ）

03-2机に置ける情報は限られる。何を置くかを選ぶ

全部を机に載せず、必要なものだけ置き、守る条件は最初に置きます。

机（モデルが見る範囲）システム指示ツール例履歴メモ取得した資料ポリシー・承認条件（特等席）外部の置き場ファイルサブエージェント必要時だけ読む要約して返す
根拠・出典・手順（折りたたみ）
  • 要素の根拠：Anthropic 2025-09-29（システムプロンプト・ツール・例示・履歴・コンパクション・構造化メモ・サブエージェント・JIT取得）。特等席は動画の「Policy First」（NotebookLM 要約 §6）。机の比喩は EXPLACE の図の言葉。

03-3情報は、洗って・分けて・要約して・外に残す

ここまでできれば OK＝担当ごとに読むファイルが一覧になっています。

必要な情報を洗う適量に絞る守る条件の枠を先に確保要約して返す形にする外に残すここまでできれば OK ＝ 各担当が読むファイルが一覧になっている
根拠・出典・手順（折りたたみ）

手順（5ステップ）

  1. 洗う：担当が仕事に使う情報（ファイル・ルール・前工程の出力）を書き出す。
  2. 適量に絞る：多すぎて忘れる／少なすぎて前提が足りない、のどちらも避ける（動画の手順）。
  3. 枠を確保：上限に達しても落としてはいけないポリシー・承認条件を先に入れる。省いた情報は「何を何件省いたか」を渡す（動画のルール。共通ルール案 4・5）。
  4. 要約で返す：サブエージェントは独自のコンテキストで動き、要約だけ返す（Claude Code の仕様）。
  5. 残す：途中の成果はファイルに置いて次の担当へ渡す。

03-4置き場は、サブエージェント・CLAUDE.md・knowledge/・rules/

毎回の前提と、必要時に引く知識を、置き場で分けます。

設計部品独立した作業サブエージェント（要約だけ返す）毎回の前提CLAUDE.md・memory相手の前提client-context.md守る条件rules/（NG表現）必要時の知識knowledge/ と Knowledge/3_型
根拠・出典・手順（折りたたみ）
  • 実在：CLAUDE.md（会社共通・フォルダごと。例：Management/Strategy/CLAUDE.md）、memory（MEMORY.md）、client-context.md、rules/、Teams/collateral/knowledge/README.md、Knowledge/CLAUDE.md（/knowledge の手順の正本）。
  • 動画の部品（NotebookLM 要約 §3）：CLAUDE.md・AGENTS.md・MEMORY.md・RAG／GraphRAG・コンテキストパック（YAML／JSON）・プロファイルファイル・MCP／Web検索。EXPLACE にコンテキストパックはない（作る（案）はしない・要否は未決）。
  • 実装手順（3ステップ）：①担当ごとの「読むファイル」を定義欄（入力情報）に書く ②毎回読むものは CLAUDE.md に、必要時のものは knowledge/ に置く ③長くなる調べ物はサブエージェントに任せて要約だけ受け取る。

03-5担当ごとに「読むもの・出すもの」が決まっている

前の担当の出力ファイルだけが、次の担当の入力です。

担当読む出すdoc-lead（依頼の一言）出す：00_brief.mdresearcher00_brief.md出す：01_research.mddoc-planner00・01出す：02_plan.mddoc-writer02_plan.md出す：03_draft.mddoc-designer03_draft.md出す：04_design/index.htmlcontent-checker04_design・出典出す：05_review.md
根拠・出典・手順（折りたたみ）
  • 出典：Teams/collateral/02_workflow.md の表（入力・出力欄）、00_brief.md §5。今回の run 2026-11-06_engineering-structure が実例（runs/<id>/）。
  • 例2（実在）：クライアント案件は client-context.md を先に読む（各チームの前提読み込み）。
  • 例3（実在）：資料作成チームの rules/（NG表現）を D4〜D6 で渡す（00_brief §9）。
  • 動画の例：NGワードのリスト（「いかがでしたか」など）を背景情報として与え、不自然な表現を抑える／過去の投稿文を解析したプロファイル（動画内の件数「391件」は要確認）で本人の口調の文章を作る（NotebookLM 要約 §4）。

03-6コンテキストは確立した用語

Anthropic が実装の指針を公開しています。

コンテキスト確立
根拠・出典・手順（折りたたみ）
  • 出典 URL は 03-1。Lütke の提唱は二次情報。

03-7渡しすぎも、渡さなすぎも、守る条件を追い出す

入れる量より、何を先に入れるかが効きます。

原因結果情報の渡しすぎ指示を忘れる情報の渡さなすぎ前提が足りない関連情報で枠を埋めるポリシー・承認条件が消える対処：守る条件を先に確保し、省いた量を渡す
根拠・出典・手順（折りたたみ）
  • 出典：動画7本（NotebookLM 要約 §5）。Anthropic 2025-09-29（03-1）は「最適な集合を選ぶ」ことを目的とする。数値はなし。

03-8CLAUDE.md は、短く置いて、同じミスの2回目に足す

ここまでできれば OK＝毎回読む前提が、短い事実だけになっています。

置く・削る・確認1失敗の追記2手順を分ける3文脈を分ける4自動メモリ5次へ進む条件200行未満・読込確認同じ指示を2回入れない（案）毎回必要な事実だけ/clear とサブエージェントMEMORY.md が200行未満（案）EXPLACE の CLAUDE.md の行数【要確認】
根拠・出典・手順（折りたたみ）

段階（前提 → 次に進む条件）

段前提次に進む条件根拠
1 置く・削る・確認リポジトリに検証コマンドがある200行未満、検証コマンドが1行で書けている、/context all の Memory files に載っているClaude Code 公式 memory・best-practices
2 失敗の追記段1同じ指示を2回入力しなくなった公式 memory のトリガー「同じミスを2回目にしたら追記」。条件は調査担当の設計案（推測）
3 手順・局所規則を分ける段2CLAUDE.md が「毎回必要な事実」だけになった公式 best-practices、Anthropic 社内記事 2026-07-24
4 文脈を分ける段3/clear を作業の切れ目で行い、調査はサブエージェントに任せる（要約だけ返る）公式 best-practices、Anthropic multi-agent 2025-06-13
5 自動メモリ段1〜3が安定MEMORY.md が200行未満に保たれている公式 memory。条件は設計案（推測）
  • Claude Code の部品名で：./CLAUDE.md（チーム共有）／./CLAUDE.local.md（個人・gitignore）／~/.claude/CLAUDE.md（個人・全プロジェクト）／/init（叩き台）／.claude/rules/（paths を YAML で指定して局所規則）／/context all（読み込みの確認）／/doctor prompt-audit（監査）。
  • 公式の原文：書くのは「リポジトリを読んでも分からないこと」だけ＝"Only write down what Claude can't find by reading the repo."。長さ＝"target under 200 lines per CLAUDE.md file"。実務者は300行未満（HumanLayer・Kasava）、60〜150行（Happy Elements）と揺れるが、この資料は公式の200行を採る。
  • 公式の注意：CLAUDE.md は「強制設定ではなく文脈」（"context, not enforced configuration"）。矛盾する指示は Claude が恣意的に一方を選ぶ（"Claude may pick one arbitrarily"）。守らせたいことは hooks（04-8）へ。
  • EXPLACE の最初の一歩（案）：CLAUDE.md の行数と、agent 定義の「入力情報」欄との重複を数える（現在の行数は未確認要確認）。
  • 出典（取得 2026-11-08）：https://code.claude.com/docs/en/memory ／ https://code.claude.com/docs/en/best-practices

03-9叩き台と矛盾探しはAIに任せ、何を残すかは人が決める

AI が書いた CLAUDE.md は出発点で、仕事の大半は行を減らすことです。

指示文AI が作る人が確かめるAI に任せてよい/init の叩き台重複・矛盾の指摘存在しない参照の検出自動メモリの記録人が持つ何を残すか矛盾の解消行数を減らす判断
根拠・出典・手順（折りたたみ）
  • 手段（公式）：/init（既存の CLAUDE.md があれば上書きせず改善案を出す）／CLAUDE_CODE_NEW_INIT=1 を設定すると対話式で CLAUDE.md・skills・hooks を提案してから書く／auto memory（Claude が自分でメモを書く。MEMORY.md は先頭200行／25KBのみ読込）／/doctor prompt-audit（Claude Code v2.1.283 以降）。
  • 公式の方向（Anthropic 社内記事 2026-07-24）：「# で CLAUDE.md に書く方式」から「関連する記憶を自動保存する方式」へ移行したと記述。2025-11 の公式ブログは # を勧めており、新しい記事を採る。現行仕様との突き合わせは要確認。
  • 指示文の原文は公開されていない（/init は組み込み）。
  • EXPLACE 用の指示文の例（案・未試行）：「CLAUDE.md と .claude/agents/ の各定義を読み、重複している指示、矛盾している指示、存在しないファイルを指す指示を一覧にして。削除や書き換えは提案だけにして、私が承認するまで変更しないで。」
  • 人が確認する点：行数と重複を減らす／矛盾の解消／自明な内容（ファイル構成など）は書かない。検証手順は専用 skill に切り出して CLAUDE.md から参照する（Anthropic 社内記事）。
  • 出典（取得 2026-11-08）：https://code.claude.com/docs/en/memory ／ https://code.claude.com/docs/en/best-practices ／ https://claude.dev/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models/

03-10国内は Progate の計測が1件、海外は多層化・短縮・外部メモリの例

短くして良くなった質問も、悪くなった質問もあります。両方を並べて見ます。

国内Progate 2026-04-21CLAUDE.md の圧縮 329→131行質問A コスト $0.234→$0.207質問Bは悪化 $0.367→$0.427（各8回・自己流）CureApp 2026-03-03CLAUDE.md に書く内容の判断基準定量なし【要確認】海外Kasava 2025-09-08CLAUDE.md の多層化（0→87ファイル）認証追加で「15分の節約」1件の比較・計測ではないHumanLayer 2025-11-25ルート CLAUDE.md は60行未満計測なし（実務者の記述）Manus 2025-07-18外部メモリとキャッシュ価格表に基づく主張計測結果は無しAnthropic 2025-11-26（古い）複数セッションをまたぐ実装定性のみ定量の成功率は無し
根拠・出典・手順（折りたたみ）

国内

誰・日付何をどう作ったか結果
Progate（横江・業務委託）2026-04-21CLAUDE.md の圧縮329行→131行。同じ質問を Before/After 各8回、claude -p … --output-format json でコストと時間を計測計測（著者・各8回・自己流）：質問A コスト $0.234→$0.207、所要 33.4s→28.8s。質問B（プレビュー）は $0.367→$0.427 と悪化。回答の質は定性評価
CureApp（7tsuno）2026-03-03CLAUDE.md に書く内容の判断基準「セッション開始時の作業を助ける情報か」で書き分け、.claude/rules/ を使い分け定量なし要確認。rules の再注入の記述は公式と未照合

海外

誰・日付何をどう作ったか結果
Kasava（Ben Gregory）2025-09-08CLAUDE.md の多層化数か月で 0→87 ファイル。ルート → サービス層 → コンポーネント層認証追加で「15分の節約」（1件の before/after・計測ではない）。「1分の文書化が10分の誤りを防ぐ」は著者の主張（計測なし）
HumanLayer（Kyle）2025-11-25ルート CLAUDE.md の設計ルートは300行未満、自社は60行未満。タスク固有は別 md に分けて一覧だけ載せる計測なし。"Claude will ignore the contents of your CLAUDE.md if it decides that it is not relevant to its current task."（実務者の記述）
Manus（Yichao Ji）2025-07-18エージェントのコンテキスト設計プロンプト先頭を安定させキャッシュを効かせる。ファイルシステムを外部メモリにする価格表に基づく主張：キャッシュ済み $0.30/MTok に対し未キャッシュ $3/MTok。計測結果は無し
Anthropic 2025-11-26（古い）複数セッションをまたぐ実装機能一覧は "passing" のみ変更可、1機能ずつ定性（機能200超のクローン）。定量の成功率は無し
この章の結論
コンテキスト＝モデルに見せる情報を選ぶ
入れる量より、何を先に入れるか
04
HARNESS

ハーネス＝失敗を二度と起こさない環境

層：中身　設計・実装・具体例・よくある失敗

04-1ハーネスは「失敗を環境に追記する」考え方

言葉はまだ定まっていません。EXPLACE の定義は案です。

一般の定義EXPLACE 定義（案）失敗を二度としない仕組みを環境側に作るAgent＝Model＋Harnessモデル以外の環境全部確立度：一部で使用
根拠・出典・手順（折りたたみ）

04-2モデル以外の全部が、ハーネス。他の4つを外側から包む

賢いモデルでも、環境がなければ同じ失敗を繰り返します。

Agent＝Model＋Harnessルールhooks検査担当権限人の関所内側に：グラフ・ループ・プロンプト・コンテキストモデルだけでは、同じ失敗を繰り返す
根拠・出典・手順（折りたたみ）
  • 根拠：Agent＝Model＋Harness（01_research §1）、動画の関係図（01-1）。中身の5つは EXPLACE の実在部品（CLAUDE.md・rules/、hooks、.claude/settings.json の権限、content-checker、G1/G2）に対応させた整理案。

04-3失敗を、仕組みに変える5つの動詞

ここまでできれば OK＝同じ失敗が二度出ません。

失敗を記録する原因を1行にする防ぐ仕組みを選ぶ追記する再発を見る「何を見落としたか」を1文ルールhook検査ここまでできれば OK ＝ 同じ失敗が二度出ない
根拠・出典・手順（折りたたみ）

手順（5ステップ）

  1. 記録：失敗した出力と、直した内容を残す（例：content-checker の 05_review.md の指摘）。
  2. 原因を1行：「何を見落としたか」を1文にする。
  3. 仕組みを選ぶ：文で防げるなら rules/（NG表現）、自動で止めたいなら hook、人が見るなら検査担当か人の関所。
  4. 追記：選んだ場所に追記する。
  5. 再発を見る：次の run で同じ指摘が出ないか確認する。
  • 動画の4手順（NotebookLM 要約 §2）：①実行前に危険操作（本番DB変更・ディレクトリ削除）を権限・フックで遮断 ②指示書・ルール・仕様書を配置 ③外部ツール（MCP・検索・ファイル操作）の接続 ④実行後にテスト・リンター・CI/CD で機械的に検証。EXPLACE は①②が実在、④の機械検査は content-checker が担い、テスト・リンターの基盤はない（ソフト開発の案件側）。
  • 出典：Hashimoto（04-1）、動画7本。

04-4hooks・ルール・権限・検査・関所に、失敗を置く

失敗の性質で、置き場所を選びます。

失敗の性質置き場自動で動かすhooks（PreToolUse／PostToolUse／Stop／SubagentStop）書いて守らせるCLAUDE.md・rules/できる範囲を絞る権限（settings.json）別の目で見る検査担当と作る担当の分離人が決める人の関所（G1・G2）
案失敗を自動で止める hook は未構築・作る（案）。現状の hooks は組織同期と稼働送信が中心です。
根拠・出典・手順（折りたたみ）
  • 出典：https://code.claude.com/docs/en/hooks （取得日 2026-11-06）。動画の部品：Claude Code＝フック・パーミッション・CLAUDE.md・スキル・サブエージェント／Codex・一般開発＝AGENTS.md・MCP・テスト・リンター・型チェック・CI/CD／AIオフィス（NotebookLM 要約 §3）。
  • 実在：.claude/settings.json に PostToolUse（hook_sync_ai_office.sh）、SubagentStart・SubagentStop・UserPromptSubmit・Stop・Notification（hook_ai_office_live.py）。AI Office は役割と権限を持つ担当が稼働する画面（動画の「AIオフィス」に近い考え方）。
  • 実装手順（3ステップ）：①失敗を3種に分ける（文で防げる／自動で止められる／人の判断が要る）②各種に置き場を割り当てる ③hook を足すときは .claude/settings.json を変える（ファイル変更のため代表の確認が要る）。
  • 注意：現状の hooks は組織同期と稼働送信が中心。失敗を自動で止める hook は未構築・作る（案）。

04-5作る担当と検査担当を分け、失敗を rules/ に追記する

人でなく仕組みが、同じ失敗を止めます。

doc-writer が作るcontent-checkerが検査不合格（指摘）rules/ の NG表現に追記次の run で再発を見るhooks：稼働を AI Office に送る
根拠・出典・手順（折りたたみ）
  • 出典：Teams/collateral/02_workflow.md（D6 は作った担当とは別が検査）、00_brief.md §9、ai-office/README.md（hooks の稼働送信。作業内容・プロンプトは送らない）。
  • 例1：D6 不合格 → D4・D5 へ戻す（2回まで）。
  • 例2：rules/ の NG 表現・NG構成を D4〜D6 で適用。
  • 例3：hook_ai_office_live.py が SubagentStart/Stop を送り、2時間終わらない稼働は「止まった？」（黄）で見える（ai-office README）。
  • 動画の例：本番データベースの書き換え・Git への直接プッシュ・特定フォルダの削除を権限フックで禁止して AI を運用／役割と権限を与えた AI スタッフが常駐する「AI社屋」（NotebookLM 要約 §4）。

04-6ハーネスは一部で使用。原典は未取得

用語は広がり始めたが、定義は固まっていません。

ハーネス一部で使用
要確認OpenAI 原典は取得不可未決・要確認
根拠・出典・手順（折りたたみ）
  • 出典 URL は 04-1。OpenAI 原典の取得要確認。

04-7権限を決めずに動かすと、事故になる

同じ指摘を人がくり返す間は、ハーネスができていません。

原因結果制限・権限なし誤削除・未承認の外部送信毎回、人が手で指摘効率が上がらない対処：自動で検出する環境
根拠・出典・手順（折りたたみ）
  • 出典：動画7本（NotebookLM 要約 §5）。数値なし。

04-8守らせたいことは、1つずつ hook にして、止まるところまで試す

ここまでできれば OK＝禁止したい操作を依頼して、Blocked が返ることを確かめられます。

CLAUDE.md に明文化11ルール＝1 hook2skills・検査・関所3観測して改善4次へ進む条件確認できるルールBlocked を試せた迂回と timeout を試した同じ失敗が二度出ない次へ進む数値基準は無い【要確認】skills は3回目の貼り付けで
根拠・出典・手順（折りたたみ）

段階（出典：実務者 WEEL 2026-08-10 の3段を原文どおり、公式 features-overview の置き方）

段中身次に進む条件
1「ルールを明文化する」。公式は CLAUDE.md を最初に置き、以降の拡張は「きっかけ」で足すとするルールが確認可能（checkable）な形で書かれている（WEEL の条件）。数値の基準は公式・実務者とも無い要確認
2「制約と検証を仕組みに埋め込む（フック・CI・lint・テスト）」禁止操作を依頼して、Blocked が返ることを試して確認できた（調査担当の提案・推測）
3繰り返す手順を skill にする。公式のきっかけ＝同じ手順を3回目に貼り付けるときdescription が他の skill と重ならない
4「観測し、継続的に改善する」同じ失敗が二度出ない（04-3）
  • WEEL の注意（原文）：「ルールを増やしすぎて身動きが取れなくなる」。
  • Claude Code の部品名で（hook 1本）：①スクリプトを .claude/hooks/protect-files.sh に保存して chmod +x ②対象パスを照合し、exit 2 で block ③.claude/settings.json に「event → matcher → handler」（例：PreToolUse → matcher "Bash"）で登録 ④/hooks で登録を確認 ⑤「.env にコメントを足して」と依頼して試す → Claude Code は実行前にブロックし、スクリプトの Blocked: メッセージを Claude に返す（公式 hooks-guide）。設定の置き場は ~/.claude/settings.json（全PJ）／.claude/settings.json（共有）／.claude/settings.local.json（個人）。
  • 公式の原文：hooks は CLAUDE.md の「.env を編集しない」より強い＝"Put guardrails in hooks."（公式 features-overview）。CLAUDE.md や skills は「依頼」、hooks は「確実に実行」。
  • 失敗時の挙動（公式 hooks-guide の言い換え）：hook が失敗・タイムアウトしても、既定ではツール呼び出しは進む。止めたい hook は onFailure: "block" を指定する（Windows で Git Bash が見つからない場合は、失敗した hook がツール呼び出しを止める例がある）。
  • EXPLACE：実在の hooks は同期と稼働送信（04-4）。失敗を止める hook は未構築・作る（案）。.claude/settings.json の変更は代表の確認が要る。
  • 出典（取得 2026-11-08）：https://code.claude.com/docs/en/hooks-guide ／ https://code.claude.com/docs/en/hooks ／ https://code.claude.com/docs/en/features-overview ／ https://weel.co.jp/media/harness-engineering/ （WEEL 2026-08-10、更新 2026-09-21）

04-9hook の下書きと試験はAIに任せ、人は3点だけ見る

AI に書かせるなら、人が見るのは「迂回」「止まらない」「費用」の3点です。

指示文AI が作る人が確かめるAI に任せてよいhook スクリプトの下書きsettings.json の登録案Blocked の試験skill の評価人が持つ迂回されないか止まらないか費用の上限手段・原文の部品/hooks で確認skill-creator
根拠・出典・手順（折りたたみ）
  • 公式の原文：hook を Claude に書かせる＝"You can also ask Claude to write the hook for you by describing what you want in the CLI." → 直後に /hooks で確認（公式 hooks-guide）。公式に「hook を書かせる指示文の原文例」は他に無い。
  • skills：.claude/skills/<name>/SKILL.md、frontmatter の description が呼び出し判断の材料。評価は /plugin install skill-creator@claude-plugins-official のあと「ask Claude to evaluate my summarize-changes skill with skill-creator」（evals/evals.json、skill あり／なしを subagent で実行。公式 skills）。
  • 公式の注意（原文）："If descriptions are vague or overlap, Claude may load the wrong skill or miss one that would help."（公式 features-overview）。
  • EXPLACE 用の指示文の例（案・未試行）：「.env と .claude/settings.json を編集しようとしたら止める PreToolUse hook を .claude/hooks/ に作って、chmod +x、登録案まで出して。登録は私が承認してから。作ったら『.env にコメントを足して』と依頼して Blocked が返ることを試し、結果をそのまま貼って。hook が失敗したときに止まるかも試して。」
  • 人が確認する3点：①迂回されないか（Write を止めると Bash に切り替えた1回の実ログがある。04-10）②止まらないか（失敗・timeout で進む。Stop hook の無限ループ）③費用の上限。詳細は 13-5。
  • AI の説明も検証する：国内の実務者は、Claude の説明をプロセスツリーで確認し「実際には…サブプロセスとして、コマンドを実行しているだけのように見えます」と判定した（Classmethod・とーち。公開日要確認）。
  • 出典（取得 2026-11-08）：https://code.claude.com/docs/en/hooks-guide ／ https://code.claude.com/docs/en/skills ／ https://code.claude.com/docs/en/features-overview ／ https://dev.classmethod.jp/articles/claude-code-hooks-basic-usage

04-10国内は1例の検証、海外は失敗を追記し続けた記録（どれも定量は弱い）

結果は1例の検証・本人の主観・自己申告で、数字としては使えません。

国内株式会社WEEL 2026-08-10ハーネス導入の手順の例「再実行では3件のテストがすべて通過」1例の検証・定量なしClassmethod hooks 7種（公開日【要確認】・古い）hooks の挙動確認Write を block すると Bash に切り替えた1回の実ログ・一般化しない海外Anthropic 2025-11-26（古い）claude.ai のクローン（機能200超）性能向上は定量なし限界も明記Mitchell Hashimoto 2026-02-05（古い）AGENTS.md と検証スクリプト「ほぼ全て解消」は本人の主観定量なしdisler（個人）取得 2026-11-0813 の hook event の実装サンプルREADME の記載「11/13 validated via automated testing」自己申告
根拠・出典・手順（折りたたみ）

国内

誰・日付何をどう作ったか結果
株式会社WEEL（企業メディア・監修 田村 洋樹）2026-08-10、更新 2026-09-21ハーネス導入の手順（CLAUDE.md・hooks・skills・memory）ゼロ除算の例外を規則化し、検証コマンドで手元確認「再実行では3件のテストがすべて通過しています。」（1例の検証・定量なし）
Classmethod（とーち）公開日要確認（2025-07 頃・古い）hooks の挙動確認（7種）PostToolUse・PreToolUse・Stop（exit 2）・SubagentStop を jq でログ化「stop_hook_active の値による判断を入れておけば永久ループを防ぐことができる」。Write を block すると Claude が Bash に切り替えた（1回の実ログ・一般化しない）

海外

誰・日付何をどう作ったか結果
Anthropic 2025-11-26（古い）claude.ai のクローン（機能200超）initializer agent が機能一覧（最初は全部 failing）と進捗ファイルを作り、coding agent は1機能ずつ。ブラウザ試験を追加"dramatically improved performance"（定量なし）。限界も明記（ブラウザ標準のアラートが見えない）
Mitchell Hashimoto 2026-02-05（古い）自分の AGENTS.md と検証スクリプト"Each line in that file is based on a bad agent behavior""it almost completely resolved them all."（本人の主観・定量なし）
disler（個人）取得 2026-11-0813 の hook event の実装サンプル.claude/hooks/ に event ごと、.claude/settings.json に登録README："11/13 validated via automated testing"（自己申告）。★4.0k（取得時点）。更新日は未確認
この章の結論
ハーネス＝失敗を二度と起こさない環境
用語は一部で使用。EXPLACE の定義は案
05
LOOP

ループ＝完了まで繰り返す時間の設計

層：中身　設計・実装・具体例・よくある失敗

05-1ループには、確立した定義がない

近い実践はあるが、言葉は固まっていません。

一般EXPLACE 定義（案）確立した定義なし関連実践＝Ralph loop完了条件まで繰り返す時間軸の設計。上限と別の評価者を置く確立度：造語に近い
根拠・出典・手順（折りたたみ）
  • 出典：https://ghuntley.com/ralph/ （Huntley 2025-07-14、取得日 2026-11-06）。命名者要確認。動画7本は「実行・検証・改善を自律で回し、完了条件を満たすまで反復」と説明（NotebookLM 要約 §1）。EXPLACE 定義未決・代表承認。

05-21周は、実行・検証・改善と、出口・上限でできている

出口（完了条件）と上限がなければ、止まりません。

上限（回数・費用）参照ファイル（毎回、新しい文脈で読む）実行検証改善別の評価者を置く完了条件を満たす？満たす出口満たさない実行へ戻る
根拠・出典・手順（折りたたみ）
  • 構成要素：毎回新しいコンテキスト・参照ファイル・完了条件（01_research §1、Huntley）／検証・改善（動画）。上限と別の評価者を置く点は EXPLACE の設計ルール案。

05-3ループは、完了条件・評価者・上限・止める人で設計する

ここまでできれば OK＝上限と止める人が書いてあります。

完了条件を書く1周の中身を決める別の評価者を置く上限を置く止める人を決める回数・費用ここまでできれば OK ＝ 上限と止める人が書いてある
根拠・出典・手順（折りたたみ）

手順（5ステップ）

  1. 完了条件：数で測れるものにする。例「指摘0、または全件に対応」（D6 の完了条件）。主観的な目標はループが破綻する（動画）。
  2. 1周：入力・作業・確認を1行ずつ。
  3. 別の評価者：自己採点で合格にしない。作る担当と検査担当を分ける（動画：別モデル・サブエージェントによるレビュー。EXPLACE は content-checker）。
  4. 上限：回数（例：2回まで）と費用未決。
  5. 止める人：超えたら誰に渡すか（例：3回目は代表）。
  • 出典：Teams/collateral/02_workflow.md（D6：2回まで、3回目は代表）、動画7本（NotebookLM 要約 §2）。費用上限は未受領未決。

05-4繰り返す手段は5つ。使える期間と起動条件が違う

PC を閉じても動くかと、完了条件を書けるかで選びます。

手段使える期間・起動条件/loopセッション内・7日で失効Desktop スケジュールPC 起動が要るCloud routinesクラウドで実行（制約は未確認）cron（Cloudflare Worker）daily-guide の実在/goal ＋完了条件公式に記載あり（版は未確認）
根拠・出典・手順（折りたたみ）
  • 出典：https://code.claude.com/docs/en/scheduled-tasks （取得日 2026-11-06。「定期タスクは作成から7日で自動的に失効する」＝"Recurring tasks automatically expire 7 days after creation"、2026-11-08 に再確認）。Cloud routines の詳細な制約は要確認。
  • /goal（v3 で更新）：Claude Code 公式ドキュメントに記載がある（https://code.claude.com/docs/en/goal ・取得 2026-11-08）。v2 の「公式で未確認」は解消。版の要件と評価モデルの既定は公式本文で未確認要確認。使い方は 05-8・05-9。
  • 動画の主張（NotebookLM 要約 §3・§7）：Claude Code・Codex・Cursor に標準搭載の /goal ＋完了条件 とオートモード／自作 Bash ループ「Ralph」（Huntley 提唱）。動画の1つは、現在は Ralph より /goal が適すると述べる。
  • 実在：explace-daily-guide は Cloudflare Worker＋cron＋KV（daily-guide/README.md）。launchd jp.explace.daily-guide-status が30分ごとに件数を Worker へ渡す（Mac が起きている間）。
  • 実装手順（3ステップ）：①ループごとに起動条件（PC 要／不要）を決める ②上限を設定する場所（回数・費用）を決める未決 ③試運転で1周させ、止める人に通知が行くか確かめる。

05-5実在のループは、回数に上限がある

実在のループは、出口と止める人を持っています。

① 差し戻し（資料作成チーム）D6 レビュー不合格D4・D5 へ戻る2回で3回目は代表回数に上限（2回まで）② 毎日の確認（daily-guide）平日 8:30 投稿代表が ✅17:15 に残りを確認翌日も同じ流れ
根拠・出典・手順（折りたたみ）
  • 出典：Teams/collateral/02_workflow.md（D6）、daily-guide/README.md（月曜 8:00 の俯瞰、平日 8:30 と毎時 :00、17:15 の残り）。
  • 例3（案）：自動 PDCA の「分」ループ。1業務の出力を content-checker が検査し、完了条件・上限・止める人を置いて1周させる（09章。最初の1業務は12章で代表が選ぶ）。
  • 動画の例（EXPLACE の実績ではない）：生成画像の文字崩れをビジョン機能で確認し合格まで生成を繰り返す／売上レポートの計算結果が一致するまで再計算／/goal でテスト全パスを完了条件に、睡眠中に修正ループを回す（NotebookLM 要約 §4）。

05-6ループは造語に近い

実践はあるが、共通の定義はありません。

ループ造語に近い
根拠・出典・手順（折りたたみ）

05-7上限がない・自己採点・曖昧な目標で、ループは壊れる

ループを回す前に、止め方を書きます。

原因結果終了条件と上限なし料金の高騰・時間の浪費AI が自分で採点採点が甘く、ミスが残る数にできない目標止まる点が決まらない対処：完了条件・上限・別の評価者
根拠・出典・手順（折りたたみ）
  • 出典：動画7本（NotebookLM 要約 §5）。数値なし。

05-81つのループが、止まり・証拠を残し・やり方を変えてから、次へ

ここまでできれば OK＝上限で止まり、判定の理由が残り、失敗のあとにやり方が変わります。

完了条件を1文1/goal で回す2失敗は人へ戻す3hooks・予算ガード4無人化5次へ進む条件1回の確認で合否上限で止まる上限内で合否が出る禁止が止まる・ログが残る数日〜1〜2週の観察（案）無人化の観察期間は代表の許容損失と照合【要確認】せーの＝Classmethod の試行。サンドボックスの1ケース（公開日【要確認】）
根拠・出典・手順（折りたたみ）

段階（前提 → 次に進む条件）

段中身次に進む条件根拠
0手作業で完了条件を1文・確認コマンドにする人が1回の確認で合否を判定できるClaude Code 公式 goal
1/goal をセッション内で回す（人が見ている）上限で止まる・判定の理由が残る公式 goal、HF.M
2失敗時に人へ戻す（上限回数）上限内で合否が出るClassmethod（せーの。Classmethod の試行で、サンドボックスの1ケース。公開日要確認）：3回失敗で人へ。ヘンリー：上限回数つきで作業→レビュー→修正（05-10）
3hooks で禁止操作を止め、監査ログを残す。予算ガードを入れる禁止操作が止まる・ログが残るせーの（同じ試行・1ケースで確認）
4無人化（クラウドの scheduled tasks、GitHub Actions）数日〜1〜2週の観察で誤作動が無いこと（調査担当の推測要確認）公式 routines、せーの
  • 実務者の実装順（せーの）：固定の bash ループ → /loop → /schedule（報告のみ）→ Maker-Checker → SDK hooks → 予算ガード → GitHub Actions。公式が定めた順ではない。
  • 次に進む条件（HF.M 2026-07-27 の原文の列挙・8項目）：達成したい状態／現在の状態／実行結果を確認する証拠／合格と不合格の基準／不合格時の次の行動／最大試行回数／最大費用と実行時間／人間へ戻す条件。原文：「一つのループで、正しく止まれない。証拠を残せない。前回の失敗から行動を変えられない。その状態でノードを増やしても、失敗する場所が増えるだけです。」
  • 反復の器（Claude Code の部品名で）：/goal <条件>（1セッションに1つ、/goal clear で停止）／/loop 5m <指示>（7日で失効、セッションが閉じると止まる）／外部の bash while ＋ claude -p／公式プラグイン /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<text>"（インストールコマンドは公式 README 本文で未確認要確認）／Stop hook（~/.claude/settings.json か .claude/settings.json に "Stop"）。
  • 実装で出た落とし穴（せーの。サンドボックスの1ケース・試行）：最初の bash ループは、1回目で正しく直ったのに set -euo pipefail と失敗するテスト出力のパイプで exit 1 で異常終了した（修正は出力を変数に取り || true）。テストを書き換えて偽合格させるケース（"Verifier Theater"）が起き、「テストを編集しない」を規則にした。
  • EXPLACE：段1の最初の1本は D6（検査と差し戻し2回）をそのまま使える。費用上限は未受領未決。
  • 出典（取得 2026-11-08）：https://code.claude.com/docs/en/goal ／ https://code.claude.com/docs/en/scheduled-tasks ／ https://code.claude.com/docs/en/hooks-guide ／ https://github.com/anthropics/claude-plugins-official/tree/main/plugins/ralph-loop ／ https://hfm.tokyo/blog/graph-engineering ／ https://dev.classmethod.jp/articles/claude-loop-engineering-practice/ ／ https://dev.henry.jp/entry/claude-code-orchestrator

05-9ループはAIに回させ、条件・上限・戻し先は人が持つ

評価者は会話に出た証拠だけで判定するので、証拠が出る条件文にします。

指示文AI が作る人が確かめるAI に任せてよい条件文の下書き修正と再実行判定の理由の記録人が持つ条件が会話で示せるか上限と費用テスト編集の禁止戻し先手段・原文の部品/goal の条件Stop hook の判定--max-iterations
根拠・出典・手順（折りたたみ）

公式の原文（出典つき）

部品原文
/goal の条件"all tests in test/auth pass and the lint step is clean"（公式 goal）
/goal の評価者"It does not call tools, so it can only judge what Claude has already surfaced in the conversation."（公式 goal）。評価の費用は小さい：評価は小さく速いモデルで課金される（"Evaluation tokens are billed on the small fast model…"）
Stop hook の判定 prompt"Check if all tasks are complete. If not, respond with {"ok": false, "reason": "what remains to be done"}."（公式 hooks-guide）
Ralph の上限"Always rely on --max-iterations as your primary safety mechanism."（Anthropic 公式プラグイン README）
停止条件"it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control."（Anthropic「Building effective agents」2024-12-19）

05-10国内のループは業務利用2件がそろった。効果の数字はまだ無い

件数はそろいましたが、効果は数字で未計測です。

国内株式会社ヘンリー 2026-02-17開発4ステップの自動化（Orchestrator 型 Skill）定量の記載なし（定性）導入から日が浅いと明記arufian 2026-07-17開発ワークフローの自動化（6体のサブエージェント）「デリバリー速度が約3倍」は著者の主張基準期間・件数・測り方の記載なしZOZO /tune 2026-08-25（参考・R&D）VLM プロンプトのチューニングT1 F1 0.7842→0.8641（初期値との比較）N=1・速報。本番稼働は【要確認】海外Anthropic C コンパイラ 2026-02-0516体の Claude が並行で Rust 製コンパイラを作成約2,000セッション・API費用 $20,000公式の実施記録・費用の目安にしないCursor 2026-01-14Web ブラウザを一から作る100万行超企業の実施記録・ロック方式は失敗Anthropic 研究システム 2025-06-13（古い）リード＋サブエージェントの研究単体 Opus 4 より 90.2% 優れる自社の内部評価
未発見国内で、LangGraph・Mastra・n8n・Dify を使ったループ・グラフの本番例は見つかっていません（調査 2026-11-08）。見つかった国内の例は、すべて Claude Code のスキル・サブエージェント型です。
根拠・出典・手順（折りたたみ）

国内（業務利用）

誰・日付何をどう作ったか結果（計測と主張を分ける）
株式会社ヘンリー（warabi・ソフトウェアエンジニア）2026-02-17（更新 2026-06-30）開発フローのうち4ステップ（情報収集・計画・実装・PR作成）の自動化Orchestrator 型 Skill。親の dev Skill は呼び出し順だけ管理し、各ステップは別コンテキストの SubAgent。「作業→レビュー→修正」を上限回数つきで繰り返す。実行前に人が最終確認し、完成した PR は作業者本人がレビュー定量の記載なし。「全てではないですが、修正不要でマージできるPRも結構作れている。」（定性）。課題として「実装の理解はペアプロに軍配が上がりました」と著者が書く要確認：要約経由の引用。導入から日が浅いと明記。業務（社内開発）で使用、と読める
arufian（フリーランス・技術顧問。個人の発信）2026-07-17（更新 2026-07-18）開発ワークフローの自動化（設計 → 実装 → レビュー → QA → デプロイ準備）スキル（SKILL.md）が司令役、6体のサブエージェント（designer・developer・reviewer・QA・deploy manager・org admin）。失敗したレビュー・QA は developer に差し戻し。レビュー書は「承認・差し戻しにかかわらず必ず生成する」ルール「デリバリー速度が約3倍」は著者の主張。基準期間・件数・測り方の記載なし（検証不可。出典の数字として載せるのみ）。クライアント案件で数か月かけて改良と記述。個人の発信

国内（参考・R&D）

誰・日付何をどう作ったか結果
ZOZO データサイエンス部（大川）2026-08-25VLM プロンプト（服の特徴抽出）のチューニング02-10 の表のとおり。/tune skill が analyzer・planner・improver・retrospector へ委譲。停止条件＝全 F1≥0.7・最大10イテレーション・3回連続の収束。人は実験設定（config）の確認とドメインエキスパートの定性評価T1 F1 0.7842→0.8641（初期値との比較）。人手チューニング後との比較は 0.8473→0.8641。T2 0.8481→0.9184、T3 0.8721→0.8794。チューニング1回 約6時間→約2.5時間、評価サイクル 約3.5週→約1週。N=1の速報。本文に「本番」の記述なし＝業務内の R&D。本番稼働は要確認。「N=1」「R&D」の語の本文照合も未了要確認

海外

誰・日付何をどう作ったか結果
Anthropic（Carlini）2026-02-05Rust 製の C コンパイラ16体の Claude が共有リポジトリで並行。current_tasks/ にテキストの「ロック」。テストが完了判定約2,000セッション、API費用 $20,000、約10万行（公式の実施記録。一般の費用の目安にはしない）。16bit x86 は GCC を呼ぶ・アセンブラとリンカが無い等の欠落も記載
Cursor（Wilson Lin）2026-01-14Web ブラウザを一から作る「数百の並行エージェント」。ロック方式は失敗（"Agents would hold locks for too long, or forget to release them entirely."）→ 計画担当と実装担当のパイプラインに分離100万行超（"over a million lines of code"）。企業の実施記録
Anthropic 研究システム 2025-06-13（古い）研究質問への回答（リード＋サブエージェント）リードがサブタスクに「目的・出力形式・ツールと情報源・境界」を渡す内部研究評価で単体 Opus 4 より 90.2% 優れる。トークンはチャットの約4倍（エージェント）・約15倍（マルチエージェント）＝自社の研究システムの測定で、一般法則ではない
この章の結論
ループは、完了条件・上限・別の評価者・止める人で設計する
確立した定義はない。EXPLACE の定義は案
06
GRAPH

グラフ＝工程と分岐の構造の設計

層：中身　設計・実装・具体例・よくある失敗

06-1グラフ＝工程・状態・分岐の構造

新しい考えではない。EXPLACE ではすでにある工程図が当てはまります。

一般EXPLACE 定義（案）ノード・状態・ルーティング・循環LangChain：新しい考えではない工程・担当・分岐・状態。正本＝workflows.json確立度：造語に近い
根拠・出典・手順（折りたたみ）

06-2EXPLACE の工程図は、すでにグラフ

工程・担当・分岐がすでに書かれています。

D0受付D1事前リサーチD2勝ち筋D3企画・構成G1構成の確認D4原稿D5図解・組版D6レビューD7品質確認・公開準備G2公開・送付の承認D8使って計測D9改善不合格は D4/D5 へ（2回まで、3回目は代表）次の版へ（D3〜D7）工程枠次へ省略できる工程差し戻し人の関所ノードの中身（動画の整理）目的担当作業根拠承認
根拠・出典・手順（折りたたみ）
  • workflows.json は業務 → 工程 → 担当で、各工程に入力・出力・完了条件・代表の関所がある（ai-office/README.md）。15業務（01_research）。ノードの5項目は動画の整理（NotebookLM 要約 §2）で、workflows.json の項目との差（「根拠」の有無）は要確認。1業務の図の選び方は doc-designer が workflows.json から選ぶ未決。

06-3工程は、5つの動詞で図にする

ここまでできれば OK＝全工程に担当・完了条件・次があり、1本の業務で試験済みです。

業務を1つ選び棚卸しノードと依存を決めるモデルと担当を配置人の関所と停止基準を置く実データで試験ここまでできれば OK ＝ 工程ごとに担当・完了条件・次が書いてある
根拠・出典・手順（折りたたみ）

手順（5ステップ）

  1. 棚卸し：繰り返し起きる業務を1本選び、各チームの 02_workflow.md から工程を写す（推測で作らない）。
  2. ノードとエッジ：工程ごとに担当を1つに（作る担当と検査担当は別）。依存（次の工程）と進行条件を書く。
  3. 配置：上流の企画と最終検査は上位モデル、末端の実行は安いモデル（動画の多数派。CLAUDE.md の Opus/Sonnet/Haiku の使い分けと同じ向き。最上位だけで回す立場もあり、EXPLACE の方針は未決）。
  4. 関所と停止基準：人が決める工程（G1・G2 など）と、止める条件（費用超過・根拠不足）を書く。
  5. 試験：実際のデータを通し、型を壊す試験や独立したレビューで育てる（動画の手順）。
  • 出典：ai-office/README.md、02_workflow.md、CLAUDE.md、動画7本（NotebookLM 要約 §2）。

06-4構造の正本は workflows.json。画面は正本の投影

画面で直しても、正本は workflows.json。手元で書き戻して初めて確定します。

役割部品正本workflows.json（15業務）表示AI Office（業務フロー・設計・オフィス）同期（hook）hook_sync_ai_office.sh：組織図の同期・公開。書き戻しはしない編集（公開済み）「設計」タブで画面保存 → D1 に下書き → 手元で --pull-drafts → workflows.json に書き戻し書き戻しの検証JSON・工程番号の重複・矢印の端。置き換え前に .bak
公開済みAI Office の「設計」タブは 2026-11-06 に本番公開済み。保存方法は決定済み。
任意・未設定通常の同期（hook）で毎回 pull するかは任意で、まだ設定していません。
根拠・出典・手順（折りたたみ）
  • 決定（2026-11-06・coordinator 経由）：保存方法は「画面で保存 → D1 に下書き → 手元で python3 AI_Agent/scripts/sync_ai_office.py --pull-drafts を流すと workflows.json に書き戻し」。「設計」タブは 2026-11-06 に本番公開済み（ai-office/README.md）。動画のルール「可視化画面と正解データの分離」（共通ルール案7）と同じ向き。
  • 書き戻しの仕様（README）：D1 の未反映の下書き（業務ごとに最新）を検証して workflows.json の該当業務を置き換え、通常の同期（org.json 作成）まで行う。置き換える前に workflows.json.bak を作る。JSON・工程番号・矢印の検証に失敗した業務は書かない（下書きは未反映のまま残る）。工程番号は業務の中で一意（short-video の M4 は重複しているので、直すまで保存できない）。
  • hook：既定は pull しない（フックは組織図の編集で同期・公開するだけ）。毎回先に pull するには hook_sync_ai_office.sh の呼び出しを sync_ai_office.py --pull-drafts --deploy に変えるが、手元で workflows.json を直している最中に走ると下書きで置き換わる（.bak は残る）。任意で、まだ設定していない。
  • 実在：AI_Agent/ai-office/workflows.json、公開 https://explace-ai-office.pages.dev/ 。D1＝Cloudflare の D1（explace-ai-office）。
  • 動画の部品（NotebookLM 要約 §3）：Dynamic Workflow・LangGraph・OpenAI Agents SDK（コード中心）／Anthropic の Skill Creator／紙の設計図を Codex に渡してコード化／Git 管理の YAML・JSON・DAG。EXPLACE は workflows.json（JSON）で、LangGraph を使うと決めていない。
  • 実装手順（3ステップ）：①1業務で「画面で保存 → D1 → 手元で書き戻し」を通す ②書き戻した内容が検証と同期の検査（warnings）に通るか確かめる ③通ってから他の業務に広げる。デプロイ権限は代表。

06-5D0〜D9 が、実在するグラフ

省く工程・戻る工程・人の関所が、図のままの規則です。

D0受付D1事前リサーチD2今回省略D3企画・構成G1構成の確認（G2と同時）D4原稿D5図解・組版D6レビューD7品質確認・公開準備G2公開・送付の承認D8使って計測今回対象外D9改善今回対象外不合格は D4/D5 へ（2回まで、3回目は代表）次の版へ（D3〜D7）工程枠次へ省略できる工程差し戻し人の関所
根拠・出典・手順（折りたたみ）
  • 出典：Teams/collateral/02_workflow.md。今回の run は D2 を省き、G1 を G2 と同時にした分岐の実例（00_brief.md §1）。D8・D9 は今回対象外。
  • 動画の例（EXPLACE の実績ではない）：Claude Code の「Deep Research」が複数のサブエージェントで5段階の DAG を組む（動画内の「100以上」「要件定義1→検索5→取得25→検証75→レポート1」は要確認）／書籍作成チーム（リサーチ・検証・誌面ルール・ライター・デザイン構成の分業）／LP 構築（構成案・画像生成・コーディングの並行）／開発パイプライン（Slack 要望 → 要件定義・実装 → レビュー → テスト → 合格までループ → Slack 通知）（NotebookLM 要約 §4）。

06-6グラフは造語に近い。LangGraph は一例

EXPLACE は LangGraph を使うと決めていません。

グラフ造語に近い
注LangGraph は実装の一例です。
根拠・出典・手順（折りたたみ）
  • 出典 URL は 06-1。

06-7大きすぎるグラフは、遅く・高く・不正確になる

小さく始めて、効いた業務だけ広げます。

原因結果1体で済む仕事に多段費用・時間が増え、精度が下がるノードの信頼性が低い構造だけ作っても動かない仕様の抜け漏れノード間で情報が分裂・消失エージェントを増やす動いた量（トークン）が増える対処：1本の業務で小さく試し、効いたら広げる
根拠・出典・手順（折りたたみ）
  • 出典：動画7本（NotebookLM 要約 §5）。費用は「数」ではなく動いた量で決まる（00_要点 §4）。一次の数字は Anthropic の自社データ（06-10）。

06-8グラフは、1つのループが安定してから、紙に書いて必要な所だけ分ける

ここまでできれば OK＝全工程に担当・完了条件・次があり、分ける理由を言えます。

1業務で1つのループ11目標に1エージェント2必要な分だけ分ける3次へ進む条件止まる・証拠・やり方が変わる実行過程を確かめた分けないと解けない事情がある業務をまたぐ連動は出典なし（13-3）
根拠・出典・手順（折りたたみ）

段階（前提 → 次に進む条件）

段中身次に進む条件根拠
01業務で1つのループを回す止まる・証拠が残る・失敗から行動が変わるHF.M 2026-07-27（実務者）
11つの業務目標に1エージェント（道具と接続先を渡す）実行過程を確かめた上で、必要な部分だけ分ける電通総研 AITC 2026-09-07（企業記事）
2役割・検証・承認・並列を必要な分だけ足す「異なる専門性、権限、検証、承認、並列処理が本当に必要になったとき、初めてグラフが価値を持ちます」電通総研 AITC
  • 公式の原則：単純な解を探し、必要なときだけ複雑にする＝"we recommend finding the simplest solution possible, and only increasing complexity when needed."（Anthropic「Building effective agents」2024-12-19・古い）。電通総研：一つの明確な仕事なら、よく設計された一つのループの方が安く速く理解しやすい（企業の見解・費用の実測ではない）。
  • 公式の注意（2025-06-13・古い）：エージェント同士で同じ文脈を共有する仕事や依存の多い仕事は、マルチエージェントに向かない。コード開発への適用は慎重に（Anthropic multi-agent）。
  • 「グラフはループを置き換えず、つなぎ、統制する」：「つまり、グラフはループを置き換えるのではなく、複数のループをつなぎ、統制します。」（HF.M）。グラフが向く仕事：LangChain 原文は "Real-world agent workflows often have predictable structure"（2026-07-22）。
  • Claude Code の部品名で：コードを書く前に、ノード（エージェント・ツール・人の承認）と接続（条件）を紙に書く（HF.M：「ループが安定したら、コードを書く前に次のテンプレートを紙に書き出します」）。役割は .claude/agents/<名前>.md（frontmatter＝name・description・tools・model）に置く。各サブエージェントは独自のコンテキストで動き、要約だけ返す。コードで組むなら LangGraph（state を決め、add_node・add_edge で START・END をつなぎ compile()。インストール・条件分岐・中断再開の API は未取得要確認）か Agent SDK（API 名は未取得要確認）。
  • EXPLACE：すでに workflows.json が正本で、D0〜D9 が実在のグラフ（06-5）。新しい業務は 06-4 の流れ（設計タブ → D1 → --pull-drafts）で足す。LangGraph を使うとは決めていない。国内の実例は Claude Code のスキル・サブエージェント型（06-10）。
  • 出典（取得 2026-11-08）：https://hfm.tokyo/blog/graph-engineering ／ https://aitc.dentsusoken.com/column/ai-agent-loop-and-graph-engineering/ ／ https://www.anthropic.com/research/building-effective-agents ／ https://www.anthropic.com/engineering/multi-agent-research-system ／ https://www.langchain.com/blog/3-years-of-graph-engineering-with-langgraph ／ https://code.claude.com/docs/en/sub-agents ／ https://docs.langchain.com/oss/python/langgraph/overview

06-9工程の定義ファイルはAIに下書きさせ、分け方の判断は人が持つ

サブエージェントへの依頼は、4点がなければ作業が重なり、すき間が残ります。

指示文AI が作る人が確かめるAI に任せてよい工程の棚卸しの下書きagent 定義の下書き依頼文の下書き人が持つ共有状態の衝突役割の重なり停止条件人の関所手段・原文の部品目的出力形式ツールと情報源境界
根拠・出典・手順（折りたたみ）
  • 公式の原文：サブエージェントの依頼に必要な4点＝"Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries."（Anthropic multi-agent 2025-06-13・古い）。詳細が無いと作業が重複し、すき間が残ったと報告している。
  • 停止条件の原文："it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control."（Anthropic 2024-12-19）。
  • 役割分担の実例（Cursor）：ロック方式は失敗し、計画担当と実装担当の2つのパイプラインに分けた（06-10）。国内の実例（ヘンリー）：情報収集・設計の結果はフォルダにファイル保存し、親には完了のみ伝達（06-10）。
  • Claude Code では /agents で Claude に作らせるか、ファイルを手で作る（公式 sub-agents）。
  • EXPLACE 用の指示文の例（案・未試行）：「workflows.json の業務『（業務名）』の工程を1つずつ読み、各工程を担当する agent の定義ファイルの下書きを作って。各依頼文には、目的・出力形式・使うツールと情報源・境界の4点を入れて。省く工程・戻る工程・代表の関所は書き換えないで。同じファイルを2つの担当が書き換える所があれば一覧にして。」
  • 人が確認する点：①共有状態の衝突（ロックの失敗）②役割の重なり ③停止条件。
  • 要確認動画が挙げる「Skill Creator」で工程を自動構築する方法は、公式の存在を未確認。
  • 出典（取得 2026-11-08）：https://www.anthropic.com/engineering/multi-agent-research-system ／ https://www.anthropic.com/research/building-effective-agents ／ https://cursor.com/blog/scaling-agents ／ https://code.claude.com/docs/en/sub-agents ／ https://dev.henry.jp/entry/claude-code-orchestrator

06-10国内のグラフは2件がそろった。効果の数字は1回の実行だけ

件数はそろいましたが、効果は数字で未計測です。

国内株式会社ヘンリー 2026-02-17親＋4ステップの Orchestrator 型 Skill定量の記載なし（定性）導入から日が浅いと明記GMO 次世代ベトナム研究室 2026-04-062層・8ステップの並列実装8画面の実装が約30分、5つの PR を自動作成1回の実行・比較対象と試行回数の記載なしHF.M・電通総研・JodyCraft（設計記事）設計の考え方実装の数値は無い海外Anthropic 研究システム 2025-06-13（古い）リードがサブエージェントに分担単体 Opus 4 より 90.2% 優れる約15倍のトークン（自社データ・一般法則ではない）Cursor 2026-01-14役割を分けたパイプラインへ100万行超企業の実施記録Anthropic C コンパイラ 2026-02-0516体の並行約2,000セッション・$20,000公式の実施記録・費用の目安にしない
未発見国内で、LangGraph・Mastra・n8n・Dify の本番・業務利用の例は見つかっていません（調査 2026-11-08）。国内の例は Claude Code のサブエージェント型です。
根拠・出典・手順（折りたたみ）

国内（業務利用）

誰・日付何をどう作ったか結果（計測と主張を分ける）
株式会社ヘンリー（warabi）2026-02-17（更新 2026-06-30）開発フロー4ステップ（情報収集・計画・実装・PR作成）の自動化Orchestrator 型 Skill。親の dev Skill は呼び出し順だけ管理し、各ステップは別コンテキストの SubAgent。情報収集・設計の結果はフォルダにファイル保存し、親には完了のみ伝達。実行前に人が最終確認定量の記載なし。「全てではないですが、修正不要でマージできるPRも結構作れている。」（定性）。「実装の理解はペアプロに軍配が上がりました」と著者が書く要確認：要約経由の引用。導入から日が浅いと明記。業務（社内開発）で使用、と読める
GMOインターネットグループ グループ研究開発本部 次世代ベトナム研究室（K.X.D）2026-04-06大きな機能実装の並列自動化（8ステップ：要件整理・Researcher・Planner・Code Agent・Tester・Code Reviewer・Docs Manager・Git Agent）上層の Agent Teams（タスク分割と依存管理、テンプレート5種）＋下層の Sub Agents（implement-orchestrator）。各ステップに人の承認ゲート。ファイル所有権を分けて並列実装「8画面の実装が並行処理で約30分で完了し、5つのプルリクエストが全自動で作成されました。」（1回の実行・比較対象と試行回数の記載なし）。「implement-orchestrator は日常の開発で最も使用頻度が高いテンプレートです」と記述。8ステップ全体の運用は未明記。業務（社内開発）で使用、と読める
  • 国内の設計記事（HF.M 2026-07-27、電通総研 AITC 2026-09-07、JodyCraft 2026-07-18）は設計の考え方で、実装の数値は無い。

海外

誰・日付何をどう作ったか結果
Anthropic 研究システム 2025-06-13（古い）研究質問への回答リードエージェントがサブエージェントに分担内部研究評価で単体 Opus 4 より 90.2% 優れる。約15倍のトークン（自社データ）
Cursor（Wilson Lin）2026-01-14Web ブラウザの自律開発全員が何でもやる平らな構造をやめ、役割を分けたパイプライン（"a pipeline with distinct responsibilities"）にした100万行超。ロック方式は失敗して分離へ。企業の実施記録
Anthropic C コンパイラ 2026-02-0516体の並行共有リポジトリ・ロックファイル・テストで完了判定約2,000セッション・$20,000（公式の実施記録）。新機能が既存を壊す等の欠落も記載
この章の結論
EXPLACE の工程図は、すでにグラフ
用語は造語に近い。構造の正本は workflows.json
07
COMBINE

課題で使い分け、重ねて使う

層：芯　重心は使い分け・組み合わせ

07-1困りごとの種類で、使うエンジニアリングが決まる

困りごとの症状から、最初に見る場所を決めます。

困りごと最初に見る場所出力の形が揃わないプロンプト読み違い・迷子コンテキスト同じミスが続く・事故が怖いハーネス途中で止まる・やり直しが要るループ担当や分岐が多いグラフ
結論
困りごとから引く
症状は1つとは限らない。そのときは内側から見る（07-2）
根拠・出典・手順（折りたたみ）
  • 対応表は EXPLACE の整理案・代表承認。症状は1つとは限らない。動画の「よくある失敗」（02〜06章の x-7）と対応している。作り方は 02〜06章の x-8（人が実装する手順）、順番は 13章。

07-21つの run の中に、5つが全部入っている

資料作成チームで、5つが重なって動いています。

ハーネスCLAUDE.md・rules/・hooks・G1/G2グラフD0〜D9ノードノード依存依存ノード（D6）ループ＝D6 の差し戻し2回まで実行検証改善プロンプトagent の指示コンテキストruns/ のファイルAgent ＝ Model ＋ Harness
根拠・出典・手順（折りたたみ）
  • 出典：Teams/collateral/02_workflow.md、00_brief.md。対応づけは本書の整理案。

07-3組み合わせると、ぶつかる所がある

効く所と代償をセットで置きます。

効く所代償情報を増やす⇔迷い・コスト上限なしで回す⇔止まらない・費用グラフを大きくする⇔遅さ・費用・精度
根拠・出典・手順（折りたたみ）
  • 根拠：コンテキストは「最適な集合を選ぶ」ことが目的（Anthropic 2025-09-29）。ループは上限が必要、グラフは大きくしすぎない（動画7本。NotebookLM 要約 §5）。v1 にあった「ハーネスが重いと速さが落ちる」は一次情報を取れず外した要確認。各トレードオフの程度（数値）は書かない。
13
ORDER

実装の順番と、AIに任せるときの落とし穴

層：芯　土台から順に、1業務ずつ確かめる。AIの報告を信じない仕組みで防ぐ

13-1順番を間違えて作り直さずに済む、根拠のある並び

古いものを先に、単純なものを先に。複雑にするのは必要になってからです。

成功基準・評価セット1CLAUDE.md2hooks（確実に実行）31つのループ4グラフ（1業務の中）5業務をまたぐ連動6根拠公式＋整理公式公式実務者実務者1件出典なし横に：skills（きっかけで足す）。段の間の矢印は「前提」
出典なし代表の仮説は2つとも、そのままでは根拠が見つかっていません（13-2・13-3）。
根拠・出典・手順（折りたたみ）

根拠のある順番（出典・日付つき）

段根拠種別
単純から始め、必要なときだけ複雑に"we recommend finding the simplest solution possible, and only increasing complexity when needed."（Anthropic 2024-12-19・古い）公式
CLAUDE.md を最初に置き、他の拡張は「きっかけ」で足すClaude Code 公式 features-overview（調査担当の要約。取得 2026-11-08）公式
プロンプトの改善は、成功基準・評価・初版のあとAnthropic 公式 develop-tests（成功基準は "F1 score of at least 0.85" のように数値で）。評価セットを先に持つ点は調査担当の整理公式＋整理
守らせたいことは hooks。CLAUDE.md と skills は依頼公式："Put guardrails in hooks."公式
ルール → 仕組み（フック・CI・lint・テスト）→ 観測・改善WEEL 2026-08-10（3段）実務者
グラフの前に、まず1つのループを安定させるHF.M 2026-07-27：「グラフを始める前に、まず一つのループを安定させます。」実務者
Prompt → Context → Harness → Loop → Graph の順の積み上げJodyCraft 2026-07-18（個人・Zenn・1件の実務者記事の整理。動画の整理との一致は未検証）実務者1件

13-2skills を先に整える順は、根拠がまだない（代表の仮説）

公式に skills 先行の記述はなく、実務者の WEEL は3段で、hooks などを第2段、skills を第3段「ルールやスキルへ」の一部に置いています。

根拠のある並びCLAUDE.md が最初（公式）hooks＝確実に実行／skills＝依頼（公式）WEEL：第2段 hooks など → 第3段ルール・スキルへ代表の仮説・出典なしskills→ ハーネス
出典なし「skills をハーネスの前に整える」は、公式にも実務者にも出典が見つかっていません。12章 #10 で代表が決めます。
根拠・出典・手順（折りたたみ）
  • 公式：features-overview は CLAUDE.md を最初に置き、以降は「きっかけ」で足す。ガードレールは hooks に置く（"Put guardrails in hooks."）。skills の きっかけ＝同じ手順を3回目に貼り付けるとき。hooks と skills の前後関係は公式に書かれていない要確認。「skills はハーネスの一部か」も公式に定義がない。
  • 実務者：WEEL（2026-08-10）は第2段で「制約と検証を仕組みに埋め込む（フック・CI・lint・テスト）」、第3段で「頻発する修正はルールやスキルへ」と書き、hooks が skills より前。skills を独立した段にはしていない。
  • 解釈（調査担当の推測）：Hashimoto の定義（失敗 → 仕組み）に当てはめると、skills も「仕組みの一つ」にはなりうる。ただし順序の根拠にはならない。
  • 判定：「skills はハーネスの前」は出典なし＝代表の仮説。この資料では未決として残す（12章 #10）。
  • 出典：Claude Code 公式 features-overview・skills（https://code.claude.com/docs/en/features-overview ／ https://code.claude.com/docs/en/skills ）、WEEL（https://weel.co.jp/media/harness-engineering/ ）。取得 2026-11-08。

13-3まず1つのループを安定させる前半は支持。業務をまたぐ連動は出典なし

1業務の中で複数ループをつなぐ例はありますが、業務をまたぐ連動の記述は見つかっていません。

まず1つのループを安定実務者 HF.M電通総研（注記つき）公式は一般原則のみその後に業務をまたいで連動出典なし
出典なし業務をまたぐ連動は、記述が見つかっていません。12章 #11 で代表が判断します。
根拠・出典・手順（折りたたみ）
  • 前半の支持：HF.M（2026-07-27・実務者）「グラフを始める前に、まず一つのループを安定させます。」電通総研 AITC（2026-09-07・企業記事）「まずは一つの業務目標を決め…」（1エージェントの話で、ループ安定の根拠としては弱い）。Anthropic 2024-12-19 は一般原則のみ（公式）。
  • 後半：HF.M の例は「1業務の中で複数のループをつなぐ」（調査・執筆・検証）。電通総研は「グラフはループの上位互換ではない」と書くのみ。国内の実装例（ヘンリー・GMO。06-10）も1つの開発フローの中の多段で、業務間の連動の記述は見つかっていない。業務間の連動＝出典なし・代表の仮説。
  • 注意：Anthropic multi-agent（2025-06-13・古い）は、依存の多い仕事はマルチエージェントに向かないと書く。
  • 判定：前半は実務者2件が支持（公式は一般原則）。後半は未決（12章 #11）。
  • 出典（取得 2026-11-08）：https://hfm.tokyo/blog/graph-engineering ／ https://aitc.dentsusoken.com/column/ai-agent-loop-and-graph-engineering/ ／ https://www.anthropic.com/engineering/multi-agent-research-system

13-4EXPLACE は、4段階で、1業務ずつ確かめながら進める（案）

各段の完了条件を満たしたら、次へ進みます。満たさなければ、その段に戻ります。

段階1 土台1段階2 環境2段階3 1つのループ3段階4 1業務のグラフ4完了条件CLAUDE.md 200行未満・読込確認・成功基準1文hook 1本で Blocked を確認・失敗時の挙動も確認上限で止まる・証拠が残る・やり方が変わる・費用の上限が決まっている（12-2 #6・回答待ち）全工程に担当・完了条件・次があり、1業務で試験済み段階4の右：業務をまたぐ連動（出典なし・代表が判断）段階2の脇：skills は3回目の貼り付けで
案この順番は「案」です。skills と hooks の先後、業務をまたぐ連動は代表が決めます（12章 #10・#11）。
根拠・出典・手順（折りたたみ）

各段の中身（案）

段階やること（Claude Code の部品名で）完了条件（ここまでできれば次）根拠・参照
1 土台CLAUDE.md を整理（200行未満）／検証コマンドを1行で／/context all で読込を確認／1つの業務の成功基準を数値の1文に／評価に使う出力の置き場を決める公式の目安（200行未満）を満たし、読み込みを確認した。成功基準が1文で書けた03-8・02-8。EXPLACE の現在の行数は未確認要確認
2 環境失敗を3種に分け、自動で止めたいものを1つ選び、.claude/hooks/ に1本作る。/hooks で確認。依頼して Blocked を確認。失敗時の挙動と迂回（Write → Bash）も試す。同じ手順を3回貼ったら skill へBlocked を試して確認できた。失敗・timeout のとき進むか止まるかを確認した。.claude/settings.json の変更は代表が確認した04-8・13-5
3 1つのループD6 など1業務の完了条件を1文に。/goal か Stop hook で回す。上限（回数・費用）と止める人を置く。別の評価者を使う上限で止まる。判定の理由が残る。失敗のあとにやり方が変わる（HF.M の3点）。費用の上限が決まっている（12章 #6・代表の回答待ち。現状は未受領）05-8・09-3。国内の業務利用の例＝05-10（ヘンリー・arufian）
4 1業務のグラフ紙に書く → workflows.json の1業務 → 「設計」タブ → --pull-drafts → 実データで試験。分ける理由があるところだけ分ける全工程に担当・完了条件・次が書いてあり、1業務で試験済み06-8・06-4。国内の例＝06-10（ヘンリー・GMO）
  • 許容できる損失＝1業務の試行（調査依頼の前提。期間の1〜2週は代表の発言と社内現状からの整理で要確認）。各段の所要時間は出典がなく、書かない未決。
  • 段階4のあと：業務をまたいで連動させるかは出典がなく、代表の判断（12章 #11）。
  • 柱（10章）との対応：段階1＝柱①②の一部、段階3＝柱③、段階4＝柱⑤と重なる。対応は案で、柱の順番は 12章 #4。

13-5AIに作らせるときの落とし穴は6つ。防ぐ仕組みを先に置く

防ぐのは AI を疑うからではなく、確かめる手順を先に置くためです。

落とし穴防ぎ方完了の虚偽申告別の評価者・テスト編集の禁止hook の迂回権限の deny と別の検査hook が止めないonFailure: blockStop hook の無限ループstop_hook_active の確認費用超過上限の明記（max-iterations 等）外部 skill の混入中身を読んでから入れる（案）
根拠・出典・手順（折りたたみ）
落とし穴根拠（出典・日付・注記）防ぎ方
完了の虚偽申告Anthropic long-running（2025-11-26）：機能一覧は "passing" のみ変更可、テスト後に1機能ずつ。せーの：テストを書き換えて偽合格（"Verifier Theater"）。/goal の評価者は "does not call tools"（公式）完了は別の評価者とテスト結果で判定。検査基準・テストを編集しない規則。証拠が会話に出る完了条件（05-9）
hook の迂回Classmethod（公開日要確認）：Write を block すると Claude が Bash に切り替えた（1回の実ログ・一般化しない）。公式 permissions：deny/ask は "isn't a security boundary around the program"、任意のサブプロセスには効かないhooks だけに頼らず、権限の deny と別の検査担当を重ねる。OS 側の制限は未調査要確認
hook が止めない公式 hooks-guide：失敗は既定で進む（"non-blocking error and lets the action continue"）。onFailure: "block" で止められる。Windows の Git Bash 未検出時は失敗した hook が止める例あり落ちたら止めたい hook は onFailure: "block"。試験で失敗時の挙動を確認（04-8）
Stop hook の無限ループ公式 hooks-guide：同じ停止を8回連続で block すると上書きされる。Classmethod：stop_hook_active の判断で永久ループを防げる（公開日要確認）スクリプト冒頭で stop_hook_active を見て即終了。判定は ok/reason の JSON（05-9）
費用超過Anthropic 研究システム（2025-06-13・自社データ）：エージェントはチャットの約4倍、マルチエージェントは約15倍。C コンパイラ $20,000（公式の実施記録・目安にしない）。Ralph の --max-iterations＝主たる安全装置（公式プラグイン README）完了条件・回数・費用の上限を先に書く（12章 #6）。SDK の回数・費用オプションの名前は公式ページで未照合要確認
外部 skill の混入公式 features-overview：description が曖昧・重複すると誤った skill を読む／見逃す。外部 skill・hook を入れるときの公式の注意文は未照合要確認入れる前に人が中身を読む（EXPLACE の案）。description の重なりを確認。承認は 12章 #12

13-6防ぎ方は、文・hook・権限・検査・関所のどれかに置く

04-3 の「仕組みを選ぶ」と同じ分け方で、置き場所を決めます。

置き場該当する落とし穴書いて守らせるCLAUDE.md・rules/　該当：虚偽申告（規則）自動で止めるhooks　該当：止めない・無限ループできる範囲を絞る権限（deny）　該当：迂回別の目で見る検査担当　該当：虚偽申告・迂回人が決める人の関所（承認・最終責任者）　該当：費用・外部 skill
案割り当ては EXPLACE の整理です。
根拠・出典・手順（折りたたみ）
  • 割り当ては EXPLACE の整理案。根拠：04-3（失敗の性質で置き場を選ぶ）、公式の区別（hooks＝確実に実行、CLAUDE.md・skills＝依頼）。
  • 「人の関所を外す」も落とし穴（WEEL：危険な変更や誤った判断がそのまま通る。日本語原文の要旨）。承認点と最終責任者を先に決める。
  • 共通ルール10項目（10-7）との対応：3 人の関所／8 小さく始めて別の担当が検査／9 止める条件。12章 #12 は、この防ぎ方を共通ルールに足してよいかを問う。
この章の結論
古いものを先に、単純なものを先に。複雑にするのは必要になってから
代表の仮説2つは出典なし（黄）。AIに任せるときは、報告を信じない仕組みを先に置く
08
DESIGN

EXPLACE に当てはめた全体設計

層：中身　指揮・Slack・AI Office・Hermes は保留

08-1代表の指示は、既存の仕組みで部署に降りる

指揮は people-director・AI Office・daily-guide の Slack で動かします。

代表people-director既存の部署に振る・チームを足す資料作成発信daily-guideエージェントSlack（#explace-daily-guide）AI OfficeHermes Agent は保留（08-4）
決定済みHermes Agent は保留（2026-11-06 代表判断）。指揮は既存の仕組みで。
根拠・出典・手順（折りたたみ）
  • 決定：2026-11-06 代表判断（coordinator 経由）。部署例は実在の部品（資料作成チーム・daily-guide）と、発信（X運用の Slack アプリが daily-guide と共用）に基づく。org-chart の正本は AI_Agent/org-chart.md（ai-office README）。部署の追加はこの資料では決めない。people-director は代表の指示を受けて既存部署に振る・チームを足す・部署を立ち上げるを決める（.claude/agents/people-director.md）。

08-2Slack ch は、部署・プロジェクトごとに1つ

ch の一覧と命名は未受領。空欄のまま残します。

部署／プロジェクトSlack ch資料作成ch 未定発信ch 未定daily-guide#explace-daily-guideほかの部署・プロジェクトch 未定
根拠・出典・手順（折りたたみ）
  • 出典：daily-guide/README.md（#explace-daily-guide、非公開）。Slack ch の一覧と命名未決・要確認。

08-3AI Office は、見る場所から、設定する場所へ

「設計」タブが公開済み。ノード操作で業務フローを編集して保存できます。

AI Office のタブ（実在・6つ）全体業務フロー設計オフィス指示変更履歴公開済み（2026-11-06）画面で保存 → D1 に下書き → 手元で --pull-drafts → workflows.json に書き戻し書き戻しの前に検証（JSON・工程番号の重複・矢印の端）、置き換え前に .bak。組織図編集時の自動同期（hook）は書き戻さない
公開済み「設計」タブ（2026-11-06）。書き戻しは手元の --pull-drafts。
根拠・出典・手順（折りたたみ）
  • 出典：ai-office/README.md。画面のタブは 全体／業務フロー／設計／オフィス／指示／変更履歴 の6つ。README に「足す」タブは 2026-11-01 代表の方針で外したとあるが、設計タブはそれとは別物と README に明記されている。保存方法は決定済み（06-4）。

08-4Hermes Agent は保留。指揮は既存の仕組みで

売上に効く成果が数字で見えるまで、新しい指揮役は入れません。

決定：保留（2026-11-06 代表判断）いまの指揮（既存）people-directorAI Officedaily-guide の Slack再検討の条件①社外から Slack で部署を指揮したい場面が実際に出る②1本の業務で売上に効く成果が数字で見える
決定済み保留（2026-11-06 代表判断）。再検討の条件は2つ。
根拠・出典・手順（折りたたみ）
  • 決定の根拠：代表判断 2026-11-06（coordinator 経由の伝達）。再検討の条件は①社外から Slack で部署を指揮したい場面が実際に出る ②1本の業務で売上に効く成果が数字で見える（hermes_接続検証.md の「決定」の順）。
  • 保留の対象：Nous Research 製 OSS（MIT）。Telegram/Discord/Slack/WhatsApp/Signal/Email/CLI、自然言語 cron＋配信先指定、スキル自律作成（agentskills.io 形式）、メモリ（FTS5・Honcho）、サブエージェント並列。モデルは Nous Portal・OpenRouter・OpenAI・カスタムエンドポイント。Claude API 直接対応は明記なし（OpenRouter 経由は未検証）。出典：https://github.com/NousResearch/hermes-agent （取得日 2026-11-06）。
  • 再検討するときの確認項目（01_research から）：Claude 接続、49体の agents・hooks・workflows.json との接続、導入の権限・接続先、費用要確認。
  • 既存側の未確認：Slack から Claude Code を動かす経路は未構築。候補＝Agent SDK（https://code.claude.com/docs/en/agent-sdk/overview ）／Cloud routines／Claude Tag。Claude in Slack の旧版は 2026-10-05 退役、Team/Enterprise は Claude Tag へ。プランの確認要確認（https://code.claude.com/docs/en/slack ）。
この章の結論
指揮は既存の仕組みで。Hermes Agent は保留
再検討の条件は2つ（①社外から Slack で指揮したい場面が出る／②売上に効く成果が数字で見える）
09
PDCA

分・時間・日の3つのループ

層：中身　速さごとに、回す人と代表の関所を分ける

09-1速いほど自動、遅いほど代表が決める

3つの速さで回し、代表が決めるのは遅い層です。

日時間分日：代表の関所代表＋team-pdca＋daily-guide時間people-director＋部署リード分作る担当と別の検査担当分 ＜ 時間 ＜ 日
根拠・出典・手順（折りたたみ）
  • 既存の PDCA は team-pdca（CLAUDE.md）。「分・時間・日」の分け方は今回の依頼文の設計案。動画の考え方：平常時は人が監督（Human-on-the-Loop）、費用・外部送信・公開・権限変更で承認（Human-in-the-Loop）（NotebookLM 要約 §6）。

09-23つのループは、回す人と見るものが違う

回す人が違えば、見るものも決める所も違います。

ループ誰が回す何を見る代表が決める所分作る担当と別の検査担当1つの出力が合格ライン決めない（上限だけ事前に）未決：上限時間people-director＋部署リード進み・差し戻し回数・止まり指示を変えるか未決：報告の頻度・形式日代表＋team-pdca＋daily-guide成果指標・工数・ルール追記ルール・優先順・部署の増減
根拠・出典・手順（折りたたみ）
  • 実在の部品との対応：分＝D6 の合否と差し戻し2回、hooks／時間＝AI Office（稼働・止まった？）と Slack、日＝team-pdca・daily-guide（毎日の cron と ✅）・/kosu。
  • 案：分の上限未決、時間の報告頻度・形式未決。人が回す役の people-director は 08-1 の決定による。
  • 設計手順（3ステップ）：①ループごとに「対象・見る指標・止める人」を1行ずつ書く ②分ループは hook か検査に載せる（自己採点で合格にしない） ③時間・日は Slack への報告と代表の返信で閉じる。
  • 最初に回す1本：売上に効く指標（段0：相談数）に紐づく1本の業務から始め、効いた業務だけ広げる（00_要点 §4、共通ルール案8）。どの業務かは代表が答える項目（12章）。

09-3上限（回数・費用）を決めて、はじめて自動にできる

数字を入れるのは代表です。入れるまで、自動にはしません。

回数費用分（空欄）（空欄）時間（空欄）（空欄）日（空欄）（空欄）
未決費用上限は未受領です。
根拠・出典・手順（折りたたみ）
  • 費用・回数の値は書かない（出典なし）未決：月の費用上限。費用はエージェントの数ではなく動いた量（トークン）で出る。ループとグラフは量を増やす側（00_要点 §4）。一次の数字は Anthropic の自社データ（エージェントはチャットの約4倍、マルチエージェントは約15倍。2025-06-13・古い。一般法則ではない）。動画の主張は一次情報で未確認要確認。
この章の結論
速いほど自動、遅いほど代表が決める
上限の数字が入るまで、自動にはしない
10
SETUP

5本柱をどの順で立ち上げるか

層：中身　柱ごとに、やること・完了条件・必要なもの・未決

10-1柱①は終わった。次は共通ルールの承認と構造設計

順番は案です。代表が決めます。

Phase 1① 知識をルール化（ルール案まで完了）② 構造設計Phase 2③ 自動 PDCAPhase 3④ 指揮系（既存で指揮）⑤ AI Office（設計タブ 公開済み）①→②→③④は既存の指揮のまま⑤は②の構造に依存③と④の順は代表が決める
根拠・出典・手順（折りたたみ）
  • 依存（案）：①→②→③、⑤は②の構造に依存。④は Hermes 保留（08-4）のため既存の指揮のまま。5つのエンジニアリングそのものの実装の順番（段階1〜4）は 13章。柱との対応は 13-4。

10-2柱①：動画7本から、共通ルール案10項目ができた

ルール案までは完了。CLAUDE.md に入れるかは代表が決めます。

やること・NotebookLM で分析（済）・型にする（済）・承認後に CLAUDE.md へ完了条件・共通ルール10項目が CLAUDE.md にあり、各部署が参照している必要なもの・00_要点とルール案.md・代表の承認未決・承認・動画7本の URL
根拠・出典・手順（折りたたみ）
  • 結果：Teams/orchestrator/engineering_kb/00_要点とルール案.md（要点・EXPLACE との対応表・共通ルール案10項目）と notebooklm_raw_2026-11-06.md（全文）。手順の正本：Knowledge/CLAUDE.md（/knowledge）。NotebookLM の要約は誤る前提で、数字は要確認のまま。各動画の URL は要確認（代表の手元の URL を足す）。

10-3柱②：部署ごとに、使う型の表をつくる

07-1 の表を、部署ごとに埋めていきます。

やること・タスク・成果物・目的・部署・Slack ch ごとに5つの使い分けを表にする・解像度16項目に当てる完了条件・部署ごとに使う型の表。Slack ch と部署が1対1必要なもの・resolution-standard.md・部署の定義・Slack ch 一覧未決・Slack ch の一覧と命名
根拠・出典・手順（折りたたみ）
  • 出典：AI_Agent/Workflows/team-pdca/resolution-standard.md（CLAUDE.md の記載）。Slack ch 一覧と命名未決・未受領。

10-4柱③：最初の1本の業務に、分・時間・日のループを置く

相談数に効く1本から始め、効いたら広げます。

やること・最初の1業務を決める・上限を置く・役割別の出力形式を定める完了条件・その1業務に「対象・上限・止める人」が書かれ、試運転で1周必要なもの・team-pdca・hooks・rubric未決・最初の1業務（相談数に効く業務）・上限（費用・回数）
根拠・出典・手順（折りたたみ）
  • 09章の表が元。最初の1業務と上限は代表が答える項目（12章）。ループの実装手順は 05-8、段階は 13-4 の段階3。

10-5柱④：既存の仕組みで指揮する。Hermes は条件付きで再検討

新しい指揮役は入れず、既存の1往復を確かめます。

やること・people-director・AI Office・daily-guide の Slack で指揮・Slack の報告の頻度・形式を決める完了条件・Slack で報告が届き、代表の1返信で部署が動く（1部署で確認）必要なもの・Slack アプリ・people-director未決・報告の頻度・形式・Hermes 再検討の条件①（社外から Slack で指揮）
根拠・出典・手順（折りたたみ）
  • 実在：daily-guide の Slack アプリ（X運用と共用。権限 chat:write・reactions:read・groups:history）。決定の根拠は 08-4。「代表の1返信で部署が動く」は現状 daily-guide が返信をキーワードまでしか処理しない（daily-guide/README.md）ため、経路は作る（案）要確認。

10-6柱⑤：AI Office の「設計」タブで、ノード操作によりワークフローを設定する（公開済み）

「設計」タブは公開済み。残るのは、手元で書き戻して1業務で確かめることです。

やること・「設計」タブを作る（済）・画面で保存 → D1 に下書き（済）・手元で --pull-drafts を流し、workflows.json に書き戻す完了条件・ノード編集が保存され、書き戻されて、業務フローのタブに反映（1業務で確認）必要なもの・AI_Agent/ai-office/・workflows.json・sync_ai_office.py --pull-drafts決定済み・「設計」タブは 2026-11-06 に本番公開済み・保存方法は決定済み
公開済み設計タブは 2026-11-06 に本番公開済み。正本は workflows.json。
根拠・出典・手順（折りたたみ）
  • 「設計」タブは 2026-11-06 に本番公開済み（ai-office/README.md）。この資料では追加の実装はしない。書き戻しは python3 AI_Agent/scripts/sync_ai_office.py --pull-drafts（検証・.bak つき）。公開は --deploy。正本は workflows.json（画面は投影）。hook に載せるかは任意で、まだ設定していない。

10-7全部署共通ルール10項目を、CLAUDE.md に入れてよいか

動画7本の8項目を EXPLACE の言葉に置き換えた10項目です。

分ける1 役割と権限3 人の関所つなぐ2 目的から承認まで1本4 ルール先読み5 省略の明示残す・戻す6 履歴と根拠7 画面は正本から小さく・止める8 小さく始める9 止める条件10 グラフを大きくしない代表の承認 → CLAUDE.md
未決未決（埋めずに残しています）
代表の承認 → CLAUDE.md未決10 のモデル配置は動画の多数派の意見で、EXPLACE の方針は未決
根拠・出典・手順（折りたたみ）
  • 案の全文（00_要点とルール案.md §3）：
  • 1. 役割と権限を分ける。担当ごとに「やってよいこと／いけないこと」を職務定義に書く。
  • 2. 目的・担当・作業・根拠・承認を1本でつなぐ。作業票に「なぜ・誰が・何を・何を根拠に・誰が承認」を書く。
  • 3. 人の関所を4つの境界に置く（費用が出る／外へ送る／公開する／権限を変える）。平常時は監督だけ。
  • 4. ルールと承認条件を先に読ませる。
  • 5. 省いた情報は「何を何件省いたか」を書いて渡す。
  • 6. 履歴と根拠を残し、戻れるようにする（runs/<id>/ を全チームに）。
  • 7. 画面は正本から作る。画面で直したら正本に書き戻す。
  • 8. 小さく始めて試験する。作った担当と別の担当が検査する。
  • 9. ループには必ず止める条件（完了条件・最大回数・費用の上限）。自己採点で合格にしない。
  • 10. グラフを大きくしすぎない。上流と最終検査は上位モデル、末端は安いモデル（動画の多数派の意見。EXPLACE の方針は未決）。
  • 代表の承認後に CLAUDE.md へ入れる。置き場は CLAUDE.md の案（全部署共通の場所）。ルール6（runs/ を全チームに）は今の運用の拡大で、適用範囲は承認時に確認要確認。
  • 13-5 の落とし穴の防ぎ方（AIの完了報告を信じない・hook の迂回・外部 skill の確認など）を足すかは 12章 #12。
この章の結論
柱①は終わった。次は共通ルールの承認と構造設計
順番は案。③と④の順は代表が決める
11
LEARN

経営・実装・学習の3列で必要項目を洗う

層：中身　あるものと足りないものを、3方向で分ける

11-1経営・実装・学習の3列で、あるものと足りないものを分ける

足りない所だけが、次の作業になります。

列ある（緑）足りない（黄）経営する・今回の資料・rubric・team-pdca・AI Office の稼働・変更履歴・各部署の metrics・3ループの成果指標の置き方・費用上限の考え方実装する・Anthropic 公式3本・Claude Code 公式6本・Hermes の GitHub・LangChain・Huntley・Hashimoto・動画7本の要約・OpenAI 原典（取得不可）・/goal の公式確認・動画内の数字の一次確認・Slack プランエージェントに学習させる・CLAUDE.md・rules/・Knowledge/3_型・/knowledge の手順・共通ルール案10項目・ルール10項目の承認・動画7本の URL
根拠・出典・手順（折りたたみ）

11-2足りない項目は、代表に答える12項目と、調べる9項目

代表の返答は12項目。残りは調べる項目で、こちらで進めます。

代表に答える（12）1EXPLACE 定義5つの承認2共通ルール10項目を CLAUDE.md に入れてよいか3最初に自動 PDCA を回す1業務4柱の順番5Slack ch の一覧と命名6自動 PDCA の上限（費用・回数）7報告の頻度・形式8動画7本の URL9代表のペルソナ段10実装の順番（段階1〜4）11業務をまたぐ連動を置くか12AI実装時の防ぎ方を共通ルールに足すか調べる（9）1OpenAI 原典2Slack プラン（Claude Tag）3動画内の数字の一次確認4Ralph loop の命名者5Cloud routines の制約6Hermes 再検討の条件①（社外から Slack で指揮）7Agent SDK の回数・費用上限の名前8国内の LangGraph・Mastra・n8n・Dify の本番例（未発見）9外部 skill・hook の公式の注意文
根拠・出典・手順（折りたたみ）
  • 調べる項目の担当は researcher（D1 の追加依頼）案。「/goal の公式確認」は 2026-11-08 に公式ドキュメントで確認でき、調べる項目から外した（版要件・評価モデルの既定は引き続き要確認）。「国内のループ・グラフ実装例（追補中）」は国内追補（10_D）で件数がそろったため、「国内の LangGraph・Mastra・n8n・Dify の本番例（未発見）」に置き換えた（件数は9のまま）。決定済みの2項目（Hermes 保留・ノード編集の保存方法）は 12-2 に確認として載せる。
この章の結論
足りない所だけが、次の作業になる
代表に答える12項目、調べる9項目
12
ASK

代表に答えてほしいこと（12項目）

層：出口　返してほしいのは2つ。決定済みの2項目は確認だけ

12-1返してほしいのは、共通認識の可否と下の12項目

この2つが返れば、返答の内容で直します。

①共通認識OK直す点②12章の項目答える12項目決定済み2項目（確認のみ）1回で返す代表の返答
根拠・出典・手順（折りたたみ）
  • 次の版は作らず、返答の内容で修正する（作業票 §2「止める目標」）。

12-2答えてほしいのは12項目。決定済みの2項目は確認だけ

黄は答えてほしい12項目、緑は決定済みの2項目です。黄色の欄は、推測で埋めていません。

#種別決めること選択肢決め手状態1承認EXPLACE 定義5つ（案）の承認承認／直す現場で言い切れるか代表承認2承認共通ルール10項目を CLAUDE.md に入れてよいか入れる／直す／入れない全部署に守らせる範囲か未決3選択最初に自動 PDCA を回す1本の業務（相談数に効く業務）代表が指定相談数にどれが効くか未決4選択柱の順番案（①②→③→④⑤）／変更どれを先に動かしたいか案5送付Slack ch の一覧と命名送付／AI が案を出す―未受領6指定自動 PDCA の上限（費用・回数）代表が指定月の費用上限未受領7選択代表への報告の頻度・形式案を別途出す見る頻度未決8送付動画7本の URL送付―未受領9確認代表のペルソナ段（読む段か）確認―要確認10選択実装の順番（13-4 の段階1〜4）で進めるか。skills と hooksのどちらを先にするか案どおり（hooks 先）／skills 先（仮説・出典なし）／変更作り直しを避けたいか、現場の手順を先に整えたいか案11選択段階4のあと、業務をまたぐ連動を試すか（出典なし）結果を見てから判断／置く／置かない許容できる損失の範囲未決12承認AI実装時の防ぎ方（13-5）を共通ルールに足してよいか足す／直す／足さない全部署のAIに守らせる範囲か未決済1決定済みHermes Agent は保留（売上に効く成果が数字で見えるまで。指揮は people-director・AIOffice・daily-guide の Slack）――決定 2026-11-06済2決定済みAI Office「設計」タブ＝2026-11-06 に本番公開済み。保存方法は「画面で保存 → D1に下書き → 手元で --pull-drafts → workflows.json に書き戻し」（正本は workflows.json）――決定・公開済み
問い（1つだけ）
共通認識はこの版で OK でしょうか。直す点があれば教えてください。あわせて、黄色の12項目に答えていただけますか。
根拠・出典・手順（折りたたみ）
  • 旧版（v1）の「共通ルールの置き場」は、#2 の「CLAUDE.md に入れてよいか」に統合した。
  • 旧版の「Hermes か既存か」は決定済み（済1）。再検討の条件は 08-4。
  • v3 で足した #10〜#12 は、代表の追加依頼（2026-11-08）への答え。#10 の「skills 先」は代表の仮説で出典なし（13-2）、#11 の「業務をまたぐ連動」も出典なし（13-3）。
  • 件数の確認：答える12（#1〜12）＋決定済み2（済1・済2）＝14。00-1・11-2・12-1 と同じ数。