ChatGPTなど別のLLMに書かせた要件定義書や実装計画書を、Claude Codeに渡して実装させる。この受け渡し自体は珍しくありません。私も何度かやりました。ただ、受け取る側の設計を考えずに既存のフォルダへそのまま置くと、あとで必ず面倒になります。
この記事は、個人で動かしているAIエージェント組織に「外部LLM・他人が作った文書」を受け入れる口を作ったときの設計メモです。口の名前は intake。一旦そこに置き、人がトリアージしてから正規の場所へ移す、という2段構えにしました。
先に正直に書いておくと、この口を作ったのは2026年10月12日で、2026年10月26日時点の受領台帳に実際の受領記録はまだ1件もありません（記入例の1行だけです）。したがってこの記事は「運用して効果が出た」報告ではなく、「なぜこの形にしたか」の設計記録です。効果の数字は出していません。
前提
- 環境: macOS、Claude Code、Markdownとシェルスクリプト。1つのGitリポジトリに台帳・設計書・スクリプトが同居しています。
- 複数のAI・定期ジョブ・人が同じブランチに書き込みます。
- 外部LLM産の文書は、プロジェクト番号もタスク番号もない状態で届きます。
最後のポイントが設計の出発点です。番号がない文書は、既存の管理体系のどこにも属していません。
直置きで何が困るか——私が警戒した3つの型
直置き（受け取ったファイルをそのまま既存フォルダへ）を避けた理由は、過去に自分で見てきた失敗の型に重なったからです。ここは今回の運用で起きた事故ではなく、体験DBにある別件の経験からの類推だと明示しておきます。
① 要件の曖昧さ。口約束で受けた仕事で、要件が後から際限なく追加され、作業量が見積もりの3倍になったことがあります。以降は契約書にスコープと変更管理の条項を書くようにしました。外部LLMの文書も同じで、書かれていない前提は、読む側のAIが勝手に補います。
② 現場とのずれ。既存の業務システムがデスクトップ前提で、現場の作業者が使えなかったことがあります。大きなボタンと写真撮影、オフライン入力に作り直したところ、報告書の作成が1件あたり1時間から10分になりました。外部LLMは私の現場を見ていません。文書が「正しそう」でも、私の運用に合うかは別問題です。
③ 暗黙知の欠落。バックアップを取っているつもりでいたのに、ハードウェア障害で3日分のデータを失ったことがあります。「取っている」と「復旧できる」は別物で、復旧手順を書いて月1回テストするまで安心できませんでした。外部LLMが書く文書にも、この種の穴は見た目には出てきません。穴は埋まっているように見えるだけです。
3つに共通するのは、文書の見た目の整い方と中身の信頼性が比例しない、という点です。ここから「受け取った瞬間は正本にしない」という方針を決めました。
設計：置き場を2つに分ける
.company/intake/
├── pending/ # 受領直後・未トリアージ。ここには新規ファイルしか置かない
├── _archive/ # トリアージ済みの退避先。元のフォルダ名・構成は変えない
└── intake-ledger.md # 受領台帳（正本）
| 場所 | 誰が置く | 中身の扱い |
|---|---|---|
pending/ |
外部LLMの出力を持ち込む人、他人の環境からのpush | 未審査。実装の根拠にしない |
| 正規配置（案件・プロジェクト・各リポジトリ配下など） | トリアージした人 | 審査済み。通常の管理対象 |
_archive/ |
トリアージ後の元フォルダ | 参照用。名前を変えず残す |
決めたルールは次のとおりです。
-
pending/配下にだけ新規ファイルを置く。 既存ファイルの変更や他ディレクトリへの書き込みは想定しない。 - フォルダ名は
YYYYMMDD_送り元_トピック/を推奨（強制はしない）。 - トリアージは人（または秘書役のAI）が気づいたときに手動で行う。
- トリアージ後は、必要な文書を正規配置へコピー（または必要部分を転記）して正本にし、受領時の元フォルダは名前を変えずに
_archive/へ移し、台帳に1行書く。 -
private/は置き場にしない。要件定義書はほぼMarkdownで、私の環境ではprivate/配下への新規Markdown作成が別のガードで止まる運用になっているため、そもそも成立しません。
台帳の列
| 受領日 | 送り元 | 内容概要 | 状態 | 紐付け先 | アーカイブ先 |
|---|
状態は pending → triaged → archived の3つだけです。紐付け先には、既存のプロジェクト／案件／タスクの番号を書きます。該当がなければ、そのとき既存の採番手順で新規採番します。
トリアージ手順
私は次の順で見ています。
-
pending/の未処理フォルダを一覧する（下のスクリプト）。 - 文書を読み、既存のどのプロジェクトに紐づくかを判断する。紐づかなければ新規採番の要否を決める。
- 前提のチェック（下記5問）を通す。
- 必要な文書を正規配置へコピー（または必要部分を転記）して正本にする。実装に進む場合は、通常のタスク受付と同じゲートを通す。
- 受領時の元フォルダを名前を変えずに
_archive/へ移し、台帳に追記する。
前提チェック5問
外部LLM産の文書を正本にする前に、私は次を確認します。
| # | 問い | 見ているもの |
|---|---|---|
| 1 | 文書が前提にしているファイル・設定・用語は、うちに実在するか | 存在しない前提 |
| 2 | 既存の設計書・台帳と同じ概念を別名で再定義していないか | 重複定義 |
| 3 | 既存の方針と矛盾する前提を置いていないか | 前提矛盾 |
| 4 | 「誰が・いつ・何を承認するか」が書かれているか | 暗黙の承認フロー |
| 5 | 外部への送信・課金・本番反映など、ゲートが要る操作を含むか | 対外アクション |
2・3には、Claude Codeに「この文書と既存の関連設計書を突き合わせて、矛盾と重複を列挙して」と頼むのが効きました。AIを壁打ち相手にした設計レビューでは、5つの改善提案のうち2つが本番運用で問題になりうる重大な設計漏れだったことがあり、レビュアーが社内にいない一人運用ほど価値があると感じています。ただしその提案は候補であって判定ではありません。採否は人が決めます。
一覧スクリプト
pending/ の未処理を眺めるための読み取り専用スクリプトです。このスクリプトは実行していません（not-executed）。macOSの stat -f を前提にしており、Linuxでは書式が違います（GNU の場合は stat -c '%y' {} + | cut -c1-10 のように読み替えます）。md_lines は改行数ベースの概算で、pending/ 直下に置かれた単体ファイルは一覧に出ません（サブフォルダだけが対象です）。環境に合わせて直してください。
#!/bin/sh
# 未トリアージ（pending/直下）のフォルダを、ファイル数・md行数・配下ファイルの最終更新日つきで一覧する。読み取りのみ。
INTAKE_DIR="${1:-.company/intake}"
for d in "$INTAKE_DIR"/pending/*/; do
[ -d "$d" ] || continue
files=$(find "$d" -type f | wc -l | tr -d ' ')
lines=$(find "$d" -type f -iname '*.md' -exec cat {} + | wc -l | tr -d ' ')
mtime=$(find "$d" -type f -exec stat -f '%Sm' -t '%Y-%m-%d' {} + | sort | tail -1)
mtime=${mtime:--}
printf '%s\tfiles=%s\tmd_lines=%s\tlast=%s\n' "$(basename "$d")" "$files" "$lines" "$mtime"
done
本文で「このスクリプトが何かを止める」とは言っていません。一覧を出すだけで、判定も移動もしません。
この設計の限界
-
強制するしくみは入れていません。 「
pending/配下にだけ置く」はトラストベースで、誰かが別の場所へ直接置けば止まりません。置かれた場合は気づいた人が手で戻します。 - トリアージは手動で、起動時の自動チェックにも入れていません。 受領が増えたら見直す前提で、今は台帳が空なので入れていません。
- 「受け取り・置き場・トリアージ」までをこの仕組みの範囲にしています。 取り込んだ計画書を実装する段階では、通常のタスク受付やレビューのゲートを免除しません。intakeは入口を整えるだけで、実装の品質は保証しません。
- 前提チェック5問は、私の環境に合わせた私用のチェックリストです。網羅を謳うものではありません。
まとめ
- 外部LLM産の文書は「番号のない、未審査の文書」として扱い、専用の
pending/に置く。 - 正規配置への正本化（コピーまたは転記）と元フォルダの
_archive/への退避は人が行い、台帳記入と1セットにする。 - 前提チェックでは、存在しない前提・重複定義・前提矛盾・承認フロー・対外アクションの有無を見る。
- 強制はしていないので、運用は規律に依存する。
いちばん大きかったのは、文書の出どころが外部LLMであること自体より、番号も持ち主もない文書が既存の体系に紛れ込むことを問題にした点です。置き場を分けるだけで「まだ信用していない」という状態をファイルシステム上に残せます。効果の検証はこれからなので、台帳に実際の受領が溜まったら、前提チェックで何件が引っかかったかを数えて、またここに追記するつもりです。
私はこの形に落ち着きましたが、他の運用もあると思います。みなさんは、別のLLMが書いた文書を受け入れるとき、どこに置いて、誰がいつ審査していますか？ コメントで教えてもらえると助かります。
この記事について
AIエージェントに会社の実務を任せる試みを続けています。この記事もその過程で出てきたものです。
同じ試みの記録を note で連載しています（うまくいかなかった話も含めて）。
📘 AI組織のつくりかた — https://note.com/fuji1009
続きが気になる方は Qiita のフォローをしていただけると、新しい記事が届きます。